[05:13] <cpaelzer> good morning
[05:28] <alkisg> Hi, once out of 10 boots, network-manager.service isn't started for me, and I have to manually start it with `service network-manager start`.
[05:28] <alkisg> I'll file a bug report, but this is one of those times, so I thought I'd ask here in case someone wants to help me troubleshoot it, so that I can add more details to the bug report.
[05:28] <alkisg> I'm suspecting an issue with "nbd-client.service" and ordering cycles etc:
[05:28] <alkisg> Απρ 07 08:20:15 srv1-dide systemd[1]: NetworkManager.service: Job NetworkManager.service/start deleted to break ordering cycle starting with network.target/start
[05:28] <alkisg> Sometimes systemd decides to delete nbd-client.service, sometimes NetworkManager.service, others dnsmasq... things like that
[05:30] <alkisg> Part of journalctl: http://paste.ubuntu.com/15664149/ ==> search for "deleted" there
[05:31] <sarnold> nice find
[05:37]  * alkisg diverts /etc/init.d/nbd-client to see if it will work around the issue in subsequent boots...
[05:59] <pitti> Good morning
[07:43] <pitti> meh, so why do the cursor-up key suddenly acts as "print screen" in QEMU since yesterday (verified on sid and xenial, so presumably not specific to the guest distro)
[07:44] <pitti> xev indeed says "Print"
[07:45] <pitti> qemu didn't change in three weeks
[07:45] <infinity> pitti: Huh.  You're the second person in a day to complain about keyboard layout weirdness.
[07:45] <pitti> it's fine on my normal desktop, this is just in qemu
[07:45] <infinity> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1566878
[07:46] <infinity> pitti: Still odd coincidence.
[07:47] <pitti> booting trusty CLI and running evtest also says "KEY_RIGHTALT" if I press cursor left
[07:47] <pitti> cursor right is KEY_PAUSE
[07:47] <pitti> perhaps somehow this gets wedged up on the host side already
[07:48] <infinity> pitti: Wait, booting trusty?  So, it's not userspace in the guest that broke.
[07:48] <pitti> infinity: right
[07:48] <pitti> infinity: as I said, it also simultaneiously affected debian sid with LXDE and xenial with unity
[07:48] <pitti> (as guests)
[07:48] <pitti> so this was a change on the host side, and not qemu
[07:49] <infinity> pitti: But all from the same xenial host?
[07:49] <pitti> I just wonder if that's just me
[07:49] <pitti> infinity: yeah, my work laptop
[07:49] <pitti> (well, my only laptop/computer really..)
[07:49]  * pitti tries to train his fingers to use Ctrl+P instead
[07:50] <infinity> pitti: Installing a quick VM.  Though, I haven't rebooted in a while, and now I'm afraid to. :P
[07:51] <pitti> I didn't reboot after this morning's dist-upgrades
[07:51] <pitti> so maybe after I do it'll be broken on the host too
[07:51] <pitti> but I'd have assumed that QEMU gets is key events from X
[07:52] <pitti> or from evdev (and that's fine on the host too, checked with evtest)
[08:12] <infinity> pitti: Can't reproduce from just a dist-upgrade.  I might reboot in a bit and see if my world explodes.
[08:13] <infinity> Or even now.  I'll reboot now.  New kernel to test anyway.
[08:15] <infinity> WTF.
[08:15] <pitti> at least four of your keys still work then :)
[08:16] <infinity> pitti: Yep.  Can reproduce after reboot.  Left is leftalt, up is sysrq.  But only in my qemu guest, not the host.
[08:16] <pitti> and if it's *only* these, then conversations with you will become interesting
[08:16] <infinity> That's so messed up.
[08:16] <pitti> ok, so I'm not mad yet
[08:16] <pitti> well, at least not in *this* regard
[08:16] <infinity> pitti: Anyhow, you can safely reboot.  Confirmed it only hoses the guest, for whatever bizarre reason.
[08:17] <pitti> tjaalton: ^ would you have any idea what could have messed up QEMU *guest*'s key events since yesterday?
[08:17] <infinity> Ahh, and after reboot, I can also confirm barry's bug.
[08:17] <pitti> tjaalton: NB that neither QEMU nor the guest OS changed at all, this must be something on the host since yesterday
[08:17] <infinity> Alt-` doesn't Alt-` anymore.
[08:17] <pitti> hm, I never used that, what is that supposed to do?
[08:18] <infinity> pitti: It cycles between windows of the same type, rather than all windows (Alt-Tab).
[08:18] <tjaalton> the key above alt
[08:18] <infinity> Oh, right, it's not ` on your keyboard, probably.
[08:18] <pitti> ah that, I faintly remember
[08:18] <infinity> tjaalton: So, yeah.  I can confirm barry's weird bug.  And also pitti's.  And I wouldn't be surprised if they're related.
[08:19] <pitti> infinity: it is, just that `/~ is below Z on my Kinesis keyboard
[08:19] <tjaalton> infinity: yeah I'll bisect this
[08:19] <pitti> (also, no cycling with that key in i3)
[08:19] <pitti> tjaalton: the bit that I don't understand is that both evtest (evdev) and xev (X translations) are just fine on the host
[08:20] <pitti> so I wonder what could possibly have changed on qemu's host input side
[08:20] <pitti> KeyPress event, serial 32, synthetic NO, window 0x2c00001,
[08:20] <pitti>     root 0xda, subw 0x0, time 8521331, (652,142), root:(656,633),
[08:20] <pitti>     state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
[08:20] <pitti> KeyPress event, serial 32, synthetic NO, window 0x2c00001,
[08:20] <pitti>     root 0xda, subw 0x0, time 8523315, (652,142), root:(656,633),
[08:20] <pitti>     state 0x8, keycode 49 (keysym 0x60, grave), same_screen YES,
[08:20] <pitti>     XLookupString gives 1 bytes: (60) "`"
[08:20] <pitti> this is Alt+` for me, which looks reasonable at first sight
[08:20] <tjaalton> pitti: new xserver, does your host have it?
[08:21] <pitti> 2016-04-06 08:55:06 status installed xserver-xorg-core:amd64 2:1.18.3-1ubuntu1
[08:21] <tjaalton> I see "error compiling keymap" on xorg log
[08:21] <pitti> tjaalton: ah, I didn't reboot since this morning
[08:21] <pitti> just dist-upgraded
[08:21] <tjaalton> could be related
[08:21] <infinity> Error compiling keymap could indeed relate.
[08:21] <pitti> but infinity just did reboot, and he still gets those errors (alt+` on host and screwed up keyboard in qemu)
[08:21] <infinity> pitti: And yes, running evtest in host and guest at the same time is just weird.
[08:22] <tjaalton> we still carry the big patch to cache xkbcomp
[08:22] <tjaalton> maybe that broke
[08:22] <tjaalton> pitti: after reboot you'd probably see them too :)
[08:22] <infinity> pitti: FWIW, Alt-` registers correctly to evtest, it's unity that's not picking it up, but barry bisected to xorg being the thing that broke it.
[08:23] <pitti> [  6842.947] (EE) XKB: Couldn't compile keymap
[08:23] <infinity> But that makes sense.
[08:23] <pitti> I have that in my xorg.0.log already
[08:23] <infinity> evtest is getting raw events.
[08:23] <tjaalton> I'll disable the patch and see what happens
[08:23] <pitti> so it's not this morning's xorg that broke it, but presumably yesterday's dist-upgrade
[08:23] <infinity> Then the kbdmap is responsible for feeding applications.
[08:23] <pitti> ah, so even xev is still below the layer of what apps see
[08:23] <infinity> Yeah.
[08:23] <pitti> but for some reason it doesn't affect gnome-terminal
[08:23] <infinity> Which is why you can run it on a server CLI. :P
[08:23] <pitti> at least there the cursor keys are fine
[08:24] <pitti> anyway, seems tjaalton is on top of it, thanks
[08:25]  * infinity stops his VM before he goes a bit insane from watching the mismatched evtest results.
[08:53] <tjaalton> infinity, pitti: yup, disabling the patch fixed things
[08:53] <pitti> tjaalton: yay; but supposedly it re-opens some other bug?
[08:54] <tjaalton> it was added to make bootup quicker.. but I don't know how much that matters these days
[08:54] <infinity> I assume that's a performance patch?
[08:55] <tjaalton> we've had it for over six years
[08:55] <infinity> tjaalton: Does it just change when the keymaps are compiled (but still only once), or do we compile repeatedly without it?
[08:55] <tjaalton> never went upstream..
[08:55] <tjaalton> i haven't looked in detail, yet
[08:56] <infinity> tjaalton: If it's only once (or even only once per xserver), it's likely not all that useful.
[08:56] <tjaalton> "This will make the 2nd and later boots slightly faster."
[08:56] <infinity> Oh.  It precompiles to a cache on disk?  I see.
[08:56] <tjaalton> yes
[08:57] <infinity> I can see the value in that, if it works.
[08:57] <infinity> The not working part sucks a bit. ;)
[08:57] <infinity> tjaalton: I'd comment out the patch for a quick upload now, if I were you, to fix all our buggy keyboards, then investigate if it's worth fixing.
[08:58] <tjaalton> yeah
[08:59] <pitti> ah, so this isn't a new patch at all, it just happened to become incompatible with a more recent xorg?
[08:59] <tjaalton> seems so
[08:59] <alkisg> pitti, would it be possible for you to have a quick look at https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1487679 when you have some time? It's making systemd delete network-manager.service one out of 10 boots, and we have to manually start it to get network access...
[09:03] <pitti> alkisg: I'll queue it; do you have some idea already how to break this?
[09:03] <alkisg> pitti: no, I've looked at /etc/init.d/nbd-client's headers but I didn't find anything so far
[09:04] <pitti> ah, this is nbd-client, not server
[09:04] <pitti> # Required-Start: $network $local_fs
[09:04] <pitti> # Required-Stop: $network
[09:04] <pitti> # Default-Start: S
[09:05] <pitti> ah, same old -- wanting to run in very early boot, but wants the network up
[09:05] <pitti> this is an impossible requirement with dynamic stuff like NM
[09:05] <pitti> so I take it nbd needs to make up its mind if it wants to run early, or wants to run after being online
[09:05]  * alkisg was sure that pitti would nail it within 1 minute :)
[09:06] <alkisg> I would vote for "after being online", as for early it ships an initramfs script
[09:08] <alkisg> Thanks!!
[09:08] <pitti> I did an initial bug followup
[09:08]  * alkisg will try to ping Wouter about it
[09:09] <pitti> alkisg: I'm sure someone tries to put /var on an NBD device and uses NetworkManager to bring up the net :)
[09:09] <pitti> alkisg: structurally this should be fairly similar to what NFS uses, so stealing some bits from there might be useful
[09:09] <infinity> pitti: Yeah, but in those cases, it should be started in initrd.
[09:09] <pitti> but nfs has native systemd units now (I don't think we managed to resolve this with sysv)
[09:12] <infinity> pitti: What it might want in a sysv world is three jobs: initrd script for root, rcS script for pre-hotplug, and rc2 script for post-hotplug cleanup.
[09:12] <infinity> pitti: But probably best to involve wouter in that than reinvent his wheels.
[09:16] <infinity> tjaalton: Thanks for the quick fix.
[09:19] <tjaalton> np, sorry about the bug :)
[09:29] <seb128> slangasek, xnox, bug #1566502 ... did anyone tried to get unity to build on s390x?
[09:30] <xnox> seb128, ubuntu-desktop is disabled on s390x.
[09:30] <xnox> seb128, we have parts of things built e.g. some indicators, but e.g. not nux nor unity7
[09:31] <seb128> xnox, nux seems to hit an illegal instruction is one of the tests, would it build if we ignored the error on s390x? does unity build then or does it has issues?
[09:31] <infinity> All that's missing is nux, really.
[09:32] <infinity> seb128: That bug you referenced has nothing to do with s390x, though.
[09:32] <seb128> infinity, it does, see comments
[09:32] <infinity> seb128: It doesn't, see next comment. :P
[09:32] <xnox> and no plans to enable that. s390x is Ubuntu Server only
[09:32] <seb128> infinity, right, I'm fine with that to
[09:32] <infinity> xnox: No it's not.  Our *contract* is server-only.
[09:32] <seb128> but seems like slangasek wanted the thing out of component-mismatch
[09:32] <infinity> xnox: We've made no effort to restrict the packages built.
[09:33] <infinity> If someone wanted to fix nux, I'd be fine with that.
[09:33] <infinity> seb128: My point is that fixing the s390x thing won't fix that part of c-m.  It's been like that for several releases.
[09:33] <seb128> infinity, ok, so my take is that it's fine to ignore that bug
[09:33] <seb128> right?
[09:34]  * infinity nods.
[09:34] <infinity> Ignore away.
[09:34] <seb128> thanks
[09:50] <infinity> Odd_Bloke: Did you ever get around to spinning up another powerpc test cloud image after I told you we had a fixed kernel?
[09:51] <infinity> Odd_Bloke: I'm thinking that if that test works (and it should), we should be a few small twiddles away from publishing dailies?
[09:56] <Odd_Bloke> infinity: I didn't, I'm afraid.
[09:57] <infinity> Odd_Bloke: Could you? :)
[09:57] <infinity> Odd_Bloke: Would be nice to get that work item off your plate.
[10:12] <Odd_Bloke> infinity: I've kicked off https://launchpad.net/~cloud-images-release-managers/+livefs/ubuntu/xenial/cpc/+build/57310, and I'm checking in the meantime if I should expect that to work.
[10:13] <Odd_Bloke> (Because I can't find my branch with powerpc changes, which either means I deleted it accidentally or the changes got merged and I deleted it :p)
[10:16] <cjwatson> infinity: Fancy some archive fun?
[10:16] <cjwatson> I need an adult.
[10:19] <Odd_Bloke> infinity: Well, that build's already failed, so that answers my question.
[10:21] <cjwatson> Maybe it's the wrong time over there.
[10:21] <cjwatson> pitti: Can you be a techboarder for me?
[10:22] <pitti> cjwatson: for you, always :)
[10:22] <cjwatson> pitti: :-) I'd like https://paste.ubuntu.com/15666533/ run in "lp-shell production devel".  This will cause the publisher to emit by-hash index files, but won't yet turn on the Release flag to cause apt to use them by default
[10:23] <Odd_Bloke> infinity: (I found my branch \o/)
[10:23] <TJ-> Odd_Bloke: as you mention cloud-images, would you happen to know why the partner-images ubuntu-xenial-core-cloudimg...  are missing key packages such as iproute2, net-tools yet the 14.04 equivalents have those packages? I ask because someone installed the docker image via that archive and complained there's no network config ability
[10:23] <cjwatson> pitti: (if it says that attribute doesn't exist, rm ~/.launchpadlib/api.launchpad.net/cache/*wadl* and try again)
[10:26] <Odd_Bloke> TJ-: I don't off-hand, no; could you file a bug at https://bugs.launchpad.net/cloud-images/+filebug with more details? :)
[10:26] <TJ-> Odd_Bloke: I was struggling to find out the responsible team/package for them, since there is cloud-images.ubuntu.com and partner-images.canonical.com
[10:27] <TJ-> Odd_Bloke: the cloud-images.ubuntu.com look correct according to the manifests
[10:27] <Odd_Bloke> TJ-: So we don't support using the images at partner-images.c.c directly; tianon takes those and creates the Docker base images from them.
[10:27] <pitti> cjwatson: ah, I better do that right away; the rm -r has run for about a minute already :)
[10:27] <LocutusOfBorg> can anybody please retry mercurial autolkgtest against the new hg-git and hg-subversion?
[10:27] <pitti> apparently I had a gazillion GBs there
[10:28] <cjwatson> yeah, BTDT
[10:28] <TJ-> Odd_Bloke: right, do you know where  bugs for that should be reported?
[10:28] <pitti> cjwatson: done; yay for moving to by-hash
[10:28] <cjwatson> pitti: great, thanks, I'll watch the publisher for a while
[10:28] <cjwatson> fingers crossed
[10:29] <Odd_Bloke> TJ-: I don't know off-hand how Docker handles image bugs; if you file something at that link, then we'll at least have something that we can point tianon at when he wakes up. :)
[10:30] <cjwatson> There's a separate advertise flag that we'll turn on once everything looks good.
[10:30] <TJ-> Odd_Bloke: yeah, I followed the Docker links back until I found the images on partner-images, so thought it was a Canonical/Ubuntu specific process
[10:31] <pitti> LocutusOfBorg: done
[10:31] <Odd_Bloke> TJ-: Yeah, if it's a problem with the contents of the image, then it's probably something that we'll end up fixing.
[10:32] <LocutusOfBorg> thanks pitti
[10:35] <infinity> cjwatson: Oh, it's the right time for me, but I was AFK.  I guess pitti's got you covered?
[10:36] <cjwatson> Yep, thanks
[10:37] <Odd_Bloke> slangasek: I'm not sure I ever thanked you for doing clean-up on our dodgy livecd-rootfs code; thanks! :)
[10:38] <TJ-> Odd_Bloke: seems this has been the case starting with 15.04 bug 1567349
[10:44] <cjwatson> doko: Would it be OK to drop the Provides from libgmpv4-dev?  I think everything that should be using that package does so explicitly (seems to be just ppl-gcc4), and the Provides field causes ambiguity when resolving build-deps from main against universe.
[10:47] <doko> cjwatson, sure. this package is only there to build older gcc's, required by the phone
[10:49] <cjwatson> doko: all right, I'll do that now, thanks
[10:49] <cjwatson> static analysis for the win
[10:52] <cjwatson> Anyone know of a reason why foo2zjs shouldn't say cups-filters | foomatic-filters rather than just foomatic-filters?  cups-filters is the one in main, and Till isn't here
[10:57] <infinity> cjwatson: Sounds reasonable to me.
[10:58] <infinity> cjwatson: Would change the dep resolution for universe flavours, but I'd consider that a feature, not a bug.
[10:59] <cjwatson> Yeah
[10:59] <LocutusOfBorg> pitti, please run the testsuite for mercurial against hgsubversion 1.8.5-1ubuntu1 if possible (just uploaded)
[11:00] <pitti> that'll still take a bit, it first needs to be reviewed/accepted, built, and published
[11:08] <LocutusOfBorg> ok, pitti question: I can click and retry them, can't I just do that by myself?
[11:08] <pitti> LocutusOfBorg: you can retry the test in the normal mode (i. e. run against released package versions except if dependencies force the -proposed version)
[11:08] <LocutusOfBorg> ok, the question was: can't I retry against proposed?
[11:09] <pitti> LocutusOfBorg: normally we only use the package trigger (i. e. mercurial) from -proposed, but take the tested reverse dependencies from -release
[11:09] <pitti> LocutusOfBorg: right now you can't
[11:09] <LocutusOfBorg> well, hgsubversion will migrate anyway, so I can wait for migration and then retry :)
[11:09] <pitti> we could add that to the REST API relatively easily, but we won't add another button for it
[11:09] <LocutusOfBorg> ok thanks
[11:09] <LocutusOfBorg> seems legit
[11:09] <pitti> LocutusOfBorg: yes, that will work of course
[11:09] <pitti> (and is also a cleaner way, as it's much simpler to pinpoint the origin of regressions)
[11:15]  * LocutusOfBorg is going to look at the debci source code
[11:17] <LocutusOfBorg> I can't find the source code for request.cgi
[11:18] <pitti> LocutusOfBorg: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/webcontrol
[11:18] <LocutusOfBorg> seems that the link on the autopkgtest points to debci source code
[11:18] <pitti> retry.cgi lives on the same server/domain, but it's unrelated to debci indeed
[11:18] <pitti> err, request.cgi
[11:19] <LocutusOfBorg> ta
[11:41]  * cjwatson shoves [by-hash=force] in a bunch of places for testing
[11:41] <cjwatson> seems to be behaving itself thus far
[11:47] <Odd_Bloke> infinity: https://launchpad.net/~cloud-images-release-managers/+livefs/ubuntu/xenial/cpc/+build/57317 should have images shortly.
[11:47] <infinity> Odd_Bloke: Ta.
[12:57] <pitti> stgraber: uh, dpkg-reconfigure lxd is very ... challenging
[12:57] <pitti> stgraber: is there some shortcut to "JFDI" it, like it did before?
[12:57] <pitti> manually entering a gazillion IP addresses seems both error prone and also most folks won't have any idea what to use there
[12:58] <pitti> it also seems to default to "lxcbr0" which already is configured by lxc, so it shouldn't ask me all those IP questions again?
[12:59] <pitti> ... and now I am supposed to come up with some valid IPv6 address -- I don't know how to do that easily :/
[13:01] <Odd_Bloke> infinity: I'm OOO tomorrow and sprinting next week, so if you want anything to happen with powerpc images, this afternoon is your last chance for a while. :)
[13:08] <pitti> stgraber: filed as a bug 1567440 now, this might be too complex for an async IRC conversation
[13:22] <infinity> Odd_Bloke: Define "afternoon".
[13:23] <infinity> Odd_Bloke: I'm about to spin it up in a VM right now.  Do you need anything more from me than "it works"?
[13:23] <infinity> Odd_Bloke: Like, sponsoring a merge of changes to livecd-rootfs, I guess?
[13:24] <stgraber> pitti: replied in the bug, the fact that you had lxcbr0 set in there is a bug, you should have had lxdbr0, that's likely caused by a bug we had in our old migration code, unfortunately detecting this is impossible (can't distinguish that from folks having actually changed their lxd config to use lxcbr0...)
[13:24] <stgraber> pitti: The rest is working as intended. We do recommend -p medium nowadays (that's what lxd init calls and what the upgrade warning tells you to run)
[13:25] <Odd_Bloke> infinity: The next ~3 hours; yeah, if I hear from you that it works then I'll submit a MP for livecd-rootfs.
[13:25] <stgraber> pitti: and yes, the user experience is worse than the pre-configured lxcbr0 in most cases but for the 1% or so where lxcbr0 broke all networking, lxdbr0 is massively better and our requirement here was "never break someone's connectivity"
[13:26] <Odd_Bloke> infinity: I don't know if I'll have dailies working before EOD (because I have about three image build-lengths until my EOD :p), but I can push that forward in spare minutes next week.
[13:27] <pitti> stgraber: I just followed up again, I re-tried this in a clean VM
[13:27] <pitti> stgraber: no, this can't possibly be "intended" -- quite frankly, this is a horrible UX
[13:27] <infinity> Odd_Bloke: It's doing datasource things.  (I thought utlemming had planned to make cloud-init inert by default?  Didn't get to that yet?)
[13:28] <infinity> Odd_Bloke: But I think that's a good sign, yes?  It broke well before this last time.
[13:28] <pitti> stgraber: I have a suggestion for restructuring the questions
[13:28] <pitti> (on the bug)
[13:28] <Odd_Bloke> infinity: Yep, I think that's definitely a good sign.
[13:28] <infinity> Odd_Bloke: Will it eventually give up on datasourceifying and give me a getty?
[13:29] <Odd_Bloke> infinity: I think so, yeah; it'll eventually realise that the EC2 metadata source isn't just being slow to respond.
[13:30] <infinity> Odd_Bloke: Kay.  I'll wait longer.  But based on the scrollback up to this point, I think we can call this "good" and push forward.  If it needs tweaking later, we can do that after it's building dailies in production.
[13:30] <infinity> Odd_Bloke: So, I see a 1-liner to live-build, I can push that ASAP.  Lemme look at livecd-rootfs.
[13:31] <infinity> Odd_Bloke: Or just toss an MP my way, since it seems you did this on top of trunk.
[13:31] <Odd_Bloke> Yeah, I'll push it up now.
[13:31] <infinity> cjwatson: Looks like we're dangerously close to lobbing the powerpc scalingstack ball into your court.
[13:31] <infinity> cjwatson: Finally.
[13:32] <cjwatson> infinity: Cool.  We need bos02 first, but from scrollback it sounds like that's getting there.
[13:33] <infinity> cjwatson: cameroff?
[13:33] <cjwatson> That's the one.
[13:33] <infinity> That's one of my new favourite bugs.
[13:34] <infinity> Odd_Bloke: Oh, looks like Colin already landed your live-build 1-liner.
[13:34] <infinity> Odd_Bloke: So just need livecd-rootfs.
[13:35] <Odd_Bloke> infinity: https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/powerpc/+merge/291250
[13:35] <infinity> cjwatson: Based on build times I've been comparing between bos01 and my POWER7 machines, I think one POWER8 compute node should replace my whole farm.
[13:35] <infinity> cjwatson: So, that's comforting.
[13:35] <infinity> (But we should still ask IBM for a few more. :P)
[13:36] <ansgar> Is filing a sync request still enough to get packages synced from Debian? Or do I need to do more than filing #1567322?
[13:37] <infinity> Odd_Bloke: That last hunk looks curious.  But I'll go look at it in context..
[13:37] <cjwatson> infinity: I don't recall how densely we're packed at the moment, but that's plausible.  I'm hoping that instances on bos02 will be a bit more reliable than on bos01.
[13:37] <infinity> ansgar: That's enough if it's something that we don't care enough about to ask for more.  Lemme look.
[13:38] <Odd_Bloke> infinity: It's basically "everything else".
[13:38] <infinity> ansgar: Ahh, yeah, I think we can do that without any extra paperwork.
[13:39] <ansgar> infinity: Yay :) It's in universe and should have no reverse dependencies outside.
[13:39] <infinity> Odd_Bloke: Yeah, after looking at the diff, that hunk is wrong.
[13:40] <infinity> Odd_Bloke: Well, "wrong", given that you 'add_serial_console hvc0' on ppc64el, and powerpc should match.  In reality, you shouldn't need to do console magic on systemd anymore at all.  But I'll make them match for now and you can revisit the whole concept later.
[13:40] <infinity> Odd_Bloke: I'll fix that and merge, the rest looks sane.
[13:40] <Odd_Bloke> infinity: Ack, thanks.
[13:44] <infinity> Odd_Bloke: Tagged and uploaded.
[13:48] <Odd_Bloke> infinity: \o/
[13:49] <infinity> Odd_Bloke: If you can twiddle some bits on your end, this should be ready to be abused in ~30-60m.
[13:49] <infinity> Odd_Bloke: (I'm just assuming here that you just need to add some vars here and there, if it's more complex, well, I'll settle for "soonish")
[13:50] <Odd_Bloke> infinity: Yeah, the trick will be finding all the heres and theres.
[13:51] <Odd_Bloke> infinity: (Enabling s390x has at least refreshed our memory on most of those parts.)
[13:51] <infinity> Odd_Bloke: rgrep my_stuff/ ppc64el
[13:51] <infinity> Odd_Bloke: Given the images are pretty much identical, I'd assume just adding powerpc wherever ppc64el lives would win.
[13:52] <Odd_Bloke> Yeah, that should get us most of the way.
[13:57] <cjwatson> mvo: Where are your scripts for managing ddtp-translations?
[13:57] <cjwatson> Oh, apt-ddtp-tools I bet
[13:59] <infinity> ansgar: Is there an order+wait-time required on those to get build-deps in an order you need, or can I just sync the lot and it'll DTRT?
[14:00] <ansgar> infinity: They have strict dependencies; just dune-grid-glue needs to be rebuild after the rest (or after dune-grid at least).
[14:01] <infinity> ansgar: Alrighty.  Doing.
[14:01] <ansgar> infinity: Thanks :)
[14:04] <infinity> Odd_Bloke: Oh hey, it finally timed out and gave me a getty.  \o/
[14:04] <infinity> Odd_Bloke: Which I can't log into, but I assume that's because no datasource set up a user.
[14:05] <Odd_Bloke> infinity: \o\ \o/ /o/
[14:05] <Odd_Bloke> I would say SHIP IT but we already did. :p
[14:05] <infinity> Odd_Bloke: ;)
[14:09] <cjwatson> mvo: do you think you could merge https://code.launchpad.net/~cjwatson/apt-ddtp-tools/xz/+merge/291260 and do a new ddtp-translations?
[14:09] <cjwatson> Laney: ^-
[14:10] <Laney> merci
[14:12] <seb128> cjwatson, wgrant, thanks ;-)
[14:18] <barry> mvo: hi!  did you see my email about gdebi?
[14:33] <mvo> barry: yes, was quite busy so far but I hope to get to it later today, thanks in any case for your fixes (I think I saw some in the mail :)
[14:34] <barry> mvo: cool.  i'm happy to take the responsibility for uploading if you want (and if i have the perms)
[14:34] <barry> mvo: otherwise, thanks!
[14:35] <mvo> barry: just upload to debian if you want and sync, thats totally fine
[14:36] <barry> mvo: +1
[14:38] <smoser> infinity, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1566468 wonder if you have thoughts on that. you had helped me with a similar issue long ago in bug 1115710
[14:43] <infinity> smoser: Friggin' mellanox again?
[14:44] <smoser> well, no. it did make me think that though. the 'ib_' was what brought it down that path.
[14:44] <smoser> it is infiniband though
[14:45] <infinity> smoser: There is a way to make the module load conditional, if you'd prefer that.
[14:45] <infinity> smoser: But there's likely not much harm in moving it to the base linux image as well.
[14:46] <infinity> smoser: I suppose the question is if ib_ser would ever be useful on a non-metal machine.
[14:46] <infinity> ib_iser, even.
[14:46] <smoser> right. i think probaly not. but open-iscsi is.
[14:46] <smoser> so...
[14:47] <smoser> so in my head its +80k into linux-image (and the cloud images) versus additional delta on open-iscsi package (which we've almost removed at this point)
[14:47] <infinity> ib_iser also pulls in ib_core, so you basically end up with a full IB system at that point.
[14:47] <smoser> but we already have that
[14:47] <smoser> yeah... i didn't say that in the bug. meant to.
[14:47] <smoser> i checked. all its deps are already there.
[14:48] <infinity> Oh, ib_core and ib_addr are in linux-image already?
[14:48] <infinity> In that case, just yank it in, IMO.
[14:48] <infinity> We have iscsi, we have ib, we may as well have the glue.
[14:50] <smoser> infinity, http://paste.ubuntu.com/15670921/
[14:50] <smoser> yeah, i think i agree.
[14:51] <infinity> smoser: Yeah, I definitely agree if it's just that module.  We already have all the scaffoling for both bits it bridges.
[14:53] <sil2100> Laney: hey! So a quick newbie DMB question ;) Now that we have the right amount of people, how usually did the first agenda get created? Since normally it's being worked on by the chair, right?
[14:53] <Laney> sil2100: nah there's only a chair during the meeting
[14:53] <Laney> all of you should work together to sort it out
[14:53] <infinity> sil2100: The rest of the time, we're coffee tables.
[14:54] <Laney> sorry we left such a backlog of applicants :(
[14:54] <sil2100> infinity: oh my, furniture all over the place
[15:16] <barry> tjaalton: yay!  thanks for fixing alt-`
[15:27] <slangasek> Odd_Bloke: heh, glad it all worked out :)
[15:36] <teward> nacc: rbasak: should we have in ubuntu-server release notes something regarding php5 being dropped entirely, with php7.0 replacing it?
[15:36] <teward> already seeing such things in #u+1 channel
[15:36] <nacc> teward: yeah, it's on my todo for this week, hopefully
[15:36] <teward> cool :)
[15:36] <nacc> teward: i need to rewrite serverguide altogether :)
[15:36] <teward> heheh
[15:36] <teward> nacc: probably should expand server guide to have nginx in it at some point - too bad I'm overworked the next few weeks
[15:37] <nacc> teward: yeah :/
[15:37] <nacc> teward: luckily, server guide (aiui) is sort of living, so we can do updates post-release
[15:37] <teward> mhm
[15:37] <ansgar> infinity: Hmm, dune-grid FTBFS on powerpc. I guess this might be https://bugs.debian.org/786500? It looks like alberta wasn't rebuilt on Ubuntu.
[15:38] <infinity> ansgar: Fun.
[15:38] <teward> nacc: just wanted to make sure the php5->php7.0 transition was noted in the release notes, given this morning's enlightenment i imparted to #ubuntu+1 about php5 going away :P
[15:38] <teward> thanks
[15:39] <nacc> teward: thanks, i'll join there too, to help out
[15:44] <infinity> ansgar: Oh, fun.
[15:45] <infinity> ansgar: Do you know what toolchain version was needed to fix that?
[15:46] <ansgar> infinity: No, I just noticed that it was fixed in Debian when I looked at dune-grid failing to build there.
[15:46] <infinity> Whee.  Well, lemme give it a whirl in a PPA before assuming a rebuild in the archive will magically help.
[15:55] <teward> nacc: sounds good
[16:04] <seb128> nhandler, hey
[16:04] <nhandler> Hi seb128
[16:05] <seb128> nhandler, about the wallpapers update, are those images CC-BY-SA 2 or 3 or a mix?
[16:05] <seb128> nhandler, I'm a bit confused by the debian/copyright thing
[16:05] <nhandler> seb128: wallpapers update?
[16:05] <seb128> nhandler, https://code.launchpad.net/~nhaines/ubuntu-wallpapers/xenial-fcs/+merge/291209
[16:05] <seb128> doh
[16:05] <seb128> nhandler, sorry wrong Nathan
[16:06] <nhandler> seb128: No problem :)
[16:06] <seb128> :p
[16:09] <xnox> caribou, hey
[16:09] <xnox> caribou, so i'm here with kernel people in bluefin
[16:10] <xnox> caribou, got a minute to chat about zfcpdump?
[16:55] <infinity> ansgar: A rebuild of alberta indeed made the world a better place in my PPA.  Replicating in the archive now.  Thanks for the pointer.
[16:58] <infinity> ansgar: Or, rather, thanks for caring enough about your syncs to follow up, rather than leaving me scratching my head. ;)
[17:02] <ansgar> infinity: It's just to get the newer dune packages in 16.04 ;)
[17:25] <jderose> tjaalton: xorg-xserver 1.18.3-1ubuntu1 fixes this -  https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1561685
[17:25] <jderose> tjaalton: is it more proper to mark that bug as invalid, or as fix released?
[17:29] <tjaalton> jderose: you probably mean -1u2
[17:30] <tjaalton> mark as dupe of the other
[17:30] <bdmurray> coreycb: Both keystone and nova were tested in bug 155935?
[17:30] <tjaalton> and boo that i didn't see this earlier..
[17:30] <bdmurray> coreycb: er bug 1559935
[17:31] <jderose> tjaalton: ah yeah, you're right... 1.18.3-1ubuntu2. i misread my apt/history :)
[17:33] <tjaalton> jderose: maybe you pinged me about that earlier and i just forgot about it...
[17:33] <tjaalton> anyway, fixed now
[17:33] <jderose> tjaalton: much thanks!
[17:47] <coreycb> bdmurray, yes, keystone and nova were tested for that bug
[17:48] <coreycb> bdmurray, I think arges already promoted that to updates
[17:48] <bdmurray> coreycb: I only see the nova task as Fix Released
[17:49] <coreycb> bdmurray, ah yeah I don't see keystone 8.1.0 in updates
[17:50] <bdmurray> coreycb: so I'll do that bit then
[17:50] <coreycb> bdmurray, thanks, appreciate it
[18:07] <hallyn> hi - how do we get a package un-blacklisted?  (https://bugs.launchpad.net/ubuntu/+source/edbrowse/+bug/1565548)
[18:09] <slangasek> hallyn: the archive team edits the list
[18:10] <hallyn> ok i did subscribe them to the bug...
[18:10] <slangasek> hallyn: yes; in practice pinging an AA probably gets you better QoS
[18:10] <hallyn> arges: ^ is that something you could look at?
[18:10] <hallyn> slangasek: ok :)
[18:10] <hallyn> thanks
[18:10] <slangasek> I am looking now fwiw
[18:13] <hallyn> it sort of exemplified the worst of what ppl complained about a few years ago...
[18:14] <slangasek> hallyn: I've updated the blacklist, it's cached somewhere and I don't know actually where in order to kick it; try syncing it in a bit and poke me for NEWing after?
[18:15] <hallyn> slangasek: great, thanks
[18:16] <cjwatson> It's a */5 cron job, I don't expect you'll have to wait long
[18:16] <cjwatson> update-sync-blacklist run by ubuntu-archive@snakefruit
[18:17] <cjwatson> Probably done already
[18:18] <hallyn> yup, sync succeeded - thx
[18:20] <hallyn> slangasek: syncpackage worked
[18:22] <kwah> Greetings...
[18:23] <kwah> Got bitten by something: unity session does not really start
[18:23] <kwah> no dash/no panel
[18:23] <kwah> Any ideas how to find out what is wrong are welcome
[18:24] <kwah> happened on xenial after yesterdays update + upgrade
[18:24] <kwah> just filed bug 1567591
[18:25] <kwah> + and no window decorators as well.
[18:26] <hallyn> kwah: sorry, i also cannot run unity7.  unit8 works better for me (but is not usable unless yo'ur ehappy in the terminal)
[18:29] <kwah> hallyn, for me everything worked perfectly till yesterday. until upgrade. not anymore :(
[18:30] <kwah> By "unity" package date looks like april fools: Installed: 7.4.0+16.04.20160401.1-0ubuntu1
[18:31] <kwah> But today is already 7th :D
[18:35] <hallyn> kwah: all i know about it is that kirkland excitedly found he could put the panel on the bottom :)  (which i personally wouldn't want, but more power to him)
[18:35] <kirkland> indeed, I do like it down under :-)
[18:36] <hallyn> is that bc you have an actual real monitor?
[18:36] <hallyn> speaking of which, did lenovo make any more announcements aobut the 'legacy' thinkpad they were gonna put out, with a reasonably sized monitor?
[18:36] <kwah> At the moment, I would not mind having it "down under". But it is nowhere.
[18:37] <sarnold> maybe he took those 16:9 monitors and spun them around to 9:16 so he's got all kinds of vertical space to play with
[18:37] <hallyn> heh i've read pdfs that way
[18:37] <hallyn> i'd rather read them on the new sony ereader
[18:37] <sarnold> hallyn: dude 4:3 is never coming back :( they made that clear..
[18:37] <hallyn> sarnold: no no!  lenovo said they would
[18:37] <hallyn> it would have the little light on top of the monitor to shine on the kbd and everything
[18:38] <sarnold> hallyn: in one of the questionaires they had a handful of screen dimensions and they had a note near the bottom "no one makes 4:3 panels any more we can't offer that as an option. sorry."
[18:38] <hallyn> don't take this away from me!
[18:38] <hallyn> biab, gotta go kick a puppy
[18:39] <infinity> sarnold: Cop out.  They could buy 16:9 panels and slice off the end with an Xacto knife.
[18:39] <hallyn> like i do
[18:39] <infinity> sarnold: A great activity for the kids at the Lenovo daycare.
[18:40] <sarnold> infinity: you know if that works that might be better than my "cover it with some dark duct tape" idea
[18:42] <nacc> Pharaoh_Atem: ping
[18:42] <sladen> hallyn: no.  There is one video interview with David the design discussing basically "the anniversary in 2017 would be a good year"
[18:42] <hallyn> sarnold: wouldn't stacking two one over the other work better?  you could glue the one kbd to the back of the other monitor...
[18:43] <hallyn> sladen: are you the kind of guy who enjoys telling kids there's no easter bunny?
[18:43] <hallyn> :)
[18:43] <infinity> hallyn: That's exactly the kind of guy sladen is.
[18:44] <hallyn> in the end i really just want it for pdfs, so the sony ereader is the way fwd for me
[18:44] <jrwren> there is no easter bunny?
[18:45]  * jrwren runs and cries in teh corner
[18:45] <sarnold> which ereader by the way? :) my prs505 or whatever it is is sluggish enough and bringing it along on trips seemed to be the magical "please subject me to extra time-consuming scrutiny" at airports
[18:47] <sladen> hallyn: infinity:  https://youtu.be/8lqAa_eD84A?t=13m34s "David Hill Q&A with Lenovo Insiders "
[18:47] <infinity> sladen: I actually prefer the new Thinkpads, I don't get this fetishism for the past.
[18:48] <infinity> Literally the only thing wrong with my T450s is the pry/clip versus screws thing.  And yeah, I'd give up a few mm and a few grams to get screws.
[18:48] <infinity> But I don't want anything remotely like an old Thinkpad just to get easier opening. :P
[18:49] <nacc> slangasek: Pharaoh_Atem: i just got a weird testcase failure with cgi/fpm/mod-php7.0, wget wasn't present in the image? is that a recent change?
[18:49] <sladen> infinity: grooy.  I quite like the same keyboard I've used for 15 years, vertical space, hardware nipple buttons, status LEDs that show when the machine is about to die, HDDs/RAM/etc thta can be exchanged
[18:49] <infinity> sladen: Hardware buttons are there in the current line.  They backpedalled on that one quickly.
[18:49] <infinity> sladen: Guts can be exchanged on this fine (except for the screw issue).
[18:50] <infinity> sladen: Keyboard, I grant you, is a matter of taste, but I type faster on their new keyboards than the old (though I like both).
[18:56] <nacc> slangasek: Pharaoh_Atem: ah i wonder if it's an autopkgtest quirk
[18:59] <hallyn> sarnold: the dpts1 'digital paper'
[19:00] <hallyn> infinity: yeah the only thing i hate about my t440s is the *&$%(*$&%)( clickpad, i think i'll love the t450 when i upgrade
[19:02] <sarnold> 1200x1600! hey!
[19:05] <infinity> hallyn: You can buy a 450 pad and install it in a 440.  wgrant did that.
[19:05] <hallyn> yeah, i saw his...
[19:08] <hallyn> i was going to hold out, but my laptop isn't breaking yet so maybe i'll give in
[19:08] <infinity> hallyn: Assuming it's not exploding, the 440 is pretty nice hardware.  Would make a decent hand-me-down.
[19:09] <infinity> hallyn: Heck, my T420s is still great, and I can't figure out what to do with it.
[19:09] <hallyn> exploding?
[19:09] <infinity> (It's doing glibc CI builds right now)
[19:09] <hallyn> it did smoke once when i didn't plu gin in the righ torder...
[19:09] <hallyn> but that was a year ago
[19:30] <slangasek> nacc: if your autopkgtest requires wget it should declare a test dependency; that's not guaranteed to be part of the test environment
[19:34] <nacc> slangasek: that's what i though, i'll update my debdiff then
[19:34] <nacc> slangasek: i don't know why we didn't see it before
[19:48] <nacc> sarnold: so i was looking at some older PHP5 CVE fixes, and noticed one of the ubuntu patches has some stray changes (very small, shouldn't have any impact, but ...). Is that expected? I would think not
[19:49] <sarnold> nacc: no, it isn't, but despite appearances we are human :)
[19:50] <nacc> sarnold: heh -- wasn't sure if it's worth fixing, i don't think it's causing this other bug or anything, just was curious
[19:50] <nacc> sarnold: it *might* actually be a performance improvement, even if marginal :)
[19:50] <sarnold> nacc: it's also possible that e.g. a first-draft change was proposed and we'd build packages with that, test, etc., and then the 'final patch' is released with other changes -- we don't always rebuild with those, especially if the changes look useless / pointless
[19:52] <nacc> sarnold: ah that could be, you're right
[19:52] <nacc> sarnold: ok, np -- just learnin'
[19:52] <sarnold> nacc: if you do spot something that looks like a regression, please do file bugs.
[19:52] <sarnold> thanks :)
[19:52] <nacc> sarnold: yep, of course
[19:58] <Pharaoh_Atem> nacc: that's strange, as it definitely worked, and nothing changed in the tests
[19:59] <nacc> Pharaoh_Atem: just confirmed that i needed to add the dep
[19:59] <nacc> Pharaoh_Atem: maybe it just happened to work before
[19:59] <nacc> Pharaoh_Atem: i'll let ondrej know
[20:01] <Pharaoh_Atem> okay
[20:12] <slangasek> nacc: fyi php-universe-source7.0 should go away as part of this merge
[20:13] <slangasek> nacc: dunno if you're prepared to do that right now :)
[20:16] <mvo_> Laney: if you still need it we should talk tomorrow, crazy day
[20:16] <nacc> slangasek: oh because our infra can do the universe builds now?
[20:17] <nacc> slangasek: i can do that today, for sure; do you have a pointer to what i need to do?
[20:18] <slangasek> nacc: basically just dropping the delta
[20:18] <slangasek> nacc: I just flipped the switch on enabling universe build-deps for main in xenial ~20 minutes ago
[20:18] <slangasek> 10? maybe it was only 10
[20:20] <nacc> slangasek: ok, cool; so i'll fix that up and udpate those debdiffs
[20:20] <nacc> slangasek: yeah, that'll be nice to have done now, will make our delta very small
[20:59] <tjaalton> huh, enigmail broke
[21:00] <tjaalton> can't find the secret key
[21:12] <tjaalton> bug 1485863
[21:12] <tjaalton> same symptoms on two xenial machines
[21:17] <tjaalton> ah it's bug 1565963
[21:38] <superm1> tjaalton: could you make sure you add some comments about what version you came from and upgrade path?  you're the second person, but we don't have a reproducer for this yet
[21:38] <superm1> I tried in a VM including an upgrade over from gnupg2.0 to 2.1, and maintainer in Debian tried as well without any luck so far
[21:39] <tjaalton> both xenial->xenial, but the .gnupg directory is much older
[21:39] <nacc> slangasek: just to be clear, i think we'll still need to have the netcat-traditional change?
[21:40] <slangasek> nacc: as a delta in build-depends?
[21:40] <tjaalton> superm1: I'll update the bug
[21:41] <superm1> thanks
[21:41] <nacc> slangasek: yeah, just trying to understand fully what is now allowed/enabled
[21:42] <tjaalton> superm1: what files should be updated by the migration? only files touched this year are random_seed and the agent socket
[21:43] <slangasek> nacc: there's no need to carry a delta for build-deps so long as those build-deps are only used as runtime.  If the build dep will be translated into a runtime dep (i.e. a library -dev package), we need to make sure we use the right one for main; but netcat, it should also be fine to drop the delta for
[21:44] <superm1> tjaalton: that's a better question for the debian maintainer who is subscribed to the bug too (i'm worried i wouldn't give a complete answer)
[21:45] <superm1> tjaalton: i know that it touches a .gpg-v21-migrated
[21:45] <superm1> if you haven't already ran the import to fix it can you back up .gnupg to something else before doing so in case there are some forensics to be done?
[21:46] <tjaalton> sure
[21:49] <tjaalton> gpg: error building skey array: Permission denied
[21:49] <tjaalton> after import
[21:49] <nacc> slangasek: to clarify, the first "runtime" above (first sentence) is referring to compile-time? And then the second part is if any binary packages need the same dep at runtime?
[21:51] <tjaalton> superm1: I guess the socket thing doesn't work if $HOME is on nfs or such and simultaneously logged in on two machines..
[21:54] <superm1> tjaalton: eek
[21:55] <superm1> if it's on NFS do you have proper permissions as your user?
[21:55] <slangasek> nacc: haha yes, sorry
[21:55] <superm1> or possibly permissions are wrong and never noticed because you haven't written to .gnupg for a long time?
[21:55] <nacc> slangasek: :) was a little worried I had no idea what runtime was anymore
[21:56] <tjaalton> superm1: this is not on nfs, was speaking hypothetically :)
[21:56] <nacc> slangasek: ok, doing a build-test now; is there a good way for me to verify locally it will build properly and packages will "live" in the right component?
[21:56] <tjaalton> but yeah import gives that error
[21:56] <slangasek> nacc: I'm sure Alice in Wonderland would clarify this for us
[21:57] <slangasek> nacc: verify locally> ummm at this point just having main+universe in your sources.list is a valid test
[21:57] <nacc> slangasek: ok, will post an updated debdiff shortly, hopefully
[21:58] <superm1> tjaalton: okay well that's probably more useful then, add whatever you determine to the bug then
[22:39] <stgraber> roaksoax: around?
[22:44] <stgraber> roaksoax: that latest maas upload introduces two new udebs as arch:any but they don't contain binaries (or in fact anything), any reason they can't be arch:all?
[22:48] <slangasek> nacc: php7.0, your merge drops debian/patches/0049-backport-89a43425.patch which seems to still be needed
[22:52] <nacc> slangasek: grr, you're right, let me fix -- i mistook the sha1
[22:59] <slangasek> nacc: shall I re-add locally?
[22:59] <nacc> slangasek: about to post a new debdiff
[22:59] <slangasek> nacc: ok
[23:00] <nacc> slangasek: updated debdiff posted just now
[23:02] <slangasek> nacc: great, uploading
[23:04] <nacc> slangasek: thanks!
[23:05] <nacc> slangasek: debian has moved on to 7.0.5, which has that bugfix, but i'll send them the wget dep change, so we should be able to sync at some point, if we get a dotrelease exception
[23:05] <roaksoax> stgraber: no no reason at all. I'll change the arch for next upload if that's ok, or would you prefer I do one now ?
[23:05] <stgraber> roaksoax: next upload is fine
[23:05] <roaksoax> stgraber: k cool, thanks!