Hi,

the transition to usrmerge as described in [1] is planned to start
around 2022-09-15 (next Thursday).

init-system-helpers 1.65~exp1 in experimental adds the new dependency on "usrmerge | usr-is-merged" and will be uploaded to unstable to start the transition. Feel free to test and report any issues.

Recent versions of debootstrap[2] will setup the usr-is-merged package to
avoid installing additional dependencies required by usrmerge. The usr-is-merged package can also be manually installed in existing systems
for the same reason.

Debian's buildds will continue to use the legacy filesystem layout for
Debian 12 (bookworm).

We will send an announcement to debian-devel-announce@ once the upload
to unstable happens.

Ansgar

[1]: https://lists.debian.org/debian-ctte/2022/09/msg00005.html
[2]: debootstrap 1.0.114+deb10u1, 1.0.123+deb11u1, 1.0.127

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Ansgar <ansgar@debian.org> [220910 09:37]:

the transition to usrmerge as described in [1] is planned to start
around 2022-09-15 (next Thursday).

[snip]

We will send an announcement to debian-devel-announce@ once the upload
to unstable happens.

What is the point in waiting until after the upload to send to debian-devel-announce? I would think that most users running
testing/unstable would want prior notice, and you shouldn't assume that
all users will read their mail before performing a routine
update/upgrade cycle on the morning after the upload. I don't think
everyone running testing/unstable reads debian-devel, so I think it
would be appropriate to send to -announce at least one (two?) day(s)
before the upload.

...Marvin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 11 Sep 2022 11:08:44 -0400, Marvin Renich <mrvn@renich.org>
wrote:

* Ansgar <ansgar@debian.org> [220910 09:37]:

the transition to usrmerge as described in [1] is planned to start
around 2022-09-15 (next Thursday).

[snip]

We will send an announcement to debian-devel-announce@ once the upload
to unstable happens.

What is the point in waiting until after the upload to send to >debian-devel-announce? I would think that most users running >testing/unstable would want prior notice, and you shouldn't assume that
all users will read their mail before performing a routine
update/upgrade cycle on the morning after the upload. I don't think
everyone running testing/unstable reads debian-devel, so I think it
would be appropriate to send to -announce at least one (two?) day(s)
before the upload.

And, is there a solution for the existing conflict with the dpkg
maintainer?

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 12 Sept 2022 at 07:35, Marc Haber <mh+debian-devel@zugschlus.de> wrote:

On Sun, 11 Sep 2022 11:08:44 -0400, Marvin Renich <mrvn@renich.org>
wrote:

* Ansgar <ansgar@debian.org> [220910 09:37]:

the transition to usrmerge as described in [1] is planned to start
around 2022-09-15 (next Thursday).

[snip]

We will send an announcement to debian-devel-announce@ once the upload
to unstable happens.

What is the point in waiting until after the upload to send to >debian-devel-announce? I would think that most users running >testing/unstable would want prior notice, and you shouldn't assume that
all users will read their mail before performing a routine
update/upgrade cycle on the morning after the upload. I don't think >everyone running testing/unstable reads debian-devel, so I think it
would be appropriate to send to -announce at least one (two?) day(s)
before the upload.

It will take a few days for the updated package to migrate to testing.
If you are running unstable - well, it's unstable ;-) There are no
user actions required anyway.

And, is there a solution for the existing conflict with the dpkg
maintainer?

Please see the linked tech-ctte email thread linked and the mails it quotes:

https://lists.debian.org/debian-ctte/2022/09/msg00005.html

Kind regards,
Luca Boccassi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 2022-09-10 at 15:37 +0200, Ansgar wrote:

Hi,

the transition to usrmerge as described in [1] is planned to start
around 2022-09-15 (next Thursday).

init-system-helpers 1.65~exp1 in experimental adds the new dependency
on
"usrmerge | usr-is-merged" and will be uploaded to unstable to start
the
transition. Feel free to test and report any issues.

Recent versions of debootstrap[2] will setup the usr-is-merged
package to
avoid installing additional dependencies required by usrmerge. The usr-is-merged package can also be manually installed in existing
systems
for the same reason.

Debian's buildds will continue to use the legacy filesystem layout
for
Debian 12 (bookworm).

We will send an announcement to debian-devel-announce@ once the
upload
to unstable happens.

Ansgar

  [1]: https://lists.debian.org/debian-ctte/2022/09/msg00005.html
  [2]: debootstrap 1.0.114+deb10u1, 1.0.123+deb11u1, 1.0.127

