[00:14] <robru> infinity: hey if you have a sec (ha), the lplib autopkgtest has a fix in trunk and just needs to be released to unblock simplejson.
[00:15] <infinity> wgrant: ^-- Hey, core-dev, release your own software.
[00:15] <wgrant> infinity: adt image downloading thing is still downloading images
[00:15] <wgrant> slow internet is slow
[00:16] <wgrant> I didn't realise it was actually blocking things.
[00:16] <infinity> Ahh, so you're already on it?  Awesome.
[00:17] <infinity> wgrant: I think someone was whining in another channel about it being out-of-date on pypi too, if you feel like killing multiple birds whilst in a software release context.
[00:23] <slangasek> gee, a whole lot of my uploads that I don't care about sure are making it into wily
[00:24] <infinity> slangasek: That's the good kind of spam, no?  I always feel some small bit of undeserved pride every time I see an ACCEPTED email from a queue.
[00:25] <slangasek> heh
[00:25] <slangasek> these are the p-m ones
[00:25] <slangasek> for libraries I never heard of before Monday
[00:25] <infinity> slangasek: Also, thanks for helping utlemming with that xe-utils thing.  After my second (and third) round of reviews, I think it's almost not icky.
[00:26] <slangasek> infinity: you may be a packaging hypochondriac
[00:26] <infinity> slangasek: I'm... Not sure what that means.
[01:41] <slangasek> anyone looked at marble yet?
[01:43] <slangasek> ok, looks like a symbol symbols ftbfs
[03:17] <slangasek> infinity: could you take a look at apt 1.0.10? python-apt dep-waits on it, which blocks language-selector-common -> kde-runtime
[03:33] <infinity> slangasek: Yeah, I was going to try merging it tonight, and if it's too much of a pain, just drop the python-apt versioned dep a bit, since it's only got it for the transition.
[03:33] <slangasek> infinity: changelog says it was bumped for a new interface
[03:33] <slangasek> ("Files2")
[03:35] <infinity> slangasek: Which changelog...?
[03:36] <slangasek> infinity: python-apt
[03:36] <slangasek> infinity: oops no, that says 1.0.9.4
[03:36] <infinity> slangasek: I don't see the string "Files2" anywhere in http://launchpadlibrarian.net/213586903/python-apt_1.0.0~beta3ubuntu1_1.0.0~beta3.1.diff.gz
[03:36] <slangasek> sorry
[03:37] <slangasek> infinity: however I just tried to downgrade the build-dep here and build, and it fails with pep8 test failures
[03:37] <infinity> Well, that would be entirely unrelated, and due to the new pep8. ;)
[03:37] <infinity> But I can look at that too.
[03:37] <slangasek> yeah
[03:37] <slangasek> it does mean the C built successfully anyway
[03:39] <slangasek> hmm and the kservice test that fails on i386 via p-m with a complaint about threads succeeds locally in an i386 chroot
[03:44] <infinity> slangasek: Perhaps needs an i386 kernel to reproduce?
[03:48] <infinity> Heh, happy to see jak is on the same "screw E402" page with python-apt that I was with unattended-upgrades.
[03:53] <pitti> heh, I added --ignore=E402 as well -- it's outright impossible to do that for some projects
[03:54] <pitti> if you have to set sys.path before "import"
[03:55] <pitti> slangasek: oh nice, http://autopkgtest.ubuntu.com/packages/k/kservice/wily/i386/ succeeds again
[03:56] <pitti> pytables also had a weird crash which now seems fixed
[03:56] <pitti> so whatever changed, good :)
[03:56] <slangasek> oh nice, flaky tests ;)
[03:59] <pitti> slangasek: nice, marble passed again too, thanks!
[03:59] <infinity> pitti: Yeah, I looked at "fixing" it in unattende-upgrades, followed the upstream pep8 bug "discussion" (argument), and just came to the conclusion that's it's a pointless error.
[03:59] <slangasek> pitti: yeah, that one required an actual fix, but done now
[03:59] <pitti> slangasek: right, hence the "thanks" :)
[04:01] <slangasek> libsfml had a package name change but there was no transition tracker for it; triggering rebuilds for that now
[04:04] <pitti> I uploaded the kicad fix now, so that it's easier to retry once apw uploads the fixed boost
[04:26] <infinity> slangasek: I opted for patching python-apt and letting mvo deal with the apt merge when he's back.  I can never decide if half his apt delta is on purpose or mistakes, but I'd rather let the mistakes be his. :P
[04:29] <infinity> Maybe I'll use my vacation to rewrite his evil build system; especially the part that mangles all the po files every time I sneeze near my laptop.
[04:36] <pitti> debuild -S -nc FTW :)
[04:36] <infinity> pitti: Yeah, that's how I always upload apt.
[04:36] <infinity> pitti: Well, that's how I always upload most things, but apt pretty much requires it.
[04:38] <pitti> ah, lots of k* just became "valid candidate", but still some uninstallables in _output
[04:39]  * pitti grabs wily-proposed schroot and pokes
[04:42] <pitti> skipped: khtml (6 <- 864)
[04:42] <pitti>     got: 63+0: a-63
[04:42] <pitti>     * amd64: libkf5kdelibs4support-dev, libkf5khtml-dev
[04:43] <pitti> so if I read that right, britney claims that khtml breaks libkf5kdelibs4support-dev ?
[04:43] <pitti> cause "chdist apt-get wily-armhf install libkf5khtml-dev libkf5kdelibs4support-dev" works fine
[04:45] <pitti> or is that part of the big "too much for britney's little brain"?
[04:45] <infinity> pitti: Try that with foo- on the end for the packages that were removed from khtml.
[04:45] <pitti> oh, because NBS?
[04:46] <infinity> I'm assuming that packages were removed anyway...
[04:46] <pitti> nope, no NBS
[04:46] <pitti> at least not from khtml
[04:46]  * infinity looks at output.txt
[04:46] <pitti> same for kdelibs4support
[04:48] <pitti> ah, "install libkf5khtml-dev kubuntu-desktop" fails, maybe that'll lead to something
[04:50] <pitti>   Considering libqca2:armhf -1 as a solution to libqca2v5:armhf 15
[04:50] <pitti>   Added libqca2:armhf to the remove list
[04:50] <pitti>   Fixing libqca2v5:armhf via keep of libqca2:armhf
[04:50] <pitti> ok, that's at least something concrete to do
[04:51]  * pitti stabs http://people.canonical.com/~ubuntu-archive/transitions/html/html/qca2-g++5.html
[04:54] <pitti> this tracker looks wrong -- several packages like kadu built successfully days ago
[04:55] <infinity> pitti: kadu only built on 2/6 arches.
[04:55] <pitti> but even those aren't marked as "done", and https://launchpad.net/ubuntu/+source/psi/0.15-2build1 built everywhere 4 days ago
[04:56] <pitti> I checked the build log, no stray hardcoded "libqca2" deps
[04:56] <infinity> Weird.
[04:56] <pitti> https://launchpad.net/ubuntu/+source/kdeconnect/0.8-0ubuntu3 even already propagated
[04:58]  * pitti wonders if it's the \b, most other trackers use a different re
[04:59] <pitti> I'll just adjust that and check in the next run, and until then go through the logs
[04:59] <pitti> hm, http://people.canonical.com/~ubuntu-archive/transitions/html/html/snappy-g++5.html used the same syntax and was happy
[05:01] <pitti> ooh, I know!
[05:01] <pitti> Depends: libqca2-plugins
[05:01] <pitti> that matches libqca2\b
[05:03] <infinity> Hahah.  Oops.
[05:03] <pitti> pushed
[05:07] <pitti> ok, missing rebuilds uploaded, there are a couple of FTBFS
[05:28]  * pitti sobs at qmake
[06:13] <Mirv> could sources qtcreator-plugin-remotelinux and qtcreator-plugin-cmake be removed from wily-proposed? the new Qt Creator 3.5 RC in -proposed pocket has the changes in those packages (which were partial forks of QtC 3.1 sources) after zbenjamin submitted everything upstream. the conflicts/breaks are there so upgrades are smooth.
[06:16] <pitti> Mirv: you mean from wily? it's not in -proposed
[06:16] <Mirv> pitti: yes, of course, I was just thinking about proposed migration
[06:17] <pitti> Mirv: you mean the qtcreator package  itself ships these modules?
[06:17] <pitti> I see it has Conflicts: to them, but not Replaces:/Provides:
[06:18] <Mirv> pitti: yes, they are part of the normal QtC but they were removed from Ubuntu's normal QtC so that they could be replaced from elsewhere
[06:18] <pitti> thus most likely apt will rather hold back the new qtcreator than removing these plugins
[06:18] <Mirv> pitti: they are in a new path in the new QtC
[06:18] <Mirv> hmm, it upgraded fine in my wily-proposed chroot
[06:18] <pitti> well, I wouldn't bet on it with just Conflicts:
[06:19] <pitti> so yes, fine to remove these from wily, but adding R/P: is still necessary IMHO
[06:20] <Mirv> ok
[06:20] <Mirv> doing a new upload of qtcreator
[06:20] <pitti> Mirv: what about qtcreator-plugin-qnx and qtcreator-plugin-valgrind, as well as all the -dev? these are also built from the old sources, but not by qtcreator
[06:22] <Mirv> pitti: they are all in the main qtcreator package that has tens of plugins, those were just ripped out of the main qtcreator package earlier. the -dev were not real -dev:s since Qt Creator doesn't officially support these kind of external plugins, so they were sort of hand made by benjamin
[06:22] <pitti> Mirv: right, but I mean it should C/R/P: those packages too then
[06:23] <Mirv> pitti: right, ok
[06:24] <Mirv> so I'm now adding C/R/P for all the old binary packages
[06:25] <pitti> Mirv: thanks
[06:25] <pitti> Mirv: http://paste.ubuntu.com/12077489/
[06:25] <Mirv> thanks!
[06:42] <infinity> pitti: No need for "provides" if nothing depends on them, only C/R to force them off.
[06:42] <infinity> (Not that all 3 hurts much either)
[07:24] <darkxst> infinity, hi, can you remove gnome-online-accounts 3.16 from wily-proposed
[08:12] <pitti> ah, seems I fixed the regexps at http://people.canonical.com/~ubuntu-archive/transitions/html/qca2-g++5.html hard enough at last
[08:14] <pitti> argh, hardcoded lib dep
[08:14]  * pitti uploads kdeconnect, take III
[11:12] <darkxst> hmm current ubuntu-gnome wily daily images, don't want to boot ;( syslinux seems to be hanging
[12:15] <infinity> darkxst: Was that gnome-bluetooth upload in -proposed a mistake?  It's got a ~ppa version.
[12:16] <darkxst> infinity, I think seb copied it from the ppa
[12:16] <darkxst> https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/transitions
[12:16] <infinity> Oh, hrm, seems to be a few ~ppa versions in wily.  Ick.
[12:17] <darkxst> I certainly didnt upload them to the archive
[12:18] <seb128> I was unsure if I should change them just to avoid the number of just copy
[12:18] <seb128> so I decided to just copy
[12:18] <seb128> it's only a version number, doesn't matter much
[12:18] <infinity> seb128: It's not the end of the world.  As you say, only a version number.
[12:18] <infinity> seb128: That said, as an end user, I see "ppa" versions, and assume I have a PPA enabled, so I might comb through the archive in a few weeks and rebuild anything with such versions.
[12:19] <seb128> fair enough
[12:19] <infinity> (That package isn't the only offender)
[12:19] <seb128> the package might have an upload before that
[12:19] <infinity> darkxst: Oh, and removed g-o-a for you.  Sorry about missing that in backscroll.
[12:19] <seb128> darkxst, btw can you merge your change back to the vcs? I didn't find a branch/mp matching so I didn't do it
[12:21] <infinity> darkxst: And your syslinux issue is known.  Supposed to be fixed in https://launchpad.net/ubuntu/+source/syslinux/3:6.03+dfsg-8ubuntu2
[12:21] <infinity> darkxst: Perhaps your daily was built before that hit the release pocket?
[12:22] <seb128> likely, iso built are buggy because of bluez
[12:22] <seb128> builds
[12:23] <seb128> which doesn't migrate for whatever reason (was autopkgtest and boottest but now it's something in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt unsure what, it's listed several times)
[12:23] <infinity> leading: bluez,gnome-bluetooth,gnome-user-share,bluedevil
[12:23] <infinity> start: 219+0: a-61:a-40:a-29:i-30:p-31:p-28
[12:23] <infinity> orig: 219+0: a-61:a-40:a-29:i-30:p-31:p-28
[12:23] <infinity> easy: 262+0: a-69:a-47:a-36:i-37:p-38:p-35
[12:23] <infinity>     * amd64: bluedevil, gnome, gnome-control-center, gnome-core, gnome-desktop-environment, gnome-phone-manager, ubuntu-gnome-desktop, ubuntu-mate-core
[12:24] <seb128> yeah, that doesn't speak to me
[12:24] <seb128> like half of those should be valid candidates and the other half not care
[12:26] <seb128> Laney helped
[12:27] <seb128> going to fix gnome-phone-manager
[12:28] <seb128> I've no clue about ubuntu-mate and what they have that depends for and what they want to use instead
[12:29] <darkxst> infinity, thanks
[12:29] <infinity>  gnome-control-center : Depends: libgnome-bluetooth11 (>= 3.4.0) but it is not going to be installed
[12:30] <infinity> seb128: That'd be the root of the problem for the -desktops too, I assume.
[12:30] <seb128> we don't use g-c-c
[12:30] <infinity> Who is "we"?
[12:30] <seb128> -desktop
[12:30] <infinity> unity doesn't, everyone else does.
[12:31] <seb128> k, I though you meant ubuntu-desktop
[12:31] <infinity> Well, that's probably what's breaking ubuntu-gnome-desktop.
[12:31] <infinity> ubuntu-mate-core is another mystery.
[12:31] <darkxst> seb128, sure I can push my changes to vcs in the morning, off for the night now
[12:31] <seb128> k, for some reason that copy didn't work or I missed it
[12:31] <seb128> darkxst, thanks, good night
[12:32] <darkxst> infinity, boot is failing way to early for g-c-c to be a problem
[12:33] <infinity> darkxst: Hrm?  Lots of boost bits are already migrated.
[12:33] <infinity> The autohinter isn't lying about the result here.
[12:34] <darkxst> infinity, it doesnt even get to the boot menu
[12:34] <infinity> Oh.  boot.  I thought you said boost. :P
[12:34] <infinity> darkxst: See above, where I pointed at the syslinux bug.
[12:34] <darkxst> infinity, looking now
[12:35] <infinity> darkxst: We're discussing bluez/g-c-c/etc because all of that it preventing you from getting new ISO builds.
[12:35] <jibel> darkxst, it's bug 1484571
[12:35] <infinity> darkxst: syslinux is fixed, but you get no new livefses until bluez is unbuggered.
[12:35] <jibel> darkxst, it should be fixed in next build
[12:36] <darkxst> right and bluez became a bit messy with stuff migrating before bluez itself
[12:37] <infinity> I'm amused by the claim that migrating bluedevil breaks bluedevil.
[12:44] <infinity> Does it make sense for bluedevil to depend on BOTH bluez-obexd and obex-data-server?
[12:44] <darkxst> gtg, if you see anything specific to ubuntu gnome ping me an I will look in the morning
[12:46] <darkxst> infinity, I think the latter dep is gone
[12:50] <infinity> darkxst: Gone from where?
[12:50] <infinity> It still exists in the archive.
[12:51] <infinity> But it seems the intent in other packages was to move from obex-data-server to bluez-obexd, but bluedevil is depending on both.
[12:57] <darkxst> infinity, yeh that, intent is its gone, depending on both makes noe sense
[12:58] <infinity> darkxst: Does bluez-obexd provide a completely compatible interface?  As in, one can just swap the dep and that's it?
[12:59]  * infinity would like to "fix" bluedevil, but is probably completely the wrong person to do so, if he has to ask these questions.
[13:00] <Mirv> I had a vague memory that the following snippet from update_output http://pastebin.ubuntu.com/12079096/ meant uninstallability of the listed packages, but I don't have problem installing those on wily-proposed (all have rebuilt against GCC5)
[13:01] <darkxst> infinity, i don't know the answer to that, and really have to go, so can
[13:01] <darkxst> can't check
[13:01] <infinity> Mirv: It means uninstallability *if* you also assume that promoting the candidate sources removes their NBS binaries.
[13:02] <infinity> Mirv: Guessing at least one of those renamed a library or something.
[13:02] <Mirv> hmm
[13:02]  * darkxst gone
[13:02] <Mirv> thanks inf
[13:08] <Mirv> that botan had the v5 library rename and those packages have all been rebuilt against it, so I don't see where the problem but lie.
[13:08] <Mirv> s/but/would/
[13:08] <Mirv> no other reverse deps
[13:08] <infinity> Mirv: The problem is that block of packages also wants muparser, which isn't in that autohint set.
[13:10] <Mirv> ahah!
[13:44] <seb128> k, so I handled gnome-phone-manager and gnome-bluetooth
[13:44] <seb128> seems like ubuntu-mare should stop pulling in bluez-alsa
[13:44] <seb128> mate
[13:44] <seb128> flexiondotorg, ^
[13:44] <Laney> didn't g-c-c need one too?
[13:44] <seb128> unsure then about bluedevil
[13:45] <seb128> Laney, sorry, gnome-bluetooth was a typo for g-c-c
[13:45] <Laney> haha
[13:45] <Laney> I see!
[13:46] <seb128> ;-)
[13:46] <Laney> what's the problem with bluedevil?
 Does it make sense for bluedevil to depend on BOTH bluez-obexd and obex-data-server?
