Re: Transition to usrmerge in full swing [was: Re: transition to usrmerge to start around 2022-09-15 (next Thursday)]

[Cyril Brulebois]

Luca Boccassi  (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 (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Transition to usrmerge in full swing [was: Re: transition to usrmerge to start around 2022-09-15 (next Thursday)]

[Luca Boccassi]

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/msg5.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 

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Luca Boccassi]

On Sun, 2022-09-18 at 14:00 +0200, Ansgar wrote:
> 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.

Thank you, and also thanks to Sven who brought it to our attention.

Let's wait a couple of days and see if anything else pops up, and then
we can upload.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Ansgar]

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

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Luca Boccassi]

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


signature.asc
Description: This is a digitally signed message part

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Ansgar]

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

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Luca Boccassi]

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-merged30+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


signature.asc
Description: This is a digitally signed message part

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Luca Boccassi]

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


signature.asc
Description: This is a digitally signed message part

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Marco d'Itri]

On Sep 18, Bjørn Mork  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


signature.asc
Description: PGP signature

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Sven Joachim]

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

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Andrey Rahmatullin]

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


signature.asc
Description: PGP signature

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Bjørn Mork]

Luca Boccassi  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

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Luca Boccassi]

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


signature.asc
Description: This is a digitally signed message part

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Adam Borowski]

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.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Luca Boccassi]

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/msg5.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


signature.asc
Description: This is a digitally signed message part

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Adam Borowski]

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...

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Luca Boccassi]

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/msg5.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


signature.asc
Description: This is a digitally signed message part

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Luca Boccassi]

On Mon, 12 Sept 2022 at 07:35, Marc Haber  wrote:
>
> On Sun, 11 Sep 2022 11:08:44 -0400, Marvin Renich 
> wrote:
> >* Ansgar  [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/msg5.html

Kind regards,
Luca Boccassi

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Marc Haber]

On Sun, 11 Sep 2022 11:08:44 -0400, Marvin Renich 
wrote:
>* Ansgar  [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

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Marvin Renich]

* Ansgar  [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