[00:15] <geser> wgrant: in case you missed it in #ubuntuwire: what about moving the superseded packages into their own tables at the end of the page?
[00:17] <ScottK> Personally I think it'd be fine to just remove them.
[00:25] <wgrant> geser: Hm, I did somehow miss that. That sounds like a good idea.
[00:46] <wgrant> geser, ScottK: How's that?
[00:47] <ScottK> wgrant: Well once the package has been superceded in the archive compared to the rebuild copy, the results of the rebuild are pretty irrelevant.  If it stiill FTBFS in the real archive, we have another page for that.
[00:48] <wgrant> ScottK: I still think it's a good idea to show them, but will remove them if there are enough votes.
[01:37] <lifeless> Hobbsee: ping
[02:23] <zooko> Good evening, folks!  (UTC-6)
[02:23] <zooko> Karmic is going to rock!
[03:16] <ScottK> wgrant: Moving to the bottom is fine with me (or clearly distiguishing most any way).  Thanks for putting the list together, it's very helpful.
[03:20] <wgrant> ScottK: Thank geser for the original code. This is just a rather hacked up version of that.
[03:20] <ScottK> OK.
[03:20] <ScottK> geser: Thanks for making it possible.
[03:52] <Hobbsee> lifeless: pong
[04:08] <lifeless> Hobbsee: nvm :)
[04:09] <lifeless> Hobbsee: was going to get you to wave your pointy stick at the buildds
[04:09] <Hobbsee> lifeless: oh, fair enough
[05:07] <alkisg> How is it decided that some Debian packages are left out of Ubuntu? E.g. http://packages.debian.org/sid/gzip-win32 ?
[05:07] <alkisg> Also, if I upload this package to my ppa, will I be able to compile another package (win32-loader) that depends on gzip-win32?
[05:08] <wgrant> alkisg: In this case it's probably because MinGW32 is in universe. gzip is in main, so can't build-depend on it.
[05:08] <wgrant> But the changelog will know for sure.
[05:09] <wgrant> Indeed, https://edge.launchpad.net/ubuntu/+source/gzip/+changelog
[05:09] <wgrant> And yes, if you remove the removal in your PPA you will be able to build-depend on it.
[05:10] <alkisg> wgrant: thanks, but I didn't quite understand this. Mings32 is in universe, right? Why can't gzip-win32 also be in universe? (and gzip, a seperate package, in main)?
[05:10] <wgrant> alkisg: The gzip-win32 binary is built from the gzip source package
[05:10] <alkisg> Ah... so it's policy reasons, to get it in main
[05:11] <wgrant> alkisg: Sources in universe cannot build binaries in main, and sources in main cannot depend on binaries in universe.
[05:11] <wgrant> Right.
[05:11] <alkisg> Got it. I didn't understand that it was the same source.
[05:11] <wgrant> Without gzip in main, things would be a little broken.
[05:12] <alkisg> wgrant, so, if I upload a modified gzip in my ppa, I'll be able to build win32-loader that depends on this, right?
[05:12] <wgrant> alkisg: Correct.
[05:12] <alkisg> Thank you very much :)
[05:13] <wgrant> np
[08:30] <alkisg> Is keyserver.ubuntu.com down?
[14:18] <quentusrex> Anyone know how to get a package to run a set of commands when the binary is installed?
[14:18] <quentusrex> build isn't it...
[14:21] <geser> you mean during package building or installing the the final deb?
[14:21] <quentusrex> installing the final deb
[14:22] <geser> {pre,postinst}
[14:22] <geser> depending on what needs to be done
[14:22] <quentusrex> I need to transcode some files..
[14:23] <quentusrex> I only distribute the high quality sounds, and it needs to transcode the lower quality ones locally....
[14:23] <geser> why that?
[14:23] <quentusrex> this way you only download 75MB of sounds
[14:23] <quentusrex> rather than 350MB
[14:24] <geser> why not do it during package build and build a binary with the high quality ones and one binary with the low quality ones?
[14:25] <quentusrex> I do that
[14:25] <quentusrex> so if you really want to download them, rather than locally transcode, that is possible
[14:25] <quentusrex> but the default dependancy package will transcode them on your box.
[14:26] <geser> what's the benefit of it instead of simply using the high quality ones?
[14:26] <quentusrex> transcoding on the fly is very cpu intensive...
[15:18] <eboyjr> Hello. gdesklets depends on python2.5, but it doesn't install with it, producing errors.
[15:21] <eboyjr> So maybe someone should fix that
[15:26] <RainCT> eboyjr: Seems to work fine with Python 2.6 on Karmic
[15:29] <eboyjr> Hrm. Okay. On Jaunty, in the source it has #!/usr/bin/python2.5 and I had to install it to make it work. Other people had the same problem. I'm glad it works in Karmic tho
[15:42] <RainCT> eboyjr: feel free to file a bug report (but I wouldn't put to much hope in getting it fixed in Jaunty)
[15:43] <eboyjr> RainCT: Alright I might if I have time. It's not something that can be quickly changed?
[15:47] <RainCT> eboyjr: probably yes, but changing stuff in stable releases requires a bit of extra paperwork (and approval from the Stable Release Updates team), and given that this problem is easy to workaround (installing python2.5) people will likely put their time into more important stuff
[15:48] <eboyjr> Alright that makes sense. I won't bother since there are HOWTOs. Karmic is coming up so early too. Time's flyin' Thanks RainCT
[15:49] <RainCT> no problem
[16:02] <zooko> Howdy RainCT.
[19:22] <fraser_m> For fixing a bug that's been reported in LP, what gets put in the changelog?
[19:23] <Laney> (LP: #xxxx)
[19:23] <fraser_m> Thanks.
[20:52] <hanska> hello people
[20:52] <hanska> do you know whether Michael Vogt is on IRC?
[20:53] <sebner> hanska: huhu, his username is mvo
[20:53] <hanska> hey sebner :)
[20:53] <sebner> hanska: but it's sunday. try again tomorrow ^^
[21:27] <hanska> sebner: sorry, my ADSL went down :) -- ok, will try tomorrow, just need to talk to him about gdebi ;)
[21:34] <dtchen> ajmitch: when you have time, please use "ubuntu-bug alsa-base" for your new laptop if you haven't already
[21:40] <Zhenech> hyperair, any idea how to tell geany to use a different default licence?
[21:46] <ajmitch> dtchen: sure, just starting it up now - I had problems with ubuntu-bug not starting firefox last week
[22:32] <dtchen> ajmitch: ok, thanks. i'm trying to break up the commits to sound/pci/hda/patch_* into logical, digestable bits so that Tim or Andy doesn't punch me (i.e., need the BugLink)
[22:33] <dtchen> jdstrand: updated my branch for your audio issue; please confirm whether it fixes your symptom
[22:33] <ajmitch> dtchen: ok, I'm just filing it now
[22:34] <ajmitch> dtchen: bug 433683 - tell me if you need anything else
[22:34] <dtchen> ajmitch: if you want to do it manually, the only file(s) i really need is /proc/asound/card*/codec*
[22:34] <dtchen> ok
[22:48] <dtchen> ajmitch: yeah, your headphone jack is actually registered as a line-out (boo, IDT!), which we don't currently do any sort of sensing with
[22:49] <dtchen> ajmitch: the last commit i made to the branch for jdstrand's bug is part one of the two required fixes for you; i'm committing yours in about ten minutes
[22:49] <dtchen> ajmitch: (if you look at your Card0.Codecs.codec.0.txt, it's node 0x0f)
[23:03] <ajmitch> dtchen: alright, I'll grab the branch you commit & try & build it
[23:04]  * ajmitch just had to run off for a quick meeting 
[23:04] <dtchen> ajmitch: pushed, should be available now
[23:04] <dtchen> bah, it ended up in jdstrand's branch, but whatever
[23:05] <ajmitch> do you have the URL for it?
[23:06] <ajmitch> nevermind, I see a commit now
[23:08] <dtchen> yeah, added a comment in the bug report, too
[23:09] <dtchen> -> offline
[23:10] <ajmitch> thanks, building now
[23:48] <lifeless> requestsync hates me
[23:52] <Laney> lifeless: please file/fix bugs if there are any