[00:05] <xevious> nacc: It only completes if I start an nspawn container and then run `dpkg --configure -a` at the bash prompt launched in the container.
[00:06] <xevious> nacc: If I directly run dpkg in the container (not manually from a shell inside the container), it doesn't complete.
[00:06] <xevious> I'll continue investigating it tomorrow.
[00:09] <nacc> xevious: strange
[00:49] <jbicha> bdmurray: could you push your changes to lp:software-properties ?
[00:50] <bdmurray> jbicha: yep, doing so
[01:06] <jbicha> slangasek: I'm updating software-properties-gtk & update-manager's dependency from libgtk2-perl to libggtk3-perl for debconf. Why is it only a recommends?
[01:23] <jbicha> slangasek: based on the test case from LP: #1679784, I'm going to bump it to Depends unless you object…
[01:24] <jbicha> apt gets in this neat inconsistent state while waiting for a debconf answer it will never get
[01:24] <jbicha> oh I guess it's only stuck until I close the app but still…
[01:28] <jbicha> slangasek: also please remove ubuntu-font-family-sources from bionic (replaced by fonts-ubuntu)
[02:20] <slangasek> jbicha: I don't recall a reason why libgtk2-perl is a Recommends instead of a Depends.  It's possible it's because that's what the package relationship had been previously.  But how does updating to libgtk3-perl work?  Is there now a gtk3-based debconf frontend?
[02:22] <jbicha> slangasek: https://launchpad.net/ubuntu/+source/debconf/1.5.66
[02:23] <jbicha> https://salsa.debian.org/pkg-debconf/debconf/commit/0250616b
[02:27] <slangasek> well, huzzah!
[02:35] <nacc> sigh, i'm pretty close to asking for a full on revert of the snapcraft SRU
[03:26] <Unit193> bdmurray: Hi.  Regarding LP #1693032...This reeeally doesn't do jack for us on Xubuntu, nor any other flavor than gnome.  Last year in May you talked with wxl and I about solutions for this in Xubuntu and Lubuntu, I had remarked about xfce4-session-logout (and I don't remember what Lubuntu had)  whatever happened to less hardcoding to GNOME? :/
[07:27] <flocculant> slangasek xnox - seb128 said you've be the best people to mention this too - grub looking horrendous - bug 1748028 has a hardware video of what I see and also a vm - seeing this reported elsewhere by others too
[07:27] <slangasek> flocculant: that looks like a duplicate of the other bug report that has just been tagged regression-update
[07:29] <flocculant> slangasek: aah - cool, I'll mark my old one as a dupe then
[07:30] <flocculant> didn't think about tagging it regression-update
[07:45] <rbasak> powersj, nacc: bug 1752215: the test needs updating (intentional in MySQL). Do we have a place to assign the bug?
[08:13] <seb128> slangasek, btw we didn't "nack" net-cpp or url-dispatcher removels, just indicators ones (which are still using by the unity session which is now community maintained)
[08:14] <slangasek> seb128: well, they're dependencies of the indicators; how can we unpick this?
[08:15] <seb128> slangasek, somebody needs to make the indicators not use them I guess? those depends are not useful under xorg/unity7
[08:15] <seb128> I guess "needs work"
[08:15] <seb128> unsure how much that is though, but probably not something we can invest much into atm
[08:15] <slangasek> right, so who is that somebody :)  if nobody does the work, the libs and their reverse-depends need to be removed
[08:16] <seb128> there is a new group of people who picked up unity
[08:16] <seb128> I guess talk to them
[08:16] <seb128> and tell them you are going to delete their work now if they don't fix your problem :p
[08:17] <Unit193> sforshee: Thanks for the patch on nvidia 304, I'll use it myself at least. :)
[08:17] <Unit193> I don't suppose there's a hard push to get everything with openssl 1.1 for Bionic?
[08:19] <seb128> slangasek, I'm going to have a look today to see if it's easy to drop the depends, if it's not I guess it's up to the unity team
[08:19] <slangasek> Unit193: as much as possible; we know there will be a couple of packages still in main using openssl 1.0
[08:20] <Unit193> openssh, right.
[08:20] <slangasek> seb128: ok, thanks.  what's the best way to flag that to the unity team?  other than just filing bug tasks
[08:20] <seb128> slangasek, anyway, desktop team own that problem and isn't objecting to remove indicators if you think that's the right way to go
[08:21] <Unit193> slangasek: Package in universe, it's pretty simple but wasn't sure if anyone would be interested.   https://salsa.debian.org/takaki/gvpe/merge_requests/1
[08:21] <seb128> slangasek, they use https://community.ubuntu.com/c/desktop/ubuntu-unity-dev I think, otherwise jbicha knows who to ping in their team
[08:21] <seb128> slangasek, sorry, "desktop team *doesn't* own that problem"
[08:22] <slangasek> seb128: well, it definitely needs to be fixed or removed soon for 18.04 because of the entanglement with curl
[08:22] <seb128> k, well as far as I'm concerned you can remove indicators&unity, I just think it would be a shame and a bad step community wise
[08:23] <seb128> anyway
[08:23] <seb128> slangasek, let me have a look today to the indicators and ping the unity people and I let you know where we stand
[08:23] <slangasek> seb128: sounds good, thanks
[08:23] <seb128> np!
[10:11] <TJ-> I'm hacking on update-manager (ubuntu-support-status). Is there a recommended way, possibly pythonic, to get the currently running package architecture, even where possibly it's a 32-bit install on a 64-bit kernel, e.g. without shelling out to do 'dpkg --print-architecture'  ?
[10:18] <cjwatson> TJ-: I'd ask python-apt for it: import apt_pkg; apt_pkg.init(); apt_pkg.config['APT::Architecture']
[10:19] <cjwatson> TJ-: (ubuntu-support-status already imports apt, which does the apt_pkg.init() bit implicitly, so you don't need that bit)
[10:21] <TJ-> cjwatson: Yes, thanks, I hadn't spotted that. Makes the job much easier
[10:22] <sladen> frozen planet.  frozen bionic
[11:45] <Unit193> sarnold: Hello, looks like Irssi hasn't been patched for the latest CVEs, is this on your tracker?  Would you be interested in reviewing and sponsoring the bugfix instead?
[11:52] <xnox> slangasek, demote them to -proposed, rather than remove? add block-proposed, let curl migrate, keep them uninstallable in -proposed?
[11:54] <xnox> Unit193, well, we are down to just 95 packages using openssl1.0, and I hope at least 4 more will get fixed up, so 91. Getting the number lower would be awesome.
[11:55] <xnox> smoser, rharper - check this out, resolvconf compat interface for systemd resolved => https://github.com/systemd/systemd/pull/8296/files
[11:55] <Unit193> Last 3 patches above S-V bump in that merge would fix 1. openssl compatibilty. 2. Ftbfs.
[11:56] <Unit193> (Trying to get it in Debian.)
[13:06] <smoser> coccinellication.  thats a word ?
[13:09] <smoser> xnox: what "use resolvconf state in the initramfs and hope that it will be transfered into the root filesystem" ?
[13:09] <smoser> i'm not aware of anything.
[13:10] <xnox> smoser, there are some, maybe it's not popular anymore.
[13:10] <smoser> in fact bug 1714308 pretty well guarantees they didn't do it well
[13:11] <xnox> smoser, huh? "they"? above is a pull request, which is yet to be merged upstream to provide a compatible /sbin/resolvconf -u
[13:11] <smoser> right
[13:11] <smoser> you said in that pull request that some things "use resolvconf state in the initramfs and hope that it will be transferred into the root filesystem"
[13:11] <smoser> and i dont know of anythings that do that.
[13:12] <smoser> nor do i think they would work
[13:12] <xnox> why not?
[13:12] <smoser> well maybe the "transfer" part might work
[13:12] <smoser> but dns didn't work in the initramfs until bionic
[13:12] <xnox> resolvconf parses input on the stdin, and then sanitises it, and dumps it to /run/resolvconf/interface/$IFACE as if.
[13:12] <smoser> so configuring resolvconf was clearly not on anyone's high priority
[13:12] <xnox> hehehe
[13:13] <xnox> smoser, but it does work in trusty/xenial? maybe nobody uses itermediate releases
[13:13] <smoser> no
[13:13] <smoser> to my knowledge we've never had working initramfs dns
[13:13] <smoser> not in "stock"
[13:13] <smoser> maybe trusty
[14:16] <alexarnaud> Hello all
[14:16] <alexarnaud> Can I forward a bugupstream on Launchdpad ?
[14:17] <alexarnaud> https://bugs.launchpad.net/ubuntu-mate/+bug/1618723 is the result of https://github.com/mate-desktop/marco/issues/118#issuecomment-355697924
[14:17] <alexarnaud> I would like to help on bugs related to accessibility.
[14:18] <alexarnaud> This bug has been fixed upstream, what is the process to mark it as resolved ? https://bugs.launchpad.net/ubuntu-mate/+bug/1618642
[14:26] <alkisg> alexarnaud: this is mostly a channel for ubuntu developers, while for users questions it's #ubuntu-mate and #ubuntu...
[14:26] <alexarnaud> alkisg: It's not usage question, it's question about the bugtracker, is there a QA channel maybe?
[14:27] <alkisg> alexarnaud: try the channels I linked, I think you'll have better chances to get a responce
[14:27] <alkisg> bug management is part of user support offered there
[14:28] <alkisg> In general, you don't need to file each upstream bug to launchpad as well,
[14:28] <alkisg> and you'd only mark it as "fix released" once the release lands in the development version of ubuntu
[14:29] <alexarnaud> alkisg: It's already the case since 17.04 or 17.10.
[14:29] <alkisg> Nice, then you can just close it
[14:29] <alexarnaud> alkisg: thanks for your help
[14:30] <alkisg> You're welcome
[14:56] <xevious> This mysql-server issue is especially weird.
[14:56] <xevious> I'm running a few more tests before posting an update to the ticket.
[15:14] <sunweaver> hi!
[15:15] <sunweaver> I would like to test ubuntu-desktop in a nested Xserver.
[15:15] <sunweaver> my setup...
[15:15] <sunweaver> a bionic-amd64 chroot with ubuntu-desktop meta package installed.
[15:15] <sunweaver> a nested Xserver launched with "nxagent -ac :1"
[15:15] <sunweaver> in the chroot, I do: export DISPLAY=:1
[15:15] <sunweaver> GNOME_SHELL_SESSION_MODE=ubuntu STARTUP="gnome-session --session=ubuntu" dbus-run-session /etc/X11/Xsession
[15:16] <sunweaver> with that, I get complaints, that the system-wide DBus instance is not running.
[15:16] <sunweaver> with other desktop envs, esp. on Debian, I can test a desktop from a chroot with that setup.
[15:16] <sunweaver> Any hint, how this can be done in Ubuntu?
[15:18] <rbasak> xevious: I commented on the bug. I'm not sure this is a bug in mysql-5.7 packaging though. What's the postinst doing wrong that breaks nspawn?
[15:19] <xevious> rbasak: It behaves differently depending on how you run it.
[15:19] <xevious> If you do the installation as a parameter of `systemd-nspawn` it'll fail.
[15:19] <xevious> If you log into the contain and run the installation from the bash prompt, it'll succeed.
[15:19] <xevious> Here's the REALLY weird thing I discovered a little while ago..
[15:20] <xevious> If you do the `apt install` as a parameter of `systemd-nspawn`, but add `dpkg --configure -a` after the `apt` command, it succeeds.
[15:20] <rbasak> xevious: given what nspawn does, it seems more likely to either be by-design behaviour from nspawn, or a bug in nspawn, no?
[15:21] <xevious> This worked fine on mysql-server-5.7 5.7.20-1ubuntu1, though.
[15:21] <xevious> It only broke with the new mysql-server package.
[15:21] <xevious> rbasak: I'm about to post some more steps to reproduce. If you could try them out, I'd appreciate it.
[15:22] <xevious> The weird thing about adding `dpkg --configure -a` is that the `apt install` doesn't fail any more: it succeeds and `dpkg --configure -a` doesn't have to do anything.
[15:23] <xevious> Without that, it fails.
[15:23] <xevious> I've only tried adding `dpkg --configure -a`. Since it doesn't appear to actually be doing anything, I'm trying an arbitrary command (`ls`) to see what that does.
[15:24] <rbasak> xevious: as I (just) described in the bug, we've changed how the postinst starts the server internally for upgrade purposes.
[15:24] <rbasak> xevious: so I can understand that this might break some use case that's less tolerant of how the postinst does that.
[15:25] <rbasak> xevious: this doesn't necessarily make it a bug in mysql-server-5.7.postinst though, even if it is a regression in behaviour.
[15:25] <xevious> Please try the steps in the comment I just posted.
[15:26] <rbasak> xevious: why? Can you not try it yourself in a VM to verify the steps?
[15:26] <xevious> I have numerous times
[15:27] <xevious> I just posted a comment
[15:27] <xevious> New steps
[15:27] <rbasak> Can you find steps to reproduce that don't rely on nspawn?
[15:28] <rbasak> If it reproduces for you in a fresh VM with nspawn, I honestly don't see what I can add by confirming it.
[15:29]  * rbasak will be back later
[15:34] <xevious> rbasak: I think I found a solution. Testing further...
[16:09] <lool> xnox: hey! is there some email explaining the way the deputy systemd is supposed to work on 14.04?
[16:09] <lool> xnox: I have a 14.04 system (with snapd, which pulled deputy systemd) but the certbot cron thinks systemd is init and disables itself; however the systemd timer for certbot doesn't work with a weird error
[16:10] <lool> I'm trying to understand if certbot systemd timer is supposed to work or if I should change the cron to detect system-systemd-active-but-not-pid-1
[16:14] <xnox> lool, i am happy to SRU "change the cron to detect system-systemd-active-but-not-pid-1" into trusty.
[16:14] <xnox> lool, please open a bug and subscribe me?
[16:15] <lool> xnox: if you mean change certbot, it's a PPA package – might also affect the released one if any
[16:15] <xnox> lool, basically, on trusty, one should assume pid1 is upstart; by hard-coding it; unless one is inside the snap, then assume pid1 is systemd.
[16:15] <lool> I'm happy to contact Ondrej@Debian to change the cron
[16:15] <xnox> lool, yeah, so if building/running on trusty, assume upstart-only, unfortunately.
[16:16]  * xnox checks calendar, *sigh* trusty is not dead yet
[16:16] <lool> xnox: Ok; he's backporting the package with just a rebuild and no source changes ATM
[16:16] <lool> I'll try to suggest something smart to do
[16:16] <lool> perhaps check which init /proc/1 actually is
[16:16] <rbasak> lool, xnox: https://lists.ubuntu.com/archives/ubuntu-devel/2017-December/040100.html
[16:16] <rbasak> It'd be worth making a list of these I think.
[16:17] <rbasak> Basically it's fallout from the SRU regression.
[16:17] <lool> ah right, remember that thread now
[16:17]  * rbasak disappears again
[16:18] <lool> rbasak: thanks!
[16:18] <lool> deputy systemd is a bit of an evil mode   :-/
[16:18] <lool> the jobs are all listed as failed etc
[16:19] <lool> anyway, will go back to Ondrej to update certbot packaging
[16:20] <xnox> lool, i recommending opening with "some trusty systems suffer from split personality disorder w.r.t. init system in charge, when snapd is also installed"
[16:23] <lool> Yep, exactly
[17:17] <xevious> rbasak: I found a solution (mentioned in the comment I just put on the ticket). Should I close it as "Invalid" or do you want to close it as "Won't fix"?
[17:20] <xevious> I figure "Invalid" applies.
[17:21] <xevious> It was effectively a support request, after I explored the issue further: I just needed to add an option to systemd-nspawn.
[18:54] <xevious> System UIDs and GIDs are carefully managed by a Debian or Ubuntu team, right?
[18:56] <xevious> E.G. the mysql UID and GID shouldn't have changed between mysql-server-5.7 5.7.20-1ubuntu1 and mysql-server-5.7 5.7.21-1ubuntu1, right?
[18:59] <xevious> Looks like the new mysql-sever-5.7 package decremented them by 1: https://paste.ubuntu.com/p/WC8WrnwwfC/
[19:01] <alkisg> aren't those randomly selected on postinst?
[19:01] <mdeslaur> they're randomly assigned, yes
[19:02] <mdeslaur> xevious: there's no expectation that it wouldn't change in two different installs
[19:03] <xevious> I see. It's just 0-99 that are statically assigned.
[19:09] <tsimonq2> rbasak, bdmurray: For the sake of not letting the process stall, how is my Qt 5 Uploaders app?
[19:15] <rbasak> tsimonq2: I've not looked again yet, sorry. A bunch of Canonical people are sprinting next week, so it may not conclude until after that.
[19:16] <tsimonq2> rbasak: ack, but it would be good to get responses from non-Canonical people then :)
[19:18] <cjwatson> xevious: 0-99 and 60000-64999 (see https://www.debian.org/doc/debian-policy/#uid-and-gid-classes)
[19:18] <xevious> cjwatson: Thanks! I also reviewed the Ubuntu Policy page about UIDs/GIDs. I'm surprised this hasn't gotten me sooner.
[19:19] <cjwatson> I'm the base-passwd maintainer, so I kind of have to know this ;-)
[19:19] <xevious> I'm adapting my imaging process to create the mysql user/group prior to installing it to ensure that it's always got the same UID/GID.
[19:20] <cjwatson> (>15 years now; I should probably look for a co-maintainer at some point)
[19:20] <xevious> Currently, mysql is refusing to start because all of the files in /var/lib/mysql are owned by epmd.
[19:20] <cjwatson> Right, if you're dropping in files created on another system then you often need to make sure IDs are synced up.
[21:11] <TJ-> Is the ubuntu-bugcontrol team no longer dealing with applications? I send a re-join message Nov 9th which I've had no reply to and checking the public archive don't see it, and don't see anything posted there since 22nd Jan. I've just re-sent my application and confirmed on my email server it was delivered (in case of an original delivery failure)
[23:03] <andersk> Can someone request a rebuild of openafs?  It will work now that a flex regression has been fixed.  (LP #1752388)
[23:58] <nacc> slangasek: trying to package a new lib and seeing the installed files end up in debian/tmp/usr/lib instead of debian/tmp/usr/lib/x86_64-linux-gnu -- what am i missing?
[23:59] <nacc> (it's using pkg-config)
[23:59] <slangasek> nacc: debhelper compat level?