[12:26] <lamont__> mjg59_: btw - sent someone your way wrt latest thinkpad acpi stuff.
[12:26] <mjg59_> lamont__: Ah, thanks
[02:15] <jbailey> lamont__: pong
[02:19] <TheMuso> .c
[02:19] <TheMuso> crap
[02:33] <weridcreep> hello
[02:35] <lamont__> jbailey: figured it out... although... 
[02:35] <lamont__> what's the easiest way to abuse an initrd to debug in it?
[02:35] <weridcreep> what kernel does ubuntu run
[02:36] <jbailey> lamont__: Existing one, or can you create a new one?
[02:36] <lamont__> jbailey: (original question involved a brainfart trying to mount the initrd locally to look)(
[02:36] <jbailey> Editting existing ones is teh suck.
[02:36] <lamont__> given the recipie, I could create a new one...
[02:36] <jbailey> Okay, edit /etc/mkinitrd/mkinitrd.conf
[02:36] <jbailey> Set DELAY=5 and BUSYBOX=yes
[02:36] <jbailey> (Make sure busybox-cvs-static is installed)
[02:36] <jbailey> as root:
[02:37] <jbailey> mkinitrd -o /boot/initrd.img-$(uname -r) $(uname -r)
[02:37] <jbailey> NOTE:  This will overwrite your current initrd.
[02:37] <lamont__> yeah - I see that
[02:37] <jbailey> If you have a sane bootloader (That is, grub grub or grub), you can make it /boot/initrd or something like that and just change it at boot time.
[02:38] <lamont__> jbailey: elilo :-(
[02:39] <jbailey> Add an entry for your testing then.
[02:39] <lamont__> yep
[02:39] <jbailey> You won't get grub2 for efi for another couple of months.
[02:39] <jbailey> (although someone has now started on it)
[02:39] <lamont__> actually, the current state is that 'Linux' doesn't boot, and 'Good' does. :-)
[02:39] <jbailey> Great!  Overwrite the one for Linux then, nothing to lose.
[02:39] <lamont__> yeah
[02:39] <jbailey> Oh!
[02:39] <lamont__> yeah
[02:39] <jbailey> Missed a step.
[02:39] <lamont__> ??
[02:40] <jbailey> Edit /etc/mkinitrd/modules and add the modules you need to have a working keyboard.
[02:40] <lamont__> serial atm
[02:40] <jbailey> 'k =)
[02:40] <jbailey> *blink*
[02:41] <jbailey> config?
[02:41] <lamont__> happy happy joy joy.  binary searches are _SO_MUCH_FUN_!!!
[02:41] <lamont__> kernel config
[02:41] <lamont__> defconfig vs itanium
[02:41] <jbailey> I didn't think there were 2700 options in there.
[02:41] <jbailey> 'sthis breezy?
[02:41] <lamont__> rather, defconfig vs breezy/itanium
[02:41] <lamont__> just a sec and I'll dump stats for you - Good has almost booted.
[02:42] <jbailey> If you feel up to it after this, I'd appreciate feedback on the initramfs-tools, since it's scheduled to become default on Friday.
[02:42] <jbailey> Since I will be away this weekend, I'd rather clobber as few UndercluedUsers as possible.
[02:43] <jbailey> (You know... For the racks of Itaniums running Breezy out there...)
[02:43] <lamont__> diff -u debian/config/itanium debian/config/ia64/itanium | wc
[02:43] <lamont__>    2732    5643   61682
[02:43] <jbailey> *ouc*
[02:43] <jbailey> +h
[02:43] <lamont__> yeag
[02:50] <lamont__> must run
[02:50] <lamont__> back later
[06:33] <fabbione> morning
[06:33] <desrt> word.
[06:34] <desrt> i have a question that i asked earlier after you'd gone to bed :P
[06:34] <desrt> why are you packaging 2.6.12?
[06:36] <fabbione> what should i be packaging?
[06:37] <desrt> 2.6.13-rc's
[06:37] <fabbione> no
[06:37] <fabbione> we are in UVF
[06:37] <fabbione> Upstream Version Freeze
[06:37] <fabbione> we need to release quite soon
[06:37] <desrt> since how long?
[06:37] <desrt> hmm
[06:37] <fabbione> 3 weeks?
[06:37] <fabbione> more or less
[06:37] <desrt> so 2.6.12 is the breezy kernel
[06:37] <desrt> weird
[06:37] <fabbione> yes
[06:38] <desrt> ok.  that's a good reason :)
[06:39] <fabbione> that's what in our conffile
[06:39] <fabbione> ops
[06:41] <desrt> is gnome a blanket exception to UVF or is 2.11 considered like a 2.12 prerelease?
[06:41] <fabbione> gnome is an exception
[06:42] <fabbione> it has been since the beginning
[06:42] <desrt> it's a good exception :)
[06:54] <fabbione> infinity: ping?
[07:13] <calc> any chance of getting a working version of ipw2200 into the kernel soon?
[07:13] <calc> fabbione: still here?
[07:13] <fabbione> calc: ipw2200 is working
[07:14] <calc> 1.0.4 -> 1.0.1 for WEP but broke WPA completely
[07:14] <fabbione> calc: 1.0.4 did break completely ipw2100
[07:14] <fabbione> and i had no time for that release to test 1.0.6
[07:14] <calc> too bad its not even for the ipw2100
[07:15] <calc> i have 1.0.4 on ipw2200 and it works more or less fine
[07:15] <fabbione> also.. people should read what's on the ipw2x00 sties
[07:15] <fabbione> sites
[07:15] <calc> i get those error messages about resetting firmware but 1.0.4 does actually work 1.0.1 doesn't at all
[07:15] <fabbione> 1.0.X releases
[07:15] <fabbione> for x = 0 stable
[07:15] <fabbione> for x > 0 development
[07:15] <fabbione> 1.0.6 = development
[07:15] <calc> 1.x.y
[07:15] <calc> x is stable
[07:15] <calc> when x = 0
[07:16] <calc> or else why not go all the way back to 1.0.0 ? :)
[07:16] <fabbione> Versions with the last number is not a zero is an unstable release, for example 1.0.1, 1.1.3, etc.
[07:16] <calc> yes
[07:16] <calc> 1.0.0 is basically useless
[07:16] <calc> 1.0.1 is nearly that way
[07:16] <fabbione> because ipw2100 is alligned with 1.0.1 ipw2200
[07:16] <calc> what does ipw2100 have to do with ipw2200?
[07:17] <fabbione> so your x.y interpration is wrong
[07:17] <fabbione> calc: they share ieee8$something layer
[07:17] <fabbione> they splitted only recently in 3 projects
[07:17] <calc> that doesn't avoid the point that ubuntu is still using a development driver and one that is more broken than the current one which fixes about an additional 30 bugs
[07:17] <calc> ah yea i see about the 802.11 stuff
[07:18] <fabbione> calc: the plan was to revert to a more stable release
[07:18] <fabbione> and than try the new split in the next kernel
[07:18] <fabbione> before the ieee code was duplicated and misalligned between the 2
[07:18] <fabbione> (ipw2x00)
[07:18] <fabbione> so it was creating all sorts of problems
[07:18] <fabbione> only recently they splitted ieee out of the 2 trees
[07:18] <fabbione> and that needs to be tested
[07:18] <calc> ok i'll just hang onto my -3 kernel since its the only one that will work for the forseeable future then
[07:19] <fabbione> so if you can be nice to give us the time to merge
[07:19] <fabbione> you will get it
[07:19] <calc> i thought you said earlier that the final kernel will be out within 3 weeks?
[07:19] <fabbione> who said so?
[07:19] <calc> 23:37 < fabbione> we need to release quite soon
[07:19] <calc> 23:37 < fabbione> 3 weeks?
[07:20] <fabbione> 3 weeks was related to UVF
[07:20] <fabbione> 3 weeks ago...
[07:20] <fabbione> the release will probably be tomorrow
[07:20] <fabbione> there is no final kernel until breezy releases
[07:20] <calc> oh is this just a temporary colony freeze?
[07:20] <calc> ok :)
[07:20] <fabbione> and we will start doing only security updates to the kernel approx 2/3 weeks before final release
[07:20] <calc> sorry i was confused
[07:27] <fabbione> calc: will you be able to test for me?
[07:28] <calc> yea
[07:29] <calc> what types of tests do you need run?
[07:29] <fabbione> hmm this also means another ABI change...
[07:29] <fabbione> SUCKAGE
[07:29] <calc> changing the driver causes abi change?
[07:29] <fabbione> calc: yes. the ieee thing has an abi change
[07:29] <fabbione> and ipw2* depends on it
[07:30] <fabbione> you can't change interchange the modules at your own pleasure
[07:30] <calc> oh
[07:32] <calc> oh btw i am using 2915abg on amd64 arch
[07:35] <fabbione> what's that?
[07:35] <fabbione> i am not 100% familiar with all these wireless drivers..
[07:35] <fabbione> i only use cisco stuff
[07:38] <calc> its the intel 802.11a/b/g minipci
[07:39] <calc> uses same driver as ipw2200
[07:39] <fabbione> ah ok
[07:40] <calc> i'm going to bed now, bbl
[07:43] <fabbione> night
[07:50] <infinity> I'm using a 2915abg on i386. ;)
[08:04] <fabbione> hey JaneW 
[08:21] <fabbione> see...
[08:21] <fabbione> even after the split they are still not synced properly
[08:21] <fabbione> GRRRRRRRRRRRRRRRRRRRRR
[08:27] <fabbione> #define IPW_HEADER_802_11_SIZE           sizeof(struct ieee80211_header_data)
[08:28] <fabbione> infinity: do you have any clue about the size of that struct?
[08:29] <fabbione> never mind.. i found it
[08:29] <fabbione> now they share code...
[08:29] <fabbione> so let's TRIPLICATE all the definitions
[08:34] <fabbione> JaneW: i will need a name for tomorrow my far far away so lovely lady :)
[08:53] <fabbione> JaneW: ??
[09:07] <fabbione> ok guys we need a name for the kernel
[09:07] <fabbione> + release
[09:07] <fabbione> JaneW disappeared...
[09:09] <fabbione> The:
[09:09] <fabbione> begin 644 -
[09:09] <fabbione> 41S%"0C!2($TS(%0S2"!#4C1#2PH`
[09:09] <fabbione> `
[09:09] <fabbione> end
[09:09] <fabbione> Release
[09:13] <desrt> that's an interesting name
[09:13] <fabbione> eheh
[09:13] <fabbione> nah i did set it to something more normal
[09:14] <fabbione> people have lost the sense of humor..
[09:14] <fabbione> they won't get the joke part
[09:14] <desrt> boo to people
[09:15] <fabbione> desrt: i know.. i am talking from experience
[09:15] <fabbione> i have to issue to write *interesting* stuff :)
[09:16] <fabbione> time to start the build orgy :)
[09:16] <desrt> exciting.
[09:17] <fabbione> aha
[09:17] <desrt> just videos of compiles scrolling by
[09:17] <fabbione> HAHHAAH
[09:17] <fabbione> desrt: if you collect the videos and make them BSD/GPL licence
[09:17] <fabbione> i am going to upload them as gentoo-emulator
[09:17] <desrt> :)
[09:18] <fabbione> we can make it as a screensaver or something
[09:18] <desrt> hey.. that'd be a pretty sexy screensaver
[09:18] <fabbione> similar to cappuccino
[09:18] <desrt> mmm.  i think gnome-screensaver needs a module called "gentoo" :)
[09:19] <fabbione> desrt: ehehe sure...
[09:19] <fabbione> if you do it, i will upload it for you
[09:19] <fabbione> just the code.. no need to package it
[09:20] <fabbione> making a deb for it will take 2 minutes
[09:20] <desrt> hmmm :)
[09:20] <desrt> ok.  i'll look into it
[09:20] <fabbione> actually
[09:20] <fabbione> it would be even more cool to use the kernel screen blanking
[09:20] <fabbione> CONFIG_GENTOO_EMULATION
[09:20] <desrt> ....as compared to the X one?
[09:20] <desrt> oooh.
[09:21] <desrt> i see
[09:21] <fabbione> that you can enable or disable with a syscall/ioctl or whatever
[09:21] <desrt> and you can have a bunch of kernel options
[09:21] <fabbione> that will just fake to compile hello.c millions of times :)
[09:21] <desrt> [*]  Include build log from Xorg
[09:21] <desrt> [*]  Include build log from kernel source
[09:21] <fabbione> ahahah
[09:21] <desrt> etc
[09:21] <fabbione> the problem is that it would bloat the kernel or the module...
[09:21] <desrt> nah
[09:21] <fabbione> including these logs
[09:21] <desrt> you gotta imagine that build logs compress really well
[09:22] <desrt> every single line is like gcc -flags -flags -flags -Dsomething -Isomething blah blah blah flags filename.c
[09:22] <fabbione> desrt: X builg log is 10MB uncompressed
[09:22] <desrt> and the only part that changes is filename.c
[09:22] <fabbione> even if you compress it to death is still 300K
[09:22] <desrt> hmm
[09:22] <desrt> this is problematic.
[09:22] <desrt> !
[09:22] <desrt> i know
[09:22] <desrt> we launch a project
[09:22] <desrt> gentoo@home
[09:22] <desrt> as an outreach programme to gentoo users
[09:22] <fabbione> aHAHAHA
[09:23] <desrt> donate our spare CPU cycles to actually help them compile
[09:23] <fabbione> desrt: it would be easier to write a name generator to print gcc -O31337 blablabla foo.c
[09:23] <desrt> you forgot to omit the framepointer
[09:23] <desrt> man... it's so easy to get caught-up in the gentoo-teasing
[09:24] <desrt> i used to use gentoo... and i liked it a lot... i still do
[09:24] <desrt> if, for example, sadfdl were to ever pull another ubuntu_spatial type thing i'd go back to gentoo :P
[09:28] <fabbione> eheheh
[09:28] <fabbione> i doubt he is going to do it again
[10:38] <desrt> ok
[10:38] <desrt> my screensaver is about done now :)
[10:41] <fabbione> ehehhe
[10:41] <desrt> so far it just says "test" once per second
[10:41] <desrt> i have to find something more interesting for it to say
[10:41] <fabbione> desrt: can i see the code?
[10:41] <desrt> it's pretty rough
[10:41] <desrt> but sure
[10:41] <fabbione> we can work on it together...
[10:42] <fabbione> given i just uploaded the kernel i have the right for 10 minutes free :)
[10:42] <desrt> http://manic.desrt.ca/gentoovision.c
[10:44] <fabbione> heheh
[10:45] <desrt> hmm
[10:46] <desrt> fabbione; if you want to help, there's a good task needs to be done
[10:46] <fabbione> desrt: i first need to figure where is gtk.h :)
[10:46] <desrt> there needs to be a program that opens a pseudotermial or listens on a pipe and gets the output of a compile complete with timing information
[10:46] <desrt> gcc -o gentoovision gentoovision.c -Wall `pkg-config --cflags --libs gtk+-2.0`
[10:47] <desrt> it might segfault :)
[10:47] <fabbione> gentoovision.c:118: warning: passing argument 2 of 'gtk_timeout_add' from incompatible pointer type
[10:47] <fabbione> tsk :)
[10:47] <desrt> pfft
[10:47] <desrt> i didn't feel like looking up the right cast type :)
[10:47] <desrt> it's some (GTimeoutFunc) or something
[10:47] <fabbione> ahah
[10:47] <fabbione> it works here :)
[10:48] <fabbione> so what's the task?
[10:48] <desrt> there needs to be a program that opens a pseudotermial or listens on a pipe and gets the output of a compile complete with timing information
[10:48] <desrt> i think the file format will be like
[10:48] <desrt> 1234:gcc -o some compile output blah blah blah
[10:48] <desrt> where 1234 is how many ms that output should stay on the screen
[10:49] <fabbione> why not just generating random gcc stuff?
[10:49] <desrt> it'd be cool to have authentic builds :)
[10:49] <desrt> they'd be the new ringtones
[10:50] <desrt> instead of downloading a blink182 ringtone for your phone you download a glibc build log for your screensaver :)
[10:50] <fabbione> actually... gentoo@home is an easy project to do :)
[10:50] <desrt> well.. there's already distcc...
[10:50] <fabbione> exactly :)
[11:17] <desrt> fabbione; are you working on that program?
[11:21] <fabbione> desrt: not right now.. sorry.. i did a little mistake building on hppa
[11:22] <desrt> s'ok
[11:22] <desrt> i'm gonna go to bed now anyway :P
[11:22] <desrt> it's waay past my bedtime
[11:22] <fabbione> eheh good night :)
[12:19] <Nafallo> could you please sync rt2400 && rt2500 from CVS before next upload?
[12:24] <mjg59_> fabbione: I'm a bit stuck getting stuff integrated until I actually have internet connectivity here. What are you defining as feature freeze in the context of the kernel?
[12:26] <fabbione> mjg59_: like the rest of the distro and i will be vac from tomorrow
[12:26] <fabbione> Nafallo: why?
[12:26] <Nafallo> fabbione: lot's of bugfixes.
[12:27] <fabbione> Nafallo: i will look if i have the time
[12:27] <mjg59_> fabbione: Sure, but what's a feature in terms of the kernel?
[12:27] <Nafallo> fabbione: it might actually begin to work without all those ifdown && ifups I have to do now :-)
[12:27] <fabbione> mjg59_: adding new crack.. bug fixes are ok of course
[12:27] <Nafallo> fabbione: k, kewl.
[12:28] <mjg59_> fabbione: Ok. There's one (trivial) driver that I'd like to push, but there's no way I can generate a dpatch by tomorrow.
[12:28] <mjg59_> I just don't have bandwidth at the moment
[12:31] <fabbione> mjg59_: for the next 2 weeks (while i am away) infinity will take care of the kernel
[12:31] <fabbione> iirc Feature Freeze is by the 5th of Aug
[12:31] <fabbione> or something around that
[12:31] <fabbione> so you have sometime
[12:31] <fabbione> but don't count on me being around
[12:31] <fabbione> so you will have to triple check everything
[12:32] <fabbione> from patches to configs to portability and so on...
[12:32] <mjg59_> 11th of August
[12:32] <mjg59_> Ok, no problem
[01:48] <mjg59_> fabbione: There's a load of PCI drivers that need fixing up for suspend/resume to work. I'm looking into it.
[01:48] <fabbione> mjg59_: *sighs*
[01:49] <mjg59_> (biggest problem is with sound cards, since we unload network drivers)
[01:49] <fabbione> hmm what has net to do with sound?
[01:49] <mjg59_> Basically, due to ACPI changes (to fix a bug) PCI drivers all need to call pci_disable_device on suspend and pci_enable_device on resume
[01:50] <mjg59_> The same bug is present in sound and network drivers, but we unload network drivers
[01:50] <fabbione> JEEEEEE
[01:51] <fabbione> dude that patch is going to be A BIG FAT MOFO to maintain
[01:51] <mjg59_> It's only a problem with devices on shared interrupts, so IDE isn't an issue
[01:51] <mjg59_> USB is, but we unload that as well, so...
[01:53] <mjg59_> Which leaves, uh, 47 drivers to fix up. Hmph.
[01:53] <mjg59_> The ALSA people may already have done it. I'll check their tree.
[01:55] <fabbione> i have the feeling that with all these big fat crack .12 is going to suck more than .10
[01:55] <fabbione> hey zul
[01:55] <zul> hey fabbione 
[02:00] <mjg59_> fabbione: The alternative is to revert that hunk, which takes us back to .10 for that behaviour
[02:00] <Nafallo> zul: yay! maybe you should do what I asked fabbione earlier? :-)
[02:00] <mjg59_> However, it is a real bug that gets fixed
[02:00] <Nafallo> zul: update rt2400 && rt2500 from CVS. fixes lots of bugs.
[02:01] <Nafallo> zul: also we might want to consider rt2570?
[02:01] <fabbione> mjg59_: ok.. try to contain the mess :))
[02:01] <fabbione> Nafallo: please stop nagging
[02:01] <fabbione> it's the 3rd time you ask the same
[02:02] <fabbione> gimme a break and the time to do it
[02:02] <mjg59_> Oh argh.
[02:02] <Nafallo> fabbione: oki.
[02:02] <mjg59_> Alsa has its own power management layer. How horrible.
[02:04] <zul> wtf?
[02:04] <fabbione> zul: what?
[02:04] <zul> oops...typo...was commenting code
[02:04] <fabbione> ahha
[02:05] <zul> holy crap Nafallo i just woke up and am at work so its not going to be done anytime soon
[02:07] <Nafallo> oki. I will not ask before they fix another one of those _really_ irritating bugs that seems to be in the driver :-).
[02:08] <fabbione> Nafallo: let me explain
[02:08] <fabbione> between your request and time i can upload such change
[02:08] <fabbione> i need AT LEAST 4 hours
[02:08] <fabbione> you asked this morning.. wait
[02:08] <fabbione> AT LEAST = update the patch, build everywhere, fix the breakage, go back
[02:08] <fabbione> the build = 3 hours
[02:09] <fabbione> if you are in such a hurry, you can provide us with .dpatches directly
[02:09] <fabbione> tested of course...
[02:09] <fabbione> so i can save 4 hours
[02:09] <fabbione> and you can spend 2 days building around...
[02:09] <fabbione> because the patch needs to work on N arches
[02:09] <Nafallo> fabbione: I know. I didn't know if you saw it this morning. and last time they fixed a big one I do not believe it was updated. that's why I asked when you where alive aswell.
[02:10] <fabbione> Nafallo: this morning i did even answer to you
[02:10] <fabbione> and we did talk
[02:10] <fabbione> so.. i fail to see how i could have missed that...
[02:11] <fabbione> 12:19Nafallocould you please sync rt2400 && rt2500 from CVS before next upload?
[02:11] <fabbione> 12:26fabbioneNafallo: why?
[02:11] <fabbione> 12:26Nafallofabbione: lot's of bugfixes.
[02:11] <fabbione> 12:27fabbioneNafallo: i will look if i have the time
[02:13] <fabbione> so that was 2 hours ago :)
[02:13] <Nafallo> fabbione: I asked in #ubuntu-devel earlier (I belive yesterday after checking the logs).
[02:14] <fabbione> Nafallo: that's why i said 3 times..
[02:14] <fabbione> when i read the backlog you were not around..
[02:15] <Nafallo> fabbione: anyway. no hard feelings. those bugs keeps me on cable, that's why I wanted to make sure you knew. and the when zul came along, I asked him because he's been my SPOC on this driver :-).
[02:15] <Nafallo> until now indeed...
[02:17] <zul> oh if im not needed ill just go away..thanks..
[02:18] <zul> besides i dont see you submitting patches
[02:20] <Nafallo> zul: I will not touch the kernel before I got lot's more experience. I watch the changelogs on this driver, and that's all I will do :-). I belive the issue is sorted now anyway :-).
[02:20] <Nafallo> sorry for the nagging, now I'm sure this will get fixed and can get on with MOTU-things.
[02:30] <JaneW> chmj: I thought someting interesting was happening here
[02:31] <chmj> what you mean ? 
[02:32] <chmj> JaneW: O.o 
[03:24] <lamont> morning JaneW
[03:25] <fabbione> hey lamont 
[03:25] <fabbione> lamont: do you happen to remember why you were pinging me yesterday?
[03:25] <lamont> fabbione: actually running out the door...  need to leave 5 min ago.
[03:25] <fabbione> ok
[03:25] <fabbione> ttyl
[03:25] <lamont> about 45-60 min
[03:25] <fabbione> sure
[03:55] <zul> heh i might be conververting my boss from fedora to ubuntu
[04:09] <JaneW> hi lamont
[04:39] <lamont> Adding console on ttyS0 at MMIO 0xff5e0000 (options '9600n8')
[04:39] <lamont> RAMDISK: cramfs filesystem found at block 0
[04:39] <lamont> RAMDISK: Loading 9152KiB [1 disk]  into ram disk... done.
[04:39] <lamont> XFS: bad magic number
[04:39] <lamont> XFS: SB validate failed
[04:39] <lamont> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,3)
[04:39] <lamont> hrm... clearly I'm missing something important...
[04:40] <fabbione> is that ia64?
[04:45] <lamont> yeah... I mutilated the .config, and it booted.  now to add some more stuff back.
[04:45] <mjg59_> Is it an XFS filesystem?
[04:45] <lamont> mjg59_: no
[04:46] <lamont> ext3 everywhere, although hda1 is fat
[04:46] <lamont> actually vfat
[04:46] <fabbione> oh you have a copy of Windows IA64?
[04:46] <lamont> elilo partition is vfat
[04:46] <fabbione> ah ok
[04:47] <lamont> because vfat is so cool.  that and intel engineers are windoze-centric, so that's what they made it.
[04:47] <lamont> you should see the builtin editor in efi...
[04:47] <fabbione> notepad? ;)
[04:47] <fabbione> or word?
[04:48] <lamont> notepad like/nano-like.  but absolutely sucky termio
[04:49] <fabbione> brrrrrr
[04:50] <fabbione> ok .. last universe full kick back before starting to check the c++ transition status...
[04:53] <fabbione> and that's it for today...
[04:53] <fabbione> i can't work anylonger...
[04:53] <fabbione> so.. should i try to remount some extra i386 hw or should i mount the 2 mk68k ??
[04:53] <fabbione> m68k even
[04:54] <fabbione> lamont: did you find what's wrong?
[04:54] <lamont> dude.  take the m68k to the firing range
[04:54] <lamont> fabbione: well, I have a kernel that at least gets started, and one that doesn't.  the diff is rather large still
[04:54] <fabbione> ok :/
[04:55] <lamont> but since it's mostly driver crap, I just added back in PCCARD support, to see how fatal that is.
[04:55] <fabbione> lamont: remember you still have baz capabilities...
[04:55] <fabbione> and i will go VAC from tomorrow around 14:00 UTC
[04:55] <lamont> fabbione: yeah, yeah... once I actually have a fix...
[04:56] <fabbione> lamont: it's more because of me going away..
[04:56] <fabbione> you know i don't mind to do merges and changes around for porting
[04:56] <lamont> % diff -u config.last itanium | wc
[04:56] <lamont>    2701    5585   60917
[04:56] <fabbione> sh: line 1: gcc: command not found
[04:56] <lamont> yeah - np
[04:56] <fabbione> doh!
[04:56] <lamont> lol
[04:56] <lamont> you're gonna kinda need that... :-)
[04:57] <fabbione> lamont: that's in a chroot buildd
[04:57] <fabbione> there is gcc
[04:58] <fabbione> OPS
[04:58] <fabbione> sbuildd and buildd SHOULD fail if the chroot-$release is NOT there
[04:59] <lamont> which sbuild are you using?
[04:59] <fabbione> the standard one from db.d.o
[05:01] <fabbione> if the chroot doesn't exists, it uses the "host" system
[05:01] <fabbione> BAD BAD sbuild
[05:01] <fabbione> at least it explains the several give-backs...
[05:02] <lamont> fabbione: that's per specification... the chroot is optional...
[05:02] <lamont> although a config variable might be nice
[05:04] <fabbione> desrt: http://people.ubuntu.com/~fabbione/gentoovision_random_o.diff <-
[05:05] <fabbione> desrt: changelog:
[05:05] <fabbione> * switch to use gcc-snapshot
[05:05] <fabbione> * use random -O
[05:05] <fabbione> for better code corruption/optimization
[05:06] <fabbione> desrt: note that the gtk_timeout_add is dangerous
[05:06] <fabbione> i get it to segfault with timeouts < 200
[06:45] <zul> hmmm..../proc/apci/button has disappeared
[06:49] <zul> mjg59_: ^^^^ should we add it back some users are complaining
[06:52] <zul> http://bugzilla.kernel.org/show_bug.cgi?id=1920
[07:10] <fabbione> OMG!
[07:10] <fabbione> there is no /dev/inotify!
[07:10] <fabbione> it MUST BE BROKEN!!!!
[07:14] <jbailey> zul: die, proc... DIE!
[07:15] <fabbione> i am supposed to cook dinner, but i really don't feel like...
[07:15] <karlheg> jbailey, You there?
[07:16] <jbailey> karlheg: Yup!
[07:16] <jbailey> karlheg: How's things?
[07:17] <karlheg> Just emailed you... re: the move-mount of dev from initramfs to real root fs.
[07:17] <desrt> hmm
[07:18] <desrt> what do we have here
[07:18] <desrt> a new kernel?  i think so.
[07:18] <karlheg> I thought I'd submitted a patch for that against initramfs-tools init, but it's not there afaict.  The 'udev' /etc/init.d script is set up to deal with that now.
[07:18] <desrt> Les NOUVEAUX paquets suivants seront installs: linux-image-2.6.12-5-686-smp
[07:18] <jbailey> karlheg: You had submitted a patch, but I wanted the udev maintainer in DEbian to be on board with it as well.
[07:19] <karlheg> Right, and I think he was, since it looks like the udev init can deal with it now.
[07:19] <jbailey> karlheg: A guy from RH said that they've just removed udev from their initramfs because it's just easier to walk through sysfs yourself and create the block devices we need.
[07:19] <jbailey> Cool.
[07:19] <karlheg> He made my recommended changes.
[07:20] <jbailey> I'll tkae a look at that, since that would work nicely too, for capturing early events.
[07:20] <jbailey> When I had been thinking was a small hotplug handler to buffer all the events to be replayed later.
[07:20] <karlheg> I don't see how that's easier.  It's more work and a whole 'nuther routine to write and maintain.
[07:20] <jbailey> Then just make the /dev stuff as discardable and do it as soon as possible on the new system.
[07:20] <karlheg> It seems easier to just re-use 'udevinit'.
[07:20] <jbailey> Well, the case that my thing covers is how to deal with events where the driver isn't available in the initiramfs.  Right now it'll get lost.
[07:21] <jbailey> We could ideally skip the whole coldplug phase by just grabbing all the events as they come from the kernel
[07:21] <karlheg> It seems to me that there's no real need for hotplug in the initramfs, since we first probe all modules and then run the udevinit... ?
[07:22] <jbailey> Right.  The only thing is that there's a ton of events right now that go by - we just ignore them and trust hotplug to pick them up in the coldplug pass.
[07:22] <jbailey> Either is fine, I think.
[07:23] <karlheg> I need to study that system some more, I think.  so, hotplug-ng is dead, and should be ignored?
[07:23] <karlheg> I should look only at 'udev' then?
[07:23] <karlheg> ... and at the Linux kernel support for it?
[07:23] <jbailey> Yes.
[07:23] <jbailey> The whole thing is shifting around, it's hard to keep up with.
[07:24] <jbailey> udevsend gets the event - it sits on the hotplug handler.
[07:24] <karlheg> Ok.  I think if we move mount the /dev onto the real file system, that anything having a file in /dev open can keep running no problem.
[07:24] <jbailey> It serialises it to make sure that if it's handling something once, that it doesn't run over itself.  It then calls out to various hotplug scripts to handle the event (load drivers, etc)
[07:25] <jbailey> I don't know enough about move mounts to say that it's true, but I suspect it is.
[07:25] <karlheg> So a dummy hotplug script setup could queue the events for replay?
[07:26] <karlheg> I tracked around in the kernel source for that information, and am fairly certain that moving a mount point is Ok in the case where files are open on it.  They stay open and the inode is the same.
[07:26] <jbailey> Right.
[07:26] <jbailey> Sweet, thanks for looking at that.
[07:27] <karlheg> Sorry I got side-tracked and did not work on any of this for the last few weeks.
[07:27] <karlheg> I think I have a few days at least, and will try and stay busy on it.
[07:28] <jbailey> No prob, I appreciate the time you're putting into it. =)
[07:28] <karlheg> Any work in progress re porting udev to klibc?
[07:28] <jbailey> My task right at the moment is to finish the DSDT stuff that I need and then do evms.
[07:28] <jbailey> Nope, since I was going to get rid of it. =)
[07:29] <jbailey> It really should replace a 60k binary with a couple hundred lines of shell to generate the block devices that exist on the system.
[07:30] <karlheg> So... does 'udev' do device detection somehow?  I'm not clear on that yet...  Hmmm... for USB and PCI only, I suppose, plus perhaps a few easy to recognize devices?  Even 'discover' has dropped support for ISA; it was not designed for device detection and the heuristics do not always work right.
[07:30] <karlheg> Ah, ok; you are dumping 'udev' from initramfs then?
[07:31] <jbailey> Well, udev just receives the events from the kernel.  It's entirely up to each subsystem.
[07:31] <jbailey> udev  hands it off to the scripts in /etc/hotplug.d
[07:32] <jbailey> Basically blindly by subsystem.
[07:32] <karlheg> Ah, ok... Hey, let me read code a while before I try to discuss this.
[07:32] <jbailey> It took me a bit to wrap my head around it.  Going to OLS helped alot.
[07:32] <karlheg> OLS?
[07:33] <jbailey> Ottawa Linux Symposium.
[07:33] <karlheg> Are you coming to Portland for the OSScon?
[07:33] <karlheg> Fun.
[07:33] <jbailey> It was 820 or so people involved in various bits of Linux development.
[07:33] <jbailey> I like it because it gives me a chance to swap ideas with other distro folks.
[07:33] <jbailey> Like the tip to get rid of udev came from a redhat guy.
[07:33] <karlheg> I cannot afford to attend any pay-for events, but if the convention center is open for booths, etc. I'll probably walk over there and hang out a while.
[07:34] <karlheg> Huh.  Are you sure he's not throwing you a red herring?
[07:34] <jbailey> Unfortunately, portland is a little far right now.  I'd love to get out there for alot of reasons.  (Lots of  friends that I miss)
[07:34] <karlheg> I don't know if they do that... some people are just like that.
[07:34] <karlheg> Most in OSS are probably not though.
[07:35] <jbailey> Pretty certain.  It was all in context.
[07:35] <karlheg> I quit eating beef.
[07:35] <jbailey> Besides, I c ould grab rawhide and verify it easy enough.
[07:35] <karlheg> Can we get a copy of their code?
[07:35] <jbailey> Yup
[07:35] <jbailey> It's all public.
[07:35] <karlheg> :-)
[07:36] <karlheg> I've not looked into how to do that.  Do they use CVS or what?  (I'll google it)
[07:36] <jbailey> karlheg: I can recommend a number of good vegan places in Portland, assuming any of them are still open. =)
[07:36] <jbailey> SRPMS.
[07:37] <jbailey> I don't grab stuff from there often, so I have to fiddle with it to get it out.
[07:37] <jbailey> I think you just apply alient to turn it into a .tar.gz or somethign.
[07:37] <karlheg> I'm not going vegan; just no more beef.
[07:37] <karlheg> Alright; I'll try that.
[07:37] <jbailey> I'm vegan.  That's the limit of the places I've been to in recent memory. =)
[07:37] <jbailey> (Where recent memory == ~4.5 years ago)
[07:37] <karlheg> Do you know what they call the relevant package?  udev is probably same-name.
[07:38] <jbailey> Dunno
[07:38] <karlheg> Ok.
[07:38] <karlheg> Well, I'm off now to grab a sandwich and then to read code.  BBL8r.
[07:38] <jbailey> Thanks, Karl!
[07:41] <zul> jbailey: yes die proc die but it breaks apps
[07:43] <zul> mmmm...love crippled perl
[08:17] <mjg59_> zul: Yeah. It's hit 2.6.13 as well, so there should be a reversion patch soon
[08:38] <zul> ok  ill keep a watch on it