Report forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#894441; Package dpkg-dev.
(Fri, 30 Mar 2018 11:15:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Jean-Michel Vourgère <nirgal@debian.org>:
New Bug report received and forwarded. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Fri, 30 Mar 2018 11:15:04 GMT) (full text, mbox, link).
Package: dpkg-dev
Version: 1.19.0.5
Severity: important
Justification: Make unrelated packages violate multi-arch specs
Dear Maintainer,
When doing bin-nmu, each architecture gets its own d/changelog entry like:
rrdtool (1.7.0-1+b1) sid; urgency=low, binary-only=yes
* Binary-only non-maintainer upload for arm64; no source changes.
* Rebuild without ruby2.3 support.
-- arm Build Daemon (arm-conova-01) <buildd_arm64-arm-
conova-01@buildd.debian.org> Tue, 27 Mar 2018 12:27:33 +0000
rrdtool (1.7.0-1+b1) sid; urgency=low, binary-only=yes
* Binary-only non-maintainer upload for armhf; no source changes.
* Rebuild without ruby2.3 support.
-- armhf / armel Build Daemon (hoiby) <buildd_armhf-hoiby@buildd.debian.org>
Wed, 28 Mar 2018 08:13:09 +0000
As a result, when building rrdtool +b1 on arm64 [1] we have:
SOURCE_DATE_EPOCH="1522153653"
while on armhf [2] we have:
SOURCE_DATE_EPOCH="1522224789"
This causes the packages librrds-perl - that uses pod2man - to get /usr/share/
man/man3/RRDs.3pm.gz having different files on different architectures:
On amd64 architecture:
.TH RRDs 3pm "2018-03-27" "perl v5.26.1" "User Contributed Perl Documentation"
On armhf architecture:
.TH RRDs 3pm "2018-03-28" "perl v5.26.1" "User Contributed Perl Documentation"
This in turn results in the package no longer being Multi-arch:same after the
bin-nmus, as reported by
Since a bin-nmu can occur for a single architecture, I believe the best course
of action would be to change dpkg-buildpackage behavior to keep previous
SOURCE_DATE_EPOCH when building a bin-nmu'ed package. This could be achive by
ignoring the entries in d/changelog that contain the "binary-only=yes" tag
when setting SOURCE_DATE_EPOCH.
Note that I did not test this solution. WB team input would be great at this
point.
Appologies for the severity. While multi-arch is not part of the policy
(#749826), I guess it is used wildly-enough to justify this. Fell free to
adjust, obviously.
See also https://lists.debian.org/debian-wb-team/2018/03/msg00040.html
[1] https://buildd.debian.org/status/fetch.php?
pkg=rrdtool&arch=arm64&ver=1.7.0-1+b1&stamp=1522153882&raw=0
[2] https://buildd.debian.org/status/fetch.php?
pkg=rrdtool&arch=armhf&ver=1.7.0-1+b1&stamp=1522225293&raw=0
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#894441; Package dpkg-dev.
(Fri, 30 Mar 2018 14:06:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Chris Lamb <lamby@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Fri, 30 Mar 2018 14:06:03 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#894441; Package dpkg-dev.
(Fri, 30 Mar 2018 18:18:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Sven Joachim <svenjoac@gmx.de>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Fri, 30 Mar 2018 18:18:03 GMT) (full text, mbox, link).
On 2018-03-30 15:02 +0100, Chris Lamb wrote:
> [adding 894441@ to CC]
>
> Hi Jean-Michel,
>
>> Filled as #894441
>> https://bugs.debian.org/894441
>
> Thanks for this. I was just briefly wondering whether this is related to:
>
> https://lists.debian.org/debian-security/2017/05/msg00011.html
It seems so. What you are describing there had been noticed by Ian
Jackson before:
https://lists.debian.org/debian-devel/2016/11/msg00328.html
Ian then filed bug #843773 against sbuild, and as a result sbuild (as of
version 0.73.0-1) no longer reuses the timestamp of the last changelog
entry in binNMUs.
The same version of sbuild introduced a --binNMU-timestamp option, and I
think wanna-build should use it to achieve a consistent
SOURCE_DATE_EPOCH across architectures in binNMUs. Something along
these lines had already been proposed in #843773.
Cheers,
Sven
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#894441; Package dpkg-dev.
(Sat, 31 Mar 2018 13:09:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Philipp Kern <pkern@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Sat, 31 Mar 2018 13:09:03 GMT) (full text, mbox, link).
On 2018-03-30 20:15, Sven Joachim wrote:
> On 2018-03-30 15:02 +0100, Chris Lamb wrote:
>
>> [adding 894441@ to CC]
>>
>> Hi Jean-Michel,
>>
>>> Filled as #894441
>>> https://bugs.debian.org/894441
>>
>> Thanks for this. I was just briefly wondering whether this is related
>> to:
>>
>> https://lists.debian.org/debian-security/2017/05/msg00011.html
>
> It seems so. What you are describing there had been noticed by Ian
> Jackson before:
>
> https://lists.debian.org/debian-devel/2016/11/msg00328.html
>
> Ian then filed bug #843773 against sbuild, and as a result sbuild (as
> of
> version 0.73.0-1) no longer reuses the timestamp of the last changelog
> entry in binNMUs.
>
> The same version of sbuild introduced a --binNMU-timestamp option, and
> I
> think wanna-build should use it to achieve a consistent
> SOURCE_DATE_EPOCH across architectures in binNMUs. Something along
> these lines had already been proposed in #843773.
I'd hold that the sourceful uploads Ubuntu does (XbuildY) are actually a
cleaner solution to the problem. The cute hack is necessary because a)
our policies discourage sourceful NMUs heavily and b) scheduling an
automatic rebuild is more than a simple RPC call and involves a
re-upload of the whole source package.
Right now wanna-build still has no notion of a consistent state across
architectures. So just like version picking is already done in higher
level orchestration (wb) that tool would need to provide the timestamps
as well. Information is also lost whenever new state is merged, although
practically that's probably not a problem here because a new sourceful
build would be pushed to all architectures mostly at once anyway.
Kind regards
Philipp Kern
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#894441; Package dpkg-dev.
(Thu, 05 Apr 2018 16:27:05 GMT) (full text, mbox, link).
Acknowledgement sent
to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Thu, 05 Apr 2018 16:27:05 GMT) (full text, mbox, link).
Cc: 894441@bugs.debian.org, Chris Lamb <lamby@debian.org>,
debian-wb-team@lists.debian.org,
reproducible-builds@lists.alioth.debian.org,
Ian Jackson <ijackson@chiark.greenend.org.uk>,
Julien Cristau <jcristau@debian.org>
On Thu, Apr 05, 2018 at 05:43:58PM +0200, Jean-Michel Vourgère wrote:
> So, during compilation:
> SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries
> because it breaks Multi-Arch:same on bin-nmu.
>
> During dpkg-deb (:
> SOURCE_DATE_EPOCH must *not* ignore bin-nmu changelog entries
> because it would break software relying on files mtime.
>
> Doh!
different ways of parsing debian/changelog to determine S_D_E is a road
to desaster, sorry.
> In https://bugs.debian.org/843773#75 Ian Jackson propose to introduce a
> BUILD_DATE_EPOCH (= time of sbuild binnmu invocation) be prefered over
> SOURCE_DATE_EPOCH by dpkg-deb.
>
> That would work, wouldn't it?
I'm also not convinced this would be a good solution.
Sadly I also don't have another idea than changing the way binNMUs are
done :( Them being no-source-changes-rebuilds with changes to
debian/changelog, which is part of the source, (IMNSHO) is poor design
and the root of this and other problems.
--
cheers,
Holger
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#894441; Package dpkg-dev.
(Thu, 05 Apr 2018 16:27:06 GMT) (full text, mbox, link).
Acknowledgement sent
to Jean-Michel Vourgère <nirgal@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Thu, 05 Apr 2018 16:27:06 GMT) (full text, mbox, link).
Cc: debian-wb-team@lists.debian.org, reproducible-builds@lists.alioth.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>, Chris Lamb <lamby@debian.org>, Julien Cristau <jcristau@debian.org>
On Friday, 30 March 2018 15:02:31 CEST Chris Lamb wrote:
> [ https://lists.debian.org/debian-security/2017/05/msg00011.html ]
On Friday, 30 March 2018 20:15:33 CEST Sven Joachim wrote:
> [ https://bugs.debian.org/843773 ]
Thanks a lot guys for pointing out that issue!
Basically, when doing bin-nmus, we really want to bump the mtime of the
distributed files. Not doing so results in some backups programs (rsync...) to
loose updates. Other programs restarting services on libraries updates
(needrestart...) would also be affected.
So, during compilation:
SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries
because it breaks Multi-Arch:same on bin-nmu.
During dpkg-deb (:
SOURCE_DATE_EPOCH must *not* ignore bin-nmu changelog entries
because it would break software relying on files mtime.
Doh!
In https://bugs.debian.org/843773#75 Ian Jackson propose to introduce a
BUILD_DATE_EPOCH (= time of sbuild binnmu invocation) be prefered over
SOURCE_DATE_EPOCH by dpkg-deb.
That would work, wouldn't it?
Information forwarded
to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>: Bug#894441; Package dpkg-dev.
(Thu, 12 Apr 2018 12:12:45 GMT) (full text, mbox, link).
Acknowledgement sent
to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>.
(Thu, 12 Apr 2018 12:12:45 GMT) (full text, mbox, link).
To: Jean-Michel Vourgère <nirgal@debian.org>,
894441@bugs.debian.org
Cc: debian-wb-team@lists.debian.org,
reproducible-builds@lists.alioth.debian.org,
Ian Jackson <ijackson@chiark.greenend.org.uk>,
Chris Lamb <lamby@debian.org>, Julien Cristau <jcristau@debian.org>
Control: reassign -1 buildd.debian.org
Hi!
On Thu, 2018-04-05 at 17:43:58 +0200, Jean-Michel Vourgère wrote:
> On Friday, 30 March 2018 15:02:31 CEST Chris Lamb wrote:
> > [ https://lists.debian.org/debian-security/2017/05/msg00011.html ]
>
> On Friday, 30 March 2018 20:15:33 CEST Sven Joachim wrote:
> > [ https://bugs.debian.org/843773 ]
>
> Thanks a lot guys for pointing out that issue!
>
> Basically, when doing bin-nmus, we really want to bump the mtime of the
> distributed files. Not doing so results in some backups programs (rsync...) to
> loose updates. Other programs restarting services on libraries updates
> (needrestart...) would also be affected.
>
>
> So, during compilation:
> SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries
> because it breaks Multi-Arch:same on bin-nmu.
>
> During dpkg-deb (:
> SOURCE_DATE_EPOCH must *not* ignore bin-nmu changelog entries
> because it would break software relying on files mtime.
>
> Doh!
>
> In https://bugs.debian.org/843773#75 Ian Jackson propose to introduce a
> BUILD_DATE_EPOCH (= time of sbuild binnmu invocation) be prefered over
> SOURCE_DATE_EPOCH by dpkg-deb.
>
> That would work, wouldn't it?
Please, see my reply at <https://bugs.debian.org/843773#132>. This is
really a fundamental problem with binNMUs+multiarch-refcounting or how
they are being issued. :)
Thanks,
Guillem
Bug reassigned from package 'dpkg-dev' to 'buildd.debian.org'.
Request was from Guillem Jover <guillem@debian.org>
to 894441-submit@bugs.debian.org.
(Thu, 12 Apr 2018 12:12:45 GMT) (full text, mbox, link).
No longer marked as found in versions dpkg/1.19.0.5.
Request was from Guillem Jover <guillem@debian.org>
to 894441-submit@bugs.debian.org.
(Thu, 12 Apr 2018 12:12:46 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Buildd Team <wb-team@buildd.debian.org>: Bug#894441; Package buildd.debian.org.
(Thu, 12 Apr 2018 12:24:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Julien Cristau <jcristau@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Buildd Team <wb-team@buildd.debian.org>.
(Thu, 12 Apr 2018 12:24:03 GMT) (full text, mbox, link).
To: Guillem Jover <guillem@debian.org>,
Jean-Michel Vourgère <nirgal@debian.org>,
894441@bugs.debian.org, debian-wb-team@lists.debian.org,
reproducible-builds@lists.alioth.debian.org,
Ian Jackson <ijackson@chiark.greenend.org.uk>, Chris Lamb <lamby@debian.org>
Control: severity -1 wishlist
On 04/12/2018 02:10 PM, Guillem Jover wrote:
> Control: reassign -1 buildd.debian.org
>
> Hi!
>
> On Thu, 2018-04-05 at 17:43:58 +0200, Jean-Michel Vourgère wrote:
>> On Friday, 30 March 2018 15:02:31 CEST Chris Lamb wrote:
>>> [ https://lists.debian.org/debian-security/2017/05/msg00011.html ]
>>
>> On Friday, 30 March 2018 20:15:33 CEST Sven Joachim wrote:
>>> [ https://bugs.debian.org/843773 ]
>>
>> Thanks a lot guys for pointing out that issue!
>>
>> Basically, when doing bin-nmus, we really want to bump the mtime of the
>> distributed files. Not doing so results in some backups programs (rsync...) to
>> loose updates. Other programs restarting services on libraries updates
>> (needrestart...) would also be affected.
>>
>>
>> So, during compilation:
>> SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries
>> because it breaks Multi-Arch:same on bin-nmu.
>>
>> During dpkg-deb (:
>> SOURCE_DATE_EPOCH must *not* ignore bin-nmu changelog entries
>> because it would break software relying on files mtime.
>>
>> Doh!
>>
>> In https://bugs.debian.org/843773#75 Ian Jackson propose to introduce a
>> BUILD_DATE_EPOCH (= time of sbuild binnmu invocation) be prefered over
>> SOURCE_DATE_EPOCH by dpkg-deb.
>>
>> That would work, wouldn't it?
>
> Please, see my reply at <https://bugs.debian.org/843773#132>. This is
> really a fundamental problem with binNMUs+multiarch-refcounting or how
> they are being issued. :)
>
Indeed. I suspect eventually we'll make no-change sourceful uploads
less labor intensive and binNMUs will go away, but we're not there right
now.
Cheers,
Julien
Severity set to 'wishlist' from 'important'
Request was from Julien Cristau <jcristau@debian.org>
to 894441-submit@bugs.debian.org.
(Thu, 12 Apr 2018 12:24:03 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Buildd Team <wb-team@buildd.debian.org>: Bug#894441; Package buildd.debian.org.
(Thu, 12 Apr 2018 14:27:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Buildd Team <wb-team@buildd.debian.org>.
(Thu, 12 Apr 2018 14:27:04 GMT) (full text, mbox, link).
To: Guillem Jover <guillem@debian.org>, 894441@bugs.debian.org
Cc: Jean-Michel Vourgère <nirgal@debian.org>,
debian-wb-team@lists.debian.org,
reproducible-builds@lists.alioth.debian.org,
Ian Jackson <ijackson@chiark.greenend.org.uk>,
Chris Lamb <lamby@debian.org>, Julien Cristau <jcristau@debian.org>
On Thu, Apr 12, 2018 at 02:10:37PM +0200, Guillem Jover wrote:
> Please, see my reply at <https://bugs.debian.org/843773#132>. This is
> really a fundamental problem with binNMUs+multiarch-refcounting or how
> they are being issued. :)
FWIW I totally agree with what you wrote there, just that I dont see
other people agreeing so sadly I currently don't see this fixed anytime
soon. Which is pretty sad.
--
cheers,
Holger
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Buildd Team <wb-team@buildd.debian.org>: Bug#894441; Package buildd.debian.org.
(Thu, 12 Apr 2018 19:45:07 GMT) (full text, mbox, link).
Acknowledgement sent
to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Buildd Team <wb-team@buildd.debian.org>.
(Thu, 12 Apr 2018 19:45:07 GMT) (full text, mbox, link).
To: Guillem Jover <guillem@debian.org>, 894441@bugs.debian.org
Cc: Jean-Michel Vourgère <nirgal@debian.org>,
debian-wb-team@lists.debian.org,
reproducible-builds@lists.alioth.debian.org,
Ian Jackson <ijackson@chiark.greenend.org.uk>,
Chris Lamb <lamby@debian.org>, Julien Cristau <jcristau@debian.org>
control: retitle -1 "buildd.d.o: binNMUs should be replaced by easy no-change-except-d/changelog-uploads"
# I hope this is correct, realistic and accurate ;)
# if not, please fixup?
#thanks
--
cheers,
Holger
Changed Bug title to '"buildd.d.o: binNMUs should be replaced by easy no-change-except-d/changelog-uploads"' from 'dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same'.
Request was from Holger Levsen <holger@layer-acht.org>
to 894441-submit@bugs.debian.org.
(Thu, 12 Apr 2018 19:45:07 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Buildd Team <wb-team@buildd.debian.org>: Bug#894441; Package buildd.debian.org.
(Thu, 12 Apr 2018 20:12:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Emilio Pozuelo Monfort <pochu@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Buildd Team <wb-team@buildd.debian.org>.
(Thu, 12 Apr 2018 20:12:03 GMT) (full text, mbox, link).
To: Holger Levsen <holger@layer-acht.org>, Guillem Jover
<guillem@debian.org>, 894441@bugs.debian.org
Cc: Jean-Michel Vourgère <nirgal@debian.org>,
debian-wb-team@lists.debian.org,
reproducible-builds@lists.alioth.debian.org,
Ian Jackson <ijackson@chiark.greenend.org.uk>, Chris Lamb
<lamby@debian.org>, Julien Cristau <jcristau@debian.org>
On 12/04/18 21:41, Holger Levsen wrote:
> control: retitle -1 "buildd.d.o: binNMUs should be replaced by easy no-change-except-d/changelog-uploads"
> # I hope this is correct, realistic and accurate ;)
> # if not, please fixup?
> #thanks
Removing binNMUs would be a problem whenever we need to do a large amount of
rebuilds on just one architecture, e.g. due to a toolchain bug, a baseline bump,
or other reasons.
Emilio
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Buildd Team <wb-team@buildd.debian.org>: Bug#894441; Package buildd.debian.org.
(Thu, 12 Apr 2018 20:24:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Buildd Team <wb-team@buildd.debian.org>.
(Thu, 12 Apr 2018 20:24:03 GMT) (full text, mbox, link).
On Thu, Apr 12, 2018 at 10:09:44PM +0200, Emilio Pozuelo Monfort wrote:
> On 12/04/18 21:41, Holger Levsen wrote:
> > control: retitle -1 "buildd.d.o: binNMUs should be replaced by easy no-change-except-d/changelog-uploads"
> > # I hope this is correct, realistic and accurate ;)
> > # if not, please fixup?
> > #thanks
> Removing binNMUs would be a problem whenever we need to do a large amount of
> rebuilds on just one architecture, e.g. due to a toolchain bug, a baseline bump,
> or other reasons.
sure, hence the word "easy" in the bug title.
--
cheers,
Holger
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Buildd Team <wb-team@buildd.debian.org>: Bug#894441; Package buildd.debian.org.
(Thu, 12 Apr 2018 20:33:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to Debian Buildd Team <wb-team@buildd.debian.org>.
(Thu, 12 Apr 2018 20:33:03 GMT) (full text, mbox, link).
On 2018-04-12 19:41, Holger Levsen wrote:
> control: retitle -1 "buildd.d.o: binNMUs should be replaced by easy no-change-except-d/changelog-uploads"
> # I hope this is correct, realistic and accurate ;)
> # if not, please fixup?
> #thanks
That can't be done on the wanna-build side, uploads to the archive needs
to be signed. Time to reassign this bug to ftp.debian.org?
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Information forwarded
to debian-bugs-dist@lists.debian.org, Debian Buildd Team <wb-team@buildd.debian.org>: Bug#894441; Package buildd.debian.org.
(Fri, 13 Apr 2018 14:39:07 GMT) (full text, mbox, link).
Acknowledgement sent
to Philipp Kern <pkern@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Buildd Team <wb-team@buildd.debian.org>.
(Fri, 13 Apr 2018 14:39:07 GMT) (full text, mbox, link).
reassign -1 ftp.debian.org
thanks
On 2018-04-12 22:29, Aurelien Jarno wrote:
> On 2018-04-12 19:41, Holger Levsen wrote:
>> control: retitle -1 "buildd.d.o: binNMUs should be replaced by easy
>> no-change-except-d/changelog-uploads"
>> # I hope this is correct, realistic and accurate ;)
>> # if not, please fixup?
>> #thanks
> That can't be done on the wanna-build side, uploads to the archive
> needs
> to be signed. Time to reassign this bug to ftp.debian.org?
Agreed. Doing so now.
Kind regards
Philipp Kern
Bug reassigned from package 'buildd.debian.org' to 'ftp.debian.org'.
Request was from Philipp Kern <pkern@debian.org>
to control@bugs.debian.org.
(Fri, 13 Apr 2018 14:45:20 GMT) (full text, mbox, link).
Acknowledgement sent
to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian FTP Master <ftpmaster@ftp-master.debian.org>.
(Fri, 13 Apr 2018 18:03:09 GMT) (full text, mbox, link).
> On Thu, Apr 05, 2018 at 05:43:58PM +0200, Jean-Michel Vourgère wrote:
> > So, during compilation:
> > SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries
> > because it breaks Multi-Arch:same on bin-nmu.
> >
> > During dpkg-deb (:
> > SOURCE_DATE_EPOCH must *not* ignore bin-nmu changelog entries
> > because it would break software relying on files mtime.
I don't think we are as doomed as all that. I analysed this in my
message here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843773#75
That was in November 2016 and Guillem replied in January 2017 saying,
essentially, that he still disagreed with the design of multiarch, and
that binNMUs are not coinstallable.
AIUI binNMUs are now coinstallable ? And that is why
My solution is still applicable, I think. There is no change to
wanna-build needed.
There is a resulting small wrinkle that the on disk mtime of a
multi-arch shared file may the mtime of any of the source packages.
Guillem complains that it would make verification difficult, but I
think that is a soluble problem. Guillem also complains that the
mtime may flap; but that is easily avoided by having the on-disk mtime
only go forwards.
As for Guillem's complaints about the design of multiarch: these
concerns were overruled by a decision of the Technical Committee.
I don't think they are good reasons to divert from the
straightforward, if not entirely neat, course I propose.
Thanks,
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Acknowledgement sent
to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian FTP Master <ftpmaster@ftp-master.debian.org>.
(Fri, 13 Apr 2018 23:48:02 GMT) (full text, mbox, link).
On Fri, 2018-04-13 at 19:01:08 +0100, Ian Jackson wrote:
> > On Thu, Apr 05, 2018 at 05:43:58PM +0200, Jean-Michel Vourgère wrote:
> > > So, during compilation:
> > > SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries
> > > because it breaks Multi-Arch:same on bin-nmu.
> > >
> > > During dpkg-deb (:
> > > SOURCE_DATE_EPOCH must *not* ignore bin-nmu changelog entries
> > > because it would break software relying on files mtime.
>
> I don't think we are as doomed as all that. I analysed this in my
> message here:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843773#75
>
> That was in November 2016 and Guillem replied in January 2017 saying,
> essentially, that he still disagreed with the design of multiarch,
No. I think that refcounting in particular (not the entirety of
multiarch) was a misstep (even though it was me who proposed it on the
very early "design sprints"), trading apparent convenience and avoidance
of package increase for a correct and robust foundation. But as it was
also me, after having reverted the patch, the one accepting that path
forward given the rough consensus on debian-devel, I'm happy to share
the blame. I do take issue though, when people complain now that the
consequences of refcounting and binNMUs do not play well together,
because well, "I pretty much already told you so?".
> and that binNMUs are not coinstallable.
> AIUI binNMUs are now coinstallable ? And that is why
I think I might not have been explicit enough, but you might notice
there I'm talking about binNMUs with different binary versions (and
obviously same source version) not being in lockstep and not being
coinstallable. And no, they are still not coinstallable, and I'm not
planning on making them so.
> My solution is still applicable, I think. There is no change to
> wanna-build needed.
>
> There is a resulting small wrinkle that the on disk mtime of a
> multi-arch shared file may the mtime of any of the source packages.
> Guillem complains that it would make verification difficult, but I
> think that is a soluble problem. Guillem also complains that the
> mtime may flap; but that is easily avoided by having the on-disk mtime
> only go forwards.
As I also mentioned on my reply, but probably also not explictly
enough, this does not work if you install and remove current instances
and then install another instance. I'm not sure how you'd want dpkg to
track files for removed packages.
In your backup scenario, that would still trip it.
> As for Guillem's complaints about the design of multiarch: these
> concerns were overruled by a decision of the Technical Committee.
No. They were most definitely not. There's never been such ruling.
(And the only related ruling was in vain anyway…)
> I don't think they are good reasons to divert from the
> straightforward, if not entirely neat, course I propose.
That course is not a solution, I'm afraid.
Thanks,
Guillem
Changed Bug title to 'binNMUs should be replaced by easy "no-change-except-debian/changelog-uploads"' from '"buildd.d.o: binNMUs should be replaced by easy no-change-except-d/changelog-uploads"'.
Request was from Chris Lamb <lamby@debian.org>
to control@bugs.debian.org.
(Sun, 15 Apr 2018 08:00:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian FTP Master <ftpmaster@ftp-master.debian.org>.
(Sun, 15 Apr 2018 15:03:03 GMT) (full text, mbox, link).
Guillem Jover writes ("Re: Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same"):
> On Fri, 2018-04-13 at 19:01:08 +0100, Ian Jackson wrote:
> > AIUI binNMUs are now coinstallable ? And that is why
>
> I think I might not have been explicit enough, but you might notice
> there I'm talking about binNMUs with different binary versions (and
> obviously same source version) not being in lockstep and not being
> coinstallable. And no, they are still not coinstallable, and I'm not
> planning on making them so.
Ah. Well, OK. From my POV I am mainly trying to solve, here, the
"wrong timestamp breaks backups" problem. If binNMUs are not
coinstallable then that's out of scope right now although IMO we
shouldn't do something now that would make it harder. I think my
proposal does not make that harder.
> > My solution is still applicable, I think. There is no change to
> > wanna-build needed.
> >
> > There is a resulting small wrinkle that the on disk mtime of a
> > multi-arch shared file may the mtime of any of the source packages.
> > Guillem complains that it would make verification difficult, but I
> > think that is a soluble problem. Guillem also complains that the
> > mtime may flap; but that is easily avoided by having the on-disk mtime
> > only go forwards.
>
> As I also mentioned on my reply, but probably also not explictly
> enough, this does not work if you install and remove current instances
> and then install another instance. I'm not sure how you'd want dpkg to
> track files for removed packages.
>
> In your backup scenario, that would still trip it.
I don't expect dpkg to track files for removed packages.
My scheme does not always manage to avoid unnecessary backing-up of
files which actually contain identical contents. But I don't think
that is a necessary design goal.
It would be good to avoid unnecessary backing-up where possible and I
think my scheme does it in many such cases. It does indeed miss some
cases involving removal and reinstallation of a particular .deb. I
don't think that matters very much.
I think that my proposal will always result in a file being backed up
when needed, if the backup arrangements are correct.
When I said "the on-disk mtime only go forwards" I meant in the usual
case where packges are upgraded rather than downgraded. I still want
the on-disk mtime to be one of the mtimes of the .debs which contained
this version of the file.
And this rule is only there to avoid the mtime flapping as a result of
a series of single-arch binNMUs which you now say cannot occur...
Ian.
Added indication that bug 894441 blocks 900837
Request was from Holger Levsen <holger@layer-acht.org>
to 900837-submit@bugs.debian.org.
(Tue, 05 Mar 2019 13:45:03 GMT) (full text, mbox, link).
Severity set to 'normal' from 'wishlist'
Request was from Luca Falavigna <dktrkranz@debian.org>
to control@bugs.debian.org.
(Sun, 11 Sep 2022 12:39:15 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.