[12:08] <zul> need to get dinner bbl
[12:10] <mdz> zul: backing out your patch and building with gcc-4.0 still gives me a broken grub (this one with weird corruption of the menu commands)
[12:11] <mdz> oddly enough, I can boot fine with this one if I use the grub command line rather than the menu
[12:11] <jdub> mdz: current edgy grub is b0rk, or is this pre-upload testing?
[12:11] <mdz> jdub: the former
[12:12] <zul> have you tried removing the diskless boot stuff?
[12:12] <jdub> mdz: thanks 8)
[12:17] <mdz> zul: not yet
[12:21] <mdz> zul: I'm trying dapper grub + your quiet patch with gcc-4.0
[12:21] <mdz> zul: ok, that works
[12:21] <mdz> so your patch does not appear to be at fault
[12:22] <zul> well thats a good thing ;)
[12:22] <mdz> zul: did you test this whole package before uploading it?
[12:22] <zul> yes i did...i didnt have the same problems
[12:22] <mdz> that is, did you test your patch with the merged grub
[12:22] <zul> yes
[12:22] <mdz> but you can confirm the problem now, yes
[12:23] <mdz> ?
[12:23] <zul> correct...but i didnt run update-grub before i ran grub-install
[12:23] <mdz> I didn't try 0.97-11ubuntu1
[12:24] <mdz> zul: surely that shouldn't matter
[12:24] <mdz> it breaks in the same way regardless of whether the quiet option is used or not
[12:25] <zul> hold on a  sec..
[12:26] <zul> i just want to try something
[12:27] <mdz> I'm trying reverting cvs-sync
[12:27] <mdz> then I'll try disabling netboot
[12:27] <mdz> one of those should be at fault
[12:33] <zul> mdz: i have modified quiet.diff so the GNU/GRUB is in the menu reverted the diskless client and i was able to boot
[12:34] <zul> and i reverted the change from the update-grub as well
[12:35] <mdz> zul: looks like it was the netboot stuff
[12:35] <zul> correct
[12:35] <zul> ill revert the netboot stuff after i come back from dinner is that ok?
[12:36] <mdz> zul: now we just need to do something about the fact that update-grub will break the boot
[12:36] <mdz> zul: I'll take care of reverting the netboot stuff
[12:36] <zul> ok
[12:37] <zul> i reverted the update-grub for quiet as well..but i need to go out since my wife is starting to get upset, bbl
[01:19] <mdz> zul: should be all set now
[01:20] <jdub> mdz: shouldn't you be out enjoying the last sun you'll see for a long time? :)
[01:20] <bddebian> heh
[01:20] <mdz> jdub: it is sunny and 93F
[01:20] <mdz> and I'm 20 minutes late for a barbecue
[01:21] <jdub> oh, it's mid afternoon
[01:21] <mdz> but I knew that if grub wasn't fixed, there would be a kernel upload or something which would stop nearly all edgy systems from booting
[01:21] <jdub> heh
[01:21] <mdz> this would be widely recognized as a bad thing
[01:22] <mdz> except by the powerpc users, who would have a nice chuckle
[01:22] <mdz> all 5 of them
[01:23] <jdub> stuck fixing grub merges on sunday, and suffering the torment of going to a barbecue but not eating meat - horror!
[01:24] <mdz> it turned out it wasn't the merge, but an opportunistic feature enhancement bundled with the upload (enabling diskless support)
[01:24] <mdz> which used to work fine, but now seems to completely break grub
[01:25] <jdub> heh
[01:29] <jdub> http://blogs.gnome.org/view/rbultje/2006/07/10/0
[01:29] <jdub> ^ macbook isight on linux :)
[01:30] <jsgotangco> wow
[01:33] <bddebian> Who is responsible for the merges pages?
[01:35] <tseng> keybuk
[01:36] <bddebian> I was afraid of that
[01:37] <bddebian> BTW, Hi tseng :)
[01:37] <tseng> hi.
[02:14] <jdub> hrm, how do i request an ignore-my-merge sync? ping elmo?
[02:14] <bddebian> You just want a straight sync?
[02:16] <jdub> yeah
[02:16] <bddebian> Just file a sync request on LP
[02:17] <jdub> hrm, ok
[02:17] <jdub> is there a wiki page about this?
[02:18] <bddebian> Not that I know of.  Just file a bug on LP request sync of <package> <version> from Debian <unstable,experimental> and subscribe ubuntu-archive
[02:19] <slomo_> jdub: https://wiki.ubuntu.com/DeveloperResources
[02:19] <slomo_> there's a section about syncs
[02:19] <jdub> slomo_: thanks
[02:20] <sladen> jdub: file a bug against the package and subscribe ubuntu-archive
[02:21] <bddebian> I get no respect :-)
[02:21] <jdub> slomo pointed me to Actual Documentation
[02:29] <thierryn> hi, I'm looking at https://wiki.ubuntu.com/PbuilderHowto and I see some big mistake in it... and it doesn't work for me... anyone could help me a bit?
[02:29] <bddebian> thierryn: What's the problem?
[02:29] <bddebian> Though I am apparently unqualified to answer :-)
[02:30] <thierryn> I'm on dapper, I do "sudo pbuilder create" then "sudo pbuilder build my-app.dsc" and it output this :
[02:31] <zul> mdz: sorry about that
[02:31] <thierryn> W: /home/thierry/.pbuilderrc does not exist
[02:31] <thierryn> pbuilder-buildpackage/i386 $Id: pbuilder-buildpackage-funcs,v 1.16 2005/06/03 12:07:39 dancer Exp $
[02:31] <thierryn> $Id: pbuilder-buildpackage,v 1.113 2005/06/25 06:27:42 dancer Exp $
[02:31] <thierryn> Current time: Mon Jul 10 00:23:46 UTC 2006
[02:31] <thierryn> pbuilder-time-stamp: 1152491026
[02:31] <thierryn> Building the build Environment
[02:31] <thierryn>  -> extracting base tarball [/var/cache/pbuilder/base.tgz] 
[02:31] <thierryn> E: failed to find /var/cache/pbuilder/base.tgz, have you done <pbuilder create> to create your base tarball yet?
[02:31] <thierryn> sorry for the spam
[02:32] <bddebian> Wow, hey infinity
[02:33] <bddebian> thierryn: Does the base.tgz exist?
[02:33] <bddebian> And have you checked your /etc/pbuilder/pbuilderrc?
[02:33] <thierryn> ho ok found the problem
[02:34] <thierryn> when I do pbuilder create I get:
[02:34] <thierryn> The following packages have unmet dependencies:
[02:34] <thierryn>   aptitude: Depends: libsigc++-2.0-0c2a (>= 2.0.2) but it is not installed
[02:34] <thierryn>   gnupg: Depends: libreadline5 (>= 5.1) but it is not installed
[02:34] <thierryn>   libsasl2: Depends: libdb4.2 but it is not installed
[02:34] <thierryn>   whiptail: Depends: libnewt0.52 (>= 0.52.2) but it is not installed
[02:35] <bddebian> You get that error on create?
[02:36] <thierryn> yeah
[02:36] <bddebian> Do you have debootstrap installed?
[02:36] <thierryn> yeah
[02:37] <bddebian> What happens if you do 'sudo pbuilder create --distribution dapper' ?  Anything different?
[02:39] <thierryn> E: No such script: /usr/lib/debootstrap/scripts/dapper
[02:39] <thierryn> ho im in a chroot<
[02:39] <bddebian> hmm
[02:41] <thierryn> but its been a long time since a used it, dont know if its edgy or dapper chroot
[02:41] <bddebian> Check your sources.list?
[02:43] <thierryn> where?
[02:43] <bddebian>  /etc/apt/sources.list
[02:43] <gnomefreak> thierryn: those look like edgy errors not so much dapper
[02:54] <bddebian> thierryn: Did we lose you? :-)
[02:55] <thierryn> no no fixing sources.list
[02:55] <bddebian> Ah :-)
[02:58] <thierryn> ha great, the chroot was breezy, that was the problem 
[03:01] <thierryn> is edgy repositories ready? I mean, can I create a edgy chroot
[03:01] <thierryn> &?
[03:02] <jdub> thierryn: yes
[03:02] <jdub> (no idea if debootstrap will successfully create one though)
[03:03] <infinity> It should.
[03:03] <thierryn> jdub : k
[03:03] <bddebian> thierryn: Can't you just dist-upgrade your existing chroot?
[03:04] <jdub> hi infinity 
[03:04] <jdub> infinity: how was your break?
[03:04] <infinity> jdub: Good until it wasn't.  See warthogs.
[03:05] <jdub> infinity: suck! :|
[03:05] <infinity> jdub: I'm just trying to kill a few thousand messages of email backlog before I go back to bed. :/
[03:05] <bddebian> heh
[03:48] <Hobbsee> hi all
[06:28] <jdub> yeah?
[06:31] <Hobbsee> heya jdub!
[06:31] <jdub> morning Hobbsee 
[06:32] <imbrandon> moins jdub, hey i was wondering whom to prod about getting skype 1.3 pkg in ubuntu-commercial repos ? or if there even WAS someone to prod about it
[06:34] <jdub> skype has their own repository
[06:37] <imbrandon> i realize this but a uniform place for commercial software would be nice since they ahve obviously started it
[06:56] <neuralis> jdub: http://solarsail.hcs.harvard.edu/~krstic/jdub.jpg
[06:58] <Hobbsee> haha
[06:58] <Hobbsee> neuralis: loosk just like him to me :P
[06:58] <neuralis> Hobbsee: it captures the essence of jdub well.
[06:58] <Hobbsee> hehe, indeed
[06:59] <jsgotangco> oh my
[07:01] <Eleaf> hi ;p
[07:01] <Hobbsee> hey Eleaf 
[07:01] <Eleaf> hi
[07:03] <Eleaf> I need to know what gtk method or widget is used whenever you change the volume with the keyboard and that volume item comes up in the middle of the desktop and how it is called ;p.
[07:04] <neuralis> Eleaf: this is not the appropriate channel. try #gtk.
[07:05] <Eleaf> there is 8 people there, I cannot expect a response in my timeframe
[07:05] <neuralis> Eleaf: that doesn't mean this channel becomes any more appropriate for your question.
[07:05] <jdub> Eleaf: try #gnome-hackers on gimpnet
[07:06] <jdub> neuralis: try to give helpful redirection dude
[07:06] <Eleaf> ;o)
[07:06] <neuralis> jdub: #gtk was all that came to mind.
[07:07] <jdub> neuralis: the underlying toolkit five levels down from the item the question was about? not wildly useful
[07:07] <jdub> Eleaf: gnome-settings-daemon handles those keys - #g-h for more discussion would be best
[07:07] <Eleaf> Thanks to both of you
[07:08] <Eleaf> okay jdub 
[07:09] <neuralis> jdub: huh? he wanted help identifying a gtk widget; i'm not sure how you see this as five levels removed from gtk
[07:10] <jdub> neuralis: the developers of the toolkit are not going to be entirely helpful with an implementation detail from one of their user's applications
[07:11] <neuralis> jdub: 'how do you draw a small floating window with gtk' seems pretty generic to me. anyway, doesn't matter.
[07:15] <fabbione> GOOOOOOD MORNING!
[07:15] <Hobbsee> hey fabbione!
[07:16] <fabbione> Hobbsee: intercontinental icecubes?
[07:16] <Hobbsee> fabbione: of course :)
[07:17] <sbalneav> night all
[07:22] <Hobbsee> hey raphink 
[07:22] <raphink> hi Hobbsee
[07:23] <raphink> :p
[07:23] <Hobbsee> raphink: please approve https://launchpad.net/distros/ubuntu/+source/netatalk/+bug/52488
[07:24] <Ubugtu> Malone bug 52488 in netatalk "[Edgy MoM]  Please sync netatalk 2.0.3-4 from Debian Sid" [Untriaged,Unconfirmed]  
[07:24] <Hobbsee> :P
[07:24] <Hobbsee> that's all, for the moment :)
[07:24] <Hobbsee> raphink: bleh.  maybe those icecubes do need to be thrown at you then.
[07:26] <fabbione> bug #52431
[07:26] <Ubugtu> Malone bug 52431 in libxrender "libXrender.la" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52431
[07:26] <fabbione> this is so no
[07:27] <Hobbsee> fabbione: mind pointing me to somewhere as to why it isnt?  i'm curious
[07:27] <fabbione> Hobbsee: google for why .la files should die
[07:27] <Hobbsee> fabbione: will do
[07:28] <fabbione> there have been several threads/flamewars/nuclearexplosions
[07:28] <Hobbsee> fabbione: hehe, right
[07:28] <fabbione> holy crusades started because of .la files!
[07:29] <Hobbsee> oh scary!
[07:31] <raphink> the main problem in .la is .hollywood
[07:32] <raphink> Hobbsee: there, done
[07:32] <Hobbsee> raphink: thankyou :)
[07:51] <pitti> Good morning
[07:51] <Hobbsee> hey pitti!
[07:57] <pitti> hi Hobbsee 
[08:44] <pitti> fabbione: do you remember why squid only suggests the snakeoil SSL cert in the documentation and does not actually use it by default?
[08:44] <fabbione> pitti: i think because squid can do some ssl operations but there is no real gain with the snakeoil
[08:47] <pitti> fabbione: I'm currently writing a debian bug (since this documentation change is our only diff), so I'd like to write some justification :)
[08:47] <fabbione> pitti: i will need to look into it again
[08:47] <fabbione> pitti: do you think it can wait a bit or is it urgent?
[08:47] <pitti> fabbione: ok, thanks!
[08:47] <fabbione> i am in the middle of merging xorg-server
[08:48] <pitti> fabbione: no, not urgent at all; I just postpone the mail
[08:48] <pitti> ooooh
[08:48] <fabbione> ok thanks
[08:48] <pitti> xorg> rock :)
[09:06] <fabbione> this is so going to blow up
[09:06] <fabbione> who was doing mesa merge?
[09:13] <pitti> fabbione: I'm not (it's assigned to me, but I only fixed the POT file; I have no clue about the package)
[09:14] <fabbione> pitti: ok
[09:14] <fabbione> i can workaround it for now, but once that merged we need to remember to do another xorg-server uplaod
[09:14] <fabbione> it changes a B-D
[09:18] <sivang> morning
[09:18] <Hobbsee> hey sivang 
[09:19] <sivang> hey Hobbsee 
[09:21] <pygi> sivang, :)
[09:21] <sivang> hi pygi 
[09:22] <dholbach> good morning
[09:23] <pygi> mornin' dholbach 
[09:24] <dholbach> hey pygi
[10:12] <pitti> sivang: hey
[10:13] <sivang> pitti: Hi Martin! how are you ?
[10:13] <pitti> sivang: pretty fine, and you?
[10:13] <pitti> sivang: the weekend was full of soccer watching and b-day celebration (of my grandma)
[10:14] <pitti> sivang: do you think you can merge and test culmus?
[10:16] <sivang> pitti: I talked about it with Colin, he told me that we should better wait for when x-sync/merge is over, since then culmus will turn into just a sync, but if you want me to do it now, I can ofcourse.
[10:16] <pitti> sivang: oh, no, that makes sense
[10:17] <sivang> pitti: he said that once X is done, it could get synced no fuss, since he checked and the changes are due to X stuff changing (paths, etc)
[10:18] <pitti> sivang: *nod*
[10:18] <sivang> pitti: re Weekend, although not much soccer watching (no TV in my apartment) we went out for some walking around the city, and watched a DVD, and prepared French Onion soup :)
[10:21] <madduck> pitti: are there any ubuntu changes in logcheck you want in debian?
[10:22] <pitti> madduck: no, I just requested a sync
[10:22] <madduck> ok
[10:22] <pitti> madduck: our only change (creation of /var/lock/logcheck in init.d) has been adopted
[10:22] <pitti> hi madduck 
[10:22] <madduck> hi. ok. great.
[10:22] <seb128> Mithrandir: around?
[10:37] <dholbach> hey el
[10:40] <Mithrandir> seb128: hiya
[10:40] <seb128> Mithrandir: yeah
[10:40] <seb128> Mithrandir: that's something weird with xkeyboard-config
[10:40] <Mithrandir> seb128: how so?
[10:41] <seb128> Mithrandir: xkb-data is empty and xkeyboard-config has the content ... shouldn't it be the other way around?
[10:41] <seb128> Mithrandir: and data are still installed to /etc instead of /usr/share ... is that on purpose?
[10:41] <Mithrandir> seb128: both is on purpose.  The transition isn't done yet.
[10:42] <seb128> ok
[10:42] <seb128> so I fix libxklavier for now
[10:42] <seb128> it's build with /usr/share as xkb path atm :p
[10:44] <pitti> hey Keybuk 
[10:45] <sivang> morning Keybuk 
[10:45] <pitti> Keybuk: FYI and to avoid duplicate work, I grabbed some of your merges
[10:45] <pitti> Keybuk: logcheck and mtools so far
[10:46] <pitti> Keybuk: and I am going to do sane-backends and netkit-base unless you want to
[10:46] <seb128> Keybuk: you should rather grab merges from people not being around like mvo no? :)
[10:46] <pitti> Keybuk: oh, and I already did nis
[10:46] <pitti> seb128: you mean me?
[10:46] <seb128> ups
[10:46] <seb128> yep
[10:47] <seb128> pitti: you should rather grab merges from people not being around like mvo no? :)
[10:47] <pitti> seb128: yep, I just did some packages I was familiar with
[10:47] <Keybuk> pitti: I'd prefer to do netkit-base
[10:47] <seb128> pitti: you seem to be looking for something to do and trying to take work from other people for a week, I've a whole stack of GNOME bugs to track if you fancy it :p
[10:47] <pitti> Keybuk: sure, I do not have a particular attachment to it :)
[10:48] <pitti> seb128: I have heaps of work to do for myself, but we need to kill the merges
[10:48] <Keybuk> otherwise no objection, I've also been grabbing merges from other people (Adam and Lamont mostly)
[10:48] <seb128> pitti: right, "we", you don't need to do them for everybody then :)
[10:48] <pitti> seb128: so I did Charles' merges and Adam's so far
[10:48] <pitti> seb128: sure :) (just trying' to help, sorry)
[10:49] <seb128> pitti: no need to be sorry, but I'm just pointing that other people will do their merge if you let them some time (I know I'll do mines for sure :p) ;)
[10:50] <Mithrandir> I'll grab the discover1 merge since I doubt daniels is going to do it. :-P
[10:51] <seb128> pitti: though I'm sure than MOTU guys would be happy if you do their ~490 merges to do ;)
[10:52] <Mithrandir> fabbione: so, did it work?
[10:52] <dholbach> and i'd be happy if somebody did  scim  - really happy
[10:52] <pitti> sivang: I'd let infinity do this
[10:52] <pitti> sivang: he has access to Debian's svn and might have ubuntu in svn, too
[10:52] <sivang> pitti: ah, I see, okay then :)
[10:53] <pitti> dholbach: ok, I'll do that
[10:53] <fabbione> Mithrandir: yes.. first shot.. and we don't need to do fonts transition. The DEbian path is hardcoded as optional in the server binary
[10:53] <Mithrandir> fabbione: oh, excellent.
[10:53] <fabbione> Mithrandir: at least as upgrade from dapper.. i have no idea if it works on clean installs yet
[11:12] <sivang> dholbach: any ohter mergers you'd be hapy for someone to help you with? :)
[11:13] <dholbach> ogra wanted to do gpm and pitti wanted to do scim
[11:13] <dholbach> i think thoses were the ones i wasn't happy with
[11:13] <pitti> dholbach: scim-{anthy,chewing,etc.} too?
[11:13] <dholbach> hum, i didn't touch them
[11:13] <Chipzz> dholbach: s/gpm/g-p-m/ ;)
[11:13] <dholbach> lemme look whose merges those are
[11:14] <dholbach> Chipzz: yeah, probably :)
[11:14] <Chipzz> dholbach: gpm is an actual package and probably not what you're referring too ;)
[11:14] <dholbach> pitti: hum, not sure, if Hou ZhengPeng wanted to do them
[11:14] <dholbach> Chipzz: i know
[11:15] <Chipzz> anyway, enough nitpicking :P
[11:15] <dholbach> :)
[11:15] <el> hey dholbach :)
[11:15] <dholbach> el: how's it going?
[11:15] <dholbach> el: when are we going to go for some ice cream? i feel like it now already ;)
[11:15] <dholbach> *melt*
[11:16] <el> dholbach, hehe, too hot to work
[11:16] <el> dholbach, this week is very busy -> we have to do 40 tests :-|
[11:16] <dholbach> el: i can't say, I'm not busy :-)
[11:17] <dholbach> but not too busy to get some of the best icrecream around :)
[11:17] <el> dholbach, hehe 
[11:17] <el> dholbach, wednesday evening maybe? 
[11:17] <el> some feierabend icecream (instead of feierabend beer)
[11:17] <dholbach> el: sounds good
[11:17] <el> yammm
[11:17] <dholbach> (that doesn't stop me of getting some later on) :-p
[11:18] <el> dholbach, you are lucky to live almost next door
[11:18] <dholbach> el:i think it's the same distance for both of us, no?
[11:18] <dholbach> (from your work place)
[11:18] <el> dholbach, from home yes, but not from my work office ;-)
[11:18] <dholbach> oh, hm
[11:19] <el> dholbach, the new workplace (starting september) is next door
[11:19] <dholbach> ahhhh
[11:19] <dholbach> rock on :-)
[11:19] <el> that's gonna be great :)
[11:19] <el> ice cream every day
[11:19] <dholbach> woohoo
[11:19] <el> hehe
[11:20] <pitti> Keybuk: do you want to merge dhcdbd together with n-m or shall I merge it?
[11:20] <dholbach> el: bon appetit
[11:20] <jsgotangco> he el
[11:20] <Keybuk> pitti: I will merge it, as I said last week
[11:21] <pitti> Keybuk: oh, I forgot; thank you!
[11:22] <Keybuk> Kamion: morning
[11:22] <ivoks> hi
[11:23] <sivang> hey ivoks 
[11:23] <ivoks> pitti: ping
[11:23] <pitti> hi ivoks 
[11:23] <ivoks> hi sivang ; how are you?
[11:23] <ivoks> pitti: you've heard about that bug in 1.2.1? :)
[11:24] <pitti> ivoks: yep, I read it this morning
[11:24] <sivang> ivoks: fine, thanks.
[11:24] <pitti> ivoks: I was just about to turn my attention to it :)
[11:24] <pitti> ivoks: I'll also add something to postinst to /^RunAsUser/d 
[11:24] <ivoks> pitti: there's debdiff that fixes it
[11:24] <ivoks> pitti: nice :)
[11:25] <pitti> ivoks: (and grrr @upstream to silently break his own configuration file format...)
[11:25] <ivoks> pitti: it's a bug
[11:25] <pitti> ivoks: I mean RunAsUser, not the IP parsing
[11:25] <ivoks> ah, that
[11:26] <ivoks> s/^RunAsUser/# RunAsUser - this option isn't available in CUPS 1.2.1/ would be nicer... imho
[11:26] <pitti> ivoks: *nod*
[11:26] <sivang> ivoks: FYI I did the merge for etherape, was just a sync.
[11:27] <ivoks> sivang: etherape? /me confused
[11:27] <pitti> ethereal?
[11:28] <HrdwrBoB> etherape is a graphical tool
[11:28] <HrdwrBoB> maps your network connections
[11:28] <HrdwrBoB> it's seperate
[11:28] <sivang> EtherApe is an etherman clone. It displays network activity
[11:28] <sivang>  graphically. Active hosts are shown as circles of varying size,
[11:28] <sivang> pitti, ivoks : ^^
[11:28] <ivoks> i know what they both are, bu i don't remeber saying anything abou ti
[11:28] <ivoks> s/ti/it
[11:28] <sivang> ivoks: you were the last uploader on the MOTU merge list ;)
[11:28] <ivoks> ah... :)
[11:29] <sivang> so it's courtesy and good practice to let the last person know you are taking his merge :)
[11:29] <ivoks> sivang: right, thanks for info
[11:29] <sivang> ivoks: np
[11:33] <doko> pitti: bug 52465
[11:33] <Ubugtu> Malone bug 52465 in gcc-4.1 "[libgcc1]  segfault on ppc when unwinding stack (c++ exceptions, mono exceptions)" [Critical,Confirmed]  http://launchpad.net/bugs/52465
[11:33] <ivoks> see you later today, bye
[11:34] <fabbione> go SSP!
[11:34] <pitti> doko: ugh, I thought it only affected mono
[11:35] <pitti> doko: so maybe we should disable it on ppc until upstream has a fix?
[11:37] <doko> first looking at it ...
[11:50] <seb128> is there any massive builds retry planned?
[11:50] <seb128> most of GNOMEish stuff have not built on !i386 for a week apparently
[11:50] <fabbione> seb128: what's the blocker?
[11:50] <fabbione> can you see it from the logs?
[11:50] <fabbione> or is it just random?
[11:51] <fabbione> x libs have been finished friday
[11:51] <Keybuk> seb128: I did a retry on Thursday/Friday ... what's the problem ?
[11:51] <seb128> fabbione: for one GTK 2.10 didn't built due to xorg borkage and didn't get retried since
[11:51] <fabbione> seb128: oh ok
[11:51] <fabbione> it should be settled by now
[11:51] <fabbione> libs are all done
[11:51] <fabbione> hopefully they also work
[11:51] <seb128> Keybuk: let me look to be sure
[11:51] <Keybuk> seb128: could you give me a list of things that need giving back
[11:52] <seb128> it looked like a "GTK failed because pango was not installable due to xft"
[11:52] <seb128> Keybuk: sure, a min
[11:52] <seb128> Keybuk: gtk+2.0 to start :)
[11:52] <seb128> hum
[11:52] <seb128> http://librarian.launchpad.net/3279966/buildlog_ubuntu-edgy-amd64.gtk%2B2.0_2.10.0-0ubuntu1_FAILEDTOBUILD.txt.gz
[11:52] <seb128>   linuxdoc-tools-text: Depends: groff but it is not going to be installed
[11:53] <seb128> ah
[11:53] <seb128> it got retried, that's a new error 
[11:53] <Kamion> Keybuk: hi
[11:53] <seb128> hum
[11:53] <Keybuk> Kamion: good weekend?
[11:53] <seb128> anybody with an amd64 to looks if groff is installable now, and if it's not why?
[11:53] <Kamion> yep, much beer
[11:53] <Kamion> seb128: what's wrong with edgy_probs?
[11:53] <Keybuk> Kamion: I got slightly sunburnt at goodwood on saturday
[11:54] <Kamion> edgy_probs currently says that groff is installable everywhere
[11:54] <fabbione> pitti: ping?
[11:55] <pitti> fabbione: pong
[11:55] <seb128> Kamion: nothing, so gtk+2.0 probably need a retry only
[11:55] <seb128> Kamion: I was looking at http://librarian.launchpad.net/3279966/buildlog_ubuntu-edgy-amd64.gtk%2B2.0_2.10.0-0ubuntu1_FAILEDTOBUILD.txt.gz
[11:55] <fabbione> pitti: do we have anything pending on xorg-server by anychance?
[11:55] <Kamion> sure, just saying you can look at the automatic list rather than asking for people to check manually
[11:55] <fabbione> (dapper to be more specific)
[11:55] <seb128> Kamion: right
[11:56] <Kamion> also looking at just the last of a huge pile of "is not going to be installed" from apt is not very helpful IME
[11:56] <Kamion> because it's usually just that apt's problem resolver got bored
[11:56] <Kamion> note that groff depends: libx11-6 and above apt said that it was unhappy with libx11-6
[11:56] <pitti> fabbione: if http://xorg.freedesktop.org/releases/X11R7.0/patches/x11r7.0-setuid.diff is already applied in edgy, then not
[11:56] <pitti> fabbione: oh, that one is not yet applied in dapper
[11:57] <fabbione> pitti: ok perfect thanks
[11:57] <pitti> fabbione: it's not really urgent (I regard it as bug fix rather than a vulnerability)
[11:57] <fabbione> pitti: i am about to apply it to edgy via debian sync
[11:57] <fabbione> pitti: if you think it's only bug fixes i will prepare a dapper-updates
[11:58] <fabbione> pitti: i need to upload xorg-server because well.. hmm one package in dapper is kind of empty by mistake
[11:59] <pitti> fabbione: -updates is fine for me
[11:59] <fabbione> pitti: ok thanks
[11:59] <fabbione> pitti: what's the approval procedure for -updates now? open a bug with debdiff and sub ubuntu-release?
[11:59] <seb128> Keybuk: gtk+2.0 (which should unblock libgnomeui which is dep-waiting) then when libgnomeui is built: ubuntulooks gucharmap gcalctool gnome-python totem gnome-system-monitor evince gossip tsclient file-roller glabels glade nautilus-sendto nautilus-cd-burner epiphany-browser
[11:59] <fabbione> -ETOOMANYPROCEDURES
[12:00] <pitti> fabbione: unless there is already a bug, just mail mdz
[12:00] <pitti> fabbione: if there is a bug, sub'ing him and asking for approval works fine, too
[12:00] <fabbione> pitti: ok. i don't recall a bug about it
[12:01] <Keybuk> seb128: gtk+2.0 rebuilding now (this had already built on i386)
[12:01] <seb128> Keybuk: has said before, that's on !i386
[12:01] <seb128> Keybuk: i386 is fine
[12:02] <Keybuk> ok
[12:02] <seb128> i386 libs built just before the xorg b0rkage probably
[12:05] <tseng> moin seb128 
[12:05] <Keybuk> will they not need rebuilding with the new X11 libs?
[12:05] <seb128> hi tseng
[12:06] <seb128> Keybuk: I don't think so
[12:06] <seb128> Keybuk: anyway GNOME 2.15.4 this week so we will rebuild a good part of the stack anyway
[12:07] <fabbione> Keybuk: no, there are no relevant changes to the libs other than being installable again
[12:07] <fabbione> Keybuk: it was a merge only but some of them had the (in)famous epoch versioned depends *
[12:15] <Keybuk> seb128: dep-wait on ia64: libglib2.0-dev (>= 2.12.0)
[12:16] <sivang> Keybuk: will you have time today to review SystemCleanUpTool so we can get it approved ?
[12:16] <seb128> Keybuk: hum, right, glib FTBFS on ia64 ... I need to investigate that, thank you for pointing it
[12:16] <Keybuk> sivang: possibly
[12:17] <sivang> Keybuk: oh, that would make me happiest man alive :)
[12:20] <Kamion> seb128: goffice in NEW seems to drop back from libgoffice-1-2 to libgoffice-0-3; is that intentional?
[12:20] <seb128> dholbach: do you know about goffice?
[12:20] <Kamion> Gloubiboulga: ^--
[12:20] <seb128> Kamion: there might be 2 versions to NEW?
[12:21] <Kamion> there are not
[12:21] <seb128> Kamion: I think somebody synced the unstable version first, and dholbach figured we need the experimental one
[12:21] <seb128> ok
[12:21] <Kamion>   * [debian/*]  Follow upstream versioning change for the development version.
[12:21] <seb128> I'll let dholbach or Gloubiboulga comment then
[12:21] <Kamion> hmm, may be deliberate
[12:21] <dholbach> seb128: for gnumeric 1.7.0 we need goffice 0.3.0
[12:21] <Kamion> we have the version from experimental, yes
[12:22] <dholbach> and the package name was crafted in debian (the soname really changed)
[12:22] <Kamion> I'm fine with it if it's intentional, just wanted to check
[12:22] <Kamion> (accepted)
[12:22] <dholbach> thanks Kamion
[12:24] <pitti> seb128, dholbach: do you plan to update gimp to 2.2.12 in the next time? I currently do the security update for stables and wonder whether I should update edgy, too (and merge with Debian on this occasion)
[12:24] <seb128> pitti: I don't intend to touch gimp for now, maybe dholbach do though :)
[12:24] <pitti> (it's mvo's merge ATM)
[12:25] <dholbach> seb128: let's get the experimental gimp in :)
[12:26] <dholbach> seb128: debian has 2.3.9-1 in experimental
[12:26] <hmrocha> hello, when i press alt+f2 and run gconf-editor gnome-panel crashes
[12:26] <Kamion> pitti: do we want linuxprinting.org-ppds in main?
[12:26] <seb128> dholbach: I've too much to do already but feel free to do it
[12:26] <hmrocha> can you try in your computer please?
[12:26] <seb128> hmrocha: do you use a11y feature?
[12:26] <pitti> dholbach: this also needs the security patch, btw (it's only fixed in 2.2.12)
[12:26] <hmrocha> seb128: what's that?
[12:26] <dholbach> seb128, pitti: might be safer to do the 2.2.12 update
[12:26] <dholbach> pitti: i set it on my list
[12:26] <seb128> hmrocha: try #ubuntu, that's not an user chan, but that might be a known issue
[12:27] <pitti> Kamion: hm, sounds useful for printers which speak Postscript
[12:27] <hmrocha> seb128: ok, sorry
[12:27] <pitti> Kamion: but I never looked at it or saw a request for it
[12:27] <dholbach> seb128, pitti: not sure how stable experimental gimp is
[12:27] <seb128> dholbach: stable enough for edgy probably ;)
[12:27] <Kamion> nor I, I just noticed the name while looking through the hplip changelog while doing NEW processing
[12:27] <dholbach> seb128: word up :-)
[12:27] <Kamion> Keybuk: btw, I'm bored of archive admin for now, your turn :)
[12:27] <hmrocha> seb128: are memory leaks appropriate for this channel?
[12:27] <pitti> dholbach: ok, great (Debian has the fix in unstable already, CVE is in their changelog)
[12:28] <seb128> hmrocha: no
[12:28] <seb128> hmrocha: cf topic
[12:28] <seb128> hmrocha: you really want to use the bug tracker for issues like that
[12:28] <dholbach> pitti: i'll have a look if 2.3.10 fixes it
[12:28] <Keybuk> Kamion: heh, if you'd waited just 30s, I would have done it anyway
[12:28] <Keybuk> I was just about to start the syncs, when you did the first one
[12:29] <Kamion> ah, heh, ok
[12:29] <Kamion> sucks to be me
[12:42] <Keybuk> sivang: UNIVERSE NEEDS YOU! :D
[12:42] <Keybuk> (though I guess their deadline is a lot further away)
[12:48] <sivang> Keybuk: I already helped some merges there , and wil do more , but yeah, main's deadline is annoyingly close :)
[01:09] <Mithrandir> doko: would you care to do the syck merge as it's a python transition thing?
[01:09] <ogra> pitti, you have a logitech udb 250 headset, right  
[01:09] <ogra> ?
[01:09] <ogra> *usb
[01:14] <dholbach> ogra: and another g-p-m release: 2.15.4 :)
[01:14] <ogra> dholbach, is the stack ready now ? 
[01:15] <dholbach> ogra: i386 seems happy
[01:15] <ogra> when i tried it last time, it ftbfs because of missing pango stuff
[01:15] <ogra> ok, then i'll try today again
[01:15] <dholbach> rocknroll
[01:15] <doko> Mithrandir: ok
[01:16] <Mithrandir> doko: cheers.
[01:20] <doko> Mithrandir: bah, now we're in sync with python, we have a php4/php5 divergence
[01:21] <Mithrandir> doko: we've had that since hoary or breezy, so that's nothing new.
[01:32] <slomo_> Keybuk, Kamion: could you please accept metacity and nautilus-cd-burner from NEW? i'm waiting for them for gnome-python-desktop upload which is currently blocking most of gnome
[01:32] <Keybuk> slomo_: I'll be processing the NEW queue once I've finished processing syncs
[01:33] <Keybuk> you shouldn't need to block an upload for a NEW processing, the build will dep-wait
[01:34] <slomo_> Keybuk: i wanted to testbuild it before... but ok, i'll just upload it and hope that it builds fine :)
[01:35] <Keybuk> you can test build it by building metacity and nautilus-cd-burner
[01:38] <doko> Selecting previously deselected package libc6-i386.
[01:38] <doko> Unpacking libc6-i386 (from .../libc6-i386_2.4-1ubuntu6_amd64.deb) ...
[01:38] <doko> Selecting previously deselected package lib32gcc1.
[01:38] <doko> Unpacking lib32gcc1 (from .../lib32gcc1_1%3a4.1.1-2ubuntu5_amd64.deb) ...
[01:38] <doko> dpkg: error processing /home/buildd/build-224804-172430/chroot-autobuild/var/cache/apt/archives/lib32gcc1_1%3a4.1.1-2ubuntu5_amd64.deb (--unpack):
[01:38] <doko>  trying to overwrite `/usr/lib32', which is also in package libc6-i386
[01:38] <doko> Selecting previously deselected package lib32z1.
[01:38] <doko> Unpacking lib32z1 (from .../lib32z1_1%3a1.2.3-12ubuntu1_amd64.deb) ...
[01:38] <doko> dpkg: error processing /home/buildd/build-224804-172430/chroot-autobuild/var/cache/apt/archives/lib32z1_1%3a1.2.3-12ubuntu1_amd64.deb (--unpack):
[01:38] <doko>  trying to overwrite `/usr/lib32', which is also in package libc6-i386
[01:38] <doko> Mithrandir: ^^^ from the gcc-4.1 build log, works fine for me, is this a problem with the buildd?
[01:39] <Mithrandir> doko: do you have force-overwrite or something in dpkg.conf?
[01:40] <doko> /usr/lib32 is a directory ...
[01:40] <infinity> It bloody well better be, yes.
[01:40] <Mithrandir> oh, true.
[01:41] <Mithrandir> that's interesting, then..
[01:41] <infinity> Can someone mail me to investigate that tomorrow when I'm in and not sick?
[01:41] <infinity> I've had this argument with dpkg and glibc a few times already, so there may be a real bug somewhere.
[01:41] <infinity> s/may be/almost certainly is/
[01:42] <Mithrandir> infinity: sent.
[01:43] <infinity> Thanks.
[01:43] <Mithrandir> I just C&P the IRC log, I presume that works.
[01:43] <infinity> Works for me, yes.
[01:47] <Keybuk> doko: usually happens when two different packages think /usr/lib32 is a symlink to different places
[01:48] <Keybuk> the annoying thing is that the error will occur on a package that thinks /usr/lib32 is a directory
[01:50] <infinity> It should be a directory everywhere, but I'm looking.
[01:50] <doko> Keybuk: that could be a wrongly merged lib32* package, which still has /usr/lib32 pointing to /emul/something. but looking at the changelog, the first lib32 packages unpacked are libc6-i386, and then lib32gcc1. so maybe it's a leftover symlink on the buildd?
[01:51] <janimo> hi all
[01:52] <zul> hey
[01:52] <jsgotangco> hey
[01:53] <Keybuk> doko: leftover from what?>
[01:53] <Keybuk> chroots are fresh for each build, not re-used
[01:58] <infinity> root@crested:~# dpkg -S /emul
[01:58] <infinity> fakeroot: /emul
[01:58] <infinity> doko: The fakeroot merge is what did it.
[01:58] <infinity> doko: Fix that and we're back on track.
[01:59] <infinity> doko: (and fix your preinst to be less scary too)
[01:59] <Kamion> hmm, doc-base <- fun merge
[02:02] <sivang> seb128: Would you mind if I did vino? ; no new  upstream version, and only one patch to reapply (01_no_client_on_hold_loop.patch) and only autotools version change (1.9.6) they are using. So needs putting the patch in, and possible rebuild with changed autoconf version.
[02:03] <sivang> seb128: ah also, dropping avahi build deps
[02:03] <infinity> doko: Of course, given fakeroot's build-deps, I may need to manually bootstrap that when I wake up, but if you upload fixed source, I can sort it on the binary end.
[02:06] <doko> infinity: ok, will do
[02:07] <ogra> pitti, ping
[02:07] <doko> infinity: err, fakeroot 1.5.9ubuntu1 does have /usr/lib32 ...
[02:08] <seb128> sivang: do what? I asked for a sync of vino and it has been done
[02:08] <infinity> doko: Oh, hah.  It failed to build with the same problem.
[02:09] <infinity> doko: So if I bootstrap the current one, everything will be fine?
[02:09] <doko> infinity: yes, looks so
[02:09] <infinity> doko: Okay, thanks.  Will do.
[02:11] <sivang> seb128: ah, okay, probably MoM was not updated yet :) 
[02:12] <seb128> sivang: you can probably help MOTU guys, they have an impressive list of merges to do
[02:18] <doko> iwj: will xulrunner be in main for edgy?
[02:20] <infinity> doko: Err, I'll fix it when soyuz stops arguing with me about what I'm trying to do.
[02:21] <dholbach> doko: unfortunately not, seems upstream has no firefox-without-xulrunner source, so we'd have the source in the archive two times
[02:22] <seb128> dholbach: what about xulrunner?
[02:22] <dholbach> seb128: doko asked, if we'll have xulrunner in main for edgy
[02:22] <seb128> ah, k
[02:23] <seb128> probably not 
[02:23] <dholbach> pitti: gimp uploaded
[02:23] <pitti> ogra: pong
[02:24] <pitti> ogra: yes, I have a logitech usb headset, not sure about the model
[02:24] <seb128> dholbach: later
[02:24] <sivang> seb128:  Is the synced vino already in edgy ?
[02:25] <seb128> sivang: you don't know how to look that by yourself that you have to ask?
[02:25] <seb128> sivang: I've read the mail on edgy-changes, let me have a look on the ftp since that seems to be to complicate for you to do it :p
[02:25] <gnomefreak> vino 2.13.5-0ubuntu6   is in edgy atm
[02:26] <seb128> http://archive.ubuntu.com/ubuntu/pool/main/v/vino/vino_2.13.5-1.diff.gz
[02:26] <seb128> 2.13.5-1 has been synced
[02:26] <seb128> looks like it didn't build yet though
[02:27] <sivang> seb128: so I can get the source only after it's been built ? 
[02:27] <sivang> seb128: (I apt-get source and it gave me the odl one)
[02:27] <seb128> the URI I just copied
[02:28] <seb128> you know you can wget it
[02:28] <seb128> but why do you need the new version anyway?
[02:28] <ogra> pitti, does your headset work for more than 1-1.5 mins with the current powerpc kernel ?
[02:28] <seb128> that's only a sync from Debian, it has nothing useful
[02:28] <ogra> for me it just dies
[02:28] <sivang> seb128: I don't, I just wanted to know what made me be stupid and think it was not sync'd yet, sorry :)
[02:28] <pitti> ogra: hm, I don't know; I have to upgrade my laptop to current edgy and check
[02:28] <seb128> sivang: that's not exactly the right chan for that :p
[02:28] <sivang> seb128: never trust apt-get source then :p
[02:29] <seb128> sivang: rather wait for the index update
[02:29] <sivang> seb128: I agree, and apologize deeply :)
[02:29] <seb128> sivang: but users questions on #ubuntu
[02:29] <ogra> pitti, for me it doesnt even play music for more than the above timeframe
[02:29] <seb128> np
[02:29] <ogra> seems either the driver or alsa
[02:29] <pitti> ogra: I haven't used it very extensively so far, but I'll check on next possibility
[02:30] <ogra> it works well on my amd64 lappie with the dapper kernel though
[02:34] <Hobbsee> hi all
[02:35] <Riddell> Keybuk: are you still playing at being infinity today?  could you give back komba2?
[02:52] <iwj> doko: I wasn't planning to do anything do with about by from or pertaining to xulrunner.
[03:05] <Keybuk> Riddell: I am
[03:07] <Hobbsee> Keybuk: thanks for fixing MOM :)
[03:07] <Keybuk> fixing?
[03:07] <Hobbsee> Keybuk: how it wasnt updating, even though the merges had gone thru
[03:08] <Keybuk> when wasn't it updating?
[03:08] <Keybuk> Mithrandir: ?
[03:08] <Douglas77> hi! Do you know how to customize a Ubuntu-ISO so it uses a self-compiled kernel? https://help.ubuntu.com/community/LiveCDCustomization/6%2e10 doesn't talk about that...
[03:08] <Hobbsee> Keybuk: a couple of days ago?  there was talk about it, people were confirming it - i thought you were too...
[03:08] <Mithrandir> Keybuk: it doesn't do magic stuff to fix mismatched orig.tar.gz files between Debian and Ubuntu.
[03:09] <Keybuk> Mithrandir: it can't do anything ?
[03:09] <Keybuk> Hobbsee: *shrug* not that I'm aware of
[03:09] <Mithrandir> it could magically give me a new unsigned .dsc with the correct .dsc.
[03:09] <Mithrandir> uh, orig.tar.gz
[03:09] <Keybuk> Hobbsee: the archive was fucked a lot last week, maybe it was that
[03:09] <Keybuk> (which I was fixing)
[03:09] <Hobbsee> Keybuk: it also borked the kid3 merge - said two files were different, but they werent.
[03:09] <Keybuk> Mithrandir: for which, Debian?
[03:09] <Hobbsee> Keybuk: ah, may well have been
[03:10] <Keybuk> Hobbsee: bet they were
[03:10] <Hobbsee> Keybuk: bet they werent. StevenK and myself checked that with diff.
[03:10] <Hobbsee> s/diff/whatever it was - my brain's dying!
[03:10] <Keybuk> Hobbsee: did you md5sum them?
[03:10] <Mithrandir> Keybuk: it'd make sense for it to give me a source package with what's in Ubuntu, but with Debian's diff, yes.
[03:10] <Keybuk> Mithrandir: but that wouldn't be the source of the merge ...
[03:10] <Hobbsee> Keybuk: didnt try that, no.
[03:11] <Keybuk> Mithrandir: it could give you a .src.tar.gz of the Debian unpacked tree
[03:11] <Keybuk> Hobbsee: binary files, I assume?
[03:11] <rodarvus> iwj: do you have any idea on how hard would it be to have xulrunner on main for Edgy? Could be useful for Edubuntu (possibly for other reasons too)
[03:11] <Hobbsee> Keybuk: po files.
[03:12] <iwj> rodarvus: Hi.  As I said to doko, I'm afraid I haven't looked at that at all.
[03:12] <iwj> So I don't really know the answer.
[03:12] <Hobbsee> Keybuk: unfortunately, i dont have it anymore.
[03:12] <iwj> rodarvus: Wouldn't this be the kind of thing that should be in a spec ?
[03:13] <Keybuk> Hobbsee: oh, those always do odd things
[03:13] <Hobbsee> Keybuk: ah okay
[03:13] <Keybuk> Hobbsee: usually means msgmerge core dumped
[03:13] <Keybuk> (yay, gettext)
[03:13] <Hobbsee> hehe great, we say!
[03:13] <seb128> rodarvus: we discussed it basically during the summit, xulrunner to main is not a good idea
[03:13] <Kamion> msgmerge sometimes issues complaints about strange encodings or whatever
[03:13] <seb128> rodarvus: since we have to ship firefox xulrunner would be only code duplication
[03:14] <seb128> rodarvus: we have nobody wanting to work on maintaining it and enough bugs without that anyway
[03:14] <rodarvus> seb128: oh, that is partially bad news, as we'd like to research the possibility of having Epiphany on Edubuntu (but I agree it will probably won't be done in Edgy timeframe)
[03:14] <Kamion> epiphany's already in main
[03:14] <seb128> rodarvus: we would like to use xulrunner for GNOME too ....
[03:15] <seb128> Kamion: but it uses firefox, not xulrunner atm
[03:15] <Kamion> yes
[03:15] <rodarvus> Kamion: yes, but it uses firefox
[03:15] <seb128> the discussion is about xulrunner here
[03:15] <seb128> if they have to ship firefox anyway, no point to ship a second browser (epiphany)
[03:15] <seb128> it would be nice to ship epiphany based on xulrunner and no firefox for them though
[03:16] <seb128> anyway, I don't think it'll happen before having firefox using xulrunner ...
[03:16] <iwj> And the point of this is just to get the redundant firefox code off the install cd ?
[03:16] <ogra> seb128, we have to ship epiphany 
[03:16] <Kamion> iwj: right, epiphany doesn't produce a gain unless its firefox dependency is removed
[03:16] <ogra> and will do so, regardless of the rendering engine
[03:17] <ogra> but xulrunner would indeed be a size advantage (a major one)
[03:17] <seb128> ogra: why? because of kioske mode?
[03:17] <ogra> yep
[03:17] <rodarvus> iwj: for us, the point is to have Epiphany as default browser on low-memory situations, and also because epiphany is kiosk-able (using sabayon)
[03:17] <seb128> hum, k
[03:17] <ogra> and because we want to ship pessulus and sabayon by default
[03:17] <iwj> rodarvus: Those things can be done even if you still ship firefox.
[03:17] <iwj> You just turn it off in the menus etc.
[03:17] <ogra> which both have browser features included
[03:18] <iwj> Kamion: Quite so.
[03:18] <seb128> iwj: the edubuntu CD is fighting to spare 1M usually, so dropping firefox would probably be a good win for them
[03:18] <ogra> adding epiphany will cost us only some MB ...
[03:18] <rodarvus> seb128: exactly
[03:18] <iwj> seb128: Mmmhm.
[03:18] <ogra> but dropping firefox and replacing it with xulrunner willl rather go into the 10MB area
[03:19] <iwj> I think though that you're going to have real problems with dual maintenance of lots of the code.
[03:19] <seb128> that's why we don't want xulrunner to main :p
[03:19] <ogra> i think its only a security updates issue ... but there its a major one 
[03:20] <seb128> I think the plan for upstream is to make firefox use xulrunner at some point, but that's not for now :/
[03:20] <rodarvus> Kamion, Keybuk: in the next few yours we'll be uploading a dozen+ xserver-xorg-video-* packages as NEW - hopefully later today, they'll replace all old xserver-xorg-driver-* packages
[03:20] <Keybuk> rodarvus: ok
[03:20] <ogra> maintaining a source twice works if you have two people caring for it during development ... but it would give pitti grief if he'd have to do security patches for both
[03:20] <pitti> BenC: ping
[03:20] <rodarvus> (later a upload of xorg to satisfy xserver-xorg-video-all will be done to satisfy the dependency too)
[03:21] <iwj> seb128: Yes.
[03:22] <mhb> good afternoon to you, mighty developers
[03:24] <mhb> perhaps one of you knows (and could tell me) when we unworthy translators will be able to translate Edgy ... (surely after Jul 13th, but when?)
[03:25] <seb128> mhb:  #launchpad might be a better place to ask that
[03:25] <seb128> mhb: carlos probably knows about it
[03:25] <seb128> mhb: why "unworthy"?
[03:26] <Kamion> mhb: with regard to your inkscape query from the weekend, 0.44 has already been uploaded to Edgy, but just hasn't built yet. That will be sorted out.
[03:26] <mhb> seb128: a bit of drama never hurts :o)
[03:26] <pitti> carlos: any idea when we can get edgy translation tarballs?
[03:26] <seb128> mhb: not sure if it hurts but it can bother people :p
[03:27] <ogra> mhb, telling that to seb128 might not be the right thing, he had his drama yesterday evening :)
[03:27] <seb128> lol
[03:27] <ogra> (he's french)
[03:27] <seb128> ogra: that's only sport, I don't really care about it :)
[03:27] <ogra> seb128, btw, any words from zidane in the french press ? 
[03:27] <seb128> nop
[03:29] <thom> there's not much he could really say... "i suck, it's been fun, kthx"
[03:30] <jsgotangco> he got to be man of the match though
[03:30] <ogra> thom, well, i'd be curious to hear about the reason ...
[03:31] <mhb> should I wait here for a response from carlos or should I ask in #launchpad?
[03:31] <mhb> Kamion: thanks
[03:36] <carlos> mhb, seb128, pitti: I'm finishing some migration code for Edgy
[03:36] <carlos> it's my main task atm so I guess really soon
[03:36] <seb128> cool
[03:37] <pitti> carlos: cool
[03:37] <seb128> mhb: carlos replied :p
[03:37] <mhb> seb128: noticed :o)
[03:37] <mhb> carlos: thanks for the answer
[03:37] <ogra> seb128, dholbach, does ekiga offer any kind of plugin mechanism ? i'd like to write a script that notifies all my desktops if a call comes in ...
[03:38] <mhb> carlos: really soon is a matter of days? one week? two weeks?
[03:38] <carlos> mhb: days to finish some code to open it even better than dapper
[03:38] <seb128> ogra: no idea, I've not used ekiga (yet)
[03:38] <Treenaks> ogra: afaik it doesn't..
[03:39] <carlos> mhb: after that I will test it and try to move it into production... I guess we could say one week or so
[03:39] <ogra> room for improvement then :)
[03:39] <carlos> between testing and deployment 
[03:39] <Treenaks> ogra: yeah, it also doesn't notify anything/anyone when a connection to a SIP server drops
[03:39] <Treenaks> ogra: (so you can't get incoming calls..)
[03:39] <ogra> Treenaks, well, i see if my account is connected or not in th eUI
[03:40] <Treenaks> ogra: yes, but it doesn't notify you if it gets disconnected for (some|no) reason
[03:40] <Keybuk> ogra: adding libnotify support would be better ?
[03:40] <ogra> Keybuk, surely
[03:50] <bddebian> Morning folks
[03:50] <bddebian> Thanks Kamion
[03:53] <Keybuk> Mithrandir: I don't think we should even attempt to merge bootchart
[03:53] <Keybuk> the Debian package is _completely_ different
[03:53] <Mithrandir> Keybuk: iirc you and whoever packaged it in Debian did it in parallell?
[03:54] <Keybuk> yup, and they've taken a totally different direction with it
[03:54] <Keybuk> we integrated it into the initramfs and used java-gcj-compat
[03:54] <Keybuk> they've made it use kaffe and replace init
[03:54] <Mithrandir> ew, ok.
[03:55] <Mithrandir> try dropping the maintainer a mail asking if he could switch to our approach?
[03:55] <bddebian> Must be because of you damn non-cooperative Ubuntu types
[04:02] <Keybuk> general observation: merges are much easier if you don't reindent the entire source coed
[04:04] <seb128> Keybuk: could you bump the gnome-python-desktop build priority? :) That would unblock the gnome-applets sync and new version and some other packages probably too
[04:04] <sivang> heh
[04:05] <Keybuk> seb128: ok
[04:06] <gnomefreak> was it decided to keep xorg 7.0 for edgy?
[04:06] <seb128> Keybuk: thank you
[04:06] <seb128> gnomefreak: no
[04:06] <Keybuk> gnomefreak: no decision was made
[04:06] <gnomefreak> ok
[04:08] <seb128> Keybuk: hum, has nautilus-cd-burner been accepted yet (soname change)? because it's required for gnome-python-desktop
[04:08] <Keybuk> no, it has not
[04:09] <seb128> ok, so sorry for asking to bump the build priority, it'll be of no use for now :)
[04:11] <Kamion> doko: by the way, in case you're going round converting stuff to new python policy, please ignore oem-config*; oem-config itself is converted in bzr and the rest are going away
[04:12] <doko> Kamion: ok, thanks
[04:15] <slomo_> doko: gcc-4.1 4.1.1-8ubuntu1 FTBFS on ppc :(
[04:16] <doko> slomo_: yes, I see. looks like gnat doesn't like ssp ...
[04:16] <fabbione> so does amd64
[04:16] <doko> fabbione: no, something else
[04:17] <fabbione> so does amd64 + fail
[04:20] <bddebian> Kamion or Keybuk: gcl needs a rebuild.  Can you guys throw it up or should I just pull it add a build1 version and throw it back up?
[04:22] <Keybuk> bddebian: on which architectures?  I'm showing a successful build on i386, amd64 and sparc
[04:22] <bddebian> Keybuk: It built successfully, it just needs a rebuild against some newer libs
[04:23] <dholbach> ogra: no idea, sorry
[04:23] <Keybuk> bddebian: then you will need a new upload
[04:23] <dholbach> ogra: isn't 'ringing' enough? :)
[04:23] <bddebian> Keybuk: OK, thanks
[04:24] <ogra> dholbach, not in this house :) my office is upstairs and i like to work in the garden or in one of the balconies :)
[04:24] <dholbach> ogra: the laptop speaker will ring
[04:24] <ogra> dholbach, if i get a call on the desktop machine ? 
[04:25] <fabbione> ogra: can't you just close ekiga from the ws and open it on the laptop?
[04:25] <dholbach> ogra: you won't have run back in time, so you'd want to use ekiga on the laptop
[04:26] <bddebian> Damn, I swore I sent lightspeed up already..
[04:26] <ogra> sigh, ok, then i have to find out whats wrong with 2.6.17's usb-sound driver :)
[04:26] <Treenaks> *something about scratching one's own itch* :P
[04:30] <Gloubiboulga_> hello janimo 
[04:30] <bddebian> Hmm, I wonder how gcl built.  It FTBFSs for me
[04:30] <janimo> Gloubiboulga_: hi :)
[04:31] <janimo> Gloubiboulga_: I'll start on the xfce packages as I said on the list
[04:31] <Keybuk> raphink: note, it's generally a bad idea to set an importance on a sync request ;)
[04:31] <ogra> janimo, !!
[04:31] <ogra> welcome back !
[04:31] <Keybuk> raphink: we tend to just assume those on the bottom are the new ones
[04:31] <Gloubiboulga_> janimo, ok :)
[04:31] <Keybuk> raphink: setting a higher importance means that we miss them unless we're concentrating
[04:31] <janimo> ogra: thanks
[04:35] <raphink> Keybuk: ah ok :)
[04:35] <raphink> ic
[04:35] <raphink> so I just confirm it and subscribe you
[04:35] <raphink> thank you for the 3 syncs Keybuk :)
[04:47] <Gloubiboulga_> hm, the new goffice is built on LP but is not on the repos yet (it's been uploaded last week)
[04:47] <Gloubiboulga_> is there a problem somewhere?
[04:49] <slomo_> Gloubiboulga_: it's on binary NEW
[04:50] <Gloubiboulga_> ah ok, thanks slomo_ 
[04:52] <Keybuk> fabbione: X query, if you're there?
[04:53] <Keybuk> (or anyone, for that matter)
[04:54] <Keybuk> we have an xterm patch to put the manpage in 1 not 1x
[04:54] <Keybuk> do we still want that?
[04:54] <Keybuk> oh, ignore me, it changed upstream anyway
[04:55] <Keybuk> hmm, but Debian still has a patch to put it in 1x
[04:55] <Keybuk> ok, so do we want to keep Debian's 1x patch, or our (and upstream's) 1 ?
[05:01] <Kamion> Gloubiboulga_: I processed it through NEW this morning
[05:01] <Kamion> Keybuk: "put it in 1x" is ambiguous
[05:02] <Keybuk> Kamion: section
[05:02] <Kamion> Keybuk: there are (still) two things that could mean - either the directory (/usr/share/man/man1 is correct, /usr/share/man/man1x is wrong) or the filename (xterm.1.gz or xterm.1x.gz; I'd lean towards the latter but it's not critical)
[05:02] <Keybuk> filename
[05:02] <Keybuk> we and upstream call it xterm.1.gz
[05:02] <Keybuk> but Debian call it xterm.1x.gz
[05:02] <Keybuk> and it's a patch we deliberately dropped, fwict
[05:02] <Keybuk> I was wondering whether we still drop that
[05:02] <crimsun> I've been dropping it.
[05:03] <Kamion> Debian is arguably more correct here, though it's a nicety
[05:03] <Gloubiboulga_> Kamion, thanks, I shouldn't trust packages.u.c :)
[05:03] <Kamion> the directory is worth worrying about (and diverging from Debian if they get it wrong); for the filename, just going from minimal diff from our immediate parent is probably most sensible
[05:04] <Kamion> Gloubiboulga_: (on the one architecture where it built ...)
[05:04] <Kamion> https://launchpad.net/distros/ubuntu/+source/goffice/0.3.0-1ubuntu1
[05:04] <Kamion> the others were probably transient problems though
[05:05] <janimo> Gloubiboulga_: tried mailing goffice debian maintainer?
[05:05] <Kamion> janimo: what for?
[05:05] <janimo> so we don't carry the -gtk patch?
[05:05] <Gloubiboulga_> janimo, not yet, I was waiting to get goffice/gnumeric uploaded
[05:05] <janimo> Gloubiboulga_: ok, as he said he'd take it if it works in ubuntu.
[05:05] <Kamion> ah
[05:06] <Chipzz> so
[05:06] <Chipzz> is anyone bothering with evolution-exchange ?
[05:06] <Chipzz> apt-get dist-upgrade has been threatening me to remove it for over 3 days :P
[05:07] <Keybuk> Chipzz: define "bothering"
[05:07] <Hobbsee> Chipzz: is there a bug filed for it?
[05:07] <Hobbsee> heh
[05:07] <Keybuk> if you're complaining about a mere 3-day breakage in edgy, you're going to be ignored
[05:07] <Hobbsee> Keybuk: does "bothering" happen to include removing it from the archive?  that could be fun.
[05:07] <Hobbsee> Keybuk: break X on Chipzz in punishment hehe :P
[05:08] <Keybuk> Hobbsee: X isn't broken anyway?
[05:08] <gnomefreak> not yet
[05:08] <Chipzz> Keybuk: I think it needs a rebuild
[05:08] <Hobbsee> Keybuk: no, kdelibs4-dev is still installable today, so it cant be...
[05:08] <Chipzz> Keybuk: I assumed that no-one had noticed the breakage
[05:09] <Keybuk> Chipzz: edgy is mid-merge ... you're lucky if anything works
[05:09] <Hobbsee> Chipzz: --> launchpad and file a bug, if there's not already there == quickest and most useful way to tell someone.
[05:09] <Keybuk> Chipzz: you clearly don't need evolution-exchange, because you wouldn't run edgy on a box you need
[05:09] <Chipzz> Hobbsee: probably
[05:09] <gnomefreak> i think i saw a bug on it already
[05:10] <Hobbsee> well with logic like that.... :P
[05:11] <gnomefreak> Chipzz: this your issue too? https://launchpad.net/distros/ubuntu/+source/evolution-exchange/+bug/49142
[05:11] <Ubugtu> Malone bug 49142 in evolution-exchange "Could not connect to Evolution Exchange backend process" [Untriaged,Unconfirmed]  
[05:12] <Chipzz> # apt-get install evolution
[05:12] <Chipzz> The following packages will be REMOVED: evolution-exchange*
[05:12] <tseng> evolution-exhcange is built again "old" evolution
[05:12] <dholbach> Chipzz: that's edgy?
[05:12] <tseng> it needs rebuilt
[05:12] <Chipzz> tseng: that's what I said
[05:12] <Chipzz> dholbach: idd
[05:12] <Keybuk> tseng: it currently FTBS completely
[05:13] <tseng> Keybuk: *unsuprised8
[05:13] <tseng> Keybuk: took months to get evolution-sharp updated
[05:13] <Keybuk> this is a completely pointless discussion
[05:13] <Keybuk> it's edgy
[05:13] <Chipzz> the reason I'm "whining" is because in most cases breakage gets noticed and fixed really fast
[05:13] <tseng> yes, it really is
[05:13] <Keybuk> Chipzz: EDGY ... MERGES ... STFU :p
[05:13] <tseng> it is completely obvious to the developers
[05:13] <Chipzz> nm :P
[05:13] <dholbach> Chipzz: the whole stack is broken atm, and its being fixed - don't use edgy, if you can't live with breakage... sorry
[05:13] <Keybuk> Chipzz: we're not making any attempt to make anything build or be installable until after UVF
[05:14] <Chipzz> guys, I was merely pointing out that the package was broken in case no-one noticed yet; I really don't want this whole discussion ;P
[05:14] <infinity> doko: Did you drop the syck change that turned off optimisation in the testsuite?
[05:15] <infinity> Mithrandir: That was the fix for amd64, right?
[05:16] <doko> infinity: hmm, apparently
[05:17] <infinity> doko: Kay, I'm going to kill the amd64 build that's been spinning for the last hour, if you can upload a fix for me.
[05:17] <bddebian> ohh, hamlib failed to build, no wonder
[05:17] <Hobbsee> bddebian: ah, and that's why i cant seem to get to it.  excellent.
[05:18] <bddebian> Hobbsee: Aye :-)
[05:18] <bddebian> Hobbsee: I'm going to look at it now
[05:18] <Hobbsee> bddebian: cool :)
[05:26] <ogra> mumble, mumble ... 
[05:29] <Keybuk> ogra: you weren't the last to touch it, so stop grumbling ;P
[05:29] <ogra> Keybuk, well, i listed it on my "to merge" packages the last two meetings :P
[05:29] <Keybuk> ogra: any particular reason?  I made the changes to it
[05:30] <ogra> Keybuk, its in main for edubuntu, but i'm fine that you merged it 
[05:32] <bddebian> Is python2.3-dev borked in Edgy?
[05:32] <Kamion> ENOCONTEXT
[05:32] <bddebian> The following packages have unmet dependencies:
[05:32] <bddebian>   python2.3-dev: Depends: python2.3 (= 2.3.5-9ubuntu1) but it is not going to be installed
[05:33] <ogra> we have python 2.3 stuff in edgy ? 
[05:33] <Keybuk> bddebian: I believe your paste answers your own question
[05:34] <bddebian> Keybuk: Aye but I can't do anything about it
[05:34] <Kamion> bddebian: general method for investigating that kind of problem is to 'apt-get install' the thing(s) that it's complaining about explicitly, and iterate until you get to the thing that's actually broken
[05:34] <sivang> bddebian: all packages should use 2.4-dev, AFAICT, at least, all the apckages I have touched had patches to use 2.4-dev instead of 2.3-dev
[05:34] <mdke> pitti: in case you haven't seen it yet - https://lists.ubuntu.com/archives/ubuntu-translators/2006-July/000724.html
[05:34] <Kamion>  python2.3 |   2.3.5-14 | edgy/universe | source
[05:34] <Kamion> ^-- not built yet
[05:34] <bddebian> sivang: Agreed but hamlib specifically build-conflicts python2.4
[05:35] <sivang> bddebian: ah, then just wait for it to be built I guess
[05:35] <Kamion> doko: python2.3 2.3.5-14 ftbfs looks like a bug
[05:35] <sivang> bddebian: or build it yourself in the meanwhile..
[05:35] <Kamion> e.g. http://librarian.launchpad.net/3288053/buildlog_ubuntu-edgy-i386.python2.3_2.3.5-14_FAILEDTOBUILD.txt.gz
[05:35] <bddebian> Kamion: I know but I don't have an Edgy machine and pbuilder login is a pita :-)
[05:35] <Kamion> bddebian: that's nice
[05:35] <sivang> bddebian: use edgy :) I use it on my laptop
[05:36] <Hobbsee> bddebian: pbuilder login isnt *that* bad :P
[05:36] <bddebian> Hobbsee: No, works good it's just slow to setup/etc for a quick test :-)
[05:36] <Hobbsee> bddebian: that is true
[05:37] <Hobbsee> also
[05:39] <doko> Kamion: known, low prio at the moment
[05:39] <doko> pitti: tetex-extra fails to configure in dapper-updates
[05:40] <Kamion> doko: fair enough
[05:44] <Kamion> iwj: can your dpkg symlinks-to-same-directory file conflict patch go up to Debian, or is it too experimental/doubtful/broken?
[05:57] <iwj> Kamion: I think I already submitted it to the BTS with a note saying `please apply this'.
[05:57] <iwj> Let me check.
[05:59] <iwj> Hmm.  I can't seem to find a record of that.
[06:00] <pitti> mdke: yep, I investigated this today, and it's a complete miracle; build-langpacks.sh and apt-ftparchive DTRT when I run it manually, but fail when running from cron
[06:01] <pitti> mdke: I added some debug code to the script and will see what breaks tomorrow
[06:01] <pitti> mdke: but thanks for pointing out
[06:01] <pitti> doko: oh, with the tetex-bin in d-updates? is there any bug report for that?
[06:02] <iwj> Kamion: No, I seem to have omitted to do that.  But it should go to Debian and given the testing it's had since I invented it I'm confident in it.
[06:02] <iwj> Kamion: Do you want me to submit it ?
[06:02] <iwj> Sorry for not doing that sooner.
[06:03] <Kamion> iwj: sounds like a good idea; it's our last diff versus Debian
[06:03] <Kamion> (I just merged 1.3.22)
[06:03] <iwj> Right.
[06:04] <iwj> I'll do that now.
[06:04] <Kamion> thanks
[06:04] <Kamion> makes more sense coming from you than from this humble merge-monkey
[06:04] <iwj> *snort*
[06:04] <iwj> You mean `you have a chance of remembering what on earth it was all about'.
[06:05] <Kamion> that too ...
[06:06] <bddebian> merge-monkey?
[06:06] <doko> pitti: bug 52555
[06:06] <Ubugtu> Malone bug 52555 in tetex-base "tetex-extra failts to configure" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52555
[06:07] <pitti> doko: thanks, I'll check that in a clean chroot
[06:08] <gnomefreak> who maintains xservwer-xorg-core?
[06:09] <Hobbsee> gnomefreak: apt-cache show?
[06:09] <Kamion> ubuntu-x-swat
[06:09] <bddebian> Anyone know of a POSIX compliant version of this?  rm -f $${$@%.rm}
[06:09] <bddebian> Seems to fail on dash
[06:10] <Kamion> what does that even mean in bash? :)
[06:10] <Kamion> $@ being the positional parameters
[06:10] <bddebian> No freakin' clue :-)
[06:10] <bddebian> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376806
[06:10] <Kamion> looks like garbage to me; can you point me at the context?
[06:10] <Kamion> ah
[06:10] <Ubugtu> Debian bug 376806 in gcl "Subject: gcl: FTBFS: bashisms in debian/rules" [Important,Open]  
[06:10] <Kamion> oh, it's within a makefile
[06:10] <iwj> Ahhhh.
[06:11] <bddebian> Kamion: debian/rules to be precise
[06:11] <mdke> pitti: cool, thanks
[06:11] <iwj> ${<filename>%.rm}
[06:11] <Kamion> use make's own text-handling functions if you're working on a make variable
[06:12] <bddebian> iwj: rm -f $${$@%.rm} -> rm -f ${<filename>%.rm}  ?
[06:12] <iwj> bddebian: It's transformed like that by make.
[06:12] <pitti> bddebian: that won't work, you need $$ to escape the $ from make
[06:12] <bddebian> Hmm
[06:12] <iwj> You can see that in the bug report you reference.
[06:12] <Kamion> rm -f $(patsubst %.rm,%,$@)
[06:12] <iwj> ${...%...} is supported by SuSv3.
[06:12] <Kamion> pitti: it is, but var has to actually be a variable not random text
[06:13] <pitti> oh, heh, true
[06:13] <iwj> Oh, duh!
[06:13] <bddebian> Why not just rm -f debian/control.rm since that is all that is passed to it?
[06:14] <iwj> Don't ask me.
[06:14] <pitti> bddebian: maybe it's not 31337 enough?
[06:14] <Kamion> k
[06:14] <iwj> Why write what you mean in a makefile when you can make it (a) complicated, (b) wrong and (c) unportable all in one go ?
[06:15] <Kamion> $ echo ${foo.rm%.rm}
[06:15] <Kamion> -bash: ${foo.rm%.rm}: bad substitution
[06:15] <Kamion> bash does that too ...
[06:15] <LaserJock> iwj: lol
[06:15] <bddebian> Kamion: I know, it ftbfs'd for me to with bash :-)
[06:16] <bddebian> I wonder how it built on the buildd
[06:16] <pitti> bddebian: btw, this would be 'rm debian/control' (without the .rm), but this looks fishy, too :)
[06:16] <bddebian> Oh
[06:18] <Kamion> debian/control.rm:
[06:18] <Kamion>         rm -f $${$@%.rm}
[06:18] <Kamion> debian/control: debian/control.rm
[06:18] <Kamion>         cp debian/control.$(EXT) debian/control
[06:19] <Kamion> personally I'd do the patsubst thing and pray I never have to look at that makefile again
[06:19] <ogra> bddebian, as some buddhists say, to raise your karma ;)
[06:19] <bddebian> ogra: Well I'm stupid, I have too much going on in RL and I seem to piss -devels off :-(
[06:20] <pitti> Kamion: does it modify debian/control at all after copying it? on-the-fly debian/contol's are so evil...
[06:21] <Kamion> pitti: no idea, don't want to find out
[06:21] <sivang> pitti: I so much agree , they are EVIL
[06:22] <bddebian> So what should I do?
[06:23] <sivang> iwj: to win a write-once read-never content? :)
[06:23] <sivang> s/content/contest/
[06:23] <Kamion> bddebian: 17:19 < Kamion> personally I'd do the patsubst thing and pray I never have to look at that makefile again
[06:23] <bddebian> Kamion: OK, thx
[06:23] <pitti> bddebian: IMHO, the best would be to just create a static control and throw away all the rewriting stuff, if that's reasonable
[06:24] <pitti> bddebian: (depends on what this actually does to the .rm file to produce d/control)
[06:24] <bddebian> pitti: I will ask Debian maintainer to do so :-)
[06:24] <pitti> bddebian: yep, file a serious bug, that helps getting attention :)
[06:25] <Kamion> pitti: the .rm thing is just a magic target to arrange for debian/control to be removed (why bother? but hey); control.$(EXT) is the thing that actually gets copied
[06:25] <pitti> (... starts revolting?)
[06:26] <bddebian> This freaking thing takes forever to build too :-(
[06:26] <bddebian> OK, can I ask another question without getting lynched? :-)
[06:26] <Kamion> nobody lynched you
[06:27] <pitti> bddebian: no, we can't /msg you an ice cream, sorry
[06:27] <bddebian> heh
[06:27] <bddebian> Kamion: No, not on this, thank you all for the help, BTS
[06:27] <bddebian> Err BTW
[06:28] <bddebian> hamlib builds fine with python2.4 however it has a binary package python2.3-hamlib2.  Can I make that python2.4-hamlib2 or should I just wait for python2.3 to get fixed?
[06:28] <Kamion> python2.4-hamlib2 should be fine, but it should also be converted to the new python policy (which would make it python-hamlib2 once all the other necessary changes are made)
[06:29] <Kamion> but if you don't feel up to that, python2.4-hamlib2 is fine; just check reverse dependencies
[06:29] <bddebian> Well I would need to check reverse-deps if I did python-hamlib2 anyway wouldn't I?
[06:29] <Kamion> yes
[06:31] <bddebian> So if I did that, build-deps should just be python-dev and python not versioned right?
[06:32] <Kamion> bddebian: it's not that simple - see the new python policy
[06:32] <Kamion> it is not a cut-and-paste conversion
[06:32] <ogra> pitti, hmm, very intresting, my headset doesnt work with 2.6.15 either, seems gnome-sound-properties is automatically set back to the internal soundcard after 1-1.5mins
[06:32] <bddebian> OK, well this starts to lead into my issues.  How much do we stray from Debian?  This is always puzzling to me
[06:33] <Kamion> we want to convert everything to the new python policy; however there is a team in Debian actively doing the conversion so it may not be worth your while to learn how to do this one
[06:33] <sivang> Kamion: wouldn't be able to just sync up from debian once they have finished the conversoin?
[06:34] <pitti> ogra: the only thing that resets the default card known to me is gnome-volume-manager, when it sees that you just removed the default device
[06:34] <Kamion> sivang: yes
[06:34] <bddebian> sivang: Yes but it's holding up other merges/syncs
[06:34] <pitti> ogra: can you check whether the settings in ~/.asoundrc.asoundconf change after that time?
[06:35] <ogra> pitti, nope, they dont change
[06:35] <pitti> ogra: hm, then it's not g-v-m
[06:36] <ogra> !defaults.pcm.card Headset
[06:36] <ogra> defaults.ctl.card Headset
[06:36] <ogra> defaults.pcm.device 0
[06:36] <ogra> defaults.pcm.subdevice -1
[06:36] <pitti> ogra: g-s-p reads the default card directly from alsa normally
[06:36] <ogra> g-s-p shows "Snapper"
[06:36] <pitti> ogra: anything helpful in dmesg?
[06:36] <ogra> nope
[06:36] <ogra> neither in .xsession-errors
[06:36] <pitti> ogra: oh, Snapper? that's the internal card
[06:36] <ogra> yeah
[06:36] <ogra> it flips back to that after the time 
[06:37] <ogra> i can select the headset and hear sound again ...
[06:37] <ogra> then after 30sec up to 1.5mins it flips back again
[06:37] <sivang> bddebian: maybe we can just wait with those and stack them up, and then do them in mass once the transition is over?
[06:37] <pitti> ogra: do you have esd running?
[06:37] <pitti> ogra: do you get the same behaviour without esd?
[06:41] <dholbach> seb128: woohoo - seems like the 'themes' problem gets solved for us: some of the unmaintained themes were stripped from 2.15.4 :-)
[06:41] <pitti> ogra_: did esd kill your session? :)
[06:41] <ogra_> grmbl
[06:41] <ogra_> i hate hate hate broadcom
[06:41] <ogra_> no my regular 2h network crash happened
[06:42] <ogra_> thats definately my last apple
[06:42] <pitti> ogra_: it works just wonderfully here since pre-dapper...
[06:43] <ogra> pitti, hmm, now the headest is selected all the time if i start g-s-p but sound only comes out of the speakers ...
[06:43] <ogra> funny
[06:43] <ogra> aha
[06:44] <pitti> ogra: well, without esd you have to restart the player
[06:44] <ogra> but i get errors now 
[06:44] <pitti> ogra: esd can switch on the fly, but not apps using libasound directly
[06:44] <ogra> ALSA lib conf.c:3479:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
[06:44] <ogra> ALSA lib conf.c:3947:(snd_config_expand) Evaluate error: No such file or directory
[06:44] <ogra> ALSA lib pcm.c:2146:(snd_pcm_open_noupdate) Unknown PCM dmix:CARD=Snapper,FORMAT=S16
[06:44] <ogra> /usr/bin/esd: Kein Prozess beendet
[06:44] <ogra> funnily snapper is selected and plays sound :)
[06:45] <ogra> i see that error if i try to switch cards in g-s-p
[06:46] <ogra> not using esd doesnt change the bahavior btw, it still flips back to snapper
[06:52] <ogra> (oh and i'm using totem-gstreamer as player ... esd shouldnt affect that at all)
[06:55] <fabbione> Keybuk: i don't care.. personally. i would prefer to drop as much Ubuntu custom as we can and go Debian and iirc in dapper i did a last minute merge that was taking us very close to that
[06:56] <fabbione> Keybuk: *probably* we can just sync
[07:00] <Keybuk> fabbione: we have a bug-fix patch so we can't sync
[07:00] <fabbione> Keybuk: ok :)
[07:00] <Keybuk> and I got the patch from the Debian BTS in the first place, so it's not a candidate for pushing to Debian :p
[07:01] <bddebian> Boy that sounds familiar
[07:02] <fabbione> Keybuk: hehe
[07:02] <glatzor> ping doko
[07:03] <DaSkreech> Hello
[07:03] <DaSkreech> Who was working on the usplash for dapper?
[07:04] <glatzor> DaSkreech: artowrk or code?
[07:04] <glatzor> artwork
[07:04] <DaSkreech> Ermm code I should think
[07:05] <doko> glatzor: just speak up
[07:05] <DaSkreech> I wanted to find out why the countdown on shutdown was repalced with a countup
[07:06] <glatzor> Hi doko. I worked on gnome-app-install, that is written in python. I finally tested the app with atk enabled and it crashes with "Illegal instruction"
[07:07] <DaSkreech> Where can I find the changelogs so I can see if a reason was given?
[07:07] <doko> glatzor: nice :)
[07:08] <LaserJock> DaSkreech: http://changelogs.ubuntu.com/changelogs/pool/main/u/usplash/
[07:08] <glatzor> doko: I am on a dapper powerpc. Do you have got any idea? I found some older bug reports using google. But either they haven't been answered at all or wer closed with "we think the new version of python fixes this"
[07:08] <DaSkreech> LaserJock: Thanks
[07:08] <pitti> G0SUB: ping
[07:09] <doko> glatzor: are you able to verify on a non-powerpc architecture?
[07:09] <glatzor> doko: No :/
[07:09] <glatzor> But I could send the packages to anybody who is willing to help :)
[07:10] <doko> glatzor: then please submit a bug report, with a reduced testcase, if possible
[07:10] <pitti> mdz: ok to upload the cups regression (bug 52390) to dapper-updates?
[07:10] <Ubugtu> Malone bug 52390 in cupsys "cupsys 1.2.1-0ubuntu1 doesn't support 11.22.33.* network masks" [High,In progress]  http://launchpad.net/bugs/52390
[07:11] <glatzor> doko: I cannot locate the error exactly.
[07:21] <doko> mdz: https://wiki.ubuntu.com/OpenOfficeL10n is still open should be done.
[07:21] <Keybuk> pitti: ping? (re hal derooting)
[07:21] <pitti> hey Keybuk 
[07:22] <Keybuk> pitti: did we or Debian de-root hal?
[07:22] <pitti> Keybuk: I did the initial derooting back in warty
[07:23] <pitti> Keybuk: the current architecture (small master instance as root, main process as haldaemon) was done by Debian (sjoerd)
[07:23] <Keybuk> ok
[07:23] <Keybuk> so that would explain why n-m doesn't work properly a lot of the time :)
[07:23] <Keybuk> <policy user="hal">
[07:23] <Keybuk>      <allow send_destination="org.freedesktop.NetworkManager"/>
[07:23] <Keybuk>      <allow send_interface="org.freedesktop.NetworkManager"/>

[07:23] <Keybuk> ^ DanW says we need that
[07:23] <pitti> Keybuk: ooh
[07:23] <pitti> Keybuk: s/hal/haldaemon/
[07:24] <Keybuk> right
[07:24] <pitti> Keybuk: but the current derooting behavior is upstream since hal 0.5.7 (for quite a while now)
[07:25] <mdz> pitti: why does that patch use pointer arithmetic instead of simple array subscripting?
[07:25] <Keybuk> pitti: RH could be using older or re-rooted hal?
[07:26] <pitti> mdhow do you mean?
[07:26] <pitti> mdz: how do you mean?
[07:26] <seb128> dholbach: I know, that's a part of the changes we spoke with Thomas during GUADEC
[07:26] <seb128> dholbach: he wants to move the accessibility themes to the a11y capplet too
[07:27] <mdz> pitti: 
[07:27] <mdz> ++    unsigned val[4] ; /* IPv4 address values */
[07:27] <pitti> Keybuk: hm, RHEL certainly does, but fedora 4 should have the latest hal, too
[07:27] <mdz> ++    ipcount = sscanf(value, "%u.%u.%u.%u", val + 0, val + 1, val + 2, val + 3);
[07:27] <pitti> mdz: you mean &val[1]  instead of val+1?
[07:27] <mdz> pitti: yes
[07:27] <mdz> I see it is just renaming the variable and preserving the style of the old code
[07:27] <pitti> should be perfectly equivalent
[07:29] <pitti> mdz: I don't know the reason
[07:29] <mdz> it is, it's just a bit weird
[07:31] <mdz> doko: does oo.o use hunspell or myspell now?
[07:32] <pitti> mdz: uploaded, thanks for review; can you ack it in the queue in some minutes?
[07:32] <doko> mdz: hunspell, but myspell dicts still work
[07:57] <mdz> slomo_: is bug #52561 related to your changes?
[07:57] <Ubugtu> Malone bug 52561 in dbus "E: removing Assembly /usr/lib/mono/gac/dbus-sharp/0.60.0.0__9eef2692033670f5/ failed" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52561
[08:02] <ogra> grrr
[08:03] <ivoks> it's not edgy's fault! don't
[08:03] <ogra> it is !
[08:03] <ivoks> :)
[08:03] <DaSkreech> So that's why it's called kicking the bleeding edge habit
[08:03] <ogra> well, indeed i could blame the single apps ... like evo wiping my gpg keys 
[08:04] <ogra> or gstreamer or whatever for flipping soundcards all the time
[08:04] <ogra> or broadcom for building crappy wlan cards ...
[08:04] <ogra> but its so much easier to just blame edgy :P
[08:04] <pitti> ogra: the card is fine, curse at them for not releasing drivers or specs :)
[08:05] <ogra> pitti, well, i seem to be the only one where the card causes reboots and hardlocks
[08:05] <pitti> ogra: hm, true, maybe your's is indeed broken physically
[08:05] <slomo_> mdz: do you have mono-gac 1.1.13.8-1ubuntuX and cli-common 0.4.3?
[08:05] <ogra> intrestingly it doesnt work at all with the firmware of our fwcutter package 
[08:06] <ogra> i have to use the one from my os X cd
[08:07] <slomo_> mdz: and does the dll still exist?
[08:07] <ogra> pitti, no wired ethernet yet in this house
[08:09] <ivoks> ok, anyone interested in syncing inkscape from sid?
[08:09] <ogra> ivoks, didnt that happen last week already ? 
[08:09] <ogra> i think it ftbfs
[08:10] <ivoks> 0.43 is in edgt
[08:11] <ivoks> ah, source is 0.44
[08:11] <ivoks> hm
[08:12] <ivoks> sorry for distraction :)
[08:12] <ivoks> looks like libpango error
[08:12] <ogra> pitti, bug 52552, is there a way to get these .xml files into the langpacks ? 
[08:12] <Ubugtu> Malone bug 52552 in gcompris "only english or german descriptions displayed" [Untriaged,Rejected]  http://launchpad.net/bugs/52552
[08:16] <slomo_> mdz: also what was updated before in the same apt run?
[08:18] <pitti> ogra: no reasonable one ATM; why not just ship them in the application deb?
[08:21] <ogra> pitti, afaik they are in there ...
[08:22] <pitti> ogra: ah, I think the locales are just missing
[08:22] <pitti> ogra: you can't select Catalan if you don't have ca_ES.UTF-8 locale
[08:22] <ogra> yes
[08:22] <ogra> but the base language pack should have generated them
[08:22] <ogra> or am i wrong ? 
[08:22] <pitti> ogra: only if he actually had l-p-es installed
[08:23] <pitti> erm, l-p-ca, of course
[08:23] <ogra> what about his last comment ?
[08:23] <pitti> ogra: that sounds like a bug in gcompris proper
[08:23] <ogra> do we still support crappy UTF-8@euro stuff ? 
[08:23] <pitti> ogra: no, UTF-8@euro is evil
[08:24] <ogra> yeah
[08:24] <ogra> but he was offered it in gdm apparently
[08:36] <ogra> pitti, btw, if i use xmms to listen to music with direct alsa output, the sound stays at the headset, so i blame the gstreamer layer 
[08:38] <ogra> but why do we have a debian skin in xmms by default ? 
[08:53] <xhaker> ogra: looks kinda integrated in the distro.. nobody was poked to do a Human kin
[08:53] <xhaker> skin*
[08:53] <pitti> mdz: can you please release cupsys for dapper-updates?
[08:55] <ogra> xhaker, well, if i'd like blue and brushed metal i'd probably not use ubuntu :)
[08:55] <ogra> but i know there was a ubuntized theme for it ... i wonder where its gone
[08:59] <xhaker> ogra: http://anka.org/henrik/humanxmms/
[09:00] <xhaker> look nice
[09:00] <ogra> thats old, there was an updated one as well ..
[09:00] <ogra> but its ccbysa licensed, so we could include it ...
[09:12] <xhaker> bugger
[09:32] <bddebian> Damn, where'd everybody go? :-)
[09:32] <jjesse> we left
[09:33] <LaserJock> we are ignoring you
[09:35] <zul> all i hear is the basoon playing
[09:38] <HiddenWolf> sivang: ping: system-cleanup-tool, will you make sure it takes a look at ~/.thumbnails, please?
[09:49] <bddebian> LaserJock: Well that I would expect :-)
[09:49] <LaserJock> bddebian: lol, you know we love you ;-)
[10:00] <bddebian> LaserJock: YOU only love me 'cause I hit your Science packages ;-P
[10:01] <DaSkreech> Science Biology or science chemistry?
[10:01] <LaserJock> DaSkreech: Science science, but I prefer the chemistry kind ;-)
[10:01] <DaSkreech> Well as long as it's Science Fiction :)
[10:02] <LaserJock> bah
[10:03] <LaserJock> bddebian: how has the .desktop battle been going?
[10:09] <bddebian> LaserJock: Actually better than I expected.  Though I did have 1 DD ask "What is a desktop file?" :-)
[10:10] <seb128> bddebian: you do push .desktop patches to Debian?
[10:10] <bddebian> seb128: Yes, should I not be?
[10:10] <sivang> HiddenWolf: could you please add something about it to the spec proposal so I can merge and not forget about it? :)
[10:10] <seb128> bddebian: as said by mail I still think you lower the quality of the distribution because you ship something that works only for english people
[10:11] <seb128> bddebian: are you an english native speaker? or using an english locale?
[10:11] <HiddenWolf> sivang: sure
[10:11] <bddebian> seb128: Why do they only use English?  Desktop files can have translations
[10:11] <bddebian> I am a native English speaker btw
[10:11] <seb128> so you don't notice what you break
[10:12] <seb128> bddebian: for the reasons I mentionned by mail, it would require translators to open a bug every time they have an update, would force the maintainer to update the package everytime a translation needs to be changed
[10:12] <bddebian> seb128: As opposed to what?
[10:12] <seb128> bddebian: few people do track packages specific strings to translate them
[10:13] <seb128> opposed to people commiting to the upstream CVS which has a translation team
[10:13] <seb128> and having all the translations changed rolled with the new tarballs
[10:13] <seb128> system were translated can work directly
[10:13] <seb128> by opposition to opening 48 bugs and doing 48 uploads if you want to get 48 translations for your package 
[10:14] <seb128> by shipping a .desktop with the package you usually say you don't care about non-english desktops which will have that non-translated entry
[10:15] <seb128> because I doubt any maintainer is wanting to do receive a bug every time a translator has a typo to fix or a new translation
[10:15] <bddebian> seb128: No, by adding a .desktop file I say it can have a menu entry in Gnome or KDE instead of having to be started from a terminal session
[10:15] <seb128> let me start again
[10:15] <seb128> seems you missed the point
[10:15] <seb128> the place for that is *upstream*
[10:15] <seb128> upstream which has translations team
[10:16] <seb128> upstream where translators can work without opening bugs for the maintainer and requiring a new upload
[10:16] <bddebian> And if there is a new upstream "release" because of translations would it not require a new upload?
[10:17] <seb128> if you read upstream changelog you will notice "translations update" 
[10:17] <seb128> translations are updated with every new version
[10:17] <seb128> that's a part of the deal
[10:17] <seb128> translators can work between versions to fix whatever they want
[10:17] <slomo_> and normally there are no new versions just for new translations
[10:18] <bddebian> So are you also suggesting I should not be including them in Ubuntu packages until they come from Upstream?
[10:18] <seb128> right
[10:18] <bddebian> Works for me
[10:19] <bddebian> So I won't merge my desktop files from Dapper either?
[10:20] <seb128> have you read my mail on the list?
[10:20] <seb128> the decision is up to you, but I don't think that worth having to create a diff from Debian, especially because it's a non-translated item
[10:21] <seb128> that should be sent upstream and waiting for the next version is probably fine usually
[10:25] <bddebian> seb128: Then why did we have such a big push for desktop files?  Or was the intent from the get-go to get them upstream and I somehow missed that?
[10:26] <seb128> bddebian: because some MOTU guy decided that was a good idea
[10:26] <seb128> and made a wiki page
[10:26] <seb128> and other people decided to run with him on that
[10:27] <seb128> I already pointed the translations and diff work from Debian issues when you guys started
[10:27] <seb128> after that people do what they want ...
[10:28] <seb128> you can discuss than a non translated menu item is better than no menu item
[10:28] <bddebian> Well I somehow missed that so I apologize
[10:28] <seb128> but in any case such patches should go directly upstream
[10:28] <LaserJock> seb128: I was unaware of that (though it makes sense) but to a certain extent I feel it is bad for us to ship apps that don't show up in a menu
[10:28] <seb128> LaserJock: so send patches upstream
[10:28] <LaserJock> seb128: well, for some that might work, others unlikely
[10:28] <seb128> you work at the wrong place
[10:29] <LaserJock> seb128: your translation argument only works if upstream will translate it
[10:29] <seb128> no reason upstream would not accept it if that's a good idea
[10:29] <LaserJock> and is alive
[10:29] <seb128> if they don't you might ask yourself if you really need it
[10:29] <seb128> right
[10:29] <seb128> if you don't send it upstream so send it to Debian
[10:29] <seb128> so you don't create hundred of packages diffs due to that
[10:30] <LaserJock> right
[10:30] <seb128> and you make Debian people happier by sending back
[10:30] <seb128> and your reduce the MOTU workload
[10:30] <LaserJock> sure, that's what we are trying to do
[10:31] <pitti> slomo_: can you please commit your hal modifications into bzr?
[10:31] <seb128> LaserJock: cool then
[10:31] <LaserJock> I guess it's a matter of "get it in quick to Ubuntu, then send upstream and wait to sync" or "send upstream and wait for it to trickle down to Ubuntu"
[10:32] <seb128> some MOTU seem to not bother to "send upstream"
[10:33] <LaserJock> that, we are trying to correct, for sure. It is a bit of a learning process for some
[10:33] <seb128> cool :)
[10:38] <darius_> Alright, it's been over a month - must bring up bug # 30557 again
[10:39] <Mez> !bug 30557
[10:39] <Ubugtu> Malone bug 30557 in linux-source-2.6.15 "cpu idle time in /proc/stat wrong" [Medium,Confirmed]  http://launchpad.net/bugs/30557
[11:11] <mdz> pitti: will do
[11:13] <pitti> mdz: thanks