[00:23] <slangasek> man, what's with the sort order on http://people.canonical.com/~ubuntu-archive/transitions/
[00:24] <slangasek> xnox: are you driving no-change rebuilds for boost1.58?
[00:25] <slangasek> I have a stack of ABI-breaking libraries /on top/ of gnuradio whose build-deps are currently uninstallable because of boost->libzeep->gnuradio, so if nobody is batching those up I suppose I should take a look soon
[00:26] <slangasek> OTOH I should also double-check that these gnuradio revdeps are actually libraries and not just plugins or something
[01:04] <slangasek> anyone have the url to the last full-archive rebuild test? (main+universe)
[01:15] <slangasek>  looks like this might be it - https://launchpad.net/ubuntu/+archive/test-rebuild-20150402
[01:51] <slangasek> Package: libgdome2-cpp-smart0v5
[01:51] <slangasek> Conflicts: libgdome2-cpp-smart0c2a, libgdome2-cpp-smart0, libgdome2-cpp-smart0c2
[01:53] <slangasek> latest script revision, smarts added to handle c2/c2a -> v5 renaming. http://paste.ubuntu.com/11997246/
[04:27] <slangasek> should kdepimlibs have gotten a package name transition already?  it shows up in my to-be-converted list
[07:15] <slangasek> wow, so hdf5's C++ library has a symbols file where every single symbol is marked 'optional' and new symbols are not build failures.  ok then!
[07:33] <slangasek> ... and furthermore there's a version script, which doesn't match any of the new symbols
=== utlemming is now known as utlemming_away
=== utlemming_away is now known as utlemming
[17:53] <slangasek> ugh who let gadap into the archive (library package builds only .a, which is used by other packages in the archive)
[17:54] <infinity> slangasek: #debian-ftp is over there.
[17:54]  * infinity points.
[17:55] <infinity> slangasek: Though, it seems to only have one r-build-dep, so it could be worse...
[17:59] <slangasek> infinity: yes, it's still a pain for abi transitions
[17:59] <infinity> slangasek: Don't worry, Go will save us all from this evil C++.
[18:01] <infinity> slangasek: Also, can you be a dear and review ubuntu-drivers-common/trusty?
[18:02] <infinity> I suppose I should make sure it passes its testsuite first...
[18:06] <infinity> Oh look, it passes.
[18:13] <infinity> bdmurray: You around?
[18:16] <bdmurray> infinity: yep
[18:17] <infinity> bdmurray: Too late, I think arges is on the case.
[18:17] <infinity> slangasek: Disregard the pleading for review.
[18:17] <bdmurray> infinity: when is this point release?
[18:17] <infinity> bdmurray: Thursday.
[18:18] <bdmurray> infinity: okay, I was just thinking about meta-release changes and being out on Friday
[18:18] <infinity> bdmurray: Ahh, yeah.  Who else has commit to that?  We really need to spread it around a bit more.
[18:19] <infinity> ... not that it's accurate anyway right now.
[18:19] <infinity> Whee.
[18:19] <infinity> bdmurray: lucid still claims to be Supporter: 1 in meta-release-lts.
[18:19] <infinity> And in meta-release
[18:19] <infinity> And, not shockingly, -development.
[18:20] <infinity> bdmurray: I must have missed bugging you about EOL on that one.
[18:21] <infinity> bdmurray: Then again, no one ever changed it to 10.04.4 either, so it seems lucid is full of meta-release fail. :)
[18:21] <arges> infinity: ok accepted ubuntu-drivers-common into trusty-proposed
[18:21] <infinity> arges: Ta!
[18:21] <bdmurray> infinity: I'll have a look at fixing that.
[18:25] <slangasek> infinity: ok disregarding
[18:32] <slangasek> seb128: did you look at reverse-depends before removing xbmc from wily?  xbmc-pvr-addons, at least, should also go
[18:33] <slangasek> (or be renamed or something
[18:33] <slangasek> )
=== jhodapp__ is now known as jhodapp_
=== jhodapp_ is now known as jhodapp
[18:51] <bdmurray> infinity: wrt meta-release its cjwatson, mvo and me
[18:59] <infinity> bdmurray: Yeah, should probably add me to that list, since two of those people are not directly involved in the release process anymore.
[19:08] <bdmurray> infinity: I'll submit an RT for you since its a group change on a server and I know the details.
[19:08] <infinity> bdmurray: Ta.
[19:09] <infinity> bdmurray: Then tell me what branch I'm supposed to check out. :P
[19:12] <bdmurray> infinity: ~ubuntu-core-dev/meta-release/ubuntu/
[19:12] <infinity> bdmurray: Well, based on the path, I assume lots and lots of us have commit to that...
[19:12] <infinity> bdmurray: So, there's clearly a second step here that involves changelogs.u.c
[19:13] <bdmurray> infinity: yeah, there is some manual copying around on the server
[19:13] <infinity> bdmurray: Check.
[20:28] <slangasek> robru: I'm about to trigger mass-rebuilds for tinyxml, because I found some intersection between that transition and the libjsoncpp one
[20:28] <slangasek> robru: so http://people.canonical.com/~ubuntu-archive/transitions/html/tinyxml-g++5.html may be worth looking at in a little bit
[20:29] <robru> slangasek: oh hey. sorry I'm late going to lunch, the creds leak situation turned out to be worse than I thought (in addition to the fixes I told you, it's also leaking tokens when debugging is enabled). so I've only just fixed this, just about to lunch now
[20:29] <slangasek> ok
[20:29] <robru> slangasek: thanks for the tip though
[21:36] <slangasek> looking into the ogre-1.8 FTBFS
[21:36] <slangasek> (by way of a convoluted chain of dependencies that will not be expanded here)
[22:28] <robru> slangasek: ok sorry about that, what am I looking at on that page there?
[22:28] <robru> slangasek: I see a whole lot of red X's. that's good, right?
[22:29] <slangasek> robru: it's good that you see them but not good that they're there
[22:29] <robru> heh
[22:29] <robru> slangasek: so I should just drill down into the build logs and figure out what the failures are?
[22:30] <slangasek> robru: you'll notice a double dose of them in arm64, ppc, and (to a lesser extent) ppc64el; those are ignoreable for now and just mean that the builders for those archs are a little behind.  For the ones with x in the amd64 column, yes, drill down and figure out the cause of failure
[22:30] <robru> slangasek: ah I was just about to ask if there was a distinction between "failing on all arches" and "failing on some arches", you read my mind ;-)
[22:31] <slangasek> robru: particularly for packages that have XubuntuY version numbers, it's worth looking whether there's a newer version in Debian that might fix the failure (merges.ubuntu.com)
[22:32] <slangasek> robru: for packages that a reasonable fix is possible, prepare a source package and submit it to sponsorship queue (which in this case means: open bug on package, upload debdiff, subscribe ubuntu-sponsors) and you can also ping here for uploads
[22:33] <slangasek> robru: for unseeded packages where a fix seems untractable, it's often reasonable to remove the package from wily and wait for a fix from Debian; feel free to propose removals where you think this is appropriate
[22:33] <robru> slangasek: oh man that sounds like a crusty workflow. can't just dput to my ppa or something?
[22:34] <slangasek> robru: and if you find packages that are failing to build because their build dependencies are uninstallable, that may indicate that we need to traverse a different part of the dep chain or retry the builds etc
[22:34] <slangasek> robru: no, the sponsors don't want to be redownloading a full package from a ppa :)
[22:35] <slangasek> interchanging debdiffs is more efficient
[22:35] <robru> slangasek: k I'm not great with debdiffs but I'll figure it out. should I be attempting to reproduce these failures locally in sbuild or something?
[22:35] <slangasek> robru: generally yes
[22:36] <robru> alright
[22:36] <slangasek> as for debdiffs, the command is 'debdiff' to create a diff between two source packages (.dscs)
[22:36] <infinity> robru: "Not great with debdiffs"?  After you build that source package you would have uploaded to your ppa, "debdiff old.dsc new.dsc > new.debdiff" done.
[22:36] <robru> infinity: well I don't have old.dsc at the moment ;-)
[22:36] <infinity> For bonus points, read the debdiff too. :P
[22:36] <infinity> robru: How are you lacking old.dsc?
[22:37] <infinity> robru: Oh.  If you're using UDD/bzr for this and trusting the branches to be accurate, stop that.
[22:37] <robru> infinity: because I literally *just* started looking at this and I don't have anything on my system at all.
[22:37] <infinity> robru: pull-lp-source $package && hack, hack, hack && debuild -S && debdiff old new.
[22:37] <slangasek> robru: 'pull-lp-source'
[22:38] <robru> slangasek: infinity: thanks. last time I tried asking around for how to download source packages nobody seemed to know and I ended up writing some hack to fudge sources.list to make 'apt-get source' download from other archives.
[22:39] <slangasek> I guess you didn't ask the right people ;)
[22:39] <robru> slangasek: no apparently not. but they were core devs oddly
[22:39] <cjwatson> pull-lp-source knowledge has been percolating outwards for a while.  I think most people have heard of it now but that was less so a year or so ago
[22:40] <robru> now I need to figure out how to set up sbuild ;-)
[22:40] <cjwatson> https://wiki.ubuntu.com/SimpleSbuild
[22:40] <robru> thanks
[22:40] <infinity> Sadly, pull-debian-source is in a bit of a state, with Debian's APIs in flux.  Need to fix that to use ftpmaster's new shiny on all releases.
[22:40] <infinity> But pull-lp-source is definitely love.
[22:41] <robru> oh man, sbuild wants to pull in exim4. Can it, like, not?
[22:41] <infinity> robru: apt-get install nullmailer sbuild
[22:42] <robru> infinity: thanks
[22:42] <infinity> robru: Or some real MTA of choice, if you want to mail stuff.
[22:42] <robru> infinity: nah, happy gmail user
[22:42] <infinity> (sbuild likes to mail out build logs, but this feature is perhaps of questionable value to the average dev)
[22:43] <robru> yep, sounds useless to me