[12:22] <tseng> wow
[12:23] <Keybuk> he's going to be doing that all weekend ...
[12:24] <Keybuk> we tried to stop his client earlier, but it looks like it's still keeping-on-coming-back :-/
[12:26] <ogra> i hope he has a flatrate
[12:26] <mdz> HiddenWolf: we implemented that months ago
[12:28] <HiddenWolf> mdz, how do you turn it on?
[12:28] <HiddenWolf> I had a 560mb  /var/cache/apt/archives
[12:29] <HiddenWolf> And mine was the smallest of the people that I asked to check.
[12:31] <mdz> it is on by default in breezy
[12:31] <Keybuk> HiddenWolf: what app are you using to install and upgrade software?
[12:31] <HiddenWolf> Keybuk, plain apt.
[12:32] <mdz> files are expired after 2 days by default
[12:32] <HiddenWolf> mdz, no option in synaptic to set anything, and I did not download 560mb of hoary changes over the last 48 hours.
[12:32] <HiddenWolf> mdz, s/hoary/breezy
[12:33] <HiddenWolf> mdz, that was _before_ I did tonight's gnome/xorg download, 100+ packages for 40mb total.
[12:34] <mdz> mvo did change that code recently; it's possible that it stopped working
[12:34] <Keybuk> syndicate scott% du -sh /var/cache/apt/archives
[12:34] <Keybuk> 474M    /var/cache/apt/archives
[12:34] <mdz> er
[12:34] <mdz>     MaxAge=0
[12:34] <mdz>     MinAge=2
[12:34] <mdz>     MaxSize=0
[12:34] <mdz> those defaults are not what they used to be
[12:35] <HiddenWolf> mdz, closing my bug before checking it actually worksforyou? ;)
[12:35] <mdz> HiddenWolf: yes. your bug said "hey it would be nice if this were implemented" and it clearly already was
[12:36] <Keybuk> it's been a long release for him
[12:36] <mdz> if it had said "cache pruning doesn't seem to be working anymore" that would have been worth a closer look
[12:36] <HiddenWolf> mdz, besides, it'd be good to put the options in synaptic, and allow a user to set size/age limit.
[12:38] <mdz> that's a feature
[12:38] <mdz> whereas the cache not being pruned by default is a bug
[12:38] <HiddenWolf> mdz, true
[12:39] <HiddenWolf> Well, I'm not sober, and it's past midnight. I'll leave you to it.
[12:39] <HiddenWolf> Night.
[12:39] <ogra> HiddenWolf, err, you can set this options
[12:39] <ogra> HiddenWolf, in update-manager
[12:40] <HiddenWolf> ogra, just "clear after download" "clear now" or "cache everything" in synaptic.
[12:40] <HiddenWolf> ogra, if that's the case, then there's a difference between the two that I'd consider a bug.
[12:41] <ogra> i have "set maximum size for the package cache" and "delete old packages after:"
[12:41] <ogra> and its been there since quite a while....
[12:42] <HiddenWolf> ogra, not in my synaptic.
[12:42] <HiddenWolf> which was just dist-upgraded 10 minutes ago.
[12:42] <ogra> HiddenWolf, i didnt talk about synaptic
[12:42] <HiddenWolf> ogra, then synaptic and u-m disagree. I never see update-manager tho. command line works for me.
[12:43] <ogra> HiddenWolf, you asked for an option... its obviously there
[12:44] <ogra> mdz, xinit is updated in the archive, a new cdbuild would be nice
[12:44] <mdz> ogra: binaries are in?
[12:44] <ogra> according to http://archive.ubuntu.com/ubuntu/pool/main/x/xinit/, yes
[12:44] <mdz> running
[12:44] <ogra> thanks
[12:45] <ogra> i hope thats the last one...
[12:45] <HiddenWolf> ogra, make me happy, put the option in synaptic. ;)
[12:46] <HiddenWolf> and good night. :)
[12:46] <ogra> HiddenWolf, i'm not the synaptic maintainer :)
[01:01] <Mitario> hello everyone
[01:04] <bddebian> Hello Mitario 
[01:57] <elmo> Kamion: is your seed regeneration stuff working?
[02:03] <bddebian> THANK YOU ELMO!
[02:35] <Riddell> bddebian: what did elmo do?
[02:36] <Riddell> libdebtags1, nice
[02:37] <bddebian> Riddell: Got me your debtags, libdebtags, and tagcoll and got me my upload rights :-)
[02:37] <crimsun> hmm, load of gstreamer engine fixes in amarok 1.3.1
[02:38] <Riddell> crimsun: what was wrong with it?
[02:38] <crimsun> Riddell: various people reported "buzzing" with gstreamer engine in 1.2.[34] 
[02:39] <tseng> Reinstallation of libxml-libxml-perl is not possible, it cannot be downloaded.
[02:40] <elmo> tseng: that'll sort itself out in next cron.daily
[02:40] <tseng> elmo: great.
[02:40] <slomo> elmo: when does cron.daily run? ;)
[02:41] <Mez> slomo every 20 mins
[02:41] <elmo> 30
[02:41] <Mez> ah
[02:41] <Mez> nearly ;)
[02:41] <slomo> daily? every 30 minutes? ah... well ok ;)
[02:42] <Mez> not bad for something I read about 3 months ago
[02:44] <ogra> brb
[02:50] <sabdfl> night all. THAT's the Badger
[02:50] <ogra_ltsp> mdz, edubuntu default install on i386 is good
[02:51] <mdz> ogra_ltsp: fantastic
[02:51] <ogra_ltsp> mdz, going to test the workstation 
[02:51] <ogra_ltsp> brb
[03:17] <daniels> Mithrandir: i'm against adding new functionality and extensions to xnest
[03:18] <daniels> Mithrandir: i'd much rather gdm pass the geometry
[03:23] <ajmitch> daniels: any known problems with setting 855resolution to run earlier in bootup?
[03:23] <daniels> ajmitch: nope
[03:23] <ajmitch> found a bug in malone about people wanting it to start before gdm
[03:23] <ajmitch> ok, will upload
[03:31] <daniels> thanks
[03:31] <daniels> make sure you migrate it
[03:32] <ogra_edu> mdz, workstation is fine too
[03:32] <daniels> because update-rc.d won't migrate them for you, it will say 'oh, you already have links for this, good work then'
[03:32] <ajmitch> I see
[03:33] <Mez> wtf? regular ogra?
[03:33] <ajmitch> why not?
[03:33] <ajmitch> he can clone himself if he wants :)
[03:34] <ogra> mdz, bsed on Kamions info from the amd64 install, i think we can assume that it only suffered the same bugs i had on x86, so i would say lets publish this...
[03:34] <slomo> can someone remove gmime2.1 from incoming? the connection stalled :/
[03:35] <tseng> slomo: elmo was just here
[03:35] <ogra> mdz, but i'm way to tired to rewrite the announcement now, ok to send it out tomorrow ? 
[03:35] <tseng> slomo: but it should upload again ok
[03:36] <elmo> done
[03:36] <slomo> elmo: thanks :) can i really just reupload like tseng said?
[03:37] <elmo> no
[03:37] <elmo> well, actually, yes
[03:37] <tseng> depends how much went up, but stuff that isnt properly formed is deleted anyway
[03:37] <elmo> you can't overwrite a file, but if you upload again, the bad upload would get REJECTed and moved out of the way
[03:37] <tseng> right?
[03:37] <elmo> tseng: only if a .changes makes it
[03:37] <elmo> stuff without a .changes is ignored
[03:38] <elmo> (yes, that means you, whoever uploaded photoshop)
[03:38] <bmonty> elmo: can you do a sync of ace?
[03:38] <slomo> lol
[03:38] <tseng> good one
[03:39] <elmo> bmonty: are you a MOTU?
[03:39] <ajmitch> elmo: are you able to sync from debian's NEW queue, or shall I wait for it to be processed there?
[03:39] <bmonty> nope
[03:39] <elmo> bmonty: please get a MOTU to ack or proxy your request 
[03:39] <elmo> ajmitch: I can't sync from NEW, it's not public
[03:39] <ajmitch> alright
[03:39] <bmonty> elmo: will do
[03:40] <ajmitch> elmo: ack on ace sync
[03:40] <azeem> hrm
[03:40] <elmo> bmonty: I need your name + email
[03:40] <bddebian> Heya azeem 
[03:40] <azeem> ajmitch: can you tell elmo to sync/import libghemical (needed for ghemical, a user bugged me)?
[03:41] <azeem> hey Barry
[03:41] <Lathiat> azeem: i test all that
[03:41] <Lathiat> azeem: and it builsd however ghemical is fairly useless
[03:41] <azeem> Lathiat: why is that?
[03:41] <Lathiat> azeem: i think a new ghemical version is needed or lighemical
[03:41] <Lathiat> azeem: the window you draw in doesnt come up
[03:41] <Lathiat> and theres no way to bet it up
[03:41] <Lathiat> *get i up
[03:41] <bddebian> Lathiat: Even in the newer version?
[03:42] <Lathiat> bddebian: define newer version
[03:42] <bddebian> Lathiat azeem: i think a new ghemical version is needed or lighemical
[03:42] <Lathiat> i had libghemical 1.9, ghemical 1.5
[03:42] <Lathiat> built with mopac support
[03:42] <Lathiat> (and ive used ghemical before so im pretty sure it wasnt rigth)
[03:43] <azeem> yeah, I got a report about that for Debian as well
[03:43] <azeem> Lathiat: thanks
[03:43] <Lathiat> azeem: so we could do with 1.9 or something?
[03:43] <Lathiat> azeem: (are you the debian maintainer?)
[03:43] <azeem> probably and yes
[03:43] <Lathiat> azeem: is a new ghemical likely to come soon?
[03:44] <azeem> Lathiat: upstream?
[03:44] <Lathiat> azeem: somethign in debian that makes it work :) whatever that is
[03:44] <azeem> Lathiat: well, I wanted to look at it soonish, if you say 1.9 works, I can do that tomorrow
[03:44] <Lathiat> azeem: i havent tried 1.9
[03:45] <Lathiat> azeem: (only libghemical was 1.9, i stoel taht from debian, the ghemical i stole was 1.5)
[03:45] <azeem> I didn't get it to build some time ago, so I went for 1.5 in the meantime
[03:45] <Lathiat> ok
[03:46] <elmo> mdke: ?
[03:50] <Lathiat> mjg59: any news on #14659.. its rather nasty ? 
[03:50] <Lathiat> mjg59: oops, i meant #14658
[03:51] <crimsun> elmo: please sync vlc from Sid; it's fine to blow away the Ubuntu changes (I'll merge them back in by hand)
[03:51] <elmo> crimsun: um, if you know you're going to do an ubuntu upload immediately after I sync, there's no point in me syncing
[03:51] <crimsun> so it's better to just upload directly?
[03:51] <Lathiat> crimsun: just make sure you pass -v to debuild
[03:52] <Lathiat> to get all the changelog in .changes
[03:52] <crimsun> sure, I can do that.
[03:52] <elmo> crimsun: if you know you're going to be modifying it from Debian, yes
[03:52] <crimsun> all right, thanks.
[03:55] <elmo> bmonty: ok to override ubuntu changes?
[03:56] <elmo> [Updating]  ace (5.4.2.1.0-1ubuntu2 [Ubuntu]  < 5.4.7-3 [Debian] )
[03:56] <bmonty> elmo: I don't see any way to avoid it....the package won't build without syncing in the debian patches for gcc 4.0
[03:58] <elmo> bmonty: err, but are the ubuntu changes merged into the debian or otherwise no longer relevant?
[03:58] <Lathiat> we have 1 build-dep change. if thats nto fixed upstream we can easily put it back
[03:58] <elmo> guys
[03:58] <elmo> I'm not being funny, but you should be checking this stuff BEFORE you ask for syncs
[03:58] <Lathiat> elmo: i'll sort it uot and we'll get back to you :)
[03:58] <Lathiat> bmonty: ->#ubuntu-motu
[03:58] <elmo> thanks
[04:02] <Lathiat> elmo: ok, please sync
[04:02] <elmo> done
[04:02] <Lathiat> elmo: thanks :)
[04:04] <Mez> hmm
[04:04] <Mez> if firefox has changed name from mozilla-firefox -> firefox
[04:04] <Mez> should stuff like mozilla-firefox-locale-fr-fr change to firefox-locale-fr-fr
[04:05] <bddebian> Probably.  Consistency is a GOOD thing ;-)
[04:05] <Mez> hmm
[04:05] <Mez> none of the locale have been renamed yet
[04:05] <Mez> and i think it's too close to release to do it
[04:05] <Lathiat> Mez: talk to diziet perhaps i saw he was doing some related stuff earlier
[04:05] <Mez> Lathiat, ciool
[04:08] <Mez> you got an email address for him/
[04:12] <Mez> ogra: ping
[04:29] <elmo> christ
[04:29] <elmo> there has to be a saner way to handling the seeds than this duplication
[04:34] <bddebian> elmo: Did you happen to morgue any of the ones I mentioned a while back, do you know?
[04:34] <elmo> bddebian: I've no idea sorry - it should be easy for you to check?
[04:35] <bddebian> elmo: What's the best way to check.  I don't see any binaries or source packages.  Is that enough?
[04:35] <elmo> yes?
[04:36] <bddebian> OK, sorry, just wan't sure.
[04:36] <jblack> infinity: ping
[04:36] <jblack> mdz: ping
[04:37] <mdz> jblack: yes?
[04:38] <elmo> mdz: how are merges of ubuntu changes to {edu,k}buntu handled?  manually?
[04:38] <elmo> (seed-wise)
[04:38] <mdz> elmo: yes
[04:38] <jblack> so, kind of a cute story. Remember how infinity said he was going to hijack my laptop? 
[04:38] <jblack> I went and got another one so that I could work while he had it. This one has a 1280x768 display.
[04:38] <elmo> mdz: :|
[04:38] <jblack> the first cd you had me burn doesn't use the full cd. 
[04:39] <jblack> doens't use the full screen, that is.
[04:39] <bddebian> elmo: Hmm, yaprimaxgui appears to still be there
[04:40] <elmo> yaprimaxgui |    3.1.2-1 | hoary/universe | source, amd64, i386, ia64, powerpc
[04:40] <elmo> it's in hoary
[04:40] <elmo> not breezy
[04:41] <bddebian> Shows in apt-cache policy and apt-cache source for me??
[04:41] <jblack> mdz: I don't have the second cd any more, so I'm burning a copy to make sure the fix fixed the problem you guys were looking at.
[04:41] <mdz> ok
[04:41] <bddebian> s/source/showsrc/
[04:41] <elmo> bddebian: dude, it's not in breezy
[04:41] <elmo> whatever your apt is telling you
[04:41] <bddebian> OK, sorry
[04:42] <mdz> bddebian: use apt-cache madison; that shows you where stuff is coming from
[04:42] <jblack> btw, reboot on the livecd doesn't work on this new one either.
[04:42] <bddebian> mdz: Thank you
[04:42] <bddebian> Heh, local archive, what a dolt
[04:44] <bddebian> Can I mention xezmlm without getting in trouble?
[04:50] <daniels> jblack: the new live cd should give you the full display
[04:52] <jblack> I'll rsync a third image down and check that if the 2nd one doesn't.
[05:00] <jblack> the second cd I was told to download didn't fix the screen. 
[05:00] <jblack> Burning today's livecd
[05:06] <bddebian> lamont-away: If you happen to come around can you free up debtags.  I sent up a new, fixed libdebtags1 that should meet the Dep-wait.  Thx
[05:16] <jblack> daniels: negative
[05:17] <jblack> mdz: negative. 
[05:18] <jblack> native resolution is 1280x768. The casper log for a just-burned-now livecd shows it finds 1280x768, but ends up using 1024x768 
[05:22] <daniels> jblack: full post.log and xorg.0.log would rock
[05:22] <jblack> I guess um.. well, would pastebin.org work? 
[05:28] <daniels> sure
[05:28] <jblack> Ok. still booting. 
[05:30] <daniels> thanks
[05:34] <jblack> daniels:  first one pasted. 
[05:34] <jblack> You can find it linked under pastebin.com under recent posts.
[05:34] <jblack> That's post.log
[05:35] <jblack> Ok. jblack1 and jblack2 
[05:35] <jblack> daniels: Let me know when you get them.
[05:36] <daniels> got 'em
[05:36] <jblack> Ok. standing by
[05:37] <daniels> okay, looks like your video BIOS sucks
[05:37] <daniels> you'll need a tool like 855resolution to patch it
[05:37] <jblack> Heh. 
[05:38] <jblack> I think you misunderstand. I'm not complaining about a problem. mdz asked me to test my laptop last night because it has a unusual screensize. 
[05:38] <jblack> which led to me mentioning acpi problems, which got infinity that I had lost the right to my laptop in ubz. 
[05:39] <jblack> so today I got a brand new one (its tiny and runs like 6 hours), also with a widescreen. 
[05:39] <daniels> heh
[05:39] <daniels> yeah, I was just checking that it wrote the configuration file out right
[05:39] <daniels> thanks for the testing :)
[05:40] <jblack> Welcome. 
[05:40] <jblack> btw, it doesn't look bad at 1024x768 instead of 1280x768
[05:41] <jblack> daniels: need anything else? 
[05:41] <jblack> mdz: anything else? 
[05:42] <daniels> nope, that's fine, thanks
[05:45] <daniels> ow, dude
[05:45] <daniels> ajmitch: dbtcp -- just say no.
[05:46] <bddebian> heh
[08:36] <Mithrandir> daniels: are you opposed to adding functionality to xnest even if it comes in the form of a patch?
[08:37] <daniels> Mithrandir: not hugely
[10:44] <pef> hi
[10:48] <Mez> hmm
[10:48] <Mez> how to make a file show only lines that arent duplicate
[10:48] <Mez> i.e.  using sort, to concetenarte
[10:48] <ajmitch> uniq?
[10:48] <Mez> aha :D
[10:49] <Mez> does sort not cncetenate lines?
[10:55] <Mez> hmm
[10:56] <Mez> uniq isnt Exactly what I'm looking for
[02:14] (pkern/#ubuntu-devel) At least it could replace the bloddy RhythmBox which crashes just when an iPod is plugged in (on Hoary at least)
[02:15] <pkern> Hihi and Banshee segfaults just when I hit Preferences. What a pity.
[02:15] <tseng> that will be fixed
[02:15] <tseng> very soon
[02:15] <bddebian> I think slomo is working on banshee
[02:16] <bddebian> Oh and apparently tseng too
[02:16] <tseng> bddebian: and we're talking to him, thanks :P
[02:16] <slomo> btw, preferences don't crash for me ;) but that will be fixed upstream soon
[02:16] <tseng> i think its already fixed
[02:17] <tseng> abock will give me the tarbal when he wakes up
[02:17] <pkern> tseng & slomo: Thanks. (o:
[02:17] <bddebian> Heya slomo 
[02:17] <slomo> tseng: and you said there will be no new release soon? ;P
[02:18] <tseng> slomo: i said 0.9.8 in a week
[02:18] <tseng> slomo: we get 0.9.7.1 under the table today
[02:18] <slomo> tseng: fine :)
[02:20] <azeem> Lathiat: I built ghemical-1.90 for breezy at people.debian.org/~mbanck/ubuntu-breezy
[02:20] <azeem> seems to work OK, uploading them to unstable now after a bit of cleanup
[02:23] <ivoks> ajmitch: ping
[02:26] <ajmitch> ivoks: pong
[02:27] <ivoks> ajmitch: it's ok, i resolved my problem :) sorry for bother...
[02:28] <ajmitch> ok :)
[02:47] <pvanhoof> Hey guys .. /dev/input/mice isn't created by the current Breezy setup
[02:47] <pvanhoof> yet xorg.conf uses it
[02:47] <pvanhoof> however
[02:47] <Kamion> ogra: ok, it's up
[02:47] <pvanhoof>  /dev/.static/input/mice actually is created
[02:47] <ogra> yay, thanks :)
[02:47] <pvanhoof> and works
[02:48] <Kamion> ogra: http://releases.ubuntu.com/edubuntu/5.10/ etc., see other announcements
[02:48] <pvanhoof> is this a known bug? Or should I report it?
[02:48] <Keybuk> pvanhoof: it's a known bug (#12915) though any information you can give to help debug it would be greatly appreciated
[02:48] <pvanhoof> Keybuk, ok
[02:48] <Keybuk> we have no idea why it doesn't appear for some people sometimes
[02:49] <ogra> Kamion, i wonder why we didnt just change the ip to 192.168.0.10 ... i must have been barred somehow yesterday
[02:49] <pvanhoof> ok, if somebody wants to login to my laptop .. he may
[02:49] <pvanhoof> Keybuk, one thing I know is that I have a synaptics touchpad thing and a USB mouse
[02:49] <HiddenWolf> hunger, like I said, bug daniels.
[02:49] <pvanhoof> Keybuk, and the usb mouse wasn't connected during boot
[02:49] <Kamion> ogra: what IP?
[02:49] <pvanhoof> Keybuk, perhaps that combination did something ...
[02:49] <Kamion> ogra: anyway the UK, US, and Swedish mirrors all have it
[02:50] <pvanhoof> Keybuk, and I can "disable"  the touchpad using a "FN" key on my laptop (it was disabled upon boot)
[02:50] <ogra> Kamion, the preseeded one... since you said the gatway error only occurs if gw ip = iface ip
[02:50] <Keybuk> pvanhoof: I have the same combination here
[02:50] <Keybuk> we think the problem is udev events getting lost early in the boot process
[02:50] <ogra> Kamion, thanks... fixing the announcement now
[02:50] <Kamion> ogra: because it was a late and clearly-untested change anyway and the best thing to do was to revert it
[02:50] <pvanhoof> when it's disabled .. the synaptics kernel module used to throw kernel warnings upon boot. Ps. My laptop is a acer travelmate 8000
[02:50] <Keybuk> because if you run "udevstart" once the system has settled down, the device appears
[02:50] <Kamion> insufficiently-tested, at least
[02:51] <ogra> Kamion, yes, but lets just use 192.168.0.10 if the gateway gets set up right then ...
[02:51] <Kamion> ogra: no, let's revert late untested changes
[02:51] <Kamion> standard release management practice
[02:51] <pvanhoof> root@lort:~ # ls -alh /dev/input/mice
[02:51] <pvanhoof> ls: /dev/input/mice: No such file or directory
[02:51] <pvanhoof> root@lort:~ # udevstart
[02:51] <pvanhoof> root@lort:~ # ls -alh /dev/input/mice
[02:51] <pvanhoof> crw-rw----  1 root root 13, 63 Sep 10 14:51 /dev/input/mice
[02:51] <pvanhoof> root@lort:~ #
[02:51] <pvanhoof> indeed
[02:52] <ogra> Kamion, i mean for the next builds... i cant release without a preseeded ip, thats to ugly ...
[02:52] <Kamion> ogra: sure, now - we did the right thing for preview, though.
[02:52] <ogra> yup
[02:53] <Kamion> why .10 though? just .2 I think
[02:53] <Kamion> IPs aren't particularly decimal despite their usual representation :)
[02:53] <pvanhoof> Keybuk, my first test was :  rm /dev/input/mice , unplug the usb mouse and hardware disable the touchpad
[02:53] <pvanhoof> and then a udevstart
[02:53] <pvanhoof> and /dev/input/mice got created
[02:53] <pvanhoof> so that ain't the problenm
[02:54] <ogra> Kamion, my personal preference is to put routers below .10 and servers between .10 and .20, i'm open for everything :)
[02:54] <Keybuk> no, /dev/input/mice isn't actually connected to any hardware
[02:54] <Keybuk> it's a multiplexer for all connected mice devices the kernel provides with the mousedev module
[02:54] <Kamion> ogra: I want to investigate the problem where I saw the debian-installer/dummy template text instead of the netcfg/get_ipaddress template text first, though
[02:54] <Keybuk> rmmod mousedev && modprobe mousedev makes it appear again too
[02:54] <Keybuk> though mousedev is loaded for people on boot
[02:54] <ogra> Kamion, yup...
[02:54] <Keybuk> so that should cause the device to be created
[02:54] <pvanhoof> is there something that happens after udevstart that could be important?
[02:54] <pvanhoof> (during normal boot)
[02:55] <pvanhoof> like .. loading a specific kernel module
[02:55] <Keybuk> we thought of that, in fact for a while we thought the problem was that the kernel support for AF_UNIX sockets was in a module
[02:55] <Keybuk> and certainly loading that earlier removed some of the symptoms sometimes
[02:55] <Keybuk> but we now don't think that's the problem, and is just suppressing it slightly
[02:55] <Keybuk> also force-starting udevd before running udevstart fixes it
[02:56] <pvanhoof> well, a quickfix could be to start udevstart in the gdm script :-\
[02:56] <Keybuk> that'd be the third time it would be run in the boot process
[02:57] <pvanhoof> Keybuk, another hint .. it's a race
[02:57] <pvanhoof> becuase
[02:57] <Keybuk> oh, it's definitely a race
[02:57] <pvanhoof> sometimes my boot does work
[02:57] <pvanhoof> and other times it doesn't
[02:57] <pvanhoof> so it could be a problem with parallel starting scripts?
[02:57] <pvanhoof> (which ubuntu does, right?)
[02:57] <Keybuk> we don't parallel much, only the network stuff
[02:58] <pvanhoof> indeed, can't be the problem then
[02:59] <pvanhoof> since when did it start to happen? 
[03:00] <Keybuk> up for some debugging fun?  edit /etc/init.d/udev and change the _SECOND_ time (~line 217) udevstart is run with "UDEV_LOG=debug udevstart"
[03:00] <Keybuk> and then when you get a missing /dev/input/mice -- attach /var/log/syslog to the bug
[03:00] <pvanhoof> ok
[03:00] <Keybuk> it started about the time we did 2.6.12 / initramfs / etc.
[03:01] <Keybuk> oh, and edit /etc/udev/udev.conf and change the udev_log= line there to debug too
[03:01] <pvanhoof>     log_begin_msg "Creating initial device nodes..."
[03:01] <pvanhoof>     UDEV_LOG=debug udevstart
[03:01] <pvanhoof>     make_extra_nodes
[03:01] <pvanhoof> like that?
[03:01] <Keybuk> yup
[03:02] <Kamion> elmo: could you kick the torrent tracker for Edubuntu, please?
[03:03] <pvanhoof> does udev restart trigger the logging?
[03:03] <pvanhoof> becuase I find few interesting things in syslog
[03:03] <Keybuk> you'll need to restart the machine to get an interesting log
[03:03] <Keybuk> you can't really restart udev on a running machine
[03:03] <pvanhoof> aha ok, nex reboot then :)
[03:04] <pvanhoof> Writing down #12915
[03:04] <pvanhoof> :)
[03:04] <sivang> HiddenWolf: there is a seemelss out of the box support for Apple's 20+ inch displays, which failed with RH, mandrake etc..
[03:05] <HiddenWolf> sivang/
[03:05] <HiddenWolf> ?
[03:05] <Keybuk> pvanhoof: thanks
[03:06] <HiddenWolf> sivang, I haven't touched an apple in years. What where you referring to?
[03:06] <pvanhoof> the gnokii package can't remove it's group
[03:06] <pvanhoof> this made my last apt-get upgrade fail
[03:06] <pvanhoof> I had to manually remove the group from /etc/group and retry
[03:07] <Keybuk> what I'm hoping to see is where udevstart actually gets run in your boot process, whether it sees that the mousedev device is detected, whether it tries to add it, and whether it gets to udevd
[03:07] <Keybuk> in fact, we know already that it's _not_ getting to udevd; so knowing whether the former stuff is happening would be very useful
[03:07] <pvanhoof> ok
[03:11] <pvanhoof> Keybuk, if you guys push a new kernel package :), I might reboot faster and append my syslog earlyer :)
[03:11] <pvanhoof> *hint*
[03:11] <Keybuk> nothing to do with me :p
[03:11] <Keybuk> I doubt we'd change kernel API this close to release though
[03:15] <pvanhoof> it would be *very* useful if the default compiler could compile kernel modules
[03:15] <zul> Keybuk: just for the fun of it we might :)
[03:15] <pvanhoof> right now I have to do crazy stuff to get the vmware support modules working
[03:16] <pvanhoof> but that is probably also a problem in the vmware software .. not really an ubuntu problem perhaps
[03:17] <torkel> pvanhoof: shouldn't it be enough to set CC=gcc-3.4 when building the vmvare modules?
[03:17] <hunger_> Keybuk: I did have the missing /dev/input/mice, too. It does work for me again for a while now.
[03:18] <pvanhoof> torkel, nope (I think even for correctly setup kernel module build environments CC=something also doesn't work. It's another env var I think)
[03:18] <Keybuk> hunger_: what kind of system did you have the problem on?
[03:19] <zul> pvanhoof: at the time gcc 4.0 miscompiled the kernel so we used gcc 3.4 to build the kernel fyi
[03:19] <pvanhoof> zul, ok
[03:19] <hunger_> Keybuk: Thinkpad T43p.
[03:19] <torkel> pvanhoof: it was enough for me last time I rebuilt the modules
[03:20] <hunger_> Keybuk: I upgraded to a 2.6.13 kernel which might have helped with /dev/input/mice (/dev/input/mouse0 was created by the way).
[03:20] <bddebian> elmo: Can you also please sync vipec 3.2.0-4 from Debian unstable?  Or better yet, would it be better for me to just upload using -v<version> instead of pinging you for every little sync?
[03:20] <pvanhoof> hunger, /dev/.static/input/mice exists on my system. As a temporary fix you could use that (or symlink it to /dev/input/mice)
[03:21] <pvanhoof> hunger, else will only one of your mice work
[03:21] <pvanhoof> s/mice/mouses 
[03:21] <hunger_> pvanhoof: I just logged in as root in the console and reran udevstart:-)
[03:21] <pvanhoof> ah yes, that also works. However .. 
[03:21] <pvanhoof> the gdm failure screen makes my keyboard hang
[03:21] <hunger_> pvanhoof: That did create the missing entry.
[03:21] <hunger_> pvanhoof: Use kdm:-)
[03:22] <pvanhoof> so I have to login on another system .. stop gdm, do the trick and restart gdm
[03:22] <hunger_> pvanhoof: and X will not start here without /dev/input/mice, so neither gdm nor kdm will work and dump me to the console.
[03:23] <pvanhoof> bleh .. actually .. X should work even without a mouse
[03:23] <hunger_> pvanhoof: Nope. Not is it is a CorePointer.
[03:24] <pvanhoof> so what about blind people .. perhaps they don't use X much, but I can see a use for a mouse for blind people
[03:24] <pvanhoof> yet X might be usable (with only a keyboard and braille device)
[03:24] <hunger_> pvanhoof: I guess they define something else as corepointer.
[03:25] <hunger_> pvanhoof: They have sliders on their keyboard that simulate a mouse.
[03:36] <j^> Section "ServerFlags"
[03:36] <j^>  Option "AllowMouseOpenFail"    "true"
[03:36] <j^> in /etc/X11/xorg.conf should let you start x without a mouse
[03:42] <Keybuk> yeah, but then it won't notice when you plug it in later
[03:42] <Keybuk> #include <rant about X developers focussing on bling instead of actually fixing it>
[03:43] <hunger_> Keybuk: adding bling *IS* fixing X for most people or so it seems to me.
[03:44] <pvanhoof> patch X in ubuntu and ignore their reasoning?
[03:44] <hunger_> j^: Actually I prefer no X to X without a mouse.
[03:44] <Keybuk> unfortunately our X maintainer is one of the bling crowd
[03:45] <hunger_> Keybuk: Who? daniels?
[03:45] <Keybuk> yup
[03:46] <hunger_> Keybuk: I had not noticed that yet...
[03:48] <Mez> grr whats happened with fglrx
[03:48] <Mez> it sucks ass now
[03:48] <Mez> I cant use it
[03:48] <hunger_> Mez: When was fglrx good?
[03:48] <Mez> hunger_when it let me play games
[03:48] <Mez> Xlib:  extension "XFree86-DRI" missing on display ":0.0".
[03:49] <hunger_> Mez: lrm contains an old version, too... try upgrading.
[03:49] <hunger_> Mez: Not that that is easy with daniels having moved everything around;-|
[03:50] <Mez> lrm?
[03:50] <hunger_> linux-restricted-modules
[03:50] <Mez> erm
[03:50] <Mez> yeah
[03:50] <Mez> I'm using the latest version
[03:50] <Mez> I think
[03:50] <hunger_> Mez: Have fun figuring out where to put stuff... the ATI script did install things in all the wrong places for me.
[03:51] <Mez> ...?
[03:51] <Mez> it worked fine yesterday
[03:51] <Mez> I did an update (after being away 2 weeks)
[03:51] <Mez> and it broked
[03:51] <hunger_> Mez: It did? Cool, maybe I should install the ATI stuff again.
[03:52] <Mez> ...?
[03:52] <Mez> ATI stuff
[03:52] <hunger_> fglrx and libGL and such.
[03:52] <Mez> :(
[03:52] <hunger_> Mez: I tested it and then moved on... didn't like it, broke too many things I like.
[03:52] <Mez> yeah
[03:53] <Mez> this broke me gaming
[03:53] <Mez> I like my games
[03:53] <hunger_> Mez: fglrx crashed my system, I like my system;-)
[03:55] <j^> hunger for installations with one app starting in fullscreen mode i prefer X without a mouse attached to the pc to no X
[03:56] <eruin> j^; your last nm package has added itself twice to bootup ;-)
[03:56] <hunger_> j^: that is a special situation;-)
[03:57] <Mez> :(
[04:00] <hunger_> j^: Any idea on when your NM debs will make it into universe?
[04:02] <jammcq_office> whiprush: ping
[04:05] <j^> hunger_ thats not up to me, so i have no idea
[04:06] <hunger_> j^: Too bad... I'd love to give it a try on my private laptop once more... even though I still do not like the idea too much.
[04:06] <\sh> infinity: ping
[04:07] <j^> hunger_ you can add http://bootlab.org/~j/NetworkManager-breezy/ and try
[04:09] <ogra> hunger_, tseng uploaded them a week ago
[04:09] <hunger_> ogra: So when will they show up?
[04:10] <ogra> hunger_, aks tseng .... i dont know where his upload went ...
[04:16] <hunger_> j^: Seems like NM does not work with my wireless connection.
[04:16] <hunger_> j^: Stops the connection at install time and then claims there is no wireless network around.
[04:17] <j^> hunger_ you might wait some seconds
[04:17] <j^> does iwlist eth? scanning work?
[04:17] <hunger_> j^: But the icon shows up... which is more than what I can say about the NM in the archives.
[04:17] <hunger_> j^: The device is called ath0 and scanning works.
[04:18] <hunger_> j^: But madwifi is rumored to not work too well with NM.
[04:18] <lu|sleep> it works decently here with latest breezy kernel and j^ n-m
[04:18] <hunger_> j^: And of course I do not know the passphrase for this network... only the key.
[04:18] <lu|sleep> you have to disable the 'always search' wireless network discoverty
[04:19] <ogra> n-m never worked for me with pcmcia orinoco here
[04:19] <hunger_> lu|sleep: I did.
[04:19] <lu|sleep> since the atheros driver can't do discovery and be up at the same time
[04:19] <ogra> (scanning works though)
[04:19] <j^> ogra thats because the orinoco driver only got search support in 2.6.13, if you use orinoco.sf.net it works
[04:19] <hunger_> lu|sleep: I set it to search when disconected.
[04:19] <lu|sleep> j^: how can I find out what dns servers bind is looking at? for some reason n-m ignores my local (192.168.1.1) dhcp server, AFAICT
[04:20] <j^> lu|sleep /var/lib/NetworkManager/NetworkManager-named.conf
[04:20] <lu|sleep> hunger_: hrm, well, works fine for me with an atheros with that setting. YMMV, I guess
[04:21] <tseng> ogra: i uploaded it, it went nowhere, nafallo uploaded it, same thing
[04:21] <hunger_> lu|sleep: I guess I need to change the WEP key... I do not remember the passphrase anymore.
[04:21] <lu|sleep> j^: thanks
[04:21] <tseng> ogra: we wont get any mails because j^ is not whitelisted
[04:21] <lu|sleep> ah, I don't use WEP
[04:21] <ogra> tseng, time to poke elmo then
[04:21] <lu|sleep> that might be part of the problem
[04:21] <infinity> \sh : pong... Ish.
[04:21] <tseng> elmo: poke?
[04:21] <hunger_> j^: Can I give a key to NM instead of the passphrase?
[04:21] <tseng> hunger_: "hex key"
[04:22] <tseng> hunger_: yes
[04:22] <\sh> infinity: I have a small problem because of libgdkglext-x11...and I think you had a similar error message the last time
[04:22] <\sh> infinity: /usr/lib/gcc/i486-linux-gnu/4.0.2/../../../../lib/libgdkglext-x11-1.0.so: undefined reference to `pango_x_font_cache_load'
[04:22] <infinity> \sh : ...?
[04:22] <Mez> daniels: ping
[04:23] <infinity> \sh : Build log?
[04:23] <\sh> infinity: its in a config.log of gtkglextmm
[04:23] <\sh> infinity: i'm trying to fix this package..but it looks like that gtkglext is the problem...and libgdkglext-x11 is in gtkglext
[04:24] <infinity> \sh : Well, you're not linking the library you need, obviously.  But you may want to find out WHY that is.
[04:25] <\sh> infinity: hmmmm....
[04:25] <bddebian> infinity: Can you release kboinscpy-cvs from Dep-wait?
[04:26] <infinity> \sh : Does the package use pkg-config to put together its linker lines?
[04:26] <hunger_> tseng: I need to prefix hex key? I need to put the key in ""?
[04:26] <hunger_> tseng: Stupid me... found it.
[04:27] <infinity> bddebian : Package doesn't exist.  Can you spell it better? :)
[04:27] <hunger_> The applet looks really ugly in KDE... but it seems to work fine.
[04:27] <\sh> infinity: yes...even in the configure section...
[04:34] <\sh> infinity: i will talk to pitti next time...i think he had the same error message but i will try to fix this issue
[04:36] <\sh> libgtkmm2.0
[04:36] <\sh> is the devil i think lets see
[04:37] <infinity> \sh : If you're still confused to all hell after the weekend, ping me, but right now, I'm trying very hard not to do anything even remotely like work, unless I can do it in under 60 seconds.
[04:38] <\sh> infinity: no problem...thx anyways :)
[04:38] <Mez> infinity: no chance of mono bootstrap then
[04:38] <ivoks> :>
[04:39] <infinity> bddebian : Ahh, kboincspy-cvs, not kboinscpy-cvs.  You made me search for it and everything.  You owe me. :)
[04:39] <infinity> bddebian : Cleared.
[04:44] <bddebian> Gah, sorry
[04:44] <bddebian> infinity: Also, debtags is dep-waiting libdebtags1 and libdebtags1 shows up as building in the buidlogs but I don't see it in the archive, any clues?
[04:46] <bddebian> Might be waiting for elmo, I think it's new in the archive
[04:46] <infinity> Looks installed to me.
[04:46] <infinity> Where does it say it's building?
[04:47] <ivoks> infinity: searchandrescue is dep-wait (xlibmesa-glu-dev ??), could you please kick it? :)
[04:47] <infinity> Oh, nevermind, I looked at libdebtags, not libdebtags1.
[04:47] <infinity> Yeah, libdebtags1 is in binary NEW, because it's.  Well.  New.
[04:47] <pkern> "If your ISP does sender callback checks, it will block our mail." <-- Bah, the reason provided isn't very valid. Sender callback is not connecting to the sending machine but checking for a valid email.
[04:48] <bddebian> infinity: OK, thx
[04:51] <bmonty> anyone here know where I can get a copy of the CA certificate that ubuntu/canonical uses on their websites?
[05:06] <bddebian> elmo: I have to run for a while but another sync request.  xastir from Debian unstable 1.6.0-1.  Builds clean and fixes several FTBFS failures for us.  Thanks as always.
[09:02] <bddebian> Who's the ruby expert?
[09:39] <bddebian> elmo: You around sir?
[09:40] <elmo> bddebian: no, sorry - mail me.
[09:40] <elmo> kamion: done
[09:40] <elmo> (gone)
[09:40] <bddebian> elmo: OK, thx
[09:40] <ondrej> hi all...  looks like, that new Launchpad Integration menu items are untranslated (and are not available in Rosetta)...
[09:41] <ondrej> since menu items are likely to be same, it makes sense to make translation just once and update them together in all LI packages.
[09:43] <spacey> where are the launchpad integration menu items?
[09:46] <spacey> did the patch to not display admin stuff to non-sudo users in the gnome menu get in?
[09:48] <ondrej> spacey: Help->Get Help Online... and Help->Translate This Application...  (at least in firefox and evo)
[09:49] <jbailey> ondrej: They're translated into French on my system.
[09:49] <jbailey> Dunno about availability in Rosetta, though.
[09:50] <wasabi_> usplash for ppc coming soon?
[09:50] <jbailey> wasabi_: It's in, regenerate your initramfs with it installed.
[09:50] <wasabi_> k. doing so.
[09:50] <jbailey> That'll get taken care of for you automatically for release.
[09:51] <ondrej> jbailey: not in czech :-(, it could be related to fact, that LI items are updated from debian/patches?
[09:51] <wasabi_> Darn MOL doesn't support Tiger yet.
[09:51] <wasabi_> jbailey, those evms things up?
[09:51] <jbailey> ondrej: It seems unlikely that they'd be separate from the regular .po mechanism, but I'm only guessing.
[09:51] <jbailey> wasabi_: No, I'm doing more evms hacking today and tomorrow.
[09:51] <wasabi_> Oh.
[09:52] <wasabi_> ok.
[09:52] <jbailey> wasabi_: Are you interested in being a guinea pig? =)
[09:52] <wasabi_> Yes. Very.
[09:52] <jbailey> wasabi_: Also, can you tell me, do evms volumes always start with /dev/evms/ ?
[09:52] <wasabi_> Yes.
[09:53] <wasabi_> sometimes they are in subdirs of /dev/evms/ however.
[09:54] <jbailey> That's fine.  I will just hook it so that evms-activate is only called when the root starts with /dev/evms
[09:54] <ondrej> well, I will raise it again on some other day/time then Saturday 22:00... (ie. will ask seb128 about it :-)
[09:54] <jbailey> ondrej: Please file a bug in bugzilla.
[09:54] <jbailey> ondrej: It's easier for it to get tracked then, and the launchpad-integration stuff is important.
[09:55] <ondrej> jbailey: what package?
[09:55] <ondrej> (since it seems to be smart to update them all at once...)
[09:56] <wasabi_> cool uspaslh on ppc
[09:56] <wasabi_> high res too
[09:56] <wasabi_> well, it's smaller
[09:56] <jbailey> ondrej: Mmm.  launchpad-integration, I suspect.
[09:56] <jbailey> wasabi_: It's 640x480.
[09:56] <jbailey> Same image across all arch's.
[09:56] <wasabi_> it centered it in the screen vs stretch
[09:56] <wasabi_> so it looks ok
[09:57] <ondrej> jbailey: yeah, you're right...  I'll do it right away.
[09:58] <jbailey> wasabi_: Yeah, it's an awesome hack. =)
[09:58] <wasabi_> Where is the usplash image stored?
[09:58] <jbailey> embedded in the usplash binary.
[09:58] <wasabi_> Hmmm.
[09:58] <wasabi_> Anyway to rectify that?
[09:59] <wasabi_> So it's easily updatable.
[09:59] <jbailey> I've sent a patch to Matthew to make it loadable./
[09:59] <wasabi_> k
[09:59] <tseng> its a png in the source
[09:59] <wasabi_> It should totally support animation.
[09:59] <wasabi_> I want a dancing circle of ubuntu developers.
[09:59] <jbailey> wasabi_: err...
[09:59] <jbailey> wasabi_: Have you ever *seen* us dance?
[10:00] <Mithrandir> jbailey: it wasn't so bad in Oxford
[10:00] <tseng> has anyone heard of a /usr/bin/no?
[10:00] <tseng> and can tell me where it comes from
[10:00] <Mithrandir> tseng: dpkg -S ?
[10:00] <tseng> Mithrandir: but i dont have it.
[10:01] <jbailey> Debian's Contest-i386.gz doesn't mention it.
[10:01] <\sh> i know only /bin/no
[10:01] <tseng> its a ftbfs on a missing build-dep in my pbuilder
[10:01] <tseng> \sh: maybe that
[10:01] <wasabi_> jbailey, it's 640x480, but does it support higher, for instance on ppc?
[10:01] <tseng> < tseng> no --ecma ./en -o gtk-sharp-docs
[10:01] <tseng> < tseng> make[1] : no: Command not found
[10:01] <wasabi_> ie is it smart or hard coded?
[10:02] <jbailey> wasabi_: There doesn't appear to be an easy way of detecting the resolution.
[10:02] <jbailey> zgrep "bin/no " Contents-i386.gz
[10:02] <jbailey> gives  nothing.
[10:02] <wasabi_> jbailey, well, I sort of mean, if I drop a 1024x768 png in the loadable place, will it change res to that, or does it just have no idea at all?
[10:02] <\sh> tseng...hmmm
[10:03] <jbailey> Mithrandir: Maybe it was just the group of us at the Stonewall in Sydney. =)
[10:03] <tseng> something is broken, I think, will go upstream
[10:03] <jbailey> wasabi_: It's just offsets, so it'll start placing it wherever you ask it to.
[10:03] <\sh> graphviz: usr/bin/nop
[10:03] <jbailey> wasabi_: I could probably hack something in to look at the resolution at try to DTRT.
[10:03] <\sh> its the only thing i found which sounds like this ;)
[10:04] <wasabi_> Hmm. I'd also like to turn off the text output.
[10:04] <jbailey> wasabi_: I suspect more colour deptch is probably wanted first, though. =)
[10:04] <jbailey> Turn it off?
[10:04] <jbailey> So that you jus thave the progress bar?
[10:04] <wasabi_> Yeah.
[10:04] <Mithrandir> jbailey: I wasn't there, iirc
[10:06] <jbailey> wasabi_: I don't know how the progress bar updates.  Otherwise you could hack something in /lib/lsb/init-functions
[10:06] <jbailey> But it relies on gettnig some sort of updates on a regular basis to keep the splash from dieing.
[10:06] <wasabi_> hmm
[10:06] <wasabi_> weird.
[10:06] <wasabi_> sounds complicated. ;)
[10:07] <jbailey> Nah, its just that if usplash doesn't get an update for N seconds, it goes away to let you see what's broken. =)
[10:07] <jbailey> I think N is currently 10.
[10:11] <\sh> jdub or anyone who is planet responsible: fixed my rss feed :(
[10:16] <sladen> jbailey: perhaps make it switch away after X seconds and die after Y seconds;  giving it the option to switch back.
[10:16] <karlheg> mjg59, Can we chat a moment re usplash and initramfs support for it?
[10:17] <jbailey> sladen: What problem does that solve?
[10:17] <karlheg> mjg59, I am looking at your hook and script, and see a possible improvement.
[10:17] <sladen> jbailey: if it switches away, it'll switch back if things continue to happen again
[10:17] <jbailey> Oh, I see.
[10:17] <jbailey> Have it automatically switch back.  That makes sense.
[10:17] <jbailey> I thought you meant to have the user do that.
[10:17] <karlheg> mjg59, I'll patch it and email that.
[10:18] <jbailey> sladen: Maybe file an enh bug in bugzilla for it>
[10:18] <karlheg> Q: Is there a 'paste' site for this channel where I can show the patch to others here?  You seem to be discussing usplash atm, right?
[10:19] <jbailey> pastebin.com I think is pretty common
[10:21] <karlheg> The question is why run all the hard to keep updated 'insmod' rather than a 'modprobe', and why not use 'force_load' from the hook, and let 'load_modules' do the modprobe for you, and 'udevstart' create the fb0 device automatically?
[10:23] <karlheg> Ah; so the 'fbcon' and 'vga16fb' modules should only be loaded if 'vesafb' is not present... I see it now.
[10:24] <karlheg> Ok, so since 'modprobe' is present in the initramfs, then why not use it rather than 'insmod'?
[10:25] <karlheg> ... letting 'modprobe' handle the depends?  The 'depmod' is already run by the time that the init-premount scripts are run.
[10:25] <sladen> jbailey: depends whether it is a bug
[10:26] <jbailey> sladen: Severity: enhancement
[10:26] <jbailey> karlheg: modprobe is in there, it's built into busybox
[10:27] <karlheg> jbailey, No, you are using the "real" one, not the busybox one.
[10:27] <karlheg> bb 'insmod' perhaps?
[10:30] <jbailey> Ah, maybe.
[10:30] <sedak> about the usplash thing ...
[10:31] <jbailey> I do know that it's in there somehow, though.
[10:31] <sedak> i've compile my own kernel
[10:31] <sedak> and i had to add insmod ... fb.ko to make it work
[10:32] <sedak> maybe it would be a good idea to add to load ?
[10:32] <jbailey> sedak: possibly, or at least document it.
[10:32] <jbailey> sedak: I usually try to discourage people from compling their own kernels when possible.
[10:32] <sedak> ok
[10:33] <sedak> it is just something i do since i'm young ...
[10:33] <jbailey> =)
[10:33] <sladen> jbailey: is busybox now in initramfs' by default or just if requested?
[10:33] <sedak> i've been addicted
[10:33] <karlheg> I've fixed it, if mjg59 accepts the patch, by using 'modprobe' rather than hand-maintained 'insmod' lines in the script that loads them.
[10:33] <jbailey> sladen: Always.
[10:33] <jbailey> karlheg: Does it work?
[10:33] <jbailey> karlheg: ISTR there was some problems with it before.
[10:34] <karlheg> I will test it soonish.
[10:34] <sedak> well, anyway, if you use modprobe, there is no need to add a insmod fb.ko
[10:45] <karlheg> http://pastebin.com/360043
[10:45] <karlheg> Who should I email it to?  Or should I post it to bugzilla?  I suppose the latter.
[11:01] <Kamion> elmo: thanks
[11:01] <Kamion> tseng: stuff looking for 'no' is almost always a configure script that went "checking for foobar: no" (i.e. couldn't find foobar) and then mistakenly stuck 'no' into a Makefile where it would get run as a command
[11:01] <Kamion> tseng: so therefore typically a missing build-dep
[11:01] <jbailey> karlheg: Does it work?
[11:01] <tseng> Kamion: yep, we've figured it out :)
[11:02] <tseng> Kamion: thanks.
[11:02] <tseng> Kamion: more of a broken build-dep, bad symlinks
[11:02] <Kamion> karlheg: have module dependencies been guaranteeably updated by that point?
[11:02] <Kamion> remember that happens during boot after usplash starts ...
[11:03] <jbailey> Hmm, actually that's a good point.
[11:03] <jbailey> Kamion: They are now, but they won't be when usplash moves to run earlier.
[11:03] <Kamion> right ...
[11:03] <Kamion> anyway, I'm meant to be going to a party; later
[11:03] <jbailey> I think paprt of what mdz wanted was for usplash to be running while depmod -a did its stuff.
[11:03] <jbailey> Kamion: enjoy. =)
[11:20] <glm> Hi out there, I'm looking for a screen(1) user which will download http://pubwww.fhzh.ch/~mgloor/data/screenie-1.26.0.tar.gz from http://pubwww.fhzh.ch/~mgloor/screenie.html to report if it's working with Ubuntu or not. Thanks.
[11:21] <sladen> jbailey: is depmod not cached?
[11:24] <karlheg> Kamion, Yes, by 'load_modules'.
[11:25] <karlheg> jbailey, What if the depmod -a was run sooner?
[11:26] <karlheg> ... hmmm.  What about a static modules.dep with information for ONLY the fbcon and vga16fb in it... generated by the usplash hook?
[11:26] <karlheg> Let me explore that.
[11:26] <karlheg> (brb)
[11:27] <karlheg> Q: are the modules.dep lines each complete in themselves, or is a transitive closure required?
[11:29] <jbailey> sladen: No, it's run at boottime to allow late assembly of the modules.
[11:29] <jbailey> karlheg: depmod -a is slow, that's the whole point of running usplash before it.
[11:29] <jbailey> That way the user has something to look at.
[11:29] <jbailey> I dont know the formal structure of the modules.dep file.
[11:30] <karlheg> jbailey, Right, but if the 'usplash' hook created a "modules.dep" that contained only enough information for 'modprobe' to work for it's required modules, maybe that will suffice?
[11:30] <jbailey> If it knows all that inforamtion, tough, why not just use insmod?
[11:31] <karlheg> The thing is that a series of hand-written 'insmod' statements is fragile in the face of kernel rebuilds with different module vs static driver sets compared with the stock kernel, and in the face of kernel changes that affect the module deps.
[11:31] <karlheg> I think I can hack it.  Patch pending.
[11:31] <jbailey> Right.  Probably the right thing to do is to generate the insmods at build time and load those into the initramfs.
[11:32] <karlheg> man modules.dep
[11:32] <karlheg> ... says that the dependencies listed are "complete", and gives an example.
[11:33] <sladen> jbailey: that would be better;  you could notice what platform you're on too
[11:33] <karlheg> Thus, the 'usplash' mkinitramfs hook need only 'grep' out the relevant lines from the system "modules.dep" file.
[11:33] <hunger_> Why is depmod -a run all the time? Does it change between reboots?
[11:34] <karlheg> It can then install, or better, catenate to if exists, a temporary static "modules.dep" file...
[11:34] <karlheg> Hmmm.  Perhaps that depmod ought be run at mkinitramfs time then.  Simple.
[11:34] <karlheg> Ah.  catenate_cpiogz.
[11:34] <karlheg> It MUST be run at run-time.
[11:35] <karlheg> But a temporary static one for 'usplash' should do the trick for early start up; the later depmod can overwrite it.
[11:35] <karlheg> I'll do that.
[11:35] <sladen> karlheg: I don't really see the benifit of modprobe for two modules in the first 2 seconds of boot
[11:36] <jbailey> hunger_: it might.  There's no promises.
[11:36] <jbailey> hunger_: the initramfs doesn't know where it came from.  One of its features is that it could be assembled by the bootloaders.
[11:36] <karlheg> sladen, Think of the case where a custom kernel is installed with different set of modular vs built-in drivers as compared with the stock kernel.
[11:36] <jbailey> karlheg: Keep in mind.  You don't *know* for certain that usplash is the only one that needs it.  Try to think of solutions that can cohabitate with other things.
[11:37] <hunger_> jbailey: Which bootloader can do something that complex?
[11:37] <karlheg> ... or if a Linux kernel upgrade brings in a kernel with different set of modules required for the fbcon and vga16fb.
[11:37] <jbailey> karlheg: Like if something else also wants modprobe, it could overwrite your modules.dep before you get there.
[11:37] <sladen> karlheg: then they obvious know what they're doing ("...")
[11:37] <jbailey> hunger_: It's about a 10 line hack to grub.  I think grub2 has it already.
[11:37] <jbailey> hunger_: One of hpa's bootloaders also apparently has it.
[11:38] <hunger_> jbailey: Oh, great...
[11:38] <karlheg> The 'manual_load_modules' function does the right thing, by using 'modprobe' to get the list.  The script in the initramfs should also use 'modprobe' for the same reason, and can if a temporary static "modules.dep" is used.  I am very sure it will work, and will create the patches.
[11:38] <karlheg> I wonder if 'modprobe' can be given a specific "modules.dep" file?
[11:41] <karlheg> Ah, it's simple.  I see.  The series of 'insmod' commands can be dumped to a file with "modprobe --show-depends".
[11:41] <karlheg> That can be sourced by the 'usplash' initramfs script.
[11:41] <karlheg> Then, it's just like a 'modprobe', but requires no "modules.dep".
[11:42] <karlheg> Very simple.
[11:42] <karlheg> The 'usplash' mkinitramfs hook can do all of that easily.
[11:42] <hunger_> karlheg: Will that work with bootloaders that meddle with the initrd?
[11:42] <jbailey> karlheg: Right, that's why I meant earlier by generate them.
[11:43] <karlheg> jbailey, Ah.
[11:43] <hunger_> jbailey: Does that work with grubX meddling with the initramfs?
[11:43] <karlheg> hunger_, Probably; if it can run anything at all in there, then it can run this.
[11:44] <jbailey> hunger_: Yup, because the dependancies are caused by the modules.  You're just running insmod at that point.
[11:44] <jbailey> hunger_: Unless you actually change out modules from underneath something, there should be no conflict.
[11:44] <hunger_> karlheg: You run the modprobe --show-depends on ramfs buildtime, don't you?
[11:44] <jbailey> hunger_: Yes.  Where do you see the problem?
[11:44] <hunger_> jbailey: Under that assumption, why do you need to regenerate modules.dep?
[11:47] <karlheg> hunger_, Each package that needs to can drop it's own script into the mkinitramfs hooks chain.  Each can thus add its own set of modules.  Given only that, a prebuilt "modules.dep" is possible.
[11:47] <hunger_> jbailey: Why don't you copy the system's modules.dep when creating the initramfs and then stick with that? It should work for as long as nobody meddles with the modules;-)
[11:48] <karlheg> The problem is that the initramfs can consist of catenated gzipped cpio archives, and mkinitramfs supports that.  That is also what the bootloader likely does.
[11:48] <karlheg> So one overlays the next, and a "modules.dep" must be generated late.
[11:48] <hunger_> karlheg: So why is it save to modprobe --show-depends then?
[11:49] <karlheg> Hmmm.... so as long as no modules not in the system already are added to the initramfs, that should work.
[11:49] <karlheg> Because it's done at mkinitramfs time and we assume that the modules are from the system only...
[11:50] <karlheg> This seems to imply that the copy of "modules.dep" should suffice, doesn't it?
[11:50] <hunger_> karlheg: I do not see why one should work while the other doesn't. AFAICT both have the same assumptions.
[11:51] <karlheg> Iff the modules themselves are not overlayed with ones that have different deps, and no out-of-system-set modules are added by anything that require deps be present, it should work fine.
[11:51] <hunger_> karlheg: But then it is late here and I should have gone to bed hours ago;-)
[11:51] <karlheg> We need to document that.
[11:51] <karlheg> ... assumption.
[11:52] <jbailey> karlheg: Right, we assume there's only one instance of any given module in the world and don't allow for namespace collisions.
[11:52] <jbailey> karlheg: If people are overwriting system kernel modules, they'd better know what they're doing.
[11:52] <jbailey> Out of system modules need to be able to be added, though.  It might be important for non-Free modules that can't ship with the kernel.
[11:53] <thesaltydog> is ipw2100 driver not yet in breezy?
[11:53] <karlheg> jbailey, Leaving only the case where something adds an out-of-system-set module to a cpiogz overlay.
[11:53] <jbailey> karlheg: 
[11:53] <jbailey> right
[11:53] <jbailey> So depmod -a still needs to be run.  But the --show-depends trick is enough for usplash.
[11:53] <jbailey> And almost nothing else should ever have to worry about being run that early.
[11:55] <sladen> presumbly you have to point 'modprobe' at the specific module-set/kernel-version in question before generating the depends
[11:56] <karlheg> sladen, No need to now.  'modprobe --set-version=${VERSION} --show-depends' prints a series of 'insmod' statements.
[11:57] <sladen> grooviness
[11:57] <karlheg> A short shell snippet is thus generated that can be sourced from the (eg) 'usplash' mkinitramfs script.
[11:57] <thesaltydog> anybody knows when the ipw2100 driver will be in Breezy? I lost it during upgrade from Hoary so no more wireless...
[11:58] <karlheg> I will make those changes, and update the patch I submitted earlier.
[11:58] <karlheg> thesaltydog, I wonder if you need the 'linux-restricted-modules' package for that?
[11:59] <karlheg> thesaltydog, I need to have that installed to get my madwifi (atheros) working.
[11:59] <thesaltydog> I have linux-restricted-modules installed..
[11:59] <thesaltydog> it doesn't work with 2.6.12, but it still works with 2.6.10-5..
[12:01] <karlheg> jbailey, I will document this all in the 'mkinitramfs.8'.