[12:02] <ogra> mdke: you have probs with the new kernel/udev ? 
[12:02] <mdke> ogra, yeah, i can't boot
[12:02] <ogra> oh ? 
[12:02] <mdke> my hard disk disappears ;)
[12:03] <ogra> mdke: Keybuk is your man ...
[12:03] <mdke> yeah I know
[12:03] <mpt> mdke, I didn't see that, thanks for the pointer
[12:03] <ogra> i have a reciepe anywhere
[12:03] <mdke> we exchanged bugmail, but I wanted to see if I can get anyone in here to help out
[12:05] <ogra> mdke: see /query
[12:05] <mdke> yeah
[12:05] <mdke> ogra, thanks, but I can boot the old kernel ;)
[12:05] <mdke> ogra, just wanted to see if I can help someone fix the new one by debugging
[12:05] <ogra> ah, k
[12:06] <mpt> mdke, url? (searching for "wiki license" on the wiki shows nothing relevant)
[12:06] <mdke> mpt, WikiLicensing
[12:06] <mpt> thanks
[12:06] <mdke> mpt, i answered your specific points on the docteam mailing list in the Packaging guide thread... but i bet you have quite a bit of mail to get through ;)
[12:12] <jdub> ogra: lordy, gnome-screensaver is ugly atm - when are we going to do the seed switch to bring that in by default?
[12:14] <ogra> jdub: its in the main inclusion queue since 2 days on mdz request... i hope pitti finds the time for it before flight 2
[12:14] <mdke> yeah, what happened to the pretty breezy screensaver?
[12:15] <ogra> jdub: its an awful lot of work to make the hacks work with gnome-screensaver 
[12:15] <ogra> jdub: i dont understand their decision for .desktop files for each hack at all :/
[12:20] <torkel> ogra: there is a script in g-s that creates the .desktop files from the hacks (but you probaly already knew that :-)
[12:20] <ogra> torkel: err, nope 
[12:20] <mhz_cook> smurf: ping
[12:21] <ogra> torkel: but i question the whole concept, it silly 
[12:21] <ogra> *its
[12:21] <mhz_cook> jdub: any chances to get that ML?
[12:21] <torkel> ogra: I more or less agree with you
[12:22] <jdub> i've just returned from trveling, not yet sure whether i have access to the main server
[12:22] <jdub> so, not just yet
[12:22] <mhz_cook> okis
[12:22] <ogra> torkel: migrate-xscreensaver-config.sh doesnt help much for the packaging, but i'll try to use it for the .desktop generation in xscreensaver 
[12:23] <ogra> thanks for teh hint :)
[12:23] <lamont> mdz: new util-linux and postfix uploaded to debian, which should be able to just sync in to ubuntu and conform
[12:24] <mdz> lamont: cool, ask elmo for the sync
[12:27] <lamont> mdz: they have to make it into the archive first...
[12:27] <lamont> that's tomorrow's dinstall run
[12:28] <mdz> lamont: iirc elmo can sync from incoming now
[12:28] <lamont> ah, neato
[12:34] <Kamion> bigozs: right now, parts of the installer need to be in shell or C (generally shell if possible) for maximum portability
[12:35] <Kamion> things that will be specific to the live installer can be python
[12:40] <Kamion> it has a function called enough_mem which appears to return true iff biosmem < 4MB || biosmem >= 200MB || !syslinux
[12:41] <Kamion> I confess to being somewhat baffled by the first part of that, unless the RPN language is confusing me
[12:41] <daniels> dude, you have TOO MUCH MEMORY
[12:41] <daniels> lose 60MB of that 64
[12:42] <bigozs> Kamion: is there any specific way shell scripts are integrated into the installer?
[12:42] <Kamion>     key keyF7 eq or {
[12:42] <Kamion>       % call super penguin
[12:42] <Kamion>       p.call.super
[12:42] <Kamion>     }
[12:42] <seb128> daniels: 2.6.12 doesn't do a difference for this desktop switching slowness
[12:42] <Kamion> uh-huh
[12:42] <Kamion> bigozs: that question either has a very short answer or a very long one
[12:43] <Kamion> bigozs: mostly they use debconf for interaction and database access
[12:43] <daniels> seb128: scheiss
[12:43] <Kamion> bigozs: but really you probably just want to have a look at a bunch of them :-)
[12:43] <daniels> seb128: could you please ht me up with an xorg.0.log?
[12:44] <bigozs> I may be asking stupid questions but I'm completely unfamiliar with the installer architecture :)
[12:44] <seb128> daniels: my chinstrap dir has it
[12:44] <Kamion> bigozs: easiest way to get the whole lot at once is to check out the upstream repository, svn://svn.debian.org/svn/d-i/trunk/ (beware there's rather a lot of it)
[12:44] <daniels> seb128: cheers
[12:44] <Kamion> look in installer/doc/devel/ for various bits of documentation, intro and otherwise
[12:44] <bigozs> ok, will look
[12:44] <Kamion> most of the actual code is in packages/
[12:48] <Kamion> bigozs: a useful thing to look at might be os-prober, which pokes around in other filesystems on the disk to figure out in generic terms how to boot them; that at least is kind of in the same ballpark as what you're looking at
[12:49] <bigozs> ok
[01:04] <nekohayo> hey just a randomish question, do you know if any of those gnome performance hacks have already been uploaded to dapper or not yet?
[01:05] <bigozs> os-prober looks interesting, i have to look at it when i have more than 3 hours sleep :)
[01:06] <bigozs> my life is governed now by my daughters sleep cycle
[01:06] <daniels> ah, it's the destroyer of worlds
[01:06] <daniels> good morning
[01:08] <Kamion> mdz: oh, wow, not only does gfxboot support changing the keymap (in syslinux, even), but it can do keymap defaulting by locale or whatever other arbitrary criteria we dream up
[01:10] <Kamion> writing a theme may well be an utter bastard, though; I'll probably start with a hacked SuSE one and go from there
[01:10] <Kamion> since "theme" => "7000+ lines of something that looks a bit like PostScript"
[01:10] <ogra> heh
[01:11] <ogra> the suse way of life
[01:11] <Keybuk> we could get sladen in to not do it
[01:11] <daniels> zing!
[01:11] <Kamion> gfxboot provides you the facility to draw on the screen, handle input, and all the rest of it from the bootloader, but no widgets or policy or whatever
[01:11] <Kamion> it's like udev for shiny
[01:11] <jdub> Kamion: policy is for fascists!
[01:11] <daniels> MECHANISM NOT POLICY
[01:12] <mdke> ooh Keybuk 
[01:12] <Keybuk> uh-oh
[01:12] <Keybuk> I dislike "ooh Keybuk" this week
[01:12] <Keybuk> what critically important part of YOUR system doesn't work? :p
[01:12] <ogra> lol
[01:12] <mdke> Keybuk, your call, if you fancy some udev debugging
[01:12] <mdke> it's the hard drive
[01:12] <jdub> my system is pretty funky atm
[01:12] <jdub> trackpad doesn't work
[01:13] <Keybuk> SATA?
[01:13] <jdub> usb mouse dies after a while
[01:13] <Keybuk> jdub: yeah, that's a kernel bug afaict
[01:13] <jdub> usual fglrx fuckage
[01:13] <mdke> Keybuk, yes, #20557
[01:13] <Keybuk> so blame BenC for those ... though there have been "mouse is broken" bugs since all through 2.6.15 so far
[01:13] <daniels> you're using fglrx??
[01:13] <jdub> (this time it oopses the kernel, and doesn't shutdown/reboot)
[01:13] <jdub> daniels: have to on this
[01:13] <Keybuk> mdke: ah, good
[01:13] <jdub> daniels: ati driver just makes a very bright mess on the screen
[01:13] <Keybuk> mdke: you'll want the upload I'm going to do in a short while then
[01:13] <daniels> oooh, shiny blooming
[01:13] <mdke> Keybuk, ah good news
[01:13] <daniels> which chipset?
[01:14] <jdub> not blooming though
[01:14] <Keybuk> mdke: echo ide-generic >> /etc/modprobe.d/blacklist ; update-initramfs -u ; reboot ; profit
[01:14] <Keybuk> (temporary fix)
[01:14] <daniels> jdub: oh?
[01:14] <mdke> Keybuk, that's ok, I have a breezy partition :)
[01:14] <daniels> zsh: profit: command not found
[01:14] <jdub> really messy flickering, looks like very bright high resolution cga colours :)
[01:14] <mdke> Keybuk, will try tomorrow and close/comment on bug
[01:14] <daniels> jdub: ah, sweet
[01:14] <jdub> xorg thinks it's a radeon xpress 200M RC410
[01:14] <daniels> ah, right
[01:14] <daniels> and it fails with dapper?
[01:15] <daniels> i expect MAXIMUM FUCKTASMIC with breezy for that chipset
[01:15] <daniels> but it should be orright with dapper
[01:15] <jdub> i'm running dapper
[01:15] <mdke> Keybuk, thanks :)
[01:15] <jdub> fglrx -> fine apart from oops, no vga, etc
[01:15] <daniels> wack
[01:15] <Keybuk> mdke: if you want the boring details, libata takes ownership of devices asynchronously -- so sometimes the "modprobe ide-generic" happens before its done so, and ide-generic steals all the devices
[01:15] <jdub> ati -> messy interesting flicker
[01:15] <jdub> actually, i'll try again with -7 fglrx
[01:15] <jdub> er
[01:15] <jdub> ati
[01:15] <Keybuk> the fix is obvious, we're not going to modprobe ide-generic if ROOT==/dev/sd* :p
[01:16] <mdke> ok
[01:16] <mdke> you guys know what you're doing :)
[01:16] <mdz> Kamion: wow, nice
[01:16] <daniels> jdub: i think cvs might have the hot fix action
[01:16] <mdke> i have no clue what you said
[01:16] <daniels> well
[01:16] <daniels> cvs + anholt's patches
[01:16] <jdub> ok
[01:16] <Keybuk> do you know what the funny thing is?  breezy is broken here too ... except busybox's shell is so slow, the extra echo in between the two modprobes is enough to make it work <g>
[01:16] <mdke> Keybuk, so I don't need ide-generic?
[01:17] <Keybuk> mdke: no, not for your root filesystem anyway
[01:17] <jdub> daniels: so that'll be basic FOSS ati support, no 3d and so on?
[01:17] <mdke> Keybuk, if I need it for something else, it'll be there?
[01:17] <Keybuk> yup, it'll be loaded once the real root filesystem is running as soon as anything that smells like IDE is found
[01:17] <mdke> Keybuk, ah great
[01:18] <Keybuk> you only need it for pcmcia ide devices though
[01:18] <Keybuk> and even that might not be true now
[01:18] <Keybuk> (I'm going to still err on the side of loading it though, just in case)
[01:18] <mdke> sounds fine
[01:18] <mdke> Keybuk, thanks
[01:19] <Keybuk> mdz: btw, how is your laptop today?
[01:19] <mdz> Keybuk: out of reach
[01:19] <daniels> jdub: well, there's 3d support, but it may well fail to draw anything and hang your machine
[01:19] <mdz> I left it in the car, and can't get there until later
[01:19] <mdz> (floor varnish is drying)
[01:20] <jdub> heh
[01:22] <Keybuk> fair enough
[01:23] <Keybuk> mdke: randomly, is your laptop-that-doesn't-boot reachable at the moment
[01:23] <mdke> Keybuk, on my lap
[01:24] <Keybuk> right
[01:24] <Keybuk> so I guess you can't reboot that to check something for me? :p
[01:24] <mdke> Keybuk, sure
[01:24] <Keybuk> reboot into dapper, and it should fail with /dev/sda* not found -- and drop you to a shell
[01:24] <mdke> yeah
[01:24] <Keybuk> then cat /proc/modules and note down the list
[01:25] <Keybuk> just want that
[01:25] <mdke> ok i'll try
[01:27] <mdke> Keybuk, bad news
[01:27] <mdke> it booted
[01:27] <mdke> is this a "sometimes it does, sometimes it doesn't" job?
[01:27] <Keybuk> yup
[01:27] <Keybuk> that's good
[01:27] <mdke> want me to try again?
[01:27] <Keybuk> reboot a couple more times until it doesn't
[01:27] <mdke> k
[01:27] <mdke> brb
[01:27] <Keybuk> sometimes (entirely serious) waving it around a bit to cool off helps
[01:28] <seb128> daniels: grumpf, slowness happens with fglrx too
[01:29] <seb128> I've downgraded gtk, no change neither
[01:29] <seb128> and cairo version didn't change
[01:30] <daniels> seb128: so if you downgrade to xserver-xorg-core 6.8.2-77, and downgrade drivers as appropriate, does it get quicker then?
[01:31] <daniels> i'll be shitted off if it's slower in the core
[01:32] <seb128> daniels: would grabbing 5.10 debs would work?
[01:32] <seb128> s/would work/work/
[01:34] <mdke> Keybuk, lol. Ok I have them: you don't want the numbers too right?
[01:34] <Keybuk> right, just the names for one that failed
[01:34] <mdke> i just wrote them all down...
[01:34] <mdke> some failed?
[01:35] <Keybuk> no, I mean all of the names you wrote down ... from the failed boot :p
[01:35] <mdke> ah cool
[01:35] <BenC> daniels: can you verify 6841 on breezy (strip on xfs)?
[01:35] <mdke> Keybuk, /query
[01:35] <Keybuk> sure
[01:35] <daniels> BenC: yep
[01:35] <daniels> seb128: yep
[01:35] <seb128> daniels: all drivers need to be downgraded?
[01:35] <seb128> daniels: or just the ati one?
[01:35] <BenC> daniels: is that "yep" it is still a bug, or "yep" you can test it? :)
[01:35] <daniels> seb128: -core, -input-kbd, -input-mouse, -driver-ati
[01:35] <daniels> BenC: yep it's still a bug
[01:35] <BenC> daniels: no change with 2.6.15 either?
[01:36] <daniels> BenC: dude, I'm not trying .15 :P
[01:36] <BenC> daniels: come on, I'm running it on 6 machines here :P
[01:36] <daniels> seriously, I'm going to try to get all my machines up to .15 and the new shiny broken stuff next week
[01:36] <daniels> so I'll let you know then
[01:36] <daniels> but it only happens when building the monolith, so I haven't tried that environment for a while now
[01:36] <Keybuk> 15+new-world-order, when it works, is a lot better
[01:36] <BenC> ok, thanks
[01:37] <Keybuk> and if it doesn't work, it's better I know now, so it will
[01:37] <daniels> Keybuk: is this a lot like the new X world order, which was stupendously great for me, who was generally hanging five or so revisions back, and had a hand-hacked transition anyway? :P
[01:37] <jdub> ogra: xscreensaver-dataq and xscreensaver conflict on /usr/share/xdscreensaver/config/README
[01:37] <ogra> jdub: not anymore 
[01:38] <ogra> jdub: 4.23-2ubuntu3 is what you want
[01:38] <Keybuk> daniels: nah, this actually feels really good -- we have a huge flexibility to debug and arrange things
[01:38] <Keybuk> it's just doing some fine-tuning now
[01:38] <Keybuk> of course, fine-tuning the mounting of the root filesystem
[01:38] <Keybuk> which appears major :p
[01:38] <Keybuk> I go with what infinity said this morning
[01:39] <jdub> ogra: i had it during upgrade to that
[01:39] <Keybuk> I'm glad we're not releasing dapper this month, but I'm glad we're going to release dapper with this stuff
[01:39] <ogra> jdub: exact error ? 
[01:39] <daniels> Keybuk: this was exactly the case with breezy
[01:39] <ogra> jdub: since thats what the ubuntu3 upload was for ...
[01:39] <jdub> ogra: can't paste - -data tried to replace config/README owned by xscreensaver
[01:40] <jdub> from ubuntu1 -> ubuntu3
[01:40] <ogra> hrm
[01:40] <BenC> I should do atleast one xfs install so I can test these things
[01:40] <jdub> worked on the second run through though
[01:41] <daniels> seb128: if you say that it's all fixed now, I'm going to be really upset
[01:41] <ogra> jdub: either yours or Riddells system was f*cked then ..
[01:41] <daniels> i like blaming things on the kernel
[01:41] <seb128> daniels: downgrading those 4 packages fixes the left handed mouse and the slowness of desktop switching
[01:41] <daniels> d'oh
[01:42] <seb128> daniels: sorry
[01:42] <daniels> the mouse was expected
[01:42] <daniels> the slowness sucks
[01:42] <seb128> that feels so good
[01:42] <seb128> the 2s to switch desktops is ugly to use when you switch desktop often
[01:42] <seb128> and I do switch often
[01:42] <daniels> two seconds?
[01:43] <seb128> that's my estimation on how low it takes it to redraw the background
[01:43] <seb128> maybe 1s
[01:43] <daniels> jesus christ
[01:43] <ogra> seb128: where do i set the scrollback buffer in xchat-gnome ? 100 lines is really not usable
[01:43] <daniels> can you please put up the log from -77 on chinstrap or so?
[01:43] <daniels> i'd like to diff the two
[01:44] <seb128> daniels: Xorg.0.log.speed at the same place
[01:44] <daniels> heh
[01:45] <jdub> seb128: redrawing the background?!
[01:46] <seb128> jdub: with new xorg, it takes 1-2s to redisplay nautilus' icons and stuff on the desktops when switching between them
[01:46] <seb128> s/desktops/workspaces/ rather
[01:46] <jdub> hrm, not happening here
[01:46] <seb128> lucky you :)
[01:46] <jdub> ;-)
[01:46] <seb128> happens to dholbach on one box too
[01:46] <jdub> everything else sucks, mind! :)
[01:47] <jdub> (stupid quebecistani laptop!)
[01:47] <seb128> I still have an outdated udev because Keybuk broke my mouse :p
[01:47] <Keybuk> I did nothing of the sort
[01:47] <jdub> does your mouse work for a while and then stop?
[01:47] <Keybuk> BenC broke your mouse :p
[01:47] <daniels> seb128: if you comment out Load "dri" in xorg.conf, is it any happier then?
[01:47] <seb128> jdub: not, xorg refuse to start because it claims there is no mouse
[01:47] <seb128> daniels: k
[01:47] <daniels> seb128: (in dapper)
[01:47] <seb128> daniels: I upgrade again, comment and try, that's it?
[01:48] <daniels> yeah
[01:48] <BenC> if your mouse breaks in X, don't blame me until you can reproduce it with gpm :P
[01:48] <daniels> also, what sort of card did dholbach have?
[01:48] <daniels> BenC: DUDE GPM IS THE DEVIL
[01:48] <daniels> BenC: also, if /dev/input/mice doesn't exist, it's *so* not X's fault
[01:48] <daniels> i blame udev
[01:48] <BenC> yeah, me too :)
[01:48] <jdub> daniels: apart from the kernel working around X being a doofus :-)
[01:48] <jdub> daniels: so strictly speaking, it's *all* X's fault :-)
[01:48] <daniels> jdub: the what now?
[01:49] <jdub> /d/i/m is a hack to work around X not having reasonable hardware autoconfiguration
[01:49] <jdub> so we can always boil down to blaming X
[01:49] <jdub> which must be a relief for the kernel hackers
[01:49] <jdub> though they have a lot to be blamed for too ;)
[01:52] <seb128> daniels: nop, still slow without dri
[01:53] <daniels> seb128: whoohoo
[01:53] <daniels> seb128: if you're feeling really brave, you could start it in gdb from another machine, and ^C it from there while it's redrawing the background
[01:53] <daniels> based on previous stuff, I suspect fbComposeGeneral()
[01:54] <daniels> which will !!HURT!! for background-sized stuff
[01:54] <daniels> jdub: yeah, X is pretty nice, shame the server's so shit
[01:54] <seb128> daniels: I'm trying to build sysprof with current linux atm, would it do the trick?
[01:56] <daniels> what's sysprof?
[01:56] <ogra> ah, thats better :)
[01:57] <seb128> daniels: profiling tools, you don't read federico's blog? :)
[01:57] <daniels> i'm still digesting nat's last entry
[01:57] <daniels> i expect to be done next week
[01:58] <seb128> it was before UBZ
[01:58] <seb128> how much do you have to catch up? :)
[01:58] <seb128> daniels: you have not read the blogs about pango, fileselector, etc?
[01:58] <daniels> ah, I see
[01:59] <daniels> that thing
[01:59] <OgMaciel> elmo, excuse me... do u have a minute?
[01:59] <daniels> well, it won't help *that* much, as you'll likely get stuff with much higher cumulative totals
[01:59] <daniels> a lot of time in WaitforSomething, f.e. :P
[01:59] <daniels> interrupting it with gdb will tell you which code path it's hit at that particular point
[02:00] <daniels> the radeon exa support is much better here, because you can just turn on fallback debugging and have it tell you exactly when and why you're falling back
[02:00] <seb128> daniels: according to sysprof 81.32% is spent to XAAComposite
[02:01] <daniels> does it say which child functions it's calling?
[02:01] <seb128> I like this tool :)
[02:01] <daniels> into fbComposite*, or RADEONCPComposite*?
[02:02] <seb128> daniels: http://people.ubuntu.com/~seb128/ati.png
[02:02] <seb128> daniels: useful for you?
[02:03] <daniels> very useful, thanks :)
[02:03] <seb128> grr, switching between windows on the same workspace is slooow too
[02:03] <daniels> so yeah, falling back to fbComposite -> YOU LOSE
[02:03] <daniels> don't see *why* it's needing to do that though
[02:03] <daniels> nautilus shouldn't be doing stupid tricks with argb
[02:03] <seb128> how do I workaround that? :)
[02:03] <daniels> heh
[02:04] <seb128> do you think it's nautilus?
[02:04] <seb128> or cairo?
[02:04] <daniels> i386 or amd64?
[02:04] <daniels> i think cairo, tbh
[02:04] <seb128> amd64 box but with an i386 install
[02:04] <daniels> (fb* is the pure-software rasteriser)
[02:06] <daniels> i'll see if I can get you a debugging i386 build
[02:08] <seb128> daniels: I can do a xorg rebuild on my box if you want
[02:08] <daniels> it shouldn't take that long to do an MMX copy though
[02:09] <seb128> just send me a patch if there is something you want try
[02:09] <daniels> seb128: if you want to do that and just stick ErrorF("src_x %d, src_y %d, dst_x %d, dst_y %d, w %d, h %d\n", src_x, src_y, dst_x, dst_y, w, h); at the top of fbCopyAreammx in fb/fbmmx.c, that would be useful
[02:09] <daniels> but yeah, I just don't see how it could be that slow to do a memcpy
[02:10] <jdub> daniels: it's probably doing it 200 times just for good measure :)
[02:10] <ogra> jdub, do you care for gamin nowadays ? is there an update in the queue ? 
[02:10] <seb128> why should he care for gamin?
[02:10] <OgMaciel> ogra, hi... can you spare a minute?
[02:11] <jdub> ogra: seb128 does - unfortunately DV still just puts it on his website
[02:11] <ogra> seb128, because he did once :)
[02:11] <jdub> seb128: launchpad seems to think so ;)
[02:11] <ogra> OgMaciel, if its only a minute, yes ... i'm busy preparing a report for the meeting
[02:12] <seb128> daniels: what source package has fb/fbmmx.c?
[02:12] <OgMaciel> ogra, can I pvt then? it will take a minute
[02:12] <ogra> sure
[02:12] <daniels> seb128: xorg-server
[02:12] <seb128> k
[02:12] <daniels> seb128: and just drop obj-i386-gnu-linux/hw/xfree86/Xorg into /usr/bin when you're done
[02:12] <daniels> so you get debugging
[02:13] <seb128> k
[02:13] <ogra> seb128, i'm still hoping for my app menu to magically reappear with a gamin update ;)
[02:13] <daniels> jdub: planet.g.o is down now.  i demand to know what you plan to do about this.
[02:14] <seb128> daniels: gnome.org is down
[02:14] <jdub> daniels: the server was hammered, all the sites are down
[02:14] <azeem> daniels: man, you're out of luck.  One posting in month and nobody can see it!
[02:14] <daniels> hammered?
[02:14] <azeem> s/month/months/
[02:14] <daniels> azeem: eh, I'm not on p.g.o
[02:14] <azeem> daniels: d'oh
[02:14] <daniels> just p.fd.o, p.d.o, planet.slug.org.au and planet.linux.org.au
[02:15] <azeem> daniels: alexl's posting is linked to by lwn.net, and you can easily read Nat's post till the server is responsive again
[02:15] <seb128> daniels: speaking about fd.o, Amaranth was saying that pyxdg has no new version because the maintainer his waiting to get is key back to use the CVS again or something, is that you who does that? :)
[02:16] <daniels> seb128: i saw that ... who's the maintainer who needs a key?
[02:16] <seb128> (not that I really care, but we could use a fixed pyxdg :p)
[02:16] <daniels> seb128: i mean, theoretically I'm responsible for that kind of crap but I try to avoid it as much as possible
[02:16] <daniels> azeem: rad
[02:17] <seb128> daniels: <Amaranth>     if a fd.o admin ever uploads lanius' key
[02:17] <seb128> if you know who this lanius is
[02:17] <daniels> ah, lanius
[02:17] <daniels> yeah, he pinged me, uh
[02:17] <daniels> two months ago
[02:17] <seb128> hehe
[02:18] <azeem> "Serious problems with Mr. Stone"
[02:18] <ogra> *giggle*
[02:18] <daniels> ------- Additional Comments From h_wendel@cojobo.net  2005-12-01 06:39 -------
[02:18] <daniels> sorry, in the meantime i created a new key, i'll attach it
[02:26] <Keybuk> right ... so let's see whether shiny-new-initramfs-script works
[02:31] <Keybuk> sooooo.....
[02:32] <Keybuk> who has a SATA or SCSI root filesystem and is feeling adventurous? :p
[02:32] <Keybuk> coz it worketh for me
[02:32] <jdub> hrm, only on my server :)
[02:32] <jdub> which is not running dapper yet ;)
[02:32] <Keybuk> heh
[02:34] <sistpoty> Keybuk: I guess HPT37X won't count?
[02:34] <sistpoty> (sata controller handled by hpt37x)
[02:34] <Keybuk> does it show up as /dev/hda or /dev/sda?
[02:35] <sistpoty> as /dev/hda
[02:35] <Keybuk> no, doesn't count then
[02:35] <Kamion> Keybuk: I do, although I think it already worked
[02:35] <Kamion> it was the one that showed up as a RAID controller
[02:35] <wasabi> hmm. /usr/lib/mozilla-firefox/libgtkembedmoz.so has vanished.
[02:36] <wasabi> Hmm. Nope it's there.
[02:36] <Keybuk> bah, where's the T43 fan-club when you need them? :p
[02:44] <fabbione> GOOOOOD MORNING EU EARLYBIRDS
[02:44] <zul> hey fabbione 
[02:44] <dholbach> hellas fabbione 
[02:44] <fabbione> maswan: hey dude...
[02:45] <fabbione> maswan: is there any possibility to get buttercup back online?
[02:45] <fabbione> maswan: we have a workaround for the kernel and soon a proper fix
[02:45] <fabbione> hi dholbach , zul
[02:46] <maswan> fabbione: yeah, I'll try to get it done, I think we are mostly done with using it as a solaris test install subject, but I'll have to check with the solarisers
[02:46] <fabbione> maswan: cool thanks
[02:52] <seb128> daniels: no weird value with the debug outpud
[02:53] <dholbach> hey seb128 :)
[02:53] <ogra> Keybuk, thats ajmitch in your initramfs ;)
[02:53] <seb128> re dholbach
[02:53] <seb128> daniels: src_x 0, src_y 1030, dst_x 0, dst_y 2054, w 1280, h 1024
[02:54] <Keybuk> ogra: what tool is doing that?
[02:55] <ogra> no idea, but ajmich migh know 
[02:55] <Keybuk> as long as it's nothing I broke, that's ok
[02:55] <Keybuk> but it's annoying
[02:57] <ajmitch> ogra: I didn't touch it
[02:57] <ogra> ajmitch, but you mght know what it means
[02:57] <ajmitch> yes, but I'm not sure why it's trying to mount it
[02:57] <ajmitch> it can't mount if the kernel is booted with selinux disabled (as the default is)
[02:58] <ajmitch> hi pitti 
[02:58] <ogra> Keybuk, so dont we boot with selinux disabled anymore ?
[02:59] <pitti> *yawn* good morning
[02:59] <jdub> hello pitti!
[02:59] <ogra> BenC, did that change ? ^^^^
[02:59] <pitti> Hi jdub, how are you?
[02:59] <jdub> hot!
[02:59] <jdub> you?
[02:59] <BenC> what?
[02:59] <pitti> jdub: tired
[02:59] <mdz> infinity: ping
[03:00] <ogra> BenC, selinux off by default
[03:01] <ogra> BenC, see Keybuks mumbling above
[03:01] <BenC> it defaults to off, yes
[03:01] <Keybuk> ajmitch: what's "it" ?
[03:01] <BenC> you have to pass selinux=1 for it to be enabled
[03:02] <BenC> I just took default settings for that based on breezy, so if it's different, it was unintentional
[03:02] <ajmitch> 'it' being /selinux
[03:02] <Keybuk> right, but what's trying to mount that and generating the error?
[03:03] <ajmitch> you get complaints about unknown fs type selinuxfs
[03:03] <Keybuk> the kernel itself?
[03:03] <Keybuk> gah, need to find a new musical
[03:03] <BenC> ogra: anything I need to fix?
[03:03] <ajmitch> the only think I see that changed recently was sysvinit
[03:03] <ogra> BenC, ask Keybuk :)
[03:04] <ogra> probably if he finds something
[03:04] <BenC> Keybuk: anything wrong with the selinux default config?
[03:04] <Keybuk> no idea
[03:04] <Keybuk> selinux smells
[03:04] <Keybuk> I keep far far away from it
[03:04] <Keybuk> it was there before I broke^Wmerged selinux
[03:04] <Keybuk> uh, sysvinit
[03:04] <BenC> heh, it's probably just the stinch of NSA on it :)
[03:05] <Keybuk> unless it is Manoj's patch
[03:05] <ajmitch> and I haven't been brave enough to reboot yet
[03:13] <Kamion> Keybuk: my SATA box boots fine with current dapper; if you want me to try something else, I can
[03:13] <Keybuk> yup, was manoj's patch
[03:14] <daniels> seb128: hrm
[03:14] <Amaranth> *sigh*
[03:14] <Amaranth> fscking computers
[03:14] <Amaranth> always breaking
[03:16] <Keybuk> what's broken now?
[03:16] <Amaranth> my motherboard
[03:16] <Amaranth> fans turn on, nothing else, won't turn off
[03:16] <ajmitch> Keybuk: selinux mounting was debian #329328 ?
[03:17] <Keybuk> no idea
[03:17] <Keybuk> I just disabled the entire patch
[03:17] <Keybuk> I imagine it's fixed in Debian and will get re-enabled when I turn mom on again
[03:17] <ajmitch> right, the other option is (14:46:49) slb12stephanie: ok thats relieving
[03:17] <ajmitch> sigh
[03:17] <ajmitch> export SELINUX_INIT=NO
[03:18] <Keybuk> where do you do that? :p
[03:18] <Keybuk> how do you export something to _INIT_
[03:18] <ajmitch> it says in the initrd, so in initramfs, no?
[03:18] <ajmitch> or as a kernel option if you want to
[03:19] <Keybuk> I thought run-init purged the environment?
[03:19] <Keybuk> otherwise all the initramfs variables would be leaked to the world
[03:25] <jdong> Breezy doesn't support dm-bbr?
[03:25] <jdong> I thought Hoary did
[03:26] <Amaranth> dm-bbr?
[03:27] <jdong> evms/device mapper's bad block relocation
[03:27] <jdong> i.e. handling bad sectors at a level below the filesystem
[03:27] <jdong> [4482447.706000]  device-mapper: unknown target type
[03:27] <jdong> dm-bbr.ko not in Ubuntu kernels
[03:28] <jdong> heh, not in Ubuntu kernel sources for Breezy
[03:28] <jdong> hmm
[03:29] <jdong> and to think we use evms and don't support its features... :-/
[03:31] <whiprush> jdub: CC/a11y summary in the fridge queue if you want to check it out.
[03:34] <Keybuk> fabbione, mdz: for dapper, I recomment only using /dev/disk/by-* for removable devices (which all appear as SCSI)
[03:35] <mdz> Keybuk: oh, that's a good criterion
[03:35] <Keybuk> for dapper+1 we can convince the kernel guys, or do ourselves, to add some "WAIT! THIS BUS IS NOT READY YET!" flag to /sys we can wait on
[03:35] <Riddell> infinity: please give back gwenview again
[03:36] <fabbione> Keybuk: hmmmm
[03:36] <fabbione> so why i can see my ata disks there?
[03:36] <Keybuk> because it's generic and done for every block device
[03:36] <Keybuk> what won't work is the initramfs bit :)
[03:37] <Keybuk> it'll fail for people with non-PCI/generic ide controllers because the initramfs won't know it needs to load ide-generic
[03:37] <fabbione> Keybuk: ok.. i think it's better to defer the specs than.
[03:37] <fabbione> we don't want to be so inconsistent in such delicate part of the installer
[03:37] <Keybuk> it'll work fine for SATA drives
[03:38] <fabbione> Keybuk: i don't think we want to play with this for dapper.. this really sounds something for dapper+1
[03:38] <Keybuk> by dapper+1 we may find that the kernel guys go with their plans to move all the old ide drivers into libata
[03:40] <fabbione> yes, and i think for the sake of consistency we should avoid dapper
[03:40] <HrdwrBoB> Keybuk: if that was the case, installing to USB would work
[03:41] <Keybuk> you should be able to install to usb now
[03:41] <HrdwrBoB> you can, but it won't boot
[03:41] <Keybuk> will
[03:41] <Keybuk> just change the root= line
[03:41] <HrdwrBoB> because the device waits to settle, and the initrd tries to boot
[03:41] <HrdwrBoB> then fails
[03:41] <Keybuk> initramfs waits for the device to settle now :)
[03:42] <HrdwrBoB> ah :)
[03:56] <whiprush> jdub: MOTU school announcement in the queue also, I think we should run that one on friday though.
[04:01] <mdz> fabbione: we should do it for cases where otherwise the install doesn't actually work properly (e.g., USB)
[04:01] <mdz> I think Keybuk's idea of doing it only for removable devices is safe and will fix some bugs
[04:01] <fabbione> mdz: i disagree. even an IDE disk can be removable
[04:02] <fabbione> and we have no way to know if it will be shuffled around
[04:02] <fabbione> it creates a big inconsistency in the installs
[04:02] <mdz> fabbione: the kernel has a concept of removable devices; that's what I'm talking about
[04:02] <mdz> e.g., flash media and USB
[04:02] <fabbione> mdz: i have a USB disk..
[04:03] <fabbione> it's a 2.5"
[04:03] <fabbione> that's something i stick into laptop's and becomes IDE
[04:03] <Keybuk> fabbione: if an IDE disk is removable, it doesn't show up as an IDE disk
[04:03] <fabbione> Keybuk: it might in the next boot
[04:03] <fabbione> go figure
[04:04] <fabbione> user case: my cdrom is broken and my laptop doesn't boot from netcard
[04:04] <fabbione> i stick my hd in a usb thingy
[04:04] <fabbione> install ubuntu put it back in the laptop
[04:04] <fabbione> assuming that we claim to be able to recognize root, that will just be bad
[04:04] <ogra> Kamion, do you think flight 2 might happen this week ? 
[04:05] <Keybuk> right, but that's new functionality
[04:05] <fabbione> mdz: i really really believe that this is not material for dapper. either we can be consistent, or we skip
[04:05] <Keybuk> if we just advertise it and test it for known-removables like installing to USB
[04:05] <Keybuk> and worry about the "move things around" for dapper+1
[04:06] <fabbione> Keybuk: i still don't like it really.. let's do it for dapper+1 and do it properly, once. it sounds too hairy to me to go around and check if drivers are removable or not, try to guess and so on
[04:06] <Keybuk> that's easy
[04:06] <Kamion> ogra: depends largely on how much work fixing casper turns out to be
[04:06] <mdz> Keybuk: surely we can use a smarter test than looking at root= and address it that way
[04:07] <Keybuk> mdz: if you can think of one, I'm all ears
[04:07] <ogra> Kamion, ok, i just want to know if i need to push my ppc dealer :)
[04:07] <Kamion> ogra: 3am is not the best time to ask me this kind of question ;)
[04:07] <mdz> Keybuk: we need to know before the device is created?
[04:08] <ogra> Kamion, sorry ... :) i'm used to it, normally up until 4 :)
[04:08] <mdz> Keybuk: it still seems like a kernel bug to me
[04:08] <Kamion> my normal bedtime is more like 11 these days
[04:08] <Keybuk> yup
[04:08] <Keybuk> we need to know what bus it's on in order to do the right thing to create the device
[04:08] <Keybuk> I'm inclined to agree
[04:09] <Keybuk> the kernel doesn't inform us that the driver is still poking around
[04:09] <Kamion> zul: I do think it'd be more helpful to get Flight 2 out and then ping people to retest with that
[04:09] <ogra> Kamion, yes, forgot, youre a father now ;)
[04:09] <Kamion> (grub)
[04:09] <Keybuk> if there were a sysfs attribute to say whether the driver was scanning the bus or not, it'd be easy
[04:09] <Kamion> just because that gets us 0.97
[04:09] <Kamion> ogra: stepfather
[04:10] <Kamion> important distinction around here
[04:10] <ogra> still a child involved :)
[04:10] <Keybuk> IDE is actually helpful, it doesn't let modprobe exit until it's claimed all the devices it wants
[04:10] <Keybuk> SCSI isn't helpful, it lets modprobe exit and then starts poking around
[04:10] <zul> Kamion: sure no problem...just going through them
[04:10] <Keybuk> and anything implemented using SCSI (SATA, USB, IEEE1394, etc.) gain this unhelpfulness
[04:12] <ogra> thats such a mess ... people just register packages randomly
[04:12] <Keybuk> if we could wait for a scsi driver to stop scanning for devices in a udev rule, the job would easy
[04:12] <Keybuk> 1) poke every storage controller we can find
[04:12] <Keybuk> 2) if $ROOT still doesn't exist, try loading ide-generic
[04:13] <Kamion> zul: you may also find some bugs filed on grub-installer
[04:13] <Keybuk> without a way to know whether the driver is scanning (where we are now) we can't do #2 because #1 hasn't finished
[04:13] <Keybuk> the only way to know whether the driver has finished scanning is to loop until $ROOT exists, and for scsi (especially usb) that can take up to 30s
[04:14] <Keybuk> and I'm inclined to think people with ISA/generic IDE controllers won't be happy about that 30s wait
[04:14] <Keybuk> (we actually have requests to make that wait up to 3 MINUTES)
[04:14] <Amaranth> top forums guys are threatening to split if the CC tries to say they have any control over their operation
[04:14] <Keybuk> (and to truly support usb root, we should make that wait forever, to allow them time to find it and plug it in)
[04:15] <zul> Kamion: i selected all of grub* in my bug query 56 bugs found
[04:17] <ogra> sounds like we should put up a motto for the next bugday ... call it gub bugday or something to point bugsquasher to them
[04:17] <ogra> s/gub/grub
[04:17] <zul> ogra: kernel has 500+ ;)
[04:18] <zul> ogra: kernel has 500+ ;)
[04:18] <ogra> zul, kernel has an upstream ;)
[04:18] <zul> brb
[04:18] <ogra> who eventually fixes bugs :)
[04:18] <Kamion> so does grub to some extent
[04:18] <ogra> i thought its unmaintained
[04:19] <Kamion> as I said in the meeting we got a new upstream release relatively recently
[04:19] <ogra> v1 that is
[04:19] <Kamion> it's not very actively maintained but the maintainer does IME respond to mail, at least eventually
[04:19] <ogra> ah, k
[04:19] <Kamion> I'm not sure general bug-squashing manpower helps with grub; you need a lot of specialist boot knowledge
[04:20] <Kamion> or else you end up just flailing around saying WORKSFORME
[04:20] <ogra> usually the bugday squashers only confirm etc ... 
[04:20] <Kamion> Amaranth: please, that isn't an #ubuntu-devel issue
[04:20] <ogra> but you could get them o do all the paperwork of pinging reporters etc
[04:21] <Kamion> what I really don't want is people repeatedly pinging reporters when there's no possibility that a bug has been fixed
[04:21] <Kamion> that just annoys reporters and eventually they stop answering you ...
[04:21] <Kamion> anyway, bedtime
[04:21] <ogra> night Kamion 
[04:22] <zul> same here..
[04:22] <zul> night
[04:22] <ogra> night
[04:26] <Keybuk> yup, definitely bed time
[04:26] <Keybuk> back in ~8hrs
[04:26] <jdub> mjg59: not sure it's crucial functionality
[04:26] <jdub> mjg59: but if it's a quick patch, it'd be way sweet
[04:27] <mjg59> jdub: No, but getting beyond just hanging the machine would be good
[04:27] <jdub> mjg59: have you seen any Z series machines yet?
[04:27] <mjg59> jdub: We can get at least as good as the people using hdparm to register/unregister their IDE bus, which is what currently happens
[04:27] <jdub> winkle: 13
[04:27] <jdub> boh
[04:27] <mjg59> jdub: I haven't, no
[04:28] <mjg59> jdub: You? I'm curious to know how Thinkpad-like they are
[04:30] <jdub> me too
[04:31] <whiprush> howdy jdub.
[04:36] <jdub> have to think about my next machine
[04:37] <lifeless> x1
[04:37] <lifeless> you know you want to
[04:37] <mjg59> jdub: Just tested
[04:37] <ogra> bah, you dell addicts
[04:37] <mjg59> jdub: Pulling out the CD drive just closed the Nautilus window open on it
[04:38] <jdub> lifeless: don't really want a keyboard that size
[04:38] <mjg59> jdub: Putting the CD drive back in mounted the CD in it automatically
[04:38] <jdub> i'm really only looking at X40, possibly Z series at this point
[04:38] <jdub> i was very happy with the formfactor of the X300 (plus it had a trackpad)
[04:38] <jdub> mjg59: phwoar, rad :)
[04:38] <lifeless> keyboard is the same ;)
[04:39] <mjg59> jdub: With a file selector open on it, ripping out the CD drive just removes the CD drive from the left pane and blanks the right pane
[04:39] <mjg59> We are /so/ shipping this patch
[04:39] <jdub> pipka will love you for that :)
[04:39] <jdub> lifeless: the X1 keyboard was not the same as the X300
[04:39] <mjg59> jdub: And putting the drive back in results in the files appearing in it again
[04:40] <lifeless> mm, felt the same to me
[04:40] <jdub> (of course, that will make her ask if she should upgrade to dapper again)
[04:42] <mjg59> jdub: So now I just have to figure out a way of doing it for PATA (or convince Ben that switching to the somewhat experimental PATA/libata drivers is a good idea)
[04:43] <jdub> and perhaps whiltelist the good ones of those?
[04:44] <mjg59> jdub: The only really interesting ones are the Intel and VIA ones, really
[04:45] <mjg59> Unless Alan writes an ATI one
[04:45] <jdub> can we choose between ide layer and libata drivers like that?
[04:46] <mjg59> There are two issues:
[04:46] <mjg59> 1) They claim the same PCI IDs. Without blacklisting/whitelisting/something then we're not sure which one we'll get
[04:46] <mjg59> 2) They result in people's drives moving from hda to sda, and we have to work out how to manage that transition
[04:48] <mjg59> jdub: At the moment, I'd lean towards building them but not having them loaded by default - then people can play if they want to, but I doubt they'll be ready for primetime by Dapper
[04:55] <wasabi> One of these days I've like to see EVMS be used by default for everything. ;)
[04:57] <jdub> i'd like to see zfs on linux instead :)
[04:57] <ogra> ogra@honk:~/dapper-xss/bastel/xscreensaver-4.23 $ free
[04:57] <ogra>              total       used       free     shared    buffers     cached
[04:57] <ogra> Mem:        506164     500124       6040          0       1232      25224
[04:57] <ogra> -/+ buffers/cache:     473668      32496
[04:57] <ogra> Swap:       979956     556660     423296
[04:57] <ogra> hmm, i have xchat, evolution and 2 terminals open 
[04:57] <wasabi> How does ZFS fix this?
[04:57] <wasabi> What's so great about ZFS anyways he
[04:58] <wasabi> oh, uh, checksums.
[04:58] <wasabi> Wow.
[04:59] <jdub> there's a great presentation by jeff bonwick which is well worth reading
[04:59] <jdub> that goes through the salient points
[04:59] <SEJeff> link?
[04:59] <wasabi> google.com
[04:59] <jdub> googleable, i'm sure - it's just sitting on my desktop atm
[05:00] <ajmitch> ogra: that's looking a little heavy
[05:00] <daniels> jdub: so are you in melbourne today?
[05:00] <ogra> ajmitch, killing evo freed 800MB
[05:00] <daniels> jdub: or is that tomorrow?
[05:00] <jdub> daniels: nup, back home
[05:00] <daniels> jdub: bastard.
[05:00] <daniels> YOU DON'T LOVE ME ANYMORE
[05:00] <daniels> you and pipka not having lunch and/or beer with me is against the code of conduct
[05:01] <jdub> yeah
[05:02] <SEJeff> But I don't think zfs supports online resizing. ext3 does so ext3 makes more sense for a server
[05:03] <jdub> eh? dude. read up.
[05:03] <jdub> zfs is intensely cool for a server
[05:03] <jdub> totally different kettle of fish to ext3/lvm/evms
[05:03] <wasabi> Hmm.
[05:03] <wasabi> Raid built into the file system.
[05:04] <mjg59> daniels: If you continue with this criticism, you'll be banned and have your posts deleted
[05:04] <SEJeff> I just found the article. Checksums and other niceties. http://www.sun.com/2004-0914/feature/
[05:04] <ajmitch> ogra: usually it's firefox or galeon that does that for me :)
[05:04] <seth_k> mjg59, NOOOOO, don't make me have forums flashbacks, I'm already banned from there :P
[05:04] <ogra> ajmitch, i started it again and it immediately claims 200M of ram and 300M of swap ... 
[05:12] <wasabi> This is hilarious: http://blogs.sun.com/roller/page/bonwick/20040925
[05:14] <wasabi> I do actually wonder how hard it would be to create a OpenSOlaris/LInux fs bridge
[05:16] <jdub> mmm, usb over ip patches proposed by gregkh
[05:16] <wasabi> usb over IP?
[05:16] <wasabi> I might actually have a use for that.
[05:20] <wasabi> So might LTSP heh
[05:21] <ogra> yeah
[05:22] <ogra> jdub, got an url ? 
[05:22] <wasabi> http://usbip.naist.jp/
[05:22] <ogra> ah that one.. iinspected it for ltsp local devices
[05:23] <jdub> BenC: will dapper kernels on breezy be scary?
[05:25] <ogra> wasabi, but jdub sounded rather like it'd be a upstream kernel thing ...
[05:25] <Amaranth> jdub: Hotplug went away, I'd say that's a given.
[05:25] <wasabi> ogra, dunno, maybe that one was submitted? I dunno
[05:26] <ogra> wasabi, pre alpha ? 
[05:26] <ogra> unlikely
[05:26] <ogra> lats release 20041130
[05:26] <infinity> Yeah, there's never been pre-alpha code in Linus's tree...
[05:26] <ogra> *last
[05:26] <infinity> The part where it's unmaintained since 2004 is a bit worse, though.
[06:15] <fabbione> ogra:
[06:15] <fabbione> Unpacking replacement xscreensaver-data ...
[06:15] <fabbione> dpkg: error processing /var/cache/apt/archives/xscreensaver-data_4.23-2ubuntu3_amd64.deb (--unpack):
[06:15] <fabbione>  trying to overwrite `/usr/share/xscreensaver/config/README', which is also in package xscreensaver
[06:15] <StevenK> Whee.
[06:16] <infinity> fabbione : I just uploaded a fix for that.
[06:16] <fabbione> infinity: ok thanks
[06:48] <jsgotangco> hey moquist long time no chat
[07:46] <tux-rox> jdub, just wanted to say thanks for the great presentation at PSU. I brought a friend along who is relatively new to FOSS and she also enjoyed to talk as well.
[07:47] <jdub> tux-rox: cool, thanks :)
[07:48] <tux-rox> Ya, you were here at a strange weather time. It is usually not so crappy...
[07:48] <tux-rox> Rain, yes, but it was a bit colder than usual for this time of year.
[07:49] <tux-rox> Anyhow, I am glad you enjoyed the visit. Take care.
[08:45] <sivang> morning all
[09:32] <pitti> Good morning
[09:34] <Mithrandir> hi pitti
[09:34] <pitti> Hi Tollef
[09:45] <dholbach> good morning
[09:47] <\sh> moins
[09:48] <\sh> grrrr..fighting with dd-wrt on linksys and wanting wireless xdmcp sessions 
[09:49] <ajmitch> hi
[10:32] <pitti> infinity: thanks for cleaning up m-f-l-all
[11:03] <pitti> Riddell: ping
[11:05] <dholbach> he uploaded until 5 - i doubt he's awake
[11:05] <dholbach> past 5
[11:06] <doko> chmj: pong
[11:07] <chmj> doko: nm, figured out 
[11:29] <slomo> infinity, lamont-away: any idea why mod-mono isn't even tried to build on ppc/ia64? should work fine imho
[11:30] <tseng> slomo: its probably blacklisted from way back
[11:31] <slomo> tseng: why? was it completly broken in the past?
[11:32] <tseng> slomo: at one point mono* was broken :)
[11:53] <ogra> fabbione, sorry, Riddell reported exactly the opposite, thats why i "fixed" it in first place yesterday, jdub has the same prob as you
[12:03] <Diziet> Bizarre.  The postman just called and has delivered a document to do with a lawsuit in the US about VA Linux.  Somehow, apparently, I was hard done by in an unfair and illegal way, when they gave me free money.  Boggle.
[12:06] <lifeless> woo
[12:07] <Diziet> It seems to suggest that because they so unfairly gave me free money earlier, I might be entitled to compensation now.  I think it must be a get-very-rich-over-many-years scheme for lawyers.
[12:08] <Diziet> When I get a moment I think I'll post to debian-devel or -private about it.  Presumably other people from the time of the VA IPO will have had them too.
[12:11] <Mithrandir> so since you were given free money, they are giving you more free money?
[12:12] <Diziet> Something like that.  Actually I think mainly lawers will get money.
[12:13] <Diziet> It's all quite dense and I haven't read it properly.  When I have I'll post to debian-devel, I think.
[12:13] <Diziet> But now I should do some actual work rather than boggling at the mad USAian legal system.
[12:17] <pitti> Mithrandir: hm, if you actually changed something in nmap, it shuold be -ubuntu1, not -build2
[12:18] <pitti> Mithrandir: oh, not dch?
[12:18] <pitti> :)
[12:18] <Mithrandir> no, the emacs-changelog mode.
[12:18] <Mithrandir> pitti: anyway, thanks, fixed.
[12:18] <pitti> thanks
[12:22] <seb128> daniels: around?
[12:23] <pitti> speaking of daniels, am I the only one who experiences video driver regressions with both nv and ati?
[12:23] <pitti> on nv I get flickering while pressing keys, on radeon my screen gets scrambled and colored oddly
[12:24] <seb128> pitti: ati on ppc?
[12:24] <pitti> seb128: yes
[12:24] <pitti> and nv on amd64
[12:24] <seb128> pitti: does using 16bpp fixes it?
[12:24] <pitti> seb128: no idea, I just filed a bug so far, but didn't play with it
[12:24] <Kinnison> pitti: breezy + nvidia + amd64 is definitely a regression from hoary
[12:24] <pitti> Kinnison: I don't use the nvidia driver, just the opensource nv one
[12:24] <Kinnison> pitti: breezy + nv + amd64 doesn't render stably on my boyfriend's pc
[12:24] <seb128> pitti: the ati/ppc issue is likely http://bugzilla.ubuntu.com/show_bug.cgi?id=20286
[12:25] <Kinnison> pitti: It puts snow and distortion on the screen
[12:25] <pitti> Kinnison: and it worked fine on breezy, regression is on current dapper
[12:25] <Kinnison> pitti: Hmm
[12:25] <seb128> pitti: if using 16bpp fixes it, that's this bug
[12:25] <Kinnison> pitti: I think the quality of the driver is regressing because for my rob, hoary was fine, breezy was slightly not worky
[12:25] <pitti> seb128: ah, cool; I'll check that and close mine as a dup then
[12:26] <pitti> seb128: thanks Seb (you have an awesome memory for bugs :) )
[12:26] <seb128> np ;)
[12:27] <seb128> (not really, this bug was just assigned to nautilus and I sorted that with daniels this night before meeting :p)
[12:30] <slomo> pitti: i have the same problem with a radeon on ppc
[12:30] <pitti> slomo: I'm fairly sure it's the same bug as I have, but I'll check it
[12:31] <pitti> I need to boot the iBook first, sleep doesn't work any more
[12:31] <slomo> pitti: hm, works for me
[12:32] <zyga> guys how long does it take for new members to appear on the official list on launchpad?
[12:33] <pitti> slomo: well, it works with 2.6.15, but this breaks my wireless; and with 2.6.12 I don't get /dev/pmu any more with new udev
[12:35] <slomo> pitti: hm, i unplug my usb wireless thingie every time before sleep... the airport extreme doesn't work with wep currently
[12:36] <pitti> slomo: I use prism2_usb (l-wlan-ng), it doesn't work with 2.6.15 any more; which driver do you use for the usb?
[12:37] <slomo> pitti: exactly the same... weird
[12:37] <pitti> slomo: https://bugzilla.ubuntu.com/show_bug.cgi?id=20498
[12:39] <slomo> pitti: i get this message about /proc/net/wireless too but it works nonetheless
[12:39] <pitti> slomo: hmm, thanks; which usb card do you have? I have a Netgear MA-111
[12:40] <slomo> pitti: d-link dwl-122
[12:46] <janimo> is ALSA supposed to work with current kernel/udev already?
[12:46] <pitti> janimo: WFM
[12:47] <janimo> forgot what that means :)
[12:47] <pitti> works for me
[12:47] <janimo> aha
[12:47] <janimo> automatic eth interface bringup?
[12:55] <pitti> mvo: hm, poppler-utils C/R/P xpdf-utils since hoary
[12:56] <pitti> mvo: so it seems that only the versioned dependency of xpdf should be dropped
[12:56] <mvo> pitti: fine with me
[12:59] <seb128> Diziet: do you have some bug about /usr/lib/mozilla-firefox/components/compreg.dat still installed on dapper?
[12:59] <seb128> Diziet: it's shipped by firefox 1.0.7 package but no 1.4.99, it should be removed on upgrade, no?
[01:01] <slomo> elmo_: can you sync from debian NEW?
[01:02] <pitti> slomo: we don't do it in general, we wait for Debian's sanity checks
[01:03] <seb128> pitti: it's for binary change
[01:03] <seb128> ie: not a new NEW package
[01:06] <Kamion> syncing from Debian NEW would require elmo to use his position as a Debian ftpmaster to work on Ubuntu, since NEW isn't public
[01:07] <Kamion> I don't know if he does it or not but if I were him I'd be worried about mixing up the hats too much
[01:07] <Mithrandir> incoming is fine to sync from, though
[01:07] <Kinnison> Kamion: I'd have invited you to come to the kingston but I don't have your home number and your mobile is off. You should join us :-)
[01:07] <Kamion> yes, incoming's basically "pending part of the archive but apt-ftparchive's too slow to run continuously"
[01:08] <Kamion> (etc.)
[01:08] <Kamion> Kinnison: ooh. when? now?
[01:08] <Kinnison> Kamion: aye
[01:14] <Kamion> Kinnison: ok, I'll head out in five
[01:15] <Kinnison> Kamion: I think there's parking space in front of the pub
[01:15] <Kinnison> Kamion: otherwise there's room in the gwydir st car park
[01:17] <Robot101> Kinnison: are you at the Kingston perchance? :D
[01:17] <Kinnison> Robot101: of course
[01:17] <Kinnison> Robot101: smokestack lightning
[01:17] <Kinnison> So good
[01:26] <GnuKemist> elmo_, good morning...  can you help me change my email on launchpad from og-maciel@ubuntu.com to ogmaciel@ubuntu.com (no dash)?  I need to be able to give people I've been advocating to my corrected email...
[01:38] <jbailey> wasabi: ping?
[01:43] <mvo> Diziet: mind if I reassign #13750 to you (ff enhancement request)?
[01:49] <ssam> is there a due date for flight 2?
[01:53] <ssam> http://bugzilla.ubuntu.com/show_bug.cgi?id=8320#c11 implies its out now
[01:56] <seb128> daniels: ping?
[02:01] <Kamion> ssam: no, and it's not out
[02:02] <Kamion> ssam: the comment is valid for the future :-)
[02:14] <Keybuk> well, that's gotta be good.  I've been on for a while and nobody's jumped one me yet
[02:15] <ssam> kamion thanks
[02:21] <ogra> oooh Keybuk !!
[02:21] <pitti> Keybuk: run!
[02:21] <ogra> Keybuk, just wanted to say good morning ;)
[02:24] <Keybuk> heh
[02:24] <Keybuk> ogra: how's your laptop this morning?  do you have dma?
[02:24] <sivang> anybody idea what's with the fridge? it seems down..
[02:24] <ogra> yup
[02:24] <zakame> er, is it possible for pdebuild to sign both {source,$arch}.changes? I currently have it so that it signs only $arch.changes, but not the source.changes...
[02:24] <ogra> Keybuk, everything fine over here
[02:24] <Keybuk> good-o
[02:25] <ogra> zyga, http://people.ubuntu.com/~ogra/bzr-archive/hwdb-client/ this is for you ... but beware, the code is a mess, i'll jump on it the next days and rearrange/clean up a lot
[02:26] <zyga> ogra: thank you :-)
[02:26] <zyga> ogra:I'll have a look in 30 minutes, most of my patches should be non-intrusive
[02:26] <ogra> oki
[02:27] <ogra> BenC, for your kids (i'll package it the next days, but if you need it soon, grab it) https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&id=226
[02:28] <BenC> ogra: nice, let me know when it's ready and I'll test it
[02:28] <ogra> yup :)
[02:40] <lamont-away> %mod-mono: amd64 i386                                                  # i386-only, but should it be?
[02:40] <lamont-away> slomo: that's why... should we change it?
[02:41] <slomo> lamont-away: i see no reason why it shouldn't build on ppc/ia64... but if you want i can testbuild on ppc in a few minutes
[02:44] <lamont-away> I just made it the same as the rest of the mono packages
[02:46] <slomo> lamont-away: thanks... what is it for the other mono packages? i386, amd64, powerpc, ia64?
[02:48] <lamont-away> %mod-mono: amd64 i386 powerpc arm ia64 s390
[02:48] <slomo> ok :)
[02:55] <Diziet> python--
[02:55] <Diziet> >>> output = Popen(["false", "diedammit"] , stdout=PIPE).communicate()[0] 
[02:55] <Diziet> >>> 
[02:59] <seb128> Diziet: have you read about http://bugzilla.ubuntu.com/show_bug.cgi?id=20183 ? It makes all apps using gecko crashing on some boxes, would be one of the bug nice to sort :)
[02:59] <crimsun> elmo_: please sync osdsh and lablgl from Sid (ok to override Ubuntu changes), thanks
[03:02] <pitti> Riddell: here?
[03:04] <Diziet> seb128: Yes, um, I'd seen it but I'm confused about it.
[03:05] <Diziet> You say this file (compreg.dat) is supposed to be removed.  So do we know why it isn't ?
[03:05] <seb128> Diziet: I supposed it's supposed to be removed, it's not installed on my dapper
[03:05] <seb128> the package .list doesn't mention it
[03:06] <seb128> and it was listed with 1.0.7
[03:06] <Diziet> Are you sure that the package is supposed to be removed ?  Perhaps it's a mistake that it has disappeared.
[03:06] <Diziet> I can't see how it would fail to go away during the upgrade if it's in the old package but not the new one.
[03:06] <seb128> if a file is shipped by 1.0.7 and not 1.4.99, it's supposed to be removed by dpkg on update, no?
[03:07] <Diziet> Yes.  Except perhaps if it's a conffile.
[03:07] <seb128> there was some symlink stuff to /var too with 1.0.7, but I don't know firefox well, just discussed with epiphany upstream
[03:07] <seb128> I just know that we have like 4-5 bugs now of people have gecko apps crashing with firefox1.5
[03:08] <seb128> and we tracked the crash this morning to this file, removing it fix the issue and it's not installed on my box/listed as a firefox file ... ie: it should not be here
[03:09] <seb128> $ grep compreg /var/lib/dpkg/info/firefox*
[03:09] <seb128> /var/lib/dpkg/info/firefox.prerm:    rm -f /var/lib/mozilla-firefox/components/compreg.dat
[03:09] <Diziet> /var/lib ??
 firefox.list:/usr/lib/mozilla-firefox/components/compreg.dat
[03:10] <daniels> seb128: REPRESENT
 here on breezy it's a symlink to /var/.... ?
[03:10] <Diziet> So on the systems that have the file, where it's breaking, what does  dpkg -S  say ?  And what about  dpkg -s firefox  ?
[03:11] <Diziet> symlink to var> So it is, on my breezy install too.
 doctau: does /usr/lib/mozilla-firefox/components/compreg.dat exist ?
       yep
 what does dpkg -S say for that file? is it installed by the package?
       chpe: nop
       not owned by a package
[03:11] <Diziet> I don't see how compreg.dat could be in firefox.list if they've got the new firefox package.
[03:11] <Diziet> ????
[03:12] <seb128> Diziet: chpe uses breezy with 1.0.7
[03:12] <seb128> doctau uses 1.4.99
[03:12] <seb128> sorry for not beeing clear
[03:12] <Diziet> Ah.
[03:12] <seb128> and according to chpe, /usr/bin/firefox does some stuff with this file on breezy
[03:12] <Diziet> So which machine doesn't work ?
[03:13] <seb128> the issue is with current dapper
[03:13] <seb128> some people have this file and they should not
[03:13] <Diziet> doctau's machine then ?
[03:13] <seb128> yep
[03:13] <seb128> some people have it and it doesn't come from a package according to dpkg
[03:13] <Diziet> Oh, err, just a mo, I have an idea.
[03:13] <Diziet> Let me think.
[03:14] <Diziet> I'm guessing here, but here's my theory:
[03:14] <Diziet> This file is a registry of components including extensions.
[03:14] <Diziet> If you have pre-1.4.99 extensions installed then this compreg.dat file is updated by those extensions somehow, normally.
[03:15] <Diziet> But the 1.0.7 package makes it a symlink to /var so the file ends up in /var.
[03:15] <Diziet> Now the 1.5 package removes the symlink.  Then if anything were to try to create the file in /usr it would just go ahead and do so.
[03:15] <Diziet> So we need to find out who is creating this file.
[03:16] <Diziet> I'm tempted to suggest a test version of the ff 1.5 package which does chattr +i on it.
[03:17] <Diziet> Also, I suppose if you have ff running as root when you upgrade it might manage to create this file somehow.  I have no idea what bits of the ff and extensions touch it.
[03:17] <seb128> hum, maybe yeah
[03:17] <seb128> but is it useful?
[03:17] <seb128> maybe firefox postinst should just clean it?
[03:17] <seb128> if -f ... rm -f it
[03:17] <Diziet> What, this file ?  Evidence suggests that the file is not used in 1.5.
[03:17] <Diziet> Err, how would that help ?  dpkg has already removed it.
[03:17] <Diziet> The problem is obviously that something is creating it again later.
[03:17] <seb128> right
[03:18] <Diziet> And it has to be something than runs as root.
[03:18] <Diziet> s/than/that/
[03:18] <Diziet> So my best guess at the culprit is some extension or embedder's maintainer scripts, probably indirectly.
[03:19] <Diziet> Obviously normal dapper systems don't have this.  So I suspect that it happens when you run an old Breezy package's maintainer scripts when that package is updated after ffox.
[03:19] <Diziet> What do you think of my theory ? :-)
[03:20] <Diziet> Let me think what the best way to test it would be.  Hmm.  Install breezy (or find a not-yet-upgraded breezy system).  Update just firefox.  Create this file again as a symlink to /dev/enoent/firefox.
[03:20] <Diziet> Then do the rest of the upgrade.
[03:20] <seb128> doctau has installed a dapper flight1
[03:20] <seb128> which had firefox 1.0.7
[03:20] <Diziet> Or alternatively make a firefox 1.5 package which has /usr/lib/mozilla-firefox/components/compreg.dat -> /dev/enoent/firefox
[03:20] <seb128> and upgraded since
[03:21] <Diziet> Mmm.
[03:21] <Diziet> But so did I and it doesn't do it for me.
[03:21] <Diziet> Presumably doctau has more extensions and stuff than I do.
[03:21] <seb128> note than doctau doesn't use firefox
[03:21] <Diziet> Does this mainly seem to happen with epiphany ?
[03:21] <seb128> I'm not even sure it runned firefox once before, I'll ask him
[03:22] <seb128> the file breaks gecko (epiphany doesn't run, devhelp/yelp crash)
[03:22] <seb128> firefox works fine
[03:23] <Diziet> Is this epiphany etc. built against ff 1.0.7 -dev packages ?
[03:23] <seb128> no
[03:23] <Diziet> Hmm.
[03:23] <seb128> that's the current dapper i386 package
[03:24] <seb128> and I've updated the Build-Depends to say >= 1.4.99
[03:24] <seb128> 1.4.99something to be exact, where something is the version you didn't built staticly :)
[03:24] <Diziet> How about this for a plan: since we have a workaround (delete the file) I will postpone dealing with this until my next round of firefox maintenance (ie probably at least a week).  In the meantime if any information surfaces about what creates the file we can add it to the bug report.
[03:25] <Diziet> I'll change the bug priority to P1 to make sure I pick it up later.
[03:26] <seb128> Diziet: fine with me. I was just pointing it as something we want to try to sort before 6.04, no hurry
[03:26] <Diziet> Right.  Indeed, thanks for drawing it to my attention and helping out.
[03:27] <Diziet> seb128: Done, thanks.
[03:27] <seb128> Diziet: np, thank you :)
[03:50] <zyga> ogra: how do you properly translate help calls (yelp) that has /C/  inside, should I add magick that makes C -> locale?
[03:51] <ogra> i'd be grateful if you did, yes ;)
[03:51] <Keybuk> yup
[03:51] <Keybuk> ww
[03:54] <Riddell> pitti: hi
[03:56] <zyga> ogra: gaa, you are using a mixture of tabs and spaces
[03:57] <zyga> ogra: can we agree on a tab-or-space style? I prefer spaces
[03:57] <ogra> i prefer tabs :) 
[03:57] <zyga> ogra: any vim settings you use?
[03:57] <ogra> but switch it as you like, i can handle it
[03:57] <zyga> ogra: that will make the diff huge
[03:57] <ogra> only default vim
[03:58] <ogra> as i said, the code is ugly as hell :)
[03:58] <ogra> so i'm expecting ugly big diffs ...
[03:58] <zyga> ogra: hmm, so you wont mind if I retab everything and do all sorts of cleanups?
[03:58] <ogra> nope, not at all ...
[03:58] <zyga> allright, thank you :)
[03:59] <slomo> BenC: any idea when you will look at the libraw1394 update i sent to you? some packages are waiting for it now :/
[04:00] <BenC> slomo: someone in debian is supposed to do the new package and push it through their mentor/proxy
[04:00] <BenC> I honestly haven't  had the time to even think about it
[04:01] <BenC> check the bug reports on it, and you can find the guy that is wanting to do it
[04:01] <BenC> ping him for progress
[04:01] <slomo> ok, i'll do it on saturday... i've no time before :/
[04:02] <BenC> this was about a week ago, so I was really expecting it to be done by now
[04:05] <zyga> ogra: http://ubuntu.suxx.pl/hwdb-client--main 
[04:06] <zyga> ogra: just my branch, not done at all
[04:06] <ogra> zyga, great, i'll monitor it :)
[04:13] <fabbione> elmo_: can you please sync util-linux from sid. ok to override ubuntu changes
[04:13] <fabbione> (in incoming)
[04:13] <lamont> elmo_: also postfix, same story
[04:14] <zyga> ogra: just a question: in hwdb-bastel, the longish filename... what is it supposed to do?
[04:14] <zyga> (it looks like it's supposed to be random')
[04:14] <ogra> hmm, i have a bastle foler in there... oops... didnt notice
[04:15] <zyga> bastle?
[04:15] <ogra> oh, no its not a folder ...
[04:15] <Kinnison> Everyone: Kamion has had a disk failure in his server and thus will be offline for a while
[04:15] <ogra> thats the server side, its accidentially in there ...
[04:16] <zyga> ogra: k, I'll leave it as is
[04:16] <ogra> zyga, ignore it, i'll remove it
[04:16] <ogra> the filename is the actual filename that gets bzipped and uploaded btw
[04:16] <zyga> I see
[04:19] <ogra> the app generates a md5 sum of the file which becomes the filename ... and the HW id on the server for this record
[04:21] <zyga> ogra: hmm, other issue
[04:21] <zyga> you do .startswith and endswith often
[04:21] <zyga> that smells sensitive to gettext corruption
[04:21] <ogra> yup, that'll be part of the cleanup
[04:22] <ogra> my string handling skills in python were quite bad back then, it has improved, dont worry ...
[04:22] <ogra> if you want to change ti, feel free, elsewait until i get to it ...
[04:23] <ogra> (note it wasnt touched at all in berrzy, i only fixed 2-3 minor bugs) 
[04:23] <ogra> *breezy
[04:24] <ogra> also the xml handling will see a rewrite
[04:24] <zyga> hmm
[04:24] <zyga> actually I dont mind endswith and such
[04:24] <zyga> I'm just not sure on how to handle those
[04:24] <zyga> I cannot wrap that in _()
[04:25] <zyga> it needs a smarter test
[04:25] <ogra> yup
[04:25] <zyga> all I did so far was the non-intrusive changes
[04:25] <ogra> ok
[04:25] <zyga> now I'm looking at the hard bits
[04:25] <ogra> thats good for a start
[04:25] <zyga> I still need to read everything and understand how this works exactly
[04:25] <ogra> heh, might be hard :)
[04:26] <zyga> nah
[04:26] <zyga> I'll learn how to use xml from python
[04:26] <zyga> :-)
[04:26] <ogra> its rather perl style written in another lang, so it suffers in this area 
[04:26] <zyga> hehe
[04:27] <ogra> (i must admint that i'm shocked myself by the code somethimes :) )
[04:27] <ogra> -h
[04:27] <zyga> I like python
[04:27] <zyga> it forces clean code somehow
[04:27] <zyga> unlike perl that loves !@!#%@53436 for variables
[04:27] <ogra> me too, but i just had started with it when i started hwdb
[04:27] <Diziet> Punctuation isn't dirty, you know.
[04:28] <zyga> Diziet: only when spelled 'punctuation' ;-))
[04:28] <ogra> and the odd thing is that you can still write it lik a perl app even if its python
[04:28] <zyga> ogra: I had tabstop=4  so your code looked like random indent
[04:28] <ogra> just omit brackets and smicolons *g*
[04:28] <zyga> heh
[04:28] <zyga> :)
[04:28] <zyga> k, back to work
[04:30] <Diziet> zuga: So how do you spell it ?
[04:34] <zyga> Diziet: punctuation, do not confuse with , . ; : _ and other such maddnes
[04:35] <Diziet> I see.  What a strange opinion.  I find Python *very annoying*.
[04:36] <paxer> hi who is responsible for the NetworkMagic Spec?
[04:36] <tseng> paxer: last i heard Keybuk 
[04:36] <Diziet> https://launchpad.net/distros/ubuntu/+spec/network-magic
[04:36] <Diziet> That info is supposed to be up to date.
[04:36] <paxer> mhh I would like to help, because the current wifi situation in breezy sucks.
[04:37] <paxer> Diziet, I didn't found any CVS or impementing specific information.
[04:39] <Diziet> You mean, a link to the source, etc. ?
[04:39] <paxer> yes
[04:39] <paxer> something to start up with anything
[04:39] <Diziet> I think you should probably talk to Keybuk since he's the assignee.
[04:40] <Diziet> (If you're serious you should probably subscribe to the network-manager upstream list, too, although it's quite noisy.)
[04:40] <paxer> ok thanks, I have ne experience in the ubuntu development process, so I thought I better ask here, before spaming some harmless persons
[04:44] <paxer> How is the code management handelt in general? is there something like a ubuntu cvs? or has every project an own cvs / subversion solution?
[04:45] <zyga> paxer: ubuntu uses bzr
[04:45] <paxer> have you some URL for me, where I can get an overview?
[04:47] <paxer> I found it myself :)
[04:47] <mdke> bazaar.ubuntu.com 
[04:48] <paxer> thx
[04:50] <mhz> hi
[04:59] <ryanpg> pitti, hi I see you've closed bug 20564 (udev ieee1394 rule permissions) but... it still doesn't work for me
[05:00] <pitti_> ryanpg: even with the latest udev?
[05:00] <ryanpg> yes
[05:00] <pitti_> ryanpg: what are your device permissions now?
[05:01] <ryanpg> one sec
[05:01] <ryanpg> brw-rw---- 1 root disk 8, 3 2005-12-08 09:48 sda3
[05:01] <pitti_> ryanpg: blame Keybuk :)
[05:02] <pitti_> ryanpg: sorry for that, please reopen the bug then
[05:02] <Keybuk> what's the device?
[05:02] <ryanpg> ok
[05:02] <ryanpg> firewire hard drive
[05:02] <pitti_> ah, good test case
[05:02] <Keybuk> you have /sys/block/sda/sda3 ?
[05:03] <ryanpg> yes
[05:04] <Keybuk> ok, can you supply the output of:  udevinfo -a -p /block/sda/sda3
[05:04] <ryanpg> yes I'll add it to the bug
[05:04] <Keybuk> and while you're doing that, I'll put an extra "e" in the rule
[05:04] <thierry_> seb128 : don't wan't to stop you doing important stuff, but could take a fast look at malone bug 5544 ?
[05:05] <pitti_> Keybuk: heh, just saw it
[05:05] <Keybuk> ryanpg: edit /etc/udev/rules.d/40-permissions.rules
[05:06] <Keybuk> change BUS=="iee1394" (near the top) to BUS=="ieee1394"
[05:06] <ryanpg> yeah I'm doing that ;P
[05:06] <Keybuk> then sudo udevplug /sys/block/sda/sda3
[05:06] <Keybuk> and see if the permissions become right
[05:07] <ryanpg> yep
[05:07] <ryanpg> 60640
[05:08] <Keybuk> uh, I mean the group
[05:08] <ryanpg> oh duh sorry... one sec
[05:08] <ryanpg> plugdev
[05:08] <Keybuk> goodo
[05:08] <pitti_> \o] 
[05:08] <pitti_> \o/ even
[05:09] <ryanpg> now do I need to restart hal
[05:09] <pitti_> although the first one could be 'scratching my head' :)
[05:09] <pitti_> ryanpg: shoudn't be necessary
[05:09] <pitti_> ryanpg: just unplug/replug should do
[05:09] <ryanpg> hm... well it's still not working :(
[05:10] <ryanpg> nothing mounted... but I've got a meeting I have to attend
[05:10] <pitti_> ryanpg: can you please do the DebuggingRemovableDevices tour again now?
[05:10] <pitti_> and please do try after a clean reboot, just in case
[05:10] <ryanpg> sure... this afternoon
[05:11] <ryanpg> pmount works btw
[05:11] <rtcm> pitti_: cupsys is using a link in /etc/cups/pdftoos.conf which does not exist (in dapper)
[05:11] <ryanpg> ok I'm off for now
[05:11] <rtcm> pitti_: maybe poppler-utils should include it?
[05:12] <pitti_> rtcm: right, it should
[05:12] <pitti_> rtcm: can you please file a bug against it?
[05:12] <rtcm> sure
[05:17] <mvo> Keybuk: the MoM output for aptitude looks a bit odd, any idea?
[05:19] <Keybuk> define odd
[05:20] <freelove> can i talk to mr. mark shuttleworth here plzzzzzzz?
[05:20] <tseng> not like that
[05:20] <Keybuk> I expect it has something to do with the fact we can't sync/merge from experimental
[05:20] <ogra> freelove, sabdfl isnt around currently :)
[05:20] <Amaranth> sabdfl isn't on IRC regularly, your place bet is email
[05:20] <Amaranth> err, best bet
[05:21] <freelove> his personal email? will he read my email?
[05:21] <ogra> Amaranth, not true he's around quite often :)
[05:21] <Mithrandir> freelove: yes, why shouldn't he?
[05:21] <Amaranth> ogra: But not on any consistent schedule.
[05:21] <ogra> nope
[05:21] <ogra> but several times a week ...
[05:21] <Amaranth> email is easier :)
[05:21] <freelove> whats his email id ogra?
[05:21] <ogra> that might be true 
[05:23] <freelove> there are so few ppl in #kubuntu-devel......
[05:23] <ogra> mark@ubuntu.com i think
[05:23] <mdz> morning
[05:23] <tseng> 'lo mdz 
[05:24] <ogra> morning mdz
[05:25] <freelove> ogra thx
[05:26] <Mithrandir> Keybuk: could I have /etc/udev/rules.d/60-symlinks.rules and /lib/udev/cdrom_id in the initramfs, please?
[05:28] <pitti> Hi mdz 
[05:28] <Keybuk> no
[05:28] <Mithrandir> Keybuk: why not?
[05:28] <Keybuk> neither symlinks or permissions are suitable for the initramfs, because they can't be "undone" by the real filesystem
[05:29] <Mithrandir> they'd be very useful for the live CD.
[05:29] <Keybuk> why?
[05:29] <Keybuk> you shouldn't rely on anything in 60-symlinks anyway, they almost never work
[05:29] <Mithrandir> because then I can just iterate over /dev/cdrom* and try mounting until I found the right CD.
[05:30] <Keybuk> that won't work, because there's no guarantee that there's a /dev/cdrom* for every CD
[05:30] <Keybuk> in fact, it almost always works out that there isn't, and there's just one
[05:30] <Mithrandir> hm
[05:30] <Keybuk> if you need something like that, you'll need to use the ungodly hack the installer uses
[05:30] <Mithrandir> that kinda sucks.
[05:30] <Mithrandir> I was hoping to not use ungodly hacks. :-)
[05:30] <Keybuk> iterating CDs is an ungodly hack ;)
[05:30] <Keybuk> use /dev/disk/by-label or something to pick exactly the right one
[05:30] <Mithrandir> nono, that's nice and pretty.  Almost, at least.
[05:31] <Mithrandir> nocando, we can't predict the label.
[05:31] <Keybuk> you could walk /sys and look for CDs yourself, then look them up in the udevdb to find out what block device they have (if any)
[05:31] <Mithrandir> how do I know if something is a CD?
[05:31] <freelove> will dapper be faster than breezy:) ??
[05:32] <Keybuk> cdrom_id does that
[05:32] <Keybuk> (you can have _that_ in the initramfs, just not the symlinks rules)
[05:32] <tseng> freelove: please address general questions to #ubuntu
[05:32] <Mithrandir> Keybuk: ok, if I could have that, I could live with running it over the whole of /dev
[05:32] <Keybuk> you'll need ide_media too (I think that's there already)
[05:33] <Keybuk> oh, no, ignore me
[05:33] <Keybuk> cdrom_id does work on IDE drives
[05:33] <Mithrandir> cdrom_id will work on SCSI, SATA and IDE drives?
[05:33] <Keybuk> probably
[05:33] <Mithrandir> "probably" is a bit weak. :-/
[05:34] <Keybuk> there are no guarantees
[05:34] <Mithrandir> I don't have a SATA drive, but I could dig out a SCSI drive at least.
[05:34] <Keybuk> it does seem to do the right thing for everything tested so far
[05:34] <Mithrandir> let's hope it continues doing that, then. :-)
[05:34] <Keybuk> that's what it's for
[05:35] <Keybuk> it's the binary to know all about the silly corner cases for every damned driver
[05:36] <Mithrandir> ok
[05:36] <Keybuk> if you're going to write something to find CD drives, could you replace the installer's cdrom-detect while you're at it
[05:36] <Mithrandir> I'm going to do one thing at a time first, I think
[05:37] <Keybuk> something like:
[05:37] <seb128_> thierry_: thanks for the patch
[05:37] <Keybuk> for sysblock in /sys/block/*; do
[05:37] <Keybuk>     devname=$(udevinfo -q name -p ${sysblock#/sys})
[05:38] <Keybuk>     cdrom_id /dev/$devname
[05:38] <Keybuk> done
[05:38] <Keybuk> would iterate all block devices looking for CD drives
[05:38] <Mithrandir> you don't have to chop off /sys, it seems
[05:39] <Mithrandir> and I'd need udevinfo in the initramfs
[05:39] <Mithrandir> sbalneav: yes, I'm Tollef
[05:39] <sbalneav> Hey Mithrandir!
[05:40] <Mithrandir> hiya
[05:40] <Keybuk> Mithrandir: that's also easy to arrange
[05:40] <ogra> sbalneav, scotty !!
[05:40] <Keybuk> you could also do something a little more ungodly if you liked ...
[05:40] <Keybuk> for magic in /dev/.udev/db/block@*; do
[05:40] <sbalneav> I had a quick question about a ubu box I'm setting up and pam_umask.  Probably not acceptible in this channel, can you join me in #pamumask?
[05:40] <sbalneav> Hey ogra!
[05:41] <Keybuk> but ahem, you're not supposed to do that <g>
[05:41] <Mithrandir> sbalneav: sure
[05:41] <Mithrandir> Keybuk: I would prefer not to, please. :-)
[05:41] <Keybuk> anyway, given you're modifying the initramfs yourself to add this code
[05:41] <Keybuk> either copy the udev helpers with your own initramfs hook
[05:41] <Keybuk> or give me the complete finished thing if it's suitable for the real initramfs
[05:42] <Keybuk> and I'll put it in the udev package
[05:42] <Mithrandir> yup, willdo
[05:42] <Keybuk> the reason the /dev/cdrom* isn't suitable is that there's no checking the symlink doesn't already exist
[05:42] <Keybuk> so if you have two cdroms, they might try and both use /dev/cdrom
[05:43] <Keybuk> the %e thing doesn't have a great big lock around it
[05:44] <Mithrandir> ah
[05:44] <Keybuk> for the installer, we do it using an evil shell script that does have a great big lock around the plugging of drives
[05:44] <Keybuk> udevd would probably get the /dev/sda and /dev/sdb events (two CD-ROMs) at the same time, if they come from the same driver
[05:44] <Keybuk> as there's no path conflict they'd be processed at the same time
[05:44] <Keybuk> so they'd both test for the non-existance of /dev/cdrom at the same time
[05:44] <Keybuk> and both make a /dev/cdrom symlink
[05:45] <mdke> Keybuk, my sata drive controller is looking better now, thanks
[05:46] <Keybuk> mdke: your laptop boots?
[05:46] <mdke> yeah
[05:46] <mdke> everything else works too
[05:46] <Keybuk> Mithrandir: upstream have preferred to deprecate %e rather than fix the problem -- and I tend to agree with their logic as predictable names like the /dev/disk tree are better
[05:47] <Keybuk> if you give people /dev/cdrom0 and /dev/cdrom1 they'll bitch that they swap round every other boot
[05:47] <Mithrandir> Keybuk: if I could have /dev/cdroms, I wouldn't mind. :-)
[05:47] <Keybuk> that has the same problem
[05:47] <Keybuk> /dev/cdroms/0 and /dev/cdroms/1 would swap every other boot
[05:48] <Keybuk> whereas /dev/disk/bu-id/ata-HP43CDROM is forever
[05:48] <Keybuk> as is /dev/disk/by-path/ etc.
[05:48] <Mithrandir> have it be /dev/cdroms/ata-HP43CDROM, then
[05:48] <Keybuk> see, now that's an interesting idea
[05:49] <Keybuk> right now /dev/disk doesn't have a by-type
[05:49] <Keybuk> we could add that to the persistent rules
[05:49] <Keybuk> /dev/disk/by-type/cdrom/$ID
[05:49] <Keybuk> /dev/disk/by-type/disk/$ID
[05:49] <Mithrandir> yup, that'd be useful
[05:50] <Mithrandir> you think that's upstreamable as well?
[05:50] <Keybuk> potentially
[05:50] <Keybuk> it could also be considered irrelevant though, as upstream for those rules might just retort "they're all called scd*"
[05:51] <Mithrandir> except my DVD drive is called /dev/hda
[05:51] <Keybuk> it's increasingly likely that in a couple of kernels time, it won't be
[05:51] <Mithrandir> oh?
[05:51] <Keybuk> they're fast moving towards replacing the IDE subsystem with libata
[05:52] <Mithrandir> scd would also be fine, I just want something which is nice to iterate over.
[05:52] <Mithrandir> also, that wouldn
[05:52] <Mithrandir> 't cover the ancient CD subsystems
[05:52] <Mithrandir> pre-IDE
[05:52] <Keybuk> hmm, I don't think they work anyway
[05:52] <Keybuk> we don't bother with them in initramfs
[05:52] <Keybuk> you have to load the driver to find out whether you have one, and the driver often hangs the machine if you don't
[05:53] <freelove> can i speak to dear mr. mark shuttleworth plz??
[05:53] <Mithrandir> freelove: he just left the channel.
[05:53] <Mithrandir> freelove: 17:50 -!- sabdfl [n=mark@ubuntu/member/pdpc.silver.sabdfl]  has left #ubuntu-devel [] 
[05:53] <freelove> nooooooooooooooooooooo! 
[05:53] <freelove> :(
[05:53] <Mithrandir> just send him a mail
[05:53] <Keybuk> mark.shuttleworth@canonical.com
[05:53] <freelove> will he reply?
[05:54] <Mithrandir> if you write something interesting, quite likely.
[05:54] <Keybuk> it depends, he receives a lot of e-mail, so it's worth taking your time over writing it
[05:54] <Mithrandir> if you write "are you mark", maybe not
[05:54] <freelove> ok
[05:54] <Keybuk> but yes, if it's interesting and exciting, I'm sure
[05:54] <Keybuk> "can I have some of your money?" doesn't tend to get replies, unless it's "if I send you into space again, can I have some of your money?" :p
[05:54] <freelove> lol:)
[05:55] <Keybuk> Mithrandir: do you want to support old CD drives then?
[05:55] <Mithrandir> Keybuk: if it's not painful, I don't see a reason not to.  I'm not going to jump through lots of hoops to get them supported, though
[05:56] <Keybuk> aiui, it's very painful
[05:56] <Keybuk> I don't think our current installer supports them?
[05:56] <Mithrandir> I'm not sure.
[05:56] <Keybuk> anything pre-PCI means you have to know you want the driver, and load it by hand
[05:56] <Mithrandir> it's probably easier just to ship anybody who shows up with such a drive a new DVD drive.
[05:56] <Keybuk> we only support them in the real system by people adding them to /etc/modules
[05:56] <Keybuk> heh
[05:56] <Mithrandir> and cheaper
[05:57] <Keybuk> I doubt anyone with such a drive has the computing capacity to run X, let alone anything else
[05:57] <Keybuk> unless my memory is deceiving me, they died with the 386
[05:57] <Mithrandir> they didn't.  You get 486DX2 machines with them, but yes, they're quite old.
[06:05] <Keybuk> ACTION=="add", SUBSYSTEM=="block", KERNEL=="*[!0-9] |sr*", IMPORT{program}="cdrom_id --export $tempnode", ENV{ID_CDROM}=="?*", IMPORT{program}="path_id %p", SYMLINK+="cdroms/$env{ID_PATH}"
[06:05] <Keybuk> Mithrandir: ^ knock yourself out ;)
[06:05] <Mithrandir> nah, I'm using your udevinfo thingy
[06:05] <Mithrandir> seems to work
[06:07] <Keybuk> yeah, the nice thing about the new world order is that this kind of thing is actually rather simple
[06:11] <mdz> seb128: does xchat-gnome  have a shortcut for next/previous channel, like ctrl+pgup/pgdn did in xchat?
[06:13] <seb128> mdz: alt-up/down
[06:13] <ogra> argh... my usb writer cant write dvds anymore
[06:13] <Keybuk> ogra: somebody else was having problems with that
[06:13] <Keybuk> why can't it write dvds?
[06:13] <crimsun> I can't even get my usb cdrw to do anything useful.
[06:14] <ogra> cdrecord: Unspecified command not implemented for this drive.
[06:14] <ogra> cdrecord: Cannot get next writable address.
[06:15] <ogra> i get this for blanking RW as well
[06:15] <ogra> sg is loaded and i can access the drive for reading just fine
[06:16] <mdz> seb128: hmm, doesn't work for me (acts like up/down)
[06:16] <mdz> would my gtk-key-theme-name affect it?
[06:17] <Keybuk> are the permissions right?  (ie. does it work if you're root)
[06:17] <ogra> nope, tried already
[06:18] <Keybuk> could be a new kernel bug then
[06:22] <dholbach> mdz: i revamped the testplan pages, they're now at http://wiki.ubuntu.com/Testing
[06:22] <dholbach> mdz: the installation matrix is at http://wiki.ubuntu.com/Testing/Current - do you think i should do additional pages for Kubuntu and Edubuntu to test their instlalation methods?
[06:23] <seb128> mdz: hum, maybe. Let me try with Emacs mode
[06:23] <dholbach> (i will change bits in the individual items on the the short and long test plans though, especially the media related tasks)
[06:24] <Riddell> dholbach: yes please
[06:24] <dholbach> Riddell: the test plans themselves are generic, so it says "Your mail app", i'll add CurrentKubuntu, ok?
[06:24] <Riddell> ok
[06:25] <dholbach> ogra: same for edubuntu?
[06:25] <ogra> the install is different, i'll look after dinner
[06:25] <mdz> dholbach: yes
[06:25] <dholbach> ogra: oh ok
[06:25] <mdz> dholbach: "does the resolution match?" in the short test is a bit vague
[06:26] <ogra> dholbach, but generally, yes
[06:26] <dholbach> mdz: i'll review the individual items and make changes to them now (some bits are from the BOF session at UBZ)
[06:29] <mdz> Keybuk: the T42 is booting, with DMA, in 1:05
[06:29] <mjg59> mdz: Is suspend still broken for you?
[06:30] <mdz> mjg59: will test now
[06:30] <mdz> mjg59: goes down quickly but refuses to wake up
[06:30] <ogra> mine doesnt go down ... 
[06:31] <mdz> no response to any keys or power button, moon light stays on
[06:31] <mdz> this is with 2.6.15-7
[06:31] <mjg59> mdz: Ok, fair enough
[06:31] <mjg59> I'll try to debug
[06:33] <mjg59> It works fine here using ata_piix, so I think it's probably something in the IDE suspend support
[06:33] <mdz> 0000:00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01)
[06:34] <mjg59> mdz: Can you do kernel builds there?
[06:34] <mdz> mjg59: I can, but they take a while
[06:38] <mjg59> mdz: Can you disable USE_DPMS in /etc/default/acpi-support and see if it gives you anything useful looking?
[06:39] <mdz> mjg59: some text flashes by too quickly to read, then a blinking cursor, then blank and the same state of death
[06:40] <mjg59> Right. What fun.
[06:40] <mjg59> mdz: What was the last previous version to work?
[06:40] <mdz> mjg59: breezy
[06:40] <mdz> last known to work
[06:41] <mdz> hibernate at least was working with dapper + the breezy kernel
[06:42] <mjg59> mdz: Do we still have older 2.6.15 packages?
[06:42] <mjg59> Oh, yes, of course - it was generally broken for ages. Hrm.
[06:42] <Riddell> infinity: please give back kdebluetooth
[06:43] <mjg59> Grah. Any chance you can get a git checkout from a while back and change the config to enable HOTPLUG_CPU?
[06:43] <mdz> I've never used git, but can follow instructions
[06:43] <mjg59> Then if that works, git bisect it to the patch that breaks it
[06:44] <mjg59> Basically, get git, then do git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git
[06:45] <mjg59> Then you need to check out an older version
[06:45] <zyga> ogra: back to hwdb-client
[06:45] <mdz> guh
[06:45] <mdz> git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git  -> git: fatal error: `chdir' failed: permission denied.
[06:46] <ogra> Keybuk, hmm, i get the same error with my internal IDE DVD writer ...
[06:46] <ogra> zyga, yup
[06:46] <mjg59> Delete everything in debian/config/x86 except i386 and generic, then edit that to enable CPU_HOTPLUG and do a dpkg-buildpackage
[06:46] <infinity> Riddell : Mail those requests if I'm not obviously around (I was idle for several hours)... The fact that I'm restless and awake at 4:45am is a fluke. :)
[06:46] <seb128> mdz: alt-up/down works fine for me with xchat-gnome/emacs keybindings, that's weird
[06:46] <mjg59> mdz: Ah, sorry - there should be a " ubuntu-2.6" on the end of that
[06:46] <mdz> git: warning: invalid extra options ignored
[06:46] <mdz> strace says it is trying to chdir to 'clone'
[06:47] <mjg59> git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git ubuntu-2.6 seems to work for me
[06:47] <mdz> what version of git?
[06:47] <mdz> ii  git            4.3.20-7build1 GNU Interactive Tools, a file browser/viewer
[06:47] <mjg59> That's entirely the wrong git
[06:47] <mdz>  haha
[06:47] <mdz> of course it is
[06:47] <infinity> Riddell : Also...
[06:47] <infinity> make[2] : Entering directory `/build/buildd/kdebluetooth-0.99+1.0beta1'
[06:47] <infinity> ./admin/cvs.sh: line 13: autoconf: command not found
[06:47] <mjg59> Anyway, I have to get some food
[06:48] <mdz> what do we call the right git?
[06:48] <mjg59> I have git-core, ubt I'm not sure where it came from
[06:48] <Riddell> blurg
[06:48] <mjg59> kernel.org has debs, I think
[06:48] <ogra> mdz, shouldnt BenC know ? ;)
[06:49] <infinity> https://wiki.ubuntu.com/KernelGitGuide claims that "git-core" is in dapper.
[06:49] <mdz> ok, git-core works much better
[06:49] <mdz> infinity: it is
[07:02] <zyga> ogra: I've started with hwdb-send, can I modify it to use python stuff instead of external commands?
[07:04] <ogra> zyga, i rather wanted to integrate it in the main client
[07:04] <ogra> what wouls you like to change ? 
[07:04] <ogra> *would
[07:05] <zyga> ogra: cleanup glade mess, cleanup md5 digest
[07:05] <zyga> I'm not sure why you copy stuff around so I'll leave that part intact
[07:06] <ogra> thats if the server can be pinged ... so the file gets moved to the Desktop, asking the user to mail it to hwdb@ubuntu.com
[07:06] <ogra> *cant
[07:07] <zyga> ogra: neet :-)
[07:07] <zyga> ogra: ok, so should I leave that alone? glade is really messy overe there
[07:07] <ogra> is there an alternative included in python to generate md5sums and rename files accordingly ? i'm not aware of any internal methods
[07:08] <zyga> ogra: md5 is easy I'm not sure about file moving but I didn't look yet
[07:08] <ogra> the bzip2 part could be lolved internally ...
[07:08] <ogra> solved
[07:08] <ogra> the important pat is that the filename is the md5sum in the end, thats an essential piece of hwdb
[07:09] <lamont> slomo: btw, debian's mod-mono says 'Architecture: i386'
[07:09] <zyga> ogra: that's easy
[07:09] <ogra> if you have a way to solve that in plain python i'm fine with it
[07:09] <zyga> ogra: does rename fail on fs boundary?
[07:10] <ogra> fs boundary ? 
[07:10] <slomo> lamont: yes, for whatever reason... i talked with one of the maintainers and he said he will change it to arch any for the next upload
[07:10] <ogra> zyga, you mean if /tmp doesnt exist ? 
[07:10] <zyga> filesystem boundary, say /tmp is on partition foo and $HOME/Desktop is on bar
[07:11] <zyga> (so that rename is non trivial and needs to copy the data)
[07:11] <ogra> oh, nope, that cant happen 
[07:11] <slomo> lamont: must've been in the old days where mono was only available for i386
[07:11] <lamont> yeah
[07:11] <zyga> so os.rename can be used instead of os.system('mv %s %s')
[07:11] <ogra> zyga, mv works over partitions without probs
[07:11] <slomo> doko: ping?
[07:11] <tseng> slomo: lamont still has nightmares about mono 1.0
[07:11] <zyga> ogra: mv does, but does os.rename? :)
[07:11] <ogra> zyga, i guess so
[07:11] <zyga> k, I'll test
[07:12] <ogra> hmm, i'd think so
[07:12] <zyga> ah
[07:12] <zyga> OSError: [Errno 18]  Invalid cross-device link
[07:12] <zyga> not good
[07:12] <tseng> has to be a hardlink i think
[07:13] <zyga> tseng: ?
[07:13] <zyga> tseng: it's a regular file, touched for this test
[07:14] <ogra> sadly there is no os.move ...
[07:16] <theCore> Diziet, what are the packaging procedures in Ubuntu ? i'm currently working on the PackagingGuide and I would like to make a chapter on this for new maintainers 
[07:16] <zyga> ogra: you don't test for any failure
[07:16] <zyga> ogra: we could write an os.move equivalent easily
[07:16] <ogra> do it if you like :) 
[07:17] <zyga> k
[07:17] <zyga> I'll ping you when it's done, if it doesn't match the direction where the code is going bash me :)
[07:17] <ogra> zyga, for which failure should i test ? 
[07:18] <ogra> if hdwb-send is called i have the guarantee that the file exists ... if /tmp doesnt exist on your system, the system is broken anyway
[07:18] <zyga> ogra: mv can fail
[07:18] <ogra> the only failure that can happen is that the server isnt reachable ...
[07:19] <zyga> ogra: not enough free space 
[07:19] <zyga> ok
[07:19] <zyga> later :)
[07:19] <ogra> hmm... mv ... its a 200k file ...
[07:19] <zyga> ogra: theory :)
[07:19] <zyga> bbl
[07:19] <ogra> sure there could be space issues, but then it would break earlier already
[07:29] <ryanpg> pitti, hia back for a few... I did the removable media routine again... is it kosher to attach a .tar.gz to the bug or should I just attach all the logs individually
[07:33] <ryanpg> somehow I suspect this line from dbus will be meaning ful "12:26:54.764 [I]  blockdev.c:602: Ignoring hotplug event - no parent
[07:33] <ryanpg> "
[07:36] <dholbach> elmo_: please sync libglademm2.4 from sid, ok to override
[07:39] <doko> slomo: pong
[07:41] <slomo> doko: you asked xine-lib to be updated to 1.1 in #19356... did you already take a look at 1.1 (i.e. if it's ABI compatible, etc)? and it's a development version judging from their homepage... 1.0 is stable
[07:43] <doko> slomo: 1.0.x is not ready for g++-4.0, 1.1.x is.
[07:44] <slomo> doko: ok, that's a good argument to update ;) i'll take a look at it then, thanks
[07:44] <doko> slomo: thanks!
[07:45] <doko> ahh, 1.1.1 is current ...
[07:51] <slomo> doko: judging from their release notes it should be safe to upgrade to 1.1.1... i'll test it locally later
[07:53] <Amaranth> the X mouse fix was to modprobe psmouse, right?
[07:54] <slomo> doko: but our current version is patched to work with gcc4 too
[07:54] <doko> allowing playback on x86_64 systems (previously QDM2 was only
[07:54] <doko> possible using win32 codecs).  ... from the release notes ...
[07:55] <dholbach> slomo: the less delta the better - we had bug reports, which indicated, that upstreams version was good, ours wasn't :)
[07:55] <LaserJock> whois Diziet
[07:56] <dholbach> LaserJock: the person with the nick name "Diziet", maybe?
[07:56] <ogra> lol
[07:56] <LaserJock> dholbach: sorry forgot the / :-)
[07:56] <dholbach> no need to be sorry :)
[07:56] <Diziet> laserjock: How may I help you ? :-)
[07:56] <LaserJock> trying to get the hang of irssi
[07:56] <slomo> dholbach: i have to introduce a big delta anyway... need to split of patent encumbered stuff into a another source package to not have this stuff in main ;)
[07:57] <LaserJock> Diziet: I am working on the Ubuntu Packaging Guide
[07:57] <dholbach> slomo: oh, i see
[07:57] <Diziet> Ahh.
[07:57] <LaserJock> Diziet: and I wanted to check in with you about the Ubuntu Developer's Reference
[07:58] <Diziet> Ah.  Well, I haven't really started that yet.
[07:58] <slomo> well, i'll go for 1.1 then...
[07:58] <LaserJock> Diziet: well, we are still in the organizing stage too 
[07:58] <ssam> i am getting messages "OIL: ERROR liboiltest.c 266: oil_test_check_impl(): illegal instruction in fbCompositeSolid_nx8888mmx" in amongst the output when i run apt-get in dapper. any ideas what it is?
[07:59] <LaserJock> Diziet: I have an outline at https://wiki.ubuntu.com/UbuntuPackagingGuide/Outline
[07:59] <LaserJock> Diziet: but I am wondering how much packaging you are going to cover in the UDR
[08:01] <LaserJock> Diziet: I been thinking of the two as, the UDR covers the policy and the Packaging Guide is a tutorial
[08:04] <Diziet> I was going to try to keep it light on detailed information about packaging.  Did you read the wiki page DeveloperDocumentation ?
[08:04] <LaserJock> Diziet: yes, that is why I wanted to talk to you
[08:04] <Diziet> I think the right distinction between the UDR and your Packaging Guide is reference vs. tutorial.  Do you agree ?
[08:05] <LaserJock> Diziet: I guess, although that is a bit finer distinction
[08:06] <Diziet> On the contrary, I think it's a very good distinction.  It changes the structure of the document completely.
[08:08] <LaserJock> Diziet: yes, but it might be somewhat confusing to have a packaging reference and packaging tutorial in two different places. I will have to think about it.
[08:08] <Diziet> Tutorials are allowed to leave stuff out, and also to have a much clearer preference on things where there are several permissible answers.
[08:08] <LaserJock> Diziet: true
[08:09] <Diziet> And of course the material is organised by taxonomy rather than functionally.
[08:09] <LaserJock> Diziet: ok, we will try to keep that in mind and if we need to shift material that shouldn't be a problem
[08:09] <Diziet> shift material> Quite so.
[08:10] <LaserJock> the should be complimentary docs in any case
[08:10] <LaserJock> s/the/they/
[08:14] <LaserJock> Diziet: How will the UDR be developed, bzr?
[08:29] <ryanpg> hey pitti have you been away? I ran the removable debugging gamut again is it ok to attach a tar.gz with the logs to the bug?
[08:38] <pitti_> ryanpg: that's fine, thanks
[08:43] <infinity> ARGH.
[08:43] <infinity> siretart : Around?
[08:44] <infinity> siretart : 'mplayer-586' depends 'mplayer' depends 'mplayer-skins' conflicts 'mplayer-586'.  Spot the problem.
[08:44] <siretart> infinity: err, what did I break?
[08:44] <infinity> siretart : I assume you only wanted "Replaces", not "Replaces/Conflicts"
[08:45] <siretart> infinity: ah, damn, my bad
[08:45] <siretart> sorry, will reupload in a sec
[08:46] <siretart> infinity: if mplayer-skins just replaces (without conflicting) will the old mplayer packages be removed?
[08:47] <infinity> No, and you don't want them to be.  You need mplayer-586 to be installible to get people to upgrade to mplayer.
[08:47] <infinity> I fixed this same bug in mplayer itself earlier today.
[08:48] <siretart> right
[08:48] <slomo> infinity: thanks for that btw :)
[08:48] <infinity> "Replaces" is for files moving between packages.  "Conflicts" is when two packages CURRENTLY have the same file (and it's not moving anywhere)
[08:49] <infinity> Replaces/Conflicts together is to work around an old dpkg bug that is long fixed.  Never use that combination unless you're positive it's what you want.
[08:49] <siretart> ok. uploaded
[08:50] <Amaranth> oh, Replaces/Conflicts together isn't needed anymore?
[08:50] <Amaranth> i just copied mozilla-firefox/firefox
[08:50] <infinity> Amaranth : The bug was fixed ages ago, and the fixed dpkg is in (at least) sarge, hoary, and breezy... Maybe warty too.
[08:50] <infinity> So, yeah.  Don't do it anymore. :)
[08:51] <siretart> aaaah. this explains
[08:52] <infinity> (Now, if you really want the other package completely removed, you can use the combination, but don't use it for arbitrary file overwriting)
[08:52] <infinity> In the case of mplayer-586, the world blows up when you try.
[08:53] <Amaranth> oh, i wanted the other package completely removed
[08:53] <infinity> (cause upgrades won't work)
[08:53] <infinity> Amaranth : Then you're probably okay doing it your way.  So long as you make sure you didn't create a hideously broken upgrade loop.  (which happens a lot with Conflicts/Replaces)
[08:54] <infinity> Oh, this is laghable.  I still haven't slept, and I supposedly start work in 3 hours.  Go me.
[08:55] <infinity> laughable, too.
[08:57] <dholbach> infinity: please go to bed and sleep whatever time you need :)
[08:59] <jdong> (kick him for 3 hours)
[09:02] <Diziet> No, Replaces/Conflicts isn't obsolete.  But I don't have time to explain right now :-).
[09:03] <Diziet> But A -Replaces-> B -Replaces-> A is always wrong (with intervening packages too), regardless of any Conflicts.
[09:04] <infinity> Diziet : The primary reason it was frequently used (working around the fact that dpkg didn't pay attention to Replaces when installed a "replaced" package) is obsolete.
[09:05] <infinity> Diziet : The other reason (completely whacking package B) is still valid, of course, but that's not why it was most frequently used.
[09:06] <infinity> Diziet : As for circular Replaces, that should be fine with versioned replaces... It would blow up miserably with unversioned replaces, obviously.
[09:08] <infinity> Which reminds me.
[09:09] <infinity> siretart / slomo : You're much less likely to make dpkg unhappy in the future (should you, say, have to move files around again, split the packages again, god knows what) if you make those Replaces correctly versioned, instead of unversioned... (ie: mplayer Replaces: mplayer-586 (<< $firstDummyVersion))
[09:10] <siretart> infinity: thanks. will remember that
[09:10] <slomo> infinity: ok, thanks... will keep that in mind :) but the package layout for mplayer will stay as it is now
[09:12] <feugan3333> Hi all. After installing the nvidia-glx package xmms is segmentation faulting. I don't see a bug report for this. Anyone know about it?
[09:15] <feugan3333> Does xmms make use of opengl?
[09:16] <slomo> feugan3333: for visualization plugins, yes... but this is not a support channel... better ask in #ubuntu or on the mailinglist
[09:17] <feugan3333> slomo: I'm really trying to find out if I should report a bug, if so how?
[09:18] <crimsun> feugan3333: general troubleshooting occurs in #ubuntu
[09:18] <Flare> feugan3333 ==> http://bugzilla.ubuntu.com/
[09:18] <feugan3333> ok thanks
[09:19] <Flare> Next time read the topic please.
[09:20] <feugan3333> Flare: I though developers would like to know about a program that seg faults on startup. Not much support can be given.
[09:24] <psusi> shouldn't local X apps be connecting to the X server using the unix domain socket and not tcp/ip?
[09:28] <Mithrandir> they should
[09:28] <Mithrandir> especially given that the X server doesn't listen on TCP
[09:31] <psusi> of course it does
[09:31] <psusi> it listens on port 6000 + display_num
[09:31] <psusi> and it seems most apps are using TCP to connect to the server instead of the unix domain socket
[09:32] <psusi> under ubuntu
[09:32] <HrdwrBoB> erm
[09:32] <HrdwrBoB> by default it doesn't listen on TCP at all
[09:32] <psusi> lsof a gnome-terminal
[09:32] <HrdwrBoB> you have to specifically remove -notcp from the config
[09:32] <psusi> well... yea... it does... netstat -a -n
[09:33] <psusi> wait...
[09:33] <psusi> maybe the local one isn't... on this machine
[09:34] <HrdwrBoB> I'm not making this up, the default is notcp
[09:34] <psusi> ok... yea... the local server isn't listening... the tightvnc server is... and apps are using TCP to talk ot it instead of the unix domain socket... also I noticed on my home machine that apps will TRY to use tcp and take forever to time out and fall back to the unix domain socket
[09:34] <psusi> if you don't configure your lo interface
[09:34] <HrdwrBoB> yes
[09:34] <psusi> shouldn't they be trying the unix domain socket first?  not tcp?
[09:35] <HrdwrBoB> lo sometimes fails on wake up from sleep on my laptop, with no lo, things go terribly broken
[09:35] <HrdwrBoB> possibly, if you see that they are and shouldn't be, submit a bug
[09:36] <psusi> well yea... they are... which is why things break down when you don't have a loopback
[09:36] <psusi> hrm...
[09:56] <slomo> doko: fyi, xine-lib 1.1.1 works fine with at least totem-xine and gxine and judging from soname it should be completly compatible... i'll do some further tests and upload it then... splitting it will come later this weekend
[09:58] <seb128> slomo: rock
[09:59] <slomo> seb128: do you want to take a look at my current work? (i.e. merge and update to 1.1.1)
[10:01] <seb128> slomo: why not, are the sources somewhere online atm? 
[10:02] <slomo> not yet, i'll upload them now to my server
[10:02] <seb128> k, thansk
[10:05] <\sh> damn...I just fucking resigned 
[10:05] <spacey_ki> why
[10:06] <tseng> \sh: eh?
[10:06] <\sh> spacey_ki: because my indirect boss is a fucking social asshole..thats why
[10:06] <\sh> tseng: not eh..the truth the real the reality
[10:08] <greenpenguin13> wahey that round of updates fixed all my problems :)
[10:13] <slomo> seb128: get it from here http://slomosnail.de/~slomo/temp/
[10:15] <Riddell> elmo_: please sync libgii from debian, overwriting ubuntu changes
[10:18] <slomo> seb128: btw, i've written wavpack main inclusion report today... maybe it's ready when debian added wavpack support to gst-plugins
[10:21] <seb128> slomo: cool, download xine-lib atm
[10:21] <hunger_> BenC: My system boots again with the newest udev. It was broken inbetween for a while. Bluetooth is working again, too.
[10:24] <psusi> same here... except for bluetooth... I have no bluetooth
[10:25] <hunger_> Even my CDROM works again (have not yet tested burning something with it though).
[10:26] <hunger> Even pcmcia cards are detected! This is getting really nice!
[10:28] <hunger> Thanks for all the great work on udev and the new kernel! Keep it up, please.
[10:28] <Kamion> hunger: pcmcia> hooray
[10:28] <BenC> hunger: cool
[10:28] <Kamion> (16-bit PCMCIA, or CardBus?)
[10:29] <hunger> Kamion: it is a 16bit card... in a cardbus-capable slot.
[10:30] <Kamion> rock on
[10:30] <Kamion> those are the hard ones
[10:30] <hunger> Kamion: Just grabbed the old wlan card from my wife's laptop...
[10:30] <slomo> seb128: if you're fine with it i'll send it up later... btw, it works on one video file (h264) where mplayer only shows a distorted picture ;)
[10:30] <seb128> slomo: it's still building, not quick to build
[10:31] <slomo> seb128: no... but way faster than mplayer ;)
[10:35] <greenpenguin13> hmm
[10:36] <greenpenguin13> i cant start x with the latest two kernels
[10:36] <greenpenguin13> something to do with nvidia-glx
[10:36] <mvo> what are the magic words to see more than 10 translations in rosetta?
[10:38] <mpt> there are none, mvo
[10:38] <mpt> sorry
[10:38] <mpt> (and try #launchpad for Launchpad questions)
[10:39] <mvo> mpt: oh :( and searching is not possible as well
[10:40] <mpt> not yet, no
[10:40] <mpt> though that's high on the list of unimplemented features
[10:44] <zyga> mvo: there is a translators whishlist somewhere on the wiki
[10:45] <seb128> slomo: xine, DOH
[10:45] <slomo> seb128?
[10:46] <seb128> slomo: totem-xine works way better than totem-gstreamer :/
[10:46] <crimsun> always has in my experience
[10:46] <seb128> slomo: 1.1.1 works great, no ABI breakage, I've diffed the symbols exported
[10:47] <seb128> crimsun: yeah, but I tend to have the -gstreamer variant installed to debug it :)
[10:47] <slomo> seb128: yes, let's work together to get totem-gstreamer working at least as good as xine :)
[10:48] <seb128> I hope gst0.10 will works better
[10:48] <slomo> it must ;)
[10:48] <seb128> slomo:I'll probably upload a gstreamer0.10 ready to upload tomorrow
[10:48] <seb128> just change the unversionned stuff hover the current online one
[10:48] <seb128> s/change/changing/
[10:48] <seb128> s/hover/over/
[10:49] <seb128> slomo: have you looked at this one? (not speaking about gst-plugins-base0.10 which needs some work)
[10:49] <slomo> yes, i only looked at gst itself... plugins was only a quick look over
[10:50] <slomo> if you change the unversioned stuff it seems to be fine for me... even compiles in pbuilder etc ;)
[10:52] <slomo> seb128: lool was ok with your decision about the tools?
[10:54] <Amaranth> seb128: xchat-gnome is awesome
[10:54] <Amaranth> although i don't enjoy the things i had to do to get it on breezy
[10:55] <fabbione> guys, who has been playing with mplayer recently?
[10:55] <dholbach> fabbione: if you're going to give a lecture, you're a bit late :)
[10:55] <fabbione> dholbach: no
[10:55] <fabbione> there is a regression i would like fixed :)
[10:55] <dholbach> ah ok, because infinity did an hour ago
[10:56] <fabbione> nothing about packaging
[10:56] <fabbione> it's how they build it
[10:56] <fabbione> (i think)
[10:56] <slomo> Amaranth: is the trayicon of x-g finally working?
[10:56] <dholbach> slomo and siretart are motumedia :)
[10:56] <fabbione> slomo, siretart: ping?
[10:56] <fabbione> Requested video codec family [wmv9dmo]  (vfm=dmo) not available.
[10:56] <fabbione> Enable it at compilation.
[10:56] <fabbione> Requested video codec family [wmvdmo]  (vfm=dmo) not available.
[10:56] <fabbione> Enable it at compilation.
[10:56] <slomo> fabbione: i've done that package, yes
[10:56] <fabbione> that's playing .wmv 
[10:57] <fabbione> no video
[10:57] <seb128> slomo: yep, lool is ok
[10:57] <seb128> Amaranth: rock :)
[10:57] <crimsun> err, can anything actually play wmv9 video?
[10:57] <fabbione> slomo: can you please check all the configure log and see what did you or siretart miss?
[10:57] <fabbione> crimsun: yes. it was working with the version of mplayer i had in breezy
[10:57] <dholbach> and crimsun is motu media too
[10:57] <slomo> fabbione: yes, i'll put it on my todo list for tomorrow
[10:57] <fabbione> crimsun: + codecs
[10:57] <fabbione> slomo: ok thanks
[10:57] <crimsun> fabbione: k
[10:58] <Amaranth> slomo: dunno, probably not here
[10:58] <slomo> fabbione: can you give me a testfile?
[10:58] <fabbione> crimsun: these porn^Wfiles are at least 2/3 years old
[10:58] <fabbione> ;)
[10:58] <crimsun> I know it absolutely won't work with vlc because it's in universe, but mplayer should have no prob then since it's in multiverse
[10:58] <fabbione> slomo: grab any from the net..
[10:58] <Amaranth> fabbione: w32codecs?
[10:58] <slomo> fabbione: well, i could play various wmv files ;)
[10:58] <fabbione> slomo: the all fail 
[10:58] <fabbione> slomo: this is amd64
[10:58] <slomo> fabbione: are you on x86 or amd64?
[10:59] <fabbione> Amaranth: yes
[10:59] <slomo> fabbione: w32codecs or only native stuff?
[10:59] <dholbach> crimsun: i was quite pleased with vlc, when i tested it
[10:59] <fabbione> slomo: w32codecs
[10:59] <Amaranth> wmv9 without w32codecs is unpossible at the moment
[10:59] <crimsun> elmo_: please sync libsdl-sound1.2 from Sid (ok to override Ubuntu changes), thanks
[10:59] <dholbach> crimsun: i mean it didn't explode every five minutes :)
[10:59] <slomo> fabbione: isn't enabled for amd64 because we didn't know if it works... thanks for reporting :) i'll enable it now
[10:59] <crimsun> ah, w32codecs.
[11:00] <fabbione> cluebat even ;)
[11:00] <crimsun> I was about to say that I didn't know of a *nix lib to handle it
[11:00] <seb128> what an idea to use mplayer
[11:00] <dholbach> slomo: don't worry, i received the same treatment from fabbione once, it's "coming of age" in ubuntu land :)
[11:00] <Amaranth> *poof*
[11:01] <fabbione> dholbach: ehehe
[11:02] <slomo> fabbione: anything else you want to see fixed? :)
[11:02] <dholbach> slomo: evolution next, please
[11:02] <dholbach> slomo: oh wait... and gamin :)
[11:02] <fabbione> slomo: yes.. ATI driver for r300 on ppc. kthxbye
[11:02] <slomo> bah, i mean in mplayer ;)
[11:02] <fabbione> ah also world peace
[11:03] <slomo> but i want the other 3 fixed too :P who can do it? ;)
[11:03] <fabbione> slomo: it would also be nice if you could fix my tax return statement...
[11:03] <lifeless> fabbione: I think thats illegal
[11:03] <lifeless> 'fixing' it I mean ;)
[11:03] <fabbione> ahah
[11:04] <lifeless> but perhaps your consiglieuri could help ;)
[11:04] <dholbach> seb128: fabbione must be french, he said "ahah" :)
[11:04] <seb128> ;)
[11:04] <slomo> fabbione: mplayer uploaded ;) tell me if it works later :)
[11:05] <fabbione> slomo: ok thanks
[11:05] <fabbione> slomo: i will let you know tomorrow.. i am almost on the way to sleep
[11:06] <slomo> fabbione: ok, then tomorrow :) i plan to go to bed now too
[11:10] <Riddell> elmo_: please sync libgii and ekg from debian, overwriting ubuntu changes
[11:12] <mdke> Riddell, yo
[11:13] <mdke> Riddell, i was trying to put that svn:externals property back the other day, but totally failed. Would you do it for me?
[11:14] <Riddell> mdke: ok
[11:14] <Riddell> it's not very well explained
[11:15] <Riddell> mdke: are any of the other docs in generic going to be used?
[11:15] <mdke> Riddell, erm: the active docs in there are the serverguide and packaging guide. I've been building the latter with ubuntu stylesheets for the website, thoughts on shipping with kubuntu?
[11:16] <jbailey> Anyone know if Launchpad has something like the Debian watch file support to get notified of new versions when they come out?
[11:16] <lifeless> products, upstream imports, productseries
[11:17] <lifeless> jbailey: IOW the hooks are there but notification is a bit of a loose term
[11:17] <jbailey> lifeless: Intentionally so. =)
[11:17] <Riddell> mdke: if it's shipped with ubuntu, we want it for kubuntu too :)
[11:17] <jbailey> lifeless: I'd be happiest with an rss feed that I could hook onto so that I had a work list. =)
[11:17] <jbailey> lifeless: Second place is a web page that I have to remember to check, and failing that, an email.
[11:17] <lifeless> jbailey: do up a use case. Probably on launchpadpersonalsubscriptions
[11:17] <mdke> Riddell, the decision kinda hasn't been made yet about whether it is a useful doc for shipping in the distro, but right now, it's in there, so you can add it too if you like
[11:20] <jbailey> lifeless: Thanks.  Use case #3 of https://wiki.launchpad.canonical.com/ProductSubscriptions seems to cover it.
[11:20] <jbailey> Well, not the email part, but everything else in there is RSS.
[11:20] <jbailey> Mmm, actually #4 covers it almost better.
[11:20] <lifeless> so, add a note saying 'mee too' ;)
[11:21] <lifeless> noone knows *who* those cases satisfy unless you say os
[11:21] <shawarma> Who is the mastermind behind the suspend/resume functionality in Breezy? I've got a quick question..
[11:21] <slomo> seb128: i'll take a closer look at base plugins tomorrow then after you've uploaded gst itself :) and i could take a look at the 0.10 ffmpeg plugin later... should be a fairly easy one
[11:21] <lifeless> shawarma: mjg59 
[11:21] <shawarma> lifeless: Thanks.
[11:21] <jbailey> lifeless: What sort of form shouldI use for that?
[11:21] <lifeless> jbailey: under the use case: -- JeffBailey Hey this rocks, I'd love that.
[11:22] <seb128> slomo: don't bother on gst0.10, it's trivial
[11:23] <seb128> slomo: just a standard update, no split, or anything like that for it
[11:23] <seb128> jbailey: how know what would be nice? multibuild with cdbs ... what's going on with cdbs2? :)
[11:24] <jbailey> seb128: cdbs2 is dead.  Long live cdbs3.
[11:24] <seb128> ?
[11:24] <slomo> seb128: oh ok, then let's get base plugins in and and worry about the bad/ugly/ffmpeg then :) but for good i think i'll prepare a splitting proposal at the weekend
[11:25] <seb128> dead before beeing born, wth?
[11:25] <jbailey> seb128: Not at all.   I demoed it to a number of people in Sydney.  Didn't you see it?
[11:25] <seb128> slomo: k, I'll have gstreamer0.10 sorted by tomorrow, then we can discussed -base and move on others stuff
[11:25] <seb128> jbailey: no!
[11:26] <dholbach> jbailey: demo! demo! demo! :)
[11:26] <seb128> k, so what cdbs3 is? :)
[11:26] <jbailey> seb128: Anyhow, I got too busy to finish it, and the others I showed it to all ran in fear.
[11:26] <Mithrandir> jbailey: just like scott "demoed" hct more than a year ago? ;-)
[11:26] <jbailey> The wimps couldn't handle posix shell.
[11:26] <Mithrandir> jbailey: OO posix shell, I assume?
[11:27] <jbailey> Mithrandir: In a similar vein, yes.  As in it worked for my contrived test cases, but needed lots of love before first upload.
[11:27] <slomo> jbailey: you wanted to ping ivoks and me about cdbs some time in the future ;)
[11:27] <jbailey> Mithrandir: Yes!  Implementing associative arrays in pure posix shell was brutal, BUT I OVERCAME IT! MWAHAHAHAH
[11:27] <seb128> jbailey: anyway, any cdbsN with multibuild would be welcome
[11:28] <Mithrandir> jbailey: You. Are. Insane.
[11:28] <Mithrandir> :-)
[11:28] <slomo> gn8 Mithrandir :)
[11:29] <Mithrandir> it can't be that bad, can it?
[11:30] <jbailey> Mithrandir: True, but my insanity makes me cute. =)
[11:30] <jbailey> Good sleeps, Tollef.
[11:32] <dholbach> good night everybody
[11:33] <jbailey> G'n Daniel. =)
[11:33] <jbailey> seb128: cdbs3, as proposed by dilinger, is more automake-style.
[11:34] <jbailey> seb128: So the idea is to generate at package generation time a very clean rules file so that it's easy to tell what's going on.
[11:34] <seb128> (hate hate hate autocrap)
[11:35] <seb128> hum
[11:35] <seb128> that would be nice but not that useful if cdbs works correctly :)
[11:36] <azeem> jbailey: this will also frequently change the .diff when cdbs changes, right?
[11:37] <jbailey> azeem: Ideally, no.
[11:37] <jbailey> azeem: The idea is that unlike the output from Automake, there's not alot of portability consideration that needs to be taken.
[11:38] <jbailey> azeem: There's usually one correct minimal rules file.
[11:39] <azeem> but packaging procedures tend to change over time, which has been abstracted by CDBS so far and will now reflect in different rules files
[11:39] <jbailey> azeem: Right.  One of the critisisms of tools like debhelper and cdbs is that it's hard to keep them deterministic.
[11:39] <lifeless> but I like debhelper
[11:40] <lifeless> jbailey: is cdbs3 in python ?
[11:40] <jbailey> lifeless: And cdbs will continue to use debhelper.  It's the best tool for the job.
[11:40] <marian> hello
[11:40] <jdub> jbailey: y'know what we need - a little rules language for making it really easy to package binaries
[11:40] <jbailey> lifeless: I think that's what we settled on, yes.
[11:40] <lifeless> sweet
[11:40] <lifeless> you might sway me yet
[11:40] <lifeless> I like things I can unfuck without writing perl
[11:41] <lifeless> or shell
[11:41] <Kamion> jbailey: generate rules file> argh, sounds like yada
[11:41] <jbailey> jdub: Unforutnately, upstream packages aren't near regular enough for that.
[11:42] <jbailey> Kamion: yada's output is absolute schite, though.
[11:42] <jbailey> Kamion: And it's input isn't any better.
[11:42] <Kamion> indeed so
[11:42] <Kamion> but my impression has always been that it's the rules file generation that really drives people insane about it
[11:42] <jdub> jbailey: 'copy tree of files' sort of stuff
[11:42] <jbailey> Kamion: The idea is to take input that looks essentially like a cdbs1 rules file, and spit out something like you'd expect to write yourself.
[11:43] <Kamion> rather than the actual input/output formats
[11:43] <Kamion> (after all when working on Debian packages you end up dealing with just about every format known to man; what's one more?)
[11:44] <Kamion> the issue is that we have ten years of expectation that debian/rules is the core file driving everything
[11:44] <Kamion> changing that would be incredibly confusing ...
[11:44] <jbailey> Ah, you mean so it would suck to discover that it had been generated when you get around to editting it.
[11:44] <jbailey> Hmm
[11:44] <Kamion> exactly
[11:44] <Kamion> if debian/rules was the driving file and it produces debian/rules.out or something, that'd be less bad
[11:44] <lifeless> store a checksum
[11:45] <Kamion> lifeless: so missing the point
[11:45] <lifeless> Kamion: not really. I think its very useful to be able to edit fucked output
[11:45] <azeem> I think the history with debian/control{,.in} shows that this is a valid concern
[11:45] <Kamion> losing your changes sucks, yes, but my point is more that breaking really hardcoded developer expectations is bad
[11:45] <lifeless> so if one runs a tool to make debian/rules, and its buggered, just fix the rules file
[11:45] <azeem> OTOH, debian/rules is more free-form than control, so you might rather expect something like that
[11:46] <lifeless> so the question is - is the generation done per build or when the developer feels like it ?
[11:46] <Kamion> lifeless: fine as long as one is running a tool to make some file *other* than debian/rules, please
[11:46] <Kamion> lifeless: my point is that taking a file which has historically always been source and making it autogenerated is bad, when you consider that this will be hacked on by random people diving in quickly to fix a bug
[11:46] <lifeless> ok, I see what you mean, but I am not convinced which the lesser harm is. Would you be happy with a stub rules file that says 'foo is the source, this file calls foo.bar for all targets'
[11:47] <lifeless> s/foo.bar/foo.out/
[11:47] <azeem> but I see how others don't like it
[11:47] <Kamion> if their changes get clobbered, that's arguably better, because then we won't end up with source packages containing debian/rules files which started out as autogenerated and then were randomly hacked on
[11:47] <Evaso2> hi, i doesn't know if could be also useful for developer but there is a list of package not in sync with his upstream version ordered by popcon values. There are also available upstream NEWS/Changelogs when you click on the upstream version number. If anybody would test it could find here: http://dehs.alioth.debian.org/no_updated.html
[11:47] <jdub> so why isn't cdbs regarded as deterministic?
[11:47] <Kamion> lifeless: I don't know if you've ever seen a configure file that somebody decided to hack by hand and then had to carry over its changes, but it isn't pretty
[11:48] <lifeless> Kamion: I have
[11:48] <lifeless> I also had to try to fix said configure.in.
[11:48] <Kamion> jdub: its debian/control editing mode (optional) produces nondeterministic results because it's editing files after buildds have already inspected them to decide on what to do
[11:48] <lifeless> I *know* why they hacked configure in that case. ewww.
[11:48] <jdub> Kamion: *oh*
[11:48] <azeem> I think CDBS has lost much credit due to nyu's random 'let's do this so to fix that' stuff people weren't prepared for
[11:48] <jbailey> jdub: Because it's a tool with large scope that can be hard to track down the specific verions.
[11:49] <Kamion> jdub: oh, I guess people are referring to substantial behaviour changes of the tool
[11:49] <jbailey> jdub: The thing that debhelper did well is that when it broke, the app was probably only doing one little thing.
[11:49] <jbailey> jdub: When cdbs breaks, it can take out completely random things.
[11:49] <Kamion> debhelper is also very careful about compatibility
[11:49] <jbailey> azeem: Yeah, that's probably true.
[11:49] <Kamion> the DH_COMPAT / debian/compat stuff
[11:49] <jbailey> cdbs was while I was still the main person hacking on it. =(
[11:50] <azeem> seb128: fork it!
[11:50] <jbailey> The other folks who did things with it tended to ignore the fact that it had a testsuite.
[11:50] <jdub> i'd be surprised if sebuild and dhbuild were as efficient if not for cdbs :)
[11:50] <seb128> and some "list of targets for common actions you may want to do" :)
[11:50] <jbailey> Even a recent upload to Ubuntu *disables* one of the tests rather than fixing it.
[11:51] <lifeless> garh
[11:51] <lifeless> whodidthatcanyouhurtthembadlyplease
[11:51] <seb128> jbailey: yeah, those KDE guys, breaking everything :p
[11:52] <jbailey> One of the problems I ran into with cdbs2 was convincing folks to hack on it as well.  I could cheerfully dig the code up, but it's hard to find a decent common denominator that people will put up with.
[11:52] <jbailey> Posix shell was the one thing that could be guaranteed to be on everyone's system.
[11:52] <lifeless> and that noone will respect
[11:52] <jbailey> Even doing the pieces in bash would make the code alot simpler.
[11:53] <jbailey> lifeless: You can ask infinity or keybuk, my shell code is purty. =)
[11:53] <lifeless> its not about you!
[11:53] <lifeless> ;)
[11:53] <jbailey> That's what my shrink says too...
[11:53] <lifeless> say hi to her
[11:54] <Kamion> work-in-progress bootloader screens can be really weird sometimes: http://people.ubuntu.com/~cjwatson/gfxboot/weird.png
[11:56] <jbailey> Kamion: Clearly this is original work ;)
[11:56] <seb128> jdub: you have not commented on the ubuntu-desktop session dialog discussion !
[11:56] <Kamion> I'll leave credit, don't worry :)
[11:56] <jbailey> To wrap this up, do you think it's worth me dusting off the cdbs2 codebase and keeping that going?
[11:57] <jbailey> The rules files are like cdbs1 ones, but cleaner, and the codebase already has more documentation that cdbs1
[11:57] <jdub> seb128: not yet
[11:57] <jbailey> And hey, it's not written in obscure gnu make.  It *has* to be better. =)
[11:57] <lifeless> jbailey: if you have a python version planned, start it ;)
[11:57] <seb128> jbailey: as an user I don't really care about cdbs1/cdbs2/cdbs3, I want something easy to use and powerful enough
[11:57] <jdub> #!/usr/bin/debian-packaging-ini-file-configuration-processor
[11:58] <jdub> ;_)
[11:58] <seb128> jbailey: cdbs1 with multibuild and some "list of targets to use for doing common actions" would be good enough
[11:58] <jbailey> jdub: Policy says it has to be make.
[11:58] <lifeless> jdub: #!/usr/bin/env debian...
[11:58] <jdub> policy can bite my precious golden arse!
[11:58] <jdub> that's interesting though
[11:58] <lifeless> ---
[11:58] <lifeless> $*:
[11:59] <lifeless>   /usr/bin/debian-packaging-ini-file-configuration-processor $*
[11:59] <jbailey> procmail based debian/rules files? =)
[12:00] <lifeless> jbailey: my make syntax needs a refresher, I think there is a wildcard target facility though
[12:00] <Kamion> policy> last time it came up it was observed that all the present examples that *weren't* make were deliberate exercises in obfuscation
[12:00] <lifeless> so just thunk it through
[12:00] <psusi> jbailey: hey... do you think you might have some time soon to take a look at http://bugzilla.ubuntu.com/show_bug.cgi?id=15897 again?  I think it needs reassigned back to Fabio
[12:00] <jbailey> lifeless: There is, I do.
[12:00] <Kamion> (and yes, that you could always thunk so it didn't restrict actual innovation as opposed to piss-taking)
[12:01] <jbailey> I'll dig up the code base, dust it off and show it around.
[12:01] <lifeless> Kamion: I wasn't piss-taking, as jbaileys comment shows I think ;)
[12:01] <seb128> jbailey: why not sendmail configuration files while you are at it :p
[12:01] <slomo> lamont-away, infinity: please give-back banshee on ppc, thanks :) and what happened to mod-mono?
[12:01] <jdub> i'm not really piss-taking
[12:01] <jbailey> seb128: I *like* sendmail.
[12:01] <jdub> jbailey: jebus. lucky we don't support it. :)
[12:01] <Kamion> lifeless: I wasn't talking about you
[12:01] <seb128> jbailey: I know, and that's not normal :)
[12:01] <Kamion> the piss-taking was years ago
[12:01] <lifeless> Kamion: ahha. ok.
[12:01] <jbailey> seb128: When I look at specs like PostfixCandy, I keep thinking about how trivial it would be in sendmail.
[12:01] <Kamion> shoop, IIRC
[12:01] <lifeless> 'Its not about you *either* lifeless
[12:01] <lifeless> '
[12:02] <jbailey> jdub: Hmm.  True.  I guess I'm in a position to argue that we could support sendmail, aren't I? =)
[12:02] <jdub> luckily, no :-)