info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1000785: bullseye-pu: package curl/7.74.0-1.3+deb11u1
9 views
Skip to first unread message
Helmut Grohne
Nov 28, 2021, 3:50:03 PM11/28/21
to
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.d...@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Alessandro Ghedini <gh...@debian.org>, Samuel Henrique <samu...@debian.org>, Sergio Durigan Junior <serg...@debian.org>
libcurl4-gnutls-dev is not multiarch-coinstallable in bullseye despite
being marked Multi-Arch: same. When attempting to coinstall it, dpkg
issues an unpack error. That's a very bad thing to do.
The issue has been reported as #990128 and has been fixed in unstable.
Reproducible builds added compiler flags that include the build
directory (which varies per build) and those build flags made it into
curl-config. As such, reproducible builds made curl unreproducible. This
issue has been well understood and for a different compiler flag, a
workaround was already in place in debian/rules. The solution was to
extend the workaround in the obvious way (stripping that other flag).
I think that the risk/benefit ratio is good. The only affected piece is
curl-config, the change is fairly obvious and it makes unpack errors
from dpkg go away. It also has been in testing for a while now. buster
is unaffected by this issue.
Note that I am not a curl maintainer, but I provided the solution for
unstable. I intend to NMU this change. I've put the curl maintainers
into X-Debbugs-Cc in case they wish to pick this up.
The full (small) .debdiff is attached.
Helmut
Severity: normal
Tags: bullseye
User: release.d...@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Alessandro Ghedini <gh...@debian.org>, Samuel Henrique <samu...@debian.org>, Sergio Durigan Junior <serg...@debian.org>
libcurl4-gnutls-dev is not multiarch-coinstallable in bullseye despite
being marked Multi-Arch: same. When attempting to coinstall it, dpkg
issues an unpack error. That's a very bad thing to do.
The issue has been reported as #990128 and has been fixed in unstable.
Reproducible builds added compiler flags that include the build
directory (which varies per build) and those build flags made it into
curl-config. As such, reproducible builds made curl unreproducible. This
issue has been well understood and for a different compiler flag, a
workaround was already in place in debian/rules. The solution was to
extend the workaround in the obvious way (stripping that other flag).
I think that the risk/benefit ratio is good. The only affected piece is
curl-config, the change is fairly obvious and it makes unpack errors
from dpkg go away. It also has been in testing for a while now. buster
is unaffected by this issue.
Note that I am not a curl maintainer, but I provided the solution for
unstable. I intend to NMU this change. I've put the curl maintainers
into X-Debbugs-Cc in case they wish to pick this up.
The full (small) .debdiff is attached.
Helmut
Adam D. Barratt
Nov 30, 2021, 3:40:04 PM11/30/21
to
Control: tags -1 + moreinfo
On Sun, 2021-11-28 at 21:39 +0100, Helmut Grohne wrote:
> libcurl4-gnutls-dev is not multiarch-coinstallable in bullseye
> despite being marked Multi-Arch: same. When attempting to coinstall
> it, dpkg issues an unpack error. That's a very bad thing to do.
>
ACK.
> The issue has been reported as #990128 and has been fixed in
> unstable.
> Reproducible builds added compiler flags that include the build
> directory (which varies per build) and those build flags made it into
> curl-config. As such, reproducible builds made curl unreproducible.
> This
> issue has been well understood and for a different compiler flag, a
> workaround was already in place in debian/rules. The solution was to
> extend the workaround in the obvious way (stripping that other flag).
>
> I think that the risk/benefit ratio is good. The only affected piece
> is
> curl-config, the change is fairly obvious and it makes unpack errors
> from dpkg go away.
What's the potential impact of the change? Is "curl-config --configure"
consumed by anything, other than human eyeballs?
Regards,
Adam
On Sun, 2021-11-28 at 21:39 +0100, Helmut Grohne wrote:
> libcurl4-gnutls-dev is not multiarch-coinstallable in bullseye
> despite being marked Multi-Arch: same. When attempting to coinstall
> it, dpkg issues an unpack error. That's a very bad thing to do.
>
> The issue has been reported as #990128 and has been fixed in
> unstable.
> Reproducible builds added compiler flags that include the build
> directory (which varies per build) and those build flags made it into
> curl-config. As such, reproducible builds made curl unreproducible.
> This
> issue has been well understood and for a different compiler flag, a
> workaround was already in place in debian/rules. The solution was to
> extend the workaround in the obvious way (stripping that other flag).
>
> I think that the risk/benefit ratio is good. The only affected piece
> is
> curl-config, the change is fairly obvious and it makes unpack errors
> from dpkg go away.
consumed by anything, other than human eyeballs?
Regards,
Adam
Helmut Grohne
Dec 1, 2021, 5:50:03 AM12/1/21
to
Control: tags -1 - moreinfo
Hi Adam,
On Tue, Nov 30, 2021 at 08:25:57PM +0000, Adam D. Barratt wrote:
> What's the potential impact of the change? Is "curl-config --configure"
> consumed by anything, other than human eyeballs?
curl-config is mainly meant for machine consumption. It kinda is a
predecessor of pkg-config.
Preconditions to be affected:
* You must perform a build of a software using one of the
libcurl*-*-dev packages.
* Your build must not use pkg-config (very uncommon), but rather use
curl-config.
* Your build consumes curl-config --cflags (roughly equivalent to
pkg-config --cflags libcurl).
As such I think that the number of affected users is fairly small (due
to the requirement of not using pkg-config).
If all of these are met, then your cflags now lost a flag:
-file-prefix-map=$build_path_used_while_building_curl=.
This flag should not be used by your build in the first place. Since our
buildd build paths are generated randomly, it is very unlikely that any
of the files you are building matches this prefix. The flag normally
does not have any effect on your build. As such, dropping it normally
does not change your build.
As such, I think that the risk of breaking something is fairly low. Keep
in mind that oldstable lacks this bug (and this flag). If something was
seriously broken there, we'd surely have received a bug report by now.
Even switching to pkg-config would drop that flag and it really doesn't
belong there in the first place. It was injected there by the
reproducible builds folks in order to make the curl build unreproducible
err I meant reproducible. Whatever.
Helmut
Hi Adam,
On Tue, Nov 30, 2021 at 08:25:57PM +0000, Adam D. Barratt wrote:
> What's the potential impact of the change? Is "curl-config --configure"
> consumed by anything, other than human eyeballs?
predecessor of pkg-config.
Preconditions to be affected:
* You must perform a build of a software using one of the
libcurl*-*-dev packages.
* Your build must not use pkg-config (very uncommon), but rather use
curl-config.
* Your build consumes curl-config --cflags (roughly equivalent to
pkg-config --cflags libcurl).
As such I think that the number of affected users is fairly small (due
to the requirement of not using pkg-config).
If all of these are met, then your cflags now lost a flag:
-file-prefix-map=$build_path_used_while_building_curl=.
This flag should not be used by your build in the first place. Since our
buildd build paths are generated randomly, it is very unlikely that any
of the files you are building matches this prefix. The flag normally
does not have any effect on your build. As such, dropping it normally
does not change your build.
As such, I think that the risk of breaking something is fairly low. Keep
in mind that oldstable lacks this bug (and this flag). If something was
seriously broken there, we'd surely have received a bug report by now.
Even switching to pkg-config would drop that flag and it really doesn't
belong there in the first place. It was injected there by the
reproducible builds folks in order to make the curl build unreproducible
err I meant reproducible. Whatever.
Helmut
Adam D. Barratt
Dec 3, 2021, 11:00:05 AM12/3/21
to
Control: tags -1 + confirmed
On Wed, 2021-12-01 at 11:06 +0100, Helmut Grohne wrote:
> Control: tags -1 - moreinfo
>
> Hi Adam,
>
> On Tue, Nov 30, 2021 at 08:25:57PM +0000, Adam D. Barratt wrote:
> > What's the potential impact of the change? Is "curl-config --
> > configure"
> > consumed by anything, other than human eyeballs?
>
> curl-config is mainly meant for machine consumption. It kinda is a
> predecessor of pkg-config.
>
> Preconditions to be affected:
> * You must perform a build of a software using one of the
> libcurl*-*-dev packages.
> * Your build must not use pkg-config (very uncommon), but rather use
> curl-config.
> * Your build consumes curl-config --cflags (roughly equivalent to
> pkg-config --cflags libcurl).
>
> As such I think that the number of affected users is fairly small
> (due to the requirement of not using pkg-config).
>
Thanks for the detailed explanation. Please go ahead.
Regards,
Adam
On Wed, 2021-12-01 at 11:06 +0100, Helmut Grohne wrote:
> Control: tags -1 - moreinfo
>
> Hi Adam,
>
> On Tue, Nov 30, 2021 at 08:25:57PM +0000, Adam D. Barratt wrote:
> > What's the potential impact of the change? Is "curl-config --
> > configure"
> > consumed by anything, other than human eyeballs?
>
> curl-config is mainly meant for machine consumption. It kinda is a
> predecessor of pkg-config.
>
> Preconditions to be affected:
> * You must perform a build of a software using one of the
> libcurl*-*-dev packages.
> * Your build must not use pkg-config (very uncommon), but rather use
> curl-config.
> * Your build consumes curl-config --cflags (roughly equivalent to
> pkg-config --cflags libcurl).
>
> As such I think that the number of affected users is fairly small
> (due to the requirement of not using pkg-config).
>
Regards,
Adam
Helmut Grohne
Dec 3, 2021, 4:30:03 PM12/3/21
to
Dear curl maintainers,
Adam has acked my stable upload. Consequently, I've uploaded my proposed
NMU. In accordance with devrev, it went to delayed/5. Please let me know
if that doesn't work for you. The diff is exactly the one I sent
previously.
Helmut
Adam has acked my stable upload. Consequently, I've uploaded my proposed
NMU. In accordance with devrev, it went to delayed/5. Please let me know
if that doesn't work for you. The diff is exactly the one I sent
previously.
Helmut
Sergio Durigan Junior
Dec 3, 2021, 4:40:03 PM12/3/21
to
Sorry for the delay in replying. I looked at your patch and it seems
like a sensible approach to me. Thanks for taking care of it.
Cheers,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/
Adam D Barratt
Dec 11, 2021, 12:40:05 PM12/11/21
to
package release.debian.org
tags 1000785 = bullseye pending
thanks
Hi,
The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye.
Thanks for your contribution!
Upload details
==============
Package: curl
Version: 7.74.0-1.3+deb11u1
Explanation: remove -ffile-prefix-map from curl-config, fixing co-installability of libcurl4-gnutls-dev under multiarch
tags 1000785 = bullseye pending
thanks
Hi,
The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye.
Thanks for your contribution!
Upload details
==============
Package: curl
Version: 7.74.0-1.3+deb11u1
Explanation: remove -ffile-prefix-map from curl-config, fixing co-installability of libcurl4-gnutls-dev under multiarch
0 new messages