Quick update: three minor issues where found, two with i-s-h itself
(one solved in experimental just now about test deps uninstallability
on some ports and one piuparts seemingly false positive about
/etc/shells that I'll fix tomorrow), and one in usrmerge+nspawn+arm64
[0]. I have just come back home from LPC so did not have much time
today, will have a look at the latter two tomorrow and then upload to
unstable once the situation is clearer.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019575

--
Kind regards,
Luca Boccassi

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmMjn+EACgkQKGv37813 JB7Z5xAAlipBf7YhJowiKeLOpG61/kBWiN/TkVAWBqpG036i6q6RqZfa3w6bavVr U0d5jKfYVi/1OOdpyOUArmhmudZXKUm17RsThqn8ihzfgODvmDBdJLzdJ2CkVckK U543XWXnPIMC5cMB6IcChMyuxYpMud3fxtM1BFNllSrX5a6Srdeg4HXEZ80DrWPn MIg8W2Rbz93y+one4SCgYRdBPu0aMzvwX5bQvDLybzo5OPZeaHmzbjRXYB8tEgan ZKI0gRlyLY444yLAOlWZCaJEYSY7ascFLGkIGoeba2g6FM/ehfCrEgj3ZOufDx1V IyfIzS91/fCBerCOYHvQWOKefrXKh5rfCGMSY5mp4hPh72mjo64UIoYVCvBKeEXc AAkvXoypTt0xPvjPghGlSghhyYQ2qvCYfas0CE3C/DDFfrmOOpMMv5lN1xPmMW7x BYbw1Az9xwGuVeFLcAav7AF5jASh41s+EUfkrAjpOPAnMn6F0gP2SWcOHrXdmirB CvpyEoRKkfSZZ9e2WG2LXb/PrEf0+GAgPfnEM8i0sUp8NJe2giyFkEvw130i4Gnw 4nOYy3KjUe00Bz6xzS7jyYGiWguHUNi/Y45M7NxamHq16tcZYcaluYyB3gfp0iRO 8REsYhNSjUQAMXs5/6ITlupdimqi/3e4GyhUqZE0T+Y0AS8GFLo=
=dy7r
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Sep 15, 2022 at 10:57:52PM +0100, Luca Boccassi wrote:

On Sat, 2022-09-10 at 15:37 +0200, Ansgar wrote:

the transition to usrmerge as described in [1] is planned to start
around 2022-09-15 (next Thursday).

I have just come back home from LPC so did not have much time
today, will have a look at the latter two tomorrow and then upload to unstable once the situation is clearer.

... unstable of what distribution?

I seriously hope you're not talking about Debian.


Have you fixed the issues listed, as discussed on IRC? Implemented at least the configurable list of aliases compromise, as agreed?

If not, the only transition that can work is one to a scheme supported
by dpkg, which usrmerge is not.


Meow.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the
⠈⠳⣄⠀⠀⠀⠀ sky. Your cat demands food. The priority should be obvious...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 2022-09-15 at 22:57 +0100, Luca Boccassi wrote:

On Sat, 2022-09-10 at 15:37 +0200, Ansgar wrote:

Hi,

the transition to usrmerge as described in [1] is planned to start
around 2022-09-15 (next Thursday).

init-system-helpers 1.65~exp1 in experimental adds the new dependency
on
"usrmerge | usr-is-merged" and will be uploaded to unstable to start
the
transition. Feel free to test and report any issues.

Recent versions of debootstrap[2] will setup the usr-is-merged
package to
avoid installing additional dependencies required by usrmerge. The usr-is-merged package can also be manually installed in existing
systems
for the same reason.

Debian's buildds will continue to use the legacy filesystem layout
for
Debian 12 (bookworm).

We will send an announcement to debian-devel-announce@ once the
upload
to unstable happens.

Ansgar

  [1]: https://lists.debian.org/debian-ctte/2022/09/msg00005.html
  [2]: debootstrap 1.0.114+deb10u1, 1.0.123+deb11u1, 1.0.127

Quick update: three minor issues where found, two with i-s-h itself
(one solved in experimental just now about test deps uninstallability
on some ports and one piuparts seemingly false positive about
/etc/shells that I'll fix tomorrow), and one in usrmerge+nspawn+arm64
[0]. I have just come back home from LPC so did not have much time
today, will have a look at the latter two tomorrow and then upload to unstable once the situation is clearer.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019575

All 3 issues are solved or pending:

1) init-system-helpers build issue on some ports architectures has been
fixed (new test dependency fakeroot is not available everywhere, made
optional)

2) salsa CI issue with piuparts job image not being built by debootstrap/mmdebstrap and thus not installing usrmerge/usr-is-merged,
causing a false positive when usrmerge is pulled in by the package-
under-test thus falsely attributing the /etc/shells change to it, fixed
by installing usrmerge in the pre-built image, MR pending: https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/372

3) systemd-nspawn on aarch64 merged systems creates a /lib64 -> /usr/lib/aarch64-linux-gnu symlink which is not created by debootstrap/mmdebstrap, so the usr-is-merged preinst check doesn't
expect it and erroneously fails. Fixed with NMU to just enforce that
the arch-specific libdirs are symlinks to /usr/lib* instead of exactly
the same dirname under /usr, as this is not the right place to care
about that detail, the only important thing in this context is the
target being under /usr.

Unless any new issue pops up, I'll upload i-s-h to unstable to start
the transition tomorrow evening.

