[12:07] <mdz> TMM: I looked at the bug list for gnome-panel
[12:08] <mdz> TMM: where did you see 'edgy bugs'?  wherever that is, it's a red herring and doesn't mean what it says
[12:08] <HiddenWolf> mdz, it's the list of bugs targetted at edgy
[12:08] <mdz> TMM: that's not quite the same as "the entire X experience feels very sluggish"
[12:08] <HiddenWolf> distros/ubuntu/edgy/+bugs
[12:08] <mdz> HiddenWolf: which is not edgy bugs
[12:08] <HiddenWolf> mdz, easy to make the mistake. ;)
[12:08] <mdz> HiddenWolf: yes, but where in the UI links to that and calls it edgy bugs?
[12:08] <TMM> mdz: https://launchpad.net/distros/ubuntu/edgy/+bugs
[12:09] <HiddenWolf> mdz, it doesn't, but the url seems to suggest "list of bugs in edgy"
[12:09] <HiddenWolf> mdz, But I guess people will figure out that edgy has more than 0 bugs.
[12:09] <mdz> HiddenWolf: and given that launchpad doesn't keep track of which bugs are in which release, how do you figure that would work? :-)
[12:09] <TMM> mdz: that is just an extreme example, the rest just 'feels' a bit sluggish
[12:10] <TMM> mdz: like, text scrolling up in xchat-gnome takes just a little too long, opening a menu is just a fraction 'off' 
[12:10] <HiddenWolf> mdz, I was just explaining where the confusion came from, since I end up at that page instead of ubuntu/+bugs regularly myself. :)
[12:10] <TMM> mdz: right then, I just arrived at that page, and, didn't know what to do. I'm not a big malone user (yet)
[12:12] <mdz> TMM: I'd like to know how you got there; nothing should link to that (because there's no mechanism to make it do what it should)
[12:12] <HiddenWolf> mdz, it's linked to allright
[12:12] <HiddenWolf> https://launchpad.net/distros/ubuntu/edgy has a bugs link
[12:13] <TMM> mdz: well, I was being a stupid 'user' so I dod : https://launchpad.net/ > The Ubuntu distribution > Ubuntu milestones:/ ubuntu-6.10 > For:  Ubuntu  Edgy  
[12:13] <HiddenWolf> and the /edgy page is easily gotten to from any link that lists the edgy release
[12:13] <TMM> that gets you
[12:13] <TMM> https://launchpad.net/distros/ubuntu/edgy
[12:13] <TMM> then I clicked on 'bugs'
[12:13] <TMM> perhaps I am stupid, but that SEEMED logical at the time
[12:14] <Kamion> https://launchpad.net/distros/ubuntu/+bugs links there too
[12:14] <Kamion> under "Release bugs"
[12:14] <Kamion> googling for link:https://launchpad.net/distros/ubuntu/edgy/+bugs also lists https://launchpad.net/distros/ubuntu/dapper/+bugs, for the same reason
[12:15] <TMM> mdz: anyway, I'm still not sure what I should do about the whole sluggishness thing :) just file a bug against xserver-xorg or something?
[12:15] <mdz> TMM: I think you may be imagining the sluggishness after noticing that direct rendering was disabled ;-)
[12:16] <mdz> I've lost direct rendering as well but have not noticed any difference
[12:16] <bddebian> heh
[12:17] <bddebian> mdz: Can't do mythtv until libiec61883 gets out of NEW :-(
[12:17] <wasabi_> Do we have any centralized system that deals with debian/watch files?
[12:17] <TMM> mdz: err... no :) I know what 'direct rendering' is for :) 
[12:17] <wasabi_> Launchpad could!
[12:17] <bddebian> wasabi_: Deals with them in what way?
[12:18] <mdz> wasabi_: https://launchpad.net/products/launchpad-bazaar/+spec/tracking-versions
[12:18] <wasabi_> Notifies the author, marks the package.
[12:18] <mdz> tada
[12:18] <wasabi_> Neato.
[12:18] <bddebian> Ah
[12:18] <mdz> retroactive feature specifications
[12:18] <wasabi_> Haha
[12:18] <wasabi_> "should be rolled out"
[12:19] <mdz> meaning it was already partially implemented before that was written
[12:19] <TMM> mdz: like, if I overlap xchat-gnome with a fullscreen terminal, and I minimize it again, I can see the chat-portion being redrawn from a dull-gray. I am very sure that I didn't see anything like that on dapper.
[12:19] <wasabi_> Neat. The Wiki page is private though. =(
[12:19] <wasabi_> That is a wee bit annoying.
[12:19] <wasabi_> And offends my sensibilities. ;)
[12:19] <mjg59> Oh argh
[12:19] <mjg59> It doesn't even approximately build with gcc 4
[12:19] <mdz> wasabi_: there is nothing I can do about that
[12:20] <TMM> mjg59: fun, fun fun! :)
[12:20] <mjg59> Or, indeed, gcc-3.3
[12:20] <mjg59> Maybe I'm doing something wrong
[12:20] <wasabi_> I suspected as much.
[12:20] <mdz> mjg59: and you want it in main? :-P
[12:20] <mjg59> Ah, yes, it's just a crack-addled build system
[12:20] <mjg59> mdz: You want high-res bootsplash?
[12:20] <mdz> mjg59: depends on the price
[12:21] <mjg59> mdz: It's actually fine with gcc 4
[12:22] <TMM> mdz: so... I just ignore this then? :)
[12:26] <Ubugtu> Malone bug 45200 in ubiquity "[Flight 7]  installer crashed trying to select partition for mount point" [Medium,Confirmed]  http://launchpad.net/bugs/45200
[12:26] <mjg59> Oh nngh symbol mangling
[12:28] <gnomefreak> Kamion: sorry about the bug that i rejected. the part i have no more info is what got me on that
[12:28] <Kamion> gnomefreak: it was on the edge, but it made some degree of sense to me
[12:29] <Kamion> for you guys it's a matter of trying to guess whether the responsible developer will have enough information
[12:29] <mdz> TMM: I'm more concerned about the fact that starting gdm hangs the entire system requiring a power cycle on my laptop
[12:29] <mdz> (bug 54650)
[12:29] <Ubugtu> Malone bug 54650 in xserver-xorg-video-ati "[Edgy]  System freezes when loading gdm" [High,Confirmed]  http://launchpad.net/bugs/54650
[12:30] <mdz> you're getting off easy
[12:30] <Kamion> severity: breaks-mdz-hardware
[12:30] <TMM> mdz: ghe :) 
[12:30] <bddebian> hehe
[12:30] <mdz> I think I just managed to blame SSP for that though
[12:30] <imbrandon> heh
[12:31] <TMM> mdz: still, I'd like to try and fix it, but, it seems that xorg 7.1 fixes it for me anyway... so, I'll just hope that's what goes into edgy
[12:31] <gnomefreak> TMM: its in edgy atm (not fully i dont think)
[12:31] <TMM> edgy has 7.0.0 with aiglx enabled by default... straaange 
[12:31] <TMM> gnomefreak: the version for xserver-xorg is labeled as 7.0.22
[12:32] <mdz> hmm, false alarm
[12:32] <gnomefreak> hmmm i thought 7.1 started in
[12:32] <mdz> yes, it's 7.1
[12:32] <TMM> imbrandon: hey, you 'why don't you have a nice cup of' guy? :)
[12:33] <gnomefreak> thought so
[12:33] <mdz> TMM: no
[12:33] <imbrandon> TMM: huh ?
[12:33] <TMM> mdz: not here it isn't :) (well, not according to the version info anyway) 
[12:33] <TMM> imbrandon: sorry then :)
[12:33] <TMM> mdz: perhaps I have an outdated mirror
[12:33] <gnomefreak> TMM: no
[12:33] <mdz> TMM: either you're not up to date, or you're looking in the wrong place.  I'm curious to know how you confirmed it was fixed with xorg 7.1 then
[12:34] <gnomefreak> mdz: everyone has 7.0.22 maybe pre 7.1 base?
[12:34] <mdz> gnomefreak: the current packages in edgy come from xorg 7.1
[12:35] <gnomefreak> mdz: than not sure why version numbers are off
[12:35] <Kamion> 7.0.22 identifies a package containing some base scripts
[12:35] <Kamion> it is not a useful description of the upstream xorg version present on the system
[12:35] <mdz> correct
[12:35] <gnomefreak> ok
[12:35] <TMM> mdz: well, X -version says now "X Window System Version 7.1.1". and, it worked 'fine' with the xorg-air server from dapper, and that was just a 7.1 ... perhaps it got broken in 7.1.1 sorry about that
[12:35] <mdz> you looked at the version number of the 'xorg' package or such
[12:36] <mdz> TMM: dapper didn't have 7.1
[12:36] <TMM> mdz: backport from aiglx.compiz.info
[12:36] <gnomefreak> xorg and xserver-xorg show same
[12:36] <imbrandon> both show 7.0.22ubuntu7  but X -version shows 7.1.1
[12:36] <imbrandon> ( in edgy )
[12:37] <gnomefreak> correct
[12:39] <TMM> well, my cdrom drive's broken as well :P
[12:39] <TMM> I need to do some digging it seems :) nice :)
[12:39] <gnomefreak> TMM: cdrom 15 USD ;)
[12:40] <Kamion> gnomefreak: xorg and xserver-xorg both come from the same source package; neither actually provides the server binary, as 'dpkg -L' on each will show you
[12:40] <mdz> can you even buy CD-ROM drives anymore?
[12:40] <TMM> gnomefreak: no, the cdrom drive ITSELF works fine :) edgy just doesn't recognise mine anymore
[12:40] <gnomefreak> Kamion: ah ok
[12:40] <gnomefreak> mdz: i have 10 or so laying around
[12:40] <gnomefreak> lol
[12:41] <imbrandon> mdz: heh dont think so, most all dvd read and or dvd read / cdrw 
[12:42] <gnomefreak> imbrandon: you wouldnt happen to have the kubuntu logo in you K menu would you?>
[12:43] <TMM> hal doesn't recognises it anymore
[12:44] <gnomefreak> TMM: did you do todays updates? i think hal was updated this morning
[12:46] <TMM> gnomefreak: yes, I did
[12:46] <TMM> gnomefreak: I just upgraded from dapper today
[12:46] <gnomefreak> ah
[12:46] <gnomefreak> so the question was it working before the hal update is usless
[12:46] <TMM> I have only been running edgy for 4 hours or something now :)
[12:47] <gnomefreak> edgy has been fairly good so far been runnning it from day 1 and only had to reformat 2 times once was new harddrive 
[12:48] <wasabi_> I've been running the same install since... warty.
[12:48] <wasabi_> Heh. Can't say I've ever reformatted any Linux machines, except the ones I screw the fs up on.
[12:48] <HiddenWolf> wasabi, a reinstall fixed a bunch of bugs for me last week, but I had changed my hardware a bit.
[12:48] <HiddenWolf> wasabi, going from pci to onboard sound was less than stellar. :)
[12:49] <wasabi_> Shoulda fixed it, and bugged what you fixed. ;)
[12:49] <HiddenWolf> wasabi, I had no clue. It worked after a bit of tinkering, but the quality was aweful.
[12:50] <HiddenWolf> I thought I'd have to live with it till I got a new card, reformatted to get rid of an old disk I used, and on reinstall got a perfect quality audio.
[12:51] <Kamion> -rw-r--r--  1 root root 5 1999-06-09 21:11 /etc/hostname
[12:51] <Kamion> I guess that install is about that old
[12:51] <Kamion> iwj is going to win any dick-size wars of this kind, though
[12:52] <TMM> I'll just reinstall with fedora core 5 ;)
[12:52] <TMM> joke :)
[12:53] <HiddenWolf> Kamion, and your system is cruft-free? :)
[12:53] <LaserJock> Kamion: wow, they had Linux back then? ;-)
[12:53] <TMM> anyway, off to bed, I'll investigate this some more later 
[12:53] <TMM> bye!
[12:54] <Kamion> 1999 was only Debian slink or so
[12:55] <imbrandon> gnomefreak: you mean the side logo ? or the distributor-logo 
[12:56] <HiddenWolf> Kamion, and you've just copied your install along from pc to pc?
[12:56] <gnomefreak> imbrandon: the logo on the side runs vertictly
[12:56] <imbrandon> gnomefreak: yea i have that , afaik its on all kubuntu installs by default 
[12:56] <BenC> mjg59: Re: PAGE_MASK, no
[12:57] <Kamion> HiddenWolf: same computer, though it's had a few hard disk replacements; but there's been some kind of hardware continuity throughout
[12:57] <Kamion> still quite adequate for handling mail and IRC and stuff
[12:57] <gnomefreak> imbrandon: theres a bug with it in 3.5.4 dapper i cant duplicate it and i know you are on edgy i wanted to see if same for you
[12:57] <doko> infinity, Kamion: please approve openoffice.org_2.0.3-4dapper1 for dapper-proposed
[12:57] <HiddenWolf> Kamion, ah, cheers
[12:58] <imbrandon> gnomefreak: sure lets goto k-devel to not clog up in here
[12:58] <gnomefreak> ok
[01:01] <Kamion> doko: accepted
[01:02] <robertj> Kamion: do you have any thought on pitti's zero-conf uber-post?
[01:04] <mdz> mjg59: usplash 0.4-1 seems to work well on my T42 during shutdown, but upon reboot it doesn't start (no error output)
[01:04] <Kamion> robertj: no, I haven't caught up on ubuntu-devel in ages
[01:05] <robertj> https://lists.ubuntu.com/archives/ubuntu-devel/2006-July/019680.html
[01:05] <bluefoxicy> is there a list of all the officially approved release goals for ubuntu
[01:06] <bluefoxicy> like GccSsp and automated-problem-reports and the like, things that definitely are going in?
[01:06] <robertj> bluefoxicy: at this point I think everything thats going in should theoretically have an approved spec in launchpad
[01:07] <Kamion> robertj: do I have to get involved in it? the core developers who've already spent time on it are competent; I don't see why I need to spend the time to bring myself up to speed as well
[01:07] <doko> cprov-dinner, infinity: please kill the sparc build of openoffice.org 2.0.3-4ubuntu1 in ubuntu edgy (it will fail due to a buggy pkg-create-dbgsym
[01:07] <bluefoxicy> robertj:  Eyeballing it there's somewhere in the neighborhood of 100-200 approved specs.
[01:08] <Kamion> (given my already high workload)
[01:08] <robertj> Kamion: no, I was just under the impression that you were interested, that's all, you certainly don't need to be involved in everything
[01:08] <Kamion> I think I commented on things going past, but TBH I'm not interested enough to take a side :-)
[01:08] <robertj> bluefoxicy: there are lots of priorities as well
[01:08] <robertj> bluefoxicy: so lots of the low stuff are approved if someone does them...
[01:09] <mdz> doko: you might be interested in bug 54650
[01:09] <Ubugtu> Malone bug 54650 in xserver-xorg-video-ati "[Edgy]  System freezes when loading gdm" [High,Confirmed]  http://launchpad.net/bugs/54650
[01:09] <mdz> doko: seems to be toolchain related
[01:11] <doko> mdz: ohh, nice, pitti will be happy as well :-/
[01:11] <imbrandon> who was wanting the edgy usplash pictures if they dident look right ? ( edgy of course )  my poor iBook seems to not want to fill the screen with the test patern like my x86 boxes
[01:12] <mdz> doko: my X was broken for 2 weeks due to this ;-)
[01:12] <Kamion> could it be a gdm child process crashing due to an SSP check and then gdm hanging waiting for it, or something?
[01:12] <bluefoxicy> damn, looks like Xen won't fit in Edgy though.  Oh well.
[01:12] <doko> mdz: you know, I'm still working on dapper-updates on my T42 ;-)
[01:13] <robertj> imbrandon: iBook intel or ibook g3/g4?
[01:13] <imbrandon> iBook g3 800mhz
[01:13] <imbrandon> ppc
[01:13] <mdz> doko: do you think it's possible to track it down or should we just build the server with -fno-stack-protector?
[01:13] <imbrandon> there is no iBook intel afaik , only mac book pro == intel 
[01:13] <robertj> imbrandon: now that my wifes' new laptop is here I can upgrade my g3 to edgy, track me down a week or so from now ;)
[01:13] <bluefoxicy> iwj:  "We should consider whether we can have the default Edgy kernels support Xen out of the box (ie, provide xen-enabled kernels) now that recent Xen allows kernels to target both i386 and Xen/i386. -iwj"  <-- what, you mean I could boot a Xen kernel on straight i386 without Xen?
[01:14] <robertj> imbrandon: ibook was renamed macbook, macbook pro is the new powermac
[01:14] <robertj> but if it looks like a toilet, its an ibook
[01:14] <imbrandon> robertj: ahh ok no this is an orig iBook, but anyhow yea no biggie just wanted someone to know ;)
[01:14] <mdz> doko: I'm not even sure what part of it is breaking
[01:14] <robertj> err new powerbook
[01:14] <robertj> imbrandon: #ubuntu+1 might be a good spot too
[01:14] <robertj> and bugzilla
[01:14] <robertj> err launchpad
[01:15] <bluefoxicy> robertj:  I have been wanting a PPC arch for a while, to test Ubuntu PPC on... qemu on Ubuntu doesn't like PPC >:|  Fix qemu!  :D
[01:15] <imbrandon> robertj: yea i just rember from the ML that someone wanted actual picktures but i have no digi cam atm
[01:16] <imbrandon> bluefoxicy: yea it dosent like 2.6 kernels its a qemu-system-ppc thing
[01:16] <LaserJock> I finally got Dapper on my intel iMac the other day, it was nice to see the brown ;-)
[01:16] <imbrandon> LaserJock: nice
[01:16] <bluefoxicy> imbrandon:  I can't even get video up properly, much less reach grub
[01:17] <bluefoxicy> imbrandon:  or isolinux as it may be.
[01:17] <imbrandon> bluefoxicy: tried dist upgrading from the debian pre install that can be downloaded ?
[01:17] <bluefoxicy> nope
[01:18] <imbrandon> bluefoxicy: ok dont waste the time ( it dosent work lol ) but yea its a qemu / pearpc thing not ubuntu , no modern distros work on it
[01:18] <imbrandon> the debian thats preloaded is VERY old
[01:18] <imbrandon> ( as far as the ppc qemu of course )
[01:19] <doko> mdz: I'll have a look at it tomorrow, added it to https://wiki.ubuntu.com/GccSsp
[01:19] <imbrandon> one thing is the altecv stuff is very experimental etc
[01:19] <bluefoxicy> imbrandon:  I don't feel like trying again anyway, I had to go and manually download a video bios image from somewhere I found on google... I think Ubuntu has openhackware now so I don't need to go looking for a system bios... and after it all it still didn't work.
[01:20] <imbrandon> bluefoxicy: you can get it all from debian unstable ( if ou try in the future just FYI )
[01:21] <bluefoxicy> imbrandon: nods.
[01:21] <imbrandon> afaik the sparc cd's dont load in qemu-system-sparc either , havent looked into that much either but i'd assume its the same problem
[01:21] <bluefoxicy> imbrandon: I don't have money for a sparc either; why is ubuntu building for sparc again?
[01:22] <imbrandon> business servers , heh
[01:22] <Kamion> because we like to taunt you
[01:22] <bluefoxicy> Scalable Processor ARChitecture or something
[01:22] <mdz> doko: thanks
[01:23] <bluefoxicy> Kamion:  I don't think Sun will support you if you rm -rf solaris ;)
[01:32] <wasabi_> Wow. new root=UUID= thing.
[01:32] <wasabi_> Completely failed on my setup at work. Don't klnow why yet. EVMS.
[01:32] <mjg59> Magic, isn't it?
[01:33] <mjg59> Yes, there may still be a couple of issues
[01:33] <wasabi_> It's attempted magic. ;)
[01:33] <wasabi_> I like it. I'd like to see UUIDs used in more places though, obviously.
[01:33] <wasabi_> LIke fstab.
[01:33] <mdz> mjg59: mailed -devel with further usplash 0.4 experience
[01:33] <wasabi_> Even though it confuses the hell out of people reading fstab. ;)
[01:33] <mjg59> mdz: Ta
[01:34] <cprov-dinner> doko: build aborted and another bug discovered ... marked it manually as failed, should be enough for now.
[01:34] <wasabi_> Hmm. Also, any way /var/lock can be rebound during boot, instead of mounted over?   /var/lock/.hidden or something
[01:34] <mjg59> mdz: Works on amd64 as well now
[01:34] <doko> cprov-dinner: another soyuz bug?
[01:34] <wasabi_> Hiding it sort of makes it a pain for me to clean it up to stop the annoying message on boot.
[01:35] <cprov-dinner> doko: what a surprise :(
[01:35] <mdz> mjg59: sabdfl is going to kiss you
[01:35] <mjg59> mdz: I'll accept booze
[01:36] <mjg59> mdz: Autodetecting the correct resolution is going to be a pain
[01:36] <mjg59> And it's possible that this will fuck up horribly on some machines
[01:36] <mjg59> But I think it's got a better chance than vesafb, so it's worth a go
[01:36] <wasabi_> Attempt to get a high res usplash?
[01:36] <mjg59> wasabi_: Oh, it works
[01:36] <wasabi_> Nifty. If only I could make my BIOS stfu.
[01:37] <HiddenWolf> wasabi, not without killing it, I'm afraid.
[01:39] <mjg59> mdz: There's bloat of about 250K as a result of this
[01:39] <mjg59> Plus any extra bloat caused by increased artwork size
[01:39] <mjg59> Someone could probably trim that down
[01:40] <mdz> mjg59: uncompressed?
[01:40] <mjg59> Oh, it's probably only about an extra 100K once gzipped
[01:40] <mdz> ha
[01:40] <mdz> ah
[01:40] <mjg59> So I guess it could be worse
[01:42] <mdz> mjg59: it's statically linking svgalib I assume/
[01:42] <mdz> ?
[01:42] <mjg59> Getting svgalib to use x86emu was the only really painful part of this
[01:42] <mjg59> mdz: Yeah
[01:44] <Kamion> wasabi_: um - fstab is converted to UUIDs on upgrade to edgy
[01:44] <Kamion> (libvolumeid0)
[01:44] <wasabi_> Oh looky there. You are correct.
[01:45] <mdz> wasabi_: you can mount --move it and then clean it out
[01:45] <mdz> at least intuitively that should work
[01:46] <mdz> that message is pointless, we should just disable it
[01:46] <wasabi_> Agreed.
[01:46] <mdz> it uglifies usplash too
[01:46] <wasabi_> It's pretty typical for programs not to clear /var/lock on shutdown.
[01:46] <wasabi_> So, most ugprades to edgy will end up with it.
[01:47] <wasabi_> Actually, I guess dapper has it too.
[01:47] <wasabi_> So they have it now. :)
[01:48] <mdz> wasabi_:  there are directories in /var/run managed by the packaging system; there will always be something there
[01:48] <mdz> and nothing has a  chance to clear them out at shutdown anyway; they stay mounted until quite late
[01:50] <wasabi_> Wonder how long it will take the unix diehards to complain about the disaster fstab just became.
[01:50] <Kamion> it took about ten minutes
[01:50] <Kamion> the comments do help though
[01:50] <Kamion> and they'll see the point as soon as /dev/hd* becomes /dev/sd* ;-)
[01:50] <wasabi_> Heh.
[01:51] <Seveas> it should be possible to mount disk id's instead of /dev/foo
[01:51] <wasabi_> Yeah. 'mount' needs love.
[01:51] <Seveas> mount -t ricer UUID:31312329381231 /var 
[01:51] <mjg59> Oh oops
[01:51] <crimsun> it's possible for a few fs types already
[01:52] <mjg59> mdz: is usplash maintained in bzr?
[01:52] <HrdwrBoB>  I use LVM for that reason
[01:52] <Seveas> mjg59, lp.net/products/usplash/+branches
[01:52] <mjg59> Right
[01:53] <wasabi_> Wonder how network block devices deal with UUIDs
[01:53] <mjg59> I need something that bitches at me when I do things like modify packages that should be kept there
[01:53] <wasabi_> Do the UUIDs come from the file systems? or the device?
[01:53] <mjg59> wasabi_: The fs
[01:53] <wasabi_> And then, what about dm devices?
[01:53] <Seveas> mjg59, it's called "keybuk"
[01:53] <mdz> mjg59: yes
[01:53] <wasabi_> It's reasonable for /dev/hd* and /dev/md* and /dev/lvm* and /dev/evms/* to all point to the same fs.
[01:53] <wasabi_> Hence, have the same UUID.
[01:53] <mdz> mjg59: I have a script which checks the wiki and bitches at me
[01:53] <wasabi_> That might actually be my issue. ;)
[01:54] <mdz> at least, it's meant to.  I don't think I've tested it
[01:55] <mdz> hmm, it doesn't
[01:55] <mdz> because the wiki gives it a 403 for some reason
[01:56] <mdz> apparently, wget isn't allowed to do ?action=raw
[01:56] <mdz> that's pretty lame
[01:57] <wasabi_> \?
[01:58] <mjg59> How long does it take between adding a public key and it hitting the hosts?
[01:59] <mjg59> Oh, approximately no time at all
[01:59] <bluefoxicy> anyone know how I could find out all the optimizations (LDFLAGS and CFLAGS) that stuff is built with on Ubuntu's build servers?
[01:59] <bluefoxicy> preferably without logging into the build servers, since you know, I don't have an account and don't belong there :>
[01:59] <Kamion> bluefoxicy: apt-get source $package
[01:59] <Kamion> and the gcc default
[01:59] <Kamion> s
[02:00] <Kamion> there's no buildd magic
[02:00] <bluefoxicy> Kamion:  it's built with i486 instrs and i686 scheduling, with -Wl,-O1, etc... so that's all in gcc defaults?
[02:00] <Kamion> yes
[02:01] <Kamion> well, not -Wl,-O1, that's only done in certain packages
[02:01] <Kamion> contrary to rumour it is not done globally
[02:01] <bluefoxicy> I thought it was system-wide on the buildd
[02:01] <Kamion> it's not
[02:01] <Kamion> (to my knowledge)
[02:01] <bluefoxicy> wow.  I asked months ago and numerous people said it was done globally.
[02:03] <Kamion> even when we used gcc-opt to override gcc flags on the buildds - which we don't any more as of edgy - I'm pretty certain that it never knew how to override linker flags
[02:04] <Kamion> all it did was force compiler flags to be within certain optimisation ranges
[02:04] <bluefoxicy> heh
[02:04] <Kamion> oh, and set -mtune=pentium4 -march=i486, but those are the gcc defaults now
[02:05] <bluefoxicy> Kamion: Maybe you should start thinking about optimizing linker flags after Edgy is out, it'd make for good discussion, re http://lwn.net/Articles/192624/
[02:05] <Kamion> not me personally
[02:05] <bluefoxicy> no, not you personally :P
[02:08] <mjg59> mdz: Right. I haven't fixed the init script, but nobody will actually be getting their hands on it until svgalib is in main /anyway/
[02:09] <mjg59> mdz: Can we take individual binary packages from a source without pulling them all in? I'm not necessarily happy with the svgalib demo binaries, since they're probably all suid root. The library itself is fine.
[02:09] <Kamion> mjg59: yes
[02:09] <Kamion> please note that in the main inclusion report though
[02:11] <Kamion> so that we have a fighting chance of not accidentally promoting the demo binaries in future
[02:13] <gnomefreak> xgl/compiz are in official repos?
[02:16] <mjg59> gnomefreak: Yes, but currently old versions
[02:17] <gnomefreak> hmmm
[02:19] <mdz> mjg59: the primary reason we keep it out of main is to prevent nasty suid binaries from creeping in through other packages
[02:20] <gnomefreak> mdz: i say kick it out all together
[02:20] <mdz> gnomefreak: I was talking about svgalib
[02:20] <gnomefreak> oh
[02:22] <mjg59> mdz: Right
[02:23] <mdz> mjg59: though the main inclusion process should prevent that just as well nowadays
[02:23] <mdz> except where Debian introduces something without our knowledge
[02:24] <mjg59> mdz: To be honest, I'd be quite tempted to say that we can't support all of its code
[02:24] <mjg59> But the chances of anyone actually having hardware old enough that svgalib claims to support it (other than through vesa) is, well, small
[02:24] <mdz> mjg59: would it be feasible to copy the bits you need into usplash, as with bogl?
[02:25] <mjg59> mdz: Not in any remotely trivial manner
[02:25] <mjg59> The build system is a nightmare
[02:25] <mdz> I'd like to find a way to let it into main for usplash without exposing us to any potential evils
[02:25] <mjg59> Sure
[02:25] <mdz> maybe I'm paranoid; it's probably unlikely that new suid programs are popping up due to svgalib
[02:26] <mdz> in this day and age
[02:26] <mdz> one would hope
[02:26] <mjg59> It wouldn't be /too/ difficult to add a new source package that just builds the vesa support
[02:26] <mjg59> There's a pile of defines to enable and disable individual drivers
[02:32] <mdz> mjg59: perhaps we could fix it to blow up if it detects  it's running suid
[02:32] <Kamion> mdz: could you have a look through ubiquity 1.0.14 in dapper-updates? it's mostly translation updates and just a couple of small bug fixes; I changed the progress bar like you asked too
[02:33] <Kamion> (it's uploading at the moment)
[02:33] <mdz> Kamion: I assume it's suitable for upgrading a dapper live CD and testing?
[02:33] <Kamion> mdz: if you could accept it at some point over the next day if it's OK, that would be good
[02:33] <Kamion> mdz: yes; make sure you upgrade ubiquity, ubiquity-frontend-gtk, and ubiquity-ubuntu-artwork, and probably gparted as well
[02:34] <Kamion> one of these days I should tighten the dependencies there
[02:34] <mdz> Kamion: is it finished uploading?
[02:34] <Kamion> yes, just
[02:34] <mjg59> mdz: Sure
[02:34] <mjg59> mdz: Though that might break other apps
[02:34] <mjg59> mdz: ISTR quake using it for mode setting and needing to be suid as a result...
[02:35] <Kamion>    78120 | S- | ubiquity             | 1.0.14               | 5 seconds
[02:35] <Kamion>          | * ubiquity/1.0.14 Component: main Section: admin
[02:35] <mdz> just made the queue run it looks like
[02:36] <mdz> Kamion: is it safe to build it on edgy and for installation on dapper, for testing purposes?
[02:36] <mdz> s/and /
[02:36] <Kamion> mdz: I wouldn't recommend it
[02:36] <Kamion> I'm not sure what the current python toolchain will do
[02:37] <Kamion> and it build-depends: libparted1.6-dev which is dead in edgy
[02:37] <Kamion> you can build it on the live CD; if you want to avoid too many build-deps, skip installing python-kde3-dev and build with UBIQUITY_NO_KDE=1 set in the environment
[02:38] <Kamion> I do that all the time
[02:38] <mdz> ok
[02:38] <mdz> do you have a cut-and-waste handy for the list of packages I need on top of the live CD?
[02:39] <Kamion> afraid not - I do build-essential devscripts fakeroot, then cut-and-paste from dpkg-checkbuilddeps output
[02:39] <Kamion> unfortunately its output is not in the most convenient format
[02:40] <mdz> apt-cache showsrc "$1" | grep-dctrl -nsBuild-Depends '' |head -1 | \
[02:40] <mdz>         sed -e 's/ ([^)] *)//g' -e 's/,//g'
[02:40] <Kamion> build-essential devscripts fakeroot apt bison debhelper dpkg-dev flex grep-dctrl intltool-debian iso-codes libart-2.0-dev libdebconfclient0-dev libdebian-installer4-dev libglib2.0-dev libgtk2.0-dev libparted1.6-dev libxml-parser-perl locales po-debconf python python-gtk2-dev python-xml python2.4-dev wget
[02:40] <Kamion> I guess that would do
[02:40] <Kamion> (didn't bother trimming, as you can tell)
[02:41] <Amaranth> what's the magic to build a package without stripping it?
[02:41] <Kamion> Amaranth: DEB_BUILD_OPTIONS=nostrip; see the dh_strip(1) man page
[02:42] <Amaranth> ah, thanks
[02:43] <mdz> Kamion: eek, 206MB
[02:44] <mdz> (with kde)
[02:44] <mdz> still 90M without
[02:44] <mdz> this machine has plenty of RAM though, fortunately
[02:44] <Kamion> that's why I did the UBIQUITY_NO_(GTK|KDE) thing ...
[02:46] <mdz> Kamion: has riddell tested this version on Kubuntu?
[02:46] <Kamion> mdz: I don't believe so
[02:48] <mdz> Kamion: please ask him to do so before we roll kubuntu for the point release
[02:50] <mdz> sort-countries certainly takes a long time
[02:50] <Kamion> it's running localedef a lot
[02:54] <mdz> Kamion: I just noticed that dapper-updates isn't in sources.list on the dapper live CD
[02:54] <mdz> we ought to fix that in the point release, if it isn't automagically fixed in the process
[02:55] <Kamion> I believe it is; the livefs build process for dapper involves an update/upgrade to dapper-{security,updates}
[02:57] <mdz> test install is in progress
[03:04] <mdz> Kamion: the more I look at the time remaining indicator in ubiquity, the more I feel that (in edgy) we should change it to display "about N minutes" and forget seconds
[03:05] <Kamion> mm, quite possibly
[03:05] <mdz> that's what both macos and windows did the last I saw, and it's a smoother experience
[03:07] <Kamion> need to check what they do once it gets below a minute
[03:07] <Kamion> (since I'll probably need separate debconf templates to make both situations translatable)
[03:09] <mdz> Kamion: I think it's "less than 1 minute remaining" or even still "about 1 minute"
[03:12] <mdz> Kamion: 1.0.14 accepted
[03:17] <Kamion> thanks
[03:41] <robertj> mdz: will install stages have artwork in the point?
[03:41] <robertj> or at least have all the stuff leff justfied
[03:41] <mdz> robertj: point releases are bug fixes only
[03:42] <mdz> not eye candy
[03:42] <robertj> mdz: I know, but I thought you might have received the artwork anyway and its about as low-risk as you can get
[03:42] <mdz> besides which, nobody has implemented such a feature
[03:42] <robertj> mdz: I thought it was contracted out
[03:43] <mdz> there is neither artwork nor a place in the UI for it, in dapper or edgy
[03:43] <imbrandon> mdz yea on OSX its "less than 1 minute remaining" for > 60sec and "about 1 minute remaining" for > 2min but < 1min everything else is in minutes
[03:43] <mdz> imbrandon: I think your <> were backwards but I understand :-)
[03:44] <imbrandon> err yea LOL just noticed that hehe
[03:45] <imbrandon> without getting killed , can i ask the status of -backports / soyuz for edgy --> dapper ?
[03:58] <rodarvus> mdz, thanks for tracking #54650
[03:58] <rodarvus> I don't have this problem locally, and was having a hard time debugging it
[03:59] <rodarvus> it was apparently happening for via and (possibly) sis
[04:00] <mdz> rodarvus: as well as ati? eek
[04:01] <rodarvus> yup, but its not for all cases, very few ones, actually
[04:12] <LaserJock> imbrandon: what do you want to know?
[04:12] <imbrandon> LaserJock: ?
[04:13] <LaserJock> imbrandon: without getting killed , can i ask the status of -backports / soyuz for edgy --> dapper ?
[04:13] <imbrandon> ohh when soyuz was going to be able to let the bckports team start to process them 
[04:13] <imbrandon> afaik thats all that was lacking
[04:13] <LaserJock> I thought it already did
[04:14] <LaserJock> could be wrong
[04:15] <imbrandon> nope -backports still looks mighty empty 
[04:15] <imbrandon> and still lots waiting on LP to be backported , crimsun said it was becoue of lack of soyuz support a week or so ago
[04:15] <LaserJock> hmm
[04:16] <imbrandon> http://archive.ubuntu.com/ubuntu/dists/dapper-backports/main/source/Release
[04:16] <imbrandon> s/main/universe same thing
[04:26] <bluefoxicy> I uh.  Yeah I'll take that to the mailing list.
[04:27] <bluefoxicy> Er.  Is now not the best time to get on about Edgy+1 toolchain details on -devel?
[05:31] <crimsun> My kde-guidance (0.6.7-3ubuntu2) upload (fixing bug 54742) 92 minutes ago seems to have been eaten by a grue.
[05:31] <Ubugtu> Malone bug 54742 in kde-guidance "Broken symlinks in kde-guidance-0.6.7-3ubuntu1" [Medium,Fix released]  http://launchpad.net/bugs/54742
[05:35] <bddebian> A grue? Haha, I haven't heard that in forever
[05:42] <robertj> bddebian: grues have been almost hunted to extinction by their natural predator, the wumpus
[05:43] <bddebian> :-)
[05:43] <bddebian> And cats hunt wumpus, hence catty wumpus?
[05:43] <bddebian> OK, that was really bad.. :-)
[05:57] <bluefoxicy> what the fuck
[05:57] <bluefoxicy> I am going to assume everyone here is on edgy
[05:57] <bluefoxicy> On that note I strongly advise examining your swap layout
[05:57] <bluefoxicy> bluefox@icebox:/tmp/x$ swapon -s
[05:57] <bluefoxicy> Filename                                Type            Size    Used    Priority
[05:57] <bluefoxicy> /dev/sda5                               partition       2104472 408120  -1
[05:57] <bluefoxicy> /dev/evms/sda5                          partition       2104472 0       -2
[05:58] <bluefoxicy> because my kernel thinks I have 4 gigs of swap and I'm not sure what happens once I fault through the first swap file.
[05:58] <bluefoxicy> # /dev/sda5 -- converted during upgrade to edgy
[05:58] <bluefoxicy> UUID=c3e782d2-8f84-4ac9-b7da-1b2bb89c5b1d none swap sw 0 0
[05:58] <bluefoxicy> this MAY be the culprit
[06:00] <jcsmith> hi all: is there an overview of whats planned for edgy out there anywhere thats somewhat up to date?
[06:06] <TheMuso> bluefoxicy: I seem to be showing twice the amount of swap I should have.
[06:07] <bluefoxicy> TheMuso:  swapon -s plz.
[06:08] <TheMuso> luke@linden:~$ swapon -s
[06:08] <TheMuso> Filename                                Type            Size    Used    Priority/dev/sda2                               partition       1052248 0       -1
[06:08] <TheMuso> /dev/evms/sda2                          partition       1052248 0       -2
[06:08] <TheMuso> SOrry bout the formatting
[06:10] <bluefoxicy> TheMuso:  yeah..... that would be it.
[06:11] <bluefoxicy> I'm going to mark this bug critical.  Just a guess.
[06:11] <bluefoxicy> oh nm.  I can't mark importance apparently so https://launchpad.net/distros/ubuntu/+bug/54753  Have fun.
[06:11] <Ubugtu> Malone bug 54753 in Ubuntu "Edgy double-adds swap" [Untriaged,Unconfirmed]  
[06:11] <TheMuso> I'll add a comment to that.
[06:13] <TheMuso> Hey Hobbsee 
[06:14] <TheMuso> You in edgy atm?
[06:14] <Hobbsee> hi TheMuso. yep
[06:14] <TheMuso> Could you please paste the output of swapon -s command please?
[06:15] <TheMuso> Seems there is something funny going on with swap and the newly created UUIDs in fstab.
[06:15] <Hobbsee> sarah@sarah:~$ swapon -s
[06:15] <Hobbsee> Filename                                Type            Size    Used    Priority
[06:15] <Hobbsee> /dev/hda6                               partition       546168  0       -1
[06:15] <Hobbsee> /dev/evms/hda6                          partition       546168  0       -2
[06:15] <Hobbsee> TheMuso: ^
[06:15] <TheMuso> Ok you have it to.
[06:15] <bluefoxicy> TheMuso:  I think it's safe to confirm this one ;)
[06:16] <TheMuso> Yeah.
[06:16] <Hobbsee> uh oh, i've got the "kopete is too old" bug again
[06:17] <TheMuso> bluefoxicy: I am going to try without evms installed and see what happens.
[06:17] <TheMuso> brb
[06:20] <TheMuso> That is better, at least for the moment.
[06:21] <TheMuso> It is kinda easy when you don't use evms.
[06:21] <bluefoxicy> I would be thoroughly amused if someone had a couple hundred megs in the first swap device and decided to shut it off
[06:21] <bluefoxicy> and it wrote it all into the evms copy
[06:21] <TheMuso> evms gets installed by default and loads anyway
[06:21] <bluefoxicy> and went WHAT THE HELL HELP *panic()*!
[06:21] <Hobbsee> true
[06:22] <TheMuso> hmmm
[06:22] <TheMuso> Evms doesn't exist in the edgy archive.
[06:22] <Hobbsee> bluefoxicy: TheMuso any idea what that package should be?
[06:23] <bluefoxicy> what package?
[06:23] <TheMuso> Hobbsee: sudo apt-get --purge remove evms should be alright
[06:23] <TheMuso> evms
[06:23] <bluefoxicy> oh, no clue.  bug #54753
[06:23] <Ubugtu> Malone bug 54753 in Ubuntu "Edgy double-adds swap" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54753
[06:23] <TheMuso> Seems like it no longer exists in edgy
[06:23] <Hobbsee> bluefoxicy: yeah, i just saw it in -bugs and confirmed it
[06:23] <bluefoxicy> but I don't think it's evms' fault, maybe.  More ljke the init scripts.
[06:24] <bluefoxicy> or the kernel
[06:24] <bluefoxicy> the kernel should probably refuse to do it.
[06:25] <TheMuso> hmmm
[06:31] <TheMuso> Hobbsee: You also need to re-configure your initramfs to get rid of evms from it.
[06:32] <Hobbsee> TheMuso: eek?
[06:32] <TheMuso> Well it does have initramfs hooks.
[06:32] <TheMuso> s/reconfigure/rebuild/
[06:32] <TheMuso> for initramfs
[06:34] <pitti> Good morning
[06:34] <ajmitch> morning pitti 
[06:36] <Hobbsee> hi pitti 
[06:36] <Hobbsee> oh yay, two uploaders to main
[06:36] <pitti> hi ajmitch, moin Hobbsee 
[06:37] <pitti> infinity: once pkg-create-dbgsym 0.5 is in the buildd chroots, can you please give-back openoffice.org?
[06:42] <pitti> infinity: ^ nevermind, doko uploaded a new version anyway
[06:55] <bluefoxicy> so does anyone know when a good time would be to discuss edgy+1 toolchain things?
[07:05] <jsgotangco> the development summits are a good time to discuss it with an appropriate spec i guess
[07:07] <Hobbsee> bluefoxicy: were you planning to go to the edgy+1 dev summit?
[07:07] <bluefoxicy> Hobbsee:  Not unless it's in Baltimore.
[07:09] <imbrandon> anyone else having truble connecting to archive.u.c or gb.archive.u.c ?
[07:09] <Hobbsee> ah ok
[07:09] <Hobbsee> imbrandon: no
[07:13] <tritium> Hobbsee: the chupacabra did it
[07:13] <imbrandon> lol
[07:13] <Hobbsee> tritium: hehe.  i believe it was bits of compiling.
[07:13] <tritium> Hobbsee: :)
[07:15] <bluefoxicy> jsgotangco:  there's already stuff at https://wiki.ubuntu.com/EdgyPlusOneToolchainRoadmap and I appended a few things to it but there are some interesting thoughts I've had along the way.  Plus I'm still itching to get pax-utils into universe and the 'janitors team' gives me an excuse ;)
[08:21] <Amaranth> pitti: slam dunk
[08:21] <Amaranth> (avahi)
[08:21] <Burgundavia> Amaranth: ?
[08:21] <Amaranth> Burgundavia: his mail to u-d about avahi, it was the perfect response
[08:22] <ajmitch> now we just need one to shut up the mono thread
[08:23] <Amaranth> ajmitch: Go right ahead. :)
[08:23] <pitti> Amaranth: ?
[08:23] <Hobbsee> bleh.  debian added two versions, but didnt actually fix what they botched.
[08:23] <pitti> Amaranth: oh, avahi is on topic for today's TB meeting :)
[08:24] <Amaranth> today's?
[08:24] <Burgundavia> pitti: great email, lays out an exact course
[08:24] <Amaranth> oh, i guess i did just flip over to tuesday
[08:26] <Burgundavia> Amaranth: where in the real world are you?
[08:26] <Amaranth> iowa
[08:26] <Amaranth> middle of the US
[08:26] <Amaranth> it's actually 0126 here
[08:26] <Burgundavia> you are near nuzum then
[08:27] <Amaranth> so by 'just' i mean 'wow, that's the first time i noticed it was tuesday'
[08:27] <Hobbsee> heh
[08:27] <Hobbsee> @time sydney
[08:27] <Ubugtu> Current time in Australia/Sydney: August 01 2006, 16:27:12
[08:27] <Hobbsee> stop living in the past, you :P
[08:27] <Amaranth> where is nuzum?
[08:27] <neuralis> ff/win 1
[08:27] <neuralis> er.
[08:27] <Hobbsee> any core devs feel like uploading a couple of things for me?
[08:28] <Burgundavia> neuralis: uh?
[08:28] <Burgundavia> Hobbsee: why don't you apply for yourself?
[08:28] <Hobbsee> Burgundavia: you're as bad as crimsun.  do you think i'd get it?
[08:28] <Hobbsee> Burgundavia: but then again, there *is* a meeting tomorrow....
[08:28] <Burgundavia> Hobbsee: despite a little kde brain damage ;), I see lots of uploading into main recently
[08:28] <Burgundavia> plus a good track record
[08:29] <Hobbsee> Burgundavia: hehe yeah, it's getting pretty hard to find uploaders.  
[08:29] <crimsun> Hobbsee: I can try
[08:29] <crimsun> Hobbsee: my key issue might bite again, we can see.
[08:29] <pitti> Hobbsee: toss me a debdiff and I'll check/upload it
[08:29] <Hobbsee> pitti: okay.  debdiff is at http://buntudot.org/people/~hobbsee/kopete.debdiff  - to go on kopete in edgy :)
[08:30] <Hobbsee> hi dholbach!
[08:30] <Hobbsee> crimsun: dont feel left out, i have another one, i'm just double checking that debian's changes semi-work.
[08:30] <dholbach> hey Hobbsee, hey pitti! howare you?
[08:30] <dholbach> good morning everybody
[08:30] <Hobbsee> dholbach: i'm fixing things :D  in main :D
[08:30] <crimsun> Hobbsee: heh, uploading for me is a 50/50 thing. Either it works brilliantly, or I get no feedback at all.
[08:31] <dholbach> Hobbsee: ROCK ON
[08:31] <Hobbsee> crimsun: heh
[08:31] <pitti> dholbach: a little tired, I woke up too early; but good enough :)
[08:31] <Hobbsee> dholbach: now i should go for core, i'm told :P
[08:31] <dholbach> pitti: when did you wake up?
[08:31] <pitti> dholbach: at 6, my hayfever struck again
[08:31] <dholbach> urg :/
[08:32] <pitti> Hobbsee: kopete_3.5.4+kopete0.12.1 ???
[08:32] <pitti> yay for version number sanity
[08:32] <Hobbsee> pitti: that's the one.  yeah, i know.
[08:33] <Hobbsee> pitti: it's not nice.  and i was the one to version it that way.  there is a reason behind it
[08:33] <pitti> Hobbsee: uploaded
[08:33] <Hobbsee> pitti: thankyou :)
[08:33] <pitti> Hobbsee: well, it should be 3.5.4+0.12.1
[08:33] <Hobbsee> pitti: wish icq wouldnt change their protocols so often :P
[08:33] <Hobbsee> pitti: i think i tried that....and it wasnt updating.  we had trouble, anyway
[08:33] <pitti> heh, IRC is like X, 'twenty years and still binary compatible' :)
[08:34] <pitti> Hobbsee: no, nevermind, 3.5.4+0.12.1 << 3.5.4+kopete0.12.1
[08:34] <Hobbsee> pitti: yeah, that's what i think we found
[08:34] <pitti> Hobbsee: just a small morning rant, that's all :)
[08:34] <Hobbsee> pitti: hehe, that's okay :)
[08:36] <bluefoxicy> copy and paste is being shit and it's really really REALLY starting to piss me off but I cannot determine EXACTLY what the problem is and "C&P is being shitty" is not a good bug report!  >:|
[08:37] <bluefoxicy> it seems to only affect certain applications
[08:37] <bluefoxicy> except those applications can destroy the clipboard for other applications and I'm not sure which is which
[08:37] <bluefoxicy> but one of them is definitely xchat-gnome
[08:37] <Hobbsee> hehe.  i thought that about my "keyboard randomly stops working" error - how on earth do you go about debugging that???
[08:38] <bluefoxicy> Hobbsee:  can of raid and a screw driver.
[08:38] <Hobbsee> bluefoxicy: hehe
[08:38] <Hobbsee> bluefoxicy: it works when you log out of kde
[08:39] <Hobbsee> (cue reports of "dont use kde, problem solved)
[08:39] <bluefoxicy> don't-- damnit Hobbsee don't do that.
[08:39] <Hobbsee> hahaha
[08:42] <bluefoxicy> Hobbsee:  no joke, in my security class there were these two high school kids (yes this is at a college), one used KDE on Fedora and the other used GNOME on Ubuntu
[08:42] <bluefoxicy> and they started talking about DE's so I gave a simple technical explanation why KDE sucks, like 2 minutes.
[08:42] <bluefoxicy> For the rest of the class, every time they brought up linux
[08:42] <Burgundavia> Hobbsee: we hadn't noticed ;)
[08:43] <Hobbsee> Burgundavia: :P at you.
[08:43] <jsgotangco> let's not resurrect an age old war
[08:43] <bluefoxicy> "You use that stupid ubuntu thing when fedora is so much better, and what is with GNOME it's a pile of crap"
[08:43] <Hobbsee> jsgotangco: had no intention of it :P
[08:43] <Burgundavia> bluefoxicy: seriously, not here, try -offtopic
[08:43] <bluefoxicy>   "No way that ugly bloated desktop you use doesn't work half teh time and fedora breaks" blahblahblah on and on he couldn't say "KDE" it was funny.
[08:43] <bluefoxicy> Burgundavia:  hahaok :P
[08:43] <dholbach> bluefoxicy: admirable sentiments, but it's enough
[08:44] <bluefoxicy> haha
[08:44] <bluefoxicy> dholbach:  keybuk has ascii art of you
[08:44] <dholbach> bluefoxicy: i know
[09:13] <Kamion> crimsun: http://librarian.launchpad.net/3685578/vSLlaYID2s9avqQulVSjHfIUNSB.txt - may be transient, if that key is definitely good then my best advice is to try reuploading :-/
[09:14] <crimsun> ok, I'll try reuploading; it's the same key I've been using during Edgy thus far
[09:15] <Kamion> I've noticed similar weirdness before - need to make sure there's a Soyuz bug filed about it
[09:21] <Hobbsee> Kamion: when are you building the dapper point release?  which day this week?  i've got a fix that i want in.
[09:23] <Burgundavia> Hobbsee: all demand and no ask I see ;)
[09:23] <Hobbsee> Burgundavia: of course, of course :P  nah.  i will ask, when i ask him to upload it for me :)
[09:25] <crimsun> (oh, LP is down for maint.)
[09:32] <Kamion> Hobbsee: dunn
[09:32] <Kamion> o
[09:32] <Hobbsee> Kamion: in the next few hours?  /me is test building still.
[09:32] <Kamion> upload sooner rather than later if you want something in; I don't have an exact day
[09:33] <Kamion> I'm off work today (wife's birthday), so not in the next few hours
[09:33] <Hobbsee> Kamion: i'll be bugging you soon about it - but i will check that nothing has blown up first :P
[09:33] <Hobbsee> Kamion: ah, okay
[09:33] <Kamion> and not today, for that matter
[09:33] <Hobbsee> cool :)
[09:33] <Hobbsee> Kamion: enjoy your wife's birthday
[09:33] <Kamion> will do, we're off to the safari park
[09:33] <dholbach> Kamion: enjoy it!
[09:34] <Hobbsee> Kamion: ooh!  fun!  post pictures, or face my long pointy stick :P
[10:19] <dholbach> ogra: gnome-screensaver update for dapper? 2.14.3?
[10:21] <ogra> hmm, i have to look at the changes ...
[10:23] <mvo> jdub: is your apt-get problem with the latest edgy apt version solved (that it failed to download .bz2 files)?
[10:23] <Hobbsee> mvo: he's possibly still on a plane
[10:23] <mvo> Hobbsee: ah, thanks
[10:23] <Hobbsee> ogra: it's being suggested that i go for core tomorrow :)
[10:24] <Hobbsee> mvo: on his way from portland to sydney - not sure when he gets in though
[10:24] <\sh> moins
[10:24] <Hobbsee> hi \sh!
[10:25] <\sh> hey hobbsee....
[10:25] <ogra> Hobbsee, yay ... i'll cheer for you :)
[10:25] <ajmitch> mvo: was it downloading partial files & then failing?
[10:25] <Hobbsee> ogra: hehe!  thanks :)
[10:26] <Hobbsee> ogra: depends if i'm awake
[10:26] <mvo> ajmitch: no, not downloading .bz2 files at all, just .gz files
[10:26] <ogra> (it's today for me btw ;) )
[10:26] <Hobbsee> any ETA on when launchpad is back up?
[10:26] <Hobbsee> ogra: true.  that's because you like living in the past :P
[10:26] <ogra> haha
[10:26] <ajmitch> mvo: ok, I was having a different problem (and blamed my proxy)
[10:30] <mvo> ajmitch: proxies are evil!
[10:30] <mdke> Hobbsee: any time now, downtime was estimated to be 10 minutes
[10:30] <pygi> sivang, poke
[10:31] <Hobbsee> mdke: okay
[10:31] <mvo> infinity: what was your complain about gksu again? I'm currently looking into it
[10:31] <ajmitch> mvo: yes, it was not being happy with my local squid
[10:32] <mvo> ajmitch: oh? I have a local squid that works pretty good in my local net, no problems with apt. I usually blame proxies that are configured in a way that they are too agressive
[10:34] <Hobbsee> oh yay, LP is back
[10:34] <ajmitch> mvo: I'll try & reproduce it
[10:35] <mvo> ajmitch: ok, thanks
[10:43] <jdub> mvo: i'll have a poke now
[10:45] <Hobbsee> ah, jdub does exist!
[10:46] <mvo> jdub: thanks
[10:46] <jdub> morning
[10:47] <seb128_> hey jdub
[10:49] <Hobbsee> hi seb128_ 
[10:49] <seb128_> Hi
[10:49] <doko_> pitti: http://librarian.launchpad.net/3692782/buildlog_ubuntu-edgy-i386.openoffice.org_2.0.3-4ubuntu2_FAILEDTOBUILD.txt.gz :-(
[10:50] <infinity> mvo: The fact that it's now offering to save passwords (and appears to do so by default), which kinda defeats the whole "using sudo helps you know that you're doing stuff as root" thing.
[10:51] <infinity> Kamion: The pockets are traditionally meant to be self-contained.  Last time we did a d-i upload, I hacked up the chroots just for d-i to allow security.
[10:51] <mvo> infinity: right, I will disable the whole "default" thing at least
[10:52] <seb128_> I find it handy
[10:53] <pitti> mvo++
[10:53] <pitti> doko_: *boggle*
[10:54] <Hobbsee> infinity: you going to be around for a while? 
[10:54] <pitti> doko_: argh, indeed I did recoomends, suggests, conflicts, provides, breaks, depends, but I forgot about replaces; damn me :/
[10:54] <infinity> Hobbsee: Should be here all night.
[10:54] <Hobbsee> infinity: cool.  can you ack stuff to dapper-updates?
[10:55] <pitti> doko_: I'm terribly sorry, I fix it now, upload, and ask infinity to give-back once 0.6 is in the archive
[10:55] <infinity> Hobbsee: Depends.  Does it have approval from Kamion or mdz?
[10:56] <Hobbsee> infinity: nope
[10:56] <Hobbsee> infinity: kamion isnt working today, and it's too ealry for mdz
[10:56] <infinity> Hobbsee: I believe that, technically, I'm a member of the group allowed to give such approval, but I've not been oficially delegated this task, so I'm wary.
[10:56] <infinity> Hobbsee: If it's small and obvious, I'll look it over and take the heat for it, though.
[10:56] <Hobbsee> infinity: 1 line patch :P
[10:56] <Hobbsee> infinity: let me reboot and check that it works first though
[10:56] <infinity> Hobbsee: Excellent, then test away, and give me a debdiff before you upload.
[10:57] <Hobbsee> infinity: debdiff is at http://buntudot.org/people/~hobbsee/kdenetwork.debdiff - i'll be back in a few mins.
[10:57] <infinity> Hobbsee: Oh, yeah, if that is tested to work, I'm cool with that.
[10:58] <infinity> Hobbsee: Is the fix pulled from a new upstream or CVS or something?
[10:58] <Hobbsee> infinity: it's not yet, mainly cos i'm lazy :P
[10:58] <Hobbsee> infinity: from kde, yeah.
[10:58] <infinity> Hobbsee: Kay, then yeah.  Test it and get back to me, and I'm fine with it if it works.
[10:58] <pitti> Hobbsee: oh, is it that kopete fix?
[10:59] <Hobbsee> pitti: yes
[10:59] <pitti> infinity: it just changes the ICQ protocol magic number
[10:59] <Hobbsee> infinity: fortunately it's an easy test :P  "does icq connect?  yes/no"
[10:59] <pitti> looks fine for me
[10:59] <infinity> pitti: Yeah, I still want it tested. :)
[11:00] <pitti> absolutely
[11:04] <doko_> infinity: please kill sparc build of openoffice.org 2.0.3-4ubuntu2 in ubuntu edgy
[11:05] <doko_> infinity: please kill powerpc build of openoffice.org 2.0.3-4ubuntu2 in ubuntu edgy
[11:07] <pitti> mvo: hm, I thought edgy's apt-get would automatically remove dependencies now?
[11:07] <mvo> pitti: only if you tell it: "apt-get remove --auto-remove"
[11:07] <infinity> doko_: Will do.
[11:08] <pitti> mvo: ah; that shouldn't be the default?
[11:08] <pitti> mvo: right, now it works; purging f-spot removes the whole mono stack, too :)
[11:08] <Hobbsee> infinity: awww....crap.  i have kde 3.5.3 on here, and i'ts not easily going to let me install kdenetwork 3.5.2 without dependancy hell.
[11:08] <pitti> ajmitch: still here?
[11:09] <mvo> pitti: we could make it default, yeah. I was a bit worried initially that it might have problems and is too over-enthusiastic
[11:09] <Lathiat> i could see it causing problems wher eyou using something that was pulled in as a dependancy and it magically disappears, i guess
[11:09] <pitti> mvo: hm, ok, principle of least surprise
[11:10] <Lathiat> (like, from a non-packaged program, or whatever)
[11:10] <pitti> mvo: a shorter option (-a?) would work, too :)
[11:10] <infinity> Hobbsee: Run it in a dapper chroot?
[11:10] <Hobbsee> infinity: ahh.  works a charm, feel free to upload it :)
[11:10] <pitti> mvo: ... and --auto-purge ;)
[11:11] <infinity> Hobbsee: Ahh, kay.  Cool.
[11:11] <Hobbsee> infinity: coulda done that.  i fiddled with my system a bit
[11:11] <infinity> Hobbsee: I take it that it's in main, and you're not in core-dev?
[11:11] <Hobbsee> infinity: i hit join team about 5 mins ago, but yeah
[11:11] <infinity> Hobbsee: I'll sponsor it then, sure.
[11:11] <Hobbsee> infinity: :)
[11:11] <Hobbsee> infinity: you can cheer for me tomorrow too if you like :)
[11:12] <infinity> I only attend such meetings to prevent people from getting into core-dev, not to recommend. :)
[11:12] <infinity> And since I don't intend to prevent you, I'll just not show up.
[11:12] <Hobbsee> infinity: ah.  
[11:13] <Hobbsee> infinity: i guess that's a convenient excuse not to come to meetings :P
[11:13] <infinity> It works for me.
[11:14] <mvo> pitti: I guess someone should blog about it, that will spread the word (this seems to be the best way nowdays to get any message out) :)
[11:14] <mvo> pitti: you are right, a shorter options is needed
[11:18] <Hobbsee> mmm...nice edgy :)
[11:21] <mdke> sabdfl: got a minute?
[11:22] <Hobbsee> hi sabdfl 
[11:22] <Hobbsee> ack, my touchpad is on steroids.
[11:30] <iwj> bluefoxicy: booting a xen kernel on bare i386> Yes, in principle it's supposed to be possible to get that to work.  However I wouldn't count on the xen kernel we have in edgy supporting that properly.
[11:41] <mdke> sabdfl: unping, thanks
[11:44] <ogra> argh
[11:45] <pitti> is a hi-res boot splash really important enough to pull in such crack? </whine>
[11:45] <ogra> pitti, that means we have to revert the svgalib dropping we did in hoary as well, right ? 
[11:46] <Lathiat> of course
[11:46] <pitti> ogra: no, why?
[11:46] <ogra> (dependency dropping)
[11:46] <Lathiat> "shiny"
[11:46] <ogra> pitti, because if we have svgalib in main it would be pointless to cut functionallity of packages ?
[11:47] <pitti> ogra: TBH I would strictly confine svgalib-ness in main
[11:48] <ogra> but if we'd get it we shoud revert the packges /me thinks
[11:48] <Lathiat> whats so bad about svgalib?
[11:49] <pitti> Lathiat: dead upstream, bad package maintenance, suid root programs, reportedly lots of hardware incompatibilities
[11:49] <Lathiat> ah, awesome
[11:49] <pitti> and security history
[11:50] <Lathiat> are there no nicer alternatives for the splash stuff?
[11:52] <pitti> pygi: I certainly don't
[11:52] <HiddenWolf> pygi, you know what they say about first impressions.
[11:53] <HiddenWolf> pygi, I don't agree personally, but people see pictures, not vulnerabilities.
[11:53] <pitti> HiddenWolf: I'd rather prefer a VGA that works everywhere than SVGA that doesn't work on half of today's machines
[11:53] <HiddenWolf> pitti, that'd be the less is more school of thinking, went out of style in the 70's ;)
[11:53] <pygi> HiddenWolf, do we want to become "preety pictures" distro?
[11:56] <HiddenWolf> pygi, I don't think so, but I guess you'd get a different responce from an osx crowd.
[11:57] <pygi> Not that I have any right to vote on this matter, but it's still bad
[12:24] <pitti> doko_: why shall I merge blender again?
[12:24] <pitti> doko_: (it's a new upstream version)
[12:25] <doko_> pitti: this version is already converted to the new python policy
[12:25] <ogra> pitti, its on my list to look at it ... the new version adds ffmped deos
[12:25] <pitti> ah
[12:25] <ogra> *deps
[12:25] <pitti> deos?
[12:25] <ogra> heh
[12:25] <pitti> ah
[12:26] <pitti> ogra: did the earlier version have a static copy, or no ffmpeg at all?
[12:26] <ogra> well, actually lfittl is looking at it and if it still works if we drop the dep
[12:26] <ogra> no ffmpeg at all
[12:26] <ogra> its a new feature ... 
[12:26] <pitti> ok, then let's hope that configure tests for it :)
[12:26] <ogra> the movie industry discovered blender recently ... there were many features added
[12:26] <ogra> there is no configure :/
[12:26] <ogra> blender is a weird package ...
[12:27] <ogra> scons based ...
[12:28] <pitti> doko_: you know the dapper-proposed process, as it seems - can we just upload to there and later ask mdz/Kamion to approve and sync to dapper-updates?
[12:28] <pitti> mdz half-accepted it, but I don't have his final ack
[12:28] <pitti> s/accepted/approved/
[12:29] <doko_> pitti: no, AFAIK mdz and Kamion want explicit approval.
[12:30] <pitti> ok
[12:30] <seb128> pitti: what is the difference between dapper-proposed and dapper-updates?
[12:30] <pitti> seb128: -proposed is not enabled by default
[12:31] <seb128> ah, yet another source to use
[12:31] <pitti> seb128: so it's a nice place to be autobuilt and ask people to test packages from it
[12:31] <seb128> I didn't know about it :)
[12:31] <ogra> seb128, -proposed is for users willing to test 
[12:31] <pitti> seb128: it's relatively new
[12:31] <seb128> so I could upload the new evolution stack to it before dapper-updates then
[12:32] <ogra> yup
[12:32] <seb128> has dapper-proposed be announced somewhere?
[12:33] <ogra> i dont think so ... at least i didnt see an announcement
[12:35] <mdke> yet another undocumented source which isn't in software-properties :(
[12:35] <pitti> mdke: that might be because it was introduced after the dapper release :)
[12:35] <pitti> (at least I think so)
[12:35] <pitti> we just wanted a staging area for -updates
[12:35] <mdke> yes, it is. That's the problem with introducing this stuff after release
[12:36] <mdke> you get a distribution that starts to feel like it has been put together in bits
[12:36] <ogra> i dont think it should be announced prominently ...
[12:36] <ogra> software in there is for testing, nothing else ...
[12:36] <imbrandon> and afaik its been arrounf since pre breezy just not used
[12:37] <mdke> it's more -commercial that I whinge about
[12:37] <imbrandon> heh yea i dident / dont see that, why isnt it just in multiverse ?
[12:37] <seb128_> bah, the dsl connection is not happy today
[12:37] <ogra> -commercial is exposed very prominently in g-a-i
[12:38] <mdke> ogra: I'm afraid that isn't good enough. You are still left with a situation where it is undocumented, not in the most prominent sources management tool (software-properties), and only available from one package manager
[12:39] <mdke> we should probably add it to software-properties and push some documentation updates
[12:40] <HiddenWolf> mdke, isn't that exactly the point? We don't want people using it unless they know about testing it.
[12:41] <mdke> HiddenWolf: no, we moved onto -commercial
[12:41] <HiddenWolf> mdke, if people enable it as a matter of course, it turns into a second -updates
[12:41] <HiddenWolf> mdke, ah, excuse me
[12:48] <infinity> mdke: IMO, -proposed shouldn't be exposed in software-properties at all, or people who think they're "power users" will install all our broken crap from there.
[12:49] <infinity> mdke: Think of it as a staging area for -updates.  It's intended to be broken, and almost always will be.
[12:49] <mdke> yeah, I understand that
[12:49] <infinity> And most people who think they're power users don't know how to back out of a failed dpkg run, etc.
[12:49] <mdke> it's like a second  unstable distribution. I was on about -commercial
[12:49] <infinity> (Note all the people on lists who claim that dpkg --force-random-option will someone magically make a broken postinst start working, for instance)
[12:50] <infinity> s/someone/somehow/
[12:50] <mdke> btw who takes care of the -commercial packages?
[12:50] <infinity> Why do my fingers always autocomplete that one wrong?
[12:50] <mdke> the vendor themselves?
[12:51] <mdke> seems there is a bug about realplayer showing up in the wrong place in the menu, maybe we can pass that along
[12:51] <infinity> The vendors are meant to provide us source packages, but we (Canonical) will also obviously "help", and make sure they're somewhat sane.
[12:51] <mdke> infinity: so bug reports on launchpad are ok
[12:51] <mdke> +?
[12:52] <infinity> It's still a package in the archive, so sure.
[12:52] <infinity> Do we even have stuff in -commercial yet?
[12:52] <mdke> thanks
[12:52] <infinity> I don't even remember setting up -commercial buildds.
[12:52] <imbrandon> realplaer and opera
[12:52] <mdke> infinity: realplayer and opera are in there
[12:52] <mdke> and realplayer is in the "graphics" menu, apparently :)
[12:53] <mdke> delusions of grandeur maybe from someone at realplayer
[12:53] <imbrandon> heh infinity they have been there since the -commercial announcement
[12:53] <imbrandon> mdke: no it is, leaste in KDE
[12:53] <imbrandon> ( the realplayer thing )
[12:53] <mdke> it is what?
[12:53] <imbrandon> in the graphics menu
[12:54] <imbrandon> by default
[12:54] <mdke> ah, ouch
[12:54] <ajmitch> hi doko 
[12:54] <infinity> No, seriously, I must have lost a week.  Maybe to VAC.
[12:54] <mdke> imbrandon: you can confirm bug 52484 then
[12:54] <Ubugtu> Malone bug 52484 in realplayer "Realplayer is in Graphics submenu, not Sound & Video." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52484
[12:54] <infinity> imbrandon: Where was this announce?
[12:54] <imbrandon> umm one of the ML and various news sites arround the web
[12:55] <imbrandon> mdke: sure one sec
[12:55] <mdke> infinity: it was announced on sounder, I think :)
[12:56] <ogra> doko, 
[12:56] <ogra> Unpacking replacement openoffice.org-draw ...
[12:56] <ogra> dpkg: error processing /var/cache/apt/archives/openoffice.org-draw_2.0.3-3ubuntu4_i386.deb (--unpack):
[12:56] <ogra>  trying to overwrite `/usr/lib/openoffice/program/libflash680li.so', which is also in package openoffice.org-core
[12:56] <ogra> known ?
[12:57] <Hobbsee> ogra: i believe so
[12:57] <ajmitch> ogra: current is -4ubuntu2, should be fixed from what the changelog says
[12:58] <doko> ogra: ask pitti why the fix is not yet in the archive ;)
[12:58] <ogra> hmm, no -4ubuntu2 for me here ...
[12:58] <gnomefreak> yes known bug
[12:58] <ogra> ah, ftbfs :)
[12:58] <dholbach> ogra: 2.0.3-3ubuntu4-1 is current on edgy (amd64)
[12:59] <ogra> i'm running i386 on my amd64 laptop currently ... :)
[01:00] <dholbach> ok
[01:00] <geser> it's bug 54288
[01:00] <Ubugtu> Malone bug 54288 in openoffice.org "[Edgy]  openoffice.org-draw 2.0.3-3ubuntu3 fails to unpack due to attempt to overwrite file in openoffice.org-core" [High,Confirmed]  http://launchpad.net/bugs/54288
[01:00] <jono> hi all
[01:00] <dholbach> heya jono
[01:01] <jono> hey dholbach 
[01:04] <Ubugtu> Debian bug 380859 in ltsp "Subject: Python transition (#2): you are building a private python module !" [Important,Open]  http://bugs.debian.org/380859
[01:04] <ajmitch> ogra: yes, I just got a few of them on packages I have to touch
[01:04] <ogra> meh ...
[01:05] <ogra> i dont build any modules though ... the report is wrong ...
[01:18] <jdub> fabbione: ping
[01:19] <pitti> doko: I don't know why 0.6 is taking so long :(
[01:20] <doko> pitti: just built
[01:20] <doko> infinity, pitti: why is pkgstriptranslations taking so long on rothera?
[01:22] <pitti> doko: you mean taking long to generate the translation tarball?
[01:22] <doko> pitti: IIRC, it's now about 45 minutes
[01:23] <pitti> whoa...
[01:24] <infinity> That's because it does very retarded things.
[01:25] <infinity> On every invocation.
[01:25] <infinity> On huge source trees, it's pretty crap. :/
[01:25] <infinity> pitti: What was the rationale for searching for translations outside the binary package build directories again?
[01:25] <ogra> jdub, i guess he's bus breast-feeding ;)
[01:25] <ogra> *busy
[01:25] <infinity> pitti: Cause that's the thing that kills it.
[01:27] <pitti> infinity: because interesting translations are anywhere *except* in the binary package build dirs
[01:28] <pitti> infinity: I know that it is horribly inefficient, because it's stateless
[01:28] <infinity> pitti: Right, then.  I suppose there's not much we can do to speed it up, then, unless we teach it to save state.
[01:28] <infinity> pitti: Hah, jinx.
[01:29] <pitti> infinity: well, we could make some assumptions if a translation tarball already exists, though
[01:53] <Fjodor> Is there something wrong in the latest edgy kernel wrt sata or xfs? I noticed it took a long time rm -rf'ing a kernel build dir, and are about to time it. Copying it over took 10 minutes(!). That's way too long, and longer than I ever saw on 5.16
[01:54] <Fjodor> *514
[01:54] <Fjodor> *5.14
[01:55] <Fjodor> Deletion time 2m46s. Also way too long
[02:02] <ogra> dholbach, if at some point jokosher will be stable enough for main inclusion, please ping me, it looks like a really good addition to edubuntu-desktop ;)
[02:03] <dholbach> ogra: it ROCKs hard :)
[02:03] <dholbach> jono: ^ words of praise :)
[02:03] <plaes> any Rosetta guys here?
[02:04] <HiddenWolf> Do we really need a sound editor in the default desktop?
[02:04] <phanatic> plaes: #launchpad
[02:04] <plaes> thx :)
[02:04] <ogra> dholbach, i know that it rocks :) but 0.1 seems a bit young to consider it for main ;)
[02:04] <dholbach> ogra: i'm quite sure, jono would say the same :)
[02:04] <ogra> HiddenWolf, in edubuntu 
[02:05] <dholbach> HiddenWolf: yeah and drop gnome-sound-recorder :)
[02:05] <ogra> HiddenWolf, we already ship denemo in edubuntu for notesetting
[02:35] <jono> ogra, thanks :)
[02:36] <jono> ogra, 0.1 is too young, but I think 0.2 will be suitable for inclusion
[02:40] <seb128> ok, I didn't wait enough to dist-upgrade my edgy apparently :p
[02:40] <seb128> I didn't touch xorg for a week because of the transition but looks like the ati driver still need to be upgraded :/
[02:41] <Amaranth> fglrx?
[02:41] <seb128> no, ati
[02:41] <Amaranth> oh
[02:41] <Amaranth> i thought ati was fine
[02:42] <seb128> it's still 7.0 apparently
[02:42] <Amaranth> it's at least been recompiled for 7.1, i remember that night :P
[02:47] <ogra> jono, wow, cool !
[02:47] <geser> I'm also using the ati driver for xorg and I've already installed the version for Xorg 7.1
[02:48] <ogra> seb128, ati is fine here
[02:48] <ogra> fglrx isnt though ...
[02:49] <ogra> seb128, which version of xserver-xorg-video-ati do you have installed ? 
[02:50] <desrt> holy crap it's tuesday!
[02:50] <jono> ogra, 0.2 will have all kinds of cool stuff in there :)
[02:51] <pitti> desrt: you don't like Tuesdays?
[02:51] <desrt> i've a meeting today
[02:51] <ogra> jono, do you target cubase ? ;)
[02:51] <desrt> and i think i didn't go to work yesterday because i didn't realise it was monday
[02:52] <jono> ogra, pretty much :)
[02:52] <ogra> hehe, cool !
[02:52] <ogra> thats long awaited :)
[02:53] <seb128_> k
[02:53] <ogra> seb128_, xserver-xorg-video-ati works fine here
[02:54] <seb128_> that was -driver-ati installed about -video-ati
[02:54] <ogra> ah :)
[02:54] <seb128_> s/about/instead of
[02:54] <seb128_> something should conflict and force to upgrade
[02:54] <seb128_> and no, I don't have ubuntu-desktop :p
[02:54] <ogra> i thought they conflict ...
[02:55] <desrt> score.  the xen stuff finally hit the wall.
[02:55] <ogra> i know it was replaced automatically here ...
[02:55] <ogra> but then i have edubuntu-desktop installed  :)
[02:55] <desrt> let the testing begin...
[02:56] <geser> video-ati conflicts driver-ati but you need to install it manually or through a meta-package
[02:57] <seb128_> that's what I complain about :p
[02:57] <seb128_> xserver-xorg should Breaks or Conflicts with the -driver-*
[02:57] <ogra> hmm ...
[02:57] <geser> it's xserver-xorg-driver-all
[02:58] <geser> and xserver-xorg depends on  xserver-xorg-video-all | xserver-xorg-video
[02:59] <ogra> well, the xorg metapackage should care for everything ... 
[02:59] <ogra> seb128, do you have that ?
[03:00] <seb128_> ogra: no
[03:04] <doko> infinity, cprov: new pkg-create-dbgsym is in the archive, please requeue  openoffice.org 2.0.3-4ubuntu2 on powerpc, sparc, i386 (wondering why it did succeed on amd64 ...)
[03:08] <cprov> doko: done
[03:09] <cprov> and it also breaks the UI :(
[03:10] <doko> pitti: ^^^ if the build fails, I'll phone you when the build finishes ... at 3am ;-P
[03:10] <doko> cprov: the OOo UI?
[03:10] <pitti> doko: right, thanks for reminding me to pull the telephone cable
[03:10] <cprov> doko: the soyuz UI 
[03:10] <doko> :)
[03:16] <rodarvus> seb128, ati should be fixed by now
[03:16] <rodarvus> the last (known) bug was nailed by mdz last night
[03:16] <seb128> rodarvus: I had driver-ati installed instead of video-ati and nothing complained
[03:16] <rodarvus> (the driver itself was uploaded for 7.1 a few days ago)
[03:17] <rodarvus> oh
[03:17] <seb128> I had to apt-get install video-ati
[03:17] <rodarvus> seb128, you just have to update xorg (actually xserver-xorg-video-all)
[03:17] <rodarvus> it will automatically update your drivers
[03:17] <seb128> right
[03:18] <rodarvus> seb128, this change was finally commited last Thursday, I think
[03:18] <seb128> but I don't have video-all and I don't want it
[03:18] <seb128> I don't want a zillion of drivers I don't use
[03:18] <doko> seb128: what is the status of the gnome libs for dapper-updates?
[03:18] <rodarvus> (so, before, it was common for people to still use xserver-xorg-driver-*)
[03:18] <rodarvus> seb128, no problem, the requirements are xserver-xorg-video-all | xserver-xorg-video
[03:19] <rodarvus> the second is provided by -video-ati (and all other video drivers)
[03:19] <seb128> doko: we have done most of GNOME 2.14.3 but still not GTK, it's on my list for this afternoon
[03:19] <seb128> rodarvus: not sure of what is required but the server should conflict with -driver-* or something
[03:20] <doko> ok
[03:20] <seb128> at the moment you can be in a situation with everything to 7.1
[03:20] <seb128> but ati driver still to 7.0
[03:20] <ogra> not if you have the xorg metapackage installed
[03:20] <rodarvus> that should be addressed, strange.
[03:20] <rodarvus> seb128, do you have 'xorg' installed?
[03:20] <seb128> ogra: I don't, again
[03:20] <seb128> rodarvus: no
[03:20] <ogra> seb128, but why ? 
[03:20] <rodarvus> why?
[03:20] <rodarvus> :)
[03:20] <seb128> dunno
[03:20] <seb128> because it works without it?
[03:21] <seb128> and I don't feel the need to go and install packages I don't have when everything works fine?
[03:21] <seb128> I've upgraded that box since hoary or something like that
[03:21] <seb128> dunno if it was installed or when it got removed
[03:21] <rodarvus> seb128, it is a metapackage (as I'm sure you know), so you risk missing updates, if you don't have it installed
[03:22] <seb128> but until my dist-upgrade this week that was working fine
[03:22] <rodarvus> it was probably uninstalled automatically, when you first updated to Edgy
[03:22] <seb128> right
[03:22] <rodarvus> (in the first week fonts were quite broken, and triggered an uninstall of xorg)
[03:22] <seb128> my point is that something else should have the Conflicts then
[03:22] <seb128> obviously it's possible to be in a broken situation, my desktop was in that case
[03:22] <seb128> and that should not be possible :p
[03:22] <rodarvus> seb128, xorg-server 1:1.1.1-0ubuntu4 (which will be uploaded in a few hours) will have something like this
[03:22] <ogra> well, i guess it was never instaled because he has no -desktop package istalled (which would have changed deps from x-window-system-core to xorg)
[03:23] <seb128> maybe the server should Conflicts and not xorg
[03:23] <rodarvus> actually, Breaks: <all old drivers>
[03:23] <doko> Kamion, infinity: please approve openoffice.org-amd64 2.0.3-4dapper1 for dapper-proposed
[03:23] <seb128> rodarvus: ok, that was what I was asking for, thank you ;)
[03:23] <infinity> doko: Will do.
[03:23] <rodarvus> seb128, no thank YOU :)
[03:23] <infinity> doko: On both counts.
[03:23] <Hobbsee> doko: Kamion has the day off today.
[03:25] <doko> infinity: which counts?
[03:25] <infinity> doko: Err, give-backs, and ooo-amd64 approvals.
[03:26] <doko> infinity: give-backs already done by cprov
[03:26] <infinity> doko: I see that.
[03:26] <infinity> doko: Well, I see that on all but powerpc, which I've just remedied.
[03:30] <wasabi> Yeah. Must be evms. I have two device nodes that return the same vol_id
[03:30] <infinity> pitti: Kamion requested those langpack updates from you, right?
[03:31] <fruwak> !topic
[03:31] <infinity> fruwak: I think you meant /topic
[03:31] <infinity> fruwak: There are no bots in this channel.
[03:31] <fruwak> yes thx :D
[03:31] <pitti> infinity: right
[03:31] <fruwak> i fixed that :D
[03:32] <infinity> pitti: Okay, then I'll just leave them for him to deal with when he gets back. :P
[03:32] <fruwak> im no bot :D i can be robot :D
[03:32] <pitti> infinity: I'll bother him about NEWing and such tomorrow
[03:32] <pitti> infinity: that should be fine
[03:42] <bddebian> Heya
[04:02] <Fjodor_> BenC: Is there something wrong in the latest edgy kernel wrt sata or xfs? I noticed it took a long time rm -rf'ing a kernel build dir, and timed it 2 2m46s. Copying it over took 10 minutes(!). That's way too long, and longer than I ever saw on 5.14 or earlier
[04:03] <Fjodor_> Brb
[04:03] <ogra> 5.14 ? that would be 6.02 then ?
[04:03] <ogra> :)
[04:03] <Hobbsee> ogra: and who did a secret release of 6.02 anyway?
[04:04] <zul> it was me..sorry...its my deriative
[04:04] <gnomefreak> looks like they need a say off
[04:04] <gnomefreak> s/say/day
[04:04] <Hobbsee> zul: heh
[04:05] <ogra> zul, xenubuntu prerelease ?
[04:05] <zul> ogra: eventaully yeah :)
[04:05] <ogra> :)
[04:05] <zul> its apart of the plan for world domination
[04:06] <giftnudel> 1. release in 5.14 2. ????? 3. prof... eh world domination?
[04:06] <Hobbsee> zul: but i was going to take over the world!  that's my job!
[04:06] <zul> Hobbsee: you have to wait in line..
[04:06] <Hobbsee> zul: we cant have two people taking over the world!
[04:06] <zul> narf
[04:06] <giftnudel> you can split at the equator
[04:07] <Hobbsee> as long as i get the northern half :P
[04:07] <zul> yeah i dont want australia...its full of dingos
[04:07] <Hobbsee> heh
[04:07] <ogra> they dont show up on the internet ;)
[04:07] <infinity> I've never seen a dingo outside of a zoo...
[04:07] <Hobbsee> ogra: hehe
[04:08] <ogra> you have to go *outside*, you know 
[04:08] <Hobbsee> ogra: outside?  what's that?
[04:08] <thom> infinity: you've been outside?!?
[04:08] <infinity> thom: About 3 times since I took this job, yes. :P
[04:08] <Hobbsee> hehehe
[04:08] <Hobbsee> infinity: wow, which were they?  going to and from conferences?
[04:09] <ogra> infinity, you mean while driving to the airport ?
[04:09] <infinity> Yeah, pretty much.
[04:09] <Hobbsee> that must mean that you're still at a conference.   must be pretty quiet there now.
[04:09] <zul> isnt it the koala that gets stoned off eucalpytus?
[04:09] <Hobbsee> if you never actually left the second conference.
[04:09] <Hobbsee> ah crap!
[04:10] <ogra> zul, yes they drop on you ...
[04:10] <ogra> zul, but you can prevent that by sticking forks in your hat a heard ;)
[04:10] <Hobbsee> ogra: you're confusing the koalas and the dropbears.  the koalas go across busy roads.
[04:11] <ogra> s/a/i/
[04:11] <ogra> Hobbsee, ah, right ...
[04:11] <zul> ogra: or a large spike a la kriaser willem?
[04:11] <Hobbsee> ogra: so do the echidnas, for that matter.
[04:11] <zul> heh...we have canadian geese crossing the road
[04:11] <ogra> zul, could wor as well :)
[04:14] <Hobbsee> oh yeah, forgot the ducks wandering around on the street too - and they do not move for cards!
[04:14] <Hobbsee> s/cards/cars
[04:14] <giftnudel> they probably won't move if you give them cards either
[04:15] <Hobbsee> hehe, yeah
[04:20] <zul> Hobbsee: canadian geese has a tendency to get upset and attack me
[04:20] <Hobbsee> zul: ahhh...nasty
[04:21] <ogra> zul, you really shouldnt go out in that gander costume ;)
[04:21] <zul> ogra: i try not to
[04:21] <bddebian> Is hamlib stuck in NEW?
[04:22] <bddebian> Oh, NM, I can check myself sorry
[04:22] <bddebian> Yep, sure is.
[04:29] <heno> seb128: are you importing gnome-orca as part of the normal gnome 2.16 imports or should I do a separate main inclusion report? 
[04:30] <heno> seb128: it will be the default screen reader for gnome 2.16 AFAIU, but other people like FC6 are not going to use it yet
[04:30] <seb128> heno: better to ask pitti if it needs one
[04:30] <heno> (we would like to though)
[04:31] <heno> ok, pitti ^ ?
[04:31] <bddebian> Whomever is working on syncs, THANK YOU :-)
[04:31] <seb128> heno: I'm fine with using for edgy, dholbach might have better idea on it though, he's packaging the a11y stack usually
[04:31] <HiddenWolf> seb128, what's the relation between orca and the simple-onscreen-keyboard soc?
[04:31] <heno> HiddenWolf: nothing
[04:32] <seb128> no idea, I use or know neither of those
[04:32] <heno> separate things completely
[04:32] <heno> both are cutting edge assistive technology
[04:32] <heno> :)
[04:33] <heno> Orca will be the default reader for gnome 2.16 and we are working to make SOK default by 2.18
[04:33] <heno> replacing GOK
[04:34] <dholbach> heno: i updated it every time there was a new release and i'll subscribe the accessibility team to the bugs of it
[04:37] <heno> dholbach: do we need to do anything special to get it into main and onto the CD? (I'm familiar with the main inclusion report and seed change request, but I was wondering if there is more automation to it when it is a default part of gnome?)
[04:37] <heno> If not, I'm happy to just follow the normal steps for inclusion
[04:38] <dholbach> heno: maininclusionreport, then seed change
[04:39] <dholbach> heno: what automation are you thinking of?
[04:39] <heno> dholbach: I didn't know if the standard gnome desktop got accepted as a whole unit or not
[04:40] <heno> I guess not
[04:40] <heno> i'll follow the normal steps, thx
[04:42] <dholbach> heno: that was historical - all new components since warty (or hoary or something) went through that process
[04:42] <heno> ok, cool
[04:46] <janimo> heno, hi xubuntu-at-mag and xubuntu-at-speak are in NEW now
[04:47] <heno> janimo: cool! What do they use? Gnopernicus/Orca? gnome-mag, gnome-speech?
[04:47] <janimo> heno, the packages you listed in the wiki :)
[04:47] <janimo> just added them to the depends field
[04:47] <janimo> orca, espeak, speech-dispatcher, gnome-mag
[04:48] <janimo> and orca, yes
[04:48] <heno> looks good
[04:48] <janimo> I did not upload one for the keyboards as the package is not yet in the archive
[04:49] <heno> right, we'll get that in soon
[04:49] <heno> janimo: thanks!
[04:49] <janimo> heno, np :)
[04:53] <Amaranth> pitti: i've got an initscript in /etc/dbus-1/event.d/, my /etc/dbus-1/system.d/willowng.conf is almost identical to the one you have for hal, but i can't seem to get mine to own it's dbus interface. it does if i run as root or if i su into the willowng user but when it starts as root, drops to willowng user, then tries it fails. any ideas?
[04:54] <ogra> pitti, willowng is Amaranths SoC project he does for us
[04:55] <pitti> sorry, was at the phone
[04:56] <pitti> re (sorry, was at the phone)
[04:57] <Amaranth> that reminds me, what does 're' mean?
[04:57] <azeem> "I am back"
[04:57] <ogra> returned ?
[04:58] <Amaranth> ah
[04:58] <Amaranth> people leave for bed, come back in the morning, and say that so i didn't think it was that
[05:00] <Amaranth> http://rafb.net/paste/results/7rs4ts10.html is my dbus conf file
[05:20] <iwj> Hmm, my X is still completely hosed in edgy.  Should I report it as a bug ?
[05:21] <bddebian> OK, gtkgl2 in Debian still has two .la files, do I need to strip those out?
[05:22] <seb128> bddebian: don't create a diff only for that
[05:24] <cypher1> i am trying to understand the files under /proc/acpi/battery/*.. has anyone has any URLs ?
[05:25] <BenC> is there an installer option to keep it from automatically running each next step of the install process?
[05:25] <BenC> IOW, let me select things manually
[05:28] <bddebian> seb128: OK, just sync it?
[05:28] <seb128> bddebian: I've not looked to the package, but if there is no Ubuntu change we need to create a diff just to drop them, ask a sync rather
[05:29] <bddebian> OK, thanks
[05:36] <Riddell> Kamion: could you move some packages to main?
[05:37] <Riddell> http://kubuntu.org/~jriddell/tmp/main
[05:40] <mdke> Riddell: he mentioned earlier that he is off work today
[05:40] <mdke> (just fyi, in case you didn't know that already)
[05:40] <Riddell> mdke: I didn't, thanks
[05:41] <Riddell> maybe mdz is awake instead?
[05:50] <infinity> Riddell: Are all those source packages in main?
[05:51] <infinity> Riddell: If not, are there MIR for each one?
[05:51] <Riddell> infinity: none are in main, they all have successful main inclusion reports
[05:53] <janimo> infinity: are edgy CD builds off until dapper.1 is out ?
[05:53] <pitti> Riddell: did you get my mail wrt. hal re-sanitizing?
[05:53] <infinity> janimo: Not sure, you'd have to ask Kamion when he gets back.  I'm not touching the cdimage host without his approval while he's working on dapper.1
[05:54] <Riddell> pitti: yes, sorry should have got back to you on that
[05:54] <pitti> Riddell: if you cannot revert to the pmount behavior and depend on these scripts, I need to schedule some time to make them safe
[05:54] <janimo> infinity: ok. I just saw no dailies today to check wether xubuntu is still oversized
[05:54] <pitti> Riddell: but I'm not aware of the KDE situation, a short briefing would be appreciated
[05:54] <Riddell> pitti: it's a new need in KDE 3.5.4, I don't know how easy it would be to remove, I suspect not very
[05:55] <wasabi_> Heh nice.
[05:55] <wasabi_> Everybody updated initramfs to use UUIDs, but nobody fixed local-top/evms at all.
[05:55] <Riddell> pitti: I need to check which scripts it needs exactly, it doesn't need the eject one for example
[05:57] <pitti> Riddell: how did KDE mount removable stuff before?
[05:57] <infinity> Riddell: Grr, the page title should be MainInclusionReportPackage not MainInclusionReviewPackage... You completely messed up my wiki searching mojo. :)
[05:57] <Riddell> pitti: pmount
[05:57] <pitti> Riddell: i. e. before hal offered the mount API through the scripts you added?
[05:58] <Riddell> infinity: humble appologies
[05:58] <infinity> MartinPitt: needs soname fix or library package renaming to match soname, ok otherwise
[05:59] <pitti> Riddell: pmount through a kioslave or something like ivman?
[05:59] <infinity> Riddell: Are we doing something about that?
[05:59] <pitti> wasn't that fixed?
[05:59] <infinity> Well, if it was, the MIR page wasn't updated.
[05:59] <Riddell> infinity: that's been fixed
[05:59] <infinity> Ahh, the binary is libpth20, so I suppose it was fixed.
[05:59] <infinity> Riddell: Excellent.  Will promote nowish.
[06:00] <Riddell> infinity: I updated the UbuntuMainInclusionQueue page but I'll mind and update the actual report page in future
[06:00] <Riddell> thanks infinity 
[06:01] <Riddell> pitti: I'll need to wait until the KDE HAL dude is around to ask him how easy it would be to revert back to using just pmount, the pmount code seems to still be there from a grep
[06:02] <pitti> Riddell: gnome-volume-manager looks for gnome-mount (which uses hal) and falls back to pmount-hal if it's not found
[06:03] <infinity> Riddell: All done.  Should make this publisher run, so should be visible in ~40 mins.
[06:06] <ogra> iwj, run mkfontdir in the misc directory
[06:23] <iwj> ogra: I don't need the X to work, so I can leave the install hosed for the moment :-).
[06:23] <iwj> Until a proper fix is released at which point I can verify whether it's fixeds.
[06:23] <iwj> s/xeds/xed/
[06:24] <iwj> This also makes it easier to reproduce at least one of my other two bugs, too.
[06:25] <ogra> iwj, yup, then wait for rodarvus to return i told it to him when he was done with the X 7.0 sync ... but he said it would be fixed in 7.1 anyway
[06:30] <iwj> Sure.  (FYI, the others are bug 54812 and bug 54813.)
[06:30] <Ubugtu> Malone bug 54812 in xserver-xorg "X server garbled display" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54812
[06:31] <Ubugtu> Malone bug 54813 in xserver-xorg "X server failure dialogue garbled (UTF-8 problem)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54813
[06:33] <ogra> i think 54813 exists since breezy
[06:35] <ogra> daniels never really cared and whe he left there were bigger probs than frames around error dialogs :)
[06:37] <BenC> Kamion: ping
[06:41] <dholbach> BenC: he's out for today.
[06:44] <BenC> dholbach: thanks
[06:45] <iwj> ogra: Sure.  But I thought if I was going to report two bugs based on the same set of facts I might as well throw in the third as it was hardly any effort :-).
[06:45] <ogra> hehe
[06:45] <ogra> i'm sure rodarvus will fix tem once he's done with 7.1 packaging
[06:45] <ogra> *them
[07:02] <bluefoxicy> iwj:  I'm not worried about your kernel working properly; I'm worried about the future situation where it may be possible to ship straight Xen kernels, especially if Linus takes Xen in mainline
[07:04] <zul> bluefoxicy: when it comes to that we will include it in ubuntu-kernel
[07:04] <bluefoxicy> zul:  nods.  Which means all kernels will be able to run native, Xen dom0, or Xen domU  :)
[07:06] <zul> well native and dom0 now
[07:06] <bluefoxicy> I thought dom0 kernels could also run domU
[07:06] <zul> they can,we dont ship domU kernels
[07:07] <bluefoxicy> :>
[07:21] <Treenaks> pitti: Cups doesn't seem to detect the default paper size on printers it finds automatically (by 'browsing'); is that a bug in cups or in gnome-cups-manager?
[07:22] <iwj> bluefoxicy: Yes, that's what we would like to do, of course.  But atm there is big politics with Xen and mainline kernels :-/.
[07:23] <bluefoxicy> iwj:  as much as I hate to say it, Arjan will probably get it in mainline if anything.  That guy can talk Linus into putting just about anything in there.
[07:26] <iwj> Well, it would be nice.  Last I saw (a few months ago) Linus was still telling the Xen guys and the vmware guys to come back when they could agree on a single interface, which seemed doomed and stupid to me.
[07:27] <zul> Name                              ID Mem(MiB) VCPUs State  Time(s)
[07:27] <zul> Domain-0                           0      362     1 r-----  2749.0
[07:27] <zul> ramdisk                            7       64     1 -b----     9.6
[07:27] <zul> oops...sorry..
[07:30] <bluefoxicy> iwj:  they do not even work the same way, that's retarded.
[07:30] <bluefoxicy> That kind of thing should go to vmware/kqemu, not vmware/xen
[07:31] <iwj> vmware want to do paravirt stuff too apparently.
[07:35] <zul> ahem...http://70.29.57.2/ubuntu/Screenshot.png
[07:52] <Lathiat> I have to excuse myself from the avahi/tb discussion this morning unfortunately, hopefully somebody else knowledgable will be there.
[07:54] <ogra> oh, there is a tb meeting today, right ... and Hobbsee going for main ! 
[08:06] <LaserJock> doko: ping?
[08:19] <Zdra_> I have a question to developers: how do you do to test patch in a lib (like gnomevfs) ? Apply the patch in the package's source, build it and then install it ? or apply the patch in upstream source and compile it with prefix=/usr ?
[08:21] <LaserJock> Zdra_: I would guess mostly in the source package, but it would probably depend on the situation
[08:22] <Zdra_> LaserJock: so you rebuild the package and install it with dpkg -i ?
[08:22] <LaserJock> yeah
[08:22] <LaserJock> for me, I have to reproduce as nearly as I can what the user is going to see
[08:23] <LaserJock> and that means rebuilding the source, .deb, and installing, etc.
[08:24] <Zdra_> the problem I have with this solution is when I build the package ubuntu's patch are applied and I don't know how to reverse them so if I rebuild the package again it make errors
[08:25] <Zdra_> I guess there is some debian doc to explain how to clean up the source code before build it
[08:26] <Zdra_> and another problem: It compile the whole package everytime I change one line...
[08:27] <LaserJock> Zdra_: why don't you hop on over to #ubuntu-motu
[08:27] <Zdra_> didn't know that's the right chan to discuss that kind of things, thanks.
[08:37] <gabaug> I want to create a bzr branch for f-spot that can be committed to by other f-spot devs...do I need to create a f-spot team to do that?
[08:37] <tseng> hi gabaug 
[08:37] <gabaug> hi tseng
[08:37] <tseng> there is a #bzr
[08:37] <gabaug> thanks
[08:37] <tseng> that might have more relevant people, not sure
[08:37] <tseng> not sure if it falls into bzr or launchpad team
[08:38] <tseng> #launchpad or #bzr knows best.
[08:42] <janimo> Gloubiboulga: hi, did not forget :)
[08:42] <Gloubiboulga> hi janimo, ok, I haven't checked if you were online :)
[08:45] <bluefoxicy> hi tseng
[08:52] <Gloubiboulga> janimo, someone on #xubuntu told us he's writing a gui to add/remove printers for xubuntu
[08:52] <janimo> ivoks or someone else?
[08:52] <Gloubiboulga> someone else
[08:52] <janimo> since he is working on a pygtk configurator
[08:52] <janimo> and I am just looking a gnome-cups-manager right now
[08:53] <Gloubiboulga> ok, he'll probably mail the xubuntu list
[08:54] <Gloubiboulga> janimo, val314159 is our man :)
[08:54] <val314159> hello
[08:54] <janimo> val314159: hello
[08:54] <ogra> rodarvus, btw, any idea about bug 54809 ? seems it still looks in the wrong dir
[08:54] <Ubugtu> Malone bug 54809 in xserver-xorg "X server cannot find default font `fixed'" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54809
[08:55] <val314159> im finshing up a pygtk add/remove printer add for xubuntu
[08:55] <janimo> val314159: nice, please post to the list when ready for testing :)
[08:56] <janimo> val314159: btw someone else is doing the same thing for ubuntu, not sure if edgy is the target though
[08:56] <val314159> oh, man, and i thought i was all unique
[08:56] <janimo> anyway with so many options I hope we'll get print config one way or another in xubuntu
[08:56] <rodarvus> ogra, I supposed this was due to you and iwj having used a broken version of xfonts-utils
[08:56] <janimo> val314159: there's much demand for such an app you cannot be unique ;)
[08:56] <ogra> rodarvus, iwj updatesd today 
[08:57] <ogra> so it was the most recent binary
[08:57] <rodarvus> right, indeed
[08:57] <janimo> val314159: don't let that discourage you, but try to see if you guys can cooperate (the other's nick is ivoks)
[08:57] <rodarvus> ogra, I'll have a look at it today, thanks!
[08:57] <ogra> rodarvus, there should also be a versioned dependency on xfont-utils
[08:58] <ogra> so that this cant happen with 7.x
[08:58] <rodarvus> you mean of xorg on xfonts-utils?
[08:59] <val314159> ok, got it.  time to upload
[09:00] <ogra> rodarvus, yep
[09:01] <rodarvus> ogra, yes, good sugestion - I'll do it
[09:01] <rodarvus> thanks again :)
[09:01] <Commander-Crowe> oh wow
[09:02] <Commander-Crowe> so what are you guys developing?
[09:02] <ogra> SuSE linux 11.1 
[09:02] <HiddenWolf> ogra lmao
[09:03] <zul> world domination
[09:03] <ogra> Commander-Crowe, no in fact we're developing the OS of the future :)
[09:03] <Commander-Crowe> lol
[09:03] <Commander-Crowe> 11.1?
[09:03] <Commander-Crowe> have 11 come out yet?
[09:03] <Commander-Crowe> has 10.2 come out yet?
[09:03] <HiddenWolf> Commander-Crowe, ubuntu.com
[09:03] <ogra> and as you might guess from the channel name thats not SuSE
[09:04] <Commander-Crowe> yeah
[09:04] <ogra> :)
[09:04] <Commander-Crowe> I was gonna do crowe linux
[09:04] <Commander-Crowe> all it was gonna be was a load of drivers
[09:05] <Commander-Crowe> compatible with eveything out there
[09:06] <tritium> !enter > Commander-Crowe 
[09:06] <tritium> oops, sorry, wrong channel :)
[09:07] <bddebian> Heya tritium
[09:07] <tritium> hi bddebian 
[09:07] <val314159> ok, i uploaded garp (gtk add/remove printer)
[09:07] <janimo> val314159: if you want testers you could mail the xubuntu-list
[09:08] <Commander-Crowe> garp?
[09:08] <val314159> d'oh!  i just mailed xubuntu-devel
[09:08] <Commander-Crowe> for printing?
[09:09] <janimo> val314159: ok :)
[09:09] <val314159> the world according to your printer?
[09:10] <Commander-Crowe> so the next version of UBuntu is 6.10?
[09:10] <Commander-Crowe> when does it come out/
[09:11] <ogra> 06/10 indeed ;)
[09:12] <janimo> val314159: it should be more than just a gtk wrapper around lpadmin :)
[09:13] <janimo> should do at least as much as gnome-cups-manager does not
[09:13] <janimo> s/not/now/
[09:13] <val314159> :hms
[09:14] <janimo> there's a redhat printer config tool written in python, pretty complex, and cannot easily be adapted to ubuntu, hence someone is writing one from scratch
[09:15] <val314159> i guess i misunderstod the problem.  i thought it was just to get printers going on xubuntu without grabbing all of gnome
[09:15] <janimo> val314159: yes, that is the goal. But I am sure it cannot be done by just using lpadmin
[09:15] <val314159> i used lpinfo and lpstat too (:
[09:16] <janimo> val314159: well, if those can do what can otherwise be done by using cups libraries, great.
[09:17] <val314159> so, it could be a wrapper, it just needs more functionality?
[09:17] <val314159> altho python bindings would be much sweeter
[09:22] <janimo> val314159: if it does all that gnome-cups-manager does it's enough
[09:23] <janimo> so detect/add/remove local and networked printers at least
[09:24] <val314159> ok, im instaling gnome-cups-manager to see what i'm missing
[09:27] <LaserJock> mdz: ping?
[09:29] <val314159> it looks like my script does the same thing, but thier interface is way nicer
[09:29] <val314159> except they have a way to turn on network printer detect
[09:30] <crimsun> janimo: RE: gxine, I'll work with Darren on stripping out the js dependency.
[09:30] <janimo> crimsun: great, thanks
[09:55] <zul> ill apply the patch
[09:55] <zul> doh..
[09:56] <desrt> there is no dana.  only zul.
[09:56] <zul> hey desrt 
[09:56] <desrt> 'sup
[09:56] <zul> not much you?
[09:56] <desrt> i see your packages landed in edgy.
[09:56] <zul> yep doing another one tonight
[09:56] <desrt> l33t.
[09:56] <desrt> i got edgy on my laptop
[09:57] <desrt> it's only got 1gig, so probably not the ideal test machine
[09:57] <zul> better than mine
[09:57] <desrt> i may edgify my desktop tonight -- it's a bit beefier
[09:57] <tseng> desrt: please do
[09:57] <tseng> desrt: then you can fix muine
[09:57] <desrt> did you take dbus out?
[09:57] <tseng> no
[09:57] <desrt> good.
[09:57] <tseng> I tried a few things regarding vfs
[09:57] <desrt> i'd have had to fuck you up
[09:58] <desrt> i can always fix muine on my laptop
[09:58] <desrt> what is the problem?
[09:59] <tseng> it segfaults on startup
[09:59] <desrt> did you upload that?
[09:59] <tseng> specifically starting the dbus service
[09:59] <tseng> upload what?
[09:59] <desrt> the segfaulting muine :)
[09:59] <tseng> no
[09:59] <tseng> i uploaded a working muine
[09:59] <seb128> desrt: hi
[09:59] <tseng> gnome 2.15 upgrade hosed it.
[09:59] <desrt> is it just the old package linked against new dbus starts failing?
[09:59] <desrt> ah :(
[09:59] <desrt> seb128; hey.
[09:59] <desrt> seb128; what's up?
[09:59] <tseng> rebuild is obviously no help
[10:00] <desrt> tseng; maybe not true
[10:00] <tseng> we can talk about it later, other things ive already tried
[10:00] <seb128> desrt: https://launchpad.net/distros/ubuntu/+source/gtk+2.0/+bug/54261 is no go
[10:00] <Ubugtu> Malone bug 54261 in gtk+2.0 "every single gtk app wakes up on button or modifier key press" [Medium,Fix committed]  
[10:00] <tseng> desrt: well, I've tried it
[10:00] <desrt> seb128; ah.  why?
[10:00] <tseng> so its true in my experience
[10:00] <desrt> tseng; k.  was thinking maybe ABI break without corresponding API break
[10:00] <seb128> desrt: GTK 2.8.20 has no mention of XkbSelectEventDetails function to its source code
[10:00] <desrt> eh
[10:01] <desrt> that doesn't sound right
[10:01] <seb128> and I don't know about the issue to know if it applies at all to 2.8
[10:02] <desrt> goddamn why don't we have a dbus-sharp?
[10:03] <crimsun> meaning libdbus-1-cil?
[10:03] <desrt> seriously.
[10:03] <Zdra_> seb128: I think you should consider including this upstream patch to ubuntu's package: http://bugzilla.gnome.org/show_bug.cgi?id=340938 --> still not commited to gnome-2-14 branch but is in head. May be useful before dapper point release. (sorry if you are already aware of this bug)
[10:04] <seb128> desrt: http://cvs.gnome.org/viewcvs/gtk%2B/gdk/x11/gdkdisplay-x11.c?rev=1.60&only_with_tag=gtk-2-8&view=markup
[10:04] <seb128> desrt: it has a 
[10:04] <seb128>             XkbSelectEvents (display_x11->xdisplay,
[10:04] <seb128>                              XkbUseCoreKbd,
[10:04] <seb128>                              XkbNewKeyboardNotifyMask | XkbMapNotifyMask | XkbStateNotifyMask,
[10:04] <seb128>                              XkbNewKeyboardNotifyMask | XkbMapNotifyMask | XkbStateNotifyMask);
[10:05] <seb128> desrt: do you know if that's the part that need to be changed and how?
[10:05] <desrt> ya.  that's what i see now.
[10:05] <desrt> that's almost definitely the part that needs to change
[10:06] <desrt> look how they both come before the XkbSetDetectableAutoRepeat
[10:06] <seb128> Zdra_: from the bug you pointed, click on the ubuntu bug pointed, you will notice it has been fixed before dapper :)
[10:06] <desrt> seb128; i bet you could replace the XkbSelectEvents with the new XkbSelectEventDetails outright with no ill effects
[10:06] <desrt> seb128; but i'd ask mclasen
[10:07] <Zdra_> seb128: oops, sorry !
[10:07] <seb128> desrt: thank you, I've no real knowledge of xkb code and I don't want to break GTK to dapper ;)
[10:07] <seb128> Zdra_: no need to be sorry, thank you for pointing things you think that should be fixed ;)
[10:07] <desrt> seb128; ask matthias to be really sure :)
[10:07] <seb128> desrt: will do
[10:08] <desrt> tseng; eat me.  you broke my muine.
[10:08] <tseng> desrt: no
[10:08] <tseng> desrt: seb did
[10:08] <desrt> no.  seb didn't.
[10:08] <desrt> i didn't _realise_ that it was broken until you asked me to start it
[10:08] <tseng> sigh.
[10:09] <tseng> I told you it was broken the other day
[10:09] <tseng> fair warning
[10:09] <desrt> muine uses libdbus-1-cil
[10:09] <seb128> what broke it?
[10:09] <desrt> so the bug is probably that the dbus library abi changed in such a way that libdbus-1-cil doesn't quite fit anymore
[10:09] <tseng> seb128: iain took a 2.14 gnome system
[10:09] <tseng> upgraded just gnomevfs to 2.15
[10:09] <tseng> this started the breakage there
[10:10] <tseng> now, muine 0.8.3 works
[10:10] <seb128> ABI breakage on gnome-vfs? not good
[10:10] <tseng> and removing the gnomevfs related diff doesnt fix it
[10:10] <desrt> gnomevfs 2.15 would probably pull in a new dbus?
[10:10] <tseng> desrt: yes.
[10:10] <desrt> seb128; hah!
[10:10] <tseng> but downgrading dbus doesnt fix it
[10:10] <tseng> i am still fuzzy on the cause
[10:10] <desrt> seb128; welcome to the world post-bug 348100
[10:10] <tseng> i only have iains word to go by
[10:10] <seb128> is mono likely to be confused by bonobo function being moved around?
[10:10] <tseng> to point us at vfs
[10:11] <tseng> seb128: very doubtful
[10:11] <tseng> i dont know of any bonobo using mono apps
[10:11] <tseng> unless gnomevfs-sharp is?
[10:11] <desrt> i think you're wrong about gnome-vfs
[10:11] <seb128> macOS is confused by it :p
[10:11] <seb128> and it broke gnome-python too
[10:11] <desrt> i _hope_ you're wrong about gnome-vfs
[10:11] <tseng> desrt: I think I am too
[10:11] <tseng> desrt: but iain didnt make up what he saw
[10:11] <tseng> so its where I started
[10:12] <tseng> if you have a better idea..
[10:12] <tseng> I'll investigate it
[10:12] <desrt> i'm testing some ideas out
[10:12] <seb128> I'm not sure of how bindings react that functions move
[10:12] <seb128> but the python ones were broken by it
[10:12] <tseng> seb128: there are other things using dbus-sharp in a similar way
[10:12] <tseng> they aren't dying
[10:12] <desrt> oh.  there goes that idea
[10:12] <desrt> >:|
[10:13] <seb128> is the issue dbus-shard or gnomevfs-sharp?
[10:13] <tseng> seb128: not sure
[10:13] <tseng> the stacktrace clearly points to dbus
[10:13] <desrt> i thought maybe libdbus-1-cil didn't get updated when dbus was upgraded
[10:13] <tseng> iain says downgrading vfs is the fix
[10:13] <desrt> i guess that's impossible
[10:13] <tseng> desrt: yeah.
[10:13] <seb128> k, so not likely to be the bonobo changes to gnomevfs then
[10:13] <tseng> desrt: did you see that i said muine 0.8.3 works
[10:14] <tseng> if you fix one tiny compiler bug
[10:14] <desrt> dude
[10:14] <desrt> downgrading gnome-vfs uninstalls half the system
[10:14] <tseng> he was working from sources
[10:14] <tseng> which is why i havent confirmed this
[10:14] <desrt> including muine :)
[10:14] <tseng> yes :)
[10:14] <tseng> he had dapper and build gnomevfs from source
[10:15] <tseng> i believe.
[10:15] <tseng> then installed pkg back over top
[10:16] <crimsun> this is off the current discussion, but are there plans to replace esound with pulseaudio in edgy? If so I should start fixing the alsa plugin bits.
[10:16] <desrt> k
[10:16] <desrt> crash occurs in pthread_mutex_lock
[10:17] <tseng> (really?)
[10:17] <tseng> gross
[10:17] <desrt> gdb may be lying
[10:17] <ogra> crimsun, i wanted to have it in ltsp at some point, but wasnt planning to work on it in edgy yet (rather +1)
[10:18] <desrt> maybe new/old gnome-vfs uses/stops-using pthreads and this somehow ends up indirectly affecting dbus?
[10:18] <tseng> that would be pretty sick
[10:18] <tseng> latexer suggested initializing gnomevfs by hand
[10:18] <tseng> which i put in the FileUtils singleton
[10:18] <tseng> Init()
[10:18] <tseng> this didnt help.
[10:19] <desrt> heck
[10:19] <desrt> maybe bonobo itself is responsible for the pthread thing
[10:19] <tseng> I would think we would have noticed somewhere else
[10:19] <crimsun> ogra: ok. Well, I'll start getting the bottom of the stack (from alsa side) ready in case you miraculously find time to poke it with a stick.
[10:19] <tseng> i took the dllimport of gnomevfs out as well
[10:20] <tseng> so its all through gnomevfs-sharp
[10:20] <desrt> the dbus glib bindings use threads
[10:20] <ogra> crimsun, it looks like pulse is/will be capable of remote mixer stuff and the like ... its very very intresting for ltsp
[10:26] <janimo> seb128: gdm via gksu :)
[10:27] <janimo> I mean gconf via gksu via gdm
[10:28] <tseng> desrt: driving home, be back in 20
[10:29] <seb128> janimo: ah, that's not from the gdm code but just because of the menu item, we could use a Recommends for it
[10:29] <desrt> tseng; i won't be here, most probably
[10:29] <desrt> tseng; cheers
[10:29] <janimo> seb128: but still needed if you want to launch gdmsetup from the menu
[10:30] <seb128> janimo: right
[10:30] <seb128> you use gksu for xubuntu anyway, no?
[10:30] <janimo> yes, so that;s why gconf is not an issue
[10:30] <janimo> it is needed by too many thiings
[10:34] <desrt> oh my
[10:34] <desrt> dbus_gmutex_lock (0xabcdef)
[10:34] <desrt> that doesn't look like a very likely address for a mutex.....
[10:35] <desrt> hmmmm
[10:35] <desrt> #define _DBUS_DUMMY_MUTEX ((DBusMutex*)0xABCDEF)
[10:35] <desrt> tseng; this is for your benefit.  i hope you have a good scrollback :)
[10:39] <desrt> tseng; problem appears to be that someone calls dbus_new_lock (or whatever) then initialises the thread functions then calls lock()
[10:39] <desrt> tseng; lock(), if the thread functions are not initted, ignores its argument
[10:39] <desrt> tseng; so 0xabcdef would be fine.   but if you use a pre-initialised lock value with a post-initialised lock then the lock function expects a legit value
[10:46] <desrt> wow.  god really _does_ kill a kitten every time you output to stdout from a library
[10:49] <desrt> tseng; k.  problem is thus:
[10:49] <desrt> gnome-vfs calls dbus_g_thread_init ().  it didn't use to do this.
[10:49] <desrt> on muine start, dbus-glib acquires a lock for itself (which is 0xabcdef because locking isn't initialised)
[10:49] <desrt> then gnome-vfs calls dbus_g_thread_init(), switching the locking stuff on
[10:49] <desrt> then when dbus-glib goes to use its lock shit explodes
[10:50] <desrt> this is sort of a big not-easily-solveable problem
[10:52] <viper550> I've noticed the acclomplishments you've made on Usplash
[10:54] <viper550> hello?
[10:58] <viper550> Is anyone here?
[10:58] <Hobbsee> viper550: there's a tech board meeting on at the moment
[10:59] <viper550> ubuntu-meeting? I'm there!
[11:02] <tseng> desrt: wow
[11:02] <tseng> desrt: good catch.
[11:11] <pitti> hi keescook 
[11:11] <keescook> hiya!  :)
[11:11] <keescook> wasn't sure if you were still awake.  :)
[11:12] <pitti> keescook: we have a meeting right now
[11:12] <keescook> ah-ha, very cool.
[11:13] <pitti> keescook: btw, you don't happen to have experience with avahi?
[11:14] <pitti> keescook: this topic will be discussed in the current tech board meeting once the new members have been discussed
[11:14] <keescook> not specifically with the codebase, but I've toyed very briefly with other mDNS implementations.
[11:15] <keescook> I've been eyeing it from an "information leakage" angle.  :P
[11:15] <keescook> what in particular about it was going to be of interest?
[11:16] <geser> gnupg 1.4.5 (released today) contains two security fixes. should someone special be noticed about it?
[11:16] <pitti> keescook: whether we can enable it by default or not mainly
[11:17] <pitti> keescook: there was a huge thread on ubuntu-devel, maybe you can just take a look at https://lists.ubuntu.com/archives/ubuntu-devel/2006-July/019680.html
[11:17] <keescook> pitti: Ah, yeah, to that I can't say, but my kneejerk without having looked through the codebase would be "no".  It's relatively young code.
[11:17] <pitti> keescook: (but only if you are interested, of course)
[11:17] <pitti> keescook: heh, mine too :)
[11:17] <keescook> pitti: I'll take a read, but it probably won't be for a few hours.
[11:17] <pitti> keescook: don't worry then
[11:30] <lucas> how can I get in touch with a powerpc buildd admin ?
[11:33] <pitti> lucas: mail/ping infinity 
[11:34] <lucas> ok, thks
[11:34] <pitti> lucas: sure you want a buildd admin?
[11:34] <pitti> s/^/are you/
[11:34] <lucas> well, there's a very strange build failure on powerpc
[11:34] <lucas> actually, two of them
[11:34] <lucas> it's difficult to understand them without getting access on the system itself
[11:34] <pitti> do you have the log URL?
[11:34] <pitti> hm
[11:35] <lucas> http://librarian.launchpad.net/3642591/buildlog_ubuntu-edgy-powerpc.revolution_0.5-3ubuntu1_FAILEDTOBUILD.txt.gz
[11:35] <Hobbsee> pitti: sigh.  :P  they're into questions today, but i can understand why.
[11:35] <pitti> lucas: if the chroot/buildd is broken, then you need infinity
[11:35] <lucas> search for [BUG]  Segmentation fault
[11:35] <lucas> ruby looks broken
[11:35] <pitti> Hobbsee: well, once you are in ubuntu-core-dev, you can do a lot of trouble potentially :)
[11:36] <Hobbsee> pitti: oh of course.  i really dont blame them.  most annoying that mdz didnt see the last logs though
[11:39] <gnomefreak> Hobbsee: you are handling being hammered good ;)
[11:39] <Hobbsee> gnomefreak: yeah, surprisingly.  i'm still mostly asleep
[11:39] <gnomefreak> its what like 4am there?
[11:40] <Hobbsee> gnomefreak: meeting started at 6
[11:40] <Hobbsee> it's 7.40am now
[11:40] <gnomefreak> damn thats still early
[11:41] <Hobbsee> gnomefreak: yeah, and i'm not a morning person
[12:00] <pitti> Hobbsee: I think creating a  'sponsoring team' and filing bugs with this team in CC should work
[12:00] <pitti> Hobbsee: and with a little script it should be as easy as 'request_sponsor foo.debdiff'
[12:01] <Hobbsee> pitti: yeah, if it got done.
[12:01] <crimsun> pitti: I'm happy to be on said sponsoring team as need be.
[12:02] <pitti> Hobbsee: yep, I will do some python fu tomorrow