[01:02] <Unit193> Well that's interesting, same upstream version of webkitgtk in both Xenial and Yakkety, but an application only segfaults on the latter (and unstable.)
[05:26] <pitti> Good morning
[05:27] <tsimonq2> o/ pitti
[05:28] <jbicha> pitti: good morning
[05:28] <tsimonq2> o/ jbicha
[05:28] <jbicha> the autopkgtest machines seem to be having trouble :(
[05:29] <pitti> hey tsimonq2, hello jbicha
[05:29] <tsimonq2> how are you pitti?
[05:30] <pitti> jbicha: indeed, I have lots of worker failure mails in my mbox :(
[05:30] <pitti> Welcome to [1mUbuntu 16.10[0m!
[05:30] <pitti> [    2.184796] systemd[1]: Set hostname to <16fad193-3c64-481d-9183-e3a7910315d0-adt-prepare>.
[05:30] <pitti> [    2.218417] systemd[1]: unhandled signal 4 at 0000000023c6f370 nip 0000000023c6f370 lr 0000000023c721f4 code 30001
[05:30] <pitti> [    2.218730] systemd[1]: Caught <ILL>, core dump failed (child 553, code=killed, status=4/ILL).
[05:30] <pitti> !healthy :(
[05:31] <pitti> lcy and lgw often time out but at least caught up, but ppc64 is FUBAR
[06:01] <pitti> tracking in bug 1616743, FTR
[06:38] <pitti> ok, they are catching up
[07:18] <LocutusOfBorg> pitti, hi, you seem the best person to ask removal of runit-sysv package :) described in lp: #1595485
[08:04] <pitti> LocutusOfBorg: it only exists in yakkety-proposed, got reintroduced in your merge :)
[08:05] <pitti> LocutusOfBorg: current version just builds runit
[08:05] <pitti> LocutusOfBorg: so the merge needs to be updated to drop that binary, then it'll be NBS and get removed semi-automatically
[08:24] <LocutusOfBorg> pitti, I don't get, yes I have introduced it, but it failed to migrate because the runtime dependency was dropped in Ubuntu
[08:24] <LocutusOfBorg> so I removed it again
[08:25] <LocutusOfBorg> but now it is NBS, but not autodecrufted
[08:25] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/runit/2.1.2-6ubuntu1
[08:25] <LocutusOfBorg> yes, you have to remove it only from proposed, this is true
[08:25] <LocutusOfBorg> and the latest merge is not building it anymore, from my point of view
[08:33] <infinity> pitti: NBS in proposed isn't tracked by anything but britney.
[08:33]  * infinity fixes.
[08:34] <infinity> LocutusOfBorg: Removed.
[08:34]  * infinity goes to bed for realz.
[08:46] <LocutusOfBorg> have a good night infinity :)
[08:46] <LocutusOfBorg> and thanks
[09:11] <mardy> yofel: hi! Do you think you could help with pushing the fix for bug 1451728?
[09:13] <yofel> if someone gives me ready made debdiffs for what I'm supposed to upload, maybe yes
[10:18] <seb128> dpm, hey, did you get any news from wgrant/cjwatson/pitti about langpacks in yakkety?
[10:19] <dpm> hi seb128, no, I didn't
[10:19] <seb128> :-(
[10:19] <cjwatson> it does need to be set up per https://wiki.canonical.com/Launchpad/Translations/UbuntuOpenings, I just haven't had time
[10:19] <cjwatson> (and won't this week)
[10:20] <seb128> cjwatson, ok, thanks ... can somebody else do that?
[10:20] <cjwatson> William may have time, I don't know
[10:20] <seb128> k
[10:20] <seb128> let's see if he replies
[11:28] <pitti> mwhudson: still here?
[11:29] <LocutusOfBorg> pitti, will pthon-pysam run for cython on amd64/proposed aswell? I see it in ppc64el, but not amd64
[11:30] <LocutusOfBorg> strange
[11:45] <pitti> LocutusOfBorg: kicked; pysam/i386 can't succeed as it isn't built any more; I'll sort that out once the rest of the tests get green
[11:54] <LocutusOfBorg> ta
[12:01] <LocutusOfBorg> pysam/armhf seems to have the same issue
[12:01] <LocutusOfBorg> and cbsuite/i386
[12:53] <pitti> slangasek, xnox: are there some tricks how to debug shutdown problems with upstart? I tried to run upstart-monitor (http://paste.ubuntu.com/23088846/), but this doesn't really tell me anything; after "reboot" it stops some stuff, but ssh etc. continues to run and it does not really reboot
[12:54] <xnox> running upstart in debug mode, and capturing console log is one way to do it.
[12:54] <pitti> if I stop /etc/init/systemd.conf manually there are no processes left, but it still doesn't shut down; so I figure starting the deputy systemd in trusty chagnes the system state somehow, but I don't know enough about how shutdown works with upstart to say which, I'm afraid
[12:55] <xnox> pitti, upstart doesn't do shutdown....
[12:55] <xnox> after it's done, it hands over to sysvinit to shutdown everything.
[12:56] <xnox> i'm guessing you will nit init.d script to stop subordinate systemd.
[12:56] <pitti> xnox: well, it should at least stop all jobs, no?
[12:56] <xnox> i'm guessing you will need init.d script to stop subordinate systemd.
[12:56] <pitti> xnox: that's not it -- as I said, I already ran "initctl stop systemd" and everythign is gone
[12:56] <xnox> nah, it doesn't stop all the jobs.... only those with "stop on" conditions
[12:56] <pitti> and after that, reboot just does http://paste.ubuntu.com/23088846/ but http://paste.ubuntu.com/23088865/ is still left
[12:56]  * xnox re-reads
[12:57] <pitti> xnox: a lot of things are "stop on stopping dbus", dbus itself is "stop on deconfiguring-networking"; all of these are still running
[12:58]  * xnox did say "init.d" script to stop systemd, not "init" - upstart job. probably sysvinit killall is failing to killall, and things have respawned or some such.
[12:59] <xnox> pitti, is there a way for me to get trusty VM with such systemd-delegate in an easy manner?
[13:00] <pitti> xnox: yes; let me upload the current git to a PPA
[13:03] <pitti> xnox: I used "autopkgtest-buildvm-ubuntu-cloud -r trusty" to build a trusty VM, and then scp over the .debs; dpkg -iO *.deb, then install libsystemd-journal0.deb and systemd.deb, that's it
[13:03] <pitti> building in https://launchpad.net/~pitti/+archive/ubuntu/systemd/+packages now
[13:03] <xnox> cool, tah.
[13:04] <pitti> if your local sbuild can beat it, it's in https://git.launchpad.net/~ubuntu-core-dev/+git/systemd-trusty :)
[13:05] <pitti> xnox: so, sometimes I notice that the deputy systemd changes utmp and then runlevel is "unknown"; but it also hangs if it is 2 as expected, so that's not it either
[13:05] <xnox> meh, i'm currently in round 2 match against juju reactive layers =)
[13:31] <pitti> xnox: ah, it finished building
[14:32] <LocutusOfBorg> pitti, I think you can ignore python-pysam failing testsuites now?
[15:35] <pitti> rharper: hm, do you still remember how you did DHCP over VLAN? I'm trying to run dnsmasq on a vlan interface and it jusjt fails with "no such interface" although it clearly exists in "ip a" and /sys/class/net
[15:35] <pitti> and that has poor google juice :/
[15:36] <rharper> pitti: it was done with switched based vlans
[15:36] <pitti> rharper: this is mostly for writing a more demanding test case; my current integration test case just adds static addresses and works, but I thought I'd give it a try
[15:37] <rharper> pitti: does it show up under ifconfig or ip list ? (the interface?)
[15:37] <rharper> the ip output shows interface-name@vlan_raw_interface
[15:37] <pitti> 115: nptestsrv@veth43: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
[15:37] <pitti>     link/ether ca:d8:4f:d0:f1:9e brd ff:ff:ff:ff:ff:ff
[15:37] <pitti> oh, it's DOWN -- that's not good I think
[15:37] <rharper> and you're telling dnsmasq interface is 'ntptestsrv' right ?
[15:37] <rharper> versus ntptestsrv@veth43
[15:38] <pitti> right
[15:38] <rharper> huh
[15:38] <pitti> dnsmasq --keep-in-foreground --log-queries --log-facility=- --log-queries --conf-file=/dev/null --dhcp-leasefile=/tmp/l  --bind-interfaces --interface=nptestsrv --except-interface=lo --enable-ra --dhcp-range=192.168.5.10,192.168.5.200
[15:38] <pitti> rharper: anyway, for my other test interfaces I up them first and give them some IP, I forgot to do that for this one
[15:39] <pitti> rharper: so, probably just PEBCAK, and the usual "find the reason right after you ask in public"
[15:39] <rharper> pitti: =)
[15:39]  * pitti is still amazed how often this works -- enlightenment through embarrasment
[15:41] <pitti> rharper: works like a charm \o/
[15:41] <rharper> nice!
[15:41] <pitti> which is a cooler test than with static addresses :)
[15:47] <infinity> pitti: I'm not sure if it's enlightenment through embarrasment or just putting yourself in another mindset by asking the question.
[15:47] <infinity> pitti: I find asking leads me to the answer myself surprisingly often.
[15:47] <pitti> infinity: in a lot of cases it's actually that
[15:47] <pitti> not for this case, I just spotted what I previously didn't look at
[15:48] <infinity> pitti: It's also a weird skill not everyone has.   The above example specifically, actually.
[15:48] <infinity> pitti: Commonly, you'll find yourself pasting a log or typescript saying "LOOK, IT DOESN'T WORK BECAUSE... Oh.  Hah.  I can read, really."
[15:49] <infinity> pitti: Lots of people seem to be incapable of spotting the error on countless reads.
[15:49] <pitti> we call  that "Scheuklappen-Effect" ("blinker effect")
[15:49] <infinity> Germans really do have a word for everything.
[15:49] <pitti> not sure if "blinker" is right, the things that horses wear on their eyes
[15:49] <infinity> Blinders.
[15:50] <pitti> you look at one thing from one angle for so long that you forget other perspectives
[15:50] <infinity> Akin to tunnel vision.
[15:50] <pitti> right, that
[15:51] <infinity> They say English is the most expressive language (and with the number of languages we've ripped off, we bloody well should be), but no one seems to come up with nouns and noun phrases that describe precise situations and emotions as well as Germans.
[15:52] <pitti> we can build arbitrarily long words :)
[15:52] <infinity> That's probably it.  You can turn a noun phrase into a single noun.
[15:52] <infinity> And we're stuck with the phrase.
[15:52] <infinity> So, an English idiom is a German word.
[15:53] <pitti> and I now learned how vlans work
[15:53] <pitti> they are a thing now in netplan for networkd; now off to teach it the equivalent thing for NM
[15:54] <infinity> I still say Fausthandschuhe is my favourite German word.
[15:54] <pitti> actually no -- off to making dinner
[15:54] <infinity> Just the absurdity of it.
[15:54] <pitti> infinity: wow, that's the weirdest one you found?
[15:54] <infinity> pitti: No, there are much weirder, but I love the literal derivation of that one.
[15:54] <infinity> Gloves are hand shoes.  And mittens are fist hand shoes.
[15:54] <tsimonq2> LOL that translates to "mittens"
[15:54] <infinity> tsimonq2: Yes. :)
[15:55] <infinity> tsimonq2: Literally "fist hand shoes".
[15:55] <tsimonq2> so complicated for that word that's kinda little in English
[15:55] <tsimonq2> LOL
[15:55] <pitti> oh, wow -- so far I had interpreted "mitten" as a thick glove you use for taking things out of the oven
[15:55] <ogra_> hmm, now that talk about vlan made me hungry ... (reminding me of https://en.wikipedia.org/wiki/Vla )
[15:55] <infinity> pitti: That's a mitt.  Confusingly enough, we have a distinction.
[15:55] <Laney> Oven glove
[15:55] <infinity> pitti: Mitts are thick mittens used for things like ovens and baseball.
[15:55] <pitti> ogra_: yummy
[15:55] <infinity> pitti: Mittens are winter clothing without fingers.
[15:55] <tsimonq2> http://img.ctrlv.in/img/16/08/25/57bf1507aa7ed.png
[18:50] <nacc> mdeslaur: re: LP: #1612089, based upon the last comment, do we need to do a revert in the cloud-archive version too?
[18:50] <mdeslaur> nacc: yes, the regression is being worked on on qemu-devel
[18:50] <mdeslaur> nacc: no fix yet besides the revert
[18:51] <nacc> mdeslaur: right, i meant more if you already had a handle on the cloud-archive revert, or if i should follow up on that myself )
[18:51] <mdeslaur> nacc: I don't touch the cloud-archive
[18:52] <nacc> mdeslaur: ok :)
[18:52] <mdeslaur> nacc: thanks
[18:52] <nacc> jgrimm: --^ who should i follow up with?
[18:52] <jgrimm> nacc, jamespage or coreycb
[18:53] <nacc> jgrimm: ack, thanks
[18:53] <jgrimm> np
[18:54] <nacc> jamespage: coreycb: just fyi, re: LP: #1612089, i'm trying to find the changelog for that version mentioned in c7, but it might need the same revert done in the primary archive
[19:09] <nacc> coreycb: i think it was your upload based upon https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/liberty-staging/+packages?field.name_filter=qemu&field.status_filter=published&field.series_filter= and the solution is to disable debian/patches/CVE-2016-5403.patch. Do you want a patch for that?
[19:33] <coreycb> nacc, I'll handle the cloud archive bits, thanks for the nudge
[19:33] <nacc> coreycb: thanks!
[19:34] <nacc> jgrimm: afaict, with that --^, we can unsub ubuntu-server from the bug, right?
[19:35] <jgrimm> nacc, i guess, tho we don't usually, just let it ride out to closure
[19:38] <nacc> jgrimm: oh ok