[12:03] <LaschW> jbailey: Hey, theres a thing I just comming into my mind...
[12:03] <LaschW> jbailey: I'm using xfs filesystem
[12:04] <LaschW> jbailey: /boot is ext2 all other partitions are xfs
[12:04] <seb128_> HiddenWolf: never
[12:04] <LaschW> jbailey: grub-install said:'Due to a bug in xfs_freeze, the following command might produce a segmentation
[12:04] <LaschW> fault when /boot/grub is not in an XFS filesystem. This error is harmless and
[12:04] <LaschW> can be ignored.'
[12:05] <LaschW> jbailey: Ccould this be the problem?
[12:05] <HiddenWolf> seb128_, ehm, 0.10 then?
[12:06] <seb128_> HiddenWolf: when it's here
[12:06] <Surak> Hiddenwolf: or even perhaps a 1.0 :-)
[12:06] <Surak> some day...
[12:07] <LaschW> jbailey: I was wondering about this grub-install message when I used it some month ago, because I don't get any segfaults. 
[12:07] <LaschW> jbailey: Seems that is the problem...
[12:07] <seb128_> HiddenWolf: we will not package 0.9 because it would mean extra work to rename packages and 0.10 is due first week of december
[12:07] <seb128_> HiddenWolf: so we will package 0.10 when there is tarballs
[12:09] <mdke> gnome-terminal is really not for public consumption
[12:09] <mdke> it has no preferences!
[12:13] <mdke> daniels, my hero *closes 20018 within 10 minutes of reporting it*
[12:14] <daniels> heh
[12:14] <daniels> i fixed the seeds just before
[12:15] <daniels> bzr get   18.72s user 1.50s system 0% cpu 38:21.08 total
[12:15] <daniels> daniels@ephemera:~/canonical/seeds% ls
[12:15] <daniels> whoohoo sftp transport
[12:15] <mdke> daniels, is that likely to be the same problem as #19641?
[12:15] <daniels> any breezy -> dapper DRI regressions will, at this point, be missing libgl1-mesa-dri
[12:16] <mdke> both are flight 1 installs
[12:16] <daniels> particularly if the X server log says that DRI's enabled
[12:16] <daniels> yeah
[12:16] <mdke> but with #19641 it doesn't seem to detect the card properly,it just says "generic intel" or something
[12:17] <LaschW> jbailey: Pardon me making this useless noise, and thank you for your help. Wolfgang
[12:18] <daniels> mdke: yeah, generic intel is okay
[12:18] <daniels> mdke: there are a few intel pci ids I haven't caught on to yet in discover1-data
[12:18] <mdke> aha
[12:18] <seb128_> daniels: is the xkb bug you fixed with -updates supposed to be fixed with dapper now?
[12:18] <mdke> daniels, i don't remember if it was like that already with Breezy or not
[12:19] <daniels> seb128_: think so, yeah
[12:19] <daniels> seb128_: #15372
[12:19] <jbailey> LaschW: Sorry about the lag, I'm more away from my computer than at it atm.
[12:19] <daniels> mdke: pretty sure discover1-data hasn't regressed any
[12:19] <seb128_> daniels: oh, but it didn't build yet I guess?
[12:19] <mdke> daniels, i'll check it out
[12:19] <daniels> seb128_: pretty sure I uploaded it ages ago
[12:19] <daniels> xkeyboard-config (0.6-8) dapper; urgency=low
[12:20] <daniels>   * Add level3(ralt_switch_for_alts_toggle), which maps RALT to
[12:20] <daniels>     [ l3switch, group_next ] , which is the desired behaviour for a three-level
[12:20] <daniels>     keyboard with multiple layouts present (see below).
[12:20] <daniels> [...] 
[12:20] <daniels>  -- Daniel Stone <daniel.stone@ubuntu.com>  Mon, 10 Oct 2005 15:41:08 +1000
[12:21] <jbailey> seb128_: Is ephy in the queue for things to fix, or does it need other love to make it work?
[12:21] <seb128_> jbailey: it needs a firefox building
[12:21] <seb128_> jbailey: the only version which built was the broken one
[12:22] <jbailey> *lol*
[12:22] <seb128_> gcj broke the archive just after that
[12:22] <seb128_> and Diziet forgotten a Build-Depends then
[12:22] <jbailey> Right.
[12:23] <jbailey> So hopefully it'll sort itself out pretty quickly then, I won't mess things up by adding another body.
[12:23] <seb128_> forget
[12:23] <jbailey> I'm just without my saved bookmarks and passwords, so I might build it locally in the meantime. =)
[12:24] <seb128_> what I did
[12:24] <seb128_> I could work efficently without it
[12:24] <seb128_> I've my toolbar with all the entries to put bugzilla, etc bug numbers
[12:24] <mdz> daniels: http://people.ubuntu.com/~lamont/buildLogs/x/xorg-server/1:0.99.3-0ubuntu1/xorg-server_1:0.99.3-0ubuntu1_20051123-2232-i386-failed.gz
[12:24] <seb128_> my bookmarks, passwd
[12:26] <jbailey> seb128_: That's in ephy or ff?
[12:26] <seb128_> epiphany for me
[12:26] <seb128_> I've spent 2-3 hours to fix firefox/rebuild epiphany yesterday morning
[12:27] <jbailey> Oh btw, did I tell you the answer to the freecell problem is either to make threads work on guile for ppc and amd64 or is to convince the gnome-games maintainer that perhas freecell doesn't need to be threaded? =)
[12:27] <seb128_> no
[12:27] <seb128_> you said that you were going to fix guile *g*
[12:28] <LaschW> jbailey: No problem, you saw my posting about xfs filesystem and grub-install?
[12:28] <jbailey> Well, more that I went looking for the problem in guile.
[12:28] <\sh> bah..ace is a bitch
[12:28] <jbailey> seb128_: Part of the problem is that quickthreads is going away in 1.8 in favour of a proper pthreads implementation.  But it's not do out until well after UVF
[12:29] <jbailey> s/do/due/
[12:30] <jbailey> LaschW: Yeah.  I don't thin kit would matter much.
[12:30] <jbailey> LaschW: Usually boot loader problems result in nothing working, rather than partially working.
[12:30] <jbailey> The boot cycle isn't resiliant. =)
[12:31] <jbailey> All that initramfs-tools has done is provide a better best-effort case for booting.
[12:31] <LaschW> jbailey: May it be worth posting it at ubuntu-users, a short description of the problem and the sollution?
[12:32] <jbailey> I think I'm confused.
[12:32] <jbailey> Did you find a solution?
[12:32] <LaschW> jbailey: I don't think it's worth a bugzilla report
[12:32] <jbailey> Well, you should never see the words 'segmentation fault' at boot time.
[12:32] <seb128_> daniels: does "setxkbmap -model pc105 -layout 'fr' -print | xkbcomp - :0.0" work for you?
[12:32] <jbailey> If nothing else, it's hard to localise. =)
[12:33] <LaschW> jbailey: Yepp, the segfault messages come due an ext2 /boot partition and all other partitions beeing xfs filesystems
[12:33] <jbailey> That still really doesn't make any sense.
[12:33] <jbailey> That's a reasonably supported cas.
[12:33] <daniels> zell; if by zorks you ,eqn gives ,e azerty; then yeqh
[12:34] <daniels> i think it does zhqt its supposed to do
[12:34] <seb128_> X Error of failed request:  BadValue (integer parameter out of range for operation)
[12:34] <seb128_>   Major opcode of failed request:  148 (XKEYBOARD)
[12:34] <seb128_>   Minor opcode of failed request:  9 (XkbSetMap)
[12:34] <seb128_>   Value in failed request:  0x16710002
[12:34] <seb128_>   Serial number of failed request:  77
[12:34] <seb128_>   Current serial number in output stream:  83
[12:34] <seb128_> 
[12:34] <seb128_> here
[12:34] <daniels> can you please put the output of setxkbmap -model pc105 -layout fr -print | xkbcomp -xkb - -, somewhere for me?
[12:36] <seb128_> daniels: xkb on chinstrap
[12:39] <daniels>         symbols[Group1] = [       KP_Divide,     XF86_Ungrab ] 
[12:39] <daniels> at a guess
[12:39] <daniels> does disabling the allowclosedowngrabs thing help?
[12:40] <daniels> okay, so I can't see what it's actually BadValue'ing to, so I'll have to hav ea closer poke at it
[12:40] <\sh> g'night all....
[12:40] <daniels> can you tar up /etc/X11/xkb?
[12:46] <seb128_> daniels: sure
[12:46] <dholbach> good night everybody
[12:46] <mdke> night
[12:47] <seb128_> 'night dholbach
[12:47] <mdke> i would like to see gnome-terminal replaced with something better in Ubuntu and/or gnome itself. How remote are the chances? out of 1000
[12:47] <seb128_> daniels: xkb.tar.gz same place
[12:48] <daniels> seb128_: thanks man
[12:48] <daniels> mdke: define 'better'
[12:48] <seb128_> daniels: thank *you*
[12:48] <mdke> daniels, well one which is being maintained. one which is faster, maybe even one which has the preferences under "edit->preferences"
[12:49] <seb128_> mdke: what is wrong with g-t ?
[12:50] <mdke> seb128_, i think it is very difficult for new users to find the preferences. also it is slow, and apparently (from what I am hearing now in #gnome), it is unmaintained
[12:51] <seb128_> mdke: new users don't use a command line, preferences are in the edit menu ... if that's just matter of changing a label that's trivial; slow is a troll
[12:52] <seb128_> mdke: unmaintained is half true, official maintainer is not responsive but some other people commit patches, roll tarballs, etc
[12:56] <mdke> yeah speed is not an issue for me
[12:57] <seb128_> the only issue is that "preferences" is called "profile"
[12:57] <seb128_> and you want to make a new app only for this? :p
[01:04] <mdke> seb128_, if someone will fix it, I'm happy
[01:04] <mdke> seb128_, but it seems it is not as simple as a name change
[01:08] <seb128_> changing the name of this entry is trivial
[01:08] <seb128_> they just want to do other change too upstream
[01:11] <daniels> seb128_: hmmmmmmm.  even blasting your xkbcomp'ed stuff at my server is fine, but my server's still stock.
[01:18] <slomo> elmo: please sync libgdiplus from debian/unstable... ubuntu changes can be dropped
[01:55] <daniels> \sh_away: you probably want to change that maintainer field to you
[02:16] <jbailey> Yay, working ephy again.
[02:34] <Graider> I've been testing Ubuntu among myself and my neighbours for use at a community centre. I just have the suggestion that xfe (file manager) be included in the default ubuntu install. The file manager makes things a LOT less scary to the windows convert
[02:36] <daniels> nautilus is already there for managing files
[02:36] <mjg59> Graider: In Nautilus, select "view as list" from the view menu
[02:40] <Graider> okay. now I feel a little stupid. Here I was thinking I was offering a useful suggestion and it turns out it's already covered. :) okay. well I still like xfe myself, but I suppose that's just choice
[02:41] <Graider> sorry to have bothered you :)
[02:41] <crimsun> win 21
[02:41] <crimsun> err, sorry.
[05:46] <infinity> daniels : No pressure, but it looks like now that xorg-server is finally buildable, pretty much everything else with "xorg" in the name is FTBFS.
[05:46] <elmo> MAXIMUM PRESSURE
[06:16] <infinity> elmo : Can libroken16-heimdal move to main, pretty please?
[06:19] <elmo> infinity: done
[06:20] <elmo> also, fyi, I did a rene run, which in retrospect was less than clever, but, *shrug*
[06:21] <infinity> Heh.
[06:24] <Lathiat> heh
[06:31] <shadeofgrey> hello everyone
[06:32] <mdz> infinity: what are the other xorg failures about?
[06:32] <shadeofgrey> i just felt like it was appropriate for me to stop by before turkey and the like to say...  thanks for everything.  if it werent for you and what you do, id still be a windows slut like every other loswer out there without the balls to stand up to the likes of billy and his drones
[06:32] <infinity> mdz : Mostly looks like missing build-deps, I'll tackle some of them in a bit if Daniel isn't available to do so.
[06:32] <mdz> shadeofgrey: :-)
[06:32] <shadeofgrey> so anyway..  thanks for ubuntu.  from the bottom of my disabled heart, thanks...
[06:33] <shadeofgrey> ill.. be getting out of your way now.
[06:33] <shadeofgrey> uh..  oh yes...  and theres this matter of a pretty serious bug i found in breezy
[06:34] <shadeofgrey> either that or its a hardware glitch of some kind
[06:34] <shadeofgrey> anybody have aminute to speak with me about it?
[06:34] <shadeofgrey> if not...  i understand.  i know im not a coder and not supposed to be here..
[06:35] <zakame> hello all
[06:35] <infinity> shadeofgrey : We'd appreciate a bug being filed.
[06:36] <infinity> shadeofgrey : But if you want a quick appraisal of "is this even a bug at all?", you can /msg me.
[06:36] <infinity> shadeofgrey : But you'll have to mail me a slice of pumpkin pie.
[06:36] <shadeofgrey> infinity:  i know nothing of how to properly file a bug...  in fact, im not even sure it IS a bug...  thats why i wanted to talk to somebody that really knows the kernel and all that...
[06:36] <shadeofgrey> ah excellent
[06:46] <daniels> mdz: build-deps new in rc2. will be sorted in uploads tomorrow.
[06:49] <fabbione> hey daniels 
[06:49] <fabbione> daniels: how is going the build for modular?
[06:50] <infinity> elmo : Meh, looks like libgssapi4-heimdal also wants to move to main.. .(can you check and see if anything else from the heimdal source looks like it's trying to move too?)
[06:55] <daniels> fabbione: server is fine, all the modules are ftbfs
[06:55] <fabbione> daniels: SCORE
[06:56] <daniels> kem went through and added a bunch of new b-ds right before rc2
[06:56] <daniels> i've got it in hand, but have family commitments tonight, so it'll be about 18h or so
[06:59] <jdub> mdz: holy crap :-)
[06:59] <Treenaks> jdub: morning
[06:59] <mdz> jdub: heh, the video clip?
[06:59] <jdub> yo!
[06:59] <jdub> mdz: haven't looked -> look at my hostname :-)
[07:00] <fabbione> daniels: ehhe
[07:00] <fabbione> hey jdub 
[07:00] <jdub> mdz: haha
[07:00] <daniels> anyway
[07:00] <mdz> jdub: !
[07:01] <jdub> mdz: i got off the phone, looked at the light, and it was on!
[07:02] <jdub> which means it came on while we were talking
[07:02] <jdub> you have the magic touch!
[07:06] <tritium> jdub, did you ever make it to NV or San Francisco?
[07:07] <jdub> tritium: nup
[07:07] <infinity> mdz : Oh, I didn't notice elmo went to sleep.  Can you promote libgssapi4-heimdal to main?
[07:08] <tritium> jdub, well, glad I didn't miss anything, in that case
[07:08] <infinity> mdz : Built from the heimdal source, newer heimdal-dev depends on it.
[07:08] <jdub> tritium: see my blog re: going to portland though
[07:08] <Burgundavia> infinity, elmo infinity: done
[07:08] <Burgundavia> elmo also, fyi, I did a rene run, which in retrospect was less than clever, but, *shrug*
[07:08] <tritium> jdub, ok, thanks
[07:08] <mjg59> Wah.
[07:08] <mjg59> I sent a load of patches to LKML, and now I want instant feedback gratification.
[07:09] <infinity> Burgundavia : That was for a different lib.
[07:09] <infinity> Burgundavia : But thanks anyway.
[07:09] <Burgundavia> infinity, oh, am tired
[07:16] <floam> I know about dapper-changes, but is there a way to check out the progress of stuff after it has been accepted? for instance, a lot of the new x11 seems still to not have been built, it would be nice if there was an automated thing one could check
[07:17] <tseng> people.ubuntu.com/~lamont/buildLogs/byDate/today.html
[07:17] <floam> aha
[07:17] <floam> excelent
[07:18] <floam> wow, mostly failed. I'm suprised it's not the other way around
[07:18] <tseng> it will turn around eventually
[07:19] <infinity> Mostly failed due to the fact that I retried everything that had previously failed.
[07:19] <infinity> That never goes well. :)
[07:20] <lamont> elmo: bld-4 should be flowing packages towards the archive
[07:21] <floam> seems like most of the hyperlinks lead to 404's
[07:21] <floam> you've got to go to up a few directories and then track the packages down manually
[07:21] <floam> s/packages/logs/
[07:22] <infinity> Curious.  Blame lamont, it's his script. :)
[07:23] <mdz> infinity: done
[07:23] <lamont> floam: example?
[07:24] <infinity> mdz : Many happy returns.
[07:24] <floam> interesting
[07:24] <lamont> hrm
[07:24] <floam> lamont: maybe s/most/the one I tried twice/
[07:24] <floam> let me figure out which that was
[07:25] <lamont> infinity: you flooded me with enough logs that the rsync is now 17 minutes in....
[07:25] <lamont> and still going.
[07:25] <lamont> floam: give it a while, and the rsync will finish.
[07:26] <floam> ah.
[07:26] <floam> that would make sense
[07:26] <lamont> then again, it could just be a function of the size of things.
[07:26] <floam> I was sure most at one spot weren't working, but then they were a few mintues later
[07:26] <infinity> lamont : \o/
[07:27] <floam> I started to think I was going nuts so I ran it's dead link checker on it
[07:27] <fabbione> maswan: ping?
[07:27] <lamont> floam: currently 7GB in the tree, give or take a little
[07:44] <floam> have you guys ever considered using tinderbox?
[07:44] <pitti> Good morning
[07:45] <lamont> floam: can't remember if that's one we looked at and ran away from, or not.
[07:45] <lamont> url?
[07:45] <infinity> tinederbox wouldn't really suit our needs.
[07:46] <floam> lamont: http://www.mozilla.org/tinderbox.html
[07:46] <floam> it does do more than you need, I am sure
[07:46] <floam> I just like it's cute little build tables
[07:46] <floam> ex. http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey
[07:47] <lamont> floam: yeah - it does about 10 times what we need, and doesn't do a couple things we do need.
[07:47] <infinity> And simple tables of build log stuff isn't terribly difficult for us to do either, we just don't.
[07:47] <lamont> major re-engineering job if we wanted to use it, and launchpad is already doing next-gen buildd, so no reason to reinvent the wheel, since debian's wanna-build/buildd/sbuild does a fine job of specifically doing everything we need, nothing more or less
[07:48] <infinity> (We do so in Debian, but we've never gotten around to doing it in Ubuntu, because we have a complete rewrite of how we do buildd stuff going on in Launchpad)
[07:48] <lamont> it was on someone's todo list for a few months...
[07:48] <lamont> starting with rewriting said code from PHP into python
[07:48] <lamont> (the debian build-logs stuff that is)
[07:49] <infinity> The stuff at cerberus.0c3.net would be handy too.
[07:49] <lamont> ~lamont/buildLogs was a temp hack to give us something for the "couple weeks" until the code was ready to go production elsewhere...
[07:49] <infinity> Actually, I should just run that code against the Ubuntu lists.
[07:49] <lamont> that was during warty.
[07:49] <infinity> Stupid me.
[07:49] <lamont> infinity: iz php code.  run screaming
[07:50] <infinity> lamont : No it's not.
[07:50] <lamont> ah, then that was something else...
[07:50] <lamont> buildd.debian.org scriptage
[07:50] <infinity> lamont : It's REXX.  Stare in shock and awe, THEN run screaming.
[07:50] <infinity> Yeah, buildd.debian.org is in PHP.
[07:53] <lamont> that was the original "gonna rewrite this in something sane" thing
... I kept meaning to rewrite the REXX stuff in shell or python, or anything other than REXX, but there aren't enough non-work hours in the day.
[07:55] <infinity> Woo, this instills confidence!
[07:55] <infinity>   * Compatibility with Linux 2.6.15 - may result in random breakage
[07:55] <infinity>     since it now has the ability to write to RAM the kernel may be using
[07:58] <floam> so it looks like all that x11 stuff is pretty dead. I got bit a few hours ago because xserver-xorg-core got built, but nothing else
[07:58] <floam> X11 went poof until I reverted
[07:59] <crimsun> I bet you used dist-upgrade, eh?
[07:59] <floam> ?
[08:00] <floam> crimsun: I've been on dapper just fine for quite a few days
[08:00] <infinity> Hrm, no it doesn't take a dist-upgrade to upgrade xserver-xorg-core.
[08:00] <crimsun> infinity: hmm, I haven't been bitten
[08:00] <crimsun> (I also haven't updated, but that's another story)
[08:00] <infinity> Restart GDM. :)
[08:00] <floam> crimsun: according to the build logs, xserver-xorg-core is the only part of the 7.0rc to have built successfully
[08:00] <floam> so you're stuck with a new that, but everything else is old
[08:00] <floam> it's unable to find any modules, among other issues
[08:02] <infinity> Whee.  I guess that makes getting the rest of X building a bit more urgent.
[08:03] <Keybuk> Dear daniels, dpkg-buildpackage also has a -b option
[08:03] <floam> nah, I'm sure it's a good thing. You can weed out all the people that will be whining about how terrible dapper is early
[08:04] <Keybuk> the trouble with that is we also end up weeding out all the people who'd file useful bug reports
[08:04] <Keybuk> and end up with what happened for breezy, when it first got really tested at beta
[08:06] <floam> it seems like a lot of stuff gets reported on those webforums but not in bugzilla
[08:06] <floam> it might be useful if there was big angry text telling people not to do that, since it seems a lot of it goes unnoticed
[08:06] <pitti> infinity: can you please release the dep-wait of cyrus-sasl2? it waited for the new heimdal, which is now available
[08:10] <sivang> morning
[08:11] <marilize> morning
[08:12] <sivang> morning marilize 
[08:12] <infinity> pitti L It's building already.  You're too slow. :)
[08:12] <marilize> sivang: :)
[08:12] <pitti> infinity: great, thanks!
[08:15] <Keybuk> floam: that's not actually too bad, in most cases the bugs find their way into Bugzilla; usually better written or more succinct than the original forums posts
[08:16] <Keybuk> multiple rumours of reports which eventually coalesce into a bug are better than multiple bad bug reports
[08:16] <pitti> doko: ping
[08:22] <Burgundavia> Keybuk, you seen that knoware project out of KDE?
[08:31] <Keybuk> Burgundavia: no?
[08:32] <Keybuk> cute
[08:34] <Burgundavia> Keybuk, basically collabrative bug reporting 
[08:38] <sivang> ah, it's not
[08:39] <sivang> Burgundavia: thanks for the links
[08:41] <nomed> i see there are issues with radeon driver for some ATI cards
[08:42] <nomed> i would just tell you it seems an issue related to mtrr and adresses assigned
[08:49] <Burgundavia> sivang, both the backup programs that google funded were written in pyGTK
[08:53] <sivang> Burgundavia: I know, currently checking PyBackBack. Still, so buggy...
[08:54] <Burgundavia> sivang, most of the google soc stuff is buggy
[08:54] <Burgundavia> the tight time constraints made them so
[08:54] <Burgundavia> sadly most of the code is simply going to bitrot too
[08:54] <sivang> Burgundavia: it's unmaintained?
[08:55] <Burgundavia> sivang, afaik, yes
[08:57] <sivang> Burgundavia: might be good for GUI ideas though :-)
[08:59] <sivang> That is , if I'll get this thing to run. Seems to be havin a setup.py problem
[09:03] <pitti> Hi carstenh 
[09:25] <carstenh> hi pitti 
[09:26] <fabbione> pitti: ping?
[09:26] <pitti> Good morning Mr. Nitto
[09:26] <fabbione> Mr Pitt
[09:26] <fabbione> pitti: are we trying to kill libreadline4 by any chance?
[09:26] <pitti> fabbione: yes, we do
[09:26] <fabbione> pitti: ok
[09:27] <fabbione> i assume we are going for 5, right?
[09:27] <pitti> fabbione: right
[09:27] <fabbione> oky doky
[09:27] <pitti> fabbione: only two packages left that use 4 (quagga and lua50)
[09:28] <fabbione> pitti: and tftp-hpa
[09:28] <fabbione> that i am killing now
[09:28] <pitti> fabbione: oh, I meant 'in main'
[09:28] <fabbione> it's in main
[09:29] <pitti> oh, then why didn't it appear in melanie? odd...
[09:29] <pitti> fabbione: it doesn't depend on readline???
[09:29] <pitti> Package: tftp-hpa
[09:29] <pitti> Depends: libc6 (>= 2.3.4-1)
[09:29] <fabbione> hmmm weird
[09:29] <fabbione> but it's a B-D
[09:29] <pitti> oh, build dependency, sorry
[09:29] <fabbione> ok i will check on that
[09:30] <pitti> it seems that elmo's magic scripts don't catch those
[09:30] <fabbione> well if B-D it should also at least Depends: on it
[09:30] <pitti> fabbione: maybe the b-d is superfluous?
[09:30] <fabbione> what's the name of that spec again?
[09:30] <fabbione> pitti: yeah that's what i want to check
[09:30] <fabbione> kill-duplication?
[09:30] <pitti> https://wiki.ubuntu.com/DapperDuplicatedPackages
[09:31] <pitti> fabbione: well, that's the plan; the spec is separate: https://wiki.ubuntu.com/ReducingDuplication
[09:31] <pitti> the latter lists the goals, the former the concrete steps for dapper
[09:31] <fabbione> impressive
[09:31] <fabbione> it B-D on it, but it configure with --disable-readline
[09:32] <pitti> lol
[09:33] <pitti> fabbione: ah, look at the description
[09:33] <pitti> The source includes readline
[09:33] <pitti>  support but it is not enabled due to licence conflicts between
[09:33] <pitti>  the BSD advertising clause and the GPL.
[09:34] <pitti> fabbione: that seems to be a common problem with bsd licensed stuff, postgresql has it as well
[09:34] <fabbione> pitti: ok.. B-D killed.. kthxbye
[09:34] <fabbione> hey sabdfl 
[09:34] <pitti> great
[09:34] <pitti> Hi sabdfl 
[09:35] <mvo> morning sabdfl 
[09:35] <fabbione> Keybuk: what's the best practise to close mom bugs, so that they can be reopened again properly by the script?
[09:35] <fabbione> Keybuk: -> RESOLVED FIXED?
[09:35] <sabdfl> howdy all
[09:35] <Keybuk> yes
[09:35] <fabbione> Keybuk: thanks
[09:35] <siretart> morning sabdfl!
[09:36] <Keybuk> though mom is running right now
[09:36] <Keybuk> uh, ISN'T running
[09:36] <fabbione> Keybuk: no biggie
[09:38] <sivang> yo sabdfl 
[09:39] <infinity> pitti / fabbione : License issues with readline can be worked around with editline, if anyone feels the urge.
[09:40] <fabbione> infinity: i don't think we need that for a tftpd
[09:40] <fabbione> really
[09:40] <infinity> Oh, I didn't read enough backscroll.
[09:40] <infinity> Why the heck would tftpd need/want readline support at all?
[09:40] <fabbione> infinity: dunno...
[09:41] <fabbione> probably the client
[09:41] <\sh> x-b0rkness...I missed that a couple of months now...back to console :=
[09:41] <fabbione> is katie running?
[09:41] <fabbione> or lists are down?
[09:42] <fabbione> i don't see a single mail to -changes since 5:50 am
[09:42] <fabbione> 4 hours ago
[09:42] <fabbione> brb
[09:45] <infinity> Okay, I think I got all the missing deps.  We'll find out...
[09:52] <fabbione> jdub: are lists down?
[09:53] <Mithrandir> doko: I'll reassign my libmusicbrainz merge bugs to you, if that's ok?  You listed yourself on the allocator change mail.
[09:57] <infinity> Alright, with my xorg-server upload, all the drivers except via should build...
[09:57] <infinity> (via seems gto want a newer libdrm than we currently have in the archive)
[09:59] <fabbione> infinity: i assume you mean DON'T have
[10:00] <dholbach> good morning
[10:00] <sivang> morning dholbach 
[10:01] <dholbach> hi sivan
[10:01] <doko> Mithrandir: ok
[10:01] <infinity> fabbione : No, I meant it how I typed it, it just wasn't itaglish friendly. :)
[10:10] <BROKEN_LADDER> quick question that i'm only asking here because it's a last resort.  where are the ubuntu default settings, governing theme and such, stored prior to any personalized settings in ~/ ?  i want to eradicate the brown theme from my system, and any new users, without resorting to editing /skel
[10:11] <pitti> BROKEN_LADDER: /usr/share/gconf/schemas/ IIRC
[10:11] <pitti> BROKEN_LADDER: but you should not change these
[10:11] <pitti> BROKEN_LADDER: since they are overwritten by subsequent package installs
[10:11] <pitti> BROKEN_LADDER: take a look at sabayon
[10:12] <BROKEN_LADDER> package installs change that?
[10:12] <pitti> BROKEN_LADDER: sabayon is what you want; please move over to #ubuntu (I'm there, too)
[10:12] <BROKEN_LADDER> i was already in #ubuntu
[10:29] <doko> Kamion, mdz: please promote these binary packages to main: libarts1c2 libboost-python1.33.0 libcppunit-1.10-2c2a libenchant1c2a libmagick++9c2a libmusicbrainz2c2a libmusicbrainz4c2a libsigc++-2.0-0c2a libopenexr2c2a libpcre3c2a libpt-1.8.3c2a libtag1c2a
[10:29] <BROKEN_LADDER> can i please choke whomever made smeg?
[10:29] <Kamion> doko: not until I've unbroken the overrides
[10:29] <BROKEN_LADDER> it won't let me edit the layout of the menu for the "predefined" titles.  i can't change accessories to ACCESSORIES
[10:30] <BROKEN_LADDER> anyone know a way around this?
[10:30] <Kamion> hooray, cron.unchecked actually finished this time
[10:31] <floam> BROKEN_LADDER: you should really be asking in #ubuntu, on the mailing list, or on the forums
[10:31] <Kamion> or file a bug on alacarte (smeg's new name)
[10:31] <floam> BROKEN_LADDER: and I'm able to rename Accessories just fine in smeg
[10:32] <floam> 0.7.5
[10:32] <Kamion> doko: a number of those are already in main. Are you going by mdz's anastacia output?
[10:33] <Kamion> doko: if so, don't bother yet, I'll do a cron.sync run in a moment
[10:34] <Kamion> and I'll promote all the c2a stuff
[10:36] <BROKEN_LADDER> i have 0.7.5
[10:36] <floam> BROKEN_LADDER: just right click on a category and hit properties
[10:36] <BROKEN_LADDER> floam but does it actually affect what you see in your menu?
[10:36] <BROKEN_LADDER> changing that doesn't actually do anything though in the real world.
[10:36] <fabbione> BROKEN_LADDER: please move to #ubuntu
[10:37] <fabbione> this is not a support channel
[10:37] <floam> BROKEN_LADDER: looks like it does not, go ask in #ubuntu how to edit .desktop files
[10:37] <BROKEN_LADDER> so asking developers is bad when you've exhausted all other resources for weeks on end?
[10:37] <floam> BROKEN_LADDER: you have? have you filed a bug yet? What about the mailing list?
[10:37] <floam> BROKEN_LADDER: Web forums?
[10:38] <floam> there are many resources
[10:39] <dholbach> BROKEN_LADDER: if you feel it's a bug, file a bug report
[10:40] <BROKEN_LADDER> dholbach i don't have any indication that it's a bug.  i'll just keept plugging away on the forums and in #ubuntu.
[10:40] <BROKEN_LADDER> it seems obviously to be intentional.  why else would it only affect folders that are predefined?
[10:40] <dholbach> BROKEN_LADDER: you could file a support request on http://launchpad.net/support too
[10:41] <Nafallo> BROKEN_LADDER: to get the right developers attention the best thing to do is file a bug. then you can talk with him if it's a bug or not. this is not the place (atleast you have a patch to fix the bug).
[10:42] <BROKEN_LADDER> okay. thx
[10:42] <doko> Kamion: yes, that was from anastacia's output
[10:42] <Nafallo> atleast if you *DO NOT* have a patch rather :-)
[10:42] <Nafallo> np
[10:43] <floam> BROKEN_LADDER: and just for your information, it works in 0.8
[10:44] <floam> so don't file a bug
[10:44] <BROKEN_LADDER> floam but you just said it works in 0.7.5. i thought...
[10:44] <floam> no.
[10:44] <BROKEN_LADDER> ah!  so i'm not crazy?!
[10:44] <Keybuk> BROKEN_LADDER: this is not a support channel.  Please stop asking for support here.
[10:45] <BROKEN_LADDER> i'm not Keybuk 
[10:45] <Keybuk> yes, you are
[10:45] <BROKEN_LADDER> nope.
[10:45] <BROKEN_LADDER> just wrapping up my discussion with floam about an upcoming version of smeg.
[10:45] <seb128> still not the place
[10:46] <seb128> please move that to #ubuntu
[10:46] <BROKEN_LADDER> k, i'll chat with him in priv or in another channel.
[10:46] <Keybuk> thankyou
[10:47] <Nafallo> Keybuk: you got nothing for me to test today? :-)
[10:47] <crimsun> pitti: just a random thought RE: hide-admin-tools-to-users, is there any way the check can be tied into tty tickets?
[10:48] <Keybuk> Nafallo: not yet
[10:49] <crimsun> pitti: (unfortunately that would mean that /var/run/sudo/ would have to be accessible, which is an information disclosure)
[10:49] <Keybuk> at least, nothing that won't leave your machine in pieces ;)
[10:49] <Nafallo> hehe :-)
[10:50] <seb128> infinity: why are the "given-back" build not retried? Could you retry libgpod on i386, thanks
[10:51] <pitti> crimsun: well, if the user already authenticated, then this would not be a problem in the first place
[10:51] <pitti> crimsun: but at login (when menus is started) we can be sure that the user is not
[10:54] <BROKEN_LADDER> one last thing before i depart..  i suggest you guys make it so that when you log in on a new screen, and you're already logged in, that the password box from xscreensaver somehow be bypassed, to create the "illusion" of an xp-style multi-login system.  
[10:54] <pitti> why on earth do we need that?
[10:55] <pitti> Window managers provide multiple desktops for years...
[10:57] <crimsun> pitti: what if the approach is shifted to avoid touching sudo at all? For instance, if we're going to hide the admin tools, is it a fair assumption that gksudo is going to be used? If it is a fair assumption, would storing a gconf key still be overboard in terms of information disclosure?
[10:57] <crimsun> (I realize that doesn't cover the "plain" sudo case)
[10:57] <pitti> crimsun: I think so, otherwise we would not need sudo logging
[10:58] <pitti> crimsun: and even then, at some point you have to determine the gconf key
[10:58] <pitti> crimsun: and the key is not adapted if an users' privs are changed
[10:58] <pitti> e. g. the admin could say at some point 'allow network-admin to this guy, but nothing else'
[10:58] <crimsun> true. I keep running into the info disclosure issue.
[11:03] <Kamion> crimsun: is all this Standards-Version bumping really necessary?
[11:07] <crimsun> Kamion: eh, I suppose not. I only did it for two packages as I recall
[11:10] <Kamion> ideally please don't in future, it just creates unnecessary diffs which somebody has to look at later
[11:10] <crimsun> Kamion: ack
[11:10] <zakame> hmmm, that goes for me too
[11:10] <Kamion> nothing actually cares about Standards-Version, aside from lintian/linda whinging; it's only meant as a reminder to the maintainer to look over newer versions of the policy manual
[11:11] <Kamion> (and old S-V can be an indication that a package is poorly looked-after, in Debian)
[11:11] <Nafallo> that goes for all MOTUs :-P
[11:11] <zakame> hmm, indeed :)
[11:12] <floam> MsOTU
[11:13] <Kamion> fabbione: new rescue with the changes you'll need for server rescue mode is in dapper now
[11:13] <fabbione> Kamion: cool
[11:16] <pitti> cupsys, there you go. Now let's see what breaks :)
[11:27] <doko> pitti: please review icu for main inclusion
[11:35] <pitti> doko: reviewed and approved; looks fine
[11:35] <doko> pitti: thanks
[11:35] <pitti> doko: btw, do you plan a new OO.o upload soon?
[11:37] <pitti> doko: can you please try to build OO.o against firefox-dev instead of mozilla-dev, and use libdb4.3 instead of db4.2?
[11:38] <doko> pitti: in some weeks, maybe. we're currently in the libstdc++ allocator change, and I see that 19738 wasn't addressed yet
[11:39] <pitti> ok
[11:39] <pitti> I just want to make damn sure that mozilla goes into universe for dapper
[11:39] <pitti> otherwise we'll make the support hell even worse
[11:45] <mdz> pitti,doko: icu promoted, thanks
[11:59] <Kamion> doko: all those c2a binaries are in main now
[11:59] <doko> Kamion: nice!
[12:04] <fabbione> bah
[12:04] <fabbione> i killed p-a-l merge
[12:05] <fabbione> actually no...
[12:05] <fabbione> hmm
[12:05] <fabbione> Kamion: i think i have been a bit too fast in uploading p-a-l merge.. if that's a problem please let me know
[12:06] <fabbione> i might have screwed the Depends:
[12:07] <mvo> Mithrandir: do you mind if I upload a newer pbuilder? you seem to be the last person touching it
[12:07] <doko> mvo: any estimate for the apt upload (libstdc++ allocator change)?
[12:07] <doko> dholbach: any estimate for the g*mm* uploads (libstdc++ allocator change)?
[12:08] <mvo> mvo: I want to bring in a abi change as well, it's prepared, I will test it a bit before the upload
[12:08] <mdz> doko: apt should only need a no-change upload, since it calculates its soname at build time
[12:08] <mdz> mvo: you worry me when you talk to yourself
[12:08] <mvo> mdz: *arg*
[12:09] <dholbach> doko: ok, if i do it tomorrow?
[12:09] <mvo> mvo: stop talking to yourself
[12:09] <seb128> Diziet: "ldd -r /usr/lib/mozilla-firefox/libgtkembedmoz.so" gives a bunch of undefined symbol which seems to make yelp build unhappy, it would be nice if you could fix it (no hurry) :)
[12:11] <mvo> mdz: I was thinking about the "default sources.list spec" (enable network sources in sources.list by default and deal with it gracefully)  yesterday and came up with a "per-queue permanent failure" mode. do you think you will have a time to look over the idea? I'm interessted in a second opinion? I'll also ask on deity about it
[12:11] <Kamion> fabbione: please recheck until you're happy with it, then
[12:11] <Kamion> I'm doing too much other stuff
[12:11] <doko> mdz, mvo: yes, but aptitude currently is uninstallable, so we should do it soon
[12:11] <mdz> mvo: certainly, email is best though
[12:12] <mvo> mdz: nice, thanks!
[12:15] <fabbione> Kamion: yes don't worry. i meant if you notice daily-installer failures related to it, just tell me. I noticed too late that the Depends: relies on other merges that needs to be done.. and i plan to do them by today.
[12:15] <fabbione> max tomorrow if the world fall down
[12:21] <Kamion> fabbione: oh, which ones?
[12:25] <mvo> Keybuk: the pbuilder result from MoM looks a bit odd, do you have time to take a look?
[12:25] <mvo> Keybuk: or rather, the other way around :) MoMs merge for pbuilder ...
[12:36] <fabbione> Kamion: Depends: partman-base (>= 73), partman-auto (>= 45), partman-lvm, di-utils (>= 1.15), lvm2-udeb
[12:37] <fabbione> at least partman-auto needs merging. we have 44ubuntu7
[12:37] <Kamion> fabbione: ok, that's on my list, I'll do it later
[12:37] <fabbione> i have lvm2
[12:37] <Kamion> it has fiddly translation stuff to do
[12:37] <fabbione> but the udeb it's there
[12:37] <Kamion> in any case it won't break the installer
[12:37] <fabbione> not sure about the others yet
[12:38] <fabbione> ok
[12:38] <fabbione> that's enough for me to know that i can do the merges quitely
[12:49] <Simira> Mithrandir ?
[01:03] <sivang> aren't we supposed to have a development status meetin now?
[01:03] <Kamion> err ... AFAIK it's in two hours
[01:03] <ogra> sivang, not really
[01:03] <Kamion> yes, it is in two hours
[01:03] <sivang> ogra: 12:00UTC no?
[01:04] <ogra> 14:00 UTC
[01:04] <Kamion> 14:00 UTC; see http://lists.ubuntu.com/archives/ubuntu-devel-announce/2005-November/000004.html
[01:04] <ogra> according to the fridge
[01:04] <Kamion> (and erratum in http://lists.ubuntu.com/archives/ubuntu-devel-announce/2005-November/000005.html)
[01:05] <sivang> uh-ha. thanks
[01:05] <mvo> Kamion: you are still interessted in a "fail-early-and-fast" mode for apt when it comes to network failures? for the installer?
[01:06] <Kamion> mvo: yes
[01:06] <Diablo-D3> I think I have found the scariest thing ever
[01:06] <Diablo-D3> booting linux, and seeing the line "Segementation fault" several times in a row, and the box not doing anything for several seconds.
[01:07] <\sh> Diablo-D3: oh..surprise...u discovered a development version....this is nothing for production environments
[01:08] <Diablo-D3> \sh: lol.
[01:08] <Keybuk> mvo: odd in what sense?
[01:08] <Diablo-D3> \sh: dapper for the win.
[01:08] <Diablo-D3> \sh: it still doesnt beat the libc5->6 transition in debian
[01:09] <Keybuk> mvo: looks just like pbuilder includes its testsuite output in its own source package, I think I've seen that before
[01:10] <mvo> Keybuk: the changelog ordering of the merged.patch
[01:10] <Keybuk> oh, that always goes screwy if it picks the Debian side
[01:11] <mvo> oh, ok. so nothing to worry?
[01:11] <fabbione> Kamion: other than partman-auto merge the others are in sufficient version.. do you want me to do that merge for you?
[01:12] <Diablo-D3> hrm.
[01:12] <Diablo-D3> is it safe to say ubuntu is now the most popular distro in existance?
[01:12] <\sh> mvo: I had this, too...and in some cases I had a broken diff.gz as well..wrong sourcepatches etc. I just used the debian package and merged the changelog and stuff ... and dropped ubuntu changes if needed
[01:12] <\sh> Diablo-D3: no Windows is
[01:12] <Diablo-D3> \sh: ...
[01:13] <Kamion> fabbione: I'd rather do it myself - it has some really hairy translation merging to do, and I have the tools to do it mostly right
[01:15] <fabbione> Kamion: works for me :)
[01:22] <Kamion> fabbione: you broke the partman-auto-lvm merge a bit; please check executable bits versus Debian - the ones I noticed are that automatically_partition/some_device_lvm/{choices,do_option} should be executable in the source package
[01:23] <fabbione> Kamion: i did only unpack the debian package and manually merged the bits... if they are broken, debian needs the same fix
[01:24] <fabbione> Kamion: yeps.. i confirm
[01:24] <fabbione> Debian has the same issue
[01:28] <fabbione> Kamion: probably the svn properties for the files haven't been set properly..
[01:32] <Kamion> quite right
[01:33] <Kamion> I'll fix
[01:33] <fabbione> ok
[01:33] <fabbione> i am keeping the interdiffs.. 
[01:33] <fabbione> this time..
[01:33] <fabbione> so i can push them to joeyh and co.
[01:33] <Kamion> sorry, MOM misses executable bit changes so I assumed it was a merge problem
[01:34] <fabbione> Kamion: no problem dude.. thanks for noticing.. i didn't
[01:34] <fabbione> we would have noticed at the first test.. that's for sure
[01:34] <Kamion> I happened to notice because I'm in the middle of producing partman.deb, and lintian told me
[01:37] <Kamion> fabbione: ok, version 5 heading in the direction of  incoming
[01:38] <fabbione> 5?
[01:38] <fabbione> ok
[01:39] <Mithrandir> mdz/JaneW : is it on purpose that the openoffice-amd64 spec isn't targetted at dapper?
[01:43] <biel> hi there! I do not know if this is the right channel, but I am looking for information on how to make a live distro (like ubuntu ;-)  ) can anyone help me ?
[01:44] <Kamion> mjg59: you say you call cardctl insert from userspace - are you prepared for that changing to pccardctl?
[01:56] <fabbione> bah
[01:56] <fabbione> i did even use p-a-l-3
[01:58] <\sh> fabbione: play xbox..the new one..it's broken too :)
[01:59] <fabbione> \sh: yes i saw the pics
[01:59] <fabbione> i am a proud of owner of a ps2 that i did turn on only 10 times in 3 years
[01:59] <fabbione> basically new
[01:59] <\sh> fabbione: I just read a nice article about the US launch of xbox...cooling problems etc. pp.
[02:00] <fabbione> and snow on screen
[02:01] <fabbione> http://www.flickr.com/photos/80491849@N00/
[02:01] <fabbione> ^^
[02:01] <\sh> hmmm...can someone confirm this: #17792
[02:02] <sivang> \sh: installer bug?
[02:02] <\sh> sivang: grub bug i think
[02:02] <sivang> \sh: bah, I need another machine here for tests like this
[02:03] <\sh> hda, hdb, hdc is normally counted hd(0,0/1,0/2,0) but after installing grub the hdc drive is hd(1,0) and not hd(2,0)
[02:03] <\sh> the guy who reported it, works in my company...he showed me the behaviour
[02:03] <doko> Riddell: what is gettext-kde? arts b-d's on it
[02:05] <Riddell> doko: it's for extracting strings from KDE programs for rosetta, I've written a main inclusion report, we need to poke mdz or pitti to review I guess
[02:05] <pitti> me actually, yes
[02:05] <pitti> sounds harmless, but I'll take a look at it
[02:06] <\sh> fabbione: btw....can your friend test dappers xterm_207? 
[02:07] <fabbione> \sh: i will ask.. yes
[02:07] <\sh> fabbione: cool..thx :)
[02:07] <\sh> actually...one or two bugs fixed with xterm-207...Thomas did a great job on the stand alone version
[02:08] <tepsipakki> fabbione: so partman-auto-lvm is not quite there yet to test?-)
[02:08] <fabbione> tepsipakki: it works in breezy...
[02:09] <fabbione> i just did a wrong merge in dapper
[02:09] <fabbione> nothing to fear
[02:09] <fabbione> it will be fixed by tomorrow
[02:09] <tepsipakki> i'd test a fully automated install
[02:10] <tepsipakki> you say it should work with breezy?
[02:10] <Riddell> pitti: will I need a main inclusion report for imlib11?  the source package is already in main
[02:10] <pitti> Riddell: no, that's trivial then
[02:13] <pitti> doko: mmmm, alsa 1.10. Thanks :)
[02:15] <fabbione> tepsipakki: it does work.
[02:15] <tepsipakki> oh
[02:16] <tepsipakki> how do I tell the installer to use lvm for the fs's?
[02:16] <fabbione> at the partitioner
[02:16] <fabbione> it asks if you want to erase the entire disk and use LVM'
[02:16] <tepsipakki> by "fully automated" I meant a preseed-install ;)
[02:17] <tepsipakki> netboot && sleep
[02:17] <tepsipakki> ;)
[02:17] <fabbione> tepsipakki: can't remember
[02:18] <fabbione> the template is partman-auto-lvm/text/use_device
[02:18] <fabbione> and Template: partman-auto-lvm/new_vg_name
[02:18] <fabbione> but the second one is low priority.. so you might not see it
[02:18] <tepsipakki> ok, I'll check
[02:19] <fabbione> \sh: where is xterm-207 ?
[02:19] <fabbione> is it in the archive?
[02:22] <tepsipakki> fabbione: does the use_device accept the same as partman-auto (/dev/discs/disc0/disc)
[02:22] <tepsipakki> ?
[02:22] <pitti> elmo: please sync mozilla-locale-de-at
[02:23] <fabbione> tepsipakki: i assume so
[02:23] <\sh> fabbione: yepp...dapper
[02:23] <fabbione> tepsipakki: it's the same template.. renames
[02:23] <fabbione> renamed
[02:23] <\sh> xterm_207-0ubuntu1
[02:23] <tepsipakki> fabbione: ok, thanks.. I'll try it ->
[02:24] <\sh> fabbione: http://archive.ubuntu.com/ubuntu/pool/main/x/xterm/
[02:24] <fabbione> \sh ok
[02:24] <\sh> fabbione: it's installable on breezy too :)
[02:24] <\sh> i should request a backport :)
[02:25] <fabbione> \sh: i am only pushing info from chan to another
[02:25] <\sh> fabbione: hehe :)
[02:25] <fabbione> i have no direct interest in it yet
[02:31] <doko> pitti: are you looking for libcupsys installability?
[02:31] <pitti> doko: does it fail?
[02:32] <doko> The following packages have unmet dependencies:
[02:32] <doko>   libcupsys2-dev: Depends: libcupsys2 (= 1.1.99.b1.r4841-1ubuntu1) but it is not installable
[02:32] <doko> Package libcupsys2 is not available, but is referred to by another package.
[02:33] <doko> This may mean that the package is missing, has been obsoleted, or
[02:33] <doko> is only available from another source
[02:33] <doko> However the following packages replace it:
[02:33] <doko>   libcupsimage2
[02:33] <doko> E: Package libcupsys2 has no installation candidate
[02:33] <dholbach> mvo: thank you for fixing pbuilder
[02:33] <pitti> doko: oh, libcupsys2 is in universe
[02:34] <mvo> dholbach: :)
[02:34] <pitti> doko: libcupsys2-gnutls10 is obsolete now, it's a transitional package to libcupsys2
[02:35] <ik5pvx> hi
[02:35] <doko> pitti: and which of the gnutls packages do we use, 11, 12, or both?
[02:35] <pitti> doko: ? the latest
[02:36] <pitti> doko: it just b-depends on libgnutls-dev
[02:36] <pitti> elmo, Kamion: can you please promote libcupsys2 to main? it's the 'new' name of libcupsys2-gnutls10
[02:36] <ik5pvx> \sh you around ?
[02:37] <doko> pitti: but cupsys still uses 11 ...
[02:37] <\sh> ik5pvx: yeah..
[02:37] <tepsipakki> fabbione: didn't work, it still installs on real partitions. shouldn't it have some hooks in the recipe, like in the changelog of p-a 41u7?
[02:37] <ik5pvx> \sh I've tested xterm 207
[02:38] <pitti> doko: oh, gnutls12 is still in universe
[02:38] <ik5pvx> \sh still same thing, by default doesn't go to load XTerm-color like it used to in the past both on ubuntu and on debian
[02:38] <ik5pvx> \sh, it does if I use -class XTerm-color
[02:39] <pitti> doko: yes, eventually we should build everything against 12 and drop 10 and 11
[02:39] <fabbione> tepsipakki: did you test breezy or dapper?
[02:39] <fabbione> \sh: ik5pvx is the guy having the issue.. so you two can talk together
[02:40] <\sh> ik5pvx: ok..lets switch to query
[02:40] <tepsipakki> fabbione: breezy
[02:40] <fabbione> tepsipakki: it works in breezy, you might have preseeded the wrong thing
[02:40] <fabbione> tepsipakki: on what arch are you trying btw?
[02:41] <tepsipakki> x86
[02:41] <Kamion> pitti: promoted libcupsys2 and libgnutls-dev
[02:41] <fabbione> it works
[02:41] <fabbione> 100%
[02:41] <pitti> Kamion: ah, you promotoded gnutls-12 now? nice
[02:41] <Kamion> libgnutls12 was already in main
[02:42] <tepsipakki> can I paste the preseeds here?
[02:42] <tepsipakki> six lines ;)
[02:42] <fabbione> tepsipakki: i didn't test with preseeding.. i know if you select the option it work
[02:42] <fabbione> +s
[02:42] <tseng> tepsipakki: pastebin.
[02:44] <pitti> Kamion: ok, that means that from now on packages shuold build against 12, great
[02:46] <tepsipakki> fabbione: does the manual version load a specific recipe or what?
[02:46] <fabbione> tepsipakki: it loads the standard recive
[02:46] <fabbione> only if you select low priority install it will ask for the recipe
[02:47] <fabbione> but that makes no differenve
[02:47] <fabbione> difference
[02:49] <tepsipakki> I'm looking at the source but don't know what to preseed ;)
[02:49] <tepsipakki> http://pastebin.com/437110
[02:50] <fabbione> tepsipakki: there are only 2 templates
[02:51] <fabbione> there isn't much to preseed
[02:51] <fabbione> and the names are the one i did paste before
[02:53] <tepsipakki> I'll check the logs
[02:59] <Kamion> if you have specs assigned to you, please /join #ubuntu-meeting
[03:00] <Diziet> Aha.
[03:02] <mjg59> Kamion: Presumably, yes
[03:15] <Kinnison> A while ago, seb128 managed to tell me how to get my 'Text Editor' shortcut back in the Accessories menu
[03:15] <Kinnison> anyone know?
[03:15] <Diablo-D3> ....... windows?
[03:16] <Kinnison> Diablo-D3: No dear, Ubuntu/Breezy
[03:16] <Diablo-D3> oh
[03:16] <seb128> Kinnison: rm ~/.local/share/applications/gedit.desktop
[03:16] <Keybuk> Kinnison: #ubuntu
[03:17] <Kinnison> seb128: that's the monkey, ta
[03:17] <Kinnison> Keybuk: feh, I'm already on 13 channels, adding another will hurt my brain
[03:18] <Keybuk> Kinnison: this still isn't a support channel. :)
[03:18] <Keybuk> and tbh, if we let you get away with it, the cluebies will argue and fight
[03:18] <Kinnison> Keybuk: oh right
[03:18] <Diablo-D3> yeah damnit
[03:18] <Kinnison> fair enough
[03:19] <Diablo-D3> and #ubuntu-laptop isnt one either
[03:19] <Diablo-D3> ;)
[03:43] <pitti> zyga: do you know a bit about packaging? would you like to provide updated gnome-menu etc. packages for the langpacks-for-desktop-files?
[03:44] <seb128> he already sent some patches to malone
[03:44] <zyga> pitti: I know some bits, I can do that 
[03:44] <pitti> if not, I'll find some time to apply and package them, no problem
[03:44] <zyga> seb128: yes but I never published patched desktop files
[03:44] <pitti> just curious if you want to learn about packages or not :)
[03:44] <zyga> I sure do
[03:45] <pitti> zyga: oh, the patches have to be compatible with unpatched desktop files anyway
[03:45] <zyga> hm?
[03:45] <pitti> so once we have the patched packages in dapper, we can start with the intltool changes
[03:46] <zyga> let's separate: patches to code (done, working), patches to desktop files, none, missing
[03:46] <pitti> zyga: I mean, if a .desktop file does not have a X-Ubuntu-Gettext-Domain: field, it still must work
[03:46] <zyga> ah, k
[03:46] <pitti> i. e. it shuold fall back to the inline translations in the desktop file
[03:46] <zyga> I can just add the relevant field, without stripping exiting messages
[03:46] <pitti> right, that was the plan
[03:46] <zyga> k
[03:46] <pitti> zyga: but don't bother with manually updating all desktop files
[03:46] <zyga> is there anyone working on intltool support?
[03:46] <pitti> zyga: we'll do that automatically; just one for testing is enough
[03:47] <zyga> ah, then I have enough for you ;)
[03:47] <pitti> zyga: if you want to work on the gnome side, I'll take a look at intltool
[03:47] <zyga> gnome-side?
[03:47] <zyga> all gnome tools are patched and support this
[03:47] <pitti> oh, so much the better :)
[03:47] <zyga> (all that I knew of)
[03:47] <pitti> thanks for your efforts
[03:47] <zyga> panel, nautilus (same libs), python libs
[03:48] <zyga> the thing needed now is intltool support and automated builds with extra field
[03:49] <zyga> kde is totally not-supported, I don't touch kde
[03:49] <pitti> zyga: ok, if intltool is a blocker, I'll shift it up in my queue ;)
[03:49] <Keybuk> building packages after init=/bin/sh seems so wrong
[03:49] <Riddell> zyga: hmm?
[03:49] <Keybuk> aka. "aren't you glad Keybuk tested this before uploading it?" :)
[03:50] <pitti> zyga: the spec talks about it, I talked to Riddel at UBZ
[03:50] <zyga> Riddel: if you can patch kde world to support X-Ubuntu-Gettext-Domain that would be great
[03:50] <zyga> will do
[03:50] <Riddell> zyga: yeah, I hope to.  no idea if I'll manage it or have time but it's my aim
[03:51] <zyga> Riddell, great I know C++ but I'm helpless kde-wise so  if there is anyway I can help you feel free to ask
[03:53] <Keybuk> ok ... let's try that again, with a less-ronnied initramfs
[03:57] <\sh> hmmm...
[03:57] <\sh> the last build log I can see is from 0732 DCT? 
[04:05] <Mithrandir> seb128: didn't you get wv2 synced? (#19351)
[04:05] <doko> pitti: firefox ping
[04:06] <pitti> doko: I didn't work on the separate libs yet
[04:06] <pitti> doko: I just took a look at the list of packages that build against mozilla-dev
[04:06] <pitti> doko: because these actually keep -browser in main
[04:06] <seb128> Mithrandir: I did, but it took some time between when I asked and when elmo did it and I forgot to go back to change bugzilla, sorry
[04:06] <Mithrandir> seb128: np, I
[04:07] <seb128> pitti said something about not using PENDINGUPLOAD
[04:07] <Mithrandir> 'll just close the bug, then
[04:07] <seb128> yeah
[04:07] <pitti> Diziet: do you think it is reasonably easy to build libnspr and libnss packages from firefox?
[04:07] <doko> pitti: I cannot switch to firefox-dev, as long as firefox-dev ships with broken libnspr.pc/libnss.pc files. so please fix that first
[04:07] <seb128> pitti: what about xulrunner?
[04:07] <pitti> seb128: what's that?
[04:08] <Diziet> pitti: Actual separate packages, or just include them in firefox-dev's output ?
[04:08] <pitti> Diziet: separate packages, like mozilla produces ATM
[04:09] <Diziet> Why would they want to be separate packages ?
[04:09] <doko> Diziet: because they currently are separate packages?
[04:10] <pitti> Diziet: they are now, and half the world depends on them
[04:10] <Diziet> Ahh.
[04:10] <Diziet> Um, dpkg-shlibdeps and a Provides for the Build-Depends ?  (Excuse me for being vague, the coffee is just brewing ...)
[04:11] <pitti> Diziet: why not just copy the control records from mozilla and build true debs?
[04:11] <infinity> Split libraries == good.
[04:11] <seb128> pitti: http://wiki.mozilla.org/XUL:Xul_Runner
[04:11] <Diziet> I suppose that means you won't have to install huge piles of firefox crap on systems that just want libnss.
[04:12] <pitti> Diziet: hm, why?
[04:12] <pitti> Diziet: the libraries themselves don't depend on firefox
[04:12] <Diziet> You misunderstand.  I mean, separate package as you suggest would have the beneficial effect I describe.
[04:12] <Diziet> I'm just trying to keep the diff small, you see.
[04:13] <pitti> Diziet: oh, I would not mind a completely separate source package
[04:13] <Diziet> Ah, coffee.
[04:13] <pitti> enjoy :)
[04:14] <Diziet> I think a separate source package would risk having to do rather too much violence to the firefox upstream build system.
[04:15] <Diziet> doko: Your .pc brokenness> is that in bugzilla ?  If you've got it to hand, feel free to mark it P1 and I'll pick it up in my next round of firefox activity.
[04:17] <Diziet> I think I'm at least half-convinced now that having firefox ship the nss and nspr .debs, to look like mozilla's .debs, is the right answer.
[04:18] <mvo> Diziet: how long does a ff build take on a reasonable fast box? 
[04:18] <pitti> mvo: on mine it took 20 minutes with ccache
[04:18] <mvo> pitti: thanks
[04:19] <Diziet> My 2G Athlon does it in about a hour.  Much faster with ccache.
[04:19] <seb128> it takes like 40min here
[04:19] <pitti> Diziet: maybe I misunderstood your proposal then; you wanted to ship the .so files in f-dev and just Provide: the libnss- stuff?
[04:19] <seb128> athlon 3000
[04:19] <Diziet> pitti: Um, it's not so much `my proposal' yet.  I'm just exploring alternatives :-).  But:
[04:19] <pitti> Diziet: it's not that appealing to me, but it would certainly work, too
[04:20] <Diziet> To ship the .so files in f-dev and Provide libnss-dev.  And I suppose there'd be another library ff-libs or something where the shlibs from ff-dev would point to,.
[04:20] <Diziet> I mean, another package.
[04:20] <pitti> Diziet: right, right now some libs are in firefox.deb proper
[04:20] <Diziet> Those'll have to move into a separate .deb, won't they ?
[04:21] <doko> Diziet: it's 12398, changed the priority
[04:21] <Diziet> Are they separated in mozilla-browser ?
[04:21] <Diziet> doko: Thanks.
[04:21] <pitti> Diziet: seems to be quite independent from the nss/nspr problem, but that would indeed be nice
[04:21] <pitti> Diziet: no, they aren't
[04:21] <Diziet> Hmm.
[04:21] <pitti> Diziet: m-b ships three .so files
[04:21] <pitti> Diziet: so m-dev depends on m
[04:21] <pitti> which is a bit ugly
[04:21] <pitti> and the main reason why we had to keep m-browser in main for breezy
[04:21] <Diziet> And everything that needs libnss Depends m-f ?
[04:21] <pitti> no
[04:22] <pitti> Diziet: nss and nspr are quite independent
[04:22] <Kamion> Diziet: separate packages would be convenient in the event that libnss/libnspr's sonames change
[04:22] <Diziet> kamion: True.
[04:22] <pitti> Diziet: in fact they have separate upstreams (but no idea how often they sync to each other)
[04:22] <Kamion> although I *suppose* Provides would have a similar effect ...
[04:22] <Diziet> So where do the libs come from at runtime ?
[04:22] <pitti> Diziet: right now, libnspr and libnss sources are part of moz/ffox source tarballs
[04:23] <Kamion> but it's easier to see that we should drop the libnss/libnspr .debs from mozilla if firefox is shipping them (the archive will resolve it then, rather than creating enormous buildd confusion)
[04:23] <pitti> right
[04:23] <Diziet> pitti: Yes, that's at build-time.  But where do the programs that link against nss/nspr get the libs from _at runtime_ ?
[04:24] <pitti> Diziet: libnspr4 and libnss3 debs
[04:24] <pitti> these only ship the relevant libs
[04:24] <Diziet> Which come from ... ?
[04:24] <pitti> Diziet: mozilla source
[04:24] <pitti> Diziet: oh, mozilla-browser and firefox ship three *additional* shared libraries
[04:24] <Diziet> Oh, I thought you said they weren't separated out.
[04:24] <pitti> Diziet: that's why -dev depends on the browser
[04:25] <Diziet> What are these libraries for ?  Are they used only at build-time ?
[04:25] <pitti> so a -libs package would be nice for f, but is not utterly urgent and unimportant for dropping mozilla
[04:25] <pitti> Diziet: no, quite many other packages depend on nss/nspr
[04:25] <pitti> some generic certificate handling stuff, AFAIK
[04:25] <Diziet> These three additional shared libs that you speak of.  What are they called ?
[04:25] <pitti>  This package provides the runtime libraries needed to use the Netscape
[04:25] <pitti>  SSL/TLS layer, including S/MIME and key management.
[04:26] <Diziet> Damn, I seem to have deleted my most recent ff build tree.
[04:26] <pitti> Diziet: /usr/lib/mozilla-firefox in the firefox package
[04:26] <pitti> oops, there seem to be quite some more in 1.5
[04:26] <doko> Diziet: and it would be nice to have the libmozgeckoplugin (or something like this) in a firefox-lib package
[04:26] <pitti> libmozjs.so, libxpcom.so, and so on
[04:26] <pitti> these are important for e. g. epiphany
[04:27] <doko> needed by eclipse, and others
[04:28] <Diziet> I'm still confused.  Packages which use stuff from m/f are:  1. packages which embed the browser (epiphany etc.)  2. packages which use libnss/libnspr as generally useful libs (lots, we assume).   3. ?  4. ?
[04:28] <Diziet> libmozjs sounds like the JavaScript interpreter.  Is this used by anything except packages of type 1 ?
[04:29] <pitti> probably not
[04:29] <pitti> Diziet: my main concern is:
[04:29] <pitti> Diziet: a lot of packages need libnspr4 and libnss3
[04:29] <pitti> these are built from mozilla source ATM
[04:29] <pitti> we want to kill mozilla
[04:29] <Diziet> Yes, yes, _please_ stop telling me your concern.  I understand.  What I _don't_ understand is all of the surrounding context and the way it all fits together.
[04:29] <pitti> since firefox sources contain the same library sources, it would rock to build these debs from firefox source instead of moz source
[04:30] <pitti> ah, ok
[04:30] <Diziet> Before we decide what to do about it I want to understand the _whole_ problem so that we won't have to change our mind in another 2 weeks when we discover that what we decided first was wrong.
[04:30] <pitti> Diziet: there are currently three packges that build-depend on mozilla-dev, so we have to change them as well
[04:31] <pitti> Diziet: but that's a problem with the depending packages themselves
[04:31] <doko> mvo: any estimate on the apt/aptitude uploads?
[04:31] <pitti> ideally OO.o and librsvg2 would build against ffox-dev
[04:31] <Diziet> Do my categories 1 and 2 overlap ?
[04:31] <Diziet> Are there any categories 3 and 4 that I'm missing ?  Or can everything be considered as 1 or 2 ?
[04:31] <Diziet> If 1 and 2 overlap, what will we do when the ABI to libnss changes and firefox and the embedder are out of sync ?
[04:32] <pitti> Diziet: I think 1 entails 2
[04:32] <Diziet> So all programs that embed ff are direct users of libnss etc. ?  Hrm.
[04:32] <mvo> doko: tomorrow? if it's totally urgent I do it tonight
[04:33] <Diziet> Usual approach with shared libs is to allow coinstallation of incompatible versions.  Does that mean we have to try to support coinstallation of two abi-incompatible firefoxes ?
[04:33] <pitti> Diziet: I don't think so
[04:33] <pitti> Diziet: we never had that case, though; nss and nspr ABIs did not change for years
[04:33] <Diziet> So if the libnss abi (or the embedding abi) changes, we accept tiresome coupling to epiphany, oo.o, etc. etc.
[04:34] <pitti> Diziet: if that would happen, i. e. firefox 2.0 would ship a nspr5, we need to rebuild all depending apckages, right
[04:34] <Diziet> Right.  But you wouldn't be able to coinstall both versions, unlike any other shared lib package.
[04:34] <pitti> Diziet: well, you can coinstall the debs
[04:34] <Diziet> We can support coinstallation easily for my category 2.
[04:34] <pitti> but the old deb would not be built any more
[04:34] <Diziet> No, you can't coinstall firefox and firefox2.
[04:34] <pitti> right
[04:34] <pitti> coinstallation for 1 is hard
[04:34] <pitti> but not really necessary
[04:35] <Diziet> So that means that you can't coinstall oo.o-build-against-ff1 and epiphany-built-against-ff2.
[04:35] <pitti> for 2 it is still hard, since then we need separate sources for nspr and nss
[04:35] <pitti> Diziet: we should try hard to avoid that case :)
[04:35] <Diziet> Avoid which case ?  Avoid ever having that combination of versions ?
[04:35] <pitti> yes
[04:35] <pitti> that would mean to have two ffox sources in main
[04:36] <pitti> one is more than enough pain
[04:36] <Diziet> You can't get from both-against-ff1 to both-against-ff2 without going through a mixture.
[04:36] <pitti> Diziet: why not? the packages could be upgraded at the same time
[04:36] <Kamion> if the package name changes then we can go through the transition without having a period when stuff is uninstallable
[04:36] <pitti> or does that break in any way?
[04:36] <Kamion> which I for one would appreciate
[04:37] <Diziet> No two packages can be upgraded at the same time.  I think you may mean `very quickly one after the other and we hope the user does not notice'.
[04:37] <pitti> yes; but even if that's not possible, breaking the dev version for one or two days is still better than keeping two ffox sources around IMHO
[04:37] <Diziet> It wouldn't be too hard, if and when it happens, to make a special backward-compatible firefox source which produced the old libnss.
[04:38] <pitti> Diziet: you mean the ffox-dev-old?
[04:38] <Diziet> Just fork the old firefox package into a new package with a new name and a build system made only to ship the libnss runtimes.
[04:38] <pitti> oh, ok, sure
[04:38] <Diziet> No, I mean libnss4 <=Source:= firefox-old-libnss
[04:40] <Diziet> It's almost tempting to try to split the firefox.deb into an embedder (ie, a cat.2 package as above but built from the same source) and the embeddable browser.
[04:41] <pitti> with all the /usr/lib/m-f/*.so?
[04:41] <Diziet> Then with a slight editing of pathnames you could coinstall both embeddable browser.
[04:41] <Diziet> Hrm, if you have both browsers on a machine, your profiles might well get a bit mangled.
[04:42] <Diziet> I think this is probably too great a deviation from upstream's intended use practices.
[04:42] <Diziet> Also, weird shit would happen because the browser you saw inside your oo.o would be a different version (possibly very different) to the one you got when you just asked for a browser.
[04:43] <Diziet> I think this argument demonstrates that the embedding ABI should never change.
[04:43] <pitti> hehe, let's hope the best
[04:43] <Diziet> Not that upstreams ever care about this kind of thing.
[04:43] <pitti> although I doubt that current epy still works with 1.5, or does it? seb128?
[04:44] <Diziet> There are some differences already, AIUI.
[04:45] <seb128> pitti: it does, I've rebuilt before going to sleep this night
[04:45] <pitti> ah, cool, so at least the API didn't change (too drastically)
[04:45] <seb128> pitti: upstream are fast :)
[04:45] <Diziet> So you had to rebuild it.
[04:45] <seb128> yeah, ABI change
[04:45] <seb128> some symboles were missing
[04:45] <Diziet> See above ^ :-).
[04:45] <pitti> seb128: ok, so you actually upgraded the version?
[04:46] <seb128> pitti: no, just rebuilt, epiphany is adapted to build with different firefox, mozilla, xulrunner, etc
[04:46] <pitti> oh, wow
[04:46] <Diziet> epiphany Depends firefox, does it ?
[04:46] <seb128> yep
[04:47] <Diziet> And Build-Depends firefox-dev.  Right.
[04:47] <pitti> for all the libraries, I assume
[04:47] <seb128> correct
[04:47] <seb128> $ ldd /usr/bin/epiphany | grep firefox
[04:47] <seb128>         libgtkembedmoz.so => /usr/lib/mozilla-firefox/libgtkembedmoz.so (0xb7fb8000)
[04:47] <seb128>         libxpcom.so => /usr/lib/mozilla-firefox/libxpcom.so (0xb7fb4000)
[04:47] <seb128>         libplds4.so => /usr/lib/mozilla-firefox/libplds4.so (0xb7fb1000)
[04:47] <seb128>         libplc4.so => /usr/lib/mozilla-firefox/libplc4.so (0xb7fac000)
[04:47] <seb128>         libnspr4.so => /usr/lib/mozilla-firefox/libnspr4.so (0xb7f7c000)
[04:47] <Diziet> Does epiphany use libnss/libnspr ?
[04:47] <seb128>         libxpcom_core.so => /usr/lib/mozilla-firefox/libxpcom_core.so (0xb6e3d000)
[04:47] <Diziet> Ah, there we go.
[04:47] <Diziet> *blink*  Its own libnspr ?
[04:48] <pitti> Diziet: remember, ffox doesn't build a separate deb ATM
[04:48] <pitti> (for nspr)
[04:49] <Diziet> Right.  Um, so does that mean that apps that embed firefox link against ff's nspr and other apps take the one from mozilla-* ?
[04:49] <Diziet> (in breezy, say)
[04:49] <seb128> yep
[04:49] <Diziet> That's clearly wrong.
[04:49] <seb128> $ ldd /usr/bin/evolution | grep nspr
[04:49] <seb128>         libnspr4.so => /usr/lib/libnspr4.so (0xb7961000)
[04:50] <seb128> that's why we want to build libsnpr from firefox and use this one :)
[04:50] <Diziet> Because before you know it some wobbly pile of libraries and suites and environments and other such words will mix them up.
[04:50] <Diziet> (Has probably already happened and may be the cause of bizarre crashes.)
[04:52] <Diziet> So what we seem to be heading towards is:  firefox will provide the -dev and runtime packages for libnss and libnspr.  These packages will look just like the ones from mozilla.
[04:52] <Diziet> The actual firefox.deb will naturally then use the ones provided by its own libnss.
[04:52] <seb128> right
[04:53] <Diziet> Possible trouble will be handled as follows:
[04:53] <Diziet> ABI change to libnss: we will fork the firefox package to make a firefox-old-libs.
[04:53] <Diziet> ABI change to embeddable firefox: tough, pain
[04:54] <Diziet> Bugs in libnss which mean we want to have different libnss for firefox: We revert to previous arrangement, or institute separate source for libnss which firefox won't use.
[04:54] <Diziet> Have I covered everything ?
[04:55] <Diziet> (I think this is going to be a u-d-a posting.)
[04:55] <seb128> seems fine to me ... pitti ?
[04:57] <seb128> though a firefox-old-libs would probably be required, the rdepends are quite small, we can quickly transition that
[04:57] <seb128> s/be/not be/
[04:58] <pitti> back
[04:58] <Diziet> See scrollback and tell us what you think.
[04:59] <pitti> Diziet: looks fine to me
[04:59] <Diziet> debian/rules build, with a pretty full ccache and most of the source (but not the ccache) in buffer cache, 11m40.  fakeroot debian/rules binary a further 2m40.
[04:59] <pitti> Diziet: I still think that the transient -old package is overkill, but that won't happen any time soon anyway
[05:00] <Diziet> Sure.  I'll note that in my writeup.
[05:00] <\sh> laters
[05:00] <pitti> Diziet: thank you
[05:20] <mvo> Diziet: does the message in http://paste.ubuntulinux.nl/4992 make any sense for you?
[05:21] <mvo> Diziet: I can give you a backtrace as well if you want :)
[05:21] <Riddell> pitti: how is that gettext-kde main inclusion review coming along?
[05:22] <pitti> Riddell: not yet started, is it very urgent?
[05:22] <pitti> Riddell: I generally tend to do them in batches once every week or so, when I'm not in a mood for hacking :)
[05:22] <Diziet> mvo: No.
[05:22] <Diziet> It looks like a severe installation problem.
[05:22] <pitti> unless people bug me to do them quickly
[05:23] <Diziet> What's it from ?
[05:23] <Riddell> pitti: it is blocking all of KDE, which needs to be uploaded for libstdc++ transition
[05:23] <pitti> Riddell: oh, ok, then I do it now
[05:23] <Diziet> *laugh*
[05:23] <mvo> Diziet: it's a debug rebuild of your tree
[05:23] <Riddell> pitti: thanks
[05:23] <Diziet> Nice.
[05:23] <Diziet> I should try that myself.
[05:24] <mvo> Diziet: triggered with a small python script that uses gtkmozembed
[05:24] <mvo> http://paste.ubuntulinux.nl/2994 is the script
[05:25] <Diziet> No it's not.
[05:25] <Diziet> 4994.
[05:25] <Diziet> Has this been rebuilt against the new ff-dev ?
[05:25] <Diziet> FSVO `this'.
[05:26] <seb128> Keybuk: are "Intel PRO/Wireless 2200BG" card known to be problematic? cf http://bugzilla.ubuntu.com/show_bug.cgi?id=19554
[05:26] <Diziet> `No' is a perfectly good answer.  It shouldn't break like that; the dependencies should be right.
[05:27] <Keybuk> seb128: is that the iftab swap bug?
[05:28] <seb128> Keybuk: I don't think so, I get an IP when running dhclient with the iftab bug, it just doesn't work on boot
[05:28] <mvo> Diziet: it is rebuild
[05:28] <Keybuk> "doesn't work" ?
[05:28] <Keybuk> does it not get an IP?  does it not show up in ifconfig?  does it get an IP, but just doesn't route?
[05:28] <seb128> Keybuk: he mentions the card beeing listed as eth2 but ifconfig has no eth2
[05:28] <sabdfl> Keybuk: i'm upgrading to dapper now, any particular requirement i.t.o. kernel / udev?
[05:29] <seb128> Keybuk: the bug I've pointed has ifconfig/dhclient output, but I'll ask for details on the card ... what's the best way to have that, dmesg | grep eth? lspci?
[05:29] <Keybuk> sabdfl: not yet ... I think BenC *just* uploaded the 2.6.15-4 kernel, but stick with 12-9 unless you want life to be exciting
[05:29] <Keybuk> seb128: lspci I guess
[05:29] <seb128> k, thanks
[05:30] <Keybuk> seb128: along with ls /sys/class/net; cat /sys/class/net/*/address; readlink /sys/class/net/*/device
[05:32] <sabdfl> Keybuk: coolio. i have enough excitement for one person right now :-)
[05:32] <Diziet> mvo: And it failed before you rebuilt it debug ?  (Ie, that's what you were trying to debug?)
[05:32] <Keybuk> sabdfl: do I want to ask?
[05:32] <sabdfl> Keybuk: what should the /etc/network/interfaces file look like after a fresh install? mine is hoary->breezy->dapper
[05:33] <Kamion> we haven't made the dapper changes to that yet
[05:33] <Keybuk> sabdfl: it hasn't changed yet
[05:33] <sabdfl> ok
[05:33] <Keybuk> there are some ... issues with network-manager
[05:33] <Kamion> I'm sort of waiting until the dust settles so I can see what's on the other side, too
[05:33] <sabdfl> should i go with network manager now?
[05:34] <Keybuk> you can certainly install it, and for you it should work
[05:34] <Keybuk> I think you have an ipw in that X40, no?
[05:34] <pitti> Riddell: oh, that's just xgettext? so intltool and the like are the same?
[05:34] <Riddell> pitti: yes
[05:34] <pitti> Riddell: or does kde use the copies in source packages?
[05:35] <Riddell> kde doesn't use intltool as far as I know
[05:35] <pitti> ok
[05:35] <pitti> Kamion: gettext-kde looks fine
[05:36] <Kamion> for main?
[05:36] <pitti> Kamion: if you want to promote it now, I put it into the approved section right away
[05:36] <pitti> yes
[05:36] <Kamion> pitti: done
[05:37] <sabdfl> seb128: are there gstreamer-0.9 packages anywhere?
[05:37] <Kamion> ... oops, while apt-ftparchive was running
[05:37] <Kamion> that probably wasn't a terribly good idea
[05:37] <pitti> Kamion: yay race conditions :)
[05:37] <Kamion> oh well, if the archive is broken in the next half-hour, my fault, sorry
[05:37] <sabdfl> Keybuk: yup. X40, ipw2100
[05:38] <sabdfl> Kamion: garhk. am mid-upgrade :-)
[05:38] <sabdfl> oh well. i have your home phone number handy >:-)
[05:39] <Kamion> sabdfl: it'll *probably* only matter if you're trying to install gettext-kde, which you probably aren't
[05:39] <Kamion> if you've already downloaded the package lists, you're certainly fine
[05:39] <seb128> sabdfl: no, we are waiting for 0.10 which is due in ~10 days
[05:39] <sabdfl> seb128: cool, thanks
[05:39] <mjg59> Damnit.
[05:39] <seb128> np
[05:39] <sabdfl> mjg59: ?
[05:40] <mjg59> Configuring the ATI northbridge to have the same config values as Windows doesn't seem to fix suspend on the nc4000
[05:40] <sabdfl> the voodoo that you do
[05:40] <mjg59> On the other hand, the nx6125 works now
[05:40] <sabdfl> you must have forgotten a pin in the doll
[05:41] <mjg59> And I've finally pushed all my patches upstream
[05:47] <mvo> Diziet: yes, I got a segfault before as well
[05:49] <pitti> mvo: for a few days now, apt-get source seems to go crazy
[05:49] <pitti> mvo: apt-get update failed for my breezy/universe sources (md5 mismatch)
[05:49] <pitti> mvo: however, dapper/main and all others are fine
[05:50] <pitti> mvo: still, apt-get update libusb doesn't do anything but complain about missing breezy universe sources :(
[05:50] <pitti> mvo: not even if I specify the exact version
[05:51] <mvo> pitti: are you behind a proxy?
[05:51] <pitti> mvo: yes
[05:51] <sabdfl> https://addons.mozilla.org/themes/moreinfo.php?id=505
[05:52] <pitti> mvo: that might explain the wrong md5 sums, that happens pretty often to me
[05:52] <pitti> mvo: but why does apt-get source refuse to do anything? is that intentional?
[05:52] <mvo> pitti: if it gets wrong md5 on a index, the index is refused
[05:52] <pitti> *all* indices?
[05:52] <mvo> pitti: and a normal apt-get update dosn't fix your universe/Source index? that's really odd
[05:53] <mvo> pitti: no, only the one with the failed md5sum
[05:53] <pitti> mvo: ok, universe/breezy is wrong, but I want a dapper/main source
[06:00] <mdke> has anyone noticed the rss feeds not working properly on planet.ubuntu.com? or is it something wrong with me?
[06:02] <ptlo> mdke, not working in what sense?
[06:03] <mdke> ptlo, only jeff's last post is there. Everything since yesterday has disappeared
[06:03] <jbailey> mdke: Hmm?
[06:04] <mdke> jbailey, australian jeff
[06:04] <jbailey> Ah. =)
[06:04] <jbailey> I don't think I'm on planet.ubuntu.  Dunno, though.
[06:05] <ptlo> mdke, i wgetted the rss20.xml and it contains entries since 09 nov, the same as the current html page
[06:05] <mdke> ptlo, how about rss10.xml?
[06:05] <ptlo> mdke, ditto for rss10.xml - it all seems to work for me
[06:05] <mdke> you've tried them in an rss reader?
[06:06] <ptlo> oh, just a sec
[06:06] <ptlo> no, just downloaded
[06:06] <mdke> i think there is something wrong with the xml which is breaking the entries
[06:08] <ptlo> mdke, Quim Gil's post about GUADEC & GNOME breaks xml well-formedness (it contains unquoted '&')
[06:08] <ptlo> and sure enough, that post is directly after jeff's
[06:09] <mdke> yeah that is it
[06:09] <mdke> must be a planet bug though, it should be able to handle that
[06:10] <sabdfl> oops
[06:10] <sabdfl> guess x really is toast right now
[06:12] <mdke> jdub, Keybuk, the rss xml feeds from planet ubuntu are broken right now, due to a problem with one of the posts (the presence of an & in the post title possibly?) Are you guys aware of this bug (if it is a bug) already?
[06:20] <mdke> did the ubuntu for vmware thing get done?
[06:22] <Riddell> infinity: would you be able to give back arts and kdelibs to the buildds?
[06:22] <Riddell> well, just arts to begin with
[06:23] <Riddell> mdke: henrick was doing it, not sure if it's been released
[06:23] <mdke> yeah me neither
[06:23] <mdke> i can't see it anywhere
[06:28] <sabdfl> q
[06:30] <Diablo-D3> yay
[06:30] <Diablo-D3> dapper has been busy today
[06:36] <psusi> hrm... seems that someone did something breaky with some packages
[06:42] <infinity> It's going to require a fair mess of rebuilds around the world to make ubuntu-desktop not break.
[06:42] <infinity> Library transitions are ugly that way.
[06:42] <psusi> shouldn't be...
[06:42] <ogra> do we have a elmo around today ?
[06:43] <psusi> here we go... ubuntu-desktop depends on gnomemeeting... which depends on libpt-1.8.3c2
[06:43] <psusi> the new libpt-plugins packages depend on libpt-1.8.3.c2a, which conflicts with the non a package
[06:44] <psusi> why is there a seperate libpt-1.8.3c2 and libpt-1.8.3c2a instead of just a newer version of libpt-1.8.3c2?
[06:44] <infinity> psusi : Yes.  As I said, library transitions are ugly. :)
[06:44] <infinity> psusi : Because the ABI changed.
[06:44] <psusi> why is it ugly?  why isn't it simply a new version of the package?
[06:44] <psusi> hrm...
[06:45] <psusi> if they change the ABI, why don't they change the name of the library to .1 or something?
[06:45] <psusi> so you can install both
[06:46] <infinity> Because the library itself didn't change, but it was compiled with a compiler that changed its ABI.
[06:46] <infinity> So the SOVER didn't change, but the ABI did.
[06:47] <psusi> how would that have happened?
[06:47] <psusi> the move to gcc 4?
[06:47] <infinity> The move to gcc4 is why it's got a "c2" on the end of it.  Just now, with a g++ allocator change, we moved from "c2" to "c2a"
[06:48] <infinity> Unfortunate, but life goes on.
[06:48] <infinity> At any rate, if you follow ubuntu-devel or ubuntu-devel-announce, this is all explained there.
[07:03] <mdz> Mithrandir: we aren't going to use the targeting in launchpad until it has some access control
[07:03] <mdz> Mithrandir: meanwhile, DapperGoals in the wiki
[07:09] <\sh> oh yeah....libtransitions...rebuilds....fun
[07:09] <\sh> and 30k bugs in my malone bugs reported list
[07:10] <Diablo-D3> Riddell: hey, does debtags break for you?
[07:10] <\sh> yes
[07:10] <\sh> because apt is not rebuild 
[07:10] <Diziet> Has the freetype breakage discussed in 13592 been sorted out yet ?
[07:10] <Diablo-D3> \sh: thats to me?
[07:11] <\sh> Diablo-D3: yes
[07:11] <Diablo-D3> okay, just making sure.
[07:11] <Riddell> Diablo-D3: havn't tried it recently
[07:11] <Diablo-D3> Im just wondering why adept needs debtags
[07:11] <Diablo-D3> oh.....  adept is a package manager for kde
[07:12] <Diablo-D3> doh.
[07:12] <Keybuk> someone remind me ... in a sh -e script, the following is wrong, yes?
[07:12] <Keybuk> log_begin_msg "..."
[07:12] <Keybuk> start-stop-daemon...
[07:12] <Keybuk> log_end_msg $?
[07:12] <infinity> You need to wrap it in an if.
[07:12] <Keybuk> that's what I thought
[07:13] <Keybuk> I'm not going crazy
[07:13] <infinity> Or other similar tricks to strip the return.
[07:13] <Diablo-D3> btw, ubuntu just did something neat.
[07:13] <Keybuk> if start-stop-daemon; then
[07:13] <Keybuk>   log_eng_msg 0
[07:13] <Keybuk> else
[07:13] <Keybuk>   log_end_msg $?
[07:13] <Keybuk> fi
[07:13] <Keybuk> was what I was inclined to do
[07:13] <Diablo-D3> its using both my wired and wireless connection to do network traffic
[07:13] <infinity> That should do the trick.
[07:14] <Diablo-D3> like, automagically.
[07:15] <infinity> Keybuk : For maximum unreadability, you can do: command && log_eng_msg $? || log_eng_msg $?
[07:16] <ogra> infinity, oh, localized lsb init ? log_eng_msg ?
[07:16] <ogra> :)
[07:16] <pitti> ogra: localized?
[07:16] <pitti> ah, ok :)
[07:17] <ogra> pitti ;)
[07:17] <pitti> ogra: it's hard to read that 6 pixel font in my xchat :)
[07:17] <infinity> ogra : I blame keybuk, I copy and pasted his example. :)
[07:17] <ogra> lol
[07:18] <ogra> pitti, get a projector then you even can read 6px fonts
[07:19] <ernstp> libGL error: dlopen /usr/X11R6/lib/modules/dri//r300_dri.so failed (/usr/X11R6/lib/modules/dri//r300_dri.so: cannot open shared object file: No such file or directory)
[07:19] <ernstp> /usr/lib/dri/r300_dri.so
[07:19] <Diablo-D3> since when did ubuntu ship r300 dri stuff?
[07:20] <infinity> ernstp : If an update/upgrade round doesn't sort you out, please file a bug.
[07:20] <ernstp> it's in xorg now
[07:21] <ernstp> sometimes when stuff is changing really fast and unstable you like to hear build-details etc directly
[07:21] <ernstp> you = ubuntu devs
[07:22] <infinity> ernstp : Except that of the two people who deeply care about that bug, one is going to sleep right now, and the other isn't here.
[07:23] <\sh> infinity: sleep well :)
[07:23] <\sh> infinity: and thx for fixing
[07:25] <ernstp> infinity: oh, right. :-) got it
[08:36] <\sh> lamont-away / infinity: can u give-bach ardour (universe/sound/ardour_0.99-3ubuntu1: Needs-Build [optional:out-of-date] )
[08:36] <\sh> give-back even
[08:37] <Keybuk> ok then, let's see if my laptop will boot *now*
[08:37] <lamont-away> \sh: done
[08:37] <\sh> lamont-away: thx
[08:37] <lamont-away> Keybuk: better shoelaces... that's what you need.
[08:48] <\sh> lamont-away: can you give-back kdiff3 kwave kmymoney2 , too thanks :)
[08:52] <FireRabbit> is linux-restricted-modules-686 in main?
[08:52] <FireRabbit> or multiverse
[08:52] <lamont-away> \sh: I rather expect that infinity/I will be doing massive give-backs everytime the buildd's get quiescent
[08:52] <lamont-away> FireRabbit: should be in restricted (hence the name)
[08:53] <FireRabbit> right ok
[08:55] <\sh> lamont-away: they were left from the libgcj6 b0rkness...I just forgot about them
[08:55] <FireRabbit> and on breezy is restricted enabled by default?
[08:55] <FireRabbit> or only main
[08:56] <lamont-away> whatever sources.list syas...  I think 'main restricted'
[08:56] <FireRabbit> well i dont have any unmodified systems :) i cant remember
[08:57] <FireRabbit> er, i'm trying to work on some documentation on the wiki and i dont want to be wrong ;)
[08:57] <\sh> FireRabbit: this is more a question for #ubuntu :)
[08:57] <FireRabbit> alright fair enough
[09:14] <mdke> jbailey, around? got 2 minutes?
[09:16] <jbailey> mdke: I'm around, yes.
[09:16] <jbailey> Just watching glibc build on hppa, so I might be lagged.
[09:16] <mdke> jbailey, what about the 2 minutes bit?
[09:17] <mdke> ok
[09:17] <mdke> jbailey, we're just doing the jbailey -> dholbach transition... we wanted to know, if a document in -docs changes name, do we need to do anything else to make the omf work except rename it in the package? i.e. does anything need to be done in any other packages?
[09:18] <ogra> lamont-away, whats up with the buildlogs ? 
[09:18] <Keybuk> jbailey: trade ya ... I'm currently being annoyed by the fact that my "what type of disk is this?" IDE binary runs so fast it beats the /proc/ide/.../media file appearing
[09:18] <jbailey> Keybuk: No.  Mine is now actually working. =)
[09:18] <dholbach> mdke: the "jbailey -> dholbach" transition... that's funny - this one will take ages ;)
[09:18] <jbailey> Keybuk: Although the correct answer there is to beat htem into making is a sysfs event. =)
[09:18] <ogra> mdke, this transition will require 3 years of hairgrowing for dholbach at least
[09:19] <mdke> lol
[09:19] <dholbach> ogra: and that's only the hair-growing
[09:19] <ajmitch> dholbach: you think you can pull off the accent?
[09:19] <ogra> hehe
[09:19] <dholbach> but funnily enough, i started becoming a hobby vegetarian :)
[09:19] <Keybuk> jbailey: a sysfs attribute, you mean?
[09:19] <dholbach> stopping smoking might take a bit longer
[09:20] <ogra> what the hell is a *hobby* vegetarian ?
[09:20] <jbailey> mdke: *thinking8
[09:20] <mdke> jbailey, :)
[09:20] <\sh> ogra: eating space cookies :)
[09:20] <ogra> lol
[09:20] <ogra> instead of smoking *g* ....
[09:21] <dholbach> haha
[09:21] <dholbach> not really
[09:21] <jbailey> mdke: The contents of the OMF file have to be correct as well.
[09:21] <\sh> actually i don't need any drugs ,) I have my pbuilder, a crashing kde/gnome panel and some packages to go
[09:21] <mdke> jbailey, well yes. But no other package needs to change?
[09:21] <jbailey> mdke: The nice part is that it should be possible to generate the OMF file from poxml as well, and get the headers and such translated.
[09:22] <jbailey> mdke: Not that I know of.  Scrollkeeper just reads the OMF file.
[09:22] <mdke> ok cool thanks
[09:22] <mdke> yeah we can translate it
[09:22] <jbailey> How it handled the mapping of the various language was always a bit of a mystery to me, bnut it worked. =)
[09:22] <jbailey> Keybuk: Right. =)
[09:23] <jbailey> Keybuk: That way you can just get an event for it.
[09:23] <jbailey> dholbach: Hobby vegetarian?
[09:23] <jbailey> dholbach: You do this in your spare time when noone's looking?
[09:24] <dholbach> maybe i should blog about it :)
[09:24] <mdke> he eats meat when no one is looking
[09:24] <ogra> lol
[09:24] <Keybuk> jbailey: well, you do get an event
[09:24] <Keybuk> the trouble is the "what is it?" information isn't there
[09:25] <jbailey> Keybuk: Any idea why the idea subsystem can't just behave like SCSI? =)
[09:25] <Keybuk> what?  tell you it's there, then not tell you what's actually on it for 30 seconds? :p
[09:26] <ogra> 30 secs would be a fast scsi adapter ... :)
[09:26] <ogra> i have some old adaptecs around that take up to 2 min to probe devices
[09:27] <\sh> merging, renaming, writing the changes in the debian/changelog in less then a minute...boring
[09:27] <ogra> \sh, junkie
[09:27] <ajmitch> \sh: automate it :)
[09:28] <\sh> ogra: i have to practice for my time when i'm employed by the state
[09:28] <ogra> employed by the state ? 
[09:28] <\sh> hartz4
[09:28] <\sh> .oO(someone has to sponsor my dsl line)
[09:28] <ogra> some people call that unemployment ;)
[09:28] <pitti> oh, btw, doko, still her?
[09:28] <pitti> +e
[09:29] <ajmitch> hi pitti 
[09:29] <\sh> ajmitch: believe me...yes
[09:29] <pitti> Hi ajmitch 
[09:29] <\sh> ajmitch: i'm going to be 35 in january...and then I'm old
[09:29] <ajmitch> \sh: ntw I tried newmerge.py, it said the mail was sent but I never saw it show up :)
[09:29] <pitti> \sh: don't scare us
[09:29] <ajmitch> \sh: and the merge is still unassigned on the list
[09:29] <\sh> ajmitch: lpbugs.py
[09:30] <\sh> ajmitch: newmerge.py is obsolete
[09:30] <\sh> pitti: well...it's time...I will have my answer just before x-mas
[09:30] <\sh> pitti: we talked about it during todays teammeeting...and I'm one of the guys who survived 3 lycos firing rounds
[09:31] <pitti> \sh: lycos?
[09:31] <\sh> .oO(in less then 2 years)
[09:31] <ogra> pitti, nope, ish gmbh ....
[09:31] <\sh> pitti: yeah...lycos europe, i worked there
[09:31] <\sh> pitti: before I started at ISH gmbh
[09:31] <pitti> ah, IC
[09:31] <ajmitch> \sh: fine, will try that one :)
[09:32] <ajmitch> \sh: fyi bzr pull still isn't updating that branch
[09:32] <\sh> ajmitch: use bzr branch :)
[09:33] <ajmitch> \sh: shouldn't need to
[09:33] <ajmitch> since bzr branch is only for grabbing a new branch
[09:33] <\sh> pitti: so I need a new job...or I will have a longtime holiday
[09:49] <Surak> Hello all
[09:50] <Surak> seb128: (about gstreamer-ffmpeg compilation problem): I did what you asked for. I downloaded dapper packages and tried to create debug packages from it (the same way I did with breezy, and following https://wiki.ubuntu.com/DebuggingProgramCrash ) - bot still no success. The same assembler error message appears in another machine. 
[09:50] <mdke> jbailey, poxml is in the build-depends for ubuntu-docs... but we were using xml2po weren't we?
[09:50] <Surak> but
[09:52] <jbailey> mdke: xml2po is in the poxml package, iirc.
[09:52] <doko> pitti: yes
[09:52] <Surak> seb128: Just to remind, this is related to http://bugzilla.ubuntu.com/show_bug.cgi?id=19434
[09:54] <seb128> Surak: "but ..."? :)
[09:54] <pitti> doko: the recent ReST vuln in zope2.7 - does that affect 3, too?
[09:54] <seb128> Surak: does the dapper package install on a 5.10 box?
[09:55] <Surak> seb128: hm, it did, but ain't tested. I just went straight to debugging stuff. Urgh!
[09:55] <doko> pitti: no, AFAIK that has the newer docutils
[09:55] <Surak> seb128: I wrote "bot" instead of but :-)
[09:56] <pitti> doko: ok, so we need to fix 2.8 for breezy
[09:57] <pitti> doko: do you still have the downsized patch somewhere?
[10:00] <Keybuk> right
[10:00] <Keybuk> if this one works, I'm going to kill people
[10:01] <Keybuk> it's exactly the same as last time
[10:01] <ajmitch> sounds promising
[10:01] <Keybuk> but with a sleep(3) at the top
[10:01] <ajmitch> what has awakened a murderous rage?
[10:01] <ogra> yay for sleep 3's
[10:02] <Keybuk> pitti: hand me my gun
[10:02] <Keybuk> IT'S KILLING TIME!
[10:02] <doko> pitti: I have to look ...
[10:02] <ajmitch> yay
[10:02] <Mithrandir> ajmitch: sleep, apparently.  Strange thing, that sleep awakens stuff.
[10:03] <Keybuk> ajmitch: I wrote a nice, fast, binary helper for the IDE subsystem that can report what media type a particular device is
[10:03] <Keybuk> e.g.
[10:03] <Keybuk> # /lib/udev/ide_media /devices/pci0000:00/0000:00:10.0/ide0/0.0
[10:03] <Keybuk> disk
[10:04] <pitti> Keybuk: is /proc/bus/ide/hda/media obsolete now?
[10:04] <Keybuk> sadly not
[10:04] <pitti> erm, /proc/ide/device/media, eve
[10:04] <pitti> n
[10:04] <dholbach> good night everybody
[10:04] <\sh> night dholbach 
[10:05] <dholbach> night stephan
[10:05] <slomo> gn8 dholbach :)
[10:05] <Keybuk> pitti: nope, because that's exactly what this helper does
[10:05] <Keybuk> it parses the sysfs path you give and figures out where under /proc it has to look
[10:05] <pitti> lol
[10:05] <Keybuk> but it was too fast
[10:05] <Keybuk> the shell one works because it's written in shell, and slow
[10:05] <Keybuk> my binary one only works if I put a sleep in it <g>
[10:06] <pitti> which makes the writing in C quite pointless?
[10:06] <Keybuk> the /proc/ide/**/media thing hadn't actually turned up, before it had given up and exited
[10:06] <Keybuk> pitti: nah, I like writing these helpers in C :)  it makes me feel clever
[10:06] <pitti> Keybuk: still, my gut feeling tells me that this stuff should be obsoleted in /proc...
[10:06] <Keybuk> I've put a for (100) usleep(30000) type thing in now
[10:06] <Keybuk> yes
[10:07] <pitti> Keybuk: yes, because string parsing is such an enjoyable experience in C
[10:07] <Keybuk> I was just chatting to kay about that, he was going to craft a put-it-in-sys patch, then bought a SATA laptop
[10:07] <Keybuk> pitti: compared to shell, yes
[10:07] <yi> hurmm, anyone else having trouble with the xorg 6.99 builds in dapper? it seems it doesn't know where to look for modules
[10:07] <pitti> Keybuk: oh, and now he can't test it any more? with no IDE disk?
[10:07] <pitti> bad timing...
[10:08] <\sh> yi: apt-get update ; apt-get dist-upgrade and you'll be fine.
[10:08] <Keybuk> pitti: more like doesn't care anymore :p
[10:08] <yi> \sh: well
[10:08] <yi> \sh: if it were that simple life would be great
[10:08] <Keybuk> SATA disks wear drag and pretend to be SCSI controllers
[10:09] <yi> \sh: i'm getting "Unknown protocol evdev"
[10:09] <yi> the module is there, did the name change?
[10:10] <ogra> yi, xorg is in active development currently ... its only half transitioned yet afaik
[10:11] <\sh> yi: oh then it's a not compiled or just missing module...wait until infinity or daniels are around..one is sleeping the other one is not there
[10:11] <\sh> pitti: bzr is fun :)
[10:11] <pitti> oooh, yes
[10:11] <pitti> I still feel the baz pain when my gf comes along with her diploma thesis baz archive
[10:11] <ajmitch> pitti: yes, I can get away with upgrading only when I remember, rather then when things are broken :)
[10:12] <ogra> bzr is cool .... it finally made me undestand versioning systems ... thanks to Keybuk and bzrk :)
[10:12] <\sh> pitti: and since I and siretart and others are using it to merge and branch our motu-tools repositories with it...ROCK..I really like it
[10:12] <pitti> doing the rm -r ++revision-lock-held; mkdir -p ++revision-lock/+contents dance again...
[10:12] <yi> \sh: no the modules are there
[10:12] <\sh> yi: then file a bug please :)
[10:12] <ajmitch> pitti: baz scares me
[10:12] <\sh> my x is running with a plain and usable config :) 
[10:12] <yi> no, it's not a bug either
[10:13] <ogra> yi, its just not ready yet ... it will very likely be done during the next 48h
[10:13] <pitti> ajmitch: oh, it worked well enough, compared to cvs; it was just horribly sloooow
[10:13] <yi> it seems that they use "Driver" "evdev"
[10:13] <yi> instead of "Driver" "mouse"
[10:13] <yi> Option Protocol evdev
[10:13] <ajmitch> anythign works well compared to cvs
[10:13] <pitti> well, true
[10:14] <lamont-away> ajmitch: and then there's clearcase.
[10:14] <ajmitch> I'll stay away from such things
[10:14] <\sh> ajmitch: svn is sometimes to stupid..or was in the beginning when I used it in 2003
[10:14] <lamont-away> DB_File needs compatible versions of libdb & db.h
[10:14] <lamont-away>         you have db.h version 4.3.28 and libdb version 4.3.29
[10:14] <lamont-away> GO devscripts
[10:15] <ajmitch> \sh: I still curse svn, but it's an improvement on cvs
[10:15] <pitti> that is *such* an incompatible change...
[10:15] <\sh> ajmitch: is the bug fixed, when you try to commit or checkout files which are e.g. kyrillic but your local/system local is US_ASCII?
[10:15] <mdke> jbailey, no it's in gnome-doc-utils. poxml is in the kde toolchain. np i'll change it now
[10:15] <\sh> ajmitch: or is it still segfaulting?
[10:16] <\sh> locale even
[10:16] <ajmitch> \sh: I have no idea, I only have straight ASCII files here
[10:17] <\sh> ajmitch: yeah..and I used it in a multilanguage utf-8 environment, where the web junkies were using windows and nameing their html files in their local language with local charsets
[10:17] <\sh> ajmitch: and this was really BAD
[10:18] <slomo> \sh: it's fixed now afaik... at least i had no problems with iso-8859-1 and utf8 and plain binary stuff ;)
[10:20] <\sh> slomo: i'll try it again sometime...when there is time, when there are no merges, no transitions :)
[10:24] <floam> yay
[10:24] <floam> I found a patch that fixes the input issues in the new X11 stuff
[10:25] <floam> http://bugzilla.ubuntu.com/show_bug.cgi?id=20052
[10:26] <ajmitch> \sh: in other words, in the time between dapper & when dapper+1 opens? ;)
[10:26] <\sh> ajmitch: yeah..during the next ubuntu dev conference :)
[10:28] <ajmitch> hm, doesn't look like the mail went through to malone still
[10:29] <\sh> ajmitch: local smtp?
[10:29] <\sh> or local sendmail?
[10:29] <ajmitch> local sendmail
[10:30] <ajmitch> I see it going out in my maillogs
[10:30] <\sh> ajmitch: u sure u send with a launchpad registered email address?
[10:30] <ajmitch> yes
[10:30] <ajmitch> ubuntu.com address
[10:30] <ajmitch> which is registered on lp
[10:30] <\sh> it takes normally max 1 min
[10:30] <ajmitch> there's at least a few merges which I can do
[10:31] <ajmitch> it's been > 30 min
[10:31] <ajmitch> nothing in my reported bugs list
[10:31] <slomo> it took ~3 hours one time for me
[10:31] <ajmitch> sent with the new gpg key, which is also enabled in lp
[10:31] <ajmitch> I should just upload then :)
[10:32] <\sh> ajmitch: lpbugs.py -n <packagename> -> ?
[10:32] <ajmitch> \sh: yes
[10:32] <\sh> strange
[10:32] <ajmitch> I blame launchpad
[10:35] <\sh> elmo: please sync caudium from unstable, dropping ubuntu changes ok
[10:35] <\sh> elmo: thx
[10:37] <\sh> ajmitch: which merges? I can file the bugs for u
[10:38] <\sh> ajmitch: u can update them later in LP directly
[10:41] <ajmitch> \sh: I could put them in LP directly as well
[10:43] <Keybuk> http://people.ubuntu.com/~scott/bootcharts/dapper-20051124-1.png
[10:43] <ajmitch> 1 to sync (after test), 2 to upload
[10:43] <Keybuk> ^ sweet
[10:45] <ogra> Keybuk, WOAH
[10:46] <Keybuk> there's two massive modprobes there
[10:46] <Keybuk> I suspect one of them is my soundcard, which has always taken that long
[10:46] <Keybuk> the other might be radeonfb, which I need to blacklist
[10:46] <ogra> but you are at 40 sec
[10:47] <ajmitch> \sh: I can't file a new sync bug straight away? I have to file a new one & then update it to sync?
[10:47] <\sh> ajmitch: we need to update the revu list...you can do it also directly on revu...see sistpotys mail :)
[10:47] <wasabi> Surely there has to be a way to up the priority of X to "kick everything else's ass".
[10:47] <Keybuk> *shrug* it's a start yeah
[10:47] <wasabi> And every GUI program.
[10:47] <\sh> ajmitch: yes
[10:47] <Keybuk> there's still some whitespace in it
[10:47] <\sh> ajmitch: because u have to test it first
[10:47] <Keybuk> can probably get another 10-15s out of that
[10:47] <ajmitch> \sh: found one where the only ubuntu change in the merged debdiff is a changelog
[10:48] <ajmitch> because the ubuntu changes went up to debian
[10:48] <ajmitch> not a lot to do there ;)
[10:48] <\sh> ajmitch: it's like this: u start to work on a package with filing the bug :)
[10:48] <\sh> ajmitch: then u check...and decide: sync or merge and update the bug accordingly
[10:48] <ajmitch> fine
[10:49] <\sh> ajmitch: if the package is build...u close it after..the pending upload feature of LP...don't use it..u won't find your package again
[10:49] <ogra> Keybuk, if you get it to 30, i could actually achieve 45 for thin clients :)
[10:49] <ajmitch> and I can find pending upload bugs just fine
[10:49] <\sh> ajmitch: ajmitch@ubuntu.com ?
[10:49] <ajmitch> \sh: yes
[10:50] <Keybuk> ogra: I think it's probably 30s for everyone but my laptop
[10:50] <\sh> u should have mail in 5 4 3 2 1 now
[10:50] <ogra> heh
[10:50] <Keybuk> when we did this a year ago, my laptop was always 10s longer because of its soundcard module thing
[10:50] <ajmitch> \sh: thanks
[10:50] <\sh> ajmitch: is it in your reported bugs?
[10:50] <Keybuk> iirc it's spinning waiting for firmware or something
[10:50] <ogra> pcmcia seems to take some time too
[10:50] <Keybuk> pcmcia is going anyway
[10:51] <ogra> hopefully
[10:51] <Keybuk> nah, is
[10:51] <Keybuk> kernel does most of it now, the rest is a handful of udev rules and helpers that kamion's packaged up
[10:51] <ajmitch> \sh: nothing is in my reported bugs at the moment
[10:51] <ogra> cool
[10:51] <ajmitch> well nothing merge related
[10:52] <\sh> ajmitch: u see...all pending uploads are just disappearing from your reported bugs
[10:52] <ajmitch> \sh: https://launchpad.net/distros/ubuntu/+bugs-advanced
[10:52] <floam> \sh: you are going to make my head explode :(
[10:53] <floam> s/u/you/
[10:53] <ajmitch> \sh: since bugs get assigned to motumergers, you can search for pending upload bugs there
[10:53] <ajmitch> if LP doesn't die in the process ;)
[10:53] <ajmitch>  Timeout error
[10:53] <ajmitch> Sorry, Launchpad took too long to process your request. 
[10:53] <\sh> ajmitch: really? thats the problem.
[10:53] <\sh> ajmitch: this is what I meant
[10:54] <\sh> ajmitch: don't use it
[10:54] <\sh> floam: I?
[10:54] <ajmitch> don't use LP? ok
[10:54] <\sh> ajmitch: don't use lpbugs.py "pending upload" option :)
[10:54] <ajmitch> ;)
[10:54] <\sh> ajmitch: means: don't set any bug in LP to pending upload
[10:54] <floam> \sh: I suffer from people-that-say-u-make-me-want-to-set-myself-on-fire syndrome
[10:54] <ajmitch> hehe
[10:54] <ajmitch> morning lifeless 
[10:54] <lifeless> hi
[10:55] <\sh> floam: oh...set me on ignore then, thx
[10:55] <ogra> hey lifeless 
[10:55] <ajmitch> \sh: hopefully I'll get that email from you soon..
[10:55] <ogra> mako, finally !
[10:55] <ajmitch> hey mako 
[10:55] <lifeless> so I now the no support rule here ... but I hgave a bug with hotplug and wifi ;)
[10:56] <Keybuk> lifeless: irrelevant, hotplug isn't in dapper
[10:56] <lifeless> if someone can point me at the right way to diagnose it that would be great. 
[10:56] <Keybuk> upgrade in a couple of days time, and see if you still have the same bug
[10:56] <lifeless> Keybuk: well, not hotplug then
[10:56] <mako> ogra: tell me about it
[10:56] <mako> ajmitch: hola
[10:56] <ogra> mako, yore not a pumpkin anymore :)
[10:56] <Keybuk> lifeless: diagnosing it depends exactly what's wrong
[10:56] <lifeless> Keybuk: ah, you think its transitional ? All I know is that the interface does not come up automatically, it used to do so.
[10:56] <ogra> *youre
[10:56] <mako> ogra: you try living life as a pumpkin for nearly 48 hours
[10:57] <ogra> i dont want to :)
[10:57] <\sh> lol
[10:57] <Keybuk> lifeless: have you reinstalled recently, or did it just stop working of its own accord?
[10:57] <\sh> nice crash of konversation.."please hit shift+something and die"
[10:57] <lifeless> Keybuk: I upgraded to dapper when I got back from UBZ
[10:58] <\sh> ajmitch: 3 minutes ago I send it to you
[10:58] <Keybuk> I don't know of any bugs, because none of that stuff changed yet
[10:58] <lifeless> Keybuk: I *think* it worked for the first day or two of updates, but I can't swear to it.
[10:58] <Keybuk> you running 2.6.12 or 15?
[10:58] <\sh> ajmitch: bug in LP ,)
[10:59] <lifeless> ah, -12
[10:59] <lifeless> erm .12
[10:59] <Keybuk> dunno why it broke then
[10:59] <\sh> ajmitch: 'alps-light1' couldn't be found in command 'affects /distros/ubuntu/alps-light1' ... 
[10:59] <Keybuk> otoh pretty much everything between you and your network card is changing soon
[10:59] <lifeless> yah
[11:00] <lifeless> want me to wait for that and tey again then 
[11:00] <lifeless> ?
[11:00] <Keybuk> start at seeing whether the right module is loaded, then look to see whether dhclient was spawned for it, etc.
[11:00] <lifeless> the module is loaded
[11:00] <lifeless> but AFAICT dhclient was not invoked for it
[11:00] <Keybuk> did the card get the expected name?
[11:00] <lifeless> according to daemin.log
[11:01] <lifeless> yah, if I ifup it it works.
[11:01] <Keybuk> do you have two eth cards?
[11:01] <slomo> daniels: want me to fill some bugs with exa on radeon on powerpc? or is exa something you don't care for now? ;)
[11:01] <lifeless> yes, eth0 is the built in ethernet
[11:01] <lifeless> eth1 is the wifi
[11:01] <lifeless> ipw2200 FWIW
[11:01] <Keybuk> could be that you need to swap the names around
[11:01] <mdke> lifeless, mine isn't working with the .12-10 kernel either, in fact, nor is my ethernet
[11:02] <mdke> works if I boot the .12-9 kernel
[11:02] <mdke> in fact, X doesn't work with that kernel either
[11:02] <lifeless> strange, I'm running 12-9
[11:02] <mdke> ah
[11:02] <Keybuk> where did you get 12-10 from?  there's no such beast
[11:02] <mdke> hmm
[11:03] <Keybuk> or is that the security update one?
[11:03] <lifeless> hotplug is still installed - should I remove it ?
[11:03] <mdke> Keybuk, ok you have a good point. I must be running dapper with the breezy kernel, and vice versa
[11:03] <ajmitch> \sh: maybe my email is just taking a long time today :)
[11:03] <Keybuk> lifeless: no :)  not just yet
[11:03] <Keybuk> not if you enjoy booting
[11:03] <ajmitch> \sh: try ajmitch@ihug.co.nz instead
[11:03] <lifeless> well, yes as it happens, I do
[11:04] <Keybuk> I don't have hotplug installed, but I also know how to boot a machine by hand
[11:05] <lifeless> thanks for the help ;)
[11:06] <lifeless> as we're changing the layout, theres little value identifying the problem
[11:06] <lifeless> I'll workaround till the new process is in place
[11:06] <lifeless> and then we can see
[11:07] <Keybuk> probably a bad idea
[11:07] <Keybuk> I should probably be sociable for the 12 hours after I do it
[11:07] <lifeless> in the middle of the c++ transition too? evvvil
[11:07] <Keybuk> there's no C++ in it
[11:07] <Keybuk> is all C
[11:08] <Keybuk> lucious, sexy, C
[11:08] <lifeless> and ? theres plenty of tools that do have c++
[11:09] <Keybuk> I'll upload it tomorrow morning instead
[11:09] <Keybuk> when 2.6.15-4 has actually built
[11:09] <lifeless> might be an idea, yes ;)
[11:13] <ogra> \sh, poke lamont-away 
[11:14] <\sh> ogra: you asked him :) i'm only waiting that I can "set status fixed" to my long long long buglist in malone :)