--
Kind regards,
Luca Boccassi

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmMlI0UACgkQKGv37813 JB5O1g/9FXdn236urj5HwiAdFrIs7DFBJyH8GXh94/XusfOdyn1XuD6fHPL9Tsjm 92TdSX4iOkf6NAGAHK9p6c2/O5MxLPrZwKUX8aePIoIitAnbXnX3Un8PMHHzwK+B VzPNbNAsk6IsqLzaiyd9cf8Q4Y8cLqvtXMAp9GZ+iFsr9iJSsaRAxmNVjkG+BYmx NmJrIZkF8xepd/5oFoLSGet7MpdOuWHyiSqTAMhnAYUw1VbbkWv0QdTd06aFkGWU 9KqwYEnhGjNSRmd3GiFyNidQh5POpCi33Xosg+n+GgJdayKUnCx1DALQgUrTb1I+ neHD8GlKfRFa/KZgF0QrmxKNqoTVfThPjAhVTCdkV2dpMszi3Tsse/GEC4zzF0UW d1UKMlYWMDxxgunr7vAi7e4sPUZnGf6wbX3IfTgmTjDVhPHjOU1d/MvSfdM9J7Ea 09/aALR9/s1TWX9fWFNP/IGDfqrWgz93UQ78vmKM6uun1B61zmd8ts/KRnjNc6Q4 wWB8H2eRymSssygWNxCSbzEjdp+ySWcj4an8KVrNoSnSKxe6eB04TGYIut7Ws1VL Gqf6olKYbxrtI4RHTuQTPCQOjiO0f8kGxaN0ckzCp6ggQEAUISEIfFo7A44g3znS pTEWiS5c+ZzjIQy8+yp3ID+IhAp9sVMgcpdLKF0ZKNWgoOMK3iM=
=rSHw
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Sep 17, 2022 at 02:30:45AM +0100, Luca Boccassi wrote:

Unless any new issue pops up, I'll upload i-s-h to unstable to start
the transition tomorrow evening.

... and you ignored anything you don't like, and uploaded ANYWAY.

Despite even the GR talk, which you folks _explicitely requested_.

Not amussed.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀ -- <willmore> on #linux-sunxi
⠈⠳⣄⠀⠀⠀⠀

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2022-09-18 at 03:46 +0200, Adam Borowski wrote:

On Sat, Sep 17, 2022 at 02:30:45AM +0100, Luca Boccassi wrote:

Unless any new issue pops up, I'll upload i-s-h to unstable to
start
the transition tomorrow evening.

... and you ignored anything you don't like, and uploaded ANYWAY.

Despite even the GR talk, which you folks _explicitely requested_.

Not amussed.

Nothing was ignored. I have no idea what you mean by "you folks", but I certainly did not request nor talk about any GR, and it was never
mentioned in any of the long threads on the subject in the past few
months. The agreed plan was executed exactly as discussed and
communicated in the past ~3 months, as demonstrated plainly and openly
by the links contained in the mail to d-d-announce, and it will go
ahead as decided.

--
Kind regards,
Luca Boccassi

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmMmgKAACgkQKGv37813 JB6z1xAAmK7/w7VE0IZwrdTjB2iSw0SPhC1nB9Qn8gLAWDz6Jjn+Je501XJ3gQg2 LysmweNh3Oxus2tIsuE6p5nYY2/2H8M7yPxk4n0tdGUOgdA7d3hK1xxzoNE/s+kp YVpWKGCtZXkxFhoLvp2GWcr6imi9ieLbCPqVfP0kBKzI/vTyfCD54kx562opPEkn ZK0TvrhWvGn+Tgn53whsfKtel1BYUdOPSqwyHgx7aj4gKU1mQOp5o+52WZO0bm/W LesiYlJd/voy+mO5splmtVxqfGWbz1SdbQd9+jd2/bmzr4u+KJosJv/gOAllYUkJ QXa32OQ6mH3XPWOgsiPU031z3aqoxiFR3aI7GI4pAguoh+HXrCJ1GPpOJytGi0Xq rrEZODkC/3sRYwo/o6NNuRCv318sEfnavJKZgTTFjOftl1ZJLXfNjOrl3f3mbVLS XvjFKUPkINKkgbHTS30lmj8QwdnMf4LVga3ut1Sz71T0qsESVAk/ZHJZXdoBc8R2 32y0140DALBnVexcZBGMzCWE4JobbQKlsKLB/zvjxYQxgwk1emQrvLwaCWWq3evj 05fAQ8vOXgVmbsj82WHuocOglLbfSSbQBaNA0he3xQLsFg+RzGaVq5i3OpxV5sza tVszCU0ceqQ//cEn8GC1j4k9gRJ/t6fT7RFtYDK6EQ0Zkg30rUc=
=saBS
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Luca Boccassi <bluca@debian.org> writes:

Nothing was ignored.

In the spirit of good faith I'll assume you meant "Nothing new was
ignored".

It's a fact that you are ignoring a few issues caused by usrmerge. This
is thoroughly documented in the BTS.

Arrogance is not on the bug list, but maybe it should be? It's
definitely something Debian will have to work on before releasing with
usrmerge in the current state.

