[12:58] <Lathiat> sivang: there is a way
[12:58] <Lathiat> sivang: its in the network prefs
[12:58] <sivang> Lathiat: /me checks
[12:58] <Lathiat> system->admin->networking
[12:58] <Lathiat> general tab
[12:59] <Lathiat> which crashes for me.. but its there ;)
[12:59] <sivang> Lathiat: oh nice, that is slomo's patch ?
[12:59] <Lathiat> sivang: not sure
[01:00] <sivang> Lathiat: did not crash, but then again I do not have any other appliances that would respond to it
[01:00] <Lathiat> well i maen the 'networking' util crashed
[01:00] <Lathiat> wouldnt even opern the first screen :)
[01:01] <sivang> Lathiat: hehe, file a bug or either look for the tons already reported
[01:01] <sivang> elmo: ^^^ (about the avahi-daemon thiingy)
[01:02] <Lathiat> oh the networkign thign dying is well known?
[01:04] <sivang> Lathiat: I think I've seen a couple dying network-admin reports already
[01:07] <Lathiat> ah ok
[01:07] <Lathiat> bbl
[01:45] <Riddell> tfheen: kubuntu accessibility seems to work except that the spelling is wrong in ubiquity-hooks/30accessibility  s/imparement/impairment
[01:45] <Riddell> (which is my fault)
[02:21] <Tonio_> Riddell: have you finished your changes to kds ? I have a few things to do too
[05:24] <milosevic> mdke_ ?
[05:25] <milosevic> mdke_: ping ^^^
[06:20] <hile> how does a package appear for translation in launchpad?
[06:21] <hile> I have some translations for which i can't find a translation page to upload upstream .po files ...
[06:22] <infinity> The templates and translations are stripped from packages when we build them, then rosetta imports those.  In theory.
[06:22] <infinity> In practice, I'm not sure precisely what happens, as I've not played with the rosetta side of it, only the buildd side.
[06:23] <hile> I'll check again if it's in rosetta banshee-plugins and not banshee-official-plugins (package name, source is just banshee-plugins)
[06:23] <hile> there's no simple 'search package by name' in rosetta either which would be really nice...
[06:26] <hile> btw, what do you thinkw e should do for a package which does not have translations at all, i.e. seems not to be localized (revelation)
[06:27] <hile> should I file a bug to launchpad for it, expecting someone to implement localization or what ;)
[06:27] <infinity> You could try, though you're better off going to upstream (if you know where to find them) to get them to do that, generally.
[06:27] <hile> of course yeah ... 
[06:28] <infinity> While we try to forward as many bugs upstream as we can and, occasionally, we might even be interested in localising a pet project here and there, we don't have the manpower to deal with feature requeusts like that all the time.
[06:28] <hile> just thought if it's tupid idea in the first place
[06:28] <hile> true
[06:28] <infinity> It's never a "stupid idea" to ask for someone to use gettext-style string localisatoin in their software, IMO.
[06:28] <infinity> They may not do it, but it never hurts to ask. :)
[06:29] <hile> no but it might be stuupid idea not to ask it from upstream and ask it from ubuntu devels ;)
[06:29] <infinity> Yeah, it's generally something we're not likely to spend our time on, unless it's a highly visible part of the default desktop, and thus has a pretty obvious usability impact.
[06:30] <hile> ok, what does this mean: https://launchpad.net/distros/ubuntu/edgy/+source/banshee-official-plugins/+translations
[06:30] <hile> that package  is translatable, it just does not have many translations yet 
[06:32] <infinity> Yeah, the buildd process did find and strip translations (banshee-official-plugins_0.11.0-0ubuntu1_i386_translations.tar.gz), so if rosetta imports aren't actually running, you might wantto bug the launchpad/rosetta people about it.
[06:35] <hile> as I said I have translated upstream and sent a patch as bug (not in gnome cvs),  not yet accepted or handled, just would like to push it via launchpad to edgy package as well ;)
[06:35] <hile> well, I asked on rosetta-users about it
[07:24] <bluefoxicy> heh wow lots of directories.  Maybe a function to watch recursively would be a good idea.
[07:48] <fabbione> morning guys
[08:17] <tfheen> Riddell: where do you see that typo?  If it's in gfxboot, that's not from casper.
[08:19] <tfheen> fabbione: any chance you could tell me why gcc-3.3-doc is uninstallable on sparc?
[08:19] <fabbione> tfheen: yes.. i need a few minutes to power on everythin
[08:20] <tfheen> thanks
[08:25] <fabbione> i wonder why we have gcc-3.3 in main still
[08:27] <fabbione> tfheen: gcc-3.3 -13 (HI SCOTT) is FTBFS on sparc
[08:27] <fabbione>  /usr/include/gnu/stubs.h:9:27: gnu/stubs-64.h: No such file or directory
[08:27] <fabbione> looks like glibc borkage 
[08:28] <tfheen> fabbione: that explains it; any chance we could get it fixed?  (And I too wonder why it's in main; that might be because of libstdc++5 or something like that)
[08:28] <fabbione> tfheen: i am looking into it
[08:28] <tfheen> cheers
[08:28] <fabbione> but it might require doko/jbailey love
[08:29] <hile> uhm, funny, the rosetta error page for translations says 'send mail to rosetta-users',  only problem is you have to subscribe first ...
[08:34] <fabbione> tfheen: looks like glibc borkage
[08:35] <fabbione> tfheen: i need some time to dig into it
[08:35] <fabbione> tfheen: but one thing i am sure about....
[08:35] <fabbione> I HATE YOU ALL!!!! I DO NOT WANT TO HACK GLIBC!!! YOU ALL HATE ME TO DEATH!!! :P
[08:44] <infinity> tfheen: Yeah, it's in main for libstdc++5.
[08:44] <infinity> Not really necessary for sparc, so we could just remove the sparc binaries if the FTBFS is a pain to fix.
[08:46] <fabbione> infinity: nah it's not a pain
[08:46] <fabbione> it's a missing include that should be provided by glibc
[08:46] <fabbione> i need a few minutes to dig it... local mirror was rsyncing
[08:49] <fabbione> tfheen: confirmed.. it's a bug in glibc
[08:51] <psykoyiko> fabbione: your confirmation wouldn't revolve around asm/processor.h, would it?
[08:52] <fabbione> psykoyiko: no
[08:52] <fabbione> gnu/stubs.h becoming a wrapper to include gnu/stubs-{32,64}.h and the 64 not being generated at all
[08:53] <fabbione> and i think that's just sparc specific
[08:53] <psykoyiko> ah.
[08:54] <pitti> Good morning
[08:54] <fabbione> tfheen: it's actually a general bug.. also i386 and others are affected. except that they usually do not include the -64.h 
[08:54] <fabbione> hey pitti
[08:56] <pitti> hey fabbione 
[08:56] <psykoyiko> should developer support type questions be directed here or in #ubuntu? 
[08:56] <psykoyiko> by developer support I mean developer questions not directly related to ubuntu development
[08:57] <tfheen> psykoyiko: this channel is for development of ubuntu, not development on ubuntu.
[08:58] <psykoyiko> tfheen: Thanks, the lines seemed blurry from my point of view.
[09:07] <bluefoxicy> bah
[09:07] <bluefoxicy> I don't know how to approach this problem.
[09:08] <bluefoxicy> I want to prove that if you have a task that relies on CPU and IO, and you parallelize the CPU and IO, then the time the task spends is precisely the isolate time of the longer task
[09:09] <bluefoxicy> so for example a task that's primarily CPU bound (say 1.0s CPU and 0.5s IO) will take a nominal time normally (1.5s); but in parallel, take the CPU time (1.0s) and the IO time will be lost because the parallel IO thread is outrunning CPU
[09:11] <bluefoxicy> whereas a primarily IO bound task (0.5s CPU 1.0s IO) will have a situation where the CPU catches up to the readahead() in the parallel IO thread and waits to get data; but then its following CPU-bound moment has the parallel IO thread skipping over that IO which just happened, and reading the next IO burst.  Eventually this should yield a total time of the IO time (1.0s) plus precisely the last bit of work the CPU does.
[09:12] <bluefoxicy> oh well.  I'll just sleep.
[09:12] <popey> heh
[09:12] <popey> I'm sure someone was listening
[09:12] <popey> :)
[09:12] <bluefoxicy> yes but I need sleep :)
[09:12] <bluefoxicy> I'm still working on writing my own readahead program
[09:13] <bluefoxicy> this one is going to have the concept of a "monitor," which monitors a directory for access, which gets logged later
[09:13] <bluefoxicy> (as opposed to /etc/readahead/*)
[09:14] <psykoyiko> okay, this actually seems like a bug
[09:14] <psykoyiko> I can't seem to #include <asm/atomic.h>
[09:14] <sivang> morning!
[09:14] <psykoyiko> due to a missing asm/processor.h
[09:14] <bluefoxicy> And also the concept of special types of files, most importantly ELF files, which when being read ahead will only have a subset of sections read in; this part seems interesting to me, because i would lend itself to glibc read-ahead optimizing itself
[09:15] <bluefoxicy> (glibc takes 1.5 seconds to ldd -r -d openoffice.org and then 0.4 seconds to do same afterwards)
[09:16] <bluefoxicy> heh.. there's a funky idea, gnome with read-ahead
[09:18] <bluefoxicy> let's see.. icon is displayed on the screen... yeah I can see this...
[09:18] <bluefoxicy> I'll spec this up, it'll be better than just babbling on.
[09:41] <fabbione> hey mvo
[09:42] <fabbione> mvo: i am not sure #63353 is a glibc bug... the submitter has a messed up mix of dapper and edgy in sources.list
[09:42] <fabbione> and i can't even reproduce it here
[09:42] <fabbione> (with apt-get that's it)
[09:44] <mvo> fabbione: hi! 
[09:44] <mvo> fabbione: well, his sources.list looks sane, he had only dapper source before he tried to upgrade
[09:45] <mvo> fabbione: its unfortunate that we don't have the terminal log of the failure :/
[09:45] <fabbione> such kind of bug would have show up much early and a much more "OMG THE SKY IS FALLING DOWN" style
[09:47] <mvo> fabbione: yeah, its a odd report
[09:50] <tfheen> doko_: why is #64946 against gcc-defaults rather than the universe packages?
[09:58] <dholbach> good morning
[09:59] <tfheen> dholbach: excellent, I was just looking for you.  You're on the ball for the 6.10-targeted bluetooth bugs, right?
[09:59] <pitti> hi tkamppeter 
[10:00] <dholbach> tfheen: I didn't have much luck with them - it'd be nice, if somebody would help looking into that
[10:00] <dholbach> tfheen: but I'll play with those bugs later on
[10:01] <tfheen> dholbach: 'k.  I can poke them and see if they're easy to fix
[10:01] <tfheen> but now I need to go out and pick up a couple of disks.
[10:07] <dholbach> tfheen: mjg59 said we were crazy to not ship 3.7 (which is in debian)
[10:08] <dholbach> tfheen: the problems are: 1) computer is not discoverable until you type   hciconfig hci0 piscan   (regression that happened somewhere), 2) pairing does not work  3) nautilus-sendto being broken about bluetooth  and maybe others I can't remember right now :-/
[10:23] <tfheen> dholbach: that's a fairly big jump.  I'll have to take a look at it.
[10:24] <geser> tfheen: could you please giveback gnustep-back on i386? thanks
[10:24] <dholbach> tfheen: his exact words were:    Okt 09 18:10:14 mjg59      dholbach: The version we have is an utter crock of shit, really
[10:25] <tfheen> dholbach: heh, ok.
[10:25] <tfheen> dholbach: any chance you could try the version in Debian and file an UVF exception request?  If you can't, I'll do it.
[10:25] <tkamppeter> hi pitti
[10:25] <dholbach> tfheen: it's not just syncing from Debian unfortunately
[10:26] <tfheen> dholbach: why not?
[10:26] <dholbach> tfheen: because that doesn't just fix all our bugs
[10:26] <dholbach> but it's a good first step :)
[10:26] <tfheen> well, we'd still need an UVF exception to go to 3.7
[10:27] <tfheen> and I care less about it fixing all bugs than fixing all 6.10-targetted bugs
[10:28] <dholbach> tfheen: right
[10:49] <Keybuk> seb128: last night's upgrade killed my panel and all the applets
[10:49] <seb128> hum
[10:49] <seb128> what packages did you update?
[10:50] <seb128> killed, like it froze?
[10:50] <pitti> *me too*
[10:51] <pitti> seb128: it was just killed and restarted automatically
[10:51] <seb128> what package did you update?
[10:51] <pitti> hm, today I had 90 MB worth of dist-upgrade
[10:51] <pitti> and I upgraded yesterday, too, so something from yesterday
[10:51] <Ng> I do upgrades each morning, just did this mornings and my panel et al are still intact
[10:52] <Ng> although I haven't restarted yet ;)
[10:52] <pitti> seb128: wasn't that bad actually, since the panel restarts automatically I got the new version with new libs for free :)
[10:52] <seb128> :p
[10:55] <tfheen> dholbach: you never said whether you could handle bluez or not, you just said it wouldn't fix all the bugs. :-P  Can you or can't you?
[10:58] <dholbach> tfheen: I'd be happy with some help on it :)
[10:59] <tfheen> dholbach: I'll attack it with fangs and claws once my dist-upgrade finishes then.
[10:59] <dholbach> ;-)
[11:02] <seb128> hum
[11:02] <seb128> my panel didn't crash on upgrade
[11:02] <Kamion> mjg59: was compiz-kde deliberately removed?
[11:02] <seb128> Keybuk, pitti: did apport collected any crash about that panel restart?
[11:03] <Keybuk> seb128: it hung, it didn't restart
[11:03] <pitti> seb128: not for me, it just restarted
[11:03] <seb128> Keybuk: did you get a backtrace of the hang?
[11:04] <Keybuk> seb128: http://people.ubuntu.com/~scott/upgrade.txt
[11:04] <Keybuk> seb128: I couldn't even open a terminal at that point
[11:06] <gicmo> ;-D
[11:08] <doko_> tfheen: hmm, a MOTU changed that, reverted ...
[11:09] <tkamppeter> pitti, kamion, you have mail, UVF ER for HPLIP 1.6.9, until when does this need to be packaged. Which hour is the final freeze on Thursday?
[11:10] <pitti> tkamppeter: the earlier the better; preferably it should be in the archive by tomorrow
[11:11] <tfheen> I'll freeze the archive when I get to work on Thursday morning, fwiw.
[11:15] <tkamppeter> pitti, doko_, mvo, I will not have much time today, can someone of you package it? It is only replacing the source tarball by the new one from upstream and moving the fax PPD from hpijs-ppds to hplip subpackage? Thanks.
[11:16] <pitti> I cannot test it at all
[11:18] <dholbach> tkamppeter: Hello - do you know how good the chances are for a Lexmark Z43 to work in properly in Ubuntu?
[11:18] <gicmo> "Sound does work, just not through the speaker jacks. For some reason the current ALSA driver doesn't control the audio outputs correctly. This is a known issue and hopefully will be resolved soon. The optical output plug works, and I currently use this to get sound through an amplifier. Just make sure the IEC958 port is turned on in alsamixer."
[11:18] <gicmo> FUCK
[11:18] <gicmo> and I was about the buy the cable but didnt 
[11:18] <gicmo> grml
[11:18] <dholbach> tkamppeter: My sister just acquired one of these and wasn't happy with it in a Dapper install
[11:20] <tkamppeter> dholbach, it probably fails due to the driver "drv_z42" (see linuxprinting.org) not being in the Ubuntu distro. Perhaps current Edgy's Gutenprint supports this model, too but I am not sure. If everything else fails, compile drv_z42 from source.
[11:20] <dholbach> tkamppeter: Ok, I'll tell her to try with an Edgy LiveCD
[11:20] <dholbach> tkamppeter: Thanks.
[11:23] <mantiena-baltix> tfheen: hi
[11:27] <tkamppeter> pitti, perhaps doko_ or mvo can test and I can perhaps do a test tomorrow (on PhotoSmart 2600) when I can grab the package somewhere
[11:27] <mantiena-baltix> tfheen: are you online ? I wanna talk about hard disk partitions automount realization in casper
[11:28] <tfheen> mantiena-baltix: yes, I'm online, but I rarely respond to contentless pings.
[11:28] <tkamppeter> pitti, another thing is moving over the Fax PPD from the hpijs-ppds sub-package to the hplip sub-package, which does not require real testing but only checking whether it was done correctly by the build.
[11:29] <doko_> tkamppeter: my printer dies a week before ... :(
[11:31] <mantiena-baltix> tfheen: ok,  so, I didn't found any code, related to partition automountin in casper bzr, have you some code or not ?
[11:31] <tfheen> mantiena-baltix: there is no code in the current branch, no.
[11:33] <mantiena-baltix> tfheen: maybe there is some code in some other branch, for example in http://people.ubuntu.com/~tfheen/bzr/casper/ ?
[11:33] <tfheen> mantiena-baltix: I doubt it; there was some code written for breezy, but the rest of casper has changed a lot in the meantime.
[11:35] <tkamppeter> doko_: which model? If it is an HP multi-function device, certain parts can still be working, for example if the printing mechanics is broken it still can fax).
[11:37] <doko_> tkamppeter: hp6110, it has a fax, yes ... but last I checked, faxing was only working locally
[11:38] <mantiena-baltix> tfheen: in Previous Baltix Linux distro versions (based on Ubuntu hoary and breezy)  I used automount code, written by Kamion - look at http://people.ubuntu.com/~cjwatson/bzr/casper/automount/casper/pre.d/12fstab
[11:39] <mantiena-baltix> tfheen: what you think about using same code for current casper ?
[11:39] <mantiena-baltix> tfheen: less than 50 lines ;) 
[11:40] <mantiena-baltix> current casper still has 12fstab script in scripts/casper-bottom/
[11:41] <tkamppeter> doko_, if fax only works locally, that is enough to test the fax capability.
[11:42] <tkamppeter> If the network interface of your device is broken, simply test it as an USB device.
[11:42] <Kamion> mantiena-baltix: that code won't work any more
[11:42] <tfheen> mantiena-baltix: that one won't work correctly due to how udev works.
[11:42] <tfheen> amongst other things.
[11:42] <Kamion> it uses partconf, which is not available
[11:42] <tkamppeter> doko_, and you also do not need a phone line and a destination fax machine. If you hear your device dialling, then HPLIP has done its job.
[11:43] <Kamion> it would have to be rewritten in a different way
[11:43] <Kamion> probably iterating over /sys/block or something
[11:44] <tfheen> it should really rather just be a daemon which mounts all block devices as they become available
[11:44] <tfheen> similar to g-v-m.
[11:45] <mantiena-baltix> Kamion, tfheen: it's pretty hard for me to write a daemon :(
[11:45] <doko_> tkamppeter: ok, I'll look at it. do you have an updated package?
[11:46] <tkamppeter> doko_, unfortunately, Debian did not pick it up even that it is available for 3 weeks now.
[11:46] <Kamion> doko_: I assume you'll subscribe ubuntu-archive to bug 64946 when you're ready?
[11:46] <Ubugtu> Malone bug 64946 in Ubuntu "sync requests / UVF exceptions (Ada packages in universe)" [Medium,Confirmed]  http://launchpad.net/bugs/64946
[11:48] <tkamppeter> So what needs to be done is ap-get source hplip to get the souurce of the current 1.6.7-2ubuntu2 package
[11:48] <mjg59> Keybuk: Can I grab you to help work out why zd1211s seem unhappy about the essid being set from /etc/network/interfaces at some stage?
[11:48] <mantiena-baltix> Kamion, tfheen: btw, in current casper there is a script for finding and mounting swap partitions - this script doesn't use /sys/block :(
[11:48] <Keybuk> mjg59: sure
[11:48] <mjg59> Not right now, though
[11:48] <tkamppeter> and then replace the source tarball by the 1.6.9 one from http://hplip.sf.net/
[11:48] <tfheen> mantiena-baltix: correct, it doesn't work properly.
[11:48] <mjg59> Since I can't actually find mine at the moment
[11:48] <Keybuk> mjg59: isn't that one of the cards that has to be UP before it will accept and essid?
[11:48] <mantiena-baltix> scripts/casper-bottom/13swap
[11:49] <tkamppeter> and move over the Fax PPD to hplip (bug 59409)
[11:49] <Ubugtu> Malone bug 59409 in hplip "Fax PPD not installed by default" [Undecided,Confirmed]  http://launchpad.net/bugs/59409
[11:49] <doko_> Kamion: ok, done; was waiting for MOTU approval 
[11:50] <mjg59> Keybuk: Could be, in which case it's possible that ifup is doing the wrong thing in this case
[11:50] <Keybuk> mjg59: could be
[11:50] <Kamion> Keybuk: bagsy the backports in ubuntu-archive's queue - I want to work on fixing bugg 63726
[11:50] <Kamion> er, bug 63726
[11:50] <Ubugtu> Malone bug 63726 in Ubuntu "backports-changes are currently useless" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63726
[11:50] <mjg59> Keybuk: It's certainly a card that needs the essid to be explicitly set
[11:50] <tkamppeter> Perhaps simple changes can also fix bug 58727 and bug 60242, 
[11:50] <Ubugtu> Malone bug 58727 in hplip "bug in hplip .deb removal script" [Undecided,Unconfirmed]  http://launchpad.net/bugs/58727
[11:50] <Ubugtu> Malone bug 60242 in hplip "Removing hplip encounters errors: scanner group not empty" [Undecided,Unconfirmed]  http://launchpad.net/bugs/60242
[11:52] <Keybuk> Kamion: ok
[11:52] <mantiena-baltix> tfheen: can we make a deal ? if you or Kamion or someone else will rewrite scripts/casper-bottom/13swap in correct way then I can write partitions automounting code in the same way :) Now it's to hard for me to write a daemon without any example :(
[11:53] <tkamppeter> doko_, perhaps bug 62718 is also a small thingy in the scripts, but when I installed my last two builds of HPLIP 1.6.7, this bug did not occur for me.
[11:53] <Ubugtu> Malone bug 62718 in hplip "[Edgy]  Current Updates (2006-09-27) Break HPLIP" [Low,Needs info]  http://launchpad.net/bugs/62718
[11:53] <Keybuk> mjg59: are the "usplash segfaults" and "usplash spins at 100% CPU" bugs the same?
[11:54] <mjg59> Keybuk: Yes
[11:54] <tfheen> mantiena-baltix: no; if I get the time to rewrite 13swap I'd write it so it could automount partitions too.
[11:56] <mantiena-baltix> tfheen: then maybe you can show me some example how to write partition automounting daemon for casper ?
[11:57] <dholbach> Keybuk: 65030 is a dup and a translation team problem - didn't seb128 tell you that yesterday? or was that somebody else?
[11:57] <tfheen> mantiena-baltix: dude, I'm busy with the release candidate for Edgy, there's absolutely no way I have time to sit down and fix those bits of casper.  Ask again in a month and I might have time.
[11:57] <Keybuk> dholbach: I couldn't find the dup bug
[11:57] <Keybuk> it's certainly not listed against the 6.10 milestone
[11:58] <Keybuk> and a bug should be open for that until it's fixed
[11:58] <seb128> it's fixed
[11:58] <Keybuk> it isn't fixed
[11:58] <Keybuk> I'm completely up to date today, and I still see it
[11:58] <seb128> it just needs a damn languagepack upload
[11:58] <seb128> it's "Fix Commited"
[11:58] <Keybuk> then it's not fixed until there's been a langpack upload
[11:58] <Keybuk> how do we get one of those?
[11:58] <pitti> I'm fine with doing it at any time
[11:59] <seb128> bug #60047
[11:59] <Ubugtu> Malone bug 60047 in language-pack-gnome-en-base "Folders with new messages are prefixed 'folder-display|'" [Medium,Fix committed]  http://launchpad.net/bugs/60047
[11:59] <pitti> but I'd like to do it after all other edgy stuff settled
[11:59] <Keybuk> seb128: ok, I'll make that targeted against 6.10
[11:59] <pitti> i. e. tomorrow would be a good time IMHO
[11:59] <seb128> Keybuk: fine with me ;)
[12:01] <shawarma> Should kernel bugs be assigned to ubuntu-kernel-team? They're already in the "also notified" list.
[12:01] <Keybuk> shawarma: let them choose the assignee
[12:01] <fabbione> shawarma: no. 
[12:01] <Keybuk> in general, if there's a bug contact for a package, let the bug contact(s) decide
[12:01] <infinity> shawarma: Yeah, don't assign them at all, please.
[12:01] <seb128> Keybuk: "deb http://people.ubuntu.com/~pitti/langpacks/daily/edgy/ ./" BTW
[12:01] <shawarma> Keybuk: Ok. So setting it to confirmed and providing info about a fix should be sufficient?
[12:02] <seb128> Keybuk: daily language packs
[12:02] <Keybuk> that way an entire team see the bug, and can assign to an individual who's actually going to debug/fix it
[12:02] <infinity> shawarma: If someone wants to claim (or delegate) a bug, then we use the assignee for that.
[12:03] <shawarma> infinity: alright. I'll just leave it as is.
[12:05] <shawarma> Keybuk: Ok. Sounds sane enough. I wasn't sure if it wasn't assigned automatically so that the bugsquad could confirm it first and the assign the team.
[12:06] <Keybuk> assigning to teams is almost always worthless
[12:06] <Keybuk> teams should be subscribed, individuals should be assigned
[12:06] <shawarma> Makes sense.
[12:06] <shawarma> Ok, thanks.
[12:07] <seb128> Keybuk: it cleans up the un-assigned list and allow team member to have an overview of bugs the team is responsive for
[12:09] <Keybuk> seb128: I mean for people not in that team
[12:15] <tkamppeter> doko_, thanks in advance for your help. Contact me (pref. by e-mail) in case of any problems.
[12:17] <RicardoPerez> pitti: ping
[12:17] <pitti> hi RicardoPerez 
[12:17] <RicardoPerez> pitti: hi! there are no daily langpacks since some days ago. is it correct?
[12:17] <pitti> RicardoPerez: oh, ugh
[12:18] <pitti> RicardoPerez: hm, I got packages from today
[12:18] <RicardoPerez> pitti: ummmmm...
[12:18] <RicardoPerez> Spads: :D
[12:18] <pitti> RicardoPerez: however, some time ago I taught langpack-o-matic to only generate a new package if there is actually new data
[12:19] <RicardoPerez> pitti: my current version is 20061004
[12:19] <pitti> RicardoPerez: so there might not be a new version for your particular language
[12:19] <doko_> seb128: ping
[12:19] <RicardoPerez> pitti: mmmm... strange... carlos change the name of one .mo file...
[12:19] <seb128> doko_: pong
[12:19] <pitti> RicardoPerez: oh, indeed, edgy is indeed behind, I was looking at dapper
[12:19] <pitti> RicardoPerez: will fix, thanks
[12:20] <RicardoPerez> pitti: ah, great :) thanks to you
[12:21] <pitti> RicardoPerez: generating new edgy packs now, check again in 1 or 2 hours
[12:21] <RicardoPerez> pitti: thanks again :) i'll check it
[12:25] <fabbione> elmo: ping?
[12:28] <fabbione> elmo: regarding bug #64198, it would be lovely if you can add the info today. I only have a small time window to talk to upstream every day because they are located in different TZ. otherwise we risk to take ages to get that fixed
[12:28] <Ubugtu> Malone bug 64198 in xserver-xorg-video-ati "LiveCD can't start X on Apple Xserve or PowerBook" [High,Confirmed]  http://launchpad.net/bugs/64198
[12:31] <Keybuk> doko_: ping
[12:32] <sivang> pitti: has there been soem changes recently to how hal reports information volumes in optical drives et al ?
[12:32] <doko_> Keybuk: pong
[12:32] <sivang> pitti: hubackup CDROM detection code breaks now becuase what seem like layout change in child and parent nodes on the tree..
[12:32] <Keybuk> doko_: bug #63747
[12:32] <Ubugtu> Malone bug 63747 in openoffice.org-amd64 "please remove the openoffice.org-amd64 source" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63747
[12:32] <Keybuk> shall I do that now?
[12:32] <doko_> Keybuk: yes please! :)
[12:33] <pitti> sivang: actually not; hal upstream version didn't change since dapper
[12:33] <pitti> sivang: only a couple of patches, but I cannot remember any of them touching CD stuff
[12:33] <sivang> pitti: CD volumes now appear to be a child of the CD/DVD/CDROM  'device' node.
[12:33] <pitti> doko_: yay :)
[12:33] <pitti> sivang: that's how it's supposed to be
[12:34] <sivang> pitti: rather then being populated in the device node, as I recall it was..
[12:34] <pitti> sivang: and I don't remember it ever being different
[12:34] <pitti> sivang: bus -> controller -> drive -> volume
[12:34] <sivang> pitti: hmm, I see. it does make much more sense, I guess it's me flipping :-)
[12:34] <sivang> thanks anyway
[12:34] <pitti> sivang: np :)
[12:35] <thom> heh
[12:36] <pitti> hi thom, how's it going?
[12:37] <thom> going well
[12:37] <thom> und du?
[12:37] <madduck> tfheen: ping!
[12:37] <tfheen> madduck: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I'll respond when I am around.
[12:37] <madduck> tfheen: this was on purpose...
[12:38] <madduck> wouldn't it be better to /msg privately?
[12:38] <madduck> just thinking...
[12:38] <thom> dholbach: hey duder
[12:38] <dholbach> thom: Alter!
[12:39] <dholbach> :-)
[12:39] <pitti> thom: cold disappears slowly, I'm fine :)
[12:41] <hunger> pitti: You were at akademy in dublin?
[12:41] <pitti> hunger: no, I wasn't
[12:41] <sivang> pitti: anything I can kill in order to release a cd from the drive? eject /pumount / gui eject won't work on account it's busy.
[12:41] <hunger> pitti: Oh, I thought because of the cold... everybody that has been there got one;-)
[12:42] <sivang> pitti: never mind, managed it.
[12:42] <pitti> sivang: fuser -k? :)
[12:42] <pitti> but I wouldn't recommend that
[12:44] <sivang> pitti: cool, would come useful for testing.
[12:44] <Kamion> madduck: personally I hope that Tollef's script complaining publicly will reduce the incidence of contentless pings
[12:44] <madduck> Kamion: yeah true. i have adopted it too.
[12:45] <Riddell> tfheen: the spelling is wrong in ubiquity-hooks/30accessibility in casper
[12:45] <Riddell> it needs to be changed to match scripts/30accessibility
[12:47] <sivang> crap, cdrecord got hung up on blanking a media
[12:47] <giftnudel> fuser -k?
[12:47] <giftnudel> ;)
[12:47] <ogra>  human-cursors-theme (0.2-0ubuntu1) edgy; urgency=low
[12:47] <ogra>  .
[12:47] <ogra>    * New release:
[12:47] <ogra>      - moved cursor-theme from human-theme.
[12:47] <ogra> dholbach, ^^^^
[12:47] <ogra> did you also move the alternative setup ?
[12:48] <dholbach> yes
[12:48] <ogra> thanks :) 
[12:48] <dholbach> you could have looked before you asked ;-)
[12:48] <dholbach> cool
[12:52] <tfheen> Riddell: fixed
[12:53] <Riddell> thanks
[01:00] <Ng> sivang: does hubackup use gnome-vfs at all? like can I direct backups to a remote machine easily?
[01:01] <giftnudel> sivang: where is the main development branch of hubackup which I can check out to fiddle with it?
[01:02] <sivang> giftnudel: I love you forever ((tm) Martin Pitt) if you could join me in helping :-)
[01:02] <sivang> Ng: yes. the new version in edgy now uses a stock GNOME file selector that will allow your to save backup to any gnome-vfs mounted target.
[01:02] <giftnudel> let's say it that way, I like python and I like the idea, if I can help is really another question ;) (but I can try)
[01:03] <sivang> giftnudel: the really recent branch is now http://muse.19inch.net/~sivan/bzr/hubackup/hubackup--main
[01:03] <Ng> sivang: how new? I just ran it and it didn't show my gnome-vfs mounts in the selector
[01:03] <Ng> but maybe I have an older version
[01:03] <sivang> Ng: you on edgy?
[01:03] <Ng> yup
[01:03] <sivang> Ng: what kind of mounts do you have?
[01:04] <Ng> sivang: I have two sftp mounts in my Places menu
[01:07] <Ng> sivang: also, in the backup/verification windows, when it says it's finished, the button to make it go away still says "Cancel"
[01:07] <Ng> funky little app though :)
[01:07] <sivang> Ng: interesting. Either the stock selector lies, or I used it wrongly. Could kindly file a bug?
[01:07] <Ng> certainly
[01:07] <sivang> Ng: and also for the latter one? O:-) 
[01:08] <Ng> will do
[01:08] <Ng> I have a couple more too ;)
[01:08] <sivang> Ng: thank you. It started off as something "will be finished in no time" and continues growing at an alarming rate :-)
[01:09] <sivang> Ng: The amount of implementation issues discovered in attempting to bring the "no worries" workflow is enurmous.
[01:09] <Ng> that sounds quite normal ime ;)
[01:09] <Keybuk> pitti: ping
[01:09] <pitti> hi Keybuk 
[01:09] <Keybuk> pitti: has anybody spoken to you about kexec-tools and main?
[01:10] <Keybuk> or command-not-found ?
[01:10] <sivang> Ng: I hope so :-p
[01:10] <pitti> Keybuk: no
[01:11] <Keybuk> pitti: kexec-tools is a dependency of the linux-image-kdump package
[01:11] <Keybuk> and command-not-found is seeded in desktop
[01:11] <pitti> Keybuk: l-i-kdump should go into main?
[01:12] <tfheen> Keybuk: linux-image-kdump should be demoted.
[01:12] <Keybuk> pitti: we main anything built by the kernel by default
[01:12] <Kamion> it's hard to express that demotion in the seeds without expanding the %linux-meta entry, unfortunately
[01:12] <Kamion> which would be annoying
[01:12] <Kamion> is anyone working on a glibc upload?
[01:13] <infinity> linux-image-kdump isn't in linux-meta, it's in linux-source.
[01:13] <Kamion> infinity: good point
[01:13] <sivang> Ng: If you would, I'd like to have all your discovered bugs, thank you :)
[01:13] <infinity> THough I suspect the same argument may apply. :)
[01:13] <Kamion> it doesn't. why's linux-image-kdump in supported then ...
[01:13] <Keybuk> Kamion: because I put it there
[01:13] <Kamion> oh
[01:13] <Keybuk> you said to main anything built by linux-source, remember ;)
[01:14] <tfheen> I removed it yesterday, though
[01:14] <tfheen> it's not in the germinate output
[01:14] <tfheen> so it should be demotable.
[01:14] <Kamion> let's drop it back and get Ben to put universe/ in its control file
[01:14] <infinity> Right, so we're just talking in circles, but everything's okay? :)
[01:14] <Kamion> so the queue is still easily processable
[01:14] <infinity> Kamion: I already asked him to put universe/ in the control file, for the sake of our sanity with queue/new, yes.
[01:14] <Keybuk> tfheen: it's still in *ubuntu supported
[01:14] <tfheen> Keybuk: oh, probably yes.  That's easy to fix, though.
[01:15] <Kamion> I'm wondering whether I should fix bug 63234 by adding librt to libc6-udeb (which is what Debian did, but is an extra bit of space used just for xfsprogs) or link xfsprogs against librt statically
[01:15] <Ubugtu> Malone bug 63234 in debian-installer "installer unable to format xfs" [Undecided,Confirmed]  http://launchpad.net/bugs/63234
[01:15] <Kamion> leaning towards being in sync with Debian
[01:15] <Kamion> (it's only 30K)
[01:16] <infinity> Kamion: I'm sure something else will want it eventually.
[01:16] <Keybuk> ok, so mdz put command-not-found into desktop
[01:16] <Kamion> yeah
[01:16] <Keybuk> but didn't make an MIR for it
[01:16] <infinity> Kamion: Like the guy who complained on ubuntu-devel@lists a day ago.
[01:16] <Kamion> infinity: ?
[01:17] <infinity> https://lists.ubuntu.com/archives/ubuntu-devel/2006-October/021560.html
[01:18] <Kamion> /usr/lib/cdebconf/frontend/gtk.so doesn't link to librt directly in Debian, although it may do indirectly for all I know
[01:18] <mantiena-baltix> dholbach: hi, I wanna talk about translations in ubuntu-docs package, do  you have some time ?
[01:19] <dholbach> mantiena-baltix: I doubt I'm the right person for that
[01:19] <dholbach> mantiena-baltix: but what is your problem?
[01:21] <giftnudel> sivang: do you have any small things you liked to do to hubackup but have never gotten around?
[01:21] <mantiena-baltix> dholbach: I found you in changelog of ubuntu-docs package :) in Ubuntu Dapper ubuntu-docs source package was ~7Mb size, but  in edgy it's less than 1 MB, it seems translations were removed, right ?  
[01:21] <dholbach> mantiena-baltix: you might want to talk to mdke or people in #ubuntu-doc - I'm not sure, but I guess that translations should be in the language-packs, no?
[01:22] <mantiena-baltix> dholbach: I also think so, but in dapper all translations were in ubuntu-docs package :(
[01:22] <mantiena-baltix> ok I will talk on #ubuntu-doc
[01:22] <dholbach> ok cool
[01:23] <infinity> Files: 
[01:23] <infinity>  42034af3a900c210a282d677ae6a0322 327544 text optional ubuntu-docs_6.10.1_all.deb
[01:23] <infinity>  0a4a580670e541d70d30dd40030f121c 122965 raw-translations - ubuntu-docs_6.10.1_i386_translations.tar.gz
[01:23] <infinity> The translations were stripped and fed to rosetta, so they'll be in the langpacks.
[01:23] <dholbach> Thanks infinity.
[01:23] <mantiena-baltix> infinity: ok, thanks
[01:23] <infinity> Well, some translations anyway, I don't know if that's "all of them"
[01:23] <infinity> Cause I'm not sure how the package is laid out.
[01:24] <sivang> giftnudel: let me think :)
[01:25] <Keybuk> tfheen: can I make a really scary request?  we ship gettext 0.14 which isn't completely compatible with the version of autoconf and automake we ship (doesn't support datarootdir)
[01:25] <Keybuk> could we merge that with Debian's 0.15?
[01:29] <tfheen> Keybuk: how big and scary is the diff?
[01:29] <fabbione> tfheen: are you sure you want to know? :P
[01:29] <tfheen> fabbione: I LOVE big and scary diffs.  Didn't you know?
[01:30] <fabbione> tfheen: ehhee
[01:30] <Keybuk> tfheen: the diff between 0.14.6-1 and 0.15.2 ?
[01:30] <Keybuk> oh, a mere 21MB
[01:30] <tfheen> uh.
[01:30] <tfheen> that's.  scary.
[01:31] <tfheen> is there anything which is _broken_ if we don't upgrade?
[01:31] <Keybuk> I wouldn't ask, except the merge is clean and it's in unstable
[01:31] <Keybuk> in theory any package developed on Ubuntu that uses gettext is fractured
[01:31] <Keybuk> not completely broken
[01:32] <Kamion> and in practice?
[01:33] <Keybuk> it means ./configure --dataroot=/usr/share won't do the right thing
[01:33] <Keybuk> it'll put translations in /usr/local/share
[01:34] <tfheen> that single thing sounds backportable quite easily.  Isn't it?
[01:34] <Keybuk> it's hard to gauge because --dataroot is new, so most people may still be building with --datadir= instead
[01:35] <Keybuk> tfheen: it involves remaking Makefile.in.in ... which is ... N-hard
[01:35] <Keybuk> it certainly means any software developed on Ubuntu gives an ugly warning during ./configure
[01:36] <seb128> dholbach: ubuntu-docs translations to rosetta, how would that work?
[01:36] <Keybuk> it may be enough to just add datarootdir = @datarootdir@ to the one in our package
[01:36] <seb128> dholbach: aren't documentation file .xml which have to be translated (ie: don't use gettext)?
[01:38] <Keybuk> tfheen: yes, that gets rid of the warning
[01:38] <seb128> Keybuk: I've seen warnings about that for a bunch of packages with autoconf updates too
[01:39] <tfheen> Keybuk: I'd be far happier with that than a new upstream version of gettext, really.
[01:39] <Keybuk> seb128: yes, updating autoconf or automake and not updating gettext is the cause
[01:39] <Keybuk> tfheen: I'm just grepping gettext for any use of that variable, other than having it in Makefile.in.in to allow datadir to be defined based on it
[01:41] <tfheen> ok, so let's just go for the one-line patch solution then?
[01:41] <Keybuk> yup
[01:42] <Kamion> right, I think that's LVM and RAID in a rather healthier state in the installer now
[01:43] <fabbione> Kamion: there was another duplicate bug of the one you just closed...
[01:43] <fabbione> Kamion: can't remember the number tho
[01:44] <Kamion> you mean one not already marked as a duplicate?
[01:44] <fabbione> probably....
[01:44] <Kamion> if you find it, feel free to mark it
[01:44] <tfheen> dholbach: it seems nautilus's sendto thingy with obex doesn't work because gnome-obex-send doesn't grok gVFS URIs.
[01:44] <fabbione> the one in which i did add comments..
[01:44] <fabbione> Kamion: willdo
[01:44] <Kamion> ta
[01:45] <dholbach> seb128: you can use translations for .xml files too
[01:45] <dholbach> seb128: isn't @INTLTOOL_XML_RULE@ for stuff like that?
[01:45] <dholbach> tfheen: ahhhhhh!
[01:45] <dholbach> tfheen: I'll have a look at that after lunch
[01:46] <tfheen> dholbach: so it gets a file not found when passed file:///whatever.  Thanks. :-)
[01:46] <dholbach> tfheen: thanks
[01:47] <tfheen> dholbach: and we'd need to get bluez-gnome in, but that's doable.
[01:47] <dholbach> tfheen: for main?
[01:47] <dholbach> tfheen: did you play with it?
[01:48] <tfheen> dholbach: bluez is kinda useless if you can't pair your phone, don't you agree?
[01:48] <dholbach> I do
[01:48] <funman> hi
[01:48] <seb128> dholbach: not that I know of
[01:49] <tfheen> dholbach: are you in touch with fschoep?  Any idea about when we'll get the final artwork?
[01:49] <seb128> dholbach: usually such magic is to list strings to a .po so translators can translate them
[01:49] <dholbach> tfheen: I'll prod him about it.
[01:49] <tfheen> thanks
[01:49] <seb128> dholbach: then transitions are used to build translated .xml during the build
[01:49] <tfheen> dholbach: please do remind him that we freeze on thursday.
[01:49] <seb128> s/transitions/translations
[01:49] <dholbach> seb128: I'm not sure, that's why I pointed him to #ubuntu-doc
[01:50] <sivang> giftnudel: so for the free space in a multi session CD, there are some hints in nautilus-cd-burner we might be able to borrow. However, they are in C and not in python.
[01:51] <seb128> ncb doesn't do multisession
[01:54] <giftnudel> sivang:  if ncb can't do that. then I'll see how gnomebaker does that
[01:54] <sivang> seb128: true (due to the fact that CDs are so cheap these days ;-)) but I'm sure I've seen code there that reports how much free space is left on A CD.
[01:54] <sivang> giftnudel: that would be cool, thank you!
[01:55] <giftnudel> i'm sure they got that right ;)
[02:00] <tfheen> ok, so the bluez-passkey-gnome seems to work.  That means we "just" have to get the hci config to scan by default
[02:04] <Keybuk> tfheen: so this gettext thing turns out to be hard
[02:04] <Keybuk> the Makefile.in.in and Makefile.in that need patching are inside archive.tar.gz
[02:05] <Keybuk> which is a tarball inside the orig.tar.gz\
[02:05] <Keybuk> (so can't be patched by diff.gz)
[02:06] <tfheen> well, we can repack the orig.tar.gz if we really want to.
[02:06] <tfheen> or we could have a patch system in there.
[02:06] <Keybuk> patch system can't patch binary tarballs?
[02:10] <tfheen> it could unpack and repack the tarball
[02:10] <tfheen> ugly, agreed
[02:10] <Keybuk> this seems rather intensively evil just to avoid updating the tarball
[02:10] <Keybuk> and more error-prone
[02:10] <tfheen> heno: have you heard anything from TheMuso regarding casper and accessibility?
[02:10] <tfheen> Keybuk: well, let's just repack the tarball then.
[02:11] <Keybuk> oh, and not only are they inside the archive.tar.gz
[02:11] <Keybuk> they're RCS files!
[02:11] <tfheen> \o/.  Or something.
[02:11] <heno> tfheen: no, but he should be here
[02:12] <heno> tfheen: can you point me at the actual scripts somewhere so I can have a look
[02:12] <lifeless> t east RCS files are patchable
[02:12] <heno> alternatively, any suggestions on debugging it?
[02:12] <seb128> heno: hi, should bug #59553 be fixed for edgy? did the patch get testing?
[02:12] <Ubugtu> Malone bug 59553 in control-center "launch AT apps from gnome-at-prefs" [Wishlist,Confirmed]  http://launchpad.net/bugs/59553
[02:12] <tfheen> heno: apt-get source casper gets you something which is fairly fresh and up to date.
[02:14] <heno> seb128: yes please. I've tested it myself, but I think that's it
[02:14] <heno> tfheen: thanks
[02:14] <seb128> heno: ok, I'll look at it now
[02:16] <Fade> tfheen: I updated the xemacs bug with the workaround.
[02:16] <Keybuk> lifeless: are you saying RCS is better than bzr? :)
[02:16] <Fade> the segfault is still there, but it should be pushed upstream, imo.
[02:17] <tfheen> Fade: fabbione did some font updates which could have fixed this yesterday or so
[02:17] <Fade> I had already updated my configs at that point, so I can't verify.
[02:17] <sivang> giftnudel: n-c-b seems to be using gnome_vfs_get_volume_free_space, it probably should have some python bindings we coudl use, but make sure this reports free space on multisessoin CDs (RW/R)
[02:18] <giftnudel> I just created a multisession cdrw
[02:18] <fabbione> tfheen: unlikely.. the changes were related only to versioned Depend to fix dapper -> edgy partial upgrades
[02:18] <giftnudel> sivang: cdrecord -msinfo does return some information for mkisofs, maybe this is usable too
[02:18] <tfheen> fabbione: hmkay.
[02:19] <sivang> giftnudel: true, see if you can find a way to integrate it into DeviceInfo.py's list, I actually experimented with this not sure why I left it eventually.
[02:20] <giftnudel> sivang: I see if, at some point can get a reliable size
[02:20] <lifeless> Keybuk: in this one regard, it can do something bzr can't :)
[02:23] <giftnudel> sivang: gnomebaker uses the -msinfo info and seems to get the size from there, I'll see if I can find out how they do it ;)
[02:24] <sivang> giftnudel: hehe, funny, What about the gnome-vfs thingy?
[02:24] <giftnudel> well, they don't use it
[02:24] <sivang> giftnudel: okay, cool, let's stick to the gnomebaker approach
[02:29] <sivang> giftnudel: if we can come up with two functions, one that tells the complete volume / media size (not free space) and ones that tells the free space left on a medium, we win. the former will also cater for hal's reporting capacity basically as volume size.
[02:29] <sivang> giftnudel: (this sometimes breaks setting up correct slice size)
[02:31] <kristog> hello
[02:36] <mantiena-baltix> pitti: could you tell me if regexps are supported in /etc/pmount.allow ?
[02:40] <pitti> mantiena-baltix: no, not right now
[02:41] <mantiena-baltix> pitti: I found some code in device_whitelist:
[02:41] <mantiena-baltix>  const char*  whitelist_regex = "^[[:space:] ] *([[:alnum:] /_+.\-] +)[[:space:] ] *(#.*)?$";
[02:41] <mantiena-baltix> pitti: what does this code ?
[02:42] <pitti> mantiena-baltix: it checks the validity of an entry in the whitelist
[02:42] <pitti> mantiena-baltix: basically, a device name surrounded by some whitespace and comments
[02:44] <mantiena-baltix> pitti: could you add support for regexps in pmount.allow ? It would be very good to have an ability to write for example /dev/sd* in pmount.allow to have an ability to mount all SCSI/SATA devices
[02:45] <giftnudel> sivang, do you know how they do it? They try to mount the cd and add up the size of all files in the disc
[02:45] <pitti> mantiena-baltix: I'm not convinced that this is very useful, but feel free to file a wishlist bug :)
[02:46] <pitti> mantiena-baltix: IOW, I agree that this is an useful feature, but it's not high-priority on my todo list
[02:51] <mantiena-baltix> pitti: It's hard to add regexp feature for /etc/pmount.allow ?
[02:51] <pitti> mantiena-baltix: not terribly, no, just a SMOP
[02:53] <Keybuk> tfheen: nope, there is no way to do this
[02:54] <Keybuk> not without serious RCS-file surgery of a revision several away from the head, and manual fixing of those since
[02:54] <Keybuk> (it checks out against a tag)
[02:55] <tfheen> Keybuk: *sigh*.
[02:57] <Keybuk> they've done everything possible to make it impossible to just patch that file :-(
[02:57] <tfheen> and the archive.tar.gz is what's shipped in the deb?
[02:58] <heno> tfheen: I grabbed casper version 1.73 from LP; I assume I can use that. I see various obsolete things in the script. I'll update and make a patch.
[02:59] <Keybuk> tfheen: yeah
[02:59] <mantiena-baltix> pitti: I could try to add but my regexp knowledge is not big, especially for regexps in C :(
[02:59] <pitti> mantiena-baltix: well, the function already handles regexps for checking the pmount.allow format
[02:59] <infinity> A little RCS surgery never killed anyone.  In fact, it used to be a hobby of mine.
[03:00] <pitti> mantiena-baltix: you can use the same scheme for matching the entry against the device name
[03:00] <StevenK> infinity: Yes, but you're a masochist.
[03:00] <Kamion> mantiena-baltix: for a start, "/dev/sd*" isn't a regex, unless you really mean "/dev/s followed by zero or more d characters"
[03:00] <tfheen> heno: excellent, thanks.
[03:01] <Kamion> mantiena-baltix: the correct term for things like /dev/sd* is "glob" or "shell pattern"
[03:02] <mantiena-baltix> Kamion: ok, I mean glob support in pmount.allow
[03:02] <Keybuk> tfheen: so what you want to do?
[03:02] <pitti> mantiena-baltix: yeah, I would be more comfortable with globs, too
[03:02] <tfheen> Keybuk: strangle the hcid author?
[03:02] <tfheen> Keybuk: about gettext.. if Adam volunteers to hack the ,v file, let him?
[03:02] <sivang> giftnudel: maybe they export this function of their as a module ?
[03:02] <sivang> giftnudel: so we could just import or use?
[03:03] <Keybuk> tfheen: want to do it?
[03:03] <Keybuk> it's two RCS files inside archive.tar.gz inside the orig.tar.gz files
[03:03] <mantiena-baltix> pitti: regcomp function handles globs or I should use another function for this ?
[03:03] <Keybuk> gettext checks out some arbitrary old revision
[03:03] <tfheen> dholbach: so, do you actually have any bluetooth hardware?  If so, can you test a fix for me.
[03:03] <pitti> mantiena-baltix: no, regcomp handles regular expressions
[03:03] <tfheen> Keybuk: a revision and not just a tag?
[03:03] <pitti> mantiena-baltix: use glob() for shell patterns (globs)
[03:03] <pitti> sivang: it does after pushing the first time
[03:03] <giftnudel> sivang: for me it does that
[03:03] <Keybuk> tfheen: I honestly don't know, it's a maze of twisty shell that does it
[03:03] <tfheen> sivang: bzr push --remember ?
[03:04] <pitti> sivang: if you want to change it, use --remember
[03:04] <jdong> sivang: --remember; set up branch aliases if you want to remember more
[03:04] <Keybuk> and, annoyingly, gettextize and autopoint appear to do different things
[03:04] <sivang> tfheen: yep, that's what i needed. it never does it automatically for me for some odd reason.
[03:04] <sivang> jdong: haha
[03:04] <sivang> jdong: that is read as a natural language sentence :)
[03:04] <jdong> lol :)
[03:04] <dholbach> use --remember
[03:05] <tfheen> Keybuk: I'm really not happy about putting in a new upstream version at this point -- particularly not something where the diff weighs in at 21MB.
[03:05] <giftnudel> sivang: what do you mean, gnomebaker is c as well?
[03:06] <Keybuk> tfheen: I can understand that, but I don't think we should ship a broken gettext either
[03:06] <Keybuk> as this affects any developer who uses ubuntu, and all their users
[03:06] <tfheen> Keybuk: yes..
[03:07] <infinity> Keybuk: What's the bug# here, and the patch that needs applying?
[03:07] <giftnudel> sivang: anyhow, I get a feeling why you stopped looking at it (there is no really easy way to do these things, for example, get the size of a cd medium)
[03:07] <Keybuk> infinity: I haven't filed a bug yet
[03:07] <infinity> Keybuk: Can you? :)
[03:07] <Keybuk> infinity: the patch is adding "datarootdir = @datarootdir@" before the datadir= line in ever occurance of po/Makefile.in.in and intl/Makefile.in
[03:07] <infinity> Keybuk: I'll poke at the RCS hacking route, and if it looks sufficiently low in crack, I'll just do it.
[03:07] <ogra> infinity, any news about the archive bug that makes my ppc CD explode ?
[03:08] <Keybuk> infinity: the RCS tree is inside archive.tar.gz, it checks out a non-head revision to copy into the package when you update it
[03:09] <infinity> If not, we'll need to argue about the right thing to do.
[03:09] <infinity> (Maybe checkout both branches, and alter the build system to just used the checked out copies, or similar scariness)
[03:09] <Keybuk> build system?
[03:09] <Keybuk> nothing to do with the build system
[03:09] <Keybuk> this is the installed system
[03:09] <Keybuk> /usr/share/gettext/archive.tar.gz
[03:10] <sivang> giftnudel: yes, it's very discouraging. I wish there was a unified API for this things, but there will not be , until libburn will be finished with multi session support.
[03:11] <sivang> giftnudel: still, just copying with gnomebaker does could be useful, no?
[03:11] <zul> pitti: ping
[03:11] <pitti> hey zul
[03:11] <sivang> giftnudel: hal also does not make it easy, as 'capacity' is always the size of the volume, not the true capacity of the medium.
[03:11] <sivang> anyway, I really need to get lunch now before I'll drop! 
[03:11] <Keybuk> bug #65063
[03:11] <Ubugtu> Malone bug 65063 in gettext "Doesn't support datarootdir" [High,Confirmed]  http://launchpad.net/bugs/65063
[03:11] <sivang> giftnudel: ttl
[03:12] <giftnudel> ok
[03:12] <zul> pitti: hi i have a question on one of the security patches for the kernel-sec svn, the s390 patch we shouldnt really care about it should we?
[03:12] <pitti> zul: I marked it as 'ignore'
[03:12] <zul> ah ok
[03:12] <pitti> zul: since we don't have that platform anyway, not even as port
[03:12] <zul> pitti: heh i just needed more coffee
[03:13] <sivang> giftnudel: that was meant with a ;-) , sorry for not supplying it
[03:13] <giftnudel> sivang: yes, the gnomebaker approach of just opening the disc and reading the size of all files seems the easiest way
[03:13] <giftnudel> sivang: oh, I understood it that way
[03:14] <tfheen> dholbach: if you have any bt hardware, please try adding "discovto 0;" (no quotes) in the device { section in /etc/bluetooth/hcid.conf, rm -rf /var/lib/bluetooth/* and restart hcid/bluetooth.
[03:16] <pitti> infinity: do you see any reason to keep php4 in edgy?
[03:16] <pitti> infinity: I'm just doing another php security update and I'm too lazy/busy to fix it for the universe php4's, too
[03:17] <infinity> pitti: I see reasons to keep it in Etch, but if you'd prefer to drop it from Edgy, I don't know if I care so much.
[03:17] <infinity> pitti: We draw such a clear line between supported and unsupported, that people would be a fool to run the "alternate php" anyway.
[03:17] <pitti> infinity: oh, wait, it has a fair number of rdepends
[03:17] <infinity> (It does still have uses, but most stuff should work with both)
[03:19] <giftnudel> sivang: I'll write down what I found out and what we could try, i have an idea, I will notify you when it's ready
[03:21] <infinity> Keybuk: Right, s/build system/whatever the fuck does an RCS checkout/ then.
[03:22] <infinity> Keybuk: Anyhow, file a bug and subscribe me to it, SVP?
[03:22] <StevenK> infinity: [23:11]  < Keybuk> bug #65063
[03:22] <Ubugtu> Malone bug 65063 in gettext "Doesn't support datarootdir" [High,Confirmed]  http://launchpad.net/bugs/65063
[03:23] <infinity> StevenK: Thanks, I'm half asleep.
[03:23] <Keybuk> infinity is clearly a "glass half empty" kinda guy
[03:23] <tuhl> what is the right channel to discuss xen on edgy?
[03:24] <zul> #ubuntu-xen or me
[03:24] <tuhl> crimsun: I solved the python problem, by removing all packages and reinstall them :-)
[03:25] <tfheen> zul: oh, speaking of xen.  Any reason why the ubuntu-xen repo's master branch isn't the right one?
[03:25] <zul> tfheen: for 2.6.16 or 2.6.17?
[03:25] <tfheen> zul: we have/want to switch to .17 don't we?
[03:26] <zul> we have switch to .17
[03:26] <mantiena-baltix> pitti: pmout uses debug function for debug messages - how I can read these messages?
[03:26] <pitti> mantiena-baltix: pmount -d
[03:26] <zul> i just havent had a chance to update the git repository yet for 2.6.17
[03:26] <tfheen> zul: ok.
[03:26] <pitti> mantiena-baltix: or, if you use pmount-hal, export PMOUNT_DEBUG=1
[03:26] <pitti> mantiena-baltix: (see manpages)
[03:26] <zul> tfheen: its on my todo list for tonight
[03:28] <tfheen> zul: cool, thanks.
[03:30] <mantiena-baltix> pitti: thanks
[03:30] <jdong> who do I subscribe in LP for UVF exceptions?
[03:31] <jdong> the wiki's down so I couldn't pull up the doc
[03:32] <giftnudel> sivang: http://paste.ubuntu-nl.org/26158/ - I have put down the idea there
[03:37] <giftnudel> pitti: I don't understand why you closed bug 59981 again, this is the exact same issue /etc/dbus.d/event.d/20hal restart, 25networkmanager restart did fix this (as before)
[03:37] <Ubugtu> Malone bug 59981 in hal "suspend makes network-manager say eth1 is a wired device" [Undecided,Fix released]  http://launchpad.net/bugs/59981
[03:39] <pitti> giftnudel: NB that you have to restart hal, not network-manager
[03:39] <pitti> giftnudel: i. e. reboot to be on the safe side
[03:39] <pitti> giftnudel: and the fix was confirmed by several other people
[03:39] <pitti> if it doesn't work for you, then it must be a different cause
[03:39] <giftnudel> well, it worked for me too, but I had this once in 7 suspends ...
[03:40] <giftnudel> yeah, guten appetit
[03:52] <mantiena-baltix> tfheen: I have one good idea about mounting hard disk partitions in live CD :)
[03:52] <mantiena-baltix> tfheen: you told, that we need a daemon like gnome-volume-manager, right ?
[03:58] <mantiena-baltix> tfheen: so, maybe we don't need another daemon, maybe we should just improve gnome-volume-manager  ? ;)
[04:11] <pitti> giftnudel: re
[04:12] <giftnudel> pitti: let me reboot and see if I get that again, but I'm really sure that I installed the most recent version before I got this problem
[04:13] <pitti> giftnudel: ok
[04:13] <giftnudel> pitti: also, I wouldn't have reopened it, if there hadn't been a duplicate reported today
[04:13] <pitti> giftnudel: do not get me wrong, I don't blame you for that, I just want to track them properly
[04:16] <Kamion> ogra: the archive bug is fixed; your next CD builds should be within size limits
[04:16] <Kamion> jdong: ubuntu-release
[04:16] <Kamion> jdong: (for main; I forget for universe)
[04:16] <jdong> Kamion: yep, thanks, figured it out
[04:16] <ogra> Kamion, yippie, you roock !
[04:16] <ogra> -o
[04:16] <giftnudel> pitti: yes, I know, I just wanted to tell you why I thought a reopen would be justified
[04:19] <pitti> giftnudel: if it still happens, please open a new bug for now and attach /proc/net/wireless and lshal before and after suspending
[04:20] <giftnudel> pitti: ok, I will do that, thanks a lot
[04:20] <pitti> would be nice to settle that for edgy
[04:21] <StevenK> jdong: motu-uvf for universe
[04:21] <StevenK> (Just so you know)
[04:21] <jdong> StevenK: yep
[04:21] <jdong> I'm more familiar with universe UVFe's than main ones
[04:23] <mantiena-baltix> Kamion: what you think about adding mounting hard disk partition for LiveCD functionality into gnome-volume-manager  ? Why to write another daemon when there is daemon for partition mounting already ?
[04:25] <pitti> mantiena-baltix: (For the record, I'm the person who breaks g-v-m usually)
[04:25] <pitti> mantiena-baltix: I don't really see how that should work TBH
[04:25] <Kamion> mantiena-baltix: I'm not qualified to say
[04:25] <pitti> mantiena-baltix: g-v-m runs in the user's session, it would need some backend to do this
[04:25] <pitti> mantiena-baltix: for example, adding the partitions to /etc/fstab
[04:26] <pitti> mantiena-baltix: g-v-m and Utopia are very bad at/not designed for handling static hard drive partitions
[04:26] <mantiena-baltix> pitti: hehe, it seems you are the person, who breaks most of things, I'm talking about ;)
[04:26] <pitti> mantiena-baltix: sorry :/
[04:27] <jdong> pitti: btw, have you come to any sort of decision on the mWhr conversion patch in hal?
[04:27] <pitti> mantiena-baltix: My gut feeling is that a simple gksudo mount wrapper on the nautilus level, combined with a small hal fix to display unmounted hard disk partitions is the way to go
[04:27] <mantiena-baltix> pitti: btw, I don't see difference in handling static or removable partitions when runing from LiveCD
[04:27] <pitti> jdong: oh, sorry, didn't yet find time for this bug; I'll do another session today, promised
[04:28] <pitti> mantiena-baltix: it's not live CD specific at all, unless you aim for a casper solution
[04:28] <pitti> mantiena-baltix: everything !casper, i. e. nautilus, pmount, g-v-m have to work identically in the live and the instlaled system
[04:29] <pitti> mantiena-baltix: so either you modify casper to add them to fstab (user-mountable), or we modify gnome to allow the user mounting hard drive partitions through gksudo
[04:29] <pitti> mantiena-baltix: the latter will become much easier in edgy+1 when we get gnome-mount, btw.
[04:30] <pitti> which alternative we take depends on whether or not we want the same functionality in the installed system
[04:30] <mantiena-baltix> pitti: yea, I understand you, thanks for info about gnome-mount. btw, where I can get gnome-mount ?
[04:30] <giftnudel> pitti: it looks good with some quick tests but I will open a bug when I encounter it again
[04:30] <pitti> mantiena-baltix: it's in Debian now, or you just build the upstream version
[04:30] <pitti> mantiena-baltix: but it requires hal 0.5.8.1
[04:31] <jdong> waaah, BenC... unusual-dev... :(
[04:31] <pitti> giftnudel: it is possible that the dup was because the user didn't reboot
[04:31] <mantiena-baltix> pitti: why it requires such new hal ?
[04:31] <sivang> re giftnudel 
[04:31] <giftnudel> pitti: : yes probably
[04:31] <pitti> mantiena-baltix: well, basic gnome-mount works with edgy's hal, too
[04:31] <sivang> giftnudel: thanks for the research, seems interesting
[04:31] <pitti> mantiena-baltix: just not the more elaborate features
[04:32] <pitti> mantiena-baltix: I successfully used gnome-mount 0.4 here on edgy
[04:32] <giftnudel> sivang: funnily, your deviceinfo works nicely with my quickly burnt multi-session-cd
[04:32] <sivang> giftnudel: are you sure?
[04:32] <giftnudel> sivang: it reports the size and the capacity correctly
[04:33] <giftnudel> yes
[04:33] <sivang> hmm
[04:33] <giftnudel> it doesn't work with a single-session dvd
[04:33] <giftnudel> well it works
[04:33] <giftnudel> but the capacity is of course just the size (since you can't add more)
[04:34] <giftnudel> actually, all looks nice ;)
[04:34] <sivang> giftnudel: hmm, can you paste the output somewhere ? or do you see it in the hubackup gui ?
[04:34] <giftnudel> I will privmsg you, it's not that much
[04:34] <sivang> sure, thanks
[04:35] <jdong> does anyone want to consider bug 57872 and the fix I proposed?
[04:35] <Ubugtu> Malone bug 57872 in gnome-power "regression: pressing power button no longer brings up logout dialog" [Unknown,Unconfirmed]  http://launchpad.net/bugs/57872
[04:35] <jdong> a few users have reported back that it fixes the problem
[04:35] <jdong> no negative feedback
[04:43] <dholbach> tfheen: with bluez-utils 3.1 or 3.7?
[04:44] <tepsipakki> jdong: ask seb128 directly?
[04:45] <jdong> tepsipakki: yeah, perhaps I should... I wasn't sure if he (or anyone) is responsible for the package
[04:47] <tepsipakki> jdong: actually, ogra has done latest uploads..
[04:47] <tepsipakki> of g-p-m
[04:47] <jdong> I really don't mind who... just someone please weigh in on it....
[04:47] <ogra> jdong, urgh, why is this patch 4.5M compressed ?
[04:47] <jdong> ogra: it's not just the patch... I just zipped up pbuilder/result after the build finished
[04:48] <jdong> which includes the source and binaries
[04:48] <ogra> ah
[04:48] <jdong> binaries because people tend to be more motivated to test binaries :)
[04:48] <jdong> the actual patch is to delete the first hunk from patch 56
[04:48] <tepsipakki> jdong: just attach the patch
[04:48] <ogra> but that will mean it always saves the session
[04:48] <jdong> ogra: no it doesn't
[04:49] <jdong> the first hunk is calling the logout dialog
[04:49] <jdong> the second hunk saves the session
[04:49] <jdong> an interactive save session request = logout dialog
[04:49] <jdong> I've confirmed that it does not save the session
[04:49] <tfheen> dholbach: yes, both please.
[04:50] <ogra> jdong, oh, right, i'll revert that in the patch then ... what bothers me is that it worked in 2.14, the pacth is a direct port
[04:50] <jdong> ogra: hmm, really? that's really odd then
[04:51] <ogra> yes
[04:51] <jdong> ogra: because post-patching, the else if branch for interactive logout is blank
[04:51] <jdong> except for a log function call
[04:51] <ogra> but if it doesnt force the saving of the session, its fine to revert that part
[04:51] <jdong> I'm positive it doesn't force the saving of the session
[04:51] <ogra> ok, i'll redirect angry users to you then ;)
[04:52] <jdong> oh boy :)
[04:54] <dholbach> tfheen: looks good!
[04:55] <tfheen> dholbach: so it then enters discoverable mode for you by default?
[04:56] <dholbach> tfheen: it looks like
[04:56] <tfheen> dholbach: yay.  Then we "just" need to fix the passkey problem.
[04:56] <dholbach> tfheen: let's see what people answer to the bug report
[04:56] <dholbach> tfheen: i'll look at nautilus-sendto now
[04:56] <dholbach> tfheen: we should sync bluez-gnome anyway
[04:56] <dholbach> ;)
[04:57] <tfheen> dholbach: ok, thanks.  Yes, we should grab bluez-gnome.  mjg59 seemed to wish for bluez-{libs,utils} 3.7; I can't really comment on that.
[04:58] <mantiena-baltix> tfheen: have you read pitti talks about mounting hard disk partitions ?
[04:58] <tfheen> mantiena-baltix: no.
[04:59] <dholbach> tfheen: i flicked through the changelogs and it seems that they fixed a lot of issues
[04:59] <mantiena-baltix> tfheen: you told, that we need a daemon like gnome-volume-manager
[04:59] <tfheen> dholbach: can you draft an UVF exception request then?
[04:59] <mantiena-baltix> my idea was, that we don't need another daemon, maybe we should just improve gnome-volume-manager  
[05:00] <seb128> jdong: you are pinging for 3 days about that patch now, no?
[05:00] <seb128> jdong: didn't Kamion said he would have a look yesterday?
[05:00] <dholbach> tfheen: Ok, I'll send it to you and mjg59 to take a 2nd look
[05:00] <mantiena-baltix> tfheen: and pitti told, that we could use gnome-mount ;)
[05:00] <jdong> seb128: on and off for a few days... I didn't catch it if Kamion said so
[05:00] <tfheen> dholbach: thanks.
[05:00] <jdong> sorry, I thought nobody responded
[05:01] <mantiena-baltix> tfheen: (17:29:18) pitti: mantiena-baltix: so either you modify casper to add them to fstab (user-mountable), or we modify gnome to allow the user mounting hard drive partitions through gksudo
[05:01] <mantiena-baltix> (17:29:31) pitti: mantiena-baltix: the latter will become much easier in edgy+1 when we get gnome-mount, btw.
[05:01] <tfheen> mantiena-baltix: I guess I'll revisit this after edgy, then.
[05:02] <seb128> jdong: I'm probably mixing that with something else
[05:02] <mantiena-baltix> tfheen: ok, don't forget this !
[05:04] <seb128> jdong, ogra: I've not followed the issue, but might be due to bug #62163
[05:04] <Ubugtu> Malone bug 62163 in control-center "variables from the session are not defined" [Unknown,In progress]  http://launchpad.net/bugs/62163
[05:04] <seb128> cf https://launchpad.net/distros/ubuntu/+source/control-center/+bug/63423 too
[05:04] <Ubugtu> Malone bug 63423 in control-center "[Edgy]  keybind for "Log out" does not work" [Unknown,Unconfirmed]  
[05:04] <mantiena-baltix> tfheen: I think now best solution for me would be to patch pmount to understand globs in /etc/pmount.allow and to put these lines into dapper-based Live CD:
[05:04] <mantiena-baltix> /dev/hd*
[05:04] <mantiena-baltix> /dev/sd* 
[05:04] <pitti> mantiena-baltix: ouch
[05:05] <pitti> mantiena-baltix: then you should make damn sure to not install that pmount.allow into the final system
[05:05] <tfheen> mantiena-baltix: I don't care what you're doing in baltix, but we will not do any such changes in Ubuntu at this point.
[05:06] <ogra> seb128, hmm, should i hold back the g-p-m change and wait for your fix then ?
[05:06] <ogra> to check that its really caused by SESSION_MANAGER ?
[05:06] <mantiena-baltix> pitti: of course I'm not planing to put these lines into installed system
[05:06] <seb128> ogra: it's not sure we will fix gnome-session for edgy
[05:06] <ogra> ok, then i'll go on
[05:07] <seb128> ogra: upload your workaround, we will revert it if required
[05:07] <ogra> just testbuilding here ... 
[05:07] <mantiena-baltix> tfheen: I understand, I just wanna find best solution for dapper-based LiveCD
[05:07] <ogra> (pbuilder is outdated and i get shitty bandwith :( )
[05:12] <Kamion> seb128: I think you're confusing that with something else, or at least I hope I didn't go temporarily insane and say I'd do it
[05:13] <seb128> Kamion: yeah, I had a look at my IRC log, you were probably replying to somebody else, there was several people speaking on the chan yesterday evening ;)
[05:14] <ogra> we should fobid that :P
[05:16] <Kamion> yeah, I was talking to Tonio about a main inclusion request
[05:16] <janimo> ogra: hi, did you get my mail re ldm and gnomecanvas?
[05:16] <BenC> $ sudo apt-get -u dist-upgrade
[05:16] <BenC> Segmentation fault (core dumped)
[05:16] <BenC> wonder when that started
[05:17] <ogra> janimo, ouch, i forgot to reply ... i dont think thats feasable this late in the release ...i'm not sure ldm uses *only* gnomecanvas and the change would also require a change to some ltsp bits (the installer etc)
[05:18] <ogra> i'd rather have had that request a month ago now its a bit late to get proper testing for it
[05:18] <janimo> ogra, no it really only uses gnome canvas
[05:18] <janimo> and besides the rest of python-gnom eis in the lareday installed desktop
[05:18] <janimo> ogra, grep fro import in the sources
[05:18] <janimo> it's only gnome canvas
[05:18] <janimo> :)
[05:18] <ogra> janimo, i wrote it, i know whats in there
[05:19] <janimo> well a month ago the package split was only discussed
[05:19] <KhanFounded> gnome canvas is so cruel, takes a lot less elves for the same area
[05:19] <janimo> ogra, so why do you sayd then you are not sure that is the only gnome thing? I thought you said that before
[05:20] <janimo> ogra, and I mailed as soon as python-gnomecanvas hit the archives. And that timing was beyond me believe me :)
[05:20] <ogra> right, its still vers ylate 
[05:20] <ogra> *very late
[05:21] <ogra> freeze is in two days ... if the installer breaks due to broken dependencys i wont have the time to fix everything 
[05:21] <ogra> ltsp is bigger than ldm
[05:22] <ogra> if i find the time tonight i'll do some testing, but i'm noit really fond of causing possible breakage *now*
[05:26] <Petaris> ajmitch: Any progress with the network authentication bits?
[05:29] <janimo> ogra: cannot really cause breakage I am sure, as you'll just change the package (if you chose) to only Depend: on what it uses
[05:29] <ogra> janimo, and rewrite the installer 
[05:29] <janimo> and if by some mircale that dep was broken anyway you still have the original deps in teh default install
[05:30] <ogra> it *is* a lot moire than just changing this one dependency
[05:30] <janimo> ogra: same thing is done in update-manager in dapper
[05:30] <janimo> ogra, what else is there besides the dep?
[05:30] <janimo> I must have missed something LTSP specific then
[05:30] <ogra> the installer plugins that resolve dependencys etc
[05:31] <Kamion> huh?
[05:31] <Kamion> ogra: what's the problem here?
[05:31] <janimo> ogra, but supposing the package only depends on gnome-canvas then there's no extra work right?
[05:31] <Kamion> beyond hand-waving about installer problems
[05:31] <janimo> Kamion: ldm depends on python-gnome2 now but can only use the recently split python-gconf now
[05:31] <Keybuk> seb128: new rhythmbox is confusing me ... it's given me an icon for my iAudio, which contains its contents
[05:32] <Keybuk> should I also add that to my library?
[05:32] <ogra> Kamion, ltsp-build-client's plugin system needs changes if i change a dependency of an installed package
[05:32] <ogra> Kamion, its not about d-i
[05:32] <Kamion> ogra: oh, so not the core installer then
[05:32] <ogra> no :)
[05:32] <Kamion> due respect but that's rather broken
[05:32] <Kamion> you should make it process dependencies properly
[05:32] <janimo> ogra: is there a parallel thing doing more or less the same thing?
[05:32] <ogra> Kamion, it does
[05:32] <Kamion> ogra: then why does it need to be changed?
[05:33] <ogra> i just dont want to touch the code two days beforew freeze if i9 have a working edubuntu iso since week and that change should really have been months ago
[05:33] <seb128> Keybuk: what do you mean? no, your library is your local list of files, the permanent one
[05:33] <seb128> Keybuk: removable medias are considered as differents libraries
[05:34] <Keybuk> seb128: how can I share the removable media?
[05:34] <ogra> and especially since my time is very limited these tests will take me the time to fix final stuff with g-p-m or g-s-s 
[05:34] <Keybuk> my laptop sees "Music", but not anything in it
[05:34] <ogra> which i'm also not fond of
[05:36] <ogra> i'm not saysing "it will break" but it has breakage potential in it which i really really dont like at this point 
[05:36] <ogra> so it needs decent testing which costs lots of time
[05:36] <seb128> Keybuk: hum, good question
[05:37] <Keybuk> this worked when it used to just consider players as detachable bits of your library :)
[05:38] <seb128> Keybuk: you can try unsetting /apps/rhythmbox/plugins/generic-player/active
[05:38] <Keybuk> what will that do?
[05:38] <seb128> stop using the generic-player plugin
[05:38] <dholbach> tfheen: NonLangagePackTranslationDeadline is the same date for artwork?
[05:38] <Keybuk> that killed the music player
[05:38] <seb128> ie: doesn't make your player listed as a different entry
[05:39] <Keybuk> can't it just share those?
[05:39] <Keybuk> it doesn't share podcasts either
[05:39] <seb128> it could
[05:39] <seb128> but it's not done and will no change before edgy
[05:40] <tfheen> dholbach: I haven't been able to get anybody to tell me when artwork freeze is.
[05:40] <tfheen> dholbach: but artworkfreeze in two days is fine with me.
[05:40] <dholbach> tfheen: right, mail sent - I guess he'll get back to you
[05:42] <janimo> ogra: but testing in the ldm case is either it starts or it doesn;t no? Like if by absurd one daily would break one would notice at once
[05:42] <janimo> ogra: your call of course, I don;t want to cause too much pains
[05:42] <janimo> it's just that there's a few unused megs of debs on the xubuntu CD because of it
[05:43] <ogra> janimo, testing the ldm case starts with spending 30-40 minutes watching ltsp-build-client building, then booting a thin client and checking if ldm works 
[05:43] <ogra> the install part is the time consuming piece here
[05:44] <ogra> as i said i'll try to invest some time into it .. but no promises
[05:45] <ogra> and please, please dont come up with such changes some days before RC  ... such things should be solved far before beta
[05:45] <sladen> pitti: is apport meant to use vast amounts of CPU?  It's mmap()ing, reading half megabytes pages, and remmap()ing
[05:46] <sladen> pitti: but doesn't acutally appear to be /doing/ anything visible (aside from the 90% CPU usage)
[05:48] <sladen> pitti: ah, that was a 60MB firefox core dump.
[05:48] <pitti> sladen: apport itself has to gzip the core dump, collect some /proc information and other bits 
[05:48] <pitti> sladen: so yes, it's quite resource intense
[05:48] <pitti> sladen: but I moved most of the expensive bits to aport-gtk, where they will be only done when the user actually wants to report a bug
[05:48] <pitti> bbl
[05:50] <dholbach> tfheen: were you able to do the pairing with the default passkey "BlueZ"?
[05:52] <kristog> dholbach, afaik BlueZ cannot be handled by phone you have to use numbers 
[05:52] <dholbach> hrm
[06:05] <sfllaw> Kamion: What is the most recent documentation about kickstart and Ubuntu?
[06:05] <sfllaw> Is it the hoary manual?
[06:06] <sfllaw> And is it supposed to be better these days?
[06:06] <Kamion> sfllaw: the installation-guide-${arch} package
[06:06] <Kamion> it's had some maintenance, although not lots. What in particular are you wondering about?
[06:06] <sfllaw> I need to know what kind of testing would be reasonable.
[06:07] <sfllaw> Is installation-guide-* available on the web?  Or does one have to install Ubuntu before reading it?
[06:19] <Lure> mjg59: I have usplash regression on ATI FireGL V5000 laptop after Beta: kubuntu logo looks edgy and there is green (or in one case) white cast on progress bar
[06:21] <Lure> mjg59: this has happened with first upgrade of usplash after beta, but I did not pay attention as I though usplash artwork is still changing, but my desktop (ATI radeon 9100) displays it perfectly after dapper->edgy upgrade
[06:22] <bddebian> Howdy
[06:59] <tkamppeter> doko_, did you have a look into HPLIP 1.6.9? Is it feasable?
[07:00] <doko_> tkamppeter: no, not yet
[07:03] <Kamion> sfllaw: it's on doc.ubuntu.com, but an old version; I've been engaged in a conversation with mdke about getting that updated
[07:04] <Kamion> though IME the best testing of Kickstart support so far has come each time a big corporate starts trying to roll out Ubuntu :)
[07:04] <sfllaw> Oy.
[07:04] <sfllaw> I'm probably unable to go through all the combinations, but a preliminary test would be good.
[07:05] <Kamion> use dapper's system-config-kickstart to generate some test files
[07:05] <Kamion> (edgy's is broken at the moment; working on that right now)
[07:05] <sfllaw> Thanks.
[07:05] <sfllaw> I'll fire up my Dapper VM.
[07:05] <Kamion> (bug 59820)
[07:05] <Ubugtu> Malone bug 59820 in system-config-kickstart "system-config-kickstart not starting" [High,Confirmed]  http://launchpad.net/bugs/59820
[07:05] <Kamion> oh, yeah, it'd need to be dapper's system-config-kickstart with other bits of dapper, so a VM's a good plan
[07:07] <sfllaw> ^^ will be fixed before release, right?
[07:08] <dholbach> tfheen: WOOOOO! gnome-bluetooth 0.8.0 fixes the pass URI to gnome-obex-send thing :-)
[07:08] <psykoyiko> does anyone want to poke at http://launchpad.net/bugs/65014 ?
[07:08] <Ubugtu> Malone bug 65014 in linux-source-2.6.17 "asm/atomic.h #includes non-existant header file, asm/processor.h" [Undecided,Unconfirmed]  
[07:09] <psykoyiko> Hi, Spads.
[07:10] <zul> hey Spads how is it going?
[07:10] <Spads> psykoyiko!
[07:13] <gnomefreak> tfheen: your irssi script "contentless_ping" is there a way to get it to /msg $user output instead of output in channel? (im looking at the irssi docs on varibles but i dont see one that will work)
[07:15] <hunger> Why is archive.ubuntu.com so slow recently? Is that on purpose to get people to use mirrors?
[07:18] <kristog> mdz, why bluez-libs 3.7.1 and bluez-utils 0.3.5?
[07:18] <kristog> we will have 2 different source so
[07:18] <Kamion> sfllaw: it's targeted at ubuntu-6.10 - so yes, I hope so
[07:39] <mdke_> tfheen: yay for countless_ping
[07:39] <mdke_> *contentless*
[07:40] <gnomefreak> i think i fixed it to /msg user
[07:40] <LaserJock> mdke_: ping? ;-)
[07:40] <gnomefreak> LaserJock: try mdke_ ping  without the chars
[07:41] <gnomefreak> LaserJock: also try me let me know if you get a /msg about it
[07:41] <gnomefreak> :)
[07:41] <LaserJock> gnomefreak: ping
[07:41] <gnomefreak> grrrrrr
[07:42] <gnomefreak> its putting  :: with your nick and i thought i fixed that brb
[07:43] <sladen> ho ho ho, every single python TLS library seems to be broken in some manner
[07:56] <gnomefreak> i fixed it :)
[08:03] <psykoyiko> can someone confirm that #include <asm/atomic.h> is broken on edgy?
[08:04] <psykoyiko> this seems to be a using-kernel-headers-but-we-shouldn't kind of bug
[08:21] <mdz> seb128: on some recent upgrades, my panel has gone weird (menus, clock, show desktop, window list, pager all missing) until I kill it.  is this known?
[08:23] <Seveas> mdz: ah so I'm not the only one who sees tha
[08:23] <Seveas> t
[08:28] <seb128> mdz: looks like some applet didn't like something which has been updated, some people mentioned it but none with useful data to have an idea on the issue
[08:29] <mdz> seb128: my system is in the broken state right now; is there any information i can collect?
[08:30] <mdz> my .xsession-errors is useless due to bug 39075
[08:30] <Ubugtu> Malone bug 39075 in vte "No handler for control sequence `device-control-string' defined" [Low,Unconfirmed]  http://launchpad.net/bugs/39075
[08:35] <sivang> re
[08:39] <vuntz> mdz: can you interact with the panel?
[08:39] <vuntz> right-click on it, move it, etc.
[08:39] <vuntz> or is it blocked?
[08:40] <seb128> mdz: reply to vuntz :)
[08:40] <vuntz> seb128: lazy you :-)
[08:40] <seb128> vuntz: apparently interactions are not working but sysmon applet, clock etc keeps being updated
[08:41] <seb128> vuntz: bt have not a lot of useful and strace is blocked on a FUTEX or something
[08:41] <seb128> not of useful, like no panel funtion
[08:41] <vuntz> it probably means an applet is blocked in the loading stage and the panel blocks on it
[08:41] <seb128> yeah, my bet was an applet
[08:41] <seb128> "loading"?
[08:41] <vuntz> easy way to debug this is to kill each applet process until this unblocks the panel :-)
[08:42] <seb128> panel was running fine, it's not on startup
[08:42] <vuntz> oh
[08:42] <seb128> that happens while running
[08:42] <vuntz> that's quite interesting
[08:42] <seb128> desktop is fine, dist-upgrade and it hangs
[08:42] <seb128> something change under it
[08:42] <seb128> I would have blamed a dbus restart or something
[08:42] <vuntz> is it using the cpu or just waiting?
[08:42] <seb128> but we don't restart dbus on update and it has not been updated
[08:42] <seb128> waiting
[08:43] <vuntz> could be because of file monitoring, but I can't imagine how this would happen
[08:43] <vuntz> seb128: do you have a bug number for this?
[08:43] <seb128> no
[08:44] <seb128> we can get mdz to open one with required infos though ;)
[08:44] <vuntz> interesting info to get: list of applets/panel objects (ie, applets + launchers + menus)
[08:44] <vuntz> what changed (if dist-upgrade, which packages were upgraded, etc.)
[08:45] <vuntz> stack trace
[08:45] <jdong> Kamion: when you get a chance, can you go through Backports's binary NEW queue?
[08:48] <dholbach> or bonobo-activation-server :)
[08:49] <mdz> vuntz: I can interact with the applets which are still running
[08:49] <mdz> vuntz: but not with the panel itself (no response to right-click)
[08:50] <mdz> vuntz,seb128: should I kill applets to see if it continues?
[08:51] <seb128> yeah, maybe getting a bt for every one before killing it?
[08:51] <seb128> each one
[08:52] <sladen> mdz: last time I had that, it was the keyboard switcher applet dying on load
[08:52] <desrt> seb128; i did my proof of concept.  it seems to work.
[08:53] <mdz> all of the applets I see running are still alive and I can interact with them
[08:53] <seb128> desrt: oh, nice!
[08:53] <desrt> seb128; i haven't actually seen that it produces better traces
[08:53] <desrt> seb128; only that it works :)
[08:53] <seb128> vuntz: any idea?
[08:55] <mdz> there were two sets of e-d-s / e-a-n running for some reason
[08:55] <mdz> I killed them all and it didn't help
[08:57] <xav> doko_, doko__ ping
[08:57] <desrt> seb128; got any 100% reproduceable crash in a gnome app for which bugbuddy always gets bad traces?
[08:58] <vuntz> mdz: can you put a stack trace of what's the panel doing somewhere?
[09:04] <desrt> seb128; k.  i have class so i should go
[09:04] <desrt> seb128; ping me later if you know of such a bug
[09:04] <seb128> desrt: oh, sorry, looking at several things at the same time
[09:04] <seb128> desrt: I've a non-easy example, deskbar-applet crashing with pygtk 2.10.2
[09:04] <seb128> which requires downgrading pygtk
[09:05] <seb128> I kept packages on my box for that :)
[09:05] <seb128> desrt: feel free to send me a patch and I'll try it, otherwise I'll try to think to a simpler example
[09:09] <imbrandon> mdz, ping , w.r.t bug 64488 , upstream commented saying they never left string freeze upstream ( e.g. no new strings )
[09:09] <Ubugtu> Malone bug 64488 in konversation "UVFe ( main ) for konversation 1.0 to 1.0.1" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64488
[09:10] <mdz> vuntz: I did, but it's not very good
[09:11] <mdz> vuntz: pasted in /query
[09:12] <vuntz> would be interesting to know if people seeing this are all using ubuntulooks
[09:12] <rodrigue> Salut  tous j'ai un gros soucis de mise  jour !
[09:12] <rodrigue> En gros tout fonctionnais bien jusqu'a la mise  jour d'aujourd'hui que j'ai hsiter  faire .....
[09:12] <rodrigue> Depuis qu'elle est faite, plus d'acclration graphique !!! Comment revenir en arrire ?
[09:12] <imbrandon> !fr
[09:12] <vuntz> rodrigue: je pense que ce serait mieux de demander dans #ubuntu-fr
[09:13] <vuntz> rodrigue: c'est un canal anglais
[09:13] <rodrigue> Oups. . . dj demander dans Ubuntu-fr 
[09:13] <_ion> No sithn minkin.
[09:14] <vuntz> rodrigue: et c'est un canal de dveloppement, pas de support
[09:14] <_ion> (I.e. thanks for only using English)
[09:14] <rodrigue> Pardon . . . 
[09:14] <rodrigue> I'm sorry
[09:14] <jdong> whoa, did #ubuntu-fr and #kubuntu-devel switch on me while I was gone?
[09:15] <jdong> I remember this stunt from grade school
[09:15] <rodrigue> :)
[09:15] <jdong> BenC: how's my faaavorite kernel developer doing today? :)
[09:15] <mdz> imbrandon: it's pretty clear from the changelog that it isn't a bugfix-only release; where did you get the idea that it was?
[09:17] <mdz> imbrandon: none of the bugfixes seem critical for edgy, and it sounds like there's a substantial amount of new code which is untested in ubuntu
[09:18] <xav> jdong, I'm not sure if it's the best place to ask, but do you know what's up with https://launchpad.net/distros/ubuntu/+source/openoffice.org/+bug/54776 ?
[09:18] <Ubugtu> Malone bug 54776 in openoffice.org "[Edgy]  font hinting does not work with libfreetype6 v. 2.2.1" [Undecided,Needs info]  
[09:32] <AlinuxOS> mjg59, ping.
[09:50] <jdong> xav: why do you ask me? I am the clueless fool when it comes to Openoffice/freetype :)
[09:51] <xav> jdong, but you contributed to this bug report, right?
[09:51] <jdong> xav: yeah, just  to say that the fonts looked BETTER after the recent uploads
[09:52] <jdong> it still looks different than native
[09:52] <xav> oh, so that's what I didn't understand
[09:52] <jdong> but much less blurry
[09:52] <xav> what changed
[09:52] <xav> and why does it look better
[09:52] <xav> I personally didn't see a difference, but I'm not sure
[09:52] <jdong> well, it's not nearly as blurry as it was before on my screen
[09:52] <jdong> I have an LCD, idn if that makes any difference
[09:53] <jdong> but the old fonts were very blurry (my eyes watered after using it for a few minutes)
[09:53] <jdong> the new ones are bearable again
[09:53] <xav> do you have a screenshot before and after?
[09:53] <xav> I still find them very blurry
[09:53] <Spads> "Playing with the use-mention dichotomy" isn't "everything in life, you know."
[09:53] <Spads> er, wrong channel
[09:54] <jdong> xav: when I feel less lazy I might do a screenshot comparison
[09:54] <xav> jdong, I don't see a difference between http://librarian.launchpad.net/4168326/openoffice-font.png and http://librarian.launchpad.net/4566596/Bildschirmfoto.png
[09:55] <jdong> xav: you don't see the difference?
[09:55] <jdong> xav: it's slightly less blurry 
[09:56] <jdong> Look at the two capital E's for a rough comparison
[09:58] <xav> you made me doubt, so I zoomed on both E
[09:58] <xav> they are totally identical
[09:58] <mantiena-baltix> pitti: still online ?
[09:58] <_ion> Eww, blurry fonts.
[09:58] <pitti> mantiena-baltix: yup
[10:00] <mantiena-baltix> pitti: why did you want to make me busy for the whole night ?
[10:01] <mdz> kristog: you proposed an agenda item for the technical board meeting, but you aren't in #ubuntu-meeting
[10:01] <ogra> Keybuk, could you have a loo9k at the last two comments on bug #65003 i thought that part of coreutils was fixed ...
[10:01] <kristog> 22.01 :) sorry
[10:01] <Ubugtu> Malone bug 65003 in ltsp "ltsp-build-client needs to handle proxy settings for apt in the chroot" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65003
[10:02] <Keybuk> ogra: ?
[10:02] <Keybuk> doesn't look like any problem I'm familar with
[10:02] <xav> so antialiasing is still very blurry, and without antialiasing, it's still very ugly
[10:02] <ogra> Keybuk, well, didnt you patch rm back in london ?
[10:03] <ogra> oh, no that was cp 
[10:03] <ogra> sorry
[10:03] <xav> there are 2 fedora patches for ooo in the bug report. they weren't applied ?
[10:03] <pitti> mantiena-baltix: pardon?
[10:03] <mantiena-baltix> pitti: some time ago (16:03:42) you toldi: mantiena-baltix: use glob() for shell patterns (globs)
[10:03] <xav> that's what I wanted to ask to doko_ 
[10:04] <mantiena-baltix> pitti: but after reading glob() function documentation (after ~20 minutes) I understood that this is not our way ;)
[10:05] <pitti> mantiena-baltix: well, if you prefer regexps, that's fine, too, but a bit unusual for specifying files
[10:06] <ogra> mjg59, which g-p-m issue did you mean yesterday ?
[10:06] <mantiena-baltix> pitti: no, I don't prefer regexps, it's not user-friendy way to write regexps into /etc/pmount.allow
[10:06] <pitti> mantiena-baltix: so, what's so evil about glob(3)? it's pretty straightforward
[10:06] <mjg59> ogra: The power button action one
[10:07] <pitti> call glob() on the pattern and check if the target device file is in the result set
[10:07] <mjg59> ogra: So yes, I've just seen the bug closed
[10:07] <ogra> mjg59, ah, great so i fixed the right one today ;)
[10:07] <mantiena-baltix> pitti: but glob () function is not our way (TM) it's too hard to use 
[10:07] <pitti> mantiena-baltix: fnmatch(3) is even easier
[10:07] <jdong> ogra: thanks for your time on that bug :)
[10:08] <mantiena-baltix> pitti: yea, fortunately in glob () manual I fount this line:
[10:08] <jdong> I've been eagerly waiting for it for a week now :)
[10:08] <mantiena-baltix>  If a utility needs to see if a pathname matches a given pattern, it can use fnmatch().
[10:08] <ogra> jdong, thanks for the patch
[10:09] <mantiena-baltix> pitti: so. maybe you wanna patch, which removes one line from TODO file and changes 2 lines in src/policy.c ?:)
[10:10] <pitti> mantiena-baltix: heh, sure :)
[10:10] <pitti> mantiena-baltix: I can't apply it to edgy, but I can apply it upstream, and in Debian soon
[10:10] <mantiena-baltix> -           if( !strcmp( d, device ) ) {
[10:10] <mantiena-baltix> +           if( !strcmp( d, device ) || !fnmatch(d, device, 0) ) {
[10:10] <mantiena-baltix> ;)
[10:10] <pitti> mantiena-baltix: the strcmp should be superfluous then
[10:11] <pitti> fnmatch(a, a, 0) should be true
[10:11] <mantiena-baltix> pitti: maybe, that's why I'm pasting patch here - I'm not very experienced in glob and fmatch
[10:13] <mantiena-baltix> pitti: So, you think we should simply use
[10:13] <mantiena-baltix> +           if( !fnmatch(d, device, 0) ) {
[10:13] <mantiena-baltix> ?
[10:13] <pitti> mantiena-baltix: I think so; I have to test it thoroughly, but it looks fine
[10:14] <mantiena-baltix> pitti: One of things, which I don't understand, is last fmatch argument - flag
[10:15] <mantiena-baltix> pitti: I don't know which flag to use, so I put zero there :)
[10:15] <pitti> mantiena-baltix: you should use FNM_PATHNAME 
[10:16] <pitti> mantiena-baltix: man fnmatch explains the options
[10:17] <mantiena-baltix> pitti: so, line should look like this:
[10:17] <mantiena-baltix> if( !fnmatch(d, device, FNM_PATHNAME) ) {
[10:17] <mantiena-baltix> ?
[10:17] <pitti> looks fine
[10:17] <pitti> mantiena-baltix: please test it a bit with various cases
[10:22] <mantiena-baltix> pitti: yes, I'm testing now and I changed also another line in policy.c to allow * character in /etc/pmount.allow
[10:22] <mantiena-baltix> -    const char* whitelist_regex = "^[[:space:] ] *([[:alnum:] /_+.\-] +)[[:space:] ] *(#.*)?$";
[10:22] <mantiena-baltix> +    const char* whitelist_regex = "^[[:space:] ] *([[:alnum:] /_+.\-*] +)[[:space:] ] *(#.*)?$";
[10:22] <pitti> mantiena-baltix: heh, right
[10:23] <pitti> mantiena-baltix: and, while you are at it, [ and ]  for full shell glob support
[10:23] <mantiena-baltix> pitti: but I'm not sure if I did this in correct way
[10:24] <mantiena-baltix> pitti: could you show me how to add [ and ]  ?
[10:24] <pitti> mantiena-baltix: just adding \[\]  to the []  set should do it
[10:25] <pitti> right after the *
[10:26] <mantiena-baltix> pitti: btw, why there is slash before minus in [[:alnum:] /_+.\-*]  ??? why not like this: [[:alnum:] /_+.-*]  ???
[10:28] <Keybuk> mantiena-baltix: because that matches all characters from "." to "*" :)
[10:29] <mantiena-baltix> Keybuk: ok, I understood, thanks
[10:30] <tfheen> gnomefreak: yes, it's trivial.  Just remove the $channel from the msg command
[10:30] <tfheen> dholbach: yay, great.
[10:31] <pitti> mantiena-baltix: the minus should be the last character in that set to keep it readable, and to avoid ambiguity with ranges
[10:31] <dholbach> tfheen: and nautilus-sendto is a gnome-bluetooth bug, fixed in 0.8.0 (which needs uvf + libbtctl uvf)
[10:31] <tfheen> dholbach: uh-huh.  Have you filed UVF exception requests and/or talked with mdz/Kamion about it?
[10:32] <dholbach> tfheen: not yet - I just finished packaging and testing it
[10:32] <dholbach> tfheen: what about bluez-gnome?
[10:32] <tfheen> dholbach: since while I'd love us to have decent bluetooth functionality, we're quite close to freeze and I'm too happy about doing those kinds of surgery at this point.
[10:32] <tfheen> dholbach: it's needed for the passkey agent, iirc?
[10:33] <dholbach> tfheen: it's the only thing that worked for me
[10:34] <dholbach> tfheen: i'll write a mail about libbtctl and gnome-bluetooth now
[10:34] <mantiena-baltix> pitti: like this ?:
[10:34] <mantiena-baltix> const char* whitelist_regex = "^[[:space:] ] *([[:alnum:] /_+*.\] \[\-] +)[[:space:] ] *(#.*)?$";
[10:34] <pitti> mantiena-baltix: you don't have to escape the minus if it's the last character; it *should* work, though (testing appreciated)
[10:35] <tfheen> dholbach: goodie.
[10:36] <mantiena-baltix> pitti: but you escaped minus in your code, even when minus was last
[10:36] <pitti> mantiena-baltix: hm, wait
[10:36] <pitti> mantiena-baltix: please read regex(7)
[10:36] <mantiena-baltix> pitti: ok
[10:36] <pitti> mantiena-baltix: \ is not an escape character in []  sets
[10:38] <pitti> mantiena-baltix: it needs to be sth. like [] [:alnum:] /_+*.[+\-] 
[10:38] <pitti> mantiena-baltix: 'To include a literal ]  in the list, make it the first character'
[10:38] <mantiena-baltix> pitti: your code in pmount 0.9.13 is:
[10:38] <mantiena-baltix>  whitelist_regex = "^[[:space:] ] *([[:alnum:] /_+.\-] +)[[:space:] ] *(#.*)?$";
[10:38] <pitti> mantiena-baltix: yes, \ is a valid character for file names
[10:39] <pitti> mantiena-baltix: ah, bzr diff told me now: before I used the - unescaped, but that didn't work in some locales
[10:39] <pitti> mantiena-baltix: with \- it worked
[10:42] <sladen> \sh_away: your last wine upload ( 0.9.22-0ubuntu1 ) takes the diff from 5k lines to 35k lines---alot of the churn in the diff looks a bit suspect
[10:43] <sladen> \sh_away: can you give it a once over when you're next around;
[10:43] <mantiena-baltix> pitti: if I write slash in /etc/pmount.allow then regexp doesn't match, it seems  whitelist_regex = "^[[:space:] ] *([[:alnum:] /_+.\-] +)[[:space:] ] *(#.*)?$"; doesn't allow \ 
[10:43] <pitti> mantiena-baltix: ok; it seems the regexp manpage isn't that precise then
[10:53] <dholbach> tfheen: done
[10:53] <dholbach> tfheen: and added ubuntu 6.10 milestone to that bug
[11:00] <mantiena-baltix> pitti: so, what I pattern I should use for regexp ? it's enough to use this ?:
[11:00] <mantiena-baltix> const char* whitelist_regex = "^[[:space:] ] *([[:alnum:] /_+*.\] \[\-] +)[[:space:] ] *(#.*)?$";
[11:01] <pitti> mantiena-baltix: if that works, it lokos good to me; but please put the \- to the end
[11:02] <lemsx1> mantiena-baltix: [[:alnum:] /_+*.\] \[\-] + <--- this is almost the same as [^[:blank:] ] + ... perhaps is a better class?
[11:03] <mantiena-baltix> lemsx1: talk with pitti - I'm not regexp guru ;)
[11:03] <pitti> it's not almost the same
[11:03] <pitti> also, I'd prefer a whitelist over a blacklist
[11:05] <mdke> mantiena-baltix: you had a question earlier?
[11:06] <mantiena-baltix> mdke: what question ?
[11:07] <mdke> mantiena-baltix: I don't know, it was your question. I got a highlight
[11:07] <mantiena-baltix> :)
[11:08] <mdke> mantiena-baltix: translations for documentation maybe?
[11:17] <tormod> pitti, hi, do you have a prism2 device yourself to test with?
[11:17] <pitti> tormod: hi
[11:18] <pitti> tormod: well, a half-broken Netgear stick, yes
[11:18] <AlinuxOS> pitti, ;)
[11:18] <pitti> tormod: I bought an Airport Extreme when it broke, and I almost threw it away
[11:18] <pitti> tormod: but it still sorta works for testing basic stuff
[11:19] <tormod> pitti, because the firmware upload is still broken. The /proc/net/p80211 is missing. Should that be /proc/net/ieee80211 now?
[11:19] <pitti> tormod: hm, no idea; I don't upload firmware to my stick
[11:19] <nawty> Hi guys, i've got a strange question, anyone around that'd be able to help me, i'm not sure how to log this specific bug. 
[11:20] <nawty> Basically, my boot hangs ( although, not really a hang, just kinda sits there, without hanging, but does nothing ) 
[11:20] <tormod> pitti, because you don't want to, or because it doesn't work :)
[11:20] <nawty> at 'waiting for root filesystem...' 
[11:20] <nawty> Using linux-kernel-2.6.17-10-generic, and -i386
[11:20] <nawty> was a clean install of dapper yesterday, edgy-ed today. 
[11:21] <nawty> the dapper kernel, -2.6.15-somthing works perfectly. 
[11:21] <tormod> nawty, try remove "quiet" and "splash" and ask again in #ubuntu
[11:21] <pitti> tormod: I don't need to, and the only time when I tried, the stick went broken, and I had to plug it into a winxp box to make it work again
[11:21] <nawty> tormod: i've removed quiet, and splash, and that's where i've seen it hangs. 
[11:21] <nawty> tormod: it's a bug, not a support request. 
[11:22] <nawty> tormod: I've tested booting with the options : 'irqpoll, and nommap ( i think it was no mmap )' 
[11:22] <nawty> tormod: which were both on forum posts about that specific problem 
[11:23] <nawty> the thing is, it's not a kernel / hardware bug, i'm sure of it, because it doesn't hard hang, it just seems to sit there, when it's supposed to go from kernel->rootFS 
[11:23] <nawty> thus, the 'waiting for root filesystem... ...'
[11:23] <tormod> nawty, file a bug with all the information you can give.
[11:23] <AlinuxOS> pitti, hello again, is there deadline for mozilla 2.0 translations pack ?
[11:23] <nawty> tormod: but under what package. 
[11:23] <nawty> tormod: it could be anything from the initrd, to the upstart stuff, to the kernel. 
[11:23] <pitti> AlinuxOS: well, it's becoming really tough now; given that it had to get through NEW and everything
[11:24] <nawty> tormod: and against the kernel -i386, or -generic
[11:24] <pitti> AlinuxOS: I'm afraid it's veery late
[11:24] <nawty> tormod: or against, source? 
[11:24] <AlinuxOS> pitti, and after realise ? :)
[11:24] <nawty> tormod: i've also regenerated the initrd a few times ( for the record ) 
[11:24] <pitti> AlinuxOS: we can't introduce new packages after release
[11:24] <AlinuxOS> mozilla is still beta.
[11:24] <pitti> AlinuxOS: we have 2.0rc2 now
[11:24] <AlinuxOS> yes
[11:25] <nawty> tormod: do you still figure i should ask in #ubuntu ? 
[11:25] <AlinuxOS> so when there is final...we need final transaltion packs or not ? 
[11:25] <mantiena-baltix> mdke: yea, I asked dholbach about ubuntu-docs package  - why in dapper all translations were included into ubuntu-docs package, but infinity told me, that in edgy ubuntu-docs  translations will be included into langpacks ;)
[11:27] <tormod> nawty, file under linux-source-2.6.17 please. no wait, that sounds familiar, this is a "udev" bug. look in launchpad, file a new if needed.
[11:27] <AlinuxOS> pitti, so it's impossible to have it like update after Edgy realise ...right?
[11:27] <nawty> tormod: i've also reinstalled udev, and upstart. 
[11:27] <pitti> AlinuxOS: right
[11:27] <nawty> tormod: should i check under udev @ launchpad ? 
[11:29] <tormod> nawty, yes udev @ launchpad
[11:29] <nawty> *seaches the great launchpad massives*
[11:29] <AlinuxOS> pitti, why so ?  I know that there is freeze period, but I think that having locale remotely linked with your locale is pretty good.
[11:30] <AlinuxOS> that means that georgian remains without transalted firefox 2.0 :(
[11:30] <mantiena-baltix> pitti: should'nt I use FNM_NOESCAPE flag in fnmatch ?
[11:31] <nawty> tormod: this the correct one ? : https://launchpad.net/distros/ubuntu/edgy/+source/udev/+bugs
[11:31] <tormod> nawty, yes, and then ask in #ubuntu+1 since you are using edgy.
[11:32] <nawty> tormod: no bugs, under dapper, or edgy. 
[11:32] <nawty> let me go ask in #+1 anyway. 
[11:32] <nawty> tormod: thanks for your help so far. 
[11:36] <doko_> xav: pong
[11:37] <xav> doko_, I had questions about openoffice, concerning freetype problem
[11:38] <xav> https://launchpad.net/distros/ubuntu/+source/openoffice.org/+bug/54776
[11:38] <Ubugtu> Malone bug 54776 in openoffice.org "[Edgy]  font hinting does not work with libfreetype6 v. 2.2.1" [Undecided,Needs info]  
[11:39] <xav> someone pasted the links to two fedora patch there
[11:39] <doko_> the patches are both applied
[11:40] <xav> oh I see, that's what I wanted to know, I wasn't sure
[11:40] <xav> unfortunately, it doesn't seem to fix the issue then
[11:40] <doko_> :-/
[11:42] <xav> that's odd, I thought it would do it
[11:43] <xav> and openoffice isn't the ideal app to play with, with its building time
[11:43] <Seveas> xav, you don't have a 4gazillion mhz machine with infinite IO bandwidth and neglegible IO latency?
[11:44] <xav> no, but I hope openoffice devs have
[11:58] <xav> doko_, ohhh
[11:59] <xav> doko_, it works :))
[11:59] <AlinuxOS> Seveas, 4gazillion :D
[12:00] <doko_> xav: what did you change?
[12:01] <xav> doko_, I remember fontconfig was a bit weird sometimes about its settings
[12:02] <xav> so I wrote a .fonts.conf with antialiasing/hinting settings
[12:02] <xav> like kde does
[12:02] <xav> gnome only exports Xft resources, it doesn't write any config files
[12:02] <sivang> doko_: if you have time, there are those two bugs for moin that I'd like to take care of if you think it's right - https://launchpad.net/distros/ubuntu/+source/moin/+bugs and deserves UVFs , as well as a pending merge as it seems. The merge is about adopting to new python policy, is it worthwhile UVF and upload as well?
[12:03] <doko_> xav: you may want to attach that settings as documentation to the report
[12:03] <xav> it looks much better now, the hinting / hintstyle options are now used
[12:03] <xav> doko_, yep
[12:03] <xav> but it seems it still can't use subpixel rendering
[12:03] <xav> nor native hinting
[12:06] <sladen> seb128: what's the deal with bug #59159 ?  Do you have a rough idea of the extent of the problem?
[12:06] <Ubugtu> Malone bug 59159 in gst "network-admin doesn't scan for networks [regression] " [Unknown,Unconfirmed]  http://launchpad.net/bugs/59159
[12:07] <seb128> sladen: the feature has not been implemented/ported to the new code
[12:08] <seb128> gnome-system-tools src/network/connection.c
[12:08] <seb128> wireless_essid_populate_model() to rewrite
[12:09] <seb128> and probably needs to write the liboobs method for it