[12:11] <Hobbsee> pitti: cool
[12:14] <dholbach> good night guys
[12:15] <Hobbsee> night dholbach 
[12:18] <Hobbsee> Keybuk: w.r.t. email, it is possible, if the person actually sees it. and its' easier to keep track of pacakages if you're only uploading a few at a time.
[12:18] <Hobbsee> Keybuk: not trying to keep track of many.
[12:19] <gnomefreak> night dholbach 
[12:20] <gnomefreak> Hobbsee: i will help out as much as i can with kubuntu (just let me know)
[12:20] <Hobbsee> gnomefreak: your bugwork stuff is great :)
[12:20] <Hobbsee> means i dont have to do it
[12:20] <gnomefreak> ;)
[12:20] <gnomefreak> Hobbsee: i have a few you can take if you want them (me and backtraces are not friends today)
[12:21] <Hobbsee> gnomefreak: eh. me neither.
[12:22] <gnomefreak> and thunderbird
[12:22] <Riddell> gnomefreak: workaround?
[12:22] <gnomefreak> fonts 
[12:22] <gnomefreak> it only shows first few letters of a row
[12:23] <lucas> I've a package which just needs a rebuild because of an ABI change. should I mail infinity ? upload a -XXXbuild1 package ? file a bug ?
[12:23] <Hobbsee> *shit*
[12:23] <gnomefreak> for some reason i can only duplicate it in mozilla engines
[12:23] <tritium> get your butt to class, Hobbsee ;)
[12:24] <Hobbsee> heh
[12:24] <gnomefreak> math
[12:24] <gnomefreak> lol
[12:24] <gnomefreak> ok brb let me boot kde and see if i cant find out more info on this before bed
[12:26] <Keybuk> pitti: got a brief question about dhclient, if you have a few moments
[12:26] <pitti> Keybuk: as long as it's not too difficult, sure :)
[12:27] <Keybuk> the dhclient hooks are run as root, even though the daemon is de-rooted to run as dhcp, yes?
[12:27] <pitti> right, they have to
[12:27] <Keybuk> and there's an apparent, but unconfirmed/debugged bug where sometimes this doesn't happen?
[12:28] <pitti> Keybuk: yep, ISTR reading about some 'permission denied' bug
[12:28] <pitti> Keybuk: most of them were killed with a fix in dapper
[12:28] <pitti> Keybuk: but it's entirely possible that some corner case is still present
[12:29] <Keybuk> okies
[12:29] <Keybuk> then dhcdbd doesn't need permission for the dhcp user to talk to it
[12:30] <pitti> 'it' being the daemon or the script?
[12:30] <LaserJock> mdz: I think perhaps doko uploaded a broken matplolib to -updates universe, is it better to leave it for him or upload a fixed package?
[12:30] <Keybuk> pitti: dhcdbd dcaemon
[12:30] <pitti> ah
[12:31] <pitti> Keybuk: no, I do not see a reason why dhclient should talk to dhcdbd
[12:32] <gnomefreak> LaserJock: someone in #ubuntu is asking about that package
[12:32] <LaserJock> gnomefreak: oh really?
[12:32] <gnomefreak> yeah
[12:33] <gnomefreak> tell him its being worked on?
[01:04] <Riddell> is there a vari
[01:04] <Riddell> is there a variable with the name of the source package I can use in debian/rules?
[01:06] <doko> Laser_away: don't ping and start talking about the topic 4h later ... :-( if you do have a fix for a problem, please file a bug report (if there isn't one already) and attach a patch
[01:08] <LaserJock> doko: sorry
[01:53] <LaserJock> doko: debdiff at malone bug #54821, thanks
[01:53] <Ubugtu> Malone bug 54821 in matplotlib "python-matplotlib won't install" [Untriaged,Confirmed]  http://launchpad.net/bugs/54821
[02:32] <Riddell> infinity: libassuan-dev doesn't seem to have been moved to main
[02:32] <Riddell> although the source package has
[02:39] <Keybuk> Riddell: doesn't look as though anyone has explicitly promoted it
[02:39] <Keybuk> the source is probably "wrong"
[02:41] <Keybuk> fixed
[02:43] <gnomefreak> did anything take the place of pd-externals?
[02:43] <TheMuso> gnomefreak: No.
[02:44] <bddebian> Howdy
[02:44] <TheMuso> gnomefreak: Did you read the bug?
[02:44] <floam> is openoffice all borken for anyone else?
[02:44] <floam> (I've got some dependency hell going on in edgy)
[02:44] <gnomefreak> TheMuso: yes and i would like to close it
[02:44] <gnomefreak> TheMuso: thats why im asking
[02:44] <TheMuso> Right.
[02:45] <gnomefreak> floam: it will be fixed soon
[02:45] <gnomefreak> soon = not today give it a few days
[02:46] <floam> gnomefreak: I don't mind it being broke, I just worry when I think I could be the only one
[02:47] <gnomefreak> floam: everyone had it broke you have to remove every OOo package and reinstall openoffice.org (iirc)
[02:48] <gnomefreak> TheMuso: i went ahead and closed it due to you gave him all info he wanted (i miss read the last line about the CVS)
[02:48] <TheMuso> Ok.
[02:51] <floam> gnomefreak: ah removing it all at the same time did seem to cure it
[02:54] <bddebian> Thanks Keybuk
[02:56] <Keybuk> :)
[02:56] <Keybuk> you can tell I'm avoiding work
[02:57] <bddebian> I can?
[02:57] <Keybuk> that's the best thing about being on the ubuntu-archive team; you have hours of entirely legitimate work that can be done instead of whatever it was you were supposed to be doing and are procrastinating about
[02:58] <zul> oh hey Keybuk 
[02:58] <bddebian> Ah, I see.  And here I was feeling bad about all the sync requests
[02:58] <Keybuk> bddebian: *shrug* provided they're in alphabetical order, I don't mind ;)
[02:58] <bddebian> Heh
[02:58] <Keybuk> (makes it easier to cut and paste the output into the bug report)
[03:10] <zul> Keybuk: xen adds a udev rule is it ok to call it 92-xen-backend.rules?
[03:11] <crimsun> I'd choose 95- if it loads modules.
[03:11] <bluefoxicy> has anyone figured out who's mess the double-swap thing is or what happens if you enter that second swap device?
[03:11] <Keybuk> zul: what does the rule do?
[03:11] <zul> it loads the bridges needed for networking and the block devices needed
[03:12] <Keybuk> bluefoxicy: "double swap thing" ?
[03:12] <Keybuk> zul: loads modules?  then 95
[03:12] <bluefoxicy> Keybuk:  swapon -a
[03:12] <bluefoxicy> Keybuk:  err, sorry.  swapon -s
[03:12] <zul> Keybuk: ok
[03:12] <Keybuk> bluefoxicy: ?
[03:12] <Keybuk> bluefoxicy: bug#?
[03:13] <bluefoxicy> Keybuk:  whatever your swap device is, i'ts /dev/<whatever> and /dev/evms/<whatever> that get loaded now due to the UUID thing in fstab bug #54753
[03:13] <Ubugtu> Malone bug 54753 in Ubuntu "Edgy double-adds swap" [Untriaged,Confirmed]  http://launchpad.net/bugs/54753
[03:13] <Keybuk> bluefoxicy: oh yeah
[03:13] <Hobbsee> bluefoxicy: what was the fix for that?  or just wait?
[03:13] <Hobbsee> hey Keybuk 
[03:14] <Keybuk> evms is the sux0r
[03:14] <bluefoxicy> Keybuk:  as far as I know, nobody has yet been brave enough to get Linux to start writing into the second swap device; I would imagine it'd be about the computer equivalent of sliding a lit M80 up your rectum
[03:14] <Keybuk> bluefoxicy: with or without lubricant?
[03:15] <zul> mmm...bottom
[03:15] <Ubugtu> Malone bug 1 in ubuntu-desktop "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
[03:15] <bluefoxicy> Keybuk:  mmm... I don't think it makes much of a difference when the fuse burns down.
[03:15] <zul> jdub: FYI http://70.29.57.2/ubuntu/xen.png
[03:15] <Keybuk> bluefoxicy: it's obvious who broke it
[03:16] <Keybuk> just not obvious who has the skillz to fix it
[03:16] <bluefoxicy> Keybuk:  well, there are multiple theories over here.
[03:16] <bluefoxicy> Keybuk:  1)  whoever converted fstab should have tested this first
[03:16] <Keybuk> there are?  who?
[03:16] <bluefoxicy> Keybuk: 2)  Removing evms fixes it, maybe this is a mount problem.
[03:16] <tseng> sigh
[03:16] <Keybuk> person who did the fstab conversion explicitly didn't test evms, lvm, raid, etc. and said as much
[03:16] <bluefoxicy> Keybuk: 3)  the KERNEL should probably figure out that these are the same device and not let us doi t.
[03:16] <jdub> zul: oh, btw, i booted the xen kernel this morning
[03:16] <zul> and?
[03:17] <Keybuk> because person who did the fstab conversion knows fuck all about them and doesn't care for them either
[03:17] <tseng> er.. bddebian 
[03:17] <Keybuk> #2 is true, evms is not installed in new edgy installs anyway
[03:17] <bluefoxicy> Keybuk:  nods.  they were in Breezy or Dapper, so upgrades are likely to see this.
[03:17] <jdub> zul: is there an ubuntu-xen channel to chat aobut it in? or ubuntu-kernel?
[03:17] <Keybuk> but as you say, the upgrade path needs to cope here
[03:17] <zul> ubuntu-kernel works
[03:17] <Keybuk> this will probably be fixed at the dev summit
[03:18] <Keybuk> when the person who cares about the fabbione filesystems can sit next to the person who did the uuid mounting
[03:18] <zul> jdub: however i was just about to run to the store
[03:18] <bddebian> Hey if I'm too useless to be a core-dev, can I at least get op in here? ;-)
[03:18] <bluefoxicy> Keybuk:  yeah.  My thinking is somewhere along the line either mount or the kernel needs to say "uh uh no screw that" when you double-add a swap dev.
[03:18] <Keybuk> bluefoxicy: *nods*  the migration needs to special-case evms and lvm I suspect
[03:18] <Keybuk>                                   ^also
[03:18] <jdub> zul: ok, ping me when you're around - i was about to grab lunch, too :)
[03:19] <bluefoxicy> Hobbsee:  btw, uninstall evms (and reboot) or swapoff the second swap device (each time you boot), or both.  That'll get rid of it.
[03:20] <Keybuk> we've got an open task to patch mount to use libvolume_id instead of libblkid
[03:20] <Keybuk> no idea whether that fixes it or not
[03:20] <Hobbsee> bluefoxicy: oh nice.   want to tell me why it's being installed on my system anyway?
[03:20] <Keybuk> Hobbsee: was installed by default in dapper, no longer in edgy
[03:20] <bluefoxicy> Hobbsee:  evms?  it was in breezy and/or dapper
[03:20] <Hobbsee> Keybuk: ah good.  i dist-upgraded
[03:20] <bluefoxicy> will somebody get itunes working in Ubuntu JESUS
[03:21] <bluefoxicy> my mom is screaming about crap on windows again, I just want to stick Linux on there so she can go away ><
[03:21] <Hobbsee> bluefoxicy: i thought people were doing stuff with that.  amarok handles it better
[03:21] <bluefoxicy> back in a few minutes.
[03:23] <bddebian> thanks for the warning
[03:28] <Hobbsee> Keybuk: mdz if now-ish is a suitable time to discuss what happens with uploads to main, etc, that's cool here.
[03:35] <zul> jdub: ping im back
[03:39] <bluefoxicy> tseng:  stop poking meeeeeeeeee  </warcraft>
[04:07] <infinity> Riddell: Sorry about that.  I did a source+binary promotion, and soyuz appears to not believe that that binary belongs to that source...
[04:08] <Keybuk> infinity: you forgot to move it on the queue page too then <g>
[04:08] <infinity> Keybuk: It was 3am, give me a break. :)
[04:09] <infinity> Keybuk: At any rate, the soyuz bug is clearly still there.  Bah.
[04:09] <Hobbsee> infinity: fix it.  even at 3am :P
[04:19] <robertj> Can we get edgy+1 as a spec target on launchpad?
[04:19] <Hobbsee> robertj: probably ask that in #launchpad
[04:19] <robertj> I thought about that, just though it was probably more a policy question
[04:20] <robertj> but if noone feels strongly, I'll file a bug
[04:24] <robertj> Bug #54869
[04:24] <Ubugtu> Malone bug 54869 in Ubuntu "edgy+1 needed as a release target for spec drafting" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/54869
[04:25] <Hobbsee> robertj: package effected for that should be launchpad
[04:25] <Hobbsee> *it
[04:26] <infinity> s/launchpad/blueprint/
[04:26] <Hobbsee> oh.  wait.  i assigned it wrong.  i thought you could assign things to launchpad
[04:26] <Hobbsee> ahhh...
[04:27] <Hobbsee> infinity: who renamed that so unintuitively?  :P
[04:27] <infinity> blueprint is the name of the spec tracker.
[04:27] <Hobbsee> right
[04:27] <infinity> "launchpad" isn't a product at all, just a service that ties them all together.
[04:27] <Hobbsee> news to me.
[04:27] <Hobbsee> yep, true
[04:27] <infinity> blueprint, soyuz, malone, etc.
[04:28] <Keybuk> robertj: that would be an incorrect bug ... we don't use the spec targets until they have been approved
[04:28] <Hobbsee> infinity: one problem anyway.  there's no way to assign anything to blueprint
[04:28] <Keybuk> and specs for edgy+1 wont be approved until the edgy+1 development summit
[04:28] <Keybuk> which happens after edgy+1 has opened
[04:29] <robertj> ah
[04:29] <infinity> Hobbsee: Because it's not an ubuntu package.  You need to add a new task for the product.
[04:29] <Hobbsee> ah
[04:29] <infinity> Hobbsee: Of course, as Keybuk mentions, it's probably pointless anyway.
[04:29] <Hobbsee> well, yeah, but it's useful to know.
[04:29] <Keybuk> I think the blueprint targets are also just the list of releases for the distro
[04:30] <infinity> Reassigning a bug from a package to a product is less than intuitive, yes.
[04:30] <Keybuk> and there's no way to open a edgy+1 release without closing edgy
[04:30] <infinity> Add new task, reject original task.
[04:30] <infinity> Keybuk: That's not true, we can have multiple open dists at the same time.  Of course, we don't WANT that.
[04:31] <Keybuk> infinity: right
[04:41] <jdub> zul: pong
[04:42] <zul> jdub: i was just about to head to bed but i can stay for a bit longer
[04:42] <jdub> :)
[04:42] <jdub> won't keep you long
[04:42] <zul> ok
[04:42] <ajmitch> afternoon jdub 
[04:42] <jdub> you konw about the TLS-related 5s delay message?
[04:42] <zul> yep..
[04:42] <zul> im working jeff to fix it
[04:43] <zul> its glibc and xen thingy
[04:43] <zul> next..:)
[04:44] <ajmitch> next to be fixed is my wireless with that kernel :)
[04:44] <jdub> zul: we're definitely not going to have a single linux/xen for edgy?
[04:44] <ajmitch> zul: got a git tree of that kernel that you're working from?
[04:44] <zul> correct..
[04:45] <zul> ajmitch: working on it this weekend hopefully
[04:45] <ajmitch> ok
[04:45] <jdub> zul: which is the scarier side of the fence - patching a kernel so it'll run on xen (domU), or patching a kernel so it can be a dom0?
[04:45] <ajmitch> then I can try & ram ipw2200 in
[04:46] <zul> jdub: its a config option, dom0 kernels can do both but i was thinking of supplying a domU kernel as well
[04:47] <jdub> zul: right, but it requires scary patching to make our linux-image dom0 capable?
[04:47] <zul> jdub: yes, edgy kernel uses a different alt-smp than that of the xen-kernel
[04:47] <zul> and upstream is based off of 2.6.16.13
[04:48] <jdub> ahr
[04:48] <jdub> scary
[04:48] <zul> very...and very masochistic
[04:48] <jdub> i was about to say ;)
[04:49] <jdub> uh, now i've forgotten the other things
[04:49] <jdub> i'll play with it again and ping you when you're up :)
[04:49] <zul> and there was a modificaton to kernel-package to get the naming correct
[04:49] <zul> jdub: ok i just uploaded a -3 xen-utils and in the process of upload a -4 kernel 
[04:50] <zul> my isp is going to love me this month ;)
[04:50] <zul> jdub: oh yes if you were going to ask for grub, debian has a patch for update-grub already
[04:51] <ajmitch> mine already loves me lots..
[04:51] <jdub> rad
[04:51] <ajmitch> zul: does the -4 kernel create the initramfs?
[04:51] <zul> no it doesnt...debian doesnt as well
[04:51] <ajmitch> ok
[04:51] <zul> afaik
[04:52] <zul> there should be really a #ubuntu-xen meh...anyways im going to bed...night
[04:52] <ajmitch> yeah
[04:52] <ajmitch> night
[04:52] <jdub> zul: planning to do lrm packages for xen-image?
[04:53] <zul> uh...good question..to get nvidia working with xen is kind of hackish from what i read
[04:53] <ajmitch> jdub: proprietary drivers like nvidia tend not to play nicely with xen
[04:53] <ajmitch> heh
[04:53] <ajmitch> should be possible, I guess
[04:54] <ajmitch> my poor laptop is tethered again by ethernet
[04:54] <jdub> it's a pity there are so many infrastructural changes that  need to be made
[04:54] <jdub> making it hard to backport for dapper
[04:56] <zul> right this time im going to bed..
[04:56] <infinity> There's been a VERY LOUD fire alarm going off down the street for the last half hur.
[04:56] <infinity> s/hur/hour/
[04:57] <infinity> I'm nearly ready to kill.
[04:57] <imbrandon> infinity: bb gun --> speaker
[04:57] <imbrandon> heh
[04:58] <zul> jdub: if you have any questions feel free to email me
[05:01] <Keybuk> infinity: you would have gone nuts here at the weekend
[05:01] <Keybuk> some kids burned down the local sub station
[05:01] <bddebian> bb gun? pfft, 20 Gauge
[05:01] <Keybuk> and for the first few hours of the power outage every single house alarm for miles was going off
[05:02] <bluefoxicy> heh
[05:02] <bluefoxicy> with no power
[05:03] <Keybuk> assumedly they get their power from elsewhere
[05:03] <bluefoxicy> speaking of power, my computer is on a UPS.  It's required.
[05:04] <jdub> ajmitch: whoa, xgl update
[05:04] <bluefoxicy> When my AC kicks in it can knock the power out because I have more power drain up here (FROM ONE SOCKET MIND YOU) than the breaker allows.  (a wall -> 6 way splitter; a UPS; a power strip; another power strip)
[05:04] <bluefoxicy> so my UPS goes down and relieves the load for about 3 seconds :P
[05:05] <ajmitch> jdub: correct
[05:05] <ajmitch> I thought I may as well get it out there & get the bugreports flooding in
[05:06] <ajmitch> jdub: f-spot also added to desktop seed in the bzr branch, just need to get ubuntu-meta updating properly
[05:06] <jdub> ajmitch: cool
[05:09] <Keybuk> *sigh*
[05:09] <Keybuk> now my hardphone is deciding it doesn't like the network every few minutes
[05:10] <whiprush> hi Keybuk 
[05:10] <bddebian> Why are there buildX versions that didn't get synced automagically?
[05:10] <bddebian> Heya whiprush
[05:10] <whiprush> hi bddebian, others ...
[05:10] <ajmitch> bddebian: debian may have updated after the autosync was turned off
[05:10] <ajmitch> hey whiprush 
[05:11] <Keybuk> hmm, there's half a dozen firmware updates for my hardphone
[05:11] <Keybuk> maybe one of those helps ...
[05:11] <whiprush> Keybuk: man dude, I bet 20 bucks you get hosed on network-manager syncage again this cycle.
[05:11] <Keybuk> whiprush: how do you mean?
[05:12] <bddebian> ajmitch: Fair enough, thx
[05:12] <whiprush> major release at the most crappy times.
[05:12] <Keybuk> I'm largely ignoring network-manager this cycle
[05:13] <whiprush> wotcha working on?
[05:14] <Keybuk> upstart
[05:14] <whiprush> heh
[05:14] <whiprush> I just remembered the dash thing
[05:14] <Hobbsee> Keybuk: make StevenK do it :P
[05:16] <Kaleo> Hello guys 
[05:18] <bddebian> Hello Kaleo
[05:18] <Kaleo> Hi bddebian 
[05:25] <Kaleo> bddebian, do you know who usually hacks on ubiquity ?
[05:26] <bddebian> Not really, sorry
[05:26] <jdub> Kaleo: Kamion 
[05:27] <Kaleo> okay
[05:36] <Kaleo> jdub, thanks
[06:42] <micahcowan> I'm upgrading to edgy, so I can help squash bugs... is updating sources.list and doing apt-get dist-upgrade sufficient (actually, it's already underway...)?
[06:43] <Hobbsee> micahcowan: yes
[06:44] <micahcowan> great. Next question: it's halting because it wants /usr/X11R6/bin to be a symlink, so it wants me to move it out of the way. I figure it might be easier if the contents of that dir are already where they're going to be, perhaps... what is /usr/X11R6/bin going to point at (it didn't seem to say)?
[06:45] <Hobbsee> micahcowan: --> #ubuntu+1
[06:45] <micahcowan> oh, great. Thanks!
[06:58] <jdub> hrm
[06:58] <jdub> genius is not in ubuntu
[06:59] <Hobbsee> jdub: should it be?
[06:59] <jdub> yeah, totally
[07:00] <LaserJock> we have no genius?
[07:36] <Lathiat> probably :)
[07:39] <crimsun> reachable for me.
[07:40] <Lathiat> works for me too
[07:48] <raphink> yes that works now :)
[07:49] <raphink> it just took quite a long tim
[07:49] <raphink> time
[08:40] <dholbach> ogra: hellas! you might want to look into http://download.gnome.org/sources/genius/0.7/
[08:40] <dholbach> might be something for the edubuntu world
[08:41] <crimsun> you just missed   00:58 < jdub> genius is not in ubuntu   01:00  * jdub packages it as a birthday present for maia
[08:41] <dholbach> WOW
[08:42] <dholbach> jdub:  WAY TO GO !!!
[08:48] <jdub> dholbach: ha ha
[08:50] <mvo> ah ah ?
[08:54] <dholbach> ogra: how did gnome-screensaver 2.14.3 look?
[08:58] <pitti> Good morning
[08:58] <Burgundavia> morning pitti
[08:58] <Hobbsee> hi pitti!
[08:59] <Burgundavia> pitti: mpt and myself had a discussion about the crashingreporting UI in -desktop
[09:00] <pitti> hey Hobbsee 
[09:00] <pitti> Burgundavia: don't tell me you redesigned it once again :)
[09:01] <Burgundavia> pitti: not the edgy stuff. We were talking about the edgy+1 stuff
[09:01] <pitti> Burgundavia: yesterday I almost finished implementing his design
[09:01] <pitti> ah
[09:01] <dholbach> somebody please add #ubuntu-bugs to the topic
[09:03] <jdub> mvo: the apt update didn't fix the Packages.bz2 issue i was seeing
[09:03] <jdub> Failed to fetch http://people.ubuntu.com/~jdub/edgy/Packages.gz  404 Not Found
[09:03] <mvo> jdub: oh, crap. thanks for testing
[09:04] <pitti> AAAARRRRGH @ f-spot
[09:04] <Hobbsee> dholbach: like that?
[09:05] <pitti> ajmitch: nnnnnnggg, I explicitly unticked 'do not copy photos' during import and still it created a 5 GB ~/Photos folder and copied them
[09:05] <pitti> ajmitch: this just DoSed my backup system
[09:05] <dholbach> Hobbsee: super
[09:05] <ajmitch> pitti: interesting
[09:05] <jdub> infinity: around?
[09:06] <pitti> ajmitch: this should so much default to 'off'...
[09:06] <pitti> ajmitch: (sorry for the rant)
[09:07] <ajmitch> file a bug, I'll look for a patch in the stable branch upstream
[09:08] <pitti> ajmitch: will do
[09:08] <pitti> ajmitch: ooh, new xserver-xgl? COTD? :)
[09:09] <ajmitch> pitti: of course
[09:09] <jdub> i would test it if fglrx worked - gar! quebecistani craptop!
[09:09] <jdub> also, no xorg 7.1 means no aiglx love :(
[09:09] <jdub> aiglx > xgl :(
[09:13] <dholbach> jdub: you uploaded genius already? :)
[09:13] <jdub> dholbach: no
[09:13] <jdub> i have to fix up pbuilder before i feel comfortable uploading it
[09:13] <dholbach> ok
[09:13] <dholbach> in dapper it should suffice to install it
[09:14] <Hobbsee> jdub: you broke pbuilder?
[09:14] <jdub> it hasn't been working on my machine for a long time
[09:15] <Hobbsee> jdub: ahhh.  great
[09:15] <dholbach> create --override-config --distribution=<something>?
[09:29] <infinity> jdub: Yes, thought obviously less than attentive on IRC.
[09:30] <jdub> infinity: fuck, i should remember to add payloads to my pings
[09:30] <infinity> jdub: Yes.  Yes you should.
[09:31] <jdub> infinity: ah, that's right
[09:32] <jdub> infinity: i would like to make xnest an alternative, so we can switch between xnest and xephyr - are there any standardisation problems with that, and things we need to sort out with debian, or is it "propose a patch and go" type stuff?
[09:32] <infinity> Well, in the interest of sane sidegrades, you may want to make sure it happens in time for both etch and edgy.
[09:33] <infinity> But otherwise, it's just a matter of making the packaging changes correctly so it doesn't explode, and you're good to go.
[09:50] <pitti> Kamion: can you please accept/new all the new dapper langpacks?
[09:54] <Kamion> pitti: done
[09:54] <pitti> thanks
[09:54] <Kamion> infinity: hmm, I see my cheesy attempt at hacking around the pockets thing in d-i didn't work quite right
[09:54] <Kamion> infinity: should I fix the cheesy hack, or remove it and coordinate an upload with you?
[09:55] <Kamion> happy to do either (though it seems that fixing the cheesy hack might involve less messy coordination time in the future)
[09:57] <pitti> doko: yay, OO.o built everywhere *phew* :)
[09:57] <dholbach> pitti: that sounds as you were in doubt :)
[10:14] <Hobbsee> hehe
[10:24] <infinity> Kamion: I think the cheesy hack is probably the best way to go, actually.
[10:24] <infinity> Kamion: Oh, which you decided to do without prompting anyway.  Yay, response time.
[10:25] <tepsipakki> congrats, there's an article on Helsingin Sanomat (biggest newspaper in Finland) about installing Ubuntu. It's takes nearly the whole front page of part D :)
[10:25] <pitti> dholbach: not any more, because doko did not phone me at 3 am :)
[10:25] <Kamion> infinity: :-)
[10:26] <dholbach> pitti: hehe
[10:36] <doko> pitti: lucky guy :)
[10:36] <pitti> doko: so, if pkg-create-dbgsym works with OO.o, it just has to work with just about any other package, too :-P
[10:37] <doko> pitti: does it take as long as pkg-stripstranslations does? ;-P
[10:38] <pitti> doko: I don't know, but at least it has no redundancy (as striptranslations has)
[10:39] <dholbach> gutenprint 5.0 is there
[10:41] <pitti> oh, great
[11:04] <ajmitch> hunger: wireshark sync was already requested, just spotted it in -bugs :)
[11:12] <ajmitch> pitti: that's useful - I still have a package using tarball.mk & simple-patchsys
[11:12] <pitti> ajmitch: until now I had a separate script, but it used dbs-edit-patch, and it doesn't work very well
[11:13] <ajmitch> it's a package I never touched much, I adjusted the patch with vim each time
[11:14] <pitti> ajmitch: hal and g-v-m use tarball.mk, as well as postgresql, so I have a certain interest in a good patch edit script :)
[11:22] <janimo> pitti, while at it can you make it to accept debian/patches/xx_name as well, so only use basename of argument?
[11:22] <pitti> janimo: right, that was already on my list
[11:22] <janimo> as it's easier to use completion  than remember the names
[11:22] <janimo> ok:)
[11:29] <hunger> ajmitch: Thanks for the info wrt. wireshark!
[11:30] <ogra> seb128, dholbach ...
[11:30] <ogra> ogra@edubuntu:~/packages/gnome-screensaver-2.14.3$ debdiff ../gnome-screensaver_2.14.1-0ubuntu5.dsc ../gnome-screensaver_2.14.3-0ubuntu1.dsc|wc -l
[11:30] <ogra> 34295
[11:30] <ogra> that doesnt make me feel we should have it in -updates
[11:30] <ajmitch> hunger: I've fixed xserver-xgl, too, just have to upload
[11:30] <Chipzz> is there somewhere I can ask about ltsp on ubuntu?
[11:30] <ogra> Chipzz, yes
[11:31] <hunger> ajmitch: This is getting spooky!
[11:31] <Chipzz> ogra: where?
[11:31] <ogra> Chipzz, here or in #edubuntu ... ot in #ltsp .... 
[11:31] <hunger> ajmitch: so many of my bugs are vanishing today!
[11:31] <Chipzz> ogra: well, since this isn't a support channel... :P
[11:31] <ogra> in any case you'll likely talk to me ;)
[11:31] <dholbach> ogra: that depends on where the changes are - most of it is buildsystem for sure and translations
[11:31] <ajmitch> hunger: well I did upload xserver-xgl the first time - I just missed that conflict
[11:31] <seb128> ogra: 30000 lines of .po changes and 4000 of autogenerated Makefile and 400 of code? :p
[11:31] <dholbach> ogra: pipe it through diffstat
[11:31] <ogra> Chipzz, then #ltsp or #edubuntu
[11:32] <ogra> seb128, argh, i didnt think about the .po files :)
[11:32] <seb128> ogra: for other tarballs 90% of the changes where help translation and .po
[11:32] <hunger> ajmitch: No problem:-) It is just that this is the 4 or 5th of my bugs that got squashed today;-)
[11:33] <ajmitch> hunger: you should be happy about that :)
[11:33] <hunger> ajmitch: I definitly am!
[11:33] <ogra> seb128, yep ... i just didnt think about that ... and i'm convinced autotools wont produce 30000 line diffs ;)
[11:34] <ogra> oh, well, diffstat disagrees even here :) aclocal.m4                          |12821 ++++++++++++++++++------------------
[11:35] <seb128> :p
[11:52] <hunger> Riddell: Any news on the edgy/artsd crashes?
[11:54] <Riddell> hunger: looks like kdemultimedia decided to go with the wrong akode even though I gave it a versioned build-dep
[11:55] <Hobbsee> Riddell: darn.  eta on the fix?
[11:56] <Riddell> I'll throw it up for another build now
[11:57] <doko> interesting, 2.0.3-4ubuntu2 < 2.0.3-3ubuntu2-1 ... didn't know that
[11:58] <infinity> doko: Well, 2.0.3-3ubuntu2 is the upstream version in the second case.
[11:59] <infinity> doko: There's only one Debian Revision, and it's the one after the last "-".
[11:59] <infinity> doko: (Policy strongly advises against, or perhaps even forbids, having more than 1 "-" in the version, for this very reason)
[12:00] <StevenK> I don't think they forbid it.
[12:00] <doko> ohh, I missed the -1 ...
[12:03] <infinity> The upstream_version may contain only alphanumerics[33]  and the characters . + - : (full stop, plus, hyphen, colon) and should start with a digit. If there is no debian_revision then hyphens are not allowed.
[12:03] <infinity> That doesn't read very clearly, since it seems to imply that if there's a debian_revision, multiple hyphens are allowed, but that's not really what it means. :)
[12:03] <infinity> And earlier:
[12:03] <infinity> The format is: [epoch:] upstream_version[-debian_revision] 
[12:03] <pitti> infinity: why, it's pretty clear, isn't it?
[12:04] <pitti> infinity: this essentially means that 'native packges must not have hyphens'
[12:04] <infinity> pitti: No, it's not quite clear.  If there's no debian_revision, hyphens aren't allowed (ie: for native packages), but it doesn't really specify how many you should have if there is (which is, ideally, 1)
[12:04] <pitti> and for non-native packages, the last hyphen separates the debian revision
[12:05] <infinity> Anyhow, just leads to this sort of accidental confusion.
[12:05] <infinity> No big deal.
[12:05] <pitti> infinity: I think it wanted to avoid specifying the number of hyphens
[12:05] <pitti> right
[12:15] <micah_c> What's the process for bugs that are assigned to MOTU-Reviewers? ...I'm interested in 45930, which is for the "joystick" package (jstest and similar). It's a /very/ inessential package; however, I've submitted a patch that fixes the issue, and am just curious when I might expect to see the package updated? I'm not impatient or anything...
[12:15] <micah_c> Actually, disregard that: #ubuntu-motu should be a much better place to ask this (I just realized...)
[12:21] <seb128> doko: I'm done with libs uploads to dapper-updates, now they have to be accepted and build
[12:21] <doko> seb128: ok, I have to find out these I need ...
[12:21] <dholbach> pitti: you rock!
[12:21] <seb128> dholbach: what did he do?
[12:22] <pitti> dholbach: do I? :) (thanks)
[12:22] <dholbach> seb128: cdbs hacking :)
[12:22] <pitti> ah, that :)
[12:22] <pitti> yep, that was a long-standing item on my todo
[12:22] <dholbach> and new gvm
[12:22] <seb128> doko: probably gtk-engins gtk+2.0 
[12:22] <seb128> gtk-engines
[12:22] <seb128> and maybe at-spi, dholbach would know
[12:22] <dholbach> update for gtk32-libssomething?
[12:23] <seb128> dholbach: for dapper-updates yep
[12:23] <dholbach> no, didn't do at-spi changes for dapper
[12:23] <doko> pango is already built
[12:24] <seb128> pango had no new version
[12:26] <seb128> ah, nice
[12:26] <seb128> better cdbs-edit-patch ;)
[12:27] <pitti> dholbach: FYI, I also updated the MOTU school patch page
[12:27] <pitti> seb128: enjoy!
[12:27] <pitti> seb128: it saved me a lot of time with the new g-v-m
[12:27] <dholbach> it's the HUG DAY :)
[12:27] <pitti> right!
[12:28] <seb128> pitti: I got used to mv the patch to the src dir, cdbs-edit, patch -p1 etc
[12:28] <Spads> Hmmm, I'm not seeing xen-image in edgy.  Am I missing something?
[12:28] <seb128> pitti: really nice that I can drop the extra steps now ;)
[12:29] <pitti> seb128: oh, you didn't use my cdbstpatch script? 
[12:29] <pitti> well, it's obsolete now anyway (and quite broken, too)
[12:29] <seb128> pitti: what script? I use cdbs-edit-patch
[12:29] <tseng> dholbach: python beagle bits have changed again, btw
[12:29] <dholbach> tseng: mh, what does that mean for me?
[12:30] <tseng> dholbach: its back to being called python-beagle (again)
[12:30] <dholbach> ahhhh
[12:30] <dholbach> is it in the archive again?
[12:30] <tseng> its in unstable
[12:30] <dholbach> ah ok
[12:30] <dholbach> once it hits the archive, i'll change the suggests from deskbar-applet
[12:30] <tseng> i think its in NEW for us
[12:31] <Ubugtu> Malone bug 37603 in ubuntulooks "Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits" [Medium,Unconfirmed]  http://launchpad.net/bugs/37603
[12:31] <dholbach> right-o
[12:41] <Spads> I can see packages for the guest Xen kernel, but not the host.  Has xen-image made it into edgy proper yet?
[12:42] <ajmitch> iirc the kernel can be used for both
[12:46] <Spads> hmmmm
[12:49] <imbrandon> ajmitch: i thought domU and dom0 kerns were diffrent
[12:49] <Spads> That's my experience
[12:50] <ogra> Spads, ask zul if he's arund
[12:50] <Spads> zul: ping
[12:50] <ogra> he packaged it
[12:50] <ajmitch> I'm sure zul mentioned that this one has them as either
[12:50] <ajmitch> as I've seen in debian
[12:50] <imbrandon> right, it might contain both
[12:51] <ajmitch> 14:46 < zul> jdub: its a config option, dom0 kernels can do both but i was thinking of supplying a domU kernel as well
[12:51] <imbrandon> ahh
[12:51] <ogra> iirc he said somethig about domU not being included
[12:51] <Spads> yeah
[12:51] <ogra> we only have dom0
[12:51] <Spads> the source package can be used to generate both
[12:51] <Spads> I saw chatter about a xen-image package for the host kernel
[12:51] <Spads> and I thought that was what the cheering was about earlier
[12:52] <ogra> the cheering was about seeing soething with xen in the name hitting the archive :P
[12:52] <Spads> 18:06 <bluefoxicy> I thought dom0 kernels could also run domU
[12:52] <Spads> 18:06 <zul> they can,we dont ship domU kernels
[12:52] <ogra> we're so easy to please :)
[12:53] <Spads> Huh.
[12:53] <Spads> Okay, this is a Xen 3.0 thing
[12:53] <Spads> color me impressed
[12:54] <ajmitch> ogra: you mean the cheering wasn't just about xgl, and the groan as new bugs come in?
[12:55] <imbrandon> heh
[12:55] <jdub> Spads: it works okay, but needs a bit of love
[12:56] <Spads> jdub: I notice no hypervisor package either
[12:56] <jdub> Spads: unfortunately it requires a bunch of infrastructure changes
[12:56] <jdub> Spads: xen-hypervisor-3.0-i386
[12:56] <Spads> oh
[12:56] <Spads> this is amd64
[12:56] <Spads> maybe that's why I'm not seeing it all
[12:57] <jdub> xen-hypervisor-3.0-amd64
[12:57] <Spads> W: Unable to locate package xen-hypervisor-3.0-amd64
[12:57] <jdub> hrm, maybe it hasn't built
[12:58] <Spads> ahhh
[12:58] <Spads> there are sources
[12:58] <Spads> good enough for me
[12:59] <Spads> jdub: thanks for the hints
[12:59] <ogra> https://launchpad.net/+builds/+build/233537
[12:59] <ogra> Spads, ^^
[12:59] <Spads> Gar.
[12:59] <Kamion> infinity: '-d dapper' doesn't seem to work via the ssh trigger; I get "bad project: -d"
[01:01] <infinity> Kamion: Lies.
[01:01] <infinity> Kamion: How do you invoke the trigger?
[01:01] <infinity> Kamion: Give me a full command-line.
[01:02] <doko> Kamion: dapper-proposed did build the native amd64 packages once, the resulting binary packages should be removed. do you want a bug report? openoffice.org-evolution, openoffice.org-dev
[01:03] <infinity> Kamion: Oh, I see the problem, I think.
[01:04] <infinity> Kamion: Try triggering on king...
[01:07] <doko> pitti: new firefox security upload for dapper?
[01:07] <pitti> doko: yet another one???
[01:08] <ogra> dholbach, does genius have a homepage ? 
[01:09] <dholbach> ogra: dunno
[01:09] <dholbach> ogra: jdub stepped up to package it
[01:09] <ogra> http://www.jirka.org/genius.html
[01:09] <ogra> found it :)
[01:09] <doko> pitti: no, I'm just confused, about our ia32-libs* packages for -security, -updates, and -proposed ...
[01:09] <ogra> jdub, slacker ! :)
[01:17] <Kamion> infinity: + ssh -o ControlPath none -n buildd@terranova.buildd /home/buildd/bin/BuildLiveCD -d dapper ubuntu
[01:17] <Kamion> infinity: yep, king seems happier now ...
[01:18] <Kamion> doko: yes please
[01:18] <mhb> hello everyone
[01:20] <mhb> I have a little devel-related question ... Are there plans to get the console (ALT+F1...) localised (displaying fine local characters, respect the keyboard setting etc.)?
[01:22] <infinity> Kamion: Okay, I'll update the others.  Thanks for testing.
[01:25] <infinity> Kamion: terranova and royal fixed too now.
[01:31] <pitti> doko: ah, now I know what you mean; no, ia32-libs* update is not required, the latest USN only fixed a regression in the browser itself (not in the libs)
[01:38] <mjg59> pitti: the suidness can't be removed from svgalib, hence my suggestion that we not include the binaries
[01:38] <mjg59> The library itself is safe
[01:41] <ldarnis> join #ubuntu-motu
[01:41] <ldarnis> oops
[01:43] <mjg59> Hm.
[01:43] <Hobbsee> hm?
[01:44] <Hobbsee> mjg59: i rather like keybuk's idea - if we've got an X server, give people a login window.
[01:44] <mjg59> Fujitsu: Minimises the amount of code that needs to be maintained
[01:44] <Hobbsee> mjg59: then show them the rest of the bootup, depending on hwo long they take to login.
[01:44] <sabdfl> Kamion: for the moment, we want to build foobuntu iso's but not publish them in the usual place
[01:44] <sabdfl> pass them on fsf europe for testing etc
[01:44] <mjg59> Hobbsee: Yeah, but we're not going to have an X server :)
[01:45] <Hobbsee> mjg59: pity....
[01:45] <Hobbsee> :P
[01:45] <pitti> mjg59: although I'm not generally a friend of code copies, if you only need a safe fragment of the code, then this could make sense
[01:45] <StevenK> mjg59: Why not just statically link? Even those that has an ick factor.
[01:45] <pitti> hey sabdfl 
[01:45] <Hobbsee> Kami*on will hate me, i think.  requesting more syncs :P
[01:45] <StevenK> s/those/though/
[01:45] <sabdfl> hey folks
[01:45] <mjg59> StevenK: Can't have build-depends in universe for packages in main
[01:45] <Fujitsu> Hi sabdfl!
[01:45] <StevenK> mjg59: Point.
[01:49] <mjg59> Ok, maybe this is doable
[01:49] <doko> seb128: gtk-engines will be updated as well for dapper-updates?
[01:49] <Kamion> sabdfl: how do we go about passing them on without publishing them on cdimage? I can't really mail ISO images around :)
[01:50] <Hobbsee> Kamion: well, you can try.  could be amusing to see the results too :P
[01:50] <Kamion> infinity: thanks
[01:50] <sabdfl> Kamion: they can be published, just not in the usual place
[01:50] <sabdfl> call them gnubuntu, please
[01:50] <sabdfl> it's unofficial until it's not, iyswim
[01:50] <Chipzz> sabdfl: what's rms going to say about that? :)
[01:51] <Kamion> ok, any ideas as to where to publish them though?
[01:51] <sabdfl> YES!
[01:51] <Kamion> people.ubuntu.com or something?
[01:51] <sabdfl> that would be fine
[01:51] <Chipzz> sabdfl: or are you referring to what rms actually wanted?
[01:51] <Kamion> so is it foobuntu or gnubuntu internally? getting mixed messages here :)
[01:51] <sabdfl> gnubuntu
[01:51] <Kamion> I'd just written "foobuntu" into a load of files
[01:51] <Kamion> d'oh
[01:51] <sabdfl> sorry
[01:51] <Kamion> oh well, shouldn't take long to sed
[01:52] <Kamion> I'm doing a test build now
[01:52] <doko> seb128: orbit2 stays at v 2.14.0 ?
[01:52] <doko> dholbach: or do you know about plans for orbit2 and gtk-engines ?
[01:52] <jsgotangco> \o/ gnubuntu \o/
[01:53] <dholbach> doko: for dapper?
[01:53] <doko> dapper-updates
[01:53] <Kamion> doko: do you mean gtk2-engines?
[01:53] <Kamion> gtk2-engines is already in the dapper-updates unapproved queue
[01:53] <dholbach> doko: there were not tarballs for orbit, but for gtk-engines
[01:54] <doko> sure, gtk2-engines
[01:55] <doko> dholbach: I don't see anything in launchpad for gtk-engines and gtk2-engines
[01:55] <dholbach> then it must be in the unapproved queue
[01:55] <Kamion> sabdfl: would the title-case name be Gnubuntu or GNUbuntu?
[01:55] <Kamion> dholbach: it is, as I said
[01:56] <Kamion> I did a lot of unapproved this morning, just lost the will to live part-way through - I'll regain it in a bit
[01:56] <sabdfl> Kamion: i've no idea which is more appropriate, would you take a squizz at gnu.org and see what they tend to prefer?
[01:57] <jsgotangco> GNU
[01:57] <doko> Kamion: is there still some stuff in the unapproved queue for dapper-updates?
[01:58] <Kamion> oh, if it's what they prefer then GNUbuntu seems likely - c.f. GNUtls, GNUstep. there are counterexamples of course
[01:58] <Kamion> doko: yes
[01:58] <Kamion> (e.g. Gnumeric, GnuPG)
[02:00] <Kamion> Hobbsee: not really; it's been talked about for a long time, as you say
[02:00] <Hobbsee> Kamion: okay, cool
[02:00] <mdke> GNU/buntu surely
[02:00] <Kamion> :-P
[02:00] <jsgotangco> ekkk
[02:04] <imbrandon> lol @ mdke;)
[02:06] <mjg59> pitti: Ok, looks like I should be able to munge it directly into usplash
[02:06] <mjg59> sabdfl: You ought to have high-res usplash at some point this evening
[02:07] <sabdfl> mjg59: awesome - without compromising suspend / resume?
[02:07] <mjg59> I believe so
[02:07] <sabdfl> very cool. i thought i would have to take mind-enhancing substances to ever see that :-)
[02:07] <jsgotangco> lol
[02:08] <imbrandon> lol
[02:09] <doko> Kamion: but no gtk2* and orbit2 stuff?
[02:10] <sabdfl> mjg59: how did you solve the "wake up the video card" problem?
[02:11] <thom> mjg59: also, any news on hotpluggable x60s ultra bay justice?
[02:11] <Kamion> doko: 12:53 < Kamion> gtk2-engines is already in the dapper-updates unapproved queue
[02:12] <mjg59> sabdfl: We don't use the framebuffer
[02:12] <mjg59> Just jump to vesa directly
[02:12] <mjg59> thom: Wurgh. I'll try to hit that over the weekend?
[02:12] <thom> yay :-)
[02:12] <ajmitch> mjg59: do you still want to take the blame & be marked as maintainer of xserver-xgl, or shall I change that? :)
[02:12] <mjg59> ajmitch: Heh
[02:12] <thom> my hack doesn't work anymore in edgy since /proc/acpi/ibm/dock has gone away
[02:13] <mjg59> ajmitch: If you're going to actively look after it, would you mind adopting it for now?
[02:13] <ajmitch> I can
[02:13] <mjg59> Cool
[02:13] <mjg59> Thanks for the upload
[02:13] <ajmitch> also got libcm, and possibly spiftacity
[02:13] <dholbach> create an xgl team in launchpad and subscribe it to the bugs
[02:13] <ajmitch> sounds sane
[02:13] <dholbach> i'm sure you'll get followers
[02:14] <jsgotangco> he'll be treated like a god
[02:14] <ajmitch> hah
[02:21] <janimo> which of the gnome daemons or apps listens to key presses via HAL?
[02:27] <Lure> janimo: I think gnome-settings-daemon from control-center package 
[02:28] <Lure> janimo: at least this is what I used to understand Ubuntu behaviour for KubuntuLaptopButtons...
[02:28] <mjg59> Nothing listens to the HAL events yet
[02:28] <Riddell> Lure: which reminds me, mjg59 said he could supply us with a list of supported keys
[02:28] <janimo> Lure, thanks. I know g-v-m and g-p-m are candidates as well, but was wondering if it got put somewhere common in latest gnome
[02:28] <mjg59> gnome-settings-daemon gets them straight from X
[02:29] <janimo> mjg59: so no gnome app does the equivalent of lshal -m for keys?
[02:29] <mjg59> janimo: Not via hal, no
[02:29] <Lure> true, g-s-d just does X events
[02:30] <mjg59> Should probably port that some time
[02:30] <mjg59> And also add code to let people set new keymaps
[02:30] <janimo> mjg59: so classical grab the keyboard then, thanks
[02:30] <Lure> mjg59: so using hal directly is preffered over X events?
[02:30] <mjg59> Lure: Yeah
[02:31] <Lure> mjg59: ok, will rething Kubuntu implementation then...
[02:31] <Lure> s/rething/rethink/
[02:32] <Lure> mjg59: can you supply us with the list of all supported keys as mentioned by Riddell?
[02:33] <Hobbsee> Lure: i got a few more people adding their keys to your list, btw
[02:33] <mjg59> Sure, hang on a moment
[02:33] <Lure> Hobbsee: seen that - thanks!
[02:33] <mjg59> Lure: As far as the hal ones go, just check hald/linux2/addons/keyboard.c
[02:34] <zul> heylo
[02:34] <Hobbsee> hi zul 
[02:34] <Lure> mjg59: ok, thanks - will do this evening...
[02:35] <setuid> I'm trying to figure out the magic to build the ATI driver packages for Edgy. Any hints here? 
[02:36] <setuid> The BinaryDriverHowto/ATI document didn't seem to help 
[02:37] <setuid> https://help.ubuntu.com/community/BinaryDriverHowto/ATI
[02:39] <pygi> sivang, poke
[02:58] <mdke> dholbach: ping?
[02:59] <janimo> mjg59: hmm in g-p-m 2.14.3 at least, in src/gpm-hal-monitor.c there is code for handling button pressed events from HAL.
[03:01] <mjg59> janimo: Only sleep, power and lid
[03:01] <janimo> well, that's something
[03:01] <mjg59> That's because they can come from multiple sources
[03:01] <janimo> I only need sleep for xfce anyway
[03:01] <janimo> for now that is
[03:01] <pitti> dmg: hello
[03:01] <dmg> howdy
[03:04] <Hobbsee> mdke: i think he went to lunch
[03:05] <doko> Kamion: I got a reject for ia32-libs-openoffice.org_11.1 ?
[03:05] <mdke> Hobbsee: yep thanks, he can respond when he gets back
[03:05] <Hobbsee> mdke: true
[03:33] <Kamion> doko: yes, you uploaded it twice and I rejected the first one since the second was obviously newer
[03:34] <doko> Kamion: thanks
[03:36] <ogra> mvo, if u-m pops up a conffile prompt, wouldnt it be better to show the user the full patch instead of only the filename ? 
[03:36] <ogra> *path
[03:37] <mvo> ogra: probably, yes. what conffile is it?
[03:37] <ogra> /etc/exports ...
[03:38] <ogra> i had a prompt asking me about exports so i was confused and had to look into the vte win to find out its /etc/exports
[03:39] <ogra> especially since i didnt look which packages were upgraded ...
[03:41] <seb128> nice, gdb segfault :/
[03:41] <mvo> seb128: haha, generate a bt :)
[03:42] <mvo> ogra: right, I will look at it
[03:42] <seb128> Program received signal SIGSEGV, Segmentation fault.
[03:42] <seb128> 0x0808ff32 in _initialize_thread_db ()
[03:42] <seb128> (gdb) bt
[03:42] <seb128> #0  0x0808ff32 in _initialize_thread_db ()
[03:42] <seb128> #1  0x08090309 in _initialize_thread_db ()
[03:42] <seb128> #2  0x081075b9 in normal_stop ()
[03:42] <seb128> #3  0x0807f6c9 in discard_cleanups ()
[03:42] <seb128> #4  0x081122d9 in throw_exception ()
[03:42] <seb128> #5  0x0811238c in throw_exception ()
[03:42] <seb128> #6  0x081123e2 in throw_verror ()
[03:42] <seb128> #7  0x080821ea in error ()
[03:42] <seb128> #8  0x080824ca in perror_with_name ()
[03:42] <seb128> #9  0x0808ed08 in supply_gregset ()
[03:42] <seb128> mvo: here you go :p
[03:56] <seb128> mvo: want to debug it? :)
[03:59] <seb128> doko: around?
[04:00] <doko> seb128: yes
[04:00] <seb128> doko: http://librarian.launchpad.net/3709638/buildlog_ubuntu-edgy-i386.ctypes_0.9.9.6-1_FAILEDTOBUILD.txt.gz
[04:01] <seb128> doko: does it look like something that just need a retry?
[04:01] <seb128> "pycentral: pycentral rtinstall: installed runtime python2.3 not found"
[04:02] <doko> seb128: maybe sync that from unstable. the package explicitely depends on python2.3, not python-all-dev. in edgy, we don't support 2.3 anymore.
[04:03] <seb128> doko: that's the package from Debian unstable
[04:06] <doko> seb128: then it should depend on python-all-dev
[04:06] <doko> b-depend
[04:06] <seb128> doko: "Build-Depends: python2.3-dev (>= 2.3.5-10), python2.4-dev, python-central (>= 0.4.17), debhelper (>= 5.0.37.1)"
[04:06] <seb128> doko: python2.3-dev (>= 2.3.5-10), python2.4-dev has to be remplaced by python-all-dev ?
[04:06] <doko> python-all-dev (>= 2.3.5-11)
[04:07] <seb128> ok,t hank you
[04:07] <bddebian> Morning
[04:07] <seb128> I'll open a Debian bug and fix the Ubuntu package
[04:07] <doko> seb128: right, but look in the rules file, if python2.3 is called explicitely ...
[04:07] <StevenK> Both seem to ignore subdirectories underneath /usr/share/py{central,thon-support}.
[04:08] <seb128> doko: 
[04:09] <StevenK> Which means /usr/share/pycentral/linda/__init__.py gets linked as __init__.py, and then I wonder why import linda fails.
[04:09] <seb128> build-python%:
[04:09] <seb128> 	dh_testdir
[04:09] <seb128> 	python$* setup.py build
[04:09] <seb128> and they do that for "PYVERS	:= $(shell pyversions -vr debian/control)"
[04:09] <seb128> so it should be fine
[04:09] <doko> StevenK: it must be /usr/share/pycentral/linda/linda/__init__.py
[04:09] <bddebian> Aye, you need debian/pycompat
[04:09] <doko> do you move things around yourself?
[04:09] <StevenK> doko: Ewwww
[04:10] <seb128> hum, I should read the new policy
[04:10] <seb128> for now I'll just drop the python2.3 Build-Depends for the Ubuntu package
[04:11] <StevenK> I was ignoring until someone filed a bug on Linda.
[04:11] <bddebian> http://wiki.debian.org/DebianPythonFAQ
[04:11] <bddebian> http://wiki.debian.org/DebianPython/NewPolicy
[04:11] <doko> seb128: looks fine. and something special about ctypes (because it's part of python2.5), the package should not depend on python (<< 2.5) (but you would have to remove that yourself at the moemnt
[04:11] <seb128> bddebian: I know where they are, I've just been lazy trying to understand it and to decide what tool to use
[04:11] <imbrandon> nice, fink is on LP now /me dances
[04:11] <bddebian> Ah
[04:12] <doko> bddebian: no, just the latter
[04:23] <Riddell> pitti: it seems like KDE HAL dude doesn't want to stop using the HAL mounting scripts
[04:23] <Riddell> pitti: since they implement functionality that would otherwise have to be duplicated in KDE
[04:23] <Riddell> pitti: and it's hard to argue against using HAL since it's ment to be where all the problems are taken care of
[04:23] <pitti> Riddell: why duplicated? the scripts do exactly the same as pmount-hal
[04:24] <Riddell> pitti: in this case it was creating nice names in /media
[04:24] <pitti> Riddell: ok
[04:24] <pitti> Riddell: well, then we need to sanitize the backend scripts
[04:30] <Riddell> pitti: could we not just make the scripts run pmount?
[04:31] <pitti> Riddell: maybe we can cowboy it, but the scripts are run as root, not as the target user
[04:32] <Riddell> right
[05:04] <dholbach> mdke: pong
[05:05] <mdke> dholbach: I've made an ubuntu-docs package for edgy, it's at https://docteam.ubuntu.com/repos/trunk if you fancy uploading
[05:05] <mdke> i hope it works :)
[05:05] <dholbach> ahhhh nice
[05:06] <mdke> I've tested it on dapper, but not edgy
[05:07] <dholbach> i'll let you know - checking out
[05:15] <viper550> Hello
[05:16] <seb128> hi viper550
[05:16] <dholbach> mdke: it's building - i made some tiny changes to it - will send you the diff
[05:16] <dholbach> (after it built)
[05:17] <mdke> dholbach: thanks
[05:18] <dholbach> anytime
[05:25] <mjg59> Wow. Are the buildds busier these days?
[05:25] <mjg59> I had got far too used to uploading stuff and it hitting the archive half an hour later
[05:26] <mjg59> pitti: I've removed the need for including svgalib
[05:28] <zul> mjg59: i could be one to blame for the buildds being busier :)
[05:28] <mjg59> zul: Oh, they're doing a kernel?
[05:28] <bddebian> I'm sure all the sync requests don't help either :-)
[05:29] <kbyrd> zul: you have a chance to look at that email I sent about vmware-player-kernel?
[05:29] <zul> mjg59: yesterday i think and the new xen crack probably doesnt help
[05:29] <zul> kbyrd: i will tonight, i been busy with real life stuff
[05:30] <zul> i will most difnently upload it during my lunch break
[05:34] <kbyrd> zul: "real life?" what is this thing?
[05:34] <zul> kbyrd: as in personal family matter
[05:35] <kbyrd> zul: I was kidding. Of course I understand real life, many of us don't seem to make enough time for it.
[05:48] <dholbach> mdke: Installed-Size: [-32468-]  {+2120+}
[05:48] <doko> Kamion: ia32-libs-gtk is the last one for dapper-updates
[05:51] <dholbach> mdke: and the source package .tar.gz is about twice as big - anything we can add to the "remove it" list?
[05:53] <mdke> dholbach: don't think so, the package is bigger than the dapper package?
[05:53] <dholbach> mdke: the source tarball, the package is WAY smaller
[05:54] <dholbach> -rw-r--r-- 1 daniel daniel 5999074 2006-05-29 15:09 ubuntu-docs_6.06.1_all.deb
[05:54] <dholbach> -rw-r--r-- 1 daniel daniel  313432 2006-08-02 17:19 /var/cache/pbuilder/result/ubuntu-docs_6.08.1_all.deb
[05:54] <G0SUB> nags: I don't see hno here
[05:54] <nags> G0SUB: heno ?
[05:54] <dholbach> -rw-r--r-- 1 daniel daniel  6728888 2006-05-29 14:08 ubuntu-docs_6.06.1.tar.gz
[05:54] <dholbach> -rw-r--r-- 1 daniel daniel 15653321 2006-08-02 17:15 ubuntu-docs_6.08.1.tar.gz
[05:54] <G0SUB> heno: ping
[05:54] <G0SUB> nags: ah
[05:54] <G0SUB> dholbach: hello :)
[05:54] <nags> G0SUB: :D
[05:54] <dholbach> hello G0SUB
[05:54] <heno> nags, G0SUB: pong
[05:55] <mdke> dholbach: ok, a few things.
[05:55] <nags> hi heno 
[05:55] <G0SUB> heno, dholbach: meet nags, he is the lead developer of Linux Desktop Testing Project
[05:55] <mdke> dholbach: shall I add them to the repo or do you want me to tell you them?
[05:55] <G0SUB> ldtp.freedesktop.org
[05:55] <nags> heno: I sent you a mail few days back, cc G0SUB 
[05:55] <nags> hi dholbach :)
[05:55] <dholbach> hi nags! :)
[05:55] <Kamion> doko: ok
[05:56] <dholbach> mdke: you can tell me in a query and i'll add them and send it to you in a diff
[05:56] <mdke> ok
[05:56] <heno> nags: looks cool
[05:56] <nags> dholbach / heno : Few info about LDTP...
[05:56] <nags> LDTP is used by Sun China team in their solaris platform
[05:57] <nags> also by Palm Source in their embedded hardware based on GTK+ application
[05:57] <nags> Recently LDTP getting integrated with Jhbuild and GNOME Tinderbox
[05:57] <doko> dholbach, seb128: totem-xine is currently uninstallable in dapper-updates (amd64)
[05:58] <nags> http://people.freedesktop.org/~prashmohan/jhbuild-screencast-low.avi
[05:58] <dholbach> doko: what does apt-get say?
[05:58] <doko> dholbach: I'm updating OOo first ...
[05:58] <dholbach> ok
[05:58] <nags> http://www.0d.be/2006/07/25/integrating-ldtp-into-jhbuild/
[05:58] <nags> http://tieguy.org/blog/2006/07/26/little-bits-of-awesomeness/
[05:59] <nags> also we have automation scripts for Evolution and Gedit
[06:00] <heno> nags: have you spoken with sfllaw, our testing guru?
[06:01] <nags> heno: no, let me ping him
[06:01] <sfllaw> Hi.
[06:01] <nags> sfllaw: Hi
[06:01] <nags> sfllaw: kindly go through my above messages :)
[06:02] <nags> heno: Thanks, guiding me :)
[06:02] <sfllaw> That's pretty neat.
[06:02] <sfllaw> cr3 has been looking into Autotest as of late.
[06:03] <sfllaw> Using the accessibility libraries to do automatic testing is an interesting idea.
[06:03] <nags> sfllaw: ya :)
[06:03] <sfllaw> You'll certainly find out whenever the accessibility stuff breaks!
[06:04] <nags> sfllaw: yes you are right
[06:04] <nags> sfllaw: we have filed some important bugs in bgo
[06:04] <nags> sfllaw: we would like to collaborate with Ubuntu team :)
[06:05] <sfllaw> That would be excellent!
[06:05] <nags> sfllaw: Kindly guide me, how to proceed in this regard...
[06:05] <sfllaw> Let me get you in touch with cr3 (Marc) who is doing lots of this automated testing stuff.
[06:05] <nags> sfllaw: okay
[06:06] <nags> sfllaw: Sure, thanks :)
[06:06] <sfllaw> Uhm.  He's out to lunch.
[06:06] <sfllaw> Speaking of which, I should be doing that too.
[06:06] <sfllaw> :)
[06:06] <sfllaw> Will you be online for a while?
[06:06] <nags> sfllaw: sure :)
[06:06] <sfllaw> If not, e-mail marc.tardif@ubuntu.com
[06:06] <sfllaw> Ah, OK.
[06:06] <nags> sfllaw: I will wait :)
[06:07] <sfllaw> I've sent him a message.
[06:07] <sfllaw> He should join #ubuntu-devel when he gets back.
[06:07] <dholbach> which reminds me, i wanted to update dogtail again
[06:07] <sfllaw> Then we can talk.
[06:07] <sfllaw> Meanwhile, I have parcels to retrieve and groceries to buy.
[06:07] <nags> sfllaw: its just 9:25 PM here, I will go to sleep after 11:30 PM
[06:07] <sfllaw> Ah.
[06:07] <sfllaw> 12:07 here.
[06:07] <nags> sfllaw: sure, will wait...
[06:07] <nags> sfllaw: okay
[06:23] <dholbach> can somebody of the buildd admins tell me why the totem 1.4.3-0ubuntu1 (dapper-updates) builds on sparc, amd64, powerpc, hppa broke because of libnautilus-extension-dev not being installable?
[06:23] <Lathiat> is libnautilus-extension-dev installable on hppa?
[06:24] <dholbach> doko: i think that's what you meant. ^
[06:24] <dholbach> Lathiat: on amd64: http://librarian.launchpad.net/3718725/buildlog_ubuntu-dapper-amd64.totem_1.4.3-0ubuntu1_FAILEDTOBUILD.txt.gz
[06:24] <Lathiat> dholbach: then what you said was confusing
[06:24] <Lathiat> ;p
[06:24] <dholbach> Lathiat: it's the same problem in all the cases - for some weird reason, it just worked on ia64 and i386
[06:25] <dholbach> Lathiat: really?
[06:25] <Lathiat> oh i see
[06:25] <Lathiat> its ambiguous if you sortof skim read it
[06:25] <Lathiat> nvm :)
[06:25] <dholbach> ok
[06:25] <dholbach> :-)
[06:26] <Lathiat> i was reading "builds" as the act of building not the sortof "objects" of building
[06:26] <Lathiat> anyway.. ;)
[06:26] <dholbach> similar breakage of gnome-panel 2.14.3-0ubuntu1 on sparc
[06:28] <bddebian> Sparc?  Who cares about Sparc? ;-P
[06:30] <zul> sparc users and fabbione for one..
[06:31] <dholbach> the problem is, that it's dapper stable, not wonky edgy
[06:41] <pitti> Riddell: can you please bzr the latest hal version?
[06:41] <pitti> Riddell: I'll try to sanitize the scripts in the near future
[06:42] <Riddell> pitti: oh yes, forgot about that
[06:46] <infinity> dholbach: Just looks like the uploads were poorly-timed.  A retry of all of them seems to be working fine.
[06:46] <dholbach> THANKS :)
[06:53] <LaserJock> hmm, good idea. Maybe we just need to be hugging the archive admins every time a build goes through :-)
[06:54] <bddebian> :-)
[07:01] <nags> cr3: Hi
[07:01] <cr3> nags: hi
[07:02] <cr3> sfllaw: did I miss everything?
[07:02] <nags> cr3: was chatting with sfllaw 
[07:02] <nags> cr3: and I was telling him about LDTP and also would like to collaborate with Ubuntu team...
[07:03] <nags> brb
[07:07] <cr3> nags: I am somewhat familiar with LDTP, only enough to have tried it to test firefox and gedit. I like how it works with accessibility to test applications programmatically, very cool project.
[07:07] <infinity> dholbach: All better now.  Thanks for the heads-up.  (That was breaking the livefs builds on powerpc too, I just noticed, so yay for fixing that)
[07:08] <dholbach> it's the HUG DAY
[07:08] <nags> cr3: Thanks :)
[07:08] <infinity> Laser_away: I'm not sure I could handle that many hugs.
[07:08] <infinity> Laser_away: And, really, I only have eyes for dholbach and mvo.
[07:09] <nags> cr3: Casanova did Tinderbox integration as part of GNOME + Google SoC. He has also completed basic sanity tests for Evolution
[07:09] <dholbach> hihi :)
[07:09] <cr3> nags: nice!
[07:11] <nags> Casanova: ping
[07:38] <seb128> doko, dholbach: totem ftbfsed on some archs because of instability of nautilus (eel, nautilus have been updated to dapper-updates too and need to build first)
[07:39] <dholbach> seb128: infinity gave back and we're (soon) all good again.
[07:40] <doko> ok
[07:40] <dholbach> in the meantime we have to live with bugs like bug 54957
[07:40] <Ubugtu> Malone bug 54957 in totem "update totem (1.4.3-0ubuntu1) has broken totem-xine-firefox-plugin" [Medium,Needs info]  http://launchpad.net/bugs/54957
[07:40] <Chipzz> seb128: how can totem ftbfsed because of instability of a GUI program?
[07:40] <seb128> dholbach: ok, looks like I'm of no use nowadays around :p
[07:40] <LaserJock> dholbach: and perhaps emails on -devel
[07:40] <Chipzz> how is a GUI program involved in building other programs?
[07:40] <thom> Chipzz: libnautilus
[07:40] <seb128> Chipzz: nautilus has a libnautilus-extension
[07:41] <Chipzz> yes, but you should *link* to that, not run it...
[07:41] <doko> Kamion: please process ia32-libs-gtk for dapper-updates. sorry, I'm nagging, so I can announce the OOo 2.0.3 packages for testing ...
[07:41] <dholbach> seb128: what do you mean?
[07:41] <seb128> Chipzz: I was speaking to people who understand what I say without have to type a 15 chars lib name long
[07:42] <seb128> dholbach: every time sombody ask me I question you have replied before I read my IRC :p
[07:42] <seb128> s/have/having
[07:42] <Chipzz> seb128: are you calling me stupid?
[07:42] <Chipzz> seb128: I have been building gnome from cvs since pre 2.0
[07:43] <seb128> Chipzz: "<Chipzz> how is a GUI program involved in building other programs?", obviously you didn't what I was saying
[07:43] <Chipzz> I *know* what libnautilus-extension is
[07:43] <Chipzz> seb128: that's because nautilus doesn't run during the build of totem
[07:44] <Chipzz> seb128: and because you *link* against libnautilus-extension, but you do not actually *run* the resulting program in the build
[07:44] <thom> Chipzz: you're aware that library api/abi can be unstable, right?
[07:44] <seb128> Chipzz: as I said, I wrote nautilus because it's short than libnautilus-extension1 and people I was talking too understand what I mean by it
[07:44] <mjg59> Let's try that upload one more time
[07:45] <Chipzz> seb128: what you said was wrong; you should have said *api* instability
[07:45] <seb128> Chipzz: k, so make it clear for you "libnautilus-extension-dev needs to be installable to build totem because totem uses it for the audio,video properties page"
[07:45] <Kamion> seb128: nautilus is still in unapproved; do I need to process it urgently?
[07:45] <Chipzz> and when I ask clarification because *you* said something *wrong*, I prefer not to be called stupid
[07:45] <Chipzz> thank you very much
[07:45] <Chipzz> sjeesh
[07:45] <seb128> Kamion: no, it should run fine with the eel2 which has been accepted
[07:46] <seb128> Kamion: I've not looked into details yet, just came back and dholbach told it's alright now, I think it was just eel which built on i386 but not amd64 yet
[07:46] <seb128> Chipzz: again, I was speaking to people who understand what I mean
[07:47] <Kamion> doko: libpixman1 was removed (though no changelog); was it moved to another ia32-libs-* package? if so, does that package need a Replaces?
[07:48] <doko> Kamion: no, it vanished to or came from universe. it shouldn't have been in the package in the first place.
[07:49] <Kamion> doko: fair enough - accepted
[07:49] <doko> the edgy package does have the changelog; forgot it here.
[07:49] <Chipzz> seb128: I normally DO understand; but what you said did not make much sense; ergo I ask for clarification
[07:50] <dholbach> rodarvus, fabbione, infinity: bug 54648 and bug 52657 would require your genius and X knowledge :-)
[07:50] <Ubugtu> Malone bug 54648 in glade "glade-2 won't start, gives X BadValue error (edgy)" [Medium,Needs info]  http://launchpad.net/bugs/54648
[07:50] <Ubugtu> Malone bug 52657 in evolution "X Windows error when running 2.7.4" [Medium,Needs info]  http://launchpad.net/bugs/52657
[07:50] <doko> Kamion: what the best approach to compare package sizes between dapper-proposed and dapper-updates (if we decide to include it)
[07:50] <seb128> Chipzz: alright, no problem :)
[07:56] <rodarvus> dholbach, I've seen them
[07:56] <rodarvus> both bugs look quite strange :)
[07:56] <doko> Kamion, Keybuk, mdz: approval of ia32-libs-scim in NEW for edgy would be nice as well for OOo testing
[08:01] <pitti> does anyone feel responsible for the vmware-player-kernel-2.6.15 dapper-security upload?
[08:02] <pitti> Changed-By: VMware Build Team <vmware-build@vmware.com>
[08:03] <mvo> pitti: I can do this
[08:03] <seb128> see, mvo is the master
[08:03] <pitti> mvo: this team is not really a team in launchpad
[08:04] <pitti> mvo: do these guys really have upload privs to jackass, or did you sponsor this?
[08:04] <mvo> pitti: I just sponsor it
[08:04] <pitti> ok
[08:04] <pitti> mvo: it was a regression from the last kernel security update?
[08:05] <zul> pitti: yes me
[08:05] <zul> pitti: i uploaded it
[08:05] <pitti> ok
[08:06] <zul> it contains a fix for people who want to use module-assitant
[08:08] <mvo> zul: did you got it from vmware? is this the fix for #49924,
[08:08] <zul> mvo: yes i got it from vmware
[08:09] <mvo> zul: ah, nice! so this is there version -9?
[08:09] <zul> i believe so, i was talking to kbyrd about it
[08:10] <kbyrd> yes, it is.
[08:10] <mvo> nice, thanks zul, kbyrd
[08:10] <zul> no probs
[08:11] <kbyrd> Should I not put us in the changelog since we don't upload?
[08:12] <kbyrd> If someone could verify (besides me) and close that bug, I'd appreciate it.
[08:16] <rubikcube> dunno if I'm right here, but is there a reason why in the LaTeX docs lshort is delivered only as pdf, not as dvi?
[08:17] <pitti> rubikcube: there's not much reason to ship the documentation in ten different formats IMHO
[08:18] <pitti> PDF should be fine as a default, and since the source is available, you can easily generate other formats if you wish
[08:18] <rubikcube> yes, but I thought that dvi should be the canonical format
[08:26] <rubikcube> ok, I see, the dvi version seems to have font problems *hmpf*  
[08:28] <Riddell> how do I setup a locale in a chroot?
[08:29] <Riddell> dpkg-reconfigure locales  doesn't seem to do very much
[08:29] <Kamion> Riddell: locale-gen <locale identifier>
[08:29] <bddebian> locale-gen..
[08:29] <bddebian> Oh whoops
[08:31] <bddebian> Shit I can't tell where I'm at on the merges list anymore.. :-(
[08:32] <Riddell> thanks Kamion 
[08:42] <Kamion> doko: the copyright file for ia32-libs-scim is completely wrong; could you correct it?
[08:44] <doko> Kamion: ouch ... yes, copied from another package ...
[08:44] <doko> we should generate the copyright file ...
[08:44] <rodarvus> who usually sends the ubuntu-core-devel meeting announcements?
[08:45] <rodarvus> next one is 12 hours from now and there is no sign of it on ubuntu-devel-announce@ yet
[08:48] <ogra_thin> rodarvus, sfllaw iirc
[08:50] <sfllaw> I do.
[08:50] <sfllaw> I just got back from the post office.
[08:50] <sfllaw> And it's about time to.
[08:51] <rodarvus> nice, thanks!
[08:54] <bluefoxicy> so 1) wtf bootloader is on the Dapper CDs; 2) Why doesn't Grub look that freaking leet
[08:54] <Kamion> 1) syslinux+gfxboot 2) because we haven't ported the grub/gfxboot patches from suse yet
[08:55] <Kamion> and would require some care not to conflict with quieten-grub anyway
[09:00] <bluefoxicy> Kamion:  ah.
[09:11] <ogra> Kamion, if you dont mind, i just uploaded a new willowng to the NEW queue, would you take a look ?
[09:31] <ogra_thin> hmm, why can i exec update-manager as unprivileged user ? and why is it even in the menu ?
[09:33] <rubikcube> ogra_thin: can you also actually update something?
[09:34] <ogra_thin> i'm up to date, but i can hit refresh and it works ...
[09:34] <ogra_thin> it doesnt from the commandline though
[09:35] <ogra_thin> but well, i'll wait until mvo returns
[09:39] <msikma> Hey guys. I'm a participant of the Ubuntu Artwork team and would like to edit a metacity theme to propose changes to the default Human style for Edgy. But I've never done it before. Anybody know any good documentation on it?
[09:40] <dholbach> msikma: you could check some of the existing themes
[09:40] <dholbach> about documentation, i don't know, sorry
[09:40] <ogra_thin> i think havoc pennington had a nice howto, but i dont know how recent it is
[09:40] <msikma> Yeah, I downloaded a nice theme called Chiro which I would like to fool around with. It's just a window border. It appears to be an XML file, but it's still not quite straightforward.
[09:41] <ogra_thin> http://developer.gnome.org/doc/tutorials/metacity/metacity-themes.html
[09:41] <msikma> Thanks!
[09:42] <ogra_thin> but beware that might be very old
[09:42] <mikearthur> 2.6.17-5.16 = kernel source 2.6.17.16 or 2.6.17.5?
[09:42] <msikma> This is _very_ nice. Even if it's old, it will come in handy.
[09:42] <msikma> Ah, copyright 2002.
[09:44] <gnomefreak> mikearthur: first you asked in 3 channels each channel is the wrong place to ask. 2nd this is not a support channel. Please join #ubuntu+1 and ask
[09:44] <mikearthur> gnomefreak: sorry, thanks
[09:53] <dholbach> have a nice evening
[09:54] <zul> c ya dholbach 
[09:55] <dholbach> bye zul
[10:06] <pitti> Kamion: ping
[10:15] <Kamion> ogra: willowng done
[10:15] <Kamion> pitti: yes?
[10:16] <pitti> Kamion: the new langpacks for dapper are finally in the archive
[10:16] <pitti> Kamion: and I did a size comparison chart
[10:16] <pitti> http://people.ubuntu.com/~pitti/tmp/langpacksize-dapper.txt <= original CDs
[10:16] <pitti> http://people.ubuntu.com/~pitti/tmp/langpacksize-dapper-newbase-20060801.txt <= current langpacks
[10:17] <pitti> Kamion: so, luckily they didn't grow too much
[10:17] <Kamion> about 3MB up on the set we use for the CDs :-/
[10:17] <pitti> Kamion: the top 11 languages grew by 2.5 MB
[10:17] <pitti> yep, we probably have to drop one
[10:17] <Kamion> yeah, silbs didn't seem happy with that possibility
[10:17] <mjg59> Could people test the latest usplash?
[10:17] <pitti> Kamion: however, it is difficult to know in advance since I don't know the size diff of the other packages
[10:18] <Kamion> I did a build this morning, IIRC after I accepted those langpacks
[10:18] <pitti> Kamion: will we roll a test CD before the official one?
[10:18] <pitti> Kamion: oh, the packs didn't enter the archive until some hours ago
[10:18] <pitti> building them took some time
[10:18] <pitti> Kamion: test CD so that we can precisely calculate how many to drop
[10:19] <crimsun> mjg59: as in suspend-to-{disk,ram} -> resume? I can try in a bit.
[10:19] <mjg59> crimsun: Well, whether it works at all to begin with :)
[10:19] <Kamion> hmm, no, I caught it in the middle
[10:20] <Kamion> pitti: kicking off livefs builds now
[10:22] <pitti> Kamion: ok, then I'll adjust the seeds accordingly tomorrow morning?
[10:22] <Kamion> mdz: could I get a judgement call from you? we may have to drop German language packs from the powerpc desktop CD for the dapper point release
[10:23] <Kamion> mdz: silbs didn't seem massively happy about it, but I can't think what else to do
[10:23] <mdz> Kamion: what grew?
[10:23] <pitti> mdz: mainly the langpacks themselves
[10:23] <pitti> by 2.5 MB for en to de (top 11)
[10:23] <mdz> ah, hmm
[10:23] <Kamion> I already dropped xh
[10:23] <Kamion> but that wasn't all that big
[10:23] <mdz> Kamion: it doesn't bother me if we need to drop it
[10:23] <mdz> only powerpc, right?
[10:24] <pitti> not that we had much choice :)
[10:24] <Kamion> i386 can be rescued easily (it has lots of langpacks); xh de are next in line for amd64
[10:24] <Kamion> mdz: I'm not sure
[10:24] <Kamion> mdz: apparently powerpc had problems burning for some people even in dapper; it was below what I understood the real size limit to be, but above 700MB, and I've had reports of some software/media (unsure which) not liking that
[10:24] <mjg59> mdz: I stuffed the necessary svgalib stuff in usplash, so we can drop the main inclusion
[10:25] <pitti> mjg59: *hug*
[10:25] <mdz> mjg59: I saw, thank you
[10:25] <mdz> mjg59: did you and/or Keybuk sort out the device node issue?
[10:25] <Kamion> but if you check http://cdimage.ubuntu.com/daily-live/20060802/, they're all a bit over
[10:25] <mjg59> mdz: Oh, good point
[10:25] <mjg59> mdz: No, I had a locally hacked script here
[10:25] <mjg59> I'll fix that for the next upload
[10:25] <Kamion> that's with old l-p-*-base and new l-p-* though due to an accident of timing, which is pretty much pessimal
[10:25] <pitti> Kamion: oh, btw, will we do new alternate images, too?
[10:26] <Kamion> pitti: yes, already started building those
[10:26] <Kamion> http://cdimage.ubuntu.com/daily/20060802/
[10:26] <Kamion> no size problems there for Ubuntu at least
[10:26] <pitti> they look good
[10:26] <pitti> Kamion: ok, I'll look at the latest ones tomorrow morning and adjust
[10:27] <Kamion> I might need to try to engineer a different build directory for dapper - it would really be preferable to keep building edgy at the moment
[10:27] <Kamion> anyway, I need to go offline for a short while to test why my phone line is non-functional; if I don't come back, then it's more hosed than I'm hoping ...
[10:27] <Kamion> oh, whoops, can't do that while the livefses are building, so postponed ...
[10:28] <pitti> Kamion: no screen? :)
[10:32] <lamont> Kamion: will the new dapper ppc iso be one that I can burn onto 700MB media using dapper?
[10:40] <gnomefreak> who updated the usplash?
[10:41] <HiddenWolf> that'd be mjg59
[10:42] <gnomefreak> it died
[10:43] <Kamion> lamont: that's the plan ...
[10:43] <Kamion> pitti: more relevantly I didn't ssh somewhere ex-ADSL before kicking off the six subsidiary ssh connections
[10:51] <Kamion> bddebian: FWIW you don't need to mention that Ubuntu changes can be dropped if the current Ubuntu version doesn't contain "ubuntu"; the sync script ignores buildN
[10:52] <Kamion> Ubuntu changes <=> version contains "ubuntu"
[10:52] <bddebian> Kamion: OK, sorry
[10:53] <Kamion> no need to be sorry, as it doesn't cause us extra work if you do say that; I just wanted to save you the effort of saying it in future :-)
[10:54] <bddebian> Well I actually ran across one where someone changed a build dep but still called it buildX :-(
[10:55] <Kamion> bddebian: lovely
[10:55] <Kamion> that can be ok if you're absolutely certain that it can be synced next time, I guess, but it's not very good form
[10:55] <cjb> Hi.  Is there any chance of getting -mtune=generic support in edgy's gcc?
[10:55] <bddebian> Aye
[10:55] <icecrash> hi
[10:56] <bddebian> Hello icecrash
[10:56] <icecrash> i'm currently working on a customized server image
[10:56] <icecrash> having problems with cdimage
[10:56] <icecrash> anyone with deeper experience in that?
[10:57] <icecrash> two problems exists
[10:58] <icecrash> during the anonymous ftp sync, the rsync process will not sync the dists part of the ubuntu archive, so the debian-installer part that follows fails
[10:59] <icecrash> do I have a chance to work with this suite with a partly mirror only containing i386 debs?
[11:00] <Kamion> icecrash: what do you mean "will not sync"?
[11:00] <Kamion> it syncs the entire archive in the first pass
[11:00] <icecrash> so I thought
[11:00] <icecrash> I setupped a partly mirror with 
[11:01] <Kamion> it may well make sense to do it with debmirror or something plus a few custom rsyncs - anonftpsync in there is just what we use inside the datacentre where bandwidth isn't a huge issue
[11:01] <Kamion> debmirror and manually sync in dists/blah/main/installer-*
[11:02] <icecrash> debmirror ${LOCAL_ARCHIVE} --progress --host=${REMOTE_SERVER}  \
[11:02] <icecrash>  --root=${REMOTE_ROOT} --dist=${DISTS} --section=${SECTIONS} \
[11:02] <icecrash> --method=rsync --arch=${ARCHES} -v --nomd5sums
[11:03] <icecrash> syncing against fr.archive.ubuntu.com
[11:03] <Kamion> you might need a few --ignore options as well - debian-cd will probably want you to rsync in doc, indices, tools
[11:03] <Kamion> been a while (> 2 years) since I did this using my local mirror though :-)
[11:04] <icecrash> ok, but I have no probs to sync more than I need
[11:04] <icecrash> :)
[11:04] <Kamion> right, but it's nice not to clobber the datacentre with excess load during a week where we're pushing out a lot of dapper updates
[11:04] <icecrash> syncing for dists=dapper,dapper-updates,dapper-security
[11:04] <Kamion> though you could always pull from a mirror
[11:04] <Kamion> (and probably should, if possible)
[11:04] <icecrash> ok
[11:05] <pygi> anyone could poke for me do we get shared libs with libburn package?
[11:10] <mjg59> So, what should I do about resolution setting in the NEW! IMPROVED! usplash?
[11:10] <Chipzz> new, improved, AND invisible!
[11:11] <Chipzz> s/invisible/broken/ :P
[11:11] <mjg59> Well, currently
[11:11] <mjg59> But that's not the point
[11:11] <Chipzz> so what /is/ the point? ;)
[11:11] <mjg59> < mjg59> So, what should I do about resolution setting in the NEW!  IMPROVED! usplash?
[11:12] <gnomefreak> it looked small on shutdown and not there on boot
[11:12] <mc44> keep it at 640x400 just for kicks
[11:12] <Chipzz> well if I'ld know what you meant... ;)
[11:12] <Chipzz> gnomefreak: exactly ;)
[11:12] <mjg59> The resolutions it can use on x86 and amd64 are limited to the ones in the vesa bios
[11:12] <pygi> gnomefreak, any chance you  could look for me? my upstream build system fails to build shared libs and seems like debian packages does
[11:13] <pygi> bleh =P
[11:13] <mjg59> So should we (a) stick to something fairly safe like 800x600, or (b) grab the closest to the X configuration?
[11:13] <pygi> mjg59, a :)
[11:13] <gnomefreak> b
[11:14] <^ohoel> I see there's a new sled-menu-ish project going on the forums
[11:14] <gnomefreak> b = safest way that way as long as they have X they should beable to view it
[11:14] <gnomefreak> pygi: what did you want me to do?
[11:14] <bluefoxicy> mjg59:  stick to something 800x600 and make it use a million colors :D
[11:14] <pygi> gnomefreak, check if we get shared libs with libburn package :)
[11:14] <mjg59> Colour depth is an uninteresting problem
[11:15] <bluefoxicy> mjg59:  actually I've been admiring Gentoo's 2006.0 install CD.  It switches into a graphical boot-up with icons like MacOS used to show
[11:15] <bluefoxicy> and the graphic is ... well, eye candy :P
[11:15] <mjg59> This is also an uninteresting issue right now
[11:15] <bluefoxicy> MASSIVE eye candy
[11:16] <mjg59> I provide mechanism, not policy
[11:16] <bluefoxicy> ah
[11:16] <mc44> mjg59: cant you just steal the resolution from whatever is in xorg conf?
[11:16] <bluefoxicy> why not provide mechanism for (b) with a mechanism to override
[11:16] <gnomefreak> you get nothing with it pygi 
[11:16] <mjg59> mc44: I can 
[11:16] <Chipzz> but why use X? X can take several seconds to start...
[11:16] <mjg59> Chipzz: What?
[11:16] <pygi> gnomefreak, bleh, oki :P
[11:17] <crimsun> mjg59: I think it's early enough that stealing the resolution is worth trying.
[11:17] <Chipzz> mjg59: you read what I said
[11:17] <mjg59> Chipzz: We're not using X
[11:17] <Chipzz> mjg59: I thought that was under consideration?
[11:17] <mjg59> Chipzz: No
[11:17] <Chipzz> apologies then
[11:18] <Amaranth> mjg59: I would think using a resolution from xorg.conf would be good
[11:18] <bluefoxicy> heh, I suggested on -devel@ using Kdrive's VESA server for graphical boot-up
[11:18] <Chipzz> mjg59: btw, what you said about vesa is incorrect btw
[11:18] <Amaranth> mjg59: you know the monitor can show those resolutions
[11:18] <mjg59> Chipzz: Which bit?
[11:18] <bluefoxicy> and someone was like" If I get X I'm drawing a log-in screen"
[11:18] <dabear> hi, just on question, does edgy's metacity have composite enabled?
[11:18] <Amaranth> dabear: no, it's buggy
[11:18] <Chipzz> svgalib can use modelines in the same format as X uses them, to get arbitrary resolutions
[11:18] <mjg59> Chipzz: Not through vesa
[11:19] <mjg59> Or, at least, not on most vesa systems
[11:19] <mjg59> Very little implements GTF
[11:19] <Chipzz> mjg59: vesa is also a mostly a non-issue
[11:19] <mjg59> Chipzz: WTF are you talking about?
[11:19] <Chipzz> what you are referring to is actually vesa 2.0
[11:19] <mjg59> Yes
[11:19] <gnomefreak> vesa is the most widely used
[11:19] <Chipzz> vesa 1.2 (which a lot of older cards use) is not at all usable
[11:19] <mjg59> Which is pretty much all that's widely implemented
[11:20] <mjg59> Chipzz: Practically any piece of hardware that can run Ubuntu has VBE 2.0
[11:20] <mjg59> (or greater)
[11:20] <Chipzz> mjg59: all 1MB and 2MB trident and trio etc cards implement vesa 1.2
[11:20] <mjg59> I'm utterly failing to care
[11:20] <mjg59> Especially since svgalib can cope with segmented framebuffers /anyway/
[11:20] <Chipzz> and on the cards that do support vesa, you have framebuffer drivers too (so can use directfb or such)
[11:21] <mjg59> Chipzz: No, we /don't/
[11:21] <mjg59> Because then suspend/resume stops working
[11:21] <Chipzz> ugh :/
[11:22] <mjg59> Since almost none of them know how to reprogram the framebuffer from scratch
[11:24] <mjg59> So doing this without a framebuffer is massively preferable right now
[11:26] <mc44> mjg59: will you need to have lots of artwork at different resolutions if you nick the value from X?
[11:26] <dabear> is there any written standard on what has to be done on a product to increment the main/second version number?
[11:27] <mjg59> mc44: We'll see
[11:46] <doko> Kamion: uploaded ia32-libs-scim_2 again with the updated copyright. seems, that *nobody* did update *any* of the ia32-libs* packages that after the initial creation of the package :-/
[11:47] <Kamion> ok, thanks
[11:47] <Kamion> will look tonight
[12:03] <mdeslaur> +