Re: /usr-merge by default for new installations, with backwards compat
On Wed, Nov 28, 2018 at 03:03:20PM -0200, Andreas Hasenack wrote: > On Thu, Nov 8, 2018 at 9:22 AM Robie Basak wrote: > > I see that you blocked the SRU for debootstrap in LP: #1773496 / LP: > > #1800945 on a usr-merge problem. Please can you resolve this, given that > > you chose to drive this change in Ubuntu? I believe this is what is > > causing the sbuild autopkgtests in stable releases to fail - because > > distro-info-data now mismatches what debootstrap knows about. > Looks like this is blocking an SRU of mine: > https://bugs.launchpad.net/ubuntu/+source/exim4/+bug/1786508 > Verification was done on Oct 26th (~1 month ago). > DEP8 is clean except for sbuild/0.75.0-1ubuntu1: > http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#exim4 > This is the failure in sbuild's test: > autopkgtest [16:51:16]: test build-procenv: [--- > INFO: Creating sbuild chroot 'disco-amd64-sbuild' for release 'disco' > in directory '/tmp/autopkgtest.gqMpRP/autopkgtest_tmp/schroot-disco' > from url 'http://archive.ubuntu.com/ubuntu' > mkdir /tmp/autopkgtest.gqMpRP/autopkgtest_tmp/schroot-disco > E: No such script: /usr/share/debootstrap/scripts/disco > E: Error running debootstrap at /usr/sbin/sbuild-createchroot line 274. In such circumstances, it's legitimate to either ask the SRU team to hint the sbuild autopkgtests as bad (since this is not a regression introduced by exim4, but is reproducible in the release pocket) or to retrigger the tests in such a way that the -proposed debootstrap is also pulled in, getting a passing test. I've done the latter now: retry-autopkgtest-regressions --series bionic --blocks exim4 \ | sed -e's,$,\=debootstrap/1.0.95ubuntu0.3,' \ | xargs -rn1 -P10 wget --load-cookies ~/.cache/autopkgtest.cookie -O- retry-autopkgtest-regressions is from lp:ubuntu-archive-tools. This should clear the test blockage for the exim4 SRU. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: /usr-merge by default for new installations, with backwards compat
On Wed, Nov 28, 2018 at 3:03 PM Andreas Hasenack wrote: > DEP8 is clean except for sbuild/0.75.0-1ubuntu1: > http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#exim4 > > This is the failure in sbuild's test: > autopkgtest [16:51:16]: test build-procenv: [--- > INFO: Creating sbuild chroot 'disco-amd64-sbuild' for release 'disco' > in directory '/tmp/autopkgtest.gqMpRP/autopkgtest_tmp/schroot-disco' > from url 'http://archive.ubuntu.com/ubuntu' > mkdir /tmp/autopkgtest.gqMpRP/autopkgtest_tmp/schroot-disco > E: No such script: /usr/share/debootstrap/scripts/disco > E: Error running debootstrap at /usr/sbin/sbuild-createchroot line 274. Just confirmed that with debootstrap from bionic-proposed (https://launchpad.net/ubuntu/+source/debootstrap/1.0.95ubuntu0.3) the sbuild dep8 tests pass. Maybe all we need is the ubuntu0.2 release, which creates the disco symlink. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: /usr-merge by default for new installations, with backwards compat
On Thu, Nov 8, 2018 at 9:22 AM Robie Basak wrote: > > Hi Dimitri, > > I see that you blocked the SRU for debootstrap in LP: #1773496 / LP: > #1800945 on a usr-merge problem. Please can you resolve this, given that > you chose to drive this change in Ubuntu? I believe this is what is > causing the sbuild autopkgtests in stable releases to fail - because > distro-info-data now mismatches what debootstrap knows about. > Looks like this is blocking an SRU of mine: https://bugs.launchpad.net/ubuntu/+source/exim4/+bug/1786508 Verification was done on Oct 26th (~1 month ago). DEP8 is clean except for sbuild/0.75.0-1ubuntu1: http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#exim4 This is the failure in sbuild's test: autopkgtest [16:51:16]: test build-procenv: [--- INFO: Creating sbuild chroot 'disco-amd64-sbuild' for release 'disco' in directory '/tmp/autopkgtest.gqMpRP/autopkgtest_tmp/schroot-disco' from url 'http://archive.ubuntu.com/ubuntu' mkdir /tmp/autopkgtest.gqMpRP/autopkgtest_tmp/schroot-disco E: No such script: /usr/share/debootstrap/scripts/disco E: Error running debootstrap at /usr/sbin/sbuild-createchroot line 274. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: /usr-merge by default for new installations, with backwards compat
Hi Dimitri, I see that you blocked the SRU for debootstrap in LP: #1773496 / LP: #1800945 on a usr-merge problem. Please can you resolve this, given that you chose to drive this change in Ubuntu? I believe this is what is causing the sbuild autopkgtests in stable releases to fail - because distro-info-data now mismatches what debootstrap knows about. Alternatively, can we just land the debootstrap SRUs anyway? Given that users release upgrading won't be converted to usr-merge anyway and we have to support that, I don't see it being much of a problem if users running debootstrap for Disco while running Bionic also get non-usr-merge. Perhaps it would even be a good thing to get better dogfooding coverage on both supported combinations. Thanks, Robie signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: /usr-merge by default for new installations, with backwards compat
On 24 July 2018 at 01:06, Seth Arnold wrote: > On Mon, Jul 23, 2018 at 01:41:03PM +0100, Dimitri John Ledkov wrote: >> In the Ubuntu Archive in cosmic all / vs /usr conflicts are resolved, > > AppArmor profiles need to be adjusted: > https://gitlab.com/apparmor/apparmor/issues/8 > Yes, I was planning to verify these. Note that we are only planning to perform / & /usr merge, all binaries will remain the same w.r.t. bin -vs- sbin locations. Thus in practice only /bin and /sbin things need to be verified in the profiles to correctly take into account optional /usr prefix. This should be a smaller subset of binaries I hope. -- Regards, Dimitri. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: /usr-merge by default for new installations, with backwards compat
On Mon, Jul 23, 2018 at 01:41:03PM +0100, Dimitri John Ledkov wrote: > In the Ubuntu Archive in cosmic all / vs /usr conflicts are resolved, AppArmor profiles need to be adjusted: https://gitlab.com/apparmor/apparmor/issues/8 Thanks signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: /usr-merge by default for new installations, with backwards compat
On 23 July 2018 at 13:47, Robie Basak wrote: > Hi Dimitri, > > On Mon, Jul 23, 2018 at 01:41:03PM +0100, Dimitri John Ledkov wrote: >> Going forward, I believe, it is useful to enable usr-merge by default >> on new installs, without forcing migration of existing installations >> and continue to support split-usr systems. It will enable our users to >> use their systems in more innovative ways, and reduce the amount of >> any accidental /-vs-/usr mistakes and incompatibilities in the >> archive, and among third-party software. > > Could you please fill us in on Debian's position and status on this? How > much delta do we or would we have to maintain, and how much pain is > there in this maintenance? The changes are in per-distro scripts in debootstrap. And the Ubuntu ones are synced into Debian on regular basis (once we announce our codenames and/or sync back our changes), thus in practice deltas are short-lived and folded back into Debian uploads of debootstrap. Some of the conflicts in Cosmic have been resolved differently to Debian, thus there are only a small number of packages with different breaks versions / paths to debian, e.g. usrmerge package being the largest delta - which is still very small. Currently, Debian has --merged-usr enabled by default in unstable and testing. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839046 uploaded in 1.0.102, full current changelog at https://tracker.debian.org/media/packages/d/debootstrap/changelog-1.0.106 -- Regards, Dimitri. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: /usr-merge by default for new installations, with backwards compat
Hi Dimitri, On Mon, Jul 23, 2018 at 01:41:03PM +0100, Dimitri John Ledkov wrote: > Going forward, I believe, it is useful to enable usr-merge by default > on new installs, without forcing migration of existing installations > and continue to support split-usr systems. It will enable our users to > use their systems in more innovative ways, and reduce the amount of > any accidental /-vs-/usr mistakes and incompatibilities in the > archive, and among third-party software. Could you please fill us in on Debian's position and status on this? How much delta do we or would we have to maintain, and how much pain is there in this maintenance? signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
/usr-merge by default for new installations, with backwards compat
Over the past year, there have been multiple times when I had to fix scripts / exec calls to account for split-usr and usr-merged systems by patching constants or adding configuration checks to detect if certain binaries need to be called from /usr or /. At the same time, I find certain properties of usr-merged systems attractive. For example, the fact that all the packaged managed stuff is scoped in /usr is very convenient, for deduplication, sharing, snapshotting, including/excluding said dir in configs for diffs & backups. Ability to call any binary using /bin and /sbin prefixes is very cute too. Our initrd implementation has been fixed for a while to mount both / and /usr before executing init. Going forward, I believe, it is useful to enable usr-merge by default on new installs, without forcing migration of existing installations and continue to support split-usr systems. It will enable our users to use their systems in more innovative ways, and reduce the amount of any accidental /-vs-/usr mistakes and incompatibilities in the archive, and among third-party software. In the Ubuntu Archive in cosmic all / vs /usr conflicts are resolved, initrd by default mounts /usr (if it is separate), and debootstrap/dpkg have support to create usr-merged systems and ensure conflicting binaries are prevented from installation. Therefore next week, I would like to start the upload of debootstrap to switch cosmic to have merged-usr by default for new installations only. This will then include desktop / server / cloud / container installations and images as well. Existing installations will not be forced to merge /usr, but can opt into doing so by installing usrmerge package. /usr-merged installations with /usr as a seperate mountpoints will continue to be supported, as long as they boot with initrd which does mount both / and /usr - this is already the case with default Ubuntu for a few releases now. Overall the scope of changes is very small, simply /bin becomes a symlink to /usr/bin (and a few other paths, in a similar fashion) with everything still available and working via any path prefix. -- Regards, Dimitri. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