usrmerge adds bugs which you so far have been unable to fix. That's
nothing to be ashamed of. Just try to be honest about it.

I assume that you plan to fix the bugs before the release. Note that the
CTTE did not request the addition of any bugs, or make any exceptions
for the usrmerge package. What to do about usrmerge if it conflicts
with other goals is not decided yet.

So if you don't want another round of pointless discussions, then I
suggest that you start working on those bugs now. That's the smart thing
to do if you want to make *sure* usrmerge is part of the release. If
there is no conflict between release goals, then there will be no need
for a discussion.

I find it quite disappointing to read https://bugs.debian.org/848622 . I
don't know if it is arrogance or ignorance, but this bug is undoubtedly
caused by usrmerge:

frtest2:~# ls -l /usr/bin/bash
-rwxr-xr-x 1 root root 1283864 Aug 25 16:03 /usr/bin/bash
frtest2:~# dpkg -S /usr/bin/bash
dpkg-query: no path found matching pattern /usr/bin/bash

Pointing at other maintainers/packages to fix your bugs is anti-social.

Don't force Debian decide whether the usrmerge bugs should be accepted
in the next release. Just fix them. The alternative is ugly. And I'm
not thinking about the actual bugs, but about the discussion...

It's fine to oversell the advantages of usrmerge. It's not fine to try
to hide the disadvantages.


Bjørn

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Sep 18, 2022 at 11:16:22AM +0200, Bjørn Mork wrote:

I find it quite disappointing to read https://bugs.debian.org/848622 . I don't know if it is arrogance or ignorance, but this bug is undoubtedly caused by usrmerge:

frtest2:~# ls -l /usr/bin/bash
-rwxr-xr-x 1 root root 1283864 Aug 25 16:03 /usr/bin/bash
frtest2:~# dpkg -S /usr/bin/bash
dpkg-query: no path found matching pattern /usr/bin/bash

`dpkg -S` not knowing about files installed by packages is nothing new.
This was always how it worked and it was never reliable to answer "which package installed this file/which package is responsible for this file", usrmerge just added one more case where it fails.
#134758, linked in the bug you linked, indeed covers a part of this
general problem.

Pointing at other maintainers/packages to fix your bugs is anti-social.

"your bugs"

Don't force Debian decide whether the usrmerge bugs should be accepted
in the next release. Just fix them. The alternative is ugly. And I'm
not thinking about the actual bugs, but about the discussion...

"usrmerge bugs"

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmMm5eEtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh EHEQAIRI+kOBTiatglV1TD/Z9c+1r77p+ilq6piAZsTCF5JBmAS5QYjPLkaGF1pS GzChMJ20snMD5XG9EyPAq32EGilRTCtQxkVHVruD3yOlqqqZbLLcS4863vXoeeQ1 QNT+ROaRGcGmEOsne0CPtxjnnWEnV+AveYJxnmAURqO/WavmtT+T+DmWK60/nWui tjnuPwi1BMs15FGTCNTTygQEQW6pXI+iypiNp3S5gE3qY62Lmmsx4IE9jJ21reXG ssmCvnHyxBG78fRbuVgSHMtZyQOuqoHZo2+2HNgeViYkKexoS/6RvtiFHUdDNWaw gx7pvVLWtMp2CHAyAtcl/F3hBxtZiWAlHH+TF25KFLCZxF1KvMlrA8tbPznY0Mvc bTzry6tI8WYkgQy6kfDueFxnwqyU1/Rb6/6pSPRxKSJXEeqj/mcP8LNrCAW5+2Qp ZQ02iO73e+NjGTlIN6jcGP3Ykx8MCZRQ6U1sg3aqNi6wZKm2Pe/dDo5/KioX+N9X a2khhqA6seW29CVKDN3bvBa0u4VCSsnsH+PFolWYxUrlkSTHZipc9wgG7hCA30Gf D8BB8xbsjPINkdvuH7yjG8ye+0W7MApMVcIvxcNWlyZ+kPucFEp2TW5CtxN/AdHg HvlnaPV0I40N6r+edu2SPuVYg7z74zo59HI/7pYRsX+bXc5r
=WcXR
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sep 18, Bjørn Mork <bjorn@mork.no> wrote:

So if you don't want another round of pointless discussions, then I
suggest that you start working on those bugs now. That's the smart thing

In other words, you are saying that if we don't do what you want then
you will keep rehashing the same old arguments.
This looks like extortion to me.

to do if you want to make *sure* usrmerge is part of the release. If
there is no conflict between release goals, then there will be no need
for a discussion.

"That's a nice feature you have there, it would be a shame if something happened to it..."

I find it quite disappointing to read https://bugs.debian.org/848622 . I don't know if it is arrogance or ignorance, but this bug is undoubtedly caused by usrmerge:

And our position is that it needs to be fixed in dpkg.

--
ciao,
Marco

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCYybobwAKCRDLPsM64d7X geS6AQCrvgovKOw+1R2dI1q0M97v3RLTBGJq20mpYYcN6xk5mwD/biakb8+kq1Nt cY0RXdJClCLt173qsv+lbAIP4O+qbAo=
=xWK9
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-09-10 15:37 +0200, Ansgar wrote:

