On Tue, 2022-08-16 at 21:06 +0100, Luca Boccassi wrote: > On Thu, 2022-07-28 at 13:14 +0100, Luca Boccassi wrote: > > On Sun, 2022-07-17 at 00:56 +0100, Luca Boccassi wrote: > > > On Mon, 2021-10-18 at 12:17 -0700, Sean Whitton wrote: > > > > Hello, > > > > > > > > On Wed 15 Sep 2021 at 11:46AM +01, Simon McVittie wrote: > > > > > > > > > As discussed in our last meeting, I think we should issue > > > > > more > > > > > specific > > > > > advice about merged-/usr, and in particular about what > > > > > #978636 > > > > > means for > > > > > maintainers right now. > > > > > > > > With five votes cast in favour of the text by Simon, Niko, > > > > Gunnar, > > > > Marga > > > > and myself, the outcome is no longer in doubt. Thus, in > > > > accordance > > > > with > > > > the Debian Constitution, the voting period has now concluded. > > > > > > > > Therefore, using its powers under section 6.1.5 of the Debian > > > > Constitution, the Technical Committee issues the following > > > > advice: > > > > > > > > Summary > > > > ======= > > > > > > > > There are currently Debian 11 installations with both the > > > > merged-/usr > > > > and non-merged-/usr filesystem layouts. All of these > > > > installations > > > > should successfully upgrade via normal upgrade paths to a > > > > merged-/usr > > > > Debian 12. Only after the release of Debian 12 can packages > > > > assume > > > > that > > > > all installations will be merged-/usr. > > > > > > > > Main points: > > > > > > > > - We have recommended merged-/usr for Debian 12. > > > > - Moving individual files is not merged-/usr. > > > > - "Symlink farms" are not merged-/usr. > > > > - Upgrading a non-merged-/usr system to Debian 12 needs to > > > > work. > > > > - Upgrading a merged-/usr system to Debian 12 needs to work. > > > > - Packages cannot assume all systems are merged-/usr until the > > > > Debian > > > > 13 > > > > development cycle begins. > > > > - Upgrading via apt in the usual way should work. > > > > - Testing and QA systems should be able to avoid this > > > > transition, but > > > > if > > > > they do, they cannot be upgraded beyond Debian 12. > > > > - A package building incorrectly on a non-merged-/usr system is > > > > a > > > > bug. > > > > - A package building incorrectly on a merged-/usr system is a > > > > bug. > > > > - Please stop moving individual packages' files from the root > > > > filesystem > > > > into /usr, at least for now. > > > > > > > > Definitions and current status > > > > ============================== > > > > > > > > libQUAL refers to the directories described in FHS 3.0 section > > > > 3.10 > > > > [1], > > > > such as lib64 on the amd64 architecture. > > > > > > > > Merged /usr is the filesystem layout in which /bin, /sbin, /lib > > > > and > > > > each > > > > /libQUAL that exists are symbolic links to the corresponding > > > > directories > > > > below /usr. This results in aliasing between /bin and /usr/bin, > > > > and > > > > so > > > > on. > > > > > > > > In the merged-/usr layout, files whose canonical logical > > > > location is > > > > in > > > > one of the affected directories on the root filesystem, such as > > > > /bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically > > > > located > > > > at > > > > the corresponding path below /usr, such as /usr/bin/bash. Each > > > > file > > > > in > > > > one of the affected directories is accessible via two paths: > > > > its > > > > canonical logical location (such as /bin/bash or /usr/bin/env), > > > > and > > > > the > > > > other path implied by the aliasing (such as /usr/bin/bash or > > > > /bin/env). > > > > > > > > There are two supported categories of Debian 11 installation, > > > > which > > > > are > > > > currently considered equally-supported: > > > > > > > > - Merged-/usr installations. These were installed with debian- > > > > installer > > > > from Debian 10 or later, or installed with debootstrap -- > > > > merged- > > > > usr, > > > > or converted from the non-merged-/usr layout by installing > > > > the > > > > usrmerge package, or installed or converted by any similar > > > > procedure. They have the merged-/usr layout. > > > > > > > > - Non-merged-/usr installations. These were installed with > > > > debian-installer from Debian 9 or earlier and subsequently > > > > upgraded > > > > without converting to merged-/usr, or installed with > > > > debootstrap > > > > --no-merged-usr, or converted from the merged-/usr layout > > > > with > > > > dpkg's > > > > "dpkg-fsys-usrunmess" utility or any similar procedure. They > > > > have > > > > the > > > > traditional, non-merged-/usr layout in which /bin/bash and > > > > /usr/bin/env have exactly those physical paths, and > > > > /usr/bin/bash > > > > and > > > > /bin/env do not exist. > > > > > > > > Merged-/usr is not the only filesystem layout that has been > > > > proposed > > > > for > > > > unifying the root filesystem with /usr. For avoidance of doubt, > > > > we do > > > > not consider other filesystem layouts to be implementations of > > > > merged-/usr. In particular, we do not consider these to be > > > > implementations of merged-/usr: > > > > > > > > - all affected files physically located in /bin, /sbin, /lib > > > > and > > > > /libQUAL, with /usr/bin as a symlink to /bin, etc. (this is > > > > the > > > > reverse of merged-/usr, and was historically used in the > > > > hurd-i386 > > > > port) > > > > > > > > - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with > > > > individual symbolic links such as /bin/bash -> /usr/bin/bash > > > > for > > > > only > > > > those files that historically had their canonical logical > > > > location > > > > on > > > > the root filesystem > > > > > > > > - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with > > > > individual symbolic links such as /bin/env -> /usr/bin/env > > > > for all > > > > files in the affected directories, regardless of whether they > > > > historically had their canonical logical location on the root > > > > filesystem > > > > > > > > [1]: > > > > https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential > > > > > > > > Upgrade path from Debian 11 to Debian 12 > > > > ======================================== > > > > > > > > The technical committee resolved in #978636 [2] that Debian 12 > > > > 'bookworm' should only support the merged-/usr layout. This > > > > resolution > > > > describes the implications of that decision in more detail. > > > > > > > > Debian installations have traditionally had a straightforward > > > > upgrade > > > > path between consecutive releases, and the technical committee > > > > expects > > > > maintainers to continue this. In the case of #978636, the > > > > upgrades we > > > > are interested in are: > > > > > > > > - Upgrading from Debian 11 (stable release) to Debian 12 > > > > (stable > > > > release) > > > > > > > > - Upgrading from Debian 11 (stable release) to testing/unstable > > > > during > > > > the development cycle that will lead to Debian 12, and > > > > subsequently > > > > upgrading from testing/unstable to Debian 12 (stable release) > > > > > > > > What we understand this to imply is as follows: > > > > > > > > - Because Debian 11 installations with the merged-/usr layout > > > > already > > > > exist, and because Debian 12 should only support the merged- > > > > /usr > > > > layout, all packages in Debian 12 should be installable onto > > > > a > > > > merged-/usr system along with their dependencies, and work > > > > correctly > > > > on the resulting system. > > > > > > > > - Because Debian 11 installations with the non-merged-/usr > > > > layout > > > > already exist, all packages in Debian 12 should be > > > > installable onto > > > > a > > > > non-merged-/usr system along with their dependencies, and > > > > work > > > > correctly on the resulting system. > > > > > > > > + The key reason for this is that apt is not required to > > > > perform > > > > the > > > > upgrade between stable releases in any particular order, > > > > so > > > > long > > > > as package dependency relationships are respected; > > > > therefore > > > > the > > > > upgrade can happen in whatever order apt chooses, which > > > > can > > > > vary > > > > between machines. Debian has not traditionally required > > > > use of > > > > a > > > > special upgrade tool similar to Ubuntu's do-release- > > > > upgrade(8) > > > > and > > > > we believe the upgrade to Debian 12 should be no > > > > different (see > > > > below for more details on this topic). > > > > > > > > + Another reason for this is that during the development of > > > > Debian > > > > 12, testing/unstable systems undergo a series of partial > > > > upgrades, > > > > which similarly will happen in an undefined order. > > > > > > > > + We do not require that the resulting system remains > > > > non-merged-/usr: if the packages involved in this > > > > installation > > > > transaction are part of the implementation of a > > > > transition to > > > > merged-/usr, then installing them might result in the > > > > system > > > > becoming merged-/usr. > > > > > > > > - The same expectations apply to packages uploaded to > > > > testing/unstable > > > > during the development cycle that will lead to Debian 12. > > > > > > > > - Debian contributors who are interested in merged-/usr are > > > > invited > > > > to > > > > implement a straightforward migration path from non-merged- > > > > /usr to > > > > merged-/usr. The Technical Committee will not design this > > > > migration > > > > path in detail. If disputes arise related to this migration > > > > path, > > > > or > > > > if advice on this migration path is requested, we will > > > > resolve > > > > those > > > > by following our usual procedures. > > > > > > > > + One example of a migration path that might be used is for > > > > an > > > > Essential package to add a dependency on the usrmerge > > > > package, > > > > so > > > > that it will be installed automatically during upgrades. > > > > We do > > > > not > > > > require this to be the migration path that is chosen; it > > > > is > > > > presented here merely to demonstrate that such a > > > > migration path > > > > can exist. > > > > > > > > - After Debian 12 is released, the transition to merged-/usr is > > > > considered to be complete. Because we do not support > > > > "skipping a > > > > release" when upgrading systems, new packages uploaded to > > > > testing/unstable during the development cycle that will lead > > > > to > > > > Debian > > > > 13 may assume and require that the system onto which they are > > > > installed is merged-/usr. > > > > > > > > If a suitable transition mechanism is not available by the time > > > > the > > > > Debian 12 freeze is reached, the Technical Committee will > > > > rescind our > > > > advice in #978636 and modify our advice in this resolution to > > > > reflect > > > > the situation that has been reached. We hope that this will not > > > > be > > > > necessary. > > > > > > > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636 > > > > > > > > Use of a special upgrade path > > > > ============================= > > > > > > > > Some developers have argued that we should deploy merged /usr > > > > by > > > > means > > > > of a special upgrade path, with all other upgrade paths being > > > > declared > > > > to be unsupported. Some examples of special upgrade paths that > > > > might > > > > be > > > > proposed: > > > > > > > > - upgrading dpkg before carrying out the rest of the upgrade > > > > > > > > - installing the usrmerge package before carrying out the > > > > upgrade > > > > > > > > - using a special tool similar to Ubuntu's do-release- > > > > upgrade(8) > > > > which > > > > encapsulates whatever steps are necessary > > > > > > > > This would imply that upgrade paths other than the recommended > > > > one > > > > are > > > > not expected to work. > > > > > > > > We are aware that many Debian users do not read the release > > > > notes > > > > before > > > > upgrading from oldstable to stable, and will expect to be able > > > > to > > > > upgrade via whatever apt commands they are used to using, > > > > regardless > > > > of > > > > whether the release notes recommend something different. Given > > > > that > > > > there are alternatives available, we do not think that merged- > > > > /usr is > > > > sufficiently good cause to interfere with this. > > > > > > > > During the Debian 12 development cycle, users of > > > > testing/unstable > > > > will > > > > also need an upgrade path from Debian 11 to testing/unstable, > > > > or from > > > > older to newer snapshots of testing/unstable. In general this > > > > will be > > > > done using apt, and it needs to continue to work if at all > > > > possible, > > > > even before a special upgrade tool has been prepared; > > > > introducing a > > > > "flag day" at which all testing/unstable users are expected to > > > > carry > > > > out > > > > additional non-automatic upgrade steps would be disruptive, and > > > > in > > > > practice many testing/unstable users are likely to skip those > > > > steps. > > > > > > > > For these reasons, we make the simple, conservative > > > > recommendation > > > > that > > > > a special upgrade path should not be required, and upgrading > > > > via apt > > > > in > > > > approximately the same way as previous Debian releases should > > > > continue > > > > to work in general. > > > > > > > > Testing and QA > > > > ============== > > > > > > > > We anticipate that during the development cycle that will lead > > > > to > > > > Debian > > > > 12, it is likely to be useful for testing and QA infrastructure > > > > (such > > > > as > > > > autopkgtest, piuparts and/or reproducible-builds) to be able to > > > > produce > > > > an installation of Debian testing/unstable that is not merged- > > > > /usr, > > > > in > > > > order to be able to verify that packages targeted for inclusion > > > > in > > > > Debian 12 can still be installed and/or built successfully in a > > > > non-merged-/usr environment during partial upgrades. > > > > > > > > As a result, we recommend that if there is an automatic > > > > migration > > > > from > > > > non-merged-/usr to merged-/usr, it should be possible to > > > > prevent that > > > > migration. However, systems where that migration has been > > > > prevented > > > > are > > > > not required to be fully-supported, and in particular, > > > > upgrading them > > > > to > > > > Debian 13 or to the state of testing/unstable during > > > > development of > > > > Debian 13 should be considered unsupported. > > > > > > > > Building packages > > > > ================= > > > > > > > > In #914897 [3] the Technical Committee resolved that for Debian > > > > 11, > > > > packages can validly be built in either a merged-/usr or non- > > > > merged- > > > > /usr > > > > environment. We understand this to imply that packages built > > > > in > > > > either > > > > a merged-/usr or non-merged-/usr environment should work as > > > > intended > > > > in > > > > either a merged-/usr or non-merged-/usr environment. > > > > > > > > There is a class of bugs in which a package embeds the absolute > > > > path > > > > to > > > > some executable or other file, in such a way that if it is > > > > built in > > > > an > > > > environment with a unified /usr (either via merged-/usr or > > > > symlink > > > > farms), this can result in embedding a non-canonical path such > > > > as > > > > /usr/bin/sh or /bin/env which will not work correctly in a > > > > non-merged-/usr environment. The Technical Committee reminds > > > > maintainers that packages in Debian 12 are expected to work > > > > correctly > > > > in > > > > a non-merged-/usr environment, and therefore this class of bugs > > > > needs > > > > to > > > > be resolved. As a result, we recommend that these bugs should > > > > generally > > > > be treated as release-critical for Debian 12 by maintainers and > > > > the > > > > release team. > > > > > > > > The Reproducible Builds effort tracks this class of bugs as > > > > "paths_vary_due_to_usrmerge" [4] and many bugs in this class > > > > are > > > > tracked > > > > with the usertag "usrmerge" [5]. In Autotools-based build > > > > systems, > > > > they > > > > can often be avoided by passing arguments such as > > > > `SED=/bin/sed` to > > > > the > > > > configure script. > > > > > > > > Note that although the name of the usertag mentions usrmerge, > > > > this > > > > class > > > > of bugs is not specific to the usrmerge package, and not > > > > completely > > > > specific to merged-/usr; many of these bugs would also manifest > > > > if > > > > unified /usr was achieved via symlink farms, or if a local > > > > executable > > > > such as /usr/local/bin/sed existed on the build system. > > > > > > > > #993675 [6] is a typical example of this class of bugs. > > > > > > > > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914897 > > > > [4]: > > > > https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html > > > > [5]: > > > > https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=reproducible-builds%40lists.alioth.debian.org&tag=usrmerge > > > > [6]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993675 > > > > > > > > Moratorium on moving files' logical locations into /usr > > > > ======================================================= > > > > > > > > In the past, some package maintainers have taken advantage of > > > > the > > > > fact > > > > that /usr is now required to be mounted during early boot > > > > (since > > > > Debian > > > > 9) to move individual files from the root filesystem to /usr. > > > > Examples > > > > of this being done during previous development cycles include > > > > the > > > > libglib-2.0.so.0 and libgcrypt.so.20 shared libraries, and the > > > > command-line utilities in the iptables package. > > > > > > > > The Technical Committee recommends that during the Debian 12 > > > > development > > > > cycle, the maintainers of individual packages should not > > > > proactively > > > > move files from the root filesystem to the corresponding > > > > locations in > > > > /usr in the data.tar.* of packages. Files that were in /usr in > > > > the > > > > Debian 11 release should remain in /usr, while files that were > > > > in > > > > /bin, > > > > /lib* or /sbin in the Debian 11 release should remain in those > > > > directories. If files were moved from /bin, /lib* or /sbin > > > > into /usr > > > > since the Debian 11 release, they should be moved back to their > > > > Debian > > > > 11 locations. > > > > > > > > Similarly, during the Debian 12 development cycle, we recommend > > > > that > > > > maintainers of tools such as debhelper should not move files > > > > from the > > > > root filesystem into /usr. > > > > > > > > For example, debhelper 13.4 started moving systemd units from > > > > /lib/systemd into /usr/lib/systemd, but this was subsequently > > > > reverted > > > > in 13.5.2. We consider the revert that was done in 13.5.2 to > > > > have > > > > been > > > > an appropriate course of action. > > > > > > > > We issue this recommendation for several reasons: > > > > > > > > - The transition to merged-/usr will make the logical locations > > > > of > > > > these > > > > files irrelevant to their physical locations. > > > > > > > > - The transitional mechanisms necessary to prevent such moves > > > > from > > > > breaking other packages that hard-code specific paths are > > > > error- > > > > prone, > > > > and can themselves interfere with the transition to merged- > > > > /usr. > > > > > > > > - After the transition to merged-/usr has completed, during the > > > > Debian > > > > 13 development cycle, we expect that maintainers will be able > > > > to > > > > move > > > > these files without needing transitional mechanisms. > > > > > > > > - On merged-/usr systems, there is a possible failure mode > > > > involving > > > > files being moved between packages (with Replaces) during the > > > > same > > > > release cycle that their logical location is changed from the > > > > root > > > > filesystem to the corresponding aliased directory in /usr, > > > > which > > > > can > > > > result in the affected file disappearing. This can be avoided > > > > by > > > > not > > > > changing the file's logical location until the beginning of > > > > the > > > > Debian > > > > 13 development cycle, after the transition to merged-/usr is > > > > complete. > > > > > > > > - On non-merged-/usr systems, a failure mode has been observed > > > > in > > > > which > > > > older shared libraries in /lib/MULTIARCH are not always > > > > deleted as > > > > intended, and interfere with correct loading of the newer > > > > shared > > > > library in /usr/lib/MULTIARCH. This can be avoided by not > > > > changing > > > > the > > > > file's logical location until the beginning of the Debian 13 > > > > development cycle, after the transition to merged-/usr is > > > > complete, > > > > at > > > > which point ldconfig(8) will choose the newer library even if > > > > this > > > > occurs. > > > > > > > > This recommendation applies until Debian 12 is released, or > > > > until a > > > > subsequent Technical Committee resolution rescinds it, > > > > whichever is > > > > sooner. We intend to rescind this recommendation if mechanisms > > > > are > > > > developed to avoid the undesired side-effects of moving files > > > > from > > > > the > > > > root filesystem into /usr. > > > > > > > > For the Technical Committee: > > > > > > Hello Technical Committee members, > > > > > > We are half a year from the first Bookworm freeze, and more than > > > half a > > > year since the quoted decision. While no progress has been made > > > in > > > Debian, in this period of time OpenMandrive finished their > > > transition, > > > and Gentoo and Yocto started planning theirs, and Ubuntu > > > forcefully > > > upgraded all old installations, that existed before the installer > > > was > > > changed, that updated to 21.10 and the LTS 22.04. The list of > > > distributions shipping with the legacy layout is getting smaller > > > and > > > smaller. It is time to complete this work, before upstream > > > software > > > start dropping support too. > > > > > > So here's the plan for Debian Bookworm, in accordance with your > > > decision as quoted above. > > > > > > Piuparts has been enhanced with a new test case that covers the > > > moratorium on moving files manually between their location in the > > > root > > > directories and /usr. This also covers moves between packages, > > > and > > > across a distribution upgrade. I am told this test is now live > > > and thus > > > covering all packages migrating from unstable to testing [0]. > > > This coverage will give us peace of mind that the hypothetical > > > and > > > never-seen failure modes described in your decision cannot happen > > > unnoticed, will be caught by Piuparts and cause the package to > > > become > > > RC-buggy. > > > > > > The usrmerge package has been updated to pick up a few fixes from > > > Ubuntu, and most importantly to provide a new lightweight > > > metapackage, > > > usr-is-merged, that can only be installed on merged-usr systems, > > > to > > > provide a way for installers to avoid the additional dependencies > > > of > > > usrmerge when they set up the filesystem correctly by themselves > > > (eg: > > > debootstrap), and for users who already completed the transition. > > > It > > > also gained a flag file that stops the package from updating the > > > system, clearly marked as making the system unsupported. > > > > > > A MR is pending for debootstrap [1] to make use of this new > > > package and > > > file flag when --variant=buildd is passed, so that buildds can > > > continue > > > to be unmerged-usr until the CTTE says otherwise, as per decision > > > above. > > > > > > Once deboostrap is updated and deployed on the buildds, a > > > "usrmerge | > > > usr-is-merged" dependency will be added to the Priority: > > > essential > > > init-system-helpers package, and uploaded to unstable to complete > > > the > > > transitions for all installations that are older than buster or > > > that > > > have been manually installed as unmerged-usr. Any system not > > > upgraded > > > will be considered unsupported, and any package that doesn't work > > > on > > > the only supported layout will be considered RC-buggy, as per > > > decision > > > above. No special installation or upgrade path will be necessary, > > > the > > > normal apt upgrade/install process works as expected, and the > > > transition happens from a maintainer script and it does not > > > require to > > > be ordered before or after any other package installation or > > > upgrade. > > > > > > All software has bugs by nature, and this will be no exception. > > > But > > > with Ubuntu having done an enormous amount of QA for us in the > > > past > > > years, especially in the almost 12 months since 21.10 and 22.04 > > > LTS > > > have been released, without revealing any major issues, and with > > > the > > > new Piuparts coverage, and with all upstream software having been > > > exercised in the new layout for the best part of a decade in most > > > distributions, it is really not going to get any better. > > > > > > The patch from user uau that the dpkg maintainer rejected in the > > > past > > > has been submitted to the existing bug [2] for completeness (with > > > permission from the author). > > > It will not be necessary to initiate or complete the migration to > > > merged-usr, and we will not hold back waiting for a resolution on > > > it, > > > given the maintainer has made his intentions abundantly clear on > > > the > > > matter as recently as four months ago [3]. The patch is presented > > > simply because it will likely be necessary, in that or any other > > > form, > > > to lift the moratorium on moving files between packages manually, > > > whenever the CTTE decides that should happen. Whatever happens > > > (or > > > doesn't) to that patch/bug will not hold back the plan discussed > > > here. > > > > > > Do any of the Technical Committee members believe that this plan > > > does > > > not comply fully with their decision quoted above? > > > > > > Thank you! > > > > Status update: > > > > - piuparts is running and I am not aware of any issues found so far > > - usrmerge has been uploaded and has migrated to testing with the > > new > > flag and package > > - reportbug MR still waiting on review/merge > > - mmdebstrap has been updated and uploaded to unstable > > - debootstrap has been updated, uploaded to unstable, migrated to > > testing, uploaded to stable-backports > > > > Today I talked to the buildd team on IRC regarding the buildds. A > > preference was expressed for getting the new debootstrap via > > stable- > > updates rather than backports. Moreover, it was mentioned that > > there > > are still 11 buildd machines running on oldstable. > > > > So I have backported and tested the debootstrap change on top of > > the > > versions shipped in buster and bullseye, and filed p-u bugs: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016168 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016169 > > > > We are hoping these can make it in time for the next oldstable > > point > > release, which is scheduled for next week or so, before EOL. > > > > If we can't make it, then I will go back to the buildd team and > > propose > > to go via the stable-backports and oldstable-backports-sloppy > > routes. > > > > Once the buildds have the debootstrap changes deployed, then we > > will > > upload init-system-helpers with the usrmerge | usr-is-merged > > dependency. A notification about the transition will be sent to the > > debian-devel mailing list when that upload happens. > > Small update: > > The debootstrap changes are all uploaded to stable-p-u and oldstable- > p- > u and accepted for the next point releases. The point releases have > also been scheduled for September the 10th. > > So as soon the buildds have been updated to those point releases > after > the 10th, I will proceed with uploading init-system-helpers with the > new dependency.
Big update: with the new point releases done, it's a matter of hours/days until the buildds get the new debootstrap, so we are almost ready. In minutes I will upload to experimental a new version of init-system- helpers with the usrmerge | usr-is-merged dependency, so that we can do some last minute testing. I am travelling from tomorrow until Thursday, so I intend to do the upload to unstable and kick the transition into high gear sometimes around EOD on Thursday evening. A mail to debian-devel will be shortly sent with a notification today, and to debian-devel-announce on Thursday following the unstable upload. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
