[00:08] <bluesabre> backlight
[00:08] <bluesabre> woops
[00:17] <rbasak> nacc: yes
[00:17] <nacc> rbasak: ack, will do
[00:17] <rbasak> Thanks!
[00:19] <nacc> rbasak: and actally, i'm going to delete the vivid/wily tasks for mysql-5.7, as it doesn't exist there, if that's ok with you? i've never been quite sure on that policy
[00:19] <rbasak> Deleting tasks is a little dangerous, as they can't be recreated (Launchpad bug)
[00:19] <rbasak> So I usually use Invalid instead, since I found out about that.
[00:19] <nacc> rbasak: oh i didn't realize that, as i thought i had recreated them in the past
[00:19] <nacc> will just leave at don't fix
[00:20] <nacc> *won't
[00:20] <rbasak> Sure
[00:39] <nacc> rbasak: if you have the time, i would like to still chat tmrw to talk about the UOS session
[01:04] <rbasak> nacc: sure
[01:05] <nacc> rbasak: thanks
[05:02] <pitti> Good morning
[05:37] <cpaelzer_> good morning
[06:13] <LocutusOfBorg> nacc, probably  yes
[06:15] <LocutusOfBorg> coreycb, pandas sync?
[06:15] <LocutusOfBorg> not sure BTW
[07:15] <smb> nacc, we could. or are you on that libvirt apparmor one already cpaelzer ?
[07:15] <smb> nacc, cpaelzer for xenial the question is whether we want to push things over the current proposed to limit the number of releases
[07:16] <smb> erm and morning
[07:26] <cpaelzer> smb: morning :-)
[07:26] <cpaelzer> smb: no deep in qemu atm - no touch on libvirt by me
[07:27]  * smb hands cpaelzer a snorkel
[07:27] <smb> cpaelzer, ack, then I will have a look as time permits
[07:27] <cpaelzer> smb: if the fix is easy and the current xenial hasn't passed proposed I'm for your suggestion of pushing over the current one
[07:27] <cpaelzer> smb: the current one is only the preventive fix for the service names
[07:27] <cpaelzer> smb: that one surely can take a sibling I think
[07:28] <cpaelzer> smb: otherwise if bigger I'm for "one change at a time"
[07:28]  * cpaelzer is known as snorkler
[07:28] <smb> cpaelzer, right, the not shutting down all guests is more annoying that that and the fix is rather simple
[10:20] <LocutusOfBorg> nacc, llvm-toolchain-3.7 fixed for powerpc
[10:21] <LocutusOfBorg> caribou, ^^ feel free to steal the patch for 3.6
[10:21] <caribou> LocutusOfBorg: ok, will look at it
[10:24] <LocutusOfBorg> let me know if you upload please
[11:23] <caribou> nacc: rbasak: LocutusOfBorg has a fix for the powerpc FTBS on 3.7 that I can backport to 3.6
[11:25] <caribou> nacc: rbasak: then Debian has just removed llvm usage from the package until upstream fixes things to use LLVM 3.8
[11:25] <caribou> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839850
[11:25] <caribou> So either I upload a new LLVM 3.6, or we just disable LLVM in clamav, & forget about 3.6
[11:26] <caribou> nacc: rbasak: not sure what's the best option now that we're in Final Freeze
[12:06] <rbasak> caribou: thanks! Maybe best to ask the release team?
[12:09] <rbasak> caribou: maybe from an SRU perspective, if it's just the binary name, it'd be better to add a workaround to clamav for that for Yakkety only (and not copy that forward to Z)?
[12:09] <rbasak> I don't know what mechanism we might use exactly, but what I mean is the principle that we do the minimal thing for Yakkety now and then fix llvm in Z.
[12:10] <rbasak> And that minimal thing could be in clamav so as not to risk other packages.
[12:10] <caribou> rbasak: imho, minimal for Y is to add LocutusOfBorg's two line patch to llvm3.6 to fix the powerpc's FTBS
[12:11] <caribou> clamav remains untouched
[12:11] <rbasak> caribou: is that minimal though? It could impact every SRU as dependent packages are rebuilt.
[12:11] <caribou> llvm-toolchain-3.6 builds for all architectures
[12:11] <caribou> rbasak: according to nacc & my check, only clamav depends on llvm3.6
[12:12] <rbasak> Oh, OK. That's fine then I guess :)
[12:12] <caribou> rbasak: that being the reason to get rid of it, but now is a bit too late
[12:12] <rbasak> Yeah.
[12:12] <rbasak> It sounds fine to me then if the release team agree.
[12:12] <caribou> rbasak: I'll fix that for Z
[12:12] <caribou> ok, I'll check with them
[12:12] <rbasak> Thanks again for handling this!
[12:13] <caribou> LocutusOfBorg's fix is already in 3.7
[12:38] <jamespage> pitti, hey - need some help on bug 1631328
[12:38] <jamespage> what's the right way to install a new udev rules file that relies on a user/group that the package maintainer script has not yet created
[12:39] <jamespage> it appears the yakkety udev drops that part of the rule when loading them?
[12:43] <pitti> jamespage: such rules shouldn't be a problem -- we install those all the time, as long as the postinst actually addgroups them
[12:43] <jamespage> pitti, it does
[12:43] <rcj> X on yakkety with two displays is giving me an area that acts like a hall of mirrors
[12:44] <jamespage> pitti, but I'm def seeing the behaviour I think I am
[12:44] <jamespage> pitti, udev complains about the missing user/group
[12:44] <jamespage> about 2 seconds before they are created
[12:44] <jamespage> and then block devices don't get the correct perms (ceph/ceph) until I do a restart or reload of udev
[12:44] <pitti> jamespage: yes, I figure it picks up the new rule during unpack via inotify
[12:45] <jamespage> that was my guess
[12:45] <pitti> jamespage: your postinst needs to udevadm trigger those after group cretion
[12:45] <pitti> but it seems it already does?
[12:45]  * jamespage looks
[12:45] <jamespage> I don't think so
[12:46] <pitti> jamespage: merely installing an udev rule also doesn't actually do anything -- in order for them to get active the device needs to get removed/added or udevadm triggered
[12:46] <pitti> jamespage: oh, I thought because you said so in #8
[12:46] <jamespage> pitti, yeah I know that - the charm does that bit once its configured with block devices etc...
[12:46] <jamespage> the charm does a udevadm trigger to make udev pickup disks its just prepared for use
[12:46] <jamespage> the trigger is firing, but the perms are not applied
[12:47] <jamespage> so its kinda like an incomplete rule application
[12:47] <jamespage> pitti, I guess a fix is to reload the udev daemon in the postinst script
[12:48] <pitti> jamespage: udevadm control --reload?
[12:48] <pitti> jamespage: could work, yes, if that's a race condition
[12:48] <pitti> it only auto-updates via inotify every 5 seconds or so, to avoid bursts
[12:49] <jamespage> pitti, its def a race condition
[12:50] <jamespage> its a shame that when udev does not detect a user/group, it just sets up the rules partially
[12:50] <jamespage> that feels a bit odd
[12:53] <pitti> jamespage: it's actually odd that it runs the rules at all during package installation
[12:54] <jamespage> pitti, its not
[12:54] <pitti> normally that doesn't wiggle devices
[12:54] <jamespage> pkgs installed, charm configures block devices, then triggers the udevadm trigger
[12:55] <jamespage> pitti, my issue is that the rule gets partially loaded due to the race with user/group setup
[12:56] <jamespage> pitti, http://paste.ubuntu.com/23288779/ look ok?
[12:56] <pitti> jamespage: that's after the addgroup?
[12:56] <jamespage> pitti, addgroup is done in ceph-common, rule is installed in ceph-osd
[12:57] <jamespage> ceph-osd -> ceph-base -> ceph-common
[12:57] <pitti> jamespage: well, still needs to be "after" -- if ceph-osd depends: ceph-common that's also fine
[12:57] <jamespage> so it should happen that way
[13:15] <coreycb> LocutusOfBorg, looking at pandas
[13:20] <coreycb> LocutusOfBorg, synced, thanks for the nudge
[13:29] <LocutusOfBorg> thanks
[14:42] <nacc> smb: cpaelzer: yeah, i trust your judgment(s)
[14:43] <nacc> LocutusOfBorg: ack (re: powerpc fix)
[14:43] <nacc> caribou: ack on fixing powerpc for now and removing the dep in Z
[14:44] <caribou> nacc: I'm on it; will upload early monday morning unless the release team tells me otherwise
[14:44] <caribou> (or before eod if they ping me)
[14:44] <nacc> caribou: great, thanks for following up on it!
[14:51] <cpaelzer> nacc: it is scary you trust me and I don't even remember what I wrote
[14:51]  * cpaelzer reading back
[14:51] <nacc> cpaelzer: re: libvirt fixes and whether to combine more into -proposed
[14:52] <cpaelzer> nacc: ah yeah, I already discussed on this and more with smb - good for now
[14:52] <nacc> cpaelzer: thanks!
[14:52] <cpaelzer> nacc: I debugged and triaged a bug we had, but we decided to postpone until after release
[14:52] <cpaelzer> nacc: so it got to the backlog with some extra info
[14:52] <smb> nacc, cpaelzer yeah ... actually its alrady uploaded now
[14:52] <cpaelzer> smb: thanks
[14:52] <nacc> smb: thanks!
[14:57] <smb> cpaelzer, Oh to clarify, nacc mentioned different messages of apparmor which I could not reproduce at all. For those I asked in the bug report for confirmation they are not gone for other reasons. The one we looked at are new to yakkety while the other ones were in Xenial
[14:58] <nacc> cpaelzer: it was just another libvirt bug in the server-next queue
[15:41] <pitti> cyphermox: do you have some time or know someone to verify bug 1592721?
[15:41] <cyphermox> ok
[15:41] <pitti> it's otherwise ready to release
[15:41] <cyphermox> yep
[17:21] <tsimonq2> pitti: you mentioned a quote in the last foundations meeting (yes I read those :P) stating something like "if it
[17:21] <tsimonq2> argh I hate this enter key placement!
[17:21] <tsimonq2> "if it's hard, do it more often"
[17:21] <tsimonq2> pitti: where did you find that? :P
[17:22] <tsimonq2> pitti: or is that your quote? I was just wondering because it was in quotation marks
[18:53] <chiluk> cyphermox: looks like a regression on your most recent update to initramfs-tools..https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474
[19:22] <pitti> tsimonq2: I think it's a Google motto
[19:22] <pitti> tsimonq2: but I really like it
[19:34] <slangasek> chiluk: LP: #1631474 : you may want to also sync with lamont on this
[19:34] <chiluk> slangasek ok .. at the moment, I'm just tryign to understand what the user is attempting to accomplish with ip=dhcp ... perhaps they are using a nfs root?
[19:34] <chiluk> I don't know just yet.
[19:35] <chiluk> slangasek I'll drive it for the time being.. it looks like a fairly straightforward bash change.
[19:35] <slangasek> chiluk: ok
[19:35] <chiluk> I just need to figure out what's not exactly working
[19:35] <pitti> bdmurray: can http://launchpadlibrarian.net/275354292/update-manager_1%3A16.10.2_1%3A16.10.3.diff.gz be changed to not pull in the whole python3-launchpadlib stack into standard? (http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt)
[19:36] <slangasek> chiluk: there's mention in the bug of AWS, which is a particularly strange place to be doing nfs or iscsi root, I would think
[19:36] <cyphermox> well, it's really broken anyway
[19:36] <chiluk> yeah that's my thought as well. and that is correct it is in aws
[19:36] <pitti> bdmurray: like, dropping it to a Suggests: and gracefully not doing PPA changelogs if the module doesn't exist, or doing REST calls with urllib?
[19:36] <slangasek> cyphermox: what's really broken?
[19:36] <cyphermox> that logic there in initramfs -- I see exactly what's wrong
[19:37] <cyphermox> we don't skip on, all, and dhcp when parsing IP
[19:37] <chiluk> yeah the device isn't getting declared explicitly?
[19:37] <cyphermox> chiluk: well, klibc had a mess of different options differently configured
[19:38] <pitti> infinity: ah, perl is being dragged in by the new  "rename" -- that seems awfully heavy too
[19:38] <cyphermox> do basically the if there that looks if ip= contains BOOTIF needs to not run if ip = (dhcp|all|on)
[19:38] <cyphermox> s/all/any/
[19:39] <chiluk> ah ok.
[19:39] <pitti> infinity: which is not seeded and purges without issue in a VM, and is by itself just a recommends of perl -- WTH
[19:39] <chiluk> cyphermox: want me to punt it back to you?
[19:40] <cyphermox> chiluk: well if you want to do it, feel free, or I can fix it myself
[19:40] <cyphermox> it needs a fix in both xenial and yakkety
[19:40] <chiluk> cyphermox you would likely end up sponsoring the upload anyways.
[19:41] <cyphermox> well, you could get one more sponsored upload I can vouch for ;)
[19:41] <cyphermox> I don't mind either way
[19:41] <chiluk> alrighty.. I'll do the legwork then.
[19:41] <chiluk> I really could use the uploads ..
[19:46] <chiluk> it might take me a little longer than you to fully wrap my head around what this awesome bash script is doing.. but this is a good opportunity to spread the expertise.
[20:04] <tsimonq2> pitti: cool :)
[20:07] <smoser> cyphermox, around ?
[20:07] <smoser> pokign aroudn with open-iscsi and such.
[20:08] <smoser> i launch a vm with a nick on a lxdbr0 and then run
[20:08] <smoser> http://paste.ubuntu.com/23290520/
[20:13] <cyphermox> smoser: seems to me like a badly configured dhcp server?
[20:15] <smoser> is it expected that dhclient use 'ip' from busybox ?
[20:15] <cyphermox> yes, that's fine
[20:17] <smoser> well, dhcp server is configured by lxd
[20:17] <smoser> http://paste.ubuntu.com/23290551/
[20:17] <smoser> and stgraber says it should work
[20:18] <cyphermox> are there free IPs?
[20:18] <cyphermox> what packets go through?
[20:18] <cyphermox> tbh there is nowhere near enough information there to know what is wrong, but it's not likely because of which /bin/ip we use
[20:20] <smoser> i'm trying to do ipv6 dhcp
[20:20] <smoser> so probably
[20:20] <smoser> and there are 2 hosts on that network
[20:21] <cyphermox> smoser: well, we do exactly that to deploy maas instances in an ipv6 only network and it works
[20:21] <cyphermox> lamont: ideas?
[20:22] <smoser> cyphermox, well, "works" is a bit of a strong word. :)
[20:22] <cyphermox> it *works*
[20:22] <smoser> lamont has been strugging with it for quite a while
[20:22] <cyphermox> yeah, there's various pieces into that, not just dhcp.
[20:22] <lamont> smoser: initramfs-works.
[20:22] <lamont> shutdown later doesn't
[20:23] <lamont> in that it shuts down the interface whjere the root disk lives
[20:23] <lamont> which could ultimately be an initramfs-tools bug, but it's not a configuration bug
[20:24] <lamont> having said that, bridges and ivp6 address diescovery have their moments... since they "optimized" the bridge code to not forward multicast packets taht weren't "needed", and having that on has caused great pain with ipv6 address discovery for me.
[20:25] <lamont> smoser: packet traces are a very good start for figuring out what is happening with dhcp
[20:26] <smoser>  http://paste.ubuntu.com/23290593/
[20:27] <lamont> smoser: . /lib/functions (or such) and run configure_networking() ?
[20:28] <smoser> yeah, i can try.
[20:28] <smoser> so fyi, i run: dhclient -6 -d -v eth0
[20:28] <smoser> it errors like in
[20:28] <smoser> http://paste.ubuntu.com/23290520/
[20:28] <smoser> second time, it actually tries to do something
[20:28] <smoser> but still fails
[20:29] <smoser> so it surely seems to me that the 'ip' that is causing garbage was bringing the interface up
[20:29] <smoser> which seems important.
[20:31] <lamont> smoser: the code that actually runs in the initramfs is: . /scripts/functions; configure_networking
[20:31] <lamont> and that code works
[20:32] <smoser> well, that fails the same way for me.
[20:32] <lamont> and what do the packet traces look like?
[20:32] <smoser>  message status code NoAddrsAvail: "no addresses available"
[20:32] <smoser> stgraber, ^
[20:32] <smoser> "NoAddrsAvail:"  ?
[20:32] <lamont> tcpdump -ni any por5 547
[20:33] <lamont> only without the typo
[21:08] <jderose> cyphermox: bah, your initramfs-tools update for xenial broke some of my PXE boot related tooling :P still digging into the details, not yet sure if it's fragile assumptions on my end or a bug on your end... will let you know
[21:08] <jderose> but the symptom is a kernel panic when trying to PXE boot
[21:11] <cyphermox> jderose: there is a bug
[21:11] <cyphermox> I bet your PXE deployments pass ip=dhcp
[21:11] <jderose> cyphermox: have the # or link handy?
[21:11] <jderose> cyphermox: yes, indeed it does
[21:12] <cyphermox> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474
[21:12] <cyphermox> entirely my fault, I derped there adding the logic to parse BOOTIF.
[21:12] <cyphermox> chiluk is working on the fix and I'll sponsor it as soon as it's ready
[21:13] <jderose> cyphermox: happens to everyone, no worries :)
[21:13] <cyphermox> it's kind of crippling ;)
[21:13] <chiluk> yeah I'm finding some other issues as well while I look through the code.
[21:13] <jderose> cyphermox: also, if you ever have a proposed package with PXE boot related changes... i'm always happy to test, feel free to ping me anytime :)
[21:14] <chiluk> jderose can you add your /proc/cmdline to the bug and paste it here as well
[21:14] <chiluk> so I know how people are using this.
[21:14] <chiluk> thanks.
[21:14] <chiluk> I'm trying to make sure all cases get covered.
[21:14] <jderose> chiluk: yup, will do
[21:17] <jderose> chiluk: done
[21:17] <chiluk> cyphermox: for example if ! echo "${IP}" | grep -qc 'BOOTIF'; then  will always return true regardless
[21:28] <chiluk> jderose: would you be willing to test an updated initramfs-tools for me shortly?
[21:32] <jderose> chiluk: yup, absolutely! prefer a ppa, but i can manage a deb too, will just take a bit more hacking around (my tooling doesn't make debs especially easy)
[21:32] <chiluk> sure I'll create a ppa ..
[21:32] <chiluk> one sec.. I'm trying to test it myself and the deb is failing to install ..
[21:32] <chiluk> which is strange.
[21:32] <jderose> chiluk: awesome, easy peasy then
[21:36] <cyphermox> chiluk: what?
[21:36] <jderose> chiluk: oh, for completeness here and not just in the bug, my current cmdline is something like: initrd=initrd.img-4.4.0-36-generic root=/dev/nfs nfsroot=10.17.76.1:/var/lib/tribble/ephemeral ip=dhcp ro nomodeset net.ifnames=0
[21:37] <chiluk> cyphermox: the IP variable should never contain BOOTIF
[21:37] <chiluk> so the grep will always fail so the if will always be true
[21:37] <cyphermox> that's not true
[21:38] <cyphermox> the IP variable totally can and does contain BOOTIF sometimes
[21:38] <cyphermox> BOOTIF == whatever interface teh system used to boot with
[21:39] <chiluk> cyphermox does dash support ;& fall-through syntax?
[21:39] <cyphermox> I do not know
[21:40] <chiluk> it looks like a no.. which pisses me off
[21:40] <chiluk> why aren't we just using bash..
[21:41] <jderose> chiluk: not sure if it will be helpful, but i rather recently discovered https://www.shellcheck.net/ and it's kinda badass :)
[21:43] <cyphermox> chiluk: http://paste.ubuntu.com/23290876/
[21:43] <cyphermox> should be sufficient afaik
[21:44] <chiluk> crap cyphermox that's finding a world of bugs on just this one area.
[21:44] <cyphermox> oh, looking for on should be strict, in case we ever have devices that start in on ;)
[21:45] <cyphermox> I'm going to have to come back later, I have a dinner planned tonight
[21:46] <jderose> cyphermox: enjoy, thanks for the quick response!
[21:46] <chiluk> ok cyphermox... I'll put together a patch and ppa and get that out to folks as soon as I'm happy
[22:02] <chiluk> my kingdom for full bash interpretter instead of fricking dash.
[22:02] <chiluk> I'm trying to make things pretty here.
[22:18] <ScottK> infinity: Kubuntu would like to get a security fix in before release:   https://anonscm.debian.org/git/pkg-kde/frameworks/kcoreaddons.git/commit/?id=ab7258dd8a87668ba63c585a69f41f291254aa43
[22:19] <infinity> ScottK: Security fixes welcome.
[22:19] <ScottK> K. Thanks.