[12:13] <geser> ScottK: http://launchpadlibrarian.net/8296887/py2.5.diff
[12:14] <ScottK> geser: Does that still work with 2.4 too?
[12:15] <geser> yes
[12:15] <ScottK> Cool.
[12:16] <geser> for both python2.4 and python2.5 the test file succeeds
[12:16] <ScottK> OK.
[12:17] <geser> I tested it on AMD64 so I assume it should also work on 32bit
[12:17] <geser> ScottK: should I also add the patch to Debian bug #423314?
[12:17] <ubotu> Debian bug 423314 in python-tclink "[Fwd: Re: python-tclink 3.4 fails with python2.5] " [Important,Open]  http://bugs.debian.org/423314
[12:18] <ScottK> OK.  I'll test it on i386 before I commit it.
[12:18] <ScottK> geser: Up to you.  
[12:19] <ScottK> I'll commit it to the Debian Python Modules Team and then hunt for a DD to upload it either way.
[12:20] <geser> ok, I will add it to the Debian bug and cc upstream
[12:27] <ScottK> Sounds good.
[12:28] <geser> ScottK: have you tested it on i386 already?
[12:29] <ScottK> No.  Got distracted by family stuff.  Assembling the package now.
[12:29] <geser> It would be good to know if it works for you too before I sent it upstream
[12:31] <ScottK> OK
[12:32] <ScottK> It looks like Debian has a patch in that's not released yet.  I'm checking to make sure this doesn't conflict.
[12:37] <ScottK> geser: This patch: http://svn.debian.org/wsvn/python-modules/packages/python-tclink/trunk/debian/patches/py_tclink-type-error-fix.dpatch?op=file&rev=0&sc=0 is for a different problem (if I'm reading it correctly), but interferes with yours.  how about you edit this patch instead of creating a new one?
[12:41] <ScottK> geser: I also asked the guy that did the patch in Debian what he thought.
[12:46] <ScottK> geser: I have just your patch building.
[12:51] <ScottK> geser: It builds. It may be a bit before I can get the Debian package update.  You might want to do an ubuntu2 in the meantime.
[12:52] <geser> ScottK: will do an upload tomorrow, it's nearly 1 a.m. here
[12:55] <geser> ScottK: I'm going to bed now, see you tomorrow
[12:56] <jussi01> gah, i hate it when gutsy breaks badly...
[12:57] <jussi01> especially when it looks like a stupid reason....
[01:04] <hendrixski> I just switched to a new computer, and am trying to get my old gpg key on board... I can't sign debian packages 'cause it says it has no private key... but it never asked me :-(
[01:05] <hendrixski> anybody have any words of wisdom?
[01:06] <jussi01> hmmm... words of wisdom.... nope... sorry, not me....
[01:06] <jussi01> :P
[01:07] <hendrixski> jussi01, lol
[01:07] <jussi01> :)
[01:08] <hendrixski> I had a flashback to windows... maybe it'll help if I reboot??? 'cause I already restarted the gpg-agent...
[01:08] <jussi01> hendrixski: i didnt see your issue...
[01:08] <jussi01> I just logged on again..
[01:09] <hendrixski> jussi01, oh... right right.... lemme try that log-out & log-in
[01:12] <ScottK> When hendrixski comes back ask him if he copied his ~/.gnupg from the old computer to the new one.  Thats' where the secret key is.
[01:12] <jussi01> ScottK: yeah, I didnt see what he asked, lol
[01:12] <jussi01> wht was his problem?
[01:13] <DarkSun88> jussi01: <hendrixski> I just switched to a new computer, and am trying to get my old gpg key on board... I can't sign debian packages 'cause it says it has no private key... but it never asked me :-(
[01:13] <ScottK> No private key on a new computer.
[01:13] <jussi01> aha
[01:13] <DarkSun88> hendrixski: <ScottK> When hendrixski comes back ask him if he copied his ~/.gnupg from the old computer to the new one.  Thats' where the secret key is.
[01:13] <hendrixski> jussi01, n go
[01:14] <hendrixski> DarkSun88, no... I didn't... is there a way to recreate the ~/.gnupg if I have my public and private keys?
[01:16] <DarkSun88> hendrixski: I don't know.
[01:18] <hendrixski> DarkSun88, ScottK, is it safe for me to go around messing with the files in the ~/.gnupg directory?  or are there gpg commands I should use instead?
[01:22] <hendrixski> oh... wait it's all binary files.... bugger
[01:25] <hendrixski> :-(  so am I supposed to create a new gpg key for each computer?
[01:27] <StevenK> You have an export of your private and public keys?
[01:29] <hendrixski> StevenK, you mean like the .asc file of the key?
[01:30] <StevenK> I thought a .asc was a signature.
[01:32] <hendrixski> StevenK, oh... umm, then no.. I can export it using seahorse...:-) would that set it up so that I  can sign stuff?  or are there steps I can do once it's exported that would allow me to do that again?
[01:33] <hendrixski> oh ... wait... when I click on it to export it then it tells me that I can save the export as a .asc.... :-( I am SSSSSSSSOOOOOO confused
[01:47] <jussi01> hendrixski: so cant you just copy th ~/.gnupg folder to each machine?
[01:49] <hendrixski> jussi01, no... because I wiped out the other computer :-(
[01:50] <jussi01> oh... hendrixski i would say they are gone forever.... just create a new one, and get someone to resync revu for you...
[01:50] <jussi01> thats what i did
[01:52] <hendrixski> well... I'll create one for the time being.. I'm still on the learning curve here (OBVIOUSLY) so none of what I'm packaging even works... let alone is good enough to submit back
[01:52] <jussi01> heh, dont worry, you will get there :)
[01:58] <hendrixski> jussi01, getting there is half the fun.
[01:58] <jussi01> yeps:)
[01:58] <hendrixski> ok... so I created a new gpg key... only gona let this one hang around for 10 days...
[01:58] <hendrixski> and tried to create the package again and... same error
[02:00] <hendrixski> gpg: [stdin] : clearsign failed: secret key not available
[02:03] <hendrixski> seriously is that a bug or am I just not smart enough to do this?
[02:08] <jussi01> oh... the poor guy...
[03:55] <mwolson> can someone please push my updates to erc and muse-el out on REVU?  the erc update resolves a DaD entry
[03:56] <mwolson> and the muse-el update will preemptively resolve one :^)
[04:00] <persia> mwolson: For a merge (erc), please rather post a debdiff against the Debian release to a bug.
[04:01] <mwolson> "post" as in post to a launchpad bug?
[04:03] <persia> mwolson: Yes.  When processing a merge, please open a launchpad bug (so others can see you are working on it), and when it is complete, attach a debdiff against Debian for the changes (or if the orig.tar.gz files differ, a debdiff against Ubuntu, with a note that it requires a manual merge, and that the debdiff is against Ubuntu).
[04:04] <persia> mwolson: Having just looked also at muse-el, the same guidelines apply.  Archiving both uploads.
[04:07] <StevenK> Excellent. I managed to just sneak in the new curl upload.
[04:07] <persia> mwolson: Looking at some of your other uploads - you probably want to read "Preparing New Revisions" in https://wiki,ubuntu.com/MOTU/Contributing: bugs are generally a faster way to get fixes in: you only need REVU when it is a NEW package, or a new upstream version.
[04:10] <mwolson> persia: thanks for the pointers
[04:11] <persia> mwolson: Thanks for all the excellent work to get the emacs packages in shape.  I'm looking forward to seeing the patches in the U-U-S queue for upload.
[04:11] <Fujitsu> StevenK: any idea about this error? It seems rather related to what you've been doing lately:
[04:11] <Fujitsu> tunepimp.tunepimp.TunePimpError: Error opening library: /usr/lib/libcurl-gnutls.so.4: version `CURL_GNUTLS_4' not found (required by /usr/lib/libtunepimp.so.5)
[04:12] <Fujitsu> I've rebuilt libtunepimp, but it still doesn't like me.
[04:13] <mwolson> persia: come to think of it, i have also made a package for emacs22; i've emailed Michael Vogt (the person who last changed emacs21 for Ubuntu) about getting it into gutsy; can you advise me on what other steps might be appropriate?
[04:13] <StevenK> Fujitsu: Hrrrm. Crap.
[04:13] <Fujitsu> That's what I thought.
[04:14] <Fujitsu> I didn't think things were meant to be able to die like that...
[04:14] <persia> mwolson: The best way to get a new package of that impact into Ubuntu is to get it into Debian.  Failing that, REVU is the mechanism, but I'm not sure that most of us would feel qualified to review changes of that magnitude.
[04:15] <mwolson> persia: My particular package will definitely not get into Debian because it includes GFDL documentation.  I want to beat Debian's version of emacs22 into gutsy so that it doesn't get split into some -nondfsg parts like emacs21 did.
[04:16] <persia> mwolson: Then email (or IRC) with recent uploaders of emacs21 in Ubuntu is likely your best path.
[04:16] <mwolson> I'm also collaborating to some extent with the guy who maintained emacs-snapshot packages in Debian until earlier this year; the emacs22 package borrows quite a bit from his, and his has had decent testing
[04:16] <Simon80> can anyone tell me why smplayer is in multiverse?
[04:17] <persia> Simon80: Dependency on mplayer?
[04:17] <Simon80> hrm, ok
[04:17] <StevenK> Fujitsu: Crap, maybe we do need to rebuild the curl4 packages. All 40 of them ...
[04:18] <Fujitsu> StevenK: Rebuilding it doesn't help...
[04:18] <StevenK> Fujitsu: Wait for the newest curl, -6ubuntu3
[04:18] <persia> mwolson: I've archived the remainder of your bugfixes in REVU.
[04:18] <Fujitsu> What was it that caused this reduction in SONAME?
[04:18] <ajmitch> crack
[04:19] <Fujitsu> ajmitch: Well, obviously, but I was looking for a little more verbosity.
[04:20] <persia> My understanding was that Debian didn't want to process the transition when there wasn't a significant ABI change, so they forced the use of the old name.
[04:21] <Simon80> ok, so why is mplayer in multiverse?
[04:22] <Fujitsu> Simon80: Patents and some potentially non-free code, I think.
[04:22] <Fujitsu> Though the latter seems to have been resolved recently.
[04:22] <Simon80> mmhmm, I see nothing in the copyright file
[04:23] <persia> Interesting: Debian has 1.0~rc1-14 in main now.
[04:24] <Fujitsu> persia: I believe it has some stuff stripped out, but I never got around to completely checking that.
[04:24] <RAOF> That surely has patented algorithms in it?
[04:25] <Simon80> I personally don't care about patented algorithms
[04:25] <Fujitsu> Simon80: But the archive admins do, fortunately.
[04:25] <Simon80> lol
[04:25] <Simon80> do they? see above..
[04:26] <Fujitsu> I see little relevant stuff above.
[04:26] <Simon80> either way, I think it's immoral to enforce any restrictions on decoding from these formats
[04:26] <Simon80> immoral, unethical, wrong
[04:26] <Simon80> etc.
[04:26] <Simon80> evil, even
[04:26] <Fujitsu> It's also likely illegal to not do so.
[04:26] <RAOF> Take it up with $GOVERNMENT
[04:26] <persia> Ah.  Yes.  All the encoding is stripped in debian (see debian/rules fix-orig-source:)
[04:27] <Fujitsu> persia: That'd do it.
[04:27] <Simon80> Fujitsu: for one thing, I mean immoral for the patent holders, and second, it's not criminal
[04:27] <Simon80> merely something you can be sued for
[04:27] <Fujitsu> I might see if I can minimise divergence from them, though.
[04:27] <persia> Simon80: It appears that the decoding isn't the problem, rather the encoding.  We'd prefer it in multiverse with encoding than in universe with encoding stripped.
[04:27] <Simon80> fair enough
[04:28] <Simon80> though I personally don't mind if they strip encoding
[04:28] <Fujitsu> A lot of people do, however.
[04:28] <Simon80> well, unless you have hardware that only decodes one of these tainted formats
[04:28] <persia> Simon80: Is multiverse that hard to use?  I suppose we could ship mplayer-free, but I think most users would only be confused.
[04:29] <Simon80> then it's a problem
[04:29] <Fujitsu> And I'm not sure we really want to be maintaining two of those things...
[04:29] <Simon80> persia: no, I was just curious, I don't mind multiverse at all
[04:29] <Simon80> that reminds me, I need to file a bug about Synaptic not making license info clear in its UI
[04:29] <Fujitsu>  libavcodec/README.jfdct.gz |   37 
[04:29] <Fujitsu>  mencoder.c                 | 1751 ---------------------------------------------
[04:30] <Fujitsu>  2 files changed, 37 insertions(+), 1751 deletions(-)
[04:30] <Fujitsu> That's the difference between our upstream tarballs.
[04:30] <Simon80> I see
[04:30] <Simon80> seems that you have to hunt down the copyright file to find out the license, synaptic should have that as a right click or package menu item
[04:30] <Simon80> view copyright info
[04:31] <Fujitsu> I don't believe apt has that information unless the package is installed.
[04:32] <persia> Fujitsu: One could grab it from e.g. http://changelogs.ubuntu.com/changelogs/pool/multiverse/m/mplayer/mplayer_1.0~rc1-0ubuntu11/copyright, if the network was available.
[04:35] <Simon80> lol
[04:36] <Simon80> it's not like that was a dead link
[04:36] <Simon80> it's hard to refute that kind of proof of existence
[04:36] <Simon80> unless maybe I haxxor c.u.c and remove the file
[04:46] <Fujitsu> Yay, debuild actually works with gpg-agent now.
[04:47] <Simon80> since when?
[04:47] <Simon80> gutsy?
[04:47] <Fujitsu> A few days ago, I think.
[04:47] <mwolson> nice
[04:47] <Simon80> so, only in gutsy
[04:47] <Simon80> cause yeah, I just tried that this weekend and said hmm, that doesn't work, and it's breaking things too
[04:48] <Simon80> and I have a post debuild hook to lsdiff my diff.gz, so hrm
[04:48] <Simon80> I don't like it when debuild errors out before that
[04:48] <ScottK> geser: Uploaded in Debian.  I'll file a sync once it's out.
[04:48] <Simon80> perhaps I should move it to post source
[04:54] <mwolson> i want to be very sure that i'm doing things correctly this time before repeating this process for 3 more packages: can someone double-check https://bugs.launchpad.net/ubuntu/+source/bbdb/+bug/123896 ?
[04:54] <ubotu> Launchpad bug 123896 in bbdb "Candidate revision bbdb_2.35.cvs20060204-1.1ubuntu1" [Undecided,Confirmed]  
[05:19] <superm1> hi guys.  i've got a package i'd like if someone can revu: http://revu.tauware.de/details.py?upid=5863, mythbuntu-default-settings
[05:35] <StevenK> Fujitsu: New curl binary packages should hit the archive soonish.
[05:40] <Fujitsu> StevenK: Great, I'll try once they're published.
[05:47] <StevenK> Fujitsu: Great, I'm very very curious if it works without a rebuild. If it doesn't, it looks to be another upload of curl and about 40 rebuilds.
[05:48] <Fujitsu> I'm grabbing the binaries from LP now.
[05:48] <Fujitsu> Which ones do I need? All of them?
[05:48] <peanutb> What is with all these netsplits?
[05:48] <jmg> it feels like undernet
[05:48] <peanutb> (ohh sorry, thats on Efnet)
[05:49] <StevenK> Fujitsu: Depends on what you have installed.
[05:51] <StevenK> Fujitsu: Pastebin 'COLUMNS=150 dpkg -l | grep curl' for me, please?
[05:52] <Fujitsu> Oh, neat, the binaries aren't linked until published.
[05:52] <Fujitsu> StevenK: Sure.
[05:53] <StevenK> Fujitsu: Yup. Should happen this publisher run, in about 15 minutes.
[05:54] <Fujitsu> StevenK: Right, but I would have thought they'd be available from the builds page before publishing.
[05:54] <Fujitsu> http://paste.ubuntu-nl.org/28448/
[05:54] <StevenK> Fujitsu: It could be due to not wanting to show them if they're stuck in NEW, or something.
[05:55] <Fujitsu> True.
[05:56] <StevenK> Fujitsu: Grab -6ubuntu3 for the libcurl* packages you have installed.
[05:57] <Fujitsu> StevenK: I'll do so in about 8 minutes.
[05:58] <StevenK> If it doesn't work, I suspect both pitti and I might cry. A lot.
[05:59] <Fujitsu> StevenK: Why? Huge numbers of rebuilds?
[06:00] <StevenK> Fujitsu: Yup. About 40.
[06:00] <Fujitsu> Can't that be semi-automated?
[06:01] <StevenK> I'd be doing them semi-automatically, but it still involves smashing my machine, my pipe, the buildds and the archive.
[06:03] <Fujitsu> They're published.
[06:03] <StevenK> Huzzah. Or something.
[06:05] <ScottK> If I want to synch a new upload from Debian, do I need to wait until it's published on f.d.o. before I file the sync bug?
[06:09] <StevenK> Fujitsu: Come on, put me out of my misery. :-P
[06:09] <Fujitsu> You don't want to know, I don't think.
[06:10] <Fujitsu> I'm being absolutely sure before I give you the bad news.
[06:11] <Fujitsu> Right. /me removes mysql-server-5.0, rather than having the kernel spewing oopses over all of my terminals.
[06:13] <Simon80> meh
[06:13] <Simon80> isn't it just something like for dir in *; do (cd dir && debuild);done or whatever?
[06:13] <ajmitch> heh
[06:13] <StevenK> Simon80: It's a little harder than that.
[06:14] <Simon80> ..but only a little, right?
[06:14] <ajmitch> not quite as short, though I suspect a few of us have a script to tweak changelog & rebuild a set of packages
[06:14] <Simon80> you'd want to tweak the control as well
[06:14] <StevenK> I was just plotting how to script adding changelog entries.
[06:14] <ajmitch> it's not hard
[06:14] <Simon80> StevenK, dch does it
[06:14] <Simon80> man dch
[06:15] <Fujitsu> StevenK: I'm sure doko has done it a lot.
[06:15] <Simon80> it's THAT easy
[06:15] <StevenK> Simon80: You don't need to help me, really. :-)
[06:15] <Simon80> lol, sorry, I'm not trying, you just made it sound like adding to changelog was non trivial
[06:16] <Fujitsu> StevenK: A rebuild of libtunepimp fixes it, unfortunately.
[06:16] <ajmitch> aha, I had to handle -XbuildY vs -XubuntuY vs -X
[06:16] <ajmitch> but I think that dch does that now
[06:16] <StevenK> Simon80: It is, because you have 3 distinct cases.
[06:17] <StevenK> Simon80: -X -> -Xubuntu1 ; -XubuntuY -> -XubuntuY+1 ; -XbuildY -> -XbuildY+1
[06:17] <StevenK> Fujitsu: After the rebuild, which library does it depend on and link against?
[06:17] <Fujitsu> StevenK: No, -X -> -Xbuild1
[06:17] <Simon80> StevenK, boo
[06:17] <StevenK> Oh, yes, right.
[06:17] <Fujitsu>         libcurl-gnutls.so.4 => /usr/lib/libcurl-gnutls.so.4 (0xb7c22000)
[06:17] <ajmitch> except that I have *breezy* hardcoded in this script
[06:17] <Simon80> it's still straightforward
[06:17] <Fujitsu> ajmitch: Ouch.
[06:17] <ajmitch> showing its age :)
[06:18] <StevenK> Fujitsu: What about its Depends?
[06:18] <Simon80> dpkg-parsechangelog | grep version | cut... etc.
[06:18] <Fujitsu> libcurl3-gnutls (>= 7.16.2-1)
[06:19] <Fujitsu> Hm, actually, that could be wrong.
[06:19] <StevenK> But it still dies without a rebuild ... *Wonderful*.

[06:19] <Fujitsu> The old one depends on libcurl4-gnutls.
[06:19] <StevenK> It isn't wrong.
[06:19] <StevenK> But the ABI shouldn't be different...
[06:20] <ajmitch> "shouldn't"
[06:20] <ajmitch> hah
[06:20] <Fujitsu> I thought it might have been wrong, because it listed both when I apt-cache showed. It turns out it was right, though.
[06:20] <Fujitsu> This looks pretty ABI-broken to me: Error opening library: /usr/lib/libcurl-gnutls.so.4: version `CURL_GNUTLS_4' not found (required by /usr/lib/libtunepimp.so.5)
[06:20] <StevenK> Fujitsu: Look at the description for libcurl4-gnutls. That should explain it.
[06:21] <Fujitsu> Ah.
[06:21] <StevenK> Fujitsu: Can you objdump -hpT /usr/lib/libcurl-gnutls.so.4 | grep CURL_GNUTLS
[06:22] <Fujitsu> StevenK: No CURL_GNUTLS_4 references at all.
[06:22] <StevenK> Personally, the Description for the new libcurl4{,-gnutls} amuses me.
[06:22] <Fujitsu> StevenK: That it does.
[06:22] <Fujitsu> older (newer)
[06:22] <StevenK> Fujitsu: I'm worried that CURL_GNUTLS_3 appears.
[06:23] <Fujitsu> StevenK: It's all that appears.
[06:23] <StevenK> Crap.
[06:23] <StevenK> So it *does* change.
[06:23] <StevenK> (At least for GnuTLS)
[06:24] <Fujitsu> So the SONAME was meant to revert, but symbol names weren't? How strange.
[06:25] <StevenK> The symbols are unversioned, but CURL_GNUTLS_[34]  is the library itself being fragging braindead.
[06:26] <Fujitsu> Neat.
[06:27] <ajmitch> special
[06:27] <StevenK> Fujitsu: Would you mind looking at http://people.ubuntu.com/~pitti/tmp/cruft/libcurl4, and seeing if one the packages listed there as cruft actually works?
[06:27] <Fujitsu> StevenK: Doing so.
[06:27] <StevenK> Fujitsu: Thanks,
[06:27] <StevenK> s/\,//
[06:28] <Fujitsu> william@irranat:~/MOTUing/libtunepimp-0.5.3$ gmpc
[06:28] <Fujitsu> gmpc: /usr/lib/libcurl.so.4: version `CURL_4' not found (required by gmpc)
[06:28] <StevenK> OH BLOODY ... &*&%($%($(%(%(*&^(
[06:28] <Fujitsu> :(
[06:29] <Hobbsee> hi everyone
[06:29] <Fujitsu> Hi Hobbsee.
[06:29] <Fujitsu> I think StevenK is about to combust.
[06:29] <Hobbsee> so it seems...
[06:30] <superm1> hi Hobbsee 
[06:30] <StevenK> Hobbsee: Curl is still stuffed.
[06:30] <ajmitch> hello Hobbsee 
[06:31] <Hobbsee> StevenK: yummy
[06:31] <Fujitsu> StevenK: Any idea why it's so screwed?
[06:32] <StevenK> Fujitsu: I'll talk to pitti about it when he appears.
[06:33] <Hobbsee> :P
[06:36] <StevenK> Right, crap. It looks like those symbols are versioned.
[06:36] <StevenK> Which means 40 rebuilds or so.
[06:37] <Fujitsu> StevenK: No other way out?
[06:37] <StevenK> Not that I can think of.
[06:37] <Fujitsu> Ouch.
[06:37] <StevenK> But Debian said the symbols are unversioned! Grah!
[06:37] <Fujitsu> I hope you have a lot of bandwidth free :P
[06:43] <StevenK> And it seems they tell lots of lies, since we patch it to be versioned. And now the damage is done.
[06:44] <StevenK> s/we/they/
[06:45] <Fujitsu> Ahh, very nice.
[06:46] <StevenK> Sigh. They said it was versioned.
[06:46] <StevenK> And now I need to profess to pitti that I really am an idiot.
[06:47] <Fujitsu> Did you break something because you thought they were unversioned?
[06:47] <StevenK> If the symbols were unversioned, both libtunepimp and gmpc ought to work.
[06:48] <Fujitsu> Right.
[06:48] <Fujitsu> Shouldn't apport have retraced bug #123870 by now?
[06:48] <ubotu> Launchpad bug 123870 in listen "[gutsy]  listen.py crashed on exit (SIGSEGV in PyThreadState_New())" [Undecided,New]  https://launchpad.net/bugs/123870
[06:48] <Fujitsu> StevenK: How about no.
[06:49] <StevenK> Fujitsu: You know what seppuku is?
[06:49] <Fujitsu> Of course.
[06:49] <Fujitsu> Who doesn't?
[06:49] <StevenK> I know it by it's older name, hari-kari
[06:50] <Fujitsu> ScottK: Has listen been crashy lately?
[06:50] <ScottK> IIRC yes.  
[06:50] <ScottK> That and one other written in Python player thingg.
[06:51] <ScottK> thingy that I don't recall the name of at the moment.  I think it starts with e.
[06:51] <ScottK> It's mostly the other one, but listen.py comes up a lot in my bugmail.
[06:51] <Fujitsu> exaile?
[06:51] <ScottK> That's the one.
[06:51] <Fujitsu> exaile's always been nice and crashy.
[06:52] <ScottK> There's a new one that doesn't crash in some of the old ways, but has new ones to replace them.
[06:52] <ScottK> Isn't there some kind of MOTU multi-media team?
[06:52] <Fujitsu> MOTU Media, yes.
[06:53] <ScottK> Should they get all that bugmail?
[06:53] <ScottK> I currently have pythonistas subscribed since they are in python, but if another team would care, I could remove myself and still be guilt free.
[06:54] <ScottK> remove myself ~ remove pythonistas because there aren't many members.
[06:54] <Fujitsu> ScottK: I'm not sure if we want it :P
[06:54] <Fujitsu> We've already got vlc, mplayer and xine.
[06:54] <ScottK> Well they are Medai...
[06:54] <Fujitsu> Quite enough bugs.
[06:54] <ScottK> Sure, so you're used to it.
[06:54] <Fujitsu> Hah, yes.
[06:56] <ScottK> So I can switch bug contact to MOTU media for those?
[06:57] <Fujitsu> I suppose so.
[06:58] <Fujitsu> It'll never work.
[06:58] <ScottK> As I've discovered.
[06:58] <ScottK> Urgh.
[06:58] <Fujitsu> Especially when filing bugs.
[06:58] <ScottK> Silly security precautions.
[06:59] <ScottK> OK, try again...
[06:59] <ScottK> will you sub MOTU Media for exaile and listen?  I'm going to remove pythonistas.  There's no way I'd try and fix those anyway.
[07:00] <Fujitsu> OK.
[07:00] <ScottK> Mine are done.
[07:00] <Fujitsu> I can only subscribe motumedia, thanks to one of the high-priority Malone bugs.
[07:00] <Fujitsu> s/,//
[07:01] <ScottK> OK.  If Laserjock would lower himself to show up here and not just in #ubuntu-devel, you could whine.
[07:01] <ScottK> ;-)
[07:01] <Fujitsu> Hm, interesting that he's not here.
[07:02] <Fujitsu> ScottK: I don't know why I'd want to whine about these relaxed permissions, though
[07:02] <ScottK> No.  He hasn't been the last couple of times I've seen him over there.
[07:02] <ScottK> Ah.  I understand now.
[07:04] <StevenK> Actually, I just thought of a way around this.
[07:05] <StevenK> A new upload of curl, that hacks in both CURL_3 and CURL_4 symbols.
[07:05] <Fujitsu> StevenK: Oh no. Sounds bad. What is it?
[07:05] <Fujitsu> Ah.
[07:05] <Fujitsu> Hacks. Yay.
[07:05] <ScottK> Well back to working my way through Ubuntu packages with Ubuntu diffs that belong to Debian Python Modules Team and putting all the relevant Ubuntu changes in their svn.
[07:05] <Fujitsu> At least it's better than 40 rebuilds.
[07:05] <Fujitsu> ScottK: How many are there?
[07:05] <StevenK> Fujitsu: That the thought I'm consoling myself with.
[07:06] <ScottK> Fujitsu: DPMT has ~ 130 packages.  I'm about 90% through the list.
[07:06] <Fujitsu> How many had Ubuntu diffs?
[07:06] <ScottK> IIRC about a dozen.
[07:07] <ScottK> All but one or two should work for sync after then next Debian upload.
[07:07] <ScottK> then/the
[07:08] <Fujitsu> ScottK: Nice work. I should probably do something similar for science packages in the near future.
[07:08] <Fujitsu> StevenK: If you need any testing or whatever, please ask.
[07:08] <StevenK> Fujitsu: I was planning on. :-)
[07:08] <Fujitsu> Hi crimsun!
[07:08] <crimsun> 'lo
[07:08] <RAOF> ScottK: You mean "python-pyinotify"?  Cause I sent that patch to the BTS
[07:09] <ScottK> Going through that was how I noticed geser's problem with python-tclink and python 2.5
[07:10] <RAOF> Ah, it's also built against 2.4 only?
[07:10] <ScottK> RAOF: No, notify-python is a different package.  DPMT doesn't have python-pyinotify.
[07:10] <RAOF> Ah.  Of course it is :)
[07:10] <ScottK> This was a case of him having changed the package to build against python 2.5 when it didn't work with python 2.5
[07:11] <ScottK> Good news is after I pointed that out, he figured a patch that's already been uploaded for Debian and we can sync after it builds.
[07:12] <StevenK> Fujitsu: Do you want to build curl, or do you want me to throw you binaries?
[07:12] <Fujitsu> StevenK: How long does it take to build?
[07:12] <StevenK> Fujitsu: 10 minutes on my 3Ghz amd64
[07:12] <Fujitsu> Probably faster to throw me binaries, then.
[07:12] <Fujitsu> ALthough I'd need i386, so maybe not.
[07:12] <StevenK> I can build either.
[07:13] <Fujitsu> Ah, great.
[07:13] <StevenK> At this point, I'm still investigating the versioning of the symbols.
[07:15] <StevenK> Shared libraries are fun.
[07:17] <StevenK> Fujitsu: What was the first symbol that was bitched about? CURL_GNUTLS_4?
[07:18] <Fujitsu> StevenK: That's the one.
[07:18] <Fujitsu> (for libtunepimp, at least. gmpc was just CURL_4)
[07:24] <StevenK> Right. I think I have a horrid hack for this.
[07:24] <Fujitsu> StevenK: Good (bad).
[07:24] <StevenK> Heh
[07:25] <StevenK> I'm going to leave the decision to pitti, and I'll go with what he says. I'm still not sure if this will work at all.
[07:26] <StevenK> Whimper.
[07:27] <Fujitsu> I presume it's just because I haven't updated it in about 5 hours...
[07:28] <Toadstool> heya everybody!
[07:28] <Toadstool> wom2
[07:28] <Fujitsu> Hi Toadstool.
[07:28] <Toadstool> oops
[07:28] <Toadstool> hey Fujitsu 
[07:30] <Toadstool> DebianImportFreeze? Automatic syncs are stopped already?
[07:31] <Toadstool> hmpf
[07:31] <Fujitsu> Toadstool: A couple of days ago, I think :(
[07:31] <Toadstool> June 21st apparently, kind of early, isn't it?
[07:32] <Fujitsu> I would have thought so.
[07:32] <Fujitsu> But we don't control it, unfortunately.
[07:35] <Hobbsee> Toadstool: Fujitsu: what are your thoughts on tools for universe, w.r.t catching bugs fixed in debian, etc.  have you read the mailing list yet?
[07:36] <Fujitsu> Hobbsee: I read that about 2 minutes after you sent it.
[07:36] <Hobbsee> Fujitsu: right
[07:36] <Fujitsu> I think it'd be nice to have some way of keeping autosync on, but that's obviously not possible...
[07:37] <Hobbsee> Fujitsu: saying "we dont control it" is effectively useless - even though it's true.  Coming up with producive solutions as to what we *can* do, apart from leaving the autosyncer on, is useful.
[07:37] <crimsun> that would likely require access to Soyuz source.
[07:37] <Fujitsu> Hm, great, we're already 236 syncable packages behind.
[07:38] <Fujitsu> crimsun: That would always be good.
[07:38] <Toadstool> Hobbsee: I read it real quick this afternoon at work and wanted to read it again tonight and give it a little more thinking but unfortunately it is the 4th of July over here (well not yet, but fireworks, etc) and I was invited to a dinner and drank a little too much wine
[07:38] <Hobbsee> Toadstool: no problem.  :)
[07:38] <Toadstool> tomorrow :)
[07:38] <Hobbsee> Toadstool: good thought on it is what i want - i merely wrote that as a starting point :)
[07:38] <Fujitsu> If Malone did version tracking and imported Debian bugs it would be nice, but ajmitch's list does that fairly well.
[07:40] <Fujitsu> If we can acquire resources (ie. hope lucas will do it), rebuilding a piupartsing would be very nice, but I think it was done too late in the cycle last time.
[07:40] <Hobbsee> Fujitsu: apparently it takes about 6 days to do.
[07:40] <Hobbsee> Fujitsu: on lucas' machine
[07:40] <Hobbsee> Fujitsu: however, it's possible to do it in the data center, assuming that it doesnt render the machines incapable for anything else
[07:41] <Hobbsee> Fujitsu: it seems that getting debcheck regualrly run for ubuntu, and fixing that stuff first, would be useful - and then do piuparts later
[07:41] <Fujitsu> StevenK: Why is libcurl4-dev depending on an old version of libcurl4?
[07:41] <Fujitsu> It'd be useful to have a machine to run this stuff on, too. tiber is probably worse than useless.
[07:41] <Toadstool> the thing is, we already have several tools or lists set up by different people but it is kind of scattered all around the world and it is hard to keep track of all these tools. if we had something like a qa page, it'd be easier to have a global overview of what needs to be done, imo
[07:41] <Hobbsee> Fujitsu: ideally, we'd stick all these scripts, and outputs in some locial place
[07:42] <lifeless> ubuntu-weather-report 
[07:42] <Hobbsee> Toadstool: that's what i want to do, yes.
[07:42] <lifeless> its a spec
[07:42] <Fujitsu> Hobbsee: Where local is maintained by Canonical and entirely out of our control, probably.
[07:42] <Fujitsu> lifeless: It got condemned to the land of -ENOTIME, AFAIK.
[07:42] <lifeless> if you'd like to work on that, it would be great; it will need data from within the datacentre though
[07:42] <Hobbsee> lifeless: it's got no URL, and mithrandir doesnt have ntoes, and i've not seen bdmurray awake at the same time
[07:42] <lifeless> Fujitsu: it got made my problem; yesterday I mailed mdz saying ENOTIME
[07:42] <Fujitsu> lifeless: Ah.
[07:42] <Hobbsee> Fujitsu: depends on who's "our" control is, etc.
[07:43] <lifeless> Mithrandir does not have toes?
[07:43] <Hobbsee> lifeless: do you have notes on it?
[07:43] <Hobbsee> s/ntoes/notes/
[07:43] <lifeless> Hobbsee: I remember most of it, and will mail bdmurray to ask him to upload his
[07:43] <Hobbsee> lifeless: thankyou.  i want to speak to heno, and likely him too anyway, so will grill him over that at the same time.
[07:45] <StevenK> Fujitsu: Doing my own testing first.
[07:45] <ajmitch> lifeless: any indications of what it might be?
[07:46] <StevenK> Fujitsu: It does? (libcurl4-dev)
[07:46] <Fujitsu>   libcurl4-dev: Depends: libcurl4 (= 7.16.2-4ubuntu1) but 7.16.2-6ubuntu3 is to be installed
[07:46] <Fujitsu> That's in a Gutsy chroot updated 10 minutes ago.
[07:46] <lifeless> ajmitch: of what what might be?
[07:47] <ajmitch> what may be contained in this spec, what tools would be available
[07:47] <StevenK> Fujitsu: I haven't checked, libcurl4-dev might be NBS.
[07:47] <Toadstool> /win/win1
[07:47] <Toadstool> gar
[07:48] <StevenK> libcurl4-dev is not built by curl any more.
[07:48] <Fujitsu> StevenK: Right, it's NBS.
[07:48] <Fujitsu> Damn, beat me to it.
[07:48] <StevenK> Fujitsu: :-P
[07:48] <Fujitsu> This is probably a bad thing, as stuff build-depends on it.
[07:48] <StevenK> It's Provided by libcurl4-gnutls-dev
[07:49] <StevenK> So once libcurl4-dev gets killed, stuff should deal.
[07:49] <Fujitsu> Ah, true.
[08:02] <Fujitsu> crimsun: Has MoM been turned off?
[08:03] <crimsun> or if our resident ubuntu-release LP team member has privileges to the knob(s)...
[08:03] <Hobbsee> crimsun: i dont have DC access at this point.
[08:03] <Hobbsee> crimsun: at the moment, there's focus on lucas' scripts.   if you could look at, think on, and respond to, my post on the motu mailing list, i'd find that very useful
[08:04] <Hobbsee> crimsun: MoM only does merges, not syncs, unfortunately, so only does half of what we want
[08:04] <crimsun> Hobbsee: true (although my particular use cases are specifically merges).
[08:05] <Hobbsee> crimsun: true.  ask the relevant people (keybuk, i guess) when they wake up
[08:07] <Hobbsee> crimsun: no idea if pitti can do it
[08:08] <Fujitsu> AFAIK Keybuk/cjwatson do MoM.
[08:09] <Toadstool> I'll try not to laugh too hard next time I read this in my backlog. I guess champagne helps being really dumb but it made my day^Wevening
[08:09] <Hobbsee> Fujitsu: true, but i'm not sure how many more people can turn it on/off
[08:10] <Fujitsu> Is it actually turned off?
[08:10] <crimsun> it seems so.
[08:11] <Fujitsu> That sounds wrong.
[08:14] <man-di> Fujitsu: it think it had some problems due to ftp.debian.org having problems (disk full) and not updating
[08:16] <Fujitsu> man-di: I knew about ftp.d.o being stuffed, but hadn't considered that MoM might be using it.
[08:17] <man-di> Fujitsu: thats what I heared, I dont know if its a fact
[08:26] <dholbach> good morning
[08:27] <RAOF> good afternoon
[08:27] <Fujitsu> Hi dholbach.
[08:27] <dholbach> hey RAOF, hey Fujitsu
[08:27] <dholbach> how's it going?
[08:31] <Hobbsee> morning dholbach!
[08:31] <dholbach> heya Hobbsee
[08:31] <RAOF> Eh.  Seems that prebuild has a launchpad page now, so I might ressurect my attempts to get it to generate sane autotools.  Then I could get Tao 2.x into debian, which'd be nice
[08:37] <DarkMageZ> if i wanted to get a package into multiverse... should i upload it to revu?
[08:37] <Hobbsee> yes
[08:39] <RAOF> Unless it was a bugfix to an existing package?
[08:40] <RAOF> Or merge from debian, etc
[08:41] <DarkMageZ> actually. that's my next question :)
[08:42] <DarkMageZ> so i've tidied up that libvisual package alittle more to attempt to avoid being burnt by the motus :) since it's a bunch of bugfixes in one change then?
[08:44] <RAOF> It's just an extra patch or two, right?  In which case it wants to be a debdiff attached to a launchpad bug, and "ubuntu-universe-sponsors" subscribed.
[08:45] <DarkMageZ> extra 2 patches and --disable-gdkpixbuf (as gdkpixbuf is just a blank plugin)
[08:45] <RAOF> Presuming that you are not patching the source direcly, that sounds debdiffable
[08:45] <crimsun> (still debdiffable even if the source is patched directly)
[08:46] <DarkMageZ> oh, also had to autotool it and patch directly :(
[08:46] <DarkMageZ> actually 3 patches
[08:47] <RAOF> crimsun: Just more likely to be rejected :)
[08:48] <crimsun> well, if we're talking about libvisual source, yes, it would make sense to use cdbs's simple-patchsys
[08:49] <RAOF> Why do you need the autotools change?  Is configure broken? :(
[08:49] <DarkMageZ> there were changes to the makefile.am's
[08:49] <RAOF> Yay :(
[08:49] <DarkMageZ> nessesary tho
[08:51] <RAOF> Touching autotools is never fun.  Anyway, debdiff it against the current ubuntu package, and put it on launchpad
[08:52] <DarkMageZ> diff the ubuntu diff against my diff or just my diff against the orig.tar.gz?
[08:52] <RAOF> If possible using patches, rather than touching the upstream source directly
[08:53] <RAOF> man debdiff :)
[08:53] <RAOF> diff the two .dsc's
[08:58] <DarkMageZ> so "debdiff 1.dsc 2.dsc > libvisualplugins.diff" ?
[08:58] <Hobbsee> DarkMageZ: looks right
[09:01] <DarkMageZ> so i'm going to file a new bug report and mark the 2 bugs it fixes against it. what should i put in the title?
[09:03] <DarkMageZ> "[debdiff]  bunch of fixes for libvisual-plugins" ?
[09:06] <RAOF> DarkMageZ: Might be nice to indicate what it fixes :)
[09:06] <DarkMageZ> description :)
[09:07] <RAOF> But essentially, yes.  And subscribe u-u-s
[09:08] <RAOF> (not assign.  I misread that for so long :()
[09:15] <DarkMageZ> yay. filed :)
[09:30] <RAOF> DarkMageZ: Eeep.  That's quite a patch
[09:32] <RAOF> Some comments: We don't do NMU's, so you can ignore the warning
[09:33] <DarkMageZ> will i need to redo the debdiff with my nmu comment removed from the changelog/
[09:33] <RAOF> 2) The MOTU who looks at that is going to ask you to make those patches, rather than touching the source
[09:34] <RAOF> 3) You can seriously trim the auto* changes
[09:35] <RAOF> The smaller the debdiff, the easier and faster it will get in, generally :)
[09:36] <RAOF> To make patches, you can use cdbs-edit-patch, if you are not already aware
[09:38] <DarkMageZ> 2 & 3 require skills that i don't have
[09:40] <RAOF> 2 is easy - just run 'cdbs-edit-patch 0x_my_patch_name', and do what you did before
[09:42] <RAOF> (as in: run 'patch -p0 < patch', or whatever it was that you did to apply the patches)
[09:43] <RAOF> For 3 you can start by doing 'c-e-p 99_autotools', running autogen.sh, and then exiting
[09:44] <RAOF> The autotools bit is certainly non-trivial, though
[09:45] <RAOF> If you want, I can do the autotools cleanup, if you want to do the rest
[09:48] <DarkMageZ> k. i'll sort the patches. you can sort the autotools :)
[09:48] <RAOF> :)
[09:56] <DarkMageZ> so i've extracted the orig.tar.gz twice. one for hacking up and one called *.orig . so after each individual change i should generate a diff between both folders then start again on the next patch?
[10:04] <RAOF> DarkMageZ: No.  What you want to do is start with a clean package.  Then run 'cdbs-edit-patch 0x_foo', then mess with the source in there, and when you run 'exit', it will automatically create 'debian/patches/0x_foo.patch' for you
[10:05] <DarkMageZ> yeah, i just completed my first change after reading the ubuntu packaging guide about that :)
[10:05] <RAOF> :)
[10:09] <dholbach> can somebody give a second OK on  http://revu.tauware.details.py?upid=5867 ?
[10:11] <Sp4rKy> StevenK: around ?
[10:12] <StevenK> Sp4rKy: Ish
[10:12] <Sp4rKy> StevenK: i'm merging libtunepimp
[10:12] <crimsun> dholbach: "upload 5867 invalid or has been nuked"
[10:13] <StevenK> Sp4rKy: Don't, please.
[10:13] <Sp4rKy> it appears you maintain it
[10:13] <Sp4rKy> StevenK: why ?
[10:13] <crimsun> presuming you meant [..] tauware.de/details.py?upid=5867
[10:13] <Sp4rKy> you do it?
[10:13] <StevenK> Sp4rKy: Well, when I say don't, I mean not yet.
[10:13] <Sp4rKy> ok ,why ?
[10:14] <Sp4rKy> it will have an update on debian ?
[10:14] <StevenK> Sp4rKy: libcurl is one of libtunepimp's Build-Depends. I'm about to upload a new version that changes stuff again, and I'd like for that go in before it's merged.
[10:14] <Sp4rKy> ok
[10:14] <StevenK> Sp4rKy: So, hold off for a day, please.
[10:15] <Sp4rKy> what will be changed in libtunepimp ?
[10:15] <Sp4rKy> the BD name ?
[10:15] <StevenK> Nope.
[10:15] <dholbach> sorry, that was  http://revu.tauware.details.py?upid=5857   - thanks crimsun
[10:15] <StevenK> I just want it to build against the correct libcurl.
[10:15] <crimsun> dholbach: is your irc client performing some strange autocorrection of urls?
[10:16] <dholbach> crimsun: no... where do you get that idea?
[10:16] <Sp4rKy> StevenK: ok
[10:16] <crimsun> 04:15 < dholbach> sorry, that was  http://revu.tauware.details.py?upid=5857
[10:16] <Sp4rKy> StevenK: can you ping me when curl was uploaded please ?
[10:16] <dholbach> crimsun: I reviewed it on my other machine, and typed it in manually
[10:17] <crimsun> dholbach: right, but either I'm blind, or the domain is utterly missing in addition to the separator
[10:17] <dholbach> http://revu.tauware.de/details.py?upid=5857
[10:18] <dholbach> *blush crimson*
[10:18] <dholbach> it's just me
[10:22] <StevenK> Sp4rKy: Sure, but it's going to take ~ 2 hours for it hit the archive.
[10:23] <Sp4rKy> StevenK: np, i'll wait
[10:23] <Sp4rKy> the merge is pretty ready, i'll just rebuild it to check :)
[10:29] <crimsun> dholbach: reviewed.
[10:31] <dholbach> crimsun: thanks ... what's wrong with /usr/bin/env python?
[10:31] <Fujitsu> dholbach: Debian policy says you're not to use it.
[10:31] <dholbach> ah ok
[10:31] <crimsun> what he said.
[10:36] <DarkMageZ> RAOF, should i send you the new .diff.gz?
[11:27] <RainCT> what should be done if a package is using a GNOME icon (= that's not in KDE)? copy that icon and install it with the name of the package to have it on both?
[11:43] <dholbach> best to depends on gnome-icon-theme (if that's where the icon is from)
[12:02] <RAOF> DarkMageZ: Attach it to the bug, and I'll look at it when I'm free
[12:23] <dholbach> keescook: I added the scripts you added to setup.py in ubuntu-dev-tools
[12:24] <dholbach> keescook, geser, Lutin: can you check that your scripts have all license notices in the header in ubuntu-dev-tools?
[12:24] <dholbach> I'd really like to upload the package soon
[12:25] <keescook> dholbach: ah! very cool; yeah I forgot that bit.  :)
[12:32] <NeilW> Anybody free to do a package REVU? Apparently I have to beg so here goes.
[12:34] <RainCT> dholbach: the icon is in gnome-media-common, so it should depend on it?
[12:34] <tom_> hello! I'm thinking of joining the MOTU team. I like compiling proper Debian packages and I am also a member of the GETDEB community where I sometimes upload newer packages. So after reading the documentation I found that I must seek a mentor. But since I am going to the sea in about a week and will be there for a month should I rather seek the mentor after I get home? If that is the case...
[12:34] <tom_> ...what else can my n00bs packaging skills do till I get to the sea-side.
[12:36] <dholbach> RainCT: it's preferrable to duplicating icons and stuff, but I know that it might be a bit heavy
[12:36] <minghua> tom_: As far as I remember mentor is not mandatory.  Pick packages that you want to help with, reply to bug reports, write patches, then ask for review.
[12:36] <RainCT> dholbach: ok, thanks
[12:39] <tom_> minghua: that is my my problem. I do not know where to begin and which packages should I start to compile. 
[12:40] <jussi01> morning all
[12:41] <minghua> tom_: Read the documentations on wiki, for example https://wiki.ubuntu.com/MOTU/Contributing .
[12:41] <minghua> tom_: (which is in the channel topic)
[12:44] <tom_> minghua: so I go here: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=needs-packaging , and then I pick a package and create a proper DEB file and then I uploud the package to REVU. Is this correct?
[12:46] <RainCT> dholbach: do you know if it's a build-depends or a build-depends-indep?
[12:48] <minghua> tom_: Yes, that's correct.  Although I should warn you that MOTU is now lacking manpower for reviewing REVU packages, so it's probably not the best way to start contributing.  But if you can find a MOTU who is interested in the package you are going to work on, then by all means go ahead.
[12:48] <dholbach> RainCT: a depends
[12:49] <tom_> minghua: so what would the the better way to start contributing?
[12:52] <minghua> tom_: I think bug triaging is probably the safest way to start -- we always need more people to look at bugs.
[12:52] <minghua> tom_: https://wiki.ubuntu.com/MOTU/TODO is another page worth reading.
[12:53] <minghua> tom_: Start from https://wiki.ubuntu.com/MOTU/ and get an idea what MOTUs do, find an area that interests you.
[12:57] <RainCT> keescook: So what's with Open Invaders?
[12:58] <keescook> RainCT: I haven't had much time to examine it.
[12:59] <keescook> RainCT: did you contact upstream about the amd64 build issues?
[01:00] <RainCT> keescook: no, was waiting for the package to get into the repositories to tell him about that (and some other comments I've) on the same mail. (btw, it's not only with amd64 but also powerpc iirc)
[01:17] <yamal> is it ok for a package in universe to recommend or suggest something that is in multiverse? 
[01:18] <Fujitsu> Suggests perhaps, but I don't think a Recommends is appropriate.
[01:19] <yamal> in that case i'll just make it a suggested, thanks
[01:20] <porthose> could you please point me to a good CDBS howto
[01:21] <tom_> I am also interested in a good CDBS guide. The ones I've seen lack a lot
[01:25] <NeilW> What should the version number look like for an Ubuntu native package?
[01:27] <DktrKranz> NeilW, take pbuilder as example: 0.166ubuntu1
[01:29] <Amaranth> DktrKranz: nope, that's a debian native package with ubuntu changes :)
[01:29] <DktrKranz> whoops, I read Debian :)
[01:30] <CrummyGummy> Hi all, can anyone please point me to some examples of packaging using cdbs?
[01:32] <NeilW> CrummyGummy: The Ruby Extras guys use a lot of CDBS. Try http://svn.debian.org/wsvn/pkg-ruby-extras/
[01:32] <icf7> zakame: Has the Java channel changed from #ubuntu-motujava ?
[01:33] <NeilW> So is an Ubuntu native package just 0.1, a Debian upstream package with Ubuntu changes 0.1-0ubuntu1 and a Debian native package with Ubuntu changes 0.1ubuntu1
[01:46] <icf7> I wrote a template for the use of uscan which respects debian policies: http://pastebin.ca/602915 . Any comments? Is this good enough to be integrated in the Wiki examples?
[01:50] <mok0> icf7: As I understand it, the get-orig-source target is intended to fetch the current version of the orig.tar.gz, and possibly repackage it.
[01:50] <mok0> icf7: but I'm no authority...
[01:50] <icf7> mok0: Exactly. This is an example for repackaging a zip to a .tar.gz
[01:51] <mok0> icf7: why do you need uscan then?
[01:51] <icf7> mok0: To download the current version
[01:51] <mok0> ifc7: you could just grep it out of control
[01:51] <mok0> :-)
[01:52] <icf7> mok0: debian/control? Where should the version be set? And how is magically it updated as soon as upstream releases a new version?
[01:52] <mok0> rephrase -- you could grep the version info from control
[01:53] <mok0> rephrase #2 grep from changelog
[01:54] <mok0> Generally speaking, it is surprising that the buildertools do not know how to deal with a .zip archive
[01:54] <icf7> mok0: Well, changelog is updated after downloading the newest version
[01:55] <icf7> mok0: By uscans cousin, uupdate
[01:55] <mok0> icf7: going back to my initial comment, shouldn
[01:56] <mok0> 't the target just get the current packaged version and not the newest?
[01:56] <icf7> mok0: Oh, yes, get-orig-source fetches the _newest_ version, not the one in changelog
[01:56] <icf7> mok0: See http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
[01:57] <mok0> OK I stand corrected
[01:57] <mok0> icf7: In that case, I think your example is very instructive
[01:58] <mok0> But you need a thorough explanation how it is used, for newbies like me
[01:59] <icf7> well, I'll just change the wiki then and ask persia when he comes to IRC
[02:01] <mok0> icf7: Is __PACKAGE__ a macro that gets expanded?
[02:01] <icf7> mok0: no, just the package name
[02:01] <icf7> mok0: The implementor may use a macro for this, though
[02:01] <mok0> icf7: ... so you have to put the package name in there verbatim?
[02:02] <icf7> mok0: depends ... normally yes. Any idea how to obtain the full name of the downloaded package from uscan?
[02:04] <mok0> I'm not really familiar with uscan, I've never used it other than to check the newest version of the upstream sources
[02:04] <mruiz> hi all
[02:04] <mok0> but again... can't you grep it from debian/control?
[02:04] <icf7> mok0: No, no version info there, especially not the one released by upstream.
[02:05] <mok0> but there is no version info in __PACKAGE__
[02:05] <icf7> mok0: After that, there is $${version} which gets set by uscan's output
[02:05] <icf7> sry, I gotta go ... will be back around ~16 UTC
[02:14] <asac> geser: why did you reinstantiate the bogus xulrunner patches?
[02:15] <asac> geser: I already explained that they are hazardous, didn't I? (or was is someone else i talked to)?
[02:16] <asac> geser: anyway ... if you want to take a look, the probably right approach is not at https://bugzilla.mozilla.org/show_bug.cgi?id=386610
[02:16] <ubotu> Mozilla bug 386610 in XPCOM "pyxpcom fails to build against python 2.5 (api changed)" [Normal,Assigned]  
[02:16] <asac> s/not/now/
[02:16] <asac> i will upload an updated xulrunner
[02:19] <DarkSun88> asac: My package?
[02:20] <asac> yeah ... feel free to take it afterwards again
[02:20] <DarkSun88> I'm last uploader of xulrunner package, if you want, I'll make a debdiff and I'll upload it in LP
[02:20] <asac> its already done ... sorry, if i don't upload now i will forget again :) is it ok?
[02:21] <DarkSun88> Ok :)
[02:21] <asac> i can change the changelog person if you want though :)
[02:21] <asac> but that would be kind of spoofing
[02:21] <DarkSun88> asac: Don't worry.
[02:22] <asac> DarkSun88: http://people.ubuntu.com/~asac/xulrunner_1.8.1.4-2ubuntu1_1.8.1.4-2ubuntu2.debdiff
[02:23] <asac> thats he debdiff (if you care)
[02:24] <DarkSun88> It's your. You upload it ;)
[02:25] <asac> DarkSun88: sure ... i even forgot to update autoconf .... do you know how to do that for future merges?
[02:25] <asac> (though I hope that mike will apply these patches in next upload)
[02:25] <asac> DarkSun88: i touch configure.in in the 61_... patch
[02:25] <asac> DarkSun88: thus you need to rerun autoconf2.13 ... and update 99_autoconfSOMETHING.dpatch
[02:27] <asac> 1. dpatch-edit-patch 99_configure.dpatch
[02:27] <asac> 2. autoconf2.13
[02:27] <asac> 3. exit 0
[02:27] <asac> done.
[02:27] <CrummyGummy> NeilW, Thanks.
[02:29] <asac> DarkSun88: ok i added the 3 steps above to remaining changes so you just follow these
[02:31] <asac> DarkSun88: if you want an upload reviewed/sponsored for xulrunner in future, just ask me please ... i am always here or in #ubuntu-mozillateam :)
[02:31] <DarkSun88> Ok, thanks a lot.
[02:31] <DarkSun88> :)
[02:31] <xxxxx1> morrrning all!
[02:31] <asac> DarkSun88: if you want to work more on mozilla packages, just join mozillateam :) ...we always need more skilled people .)
[02:31] <DarkSun88> :)
[02:31] <DarkSun88> Ok
[02:47] <Fujitsu> Hi Hobbsee.
[02:48] <Hobbsee> hey Fujitsu 
[02:48] <jussi01> hello Hobbsee!
[02:49] <Hobbsee> heh
[02:49] <Hobbsee> you're here too, hey?
[02:49] <jussi01> yep...
[02:49] <Hobbsee> hiya jussi01!  not klined again, i see?
[02:49] <jussi01> Hobbsee: no...:P
[02:50] <jussi01> lol, i dont leave my pc unattended now...
[02:50] <Hobbsee> oh good
[02:50] <zul> tis the Hobbsee fan club
[02:50] <jussi01> zul: isnt that the whole of -motu?
[02:50] <jussi01> :P
[02:50] <jussi01> everyone loves Hobbsee
[02:50] <zul> im not a member
[02:50] <Hobbsee> heh
[02:50] <Hobbsee> zul: at least i'm not a deity...
[02:50] <jussi01> zul: well its free to join....
[02:51] <jussi01> Hobbsee: be thankful fo rthat...
[02:51] <jussi01> :P
[02:51] <Hobbsee> heh, yeah
[02:51] <jussi01> you'd end up like crimsun
[02:51] <zul> Hobbsee: thank deity ;)
[02:51] <Hobbsee> hehe
[02:52] <jussi01> where is crimsun anyway... i haven seen him for ages...
[02:53] <StevenK> Oh, twitch.
[02:54] <zul> he is moving last time I heard
[02:54] <jussi01> StevenK: ?
[03:02] <Hobbsee> Fujitsu: you've done debcheck for ubuntu now?
[03:02] <StevenK> The reason I'm twitching is I'm doing 37 rebuilds for libcurl.
[03:02] <StevenK> It is 550Mb of packed and unpacked sources.
[03:02] <Fujitsu> Hobbsee: Yup, I think it's working.
[03:02] <zul> that must be fun
[03:02] <Hobbsee> Fujitsu: neat :)
[03:02] <StevenK> zul: You're telling me.
[03:02] <Fujitsu> StevenK: That might take a while to upload.
[03:02] <Hobbsee> Fujitsu: you'll throw the scripts into bzr somewhere, or something?
[03:03] <StevenK> Fujitsu: Why? Most, if not all of them aren't going to involve the orig.
[03:03] <Fujitsu> StevenK: Hm, true.
[03:03] <Fujitsu> Hobbsee: Sure, once I minimise the diff from Debian.
[03:03] <Hobbsee> Fujitsu: excellent :)
[03:04] <Fujitsu> Currently sitting at http://people.ubuntu.org.au/~fujitsu/debcheck/
[03:04] <Fujitsu> Though that box is a little slow.
[03:15] <mruiz> Hi all. I need to delete some files from REVU (amsn).
[03:16] <mruiz> Someone can help me with this issue ?
[03:18] <Hobbsee> mruiz: i dont think tehy're there
[03:21] <mruiz> Hobbsee, some files "appeared" debian/package.postinst and debian/package.postrm. In my laptop don't exist. For this, I want to upload all the files again.
[03:21] <Hobbsee> mruiz: are they in the .orig.tar.gz?
[03:22] <mruiz> no
[03:22] <jeromeg> are bug 52786 and bug 52787 only packaging problems , or should they be worked upstream ?
[03:22] <ubotu> Launchpad bug 52786 in openafs "openafs-modules-source builts when kernel API++" [Low,Incomplete]  https://launchpad.net/bugs/52786
[03:22] <Hobbsee> mruiz: there's nothing in incomming, so you can just fix it and upload again
[03:22] <ubotu> Launchpad bug 52787 in openafs "openafs-modules-sources should also create a second openafs-module-2.6-<flavor> pkg" [Low,Confirmed]  https://launchpad.net/bugs/52787
[03:24] <mruiz> thanks Hobbsee 
[03:24] <Hobbsee> Fujitsu: looks good.  still isnt terribly intuitave (like, having a section for building, and a sectino for installing, and saying "main" and "main+universe)
[03:25] <Hobbsee> but good work :)
[03:26] <Fujitsu> Hobbsee: It shouldn't be difficult to do that. I'll have a look now.
[03:26] <Hobbsee> Fujitsu: cool :)
[03:37] <rexbron> Hobbsee: Do you have a free moment to review and upstream update in revu? The link is: http://revu.tauware.de/details.py?upid=5496 . Thanks!
[03:38] <jeromeg> anyone has an idea?
[03:39] <Hobbsee> rexbron: can you give a debdiff of the two versions please?
[03:39] <Hobbsee> rexbron: debdiff oldversioninarchive.dsc newversion.dsc > murrine.debdiff
[03:39] <rexbron> Sure, one second
[03:39] <Hobbsee> thanks
[03:44] <jussi01> Hobbsee: is there not a debdiff already on revu?
[03:44] <Hobbsee> jussi01: there's a diff
[03:44] <Hobbsee> oh wait, yeah
[03:45] <jussi01> :)
[03:45] <Hobbsee> forgot about that
[03:45] <rexbron> :)
[03:47] <Hobbsee> me too.
[03:48] <Hobbsee> the worst i've ever seen pbuilder do is segfault.  not explode.
[03:48] <StevenK> Blink!
[03:48] <StevenK> You've gotten pbuilder to segfault?
[03:48] <jussi01> lol
[03:48] <Hobbsee> StevenK: well, apt inside pbuilder.
[03:49] <StevenK> Ah
[03:49] <Hobbsee> (dapper)
[03:49] <elkbuntu> StevenK, you'd segfault too if you were hit with a long pointy stick of doom
[03:49] <StevenK> Heh
[03:49] <Hobbsee> hahahahah
[03:49] <jussi01> rofl
[03:49] <rexbron> oh my
[03:49] <StevenK> pbuilder is shell, I'd be very suprised if it segfaults
[03:49] <StevenK> elkbuntu: I'd probably dump core, too.
[03:50] <rexbron> us users can do things they never imaged possible. :)
[03:50] <elkbuntu> ... rofl
[03:50] <rexbron> err s/imaged/imagined/g
[03:50] <elkbuntu> StevenK, not to mention the memory leakage
[03:50] <StevenK> Heh
[03:50] <asac> StevenK: can we have a look at the configure patch you introduced to kover at some point?
[03:50] <Hobbsee> hiya asac 
[03:51] <asac> hi Hobbsee :)
[03:52] <asac> StevenK: you can still see it here: http://pastebin.mozilla.org/114322
[03:53] <asac> StevenK: point is that patching configure without configure.{in,ac} is bad (TM)
[03:53] <Hobbsee> asac: i believe there's a bug report about it failing to build.
[03:53] <Hobbsee> asac: or at least, it failed to build without that change
[03:53] <asac> might be ... however its not documented in changelog
[03:54] <asac> and it should be fixed in configure.in ... otherwise future merges will become a real pita
[03:54] <asac> StevenK: do you remember why we needed this?
[03:54] <StevenK> asac: Gimme a sec...
[03:54] <asac> sure
[03:54] <Hobbsee> rexbron: uploaded, thanks
[03:54] <rexbron> woot ty
[03:54] <rexbron> :D
[03:55] <Hobbsee> no problem :)
[03:55] <StevenK> asac: We need to drop -ansi from the CFLAGS otherwise it doesn't build due to ... something.
[03:55] <asac> yeah ... probably because of non-ansi compliance in c code
[03:55] <StevenK> In the kernel headers.
[03:55] <asac> however ... this should be done in configure.in
[03:56] <asac> and configure just be recreated with autoconf
[03:56] <StevenK> asac: I think I tried and autoconf told me what it thought.
[03:56] <asac> he?
[03:56] <StevenK> asac: I tried to patch configure.in/.ac and re-run autoconf and got no change in the configure script
[03:57] <asac> uh ... there must be something wrong then
[03:57] <StevenK> asac: But I don't know much about autoconf, so it could have been something I did.
[03:57] <StevenK> asac: It was a while ago. :-)
[03:57] <asac> ok ... StevenK can you try to readd that change?
[03:58] <asac> please try --std=c99 ... and if that fails try --std=gnu99
[03:58] <asac> in CFLAGS
[03:58] <StevenK> Instead of, or as well as -ansi?
[03:58] <asac> ah its just -std
[03:58] <StevenK> asac: It won't be until tomorrow, at this point. I'm about to upload 37 sources and go to bed soon after.
[03:59] <asac> instead of ... gcc(1) reveals that -ansi is a shorthand for
[03:59] <asac> -std=iso9899:1990
[03:59] <asac> or -std=c89
[03:59] <asac> StevenK: is -ansi mentioned in configure.ac?
[03:59] <asac> if so ... just try to drop it and see if it helps
[04:00] <StevenK> asac: *nod*
[04:00] <StevenK> I don't want to look at this point, I'm juggling eggs.
[04:00] <asac>  (looking at gcc(1)) if it doesn't use -std=gnu89 ... which appears to be -ansi + gnu extensions
[04:01] <asac> ... and should be closest to what upstream wnated
[04:01] <asac> StevenK: yeah ... just do when you feel better ;)
[04:01] <asac> StevenK: ... or just find out where it failed to build so we can document it ... i will push it to bluekuja then
[04:02] <asac> bug id would be great
[04:03] <StevenK> asac: Would you mind searching for it?
[04:04] <StevenK> asac: It's definetly submitted by me, and it's probably against linux-libc-dev
[04:04] <asac> i have no time to do that ... sorry
[04:04] <StevenK> Okay, I'll look at it later
[04:04] <asac> thanks
[04:37] <mruiz> ping dholbach 
[04:44] <dholbach> mruiz: pong
[04:45] <mruiz> dholbach, how is your car? :-)
[04:45] <dholbach> hehe, all sorted :)
[04:45] <dholbach> ready to go for the holidays
[04:45] <dholbach> http://daniel.holba.ch/car
[04:45] <dholbach> http://daniel.holba.ch/greece.png
[04:45] <dholbach> :-)
[04:46] <mruiz> I found the error (about the strange files)... upstream version included a debian directory with this files
[04:46] <dholbach> ahhhhh ok
[04:46] <dholbach> nevermind then
[04:46] <mruiz> I uploaded a new version for your review :-)
[04:46] <dholbach> as they are called package.post{inst,rm} they will not affect the package build anway
[04:46] <dholbach> they should be called <real package>.post{inst,rm}
[04:47] <dholbach> so they will be just ignored, which is good
[04:47] <dholbach> but great - I'll check it out and let you know
[04:47] <mruiz> I can't see any sticker "powered by ubuntu" on your car ;-)
[04:47] <dholbach> ... not yet - because those picture were done by the guy who owned it before
[04:47] <mruiz> mmmm
[04:48] <coNP> wow, is it the quickest or the shortest way? :D
[04:48] <dholbach> coNP: maybe not - we just wanted to make sure to see some spots on the way ;-)
[04:49] <dholbach> (oh and I have to drop my dog at my parents' place
[04:53] <xxxxx1> hello dholbach 
[04:54] <dholbach> hiya xxxxx1
[04:57] <dholbach> can somebody give http://revu.tauware.de/details.py?upid=5851 a second review?
[05:04] <norsetto> dholbach: Hi Daniel ... everything ok?
[05:04] <dholbach> norsetto: yep... how are you doing?
[05:04] <norsetto> dholbach: busy :-)
[05:05] <dholbach> I know what you're talking about :)
[05:05] <norsetto> dholbach: you do!?
[05:05] <dholbach> yeah, I should think so :)
[05:05] <norsetto> dholbach: want something more?:-D
[05:06] <dholbach> you finished some more packages? :)
[05:06] <norsetto> dholbach: of course: https://bugs.launchpad.net/ubuntu/+source/rt2500/+bug/113054 8-)
[05:06] <ubotu> Launchpad bug 113054 in rt2500 "rt2500 configuration tool missing .desktop file" [Wishlist,Confirmed]  
[05:06] <norsetto> dholbach: actually, I got two birds with a stone ......
[05:07] <dholbach> can you subscribe ubuntu-universe-sponsors to the bug? if it doesn't get done in time, I'll check it myself
[05:09] <norsetto> dholbach: done
[05:09] <dholbach> great, thanks
[05:09] <norsetto> dholbach: could you perhaps rise the importance? its a good workaround for another critical bug
[05:10] <norsetto> dholbach: this https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.22/+bug/118205
[05:10] <ubotu> Launchpad bug 118205 in linux-ubuntu-modules-2.6.22 "Gutsy kernel 2.6.22-7-generic missing rt61 module" [High,Incomplete]  
[05:11] <dholbach> ok
[05:13] <norsetto> dholbach: thanks, I will be adding a note to 118205
[05:53] <norsetto> dholbach: Daniel, any news about REVU (http://revu.tauware.de/details.py?upid=5851)? Who/how do we have to corrupt? I've got some tomato from my orchard which are just ripe.....
[05:54] <crimsun> I will look at that, norsetto, after I finish a merge.
[05:54] <crimsun> ETA 35 mins.
[05:55] <norsetto> crimsun: thanks, you want them green, half-green or red ;-)
[05:56] <crimsun> preferrably not overripe, and preferrably not all over my windows/laptop/face.
[05:56] <crimsun> :-)
[06:14] <dholbach> mruiz: I always use debdiff old.deb new.deb to make sure that files that move around still make sense
[06:14] <dholbach> so if you have a package that has several binary packages you want to make sure you find files that move across binary packages, so you can adjust conflicts and replaces
[06:14] <mok0> When I author man pages for a package, how should I specify the license?
[06:16] <ScottK> mok0: Up to you.  If it's the same as the debian packaging and the man page is in /debian, then you don't need to specify directly I don't think.
[06:16] <ScottK> In general it's simplest if you use one license throughout a package.
[06:16] <mok0> So not saying anything about license is OK
[06:20] <mruiz> dholbach: is possible, because upstream tarball increased at least 1MB between versions
[06:22] <dholbach> mruiz: there seem to be files missing
[06:28] <ScottK> mok0: If it's in the debian package the statement about licensing of the debian package in debian/copyright IS a statement about it's licensing.
[06:30] <ScottK> mok0: See my comment in Bug #118771
[06:30] <ubotu> Launchpad bug 118771 in Ubuntu Feisty "Syntax error in python module" [Low,Fix committed]  https://launchpad.net/bugs/118771
[06:32] <zakame> good evening
[06:35] <mruiz> dholbach: some files are missing because they changed its format: a lot of "gif" became "png"
[06:36] <geser> ScottK: did the patch for python-tclink work for you?
[06:37] <dholbach> mruiz: so you say everything's alright and nothing will break? :)
[06:38] <jekil> anyone can review please? http://revu.tauware.de/details.py?upid=5663
[06:39] <ScottK> geser: I didn't get a chance to fully test it (it built).  According to upstream (this was discussed on the Debian bug) your fix is a good one for a problem that is primarily a 64 bit problem.  
[06:39] <ScottK> geser: Debian has published an updated package.  I'm going to request a sync when I have a few minutes.
[06:42] <geser> good
[06:45] <asac> StevenK: can you ping me next time before you upload gnash?
[06:45] <ScottK> jekil: Did tablelist make it out of NEW and get published yet?
[06:45] <asac> StevenK: is it just a respin? otherwise please provide a bzr branch update for your changes
[06:45] <ScottK> asac: I think it was part of a mass fix-up due to libcurl excitement.
[06:46] <jekil> ScottK: yes
[06:46] <ScottK> OK.
[06:46] <ScottK> jekil: Your comment on the package sounds to me like the opposite.
[06:47] <jekil> ScottK: ops! sorry, not enough sleep ;) it's published
[06:47] <asac> ScottK: yeah anyway ... i need the fix in bzr :) ... if it involves more than a respin :)
[06:47] <asac> otherwise it will drown on next upload
[06:48] <geser> asac: the gnash upload is for the curl rebuild
[06:48] <asac> geser: i see that in changelog ... but were modifications needed? or just a version bump and respin?
[06:49] <geser> it's only to get the deps right (depend on libcurl3-* instead of libcurl4-*) and shouldn't include any changes besides the changelog
[06:50] <asac> StevenK: anyway, the bzr branch is here http://bazaar.launchpad.net/~ubuntu-core-dev/gnash/ubuntu ... please provide me with something so i can merge things in
[06:50] <asac> yeah ... that should have been documented in changelog then
[06:50] <mruiz> dholbach: I hope that. I will test it before.
[06:50] <asac> gnash is defacto in main now ... so please document properly
[07:00] <norsetto> time to go ...cheers daniel&daniel!
[07:04] <dholbach> mruiz: let me know when it's ok
[07:04] <mruiz> sure
[07:04] <mruiz> bye all
[07:08] <chillywilly> happy fourth to all americans :)
[07:24] <ScottK> chillywilly: Thanks.
[07:51] <coNP> StevenK: what is the proper syntax to close debian bugs in changelog?
[07:54] <dholbach> coNP: (Closes: #12345) AFAIK
[07:54] <coNP> okay, thanks 
[08:30] <bmm> Any MOTU: after a comment I can't seem to get working, I would love more comments on ccbuild: http://revu.tauware.de/details.py?upid=5856
[08:36] <coNP_> how can I sign my repository for pbuilder?
[08:38] <dholbach> see you tomorrow
[08:39] <ScottK> coNP_: Why would you need to?
[08:39] <coNP_> oh I guess I can do without that
[08:44] <coNP_> StevenK: I uploaded openbox and obconf to REVU (both intended for both debian & ubuntu), please review them
[09:01] <ScottK> geser: python-tclink sync requested.
[09:13] <zul> argh can this day go any slower
[09:13] <axxo> definitly
[09:51] <tsmithe> hi could someone review ubuntustudio-sounds for me? http://revu.tauware.de/details.py?upid=5860
[09:52] <tsmithe> i don't think i need to add anything to docs, considering the "resulting binary looks fine"
[09:52] <tsmithe> *dirs
[09:55] <luisbg> can please somebody look at tsmithe's?
[10:10] <ScottK> doko: Are we supporting Python 2.4 in Gutsy (I thought we were).  When I build a Python package just for 2.4, the buildds say, /bin/sh: python2.4: not found???
[10:12] <gnomefreak> ScottK: is it installed?
[10:12] <icf7> ScottK: gutsy has python 2.5
[10:12] <gnomefreak> if its in shlibs it would have to be installed
[10:12] <gnomefreak> icf7: 2.4 also
[10:14] <icf7> gnomefreak: Yes, when explicitely requiring the package python2.4
[10:14] <ScottK> gnomefreak and icf7: I was expecting support for multiple python versions in Gutsy.
[10:14] <gnomefreak> ScottK: thats a bit harder maybe add them both as depends?>
[10:15] <ScottK> The trick in this case is to build for 2.4, but not 2.5 as the functionality was included in 2.5, so the external package is extraeneous cruft for 2.5
[10:15] <gnomefreak> wondering if you can depen on python-all i believe that contains both interpreters
[10:16] <gnomefreak> ScottK: its a holiday easy questions please :(
[10:16] <gnomefreak> :P
[10:19] <gnomefreak> ScottK: maybe add python $(source:version) or something like that to beable to use on whatever is installed?
[10:19] <gnomefreak> source:version may not work but somethin gof the like
[10:20] <ScottK> It's already got a proper pyversions file that should cover that adequately.  
[10:21] <ScottK> Now that I think about it though, satisfydepends isn't going to look in there.  Thanks for the hint.
[10:22] <gnomefreak> yw 
[10:24] <geser> ScottK: if you need python2.4 on the buildds you need to add it to build-depends
[10:24] <ScottK> geser: Thanks.  I'm trying to figure a common Debian/Ubuntu solution where Debian has 2.4 as default and we have 2.5.
[10:26] <geser> python should depend on the current python versions
[10:32] <joejaxx> 3~/win 108
[10:32] <joejaxx> bah
[10:34] <mohammad> Hello, I have debianized an arabic font which I think is really needed in ubuntu. http://revu.tauware.de/details.py?upid=5880  would you please review it?
[10:40] <ScottK> mohammad: Version in debian/changelog should be 1.001-0ubuntu1.
[10:40] <ScottK> mohammad: Why do you specify PACKAGE_VERSION in debian/rules?  That shouldn't be necessary.
[10:42] <mohammad> ScottK: thank you I will fix them now
[10:42] <ScottK> mohammad: I'm not sure gnome is the right section for a font.
[10:42] <ScottK> I'd guess this works for kde too, right?
[10:42] <mohammad> ScottK: yes it works for kde as well
[10:42] <ScottK> mohammad: Two spaces before homepage in debian/control
[10:42] <ScottK> mohammad: I suggest a different section then.
[10:43] <ScottK> In debian/copyright it says "All Rights Reserved", when, in fact, all right's aren't reserved based on the license.
[10:44] <Q-FUNK> if it's a ttf font, section x11 might work best
[10:46] <ScottK> mohammad: Not sure if the license of the package is GPL compatible (I'm thinking not).  I'd recommend license your packaging under the same license as the underlying software.
[10:46] <ScottK> That's all I got on a quick review.
[10:48] <mohammad> ScottK: thank you I am fixing them :)
[10:48] <ScottK> OK.  No guarantee that's it.  I only took a quick look.
 mohammad: Version in debian/changelog should be 1.001-0ubuntu1. < and s/unstable/gutsy/
[10:51] <ScottK> Ah.  Yes, of course
[11:06] <mohammad> ScottK: I have applied all the comments. would you please take a look again? http://revu.tauware.de/details.py?upid=5883
[11:08] <tsmithe> ScottK, if you are reviewing, could you possibly take a look at ubuntustudio-sounds and ubuntustudio-look, both of which have had one advocate so far
[11:19] <DktrKranz> could you please have a look at http://revu.tauware.de/details.py?upid=5884? it's a new upstream version of php-interbase, recently readded to archives. thank you.
[11:21] <DktrKranz> np
[11:24] <mohammad> thank you ScottK, and Q-FUNK for giving me some comments :) see you later
[11:34] <ScottK> who wants to write a response to esr on the motu list that says "Mailing lists aren't bug trackers.  To file a bug ...."
[11:35] <tsmithe> ScottK, hahaha
[11:43] <tsmithe> wow ok