=== ajmitch_ is now known as ajmitch === StevenK_ is now known as StevenK === StevenK is now known as Guest99695 === Guest99695 is now known as StevenK === dobey_ is now known as dobey [00:37] pitti: *poke* [00:37] infinity: hey [00:38] pitti: trusty-adt-libproxy-ppc64 <-- Why is that not using the dpkg arch (ppc64el)? [00:38] pitti: ppc64 is very much not the same thing. :) [00:39] pitti: (And don't go away, I have more important things to discuss) [00:39] infinity: ah, thanks for pointing out; the view name etc. is right, just not the suffix; I asked jibel to rename them [00:41] pitti: Alright, cool. Simple annoyance, that one. [00:42] 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] 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] infinity: ah, good; setting that off now [00:43] 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] infinity: I can make sure that the latest build wins, that ok? [00:44] 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] pitti: Is flushing really hard? [00:44] *meh* need more interweb tubes here [00:45] infinity: no, it's not; I meant the order of re-pulling them from the buildds [00:45] pitti: If so, then yeah, latest-build-wins would probably work for now, and we can not care about those few. [00:52] pitti: '*_ppc64el*deb' please. Your will catch a few packages with ppc64el in the name on other arches. :P [00:52] *nod* [00:52] 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] infinity: hm, lp.builders objects have no .arch property or something like that? meh [00:54] so, 'ppc64el' in .title === tsimpson_ is now known as tsimpson === Daviey_ is now known as Daviey [00:56] pitti: Title should do. Or just limiting to fisher*, denneed* and postal* [00:56] doko: I can, but it's been that way forever, this isn't something I added recently [00:56] that said, it's not a reason to keep this old thing around [00:58] infinity: purged, slurping ddebs from the ppc64el builders (the title hack works) === cr3 is now known as Guest25506 [01:00] 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] 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] I started with Feb 14 [01:04] pitti: Started on Feb17, but definitely more packages in Feb18, yeah. === TheLordOfTime is now known as teward === 64MAAD7EP is now known as tgm4883_ [01:26] infinity: all slurped; rebuilding indexes now [01:30] pitti: \o/ [01:30] pitti: Thanks. === Guest25506 is now known as cr3 === cr3 is now known as Guest62484 === FlannelKing is now known as Flannel === Guest62484 is now known as cr3 === cr3 is now known as Guest9780 [02:25] slangasek: Kubuntu wants Qt5 5.2 in. [02:52] ScottK: ok. Is any further testing coordination needed wrt Kubuntu, or should we just get it in ASAP? [02:52] slangasek: Get it in ASAP. [02:53] We mostly want it in 14.04 so we can backport KDE Frameworks 5 after it's released. [02:54] ok === mwhudson is now known as zz_mwhudson === Guest9780 is now known as cr3 === cr3 is now known as Guest63647 === Guest63647 is now known as cr3 === cr3 is now known as Guest73526 [04:51] hey guys :) still hope to have packages brought in? ;) === Guest73526 is now known as cr3 === cr3 is now known as Guest11534 === Guest11534 is now known as cr3 === cr3 is now known as Guest1879 [06:31] good morning [06:32] that [06:33] hey nisstyre :) [06:33] good morning dholbach [06:33] hi ESphynx [06:34] dholbach: archive is still open eh? [06:36] ESphynx, I guess - I haven't heard otherwise [06:37] I'm praying my release makes it in somehow :P === zequence_ is now known as zequence === Guest1879 is now known as cr3 === cr3 is now known as Guest53191 === geser_ is now known as geser === OdyX` is now known as OdyX === Guest53191 is now known as cr3 === cr3 is now known as Guest12544 [08:25] 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] should it be this way? === mthaddon` is now known as mthaddon === apachelogger_ is now known as apachelogger === shijing_ is now known as shijing === Guest12544 is now known as cr3 === cr3 is now known as Guest38187 === mpt_ is now known as mpt === doko_ is now known as doko === Laney changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [09:38] hi guys [09:41] cjwatson do you have some time to look at bug #1272664 that had been assinged to you? [09:41] bug 1272664 in efibootmgr (Ubuntu) "Installing UEFI boot entry on Hyper-V gen 2 corrupts VM configuration, making the VM unuseable" [High,Confirmed] https://launchpad.net/bugs/1272664 === alexlist` is now known as alexlist === Guest38187 is now known as cr3 === cr3 is now known as Guest52463 === tkamppeter__ is now known as tkamppeter [11:09] OdyX, hi === ochosi_ is now known as ochosi === Nigel_ is now known as G [11:16] slangasek: Argh. The new libcap-dev includes which conflicts with , which is the cause of your qemu FTBFS across the board. [11:17] slangasek: I was about to blame my new glibc until I looked closer. === lool- is now known as lool === Guest52463 is now known as cr3 === cr3 is now known as Guest60600 [11:37] 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] I really need to find the time to do some broader comparison of kernel/glibc type mismatches here. [11:52] slangasek: Something like this might minimize the damage for now: http://paste.ubuntu.com/6970443/ === MacSlow is now known as MacSlow|lunch === bluesabre21 is now known as bluesabre2 === Guest60600 is now known as cr3 === cr3 is now known as Guest19129 === MacSlow|lunch is now known as MacSlow === Guest19129 is now known as cr3 === cr3 is now known as Guest60280 === sforshee` is now known as sforshee === AbsintheSyringe is now known as fooctrl === Pici` is now known as Pici [14:01] 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. === Trevinho_ is now known as Trevinho [14:06] ScottK: did you see the announcement? === arges_ is now known as arges [14:21] jhenke: probably not for a while, sorry, am buried in libclick [14:21] @pilot in === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kenvandine === Guest60280 is now known as cr3 === cr3 is now known as Guest54261 [14:56] 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] rbasak: I did (after I wrote that). === charles_ is now known as charles === Guest54261 is now known as cr3 === cr3 is now known as Guest75654 [15:50] anyone willing to sponsor/upload bug 1282837 for me? [15:50] bug 1282837 in Ubuntu Trusty "FFe: new package cloud-install" [High,Confirmed] https://launchpad.net/bugs/1282837 [16:02] @pilot out === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [16:09] 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] 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] Good morning [16:11] (on the phone) [16:11] pitti, good morning :) [16:12] 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] pitti, OK will steal :) thanks! [16:14] didrocks: I already gave my +1 to sergiusens [16:15] ScottK: the "AttributeError: 'NoneType' object has no attribute 'quit' [16:15] ScottK: how is that an infrastructure problem? [16:15] ScottK: it could be yet another fallout from switching default python3 to 3.4 [16:15] I haven't yet waded through all the failures [16:15] stgraber: ah, thanks :) [16:16] pitti, Just since you mention that, I saw those relatively often in update output === tgm4883_ is now known as tgm4883 [16:17] another fallout is that a lot of packages' postinst now have some AttributeError in __del__() [16:17] Oh so that one actually [16:19] xnox_: hey, would need gcc-i686-linux-androideabi or similar to be able to build the x86 emulator :-) [16:25] pitti: No idea. I just know it worked last week on i386/amd64 and there's nothing armhf specific in the failure. [16:27] ScottK: yeah, last week we still had py 3.3 [16:27] 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] Right, so by "infrastructure", I meant not the package. === Guest75654 is now known as cr3 [16:28] ScottK: at least it worked on x86 yesterday === cr3 is now known as Guest36078 [16:29] 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] s/less deps/less packages/ [16:29] and s/less/fewer/, but meh @ grammar :) [16:30] 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] 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] 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] barry, but i just realized the function i was working on wouldn't trigger this anyway [16:35] rsalveti: ok. I'll try to cook that. [16:35] xnox_: thanks [16:35] (there are actually multiple meanings of "memoize"; in the python context i's mostly closely associated with pickling) [16:36] 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 === superm1_ is now known as superm1 [16:52] barry: doko: what's up with subprocess NoneType stuff? it seems to be triggered by py3compile. [16:53] xnox_: i've seen that too. haven't had time yet to investigate [16:53] barry: it appears that __del__ of subprocess does "if not getaatr(self, '_child_created', False) [16:54] xnox_, didn't look at it yet [16:54] but.... self is NoneType?! [16:55] 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] 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] 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] ^ maybe an archive admin can shed some light on this? [16:56] seb128, are you still around and know what might be the problem? [16:59] seb128, alex-abreu: false alarm [16:59] 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] Fetched 2157 kB in 2s (965 kB/s) [16:59] alex-abreu, ^ we're fine [16:59] it's not migrating to release though [16:59] ah, you're right [16:59] 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] dholbach, ah its in proposed! [16:59] pbuilders have proposed enabled [17:00] Laney, what can we do? [17:00] an archive admin will need to remove it [17:00] alex-abreu, can you maybe try talking to anyone of these folks about it? https://launchpad.net/~ubuntu-archive/+members#active [17:01] jdstrand, might be around [17:03] alex-abreu, got to go - drop me a mail if you need anything from me later on! [17:03] dholbach, sure [17:03] dholbach, I'll ry to unblock it [17:03] thanks a bunch! [17:03] * dholbach hugs alex-abreu and Laney [17:03] have a great weekend evryone [17:04] you too [17:04] bye! [17:22] infinity: why do you hate venezuela? =) [17:22] # localedef -c -f UTF-8 -i es_VE es_VE.UTF-8 [17:22] LC_MONETARY: value of field `int_curr_symbol' does not correspond to a valid name in ISO 4217 === Guest36078 is now known as cr3 === cr3 is now known as Guest80932 [17:30] infinity: filed bug 1283152 [17:30] bug 1283152 in eglibc (Ubuntu) "es_VE localedef is broken" [Undecided,New] https://launchpad.net/bugs/1283152 [17:33] is there some summary page of the difference between to adt runs in jenkins? [17:35] artifacting dpkg -l or so would be useful [17:35] then one could diff it [17:37] looks like jdstrand has cleaned up the cordova-ubuntu-3.4-dev binary === dbarth__ is now known as dbarth [17:50] 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] sup? [17:52] hiya, i'm looking for an archive admin to help unblock a package that is stuck in proposed [17:52] dbarth, done already :) [17:52] oops, scratch that, [17:52] sorry [17:54] slangasek: I'm not seeing anything obvious; are you saying ppc64el is broken by the new libcap? [17:54] hallyn: qemu FTBFS because of the new libcap [17:54] so I thought you might like to have a look ;) [17:54] "I don't see how that relates to me" [17:54] i'll take a look, thanks [18:04] cjwatson: I did === geoff-- is now known as geoff- [18:04] and now cordova-ubuntu-3.4 has migrated [18:04] happy daze [18:20] slangasek: well holy cheeseballs, /usr/include/linux/capability.h has mis-matched parens in the last define [18:20] oh no [18:20] i need new glasses [18:20] hm libc 2.19 broke scipy :( [18:24] any other known fallout by the upload? [18:25] infinity: ^ [18:27] hm it might actually be that it fixed its math functions but scipy tests used wrong ulps === Guest80932 is now known as cr3 [18:30] hallyn: Check backscroll for my explanation to Steve. === cr3 is now known as Guest87202 [18:30] 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] jtaylor: Nothing that I know of yet. [18:31] infinity: so you can't define something in enum that is #defined? [18:31] i wonder if there is a reason for those to be an enum [18:32] hallyn: The reason for them being an enum is actually to guard against the inverse. [18:33] hallyn: Which, I suppose, means one could also just include sys/foo.h before linux/foo.h to sort the issue. [18:33] oh i see now. i simply could not reproduce the issue in a standalone c program, finally did [18:34] so yeah i think #include sys/foo.h is the way to go... [18:37] 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] well scipy tests against a infinite precision library [18:37] so I chances are its worse now [18:38] 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] but I'm still trying to extract the inputs :/ [18:38] s/content/contend/ [18:38] well C99 appendix gives bounds on what libc should provide [18:38] most don't follow it though [18:38] glibc is actually one of the better ones [18:38] Yeah, we're working on being more compliant than we were. :) [18:39] I still ahve a huge stack of complex trigonometry bugs to fowrard to glibc :/ [18:39] 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] 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] hallyn: But that should do the trick. [18:41] yeah, and my first attempt failed, [18:41] but i may have left some garbage, [18:42] hallyn: And by "that change", I assume you mean http://paste.ubuntu.com/6972335/ ? [18:42] i did. if it turns out that didn't jsut break my qemu build even more [18:43] well hey, btrfs really *has* sped up on fsync in trusty [18:43] It shouldn't, but I'll spin up a test here for paranoia's sake. [18:49] 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] leading: ruby-defaults,ruby2.0,ruby1.9.1 [18:49] failed: ruby-defaults [18:49] but doesn't show anything anymore ... [18:49] all right. it's noticably faster, but still eatmydata-worthy [18:57] thomi: https://blueprints.launchpad.net/ubuntu/+spec/core-1311-python3-roadmap [19:02] infinity: looks like i'd left something in a bad state :) in a new environment it builds fine with that change [19:04] hallyn: Yeah, getting to that conclusion here too. Slowly. [19:09] 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:09] Launchpad bug 1282830 in wallch (Ubuntu) "FFE: Wallch 4.0" [Wishlist,Confirmed] [19:11] 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] rcj: That will fall out from my libcap upload. [19:12] (As in, the change you want is uploaded but FTBFS) [19:13] infinity; thanks. just trying to determine the fastest route to get back up and running with qemu-img. [19:18] hallyn: Uploaded, I'll retry qemu when it's published. [19:18] mh ok glibc 2.19 produces worse results [19:18] jtaylor: :( [19:18] jtaylor: In which function(s)? [19:19] still checking where exactly, but mpmath is correct and the error is significant [19:20] jtaylor: Could it, perhaps, be a need for -ffp-contract=off somewhere? [19:20] I don't have fma [19:20] also thats off by default in gcc4.9 [19:20] oh we are still 4.8 [19:20] 4.8 defaults to fast. [19:20] 4.9 not, at least in c99 mode [19:21] but its not out yet, got confused as I'm running with that since a while :/ [19:21] 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] oh no it goes into fortran code :( === Guest87202 is now known as cr3 === cr3 is now known as Guest81637 [19:37] rcj: I'm afraid I don't have any, sorry. But should be building in archive soon iiuc [19:40] infinity: but to prevent more failures later, should the libc6 version put the enum inside a #ifndef XATTR_CREATE? [19:41] hallyn: Possibly, yes. I did this for another set of defines earlier for similar fallout. [19:42] 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] upstream glibc? [19:45] hallyn: Yeah. [19:46] 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] infinity, enum guarded [19:46] ? [19:49] apw: Remember the P_ALL, etc issue we discussed a while back? [19:50] yeah i remember that issue, painfully [19:51] 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] 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] its all a twisty maze with glass on the floor [19:56] arges: were you going to verify bug 1277157 ? [19:56] bug 1277157 in netcf (Ubuntu Quantal) "libvirtd restart due to assertion failure in libnl" [High,Fix committed] https://launchpad.net/bugs/1277157 [19:56] 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] hallyn: hi [19:58] infinity: qemu given back [20:00] hallyn: so the libvirt in the bug comes from the cloud-archive [20:00] slangasek: Ta. [20:01] hallyn: i'm having the reporter verify this on his machine, is this blocking something for you? [20:01] 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] thx [20:01] no, i just don't like to let things slip through the cracks [20:01] and then months down the road we have an unverified sru [20:01] thanks - i'll wait for results from teh reporter! that's perfect [20:01] hallyn: i don't like unverified srus either : ) [20:02] 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] hallyn: any reason not to push the qemu arm64 patches to Debian? [20:02] slangasek: now that they're upstream, probably not. [20:02] slangasek: mjt may want to just wait for 1.8 [20:03] 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] let's ask [20:04] I was just planning to push back the debian/control changes, and found a much bigger delta than I expected [20:05] stgraber: ok lemme address the missing --dir [20:06] slangasek: yeah the number of patches is impressive [20:06] hallyn: have you by chance been rebasing these branches, rather than merging them? because 6c93231780ecc89ac9e64686dd3247437d4b0696 doesn't look like a merge :) [20:07] (guess I won't be cherry-picking ;p) [20:07] slangasek: they have to be rebased bc we also have the omap3 patchset [20:07] maaaan [20:07] oh that [20:08] slangasek: yes i *intended* with the latest merge to make it a complete sync. However mjt calmed down from that... [20:08] wisely [20:08] ah, well [20:08] i worked toward it partially which is how i bricked some machines [20:08] it's still not a merge topologically :) [20:09] with the *next* merge i may make it completely syncable [20:09] what do you mean? [20:09] 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] 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] not sure, i don't recall making a change there [20:12] seems to have happened with the binary package reorg, post-quantal [20:12] is OVMF useful on any other arches? [20:12] hallyn: *this* build of OVMF certainly isn't :) [20:12] 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] so I think I'll just arrange to move that into qemu-system-x86 [20:13] sounds good [20:20] slangasek: so how would the OVMF.fd filenames look if different arches were supported? /usr/share/ovmf/ovmf-$arch.fd ? [20:20] hallyn: undecided :-) [20:20] ok [20:20] guess i need to be looking at that pkg. i've been negligent there [20:21] I suppose I would leave /usr/share/ovmf/ovmf.fd in place for backwards-compatibility, and then use ovmf-$efiarchname.fd [20:21] infinity: that doesn't look right: http://paste.ubuntu.com/6972824/ [20:21] yeah [20:21] though maybe its the debugger [20:23] 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] jtaylor: I know the testsuite passes within whatever acceptable ULPs upstream has defined, but that's about as far as my libm usage goes. === Guest81637 is now known as cr3 === cr3 is now known as Guest25994 [20:41] k filed a bug [20:41] http://sourceware.org/bugzilla/show_bug.cgi?id=16623 [20:41] sourceware.org bug 16623 in libc "cos change of behavior in 2.19 causes scipy testfailures" [Normal,New] [20:48] fwiw I think its a bug, that number should just still be in the range where glibc can give a right result [20:48] at least +- 0.1 [20:53] stgraber, wow, you got a special edition of the german ix magazine (professional it magazine) about LXC ! congrats !! [20:54] (and you are mentioned in the announcement, i bet they just translated your blog ;) ) [20:54] ogra_: hehe, yeah, I saw a lot of hits coming from heise.de and referring to that magazine [20:54] yeah === Sweetsha1k is now known as Sweetshark [21:31] slangasek: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest%20ppc64el/ :) === Guest25994 is now known as cr3 === cr3 is now known as Guest76515 [21:33] pitti: whoo! thanks :) [21:33] pitti: the ppc64 junk jobs still need removing, I guess? [21:34] slangasek: correct, that RT is still pending [21:34] ok [21:34] slangasek: wolfe-05 ran out of disk space, I'll clean up (bah jenkins leaking all its files) and retry jobs [21:35] *phew*, we've worked on hardly anything else than ppc/armhf tests this week, but finally getting there :) [21:37] 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] 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] pitti: how can we reproduce the adt environment? [21:38] 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] slangasek: debcheckout autopkgtest; sudo tools adt-build-lxc ubuntu trusty [21:38] slangasek: neat! :) [21:39] slangasek: that's mostly equivalent to sudo lxc-create with the ubuntu template (debootstreap) [21:39] slangasek: then for the actual test: ./run-from-checkout coreutils --- lxc -es adt-trusty [21:39] pitti: ok. what does that give us as the backing filesystem? ext4, tmpfs, or some aufs madness? :) [21:39] slangasek: I think --ephemeral defaults to tpmfs and overlayfs [21:40] pitti: and you're using --ephemeral? [21:40] slangasek: let me run the test on amd64 in LXC [21:40] slangasek: right [21:40] ok [21:40] ah, need to create a trusty container; argh slow network [21:40] pitti: do you have more than one test running /in parallel/ using overlayfs against the same base chroot? [21:41] slangasek: on the ppc nodes we have two parallel runs, on armhf just one [21:41] 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] pitti: right, please do *not* use multiple overlayfs instances against a single directory on ppc64el; we've seen instabilities with this before [21:42] (instabilities == filesystem corruption) [21:42] slangasek: ok, good to know; that'll halve our running slots, but I guess they shuld still be able to keep up [21:42] pitti: couldn't you run two chroots side-by-side? [21:43] slangasek: with some extra hackery and lock files or so, yes [21:43] 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] infinity: ^^ [21:45] slangasek: reconfiguring jenkins on our side is a bit tricky, as d-jenkins is broken; jibel will try [21:46] pitti: Oh, if the lxc adt stuff is using overlayfs, we're going to see failures even without the parallel madness. [21:46] pitti: Could I talk you into switching to aufs? [21:47] infinity: it's just using lxc --ephemeral, so whatever it supports [21:47] ah, --union-type [21:47] pitti: btrfs-snapshots are quite good with that. [21:48] pitti: So, if you really want more parallelism, your better option is to spin up twice as many VMs and overcommit CPU. [21:48] (This is what I've done for the buildds) [21:49] 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] $ sudo lxc-start-ephemeral --union-type=aufs -o adt-trusty [21:55] lxc_container: command get_cgroup failed to receive response [21:55] hmmm; stgraber ^ ? [21:56] infinity, slangasek: I get the same errors on trusty amd64 with a single container (but with overlayfs); trying with clone now [21:58] still 2 test failures, although the output looks cleaner [21:58] FAIL: [21:58] File name too long at -e line 2. [22:02] "file name too long" - err? [22:03] 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] slangasek: we already run them during package build, the autopkgtest sohuld mostly be a smoke test [22:04] slangasek, infinity: wolfes reconfigured to only use one running slot [22:09] 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] stgraber: hm, it doesn't create a log file in the first place [22:12] stgraber: /var/log/lxc/ has gazillions of logs, just not for the --union-type=aufs one [22:12] (are these ever cleaned up?) [22:12] uh, apparenlty not, I've got logs from half a year ago [22:12] hmm, we probably should ship a logrotate config then :) [22:13] pitti: so one trick you could do is set those two options in your orig container (adt-trusty): [22:13] lxc.logfile = /dev/stderr [22:13] lxc.loglevel = debug [22:13] start-ephemeral will copy that to the aufs clone and you'll get the log output at startup on stderr [22:14] done, but no output at all (except for the cgroup response and the failure notice) [22:14] that's slightly annoying... how about if you set it to some fs path? [22:15] stgraber: if I run with --union-type=overlayfs the container starts, but still no debugging output [22:15] but I did get /var/log/lxc/adt-virt-lxc-ewfdkd.log [22:15] (zero bytes) [22:16] * pitti logs to /tmp/log [22:16] stgraber: got created, but empty [22:16] stgraber: also empty with (working) overlayfs [22:17] pitti: what version of lxc is that? [22:17] 1.0.0~rc4-0ubuntu1 [22:17] stgraber: I didn't dist-upgrade today, might that help? [22:17] (last upgrade yesterday) [22:17] probably not [22:17] unless you're using btfs or xfs as your /var/lib/lxc [22:17] *btrfs [22:18] no, good ol' ext4 [22:19] 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] 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] which should be a bit more useful at telling you what's wrong [22:22] 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] pitti: hmm, maybe that container is actually getting past that point, pass -k then [22:23] still doesn't exist [22:23] perhaps it fails on creation already? [22:24] pitti: well, let's try something simpler then :) [22:24] pitti: lxc-clone -o adt-test -n test -B aufs -s [22:24] --keep-data also doesn't work [22:24] 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] stgraber: ah, now we are talking [22:24] progress! [22:25] pitti: so let's look for the obvious problems: grep aufs /proc/modules [22:25] no hit [22:25] pitti: modprobe aufs [22:25] $ modinfo aufs [22:25] modinfo: ERROR: Module aufs not found. [22:25] that'd explain it ;) [22:25] that'd do it [22:26] $ grep AUFS /boot/config-3.13.0-8-generic [22:26] CONFIG_AUFS_FS=m [22:26] LIES! [22:26] well, that or you didn't reboot the box in a while [22:27] it could be that the kernel you're running has been uninstalled [22:27] so the .ko no longer exist on disk [22:27] no, still installed [22:27]