the transition to usrmerge as described in [1] is planned to start
around 2022-09-15 (next Thursday).

init-system-helpers 1.65~exp1 in experimental adds the new dependency on "usrmerge | usr-is-merged" and will be uploaded to unstable to start the transition. Feel free to test and report any issues.

Recent versions of debootstrap[2] will setup the usr-is-merged package to avoid installing additional dependencies required by usrmerge.

This does not quite work as intended, because debootstrap's simplistic
resolver only ever looks at the first alternative in dependencies, and
so usrmerge gets installed anyway. See #768062, for instance.

Cheers,
Sven

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2022-09-18 at 11:16 +0200, Bjørn Mork wrote:

It's fine to oversell the advantages of usrmerge.  It's not fine to
try
to hide the disadvantages.

Nothing is hidden, there's an open bug on the BTS, that's hardly a
secret hideout. As others have already explained (and as it was already explained countless times before including in the CTTE threads), and as
it is already explained in the bug itself, it is a minor issue at best
as dpkg -S was never reliable to begin with, and moreover if it was an
issue for scripts those scripts would already be broken given merged-
usr has been the default in new installations for the past 2 releases
(and for many years in Ubuntu). Therefore it can only be an issue for
console users, who can retrain muscle memory and use pattern matching
mode:

$ dpkg -S bin/passwd
passwd: /usr/bin/passwd

Finally, a patch was provided out of courtesy and is available on the
dpkg BTS attached to the relevant bug, it's up to the maintainer to
take it on. We cannot force it. We are certainly not going to block the transition for such a minor and work-aroundable problem.

--
Kind regards,
Luca Boccassi

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmMm/EkACgkQKGv37813 JB6KMw/+P3diS5B4q028x9AruNdXq3FAFVfjYqHC+HNOI8rCNHQ2hqEpPjSLRyZc fnqOiHfb05VdIHS4pAeR2kA9D9DT6VmvXp9yK/H4p/POyMqao4pteal5COUIOjC9 F9gwvUUo1wlfPOKvQw7slu/2hS9BVHrIMNQXKv3u13wGRzUvuSs13imPNSsheCAf KZ7sMgJ6m5zvfBWk9q1GZmNhIgnfC85ygB76MG4sFS1Ve6D2Q0JHQ+qKu2r3l0+2 hIHrFEa9g5J+ljSfnmRf+wGgZshEpz+vtgWVdKlhaMfjC6Ge11CCakChD93LaYYo kvP/uMMgnAvNHUiYycaUwR9eFR+Rl/uIyq3+bTYgl9iB4lKQJa01iFzv8lpgekar 1Y6cAX8nXTIryDC+rT0O3GbDvPbDQ/KQTo/eg2pM2Jd6vD1YHW9varhK8S+CwXyV oDvf31oUG6xwkb1xxEcudp15zPFvL2hmOFMmBAfkZZFPT2YMxxTv1UnellgZ2I/W Ftf38mvzheRzc62CT4mzxe70a5RYYc2Ud9kMsNJCoNk3H0sAWg+mYRNh5d1+jYAm aRzb3dm5E8HH/DMXTSIek7Uh0ApFI/XbaLmri6U2QKrXe1p8DH4f7FbJQ/bwhYRx x6box+paN0WV1GbvtBMS2JXieZKgBgKV2aTLNTCWupWcA6IXW8g=
=ijVn
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2022-09-18 at 12:11 +0100, Luca Boccassi wrote:

On Sun, 2022-09-18 at 11:42 +0200, Sven Joachim wrote:

This does not quite work as intended, because debootstrap's
simplistic resolver only ever looks at the first alternative in dependencies, and so usrmerge gets installed anyway.  See #768062,
for instance.

That doesn't match what I have seen while testing it, and what I see
even now in a sid chroot where usr-is-merged is pre-installed:

Did you try debootstrap with init-system-helpers 1.65.2 in unstable?
I could reproduce the problem; "debootstrap --print-debs unstable
unstable https://deb.debian.org/debian" or similar should be sufficient
to show the problem.

I wrote a possible patch for debootstrap in [1], but being debootstrap
we might need to have it in stable as well. Maybe someone has other
ideas as well.

Ansgar

[1]: https://salsa.debian.org/ansgar/debootstrap/-/commits/exclude-usrmerge

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2022-09-18 at 12:51 +0100, Luca Boccassi wrote:

I wrote a possible patch for debootstrap in [1], but being
debootstrap we might need to have it in stable as well. Maybe
someone has other ideas as well.

  [1]: https://salsa.debian.org/ansgar/debootstrap/-/commits/exclude-usrmerge

Indeed, that test was in an already installed chroot. This is very
strange as I am sure I had tested with a local reprepro with the new
packages when testing the debootstrap changes, and I recall that it was working as intended. Evidently I was mistaken.

Could you please fire a MR with those commits to the deboostrap repo?

https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/76

