[12:02] <ogra> night mvo
[12:18] <lamont> daniels: if I rebuild xaw3d, then I get no libXaw3d.so.6.1 (as of early july, it appears) - is that expected?
[01:01] <Robot101> jbailey: ping
[01:02] <Robot101> jbailey: why is mdrun not used in the initrds to assemble /'s md by UUID instead of device name?
[01:05] <jbailey> Robot101: ...
[01:05] <jbailey> Robot101: I do use mdrun in the initramfs...
[01:06] <jdub> you may use it man, but do you UUUUUUSE it... maaaan?
[01:06] <jbailey> jdub: Aren't you supposed to be asleep?
[01:06] <Robot101> jbailey: oh... I was looking through p.u.c/~scott/patches/initrd-tools... but you've completely ditched mkinitrd?
[01:06] <lifeless> jbailey: its 9am
[01:06] <jdub> it's 9am!
[01:06] <jdub> not that i actually went to sleep at all
[01:06] <jbailey> Robot101: Right. =)
[01:06] <jdub> regardless
[01:07] <jdub> it's 9am!
[01:07] <jbailey> Robot101: Seeking testers for the stuff before I upload it to Debian, but I think I might just start doing it.
[01:07] <Robot101> jbailey: I'll give it a whirl now
[01:07] <jbailey> jdub, lifeless: It's 9am on a *Saturday*
[01:07] <jdub> SMELLY CANADIAN!
[01:07] <jdub> BACK IN YOUR BOX!
[01:07] <Robot101> jbailey: I can't switch from my own kernel to a stock kernel because mine uses /dev/hdX for my SATA, the stock uses /dev/sdX
[01:07] <jbailey> Only because I've been hauling boxes.
[01:08] <jbailey> Robot101: And you have a dislike of using SCSI device names? =)
[01:08] <Robot101> jbailey: no, the stock uses libata for my VIA SATA, and my kernel config predates libata and I never changed it yet
[01:08] <jbailey> Ah. =)
[01:08] <jbailey> So something that'll need to change eventually, just not right now.
[01:09] <Robot101> now I'm bored of compiling kernels, and I certainly don't want to have to hand-compile a kernel that uses libata soley so that mkinitrd can write the correct devices into /script
[01:09] <jbailey> Oh, I see. =)
[01:09] <jbailey> Yeah, mkinitrd sucks for a number of reasons.
[01:09] <Robot101> how much will I need to pull from breezy to make this go?
[01:10] <jbailey> Gimme a sec, I'll see what I can assemble for you.
[01:10] <Robot101> will it work with a stock debian kernel or do I need ubuntu's?
[01:10] <jbailey> It occured to me that there isn't a suitable busybox in Debian. =(
[01:10] <jbailey> Pretty much any kernel should do.
[01:10] <Robot101> I've got breezy in sources.list
[01:10] <Robot101> I'll throw a few things in and see what happens :)
[01:10] <jbailey> klibc, busybox-cvs and initramfs-tools then
[01:11] <Robot101> jbailey: what other stuff does mkinitramfs do that mkinitrd doesn't? some udev funk and acpi...?
[01:12] <tseng> jdub: are you coming to philly yet?
[01:12] <jbailey> I think the only thing it does that mkinitrd doesn't is easy nfsroot.
[01:12] <jbailey> Aside from that, it's just a much cleaner design.
[01:13] <Robot101> I was having fun picking apart exactly what this initrd did
[01:13] <Robot101> I had to scp it to my laptop because of course, my hand-rolled kernel on my desktop doesn't have cramfs either
[01:13] <Robot101> :)
[01:14] <jdub> tseng: you going to pitch for it? :)
[01:14] <jbailey> cramfs is teh suck too.
[01:16] <tseng> jdub: dunno, im not really in philly proper
[01:16] <tseng> jdub: hannah is?
[01:17] <Robot101> jbailey: how do I get this going then, just mkinitramfs -o /boot/initrd.img-2.6.12-1-k7 and give it a go?
[01:18] <jbailey> Robot101: Basically, yup
[01:19] <jbailey> You might not want to overwrite your working config. =)
[01:20] <Robot101> well this is the point, initrd.img-2.6.12-1-k7 *doesn't* work :)
[01:20] <jbailey> ;)
[01:20] <Robot101> Kernel version too old.  initramfs-tools requires at least 2.6.12.
[01:20] <Robot101> egg... chicken...
[01:20] <jbailey> Err. 2.6.12-1-k7 *is* 2.6.12...
[01:21] <Robot101> yes but that's the kernel I'm trying to get working, not the one I'm running :D
[01:21] <jbailey> Can you please check to see how you're tripping the version check?
[01:21] <jbailey> It shouldn't be checking the running kernel.
[01:21] <jbailey> Oh!
[01:21] <jbailey> I see.
[01:21] <jbailey> You didn't pass it a verison number.
[01:21] <jbailey> That would be bad.
[01:21] <jbailey> mkinitramfs -o /boot/initrd.img-2.6.12-1-k7 2.6.12-1-k7
[01:21] <jbailey> It doesn't attempt to parse your output filename, it assumes you want the running kernel version.
[01:22] <Robot101> trundle trundle...
[01:24] <Robot101> well that's a bit of an arse
[01:24] <Robot101> it loaded the right module which has just wedged
[01:24] <Robot101> sata_via... tum ti tum
[01:25] <Robot101> then ata1: dev 0 ATA, max UDMA/133, 160086528 sectors
[01:25] <Robot101> and then locked up
[01:26] <Robot101> jbailey: rock, it worked!
[01:29] <Robot101> jbailey: aha, /dev/pts isn't mounted
[01:30] <Robot101> jbailey: is that usually in fstab on ubuntu?
[01:30] <Robot101> hmm... no...
[01:32] <jbailey> Umm, I think udev might mount that?
[01:33] <jbailey> No, mountvirtfs does
[01:33] <Robot101> that's odd
[01:34] <jbailey> Swiching to stock kernels now should be as simple booting with it and changing the root= line in grub, I think.
[01:35] <Robot101> with mkinitramfs you mean
[01:35] <jbailey> Right.
[01:35] <Robot101> I didn't need to change the root line because it's still /dev/md0
[01:35] <Robot101> still puzzled by the pts lackage
[01:35] <jbailey> Oh, I see. =)
[01:36] <jbailey> I  hadn't realised you were on raid.
[01:36] <jbailey> So in that case, yes, you shouldn't have to change anything.
[01:36] <jbailey> It'll just autodetect all of that.
[01:36] <jdub> Mitario: you in amsterdam?
[01:36] <Mitario> jdub, umm, 'bout 50km
[01:36] <Robot101> well the reason mkinitrd didn't work was because a) it didn't load my sata driver plus b) it hardcoded the path to my SATA drives as hdX
[01:36] <Mitario> jdub, 1 hour by train :)
[01:36] <Mitario> jdub, or do you actually mean now?
[01:37] <Robot101> jbailey: can I put something in kernel-img.conf to use mkinitramfs from now on?
[01:37] <jdub> Mitario: https://wiki.ubuntu.com/BadgerBadgerBadgerTour
[01:37] <jbailey> Robot101: Right.  There's none of that hardcoded in there.
[01:37] <jbailey> Robot101: Ubuntu's kernels will do it automatically.  I don't think Debian's kernels have the hack, but they might.  Try adding: "ramdisk = /usr/sbin/mkinitramfs
[01:37] <jbailey> "
[01:38] <jbailey> ISTR Fabio sent it off to Manoj, but I didn't track if it was accepted or not.
[01:38] <Mitario> jdub, ah cool! well, I can always drop by :)
[01:38] <jdub> Mitario: rad :)
[01:38] <Robot101> jbailey: the funny thing is, mkinitrd will work for now... :)
[01:38] <Robot101> actually, it might be too shit to work out that sda and sdb are from sata_via
[01:38] <Robot101> scratch that, it is.
[01:39] <jbailey> That logic always scared me.  It was so bloody fragile.
[01:39] <Robot101> oh well, every time I pull down a stock kernel the next reboot will be an "oh shit" :)
[01:39] <Robot101> until we burninate mkinitrd
[01:40] <jbailey> Oh good.
[01:40] <jbailey> I can safely encourage you to just use Ubuntu here. =)
[01:40] <Robot101> feh :P
[01:41] <Robot101> its tempting actually, but I think at some point I'll go Xen and run debian and ubuntu at the same time :)
[01:41] <Robot101> but probably sit at ubuntu and have debian in the background
[01:41] <Robot101> :)
[01:41] <Robot101> just because I can really...
[01:42] <jbailey> ISTR a recent announcement saying that we're going to Xenify our stuff sometime.
[01:42] <Robot101> yeah, xen 3.0 actually works now
[01:42] <jbailey> Ah, handy.
[01:42] <Robot101> like acpi, apm and stuff
[01:42] <Robot101> I'm surprised ppc support has been so long coming
[01:43] <Robot101> ooh, the Debian images do have ramdisk =
[01:43] <tseng> jdub: i cant comment on your blog post about pyjamas
[01:43] <tseng> jdub: it is calling out to me
[01:43] <elmo> xen-3 is out?
[01:43] <Robot101> elmo: poorly phrased, I meant xen 3.0 will actually work on most hardware
[01:43] <xTina> Hm, is there a known bug with dpkg > 1.10.27ubuntu1 (e.g. the one built against the fixed zlib) that causes the unpacking step of apt-get install kubuntu-desktop on a fresh system to fail reliably (but sometimes with different packages) if dpkg has been updated beforehand?
[01:44] <xTina> I tried it repeatedly on multiple systems with automated installs -- if I insert a dist-upgrade before installing kubuntu-desktop, the installation fails in 90% of the attempts, if I keep the old dpkg until kubuntu-desktop has been installed it works 100%.
[01:44] <jbailey> Robot101: Anyhow, anything esle you need?  I think I'm otherwise going to wander away for the evening.
[01:44] <Robot101> jbailey: no I'm hugely grateful, and encourage you to spread mkinitramfs far and wide :)
[01:47] <Robot101> team in IBM, even
[01:48] <jbailey> Robot101: Lovely.  Yeah, I need to get around to merging that in to Debian.  *sigh*  Too much to do. =)
[01:49] <Robot101> jbailey: anything I can help with?
[01:50] <Robot101> jdub: couldn't tempt you up to cambridge for bit when you're in london? :)
[01:50] <jbailey> Robot101: If you'd be willing to help negotiate  adding busybox-initramfs to whichever busybox is being maintained, that would be lovely.
[01:50] <Robot101> jdub: add * drink ale with debian-uk in cambridge :)
[01:50] <jbailey> In Ubuntu, busybox-cvs is more recent, but I think the busybox package is a better choice in Debian.
[01:51] <jdub> Robot101: i'll put a ? ;)
[01:51] <jbailey> Robot101: If someone is actively caring about this, it's incentive to beat klibc into shape.  initramfs-tools is just a simple upload.
[01:51] <Robot101> jdub: post to<EMAIL_ADDRESS>and fix a date :)
[01:52] <Robot101> jdub: or badger people in #debian-uk on OFTC
[01:52] <tseng> you said badger
[01:52] <jdub> "Catch up with RobertMcQueen, ColinWatson and the whole Cambridge debian-uk mafia?"
[01:52] <jdub> ^ haw haw
[01:52] <Robot101> jdub: I'm not a very high ranking member of the UK cabal :D
[01:53] <jdub> Robot101: anyway, you should post :)
[01:53] <Robot101> jdub: to what, my blog? :)
[01:53] <jdub> debian-uk :)
[01:53] <Robot101> oh right
[01:53] <Robot101> I thought you'd found a comical hackergotchi for me :D
[01:54] <Robot101> http://images.google.com/images?q=robot
[01:54] <Robot101> :)
[01:54] <Robot101> jdub: any particular date preference?
[01:55] <Robot101> jbailey: ahh, I worked out the pts problem
[01:55] <Robot101> jbailey: it's because I've not been able to upgrade udev :)
[01:55] <Robot101> jbailey: because of being on <2.6.12
[01:56] <jbailey> Our udev doesn't have that deficiency.. =)
[01:56] <jbailey> We stopped taking newer versions of udev intentionally so that upgrades from Hoary to Breezy wouldn't suck.
[01:57] <Robot101> ahh
[01:57] <jbailey> There's some clever features in the newer udev that if you've never had, you won't miss. =0
[01:57] <desrt> clever?
[01:58] <Robot101> jbailey: Keybuk explained it the other day but I forgot what it was
[01:58] <jbailey> desrt: Where, there's bits like /dev/by-label and /dev/by-uuid
[01:58] <Robot101> oh yeah, it deprecates almost all of hotplug because the kernel tells udev enough information to just read modules.foo itself and get the right module
[01:59] <Robot101> so then you can put coldplug on
[01:59] <desrt> jbailey; oh.  that's really cute.
[01:59] <jbailey> I think there's some other bits that can use the new socket interface of getting events from the kernel to react a bit more cleanly.
[01:59] <Robot101> and be done with hotplug entirely
[01:59] <jbailey> Right, we do that in the initramfs.
[01:59] <jbailey> Which is why it requires 2.6.12 =)
[01:59] <Robot101> do what, coldplugging?
[01:59] <jbailey> Yeah.
[01:59] <infinito> hi!
[01:59] <infinito> does anyone know what signal send gnome session to apps when closing?
[01:59] <infinito> i need to make some actions on my program before closing session...
[02:00] <Robot101> so does that mean I can just take hotplug off my system if I have a sufficiently new udev? :)
[02:00] <jbailey> That's why it was able to detect everything for you, it doe sit all at boot time and just loads up most of the modules to give itself the most choice at bootup.
[02:00] <desrt> infinito; see the topic
[02:00] <jbailey> Robot101: No, the ide bus is still not covered.
[02:00] <jbailey> i think SCSI is now, though.
[02:00] <Robot101> ah, you need a newer udev to be able to install coldplug
[02:00] <Robot101> what happens if you coldplug twice? :)
[02:01] <infinito> desrt: i'm writing an app for ubuntu, is that included on ubuntu-development??
[02:01] <desrt> infinito; cool.  what app?
[02:01] <jbailey> Robot101: Nothing bad.  The module is already loaded.
[02:01] <infinito> desrt: a webcam activity monitor applet
[02:02] <desrt> infinito; i think you're pretty much screwed if you're an applet :(
[02:02] <Robot101> actually let me test if I get any ptys :)
[02:03] <desrt> infinito; consider making a note about your desired use case on the AppletsRevisited page of the gnome wiki
[02:04] <infinito> desrt: well, in fact is not an applet, is a tray icon that notifies when your webcam is on
[02:04] <Robot101> jbailey: does it do everything, including sound etc?
[02:04] <Robot101> jbailey: (in the initrd)
[02:04] <jbailey> Robot101: No, just storage and network.
[02:04] <jbailey> mm.
[02:04] <jbailey> And framebuffer and acpi. =)
[02:05] <desrt> infinito; either way, i don't think applets or tray icons get asked nicely when the session is about to end
[02:05] <desrt> infinito; the best you can do is probably register a signal on the 'destroyed' event of your eggtrayicon widget
[02:05] <Robot101> desrt: eh?
[02:05] <desrt> infinito; btw.  this isn't really related to ubuntu development
[02:05] <Robot101> desrt: if it's a GnomeProgram you can use the gnome_session_* stuff
[02:06] <infinito> desrt: ok, sorry, thanks anyway :)
[02:06] <Robot101> it probably emits signals to tell you gnome is closing down
[02:06] <desrt> Robot101; can trays that don't have their own main windows be gnome programs?
[02:06] <Robot101> hrm
[02:06] <infinito> desrt, Robot101: it's python
[02:07] <Robot101> sure, but you should still be able to use libgnome...
[02:07] <desrt> :)
[02:07] <desrt> infinito; good luck
[02:07] <infinito> desrt: thanks
[02:08] <mjg59> Evening
[02:11] <elmo> do we have a trivial tag or equiv in our bugzilla?
[02:12] <lifeless> 'tag' ?
[02:12] <elmo> in debbugs, you can assign tags to bugs, 'patch', 'trivial', 'unreproducible' etc.
[02:12] <lifeless> oh right, that form.
[02:12] <lifeless> uhm, you could abuse milestones, but thats all that comes to mind
[02:12] <lifeless> and I do mean ABUSE
[02:12] <elmo> ah, easyfix keyword
[02:13] <elmo> (or 'patch', but in this case 'easyfix' is actually better
[02:13] <Robot101> infinito: libgnomeui gets you session management
[02:14] <infinito> Robot101: under python as well?
[02:14] <Robot101> dunno
[02:16] <Robot101> I don't see why python wouldn't bind session management
[02:18] <Robot101> infinito: gnomeclient is what you want
[02:18] <Robot101> http://developer.gnome.org/doc/API/2.0/libgnomeui/GnomeClient.html
[02:19] <infinito> Robot101: umm thanks, im gonna take a look at it...
[02:19] <Robot101> infinito: gnome_init or similar establishes a connection to the session manager
[02:19] <Robot101> infinito: then you can get a gnomeclient object and bind signals on it
[02:20] <Robot101> infinito: like "die" :)
[02:20] <infinito> Robot101: that's what i was reading
[02:21] <ajmitch> afternoon
[02:21] <Robot101> it's not tied to GnomeProgram (which would make little sense really)
[02:21] <Robot101> jbailey: yeah, newer udev mounts /dev/pts for me :)
[02:29] <TerminX> anyone know why permissions on a bunch of device nodes get screwed when the mplayer package upgrades?
[03:29] <CarlFK> breezy live booting: "no eathernet found, but firewire was"  no eathernet is correct, but there isn't any firewire either.
[03:30] <CarlFK> is bugzilla still the place?
[03:54] <jbailey> Robot101: Right, but it's mountcirtfs that does it...
[03:56] <Robot101> jbailey: but it didn't when I had udev <060
[03:59] <jbailey> Add set -x to the top of S02mountvirtfs?
[03:59] <jbailey> Robot101: Otherwise known as bug reports welcome. =)
[04:01] <CarlFK> breezy live doesn't put my old P2 laptop into 1024x768 - is this worth bugging?
[04:20] <hub> will kernel 2.6.12 bring me something in Ubuntu ?
[04:21] <hub> compared to 2.6.10?
[04:23] <Robot101> hot chicks
[04:23] <Robot101> riches beyond your wildest dreams
[04:23] <hub> I have plenty of that already
[04:23] <hub> what else?
[04:31] <bddebian> 2 more
[05:07] <zul> hi
[05:20] <daniels> mdz: yes
[05:20] <daniels> lamont-away: i don't know
[05:25] <mjg59> daniels: Don't suppose you had any joy poking the X300 stuff any further?
[05:31] <daniels> mjg59: i haven't had any time, sorry
[05:33] <mjg59> daniels: Ok, no problem
[05:33] <mjg59> daniels: I should file a bug about it, really...
[05:34] <daniels> mjg59: i suspect ati don't care because they submit everything via the cp instead of via mmio, so getting r300 dri support in might neatly skirt the problem ;)
[05:36] <mjg59> daniels: Haha
[05:36] <mjg59> Though it would also require PCI express DRI...
[05:37] <mjg59> But you think it's just a matter of syncing the engine in the right place?
[05:37] <daniels> mjg59: oh, yeah, duh
[05:37] <daniels> mjg59: well, idling the engine *works*, but it's usually a workaround for something else (usually an asic bug)
[05:37] <daniels> it slaughters performance
[05:38] <daniels> normally ATI are able to let us know what the particular hardware bug is and how they worked around it, but no more, it seems
[05:39] <mjg59> Hm.
[05:39] <mjg59> Still better than switching off acceleration completely, right?
[05:39] <mjg59> Can you make it specific to the X300?
[05:43] <daniels> yeah, worst-case scenario is that I just have an if block which defaults accel to false on the x300, true otherwise
[05:57] <mjg59> Ok, cool
[08:53] <pef> hello
[08:59] <zyga> hello
[08:59] <zyga> what are 'Release' files?
[09:00] <zyga> I'm translating the installer and I've found some messages I cannot really understand: 'Failed getting Release signature file ${SUBST0}.'
[09:27] <Mithrandir> mjg59: does usplash use double-buffering?
[09:28] <daniels> you *can't* double-buffer with vga, can you?
[09:29] <daniels> fill a couple of registers, poke an int, rinse, repest
[09:30] <Mithrandir> ew, ok.
[09:30] <Mithrandir> I thought you still had an fB?
[09:30] <Mithrandir> s/B/b/
[09:31] <Lathiat> i thought vga had more than 1 screen
[09:31] <daniels> Mithrandir: well, you do have an fb, but at a fundamental level, the fb still has to draw with poke-poke-int-poke-poke-int-poke-poke-int
[09:32] <daniels> Mithrandir: you can't just draw offscreen and tell the card to scan out from that buffer now
[09:32] <daniels> (nice as that would be)
[09:34] <Mithrandir> daniels: you should be able to map the fb, and then just memcpy onto it. :-)
[09:35] <daniels> Mithrandir: hah.  not how vga works.
[09:35] <Mithrandir> daniels: vga sucks, then
[09:35] <Mithrandir> :-)
[09:36] <Lathiat> its interesting, mjg59 reckons that in most cases that vesa breaks suspend and that vga16 works, yet in my case vesa works and vga16 always screws my consoles up. :)
[09:36] <Lathiat> i seem to always get thigns upside down
[09:54] <daniels> Mithrandir: well, duh
[09:56] <Mithrandir> daniels: any reason why /dev/input/mice doesn't default to ExplorerPS2, but ImPS2?
[09:57] <Mithrandir> (changing it makes my MX518's side buttons work correctly)
[10:09] <daniels> Mithrandir: need to establish whether or not it breaks non-explorers
[10:11] <Mithrandir> daniels: so if I can verify that it works correctly with a ps2 and usb mouse, it's ok?
[10:11] <daniels> Mithrandir: go and find the cheapest, shittiest, oldest ps/2 mouse you can see
[10:11] <daniels> Mithrandir: test it with 50 or those
[10:11] <Mithrandir> I generally don't have shitty hardware. :-P
[10:12] <HiddenWolf> shit, I just trew a crate of those out last month. literally.
[10:12] <daniels> Mithrandir: i noticed those
[10:14] <Mithrandir> I mean, why would you save old, shitty, cheap hardware? ;-)
[10:14] <Mithrandir> mvo: the language-selector UI needs some love, I think.
[10:15] <Mithrandir> mvo: if you don't make any changes, "Ok" is a noop
[10:15] <Mithrandir> mvo: should it possibly be "apply changes" and "quit" depending on whether you have done any changes or not?
[10:15] <Mithrandir> s/and/or/
[10:16] <mvo> Mithrandir: yes, it should probably just set the ok button to insensitiv if nothing changed
[10:17] <mvo> Mithrandir: did you noticed other problems as well with it?
[10:17] <Mithrandir> mvo: the norwegian setup is wrong, since there is not a "Norwegian" language, there are two forms of norwegian, which should be treated as two languages for all practical reasons.
[10:18] <Mithrandir> mvo: I think setting the button to insensitive is wrong; an application should be quittable without using the wm decorations.
[10:20] <zyga> mvo: morning :)
[10:21] <zyga> mvo: I'd love to hack language-selector
[10:22] <mvo> zyga: go for it :)
[10:22] <zyga> mvo: I hope it runs on hoary though :/
[10:23] <mvo> zyga: uhh, it depends on a updated python-apt
[10:23] <mvo> Mithrandir: well, if "ok" is insensitiv, "cancel" is still available :)
[10:23] <zyga> mvo: installing breezy's .deb will probably pull everythin in
[10:24] <mvo> zyga: yes :/
[10:24] <zyga> mvo: how about 'Apply changes' and 'Exit'
[10:24] <Mithrandir> mvo: language-selector looks like a dialog, "Cancel" should undo the changes, really.
[10:24] <zyga> apply could become sensitive
[10:24] <mvo> Mithrandir: so it should just be "Norwegian Bokmal" and "N. Nynorsk" but not "Norwegian" ?
[10:24] <Mithrandir> mvo: correct.
[10:24] <Mithrandir> mvo: both should have fallbacks to no_NO
[10:24] <zyga> mvo: will python-apt work on hoary if I build the deb myself?
[10:24] <mvo> zyga: yes, it should be
[10:25] <zyga> mvo: dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
[10:25] <zyga> (I just tried dpkg-buildpackage)
[10:28] <zyga> mvo: arghh... it depends on libapt-pgk-dev
[10:31] <zyga> mvo: It might just work...
[10:31] <mvo> zyga: yeah, it should
[10:46] <hunger> What do I need to do to make xdm install cleanly? Currently it exits postinst with status 1.
[10:51] <zyga> mvo: http://pastebin.com/353434
[10:51] <zyga> mvo: tell me if it's okay to override those dependencies
[10:53] <mvo> zyga: it dosn't build with the old libapt-pkg-dev?
[10:53] <mvo> from hoary?
[11:07] <zyga> mvo: when you said it depends on new python-apt I assumed it needs all updated apt stuff
[11:09] <mvo> zyga: you are right, it does. it needs >= 0.6.40 to build
[11:10] <Aric> anyone heard from DanielS when the next breezy Xorg packages will go up?
[11:52] <pitti> Hi
[11:52] <siretart> hi pitti
[11:53] <carstenh> hi pitti
[11:53] <pitti> Hi guys
[11:56] <pitti> carstenh: could you sleep a bit? :)
[11:56] <carstenh> pitti: sure :)
[12:01] <pitti> doko: thanks for building a mythes shlib :-)
[12:08] <kronoss> hi
[12:09] <pitti> Hi kronoss
[12:11] <sivang> morning all
[12:11] <sivang> pitti: aren't you taking a weekend time off? ;-)
[12:13] <pitti> sivang: yes, just some email reading :-)
[12:27] <Robot101> jbailey: wow, mkinitramfs is very neat
[12:27] <sivang> Robot101: what's neat about it ?
[12:28] <Robot101> how flexible and elegant it is compared to mkinitrd
[12:28] <Robot101> which is just a hairball of crap that doesn't actually work in any remotely interesting situations
[12:28] <sivang> Robot101: but it serves different purposes, no?
[12:28] <Robot101> (*especially* when upgrading from a hand-rolled to a stock kernel)
[12:29] <sivang> Robot101: eh, so it allows some more corner cases , that's always nice
[12:29] <Robot101> sivang: it makes an initrd.ing which brings up your hardware and mounts your /
[12:29] <Robot101> sivang: it's a damn sight better at it than mkinitrd is
[12:29] <Robot101> s/ing/img/
[12:30] <sivang> Robot101: does it have anything to do with RAM ? =) (given it's name)
[12:30] <Robot101> initramfs is just a better replacement for initrds in 2.6 kernels
[12:31] <sivang> Robot101: ah I see, so what does the ram in its name stands for? is it just its name?
[12:31] <azeem> sivang: same as in initrd, I guess
[12:31] <Robot101> the kernel always has a rootfs, which is a RAM-based filesystem, and when given an initramfs image, which is a gzipped cpio thing, unpacks it into the rootfs
[12:31] <azeem> the r stands for ram
[12:31] <ompaul> ram as in random access memory or something else?
[12:32] <sivang> ompaul: yep, I think so
[12:32] <sivang> azeem: k, thanks
[12:32] <Robot101> initramfs lets you use as much space as you want, and its writable
[12:32] <sivang> Robot101: how's that?
[12:32] <Robot101> and you don't give the kernel a filesystem image, you give it a cpio.gz essentially
[12:33] <Robot101> initrd sets you up a ramdisk device of a certain size, and unzips the initrd into it, then mounts that filesystem
[12:33] <Robot101> so you only have as much space as your filesystem image
[12:34] <sivang> Robot101: what was the obsticle in making it variable size that initramfs overcame ?
[12:34] <Robot101> sivang: tmpfs/ramfs/rootfs lets you store filesystems in the VFS file caches basically
[12:35] <Robot101> sivang: so it's like a cache of files off disk filesystems, without a disk
[12:35] <Robot101> sivang: so unless you place a limit on its size, your filesystem is as big as you have free virtual memory
[12:36] <sivang> Robot101: right. makes sense. And initrd was just plain file that was read from disk in boot time, which entitled the size barrier?
[12:36] <Robot101> sivang: whereas for an initrd image, the ramdisk is a pretend block device the kernel sets up for you, and they have a fixed size
[12:37] <Robot101> sivang: the choice of using cramfs for the image makes for smaller initrds, but means that this pre-/ root filesystem can't be written, so the first thing that happens in the initrd is mounting up a load of tmpfs filesystems and copying stuff around
[12:37] <Robot101> sivang: anyway, the use of initramfs in the kernel instead of initrd isn't the reason that mkinitramfs is better than mkinitrd
[12:38] <sivang> Robot101: then what is the reason? =)
[12:38] <siretart> woah. vdk is a beast..
[12:38] <Robot101> sivang: the reason is that mkinitrd is a crap fragile hack which produces initrds that don't reliably initialise your hardware and mount your / :P
[12:38] <sivang> Robot101: that's I've seen , that's probably because of all the loosy file copies and the size constraints no?
[12:38] <Robot101> sivang: no, that's because mkinitrd is just crap
[12:39] <sivang> Robot101: say, as a side note, are you familiar with PKG_CHECK_MODULES directive in autoconf configure files?
[12:39] <Robot101> sivang: you could very easily put most of the clue in mkinitramfs's images into an initrd, but there'd be no point
[12:39] <Robot101> sivang: not really, sorry :-/
[12:40] <sivang> Robot101: k, np , guess I'm off to the autoconf channle
[12:40] <Robot101> wow, there is one?
[12:42] <sivang> Robot101: apparetly, there is only one person in there, so I asked aways in #gnu as well
[01:08] <shackan> is this a good place do ask where does g-n-m take information about active interfaces ? it's not e-n-i because it shows devices not mentioned in the interfaces file, and it's not hal for the same reason, and it's not ifconfig because it does not show all the interfaces ifconfig shows, so how does it work or where can I ask ?
[01:11] <hunger> shackan: I guess "all of the above" applies.
[01:12] <shackan> ugh
[01:12] <hunger> shackan: It definitly gets static configuration from /e/n/i from what I learned here.
[01:12] <hunger> shackan: But it does do additional device discovery.
[01:12] <hunger> shackan: Yeah, I know... it sucks.
[01:13] <shackan> I hope it could just use hal
[01:13] <hunger> shackan: Dynamic stuff defined in /e/n/i is ignored...
[01:13] <shackan> that's what it's meant to do..
[01:14] <shackan> ok, briefly, I want a particular interface to show up in the manager
[01:14] <Robot101> shackan: ifupdown stores state on interfaces in /var somewhere
[01:14] <hunger> shackan: Well, it is meant to configure interfaces. I do not care where it does store its configuration, but I hate it to be in several places.
[01:14] <Keybuk> Robot101: /etc
[01:14] <Keybuk> (at least, it used to be)
[01:15] <Robot101> oh right
[01:15] <Keybuk> /etc/network/run/ifstate
[01:15] <Robot101> why on earth is the busybox-cvs package in ubuntu based on the same orig.tar.gz as in debian, but contains a 5MB diff to a new upstream version?
[01:15] <Robot101> that's obcenely lazy
[01:16] <hunger> NM is not installable on breezy right now anyway:-(
[01:16] <shackan> it seems if[up|down]  requires an entry to be added to net/interfaces
[01:16] <hunger> Looks like j^'s debs are still not in universe.
[01:16] <Keybuk> because otherwise you'd have to change the upstream version?
[01:16] <hunger> shackan: Right. ifup/down needs that entry. NM does not use that though afaikt.
[01:18] <Robot101> Keybuk: I had to use initramfs-tools to render my sid desktop bootable because mkinitrd is so crap :)
[01:19] <shackan> thanks anyway
[01:19] <shackan> I'll look for an official site with a faq or something
[01:20] <Robot101> Kamion: why does busybox-cvs in ubuntu have a 5MB diff? I'd like to merge the relevant changes to make initramfs stuff work into debian's busybox 1.x package
[01:20] <Robot101> Kamion: but it's a little hard to.. uh... know which changes are relevant
[01:23] <Robot101> ah
[01:23] <Robot101> Keybuk: http://people.ubuntu.com/~scott/patches/busybox-cvs/ seems to have rendered the entire package into a patch :)
[01:23] <HiddenWolf> lol
[01:23] <Keybuk> it would do
[01:24] <Robot101> really? the sid one and the breezy one have the same orig.tar.gz
[01:24] <Keybuk> exactly, so the patch on that URL would be the entire difference of the .diff.gz
[01:24] <Keybuk> it's 5MB, as you said
[01:25] <Robot101> Keybuk: no it's not, it's 82k
[01:25] <Keybuk> the .diff.gz ?
[01:25] <Robot101> no, the interdiff from busybox-cvs_20040623-1.diff.gz to busybox-cvs_20040623-1ubuntu21.diff.gz
[01:26] <Robot101> the debian diff.gz is 175445, and the ubuntu diff.gz is 191796, and they share the same orig.tar.gz
[01:26] <Keybuk> *shrug*
[01:27] <Robot101> so the output on your page is bogus
[01:27] <Keybuk> almost certainly
[01:27] <Robot101> you seem unconcerned :P
[01:28] <Keybuk> I am
[01:28] <Keybuk> if it's just that one package, there's probably something odd
[01:28] <Robot101> given that this page is meant to be the magical oracle for Debian people to come and get their Ubuntu crack, it's not making it easy for me to understand what's been changed :P
[01:28] <Keybuk> looks like a lot of them have done that though
[01:28] <Keybuk> probably a bug
[01:29] <Robot101> you still seem unconcerned :P
[01:29] <Keybuk> yes, it's Satday
[01:29] <Keybuk> with an "ur" in there
[01:29] <Robot101> uuuur
[01:29] <Keybuk> I'll be concerned on Monday ;)
[01:29] <Robot101> lol
[01:29] <Robot101> fair enough
[01:30] <Keybuk> I'd guess it didn't like me wiping the files cache the other day
[01:30] <Robot101> why is that not eg patches.ubuntu.com? :)
[01:30] <Keybuk> because
[01:30] <Keybuk> it's not an official service, I guess
[01:31] <Robot101> it comes up very often in arguments against ubuntu being a fork... it probably should be :)
[01:31] <Keybuk> but we are a fork
[01:31] <Keybuk> just one that eats the same meatballs ;)
[01:31] <Robot101> fork/spoon/whatever... against it being an uncooperative fork at any rate
[01:32] <Keybuk> Debian is an uncooperative parent, in my experience
[01:34] <Keybuk> weird
The requested URL /archive/2004/06/30/debian/pool/main/b/busybox-cvs/busybox-cvs_20040623-1.diff.gz was not found on this server.</p>
[01:35] <Keybuk> there you go
[01:35] <Keybuk> that's the problem
[01:35] <Keybuk> snapshot.debian.net has lost most of the archive
[01:38] <Robot101> Keybuk: there we go, waldi would be happy to see a patch making busybox good for initramfs
[01:38] <Keybuk> hmm?
[01:39] <Robot101> Keybuk: I'm trying to spread the mkinitramfs love into Debian :)
[01:39] <Keybuk> right ...
[01:39] <Robot101> given it can make my computer boot, and mkinitrd can't
[01:39] <Robot101> well I was just saying, he doesn't seem to be uncooperative...
[01:39] <Keybuk> right, it's certainly not all
[01:40] <Keybuk> but at some point the work to try and get the changes into Debian exceeds the benefit
[01:40] <azeem> hear, hear
[01:40] <Robot101> but at some point you have more delta than you have people to maintain it
[01:40] <Keybuk> the fact he hasn't, despite their being a patch available, is somewhat indicitive
[01:41] <Keybuk> why doesn't the Debian version support initramfs?
[01:41] <Keybuk> the patch has been available all the time
[01:41] <Robot101> was he even aware that ubuntu's version had been modified for supporting it?
[01:41] <Keybuk> he should have been
[01:41] <Keybuk> the Debian PTS and QA pages keep track of that these days
[01:42] <Keybuk> as a maintainer, keeping an eye on what other distributions are doing with the same package is kinda useful -- not just Debian-derivs but what RedHat are doing etc.
[01:43] <Keybuk> in my experience the complaints are that the patch isn't handed to them on a gilded silver platter, perfectly tailored to their wishes, etc.
[01:44] <Keybuk> a lot of Debian maintainers just don't seem willing to do _any_ work to merge Ubuntu patches in
[01:44] <Keybuk> and expect Ubuntu to do all that work, rather than meeting half way
[01:44] <Keybuk> we've done more than any other distribution to make it easy to find the differences
[01:45] <Keybuk> I've helped the QA and PTS people find out what's different
[01:45] <ajmitch> Robot101: it's a big challenge for universe, since we're spread so thin
[01:45] <ajmitch> we don't have time to tailor things for debian, generally
[01:47] <Robot101> fair enough
[01:47] <Robot101> I don't really think you're an uncooperative fork
[01:47] <Robot101> :)
[01:47] <Keybuk> I'm finding it slightly amusing that you're the first person to notice NDA hasn't worked for two months <g>
[01:47] <Keybuk> that really shows how many Debian people are using it :p
[01:48] <Keybuk> (actually, it's probably only a couple of weeks -- it would have survived the snapshot melt until I deleted the disk cache because it ran out of space)
[01:49] <Keybuk> Aug 24, in fact, is when it would've failed
[01:49] <azeem> Keybuk: the snapshot melt concerns only stuff from last year, so if there have been more recent Debian uploads, you wouldn't notice I guess
[01:50] <Keybuk> azeem: yeah, it'll be just where the Debian version the Ubuntu one is based off is before March 13th
[01:50] <Robot101> this package is only so old because it's been superseded in debian
[01:50] <Robot101> debian's not the only people with merging work to do :D
[01:51] <Keybuk> right, but we're in freeze, so we have to do all the merging work at the start of dapper
[01:51] <Robot101> hrm, so in a month or two someone will be paid to do what I'm about to do now?
[01:51] <ajmitch> I think for universe, it'll take a few weeks just for merges at the start of the cycle
[01:52] <Keybuk> Robot101: that's the other bit of the Debian problem <g>
[01:52] <Keybuk> "I'm not doing that if someone else is going to get paid to do it" :p
[01:52] <ajmitch> Robot101: some of us do things out of love, still :)
[01:52] <Robot101> (note that I'm still doing it)
[01:55] <Robot101> the mergeometer... watch find . -name *rej
[01:55] <Robot101> :D
[01:57] <Keybuk> heh, how do you think merge-o-matic works? :p
[01:59] <Keybuk> rookery files% grep "404 Not Found" *.dsc| wc -l
[01:59] <Keybuk> 764
[02:00] <Robot101> Keybuk: something evil with interdiff, grepdiff...? :)
[02:01] <Keybuk> rookery files% /bin/ls *.dsc~*ubuntu* | wc -l
[02:01] <Keybuk> 1669
[02:02] <Keybuk> so about half of our Debian bases are missing :-/
[02:03] <azeem> Keybuk: you use snapshot.d.n only when the package is not on ftp.d.o?
[02:05] <Keybuk> azeem: no, always use snapshot
[02:06] <azeem> Keybuk: hrm, so maybe trying ftp.d.o first might help a bit in this situation?
[02:07] <Keybuk> maybe a bit
[02:07] <Keybuk> snapshot never broke before, so there wasn't any reason to do it <g>
[02:07] <azeem> yeah
[02:25] <Robot101> Keybuk: where can I get old ubuntu diff.gzs?
[02:26] <Keybuk> morgue.ubuntu.com
[02:26] <Robot101> word
[02:26] <Robot101> I realised that what I was trying to do was break up this patch into its constituents, and given that each change was probably made one at a time I can do a lot of the work for me with interdiff :)
[02:27] <Robot101> <-- patch n00b
[02:27] <jdub> GOOD MORNING FREEDOM LOVERS!
[02:28] <Mitario> um... hi :)
[02:28] <sebest> good morning!
[02:28] <Robot101> jdub: moin
[02:29] <Robot101> hrm
[02:30] <Robot101> fuck it
[02:34] <Kamion> Robot101: I was too scared to switch from busybox-cvs to busybox at the point that change happened in Debian ... as the man says, we'll do it for breezy+1
[02:35] <Kamion> all the initramfs stuff was jbailey's work, anyway
[02:35] <Robot101> Kamion: fair enough
[02:36] <Robot101> I think I've already merged enough for the initramfs
[02:37] <Kamion> jbailey probably ought to have sent waldi a patch for that, if he wanted to merge stuff to Debian
[02:38] <Kamion> then again, there's a fair amount of busybox stuff I ought to have sent patches for, too
[02:38] <Robot101> I'm highly keen on seeing it in debian, mkinitrd is just too stupid for words
[02:38] <Kamion> although I have sent some of it
[02:38] <Robot101> it's very hard to migrate from a custom kernel to a stock kernel in a fair number of situations
[02:39] <Robot101> mkinitrd's initrds just aren't robust in the slightest
[02:40] <Robot101> I wonder what the debian kernel folks think about mkinitramfs
[02:43] <Kamion> Robot101: they seem to be vacillating between it and yaird
[02:44] <slomo> hm... do we have daily live cds?
[02:44] <ajmitch> slomo: yes
[02:54] <Robot101> Kamion: hm, and yaird postdates ubuntu's mkinitramfs?
[02:56] <Robot101> Kamion: mkinitramfs looks like it does a lot more automatically (at boot time) than yaird
[02:57] <Robot101> which makes it more robust
[03:01] <Robot101> it seems to be about how to boot linux boxes, not about how it works
[03:06] <Kamion> Robot101: no idea
[03:06] <Kamion> slomo: http://cdimage.ubuntu.com/daily-live/
[03:07] <slomo> Kamion: thanks :) ajmitch already gave me an url
[03:52] <madduck> Diziet: ayt?
[03:53] <pef> what do you think about debian/rules commented debhelper commands calls ?
[03:53] <madduck> pef: remove them. :)
[03:54] <pef> madduck: I don't understand why lot of packages have them
[03:54] <madduck> pef: dh_make
[03:54] <ogra> lazyness
[03:54] <pef> so commented out -> to delete
[03:54] <madduck> yes
[03:55] <madduck> there was a debian list post about this sometime in the last few weeks
[03:55] <madduck> can't find it now.
[03:55] <madduck> basically, the main objection from the side of people is that they won't know the right commands should they ever need them in the future
[03:56] <madduck> which is utter b/s. the solution is obviously to 'dh_<TAB>' at the shell. :)
[03:56] <madduck> and man debhelper.
[04:03] <siretart> madduck: do you know/have a work-around for non existing baz_load_dirs?
[04:04] <madduck> sec
[04:06] <madduck> siretart: workaround for what?
[04:07] <madduck> siretart: i mean, what problem?
[04:07] <madduck> i don't have a new baz_load_dirs yet
[04:07] <siretart> madduck: well, afai understood, tla_load_dirs does not handle loading into bazaar archives
[04:07] <madduck> oh, it does.
[04:08] <madduck> you need to get the latest from unstable
[04:08] <madduck> -3 i think
[04:08] <madduck> ah no...
[04:08] <madduck> http://bugs.debian.org/322622
[04:08] <siretart> exactly
[04:09] <madduck> no. i usually just tar the new upstream over and then check status and diff output
[04:09] <madduck> renames are very infrequent, IME
[04:09] <madduck> siretart: but it should be *trivial* to patch.
[04:10] <siretart> hm
[04:10] <madduck> ah, here's a workaround.
[04:10] <madduck> echo -e "#!/bin/sh -e\nexec baz $@" > ~/bin/tla
[04:10] <madduck> :)
[04:12] <siretart> hm. nasty, but effective :)
[04:12] <madduck> might not work
[04:12] <madduck> but you could us a case statement to translate commands back and from. :)
[04:12] <madduck> better to patch load-dirs-common.
[04:13] <siretart> jepp
[05:15] <jbailey> slomo: No.  At this point it likely won't get looked at until after Preview is done.
[05:15] <jbailey> I have a couple higher priority bugs to chase at the moment.  I don't know where it is in BenC's queue.
[05:16] <slomo> jbailey: ok... no problem :)
[05:49] <marcin_ant> hi all - short question - there are 14 Google Soc Projects in breezy bounties
[05:50] <marcin_ant> release day was 01.09, so, could someone tell me what is the status of these projects?
[05:50] <marcin_ant> are there any reports etc. what's going on for example with bluetooth support goal?
[05:51] <ryanthiessen> marcin_ant: a lot of the SoC projects missed Breezy's feature freeze and will be included in breezy+1
[05:52] <marcin_ant> ryanthiessen, ok but what about the status of these projects?
[05:53] <marcin_ant> ryanthiessen, 1. personally I would like to know if there is any work on bluetooth support and 2. I'm just curious if these Soc projects were successfull
[05:54] <marcin_ant> ryanthiessen, (it's pretty strange for me - $2 mln budget and I cannot see any list of accepted projects, any reports what's going on with these projects.... )
[05:58] <hunger> marcin_ant: I bet there will be a paper by google soon, claiming a huge success...
[05:58] <hunger> marcin_ant: I have not yet heared of any myself though:-)
[06:00] <marcin_ant> hunger, well maybe but I'm not so sure...
[06:01] <marcin_ant> hunger, for example Chris DiBona announced a web page with list of accepted project at 04.07
[06:01] <marcin_ant> hunger, and there is no such webpage since today
[06:01] <slomo> elmo: did you already read my mail regarding ffmpeg?
[06:03] <marcin_ant> hunger, and another thing is that if ubuntu is mentor and this is ubuntu-devel channel than I thought that someone here should know what's going on with these projects
[06:10] <desrt> mxpx; pong
[06:11] <ryanthiessen> marcin_ant: pitti is the bluetooth assessor, ask him when he's around
[06:11] <marcin_ant> ryanthiessen, ok
[06:11] <marcin_ant> ryanthiessen, thx
[06:11] <marcin_ant> .seen pitti
[06:11] <marcin_ant> ,seen pitti
[06:12] <marcin_ant> ehh hello bot, are you there?
[06:12] <marcin_ant> anyway pitti isn't online
[06:20] <amep> I have a laptop that fails during suspend to RAM (goes down, but oopses on the way up before the screen lights up). The machine is a Compaq R3000z AMD64 system. How should I go about debugging? and is suspend to RAM a target for breezy so should I even bother? Suspend to disk worked.
[06:49] <amep> I have a laptop that fails during suspend to RAM (goes down, but oopses on the way up before the screen lights up). The machine is a Compaq R3000z AMD64 system. How should I go about debugging? and is suspend to RAM a target for breezy so should I even bother? Suspend to disk worked.
[06:49] <Lathiat> amep: file a bug
[06:49] <Lathiat> would be appreciated, thanks :)
[06:50] <amep> OK, I'll do that. I'll include lsmod output and what else?
[06:51] <Lathiat> details of your laptop, lsmod, if you have any info i your syslog such as the oops information thatd be good, as would an lspci
[06:51] <amep> Cool, will do.
[06:51] <amep> Thanks
[06:51] <Lathiat> nps
[06:51] <hunger> amep: A wiki page about the laptop might be nice as well (LaptopTesting
[06:54] <amep> hunger: There is one at LaptopTestingTeam/CompaqPresarioR3000 should I add to that or should I create a LaptopTesting/CompaqPresarioR3000z page?
[06:55] <Lathiat> amep: is that laptop the same as yours specification wise?
[06:55] <amep> It's hard to tell. I'll look.
[06:56] <hunger> amep: I'd create a new page... even if the specs are similar who knows what hardware compaq built into each one.
[06:56] <amep> I also wanted to know if you care whether it's under LaptopTesting or LaptopTestingTeam.
[06:56] <Lathiat> LaptopTestingTeam is the place
[06:57] <hunger> amep: Listen to Lathiat, he knows things;-)
[06:57] <Lathiat> i do? *G*
[06:57] <amep> OK, I'll write that page this while I write the bug report.
[06:57] <amep> Is there a template page?
[06:59] <Lathiat> amep: yes, see the LaptopTestingTeam page
[07:01] <amep> Lathiat: Sorry I should have seen that.
[07:01] <Lathiat> amep: 'sok
[07:13] <lamont-away> postgres is pitti, yes?
[07:15] <tseng> yes
[07:21] <Lathiat> -EWIN
[07:23] <amep> Lathiat: what package should I file my sleep bug against? acpi or acpi-support?
[07:24] <Lathiat> amep: uh
[07:24] <Lathiat> amep: acpi-support
[07:24] <amep> OK. Thanks.
[07:26] <lamont-away> https://bugzilla.ubuntu.com/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=UPSTREAM&bug_status=PENDINGUPLOAD&field0-0-0=product&type0-0-0=substring&value0-0-0=FTBFS%20in%20breezy&field0-0-1=component&type0-0-1=substring&value0-0-1=FTBFS%20in%20breezy&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=FTBFS%20in%20breezy&field0-0-3=status_whiteboard&type0-0-3=substring
[07:26] <lamont-away> &value0-0-3=FTBFS%20in%20breezy
[07:26] <lamont-away> ^^ for fun
[07:26] <HiddenWolf> lamont-away, www.tinyurl.com!
[07:27] <lamont-away> yeah, well..
[07:30] <ompaulAFK> http://tinyurl.com/ac3q7
[07:44] <Lathiat> mjg59: ugh, keyboard shortcut handling is totally bogus
[07:57] <hunger> Does anyone know how to fix the current xdm?
[08:17] <djpig> Keybuk: ping
[08:17] <Keybuk> yo, 'sup?
[08:18] <djpig> is http://people.ubuntu.com/~scott/patches/ currently broken?
[08:18] <Keybuk> yes, see topic :p
[08:18] <Keybuk> actually, it's snapshot.debian.net that's broken
[08:19] <Keybuk> they lost the drive, so we can't get the old versions of the Debian packages to make the diffs
[08:19] <djpig> ic
[08:58] <jbailey> Keybuk: Around?
[09:00] <Keybuk> jbailey: yes
[09:00] <Keybuk> I do get aroud
[09:00] <jbailey> ;)
[09:00] <jbailey> Keybuk: I think we're going to need a solution of some sort with dpkg for "breaks" or something.
[09:01] <jbailey> right now if you upgrade glibc and nothing else to breezy, the old initrd-tools makes initrd's that are broken.
[09:01] <Keybuk> we do need Breaks
[09:01] <Keybuk> but we need Breaks 6-months ago, if we want it for the hoary->breezy upgrade
[09:01] <Keybuk> so there ain't bugger all we can do about that now
[09:01] <jbailey> If you update glibc without updating libterm-redline-gnu-perl and happen to use the terminal mode of debconf, any debconf app breaks.
[09:01] <jbailey> I suspect we'll see mass breakage if we don't have something. =(
[09:01] <Keybuk> (because the hoary apt has to calculate the upgrade; and the hoary app doesn't do Breaks)
[09:02] <jbailey> Ouch
[09:02] <jbailey> Is there nothing we can do? =(
[09:02] <Keybuk> other than doing Breaks, and then put "upgrade dpkg and apt first" in the release notes
[09:02] <Keybuk> which, btw, NOBODY will follow
[09:02] <Keybuk> nope, nothing
[09:03] <jbailey> Should I just close these bugs as WONTFIX ?
[09:03] <Keybuk> make them versioned deps in ubuntu-*
[09:03] <Keybuk> ask mdz what he wants to do about it
[09:03] <jbailey> Well, he's the one who prompted me into asking you the first time a few months ago when it came up.
[09:04] <jbailey> initrd we could ignore, since we don't actually use it anymore.
[09:04] <jbailey> But this adds people using readline frontend into the mx, so I figured I'd ask again.
[09:05] <jbailey> I can put it in the release notes, and I don't know that many people will actually use readline mode on Ubuntu.
[09:05] <jbailey> libreadline-gnu-perl isn't even in main for us.
[09:05] <jbailey> I just don't know what to do with the bug reports otherwise.
[09:07] <Lathiat> what does Breaks: do
[09:08] <Lathiat> make sure that package upgrades with it?
[09:08] <jbailey> AIUI, it basically makes it a temporary pre-depend.
[09:08] <jbailey> Or unpacks it first or something.
[09:10] <desrt> will preview have 2.12.0?
[09:11] <Keybuk> lol
[09:11] <Keybuk> no
[09:11] <desrt> eek
[09:11] <Keybuk> Breaks is to Conflicts as Depends is to Pre-Depends
[09:11] <Keybuk> when foo Conflicts bar, even if it's just bar (<< some-version) it means that bar has to be _removed_ from the system before foo can be unpacked
[09:11] <Keybuk> apt might decide to remove then install the new version, but it still has to not be on the disk at some point
[09:12] <jbailey> Ah, hmm.
[09:12] <Keybuk> Breaks is less so, it simply requires that it be deconfigured -- so a normal upgrade can take place
[09:12] <Keybuk> foo Breaks bar (<< some-version) means bar has to be upgraded, basically
[09:16] <Lathiat> ah ok
[09:16] <lamont> malloc: ../bash/jobs.c:737: assertion botched
[09:16] <lamont> free: underflow detected; mh_nbytes out of range
[09:16] <lamont> Aborting.../bin/sh: line 1: 19261 Aborted                 CC="cc" CXX="g++"
[09:16] <lamont> Go, bash!!!
[09:16] <Keybuk> sweet
[09:16] <lamont> and that's just running configure. (for vino)
[09:19] <Keybuk> we could stick dpkg and apt into hoary-updates ... <G>
[09:21] <lamont> Keybuk: or hoary-security... :)
[09:21] <lamont> but that doesn't help the off-net user
[09:21] <Keybuk> *giggle*
[09:21] <Keybuk> are you joining us in Montreal, btw?
[09:21] <lamont> gonna ask next week if they'll send me... if I do come, it'll just be for a couple of days
[09:22] <Keybuk> aww :-/  but it'll good to see ya
[09:22] <lamont> it'll be good to be seen.
[09:22] <lamont> er, or something like that
[09:28] <jbailey> lamont: We'll have you over for a drink. =)
[09:28] <lamont> heh
[09:28] <pef> is it possible to build a custom ubuntu cd for installing something like a configured samba network ?
[09:28] <Keybuk> yes.
[09:29] <lamont> pef: it's easiest to start from a built CD though
[09:30] <pef> for example: I have an ubuntu server, with samba configured and postfix working as an mx backup. is it possible to build a custom cd which install theses services like there were ? disk cloning is great, but if you change hardware ?
[09:38] <lamont> most certainly
[09:38] <lamont> if it was me, I'd add a package that Depends: postfix, samba, and configures them like you want.
[09:39] <lamont> then do a server install, and then install your pacakge.
[09:40] <lamont> sadly, the Release file is signed on the CD, so you also have to upgrade ubuntu-keyring to include your (newly generated and held sacred) key, and re-sign the new Releases file with that key
[09:41] <lamont> alternatively, you just include a new subdirectory on the CD that contains your self-contained tree with your package.
[09:41] <lamont> that's considerably easier, and gives a clear history of the CD
[09:41] <lamont> but it does require adding the key, or dealing with it being unauthenticated, etc.
[09:45] <pef> ok, nice idea
[09:47] <lamont> cc -O2 -I../include -g -Wall -DGCC_WARN   -c -o end.o end.c
[09:47] <lamont> end.c:1190: warning: 'list_vanquished' defined but not used
[09:47] <lamont> that just sounds like a serious nethack bug.
[09:47] <lamont> Kamion: fix that.  kthxbye. :-)
[10:49] <mxpxpod> desrt: you have a pbook, right?
[10:54] <desrt> mxpxpod; i do.
[10:54] <desrt> mxpxpod; i'm on that laptop testing thingy
[10:54] <mxpxpod> desrt: can you come to #ubuntu-laptop and discuss some ppc laptop stuff?
[10:54] <desrt> sure
[11:09] <Lathiat> ogra: hrm, the password circles are off center
[11:10] <Lathiat> mjg59: another bug, lid down -> lid up -> lid down -> lid up -- doesnt auto dpms back on like it does the first time
[11:31] <wasabi> darn ibook still won't wake up
[11:33] <slomo> jbailey: i found two other people with an ibook g4... everything works for them :(
[11:39] <slomo> fabbione: can we update linux-wlan-ng (kernel modules and userland tools) to 0.2.2 after preview freeze? between 0.2.1-final and our version (-pre26) were many important bugfixes and between 0.2.2 and 0.2.1-final was exactly one change: a bugfix ;)
[11:58] <Kamion> lamont-away: odd, list_vanquished is a function