[00:35] <nacc> mwhudson: probably my own ignorance but why would alignment and parallelism interplay like that? or is parallelism a red herring?
[00:37] <sarnold> re-run locally with -j4 or re-run on the arhmhf with -j1 to find out? :)
[00:38] <nacc> sarnold: so on the armhf porter, -j1 is used and it passes
[00:38] <slangasek> nacc: the porter box's kernel does not raise SIGBUS
[00:38] <nacc> sarnold: but on the test rebuild, -j4 was used and it failed
[00:38] <nacc> slangasek: ah
[00:38] <nacc> good info! :)
[00:38] <slangasek> so parallel is a red herring
[00:38] <sarnold> slangasek: wow, how (and _WHY_)? :)
[00:39] <slangasek> sarnold: the better question is, why did the armhf builders start raising it
[00:39] <sarnold> each arch has their own rules.. it feels to me like the builders ought to stick with 'usual'
[00:40] <slangasek> sarnold: the usual is to not raise SIGBUS on anything armv7 or later.  But android kernels forced it on, so we used to get bugs that were not reproducible on the builders or porter box, only on phones
[00:40] <slangasek> then when we moved builders to armhf guests on arm64, suddenly we were getting sigbus there, but I don't think anyone's been able to determine why
[00:40] <slangasek> if we could get the porter box to also have it on, we'd be golden
[00:41] <nacc> slangasek: mwhudson: i guess i'm at a loss on how to go further with the memcached failure then, given that i can't reproduce it (at least, not that i know of yet)
[00:41] <sarnold> yeah, inconsistent seems like a quite route to insanity
[00:41] <slangasek> nacc: mwhudson's hint (not validated yet by me) is to log into the armhf chroot on the arm64 porter box
[00:41] <nacc> slangasek: interesting, I can try that tomorrow!
[00:42] <nacc> slangasek: would you happen to know who i might turn to for llvm testcase failures?
[00:42] <nacc> (unrelated to arm)
[00:43] <slangasek> nacc: perhaps doko
[00:43] <nacc> heh ok :)
[05:26] <pitti> Good morning
[05:41] <cpaelzer> nacc: coreycb: I already was on a birthday overloading my belly at the time yesterday :-/
[05:41] <cpaelzer> coreycb: I'm here to help you get access to our node as interim help if you want that, but you'll need some extra access I'll send you in a query
[05:42] <cpaelzer> coreycb: I think jamespage and beisner were of your Team and could share one where you already have VLAN access
[05:42] <cpaelzer> coreycb: but we can discuss all that once you are online again
[05:42] <cpaelzer> coreycb: and in any case if I'm not here jfh might be able to help as well (but same TZ)
[05:42] <cpaelzer> ah - and good morning devel channel :-)
[05:57] <pitti> roaksoax: you are double sure that you want to replace the stable MaaS 2.0 with a beta version of 2.1 a week before release? the upload does not point to a FFE bug, so please reupload with a pointer to that, so that this can be discussed somewhere (and/or discuss in #u-release)
[06:40] <pitti> coreycb: can you please have a look at the failed armhf/s390x tests of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#nova ? they complain about compute-kvm not running, which is understandable in an lxc container
[06:41] <pitti> coreycb: so this is a regression between b2 and rc2
[08:10] <sil2100> xnox: hey! Any news on the upstart merge and new release?
[08:24] <doko_> caribou: is https://bugs.launchpad.net/ubuntu/+source/tomsfastmath/+bug/1619239 still in progress?
[08:25] <caribou> doko_: we've postponed it until 17.04 & I have prepared a new clamav w/o the tomsfastmath dependancy that is about to be uploaded
[08:26] <doko_> ta
[08:26] <caribou> doko_: the security team's backlog for MIR reviews made it almost impossible to have it reviewed for 16.10
[08:28] <doko_> Mirv: that looks like a qt issue: https://launchpad.net/ubuntu/+source/ubuntu-push-qml/0.1+15.10.20150826.1-0ubuntu2/+build/10990923
[08:43] <Mirv> doko_: ack, so it does
[09:31] <dpm> popey, doko_, has bug 1625074 been sorted out?
[09:33] <doko_> dpm, popey: wait for review from the security team
[09:36] <dpm> doko_, ok, thanks, it seems they say review is underway
[09:37] <popey> willcooke: ^ I think you mentioned some new info from the security team?
[09:37]  * willcooke reads
[09:37] <willcooke> so yeah, we have the OK to go ahead with MIRing before the security review is complete
[09:38] <willcooke> doko_, I'll ask slangasek to confirm with you formally
[10:22] <rbasak> ddstreet: please could you do the SRU paperwork for bug 1224007?
[11:21] <jbicha> LocutusOfBorg: the link-grammar autopkgtest failure was my fault but it's all fixed now
[12:19] <caribou> nacc: did you find anything regarding the llvm-3.6 FTBS so far ?
[12:30] <stgraber> infinity: are you planning on refreshing the yakkety chroots pre-release? working on crappy internet today (aka LinuxCon) and just noticed it's pulling quite a lot of updates
[12:31] <coreycb> pitti, I'll take a look, I thought I'd fixed it yesterday but perhaps not
[12:36] <LocutusOfBorg> caribou, can I know the llvm issue context?
[12:36] <LocutusOfBorg> jbicha, thanks
[12:37] <caribou> LocutusOfBorg: the FTBS is very early in the rules file:
[12:37] <caribou> dpkg-query: no packages found matching g++-6.1
[12:37] <caribou> dpkg: error: --compare-versions takes three arguments: <version> <relation> <version
[12:38] <caribou> LocutusOfBorg: just not sure if nacc has identified the issue already
[12:40] <LocutusOfBorg> I know what the issue is
[12:40] <LocutusOfBorg> and I know what the patch is
[12:41] <LocutusOfBorg> usually asking me about llvm issues is a quickeer fix
[12:41] <caribou> :)
[12:41] <LocutusOfBorg> you just need to adjust the regex for new gcc
[12:41] <caribou> LocutusOfBorg: yeah, that was my next step
[12:42] <caribou> LocutusOfBorg: nacc told me about the FTBS since clamav which I uploaded is its only dependancy
[12:43] <LocutusOfBorg> https://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/3.8/debian/rules?r1=2038&r2=2041
[12:43] <LocutusOfBorg> I want to get rid of old llvm in Debian and Ubuntu
[12:44] <caribou> LocutusOfBorg: thanks; do you want me to take care of it or you want to do it yourself ?
[12:44] <LocutusOfBorg> why aren't you using llvm 3.8 is unknown to me
[12:45] <LocutusOfBorg> caribou, ENOYETCOREDEV
[12:45] <caribou> LocutusOfBorg: oh, didn't know that
[12:45] <LocutusOfBorg> and I want to get rid of that
[12:45]  * LocutusOfBorg applied for core-dev but only one advocacy so far
[12:45] <caribou> LocutusOfBorg: & Debian is still using 3.6 and from what I can gather, clamav needs sensible adaptation to use higher than 3.6
[12:46] <caribou> LocutusOfBorg: & I don't have much to do about it myself, I just merged the package from debian
[12:46] <LocutusOfBorg> well, yesterday Sylvestre started the transition to llvm-3.8
[12:46] <LocutusOfBorg> so I suspect clamav being broken in Debian right now?
[12:46]  * LocutusOfBorg does some dak query 
[12:47] <LocutusOfBorg> https://buildd.debian.org/status/fetch.php?pkg=clamav&arch=amd64&ver=0.99.2%2Bdfsg-3%2Bb1&stamp=1475621172
[12:47] <LocutusOfBorg> sigh, true
[12:47] <caribou> LocutusOfBorg: ok, I'll wait until nacc comes in so we don't overlap on this
[12:48] <LocutusOfBorg> configure: error: LLVM < 3.7 required, but "3.8.1"(381) found
[12:48] <caribou> yep, that's what I got yesterday when I tried to build with 3.8
[12:49] <LocutusOfBorg> ok let me fix llvm 3.6
[12:49] <LocutusOfBorg> sigh
[12:51] <caribou> LocutusOfBorg: don't bother, I can do it
[12:54] <LocutusOfBorg> thanks
[12:54] <LocutusOfBorg> if you want to forward patches to the debian bug reports... :)
[12:54] <LocutusOfBorg> even if trivial, I can give you credits and maybe upload
[12:54] <LocutusOfBorg> (having RC bugs helps in kicking them out of testing)
[12:58] <caribou> LocutusOfBorg: wait, are we talking about the same thing ? I was referring to applying your regex modification to LLVM-3.6
[13:00] <LocutusOfBorg> yes
[13:00] <caribou> k, I'm on it
[13:01] <LocutusOfBorg> core-devs: syncpackage -s costamagnagianfranco portaudio19
[13:01] <LocutusOfBorg> please ^^
[13:01] <LocutusOfBorg> patch for this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833950
[13:03] <LocutusOfBorg> dholbach, ^^
[13:04] <LocutusOfBorg> this is a serious bug that prevents blind people from using the system
[13:06] <dholbach> in a all right now
[13:10] <dholbach> sorry, in a call
[13:11] <LocutusOfBorg> I aksed ginggs to sync, I can open a bug if needed
[13:11]  * LocutusOfBorg TIA
[13:16] <pitti> apw: I finally got an useful log, filed bug 1630578 about the eternal retry loop
[13:18] <dholbach> LocutusOfBorg, done
[13:18] <LocutusOfBorg> <3
[13:20] <dholbach> it will be sitting in the release team queue
[13:34] <pitti> Laney: yay, armhf beat x86 this morning's queue run! (second after s390x)
[13:34] <Laney> \o/
[13:35] <Laney> Intel better be worried
[13:35] <ogra_> intel is doomed (since yaears !)
[13:37] <LocutusOfBorg> dholbach, thanks
[13:37] <dholbach> :)
[13:38] <LocutusOfBorg> blind people should appreciate that
[13:38] <pitti> apw: and I reduced the reproducer from 5:30 hours to 1s, which is a lot more comfy :)
[13:59] <apw> pitti, yay :)
[14:57] <caribou> nacc: I'm about to upload a fixed llvm-toolchain-3.6
[15:24] <rbasak> cyphermox: is grub2 2.02~beta2-36ubuntu3.4 in the Xenial queue supposed to supersede 2.02~beta2-36ubuntu3.3 in proposed? They refer to the same bug, but the earlier version is still v-needed.
[15:25] <nacc> caribou: great!
[15:25] <nacc> caribou: thank you
[15:26] <caribou> nacc: well, you can thank LocutusOfBorg
[15:26] <caribou> nacc: want me to upload clamav along with it ?
[15:26] <nacc> caribou: ah that won't fix it though
[15:26] <nacc> the regex fix?
[15:26] <nacc> i sent that to debian already, or acked the one they had in their bug report
[15:26] <nacc> it will still fail to build clamav
[15:26] <nacc> err, not clamav, but its own testcase
[15:26] <nacc> there are two failures
[15:27] <caribou> nacc: oh, I didn't get that far, the build just killed my test server
[15:28] <nacc> caribou: yeah, i didn't want to upload a partial fix, sorry -- i thought i had mentioned that to you earlier
[15:28] <caribou> grrr
[15:28] <nacc> let me find the test failures
[15:29] <caribou> nacc: nope but no worry, I had a bit of time so I thought I'd give it a look
[15:29] <nacc> http://paste.ubuntu.com/23280288/
[15:29] <nacc> are the two failures i see with the regex fix
[15:30] <Odd_Bloke> pitti: I've noticed that /var/log/syslog ends up with the first N messages with the same (later-than-boot) timestamp whereas journalctl has different, earlier timestamps for the same events.
[15:30] <Odd_Bloke> pitti: Shall I file a bug for this?
[15:30] <caribou> nacc: then maybe LocutusOfBorg can help more than I can
[15:31] <pitti> Odd_Bloke: I suppose rsyslog records the dates when it receives the event, not the date from teh original event?
[15:31] <pitti> Odd_Bloke: rsyslog actually has a mode to pull from the jouranl (which should preserve origianl timestamps), but we don't use that yet; at some point we should as it will also avoid truncated logs on bursts
[15:31] <LocutusOfBorg> caribou, where are the failures?
[15:32] <LocutusOfBorg> on i386?
[15:32] <Odd_Bloke> pitti: Yeah, that rsyslog hypothesis seems likely.
[15:32] <caribou> nacc: ^^
[15:32] <nacc> LocutusOfBorg: http://paste.ubuntu.com/23280288/
[15:32] <nacc> LocutusOfBorg: that occurs on amd64, not sure if the same tests fail on other archs yet
[15:40] <cyphermox> rbasak: yes
[15:42] <LocutusOfBorg> nacc, link?
[15:43] <nacc> LocutusOfBorg: just provided? http://paste.ubuntu.com/23280288/
[15:43] <LocutusOfBorg> not helping, I want a full build log
[15:43] <LocutusOfBorg> e.g. a ppa build
[15:44] <nacc> LocutusOfBorg: would my local sbuild's full log be sufficient?
[15:44] <LocutusOfBorg> against yakkety?
[15:44] <nacc> yes
[15:44] <nacc> with the fix for the regex
[15:44] <LocutusOfBorg> regex fix for llvm 3.6 against yakkety and nothing more
[15:44] <nacc> yes
[15:44] <LocutusOfBorg> let me upload on my ppa
[15:44] <nacc> i have the same
[15:46] <nacc> LocutusOfBorg: http://termbin.com/j435
[15:47] <nacc> LocutusOfBorg: only change to the package was the regex fix for recognizing gcc 6
[15:47] <nacc> bah seems cutoff
[15:51] <rbasak> nacc: do you have SRU paperwork for bug 1575543 please?
[15:52] <nacc> rbasak: was on my list to do today and upload
[15:52] <nacc> i was fixing it live with a  requestor in #ubuntu yesterday
[15:52] <rbasak> Seems to already be in the queue?
[15:52] <nacc> bah, i thought i had *not* yet uploaded, let me fix the bug
[15:52] <rbasak> But sure, it can be processed when you're ready :)
[15:56] <nacc> rbasak: updated
[15:56] <rbasak> Thanks!
[15:59] <nacc> rbasak: thank you!
[16:03] <juliank> eww, autopkgtest had an autopkgtest failure on amd64 for apt/1.3.1. I retried that now, let's see if it goes normally this time
[16:08] <nacc> mwhudson: slangasek: fyi, reproduce the memcached failure on arm64 porter in armhf chroot
[16:10] <nacc> mwhudson: http://paste.ubuntu.com/23280567/
[16:17] <slangasek> nacc: nice, now you have something you can gdb :)
[16:18] <rbasak> jamespage: what's the regression risk for the SRU in bug 1608934? Please could you fill that in?
[16:18] <nacc> slangasek: yep :)
[16:25] <nacc> mwhudson: slangasek: http://paste.ubuntu.com/23280630/ (gdb bt)
[16:25] <nacc> will try and debug :)
[16:32] <nacc> LocutusOfBorg: able to reproduce?
[16:38] <LocutusOfBorg> sorry will try now
[16:39] <nacc> LocutusOfBorg: np, I can also e-mail you the log (as I think it'e exceeding the pastebin's size)
[16:53] <lamont> [  OK  ] Reached target Shutdown.
[16:53] <lamont> [  397.076385]  connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4294988998, last ping 4294990256, now 4294991552
[16:54] <lamont> WHY do we still want to talk to the root fs after we get to shutdown?
[16:54] <lamont> (it's trying to reboot...)
[17:11] <koike> cyphermox, hey, shim was rejected by debian because of missing copyrights attributions, I just send you a merge proposal, could you take a look when you have some time please?
[17:14] <smoser> pitti, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/o/open-iscsi/20161005_154808@/log.gz
[17:14] <smoser> why would we not have access to kvm there?
[17:21] <slangasek> doko_: did you see that your tomcat8 sync brought a new dep with it (taglibs-standard)?
[17:26] <cyphermox> koike: ack, but I'll merge that with some changes, we have a shim pending upload now...
[17:26] <koike> cyphermox, ok, thanks
[17:27] <slangasek> cyphermox: maybe I should merge in the packaging changes that I was making for Debian
[17:27] <slangasek> cyphermox: i.e. maybe you want to hold off on work for a bit so I can stop having to redo my changes to debian/copyright ;)
[17:29] <lamont> pitti: you around?  I'm trying to fathom what systemd et al might be dowing after "Reached target Shutdown" that requires the root disk still
[17:30] <lamont> or how to get a working getty at that point. :/
[17:30] <lamont> s/getty/shell
[17:31] <koike> slangasek, ops, I hope I didn't cause a double work here
[17:31] <slangasek> koike: don't worry; my changes are just fixing the order of stanzas in the file
[17:33] <cyphermox> slangasek: ok
[18:58] <pitti> lamont: did you try booting with systemd.debug-shell? (should be on Ctrl+Alt+F8)
[19:00] <lamont> pitti: you're assuming I have more than ttyS1
[19:00] <lamont> that's all I have
[19:01] <pitti> ah, difficult then; after that there's little room for getty etc.; nothing should run then except /lib/systemd/systemd-shutdown, which essentially just umounts root and tells the kernel to power off
[19:02] <pitti> booting with "debug console=ttyS1" might still help a bit
[19:32] <nacc> slangasek: so memcached's configure script has a check to determine if it needs to do alignment or not, but it passes -O2 to the test compilation, which leads to a successful test of the program. If I manually pass no optimization flags, the test correctly raises a SIGBUS. Thoughts?
[19:34] <slangasek> nacc: on a Linux system, messing around with possibly /not/ aligning is a waste of effort; there are various cases where the build and runtime behavior can be legitimately different, and even if the test succeeds it's an inefficiency in CPU and/or kernel to do the fix-up on userspace's behalf
[19:35] <slangasek> nacc: just neuter the test and always choose to align
[19:35] <nacc> slangasek: ok, i'll test that -- probably worth sending upstream too then?
[19:35] <slangasek> the test succeeding or failing with different optimization levels is interesting, but not predictive
[19:35] <slangasek> nacc: IMHO yes
[19:35] <nacc> slangasek: ok, thanks!
[19:36] <slangasek> maybe they have users on other platforms who wouldn't like alignment to be enforced, but I don't know what those are
[19:47] <nacc> slangasek: is this the wrong way to go about it? the build succeeds with this patch, and afaict, there is no configure flag i can pass to say force alignment http://paste.ubuntu.com/23281367/
[19:48] <nacc> oh i might not need to patch configure.ac anymore
[19:48] <slangasek> nacc: that's what I would look to do
[19:49] <slangasek> (though I would patch configure.ac and make sure the package used dh_autoreconf for configure)
[19:49] <nacc> slangasek: yeah, i think it used to -- but there are changelog entries indicating memcached doesn't play properly with dh_autoreconf
[19:49] <nacc> i'll try and investigate that
[19:53] <nacc> slangasek: ah ok, i misread the changelog, so just patching configure.ac is sufficient
[20:02] <nacc> jgrimm: --^ thanks to slangasek's help, memcached's ftbfs is fixed, so i think -server is now clean (pending another test rebuild for the remaining packages, and hopefully LocutusOfBorg figuring out llvm-toolchain-3.6). coreycb, I'm assuming you've got a handle on nova still?
[20:02] <jgrimm> :) nice. thanks nacc
[20:04] <coreycb> nacc, yep, I've got nova
[20:04] <nacc> coreycb: great, thanks for confirming
[20:16] <juliank> I'm starting preparing the apt 1.2.15 update for xenial. It's gotten a bit large, it really should have been 3 to 4 updates, but 1.3 development was too busy. Sources for RC1 are available at https://launchpad.net/~deity/+archive/ubuntu/apt-1.2 - binaries should get building soon
[20:17] <juliank> The 1.2.15 update will fix the autoremoval code to only consider the latest provider of a given source package for protecting, so older kernels can effectively be removed even if some of their provides are being depended upon by other packages.
[20:18] <juliank> It also fixes a ton of other bugs and buffer overflows and maybe underflows
[20:18] <juliank> Overall, I cherry-picked 54 commits since 1.2.14
[20:20] <juliank> Feedback is appreciated. I'll put this on my server-playing thinkpad once the PPA is built and give it a drive for a few days
[20:45] <LocutusOfBorg> nacc, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/6984130/+listing-archive-extra
[20:46] <LocutusOfBorg> can't reproduce
[21:25] <juliank> kirkland: I'm playing around with byobu and wondering if there's a way to make it automatically pick the last session when starting, as asked in http://askubuntu.com/questions/798763/how-to-make-byobu-automatically-select-last-used-session
[21:58] <slangasek> coreycb: looks like nova autopkgtests still fail on armhf and s390x?
[22:00] <slangasek> if nova's systemd units are relying on timeouts to detect daemon starts, may I suggest trepanning
[22:05] <nacc> LocutusOfBorg: hrm, strange! care to upload?
[22:21] <coreycb> slangasek, that was a lame attempt at a fix.. it turned out the service is continually restarting on all arch's, and just not getting lucky on armhf and s390x.  what do you mean by trepanning?
[22:21] <coreycb> slangasek, I have a config option change that I'm testing to fix it
[22:21] <slangasek> coreycb: I mean someone needs to let the evil spirits out of the head of whoever thought of implementing the service this way ;)
[22:21] <coreycb> slangasek, agreed, it's not very intelligent
[22:38] <nacc> from a process perspective, -updates and -security packages may not go through -proposed? Is that accurate?
[22:38] <nacc> and by may, I mean 'might'
[22:40] <slangasek> nacc: true
[22:41] <nacc> slangasek: thanks!
[22:42] <Unit193> slangasek: FWIW, you can change the topic with  /cs topic #ubuntu-devel Foo  now, when you're identified.
[22:42] <slangasek> Unit193: what's '/cs'?
[22:42] <Unit193> slangasek: Sorry, /msg ChanServ
[22:43] <slangasek> ok
[22:51] <nacc> rbasak: fyi, just shot you a couple MRs, no need to review them, they are for our process discussion
[23:25] <nacc> smb: not sure if you've seen LP: #1591695, but given that someone is trying to contribute, would be good to pick up their change, if reasonable
[23:27] <rbasak> nacc: ack, thanks
[23:29] <nacc> rbasak: also, i'm thinking we might be able to take LP: #1519120 off of the server-next list, unless you think wes should look at the NM changes GUI changes?
[23:29] <nacc> and maybe replace it on the list with LP: #1541678
[23:30] <nacc> ah i see it was
[23:30] <nacc> and assigned to you, rbasak :)
[23:31] <rbasak> nacc: 120 I disambiguated in #14
[23:31] <rbasak> comment #14
[23:31] <rbasak> I'd be fine pulling that from server-next
[23:31] <rbasak> And only leave us subscribed to follow any non-NM developments
[23:31] <rbasak> (since it was confused with the separate vlan package bug)
[23:32] <nacc> ack
[23:32] <nacc> (and done)
[23:32] <rbasak> Thanks!