The most important part is setting up the chroot correctly, the
additional dependencies are an annoyance but can be removed post-fact
and shouldn't break things, so maybe it's fine to update it only in
unstable for now?

Sure, it might mean a few dependencies we don't want in buildd chroots
for a few days, but I don't think that's a critical problem. It only
affects testing/unstable either way.

Ansgar

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2022-09-18 at 11:42 +0200, Sven Joachim wrote:

On 2022-09-10 15:37 +0200, Ansgar wrote:

the transition to usrmerge as described in [1] is planned to start
around 2022-09-15 (next Thursday).

init-system-helpers 1.65~exp1 in experimental adds the new
dependency on
"usrmerge | usr-is-merged" and will be uploaded to unstable to
start the
transition. Feel free to test and report any issues.

Recent versions of debootstrap[2] will setup the usr-is-merged
package to
avoid installing additional dependencies required by usrmerge.

This does not quite work as intended, because debootstrap's
simplistic
resolver only ever looks at the first alternative in dependencies,
and
so usrmerge gets installed anyway.  See #768062, for instance.

That doesn't match what I have seen while testing it, and what I see
even now in a sid chroot where usr-is-merged is pre-installed:

# dpkg -l | grep merge
ii usr-is-merged 30+nmu1 all Transitional package to assert a merged-/usr system
# apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
init-system-helpers
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 49.8 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]

apt does not attempt to install usrmerge.

Can you provide a reproducer?

--
Kind regards,
Luca Boccassi

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmMm/OgACgkQKGv37813 JB4EFQ/+JMY4wywXDaZWLr+EZ+LpSRHSBnt6N0YuJA3P45Nvg7BMdtIFuZaxNvzw pxflrS/jkWMj7aB4FFIsb33FhUFDKyi/9ejxcLsAD6c9iYLMvDRYk8DvzSzZgA2X 7ZLZzXyaxBlfBjvquH6f7CPia4Sfdx6HtRNNEX2B+wxbwhbMcP2Wm0a56++YBxPp WZO1LWP/1tJfsgqn2Gkpglo9RlRDezzMLXrffmP/Hb2pKYu6khtsvbk2zF4uqWwN I5lvFBk8ssuaw9y6P8uFacprdt6ddZEvYlAGICz4JtxHuq1ZyDCeXBh0K1YtyuXV rJFH+VCl5dh7kkcXKWSwrxrI4wgbE3+PrQ7+zFL9FpceBec9XrXxqmc5U9Htrjie EJonua3U0+jF2uQ588p2XPDxjQw8Zs3ebc7Ua6On3CV+4GhEeAt0SpDJLVW+ZP7Z q8jEbYezG4ZF+SYD2+fFNIlXwTzlynITHHegHaBvlPcnzLkf82fBMaVsPr16KP0X AdJbqDueXIw8PIBecrpAGlmPKdedJp3/5+wjqdjdkEf7sVhZY4oVDEAKBErPPTzZ lsSHLR9lXUap88dcTn+ABkrpfKQm2PuGxm910eyq142YmjZ6v7w9tx3r/7/yjvd/ PBX5WTvmyTIoS0DTcGgv8rbvEy7KfBG+jmgwmW+3/BBFwe4YjZ0=
=Zsns
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2022-09-18 at 13:20 +0200, Ansgar wrote:

On Sun, 2022-09-18 at 12:11 +0100, Luca Boccassi wrote:

On Sun, 2022-09-18 at 11:42 +0200, Sven Joachim wrote:

This does not quite work as intended, because debootstrap's
simplistic resolver only ever looks at the first alternative in dependencies, and so usrmerge gets installed anyway.  See
#768062,
for instance.

That doesn't match what I have seen while testing it, and what I
see
even now in a sid chroot where usr-is-merged is pre-installed:

Did you try debootstrap with init-system-helpers 1.65.2 in unstable?
I could reproduce the problem; "debootstrap --print-debs unstable
unstable https://deb.debian.org/debian" or similar should be
sufficient
to show the problem.

I wrote a possible patch for debootstrap in [1], but being
debootstrap
we might need to have it in stable as well. Maybe someone has other
ideas as well.

Ansgar

  [1]: https://salsa.debian.org/ansgar/debootstrap/-/commits/exclude-usrmerge

Indeed, that test was in an already installed chroot. This is very
strange as I am sure I had tested with a local reprepro with the new
packages when testing the debootstrap changes, and I recall that it was
working as intended. Evidently I was mistaken.

Could you please fire a MR with those commits to the deboostrap repo?

The most important part is setting up the chroot correctly, the
additional dependencies are an annoyance but can be removed post-fact
and shouldn't break things, so maybe it's fine to update it only in
unstable for now?

