[06:43] <darkxst> can we get Ubuntu GNOME ISO size limits bumped up to 1.5GB?
=== ara_ is now known as ara
[07:23] <slangasek> infinity: well, I pulled in your changes from trusty but that's insufficient, because it goes on to install the ubuntu-live task which also includes various other conflicted libraries
[07:24]  * didrocks wonders when slangasek isn't working
[07:24] <slangasek> didrocks: weekends when we're not in the critical path of a terrible g++ transition
[07:25] <didrocks> slangasek: good luck! if you need any new hands, this week should be better for me…
[07:25] <slangasek> didrocks: the transition tracker has huge piles of libraries that we haven't started the rebuilds for yet, dig in :)
[07:25] <didrocks> slangasek: will do! :)
[14:17] <arges> infinity: would you be terribly inconvienced if I reviwed the openstack uploads in vivid today
[15:03] <infinity> arges: Why would I be inconvenienced if you did my job for me? :P
[15:03] <arges> infinity: : )
[15:09] <Laney> slangasek: Had a go at implementing de-duping for the tracker
[15:10] <slangasek> Laney: de-duping?  you mean for the new-binary-package-name case?
=== seelaman` is now known as seelaman
[15:11] <Laney> Yep
[15:12] <slangasek> Laney: ok.  tdaitx was also looking at this on Friday (and this morning), if you want to compare notes
[15:14] <tdaitx> Laney, http://paste.ubuntu.com/12047242/ and http://paste.ubuntu.com/12047866/
[15:14] <tdaitx> in short: if a source package (in Source file) appears more than once, all binaries ("Binary:" field) it declares are removed from Package_arch file except for the ones in the latest (ie. highest version) source package
[15:15] <infinity> tdaitx: You can't (reliably) map in that direction, though.  Some source packages lie aboutt he binaries they produce and we don't enforce consistency.
[15:15] <tdaitx> Laney, slangasek said "I can see that this approach will mask per-architecture build failures, for instance, which I suspect is not what the release team wants"
[15:15] <infinity> tdaitx: The only reliable mapping is the Packages file.
[15:15] <tdaitx> oh
[15:16] <infinity> tdaitx: It might be good enough for a hack today, mind you.  JUst saying that it's not accurate for all source->binary mappings, since we're trusting the source package not to lie.
[15:16] <tdaitx> indeed
[15:17] <infinity> tdaitx: The inverse (checking the Source: field on binaries in Packages) is always correct.
[15:17] <Laney> I grabbed the source packages from -proposed's Packages file and then ripped those out of release's
[15:17] <infinity> tdaitx: With the hilarious caveat that binaries whose name matches their source don't have a Source field, so you have to check for Source not being set and assume Source==Package
[15:18] <infinity> tdaitx: All that said, Laney's solution is probably simpler. :P
[15:18] <infinity> tdaitx: But, y'know, consider the above a lesson in apt source parsing in general.
[15:18] <tdaitx> Laney, I tried that, but ben does look at the binaries in Packages_arch
[15:19] <tdaitx> I mean, it does what infinity suggested: grab the Source from the binary
[15:19] <Laney> Yep
[15:19] <Laney> I only look at Packages
[15:19] <Laney> (and write to)
[15:20] <Laney> anyway, sorry for duplicating your work - I wasn't aware :(
[15:20] <tdaitx> np
[15:22] <tdaitx> Laney, in short: you grab all Source fields from -proposed Packages and proceed to remove the binaries in release Package that have the same Source?
[15:23] <Laney> Right, and fall back to Package if Source isn't there
[15:23] <Laney> Then spit proposed and release out as Packages_arch
[15:23] <Laney> Tool of choice was grep-dctrl
[15:24] <slangasek> Laney: are you doing it on a per-arch basis?
[15:25] <tdaitx> nice, Laney can you send me the script? I would like to compare what they are (not) ripping out
[15:25] <infinity> You'd have to, to get it right.
[15:25] <Laney> Yep
[15:25] <Laney> tdaitx: It's in go on snakefruit, if you have access
[15:26] <tdaitx> not sure I do
[15:26] <Laney> I would bet it has some bugs :)
[15:26] <Laney> ok
[15:26] <infinity> tdaitx: You'll probably find Laney's approach and your approach tearing out the same packages (hopefully), because there aren't many source->binary liars in the archive.  If the kernel is in proposed, though, I know it lies. :)
[15:26]  * Laney VPNs it up
[15:26] <infinity> (Which is a bug, but it's also a bug that we have no lie detection, so it's allowed to)
[15:27] <infinity> Laney: He doesn't have snakefruit, no, I've tried to impress upon IS the importance of not randomly handing out sensitive groups/hosts to people without asking, so I'd be miffed if he did. :P
[15:27] <Laney> tdaitx: http://paste.ubuntu.com/12048720/
[15:29]  * tdaitx wishes to had known about grep-dctrl
[15:29] <infinity> tdaitx: By the way, grep-dctrl.  HTH.
[15:30] <tdaitx> yeah
[15:30] <tdaitx> that =)
[15:30] <Laney> There's certainly some golfing to be done there. :P
[15:30] <Laney> zcatting the same thing twice, oh my
[15:32] <infinity> Laney: The second one will be near instant, probably, but yeah, a bit eww.
[15:32] <infinity> Laney: And, of course, at that point, output == proposed (doesn't it?), so you could do your filter on output instead.  Which will be in cache.
[15:33] <infinity> Yeah, that's the first write to output.
[15:33] <Laney> Feel free to go shrink it. ;)
[15:34] <infinity> Laney: I don't much care, it'd save half a second, at best.  Was just engaging in your optimisation thought exercise. :P
[15:34] <infinity> (Also, what have I become where I don't think saving half a second is huge?  I hate modern computing...)
[15:38] <slangasek> infinity: well when you get old and your reaction time slows to 5 seconds for anything...
[15:45] <infinity> slangasek: Touche.
=== tdaitx is now known as tdaitx|lunch
=== tdaitx|lunch is now known as tdaitx
[17:40] <tdaitx> Laney, infinity, slangasek: packages kept only by Laney's script *or* mine for amd64, ppc64le, and all archs @ http://paste.ubuntu.com/12049566/
[17:41] <tdaitx> hopefully this can tell if either script is removing something that it shouldn't
[17:44] <infinity> tdaitx: Well, you can spot-check that with "rmadison <package>" on a few and see what reality says about the situation.
[17:45] <infinity> tdaitx: If it exists in both suites and one of you is removing it, you have a bug.
[17:46] <tdaitx> infinity, thanks, that's a good tip
[17:59] <slangasek> tdaitx: or, for example, if I look at the first package in that list, ruby-gdk3-dbg: ruby-gdk3-dbg comes from ruby-gnome2 source package, ruby-gnome2 source exists in wily-proposed but is not built on any arch; so this should not be removed, laney's script is correct for this one
[18:01] <slangasek> tdaitx: and then you get down to line 13, libsigc++-2.0-0c2a built from libsigc++-2.0 source, which exists in wily-proposed, is built for all architectures, and no longer includes this binary package - so your script is the correct one ;)
[18:05] <tdaitx> slangasek, I have also confirmed that my script is removing binaries that exist in both series (wily and -proposed), but so far there is another package available from the same source, example: removing libcdr-0.1-1 (wily and -proposed) but keeping libcdr-0.1-1v5 (-proposed)
[18:08]  * doko looks for gcc-5 5.2.1 in -release ...
[18:11] <slangasek> tdaitx: in that case, there are two versions of the source package in wily-proposed, and the latest version has dropped the libcdr-0.1-1 binary (in favor of libcdr-0.1-1v5).  So it's correct to remove
[18:12] <infinity> slangasek: If there are two versions in -proposed with differing binaries, that confuses britney until someone processes the NBS manually (I'll do that).
[18:12] <infinity> WOuldn't be shocked if it confused other things too.
[18:13] <slangasek> infinity: sure, but "something gets confused" is different from "it should be on the transition tracker"
[18:13] <infinity> slangasek: Yeahp, just saying it's harder to sort out those cases correctly sometimes. :)
[18:14]  * infinity finds libcoverartcc1 in the same state and fixes.
[18:14]  * infinity hunts for more.
=== seelaman is now known as manonmani
=== manonmani is now known as seelaman
[18:22] <tdaitx> slangasek, ruby-gdk3-dbg is on wily's Sources Binary: field, but not on -proposed's Source Binary: field, is this one case where the Binary: field from -proposed is lying/wrong?
[18:23] <slangasek> tdaitx: no, my point is that the package has not been built in wily-proposed yet so it shouldn't be taken off the transition tracker because it's not "done"
[18:23] <tdaitx> oh
[18:24] <slangasek> this is different than infinity's point that the Sources may lie, but leads to the same conclusion
[18:24] <tdaitx> is that the reason it does not show in -proposed's ruby-gnome2 Binary: ? because it was not build yet?
[18:27] <infinity> This whole "sync first, then rename" caused quite a mess...
[18:27] <infinity> Okay, I think I got all the NBS in proposed.
[18:27] <infinity> At least, all the rename-related NBS.
[18:29] <infinity> slangasek: http://paste.ubuntu.com/12049946/ cleaning up that might help a bit.
[18:29] <infinity> Hopefully we don't see too many more "try to build, then rename later" shenanigans.
[18:29] <infinity> s/build/rebuild/
[18:44] <doko> infinity, did you see my gdb ping?
[18:45] <infinity> doko: I did, yeah.  Rebuilding it and will ask a WeBop to babysit when it stalls again.
[18:45] <infinity> doko: Not exactly an ideal workflow going forward, mind you.
[18:46] <doko> sure, I can disable the testsuite, which isn't ideal either.
[18:49] <infinity> doko: Quite.  Disabling the one test might be okay.  Finding out why it explodes might also be nice.  gdb still tries pretty hard to kill my ppc builders too.
[18:49] <infinity> Not that any of that is gdb's fault, it's clearly kernel bugs.
[18:50] <infinity> doko: Anyhow, we'll do the hackish thing for today.
[18:54] <doko> is oftc irc down? can't connect
[18:54] <teward> doko: up for me
[18:56] <ScottK> doko: Working here.
[19:00] <doko> hmm, nslookup irc.debian.org fails for me from germany, brazil,
[19:01] <teward> doko: nslookup on irc6.geo.oftc.net
[19:01] <teward> (irc.debian.org is a CNAME to that)
[19:01] <teward> ooop
[19:01] <teward> doko: actually, looks like OFTC's dns is possibly blown up
[19:01] <doko> no, doesn't work either
[19:01] <teward> yeah it shouldn't
[19:02] <doko> ok, will wait
[19:02] <teward> http://paste.ubuntu.com/12050243/
[19:02] <teward> SERVFAIL
[19:03] <teward> doko: i could give you the v6 addr for one of their servers now if you want.  don't have v4 because it's connected to my bouncer, but..
[19:04] <teward> until they fix DNS anyways
[19:04] <doko> getting food first =)
[19:05] <teward> mmkay
[19:05] <infinity> doko: Curious.  The testsuite didn't hang on armhf this time.
[19:19] <slangasek> ok, that's strange, I just reloaded http://people.canonical.com/~ubuntu-archive/transitions/html/icu.html and mediawiki2latex has dropped off of there when it shouldn't have
[19:19] <slangasek> has someone deployed changes to snakefruit?
[19:19] <slangasek> (Laney?)
[19:20] <slangasek> oh, no, I see, someone actually fixed mediawiki2latex
[19:20] <slangasek> tricky
[19:20] <teward> doko: apologies for discussion derailments.  But, in the interim: i've made a note to OFTC that their DNS is explodified.  sarnold poked that up to people there.  beauty.oftc.net is 2604:a880:800:10::870:a001 port +6697 and is up, although DNS won't resolve because i think their DNS exploded.
[19:20] <slangasek> and that was Laney too, right attribution wrong change ;)
[19:20] <teward> in case anyone else here with v6 who needs to get to OFTC needs to get there... :P
[19:23] <slangasek> ok, now this one is *not* due to a fix... mrtrix is broken and FTBFS on armhf, but no longer shows up on http://people.canonical.com/~ubuntu-archive/transitions/html/gtkmm2.4-g++5.html
[19:26] <Laney> My thing totally broke for packages which contain "+" :)
[19:26] <Laney> I avoided using regex now...
[19:28] <slangasek> heh
[19:28] <slangasek> Laney: did you deploy any changes to snakefruit, though?  I'm trying to figure out why mrtrix is gone from the tracker
[19:29]  * Laney looks
[19:29] <Laney> it's showing as unknown
[19:30] <slangasek> hrm
[19:30] <Laney> for armhf
[19:30] <Laney> but why?
[19:31] <Laney> oh, because I made it remove the old binaries from Packages - this seems suboptimal
[19:31] <slangasek> ok; so the filter is wrong, 5 good + 1 unknown should still show when 'unknown' is checked, surely
[19:31] <slangasek> and looking at the package in the archive, it doesn't look 'unknown' to me
[19:32] <slangasek> ah, so you did deploy a change :P
[19:32] <slangasek> Laney: are you reverting this?
[19:33] <Laney> Thinking
[19:33] <slangasek> Laney: please revert this ;)
[19:57] <doko> slangasek, xnox: any news about the boost1.58 rebuilds?
[20:20] <doko> teward, oftc works again
[20:20] <slangasek> doko: I haven't been tracking boost, I assumed xnox was doing something with it and that I'd just get in the way if I tried to trigger rebuilds
[20:21] <teward> doko: their DNS just came back up yes
[20:21] <teward> doko: in any case if it breaks in the future https://pbin.dark-net.net/view/raw/0411bee5 is a 'good server' for now
[20:21] <teward> (that'll be there for a week, that pastebin)
[20:37] <slangasek> xnox: the scripts I have on hand for batch-uploading don't map to boost, should I hack up a new one or do you have something scripted to go on your side?
[20:45] <tdaitx> slangasek, please try to rebuild notmuch, I tried a local build and it went ok
[20:49] <tdaitx> robru, ^ in case you can also trigger a rebuild for notmuch
[20:49] <robru> tdaitx: so far I trigger rebuilds by asking slangasek to do it ;-)
[20:51] <tdaitx> robru, alright then, I will keep pestering him about it
[21:08] <tdaitx> robru, slangasek, as for the ceph issue, here is the bug (with fix): http://tracker.ceph.com/issues/11576
[21:08] <robru> cool
[21:09] <slangasek> tdaitx: any idea what changed that would make notmuch work again?  FWIW I did previously reproduce the build failure locally against wily-proposed
[21:09] <tdaitx> slangasek, nope, I tried to reproduce it locally and it build ok
[21:09] <slangasek> ok. I'll retry it in launchpad
[21:10] <tdaitx> I saw that my env had newer packages and that's it
[21:10] <robru> tdaitx: slangasek: https://github.com/ceph/ceph/pull/5122/files so I guess we need to distropatch this fix onto our existing package?
[21:10] <robru> or pull a newer upstream?
[21:12] <slangasek> robru, tdaitx: the ceph package is owned by the server team and in main, we shouldn't take it upon ourselves to pull a new upstream version without coordinating with them.
[21:12] <slangasek> tdaitx: if you have a patch for ceph, you might want to throw it in the direction of smoser
[21:12] <slangasek> (e.g. on #ubuntu-devel)
[21:13] <doko> tdaitx, LP: #1483403
[21:13] <ubot93> Launchpad bug 1483403 in ceph (Ubuntu) "ceph FTBFS with boost1.58" [Critical,Confirmed] https://launchpad.net/bugs/1483403
[21:14] <slangasek> ah yes, so posting the patch there and letting the server team pick it up seems like a good approach
[21:19] <doko> tdaitx, not much luck
[21:24] <doko> slangasek, why didn't you mark clementine and notmuch as removal candidates?
[21:25] <slangasek> doko: notmuch because it has revdeps and is popular so I wasn't considering it a removal candidate, but that doesn't mean it can't be removed. clementine, I don't know why ;)
[21:39] <slangasek> doko: oh, because the clementine issue is a trivial fix, that's why
[21:40] <slangasek> doko: #ifndef Q_MOC_RUN // #include <boost/thingy.hpp> // #endif
[21:40] <doko> slangasek, yeah, was talking with sitter about that for kdepim as well
[21:41] <doko> slangasek, debian seems to close many transitions as not needed. with their next sourceful uploads, these will appear again in -proposed (because the old binary is still there). how could we avoid this?
[21:42] <slangasek> doko: track the ones that are closed as not-needed, we should revert the package name transitions and add a Provides: libfooNv5 for compatibility
[21:43] <slangasek> possibly even a Provides: libfooNv5 (= $version), since I hear that works now with apt/dpkg in vivid and wily
[21:43] <slangasek> then we rebuild the revdeps (again) if necessary, but it can be a soft transition
[21:45] <slangasek> strange, why did numexpr just get into wily? (python3.5 no-change rebuild uploaded 19 days ago)
[21:46] <slangasek> because p-m+autopkgtest went wrong
[21:46] <tdaitx> notmuch rebuild failed... hmm, I wonder what is "wrong" with my local sbuild
[21:46] <slangasek> tdaitx: is your local sbuild configured to build against wily-proposed, or only against wily?
[21:47] <tdaitx> I had a wily that had proposed disabled, but I installed/made a new one that includes proposed
[21:47] <tdaitx> or at least I thought I did, will check that... again
[21:48] <slangasek> ok
[21:52] <tdaitx> slangasek, apologies, how can I be sure my schroot is indeed running -proposed? it does show in apt sources.list and I can see gcc5 5.2.1 (instead of 5.1..1)
[21:52] <slangasek> tdaitx: well, those are the things I would check also so it sounds like you're there
[21:52] <slangasek> tdaitx: are you running the build under sbuild?
[21:53] <tdaitx> right
[21:53] <tdaitx> yes, I am
[21:53] <tdaitx> I will try another build after ceph is done
[21:53] <tdaitx> meanwhile I will compare the build logs
[21:59] <slangasek> doko: is openvdb on your radar?  your last upload went from 4 archs failing with .symbols mismatch, to 6 archs failing with .symbols mismatch
[22:03] <doko> slangasek, ok, I'll look
[22:04] <tdaitx> slangasek, what's the right way to fetch the package? I'm using  pull-lp-source <pkg> wily-proposed
[22:05] <infinity> tdaitx: You just need "wily", it'll magically pick the latest version from wily{-updates,-security,-proposed}
[22:05] <infinity> tdaitx: Or indeed, no argument, which defaults to the dev release, which is wily.
[22:05] <tdaitx> the version matches, but I can see a few differences in the build logs that made me wonder if I actually have the same thing
[22:07] <infinity> tdaitx: Such as?
[22:08] <infinity> tdaitx: Could be as simple as you comparing a -A build with not. (ie: amd64 on LP builds -A, while all other arches don't, and the sbuild default is withuot, IIRC)
[22:09] <doko> infinity, tdaitx: so notmuch succeeds locally here in fresh sid and wily-proposed chroots, with the wily-proposed kernel running
[22:10] <tdaitx> meh, not such meaningful changes actually... setup.py running files in a different order (might be ok actually), a few different packages being installed...
[22:14] <tdaitx> doko, succeeds locally here as well, 3.19.0-25-generic
[22:18] <infinity> doko: Yeah, confirmed here too.  So we might just need to disable that one test when run on << 3.19
[22:18] <infinity> Except... That's still sketchy.  Cause it built BEFORE all these rebuilds.
[22:19] <infinity> And the kernels weren't downgraded. :P
[22:19] <infinity> Oh, not in this version, though.  Maybe that test is new.
[22:20] <infinity> Yeah, okay, same test was failing before the transition too.
[22:22] <tdaitx> infinity, any chance we can get a set -x in that test/T160-json.sh script? at least to see where exactly it is failing?
[22:22] <infinity> tdaitx: Not easily.
[22:22] <infinity> tdaitx: Not without uploading to a PPA with said hack in place.
[22:24] <infinity> So, that's kinda suspicious.  It was working with 0.17-3, started failing with 0.17-5 ...
[22:25] <infinity> It's possible the packaging broke, but seems more likely that coincides with a dependency breaking.
[22:25] <infinity> Especially since the packaging didn't change meaningfully between those versions.
[22:27] <tdaitx> infinity, sorry, how did you tell it started failing with 0.17-5?
[22:28] <infinity> tdaitx: Drilled back through publishing history until I found the earliest one with failures.
[22:28] <infinity> tdaitx: https://launchpad.net/ubuntu/+source/notmuch/0.17-5
[22:29] <infinity> And there are zero changes between -3 and -5 to account for it, so it has to be something else than changed (a dep, toolchain, etc)
[22:29] <infinity> Same kernel on both builds too.
[22:30] <doko> the toolchain doesn't have bugs, it only exposes some
[22:30] <infinity> doko: Uh huh. :)
[22:30] <doko> well, at least until now I didn't see one for GCC 5
[22:31] <infinity> doko: This isn't gcc-5, this has been breaking since trusty.
[22:31] <infinity> Or, utopic rather.
[22:31] <doko> yeah, some people are behind with merges ...
[22:32] <infinity> doko: This has nothing to do with merges.  It's a package without a delta whose autosyncs have been failing for two years.
[22:57] <infinity> tdaitx: Your sh -x request: https://launchpad.net/~adconrad/+archive/ubuntu/ppa/+build/7782298
[22:58] <robru> infinity: any low-hanging fruit you can throw my way? I just got a succesful build of clementine and mailed the debdiff to slangasek
[22:58] <infinity> robru: No idea, I'm not on top of the transition stuff, since I wasn't involved last week.
[22:58] <robru> heh, he told me you'd know since he's afk briefly
[23:00] <infinity> robru: He lied. :)
[23:00] <robru> well, anybody else know any easy transition bits for a noob to poke at?
[23:02] <slangasek> infinity: I said that you would be able to guide, which I have every confidence in even if you don't already know ;)
[23:02] <robru> he's back!
[23:03] <slangasek> robru: try libktorrent, same basic issue as clementine
[23:03] <robru> thanks
[23:06] <tdaitx> infinity, bummer, I was setting up my ppa =P
[23:06] <tdaitx> infinity, anyway, it is stuck in a loop... it seems to be missing at least one dependency
[23:07] <infinity> Oh, maybe the reason it works locally is because my local schroot is a tiny bit fatter than the lp-buildd chroot tarballs.
[23:09] <infinity> Bah, we still don't have "apt-get build-dep foo.dsc"
[23:09] <infinity> Must be in apt 1.1
[23:09] <tdaitx> I am not sure, mine is supposedly very slim
[23:09] <tdaitx> and it still passes
[23:13] <infinity> tdaitx: Testing a theory on the one thing I guarantee is different.  Sec.
[23:14]  * tdaitx still waiting for ceph to finish... doh, forgot parallel build! to kill or not to kill?
[23:15] <infinity> tdaitx: My .bashrc has this at the end, so I never have to think about it:
[23:15] <infinity> export DEB_BUILD_OPTIONS="parallel=$(nproc)"
[23:15] <tdaitx> indeed
[23:15] <infinity> Hrm, purging locales didn't break it.  That was my one good guess.
[23:16]  * infinity compares an entire dpkg -l with the build log.
[23:19] <tdaitx> so... after uploading to my ppa, how long does it usually take for the builders to grab it?
[23:23] <infinity> Bah.  Literally identical set of packages installed, still no failure.  Not we're in the realm of the bizarre.
[23:23] <infinity> tdaitx: Depends on queue depth.
[23:31] <infinity> tdaitx: Though, generally, you have to actually upload something first.
[23:31] <infinity> (I see nothing in your PPA)
[23:31] <ScottK> Now you're getting demanding.
[23:31] <infinity> ScottK: I know, I'm a stickler.
[23:33] <tdaitx> infinity, but I did run dput and it said the world was good and peaceful
[23:33] <tdaitx> did it lie?
[23:33] <infinity> tdaitx: dput just fires and forgets.
[23:33] <infinity> tdaitx: You either (a) have a REJECT email, if your upload was unacceptable, or you (b) have zero feedback at all if you forgot to sign your upload.
[23:34] <infinity> I'm betting on B.
[23:34] <tdaitx> I did sign it, dput checked that
[23:34] <infinity> Then check your email. :)
[23:35] <infinity> (I'm going to assume you signed it with the same key LP knows...)
[23:35] <tdaitx> infinity, indeed, it was rejected
[23:35] <tdaitx> oh yeah, from the command line it seemed like dput checked even that
[23:36] <infinity> dput just checks that it's signed, period, not who it's signed by.  Though, if you got a reject, it was the right key.
[23:36] <infinity> And something else was wrong.
[23:36] <tdaitx> right, I cant submit to wily-proposed
[23:36] <infinity> Yeah, get out of that habit anyway.
[23:36] <infinity> The correct thing to upload to is always just "$release".
[23:37] <infinity> For PPAs without pockets, that works, and for the primary archive, we map $release to $release-proposed on the server side.
[23:37] <tdaitx> nice
[23:37] <tdaitx> infinity, ha! I was able to reproduce the issue locally
[23:38] <infinity> tdaitx: !
[23:38] <tdaitx> infinity, TERM="unknown" sbuild
[23:38] <infinity> Ahh!
[23:38] <tdaitx> dtach does not like an unknown term
[23:38] <infinity> Also, balls.  That means our term setup is different from Debian's, where it succeeded on all buildds.
[23:38] <tdaitx> I have been bitten by that I don't remember how long ago
[23:38] <tdaitx> yes
[23:39] <tdaitx> mine was rxvt-unicode, from my own term
[23:40] <infinity> Looks like Debian isn't explcitly setting TERM at all, so hard to say what setting is leaking through.
[23:40] <infinity> I guess whatever the buildd pid has.
[23:41] <infinity> Man, and we tried to hard to be 100% compatible. :P
[23:41] <infinity> I even remember when we made this change (which coincides with when this build started failing).
[23:41] <infinity> For now, though, a delta to call the testsuite with TERM=vt100 or something will probably work.
[23:42]  * infinity tries.
[23:45] <tdaitx> infinity, yeah, that should do it... vt100 or even xterm (I can see it installed on my failed build session)
[23:46] <infinity> Already testing vt100, so if that works, that wins.
[23:46] <tdaitx> or linux
[23:48]  * tdaitx is somewhat happy to have battled against dtach on the past
[23:50] <robru> hey release peeps, I've analyzed http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gcc-5 and found that kservice, libktoblzcheck, kdeclarative, autopilot-gtk, step regresions are more recent than the gcc5 upload (eg, those autopkgtests passed with the initial gcc5 upload then failed later for other reasons)
[23:53] <robru> infinity: ^
[23:54] <infinity> tdaitx: Okay, confirmed that this works: http://paste.ubuntu.com/12052461/
[23:54] <infinity> tdaitx: Will upload after making the changelog more manager friendly.
[23:55] <tdaitx> infinity, great =)
[23:55] <tdaitx> oh yeah, be "nice" on the changelog
[23:57] <infinity> tdaitx: Thanks for the analysis!
[23:58] <infinity> robru: Your analysis, I'm less sure what to do with.  If those are new failures, we kinda still need to know why.
[23:58] <robru> infinity: yeah I'm not really sure either. slangasek asked me to look into that. apparently the ones I listed shouldn't block the gcc5 transition
[23:58] <tdaitx> infinity, you are welcome =)
[23:59] <slangasek> infinity: yes, this is for unblocking gcc-5, not for ignoring the failures wholesale
[23:59] <tdaitx> ceph just passed locally
[23:59] <tdaitx> one, two down... one, two to go...
[23:59] <infinity> slangasek: Check.
[23:59] <infinity> robru: So, are those the only regressions britney's hating on?
[23:59]  * infinity looks.
[23:59] <robru> infinity: no there's other regressions
[23:59] <infinity> Right, in that case, not much I can do about it yet.