Bug#1050974: binNMU: Rebuild against curl without NSS support
Hi,
On 2023-09-02 19:42, Sebastian Ramacher wrote:
> > On top of that, those two packages have already been rebuilt for
> > riscv64 (no binNMUs required there), whereas if we force another
> > upload only to solve this, we will trigger a build for every arch and
> > needlessly consume at the very least 77 hours of the riscv builders'
> > time (while we are still rebuilding the archive for riscv, delaying it
> > all).
> > https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-14=riscv64
> > https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-15=riscv64
> >
> > Do you think that's a sensible compromise?
> > I'm asking to proceed with binNMUs because eg25-manager has been fixed
> > in git already and the llvm packages are about to be removed (although
> > I want curl to migrate before that), also rebuilding them on riscv
> > takes a lot of effort at a not-so-great time (no binNMUs required for
> > riscv).
>
> Please get those uploaded instead. We will rebuild
> llvm-toolchain-{14,15} a bunch of times for transitions anyway. If
> riscv64 buildds are not ready to cope with that, the architecture is not
> ready to become a release architecture.
Please note that avoiding an upload on riscv64 is NOT a request from the
riscv64 porters. Despite the long building time, we believe that the
build daemons will be able to handle a rebuild of those packages. In
addition 2 more buildds are being prepared.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
signature.asc
Description: PGP signature
Bug#1050976: Bug#1050974: binNMU: Rebuild against curl without NSS support
Hi
On 2023-09-02 18:27:39 +0100, Samuel Henrique wrote:
> Hello Sebastian anb Paul,
>
> > So let's not just rebuild those. Samuel, please file bugs against those
> > packages so that the maintainers fix the build dependencies.
>
> I have filled bugs already, here's the current situation:
>
> eg25-manager:
> https://bugs.debian.org/1043547
> Has been fixed in git already, so the next upload will have the correct B-D.
>
> llvm-toolchain-14 and llvm-toolchain-15:
> https://bugs.debian.org/1043550
> https://bugs.debian.org/1043551
>
> I have not explicitly asked for the B-D change for llvm, and I think
> doing it so will be a waste of time and effort, let me explain.
> Both llvm-toolchain-14 and llvm-toolchain-15 will be removed from the
> archive soon, see their ROM bugs:
> https://bugs.debian.org/1050069
> https://bugs.debian.org/1050070
Removing old llvm-toolchain versions usually takes month. For reference,
removal of llvm-toolchain-13 took a year (RM bug was filed in August
2022) and is still part of trixie.
> On top of that, those two packages have already been rebuilt for
> riscv64 (no binNMUs required there), whereas if we force another
> upload only to solve this, we will trigger a build for every arch and
> needlessly consume at the very least 77 hours of the riscv builders'
> time (while we are still rebuilding the archive for riscv, delaying it
> all).
> https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-14=riscv64
> https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-15=riscv64
>
> Do you think that's a sensible compromise?
> I'm asking to proceed with binNMUs because eg25-manager has been fixed
> in git already and the llvm packages are about to be removed (although
> I want curl to migrate before that), also rebuilding them on riscv
> takes a lot of effort at a not-so-great time (no binNMUs required for
> riscv).
Please get those uploaded instead. We will rebuild
llvm-toolchain-{14,15} a bunch of times for transitions anyway. If
riscv64 buildds are not ready to cope with that, the architecture is not
ready to become a release architecture.
> Note: llvm-toolchain-16, which is going to be the new default, has
> already fixed the B-D and the package has been uploaded, so that's why
> there's no action for that one.
llvm-toolchain-16 can only become the default once its build is fixed on
mips64el. I have seen no progress in that direction, though.
Cheers
--
Sebastian Ramacher
Bug#1050974: binNMU: Rebuild against curl without NSS support
Hello Sebastian anb Paul, > So let's not just rebuild those. Samuel, please file bugs against those > packages so that the maintainers fix the build dependencies. I have filled bugs already, here's the current situation: eg25-manager: https://bugs.debian.org/1043547 Has been fixed in git already, so the next upload will have the correct B-D. llvm-toolchain-14 and llvm-toolchain-15: https://bugs.debian.org/1043550 https://bugs.debian.org/1043551 I have not explicitly asked for the B-D change for llvm, and I think doing it so will be a waste of time and effort, let me explain. Both llvm-toolchain-14 and llvm-toolchain-15 will be removed from the archive soon, see their ROM bugs: https://bugs.debian.org/1050069 https://bugs.debian.org/1050070 On top of that, those two packages have already been rebuilt for riscv64 (no binNMUs required there), whereas if we force another upload only to solve this, we will trigger a build for every arch and needlessly consume at the very least 77 hours of the riscv builders' time (while we are still rebuilding the archive for riscv, delaying it all). https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-14=riscv64 https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-15=riscv64 Do you think that's a sensible compromise? I'm asking to proceed with binNMUs because eg25-manager has been fixed in git already and the llvm packages are about to be removed (although I want curl to migrate before that), also rebuilding them on riscv takes a lot of effort at a not-so-great time (no binNMUs required for riscv). Note: llvm-toolchain-16, which is going to be the new default, has already fixed the B-D and the package has been uploaded, so that's why there's no action for that one. Thank you, -- Samuel Henrique
Bug#1050974: binNMU: Rebuild against curl without NSS support
On 2023-09-01 19:45:53 +0200, Paul Gevers wrote: > Hi, > > On 01-09-2023 14:25, Samuel Henrique wrote: > > These packages have a build dependency on the virtual package > > "libcurl4-dev", which is satisfiable by any variant of the curl > > binaries (openssl, gnutls, nss). > > Policy 7.5 [1] says that "To specify which of a set of real packages should > be the default to satisfy a particular dependency on a virtual package, list > the real package as an alternative before the virtual one." It's best > practice to specify which real package should be used to avoid apt choosing > it on the buildd. We had variation because of temporary non-installability > in the past (IIRC), it's better to wait with building. > > I must admit I though the requirement was stronger and you *had to* specify > a real package before a virtual build dependency. So let's not just rebuild those. Samuel, please file bugs against those packages so that the maintainers fix the build dependencies. Cheers > > Paul > > [1] > https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides -- Sebastian Ramacher
Bug#1050974: binNMU: Rebuild against curl without NSS support
Hi, On 01-09-2023 14:25, Samuel Henrique wrote: These packages have a build dependency on the virtual package "libcurl4-dev", which is satisfiable by any variant of the curl binaries (openssl, gnutls, nss). Policy 7.5 [1] says that "To specify which of a set of real packages should be the default to satisfy a particular dependency on a virtual package, list the real package as an alternative before the virtual one." It's best practice to specify which real package should be used to avoid apt choosing it on the buildd. We had variation because of temporary non-installability in the past (IIRC), it's better to wait with building. I must admit I though the requirement was stronger and you *had to* specify a real package before a virtual build dependency. Paul [1] https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1050974: binNMU: Rebuild against curl without NSS support
Control: tags -1 - moreinfo Hello Sebastian, I'm sending this same response to all 3 bugs related to this. > Why does that require rebuilds? These packages have a build dependency on the virtual package "libcurl4-dev", which is satisfiable by any variant of the curl binaries (openssl, gnutls, nss). Our current builds ended up linking against the nss variant, so now that we've dropped that, a rebuild is needed for the packages to pick either openssl or gnutls. Related bugs: Main one where I'm tracking all changes: libcurl4-nss-dev: NSS support will be dropped in August 2023 https://bugs.debian.org/1038907 Bugs against the packages I'm requesting the binNMUs: llvm-toolchain-14: links against libcurl3-nss which will be dropped in August 2023 https://bugs.debian.org/1043550 llvm-toolchain-15: links against libcurl3-nss which will be dropped in August 2023 https://bugs.debian.org/1043551 eg25-manager: build-depends on deprecated libcurl4-nss-dev, will be dropped in August 2023 https://bugs.debian.org/1043547 Thank you, -- Samuel Henrique
