[12:02] <smurfix> jdub: All a matter of your PoV. ;-)
[12:02] <smurfix> smiley
[12:04] <seb128> oh, mdk change for one version/year now 
[12:05] <jdub> seb128: main result: fcrozat will be on irc more often now ;)
[12:05] <seb128> ah ah
[12:07] <thom> mdz: i've mailed justdave to find out if he knows a way to do it
[12:07] <jdub> haha: "first of all during install you can compile your own kernel (what most sane people do)"
[12:07] <infinity> Anyone currently have any automounter processes running on their machine?
[12:07] <mdz> thom: meanwhile, we have a kubuntu product which acts just like ubuntu?
[12:07] <Burgundavia> jdub: that one cracked me up as well
[12:09] <HiddenWolf> jdub: piont whoever said that to gentoo. :P
[12:09] <mdz> Kamion: around?
[12:10] <thom> i'm gonna add a link in a similar style to livecd, so at least you get the kubuntu keyword set
[12:12] <thom> mdz/amu/haggai/Riddell: sample text for the kubuntu product?
[12:13] <ogra> fabbione, if you read this tomorrow, could you please add #ubuntu-motu to your weblogger asap ?
[12:14] <Riddell> thom: Beasties specific to the KDE based Ubuntu derived distribution
[12:15] <thom> Riddell: done
[12:16] <Riddell> cool :)
[12:17] <haggai> thanks thom
[12:17] <jdub> thom: so we can't really do qa contact stuff yet, right?
[12:18] <thom> jdub: we can't set it on keywords from the bug entry page, is all i'm talking about
[12:18] <mdz> jdub: not at the product level
[12:18] <mdz> thom,Riddell: "beasties"?
[12:19] <mdz> please reconsider
[12:19] <jdub> so we're using the same livecd hack
[12:19] <haggai> s/Beasties/Bugs/ ?
[12:21] <thom> justdave: so, if you remember the hack in place to ensure that bugs filed on the livecd get a keyword and the owner set, the desire is to do similar but set the qa contact
[12:21] <thom> is that possible/plausible?
[12:21] <mdz> haggai: that would be better, yes ;-)
[12:21] <jdub> isn't that just another url component?
[12:21] <justdave> hmm, plausible, but I don't think qacontact is in the enter_bug form
[12:21] <thom> justdave: no, it's not
[12:21] <justdave> you'd have to add a hidden field to the enter_bug template to hold it
[12:22] <justdave> I *think* post_bug will accept it if it's in the form
[12:22] <justdave> you're still running 2.19.1+, right?
[12:23] <thom> yeah
[12:24] <justdave> yes, post_bug does accept it if it's in the form
[12:24] <justdave> so adding it to the template should be all that's needed
[12:24] <justdave> even as a hidden field which is set when the livecd "product" is chosen
[12:25] <thom> ok
[12:26] <mjg59> Hmm. 200 for conference registration and a room at LCA.
[12:26] <mjg59> That's less than I paid for fewer nights of accommodation at Guadec in Dublin.
[12:27] <Riddell> mjg59: but more than fosdem
[12:27] <justdave> roundabouts line 262 in template/en/default/bug/create/create.html.tmpl
[12:27] <Riddell> (or indeed akademy which I just announced on kde dot news)
[12:27] <Mithrandir> mjg59: where are you staying for LCA?
[12:27] <mjg59> Riddell: This is for a week
[12:27] <mjg59> Mithrandir: The student rooms
[12:28] <Mithrandir> mjg59: ok, they're all booked out now, so I'm kinda searching for something.
[12:28] <Mithrandir> I tried mailing the hostel stuff but they never responded
[12:28] <Mithrandir> I should try to call the,m
[12:28] <Mithrandir> s/,//
[12:28] <justdave> [% IF keywords == "livecd" %] 
[12:28] <justdave>   <input type="hidden" name="qa_contact" value="nametouse">
[12:28] <justdave> [% END %] 
[12:28] <mjg59> Mithrandir: Ah - an email was sent out offering more rooms
[12:29] <Mithrandir> mjg59: oh, it was?  could you bounce it to me?
[12:29] <Mithrandir> (or are they all taken now?)
[12:29] <jdub>   ubuntu-announce:3280
[12:29] <jdub>   ubuntu-users:1626
[12:29] <jdub>   ubuntu-security-announce:1029
[12:29] <jdub>   ubuntu-news:1237
[12:30] <mjg59> Mithrandir: Dunno, I got bounced it by keybuk...
[12:30] <jdub>   kubuntu-devel:56
[12:30] <jdub>   kubuntu-users:136
[12:30] <jdub>   ubuntu-devel:737
[12:30] <mjg59> They said they'd open it up to people who hadn't booked yet in April
[12:30] <Mithrandir> mjg59: if you could bounce it to me, I'd appreciate.
[12:30] <mdz> speaking of ubuntu-news, I haven't seen Ubuntu Traffic in a while...mako? ;-)
[12:31] <Mithrandir> mjg59: tfheen@err.no ; thanks :)
[12:31] <jdub> and ladies and gentlemen
[12:31] <thom> justdave: thanks a bunch
[12:31] <jdub> the top five ubuntu loco lists
[12:31] <jdub>   ubuntu-es:555
[12:31] <jdub>   ubuntu-fr:433
[12:31] <jdub>   ubuntu-de:306
[12:31] <jdub>   ubuntu-it:230
[12:32] <jdub>   ubuntu-ru:122
[12:32] <jdub> 
[12:32] <justdave> thom: np
[12:33] <ogra> Mithrandir, any answer from Ove ?
[12:34] <Mithrandir> ogra: no, none
[12:34] <ogra> Scott didnt confirm to be there tomorrow either, hrm
[12:34] <mako> mdz: yeah.. its been a little bit.. me pouring water into my laptop week didn't really help the situation
[12:34] <mdz> mako: through your nose, I hope
[12:35] <mako> i spilled water onto *two* computers in under 30 seconds
[12:35] <mako> it would have been funny if it didn't also make me unable to work for 4 days
[12:35] <ogra> mako, did you talk to guiness ?
[12:36] <mako> ogra: ?
[12:36] <ogra> mako, its proably worth a entry in their book ;)
[12:36] <thom> justdave: hrm; the enter_bug page correctly has:
[12:36] <thom>    <input type="hidden" name="qa_contact"
[12:36] <thom>    	  value="kubuntu-bugs@lists.ubuntu.com">
[12:36] <mako> not only that, but it was *while* my talk was being introduced.. 
[12:36] <thom> but when i go to the bug (#8021) there's not QA contact filled in
[12:36] <mako> so i'm there, standing front of 1500 people about to talk having just poured water into two computers.. one of which was running the presentation
[12:36] <ogra> argh
[12:37] <mako> frickin' horrible :)
[12:37] <mjg59> Mithrandir: Sent
[12:37] <mako> the laptop seems to be fine.. although the keyboard is not.. i've already ordred a new one :)
[12:37] <Mithrandir> mjg59: thanks
[12:37] <ogra> mako, but a good practice for improvisation....
[12:38] <mjg59> My name is Mako, and I have a drinking problem...
[12:38] <ogra> lol
[12:38] <mako> mjg59: perhaps, but that is unrelated :)
[12:39] <mako> "i don't have a drinking problem, 'cept when i can't get a drink"
[12:39] <ogra> heh
[12:39] <Mithrandir> mako: new laptop or new keyboard?
[12:39] <justdave> thom: grrr.   post_bug.cgi line 149
[12:39] <mako> Mithrandir: new laptop keyboard
[12:39] <justdave> currently has         $::FORM{'qa_contact'} = $qa_contact;
[12:39] <Mithrandir> mako: I'm amazed your latop hasn't fallen totally apart yet.
[12:40] <mako> Mithrandir: it's a kb/mouse deal.. found a refurbished one for ~60USD + shipping
[12:40] <mako> Mithrandir: yeah.. me too :)
[12:40] <mako> Mithrandir: it's teetering on the edge
[12:40] <justdave> change that to    defined($::FORM{'qa_contact'}) || $::FORM{'qa_contact'} = $qa_contact;
[12:40] <mako> i thought the water thing was the end of it.. but i think i might have another 6 months out of this one..
[12:40] <Kamion> jdub: yes?
[12:40] <Mithrandir> heh
[12:40] <Kamion> mdz: yes?
[12:41] <seb128> hum,  gaim 1.2.0 
[12:41] <thom> Can't modify logical or (||) in scalar assignment at post_bug.cgi line 150, near "$qa_contact;"
[12:41] <thom> Execution of post_bug.cgi aborted due to compilation errors.
[12:41] <dholbach> hey zul
[12:42] <zul> hey
[12:42] <thom> justdave: ^^
[12:42] <Kamion> thom: "||" => "or"
[12:42] <justdave> what Kamion said :)
[12:43] <justdave> or add another set of parens on the right-hand-side would work, too
[12:43] <thom> justdave: still no joy
[12:43] <justdave> still errors, or still doesn't work?
[12:43] <mdz> Kamion: hmm, I forget
[12:43] <thom> just no QA contact set
[12:44] <mdz> Kamion: fwiw, DVD install on amd64 from Saturday's ISO did not ask for the disc, seems to be fixed
[12:44] <zul> is launchpad active now or something?
[12:44] <justdave> ok, let's do it the long spelled out and easy to read way :)
[12:45] <Kamion> mdz: bonus, thanks for testing
[12:45] <justdave> if (!defined($::FORM{'qa_contact'})) { $::FORM{'qa_contact'} = $qa_contact }
[12:45] <jdub> Kamion: started testing kickstart with my toilet seat
[12:45] <mdz> Kamion: we need to do something about the long pause after the passwd questions
[12:45] <Kamion> jdub: never tried it on powerpc :)
[12:45] <jdub> :-)
[12:45] <Kamion> mdz: yeah, need an extra progress bar in apt-setup-udeb, easy to do
[12:45] <jdub> that makes it more fun
[12:45] <Kamion> jdub: there's no bootloader support for powerpc in kickseed
[12:45] <mdz> Kamion: is it on your list, or would you like a bug?
[12:45] <Kamion> nor upstream for that matter
[12:45] <Kamion> mdz: bug'd be good
[12:46] <Kamion> jdub: it may be a matter of defining more syntax, which makes it scary
[12:46] <jdub> Kamion: atm, netcfg/choose_interface=eth0 doesn't seem to be working
[12:46] <thom> justdave: is there actually a QA contact set by default? (I assume not, since the field is blank) if not, we won't ever hit that code, will we?
[12:46] <Kamion> jdub: would need /var/log/* to diagnose
[12:46] <jdub> Kamion: by default, it attempts to use my wifi (eth1)
[12:49] <justdave> thom: the param it's loading is whether the QA contact field is visible at all on show_bug
[12:49] <justdave> if you can see it on the show_bug page then that's on and that code runs.
[12:49] <Kamion> jdub: like I say ...
[12:49] <justdave> that's populating it with the default from the database if it's on.
[12:50] <thom> ah, right
[12:50] <jdub> Kamion: also, i'm netbooting
[12:50] <justdave> thom: doh, you're right....
[12:50] <jdub> anyway, trying again atm
[12:50] <justdave> ok, put the original code back...
[12:50] <justdave>     if (defined $qa_contact && $qa_contact != 0) {
[12:50] <justdave>         $::FORM{'qa_contact'} = $qa_contact;
[12:50] <justdave>         push(@bug_fields, "qa_contact");
[12:50] <justdave>     }
[12:50] <Kamion> jdub: where's your kickstart file
[12:50] <Kamion> jdub: ?
[12:50] <justdave> except move the push line outside the last brace
[12:50] <justdave> that's the problem. :)
[12:51] <justdave> the push is conditional on whether there's a qa defined for that component
[12:51] <justdave> we need it to check that field whether there's a default or not
[12:51] <justdave> @bug_fields is the list of fields it looks for later when reading the form
[12:51] <jdub> Kamion: on a local http machine
[12:51] <Kamion> jdub: oh, I see your problem
[12:52] <Kamion> jdub: in order to get that kickstart file, kickseed forces netcfg/choose_interface=auto in an attempt to bring the network up with *some* interface noninteractively
[12:52] <thom> justdave: with that modification, still no joy
[12:52] <jdub> Kamion: aha
[12:52] <Kamion> jdub: I hadn't considered that people might be setting that on the kernel command line
[12:52] <Kamion> jdub: willfix
[12:53] <justdave> thom, looks like this, right?
[12:53] <justdave>     if (defined $qa_contact && $qa_contact != 0) {
[12:53] <justdave>         $::FORM{'qa_contact'} = $qa_contact;
[12:53] <justdave>     }
[12:53] <justdave>     push(@bug_fields, "qa_contact");
[12:53] <jdub> Kamion: so, does autoconfiguration attempt to use wifi first?
[12:53] <Kamion> jdub: first interface it thinks it can use
[12:53] <thom> justdave: yeah; shouldn't that push be $::FORM{'qa_contact'} ?
[12:53] <justdave> oh, but that overrides only if there wasn't one defined for that component
[12:53] <Kamion> jdub: maybe mii/ethtool doesn't work on your eth0
[12:54] <jdub> aha
[12:54] <jdub> no, it doesn't
[12:54] <Kamion> jdub: /var/log/* would say
[12:54] <justdave> no, the checking of the value in $::FORM{'qa_contact'} should happen later
[12:54] <justdave> the hash key needs to be in @bug_fields before then though.
[12:54] <thom> ok
[12:54] <justdave> it uses @bug_fields to know which fields to read.
[12:54] <thom> right
[12:55] <jdub> yeah, syslog just shows that it thinks it's disconnected
[12:55] <justdave> that if block needs to also not fire if $::FORM{'qa_contact'} already contains something.
[12:55] <Kamion> *dis*connected? it shouldn't be trying to use it then
[12:55] <justdave> so maybe we need that line we did earlier in there anyway
[12:55] <jdub> it's not
[12:55] <jdub> that's the problem :)
[12:55] <justdave> if (!defined($::FORM{'qa_contact'})) { $::FORM{'qa_contact'} = $qa_contact }
[12:55] <Kamion> oh. "it thinks it's disconnected" => what does the second "it" refer to?
[12:55] <jdub> eth0
[12:55] <justdave> as well as having the push outside the if() block
[12:56] <thom> right
[12:56] <jdub> it skips eth0 (wired), goes on to eth1 (wifi)
[12:56] <Kamion> jdub: so is that not what you want? from what you said earlier I thought you wanted eth1
[12:56] <jdub> no, i expected eth0 (wired) to work
[12:57] <thom> justdave: still no joy
[12:57] <Kamion> jdub: oh right, I misremembered
[12:57] <dholbach> good night everyone
[12:58] <Kamion> jdub: fun example of MII/ethtool being plain wrong, then
[12:58] <Kamion> since people keep claiming at me that it's infallible and why don't we just believe it ;)
[12:58] <jdub> heh
[12:58] <jdub> perhaps it should do something different if mii/ethtool isn't supported by the defice?
[12:58] <jdub> device
[12:59] <jdub> bring up the interface and detect traffic ;)
[12:59] <Kamion> jdub: your device is claiming it supports it
[01:00] <Kamion> jdub: if it didn't claim to support it, ethtool-lite would log "couldn't determine MII ioctl to use for <iface>" and return UNKNOWN
[01:00] <Kamion> I think hardware that plain lies deserves to lose :P
[01:01] <jdub> the toilet seat never lies!
[01:01] <mdz> Kamion: oh, I remember what I was pinging about
[01:01] <mdz> Kamion: UDU planning
[01:01] <Kamion> oh, CRAP, the LCA reg thing
[01:01] <mdz> Kamion: trying to break down / group the installer stuff into BOFs
[01:02] <mdz> Kamion: oh, that too
[01:02] <Kamion> MUST DO THAT TOMORROW
[01:02] <Kamion> mdz: now not a great time for that, was about to go to bed ... can you mail or something?
[01:02] <thom> justdave: any further thoughts?
[01:02] <jdub> Kamion: hrm, where are the mii/ethtool binaries during install?
[01:02] <mdz> Kamion: will do, about both
[01:03] <mkedwards> amu: is there something hard about building boost?  IWFM
[01:04] <amu> mkedwards: nope everything was fine, boost as a depends
[01:04] <Kamion> jdub: it's a function in netcfg, not a separate binary
[01:04] <jdub> oh
[01:06] <mkedwards> amu: per MOTUTodo, boost needs to move to main, right?
[01:08] <jdub> Kamion: can i make the installer use eth0 mid way through?
[01:09] <seb128> jdub, mdz: opinion on gaim 1.2.0 ?
[01:09] <seb128> :)
[01:10] <ogra> *g*
[01:10] <jdub> seb128: from what i hear it's not significantly different to 1.1.4, it's essentially a few fixes and blessed
[01:10] <mdz> gaim scares me in general
[01:10] <mdz> gaim updates close to release scare me more
[01:10] <amu> mkedwards: so it is
[01:11] <Kamion> jdub: setup/net brokenness fixed in kickseed 0.17
[01:11] <zul> mdz: oh its not that bad :)
[01:11] <mdz> zul: I use it every day, but I never take my eyes off it
[01:11] <mdz> I don't turn my back on it
[01:11] <Kamion> jdub: 'network --device=eth0' in kickstart should do that?
[01:11] <zul> heh
[01:11] <jdub> i currently have
[01:11] <jdub> network --bootproto=dhcp --device=eth0
[01:12] <seb128> the evil gaim crashes mdz's panel every night when he's not looking
[01:12] <jdub> man, gaim still dies for me when i kill my panel
[01:12] <seb128> me too
[01:12] <Kamion> jdub: that *should* do it, if it doesn't let me know
[01:12] <ogra> for me too
[01:12] <seb128> gossip doesn't :)
[01:12] <seb128> dudes, you don't kill a panel
[01:13] <seb128> you need to be nice with it and use gnome-session-remove :)
[01:13] <seb128> gaim is happy in this case
[01:13] <Benoni> In Russia, gnome-panel kills *you*!
[01:13] <Benoni> Ha ha ha.
[01:13] <Benoni> Thank you, thank you.  I'll be here all week.  Remember to tip your waitress.
[01:13] <mdz> Kamion: hoary-dvd-amd64 desktop install looks good, testing live now
[01:14] <jdub> Kamion: it really wants to keep using eth1 :-)
[01:14] <justdave> thom:  found it.
[01:14] <mdz> Kamion: we should add a bit about 'live' to the isolinux text on the dvd
[01:14] <justdave> thom: it's expecting a user ID and not a username
[01:14] <maswan> anyone has a mirror and can test updating to rsync://releases.ubuntu.com/ubuntu ? I'm seeing failures in the logfiles, but they all come form just one host
[01:14] <ogra> jdub, whats wrong with that ? swap your cards :-P
[01:15] <thom> justdave: unf. how do i work round this?
[01:15] <jdub> ogra: laptop.
[01:15] <justdave> thom: hang on a sec, still trying to figure out the least instrusive way to work around that
[01:15] <jdub> though i could take out the airport.
[01:15] <ogra> heh
[01:15] <Kamion> jdub: wonder how many times I have to keep mentioning /var/log/* ... ;)
[01:15] <Kamion> mdz: yes, we should. it's a bit fiddly
[01:16] <Kamion> mdz: is #8015 a kernel bug?
[01:17] <mdz> Kamion: it's a sort of fuzzy make-the-kernel-smarter-or-work-around-it-in-userspace thing
[01:17] <jdub> Kamion: i've mentioned what's in there earlier, but i can't get anything to you beyond what i can type
[01:18] <Kamion> jdub: you have nc
[01:18] <zul> Kamion, i dont like the words kernel and bug in the same sentence :)
[01:19] <jdub> ok, without the wifi card there to confuse everything, it's already into base installation
[01:20] <jdub> it seems to have created the partitions and formatted :)
[01:22] <jdub> Kamion: have you tried loading a cfg file with s-c-k?
[01:23] <thom> mdz/jdub: can you add kubuntu-bugs@lists as a valid bugzilla user, please? (i assume that's how this works)
[01:23] <mdz> Kamion: I was thinking today that a casper-style overlay could reduce d-i's memory requirements (keeping much of the initrd on the CD rather than in memory)
[01:23] <mdz> it'd be slower, though
[01:23] <jdub> thom: sure
[01:24] <infinity> Whast sort of hours does pitti keep?
[01:24] <jdub> thom: done
[01:24] <jdub> thom: will create list in a minute too
[01:24] <thom> infinity: gmt+1 9am-> late seems about right
[01:25] <infinity> So, I proabbly just missed him, then?  Achwell.
[01:27] <thom> justdave: thanks heaps, that's working
[01:27] <thom> mdz,Riddell,haggai,etc: you have kubuntu love
[01:27] <justdave> thom: coolness :)
[01:27] <justdave> thom: took long enough :)
[01:27] <thom> justdave: oh well :-) no pain no gain ;-)
[01:27] <mdz> thom: thanks
[01:29] <Kamion> jdub: yeah; did it break?
[01:29] <Kamion> mdz: that would be interesting ...
[01:33] <jdub> kubuntu-bugs is alive
[01:34] <jdub> needs a small bit of love from haggai/Riddell 
[01:40] <ogra> mdz, look at ~/.xscreensaver, line 7 :)
[01:41] <mdz> ogra: that is disabled by default, isn't it?
[01:41] <mdz> ogra: the problem is with, e.g. the "Lock Screen" menu item, and acpi-support's locking
[01:41] <mdz> which do xscreensaver-command -lock
[01:41] <jdub> http://tml-blog.blogspot.com/2005/03/stop-that-music-or-vmware-is.html
[01:41] <jdub> heh
[01:41] <jdub> yo Benoni 
[01:41] <thom> ogra, mdz: hrm, what's the problem?
[01:42] <ogra> thom https://bugzilla.ubuntu.com/show_bug.cgi?id=7150
[01:42] <mdz> thom: on the live CD, the logged-in user has a locked password
[01:42] <ogra> thom, xss allows locking even if there is no PW
[01:43] <thom> ow
[01:43] <amu> jdub: please file a bug
[01:43] <ogra> mdz, is ti possible to have a different xscreensaver package for the live CD (patched) ?
[01:43] <mdz> ogra: no
[01:43] <ogra> *sigh*
[01:44] <mdz> casper can change the acpi-support config easily enough
[01:44] <mdz> I'm not so sure about how to remove the menu item
[01:48] <ogra> hmm, the entry in ~/.xscreensaver doesnt even affect the behavior, odd
[01:49] <jdub> amu: hmm?
[01:52] <daniels> Benoni: quiche?
[02:30] <mako> ogra: around?
[02:33] <crimsun> mako: he went to bed ~40 mins ago
[02:33] <mako> ah well
[02:35] <Amaranth> arg
[02:35] <Amaranth> i go from a menu spec issue to a python xml issue
[02:36] <daniels> Amaranth: builds character
[02:36] <Amaranth> daniels: finds bugs, i think
[02:37] <Amaranth> nothing in my dom tree from the root on down has an ownerDocument attribute
[02:38] <sabmoc> oooo.. he is such a cute badger!!
[02:39] <sabmoc> looks like a bunny with claws
[02:40] <Amaranth> yea for making none of my menus show up!
[02:40] <sabmoc> yay!
[02:40] <sabmoc> oh wait, you're being sarcastic Amaranth ?
[02:40] <Amaranth> heh
[02:40] <sabmoc> fear the badger!
[02:41] <Benoni> Hey, daniels.  Long time no see.
[02:41] <daniels> 111     Mar 22 Mona            (   0) Wikipedia knows the shit
[02:41] <daniels> strangest spam I've yet received
[02:43] <daniels> whoever uploaded toursst: you just uploaded it to Debian, dude
[02:52] <Benoni> So daniels, how have you been?
[02:52] <daniels> not too bad, thanks; you?
[02:53] <Benoni> Good, good.  Life has changed quite a bit since last we talked.
[02:54] <daniels> indeed
[02:54] <Benoni> I'm now *Dr.* Benoni.  (W00t!)
[02:56] <Benoni> Speaking of which, jdub, are you still around?
[03:00] <adamh> How can I install ant on Ubuntu?
[03:13] <mdz> interesting, Debian hit 300k bugs at around the same time Ubuntu hit 8k bugs
[03:14] <wasabi_> mdz, who do I need to coordinate with on the upload of a new Ant package? It's merging two Debian merged packages into one, and moving that one to universe.
[03:16] <mjg59> mdz: And around the time we hit 111111111 seconds since the epoch. Conspiracy?
[03:18] <mdz> wasabi_: you already have privileges to upload to universe, right?
[03:18] <wasabi_> Yes.
[03:19] <mdz> wasabi_: if you need packages synced in from Debian, mail James and CC me; if you just need to upload stuff directly, go ahead
[03:19] <mdz> wasabi_: once it's in the archive, we can promote it from multiverse to universe as appropriate
[03:19] <wasabi_> Not exactly. I need a package in universe removed.
[03:19] <wasabi_> And then this package uploaded to multiverse (for now)
[03:19] <mdz> before you can upload?
[03:19] <wasabi_> Err, wait, that's not going to work yet. ;)
[03:19] <wasabi_> But, in the future!
[03:19] <wasabi_> Do you know the Ant situation?
[03:20] <mdz> I talked to jbailey about it briefly in the context of oo.o2
[03:20] <wasabi_> two source packages: libant1.6-java and ant
[03:20] <wasabi_> libant1.6-java produces libant1.6-java
[03:20] <wasabi_> ant produces ant
[03:20] <wasabi_> libant1.6-java is in universe, ant is in multiverse.
[03:20] <wasabi_> new package: ant. produces both ant and libant1.6-java (superset of old libant1.6-java)
[03:20] <wasabi_> And removes non-free pieces that forced 'ant' to be in multiverse previously.
[03:21] <mdz> as long as the new package follows the existing version line, that's no problem
[03:22] <mdz> upload ant 1.6.2-2ubuntu1 or similar; the binary packages it builds will supersede both ant and libant1.6-java since it's a newer version
[03:22] <mdz> then once the dust settles, you can request removal of libant1.6-java
[03:22] <wasabi_> ahh.
[03:23] <wasabi_> Now to just figure out how to get this thing properly universe-compatible.
[03:23] <mdz> well, at least, that's how it would work if they were in the same component
[03:23] <mdz> I'm not entirely sure how this type of superseding works across components
[03:23] <mdz> probably best to check with elmo
[03:23] <mdz> hopefully it still works as I described, but check before uploading
[03:26] <wasabi_> that makes sense. thx
[03:35] <wasabi_> mdz, can you perhaps move libbcel-java to universe?
[03:35] <wasabi_> if not i'll wait for elmo tomorrow.
[03:36] <wasabi_> just, I have a log of 3 packages to upload waiting on it that I want to get going. ;)
[03:36] <wasabi_> and im totally impatiant
[03:41] <mdz> wasabi_: will libbcel-java build if it's in universe?
[03:42] <mdz> it looks like its build-depends are satisfied in universe, but please confirm
[03:42] <wasabi_> The source package is in universe.
[03:42] <wasabi_> the binaries are in multiverse.
[03:42] <wasabi_> So yeah, I confirm. ;)
[03:48] <mdz> wasabi_: should be in the next pulse
[03:48] <wasabi_> awesome, thanks.
[03:53] <wasabi_> mdz, oh, libbcel-java-doc too if ya didn't notice it. ;)
[03:53] <mdz> I did
[03:53] <wasabi_> k thanks once again
[04:48] <infinity> mdz : Given that you seem to have opinions on how 7847 (shouldn't be) fixed, want to glance at my diff before I upload?
[04:49] <mdz> sure
[04:51] <infinity> http://lucifer.0c3.net/~adconrad/cupsys.diff
[04:52] <infinity> (But, hey, what's wrong with 'sleep 20 ; pray'?)
[04:52] <mkedwards> mdz: device-mapper snapshots don't survive crashes very well.  :(
[04:56] <mdz> infinity: how does that address the issue of a failed restart aborting the upgrade?
[04:57] <infinity> Oh, wait.  Do I need to read those lsb functions?... When you "log_end_msg 1", does it exit 1 as well?
[05:02] <infinity> Oh, it does too...  Feh.  Well, it half fixes it, since the stop is less likely to fail.
[05:02] <infinity> I'm not so sure one can have their cake and eat it too in rgards to init scripts having correct output and never exiting with a failure, so I guess anything that's restarting it in postinst will also need a ||true
[05:05] <sabmoc> when setting up pan to browse gmain, do you need to add anything except the new servers name?
[05:05] <sabmoc> news* servers name
[05:06] <sabmoc> I set mine up last night and it works fine, but I am trying to help someone else and it is asking them for a group and doesnt seem to be working. :/
[05:08] <infinity> mdz : Yeah, I guess the second half of the fix is a ||true in cupsys-driver-gimpprint's postinst.  Easy enough.
[05:10] <mdz> mkedwards: hmm, I'd expect them to hold up as well as the filesystem above them allows
[05:10] <mdz> sabmoc: please use #ubuntu for questions about using Ubuntu; this channel is for development-related discussion
[05:11] <mkedwards> mdz: filling a cow device is a bad scene
[05:11] <mdz> mkedwards: yes, yes it is
[05:11] <mdz> mkedwards: in the casper source package is the beginning of a simple applet to display a meter, to try to avoid that happening
[05:12] <mdz> mkedwards: I also changed casper at one point to use a device-mapper target as the snapshot store, rather than the ramdisk directly, so that it can be trivially extended
[05:14] <mkedwards> mdz: jogging the USB stick is also a bad scene.
[05:14] <mkedwards> mdz: pstore valid flag set to zero, snapshot unrecoverable.
[05:17] <mkedwards> mdz: dm-exception-store.c code is scary 
[05:18] <mkedwards> "hmm, didn't expect an error code here ... better mark it invalid, from which we can't recover."
[05:34] <kain> hi there, anyone knows here why eclipse isn't in current multiverse/devel repos on hoary?
[05:35] <wasabi_> Heh.
[05:35] <wasabi_> Because I haven't uploaded it yet.
[05:36] <kain> that's ok, thanks ;)
[05:36] <wasabi_> I have 3.0 packages on mentors
[05:36] <wasabi_> which you are welcome to attempt to build.
[05:36] <kain> today I can give it a try
[05:37] <sabmoc> will there eventually be a http://planet.ubunut.org ?
[05:37] <wasabi_> isn't there  already?
[05:38] <sabmoc> we'll I hope not :)
[05:38] <sabmoc> well*
[05:38] <mdz> there has been, for many months now
[05:38] <wasabi_> http://planet.ubuntu.com/
[05:38] <mdz> planet.ubuntu.com and planet.ubuntulinux.org
[05:38] <sabmoc> ah, but no planet.ubunut.org
[05:38] <sabmoc> ubuntu* gah
[05:38] <mdz> kain: because it doesn't build yet
[05:39] <kain> I see
[05:39] <mdz> sabmoc: ubuntu.org is a different organization
[05:39] <sabmoc> mdz not affiliated with canonical?
[05:39] <fabbione> morning
[05:39] <mdz> sabmoc: correct
[05:39] <sabmoc> ahic
[05:39] <mdz> nor affiliated with Ubuntu the open source project
[05:40] <wasabi_> I guess I could almost upload Eclipse 3.0 to multiverse.
[05:40] <wasabi_> hmm. maybe maybe not.
[05:41] <kain> mm
[05:41] <wasabi_> nope, still missing tomcat
[05:41] <fabbione> mdz: do you still play around with uml?
[05:42] <mdz> fabbione: I have no time for it
[05:42] <fabbione> mdz: i just have one problem with rootstrap that complains it can't find the init= script... perhaps you knew...
[05:42] <wasabi_> mdz, how long is the next "pulse"?
[05:43] <wasabi_> thought that was a 30 minute deal
[05:46] <crimsun> wasabi_: at :03 and :33
[05:47] <wasabi_> hmm or will it not change until I upload a new version?
[05:52] <crimsun> there is something odd afoot with the buildds
[05:53] <Amaranth> woohoo, non-root menu editting!
[06:26] <sabmoc> Amaranth, really?
[06:26] <Amaranth> sabmoc: yeah
[06:54] <Kaloz> good (ugt) morning
[07:07] <sabmoc> Amaranth, cool
[07:08] <Amaranth> sabmoc: it has bugs :P
[07:09] <sabmoc> Amaranth, are you packaging a new version of fixing the old one?
[07:09] <infinity> mdz : Shall I prepare a fixed php4 for warty?.. I found the bug.
[07:09] <sabmoc> s/of/or/;
[07:09] <sabmoc> I cant type at all tonight
[07:09] <infinity> mdz : I'm assuming I don't have the access required to actually push it through, of course.
[07:09] <Amaranth> sabmoc: still trying to fix it
[07:10] <sabmoc> Amaranth, well, good job :) ..i'll go back to my doodle drawings now
[07:11] <sabmoc> Amaranth, I know a lot of people would really like that fixed
[07:16] <fabbione> schweeb: ping?
[07:17] <schweeb> fabbione: about to sleep, but yea?
[07:18] <fabbione> schweeb: is it you packaging xen, right?
[07:18] <schweeb> for personal use, yes
[07:18] <schweeb> want me to upload what I've got so far?
[07:18] <fabbione> schweeb: did you manage to get xend to start?
[07:19] <fabbione> i am more interested in making it working first :-)
[07:19] <schweeb> heh
[07:19] <fabbione> i did compile it from sources without any problem
[07:19] <fabbione> but xend refuses to start
[07:19] <schweeb> umm, xend started in sarge, yes
[07:19] <fabbione> i am on an ubuntu machine....
[07:19] <schweeb> are you in a domain 0?
[07:19] <fabbione> yes
[07:20] <fabbione> i already booted with the Xen kernel
[07:20] <fabbione> and now it is supposed to start xend
[07:20] <schweeb> did it error at all?
[07:20] <fabbione> nope....
[07:20] <fabbione> did you move the tls libs out of the way?
[07:20] <schweeb> yes
[07:21] <fabbione> so did i
[07:21] <schweeb> it'll bitch a lot otherwise
[07:22] <schweeb> umm, hrm
[07:22] <schweeb> you're using 2.0.5?
[07:23] <schweeb> stable, testing, or unstable?
[07:24] <schweeb> fabbione: even manually executing 'xend start' does nothing?
[07:25] <schweeb> then try 'xend status'
[07:25] <fabbione> nope
[07:25] <schweeb> urgh :-/
[07:25] <fabbione> i am using 2.0.5
[07:25] <fabbione> i did a strace and i can see it fails to open a lot of files
[07:26] <fabbione> specially some .so in /usr/lib/python/xen/xend/
[07:26] <svenl> Kamion: ok.
[07:27] <schweeb> fabbione: hrm, I'm assuming you have python twisted and python logging installed?
[07:27] <fabbione> schweeb: what's the standard output of a xend status?
[07:27] <fabbione> twisted yes... not sure about logging
[07:28] <Amaranth> ffs why do you have to make this so hard
[07:28] <Amaranth> err, they
[07:28] <schweeb> logging is included in the dist tarball... it shoul dget installed on compile
[07:28] <Amaranth> not any of you, i don't think :P
[07:28] <Amaranth> stupid fd.o menu spec
[07:28] <fabbione> schweeb: is there a deb package for it?
[07:28] <fabbione> (for logging i mean)
[07:28] <schweeb> I'm not sure
[07:29] <fabbione> ok
[07:29] <fabbione> i will just build it
[07:29] <schweeb> I thought it was part of the base python distro
[07:29] <schweeb> but I know jack about python
[07:30] <schweeb> fabbione: which .so is it missing?
[07:30] <fabbione> no luck
[07:30] <infinity> Can/does anyone other than pitti do security uploads?
[07:30] <fabbione> open("/usr/lib/python/xen/xend/server/domainmodule.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[07:30] <fabbione> schweeb: just one of them that is missing....
[07:31] <fabbione> infinity: nope...
[07:31] <fabbione> infinity: btw.. i have a bug report for you...
[07:31] <fabbione> infinity: what email can i forward to?
[07:32] <Amaranth> This is so _stupid_.
[07:33] <schweeb> fabbione: odd, I don't have a domainmodule.so compiled... maybe it's a dynamically generated python thing or something
[07:33] <schweeb> I have domain.py and domain.pyc in that path...
[07:33] <fabbione> schweeb: ok.. at least that excludes the possibility that i did miscompile
[07:33] <fabbione> schweeb: so do i
[07:33] <infinity> fabbione : Ubuntu or Debian?
[07:33] <fabbione> infinity: Ubuntu...
[07:33] <infinity> fabbione : Ubuntu bug reports, you can assign to adconrad@0c3.net in bugzilla.
[07:33] <schweeb> infinity: it's a xen specific thing
[07:34] <schweeb> unsupported
[07:34] <fabbione> infinity: i will forward the mail. somehow bugzilla barfed
[07:34] <schweeb> oh
[07:34] <schweeb> whoops, mixing up convos
[07:34] <schweeb> hehe
[07:34] <infinity> bugzilla, barf?... Never... That's crazy talk.
[07:34] <fabbione> infinity: aahha
[07:35] <fabbione> schweeb: are you running 2.0.5 btw?
[07:35] <fabbione> or unstable? or bk snapshot?
[07:35] <fabbione> i really don't care to upgrade or something
[07:35] <schweeb> running is a relative term ;)
[07:35] <schweeb> more, I have the userspace packaged, and still have to make a kernel
[07:36] <schweeb> but yes, 2.0.5 stable
[07:36] <fabbione> schweeb: well.. but did you test xen at all, before starting the packaging part?
[07:36] <schweeb> yep
[07:36] <fabbione> ok
[07:36] <schweeb> xen 2.0.4 though
[07:36] <schweeb> 2.0.5 just came out like last week
[07:36] <fabbione> schweeb: ah ok.. so it might actually be buggy
[07:38] <mdz> infinity: yes, coordinate with pitti
[07:40] <schweeb> fabbione: bwell, I'm  uploading what I've got on the packages right now, if you at least want to try them, see if it helps... http://schweeb.org/~chris/ubuntu/ ... I'm uploading now, so wait at least a half hour or so...  they don't by any means pass lintian
[07:40] <schweeb> but, bedtime, later
[07:40] <fabbione> schweeb: don't worry.. no need to trash your bw
[07:40] <fabbione> schweeb: i just need to get it working.. and have a good night :-)
[07:41] <schweeb> thx... I should have gone to bed 2 hrs ago, I'm gonna pay for this
[07:41] <schweeb> hehe
[07:41] <schweeb> night
[07:44] <infinity> fabbione : That bug did finally get submitted to bugzilla.  And I'm fixing it right now.  I need pitti to upload it, though. :)
[07:44] <fabbione> ah ok
[07:56] <mdz> Keybuk: would it be easy to filter the changelog diffs into a separate patch in MOM?
[07:56] <bob2> bah
[07:56] <bob2> slay in ubuntu is fascist
[07:57] <Keybuk> mdz: in the ongoing-merge output or patches output?
[07:57] <mdz> slay is a silly single-purpose tool which duplicates functionality in more standard tools
[07:57] <mdz> Keybuk: in the patches output
[07:57] <Keybuk> they are already?
[07:57] <mdz> they weren't the last time I looked...
[07:57] <mdz> did you change that within the past month or so?
[07:57] <Keybuk> nope
[07:58] <Keybuk> ah, changelog + control get lumped together
[07:58] <mdz> and called most descriptively "misc"
[07:58] <Keybuk> heh
[07:58] <Keybuk> sure, can change that
[07:58] <mdz> thanks
[07:59] <Keybuk> seb128's filed a bug about that libtool bug I mentioned the other week
[08:00] <fabbione> mdz: #7939, if we can't get a fix in the kernel i will upload hotplug to blacklist the alsa module and load the oss one. would that be ok for you?
[08:00] <fabbione> (also because i have no other solution)
[08:02] <mdz> Keybuk: yes, I noticed
[08:03] <infinity> mdz : Alright, fix tested, rolled, and signed for pitti to have a look at.  I've pinged him via mail with a pointer to the sources, so the ball is in his court.
[08:04] <mdz> fabbione: alsa-base rather than hotplug, but yes
[08:04] <fabbione> mdz: ok
[08:04] <mdz> infinity: he'll be awake soon enough
[08:05] <fabbione> you talk about the devil...
[08:05] <pitti> Good morning
[08:05] <infinity> Speak of the devil..
[08:05] <infinity> Also, I'm redundant.  Yay.
[08:05] <infinity> pitti : Check your mail, svp. :)
[08:06] <pitti> infinity: I'm about it :-)
[08:29] <pitti> mdz: still here?
[08:31] <mdz> pitti: yes
[08:31] <pitti> mdz: remember that we removed raidtools support from heartbeat?
[08:32] <pitti> mdz: the Debian maintainer did this as well and cleaned this up further a bit
[08:32] <mdz> pitti: yes, and Debian is discussing the same thing now
[08:32] <pitti> mdz: it's in version -8 in incoming
[08:32] <pitti> mdz: between -3 (that we have) and -8 are only bugfixes, can we merge this?
[08:33] <mdz> pitti: do you have a specific reason to change it so close to release?
[08:33] <pitti> mdz: no, not a particular one
[08:33] <mdz> pitti: at this late stage I prefer not to change things unless we have a good reason
[08:34] <pitti> mdz: okay, fine for me :-)
[08:38] <Play_> http://www.playzero.com
[08:38] <Play_> http://www.playzero.com
[08:38] <dilinger> pitti: hey, what is this vfs-f-maxcount patch that was added to warty's kernel in 16.11?
[08:52] <mdz> Keybuk: you sound like an arch developer -- that version is *weeks* old, it's worthless!
[08:52] <Keybuk> mdz: version?
[08:52] <mdz> Keybuk: 7995
[08:52] <Keybuk> heh; no, I just said what you said, we opted not to take the patch
[08:53] <Keybuk> afaik, of every libtool-using source in existance, it only affects gnome-vfs2 at the moment
[08:53] <Keybuk> so if we're not re-libtoolizing that, it's not worth taking
[09:04] <mdz> night all
[09:05] <pitti> night mdz
[09:05] <pitti> sleep well
[09:10] <pitti> doko: ooo 1.1.3-8ubuntu1 bibliography db still crashes on ppc
[09:31] <dholbach> gooood morning
[09:31] <jdub> pants off dholbach 
[09:32] <pitti> Hi dholbach 
[09:32] <Treenaks> good morning all
[09:32] <dholbach> jdub: they are off! wooohoooo! spring is in the air!
[09:32] <ogra> morning
[09:32] <dholbach> hey ogra
[09:32] <pitti> Moin ogra
[09:33] <jdub> heh
[09:33] <jdub> raining here :)
[09:33] <Treenaks> nice, sunny spring weather here :)
[09:34] <dholbach> morning jani
[09:35] <ogra> thanks dholbach 
[09:35] <jani> morning, dholbach
[09:37] <jani> dholbach, I faxed the notary stuff to mako this morning
[09:38] <jani> I might get to do an upload before hoary :)
[09:38] <dholbach> jani: wow... that's sooooo coool :-)
[09:43] <Seveas> mjg59, ping?
[09:45] <ogra> fabbione, ping
[09:46] <fabbione> ogra: pong
[09:47] <jani> elmo ping
[09:50] <Mithrandir> fabbione: did you find my fleece neck?
[09:51] <fabbione> Mithrandir: there was nothing in the car :(
[09:51] <Mithrandir> fabbione: it's probably lying around here somewhere, then. :/
[09:51] <Mithrandir> I'll see if I can find it
[09:51] <fabbione> Mithrandir: i will check again, but i doubt it's there
[09:52] <Mithrandir> it's not a big deal, it's just a fleece neck
[09:52] <fabbione> still annoying
[09:58] <jani> ?
[10:18] <ogra> ahh, the world gets into shape again
[10:18] <zyga> not really :/
[10:18] <pitti> welcome back, world
[10:18] <zyga> just the ngettext part
[10:18] <ogra> hey pitti :)
[10:18] <Amaranth> stupid netsplits
[10:18] <Amaranth> I was all alone! :/
[10:18] <Burgundavia> BBC says --> Rise of the zombies threatens UK 
[10:19] <zyga> what's stat64 needed for?
[10:19] <zyga> to check for .mo files?
[10:19] <pitti> zyga: we have to stat the files in locale and locale-langpack to compare timestamps
[10:19] <pitti> zyga: if a file is present in both dirs, we want to take the newer one
[10:20] <Amaranth> ogra: I don't need comfort, I need a PyXDG hacker. :)
[10:20] <zyga> hmm
[10:20] <ogra> heh
[10:20] <siddharthk> what is PyXDG 
[10:20] <zyga> pitti: when do you have to do that?
[10:21] <Amaranth> siddharthk: python module that implements various freedesktop.org specifications
[10:21] <ogra> siddharthk, xdg is the new menu spec for .desktop files
[10:21] <zyga> pitti: once a mo file is open does it stay open or is it rechecked on every gettext call?
[10:21] <pitti> zyga: up to the prelast libc version we had done it for every string lookup
[10:21] <jdub> it's a hassle when you have a bunch of people and no way to work together
[10:21] <pitti> zyga: it is rechecked
[10:21] <sabmoc> jdub, yes
[10:21] <zyga> pitti: what about some fam thing?
[10:21] <pitti> zyga: not for libc
[10:21] <sabmoc> jdub, Im pretty sure they have ideas and we just need a way to talk
[10:22] <zyga> pitti: rechecking this is really bad idea :/
[10:22] <Amaranth> I posted a reply to a macrumors thread defending PyMusique, I suspect I'll be torn to shreds.
[10:22] <pitti> zyga: this is what the original libc6 does, but it uses cachign
[10:22] <pitti> caching, even
[10:22] <sabmoc> jdub, Im pretty happy about how well it is working
[10:22] <pitti> zyga: I added caching in the latest version as well, but it is flawed
[10:22] <zyga> hmm
[10:23] <siddharthk> what kind of development is being done in pyXDG ?
[10:23] <mkedwards> Amaranth: I possess a modest amount of python-fu; what needs doing?
[10:23] <siddharthk> i have some python exposure.
[10:23] <zyga> pitti: and libc got broken by caching only one domain?
[10:23] <pitti> zyga: yeah, sort of
[10:24] <zyga> cache = open mo && read all ?
[10:24] <pitti> zyga: cache == store the result from a previous timestamp comparison
[10:24] <zyga> ah
[10:24] <pitti> zyga: btw, my current version looks promising
[10:25] <zyga> btw: is this really needed - checking if mo has changed on every lookup?
[10:25] <siddharthk> i just now downloaded pyXDG from http://freedesktop.org/Software/pyxdg
[10:25] <zyga> it's not that those things change all the time
[10:25] <pitti> zyga: it isn't done
[10:26] <pitti> zyga: it's implemented as lazy initialization
[10:26] <Amaranth> mkedwards: So do I, I just don't possess enough menu-spec-fu to know how to fix this. :P
[10:26] <Amaranth> mkedwards: https://bugs.freedesktop.org/show_bug.cgi?id=2784
[10:26] <zyga> 10:22 < pitti> zyga: I added caching in the latest version as well, but it is flawed
[10:26] <zyga> hmm
[10:26] <zyga> pitti: okay I need more insight into how that works exactly
[10:27] <siddharthk> the README says, implementation of XDG-Base-Directory, XDG-Desktop, XDG-Menu, XDG-Icon-Theme standards. But http://www.freedesktop.org/standards/basedir-spec is not accessible.
[10:27] <pitti> zyga: the mo lookup has had caching since ages
[10:27] <pitti> zyga: my caching refers to the timestamp comparison
[10:27] <Amaranth> siddharthk: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
[10:27] <zyga> pitti: can I see your tree somehow?
[10:28] <pitti> zyga: download glibc sources, debian/patches/ubuntu-altlocaledir.dpatch
[10:28] <pitti> zyga: I prepare a new dpatch soon, when I finished testing the new libc
[10:29] <zyga> pitti: how is that different from apt-get source glibc ?
[10:29] <pitti> zyga: that's what I meant
[10:29] <zyga> :-)
[10:29] <zyga> excelent :>
[10:29] <zyga> I come from slackware background
[10:29] <dholbach> hey mvo
[10:29] <zyga> and apt-get is really nice ;] 
[10:29] <pitti> zyga: oh, indeed :-)
[10:30] <pitti> zyga: I came to Debian from SuSE in 1997, and I loved it
[10:30] <zyga> I tried fedora for a while but it was sooo broken on amd64 that I decided to try debian again :)
[10:31] <pitti> zyga: btw, the version you are currently downloading is the broken one
[10:32] <zyga> ok just a simple question - all of the patches from debian/patches are already applied, right?
[10:32] <pitti> zyga: it works great for single-domain apps (most console tools), but it breaks for gnome stuff
[10:32] <pitti> zyga: no, they are applied at build-time
[10:32] <pitti> zyga: debian/rules patch
[10:32] <pitti> zyga: call that to generate the build tree and apply the patches
[10:34] <zyga> pitti: hmm I think I need more help with the debian way... this will take some time 
[10:34] <siddharthk> and how this pyXDG is used ? is it something like applying user desktop settings once he logs in ?
[10:34] <pitti> zyga: glibc has a particularly difficult source packaging 
[10:34] <pitti> zyga: almost all packages are way easier
[10:35] <zyga> pitti: ./debian/rules made some stuff but I'm puzzled what exactly
[10:35] <zyga> pitti: I don't see any ./configure or anything similar
[10:35] <pitti> zyga: if you called it with patch, then it should have generated build-tree/glibc-2.3.2
[10:35] <zyga> ah so that's how it works
[10:36] <zyga> ./debian/rules ./debian/patches/foo.dpatch ?
[10:36] <pitti> zyga: nope
[10:36] <pitti> zyga: debian/rules patch
[10:36] <pitti> zyga: glibc has a lot of homebrew build magic, I don't fully analyzed it myself
[10:37] <jbailey> pitti: It's not that the packaging is difficult, it's that we've taken every hack that people usually think of for packaging and wound up using it in one package.
[10:37] <pitti> jbailey: sure :-) I mean I had to actually look into rules.d/* to find out how to rebuild without cleaning, and unpack sources, etc.
[10:38] <zyga> pitti: doesnt work (probably my fault)
[10:38] <pitti> jbailey: btw, my new patch looks promising
[10:38] <zyga> let's try it one more time...
[10:38] <zyga> getting clean glibc sources...
[10:38] <pitti> jbailey: another 30 minutes, and I shall have it ready
[10:38] <pitti> zyga: "debclean"
[10:39] <zyga> on my link apt-get source is faster ;] 
[10:39] <pitti> zyga: okay, debian/rules patch might not work
[10:39] <pitti> zyga: rm -r glibc-*
[10:39] <pitti> zyga: dpkg-source -x glibc*.dsc
[10:39] <jbailey> pitti: Nice!  I'll wind up hackign my glibc stuff a little later into the day than I tihnk I had planned for.  After I'm done looking at 1440 with Jordi, I think I need to go back to bed. =)
[10:39] <jdub> sabmoc: cool
[10:39] <sabmoc> :D
[10:39] <sabmoc> needs some more work, but I like it
[10:41] <zyga> pitti: extracting now... seems to work this time
[10:42] <zyga> pitti: ok, still the same situation - glibc is packed and debian is full of flurry stuff that I don't know about
[10:42] <zyga> trying README now
[10:42] <pitti> zyga: maybe jbailey can tell you how to unpack and patch the sources without building it
[10:43] <pitti> jbailey: what's the glibc way to do "debian/rules patch" (or apply-patches)?
[10:43] <jbailey> pitti: "debian/rules patch" =)
[10:44] <zyga> jbailey: from what pwd?
[10:44] <pitti> jbailey: hmm, that seems to fail for zyga
[10:44] <pitti> zyga: the source directory
[10:44] <zyga> jbailey: I've tried that but it didn't to anything usefull
[10:44] <jbailey> zyga: top of the source tree.
[10:44] <jbailey> zyga: Paste me the output in a /msg?
[10:44] <Burgundavia> amd64 users here?
[10:44] <zyga> rechecking...
[10:44] <zyga> ok
[10:44] <zyga> Burgundavia: me
[10:44] <Burgundavia> zyga: can confirm that you have libparted1.6-dev?
[10:44] <pitti> Burgundavia: ogra, thom
[10:45] <ogra> yup
[10:45] <Burgundavia> pitti: thanks
[10:45] <Burgundavia> hmm
[10:45] <Burgundavia> damn qtparted bug
[10:46] <siddharthk> amaranth, after browsing through the code, i see that, this module is acting as interface to .desktop files. am i right ?
[10:46] <ogra> Burgundavia, dholbach too
[10:46] <Amaranth> siddharthk: More or less.
[10:46] <Burgundavia> ogra: he is walking dog currently
[10:46] <zyga> Burgundavia: in a second
[10:46] <jbailey> zyga: Oh, I see.  No I meant literally 'debian/rules patch'
[10:47] <ogra> Burgundavia, ok
[10:47] <jbailey> zyga: You can't apply only one patch, it needs to be listed in debian/patches/00list
[10:47] <jbailey> zyga: The assumption is that all patches have to be done in the right order before files are patches multiple times.
[10:47] <jbailey> s/before/because/
[10:48] <zyga> jbailey: I see, so literally what do I need to do?
[10:48] <Amaranth> hey seb128, think you could help me with another python-xdg issue? :)
[10:48] <pitti> zyga: debian/rules patch
[10:48] <zyga> ah
[10:48] <zyga> :>
[10:48] <pitti> zyga: as I said :-)
[10:48] <zyga> hehe
[10:48] <zyga> that was confusing ;] 
[10:48] <zyga> ok this time it works great
[10:48] <zyga> thanks alot
[10:49] <zyga> Burgundavia: checking now
[10:51] <siddharthk> Amaranth, may i know the issue ?
[10:51] <zyga> Burgundavia: no I don't have it
[10:51] <zyga> Burgundavia: can install though
[10:52] <jdub> whiprush: i like the new hackergotchi spot on planet arslinux ;)
[10:52] <Amaranth> siddharthk: https://bugs.freedesktop.org/show_bug.cgi?id=2784
[10:52] <Burgundavia> zyga: ok, just checking
[10:52] <Amaranth> siddharthk: you can see the bug in action at http://img166.exs.cx/img166/8287/16nq.jpg
[10:52] <Burgundavia> zyga: can I provide with you a .dsc/.diff.gz to build and test install?
[10:53] <zyga> Burgundavia: hmm as I'm really unexperienced regarding debian build you might need to help me a bit along the way, buy yes
[10:53] <siddharthk> amaranth, ok let me see
[10:54] <Burgundavia> zyga: lets move to #ubuntu-motu
[10:54] <zyga> ok
[11:00] <pitti> infinity: ping
[11:04] <zyga> pitti: I'm with you -- reading intl sources now ;] 
[11:04] <jdub> jbailey: still around?
[11:04] <pitti> zyga: no, I'm currently discussing this issue with them, and they are very unfriendly
[11:05] <pitti> zyga: they don't even read and understand the problem, they just say "you want to do this modification? you don't know about packaging and it's nonsense"
[11:05] <siddharthk_> amaranth, i see some testcases in test dir,  we can add testcases validating against such bugs ?
[11:05] <jbailey> jdub: Yup
[11:05] <zyga> pitti: hey I didn't know about packaging but you managed to help me out ;-)
[11:07] <mkedwards> Amaranth: OK, I've reproduced the bug ... python-fu going into action.
[11:07] <Amaranth> mkedwards: hehe
[11:07] <Amaranth> siddharthk_: Well, you could try...
[11:08] <Amaranth> mkedwards: Do you have my menu editor?
[11:08] <mkedwards> Amaranth: reproduced it using test-menu.py
[11:08] <Amaranth> yeah, that works too :)
[11:09] <siddharthk_> let me see
[11:10] <seb128> Amaranth: ?
[11:11] <Amaranth> seb128: https://bugs.freedesktop.org/show_bug.cgi?id=2784
[11:13] <zyga> BTW: glibc could use some doxygen syntax :/
[11:13] <seb128> Amaranth: do you have the issue with gnome-menu-spec-test too ?
[11:13] <Amaranth> seb128: It doesn't show up in the menus, let me check with that.
[11:14] <jbailey> zyga: I think glibc is pretty much intended to be unfriendly.  There's alot of magic in there and the upstream maintainers are not known for being kind to new people.
[11:14] <zyga> pbuilder create --distribution hoary
[11:14] <pitti> jbailey: hah, I'm just experiencing this
[11:14] <zyga> hmm... sorry
[11:15] <pitti> jbailey: I asked them about this issue, and I was only insulted and threatened
[11:16] <Amaranth> seb128: Not that I can see.
[11:16] <Amaranth> seb128: Removing from 0x80c2c40 entry gnome-btdownload.desktop
[11:16] <jbailey> pitti: Yeah, it's pretty standard.  You need asbestos underwear to hang out on the libc mailing lists.
[11:16] <Amaranth> seb128: That's close to the last thing that happens, like I would expect.
[11:17] <jdub> jbailey: so, what do you think about moving to newer versions of NPTL in breezy?
[11:17] <pitti> jbailey: I won't followup any more, that makes no sense
[11:17] <pitti> jbailey: I rather ask Denis Barbier, he seems to be very nice and actually understand the gettext code
[11:17] <jbailey> jdub: mdz's already agreed to it. =)
[11:17] <jdub> aha, great :)
[11:18] <jbailey> jdub: I want to sync up with gotom on my idea of making the NPTL stuff a hard default, rather than relying on the tls hwcap.  Applications that are still broken and can't cope will need a solution to use LinuxThreads, though.
[11:18] <jbailey> jdub: But it would be really nice to actually use the NPTL header files.
[11:20] <doko> jbailey: nptl on powerpc is broken, isn't it?
[11:21] <seb128> pitti: WTF with g-c-m ? :) debian/patches/ui_browse_ctl.patch 865K ... ?
[11:21] <pitti> seb128: that's the result of update-po
[11:21] <seb128> but why doing that ?
[11:21] <pitti> seb128: sivang said that he did exactly like you suggested
[11:21] <jbailey> doko: Do you mean upstream?  I thought I'd seen a number of success reports.
[11:21] <seb128> and why in is patch and not in a translation patch ?
[11:21] <pitti> seb128: because he had to add some strings
[11:21] <seb128> pitti: no way
[11:21] <jbailey> doko: But tht that type of thing could be tweaked per-arch if it really needed to be.
[11:21] <seb128> and ?
[11:21] <Kamion> jbailey: sounds strange; what's the value in making it a hard default?
[11:21] <jbailey> doko: It's nice like we're consistant now.
[11:21] <pitti> seb128: the Hebrew/German translations are in separate patches
[11:22] <seb128> I said "diff -u po/nn.po.orig po/nn.po >> debian/patches/translations"
[11:22] <Kamion> jbailey: oh, the header files, I see
[11:22] <seb128> yeah, I know
[11:22] <seb128> and this patch is enough, isn't it ?
[11:22] <jbailey> Kamion: Upstream doesn't like the code that allows the linker to support switching between both.  They're of the opinion that you should use only the ld.so that was built with the matching thread library.  It shows up subtle problems from time to time.
[11:22] <seb128> what's the point to include 800k of po changes in a ui patch ?
[11:22] <jbailey> Kamion: But yeah, that and the header files that are actually getting development, etc...
[11:22] <seb128> pitti: I'm dropping that if you don't mind, the po changes are enough
[11:22] <pitti> seb128: I don't know, I relied on the fact that sivang and you discussed how to do it
[11:22] <Kamion> jbailey: sounds like the sort of thing we ought to be coordinating with Fedora etc. ...
[11:23] <pitti> seb128: sure, go ahead
[11:23] <seb128> thanks
[11:23] <pitti> seb128: but at least the POT changes should be somewhere
[11:23] <Kamion> so people don't go insane switching from distro to distro trying to figure out what's going on with their threaded applications :)
[11:23] <pitti> seb128: so that Rosetta users see the new strings
[11:23] <seb128> pitti: no need to include 800K of po to include the new .pot :)
[11:23] <pitti> seb128: sure :-) thanks for cleaning this up
[11:23] <jbailey> Kamion: Right.  I'm more actively worried about someone doing a backport of some sort on an Ubuntu system and having a non-working deb get handed to someone on Debian.
[11:23] <seb128> np
[11:24] <Kamion> jbailey: yeah, binary incompatibility there would be Badness
[11:25] <jbailey> Kamion: In practice it shouldn't be a problem when everyone actually drops 2.4 support.  Breezy might be a release too soon.  After that I'm pretty sure every distro will have dropped it.
[11:27] <zyga> pitti: cscope helps alot with glibc mess
[11:33] <smurfix> Just after I replaced my mainboard because of its random power failures, I get random power failures from outside
[11:33] <zyga> smurfix: get a random ups
[11:33] <smurfix> zyga: My computer room already has one
[11:33] <zyga> they're cheeper than random mobos
[11:34] <smurfix> zyga: time to string a power cable to the office :-/
[11:35] <zyga> smurfix: I've got one small ups for every home pc
[11:35] <zyga> call me crazy...
[11:36] <seb128> pitti: about the .pot files/rosetta, do we need to include them in the packages ? g-c-m has no .pot and it's not generated during the build
[11:36] <Amaranth> seb128, mkedwards, siddharthk_: any ideas? :)
[11:37] <mkedwards> Amaranth: the author of pyxdg should be shot.
[11:37] <mkedwards> Amaranth: actually, shooting is too good for him.
[11:37] <mkedwards> he should be strangled, drowned, diced, and then shot.
[11:37] <jbailey> zyga: Symbol versioning tricks.
[11:37] <pitti> seb128: they should at least be generated during the package build
[11:37] <pitti> seb128: without a pot, the Rosetta guys can't import the pacakge
[11:37] <zyga> jbailey: hmm?
[11:38] <Amaranth> mkedwards: heh heh heh
[11:38] <jbailey> zyga: It also allows you to override the symbols in glibc with local versions.
[11:38] <mkedwards> This code is unworthy of a Visual Basic programmer.
[11:38] <seb128> pitti: we can upload the .pot by hand, right ?
[11:38] <zyga> jbailey: tricky - almost smart really ;-)
[11:38] <pitti> seb128: yes, but this gets tedious
[11:38] <pitti> seb128: generating the pot file is not possible at build time?
[11:39] <seb128> Amaranth: I've some other stuff to do than replying to 100 questions/days about how edit a menu
[11:39] <Amaranth> seb128: sorry :/
[11:39] <seb128> pitti: need to hack, I don't like that
[11:39] <Amaranth> seb128: you seemed to be the only person that had any clue how this actually worked
[11:39] <seb128> Amaranth: no need to be sorry but I'm busy
[11:40] <seb128> Amaranth: I've read the spec ...
[11:40] <seb128> that's all
[11:40] <Amaranth> didn't seem to help me much :P
[11:40] <zyga> #define FOO __foo
[11:40] <seb128> read it again ? :)
[11:40] <zyga> I guess they like indirection alot
[11:42] <zyga> hmmm and k&r style too?
[11:44] <Seveas> pitti, i saw your mails on libc-alpha, good luck trying to convince bone-headed drepper to be nice, i've been reading that list for some time noe and those guys simply cannot be polite. Too bad that such an important part of GNU/Linux is in the hands of these idiots
[11:45] <zyga> pitti: ping?
[11:46] <pitti> Seveas: I don't really mind the impoliteness, I rather mind that they don't even read 
[11:47] <pitti> Seveas: somehow he insists that this is a packaging problem, but I already explained three times that this has got nothing to do with packaging
[11:47] <pitti> zyga: pong :)
[11:47] <Seveas> pitti, they're known not to read things, I have seen that behaviour very often, they seem to think they are gods
[11:47] <zyga> pitti: did you grok the dcigettext madness?
[11:47] <Seveas> especially that drepper guy, the others are definitely nicer people to talk to
[11:47] <pitti> zyga: only as far as I am required to actually change it for our needs
[11:47] <zyga> pitti: I'm wondering why they choose trees instead of hash lookups?
[11:48] <pitti> zyga: hashes would be great, but doing them in C is somewhat clumsy
[11:48] <zyga> pitti: strange, did them for ages and they're fine
[11:48] <pitti> zyga: actually the whole thing should be rewritten in a clean way (with supporting several directories :-) ), but this is not something for me
[11:49] <zyga> pitti: I guess I could (and would be willing to) do that but what are the chances this gets accepted?
[11:49] <maswan> hey guys, is cdimage doing better today?
[11:49] <pitti> zyga: upstream? Might become tricky :-)
[11:49] <zyga> only one problem really -- i386 && amd64 are my only test platforms
[11:49] <pitti> zyga: Debian/Ubuntu would certainly accept it if it's sane
[11:50] <zyga> I just imagine this bearded guy with alpha telling me it's wrong ;] 
[11:50] <pitti> zyga: in Debian and Ubuntu we have two handfuls more
[11:50] <pitti> zyga: however, this shouldn't be overly platform dependent
[11:51] <zyga> well all those file locks and other mess seems ... not so neccesary
[11:51] <zyga> unless we are racing with ever updating mo file ;] 
[11:51] <pitti> zyga: well, the whole code is just a mess..
[11:51] <zyga> (I understand the need for correctnes)
[11:52] <zyga> how could I test this without changing my working libc?
[11:52] <zyga> (alias magic experts please)
[11:52] <pitti> zyga: use LD_LIBRARY_PATH
[11:52] <zyga> hmm i thought about LD_PRELOAD 
[11:52] <ogra> zyga, dont move it over ;)
[11:52] <pitti> zyga: LD_LIBRARY_PATH=/home/foo/my-glibc my-program
[11:53] <pitti> zyga: I think PRELOAD is wrong
[11:53] <zyga> so there is no way to test gettext without rebuilding glibc every time?
[11:53] <pitti> zyga: maybe it works, but LD_LIBRARY_PATH is better
[11:53] <zyga> I'm used to LD_PRELOAD gettext trick
[11:53] <zyga> and use it all the time
[11:53] <pitti> zyga: oh, if it works, so much the better :-)
[11:53] <zyga> libintl_preload
[11:53] <pitti> zyga: if you can compile libintl separately, this is certainly much easier
[11:53] <zyga> .so-mething like that
[11:55] <jani> elmo ping
[11:55] <mkedwards> Amaranth: the behavior of pyxdg is correct.
[11:55] <mkedwards> Amaranth: that "Other" menu is getting exactly what it should.
[11:55] <Amaranth> mkedwards: ...
[11:56] <Amaranth> mkedwards: Then GNOME and KDE are wrong.
[11:56] <zyga> that is the biggest mess of them all :/
[11:57] <mkedwards> Amaranth: When an application is excluded from the only set to which it otherwise belongs, the <Unallocated/> in the definition of Other picks it up.
[11:58] <Amaranth> mkedwards: Entries in the user's application.menu should come after Other has picked up what it is supposed to.
[11:59] <mkedwards> Amaranth: KDE, at least, has deliberately deviated from spec.  http://lists.freedesktop.org/archives/xdg/2004-December/005541.html
[11:59] <zyga> (since /me didnt ever rebuild glibc and actually used it afterwards)
[11:59] <zyga> should I add linuxthreads or not?
[11:59] <jbailey> zyga: Just make sure that anything you do, you do it in a chroot.
[12:00] <Amaranth> mkedwards: Well, at least I have a solution now. :)
[12:00] <mjg59> Seveas: Hi
[12:00] <Treenaks> jbailey: Real Men hack libc outside chroots :)
[12:00] <sabmoc|zombie> heh
[12:00] <zyga> ok
[12:00] <jbailey> Treenaks: Right, and the ones install the hacks inside them. ;)
[12:00] <jbailey> sane ones, that is.
[12:01] <zyga> I'll let others hack it back in if it's worthy anything
[12:02] <mkedwards> Amaranth: clarified in spec:  http://lists.freedesktop.org/archives/xdg/2004-December/005593.html
[12:02] <pitti> zyga: this is not for hoary, but if you can get this ready and sane for early breezy (the tree will open in about two weeks), that'd rock :-)
[12:03] <zyga> pitti: I'm not counting on getting it into hoary really 
[12:03] <Amaranth> mkedwards: Doesn't that mean PyXDG is wrong?
[12:03] <zyga> If 2 people test this I'd be more than happy
[12:04] <Seveas> mjg59, hi, I have an HP Compaq nc6000 laptop that works great with warty except that kacpid sometimes takes 100%cpu and the machine won't reboot (it stops at "disabling acpi"). I have been told that you were the guy to talkt to about this
[12:04] <Seveas> mjg59, the odd thing is that there are no entries in dmesg or any other log
[12:04] <Treenaks> Seveas: don't forget the /proc/acpi stuff hanging
[12:05] <pitti> zyga: maybe you can write it in a way that it doesn't do the search and iteration process all over again for each message
[12:05] <mkedwards> Amaranth: no, it means it's right.  In the gnome-btdownload example, it's included by the Internet rule in /etc/xdg/menus/applications.menu and then excluded in .config, so it's Unallocated.
[12:05] <Seveas> and it happens when power.sh is run and tries to grep -q 'off-line' from the /proc/acpi/apdapter files
[12:05] <ogra> Seveas, look in /var/log/acpid for traces, rather then in dmesg 
[12:06] <Seveas> ogra, no traces there too
[12:06] <Seveas> simply nothing
[12:06] <mkedwards> Amaranth: the Other rule picks up applications that are Unallocated.
[12:06] <Amaranth> and that last link says Excluded entries are still considered allocated
[12:06] <jbailey> pitti: Hey, looking at your "Fixing USB after ppc resume" thread.  Would be be suitable to just do an /etc/init.d/hotplug reload on resume?  That way all you have to do is make sure that all the drivers for the usb subsystem are unloaded.
[12:07] <mkedwards> Amaranth: spelled out in http://lists.freedesktop.org/archives/xdg/2004-December/005545.html
[12:07] <Amaranth> Note that an entry that is included in a menu but excluded again by a later <Exclude> is still considered allocated
[12:07] <jbailey> pitti: I suspect it's safer than memorising them and reloading them, since it's reasonable that a person might suspend, and then unplug their usb printer.
[12:07] <pitti> jbailey: I think hotplug reload will last considerably longer
[12:07] <pitti> jbailey: why "memorise"
[12:07] <pitti> ?
[12:07] <mkedwards> Amaranth: duh. You're right.
[12:07] <pitti> jbailey: I both unload and load the USB host drivers after resuming
[12:08] <jbailey> pitti: Is that enough?  Don't you have to unload all the modules that depend on those host drivers?
[12:08] <pitti> jbailey: this should eventually look like "rmmod usb_uhci && modprobe usb_uhci"
[12:08] <mkedwards> Amaranth: I was still thinking in terms of PyXDG's NotOnlyAllocated weirdness.
[12:08] <pitti> jbailey: obviously nothing really depends on the host controller interface driver
[12:08] <zyga> pitti: right now I'd like to make minimal reimplementation
[12:08] <zyga> pitti: I'm reading mo format info
[12:09] <zyga> pitti: then I'll ask you what should be needed 
[12:09] <zyga> and well see
[12:09] <pitti> zyga: the mo parsing can certainly be taken from the current code
[12:09] <zyga> pitti: I'll probably do that as soon as I'm sure I understand everything in there
[12:09] <jbailey> pitti: I do not find the Linux driver model to be incredibly obvious in many, many way.s =)
[12:10] <pitti> jbailey: I didn't bother with this; it works for me, it works for other people, let's do it :-)
[12:10] <zyga> pitti: pcc is other-endian, right?
[12:10] <jbailey> pitti: But if usbcore doesn't flip out, then that's cool.
[12:10] <pitti> zyga: other=big, yes
[12:10] <pitti> jbailey: no, usbcore is fine
[12:10] <zyga> pitti: I never remember which really - ok thanx
[12:11] <pitti> jbailey: probably the E/O/UHCI driver just fleshes out the core
[12:12] <mkedwards> Amaranth: change the else branch in Rule.do() to:
[12:13] <mkedwards> elif entry.Add:
[12:13] <mkedwards>     entry.Allocated = True
[12:13] <mkedwards>     entry.Add = False
[12:13] <mkedwards> Amaranth: that WFM
[12:13] <Amaranth> mkedwards: Can you make a patch? :)
[12:13] <mjg59> Seveas: Ok, that's not /too/ unusual. Any chance you could test it with Hoary?
[12:14] <mjg59> There's been a huge amount of ACPI code fixed
[12:14] <mkedwards> Amaranth: kind of a pain to get it to you, since I'm booted into livecd.
[12:15] <Amaranth> ok
[12:15] <Seveas> mjg59, thanks for the answer, I will try out hoary 
[12:15] <mkedwards> Amaranth: xdg/Menu.py line 378.
[12:15] <Amaranth> i'll finish the bug i'll working on in my menu editor then try it
[12:15] <mkedwards> Amaranth: make sure to get the whitespace right.  :)
[12:16] <siddharthk_> Amaranth:i can give you the patch file with the changes suggested by mkedwards
[12:17] <Amaranth> siddharthk_: ok
[12:17] <mkedwards> mjg59: who judges whether a two-line fix to https://bugs.freedesktop.org/show_bug.cgi?id=2784 goes into hoary's pyxdg?
[12:17] <mjg59> mkedwards: No idea
[12:18] <mkedwards> Amaranth: is there an Ubuntu bug for this?
[12:18] <dholbach> mkedwards: upstream changes are the safest method
[12:18] <Amaranth> mkedwards: nope, just a PyXDG one
[12:19] <Amaranth> dholbach: No guarantee this will get patched upstream in time for hoary, which I was hoping for.
[12:19] <dholbach> ah
[12:20] <mkedwards> No debian bug either, no upload since October.
[12:20] <mkedwards> Ubuntu has patched it, Matt Klose is the Ubuntu uploader.
[12:20] <mkedwards> (patched the python-xdg package, not this particular bug)
[12:21] <siddharthk_> Amaranth: how should i give you the patch file ? 
[12:22] <mkedwards> Amaranth: I would probably open an Ubuntu bug, include the patch, let Matt decide whether to try to push it into hoary.
[12:22] <Amaranth> siddharthk_: alleykat@gmail.com
[12:22] <Amaranth> mkedwards: That's the plan. :)
[12:23] <mkedwards> Amaranth: don't forget to file it with Debian as well, tag +patch, point to upstream's bug URL
[12:24] <Amaranth> will do
[12:24] <Amaranth> my brain doesn't want to figure out this category_map tuple anymore
[12:24] <mkedwards> Amaranth: or maybe just attach the patch to upstream's bugzilla, point Ubuntu and Debian bugs both to it.  :)
[12:25] <mkedwards> and include the URL for the fd.o exegesis (the clarification to the spec)
[12:29] <siddharthk_> Amaranth: ok, i have sent the patch, please let me know if i have made some mistakes. This is my first time ... 
[12:32] <mkedwards> siddharthk_: diff -naur, right?
[12:33] <siddharthk_> mkedwards: not actually ... let me send that once again.  :(
[12:33] <mkedwards> -ur is fine
[12:35] <mkedwards> conventional thing is to cp -a the clean unpacked source tree to foo-0.0-orig, modify foo-0.9, then diff -Naur them
[12:35] <mkedwards> resulting patch applies cleanly with patch -Np1
[12:36] <siddharthk_> mkedwards: ok, got it. I am resending ...  Thanks.
[12:36] <mkedwards> or you could svn import, modify, svn diff -- but that's overkill for a two-line patch.  :)
[12:41] <siddharthk_> mkedwards: i am using -Naurw .. is it fine ?
[12:43] <mkedwards> siddharthk_: you don't want -w as a general rule, especially with python.
[12:44] <mkedwards> You don't really want to ignore re-indentation in a language where whitespace is significant.  :)
[12:44] <siddharthk_> mkedwards: ok, i understand
[12:45] <mkedwards> The -a, on the other hand, shouldn't matter (dpkg barfs on binary content in diff.gz)
[12:46] <mkedwards> but it bypasses diff's "is it text" heuristic, which can sometimes be fooled by UTF-8
[12:46] <Amaranth> siddharthk_: ok, i'm ready :)
[12:46] <Amaranth> siddharthk_: did you send the new version? :)
[12:46] <siddharthk_> Amaranth: yes, just now.
[12:47] <siddharthk_> Amaranth: it is using -Naru
[12:49] <siddharthk_> Amaranth: if you see that diff file, the last 'else' clause is not showing up with proper indent, though it is correctly indented in the .py file i modified.
[12:51] <ogra> fabbione, did you get my answer before the netsplit ?
[12:56] <fabbione> ogra: i didn't even get the question...
[12:56] <siddharthk_> mkedwards: should i use spaces or tabs ?
[12:57] <mkedwards> siddharthk_: I tend to just copy the adjacent line so that I get the exact same mix of spaces and tabs.
[12:58] <mkedwards> Or edit it in IDLE or python-mode.
[12:58] <thom> seb128: is the "imap4rev1" account type in evo actually ready to use? it seems hugely broken here
[12:59] <seb128> no
[12:59] <seb128> they have switched back the default to imap for a reason :p
[12:59] <torkel> thom: I'm using it and it works most of the time, but the other one is the preferred one...
[01:00] <zyga> ok here's the idea:
[01:00] <zyga> strip as much as possible from intl :-)
[01:00] <thom> seb128: it's totally non obvious from the new account setup - i have an imap4 account, i choose imap4
[01:00] <zyga> biggest mess to go is plural form stuff
[01:01] <zyga> if the equations could be pre-calculated (cough, because they don't change really, cough)
[01:01] <zyga> stuff would be faster
[01:01] <zyga> no parsing - no mess
[01:01] <ogra> fabbione, sec. phone...
[01:01] <siddharthk_> mkedwards: ok thanks, i have already sent the modified file to Amaranth
[01:01] <mkedwards> siddharthk_: thanks!
[01:02] <pitti> seb128: can I give you #7999?
[01:02] <Amaranth> siddharthk_: i fixed the patch you sent me
[01:02] <pitti> seb128: ("nautilus wants to execute all files on a vfat flash drive"
[01:02] <siddharthk_> Amaranth: ohh .. what was missing ?
[01:02] <zyga> first step could be to get all the expressions from info gettext "Plural forms"
[01:02] <Amaranth> spacing was wrong
[01:02] <seb128> pitti: sure
[01:03] <seb128> pitti: that's probably a gnomevfs issue, for sure not a pmount one
[01:03] <zyga> then perhaps set up ugly parsing and fall back when unknown expression is there 
[01:03] <pitti> seb128: reassigned, thanks
[01:03] <seb128> pitti: hum. Should the lsb-base depends be versionned ? Just looking on hal as an example you have versionned it
[01:03] <zyga> what do you guys think?
[01:03] <pitti> seb128: yes, earlier versions didn't support all the script functions we are using
[01:03] <thom> seb128: yeah
[01:04] <seb128> k, thanks
[01:04] <siddharthk_> Amaranth: yes, i realised that, and sent you the 3rd file. Thanks for bearing with me ...
[01:04] <Amaranth> siddharthk_: oh, sorry
[01:04] <Amaranth> i editted it right away then went to get breakfest going
[01:04] <Amaranth> err, breakfast
[01:05] <Amaranth> works great!
[01:08] <siddharthk_> Amaranth, mkedwards: This was my *first* direct interaction with people from ubuntu community. This was great .. the whole bug solving thing. I am happy .. :)
[01:08] <mkedwards> siddharthk_: kinda fun, innit?  :)
[01:08] <Amaranth> Now the hard part. :)
[01:09] <siddharthk_> mkedwards: yes .. true
[01:09] <siddharthk_> Amaranth: whats that ?
[01:10] <Amaranth> getting it into debian and ubuntu :P
[01:10] <mkedwards> Amaranth: and upstream, of course.  :)
[01:10] <Amaranth> https://bugs.freedesktop.org/show_bug.cgi?id=2784
[01:10] <Amaranth> done there
[01:12] <siddharthk_> mkedwards, Amaranth: when we will start with next bug ?  :)
[01:12] <pitti> elmo: please remove the following source packages from the archive: mozilla-firefox-locale-{de,es-ar,es-es,pl,pt-br}
[01:13] <Amaranth> siddharthk_: I'm done patching bugs for now. :P
[01:13] <Amaranth> siddharthk_: Have fun hitting up bugzilla though. :)
[01:13] <mkedwards> Amaranth or siddharthk_ : please reference http://lists.freedesktop.org/archives/xdg/2004-December/005571.html in a comment to the upstream bug.
[01:14] <dholbach> elmo: could you please sync  openscenegraph  xli  phpbb2  from sid?
[01:15] <mkedwards> Makes it clear to upstream where we got the interpretation that led us to change pyxdg's behavior.
[01:15] <pitti> elmo: (they are obsoleted by the new version of m-firefox-locale-all=
[01:15] <pitti> elmo: s/=/)/
[01:15] <Amaranth> mkedwards: Not relevant...
[01:16] <dholbach> did i miss something? when did CC meeting get re-scheduled?
[01:16] <Amaranth> mkedwards: I think you meant http://lists.freedesktop.org/archives/xdg/2004-December/005593.html
[01:16] <dholbach> 16 -> 22 utc
[01:17] <mkedwards> Amaranth: yes, that's better.
[01:17] <siddharthk_> Amaranth: yes.
[01:17] <dholbach> ah ... i see "as decided 14 days ago."
[01:17] <Amaranth> https://bugzilla.ubuntu.com/show_bug.cgi?id=8055
[01:18] <siddharthk_> Amaranth: can i open a bugzilla account ? is it needed ?
[01:19] <Amaranth> I think seb128 is listed as the package maintainer.
[01:19] <Amaranth> siddharthk: You can. You'll need to do post to bugzilla.
[01:19] <Amaranth> to post comments, attachments, new bugs, etc
[01:21] <siddharthk> Amaranth: ok
[01:24] <seb128> Amaranth: you should describe what the patch does and why
[01:25] <Amaranth> oh, i did upstream
[01:25] <Amaranth> i'll do it in ubuntu too
[01:25] <seb128> no you didn't
[01:25] <seb128> I've read both bug
[01:26] <Amaranth> i guess it is a little vague :P
[01:26] <seb128> totally
[01:26] <seb128> "This patch makes <Exclude>ed entries that were included earlier stay allocated
[01:26] <seb128> as the spec says."
[01:26] <seb128> you should add a comment about how you determine that and what you change
[01:26] <seb128> and point to the spec
[01:27] <Amaranth> mkedwards: You wanna fill that in for me? :)
[01:29] <Amaranth> mkedwards: ?
[01:29] <Amaranth> seb128: Actually, I just know what I've been told it does. :/
[01:29] <Amaranth> seb128: I ran it through a couple tests.
[01:30] <mkedwards> seb128, Amaranth : really must go to bed now, but http://lists.freedesktop.org/archives/xdg/2004-December/005545.html explains why this test case should not be matched by the <Unallocated/> rule that creates the "Other" menu in /etc/xdg/application.menus.
[01:30] <Amaranth> yes, but what does the patch _do_?
[01:30] <Amaranth> and why?
[01:32] <mkedwards> If a previous <Include> pattern matched the menu entry, then it set entry.Add to True.  So the correct behavior for <Exclude>, if it finds entry.Add to be True, is to set it to False but to remember that it was allocated along the way.
[01:34] <mkedwards> Previously, the only way Allocated could get set was on insertion of the entry into a menu.  This adds a second code path by which Allocated gets set: Include followed by Exclude.
[01:34] <Amaranth> seb128: https://bugs.freedesktop.org/show_bug.cgi?id=2784 <--updated
[01:34] <seb128> Amaranth: k, thanks
[01:35] <Amaranth> shit, wait!
[01:35] <Amaranth> that one is broken :P
[01:35] <mkedwards> seb128: recommend you exercise the bug reporter's test case using /usr/share/doc/python-xdg/examples/test-menu.py
[01:35] <seb128> ?
[01:35] <Amaranth> siddharthk: i should have stayed with mine, your latest is borked
[01:36] <seb128> mkedwards: k, thanks
[01:36] <siddharthk> Amaranth: oops ... :(
[01:36] <mkedwards> you'll see that the Other menu goes away when the patch is applied.
[01:37] <Amaranth> seb128: ok, the original patch the one to use
[01:37] <mkedwards> Truly unmatched items will still go in Unallocated.
[01:37] <mjg59> thom: Sorry to keep nagging, but had a chance to take a look at the gdm-signal stuff? (It's getting a bit urgent)
[01:37] <seb128> mkedwards: right, I've understood, thanks for the explanations
[01:38] <mkedwards> Amaranth: not easy to keep the spaces straight if you're not experienced with python and patch.
[01:38] <mkedwards> g'night, all.  Try to make it clear to the Debian maintainer too.  :)
[01:39] <Amaranth> seb128: the first patch is the one i tested
[01:39] <Amaranth> i thought siddharthk tested the one he gave me :P
[01:39] <seb128> pitti: known about /usr/share/gnome-volume-manager/gnome-volume-manager-gthumb.sh (#7725) ?
[01:39] <siddharthk> Amaranth: ohh ... really sorry for that .. but is it related to spaces and tabs ?
[01:39] <Amaranth> yeah
[01:40] <Amaranth> fuck, found a regression, i think
[01:40] <seb128> I'll wait before using the patch I think 
[01:41] <thom> pitti: is there a CAN for 6319
[01:42] <Amaranth> the original authors of this junk mixed tabs and spaces
[01:42] <Amaranth> so i have to compensate
[01:42] <Amaranth> not mkedwards and siddharthk, the authors of pyxdg
[01:43] <mkedwards> seb128: replaces one line with two.  Just have to get the indentation right.
[01:43] <thom> mjg59: noted, sorry i've not done it yet
[01:44] <mjg59> seb128: Have you done anything with #7583?
[01:44] <mjg59> thom: Ok, no problem
[01:44] <mjg59> I'd just prefer to be able to build ISOs without needing my own hacked packages :)
[01:44] <zyga> pitti: ping
[01:46] <seb128> mjg59: nop, waiting to get gdm-signal in the archive
[01:47] <mjg59> seb128: Would it be possible to do it preemptively? :)
[01:48] <seb128> sure, I'll update
[01:48] <mjg59> At the moment, the shortcut does nothing (apm will return 0, so it won't move onto the next option, but running apm with no options results in it just printing the battery status to stdout)
[01:49] <seb128> k
[01:49] <mjg59> Thanks!
[01:50] <seb128> np
[01:50] <Amaranth> seb128: Ok, I've done a half-dozen different little tests, PyXDG now matches GNOME and the spec in this area.
[01:51] <Amaranth> making a new patch
[01:52] <ogra> fabbione, re, the question was...please add #ubuntu-motu to your weblogger :)
[01:52] <fabbione> ogra: ok.. just in a sec
[01:52] <siddharthk> hmm. i am waiting to see that.
[01:52] <ogra> fabbione, wow, great :)
[01:56] <fabbione> ogra: done... logs on the web will start to appear in 30/60 minutes
[01:57] <ogra> fabbione, great, thanks, thats perfect timing ( in an hour we start the malone test that should get logged)
[01:57] <fabbione> ogra: remeber that it is still an IRC network
[01:57] <ogra> fabbione, oops, sorry 2h
[01:57] <ogra> fabbione, sure ;)
[01:57] <fabbione> ogra: so if there is a netsplit the client can be anywhere
[01:57] <fabbione> ogra: ok.. just a reminder :)
[01:58] <ogra> yep, i know....
[01:58] <ogra> :)
[01:58] <fabbione> you do.. somebody did complain about incomplete logs..
[01:58] <fabbione> have fun
[02:01] <ogra> fabbione, surely it wasnt me who complained..... (i wouldnt argue with the master of pain) ;)
[02:01] <dholbach> elmo: could you please sync  xplc  from sid as well?
[02:02] <fabbione> ogra: ehehhe
[02:02] <Amaranth> seb128: Ok, lots of testing on this one. Seems to work fine. https://bugs.freedesktop.org/show_bug.cgi?id=2784
[02:03] <seb128> k
[02:08] <thom> seb128: for gdm-signal, you'll need to dep on powermanagement-interface version 0.3
[02:08] <seb128> thom: I've uploaded a patched version 
[02:08] <seb128> thom: I'll change that in the next upload
[02:11] <Amaranth> perfect
[02:11] <Amaranth> :P
[02:11] <Amaranth> seb128: I have an excuse for not understanding the spec now. The implementations are all different! :D
[02:12] <seb128> Amaranth: are you sure than your patch is not reversed ?
[02:12] <seb128> grrrr, it is
[02:12] <Amaranth> oh jeez
[02:12] <Amaranth> *facepalm*
[02:12] <Amaranth> sorry
[02:12] <seb128> np
[02:13] <seb128> upstream will start wondering why you flood them
[02:13] <Amaranth> I haven't made patches in like 18 months. :P
[02:13] <seb128> you should work, try the patch, etc before sending a new version every 5 min
[02:13] <Amaranth> yeah
[02:13] <zul> hey
[02:13] <dholbach> hey zul 
[02:13] <Amaranth> didn't go to bed last night, wanted to get this fixed first
[02:13] <seb128> hi
[02:13] <Amaranth> i blame that :P
[02:13] <zul> hey dholbach 
[02:14] <dholbach> zul: what about the kernel-non-installable-packages? :-)
[02:14] <zul> dholbach: whoops..totally forgot about it
[02:14] <zul> ill have a look at it today
[02:15] <Amaranth> seb128: I promise to get a clue first next time. ;)
[02:15] <dholbach> zul: that'd be cool because we want to discuss the proceedings of the packages on  wiki/MorgueCandidates  tonight
[02:15] <dholbach> (after the CC meeting)
[02:15] <zul> k
[02:16] <dholbach> zul: but don't worry
[02:16] <seb128> Amaranth: don't worry :)
[02:16] <seb128> Amaranth: there for upstream, some of them don't like to be mail flooded 
[02:16] <zul> dholbach: i think we might need to keep most of them because if something doesnt work with them 2.6.10 they can always fall back to 2.6.8
[02:17] <Amaranth> yeah, i can understand that
[02:17] <Amaranth> i've been flooding myself too :/
[02:17] <dholbach> zul: that's completely fine with me, the packages should just be installable
[02:17] <zul> dholbach: k
[02:18] <zul> i guess i can see why they arent installable ;)
[02:19] <dholbach> zul: gooooood :-)
[02:23] <dholbach> seb128: could it be  libmrproject  was superseded by  planner  and now is completely useless and doesn't deserve to be fixed?
[02:23] <jdub> dholbach: yes
[02:24] <jdub> dholbach: 100% correct
[02:24] <seb128> dholbach: correct
[02:24] <jdub> dholbach: it should be purged
[02:24] <seb128> damned jdub 
[02:24] <seb128> too quick :p
[02:24] <dholbach> woohoo! Clean! UNIVERSE! today!
[02:24] <ogra> hehe
[02:24] <seb128> hey jdub :)
[02:24] <tseng> dholbach: <3
[02:26] <dholbach> tseng: could you please elaborate on "<3"? :-)
[02:27] <jdub> morning slow128 ;)
[02:29] <haggai> how is network configuration supposed to be done on the live CD?  I inserted a wlan card but the interface didn't come up
[02:35] <thom> mjg59: Uploading via ftp powermanagement-interface_0.3_source.changes: done. enjoy
[02:36] <dholbach> what's wrong with the powerpc-buildd? its last build was  workrave_1.6.2-1ubuntu1_20050322-1106-powerpc-failed 
[02:39] <ogra> dholbach, the same as yesterday ?
[02:39] <jani> ping elmo
[02:39] <haggai> jdub: am I right in thinking that you get storage media eg USB stick icons to pop up on the desktop on gnome?
[02:39] <ogra> dholbach, main<->universe transition of some build dependencys ?
[02:40] <zyga> hmm
[02:40] <zyga> gettext should be thread safe, right/
[02:40] <haggai> jdub: its turned off in KDE by default and I'm wondering if it is better to turn on too.
[02:40] <mjg59> thom: Rocking
[02:40] <jdub> haggai: yeah, we do
[02:40] <haggai> jdub: so what was your reasoning to do those but nothing else on the desktop?
[02:40] <dholbach> ogra: but it should continue building :-)
[02:40] <jdub> haggai: atm, we have removeable drives and network drives on the desktop
[02:40] <dholbach> ogra: even if one package fails :-)
[02:41] <jdub> haggai: we didn't have a good, obvious interface for unmounting, etc.
[02:41] <jdub> haggai: now we have a modified drivemount applet, but it's not idea
[02:41] <jdub> l
[02:41] <ogra> dholbach, might take some time....
[02:41] <haggai> jdub: hmm, we have the media:/ view where you can unmount, but you reach it via konqueror -> removable storage.  Is that too many clicks away?
[02:42] <jdub> haggai: your call, dude :-)
[02:42] <jdub> haggai: for reference, we have the Computer view, too
[02:42] <jdub> haggai: felt it was better to have something obvious
[02:42] <jdub> i hate storage and filesystems
[02:42] <jdub> messy stupid crap
[02:42] <haggai> jdub: bah :)  I wanted a sound reason that I could just use :)
[02:42] <jdub> BURN IT ALL!
[02:43] <jdub> haggai: well, you've pretty much given the reason for why we did it ;)
[02:43] <haggai> jdub: ok, I'll take it back to the others then
[02:43] <haggai> jdub: while we're talking desktop stuff: OOo print admin tool.  I see you advocated removing the icon completely
[02:43] <Kamion> looks like today is the day I upload the ENTIRE INSTALLER
[02:43] <jdub> you should *so* not use me as a reference for kde usability dude
[02:43] <jdub> haggai: yeah
[02:44] <haggai> jdub: heh
[02:44] <jdub> haggai: what's your call on that?
[02:44] <jdub> haggai: i realised immediately afterward that we really need to work together on those calls
[02:44] <haggai> jdub: so you consider command line stuff to be ok now?  That's the only way to access additional printer/fax filtering stuff
[02:44] <jdub> haggai: we have gnome-cups-manager
[02:44] <jdub> which doesn't necessarily cover the weird OOo things
[02:44] <haggai> jdub: right, but oopadmin doesn't duplicate that anyway (add a printer is disabled on CUPS systems)
[02:45] <ogra> hmm, funny, my alt-tab recently only shows the two panels and the desktop....
[02:45] <haggai> jdub: so, you have: font replacement per printer, add a pdf converter and fax device.  Are those already covered elsewhere?
[02:46] <jdub> ogra: that's usually ctrl-alt-tab
[02:46] <ogra> ah, switching to tty1 logging in and switching back solves it....weird
[02:46] <dholbach> jdub: wow... didnt know that one
[02:46] <ogra> jdub, i have a lot of porbs with this laptop wrt keyboard stuff....
[02:46] <jdub> haggai: how important is "add a pdf converter"?
[02:46] <jdub> dholbach: a11y feature :)
[02:47] <dholbach> wooooooooow :-)
[02:47] <haggai> jdub: its important if you need very high quality stuff that OOo's PDF output isn't good enough for
[02:47] <ogra> jdub, so my laptop is more accessible then wanted :-P
[02:47] <jdub> haggai: ok, niche use case.
[02:47] <jdub> haggai: font replacement per printer seems niche.
[02:48] <haggai> jdub: about those icons, I wondered about adding the generic OOo icon (from which you can do new document or open any OOo doctype), and bin the less used doc type icons (drawing, math, writer/web)
[02:48] <wasabi_> morning
[02:48] <haggai> jdub: so a niche use = command line?
[02:48] <ogra> jdub, have such problems twice a week....seems like my meta key is stuck, or ctrl or something else...changes everytime a bit...
[02:48] <jdub> haggai: fax is interesting, but requires input of command line, etc. we should integrate that with cups better. in the mean time, don't mind losing the weird feature.
[02:48] <haggai> jdub: can we not collect nice cases in a gui point somewhere?
[02:48] <ogra> jdub, (its a new keyboard, so i doubt its a HW issue)
[02:49] <haggai> uh niche caches not nice
[02:49] <jdub> haggai: niche use case doesn't immediately relegate it to command line, but looking at this particular case, i think we can do without
[02:49] <jdub> haggai: the good thing is, you can still get to it if you have specific needs
[02:49] <haggai> jdub: righty.  And the doc type reduction?
[02:50] <jdub> yeah, i agree
[02:50] <jdub> that's a good solution
[02:50] <jdub> so we'd have
[02:50] <wasabi_> so yesterday i had mdz move a binary package from multiverse to universe. he said it would be moved in the next pulse. Am I guessing right that I need to reupload?
[02:50] <wasabi_> (since it is not yet moved)
[02:50] <jdub> presentation, word processor, spreadsheet, 'new document'
[02:50] <jdub> ?
[02:51] <haggai> jdub: s/'new document'/openoffice.org/
[02:51] <haggai> jdub: since you have to choose File->New
[02:51] <jdub> isn't there some 'new document' window you can open up?
[02:51] <jdub> there used to be an icon for it
[02:52] <jdub> i'm sure
[02:52] <jdub> oh
[02:52] <jdub> from template one
[02:52] <jdub> yeah
[02:52] <jdub> we could rename that to "New OpenOffice.org Document"
[02:52] <pitti> infinity: ping
[02:52] <haggai> checking it allows all functionality
[02:53] <jdub> business cards!
[02:53] <jdub> labels!
[02:53] <jdub> templates!
[02:53] <zyga> pitti: gettext should be thread safe?
[02:53] <jdub> this is exciting!
[02:53] <haggai> heh yeah even more stuff OOo didn't even make menu entries for
[02:53] <dholbach> thanks elmo 
[02:53] <pitti> zyga: erm, isn't this read-only?
[02:53] <jdub> doesn't do gnome-vfs though
[02:53] <pitti> zyga: or you mean internal data structures?
[02:53] <haggai> there's a bug somewhere in the packaging
[02:53] <zyga> pitti: yup but internal goo is not
[02:54] <pitti> zyga: I think so
[02:54] <zyga> pitti: well since it probably has too...
[02:54] <jdub> whoa
[02:54] <jdub> haggai: why is -gnomevfs in universe?
[02:54] <haggai> jdub: it doesn't work atm
[02:54] <jdub> oh
[02:55] <haggai> jdub: yeah new document looks good
[02:55] <jdub> so we lose drawing and math
[02:55] <ogra> ****** ok guys, everybody who wants to attend the malone test, please join #ubuntu-motu we start at 14:00 UTC ******
[02:56] <jdub> ****** woohoo! *******
[02:56] <haggai> jdub: and printer admin, and writer/web
[02:56] <jdub> yeah
[02:56] <jdub> though printer admin was already lost in another menu
[03:00] <ogra> **** malone test starts NOW in #ubuntu-motu ****
[03:00] <Loevborg> (btw: writer/web should be renamed to "web editor" or something)
[03:10] <doko> jdub, haggai: are you sure that you want to rename OOo menu items that short before the release? what about the translations needed for other languages?
[03:11] <doko> jdub: openoffice.org-evolution and openoffice.org-kde should go back to main/desktop
[03:42] <haggai> doko: hmm, ok.  We can still remove the extras though
[03:46] <mako> jani: got it dude :)
[03:50] <mantiena> Kamion, hi
[03:51] <Kamion> mantiena: hi
[03:57] <jani> mako cool
[03:58] <dholbach> is anyone aware of the powerpc-buildd hanging somehow?
[03:58] <mantiena> Kamion, in casper udeb TODO I found this info: "- Mount hard disk partitions - os-prober"
[03:59] <mantiena> Kamion, who will do this job ? you or mdz ?
[04:00] <Kamion> mantiena: I have no idea
[04:00] <mantiena> ;)
[04:00] <mantiena> Kamion, you aren't os-prober maintainer ?
[04:01] <fabbione> pitti: are you around?
[04:01] <pitti> fabbione: yeah
[04:01] <Kamion> mantiena: one of them, upstream
[04:01] <fabbione> pitti: any ETA for #8020?
[04:02] <Kamion> mantiena: I'm not sure how that's especially relevant though; os-prober shouldn't need any changes for that TODO item
[04:02] <pitti> fabbione: as soon as I reach infinity
[04:02] <fabbione> ok
[04:02] <pitti> fabbione: I can also upload it on my own, but I'd like to talk to him first
[04:02] <pitti> fabbione: probably he is asleep, though
[04:03] <fabbione> ok thanks
[04:04] <mantiena> Kamion, os-prober can write partitions, available on user's system, into /etc/fstab ?
[04:05] <Kamion> mantiena: no; please read the os-prober documentation
[04:06] <mantiena> Kamion, I've read already
[04:06] <Kamion> mantiena: then I do not understand why you asked the question above
[04:07] <mantiena> Kamion, because you told, that os-prober shouldn't need any changes for that TODO item ;)
[04:07] <Kamion> mantiena: that statement holds
[04:07] <Kamion> mantiena: other components are supposed to *use* os-prober to do things like messing with /etc/fstab
[04:07] <Kamion> mantiena: os-prober simply produces output
[04:07] <Kamion> mantiena: this should be quite clear from its documentation
[04:08] <mantiena> Kamion, ok, I understand this
[04:10] <Kamion> mantiena: have a look at the way os-prober is used throughout the installer; yaboot-installer/debian/postinst is a reasonable example
[04:11] <mantiena> Kamion, ok, it seems in os-prober's output there are missing partitions without os, for example fat32 partition with pictures, right ?
[04:11] <Kamion> that's true
[04:12] <Kamion> I'm not sure whether that would be better off in os-prober or in casper
[04:12] <Kamion> or somewhere else
[04:12] <Kamion> I suspect not os-prober; that's not really its task
[04:12] <mantiena> Kamion, I think ubuntu installer should also do this job somewhere
[04:13] <Kamion> sure
[04:14] <mantiena> because if user installs ubuntu on system, which already has some partition[s] , then user would very happy if he can access these partitions from newly installed ubuntu system ;)
[04:14] <Kamion> yes, I've read the bug reports about that
[04:14] <Kamion> you don't need to persuade me of its usefulness
[04:15] <mantiena> ;)
[04:15] <Kamion> I dunno, maybe some component a bit like os-prober that output something in a similar format about data partitions
[04:16] <mantiena> Kamion, it seems there are no filesystem type in os-prober output, right ?
[04:18] <Kamion> nope
[04:18] <Kamion> I wasn't the one who wrote that TODO item :) os-prober is probably just something to look to for ideas, not the Right Thing To Use
[04:19] <mantiena> it seems so
[04:20] <mantiena> in any case it's not casper's job, because ubuntu-installer (and debian-installer too) needs same thing
[04:20] <Kamion> it is extremely difficult to get casper to use bits of partman, and I don't think that would be very sensible
[04:21] <Kamion> I don't really mind there being a bit of code duplication here, as long as the bulk of it is common
[04:21] <mantiena> Kamion, partman already does this job ?
[04:21] <Kamion> casper will still have to be responsible for starting it off
[04:21] <Kamion> mantiena: no, but whatever would do this in the installer would have to be called from partman
[04:22] <mantiena> Kamion, maybe new d-i module, named for example partition-finder should be created for this ?
[04:23] <Kamion> mantiena: it would be sanest to have something that spits out easy-to-parse output in a similar way to os-prober, and have casper and partman both use it to add to /etc/fstab as needed
[04:24] <Kamion> the file format of /etc/fstab is probably not suitable in itself, because casper would want to mount filesystems immediately while partman probably wouldn't
[04:26] <mantiena> Kamion, I think it both cases (partman and casper) found partitions should be writen to /etc/fstab, casper could just run "mount -a" after fstab is filled with found partitions
[04:26] <mantiena> s/it/in
[04:27] <Kamion> mantiena: the way partman works, that probably wouldn't be appropriate
[04:28] <Kamion> mantiena: you would want the partitions to be selected to be mounted in particular places by default, but the user must be able to override that when doing manual partitioning
[04:28] <Kamion> you can't just dump them into /etc/fstab and say "ha, screw you hippy, I don't care if you didn't want those mounted" :)
[04:29] <mantiena> Kamion, I understand this
[04:29] <Kamion> so fstab output format wouldn't be appropriate
[04:30] <pitti> who can add tags in bugzilla?
[04:30] <mantiena> Kamion, maybe you know if automatic finding partitions is planned in hoary or it will be done in hoary+1 ?
[04:31] <Kamion> mantiena: seems unlikely that new features like that will make hoary
[04:31] <Kamion> mantiena: it is ONE WEEK until our release candidate :)
[04:31] <dholbach> pitti: add easytofix as well, for ubuntu-love--days
[04:31] <Kamion> pitti: mdz or jdub, I think
[04:32] <pitti> Kamion: okay, thx
[04:32] <mantiena> Kamion, so, it seems I need to write this component by myself, because I need it this month ;)
[04:32] <Kamion> mantiena: you're certainly the person pushing for it most
[04:33] <mantiena> it's not a problem to write this component for me, I just don't want do duplicate my work if someone other from ubuntu developers is coding the same thing ;)
[04:34] <fabbione> pitti: ping?
[04:34] <Kamion> elmo: please sync partman-partitioning 33 from Debian; translation fixes only
[04:34] <Kamion> mantiena: as far as I know nobody is currently working on it
[04:35] <pitti> fabbione: pong
[04:36] <mantiena> Kamion, I can start to write this component today and it would be nice if ubuntu developers would accept my work ;)
[04:36] <DarthFrog_> What IRC channel is the Community Council meeting in?
[04:36] <zul> #ubuntu-meeting
[04:36] <DarthFrog_> Tnx
[04:37] <zul> no probs
[04:37] <mantiena> Kamion, what things (consultation, documentation) I should do if I want to make component, which will be ok for ubuntu ?
[04:37] <thom> weee, just worked out #7711; now to work out why it's happening and how to fix it
[04:37] <mantiena> Kamion, should I write specifications of partition-finder into ubuntu wiki ?
[04:37] <Kamion> mantiena: sure, anything but IRC
[04:38] <Kamion> mail, whatever
[04:38] <Kamion> I'm not convinced about the name "partition-finder", it doesn't really say what it does
[04:38] <Kamion> but whatever
[04:39] <Kamion> mantiena: since it's post-hoary there's plenty of time
[04:40] <mantiena> Kamion, it's plenty of time for you, but not for my project this component should work in 5 days ;)
[04:41] <Kamion> mantiena: sure, so you don't have to make it be the final design; but we have plenty of time to make it non-hackish
[04:41] <Mitario> brb, trying kubuntu
[04:41] <Kamion> 5 days? don't see why you're even talking to us in that case, rather than getting coding :)
[04:42] <mantiena> Kamion, because I wanna write good software, not evil hack :)
[04:42] <Kamion> yeah, but we're all ultra-busy with bug fixing for release
[04:42] <Kamion> so right now we aren't the best people to come to for design discussions :)
[04:46] <mantiena> Kamion, ok, it seems you alredy told be main design ideas, I just write these to ubuntu wiki and show them to mdz (if he will be not too busy to see these ;)
[04:47] <mantiena> s/be/me
[04:47] <Kamion> mantiena: ok
[04:47] <Kamion> elmo: please sync floppy-retriever 1.05 from Debian; translation fixes only
[04:49] <dholbach> see you later
[04:58] <mdz> wasabi_: no, you do not need to upload
[04:59] <pitti> Hi mdz 
[04:59] <mdz> mantiena: I am already planning to write it, but in any case it will not go into Hoary (only Breezy)
[04:59] <ogra> mako pong
[04:59] <pitti> mdz: can you add bugzilla tags? ("security" and "utopia" would be nice)
[04:59] <ogra> hi mdz
[05:00] <mako> ogra: hey ddue :)
[05:00] <ogra> :)
[05:00] <mdz> pitti: keywords?
[05:00] <pitti> mdz: erm, yes
[05:00] <pitti> mdz: they correspond to debbugs tags somehow
[05:01] <fabbione> hey mdz
[05:02] <mdz> pitti: what would be the description for utopia?
[05:03] <pitti> mdz: "Bugs that affect the automatic handling of removeable media"
[05:03] <pitti> mdz: i. e. g-v-m, hal, gnome-vfs, maybe inotify, etc.
[05:03] <pitti> mdz: we can also call it "hotplug"
[05:03] <pitti> mdz: but that's somewhat overloaded
[05:04] <mantiena> mdz, maybe you already has the specifications ?
[05:05] <seb128> mdz: a "translations" would be nice too
[05:05] <mdz> mantiena: no, I will write the specification in Sydney in April
[05:05] <seb128> or i18n
[05:05] <pitti> seb128: l10n, rather
[05:05] <seb128> right
[05:06] <mdz> security and translation added
[05:06] <seb128> thanks
[05:11] <wasabi> mdz, how long is it supposed to take then?
[05:12] <jani> elmo ping
[05:13] <mantiena> mdz, I can write specifications today for you if you aren't agains this ;)
[05:16] <mdz> wasabi: it already took effect, I can see it on archive.ubuntu.com
[05:16] <mdz> mantiena: I think there is some discussion to be had in order to finalize the requirements; what do you think?
[05:16] <mdz> where should they be mounted, how will this interact with Nautilus, how to interface with os-prober
[05:30] <jdub> Kamion: ooof!
[05:30] <Kamion> jdub: hmm?
[05:30] <jdub> hoary-changes "love" ;)
[05:31] <Kamion> good, isn't it
[05:31] <Kamion> semi-automated ;)
[05:31] <Kamion> would be so much easier in revision control
[05:32] <Kamion> then I can use the same translation-exporting scripts
[05:36] <Kamion> elmo: how often does the mirror on rookery get updated?
[05:37] <mantiena> mdz, I should go, will talk with you later
[05:38] <jordi> Kamion, mvo: nano 1.3.6 has been released. It appears to work quite well here.
[05:45] <jdub> french gypsy.
[05:52] <mdz> Kamion: thanks for the clarification on d-d
[05:53] <Kamion> elmo: ok, cdimage.u.c/releases/hoary/preview/ is gone now; the preview's only on releases.u.c/
[05:53] <Kamion> elmo: and I've updated the script so that in future releases will only go on one of releases/cdimage, not both
[05:53] <thom> Kamion: any joy with simple torrent pool?
[05:54] <elmo> Kamion: thanks a lot
[05:54] <Kamion> mdz: you have no idea how many times I redrafted that message ;)
[05:54] <Kamion> thom: oh, crap. will look now
[05:54] <mdz> Kamion: yes I do :-)
[05:55] <mdz> Kamion: I had to ABORT ABORT ABORT the thomas bushnell subthread and didn't have a good place to try to start over; I think you've done that, though, thanks
[05:57] <Kamion> mdz: np
[05:57] <Kamion> joeyh's response on seeing the patches repository was something like "holy crap, there's a lot of stuff in there"
[05:58] <Kamion> he noted that we hadn't fed back a lot of discover1-data patches, I assume because they were all last-minute warty release things and we forgot about them
[06:06] <mdz> pitti: what is the outlook for the glibc locales problem? do we need to revert?
[06:06] <jbailey> mdz: He sent me a patch this morning to incorporate.
[06:07] <jbailey> mdz: It basically doesn't check files that we already know for certain don't exist, but it doesn't try to cache much beyond that.
[06:07] <mdz> Kamion: also, LCA registration
[06:07] <pitti> mdz: the new patch is essentially like the old one without caching, but avoids at least some stats()
[06:08] <pitti> mdz: it is nontrivial to make it more efficient, so this is what Hoary should ship
[06:08] <pitti> mdz: I'm currently discussing this with upstream, BTW (however, they are not exactly cooperative)
[06:09] <mvo> jdub: any news from the update-notifier icon :) ?
[06:09] <jbailey> pitti: What are you having is not a discussion, it's a beating.  =)
[06:09] <pitti> mdz: for breezy we should change the patch to drop timestamp comparison and instead prefer files in /usr/share/locale if they exist
[06:09] <pitti> mdz: i. e. we need a search path lists
[06:09] <Kamion> mdz: should I be registering as professional or hobbyist? I assume professional
[06:09] <pitti> jbailey: btw, what's the upload ETA?
[06:09] <mdz> Kamion: I think hobbyist
[06:10] <Kamion> ok
[06:10] <pitti> jbailey: I have another bug in the install-language-locales script which I would like to fix as well
[06:10] <jbailey> pitti: Evening sometime or tomorrow morning.
[06:10] <mdz> Kamion: it is a hobbyist registration which I have to transfer
[06:10] <pitti> jbailey: do I have another hour then?
[06:10] <Kamion> ah, right
[06:10] <pitti> jbailey: bug #8000 (thanks seb128 :-) )
[06:10] <jbailey> pitti: Many, it's only just stopped being morning here.
[06:10] <seb128> pitti: you're welcome :)
[06:10] <Kamion> in that case I shall use my @debian.org address to register ;)
[06:10] <pitti> jbailey: oh, nice :-)
[06:11] <seb128> pitti: you get it too ?
[06:11] <pitti> seb128: I never tried this :-)
[06:11] <pitti> seb128: I think remove-language-locales should not remove the locale that is selected in /etc/environment
[06:14] <pitti> seb128: if you manually add your default locale to /etc/locale.gen, it should work again, right?
[06:14] <dholbach> re
[06:15] <pitti> Hi dholbach 
[06:17] <seb128> pitti: probably, I can try if you want :)
[06:18] <pitti> seb128: however, it only affects perl applications
[06:18] <pitti> seb128: other apps just use C
[06:18] <seb128> which I don't want
[06:18] <pitti> seb128: but the locale should probably be available even if translations aren't
[06:18] <pitti> yeah
[06:18] <seb128> I've removed the language-pack to try some uptodate translations :p
[06:19] <pitti> seb128: this bug will be fixed as soon as jbailey uploads the new glibc
[06:19] <seb128> nice
[06:19] <pitti> seb128: i. e. then you can install debs with translations and they will be used
[06:20] <pitti> seb128: however, if I do dpkg-reconfigure locales after purging l-p-de-base, de_DE.UTF_8 gets regenerated...
[06:20] <seb128> bah, perhaps that's a local issue
[06:20] <seb128> removing or purging ?
[06:20] <seb128> does that make a difference ?
[06:21] <pitti> seb128: however, I just fix remove-language-locales to keep the default locale
[06:22] <seb128> nice, thanks
[06:34] <elmo> pitti: can you please seed the new language-pack?
[06:34] <elmo> err, if you haven't
[06:35] <pitti> elmo: oh, I didn't, thanks for notification
[06:35] <pitti> will do now
[06:35] <pitti> elmo: -rm, right?
[06:36] <elmo> yeah
[06:36] <elmo> fabbione: ?
[06:38] <pitti> elmo, Kamion: actually all the -base packages don't need to be in the seeds since the l-p-foo packages depend on them. Right?
[06:40] <pitti> elmo: seeded l-p-rm and l-support-rm
[06:42] <fabbione> elmo: ?
[06:43] <Kamion> pitti: correct
[06:45] <zyga> pitti: what's the rationale behind multiple .mo directories?
[06:45] <elmo> fabbione: is sparc buildd ok?
[06:45] <fabbione> elmo: yes, why?
[06:45] <pitti> zyga: 1) support /usr/local/share/locale
[06:46] <elmo> haven't seen an upload in 24 hours
[06:46] <pitti> zyga: (for ubuntu) 2) support /usr/share/locale-langpack/
[06:46] <elmo> and I kinda need workrave updated 
[06:46] <fabbione> elmo: ooo1.3 that was already out of ccache :( but thanks for pinging me :)
[06:46] <elmo> ok
[06:46] <zyga> pitti: and the newer one has precedense, right?
[06:46] <fabbione> it finished last hour.. next upload batch will start at 03 of the next hour...
[06:46] <pitti> zyga: right now, yes
[06:46] <fabbione> elmo: btw.. i got a timeout from ftpd recently...
[06:47] <elmo> fabbione: uh, really?
[06:47] <pitti> zyga: however, starting from breezy we don't need timestamp comparison any more
[06:47] <pitti> zyga: the first found one (in the path list) wins
[06:47] <zyga> pitti: I'm thinking about supporting multiple locations
[06:47] <elmo> I managed a 6 hour or so upload at 2k/s without timing out - are you sure it was the ftpd?
[06:47] <pitti> zyga: that'd be great :-)
[06:47] <fabbione> elmo: yes. i had almost no outgoing bw... and ftpd kicked me out uploading ooo :-)
[06:47] <fabbione> but there was traffic going
[06:47] <pitti> zyga: same like $PATH specs
[06:47] <zyga> pitti: and some config stuff like /etc/gettextrc $HOME/.gettextrc
[06:48] <pitti> zyga: /etc/gettextrc would rock :_)
[06:48] <fabbione> elmo: thanks a lot dude :-) i need to go again 
[06:48] <pitti> zyga: it could contain SEARCH_PATH=/usr/local/share/locale:/usr/share/locale:/usr/share/locale-langpack for Ubuntu
[06:48] <pitti> zyga: /usr/local/share/locale:/usr/share/locale should be the hardcoded default 
[06:49] <zyga> pitti: that could be in environment...
[06:49] <zyga> anyway that's easy as soon as I get .mo file support compleate
[06:49] <zyga> still want to add lazy transcoding 
[06:50] <zyga> (transcoding really suxx IMHO)
[06:52] <pitti> zyga: so environment beats ~/.gettextrc beats /etc/gettextrc beats hardcoded default?
[06:53] <jani> elmo ping
[06:54] <zyga> pitti: that's reasonable - but second priority
[06:54] <zyga> I'll still have a lot of work to do
[06:54] <pitti> zyga: I meant wrt <zyga> pitti: that could be in environment...
[06:55] <zyga> pitti: but I fully agree on that it's very good idea :)
[06:55] <salgado> hey guys, I wanted to build ion2 from hoary to warty, but it's telling me that I have to build it with fakeroot, even when I try to build it with fakeroot
[06:55] <zyga> I'm still puzzled about thread safty though...
[06:56] <pitti> zyga: you will do a lazy initialisation of file lookup? I. e. search the correct mo file for a locale when the first string is requested?
[06:56] <zyga> I need to see how glibc did it
[06:56] <zyga> pitti: didn't planned it but that's simple to add
[06:56] <pitti> zyga: and just use the found domain for subsequent gettext()'s for the same locale?
[06:56] <pitti> zyga: how you want to do it now?
[06:56] <zyga> pitti: I need lazy transcoding to correct encoding based on locale
[06:56] <seb128> Kamion: there is no "Select your keyboard" in the current installater or the string is not in the template ?
[06:57] <pitti> zyga: oh, I didn't know that this works :-)
[06:57] <jani> elmo could you please sync darcs 1.0.2 from debian (we have 1.0.1) now
[06:57] <pitti> oh sure, it has to
[06:57] <pitti> jani: MEEP, upstream version freeze. this requires mdz acknowledge first :-)
[06:57] <zyga> pitti: it's generally a hash table (by domain name) of hash tables (by msgid) of translated (lazily) messages :)
[06:57] <mdz> pitti: darcs is in universe, no?
[06:58] <jani> universe of ocurse
[06:58] <pitti> oh right, sorry
[06:58] <jani> :_
[06:58] <dholbach> yes, is universe
[06:58] <jani> :)
[06:58] <jani> It builds fine I tried it
[06:58] <pitti> zyga: don't you need domain -> locale -> msgid?
[06:59] <pitti> zyga: or locale -> domain -> msgid (dunno what is better)
[06:59] <zyga> well yes .. currently working with one locale chain
[06:59] <pitti> zyga: a program can call setlocale() several times with different locales
[06:59] <pitti> zyga: or do you just destroy your data structure in this case (probably makes sense)?
[07:00] <zyga> as I said I need to read glibc guts a little more to know about some stuff that's still missing in my head
[07:00] <zyga> pitti: I don't think you can destroy anything
[07:00] <pitti> zyga: oh, I just know the specification of it's interface :-) (a bit)
[07:00] <zyga> pitti: there is not a single word about when the translated message becomes invalid
[07:00] <zyga> to I must assume it never does :/
[07:01] <pitti> zyga: if the program calls setlocale() with a different locale, for example
[07:01] <zyga> pitti: do you mean that somewhere in the docs it says something like this
[07:01] <zyga> const char *foo = gettext ("foo");
[07:01] <zyga> setlocale (...);
[07:01] <zyga>  /* foo is no longer valid */
[07:01] <zyga> ?
[07:02] <pitti> zyga: well, if I do gettext("foo") in en_US, then change my locale to de_DE, gettext("foo") should return German
[07:05] <zyga> well yes
[07:05] <zyga> but if you store the result of first gettext
[07:05] <zyga> it should be still valid, right?
[07:06] <pitti> zyga: yes, of course, you can't change this :-)
[07:06] <Kamion> thom: ok, torrent tree nearly set up now; it'll contain at most one daily of each type ({Ubuntu,Kubuntu} {daily,daily-live,dvd}), one official release for each suite (e.g. Hoary preview), and one unofficial release for each suite (e.g. Array 7)
[07:06] <zyga> pitti: so that means - no destruction at all
[07:06] <pitti> zyga: oh right, gettext() returns a pointer to static memory
[07:06] <pitti> zyga: then I'd suggest domain -> msgid -> locale -> translation
[07:07] <Kamion> seb128: smurfix accidentally nuked templates.pot from the last upload; I put it back earlier today
[07:07] <Kamion> seb128: so it doesn't appear in the current installer-po/
[07:07] <seb128> hum; k
[07:07] <Kamion> seb128: should be restored tomorrow
[07:07] <seb128> nice, thanks
[07:08] <seb128> is there a string freeze for the installer ?
[07:08] <zyga> pitti: i think that locale should be higher
[07:08] <zyga> after all... you set your locale once
[07:08] <Kamion> seb128: no
[07:08] <zyga> eg... there is no gettext_for_locale stuff
[07:08] <zyga> so locale lookups could be avoided
[07:09] <Kamion> seb128: after tomorrow's installer-po/ arrives, I don't expect more than maybe half a dozen string changes at most, though
[07:09] <zyga> even if you change the locale later
[07:09] <pitti> zyga: as you wish, it probably doesn't affect the speed in any way
[07:09] <Kamion> seb128: upstream has been string-frozen for some time
[07:09] <zyga> you still got one global locale for all new messages
[07:09] <Kamion> I do have one netcfg change left to make that involves a string change
[07:10] <seb128> Kamion: all right. And I guess there is no way to know what strings are displayed in the standard installation ?
[07:11] <Kamion> seb128: unfortunately not, priorities are only in code so extracting them automatically is hard
[07:11] <Kamion> seb128: there's some attempt made to order the .pot by importance of udebs, but it may not be complete
[07:12] <pitti> jbailey: still here?
[07:12] <seb128> Kamion: k, I'll keep doing installation and to note things not translated so :)
[07:12] <pitti> jbailey: I fixed remove-language-locales for #8000, too. I put the script to http://people.ubuntu.com/~pitti/libc/ and updated the changelog
[07:13] <pitti> jbailey: can you please include this as well?
[07:15] <jbailey> pitti: Lagging, on the phone with my accountant.
[07:15] <jbailey> pitti: Sure.
[07:16] <Kamion> seb128: should basically just be Ubuntu additions
[07:16] <Kamion> seb128: don't bother with the untranslated country strings ("AD", "AE", etc.); there are translations for those in iso-codes, I just need to figure out how to suck them into choose-mirror automatically
[07:17] <seb128> yeah, I've skipped them
[07:17] <seb128> but there is a load of stuff non-translated
[07:17] <Kamion> yeah, I just looked through the list, it's indeed just Ubuntu additions
[07:17] <seb128> 963 translated messages, 2 fuzzy translations, 256 untranslated messages.
[07:18] <Kamion> seb128: the urgent stuff there is apt-setup, archive-copier, casper
[07:18] <seb128> how come than the stuff like the tz config have not translations, they are not ubuntu additions, are they ?
[07:18] <Kamion> what tz config stuff?
[07:19] <Kamion> msgid?
[07:19] <seb128> all the tzsetup.template stuff
[07:20] <Kamion> seb128: none of that shows up as untranslated here, and only one fuzzy string; are you sure you have the current version?
[07:20] <Kamion> cjwatson@rookery:~/public_html/installer-po$ msgfmt --statistics -o /dev/null fr.po
[07:20] <Kamion> 941 translated messages, 44 fuzzy translations, 236 untranslated messages.
[07:20] <seb128> arg
[07:20] <seb128> I've taken the fr.po yesterday, update around 50 strings
[07:21] <Kamion> a lot of the fuzzy stuff seems to be in base-config; perhaps a bad merge, not sure
[07:21] <Kamion> msgmerge?
[07:21] <seb128> noticed than the template is not complete
[07:21] <seb128> you have fixed it, and I've updated the po with today's template
[07:21] <seb128> without taking the fr.po update 
[07:21] <seb128> I'll try that, thanks
[07:22] <Kamion> thom: little:/srv/cdimage.no-name-yet.com/www/torrent
[07:25] <mdz> seb128: my panel crashed overnight again
[07:25] <mdz> seb128: has upstream looked at the backtrace?
[07:26] <seb128> no, Vincent is in .us for a conf for some days
[07:26] <seb128> (he's a .fr guy)
[07:27] <seb128> mdz: but seems to be specific to your configuration ... perhaps due to ~/.recently-used
[07:27] <seb128> maybe you can try to move that out of the way
[07:28] <mdz> I see nothing unusual there
[07:28] <mdz> I will move it
[07:28] <seb128> mdz: about #3159, the feature is the focus stealing prevention (which is basically most of the GNOME 2.10 work on it), and changing that is not an option
[07:29] <mdz> but we receive more bug reports about the new behaviour than the old
[07:29] <seb128> the solution is to fix gaim, but I don't know this code and upstream are not responsive
[07:30] <seb128> I know, but that's an upstream decision, I don't think we want to fork metacity 
[07:30] <mdz> seb128: is there someone we can bounty?
[07:30] <seb128> not sure, jdub will probably better knows that
[07:31] <mdz> jdub: ^^^ when you wake up
[07:38] <pitti> seb128: Adi Attar submitted the Xhosa po files to the Gnome translation project
[07:38] <pitti> seb128: how fast do these translations propagate into the upstream tarballs?
[07:39] <dholbach> pitti: they should be in next tarball release
[07:39] <dholbach> pitti: most translators have cvs accounts
[07:39] <pitti> dholbach: Adi certainly doesn't
[07:40] <dholbach> pitti: he can painlessly sign up for one
[07:40] <Kamion> (she)
[07:40] <dholbach> she... :-)
[07:40] <pitti> oh, sorry :-)
[07:41] <seb128> pitti: how ?
[07:41] <dholbach> http://developer.gnome.org/doc/policies/accounts/requesting.html
[07:42] <seb128> pitti: how did she submit them ?
[07:42] <pitti> seb128: "For the Gnome files, I have been submitting them to the Gnome
[07:42] <pitti> translation project."
[07:42] <pitti> seb128: however, I don't see Xhosa at http://l10n-status.gnome.org/HEAD/index.html
[07:43] <pitti> seb128: and I don't know where to get the files from
[07:43] <pitti> seb128: She asked me to pull the files from there, to put them into the language packs
[07:43] <seb128> pitti: Xhosa is on the GNOME CVS ?
[07:43] <pitti> seb128: not right now, as it seems
[07:43] <seb128> so nothing to do
[07:43] <pitti> seb128: I didn't find any trace of it
[07:43] <seb128> just wait
[07:43] <pitti> seb128: okay, I will ask her
[07:44] <schimmi> hi! how is a user supposed to login as root on fsck problems during boot? root has no valid password on normal Ubuntu box
[07:44] <dholbach> what is the iso code being used?
[07:44] <Kamion> dholbach: xh_ZA
[07:44] <pitti> dholbach: xh_ZA (Xhosa SOuth Africa)
[07:44] <dholbach> ok... thanks
[07:45] <Kamion> schimmi: fsck uses sulogin, which is special-cased for this situation
[07:45] <Kamion> schimmi: in the case where a root password isn't set, it will allow passwordless access
[07:45] <schimmi> I got the normal root login, but maybe that's because I had set it before
[07:45] <schimmi> just wondered...
[07:46] <Kamion> schimmi: we thought about this and noted that it wasn't a problem to do that, because if you were being presented with sulogin then you could always just reboot with init=/bin/sh
[07:46] <Kamion> schimmi: yes, if you have set your root password then we assume that you want to be asked for it :-)
[07:46] <elmo> Kamion: well, unless there's a password on the bios, grub and the machine's physically tied down
[07:46] <schimmi> Kamion, yes makes sense :) didn't expect that it just looks different with and without set root password
[07:47] <Kamion> elmo: indeed
[07:47] <Kamion> elmo: but then you generally wouldn't have got as far as sulogin in the first place
[07:47] <Kamion> unless somebody typed in the password and then walked off and left you with the machine - in which case, er, don't do that then
[07:47] <elmo> or the password only comes up when you try and do anything but the default?
[07:48] <Kamion> that would apply to a grub password, but I imagine not to a BIOS password - but yes
[07:48] <Kamion> in any case people locking down machines that way will generally set a root password, I suspect
[07:50] <elmo> yeah
[07:50] <Kamion> but we should probably document the sulogin thing better
[07:51] <elmo> like in the manpage ;)
[07:55] <Kamion> hah, yeah
[08:00] <dholbach> seb128: i'm trying to get gmime2 building again, but the bug is #299098, which seems to get resolved by gtk-doc from incoming, what do you think about it?
[08:08] <seb128> dholbach: need to fix gtk-doc-tools
[08:08] <dholbach> seb128: is gtk-doc from incoming what we'd probably want?
[08:10] <seb128> yep
[08:17] <elmo> hey, anyone know how:
[08:17] <elmo> shiri 19:17 ~ % grep -c de_DE.UTF-8 /etc/locale.gen
[08:17] <elmo> 65
[08:17] <elmo> that might have happened?
[08:18] <pitti> elmo: ugh
[08:18] <dholbach> elmo: not at all
[08:18] <pitti> elmo: how did you manage to get this?
[08:19] <elmo> pitti: that's my question dude :)
[08:19] <elmo> pitti: I'm fairly sure I didn't do it ;)
[08:19] <elmo> needless to say, it makes libc6 upgrades, err, fun
[08:19] <pitti> elmo: grep -c de_DE.UTF-8 /usr/share/i18n/SUPPORTED
[08:19] <elmo> 2
[08:20] <pitti> elmo: this should be 2
[08:20] <pitti> okay
[08:21] <pitti> elmo: can you please do sort -u /etc/locale.gen ?
[08:21] <pitti> elmo: I'm interested in the particular formatting
[08:21] <pitti> elmo: i. e. whitespace at line start, etc.
[08:22] <elmo> pitti: I copied it to http://people.ubuntu.com/~james/paste/locale.gen
[08:22] <elmo> but they seem identical
[08:23] <pitti> yeah
[08:23] <pitti> elmo: do you get one additional entry with every language pack update? or locales update?
[08:23] <elmo> it's worth noting de_UTF is the only non-UTFed locale I had in there
[08:24] <elmo> i.e. this looks like the "you will be UTF-8 suckah" script at wor
[08:24] <elmo> k
[08:24] <pitti> interesting
[08:24] <pitti> there are blocks of 2 - 4 - 8 - 16 - 32 entries
[08:24] <pitti> so it seems to double the number with every invocation of whatever
[08:25] <pitti> elmo: do you have l-p-de-base installed in the first place?
[08:25] <pitti> elmo: btw, what do yout mean with "de_UTF is the only non-UTFed locale"?
[08:25] <elmo> pitti: no l-p*
[08:25] <pitti> elmo: hmm, then this is not a install-language-locales bug
[08:26] <pitti> elmo: locales postinst maybe
[08:26] <elmo> pitti: I added all the locales _except_ de_DE-UTF8 eons ago when I was testing some locale related bug in gawk or gnupg
[08:26] <pitti> ah
[08:26] <elmo> pitti: and the locales I added all have both UTF8 and non-UTF8 variants, except de
[08:29] <elmo> pitti: when is install-language-locales called?
[08:29] <pitti> elmo: only in l-p-foo-base postinst currently
[08:29] <elmo> boggle.
[08:29] <pitti> I have an idea
[08:29] <pitti> /var/lib/dpkg/info/locales.config
[08:29] <pitti> # For each currently selected locale, try to select a corresponding UTF-8
[08:29] <pitti> # locale as well.
[08:29] <pitti> # TODO: We should check whether we've done this migration already. How? A
[08:29] <pitti> # version comparison is problematic due to merges among distributions.
[08:32] <pitti> elmo: can you please paste the value of debconf locales/locales_to_be_generated
[08:32] <Kamion> that code's been working for ages
[08:33] <pitti> Kamion: this UTF-8 migration, too?
[08:33] <Kamion> yes
[08:33] <Kamion> I mean I suppose it's possible, but I don't see why nobody else would have reported it in the three months since I added it
[08:33] <elmo> * locales/locales_to_be_generated: de_DE ISO-8859-1, de_DE@euro ISO-8859-15, en_GB ISO-8859-1, en_GB.ISO-8859-15 ISO-8859-15, en_GB.UTF-8 UTF-8, fr_FR ISO-8859-1, fr_FR.UTF-8 UTF-8, fr_FR.UTF-8@euro UTF-8, fr_FR@euro ISO-8859-15, ja_JP.EUC-JP EUC-JP, ja_JP.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.U
[08:34] <pitti> elmo: okay, it seems that we get closer
[08:34] <Kamion> boggle
[08:34] <pitti> Kamion: it would be interesting to see this loop after the comment in action
[08:35] <Kamion> I'd like to see a 'set -x' trace of locales.config in action
[08:37] <elmo> just running locales.config doesn't seem to do it
[08:37] <elmo> lemme try a dpkg-reconfigure with set -x in the script
[08:38] <Kamion> if anything I suspect dpkg-reconfigure will collapse it back down to one
[08:38] <elmo> hasn't, also hasn't made it any worse :(
[08:38] <Keito> Hi
[08:39] <elmo> maybe it's not worth digging too deeply in, if there haven't been any other reports of it
[08:39] <Kamion> elmo: seems worth investigating
[08:39] <elmo> ok, well - I'm currently generating 65 copies of the locale, any suggestions on what to try next?
[08:41] <pitti> elmo: running locales.config doesn't add anything to locales/locales_to_be_generated debconf value?
[08:41] <Kamion> cut some of the dups out of locale.gen (say down to 4), to save time, and try reinstalling a language pack?
[08:41] <pitti> Kamion: he didn't install a language pack ever
[08:41] <pitti> Kamion: so I doubt that this is a install-lanugage-locales thing
[08:41] <Kamion> oh
[08:41] <elmo> pitti: no, I don't have any installed now
[08:41] <elmo> I could have installed some, I just don't remember
[08:41] <elmo> and I don't have new supah powahed dpkg-with-logging yet
[08:41] <pitti> elmo: in this case you would have other locales, too
[08:42] <pitti> elmo: like de_AT
[08:42] <elmo> pitti: even after purging?
[08:42] <Kamion> elmo: try apt-get --reinstall install locales, see if that reproduces?
[08:42] <pitti> elmo: no, purging cleans it again
[08:42] <dholbach> elmo: could you please (later) sync  libhttpfetcher  from sid?
[08:43] <andred> When you change session language in gdm it doesn't change the language used in gdm itself. Shouldn't it do that? How else can a user easily completely switch language?
[08:43] <andred> Modifying /etc/environment doesn't even change gdm's language.
[08:44] <elmo> grep -c de_DE.UTF-8 /etc/locale.gen     
[08:44] <elmo> 129
[08:44] <elmo> whee!
[08:45] <elmo> but not set -x, 'cos it got wiped out by the reinstall, noo
[08:45] <elmo> s/noo/boo/
[08:48] <elmo> I'm still regenerating :>
[08:49] <ogra> hmm, thats a lot of german
[08:49] <Kamion> elmo: is there any other output? like "Automatically selecting $tryloc locale in addition to $oldloc."
[08:50] <Kamion> ohfuck, I guess outputting that to stdout isn't such a good plan
[08:50] <elmo> Kamion: nope, nothing
[08:50] <Kamion> elmo: try with DEBCONF_DEBUG=developer if you could; and definitely delete some of those duplicates first this time :)
[08:52] <mdz> at what point did the CC meeting time change?
[08:52] <zul> 2 weeks ago i think
[08:53] <pitti> Kamion: as a remedy, in locale-gen, could we replace
[08:53] <azeem> famous last words
[08:53] <azeem> ah :)
[08:54] <pitti> Kamion: bah, I was thrown out. Did you say anything after my "could we replace..:" question?
[08:54] <Kamion> 19:53 < pitti> Kamion: as a remedy, in locale-gen, could we replace
[08:54] <Kamion> that was the last thing I saw
[08:55] <pitti> Kamion: this sort -u would at least not generate locales multiple times
[08:55] <Kamion> pitti: but the existing code is not supposed to either (it checks)
[08:55] <Kamion> pitti: I don't like applying workarounds for bugs we don't understand
[08:55] <pitti> hmm
[08:56] <elmo> Kamion: http://people.ubuntu.com/~james/paste/typescript
[08:56] <pitti> Kamion: however, I just tried this, and de_DE.UTF-8 is generated twice for me, too
[08:57] <pitti> Kamion: that doesn't mean that the initial bug shouldn't be fixed, but avoiding multiple generation could be a good idea (independently of the debconf bug)
[08:58] <Kamion> pitti: sure, but I'd prefer to diagnose this first before it gets hidden
[08:59] <pitti> hmm, I can't reproduce this; the debconf list is cleaned up for me
[09:01] <pitti> Kamion: hah, with elmos debconf value I can reproduce it
[09:02] <Kamion> something is weird here, join is not doing what it's meant to do
[09:02] <pitti> Kamion: (I didn't use the broken last entry, that was probably a copy&paste bug)
[09:03] <Kamion> # grep de_DE.UTF-8 supported
[09:03] <Kamion> de_DE.UTF-8@euro UTF-8
[09:03] <Kamion> de_DE.UTF-8 UTF-8
[09:03] <Kamion> # echo de_DE.UTF-8 | join - supported
[09:03] <Kamion> #
[09:03] <elmo> kamion: I thought join worked on the wholel ine tho?
[09:03] <elmo> i.e. you're missing the trailing " UTF-8"?
[09:04] <Kamion> no
[09:04] <pitti> elmo: no, join uses the first field separated by space/tab
[09:04] <Kamion> but I think the file might not be sorted properly
[09:04] <elmo> oh, I'm getting confused with comm
[09:04] <Kamion> OH, FOR FUCK'S SAKE
[09:04] <Kamion> it works fine in LC_COLLATE=C :-P
[09:04] <pitti> LOL
[09:05] <Kamion> sometimes I really, really hate UTF-8
[09:05] <elmo> but, err, I'm in C, I think?
[09:05] <elmo> unless the defaults been changed?  I have no LANG or LC env vars set
[09:05] <Kamion> this is just why I couldn't get the auto-adding to work at all
[09:06] <Kamion> I haven't even got onto reproducing your bug yet :P
[09:06] <pitti> Kamion: use elmo's debconf value and do apt-get install --reinstall locales
[09:06] <Kamion> pitti: hold on, in the middle of stuff
[09:06] <zyga> Kamion: what is de_DE.UTF-*@euro ?
[09:06] <pitti> (no dpkg-reconfigure)
[09:06] <Kamion> zyga: breakage
[09:06] <zyga> ?
[09:06] <pitti> zyga: they don't exist
[09:06] <pitti> forget them :-)
[09:06] <Kamion> zyga: don't use them
[09:07] <zyga> Kamion: I see :-)
[09:07] <Kamion> pitti: you mean stick that into the debconf database, or write it into locale.gen; which?
[09:07] <pitti> Kamion: stick into debconf
[09:07] <pitti> Kamion: btw, why "join"?
[09:08] <pitti> Kamion: why not "grep -q" or so?
[09:08] <Kamion> pitti: more correct
[09:08] <Kamion> er, except when I screw up, but hey; I don't like grepping with user input as the regexp when I can avoid it, basically
[09:09] <pitti> Kamion: -F?
[09:09] <Kamion> pitti: doesn't let you use ^
[09:09] <pitti> Kamion: okay, that depends on whether you want to take the encoding into account or not
[09:09] <Kamion> pitti: I prefer join, mkay
[09:09] <Kamion> :)
[09:10] <pitti> sure, I just try to understand the reason :-)
[09:10] <elmo> pitti: leave him be, he's happy with his old skool tools that most people don't even know exist
[09:10] <elmo> ;P
[09:10] <Kamion> heh
[09:10] <pitti> elmo: I learned about join some months ago
[09:10] <pitti> elmo: I was impressed that all database operations can be done at the shell level :-)
[09:12] <Kamion> pitti: can't reproduce just by putting that in debconf
[09:12] <Kamion> which doesn't surprise me
[09:12] <pitti> Kamion: hmm, I can...
[09:12] <pitti> Value: de_DE ISO-8859-1, de_DE@euro ISO-8859-15, en_GB ISO-8859-1, en_GB.ISO-8859-15 ISO-8859-15, en_GB.UTF-8 UTF-8, fr_FR ISO-8859-1, fr_FR.UTF-8 UTF-8, fr_FR.UTF-8@euro UTF-8, fr_FR@euro ISO-8859-15, ja_JP.EUC-JP EUC-JP, ja_JP.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8, de_DE.UTF-8 UTF-8
[09:13] <pitti> Kamion: oh yes, I used elmos' original file, too
[09:13] <Kamion> ah, there we go
[09:16] <Kamion> ok, it's postinst breakage I think, working on it
[09:17] <Kamion> look at that suspicious uncommenting/commenting code
[09:18] <Kamion> pitti: do you have a glibc upload in progress? I'll send you a patch when I'm done
[09:18] <pitti> Kamion: I sent my stuff to jbailey
[09:18] <pitti> Kamion: he still has some things to fix
[09:18] <Kamion> ok
[09:18] <pitti> Kamion: so maybe just send it to him
[09:19] <jbailey> Kamion: There's still time.
[09:20] <zyga> why can't we just get rid of all ISO- EUC and KOR stuff?
[09:21] <zyga> it's not like they're here to stay
[09:21] <Kamion> zyga: deleting locales that users might be using is bad karma
[09:22] <Kamion> hence why we just generate UTF-8 equivalents
[09:22] <zyga> Kamion: hyhy
[09:22] <zyga> Kamion: UTF-8 incompatible file deletion tool ;-)
[09:22] <zyga> wipe-your-disk-wizard
[09:22] <Kamion> zyga: utf8-migration-tool :P
[09:23] <Kamion> pitti: aha; locales.postinst generates 1 + 2*(n-1) copies of each locale - so it's fine if n==1
[09:23] <zyga> Kamion: yeah.. but still my /etc/locale.alias has UTF-8 entries :/
[09:23] <Kamion> pitti: once you somehow end up with n>1 copies of any given locale, it will multiply without end
[09:25] <lamont_r> Kamion: base-mumble adds the user to /etc/aliases, but does not run newaliases...  I don't think postfix should automatically do it at startup, since the admin could have some other source for /etc/aliases.db than /etc/aliases... thoughts (#8067)
[09:25] <dholbach> thank you, elmo
[09:25] <Kamion> lamont_r: passwd.config is responsible for that; I don't have time to look at it just now but you're welcome to change as appropriate ...
[09:26] <lamont_r> ok.  is that post debootstrap?
[09:26] <Kamion> lamont_r: yeah
[09:26] <Kamion> lamont_r: pre-reboot though
[09:26] <lamont_r> that's fine - I just need newaliases to be != /bin/true. :-)
[09:27] <drspin> is the default hoary kernel bootsplash ready?
[09:27] <Kamion> drspin: no.
[09:27] <lamont_r> drspin: and it won't be kernel bootsplash, either... it'll be userspace bootsplash, and post-hoary
[09:28] <drspin> lamont_r: thanks for the tip - sorry to bug ;)
[09:28] <lamont_r> np
[09:29] <lamont_r> kernel bootsplash is too invasive, and breaks some hardware, etc, etc.
[09:29] <zul> lamont_r: i bet you have canned resposnes dont you
[09:29] <lamont_r> zul: nah, I just type fast
[09:29] <zul> lamont_r, sure sure
[09:30] <drspin> I've heard that before thanks for reinforcing :)
[09:31] <Kamion> elmo: ok, getting rid of the old dups is a bit complicated, but I've stopped them reproducing
[09:32] <lamont_r> hrm... why does 'acpi' print nothing on my laptop... wonder what we broke.
[09:33] <zul> lamont_r: not me for once 
[09:33] <lamont_r> zul:  it's been that way for a while..
[09:33] <zul> lamont_r: still i didnt do it :)
[09:33] <lamont_r> lol
[09:35] <drspin> I have a question - in Hoary on my dual celerons even with acpi=off in my kernel options I still get apic errors on both of my CPUS occassionally
[09:35] <lamont_r> drspin: you know that's really a #ubuntu question, right?
[09:36] <Kamion> elmo: *ah*, I see how it happened
[09:36] <Kamion> elmo: it generated one UTF-8 locale for de_DE ISO-8859-1, and another for de_DE@euro ISO-8859-15
[09:37] <lamont_r> Kamion: damn euros anyway.:-)
[09:38] <ogra> lamont_r, hey, we pay with them....
[09:38] <Kamion> easy fix
[09:38] <ogra> Kamion, pay with pound ?
[09:38] <drspin> lamont: the only response I always get is acpi=off -- no one ever mentioned that I should turn off APM in my bios because it's not SMP safe -- and even if I do what the need I still get the errors -- I've googled like crazy and always just get the ACPI=off solution which doesn't seem to work and I can't find any rhyme or reason to it
[09:39] <dholbach> hm, why didnt  openscenegraph  build on amd64, i mean... didnt even try to?
[09:39] <mdz> dholbach: it looks like it might need some porting, looking at the rules file
[09:40] <mdz> dholbach: it's probably failed in the past and been added to the exclusion list
[09:40] <mdz> lamont_r: can confirm
[09:41] <drspin> should I maybe take it to lkml for a solution?
[09:42] <mdz> drspin: try google first
[09:42] <Mitario> hey everyone
[09:43] <dholbach> mdz: hmmm, should build on amd64    ( * Patch to fix FTBFS on amd64 (closes: #286674)  )
[09:44] <lamont_r> drspin: the short answer is to look at http://people.ubuntu.com/~lamont/buildLogs/Lists/hoary.all.amd64
[09:44] <lamont_r> and see what that says...
[09:44] <dholbach> mdz: that's why i wanted mdz to sync it
[09:44] <dholbach> mdz: erm elmo :-)
[09:45] <mdz> dholbach: the buildds have a list which excludes packages known not to build on certain architectures, in order to avoid wasting time on them.  this needs to be updated when this type of problem is fixed
[09:46] <Kamion> jbailey: jbailey@ubuntu.com?
[09:46] <dholbach> mdz: ok thanks, i see
[09:47] <jbailey> Kamion: Please.
[09:51] <Kamion> jbailey: sent
[09:52] <drspin> lamont_r: "short answer" LOL
[09:52] <drspin> thanks I'll google a bit more
[09:53] <Kamion> drspin: I think lamont_r mentioned that to you by accident, rather than to dholbach
[09:53] <lamont_r> drspin: er, sorry.  that was really aimed at dholbach 
[09:53] <drspin> heh - LOL
[09:53] <drspin> no worries - I thought it was rather funny
[09:53] <dholbach> lamont_r: thanks, i'll have a look
[09:55] <lamont_r> dholbach: if it says it's depwaited on something in error, holler...
[09:56] <Kamion> jbailey: the sort -u when initialising SELECTED_LOCALES probably applies to Debian too; and in fact it turns out to be an alternative way to fix #271526
[09:56] <dholbach> lamont_r: it says: Dep-Wait by buildd+king [optional:uncompiled]   Dependencies: giflib-dev            - which is provided by giflib3g-dev
[09:56] <jbailey> Kamion: Thanks for that.
[09:57] <dholbach> lamont_r: the other buildds resolved that, hmmmm
[09:57] <Kamion> jbailey: (Denis' patch looks valid too, and there's probably no reason not to apply both :-))
[09:58] <dholbach> hey mvo
[09:58] <mvo> hey dholbach 
[09:59] <ogra> hi mvo 
[09:59] <mvo> hi ogra 
[10:07] <LeeJunFan> anyone else see us.archive.ubuntu.com (216.165.129.138) as being down?
[10:08] <dredg> it pings
[10:08] <LeeJunFan> no http
[10:08] <dredg> that's different to it being down
[10:09] <LeeJunFan> which screws apt.
[10:09] <LeeJunFan> ok - so http on it is down.
[10:09] <Kamion> yeah, seems so from here too
[10:09] <LeeJunFan> if it doesn't work - it's down :)
[10:10] <dholbach> what does   [Category: none]     not ours     in   http://people.ubuntu.com/~lamont/buildLogs/Lists/hoary.all.amd64    mean?   (sdl-stretch)
[10:10] <LeeJunFan> ftp is working on it.
[10:11] <lamont_r> dholbach: 'amd64 not in arch list ....
[10:11] <lamont_r> debian/control needs an edit to include amd64 where appropriate.
[10:11] <mdz> it's answering, it's just very slow
[10:11] <dholbach> lamont_r: ok, good
[10:11] <mdz> lamont_r: debian/control is Arch: any
[10:14] <lamont_r> mdz: ??
[10:15] <mdz> mizar:[/tmp]  zcat openscenegraph_0.9.8-2.diff.gz| filterdiff -i '*/debian/control' | grep Architecture| sort -u
[10:15] <mdz> +Architecture: all
[10:15] <mdz> +Architecture: any
[10:15] <lamont_r> mdz: sdl-stretch
[10:15] <mdz> oh
[10:15] <lamont_r> ok.
[10:16] <lamont_r> 'not ours' is _ALWAYS_ 'arch not in arch list', and since we auto try faileds (but not d-w's) on upload, it's self clearing.
[10:16] <lamont_r> hrm.. filterdiff
[10:16] <lamont_r> cool
[10:16] <dholbach> lamont_r, mdz: sorry for asking two questions at once
[10:16] <lamont_r> Architecture: i386
[10:17] <lamont_r> dholbach: that's not to say that it _should_ be i386-only...
[10:17] <lamont_r> i386 assembly, I guess that's ok...
[10:17] <lamont_r> but if it builds on amd64, that's easy to fix.
[10:18] <seb128> pitti: around ?
[10:18] <lamont_r> and it's just !m68k in PaS, so you're good there too
[10:18] <pitti> seb128: yes
[10:18] <seb128> pitti: new ping about https://bugzilla.ubuntu.com/show_bug.cgi?id=7725 
[10:18] <seb128> pitti: if you know about this file
[10:19] <pitti> seb128: uh, no clue
[10:20] <seb128> pitti: but /usr/share/gnome-volume-manager/gnome-volume-manager-gthumb.sh is a warty thing ?
[10:20] <seb128> if not just close it as NOTWARTY
[10:21] <pitti> seb128: this actually might be a regression in Hoary
[10:21] <seb128> k
[10:21] <pitti> seb128: I deliberately moved this script into /usr/share/g-v-m
[10:21] <pitti> seb128: probably it got dropped in a sync
[10:21] <Kamion> mdz: is casper 0.56 not in arch yet?
[10:22] <seb128> hum
[10:22] <Kamion> mdz: the changelog in casper--main--0 doesn't seem to match up
[10:22] <lamont_r> but I don't _want_ to make a custom install CD... </whine>
[10:23] <zyga> seb128: it had them for a while now
[10:28] <Kamion> mdz: please merge colin.watson@canonical.com--2005/casper--translations--0 up to patch-2 (http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005)
[10:29] <zyga> Kamion: ah, you arch pepole :)
[10:31] <thom> Kamion: rocking, thanks
[10:31] <mdke> jdub, ping
[10:50] <mdz> Kamion: my mirror isn't up-to-date
[10:50] <mdz> Kamion: updating it now
[10:52] <mdz> ...and merged
[10:57] <Kamion> mdz: ta
[10:57] <Kamion> though still doesn't show as up-to-date
[10:58] <mdz> I bet you're looking at the old chinstrap mirror
[10:58] <mdz> I'm publishing to people.u.c now
[10:58] <mdz> hmm, no, I removed the chinstrap one when I moved it
[10:58] <mdz> ** adding revision casper--main--0--patch-8
[10:58] <mdz> do you not see patch-8?
[10:59] <mdz> community council meeting -> #ubuntu-meeting
[11:00] <Kamion> $ baz archives matt
[11:00] <Kamion> matt.zimmerman@canonical.com--2004
[11:00] <Kamion>     http://people.ubuntu.com/~mdz/archives/matt.zimmerman@canonical.com--2004
[11:00] <Kamion> mdz: I'm using that
[11:00] <mdz> that's correct
[11:00] <mdz> and that should have patch-8
[11:00] <Kamion> hmm, something is odd
[11:01] <mdz> mdz@rookery:~/public_html/archives/matt.zimmerman@canonical.com--2004/casper--main--0 $ ls -ld patch-8
[11:01] <mdz> drwxr-xr-x    3 mdz      warthogs     4096 Mar 22 21:53 patch-8
[11:01] <pitti> doko: OO.o is certainly a lot more difficult?
[11:02] <doko> :-(
[11:04] <Kamion> mdz: oh, heh. You know what lifeless said earlier about proxy issues?
[11:05] <mdz> ick, why does that break?
[11:05] <Kamion> mdz: I think that could do with a more descriptive changelog though ...
[11:06] <Kamion> mdz: the cache's copy of .listing only went up to patch-4
[11:06] <mdz> Kamion: I'll fix it when I actually go back and see what it is you changed ;-)
[11:06] <Kamion> hah
[11:06] <mdz> one of these days one of us needs to write a tool for this
[11:06] <Kamion> 'baz changelog' says
[11:06] <mdz> to manage patch-logs vs. changelogs
[11:06] <mdz> patch-logs vs. debian/changelog I mean
[11:07] <mdz> ideally I would be able to merge changelog entries along with your changes
[11:07] <mdz> but creating new versions in different branches is a big mess
[11:07] <mdz> and merging changelogs in general
[11:07] <Kamion> yeah, currently I'm avoiding creating debian/changelog entries for that exact reason
[11:07] <Kamion> even for my own packages, I create them only when doing a new release
[11:08] <Kamion> but that sucks for other reasons, it's more awkward to build test versions
[11:09] <mdz> yeah
[11:09] <Kamion> pitti: took a few hours to do the installer support, too
[11:09] <Kamion> although it got quicker as I went through
[11:09] <mdz> what I've started doing (when I think of it) is to put in a changeset which does nothing but open a new version in changelog
[11:09] <mdz> and then commit changelog entries along with the changes
[11:09] <pitti> Kamion: yeah, I didn't have to upload half of the world for it :-)
[11:09] <mdz> this is something to be addressed with the next rev of the source package format
[11:10] <Kamion> sounds more like a special hct merge op, to me ...
[11:10] <Kamion> I mean upstreams that keep ChangeLog files have the same problem
[11:10] <mdz> the existing changelog format is not very suitable
[11:11] <mdz> ChangeLog is easier in this respect
[11:32] <mdz> thom: iirc, the maintainer script and/or a script it calls does that ON PURPOSE
[11:32] <mdz> oh, it uses mktemp -d now
[11:32] <mdz> and sets home to that
[11:33] <thom> hrrrm
[11:33] <thom> mdz: thanks, i'd forgotten about that
[11:33] <thom> mdz: that seems to be part of the cause of 7711
[11:33] <mdz> /usr/lib/mozilla-firefox/firefox is a nightmare of HOME madness
[11:35] <thom> yeah; none looks to be setting HOME to something whacky unless you're running under sudo, tho
[11:35] <mdz> it's the chrome update script which does the mktemp madness
[11:39] <Amaranth> woohoo, pyxdg patched upstream
[11:41] <lamont> Kamion: could you kick hoary_outdate.txt to current for me?
[11:43] <Kamion> lamont: done as best I can (can only kick the mirror)
[11:44] <dholbach> lamont: openscenegraph built fine on amd64, what do i have to do to make it build on the buildd too?   (Dep-Wait by buildd+king [optional:uncompiled]   Dependencies: giflib-dev)
[11:44] <pitti> infinity: here?
[11:46] <mdz> lamont: giflib-dev is provided by giflib3g-dev and libungif4-dev, both of which are built on amd64
[11:46] <dholbach> and the other buildds have no hassle at all
[11:46] <elmo> yes, but it's a virtual
[11:46] <elmo> w-b doesn't understand virtuals
[11:46] <elmo> a simple give-back will fix
[11:47] <elmo> I suspect the dep-wait pre-dates lamont's auto-depwaiter, or maybe the ordering of the building was just unfortunate on amd64
[11:49] <elmo> who uploaded pinfo?
[11:51] <dholbach> elmo: me
[11:52] <dholbach> sponsored the upload to a wannabe-motu
[11:52] <elmo> dholbach: please remember to either fix the Changed-By: field or ask me to whitelist the email address
[11:52] <elmo> (the latter is almost no work for me, and preferable in the long run)
[11:52] <dholbach> elmo: just ask you and state the mail adress?
[11:53] <elmo> dholbach: yah
[11:53] <Kamion> latter definitely preferable so that the changed-by: field is there for future MOTU approvals and such
[11:53] <dholbach> elmo: no signed mails by them to upload@ubuntulinux.org
[11:53] <dholbach> Kamion: i totally agree
[11:53] <elmo> dholbach: nah, it's just an email whitelist, doesn't give them any privs
[11:53] <dholbach> elmo: alright, will do
[11:53] <dholbach> elmo: and pass the word :-)
[11:54] <zenwhen> hey Amaranth 
[11:55] <elmo> pitttttttttttttti
[11:55] <mdz> elmo: can you give-back openscenegraph, if you haven't already?
[11:55] <pitti> ellllllllllllmo?
[11:55] <elmo> mdz: done
[11:55] <elmo> pitti: got some more security reviews for you, sorry dude
[11:56] <mdz> thanks
[11:56] <pitti> darn, I wasn't fast enough, just wanted to go to sleep :)
[11:56] <pitti> elmo: which ones?
[11:56] <pitti> elmo: ... and would tomorrow (i. e. now + 9 hours) be enough?
[11:57] <elmo> pitti: sure
[11:57] <elmo> I'll mail you
[11:57] <elmo> go sleep
[11:57] <pitti> okay, fine
[11:57] <pitti> night everybody!