Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1154400 > unrolled thread

Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE Adam Borowski <kilobyte@angband.pl> - 2023-07-15 18:40 +0200
    Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE Timo Röhling <roehling@debian.org> - 2023-07-16 00:40 +0200
    Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE Simon McVittie <smcv@debian.org> - 2023-07-16 13:40 +0200
      Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE Vagrant Cascadian <vagrant@reproducible-builds.org> - 2023-07-16 16:40 +0200
    Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE Simon McVittie <smcv@debian.org> - 2023-07-16 13:50 +0200
    Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE Simon McVittie <smcv@debian.org> - 2023-07-16 14:00 +0200
      Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE Luca Boccassi <bluca@debian.org> - 2023-07-16 14:30 +0200
    Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE Jonathan Carter <jcc@debian.org> - 2023-07-17 12:40 +0200

#1154400 — Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE

Package: debootstrap
Version: 1.0.128+nmu3
Severity: grave

bluca's NMU on 2023-07-15 makes debootstrap produce chroots using the
aliased-dirs scheme.  While it's currently the default scheme for non-buildd
systems, it is both not supported by dpkg (with no solution in sight), but
is also likely to produce packages that are explicitely forbidden by a
recent CTTE ruling that disallows moving files between directories aliased
by the current usrmerge scheme.

Quoting the still unsolving issues is pointless (you can read about them
in massive threads in a number of places) as bluca seems to be ignoring
them completely.

But, what matters here is the CTTE ruling in #1035831 -- for the time being,
packages must not move files between locations affected by the aliasing.

Packages built in an usrmerged chroot place such files under /usr while
built without usrmerge into whatever place they were installed to -- which
is a direct breach of the ruling.

Thus, that change needs to be reverted for now, and all packages built
with 1.0.128+nmu3 need to be either rebuilt or at least checked for such
a violation (as most are unaffected).


