[11:17] <shadeslayer> ScottK: can you acceot cvsservice in binary new
[11:17] <shadeslayer> *accept
[13:58] <elfy> anyone got an idea why utopic dailies stopped building a few days ago? (with the exception of ubuntu core and touch)
[13:59] <cjwatson> elfy: I literally just fixed that
[13:59] <cjwatson> broken by syslinux 6
[13:59] <elfy> thanks cjwatson
[13:59] <cjwatson> which image do you particularly care about and I'll rebuild it?
[13:59] <elfy> I knew I should have drunk the tea before posting :)
[13:59] <elfy> xubuntu would be awesome :)
[14:00] <cjwatson> I can't vouch for whether the images actually *work* with syslinux 6, but I guess we'll find out
[14:00] <cjwatson> elfy: queued
[14:00] <elfy> yep :)
[14:01] <elfy> ok - thanks cjwatson
[14:02] <shadeslayer> cjwatson: I hear code imports from packages are broken
[14:02] <shadeslayer> https://code.launchpad.net/~ubuntu-branches/ubuntu/utopic/firefox/utopic
[14:02] <cjwatson> shadeslayer: lots of individual imports are frequently broken
[14:02] <shadeslayer> ah I see
[14:02] <cjwatson> shadeslayer: http://package-import.ubuntu.com/status/ has status and reasons
[14:03] <shadeslayer> thx
[15:40] <elfy> cjwatson: in a few words - not very well, can boot the image - but trying to install with the desktop launcher does nothing
[15:51] <seb128> elfy, it boots for you? the ubuntu iso doesn't give me a language selection menu in virtualbox
[15:51] <seb128> (same in kvm btw)
[15:52] <elfy> seb128: yea - no screen for language, no choose between try or install - but it does boot for me
[15:52] <seb128> hum, k
[15:52] <elfy> bug 1325632
[15:53] <elfy> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1325632
[15:53] <seb128> elfy, thanks
[15:54] <elfy> that's in a vbox by the way
[15:55] <seb128> kvm does the same
[16:23] <luket_> 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] <infinity> 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] <infinity> s/and upgrade/can upgrade/
[16:41] <luket_> 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] <xnox> infinity: hm, 2.7.7 is only in utopic-proposed.
[16:43] <infinity> xnox: Yes, I know.
[16:44] <infinity> 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] <infinity> luket_: Please file a bug on python2.7, however.
[16:45] <infinity> 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] <luket_> Thank you. I'll do that.
[16:45] <ScottK> Would need to update trusty too.
[16:46] <infinity> ScottK: Obviously, yes.
[16:46] <infinity> 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] <ScottK> Obviously to you. A surprising number of people need that sort of the pointed out.
[16:48] <infinity> ScottK: Well, hopefully obvious to any SRU team member who would be reviewing the proposal. :/
[16:48] <infinity> Hopefully...
[16:49] <ScottK> Of course, it was for luket_'s benefit.
[16:51] <luket_> 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] <luket_> I'll use the template and go from there. Thanks for pointing me in the right direction.
[16:55] <infinity> 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] <infinity> luket_: So, that's another option -- make glance, in the face of python << 2.7.7, sort it itself.
[16:56] <infinity> Probably the smarter option for glance upstream, since they can't exactly demand all their users use bleeding edge python.
[16:57] <luket_> 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] <infinity> cjwatson: And, of course, it doesn't fail under GDB.  Whee.
[18:35]  * ogra_ wonders what happened to his touch image build ... 
[18:35] <ogra_> i see a process on nusakan
[18:35] <ogra_> but no related build running on kishi00.buildd
[18:36] <ogra_> infinity, do you have an idea whats going on there ?
[18:37] <ogra_> looks like hung ssh stuff ...
[18:37] <ogra_> ogra@nusakan:~$ ps ax|grep kishi
[18:37] <ogra_> 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] <ogra_> 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] <slangasek> how are you checking for the build on kishi?
[18:38] <ogra_> slangasek, w3m kishi00.buildd/~buildd/LiveCD/utopic/ubuntu-touch/
[18:38] <ogra_> from nusakan
[18:38] <ogra_> there should be a 0602.1 build
[18:38] <slangasek> ok
[18:38] <ogra_> but even the top level BuiltLiveCD.log is empty
[18:39] <ogra_> err
[18:39] <ogra_> BuildLive.out
[18:39] <ogra_> alst write to that seems to have been at 4:30 UTC
[18:39] <ogra_> *last
[18:40] <infinity> ogra_: How old is that build?  kishi00 was down last night.
[18:40] <infinity> Ahh, old.
[18:41] <infinity> Might need a stale lock removed or something.
[18:41] <ogra_> infinity, i triggered the new buuld 2.5h ago
[18:41] <infinity> ogra_: Sure, but the old one could be locking it.  Lemme poke a WeBop.
[18:41] <ogra_> yeah, thanks
[18:51] <infinity> ogra_: You should be able to try again now.
[18:51] <ogra_> whee
[18:52] <ogra_> lets see if my imgbot can cope with that :P
[19:00] <ogra_> bah, cjwatson's attempt to fix samba seems to have failed bcause it cant build a manpage ... only on i386 and armhf
[19:00] <ogra_> thats weird
[19:00] <ogra_> all other arches passed
[19:07] <infinity> ogra_: Yeah, known.  Looking into it, but it's making my head hurt.  Might try eating breakfast first.
[19:07] <ogra_> stgraber, hmm, so i triggered a new touch build with the iso tracker a while ago ... seems it hasnt been picked up
[19:08] <ogra_> infinity, well, i think zul just said in another channel he would be doing the merge ... probably coordinate with him
[19:08] <zul> ogra_:  yeah im going to re-try the build first
[19:09] <stgraber> ogra_: there was a stall process on nusakan, killed it now, let's see if that helps...
[19:12] <stgraber> ogra_: cleared the DB state and requested a rebuild of touch, let's see if it gets picked up now
[19:16] <ogra_> stgraber, great, thanks
[19:16] <stgraber> cdimage   3394  0.0  0.0   4404   612 ?        Ss   19:15   0:00  |   \_ /bin/sh -c rebuild-requests -b -q utopic iso
[19:16] <stgraber> 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] <stgraber> 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] <stgraber> 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] <stgraber> so looks like the rebuild request got picked up now and things are building
[19:16] <ogra_> yeah
[19:17] <ogra_> i see it on kishi00
[19:17] <ogra_> thanks a lot
[19:17] <stgraber> np
[19:17] <infinity> zul: Retrying the build won't help.  I don't imagine merging will either, unless that xml file changed.
[19:18] <ogra_> infinity, funny that it is only on these two arches
[19:18] <ogra_> the rest built fine
[19:23] <zul> infinity:  googling looks like it might be fixed in 4.1.7
[19:26] <cjwatson> zul: that seems surprising given that the crash is in xsltproc not samba?
[19:26] <cjwatson> unless there's some bad XML that tickles a bug in xsltproc or something
[19:26] <zul> cjwatson:  my mistake
[19:26] <zul> i spoke too soon
[19:26] <cjwatson> not saying it's impossible, just surprising :)
[19:40] <zul> well 4.1.7 built fine for me (amd64) but i dont have arm or i386
[19:41] <cjwatson> if you have amd64 then you have i386
[19:41] <cjwatson> just use a chroot
[19:41] <cjwatson> I reproduced the same failure locally
[19:42] <cjwatson> 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
[20:02] <zul> 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] <rcj> 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] <stgraber> 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] <rcj> stgraber, thanks.
[20:17] <rcj> stgraber, the precise upload went into universe but this package from trusty had a MIR and is in main for trusty.
[20:18] <rcj> will it land in main for precise?
[20:18] <stgraber> rcj: yeah, don't worry about it, if it's good, I'll override it to main
[20:18] <rcj> stgraber, thanks for taking the time to review this
[20:38] <cjwatson> 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] <cjwatson> including what look like the relevant environment variables
[20:43] <cjwatson> no-change rebuilding libxslt doesn't help
[20:44] <cjwatson> faketime isn't relevant
[20:45] <cjwatson> I can confirm it works under gdb for me
[20:46] <infinity> cjwatson: I can reproduce without waf just fine.  Just need to export the right environment.
[20:46] <cjwatson> OK, I expect I missed something
[20:46] <cjwatson> trying with valgrind, it's certainly taking a while
[20:46] <infinity> cjwatson: gdb on the dumped core is pretty monumentally unhelpful.  Might be more interesting with a -O0 libxml2
[20:47] <infinity> (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] <cjwatson> valgrind also makes it go away
[20:47] <cjwatson> FFS
[20:47] <ogra_> hovertop :)
[20:50] <infinity> Wait...
[20:50] <cjwatson> -O0 doesn't make it go away
[20:50] <infinity> 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] <cjwatson> I inserted gdb by editing debian/bin/xsltproc
[20:50] <cjwatson> So I don't think so
[20:51] <infinity> Oh, nevermind.  I can reproduce with a clean env too.
[20:51] <infinity> (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] <infinity> Bus error (core dumped)
[20:51] <infinity> So, no debian/bin foo, and no export before.
[20:52] <infinity> Irksome.
[20:52] <cjwatson> Haven't managed to get it to dump core despite prodding ulimit
[20:52] <infinity> cjwatson: Want my core?  It's not particularly enlightening to me, but maybe you'd do better with it.
[20:53] <infinity> Oh, except mine is against a local rebuild.  I should downgrade and get a matching one.
[20:53] <cjwatson> Since it's still reproducible with -O0, I'd suggest doing that first
[20:53] <infinity> cjwatson: -O0 of libxslt or libxml2?
[20:53] <cjwatson> Then hopefully the traceback will make sense
[20:53] <cjwatson> libxslt
[20:53] <cjwatson> I didn't try libxml2
[20:54] <infinity> cjwatson: I'm not convinced that it's not libxml2's fault.
[20:54] <cjwatson> We have an Ubuntu delta to that ...
[20:55] <cjwatson> I wonder what happens if you back out the recent security update?
[20:55] <infinity> 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] <infinity> cjwatson: Same bus error with -3ubuntu4
[20:58] <cjwatson> Yeah, likewise
[20:58] <infinity> Build log diff between previous successful samba build and this one to see what else has changed?
[21:00] <cjwatson> out of time
[21:00] <infinity> I'll keep digging in a bit.
[21:02] <infinity> Most everything (except xml2) looks untouched...
[21:03] <infinity> Well, and libgcc...
[21:03] <infinity> I'll have to give this a spin in a trusty chroot and then do selective partial upgrades, I think.
[21:03] <cjwatson> I had one last test already running: libxml2 -O0 still fails
[21:06] <cjwatson> disas /rm in gdb says
[21:06] <cjwatson> => 0xf75bb588 <+12>:    e8 23 71 f7 ff  call   0xf75326b0 <__x86.get_pc_thunk.bx>
[21:07] <cjwatson> some kind of multiple declarations problem?
[21:07] <cjwatson> or wrong linker or something
[21:08] <cjwatson> anyway, really gone
[21:15] <stgraber> rcj: ^
[21:16] <rcj> stgraber, Thank you so much
[21:17] <stgraber> 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] <rcj> stgraber, I will.
[22:10] <cjwatson> infinity: works after "ulimit -s unlimited"
[22:10] <cjwatson> infinity: if that's any help?
[22:17] <cjwatson> I might just upload with that to unblock us
[22:20] <cjwatson> uploaded
[22:20] <cjwatson> hopefully that'll stick this time
[22:21] <cjwatson> makes sense given the length of infinity's bt-full though
[22:21] <infinity> "sense".
[22:22] <cjwatson> I can certainly well believe that XML/XSLT processing might hit stack size limits
[22:22] <infinity> Indeed.
[22:22] <infinity> Gross, though.
[22:22] <cjwatson> Yeah
[22:24] <infinity> So, possibly just a fluke of a few kB one way or the other than ppc didn't explode?
[22:24] <infinity> s/than/that/
[22:24] <cjwatson> Could be
[22:24] <cjwatson> Or different stack layout
[22:25] <infinity> Oh, fair.  PPC is a whole lot of different in that area.
[23:10] <cjwatson> zul: all sorted now
[23:19] <stgraber> 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] <stgraber> 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