=== missing is now known as lubko [10:54] I wonder why http://packages.qa.debian.org/e/efl.html is not in Ubuntu. I didn't find it listed in the sync blacklist. [11:02] hjd, https://launchpad.net/ubuntu/utopic/+source/efl ... seems it didnt build on all arches === mitz is now known as mitz_offline === mitz_offline is now known as mitz === mitz is now known as mitz_offline === mitz_offline is now known as mitz [13:36] hjd: should be heading into the archive nowish; it wasn't synced earlier IIRC because it overwrote some Ubuntu-modified binaries elsewhere and so required manual attention [13:39] Hmm, can somebody explain me why xserver-xorg-video-openchrome-lts-saucy precise upload (which I just sponsored) is in NEW? [13:47] LP's ancestry calculation is buggy for things introduced post-release [13:48] Makes little practical difference though whether it's in NEW or UNAPPROVED [13:52] Thanks cjwatson. [13:54] ogra_`: cjwatson: Ok, I see. === Ursinha is now known as Ursinha-afk [16:46] how does one get a package to go from "proposed" to accepted in the next release? [16:52] andrewrk: https://wiki.ubuntu.com/ProposedMigration is probably what you're looking for [16:52] andrewrk: What package? [16:52] cjohnston, I'm looking at https://launchpad.net/ubuntu/utopic/+source/libgroove but I realized that the answer is probably because it is waiting for libav10.1 [16:54] andrewrk: Yes, that's right, it's in that very large cluster [16:54] is anything blocking libav10, by the way? [16:54] Yes, a ton of stuff [16:55] If nothing were blocking it it would go in automatically [16:55] http://people.canonical.com/~ubuntu-archive/transitions/libav10.html [16:56] why does this look so different than https://release.debian.org/transitions/html/libav10.html ? === timrc is now known as timrc-afk [16:57] andrewrk: Various reasons; in some cases we may just need no-change rebuilds; in some cases we have Ubuntu deltas that need merging; in some cases the package fails to build in Ubuntu and doesn't in Debian for some reason unrelated to libav; in some cases we may have fixed something in Ubuntu and forwarded the change to Debian but it hasn't been applied there yet [16:57] All the usual things [16:58] ah interesting === Ursinha-afk is now known as Ursinha [17:30] it seems like there's nothing else to do on that transition, and we're pretty much waiting on package maintainers to upload new versions [17:31] Those are contradictory :-) [17:31] There's plenty left to do on that transition, exactly involving uploading fixes ... [17:33] but I think all the fixes have been coded [17:34] e.g. no mysteries left, just waiting for some chores [17:34] That's not at all obvious [17:35] I may very well be misunderstanding the situation. Here's one thing I'm looking at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739079 at the bottom it says the debian transition is at 100% and all that is left is to remove old libraries from testing [17:35] Debian bug 739079 in release.debian.org "transition: libav10" [Normal,Open] [17:35] I just fixed renpy, for example, which was not a matter of uploading a new upstream version [17:35] ah [17:35] You're misunderstanding the situation [17:35] Debian and Ubuntu aren't the same [17:35] And it doesn't always follow that if Debian has ported everything that that means Ubuntu only has chores left to do [17:36] Anyway, it's more productive for me to fix things than to argue about semantics, I guess :) [17:36] yes, apologies [17:37] really, I'm just excited that progress is being made, thanks for your contributions to the effort. [17:37] vtk isn't obvious either, hmm [17:37] Possibly a link order issue, but unfortunately cmake is not very verbose here [17:38] make VERBOSE=1 ? [17:38] Yeah, just not in the packaging [17:38] ah [17:38] I'll poke it locally [17:39] libav is often a case where Ubuntu requires more work than Debian because for historical reasons we have a chunk of extra multimedia-related packages which haven't tended to be excellently maintained [17:39] I see - Debian is removing things and Ubuntu continues to support them? [17:39] Debian never had them in the first place [17:39] ah [17:39] We imported a load of stuff from debian-multimedia.org back in the day [17:40] I thought it was a bad idea at the time but lost the argument :) [17:43] I'll probably end up demoting some things to utopic-proposed (equivalent of removing from testing) that aren't fixed in Debian and are hard to fix, but I'd prefer to wait until everything else that can reasonably be done has been done [17:45] I'm wondering if libav10 is likely to make it into utopic [17:45] Yes [17:45] Practically certain, we'll get it sorted [17:45] Glad to hear that :) [17:45] It would be far too painful for us to abort now [17:45] And there's plenty of time [17:46] Well. DebianImportFreeze is August 7, which is my cutoff date for getting the package I'd like to see in Utopic into Debian Unstable [17:47] Sure, but (a) that's still plenty of time (b) that's not a cut-off date for finishing migrations from utopic-proposed to utopic [17:47] understood [17:47] All that means is that I turn off the auto-sync cron job on that date [17:47] * andrewrk nods [17:50] Riddell: Could you please merge opencv, or would you like me to do it? [17:51] Riddell: (for libav) [17:56] anyone in Budapest today? === timrc-afk is now known as timrc === timrc is now known as timrc-afk [19:14] can someone help with FTBFS? "dh_doxygen: Doxygen documentation not found" [19:15] however, only i386 builds fine, the rest archs are FTBFS [19:18] Suggests that something's in Build-Depends-Indep when it should be in Build-Depends [19:21] cjwatson: there are no B-D-Indep :( [19:28] if dh_doxygen is like dh_sphinxdoc you must not call it during binary-arch [21:34] cjwatson: I'll take a look [21:45] jtaylor: dropping it from d/rules fixes FTBFS, thanks! [21:50] ari-tczew: Does dropping it from b-d mean the documentation doesn't get rebuild now? [22:10] Riddell: ta [22:40] ScottK: it has not been dropped from b-d, merely from d/rules [22:40] OK. The question stands. [22:41] There's an "override_dh_sphinxdoc-arch:" (no rule content) idiom that's used in some dh_sphinxdoc packages [22:43] That would probably be better. [22:43] if its even the issue [22:43] I was just guessing, that sphinxdoc does not work in indep is probably just a bug [22:54] Erm, that was fixed. [22:55] Oh, sphinxdoc was fixed, dh_doxygen has the same bug? [23:13] siretart: Hm, shouldn't libavfilter-dev depend on the right -dev packages to match the Requires.private entry in its .pc file? [23:13] siretart: Seems odd that something that requires libavfilter apparently has to independently b-d on libavresample-dev ... [23:22] infinity: Could you merge xbmc for libav 10 support? (Or let me know and I can do it) [23:23] cjwatson: Meh, my TIL was just a rebuild, go nuts. :P [23:23] infinity: OK, will do, thanks [23:24] Those weird "nexus7" patches sound a lot more like "armhf" patches.