[00:37] <infinity> pitti: *poke*
[00:37] <pitti> infinity: hey
[00:38] <infinity> pitti: trusty-adt-libproxy-ppc64 <-- Why is that not using the dpkg arch (ppc64el)?
[00:38] <infinity> pitti: ppc64 is very much not the same thing. :)
[00:39] <infinity> pitti: (And don't go away, I have more important things to discuss)
[00:39] <pitti> infinity: ah, thanks for pointing out; the view name etc. is right, just not the suffix; I asked jibel to rename them
[00:41] <infinity> pitti: Alright, cool.  Simple annoyance, that one.
[00:42] <infinity> pitti: So, the more important thing... We need to completely flush all the ppc64el ddebs/indices from germanium and re-import fresh from the buildds.
[00:42] <infinity> pitti: My cron job that cleans old ddebs is intentionally off for now, so there should be a full set avaiable to scrape.
[00:42] <pitti> infinity: ah, good; setting that off now
[00:43] <infinity> pitti: Just make sure it's actually flushed sanely first, since I know ddebs operated on a naive first-come-first-published basis, and we've, of course, rebuilt the whole world with identical versions/filenames.
[00:44] <pitti> infinity: I can make sure that the latest build wins, that ok?
[00:44] <infinity> pitti: Still not quite ideal, as you may have ddebs that matchs things that don't exist anymore, as we had new FTBFSes.
[00:44] <infinity> pitti: Is flushing really hard?
[00:44] <pitti> *meh* need more interweb tubes here
[00:45] <pitti> infinity: no, it's not; I meant the order of re-pulling them from the buildds
[00:45] <infinity> pitti: If so, then yeah, latest-build-wins would probably work for now, and we can not care about those few.
[00:52] <infinity> pitti: '*_ppc64el*deb' please.  Your will catch a few packages with ppc64el in the name on other arches. :P
[00:52] <pitti> *nod*
[00:52] <infinity> pitti: And if you go back a week, you should be fine.  Might want to limit it to just the 10 ppc64el buildds, so you're not reimporting EVERYTHING.
[00:54] <pitti> infinity: hm, lp.builders objects have no .arch property or something like that? meh
[00:54] <pitti> so, 'ppc64el' in .title
[00:56] <infinity> pitti: Title should do.  Or just limiting to fisher*, denneed* and postal*
[00:56] <cyphermox> doko: I can, but it's been that way forever, this isn't something I added recently
[00:56] <cyphermox> that said, it's not a reason to keep this old thing around
[00:58] <pitti> infinity: purged, slurping ddebs from the ppc64el builders (the title hack works)
[01:00] <infinity> pitti: Huzzah.  Let me know when the slurping appears to have been successful, so I can un-hack my cronjobs and let them purge again.
[01:01] <pitti> infinity: ah, it's now at feb 18; I guess that's the day of the Mass Rebuild Of Death, given how much time it spends on that one :)
[01:01] <pitti> I started with Feb 14
[01:04] <infinity> pitti: Started on Feb17, but definitely more packages in Feb18, yeah.
[01:26] <pitti> infinity: all slurped; rebuilding indexes now
[01:30] <infinity> pitti: \o/
[01:30] <infinity> pitti: Thanks.
[02:25] <ScottK> slangasek: Kubuntu wants Qt5 5.2 in.
[02:52] <slangasek> ScottK: ok.  Is any further testing coordination needed wrt Kubuntu, or should we just get it in ASAP?
[02:52] <ScottK> slangasek: Get it in ASAP.
[02:53] <ScottK> We mostly want it in 14.04 so we can backport KDE Frameworks 5 after it's released.
[02:54] <slangasek> ok
[04:51] <ESphynx> hey guys :) still hope to have packages brought in? ;)
[06:31] <dholbach> good morning
[06:32] <ion> that
[06:33] <ESphynx> hey nisstyre :)
[06:33] <ESphynx> good morning dholbach
[06:33] <dholbach> hi ESphynx
[06:34] <ESphynx> dholbach: archive is still open eh?
[06:36] <dholbach> ESphynx, I guess - I haven't heard otherwise
[06:37] <ESphynx> I'm praying my release makes it in somehow :P
[08:25] <fishor> hello devs. http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/ usually provide lates vanilla build. but last build there is 3.13.0
[08:25] <fishor> should it be this way?
[09:38] <jhenke> hi guys
[09:41] <jhenke> cjwatson do you have some time to look at bug #1272664 that had been assinged to you?
[11:09] <tkamppeter> OdyX, hi
[11:16] <infinity> slangasek: Argh.  The new libcap-dev includes <linux/xattr.h> which conflicts with <sys/xattr.h>, which is the cause of your qemu FTBFS across the board.
[11:17] <infinity> slangasek: I was about to blame my new glibc until I looked closer.
[11:37] <infinity> slangasek: Though, it might be that I need to work around this in glibc headers with some undefs, like I did for P_* :/
[11:38] <infinity> I really need to find the time to do some broader comparison of kernel/glibc type mismatches here.
[11:52] <infinity> slangasek: Something like this might minimize the damage for now: http://paste.ubuntu.com/6970443/
[14:01] <ScottK> pitti: Are you dealing with things like https://jenkins.qa.ubuntu.com/job/trusty-adt-postfix-armhf/ or should lamont and I care?  It looks like something test environment related rather than a package issue.
[14:06] <rbasak> ScottK: did you see the announcement?
[14:21] <cjwatson> jhenke: probably not for a while, sorry, am buried in libclick
[14:21] <kenvandine> @pilot in
[14:56] <jhenke> cjwatson okay, do you know anybody else who can help with that issue? If not, I can wait, just want to avoid that the bug get's completely forgotten
[15:00] <ScottK> rbasak: I did (after I wrote that).
[15:50] <stokachu> anyone willing to sponsor/upload bug 1282837 for me?
[16:02] <kenvandine> @pilot out
[16:09] <didrocks> stgraber: hey, once you have a second, I used a new fakeupdate parameter to test animation changes and so on, is it fine with you? https://code-review.phablet.ubuntu.com/#/c/183/
[16:11] <mterry> pitti, what is the state of the art for faking a text message?  Is is still manually sending javascript to the phonesim daemon?
[16:11] <pitti> Good morning
[16:11] <mterry> (on the phone)
[16:11] <mterry> pitti, good morning  :)
[16:12] <pitti> mterry: by and large yes, but have a look at the messaging-app AP tests; they have a helper function which is by and large just receive(sender, text)
[16:12] <mterry> pitti, OK will steal  :)  thanks!
[16:14] <stgraber> didrocks: I already gave my +1 to sergiusens
[16:15] <pitti> ScottK: the "AttributeError: 'NoneType' object has no attribute 'quit'
[16:15] <pitti> ScottK: how is that an infrastructure problem?
[16:15] <pitti> ScottK: it could be yet another fallout from switching default python3 to 3.4
[16:15] <pitti> I haven't yet waded through all the failures
[16:15] <didrocks> stgraber: ah, thanks :)
[16:16] <smb> pitti, Just since you mention that, I saw those relatively often in update output
[16:17] <pitti> another fallout is that a lot of packages' postinst now have some AttributeError in __del__()
[16:17] <smb> Oh so that one actually
[16:19] <rsalveti> xnox_: hey, would need gcc-i686-linux-androideabi or similar to be able to build the x86 emulator :-)
[16:25] <ScottK> pitti: No idea.  I just know it worked last week on i386/amd64 and there's nothing armhf specific in the failure.
[16:27] <pitti> ScottK: yeah, last week we still had py 3.3
[16:27] <brendand> barry, i have a python itch to scratch and google isn't helping me - maybe you know the answer. it seems python memoizes recursive functions, but i was wondering how/when it does this - surely it's not as simple as when the function is called with the same inputs?
[16:27] <ScottK> Right, so by "infrastructure", I meant not the package.
[16:28] <pitti> ScottK: at least it worked on x86 yesterday
[16:29] <pitti> ScottK: it might also be possible that it's due to qemu vs. LXC; the LXC runner is quite a bit stricter (it has less dependencies pre-installed, so a lot of failures are due to insufficient binary and/or test dependencies)
[16:29] <pitti> s/less deps/less packages/
[16:29] <pitti> and s/less/fewer/, but meh @ grammar :)
[16:30] <pitti> ScottK: anyway, as I wrote on the annoucement this is pretty much a "throw everything against the wall and see what sticks" run, we don't gate on it for now
[16:33] <barry> brendand: "memoizes recursive functions"?   not really sure what that means.  it does keep a recursion count and  will throw a RuntimeError if the recursion depth is exceeded.  sys.getrecursionlimit() and sys.setrecursionlimit() control that
[16:34] <brendand> barry, memoization is where you store the result of a call in a table and don't bother to call the function if the result for the same inputs is already there
[16:34] <brendand> barry, but i just realized the function i was working on wouldn't trigger this anyway
[16:35] <xnox_> rsalveti: ok. I'll try to cook that.
[16:35] <rsalveti> xnox_: thanks
[16:35] <barry> (there are actually multiple meanings of "memoize"; in the python context i's mostly closely associated with pickling)
[16:36] <barry> brendand: python doesn't memoize in the sense that you're describing, however it's pretty trivial to write a descriptor that does that for you.  that's used some times for expensive operations, but you have to be careful about the semantic differences it can imply
[16:52] <xnox_> barry: doko: what's up with subprocess NoneType stuff? it seems to be triggered by py3compile.
[16:53] <barry> xnox_: i've seen that too.  haven't had time yet to investigate
[16:53] <xnox_> barry: it appears that __del__ of subprocess does "if not getaatr(self, '_child_created', False)
[16:54] <doko> xnox_, didn't look at it yet
[16:54] <xnox_> but.... self is NoneType?!
[16:55] <dholbach> hey... can somebody check if ubuntu-html5-platform-3.4-dev (from the cordova-ubuntu-3.4 source package) is downloadable/installable in trusty proper?
[16:55] <barry> xnox_: i wonder if this is happening at interpreter shutdown time.  maybe during cycle breaking by the gc?  when python shuts down it first sets all module attributes to None, but doesn't clear out its namespace.
[16:55] <dholbach> according to https://launchpad.net/ubuntu/+source/cordova-ubuntu-3.4/3.4~pre3.r19 it should be there for amd64/i386/armhf - and not in binNEW
[16:56] <dholbach> ^ maybe an archive admin can shed some light on this?
[16:56] <dholbach> seb128, are you still around and know what might be the problem?
[16:59] <dholbach> seb128, alex-abreu: false alarm
[16:59] <dholbach> Get:1 http://archive.ubuntu.com/ubuntu/ trusty-proposed/universe ubuntu-html5-platform-3.4-dev amd64 3.4~pre3.r19 [2157 kB]
[16:59] <dholbach> Fetched 2157 kB in 2s (965 kB/s)
[16:59] <dholbach> alex-abreu, ^ we're fine
[16:59] <Laney> it's not migrating to release though
[16:59] <dholbach> ah, you're right
[16:59] <Laney> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#cordova-ubuntu-3.4 is telling you that there's a leftover cordova-ubuntu-3.4-dev package in trusty-proposed
[16:59] <alex-abreu> dholbach, ah its in proposed!
[16:59] <dholbach> pbuilders have proposed enabled
[17:00] <dholbach> Laney, what can we do?
[17:00] <Laney> an archive admin will need to remove it
[17:00] <dholbach> alex-abreu, can you maybe try talking to anyone of these folks about it? https://launchpad.net/~ubuntu-archive/+members#active
[17:01] <alex-abreu> jdstrand, might be around
[17:03] <dholbach> alex-abreu, got to go - drop me a mail if you need anything from me later on!
[17:03] <alex-abreu> dholbach, sure
[17:03] <alex-abreu> dholbach, I'll ry to unblock it
[17:03] <dholbach> thanks a bunch!
[17:03]  * dholbach hugs alex-abreu and Laney
[17:03] <dholbach> have a great weekend evryone
[17:04] <Laney> you too
[17:04] <Laney> bye!
[17:22] <xnox_> infinity: why do you hate venezuela? =)
[17:22] <xnox_> # localedef -c -f UTF-8 -i es_VE es_VE.UTF-8
[17:22] <xnox_> LC_MONETARY: value of field `int_curr_symbol' does not correspond to a valid name in ISO 4217
[17:30] <xnox_> infinity: filed bug 1283152
[17:33] <jtaylor> is there some summary page of the difference between to adt runs in jenkins?
[17:35] <jtaylor> artifacting dpkg -l or so would be useful
[17:35] <jtaylor> then one could diff it
[17:37] <cjwatson> looks like jdstrand has cleaned up the cordova-ubuntu-3.4-dev binary
[17:50] <slangasek> infinity: ah, it's libcap-dev's doing?  ok - I think we should make hallyn fix it then, since he's the one who said we needed libcap updated :)
[17:51] <hallyn> sup?
[17:52] <dbarth> hiya, i'm looking for an archive admin to help unblock a package that is stuck in proposed
[17:52] <alex-abreu> dbarth, done already :)
[17:52] <dbarth> oops, scratch that,
[17:52] <dbarth> sorry
[17:54] <hallyn> slangasek: I'm not seeing anything obvious;  are you saying ppc64el is broken by the new libcap?
[17:54] <slangasek> hallyn: qemu FTBFS because of the new libcap
[17:54] <slangasek> so I thought you might like to have a look ;)
[17:54] <hallyn> "I don't see how that relates to me"
[17:54] <hallyn> i'll take a look, thanks
[18:04] <jdstrand> cjwatson: I did
[18:04] <jdstrand> and now cordova-ubuntu-3.4 has migrated
[18:04] <Laney> happy daze
[18:20] <hallyn> slangasek: well holy cheeseballs, /usr/include/linux/capability.h has mis-matched parens in the last define
[18:20] <hallyn> oh no
[18:20] <hallyn> i need new glasses
[18:20] <jtaylor> hm libc 2.19 broke scipy :(
[18:24] <jtaylor> any other known fallout by the upload?
[18:25] <jtaylor> infinity: ^
[18:27] <jtaylor> hm it might actually be that it fixed its math functions but scipy tests used wrong ulps
[18:30] <infinity> hallyn: Check backscroll for my explanation to Steve.
[18:30] <infinity> hallyn: Long story short, something like this would work around the mismatched macros between linux headers and userspace headers: http://paste.ubuntu.com/6970443/
[18:31] <infinity> jtaylor: Nothing that I know of yet.
[18:31] <hallyn> infinity: so you can't define something in enum that is #defined?
[18:31] <hallyn> i wonder if there is a reason for those to be an enum
[18:32] <infinity> hallyn: The reason for them being an enum is actually to guard against the inverse.
[18:33] <infinity> hallyn: Which, I suppose, means one could also just include sys/foo.h before linux/foo.h to sort the issue.
[18:33] <hallyn> oh i see now.  i simply could not reproduce the issue in a standalone c program, finally did
[18:34] <hallyn> so yeah i think #include sys/foo.h is the way to go...
[18:37] <infinity> jtaylor: And yes, jsm has been working hard upstream on making libm be less math challenged, so it's possible that some things that rely on its bugs may be a bit out of whack.
[18:37] <jtaylor> well scipy tests against a infinite precision library
[18:37] <jtaylor> so I chances are its worse now
[18:38] <infinity> jtaylor: (I'd content that anything that relies on exact values from libm was always buggy to start with, since libm makes approximation commitments, not precision... If you need precision, you need something slow and correct, like GPM)
[18:38] <jtaylor> but I'm still trying to extract the inputs :/
[18:38] <infinity> s/content/contend/
[18:38] <jtaylor> well C99 appendix gives bounds on what libc should provide
[18:38] <jtaylor> most don't follow it though
[18:38] <jtaylor> glibc is actually one of the better ones
[18:38] <infinity> Yeah, we're working on being more compliant than we were. :)
[18:39] <jtaylor> I still ahve a huge stack of complex trigonometry bugs to fowrard to glibc :/
[18:39] <hallyn> infinity: (I don't have upload rights) do you  mind pushing the new libcap with that change?  I've emailed amorgan (the upstream maintainer) to let him know, in the meantime
[18:40] <infinity> hallyn: Sure.  Might be worth a quick qemu test build against such a mangled header to make sure it doesn't blow up in new and exciting ways.
[18:41] <infinity> hallyn: But that should do the trick.
[18:41] <hallyn> yeah, and my first attempt failed,
[18:41] <hallyn> but i may have left some garbage,
[18:42] <infinity> hallyn: And by "that change", I assume you mean http://paste.ubuntu.com/6972335/ ?
[18:42] <hallyn> i did.  if it turns out that didn't jsut break my qemu build even more
[18:43] <hallyn> well hey, btrfs really *has* sped up on fsync in trusty
[18:43] <infinity> It shouldn't, but I'll spin up a test here for paranoia's sake.
[18:49] <doko> Trying easy from adconrad: ruby-defaults/1:1.9.3.4 ruby2.0/2.0.0.484-1ubuntu1 ruby1.9.1/1.9.3.484-2ubuntu1
[18:49] <doko> leading: ruby-defaults,ruby2.0,ruby1.9.1
[18:49] <doko> failed: ruby-defaults
[18:49] <doko> but doesn't show anything anymore ...
[18:49] <hallyn> all right.  it's noticably faster, but still eatmydata-worthy
[18:57] <pitti> thomi: https://blueprints.launchpad.net/ubuntu/+spec/core-1311-python3-roadmap
[19:02] <hallyn> infinity: looks like i'd left something in a bad state :) in a new environment it builds fine with that change
[19:04] <infinity> hallyn: Yeah, getting to that conclusion here too.   Slowly.
[19:09] <hakermania> Hello there! I am looking for a sponsor for my package, Wallch. If you want to sponsor it or you know someone interested, please let me know! https://bugs.launchpad.net/ubuntu/+source/wallch/+bug/1282830
[19:11] <rcj> hallyn, if you get a qemu-util package for ppc64el built while you're working on this, could you put it up for me to grab?  I'm blocked at the moment waiting for qemu-img
[19:12] <infinity> rcj: That will fall out from my libcap upload.
[19:12] <infinity> (As in, the change you want is uploaded but FTBFS)
[19:13] <rcj> infinity; thanks.  just trying to determine the fastest route to get back up and running with qemu-img.
[19:18] <infinity> hallyn: Uploaded, I'll retry qemu when it's published.
[19:18] <jtaylor> mh ok glibc 2.19 produces worse results
[19:18] <infinity> jtaylor: :(
[19:18] <infinity> jtaylor: In which function(s)?
[19:19] <jtaylor> still checking where exactly, but mpmath is correct and the error is significant
[19:20] <infinity> jtaylor: Could it, perhaps, be a need for -ffp-contract=off somewhere?
[19:20] <jtaylor> I don't have fma
[19:20] <jtaylor> also thats off by default in gcc4.9
[19:20] <jtaylor> oh we are still 4.8
[19:20] <infinity> 4.8 defaults to fast.
[19:20] <jtaylor> 4.9 not, at least in c99 mode
[19:21] <jtaylor> but its not out yet, got confused as I'm running with that since a while :/
[19:21] <infinity> hallyn: http://launchpadlibrarian.net/167203424/libcap2_1%3A2.24-0ubuntu1_1%3A2.24-0ubuntu2.diff.gz has a slightly more upstream friendly explanation than just "Argh" in the patch header.
[19:23] <jtaylor> oh no it goes into fortran code :(
[19:37] <hallyn> rcj: I'm afraid I don't have any, sorry.  But should be building in archive soon iiuc
[19:40] <hallyn> infinity: but to prevent more failures later, should the libc6 version put the enum inside a #ifndef XATTR_CREATE?
[19:41] <infinity> hallyn: Possibly, yes.  I did this for another set of defines earlier for similar fallout.
[19:42] <infinity> hallyn: But I think I need to bring this up upstream to see if we need to be doing a full userspace/kernel macro clash audit.
[19:42] <hallyn> upstream glibc?
[19:45] <infinity> hallyn: Yeah.
[19:46] <infinity> hallyn: I still blame the kernel for its defines not being enum-guarded, but even if we get that fixed, glibc needs to work with some subset of old kernels, so we might need to sprinkle some idef guards around too.  Fun, fnu.
[19:46] <apw> infinity, enum guarded
[19:46] <apw> ?
[19:49] <infinity> apw: Remember the P_ALL, etc issue we discussed a while back?
[19:50] <apw> yeah i remember that issue, painfully
[19:51] <infinity> apw: Right.  Basically ran into a redux of the same thing when one includes linux/xattr.h and sys/xattr.h out of order (ie: kernel before userspace).
[19:51] <infinity> Not sure if this is spelled out somewhere as a big no-no (I mean, other than including kernel headers at all being a no-no), but there are clearly some larger issues at play here that I think warrant discussion.
[19:52] <apw> its all a twisty maze with glass on the floor
[19:56] <hallyn> arges: were you going to verify bug 1277157 ?
[19:56] <hallyn> the test case can't quite work for precise - bc libvirt isn't built against netcf there.  but even after rebuilding libvirt i coudln't reproduce it.  sadly.
[19:57] <arges> hallyn: hi
[19:58] <slangasek> infinity: qemu given back
[20:00] <arges> hallyn: so the libvirt in the bug comes from the cloud-archive
[20:00] <infinity> slangasek: Ta.
[20:01] <arges> hallyn: i'm having the reporter verify this on his machine, is this blocking something for you?
[20:01] <hallyn> arges: hm, as i said though a manually rebuilt libvirt with netcf support didn't reproduce it.  i can try cloud-archive in a bit...
[20:01] <hallyn> thx
[20:01] <hallyn> no, i just don't like to let things slip through the cracks
[20:01] <hallyn> and then months down the road we have an unverified sru
[20:01] <hallyn> thanks - i'll wait for results from teh reporter!  that's perfect
[20:01] <arges> hallyn: i don't like unverified srus either : )
[20:02] <arges> yea i'm also setting up my big machine to see if I can do some local testing too, let me know if you get anywhere with this one
[20:02] <slangasek> hallyn: any reason not to push the qemu arm64 patches to Debian?
[20:02] <hallyn> slangasek: now that they're upstream, probably not.
[20:02] <hallyn> slangasek: mjt may want to just wait for 1.8
[20:03] <slangasek> hmm; I suppose it is rather a large patchset, would be rude to foist that on Debian if the maintainers weren't prepared to absorb them :)
[20:03] <hallyn> let's ask
[20:04] <slangasek> I was just planning to push back the debian/control changes, and found a much bigger delta than I expected
[20:05] <hallyn> stgraber: ok lemme address the missing --dir
[20:06] <hallyn> slangasek: yeah the number of patches is impressive
[20:06] <slangasek> hallyn: have you by chance been rebasing these branches, rather than merging them?  because 6c93231780ecc89ac9e64686dd3247437d4b0696 doesn't look like a merge :)
[20:07] <slangasek> (guess I won't be cherry-picking ;p)
[20:07] <hallyn> slangasek: they have to be rebased bc we also have the omap3 patchset
[20:07] <slangasek> maaaan
[20:07] <hallyn> oh that
[20:08] <hallyn> slangasek: yes i *intended* with the latest merge to make it a complete sync.  However mjt calmed down from that...
[20:08] <hallyn> wisely
[20:08] <slangasek> ah, well
[20:08] <hallyn> i worked toward it partially which is how i bricked some machines
[20:08] <slangasek> it's still not a merge topologically :)
[20:09] <hallyn> with the *next* merge i may make it completely syncable
[20:09] <hallyn> what do you mean?
[20:09] <slangasek> hallyn: do you know why /usr/share/qemu/OVMF.fd is in qemu-system-common, when all the other firmware bits are in qemu-system-x86?
[20:09] <slangasek> hallyn: I mean that 'git log debian/qemu-system-common.links' shows that the history of this file starts and ends with the latest merge
[20:10] <hallyn> not sure, i don't recall making a change there
[20:12] <slangasek> seems to have happened with the binary package reorg, post-quantal
[20:12] <hallyn> is OVMF useful on any other arches?
[20:12] <slangasek> hallyn: *this* build of OVMF certainly isn't :)
[20:12] <slangasek> there are open bug reports in both Ubuntu and Debian asking to build it for other archs beside x86_64, but then each of those would need its own symlink
[20:12] <slangasek> so I think I'll just arrange to move that into qemu-system-x86
[20:13] <hallyn> sounds good
[20:20] <hallyn> slangasek: so how would the OVMF.fd filenames look if different arches were supported?  /usr/share/ovmf/ovmf-$arch.fd ?
[20:20] <slangasek> hallyn: undecided :-)
[20:20] <hallyn> ok
[20:20] <hallyn> guess i need to be looking at that pkg.  i've been negligent there
[20:21] <slangasek> I suppose I would leave /usr/share/ovmf/ovmf.fd in place for backwards-compatibility, and then use ovmf-$efiarchname.fd
[20:21] <jtaylor> infinity: that doesn't look right: http://paste.ubuntu.com/6972824/
[20:21] <hallyn> yeah
[20:21] <jtaylor> though maybe its the debugger
[20:23] <infinity> jtaylor: I'm pretty wildly unfamiliar with libm.  If you do find issues, an upstream bug report would probably work out better than trying to educate me. :)
[20:24] <infinity> jtaylor: I know the testsuite passes within whatever acceptable ULPs upstream has defined, but that's about as far as my libm usage goes.
[20:41] <jtaylor> k filed a bug
[20:41] <jtaylor> http://sourceware.org/bugzilla/show_bug.cgi?id=16623
[20:48] <jtaylor> fwiw I think its a bug, that number should just still be in the range where glibc can give a right result
[20:48] <jtaylor> at least +- 0.1
[20:53] <ogra_> stgraber, wow, you got a special edition of the german ix magazine (professional it magazine) about LXC ! congrats !!
[20:54] <ogra_> (and you are mentioned in the announcement, i bet they just translated your blog ;) )
[20:54] <stgraber> ogra_: hehe, yeah, I saw a lot of hits coming from heise.de and referring to that magazine
[20:54] <ogra_> yeah
[21:31] <pitti> slangasek: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest%20ppc64el/ :)
[21:33] <slangasek> pitti: whoo! thanks :)
[21:33] <slangasek> pitti: the ppc64 junk jobs still need removing, I guess?
[21:34] <pitti> slangasek: correct, that RT is still pending
[21:34] <slangasek> ok
[21:34] <pitti> slangasek: wolfe-05 ran out of disk space, I'll clean up (bah jenkins leaking all its files) and retry jobs
[21:35] <pitti> *phew*, we've worked on hardly anything else than ppc/armhf tests this week, but finally getting there :)
[21:37] <slangasek> pitti: infinity and I are looking at https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest%20ppc64el/job/trusty-adt-coreutils-ppc64el/ ... coreutils passes its test suite at build time, so we're wondering if this is a problem with the test env
[21:37] <hallyn> how weird - i install linux-image-3.2 in precise, and it grabs...   all of the old 3.2 kernels (-24, -25, -26, -26, ... -41, ...)
[21:37] <slangasek> pitti: how can we reproduce the adt environment?
[21:38] <slangasek> hallyn: linux-image-3.2 isn't a real package, so you're getting the benefit of a little-known misfeature that apt supports regexps for installation
[21:38] <pitti> slangasek: debcheckout autopkgtest; sudo tools adt-build-lxc ubuntu trusty
[21:38] <hallyn> slangasek: neat! :)
[21:39] <pitti> slangasek: that's mostly equivalent to sudo lxc-create with the ubuntu template (debootstreap)
[21:39] <pitti> slangasek: then for the actual test: ./run-from-checkout coreutils --- lxc -es adt-trusty
[21:39] <slangasek> pitti: ok.  what does that give us as the backing filesystem? ext4, tmpfs, or some aufs madness? :)
[21:39] <pitti> slangasek: I think --ephemeral defaults to tpmfs and overlayfs
[21:40] <slangasek> pitti: and you're using --ephemeral?
[21:40] <pitti> slangasek: let me run the test on amd64 in LXC
[21:40] <pitti> slangasek: right
[21:40] <slangasek> ok
[21:40] <pitti> ah, need to create a trusty container; argh slow network
[21:40] <slangasek> pitti: do you have more than one test running /in parallel/ using overlayfs against the same base chroot?
[21:41] <pitti> slangasek: on the ppc nodes we have two parallel runs, on armhf just one
[21:41] <pitti> slangasek: if I were to bet, I'd bet it was due to lxc/overlayfs, not ppc
[21:41]  * pitti lets the container build and firefights the wolfes in the meantime
[21:42] <slangasek> pitti: right, please do *not* use multiple overlayfs instances against a single directory on ppc64el; we've seen instabilities with this before
[21:42] <slangasek> (instabilities == filesystem corruption)
[21:42] <pitti> slangasek: ok, good to know; that'll halve our running slots, but I guess they shuld still be able to keep up
[21:42] <slangasek> pitti: couldn't you run two chroots side-by-side?
[21:43] <pitti> slangasek: with some extra hackery and lock files or so, yes
[21:43] <slangasek> pitti: anyway, you do what you need to :) but yeah, parallel overlayfs is unreliable, so if you can fix that and retry the coreutil adt, that'd be keen
[21:44] <slangasek> infinity: ^^
[21:45] <pitti> slangasek: reconfiguring jenkins on our side is a bit tricky, as d-jenkins is broken; jibel will try
[21:46] <infinity> pitti: Oh, if the lxc adt stuff is using overlayfs, we're going to see failures even without the parallel madness.
[21:46] <infinity> pitti: Could I talk you into switching to aufs?
[21:47] <pitti> infinity: it's just using lxc --ephemeral, so whatever it supports
[21:47] <pitti> ah, --union-type
[21:47] <xnox_> pitti: btrfs-snapshots are quite good with that.
[21:48] <infinity> pitti: So, if you really want more parallelism, your better option is to spin up twice as many VMs and overcommit CPU.
[21:48] <infinity> (This is what I've done for the buildds)
[21:49] <pitti> infinity: sounds good; if smoser can give me four more VMs and we'll use only one run slot in each that'd simplify things indeed
[21:55] <pitti> $ sudo lxc-start-ephemeral --union-type=aufs -o adt-trusty
[21:55] <pitti> lxc_container: command get_cgroup failed to receive response
[21:55] <pitti> hmmm; stgraber ^ ?
[21:56] <pitti> infinity, slangasek: I get the same errors on trusty amd64 with a single container (but with overlayfs); trying with clone now
[21:58] <pitti> still 2 test failures, although the output looks cleaner
[21:58] <pitti> FAIL:
[21:58] <pitti> File name too long at -e line 2.
[22:02] <slangasek> "file name too long" - err?
[22:03] <pitti> slangasek: coreutils' adt test is a subset of the upstream tests; if these two don't work in LXC, we can just drop them as well, in the worst case
[22:03] <pitti> slangasek: we already run them during package build, the autopkgtest sohuld mostly be a smoke test
[22:04] <pitti> slangasek, infinity: wolfes reconfigured to only use one running slot
[22:09] <stgraber> pitti: that error is what you get for "generic startup failure" when not attached to the container's console (which is the case with start-ephemeral) so that's not terribly useful. Maybe you're lucky and you get the actual error in /var/log/lxc/ ?
[22:11] <pitti> stgraber: hm, it doesn't create a log file in the first place
[22:12] <pitti> stgraber: /var/log/lxc/ has gazillions of logs, just not for the --union-type=aufs one
[22:12] <pitti> (are these ever cleaned up?)
[22:12] <pitti> uh, apparenlty not, I've got logs from half a year ago
[22:12] <stgraber> hmm, we probably should ship a logrotate config then :)
[22:13] <stgraber> pitti: so one trick you could do is set those two options in your orig container (adt-trusty):
[22:13] <stgraber> lxc.logfile = /dev/stderr
[22:13] <stgraber> lxc.loglevel = debug
[22:13] <stgraber> start-ephemeral will copy that to the aufs clone and you'll get the log output at startup on stderr
[22:14] <pitti> done, but no output at all (except for the cgroup response and the failure notice)
[22:14] <stgraber> that's slightly annoying... how about if you set it to some fs path?
[22:15] <pitti> stgraber: if I run with --union-type=overlayfs the container starts, but still no debugging output
[22:15] <pitti> but I did get /var/log/lxc/adt-virt-lxc-ewfdkd.log
[22:15] <pitti> (zero bytes)
[22:16]  * pitti logs to /tmp/log
[22:16] <pitti> stgraber: got created, but empty
[22:16] <pitti> stgraber: also empty with (working) overlayfs
[22:17] <stgraber> pitti: what version of lxc is that?
[22:17] <pitti> 1.0.0~rc4-0ubuntu1
[22:17] <pitti> stgraber: I didn't dist-upgrade today, might that help?
[22:17] <pitti> (last upgrade yesterday)
[22:17] <stgraber> probably not
[22:17] <stgraber> unless you're using btfs or xfs as your /var/lib/lxc
[22:17] <stgraber> *btrfs
[22:18] <pitti> no, good ol' ext4
[22:19] <stgraber> pitti: ok, well, easiest way to figure this out will be to patch lxc-start-ephemeral, commenting the "if dest.defined: dest.destroy()" after the "The container '%s' failed to start"
[22:20] <stgraber> pitti: that way the container will fail but will still exist on the system, you can then use good old lxc-start on it
[22:20] <stgraber> which should be a bit more useful at telling you what's wrong
[22:22] <pitti> hm, I did that, it still doesn't exist
[22:23]  * pitti adds good old subprocess.call(['bash', '-i']) right after the error message
[22:23] <stgraber> pitti: hmm, maybe that container is actually getting past that point, pass -k then
[22:23] <pitti> still doesn't exist
[22:23] <pitti> perhaps it fails on creation already?
[22:24] <stgraber> pitti: well, let's try something simpler then :)
[22:24] <stgraber> pitti: lxc-clone -o adt-test -n test -B aufs -s
[22:24] <pitti> --keep-data also doesn't work
[22:24] <pitti> lxc_container: No such device - aufs: error mounting /srv/lxc/adt-trusty/rootfs onto /usr/lib/powerpc64le-linux-gnu/lxc options br=/srv/lxc/test/delta0=rw:/srv/lxc/adt-trusty/rootfs=ro
[22:24] <pitti> stgraber: ah, now we are talking
[22:24] <stgraber> progress!
[22:25] <stgraber> pitti: so let's look for the obvious problems: grep aufs /proc/modules
[22:25] <pitti> no hit
[22:25] <stgraber> pitti: modprobe aufs
[22:25] <pitti> $ modinfo aufs
[22:25] <pitti> modinfo: ERROR: Module aufs not found.
[22:25] <stgraber> that'd explain it ;)
[22:25] <pitti> that'd do it
[22:26] <pitti> $ grep AUFS /boot/config-3.13.0-8-generic
[22:26] <pitti> CONFIG_AUFS_FS=m
[22:26] <pitti> LIES!
[22:26] <stgraber> well, that or you didn't reboot the box in a while
[22:27] <stgraber> it could be that the kernel you're running has been uninstalled
[22:27] <stgraber> so the .ko no longer exist on disk
[22:27] <pitti> no, still installed
[22:27] <pitti> -11 is current, -8 is running, -7 to -11 are installed
[22:28] <pitti> meh, and if I reboot I still get -8
[22:28] <stgraber> do you have linux-image-extra-... installed too?
[22:28] <stgraber> because apparently aufs is in that one, not in the main linux-image
[22:28] <pitti> no, I don't; good point
[22:28] <pitti> infinity: vmlinux -> boot/vmlinux-3.13.0-11-generic
[22:29] <pitti> infinity: any idea why after rebooting I still get 3.13.0-8?
[22:29] <stgraber> well, at least that's the case on x86 but since -extra also exists on ppc64el, that may be the case there too
[22:29] <pitti> infinity: oh, nevermind; smoser` needs to reboot the VMs with an explicit -kernel qemu option
[22:30] <pitti> hm, no metapackage for -extra
[22:30] <bdmurray> bdrung: How would you feel about adding enabled architectures information to distro-info?
[22:30] <infinity> pitti: Because smoser's VM setup doesn't have a bootloader.
[22:30] <pitti> ah, linux-image-generic isn't installed
[22:30] <pitti> infinity: right, so I'll need to ask him to reboot with -11
[22:31] <infinity> pitti: Which host is it?  I *might* be able to figure out his setup.  Maybe.
[22:31] <pitti> infinity: wolfe-03 to 06
[22:32] <infinity> No promises that I can decipher his VM setup, it's more complex and abstracted than mine.  But let me have a poke.
[22:36] <stgraber> pitti: so just wondering, are you using overlayfs because you want the overlay on tmpfs feature or just to save you the lengthy initial clone?
[22:41] <pitti> stgraber: both really; whatever makes things faster
[22:41] <pitti> stgraber: well, we haven't actually yet run into a test which is only broken by overlayfs, so it's not that urgent for now
[22:43] <infinity> pitti: Okay, I think I might have it figured out.  Want to poweroff all your guests for me?
[22:43] <infinity> pitti: As for "tests only broken by overlayfs", you'll find that glibc's testsuite fails. :/
[22:43] <infinity> (And it's fine on aufs)
[22:44] <stgraber> I'd also expect upstart's testsuite to fail on overlayfs, not sure about aufs
[22:44] <pitti> infinity: ah, good; well, let's find out after the reboot with overlayfs
[22:44] <pitti> err, with -11
[22:45] <pitti> infinity: shutdown; that'll kill some tests, I'll retry them later
[22:46] <sarnold> pitti: there's some trusty bugs that are failing the retracing, two at-hand examples: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1283000 https://bugs.launchpad.net/ubuntu/+source/doodle/+bug/1283259
[22:49] <infinity> pitti: Just grabbing a kernel and scping it around.  Be with you shortly.
[22:56] <pitti> sarnold: they can't find glib, gdk-pixbuf and friends, that's a bit odd
[22:56] <pitti> sarnold: I can't spend much time on that now I'm afraid; could you send me a mail about this for next week?
[22:56] <sarnold> pitti: sure
[22:56]  * infinity wonders what's gone wrong with the pty setup on this machine...
[22:57] <pitti> sarnold: oh, WTH -- are you using some PPA?
[22:57] <infinity> [shared@wolfe ~]$ screen -S wolfe-03
[22:57] <infinity> Cannot open your terminal '/dev/pts/8' - please check.
[22:57]  * infinity grumps.
[22:57] <pitti> WARNING: /lib/i386-linux-gnu/libglib-2.0.so.0.3990.0 is needed, but cannot be mapped to a package
[22:57] <sarnold> pitti: dunno, I'm just trying to move bugs out of the security queue so they stand a chance of being fixed :)
[22:57] <pitti> sarnold: nevermind, mis-looked
[22:58] <infinity> smoser`: Don't suppose you're around to tell me what's up with your screen setup?
[22:58] <pitti> sarnold: yeah, that's fine; we have no shortage of failed-to-retrace bugs, if someone wants to investigate all them we have enough work for 20 years :)
[22:59] <infinity> Oh, might be a non-login shell issue.
[22:59] <sarnold> pitti: ha! :) it just feels like lately there's more 14.04 bugs coming throuh than I would have expected, and I'd hate if some of them just didn't get the attention they deserved because they stayed locked up
[23:00] <infinity> Rightm, problem solved.
[23:01] <infinity> pitti: Can you check wolfe-03 appears to be the kernel you want?
[23:01] <pitti> infinity: LGTM
[23:01] <pitti> and look, aufs
[23:02] <pitti> and it works with -ephemeral
[23:03] <infinity> pitti: 4, 5, and 6 should be up now too.  Those were all the ones you had, right?
[23:03] <pitti> infinity: right, these four; danke!
[23:10] <pitti> infinity, slangasek: wolfes changed to run tests with aufs now; I retried a few packages, but as we now only have 4 executors it has some queue
[23:20] <pitti> infinity, slangasek: do you think with aufs we can move back to two executors?
[23:21] <bdmurray> pitti: could you look at an aptdaemon mp from me?
[23:22] <infinity> pitti: Not sure.  Can 4 VMs really not keep up right now, or is there just a scary backlog?
[23:22] <pitti> infinity: I think they can keep up, I'm just impatient :)
[23:22] <pitti> infinity: just stop uploading more eglibcs and retriggering $WORLD :-P
[23:22] <pitti> bdmurray: yes
[23:23] <bdmurray> https://code.launchpad.net/~brian-murray/aptdaemon/bug-1266844/+merge/207276
[23:24] <infinity> pitti: What's that?  I can't hear you over the sound of my uploads being AWESOME.  Maybe I'll do another.
[23:26] <pitti> infinity: I have the entire setup of an adt slave scripted now; I could run it on you and make YOU do all the tests in your brain!
[23:27] <infinity> pitti: My integer performance is pretty lousy, I don't think we want that.
[23:27] <infinity> pitti: And don't even get me started on floating point...
[23:27] <slangasek> not to mention *those* filesystem corruption issues
[23:29] <pitti> there, unar fixed
[23:30] <pitti> I'm tempted to upload postgresql-9.3 to fix its tests on lxc, but that'll trigger yet another 20 tests
[23:41] <pitti> bdmurray: do you know under which conditions get_model() returns None?
[23:41] <pitti> bdmurray: I'm afraid I don't quite understand the fix with some more context
[23:49] <bdmurray> pitti: no, however bug 1024590 was fixed similarly in r963
[23:54] <pitti> mdeslaur, sarnold: did you see my postgresql security update? anything you still need from me for that?
[23:55] <sarnold> pitti: mdeslaur is on it, thanks for the fixes :)
[23:55] <pitti> sarnold: great, thanks