[13:46] <seb128>  But it seems the intent in other packages was to move from obex-data-server to bluez-obexd, but bluedevil is depending on both.
[13:46] <Laney> oh right
[13:46] <Laney> well I don't see it in the problems for the migration
[13:47] <seb128> trying: bluedevil
[13:47] <seb128> skipped: bluedevil (58 <- 823)
[13:47] <seb128>     got: 62+0: a-62
[13:47] <seb128>     * amd64: bluedevil
[13:47] <seb128> unsure if that means it's a problem though
[13:48] <seb128> infinity mentioned it so he probably thinks it is?
[13:48] <Laney> there's a later hint involving bluez and bluedevil
[13:48] <seb128> Trying easy from autohinter: bluez/5.33-0ubuntu2 gnome-bluetooth/3.16.1-1ubuntu1~ppa1 gnome-user-share/3.0.4-0ubuntu2 bluedevil/4:5.1.95-0ubuntu1 has
[13:49] <seb128>     * amd64: bluedevil, gnome, gnome-control-center, gnome-core, gnome-desktop-environment, gnome-phone-manager, ubuntu-gnome-desktop, ubuntu-mate-core
[13:49] <seb128> so it's listed in there as wel
[13:49] <infinity> I'm honestly not sure why bluedevil is in that list, it's confusing me a bit.
[13:50] <Laney> Trying easy from autohinter: libbluedevil/4:5.2.2-0ubuntu3 bluedevil/4:5.1.95-0ubuntu1 bluez/5.33-0ubuntu2 gnome-bluetooth/3.16.1-1ubuntu1~ppa1 gnome-user-share/3.0.4-0ubuntu2
[13:50] <infinity> I just noticed the weird double dep when trying to understand it.
[13:50] <Laney> […]
[13:50] <Laney>     * amd64: gnome, gnome-control-center, gnome-core, gnome-desktop-environment, gnome-phone-manager, ubuntu-gnome-desktop, ubuntu-mate-core
[13:50] <infinity> Oh, we have another autohint that I missed?  Or was libbluedevil not there last time I looked?
[13:50] <infinity> That one looks much more sane.
[13:51] <infinity> Just g-c-c broken, and ubuntu-mate-core.
[13:51] <infinity> seb128: I can fix MATE for them.  I take it bluez-alsa is dead/
[13:51] <seb128> infinity, it is yes
[13:51] <seb128> infinity, thanks
[13:51] <Laney> I think it's just that after the ones seb128 also did
[13:51] <Laney> nice
[13:53] <infinity> seb128: Is there a replacement for bluez-alsa, or is it just rolled into bluez?
[13:53] <infinity> And does anything force it off with a Conflicts/Replaces?
[13:56] <seb128> infinity, afaik it's deprecated by bluez itself, nothing seems to C/R it though
[13:56] <seb128> cyphermox, ^ maybe you know more about that?
[13:57] <cyphermox> I don't think it's still needed, pulseaudio knows about bluez's dbus APIs
[13:57] <cyphermox> so if it's no longer shipped...
[13:57]  * infinity looks sideways at the MATE seeds not having the string "bluez" in them.
[13:57] <cyphermox> infinity: does it have blue
[13:57] <infinity> cyphermox: Right, so bluez should C/R -alsa to force it off cleanly on upgrades.
[13:58] <cyphermox> infinity: most likely, yes
[13:58] <cyphermox> let me check what bluez-alsa shipped before
[13:59] <cyphermox> yeah, they probably dropped this :/
[13:59] <cyphermox> http://git.kernel.org/cgit/bluetooth/bluez.git/commit/?id=4ff9b99292eca193dc0c149722328cb0b1ab0818
[14:01] <infinity> Yeahp, fair enough.
[14:01] <infinity> Just need to make the old package go away, since it clearly won't work with the new bluez, and don't want the cruft lying around.
[14:01] <cyphermox> seb128: should I do the change?
[14:02] <seb128> cyphermox, if you want, yes please, maybe check with morphis he was configuring a packaging vcs for bluez under ~bluetooth
[14:02] <cyphermox> mmkay
[14:03] <cyphermox> eep
[14:03] <cyphermox> yeah, it's there, but no history :/
[14:04] <seb128> did we have some before somewhere?
[14:08] <cyphermox> seb128: at the very least we have launchpad as a last resort
[14:08] <seb128> right
[14:08] <cyphermox> I see Iain has a branch up to some rev of 4.99
[14:09] <cyphermox> that's still not getting is very far though
[14:10] <Laney> looks like that was using the UDD branch
[14:10] <cyphermox> yeah
[14:11] <cyphermox> I was already thinking of importing the history for the NM branch into a git-dpm tree or something, perhaps we can do the same with bluez?
[14:15] <seb128> if you have a nice workflow feel free to do it/tell us how it works
[14:16] <seb128> I suggested the desktop way of debian/ dir only because that's what I know which works best for component non hosted on launchpad
[14:22] <infinity> Okay, that was confusing.  Found the bluez-alsa dep and wiped it out.
[14:22] <infinity> It was a recommends from desktop-common, but due to an entirely weird bug, those recommends become depends for ubuntu-mate-core (and only them), while they're recommends for everyone else.
[14:22] <infinity> Whee.
[14:23] <davmor2> cyphermox: did you manage to resolve the iso booting issue in the end?
[14:23] <cyphermox> davmor2: it was broken by related bluetooth issues too ^
[14:24] <cyphermox> I haven't checked this morning yet
[14:24] <infinity> cjwatson: germinate bug/misfeature, or is MATE doing something wrong?
[14:24] <cyphermox> isn't MATE doing something special to their seed anyway
[14:24] <infinity> cyphermox: no-follow-recommends, but it doesn't follow that that should translate all recommends into deps. ;)
[14:24] <cyphermox> no, it doesn't :)
[14:25] <cyphermox> :q
[14:25] <cyphermox> dah
[14:28] <infinity> Oh.
[14:28] <infinity> cjwatson: Nevermind, not a germinate bug, their metapackage is weird.
[14:28] <infinity> flexiondotorg: Dude.
[14:29] <infinity> flexiondotorg: You around?
[14:51]  * infinity decides he's waited long enough for flexiondotorg and fixes his meta without input.
[14:52] <cyphermox> what was it?
[14:52] <infinity> cyphermox: ${germinate:Recommends} was on the Depends line for ubuntu-mate-core. :P
[14:52] <cyphermox> woops ;)
[14:55] <infinity> seb128: ubuntu-mate-meta uploaded.
[16:37] <cyphermox> seb128: infinity: could you please get the boottest for bluez to be skipped?
[16:38] <seb128> cyphermox, I don't know the magic for that
[16:38] <seb128> unsure what group has the acl for it as well
[16:38] <seb128> Laney and pitti can is all I know
[16:43] <cyphermox> seb128: I could maybe have done it but only for touch things :P
[16:44] <cyphermox> huh, scratch that,  I guess it's probably more "only for RTM"
[17:23] <slangasek> looks like python-apt is clear, but there are other apt revdeps not rebuild yet.  anyone worked on those or should I give it a go?
[18:03] <slangasek> apt revdeps uploaded
[18:04] <robru> anybody around to sponsor an upload for me? infinity?
[18:17] <cyphermox> robru: I can, I haven't left yet
[18:20] <robru> cyphermox: ah barry got to me first, but thanks
[18:21] <cyphermox> ok
[18:22] <barry> robru: built for me at least on a wily amd64 chroot
[18:23] <barry> sponsoring
[18:23] <robru> barry: yeah it should be good, not an arch-specific failure, thanks
[18:27] <slangasek> oh fail; debian-xcontrol checks its own control file at build time and barfs on XSBC-Original-Maintainer
[18:38] <slangasek> libmusicbrainz5's transition tracker also didn't cover the bases; more rebuilds needed there, trying to upload now (but at the tail end of battery here)
[18:44] <doko> why is this still showing up http://people.canonical.com/~ubuntu-archive/transitions/html/libqalculate-g++5.html ? it's the only package
[18:47] <slangasek> doko: because of a bad matching rule; .depends ~/libqalculate5\b/ also matches Depends: libqalculate5-foo.  It's in the "finished" section anyway, so you can ignore it?
[18:47] <doko> ok
[18:50] <slangasek> barry, robru, infinity, cyphermox (or anyone who's around): top priority today should be getting the mega hint unstuck.  Laney has a branch at lp:~laney/ubuntu-archive-tools/update-output-helper with a tool of the same name that helps with analysis of the output.  I'm using it like this: http://paste.ubuntu.com/12081732/
[18:50] <cyphermox> ack
[18:51] <slangasek> the interface is a bit janky (and I haven't yet merged that into ubuntu-archive-tools because of that jankiness) but hopefully you can figure it out and make some headway
[18:51] <slangasek> I've sorted out apt and musicbrainz5, there were missing revdep rebuilds - those are now on the tracker and noted in the pad
[18:53] <slangasek> 5 minutes battery left here, so signing off.  Good luck :)
[18:55] <robru> cyphermox: I don't really know what to do
[18:56] <Laney> slangasek: I thought about making it a straight wrapper with some more smarts
[18:56] <Laney> but that would have taken extra time
[19:00] <Laney> can improve it later on
[19:01] <Laney> it's looking smaller!
[19:01] <cyphermox> Laney: it's not missing much to be useful in this particular case
[19:01] <cyphermox> first I picked was tangled in apt too
[19:01] <Laney> can't parse that, sorry
[19:01] <Laney> do you mean it's not useful or it is? :)
[19:01] <cyphermox> robru: so, you get laney's branch. then run update-output-helper -u... as per the paste from slangasek
[19:02] <cyphermox> Laney: I say it's useful
[19:02] <barry> pitti: if you're around (or anybody else who has shell on autopkgtest.u.c) could you please retry ipython i386?
[19:02] <cyphermox> Laney: and I say it's not missing much to wrap the rest of what slangasek was doing
[19:02] <Laney> cool
[19:03] <Laney> I just copy and paste the huge list
[19:03] <Laney> and if you pull it does update for you :P
[19:03] <cyphermox> robru: you just need to take the huge list beside: Trying easy from autohinter, and copy-paste it when you run update-output-helper again (without -u)
[19:03] <cyphermox> yep
[19:04] <cyphermox> robru: and to finish that apt-get install call (with the obvious different dirs so you don't mess up your install), you pick some random package under amd64: or something, those without a /version_number, and try to install it, see where it hangs
[19:04] <Laney> don't forget --dry-run
[19:04]  * Laney puts that in
[19:05] <Laney> done
[19:06] <cyphermox> why?
[19:06] <cyphermox> ah, now I pick something and it's installable
[19:06] <Laney> so that it doesn't try to do anything
[19:06] <robru> cyphermox: is this meant to be done in a wily chroot?
[19:06] <Laney> nah
[19:07] <cyphermox> I thought so but passing dirs to apt makes it unnecessary
[19:08] <Laney> it's at least offering to install something here
[19:08] <Laney> don't know what would happen if I say yes :)
[19:09]  * cyphermox takes src:player
[19:09] <cyphermox> Laney: it tries to download the files from your aptroot, and fails.
[19:10] <Laney> can you try a rebuild of visp and see if it gets libogre-1.9.0v5?
[19:10] <robru> Laney: cyphermox: http://paste.ubuntu.com/12081879/ yeah I have no idea what I'm doing
[19:10] <Laney> looks like that might be why its test fails
[19:10]  * Laney is on Frankfurt train station wifi
[19:11]  * cyphermox is at home waiting for his lift to the airport
[19:11]  * cyphermox takes geos and player...
[19:11] <cyphermox> robru: no get update
[19:12] <robru> cyphermox: the paste said to update :-P
[19:12] <cyphermox> you also don't need to run the extra update with apt-get -o blah, because it gets run when you run update-output update
[19:12] <cyphermox> s/ update$/-helper/
[19:12] <cyphermox> you're just not picking the packages from the right list for the call to install
[19:13] <cyphermox> under the huge list of hints, you have besides ' * amd64:' a list of uninstallable packages, pick from that :)
[19:15] <robru> cyphermox: ok now what? http://paste.ubuntu.com/12081911/
[19:15]  * Laney plays the "will it build before the train arrives or my 30 minutes of wifi runs out?" game
[19:16] <cyphermox> robru: right, so this means that something is still depending on libgeos-c1 instead of libgeos-c1v5, what I was looking at right now
[19:17] <cyphermox> so you'd check if what you picked (libqgis) has built properly, and if you got the newest in proposed
[19:18] <Laney> often stuff is rebuilt but blocked at the excuses stage
[19:18] <doko> Laney, it's "wily it build ..."
[19:18] <Laney> the train is delayed by zwanzig minuten
[19:19] <Laney> but I have 6 minutes of wifi left
[19:19] <Laney> someone just try a visp rebuild already :)
[19:19] <doko> somebody should give back libkcddb and cantata when musicbraiz is built
[19:19] <doko> anway, afk now
[19:24] <Laney> 10 seconds
[19:24]  * Laney fail
[19:24] <Laney> ttyl :P
[20:10] <cyphermox> robru: back in a bit on my way to the airport
[20:16] <robru> cyphermox: OK I'm on lunch for a bit & running some errands, we should sync up a bit later
[21:19] <stokachu> infinity: ^
[22:09] <cyphermox> robru: well, I had to get to the airport, I'm there now having dinner since my flight still isn't for a few hours
[22:10] <robru> cyphermox: cool. Can you run me through this update output helper thing? I don't really know how to fix the problems found with it
[22:11] <cyphermox> sure
[22:11] <cyphermox> where you at now?
[22:11] <robru> cyphermox: same place we left off
[22:11] <cyphermox> ahah ok
[22:12] <cyphermox> I was just hacking at the script, I don't really like how it brings out things that may already have been rebuilt in proposed
[22:12] <cyphermox> so, you run the update and all, up to trying to install a package, which will say why it fails to install
[22:13] <cyphermox> something like http://people.ubuntu.com/~mathieu-tl/output
[22:13] <cyphermox> (but way shorter)
[22:15] <cyphermox> say you try pcl-tools
[22:15] <cyphermox> you'll get a complaint about libvtk5.8  and one about libvtk5.8-qt4,
[22:16] <cyphermox> what this means is that it's likely that pcl-tools needs to be rebuilt to pick these up, but you still need to verify
[22:18] <robru> cyphermox: ok let me try pcl-tools and see what happens
[22:19] <robru> cyphermox: ok so I see the thing about libvtk5.8{,-qt4}, what is it that I need to "verify" and how do I fix this?
[22:21] <cyphermox> ok so I found that in some cases say, pcl would already be in proposed but not being listed by update-output-helper, so I check on lp for what's there, and look in the build logs to check that it picked up the new build-deps, in this case libvtk5.8v5 and libvtk5.8-qt4v5
[22:21] <cyphermox> in this particular example, looks like pcl doesn't build
[22:23] <robru> cyphermox: so it looks like mterry was working on this recently but his FTBFS fix failed? https://launchpad.net/ubuntu/+source/pcl/1.7.2-8ubuntu1
[22:23] <cyphermox> yup
[22:24] <robru> cyphermox: oh well that one is just more BOOST_JOIN failures though
[22:24] <cyphermox> i wouldn't know
[22:24] <robru> cyphermox: I guess I don't understand what this helper tool is telling me that I can't already see on the update_excuses page
[22:25] <robru> cyphermox: I'm familiar with the BOOST_JOIN thing, I've done a few patches for that already
[22:26] <cyphermox> essentially it allows you to walk through the list so you can fix things  that unblock many things
[22:26] <cyphermox> if you want to look at pcl, I'll finish my burger, pass security, then I'll be 100% able to help :)
[22:26] <robru> cyphermox: heh, ok
[23:10]  * cyphermox is on slowww wireless tubes
[23:14] <robru> cyphermox: lol, so mterry uploaded a new fix while I was fumbling with that
[23:15] <cyphermox> ok
[23:16] <cyphermox> well, good I guess, aside from the duplication of work
[23:18] <cyphermox> robru: look at marsshooter, if you want something new
[23:18] <robru> cyphermox: yeah figured he was EOD since he's not in the channel
[23:18] <robru> also it's after 6 in his timezone
[23:19] <cyphermox> looks like it should be a straight rebuild for the new libsfml; but it's 70Mb source and I'm in an airport
[23:19] <cyphermox> otoh I guess I could bring it up on a server
[23:19] <robru> cyphermox: so you want me to pull-lp-source and poke at it? what should I check?
[23:19] <robru> cyphermox: better if you teach me I think
[23:19] <cyphermox> well, see if it's uninstallable first, it should tell you about libsfml
[23:21] <cyphermox> libsmfl has been renamed with the usual XYZv5; so doing a no-change rebuild of marsshooter should pick up these new names and just work
[23:21] <cyphermox> (but it's worth running it through sbuild first just in case)
[23:21] <robru> cyphermox: ok will do
[23:29] <robru> cyphermox: yeah, local build success, you wanna upload a nochange?
[23:30] <cyphermox> sure
[23:30] <robru> cool