--
Kind regards,
Luca Boccassi

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmMnBiYACgkQKGv37813 JB62ig//Qvhh4s0zNa6TfyFqkaY+LIkOx1zKojGP3rCZR1R5DZW9kXhBs+vBH9OT NGL5wcwXFV55tAHbONhJ0iFWR+aHzU1oESmX/8vjH+NwJPPlmLB9dLsMnVlWXXs4 u+RcmN+0MUjZouOkUl+GpO2GZ9PkH1FacrJpAA3ufryOJiGVhnQDIx51sjPPVWVp NSTkSLZ94RFX8+sz0Lmy6Y24xwx3htuojpPDJctLZHZl9+vhqAEmgvhSTLr1rPOt 2T8KQS7BYV5EIdvAbJf/yKmT9rxCFFfScaTSvzM/oEsXJNqCGMcou4jqoldBGpeb G1tIDdMK4sdMmf6Nrp1Ri2BwZ6Ysu1ifpGH+GvgjCFw6+OKM+gf1DY/xbEiNvFnW XSgEjWQkzA/gcTGqAFmnYu7+pbQbf4KTBjkw+s0NJeGLV0Vk5TdRmZW4e2Eck2IA vYn3XZjUxCULt7y2piLducv6VepOuS9WAx8q9KQAQToewuwXtzZmqTI0rXlmCK2Y ZbSExNtbhaz9Zk5SydYZr0ctnubWK5XqjWWEgyW6GDY39e3xuOa5/fvQnl46QCov Vy3YGzSTbftz2u3riUEhskB5icGfb7JoNE+1+wjTJ7f13bHCxEQKOg2htjLAUNh4 hvFfHSOwN3JJjA+sWvh7MvzF0mS9r98mx+LKYNbfg2ud0/IQFPY=
=5B/p
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 2022-09-17 at 02:30 +0100, Luca Boccassi wrote:

On Thu, 2022-09-15 at 22:57 +0100, Luca Boccassi wrote:

On Sat, 2022-09-10 at 15:37 +0200, Ansgar wrote:

Hi,

the transition to usrmerge as described in [1] is planned to
start
around 2022-09-15 (next Thursday).

init-system-helpers 1.65~exp1 in experimental adds the new
dependency
on
"usrmerge | usr-is-merged" and will be uploaded to unstable to
start
the
transition. Feel free to test and report any issues.

Recent versions of debootstrap[2] will setup the usr-is-merged
package to
avoid installing additional dependencies required by usrmerge.
The
usr-is-merged package can also be manually installed in existing
systems
for the same reason.

Debian's buildds will continue to use the legacy filesystem
layout
for
Debian 12 (bookworm).

We will send an announcement to debian-devel-announce@ once the
upload
to unstable happens.

Ansgar

  [1]: https://lists.debian.org/debian-ctte/2022/09/msg00005.html
  [2]: debootstrap 1.0.114+deb10u1, 1.0.123+deb11u1, 1.0.127

Quick update: three minor issues where found, two with i-s-h itself
(one solved in experimental just now about test deps
uninstallability
on some ports and one piuparts seemingly false positive about
/etc/shells that I'll fix tomorrow), and one in
usrmerge+nspawn+arm64
[0]. I have just come back home from LPC so did not have much time
today, will have a look at the latter two tomorrow and then upload
to
unstable once the situation is clearer.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019575

All 3 issues are solved or pending:

1) init-system-helpers build issue on some ports architectures has
been
fixed (new test dependency fakeroot is not available everywhere, made optional)

2) salsa CI issue with piuparts job image not being built by debootstrap/mmdebstrap and thus not installing usrmerge/usr-is-
merged,
causing a false positive when usrmerge is pulled in by the package- under-test thus falsely attributing the /etc/shells change to it,
fixed
by installing usrmerge in the pre-built image, MR pending: https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/372

3) systemd-nspawn on aarch64 merged systems creates a /lib64 -> /usr/lib/aarch64-linux-gnu symlink which is not created by debootstrap/mmdebstrap, so the usr-is-merged preinst check doesn't
expect it and erroneously fails. Fixed with NMU to just enforce that
the arch-specific libdirs are symlinks to /usr/lib* instead of
exactly
the same dirname under /usr, as this is not the right place to care
about that detail, the only important thing in this context is the
target being under /usr.

Unless any new issue pops up, I'll upload i-s-h to unstable to start
the transition tomorrow evening.

It's been almost two weeks now, so another (and probably final) status
update, as init-system-helpers was uploaded and has migrated to
bookworm and everything seems to be going very smoothly, without any
major issue reported. A few minor issues and corner cases were reported
and fixed in various places, with contributions from multiple people.
In usrmerge itself:

- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020312
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019985
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019506
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019575
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020549
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926699

Some of these are fixed in unstable, with the new version migrating in
a couple of days.

A few issues in other packages were found and fixed too - these are pre-existing bugs that were never found before:

- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020426
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020783

Note that the second one means cdebootstrap currently doesn't work
(usual multiarch dependency resolution issue, with a custom parser not recognizing the :any suffix and failing), a patch is available and a MR
is open.

A new version of debootstrap has also just migrated - I made a mistake
with the July update, and failed to notice that both usr-is-merged and
usrmerge are installed, which means unnecessary dependencies are pulled
in by default. The new version fixes that. It will also be available in backports on Monday, and once it has marinated enough I intend to push
to to proposed-updates too.

