[12:08] <seb128> nautilus? ;:)
[12:08] <illovae> but i know it is working, but i think it's depends of the coreutils devel
[12:08] <illovae> i know it is working on mandrivia
[12:08] <illovae> lol seb128 
[12:08] <illovae> ^^
[12:09] <seb128> what coreutils version is shipped with mandriva?
[12:10] <illovae> hehe, good question
[12:11] <illovae> look at this, 3 years ago > http://www.mail-archive.com/bug-coreutils@gnu.org/msg00610.html
[12:11] <illovae> well i don't know the version on mandrivia i don't have it, i just saw a screenshot from it, on linuxfr.org
[12:13] <seb128> illovae: according to http://linuxfr.org/~pascalscl/13847.html that was a Mandriva patch
[12:13] <seb128> they stopped using it apparently
[12:13] <seb128> the current spec has no such patch
[12:14] <illovae> erf... i was thinking that this patch wasn't added on coreutils in debian or ubuntu
[12:14] <illovae> but was available on other distribution
[12:14] <seb128> doesn't look like
[12:15] <illovae> what do you think of this patch ? a good idea, or the end-users don't want it ?
[12:15] <illovae> i mean, maybe the devels can integrate it on the next rlz of coreutils
[12:17] <seb128> I think it would have been accepted upstream or Mandriva would still be shipping it if it was good
[12:17] <seb128> they probably stopped using it for a reason
[12:17] <illovae> i'm really sorry i don't have any knowledge about how do i can demand that for a future version, maybe it's not the good place
[12:18] <jdong> illovae: file a bug report agains the package
[12:18] <seb128> usual way to ask to get a change is the bug tracker
[12:18] <illovae> yeah, it appears that the shellusers don't care about a fonction like this
[12:18] <illovae> oki jdong thx :)
[12:18] <illovae> k seb128 
[12:20] <illovae> oki
[12:21] <desrt> is the decision for mountainview sponsorship delayed or does no answer = negative?
[12:22] <illovae> thank you all for answering me with taking on your own time, i hope i wasn't too disturbing
[12:22] <illovae> and again sorry for my english :D
[12:23] <seb128> np ;)
[12:23] <seb128> your english is good enough, don't worry
[12:23] <zul> desrt: its been announced already
[12:23] <illovae> k thanks but it's difficult lol, i write in english with the speed of a child
[12:24] <desrt> so last time i think they sent out a "sorry, tough luck" email...
[12:24] <LaserJock> I don't know that they are completely done though
[12:24] <LaserJock> desrt: so maybe they haven't sent the "tough luck" emails yet
[12:24] <desrt> nod.
[12:26] <sivang> I've received it already :-)
[12:26] <sivang> this mid-day
[12:27] <ajmitch> LaserJock: I got mine
[12:27] <ajmitch> just this morning
[12:27] <sivang> maybe it was this morning,
[12:27] <sivang> I got delusinal and started drinking the minute I saw it so can't recall >;-)
[12:28] <illovae> sorry again, just a question for security : 'cp' and 'mv' are parts of coreutils right ?
[12:28] <illovae> (for my bug report)
[12:29] <desrt> ajmitch; did you get a tough-luck one or a friendly-love one?
[12:29] <sivang> desrt: there are friendly-love ones as well? :)
[12:29] <desrt> the "please come and we'll pay" ones :)
[12:29] <ajmitch> desrt: tough luck, I suck, etc :)
[12:29] <desrt> wow.  they actually said you suck?
[12:30] <ajmitch> no
[12:30] <desrt> that's tough indeed :p
[12:30] <ajmitch> it was implied :)
[12:30] <sivang> yes
[12:30] <sivang> in mine as well ;)
[12:30] <desrt> i guess failing SoC makes you a bit of a lepper :(
[12:30] <seb128> illovae: they are
[12:31] <illovae> thank a lot seb128 :)
[12:31] <seb128> np!
[12:31] <desrt> seb128; did you ever see my gdm hackery?
[12:32] <desrt> seb128; i was sort of wondering if you could help me out with something
[12:32] <seb128> desrt: I don't think so
[12:32] <seb128> maybe
[12:32] <ajmitch> desrt: I expect that
[12:32] <seb128> what is that about? ;)
[12:32] <desrt> when you successfully login the login screen stays on
[12:32] <desrt> and the 'enter your password' area is replaced by a progress bar
[12:32] <desrt> which slides along as you login
[12:33] <desrt> and the gdm window disappears only after the desktop is completely ready
[12:33] <ajmitch> desrt: enlightenment-like bling?
[12:33] <desrt> so you don't get all sorts of flickering when logging it
[12:33] <desrt> it looks extra nice if the gdm background is similar to the desktop background
[12:33] <seb128> desrt:  http://bugzilla.gnome.org/show_bug.cgi?id=322056
[12:33] <Ubugtu> Gnome bug 322056 in general "allow to set background image when using graphical greeter" [Normal,Assigned]  
[12:34] <desrt> seb128: more like http://bugzilla.gnome.org/show_bug.cgi?id=355190
[12:34] <Ubugtu> Gnome bug 355190 in general "[rfe]  gdmgreeter continues to run during login process" [Enhancement,Unconfirmed]  
[12:34] <seb128> desrt: that is what Mandriva do, that avoid jumping by a transitional uni-color background
[12:35] <desrt> see the screenshot for an idea -- http://bugzilla.gnome.org/attachment.cgi?id=72465&action=view
[12:35] <desrt> 'cept it's no longer a pulsed progress bar -- it's a real one
[12:35] <seb128> right, those are 2 different ways to make the transition gdm to desktop smoother
[12:35] <desrt> in any case i'm catching a fair amount of resistance from upstream on the issue
[12:35] <desrt> and "distro X does it this way already" is sometimes good leverage :)
[12:36] <seb128> right
[12:36] <seb128> I'm not convinced I would prefer your way to the bug I pointed
[12:36] <desrt> hmm.  ok.
[12:36] <seb128> switching directly to the desktop background with the splash is good too
[12:36] <seb128> I would need to try
[12:36] <desrt> cool
[12:36] <desrt> you need some gnome-session love in order for it to work properly
[12:37] <seb128> I just think it would feel weird to have the gdm screen staying for the time of the session startup
[12:37] <desrt> but i think there's some stuff attached to the bug that lets you emulate it with appropriate shellscrpts
[12:37] <desrt> seb128; i hate to say it, but "see also: macos, windows"
[12:37] <desrt> :)
[12:37] <desrt> anyway.  friend is here.  gotta run.
[12:37] <seb128> see you later
[12:37] <sivang> laters desrt 
[12:37] <seb128> almost time to sleep here ;)
[12:38] <sivang> seb128: do you follow Paris time?
[12:38] <seb128> correct
[12:39] <sivang> so we have now have same time :)
[01:29] <crimsun> LaserJock: pong
[01:29] <LaserJock> I pinged you in here?
[01:30] <crimsun> probably in -motu, migrating.
[02:02] <bddebian> Howdy folks
[04:21] <fossa>  i'd like to talk to a software developer or someone familiar with the field about what kind of salary i can expect as a member of a development team.
[04:29] <nictuku> fossa, if you know, please tell me
[04:29] <nictuku> if you find out, I mean
[04:36] <fossa> nictuku, no one seems to have any idea.  it could range anywhere from $45-80K
[04:36] <bluefoxicy> gimme some help here
[04:37] <bluefoxicy> what happens on the initrd
[04:37] <bluefoxicy> or more specifically what happens between executing /linuxrc and getting to readahead
[04:37] <bluefoxicy> I believe it may be possible to improve readahead efficiency massively, but this is based on a couple big assumptions
[04:38] <bluefoxicy> primarily, I am making the assumption that the boot order is initrd->linuxrc->load a bunch of hardware modules->mount and pivot root->pass control to upstart->load some more hardware->mount some essential file systems->bring up readahead
[04:39] <bluefoxicy> in which case, initrd->linuxrc->load modules for rootfs and underlying hardware->activate read-ahead process in the background->continue as normal would take advantage of the time other hardware is being probed for and initialized
[04:44] <wasabi> Hmm. Where's teh "reopen" button in LP?
[04:44] <wasabi> On a bug.
[04:45] <infinity> wasabi: Edit the bug and change the status from Fix Released to something else?
[04:45] <wasabi> Don't have a status option anywhere I can find.
[04:46] <infinity> Bug number?
[04:46] <wasabi> bug 43465
[04:46] <Ubugtu> Malone bug 43465 in libpam-krb5 "Unable to unlock." [Medium,Fix released]  http://launchpad.net/bugs/43465
[04:46] <wasabi> oh there
[04:46] <wasabi> you have to click on the "affects"
[04:46] <wasabi> Heh. I got it.
[04:46] <infinity> Yeha. :)
[04:46] <infinity> There used to be a little arrow there that made it more obvious it was expandable.
[04:46] <infinity> Not sure why that went away.
[04:47] <wasabi> Thanks!
[04:50] <bluefoxicy> whaaaa....
[04:51] <bluefoxicy> the initrd has 176 modules on it?
[04:51] <HrdwrBoB> it has all modules in it
[04:52] <bluefoxicy> HrdwrBoB:  isn't that counterproductive
[04:52] <ajmitch> wasabi: we could probably drag in new libpam-krb5 from debian, if you can test it & get back with some info on it
[04:52] <bluefoxicy> HrdwrBoB:  that being, you have to load those all, unpack them into memory, modprobe them each, they have to be stored on disk in the initrd image...
[04:52] <ajmitch> since it's still in universe
[04:54] <infinity> bluefoxicy: Yes, it's inefficient, but it's the safest approach.  You can choose to have your initrd built with "MODULES=dep" to try to guess which modules to include and make it smaller, but it's less safe.
[04:54] <bluefoxicy> infinity:  ah.
[04:54] <infinity> bluefoxicy: See initramfs.conf(5)
[04:54] <bluefoxicy> infinity:  is there a reason it's technically infeasible to detect rootfs file system type and the hardware it runs on?
[04:54] <infinity> MODULES=dep also, of course, means that upgrading your motherboard or moving the hard drive to another box will leave you with an unbootable system.
[04:55] <bluefoxicy> ...?
[04:55] <HrdwrBoB> since there is no modules for that system
[04:55] <infinity> If you only include the driver for your specific disk controller, you get a new controller...?
[04:55] <bluefoxicy> The PCI drivers aren't generic.. the IDE interface should be generic except it won't have DMA (I've run without the IDE controller driver before, it's slow)
[04:55] <infinity> Something an "expert" could deal with fine, but not robust for the ideal user.
[04:56] <infinity> s/ideal/average/
[04:56] <bluefoxicy> infinity:  the SATA controller I use will probably not work
[04:56] <HrdwrBoB> even for an expert it's a PITA
[04:56] <bluefoxicy> you _NEED_ the driver for the specific SATA you have
[04:56] <infinity> bluefoxicy: Yes, that's my point.
[04:56] <infinity> bluefoxicy: Hence why we build the "fat" initrd by default.  Much safer and easier for users to not break.
[04:56] <bluefoxicy> for me when I had Gentoo I could never figure out my IDE controller until the last year of using it
[04:56] <bluefoxicy> so I never had DMA
[04:57] <bluefoxicy> but the generic IDE support got me actual access to the disk
[04:57] <bluefoxicy> infinity:  nods, good points anyway.  But... NETWORK card drivers?
[04:57] <infinity> Similar argument.  Fat initrds for thin (or chubby) clients.
[04:58] <infinity> We don't actually load/probe them unless you're booting from a network, so it's just a bit of wasted space.
[04:58] <bluefoxicy> infinity:  alright.  Is it safe to attempt to get the rootfs access immediately and get rootfs mounted early from the initrd, in its fat form?
[04:59] <infinity> That's pretty much the whole point of initramfs anyway.
[04:59] <infinity> I'm not sure how much more quickly we can get there.
[04:59] <infinity> It's not like it does anything ELSE. :)
[04:59] <bluefoxicy> what about the other hardware?  That's loaded from rootfs, even when it's got duplicate modules in initramfs?
[04:59] <infinity> (Well, except for cute stuff like usplash and bootchart and thins)
[05:00] <bluefoxicy> infinity:  about when does readahead come into play?
[05:00] <infinity> Hardware loading is pretty much just done by udev, in two passes.
[05:00] <infinity> So, what modules you have available determines what gets loaded.
[05:01] <infinity> (I lied about the network driver thing, still thinking of pre-udevplug days)
[05:01] <infinity> So, yeah, your NIC driver will probably get loaded in the initramfs.  No big deal.
[05:01] <infinity> I don't have any NICs that actually take time to settle.
[05:01] <infinity> Or, wait.  Maybe Scott calls udevplug with an argument to only load storage class stuff.
[05:01] <infinity> Okay, I should go read the code again. :)
[05:02] <infinity> Ahh, yeah, it just loads storage class stuff if you're booting local.  I was right the first time.
[05:02] <infinity> So your NIC won't get loaded until we switch to the real root.
[05:02] <bluefoxicy> infinity:  Well my endpoint is that I want to back readahead to when it's immediatly feasible to begin reading files off the rootfs, especially before drivers start getting loaded; drivers need to initialize hardware, and if readahead is running in the background while hardware is initting you have a CPU bound problem in parallel with an IO bound problem and they both parallel quite nicely.
[05:03] <bluefoxicy> but I don't entirely understand what's happening at boot
[05:03] <infinity> We tossed around the idea of two readahead invocations (one for rootfs, one for the full fs), but we don't really read enough from the rootfs before mounting /usr to make it worthwhile.
[05:04] <infinity> So, we do readahead pretty much as soon as /usr is mounted.
[05:04] <bluefoxicy> what about moving the mount of /usr back earlier, say as soon as you can satisfy access to its device
[05:05] <infinity> It's already as early as it can get.
[05:06] <bluefoxicy> mm.
[05:06] <infinity> Check /etc/rcS.d, and tell me what you think could happen after /usr is mounted.
[05:06] <bluefoxicy> oh, rcS is always started?  (couldn't figure that part out on my own)
[05:07] <infinity> Oh, hey, Scott did give us that second readahead invocation.
[05:07] <infinity> So, even that's happened.
[05:07] <bluefoxicy> cool
[05:07] <infinity> Yeah, rcS is the "boot" runlevel.
[05:07] <infinity> You go from initramfs to rcS to whatever default runlevel you have (usually rc2)
[05:08] <bluefoxicy> hmm
[05:10] <bluefoxicy> the only other thing I can think of is that readahead is not adaptive; but preload is too much of a nightmare to me
[05:10] <wasabi> ajmitch: Sorry. I don't think it's libpam-krb5's fault.
[05:11] <ajmitch> wasabi: oh well, I'll look at reasons to get it updated anyway :)
[05:11] <wasabi> Heh.
[05:11] <wasabi> We're going to be doing directory integration stuff at the summit.
[05:11] <wasabi> libpam-krb5 will be a part of that. ;)
[05:11] <jdong> bluefoxicy: preload is indeed a nightmare
[05:11] <jdong> bluefoxicy: on my box, it tends to cause extra disk IO more than anything else
[05:11] <bluefoxicy> jdong:  I think it c.. yeah, thrashing.
[05:12] <ajmitch> wasabi: yes, I'm really hoping to get there if at all possible
[05:12] <jdong> bluefoxicy: personally I'd like to see more work in the readahead department
[05:12] <jdong> I like readahead
[05:12] <bluefoxicy> jdong:  How early can I get inotify up
[05:12] <jdong> if prefetchers are made for GNOME, firefox, etc...
[05:12] <jdong> all I think are necessary are launcher wrapper scripts
[05:13] <ajmitch> wasabi: I have a few things to bring up..
[05:13] <wasabi> ajmitch: Hope ya make it. Planning on it?
[05:13] <bluefoxicy> jdong:  preload is probably dumb enough to read-ahead entire libraries
[05:14] <jdong> bluefoxicy: I don't think preload has any level of intelligence :D
[05:14] <ajmitch> wasabi: looking at how I can get there
[05:14] <bluefoxicy> I would read-ahead their headers only first and then go back and read their .data  and let .text be
[05:14] <bluefoxicy> (dynamic linking ONLY cares about headers...)
[05:16] <bluefoxicy> jdong: I would tie the read-ahead into init mainly; just-in-time read-ahead is pretty pointless, except maybe reading in library headers to make dynamic linking more IO bound
[05:17] <jdong> bluefoxicy: jit readahead reduces disk seeking
[05:17] <bluefoxicy> I mean, you start loading Gnumeric.  It's going to immediately start picking up libraries.  Possibly faster than you can read them in.
[05:17] <jdong> bluefoxicy: that's a pretty big deal for something like GNOME startup
[05:17] <bluefoxicy> jdong:  I could make the dynamic linker do it.
[05:17] <jdong> my GNOME startup is clearly IO bound
[05:17] <bluefoxicy> no, seriously, ld.so could be hacked to do it
[05:19] <bluefoxicy> it reads the needed library section (DT_NEEDED?) and loads libraries one by one, it could easily fork() and set up a readahead() call to each in their header area (and then exit) while it goes and dynamic links
[05:31] <bluefoxicy> i'm severely unmotivated to try to hack glibc
[05:31] <bluefoxicy> I know drepper and friends will just be like "that sucks fuck off" and then show up 3 weeks later with a slightly altered patch "we wrote this, some other guy tried to do something like this but his was stupid ours is much cooler"
[05:32] <mjg59> bluefoxicy: We've heard this before
[05:32] <bluefoxicy> mjg59:  oh, right, yeah.  I've seen it too many times.
[05:44] <nictuku> infinity, maybe NWU will enter Debian experimental soon, I believe. Will you still be able to review its security, as you offered months ago?
[05:44] <infinity> nictuku: If I have time, I can look at it sometime, sure.
[05:46] <nictuku> infinity, thank you. I'll let you know when it gets to the next milestone
[06:07] <whiprush> mjg59: when you refer to docks in your post to the list, do you mean things like resuming in the dock?
[06:07] <whiprush> or just having the dock work?
[06:34] <nixternal> xorg-driver-fglrx broken?  can't get it to work here now..was working until i reboote =/
[06:34] <HrdwrBoB> yeah
[06:34] <HrdwrBoB> looks like kernel has been updated and fglrx hasn't
[06:34] <nixternal> ok..whew ;)
[06:34] <infinity> Err, but the kernel didn't have an ABI change...
[06:35] <infinity> At least, wasn't meant to.
[06:35] <infinity> Oh well, I'll be uploading a new LRM later anyway, so maybe the problem will just go away.
[06:35] <nixternal> as long as i get my 1600x1200 back soon, i don't care ;)
[06:57] <freakabcd> hi all
[06:57] <freakabcd> crimsun, err.. i believe this guy did a _working_ sample implementation _before_ dapper was released!
[06:58] <freakabcd> and its suddenly edgy+1 material?
[06:58] <freakabcd> don;t tell me you guys decided even before dapper was released that binary deltas will be edgy+1 material? heck somehow i think it might even be edgy+2 material :(
[07:01] <crimsun> freakabcd: "suddenly" is a bit far flung
[07:01] <freakabcd> sorry, it is indeed.
[07:01] <freakabcd> but could you elaborate on the idea that it was pre-conceived waay back that its edgy+1 material?
[07:02] <tfheen> freakabcd: was there an implementation in the archive before feature freeze?
[07:02] <freakabcd> tfheen, i dunno about dapper. but surely before even edgy opened for devel
[07:03] <freakabcd> its somewhere in the mailing list archives.
[07:03] <tfheen> freakabcd: oh?  Can you point me to the spec?
[07:05] <freakabcd> https://lists.ubuntu.com/archives/ubuntu-devel/2006-May/017602.html
[07:05] <freakabcd> there might be another main thread somewhere else. but thats the one i found byt looking just now
[07:06] <tfheen> that's not a spec, though.  Our development process is spec-focused where all features should have a spec before they are implemented
[07:07] <freakabcd> err.. what i meant was. if you read that thread: theres not much interest in even writing a spec.
[07:07] <freakabcd> you can;t expect 1 person to do all the work of writing the spec and implementing a proof-of-concept
[07:07] <freakabcd> the guy wrote a proof-of-concept that works. now write a spec and a proper implementation (i guess by committee). this never happened
[07:08] <tfheen> if there's no interest in the feature, nobody will write the spec.
[07:09] <tfheen> it's quite simple, really
[07:09] <freakabcd> really, people just underrate bandwidth.
[07:09] <Treenaks> really, some people overrate it
[07:09] <freakabcd> updating huge megabytes of packages for few kb of changes
[07:10] <tfheen> that might be, but somebody needs to write the spec and make sure it gets targetted for a release.  That requires somebody to push for it, not just write a sample implementation and hope it all works out in the end.
[07:11] <Hobbsee> tfheen: no magic wand waving?  no fun!
[07:11] <jdub> wang!
[07:11] <tfheen> Hobbsee: heh. :-)
[07:11] <tfheen> Hobbsee: good morning
[07:12] <ajmitch> afternoon Hobbsee 
[07:12] <tfheen> freakabcd: and complaining about missing features after feature freeze is a bit late.
[07:13] <freakabcd> apologies, my objective was not to engage in an 'include this feature or die' conversation.
[07:14] <tfheen> https://wiki.ubuntu.com/FeatureSpecifications tells a bit about how the process works
[07:19] <Hobbsee> hey tfheen, ajmitch :)
[07:27] <bluefoxicy> boot chart says things are a mess I/O wise.  Hrm.
[07:27] <bluefoxicy> How early can I get inotify up
[08:17] <pitti> Good morning
[08:23] <Hobbsee> hey pitti 
[08:54] <dholbach> good morning
[09:46] <seb128> mdz_: I think I didn't get a reply to the mail I sent you where I suggested seeding avahi-daemon, is that still pending reply on your side?
[09:46] <mdz_> seb128: I don't think it's in my inbox; please resend
[09:48] <seb128> mdz_: it was a reply to your mail about avahi-daemon activated by default (following on the debian thread about it)
[09:48] <seb128> mdz_: ok, will do
[10:01] <tfheen> mdz_: any chance you can nag LP people to get https://launchpad.net/products/malone/+bug/62495 fixed or worked around?  RC will be painful without it fixed.
[10:01] <Ubugtu> Malone bug 62495 in malone "Milestone bug list doesn't sort properly" [Undecided,Confirmed]  
[10:02] <cbx33> ping mvo
[10:02] <mvo> hello cbx33
[10:03] <heno> tfheen: when shall we set the WinFOSS freeze at? I'm easy, the remaining work is trivial anyway
[10:03] <cbx33> preffered method for upgrading a dapper machine to edgY?
[10:03] <seb128> update-manager -d 
[10:03] <cbx33> I need to do an upgrade test for edubuntu for ogra
[10:03] <cbx33> hmmm
[10:03] <heno> This page doesn't actually have an RC FREEZE data AFAICS https://wiki.ubuntu.com/EdgyReleaseSchedule
[10:03] <tfheen> heno: personally, I like to get stuff done early rather than late, so either ten or seven days before RC?
[10:04] <cbx33> seb128 i get nothing
[10:04] <cbx33> just the normal update
[10:04] <mvo> cbx33: update-manager -c -d, please let me know about the result 
[10:04] <cbx33> ok
[10:04] <cbx33> will try again
[10:05] <cbx33> mvo got it with that command, but only if I export my proxy details first
[10:05] <cbx33> this was raised as a bug last time
[10:05] <heno> tfheen: ok, monday is 10 days before, we can do that
[10:05] <mvo> cbx33: do you use gnome-terminal? is your proxy configured via gconf?
[10:06] <cbx33> hmmm lemme check not sure on this machine
[10:06] <cbx33> it is certainly configured in apt
[10:06] <tfheen> heno: if that's not enough time, do tell me, though
[10:07] <cbx33> i just set it up in the gnome network proxy 
[10:07] <cbx33> using the auto config script option
[10:07] <cbx33> and it still doesn't work
[10:08] <heno> tfheen: the only thing is if Firefox put out a very important fix late in the process, but I can ask for a special exception for that
[10:08] <heno> So we'll go with monday
[10:09] <cbx33> doesn't seem to work at all mvo
[10:09] <mvo> cbx33: this is probably a transient failure, this whole thing works by using http_proxy. that is passed via gksu and gnome-terminal. if you use the gnome-terminal that is still open it will fail unfortunately
[10:09] <tfheen> heno: sure.
[10:09] <cbx33> ah ok
[10:09] <cbx33> I'll try not using gnome terminal
[10:09] <mvo> cbx33: *but* please file a bug about this, so that I can fix it properly 
[10:10] <cbx33> nope still doesn't work even if I run from the menu
[10:10] <cbx33> only way I can get it to successfully run is to export the proxy details first
[10:11] <mvo> cbx33: oh, plesae file a bug then, I will fix it with the next upload (fix should be straight-forward)
[10:12] <cbx33> mvo no problem
[10:12] <mvo> thanks
[10:13] <Burgundavia> cbx33: do you not have an LP account?
[10:14] <ogra> Burgundavia, https://launchpad.net/people/petesavage
[10:14] <Burgundavia> ogra: odd, because mdz commented on that bug that he couldn't find pete
[10:14] <ogra> which bug ?
[10:15] <cbx33> mvo - https://launchpad.net/distros/ubuntu/+source/update-manager/+bug/40626
[10:15] <Ubugtu> Malone bug 40626 in update-manager "Update manager ignores proxy settings when attempting to download upgrade tool for Dapper." [Medium,Needs info]  
[10:15] <cbx33> Burgundavia: I know but I do have an account else I wouldn't have been able to do a lot of things ;)
[10:15] <cbx33> that was created ages ago
[10:15] <mvo> cbx33: ok, updated
[10:15] <cbx33> ty dude
[10:15] <ogra> Burgundavia, he's edubuntu member and motu ... 
[10:15] <cbx33> ogra starting the upgrade now
[10:16] <Burgundavia> ogra: yes, that is what I thought
[10:16] <ogra> cbx33, thanks, and apparently you identified a bug already ;)
[10:16] <cbx33> maybe it's because I'm PeteSavage and not Pete Savage
[10:16] <cbx33> I reported it back in the breezy -> dapper
[10:17] <cbx33> but then I think before I could LP it, someone else had
[10:18] <seb128> cbx33: dunno if you read the comments, your gconf change is not good
[10:18] <cbx33> I havn't had a chance to read yet
[10:18] <cbx33> seb128 oh?
[10:18] <cbx33> I'll go read
[10:18] <seb128> cbx33: it breaks login in some cases apparently
[10:19] <seb128> cbx33: I got gconfd complaining than /var/....USER directory can't be created
[10:19] <cbx33> grr
[10:19] <seb128> cbx33: and session exiting on that
[10:19] <cbx33> *&%$
[10:19] <cbx33> hmm.....
[10:19] <cbx33> any ideas?
[10:19] <seb128> no, nothing trivial
[10:19] <cbx33> shute
[10:20] <seb128> either look at gconfd-2 code and make it handle that fine
[10:20] <cbx33> ogra anything from your end?
[10:20] <seb128> or make something create those directories, not sure on where to plug that though
[10:20] <cbx33> seb128 sure - hmm
[10:20] <seb128> it would be easy to create them for existing users
[10:21] <seb128> the issue is if you create a new user it would need to create the directory too
[10:21] <ogra> i'd add it to users-admin then ...
[10:21] <cbx33> yeh
[10:21] <seb128> and I don't fancy try to change adduser, etc for that
[10:21] <Kamion> argh no
[10:21] <Kamion> users-admin <- wrong place
[10:21] <ogra> oh, why ?
[10:21] <seb128> because it's a gconf directory
[10:21] <ogra> additional groups are added there as well
[10:21] <ogra> ah, k
[10:21] <Kamion> ogra: people add users with useradd, adduser, or hell they create them on a totally different machine using NIS or whatever
[10:22] <cbx33> true
[10:22] <seb128> and some people add users who don't use GNOME :p
[10:22] <Kamion> there's no way to do this correctly by patching the user creation tools
[10:22] <ogra> right
[10:22] <cbx33> ok ogra I'm going for the upgrade....ok?
[10:22] <Kamion> if you want a per-user directory you need a component running as root to create it
[10:22] <cbx33> Kamion: yup
[10:22] <cbx33> but it's too late for that now
[10:23] <seb128> the way is probably to make gconfd-2 not complain when the directory doesn't exist
[10:23] <cbx33> again too late for that now
[10:23] <seb128> probably yep
[10:23] <cbx33> damn it
[10:23] <cbx33> it worked fine here
[10:23] <seb128> it doesn't here
[10:23] <ogra> cbx33, we have a component running as root ...
[10:23] <Kamion> cbx33: if it's too late for that now, then the patch surely needs to be reverted
[10:23] <ogra> why cant S-C-P create it if needed ?
[10:24] <Kamion> too late to do it at all correctly => don't do it at all ...
[10:24] <seb128> ogra: I'm not going to change gconf in a way which makes it break if you root component is not running
[10:24] <cbx33> ogra: sure 
[10:24] <cbx33> but scp isn't runnign all the time
[10:24] <ogra> right
[10:24] <seb128> Kamion: I didn't upload the patch since I faced the issue with my test user on my desktop
[10:24] <cbx33> and the dir is created in pessulus
[10:24] <ogra> i thought its only about creating the dir ... (didnt know it breaks without it)
[10:24] <Kamion> seb128: ah right, good
[10:24] <cbx33> ogra: no....that's the issue
[10:24] <cbx33> pessulus creates it......
[10:25] <cbx33> when you first load it for a specific user
[10:25] <seb128> (in fact I uploaded the patched version and a next one reverting it but both had wrong targets and were refused)
[10:25] <ogra> cbx33, it would be nice if you could CC me in the conversation about such issues next time ...
[10:25] <cbx33> ogra this is the first I've heard of it
[10:25] <ogra> since i only understand half of what you guys are talking about atm
[10:26] <cbx33> we have a dir created to allow per user mandatory keys
[10:26] <ogra> yep
[10:26] <cbx33> but if that dir doesn't exists - some machine fail to login
[10:26] <seb128> ogra: cbx33 asked me to add "xml:readonly:/var/lib/gconf/users/$(USER)/gconf.xml.mandatory" to the gconf path
[10:26] <seb128> ogra: I did the change yesterday
[10:26] <ogra> ah
[10:27] <seb128> started gdmflexiserver --xnest and logged in with my test user
[10:27] <ogra> that was the patch discussed with vuntz right ?
[10:27] <cbx33> yes
[10:27] <cbx33> he suggested that dir for it
[10:27] <seb128> and gconf complained that /var/lib/gconf/users/USER can't be created and doesn't exist
[10:27] <ogra> where he said that *could* work but would need testing
[10:27] <seb128> and the session exit
[10:27] <ogra> right
[10:27] <seb128> so it's no go from me
[10:27] <cbx33> it "does" work
[10:28] <ogra> lets postpone that for edgy+1 then
[10:28] <cbx33> for me
[10:28] <seb128> it works when I log in with gdmflexiserver and not when I use gdmflexiserver --xnest
[10:28] <seb128> for a reason I don't explain yet :p
[10:28] <cbx33> argh !
[10:28] <ogra> to get more testing and a proper solution for gconf ...
[10:28] <cbx33> ok....
[10:29] <cbx33> ogra we can put that line in a howto on the wiki
[10:29] <cbx33> I've never used gdmflexiserver - so 
[10:29] <cbx33> I generally test on real machines :(
[10:29] <seb128> right, that's one a conffile change
[10:29] <seb128> no need to rebuild a package for it
[10:29] <cbx33> indeed
[10:29] <cbx33> and per user mandatory keys is a "advanced" feature anyway
[10:29] <seb128> cbx33: better to test such changes with all sort of situations
[10:29] <ogra> ok
[10:30] <cbx33> seb128 - I need more info then :0
[10:30] <cbx33> heheh
[10:30] <cbx33> i don;t know all the weird and wonderful ways you guys test yet
[10:30] <cbx33> so I'm updating now ogra
[10:30] <ogra> cbx33, are you coming to MV btw ?
[10:31] <ogra> if so, lets put up a spec and invite seb128 to the table ;)
[10:32] <ogra> SCP will need more enhancements anyway ... 
[10:33] <seb128> :)
[10:34] <cbx33> totally
[10:40] <pitti> mjg59: on my ibook, resuming from STR causes the hard drive spindown time to be reset to 5 seconds; that's destroying the disk (besides being annoying), so I always have to manually reset it to some sane value (15 minutes); do you know which part causes this?
[10:43] <giftnudel> pitti: laptop-mode
[10:43] <pitti> giftnudel: it's not installed
[10:43] <pitti> that's universe
[10:43] <pitti> it's a standard edgy beta installation
[10:43] <giftnudel> but there is something which does this kind of thing
[10:44] <giftnudel> pitti, so you don't have /etc/laptop-mode/laptop-mode.conf ?
[10:45] <pitti> giftnudel: I do, it's from laptop-mode-tools
[10:45] <giftnudel> it's in that file
[10:45] <giftnudel> LM_AC_HD_IDLE_TIMEOUT_SECONDS, LM_BATT_HD_IDLE_TIMEOUT_SECONDS, etc
[10:45] <pitti> giftnudel: argh, indeed: CONTROL_HD_IDLE_TIMEOUT=1, TIMEOUT_SECONDS=5
[10:45] <pitti> WTF????
[10:45] <pitti> so that kills hard disks on all arches
[10:46] <giftnudel> yes
[10:46] <pitti> even for AC power
[10:46] <giftnudel> well, no, it's not active for ac
[10:46] <pitti> giftnudel: it is, I am on AC
[10:46] <pitti> LM_AC_HD_IDLE_TIUMEOUT_SECONDS=5 <= default
[10:47] <giftnudel> yes, but there is still a setting to disable it on ac
[10:47] <pitti> it should be off for AC and something like 15 minutes for battery
[10:47] <giftnudel> yes, this sounds reasonable
[10:48] <pitti> giftnudel: do you know the difference between LM_ and NOLM_?
[10:48] <giftnudel> laptop-mode and no laptop-mode
[10:48] <pitti> ah, thanks
[10:48] <pitti> giftnudel: so, the AC timeout for NOLM is 7200, and for LM 5
[10:48] <giftnudel> yes
[10:49] <pitti> mjg59: do you agree to raising the default timeouts?
[10:50] <giftnudel> "laptop-mode stop" uses the no l-m thing, and ac and batt are for l-m on
[10:50] <giftnudel> pitti: it is explained at the start of the file
[10:50] <pitti> giftnudel: ok, thanks for your help!
[10:51] <giftnudel> ENABLE_LAPTOP_MODE_ON_AC=0
[10:51] <giftnudel> this is also an important option
[10:51] <giftnudel> yes, no problem
[10:51] <pitti> giftnudel: then this one obviously does not work on the ibook
[10:52] <giftnudel> it seems so, but I really suggest a complete review of all options
[10:52] <pitti> I'll file a bug about it for discussion
[10:52] <giftnudel> target it to 6.10, it's easy fixable, but I think we should reach a consensus before that
[10:53] <giftnudel> and backport it to dapper after that, since it really spins down the disc after 5 secs which is a lot!
[10:55] <tonfa> gug
[10:55] <giftnudel> oh, I think laptop-mode is not enabled on edgy atm (it gets switched off and on on a regular basis due to some bug reports)
[10:55] <tonfa> pitti: ping
[10:56] <pitti> hi tonfa 
[10:57] <tonfa> pitti: is there some channel for apport related discussion ?
[10:57] <tonfa> or /query ?
[10:58] <pitti> giftnudel: ah, bug 29529, was already filed
[10:58] <Ubugtu> Malone bug 29529 in laptop-mode-tools "HDD powerdown every 2 seconds in Dapper" [Critical,Confirmed]  http://launchpad.net/bugs/29529
[10:58] <pitti> tonfa: /query is fine for me, or use this channel
[10:59] <giftnudel> pitti: thanks, I found that too
[11:08] <tepsipakki> poking with a stick here, but couldn't 'uname -r' in Ubuntu tell something about the OS version as well?
[11:09] <thom> changing uname is badness
[11:09] <Kamion> that'd be out of spec for uname -r and would break things
[11:09] <Kamion> use lsb_release
[11:09] <pitti> tepsipakki: try lsb_release -a
[11:09] <tepsipakki> ok, that looks nice
[11:10] <Kamion> lots of code parses uname -r (or the equivalent kernel structure) to work out the kernel version it's running on
[11:10] <tepsipakki> yeah, I see
[11:10] <tepsipakki> it's just that lsb_release isn't available on other unices ;)
[11:11] <Kamion> that's easily checked ...
[11:12] <tepsipakki> solaris and tru64 seem to be the ones that output something sensible with uname -r, macosx outputs the kernel version (8.7.0 on 10.4), aix just "2" on 5.2 etc
[11:14] <Kamion> the commercial Unixes often sync up the kernel version with the distribution release
[11:15] <tepsipakki> but I understand that it isn't trivial to change uname in linux.. especially if lsb_release is the standard way to tell the distro in linux
[11:15] <Kamion> but given a known flavour of Unix, uname -r should be considered to have a fixed format
[11:17] <tepsipakki> yes, maybe I won't file a bug about it, instead inform the unix-punks to use lsb_release in linux ;)
[11:17] <tepsipakki> uname works too, if you know which kernel is in wich
[11:18] <tepsipakki> +h
[11:19] <Keybuk> ogra: sysvinit, you about to do it?
[11:19] <Keybuk> if not, I have a quick upload
[11:23] <ogra> Keybuk, then do it
[11:24] <Keybuk> ogra: should ldm not also be in that list?
[11:24] <ogra> Keybuk, nope
[11:24] <ogra> ldm doesnt have an initscript
[11:24] <ogra> ltsp-client starts the screen scripts for ltsp, one of them is ldm
[11:25] <ogra> but there isd for example also the startx screenscript that starts an XDMCP session
[11:25] <ogra> depending on what you select in your lts.conf file
[11:25] <ogra> (ldm is just the default)
[11:44] <ogra> i had two reports now that there is a conffile prompt for login.defs during upgrades
[11:47] <givre> pitti: #35354 , David Zeuthen has just commit a fix for that bug which is actually in git : http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=2ea340399bf8cf3d2bb6bd1b5c4ecbc2042e93d4
[11:47] <pitti> bug 35354
[11:47] <Ubugtu> Malone bug 35354 in nautilus "hal does not recognize NTFS-FUSE mounted devices as mounted" [Medium,Needs info]  http://launchpad.net/bugs/35354
[11:47] <pitti> givre: ah, sweet
[11:47] <givre> pitti: tested it and it works great
[11:48] <pitti> givre: could't you have told me 30 minutes ago? I just uploaded a new hal :)
[11:48] <pitti> (nevermind)
[11:49] <givre> pitti: i saw, yeah ;)
[11:49] <ogra> hrm, 2what apart from shadow touched /etc/login.defs ?
[11:49] <Treenaks> Upload the pod bay doors HAL
[11:50] <ogra> Kamion, ^^^ ? any idea ?
[11:51] <ogra> i see you merged it ...
[11:51] <givre> pitti: there is still a possible issue about the right options to allow
[11:51] <givre> pitti: ntfs-fuse & ntfs-3g use locale= instead of iocharset=
[11:53] <givre> pitti: it's could be good to add it
[11:54] <pitti> givre: that's an entirely separate bug, isn't it?
[11:55] <givre> pitti: separate ? the option stuff ?
[11:57] <givre> pitti: i'll forward you the email i get from David Zeuthen if you want
[11:58] <givre> pitti: there is too change in the commit, one for autofs, which is in any not in edgy hal, and one for fuse
[12:00] <givre> pitti: the right change to do is add at the bug, http://librarian.launchpad.net/4667871/support-fuse.patch
[12:03] <Kamion> ogra: shadow's within its rights to change /etc/login.defs (and it did). The question is more: what other script changed /etc/login.defs?
[12:03] <ogra> right
[12:03] <Kamion> and that I don't know
[12:03] <Kamion> conffile prompts are only a bug if a script changed the conffile
[12:03] <Kamion> they aren't a bug in general
[12:03] <ogra> i cant find anything touching it by grepping through /var/lib/dpkg/info/*
[12:03] <Kamion> then quite possibly those users changed it and forgot about it
[12:04] <ogra> nope
[12:04] <ogra> cbx33, installed a plain dapper and did an edubuntu upgrade test for me
[12:04] <Kamion> ok
[12:04] <ogra> so its untouched
[12:04] <ogra> and i had a report from pips1 during a beta upgrade 
[12:05] <ogra> intrestingly *my* /etc/login.defs in edgy has 
[12:05] <ogra> -rw-r--r-- 1 root root 11K 2006-09-22 03:36 /etc/login.defs
[12:05] <Kamion> 482803f5fcf4df8ad4f99fb8b0ee3ff1  /etc/login.defs
[12:06] <ogra> i'm pretty sure i didnt get a new login package since i installed ... so something touched it as well on 2006-09-22
[12:06] <ogra> 1f6b6a6190933f3a324db770df21e1a7  /etc/login.defs
[12:06] <ogra> (edgy)
[12:06] <Kamion> my timestamp matches the last login
[12:06] <Kamion> package
[12:06] <Kamion> ogra: could you diff yours against http://people.ubuntu.com/~cjwatson/tmp/login.defs, please?
[12:06] <ogra> ok
[12:07] <ogra> ogra@edubuntu:~/packages$ diff login.defs /etc/login.defs 
[12:07] <ogra> 177,178c177,178
[12:07] <ogra> < UID_MIN                        1000
[12:07] <ogra> < UID_MAX                       60000
[12:07] <ogra> ---
[12:07] <ogra> > UID_MIN 1000
[12:07] <ogra> > UID_MAX 60000
[12:07] <ogra> aha
[12:08] <ogra> whitespace :(
[12:08] <esputo> hello, I would like to create a dapper server iso with updated packages, I've been reading arround but I get stuck on the creation of "Packages" files under /dists/ directory, is there any tool for that?
[12:11] <pitti> givre: thanks, I'll read the mail
[12:11] <pitti> esputo: apt-ftparchive does that normally
[12:11] <esputo> thak's pitti I'll give it a look
[12:12] <pitti> esputo: also, take a look at https://help.ubuntu.com/community/InstallCDCustomization
[12:12] <Kamion> ogra: it's not gnome-system-tools or something messing with that file?
[12:12] <givre> pitti: better : http://lists.freedesktop.org/archives/hal/2006-October/006308.html
[12:13] <ogra> Kamion, ah, that could be i think i added a testuser around that time
[12:13] <ogra> i'll add another one
[12:14] <pitti> givre: thanks; I added that to the bug trail
[12:14] <ogra> ogra@edubuntu:~/packages$ ls -lh /etc/login.defs 
[12:14] <ogra> -rw-r--r-- 1 root root 11K 2006-10-05 12:14 /etc/login.defs
[12:14] <ogra> Kamion, yep, it is
[12:15] <ogra> wow, that was a good guess :)
[12:15] <ogra> dholbach, ?? ^^^
[12:15] <ogra> why is it touching it ?
[12:15] <givre> pitti: thanks
[12:15] <dholbach> what is touching what?
[12:15] <ogra> dholbach, g-s-t rewrites /etc/login.defs
[12:15] <dholbach> ah, g-s-t
[12:16] <ogra> and adds whitespace
[12:16] <Kamion> s/adds/removes/
[12:16] <cbx33> ogra: ok I have another
[12:16] <ogra> err, right
[12:16] <cbx33> initramfs.conf
[12:16] <Kamion> that's not so much the point though - it shouldn't touch the file if the values it wants to write are the same as those that are already there
[12:17] <ogra> i dont see a reason to touch it at all though
[12:17] <ogra> cbx33, hmm
[12:17] <cbx33> the RESUME field setting has been altered
[12:17] <cbx33> that's the only thing
[12:17] <Kamion> RESUME should live in a separate file now, typically /etc/initramfs-tools/conf.d/resume
[12:18] <Kamion> there may be some glitchiness in that upgrade
[12:18] <cbx33> -RESUME=/dev/mapper/Ubuntu-swap_1
[12:18] <cbx33> +#RESUME=
[12:18] <cbx33> is the only diff on that file
[12:18] <dholbach> ogra: system-tools-backends, /usr/share/system-tools-backends-2.0/scripts/Users/Users.pm, line 655
[12:18] <cbx33> got enough info on that one? - chall I continue with a replace?
[12:19] <cbx33> that's /etc/initramfs-tools/initiramfs.conf
[12:19] <ogra> cbx33, yep
[12:20] <dholbach> ogra: it's used since you can change that for example in the g-s-t UI - but I guess it could be a tad more careful with preserving whitespaces *shrug*
[12:21] <ogra> it should
[12:21] <cbx33> it wasn't just whitespace
[12:21] <dholbach> called from UsersConfig.pm, line 77
[12:21] <cbx33> sorry I've missed some of the convo
[12:21] <cbx33> and cgi-irc makes it difficult to scroll back up
[12:21] <ogra> the system breaks apparently if you don5t let the package overwrite it with the package file
[12:21] <ogra> pips1 had that case
[12:21] <ogra> he couldnt log in anymore
[12:22] <cbx33> i replaced so unfortuantely I can't tell you on that score :(
[12:22] <cbx33> shall I replace with this initramfs?
[12:22] <ogra> (i'll ask him for details if he's around)
[12:22] <cbx33> ok
[12:22] <ogra> cbx33, yes, thats apparently known
[12:23] <seb128> dholbach: what is used?
[12:23] <Kamion> Riddell: so, assuming that I fix the DCOP calling problem in ubiquity (which I'm working on now), how do I disable the kded medianotifier?
[12:23] <dholbach> seb128: s-t-b seems to touch /etc/login.defs and somethin in edubuntu land (not sure if i understood correctly) doesn't cope with whitespace changes
[12:23] <cbx33> can I ask...is it necessary to regenerate the suaplsh so many times
[12:24] <seb128> dholbach: ah, k
[12:24] <cbx33> usplash
[12:24] <Kamion> dholbach: nothing to do with Edubuntu - /etc/login.defs is a conffile owned by shadow
[12:24] <Kamion> er, login
[12:24] <dholbach> &Utils::Replace::split ($file, $login_defs_prop_map{$key}, "[ \t] +", $$config{$key});
[12:24] <cbx33> on slower machines it takes a long time to regenerate 3-4 times
[12:24] <Kamion> dholbach: you have to be very careful when editing conffiles to avoid unnecessary changes
[12:25] <Kamion> making sure to replace with the same amount of whitespace would help
[12:25] <ogra> urgh !
[12:25] <ogra> the craftsmen need to shut down my power
[12:25] <cbx33> nooooooo
[12:25] <cbx33> battery?
[12:25] <cbx33> generator
[12:25] <cbx33> treadmill??
[12:25] <ogra> no, we get a solar power system and they are doing the final wiring
[12:26] <cbx33> ahhhhh yes your solar power
[12:27] <ogra> brb
[12:28] <seb128> carlos: around?
[12:28] <seb128> carlos: any reason https://launchpad.net/distros/ubuntu/+source/yelp/ has no "translation" link working?
[12:30] <cbx33> is it a known one about exports ?
[12:30] <cbx33> I have a debconf popup
[12:30] <carlos> seb128: translations need a distrorelease as a context
[12:30] <Kamion> Riddell: HAH, fixed the DCOP problem - just need to use kdesu --nonewdcop
[12:30] <carlos> seb128: for instance, https://launchpad.net/distros/ubuntu/edgy/+source/yelp/
[12:30] <seb128> carlos: ok, thank you
[12:31] <carlos> seb128: please, file a bug about that, I think is quite easy to add links to the prefered distrorelease
[12:31] <seb128> carlos: bug on what product?
[12:31] <carlos> rosetta
[12:32] <seb128> ok
[12:32] <Riddell> Kamion: for logout?
[12:33] <dholbach> sladen: thanks for taking care of fschoep's patch
[12:33] <Riddell> ah, medianotifier
[12:33] <Kamion> Riddell: well, I fixed it so that we can make reboot work now
[12:33] <Kamion> (properly, that is)
[12:33] <Riddell> Kamion: you're a genius
[12:33] <cbx33> dudes this debconf thing is horrid
[12:33] <cbx33> :p
[12:34] <Kamion> Riddell: still don't know how to disable the medianotifier though
[12:34] <Riddell> Kamion: turning off medianotifier is "dcop kded kded unloadModule medianotifier"
[12:34] <cbx33> it popped up so I asked it to show me changes
[12:34] <seb128> carlos: https://launchpad.net/products/rosetta/+bug/64154
[12:34] <Ubugtu> Malone bug 64154 in rosetta "package page should have a link to current translation" [Undecided,Unconfirmed]  
[12:34] <Kamion> that's not debconf's fault, it's ucf
[12:34] <cbx33> which it did in the update manager windows text consoly thing
[12:34] <Kamion> (probably)
[12:34] <Kamion> debconf is just the framework, don't blame it
[12:34] <carlos> seb128: thanks
[12:34] <seb128> np
[12:34] <cbx33> and i tried pressing space enter, eventually it's q i needed to press
[12:34] <cbx33> Kamion sorry I'm not blaming
[12:34] <cbx33> I'm just end usering on this one ;)
[12:35] <givre> pitti: i was thinking that adding the right options to volume.mount.valid_options is only needed when you use a solution like gnome-mount, isn't it ?
[12:36] <Kamion> Riddell: oh, dcop kded kded unloadModule maybe?
[12:36] <Riddell> Kamion: that's what I said :)
[12:36] <Riddell> 11:34 < Riddell> Kamion: turning off medianotifier is "dcop kded kded unloadModule medianotifier"
[12:36] <Kamion> Riddell: oh, I totally missed it
[12:37] <Kamion> Riddell: and guessed it myself ;-)
[12:37] <Kamion> whoops
[12:37] <Kamion> ok, cool, I'll try to wire that in
[12:37] <cbx33> btw guys - http://www.progbox.co.uk/finals/RC/exportUB2.ogg
[12:37] <cbx33> shorter login sound
[12:37] <Kamion> Riddell: do I have to unload the mediamanager too?
[12:39] <Riddell> Kamion: don't think so, that just means KDE uses HAL instead of reading fstab, but medianotifier should be the annoying popup boxes part
[12:40] <pitti> Kamion: if you have some seconds, can you please take a look at bug 61092?
[12:40] <Ubugtu> Malone bug 61092 in mozilla-firefox-locale-all "mozilla-firefox-locale-en-gb contains incorrect translations of "disk" (both dapper and edgy)" [Low,Needs info]  http://launchpad.net/bugs/61092
[12:41] <pitti> Kamion: I think the current Firefox en-GB translation is correct, but I'd appreciate your opinion
[12:41] <Kamion> "disc" is a somewhat ... fanatic British English approach, IMHO
[12:42] <Kamion> most computer-literate British English speakers I know use disk in the manner described by the reporter (i.e. not for CDs, but for practically everything else)
[12:42] <Ng> yeah, disc is something flat and round
[12:42] <Ng> otherwise disk
[12:42] <Kamion> I do know a few people who'd say "hard disc", but they also spell "font" as "fount"
[12:42] <Keybuk> I violently dislike people who do s/disk/disc/
[12:42] <Kamion> and other such archaisms
[12:43] <Keybuk> Kamion: computer programme ?
[12:43] <Ng> I'd guess it's from discus
[12:43] <Kamion> Keybuk: right
[12:43] <pitti> ok, then I do The Big Sed to fix that; thanks, guys
[12:43] <Keybuk> I just consider "disk" to be jargon, short for "diskette"
[12:44] <Spads> pro-grammammy
[12:44] <tfheen> Kamion: fount?  Is that legal?
[12:45] <pitti> I can never quite remember whether grey/gray or -ize/-ise is AE or BE
[12:46] <Kamion> tfheen: very very old
[12:46] <Kamion> I can never remember grey/gray myself
[12:47] <Kamion> I use grey, but then I also used to use -ize before I got bored of it and switched to -ise
[12:47] <Kamion> Riddell: hmm, well that worked, but for some reason the subsequent loadModule didn't seem to work
[12:47] <Kamion> Riddell: do you care? I think it's probably more important to get it unloaded to avoid the annoying popups
[12:47] <Keybuk> pitti: -ize/-ise is different depending which BE dictionary you use
[12:48] <Keybuk> Oxford prefer -ize, Cambridge prefer -ise
[12:48] <Riddell> Kamion: no, I don't care about loading it back
[12:48] <pitti> joy
[12:48] <Kamion> Riddell: righto, done then, I'll hope it's just a glitch
[12:48] <tfheen> I guess grey is british since it's Gandalf the Grey, not Gandalf the Gray.
[12:49] <Riddell> pitti: grey, -ise.  ignore the silly Oxford people
[12:49] <pitti> Riddell: I'll get gray hear while thinking about that :)
[12:50] <Keybuk> pitti: Cambridge says grey ...
[12:50] <Keybuk> David appears to have hidden my OED
[12:50] <tfheen> also, HTML only allows gray, which is annoying.  At least, it used to back in 1996.
[12:50] <Ng> tfheen: and center :(
[12:50] <tfheen> grey tended to be interpreted as green, which left me dumbfounded for a bit.
[12:51] <Riddell> I'm pretty sure CSS allows grey
[12:51] <tfheen> Riddell: HTML, not CSS.  This was back before CSS.
[12:51] <Kamion> http://www.w3.org/TR/html4/types.html says it's still only gray in HTML
[12:51] <Keybuk> pitti: OED says grey too
[12:51] <tfheen> when HTML 2.0 was the new and shiny thing.
[12:51] <Riddell> yes
[12:51] <Keybuk> so gray must be American
[12:51] <Keybuk> though both note that gray is a colour for horses
[12:51] <ogra> Keybuk, meh, ltsp-client is the first service started in rc2 ... so num_services is still 0
[12:52] <Keybuk> ogra: ?
[12:52] <tfheen> apart from the pink overload, I liked the explanation in http://www.bernzilla.com/item.php?id=232
[12:52] <ogra> Keybuk, sorry, num_steps
[12:53] <ogra> Keybuk, num_steps is initially set to 0, and the case condition breaks without adding 1 to it
[12:53] <Keybuk> yes?
[12:53] <ogra> so if ltsp-client is the first service in a runlevel num_steps is still zeroed ... and i dont get progressbar steps at all
[12:54] <Keybuk> if ltsp-client is the first service, you don't want progress steps?
[12:54] <ogra> i want them
[12:54] <Keybuk> well, you can't have them
[12:54] <Keybuk> so there
[12:54] <ogra> but the code prevents me from getting them
[12:54] <Keybuk> :)
[12:54] <ogra> well, it should add 1 to num_steps before the break
[12:54] <Keybuk> the code doesn't count the step that stops usplash, for obvious reasons
[12:54] <Keybuk> no, it shouldn't
[12:55] <Keybuk> otherwise the users will never *see* it hit 100% cause usplash gets stopped
[12:55] <ogra> well, if i make it the second service, i see a gap at the end of the progressbar
[12:55] <Keybuk> it's zero based so it hits 100% then usplash stops
[12:55] <ogra> it never gets to the full end
[12:55] <Keybuk> that's wrong
[12:55] <ogra> right
[12:55] <Keybuk> if you make it the second service, then num_steps = 1
[12:55] <ogra> but it gets to 90%
[12:55] <Keybuk> so it would reach 100% after the end of the first step
[12:55] <Keybuk> and you wouldn't see a gap
[12:56] <ogra> i can live with that for now and will make ltsp-client the second service, but i think num_steps should be at least 
[12:56] <ogra> 1
[12:56] <Keybuk> no, it shouldn't
[12:56] <ogra> lets talk about it in MV :)
[12:56] <Keybuk> otherwise you'd never see the end of the progress bar
[12:56] <Keybuk> it has to hit 100% before usplash it stopped
[12:56] <Keybuk> have you bothered to read rc?
[12:57] <pitti> tfheen: wrt. bug 60448 you had some thoughts, too; I would rotate the current .xsession-errors to .xsession-errors.prev and create a fresh .x-e on login; is that fine for you?
[12:57] <Ubugtu> Malone bug 60448 in xorg ".xsession_errors file grows out of control & saturates disk space" [High,In progress]  http://launchpad.net/bugs/60448
[12:57] <Keybuk> it tells usplash to change the progress when the script run *FINISHES*
[12:57] <Keybuk> not before it starts
[12:57] <Keybuk> so it's entirely correct that num_steps=0 if the display manager is the first thing
[12:57] <ogra> hmm
[12:57] <Keybuk> because you want no steps for that entire runlevel
[12:58] <Keybuk> I could believe there's a bug simply because it divides the progress bar up
[12:58] <ogra> anyway, i'll make it the second service for now 
[12:58] <Keybuk> it leaves the last third for the rc2
[12:58] <Keybuk> but because there's nothing in rc2, it never actually fills that final third
[12:59] <ogra> another prob (with udev i guess)
[12:59] <Keybuk> with udev?!
[12:59] <tfheen> pitti: I'd prefer to have the file be resized in-place to not put random junk files in ~
[12:59] <ogra> since i added DO_NOT_SWITCH_VT i get a long delay for usb devices
[12:59] <Keybuk> what the frak has udev got to do with anything?
[12:59] <Keybuk> *blink*
[12:59] <Keybuk> show me a bootchart
[12:59] <ogra> no keyboard or moouse input for quite some time (20-30secs)
[12:59] <Keybuk> and /var/log/udev
[01:00] <ogra> oh, there is an error on console ...
[01:00] <funman> hi
[01:01] <ogra> Keybuk, usb 4-1.2: device descriptor read/64, error -110
[01:02] <Keybuk> iz kernel boog
[01:02] <Keybuk> or probably dodgy usb cable or something
[01:02] <ogra> hmm, the client still uses -9 ... i should probably update first :)
[01:03] <pitti> tfheen: hm, weird - in my current edgy .x-e is cleaned already on login
[01:04] <ogra> pitti, 
[01:04] <ogra> ogra@edubuntu:~/devel/edgy-ltsp$ ls -lh /home/ogra/.xsession-errors 
[01:04] <ogra> -rw------- 1 ogra ogra 652K 2006-10-05 12:49 /home/ogra/.xsession-errors
[01:04] <ogra> i logged in a minute ago ...
[01:04] <ogra> here its not cleaned
[01:04] <pitti> hm, for a fresh user it is for me
[01:05] <pitti> my own is 6.9KB and looks fresh, too
[01:05] <ogra> what should clean it (note i'm not using gdm)
[01:05] <tfheen> pitti: hmm, weird.  The code doesn't look like it cleans it.
[01:05] <pitti> ogra: that's what I'm wondering, too; /etc/X11/Xsession appends only
[01:05] <dholbach> heno: replaced gok with onboard
[01:05] <pitti> maybe gdm cleans it, I'll look
[01:06] <ogra> thats wrong then :)
[01:06] <ogra> Xsession should clean it
[01:06] <pitti> a grep -r xsession-errors in /etc/ revealed nothing else
[01:06] <RicardoPerez> carlos: ping
[01:06] <carlos> RicardoPerez: pong
[01:11] <Keybuk> Kamion: do you have a moment to check over some code for me
[01:11] <Kamion> Keybuk: sure
[01:11] <pitti> I don't get it -- modifying /etc/X11/Xsession doesn't seem to have any effect 
[01:12] <pitti> seb128: does gdm do some black magic which circumvents /etc/X11/Xsession?
[01:12] <seb128> pitti: what do you mean?
[01:12] <ogra> pitti, how about adding the cleanup code to /etc/X11/Xsession.d in a separate script ?
[01:12] <Keybuk> kamion: http://people.ubuntu.com/~scott/migrate-inittab.pl.txt
[01:13] <tucoz> Hi, i am trying to track down this bug: https://launchpad.net/distros/ubuntu/+source/xserver-xorg-video-ati/+bug/52695
[01:13] <Ubugtu> Malone bug 52695 in xserver-xorg-video-ati "xorg-driver fglrx interferes with r300 dri" [Undecided,Unconfirmed]  
[01:13] <seb128> pitti: do you pick the GNOME or the default system session from gdm?
[01:14] <tucoz> I noticed that LIBGL_DRIVERS_PATH is set to the wrong path in my case. it is set to /usr/X11R6/lib/modules/dri/. do you know where to go from here, to see where that is exported?
[01:14] <pitti> ogra, tfheen: so this seems to affect Kubuntu/Edubuntu only (the bug report is from a Kubuntu user, too)
[01:15] <pitti> seb128: hm, whatever is the default for a fresh user
[01:15] <ogra> pitti, i think Xsession.d is the right place ... probably one of the xorg_common scripts should do it
[01:15] <pitti> ogra: I'm fine with changing the Xsession script, but I'd like to test it :)
[01:15] <pitti> seb128: I mean that changing /etc/X11/Xsession does not have *any* effect; it seems to be ignored when logging into gdm
[01:16] <ogra> right, if it breaks gdm that would indeed be wrong ...
[01:16] <pitti> ogra: .d is too late
[01:16] <Kamion> Keybuk: reading
[01:16] <ogra> pitti, ok
[01:16] <pitti> ogra: Xsession first creates/appends .xsession-errors and then executes .d
[01:16] <Kamion> Keybuk: I'd use an arrayref for the elements of %gettys, rather than joining them with : and having to split them up again
[01:17] <pitti> ogra: changing it won't break gdm, since gdm doesn't seem to use it in the first place :)
[01:17] <Keybuk> Kamion: yeah, I couldn't remember how to do those ;)
[01:17] <Keybuk> example?
[01:17] <Kamion> Keybuk: $gettys{$1} = [$rlevel, $process] ;
[01:18] <Keybuk> oh, [ ]  
[01:18] <pitti> seb128: I suspect that it executes /etc/gdm/Xsession, but then I wonder who cleans up ~/.xsession-erros on login?
[01:18] <Kamion> Keybuk: my ($rlevel, $process) = @$gettys{$_};
[01:18] <Keybuk> how do get stuff back out?
[01:18] <tfheen> ajmitch: regarding the mono problem on the desktop cd, if f-spot is happy from a terminal, everything's fine, right?
[01:18] <Keybuk> too much Python
[01:18] <Kamion> Keybuk: or $gettys{$_}[0]  to access single elements
[01:18] <Kamion> Keybuk: er, sorry, I think that should be @{$gettys{$_}}
[01:18] <ogra> pitti, well, if gdm would choke because the files doesnt exists or something ... was my fear
[01:19] <Keybuk> yup
[01:19] <StevenK> Kamion: I think either work.
[01:19] <Kamion> {} binds less tightly than sigils
[01:19] <Keybuk> my brain rememberd it once you showed the example
[01:19] <seb128> pitti: hum, not sure, I'm finishing lunch and I'll have a look
[01:20] <tfheen> Kamion: or $gettys{$_}->[0] , iirc
[01:20] <Kamion> tfheen: yes; $gettys{$_}[0]  is syntactic sugar for that
[01:21] <funman> do you know if gcc SSP made some regressions ?
[01:21] <funman> like packages working without the SSP, i.e. no segfaults , and triggering a stack smashing with SSP
[01:21] <Kamion> StevenK: no, only @{...} works
[01:21] <tfheen> funman: yes, sure.  emacs21, for instance.
[01:21] <pitti> a-haa
[01:22] <StevenK> Kamion: Yes, sorry, I just checked.
[01:22] <torkel> pitti: iirc "Gnome" does not run /etc/X11/Xsession, but "Default System Session" does
[01:22] <funman> tfheen: so what's wrong in that case, emacs or gcc ?
[01:22] <pitti> ogra, seb128: gdm-2.16.1/./daemon/slave.c:wipe_xsession_errors (struct passwd *pwent,
[01:22] <tfheen> funman: emacs.  One of the functions have a wrong parameter list.
[01:22] <pitti> so, gdm has its own code to wipe
[01:22] <Kamion> StevenK: otherwise it's "dereference $foo to get a list, then get the first element of that ... hold on, why does this expression start with a @?"
[01:22] <tfheen> funman: I Just Haven't Found Time To Fix It Yet.
[01:22] <ogra> pitti, ugh, even in .c
[01:22] <StevenK> Kamion: *nod*
[01:22] <funman> hmmm
[01:23] <tfheen> funman: how so?
[01:23] <funman> sorry ?
[01:23] <tfheen> funman: any particular reason for you asking your question?
[01:23] <funman> yes, problems with vlc
[01:23] <tfheen> funman: I'm not aware of SSP breaking any correct C code, though, but I haven't investigated it closely; pitti might know better.
[01:24] <funman> i couldn't reproduce on a system without SSP, and a backtrace of the stack smashing learned me nothing
[01:24] <pitti> I don't ATM, sorry
[01:24] <norber> hello, mi name is norber and i asked a question in a ubuntu-es and they don know. my english is very bad, sorry.  i have a laptop and i buy a card audio usb. I want listen a song (example dover) by the two cards audio. Is possible?
[01:24] <funman> i have little debugging experience so i may not look correctly
[01:24] <Kamion> Keybuk: ... need to get breakfast before reading the rest of this
[01:24] <funman> i emailed crimsun about that, he's the vlc package maintainer
[01:24] <Keybuk> Kamion: ok
[01:24] <pitti> torkel: doesn't seem to work for me; 'default system session' also uses the gdm one
[01:24] <Keybuk> I need to run to Tesco to get bagels, so we'll discuss it after lunch-time:)
[01:30] <sivang> ah Tesco.. if only they had that cinemon malt loaf so I could take some with me back :)
[01:30] <sivang> Keybuk: how are their bagles? the garlic bread rolls for heating up in the oven are quite nice
[01:31] <pitti> seb128: ok, nevermind then; I use xdm for testing now, it works there
[01:31] <ogra> pitti, wonderful :)
[01:31] <ogra> next time use ldm :P
[01:32] <doko_> smurf: ping
[01:32] <seb128> pitti: is gdm doing something wrong? I've not really followed on the issue I was having lunch ;)
[01:33] <ogra> seb128, its doing something on its own that should be done in Xsession
[01:33] <pitti> tfheen: ok, I'll do the truncating then for {k,edu}buntu
[01:33] <seb128> any reason why it should be done in Xsession?
[01:33] <ogra> so it was broken for non gdm users
[01:33] <tfheen> pitti: cheers.
[01:34] <ogra> seb128, for (k,x,l)dm, yes
[01:40] <pitti> seb128: well, not exactly wrong, but we cannot control the ~/.xsession-errors handling in /etc/X11/Xsession[.d]  scripts
[01:40] <seb128> pitti: should I patch the gdm code out?
[01:43] <StevenK> % head -n 1 debian/dbmail.init
[01:43] <StevenK> #!/bin/sh --posix
[01:43] <pitti> seb128: not for my sake, I don't mind deleting the previous session's .xsession-errors; tfheen might do, though
[01:43] <tfheen> pitti: it's not "OH MY GOD THE SKY IS FALLING"-bad, but I'd prefer if we didn't, yes.
[01:44] <_ion> stevenk: Wow. :-)
[01:44] <StevenK> seb128: Stupid question, if you have a second?
[01:45] <pitti> tfheen: what do you think of that:
[01:45] <pitti> # truncate ERRFILE if it is too big to avoid disk usage DoS
[01:45] <pitti> if [ "`stat -c%s \"$ERRFILE\"`" -gt 500000 ] ; then
[01:45] <pitti>   F=`tail -c 500000 "$ERRFILE"` && echo "$F" > "$ERRFILE"
[01:45] <pitti> fi
[01:45] <tfheen> pitti: I'd prefer if we saved the last N bytes.
[01:45] <pitti> with N == ?
[01:46] <pitti> I thought 0.5MB is more than enough
[01:46] <seb128> StevenK: don't ask to ask just ask
[01:46] <pepsiman> what would truncate it if I never log out?
[01:46] <tfheen> oh, but your solution will truncate it to 0 bytes when it's bigger than 500k?
[01:46] <tfheen> oh, sorry
[01:46] <tfheen> mea culpa, I can't read.
[01:46] <pitti> tfheen: no, it takes the last half MB
[01:46] <StevenK> seb128: Are you aware of any issues of font colors in progress bars?
[01:47] <pitti> I just need the F=`` echo F juggling to avoid a temporary file
[01:47] <tfheen> pitti: then it's fine; I'm obviously blind. :-)
[01:47] <tfheen> pitti: or you could just use sponge
[01:47] <pitti> tfheen: ok, great; I tested it with xdm, works fine
[01:47] <seb128> StevenK: there is a bug open on ubuntulooks about not enough contrast between text and font color
[01:47] <pitti> tfheen: sponge is in universe
[01:47] <tfheen> pitti: that's easily fixed, though.
[01:47] <pitti> tfheen: and essentially it doesn't do much else than F=``; echo $F>, does it?
[01:48] <pitti> but in general yes, sponge is useful
[01:48] <StevenK> seb128: I'm seeing strangeness on my Edgy machine - the color under the "done" part of the progress bar is white and gray.
[01:48] <tfheen> it doesn't do much else in this particular case, no.  Shells aren't too fond of null bytes and such, though
[01:49] <pepsiman> seb128: in qemu I couldn't see the edgy progress bar move at all
[01:49] <pitti> tfheen: true; well, I better use a temporary file then
[01:58] <imbrandon> doko ping
[01:59] <imbrandon> moins pitti and tfheen
[01:59] <pitti> hi imbrandon 
[02:01] <Seveas> mjg59, did you know usplash currently is rather broken? writing text and usplash_put_part generate weird-colored output
[02:06] <pitti> Keybuk: can you please approve hal (bug 56484) and cupsys (bug 54277) uploads to dapper-proposed
[02:06] <Ubugtu> Malone bug 56484 in hal "hal does not detect non-ATAPI CD-ROM drives" [Unknown,Confirmed]  http://launchpad.net/bugs/56484
[02:07] <Ubugtu> Malone bug 54277 in cupsys "cupsd can't access /var/log/cups/error_log permission denied" [High,Fix released]  http://launchpad.net/bugs/54277
[02:18] <tfheen> heno: what's happening with https://launchpad.net/distros/ubuntu/+source/casper/+bug/58836 ?  Is it still valid?
[02:18] <Ubugtu> Malone bug 58836 in casper "F5 options need to be linked to the right casper options" [Undecided,Unconfirmed]  
[02:22] <raphink> anyone has seen/worked on http://www.kde-apps.org/content/show.php?content=14779 ?
[02:26] <pitti> Riddell: bug 58636, isn't that actually a langpack issue? or are kcmlocale.mo files not shipped in the langpacks for some reason?
[02:26] <Ubugtu> Malone bug 58636 in language-pack-kde-ka "language-support-kde-ka - even then installed georgian users can't see georgian KDE UI." [Undecided,In progress]  http://launchpad.net/bugs/58636
[02:26] <pitti> Riddell: i. e. that should fix itself with the next langpack update, right?
[02:27] <Riddell> pitti: they havn't translated kcmlocale, or hadn't at the last langpack update
[02:27] <pitti> Riddell: it seems to be translated in Rosetta
[02:28] <Riddell> pitti: so it does, so yes it'll be fixed with the next langpack update
[02:28] <pitti> but daily edgy langpacks do not have kcmlocale.po, hmm
[02:28] <Riddell> pitti: for ka or all?  I'm sure I've seen it in other languages
[02:28] <pitti> I looked in -ka-base
[02:29] <pitti> Riddell: I cannot find such a file; maybe 'kcmlocale' is not the correct domain name
[02:30] <pitti> oh, silly me, it's there for other languages
[02:30] <Riddell> it was only translated for ka three days ago
[02:31] <pitti> Riddell: ok, then Rosetta probably just lags behind a bit
[02:36] <_ion> Is there a plan to move ntfs-3g to main?
[02:37] <tfheen> Riddell: Have you tried to reproduce https://launchpad.net/distros/ubuntu/+source/casper/+bug/62693 with a current daily?  IIRC, it's fixed now.
[02:37] <Ubugtu> Malone bug 62693 in casper "kubuntu accessibility features don't run" [Undecided,Unconfirmed]  
[02:37] <Riddell> tfheen: no I havn't, I'll give it a shot when I find a minute
[02:38] <tfheen> Riddell: cool, thanks.  I had a silly syntax error which probably broke it.
[02:38] <tfheen> (which is now fixed)
[02:41] <cuco> hi, i am building a package for ubuntu, which needs to create some mysql tables. on debian, i used the extra file: debian.cnf. this does not work on ubuntu. any ideas whay can i do...?
[02:42] <cuco> the question is, how do i install sql tables from postinst scripts ...?
[02:42] <tfheen> rodarvus: https://launchpad.net/distros/ubuntu/+source/casper/+bug/59618 ; should casper preseed xorg's config or should xorg look at /proc/cmdline?
[02:42] <Ubugtu> Malone bug 59618 in casper ""Safe graphics mode" doesn't use VESA" [Undecided,Confirmed]  
[02:46] <rodarvus> tfheen, I think preseeding xorg config would be a a more generic solution (as other options could be forced in the same way) - also making xorg look into /proc/cmdline would make us diverge from upstream (debian)
[02:46] <tfheen> rodarvus: ok.  Do you remember offhand what I need to preseed it with?
[02:47] <rodarvus> not from the top of my mind, I'm sorry :/
[02:47] <tfheen> np, I'll poke it myself, then
[02:48] <tfheen> hmm
[02:48] <tfheen>       if [ -n "$XFORCEVESA" ]  || [ -n "$(grep xforcevesa /proc/cmdline)" ] ; then
[02:49] <tfheen>         DEFAULT_DRIVER=vesa
[02:49] <tfheen> is there already.
[02:49] <tfheen>       fi
[02:49] <rodarvus> heh
[03:08] <jdong> aah! what on earth!
[03:08] <jdong> since when did ich8 stop working?
[03:08] <jdong> yikes... isn't kernel freeze today?
[03:09] <tfheen> it is
[03:09] <jdong> looks like bug 63516....
[03:09] <Ubugtu> Malone bug 63516 in linux-source-2.6.17 "ICH8 doesn't work" [High,Confirmed]  http://launchpad.net/bugs/63516
[03:10] <jdong> that's a pretty serious regression... will it get fixed after freeze?
[03:10] <zul> afaik ben is working regressions
[03:10] <StevenK> Phew, I have an ICH6
[03:10] <StevenK> :-P
[03:10] <zul> er...workin on regressions
[03:11] <tfheen> jdong: it's targetted for 6.10
[03:14] <Keybuk> pitti: they're on my list
[03:14] <pitti> thanks
[03:36] <tfheen> hmm, why is usplash dark blue on black?  It's not the most readable colour choice possible.
[03:37] <Keybuk> black on black?
[03:37] <tfheen> no, dark blue on black.
[03:37] <tfheen> it's possible to read, but hard.
[03:44] <dholbach> iwj: hello! can I tempt you to have a look at bug 63814? it's about a breakage of epiphany, which gives upstream a bit of pain (lots and lots of edgy users complain about crashes at bugs.gnome.org). I tried to apply the patch he was referring to, but didn't have much luck.
[03:44] <Ubugtu> Malone bug 63814 in firefox "please include patch for a highly visible crash in epiphany" [Undecided,Confirmed]  http://launchpad.net/bugs/63814
[03:45] <sivang> Keybuk: lol:
[03:45] <sivang>  * Undo Sivang's evil, evil, evil patching of things in the debian
[03:45] <sivang>     directory and just apply the patch, damnit!
[03:45] <Keybuk> Kamion: did you get a further look at my Perl?
[03:46] <iwj> dholbach: Looking at it now.
[03:47] <dholbach> iwj: Gracias.
[03:49] <iwj> The patch looks reasonable to me.
[03:49] <sivang> iwj: have you seen an issue in which everytime you run firefox it thinks the previous session was abruptly interruped and thus want sto "resotre session || ignore and start new||
[03:49] <sivang> "
[03:49] <iwj> Do you need this fixing urgently ?  If not I'll just assign myself the bug and apply the patch next time I'm fiddling with firefox.
[03:49] <sivang> iwj: ?
[03:49] <iwj> sivang: Yes, but only once when my whole system was completely hosed.
[03:50] <sivang> iwj: also, bookmarks are for some reason not working on my firefox, that is I can click 'add' but nothing happens form the add bookmark dialog
[03:50] <sivang> iwj: it's constantly reproduciable here
[03:50] <iwj> Obviously there's something wrong with your profile.
[03:51] <dholbach> iwj: the count of dups at http://bugzilla.gnome.org/show_bug.cgi?id=354790 is still bearable, I think
[03:51] <Ubugtu> Gnome bug 354790 in Mozilla interaction "crash on plugin native window destruction [@gtk_widget_destroy - ~nsPluginNativeWindowGtk2] " [Critical,Resolved: notgnome]  
[03:51] <sivang> iwj: any info I can provide to help fix the two issues?
[03:51] <dholbach> iwj: I wanted to let you know, because my own attempts failed.
[03:51] <iwj> sivang: TBH, given that I'm probably not going to have time to debug this, your best bet is to make a new profile and just copy the bookmarks across.  You could also try deleting stuff semirandomly from your profile directory.  (Take a copy of the bookmarks first.)
[03:51] <iwj> dholbach: You tried to apply that patch and failed ?
[03:52] <sivang> iwj: I already lost the bookmarks , so that's going to be easy ;-)
[03:52] <dholbach> iwj: yeah, see my last comment on the bug
[03:52] <sivang> iwj: (4-5 dist upgrades ago)
[03:52] <dholbach> iwj: but it FTBFS at another place (so it seemed to me).
[03:52] <iwj> dholbach: Oh, yes.
[03:52] <iwj> dholbach: How odd.
[03:52] <iwj> sivang: :-/
[03:52] <dholbach> iwj: maybe chpe will know what to do about it
[03:52] <smurf> doko_: pong
[03:52] <iwj> dholbach: That doesn't seem related at all.
[03:53] <dholbach> iwj: I built it in an up-to-date edgy amd64 pbuilder.
[03:53] <iwj> dholbach: Are you able to build the unpatched source ?  (I wouldn't recommend messing with this without ccache and a huge buffer cache, though.)
[03:53] <dholbach> i'll try - I'm doing bug triage in the meantime - so that's going to be fine ;-)
[03:53] <iwj> dholbach: No, don't try.
[03:54] <iwj> Let me do it.  I know all the tricks.
[03:54] <dholbach> iwj: Thanks a lot - I knew you'd be way cleverer about it. ;-)
[03:54] <iwj> I've just been through the pain and know how to avoid about half of it ...
[03:55] <dholbach> Yooohoo. :-)
[03:56] <iwj> Chase me if it gets too bad and I'll push it up my todo list.
[03:56] <Kamion> Keybuk: I'd use 'if ($idx < @job)' rather than 'if ($job[$idx] )'
[03:57] <dholbach> iwj: chpe will be happy.
[03:57] <Kamion> still looking over the rest of it
[03:58] <Kamion> sivang: IIRC moving sessionstore.js aside fixed that for me
[03:58] <Kamion> as far as I can tell firefox doesn't delete that file after restoring the session, so after one crash it bugs you about it evermore
[03:59] <sivang> Kamion: did you experience lost bookmarks as well? 
[03:59] <Kamion> sivang: n
[03:59] <Kamion> no
[04:00] <Kamion> this is for the bug where "restore session" appears all the time
[04:00] <sivang> Kamion: k, thank you
[04:00] <smurf> Would anybody like to figure out why the Live CD no longer works on an old iBook? :-/
[04:01] <Kamion> Keybuk: what's the open/close pair at the end for? could do with a comment at least
[04:02] <Keybuk> just to touch the file so upstart reloads it
[04:02] <Kamion> Keybuk: if it's just to touch the file, 'my $time = time; utime $time, $time, "/etc/event.d/$_"' is more usual
[04:03] <Keybuk> that won't cause an inotify CLOSE_WRITE event?
[04:03] <Kamion> oh, silly inotify
[04:03] <Kamion> Keybuk: do you plan to migrate stuff like sulogin, rcS, rc configuration?
[04:03] <Keybuk> I really don't see how that's possible
[04:03] <Keybuk> it would be too much of a headache to get right
[04:03] <Kamion> Keybuk: also, %ids appears to be unused apart from checking for duplicates
[04:04] <Kamion> fair enough
[04:06] <sivang> Kamion: thanks, that worked.
[04:13] <Kamion> Keybuk: otherwise, looks fine to me ...
[04:13] <simira> tfheen: behave!
[04:14] <sivang> nice, after removing the profile firefox tells me to restart ubuntu
[04:14] <tfheen> simira: it started!
[04:47] <webben> I've noticed that gnome-orca is marked as "Low urgency" on Launchpad. Is there a mechanism for expressing a desire that a
[04:47] <webben> it should be higher urgency?
[04:49] <seb128> gnome-orca is a package?
[04:49] <seb128> what does the urgency mean for the package? where do you read that?
[04:49] <StevenK> seb128: It's probably the upload details
[04:49] <webben> seb128, https://launchpad.net/distros/ubuntu/+source/gnome-orca
[04:49] <webben> on the lefthand side under "Maintainer defaults"
[04:50] <seb128> ah, that's the upload
[04:50] <seb128> the urgency setting is of no use with launchpad
[04:50] <webben> what does it mean then?
[04:50] <seb128> it's useful for Debian to determinate of fast the package has to move to testing
[04:50] <seb128> s/of/how
[04:50] <webben> that isn't related to how important the package is?
[04:51] <seb128> maybe launchpad should not display that info
[04:51] <seb128> no
[04:51] <seb128> packages have no "importance"
[04:51] <seb128> they are to main or universe basically
[04:51] <webben> then what does determine how fast a package moves to testing?
[04:52] <seb128> there is no testing
[04:52] <seb128> dapper is stable
[04:52] <seb128> nothing migrate to stable
[04:52] <seb128> and next one is edgy
[04:52] <seb128> and we upload without delay to edgy
[04:54] <webben> you mean this urgency stuff has no relevance to how ubuntu does things at all?
[04:56] <seb128> correct
[04:56] <webben> ah okay then :)
[04:56] <seb128> it's used by Debian
[04:56] <seb128> and we have no interest to change the format for Ubuntu
[04:56] <seb128> so it's around, just not useful
[04:56] <webben> i see
[04:56] <seb128> have to run for half an hour, bbl
[04:57] <webben> seb128, thanks for explaining that; bye for now :)
[04:57] <seb128> np
[05:00] <kristog> do you know if a people.ubuntu.org service is planned?
[05:05] <ogra> Kamion, i pm'd you the logs from our conversation about the edubuntu name change ...
[05:07] <ogra> i think you can revert it safely
[05:09] <Fade> hrmn. known bug that python upgrade breaks in pycentral?
[05:12] <Fade> http://pastebin.com/800753
[05:18] <janimo> pitti: hi, can you review system-config-printer and python-cups in time for RC?
[05:18] <pitti> janimo: erm, you do not seriously want that for edgy??
[05:18] <janimo> pitti: of course I do. why?
[05:18] <pitti> we are past UVF and FF and approaching RC freeze and such
[05:18] <janimo> that was the whole point of it
[05:19] <pitti> ugh
[05:19] <janimo> well it's not an UVF as it sat in universe for a while
[05:19] <pitti> that's indeed bold
[05:19] <janimo> well since there;s no other printer add gui in xubuntu there;s not much to break :)
[05:19] <pitti> janimo: I'd like to get mdz's blessing for turning our printer GUI upside down at that point
[05:19] <janimo> and it's one of the most requested pieces
[05:19] <janimo> pitti:  uhm, for xubuntu only
[05:19] <tfheen> I thought pitti enabled the web interface now?
[05:20] <pitti> tfheen: I did
[05:20] <janimo> it is not for ubunt obviously
[05:20] <pitti> janimo: hmm
[05:20] <janimo> not edgy anyway
[05:20] <janimo> pitti: did you think I want to replace gnome-cups-manager :) ?
[05:20] <pitti> janimo: well, I didn't test it at all so far (I postponed that to feisty on my personal list)
[05:21] <ogra> pitti, are we allowed to leak f-f already ? 
[05:21] <janimo> pitti: ok, I did not ever think of having that in ubuntu edgy that;s for sure. We may have had some miscommunication
[05:21] <tfheen> janimo: hard freeze is in seven days, jfyi.
[05:21] <janimo> pitti: it;s strictly for xubuntu, as right now the only way to add aprinter is via the web ui
[05:22] <janimo> tfheen: I know, but if this app is not there there's nothning in its place
[05:22] <janimo> so the risk is low
[05:22] <janimo> it is one of the most impiortant edgy xubuntu specs
[05:22] <funman> crimsun: till not there?
[05:22] <janimo> I specifically chose this route as opposed to patching gnome-cups0-manager to gtk onlyness, to avoid interfeering with ubuntu desktop
[05:22] <pitti> janimo: the point is, if we put it in main now and it screws something up, we have to support it
[05:23] <janimo> pitti: AIUI, the xubuntu bits are not 'reaaly' supported even if in main
[05:23] <janimo> there for easy CDing
[05:23] <janimo> pitti: that tool is shipped by FC6 next week by the way
[05:23] <pitti> janimo: how do you mean? we support all main things, and if there is a grave bug past release in the printer config app, we have to deal with it in -updates and such
[05:24] <janimo> so it cannot be that bad, but admittedly it may expect something else in debian
[05:24] <tfheen> that's a slippery slope once edubuntu starts to have a xubuntu ltsp modes as well, too.
[05:24] <janimo> anyway myself gauvain and others on xubuntu-devel tested it and it worked fine
[05:24] <pitti> well, I do not have a good feeling about it TBH
[05:24] <janimo> tfheen: I hope that for edgy+1 xubuntu and ubuntu printer tools will be the same
[05:25] <pitti> I'm fine with taking a look at it, but I cannot judge the releasability quality and compatibility with printer models and access modes in a short time
[05:25] <janimo> but I would not like to go another cycle without graphical 'add new printer'
[05:25] <pitti> janimo: I hope that, too
[05:25] <pitti> I so much want to get rid of g-c-m
[05:25] <pitti> that's why I really appreciated geting printer-config
[05:25] <pitti> but I never imagined it for edgy
[05:25] <janimo> pitti: so either this fedora tool or till's drake can take over in edgy +1
[05:25] <pitti> right
[05:26] <pitti> janimo: ok, as I said, I'll review it, but promotion should get past mdz
[05:26] <janimo> pitti: I thought it was clear from the start that I uploaded for wide testing for ubuntu edgy+1 but also for xubuntu edgy
[05:26] <janimo> after all it was speccied in paris :)
[05:26] <janimo> pitti: as for supported, jbailey said they are not staffed for xubuntu support
[05:26] <janimo> so it is in main but not supported for customers
[05:27] <janimo> the annuncements also specify community supported
[05:27] <pitti> oh, I wasn't aware that we make that kind of distinction
[05:27] <janimo> pitti: well, not written anywhere as far as I can tell, it's just the way it is AIUI
[05:27] <ogra> tfheen, thats still at least one release away ...
[05:28] <janimo> I do not mind as long as CDs can be rolled
[05:28] <tfheen> janimo: which spec would that be?  I can't see any edgy-targeted specs which are relevant?
[05:28] <tfheen> ogra: hence "slippery slope"
[05:28] <pitti> seb128: I'd appreciate your comment on u-devel wrt. 'Edgy "Crash Reports"'
[05:29] <ogra> pitti, just point at edubuntu, "they're rewriting kdeedu so why should we support non gnome apps" :P
[05:29] <seb128> pitti: I was going to reply
[05:29] <janimo> tfheen: https://features.launchpad.net/distros/ubuntu/+spec/xubuntu-printer-config
[05:30] <pitti> seb128: ah, thank you
[05:30] <seb128> np
[05:30] <seb128> pitti: does apport still limit the dump to 100M?
[05:30] <pitti> seb128: I'm not sure at that point what to do TBH
[05:30] <pitti> seb128: no, the default is 200 MB now
[05:31] <tfheen> janimo: it's not targeted for any release, though
[05:31] <seb128> pitti: my main issue with apport is that bugzilla get over 500 ubuntu bugs a week atm and we are already cracking under bug flood without those
[05:31] <pitti> seb128: right
[05:31] <seb128> pitti: there is no way we would cope with that amount of bug
[05:32] <pitti> seb128: if gnome is happy with getting b-b reports, can cope with it, and the workflow works fine, there's little reason to change it at that point
[05:32] <tfheen> janimo: in the future, _please_ make sure that anything you want in is actually targetted.  Stuff which isn't targetted (be it bugs, features, whatever) fall off our radar and we end up using lots of time rescuing it.
[05:32] <tfheen> janimo: also, implementation status "unknown" at this point is, well, not useful.
[05:32] <janimo> tfheen: ok, I somehow thought in parsi that accepted means targeted at edgy
[05:33] <janimo> and then forgot about the  issue
[05:33] <janimo> sorry
[05:33] <tfheen> janimo: and it's not approved either?
[05:33] <pitti> seb128: I guess we need an one-click gnome upstream bug reporting and automatic symbolic stack traces before we switch that?
[05:33] <pitti> ok, I'm off for a bit
[05:33] <janimo> tfheen: I guess I should have kept track of the specs closer
[05:33] <tfheen> janimo: I'm not trying to pick on you; it's just that those seemingly-minor things end up causing us lots of grief.
[05:34] <janimo> for this specific one imlementation meant, package fedora tool and m,assage ot work without some deps, and wait to get on the CD
[05:34] <seb128> pitti: right
[05:34] <ogra> tfheen, and that specs needed to be implemented before FF
[05:34] <tfheen> janimo: wouldn't the web UI be acceptable for edgy and we can get this into edgy+1?
[05:34] <janimo> tfheen: I know you are not. nevertheless I am sorry for not being more disciplined about it :)
[05:34] <ogra> but as long as its xubuntu only i dont mind ...
[05:34] <janimo> tfheen: the web interface scred people in dapper
[05:35] <tfheen> janimo: also, you not being an employee means I can't shout that loudly at you for not following procedures. :-P
[05:35] <sivang> hehe
[05:35] <tfheen> janimo: ok, so you have something you're _confident_ that works which is just now working except for it being in universe, is that the situation?
[05:36] <janimo> tfheen: right
[05:37] <tfheen> janimo: ok, let's hear what pitti says when he's back, then.
[05:37] <tfheen> pitti: ^^
[05:37] <janimo> he said he'll wait on matt's approval IIRC
[05:39] <janimo> Gloubiboulga: ping
[05:41] <Keybuk> OH, WOW
[05:41] <Keybuk> I HAVE A GEM OF A BUG
[05:41] <Keybuk> tfheen: are you listening? :)
[05:41] <tfheen> Keybuk: loud and clear.
[05:41] <Keybuk> you use the usplash TEXT_URGENT thing on the Live CD so that when it shuts down/restarts, it says "Press ENTER" ?
[05:41] <tfheen> yes
[05:41] <Keybuk> well, imagine for a moment that the user is a bit lazy
[05:42] <Keybuk> and left the install sitting there for, oh, a few minutes
[05:42] <Keybuk> what do you think happens? :)
[05:42] <tfheen> Keybuk: I change the timeout to a day, iirc.
[05:42] <Keybuk> usplash definitely timed out
[05:42] <Keybuk> and I was sitting at a little _ cursor
[05:42] <tfheen> let me see
[05:42] <heno> I've seen that too
[05:43] <tfheen> heno: did you see me asking you about accessibility status?  If you could look at the casper bug about it, that'd be good
[05:43] <heno> tfheen: I'll look
[05:44] <tfheen>     /sbin/usplash_write "TIMEOUT 86400"
[05:44] <tfheen>     /sbin/usplash_write "TEXT-URGENT Please remove the disc, close the tray (if any)"
[05:44] <tfheen>     /sbin/usplash_write "TEXT-URGENT and press ENTER to continue"
[05:44] <Keybuk> could the console blanker kill usplash?
[05:44] <tfheen> hmm, maybe.
[05:44] <Keybuk> uh
[05:44] <Keybuk> dude
[05:44] <Ng> I have  abug I need to report that we've noticed on pretyt much all of our server tests of the live CD where rebooting just leaves us at a blinking _
[05:44] <Keybuk> no, I see what happened
[05:45] <Keybuk> you rolled a 32-bit int :)
[05:45] <Ng> is that likely to be the same thing?
[05:45] <tfheen> Keybuk: 86400 should fit comfortably into a 32 bit int.
[05:45] <Keybuk> 86,400,000,000 is rather bigger than INT_MAX
[05:45] <Keybuk> timeout is stored internally in usex
[05:45] <tfheen> GNR
[05:45] <Keybuk> uh sec!
[05:45] <tfheen> why?
[05:45] <Keybuk> because it uses usleep() ?
[05:45] <tfheen> and seriously, it needs a way to say "don't time out, ever"
[05:46] <tfheen> timeout 0 used to do that
[05:46] <Keybuk> yeah, timeout 0 did that, until Seveas broke it
[05:46] <Kamion> usplash_down still sends TIMEOUT 0
[05:46] <Seveas> ?
[05:46] <Seveas> what did I break?
[05:46] <Keybuk> Kamion: no it doesn't, I fixed that
[05:46] <Kamion> ah, my checkout is out of date
[05:46] <Kamion> Keybuk: "fixed"
[05:46] <Kamion> surely usplash_down was correct and usplash was wrong :)
[05:47] <Keybuk> seb128: GNOME Setting Daemon fuckage on fresh edgy install - known?
[05:47] <Keybuk> Kamion: one was easier to fix ;P
[05:47] <ogra> *g*
[05:47] <seb128> Keybuk: depending
[05:47] <Keybuk> seb128: on?
[05:47] <ogra> religious usplash wars 
[05:47] <Seveas> I'm more worried about color b0rkage in usplash since r82
[05:47] <seb128> Keybuk: there is a bug happening one time every 40 boots
[05:47] <Seveas> it breaks all themes 
[05:47] <Keybuk> seb128: this was the second boot
[05:47] <tfheen> Keybuk: we could just make it use a long and only lesser arches would have to care.  Or fix timeout 0
[05:47] <Kamion> usplash is so much the village bike
[05:48] <Kamion> or the core-dev bike
[05:48] <seb128> Keybuk: mdz got it once on desktopCD boot and never since
[05:48] <Keybuk> tfheen: <g> "lesser arches" being anything not amd64?
[05:48] <tfheen> Kamion: we should build it a shed.
[05:48] <Keybuk> seb128: I just got it on a vmware install
[05:48] <tfheen> Keybuk: hey, ia64 will make do as well
[05:48] <seb128> Keybuk: do you have anything useful to the logs? is it reproducible?
[05:48] <Keybuk> seb128: which logs?
[05:48] <seb128> Keybuk: ~/.xsession-errors
[05:48] <ogra> .xsession-errors ?
[05:48] <Keybuk> nothing in there
[05:48] <Kamion> or make it a uint64_t; we have C99
[05:48] <seb128> k
[05:49] <Keybuk> well, just some C chatter
[05:49] <Kamion> int64_t rather
[05:49] <ogra> seb128, i've seen it too on ltsp ... 
[05:49] <Keybuk> Kamion: not unless you compile -std=c99 ?
[05:49] <Keybuk> or has that changed now
[05:49] <seb128> Keybuk: we have one bug being that gst_init() seem to fail sometimes, I'm going to look at that one soon
[05:49] <Kamion> and hope it doesn't overflow the long in struct timeval tv_sec
[05:49] <tfheen> Kamion: sure, that's fine, but I'd actually rather just have us fix timeout 0 or timeout -1 to work.
[05:49] <ogra> but only very rarely and not reproducable
[05:49] <Kamion> tfheen: yeah
[05:49] <Kamion> Keybuk: we could do that if necessary
[05:49] <tfheen> (either's fine, but both blow up ATM, iirc)
[05:49] <heno> tfheen: could you give me a bug # ? I can't see anything obvious
[05:49] <Keybuk> Kamion: I agree with tollef here
[05:50] <Kamion> yeah, so do I really
[05:50] <Seveas> is there anyone besides mjg59 with an svgalib fetish around?
[05:50] <Ng> Keybuk: tfheen: sorry, not intending to pester, but did you see what I said above? should I still file it?
[05:50] <Keybuk> (though I never understood why that timeout 0 was in splash_down to start off with)
[05:50] <giftnudel> tfheen: not -1, so that you can use unsigned numbers, you don't need negative timeouts
[05:50] <tfheen> heno: https://launchpad.net/distros/ubuntu/+source/casper/+bug/58836
[05:50] <Ubugtu> Malone bug 58836 in casper "F5 options need to be linked to the right casper options" [Undecided,Unconfirmed]  
[05:51] <tfheen> giftnudel: seriously, we only care about timeouts which are in the range of "seconds" to "a couple of minutes" or "never".
[05:51] <tfheen> it's not like we're strained for bits.
[05:52] <tfheen> Ng: it's mostly fixed already, apart from usplash being silly.
[05:52] <tfheen> Ng: it's actually the same bug we're talking about.
[05:52] <Ng> tfheen: that's fine, thanks :)
[05:53] <heno> tfheen: there are no recent updates on that bug. I need more context. I was off IRC for a bit, testing, rebooting, etc.
[05:53] <Keybuk> seb128: seems to be intermittent, yes
[05:53] <giftnudel> seb128: gnome-settings-daemon doesn't start after logout, is that known?
[05:53] <seb128> giftnudel: yeah, nothing is supposed to start after logout
[05:54] <seb128> things are supposed to stop on logout
[05:54] <giftnudel> seb128: ;) , I mean on second logon
[05:54] <seb128> I have the issue sometimes, not every time though
[05:54] <giftnudel> hmm, I have it everytime ...
[05:54] <funman> are there any deadline for update packages of universe ?
[05:55] <seb128> Keybuk, giftnudel: I'll patch gnome-settings-daemon to have some verbose log and will ping you back then to get a log about the issue
[05:55] <funman> i just fixed a serious bug in vlc
[05:55] <seb128> funman: one week ago
[05:55] <seb128> funman: ah? bug fixing, still plenty of time
[05:55] <funman> nice :)
[05:55] <giftnudel> seb128: ok, I have time ...
[05:55] <elmo> seb128: do you know offhand what package the network properties dialog comes from?
[05:55] <seb128> giftnudel: have time for?
[05:55] <funman> i'm waiting for crimsun to come back and i'll inform him
[05:55] <giftnudel> seb128: for testing
[05:55] <seb128> elmo: gnome-system-tools
[05:56] <elmo> seb128: danke schoen
[05:56] <seb128> de rien ;)
[05:56] <giftnudel> seb128: (the next few days)
[05:56] <seb128> giftnudel: a few min, I finish that reply on ubuntu-devel about GNOME bugs
[05:56] <seb128> k, cool, thank you
[05:56] <giftnudel> I have that too
[05:56] <eracc> Hi folks. I asked this in #ubuntu but never saw an answer so decided I'd ask people more likely to know. Why are there no webmin packages in Dapper nor in Edgy?
[05:57] <tfheen> heno: is it still valid?  If so, what needs to be fixed?
[05:57] <Kamion> eracc: 'cos they were removed from Debian
[05:58] <eracc> Ouch. I'm looking to switch our servers to ubuntu server but I rely on webmin a lot. :-(
[05:58] <Kamion> eracc: see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343897
[05:58] <Ubugtu> Debian bug 343897 in ftp.debian.org "ftp.debian.org: Please remove all webmin related packages" [Wishlist,Closed]  
[05:59] <heno> tfheen: I haven't tested a CD since you fixed that syntax bug a few days ago. I saw it in the changelog now though so I'll DL and test
[05:59] <tfheen> heno: thanks.
[05:59] <eracc> I guess I can get the package from webmin.com then. Thanks, Kamion.
[05:59] <tfheen> heno: RC freeze is in a week and I would hate us to not have good accessibility because of some stupid bug somewhere, hence me pestering you now rather than in a week. :-)
[06:00] <heno> tfheen: yes, please pester about this stuff!
[06:00] <heno> It sort of balances out my pestering :)
[06:00] <tfheen> heno: if you could get kubuntu accessibility tested too, that'd be excellent.
[06:01] <heno> yep, will do
[06:01] <tfheen> heno: it's also so I don't become a blocking point -- I'm starting to do full-time RM work on monday or so, and won't have time to hack casper then
[06:01] <heno> right
[06:03] <Gloubiboulga> janimo, quick pong
[06:06] <Kamion> eracc: I believe that's the best and recommended approach at the moment, yes
[06:08] <tfheen> seb128: http://librarian.launchpad.net/2924235/casper-1.56-no-eject-hotkey.patch should work for disabling the "eject" hotkey, right?
[06:08] <janimo> Gloubiboulga: sent you a mail 
[06:09] <seb128> tfheen: I think so
[06:09] <janimo> Gloubiboulga: the idea is to get multibuild.mk in as it is, and polish afterwards
[06:09] <seb128> tfheen: keyboard key you mean, right?
[06:09] <tfheen> seb128: yes.
[06:09] <janimo> Gloubiboulga: or we can miss RC
[06:09] <tfheen> seb128: https://launchpad.net/distros/ubuntu/+source/casper/+bug/34643 is the bug
[06:09] <Ubugtu> Malone bug 34643 in Baltix "Live CD can be inadvertently ejected via hotkey" [Undecided,Unconfirmed]  
[06:09] <seb128> tfheen: because if you press on the drive button it's going directly to g-v-m
[06:09] <Gloubiboulga> janimo, ok
[06:09] <tfheen> seb128: can we turn that off?  Having people eject the live cd while it's running is.. bad.
[06:10] <funman> crimsun: i hope you'll be happy to know that the vlc bug is know fixed in svn repository
[06:10] <Gloubiboulga> janimo, I'm away for a moment, I'll ping Martin & Seb when I'll be back
[06:10] <janimo> Gloubiboulga: it does not affect other packages and the ones that could use it wll have a few extra lines no?
[06:10] <janimo> at least until a cleaner way is found
[06:10] <Gloubiboulga> janimo, right
[06:10] <seb128> tfheen: ask pitti about that one he probably knows better, it's hal,g-v-m magic
[06:10] <tfheen> seb128: ok, thanks.
[06:10] <seb128> np
[06:10] <seb128> the patch you pointed should work fine for the keyboard multimedia key
[06:10] <tfheen> yeah, understood.
[06:11] <tfheen> pitti: how can I make pressing the hardware eject button not do anything?  Having people eject the live cd while it's running makes the world blow up.
[06:11] <janimo> Gloubiboulga: sure, thanks
[06:11] <tfheen> hmm, should we mail u-d-a about the string freeze?
[06:19] <seb128> tfheen: should the drive be locked while something is using it?
[06:20] <seb128> tfheen: I mean, eject usually doesn't work if you are using the CD
[06:20] <tfheen> seb128: yes, it has lots of stuff mounted from it.
[06:20] <tfheen> seb128: it's just for the desktop CD.
[06:20] <ogra> tfheen, you can force lock it from casper 
[06:20] <ogra> i can give you some python snippet
[06:20] <tfheen> ogra: casper can't use python.
[06:21] <tfheen> C or shell, please.
[06:21] <tfheen> and it won't help if something unlocks it..
[06:21] <ogra> hmm, no idea how that works in shell or C though 
[06:21] <tfheen> what does the python code look like?
[06:21] <ogra> we use it for the opposite in ltsp clients to force unlock it
[06:22] <ogra> fcntl.ioctl(f, CDROM.CDROM_LOCKDOOR, 0)
[06:22] <ogra> very simple 
[06:22] <kristog> tfheen: do you have time for speak about bluetooth?
[06:22] <ogra> its locked if you set it to 1
[06:22] <funman> or cat /proc/sys/dev/cdrom/lock
[06:22] <tfheen> kristog: I don't know much about bluetooth, but sure.
[06:23] <tfheen> ogra: 'k, thanks.
[06:23] <ogra> tfheen, it might be that pitti just sets the sysctl bit for it now
[06:23] <pitti> tfheen: hm, funny; it took two releases to make the CD eject button work properly, and all sorts of people complain that it didn't :)
[06:23] <tfheen> pitti: haha. :-)
[06:23] <pitti> tfheen: in fact I find that quite useful - I often eject the CD and just reboot, instead of shutting down :)
[06:24] <kristog> thom: ah sorry, i saw your name in the changelog of bluez-utils :(
[06:24] <kristog> ops
[06:24] <kristog> tfheen: ^
[06:24] <tfheen> kristog: well, I uploaded it for something or another, I can't remember.  Anyway, what's your question?
[06:25] <pitti> tfheen: well, if there's a good reason to disable the button, we can certainly hack a gconf key into g-v-m to inhibit ejection
[06:25] <pitti> but frankly, it's a hardware button, why shouldn't it work?
[06:25] <tfheen> pitti: https://launchpad.net/distros/ubuntu/+source/casper/+bug/34643 is the bug.
[06:25] <Ubugtu> Malone bug 34643 in Baltix "Live CD can be inadvertently ejected via hotkey" [Undecided,Unconfirmed]  
[06:26] <kristog> tfheen: ATM bt-suite in ubuntu edgy is useless, if you try to scan for devices nothing will discover
[06:27] <kristog> tfheen: 59222, https://launchpad.net/bugs/56651
[06:27] <Ubugtu> Malone bug 56651 in bluez-utils "Missing passkey-agent binary" [Undecided,Confirmed]  
[06:27] <tfheen> kristog: oh, that.  I've been meaning to fix that, actually.
[06:27] <bluefoxicy> http://bluefox.kicks-ass.org/stuff/bluefox/images/edgy-20061005-1.png
[06:27] <kristog> tfheen: ah ok, so you are working on them :) cool
[06:28] <tfheen> Seveas: Ubugtu is buggy.  When it gets URLs like the one above it shouldn't say "baltix", it should pick the ubuntu one.
[06:28] <tfheen> kristog: so many bugs so much time.. That I am intending to fix it doesn't mean I'll get around to it
[06:28] <ogra> tfheen, i asked for that ages ago ... Seveas just likes balitx :P
[06:28] <_ion> Hmm, apport-retrace -d fails with KeyError. I'll check Malone a bit later.
[06:28] <kristog> tfheen: uh :) ehhee :)
[06:29] <pitti> _ion: I bet I know the reason
[06:29] <pitti> _ion: and I also bet that you didn't yet upgrade to 0.26
[06:29] <AstralJava> Sheesh, devs, I'm sorry to burst into this like I didn't know you're busy enough, but what have you done to Edgy?! It's insanely fast, and still manages to use less battery than Dapper did! Thank you for making protable computing so much more enjoyable! :)
[06:29] <_ion>     needed_deps.add((pkg, dependency_versions[pkg] ))
[06:29] <_ion> ii  apport         0.26           automatically generate crash reports for deb
[06:29] <tfheen> kristog: send me a mail about it and I'll try to get it tomorrow?
[06:29] <tfheen> kristog: tfheen@ubuntu.com
[06:29] <pitti> _ion: you didn't click on 'report bug', but ignored the crash and then tried to apply apport-retrace to it, right?
[06:29] <AstralJava> protable == portable
[06:30] <kristog> tfheen: ok, thank you
[06:30] <pitti> _ion: oh, ok, then I lost my bet, sorry :)
[06:30] <_ion> pitti: I clicked report bug, and then ran apport-retrace -s -d /var/crash/_bin_sh.1005.crash
[06:30] <pitti> AstralJava: oh, sorry, we'll get that fixed :-P
[06:30] <pitti> _ion: yeah, there's probably a bug in that function which figures out the dependencies
[06:30] <_ion> (I tested it with sh -c 'kill -SEGV $$', /bin/sh hasn't actually crashed. )
[06:31] <kristog> tfheen: i will try to send you patches for them.
[06:31] <pitti> _ion: ugh, I bet there's a realpath() missing somewher
[06:31] <pitti> _ion: can you please file a bug? I cannot care for it right now
[06:31] <_ion> pitti: Yes, as i said, will do it a bit later.
[06:32] <AstralJava> pitti: Hands off!! :)
[06:32] <Seveas> tfheen, launchpad changed again and I haven't yet modified the bots
[06:32] <Seveas> launchpad devs should stop doing that
[06:33] <ogra> Seveas, liar ... youre a secret balix dev ... admit !
[06:33] <_ion> Do the bots screenscrape the launchpad website?
[06:33] <Seveas> _ion, no
[06:34] <Seveas> there is a nice rfc822 version of bug overviews
[06:34] <Seveas> (after I repeatedly and loudly complained that screenscraping broke all the time)
[06:35] <Seveas> but changing Unknown to Undecided confuses ubugtu
[06:37] <mdz> pitti: printer stuff -> if it only affects Xubuntu, it's janimo's call
[06:37] <pitti> mdz: ok, if we can have something potentially badly broken in main
[06:37] <mdz> Burgwork,cbx33: cbx33 has a launchpad account but the name on it didn't match the name used in the changelog
[06:38] <Burgwork> mdz, ah
[06:38] <mdz> tfheen: I've been working around bug 62495 using advanced search, and now I don't even notice (just changed my bookmark)
[06:38] <Ubugtu> Malone bug 62495 in malone "Milestone bug list doesn't sort properly" [Undecided,Confirmed]  http://launchpad.net/bugs/62495
[06:38] <mdz> tfheen: this also has the advantage of not showing the spec noise
[06:45] <bddebian> Heya folks
[06:47] <ogra> Kamion, the fuzzy translation bug with server/console mode was gfxboot-theme ? 
[06:47] <ogra> or was it d-i i should file against ?
[06:56] <pitti> hmm, is the announcement of the new apport-retrace with super powers something appropriate for u-d-announce?
[06:58] <Kamion> ogra: gfxboot-theme-ubuntu
[06:58] <ogra> thanks
[07:00] <Kamion> oh, dear lord, it's a hand-rolled po file parser, no wonder
[07:02] <ogra> oh, youre already looking at it ?
[07:02] <Kamion> yeah
[07:02] <ogra> so should i not file the bug ?
[07:04] <Kamion> ogra: nope, no need now, I've got it fixed
[07:04] <Kamion> ogra: thanks for the reminder
[07:04] <ogra> cool,. thanks 
[07:04] <ogra> so i declare edubuntu free of known bugs !
[07:04] <ogra> lets see about the unknown ones :P
[07:06] <bddebian> heh
[07:13] <sivang> janimo: it works like a charm
[07:18] <janimo> sivang: nice, one less reason to use win
[07:19] <sivang> janimo: indeed. However the bank site uses popups, and it won't work :-/
[07:22] <Kamion> ok, first cut at the tasksel fixes for usplash complete
[07:22] <Kamion> but I have to go out now before testing it; night all
[07:24] <ogra> night Kamion and thanks for all the fixes today :)
[08:10] <Ng> out of interest, when is the next dapper langpack release likely to be? I read something earlier about it being embargoes atm?
[08:11] <pitti> Ng: I uploaded them to -proposed today, Keybuk or Kamion have to approve them
[08:11] <Ng> ah cool
[08:11] <pitti> Ng: after they do, they'll be uploaded to -updates 7 days after
[08:11] <Ng> someone accosted me earlier about dd segfaulting and I was a bit confused until I tracked down the bugreport on a language pack
[08:11] <Ng> thanks :)
[08:16] <bSON> hi
[08:18] <givr1> pitti: do you think that the David Zeuthen patch to support Fuse could meet edgy ? 
[08:18] <bSON> is there any reason why https://wiki.ubuntu.com/AlwaysEnableUniverseMultiverse is in review so long?
[08:23] <givr1> pitti: i could understand that it could be considerate as a feature, just wanting to know
[08:26] <givr1> s/wanting/wanted
[08:35] <JB[away] > moin
[08:35] <dholbach> Treenaks: I made some changes to your bluetooth/todo suggestion
[08:51] <Treenaks> dholbach: ok, great :)
[08:52] <dholbach> Treenaks: I saw too many items like that on "TODO lists" already
[08:53] <Treenaks> dholbach: Whatever it takes to get it done ;)
[08:53] <Treenaks> dholbach: I want to browse in the train ;)
[08:53] <Treenaks> s/browse/irc/ :P
[08:53] <dholbach> I just meant to say "don't dump an item like that on a todo list, if you mean to get it done". :-)
[08:54] <S0me1> hi everyone
[08:54] <S0me1> how i can send an idea to ubuntu team?
[08:55] <funman> just write it down
[08:55] <S0me1> ok
[08:56] <LaserJock> putting it on the wiki (wiki.ubuntu.com) is good
[08:56] <S0me1> i see ok thanks 
[08:56] <Treenaks> dholbach: oh, sorry then :)
[08:57] <Kamion> funman: because obviously we read everything that is written everywhere? :-)
[08:57] <funman> at least you did
[08:57] <desrt> Kamion; aren't you supposed to be sleeping?
[08:57] <Kamion> desrt: at 8pm?
[08:57] <funman> well nice Kamion, will you fill it ?
[08:57] <desrt> Kamion; oh.  i see what happened.  nevermind :)
[08:58] <desrt> Kamion; in that case, do you know why usplash flickers on shutdown?
[08:58] <Kamion> desrt: nope, no idea I'm afraid
[08:58] <desrt> shame.
[08:58] <desrt> i wonder if init is whacking the process when it does the "sending SIGTERM/KILL to everyone"
[08:59] <Kamion> my guess for somebody who would know would be Keybuk
[08:59] <desrt> nod.  i've been meaning to ask him but he hasn't been around much
[08:59] <desrt> then i saw you were talking about usplash last night so i thought you might know :)
[09:01] <dholbach> iwj: you had any luck with the rebuilding of firefox on edgy amd64?
[09:11] <tfheen> mdz: using an advanced search doesn't give me the option of reordering the columns though
[09:23] <mdz> tfheen: you mean multicolumn sort?
[09:23] <mdz> you can sort on one column using the drop-down
[09:23] <tfheen> mdz: oh, true, that's so not-obvious that changing that and pressing "search" just changes the already-present search result.
[09:23] <feAR`> hi
[09:23] <feAR`> First of all, I am sorry for my English. 
[09:23] <dholbach> Kamion, Keybuk: can you promote python-virtkey to main? it's a dependency of onboard (which is in main and seeded already).
[09:23] <tfheen> it also doesn't display assignee, which is useful.
[09:23] <feAR`> Am...Who is responsible for Ubuntu cd's autorun?
[09:23] <feAR`> :)
[09:23] <mdz> feAR`: mvo
[09:23] <feAR`> where could I find him? :}
[09:23] <Kamion> dholbach: done
[09:23] <dholbach> Kamion: thanks!
[09:24] <mdz> feAR`: what do you want to ask him?
[09:26] <feAR`> mdz, we are creating free software cd (something like theopencd.org) but just for Lithuanians, and I am the project coordinator.
[09:26] <feAR`> I would like to ask how to change the size of k-meleon window
[09:26] <feAR`> I can't find where to set the window size..
[09:26] <mdz> feAR`: oh, that's a completely different thing
[09:26] <mdz> you're talking about the Windows autorun
[09:26] <mdz> feAR`: that's heno
[09:27] <mdz> feAR`: https://launchpad.net/people/henrik
[09:27] <bluefoxicy> ...... my ~/.evolution/addressbook directory is 419 megs
[09:27] <bluefoxicy> I never even used the addressbook.
[09:29] <feAR`> gh, how to find him
[09:29] <_ion> bluefoxicy: You know how Evolution's UI somewhat resembles Microsoft Outlook? Well, that's another feature they're imitating.
[09:29] <bluefoxicy> _ion:  lol
[09:30] <feAR`> ok
[09:41] <wasabi_> Hmm. Some people need to make cups printing programs connect directly to remote printers, and store queues in ~/.printers.conf
[09:41] <wasabi_> With the obvious entries for ipp://localhost/printer residing in there.
[09:42] <wasabi_> So authentication to the printer happens appropiatly.
[09:49] <ajmitch> wasabi_: good, someone else put in a request for libpam-krb5 updates :)
[09:49] <wasabi_> Cool.
[09:49] <wasabi_> What's changed anyways?
[09:49] <ajmitch> bug 64189
[09:49] <Ubugtu> Malone bug 64189 in libpam-krb5 "UVF: please sync from debian" [Medium,Needs info]  http://launchpad.net/bugs/64189
[09:49] <wasabi_> I submitted a patch for that, almost a year ago, heh
[09:49] <wasabi_> For something.
[09:49] <wasabi_> Dunno if it ever made it in, since it seems to have no upstream.
[09:49] <ajmitch> bug fixes, mainly
[09:50] <ajmitch> apparantly there is an upstream still
[09:50] <wasabi_> Yeah, 3 of em.
[09:50] <wasabi_> Heh;.
[09:50] <ajmitch> wonderful
[09:50] <wasabi_> RedHat maintains their own fork.
[09:50] <ajmitch> that's extra-special
[09:50] <wasabi_> Wonder if anybody fixed the service_err result.
[09:50] <wasabi_> So I can do service_err=1 auth_err=2
[09:51] <wasabi_> Used to return auth_err when the KDC was unreachable.
[09:51] <ajmitch> right, 2.x has plenty of changes for caching & realm-specific stuff
[09:51] <wasabi_> Nice.
[09:51] <wasabi_> I use pam_ccreds.
[09:51] <ajmitch> so we can hopefully get this in
[09:52] <wasabi_> It's nice to have processing jump to it when service_err is returned from krb5, and jump to invalidate the cache when it returns auth_err
[09:54] <jdong|laptop> tseng: do you know where that dapper mono repository is?
[09:55] <ajmitch> wasabi_: we can always try & get a patch into edgy
[09:55] <wasabi_> I'll have to review the state it's in currently.
[09:55] <wasabi_> I'll check it out when I get home.
[09:55] <ajmitch> ok
[09:58] <tfheen> iwj: what's happening with 57161?
[10:01] <geser> does bug 52803 qualify to be fixed for edgy?
[10:01] <Ubugtu> Malone bug 52803 in gsfonts-x11 "insufficient dependency on xfonts-utils" [High,Confirmed]  http://launchpad.net/bugs/52803
[10:02] <tfheen> seb128: https://launchpad.net/distros/ubuntu/+source/control-center/+bug/22876 is targetted for 6.10, but you say "probably won't be fixed for edgy".  Which one is correct?
[10:02] <Ubugtu> Malone bug 22876 in control-center "There is no way to control which sound device or mixer the keyboard shortcuts use" [Unknown,Confirmed]  
[10:03] <seb128> tfheen: I didn't remember about the patch when I added the comment, I'll have a look at the patch for edgy
[10:04] <tfheen> seb128: thanks.
[10:04] <seb128> tfheen: no need to bother with the desktop them, there is about 10 of them and I've then in control ;)
[10:04] <seb128> s/desktop them/desktop bugs
[10:04] <Ng> hmm, does anyone happen to know how rhythmbox identifies usb devices as music players?
[10:04] <tfheen> seb128: ok, thanks, I won't then. :-)
[10:04] <tfheen> seb128: but I'll roar at you if they're not all gone in six days. :-P
[10:04] <seb128> Ng: probably the hal informations about the device
[10:04] <seb128> tfheen: fine with me ;)
[10:05] <tfheen> seb128: thanks
[10:05] <Ng> seb128: ok thanks, I'll poke around the device manager to see why my new mp3 player isn't showing up ;)
[10:06] <Ng> aha, there's a portable_audio_player capability and category
[10:18] <jdong|laptop> zul: with ubuntu's xen, can you change the distribution of RAM while the system/VM's are running?
[10:18] <jdong|laptop> (smack me if I'm asking retarded questions  about Xen0
[10:18] <zul> no i think you have to restart it but try it out
[10:18] <jdong|laptop> so you have to specify how much RAM you give to dom0 ahead of time?
[10:18] <jdong|laptop> the last time I used Xen I found that real irritating
[10:18] <zul> yep
[10:18] <jdong|laptop> mmkay, I'll set aside a test box
[10:18] <jdong|laptop> can amd64 hosts run i386 guests?
[10:19] <ajmitch> you can shrink dom0's ram usage
[10:19] <LaserJock> hehe, that reminds me of a certain thread in -devel
[10:19] <ajmitch> but you can't increase beyond what it was booted with
[10:20] <jdong|laptop> ajmitch: ah, so I can boot dom0 to use all available RAM then shrink it as I need to boot children?
[10:20] <ajmitch> yes
[10:20] <ajmitch> it just happens
[10:20] <funman> dom0 just can access all RAM anyway
[10:21] <zul> right time to go home
[10:21] <funman> and then you'll allocate some dom0's free RAM to domUs
[10:23] <jdong|laptop> ah ok
[10:23] <jdong|laptop> and are the wiki's documents on how to use Xen still valid for Dapper?
[10:23] <funman> url?
[10:24] <funman> i don't know if ubuntu changed xen tools
[10:24] <ajmitch> probably similar enough
[10:24] <jdong|laptop> https://wiki.ubuntu.com/XenOnEdgy?highlight=%28xen%29
[10:26] <jdong|laptop> final question, will Xen process and close 120 outstanding backports requests for me while I take my nap? :D
[10:27] <ajmitch> jdong|laptop: no
[10:27] <jdong|laptop> lol
[10:27] <jdong|laptop> have a nice day, everyone
[10:36] <AnAnt> I was just running apt-get dist-upgrade, and it told me that will install some indian & far eastern fonts, why is that ?
[10:37] <AnAnt> what will a non asian do with all those fonts ?
[10:38] <funman> watch, not read, asian texts
[10:38] <AnAnt> funman: and ?
[10:38] <funman> and nothing, that's all
[10:39] <AnAnt> funman: 50 extra MB to watch asian text that I won't understand ?
[10:39] <funman> exactly
[10:40] <funman> can you see what will make these fonts install ?
[10:40] <AnAnt> ubuntu-desktop I think
[10:41] <AnAnt> because when I chose to do upgrade instead of dist-upgrade, it told me that it will hold ubuntu-desktop & ubuntu-minimal back
[10:42] <sbalneav> If you're browsing the internet, and get directed to an Asian site, with asian characters, the proper thing to do would be to display the characters correctly, as opposed to a web page full of gibberish characters.  Therefore, to do the correct thing, you need the fonts.  This isn't really a development question though, is it?
[10:43] <funman> AnAnt: i don't know if you already experienced
[10:43] <funman> but it's very funny to let a friend use your computer, and make that he can use his native language
[10:44] <AnAnt> k, I just found that it is less than 50 MB
[10:44] <AnAnt> maybe even half that size
[11:15] <geser> Kamion: do I still need an ACK from a MOTU for a sync request in universe when I already have a confirmed UVF exception?