| Saviq | Odd_Bloke: hey, re: minimal again, do you know if /dev/tty0 and friends are possible to re-enable at all? | 11:39 |
|---|---|---|
| Saviq | Odd_Bloke: just realized CONFIG_VT is disabled in there, so that probably says 'no'... | 11:43 |
| 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:28 |
| 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:29 |
| TJ- | ahasenack: did you see my replies last night after you left/ | 12:40 |
| ahasenack | TJ-: yep | 12:40 |
| ginggs | ahasenack: see the build failures here https://launchpad.net/ubuntu/+source/sssd/1.16.1-1ubuntu2 | 12:43 |
| ahasenack | so maybe dh-install or dh-python changed in cosmic since then? | 12:44 |
| ahasenack | but good to have a link now, thanks ginggs | 12:45 |
| ginggs | ahasenack: yw, i guess they could have changed. maybe try rebuilding 1.16.1-1ubuntu2 now and see what happens | 12:48 |
| ahasenack | it worked, but let me try in a proper ppa, without universe, etc | 12:49 |
| ahasenack | TJ-: where did you see the bit about the cpython-36m in the module name? readme.rst? | 12:51 |
| TJ- | ahasenack: I think I grep-ed for it in the package | 13:05 |
| Odd_Bloke | Saviq: I don't know, no; could you file a bug that I can point some (hopefully) more knowledgeable people at? | 13:25 |
| 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:57 |
| seb128 | rbasak, because bionic has 9.11 so that's not an update needed | 13:58 |
| 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 | 13:59 |
| 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:00 | |
| 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:03 |
| 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:31 |
| jamespage | (context was python 3.7 in bionic) | 14:32 |
| 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:35 |
| 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:37 |
| 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:38 |
| 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:40 |
| mvo | kyrofa: I will set it on the todo list to investigate though, I pressume htis is reproducible on x86 as well(?) | 14:41 |
| 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:42 |
| 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:43 |
| mvo | kyrofa: on the bright side, if we solve this, maybe we can even run our autopkgtests inside lxd in armhf :) | 14:44 |
| kyrofa | mvo, exactly! Would be very nice to solve | 14:46 |
| 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:47 |
| mvo | stgraber: so we can fix this on our side? do we need to detect if we run inside an unconfined container | 14:50 |
| 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:51 |
| 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:52 |
| 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:54 |
| mvo | stgraber: that sounds sensible, let me try to figure out how to detect this | 14:55 |
| 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:02 |
| seb128 | rbasak, good :) | 15:03 |
| kyrofa | mvo, that would be excellent, please let me know if I can help test, my rpi is still setup | 15:07 |
| mvo | kyrofa: still trying to figure that out | 15:08 |
| 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:15 |
| kyrofa | The pkgProblemResolver bit seemed odd | 18:16 |
| kyrofa | I thought maybe it was temporary archive flux, but it's happened twice now | 18:17 |
| * jdstrand reads backscroll and see that the conversation resolved itself | 18:26 | |
| jdstrand | sees* | 18:26 |
| infinity | GunnarHj: Ah-ha. Found why I can validate and you can't. :P | 20:23 |
| 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:24 |
| GunnarHj | infinity: Great, thanks! | 20:46 |
| 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:47 |
| 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:48 |
| infinity | (ick) | 20:49 |
| 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:54 |
| GunnarHj | infinity: GNOME and Debian don't play well together in this respect. | 20:55 |
| 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. | 20:56 |
| === mnepton is now known as mneptok | ||
| === michagogo_ is now known as michagogo | ||
| 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:18 |
| 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:20 |
| mwhudson | heh | 23:21 |
| mwhudson | i think oem-config-remaster is ancient cruft | 23:21 |
| 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:22 |
| 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:23 |
| mwhudson | which might not be terribly revealing but maybe worth a go | 23:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!