=== hobgoblin is now known as elfy === zequence_ is now known as zequence === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === pete-woods is now known as pete-woods-away [11:17] ScottK: can you acceot cvsservice in binary new [11:17] *accept === zumbi_ is now known as zumbi [13:58] anyone got an idea why utopic dailies stopped building a few days ago? (with the exception of ubuntu core and touch) [13:59] elfy: I literally just fixed that [13:59] broken by syslinux 6 [13:59] thanks cjwatson [13:59] which image do you particularly care about and I'll rebuild it? [13:59] I knew I should have drunk the tea before posting :) [13:59] xubuntu would be awesome :) [14:00] I can't vouch for whether the images actually *work* with syslinux 6, but I guess we'll find out [14:00] elfy: queued [14:00] yep :) [14:01] ok - thanks cjwatson [14:02] cjwatson: I hear code imports from packages are broken [14:02] https://code.launchpad.net/~ubuntu-branches/ubuntu/utopic/firefox/utopic [14:02] shadeslayer: lots of individual imports are frequently broken [14:02] ah I see [14:02] shadeslayer: http://package-import.ubuntu.com/status/ has status and reasons [14:03] thx === oSoMoN_ is now known as oSoMoN === pete-woods-away is now known as pete-woods [15:40] cjwatson: in a few words - not very well, can boot the image - but trying to install with the desktop launcher does nothing [15:51] elfy, it boots for you? the ubuntu iso doesn't give me a language selection menu in virtualbox [15:51] (same in kvm btw) [15:52] seb128: yea - no screen for language, no choose between try or install - but it does boot for me [15:52] hum, k [15:52] bug 1325632 [15:53] https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1325632 [15:53] elfy, thanks [15:54] that's in a vbox by the way [15:55] kvm does the same [16:23] Hello. Is this the correct place to ask about the possibility of backporting the Python 2.7.7 SSL support to 2.7.3 in Precise? [16:39] luket_: The correct place would be filing a bug on python2.7, but given that precise users and upgrade to trusty, I'm not sure asking for feature backports to precise makes much sense. [16:39] s/and upgrade/can upgrade/ [16:41] Thank you. We're stuck on 12.04 and OpenStack Essex. We need the SSL support added to 2.7.7 to properly secure Glance. [16:43] infinity: hm, 2.7.7 is only in utopic-proposed. [16:43] xnox: Yes, I know. [16:44] And, in theory, if the backport is similar for both versions, auditable, and meets SRU criteria (some of these things seem less likely than others), we could perhaps do both. [16:44] luket_: Please file a bug on python2.7, however. [16:45] luket_: Use https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template for the description (ie: we need to know exactly why this is needed, impact, etc) [16:45] Thank you. I'll do that. [16:45] Would need to update trusty too. [16:46] ScottK: Obviously, yes. [16:46] luket_: Especially, if you can expand on what "to properly secure Glance" really means, I could see making an exception for the SRU on that basis, if the argument is sound. [16:47] Obviously to you. A surprising number of people need that sort of the pointed out. [16:48] ScottK: Well, hopefully obvious to any SRU team member who would be reviewing the proposal. :/ [16:48] Hopefully... [16:49] Of course, it was for luket_'s benefit. [16:51] Python 3.4 properly verifies an SSL certificate. Python 2.7 didn't until the Python dev team backported the support to 2.7.7. [16:52] I'll use the template and go from there. Thanks for pointing me in the right direction. === chorrell is now known as chorrell-away [16:55] luket_: Ahh, yes. I think some other software (like ubuntu-one) actually does their own cert chain verification specifically because python doesn't seem to do it itself. [16:55] luket_: So, that's another option -- make glance, in the face of python << 2.7.7, sort it itself. [16:56] Probably the smarter option for glance upstream, since they can't exactly demand all their users use bleeding edge python. === chorrell-away is now known as chorrell [16:57] Yes. I'll check with the Glance team to see if there's any other way to do this before filing the bug report. [18:23] cjwatson: And, of course, it doesn't fail under GDB. Whee. [18:35] * ogra_ wonders what happened to his touch image build ... [18:35] i see a process on nusakan [18:35] but no related build running on kishi00.buildd [18:36] infinity, do you have an idea whats going on there ? [18:37] looks like hung ssh stuff ... [18:37] ogra@nusakan:~$ ps ax|grep kishi [18:37] 10891 ? S 0:00 ssh -n -o StrictHostKeyChecking=no -o BatchMode=yes buildd@kishi00.buildd /home/buildd/bin/BuildLiveCD -l -f plain -A armhf -d utopic ubuntu-touch [18:37] 22116 ? S 0:00 ssh -n -o StrictHostKeyChecking=no -o BatchMode=yes buildd@kishi00.buildd /home/buildd/bin/BuildLiveCD -l -f plain -A armhf -d precise ubuntu-core [18:38] how are you checking for the build on kishi? [18:38] slangasek, w3m kishi00.buildd/~buildd/LiveCD/utopic/ubuntu-touch/ [18:38] from nusakan [18:38] there should be a 0602.1 build [18:38] ok [18:38] but even the top level BuiltLiveCD.log is empty [18:39] err [18:39] BuildLive.out [18:39] alst write to that seems to have been at 4:30 UTC [18:39] *last [18:40] ogra_: How old is that build? kishi00 was down last night. [18:40] Ahh, old. [18:41] Might need a stale lock removed or something. [18:41] infinity, i triggered the new buuld 2.5h ago [18:41] ogra_: Sure, but the old one could be locking it. Lemme poke a WeBop. [18:41] yeah, thanks [18:51] ogra_: You should be able to try again now. [18:51] whee [18:52] lets see if my imgbot can cope with that :P [19:00] bah, cjwatson's attempt to fix samba seems to have failed bcause it cant build a manpage ... only on i386 and armhf [19:00] thats weird [19:00] all other arches passed [19:07] ogra_: Yeah, known. Looking into it, but it's making my head hurt. Might try eating breakfast first. [19:07] stgraber, hmm, so i triggered a new touch build with the iso tracker a while ago ... seems it hasnt been picked up [19:08] infinity, well, i think zul just said in another channel he would be doing the merge ... probably coordinate with him [19:08] ogra_: yeah im going to re-try the build first [19:09] ogra_: there was a stall process on nusakan, killed it now, let's see if that helps... [19:12] ogra_: cleared the DB state and requested a rebuild of touch, let's see if it gets picked up now [19:16] stgraber, great, thanks [19:16] cdimage 3394 0.0 0.0 4404 612 ? Ss 19:15 0:00 | \_ /bin/sh -c rebuild-requests -b -q utopic iso [19:16] cdimage 3398 0.1 0.0 54392 11696 ? S 19:15 0:00 | \_ /usr/bin/python /srv/cdimage.ubuntu.com/bin/rebuild-requests -b -q utopic iso [19:16] cdimage 3419 96.4 0.1 62076 15172 ? R 19:15 1:08 | \_ /usr/bin/python /srv/cdimage.ubuntu.com/bin/cron.daily-preinstalled --live [19:16] cdimage 3440 0.0 0.0 47252 3712 ? S 19:15 0:00 | \_ ssh -n -o StrictHostKeyChecking=no -o BatchMode=yes buildd@kishi00.buildd /home/buildd/bin/BuildLiveCD -l -f plain -A armhf -d utopic ubuntu-touch [19:16] so looks like the rebuild request got picked up now and things are building [19:16] yeah [19:17] i see it on kishi00 [19:17] thanks a lot [19:17] np [19:17] zul: Retrying the build won't help. I don't imagine merging will either, unless that xml file changed. [19:18] infinity, funny that it is only on these two arches [19:18] the rest built fine [19:23] infinity: googling looks like it might be fixed in 4.1.7 [19:26] zul: that seems surprising given that the crash is in xsltproc not samba? [19:26] unless there's some bad XML that tickles a bug in xsltproc or something [19:26] cjwatson: my mistake [19:26] i spoke too soon [19:26] not saying it's impossible, just surprising :) === chorrell is now known as chorrell-away [19:40] well 4.1.7 built fine for me (amd64) but i dont have arm or i386 [19:41] if you have amd64 then you have i386 [19:41] just use a chroot [19:41] I reproduced the same failure locally [19:42] I uploaded because it was still better than before, I was running out of day, and there was some chance that it might have been some bizarre local failure === chorrell-away is now known as chorrell [20:02] ive reached a hard EOD for me...4.1.7 builds fine for me on amd64 (untested on i386 and arm) i need to go take my kid to swimming lessons [20:15] stgraber, Would you have time to look at the SRU in bug #1275656? This is open-vm-tools trusty backport to precise for HWE kernels. It's becoming critical now. [20:16] rcj: oh right, sorry, had a bit of a busy week last week. I'll take a look this afternoon, hopefully it's all good and I'll let it into -proposed. [20:17] stgraber, thanks. [20:17] stgraber, the precise upload went into universe but this package from trusty had a MIR and is in main for trusty. [20:18] will it land in main for precise? [20:18] rcj: yeah, don't worry about it, if it's good, I'll override it to main [20:18] stgraber, thanks for taking the time to review this [20:38] infinity: I can reproduce it within waf but not if I pick out the exact same command from strace output and run it manually [20:38] including what look like the relevant environment variables [20:43] no-change rebuilding libxslt doesn't help [20:44] faketime isn't relevant [20:45] I can confirm it works under gdb for me [20:46] cjwatson: I can reproduce without waf just fine. Just need to export the right environment. [20:46] OK, I expect I missed something [20:46] trying with valgrind, it's certainly taking a while [20:46] cjwatson: gdb on the dumped core is pretty monumentally unhelpful. Might be more interesting with a -O0 libxml2 [20:47] (Though -O0 may also make the behaviour go away...) [20:47] * cjwatson listens to his laptop take off which in fairness doesn't take a lot of provocation [20:47] valgrind also makes it go away [20:47] FFS [20:47] hovertop :) [20:50] Wait... [20:50] -O0 doesn't make it go away [20:50] cjwatson: In both the gdb and valgrind case (and your "I can't make it fail without waf" case), could the common thread be lack of environment? [20:50] I inserted gdb by editing debian/bin/xsltproc [20:50] So I don't think so [20:51] Oh, nevermind. I can reproduce with a clean env too. [20:51] (utopic-i386)adconrad@cthulhu:~/review/samba-4.1.6+dfsg/bin$ xsltproc --nonet -o default/docs-xml/manpages/smb.conf.5 /home/adconrad/review/samba-4.1.6+dfsg/docs-xml/xslt/man.xsl default/docs-xml/manpages/smb.conf.5.xml [20:51] Bus error (core dumped) [20:51] So, no debian/bin foo, and no export before. [20:52] Irksome. [20:52] Haven't managed to get it to dump core despite prodding ulimit [20:52] cjwatson: Want my core? It's not particularly enlightening to me, but maybe you'd do better with it. [20:53] Oh, except mine is against a local rebuild. I should downgrade and get a matching one. [20:53] Since it's still reproducible with -O0, I'd suggest doing that first [20:53] cjwatson: -O0 of libxslt or libxml2? [20:53] Then hopefully the traceback will make sense [20:53] libxslt [20:53] I didn't try libxml2 [20:54] cjwatson: I'm not convinced that it's not libxml2's fault. [20:54] We have an Ubuntu delta to that ... [20:55] I wonder what happens if you back out the recent security update? [20:55] cjwatson: Here's the 'bt full' from the core: http://lucifer.0c3.net/~adconrad/bt-full.txt [20:57] * cjwatson grabs the previous version [20:57] cjwatson: Same bus error with -3ubuntu4 [20:58] Yeah, likewise [20:58] Build log diff between previous successful samba build and this one to see what else has changed? [21:00] out of time [21:00] I'll keep digging in a bit. [21:02] Most everything (except xml2) looks untouched... [21:03] Well, and libgcc... [21:03] I'll have to give this a spin in a trusty chroot and then do selective partial upgrades, I think. [21:03] I had one last test already running: libxml2 -O0 still fails [21:06] disas /rm in gdb says [21:06] => 0xf75bb588 <+12>: e8 23 71 f7 ff call 0xf75326b0 <__x86.get_pc_thunk.bx> [21:07] some kind of multiple declarations problem? [21:07] or wrong linker or something [21:08] anyway, really gone [21:15] rcj: ^ [21:16] stgraber, Thank you so much [21:17] rcj: please do another full test once both packages are built and published in -proposed then confirm that everything looks good in the bug report [21:17] stgraber, I will. [22:10] infinity: works after "ulimit -s unlimited" [22:10] infinity: if that's any help? [22:17] I might just upload with that to unblock us [22:20] uploaded [22:20] hopefully that'll stick this time [22:21] makes sense given the length of infinity's bt-full though [22:21] "sense". [22:22] I can certainly well believe that XML/XSLT processing might hit stack size limits [22:22] Indeed. [22:22] Gross, though. [22:22] Yeah [22:24] So, possibly just a fluke of a few kB one way or the other than ppc didn't explode? [22:24] s/than/that/ [22:24] Could be [22:24] Or different stack layout [22:25] Oh, fair. PPC is a whole lot of different in that area. [23:10] zul: all sorted now [23:19] rcj: hmm, so there's a problem with having open-vm-tools-lts-trusty in main for precise, it build-depends on libdumbnet-dev which isn't in main [23:19] * stgraber should have spotted it in the review... [23:21] rcj: so there are two options, 1) keep it in universe, 2) check for any other build-dep that's in universe, convince the security team to support them all, then promote them to main