Meow!
-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-rc1-00036-gc493f11e457d (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages debootstrap depends on:
ii  wget  1.21.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test               0.21-1
ii  debian-archive-keyring  2023.3
ii  gnupg                   2.2.40-1.1

Versions of packages debootstrap suggests:
ii  binutils                                 2.40.90.20230705-1
pn  squid-deb-proxy-client                   <none>
ii  ubuntu-archive-keyring                   2020.06.17.1-1
ii  ubuntu-keyring [ubuntu-archive-keyring]  2020.06.17.1-1
ii  xz-utils                                 5.4.1-0.2
ii  zstd                                     1.5.5+dfsg2-1

-- no debconf information

[toc] | [next] | [standalone]

#1154442

[Multipart message — attachments visible in raw view] — view raw

Hi Adam,

On Sat, 15 Jul 2023 18:27:24 +0200 Adam Borowski <kilobyte@angband.pl> wrote:
> Packages built in an usrmerged chroot place such files under /usr while
> built without usrmerge into whatever place they were installed to -- which
> is a direct breach of the ruling.
Packages stage their files in debian/tmp or debian/PACKAGE, not in /
of the builder chroot, so the usr-merge state of the chroot has no
effect on the package file locations.


Cheers
Timo

-- 
⢀⣴⠾⠻⢶⣦⠀   ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling                                       │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀   ╰────────────────────────────────────────────────────╯

[toc] | [prev] | [next] | [standalone]

#1154479

On Sat, 15 Jul 2023 at 18:27:24 +0200, Adam Borowski wrote:
> But, what matters here is the CTTE ruling in #1035831 -- for the time being,
> packages must not move files between locations affected by the aliasing.

If that happens in reality, then yes, that's bad, and reverting the change
is a mitigation. What packages have this behaviour?

We are going to need to bring back this change relatively early in the
trixie cycle in any case, for the reasons given in the commit message.
I have not yet analyzed whether we need this change before we can lift
the moratorium on file moves, but I suspect we might.

> Packages built in an usrmerged chroot place such files under /usr while
> built without usrmerge into whatever place they were installed to -- which
> is a direct breach of the ruling.

Do you have examples of packages that differ in this way when built in
a merged- or unmerged-/usr environment? I think we should treat this
as a RC-for-trixie bug in those packages (and in fact I would have been
tempted to call it RC for bookworm as well, again for the reasons given
by the TC, even though during the trixie cycle it was mitigated by using
unmerged-/usr fro buildds).

During most of the bookworm cycle, https://reproducible-builds.org/ has
been doing "build1" in unmerged-/usr and "build2" in merged-/usr, with
differences tracked in
<https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html>
(that list is not necessarily complete, there can also be unidentified
differences in
<https://tests.reproducible-builds.org/debian/unstable/amd64/index_no_notes.html>).

I did some bug-reporting for this during the bookworm cycle and I don't
remember reporting any bugs where a package changed whether it installed
/bin/foo or /usr/bin/foo (or sbin or lib* equivalents) according to
whether it was built in a merged-/usr chroot or not: the bugs I was
reporting were generally about file contents, not the file list.

Most of the remaining merged- vs. unmerged-/usr differences
have been packages that install an Autotools-generated
Makefile into /usr/share/doc/PACKAGE/examples, like for example
<https://bugs.debian.org/1021860> which says "EGREP = /bin/grep -E"
when built in an unmerged-/usr chroot, but /usr/bin/grep in a merged-/usr
chroot. That's annoying but not really a serious issue, because it's only
an example file, and in my opinion should not be RC (but I would consider
it potentially RC if the path was in a functionally-necessary file).

If a package installs in the typical multiple-binary-package way:

    - make
    - make install DESTDIR=$(pwd)/debian/tmp
    - dh_install splits up debian/tmp using debian/*.install
    - dh_builddeb

then a mismatch between the expected /bin/foo and a new /usr/bin/foo
will generally cause FTBFS rather than a misbuilt package, because
dh_install will fail to find /bin/foo. So I think the highest risks
for this failure mode are going to be packages that use the simplified
single-binary-package code path:

    - make
    - make install DESTDIR=$(pwd)/debian/my-package
    - dh_builddeb

and packages that do not use debhelper in the conventional way.

    smcv

[toc] | [prev] | [next] | [standalone]

#1154501

[Multipart message — attachments visible in raw view] — view raw

On 2023-07-16, Simon McVittie wrote:
> On Sat, 15 Jul 2023 at 18:27:24 +0200, Adam Borowski wrote:
>> But, what matters here is the CTTE ruling in #1035831 -- for the time being,
>> packages must not move files between locations affected by the aliasing.
>
> If that happens in reality, then yes, that's bad, and reverting the change
> is a mitigation. What packages have this behaviour?
>
> We are going to need to bring back this change relatively early in the
> trixie cycle in any case, for the reasons given in the commit message.
> I have not yet analyzed whether we need this change before we can lift
> the moratorium on file moves, but I suspect we might.
>
>> Packages built in an usrmerged chroot place such files under /usr while
>> built without usrmerge into whatever place they were installed to -- which
>> is a direct breach of the ruling.
>
> Do you have examples of packages that differ in this way when built in
> a merged- or unmerged-/usr environment? I think we should treat this
> as a RC-for-trixie bug in those packages (and in fact I would have been
> tempted to call it RC for bookworm as well, again for the reasons given
> by the TC, even though during the trixie cycle it was mitigated by using
> unmerged-/usr fro buildds).
>
> During most of the bookworm cycle, https://reproducible-builds.org/ has
> been doing "build1" in unmerged-/usr and "build2" in merged-/usr, with
> differences tracked in
> <https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html>
> (that list is not necessarily complete, there can also be unidentified
> differences in
> <https://tests.reproducible-builds.org/debian/unstable/amd64/index_no_notes.html>).

For what it is worth, there were various points during the bookworm
cycle where this was not being tested on reproducible builds
infrastructure, as the mechanisms to disable it changed several
times...

We used to just be able to build a non-usrmerge tarball, and then
install usrmerge in the second build, but I think usr-is-merged or some
similar package is installed out of the box now, and the inverse
operation is non-trivial.

... which lead to some of the identified issues being systematically
removed for packages that were otherwise reproducible (you could still
look through git history to find more, but some many may be actually
fixed).

There are differing opinions on weather reproducible builds test
infrastrure should test usrmerge variations at all, given the direction
of Debian, though any alternate test infrastructure would essentially
have to implement a reproducible builds style test to check for
differences...

After upgrading the infrastructure to bookworm, testing usrmerge
variations broke again, and so is currently disabled... though I have
configured the paths_vary_due_to_usrmerge issue so that old known issues
are not automatically removed anymore.


live well,
  vagrant

[toc] | [prev] | [next] | [standalone]

#1154480

On Sat, 15 Jul 2023 at 18:27:24 +0200, Adam Borowski wrote:
> bluca's NMU on 2023-07-15 makes debootstrap produce chroots using the
> aliased-dirs scheme.

My intention in the MR that was included in the NMU[1] was to default to
merged-/usr chroots in all cases for trixie and up, but continue to
produce unmerged-/usr chroots for bookworm. When I tested the MR, that's
the result I got[2]. Have you observed something different?

There was consensus among the TC[3] that this change was appropriate for
trixie/sid at this time.

To the best of my knowledge, the official Debian buildds run on stable
(possibly oldstable in some cases) and use debootstrap from there, so any
changes here would not affect official buildds until/unless they are
backported into (old)stable point releases via -proposed-updates.

    smcv

[1] https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/93
[2] https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/93#note_410656
[3] http://meetbot.debian.net/debian-ctte/2023/debian-ctte.2023-07-11-17.58.log.html
    18:39 to 18:50 in the timestamps' time zone

[toc] | [prev] | [next] | [standalone]

#1154481

On Sun, 16 Jul 2023 at 12:42:11 +0100, Luca Boccassi wrote:
> In the meanwhile, I'll immediately revert the sabotage.

Both of you, please don't turn this into an NMU war in the archive:
that doesn't benefit anyone. I would have preferred it if Adam had not
immediately uploaded a 0-day revert, but preserving the status quo from
bookworm is not the worst state to be in while we discuss this.

If Adam's concerns about this change are valid, then we should address
them, either by doing something different in debootstrap or by reporting
bugs against affected packages.

If Adam's concerns about this change turn out to be unfounded, then we
should reinstate my change (as NMU'd by Luca) in a calm and considered
way, and all we will have lost is a few days of progress and a few bytes
of changelog.

    smcv
    (speaking as an individual developer, not on behalf of the TC, but I
    hope this would be TC consensus if we had had a chance to discuss it)

[toc] | [prev] | [next] | [standalone]

#1154484

[Multipart message — attachments visible in raw view] — view raw

On Sun, 16 Jul 2023 12:54:35 +0100 Simon McVittie <smcv@debian.org>
wrote:
> On Sun, 16 Jul 2023 at 12:42:11 +0100, Luca Boccassi wrote:
> > In the meanwhile, I'll immediately revert the sabotage.
> 
> Both of you, please don't turn this into an NMU war in the archive:
> that doesn't benefit anyone. I would have preferred it if Adam had
not
> immediately uploaded a 0-day revert, but preserving the status quo
from
> bookworm is not the worst state to be in while we discuss this.
> 
> If Adam's concerns about this change are valid, then we should
address
> them, either by doing something different in debootstrap or by
reporting
> bugs against affected packages.
> 
> If Adam's concerns about this change turn out to be unfounded, then
we
> should reinstate my change (as NMU'd by Luca) in a calm and
considered
> way, and all we will have lost is a few days of progress and a few
bytes
> of changelog.

I have already reverted the hostile and unwarranted NMU before you
replied. And that is the right thing to do: the correct procedure when
there is a suspicion that a change breaks something is not to do a 0-
day revert without telling anybody, it's to file a bug _AND_ CC the
involved people, and wait until there is an answer, while providing
evidence of the actual issue.

As you already correctly noted, there is zero evidence of any issue
presented in this bug, and the stated 'reason' is wrong anyway:
debootstrap from unstable/testing is NOT used to build packages for
unstable/testing. This would have been trivial to find out for the
reporter.

So as with normal procedure, the change will stand where it is, and if
there is evidence of any actual issues it can be revisited later.
Blocking other people's progress with work that has the consensus of
both the project and the CTTE and force them to spend days or weeks or
months proving negatives is not an acceptable procedure.

-- 
Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#1154592

I want to echo what Simon said, please don't partake in commit 
ping-pong, it is unbecoming of a Debian Developer, and not the correct 
course of action if you disagree with something. It also reflects poorly 
on the project, so please refrain from doing so, even if you don't agree 
with how decisions are made.

-Jonathan

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web