[00:07] <Amaranth> pwnguin: I think you just add the appropriate tags to that bug
=== Huahua is now known as Shely
[00:44]  * Hobbsee waves
[00:49] <ion_> sinewaves
[00:49]  * Hobbsee sends tan waves back
=== cheguevara_ is now known as CheGuevara
=== bigon is now known as bigon`
=== fifoi is now known as CheGuevara
[05:17] <Romes> er... yeah.... this might be a bit off topic, so don't feel obligated to respond...
[05:18] <Romes> I just ventured in here to say thanks for all the hard work! I'm new to Ubuntu (and linux in general), and I can only imagine the scale of projects like this... so... thanks!!!
[05:19] <Romes> oh, and keep up the good work ;)
[05:38] <StratPlayedBlue> anyone know anything about getting things to compile with SSP?
[05:43] <StratPlayedBlue> what a good channel to get some programming help? i've got a problem compiling something i wrote with stack overflow protection
[05:46] <elkbuntu> StratPlayedBlue, many popular languages have a channel on freenode (eg, ##c, #python)
[05:48] <StratPlayedBlue> elkbuntu: yeah i've asked in ##c but it's actually a pam module i wrote complaining about missing symbol __stack_chk_fail_local
[05:49] <Burgundavia> StratPlayedBlue: there is an Ubuntu hardened mailing list
[05:49] <joejaxx> Burgundavia: not very active :P
[05:49] <StratPlayedBlue> lol
[05:50] <joejaxx> but i would post anyway
[05:52] <StratPlayedBlue> i wonder if there is a #pam-module-has-missing-ssp-symbol channel
[05:53] <joejaxx> :)
=== \sh_away is now known as \sh
=== \sh is now known as \sh_away
=== \sh_away is now known as \sh
[11:24] <Hobbsee> so quiet....
[11:25] <stgraber> and it'll be so noisy next week :)
[11:25] <Hobbsee> hehe
[11:25] <Hobbsee> that'll be fun
[11:26] <afflux> what's next week?
[11:26] <Hobbsee> people are back
[11:26] <Hobbsee> or at least, after tuesday
[11:26] <afflux> ah, see.
[11:26] <stgraber> everyone coming back from holiday with tons of bugs :)
[11:28] <stgraber> and lots of updates (as soon as the buildds start working again)
[11:28] <\sh> hey Hobbsee :)
[11:28] <Hobbsee> yeah well
[11:28] <Hobbsee> would be nice to get teh buildds fixed
[11:28] <Hobbsee> heya \sh!
=== dfiloni_ is now known as dfiloni
[11:29] <\sh> did anybody see the same strange things I have with my pbuilder? error messages because of the mount options of /var and some errors during update after libc6 tries to setup?
[11:30] <elmo> what's wrong with the buildds?
[11:31] <stgraber> E: Internal Error, Could not perform immediate configuration (2) on libstdc++6
[11:31] <Hobbsee> elmo: check any recent build for hardy
[11:31] <afflux> \sh: I just updated my hardy pbuilder, it looks good.
[11:31] <elmo> is that not just a package problem?
[11:32] <elmo> AFAIK that indicates an unresolvable depends or pre-depends cycle
[11:32] <\sh> afflux: try to create a new one ;)
[11:32] <Kmos> and palmer is not available..
[11:32] <\sh> afflux: on hardy that is..
[11:32] <elmo> palmer is not available until someone fixes ebug-http
[11:32] <elmo> (or someone tells me LP magic to make sure ebug-http isn't retried)
[11:33] <Hobbsee> <Fujitsu> +There's also a new tzdata which apt isn't smart enough to get, so the following will sort the chroots out `apt-get install libc6 tzdata && apt-get dist-upgrade'
[11:33] <Hobbsee> elmo: can you kill it from teh archive theN/
[11:33] <Hobbsee> urgh, caps.
[11:33]  * Fujitsu appears.
[11:33] <elmo> I could fix the chroots but is there no core-dev around to fix the archive?  I kinda think apt-get dist-upgrade should just work
[11:34] <Hobbsee> elmo: no one else, apart from \sh, appears to have reproduced the error.
[11:34] <Fujitsu> elmo: I can't work out why it won't work, but installing libc6 manually resolves it all.
[11:34] <Hobbsee> on a normal system, it's not breaking.
[11:34] <Fujitsu> And I've only seen it in the buildd chroots.
[11:34] <\sh> Fujitsu: I had it on my chroots on this emt64 system too, during update
[11:34] <persia> elmo: An updated libc can't be built to fix the problem, because libc doesn't work.
[11:34] <Fujitsu> persia: That too.
[11:34] <Fujitsu> \sh: Hmmm...
[11:35] <\sh> creating a new chroot won't work because of some strange "/dev/null is not existing" and "/var is mounted noexec,nodev" foo bar
[11:35] <\sh> I'll downgraded to gutsy and have to recreate everything from scratch and check again after upgrade to hardy
[11:36] <elmo> let me grab the buildd chroot and see if I can reproduce it locally
[11:36] <elmo> is there a bug on libc6 about it yet?
[11:36] <Fujitsu> I don't think it's a libc6 bug.
[11:36] <persia> elmo: It seems only to affect the buildds: non-buildd chroots haven't shown the error.
[11:36] <Fujitsu> I've played around with the buildd chroot, but can't work out what apt thinks it's doing.
[11:36] <Fujitsu> persia: \sh says otherwise.
[11:36] <\sh> persia: I#m not having any buildd style chroots here
[11:37] <Fujitsu> \sh: How out of date was the chroot you tried to upgrade?
[11:37] <persia> \sh: And you get "E: Internal Error, Could not perform immediate configuration (2) on libstdc++6".  Interesting.  I thought you were having the debootstrap issue.
[11:37] <\sh> Fujitsu: 2 days ... I killed everything yesterday night
[11:38] <Fujitsu> That's strange, as I did a very similar upgrade to my hardy sbuild chroot this morning, and it worked fine.
[11:38] <\sh> persia: I got two issues...first during update...with libc6...it complains about "libc6 not being part of dpkg installed bla"...
[11:38] <\sh> persia: second is trying to create a new chroot..which failes because of some strange behaviour of "/var being mounted noexec,nodev" ...
[11:39] <persia> \sh: That sounds slightly different to me, but maybe it's the same issue.
[11:39] <\sh> but I always think it's me or my machine which gives me a bad time..so I'm trying to reproduce it
[11:39] <\sh> most of the time the problem of the issue is sitting in front of the screen
[11:40] <\sh> osi layer 9 ,-)
[11:40] <Fujitsu> IIRC, (at least on i386) it happens because the new libstdc++6 wants lib64gcc1, which wants libc6-amd64, which wants the new libc6, which apt doesn't decide to install before it tries to install the rest. Installing libc6 manually and dist-upgrading works flawlessly.
[11:41] <Fujitsu> I'm not sure why apt decides to do what it does, though
[11:41] <Hobbsee> sounds like X, just with shorter names.
[11:41] <\sh> Fujitsu: hmm...why does apt want to install 64bit stuff on i386?
[11:42] <Fujitsu> \sh: Because libstdc++6 wants it.
[11:42] <\sh> bah...easter egg xmas present...
[11:44] <\sh> looks like it's the time  of the year where someone needs to buy new toys like nokia 6500 classic ,-)
[11:44] <elmo> ok, it's trivially reproducable with the buildd chroots
[11:45] <Fujitsu> Right, I think a number of us have downloaded the tarball and reproduced it.
[11:45] <Fujitsu> elmo: I think you want bug #165041 for that ebug-http thing.
[11:45] <ubotu> Launchpad bug 165041 in soyuz "Please allow manually marking packages 'failed'" [Undecided,New] https://launchpad.net/bugs/165041
[11:46] <Hobbsee> Fujitsu: file a bug saying "please implement cancelling builds" too
[11:46] <elmo> Fujitsu: well, the buildd chroot isn't special, except in terms of versions
[11:46] <Fujitsu> Hobbsee: It's there.
[11:46] <Hobbsee> Fujitsu: ahh
[11:46] <Hobbsee> Fujitsu: it hasn't loaded for me yet.
[11:46] <elmo> Fujitsu: right?  I guess I'm confused by y'all saying it's specific to buildds
[11:46] <Fujitsu> Hobbsee: No, not that bug. There's another bug for that.
[11:46] <Hobbsee> ahh
[11:46] <elmo> if we can agree it isn't, and get a bug filed on libc6, I can look at "fixing" the chroots
[11:47] <Fujitsu> elmo: I said I've only been able to reproduce it in the i386 buildd chroot, but most hardy systems and chroots seem to have upgraded through that without an issue.
[11:47] <Fujitsu> It could well apply to other system.s
[11:47] <Fujitsu> But the buildds are likely to be special, in that they're not upgraded frequently.
[11:48] <elmo> yikes
[11:48] <Fujitsu> ?
[11:48] <elmo> apt-get install libc6 without tzdata wants to pullout both tzdata and util-linux
[11:48] <Fujitsu> Right, because it conflicts with tzdata << whatever-2
[11:48] <Fujitsu> And apt is dumb.
[11:48] <Fujitsu> (the dist-upgrade still doesn't work even with just the new tzdata)
[11:49] <elmo> no, apt's not dumb
[11:49] <elmo> it's working as documented
[11:49] <\sh> Fujitsu: don't say this...it could be used against us ,-)
[11:49] <elmo> whoever put the conflicts into libc6 was ... misguided
[11:49] <Fujitsu> elmo: It's in Debian...
[11:50] <Fujitsu> Debian bug #455783
[11:50] <ubotu> Debian bug 455783 in libc6 "Script tzdata.postinst fails: /usr/bin/tzconfig not found" [Important,Fixed] http://bugs.debian.org/455783
[11:50] <Fujitsu> I thought it a bit odd too, but it seems to work most of the time.
[11:52] <elmo> conflicts has special meanings for essential packages, even virtually essential ones
[11:52] <Fujitsu> Oh dear.
[11:54] <Fujitsu> Even so, that's not the main cause of the failure.
[11:57] <elmo> yeah it is?
[11:57] <elmo> at least from my reading of debug::pkgorderlist=1
[11:58] <Fujitsu> Is it? Installing tzdata doesn't resolve the dist-upgrade issue.
[11:58] <Fujitsu> Or is it being extra-special even when it's not conflicting?
[11:59] <elmo> hmm
[12:07] <Fujitsu> elmo: Note that hackishly adding to libstdc++6 a pre-depends on the new libc6 convinces it to work, for some odd reason.
=== asac_ is now known as asac
[12:18] <elmo> yeah, ok, I give up, there does seem to be some element of a possible apt bug here - I'll start figuring out how to upgrade the chroots
[12:19] <elmo> can anyone else mass give back stuff, or do I need to do that too?  (not sure if there's a web ui for it yet - or if anyone else is around)
[12:19] <Fujitsu> elmo: No web UI.
[12:19] <elmo> k
[12:19] <Fujitsu> AFAIK a sysadmin or DBA has to do it.
[12:21] <Kmos> I think i've fixed the ebug-http =)
[12:22] <geser> or a click marathon
[12:23] <elmo> Current default timezone: 'Africa/Abidjan'
[12:23] <elmo> hmm
[12:24] <Fujitsu> Hah.
[12:25]  * Fujitsu missed that when he upgraded it.
[12:34] <Kmos> http://launchpadlibrarian.net/11082313/ebug-http_0.31-1ubuntu1.debdiff
[12:34] <Kmos> can someone check this one ?
[12:34] <Kmos> Trying patch debian/patches/win32_ftbfs.patch at level 1 ... 0 ... 2 ... failure.
[12:34] <Kmos> ups
[12:36] <Hobbsee> ...
[12:37] <Fujitsu> Better that it fails to build than hangs, I guess.
[12:37] <Kmos> :)
[12:37] <Kmos> i'm fixing it
[12:37] <Hobbsee> Kmos: you asked that over 2 channels, before even testing the patch?
[12:38] <Kmos> Hobbsee: the patch works.. the patch system is not working
[12:38] <persia> Kmos: The patch may work: the debdiff doesn't work.
[12:38] <Kmos> persia: i'm fixing it .. sorry
[12:48] <elmo> ok, i386 is building again
[12:49] <persia> elmo: Thank you
[12:49] <elmo> doing at least amd64 too, the others may have to wait for a real buildd admin, unless anyone's particularly bothered
[12:49] <Fujitsu> elmo: Thankyou muchly.
[12:50] <Fujitsu> Is there any other real buildd admin than Adam?
[12:51] <elmo> Fujitsu: nope
[12:51] <elmo> Fujitsu: (there are others who can do what I've just done, but it's really Adam who should be doing it)
[12:51] <Fujitsu> That's what I thought.
[12:52] <Fujitsu> (although I thought there were three others...)
[12:52] <Kmos> how about a mass give back ?
[12:52] <Fujitsu> Erm, I misread, oops.
[12:53] <elmo> Kmos: done for i386
[12:53] <Fujitsu> We're not too far behind, fortunately.
[12:53] <Kmos> elmo: thanks
[12:53] <Fujitsu> Though with palmer gone...
[12:53] <elmo> Fujitsu: so, there are plenty of folks who can do give backs and 'buildd admin'y stuff, but Adam's the one who does and should be doing chroot management
[12:53] <elmo> Fujitsu: you still have 2 i386 buildds :-P
[12:53] <Fujitsu> Yep.
[12:54] <Fujitsu> Hopefully Kmos' ebug-http fix will work.
[12:54] <Fujitsu> Then we can hopefully poke somebody to cancel that build..
[12:54] <Kmos> the ebug-http is really strange.. some perl god here ?
[12:54] <Kmos> if ($^O !~ /mswin32/i) { requires Test::Expect => 0;
[12:54] <Kmos> }
[12:55] <Fujitsu> elmo: Could you perhaps cancel it and throw the build score to something tiny, and hope that queue-builder doesn't reset it before the rest build?
[12:55] <Kmos> this is for win32, and it's where it breaks.. i made a patch for it, to remove it.. but now it breaks in some testing
[12:55] <Fujitsu> Kmos: !~
[12:55] <Kmos> Fujitsu: that's the code in Makefile.PL
[12:56] <Kmos> and it's not working
[12:56] <Fujitsu> Kmos: Yes. So it's likely *not* for win32.
[12:56] <Kmos> ah.. not for win32
[12:56] <Kmos> != is really more easy =)
[12:57] <Fujitsu> !~ != != :P
[12:57] <ubotu> Sorry, I don't know anything about p - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[12:58] <Fujitsu> elmo: Were PPA builds also given back?
[12:58] <elmo> Fujitsu: cprov's working on that now, we don't have a script for it, so he's having to giddy-up
[12:58] <Fujitsu> Aha. Funl
[12:58] <Fujitsu> *Fun.
[12:58] <DktrKranz> Fujitsu, PPAs have been given-back
[13:00] <elmo> ok, cprov's "fixed" ebug-http not to build again, so you now have palmer back too
[13:01] <Fujitsu> Thanks.
[13:01] <Fujitsu> Thankyou cprov.
[13:01] <cprov> Fujitsu: you are welcome.
[13:03] <elmo> ok, amd64 also done
=== Kmos changed the topic of #ubuntu-devel to: Archive: OPEN | Hardy Alpha 2 released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
[13:06] <Fujitsu> cprov: That was a rather good way to kill that build.
[13:07] <cprov> Fujitsu: it's the only way we have atm :(
[13:08] <Hobbsee> what, ripping otu the build system?
[13:12] <Fujitsu> cprov: I note that the given-back PPA build records didn't have the data from the previous build erased. Is that normal?
[13:13] <cprov> Fujitsu: they will be cleaned when they get dispatched
[13:14] <Fujitsu> OK, I just thought there might have been an important reason that normal give-backs cleared it all.
=== bigon` is now known as bigon
[13:16] <elmo> as an xmas special - lpia also done (although it doesn't appear to have any to give back...)
[13:16] <Fujitsu> I don't believe it had the problem, did it?
[13:16] <elmo> _well_
[13:16] <Fujitsu> Only the main 4 did, as far as I could see.
[13:16] <elmo> Fujitsu: I didn't actually check ;-)  oh well, lpia now has a fresher chroot *shrug*
[13:17] <Fujitsu> That's good too.
[13:17] <geser> http://qa.ubuntuwire.com/ftbfs/ reports only chroot problems for i386, amd64, sparc and powerpc
[13:17] <Fujitsu> elmo: Thanks again.
[13:21] <elmo> Fujitsu: np, sorry it took so long to respond
[13:21] <Fujitsu> What alerted you to it?
[13:22] <elmo> Hobbsee in #c-s, initially
[13:22] <Hobbsee> oh wow, i didnt' think that worked
[13:30] <geser> why does libstdc++6 now need both 32bit and 64bit libc installed?
[13:30] <Fujitsu> geser: I was questioning that this morning.
[13:31] <asac> hi!
[13:32] <geser> Hi asac
[13:32] <Fujitsu> Hey asac.
[13:33] <asac> Hobbsee: do you have NEW power? ... if so, could you bin NEW nss so we can upload xul+ffox 3.0 beta2?
[13:33] <Fujitsu> Has it actually built?
[13:33] <asac> afaik yes
[13:33] <asac> https://edge.launchpad.net/ubuntu/+source/nss/3.12.0~1.9b2+nobinonly-0ubuntu1
[13:34] <persia> https://launchpad.net/ubuntu/hardy/+queue?queue_state=0&queue_text=nss is also a nice link to show that
[13:34] <Hobbsee> asac: main or universe?
[13:34] <asac> oh ... its main :(
[13:34] <Hobbsee> bugger.  i was hoping you'd say universe.
[13:35] <Hobbsee> asac: i can, but i'd really prefer not to
[13:35] <asac> ok :)
=== cprov is now known as cprov-out
=== \sh is now known as \sh_away
=== asac_ is now known as asac
=== StevenK_ is now known as StevenK
=== chand is now known as chand[aw]
=== Martinp24 is now known as Martinp23
=== luka74 is now known as Lure
=== nicolai_ is now known as Kopfgeldjaeger
[17:00] <dasKreech> sabdfl: can I message you?
=== dasKreech_ is now known as dasKreech
[17:46] <RzR> hi there
[17:47] <dasKreech> hi
[17:47] <RzR> hi, is quilt encouraged in ubuntu package management ?
[17:47] <Kmos> RzR: ask in #ubuntu-motu
[17:47] <RzR> sure
=== smurf is now known as locovotebot
=== locovotebot is now known as smurf
[18:17]  * ogra_cmpc wonders if anyone has ever seen the case that in initramfs nothing in /sbin is executable (actually the error is "file not found" even though the binaries are all there ... i.e. depmod and modprobe) but eveything in /bin works just fine
[18:18] <psusi> nope
[18:19] <jbailey> ogra_cmpc: Make sure your linker got copied in.
[18:19] <ogra_cmpc> hmm
[18:20] <jbailey> If you don't happen to have readelf handy, less should show the name of the linker in the first page or so as an embedded ASCIIZ string.
[18:20] <ogra_cmpc> jbailey: well, its a freshly installed hardy .... only the originally installed initramfs works, all upqraded or newly created ones dont ... i'll check for read4elf
[18:21] <jbailey> readelf is not going to be in the initramfs.
[18:21] <jbailey> But if you're on a running systems with binutils installed, you'll have it.
[18:21] <ogra_cmpc> yep, its there
[18:27] <jbailey> ogra_cmpc: And the linker is executable?
=== psusi_ is now known as psusi
[18:28] <ogra_cmpc> you mean ld ?
[18:28] <jbailey> ld.so or klibc.so-blahblahblabh
[18:28] <jbailey> A file not found when executing a binary is almost always a dynamic linker problem.
[18:28] <ogra_cmpc> i get a proper output on teh system at least ... i cant boot into teh broken initramfs atm
[18:29] <jbailey> Can't use ldd to tell, it'll use the system paths.
[18:30] <ogra_cmpc> ogra@ceron:~/initramfs$ ls -l lib/klibc*
[18:30] <ogra_cmpc> -rwxr-xr-x 1 ogra ogra 64612 2007-12-28 20:03 lib/klibc-B9LS-Gjx2D7BYcbQig0RlgHKO9Y.so
[18:30] <ogra_cmpc> looks ok to me
[18:31] <jbailey> readelf -a sbin/modprobe |grep interpret
[18:31] <ogra_cmpc> ogra@ceron:~/initramfs$ readelf -a sbin/modprobe |grep interpret
[18:31] <ogra_cmpc>       [Requesting program interpreter: /lib/ld-linux.so.2]
[18:31] <ogra_cmpc> aha
[18:31] <ogra_cmpc> hmm
[18:31] <jbailey> 'k, so now ls -l lib/ld-linux.so.2
=== Kopfgeldjaeger is now known as You_have
[18:32] <ogra_cmpc> ogra@ceron:~/initramfs$  ls -l lib/ld-linux.so.2
[18:32] <ogra_cmpc> ls: lib/ld-linux.so.2: No such file or directory
[18:32] <jbailey> Bingo
[18:32] <ogra_cmpc> i bet that should be a link to klibc-*
[18:32] <jbailey> No.
=== You_have is now known as Kopfgeldjaeger
[18:32] <jbailey> The initramfs contrains two C libraries, sadly.
[18:32] <ogra_cmpc> oh, ok
[18:33] <jbailey> It was something I wasn't able to resolve while I was working on it.
[18:33] <jbailey> But the important question is to figure out why mkinitramfs didn't copy in the glibc bits that are needed.
[18:33] <ogra_cmpc> it does in a freshly created ltsp chroot .... must be my install
[18:34] <jbailey> Certainly, but this is a critical enough bit of infrastructure that whatever failed needs to have error handling and then send naked people across your screen with the errors tattooed on their bodies to make sure that you know it failed and don't reboot until it's fixed.
[18:35] <jbailey> ogra_cmpc: How 'bout this...  Is your /boot full?
[18:35] <ogra_cmpc> /dev/sda1              92M   45M   43M  51% /boot
[18:35] <ogra_cmpc> nopoe
[18:36] <ogra_cmpc> note that this install is manually bootsrapped on a raid0 ,,, i might have missed something
[18:37] <jbailey> I'm certain you have.  My point is that this operation needs to be resilient against any possible mistake you could make.
[18:38] <jbailey> Users will do all sorts of things that they should never do.  But the punnishment should never be that they can't boot again - which is a possibility with initramfs' that get overwritten.
[18:38] <zul> hey jbailey merry christmas
[18:38] <jbailey> Heya Chuck!  Happy new year?  /msg zul How's the munchkin?
[18:38] <jbailey> Err.
[18:38] <jbailey> zul: Consider that /msg'd =)
=== kitterma is now known as ScottK2
[19:59] <abarbaccia> hello all - the lirc package in ubuntu gutsy is broken for all transmitters
[19:59] <abarbaccia> how can i find the maintainer to repackage?
[20:02] <pochu> abarbaccia: best is to file a bug in launchpad: https://bugs.launchpad.net/ubuntu/+source/lirc
[20:02] <abarbaccia> pochu: I'm not sure what package it is exactly. I believe its acutally the lirc-modules-`uname -r` packages...
[20:02] <abarbaccia> so should i post to that or jsut to lirc
[20:05] <pochu> lirc is the source package of lirc-modules-source, so go for it.
[20:05] <pochu> But first check for dups
[20:05] <Ubulette> anyone got similar glib issues as bug 179119 ?
[20:05] <ubotu> Launchpad bug 179119 in glib2.0 "glib 2.15 not clean with -pedantic" [Undecided,New] https://launchpad.net/bugs/179119
=== nicolai_ is now known as Kopfgeldjaeger
[20:06] <Ubulette> oops, meant for -desktop
[20:10] <abarbaccia> pochu: thanks, i found a few people reporting that it doesn't work but with no clue on the solution. So i'm opening a new ticket with a better problem description. Thanks again.
[20:15] <pochu> abarbaccia: why don't you just edit the description of one of those bugs? Or add a comment. And dup the rest.
[20:20] <abarbaccia> pochu: im new to the system. sorry. I'll try to dupe the rest on the new bug I added
=== nicolai_ is now known as Kopfgeldjaeger
[21:41] <dmb_> is there a guide on howto set up your own local apt repository?
[21:41] <dmb_> i suppose http://www.debian-administration.org/articles/286 works, but is there anything ubuntu specific?
[21:54] <mjj29> dmb_: works the same for both
[21:54] <dmb_> mjj29: yeh, seems to work as well
[21:54] <dmb_> mjj29: i was just a little dee dee dee for a second
[21:54] <mjj29> I'm using debarchiver
[21:55] <dmb_> which is the one the official ubuntu repo's use?
[21:55] <mjj29> well the official debian ones use dak
[21:55] <jpatrick> can someone here giveback kmplayer? Now that the builds are fixed
[21:55] <mjj29> the description of which says 'if you don't have 10000 packages, use something else'
[21:56] <dmb_> mjj29: does the ubuntu one use the same?
[21:56] <mjj29> pass
[21:56] <mjj29> I assume so
[21:56] <mjj29> dunno what ppa uses
[21:57] <azeem> Ubuntu uses soyuz I thought
[21:57] <mjj29> azeem: google is quiet on the subject
[21:58] <mjj29> ah, I see
[21:58] <mjj29> fair enough
[21:58] <dmb_> theres so many :D
[21:59] <mjj29> The Future will apparently be DeBaBaRaReReReReReReRe tools
[21:59] <mjj29> so debian planet tells me
[22:02] <dmb_> :D
[22:23] <imbrandon> dmb_: falcon ( http://falcon.kaarsemaker.net/ ) also makes short work of it too
[22:23] <imbrandon> and is quite nice
[22:27] <dmb_> mmm
=== dmb_ is now known as dmb
=== luk__ is now known as luk