There are 3 issues with a pending or incomplete solutions:

- a MR is pending on glibc to create the biarch symlinks on the
multiarch libc6 packages too (same fix is already available for biarch packages)
- usrmerge needs some mildly invasive changes for hurd-i386 which we
are a bit wary of rolling out to other architectures to avoid
increasing risk, so for now it is handled via a specific upload to
debian-ports unreleased (thanks Samuel!)
- WSL images were still built and published unmerged, and that has now
been fixed, the maintainer uploaded a merged image to the MS store. Due
to filesystem weirdness in WSL 1.0 (it's fine in 2.0), converting
doesn't seem to work (note that everything should switch to WSL 2.0
anyway these days), there's an upstream issue about it, but there's
nothing we can do on our side

Final note, since it has been reported a few times: when using a
container manager (like Podman) that stacks multiple images with
OverlayFS, note that the conversion cannot happen, as you cannot modify
the lower layer - this is just how OverlayFS works. The base layer
needs to be converted (or rebuilt) individually. There's nothing we can
do about this, apart from detecting and aborting (without touching
anything) with a clear message.

Huge thanks to everybody who contributed fixes and/or good quality and actionable bug reports!

--
Kind regards,
Luca Boccassi

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmM4lh8ACgkQKGv37813 JB57+xAAgBZiLF/JCmAMsr7llPdrAISj5OWpPVpk4GSYg5i0l5jA6PZkGX+yOgqX 9Uo8zkH1UClAK6RkG1tXhCIiWJgHOs2TSGXEYUUuPZGnoToy1JHnOdZxDfUopOSH 71cY+oP451+p/CO7r6CWKEG/SFb302ZxOKHbYjGytBDURrhLa+CMxuuFaR/AFVVJ uvRf6N+puJuL73i38wkEN4uy2gBS2UFVRM3j2Qcx4QqMbWR3WuE2bgUA3kc++69y YLjCqIvIPtHl400LP605ZwoL7I5qTu9oHjU2j00v0XM7RkQFT4K5MVGjaG9ySe7y qFkyn48fZtDCGiNCD92v3GJob/NCanPGva/d+8LrIJlvPMdKlbKKucm142F1QT1N bs2ZDS/mLVyKbx3ub246paeGW+BcuvEiDgLWC1E2K4DjOiibCLmXfPFftR5+NJU5 OGz71hO73hC7pK/2XE9ArtY36LOObfoiQLIrQLUOT19L/yBE7LofwzPQzknFldXi GtyW/XPunHk0tG+w0icBPzT+LJb1Yo0Bm2PMu2jJWSSBKLOvYWFvz3eQEHFl2NUI +eCJfurqbDVQTqI942aACx5xmco8tM7I+nFu5wBYzfs1EpYHLterUGg1BH7t5aBM S0y8mCkBslFjOZilLtIQor8oln3peM/yoCwgquKcNz2Fo74Zg20=
=xAmO
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Luca Boccassi <bluca@debian.org> (2022-10-01):

A few issues in other packages were found and fixed too - these are pre-existing bugs that were never found before:

- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020426

base-installer fixed in unstable a few days ago and migrated to testing,
d-i works fine again since then.

- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020783

libdebian-installer just uploaded, sorry for the delay. cdebootstrap
confirmed to be happy again with deploying an unstable or testing chroot
once that's in place.


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmM49zQACgkQ/5FK8MKz VSD/5w/+LZNSnbp+7jbwFQ24xo3GlisJLjnFQmwM/xPwQ8C40TgX/8eAMKnFwKfc gc3rsLuEfa+zqH8snhnVS1911UrwCEvpwQbtv0IOTCq36Wc6y/EdaLkSXh9Yqv6W Qa9goK5RqDPWG5YtBdxSnB2LhZetF9kizKrFB683tcBpXceDuTBdx+Ri3/PvlhCs iclxNKzEhwFBuTjwBRP7Rzdb8NN+2P5GRP+AGrP8EqW2fWjyq/pdxWdJRMkQe0W6 ns1ukO2PEbPywe4zFpNhJ4pHubpaFEmVrDC/7LeFsWysCy853V85cNtkkH2TbZB7 pWDcAHcaZ0fwDL5kJr8/oDkGr+S6dx/ksnzuf3Zztc9dewuz64juqPWayD9HrTIO jQ8zOjBZM4kUEai9/buy7zTnVMCC60BWf8u7v998L6opwrr3BA3eQjuCBhqCozn1 NB0SLAVnGjQ/6u7Alqi2tYw0KjD5gE7JZV2LJWYubN45uvFvqq56DRf7Uxs3tYL5 bART5opGmS8YFXRdDIXyclGh+QfMvHFTXdT/3AC6BMGqC3dzNLuZnq1mg1DAkPB/ BSSN39zfW7p6a2zh6I+oNTxOJxIFuw/oTjeD7zaf2i5kCaDzQkO/JbYzDs5vBvOt flza3pn4hhLwxukYm/5kk93Cm+jvpoXXFcFHomUAKayIzoBUh8Q=
=nZ9L
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*