[12:13] <mjg59> Kamion: Ah, got it - I hadn't realised db_get errored on that
[12:23] <mjg59> Kamion: Thanks, fixed
[01:50] <zul> hey
[01:50] <ajmitch> hello zul
[02:51] <bddebian> Heya
[02:52] <Keybuk> not for the first time, I wish C had a two-dimensional switch
[02:53] <bddebian> Heya Keybuk
[02:53] <bddebian> A two dimensional switch?
[02:53] <Keybuk> yeah
[02:53] <Keybuk> so I can do switch (old_state, new_state) :p
[02:53] <bddebian> Ah
[02:53] <Keybuk> and each case statement lists the transitions
[02:54] <Keybuk> rather than
[02:54] <Keybuk> switch (old_state) {
[02:54] <Keybuk> case STATE_A:
[02:54] <Keybuk>     switch (new_state) {
[02:54] <Keybuk>         case STATE_A:
[02:54] <Keybuk> etc.
[02:54] <Keybuk> switch (old_state, new_state) {
[02:54] <bddebian> So create one.. ;-P
[02:54] <Keybuk> case STATE_A, STATE_A:
[02:54] <Keybuk> so much easier
[02:54] <Keybuk> I don't think it's possible to create, sadly
[02:55] <Keybuk> one can just play silly buggers with <<
[02:57] <zul> ugh..
[02:57] <lifeless> Keybuk: create a combined state value ?
[02:57] <lifeless> Keybuk: (is that what you mean by << tricks ?)
[02:58] <Keybuk> right
[02:58] <Keybuk> #define STATE_CHANGE(old, new) (((old) << 16) | (new))
[02:58] <Keybuk> switch (STATE_CHANGE (old_state, new_state)) {
[02:58] <lifeless> yeah
[02:58] <Keybuk> case STATE_CHANGE (STATE_A, STATE_A):
[02:58] <lifeless> reasonable for C
[02:58] <lifeless> I had a similar issue in python in bzr - not a state change mapping, but doing operations between two separate things
[02:58] <lifeless> created a lookup object, and put methods on its instances, works sweetly ;)
[03:07] <bluefoxicy>  2155 root      15   0  296m 217m 201m S  0.0 22.9   2:05.70 synaptic   <-- Amusing.
[03:09] <desrt> the archive makes me sad.
[03:10] <zul> anyone have spads' email address?
[03:18] <bluefoxicy> wow.  usplash now draws a tiny box in the center of my screen; and then the screen blacks with a _ sitting there solid as if the machine locked out for like 30 seconds.  I guess that's some kind of progress.
[03:22] <desrt> in what locations does ubuntu have actual offices?
[03:25] <bluefoxicy> desrt:  looking for corporate training?
[03:25] <desrt> making some vaguely pie-in-the-sky future plans :)
[03:25] <bluefoxicy> (dad says ubuntu can't reach the business desktop because businesses want to hire out for training....)
[03:25] <Lathiat> desrt: i think its london?
[03:25] <Lathiat> dont quote me on that ;)
[03:26] <bluefoxicy> Lathiat:  One convenient location.  In Africa.  </Aqua Teen Hunger Force>
[03:27] <zul> desrt: montreal is one i think
[03:28] <desrt> i know of this one
[03:33] <Lathiat> http://www.ubuntu.com/employment
[03:33] <Lathiat> lists london & montreal
[03:41] <bddebian> Damn, I think they need an office in Philadelphia! :-)
[03:43] <jsgotangco> there's an office in london
[03:44] <bddebian> No, no, USA man :-)
[03:44] <jsgotangco> you can always move to montreal heh
[03:46] <bddebian> No, they don't let people like me into foreign countries ;-P
[03:47] <mjg59> bluefoxicy: There's some sort of race in the svgalib vt switching code
[03:59] <sladen> desrt: London, Montreal, sort-of Durbanville.  Oh and Canonical One, which is normally at Stansted, except during times of emergency when it is airbourne, providing backup desk and communications facilities for vital personel.
[03:59] <desrt> durbanville near capetown?
[04:00] <desrt> what about the theoretical isle of man office? :)
[04:00] <zul> i thought it was just durban i didnt know there was a durbanville
[04:00] <sladen> zul: https://launchpad.net/people/nick-zork
[04:00] <zul> sladen: yep already sent him an email...thanks
[04:01] <bluefoxicy> mjg59:  ah.  But Falcon's Eye is svgalib so in the interim we could play nethack :)
[04:01] <bluefoxicy> sladen:  Canonical has air support?
[04:02] <bluefoxicy> when the friggin' hell did Linux get its own army?
[04:04] <Keybuk> sladen: Mark's still not managed to get an Internet connection for it though
[04:05] <Keybuk> and you forget So Carlos
[04:08] <Keybuk> desrt: the offices (aside from Sao Carlos) are all ops team though
[04:08] <Keybuk> or support
[04:08] <Keybuk> developers work from home
[04:10] <desrt> nod
[04:11] <desrt> how do you get paid?
[04:11] <desrt> direct deposit to your local bank account in your own currency?
[04:11] <Keybuk> usual UK PAYE arrangements
[04:11] <Keybuk> it varies from country to country
[04:11] <desrt> maybe better to ask one of the french or germans :)
[04:12] <Keybuk> UK employees, for example, aren't employed by Canonical Ltd but by Fieldwave Ltd which is contracted by Canonical to do work for it
[04:12] <desrt> that's an interesting factoid of which i was not aware
[04:12] <Hobbsee> hi all
[04:12] <Keybuk> this is pretty unique though, to do with law between the UK and IoM
[04:12] <desrt> Hobbsee; hello.
[04:12] <Hobbsee> wow really?
[04:12] <desrt> Hobbsee; ya.  i'm seriously saying hello.  i'll say it again: hello :)
[04:13] <Hobbsee> heh
[04:13] <Keybuk> I believe there is a similar arrangement in .ca due to local contractor law, but don't quote me on that ... I don't really keep up
[04:13] <desrt> is fieldwave a shell or do they actually do other stuff?
[04:13] <Keybuk> but yes, in general, you're paid via whatever normal mechanism you'd expect
[04:13] <Keybuk> it's an anthropomorphic companification
[04:14] <bddebian> Heya Hobbsee
[04:14] <desrt> ah.  i see.
[04:14] <desrt> clear as mud :)
[04:14] <Keybuk> vaguely standard company arrangement, aiui
[04:15] <Keybuk> sladen dug out all the paperwork at one point
[04:15] <Keybuk> he used to have it on the web, dunno if he still does
[04:15] <whiprush> keyyyyyyyybuk!
[04:16] <mjg59>     if (__svgalib_go_to_background)
[04:16] <mjg59>         (__svgalib_go_to_background) ();
[04:16] <mjg59>     __svgalib_flipaway();
[04:16] <mjg59>         if((__svgalib_textprog&3)==3){
[04:16] <mjg59>            pid_t child;
[04:16] <bddebian> Heya whiprush
[04:16] <mjg59>            if((child=fork())==0){
[04:16] <mjg59>            execv(__svgalib_TextProg,__svgalib_TextProg_argv);
[04:16] <mjg59>            } else {
[04:16] <mjg59>            waitpid(child,NULL,0);
[04:16] <whiprush> hi guys.
[04:16] <mjg59>            };
[04:16] <mjg59>         };
[04:16] <mjg59> Clearest. Code. EVER.
[04:17] <Keybuk> it could be worse
[04:17] <Keybuk> I used to have an employment contract with Demon Internet Ltd, which has a wholly owned subsidary of Thus Plc
[04:17] <Keybuk> but I used to get paid by ScottishPower Plc
[04:18] <whiprush> Keybuk: so, network-manager, you still want to kill people or do their .7 plans make you happy?
[04:18] <Keybuk> and all our equipment was owned by Thus Group Plc
[04:18] <Keybuk> etc.
[04:18] <Keybuk> whiprush: .7 plans?
[04:19] <whiprush> http://live.gnome.org/NetworkManagerToDo
[04:19] <Keybuk> oh, you mean 0.7 ?
[04:19] <whiprush> yeah
[04:19] <Ignite_> are there gtk+ 2.8 packages in the repos?
[04:19] <Hobbsee> whiprush: do we have an eta on 0.7?
[04:20] <whiprush> no idea, that's why i was asking
[04:21] <whiprush> although, if past history is to be a gauge it'll probably be out a few weeks into ubuntu's freeze. :-/
[04:21] <Hobbsee> whiprush: ah right
[04:21] <Hobbsee> heh
[04:21] <Hobbsee> whiprush: which freeze was that?  oh, feature freeze?
[04:21] <whiprush> yeah.
[04:22] <whiprush> iirc they always release things when ubuntu is frozen.
[04:22] <whiprush> and that makes scott angry. :)
[04:22] <LaserJock> whiprush: hehe, I sort of read that as "when hell freezes over" :)
[04:22] <mjg59> Oh god they've implemented locking through insanity
[04:22] <bddebian> heh
[04:23] <Ignite_> nvm
[04:23] <desrt> oh man.  i saw a textbook once that used ints for locking
[04:23] <mjg59>     forbidvtrelease = 1;
[04:23] <mjg59>     if (forbidvtacquire) {
[04:23] <mjg59>         forbidvtrelease = 0;
[04:23] <mjg59>         return;
[04:23] <mjg59>     }
[04:23] <mjg59> Yeah, that's never going to be a problem in a signal handler
[04:23] <desrt> their lock function, i swear, looked like this:
[04:23] <desrt> lock(int l)
[04:23] <desrt> {
[04:23] <desrt>   while (l);
[04:23] <desrt>   l = 1;
[04:23] <desrt> }
[04:24] <desrt> now boys and girls... tell me at least 4 things wrong with this function
[04:24] <crimsun> that's nearly as awesome as if (true && false)
[04:24] <desrt> crikey.
[04:24] <Hobbsee> heh
[04:24] <bddebian> Hey, is that MY code? ;-)
[04:27] <Keybuk> whiprush: *shrug* I'm not really bothered by n-m this cycle
[04:27] <Keybuk> if Debian update their packages, and the changes are useful, we can merge them
[04:27] <whiprush> Keybuk: heh
[04:27] <Hobbsee> whiprush: i think that's an invitation for you to take it over :P
[04:27] <Hobbsee> or someone else to
[04:27] <Keybuk> we're "a few weeks into freeze" already, after all
[04:28] <whiprush> that ^J guy still around?
[04:28] <zul> Hobbsee: be my guest
[04:28] <Hobbsee> zul: i know StevenK was looking at it.  i was just the tester.
[04:28] <ajmitch> Hobbsee: don't tempt me
[04:28] <Hobbsee> ajmitch: heh
[04:28] <Keybuk> Hobbsee: at the moment, I don't see why we need to diverge much from Debian
[04:28] <Hobbsee> Keybuk: true
[04:28] <zul> Hobbsee: but you are looking for things to do arent you :)
[04:28] <Keybuk> the kind of help that n-m needs is actually kernel people fixing wireless drivers
[04:28] <zul> Keybuk: there is no kernel bugs
[04:29] <Hobbsee> zul: heh.  yes and no.  i have to fix whatever fubar'd here first.  and i didnt fubar it.
[04:29] <Keybuk> Hobbsee: yeah, I fixed that
[04:29] <Keybuk> it bugged me that my laptop didn't work
[04:30] <Hobbsee> Keybuk: yay :)
[04:30] <Keybuk> it was siretart's fault
[04:30] <Hobbsee> Keybuk: hehe.  thanks :)
[04:30] <Hobbsee> Keybuk: haha.  isnt everything his fault?  *g*
[04:31] <Keybuk> whiprush: tbh, I can't see 0.7 being released much before edgy, if at all
[04:31] <ajmitch> Hobbsee: thanks
[04:31] <zul> night
[04:31] <Hobbsee> ajmitch: :P
[04:31] <whiprush> Keybuk: agreed
[04:39] <Ignite_> anyone know where i can find the file tag_c.h? (from taglib seems to be missing from the package, is this a bug?)
[04:42] <crimsun> libtagc0-dev.
[04:43] <infinity> Ignite_: Please take support questions to #ubuntu
[04:43] <Ignite_> thanks, i tried searching with apt-file but nothing came of it so assumed it wasn't in a package
[04:43] <Ignite_> infinity, ok no worries
[04:46] <bddebian> Heya infinity
[04:47] <mjg59> Holy christ this code makes me sad
[05:13] <bddebian> Keybuk: Still about?
[05:15] <Keybuk> yeah
[05:16] <bddebian> Keybuk: Are we stil using squashfs for the installer?
[05:16] <Keybuk> we're using it for the LiveCD, if that's what you mean
[05:16] <bddebian> Keybuk: I don't see any actual changes in your changelog entry? :-)
[05:17] <Keybuk> which?
[05:18] <Hobbsee> is someone around to upload kde-systemsettings to main for me, please?
[05:18] <bddebian> http://changelogs.ubuntu.com/changelogs/pool/universe/s/squashfs/squashfs_2.2r2-2ubuntu2/changelog
[05:18] <Keybuk> did you read the diff?
[05:18] <bddebian> No not yet, just found that entry interesting :-)
[05:18] <Keybuk> heh
[05:18] <Keybuk>  -- Scott James Remnant<EMAIL_ADDRESS>Fri, 26 May 2006 03:43:09 +0100
[05:18] <Keybuk> note time/date
[05:19] <Keybuk> that was Release Candidate day after 18 hours of debugging that
[05:19] <Keybuk> I had gone slightly crazy
[05:19] <bddebian> :-)
[05:19] <Hobbsee> heh
[05:19] <Keybuk> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368969
[05:19] <Ubugtu> Debian bug 368969 in squashfs-tools "Subject: rounding error causes generation of invalid filesystems" [Critical,Closed]
[05:21] <bddebian> That one I wasn't too worried about it's more the status indicator that Tolleg added?
[05:22] <Hobbsee> Keybuk: who do i assign things to, to get main stuff uploaded via LP?
[05:23] <Keybuk> "to get main stuff uploaded" ?
[05:24] <Hobbsee> Keybuk: to get a patch into a package in main.
[05:24] <sladen> Hobbsee: what patch, what package?
[05:24] <Keybuk> there isn't a formal sponsorship/mentor procedure yet
[05:24] <Hobbsee> sladen: bug 55135
[05:24] <Ubugtu> Malone bug 55135 in kde-systemsettings "kde-systemsettings trying to overwrite /usr/share/desktop-directories/kde-settings-accessibility.directory" [Untriaged,Fix committed]  http://launchpad.net/bugs/55135
[05:24] <Hobbsee> sladen: ^
[05:24] <Hobbsee> Keybuk: right.  that's a bit useless then :P
[05:24] <Keybuk> Hobbsee: e-mail one of the ubuntu-core-dev Kubuntu team members with the patch?
[05:24] <Keybuk> or attach it to the bug?
[05:25] <Hobbsee> no idea if they're around. might try that
[05:25] <Keybuk> Riddell appears to be subscribed
[05:25] <Keybuk> *shrug* it doesn't matter if they're around or not
[05:25] <Hobbsee> Keybuk: it does depend on whether they read their email though :P
[05:27] <LaserJock> surely they have a filter that send "Hobbsee" mail into a super special, high priority mail box ;-)
[05:27] <Hobbsee> LaserJock: heh
[05:27] <Hobbsee> LaserJock: no, not under "Hobbsee" - it's under "she who carries a big pointy stick and isnt afraid to use it on people"
[05:30] <Hobbsee> LaserJock: get it right :P
[05:34] <bddebian> Debian maintainer added progress and bugfix code to dpatch..
[05:36] <Burgundavia> Hobbsee: didn't you go for main upload privs at the last tb?
[05:36] <Hobbsee> Burg
[05:36] <Hobbsee> Burgundavia: yeah.  didnt get them.
[05:37] <Burgundavia> ah, too bad
[05:37] <Hobbsee> Burgundavia: they were in a rotten mood, and it's only been two weeks since i got MOTU.  that was the main problem.
[05:38] <Hobbsee> Burgundavia: seems longer than that though.
[05:39] <bddebian> Would linux-headers-2.6.17-5 replace linux-headers-2.6.17-1-all ?
[05:39] <crimsun> only if there's an explicit entry in debian/control
[05:40] <bddebian> crimsun: squashfs build-deps linux-headers-2.6.17-1-all
[05:57] <jdub> o/~ welcome to hotel motufornia, such a lovely place o/~
[05:57] <ajmitch> interesting..
[05:57] <Hobbsee> um, okay?
[05:58] <LaserJock> jdub: hehe, awesome
[05:58] <TheMuso> hehe
[05:58] <jdub> maybe you guys could do the lyrics :)
[05:59] <LaserJock> jdub: but we already have the HeMan theme song :/
[05:59] <TheMuso> jdub: Well whered you get the idea from in the first place?
[05:59] <bddebian> "By the power of Greyskull.."
[06:02] <jsgotangco> on a dark deserted rack server...
[06:04] <bddebian> Ubuntu disk in my haaand..
[06:04] <bddebian> I reformatted Windows...
[06:04] <jdub> TheMuso: hobbsee checking in but never leaving
[06:05] <TheMuso> um ok
[06:50] <Hobbsee> sfllaw: please dont point people at amarok bugs until 1.4.2 is released and in the archive :) - just saw your blog post on the planet
[06:50] <Hobbsee> oops, i thought that was in -bugs
[07:53] <pitti> Good morning
[07:54] <Burgundavia> morning pitti
[07:54] <pitti> Hey Burg
[07:55] <pitti> Hey Burgundavia
[07:55] <Hobbsee> hi pitti, Burgundavia
[07:55] <Burgundavia> greetings encore, Hobbsee
[07:55] <pitti> . o O { gah, my panel is broken }
[07:58] <Burgundavia> Kinnison: sad you have left us :(
[07:58] <desrt> legs@
[07:58] <desrt> erp
[07:58] <desrt> hello, pitti
[07:58] <Burgundavia> desrt: arms@ ?
[07:58] <desrt> Burgundavia; lots of biking
[07:58] <Burgundavia> ah
[07:59] <desrt> actually.. not even that much.. only a few km, but high gears and fast
[08:00] <pitti> hey desrt
[08:01] <desrt> pitti; we were wondering earlier
[08:01] <desrt> pitti; does ubuntu put money directly into your bank account with direct deposit?
[08:02] <Hobbsee> desrt: canonical, surely
[08:02] <desrt> Hobbsee; not so surely.  see scott.
[08:02] <Hobbsee> desrt: well, certainly not "ubuntu" anyway.  didnt think ubuntu was a company
[08:03] <desrt> chill, -pedantic
[08:03] <pitti> desrt: not ubuntu, of course, but canonical's bank does a bank transfer, yes
[08:03] <desrt> cool.  thx.
[08:04] <desrt> evil plans.
[08:04] <jdub> desrt: 'see scott'?
[08:05] <desrt> i need to know if my distruption of the world's financial network will have a significantly negative impact on ubuntu
[08:05] <desrt> jdub; scott is payed via some non-cononical company
[08:05] <jdub> desrt: UK employees
[08:05] <desrt> jdub; due to some weird arrangement required because cononical is isle of man
[08:06] <desrt> jdub; right.  but it was enough to place a bit of doubt in my mind if the rest of europe had a similar setup
[08:06] <jdub> desrt: even so, "ubuntu" is not correct in any case :-)
[08:07] <HrdwrBoB> and any sort of linux
[08:07] <HrdwrBoB> or indeed, software
[08:07] <jdub> desrt: would that include the ubuntu marketplace and partners?
[08:07] <desrt> i dualboot my laptop: ubuntu and ubuntu?
[08:07] <jdub> desrt: these distinctions do matter :)
[08:07] <desrt> jdub; i don't care.  whoever pays pitti's paycheques :p
[08:08] <jdub> desrt: in which case "not ubuntu" is the important distinction
[08:08] <desrt> chill, -pedantic :p
[08:08] <jdub> it's not pedantry
[08:09] <jdub> giving people the idea that ubuntu pays people really muddies things up
[08:09] <desrt> right.  but everyone here knows what everyone else means
[08:10] <Hobbsee> rotten thing.  konvi crashed.
[08:10] <Burgundavia> desrt: it is very good distinction, remember it
[08:10] <desrt> unless we have some onlookers
[08:10] <Burgundavia> desrt: we work and live in a fishbowl
[08:10] <jdub> desrt: i don't think that's true, which is why saying the right things is important
[08:10] <desrt> two lost souls?
[08:10] <desrt> jdub; to be totally honest with you, i'm always afraid that i don't know how to spell canonical
[08:10] <ajmitch> desrt: at some point, if not now, there'll be fulltime developers employed by other companies to work on ubunt
[08:11] <desrt> jdub; so i say 'ubuntu' instead to avoid the possible misspelling :)
[08:12] <Burgundavia> ajmitch: doesn't HP pay lamont to do some work on ubuntu?
[08:13] <desrt> ajmitch; how does that work, exactly?
[08:13] <ajmitch> Burgundavia: not that I know of - it could be true
[08:13] <jdub> desrt: (same way it does in gnome)
[08:13] <jdub> Burgundavia: no
[08:13] <desrt> jdub; not hardly
[08:13] <Burgundavia> ajmitch: he was still doing sort of behind the scenes work when I was at UBZ
[08:13] <desrt> jdub; the people who work on gnome are employed by redhat, novell, ...
[08:13] <ajmitch> desrt: just as some debian developers are currently employed to do stuff
[08:14] <jdub> desrt: ie. other companies.
[08:14] <desrt> is this part of the idea of people subclassing ubuntu?
[08:14] <jdub> desrt: the difference with ubuntu is that it's led by a company, but that doesn't preclude other companies working on it.
[08:14] <desrt> then they will contribute stuff upstream too?
[08:14] <jdub> either derivatives or directly on ubuntu itself
[08:15] <jdub> just as companies contribute to all kinds of other projects
[08:15] <jdub> commercially owned or not
[08:15] <ajmitch> I noticed that some of the points in the partners programme is employing a core dev fulltiem
[08:15] <desrt> redhat contributes to gnome because redhat sells gnome
[08:15] <desrt> you can't really sell a (non-derivative) ubuntu
[08:15] <jdub> of course you can
[08:15] <jdub> look at the ubuntu marketplace list
[08:16] <jdub> all those companies benefit from ubuntu itself
[08:16] <jdub> and can contribute directly to it
[08:16] <jsgotangco> they dont realize it
[08:16] <jdub> (regardless of derivatives - the case for guadalinex is more obvious)
[08:16] <desrt> aren't these support companise?
[08:16] <jdub> yes
[08:16] <desrt> hm
[08:16] <jdub> and hardware companies
[08:16] <jdub> and third party software companies
[08:16] <ajmitch> it's often sold as a service rather than as a product - not really much difference
[08:16] <desrt> ok
[08:16] <jdub> why does imendio contribute to gnome?
[08:16] <desrt> this makes some more sense now
[08:16] <desrt> ubuntu as a platform
[08:16] <jdub> (no one "sells" ubuntu btw)
[08:16] <desrt> to do [insert your business idea here]  on
[08:17] <jdub> (unless you count canonical selling ubuntu DVDs on amazon, but that's not in the same sense)
[08:17] <jdub> that is definitely not where the value lies
[08:17] <jamesh> jdub: and people reselling Ubuntu CDs on eBay :)
[08:18] <desrt> k.  i sort of get it.
[08:18] <jdub> jamesh: the forgotton value proposition
[08:18] <jdub> 'forgotten'
[08:18] <desrt> imendio contributing to gnome makes more sense than, for example, redhat
[08:18] <desrt> (in terms of explaning the ubuntu thing)
[08:18] <jdub> desrt: why? consider mepis.
[08:18] <desrt> i don't know mepis
[08:18] <jdub> desrt: it's just different companies seeing different value.
[08:19] <jdub> mepis is a commercial derivative of ubuntu
[08:19] <desrt> i see
[08:19] <jdub> but you're confusing model with value
[08:19] <jsgotangco> jdub: would linspire opening cnr to ubuntu a model or value?
[08:19] <jdub> jsgotangco: er, that's not an either/or thing
[08:20] <jdub> it's both and neither
[08:20] <jdub> depending on whether you think it's sane or not
[08:20] <jsgotangco> right
[08:21] <jdub> though i wasn't really distinguishing between dumb and good models, and i don't think desrt was misunderstanding it on those terms either ;)
[08:22] <jdub> desrt: you confused distribution model with the value of ubuntu
[08:22] <desrt> right.
[08:22] <jdub> a random linux consultant doesn't need her own distribution to derive value from contributing to ubuntu
[09:11] <pitti> Kamion: I'm a bit confused about the latest live images - they grew by a lot since yesterday, was this some experimental change which will be reverted, or do we need to kill more langpacks?
[09:14] <siretart> Hobbsee: /me isn't guilty. for anything.
[09:14] <Hobbsee> siretart: :)
[09:15] <Hobbsee> siretart: okay then.  it's fun to blame random people anyway though :)
[09:18] <ajmitch> Hobbsee: but not siretart. never siretart
[09:19] <Hobbsee> ajmitch: ah.  so i'l go back to blaming you
[09:19] <Hobbsee> man totem is screwed.
[09:21] <Hobbsee> ah.  totem-xine needs a dep on totem in dapper.  simple fix.
[09:22] <Hobbsee> and edgy.
[09:31] <Hobbsee> ajmitch: dont worry, you'll likely still get to upload stuff for me later anyway.
[09:31] <Hobbsee> evening sabdfl
[09:31] <ajmitch> Hobbsee: lucky me
[09:31] <pitti> hi sabdfl
[09:32] <Hobbsee> ajmitch: hah.  this is the problem of being a core dev.  of course, i might ask pitti instead, if you prefer
[09:32] <Hobbsee> it's not one of those evil kde things, either :P
[09:32] <pitti> Hobbsee: erm, you want totem-xine to Depend: on totem? that would be wrong
[09:33] <Hobbsee> pitti: why?
[09:33] <pitti> Hobbsee: because totem is an empty metapackage which depends on -xine | -gstreamer
[09:33] <pitti> Hobbsee: totem itself doesn't do anything
[09:33] <Hobbsee> pitti: seeing as -gstreamer does.  and it all breaks if you try to actually install -xine
[09:33] <Hobbsee> ah...didnt realise it was emtpy.
[09:33] <Hobbsee> *empty
[09:33] <Hobbsee> so it is :)
[09:34] <pitti> Hobbsee: totem-gstreamer doesn't depend on totem either )
[09:34] <Hobbsee> thanks.  ignore my idiocy.
[09:34] <pitti> hey dholbach
[09:34] <Hobbsee> hi dholbach!
[09:34] <dholbach> good morning
[09:34] <dholbach> hey pitti, Hobbsee!
[09:34] <Hobbsee> pitti: aye.  i'm a first class moron tonight then.
[09:35] <pitti> Hobbsee: it happens to all of us, don't worry
[09:35] <sabdfl> hey Hobbsee, pitti
[09:35] <dholbach> hey sabdfl
[09:35] <sabdfl> some usplash loveliness, then.... blank screen for me
[09:35] <Hobbsee> ah yes, so it's not my laptop just erroring at random?
[09:36] <dholbach> sabdfl: same here (on my x40) - it takes ages for gdm to come up :/
[09:36] <sabdfl> Hobbsee: what sort of laptop do you have?
[09:36] <Hobbsee> dholbach: and kdm, then.
[09:36] <Hobbsee> sabdfl: ah, toshiba a10 satellite?
[09:36] <Hobbsee> Sysinfo for 'sarah': Linux 2.6.17-5-686 running KDE 3.5.4, CPU: Mobile Intel(R) Celeron(R) CPU 2.40GHz at 2394 MHz (4793 bogomips), HD: 9/22GB, RAM: 665/995MB, 101 proc's, 3.7h up
[09:36] <dholbach> sabdfl: the harddisk is doing something, but i have no idea
[09:36] <dholbach> on amd64 it doesn't happen to me
[09:36] <Hobbsee> sabdfl: what information did you actually *want* from that question?
[09:37] <sabdfl> Hobbsee: tosh
[09:38] <Hobbsee> pitti: you didnt eat my brain, did you?  i'm seriously starting to wonder here...
[09:38] <imbrandon> sabdfl: yea i'm fighting that same exact problem on one of my desktops and this laptop as we speak
[09:38] <imbrandon> the usplash goodness and then a blank X screen
[09:38] <pitti> Hobbsee: heh, that was just in return for you stealing mine yesterday :-P
[09:39] <dholbach> maybe it'd help to install bootchart and inspect it afterwards :)
[09:39] <Hobbsee> pitti: :(...but...but...
[09:39] <pitti> heh, for me usplash doesn't work for me at all any more
[09:39] <pitti> svgalib goodness, I suspect
[09:39] <sabdfl> i'm sure mjg59 will nail it, i saw a late upload to usplash last night so he's on a roll
[09:39] <imbrandon> pitty looks awefull strange compared to my x86 on this iBook
[09:39] <Hobbsee> what, three in 2 days or something?
[09:40] <imbrandon> pitti: even
[09:40] <imbrandon> heh
[09:40] <pitti> Riddell: \o/ I just converted /usr/share/hal/scripts/hal-system-storage-mount to use pmount
[09:41] <imbrandon> pitti: yay
[09:41] <pitti> so KDE can now mount through hal and I can still sleep :)
[09:41] <imbrandon> yup yup
[09:42] <imbrandon> dholbach: you said gdm took forever to come up, how long is forever , i get a black screen for ~30 then i just kill kdm and use console
[09:42] <imbrandon> s/~30/~30 min
[09:43] <dholbach> 30 MIN?
[09:43] <dholbach> holy cow - no... maybe a minute or two
[09:44] <imbrandon> yea x seems borked for my x86 at the moment , like sabdfl i get uspalsh goodies then a black screen , swap to vt1/2 and no x server errors
[09:44] <imbrandon> i'm scared to upgrade my ppc till i fugure out what it is
[09:45] <imbrandon> s/fugure/figure
[09:45] <imbrandon> complains about a few fonts missing but thats normal
[09:47] <sabdfl> i can start in recover mode, then init 2 and it all comes up fine
[09:47] <imbrandon> hrm lemme try that, dident think to do that
[09:48] <sivang> hmm, that's cool - http://ubuntu.wordpress.com/2006/08/03/first-ubuntu-billboard-spotted/
[09:49] <imbrandon> sivang: yea , we should have some more goodies like that on theFridge soon too ( soon == ~24hrs )
[09:49] <imbrandon> heh
[10:03] <Nafallo> morning
[10:05] <hunger> imbrandon: Yeap, usplash is not really working well at the moment. It turned keyboard echo of my passphrases on:-)
[10:08] <kagou> hi
[10:08] <pitti> hi kagou
[10:10] <doko> Kamion, infinity: please approve openoffice.org-amd64 for dapper-proposed
[10:13] <imbrandon> ahh yea , dident even have to goto single user mode , just disable "splash" ( read usplash ) on kernel parms
[10:13] <imbrandon> then kdm is happy
[10:18] <Kamion> mjg59: thanks for that
[10:18] <pitti> Kamion: good morning!
[10:20] <Kamion> mjg59: for the record it would be really very tedious to arrange for usplash to be installed after X; I'd have to rip it completely out of the part of the installer where it's done at the moment (using custom code because we make sure it's installed just before the kernel) and put it somewhere completely different
[10:20] <Kamion> mjg59: so if I can avoid doing that it will make me happy. :)
[10:23] <Kamion> pitti: you mean the dapper live images, or edgy?
[10:26] <pitti> Kamion: dapper
[10:27] <RicardoPerez> pitti: hi. i'm waiting for the daily langpacks updates from yesterday. any news about that? thanks
[10:28] <Kamion> pitti: I'll have a look in a bit, try to figure out what's up
[10:52] <Kamion> doko: done
[11:00] <doko_> seb128, dholbach: what happened to /etc/pango/pango.modules in edgy?
[11:00] <pitti> RicardoPerez: the packs were built yesterday
[11:00] <seb128> doko_: same as in dapper?
[11:00] <pitti> RicardoPerez: but there are only new -en, -es, -fi, -fr, -fa, pt, -ru, and -zh packages, the rest of languages didn't see any updates since the recent -base update
[11:01] <seb128> doko_:
[11:01] <seb128> pango1.0 (1.12.2-0ubuntu2) dapper; urgency=low
[11:01] <seb128>   * move /etc/pango/pango.modules to /var/lib/pango/pango.modules
[11:01] <seb128>     and ship a default version in the package. This fixes a bad
[11:01] <seb128>     race during the upgrade of pango (ubuntu: #41297).
[11:01] <seb128>     update-pango-modules uses the new path too
[11:01] <seb128>  -- Michael Vogt<EMAIL_ADDRESS>Wed,  3 May 2006 18:02:28 +0200
[11:01] <doko_> seb128: at least I don't have the conffile in my edgy chroot
[11:01] <seb128> doko_: cf changelog I just copied
[11:02] <mvo> doko_: that changed during the dapper cycle
[11:02] <pitti> hey seb128, bonjour
[11:02] <seb128> hi pitti
[11:02] <seb128> pitti: how are you?
[11:02] <pitti> RicardoPerez: hm, apparently Rosetta didn't build a new tarball since July 25
[11:03] <pitti> seb128: after hacking hal/gvm this morning and yesterday, I feel great :)
[11:03] <RicardoPerez> pitti: mmmmmm
[11:03] <doko_> seb128, mvo: you know that I love these things not fixed or mentioned for ia32-libs-gtk?
[11:03] <pitti> RicardoPerez: I'm afraid I need carlos for that
[11:03] <RicardoPerez> pitti: after apt-get update && apt-get dist-upgrade, there's nothing to reinstall
[11:03] <pitti> RicardoPerez: yep, as I said, I didn't get any new data for over a week
[11:03] <seb128> doko_: I don't know what about ia32-libs-gtk enough to figure it doesn't respect the pango config
[11:04] <RicardoPerez> pitti: oh, ok. can you get the actual .po files from Rosetta and rebuild newer langpacks?
[11:04] <mvo> doko_: me neither, sorry
[11:04] <pitti> RicardoPerez: no, as I said, I need carlos for that; I don't have the necessary access
[11:04] <RicardoPerez> pitti: it's strange to have an empty template in Rosetta and a not-empty .mo file in langpacks...
[11:04] <doko_> seb128, mvo: but if a default version is shipped now, why can't I find it in my chroots?
[11:05] <seb128> doko_: in /var/lob/pango ?
[11:05] <RicardoPerez> pitti: oh, bad
[11:05] <seb128> doko_: in /var/lib/pango ?
[11:05] <seb128> doko_: if it's not I probably broke it with the merge from Debian, I'll have a look later (I'm on dapper atm)
[11:05] <doko_> seb128: but it's not copied into /etc/pango?
[11:06] <seb128> doko_: no, pango look to /var/lib/pango
[11:06] <seb128> "<seb128>     update-pango-modules uses the new path too"
[11:06] <doko_> seb128: for dapper as well?
[11:06] <seb128> yep
[11:06] <RicardoPerez> pitti: but I can download the .po files directly from Rosetta, and then I can convert it into a .mo file to replace the actual one...
[11:06] <doko_> ohh, nice :-/
[11:06] <seb128> doko_: cf the changelog I copied, "Michael Vogt<EMAIL_ADDRESS>Wed,  3 May 2006 18:02:28 +0200"
[11:06] <seb128> doko_: since may
[11:07] <doko_> seb128: did you adapt the ia32hack for pango?
[11:07] <seb128> probably not since I don't understand what this hack is about
[11:07] <doko_> you would, if you start OOo on amd64 ;-)
[11:07] <seb128> I though it was just to usr /usr/lib32
[11:08] <seb128> s/usr/use
[11:08] <doko_> we have to find the correct pango.modules.
[11:08] <seb128> "result = SYSCONFDIR "/pango32";"
[11:08] <doko_> and that's certainly not /var/lib/pango, because that file mentions /usr/lib
[11:08] <seb128> looks like it's using the SYSCONFDIR from pango
[11:08] <seb128> so no need to update anything?
[11:09] <doko_> seb128: I'm looking at bug 55016
[11:09] <Ubugtu> Malone bug 55016 in openoffice.org-amd64 "Filechhoser dialog shows strange symbols instead of text" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55016
[11:10] <seb128> hum
[11:10] <seb128> and copying to pango.modules to /etc/pango fixes the issue?
[11:10] <seb128> that's weird it doesn't happen on dapper if that's due to that
[11:11] <pitti> RicardoPerez: well, right, but you don't want to do that for the millions of .po files the language packs have...
[11:11] <dholbach> ooo seems to look in /usr/lib/pango/1.5.0/modules instead of /usr/lib32/pango/1.5.0/modules instead
[11:11] <pitti> RicardoPerez: also, what was the real problem again? are es_ES out of date, or is the problem that es_ES is present in the first place? (i. e. you actually want es and es_ES was removed)
[11:12] <seb128> dholbach: does copying pango.modules to /etc/pango fixes the issue?
[11:12] <doko_> I have to find out, but apparently /etc/pango32/pango.modules cannot be found anymore (although it's shipped in ia32-libs-gtk)
[11:12] <doko_> and then apparently the default config file is used, referencing /usr/lib, and not /usr/lib32
[11:12] <seb128> doko_: the patch from mvo does that:
[11:13] <seb128> -    file_str = g_build_filename (pango_get_sysconf_subdirectory (),
[11:13] <seb128> +    file_str = g_build_filename ("/var/lib/pango/",
[11:13] <seb128>                                  "pango.modules",
[11:13] <seb128>                                  NULL)
[11:13] <seb128> so right, it's possible it break your hack :/
[11:13] <dholbach> seb128: there's a pango.modules in /etc/pango already
[11:13] <doko_> seb128: nice, that basically breaks the ia32 hack ...
[11:13] <seb128> that's why I didn't want of that hack in the first place
[11:14] <seb128> hacks are easy to break, etc
[11:15] <mvo> doko_: so what can we do to fix it? pass a configure parameter ?
[11:15] <RicardoPerez> pitti: the problem is that there's a bad translation in es_ES that was removed in Rosetta but isn't reflected in the new langpacks. Actually, the es_ES locale must not be used for translation; we must use "es" locale instead (and, if you look at the es_ES templates in Rosetta, you can see they are empty). So, the /usr/share/locale-langpack/es_ES/LC_MESSAGES/ directory must be empty (or near empty).
[11:15] <seb128> anyway, I'll have a look later on it
[11:15] <doko_> seb128: well, you can argue that hardcoded module paths are broken as well :/
[11:15] <pitti> RicardoPerez: ah, ok, then I completely misunderstood you yesterday
[11:15] <doko_> seb128: I'll do it know, we need it for the CD build.
[11:15] <seb128> doko_: lot of application look for the config file at a known place
[11:16] <seb128> ok
[11:16] <seb128> doko_: it was broken on dapper then?
[11:16] <seb128> weird than nobody noticed
[11:16] <RicardoPerez> pitti: the es_ES templates in Rosetta was cleaned some time ago, and the old langpacks was ok, but it seems that the new langpacks are using old templates (before the "cleaning" process)
[11:17] <RicardoPerez> pitti: the bad translation is very annoying in Spanish, because formats the clock applet incorrectly (say "vie ago de 4" instead of "vie 4 de ago")
[11:18] <pitti> RicardoPerez: yep, now I understand the problem, that's easily fixable
[11:18] <RicardoPerez> pitti: oh, great! what can I do to help you?
[11:18] <pygi> pitti, whenever you have time and if you have time... ^_^
[11:18] <pitti> RicardoPerez: oh, that should be fine
[11:19] <pitti> pygi: what's the second part of that sentence? :)
[11:19] <doko_> seb128: ia32-libs-gtk wasn't uploaded after May 3, but it will be broken on the new CD's ...
[11:19] <pygi> pitti, the libburn discussion :P
[11:19] <seb128> doko_: ah, ok
[11:20] <RicardoPerez> pitti: of course, I'm at your orders :)
[11:21] <doko_> seb128: ok, the fix is to just ignore the patch, when running the binaries on amd64.
[11:22] <doko_> Kamion: ^^^ that's a showstopper for the CD's; preparing new pango1.0 and ia32-libs-gtk
[11:23] <pitti> Kamion: can I upload new language-pack-[gnome-] es-base packages to dapper-updates to remove the erroneous es_ES po files?
[11:23] <pitti> Kamion: see RicardoPerez 's problem above
[11:33] <Kamion> doko_: which, dapper or edgy?
[11:33] <Kamion> pitti: yes
[11:37] <pitti> Kamion, RicardoPerez: ok, I uploaded new Spanish gnome/kde/rest -base packages to dapper-updates
[11:37] <pitti> RicardoPerez: sorry for the confusion
[11:37] <doko_> Kamion: dapper
[11:37] <doko_> and edgy
[11:37] <RicardoPerez> pitti: oh, sorry me for to be very confused.... I'm Spanish and my English is not very good :)
[11:38] <RicardoPerez> pitti: and thanks again :)
[11:38] <pitti> no problem
[11:38] <pitti> RicardoPerez: the removal of po files is something I do not notice and will generally break
[11:38] <pitti> RicardoPerez: I have to talk with carlos to find a better process for that
[11:39] <RicardoPerez> pitti: sometimes is not a totally removed po files... sometimes is only an almost empty po file (like gnome-panel-2.0 template in es_ES locale, which has only one string translated...)
[11:39] <Kamion> doko_: hm, ok
[11:39] <Kamion> doko_: please let me know when there's something in the updates queue to review
[11:40] <pitti> RicardoPerez: empty PO files should DTRT, but nonempty es_ES files with wrong translations are the ones that hurt
[11:40] <pitti> brb, door bell
[11:41] <RicardoPerez> pitti: yes... there's a group of problems related one with another...
[11:42] <RicardoPerez> pitti: when carlos arrives I'll try to talk with him in order to clarify the problem (he's Spanish so my very bad English will not be a problem per se) :)
[11:43] <RicardoPerez> pitti: so, now, I will wait for the updates in dapper-updates, isn't it?
[11:48] <pitti> RicardoPerez: yep, they should arrive soon after Kamion acks them
[11:48] <doko_> seb128: mvo's "patch" should have been called hack as well ...
[11:49] <RicardoPerez> pitti: ok, great... i'll wait for that and i'll tell you if all is ok :)
[11:49] <RicardoPerez> pitti: thanks again
[11:49] <pitti> great
[11:49] <seb128> doko_: no doubt about that
[11:50] <mvo> doko_: err, my "patch" did fix a spectacular upgrade failure that was there for ages. basicly a upgrade of pango made everything explode between unpack and configure because there just was no working pango anymore
[11:53] <mvo> doko_: see #41297 for the rationale. I'm open for better solutions of course
[11:54] <seb128> mvo: I don't think he discuss the fix, just the hardcoded path for the config file :)
[11:56] <mvo> seb128: aha, ok. I could do a version that add "--with-pango-modules-path=" to configure but I guess that would be a bit intrusive for dapper
[11:57] <seb128> mvo: please don't, I think doko it just going to fix it with an another simple and ugly hack :p
[11:57] <doko_> mvo: doesn't help; it's pango, which hardcodes library pathes in config files.
[11:57] <seb128> mvo: I don't want to start having to run autoconf and patching the configure.in etc
[12:07] <Kamion> pitti: oh, we need to reupload ubuntu-meta for dapper if nothing else ...
[12:08] <Kamion> removing packages from the live seed requires that
[12:31] <doko_> mvo, seb128: please see http://people.ubuntu.com/~doko/pango/, if you "like" the beautified hack
[12:33] <mvo> doko: look good to me
[12:34] <mjg59> Kamion: Only X can do the resolution probing
[12:34] <doko> Kamion: pango1.0 uploaded to dapper-updates
[12:35] <seb128> doko: there is already a 0ubuntu2 to dapper-updates
[12:35] <seb128> doko: I've uploaded it yesterday
[12:35] <Kamion> mjg59: does usplash do update-initramfs on installation?
[12:37] <seb128> doko: change looks fine to me other way
[12:39] <doko> Kamion: is seb128's pango1.0 upload processed?
[12:39] <Kamion> yes
[12:39] <sladen> Kamion: yes
[12:39] <Kamion> Listing ubuntu/dapper (UNAPPROVED) 0/0
[12:40] <Kamion> mjg59,sladen: I suppose usplash *could* be installed later, then. It'd be slower and possibly not very elegant, though - need to think about it
[12:40] <Kamion> mjg59: and in any case you do still need a fallback for if X never gets installed at all
[12:41] <sladen> Kamion: personally I side with you about not /depending/ on X configuration having taken place.  If the information is available, use it.  If it's not, carry on as normal
[12:41] <Kamion> at the moment it never gets a chance to use information from X configuration on a fresh install, though, which isn't ideal
[12:42] <doko> ahh, ok pango1.0 not yet in the archive ...
[12:42] <sladen> Kamion: we could have a simple small usplash-xorg-resolution-something that depends on both usplash and xorg having been configured.  That way it can save and poke the values somewhere /if/ X ever does get configured
[12:42] <Kamion> ick
[12:43] <Kamion> messy having configuration spread out over multiple packages
[12:43] <Kamion> having it all in usplash and arranging to install usplash after xorg would be better than that ...
[12:44] <Kamion> doko: the source should definitely be there - the binaries are just being published now
[12:44] <mjg59> Kamion: If X isn't installed, it just defaults to 640x480
[12:48] <doko> Kamion: 0ubuntu3 uploaded
[12:54] <gnomefreak> dappers kernel was compilied with gcc3.4?
[12:55] <Kamion> mjg59: right, so that'll *work*, but isn't optimal
[12:55] <mjg59> Kamion: Exactly
[12:57] <Kamion> doko: I'm not sure I buy that. Won't we have exactly the same "debconf's GNOME frontend won't work during upgrades" problem while upgrading amd64 systems, which is what mvo fixed?
[12:59] <doko> Kamion: he unconditionally changed the location to /var/lib/pango/pango.modules
[12:59] <Kamion> doko: I'd have thought that we would always want to use /var/lib/pango/pango.modules, but maintain /var/lib/pango differently
[12:59] <doko> when running the i386 binaries on amd64, you'll find there the amd64 modules, but OOo like the 32bit ones
[12:59] <Kamion> doko: yes, but will /etc/pango32/pango.modules or whatever it is be valid during upgrades?
[01:00] <Kamion> grr, the pango packaging is awful, the .orig.tar.gz has a load of stuff in debian/
[01:00] <doko> /etc/pango32/pango.modules is just a static config file, it's not handled by any debconf script
[01:00] <doko> whole gnome packaging is awful ;-)
[01:00] <Kamion> /etc/pango/pango.modules isn't handled by any debconf script either
[01:01] <doko> mvo: maybe you could explain, what you did fix in the pango upgrade problem
[01:01] <Kamion> the point is that debconf *uses* pango and explodes when /etc/pango/pango.modules refers to older pango modules
[01:01] <Kamion> why would the same problem not happen with /etc/pango32/pango.modules?
[01:01] <doko> Kamion: the patch isn't applied on amd64. see the #ifdef ...
[01:02] <StevenK> Kamion: Have you got a sec?
[01:02] <mvo> doko: the problem was that the pango.modules is generated in the postinst. a new pango can change the location of the modules. this means that between unpack and configure pango (and therefore all of gtk) is unsuable - pretty bad when e.g. debconf-gnome is used
[01:02] <doko> Kamion: debconf doesn't use the 32bit version
[01:02] <mvo> but it seems to me that if the patch changes only the behaviour in a 32 bit envoronment that should be safe
[01:02] <mvo> because the native pango would still find the right modules
[01:03] <Kamion> doko: hmm, ok, I suppose that's a bit better
[01:03] <Kamion> StevenK: yea
[01:03] <Kamion> yeah
[01:03] <mvo> it is still the same race as before for any 32bit applications started between unpack/configure
[01:03] <Kamion> right, it's wrong in principle but probably won't break
[01:03] <mvo> yeah
[01:03] <Kamion> and maybe not even wrong - after all it's unconfigured
[01:04] <Kamion> it's just that everything debconf uses has to behave as if it's essential: yes to some extent
[01:04] <Kamion> and work even when unconfigured
[01:04] <dholbach> doko: pango packaging != gnome packaging :)
[01:04] <StevenK> Kamion: I've done an upload of krecipes multiple times and it seems to disappear into the ether. Are you able to poke incoming and see where it's going?
[01:04] <mvo> well, true. but it is not "really" unconfigured because it ships most of the modules it needs
[01:05] <mvo> so there is really no good reason (IMHO) to break like it used to be
[01:06] <doko> Kamion: is there still space on the amd64 ubuntu/edubuntu CD's? thinking about adding the 32bit gnome accessibility libraries
[01:07] <Kamion> doko: space on Edubuntu is unlikely
[01:07] <Kamion> doko: Ubuntu, unsure yet
[01:07] <Kamion> my inclination is not for dapper; I don't want to change desktop
[01:07] <Kamion> feel free for edgy
[01:08] <Kamion> StevenK: what weird mutant thing are you doing with your .changes files?
[01:08] <Kamion> http://librarian.launchpad.net/3600297/dpVGqQ36OFwV1RAhLkWdzLbT064.txt
[01:08] <Kamion> UploadError: Format out of acceptable range for changes file. Range 1.5 - 2.0, format 0.7
[01:08] <StevenK> Ahhh.
[01:08] <StevenK> That .changes file is special. Very special.
[01:08] <Kamion> it's a known bug that you didn't get mailed - cprov is working on fixing that
[01:09] <StevenK> So special it killed Soyuz, way cool.
[01:09] <Kamion> linda testing or something?
[01:09] <ajmitch> congratulatoins
[01:09] <StevenK> Kamion: Not exactly.
[01:09] <Kamion> it didn't kill Soyuz any more than any other malformed upload :)
[01:09] <StevenK> Kamion: I was trying to get -4ubuntu1 into the archive, and the orig between Debian and Ubuntu is different.
[01:10] <Hobbsee> oh, so *that's* why it keeps dying.
[01:10] <Kamion> traditional approach would be to build normally with the Debian working tree (patched as necessary) and the Ubuntu .orig.tar.gz in ..
[01:10] <StevenK> I did.
[01:10] <StevenK> However, I can't then run genchanges since I build using pbuilder, since debian/files doesn't exist.
[01:11] <Kamion> debian/files should only be needed for binary uploads
[01:11] <Kamion> dpkg-genchanges -S shouldn't care
[01:11] <StevenK> Now I'm trying to remember why the hell I couldn't get it to generate.
[01:12] <Kamion> if (not $sourceonly) {
[01:12] <Kamion>     $fileslistfile="./$fileslistfile" if $fileslistfile =~ m/^\s/;
[01:12] <Kamion>     open(FL,"< $fileslistfile") || &syserr(_g("cannot read files list file"));
[01:12] <StevenK> At least I haven't caused you to be cross with me.
[01:14] <StevenK> Oh, now I remember. I didn't want the orig to be uploaded.
[01:14] <StevenK> Mainly because it's close to 8MB.
[01:15] <Kamion> StevenK: if the orig is already in the archive, then just don't use -sa; dpkg-genchanges won't include it in a -4ubuntu1 upload anyway
[01:15] <Kamion> (by default)
[01:16] <Kamion> if the orig is not already in the archive, then you need to upload it either way
[01:16] <StevenK> Duh.
[01:16] <Kamion> doko: accepted; I'd like something less gross to be sorted out in edgy though ...
[01:16] <Kamion> the duplicate sysconfdir munging is pretty horrible
[01:16] <StevenK> I should read the dpkg-genchanges man page some more. :-/
[01:21] <StevenK> Let's see if Soyuz chokes on this .changes file.
[01:21] <StevenK> Kamion: Thanks for your help, by the way.
[01:21] <Hobbsee> oh dear, it's choking on the floor again.
[01:22] <doko> Kamion: too late ;) no, I really do not want to spend much more time on the ia32-libs packages.
[01:23] <Hobbsee> gnomefreak: nothing, nothing at all.  i dont kill things all the time, you know.
[01:23] <gnomefreak> darn
[01:23] <gnomefreak> :)
[01:23] <Hobbsee> gnomefreak: would you like me?
[01:23] <Hobbsee> to?
[01:24] <gnomefreak> :)
[01:24] <gnomefreak> the hot water heater guy if he doesnt get out here today please
[01:24] <Kamion> doko: not needing ia32-libs any more because 64-bit OOo works would qualify as less gross :P
[01:25] <StevenK> gnomefreak: The plumber?
[01:25] <gnomefreak> StevenK: no the propane isnt getting to the tank for some reason
[01:25] <dholbach> doko: how's 64bit ooo looking? is it too 'edgy' for edgy? :)
[01:25] <StevenK> gnomefreak: Ahh, the "Gas man"
[01:26] <doko> Kamion, dholbach: yeah, just install the openoffice.org-*-experimental packages, if you can live without java, the wizard and the binfilters.
[01:26] <StevenK> "Gas man" always made my juvinile mind crack up.
[01:26] <gnomefreak> lol
[01:27] <dholbach> doko: oh, that's a good start for amd64 already
[01:45] <zul> hey
[01:45] <ajmitch> hi zul
[02:06] <sabdfl> \http://blogs.sun.com/roller/page/coldrick#ubuntu_filesystems_usb_drives_and
[02:06] <sabdfl> do we do better in edgy?
[02:06] <mjg59> sabdfl: You were looking for me yesterday?
[02:06] <sabdfl> could someone post a reply on his blog?
[02:07] <sabdfl> mjg59: yes, to ask about Compaq / HP tablets
[02:07] <sabdfl> what mouse driver should I use? X is up fine
[02:07] <mjg59> sabdfl: What model?
[02:07] <sabdfl> TC1000
[02:07] <sabdfl> old
[02:07] <mjg59> Right
[02:07] <mjg59> I think there's some mad custom driver for that one
[02:08] <sabdfl> ok, not essential, i have a zillion other things to get working on the box first :-)
[02:08] <sabdfl> anybody know much about matchbox?
[02:09] <mjg59> Hm.
[02:09] <mjg59> Is video reinit broken on edgy?
[02:10] <mjg59> It would seem to be.
[02:10] <mjg59> thom: Did you have a chance to check on your x60s?
[02:10] <mjg59> My X40 just showed the symptoms of a failed vbestate restoration
[02:11] <Kamion> sabdfl: see http://wiki.ubuntu.com/ReplacementInit for the USB-in-fstab thing; it's known breakage in dapper, but needs a big subsystem replacement to fix in edgy - Scott's working hard on it
[02:12] <sabdfl> ok, cool - thanks!
[02:13] <Kamion> I've posted a comment to that effect
[02:14] <mjg59> sabdfl: Hrm, it claims to need some bizarro kernel driver
[02:14] <mjg59> sabdfl: I'll take a look
[02:15] <mjg59> sabdfl: Can you possibly stick the contents of all the files in /sys/bus/pnp somewhere?
[02:16] <mjg59> Oh, this driver is gross
[02:16] <mjg59> It bangs the PCI registers directly. I'm sure this can be done via ACPIPNP
[02:19] <mjg59> rodarvus: Any chance of including the driver from http://linux-tablet-pc.dhs.org/tc1k_drv.html ?
[02:21] <thom> mjg59: no, i didn't :(
[02:23] <jdub> morning
[02:23] <jdub> pants off
[02:23] <jdub> etc
[02:24] <rodarvus> mjg59, sure, do you need it *really* urgently, or it can wait a few hours?
[02:24] <thom> good morning jdub
[02:24] <mjg59> rodarvus: Not urgently
[02:24] <mjg59> rodarvus: It'll need some kernel loving anyway
[02:25] <rodarvus> mjg59, btw, I've seen you were the last uploader of xserver-kdrive - do you mind if I upload a new upstream version based on a current cvs checkout? (the old version ftbfs due to X.Org 7.1, apparently)
[02:26] <mjg59> rodarvus: Not in the slightest
[02:26] <rodarvus> 'k, thanks!
[02:26] <StevenK> rodarvus: That's also neatly listed on merges.u.c/universe-manual.html
[02:26] <mjg59> rodarvus: I'm quite short on time for the moment, so feel free to do anything with anything I've touched
[02:26] <rodarvus> StevenK, the debian changes basically say "stolen package from ubuntu", and changes the mantainer :)
[02:26] <jdub> i hear mjg59 is going to finish his thesis today
[02:27] <rodarvus> today!
[02:27] <StevenK> rodarvus: Haha
[02:30] <mjg59> Haha
[02:32] <rodarvus> mjg59, just for reference, I'm uploading xserver-kdrive_6.6.1+cvs20060804-0ubuntu1
[02:34] <mjg59> rodarvus: Cool
[02:41] <pitti> GAR
[02:41] <pitti> does anyone have experience with parsing xml in Python?
[02:42] <dholbach> pitti: what do you need?
[02:42] <jdub> pitti: use elementtree :-)
[02:42] <Kamion> I did a bit of it in debian-installer a while back
[02:42] <Robot101> elementtree ftw
[02:42] <Kamion> build/util/help-to-gfxboot.py - I just used xml.dom.minidom
[02:42] <Kamion> my documents were small enough for DOM not to be a problem
[02:42] <pitti> I tried xml.dom.minidom and xml.sax now
[02:43] <pitti> both just throw UnicodeEncodeError once there is a non-ascii char
[02:43] <pitti> dholbach, Kamion: http://people.ubuntu.com/~pitti/tmp/update-maps
[02:43] <pitti> writing to the console works, but as soon as I write into a file, or pipe through less, or something, it breaks
[02:45] <mjg59> Anyone here having the problem with X not starting cleanly with the new usplash?
[02:45] <pitti> I already googled, played around with various encoding tricks, but nothing helped
[02:45] <pitti> mjg59: hm, I have the problem that usplash entirely disappeared, but X works fine
[02:45] <mjg59> pitti: What resolution is your screen?
[02:46] <pitti> mjg59: 1280x1024
[02:46] <mjg59> pitti: Hm. Ought to work.
[02:46] <mjg59> pitti: This on PPC or x86?
[02:47] <pitti> mjg59: amd64
[02:47] <mjg59> pitti: Right
[02:48] <mjg59> pitti: Does it work from the console?
[02:48] <pitti> mjg59: how do I check?
[02:48] <mjg59> pitti: Change to the console, sudo usplash -x 1280 -y 1024
[02:50] <pitti> mjg59: that just generates an unkillable usplash process
[02:50] <pitti> mjg59: but no graphics output at all
[02:50] <mjg59> pitti: That's fun
[02:50] <mjg59> pitti: Can you strace it and try to figure out what it's doing?
[02:51] <pitti> mjg59: d'oh, I get an EPERM when trying to attach to the current process
[02:51] <pitti> maybe because it's in deep kernel sleep
[02:51] <mjg59> pitti: Ha
[02:51] <mjg59> pitti: Ok, that's going to be awkward
[02:51] <mjg59> What state is it in?
[02:51] <pitti> D+
[02:51] <mjg59> Weird
[02:51] <mjg59> Anything in dmesg?
[02:51] <pitti> oh, wait
[02:51] <pitti> I know why
[02:52] <pitti> mjg59: it's my crash reporter, it tried to gdb it, but now gdb hangs forever, too
[02:52] <mjg59> Oops
[02:52] <Kamion> pitti: debian-installer/build/util/help-to-gfxboot.py definitely processes UTF-8 data correctly
[02:52] <pitti> so apparently it crashed
[02:52] <pitti> Kamion: thanks, will look at that
[02:52] <Kamion> pitti: I had to .encode("UTF-8") whenever writing to sys.stdout
[02:52] <Kamion> which is annoying but AFAICS required
[02:53] <pitti> Kamion: ah, that might do the trick indeed; I tried various codecs calls, but apparently not to the right place
[02:53] <pitti> mjg59: ok, so running it under gdb immediately segfaults
[02:54] <pitti> mjg59: bt is totally unusable, just one ?? line and the rest of memory can't be accessed
[02:54] <mjg59> pitti: What version do you have?
[02:54] <mjg59> And what graphics chipset is this?
[02:55] <Spads> zul: ping
[02:55] <zul> Spads: pong
[02:55] <Spads> zul: So I see a tarball now in your Xen packages dir
[02:55] <pitti> mjg59: usplash 0.4-6, nVidia Corporation NV34 [GeForce FX 5200]
[02:55] <Spads> That has all relevant patches applied?
[02:56] <zul> Spads: you should download the tarball and the dsc file and do a dpkg-source -x *.dsc
[02:56] <Spads> thanks
[02:56] <pitti> mjg59: I'll build a debugging enabled version
[02:57] <Spads> zul: but you wager the xen-image package ought to just install, right?
[02:57] <zul> it should in theory but i havent run the kernel on dapper
[02:57] <mjg59> pitti: Ah, right
[02:57] <zul> you might have dependency problems though
[02:57] <mjg59> pitti: We have issues with x86emu and nvidia
[02:58] <Spads> zul: with the kernel?
[02:58] <mjg59> The vbesave call falls over entirely
[02:58] <Spads> the build-deps seemed to satisfy cleanly last I tried, and I don't see anything new in that .dsc
[02:58] <mjg59> pitti: I ought to be able to fix the segfault - hang on a sec
[03:00] <mjg59> pitti: Can you grab the source for usplash and then edit svgalib/src/x86-common.c
[03:00] <mjg59> And change REAL_MEM_BASE to 0x01000 and REAL_MEM_SIZE to 0xa0000
[03:01] <mjg59> Then see if that fixes the segfault
[03:01] <zul> Spads: yes because th kernel is made for edgy
[03:01] <Spads> hmmm
[03:01] <Spads> I'll have a look
[03:01] <zul> Spads: you can probably get the .config and download the xen-source deb and install it
[03:02] <pitti> mjg59: done, building
[03:02] <mjg59> pitti: Ta
[03:03] <jdub> whoa
[03:03] <jdub> hula upload
[03:04] <pitti> mjg59: still segfaults :(
[03:04] <mjg59> pitti: Hm
[03:05] <pitti> mjg59: ah, but now I have the -dbgsym.ddeb for free
[03:05] <mjg59> pitti: In the same way?
[03:05] <mjg59> Ah, cool
[03:05] <Lathiat> is this UUID= stuff for root= not workign with raid devices known?
[03:05] <Lathiat> its driving me nuts it keeps reverting :/
[03:07] <pitti> mjg59: http://paste.ubuntu-nl.org/19685
[03:07] <madduck> Lathiat: which mdadm version?
[03:07] <Lathiat> 2.4.1-6ubuntu1
[03:08] <mjg59> pitti: Jesus, what's it doing that low
[03:08] <mjg59> pitti: Ok, erm. Your job (should you wish to accept it or not) is to find a way to get REAL_MEM_BASE low enough that that read can succeed
[03:09] <pitti> mjg59: a 'way'? you mean experimenting with different values?
[03:09] <mjg59> pitti: Last time I tried, anything below 0x1000 didn't seem happy
[03:10] <mjg59> Oh, wait, hang on a moment
[03:10] <mjg59> pitti: Are you sure that backtrace is good?
[03:10] <pitti> mjg59: no, it's just what gdb's 'bt full' thinks is appropriate
[03:10] <mjg59> Here, line 68 of usplash_svga.c is int i=0
[03:10] <pitti> but it looks a bit like confusing ints with pointers
[03:11] <mjg59> Yeah
[03:11] <mjg59> I'm guessing that the x86emu code is confusing it
[03:14] <jdub> zul: is there a COW solution for use with xen guest filesystems?
[03:15] <zul> yeah i found a bunch of them yesterday let me dig it up for you
[03:17] <zul> jdub: http://jailtime.org/
[03:18] <zul> jdub: also if you want to use xen-tools http://www.debian-administration.org/articles/396
[03:19] <Spads> zul: got some time to help me with a few build problems?
[03:20] <zul> Spads: ill try..
[03:25] <jdub> zul: hrm, that doesn't seem to mention anything about doing COW
[03:25] <pitti> Kamion: works great now, thank you!
[03:25] <Kamion> cool
[03:27] <jdub> "It's hardly CoC."
[03:27] <jdub> ^ whoa
[03:27] <jdub> first time i've seen CoC used like that
[03:28] <zul> jdub: like images of other distros?
[03:28] <jdub> zul: having a base image and then COW files for multiple xen guests
[03:29] <zul> ah...
[03:30] <zul> jdub: http://wiki.xensource.com/xenwiki/COWHowTo
[03:30] <jdub> ahar!
[03:31] <jdub> ooh, parallax sounds interesting
[03:32] <pitti> Hobbsee: still here?
[03:32] <Hobbsee> pitti: heya!
[03:32] <pitti> Hobbsee: sorry for the delay, I'm writing that 'requestsponsor' script now
[03:33] <pitti> Hobbsee: heh, nothing :)
[03:33] <Hobbsee> pitti: ahh...nice :)
[03:33] <pitti> Hobbsee: unfortunately Malone doesn't allow email attachments, so we have to improvise a little
[03:33] <Hobbsee> pitti: ahh.
[03:34] <Hobbsee> pitti: your request merge script works relaly nicely, when the package is in debian.
[03:34] <Hobbsee> well, when the changelogs.debian arent borked.
[03:34] <Hobbsee> :P
[03:34] <StevenK> Or when changelogs.debian.net isn't broken.
[03:34] <pitti> Hobbsee: right, I take that script and transform it :)
[03:34] <StevenK> Damn, missed.
[03:34] <pitti> Hobbsee: changelogs.d.o is just lagging a bit
[03:34] <Hobbsee> hehe
[03:34] <StevenK> It's actually d.n
[03:35] <pitti> right
[03:35] <pitti> Hobbsee: something like 'debdiff oldversion.dsc newversion.dsc | requestsponsor' should be suitable, do you agree?
[03:35] <pitti> Hobbsee: or 'requestsponsor debdiff' (I'm going to support both)
[03:36] <Hobbsee> pitti: sounds good to me
[03:36] <rodarvus> mjg59, pig
[03:36] <rodarvus> oops
[03:36] <rodarvus> ping :D
[03:36] <rodarvus> damn keyboard
[03:37] <pitti> rodarvus: *tsk* :)
[03:37] <rodarvus> the url you passed to me is for a quite old driver (for X.Org 6.8)
[03:37] <rodarvus> but I believe this driver has been imported into modular X (and we already have it) , as xserver-xorg-input-fpit
[03:44] <mjg59> rodarvus: Hi
[03:45] <mjg59> rodarvus: Oh, cool
[03:45] <mjg59> Sorry for the confusion!
[03:46] <rodarvus> mjg59, np
[03:47] <rodarvus> btw, I've just checked. they're the same driver, renamed symbols everywhere (tc1k->fpit), slightly different licensing, and -fpit has support to one extra device.
[03:48] <Hobbsee> rodarvus: did you break anything while you were at it?  some people seem to be expecting edgy to be usable, for some reason.  maybe they need to be taught a lesson?  :P
[03:49] <rodarvus> nah, unfortunately the driver was already there - no chance to break it ;)
[03:49] <Hobbsee> rodarvus: ah darn!
[03:49] <rodarvus> but I'll upload an updated xorg-server in 1-2 hours, so stay tuned
[03:49] <Hobbsee> rodarvus: heh.
[03:50] <Hobbsee> great....
[03:50] <rodarvus> quite likely I'll upload ati and nvidia drivers later today too
[03:51] <Hobbsee> bah.  go ahead and break them.  i dont use them :P
[03:51] <rodarvus> Hobbsee, so theres a good chance you'll have your X broken by the end of the day :)
[03:51] <rodarvus> oh
[03:51] <Hobbsee> rodarvus: yay!
[03:51] <rodarvus> what driver do you use?
[03:51] <Hobbsee> hehe
[03:51] <rodarvus> I can brea^Wfix that too
[03:51] <Hobbsee> rodarvus: i've got an intel integrated card - which is great!
[03:51] <Hobbsee> hah
[03:52] <thom> echo "xserver-xorg-video-i810 hold"|sudo dpkg --set-selections #lalal
[03:52] <thom> a
[03:53] <thom> <-- coward, since he just got the thing to run in the right mode
[03:53] <rodarvus> thom, Breaks: xserver-xorg-video-i810 (<< <newversion>)
[03:54] <thom> bah, that's cheating
[03:54] <rodarvus> yeah
[03:54] <Hobbsee> rodarvus: heh
[03:55] <rodarvus> I'm in a good mood today :)
[03:55] <rodarvus> it's not like this all the time, though >:-)
[03:55] <Hobbsee> rodarvus: well, yeah.  of course.  even i, hobbsee-who-takes-everything-possible-as-a-joke, gets pissed off about things
[03:58] <seb128_> rodarvus: breaking xorg is running away until monday then? :p
[03:59] <seb128_> nothing like breaking edgy on friday afternoon ;)
[03:59] <rodarvus> seb128_, I was planning on take the day off monday :D
[03:59] <seb128_> hehe
[03:59] <jdub> Spads: http://perkypants.org/blog/2005/11/05/1131151921/
[03:59] <seb128_> good idea :p
[04:02] <Spads> jdub: http://crackmonkey.org/badpeople.jpg
[04:03] <dholbach> rodarvus will love to see bug 54596 fixed
[04:03] <Ubugtu> Malone bug 54596 in soyuz "karma for uploads" [Medium,Confirmed]  http://launchpad.net/bugs/54596
[04:03] <Spads> jdub: them cameras got Mexican Magical Realism.
[04:03] <jdub> ooh
[04:04] <rodarvus> dholbach, yeah, this way I'd be able to have 1 third of the Karma you and seb128_ have :)
[04:04] <jdub> Spads: dude, you are wearing a slashdot tshirt
[04:04] <Spads> jdub: that's because it is 1997
[04:04] <jdub> is that your excuse?!
[04:04] <jdub> i suppose it's reasonable
[04:04] <dholbach> rodarvus: we'll see ;)
[04:05] <rodarvus> and actually, I don't think I uploaded more than any of you two
[04:05] <rodarvus> you have done a *lot* of work on GNOME
[04:06] <dholbach> rodarvus: i'm sure there'll be a tv show soon where you can select prizes for your karma points
[04:07] <rodarvus> (about 250 uploads, since July 5th)
[04:07] <rodarvus> yeah, that would be nice :)
[04:07] <rodarvus> or they could give Playstation III to the top 5 karma
[04:07] <seb128_> that would be cool ;)
[04:08] <rodarvus> seb128_, you're on top 5, and we're not counting uploads yet :)
[04:09] <zul> dholbach: heh...that show was the old wheel of fortune in the states
[04:09] <rodarvus> dholbach, kamion has 400k karma points than you
[04:09] <rodarvus> quite likely you're on top 10
[04:11] <dholbach> YAY :)
[04:32] <doko> Kamion: ia32-libs-gtk_16.2 in dapper-proposed
[04:35] <bddebian> Hello
[04:36] <bddebian> Damn, the list of Universe merges is growing...
[04:36] <bddebian> BenC: ping?
[04:37] <rodarvus> siretart, ping
[04:38] <rodarvus> siretart, do you plan to update qemu soon?
[04:39] <rodarvus> our qemu package is currently outdated WRT to Debian, and broken, WRT booting OLPC qemu images
[04:39] <zul> rodarvus: *ahem* xen..
[04:39] <rodarvus> zul, yeah, that could be another option indeed
[04:39] <zul> we have 3.0 in universe
[04:39] <zul> for edgy that is
[04:40] <rodarvus> but I need to use another kernel on the host, right?
[04:40] <zul> well you need to use the dom0 kernel to start xen but you can use either dom0 or domU for the guest host
[04:41] <rodarvus> oh
[04:41] <rodarvus> OLPC kernels have no specific support on themselves :/
[04:41] <zul> ah ok..
[04:41] <bddebian> qemu is on the Merges list but I wasn't sure if I should touch it or not
[04:42] <zul> rodarvus: then qemu might be better..
[04:43] <rodarvus> I plan to ask for a UVF exception for qemu in 6 hours from now (~ 9:00 PM UTC) if I get no answer from sirestart until then
[04:43] <madduck> Lathiat: what exactly is the problem with mdadm?
[04:43] <Lathiat> madduck: well it just sits "Waiting for root filesystem" on boot
[04:43] <Lathiat> if i cahnge root=UUID=xxx to root=/dev/md2 in grub
[04:43] <Lathiat> it boots fine
[04:43] <Lathiat> (i also changed my fstab)
[04:43] <madduck> Lathiat: ah, that has nothing to do with mdadm then.
[04:44] <Lathiat> right, tho my question wasnt about mdadm but "are we aware this is broken" :)
[04:44] <madduck> that's a filesystem issue, not sure grub even supports UUID filesystem mounts.
[04:44] <bddebian> rodarvus: If qemu is in Universe you don't need a UVF exception
[04:44] <rodarvus> bddebian, a UVF exception from mdz is needed before merging the new qemu
[04:44] <Lathiat> madduck: well its been intentionally changed by the edgy stuff, so
[04:44] <madduck> Lathiat: but you mentioned raid, so my highlight got triggered. :)
[04:44] <Lathiat> madduck: ah right
[04:44] <Lathiat> i dont think its grub
[04:44] <Lathiat> it still has root(hd0,0)
[04:44] <Lathiat> bu root= on the linux command line
[04:44] <Lathiat> which i assume initramfs cares about
[04:44] <rodarvus> bddebian, in theory you need - its just more lax
[04:44] <Lathiat> madduck: what do you do with raid?
[04:44] <Lathiat> madduck: involved with the raid tools project or something?
[04:45] <tseng> rodarvus: universe has not had a UVF
[04:45] <madduck> i am the mdadm maintainer
[04:45] <tseng> rodarvus: so nothing to except
[04:45] <Lathiat> madduck: ah :)
[04:45] <bddebian> rodarvus: That would be news to me but I don't know shit apparently :-)
[04:45] <tseng> rodarvus: universe freeze is much later.
[04:45] <Lathiat> yeh im pretty sure this isnt mdadms fault :)
[04:46] <rodarvus> oh, ok then
[04:47] <rodarvus> I was mostly uploading stuff to main - thought UVF was enforced for universe already too
[04:47] <hunger> Looks like only physical filesystems get a /dev/disk/by-id/entry... lvm, etc. does not.
[04:56] <spike> hi thre
[04:56] <spike> is there any known prob with security.ubuntu mirror?
[04:56] <spike> it's timing out
[04:58] <pitti> spike: yes, it's known; bandwidth issues in the DC
[04:58] <elmo> spike: security.ubuntu.com shouldn't be - it'll be slow, but not timeing out
[04:58] <spike> I see, tnx
[04:58] <pitti> times out for me as well sometimes
[04:58] <pitti> as well as archive.u.c
[04:58] <spike> actually iy's not the only one timing out
[04:58] <spike> yeah, was gonna say that
[04:58] <spike> will wait, ta
[05:08] <dholbach> ** sfllaw is giving a motu school session #ubuntu-motu-school about bug triage
[05:08] <Riddell> Kamion: ubiquity kde frontend needs some fixes in dapper
[05:08] <Riddell> Kamion: http://muse.19inch.net/~jr/tmp/kde-ubiquity.diff
[05:09] <bddebian> rodarvus: qemu from Debian FTBFS :-)
[05:09] <Riddell> Kamion: no bzr branch I'm afraid
[05:09] <Riddell> Kamion: changelog "remove existing widgets when launching qtparted and mountpoints pages"
[05:12] <rodarvus> bddebian, yeah, I plan to fix that.
[05:12] <rodarvus> bddebian, you want to upload this package?
[05:12] <bddebian> rodarvus: Go for it :-)  I was just trying to "help"
[05:12] <siretart> rodarvus: it is on my list, I wanted to do it tonight
[05:12] <rodarvus> if so, make sure it boots olpc images, please
[05:13] <rodarvus> siretart, nice, I'll let you do it, then :)
[05:13] <rodarvus> bddebian, help is always appreciated!
[05:13] <bddebian> rodarvus: If you say so. :-)
[05:14] <rodarvus> siretart, I'd like to test your updated qemu package when it is ready (can be after upload)
[05:15] <siretart> rodarvus: ok. I'll ping you then
[05:20] <mdz> rodarvus: qemu is in universe
[05:21] <zul> hi mdz
[05:21] <rodarvus> mdz, thanks, I know - I just thought UVF was already enforced for universe (just more easy to get around with)
[05:22] <pitti> BenC: ping
[05:29] <sfkhooper> hey is this the right channel to get tips on how to resolve a compiler problem in ubuntu?
[05:31] <sfkhooper> is that a no then?
[05:31] <rodarvus> sfkhooper, no, that would be #ubuntu-toolchain, but only if you're finding bugs in the compiler itself
[05:32] <sfkhooper> no, setup problem
[05:32] <rodarvus> sfkhooper, people do not watch irc 100% of their times
[05:32] <rodarvus> then #ubuntu, quite likely
[05:33] <rodarvus> (or #gcc, but *shrugs*)
[05:33] <sfkhooper> ok, thanks
[05:33] <rodarvus> np
[05:37] <pitti> rodarvus: welcome to the sponsor team, and congrats for being the first member :)
[05:38] <rodarvus> pitti, heh, my pleasure :)
[05:39] <rodarvus> btw, LP is timing out on https://launchpad.net/people/pitti/+packages
[05:39] <rodarvus> pitti, I was wondering how sponsored packages show up
[05:39] <pitti> rodarvus: heh, I know
[05:39] <pitti> rodarvus: don't use mine, I have millions of packages (due to the langpacks)
[05:40] <rodarvus> (if the sponsored person appears as uploader, so we can track it in six months from now :) )
[05:40] <rodarvus> ohh
[05:40] <pitti> rodarvus: yes, it does
[05:40] <rodarvus> nice
[05:40] <pitti> rodarvus: Changed-By: should normally be the sponsoree
[05:40] <pitti> rodarvus: the only bit from the sponsor is the .dsc signature
[05:40] <rodarvus> *nods*
[05:40] <pitti> rodarvus: i. e. debuild -S -k<yourkeyid>
[05:49] <rodarvus> pitti, btw, just curious - do you plan to update thunderbird to 2.0RC in time for Edgy?
[05:49] <rodarvus> (since the same is likely to happen for Firefox)
[05:56] <icecrash> hi
[05:59] <BenC> pitti: pong
[06:00] <gnomefreak> it will be stable before release ( i dont see why not)
[06:10] <Kamion> Riddell: thanks, looking
[06:10] <Kamion> Riddell: hmm, I thought I found something in the qt documentation saying that del did .remove() under the covers. evidently not
[06:10] <Kamion> maybe only if the python del gets turned into a C++ del expediently
[06:11] <Kamion> Riddell: how are your tests going aside from that?
[06:12] <Riddell> Kamion: otherwise the qtparted back/forward stuff all works
[06:12] <Kamion> kewl
[06:12] <gnomefreak> Riddell: found a problem with 3.5.4 in edgy adn konq/mouse gestures
[06:13] <Riddell> gnomefreak: what's that?
[06:13] <gnomefreak> without trying to open link konq mouse icon bounces and lags bad cant do anything uless i move mouse than locks back up than move mouse again to free it
[06:14] <gnomefreak> s/uless/unless
[06:14] <gnomefreak> id say about 2 days this has been going on
[06:16] <Kamion> mdz: https://dogfood.ubuntu.com/distros/ubuntu/dapper.0 - does that look ok to you?
[06:17] <mdz> Kamion: this is the dapper-before-point-release snapshot?
[06:17] <Kamion> (^-- only accessible if you have the private launchpad client certificate, so most of you probably can't see that, but it'll be on production soon enough)
[06:17] <Kamion> mdz: yes
[06:17] <mdz> Kamion: I don't suppose I can login to the box and verify it properly
[06:17] <Kamion> mdz: do you have an account on mawson?
[06:18] <mdz> maybe
[06:18] <mdz> I really can't tell if it's OK over http
[06:18] <Kamion> mdz: I can give you the diff from dapper to dapper.0 though, it's pretty trivial
[06:18] <Kamion> well, actually I was interested in making sure that the naming was OK too
[06:18] <mdz> I do have an account
[06:18] <Kamion> /srv/launchpad.net/ubuntu-archive/ubuntu/dists/dapper.0
[06:18] <mdz> the naming is fine, and please do point me at the diff
[06:18] <Kamion> or ~cjwatson/dapper.0.diff
[06:19] <mdz> Kamion: no changes to restricted Packages files? that doesn't seem right
[06:19] <mdz> don't we have a new kernel in there?
[06:20] <LaserJock> mdz: could you apply the debdiff on Bug #54821 to matplotlib in dapper-updates?
[06:20] <Ubugtu> Malone bug 54821 in matplotlib "python-matplotlib won't install" [Untriaged,Confirmed]  http://launchpad.net/bugs/54821
[06:20] <mdz> or is it ABI-compatible?
[06:20] <mdz> LaserJock: ->Kamion; it may be a bit late
[06:20] <Kamion> mdz: dapper has not been updated yet
[06:21] <Kamion> so no Packages files differ between dapper.0 and dapper
[06:21] <LaserJock> mdz: grr, matplotlib in -updates now is broken
[06:21] <mdz> Kamion: oh, this is meant to be basically unchanged
[06:21] <Kamion> yes
[06:21] <mdz> +Description: Ubuntu Dapper.0 6.06
[06:21] <mdz> that's a little odd
[06:21] <Kamion> mm, that's the displayname I guess
[06:22] <Kamion> LaserJock: yes. I forget whether you're in -core-dev?
[06:22] <mdz> Kamion: did you try running the archive comparator?  it's smarter about things like Packages.{gz,bz2}
[06:22] <LaserJock> Kamion: I'm not, but it is a Universe package, does that make a difference?
[06:22] <Kamion> mdz: no, there didn't seem any point when none of the Packages files had changed
[06:23] <Kamion> LaserJock: please go ahead and upload then
[06:23] <mdz> the uncompressed ones haven't anyway
[06:23] <LaserJock> Kamion: k
[06:23] <Kamion> mdz: nor have the md5sums of the compressed ones
[06:23] <Kamion> or at least if they did then the Release file wasn't affected
[06:24] <pitti> rodarvus: maybe, I don't know yet
[06:24] <Kamion> cjwatson@mawson:~$ grep -- '^-.*Packages' dapper.0.diff
[06:24] <Kamion> cjwatson@mawson:~$
[06:24] <mdz> Kamion: looks OK to me
[06:25] <Kamion> yes, "Dapper.0" is the displayname
[06:25] <Kamion> also shows up at the top of https://dogfood.ubuntu.com/distros/ubuntu/dapper.0
[06:26] <Kamion> that's free-form, so I can make it be something else - perhaps just "Dapper"?
[06:26] <Kamion> or "Dapper r0", although I'm wary of introducing rN notation when we're not using it elsewhere
[06:27] <Kamion> I think "Dapper" would probably be best
[06:31] <Kamion> (changed on dogfood)
[06:40] <doko> Kamion: pitti found one more upgrade error in the dapper-proposed packages, plus 2.0.3 does seem to have at least some regressions (bug 55167, 55181), so maybe it's not yet ready for dapper-updates. I could fix the upgrade error now, but it won't be in the archive before tomorrow morning
[06:40] <Ubugtu> Malone bug 55167 in openoffice.org "OOo Calc crashes when using Auto filter" [Untriaged,Confirmed]  http://launchpad.net/bugs/55167
[06:40] <Ubugtu> Malone bug 55181 in openoffice.org "Cut does not work when Auto Filter applied" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55181
[06:40] <Kamion> doko: ok, thanks. if there are regressions at this point, let's leave it out of the point release and consider it for a future update
[06:41] <Kamion> doko: thanks for trying
[06:42] <doko> Kamion: ia32-libs-gtk 16.2 still needs to be included
[06:43] <Kamion> doko: oh yes, I'll review that now
[06:45] <Kamion> doko: accepted
[06:46] <Kamion> mvo: you should really put a newer app-install-data-commercial into edgy at some point; it won't get synced in automaticaly
[06:46] <Kamion> +l
[06:47] <mvo> Kamion: ok
[06:49] <philipacamaniac> is seb128 the totem-gstreamer maintainer?
[06:52] <Kamion> evand_: migration-assistant binaries accepted into universe, FYI
[06:53] <RicardoPerez> pitti: hi! I'm just installed the updated langpacks and all works like a charm. thanks a lot :)
[06:54] <thom> mjg59: oh, also, with new usplash the boot process doesn't change to the correct  vt when it needs to prompt me for my crypted volume password
[06:57] <doko> dholbach: not the nicest day for the Biergarten ...
[06:58] <Kamion> mdz: +Build-Depends: debhelper (>= 4), libcairo2-dev, graphviz-dev (> 2.8-2.1), libxml-parser-perl, pkg-config, gettext, libgnomeui-dev, libgtk2.0-dev
[06:58] <dholbach> doko: if it's too harsh we can still go somewhere else
[06:58] <Kamion> mdz: archaic dependency relationship syntax there in graphviz-cairo ;-)
[06:59] <mdz> Kamion: heh, I'm surprised lintian didn't warn about that
[07:00] <mdz> or dpkg-checkbuilddeps
[07:02] <jdub> hey mdz
[07:03] <mjg59> thom: Yeah, there's a bug open about that
[07:03] <mjg59> thom: Which version of usplash?
[07:03] <mdz> jdub: hello
[07:03] <thom> 0.4-6
[07:04] <mjg59> thom: Can you try -7 or -8 and see if they behave the same way?
[07:06] <gnomefreak> mjg59: did you release -7 or -8?
[07:06] <thom> i can
[07:07] <mjg59> Oh, no you can't
[07:07] <thom> ok
[07:07] <thom> i won't then. fine.
[07:07] <doko> dholbach: but maybe we should meet there?
[07:07] <mjg59> Hang on a minute
[07:08] <dholbach> doko: of course
[07:08] <dholbach> doko: everybody's going there
[07:08] <dholbach> doko: i'll check how to get there and soon be off
[07:14] <mjg59> thom: Ok. -9 when it hits the archives.
[07:15] <siretart> rodarvus: now I remember about qemu: I already merged on on jul 30, but the package ftbfs in edgy on amd64
[07:15] <jdub> how do we request for things to attempt a build again?
[07:15] <rodarvus> siretart, but you didn't upload it, did you?
[07:16] <siretart> rodarvus: no. I don't  like to upload broken packages
[07:16] <Kamion> jdub: ask somebody in the launchpad-buildd-admins team to requeue it
[07:16] <siretart> rodarvus: I can send you the buildlog if you like
[07:16] <siretart> I fear the problem is with our linux-header package
[07:17] <jdub> Kamion: ta
[07:17] <jdub> 'course, none of them are around ;)
[07:17] <dholbach> have a nice weekend everybody
[07:17] <siretart> debian builds against linux-kernel-headers_2.6.13+0rc3-2.1, we build against linux-kernel-headers_2.6.17-5.16
[07:17] <gnomefreak> you too dholbach
[07:18] <rodarvus> siretart, I'd really like to have this package ready soon (say, in the next two days) - I can try to fix this if you want.
[07:19] <siretart> rodarvus: sure just go ahead. I fear you will have to adapt qemu for the new linux-headers
[07:19] <bddebian> Same issue for squashfs :-(
[07:20] <rodarvus> siretart, I'll take it this evening then, thanks!
[07:20] <siretart> bye dholbach
[07:20] <bddebian> Enjoy dholbach
[07:21] <dholbach> bye siretart, bddebian
[07:21] <mdz> sfllaw: how goes the test plan for knot 2? we have a bunch of features in beta now
[07:21] <bddebian> Is BenC about yet?
[07:26] <Kamion> mdz: could you do https://launchpad.net/distros/ubuntu/+addrelease based on https://dogfood.ubuntu.com/distros/ubuntu/dapper.0, please?
[07:26] <Kamion> mdz: +addrelease requires launchpad.Admin, so I can't do it myself
[07:27] <Kamion> mdz: the Soyuz guys are ready, although they're unsure about spitting out dists/dapper.0 as yet; that may have to happen later - but it'll all be safely in the DB in the meantime
[07:27] <mdz> Kamion: not sure what you mean by "based on ..."?
[07:27] <mdz> I assume it should be based on the Dapper on prod
[07:28] <mdz> and the new release called dapper.0
[07:28] <Kamion> mdz: I mean filling in the same arguments as I did on dogfood
[07:28] <Kamion> yes
[07:28] <mdz> oh, I see
[07:28] <Kamion> I've asked cprov if he can figure out some way to cowboy the creation of dists/dapper.0
[07:28] <mdz> based on /+edit
[07:29] <Kamion> apparently it requires a "careful" publisher run, which without cowboying will rewrite /dists/dapper
[07:29] <Kamion> +edit and +admin
[07:29] <cprov> Kamion: all old _dists_ files, in fact
[07:29] <Kamion> right
[07:30] <Kinnison> Kamion: Umm, why do you have to careful the dapper distrorelease?
[07:30] <mdz> Kamion,cprov: what should Version be for this?
[07:30] <Kamion> mdz: 6.06
[07:30] <mdz> that won't clash with the existing Dapper?
[07:30] <Kamion> Kinnison: 16:29 < cprov> Kamion: I needed to run a *careful* publishing to get _apt-stuff_ (pkglist, overrides, etc) for dapper.0
[07:30] <Kinnison> umm, odd
[07:30] <Kamion> mdz: apparently it doesn't matter, and we'll be updating the existing dapper to 6.06.1 soon enough anyway
[07:30] <mdz> ok
[07:31] <Kamion> making the archival copy have the same version as the original seems prudent
[07:31] <mdz> https://launchpad.net/distros/ubuntu/dapper.0
[07:31] <Kamion> mdz: thanks. can you make that status supported in +admin too?
[07:32] <mdz> done
[07:32] <mdz> hmm, no it isn't
[07:32] <mdz> it rejected my submit because I didn't fill in a changes list
[07:32] <mdz> seems like a bug to me
[07:32] <Kamion> yes, I got that too on dogfood
[07:33] <Kamion> I just filled in<EMAIL_ADDRESS>[07:33] <mdz> filling in dapper-changes for now
[07:33] <mdz> did you file the bug?
[07:33] <bddebian> Damn bashisms
[07:33] <Kamion> mdz: no, forgot to
[07:33] <Kamion> shall I?
[07:33] <mdz> I will
[07:33] <Kamion> ok
[07:34] <Kamion> mdz: needs to be "pre-release freeze" not "supported" for the moment, so that the publisher works properly
[07:34] <Kamion> we'll then set it to supported and publish again
[07:35] <mdz> oh
[07:35] <mdz> done
[07:36] <jdub> mdz: is there a part of the release process that involves unsticking broken builds in a systematic way (like the merge process)?
[07:36] <mdz> jdub: there's a general "make sure everything has built and is buildable" process
[07:37] <mdz> it's mostly an ongoing thing handled by infinity, but we do a full round of test builds at a couple of points during the release process
[07:37] <jdub> right
[07:37] <jdub> coo
[07:37] <jdub> l
[07:37] <jdub> do we know # unbuilt packages for each release?
[07:37] <mdz> LP should be able to tell you that
[07:37] <Kamion> britney can too
[07:38] <Kamion> jdub: it's also in MilestoneRhythm
[07:38] <Kamion> we don't bother running britney for released suites, but we do for edgy - http://people.ubuntu.com/~cjwatson/testing/edgy_outdate.txt
[07:41] <jdub> Kamion: that shows difference between source and binary?
[07:41] <Kamion> jdub: yes
[07:42] <Kamion> when all builds are up to date, there are zero differences
[07:43] <tseng> beagle 0.2.7-1ubuntu1 python2.4-beagle(i386) 0.2.7-0ubuntu2 from 0.2.7-0ubuntu2
[07:43] <jdub> oh, and that's just main? does the followup mdz's talking about apply to universe (maybe less vigorously)?
[07:43] <tseng> i guess this just means its in NEW as opposed to me doing something wrong
[07:43] <jdub> tseng: i noticed beaglefs was accepted - want to take it over? :)
[07:44] <tseng> jdub: nope.
[07:44] <tseng> jdub: I thought ajmitch signed up, though
[07:44] <tseng> he listed himself as maintainer when he uploaded it
[07:44] <tseng> because he knew you wouldn't last long :)
[07:44] <jdub> he said he'd do debian uploads, but not sure he was willing to maintain it
[07:45] <tseng> he wouldnt upload something to Debian w/o expecting to take care of it
[07:45] <jdub> beaglefs is surprisingly cool
[07:45] <jdub> we need to figure out how to best make use of fuse though
[07:46] <wasabi_> I'm working on a ... sort of test case project on a fuseish thing to replace gnomevfs.
[07:47] <wasabi_> Nobody likes that idea though.
[07:47] <wasabi_> cd /fs/cifs/servername/share   etc
[07:47] <wasabi_> Memories of autofs.
[07:54] <bddebian> OK, I have squashfs building with linux-headers-2.6.17-5 .  Would someone want to check it over before I upload it?
[07:55] <siretart> bddebian: what did you do to fix it?
[07:57] <Kamion> http://people.ubuntu.com/~cjwatson/tmp/dapper-to-current-proposed.sizediff <- package size changes for the packages on the powerpc alternate install CD from dapper release to now, including dapper-proposed
[07:58] <Kamion> ignore the kernel stuff, that's an artifact of package name changes
[07:58] <Kamion> jdub: we don't run britney for universe - last time I tried, I got bored and killed it after six hours
[08:01] <elmo> Kamion: on drescher or somewhere else?
[08:01] <terre1> hi. What is "dapper.0" ? edgy  6.10  (DEVELOPMENT)   dapper.0   6.06  (FROZEN)  dapper  6.06    (CURRENT)
[08:01] <elmo> Kamion: and is britney still doing the NP stuff even in "show me uninstallables" mode?
[08:02] <Kamion> elmo: I think I tried both rookery and drescher
[08:02] <Kamion> elmo: probably, yes
[08:02] <Kamion> at least I assume so from the vastly increased runtime for universe
[08:02] <elmo> ah, ok
[08:03] <Kamion> hmm, the total there is 5MB, that doesn't explain the 10MB diff in CD size
[08:03] <Kamion> what is going on
[08:04] <iwj> I have a machine with a newly-acquired and -configured ethernet interface, which has been set up using ifconfig et al.  For some reason I don't understand it insists on faffing about with ICMPv6 router and neighbour solicitations before it will let me do IPv4 over it.
[08:05] <iwj> DoeS aNyBody know how I can hit this stupid behaviour over the head ?
[08:07] <bddebian> siretart: Just build-dep linux-headers-2.6.17-5 instead of 2.6.17-1-all.  And fixed some bashisms in debian/rules
[08:07] <Kamion> ok, I've LOST 5/6MB, this is seriously not funny
[08:12] <bluefoxicy> Can someone move tremulous from multiverse to universe?  Apparently it's 1) Hosted on sourceforge; 2) GPL code and "The media is licensed under the CREATIVE COMMONS ATTRIBUTION-SHAREALIKE 2.5 LICENSE."
[08:12] <bluefoxicy> as I understand Multiverse == redistributable but not under a Free license?
[08:12] <Kamion> bluefoxicy: tremulous depends on tremulous-data, which is not free
[08:13] <mjg59> CC 2.5 isn't considered free
[08:13] <Kamion> main+universe is closed under dependency
[08:13] <bluefoxicy> mjg59:  CC2.5 isn't a free license?
[08:13] <mjg59> No
[08:13] <mjg59> 3.0 should be
[08:13] <Kamion> but next time, file a bug on the package in question and subscribe ubuntu-archive to the bug
[08:13] <bluefoxicy> huh.  Why not?
[08:14] <bluefoxicy> Kamion:  yes, #-motu is slapping me with that too
[08:14] <iwj> ip -f inet6 addr delete dev ${vif} local fe80::fcff:ffff:feff:ffff/64
[08:14] <iwj> WTF??
[08:14] <iwj> There must be a better way!
[08:19] <bddebian> do be do be dooo
[08:19] <Riddell> pitti: your cdbs upload failed to build
[08:20] <Riddell> pitti: I have some changes to make but I'm scared to upload since then it'll be my responsibility :-/
[08:40] <pitti> Riddell: curious, I just changed the cdbs-edit-patch script
[08:40] <pitti> Riddell: don't worry, if your upload fails, too, I'll care for it on Monday
[08:55] <jdub> hrm
[08:56] <jdub> can anyone think of a relatively small, C-only, no shlib depends package?
[08:56] <tseng> no shlib depends..
[08:56] <Robot101> no libc?
[08:56] <Kamion> *no* shlibdeps? not even libc?
[08:56] <jdub> ha ha
[08:56] <tseng> yarrrrr
[08:56] <Robot101> Package: hello
[08:56] <Robot101> Depends: libc6 (>= 2.3.2.ds1-4)
[08:56] <jdub> libc is okay :-)
[08:56] <Robot101> thats quite minimal :)
[08:57] <jdub> Robot101: hrm, maybe something slightly more interesting ;)
[08:57] <Robot101> the GNU hello world, of course, reads your mail too.
[08:58] <jdub> gosh i'm glad that hello is in main
[08:58] <robertj_> https://wiki.ubuntu.com/AlwaysEnableUniverseMultiverse needs a DumbestIdea award
[08:59] <jdub> hrm, i guess i could use procmail
[08:59] <tseng> robertj_: I am sure you can easily understand the motivation
[08:59] <tseng> It just needs a slightly different fix
[09:00] <robertj_> tseng: yes, but I also understand the motivation to hit your high-school teacher in the face, but you don't do it
[09:00] <tseng> jeez.
[09:00] <robertj_> (ok, maybe overstating the point a bit ;)
[09:00] <tseng> it is hardly a dumb spec
[09:00] <tseng> a better fix imo would be making it easier to find packages in universe and enable it for use
[09:00] <jdub> one of my high school teachers got married right when i was in the middle of a crush
[09:01] <tseng> in $graphical-apt-frontend
[09:01] <tseng> which isnt nearly as easy given how apt is built
[09:01] <tseng> before assuming an idea is idiotic, I look at "#
[09:01] <tseng> before assuming an idea is idiotic, I look at "Created: 2006-06-20 by MichaelVogt
[09:01] <tseng> sigh, irssi
[09:01] <tseng> mvo is a pretty brilliant fellow if you ask me.
[09:02] <tseng> and understands apt and graphical package management better than both of us
[09:02] <tseng> jdub: rough!
[09:03] <tseng> :)
[09:03] <robertj_> mv cookie /proc/irc/mvo
[09:05] <bluefoxicy> jdub:  a crush on your teacher is... kinda eww... way too old.
[09:07] <robertj_> bluefoxicy: teachers might only be 23, it's not that unusual
[09:07] <jdub> ...
[09:07] <jdub> o/` IT'S NOT UNUSUAL... o/`
[09:07] <mjg59> 23?
[09:07] <bluefoxicy> robertj_:  I'm 21 and I wouldn't go near anyone >23
[09:07] <mjg59> bluefoxicy: Tch.
[09:07] <mjg59> You're missing out.
[09:07] <Spads> jdub: you exposed a hole in my triggers
[09:07] <Spads> 20:07  3: -publics -regexp 'o/~' -replace ''
[09:08] <bluefoxicy> mjg59:  not at all, age of consent here is 16.  ANYWAY.
[09:08] <jdub> Spads: haha
[09:08] <Spads> 20:07  2: -publics -regexp '<3' -replace ''
[09:08] <Spads> I also have interrobang
[09:08] <Spads> and this one:
[09:08] <Spads> 20:07  7: -publics -regexp 'lol' -replace '*drooling noise*'
[09:09] <jdub> what if i say lollypop?
[09:09] <Spads> jdub: I need to fix that
[09:09] <jdub> ha ha ha
[09:09] <Spads> 20:09 <jdub> what if i say *drooling noise*lypop?
[09:09] <jdub> Spads: pro. ;)
[09:09] <jdub> meanwhile
[09:10] <jdub> roflcopter
[09:10] <Spads> I think the lesson is: DON'T SAY LOLLYPOP
[09:10] <jdub> llvm built
[09:10] <bluefoxicy> llvm?  o_o
[09:11] <bluefoxicy> Wait are you trying to do 686 Ubuntu by llvm'ing the 486 code through a binary optimizer to spit out 686 code?
[09:14] <jdub> ahr, bollocks, it failed
[09:16] <poningru> sorry to disturb but quick question
[09:16] <poningru> who does shipit?
[09:16] <poningru> that I can bother on irc
[10:02] <jdub> o/` one fine day, you're gonna want me for your girl o/`
[10:05] <zul> later..
[10:08] <bddebian> Heya
[10:14] <robertj_> what do you guys think of a red, yellow, green light for update urgency?
[10:15] <robertj_> for instance, remote root woud be "red" while "obscure driver fix" would be green
[10:16] <jdub> Spads: ping
[10:18] <robertj_> or something of the sort, I suppose no emblem, local security issue, and "uhoh, openssh has been owned"
[10:42] <Kamion> ahh
[10:51] <Kamion> cjwatson@rookery:~/public_html/seeds/edubuntu-dapper$ bzr pull
[10:51] <Kamion> Using saved location: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/edubuntu.dapper/
[10:51] <Kamion> bzr: ERROR: These branches have diverged.  Try merge.
[10:51] <Kamion> how did that happen ...
[10:53] <Kamion> ouch, there are a big pile of changes missing from the edubuntu.dapper seeds on bazaar.launchpad.net
[11:19] <Kamion> ogra: have you tested the current http://cdimage.ubuntu.com/edubuntu/dapper/ bits at all?
[11:19] <Kamion> ogra: the install CD will probably be broken - I'm regenerating it shortly
[11:20] <Kamion> hmm, no janimo around
[11:24] <Kamion> Riddell: we need to cut down Kubuntu live a bit, probably language packs
[11:24] <Mirv> is the new ubuntu-desktop/ubuntu-meta meaning that Finnish is not going be included on live-i386 6.06.1 CD:s? it'd be unfortunate for it to change now, though I guess you have to drop some if you have to drop some :(
[11:24] <Kamion> Riddell: subtract 4MB or so off the currently reported CD size for powerpc
[11:25] <Mirv> the guides etc. are now assuming (in screenshots) that the translations are there
[11:25] <Kamion> Mirv: I'm afraid so
[11:25] <Kamion> we just ran out of room as the language packs grew
[11:26] <Kamion> fi has never been on the priority list (which is indexed by number of speakers); it just snuck in by virtue of being relatively early in the alphabet
[11:26] <Kamion> Mirv: note that it was only ever there for i386, not for amd64 or powerpc
[11:26] <Kamion> those architectures never had room for it in the first place
[11:26] <Mirv> Kamion: yes, I actually gathered as much during dapper that it was in there by luck mainly (there's only 5 million of us, though quite a lot of computer users of course)
[11:28] <Mirv> well, it's a problem that will be there anyway for some languages, unless edgy/edgy+1 can get this resolved with 7-zip&co
[11:28] <Kamion> at this rate, Kubuntu is going to have to lose more than that
[11:28] <Mirv> thanks for the info, I was just getting a clarification
[11:28] <bluefoxicy> has anyone actually tested p7zip or lzma compresesd debs yet?
[11:29] <Kamion> IMHO it's a flaw in the language pack system (the language packs wouldn't need to be so big if they only had what's needed for desktop, although that is not a remotely trivial change to try to make and would probably involve ditching language packs entirely to do halfway sanely, so I doubt it'll ever happen)
[11:29] <Kamion> but there, we have to make do
[11:30] <Kamion> bluefoxicy: considering current dpkg doesn't support them, probably not
[11:30] <bluefoxicy> Kamion:  well, I was making the assumption that the suggestion involves adding such support.
[11:31] <bluefoxicy> Also I thought I saw a spec on it a long time ago
[11:31] <Kamion> Scott was to look at some point, yes, but it was low-priority
[11:31] <Kamion> mdz: I've been meaning to ask - can we de-prioritise ue-partitioning-tool a bit? I don't think the remaining UI changes really qualify as Essential
[11:32] <Kamion> in fact I personally believe ubiquity-advanced-partitioner is more important, based on ratio of complaints about the two parts of the partitioner
[11:32] <Kamion> but either High or Medium would seem to make more sense
[11:38] <mdz> Kamion: didn't it just inherit that priority from the pre-edgy spec?
[11:39] <mdz> at any rate, yes
[11:39] <Kamion> it did, yes
[11:40] <mdz> it's not terribly clear from the spec which bits still remain to be implemented
[11:40] <Kamion> set to Medium
[11:40] <Kamion> it's the autopartitioning UI changes
[11:41] <Kamion> the part we did was all the integration, which was definitely Essential
[11:41] <Kamion> but we never had time for the mpt-designed UI
[11:41] <mdz> dists/dapper-updates is significantly bigger than I expected
[11:42] <mdz> 754M
[11:42] <Kamion> I've noted that in the spec
[11:43] <mdz> thanks
[11:44] <Kamion> (crudely, but hey)
[11:44] <Kamion> grr @ +assignedbugs vs. +specs?role=assignee - I can never remember which is which
[11:50] <Spads> jdub: pong
[11:58] <bddebian> Hmm, I take it --verbose isn't an option for dash?