[12:10] <sedak> is there a irc channel for the gnome project ??
[12:12] <kent> sedak, #gnome?  (perhaps on some other server though..)
[12:13] <sedak> thank you !
[12:13] <sedak> i'll try this one
[12:13] <mdke> sedak, irc.gnome.org should do it
[12:13] <sedak> ok
[12:13] <sedak> seems more appropriate then
[12:14] <sedak> thanks
[12:31] <jbailey> slomo: I haven't.  I want to prove that first.
[12:31] <jbailey> Like, I want to prove that it's likely exactly that.
[12:50] <mdz> mvo: so it looks like we need to solve this console font problem sooner rather than later
[12:51] <mvo> mdz: yes, #15102 is a serious issue :/
[12:56] <dholbach> good night everybody
[12:57] <tseng> bye dholbach 
[12:57] <mdz> mvo: please make it your first priority tomorrow
[12:57] <mvo> mdz: ok
[12:59] <tseng> good night germany
[02:26] <Burglaptop> BenC, on linux-source, the maintainer and changed by are two different @ubuntu.com for you
[02:27] <Keybuk> meh
[02:28] <Keybuk> I really hate it when you investigate why something doesn't work, and realise it doesn't work because there's nothing to _make_ it work
[02:28] <Keybuk> so, the reason permission changes aren't made to scanner devices (etc. etc.) on boot is because at the point that happens, the filesystem is still mounted readonly
[02:30] <Keybuk> in fact, I'm wondering whether in a couple of these cases, the device is made in the initramfs so the real filesystem isn't even around yet <g>
[02:32] <mjg59> Uh.
[02:32] <mjg59> The /dev from the initramfs is the same one that we use once / is mounted
[02:32] <mjg59> And it always ought to be a tmpfs
[02:34] <Keybuk> yes, but this script is trying to change the permission of something not-under-/dev
[02:34] <Keybuk> and I don't think this script is even _on_ the initramfs
[02:34] <mjg59> Oh
[02:34] <Keybuk> so we have the situation where /etc/hotplug.d/* is being run by udev once the rules are done
[02:35] <Keybuk> if that happens at S04, those scripts can't modify anything other than /dev (which is entirely sane)
[02:35] <mjg59> Yeah
[02:35] <mjg59> So, uh, what is it trying to alter?
[02:35] <Keybuk> but if the device gets loaded in the initramfs, those scripts don't happen at all
[02:36] <Keybuk> something under /proc
[02:41] <mjg59> But /proc isn't part of /
[02:41] <mjg59> It's never read-only
[02:41] <Keybuk> yeah, I'm still trying to work this out
[02:41] <Keybuk> so far I can't find the .ko that matches any scanner
[02:48] <Keybuk> actually, I don't understand this at all ... from what I can tell, every single device plugged in should end up root.plugdev because of the libgphoto2.hotplug script
[02:49] <Keybuk> or, at least, every single usb device
[02:53] <Keybuk> aha!  thankfully that doesn't happen because it uses an environment variable that doesn't exist anymore, heh
[02:55] <Keybuk> giggle
[02:55] <Keybuk> no, it really does
[02:55] <Keybuk> syndicate scott% ls -l /proc/bus/usb/001/004
[02:55] <Keybuk> -rw-rw----  1 root plugdev 52 2005-09-27 01:55 /proc/bus/usb/001/004
[02:55] <Keybuk> Bus 001 Device 004: ID 045e:001e Microsoft Corp. IntelliMouse Explorer
[03:10] <Keybuk> heh
[03:11] <elmo> would it be stupid to ask why we go to so much effort to hotplug a mouse when we could just build it in?
[03:12] <Keybuk> we do pretty much
[03:12] <Keybuk> I was just using a mouse there as an example for "something that's usb, but not a scanner"
[03:12] <Keybuk> uh, camera
[03:13] <Keybuk> I've had "why the fuck isn't this compiled in?" arguments before for many things
[03:13] <Keybuk> why is the AF_UNIX/AF_LOCAL network protocol a module?
[03:13] <mjg59> I get a fixed hotkey-setup into the archive, and then everyone bitches that X doesn't work properly
[03:13] <mjg59> I mean, ungk.
[03:14] <Keybuk> heh, do you like laptop-detect bugs mjg59 ?
[03:16] <mjg59> Is this a trick question?
[03:16] <mjg59> Can you ask him for dmidecode information?
[03:27] <Keybuk> probably
[03:27] <Keybuk> will wait until he replies to say laptop-detect say "nah"
[04:45] <fabbione> morning guys
[04:46] <bddebian> Morning fabbione 
[04:46] <fabbione> yo
[04:49] <blahrus> I assume gst is going to be fixed next time around .9?? audio/video sync issues I mean
[04:56] <Amaranth> we have a dirty secret?
[04:56] <Amaranth> "Whether on Distrowatch or on forums, voices whisper that Ubuntu has a dirty secret you may not want to hear: they don't keep the compatibility with Debian, and they want to fork away from their mother distribution."
[04:56] <ajmitch> Amaranth: sure, and the sky is falling at noon
[04:56] <Amaranth> cool
[04:56] <calc> Amaranth: hahahaha
[04:57] <Amaranth> should i wear sunglasses for that?
[04:57] <calc> Amaranth: who is the retard that wrote that
[04:57] <Amaranth> http://www.libervis.com/modules/smartsection/item.php?itemid=28
[04:57] <jsgotangco> lol
[04:57] <calc> as someone pointed out with DCC the second you make one change you have forked
[04:58] <jsgotangco> linspire didn't fork?
[04:58] <calc> so the only way ubuntu would not be forked is if it changed nothing at all (ie just be a mirror)
[04:58] <Burglaptop> Amaranth, see the response by Mark to sounder
[04:58] <Amaranth> i don't read sounder, can you link me?
[04:59] <azeem> http://lists.ubuntu.com/archives/sounder/attachments/20050926/59b358e2/faq-0001.html
[04:59] <jsgotangco> it would be nice if sabdfl would have that posted on the homepage
[05:01] <blahrus> should check out Mark Shuttleworth's speach at debconf, think you might understand his goals and passions a bit more
[05:01] <blahrus> and forking is ok ;)
[05:02] <Amaranth> It's a spoon!
[05:02] <Amaranth> jsgotangco: That would just show the article to people that haven't seen it and make it a bigger issue.
[05:02] <Amaranth> jsgotangco: It's like how coca-cola was beating pepsi until they started talking about pepsi.
[05:03] <jsgotangco> there is no spoon...
[05:03] <jsgotangco> heh
[05:04] <ajmitch> hm, interesting sounder post there
[05:08] <jbailey> I think it's funny that people say we want to fork away.  That just means more work.  Why would we do that? =)
[05:09] <ajmitch> you're right, we're lazy :)
[05:11] <bddebian> heh
[05:28] <poningru> its a spoon
[05:28] <poningru> no need for a knife
[05:28] <poningru> or a fork
[05:33] <Amaranth> it's a spork!
[05:38] <Rotund> anyone know if there's a decent gnome Zeroconf configurator?  If not, I'm thinking of writing one.
[05:38] <Burglaptop> Rotund, talk to Lathiat 
[05:38] <Rotund> he seems away
[05:39] <Rotund> Is he the resident Zeroconf guy or is he working on one?
[05:39] <Burglaptop> Rotund, he is one of the upstreams for Avahi, the freedesktop implementation of zeroconf
[05:39] <ajmitch> Rotund: he's the resident zeroconf guy
[05:39] <Rotund> yeah.  that's what I was gonna base it on
[05:40] <ajmitch> what sort of configuration were you thinking of?
[05:40] <Rotund> I haven't found one, but I wouldn't think it would be too difficult
[05:40] <Burglaptop> Rotund, there has also been some discussion on the desktop-devel list of gnome
[05:40] <Rotund> setting up the services your computer is sending
[05:40] <ajmitch> right
[05:40] <ajmitch> so configuring avahi-daemon's services
[05:40] <Rotund> right
[05:40] <ajmitch> you  may want to visit #avahi when people are around
[05:40] <Rotund> perferably have it "guess" ones by portscanning yourself
[05:41] <Rotund> preferably that is
[05:42] <ajmitch> #avahi looks fairly quiet at the moment :)
[05:44] <Rotund> yes it does
[05:44] <Rotund> I'm sure someone can tell me how to tell what ports are opened on your own computer via the kernel, right?
[05:45] <Rotund> or a command-line tool
[05:45] <rob^> nmap
[05:46] <Rotund> hmmm.  There should be a way to do it w/o portscanning
[05:46] <rob^> or just go to grc.com or others
[05:46] <infinity> bddebian : Bayonne is FTBFS on amd64 and ia64, which isn't surprising, since it seems to fail on almost every Debian arch at buildd.debian.org, except for powerpc.
[05:46] <bddebian> infinity: OK, thx
[06:17] <fabbione> mdz: ping?
[06:25] <jkrogh> Is it a reportable bug, when the network don't work after hibernation? 
[06:26] <HrdwrBoB> I just hibernated and came back and my network wasn't setup
[06:28] <fabbione> pkg: acpi-support iirc
[06:35] <mdz> fabbione: pong
[06:35] <fabbione> mdz: any objections if i upload a xorg with sparc only changes?
[06:36] <fabbione> (it's one liner to fix xserver-xorg Depends: on sparc)
[06:36] <fabbione> no code changes of any kind
[06:36] <mdz> fabbione: I would prefer that you fix some non-sparc bugs at the same time, actually
[06:36] <fabbione> mdz: my sparc work is outside working hours.. so i have to follow the rules of a MOTU and such
[06:36] <mdz> I know it is your favorite package ;-)
[06:37] <fabbione> mdz: i have no idea if daniels has other stuff in queue.. i did mail him, but got no answer
[06:37] <fabbione> mdz: yeah right.. and i am santa claus :P
[06:37] <mdz> ho ho ho
[06:38] <fabbione> ARGH! my clothes are turning red!
[06:38] <infinity> mdz : I need an opinion on #14991
[06:38] <infinity> mdz : (apache2 security update broke svn+ssl+clientcerts)
[06:39] <infinity> mdz : The reason it broke is because the users were (unintentionally) relying on the very bug we fixed.  The "feature" they were using was one that apache never actually had.
[06:39] <mdz> does it affect ubuntu?
[06:39] <infinity> mdz : Yes, it affects us, including the security updates we did for Warty and Hoary.
[06:39] <jkrogh> Is it possible to get the debuggin-output(stdout/err) from an applet? (The network-monitor reports disconnected, but the network works fine) 
[06:40] <mdz> infinity: what's the one-line summary of the breakage?
[06:40] <infinity> mdz : Now, I have a patch to add that feature (thus fixing the regression), which I will upload to breezy.  But should we care about the regression in warty/hoary, or just leave it as-sis?
[06:40] <infinity> mdz : Having a mixed read-only/read-write SVN repo that uses SSL client certs for authentication used to work, no longer does.
[06:41] <mdz> infinity: can I see the patch?
[06:42] <infinity> http://cerberus.0c3.net/~adconrad/047_verify_client_fix
[06:43] <infinity> It's a no-brainer for includion in breezy, as we DID break something people have relied on for ages, but I want an opinion on if you feel something that large is worth inclusion in hoary, or if we just leave it.
[06:44] <infinity> mdz : Basically, requests with bodies have never been able to trigger an SSL renegotiation, but that precise feature is required to allow mised read-only/read-write SVN (and several other use-cases, like a <Location> that requires SSL auth for POST, etc).
[06:45] <infinity> mdz : It stopped working when we noticed the bug where <VirtualHost>SSLClientVerify Optional <Location>SSLClientVerify required </Location></VirtualHost> didn't actually work, and the renegotiatoin wasn't being forced.  Oops.
[06:45] <infinity> So, fix that, and the bug people relied on for ages suddenly goes away and turns intoa feature request. :)
[06:46] <ajmitch> hm, why does the (recently synced) libpt-dev have /usr/lib/libpt.so.1.8 symlink? I thought that usually goes in the lib package itself?
[06:46] <infinity> ajmitch : because someone screwed up?
[06:47] <ajmitch> infinity: probably, and it affects upgrades from the earlier version :)
[06:47] <mdz> infinity: has anyone else rolled it into a security update yet?
[06:47] <mdz> any real-world production environment feedback on the patch?
[06:47] <infinity> mdz : Not sure, I'll poke Joe at RedHat and see if they've fixed the regression.
[06:47] <mdz> brb
[06:47] <mdz> irqpoll strikes again
[06:48] <infinity> mdz : The bug submitter has tested it for me, as well as several people on the apache lists (and a mess of people who've reported the bug in the apache BTS)
[06:49] <fabbione> GO FIREFOX!
[06:50] <fabbione> hoary -> breezy update is no go
[06:55] <mae> y'know, banshee looks fairly promising for the next ubuntu release if they fix some _very_ annoying bugs.
[07:01] <infinity> mdz : The bug submitter has tested it for me, as well as several people on the apache lists (and a mess of people who've reported the bug in the apache BTS).  It's also been rolled into apache trunk and apache 2.2 (waiting on enough votes for inclusion to 2.0 still)
[07:03] <infinity> mdz : TBH, I'm not picky about if we include it in warty/hoary (as no one's reported it in Ubuntu, only in Debian and other dists), and breezy is just around the corner, so in a few weeks, I can tell people who encounter the bug that "it's fixed in breezy"... Just wanted to get your take on it, if perhaps you think it's worth fixing in warty/hoary.
[07:04] <fabbione> morning sabdfl 
[07:04] <mdz> infinity: hmm
[07:04] <sabdfl> moin moin
[07:05] <ajmitch> hi sabdfl 
[07:05] <mdz> infinity: I'm inclined to agree; let's leave it for a bit and see if anyone screams
[07:05] <mdz> the breezy release gives us a good opportunity to offer users a choice of stability or the fix
[07:06] <infinity> mdz : Alright.  I will fix it in breezy today.  I'm inclined to believe that the intersection of "people running hoary servers" and "people using this apache config" must be pretty close to zero, or we'd have a bug report or two by now.
[07:07] <infinity> (It's not the sort of bug you can ignore or work around, so people who have complained)
[07:07] <infinity> s/who have/would have/
[07:08] <infinity> (Note that I've had several "me too"s on the Debian bug, and there is a large group of people whining about it upstream)
[07:10] <infinity> ingi2Gee

[07:11] <mdz> infinity: it's OK it showed up as ******* ;-)
[07:11] <infinity> Oh, handy!
[07:11] <infinity> :)
[07:12] <pitti> Good morning
[07:12] <desrt> word up, pitti
[07:12] <fabbione> hey pitti
[07:12] <fabbione> mdz: lol
[07:14] <Mithrandir> mdz: what's a sane way to handle bugs such as 16402 which are "this will bite us later"?  I'm reluctant of closing it, but it would be nice if it didn't show up in the bug lists..
[07:14] <fabbione> Diziet: your last firefox upload breaks hoary -> breezy upgrades
[07:15] <mdz> Mithrandir: the only truly sane way is to keep it open
[07:15] <mdz> Mithrandir: but you could resolve it REMIND and then set an at job to remind you to reopen it ;-)
[07:16] <Mithrandir> mdz: could we reopen all bug reports resolved LATER or REMIND after breezy releases?  That could work and would make the state sane
[07:16] <Mithrandir> or useful, or whatever
[07:20] <infinity> This is what milestones are for...
[07:20] <pitti> infinity: ah, the CAN is there, I forward it to the Debian bug
[07:21] <infinity> pitti : Excellent.  Cheers.
[07:23] <henriquemaia> hello, I have just upgraded to breezy and now my keyboard (pt) is not working right. Does anyone knows how to solve this? (a bug, maybe?)
[07:23] <mdz> Mithrandir: you can drop the priority if you like
[07:24] <mdz> Mithrandir: probably best to just keep it open; Debian will hopefully fix it soon, and we can NOTWARTY it then
[07:24] <Mithrandir> mdz: mhm, I guess so
[07:39] <infinity> mdz : Did Kamion get a chance to discuss lrm and d-i with you?
[07:53] <fabbione> hmmmmm
[07:54] <\sh> morning
[07:56] <\sh> infinity: ping I just saw your upload of libetpan, why did it compile without complains in my pbuilder then? (looking at gnutls build dep)
[07:57] <infinity> \sh : Because your pbuilder chose a different libgnutls-dev alternative than sbuild did.
[07:57] <infinity> \sh : Starting the gnutls12 (which we don't have), libgnutls-dev has become a real package, rather than a virtual, hence why it works in Debian.
[07:57] <infinity> s/the gnutls12/with gnutls12/
[07:58] <\sh> infinity: but I don't have any debian repos in it so it uses only our breezy archives
[08:00] <fabbione> mdz: do you actually export XORG_SYNC_RANGES inside casper?
[08:00] <infinity> \sh : Yes, and?
[08:00] <mdz> fabbione: no
[08:00] <infinity> \sh : We have three packages in breezy that prodive the virtual package "libgnutls-dev"... Only one of them (libgnutls11-dev) will actually work to build that package.
[08:01] <infinity> \sh : sbuild picks libgnutls7-dev.
[08:01] <infinity> \sh : Obviously, pbuilder picked 11-dev for you.
[08:01] <\sh> infinity: ok..so pbuilder pulls in somehow (and this is somehow a bit strange) libgnutls11-dev 
[08:02] <\sh> remind me to use sbuild for dapper as build env ,)
[08:03] <bob2> isn't a virtual-only build-dep a bad idea anyway?
[08:04] <\sh> infinity: thx btw for the upload...and now time go prepare for real life work *yawn*
[08:05] <\sh> bbl
[08:06] <infinity> bob2 : "real | virtual
[08:06] <infinity> Err.
[08:07] <infinity> bob2 : "real | virtual" is the nice way to go, if you want to guanratee a certain real package for buildd builds, but still allow backports easily.
[08:07] <infinity> bob2 : That package had a pure virtual build-dep because in Debian, it's not a virtual anymore.
[08:07] <bob2> ahh
[08:27] <fabbione> who has a ppc here that can reproduce #16035 ?
[08:36] <sabdfl> mjg59: ping
[08:36] <sivang> morning all
[08:37] <fabbione> mdz: i am checking some of the xorg bug, but i have the feeling that the issue is xresprobe
[08:37] <fabbione> mdz: specially comparing the bare differences between generated configs
[08:37] <fabbione> (same with 16035)
[08:37] <fabbione> the problem is i don't have a ppc to test on...
[08:39] <infinity> pitti : I still don't have that mail you forwarded to the BTS.  Can you just give me the CAN here, while I'm working on the packages? :)
[08:41] <sabdfl> ah, i see some xubuntu action coming in
[08:41] <sabdfl> good work guys
[08:42] <infinity> xubuntu == xfce?
[08:42] <fabbione> infinity: yeah
[08:44] <sabdfl> infinity: lots of demand for it in the lightweight desktop community
[08:44] <sabdfl> so thans for the effort
[08:44] <infinity> Cool.  I hsould give it a spin sometime.
[08:44] <Treenaks> sabdfl: does this also mean easy mixing (eduxubuntu?)
[08:44] <infinity> I've not used anything on my laptop except for a very default ubuntu setup.
[08:44] <bob2> haha
[08:45] <infinity> keduxubuntu may be inunstallable due to unavoidable conflicts.  Someone should try. :)
[08:45] <sabdfl> Treenaks: for some definition of easy, yes
[08:45] <infinity> uninstallable, too.
[08:45] <sivang> sabdfl: lol :)
[08:45] <sabdfl> we won't publish all permutations and combinations as officially supported
[08:45] <Treenaks> sabdfl: :)
[08:45] <sabdfl> but it should be easy to arrange
[08:46] <sivang> sabdfl: would be probably enough and nice to have some default in place, lightweight desktop users can probably tweak their way from there
[08:46] <sivang> ajmitch: aren't you bringing this to ubuntu ?
[08:46] <ajmitch> sivang: sure
[08:46] <ajmitch> sivang: at least I'll try & hack the breezy install into shape for it
[08:46] <infinity> ajmitch : With the rapid adoption of SELinux in sid/etch, we MAY be ready for it for dapper, but I wouldn't hold my breath.  dapper+1 may be more realistic, unless someone (sabdfl) decides to divert resources to making it happen.
[08:47] <ajmitch> infinity: considering that there's only been 1 or 2 of us working on it in ubuntu til now, I think dapper's still a realistic goal to have the framework all in place
[08:47] <ajmitch> infinity: although I don't think dapper would ship with a policy turned on by default
[08:48] <infinity> ajmitch : Have you been tracking the patches flowing into debian base in the last month or two?
[08:48] <ajmitch> yes
[08:48] <sivang> I don't think it should be the highest priority, in enterprise point of view, with what I encounter, SElinux if comes in default install, isn't fully exploited to it's capabilities, and people on FC4 tend to disable it or do nasty hacks to get some software working.
[08:48] <infinity> ajmitch : Cool.  Does any of it work yet? :)
[08:48] <ajmitch> infinity: sure, the patches are pretty much what I've been using here to test
[08:49] <infinity> Yeah, SELinux's complexity is a black mark against it, unfortunately.
[08:49] <ajmitch> certainly
[08:49] <ajmitch> writing policy comes close to black magic at times
[08:49] <ajmitch> just because programs can do so many weird & wonderful things
[08:49] <ajmitch> it's on the BOF list for UBZ, anyway
[08:50] <infinity> And due to the (correct) "disallow everything unless I let you do stuff" security model, poeple are likely to get furstrated and just turn the whole thing off, which defeats the purpose.
[08:50] <ajmitch> so I'll try & bring a useful demo :)
[08:50] <infinity> So it needs to be made a bit more easy to configure, I suspect.
[08:50] <ajmitch> it's improved a lot in the last year, with modular policy & runtime booleans
[08:51] <ajmitch> so you can toggle policy in specified areas
[08:51] <sivang> infinity: should probably have some GUI hooks so that each time this happens, a user is offered the possibilty to allow it, translated automatically to the underlying actions that need be taken for that in SELinux
[08:51] <ajmitch> sivang: that's possible now
[08:51] <ajmitch> possible to code, I mean :)
[08:51] <infinity> sivang : yeah, for a desktop system, that does seem desiarable.
[08:51] <sivang> ajmitch: ofcourse
[08:52] <sivang> ajmitch: that's interesting, I should add this to the BOF Ideas?
[08:52] <infinity> I need to get an SE-enabled server system running and play with it, I guess.
[08:52] <ajmitch> sivang: sure
[08:52] <infinity> sivang : I doubt the effort would be made to code it, unless an MOTU wants to take up the torch.
[08:52] <sivang> ajmitch: if we do that, we rock the enterprise. I don't think any other distro has somethign like that
[08:52] <infinity> sivang : But noting it as a "feature we should be on the lookout for" makes sense.
[08:53] <ajmitch> I'm going to try & commit to a few hours a week at least, if people are open to it
[08:53] <sivang> infinity: sorry, EPRASEERROR due to ENONNATIVESPEAKER :)
[08:53] <infinity> sivang : Which part? ;)
[08:54] <sivang> infinity: the whole sentence :)
[08:54] <infinity> Right.  Just ignore it, then.  I don't ever say anything worth reading. :)
[08:54] <ajmitch> heh
[08:55] <sivang> lol
[08:55] <jdub> vuntz: ha ha ha
[08:56] <vuntz> jdub: is this for your nice quote I sent? :-)
[08:57] <jdub> yeah
[08:57] <vuntz> ahah
[08:58] <vuntz> jdub: maybe you can write some other cool stuff for my next mail? :-)
[08:58] <sivang> vuntz: is it hilarious ? :)
[08:59] <jdub> vuntz: maybe i should take advertising revenue for your mail ;)
[09:00] <vuntz> :-)
[09:32] <\sh> re
[09:33] <sivang> Moins \sh  :)
[09:49] <janimo> mvo, do you think launchpad-integration could be easily split as to provide at least the bonoboUI query method separately?
[09:50] <janimo> rigth now lpi brings in gnome dependencies even if the program does not use gnome libs (gaim)
[09:50] <janimo> I ask you since seb128 is not around and you worked on lpi too
[09:51] <janimo> hey seb128 :) read 3 lines above :)
[09:51] <seb128> hi janimo
[09:51] <seb128> janimo: that's a joke, right?
[09:51] <janimo> well if you laugh it is 
[09:52] <janimo> but I asked seriously
[09:52] <seb128> ...
[09:52] <janimo> for xubuntu where we do not want gnome libs if possible
[09:52] <janimo> gaim is not a gnome app
[09:52] <seb128> hint: IRC start putting lines when you start your client
[09:52] <seb128> not when your box is sleeping
[09:53] <janimo> I thought you guys use scrollback and are always online :)
[09:53] <janimo> I'll repeat that then
[09:53] <seb128> you say "hi"
[09:53] <seb128> why?
[09:53] <janimo> mvo, do you think launchpad-integration could be easily split as to provide at least the bonoboUI query method separately?
[09:53] <janimo> 10:50 < janimo> rigth now lpi brings in gnome dependencies even if the program does not use gnome libs (gaim)
[09:53] <janimo> 10:50 < janimo> I ask you since seb128 is not around and you worked on lpi too
[09:53] <janimo> seb128, these were the lines I wrote just before you enetered
[09:54] <janimo> sorry if I confused you
[09:54] <sivang> janimo: could be done, but currently I wrap the l-p functions with my bonnoboui ones to avoid code duplication
[09:55] <dholbach> good morning
[09:55] <janimo> sivang, how easily could it be done?
[09:55] <janimo> morning daniel :)
[09:55] <dholbach> hey jani
[09:55] <seb128> janimo: liblaunchpad-integration0 and liblpint-bonobo0 are already splitted
[09:55] <seb128> hello dholbach
[09:55] <dholbach> morning seb
[09:55] <janimo> seb128, but the integration lib needs the app which in turn needs all of them? I just had a cursory look at the sources
[09:56] <janimo> seb128, in this case theoretically gaim should not need the gnome depends right?
[09:56] <sivang> seb128: how do we get by that my wrapper funcs use launchpad-integration itself? 
[09:56] <seb128> janimo: I don't care
[09:56] <seb128> janimo: libgnome is quite small
[09:57] <janimo> seb128, it may be quite small but it brings in other gnome dependencies (almost all )
[09:57] <seb128> sivang: I don't get your question, what wrapper funcs?
[09:57] <seb128> janimo: that's far from beeing true
[09:57] <janimo> seb128, I have bare X installed + xfce
[09:58] <seb128> raahhh, people are never happy
[09:58] <seb128> I'll get some coffee
[09:58] <seb128> later
[09:58] <sivang> seb128: laterz
[09:58] <janimo> when I tryp installing gaim it brings in bonobo,gnomeui,gamin,gconf2
[09:58] <janimo> gnomevfs etc
[10:00] <sivang> seb128: never mind, stupid quesiton :)
[10:01] <janimo> sivang, any docs on lpi besides the wiki page and the source?
[10:01] <sivang> janimo: not that I know of, sorry
[10:01] <seb128> janimo: it's a trivial lib
[10:01] <sivang> janimo: it's really simple though
[10:02] <janimo> I'll read though it see if I can come up with more meaningful questions or even solutiones re my problem
[10:02] <zyga> morning
[10:04] <mvo> ping siretart 
[10:04] <siretart> mvo: pong
[10:05] <sivang> seb128: as a side note, gaim is not a bonobo app right?
[10:05] <mvo> siretart: can you still reproduce #14077 on one of your machines? would you be able to test a updated version of u-n?
[10:05] <janimo> sivang, not or it wouldn't work on windows I guess
[10:05] <janimo> and before lpi it did only depend on gtk
[10:06] <zyga> mvo: does language-selector still need hacking?
[10:06] <siretart> mvo: I'd love to, but I don't have access to the affected machine right now
[10:06] <seb128> sivang: no, and it doesn't use the bonobo lib neither
[10:06] <siretart> mvo: and it could take until thursday until I see my dad again :(
[10:06] <mvo> zyga: good question, did you find a bug :) I had hoped that my latest upload resolved most issue
[10:07] <seb128> janimo: I'm not that happy with patching the apps for lpi neither, but I've not taken this decision
[10:07] <sivang> 09:58 < janimo> when I tryp installing gaim it brings in bonobo,gnomeui,gamin,gconf2
[10:07] <mvo> siretart: ok, thanks. it's a anoying bug because I was never able to reproduce it on one of my machines
[10:07] <seb128> janimo: if you can come with a better design or code of the lib and send a patch you are welcome
[10:07] <sivang> seb128: how come it pulls in bonobo when he tried to install gaim?
[10:08] <seb128> installing the lib install "launchoad-integration" which Depends on libgnome2-0 which grabs gconf, gnomevfs, etc
[10:08] <zyga> mvo: the UI needed some small changes if you remeber
[10:08] <siretart> mvo: I was also confused. My dad came to my and was also very confused. I'm very proud of him that he found himself that killing u-n solves the issue for him 
[10:08] <zyga> mvo: unfortunatly synaptic still has that small issue I've told you about (and patched)
[10:09] <mvo> zyga: yes, synaptic needs a update 
[10:09] <sivang> seb128 k
[10:10] <mvo> zyga: sorry, what was it in language-selector again?
[10:10] <janimo> sivang, seb128 yes that was my initial question, if lpi can be more granular so gaim can depend only on lpi_gtk not lpi_bonobo
[10:10] <seb128> it is granular
[10:10] <seb128> there is 2 libs
[10:10] <seb128> one gtk and one bonobo
[10:10] <janimo> I'll go back and dig since this would be nice for xubuntu
[10:10] <seb128> what grabs libgnome is the part which start the browser
[10:10] <seb128> it uses gnome-open
[10:11] <janimo> seb128 oh but that could surely done easier not?
[10:11] <zyga> buttons were very non-HIG
[10:11] <janimo> some direct exec or something ?
[10:11] <sivang> seb128: we could seperate the python scripts from launchapd integration ?
[10:11] <seb128> gnome-open gets the default browser from your GNOME/gconf config
[10:11] <mvo> zyga: the buttons are changed to "close/apply", wasn't that what you suggested?
[10:11] <sivang> seb128: then each lib in turn would have to have it's execing functions, currently liblpint-bonobo uses the fire up function from launchpad-integration
[10:12] <zyga> mvo: it seems better now - I've just had a look at it again
[10:12] <mvo> zyga: thanks
[10:13] <sivang> seb128: so possibly, copying the calling code from liblaunchpad-integration, into liblpint-bonoo, and making a seperate package to ship the python scripts would relieve lpint-bonobo from using launchapd-integration
[10:13] <sivang> my 2c ..
[10:14] <sivang> janimo: maybe that's what you meant?
[10:15] <seb128> sivang: not a good option imho, what do you win by doing 2 different implementation?
[10:15] <sivang> seb128: I don't win much , I agree. aside from splitting the dependencies 
[10:15] <sivang> seb128: It's still code duplication which I don't like
[10:15] <seb128> you don't split any dependency
[10:15] <seb128> the only dep is libgnome due to gnome-open
[10:16] <seb128> if you make some code getting the default browser without it you can change this code for everything
[10:16] <seb128> no need to split
[10:18] <zyga> mvo: separate l-s issue, the language and country names - are they pulled from the speciall package to avoid multiple translations?
[10:18] <janimo> could there be a generic open script which checks and if there's a gconf reads from that otherwise uses x-www-browser or something
[10:19] <crimsun> morning, jani
[10:19] <janimo> so there would be no direct dep on gnome but would be used if available
[10:19] <janimo> morning daniel :)
[10:19] <mvo> zyga: they are copies from the iso-codecs package. They are not translated before
[10:19] <zyga> mvo: they have to be - countries at least are translated in numerous packages
[10:20] <zyga> I'm not sure about languages
[10:20] <sivang> seb128: ah right, I see that now.
[10:20] <mvo> zyga: then rosetta should be able to deal with that, shouldn't it? I would suggest "this was already translated somewhere else"?
[10:20] <seb128> janimo: probably yep
[10:21] <sivang> janimo: still that would be duplicating gnome-open's job, is it that bothering that it pulls those deps in? I reckon the don't take too much space..
[10:21] <zyga> mvo: hmm true
[10:21] <janimo> sivang, the disk space is the least of the concerns
[10:21] <seb128> janimo: that's trivial to do if(gnome-open) gnome-open ... else non-gnome-call
[10:21] <zyga> mvo: is it possible to get two .pot's (for two domains) from l-s?
[10:21] <janimo> memory footprint and startup time
[10:22] <janimo> those matter more for xfce targetted machines
[10:22] <sivang> janimo: I see
[10:22] <mvo> zyga: why two domains? one for the package and one for the countires/languages?
[10:23] <janimo> seb128 but if(gnome-open) does not imply that there needs to be a dep on gnome-open for it to be called?what is that python or pseudocode?
[10:23] <seb128> pseudo-code
[10:23] <sivang> janimo: you can silently fail if !gnome-open, without depending on it
[10:23] <janimo> so how to detect existence of gnome-open?I thought of checking if there exists a gconf dir
[10:23] <seb128> you can move the libgnome Depends to a Recommend if you do that
[10:24] <sivang> right
[10:24] <seb128> janimo: no need to bother with gconf, if the file is on the disk or not works fine
[10:24] <sivang> janimo: simple file exists checking probably
[10:24] <zyga> mvo: yes
[10:25] <sivang> janimo: we do the same with some gnome-cups-manager enhancment
[10:25] <janimo> I still haven't read the lpi code so where exactly should that check be?
[10:25] <sivang> janimo: I'll find it for you
[10:26] <janimo> which files existence needs to be checked
[10:26] <mvo> zyga: last time I checked rosetta didn't liked two pots in one dir. I would have to create a po and a po-countries dir. pretty ugly :/
[10:26] <janimo> sivang, thanks do you want to take care of all this (i.e upload) or just point me to the right dir?
[10:26] <janimo> direction
[10:27] <sivang> janimo: as you prefer :) (Acutally I use seb128's sponsering for uploads for the moment)
[10:28] <janimo> well I dont' mind looking myself but I am sure you'd do a better/quicker job
[10:28] <janimo> so your call actually :)
[10:28] <mvo> sivang: how is the firefox lp integration done btw? it misses the new icons it seems
[10:29] <sivang> mvo: that was seb128's work :p :)
[10:29] <janimo> hmm interesting, as ff did _not_ bring gnome in
[10:30] <sivang> janimo: I'll email you with the details where to look anyhow. let talk afterwards
[10:30] <janimo> sivang, thanks
[10:31] <seb128> mvo: not with lpi, their html/javascript language is nothing like C :/
[10:31] <sivang> seb128: you used html/javascript for lpi on fifie? 
[10:32] <infinity> The whole UI is XML/JS.
[10:32] <mvo> seb128: you hacked it in XUL?
[10:32] <infinity> (XUL)
[10:32] <sivang> omg. poor seb128 :-/
[10:32] <seb128> mvo: dunno if that's XUL, I hack whatever language made the UI for them
[10:32] <infinity> You could have hooked it in at the C++ level and exported the functions to XUL.
[10:33] <infinity> (Which would make them available to other skins/themes, too)
[10:33] <seb128> infinity: I've no clue on how to do that and about the firefox code ... but if somebody wants to do it he's welcome
[10:33] <infinity> Note: This is not me volunteering for the task.
[10:33] <seb128> yeah
[10:33] <seb128> it took my 1 day of work/builds to get the menu items here
[10:34] <infinity> Heh.  File a bug and get Diziet to do it.  He LOVES hacking firefox, I can tell.
[10:34] <seb128> and I don't intend to spend a week to get how you can use C here and hack XUL
[10:34] <seb128> haha
[10:34] <infinity> I have my hands full with non-GUI stuff.
[10:34] <seb128> nice idea :)
[10:34] <seb128> and I'm mine busy enough with GNOME
[10:34] <seb128> I don't even use firefox
[10:35] <seb128> epiphany-browser use lpi for its part :)
[10:35] <infinity> Heh.
[10:35] <infinity> My GUI is just a pretty way to launch a few dozen terminals.
[10:38] <Mithrandir> infinity: you use GUIs for that?  I just hold down F1 until I have enough.
[10:41] <mvo> Mithrandir: is upstream doing the rewrite? 
[10:41] <Mithrandir> mvo: no idea, I've done a 90% job on my system, but it needs a bit more work.
[10:41] <Mithrandir> I've got nice stuff like dbus integration and so on in there.
[10:42] <mvo> Mithrandir: *yum*
[10:42] <Mithrandir> which means that the user doesn't have to access the nvram himself, the process can run as a tpbd user which has rw access to /dev/nvram
[10:44] <mvo> Mithrandir: nice. looking forward to it
[10:51] <mvo> seb128: will you hate me if I change the gdm init script and add a special case for usplash (init the console-fonts right before gdm starts)?
[10:52] <seb128> mvo: if that works, nop. If I get bugged because of you, you better start running now :p
[10:52] <seb128> :)
[10:53] <seb128> mvo: BTW do you still have those lpi warning on your todo, or should I put that on my list?
[10:53] <mvo> seb128: I won't manage to look at it today that's pretty sure. not sure about tomorrow though
[10:53] <seb128> any day before 5.10 is fine
[10:54] <seb128> I've still ~170 non-upstream bugs on my list, it's enough to keep me busy for the week :p
[10:54] <seb128> let me know if you start working on it, so we don't dup work
[10:56] <mvo> seb128: ok. I have some tricky must-fix-before-breezy stuff as well, but I think I'll manage to put it somewhere in between
[10:58] <seb128> mvo: thanks
[10:58] <ajmitch> hi chmj 
[10:59] <ajmitch> hi mvo :)
[11:00] <mvo> ajmitch: we will see you in UBZ?
[11:00] <ajmitch> mvo: sure
[11:00] <mvo> ajmitch: nice!
[11:00] <ajmitch> mvo: assuming I get my passport sorted out this week :)
[11:00] <mvo> ajmitch: heh :) good luck!
[11:00] <ajmitch> it just needs replaced due to some water damage
[11:00] <ajmitch> easy to do
[11:01] <ajmitch> just another expense for the trip though :)
[11:05] <chmj> hey ajmitch 
[11:07] <crispin> pitti: fyi, I am hoping to get a cf card 'soon', and will then do lots of in-depth debugging on that pmount wierdness
[11:07] <pitti> crispin: you mean #14495?
[11:08] <crispin> pitti: indeed
[11:08] <pitti> crispin: I just replied again, I'm totally confused by the contradictions in the report
[11:09] <crispin> pitti: yeah, it is getting a bit confusing in there
[11:09] <pitti> crispin: I asked to restart from scratch
[11:10] <crispin> yeah, I saw, sadly, I don't have a card at the moment, but when I do I'll work on it night and day till I track down where the problem is :-)
[11:14] <seb128> mvo, pitti: wanna join #ubuntu-desktop ? :)
[11:14] <pitti> seb128: in a minute
[11:15] <fabbione> pitti: did you read my messages?
[11:15] <pitti> fabbione: erm, email replies?
[11:15] <sivang> mvo: what are those lpi warnings about? may I help with them?
[11:16] <fabbione> pitti: also
[11:17] <dholbach> ogra, Unfrgiven, sebest: want to join #ubuntu-desktop? :)
[11:18] <mvo> sivang: warnings like: (synaptic:25229): Gtk-CRITICAL **: gtk_accel_label_set_accel_closure: assertion `gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed
[11:19] <mvo> sivang: sure, go ahead :) you get them in non-bonobo using apps
[11:19] <seb128> mvo: #ubuntu-destkop !!
[11:19] <seb128> and non-UIManager apps
[11:19] <seb128> ie: gucharmap
[11:20] <sivang> seb128: I'll join #ubuntu-desktop now 
[11:21] <seb128> feel free
[11:21] <sivang> seb128: all desktop related bugs and development should go there?
[11:24] <pitti> fabbione: alright, let's wait until the second patch is a bit more mature
[11:24] <fabbione> ok
[11:24] <fabbione> pitti: it looks sane too me
[11:24] <fabbione> it's not that bad as it seems
[11:24] <seb128> sivang: by example, but stuff like lpi can go on this chan too ... -desktop is a place to discuss with new people interested by desktop stuff, about bugs not concerning this chan (ie: minor desktop issues), etc
[11:26] <sivang> seb128: ok, nice to see that. so the desktop team is mainly for attracting new people to the table?
[11:27] <seb128> yep
[11:27] <dholbach> sivang: and a place to discuss stuff, to make more cool stuff on the desktop happen
[11:27] <Aegir> Good. I have a minor desktop issue with Ubuntu and I've been too hesitant to ask about it here :)
[11:31] <Aegir> ...And I've killed the conversation. Go me...
[11:31] <sivang> dholbach, seb128 : we should have some publicity about that, it appears that people are unaware of it
[11:32] <dholbach> seb128: want me to do it? :p
[11:32] <seb128> dholbach: do what, we mailed lists, I blogged ...
[11:32] <dholbach> seb128: oh you did
[11:32] <seb128> :)
[11:33] <dholbach> and you have a hackergotchi too :)
[11:34] <seb128> some GNOME guys did it
[11:34] <seb128> I've not asked for anything
[11:34] <dholbach> oh come on :)
[11:35] <dholbach> sivang: do you have another idea for more publicity?
[11:36] <dholbach> sivang: i ordered a plane painting #ubuntu-desktop at the sky over berlin, but that's all i could think of
[11:37] <sivang> dholbach: hehe
[11:37] <sivang> dholbach: serious?
[11:37] <sivang> dholbach: we can go over upstream communities and offer them to participate 
[11:38] <dholbach> sivang: not really :-p  - ask in #gnome* channels?
[11:39] <seb128> no
[11:39] <seb128> don't make noise on #gnome* chans :)
[11:39] <dholbach> yeah, that's what i thought :)
[11:39] <seb128> mails and planet are enough
[11:41] <pitti> lifeless: ping
[11:42] <sivang> seb128: cool then
[11:52] <zyga_> seb128: okay
[11:52] <zyga_> seb128: my laptop just died because of that bug
[11:53] <seb128> what bug?
[11:53] <zyga_> seb128: the thing is, some udev event launches a horde of scripts that then run another hordrde (>50) of hdparm
[11:53] <seb128> you have not described it
[11:53] <zyga_> I tried but the other computer died :-)
[11:53] <zyga_> I run hoary on this one
[11:54] <zyga_> it always happens after modprobing for cloop
[11:54] <zyga_> and mounting cloop a moment later
[11:54] <zyga_> I can reproduce it and I've got a log of ps aux if you'd like
[11:55] <zyga_> http://www.suxx.pl/run.log
[11:55] <zyga_> that's from yesterday
[11:55] <zyga_> the number of hanging hdparms is not constant
[11:55] <zyga_> they never die, I cannot kill any of them (all are in 'D' state according to top)
[11:56] <zyga_> system is locked and hdd led keeps blinking
[11:56] <zyga_> seb128: if you have any questions/suggestions feel free ask
[11:57] <seb128> zyga_: I let the udev guys reply to this one
[11:57] <seb128> why do you think it comes from udev?
[11:57] <zyga_> seb128: the ps aux shows it pretty clearly
[11:58] <seb128> right
[11:58] <zyga_> udev launches some udev_run_parts
[11:58] <seb128> have you put a bug to bugzilla?
[11:58] <zyga_> seb128: I tried yesterday when the box died
[11:58] <zyga_> seb128: bugzilla or malone?
[11:59] <zyga_> seb128: kernel spits 'hda: timeout waiting for DMA'
[11:59] <zyga_> and 'drive not ready for command'
[11:59] <seb128> bugzilla
[11:59] <seb128> malone is for universe atm
[11:59] <zyga_> okay
[12:01] <seb128> hey vuntz
[12:03] <vuntz> hi seb128
[12:04] <seb128> dholbach: I've closed http://bugzilla.ubuntu.com/show_bug.cgi?id=16428
[12:04] <seb128> dholbach: gdm uses the xorg config, GNOME uses the GNOME user config/xrandr ... that's not really a bug
[12:04] <dholbach> i see, thanks for that
[12:04] <seb128> np
[12:05] <seb128> the situation is not ideal, we should have an easy way to reconfigure xorg, but keeping a bug on gdm for that is not really useful
[12:09] <zyga_> seb128: our bugzilla, right?
[12:13] <seb128> zyga_: bugzilla.ubuntu.com
[12:15] <zyga_> seb128: can I change severity to major?
[12:15] <seb128> zyga_: yep
[12:16] <zyga_> seb128: #16433
[12:16] <seb128> thanks
[12:17] <zyga_> thanks
[12:51] <hughsie> pitti: ping?
[12:51] <pitti> Hi hughsie 
[12:52] <pitti> hughsie: still problems with the hal datatype patch?
[12:52] <hughsie> pitti, hi, yes!
[12:52] <hughsie> then mv -f ".deps/probe-hiddev.Tpo" ".deps/probe-hiddev.Po"; else rm -f ".deps/probe-hiddev.Tpo"; exit 1; fi
[12:52] <hughsie> In file included from probe-hiddev.c:41:
[12:52] <hughsie> /usr/include/linux/hiddev.h:92: error: syntax error before __s32
[12:52] <hughsie> /usr/include/linux/hiddev.h:94: error: syntax error before physical_minimum
[12:52] <hughsie> /usr/include/linux/hiddev.h:95: error: syntax error before physical_maximum
[12:52] <hughsie> /usr/include/linux/hiddev.h:98: error: syntax error before } token
[12:52] <hughsie> /usr/include/linux/hiddev.h:119: error: syntax error before __s32
[12:52] <pitti> hughsie: /msg please, please don't flood
[12:52] <hughsie> msg pitti sorry...
[12:52] <pitti> hughsie: hmm, configure, make, make clean worked fine for me
[12:53] <hughsie> hmm... it worked for me too this morning too
[12:53] <hughsie> but now it's complaining after a fresh checkout
[12:54] <hughsie> got any ideas?
[12:54] <pitti> hughsie: maybe one of the #include <asm/types.h> I removed really needs to be there?
[12:55] <pitti> hughsie: you might try adding it again in probe-hiddev.c
[12:55] <pitti> hughsie: maybe sys/types.h is enough, asm/ is really evil for an userspace program
[12:55] <fabbione> asm should never be used directly
[12:56] <hughsie> #include <asm/types.h> works....
[12:56] <fabbione> userland should include sys/ or whatever that will take care of digging into asm if required
[12:56] <hughsie> #include <sys/types.h> doesn't work
[12:56] <fabbione> than something else is screwed too
[12:57] <hughsie> i'm guessing  /usr/include/linux/hiddev.h shouldn't be using __s32
[12:57] <pitti> hughsie: well, at least it should include asm/types.h on its own
[12:57] <\sh> hmm...is it possible to grab now an daily ubuntu ISO with latest kernel upload (even for the installer?) ;)
[12:58] <hughsie> hiddev.h?
[12:58] <pitti> hughsie: yes, if the include file needs a symbol, it shouldn't rely on external files to include it
[12:59] <pitti> hughsie: however,  wait: it *does* include asm/types.h already
[12:59] <pitti> hughsie: are you sure that you properly recreated all autofoo files? so that the configure.in change is really active and the type definitions wiped?
[01:00] <hughsie> pitti, ahh, let me check
[01:02] <hughsie> pitti: no, i've just done a fresh autogen.sh, still the same error
[01:03] <pitti> hughsie: what did you change between this morning and now?
[01:04] <hughsie> pitti, nothing! thats the thing. I did a make distclean && ./autogen.sh && make
[01:04] <pitti> odd
[01:04] <pitti> hughsie: does "grep -r _s32" in your hal tree have any hits?
[01:05] <Kamion> \sh: you can answer these questions for yourself by looking at the *.list files on cdimage
[01:05] <pitti> hughsie: erm, "grep -r __s32 ." of course
[01:06] <hughsie> pitti: no, but it wouldn't...  /usr/include/linux/hiddev.h has the __s32 tho
[01:06] <zyga_> pitti: hi, who knows udev around here? It's about bugzilla #16433
[01:06] <pitti> zyga_: please CC me on the bug, I'll have a look
[01:07] <zyga_> pitti: k, thanks
[01:08] <zyga_> pitti: adding martin.pitt@canonical.com
[01:11] <hughsie> pitti, should we really be using linux/hiddev.h?
[01:12] <pitti> hughsie: not if you can avoid it :-) but I can't say off the top of my head if that's really necessary
[01:13] <hughsie> pitti: shouldn't hiddev.h be using non-kernel type datatypes?
[01:13] <Treenaks> sivang: unless you run into #14007 or #15080
[01:15] <sivang> so gf (who's a mostly windows user) takes this edimax card which around most distros you need to compile a module, plugs into the breezy dell lappie, we have no wireless around there, she calls up "I will have network access here, you'll see" I'm telling her no way, you need at least an ESSID. boom. she pings me on IM.
[01:16] <sivang> Treenaks: obviously she didn't run into them :)
[01:16] <hughsie> pitti: mind if I fix the HAL build until we sort this mess out?
[01:16] <hughsie> #include <asm/types.h>
[01:16] <mjg59> elmo: Are you with cvd at the moment?
[01:17] <pitti> hughsie: sure, it was there before, it's no regression
[01:17] <pitti> hughsie: my primary reason for starting this was to make hal build on amdd64
[01:18] <hughsie> pitti: sure, no problem - it's just my build fix might break the amd64 compile
[01:19] <hughsie> ogra: just to let you know, I'm installing breezy as I speak... :-)
[01:20] <ogra> YAY
[01:20] <hughsie> ogra: want to get some ubuntu love
[01:20] <segfault> why people ignores #16386?
[01:20] <ogra> :)
[01:21] <sivang> Treenaks: ah apparently, there's a shared wrieless on the building, no charge :) 
[01:21] <hughsie> ogra: i'm going to feel like a newbie again... :-)
[01:21] <ogra> nahh... ubuntu is easy... and you got us around if you need us ;)
[01:22] <hughsie> ogra: cool :-) thanks. Expect me to be complaining before long...
[01:22] <Treenaks> sivang: cool :)
[01:22] <Keybuk> pitti: dude
[01:25] <zyga_> segfault: I'd love if people send whole urls
[01:25] <zyga_> it makes lazy people like me more likely to click on the link
[01:25] <segfault> heh
[01:25] <segfault> http://bugzilla.ubuntu.com/show_bug.cgi?id=16386
[01:28] <sebest> there is not a bugzilla bot? :)
[01:28] <pitti> Keybuk: Hi! do you have a minute for discussing the hotplug mess?
[01:28] <Keybuk> pitti: yup, that's exactly what I want to discuss
[01:28] <Keybuk> hang on, let me get my gun
[01:29] <Keybuk> anyone got gregkh and kay's addresses?
[01:29] <Keybuk> so ...
[01:29] <pitti> Keybuk: Greg KH <greg@kroah.com>
[01:29] <Keybuk> hotplug
[01:29] <Keybuk> I meant his real life address, for the killing :p
[01:29] <pitti> Keybuk: oh, sorry :/
[01:30] <Keybuk> you have one of the not-working usb cameras?
[01:30] <pitti> Keybuk: send them a mail bomb instead (will drastically reduce your jail time, too)
[01:30] <pitti> Keybuk: well, they work
[01:30] <pitti> Keybuk: they are just controlled by libusb
[01:30] <Keybuk> right, yours works?
[01:30] <pitti> Keybuk: it's one of the gphoto2 cams which do not act as mass storage
[01:31] <Keybuk> right, and those are currently communicated to with /proc/bus/usb/... yes?
[01:31] <pitti> Keybuk: yes, provided that /proc/bus/usb/003/006 permissions are right
[01:31] <pitti> Keybuk: yep
[01:31] <pitti> Keybuk: thanks for pointing out the broken hotplug script, I indeed get *all* proc devices chmodded now
[01:31] <Keybuk> I wonder what is replacing that
[01:31] <Keybuk> /proc/bus/* is going away
[01:31] <zyga_> I've got a non mass-storage digital camera
[01:31] <zyga_> but it works just fine
[01:31] <pitti> Keybuk: so it seems that hotplug.d/usb is always executed, instead of being called through the hotplug map
[01:32] <Keybuk> I bet everyone's forgotten about those devices (I had)
[01:32] <Keybuk> that's right
[01:32] <Keybuk> ok, so we have
[01:32] <pitti> Keybuk: you get a proper /dev/foo for your cam?
[01:32] <Keybuk> mine's usb storage
[01:32] <Keybuk> /etc/dev.d/$SUBSYSTEM/*.dev
[01:32] <pitti> ah, I see
[01:32] <Keybuk> these are run for every /dev device node created
[01:33] <Keybuk> including those made at udevstart in S04udev
[01:33] <pitti> yep, but that doesn't help for many scanners and cams
[01:33] <Mithrandir> Keybuk: what'll replace /proc/bus/usb?  Proper devices?
[01:33] <pitti> since they don't have a sysfs node
[01:33] <Keybuk> though not those in initramfs because we dont copy the scripts there
[01:33] <Keybuk> Mithrandir: see above, I suspect everyone's forgotten about it ... I'll ask on linux-hotplug-devel later
[01:33] <Keybuk> right
[01:33] <pitti> Keybuk: so the initial boot problem is that /proc/bus/usb is already there when initramfs runs, but there is no hotplug script there?
[01:34] <Keybuk> next there's /etc/hotplug.d/$SUBSYSTEM/*.hotplug
[01:34] <Keybuk> those are run for every /dev device node created as a result of a kernel uevent
[01:34] <pitti> Keybuk: apparently they are run for more devices, not just /dev ones
[01:34] <Keybuk> and last there's /etc/hotplug/$SUBSYSTEM/*.usermap
[01:34] <pitti> Keybuk: I'd really like to keep the scanner and camera usermaps
[01:34] <Keybuk> which are run as a result of the hotplug usb agent
[01:35] <Keybuk> ok, if a usermap is involved, the script should not be in /etc/hotplug.d
[01:35] <Keybuk> it should be in /etc/hotplug
[01:35] <Keybuk> then it'll be run by the hotplug input.agent
[01:35] <pitti> Keybuk: in the past, the usermap assigned a name to a vendor/product id, and then /etc/hotplug/usb/name was executed
[01:35] <Keybuk> uh, usb.agent
[01:35] <sivang> Keybuk: under the respective subsystem no?
[01:35] <Keybuk> yes
[01:35] <Keybuk> pitti: that's still true, that code didn't go away
[01:35] <pitti> Keybuk: but /etc/hotplug/usb/ does not work any more...
[01:36] <sivang> pitti: yep, this is what I do to send SIGHUP to cupsd
[01:36] <Keybuk> pitti: it should do
[01:36] <pitti> Keybuk: #14191
[01:37] <Keybuk> ya know
[01:37] <Keybuk> it's entirely possible that the scripts aren't run
[01:37] <Keybuk> I can't find that code anymore
[01:37] <Keybuk> no, it's there
[01:37] <Keybuk>         if [ -x $HOTPLUG_DIR/$TYPE/$MODULE ] ; then
[01:37] <Keybuk>             debug_mesg Module setup $MODULE for $DESCRIPTION
[01:37] <Keybuk>             $HOTPLUG_DIR/$TYPE/$MODULE
[01:39] <Keybuk> hmm
[01:39] <Keybuk> wonder if that's broken by grepmap
[01:39] <pitti> Keybuk: hmm, then for some reason it is not executed
[01:39] <pitti> Keybuk: or it is executed, but some parameters are not passed
[01:39] <Keybuk> right
[01:39] <pitti> (more likely)
[01:39] <Keybuk> this is a total mess, isn't it :p
[01:39] <Keybuk> so how it's _supposed_ to work is:
[01:40] <Keybuk> all devices are created in userspace as a result of a kernel uevent by udev
[01:40] <Keybuk> so you'd need a udev.rules for these things that sets the permissions and stuff
[01:40] <Keybuk> there won't be an /etc/hotplug, ./etc/dev.d or /etc/hotplug.d
[01:40] <lifeless> pitti: pong
[01:41] <pitti> lifeless: your cf bug seems to have reappeared in bz, I CC'ed you
[01:41] <pitti> Keybuk: right, in an ideal world, where insane stuff like using /proc for accessing devices would be nonexistent..
[01:42] <Keybuk> but, as you've pointed out, we don't get the /proc-fu
[01:42] <lifeless> pitti: heh
[01:42] <lifeless> pitti: I see it. I'll try with the live cd
[01:42] <Keybuk> the trouble is, udev is written by the guys trying to make this non-insane world; so they're a bit low on the backward compatibility
[01:42] <pitti> Keybuk: so I should revert the path change, put the hotplug file back to /etc/hotplug/usb/libgphoto
[01:42] <sivang> Keybuk: /etc/hotplug/$SUBSYS/$name will be deprecated in some point?
[01:42] <pitti> Keybuk: and we instead fix that calling again?
[01:42] <Keybuk> yeah, the gphoto and libsane things should go back to /etc/hotplug/usb with their usermaps
[01:42] <Keybuk> then we'll debug why that's stopped working
[01:42] <Keybuk> sivang: it's already deprecated
[01:43] <pitti> Keybuk: ok, I try this locally here
[01:43] <Kamion> segfault: sounds like fabbione's memory of how the xserver-xorg keymap guessing stuff works is rather out of date, and predates it knowing about debian-installer/keymap
[01:43] <Kamion> fabbione: please see my comment in #16386
[01:43] <Keybuk> in fact, it's totally unsupported upstream and we're just muddling on
[01:44] <segfault> yeah, that's what i thought
[01:44] <segfault> it would be nice to have it fixed and working in breezy final
[01:45] <pitti> Keybuk: odd, it actually works now
[01:45] <pitti> Keybuk: did you recently fix something that could have caused that?
[01:45] <Keybuk> nope
[01:46] <Keybuk> we're still left with the "plugged in already" or "plugged in later" problem
[01:46] <pitti> Keybuk: I'm 100% sure that it did not work at the time I fixed #14191
[01:46] <sivang> Keybuk: where to look to know how to do it the "new" way?
[01:46] <pitti> Keybuk: right, <pitti> Keybuk: so the initial boot problem is that /proc/bus/usb is already there when initramfs runs, but there is no hotplug script there?
[01:46] <\sh> hmmm...
[01:46] <Keybuk> right
[01:47] <pitti> Keybuk: it seems we need some kind of coldplugging at boot
[01:47] <Keybuk> /etc/hotplug isn't run by udevstart
[01:47] <\sh> anybody who tried warty -> hoary -> breezy upgrades?
[01:47] <zyga_> \sh: me
[01:47] <pitti> Keybuk: ok, so if /etc/hotplug.d isn't any better or worse than /etc/hotplug, I just revert the #14191 change
[01:47] <zyga_> \sh: but about 3 weeks ago
[01:48] <\sh> zyga_: good...any problems with non us/uk keyboard settings in gnome? 
[01:48] <zyga_> \sh: I was doing server upgrades
[01:48] <Keybuk> pitti: in theory, /etc/hotplug/usb/* is run by /etc/hotplug/input.agent which is run by /etc/hotplug.d/default/default.hotplug
[01:48] <\sh> zyga_: oh. I did a laptop upgrade just now :)
[01:48] <Keybuk> gah, USB.agent USB USB USB
[01:48] <Keybuk> . o O { guess who's been debugging the input subsystem too much? }
[01:49] <zyga_> \sh: anything broken?
[01:49] <mvo> hello mjg59 
[01:49] <\sh> zyga_: yepp...german keyboard layout :)
[01:49] <Keybuk> so if /etc/hotplug.d/usb is being run, then /etc/hotplug/usb should also be run -- but with the bonus that the latter lets you have a usermap
[01:49] <\sh> zyga_: reconfigured xserver-xorg didn't help...
[01:50] <zyga_> \sh: what's broken with xorg?
[01:50] <mjg59> mvo: Hello
[01:50] <pitti> Keybuk: hm, I just wonder why hotplug.d worked and hotplug didn't in the past
[01:50] <Keybuk> pitti: anyone of a zillion bugs in this mess
[01:51] <pitti> Keybuk: bah - just change every user to id 0 and forget about this crap :-)
[01:51] <mvo> mjg59: what should usplash do when no display manager is used? it currently just keeps being displayed
[01:51] <mvo> pitti++
[01:52] <sladen> mvo: there should probably be an S99 QUIT
[01:52] <infinity> mvo : It needs an init script that runs at runlevel2/S99 and tells it to exit, I suspect.
[01:52] <\sh> zyga_: moment real work life
[01:52] <mjg59> mvo: It'll wait until it times out
[01:52] <Keybuk> pitti: so I'll find out what the kernel guys are doing about /proc/bus/usb/*
[01:52] <infinity> mjg59 : Can you add an init script to explicitely QUIT it?
[01:52] <mjg59> infinity: Sure
[01:53] <infinity> mjg59 : Seems a reasonable thing to do.
[01:53] <mvo> mjg59: do you mind if I add such a script?
[01:53] <Keybuk> for breezy, I think just pitting those scripts back to /etc/hotplug/usb should be fine -- and asking people not to have them turned on while they boot <g>
[01:53] <mjg59> mvo: Not at all
[01:53] <pitti> Keybuk: hopefully scanners and cameras get proper /dev entries in the future
[01:53] <infinity> mvo : Just make the script silent, since "Killing off usplash" will make no sense if usplash isn't running.
[01:53] <pitti> Keybuk: there's no way to run the scrits at bootup?
[01:54] <infinity> mvo : And if mjg59 has done his job right, it should never ever fail or exit non-zero anyway. :)
[01:54] <Keybuk> pitti: actually, ignore me ... by moving them to /etc/hotplug/usb they _should_ be run on boot
[01:54] <Keybuk> that should fix that too
[01:54] <Keybuk> because they'll be run by S:S40hotplug
[01:54] <mvo> infinity: I'll make it silent and I'll make it run /etc/init.d/console-screen.sh (if usplash was runing) to make sure that the fonts are properly set
[01:54] <pitti> Keybuk: rock, I'll try that
[01:55] <Keybuk> the device will already exist by that point, so it'll be just a side-effect of re-hotplugging anything on the usb bus
[01:55] <zyga_> mvo: what kind of fonts does usplash use?
[01:55] <infinity> mvo : Ahh, nice.  And I suspect it should be in runlevels 2 through 5.
[01:56] <mvo> infinity: right. I'll make it S98 because it seems that a lot of display-managers run as S99 (wdm, xdm) and that will make sure that the fonts are set before X starts (once it's up, that seting will not work anymore)
[01:56] <infinity> mvo : You could put it in 0,1,2 at K01 too, for bonus points, so it will kill usplash instantly on a reboot attempt during boot.
[01:57] <infinity> mvo : Err, 0,1,6
[01:57] <infinity> mvo : We run our display manager at S13. :)
[01:57] <hughsie> ogra: is vmware workstation/gsx server a recognised target for ubuntu?
[01:58] <mvo> infinity: yes, I fixed that ;)
[01:58] <infinity> mvo : Erm... "fixed"?
[01:58] <mvo> infinity: just joking, I added a special case to the init script for usplash. ugly but ...
[01:58] <infinity> mvo : We run it early on purpose, to provide the illusion of a faster boot-to-login" time.
[01:58] <mvo> I haven't found a better way yet
[01:58] <sladen> hughsie: it probably should be;  that's what half the magazine reviewers are going to be using
[01:58] <Keybuk> pitti: so with your camera, you get insert notification?
[01:58] <ogra> hughsie, i think so, but i have no clue about vmware probs... didnt use it yet
[01:59] <hughsie> ogra: it's not working :-(
[01:59] <pitti> Keybuk: you mean from hotplug? yes
[01:59] <infinity> mvo : I'm not sure we want to blink through the VTs between usplash and *dm, though..
[01:59] <infinity> mvo : Right now, we have a very smooth transition from usplash to gdm.
[01:59] <ogra> hughsie, i know about some probs with the vmware scsi drivers
[01:59] <Keybuk> pitti: odd, that means there at least is some kind of uevent for it
[01:59] <ogra> hughsie, try to switch it to ide emu...
[02:00] <hughsie> ogra: that could be right, i installed on a virtual scsi drive
[02:00] <infinity> mvo : If you kill usplash, run console-support.sh, then wait for a *dm script to run, we'll see the console for a little bit.  (maybe a long while, if they have lots of S99 scripts)
[02:00] <pitti> Keybuk: kernel: [19333.611720]  usb 3-5.1: new full speed USB device using ehci_hcd and address 10
[02:00] <pitti>  - that's the only one
[02:00] <hughsie> ogra: i'll try with ide
[02:00] <hughsie> might be worth mentioning in the reease notes or somethign
[02:00] <mvo> infinity: it isn't noticable on my machine with gdm, but it's a reasonable fast system. the problem is that the console-fonts must be set at some point (or otherwise a lot of people like greek, chinese etc will hate us)
[02:00] <pitti> Keybuk: in the future, the kernel should create sysfs nodes for these devices, so that udev can handle them
[02:01] <infinity> mvo : I take it console-screen.sh just doesn't work at all when usplash has the console?
[02:01] <mvo> infinity: the S98usplash_quit (or whatever it is called) will only be for a) console-users b) people using non-standard display managers
[02:01] <mvo> infinity: the font setting bit fails, yes
[02:01] <Keybuk> pitti: could you download http://people.ubuntu.com/~scott/udev_log_event -- put it somewhere and make it executable, then put the full path of that in /proc/sys/kernel/hotplug
[02:01] <Keybuk> pitti: then try plugging your camera in
[02:02] <infinity> mvo : Yeah, I guess it's a reasonable compromise then.
[02:02] <infinity> mvo : And S98usplash seems sane enough on its own.  I hate init scripts that don't match their package names. :)
[02:02] <mvo> infinity: ok, sounds sensible :)
[02:03] <infinity> mvo : But, yeah, don't forget to toss it in 0,1,6/K01usplash as well, so a premature reboot kills usplash.
[02:03] <mvo> infinity: will do, thanks for your suggestions
[02:03] <pitti> Keybuk: can I /msg you /tmp/udev.log?
[02:03] <Keybuk> pitti: please
[02:05] <hughsie> ogra: you def. need a note about vmware and scsi
[02:05] <ogra> rather a fix for it ;)
[02:06] <hughsie> ogra: is it a kernel thing or a vmware thing?
[02:06] <ogra> no idea... but there should be a bug open about it...
[02:06] <hughsie> ogra: okay, i'll have a search
[02:43] <pitti> [hoary]  0 martin@donald:/etc/hotplug/usb$ l
[02:43] <pitti> total 136
[02:43] <pitti> -rwxr-xr-x  1 root root   220 2005-01-05 00:08 libgphoto2
[02:43] <pitti> -rw-r--r--  1 root root 78052 2005-09-27 12:41 libgphoto2.usermap
[02:43] <pitti> -rw-r--r--  1 root root 48961 2005-02-01 09:42 libsane.usermap
[02:43] <pitti> -rwxr-xr-x  1 root root   885 2005-02-01 09:42 libusbscanner
[02:43] <pitti> erm, sorry
[02:43] <pitti> wrong window
[02:43] <pitti> Keybuk: ^ that was hoary, so we could revert to this scheme in breezy
[02:43] <Keybuk> yup
[02:43] <Keybuk> make them look like that now
[02:44] <Keybuk> and I'll fix any bugs that stops that working
[02:44] <Keybuk> because we know that worked, and right now I don't want to consider playing silly buggers and trying to implement support for usb devicefs
[02:45] <pitti> Keybuk: yep
[02:45] <Keybuk> those are supposed to be run by /etc/hotplug/usb.agent
[02:47] <Keybuk> it'll call "load_drivers usb /etc/hotplug/usb/libgphoto2.usermap 'Martin Pitt's Camera'"
[02:47] <Keybuk> where load_drivers is in /etc/hotplug/hotplug.functions
[02:48] <janimo> sivang, I sent you the mail with the lpi changes
[02:49] <sivang> janimo: k, thanks :) let's take a look 
[02:49] <Keybuk> the first field of *.usermap should be the script name to be run (and module to be loaded, if any)
[02:49] <sivang> Keybuk: if it doesn't find a modules, it will look for a scripts named after the subsystem right?
[02:49] <Keybuk> right
[02:49] <sivang> Keybuk: and execute it
[02:50] <sivang> Keybuk: and that even without listing it in *.usermap
[02:50] <Keybuk> if it's not listed in *.usermap, then it won't load <g>
[02:50] <Keybuk> usermap maps product/vendor/class/etc. to scripts
[02:50] <Keybuk> or modules
[02:50] <pitti> Keybuk: hah, I'll just convert /etc/sane.d/hotplug/libsane.db to a proper hotplug map :-)
[02:50] <Keybuk> maps of all kinds are going away for dapper \o/
[02:52] <Keybuk> including grepmap
[02:52] <Keybuk> which, I have to say, has been the easiest piece of software to support that I've ever written
[02:52] <Keybuk> because no bugs have ever been filed agains tit
[02:52] <Keybuk> I must've been having a good day when I wrote that
[02:53] <sivang> Keybuk: I added usblp script, didn't add it to *.usermap, it still fire up whenever I plug in a usb printer
[02:53] <Keybuk> sivang: sure, because usblp is a module that appears in modules.usbmap
[02:53] <sivang> Keybuk: oh :)
[02:53] <sivang> Keybuk: <sucker> DOh! </sucker> :)
[02:56] <segfault> when will the blue and purple strings be merged to the packages?
[02:58] <Kamion> segfault: they're merged automatically into language packs periodically
[02:59] <segfault> and then they're changed to green?
[02:59] <Kamion> don't know about that; you'd have to ask #launchpad
[02:59] <Kamion> also, installer translations are only merged when somebody tells me I need to do so
[03:00] <segfault> humm
[03:00] <seb128> Kamion: thanks for the french translation notes/corrections. BTW did you figure why the "Resize ...." string is not listed by the .po ?
[03:01] <segfault> i dunno if i already talked with you, but in pt_BR there are untranslated strings in the installer
[03:01] <segfault> that resize stuff seb128 pointed, and that progress bar after the reboot
[03:01] <zyga> segfault: hey, did you have a chance to look at my i18n scripts?
[03:01] <Kamion> seb128: not yet, no :(
[03:02] <Kamion> segfault: I updated some recently, but there are untranslated strings in nearly every language so that doesn't surprise me
[03:02] <seb128> Kamion: oh, and what segfault pointed too, the progress bar of the second stage
[03:02] <Kamion> segfault: I'm happy to take updates
[03:02] <Kamion> seb128,segfault: that progress bar is mostly apt
[03:02] <Kamion> look there
[03:04] <seb128> mvo: do you know why "apt-pkg/deb/dpkgpm.cc:   {"half-configured", _("Configuring %s") }," is not listed by the po files?
[03:04] <segfault> i can't find the apt for translation in rosetta
[03:05] <seb128> mvo: apt doesn't use POTFILES files?
[03:05] <zyga> segfault: rosetta might be broken and still not display packages without translation
[03:05] <zyga> segfault: without any translation in the given language
[03:05] <segfault> zyga: i've looked, but didn't test it yet
[03:06] <zyga> segfault: nag people in #launchpad to fix it or just pull the source and play with the .po file yourself
[03:06] <segfault> heh
[03:06] <Kamion> segfault: I see partman-auto (the resize string) has updates in Rosetta, so I'll grab those
[03:07] <zyga> pitti: hi
[03:07] <pitti> Hi zyga 
[03:07] <segfault> kamion: lemme see
[03:07] <zyga> pitti: how can one get all the .pot files you told me about?
[03:07] <zyga> pitti: those that get generated now
[03:07] <pitti> zyga: rosetta tarballs have them now
[03:07] <Kamion> segfault: it's up-to-date for pt_BR
[03:07] <zyga> pitti: hmm
[03:08] <zyga> pitti: okay so I can pull the .pot from any package, right?
[03:08] <pitti> zyga: moment, please
[03:08] <segfault> kamion: yeah, it's that one
[03:08] <zyga> pitti: sure, this is very low priority
[03:09] <ivoks> Kamion: ping
[03:09] <segfault> kamion: can you merge it?
[03:09] <pitti> zyga: http://people.ubuntu.com/~pitti/langpacks/rosetta-breezy-2005-09-23.tar.gz
[03:09] <pitti> zyga: this is still incomplete and also has all po files, but it is a start
[03:09] <pitti> zyga: the "templates" directory has the POT files
[03:10] <ivoks> since we use ALSA, with dmix, shouldn't libsdl1.2debian depend on libsdl1.2debian-alsa?
[03:10] <pitti> right, it should
[03:10] <pitti> something we forgot to change
[03:10] <ivoks> that would kill lots of bugs in malone :)
[03:10] <zyga> pitti: thanks :-)
[03:11] <aschildbach> hi pitti, can you hear me?
[03:11] <pitti> aschildbach: Hi Andreas, yes
[03:11] <aschildbach> ah cool
[03:11] <aschildbach> i'm the guy from #14495 (-:
[03:11] <Kamion> segfault: 14:06 < Kamion> segfault: I see partman-auto (the resize string) has updates in Rosetta, so I'll grab those
[03:12] <Kamion> segfault: (I already said I would - doing it now)
[03:12] <ivoks> pitti: will you fix libsdl1.2 then?
[03:12] <pitti> aschildbach: do you get my /msg?
[03:12] <segfault> hehe, sorry, didn't saw it
[03:13] <pitti> ivoks: please file a bug about it
[03:13] <ivoks> ok
[03:13] <pitti> ivoks: ENOTIME at the moment, sorry
[03:13] <mjg59> Kamion: That OQO issue is very odd. Would it be possible to take a look at one at some stage?
[03:14] <Kamion> mjg59: I'm afraid I don't actually have the hardware any more
[03:14] <mjg59> Ah
[03:15] <mjg59> Can you remember if it had a fan?
[03:15] <Kamion> I know others had the issue, since I found the workaround via google
[03:15] <Kamion> it had something which went WHIRRRRRRRRRRRRRRRRR very loudly
[03:15] <Kamion> I'm not sure if it was the fan or the disk or what though :-)
[03:15] <Kamion> probably the fan
[03:15] <mjg59> And that would switch on even if it didn't have processor loaded?
[03:15] <Kamion> processor+thermal meant it was loud and hot
[03:16] <Kamion> loading neither meant it was quiet (but I think still whirring gently, IIRC), and cool enough to hold
[03:16] <mjg59> The worry is that it wouldn't cool properly under load without it
[03:19] <Kamion> I suspect it might well be more hopelessly maladjusted defaults, than that it actually *needs* to have those two modules unloaded
[03:19] <Kamion> but without the hardware any more, it's tricky to say ...
[03:19] <Kamion> you could ask the OpenAdvantage guys (Jono Bacon et al); I got it on loan from them
[03:20] <pitti> aschildbach: did you get my private message?
[03:20] <Riddell> Kamion: the contents of the kubuntu live CD don't seem to have been updated for the last few days
[03:22] <Kamion> Riddell: only the last day
[03:22] <Kamion>   linux-386: Depends: linux-restricted-modules-386 but it is not going to be installed
[03:22] <segfault> will gnome-app-install be fully translated in breezy preview?
[03:22] <Kamion> I'm going to assume that's transient ...
[03:23] <seb128> where is mvo when you need him :)
[03:23] <sivang> seb128: got my email?
[03:24] <segfault> it's a critical app, since it stays in the applications menu.
[03:24] <bob2> segfault: preview was n weeks ago
[03:25] <segfault> bob2: i mean, the preview one that'll be released one week before breezy final 
[03:26] <janimo> sivang, what do you think of the change?
[03:26] <Riddell> Kamion: it seems to be longer than that, there's file that havn't been updated on the live CD that have been on the install CD
[03:26] <Riddell> from the 24th at least
[03:26] <seb128> janimo: about what?
[03:26] <seb128> sivang: no, when did you send it?
[03:26] <sivang> seb128: I forwarded you en email from janimo to me, it has his patch for dropping libgnome depend
[03:27] <sivang> seb128: 30 minutes ago I think , I'll resend to @canonical.com? (i sent to ubuntu.com)
[03:27] <seb128> please guys, the right place for patches is bugzilla
[03:27] <janimo> seb128, a change to urls.py to call x-www-browser if there's no gnome open
[03:27] <janimo> ok btw is there a nicer way of seeing if gnome-open exists than os.path.exists('/usr/bin/gnome-open')
[03:28] <janimo> I did not know how to do it w/o hardcoding the path
[03:28] <sivang> janimo: you can check if the package which installs it is on the system
[03:28] <segfault> kamion: thanks for hunting down that keyboard bug. :)
[03:28] <sivang> janimo: that can be achived through python-apt 
[03:29] <sivang> janimo: or a simple call to dpkg --get-selection and grep for the package
[03:29] <janimo> doesn't that complicate the code a lot more?
[03:30] <seb128> janimo: janimo, that's fine this way, thanks
[03:30] <janimo> it's not like gnome-open will be installed elsewhere
[03:30] <janimo> seb128, ok
[03:31] <janimo> seb128, so I'll file a bug with the diffs I made?(no debdiff since I did not know what the next versionname should be)
[03:32] <seb128> thanks!
[03:33] <sivang> janimo: cool :)
[03:34] <carstenh> jbailey: ping
[03:34] <jbailey> carstenh: pong
[03:34] <Kamion> segfault: the term is "release candidate"
[03:36] <segfault> yeah, sorry
[03:36] <mvo> seb128: do you have your own gnome-app-install baz archive?
[03:42] <seb128> mvo: no, why ?
[03:42] <seb128> mvo: have you read my apt question ? :)
[03:44] <aschildbach> pitti: have you read my answers in our private channel?
[03:44] <seb128> mvo: where are listed apt files to translated? There is no POTFILES and "apt-pkg/deb/dpkgpm.cc" is not listed by the pos
[03:44] <pitti> aschildbach: no, seems that you are not a registered user and I can't hear you
[03:44] <aschildbach> registered user? irc seems to have changed since 10 years...
[03:44] <pitti> aschildbach: /join #pmount, please
[03:46] <jbailey> seb128: Hi! =)
[03:47] <mvo> seb128: the baz archive to have the patches in a common place. would you mind to CC them to me so that I can put them into my baz archive?
[03:47] <Kamion> seb128: Rosetta definitely has those partman-auto strings; if you want to translate it there and ping me, I'll update them
[03:47] <jbailey> seb128: With the "About Ubuntu" I uploaded last night, when I use yelp to get to it, I correctly get " propos d'Ubuntu", but if I go to Sysem,  propos, I get the English "About Ubuntu".  Do you know hohat menu item gets there?
[03:48] <mvo> seb128: about the POTFILES in apt, that is part of the general makefile in po/ :/
[03:49] <seb128> Kamion: thanks
[03:50] <seb128> mvo: I don't have any patch for gnome-app-install ... I don't hack on it ... 
[03:50] <seb128> mvo: should I?
[03:50] <mvo> seb128: sorry, I meant launchpad-integration
[03:50] <seb128> oh
[03:51] <seb128> mvo: sure, I'll mirror my baz archive for it on people.ubuntu.com a bit latter
[03:51] <mvo> seb128: thanks
[03:52] <seb128> jbailey: the menu entry does "yelp ghelp:about-ubuntu"
[03:53] <jbailey> seb128: Thanks, I'll fgure out how to localise that.
[03:53] <jbailey> Fine, love me and leave me, see if I care. ;)
[03:54] <bddebian> Morning
[03:54] <seb128> hi bddebian
[03:54] <seb128> jbailey: what package has the about ubuntu?
[03:54] <bddebian> Hello seb128
[03:54] <jbailey> seb128: ubuntu-docs
[03:55] <seb128> jbailey: 5.10-1?
[03:56] <seb128> jbailey: it only has HTML files here
[03:56] <jbailey> -2
[03:56] <jbailey> Oh, hey
[03:56] <jbailey> Sujet: ubuntu-docs_5.10-2_powerpc.changes REJECTED
[03:56] <seb128> $ apt-cache madison ubuntu-docs
[03:56] <seb128> ubuntu-docs |     5.10-1 | http://fr.archive.ubuntu.com breezy/main Packages
[03:56] <seb128> ubuntu-docs |     5.10-1 | http://fr.archive.ubuntu.com breezy/main Sources
[03:56] <jbailey> Rejected: binary uploads are not allowed - please only upload source.
[03:56] <jbailey> ROAR
[03:56] <seb128> right
[03:56] <jbailey> I HATE OUR UPLOAD SYSTEM SOMETIMES
[03:56] <jbailey> But anyhow.
[03:57] <seb128> I'll have a look when the package is available
[03:57] <seb128> mvo: about apt bug, can you fix it?
[03:59] <mvo> seb128: the problem is that the strings in dpkgpm.cc are missing?
[03:59] <Kamion> segfault: merged for next partman-auto upload
[03:59] <seb128> mvo: yep, not listed by the po
[04:00] <seb128> mvo: which makes that the second phase of the installer is not translated
[04:00] <segfault> kamion: thanks. do you know anything about gnome-app-install?
[04:00] <mvo> seb128: yes, I'll reupload a version with correct po/pots 
[04:00] <seb128> mvo: and that sucks to have "Configuring: ...." during a french install :)
[04:00] <Kamion> segfault: no, sorry, that's mvo's 
[04:00] <mvo> segfault: I do
[04:00] <mvo> seb128: sure :)
[04:00] <seb128> mvo: what do you change for that?
[04:00] <segfault> mvo: will it be fully translated in release candidate?
[04:00] <seb128> carlos: rosetta hates me :'
[04:01] <seb128> :(
[04:01] <mvo> segfault: as far as possible. the long description of the applications is unfortunately not translatable. but the rest, yes
[04:01] <mvo> segfault: assuming that there are enough people working on the translation of course
[04:01] <carlos> seb128, ?
[04:02] <seb128> carlos: when clicking on "french" from the 5.10 languages list I got "a system occured" 2 times
[04:02] <segfault> mvo: yeah, but i mean that it is acctually translated to pt_BR in rosetta, but still not appeared in the binary package. Will it come with the new version of the language-pack?
[04:02] <seb128> carlos: seems to work now ...
[04:02] <mvo> segfault: yes, that should be only a problem of a not-yet-up-to-date langpack
[04:03] <jbailey> seb128: Uploaded, Dunno if it'll make this run or the :30ish one.
[04:03] <seb128> jbailey: k
[04:04] <seb128> stripping po files from packages suck
[04:04] <seb128> that's only confusing for users
[04:04] <seb128> and that piss translators
[04:04] <jbailey> Why does it piss of translators?
[04:04] <jbailey> Don't we use that to seed rosetta?
[04:09] <seb128> jbailey: because we package GNOME 2.12.n, people update and start wondering "what do I get english strings here, what is not translated upstream, where should I fill bugs", etc
[04:09] <seb128> jbailey: we usually have days of lag between new versions and language-pack update which make really hard for translators to figure what strings are laggy due to packs or not translated
[04:10] <elmo> pitti: ?
[04:10] <seb128> jbailey: not speaking about "new software has changed his translation domain because it's versionned and now I've a 100% english app"
[04:11] <elmo> dholbach: ?
[04:11] <Treenaks> seb128: people do that?!
[04:12] <Amaranth> versioned translation domains are stupid
[04:12] <aschildbach> pitti: schau nochmal in #pmount
[04:13] <seb128> Amaranth: not especially, if you design the software to have 2 versions installed together the translations should not conflict
[04:13] <Amaranth> hmm
[04:13] <Amaranth> ok, i guess i can see the point there
[04:13] <pitti> Hi elmo 
[04:13] <Amaranth> let me say that again: for most apps, versioned translation domains are stupid ;)
[04:14] <seb128> yeah
[04:14] <elmo> pitti: l-s-{bs,lt} are uninstallable - are you aware?
[04:14] <seb128> Amaranth: speaking about translation ... smeg? :)
[04:14] <pitti> elmo: no, I wasn't; will check, thanks for the hint
[04:14] <Amaranth> seb128: err... ;)
[04:14] <seb128> Amaranth: that's quite a shame ...
[04:14] <Amaranth> seb128: lack of access to any kind of linux machine makes working on it hard
[04:15] <seb128> Amaranth: pygtk works under windows :)
[04:15] <Amaranth> seb128: smeg doesn't :)
[04:16] <Amaranth> plus honestly i have no idea how to do translations
[04:16] <Amaranth> i had something from slomo that sort of worked but was clunky, i made it a little better than i lost it
[04:16] <Amaranth> (HD crash)
[04:16] <Amaranth> i only just recently found out about intltool, but it wants to use automake
[04:17] <seb128> look on other pygtk apps
[04:18] <Amaranth> hehe, they either give up or do odd things like write their own gettext
[04:20] <seb128> I don't think so
[04:21] <thesaltydog> Amaranth, I have looked for smeg in rosetta to translate it, but it isn't in there..
[04:22] <Amaranth> thesaltydog: i know, i don't have any infrastructure setup for translations in 0.7.5
[04:23] <janimo> kamion, what is the status of the OOM in d-i for machines with 64Meg, is there a bug filed on it?
[04:23] <Amaranth> thesaltydog: is/was an 0.8 feature, which if college hadn't knocked me offline (didn't think it would be this bad) would have been done by now
[04:23] <seb128> Amaranth: 
[04:23] <seb128> import gettext
[04:23] <seb128> _ = gettext.gettext
[04:23] <thesaltydog> Amaranth, I see.. 
[04:23] <seb128> Amaranth: that's what gnome-app-install do
[04:23] <Amaranth> seb128: i know that part
[04:23] <Amaranth> seb128: but none of this matters anyway because i have no way of testing anything i do
[04:23] <chmj> dholbach: ping 
[04:24] <thesaltydog> Amaranth, and put each translatable string this way: _("string")
[04:24] <Amaranth> unless someone in the US could send me colony 5 and vmware trial CDs by snail mail ;)
[04:24] <mvo> Amaranth: better look at language-selector than gnome-app-install if you look for example code
[04:24] <Amaranth> thesaltydog: i know
[04:24] <thesaltydog> Amaranth, ok. sorry.
[04:28] <Kamion> janimo: #6136 is the general problem, and in any case infinity is already working on a large chunk of it
[04:29] <bddebian> elmo: Did you get my mail about morgueing gpac?
[04:30] <seb128> Kamion: could you change the french translation for "Erase entire disk and use LVM: ${DEVICE}" to "Effacer l'intgralit du disque et utiliser LVM : ${DEVICE}"? I've updated it on pkgconf-partman-auto-lvm/Rosetta if you prefer to grab it from here
[04:31] <seb128> Kamion: I've updated the partman-auto fr.po too on Rosetta
[04:31] <janimo> kamion,#6136?that's a tla/bazaar bug
[04:31] <janimo> or debian not ubuntu bug?
[04:36] <Kamion> janimo: sorry, #6316
[04:38] <chmj> seb128: did gnome-bt get moved to main ?
[04:38] <seb128> mvo: do you know why language-selector is not listed by rosetta?
[04:38] <Kamion> seb128: partman-auto-lvm done, will do partman-auto once Rosetta mails me it
[04:38] <seb128> chmj: pool/main/g/gnome-btdownload/gnome-btdownload_0.0.18-1ubuntu6_all.deb ... but that's not new right?
[04:38] <seb128> Kamion: thanks
[04:39] <mvo> seb128: it is available, but not found with a normal search :/
[04:39] <chmj> seb128: sorry, I meant, gnome-bluetooth 
[04:39] <seb128> mvo: right, thanks
[04:39] <mvo> seb128: https://launchpad.net/distros/ubuntu/breezy/+sources/language-selector
[04:40] <seb128> chmj: that's a question for dholbach, he did the work on it
[04:40] <seb128> mvo: yeah, I've it now, but it's not listed by the packages list
[04:40] <seb128> mvo: 444 strings?! WTF
[04:40] <mvo> seb128: language+countires
[04:40] <chmj> seb128: thought so, will ask him 
[04:41] <seb128> mvo: you could have used iso-codes or something for that :/
[04:41] <mvo> seb128: but that dosn't include translations as well
[04:42] <seb128> mvo: do you know how to automatically merge translations from an another po having them?
[04:42] <Kamion> mvo: iso-codes has perfectly good translations for those into practically everything
[04:42] <Kamion> mvo: the installer uses language/country translations from iso-codes
[04:43] <seb128> epiphany-browser/totem too
[04:43] <Kamion> (it merges them automatically into .po files)
[04:44] <mvo> Kamion: thanks, I'll use them 
[04:44] <Kamion> dpkg -L iso-codes and look at all the stuff in /usr/share/locale/ - pkgstriptranslations ignores iso-codes for just this reason
[04:44] <Kamion> cool, thanks
[04:46] <mvo> does anyone knows why xdm dosn't start when it's installed?
[04:47] <hunger> mvo: IIRC that is expecting a file where the xserver puts a symlink.
[04:47] <fabbione> mvo: is it the default login manager?
[04:47] <hunger> mvo: Check /etc/X11/Xserver/* for symlinks... has been a while since I ran into that problem... and I might mix it up with the startx not working I had a while back.
[04:49] <ogra> mvo, i tried to look into it befor the screensaver havoc broke over me
[04:49] <mvo> fabbione: yes, I purged gdm (for testing)
[04:50] <ogra> mvo, it seems it cant start a session... i could always see the grey pattern and the X before it crashed
[04:50] <fabbione> mvo: no idea.. it did work here when i repackaged..
[04:50] <mvo> hunger: no /etc/X11/Xserver :/
[04:50] <fabbione> mvo: i am not sure if something did change in the meanwhile
[04:50] <fabbione> mvo: can you strace it please?
[04:51] <mvo> fabbione: sure
[04:51] <ogra> fabbione, its badly broken... and it seems the other display managers dont work either, i also tried wdm 
[04:51] <ogra> must be a more general prob... not dm specific
[04:54] <hunger> mvo: There is a bug open about this issue... I "solved" it by dpkg --purge xdm ;-)
[04:54] <mvo> fabbione: should I upload the strace?
[04:54] <\sh> oha..xdm weirdness ;)
[04:54] <mvo> hunger: heh :) 
[04:55] <fabbione> mvo: i might take a look to it, but it was working when i uploaded it.. so it's sort of a MOTU issue by now
[04:56] <\sh> fabbione: bah ;)
[04:56] <mvo> hunger: do you know the bugnumber?
[04:57] <jdub> wow, i was just looking at the fridge
[04:57] <\sh> and someone should fix evolution asap .. download mail headers via imap, remvoing a search in a folder, evolution refuses to answer anymore..no crash nothing
[04:57] <jdub> and it tells me that the community council meeting is in 5 hours
[04:57] <jdub> ;-)
[04:57] <\sh> jdub: u saw the agenda for today? I think I'll need a "gibberish" translator ;)
[05:00] <Seveas> Hi folks, I've made a bugzilla/malone bot, which you can query for bug numbers
[05:00] <Seveas> shall i keep it here too?
[05:00] <chmj> how does it work ? 
[05:00] <Seveas> !bug malone 1
[05:00] <janimo> should launchpad accounts work for fridge too?
[05:00] <bddebian> Seveas: Does it work better than the Malone search tool? :-)
[05:00] <Ubugtu> Malone bug #1: Microsoft has a majority market share Fix req. for: upstream ubuntu, Severity: Critical, Assigned to: Mark Shuttleworth, Status: Accepted http://launchpad.net/malone/bugs/1
[05:00] <Seveas> bddebian, it has no search yet for malone
[05:00] <Seveas> only for bugzilla
[05:01] <bddebian> Seveas: Sorry, I was joking :-)
[05:01] <bddebian> Search on Malone blows :-)
[05:01] <\sh> Seveas: can u move it to #ubuntu-bugs please ;)
[05:01] <Seveas> sure
[05:01] <Seveas> !join #ubuntu-bugs
[05:01] <Seveas> there :)
[05:01] <chmj> ahh, yes, thats more appropriate 
[05:02] <janimo> jdub, when you  make the xubuntu list can you please register it with gmane as well? thanks
[05:02] <\sh> thx Seveas :)
[05:02] <\sh> ok...buying some new gadgets today...linksys router, wifi usb dongle ;) etc. pp.
[05:02] <jdub> janimo: um, i've never done that before :)
[05:02] <\sh> eventually dvd usb rom ;)
[05:03] <\sh> cu later :)
[05:03] <janimo> jdub, me neither I thought only list owners can do that, but I'll try myself then
[05:03] <Seveas> jdub, did you get my mail with the Oct. 19 details?
[05:03] <ogra> janimo, thats your job as list admin
[05:03] <ogra> i had to do the same for edubuntu-devel
[05:03] <jdub> janimo: you'll be list admin ;-)
[05:03] <janimo> ogra, am I a list admin :) ?cool
[05:03] <jdub> Seveas: yep, will reply now
[05:03] <ogra> ;)
[05:04] <Seveas> merci beaucoup!
[05:07] <jdub> janimo: get my /msg?
[05:08] <janimo> jdub, just got it
[05:09] <Seveas> jdub, didn't know the fridge was working already
[05:09] <Seveas> cool!
[05:10] <jdub> Seveas: been quiet about it before official launch :)
[05:10] <Seveas> when's that?
[05:10] <dholbach> chmj: pong
[05:10] <dholbach> elmo: ?
[05:11] <fabbione> Diziet: ping?
[05:11] <janimo> jdub, thanks :)
[05:11] <jdub> Seveas: probably ~10 days before launch
[05:11] <Seveas> ok, then I won't be shouting about it too yet ;)
[05:12] <tseng> http://www.cafepress.com/ubuntushop.14580457
[05:12] <tseng> the fridge
[05:13] <jdub> heh
[05:14] <sivang> jdub: what's the fridge?
[05:14] <tseng> sivang: ^^
[05:14] <chmj> dholbach: you do realise that libgnomebt0-dev is in universe right? 
[05:14] <sivang> tseng: a mascot for wearing? :)
[05:14] <dholbach> chmj: yeah
[05:14] <dholbach> chmj: why?
[05:14] <chmj> dholbach: I see you built noatilus against it
[05:14] <tseng> yes
[05:15] <dholbach> chmj: ?
[05:15] <tseng> sivang: also.. http://perkypants.org/misc/the-fridge.jpg < the fridge
[05:15] <jdub> sivang: see the top story on fridge.ubuntu.com
[05:15] <chmj> dholbach: noatilus-sendto is in main 
[05:15] <dholbach> chmj: thanks for the heads up
[05:16] <chmj> dholbach: you mean you didn't check ?
[05:16] <dholbach> chmj: i was quite sure it was in universe
[05:16] <ogra> dholbach, just add it to the supported seed ;)
[05:16] <dholbach> jdub: i managed to get it working, but i'm not sure that we get the dependencies into main before
[05:16] <chmj> jdub: gnome-bluetooth needs to be prometed to main first 
[05:16] <jdub> yeah
[05:17] <jdub> this is why i beg
[05:17] <jdub> with a dance
[05:17] <ogra> i think there was a main inclusion report already, should be easy to get in
[05:17] <chmj> yes 
[05:18] <sivang> jdub: "present our work" can I put packages and code there?
[05:18] <jdub> sivang: not really -> that's what launchpad is for :)
[05:18] <jdub> when we do cool stuff, we talk about it on the fridge
[05:19] <hunger> mvo: No and I can't check right now... Only managed to sneak one port through the firewall and I need that for IRC:-)
[05:19] <hunger> mvo: no as in "No I do not remember the bug number for the xdm problem".
[05:19] <dholbach> chmj: will revert until we have an agreement over the main inclusion
[05:20] <mvo> hunger: ok, thanks
[05:20] <chmj> dholbach: ok, thanks 
[05:20] <slomo> elmo: would you accept mosml when the parts under the evil licence is a seperate binary and not linked to the gpl stuff?
[05:20] <fabbione> mvo: you do synaptic right?
[05:21] <ogra> dholbach, its approved
[05:21] <fabbione> mvo: does it save logs somewhere?
[05:21] <ogra> dholbach, it just needs a seed change
[05:21] <fabbione> (like all the dpkg output)
[05:21] <slomo> elmo: mjg59 said that the license on itself would be multiverse compatible
[05:21] <ogra> dholbach, https://wiki.ubuntu.com/UbuntuMainInclusionQueue
[05:21] <sivang> jdub: you mean, soyuz :)
[05:22] <ogra> the !-dev lib is already in it seems
[05:22] <dholbach> ogra: merci beaucoup
[05:25] <sivang> jdub: who runs the fridge ? :)
[05:26] <jdub> sivang: me, plus the fridge editors (mainly robitaille and whiprush atm)
[05:27] <sivang> jdub: way cool :)
[05:27] <dholbach> chmj: you didn't add MainInclusionReportGnomeBluetooth to UbuntuMainInclusionQueue
[05:28] <dholbach> chmj: at least it wasnt there
[05:30] <chmj> dholbach: hmm, I'll add it
[05:30] <dholbach> chmj: i did so
[05:30] <chmj> dholbach: thanks 
[05:30] <dholbach> de rien
[05:30] <chmj> grrr thunderbird just crashed 
[05:31] <jdub> Seveas: heh, very realistic POV in your latest sounder post ;)
[05:32] <janimo> ogra got a minute for PM?
[05:32] <ogra> sure
[05:32] <Keybuk> where did pitti go?
[05:33] <jdub> Seveas: when you have the room / cafe details nailed down for the 19th, could you please update the B3T wiki page?
[05:35] <ogra> Keybuk, home ...
[05:35] <Keybuk> bah
[05:35] <Keybuk> half-timers
[05:36] <ogra> heh
[05:36] <fabbione> bella scott!
[05:40] <Keybuk> gnargh, I hate bugzilla's search interface
[05:40] <Keybuk> and what's worse, I'm going to have Malone for not having it
[05:40] <seb128> bugzilla search interface works quite fine
[05:41] <seb128> better than searching for bugs on sf.net, the Debian BTS, malone, etc
[05:41] <Keybuk> yeah, I now have a saved search that gives me all the open bugs to which I'm Cc'd or have commented on that aren't either reported by me or assigned to me <g>
[05:43] <jbailey> Saved searches good.
[05:43] <jbailey> Far nicer than the flood of email. =)
[05:44] <Keybuk> yup
[05:45] <Keybuk> oh well
[05:45] <BenC> where do I reassign a bug that has to do with general GUI features and improvements?
[05:46] <Keybuk> BenC: seb128 :p
[05:46] <BenC> hehe
[05:46] <fabbione> hey benC
[05:46] <BenC> hey
[05:46] <Keybuk> we should have a "iz-gtk-bug" component
[05:47] <BenC> I'm going to start with hotplug since it's probably more to do with that than anything
[05:47] <Keybuk> what's the bug/
[05:48] <Keybuk> and you're just getting your own back for all the "iz linux bug" traffic I've been sending to you, aren't you
[05:49] <slomo> elmo: ok, sent you a mail about that with some more informations
[05:51] <seb128> BenC: reassign it to me, I'll close it as NOTABUG probably :) Bugzilla is not a nice place to list new stuff to make, the wiki is better for that
[05:52] <Keybuk> what is the gui?
[05:54] <janimo> seb128, what's your bugzilla address? I left the lpi bug assigned to debzilla 
[05:54] <jdub> janimo: just type seb128 and it'll disambiguate
[05:55] <Keybuk> if it's something like "would be nice to get desktop notification of hotplug events" that probably belongs somewhere around hal
[05:55] <seb128> janimo: what jdub said
[05:55] <jkrogh> Does anyone know where the network-applet gets its connectionstatus from? 
[06:03] <BenC> spent most of yesterday going through all the kernel bugs, and only got to about 1/5 of them
[06:03] <BenC> closed a lot though :)
[06:04] <Riddell> BenC: 5 more days of that and we'll have a bug free linux
[06:05] <jdub> Driver sata_promise in latest kernel (2.6.13) don't support PDC40719 chip.
[06:05] <jdub> Some googling and modification sata_promise.c make it working. PDC20319 
[06:05] <jdub> driver works almost perfect.
[06:06] <jdub> 
[06:06] <jdub> ber.
[06:08] <BenC> "almost perfect"?
[06:09] <hughsie> Keybuk: I was thinking of a desktop daemon to do somethink like that
[06:10] <hughsie> something like "you inserted a USB2 Wireless adapter - it will not work until you install firmware"
[06:10] <Keybuk> hughsie: something that listened to hal events and popped little icons into the notification tray for a few seconds for new hardware?
[06:10] <hughsie> Keybuk: not so much for new hardware, that should "just work" - but for the stuff that doesn't work, then it should tell the usetr
[06:11] <hughsie> when it needs updated userspace, a new kernel, or firmware
[06:11] <Keybuk> seems reasonable
[06:11] <hughsie> but i wanted to scope out the problm in my head before i started with a PoC
[06:11] <hughsie> any other use cases?
[06:11] <Keybuk> I want something that when it can't find a module matching a device's modalias does a GET http://drivers.ubuntu.com/?modalias=$MODALIAS which can return information about a device
[06:11] <Keybuk> "This device is supported by Breezy Badger, upgrade?"
[06:12] <Keybuk> "This device is supposed by third-party software, download?"
[06:12] <hughsie> Keybuk: it's pretty similar to the work i've been doing on gnome power manager
[06:12] <Keybuk> "This device is unknown, supply information to us?"
[06:12] <hughsie> yes, exactly
[06:13] <hughsie> Keybuk: how to store this information? One big XML datafile
[06:13] <hughsie> ?
[06:14] <Keybuk> the modalias for a device is a simple string -- that can be wildcard matched to identify the device
[06:14] <Keybuk> for each device, you may as well xml up the sysfs entry for it
[06:16] <hughsie> Keybuk, but it gets more complicated surely?
[06:16] <Keybuk> what more is there?
[06:17] <sladen> hughsie: matching PCI IDs?
[06:17] <hughsie> What hardware needs stuff doing to it before use?
[06:17] <hughsie> sladen: yes, i'm thinking of using hald as a backend : and in that way it's easy
[06:18] <Keybuk> this becomes useful for collecting information about hardware we don't know about
[06:18] <Keybuk> hardware that needs firmware issues a firmware request anyway
[06:18] <Keybuk> so you see a "I need firmware!" event go past
[06:18] <sladen> hughsie: hook hotplug aswell so that when asked for firmware it can fail but pop up a ''you need illegal firmware:   [ ]  This is legal.  Really.   [ OK ]  ''
[06:18] <Keybuk> sladen: s/hotplug/udev/
[06:18] <hughsie> sladen: we need to be careful about the legal side of things
[06:20] <hughsie> can one of you guys knock up a wiki page and post this info pls...
[06:20] <hughsie> i have to be at a meeting in 9 mins.
[06:20] <hughsie> back in a bit
[06:22] <pabs3> hmm, is it just me or are these patches broken? http://people.ubuntu.com/~scott/patches/fonttools/
[06:23] <Keybuk> see topic
[06:23] <Keybuk> snapshot.debian.net threw its disks a while back
[06:23] <pabs3> ah
[06:23] <Keybuk> so sometimes (about 10% of cases now) we can't get the original Debian source package both us and Debian are based on
[06:24] <pabs3> seems to me the same version is the latest in the debian archive
[06:24] <pabs3> http://packages.qa.debian.org/f/fonttools.html
[06:24] <Keybuk> yeah, currently mom doesn't ever look in the debian archive <g>
[06:24] <Keybuk> it's a bit thick
[06:24] <pabs3> ah :)
[06:24] <mvo> ping zyga 
[06:25] <pabs3> also, I noticed, the patches haven't been updated for xchat, which has had 2 new versions in debian
[06:25] <pabs3> how often are updates?
[06:26] <Keybuk> daily
[06:26] <Keybuk> xchat looks like another busted one
[06:27] <mdz> jbailey: are you on top of this ubuntu-docs file conflict?
[06:27] <Keybuk> oh no, maybe it's not
[06:27] <Keybuk>  * Creating xchat_None.patch (2.4.3-0.2 -> 2.4.4-0ubuntu5)
[06:28] <Keybuk> (it only updates when there are ubuntu changes, as it's just a DebianBase->Ubuntu diff)
[06:28] <Keybuk> we froze a couple of months ago, remember
[06:28] <pabs3> ah, right
[06:29] <pabs3> er -#
[06:33] <jdub> hey pablof 
[06:33] <jdub> er
[06:33] <jdub> hey pabs3 
[06:33] <pabs3> hello
[06:36] <sivang> rehi all
[06:36] <bddebian> wb sivang
[06:39] <ivoks> jdub: ping
[06:40] <hughsie> Keybuk: what about adding the support for this session daemon in gnome-power-manager?
[06:40] <hughsie> it's already got all the libnotify, hal stuff that it needs
[06:40] <Keybuk> hmm, I dislike having daemons that do too much
[06:41] <Keybuk> if the legwork to adding that support to a new daemon is a lot -- copy the legwork from g-p-m into a library they both use
[06:41] <jdub> ivoks: pong
[06:41] <ivoks> jdub: i'm interested in planet.ubuntu.com
[06:41] <hughsie> Keybuk: thats the thing, it would only be a small addition
[06:41] <ivoks> jdub: so, if you could tell me what you need, so my blog would showup on planet
[06:41] <Keybuk> would it though?  it could get quite a large addition doing all sorts of cute things
[06:41] <hughsie> it's pros and cons of having a new, seporate daemon
[06:42] <jdub> ivoks: if you're an ubuntu member, send me your rss feed url
[06:42] <Keybuk> I think the way things are going with the new session stuff is to have lots of very small daemons
[06:42] <Keybuk> jdub: correct?
[06:42] <jdub> well, i hope not
[06:43] <jdub> but there is the potential for it :)
[06:43] <Keybuk> or is it one big "do everything" daemon?
[06:43] <hughsie> Keybuk: i don;t think that would be the plan - i thin kwe need middle ground tho
[06:43] <jdub> gnome-session will activate other stuff via d-bus
[06:43] <jdub> D-BUS
[06:43] <ivoks> jdub: i am (i'm motu) url: http://ivoks.blogspot.com/atom.xml
[06:44] <hughsie> jdub: does this actually work now?
[06:45] <Keybuk> jdub: no dude, it's about the D-TRAIN
[06:45] <jdub> hughsie: mostly i believe, check libgnomeservice in gnome cvs
[06:46] <hughsie> jdub: okay, i'll give it a go
[06:46] <jdub> ivoks: is there a full content feed?
[06:47] <ivoks> jdub: yup, that one in 10 seconds :)
[06:47] <jkrogh> Where can I find a list of all metapackages? (for kickstart)
[06:47] <jdub> ivoks: my wife loved zagreb, btw. wants to take me there some time - will have to catch up with you. ;)
[06:47] <ivoks> jdub: sure!
[06:48] <spayne> jdub: you know you're lugradio interview?
[06:48] <ivoks> jdub: when was she in zagreb?
[06:48] <jdub> hmm, couple of years ago maybe
[06:48] <jdub> spayne: yeah
[06:48] <ivoks> nice...
[06:48] <jdub> hrm. must be about three years ago.
[06:48] <spayne> jdub: why did you join #lugradio, say "I hate you guys" and leav?
[06:48] <bddebian> heh
[06:48] <jdub> spayne: haha
[06:49] <jdub> spayne: that was after i heard their intro to the interview
[06:49] <spayne> lol
[06:49] <Kamion> mdz: can we promote palo to main? hppa-only, but I can't build hppa CDs for lamont without it
[06:49] <spayne> jdub: explains a lot
[06:49] <Kamion> well, actually it's built for all architectures for no wonderfully good reason
[06:50] <Kamion> would have to make sure it doesn't end up Priority: required/important, or else just remove it from the other architectures
[06:50] <lamont> Kamion/mdz: libgcc2 is very much in the same boat
[06:50] <lamont> only more so: can't debootstrap without that
[06:50] <elmo> I thought it was made it arch: any so CDs could be made?
[06:50] <elmo> that was the excuse given at the time in Debian anyway
[06:51] <lamont> elmo: it's always been arch-any
[06:51] <elmo> lamont: no it hasn't
[06:51] <lamont> er, for a good long time anyway
[06:51] <elmo> I have a good long memory :P
[06:51] <Kamion> elmo: debian-cd/tools/boot/*/boot-hppa doesn't appear to run palo
[06:51] <elmo> Kamion: ok, it may not be valid anymore
[06:51] <Kamion> the d-i build process might, but that runs on hppa
[06:51] <Kamion> maybe something mad in boot-floppies needed it
[06:51] <lamont> d-i build almost certainly does
[06:52] <Kamion> PALODEB="$($BASEDIR/tools/apt-selection cache show palo | \
[06:52] <Kamion>         sed -n 's/^Filename: \(.*_hppa.deb\)$/\1/p')"
[06:52] <Kamion> ar p "${MIRROR}/${PALODEB}" data.tar.gz | tar xz ./usr/share/palo/iplboot
[06:52] <Kamion> mv usr/share/palo/iplboot $CDROOT/install/iplboot
[06:52] <Kamion> ^-- what debian-cd does
[06:52] <mdz> Kamion: won't that cause it to show up eternally in anastacia?
[06:52] <spayne> jdub: they say waugh like war
[06:52] <Kamion> mdz: not if seeded as 'palo [hppa] '
[06:52] <Kamion> (if anastacia pays attention to ports-arch seeds, I forget)
[06:52] <Kamion> but it's in the exact same boat as silo and elilo
[06:53] <Kamion> apart from the arch: any thing
[06:53] <lamont> if it helps, I have no objection to making palo arch:hppa
[06:53] <jdub> spayne: that is how it's pronounced. the 'whoa-whoa-whoa' stuff comes from a combination of 'war' the song and 'the twelfth man'
[06:53] <lamont> at lease in ubuntu
[06:53] <elmo> Kamion: anastacia currently ignores hppa
[06:53] <mdz> fabbione: now you have an easy X bugfix to upload with your sparc changes ;-)
[06:53] <elmo> but looks at ia64 and sparc
[06:53] <spayne> jdub: in the UK, we say "waugh" wauf
[06:54] <elmo> if hppa is up-to-date enough, we could change that
[06:54] <mdz> elmo: hppa is eternally behind
[06:54] <mbreit> lamont: did you have a look at the scons problem on the buildds?
[06:54] <lamont> elmo: outside of kde being totally &*%), it's at least as current as breezy-autotest
[06:54] <mdz> lamont: every time I regen -meta it is missing things
[06:54] <elmo> ok - well the real solution is to get anastacia telling you when promotions come from a certain arch
[06:55] <jdub> spayne: perhaps in *england* (especially if trying to psyche out the cricketers). :-)
[06:55] <elmo> but that's less trivial than I first thought
[06:55] <lamont> or rather, the breakage that it currently has is trackable to things that are no-longer buildable in breezy main
[06:55] <spayne> jdub: who won again :)
[06:55] <fabbione> mdz: might do tomorrow.. i didn't upload since you didn't answer my request this morning...
[06:55] <mdz> fabbione: I fell asleep
[06:56] <mdz> I had slept about 6 hours total over 2 days
[06:56] <fabbione> mdz: + the code has been changed so much since last time i checked, that i am bit reluctant to touch it
[06:56] <lamont> mdz: libgda2 and libcaca are both FTBFS in current main.
[06:56] <fabbione> mdz: THAT MUCH?!?
[06:56] <elmo> lamont: err, they are?
[06:56] <lamont> and, while present on the other architectures, are not present on hppa.
[06:56] <elmo> I thought infinity fixed libgda2
[06:56] <fabbione> lamont: no.. they have been fixed
[06:56] <mdz> lamont: broken post-autotest?
[06:56] <lamont> ah cool
[06:56] <elmo> has b-at finished yet?
[06:57] <elmo> we should do a main only run now and catch any stragglers
[06:57] <lamont> libgda2 is fixed
[07:00] <lamont> breezy-at has nothing in needs-build
[07:00] <lamont> sounds like time to kick it again
[07:00] <elmo> ok, I'll start that now
[07:01] <lamont> mdz/kamion: I'm also going to kick all the current dep-waits, to clear any outstanding waiting-on-virtual-package issues
[07:02] <elmo> libgcc2 I think counts as obvious
[07:02] <mvo> seb128: apt with updated po/pots uploaded
[07:02] <jdub> BenC, mdz: so is this "my hard drive is slower" stuff supported by any useful evidence yet?
[07:02] <elmo> the anastacia output is all messy again
[07:03] <sivang> jdub: I'm getting weird overall performance since lastest update, may this be related? (GNOME gui responsds also slowly)
[07:03] <seb128> mvo: rock, thanks
[07:03] <mjg59> Is anyone here on a desktop with apm?
[07:03] <lamont> elmo: I know ubuntu-desktop is unininstallable, I'll track down the offending packages
[07:05] <mdz> jdub: http://bugzilla.ubuntu.com/show_bug.cgi?id=15571
[07:07] <jdub> wow, stracing gam_server is intense
[07:07] <jdub> mdz: ta
[07:07] <Keybuk> jdub: strace X ... for ultimate strace pleasure
[07:07] <fabbione> the HD performance thing is crap
[07:07] <segfault> mvo: are those untranslatable strings fixed in apt?
[07:07] <sivang> mjg59: could it be the cpu scaling not working ? No matter what I do , CPU speed won't jump up to 1.8 as it used to do
[07:07] <fabbione> i got much higher performance here with .12 than with .10
[07:07] <sivang> Keybuk: lol
[07:07] <mvo> segfault: should be with this upload
[07:07] <jdub> well, i would be expecting X to be busy most of the time (especially when pushing output of strace!) :-)
[07:08] <segfault> mvo: they will appear in rosetta after some time?
[07:08] <mjg59> sivang: I've no idea
[07:08] <mvo> segfault: yes, the import happens daily AFAIK
[07:08] <mjg59> sivang: What hardware?
[07:08] <segfault> mvo: nice, thanks.
[07:09] <sivang> mhsame old dell laptop inspiron 8200 that you fixed the pakcage for, recall the wrong module loaded that you fixed ?
[07:09] <mjg59> Yeah
[07:10] <sivang> so it is it. And it was beautifully working before, bumping CPU speed to 1.8 on load, and resting at 1.2 in low load
[07:10] <lamont> mdz/elmo: gnome-control-center is d-w libcaca-dev, libcaca is ftbfs.
[07:10] <lamont> that's the root cause of much of the uninstallability for hppa
[07:11] <mdz> lamont: is it hppa-specific, or is there a bug open?
[07:11] <sivang> mjg59: never mind, I got it working. I guess I was not stressing the machine enough
[07:11] <lamont> libcaca_0.9-5ubuntu1_20050914-0029-i386-failed.gz
[07:11] <lamont> libcaca_0.9-5ubuntu1_20050914-0240-amd64-failed.gz
[07:11] <lamont> libcaca_0.9-5ubuntu1_20050914-0501-ia64-failed.gz
[07:11] <lamont> libcaca_0.9-5ubuntu1_20050914-0928-powerpc-failed.gz
[07:11] <lamont> looks pretty general
[07:11] <bddebian> libcaca still cracks me up
[07:12] <lamont> ENOBUG
[07:12] <lamont> fixing that
[07:13] <lamont> gcc  -g -O2 -g -O2 ... -o cacaview -> 
[07:13] <lamont> /usr/lib/libImlib2.so: undefined reference to `XShmDetach'
[07:15] <lamont> now to figure out if it's imlib2, or libcaca
[07:16] <lamont> imlib2-config --libs
[07:16] <lamont> -L/usr/lib -lImlib2 -lfreetype -lz -ldl -lm
[07:16] <lamont> thanks imlib2
[07:18] <Rotund> Lathiat, you here?
[07:19] <jdub> mvo: update-notifier is polling a lot
[07:19] <Keybuk> ubuntu-bugs: 0 unread  \o/
[07:19] <Keybuk> NOBODY BREAK ANYTHING!
[07:19] <mvo> jdub: yes, I can fix that (if gaim is reliable nowdays)
[07:19] <lamont> Keybuk: got a minute?
[07:19] <Keybuk> lamont: sure
[07:20] <Keybuk> evo just hung on a futex again, so I have to restart the fucker
[07:20] <mvo> jdub: it used to be a additonal check to work-around problems in gaim
[07:20] <jdub> gamin? :)
[07:21] <mvo> jdub: err .. right :)
[07:21] <jdub> nm-applet is polling a lot
[07:21] <Rotund> anyone know if a GNOME configuration frontend for Avahi/Zeroconf is being worked on?
[07:22] <jdub> though that's probably on /proc or whatever
[07:22] <dholbach> Rotund: service-discovery-applet is in breezy, if you mean that (avahi)
[07:22] <Rotund> the other end of it.
[07:22] <Rotund> The avahi-daemon side
[07:23] <jdub> elmo: can we drop howl from the archive?
[07:24] <dholbach> Rotund: i have no idea, the avahi source package has around a million binary packages, one of them might be what you're looking for :)
[07:24] <dholbach> Rotund: i have no clue about it :)
[07:24] <Rotund> nope.  there's not one there
[07:24] <dholbach> elmo: and gnome-user-share
[07:24] <Rotund> I'm thinking of doing an "autodetect" wizard that will generate the services available
[07:24] <elmo> jdub: done
[07:24] <jdub> thanks
[07:24] <elmo> dholbach: reasoning?
[07:24] <dholbach> elmo: it depends on libhowl0
[07:25] <fabbione> +r
[07:25] <dholbach> fabbione: bon apptit
[07:25] <fabbione> dholbach: danke
[07:25] <dholbach> :)
[07:26] <kent> dholbach, do you meen to drop gnome-user-share from ubuntu?
[07:26] <elmo> dholbach: ok, done
[07:26] <dholbach> elmo: merci beaucoup
[07:26] <dholbach> kent: yes
[07:26] <Rotund> it would be great to just plug your computer on the network and have it be like "this, this, this, and this are available on your LAN"
[07:26] <dholbach> kent: it depends on howl which has licensing problems
[07:26] <Rotund> like Windows Networking/SAMBA but not shit
[07:26] <mae> y'know, banshee looks fairly promising for the next ubuntu release if they fix some _very_ annoying bugs.
[07:26] <kent> dholbach, ok. 
[07:28] <slomo> mae: they will be fixed... i'm just waiting for a new upstream release which will be there soon
[07:28] <mae> :)
[07:29] <mae> and also, playlists don't keep their order, they enforce column ordering.
[07:29] <mae> It crashed when ripping my cd, and the numbers to the playlists don't get updated properly when dragging songs into it
[07:30] <kent> aah, banshee is in breezy archives. Nice, i didnt think it was there..
[07:39] <spayne> who do i need to talk to about the ubuntu logo?
[07:39] <spayne> i'd like to use it in a T-Shirt
[07:40] <spayne> i have permission for the Mono, Hula logo
[07:40] <spayne> and my business
[07:41] <jdub> spayne: http://www.ubuntu.com/ubuntu/TrademarkPolicy/
[07:41] <spayne> anyone on IRC i can ask?
[07:42] <jdub> that's not the correct process :)
[07:45] <spayne> jdub: i'm emailing now
[07:46] <lamont> mdz: problem located, rest of fix for old bug being tested now
[07:46] <spayne> generally, is it better to use LVM which installing breezy?
[07:46] <bddebian> Anyone know of any issues with _X_SENTINEL ?
[07:46] <bddebian> from Xfuncproto.h ?
[07:49] <lamont> waz broken xorg-transition fix
[07:49] <bddebian> ??
[07:49] <zyga_> hello :-)
[07:49] <bddebian> Hello zyga_
[07:49] <dholbach> bddebian: doesn't including the correct header file fix it?
[07:49] <bddebian> dholbach: Not afaict
[07:50] <zyga_> :-)
[07:50] <lamont> mdz: new imlib2 uploaded.  now a short break, and then I'll file a bug and close it. 
[07:51] <lamont> with a tip of the hat to keybuk (auto*), and jbailey (cdbs) for speeding my walk through the painful mazes
[07:51] <mdz> lamont: the bug filing is superfluous if you're just going to upload the fix immediately thereafter ;-)
[07:52] <bddebian> heh
[07:54] <zyga> who is scott james remnat?
[07:55] <tseng> zyga: Keybuk 
[07:55] <lamont> mdz: wasn't sure if we were tracking old dead bugs or not.
[07:55] <zyga> a wiki page mapping people from IRC to their real names autogenerated from launchpad 
[07:59] <tseng> im not sure i enjoy that
[08:02] <elvirolo> hi all
[08:02] <elvirolo> i am encountering a critical bug : http://bugzilla.ubuntu.com/show_bug.cgi?id=16066
[08:03] <mdz> dholbach: talk to me about gnome-bluetooth
[08:04] <bddebian> Which seb* is Seb Payne?
[08:04] <mdz> elvirolo: the development team receives automated notification of bugs filed in Bugzilla; there is no need to repeat the report here
[08:04] <jdub> mdz: thought -> gnome-bluetooth binary needn't be in main, just libgnomebt0{,-dev}
[08:04] <mdz> jdub: isn't that built from gnome-bluetooth?
[08:04] <jdub> source, yes
[08:05] <elvirolo> mdz: yeah i know ... I was just wondering if anyone knew whether is was going to be fixed or not
[08:05] <mdz> jdub: is it ready for an ubuntu release?
[08:06] <jdub> 0.5 has had quite a bit of testing in the real world
[08:06] <jdub> 0.6 dramatically less so
[08:06] <mdz> elvirolo: of the 16,000 bugs filed before it, about 12,000 have since been fixed, so the odds are in your favour
[08:07] <jdub> i would support the inclusion of libgnomebt0 specifically for the benefit of nautilus-sendto
[08:07] <elvirolo> ok...
[08:07] <jdub> but happy to see gnome-bluetooth binary in universe
[08:07] <mdz> jdub: and a cvs snapshot from early december probably even less so? ;-)
[08:07] <jdub> mdz: that's 0.6, you see. much drama. :)
[08:08] <mdz> jdub: I try to avoid mixing binaries that way wherever possible; it creates awkward support situations
[08:08] <dholbach> jdub: then you'd be able to send files to bluetooth stuff, but not to receive it (gnome-obex-server)
[08:08] <mdz> jdub: e.g., if someone wants to fix the package in universe, we actually need to touch main
[08:08] <mdz> dholbach: is nautilus-sendto useful without the bluetooth functionality?
[08:08] <dholbach> i'd really love to see it available for the masses, and my tests with my 3 devices have been fine so far, but i'm not sure how good that works in main
[08:09] <jdub> mdz: it is, but it won't do bluetooth.
[08:09] <dholbach> mdz: yes, i tested it yesterday, it even found a blackberry device in the flat below mine :-p
[08:09] <mdz> jdub: sounds like a lack-of-feature more than a bug
[08:09] <bddebian> dholbach: Hey, fix that bluetooth-gnome pixmap bug on Malone!! ;-P
[08:10] <jdub> mdz: (ok, then i'd revise -> libgnomebt0 in desktop, gnome-bluetooth in supported)
[08:10] <mdz> dholbach: so it worked well for you?
[08:10] <dholbach> all i can say is that the test with my 3 devices has been fine and it's a COOL feature
[08:10] <jdub> mdz: it is a bug for our bluetooth goal :-)
[08:10] <mdz> very few of us seem to have bluetooth devices; it's quite difficult for us to support that functionality
[08:10] <dholbach> but i can't tell how broken it is for the world
[08:10] <jdub> works fine with three different devices i've tested
[08:10] <jdub> including the treo 650 (pipka has the same phone as sabdfl)
[08:11] <mdz> dholbach: has pitti reviewed the report?
[08:11] <jdub> 0.5 has been very widely tested
[08:11] <ogra> mdz, nobody has put it on the queue :(
[08:11] <dholbach> mdz: charles wrote it, but it wasn't linked on InclusionQueue
[08:11] <jdub> s/tested/used/
[08:11] <mdz> jdub: isn't that inconvenient, for them to share a phone while living on different continents?
[08:11] <dholbach> i just linked it there
[08:11] <dholbach> mdz: :)
[08:11] <jdub> mdz: sabdfl seems to enjoy it.
[08:12] <mdz> one of these days I will call sabdfl and pipka will answer instead
[08:12] <dholbach> chmj: how good were your tests with gnome-bluetooth?
[08:12] <dholbach> so we have at least 3 people who tested it :)
[08:13] <jdub> we'd have to include gnome-bluetooth binary if we wanted gnome-obex-server (which lets you send files to your ubuntu machine)
[08:13] <ogra> *his
[08:13] <mdz> if we were to add this to desktop and discover in a few weeks that it causes some weird nautilus crash, I would be unhappy about that
[08:13] <jdub> but i don't think we should bother with that for now
[08:13] <jdub> mdz: nautilus-sendto only runs when you context-click and choose "send to..."
[08:13] <mdz> jdub: oh, it's an external program and not a plugin?
[08:13] <jdub> so it won't crash nautilus :-)
[08:13] <jdub> yeah, the bt bit is a plugin for a separate nautilus-sendto binary
[08:13] <dholbach> mdz: until pitti has reviewed it, i'll do some more testing
[08:14] <ogra> me too
[08:14] <ogra> dholbach, can you prepare a sendto binary for amd64 and upload it anywhere 
[08:14] <mdz> dholbach: this is pretty clearly pre-featurefreeze stuff to me
[08:14] <dholbach> it's much more mature than gnome-phone-manager (which would be cool for the Bluetooth goal, if it worked more instantly)
[08:14] <dholbach> ogra: yes
[08:15] <dholbach> mdz: i'm sorry, as you know, i was a bit busy before featurefreeze
[08:15] <dholbach> (i know you all were)
[08:15] <jdub> ah, meanwhile, nautilus-sendto is crashing on startup for me (no bt bits involved)
[08:15] <ogra> dholbach, thanks, even if it probably wont be accepted, testing is alwys fine i think
[08:15] <mdz> dholbach: I'm not blaming you; it's simply  quite late to consider it
[08:15] <dholbach> yeah
[08:16] <mdz> 16 days to final release
[08:16] <jdub> mdz: "hey sabdfl, you can send files to your palm now"
[08:16] <mdz> jdub: don't you dare
[08:16] <jdub> ha ha
[08:17] <mdz> dholbach: this doesn't require any seed changes, right?
[08:17] <mdz> so if it causes problems, it can be reverted by only touching nautilus-sendto?
[08:17] <dholbach> mdz: we'd at least need libgnomebt*
[08:17] <mdz> dholbach: right, but those would be pulled in by a dependency and not seeded
[08:18] <mdz> i.e., no metapackage transition required
[08:18] <dholbach> yeah, afaik that'd be it
[08:19] <jdub> yep
[08:20] <dholbach> *grmbl*
[08:21] <lamont> mdz: once I get hppa really caught up (thanks libcaca), I may want to see about one last ubuntu-meta upload to flesh out ubuntu-* packages there
[08:21] <lamont> mdz: and it sounded like once it's semi-clean, anastasia could look at hppa as well as ia64/sparc, yes?
[08:27] <mdz> lamont: we'll see how it looks first, but yeah
[08:28] <ogra> jdub, do you remember if gsf-sharp was also for searching MS Word docs with beagle ? 
[08:28] <tseng> i dont think so dude
[08:29] <ogra> hmm
[08:29] <jdub> yeah, you need gsf
[08:29] <jdub> but you also need an old version of wv
[08:29] <ogra> not wv2 ?
[08:29] <jdub> (gsf handles the ole storage format)
[08:29] <tseng> bongness
[08:29] <ogra> we're just discussing malone #1859 in -motu
[08:30] <tseng> like i said in MOTU, i dont care about any of that MS crap
[08:30] <jdub> not wv2
[08:30] <ogra> bah
[08:30] <tseng> as soon as someone else tests it ill include their patch
[08:32] <bddebian> Does Debian include wv support in beagle?
[08:32] <jdub> doubt it
[08:32] <tseng> doubt it also, but looking
[08:32] <jdub> libwv1 doesn't exist
[08:32] <bddebian> I know :-(
[08:32] <tseng> they dont include wv or gsf
[08:32] <tseng> and neither do we
[08:32] <bddebian> SO I'm going to just reject the bug?
[08:33] <tseng> you can do whatever you like with the bug, given that im not fixing it :P
[08:33] <jdub> tseng: we have libgsf-cil
[08:33] <tseng> jdub: we do
[08:33] <jdub> bddebian: no, it should be fixed
[08:33] <bddebian> OK
[08:34] <jdub> either by fixing their wv usage or sorting out wv1's needs
[08:34] <bddebian> And we know libwv2-dev won't fix?
[08:34] <jdub> don't believe so
[08:34] <tseng> im not sure who wrote that code
[08:41] <mdz> aieee
[08:41] <mdz> I turn my back for a moment and anastacia output explodes again
[08:42] <mdz> Riddell: this kde-guidance stuff has a load of new deps which have no main reports
[08:42] <mdz> Riddell: http://people.ubuntu.com/~mdz/anastacia.txt
[08:48] <tseng> spreadubuntu.org should have had the original warty artwork along with their slogan
[08:49] <tseng> the toupe is lacking sex appeal
[08:50] <elmo> lamont: what's my IA64 system type?
[08:50] <elmo> I guess "HP-zx1/sx1000 (IA64_HP_ZX1)"?
[08:51] <lamont> elmo: I think so... what's the machine?>
[08:51] <lamont> one of the zx2000's?
[08:51] <lamont> --> zx1
[08:51] <elmo> rx1600
[08:52] <lamont> pretty sure that'd be zx1
[08:52] <elmo> ok, thanks
[08:52] <lamont> elmo: double checking and all that, but I expect that's right
[08:52] <lamont> elmo: confirmed.
[08:53] <elmo> cool, thanks
[08:54] <\sh> hmmm...
[08:55] <\sh> anybody has experience if a dlink usb wifi dongle works with the actual linux kernel? *surprise*
[08:55] <lamont> elmo: I want a gnupg patch so I can say 'default key is XX if it exists, otherwise use YY'.  kthxbye
[08:56] <\sh> Bus 004 Device 004: ID 2001:3c00 D-Link Corp. [hex] 
[08:56] <\sh> aa
[08:57] <Seveas> lamont, that should be easy to fix in a wrapper script ;)
[09:05] <jbailey> mdz: Hey just trying to track down where that ubuntu-faqguide came from.  I don't have it on any of my systems here (new installs and upgrades from Hoary), and people in the #u-docs channel don't seem to know it either.
[09:06] <jbailey> mdz: If don't know, no worries.  I'll just conflict/replaces it to clear the problem for now.
[09:06] <ogra> its a rewrite of ubuntuguide afaik....
[09:07] <ogra> jsgotangco spoke about it recently
[09:07] <jbailey> Right, and I include it in ubuntu-docs.
[09:07] <mdz> ubuntu-docs used to build ubuntu-faqguide, iirc
[09:07] <jbailey> But Matt filed 16465 about it conflcting with an ubuntu-faqguide package.
[09:08] <ogra> wasnt that called quickguide before ? 
[09:08] <jbailey> mdz: Do you know in what release timeframe I should look?
[09:08] <zyga> hey did anyone read about the new smalish laptop-palmtop-hybrid on ./?
[09:09] <zyga> the thing is: the company also semi-supports ubuntu on this thing: it's not officially supported but they have gone to great lenghts to get everything working
[09:09] <zyga> ftp://ftp.oqo.com/unsupported/linux/OQOLinux.html
[09:09] <zyga> check this out
[09:09] <jbailey> OQO...
[09:09] <zyga> wifi, sleep, touchscreen everything
[09:09] <jbailey> I think that's the device Kamion filed a bug on.
[09:09] <zyga> jbailey: oh, in bugzilla?
[09:09] <Keybuk> zyga: were you looking for me?
[09:09] <jdub> yes, openadvantage provided some hardware to test with
[09:10] <jbailey> zyga: http://bugzilla.ubuntu.com/show_bug.cgi?id=9092
[09:10] <mdz> jbailey: I don't know that it was ever in a release
[09:10] <mdz> jbailey: just add a conflicts/replaces please
[09:10] <zyga> Keybuk: not really, I just wanted to associate the person assigned to that bug to anyone here
[09:10] <jbailey> mdz: will do, thanks. =)
[09:10] <Keybuk> zyga: which bug?
[09:11] <Keybuk> #16433 ?
[09:11] <zyga> Keybuk: hdparm 
[09:11] <zyga> yes
[09:11] <Keybuk> yeah I kinda more mean "why hdparm is trying to do things to a cloop filesystem"
[09:12] <zyga> Keybuk: what I want to know is why the hell does it touch /dev/hdc when I mount cloop 
[09:12] <zyga> (that has nothing to do with it)
[09:12] <Keybuk> indeed
[09:12] <jdong> \sh: which dongle?
[09:12] <jdong> \sh: DWL-G122's all work with Ubuntu to some degree with OSS drivers
[09:12] <zyga> Keybuk: are you 100% sure it's not udev event problem? I still think that hdparm is buggy maybe but it shouldn't get called on /dev/hdc
[09:13] <\sh> jdong: which driver must be loaded? I can see the dongle in lsusb but no other recognition...so no wifi device is showing up
[09:13] <zyga> jbailey: call the marketing people to convince OQO to get fully supported device and special kernels in universe
[09:13] <Keybuk> zyga: reasonably sure, if there were a uevent problem it would show up in all sorts of other ways too
[09:13] <zyga> Keybuk: does that mean that udev will re-configure all block devices on any mount?
[09:14] <rebort> can someone lease take a look at ug 16479
[09:14] <Keybuk> zyga: no, I think what's happening is udev is handling the /dev/loop0 event and the hdparm handler in /etc/dev.d/block is getting things wrong and running hdparm on everything
[09:14] <rebort> my b, f and p keys do not work (the keyoard shortcuts dialog sees them as
[09:14] <rebort> X86AudioNext, X86Audiorev and X86Audiolay, resectively)
[09:15] <zyga> Keybuk: /dev/cloop0 that is
[09:15] <Keybuk> unless you have any evidence that udev is getting events for each thing?
[09:15] <tseng> BenM: yo
[09:15] <BenM> hey guys, i've been trying to customize a pxeboot setup
[09:15] <zyga> Keybuk: what calls those scripts, they have some environment pre-defined as it seems
[09:15] <BenM> hey ts
[09:15] <BenM> i want to install cmu-desktop, rather than ubuntu desktop
[09:15] <Keybuk> zyga: the kernel
[09:15] <BenM> but i can't figure out how to get that in the preseed
[09:15] <zyga> Keybuk: hmm
[09:15] <jbailey> zyga: I don't have one.  It's just that I came across the bug last  night when I was trolling for initrd/initramfs bugs that hadn't been assigned to me.
[09:15] <BenM> http://omega.res.cmu.edu/~benm/ubuntu/preseed
[09:16] <BenM> is that i have so far
[09:16] <Keybuk> zyga: can you download http://people.ubuntu.com/~scott/udev_log_event -- make it executable then write the full path of it to /proc/sys/kernel/hotplug
[09:16] <zyga> Keybuk: sure
[09:16] <BenM> base-config  package-selection string ~tubuntu-standard|~tubuntu-desktop|~tcmu-desktop was my first attempt
[09:16] <Keybuk> ie sudo sh -c "echo $(pwd)/udev_log_event > /proc/sys/kernel/hotplug"
[09:16] <BenM> but did not work at all
[09:16] <dholbach> erm... does anybody know why the test-rebuild got restarted and there are no logs left?
[09:17] <zyga> Keybuk: done
[09:17] <zyga> Keybuk: I'll mount the cloop now, one moment - my laptop might die at this
[09:17] <Keybuk> zyga: ok, now (with the bad bits of your hdparm script commented out so your machine doesn't go bang) can you mount your filesystem
[09:18] <zyga> Keybuk: I reverted that patch
[09:18] <zyga> Keybuk: I'll apply it again if that's not relevant 
[09:18] <Keybuk> yeah, just want to see what udev is doing
[09:21] <zyga> Keybuk: okay http://www.suxx.pl/udev.log
[09:21] <zyga> Keybuk: no /dev/hdc that's for sure
[09:22] <Keybuk> hmm, a whole bunch of loops though
[09:22] <Keybuk> maybe that's just the module preparing them
[09:22] <Keybuk> ah
[09:22] <zyga> Keybuk: note that this is for modprobe cloop && mount && umount && rmmod cloop
[09:22] <Keybuk> yeah, that'll be the module loading causing the /dev/loopN
[09:23] <Keybuk> ok, that's what I'd expect to see
[09:23] <zyga> nice, it shows my nfs mounted webserver :)
[09:23] <Keybuk> could you attach that log file to the bug with a comment like "what udev is doing"
[09:23] <zyga> sure
[09:24] <Keybuk> then edit (as root) /etc/dev.d/block/hdparm.dev
[09:24] <Keybuk> and at the top (just after the #!/bin/sh) put
[09:24] <Keybuk> exec 2>/tmp/hdparm.log
[09:24] <Keybuk> set -x
[09:24] <Keybuk> echo "$@" 1>&2
[09:24] <Keybuk> env 1>&2
[09:25] <Keybuk> (end)
[09:25] <zyga> Keybuk: one moment, log addeed to bugzilla
[09:26] <mdz> is anyone with debugging skills able to reproduce this hard drive performance issue? (http://bugzilla.ubuntu.com/show_bug.cgi?id=15571)
[09:27] <zyga> Keybuk: done, checking again
[09:28] <rebort> has anyone heard o anyone else with the keyoard issue (#16479)
[09:28] <zyga> Keybuk: http://www.suxx.pl/hdparm.log
[09:28] <Keybuk> attach that one to the bug too
[09:28] <zyga> k
[09:28] <Keybuk> actually, wait
[09:29] <Keybuk> you need to boot without "nohdparm" :p
[09:29] <Keybuk> I actually want to see what it's doing
[09:29] <zyga> Keybuk: done
[09:29] <zyga> Keybuk: I did
[09:29] <Keybuk> + grep -w -q nohdparm /proc/cmdline
[09:29] <zyga> Keybuk: I was at work and I power cycled my laptop :)
[09:29] <Keybuk> hmm
[09:30] <Keybuk> oh, sorry
[09:30] <zyga> Keybuk: empty line, $? == 1
[09:30] <Keybuk> can you change that exec 2>/tmp/hdparm.log  line to exec 2>>/tmp/hdparm.log
[09:30] <zyga> Keybuk: sure
[09:31] <zyga> done
[09:31] <Keybuk> (this is totally poor man's debugging, but hey)
[09:31] <chmj> OTE:	the daemon does not 'daemonize' actually, this makes debug output available on the console
[09:31] <Keybuk> got the updated file?
[09:32] <zyga> Keybuk: not yet, one moment
[09:33] <zyga> Keybuk: now it's longish, check the URL above
[09:33] <Keybuk> no /dev/hdc in sight
[09:33] <Keybuk> definitely hdparm playing silly buggers, not udev
[09:34] <zyga> Keybuk: but wait
[09:34] <zyga> Keybuk: check the log I attached to the bugzilla
[09:34] <Keybuk> which one?
[09:34] <zyga> Keybuk: the first one, hdparm *is* called with -q /dev/hdc
[09:34] <Keybuk> yup
[09:34] <zyga> so that's not hdparm on it's own
[09:34] <Keybuk> I think this hdparm dev.d script is calling hdparm like that
[09:35] <zyga> $DISK is broken in that script
[09:35] <Keybuk> it parses hdparm.conf in shell, and I think it just runs hdparm for each thing it finds in that conf file
[09:35] <Keybuk> yeah
[09:35] <zyga> for some reason it gets /dev/hdc from my hdparm.conf
[09:35] <zyga> Keybuk: it seems to be doing that though
[09:36] <zyga> Keybuk: really dumb, lots of loop stuff being cycled makes this thing go wild
[09:36] <Keybuk> basically it parses hdparm.conf and does whatever it says
[09:36] <Keybuk> every single time
[09:36] <zyga> Keybuk: default hdparm does nothing
[09:36] <Keybuk> it looks like someone just grabbed the boot-time init script and tried to write it
[09:37] <Keybuk> of course, why hdparm'ing your existing drive with the same settings crashes your machine is another matter
[09:37] <zyga> Keybuk: it does not crash immediatly
[09:37] <zyga> Keybuk: it simply eats the whole cpu in some kernel time... mumbo-jumbo
[09:37] <Keybuk> ...I wonder whether it's doing multiple hdparm at the same time on the same machine
[09:37] <Keybuk> on the same drive
[09:37] <zyga> Keybuk: none of the hdparm processes want to die
[09:37] <Keybuk> that'd be a bit freaky
[09:38] <zyga> Keybuk: it does basically
[09:38] <Keybuk> sweeeet
[09:38] <zyga> Keybuk: for each loop event it spawns a hdparm -whateve /dev/hda 
[09:38] <Keybuk> yup
[09:38] <zyga> and hdparm -whatever /dev/hdc
[09:38] <zyga> so that's 40 hdparm's at the same time, one after another
[09:38] <Keybuk> so when you modprobe loop, the 8 block events that get generated all cause that command to be run
[09:38] <Keybuk> all at the same time
[09:38] <Keybuk> all on the same drive
[09:38] <zyga> okay 8*4 not 10
[09:38] <zyga> yes
[09:38] <Keybuk> cute
[09:39] <zyga> could someone patch that mess into oblivion?
[09:39] <Keybuk> yeah
[09:39] <zyga> I'd love to help but I'm not really sure what that thing is supposed to do?
[09:39] <Keybuk> me neither
[09:40] <Keybuk> like I say, I think someone copied the init script
[09:40] <Keybuk> hdparm upstream doesn't have a conffile
[09:40] <Keybuk> and that's trying to make one using shell
[09:40] <Riddell> mdz: the dependencies are pyqt/pykde which has been in main before, but I can write main reports if that's helpful
[09:40] <sivang> Keybuk: do you know anything about cupsd ?
[09:40] <Treenaks> Keybuk: sound scary
[09:41] <Treenaks> Keybuk: btw, I supplied the PNP ID mess for the Thinkpad 380ED
[09:41] <zyga> Keybuk: are those udev scripts required to use bash? 
[09:41] <zyga> Keybuk: I have trivial but working and compleate hdparm.conf parser in a dozen python lines
[09:41] <Keybuk> hmm, ok, so the Debian package has changed quite a bit
[09:42] <zyga> s/compleate/complete/
[09:42] <Keybuk> zyga: I wouldn't want to start python up in a udev event
[09:42] <Keybuk> that WOULD kill your machine :p
[09:43] <zyga> Keybuk: hmm, python is faster on startup than bash IMHO, and it is really faster when someone tries to write a parser in it ;-)
[09:46] <Keybuk> and dude, Python is _huge_
[09:46] <Keybuk> and almost certainly not already in memory at that point
[09:47] <zyga> Keybuk: true
[09:47] <zyga> Keybuk: shell parser is still insane IMHO
[09:47] <Keybuk> well, yes, that script is insane
[09:47] <Keybuk> the "new" version in Debian doesn't look much better *sigh*
[09:48] <zyga> Keybuk: still - better a bloated python + gtk gui and progress bar that *works* than a sleek, low-footpring while true; updatedb; done in bash
[09:48] <zyga> s/footpring/footprint/
[09:50] <Keybuk> right
[09:50] <Keybuk> I can see what this is trying to do
[09:50] <Keybuk> and it's just getting it very highly wrong
[09:50] <zyga> Keybuk: I guess it tries to know what hdparm stuff to call associated with the event
[09:51] <zyga> Keybuk: but instead it just calls everything, right?
[09:52] <Keybuk> zyga: could you try replacing it with http://people.ubuntu.com/~scott/hdparm.dev
[09:52] <Keybuk> remove /tmp/hdparm.log
[09:52] <Keybuk> and try again
[09:53] <sivang> does anybody know if pitti should come back ?
[09:53] <zyga> Keybuk: sure
[09:55] <zyga> Keybuk: I've noticed - you have leaved hdparm stuff around, are you sure?
[09:56] <ogra> sivang, i doubt it
[09:56] <Keybuk> you can comment out the actual call if you like
[09:56] <Keybuk> stick an "echo woo" in there or something
[09:56] <Kamion> BenM: drop the ~t before cmu-desktop; ~t installs a task (based on Task: headers in the Packages file) rather than a metapackage
[09:56] <zyga> Keybuk: an echo $REST_OF_THAT_LINE would be more useful
[09:56] <Keybuk> true
[09:57] <Keybuk> and no doubt somebody will name their new toy version control system "woo" and use up yet another metasyntactic variable
[09:57] <Keybuk> ogra: serves you right
[09:57] <ogra> :-'/
[09:58] <Keybuk> mdz: I've got testing that on my todo list, as I think I've noticed it too
[09:58] <Keybuk> mdz: but I'm doing something with baz right now, so I don't think it'd be a fair test <g>
[09:58] <sivang> ogra: ok, was just wondering. I needed him for some cupsd stuff
[09:58] <zyga> Keybuk: okay, it looks better this time
[09:58] <Keybuk> zyga: got the log?
[09:58] <zyga> www.suxx.pl/hdparm.log.1
[09:59] <zyga> .0 if from previous iterationg
[09:59] <zyga> s/g$//
[09:59] <Keybuk> ok, other than my inability to write shell, that looks fixed
[10:00] <mpt> ogra: Why aren't you just ignoring them until after Breezy?
[10:00] <ogra> mpt, i do... 
[10:00] <zyga> Keybuk: hmm, it still gets called multiple times though
[10:00] <Keybuk> it will only call hdparm for the block device being created
[10:00] <Keybuk> I can only see once?
[10:00] <ogra> its just schocking me every time until i figure that its not xcsrensaver the bug is for :)
[10:00] <Keybuk> that script gets called, but it does nothing
[10:01] <zyga> Keybuk: + '[' /dev/hdc = '/dev/cloop6] '
[10:01] <zyga> /etc/dev.d/block/hdparm.dev: line 175: [: missing `] '
[10:01] <Keybuk> yeah, see my comment about my inability to write shell :p
[10:01] <Keybuk> but that's ok
[10:01] <zyga> :-)
[10:01] <Keybuk> so it'll only run hdparm for the block device being plugged 
[10:02] <Keybuk> if you were to stick /dev/loop0 in your hdparm.conf, it would run that
[10:02] <zyga> Keybuk: I've fixed and improved the script
[10:02] <Keybuk> what did you change?
[10:03] <zyga> Keybuk: just less [ ]  and more bash
[10:03] <Keybuk> hmm?
[10:03] <Keybuk> it's /bin/sh not bash
[10:04] <Keybuk> -a is not portable, or even remotely reliable
[10:04] <zyga> Keybuk: hmm
[10:04] <zyga> Keybuk: that's what I've changed
[10:04] <zyga> -a is not reliable
[10:04] <zyga> yet another reason to rewrite this mess in python
[10:04] <Keybuk> [ ... -a ... ]  is bad, use [ ... ]  && [ ... ] 
[10:04] <zyga> Keybuk: where does it fail?
[10:04] <Keybuk> each shell has a different precedence for it
[10:04] <Keybuk> so you can't actually rely on it
[10:04] <zyga> ...
[10:05] <zyga> or in C even
[10:05] <Keybuk> well, yes, clearly this script is worng
[10:05] <zyga> Keybuk: I'll try to hack it a little
[10:05] <Keybuk> but only a few weeks from release, I want to make the minimum change possible to make it work, and then look at it with suspicion for dapper
[10:10] <Keybuk> what you want to have is a program that can parse the hdparm.conf and run hdparm with the right set of a rules for a single given drive
[10:10] <zyga> Keybuk: yes, release is really soon now
[10:10] <zyga> Keybuk: hmm
[10:10] <zyga> Keybuk: that's more less 15 lines in .py
[10:10] <Keybuk> and then have SUBSYSTEM=="block", RUN+="/sbin/hdparm_block_device"
[10:10] <Keybuk> get python out of your head
[10:10] <Keybuk> 1) python is in /usr
[10:10] <Keybuk> 2) it's big
[10:10] <Keybuk> 3) it's slow
[10:10] <Keybuk> 4) these happen a LOT
[10:10] <zyga> Keybuk: hmm
[10:10] <zyga> Keybuk: okay so a C program could be hacked to do just that
[10:11] <Keybuk> writing something in Python that runs when the block device that _contains_ the Python interpreter is first discovered... bad :p
[10:11] <zyga> Keybuk: with bison flex it's easy but do you want it for breezy or dapper/
[10:11] <zyga> :D
[10:11] <Keybuk> dapper
[10:11] <Keybuk> very very dapper
[10:11] <zyga> Keybuk: I'd love to have /bin/mini_python
[10:11] <zyga> Keybuk: without any external modules
[10:12] <zyga> Keybuk: only os module and maybe re module built in
[10:12] <Keybuk> sys? :p
[10:12] <Keybuk> ugh, no re
[10:12] <zyga> I'm still confused about python module naming but you get the idea
[10:12] <zyga> re is usefull and python has separate prce anyway
[10:12] <zyga> pcre
[10:13] <Kamion> so stuff would randomly behave differently because the compiler options for /bin/mini_python and /usr/bin/python would get out of sync; yay
[10:13] <Kamion> (it *would* happen)
[10:13] <zyga> yay
[10:14] <zyga> now we know that -a gets interpreted differently and it's even slower than python as it spawsn a sub-process to read a one-line file
[10:14] <zyga> I do agree with your points
[10:14] <Kamion> && is simpler anyway
[10:14] <zyga> I just say that python --- or anything else that is 1) more efficient than bash/sh 2) portable and does not have 10 different implementations 3) a real language
[10:15] <Keybuk> zyga: Python code that does "import re" should begin "#!/usr/bin/perl"
[10:15] <zyga> Keybuk: python is chmod -r+w
[10:15] <zyga> s/python/perl/
[10:15] <zyga> I know perl but I still think that
[10:15] <Keybuk> so is some people's Python
[10:15] <Keybuk> especially when they do anything involving it's evil re system, which isn't even compatible with the rest of the world
[10:15] <zyga> I used to maitain old invoice database managed by gigantic longish perl script
[10:16] <zyga> Keybuk: why is re evil?
[10:16] <Keybuk> it's slow, not actually compatible to any other re engine
[10:16] <zyga> Keybuk: okay
[10:16] <Keybuk> if you're thinking in re's, you may as well use the interpreter with the fastest re engine in the known universe
[10:17] <Keybuk> I've seen Python code that imports re, compiles a regular expression object, then matches it against a string
[10:17] <Keybuk> to see whether the line contains an "="
[10:17] <Keybuk> the Pythonic way to to that is just if "=" in line:
[10:17] <zyga> Keybuk: I don't really thing in re's, but they are usefull nontheless (if that's a word)
[10:17] <zyga> :-)
[10:18] <zyga> s/thing/think/
[10:18] <Kamion> gigantic long perl scripts are unreadable, but so are gigantic long python scripts or gigantic long functions in C
[10:18] <zyga> geez I'm tired today ;-)
[10:18] <zyga> Kamion: true 
[10:18] <Keybuk> also I don't generally find Python a good language for writing *short* scripts in
[10:18] <zyga> but I'd say that
[10:18] <zyga> [ `cat *.c | wc -l` -gt `cat *.py *.pl | wc -l`  ] 
[10:19] <Keybuk> a short script that has to read a file, parse it and do something tends to be more complicated in Python than just about anything else
[10:19] <Kamion> zyga: your shell quoting habits need work, too ;-)
[10:19] <zyga> Keybuk: I'm not saying python is perfect
[10:19] <zyga> Keybuk: sheesh ;] 
[10:19] <zyga> Keybuk: see what I mean ;-)
[10:19] <Keybuk> zyga: not to mention that's a contendor for a double-wammy "useless use of cat" award
[10:20] <zyga> num_lines_in(file_list_from_glob("*.c") < num_lines_in(file_list_from_glob("*.py|*.pl"))
[10:20] <zyga> ;-))
[10:20] <zyga> Keybuk: actually cat is needed
[10:20] <Keybuk> [ $(wc -l *.c) -gt $(wc -l *.py *.pl) ] 
[10:20] <zyga> Keybuk: so that wc doesn't spit out stats for all the files
[10:20] <zyga> unless there is --summary or something
[10:20] <Keybuk> can't remember, tbh
[10:21] <Keybuk> btw, the shell is winning
[10:21] <zyga> heheh
[10:21] <Keybuk> that Python is evil
[10:21] <zyga> Keybuk: why?
[10:21] <Keybuk> not to mention missing a few imports ?
[10:21] <zyga> Keybuk: bah ;-)
[10:21] <Keybuk> where's num_lines_in and file_list_from_glob defined ?
[10:21] <Keybuk> c'mon, write the script PROPERLY
[10:21] <zyga> Keybuk: len(file(pathname))
[10:21] <Keybuk> right
[10:21] <zyga> Keybuk: and as for glob that's a diferent story
[10:22] <zyga> Keybuk: I'd say that 
[10:22] <zyga> 1) a small API for talking to files and doing simple stuff with them
[10:23] <Keybuk> http://people.ubuntu.com/~scott/pythonic
[10:23] <Keybuk> there
[10:23] <Keybuk> the actual equivalent Python was so long I couldn't paste it and had to put it online somewhere
[10:23] <zyga> 2) a consistent language, without any quoting problems and stuff that vary from .sh to .sh
[10:24] <Keybuk> shell has 1
[10:24] <Keybuk> and provided you stick to portable shell, 2 is true too
[10:24] <zyga> but does not have 2
[10:24] <zyga> hmm
[10:24] <zyga> portable shell has very small 1
[10:24] <Keybuk> otherwise I'll start picking on Python's incredibly bad compatibility between versions
[10:24] <zyga> Keybuk: maybe slang or something else then
[10:24] <Keybuk> "what do you mean, this won't run on Python 2.3?!"
[10:24] <Kamion> most languages have implementation-defined features; there are a bazillion of those in python
[10:25] <Kamion> shell is fine as long as you actually know how to write it
[10:25] <Kamion> (which depressingly few people do, but anyhow)
[10:25] <zyga> Keybuk: then I don't
[10:25] <zyga> and I know C - I think that sucks on the shell side IMHO
[10:25] <Kamion> and python certainly has quoting problems, for example if you pick the wrong way to invoke external processes
[10:25] <Kamion> you can pick the right way, but you can do that in shell too :-)
[10:25] <zyga> I think you are biased a little
[10:26] <Kamion> the lesson is, pick the right tool for the job, rather than clinging desperately to the hammer when trying to drive in screws
[10:26] <zyga> you seem to know your way around sh compatibility issues
[10:26] <Kamion> zyga: nope, I write python when it's appropriate
[10:26] <Keybuk> Kamion++
[10:26] <bddebian> hehe
[10:26] <zyga> and that does not frigten you :-)
[10:26] <Keybuk> Python is my favourite hammer by far
[10:26] <Kamion> I certainly tend to avoid languages where I'm aware that I don't know how to use them safely; I'd hope that applies to most people
[10:26] <Kamion> all I'm saying is, shell still has its appropriate niches
[10:27] <zyga> Kamion: and I agree
[10:27] <zyga> Kamion: and all I'm saying that is has some issues - especially the learning curve to get things right
[10:28] <Keybuk> Kamion: python also has encoding problems...  it's unicode strings are like STIs; someone innocently gives you one and suddenly everything's infected and basic things become painful
[10:28] <zyga> Kamion: I dont want to give you the impression that python has none IMHO, I just think that it has less 
[10:28] <zyga> Keybuk: yes - that sucks alot
[10:28] <Kamion> you might find http://www.greenend.org.uk/rjk/2001/04/shell.html a useful article on avoiding common shell mistakes
[10:28] <Kamion> written by a friend of mine
[10:35] <zyga> Kamion: interesting
[10:35] <sivang> Kamion: that's a keeper :)
[10:36] <zyga> I know most of that stuff really, one interesting thing for me was how to do for I in *.foo; ... done; properly
[10:36] <zyga> I still think that sh is a minefield
[10:37] <zyga> I especially like old scripts 
[10:37] <zyga> mostly written in csh
[10:37] <Keybuk> csh isn't sh
[10:37] <sivang> maybe someone can help me, I am SIGHUPing cupsd. now accoridng to the code, it should do a configuration reload in response, all I get is "Termination successful", what am I doing wrong?
[10:37] <zyga> that come along with old comercial programs 
[10:37] <zyga> ;)
[10:37] <Keybuk> they're totally different languages
[10:37] <zyga> I know :)
[10:37] <zyga> they have lots of lots of checks to work on many then-popular systems
[10:37] <Keybuk> sivang: cups doesn't handle SIGHUP
[10:37] <elmo> infinity: ?
[10:37] <Keybuk> so it will just terminate
[10:38] <Keybuk> I came across that one last year
[10:38] <zyga> sivang: I've seen someone complain recently that cups dies on sighup
[10:38] <sivang> Keybuk: I see, but it has sighup_handler there , guess it does nothing but shut down
[10:38] <Keybuk> can't remember, I think that only got enabled for debugging or something
[10:39] <sivang> Keybuk: hmm, then I will need to teach it, if you've worked with it , do know if it's should be in schduler/main.c or scheduler/server.c or config.c ? :) (they all refel to the NeedReload flag that get's set by the singals)
[10:40] <sivang> zyga: you have a bug number?
[10:40] <zyga> sivang: no, sorry - I just overheard this a few days ago
[10:40] <sivang> zyga: ok
[10:41] <zyga> sivang: if you know about a place that logs #u-d you might find something about this
[10:41] <Keybuk> sivang: no idea ... I just discovered that the log rotation script killed cupsd every night by trying to get it to hangup and re-open its log files <g>
[10:41] <Keybuk> sivang: so we changed it to restart cupsd instead
[10:41] <Keybuk> that's about as much investigation as I did
[10:42] <Keybuk> it was something to do with the fact that if it's dropped privileges, it can't actually reload its own configuration
[10:42] <Keybuk> not without elevating itself back to root, anyway
[10:42] <Keybuk> and we run cupsd in reduced privilege mode, because pitti saw it
[10:43] <sivang> Keybuk: yes, I see it now :-/
[10:43] <sivang>   if (RunAsUser)
[10:43] <sivang>     sigset(SIGHUP, sigterm_handler);
[10:43] <sivang>   else
[10:43] <sivang>     sigset(SIGHUP, sighup_handler);
[10:43] <elmo> heeeeeelp heeeelp I neeedsss a buildd admin
[10:44] <zyga> heh
[10:44] <mae__> m
[10:46] <sivang> Keybuk: so now it responsds with a restart when poked with a SIGHUP ?
[10:46] <Keybuk> sivang: no, cause it can't restart itself either
[10:46] <sivang> Keybuk: or that just plain unhandled?
[10:46] <Keybuk> it kills itself
[10:46] <\sh> elmo: Kamion is busy ;)
[10:46] <elmo> \sh: he's also not a buildd admin
[10:47] <Keybuk> "Don't send cupsd SIGHUP" :)
[10:47] <Kamion> \sh: since when was I a buildd admin?
[10:47] <\sh> damn...lamont kamion...I need some holidays
[10:47] <\sh> or new glasses?
[10:47] <sivang> Keybuk: or just teach it to handle it properly :)
[10:47] <Keybuk> sivang: if it's running as a user, it won't be able to re-open its socket
[10:48] <sivang> Keybuk: yep. so we are going to not try reopen the sockets when RunAsUser
[10:48] <Keybuk> let alone things like its log files
[10:48] <Keybuk> mehhhh
[10:48] <Keybuk> a busted HUP handler is worse than none, surely
[10:49] <Keybuk> HUP (for a daemon) means close all your sockets, file connections, reload your configuration and open them again
[10:49] <sivang> Keybuk: well, that's what pitti asked me to attempt to do, have it crippled, but then we won't have to restart the cups server every time a usb printer is plugged in
[10:49] <Keybuk> wouldn't adding some hal love to cups be a better plan
[10:49] <Keybuk> so rather than have something smack cupsd every time a printer gets added, actually have cupsd listen out for it
[10:50] <Keybuk> (and I'm not even convinced cupsd runs with enough privilege to access usb printers that it didn't open when it was root)
[10:50] <sivang> Keybuk: would, but not at that stage of the release. We'd like to have something going for breezy
[10:50] <Keybuk> fair enough
[10:51] <sivang> Keybuk: it would just "rediscover" them, so we don't suspect too much problems. I first hacked it to just to a /etc/init.d restart, but then pitti noted that users may have print jobs ongoing and it would kill them
[10:51] <zyga> am I the only person that feels breezy would be better if it was 5.11?
[10:51] <Keybuk> zyga: what would you put in .11?
[10:51] <sivang> zyga: you mena postpone the release with  a month ?
[10:51] <zyga> yes
[10:52] <Keybuk> bearing in mind moving it a month wouldn't necessarily remove the restriction on changes
[10:52] <zyga> I'm just whining though..
[10:52] <Keybuk> the theory of a 6-monthly release process is that in three weeks, we get to fix everything properly
[10:52] <zyga> Keybuk: I was thinking about the bugs
[10:52] <Keybuk> which ones?
[10:53] <zyga> Keybuk: nothing specific - as I said it's just a feeling
[10:53] <Keybuk> other than the 236 release critical ones <g>
[10:53] <Keybuk> I actually think breezy's in a slightly better state than warty was at this point
[10:53] <Keybuk> we only have 6 critical bugs open
[10:54] <zyga> but anyway - doing a every-6-months release is better than as-soon-as-everything-works-just-wait-and-use-your-nifty-oldish-package
[10:54] <Keybuk> dunno how mdz feels though
[10:55] <Kamion> zyga: one always feels it would be better if it were just a little later for a few more fixes - but after a few releases you realise it's even better to be guaranteed to have another release in six months' time that you can get your fixes into
[10:56] <zyga> Kamion: you are right
[10:56] <Keybuk> zyga: install a hoary box, use it for a few days, then install breezy instead
[10:56] <Keybuk> it's odd, but breezy does feel better
[10:57] <zyga> in corporate planet I often see a 5 year old distro and everyone refuses to upgrade ;-)
[10:57] <Keybuk> I reckon someone's lightened the control colours a bit
[10:57] <zyga> then they ask me to work in this piece of history and fix bugs and other issues
[10:58] <zyga> Keybuk: breezy has lots of excelent things
[10:58] <zyga> Keybuk: and breezy does feel better than hoary
[10:58] <ivoks> breezy is better
[10:58] <ivoks> period.
[10:58] <Keybuk> "better" is the goal
[10:59] <Keybuk> "perfect" is something to aim for, but we can get closer in 6-months
[10:59] <zyga> Keybuk: maybe I'm biased ... I started using warty, then I upgraded to hoary and got interested in developement, near breezy I see how this thing is working and I know about the bugs and issues still around
[10:59] <zyga> maybe ignorance is bliss
[11:00] <ivoks> free porn? :)
[11:00] <zyga> no
[11:00] <ivoks> it was a joke...
[11:00] <zyga> it would have been equally good with landscapes
[11:00] <zyga> the fact that it was upgraded every month
[11:00] <ivoks> yeah, that was great
[11:01] <zyga> hmm
[11:01] <ivoks> hm...
[11:01] <zyga> I've just apt-getted it and it's not in the backgrounds menu
[11:01] <Keybuk> another way of looking at release management is to rather think of extending the release cycle by a month to get more bug fixing in, reducing the development cycle by a month
[11:01] <Keybuk> that way you've got a month less to break things, and a month more to fix them
[11:01] <Keybuk> while still holding 6-monthly
[11:01] <ivoks> yup
[11:01] <zyga> Keybuk: faster freeze?
[11:01] <ivoks> and one month older packages :)
[11:02] <Keybuk> it's all a matter of balance
[11:02] <zyga> Keybuk: but then again freeze is a double-edged sword
[11:02] <ivoks> sure
[11:06] <mdz> Keybuk: about what?
[11:07] <mdz> the overall bugginess?  we're not in bad shape
[11:07] <zyga> hey I've found a bug in ubuntu-calendar
[11:07] <zyga> it's a trivial fix
[11:07] <Keybuk> mdz: that's my impression, we're actually pretty good
[11:07] <zyga> the package puts the xml files into /usr/share/gnome-wallpaper-properties
[11:08] <mdz> I don't think we can usefully compare to warty, and maybe only somewhat to hoary
[11:08] <zyga> while it should have put them in /usr/share/gnome-background-properties
[11:08] <zyga> :-)
[11:08] <mdz> but my gut says "not bad"
[11:08] <zyga> will anyone accept a patch that fixes this?
[11:09] <mdz> we have a much higher rate of sustained bug activity now than we ever have before, I'd say
[11:10] <seb128> mdz: yeah, I would say that too :/
[11:10] <zyga> anyone :-)
[11:10] <zyga> It's a one-liner and it works
[11:10] <seb128> zyga: what?
[11:11] <zyga> seb128: there's a bug in ubuntu-calendar* packages
[11:11] <seb128> $ ls -l /usr/share/ | grep properties
[11:11] <seb128> lrwxrwxrwx     1 root root    26 2005-03-02 23:40 gnome-background-properties -> gnome-wallpaper-properties
[11:11] <seb128> here
[11:11] <zyga> hmm
[11:11] <zyga> okay but it does not work 
[11:11] <zyga> a manual fix makes it work
[11:11] <seb128> "manual fix"?
[11:12] <zyga> maybe it does not like symlinks
[11:12] <zyga> hmm
[11:12] <seb128> it works for me
[11:12] <zyga> hmm I'm dumb
[11:13] <seb128> https://bugzilla.ubuntu.com/show_bug.cgi?id=13256
[11:13] <seb128> https://bugzilla.ubuntu.com/show_bug.cgi?id=8721 has some comments on the topic
[11:13] <zyga> seb128: okay
[11:13] <seb128> if you want to track the issue that would be appreciate
[11:13] <seb128> there is probably an issue but that's not obvious which one
[11:14] <zyga> zyga@falcon:/usr/share$ ls -l /usr/share/ | grep properties
[11:14] <zyga> drwxr-xr-x     2 root root  4096 2005-09-27 23:12 gnome-background-properties
[11:14] <zyga> drwxr-xr-x     2 root root  4096 2005-09-27 23:13 gnome-wallpaper-properties
[11:14] <zyga> they are not symlinks here
[11:14] <seb128> but you changed that, right?
[11:14] <zyga> no
[11:15] <zyga> I've reinstalled the packages to be sure
[11:15] <zyga> g-w-p is not a symlink
[11:15] <zyga> I did not touch that
[11:15] <zyga> I've got the gnome-background package too 
[11:15] <Kamion> seb128: it causes problems (undefined behaviour, depending on unpack ordering) for one package to install a symlink and another to install a directory in the same location
[11:15] <zyga> (I'm not sure about the name but you get the idea)
[11:16] <zyga> Kamion: I'd say it's better to put everything into the proper directory than to put symlinks around
[11:16] <Kamion> seb128: you're probably going to have to fix up the situation in maintainer scripts
[11:16] <zyga> hmm anyway it's a real bug not my imagination -- I'm really tired today and I didn't want to look like a fool
[11:19] <seb128> Kamion: do you know why ubuntu-artwork install them to the wrong directory to start?
[11:19] <seb128> jdub: around?
[11:19] <Kamion> seb128: nope
[11:20] <zyga> seb128: which directory is correct?
[11:20] <seb128> I guess that jdub knows about that
[11:21] <seb128> zyga: gnome-background-properties
[11:21] <zyga> seb128: how about a patch that makes g-b-p just search both directories?
[11:21] <sivang> Keybuk: weird. I manually executed cupsd as root, SIGHUP'd it, and it still "Terminates normally" 
[11:21] <seb128> zyga: I want to know why they made this hack first
[11:21] <Keybuk> sivang: is it actually root when you HUP it, or has it turned into cupsys?
[11:21] <zyga> seb128: or is there any easier to migrate stuff from one directory to the other
[11:22] <zyga> seb128: I think upstream changed the directory and packager tried to get upgrade working
[11:22] <seb128> zyga: no, upstream didn't change this code for pretty sure
[11:22] <zyga> seb128: maybe just rebuilding calendar packages will work, old packages get removed
[11:22] <seb128> zyga: I'm one of the upstream for it
[11:22] <zyga> hmm then I'm out of ideas
[11:23] <zyga> seb128: I can confirm that rebuidling the package fixes the issue
[11:23] <zyga> (with the new directory instead of the old one)
[11:23] <seb128> the changelog of ubuntu-artworks suggest they change it to avoid a conflicts with gnome-desktop-background package
[11:23] <seb128> rebuilding?
[11:23] <seb128> or reinstalling?
[11:23] <seb128> oh, you mean installing them to the other dir?
[11:23] <zyga> seb128: rebuilding after modifying the directory, then reinstalling
[11:24] <zyga> yes
[11:24] <Keybuk> disturbing ... my screensaver just morphed Kinnison into Diziet
[11:24] <Nafallo> lol
[11:25] <sivang> LOL
[11:25] <sivang> Keybuk: how do I check? I su'd to root, /usr/sbin/cupsd -F , then SIHUP'd it with a sudo
[11:25] <Keybuk> sivang: ps aux | grep cups
[11:26] <sivang> bah, right
[11:27] <sivang> Keybuk: damn. it is cupsys , how does it switch to the user so soon?
[11:27] <Keybuk> setuid ? :p
[11:27] <Keybuk> generally it's considered wise to drop your privileges quickly if you're going to do so
[11:28] <zyga> seb128: do you want a patch?
[11:31] <zyga> seb128: is there any way to i18n-ze the those xml files
[11:31] <zyga> yes I'm an i18n whore
[11:31] <sivang> Keybuk: ah right , funnny that support dropping the privileges but didn't care for the realod config as the user appareently . funny upstream ;)
[11:32] <Keybuk> the problem is what if the config file change the user wants to reload for is a change of listening port?
[11:32] <Keybuk> you need to be root to listen on ports < 1024
[11:33] <sivang> right, maybe I can selectivey sense a printer event, and respond only for those...
[11:33] <Simza> when is string freeze for Breezy?
[11:34] <zyga> Simza: AFAIK it's already string freeze
[11:36] <zyga> how to say in debian/control
[11:36] <mvo> yes, we are deep in string freeze
[11:36] <zyga> replaces & conflicts with the same package at version smaller than current
[11:37] <seb128> zyga: patch to https://bugzilla.ubuntu.com/show_bug.cgi?id=8721 if you have one
[11:37] <zyga> seb128: sure
[11:38] <seb128> zyga: for the translation:https://bugzilla.ubuntu.com/show_bug.cgi?id=9080
[11:48] <zyga> seb128: 13256 is a duplicate of  8721
[11:49] <zyga> seb128: can you marke it as such
[11:50] <seb128> zyga: thanks, I've done that like 10 min ago :p
[11:50] <zyga> seb128: sorry ;)
[11:50] <seb128> no problem at all
[11:50] <seb128> thanks for pointing it :)
[11:51] <zyga> seb128: I'm doing update && upgrade to check that the problem is indeed fixed 
[11:52] <zyga> seb128: just to clear things up, ubuntu-artwork contains all the translations for calendar and many other artwork-related stuff?
[11:52] <seb128> zyga: nop, no translation
[11:52] <zyga> seb128: .pot's -- sorry
[11:53] <seb128> afaik there is some work to do on it, cf https://bugzilla.ubuntu.com/show_bug.cgi?id=9080
[11:54] <zyga> do you really remember those bugs?
[11:55] <seb128> zyga: the number? no. The bugs description, yep ... and I know how to find them with a query
[11:56] <seb128> ah ah :)
[11:56] <mvo> but I can't prove it ;)
[11:56] <seb128> :p
[11:57] <zyga> aww... now it works as expected but with old packages
[11:58] <zyga> and both directories are in fact directories
[11:58] <zyga> ah, no it does not :-)
[11:58] <zyga> everything is okay now :)