Re: Upcoming transitions
On 04.12.18 18:41, Robie Basak wrote: > I'm planning to start transitions for PHP and MySQL soon, with the first > uploads in the next day or two. If it would be better to wait, please > let me know. > > I'll detail the plan with PHP in a reply to Jeremy's email as soon as > we've confirmed it'll work. please coordinate with the desktop team and the poppler transition which is still in progress, started 12 days ago. Matthias -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Changing $PATH for apt installs
On Tue, Dec 04, 2018 at 03:26:05PM -0600, Jamie Strandboge wrote: > On Tue, 04 Dec 2018, Julian Andres Klode wrote: > > > Hi folks, > > > > I'm planning to have apt set PATH to a sane value for running > > dpkg, so that maintainer scripts are executed in a sanitized > > environment. That value will be: > > > > PATH=/usr/sbin:/usr/bin:/sbin:/bin > > > > The effect: > > > > (1) There is no /usr/local, which prevents breakage from custom perl > > or python installation > > > > (2) /snap/bin is not included either. This means that packages migrating > > to snaps will have to provide compatibility links (scripts?) in /usr > > - IIRC, lxd already does so, I'm not sure about other libraries. > > > I'm generally in favor of the change, but AFAICS, lxd does *not* do anything > with compatibility symlinks (it uses snap aliases instead, which live in > /snap/bin). lxd may have done this in the past (I vaguely remember something > about that), but snaps shouldn't be doing this and in fact, strict mode snaps > typically cannot (only lxd and a couple of other super-privileged snaps happen > to be able to, but that is considered bad form). As for deb-to-snap > migrations, > that still isn't well defined (again, lxd has the ability to do whatever it > wants where most snaps cannot). I mean the .deb packages depending on snapd and installing the snap in the pre(?)inst, like the lxd one in the archive: jak@jak-t480s:/tmp$ apt download lxd Get:1 file:/etc/apt/mirrors.list Mirrorlist [226 B] Get:2 http://de1.archive.ubuntu.com/ubuntu disco/main amd64 lxd all 1:0.4 [11,1 kB] Fetched 11,1 kB in 0s (81,5 kB/s) jak@jak-t480s:/tmp$ dpkg -c lxd_1%3a0.4_all.deb | grep usr/bin drwxr-xr-x root/root 0 2018-10-10 18:28 ./usr/bin/ -rwxr-xr-x root/root34 2018-09-12 22:09 ./usr/bin/lxc -rwxr-xr-x root/root34 2018-09-12 22:09 ./usr/bin/lxd -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en 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: Changing $PATH for apt installs
On Tue, 04 Dec 2018, Julian Andres Klode wrote: > Hi folks, > > I'm planning to have apt set PATH to a sane value for running > dpkg, so that maintainer scripts are executed in a sanitized > environment. That value will be: > > PATH=/usr/sbin:/usr/bin:/sbin:/bin > > The effect: > > (1) There is no /usr/local, which prevents breakage from custom perl > or python installation > > (2) /snap/bin is not included either. This means that packages migrating > to snaps will have to provide compatibility links (scripts?) in /usr > - IIRC, lxd already does so, I'm not sure about other libraries. > I'm generally in favor of the change, but AFAICS, lxd does *not* do anything with compatibility symlinks (it uses snap aliases instead, which live in /snap/bin). lxd may have done this in the past (I vaguely remember something about that), but snaps shouldn't be doing this and in fact, strict mode snaps typically cannot (only lxd and a couple of other super-privileged snaps happen to be able to, but that is considered bad form). As for deb-to-snap migrations, that still isn't well defined (again, lxd has the ability to do whatever it wants where most snaps cannot). That said, debs should always declare their dependencies and atm, debs can't declare a dependency on a snap. Therefore, including /snap/bin in the PATH is wrong since its possible that a deb is missing a dependency and sometimes finds it in /snap/bin. As such, +1 on the change. There might be things to reconsider depending on how we want to handle deb to snap migrations and especially deb dependencies on snaps (if that every becomes a thing), but that can wait until later. -- Jamie Strandboge | http://www.canonical.com 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
Changing $PATH for apt installs
Hi folks, I'm planning to have apt set PATH to a sane value for running dpkg, so that maintainer scripts are executed in a sanitized environment. That value will be: PATH=/usr/sbin:/usr/bin:/sbin:/bin The effect: (1) There is no /usr/local, which prevents breakage from custom perl or python installation (2) /snap/bin is not included either. This means that packages migrating to snaps will have to provide compatibility links (scripts?) in /usr - IIRC, lxd already does so, I'm not sure about other libraries. Together, this ensures that deb packages only talk to deb packages. Thanks, Julian -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Upcoming transitions
I'm planning to start transitions for PHP and MySQL soon, with the first uploads in the next day or two. If it would be better to wait, please let me know. I'll detail the plan with PHP in a reply to Jeremy's email as soon as we've confirmed it'll work. 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
samba 4.9 in disco
Hi, I just wanted to email the list explaining why samba 4.9 is not yet in disco. It's also blocking the ldb migration. The samba DEP8 tests pass, but one of the triggered tests (freeipa) actually showed what we think is a valid bug, or at least significant change in behavior, in samba[1]. Basically, in a fresh install, if you have winbind running, smbd won't start, even in standalone mode (not part of a domain). This happens in debian as well, fedora, and possibly suse. There are several mailing list threads[2,3,4] about it. The freeipa dep8 tests caught it by accident really. It's not even a failure in dep8 itself (the freeipa tests always exit 0, something else I found out), but in setting up the test vm. We can workaround that by just not installing the package that pulls in winbind. Freeipa doesn't need it. That's what this MP[5] proposes. That would let samba migrate, but the bug[1] will still have to be addressed. I think we should not migrate samba as-is until [1] is addressed, or at least until there is a plan on how to address it. I'm continuing the investigation, and I wanted to communicate that it's a known issue and it's being worked on. 1. https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1806035 2. https://lists.samba.org/archive/samba/2018-November/219540.html 3. https://lists.samba.org/archive/samba/2018-October/219059.html 4. https://lists.samba.org/archive/samba-technical/2018-September/130369.html 5. https://code.launchpad.net/~ahasenack/ubuntu/+source/freeipa/+git/freeipa/+merge/360062 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
