[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#913229: marked as done (release.debian.org: RC status of merged-/usr bugs?)

Your message dated Wed, 21 Nov 2018 08:37:00 +0000
with message-id <a67c8d49-c042-1cb9-2c4d-64ed0e25e0bd@thykier.net>
and subject line Re: Bug#913229: release.debian.org: RC status of merged-/usr bugs?
has caused the Debian Bug report #913229,
regarding release.debian.org: RC status of merged-/usr bugs?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
913229: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913229
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
User: md@linux.it
Usertags: usrmerge

debootstrap in >= buster produces merged-/usr chroots for buster and sid
by default. Some packages are misbuilt in such chroots: the only concrete
example I have that is currently open is <https://bugs.debian.org/913226>
in quilt, in which a package built in a merged-/usr environment will
work on merged-/usr systems but won't work (at all) on a non-merged-/usr
system.

There are almost certainly others; most of them are probably similar to
the quilt bug, where the absolute path to an executable on the build
system ends up in the package, but to support non-merged-/usr systems
we need to canonicalize that path to the version that would work on the
non-merged-/usr systems. For instance, src:systemd used to have a similar
bug <https://bugs.debian.org/843433>.

I've opened sbuild-createchroot bug <https://bugs.debian.org/913228>
suggesting that it should create non-merged-/usr chroots to sidestep
this for buildd builds, but there are many other ways for maintainers
and testers to build binaries.

If binary packages in the archive don't work on a non-merged-/usr system,
is that a RC bug in the binary packages? For instance, if an uploader
of quilt uploaded binaries that had been built on a merged-/usr system
without first fixing #913228, would that be RC? (I'm assuming the answer
is yes; certainly systemd's #843433 was treated as RC.)

Are bugs like #843433 and #913226, in which a package built in a
merged-/usr environment won't work in a non-merged-/usr environment,
considered to be RC bugs in the *source package* even if the binaries
in the archive happen to be OK?

See also <https://bugs.debian.org/901473> which proposes that
reproducible.debian.org should exercise merged vs. non-merged /usr,
as a way to detect this class of bug.

    smcv

--- End Message ---
--- Begin Message --- 
Simon McVittie:
> [...]
> 
> Well, there's a middle ground, which I think would be a good short
> term plan: we can ensure that the official buildds build packages in a
> non-merged-/usr environment (for example by backporting a fix for #913228
> to the packages used on those buildds), which means misbuilt binary
> packages uploaded by maintainers remain potentially RC (as systemd's
> #843433 was), but source packages that would theoretically be misbuilt
> in a merged-/usr environment (like quilt #913226) don't necessarily have
> to be treated as RC.
> 
> I've sent a proposed patch to #913228.
> 
>     smcv
> 

Hi,

Thanks for clarifying.

I think Simon's proposal as quoted above is a good resolution for this
question (scoped for the buster release).  It is also aligned with other
parts of Debian working on resetting the buildds to use non-/usr merged
chroots.

If there are any objections or clarification points to this, please
follow up and we will reconsider the decision.

Thanks,
~Niels

Attachment: signature.asc
Description: OpenPGP digital signature


--- End Message ---
Reply to: