[10:54] <sil2100> Hi everyone! Still need someone from the SRU team to take a look at a fix that we'd like to SRU for raring: https://bugs.launchpad.net/unity/+bug/1043627
[10:54] <ubot2> Launchpad bug 1043627 in nux (Ubuntu Raring) "[SRU] Add XIM Support to Nux" [Undecided,Confirmed]
[10:54] <sil2100> It seems to be somewhat important
[12:17] <xnox> Can I ask for PowerPC builds be rescored of packages listed in Levels 1-3, excluding (boost-mpi-source1.53, ogre, ogre-1.8) for the boost1.54 transition http://people.canonical.com/~ubuntu-archive/transitions/boost1.54.html ?
[12:23] <cjwatson> xnox: doing
[12:23] <xnox> thanks.
[12:24] <cjwatson> xnox: frogatto librcsb-core-wrapper mkvtoolnix pentobi rdkit btag enblend-enfuse gringo lightspark mira source-highlight vera++ laserboy -> 4000
[12:27] <xnox> cjwatson: thanks, all good.
[13:01] <psivaa> cjwatson: infinity: could i know when trusty server images will start appearing in cdimages?
[13:02] <cjwatson> was planning to poke at that tomorrow; so tomorrow or Friday
[13:02] <cjwatson> I uploaded the d-i components today that need to be touched for the new release name
[13:02] <psivaa> cjwatson: ack, thanks
[14:12] <mitya57> Hi, I continue getting pinged about bug 943195 — can somebody accept the SRU please?
[14:12] <ubot2> Launchpad bug 943195 in xpdf (Ubuntu Raring) "xpdf.real crashed with SIGSEGV in GooHash::hash()" [High,Triaged] https://launchpad.net/bugs/943195
[14:13] <mitya57> (It's a bug affecting 116 people with ugly but working fix)
[15:13] <jdstrand> cjwatson: hey-- you asked me to upload apparmor for perl 5.18, so I did, but it seems to be blocked by perl now
[15:13] <cjwatson> jdstrand: Yes, that's expected
[15:13] <cjwatson> jdstrand: Should be done with that transition in a day or two
[15:13] <jdstrand> cjwatson: ok, cool, thanks
[15:14] <cjwatson> If you desperately need to upload something you can stack it on top as long as you're sure it isn't going to fail to build somewhere, or you can wait
[15:16] <jdstrand> cjwatson: no, we aren't blocked-- I just noticed it and thought I;d ask
[15:17] <cjwatson> jdstrand: If you want to speed it along you could help figure out any of the libdr-tarantool, gdal, or libmongodb-perl build failures :)
[19:44] <roaksoax> howdy! i uploaded maas to saucy-proposed a few days ago (beforr trusty was open). can someone please accept it into -propsed for sru verification and copy it into trusty?
[19:49] <infinity> roaksoax: I'll look at it after I get the last of this perl transition licked.
[19:51] <roaksoax> infinity: perfect! thank you!
[20:37] <infinity> cjwatson: FWIW, I'm fixing the gdal FTBFS, if you were planning on that.
[20:38] <infinity> cjwatson: I think stgraber is looking at libdr-tarantool-perl, though possibly with some confusion.
[20:38] <seb128> is anyone planning to let some of the saucy SRUs in this week?
[20:38] <infinity> cjwatson: So, that leaves ibmongodb-perl
[20:38] <seb128> or should I consider direct pings to get mines in? ;-)
[20:38] <infinity> l*
[20:38] <cjwatson> infinity: Oh, good, I'd got part-way into the gdal FTBFS but was interrupted by dinner.  Be m yguest.
[20:38] <infinity> seb128: I'm going to look at the SRU queues once this perl transition looks to be under control.  Don't want to keep trusty-proposed in this state too long.
[20:38] <stgraber> infinity: I'm fighting with airlines at the moment but will get back to figuring out why the test segfaults after that
[20:46] <seb128> infinity, bdmurray: do you plan do SRUs this week or next ? ;-)
[20:47] <infinity> seb128: Red 8 minutes back in backscroll.
[20:47] <seb128> infinity: sorry, missed that ... thanks ;-)
[20:48]  * seb128 blames that web client (behind a connection blocking IRC ports atm)
[20:49] <infinity> seb128: Ew.
[20:51] <slangasek> infinity: how much longer do you think it's going to take to get perl through?  The maas SRU is AIUI a time-sensitive one, so maybe I should look at it
[20:53] <infinity> slangasek: Oh, if it's time-sensitive (the maas one?), I can look.  I already had a bit of context.
[20:53] <stgraber> slangasek: down to 3 packages
[20:54] <infinity> My gdal FTBFS fix worked, and then failed on the next g++ call, so I clearly have a bit of work to do there. :P
[20:54] <brainwash> bdmurray: hey, any news on bug 1232363 ?
[20:54] <ubot2> Launchpad bug 1232363 in update-manager (Ubuntu) "Update Manager Restart button fails on xubuntu" [Medium,Triaged] https://launchpad.net/bugs/1232363
[20:54] <slangasek> infinity: oh, actually, maas was not mentioned as one of the packages affected by what I'm thinking of
[20:54] <slangasek> infinity: so don't let it disrupt your flow
[20:55] <slangasek> I was thinking of walinuxagent+cloud-init, which I think was just precise and already done
[20:55] <infinity> Ahh.
[20:56] <stgraber> yeah, I dealt with the cloud-init + walinuxagent uploads (so far precise + raring I believe)
[20:57] <slangasek> smoser: is there still a quantal SRU coming of cloud-init + walinuxagent?
[21:00] <bdmurray> brainwash: I'm working on it
[21:01] <brainwash> bdmurray: thanks, still curious if my patch works, well it's no magic anyway, copy and paste mostly :)
[21:06] <cjwatson> Wonder if I can figure out libmongodb-perl
[21:06] <cjwatson> Not my field, to put it mildly, but
[21:15] <cjwatson> Ha.  https://github.com/mongodb/mongo-perl-driver/commit/dc4db9bf3807627828859bb630ff4e852d8d261b
[21:17] <slangasek> destroy all software... or at least its tests
[21:17] <cjwatson> IOW "the javascript engine reports errors in too many random ways so let's give up for the moment"
[21:17] <cjwatson> works for me for now ...
[21:18] <infinity> cjwatson: Oh dear.
[21:19] <infinity> TMTOWTDI, I guess.
[21:19] <infinity> Though, that seems the wrong way. :P
[21:20] <cjwatson> It does, but I'll go with upstream terribleness over home-grown terribleness for software I don't know
[21:20]  * infinity nods.
[21:20] <infinity> gdal seems licked, just waiting for it's enormously slow test build to finish.
[21:21] <infinity> its...
[21:21] <infinity> Damn you, internet.
[21:27] <infinity> Phew.  gdal fixed.
[21:27] <infinity> So, that just leaves us whatever-tarantool-thingee.
[21:27] <infinity> And any arch lag...
[21:28] <infinity> I think I caught all the lagging PPC perl builds, but I'll do another sweep.
[21:28] <cjwatson> Also poking proposed-migration/autopkgtest until it stops being confused about a few things
[21:29] <cjwatson> infinity: Anything that was lagging and that mattered would show up in the transition tracker, I expect
[21:29] <infinity> cjwatson: There were plenty of PPC builds showing as blanks in the tracker, I think I got them all.
[21:29] <cjwatson> Blanks don't matter for migration
[21:29] <infinity> They should, since you can't migrate with half-built sources.
[21:30] <cjwatson> If it's a blank then it probably wasn't built before ...
[21:30] <cjwatson> If it was built before I'd expect an x, since it would've been against perlapi-5.14.blah
[21:30] <infinity> Oh, I guess outdate doesn't matter for new sources?
[21:31]  * infinity shrugs.
[21:31] <cjwatson> It's not outdate if it hasn't been built :)
[21:31] <infinity> Anyhow, I picked them all off anyway.
[21:31] <infinity> I think.
[21:31] <cjwatson> I have about three different views of this.  Going round and checking them all.
[21:32] <infinity> I'll stop fixing arm64 perl FTBFSes for a few cycles, so we can let the dust settle without me revving source versions again.
[21:32] <infinity> ... and score that gdal through the roof so it happens this century.
[21:33] <cjwatson> I already scored it high enough
[21:33] <infinity> Oh, it's already building.  Yay.
[21:33] <infinity> Heh.
[21:33]  * cjwatson reruns the sbuild autopkgtest now that schroot is in sync
[21:34] <infinity> It disturbs me that I knew more about GCC floating point options in April than I do in November.
[21:34] <cjwatson> samba4 similarly
[21:35] <infinity> My fixes to teem seem entirely like voodoo to me now.
[21:35] <infinity> s/November/October/
[21:36] <stgraber> cjwatson: ah, I just finished running the samba4 one locally and pushed an hint to ignore the failure, but a re-run works too :)
[21:36] <cjwatson> I prefer making them pass than overriding them
[21:36] <infinity> stgraber: Any hope on the tarantool segv thing?
[21:37] <stgraber> cjwatson: how can I trigger a re-run?
[21:37] <cjwatson> stgraber: you need an account on the private jenkins, then there's a "build now" operation at the top level of a test
[21:37] <stgraber> infinity: poking at this slowly (while on hold, still fighting with airlines...)
[21:42] <cjwatson> There we go, samba4 and sbuild autopkgtests back to green.  I wonder if p-m will notice
[21:46] <stgraber> cjwatson: who do I poke to get one of those accounts?
[21:46] <cjwatson> stgraber: I think I poked jibel
[21:46] <stgraber> ok
[21:50] <smoser> slangasek, quantal is difficult...
[21:50]  * cjwatson sighs and goes to kick auto-package-testing inna head
[21:50] <smoser> and not terribly high priority to anyone
[21:50] <smoser> other than to the upgrade path from p -> q
[21:50] <stgraber> infinity: I'm done being a travel agency and back to poking at that tarantool thing
[21:50] <cjwatson> hm, it's running, maybe I'll leave it
[21:52] <cjwatson> ah, looks like it picked up the rerun, good
[21:53] <cjwatson> grr, and of course the perl transition gets britney into one of its unhappy "I'm going to take ages because when I try individual packages the world becomes uninstallable" moods
[21:53] <cjwatson> (which was why I blocked it when it was hopelessly incomplete)
[21:54] <cjwatson> "AIEEE: counter overflow"  yes yes I know
[21:55] <infinity> Heh.
[21:55] <slangasek> smoser: ok; no skin off my nose if q isn't a priority for you
[21:55] <smoser> slangasek, ok. thank you. the backport is harder there.
[21:55]  * slangasek puts some paper towels down on the counter
[21:57] <roaksoax> q/win 13
[22:13] <stgraber> cjwatson: infinity suggested you may be faster at solving the libdr-tarantool-perl failure than us ;)
[22:13] <stgraber> cjwatson: http://paste.ubuntu.com/6291627/ is the stacktrace
[22:14] <stgraber> cjwatson: the function that's failing didn't change between saucy and trusty but the rest of the code changed quite a bit
[22:14] <infinity> I'm fine with demoting or reverting that, if it ends up being our only blocker, but fixed would be nicer if the bug jumps out at anyone.
[22:15] <stgraber> cjwatson: and the fun being that this only fails on i386, amd64 works fine
[22:15] <cjwatson> I used to be an XS expert but it's been a while
[22:15] <stgraber> infinity: I'm testing a rebuild of saucy's version on trusty now to confirm that's an option
[22:15] <cjwatson> Let me grab some coffee and take a look
[22:16] <stgraber> infinity: not an option, segfaults too
[22:16] <infinity> Oh, lawlz.
[22:16] <infinity> So maybe it's in something it links to?
[22:17] <cjwatson> Looks to me like a changed packet format or something
[22:17] <cjwatson> But I'll see if I can just debug it directly ...
[22:17] <infinity> Though, no.  Not link, per se.
[22:18] <stgraber> (saucy-i386-sbuild)root@castiana:~/libdr-tarantool-perl-0.42# ldd ./blib/arch/auto/DR/Tarantool/Tarantool.so
[22:18] <stgraber> 	linux-gate.so.1 =>  (0xf7788000)
[22:18] <stgraber> 	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf75c3000)
[22:18] <stgraber> 	/lib/ld-linux.so.2 (0xf7789000)
[22:19] <infinity> stgraber: Yeah, more likely sometihng it's calling out to (ie: tarantool)
[22:20] <infinity> Not that tarantool is segfaulting but, as Colin says, maybe some format has changed.
[22:20]  * cjwatson also eyes an earlier fix https://github.com/dr-co/dr-tarantool/commit/dc33e60713dfd996dcef936b26e6ce5acc67c855 to nearby code
[22:20] <stgraber> FWIW I confirmed the crash on saucy happens on the exact same line of the tp_next function
[22:21] <cjwatson> Also FWIW the counts seem random
[22:21] <stgraber> build works when downgrading tarantool to saucy's version
[22:22] <cjwatson> https://launchpadlibrarian.net/154728856/buildlog_ubuntu-trusty-i386.libdr-tarantool-perl_0.42-1_FAILEDTOBUILD.txt.gz got through two rounds of the loop before failing; my local build got through 14
[22:23] <cjwatson> 1, 13, 16 ... definitely racy
[22:23] <stgraber> hmm, looks like I was lucky, even with saucy's version I can get it to segfault
[22:23] <cjwatson> So something like an adapted version of that earlier commit seems like a decent potential candidate
[22:24] <infinity> Oh, if this is racy, I can give it back 37 times. :P
[22:24] <cjwatson> And indeed it does sometimes succeed
[22:24] <cjwatson> Nah, would rather attempt a fix
[22:25] <infinity> Yeah, that was sarcasm.
[22:25]  * infinity goes back to seeing if birch is salvageable.
[22:26] <cjwatson> my $body = join '', map { chr int rand 256 } 1 .. (300 + int rand 300);
[22:26] <cjwatson> wonder if it depends on the length of that
[22:29] <cjwatson> ... not obviously
[22:35] <infinity> cjwatson: When we thing the perl transition is ready, we might want to pause the publisher, so that massive block of copies and deletes from britney happens atomically.
[22:35] <infinity> s/thing/think/
[22:35] <cjwatson> I was thinking that too
[22:36] <cjwatson> There's still a fair amount of stuff in output
[22:36] <cjwatson> It might be over-autohinting, or more likely it's stuff that doesn't show up in the tracker :-/
[22:37] <cjwatson> Or could be under-autohinting.  gammaray's installable in trusty-proposed-amd64.
[22:38] <cjwatson> Ah, graphviz mini-transition too
[22:40]  * cjwatson crafts another tracker
[22:47] <cjwatson> Also libbuffy-bindings FTBFS; not sure why that didn't show up on the tracker, since it was there at one point
[22:53] <cjwatson> Sigh, this is going to be painful - we should've done the new graphviz after the perl transition was done
[22:53] <cjwatson> I didn't realise it was going to involve sourceful changes to dependent packages of its own
[22:54] <cjwatson> Though at least not all of them ...
[22:56] <cjwatson> This mess absolutely vindicates the decision to defer the new graphviz from saucy to trusty, though
[23:00] <stgraber> 2/9 worked with a rebuild, we've seen better, thankfully there aren't that many of those
[23:01] <infinity> poppler can be much worse, when it happens.
[23:01] <infinity> Thankfully, though they break ABI every eight days, they seem to only violently break API once a year or so. :P
[23:13] <doko> cjwatson, sorry, forgot about the graphviz one
[23:15] <cjwatson> Hmm.  Maybe this is just me not understanding something, but the reply from tarantool in the segfaulting case looks like total nonsense
[23:15] <cjwatson> Sensible-ish header but then the tuple lengths are off in la-la land
[23:19] <stgraber> cjwatson: there'll apparently be a new Debian upload of tarantool real soon (changelog entry was pushed to git 14 hours ago), I wonder if this may help
[23:20] <cjwatson> Oh, actually it's not tarantool at all
[23:20] <cjwatson> The packet I'm looking at is entirely generated by the test code
[23:21] <cjwatson> So it is utterly dumb luck whether it happens to cause it to overflow into space
[23:24] <cjwatson> Not too sure why it ever worked, though it clearly does sometimes and I can't be bothered to sort out why.
[23:26] <stgraber> so are you close to figuring it out how to fix the test or should we just turn that one off (or click rebuild a couple of times and see it magically pass)?
[23:26] <cjwatson> I'm close
[23:27] <cjwatson> But there's no rush now since we have at least graphviz to do before perl can land
[23:29] <infinity> The number of times I've run into people actually attempting to update config.{sub,guess} but landing it in the wrong directory is quite funny.
[23:40] <wgrant> Also lots of people use autoreconf to do it
[23:40] <wgrant> But then their setup is sufficiently strange, or they just don't use automake, so it doesn't actually work.
[23:41] <infinity> I'm pretty much madly in love with dh_autotools_dev's spray of bullets approach to the problem.
[23:42] <infinity> Seems to DTRT every time, so far.
[23:42] <wgrant> Yep
[23:48] <infinity> Finished 1 minute ago (took 13 minutes, 47.2 seconds)
[23:48] <infinity> Finished 1 minute ago (took 13 minutes, 46.6 seconds)
[23:48] <infinity> birch and sulfur fight to the death at the finish line...
[23:51] <infinity> I obviously need some breakfast if I'm sitting here comparing build times.
[23:59] <xnox> Can I ask for PowerPC builds be rescored to 4000 of packages listed in Levels 6 which did succeed on "adm64 i386 armhf" at http://people.canonical.com/~ubuntu-archive/transitions/boost1.54.html ?