[00:14] 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] wgrant: ^-- Hey, core-dev, release your own software. [00:15] infinity: adt image downloading thing is still downloading images [00:15] slow internet is slow [00:16] I didn't realise it was actually blocking things. [00:16] Ahh, so you're already on it? Awesome. [00:17] 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] gee, a whole lot of my uploads that I don't care about sure are making it into wily [00:24] 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] heh [00:25] these are the p-m ones [00:25] for libraries I never heard of before Monday [00:25] 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] infinity: you may be a packaging hypochondriac [00:26] slangasek: I'm... Not sure what that means. [01:41] anyone looked at marble yet? [01:43] ok, looks like a symbol symbols ftbfs [03:17] 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] 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] infinity: changelog says it was bumped for a new interface [03:33] ("Files2") [03:35] slangasek: Which changelog...? [03:36] infinity: python-apt [03:36] infinity: oops no, that says 1.0.9.4 [03:36] 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] sorry [03:37] infinity: however I just tried to downgrade the build-dep here and build, and it fails with pep8 test failures [03:37] Well, that would be entirely unrelated, and due to the new pep8. ;) [03:37] But I can look at that too. [03:37] yeah [03:37] it does mean the C built successfully anyway [03:39] 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] slangasek: Perhaps needs an i386 kernel to reproduce? [03:48] Heh, happy to see jak is on the same "screw E402" page with python-apt that I was with unattended-upgrades. [03:53] heh, I added --ignore=E402 as well -- it's outright impossible to do that for some projects [03:54] if you have to set sys.path before "import" [03:55] slangasek: oh nice, http://autopkgtest.ubuntu.com/packages/k/kservice/wily/i386/ succeeds again [03:56] pytables also had a weird crash which now seems fixed [03:56] so whatever changed, good :) [03:56] oh nice, flaky tests ;) [03:59] slangasek: nice, marble passed again too, thanks! [03:59] 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] pitti: yeah, that one required an actual fix, but done now [03:59] slangasek: right, hence the "thanks" :) [04:01] libsfml had a package name change but there was no transition tracker for it; triggering rebuilds for that now [04:04] I uploaded the kicad fix now, so that it's easier to retry once apw uploads the fixed boost [04:26] 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] 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] debuild -S -nc FTW :) [04:36] pitti: Yeah, that's how I always upload apt. [04:36] pitti: Well, that's how I always upload most things, but apt pretty much requires it. [04:38] 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] skipped: khtml (6 <- 864) [04:42] got: 63+0: a-63 [04:42] * amd64: libkf5kdelibs4support-dev, libkf5khtml-dev [04:43] so if I read that right, britney claims that khtml breaks libkf5kdelibs4support-dev ? [04:43] cause "chdist apt-get wily-armhf install libkf5khtml-dev libkf5kdelibs4support-dev" works fine [04:45] or is that part of the big "too much for britney's little brain"? [04:45] pitti: Try that with foo- on the end for the packages that were removed from khtml. [04:45] oh, because NBS? [04:46] I'm assuming that packages were removed anyway... [04:46] nope, no NBS [04:46] at least not from khtml [04:46] * infinity looks at output.txt [04:46] same for kdelibs4support [04:48] ah, "install libkf5khtml-dev kubuntu-desktop" fails, maybe that'll lead to something [04:50] Considering libqca2:armhf -1 as a solution to libqca2v5:armhf 15 [04:50] Added libqca2:armhf to the remove list [04:50] Fixing libqca2v5:armhf via keep of libqca2:armhf [04:50] 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] this tracker looks wrong -- several packages like kadu built successfully days ago [04:55] pitti: kadu only built on 2/6 arches. [04:55] 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] I checked the build log, no stray hardcoded "libqca2" deps [04:56] Weird. [04:56] 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] I'll just adjust that and check in the next run, and until then go through the logs [04:59] hm, http://people.canonical.com/~ubuntu-archive/transitions/html/html/snappy-g++5.html used the same syntax and was happy [05:01] ooh, I know! [05:01] Depends: libqca2-plugins [05:01] that matches libqca2\b [05:03] Hahah. Oops. [05:03] pushed [05:07] ok, missing rebuilds uploaded, there are a couple of FTBFS [05:28] * pitti sobs at qmake [06:13] 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] Mirv: you mean from wily? it's not in -proposed [06:16] pitti: yes, of course, I was just thinking about proposed migration [06:17] Mirv: you mean the qtcreator package itself ships these modules? [06:17] I see it has Conflicts: to them, but not Replaces:/Provides: [06:18] 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] thus most likely apt will rather hold back the new qtcreator than removing these plugins [06:18] pitti: they are in a new path in the new QtC [06:18] hmm, it upgraded fine in my wily-proposed chroot [06:18] well, I wouldn't bet on it with just Conflicts: [06:19] so yes, fine to remove these from wily, but adding R/P: is still necessary IMHO [06:20] ok [06:20] doing a new upload of qtcreator [06:20] 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] 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] Mirv: right, but I mean it should C/R/P: those packages too then [06:23] pitti: right, ok [06:24] so I'm now adding C/R/P for all the old binary packages [06:25] Mirv: thanks [06:25] Mirv: http://paste.ubuntu.com/12077489/ [06:25] thanks! [06:42] pitti: No need for "provides" if nothing depends on them, only C/R to force them off. [06:42] (Not that all 3 hurts much either) [07:24] infinity, hi, can you remove gnome-online-accounts 3.16 from wily-proposed [08:12] 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] argh, hardcoded lib dep [08:14] * pitti uploads kdeconnect, take III === pete-woods1 is now known as pete-woods [11:12] hmm current ubuntu-gnome wily daily images, don't want to boot ;( syslinux seems to be hanging === MerryChristmas is now known as benonsotfware === benonsotfware is now known as benonsoftware [12:15] darkxst: Was that gnome-bluetooth upload in -proposed a mistake? It's got a ~ppa version. [12:16] infinity, I think seb copied it from the ppa [12:16] https://launchpad.net/~ubuntu-desktop/+archive/ubuntu/transitions [12:16] Oh, hrm, seems to be a few ~ppa versions in wily. Ick. [12:17] I certainly didnt upload them to the archive [12:18] I was unsure if I should change them just to avoid the number of just copy [12:18] so I decided to just copy [12:18] it's only a version number, doesn't matter much [12:18] seb128: It's not the end of the world. As you say, only a version number. [12:18] 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] fair enough [12:19] (That package isn't the only offender) [12:19] the package might have an upload before that [12:19] darkxst: Oh, and removed g-o-a for you. Sorry about missing that in backscroll. [12:19] 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] 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] darkxst: Perhaps your daily was built before that hit the release pocket? [12:22] likely, iso built are buggy because of bluez [12:22] builds [12:23] 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] leading: bluez,gnome-bluetooth,gnome-user-share,bluedevil [12:23] start: 219+0: a-61:a-40:a-29:i-30:p-31:p-28 [12:23] orig: 219+0: a-61:a-40:a-29:i-30:p-31:p-28 [12:23] easy: 262+0: a-69:a-47:a-36:i-37:p-38:p-35 [12:23] * amd64: bluedevil, gnome, gnome-control-center, gnome-core, gnome-desktop-environment, gnome-phone-manager, ubuntu-gnome-desktop, ubuntu-mate-core [12:24] yeah, that doesn't speak to me [12:24] like half of those should be valid candidates and the other half not care [12:26] Laney helped [12:27] going to fix gnome-phone-manager [12:28] I've no clue about ubuntu-mate and what they have that depends for and what they want to use instead [12:29] infinity, thanks [12:29] gnome-control-center : Depends: libgnome-bluetooth11 (>= 3.4.0) but it is not going to be installed [12:30] seb128: That'd be the root of the problem for the -desktops too, I assume. [12:30] we don't use g-c-c [12:30] Who is "we"? [12:30] -desktop [12:30] unity doesn't, everyone else does. [12:31] k, I though you meant ubuntu-desktop [12:31] Well, that's probably what's breaking ubuntu-gnome-desktop. [12:31] ubuntu-mate-core is another mystery. [12:31] seb128, sure I can push my changes to vcs in the morning, off for the night now [12:31] k, for some reason that copy didn't work or I missed it [12:31] darkxst, thanks, good night [12:32] infinity, boot is failing way to early for g-c-c to be a problem [12:33] darkxst: Hrm? Lots of boost bits are already migrated. [12:33] The autohinter isn't lying about the result here. [12:34] infinity, it doesnt even get to the boot menu [12:34] Oh. boot. I thought you said boost. :P [12:34] darkxst: See above, where I pointed at the syslinux bug. [12:34] infinity, looking now [12:35] darkxst: We're discussing bluez/g-c-c/etc because all of that it preventing you from getting new ISO builds. [12:35] darkxst, it's bug 1484571 [12:35] bug 1484571 in syslinux (Ubuntu) "Latest wily image is not booting" [Critical,Fix released] https://launchpad.net/bugs/1484571 [12:35] darkxst: syslinux is fixed, but you get no new livefses until bluez is unbuggered. [12:35] darkxst, it should be fixed in next build [12:36] right and bluez became a bit messy with stuff migrating before bluez itself [12:37] I'm amused by the claim that migrating bluedevil breaks bluedevil. [12:44] Does it make sense for bluedevil to depend on BOTH bluez-obexd and obex-data-server? [12:44] gtg, if you see anything specific to ubuntu gnome ping me an I will look in the morning [12:46] infinity, I think the latter dep is gone [12:50] darkxst: Gone from where? [12:50] It still exists in the archive. [12:51] 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] infinity, yeh that, intent is its gone, depending on both makes noe sense [12:58] 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] 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] infinity, i don't know the answer to that, and really have to go, so can [13:01] can't check [13:01] Mirv: It means uninstallability *if* you also assume that promoting the candidate sources removes their NBS binaries. [13:02] Mirv: Guessing at least one of those renamed a library or something. [13:02] hmm [13:02] * darkxst gone [13:02] thanks inf [13:08] 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] s/but/would/ [13:08] no other reverse deps [13:08] Mirv: The problem is that block of packages also wants muparser, which isn't in that autohint set. [13:10] ahah! [13:44] k, so I handled gnome-phone-manager and gnome-bluetooth [13:44] seems like ubuntu-mare should stop pulling in bluez-alsa [13:44] mate [13:44] flexiondotorg, ^ [13:44] didn't g-c-c need one too? [13:44] unsure then about bluedevil [13:45] Laney, sorry, gnome-bluetooth was a typo for g-c-c [13:45] haha [13:45] I see! [13:46] ;-) [13:46] what's the problem with bluedevil? [13:46] Does it make sense for bluedevil to depend on BOTH bluez-obexd and obex-data-server? [13:46] 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] oh right [13:46] well I don't see it in the problems for the migration [13:47] trying: bluedevil [13:47] skipped: bluedevil (58 <- 823) [13:47] got: 62+0: a-62 [13:47] * amd64: bluedevil [13:47] unsure if that means it's a problem though [13:48] infinity mentioned it so he probably thinks it is? [13:48] there's a later hint involving bluez and bluedevil [13:48] 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] * amd64: bluedevil, gnome, gnome-control-center, gnome-core, gnome-desktop-environment, gnome-phone-manager, ubuntu-gnome-desktop, ubuntu-mate-core [13:49] so it's listed in there as wel [13:49] I'm honestly not sure why bluedevil is in that list, it's confusing me a bit. [13:50] 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] I just noticed the weird double dep when trying to understand it. [13:50] […] [13:50] * amd64: gnome, gnome-control-center, gnome-core, gnome-desktop-environment, gnome-phone-manager, ubuntu-gnome-desktop, ubuntu-mate-core [13:50] Oh, we have another autohint that I missed? Or was libbluedevil not there last time I looked? [13:50] That one looks much more sane. [13:51] Just g-c-c broken, and ubuntu-mate-core. [13:51] seb128: I can fix MATE for them. I take it bluez-alsa is dead/ [13:51] infinity, it is yes [13:51] infinity, thanks [13:51] I think it's just that after the ones seb128 also did [13:51] nice [13:53] seb128: Is there a replacement for bluez-alsa, or is it just rolled into bluez? [13:53] And does anything force it off with a Conflicts/Replaces? [13:56] infinity, afaik it's deprecated by bluez itself, nothing seems to C/R it though [13:56] cyphermox, ^ maybe you know more about that? [13:57] I don't think it's still needed, pulseaudio knows about bluez's dbus APIs [13:57] 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] infinity: does it have blue [13:57] cyphermox: Right, so bluez should C/R -alsa to force it off cleanly on upgrades. [13:58] infinity: most likely, yes [13:58] let me check what bluez-alsa shipped before [13:59] yeah, they probably dropped this :/ [13:59] http://git.kernel.org/cgit/bluetooth/bluez.git/commit/?id=4ff9b99292eca193dc0c149722328cb0b1ab0818 [14:01] Yeahp, fair enough. [14:01] 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] seb128: should I do the change? [14:02] cyphermox, if you want, yes please, maybe check with morphis he was configuring a packaging vcs for bluez under ~bluetooth [14:02] mmkay [14:03] eep [14:03] yeah, it's there, but no history :/ [14:04] did we have some before somewhere? [14:08] seb128: at the very least we have launchpad as a last resort [14:08] right [14:08] I see Iain has a branch up to some rev of 4.99 [14:09] that's still not getting is very far though [14:10] looks like that was using the UDD branch [14:10] yeah [14:11] 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] if you have a nice workflow feel free to do it/tell us how it works [14:16] 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] Okay, that was confusing. Found the bluez-alsa dep and wiped it out. [14:22] 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] Whee. [14:23] cyphermox: did you manage to resolve the iso booting issue in the end? [14:23] davmor2: it was broken by related bluetooth issues too ^ [14:24] I haven't checked this morning yet [14:24] cjwatson: germinate bug/misfeature, or is MATE doing something wrong? [14:24] isn't MATE doing something special to their seed anyway [14:24] cyphermox: no-follow-recommends, but it doesn't follow that that should translate all recommends into deps. ;) [14:24] no, it doesn't :) [14:25] :q [14:25] dah [14:28] Oh. [14:28] cjwatson: Nevermind, not a germinate bug, their metapackage is weird. [14:28] flexiondotorg: Dude. [14:29] flexiondotorg: You around? [14:51] * infinity decides he's waited long enough for flexiondotorg and fixes his meta without input. [14:52] what was it? [14:52] cyphermox: ${germinate:Recommends} was on the Depends line for ubuntu-mate-core. :P [14:52] woops ;) [14:55] seb128: ubuntu-mate-meta uploaded. [16:37] seb128: infinity: could you please get the boottest for bluez to be skipped? [16:38] cyphermox, I don't know the magic for that [16:38] unsure what group has the acl for it as well [16:38] Laney and pitti can is all I know [16:43] seb128: I could maybe have done it but only for touch things :P [16:44] huh, scratch that, I guess it's probably more "only for RTM" [17:23] 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] apt revdeps uploaded [18:04] anybody around to sponsor an upload for me? infinity? [18:17] robru: I can, I haven't left yet [18:20] cyphermox: ah barry got to me first, but thanks [18:21] ok [18:22] robru: built for me at least on a wily amd64 chroot [18:23] sponsoring [18:23] barry: yeah it should be good, not an arch-specific failure, thanks [18:27] oh fail; debian-xcontrol checks its own control file at build time and barfs on XSBC-Original-Maintainer [18:38] 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] 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] 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] ok [18:50] 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] ack [18:51] 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] 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] 5 minutes battery left here, so signing off. Good luck :) [18:55] cyphermox: I don't really know what to do [18:56] slangasek: I thought about making it a straight wrapper with some more smarts [18:56] but that would have taken extra time [19:00] can improve it later on [19:01] it's looking smaller! [19:01] Laney: it's not missing much to be useful in this particular case [19:01] first I picked was tangled in apt too [19:01] can't parse that, sorry [19:01] do you mean it's not useful or it is? :) [19:01] robru: so, you get laney's branch. then run update-output-helper -u... as per the paste from slangasek [19:02] Laney: I say it's useful [19:02] pitti: if you're around (or anybody else who has shell on autopkgtest.u.c) could you please retry ipython i386? [19:02] Laney: and I say it's not missing much to wrap the rest of what slangasek was doing [19:02] cool [19:03] I just copy and paste the huge list [19:03] and if you pull it does update for you :P [19:03] 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] yep [19:04] 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] don't forget --dry-run [19:04] * Laney puts that in [19:05] done [19:06] why? [19:06] ah, now I pick something and it's installable [19:06] so that it doesn't try to do anything [19:06] cyphermox: is this meant to be done in a wily chroot? [19:06] nah [19:07] I thought so but passing dirs to apt makes it unnecessary [19:08] it's at least offering to install something here [19:08] don't know what would happen if I say yes :) [19:09] * cyphermox takes src:player [19:09] Laney: it tries to download the files from your aptroot, and fails. [19:10] can you try a rebuild of visp and see if it gets libogre-1.9.0v5? [19:10] Laney: cyphermox: http://paste.ubuntu.com/12081879/ yeah I have no idea what I'm doing [19:10] 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] robru: no get update [19:12] cyphermox: the paste said to update :-P [19:12] 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] s/ update$/-helper/ [19:12] you're just not picking the packages from the right list for the call to install [19:13] under the huge list of hints, you have besides ' * amd64:' a list of uninstallable packages, pick from that :) [19:15] 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] 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] so you'd check if what you picked (libqgis) has built properly, and if you got the newest in proposed [19:18] often stuff is rebuilt but blocked at the excuses stage [19:18] Laney, it's "wily it build ..." [19:18] the train is delayed by zwanzig minuten [19:19] but I have 6 minutes of wifi left [19:19] someone just try a visp rebuild already :) [19:19] somebody should give back libkcddb and cantata when musicbraiz is built [19:19] anway, afk now [19:24] 10 seconds [19:24] * Laney fail [19:24] ttyl :P [20:10] robru: back in a bit on my way to the airport [20:16] cyphermox: OK I'm on lunch for a bit & running some errands, we should sync up a bit later [21:19] infinity: ^ [22:09] 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] 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] sure [22:11] where you at now? [22:11] cyphermox: same place we left off [22:11] ahah ok [22:12] 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] so, you run the update and all, up to trying to install a package, which will say why it fails to install [22:13] something like http://people.ubuntu.com/~mathieu-tl/output [22:13] (but way shorter) [22:15] say you try pcl-tools [22:15] you'll get a complaint about libvtk5.8 and one about libvtk5.8-qt4, [22:16] 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] cyphermox: ok let me try pcl-tools and see what happens [22:19] 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] 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] in this particular example, looks like pcl doesn't build [22:23] 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] yup [22:24] cyphermox: oh well that one is just more BOOST_JOIN failures though [22:24] i wouldn't know [22:24] 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] cyphermox: I'm familiar with the BOOST_JOIN thing, I've done a few patches for that already [22:26] essentially it allows you to walk through the list so you can fix things that unblock many things [22:26] if you want to look at pcl, I'll finish my burger, pass security, then I'll be 100% able to help :) [22:26] cyphermox: heh, ok [23:10] * cyphermox is on slowww wireless tubes [23:14] cyphermox: lol, so mterry uploaded a new fix while I was fumbling with that [23:15] ok [23:16] well, good I guess, aside from the duplication of work [23:18] robru: look at marsshooter, if you want something new [23:18] cyphermox: yeah figured he was EOD since he's not in the channel [23:18] also it's after 6 in his timezone [23:19] 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] otoh I guess I could bring it up on a server [23:19] cyphermox: so you want me to pull-lp-source and poke at it? what should I check? [23:19] cyphermox: better if you teach me I think [23:19] well, see if it's uninstallable first, it should tell you about libsfml [23:21] 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] (but it's worth running it through sbuild first just in case) [23:21] cyphermox: ok will do [23:29] cyphermox: yeah, local build success, you wanna upload a nochange? [23:30] sure [23:30] cool