=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== s1aden is now known as sladen
=== mitya57_ is now known as mitya57
[10:28] <geser> Laney: could you please review/comment on the patch from Debian bug #665064? it fixes the kaya FTBFS (a Haskell package)
[10:28] <ubottu> Debian bug 665064 in src:kaya "kaya: FTBFS: dpkg-buildpackage: error: dpkg-source -b kaya-0.4.4 gave error exit status 2" [Serious,Open] http://bugs.debian.org/665064
[10:33] <Laney> geser: looks sane to me
[10:33] <Laney> I could upload that NMU
[10:33] <Laney> but then again Vincent is a DD himself
[10:33] <Laney> I'll ping him
[10:34] <geser> whatever works to get the FTBFS resolved
=== Kiall is now known as Guest35492
[12:16] <semvoz> good evening :)
=== swoody is now known as Guest13539
[13:25] <geser> anyone familiar with how Python dependencies got computed has an idea why python-jenkinsapi gets a dependency on a non-existant package and how to fix it?
[13:44] <debfx> geser: it's parsed from requires.txt
[13:47] <geser> debfx: why is it correct then in Debian? see http://packages.debian.org/sid/python-jenkinsapi
[13:47] <geser> test building -5 in quantal ends in: Depends: python-lxml, python-bs4, python-pkg-resources, python2.7, python (>= 2.7.1-0ubuntu2), python (<< 2.8), python-beautifulsoup4
[13:48] <geser> resulting in "python-jenkinsapi : Depends: python-beautifulsoup4 but it is not installable"
[13:51] <debfx> hm, good question
[13:56] <debfx> geser: in Debian /usr/share/python/dist_fallback has an entry for beautifulsoup4
[13:58] <debfx> looks like it hasn't been regenerated in Ubuntu for a while
[13:59] <debfx> ScottK: ^
[14:01] <debfx> a quick fix would be to just pass --no-guessing-deps to dh_python2 since the package manually specifies the Depends anyway
[14:20] <siretart> jtaylor: please file a bug. I'm currently travelling for another week, so I'll get to that as soon as I return
[14:22] <jtaylor> siretart: so its a bug?
[14:22] <jtaylor> it looks intentional
[14:22] <jtaylor> * Have both libavcodec and libavcodec-extra package conflict with each other.
[14:24] <siretart> jtaylor: I need to take a closer look
[14:24] <siretart> jtaylor: actually, I do not want it to have coinstallable, but I there was some previous discussion about this that I need to review
[14:24] <siretart> anyway, gotta run
[14:29] <cjwatson> jtaylor: my understanding is that libavcodec53 and libavcodec-extra53 are not meant to be coinstallable, but that (following my most recent upload) libavcodec-dev and libavcodec-extra53-dev should be
[14:29] <cjwatson> jtaylor: The earlier dependency you quoted was an or-dep, so it's not a problem in itself that its two elements conflict
[14:30] <cjwatson> sorry, I meant "libavcodec-dev and libavcodec-extra-53 should be" above
[14:32] <jtaylor> k I am asking because of the yorick-av ftbs, it depends on both, though extra-53 is only needed for a test that is easily disabled
=== Quintasan_ is now known as Quintasan
[15:15] <cjwatson> jtaylor: the problem with yorick-av is that libavutil-dev and libavcodec-extra-53 aren't coinstallable
[15:15] <cjwatson> the output in the build log is a bit misleading
[15:16] <cjwatson> sounds like it might make sense to disable that one test for the time being and file a bug ...
=== maxb_ is now known as maxb
[16:05] <c_korn> hello, can't I build a quantal chroot on my lucid server? there is no script for quantal in /usr/share/debootstrap/scripts/
[16:07] <jtaylor> c_korn: just copy one of the others to that name
[16:07] <jtaylor> there all the same
[16:07] <micahg> c_korn: you probably need debootstrap from -backports
[16:07] <micahg> oh, hrm, it wasn't pushed back that far
[16:08] <micahg> c_korn: if you want to test the reverse dependencies in lucid, I'd be happy to push a backport there, but as jtaylor said, it's just adding a new symlink I think
[16:08] <c_korn> no quantal script in lucid-backports either: http://packages.ubuntu.com/lucid-backports/all/debootstrap/filelist
[16:17] <c_korn> the symlink did its job. thanks to you.
[17:06] <ScottK> debfx: Remind me on Tuesday or convince barry to fix it.
[17:48] <siretart> jdstrand: what kind of functionality does yorick-av require from libavcodec-extra-53?
[17:49] <micahg> siretart: do you meant jtaylor?
[17:51] <siretart> micahg: of course. sorry jdstrand
[17:51] <siretart> jtaylor: what kind of functionality does yorick-av require from libavcodec-extra-53?
[17:52] <siretart> thanks micahg
[17:56] <jtaylor> siretart: just testing of h264
[17:57] <siretart> jtaylor: libavcodec53 decodes h264 just fine. so why do you ned -extra-53?
[17:57] <jtaylor> good question, someone else added the dependency so that the test succeeded
[17:58] <siretart> jtaylor: have you tried removing that dependency? i.e., is it *really* necessary?
[17:58] <siretart> I suspect cargo culting going on here
[17:58] <jtaylor> I'm guessing then it will fail again
[17:58] <jtaylor> didn't try it
[17:58] <jtaylor> will do soon
[18:03] <siretart> jtaylor: k. let me know
[18:20] <jtaylor> siretart: yes the test fails with codec not found
[18:21] <micahg> sounds like a yorick-av bug
[18:22] <jtaylor> really?
[18:22] <jtaylor> I recall encoding issues with x264 if extra was not installed
[18:22] <jtaylor> the description of avcodec does not mention h264
[18:22] <jtaylor> only extra
[18:23] <micahg> oh, right :)
[18:23] <micahg> it's an Ubuntu diff from Debian
[18:23] <micahg> x264 is in universe
[18:28] <micahg> it'll be nice when the main/universe distinction goes away
[18:29] <jtaylor> is that planned?
[18:29] <micahg> yes, just not sure when, last UDS we talked about trying for 13.04
[18:30] <c_korn> hello, trying to build with my new quantal chroot there is this error: http://pastebin.com/raw.php?i=NDSG4dde this is my config: http://pastebin.com/raw.php?i=Au4PqvUg the precise chroot is building fine. please help.
[18:31] <micahg> c_korn: what group is listed in the precise config?
[18:32]  * micahg has groups=sbuild,root,admin in his quantal config
[18:33] <c_korn> micahg: the precise config is also in the paste. the warning about the admin group also appears in the precise build. maybe this is not the cause.
[18:34] <micahg> c_korn: ah, right, the mount error is the issue
[18:35] <c_korn> yeah, the error also appears with "groups=sbuild,root,admin"
[18:35] <siretart> jtaylor: what does the failing test actually do?
[18:35] <tumbleweed> I'd worry slightly more about the Es than the Ws
[18:36] <jtaylor> don't know
[18:36] <jtaylor> but how should it work if the codec is not available
[18:36] <jtaylor> probably it does encoding
[18:36] <siretart> jtaylor: please check. the only thing that I could image that would explain this failure is that the test tries to *encode* something to h264 with libx264
[18:37] <siretart> jtaylor: which seems a terribly strange thing to do in a test
[18:37] <jtaylor> we can just disable the test, thats not the issue
[18:37] <jtaylor> the issue is only, are the two packages supposed to be coinstallable or not
[18:38] <jtaylor> if not, disable the test and be done
[18:38] <siretart> jtaylor: libavcodec-extra-53 and libavcodec53 both provide an libavcodec shared object. the difference is that -extra links against libx264
[18:39] <siretart> jtaylor: so these two cannot be installed together
[18:39] <jtaylor> then extra should provide an own -dev package
[18:39] <siretart> why? there is no difference in terms of headers
[18:39] <siretart> that would make two -dev packages with exactly the same content
[18:39] <jtaylor> how do you then pull libavcodec-extra and the headers?
[18:40] <jtaylor> you can't because they rre not coinstallable
[18:40] <siretart> that seems pretty pointless to me, and you still have not really convinced me to change this opinion
[18:40] <micahg> umm, libavcodec-dev has the proper alternate dependencies
[18:41] <siretart> see
[18:41] <jtaylor> alternate dependencies are not used by buildd
[18:41] <siretart> so?
[18:41] <micahg> they are in Ubuntu
[18:41] <siretart> I realyl do not want any packages to build against the -extra variant as a saftey net
[18:41] <jtaylor> also it doesn't work for me
[18:41] <jtaylor> if I install the -dev it removes extra
[18:41] <siretart> and that some strange broken test case might want to encode to h264 does not sound really convincing to me
[18:42] <micahg> jtaylor: if you use --resolve-alternatives, it should work
[18:42] <jtaylor> urg I didn't even know that exists ..
[18:42]  * micahg isn't sure LP's old sbuild will resolve it properly though
[18:42] <jtaylor> is that an apt-get flag?
[18:42] <micahg> jtaylor: in Debian, it's policy to not use alternates, in Ubuntu we allow it
[18:42] <micahg> jtaylor: sbuild
[18:42] <siretart> no, at sbuild flag, which is not used on the buildds
[18:42] <siretart> s/at/it is an/
[18:43] <siretart> so forget about it
[18:43] <jtaylor> to me this looks wrong
[18:43] <jtaylor> I can't install both on my system
[18:43] <siretart> encoding to h264 on the buildds sounds really wrong to me
[18:44] <jtaylor> forget about the test
[18:44] <jtaylor> and forget about buildd
[18:44] <jtaylor> apt-get install libavcodec-dev libavcodec-extra-53
[18:44] <jtaylor> doesn't work
[18:44] <micahg> jtaylor: you can't have libavcodec53, libavcodec-extra-53, and libavcodec-dev, but you should be able to do that
[18:45] <jtaylor> I haven't
[18:45] <siretart> that's something that i'd be willing to investigate. I think that used to work at some point, but as indicated, I'm not entirely convinced that this was a good idea to allow in the first place
[18:45] <jtaylor> though its probably avutil as cjwatson mentioned
[18:45] <micahg> ah, there's a conflict with libavutil-dev
[18:46] <micahg> we probably have some mismatches that didn't get updated properly since most of the extra packages were removed in Debian
[18:46] <siretart> can't we just promote x264, xvid and lame to main and get rid of this libav-extra split, please?
[18:47] <siretart> that would make my life so much easier, and greatly minimize the diff to debian
[18:47] <micahg> siretart: if there are MIRs and they're not an extra security burden, it would probably be ok
[18:47] <micahg> but this late in the release cycle it probably won't happen, try for it right when R opens
[18:47] <siretart> micahg: well, in fact i've tried that before, and it seems that x264 uses gpac, which is a bit hairy for an mir.
[18:48] <micahg> siretart: hopefully the main/universe split will go away at least for build deps in 13.04 and the problem will be solved as well
[18:48] <siretart> micahg: that would be really really great and solve exactly this problem
[18:48] <siretart> micahg: is there a spec about this that I could subscribe to?
[18:49] <tumbleweed> there was discussion about it at the last UDS, so yes
[18:49] <micahg> https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-finish-archive-reorg
[18:50] <siretart> micahg: excellent, thanks and subscribed
[18:51] <micahg> siretart: are you coming to UDS?
[18:51] <siretart> micahg: i'd love, but i won't have time this cycle because I'm finishing my phd thesis. maybe next time, dependending where I end up finding a job
[18:52] <micahg> ok
[19:50]  * micahg hopes to start helping more in Debian starting in R