[11:39] <Saviq> Odd_Bloke: hey, re: minimal again, do you know if /dev/tty0 and friends are possible to re-enable at all?
[11:43] <Saviq> Odd_Bloke: just realized CONFIG_VT is disabled in there, so that probably says 'no'...
[12:28] <ahasenack> doko: hi, around? Do you recall what you were trying to fix with https://git.launchpad.net/ubuntu/+source/sssd/commit/?id=39e4993bf605d89aaa8aaafc562838ed3422d7ef ?
[12:28] <ahasenack> never mind the initscript, or the /usr/local bit, just the site-packages -> *-packages bit bit
[12:28] <ahasenack> the build works without it, and it's a delta we are carrying, I'm wondering if we still have to carry this delta
[12:29] <ahasenack> and the paths in the *.install files don't seem to mean much for what ends up in the package: https://pastebin.ubuntu.com/p/CBvNgDmp9d/
[12:40] <TJ-> ahasenack: did you see my replies last night after you left/
[12:40] <ahasenack> TJ-: yep
[12:43] <ginggs> ahasenack: see the build failures here https://launchpad.net/ubuntu/+source/sssd/1.16.1-1ubuntu2
[12:44] <ahasenack> so maybe dh-install or dh-python changed in cosmic since then?
[12:45] <ahasenack> but good to have a link now, thanks ginggs
[12:48] <ginggs> ahasenack: yw, i guess they could have changed.  maybe try rebuilding 1.16.1-1ubuntu2 now and see what happens
[12:49] <ahasenack> it worked, but let me try in a proper ppa, without universe, etc
[12:51] <ahasenack> TJ-: where did you see the bit about the cpython-36m in the module name? readme.rst?
[13:05] <TJ-> ahasenack: I think I grep-ed for it in the package
[13:25] <Odd_Bloke> Saviq: I don't know, no; could you file a bug that I can point some (hopefully) more knowledgeable people at?
[13:57] <rbasak> seb128: why did you remove the tag from bug 1606828? It does look like it should be Fix Released now though?
[13:57] <ubottu> bug 1606828 in bind9 (Ubuntu) "BIND Stable Version 9.10.4" [Wishlist,Triaged] https://launchpad.net/bugs/1606828
[13:58] <seb128> rbasak, because bionic has 9.11 so that's not an update needed
[13:59] <seb128> rbasak, but yeah, closing would work as well, I just wanted to get the bug out of one of our reports since it was boggus
[14:00] <rbasak> I see, OK. I favour Fix Released as that status line is for the development release, and it's done there now.
[14:00]  * rbasak does so
[14:03] <seb128> rbasak, wfm, I was unsure if 9.11 was a new version or serie and if the current version included all the fixes from 9.10.4 so I didn't want to take the decision to close it
[14:31] <jamespage> slangasek: I think the desire is to always test on the latest Ubuntu LTS which is ok - the primary gate would still be python 3.6, but if we can figure out a way to supply newer python versions (3.7, 3.8) onto 18.04, then we're less likely to see specific issues with those versions appearing as we move towards 20.04
[14:32] <jamespage> (context was python 3.7 in bionic)
[14:35] <TJ-> Could someone take a look at Bug #1686084 which affects Bionic, multiple users poked me about in IRC. Originally started in Zesty. Doesn't exist in Cosmic.
[14:35] <ubottu> bug 1686084 in x11vnc (Ubuntu) "x11vnc terminates with **stack smashing detected** error" [High,Confirmed] https://launchpad.net/bugs/1686084
[14:35] <kyrofa> Hey mvo, yesterday we tracked down why the armhf autopkgtest runner can't install snaps. Take a look at the profile being used: https://paste.ubuntu.com/p/W7VX2SB5Fr/
[14:35] <kyrofa> mvo, take note of the raw.lxc section
[14:37] <mvo> kyrofa: hm, hm, this indicates this should work I guess?
[14:37] <kyrofa> mvo, this profile works without the raw.lxc, and gives these types of errors when it's present: https://pastebin.ubuntu.com/p/mVBKB7ZSHn/
[14:38] <mvo> kyrofa: so if you make the profile *unrestricted* it gives you permission denied errors but if you use the default (which I assume is restricted) it works? did I get this right?
[14:38] <kyrofa> mvo, rather than change the profile (which according to git was done to make pbuilder useful), slangasek was hoping to learn what was missing to make snapd happy having more privilege
[14:40] <mvo> kyrofa: maybe stgraber can help? I find this deeply confusing. I don't know why it works with more confinement and stops working when unconfined
[14:41] <mvo> kyrofa: I will set it on the todo list to investigate though, I pressume htis is reproducible on x86 as well(?)
[14:42] <kyrofa> mvo, I haven't tried, I installed lxd from the 2.0 track on my rpi (that lxc.raw bit is invalid for 3.0, it seems)
[14:42] <kyrofa> That's how I was able to duplicate
[14:42] <kyrofa> But yes, I wouldn't be surprised
[14:43] <kyrofa> If it _doesn't_ break on x86 I'll be quite confused indeed :P
[14:43] <mvo> jdstrand: do you have any idea why lxd could start failing to install snaps with the setting:    lxc.aa_profile=unconfined
[14:43] <mvo> kyrofa: yeah, a "fun" problem - a deep rabithole
[14:44] <mvo> kyrofa: on the bright side, if we solve this, maybe we can even run our autopkgtests inside lxd in armhf :)
[14:46] <kyrofa> mvo, exactly! Would be very nice to solve
[14:47] <stgraber> because lxc.aa_profile=unconfined means that there is no apparmor at all so snapd in the container would modify the host's apparmor which also normally means we won't give the container cap_mac_admin/cap_mac_override
[14:47] <stgraber> what snapd needs is an apparmor namespace
[14:50] <mvo> stgraber: so we can fix this on our side? do we need to detect if we run inside an unconfined container
[14:51] <stgraber> mvo: you should be able to detect a lack of mac_admin/mac_override capabilities which would mean you can't interact with apparmor
[14:52] <mvo> stgraber: ok, so if we don't have mac_admin, what should we do then, can we create the apparmor namespace ourselfs (pardon my ignorance) or should we just display some sensible message
[14:54] <stgraber> nope, if you don't have mac_admin you won't be able to do anything apparmor-related
[14:54] <stgraber> so you could treat the system as if it had apparmor disabled
[14:55] <mvo> stgraber: that sounds sensible, let me try to figure out how to detect this
[15:02] <rbasak> seb128: that makes sense. I was looking at it from the opposite perspective of it being a general version bump request rather than for any specific bugs, which is why I tagged it. But either way it's gone now :)
[15:03] <seb128> rbasak, good :)
[15:07] <kyrofa> mvo, that would be excellent, please let me know if I can help test, my rpi is still setup
[15:08] <mvo> kyrofa: still trying to figure that out
[18:15] <kyrofa> I've gotten a few autopkgtest failures today that I can't quite reason out, can I get some help? Here's an example: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-snapcraft-daily/xenial/amd64/s/snapcraft/20180808_180049_8e0aa@/log.gz
[18:16] <kyrofa> The pkgProblemResolver bit seemed odd
[18:17] <kyrofa> I thought maybe it was temporary archive flux, but it's happened twice now
[18:26]  * jdstrand reads backscroll and see that the conversation resolved itself
[18:26] <jdstrand> sees*
[20:23] <infinity> GunnarHj: Ah-ha.  Found why I can validate and you can't. :P
[20:24] <infinity> GunnarHj: My package works on upgrade from xenial to bionic-proposed.  However, if you upgrade to bionic in between, then delete XKBOPTIONS from the config file, the upgrade to bionic-proposed, it pulls options from debconf.  Fixing.
[20:46] <GunnarHj> infinity: Great, thanks!
[20:47] <infinity> GunnarHj: Well, fixing when I wrap my head around it.  For the record, this bug has existed forever, it's just that until now (I guess) no one hand-edited /etc/default/keyboard, deleted XKBOPTIONS, and expected that to work. :P
[20:47] <infinity> GunnarHj: The problem is that we load all the options from debconf, then overwrite them by sourcing /etc/default/keyboard
[20:48] <infinity> GunnarHj: So, if XKBOPTIONS is gone entirely, instead of registering that as "the user has no xkboptions", we still have the old debconf answers.
[20:48] <infinity> GunnarHj: Which means, I guess, I need to replace sourcing the file with an actual file parser that treats missing vars as empty.
[20:49] <infinity> (ick)
[20:54] <GunnarHj> infinity: I agree on your background description. The increased importance of the issue is the combination of the GNOME behavior and the fact that GNOME is now the default desktop.
[20:55] <GunnarHj> infinity: GNOME and Debian don't play well together in this respect.
[20:56] <infinity> GunnarHj: Yeah, whatever file parsing madness I come up with here, I'll push to Debian too.  It's clearly a bug that we're ignoring user preferences in the case of deleted vars.
[20:56] <infinity> GunnarHj: It's just that, I suspect, no one really noticed until now.
=== mnepton is now known as mneptok
=== michagogo_ is now known as michagogo
[23:18] <mwhudson> infinity: so i got assigned this bug https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1777900 -- without thinking about it at all hard do you have any intuition where the problem might be?
[23:18] <ubottu> Launchpad bug 1777900 in ubiquity (Ubuntu) "oem-config breaks the systemd resolved link for /etc/resolv.conf in 18.04 server " [Undecided,Confirmed]
[23:20] <infinity> ubiquity$ rgrep -l resolv\.conf | egrep -v '^debian|^d-i'
[23:20] <infinity> bin/oem-config-remaster
[23:20] <infinity> scripts/plugininstall.py
[23:20] <infinity> mwhudson: ^--- I'd guess one of those two files. :P
[23:21] <mwhudson> heh
[23:21] <mwhudson> i think oem-config-remaster is ancient cruft
[23:22] <infinity> It seems so.
[23:22] <infinity> And the pluginstall bit starts with:
[23:22] <infinity>         if self.target != '/':
[23:22] <infinity>             for path in ('/etc/network/interfaces', '/etc/resolv.conf'):
[23:23] <infinity> Which means it shouldn't run during oem-config.
[23:23] <infinity> But maybe that's the very problem.
[23:23] <mwhudson> i think i'm going to mark /etc/resolv.conf immutable before running oem-config and see what breaks
[23:25] <mwhudson> which might not be terribly revealing but maybe worth a go