[12:45] <jono> hey
[12:49] <thiago_>  hi... how can i install all include files, sources, and libs, for develop, like in slackware...???
[12:49] <cheatersrealm> any ubuntu-gnome developers on? I have a patch that I would like to see rolled into ubuntu on gnome-keyring.  ( http://bugzilla.gnome.org/attachment.cgi?id=66495&action=view )
[12:49] <gnomefreak> thiago_: please ask that in #ubuntu  this is not a support channel
[12:49] <pygi> thiago_, all?? #ubunt
[12:49] <pygi> #ubuntu*
[12:49] <pygi> cheatersrealm, file a bug and attach patch pls?
[12:49] <thiago_> ok, thanks :D
[12:50] <thiago_> sorry too
[12:50] <cheatersrealm> pygi: I'm having trouble patching against ubuntu (I'm new to it) and the patch linked there (I think) is for another version of gnome
[12:51] <cheatersrealm> pygi: file a bug and link?
[12:51] <pygi> cheatersrealm, link to bug report where that patch is attached?
[12:51] <cheatersrealm> k
[12:51] <pygi> cheatersrealm, no,no, tell me the link so i could see for which version is it
[12:51] <cheatersrealm> pygi: http://bugzilla.gnome.org/attachment.cgi?id=66495&action=view
[12:52] <pygi> cheatersrealm, well, that's the patch :P But the bug report where that patch was attached? :)
[12:52] <cheatersrealm> ahh
[12:52] <cheatersrealm> sorry
[12:52] <cheatersrealm> http://bugzilla.gnome.org/show_bug.cgi?id=331003
[12:53] <Ubugtu> Gnome bug 331003 in ask dialog "Don't bring up multiple authentication windows for same thing" [Normal,Unconfirmed]  
[12:53] <cheatersrealm> I was pasting that but I just copied and pasted the patch to a wget so I lost it
[12:53] <cheatersrealm> :)
[12:54] <pygi> cheatersrealm, hm, seems that patch would need some modification to work for an applicationa sking for the same resource multiple times
[12:55] <cheatersrealm> pygi: right, but it would solve my problem
[12:55] <cheatersrealm> it asks for the master password multiple times
[12:55] <cheatersrealm> it's on loading up rhythmbox for me
[12:55] <cheatersrealm> because my library is hosted from a smb share mounted in nautilus
[12:55] <pygi> also, there is no version of gnome which this patch is applied to
[12:56] <pygi> hm, right
[12:56] <pygi> open the patch on malone, point to patch and see what happens
[12:56] <pygi> I can't be sure for which version this is
[12:56] <pygi> altought probably 2.14 as Suse is running that (I think so at least) and they ship this patch
[01:02] <cheatersrealm> so I'm seeing a similar bug relating to network-manager in the ubuntu bugs  https://launchpad.net/distros/ubuntu/+source/network-manager/+bug/31286
[01:02] <Ubugtu> Malone bug 31286 in network-manager "Displays repeated keyring dialogs on resume from suspend" [Unknown,Fix released]  
[01:07] <cheatersrealm> pygi: any ideas on what I should do?
[01:08] <pygi> cheatersrealm, aha, report a bug :)
[01:08] <cheatersrealm> pygi: start a new bug?
[01:08] <pygi> yup
[01:08] <cheatersrealm> ok
[01:08] <cheatersrealm> should I also link to the gnome patch as well?
[01:09] <cheatersrealm> and the 'similar' problem I found in ubuntu's bug repo?
[01:09] <cheatersrealm> ok
[01:09] <cheatersrealm> I'm searching for more gnome keyring bugs, but if I can't find anything better, that's what I'll do
[01:13] <ichi> hey, anyone a dev who can help me to try to catagorize this bug? I'm not sure where it belongs in a bugtracker.
[01:17] <ichi> There is a bug which I'm not sure where it goes under. The bug is, if my first set of bootsectors aren't correct, they need to be zeroed out. When I zero out the drive for a few seconds, then install grub it works. If I don't zero out, I see "GRUB" on boot and nothign happens. installs in the future work fine after its been zeroed out.  So, is this a bug in Grub, or is it marked as a hard drive error? Could Grub be fixed, or co
[01:17] <ichi> uld tools be requested for inclusion to zero out drive?
[01:17] <ichi> The install works fine if I install lilo, however I know grub works differently. Or, this could be a grub-install bug.
[01:17] <ichi> so, what do I file it under in the tracker?
[01:20] <LaserJock> go for grub then, I guess. it can be moved latter if needed
[01:20] <ichi> LaserJock: yeah, but is it a grub bug? Should be be detecting if the first boot blocks are screwed?
[01:20] <cheatersrealm> sigh, launchpad is being slow to e-mail me my registration url
[01:21] <LaserJock> ichi: I have no idea, but if you put it on Launchpad somebody more knowledgeble than me can take a look
[01:21] <ichi> mmm, true.
[01:21] <bluefoxicy> Q:  Should Ubuntu look at mounting /proc nosuid?
[01:22] <bluefoxicy> (yes this is probably dumb now since the vuln in question has been fixed...)
[01:22] <_tsume> bluefoxicy: :)
[01:23] <bluefoxicy> _tsume:  what are you smiling about?  I'm just reading stuff from a few days ago I haven't been paying attention to
[01:24] <_tsume> bluefoxicy: oh.
[01:24] <bluefoxicy> (more LWN stuff, I'm subscribed so I might as well use it huh)
[01:26] <Kamion> bluefoxicy: that's been asked with respect to the Debian installer too; I think it would make sense to do it, but I'm in two minds about whether the change belongs in the installer (writing to /etc/fstab) or in the init script that mounts /proc
[01:27] <bluefoxicy> Kamion:  I would say in fstab would make most sense.
[01:27] <bluefoxicy> That's traditionally where such things go.
[01:28] <elmo> the kernel already marks proc as nosuid and nodev
[01:28] <bluefoxicy> it's also somewhat easy to update that line if it's the default line using cat, grep, awk, and sed
[01:28] <elmo> and mounting proc nosuid in fstab doesn't actually work
[01:28] <bluefoxicy> proc on /proc type proc (rw,nosuid)
[01:28] <bluefoxicy> elmo:  re doesn't have an effect or breaks mount?
[01:28] <elmo> doesn't survive reboots on dapper
[01:29] <Kamion> bluefoxicy: but the problem with fstab is that it doesn't affect upgrades
[01:29] <Kamion> so I'm sort of inclined towards the two-pronged approach - just do both
[01:30] <Kamion> elmo: oh
[01:30] <Kamion> hmm, interestinng
[01:30] <bluefoxicy> Kamion:  I was thinking some upgrade package would fix the line but *shrug*
[01:30] <Kamion> I suspect some init script does mount -t proc proc /proc or equivalent
[01:31] <Kamion> rewriting /etc/fstab on upgrade seems like a bad idea, although of course we're having to do that anyway for UUIDs
[01:31] <elmo> and like I said, I'm 99% sure it's moot, part of the fix in the kernel was to force proc nosuid and nodev
[01:31] <Kamion> but I'd like to do as little as possible to it
[01:31] <bluefoxicy> yeah it is.
[01:32] <bluefoxicy> like I said, vuln in question has been fixed anyway.
[01:41] <bluefoxicy> God I'm bored.
[01:41] <LaserJock> go fix something then
[01:41] <bluefoxicy> nothing's breaking on my system
[01:42] <LaserJock> there are a ton of bugs on LP that need to be triaged
[01:55] <elmo> does someone want to monkey/cowboy a server seed change for me?
[01:59] <elmo> err, nm
[03:01] <bddebian> Howdy
[03:02] <bluefoxicy> hi
[03:04] <bluefoxicy> Keybuk: Was that you working on a new init?
[03:05] <bddebian> Hello bluefoxicy
[03:10] <Keybuk> bluefoxicy: yes
[03:12] <bluefoxicy> Keybuk:  Any chance there's a good, clean way to get ltrace/strace run on things during boot, or any other generic watch-this-process tool?  Or is there already a quick and dirty way to profile system boot?
[03:12] <Keybuk> what kind of profiling are you trying to do ?
[03:12] <bluefoxicy> It'd be nice to push a few buttons, set a few config options, and have the next boot spit out profiled output :>
[03:13] <bluefoxicy> Keybuk: http://lwn.net/Articles/192214/ if you have a LWN subscription.
[03:13] <bluefoxicy> I'm looking at repeating that guy's tests in the future, without going in and modifying the kernel or whatever.
[03:13] <Keybuk> I'd change /etc/inittab so that
[03:14] <Keybuk> si::sysinit:/etc/init.d/rcS
[03:14] <Keybuk> becomes strace /stc/init.d/rcS
[03:14] <Keybuk> etc.
[03:14] <Keybuk> maybe some thin shell script to log the output somewhere (you'll need a writable space)
[03:14] <bluefoxicy> ah.  Yeah /tmp is often writable enough, or /var/tmp
[03:15] <Keybuk> neither is writable that early
[03:15] <Keybuk> you may need to use /dev
[03:17] <bluefoxicy> nods.  Now the question is how do I order and cleanly report it.  *reads man pages*
[03:19] <bddebian> Ack, another sync...
[03:45] <crimsun> they're not really merges.
[03:45] <bddebian> They aren't?
[03:46] <crimsun> no, they're syncs with Debian Sid but retaining our version
[03:47] <bddebian> So I shouldn't be requesting syncs from Debian?
[03:47] <crimsun> for...?
[03:47] <bddebian> Things like trigger
[03:48] <crimsun> that's fine
[03:48] <crimsun> why?
[03:48] <bddebian> Trying to clean up this list: http://merges.ubuntu.com/universe-manual.html
[03:50] <bddebian> Am I wasting my time as always?
[03:50] <crimsun> sync looks fine unless the icon wasn't carried over
[03:51] <bddebian> It was
[03:51] <crimsun> then it's fine.
[03:51] <crimsun> -> -motu next time ;-)
[03:51] <bddebian> OK
[03:51] <bddebian> Heya Hobbsee
[03:52] <Hobbsee> hi bddebian 
[03:54] <tritium> hey folks
[03:54] <bddebian> Heya tritium
[03:54] <zul> hey Hobbsee 
[03:55] <Hobbsee> hi zul, ti
[03:55] <Hobbsee> hi zul, tritium 
[03:55] <tritium> hi Hobbsee, bddebian 
[03:56] <bluefoxicy> wow that's a pain in the ass.
[03:58] <bluefoxicy> ..... should combining -c, -ff, and -o (specifically) with strace produce null output
[03:58] <bluefoxicy> -c -ff has output; -ff -o has output; -c -o has output; -c -ff -o creates an empty file.
[04:01] <_tsume> !op
[04:01] <_tsume> no op list?
[04:01] <_tsume> drat :)
[04:02] <bluefoxicy> yeah I'm gonna file two bugs on this, the first being that strace gives null output when -c -ff -o are combined; the second being that strace -ff -o filename produces a file named filename for whatever process it first traces and filename.pid for all children (the man page says that EACH PROCESS TRACED gets filename.pid)
[04:13] <bluefoxicy> ARGH *smacks copy/paste for being broken*
[04:23] <hub> hi
[04:23] <hub> on #ubuntu-motu I have been told that we no longer ship *.la files in -dev pacakges
[04:23] <hub> is that true?
[04:24] <hub> libgk2.0 seems to still have them in the -dev package
[05:05] <fabbione> morning
[05:06] <bddebian> Hello fabbione
[05:07] <Hobbsee> hi fabbione!
[06:09] <joejaxx> is ther anyone here willing to donate some of their time and talking to me in pm about livecd generation from seeds?
[06:19] <joejaxx> hmm maybe not then
[06:23] <LaserJock> joejaxx: it's not a very active time of day for this channel
[06:24] <joejaxx> yeah i guess not
[07:08] <pitti> Good morning
[07:08] <Hobbsee> hi pitti!
[07:10] <ajmitch> morning pitti 
[07:11] <desrt> word up, all
[07:12] <ajmitch> good day, desrt 
[07:14] <desrt> my feet hurt.
[07:14] <desrt> but they are happy
[07:15] <desrt> including some light rock climbing
[07:21] <linuxboy_> desrt: sorry, but having sore feet is a support issue. Please ask about it in #ubuntu
[07:21] <linuxboy_> ;)
[07:21] <Hobbsee> hehe
[07:23] <linuxboy> ^^^ that was Vhata's joke
[07:23] <Vhata> (which I discreetly decided not to make)
[07:24] <desrt> linuxboy; glare.
[07:33] <fabbione> is gdb known to be broken in edgy?
[07:34] <fabbione> Starting program: /usr/bin/gdb 
[07:34] <fabbione> Failed to read a valid object file image from memory.
[07:35] <pitti> fabbione: it worked quite well for me recently
[07:36] <fabbione> pitti: this is as this morning upgrade...
[07:36] <fabbione> pitti: x86
[07:38] <pitti> fabbione: ok, I try again after today's dist-upgrade
[07:39] <fabbione> pitti: thanks
[07:39] <pitti> fabbione: (however, today's upgrade doesn't bring anything that's related to gdb)
[07:40] <fabbione> pitti: i know. i didn't point my finger at gdb as root caude
[07:40] <fabbione> cause
[07:40] <fabbione> but as symptomps
[07:40] <fabbione> bah that
[07:41] <pitti> fabbione: ah, new libglib2.0 -- iz gtk bug, for sure
[07:41] <fabbione> LOL
[07:41] <pitti> elmo: good morning
[07:53] <bluefoxicy> hmm.  What the hell is spawning 1 process every 2 seconds
[07:57] <bluefoxicy> the process being spawned is sh... what's spawning it...
[08:04] <fabbione> quick C question
[08:05] <fabbione> assuming i have a string that ends in /
[08:05] <fabbione> if that's true i want to strip /
[08:05] <fabbione> how can i do that easily?
[08:05] <fabbione>         if (optind < argc && argv[optind] )
[08:05] <fabbione>                 strncpy(mo->dir, argv[optind] , PATH_MAX);
[08:05] <fabbione> mo->dir is a mount point
[08:05] <pitti> l = strlen(s); if (s[l]  == '/') { s[l]  = 0; }    ?
[08:05] <fabbione> but i want to make sure that it doesn't end in /
[08:05] <Lathiat> just cut the last character off set it to null?
[08:06] <Lathiat> what pitti said :)
[08:06] <fabbione> perfect :)
[08:06] <fabbione> thanks
[08:06] <Lathiat> altho if your doing a strncpy anyway
[08:06] <Lathiat> you could always just copy 1 char short of strlen()
[08:06] <pitti> Lathiat: that would miss the test
[08:06] <fabbione> Lathiat: that will break
[08:07] <Lathiat> oh sorry i read "assuming.." and assumed the string was already known to have a /
[08:07] <Lathiat> didnt properly read the next line
[08:07] <Lathiat> :)
[08:09] <pitti> fabbione: gdb is still working properly after today's dist-upgrade; however, I'll check again after reboot (new kernel and such)
[08:09] <pitti> WTF???
[08:10] <pitti> now /etc/fstab has 10 copies of my environment
[08:10] <Hobbsee> heh
[08:11] <Hobbsee> how many was it supposed to have, pitti?
[08:11] <crimsun> /var/lib/dpkg/info/  has a suspicious kernel-image-2.6.8-11-amd64-generic.postinst
[08:11] <pitti> zzzzzzzzzero
[08:11] <crimsun> err, sorry, wrong computer
[08:12] <Hobbsee> pitti: heh...great
[08:12] <crimsun> right, it's libvolumeid0.postinst
[08:12] <fabbione> pitti: you win!
[08:13] <pitti> http://librarian.launchpad.net/3547983/fstab <= *shudder*
[08:14] <imbrandon> pitti: ouch
[08:15] <Hobbsee> holy sugar.
[08:15] <Hobbsee> grumble.  where's keybuk when you need him?
[08:15] <Hobbsee> ah, it's not late enough in the day.
[08:18] <bluefoxicy> Hobbsee:  I still think you're strange for being up before noon :P
[08:18] <Lathiat> pitti: sweet
[08:18] <Hobbsee> bluefoxicy: heh.  it's currently 4pm, anyway
[08:18] <Lathiat> looks like some copies of 'mount' too?
[08:18] <pitti> Lathiat: 'mount'?
[08:18] <bluefoxicy> Hobbsee:  oh right.
[08:18] <Lathiat> oh, dchroot, never
[08:19] <pitti> Lathiat: I only removed the environment blocks, now it's ok
[08:19] <Lathiat> just multiple copies of the output
[08:19] <pitti> Lathiat: well, I hope that'll still boot with the uuid stuff :)
[08:19] <pitti> Lathiat: no, I have 3 chroots
[08:19] <Lathiat> oh i see
[08:19] <Lathiat> before each chroot
[08:19] <Hobbsee> pitti: machines that boot are so overrated, really.
[08:19] <Lathiat> is the environment
[08:19] <Lathiat> when theres so much text its hard to see the dchroot difference
[08:19] <Lathiat> :)
[08:20] <pitti> Hobbsee: I boot it every day, so I value it :)
[08:20] <Hobbsee> pitti: heh.  how boring :P  why not just leave it on, anyway?
[08:20] <Lathiat> i had a machine upgraded from breezy to dapper that didnt see a reboot for about 2 months ;p
[08:20] <pitti> Hobbsee: because it would just waste energy for no good reason
[08:20] <bluefoxicy> pitti:  btw, for problem reports, you should report SIGILL as well, since you can get that if something screws up the instruction pointer and puts you halfway into an instruction in executable memory
[08:20] <bluefoxicy> (thanks pipacs for that insight)
[08:20] <pitti> bluefoxicy: I do
[08:21] <Hobbsee> pitti: that's a point
[08:21] <pitti> bluefoxicy: in fact, everytime the kernel would dump core, it calls my script
[08:21] <bluefoxicy> cool.
[08:22] <pitti> bluefoxicy: right, the spec is pretty outdated wrt to that; thanks for the reminder
[08:24] <pitti> fabbione: hm, after this dist-upgrade I get strange messages from /bin/pwd; something is corrupted here (my gdb works, though)
[08:26] <fabbione> pitti: hmmmm it smells like FS corruption to me
[08:26] <fabbione> none of my dist upgrades are borked that way
[08:26] <pitti> fabbione: no, chdir'ing out and back into the dir where I was fixed it
[08:26] <pitti> fabbione: it seems it lost track of inodes in the current dir, or something
[08:26] <pitti> anyway, I'll check after a reboot
[08:27] <bluefoxicy> speaking of that, glibc should detect double-free():  http://rafb.net/paste/results/JsrGSo30.html
[08:28] <bluefoxicy> which is another hack-glibc-to-trigger-problem-reports situation
[08:29] <bluefoxicy> (it's also got some heap corruption detection so it may scream on malloc() if the allocation chains are damaged)
[08:36] <fabbione> pitti: 
[08:36] <fabbione>         if (modir[l]  == '/') {
[08:37] <fabbione> this one seems to never match
[08:37] <fabbione> but i did check strlen and the string and it should
[08:37] <fabbione> but then
[08:37] <fabbione>         printf("MODIR: %s %s, mo-dir: %s\n", modir[4] , modir[5] , mo->dir);
[08:37] <Vhata> fabbione: l-1
[08:37] <fabbione> util.c:168: warning: format '%s' expects type 'char *', but argument 2 has type 'int'
[08:37] <Vhata> the first character is [0] 
[08:38] <fabbione> oh feh
[08:38] <fabbione> right
[08:38] <fabbione> thanks
[08:38] <Vhata> ell minus one
[08:38] <pitti> fabbione: fabbione you use strncpy(), right? do you make sure that the string is properly 0-terminated?
[08:38] <pitti> fabbione: argh, indeed, l-1; my bad
[08:39] <fabbione> pitti: yes i do use strncpy for that too
[08:49] <dholbach> good morning
[08:49] <highvoltage> good morning, dholbach 
[08:49] <dholbach> hey highvoltage
[08:50] <pitti> moin dholbach 
[08:50] <dholbach> hey Martin!
[09:06] <sivang> morning
[09:07] <Vhata> hi
[09:09] <Hobbsee> hi sivang!
[09:09] <sivang> hey Hobbsee :)
[09:09] <Vhata> is it morning?  what's average([ member.getTimezone() for member in channels["#ubuntu-devel"] .getMembers() ] )   ?
[09:10] <Hobbsee> Vhata: 42.
[09:10] <Vhata> morning, then.
[09:10] <pygi> sivang, yay :)
[09:11] <sivang> pygi: hey dude
[09:11] <pygi> sivang, hey, glad to hear from you :)
[09:11] <pygi> I already started to worry :P
[09:14] <sivang> pygi: check your email :)
[09:16] <pitti> hi sivang 
[09:17] <pygi> sivang, I already did :)
[09:22] <pygi> sivang, we've got some very nice ideas for libburn :)
[09:23] <sivang> pygi: cool, do you have a wiki or some sort of shared editing space so folks can read about it ?
[09:24] <pygi> sivang, not yet really, I got the trac thingy, I lack domain and then all will be ready
[09:25] <pygi> The trac have built-in wiki, so ... :)
[09:26] <ajmitch> are people working on code yet?
[09:27] <pygi> ajmitch, which code? :P
[09:27] <ajmitch> you mentioned libburn
[09:27] <pygi> currently, we are evaluating code, getting bugs, bla,bla :)
[09:27] <ajmitch> so that's a no :)
[09:27] <pygi> :P
[09:31] <dholbach> ogra, infinity, pitti: the 'select text from the terminal' but should be fixed with the new version, enjoy :)
[09:32] <infinity> dholbach: Is htis a bug I reported months ago, or one I never reported at all, cause I don't rememebr it. :)
[09:32] <infinity> Also, lag is horrible for typos.  Ugh.
[09:33] <dholbach> infinity: oh - a couple of people complained that they could not do selections bigger than one screen - I thought you complained about it too
[09:33] <infinity> Oh, I might have.  I just got bitten by that (repeatedly) last night.
[09:33] <infinity> Yay for fixing it.
[09:33] <dholbach> new vte should make you happy
[09:33] <infinity> You are my hero, as always.
[09:33] <infinity> Well, mvo is my hero, but he hasn't done anything for me lately, so you're the new mvo.
[09:34] <dholbach> gracias - but your hero should be behdad :-)
[09:34] <ajmitch> evening infinity 
[09:34] <pitti> dholbach: which particular one? the small size limit or the breakage with non-ASCII chars?
[09:34] <pitti> hey infinity 
[09:35] <dholbach> pitti: selections bigger than one screen
[09:35] <pitti> ah, that one. nice
[09:35] <infinity> Hey pitti, mvo.
[10:24] <dholbach>  /v<tab>/c<tab>  is not  /var/cache  any more *whine* - it will take me ages to get used to that
[10:24] <Vhata> what is it?
[10:25] <Lathiat> use zsh and make it complete with the first match (with 'ca' likely to be the first match) :)
[10:25] <infinity> Why did we invent another top-level in /var, instead of using something like /var/cache/crashdata or something?
[10:25] <dholbach> infinity: good question
[10:26] <pitti> infinity: it's FHS
[10:26] <infinity> pitti: Oh, FHS defines /var/crash?  Whack.
[10:27] <infinity> Ahh, so it does.  I take it back, then.
[10:28] <Mithrandir> they should rather go to /var/cache/crash or something, IMO.
[10:29] <pitti> I don't mind the particular path, I just thought it would be nice to follow FHS
[10:30] <hungerW> Why is there SHELL='/bin/sash' in fstab now?!
[10:31] <hungerW> Or TERM='xterm'?
[10:31] <Lathiat> hungerW: its a bug
[10:31] <pitti> hungerW: bug 53991
[10:31] <Ubugtu> Malone bug 53991 in udev "uuid conversion writes environment into fstab" [Critical,Unconfirmed]  http://launchpad.net/bugs/53991
[10:31] <hungerW> Ah, thanks. I was seriously confused:-)
[10:31] <Lathiat> hrm this UUID conversion stuff
[10:31] <pitti> hungerW: me too
[10:32] <hungerW> Should it use UUID for LVM volumes, too?
[10:33] <hungerW> Is the UUID generated while formating? I am asking since I format /tmp on each reboot...
[10:33] <Lathiat> why dont you just use tmpfs for /tmp ?
[10:33] <hungerW> Lathiat: Why should I?
[10:34] <hungerW> Lathiat: I have 10G tmp, I doubt that I can stuff that into ram.
[10:34] <Lathiat> heh
[10:34] <Lathiat> what on earth do you do in /tmp? :)
[10:34] <Lathiat> plus it can swap out :)
[10:35] <hungerW> Lathiat: Store DVD images of linux distros that I did not manage to burn yet, etc.
[10:35] <Lathiat> and so the power spontaneously goes and you have to redownload it? :)
[10:35] <pitti> Lathiat: I often use /tmp for temporary stuff which requires lots of disk space
[10:36] <hungerW> Lathiat: Well, basically my /tmp is encrypted with a random key. So I have to format it on reboots to make it useable.
[10:36] <pitti> Lathiat: in order to avoid getting cruft in my backups (and DoSing my network connection)
[10:36] <hungerW> pitti: Same reasoning here:-)
[10:36] <pitti> Lathiat: something like 'check if our current kernel or OpenOffice has a patch
[10:40] <hungerW> I do not have any non-LVM volumes in fstab, so I should not need that stuff.
[10:41] <Lathiat> does it hurt?
[10:41] <hungerW> Lathiat: I think it will.
[10:41] <Lathiat> howso?
[10:42] <hungerW> Lathiat: I use lots of encrypted partitions, so I doubt that the UUID will work with that.
[10:42] <Lathiat> then you should file a bug? :)
[10:42] <fabbione> hunger: no it won't change
[10:42] <hungerW> Lathiat: Some of those are encrypted with random keys and reformated on reboot. I am very sceptical that this will work with UUIDs.
[10:43] <fabbione> oh well reformat yeah
[10:43] <fabbione> that will make problems
[10:43] <fabbione> hungerW: file bugs
[10:43] <Lathiat> its hard to know what your customly reformatting tho
[10:43] <hungerW> plus it is not needed since LVM does make sure that the drives "match".
[10:43] <Lathiat> but i mean thats a pretty side case
[10:43] <Kagou> hi
[10:44] <hungerW> LVM uses its own UUID stuff to find its PVs.
[10:44] <fabbione> hungerW: there is a difference between volume id and fs id
[10:44] <fabbione> but yes, it is still pretty pointless with LVM
[10:45] <hungerW> fabbione: What is the UUID anyway? A volume ID or a FS ID?
[10:45] <fabbione> you have uuid for both
[10:45] <fabbione> but the one in fstab is clearly the fs id
[10:46] <fabbione> lvm uses volume id to rebuild the vg
[10:46] <hungerW> fabbione: Thanks.
[10:46] <hungerW> fabbione: Yeap. But it does make sure that the LVs show up with a well defined name... which is pretty similar to the by-uuid stuff udev does.
[10:47] <fabbione> hungerW: yes exactly, but the UUID is nothing more than a symlink that is resolved at mount time. so it doesn't change anything for you
[10:47] <fabbione> there is no performance hit or stuff like that
[10:47] <hungerW> fabbione: agreed.
[10:51] <hungerW> fabbione: It is just that /dev/mapper/vg0-ubuntu_usr is way better to recognise as my ubuntu /usr than UUID={someNumbersAndLetters}.
[10:53] <fabbione> hungerW: i don't disagree but you are not taking into account a few things
[10:53] <fabbione> this is just an upgrade path and you can just revert the change in fstab (it's all commented)
[10:53] <fabbione> when you start doing manual lvm stuff, you don't use UUID by default
[10:54] <fabbione> you do it.. well manually
[10:54] <fabbione> and the conversion script did run once...
[10:54] <fabbione> it won't or shouldn't run again
[10:56] <hungerW> fabbione: You are right, I will still write a bugreport about this.
[10:56] <hungerW> fabbione: Especially since no fstab.dpkg-old is left around:-(
[10:59] <fabbione> hunger: right, there are still the comments inline tho (when it works.. hi pitti!)
[11:00] <hungerW> fabbione: Yeap. It was not hard to get back to the original state:-)
[11:06] <ogra> dholbach, yippie, thanks
[11:09] <Kamion> joejaxx: we don't generate the live filesystems directly from the seeds - we generate metapackages from the seeds (see the ubuntu-meta source package) and build live filesystems basically by just installing the appropriate metapackages in a chroot and calling mksquashfs
[11:12] <ogra> YAAY .... upstream included nearly all of our gnome-screensaver patches ... !
[11:12] <ajmitch> excellent
[11:12] <fabbione> not bad
[11:12] <ajmitch> less work for you in the future :)
[11:12] <ogra> yup
[11:12] <pygi> ogra, nice nice :)
[11:13] <fabbione> pitti: https://www.redhat.com/archives/cluster-devel/2006-July/msg00212.html
[11:14] <fabbione> pitti: ^^ 2 days of debugging to get tehre
[11:14] <fabbione> and reboot
[11:14] <fabbione> +s
[11:14] <fabbione> i don't think i did EVER rebooted a machine so often
[11:14] <infinity> Okay, WTF?  Why is my fstab sprinkled with random junk from my environment?
[11:14] <fabbione> bug 53991
[11:14] <Ubugtu> Malone bug 53991 in udev "uuid conversion writes environment into fstab" [Critical,Unconfirmed]  http://launchpad.net/bugs/53991
[11:15] <infinity> Ahh, special.
[11:15] <fabbione> infinity: aren't we all?
[11:15] <fabbione> special..
[11:15] <infinity> Somehow I doubt any effort will be made to clean that up, so I guess I'll just fix it by hand.
[11:15] <pitti> fabbione: ah, nice
[11:16] <fabbione> now... time to add gfs/gfs2 support to mount to call the proper helper
[11:16] <fabbione> or mount /dev/foo /mnt will be.. disastrous
[11:18] <Kamion> it's due to set $LINE with accidentally-empty $LINE
[11:34] <Kamion> right, udev fix uploaded
[11:38] <shawarma> Keybuk not around today?
[11:42] <fabbione> shawarma: he went to sleep around our 3am
[11:42] <mvo> Kamion: can I nag you with the promotion of libgksu2? it blocks the build of the new gksu
[11:42] <shawarma> fabbione: So did I. :-)
[11:43] <fabbione> shawarma: and i woke up at 4am...
[11:43] <fabbione> did you? :P
[11:43] <shawarma> fabbione: Not entirely. Has the baby arrived?
[11:44] <slomo> hi pitti :)
[11:44] <shawarma> fabbione: Or are you just the kind of person who gets up at 4 voluntarily?
[11:44] <mvo> hello slomo
[11:44] <Hobbsee> shawarma: the heat :P
[11:44] <slomo> hi mvo 
[11:45] <shawarma> Hobbsee: Oh, right.
[11:45] <Kamion> mvo: does it not need a main inclusion report?
[11:45] <shawarma> ARGH! Totally lost track of time. gotta run!
[11:45] <fabbione> shawarma: no baby yet... i have to wake because of the heat :)
[11:45] <Kamion> pitti: ^-- ?
[11:45] <sivang> hey slomo 
[11:45] <mvo> Kamion: no, I talked to pitti, its just a renamed libgksu1.2 with a changed api
[11:45] <pitti> Kamion: it's merely a new version of libgksu (renamed source package)
[11:45] <Kamion> oh ok
[11:46] <Kamion> mvo: promoted
[11:46] <mvo> Kamion: thanks!
[11:50] <sivang> pygi: http://bazaar.launchpad.net/~ubuntu-dev/hubackup/ubuntu
[11:50] <sivang> pygi: ^^ use this instead.
[11:50] <sivang> pygi: that's a fresh branch, without all the ~300 revisions
[11:50] <sivang> pygi: can you branch from there ?
[11:50] <seb128> does somebody knows about "cdrecord needs to be runned with sudo to blank a CD"? is that a linux issue?
[11:51] <Kamion> sivang: (not that it's any of my business, but why create a fresh branch? deliberately killing off history is usually bad)
[11:52] <stub> Launchpad will be going down in 15 minutes for its regular code update. Estimated downtime will be 10 mins.
[11:52] <sivang> Kamion: I have the history in another branch backed up in 3 different locations, I did that to split up load when branching, pushing an dpulling (it's still much faster that way, even from supermirror)
[11:53] <sivang> Kamion: I realize it's a bad thing to do, but also the long revision is due to me commiting between very small changes, to be able to go back when I Started development
[11:53] <Kamion> sivang: that means you will be unable to merge from the branch on the supermirror to your private branch, surely
[11:53] <sivang> Kamion: I feel this history is not needed anymore for further development, and if we need it we can always poke the other branches, what do you think?
[11:53] <lifeless> sivang: many small changes is good, why do you say its a problem ?
[11:53] <ogra> seb128, no, that behavior was patched out long ago from the debian package ... if it does that, its a bug
[11:54] <Kamion> I think it's crazy and wrong
[11:54] <Kamion> and I think you'll regret it later
[11:54] <Kamion> as will people trying to work out why changes were introduced
[11:54] <sivang> lifeless, Kamion : it felt wrong, but it made bracnhing and pushing to supermirrors fast fast
[11:55] <Kamion> bzr's performance will improve
[11:55] <sivang> (I started with pushing the whole history, then gave up as it wanted to do it for several hours)
[11:55] <lifeless> sivang: upgrade to knits
[11:55] <lifeless> sivang: nothing should take hours with knits
[11:55] <sivang> lifeless: okay, the branch was already in knits, let me retry and try work with you performance issues I encounter.
[11:58] <pygi_> sivang, please post me branch again
[11:58] <pygi_> I got dc/ed
[11:58] <sivang> pygi_: use the other one, it's okay
[11:58] <pygi> sivang, just post it pls :)
[11:58] <seb128> ogra: what do you mean? that was an Ubuntu patch?
[11:59] <sivang> pygi: http://mercury.linuxguru.net/~sivan/hubackup--main
[11:59] <sivang> ogra: it's set suid or something to make it work no?
[11:59] <pygi> that's old one :-/
[11:59] <sivang> pygi: no that's okay, the ubuntu-dev one is wrong
[11:59] <sivang> pygi: I need to fix it 
[12:00] <pygi> sivang, ok, branching
[12:00] <sivang> stub: LP going offline means supermirror as well ?
[12:01] <ogra> seb128, it was a debian patch, short before warty ... that was when upstream abandoned linux 
[12:01] <ogra> seb128, i'm pretty sure pitti knows more ...
[12:01] <seb128> ogra: so that's likely to be due to the sync with Debian?
[12:02] <seb128> the package didn't change to Debian for ages apparently
[12:02] <ogra> i guess so ... probably they dropped the patch
[12:02] <ogra> hmm
[12:03] <pygi> sivang, do we want QT interface for edgy?
[12:03] <pygi> or rather do we have time?
[12:05] <sivang> pygi: if you're interested in working on it, you can start, following the new dsign ofcourse in the wiki page, if you can make it work as expcted and to good degree until September 7th , we might be able to put it in I think.
[12:05] <pitti> I have to reboot, brb
[12:05] <sivang> pygi: fallbaking to edgy+1 if it's not satisfactory until then
[12:06] <pygi> sivang, right, but most of the current codebase will be in second plan if we are to implement our -ng stuff
[12:07] <pygi> and if we're lucky, the cdrecord wrapper and dependency will also be dropped
[12:08] <sivang> pygi: I can't think of -ng stuff at the moment, just to get something slicketr and friendlier as per the new design + notifications. That's enough for a release and a half so it seems. I also lost A week already, which makes things a bit tighter. 
[12:09] <sivang> pygi: I think it'd be even better to concentrate efforts on getting in syn cwith the new spec, rather then working on QT version.
[12:09] <pygi> sivang, hm,ok, agreed
[12:11] <ogra> seb128, Thu May 20 15:35:52 2004 Joerg Schilling <joerg@schily.isdn.cs.tu-berlin.de>
[12:11] <ogra>         * cdrecord.c 1.286
[12:11] <ogra>           Bessere Kommentare gegen SuSE die cdrecord nicht als root laufen lasse
[12:11] <ogra>  wollen
[12:11] <ogra> seb128, seems it originaly was a suse patch 
[12:33] <ogra> hmm
[12:35] <ogra> seems i uploaded g-s-s at a bad time :/
[01:01] <mdz> ogra: ?
[01:02] <ogra> mdz, ?
 hmm
[01:02] <mdz>  seems i uploaded g-s-s at a bad time :/
[01:02] <mdz> please explain
[01:02] <ogra> yep, LP was in maintenance and i was wondering where my accepted mail wnet
[01:03] <ogra> queue is processed now ... just got the mail
[01:20] <janimo> infinity: hi, IIRC there were some explicit dependencies added on the CD build host to override some apt choices for xubuntu meta packages. Was libgoffice one of them?
[01:20] <janimo> now the desktop CD has both libgoffice-0-3 and libgoffice-gtk-1-2 pulled in and I wonder if the latter is left from the dapper setup
[01:26] <infinity> janimo:             LIST="$LIST ubuntu-base xterm libgoffice-gtk-1-2 xubuntu-desktop"
[01:26] <infinity> janimo: So, "yes".
[01:26] <janimo> infinity: thanks, could you change that to libgoffice-gtk-0-3 ?
[01:26] <janimo> as the package got renamed/updated
[01:27] <myki> Hi. AFAIK ubuntu uses udev instead of regular devfs. How is that sort out, there are just used ttys on dev instead of all pty[a-e] [0-f] , etc?
[01:27] <Vhata> ain't nothing regular about devfs
[01:28] <myki> Vhata: whatever, on debian it's default on etch.
[01:28] <ogra> myki, devfs was dropped from the kernel ... i doubt debian can use it ...
[01:29] <janimo> ogra: not until 2.6.18
[01:29] <Kamion> myki: not any more it's not
[01:29] <Kamion> pty* are handled by the /dev/pts filesystem
[01:29] <Kamion> (and /dev/ptmx) - Unix98-style
[01:29] <myki> ogra: I'm on 2.6.16-2 actually
[01:30] <ogra> janimo, hmm, i thought i saw a changelog entry in a 2.6.17 
[01:30] <ogra> or *16 even
[01:30] <zul> *cough* xen *cough*
[01:31] <Kamion> myki: it's definitely no longer the default on fresh installs. For upgrades, sure, you'd have to install the udev package to migrate to it.
[01:32] <myki> Kamion: OK. I know, I'm already on udev. Any advice how do I remove about 600 tty and pty devices?
[01:32] <Kamion> myki: don't
[01:32] <myki> I'm using 12 ttys, I don't need 325
[01:33] <Kamion> if udev is managing /dev, it'll do its thing from scratch every boot - don't go through removing stuff by hand
[01:33] <myki> Kamion: I'm not that daft ;] 
[01:35] <Kamion> a udev rule like KERNEL=="tty[a-z] [0-9] *", OPTIONS+="ignore_device" would suppress the creation of those devices
[01:35] <Kamion> and similarly for pty
[01:36] <Kamion> I don't really see the point of worrying about it though
[01:37] <myki> Kamion: ls /dev takes 3 whole screens. I got used that on ubuntu it's cleaner
[01:38] <ogra> easy to fix, use ubuntu on that machine ;)
[01:39] <myki> ogra: debian netinstaller has that advantage, to me, that it installs just what I exactly want, instead of whole dummy package
[01:40] <myki> ogra: and even on stable badger I had problems with packet dependencies (all from official repos)
[01:40] <Kamion> myki: Ubuntu creates /dev/[pt] ty[a-z] [0-9a-f]  too
[01:41] <myki> no can be
[01:41] <Kamion> (er, so yeah, the rule above should be KERNEL=="[pt] ty[a-z] [0-9a-f] "
[01:41] <Kamion> )
[01:41] <Kamion> myki: how often do you type 'ls /dev', exactly? :-)
[01:41] <ogra> ogra@edubuntu:~/packages/willowng-0.2$ ls /dev/tty*|wc -l
[01:41] <ogra> 325
[01:41] <ogra> ;)
[01:42] <Vhata> Kamion: <something> /dev/<tab><tab> is not uncommon ;-)
[01:42] <Kamion> Vhata: I don't know about you but I usually have a marginally clearer idea of what device I want than that, enough for the first character at least
[01:42] <ogra> myki, ubuntu-minimal is not *that* big :)
[01:43] <myki> Kamion: So I don't know what I did, but I had just ttys, I've been using actually. However, ignore rule works well.
[01:50] <infinity> janimo Fix committed.
[01:50] <janimo> infinity: thanks
[01:58] <ogra> is there any ETA when the build logs will be available again ? 
[01:59] <ogra> https://launchpad.net/distros/ubuntu/edgy/+builds gives me an oops
[02:02] <rodarvus> ogra, maybe people in ##soyuz1.0 can help you with that?
[02:02] <shawarma> Anything using python2.3 currently FTBFS. Is anyone working on that?
[02:02] <ogra> well, its not urgent or something ... but i'll ask there, probably they are not aware
[02:03] <doko> shawarma: we'll drop python2.3 soon
[02:04] <shawarma> doko: Uargh... There's like a million packages depending on it, is there not?
[02:04] <Kamion> shawarma: example?
[02:04] <shawarma> doko: dak
[02:05] <shawarma> Kamion: dak
[02:05] <Kamion> shawarma: https://launchpad.net/distros/ubuntu/+source/dak/1.0-8ubuntu2 built fine
[02:06] <ogra> ogra@edubuntu:~/packages$ apt-cache rdepends python2.3|grep -v python2.3|grep dak
[02:06] <ogra> ogra@edubuntu:~/packages$ 
[02:06] <ogra> and dak seems not to be in the rdepends
[02:06] <Kamion> ogra: rdepends doesn't show build-deps
[02:06] <shawarma> Does that show build-depends as well=?
[02:07] <Kamion> Build-Depends: debhelper (>= 4.1.65), python2.3-dev (>= 2.3-1), [...] 
[02:07] <ogra> Kamion, well, bu dh_python should have added the right deps
[02:07] <shawarma> Kamion: Maybe it was built before all this python-central funny business was introduced?
[02:07] <thom> doko: any chance you'll fix buildbot soon, btw?
[02:07] <Kamion> ogra: *sigh* just go look at the build-deps
[02:07] <ogra> Kamion, yes, i see
[02:07] <Kamion> shawarma: it doesn't build-depend on python-central or python-support so it's probably just broken
[02:08] <Kamion> shawarma: also there really shouldn't be a million packages build-depending on python2.3-dev directly any more
[02:08] <shawarma> Kamion: Anything build-depending on python2.[34] -dev should also build-dep on python-central?
[02:08] <Kamion> most of them should be using python-all-dev
[02:08] <Kamion> shawarma: not that simple, see http://people.debian.org/~piman/python-policy/ and http://wiki.debian.org/DebianPython/NewPolicy
[02:09] <doko> thom: yes, will be synced
[02:10] <shawarma> Kamion: Oh... the infamous new python policy.
[02:11] <shawarma> Kamion: well, I'll look at it. Thanks.
[02:12] <shawarma> Kamion: Just as I thought. The dak revision currently in edgy FTBFS.
[02:14] <shawarma> Is this new python policy in effect in Debian?
[02:15] <ajmitch> doko: we will drop zope2.8 very soon, right?
[02:15] <doko> ajmitch: yes, did you prepare the new plone? ;-p
[02:16] <ajmitch> hah
[02:16] <Kamion> shawarma: yes
[02:16] <ajmitch> kobold was doing that :)
[02:17] <shawarma> Kamion: Ok, thanks.
[02:26] <thom> doko: also, /var/run/buildbot is probably not the idea place to put the buildbot user, fwiw
[02:28] <doko> thom: hmm, I used another package as an example ... what would you recommend?
[02:31] <thom> doko: somewhere that won't get blown away every reboot
[02:32] <thom> since it's plausible that people will set up their buildbots in the users homedir
[02:33] <doko> hmm, then /var/lib/buildbot ...
[02:33] <thom> i think that makes more sense yes
[02:53] <zul> hey
[02:53] <tseng> there is only zul 
[02:53] <zul> its true
[02:53] <Hobbsee> hi zul, tseng 
[02:53] <tseng> hi.
[02:53] <zul> hi 
[03:10] <joejaxx> Kamion: oh ok thanks i will try and find more information on that
[03:13] <bddebian> Heya
[03:17] <bddebian> Hi Gloubiboulga
[03:17] <Gloubiboulga> hi bddebian, hi all
[03:32] <Mithrandir> seb128: want to answer bug 54024?
[03:32] <Ubugtu> Malone bug 54024 in xkeyboard-config "WIN key <SUPER_L> should be mapped to Applications menu" [Untriaged,Confirmed]  http://launchpad.net/bugs/54024
[03:32] <StevenK> I'd like to teach Xemacs that my Windows key is Super.
[03:47] <seb128> Mithrandir:  I'll reply to that one, reassigning (and maybe close, not sure yet). Do you have any opinion on the request?
[03:48] <Mithrandir> seb128: not really -- I'd be fine with it, but it's a "default keyboard binding" request/bug, not an XKB bug and since you're master of Gnome I figured getting you to look at it made sense.
[03:49] <seb128> Mithrandir: yeah, agreed, that's why I said I'll reply and reassign :)
[03:49] <seb128> Mithrandir: I think we already have a request to make win key = compose
[03:50] <Mithrandir> seb128: I map caps lock to compose on my machine anyway. :-)
[03:50] <seb128> I map the win key :)
[03:50] <Mithrandir> most of my machines doesn't have windows keys, so.. but yeah, it should do something useful.
[03:51] <seb128> Hobbsee: what you use do do  or  or  by example :p 
[03:52] <Hobbsee> seb128: right...okay then...
[03:52] <fabbione> seb128: you don't need them.. 
[03:52] <fabbione> :)
[03:52] <Riddell> Hobbsee: there's no easy way to do that in kde
[03:52] <fabbione> seb128: there are enough chars when typing [a-z] [A-Z]  ;)
[03:52] <Hobbsee> Riddell: hmm okay - lure's the one who knows all about it, not me
[03:52] <fabbione> seb128: everything extra is a bonus :P
[03:53] <seb128> fabbione: and next you will say that azerty is not a good keymap? :p
[03:53] <fabbione> seb128: there is only one layout.... that's qwerty :P
[03:54] <Mithrandir> seb128: I use alt-gr+[zxo]  for  :-P
[03:54] <ogra> fabbione++ 
[03:55] <seb128> altgr-o =  
[03:55] <Mithrandir> seb128: no,  = . :-P
[03:55] <seb128> ah, right, not everybody is using azerty (yet) :p
[03:55] <seb128> wait we switch to french as universal language
[03:56] <Mithrandir> ogra: we seldom use  in Norwegian.
[03:56] <rodarvus> seb128: altgr-o is  on br-abnt2 too
[03:56] <iwj> Anyone interested in the fact that dapper doesn't install on my testbed ?
[03:56] <Hobbsee> iwj: no, dapper's so last month :P
[03:56] <iwj> I'll burn a copy of knot-1 but I'm pretty sure that won't work either.
[03:56] <ogra> Mithrandir, bah, i bet if i look at some dissertations of the uni oslo i'll find some
[03:56] <ogra> :)
[03:58] <fabbione> iwj: what about explaining at least the problem? perhaps it's a known issue or something...
[03:59] <ogra> and did you try the common suspects like noacpi, pci=noacpi, nolapic etc ... ?
[03:59] <iwj> Install appears to work properly, but after the first reboot, at the point where grub should show its menu, the machine reboots.
[03:59] <iwj> I thought at first it was because I was installing the new grub in /dev/hda8 and chaining it so I let it put it in the mbr and now I have to rescue the whole machine :-).
[03:59] <fabbione> iwj: could you try an installation in expert mode and slam lilo in there?
[04:00] <fabbione> iwj: just to make sure we isolate the problem to grub 100%
[04:00] <iwj> dapper can boot on this machine.  The existing dapper install still works.
[04:00] <iwj> But I haven't rerun grub-install recently.
[04:00] <iwj> phone
[04:00] <fabbione> well if you did an install, grub-installer would have run that for you
[04:01] <fabbione> but i don't think from the previous instance
[04:01] <ogra> nope, it adds a new one ...
[04:06] <iwj> back now
[04:07] <iwj> IBM++  (they're really good with their laptop warranties)
[04:07] <iwj> Yes, so the new install's grub didn't work and the old ones do.
[04:09] <mdke> jdub: ping?
[04:10] <ogra> seb128, "- Use gnome-power-manager to implement suspend/hibernate" is that using the gconf key now ? 
[04:10] <ogra> (re: gnome-panel)
[04:11] <Hobbsee> mdke: [00:11]  [Whois]  jdub has been idle for 12 hours, 57 minutes and 52 seconds.  midnight here
[04:11] <seb128> ogra: we don't care, we are not using upstream session dialogs but the special dapper one
[04:11] <seb128> ogra: for 2.14 they have no suspend or hibernates option from GNOME
[04:11] <allee> Keybuk: ping.
[04:12] <Keybuk> allee: hello
[04:12] <allee> Keybuk: I've seen you synced digkam from debian
[04:12] <mdke> Hobbsee: thanks again
[04:12] <Hobbsee> Keybuk: you're back!  now, what did i have to tell you?
[04:12] <ogra> seb128, yes, but is the 2.15 version using them ? 
[04:12] <Hobbsee> mdke: :)
[04:12] <allee> Keybuk: unfortunetely digikam 0.9 was upload to unstable instead of experimental
[04:12] <seb128> ogra: looks like, but we patch the panel to not use their session code
[04:12] <allee> Keybuk: 0.9 beta is not ready for a stable release
[04:13] <Hobbsee> Keybuk: StevenK's done some nice work on network manager - sources are likely still on his hard drive, but i386 binaries for testing are at http://wedontsleep.org/~steven/nm/ if you're interested.  getting various -motu people to test
[04:13] <allee> Keybuk: any idea how we can sync 0.8.2-1 into edgy (when 0.9 trouble is sorted out in debian)
[04:13] <ogra> seb128, oh, so such a patch would be required for our logout dialog then ... now i understand 
[04:17] <Keybuk> allee: you'd have to epoch it and upload manually *shrug*
[04:17] <Keybuk> Hobbsee: does it fix the problems with madwifi?
[04:17] <Hobbsee> Keybuk: no idea, we're still having trouble with testers who actually have dapper
[04:17] <Hobbsee> Keybuk: it was more a FYI, we're working on this
[04:18] <allee> Keybuk: epoch is easy to and impossible to get rid off :(   AFAIK Mark talks with ftp-masters to remove digikam 0.9-beta1 from unstable
[04:18] <Hobbsee> Keybuk: and i'll be able to test out madwifi stuff on friday-ish, when i nick StevenK's wifi card that doesnt require ndiswrapper :P  shhh... :P
[04:18] <Keybuk> allee: of course, I could just not push this button
[04:18] <Keybuk> if you beg <g>
[04:18] <Keybuk> (it hasn't gone in the archive yet)
[04:18] <Hobbsee> Keybuk: s/dapper/edgy/
[04:18] <Keybuk> Hobbsee: I don't have dapper on my laptop -- it runs edgy
[04:19] <Keybuk> there's no source at that URL
[04:19] <Hobbsee> Keybuk: my error, i cant keep the distrobutions straight :P
[04:19] <Hobbsee> Keybuk: yes, i know, i'll bug him again about putting pu the sources.
[04:19] <seb128> ogra: the session dialog use g-p-m since before dapper ...
[04:19] <geser> Keybuk: bug 54036 contains a patch to add usplash support in file-rc
[04:19] <Ubugtu> Malone bug 54036 in file-rc "add support for usplash" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54036
[04:19] <seb128> ogra: remember you complained because on ltsp it acts on the server?
[04:20] <Keybuk> geser: ok, so now you need to find a motu to upload a new version of file-rc
[04:20] <allee> Keybug I'll add a note to bug 53534 about the issue.
[04:20] <Ubugtu> Malone bug 53534 in digikam "[Edgy MoM]  Please sync digikam 0.8.2-1 from Debian" [Untriaged,Fix released]  http://launchpad.net/bugs/53534
[04:20] <Keybuk> Hobbsee: 'cause I ain't touching binaries -- and I can't see the source differences
[04:20] <ogra> seb128, yes, it doesnt hide the suspend/hibernate options if the can_hibernate/suspend keys are unset
[04:20] <Keybuk> allee: should I also not sync the -doc and imageplugins-doc packages?
[04:21] <Hobbsee> Keybuk: yeah, of course - if he doesnt have them up by friday, i'll attack him with a long pointy stick in person, okay?  it's more a message of "hey, he's working on it, dont bother duplicating the work"
[04:21] <Hobbsee> hi sabdfl 
[04:21] <ogra> seb128, the easy fix is to remove g-p-m but i'd rather keep it and have gnome-session react on the gconf keys
[04:21] <sabdfl> hey hey Hobbsee
[04:21] <allee> Keybuk: all digikam*-0.8.2* are fine.  Only the 0.9-beta1 are not ready for release
[04:21] <sabdfl> good work guys, i just jumped to edgy and all went basically smoothly
[04:21] <jsgotangco> nice
[04:21] <seb128> ogra: I don't understand what you are talking about and about what you reactionned to that panel change
[04:22] <Hobbsee> sabdfl: (quick!  everybody break something!)
[04:22] <zul> hi sabdfl 
[04:22] <Arbiter> :)
[04:22] <seb128> ogra: they did for the upstream panel what we did before dapper: make the session dialog use gpm
[04:22] <seb128> ogra: nothing new for Ubuntu
[04:22] <Keybuk> sabdfl: it boots?
[04:22] <Vhata> Keybuk: try not to sound so surprised ;-)
[04:23] <sabdfl> Keybuk: it does indeed. it socks and trousers, too
[04:23] <ogra> seb128, yes, and gpm's hibernate and suspend functions depend on the /apps/gnome-power-manager/can_hibernate and /apps/gnome-power-manager/can_suspend ... if i unset these, the suspend and hibernate options still show in the logout dialog
[04:23] <Hobbsee> come on...compile kdenetwork...i want to go to bed at some point...
[04:23] <Hobbsee> sabdfl: hehe - but does it shirt too?
[04:24] <ajmitch> Hobbsee: I hope not
[04:24] <jsgotangco> haha
[04:24] <ogra> seb128, i think they just shouldnt be shown, thats all
[04:26] <ogra> Hobbsee, uk
[04:27] <seb128> ogra: that's a g-p-m bug then
[04:27] <Hobbsee> ogra: ie, is he here to be able to upload an update to dapper (assuming it compiles/installs) or what?
[04:27] <mdz> Hobbsee: London
[04:27] <ogra> Hobbsee, no idea if he's hot on uploading stuff :)
[04:28] <ogra> seb128, *should* the dialog pick these keys up ? 
[04:28] <Hobbsee> mdz: heya, didnt see you on the list.  
[04:28] <Hobbsee> ogra: lets hope he is.
[04:28] <seb128> ogra: the dialog ask to g-p-m if suspend and hibernated are activated
[04:28] <Hobbsee> ogra: it's kinda bad when about 1/5 of an app suddenly stops working.
[04:29] <ogra> seb128, aha, ok, i'll look why that doesnt work then ... thast a dbus request it sends i guess ?
[04:29] <seb128> ogra: gpm_dbus_interaction ("Suspend"); and gpm_dbus_interaction ("Hibernate");
[04:30] <ogra> seb128, ta
[04:30] <seb128> np
[04:30] <ogra> Hobbsee, you still have 4/5 left :)
[04:30] <Hobbsee> ogra: hah, yeah, and personally i dont care, cos i'm not on dapper, but i can see why the users are whinging
[04:30] <Hobbsee> ogra: and besides, i'm on kde 3.5.3 anyway, so a 3.5.2 bugfix wont effect me.
[04:32] <iwj> Hmm, if I use the stage1 from the old dapper release it gets as far as loading the new install's stage2 and _then_ reboots.
[04:36] <Kamion> allee: BTW, in future, an epoch is not that bad, and is the right solution
[04:42] <gnomefreak> is it just the uk mirrors that are messed up?
[04:42] <gnomefreak> im gettng a malformed release file error
[04:46] <Chipzz> Failed to fetch http://archive.ubuntu.com/ubuntu/dists/edgy-updates/Release  Unable to find expected entry  main/binary-i386/Packages in Meta-index file (malformed Release file?)
[04:46] <Chipzz> Failed to fetch http://security.ubuntu.com/ubuntu/dists/edgy-security/Release  Unable to find expected entry  main/binary-i386/Packages in Meta-index file (malformed Release file?)
[04:48] <gnomefreak> Chipzz: that would be the one
[04:49] <elmo> it's a launchpad bug, being worked on 
[04:51] <gnomefreak> elmo: ty
[04:52] <iwj> grub not working for me is bug 54041
[04:52] <Ubugtu> Malone bug 54041 in grub "grub does not boot for me (!)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54041
[04:54] <Arbiter> mvo, ping
[04:56] <mvo> hello Arbiter
[04:56] <Arbiter> hello mvo
[04:56] <Arbiter> i've just noticed your email about smartpm
[04:56] <Arbiter> :)
[04:56] <Arbiter> package is on REVU
[04:56] <mvo> Arbiter: ah, nice. can you give me a direct link? 
[04:57] <Arbiter> yep
[04:57] <Arbiter> wait a sec
[04:57] <Arbiter> i've patched __init__.py a bit
[04:58] <Arbiter> mvo, http://revu.tauware.de/details.py?upid=2709
[04:58] <slomo> Arbiter: it's already in edgy
[04:58] <slomo> Arbiter: or is this only an update?
[04:58] <Arbiter> alredy splitted?
[04:58] <mvo> Arbiter: nice, thanks. I look over your changes in a bit 
[04:58] <mvo> Arbiter: no, not splitted yet
[04:59] <mdz> Keybuk: would be a good idea to refrain from syncs for the next while
[04:59] <mdz> soyuz un-meltdown is in progress
[05:00] <Arbiter> mvo, __init__.py is patched to warn the user that smartpm is splitted in smartp && smartpm-gtk (if smartpm-gtk is not installed)
[05:00] <Kamion> Arbiter: (FYI the English word is just "split", not "splitted")
[05:00] <Kamion> and "split into" probably
[05:00] <Arbiter> Kamion, hehehe :D
[05:00] <Arbiter> english is not my mother tongue
[05:00] <Arbiter> :D
[05:01] <Keybuk> mdz: I'm not doing any injection, just clearing the bug queue
[05:01] <Hobbsee> bah.  let's all switch to german or something.  maybe japanese.
[05:01] <Keybuk> what did they do to soyuz this time?
[05:01] <Arbiter> Hobbsee, lol
[05:01] <Kamion> sure, I'm not criticising you, just offering an improvement
[05:01] <mdz> Keybuk: bug 54037
[05:01] <Ubugtu> Malone bug 54037 in launchpad-publisher "Release files broken for pockets" [Critical,Confirmed]  http://launchpad.net/bugs/54037
[05:01] <Arbiter> Kamion, yup
[05:01] <Keybuk> mdz: ah, that one
[05:01] <mdz> I subscribed ubuntu-archive
[05:02] <Kamion> mdz: but launchpad has full test coverage, that can't happen
[05:02] <mvo> Arbiter: if you update it again feel free to send a debdiff directly to me
[05:02] <Arbiter> mvo, sure
[05:03] <mdz> Kamion: I don't think anyone has ever claimed "full test coverage" for any non-trivial piece of software
[05:03] <Keybuk> mdz: doesn't tridge for samba4?
[05:04] <mdz> I doubt it; he's generally sane
[05:04] <Arbiter> can someone reject the colorscheme package (NEW queue)?
[05:04] <mdz> it may have tests which exhibit full code coverage, but that isn't the same thing
[05:05] <Keybuk> mdz: well, yes
[05:05] <Keybuk> but launchpad doesn't even have 10% code coverage for its tests
[05:05] <Arbiter> upstream changed the program name -.-
[05:07] <Keybuk> Arbiter: gone
[05:07] <Arbiter> thanks
[05:09] <jono> hey
[05:09] <tseng> hiya
[05:18] <bddebian> Keybuk: Thanks for the syncs.  trigger and trigger-data may need to be fakesysncs because of different orig.tar.gz ?
[05:20] <Hobbsee> bddebian: that's what i had to do before, eah
[05:21] <Keybuk> bddebian: correct
[05:21] <bddebian> OK, so how do I do that properly?  Pull the source and add a build1 version?
[05:22] <slomo> bddebian: ubuntu1... otherwise it will be tried to be autosynced next release and it could fail because of changed tarball
[05:22] <Kamion> no, build1
[05:22] <slomo> hm... won't that break?
[05:22] <Kamion> if an autosync fails, big deal, if it succeeds, we don't want to be bothered by a manual sync
[05:22] <Kamion> bddebian: build1, build with -sa plus -v<whatever>
[05:23] <bddebian> Kamion: OK, thx
[05:23] <bddebian> Heya ivoks
[05:23] <ivoks> hey everybody
[05:23] <slomo> Kamion: thanks
[05:23] <bddebian> Why would an autosync fail?  Isn't it posting the new orig.tar.gz with -sa?
[05:25] <Kamion> bddebian: for the same reason that Keybuk's sync attempt failed
[05:25] <bddebian> OK
[05:25] <Kamion> bddebian: if there hasn't been a new upstream, but just a new Debian version
[05:26] <mdz> Keybuk: can you get MOM to pull a version from experimental?
[05:26] <Keybuk> mdz: yes.
[05:27] <Keybuk> one-off or ongoing?
[05:27] <bddebian> Oh crap, kiki too?
[05:28] <mdz> Keybuk: ongoing (firefox)
[05:29] <Keybuk> dholbach: do you not also want the other telepathy packages from the same site?
[05:30] <Keybuk> gst-plugins-farsight, specifically
[05:30] <dholbach> Keybuk: i'll continue to get them included with daf (maybe they weren't there at that time or i uploaded some of them myself already) - i'll have another look
[05:31] <Hobbsee> mdz: ping?
[05:31] <mdz> Hobbsee: ?
[05:32] <Hobbsee> mdz: can we get http://revu.tauware.de/details.py?upid=2786 uploaded to dapper-updates please?  it fixes a couple of rather crucial kopete bugs.
[05:32] <Hobbsee> mdz: i can pastebin a diff if you want to eyeball that instead.  (both patches are in kde svn)
[05:32] <mdz> Hobbsee: is http://revu.tauware.de/revu1-incoming/kdenetwork-0607251125/kdenetwork_3.5.2-0ubuntu7.diff the diff from the previous version? it's huge
[05:33] <mdz> it looks like just an uncompressed version of the diff
[05:33] <mdz> Hobbsee: what's most helpful for me is a debdiff from the old version to the new version so I can see what's changed
[05:33] <lamont> Keybuk: not sure what the issue was with 2.3.0-2
[05:34] <Hobbsee> mdz: yeah.  bleck.  that diff's completely crazy.
[05:34] <lamont> mdz: postfix 2.3.1 has some more minor fixes from wietse, yada yada.. I assume that's syncable....
[05:34] <lamont> or do you want email and such?
[05:34] <Hobbsee> mdz: i havent found a way to get debdiffs onto revu :P  here you go: http://rafb.net/paste/results/bbzm1N35.html
[05:35] <Hobbsee> mdz: argh!!! it mangled my patch!
[05:35] <mdz> Hobbsee: you should delete kdenetwork-3.5.2.orig/debian/changelog.dch.save
[05:35] <Hobbsee> mdz: yeah, it's mangled it.  /me pokes it with a stick and makes it save.
[05:35] <Hobbsee> it was looking well behaved before!
[05:37] <Hobbsee> s/save/behave/
[05:37] <mdz> 19_icq_version_too_old.diff looks fine
[05:38] <Hobbsee> mdz: yeah, it's just that, and the 18 one, and the changelog entry.  but i'm still trying to figure what borked.
[05:39] <mdz> the other patch is a bit of a hack
[05:39] <Hobbsee> mdz: it's how kde's done it, and how they've done it in 0.12.1 (this patch is for 0.11 packages)
[05:39] <Keybuk> INFO:root:Trying to merge firefox: 1.5.dfsg+1.5.0.4-1ubuntu2 <- 1.5.dfsg+1.5.0.4-1 -> 1.99+2.0b1+dfsg-1
[05:39] <Keybuk> mdz ^ those are the right version?
[05:40] <seb128> ogra: the pango message you were looking at was due to "empty GPOS table" and fixed with the new version
[05:41] <ogra> ah, cool
[05:41] <ogra> so it wasnt even a font :)
[05:41] <seb128> it was a font with an empty GPOS table
[05:42] <seb128> which apparently is allowed
[05:42] <mdz> Keybuk: yes
[05:42] <ogra> ah
[05:42] <Hobbsee> mdz: http://rafb.net/paste/results/52Bz3522.html looks like the proper, sane, debdiff - sorry for the other dodgy ones.
[05:42] <mdz> Hobbsee: how does Riddell feel about it?
[05:42] <Keybuk> mdz: ok, that'll merge from experimental from now on
[05:42] <mdz> Keybuk: thanks
[05:43] <ogra> seb128, i read GPOS is only used in otf ... that was what cnfused me, i have no open type fonts installed
[05:43] <Hobbsee> mdz: he knew i was doing the patch, i dont think i've spoken to him since i made it work.  he accepted those two patches for the 0.12 branch, which is what we ship with edgy.
[05:44] <seb128> ogra: http://bugzilla.gnome.org/show_bug.cgi?id=347073
[05:44] <Ubugtu> Gnome bug 347073 in general "Allow empty GPOS table" [Normal,Resolved: fixed]  
[05:45] <seb128> ogra: the freedesktop bug speaks about dejavu
[05:45] <ogra> oh
[05:47] <mdz> Hobbsee: it looks like it has a race condition
[05:47] <mdz> it's trying to implement a mutex without actually using one
[05:48] <mdz> it'll be a smaller race than the old code, but it's still buggy
[05:48] <Hobbsee> mdz: uh, okay.
[05:49] <mdz> Hobbsee: I don't see that it can do any harm, but it isn't correct and the author should be informed.
[05:49] <Hobbsee> mdz: want to get Riddell to eyeball that when he comes back?
[05:49] <Hobbsee> mdz: okay, so i'll bug the upstream people about it?
[05:50] <Hobbsee> mdz: seeing as that svn commit is where i got the patch from.
[05:50] <mdz> Hobbsee: Olivier Goffart seems to be the author of the bit that I find weird
[05:53] <Riddell> mdz: what seems wrong with it?
[05:54] <mdz> Riddell: it's racy
[05:54] <mdz> there's a race between checking and setting "rentrency_protection"
[05:55] <mdz> the idea seems to be mutual exclusion, in which case it should use a mutex
[05:57] <Riddell> mdz: I've pinged Olivier Goffart to see if he can explain it but he's not responding, I'll get back to you when he's around
[05:58] <lfittl> mako: ping
[05:59] <mdz> Riddell: thanks
[06:06] <bddebian> I haven't gotten anything back on kiki and trigger.  Should I, or do they end up in NEW ?
[06:09] <slomo> bddebian: seems like uploads are not processed atm
[06:10] <Kamion> damnit, I'm going to have to write something that checks out all four sets of seeds
[06:12] <Keybuk> bddebian: "anything back" ?
[06:12] <Keybuk> bddebian: soyuz isn't well, it may take time
[06:18] <bddebian> Keybuk: Oh, OK, sorry
[06:29] <bddebian> doko: still around?
[06:35] <doko> bddebian: ?
[06:36] <bddebian> doko: Know/remember anything about azureus? :-)
[06:38] <Gof> mdz: ping
[06:38] <doko> bddebian: can't you just ask what you do want to know?
[06:39] <bddebian> doko: Well for one, the Debian package builds deps: sun-j2sdk1.5 | java2-compiler  and you changed it to java-gcj-compat-dev
[06:39] <mdz> Gof: yes?
[06:39] <Gof> mdz: Riddell said you have something to ask me about a kopete patch
[06:40] <doko> bddebian: we do want to have azureus in main
[06:40] <mdz> Gof: yes, the one here: http://bugs.kde.org/130630
[06:41] <mdz> Gof: er, sorry ,wrong url
[06:41] <bddebian> doko: Oh, so it is going to be promoted?
[06:41] <slomo> bddebian: iirc the debian changelog mentioned that they switch to java-gcj-compat-dev too in the latest upload
[06:41] <mdz> Gof: http://bugs.kde.org/show_bug.cgi?id=127749
[06:41] <Ubugtu> KDE bug 127749 in general "kopete freezes on desktop right click" [Crash,Resolved: fixed]  
[06:41] <bddebian> slomo: Not that I can see, unless I'm not getting the latest?
[06:42] <mdz> Gof: if the goal is to avoid concurrent execution of that block, then the fix looks incomplete
[06:42] <ajmitch> bddebian: http://packages.qa.debian.org/a/azureus/news/20060717T064745Z.html
[06:42] <slomo> bddebian: http://packages.debian.org/changelogs/pool/contrib/a/azureus/current/changelog
[06:42] <slomo> bddebian: * Build using java-gcj-compat-dev and debhelper 5.
[06:42] <mdz> Gof: there is a race between testing the value of the variable and setting it
[06:42] <ajmitch> slomo: or that :)
[06:42] <Gof> mdz: there is not
[06:42] <Gof> mdz: this is not a thread stuff
[06:42] <slomo> bddebian: maybe we can just sync it... thanks for looking at it, i had it on the bottom of my list too :)
[06:43] <bddebian> slomo: That's what I am trying to determine :-)
[06:43] <mdz> Gof: ok, so it's only trying to prevent the situation where the DCOP call causes another call into the same method from within the process?
[06:43] <Gof> the problem is a recursive call due to a call to the main event loop in  DCOPRef::callExt
[06:43] <Gof> mdz: exactly
[06:44] <mdz> Gof: ok, I understand, thanks
[06:44] <bddebian> Ah damnit, I got 2-1 from packages.d.o.. Grr
[06:45] <slomo> bddebian: use packages.qa.debian.org... it's much more uptodate most of the time and has more useful information :)
[06:45] <bddebian> slomo: OK, thx
[06:45] <mdz> Hobbsee: debdiff is OK for -updates
[06:45] <Riddell> thanks mdz, Gof
[06:45] <Hobbsee> mdz: heh, so you're not going to eat me now?  oh good.
[06:45] <Hobbsee> mdz: thanks :)
[06:46] <Riddell> can Hobbsee upload to -updates in main?  I presume not
[06:46] <Hobbsee> Riddell: ah...well, i cant upload to main normally, so i assume not
[06:47] <doko> bddebian: it *is* in main in dapper/edgy. what's your problem?
[06:47] <mdz> Hobbsee: not unless you're a fish
[06:47] <ogra> Hobbsee, are you a vegetable ?
[06:47] <bddebian> doko: Then why is it on the Universe merges page?
[06:47] <mdz> Riddell: not unless Hobbsee is in -core-dev; would you sponsor it?
[06:48] <Riddell> mdz: will do
[06:48] <mdz> thanks
[06:48] <Hobbsee> mdz: i only went for MOTU last week - sheesh :P
[06:48] <doko> bddebian: sorry, *universe*, not *multiverse*
[06:48] <bddebian> C'mon Hobbsee, get with the program :-)
[06:48] <Hobbsee> i dont think i'm a fish or a vegetable...
[06:48] <Hobbsee> bddebian: heh
[06:48] <bddebian> doko: I'm sorry, you lost me there?
[06:49] <doko> it won't be in main, we do have another torrent in main
[06:49] <bddebian> Oh, OK.
[06:49] <ogra> Hobbsee, then you are not among the endagered species 
[06:49] <bddebian> Hobbsee: Oh, so you are a mineral?
[06:49] <Hobbsee> ogra: i'm looking around for more hobbsee's, or more female linux people, and i'm not seeing many!
[06:50] <bddebian> Hobbsee: There arent many.  You could look in #debian-women
[06:50] <ogra> not seeing them doesnt mean they dont exist ;)
[06:50] <Hobbsee> ogra: women dont exist in the internet.  cue appropriate link.
[06:50] <Hobbsee> :P
[06:50] <Hobbsee> ogra: now who's to get with the program?  :P
[06:50] <ogra> heh
[06:50] <bddebian> hehe
[06:51] <bddebian> Ack, azureus, FTBFSs anyway: E: Package libswt-gtk-3.1-java has no installation candidate
[06:51] <hungerW> Hobbsee: No women on the net? I keep stumbling over pictures of nude ones all the time:-)
[06:51] <bddebian> "stumble over.." ;-)
[06:51] <hungerW> Hobbsee: So they must exist;-)
[06:52] <bddebian> slomo: No synce ^^ at least not yet :-(
[06:53] <hungerW> Hobbsee: I did get that, was just pulling your leg.
[06:53] <Hobbsee> hungerW: yes.  rather crap form of a joke too, but....
[06:54] <Hobbsee> oh well.
[06:54] <bddebian> Hobbsee: Just don't mention ponies and alcohol
[06:54] <hungerW> Hobbsee: I know:-( But it is too hot here to come up with better jokes:-(
[06:55] <mdz> Keybuk: MOM seems to flag conflicts in binary files even when they are identical in Debian and Ubuntu
[06:55] <Hobbsee> bddebian: i've already heard.  and if it doesnt sound good in your head, it certainly doesnt sound good in IRC.
[06:55] <Hobbsee> anyway...
[06:56] <bddebian> pfft
[06:56] <Hobbsee> mdz: i think Keybuk was aware of that, same with some of the .po files.
[06:57] <bddebian> I give up
[06:58] <gnomefreak> looks like a conflict in latest gksu packages or its just me but libgksu wont overwrite /usr/share/gconf/schemas/gksu.schemas
[07:08] <LaserJock> Keybuk: thanks for my silly little section bugs
[07:10] <bddebian> LaserJock!
[07:10] <bddebian> LaserJock: Hey, can you regen your packages list for me please?
[07:11] <LaserJock> sure
[07:23] <bddebian> Hobbsee: kvpnc can be synced.  I'm not sure why they did automake1.7 instead of 1.9 but whatever :-)
[07:23] <Hobbsee> bddebian: oh cool, want to request it?
[07:24] <bluefoxicy> lol, libgksudo2 broke
[07:24] <bluefoxicy> failed to completely install and update-manager didn't try again.  ('apt-get install' fixes)
[07:24] <slomo> bluefoxicy: already fixed
[07:24] <bddebian> Hobbsee: Oh sure, you want me to take the blame eh? :-)
[07:25] <bluefoxicy> slomo:  yeah, the problem fixes itself :p
[07:25] <Hobbsee> bddebian: sure, it's pitch black in here, except fo rthe computer screen.
[07:25] <Vhata> what's the canonical (ahaha, I slay me) way to run an instance of edgy within a dapper machine?
[07:25] <slomo> bluefoxicy: yes but a fixed package was uploaded too :P
[07:25] <bluefoxicy> slomo:  ah.
[07:26] <Amaranth> Vhata: vmware-server is a good choice
[07:26] <bluefoxicy> wtf.  bluefox@icebox:/tmp/x$ gksu synaptic  -> glibtop: This machine has 1 CPUs, 1 are being monitored.
[07:26] <Vhata> Amaranth: so, full on virtualisation?
[07:26] <mvo> bluefoxicy: see, it does not only gets your passwort but it also checks your cpus :P
[07:27] <Amaranth> Vhata: either that or give it it's own partition
[07:27] <Vhata> Amaranth: i.e. dual boot?
[07:27] <Amaranth> yeah
[07:27] <Vhata> let me see if vmware-server is in the hypertimetransmetroverse
[07:27] <bddebian> Hobbsee: Sent
[07:27] <Hobbsee> bddebian: thanks
[07:28] <bluefoxicy> also has anyone looked in /etc/ld.so.conf.d/ ?  I just want to make sure what I'm seeing is correct.
[07:29] <Kamion> Vhata: use edgy's debootstrap to create an edgy chroot, if you don't care about the kernel changes
[07:29] <Vhata> Kamion: that sounds like more fun
[07:30] <Vhata> (not that ubuntu development is fun of course.  deadly serious stuff, this.  straight face, stiff upper lip, what, what?)
[07:59] <Vhata> Kamion: I need debootstrap 0.3.3.0ubuntu3, not 0.3.3.0ubuntu2, yes?
[08:04] <Vhata> Vhata: work it out for yourself
[08:04] <Vhata> sorry.
[08:22] <zul> right...im ready to release havoc on the world..
[08:22] <LaserJock> noooooo
[08:23] <HiddenWolf> zul: In which fiendish way?
[08:23] <zul> xen/xen-linux image
[08:24] <HiddenWolf> nice
[08:25] <mc44> I guess someone knows the irclogs are broken
[08:26] <tseng> unlikely to be much of a priority, unfortunately
[08:27] <mc44> I'm guessing fabbione has gone off to do something important like have a baby instead :)
[08:27] <tseng> the bot is still here
[08:51] <bluefoxicy> wow that's new.  I can't triage my own bugs.  :P
[08:53] <iwj> knot-1 seems to take a lot longer to install than dapper.
[08:58] <iwj> At least I've managed to defeat my recalcitrant CD writer and my workstation isn't mumbling BIOS messages out of its PC speaker any more.
[08:59] <iwj> Yep, knot-1's grub can't cope either.
[09:00] <iwj> zul: Excellent.  I was going to try it out ASAP but as you can see I don't have a working edgy install atm :-/.
[09:02] <zul> well you should really wait for a kernel as well ;)
[09:02] <iwj> *snort*
[09:02] <fabbione> yes the irclogs are not working because one of the machines at the datacenter is broken
[09:02] <iwj> I have a kernel or two I could play with.
[09:03] <iwj> They don't quite work right but they'd let me try out your xen.
[09:03] <zul> well you dont need me then ill just go home and pout :)
[09:03] <iwj> :-P
[09:03] <zul> heh
[09:03] <iwj> (Just doing your pouting for you too.)
[09:04] <zul> brb...need to reboot
[09:04] <zul> er...nevermind
[09:05] <bluefoxicy> hmm... now all I need to do is fix #49283 and none of the apps I'm running most of the time should have an executable stack.
[09:06] <tseng> "Another quick fix is to add the following block to the end of each .nasm file in src/libFLAC/ia32/"
[09:06] <tseng> wish you'd quit that
[09:07] <zul> brb...for real this time
[09:08] <tseng> have you talked to upstream?
[09:08] <hub> damn
[09:08] <hub> I dist-upgraded to edgy and X no longer start
[09:09] <hub> is there a way to ensure that I have all the packages?
[09:09] <tseng> apt-get install ubuntu-desktop helps
[09:09] <mvo> hub: is ubuntu-desktop installed? [hello btw]  :)
[09:09] <hub> kubuntu-desktop is up to date
[09:10] <tseng> did you look at the X log?
[09:10] <iwj> Aha!  If I trim my menu.lst, it works!
[09:11] <Vhata> sabdfl at work:  grep -- -- /var/log/messages
[09:11] <Vhata> that's got to be old.
[09:12] <tseng> yeah that was not remotely funny
[09:12] <hub> could not open default font 'fixed'
[09:12] <hub> *sigh*
[09:12] <tseng> man
[09:12] <tseng> they should really roll that into the core server one of these days
[09:13] <hub> xfonts-base is there
[09:14] <hub> and I did a reconfigure of X
[09:14] <slomo> you have to run mkfontdir or something in one of the font directories
[09:15] <zul> super..http://70.29.57.2/ubuntu/xen/dmesg-xen.out
[09:15] <hub> slomo: works better
[09:15] <slomo> hub: mkfontdir in /usr/share/fonts/X11/misc
[09:15] <hub> thanks
[09:15] <slomo> np :)
[09:25] <rodarvus> Kamion, Keybuk: I'd like to have source package 'mesa' rejected from the Accepted queue (mesa-swx11-source is causing xorg-server to FTBFS)
[09:26] <Kamion> too late
[09:26] <rodarvus> :/
[09:26] <rodarvus> no worries then, thanks anyway :)
[09:26] <Kamion> if this is 6.5.0.cvs.20060524-1, it's being munched on by the publisher right now
[09:26] <rodarvus> yep, this is it
[09:26] <Kamion> if you're quick, you might be able to supersede it with a new source upload before the binaries get there, though
[09:26] <lamont> why would a laptop that booted in ~1 min on breezy take 10 min to boot dapper???
[09:26] <rodarvus> I'll upload a new release of Mesa later tonight
[09:27] <Kamion> lamont: probably hit the bad-luck side of the wait-for-root-device-to-appear code in initramfs-tools
[09:27] <Kamion> (at a guess ...)
[09:27] <rodarvus> Kamion, it won't break runtime - the only problem is xorg-server builds, it seems
[09:27] <Kamion> cool
[09:28] <lamont> he says it first shows up loading restricted drivers, and then everything goes more slowly - X startup takes about 5 of those minutes...
[09:28] <Kamion> oh, nothing I know about then ...
[09:28] <tseng> udevstart used to hang for some minutes
[09:28] <tseng> but im sure that was fixed
[09:29] <fabbione> lamont: i have heard something like and there is a bug with a workaround in LP
[09:29] <tseng> lamont: bootchart?
[09:29] <fabbione> something to do with speedstep
[09:31] <lamont> fabbione: 10x??? 
[09:31] <lamont> tseng: could be
[09:31] <fabbione> lamont: can't remember.. but pretty slow
[09:33] <lamont> fabbione: if you happen across the bug, that'd beat me reading the entire pile looking for it....
[09:33] <fabbione> lamont: let's ask on -bugs
[09:34] <bluefoxicy> tseng:  I just sent a patch to upstream.
[09:34] <tseng> bluefoxicy: goodness.. ok
[09:34] <tseng> something rubs me wrong about firing up vi and sticking your own elf headers in an asm file
[09:34] <bluefoxicy> and told them how to fix PPC because I don't feel like trying to tweak the build system to use .S instead of .s for a single file.
[09:34] <bluefoxicy> vi?
[09:34] <tseng> but its your soul, not mine :)
[09:34] <bluefoxicy> I write a small shell script to do it.
[09:36] <hub> did something change with the locales again?
[09:40] <crimsun> what's the context of "again", i.e., between what periods?
[09:41] <crimsun> my dapper->edgy dist-upgrade didn't preserve my selected locales, but I worked around it by regenerating them via locale-gen afterward
[09:48] <Kamion> pitti: I'd appreciate a tasksel MIR review when you have time; I've written the report
[09:49] <Keybuk> lamont: hmm?
[09:49] <lamont> Keybuk: when you were playing with boot times on the thinkpads...  what were you using to make those pretty graphs, etc.
[09:50] <lamont> although it looks like maybe speed step is to blame in this case.
[09:50] <Keybuk> lamont: apt-get install bootchart
[09:50] <Keybuk> then boot, and look in /var/log/bootchart for the pretty graphs
[09:51] <neom> What nick does Mark use if he comes by?
[09:51] <Keybuk> neom: sabdfl
[09:51] <neom> k
[09:52] <neom> Just found out my doctor is his uncle. O.o
[09:53] <AlinuxOS> mjg59, ping
[09:53] <Treenaks> neom: cool :)
[10:03] <Vhata> perl: warning: Setting locale failed.
[10:03] <Vhata> perl: warning: Please check that your locale settings: LANGUAGE = "en_ZA:en", LC_ALL = (unset), LANG = "en_ZA.UTF-8" are supported and installed on your system.
[10:03] <Vhata> that's after an edgy debootstrap
[10:04] <Kamion> debootstrap doesn't generate locales for you
[10:05] <Kamion> 'locale-gen en_ZA.UTF-8' in the chroot
[10:05] <Kamion> or 'apt-get install language-pack-enn'
[10:05] <Kamion> er, -en
[10:05] <Vhata> right ta
[10:56] <pitti> "Committed revision 666."
[10:57] <pitti> woo! :)
[10:57] <pitti> the release of the devil
[10:57] <LaserJock> yikes, that's an interesting statment coming from the security guy ;-)
[10:58] <pitti> MUHAHAHA
[10:58] <pitti> I wish I would release this as postgresql-common 66, unfortunately it's only 58 so far :)
[10:59] <Mithrandir> pitti: just bump the debian version number, then.  Nobody says they have to be sequential
[10:59] <slomo_> pitti: or split the changelog into 8 versions ;)
[10:59] <pitti> heh
[11:58] <Keybuk> when totem crashes every time it's opened, what's the fix?
[11:58] <slomo_> Keybuk: totem-gst or totem-xine?
[11:58] <Keybuk> gst
[11:59] <slomo_> how does it crash? anything useful on the console?
[12:01] <Keybuk> The error was 'BadAlloc (insufficient resources for operation)'.
[12:01] <Keybuk>   (Details: serial 57 error_code 11 request_code 140 minor_code 19)
[12:02] <slomo_> Keybuk: hm, i only knew that one from totem-xine until now... since when do you have this?
[12:02] <Keybuk> isn't me, it's a new user
[12:02] <Keybuk> has it since installing dapper at the weekend
[12:02] <Keybuk> definitely totem-gstreamer
[12:05] <slomo_> you could tell him to try renaming /usr/share/totem/totem_logo.png to something else... at least for totem-xine it is caused by the logo which would need more X memory then available. maybe not enough video ram or something...