[00:19] <andreserl>  howdy!! Library packages are not supposed to have Depends on ${python:Depends}, or are they
[00:49] <ScottK> andreserl: Depends on the library.
[00:49] <ScottK> If it's written in Python, maybe.
[00:50] <RAOF> From my memory of the python policy, the answer is “no”.  I'd check policy to get a definitive answer, though.
[00:51] <ScottK> If it's using a python helper like pysupport, pycentral, or dh_python2 it probably needs it, otherwise no and you have to figure it out yourself.
[01:47] <andreserl> ScottK, ok the package install some python stuff but not in the libraries. So we end up having lintian complaning about empty empty folders
[01:47] <ScottK> Is the python stuff Python modules or extensions and do you use pysupport, pycentral, or dh_python2?
[01:50] <andreserl> ScottK, I believe they are modules installed in the pacemaker binary packages. But the libraries (after new package split) only ship the *.so's
[01:50] <andreserl> s/pacemaker binary packages/pacemaker binary package
[01:51] <ScottK> If they are modules then you should use one of the helpers and have ${python:Depends}
[01:51] <ScottK> Obviously you only need that for the binary with the actual modules
[01:53] <andreserl> ScottK, so that means I can drop the ${python:Depends} for all the library binary packages that only install libraries (*.so) right?
[01:54] <andreserl> and of course the  libXX-dev too
[01:54] <ScottK> as long as none of the .so are Python C extensions, yes.
[01:55] <andreserl> ScottK, how can I determine if they are Python C extensions?
[01:55] <ScottK> They would install in a python specific directory.
[01:56] <ScottK> If they are just in /usr/lib, they aren't.
[01:56] <andreserl> ScottK, ok then :) I guess they are not since they all install in /us/lib
[01:56] <ScottK> Probably
[01:56] <andreserl> ScottK, thanks for the help :)
[01:56] <ScottK> You're welcome
[06:28] <dholbach> GOOD MORNING!
[06:32] <Rhonda> Don't shout like that at this ungodly hour!
[14:37] <ari-tczew> zul: are you going to merge 3 packages in universe where you are Touched In Last?
[14:38] <zul> ari-tczew: if you want them go ahead
[14:39] <ari-tczew> ok
[14:40] <ari-tczew> zul: ATM I'm not interested, but someone else can be. I'm marking them as 'feel free to take'
[14:40] <zul> ari-tczew: k
[16:06] <xteejx> subvertpy FTBFS, but builds ok locally, any chance we can give it back?
[16:15] <Alexqw> Where should I go or who should I poke to get an update on bug 553415?  It's fixed in Maverick but still affects Lucid.  There's a PPA with the fix for xorg-server 1.7.6 for lucid, but there was some talk about backporting all of xorg-server 1.7.7.  Comment 53 in the bug says Timo might be willing to sponsor this fix, but there's been no update on this for awhile.  Can anyone shed some light on this?
[16:24] <ScottK> Alexqw: I'd ask in #ubuntu-x.
[16:26] <Alexqw> ScottK: Ok, will do.  Thanks
[16:26] <ScottK> xteejx: I gave back i386.  If that works I'll give back the rest too (subvertpy)
[16:27] <xteejx> ScottK: Great, thank you Scott :)
[16:30] <Laney> ScottK: You told me to remind you to sign my key, so here is me doing so
[16:30] <ScottK> Laney: OK.  Thanks.
[16:31] <Laney> ty
[16:31] <apachelogger> ^^
[16:32]  * sebner pets apachelogger 
[16:32] <ScottK> xteejx: It worked, so I gave back the others too.
[16:32]  * apachelogger hides from sebner and goes looking for the mobile guy
[16:32] <xteejx> :)
[16:33] <xteejx> thank you
[16:33] <apachelogger> rbelem: btw, I think this world is ready for a tool to profile startkde, watching process and stuff
[16:34]  * sebner groans and slaps apachelogger with joy
[16:35] <apachelogger> oh my
[16:35]  * ScottK hands apachelogger #kubuntu-devel.
[16:35] <apachelogger> oh
[16:35]  * apachelogger hides in #kubuntu-devel
[16:36]  * Laney welcomes all KDE refugees to #ubuntu-motu
[16:39] <xteejx> refugees? lol
[16:40]  * ScottK suspects window confusion due to excessive multitasking.
[16:41] <apachelogger> multiwindow-multiscreen-multitasking ftw!
[16:41] <apachelogger> also my UDS notes say that I need to do more rambling in here, not sure why though
[16:42]  * xteejx sets /rantmode = ON
[16:49] <ScottK> apachelogger: As long as you do what your notes say, the rationale isn't so important.
[17:46] <RoAkSoAx> is it possible to see which were the latest packages stored in a pbuild cache?
[17:47] <geser> ctime of the files?
[17:48] <RoAkSoAx> geser: well I just updated my pbuilder. And it upgraded some packages and I want to know which are those packages. Because after the pbuilder upadte the packages I'm trying to build, FTBFS
[17:49] <xteejx> bug 671029 how would I what is suggested with pbuilder-dist ?
[17:50] <RoAkSoAx> geser: /win 3
[17:50] <RoAkSoAx> grrr
[17:50] <RoAkSoAx> sorry :)
[17:56] <rbelem> apachelogger, i just from lunch time :-)
[17:58] <rbelem> apachelogger, which tool?
[17:59] <apachelogger> one you will write :P
[18:03] <ari-tczew> xteejx: what's the problem?
[18:06] <ari-tczew> xteejx: Bhavani (coolbhavi on IRC) suggested you to check building on Debian. you must use pbuilder-dist sid.
[18:17] <ari-tczew> siretart: reading bug 449729 I'm wondering, if isn't it a rebuild request for lucid/maverick?
[18:40] <cjwatson> ari-tczew: that's a mistitled bug
[18:40] <cjwatson> oh, wait
[18:41] <cjwatson> sorry, I was reading the util-linux half.  ignore me.  I see no reason it would be worth rebuilding that for lucid/maverick though - it's cosmetic
[19:14] <xteejx> ari-tczew: Just saw the message, I'm unable to use pbuilder-dist sid create
[19:14] <xteejx> because of bug 671067 which I just found
[19:15] <ari-tczew> xteejx: do you have debian-archive-keyring installed?
[19:16] <xteejx> I do now ;)
[19:16] <xteejx> Still doesn't work
[19:16] <ari-tczew> xteejx: show me error via paste ubuntu com
[19:17] <xteejx> http://paste.ubuntu.com/525880/
[19:18] <ari-tczew> xteejx: sudo pbuilder-dist sid create --debootstrapopts --keyring=/usr/share/keyrings/debian-archive-keyring.gpg
[19:19] <xteejx> ari-tczew: It's doing something now, rettieving packages
[19:23] <xteejx> ari-tczew: Is it sid/unstable that I should be checking the build with?
[19:29] <persia> xteejx, ari-tczew: if 671067 is as easy to work around as that, consider just adding a patch to pbuilder-dist
[19:29] <xteejx> persia: I woulnd't know how to persia
[19:29] <xteejx> i.e. to code it in
[19:30] <persia> xteejx, Ought just be an extra argument passed to pbuilder (pbuilder-dist is just a wrapper).  I don't like to fiddle it, because I'm not a user, and inevitably break something, but it ought be easy.
[19:31] <xteejx> persia: Hmm, I'll have a look but I'm by no means promising anything since I don't have much experience
[19:31] <persia> That's precisely the answer I hoped for :)
[19:33] <xteejx> persia: You should know me by now lol I at least try to fix things even if I "know" I can't :)
[19:34] <ari-tczew> xteejx: yes
[19:34] <xteejx> ari-tczew: yes?
[19:34] <ari-tczew> xteejx: [20:23] <xteejx> ari-tczew: Is it sid/unstable that I should be checking the build with?
[19:34] <ari-tczew> ...
[19:35] <xteejx> ari-tczew: Oh right :) Thank uoi
[19:35] <xteejx> *you
[19:35] <ari-tczew> xteejx: what's going process?
[19:35] <xteejx> ari-tczew: huh?
[19:35] <ari-tczew> xteejx: did the command which I gave you finish?
[19:36] <xteejx> ari-tczew: It did, yes. It worked perfectly fine, created a sid chroot
[19:36] <ari-tczew> persia: xteejx showed me error, which I have been affected a few days ago.
[19:36] <ari-tczew> xteejx: did you update pbuilder?
[19:37] <ari-tczew> sudo pbuilder-dist sid update
[19:37] <xteejx> ari-tczew: My sid one? There's no need, I only just created it
[19:37] <ari-tczew> xteejx: do you want build anything in sid?
[19:38] <xteejx> I don't think so... update worked ok anyway, just done it :)
[19:39] <ari-tczew> xteejx: I was wondering that coolbhavi sent suggestion to you about test build a one package on Debian
[19:40] <xteejx> ari-tczew: Ohhhh, yes, the debian .dsc builds fine in sid
[19:40] <xteejx> So I didn't forward anything, since its our bug
[19:40] <ari-tczew> ok
[19:47]  * achiang wonders if he should subscribe ubuntu-sponsors to https://bugs.launchpad.net/bugs/671126
[19:48] <xteejx> persia: I've looked at the wrapper for pbuilder-dist, and it seems that it should already invoke the debian archive keyring http://paste.ubuntu.com/525911/
[19:48] <micahg> achiang: you should target natty instead of maverick, but after that, yes
[19:49] <achiang> micahg: ok, thx
[19:49] <persia> achiang, That's probably better fixed in qemu-bootstrap (since we've hit it in a few other cases).  I'd recommend fiddling with qemu-kvm to do that, instead.
[19:50] <persia> (qemu-debootstrap is the result of the consolidation of ~7 scripts, and would hugely benefit from someone going over it and making a proper tool)
[19:50] <achiang> persia: i thought you might say that. :-/
[19:50] <achiang> persia: you are right though; there is the quick n' dirty fix and the proper fix. fixing qemu-debootstrap is the proper thing to do
[19:51] <persia> But I'm not sure I understand why 671067 *exists* if --keyring is defined already in pbuilder
[19:51] <achiang> although arguably the patch i propose above isn't exactly dirty. i think it is a valid change
[19:51] <persia> Oh, that patch is fine, *but* we'll keep seeing that class of bug until we fix the issue.
[19:51] <persia> I don't much like workarounds :)
[19:51] <xteejx> persia: Me neither, looking at the script it *should* just work if debian-archive-keyring is installed, but doesn't
[19:52] <persia> Oh, my misreading.  It includes ubuntu-archive-keyring, and we need debian-archive-keyring.
[19:53] <xteejx> persia: No, the script does add the debootstrapopts for the keyring, but it doesn't work, also debian-archive-keyring should really be installed automatically
[19:53] <persia> Indeed.
[19:53] <xteejx> I'm looking at it anyway, fingers crossed my brain actually sees seomthing lol
[20:01] <ari-tczew> who knows, how can I fix this FTBFS: dh_makeshlibs: dpkg-gensymbols -plibapiextractor0.8 -Idebian/libapiextractor0.8.symbols -Pdebian/libapiextractor0.8 returned exit code 1
[20:01] <xteejx> shouldn't the -ldebian/blahblah be a capital L ?
[20:02] <ari-tczew> dunno
[20:02] <xteejx> don't worry ignore me thats probably wrong
[20:02] <persia> ari-tczew, That usually indicates that there was some ABI skew: you need to check the exposed symbols to ensure it's safe, and regenerate .symbols to reflect that.
[20:02] <persia> Much of the time that sort of problem means there needs to be a discussion about SONAME.
[20:02] <ari-tczew> oh my gosh
[20:03] <persia> https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols
[20:03] <xteejx> persia: I don't think I can do the pbuilder-dist thing, I've tried 3-4 combinations of things I thought *might* work and it hasn't :(
[20:04] <xteejx> I think I'll leave it or maybe look tomorrow daytime with a fresh head lol
[20:04] <persia> xteejx, Thanks for trying.
[20:04] <xteejx> persia: My pleasure :)
[20:05] <persia> stefanlsd, By the way, when are you putting that in the packaging guide ? :)
[21:07] <Amaranth> arg, all of these ATI Stream powered video encoders I find insist on upscaling my videos
[21:07] <ari-tczew> tumbleweed: ping
[22:22] <ari-tczew> when Ubuntu has been switched to gcc 4.5?
[22:23] <micahg> ari-tczew: for Natty
[22:27] <ari-tczew> hmmm. we should cooperate with upstreams, as Debian not always want include our changes to fix FTBFS, if their packages built fine
[22:29] <persia> It's an awkward time for Debian just now, because of the release freeze, meaning that lots of changes can't happen.
[22:29] <persia> But Debian will likely end up needing many of the patches later: the trick is to work closely with Debian to be aware of when they need the patches.
[22:29] <persia> (especially as lots of things don't need to be all the way upstream, when they are just in packaging)
[22:30] <siretart> ari-tczew: possibly, but the rebuild is necessary for natty as well, AFAIUI
[22:31] <kklimonda_> bugs are already being filled in the debian bts against packages that ftbfs with the new toolchain so forwarding patches isn't bad anyway - some of them are just going to rot in their bts longer than others.
[22:32] <ari-tczew> siretart: so, what's the decision? rebuild for lucid and maverick also?
[22:32] <ari-tczew> or not?
[22:32] <persia> It probably doesn't meet SRU criteria, as it works, just not as efficiently as it could.
[22:33] <siretart> exactly. you can try to start an SRU, but since this is just a warning, I don't think it's worth the efford
[22:34] <ari-tczew> cjwatson wrote, that it's not enough for SRU
[22:34] <ari-tczew> hmm. this bug doesn't affect me. I don't need it. I just wanted help Ubuntu users.
[22:35] <persia> Fix it for natty, and mark it wontfix for the others.
[22:35] <ari-tczew> persia: there are not open tasks.
[22:35] <ari-tczew> natty is fixed. siretart has uploaded (sponsored) a merge.
[22:36] <siretart> and that uploaded closed the bug in question via changelog
[22:37] <ari-tczew> ok, leave SRUs then.
[22:39] <persia> ari-tczew, Rather, mark them wontfix with a comment explaining that they don't meet SRU requirements, so users aren't surprised.
[22:40]  * ari-tczew is lazy.