[00:06] <Corey> No worries, thanks for your help.
[00:18] <Corey> http://pastebin.com/fua09b5C is my lintian output so far.  Whee, progress.
[03:16] <ScottK> tumbleweed: On these DMB replacement announcements it'd be nice to know if the incumbent is running for re-election.
=== santiago-ve is now known as foursixnine
=== almaisan-away is now known as al-maisan
[07:45] <dholbach> good morning
[07:53] <geser> ScottK: no, I'm not (for re-election)
[07:54] <geser> ajmitch: Hi, are you still available for getting nominated for DMB?
[09:23] <iulian> Morning dholbach.
[09:23] <dholbach> hey iulian
[09:26] <iulian> geser: I reckon he is, otherwise we'd be very disappointed. :)
[09:26] <iulian> Go go ajmitch!
[09:27] <nigelb> heh
[09:27]  * nigelb cheers for ajmitch as well!
=== kklimonda_ is now known as kklimonda
[10:46] <ajmitch> geser: yeah I may as well :P
[11:09] <Laney> gogo ajmitch
[11:10] <Laney> what's this "*still* available"? …
[11:12] <geser> ajmitch mentioned in the past that he would be available for election, and I hoped he didn't changed his mind
[11:12] <Laney> I'm sure I trolled him about this before :P
[11:24] <ajmitch> Laney: yeah but you troll about everything
[11:25] <Laney> you love it
[11:25] <Laney> it's Our Thing
[13:46] <ScottK> geser: Thanks.
[13:47] <astraljava> Hiya masters! Heard REVU is still down. Can someone look at it, or has someone already?
=== al-maisan is now known as almaisan-away
[14:07] <scott-work> is REVU supposed to still be up and used?
[14:08] <Laney> probably, but it is down
=== Laney changed the topic of #ubuntu-motu to: REVU is down | Precise: open for business | Want to get involved with the MOTU? https://wiki.ubuntu.com/MOTU/Contributing | Sponsor queue: http://bit.ly/fz6AyQ | http://qa.ubuntuwire.com/ftbfs | http://people.canonical.com/~ubuntu-archive/NBS | http://qa.ubuntuwire.com/bugs/rcbugs/
[14:09] <scott-work> Laney: is there any recourse if i wanted to get a kernel (per an approved blueprint) into the archives?
[14:10] <Laney> are you working with the kernel team?
[14:10] <Laney> they use git afaik
[14:10] <Laney> otherwise you could use mentors.debian.net or make a bzr branch
[14:11] <scott-work> Laney: per the blueprint we were supposed to submit to REVU and have two MOTU approve it (themuso being one of them)
[14:11] <scott-work> my understanding is that since this would be a community maintained kernel, the kernel team would not have direct purview over it
[14:11] <Laney> I don't know what it is, but they might be interested in working with you anyway
[14:12] <Laney> anyway one of the other places I mentioned should be fine
[14:13] <scott-work> thanks for you help, Laney  :)
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
[15:23] <koolhead17> hello all
[15:30] <koolhead17> Is it common practise to  package a software in n-number available language separately?
[15:30] <koolhead17> how is patch applied to all of them in that case?
=== 20QAAK923 is now known as jbicha
[17:21] <l3on> udienz, about bug 913513 ... well, debian has added:
[17:21] <ubottu> Launchpad bug 913513 in libomxil-bellagio (Ubuntu) "Please merge libomxil-bellagio 0.9.3-1 (universe) from Debian testing" [Undecided,Incomplete] https://launchpad.net/bugs/913513
[17:21] <l3on> CFLAGS="${CFLAGS} -Wall -Werror -Wno-error=unused-but-set-variable -Wno-error=unused-but-set-parameter"
[17:22] <l3on> as a workaround of problem
[17:22] <l3on> we should delete that and insert the patch you mentioned ?
[17:23] <micahg> if the patch properly fixes the issues, you might want to ask the Debian maintainer why it wasn't applied (this might be documented in a bug already)
[17:24] <l3on> cjwatson, around ? you're the author of the patch :)
[17:24] <l3on> have you forwarded that to debian ?
[17:26] <udienz> l3on: i think we can use cjwatson patch, you can take liberty to forwarding to Debian
[17:27] <udienz> don't forget to CC cjwatson in bug reports
[17:27] <l3on> udienz, ok, I'm going to prepare the new debdiff
[17:28] <micahg> l3on: you can reference debian 625367 in your bug
[17:28] <ubottu> Debian bug 625367 in libomxil-bellagio "libomxil-bellagio: ftbfs with gcc-4.6 -Werror" [Serious,Fixed] http://bugs.debian.org/625367
[17:28] <l3on> thank you micahg
[17:29] <udienz> you can reopen it http://www.debian.org/Bugs/server-control
[17:30] <micahg> yes, but it's technically fixed, so best to open a new bug
[17:31] <cjwatson> l3on: I don't remember, sorry.  But you really shouldn't need to ask me about every instance where you find a build-fixing patch of mine in a package; if it's a build fix, use your judgement to determine whether it's still needed
[17:32] <cjwatson> and if it is and I forgot to forward it then feel free to just go ahead and forward it
[19:52] <Corey> Hmm.  I've been playing around with my pbuilder sid chroot, and I'm getting http://pastebin.com/sHc8p54f.  What've I broken now? :-)
[19:55] <Corey> Put another way, I've got compiled python modules (cython) that are arch specific; do they belong in dist-packages?
[19:58] <jtaylor> yes
[19:58] <jtaylor> but not in usr/local
[20:01] <Corey> jtaylor: Ah, so I want to stash it in /usr/lib/python2.6/dist-packages instead.  I presume there's a way to inform setup.py of this fact? :_)
[20:02] <jtaylor> dh_auto_build usually does it correctly
[20:02] <jtaylor> if not it probably did not find your setu.py
[20:02] <Corey> jtaylor: You'd think: https://github.com/KB1JWQ/salt/blob/master/debian/rules
[20:03] <Corey> setup.py is in the top level dir.
[20:03] <jtaylor> well thats wrong
[20:03] <jtaylor> drop the overrides
[20:03] <jtaylor> for _build and _install
[20:03] <Corey> jtaylor: Without them setup.py never gets called.
[20:04] <jtaylor> hm is there a makefile too?
[20:04] <Corey> No.
[20:04] <jtaylor> try this: dh $@ --buildsystem=python_distutils
[20:04] <Corey> jtaylor: That github fork is "life"
[20:05] <Corey> Live, even.
[20:05] <Corey> jtaylor: Huh, build completed successfully.
[20:06] <Corey> jtaylor: But I'm still not seeing the build having compiled the stuff that setup.py build compiles.
[20:06] <Corey> And nothing's getting stashed anywhere but in /usr/share
[20:11] <jtaylor> whats the setup.py line shown when you build with DH_VERBOSE=1
[20:15] <Corey> jtaylor: Throw DH_VERBOSE=1 into rules?
[20:16] <jtaylor> export in front
[20:19] <Corey> jtaylor: The install is 	python setup.py install --force --root=/tmp/buildd/salt-0.9.5/debian/tmp --no-compile -O0 --install-layout=deb
[20:19] <jtaylor> do you copy the stuff from debian/tmp in an install file?`
[20:19] <Corey> jtaylor: Nope.
[20:20] <Corey> That... would probably explain it, wouldn't it...
[20:20] <jtaylor> than thats the reason the result is empty
[20:20] <Corey> This package will work with python 2.6 or 2.7; how do I reflect that in the .install file?
[20:20] <jtaylor> if you build depend on python-all-dev
[20:20] <jtaylor> usr/lib/python2*
[20:23] <Corey> jtaylor: And I only want to include the compiled stuff?
[20:23] <jtaylor> then make that more specific
[20:24] <Corey> I'm asking, the rest is just copied in.
[20:24] <Corey> So that stuff is already being copied in from the source itself to /usr/share, I don't need to redo that I figure.
[20:25] <Corey> But for the msgpack stuff, I'd want to have the install line look like: debian/tmp/usr/lib/python2.7/dist-packages/salt/msgpack /usr/share/python2*/dist-packages/salt/msgpack ?
[20:25] <jtaylor> some stuff is handled by default, e.g. copyright
[20:25] <jtaylor> everything else you have to do explicitly
[20:26] <jtaylor> usr/lib/python2*/dist-packages/salt/msgpack is enough
[20:26] <jtaylor> for compat >= 7
[20:26] <Corey> jtaylor: Right, but I've explicitly had it done from the topdir-- it's static python files.
[20:26] <Corey> jtaylor: Ah, and that'll know where to find it?
[20:27] <Corey> See, what I've been doing is this: in the tarball, there's a salt directory, so I have lines like salt/utils /usr/share/salt/
[20:28] <jtaylor> compat >= 7 will fall back to debian/tmp if not found
[20:29] <jtaylor> sry you do need a destination too
[20:29] <jtaylor> hm no, if the path in debian/tmp isok you can skip it
[20:29] <Corey> Yeah, it seems to have worked.
[20:29] <Corey> Ooh.
[20:30] <Corey> I threw the python-dev-all into the control file, now it looks like I'm building the socket a few times.  I have a /usr/lib/pyshared/python2.7/salt/msgpack/_msgpack.so and a ./usr/lib/pyshared/python2.6/salt/msgpack/_msgpack.so as well.
[20:30] <jtaylor> you can use wildcards
[20:30] <Corey> I just want to verify that installing the package isn't going to deb both versions of python. :-)
[20:30] <Corey> dep*
[21:51] <Corey> I'm seeing a few python-script-but-no-python-dep errors, my control file looks like https://github.com/KB1JWQ/salt/blob/master/debian/control; what did I blow up in my deps?
[21:51] <Corey> ^ crossposted from #debian-packaging on OFTC, in case it looks familiar.
[22:02] <Corey> Ahhh!
[22:02] <Corey> Found it.  Stupid nagging bug.
[22:03] <Corey> TO fix it, I have to have my packaging process patch the original source code; how do I do that properly?
[22:03] <Corey> I mean worst case I can have a DH_build that does it with sed, but that's inelegant.
[22:14] <jcfp> Corey: use a patch system, like quilt or dpatch.
[22:15] <jcfp> also, python-support is deprecated these days, see http://lists.debian.org/debian-python/2011/06/msg00136.html for info.
[22:16] <micahg> dpatch is deprecated these days as well :)
[22:16] <jtaylor> but you need to use it if you want to support lucid
[22:17] <jcfp> oh damn :)
[22:31] <Corey> Yeah, Lucid is required.
[22:31] <Corey> Will DHPython2 work with Lucid?
[22:34] <jcfp> doesn't look like it's available there
[22:34] <Corey> Okay, then as nice as it would be to use the latest shiny, that's not an option for me.
[22:34] <jcfp> just dodn expect you to be targeting lucid, since you were using a sid chroot
[22:35] <Corey> jcfp: I'm trying to target everything reasonable in production.
[22:35] <Corey> This'll be submitted to Ubuntu, Debian, it'll go into an autobuilder for nightlies, etc.
[22:38] <maxb> jtaylor: why do you say that you need to use dpatch to support lucid? why not use quilt?
[22:38] <jtaylor> maxb: I never said that
[22:38] <jtaylor> oh, you could interpret it that way
[22:39] <jtaylor> I responded to dh_python2
[22:39] <jtaylor> 3.0 is fine in lucid
[22:39] <maxb> oh right, you were talking about python-support
[23:34] <Corey> Okay, https://github.com/KB1JWQ/salt/blob/master/debian/control still throws a number of python-script-but-no-python-dep, even after I stripped out the version qualifier for Python.  How do I sanely fix this?