Fix deb build again #1942
Fix deb build again #1942
Conversation
|
Note, adding new binary packages to the linuxcnc source package and
uploading it to Debian will require a review by the FTP master group in
Debian and send the package into the NEW queue,
<URL: https://ftp-master.debian.org/new.html >. This might take a
while, and should be taken into account when we plan when to introduce
new binary packages.
When that is said, I am positive to getting separate packages for German
and Norwegian Bokmål. Not conviced the amount of translations for
Norwegian Bokmål warrant a separate package, though.
…--
Happy hacking
Petter Reinholdtsen
|
Ah, I didn't realize that. I just added those debs because the DE and NB translated pdfs get built and installed now, and dh_missing complained that they weren't included in any package. I guess I'm ok with waiting in the NEW queue again (we're not really in a rush to refresh the debs), and I'd also be ok with not adding the new debs yet (and just removing those PDFs from the install directory, which I assume would make dh_missing not complain). Does anyone have any strong feelings one way or another on this topic? |
|
[Sebastian Kuzminsky]
Does anyone have any strong feelings one way or another on this topic?
I would strongly recommend to upload quickly to unstable without new
binary packages, and upload to experimental with the new binary
packages, to make the latest improvements available quickly to users,
while we wait for the package heading for experimental to clear the NEW
queue. This way we can continue uploading to unstable while we wait for
the FTP masters to accept the new binaries. I suspect this would be
best handled using separate branches for unstable and experimental, but
guess the d/configure script could be extended to handle it too (until
we switch to build profiles - #1835).
…--
Happy hacking
Petter Reinholdtsen
|
|
Look like Lintian found some errors: |
This deb is available on Buster too, so I just added it unconditionally to the build deps, no debian/configure trickery needed.
The manpages go in linuxcnc-uspace.deb (not in linuxcnc-doc-en), so they
are built with the architecture-dependent ("binary") debs.
Since some manpages are written in asciidoc rather than roff, these
build dependencies are needed in Build-Depends (which is satisfied for
both architecture-dependent and architecture-independent builds), not
just in Build-Depends-Indep.
SebKuzminsky
force-pushed
the
fix-deb-build-again
branch
from
d67f8fa to
5610245
Compare
|
Ok, the current version of this branch (5610245) addresses all raised issues, does not add any new debs, and I believe it will pass all our CI. If it's all green in the morning I'll merge it. |
|
Look good to me. All green too. :) |
|
Perhaps we should adjust the github DI to build all and any packages separately, as I tested in commit 2b47bd1? It currently fail. |
|
When manually upgrading the debs from before the deb rebuild, I get this: I suspect some file moved between packages, and the breaks/replaces/conflicts lines to handle it are missing. |
Hmm, yeah this is an issue when upgrading from debs built from master (on Buster or Bullseye, since master doesn't currently build on Unstable), to debs built from this PR. It's not an issue when upgrading from the current released debs (2.9.0~pre0+git20220402.2500863908-4). Please note that this issue is not introduced by this current PR, it was introduced in the earlier merge of commit 1ffed0f. The Replaces/Conflicts in that commit explicitly call out the previous released debs. The problem is that the master branch uses an epoch number (1: 2.9.0~pre0...), and the released debs in debian do not (2.9.0~pre0+git...), so all of "our" debs sort as newer than all of the released debs... As far as I know there's no way to say "these new debs conflict with all previous debs from master, and with all previous released debs", because "all previous debs from master" will include all released debs ever, now and in the future. Unless we add the epoch number back in to the released debs, which I was told was a no-go from debian.org. I agree it's unfortunate that debs built by the buildbot from the master branch have this one-time self-conflict, but i don't know how to fix it without messing with how the official debs are numbered. :-( |
I am very much in favor of this suggestion, and also would like to extend our Github CI to test on a matrix of distros and hardware architectures, like this: |
|
[Sebastian Kuzminsky]
Hmm, yeah this is an issue when upgrading from debs built from master
(on Buster or Bullseye, since master doesn't currently build on
Unstable), to debs built from this PR. It's not an issue when
upgrading from the current released debs
(2.9.0~pre0+git20220402.2500863908-4).
Ah, right. Then it is OK.
The Replaces/Conflicts in that commit explicitly call out the previous
*released* debs. The problem is that the master branch uses an epoch
number (**1:** 2.9.0\~pre0...), and the released debs in debian do not
(2.9.0\~pre0+git...), so all of "our" debs sort as newer than all of
the released debs...
I had not noticed the snapshot builds from master used epochs. Good to
know.
As far as I know there's no way to say "these new debs conflict with
all previous debs from master, and with all previous released debs",
because "all previous debs from master" will include all released debs
ever, now and in the future. Unless we add the epoch number back in
to the released debs, which I was told was a no-go from debian.org.
The policy on the matter is available from
<URL: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version >.
I suspect it is a good idea to unify the snapshots and debian versions,
so perhaps someone should try to consult debian-devel@ on the matter?
I agree it's unfortunate that debs built by the buildbot from the
master branch have this one-time self-conflict, but i don't know how
to fix it without messing with how the official debs are numbered.
:-(
Do not bother. If it only involve the test packages from master, we
can ignore the problem as everyone with the packages in question should
be expected to handle any cleanup on their own.
…--
Happy hacking
Petter Reinholdtsen
|
This PR fixes building the architecture-specific and architecture-independent debs separately (i.e.
dpkg-buildpackage -Aanddpkg-buildpackage -B), as apparently the debian.org build infrastructure does but which we do not yet test in any of our CI (PR for this coming soon). This fix just consists of moving some build dependencies fromBuild-Depends-Independent(used for architecture-independent package builds) toBuild-Depends(used for both architecture-independent and architecture-dependent package builds).At some point we should probably split out the architecture-specific stuff from
Build-DependstoBuild-Depends-Arch, that's not included here.This PR also adds linuxcnc-doc-{de,nb}, since we're now building those translated docs and Sid (but not Buster) fails the deb build if those PDFs are installed by the "upstream" build but not included in any packages.
This PR takes care of the last thing I've found so far that needs to be fixed for the next dsc upload to debian.org.
@smoe & @petterreinholdtsen , your feedback on the packaging here is welcome.