[12:20] <Kim^J> Does the original kernel in Edgy eft knot3 have SMP support? Or do I have to install another one?
[12:21] <Trae> BenC you here?
[12:24] <Trae> BenC, the laptop overheat issue, https://launchpad.net/distros/ubuntu/+bug/22336 , It affects Debian's latest testing, as well as Fedora Core 6 pre (their latest release before the final this week)
[12:24] <Ubugtu> Malone bug 22336 in acpi-support "laptop overheats when performing CPU intensive tasks." [High,Confirmed]  
[12:24] <wasabi_> whiprush: Have you been to a ubuntu dev summit/conference/thing, previously?
[12:25] <Trae> The only two distro's I've seen NOT be affected by it are: Mandriva 2007 and Gentoo 2006.1
[12:25] <Ubugtu> Mandriva bug 2007 in Installation "Switching to alternate screens during install crashes X" [Normal,Resolved: fixed]  http://qa.mandriva.com/show_bug.cgi?id=2007
[12:26] <Trae> I really don't want to have to run Mandriva
[12:26] <Trae> :(
[12:26] <Trae> and Gentoo is too much compiling for my tastes
[12:31] <jdong> Trae: hehe, gentoo has overheat issues unique to itself.... :)
[12:31] <jdong> Trae: does a vanilla kernel exhibit the same issues?
[12:32] <imbrandon> tfheen, can i get an OK to upload http://federation.imbrandon.com/amarok.debdiff tis a very trivial fix
[12:32] <jdong> imbrandon: have you gotten to look at my ktorrent debdiff too?
[12:32] <imbrandon> jdong, i just seen your message, i'll check it on my ppc tonight
[12:32] <jdong> imbrandon: thankie
[12:34] <Trae> jdong I ran for quite a while with gentoo ( in terms of testing ) about 72hrs.
[12:34] <jdong> Trae: you should be able to isolate the patch from gentoo-sources that did the trick
[12:34] <Trae> it was just too much work to keep compling stuff over and over, but gentoo passed all the tests that Ubuntu and others fail at
[12:35] <Trae> jdong I am a Graphic Artist who happens to run Linux
[12:35] <Trae> I don't know about development stuff
[12:35] <Trae> I used Linux for 10+ years, but only as an end-user
[12:35] <jdong> Trae: do you know how to compile kernels and use patch to apply patches?
[12:35] <Trae> I mean, sure I can type ./configure && make && make install
[12:35] <Trae> but that doesn't make me a developer
[12:35] <Trae> heh
[12:35] <Trae> jdong not realy
[12:36] <Trae> I don't know how to do patches
[12:36] <Trae> I've done them, like, back in 96', 97', 98' 
[12:36] <Trae> when I had to, but I've all but forgotten any of that stuff
[12:36] <Trae> And I hated it back then
[12:36] <Trae> heh
[12:36] <jdong> well, gentoo's patches are at http://dev.gentoo.org/~dsd/genpatches/trunk/
[12:37] <jdong> if gentoo doesn't have the problem, one of those patches fixes it
[12:37] <Trae> :(
[12:37] <jdong> a quick glance/grep shows nothing ACPI related though
[12:37] <jdong> which makes me question if that's the culprit...
[12:37] <Trae> I can't see how this bug wouldn't be the #1 issue for all the distro's it affects
[12:37] <jdong> Trae: because not all hardware exhibits this?
[12:38] <Trae> having your distro bomb on a laptop... just seems very bad
[12:38] <imbrandon> Trae, becouse very little hardware is afected by it
[12:38] <jdong> none of the laptops I've ever used Linux on exhibit this
[12:38] <Trae> imbrandon that one bug seems like a lot of laptops are affected
[12:38] <imbrandon> Trae, not all laptops obviously as the whole laptop testing team and most developers run a lappy including myself
[12:38] <wasabi_> My laptop works fine. =)
[12:39] <jdong> Trae: put that into perspective with the number of laptops that run Ubuntu or Fedora Core combined
[12:39] <jdong> it's certainly a very significant bug for those it affects, but it's not as widespread as you make it out to be...
[12:39] <pirast> Trea, I didn't read the bug report, but can't that be caused by the the kernel not detecting the temperature correctly?
[12:39] <Trae> acer, hp, fujitsu, toshiba
[12:40] <imbrandon> anyhow all i'm getting at is this is better suited for #ubuntu-kernel as they can tell you exacly what to diag ( and they are normaly only arround durring the week )
[12:40] <Trae> not major brands I know... (hp is)
[12:40] <Trae> imbrandon the sad thing is, breezy never had a problem with this.
[12:40] <pirast> (Trae)
[12:40] <Trae> :(
[12:40] <Trae> nor warty
[12:41] <Trae> it's something that was introduced in Dapper Drake
[12:41] <jdong> Trae: I have both acer and toshiba laptops, and they are fine
[12:41] <jdong> so it's not as widespread as that
[12:41] <Trae> jdong Do you run custom kernels?
[12:41] <jdong> only a certain subset is affected
[12:41] <imbrandon> Trae, as i said ALOT has changed since breezy , anbd mostly only the kernel team can help[
[12:41] <jdong> no, I use stock Ubuntu kernels
[12:41] <jdong> unless I have a _really good_ reason to deviate
[12:41] <Trae> jdong nod...
[12:41] <Trae> it just sucks that my laptop is basically now a freakin' useless brick
[12:42] <Trae> unless I want to run Mandriva or Gentoo
[12:42] <jdong> Trae: do you know if your lm_sensors reports temporatures correctly?
[12:42] <jdong> Trae: if you lm_sensors can control your fans, just use fancontrol/pwmconfig to do userspace thermal
[12:42] <imbrandon> ugh i give up, #ubuntu-kernel
[12:42] <Trae> I'd rather have bamboo slivers drivin under my fingernails than use Gentoo
[12:42] <Trae> heh
[12:42] <jdong> imbrandon: that's a ghost town too... for today there's really not much of a difference :D
[12:43] <Trae> jdong hmmm don't really know about lm_sensors
[12:43] <imbrandon> jdong, yes there is , and i said that he needs to go in there durring the week, not say the same thing in here day after day
[12:43] <jdong> Trae: give setting up lm_sensors a chance...
[12:43] <Trae> my grub is busted ATM (after failed FC6pre attempted install)
[12:44] <Trae> jdong hmm ok.
[12:44] <jdong> good luck
[12:44] <Trae> let me see if I can install grub again
[12:44] <Trae> I've got an extra partition I've been using to do tests of other distro's
[12:44] <Chipzz> jdong: the fact that someone doesn't get an answer elsewhere does not justify having them come complain here
[12:44] <Chipzz> jdong: neither for #ubuntu, nor for #ubuntu-kernel
[12:45] <jdong> Chipzz, imbrandon: sorry, I was already in the middle of getting him a workaround, didn't feel like migrating. I'm done now
[12:46] <Chipzz> jdong: I was just pointing out the "policy"; also, if you're the one helping it's not your fault either ;)
 if gentoo doesn't have the problem, one of those patches fixes it  or one of the ubuntu patches breaks it...  ;-)
[12:47] <Trae> heh
[12:47] <Trae> In my experience, it's best to help when you can (provided a channel isn't swamped with discussion), and then kindly remind the particular use of a channel.
[12:48] <Trae> like, if there was an active discussion going on.. and the user is OT, then that's a time to directly intervene.
[12:48] <Trae> that's just my thoughts
[12:48] <Trae> jdong tx for tring to help
[12:49] <Chipzz> Trae: OTOH, most users do not care about anything but getting a solution for their problem
[12:49] <Trae> I didn't even know there was an #ubuntu-kernel
[12:49] <Chipzz> that's why they violate rules in the first place
[12:49] <Trae> Chipzz I've been dealing with this bug since Dapper was released...
[12:49] <jdong> JanC: I was about to say that, but diagnosing that is way beyond Trae's self-reported technical scope :-)
[12:49] <Trae> heh
[12:50] <Trae> jdong self-reported heh
[12:50] <Chipzz> helping them out against policy makes that feeling even stronger, and may encourage them to do the same thing the next time too
[12:50] <Chipzz> "Yes I know this is off-topic, but I need a solution for my problem, and I got helped here last time too..."
[12:50] <Chipzz> and I have seen this exact thing happen
[12:51] <Chipzz> users knowingly and willingly violating the rules for their own benefit
[12:51] <mjg59> This conversation is not usefully topical.
[12:51] <th_> hi lupine_85 
[12:51] <th_> :)
[12:51] <Chipzz> mjg59: heh :)
[12:51] <Chipzz> mjg59: exactly :)
[12:52] <imbrandon> mjg59, can only tfheen approve uploads atm ? i have a trivial upload 
[12:52] <mjg59> I certainly can't
[12:52] <imbrandon> k
[12:52] <th_> is there any interest in making ubuntu detect bios raids like medley (silicon image/cmd) and nvidia?
[12:52] <imbrandon> he's most likely gone for the day, i'll try to cacth him tomarrow
[12:52] <th_> like so it can install from scratch with a windows on such a raid
[12:53] <ompaul> th_, you should qualify that with what you have previously done
[12:53] <th_> http://www.infowares.com/linux/
[12:53] <th_> got my 2.4 kernel silicon image raid driver into the official kernel tree
[12:55] <th_> anyway
[12:56] <th_> i'm just trying to find out if this is something that is needed or not.. because I think a lot of people have windows installed on these bios raids
[12:56] <th_> if I didn't have to dual boot myself, I'd of course go with Linux raid instead of biosraid, but many people already have these systems so we should support them
[12:57] <ompaul> th_, I think you should hang out here until you see some kernel chat taking place
[12:57] <th_> ompaul, thanks, I will
[12:57] <th_> well, try that is ;) 
[12:57] <ompaul> it may take until Monday
[12:57] <th_> but I will have a look at what needs to be done to support this
[12:58] <th_> knowing that it works in Gentoo it can't be impossible ;) I think some dmraid initramfs script might be what it takes..
[12:59] <AlinuxOS> mjg59, ping (do you see me?, or maybe I'm not logged in freenode :( )
[12:59] <ompaul> th_, message me an I will give you a quick tour around ubuntuland and its support stucture
[12:59] <th_> AlinuxOS, you are in freenode alriight.. and to send a private messae you tyke "/msg username message"
[01:00] <AlinuxOS> th_, I've alredy done this... but no respose... I guess there is something wrong with my cnnection..or loging stuff
[01:01] <th_> AlinuxOS, what do you mean you have done it? you mean, implemented support for these bios raids?
[01:02] <AlinuxOS> I mean I've alredy messaged mjg59 in private...but no response...
[01:03] <th_> oic
[02:44] <ajmitch> afternoon
[02:44] <srbaker> dude
[02:46] <_ion> Night.
[02:46] <imbrandon> heya ajmitch
[02:46] <ajmitch> hi imbrandon 
[03:11] <keescook> tfheen: when you're back, I've got 1 main (libx11-6) upload ready to go in http://people.ubuntu.com/~kees/to-upload/ (and 2 universe, but I don't see dholbach around atm)
[04:46] <poningru> iwj: ping
[04:53] <poningru> anyone know where I can find the entire changelog for a particular package?
[04:54] <poningru> in this case firefox
[04:55] <jdub> /usr/share/doc/firefox/changelog.Debian.gz
[04:56] <poningru> thanks
[04:57] <poningru> mdz: ping
[04:58] <imbrandon> moins jdub
[05:44] <infinity> tfheen: Around?
[05:54] <StevenK> infinity: Careful, tfheen doesn't like contentless pings.
[05:57] <infinity> StevenK: He makes exceptions for the cute ones.
[06:06] <imbrandon> infinity, uploaded ( incase you have to poke it through the queue or such ) , thanks 
[06:10] <infinity> I do have to poke, yes.
[06:21] <jdub> mjg59: ping
[06:21] <dholbach> hi
[06:22] <mjg59> jdub: Hi
[06:22] <dholbach> drop it like its hot
[06:22] <jdub> mjg59: oh, was going to email you
[06:22] <jdub> mjg59: i'll dot hat anyway
[06:23] <mjg59> Dude, you have entirely unrealistic expectations of my response times
[06:24] <mjg59> If getting back to you within 90 seconds of the initial query at 5:20AM isn't enough to stop you from going off to email me instead, what is?
[06:25] <jdub> mjg59: email seemed to be the most sensible choice when i realised what time it was
[06:27] <mjg59> jdub: Oh, yeah, saw that a while ago
[06:30] <dholbach> i found a critical bug in edgy
[06:30] <dholbach> a very critical one, take care.
[06:30] <dholbach> it's already reported
[06:31] <mjg59> dholbach: Mm?
[06:35] <keescook> dholbach: I've got two universe uploads for you to look at, when you've got a moment: http://people.ubuntu.com/~kees/to-upload/
[06:35] <keescook> for the openssl ->098 migration, ettercap & aolserver4
[06:36] <dholbach> w/e
[06:36] <dholbach> night
[06:36] <keescook> ssh
[06:36] <dholbach> I will tommorow
[06:36] <keescook> yup, hence the "when you've got..."  :)
[06:37] <imbrandon> hrm
[09:03] <fabbione> who is part of the U. Media team?
[09:03] <fabbione> or multimedia?
[09:04] <BHSPitLappy> do you mean the artwork/audio teams, or something else?
[09:06] <minghua> fabbione: I believe crimsun is in multimedia team
[09:07] <minghua> fabbione: they actually have a LP page: https://launchpad.net/people/motumedia
[09:08] <fabbione> BHSPitLappy: no. i meam multimedia
[09:08] <fabbione> siretart, crimsun: ping
[09:08] <fabbione> minghua: thanks
[09:09] <fabbione> sharms: ?
[09:17] <siretart> fabbione: good morning!
[09:17] <fabbione> simira: morning...
[09:18] <fabbione> bug #63493
[09:18] <Ubugtu> Malone bug 63493 in mythplugins "mythweb.postinst: 31: Syntax error: Bad substitution (fix is to use Bash instead)" [High,Confirmed]  http://launchpad.net/bugs/63493
[09:18] <fabbione> siretart: i meant
[09:18] <siretart> :)
[09:18] <fabbione> siretart: it's one liner.. can we please get that done yesterday?
[09:19] <fabbione> infinity: i just uploaded iproute to fix FTBFS (wrong B-D) it's quite obvious fix..
[09:19] <siretart> oh. slomo is AFAIK still on holiday.
[09:19] <fabbione> infinity: 66207
[09:19] <fabbione> siretart: well holidays or not, Release is getting closer ;)
[09:19] <fabbione> tfheen: ^^
[09:20] <siretart> fabbione: I have heard something like that. ;) - yes, I'm looking at it
[09:23] <neuralis> fabbione: long time no see
[09:23] <neuralis> fabbione: how are you?
[09:24] <fabbione> hey neuralis 
[09:24] <fabbione> i am okish and you?
[09:24] <fabbione> i saw you might show up at MV
[09:24] <neuralis> yeah, i'll be there
[09:24] <neuralis> okish sounds about right :)
[09:25] <neuralis> i wanted to ask -- did we ever put together a decent installation guide for sparc?
[09:25] <fabbione> yeah just a bit tired but otherwise fine
[09:25] <neuralis> yeah, same here
[09:25] <fabbione> neuralis: is there any point in making one when the installer is exactly the same?
[09:26] <fabbione> you get no extra or different questions except for a warning before writing the partition layout to disk
[09:26] <fabbione> and that's about it
[09:26] <neuralis> hmm
[09:26] <neuralis> i need to try edgy; with dapper, it looked like the sas controller wasn't being detected
[09:27] <fabbione> neuralis: what kind of hw?
[09:27] <neuralis> t2000 (t1)
[09:27] <fabbione> i know that T2000 rev2 requires edgy kernel
[09:28] <fabbione> yeah but is it rev1 or rev2 of the hw?
[09:28] <neuralis> that'll do it, then
[09:28] <neuralis> rev2, i believe
[09:28] <fabbione> does it have the sas controller on board or on a pci slot?
[09:29] <neuralis> looked to be on-board, but it's 3:28am, so i might be misremembering.
[09:29] <fabbione> if it is on the mobo it's rev2
[09:29] <fabbione> and it needs edgy
[09:29] <fabbione> natural evolution :)
[09:29] <Kamion> there's already installation-guide-sparc
[09:29] <neuralis> right. okay, cool; i'll throw edgy on there tomorrow or monday.
[09:29] <Kamion> patches welcome if it's inadequate
[09:30] <Kamion> it's built from the same source as the other installation guides
[09:30] <fabbione> Kamion: it's just neuralis that's weird ;)
[09:30] <neuralis> haha
[09:31] <neuralis> no, it's just neuralis that's used to having to do all sorts of magic to get sparc machines happy with linux in the earlier years
[09:32] <neuralis> anyway, i'll check things out and submit doc patches if need be.
[09:35] <fabbione> neuralis: i don't have rev2 hw here, but i am told by a few SUN guys that works ok
[09:37] <Kamion> Riddell: I think speedcrunch, attal, kmformat need to be modified to take the removal of libqt4-debug-dev into account
[09:37] <neuralis> fabbione: yeah, i'm happy to debug if not. i only had about 10-15 minutes to play with it before leaving the office, which is why i was asking if it's known.
[09:38] <fabbione> fair enough
[09:39] <fabbione> neuralis: how much time do you have before slamming it into production?
[09:39] <fabbione> neuralis: i would like to get access to it to see if i can get dapper to work on it
[09:40] <fabbione> and given the TZ diff, i can do the work while you sleep
[09:40] <neuralis> fabbione: i don't have alom hooked up yet, but certainly, i'm happy to set that up
[09:40] <fabbione> neuralis: i will need ALOM and access to a machine from where we can do tftpboot
[09:41] <neuralis> of course
[09:41] <fabbione> that would rock
[09:42] <neuralis> sure. are you in a rush? it'll be a lot easier for me if it can wait about 3-5 days, but if you need it earlier, i can probably try and arrange it.
[09:42] <fabbione> nah 3/5/7 days are fine
[09:42] <neuralis> perfect.
[09:42] <fabbione> but you are the first one i know from where i can get access :)
[09:43] <neuralis> not a problem
[09:44] <neuralis> is the sas patch easily backportable to the dapper kernel, or do you have a better approach in mind?
[09:44] <fabbione> neuralis: i need to check that basically. i am not sure if it is only a matter of PCI-ID or it needs more
[09:45] <fabbione> the changes to the sas driver between dapper and edgy are almost all related to the hw RAID support
[09:45] <fabbione> that doesn't work in dapper
[09:45] <neuralis> right
[09:45] <fabbione> there are also a bunch of bugs opened for that one
[09:45] <fabbione> so i want to see how reasonable is a backport of the driver
[09:46] <neuralis> yeah, makes sense.
[09:46] <neuralis> okay, i'll mail you close to the end of the week and we can get it going.
[09:47] <fabbione> neuralis: thanks.. that's fine
[09:47] <neuralis> 4am; sleep time. cheers, it'll be good to see you in mv
[09:58] <siretart> fabbione: fix for bug #63493 uploaded
[09:58] <Ubugtu> Malone bug 63493 in mythplugins "mythweb.postinst: 31: Syntax error: Bad substitution (fix is to use Bash instead)" [High,Fix committed]  http://launchpad.net/bugs/63493
[09:58] <fabbione> siretart: good boy
[10:07] <fabbione> ajmitch: only 1600 pkgs left to build.. once that's done i will rekick only main.. 
[10:07] <fabbione> ajmitch: do you still want to get the mails for that or not?
[10:08] <ajmitch> I don't mind getting them
[10:10] <fabbione> ok
[10:10] <ajmitch> only 650MB of build logs so far :)
[10:12] <fabbione> yeah it's not that much
[10:23] <duncan> who can i talk to about upping my priveleges on launchpad?
[10:24] <duncan> It's mostly just because I'm finding bugs which clearly need closing but I can't seem to get anyone to notice.
[10:25] <ajmitch> you can close bugs
[10:25] <ajmitch> you just won't be able to set importance unless you're in the ubuntu-qa team
[10:28] <duncan> I can't find a way to do that anywhere. I'm thinking for example of bug 54095
[10:28] <Ubugtu> Malone bug 54095 in acpi-support "monitor dim/brighten reversed (HP Pavilion dv8220ea)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/54095
[10:29] <StevenK> Click on the link listed under "Affects"
[10:32] <duncan> StevenK-> I have two 'Also Affects...'. I can't see how they can help
[10:32] <StevenK> Just above that.
[10:33] <StevenK> For example, "acpi-support (Ubuntu)" is the link I'm refering to.
[10:34] <duncan> aha, now I've found it. Thanks - I guess I'll slowly become more useful...
[10:37] <minghua> There REALLY should be a LP usability bug open for that thing
[10:43] <Burgundavia> minghua: most of LP's interface is fundmentally broken
[11:32] <infinity> fabbione: approved and accepted.
[11:38] <tfheen> imbrandon: amarok > approved
[11:39] <tfheen> fabbione: mythplugins is multiverse, I don't do *verse.
[11:59] <Kamion> tfheen: edubuntu-meta and xubuntu-meta uploads from me in unapproved to *actually* remove the *-live metapackages - ok?
[11:59] <tfheen> Kamion: approved
[12:02] <Kamion> tfheen: sync requests in bug 65972 and bug 65973 need your approval
[12:02] <Ubugtu> Malone bug 65972 in planner "Please sync planner (main) from unstable (main)" [Undecided,Confirmed]  http://launchpad.net/bugs/65972
[12:02] <Ubugtu> Malone bug 65973 in rus-ispell "Please sync rus-ispell (main) from unstable (main)" [Undecided,Confirmed]  http://launchpad.net/bugs/65973
[12:02] <Kamion> (or otherwise)
[12:07] <tfheen> Kamion: I think those can be left for edgy+1
[12:08] <tfheen> (there are no other bugs on rus-ispell in Ubuntu; the planner update is really just a sync and I'd rather have us go with what we have and have tested than something else when it doesn't fix any targetted bugs)
[12:08] <Kamion> tfheen: ok, could you comment on those bugs?
[12:09] <Kamion> (I more or less expected that answer)
[12:11] <tfheen> Kamion: will do.
[12:15] <azazel> i guys where should i file in generic bugs for edgy? i'm trying it out on my powerbook titanium and both sound and resume aren't working anymore (in dapper they workerd fine)
[12:16] <tfheen> azazel: all bugs should be reported in launchpad.
[12:16] <Kamion> if you don't know the correct source package, then leave that field empty
[12:17] <azazel> yes... but where ? here? https://launchpad.net/distros/ubuntu/edgy/+bugs
[12:17] <tfheen> https://launchpad.net/distros/ubuntu/+filebug
[12:24] <azazel> tfheen: done, thanks
[12:29] <Kamion> tfheen: ditto bug 65963
[12:29] <Ubugtu> Malone bug 65963 in flex "sync request" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65963
[12:33] <tfheen> Kamion: iirc, doko was supposed to upload a fix for just the warning; I can't say I want to sync toolchain stuff at this point (when all it fixes is a build-issue for a universe package)
[12:43] <gnomefreak> doko__: you around i need to ask you something about eclipse depends for somereason the depends on eclipse is set like this: libjsch-java (>= 0.1.19) libjsch-java (<< 0.1.20) but edgy uses 0.1.28-1
[12:58] <xav> gnomefreak, which package?
[12:59] <gnomefreak> libjsch-java is the depends issue for eclipse
[12:59] <xav> I've both eclipse and libjsch 0.1.28 installed
[12:59] <xav> for eclipse-platform, I see: libjsch-java (>= 0.1.16)
[01:00] <gnomefreak> xav: im building eclipse and its complaining
[01:00] <xav> oh, so that's build-deps ?
[01:01] <gnomefreak> bug 66190
[01:01] <Ubugtu> Malone bug 66190 in eclipse "[Edgy]  Eclipse wont build unmet depends" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66190
[01:01] <gnomefreak> xav: yes
[01:01] <gnomefreak> ^^ the bug on it
[01:02] <pygi> gnomefreak: so debdiff and attach? :)
[01:04] <xav> well maybe remove the << 0.1.20 first, build eclipse and check it works fine
[01:06] <gnomefreak> i dont have edgy pbuilder :(
[01:06] <gnomefreak> can i change the file save it and run apt-get source -b?
[01:07] <gnomefreak> or would i need to use pbuilder like any other package?
[01:07] <xav> afaik, you never need pbuilder
[01:07] <Kamion> tfheen: ok, please say that in the bug?
[01:07] <xav> but you can always use it
[01:13] <tfheen> Kamion: done
[01:14] <Kamion> thanks
[01:16] <gnomefreak> it seems to be all of the depends are off
[01:53] <sivang> morning / afternoon all
[01:56] <Hobbsee> hey sivang 
[01:59] <sivang> hi Hobbsee , what's cracking, how are we doing with the UNMETDEPS stuff?
[02:00] <Hobbsee> sivang: not sure, i've uploaded a few
[02:00] <sivang> Hobbsee: I see, I've seen lots of stuff by MIchael, he has been busy ;-)
[02:01] <Hobbsee> hehe, yeah.  i've been uploading them :)
[02:01] <Hobbsee> geser: is here
[03:32] <gnomefreak> doko__: eclipse isnt playing nice with me im re building it but found out other lib versions need to be changed. let me know if you want to build it all i will give you the changes if you want.
[03:51] <gnomefreak> doko__: here is the full story bug #66190
[03:51] <Ubugtu> Malone bug 66190 in eclipse "[Edgy]  Eclipse wont build unmet depends" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66190
[04:09] <giftnudel> hi sivang, have you gotten around to look at my approach?
[04:30] <sivang> giskard: I have glanced at it, I'm keen to do something testing with it
[04:30] <sivang> oops
[04:30] <sivang> giftnudel: ^^
[04:30] <sivang> giftnudel: can I jus take the file put it in and test, or is this just a sketch?
[04:31] <sivang> giftnudel: also, does it work on DVDs as well?
[04:31] <giftnudel> sivang: no it doesn't work on dvds, since it uses cdrecord
[04:31] <giskard> sivang: :P
[04:31] <giskard> :)
[04:31] <sivang> giftnudel: okay, that's okay
[04:31] <giftnudel> sivang: you can merge the relevant changes to your DeviceInfo.py, it's one big block
[04:32] <sivang> giskard: sorry , but if you want to help on hubackup you're welcome :-)
[04:32] <giskard> what is it?
[04:32] <giftnudel> sivang: I works with my multisession cd, so I'm really interested if it works in general
[04:32] <sivang> giftnudel: yes, I shall do that, also, it not a big problem to probably make this work using dvd+rw tools and make it seemlessly support DVDd
[04:33] <sivang> giftnudel: I shall do some testing now. I just need to finish some talks with libburn upstream , pygi :)
[04:33] <giftnudel> sivang: dvd+rw-mediainfo works with dvds
[04:33] <giftnudel> it might do it
[04:33] <giftnudel> sivang: ok
[04:33] <sivang> giftnudel: you interested to try add support to device info using it, you can check if it's dvd/cd from the hal info already there.
[04:34] <sivang> giftnudel: ?
[04:34] <sivang> giskard: apt-cache show hubackup
[04:34] <sivang> giskard: (make sure you have universe enabled)
[04:34] <giftnudel> sivang: I will try to make that work with dvds, (if mediainfo does provide useful output
[04:34] <giftnudel> )
[04:35] <sivang> giftnudel: you'r my hero :)
[04:36] <giftnudel> sivang: oh, wait and see if it works ... ;)
[04:36] <giskard> sivang: :P 
[04:36] <sivang> giftnudel: well, you deserve praise just for your help attempts and sharp approach to that.
[04:37] <zul> *sigh* i need a uvf exception
[04:40] <infinity> zul: For?
[04:40] <zul> xen 3.0.3-rc5
[04:40] <zul> fixes the udev rules as well
[04:40] <infinity> Beg dholbach and/or ajmitch.
[04:40] <zul> yep ill wait for ajmitch
[04:41] <infinity> Also, are you going to upload a new xen-source with Tollef's fixes, so I can finally get XRM building for you?
[04:41] <infinity> If you upload xen-source, I'll approve that right away as an FTBFS fix.
[04:41] <zul> yep will do that today im about to do some more changes
[04:41] <infinity> Kay, get it in in the next 8 hours and ping me, and I'll approve it when I wake up in the morning.
[04:41] <zul> ok cool
[04:45] <giftnudel> sivang: btw, I have set up a temporary bzr branch on http://www.student.informatik.tu-darmstadt.de:8080/~mbergner/hubackup/hubackup--main/
[04:46] <sivang> giftnudel: make sure you update reglarly from my location, but very cool :)
[04:46] <giftnudel> sivang: well, I'm a bzr newbie, so expect some problems ;)
[04:47] <sivang> giftnudel: I'm happy to show you the way
[04:47] <giftnudel> sivang: if you find the first problem, please tell me, but I think up to now, everything should be fine ;)
[04:48] <sivang> giftnudel: I shall just branch from you, you already got the device info improvements inside right/?
[04:48] <giftnudel> I should
[04:48] <tfheen> zul: you don't happen to have an idea about what my 2.6.17 problem with xen on amd64/smp can be, do you?
[04:49] <zul> no i dont did it work with 2.6.16?
[04:49] <giftnudel> sivang: to update to your branch, I can use update and merge?
[04:50] <sivang> giftnudel: after you've merged from me nce
[04:50] <sivang> giftnudel: once,
[04:50] <sivang> giftnudel: actually no, you just merge everytime I tell you I made new changes
[04:50] <giftnudel> ok
[04:50] <sivang> giftnudel: (or you check it with bzr missing and locatoin)
[04:50] <sivang> *location
[04:50] <sivang> so:
[04:51] <sivang>  1) bzr branch sivang--main
[04:51] <sivang>  2) hack my stuff there
[04:51] <sivang>  3) commit, push to my web space
[04:51] <bhale> hi sivang 
[04:51] <sivang>  4) bzr missing sivang's-location
[04:51] <sivang>  5) bzr merge sivang's location if changes were made
[04:52] <sivang> let's make sure we don't touch same files at a given time, to avoid conflicts
[04:52] <sivang> hi bhale 
[04:52] <sivang> bhale: no more tseng? :)
[04:54] <Lathiat> tfheen: any further comments on the avahi init script stuff?
[04:54] <giftnudel> sivang: I'll see if that helps me, if not, I will ask you again, thanks!
[04:55] <bhale> sivang: nope.
[04:55] <sivang> giftnudel: np, feel free to ping, or email if you need
[04:55] <giftnudel> I will
[04:55] <tfheen> Lathiat: I think it's a tad late to come running with this bit now.  While it's unfortunate, only advanced users should be confused, right?
[04:55] <tfheen> advanced in this case is "people who run random stuff from /etc/init.d"
[05:03] <Lathiat> tfheen: no, same thign happens tryign to use the services gadget in system->administration
[05:03] <Lathiat> tfheen: also people who try install avahi-daemon from synaptic or even apt-get.. judgying by the bug reports they aren't 'advanced users' there just users trying to make it work
[05:05] <tfheen> Lathiat: why wasn't this picked up a week or a month ago?  It's not a new issue, is it?
[05:05] <Lathiat> no its just come more to my attention that i consider it might be a running problem
[05:06] <Lathiat> from the couple extra bugs of late etc
[05:06] <Lathiat> and af ew people on irc
[05:06] <Lathiat> as i said in my followup email i think theres a realtively "low-risk" way of doin git.. but yeh i understand we're in pretty hard freeze etc :\
[05:10] <tfheen> Lathiat: hmm.  Your proposed solution at this point is exactly what?
[05:11] <tfheen> bhale: we have a relase candidate due on Thursday, so your analysis is quite likely to be correct.
[05:26] <siretart> fabbione: re bug #66212
[05:26] <Ubugtu> Malone bug 66212 in wpasupplicant "FTBFS in edgy" [High,Confirmed]  http://launchpad.net/bugs/66212
[05:27] <siretart> fabbione: what makes you think the problem is in wpasupplicant rather then libqt4-dev?
[05:27] <siretart> fabbione: the mysql dependency is absolutely unneeded, because wpasupplicant nor wpa_gui doesn't do anything with mysql
[05:28] <siretart> fabbione: the fact that qt4 requires this, doesn't seem to be the problem of the wpasupplicant package to me
[05:40] <sivang> giftnudel: you have the free space fix applied in your repo?
[05:40] <sivang> giftnudel: I just want to branch and debuild :)
[05:40] <sivang> (and test)
[05:41] <giftnudel> sivang:  it should be in there, yes
[05:41] <sivang> giftnudel: cool, thanks
[05:41] <giftnudel> sivang: I should have the dvd part done by tomorrow, I might create a new file CDMisc.py if you don't mind
[05:42] <giftnudel> sivang: where all the cd, dvd detection stuff will be in (there are some problems with hal and some correct values which dvd+rw-mediainfo does correctly)
[05:45] <sivang> giftnudel: feel free to be as creative as needed. so this module would be imported by DeviceInfo.py and then it's 'low level' bits be used there?
[05:45] <giftnudel> yes
[05:45] <sivang> giftnudel: you also fixed the fle name with spaces qoute problem yes?
[05:45] <sivang> (according to the diff)
[05:45] <giftnudel> oh, yes
[05:45] <giftnudel> I think so
[05:45] <sivang> giftnudel: did you apply the patch from malone?
[05:45] <giftnudel> yes
[05:45] <sivang> (I happily saw someone posted that there)
[05:45] <giftnudel> that was me ;)
[05:46] <sivang> oh
[05:46] <giftnudel> I was a little bored ;)
[05:46] <sivang> stupid me to not notice
[05:46] <sivang> giftnudel: very cool, I really appriciate it
[05:47] <giftnudel> oh well, the translation irc_nick <=> real name is not that easy sometimes ;)
[05:47] <sivang> giftnudel: yes, indeed. I need to upload a new version of your fix anyway, should do it today or tomorrow. (the quote fix)
[05:48] <giftnudel> yes, the real problem was the cmd_line.split, the rest is just safety I guess
[05:48] <giftnudel> sivang: oh, wait
[05:48] <sivang> giftnudel: why are you replacing the spaces with slashes btw?
[05:48] <giftnudel> sivang: I think the " " in the cmd_line are wrong
[05:49] <giftnudel> sivang: with "\ ", you don't need to quote the line then
[05:49] <sivang> ah right
[05:50] <sivang> escape for space, good catch! :)
[05:50] <Kamion>   109622 | S- | cernlib              | 2005.dfsg-5ubuntu1   | 3 hours 20 minutes
[05:50] <Kamion>          | * cernlib/2005.dfsg-5ubuntu1 Component: universe Section: science
[05:50] <Kamion>   109530 | S- | qt4-x11              | 4.2.0-1ubuntu2       | 25 hours
[05:50] <Kamion>          | * qt4-x11/4.2.0-1ubuntu2 Component: main Section: libs
[05:50] <giftnudel> sivang: but "/path/to\ empty/"  is wrong
[05:50] <Kamion>   109473 | S- | kubuntu-default-sett | 1:6.10-58            | 38 hours
[05:50] <Kamion>          | * kubuntu-default-settings/1:6.10-58 Component: main Section: kde
[05:50] <Kamion>   109420 | S- | xorg-server          | 1:1.1.1-0ubuntu12    | 44 hours
[05:50] <Kamion>          | * xorg-server/1:1.1.1-0ubuntu12 Component: main Section: x11
[05:50] <Kamion> tfheen: ^--
[05:50] <sivang> giftnudel: ?
[05:51] <giftnudel> sivang: COPY_CMD_LINE = '-Q -y -v -m 256 -s %s -D -R %s -c %s -Z "*.gz" -Z "*.bz2" -Z "*.zip" ' <- this is correct, note the missing " " at -s %s (should not be -s "%s")
[05:52] <giftnudel> sivang: I don't know if I did this correctly or not
[05:52] <sivang> giftnudel: so you wanted to drop off the double quotes?
[05:52] <Kamion> that all sounds like a security nightmare if whatever expands %s doesn't escape unsafe characters
[05:53] <giftnudel> Kamion: right
[05:53] <Kamion> (by which I mean, escape anything it doesn't know to be safe)
[05:53] <giftnudel> Kamion: it gets the path from a filechooser, that should be safe actually
[05:54] <giftnudel> no it isn't...
[05:54] <Lathiat> tfheen: To move /etc/init.d/avahi-daemon to /etc/dbus-1/event.d/25avhai-daemon as is
[05:54] <Lathiat> tfheen: and modify init.d/avahi-daemon not to do the default checking
[05:54] <Lathiat> tfheen: https://lists.ubuntu.com/archives/ubuntu-devel/2006-October/021733.html
[05:54] <Kamion> giftnudel: er, no
[05:55] <giftnudel> sivang: hmm, let me think about this fix and if I can do it better ... maybe -s "%s" is better, then remove the sourcePath.replace() stuff, that should be much better
[05:55] <Kamion> giftnudel: well, *perhaps* safe in that you can only compromise your own account unless this is set-id, but it might well do the wrong thing. What happens if you create a file containing spaces and try to use it?
[05:55] <Kamion> "%s" is almost always wrong
[05:55] <Kamion> if you have to use "...", it implies that the code expanding %s isn't quoting properly
[05:56] <Kamion> in which case, what happens if the filename contains a literal "?
[05:56] <giftnudel> Kamion: well the space stuff is handled correctly now, but  I wonder at stuff like " & ; does it
[05:56] <tfheen> Kamion: kubuntu-default-settings and xorg-server were approved yesterday, iirc?
[05:56] <tfheen> Kamion: what's the changelog for the qt4-x11 upload?
[05:56] <pitti> sivang: you try to call a program with that set of command line arguments from python or from shell? (in python you should never use shell=True if you can avoid it)
[05:56] <Kamion> tfheen: k-d-s/x-s> dunno, I haven't been keeping track
[05:56] <Kamion> giftnudel: there's no excuse for only handling *some* metacharacters, IMHO
[05:56] <giftnudel> Kamion: yes, that's true
[05:56] <Kamion> if you're fixing it for some of them, do it properly :-)
[05:57] <Kamion> tfheen: I'll review the universe one
[05:57] <sivang> can't double quoting helpe a bit here? (although not enough)
[05:57] <Kamion> sivang: that's not a solution.
[05:58] <Kamion> it just papers over some instances of the problem
[05:58] <giftnudel> you can do something like if ' in path quote with "", else with ' ' 
[05:58] <Kamion> tfheen: it's from Riddell:
[05:58] <Kamion> +  * Install usr/bin/qdbus usr/bin/qdbusxml2cpp and usr/bin/qdbuscpp2xml
[05:58] <Kamion> +    closes Malone No 66098
[05:58] <Kamion> giftnudel: oh god no
[05:58] <giftnudel> hehe, I know ...
[05:58] <Kamion> does nobody understand escaping?
[05:58] <sivang> right, so need to make sure everything received from user is well quoted
[05:58] <giftnudel> no, better escaped
[05:58] <sivang> pitti: this is from python, lemme check again
[05:58] <sivang> sorry,
[05:58] <sivang> I wanted to say escaped
[05:59] <giftnudel> like /path/to/\;\ \&\ strang_pathname
[05:59] <sivang>         self.proc = spawn('dar',self.BACKUP_CMD_LINE.split())
[05:59] <sivang> pitti: ^^^
[05:59] <sivang> so probably is using the shell...
[06:00] <Kamion> use the subprocess module if you can
[06:00] <tfheen> Kamion: ok, qt4-x11 approved.
[06:01] <pitti> sivang: you should use subprocess.call() with a proper argv array
[06:01] <sivang> pitti: I need to be able to monitor the process through a ptry
[06:01] <sivang> pty
[06:02] <pitti> sivang: well, if you can do it with spawn, you can do it with subprocess.Popen()/communicate()
[06:02] <giftnudel> pitti: like call(proc, ("-s", path) and path can be anything like /path/to file
[06:03] <giftnudel> pitti: (so will it work with strange paths)
[06:03] <giftnudel> empty spaces, &, " and so one in it
[06:03] <sivang> pitti: I'm actually using python-expect
[06:04] <sivang> In [3] : print pexpect.spawn.__doc__
[06:04] <sivang> This is the main class interface for Pexpect.
[06:04] <sivang>     Use this class to start and control child applications.
[06:04] <Lathiat> tfheen: (a possibly better 'implementation' detail would be to check $0 and see if it matches 25avahi-daemon or something)
[06:04] <pitti> sivang: you can get stdin/out/err FDs from subprocess easily; please read the documentation about subprocess
[06:04] <sivang> so this is the spawn  I use
[06:04] <Lathiat> tfheen: do you want me to prepare a patch so you can review or would you rather leave it?
[06:04] <pitti> sivang: in general, please avoid using the shell in python, unless you have a very good reason to use it
[06:04] <Kamion> sivang: I suggest reading the Secure-Programs-HOWTO if you haven't already done so
[06:05] <Kamion> even if your program is not on a security boundary, following its recommendations is likely to improve your program's reliability
[06:05] <pitti> sivang: a backup program which can possibly work automatically is most likely a security threat if it allows shell injection
[06:05] <sivang> pitti: what is wrong by using pexpect? it saved me time and effort having to reimplement my own pty subprocess control system. I wonder if it can use some sort of escape mechanism
[06:06] <pitti> Kamion: not sure, but things like browser caches are prone to arbitrary file name injection (maybe not firefox, but in general)
[06:06] <tfheen> Lathiat: prepare the patch, and I'll review it.
[06:06] <tfheen> Lathiat: that's not a promise it'll be accepted, mind.
[06:06] <sivang> pitti, Kamion : I see
[06:07] <sivang> pitti: also, the program is not htat much of an 'automatic' , but more need to be actively operated to do something.
[06:07] <pitti> sivang: hm, if pexpect wants to do the spawning itself, and doesn't just accept a stdin/out pair, it seems quite badly designed
[06:07] <Lathiat> tfheen: *nod* ok thanks
[06:08] <pitti> sivang: (I don't know p-expect, not sure whether it's really like that)
[06:08] <tfheen> Lathiat: oh, and if you want it in, please make that patch now rather than later.  I'm going to totally close the door for such updates tomorrow morning (UTC)
[06:08] <Kamion> there really should be a standard Python codec that escapes shell metacharacters, so you can do .encode("shell_escape") - there's the string_escape encoding but it's not clear that it's guaranteed to be safe for use outside python
[06:09] <sivang> I can check how pexecpt does it's spawning
[06:09] <sivang> IIRC it uses subprocess
[06:09] <pitti> Kamion: I guess it's not pythonic to encourage the programmer to use Unix specific shells instead of subprocess (and I can perfectly understand that, too)
[06:10] <sivang> pitti: subprocess.call() is not prune to that vulns ?
[06:10] <pitti> sivang: it would be nice if it would accept a Popen object or a pair of file handles instead of a shell command string
[06:11] <pitti> sivang: if you use the default (shell=False) and use an argv array instead of a string, then there is no shell involved
[06:11] <Kamion> sivang: pexpect knows how to accept a list of arguments rather than a shell command
[06:11] <Kamion> __init__(self, command, args=[] , timeout=30, maxread=2000, searchwindowsize=None, logfile=None, env=None)
[06:11] <pitti> sivang: it's similar to using execv() instead of system() in C
[06:11] <Kamion> pitti: right, but metacharacter expansion is at least as generically useful as, say, the palmos encoding
[06:12] <pitti> heh, true
[06:12] <sivang> I see now that there's an fdepxect module, in beta that commetns say will move intp pexpect when proven to be stable enough
[06:12] <sivang> intersting
[06:12] <sivang>     """This is like pexpect.spawn but allows you to supply your own,
[06:12] <sivang>     already open file descriptor. For example, you could use it to
[06:12] <sivang>     read through a file looking for patterns, or to control a modem or
[06:12] <sivang>     serial device.
[06:13] <Kamion> in this case it does not sound like it adds significant value over using the existing support in pexpect for supplying a list of arguments
[06:13] <Kamion> just use %s and make sure that your code to expand that always fills in the filename as a single argument
[06:15] <Kamion> for instance: COPY_CMD_LINE = ['-Q', '-y', '-v', '-m', '256', '-s', '%s', '-D', '-R', '%s', '-c', '%s', '-Z', '*.gz', '-Z', '*.bz2', '-Z', '*.zip'] 
[06:15] <Kamion> assuming that assignment is in a Python program
[06:15] <hash_> Hi, just wondering if Edgy is frozen even for small bug fixes?
[06:15] <sivang> yes
[06:15] <mjg59> Especially for small bugfixes
[06:16] <Kamion> hash_: small release-critical bug fixes are allowed but need to come very soon indeed
[06:16] <hash_>  It's a trivial fix, here's the patch: http://cvs.savannah.nongnu.org/viewcvs/*checkout*/sinhala/patches/firefox_1.99%2B2.0rc2%2Bdfsg-0ubuntu2-sinhala1.patch?root=sinhala
[06:16] <Kamion> non-release-critical fixes will have to wait
[06:16] <sivang> Kamion: so s/\"/\'/ ?
[06:16] <Kamion> sivang: well done, you picked out the least relevant part of my suggestion ...
[06:16] <Kamion> (it doesn't matter in this case)
[06:17] <sivang> sorry, but I picked the previous parts as well ;)
[06:17] <sivang> it will just help fpr the expansing, it won't help injection ofcourse
[06:17] <Kamion> I just use '' out of habit unless I need ""
[06:17] <Kamion> sivang: huh?
[06:17] <sivang> (since someone coul provide ' at the filename)
[06:17] <Kamion> sivang: that is not true
[06:17] <pitti> saves a shift key press :)
[06:18] <pitti> sivang: unlike perl and shell, python does not treat ' and " differenlty
[06:18] <Kamion> sivang: you've missed the point of using a list
[06:18] <sivang> that what I recalled, but Colin's comments made me doubt that :)
[06:18] <hash_> We need to enable Pango for the si locale, otherwise Sinhala does not get rendered in Firefox, that's critical for us, but would that be considered critical by ubuntu?
[06:18] <sivang> Kamion: the original code before giftnudel's suggestion was using a list:
[06:19] <Kamion> sivang: the '...' are only parsed when Python is constructing the list COPY_CMD_LINE itself
[06:19] <Kamion> sivang: you then take a copy of that list, and iterate over it filling in the %s bits
[06:19] <sivang>         self.proc = spawn('dar',self.BACKUP_CMD_LINE.split())
[06:19] <Kamion> sivang: at that point Python couldn't care less whether the strings you copy into the new list contain ' characters or not
[06:20] <Kamion> hash_: unfortunately our firefox maintainer doesn't tend to be around at weekends
[06:20] <Kamion> tfheen: what do you think about that firefox pango change?
[06:21] <Kamion> sivang: self.BACKUP_CMD_LINE there isn't a list, it's a string. the error-prone part is that split()
[06:22] <hash_> Kamion: should I open a bug in launchpad?
[06:22] <Kamion> sivang: you should be working with a list throughout rather than having a stage where it's a string that you have to split up
[06:22] <Kamion> hash_: yes
[06:22] <hash_> Kamion: should I add anyone in particular to the CC list? e.g. release manager?
[06:23] <Kamion> hash_: I've already asked tfheen for his opinion
[06:23] <sivang> Kamion: error prone in that it fails on space contaiing file names, yes, so your suggestion is to iterate over COPY_CMD_LINE as a list, and then construct a string out of it, then feeding it to spawn? or just feed COPY_CMD_LINE as a list to spawn since it receives list arg as well?
[06:23] <Kamion> sivang: no no, don't construct a string at any point!
[06:23] <hash_> Kamion: Thanks!
[06:23] <Kamion> sivang: any point where a string with multiple arguments is involved for a shell command is a possible security vulnerability or reliability problem
[06:24] <Kamion> sivang: just feed it straight through as a list
[06:25] <sivang> ah okay, that should resolve the issue of space containing file nmaes as well as the secuirty vuln ?
[06:25] <pitti> sivang: yes (I hope you understand, why)
[06:26] <sivang> pitti: let's see if I understood why:
[06:27] <pitti> sivang: let f be 'foo bar', then compare ['cp', f, 'target/']  (direct execve) with 'cp %s target/' % f that's executed in a shell
[06:28] <pitti> sivang: let f be '; rm -rf ~; true' for a more drastic example 
[06:30] <sivang> yes, so eseentially, being inside a list, not injection can really be made,
[06:30] <sivang> since everything will be treated literaly, or just break invocation through the args supplied to the spawn comman
[06:30] <sivang> command
[06:30] <pitti> sivang: the real point is not that you cannot inject random stuff into a list, but that you avoid passing random stuff to a *shell*
[06:31] <pitti> sivang: right
[06:31] <pitti> sivang: the golden rule is: *never* call a shell with anything that is provided by the user
[06:33] <sivang> that is like the never access the db with anything that is provided by the user for web devel :-)
[06:33] <sivang> (or before you've used a built in escaping func, after thoroughly checking it)
[06:34] <_ion> pitti: Hi. You've probably noticed these already, but just in case: please see bug #65914 and bug #65917.
[06:34] <Ubugtu> Malone bug 65914 in apport "apport-retrace -d fails with KeyError" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65914
[06:34] <Ubugtu> Malone bug 65917 in apport "Doesn't handle diversions" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65917
[06:35] <sivang> pitti, Kamion : thanks for the tips I should also read the howto as well.
[06:35] <giftnudel> sivang: want me to take care of the problem or do you want do to it?
[06:35] <giftnudel> pitti, Kamion: yes thanks alot ;)
[06:35] <sivang> giftnudel: be my guest :)
[06:36] <pitti> sivang: exactly
[06:36] <pitti> _ion: I did, but I'm afraid it's a little too late for fixing them for edgy
[06:37] <giftnudel> sivang: ok, then I will do that I will rewrite the thing so that we only use a list and not a string
[06:37] <_ion> pitti: Ok, thanks.
[06:38] <giftnudel> sivang: I will open a bug about that and will assign it to me, so that it's clear that we are working on it
[06:39] <sivang> giftnudel: thanks alot dude
[06:39] <giftnudel> no problem!
[06:42] <bluefoxicy> oh wow
[06:42] <bluefoxicy> full real-time patches in 2.6.18!
[06:42] <tfheen> Kamion: what firefox pango change?
[06:42] <bluefoxicy> edgy is a 2.6.17 but these are gonna be on in Edgy+1 right?
[06:43] <tfheen> bluefoxicy: we're probably going to have 2.6.19 for edgy+1
[06:43] <bluefoxicy> tfheen:  yes but you can disable the real-time ptaches
[06:44] <Kamion> tfheen: http://cvs.savannah.nongnu.org/viewcvs/*checkout*/sinhala/patches/firefox_1.99%2B2.0rc2%2Bdfsg-0ubuntu2-sinhala1.patch?root=sinhala per hash_ above
[06:45] <Kamion> tfheen: kubuntu-default-settings accepted; there was a concern about xorg-server using a patch in debian/patches to patch a file in debian/local, which is a bit crackful
[06:45] <bluefoxicy> tfheen:  you know I have multiple times wanted the newer kernels for one reason or another, pretty much every release; it's bounced between "Driver X crashes my system and is essential" to "Kernel has new feature that I want" (or:  preempt is disabled due to bug in our version).  These have never, ever hit backports.  o_o
[06:45] <tfheen> Kamion: agreed; Seb was the uploader, wasn't he?
[06:45] <Kamion> tfheen: yes
[06:45] <tfheen> Kamion: si is which language again?
[06:45] <Kamion> <cjwatson@cairhien ~>$ grep -w si /usr/share/iso-codes/iso_639.tab
[06:45] <Kamion> sin     sin     si      Sinhala; Sinhalese
[06:46] <giftnudel> sivang: I recycled bug 59412 for that ;)
[06:46] <Ubugtu> Malone bug 59412 in hubackup "Malformed directories can cause hubackup to crash" [High,In progress]  http://launchpad.net/bugs/59412
[06:46] <sivang> giftnudel: very good, recycling is good for the environemtn!
[06:46] <giftnudel> :)
[06:47] <tfheen> Kamion: the change looks innocent enough; I have no idea whether it's needed for Sinhalese, though, given that even with the name I'm not sure where it's spoken.
[06:47] <mdke_> sri lanka
[06:47] <giftnudel> sivang: ok, I need to go now, I think this will be finished at the end of this week
[06:47] <Kamion> sounds plausible for an Indic language
[06:48] <tfheen> Kamion: ok, let's do it.  Can you upload a fixed package?
[06:49] <hash_> tfheen: Pango is needed by Sinhala
[06:49] <Kamion> should be able to, let's see
[06:50] <hash_> Kamion: does this mean I don't have to open a bug?
[06:50] <Kamion> but you'd better not finger me for TILM of firefox
[06:50] <Kamion> hash_: please do anyway and tell me the bug number
[06:50] <tfheen> Kamion: we have iwj for that. :-)
[06:51] <Kamion> I wonder if I can realistically test it ...
[06:52] <tfheen> Kamion: hash_ should be able to point to a page which doesn't render correctly with it?
[06:52] <Kamion> hash_: yes, if you could give me a URL that would be good
[06:53] <hash_> Kamion: more info here: http://bugzilla.gnome.org/show_bug.cgi?id=361538
[06:53] <Ubugtu> Gnome bug 361538 in I18N "Add si (Sinhala) to the list of locales requiring Pango" [Major,New]  
[06:54] <Kamion> is there a Sinhala-capable font in Ubutu?
[06:54] <Kamion> Ubuntu
[06:54] <hash_> ttf-freefont has glyphs but some lookups are missing.
[06:57] <hash_> Kamion: launchpad bug number: 66270
[06:57] <tfheen> bug 66270
[06:57] <Ubugtu> Malone bug 66270 in firefox "Add si (Sinhala) to the list of locales requiring Pango" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66270
[06:57] <mjg59> tfheen: I've got a two-line diff that fixes the "only the first suspend works" bug
[06:57] <tfheen> mjg59: bug #?
[06:59] <mjg59> #56365
[06:59] <mjg59> bug 56365
[06:59] <Ubugtu> Malone bug 56365 in xserver-xorg-video-i810 "X crashes on second resume from suspend-to-ram on Thinkpad X41" [Critical,Confirmed]  http://launchpad.net/bugs/56365
[07:00] <tfheen> oh, shiny.
[07:00] <mjg59> Where "Thinkpad X41" is "Any machine with i915/i945"
[07:00] <tfheen> have you gotten ilm to verify it?
[07:00] <mjg59> I can reproduce here
[07:00] <tfheen> ok, coolie.
[07:00] <tfheen> can we have a second verification that it's fixed?
[07:01] <mjg59> Fix makes sense, but is in acpi-support rather than xserver-xorg-video-i810
[07:01] <mjg59> Uh. I can test the fix on a second machine? :)
[07:01] <Kamion> tfheen: I'm just looking at that ktorrent FTBFS before firefox
[07:01] <tfheen> mjg59: what's the fix?
[07:01] <tfheen> Kamion: the ppc one which didn't make sense to either Adam or me?
[07:01] <mjg59> tfheen: Explicitly set the screen back to text mode on resume before switching back to X
[07:02] <Kamion> tfheen: oh, was it *that* one?
[07:02] <mjg59> Since the vbestate saved is from a graphical mode now (due to usplash)
[07:02] <tfheen> Kamion: I think so, yes.
[07:02] <Kamion> hadn't realised it was the same bug
[07:02] <Kamion> is Adam still on top of it?
[07:02] <tfheen> I think he's horisontal in bed, so I assume not.
[07:03] <Kamion> I'll have a go, then
[07:03] <tfheen> infinity: ^^ around and is the ktorrent build failure the crackful build failure we talked about on Friday?
[07:03] <tfheen> it's ppc specific, isn't it?
[07:03] <Kamion> the suggested patch indicates the same thing
[07:03] <Kamion> yes
[07:04] <tfheen> mjg59: if you can test it on a second machine and then upload, please do.  It sounds sensible.
[07:05] <Kamion> tfheen: oh, the patch is hateful and patches configure
[07:05] <Kamion> no wonder
[07:06] <Kamion> probably need to hunt-and-destroy the .m4 that contains it
[07:06] <mjg59> tfheen: Tested on another machine
[07:06] <tfheen> mjg59: go for it
[07:09] <mjg59> tfheen: Do you need anything in the changelog?
[07:10] <tfheen> mjg59: nothing apart from documenting the change; Kamion or Adam will ask me about it in a bit.
[07:10] <mjg59> Ok
[07:11] <tfheen> (and I'll tell them that the change is approved)
[07:11] <mjg59> Cool
[07:11] <mjg59> Uploading
[07:11] <tfheen> cheers.
[07:11] <tfheen> did you have any luck with usplash on amd64 or are you going with the vga16 route there?
[07:11] <mjg59> About to hit that now
[07:11] <mjg59> (Yesterday was a bit of a loss. Never drinking again)
[07:12] <tfheen> heh
[07:12] <tfheen> at least not until Wednesday?
[07:12] <mjg59> Especially not with freshers
[07:12] <mjg59> Eh. Maybe tomorrow.
[07:12] <keescook> what's the issue with usplash on amd64?  I'd like to help if possible...
[07:12] <mjg59> keescook: x86emu and nvidia bioses don't get along
[07:12] <tfheen> keescook: blows up with nvidia cards.
[07:12] <keescook> sounds like my config.  :)
[07:12] <tfheen> mjg59: do you have the debdiff for the acpi-support somewhere?
[07:13] <keescook> usplash needs a vga= line, yes?
[07:13] <mjg59> tfheen: This stuff /works/ in X, so the current plan of attack is to get a better idea of what X is doing
[07:13] <mjg59> keescook: No
[07:13] <hash_> Kamion: Is there anything else I need to do or any info that you need?
[07:13] <tfheen> mjg59: given that it works once in a while, I'm wondering if there are some data structures not cleared properly or something.
[07:14] <mjg59> tfheen: http://www.codon.org.uk/~mjg59/acpi-support.debdiff
[07:14] <keescook> mjg59: okay.  would 'usplash -c' be one way to test fixes?
[07:14] <mjg59> vgamode rather than vbemode is deliberate
[07:14] <tfheen> mjg59: 404
[07:14] <mjg59> keescook: Yeah
[07:14] <mjg59> tfheen: http://www.codon.org.uk/~mjg59/tmp/acpi-support.debdiff
[07:14] <tfheen> thanks
[07:15] <keescook> mjg59: okay, cool.  usplash for me just changes the brightness, and doesn't display any graphics.  is there anything I can do to help debug?
[07:15] <mjg59> keescook: Other than figuring out the bug, I doubt it
[07:15] <tfheen> keescook: does vbetool vbestate save SIGSEGV for you?
[07:15] <keescook> tfheen: checking
[07:16] <keescook> tfheen: yup, sure does.
[07:16] <mjg59> Yeah, that's the simple csae of the problem
[07:16] <tfheen> that bit is trivially solved.
[07:17] <mjg59> tfheen: That doesn't mean it works though, right?
[07:17] <tfheen> mjg59: no, it means it runs into the infinite loop problem.
[07:17] <keescook> there is a bug # for the usplash junk so I can get up to speed on it?
[07:17] <tfheen> keescook: ok, if you grab the source for vbetool, change a few defines at the top of x86-common.c, it should loop forever.
[07:17] <tfheen> #define REAL_MEM_BASE ((void *)0x1000)
[07:18] <tfheen> #define REAL_MEM_SIZE 0x80000
[07:18] <tfheen> are the defines you want.
[07:18] <tfheen> #define REAL_MEM_BLOCKS (REAL_MEM_SIZE/1024)
[07:18] <tfheen> that'll make it not segfault
[07:18] <keescook> usplash pours stuff to the screen (e.g. Calling INT 0x0 (0004:003E), EAX is 5100, Leaving interrupt call. over and over)
[07:19] <tfheen> usplash sometimes work, so vbetool is really a better test.
[07:19] <keescook> okay
[07:19] <tfheen> since it consistently fails (for me at least)
[07:19] <tfheen> you can make the same change to usplash and it should loop forever unless you neighbour's cat is red and the moon is waning and your grandfather is brushing his teeth when you run it.
[07:20] <keescook> dunno if it helps, but I've never had usplash work yet on this machine.  :)
[07:21] <tfheen> not even in dapper?
[07:21] <tfheen> or haven't you had dapper on it?
[07:21] <keescook> wrt REAL_MEM_SIZE, that should change from 0x40000 to 0x80000?
[07:21] <tfheen> yeah.
[07:21] <keescook> I had it disabled in dapper.  :P
[07:21] <Kamion> hash_: no, thanks
[07:22] <tfheen> the size isn't that important, but ISTR I ran into some bugs when I didn't bump it.
[07:23] <hash_> Kamion: thanks for the info and help, cya later
[07:29] <keescook> tfheen: after those changes, mine still segfaults...
[07:29] <keescook> er, nm, missed MEM_BASE change.  agh
[07:30] <keescook> yes, now it loops forever.  :)
[07:32] <sladen> I was looking at the i810 issue earlier (i810switch prove)
[07:32] <sladen> i810switch probe
[07:33] <Kamion> tfheen: ... y'know, Adam can keep ktorrent
[07:34] <Kamion> I've hit my "way too horrible" barrier
[07:37] <tfheen> keescook: ok, that's about where I've gotten to.  Enjoy your debugging session.
[07:38] <keescook> tfheen: looks like the save_state function just reports errors instead of quitting out.  :P  so it plows ahead even those the very first call fails.  :P
[07:39] <tfheen> keescook: that's, AIUI, normal.
[07:39] <tfheen> keescook: also, the VESA initialisation shouldn't fail either.
[07:39] <keescook> tfheen: heh.  oh.  okay.  :P
[07:40] <keescook> the save_state function seems to really depend on the size returned, though.  ?
[07:40] <tfheen> Kamion: heh.  We really want it fixed before release, though.
[07:40] <tfheen> keescook: yes, the bug is probably somewhere in x86emu.
[07:41] <Kamion> tfheen: too horrible for a Sunday evening, anyway
[07:41] <tfheen> Kamion: yeah, understandable. I'm saved by not having anything resembling a usable ppc.
[07:43] <Kamion> oh, damn, hash_ left
[07:44] <Kamion> I can't seem to reproduce that problem; the only problem with the URL he gave was that I need to set the character encoding manually
[07:51] <Kamion> unmarked as RC
[07:52] <fabbione> siretart: i am only mass-filing bugs.. i don't check all the failures in details. whatever it is.. something is broken and need fixing
[07:52] <tfheen> Kamion: ok.
[07:55] <geser> can someone review the debdiff for bug 66212 and upload it?
[07:55] <Ubugtu> Malone bug 66212 in wpasupplicant "FTBFS in edgy" [High,Confirmed]  http://launchpad.net/bugs/66212
[07:55] <Kamion> tfheen: what should be done with the two bugs currently targetted at ubuntu-6.10-beta?
[07:55] <Kamion> bug 63823, bug 63975
[07:55] <Ubugtu> Malone bug 63823 in update-manager "Edgy : Randomn crash on quit" [Medium,Needs info]  http://launchpad.net/bugs/63823
[07:55] <Ubugtu> Malone bug 63975 in network-manager "Please sponsor network-manager upload" [High,Confirmed]  http://launchpad.net/bugs/63975
[07:56] <Kamion> I presume they should be retargetted at ubuntu-6.10 and checked
[07:57] <tfheen> yes, they should be retargetted.  They weren't 6.10-beta-targetted when beta released.
[08:07] <Kamion> tfheen: done
[08:09] <tfheen> Kamion: thanks.
[08:09] <Kamion>   109625 | S- | speedcrunch          | 0.7~060412-0ubuntu5  | 44 minutes
[08:09] <Kamion>          | * speedcrunch/0.7~060412-0ubuntu5 Component: main Section: kde
[08:09] <Kamion>   109623 | S- | acpi-support         | 0.90                 | 54 minutes
[08:09] <Kamion>          | * acpi-support/0.90 Component: main Section: admin
[08:10] <tfheen> Kamion: acpi-support is approved.
[08:11] <Kamion> tfheen: speedcrunch is removing build-dep on libqt4-debug-dev (NBS); acpi-support is mjg59's vbetool vgamode set 3
[08:11] <tfheen> Kamion: ok, speedcrunch approved too, then.  Who uploaded it?
[08:11] <Kamion> Riddel
[08:11] <Kamion> l
[08:11] <tfheen> Kamion: ok, thanks.
[08:12] <tfheen> Riddell: again, please, please tell me about uploads you make rather than leaving me to work them out by myself.
[08:29] <hash_> kamion: when you tested firefox with the patch what were the contents of /var/lib/locales/supported.d
[08:30] <tfheen> hash_: he went to dinner, but he'll probably be back in a bit, if I know him correctly.
[08:35] <hash_> tfheen: Hi, would you be able to check the rendering?
[08:36] <tfheen> hash_: no, sorry, I'm deep into some other hacking.
[08:37] <hash_> tfheen: no probs.
[08:44] <shining> doko__: ping
[08:59] <sivang> tfheen: so *any* upload needs to be in advance notified to you? (I have some hubackup fixes I'd like to push before release)
[08:59] <sivang> tfheen: (hubackup is in universe)
[08:59] <tfheen> sivang: if it's in main, preferably.
[09:00] <tfheen> sivang: if it's in universe, I ignore it anyway.
[09:00] <tfheen> it won't go onto the CDs, etc, etc so talk to dholbach.
[09:00] <sivang> ah, okay cool
[09:04] <Kamion> $ cat /var/lib/locales/supported.d/si
[09:04] <Kamion> si_LK UTF-8
[09:04] <Kamion> hash_: ^--
[09:05] <Kamion> (I installed language-pack-si first)
[09:05] <hash_> Kamion: here's a screenshot: http://cvs.savannah.nongnu.org/viewcvs/*checkout*/sinhala/patches/icu-sinhala-rendering.png?root=sinhala
[09:06] <hash_> Kamion: Is that how it rendered?
[09:06] <Kamion> hash_: yep
[09:06] <hash_> Kamion: can you please do: ls /var/lib/locales/supported.d
[09:06] <Kamion> it looked correct to me; I don't speak Sinhala, but it didn't look like "formatting characters" either
[09:06] <Kamion> is that .png an image of correct rendering or incorrect rendering?
[09:07] <Kamion> $ ls /var/lib/locales/supported.d
[09:07] <Kamion> en  local  si
[09:07] <hash_> correct rendering
[09:07] <Kamion> oh, I have LANGUAGE set
[09:07] <hash_> In firefox it won't look like formatting characters. It just doesn't reorder the glyphs correctly.
[09:07] <Kamion> doesn't seem to matter though
[09:08] <Kamion> oh. want me to get screenshots to compare?
[09:08] <hash_> run: MOZ_DISABLE_PANGO=0 firefox
[09:09] <hash_> is the rendering different to the screenshot?
[09:09] <Kamion> hash_: sorry, I'm not quite sure what you're trying to get at here - the rendering looked *correct* to me even without the patch
[09:10] <hash_> Kamion: Pango is currently on enabled if bn|gu|hi|kn|ml|mr|ne|pa|ta|te these locals are there.
[09:10] <Kamion> I'm using http://people.ubuntu.com/~cjwatson/tmp/icu-sinhala-rendering.txt to avoid having to set the character encoding manually
[09:10] <Kamion> hash_: yes, I understand that and I changed /usr/bin/firefox temporarily for testing
[09:11] <Kamion> in order to confidently apply your patch and push it through for RC, I need to be able to see a difference in firefox with and without that patch
[09:11] <hash_> Kamion: I'm trying to work out how Pango is getting enabled without the patch on your system. Any ideas?
[09:12] <Kamion> oh, right, I see what you mean now
[09:12] <hash_> That's why I asked for an ls of /var/lib/locales/supported.d
[09:13] <Kamion> hash_: I ran firefox under 'bash -x'; it's definitely setting MOZ_DISABLE_PANGO=1
[09:15] <hash_> with the patch?
[09:15] <Kamion> hash_: no
[09:15] <Kamion> + egrep '^(bn|gu|hi|kn|ml|mr|ne|pa|ta|te)_' /var/lib/locales/supported.d/en /var/lib/locales/supported.d/local /var/lib/locales/supported.d/si
[09:15] <tfheen> hash_: Kamion needs to be able to see what's wrong, then that it's fixed by the patch.  Without that, we won't apply the patch.
[09:15] <Kamion> + MOZ_DISABLE_PANGO=1
[09:15] <Kamion> + export MOZ_DISABLE_PANGO
[09:16] <Kamion> (you confused me by asking for an ls of /var/lib/locales/supported.d - firefox doesn't care about the filenames, it cares about the contents)
[09:17] <hash_> I just needed to know what files where there.
[09:17] <Kamion> you needed to know their contents, actually
[09:17] <hash_> Kamion: could you take a screenshot and put it on the web?
[09:17] <Kamion> but in any case none of those languages are there
[09:18] <hash_> You can work out the latter from the former
[09:19] <Kamion> hash_: http://people.ubuntu.com/~cjwatson/tmp/sinhala-unpatched.png
[09:19] <Kamion> hash_: no, you really can't - the contents of /var/lib/locales/supported.d/local can't be determined from the filename
[09:19] <Kamion> if you don't believe me, tell me what's in there :-)
[09:20] <hash_> so that's incorrect rendering
[09:20] <Kamion> ok
[09:20] <Kamion> what's incorrect about it? (I believe you, just trying to understand so I can compare)
[09:20] <hash_> incorrect: the dependent vowel modifiers succeed the consonants always.
[09:21] <hash_> correct: some of the dependent vowel modifiers precede the consonants.
[09:21] <slomo> tfheen: are uploads to main for fairly trivial bugfixes still allowed? i uploaded a libnotify with some small patches ~2 weeks ago but forgot to add simple patchsystem to debian/rules :/ bug #63335 and the duplicate is about it
[09:21] <Ubugtu> Malone bug 63335 in libnotify "patches in debian/patches are not applied" [Medium,Confirmed]  http://launchpad.net/bugs/63335
[09:21] <Kamion> ah, I see
[09:21] <Kamion> ok, it was clearer once I actually compared them side by side
[09:22] <Kamion> and wasn't expecting there to be Unicode replacement characters or something in there
[09:22] <Kamion> hash_: does http://people.ubuntu.com/~cjwatson/tmp/sinhala-patched.png look right, then?
[09:22] <hash_> please have a careful look at rows 11 to 16.
[09:22] <hash_> Kamion: yes! :-)
[09:23] <hash_> compare rows 11 to 16 of the two.
[09:23] <tfheen> slomo: no, sorry.
[09:23] <Kamion> yep, I see, and the bits around the bottom of the characters on rows 8 and 9 are different too
[09:23] <slomo> tfheen: ok, np
[09:23] <hash_> yep.
[09:23] <Kamion> hash_: ok, thanks a lot, sorry for giving you the run-around on that
[09:24] <tfheen> slomo: we're just too close to release.
[09:24] <hash_> that's ok, it's not the first time and it won't be the last. ;-)
[09:24] <Kamion> you need to invent less subtle rendering bugs ;-)
[09:25] <hash_> hehe. when it comes to i18n, it usually takes a little while to convince maintainers.
[09:25] <hash_> So relatively speaking, this has been one of the quickest positive responses I have had in 3 years! :-)
[09:26] <tfheen> hash_: it's more that most of us are western-language people who are (unfortunately) ignorant of a lot of the issues affecting non-latin languages.  Even those of us who have gone through this a couple of times for different languages stumble across new problems for new languages.
[09:27] <Kamion> now all I need is enough disk space to build a firefox source package
[09:27] <tfheen> Kamion: do it on a porter box?
[09:27] <Kamion> yeah, I've done lots of i18n work in the past for various languages - it's usually more obvious when stuff breaks :)
[09:27] <Kamion> tfheen: if I have to, yeah. I think I'm not far short so I'll just zap a few things.
[09:27] <giskard> Kamion: do you need diff, dsc of NM?
[09:28] <Kamion> hoary and breezy chroots can go
[09:28] <Kamion> giskard: nothing to do with me - I was just changing the bug targets since the 6.10 beta is out
[09:28] <tfheen> doing installations in languages you have no idea about and debugging problems in those is.. interesting.
[09:28] <giskard> Kamion: ah! ok :)
[09:28] <tfheen> like me fixing korean support for dapper.
[09:29] <hash_> do you guys have access to native speakers, so that you can ask?
[09:29] <tfheen> hash_: sometimes.
[09:29] <tfheen> depends on the language and such.
[09:29] <Kamion> hash_: mostly via helpful folks like you
[09:30] <Kamion> we have some spread of languages on the Canonical staff but it's obviously far from complete
[09:30] <hash_> There's Sri Lanka Ubuntu team. I assume other countries have such teams too.
[09:30] <Kamion> the community's big enough now that it's getting easier
[09:31] <Kamion> often, though, the latency involved is such that if you have the broken system in front of you it can be easier to guess
[09:31] <tfheen> Sinhala is a Sri Lankan language?
[09:31] <hash_> BTW, is rendering of Latin based character sets in firefox *without* bug that much quicker than *with* Pango?
[09:31] <tfheen> hash_: yes.
[09:31] <Kamion> tfheen: we did this earlier :-)
[09:31] <Kamion> 17:47 < tfheen> Kamion: the change looks innocent enough; I have no idea whether it's needed for Sinhalese, though, given that even with the name I'm not sure where it's spoken.
[09:31] <Kamion> 17:47 < mdke_> sri lanka
[09:31] <hash_> Yeah Sinhala is the main language of Sri Lanka
[09:31] <Kamion> hash_: yes - disabling Pango dealt with a *lot* of complaintss
[09:32] <tfheen> Kamion: ah, ok.  I didn't see mdke_'s reply.
[09:32] <Kamion> -s
[09:32] <tfheen> Pango is horribly, horribly slow.
[09:32] <Kamion> the complaints were mostly of the form "I tried upstream's binaries and they were an order of magnitude faster. You guys suck"
[09:32] <hash_> Because Fedora Core and Debian use Pango by default.
[09:32] <tfheen> if it would grow optimisations for ascii/latin languages, I wouldn't mind, really.  Unsure how easy that is to do, though.
[09:32] <Kamion> yes, Debian gets the complaints too
[09:33] <Kamion> don't know about Fedora, as I'm not active in that community
[09:33] <hash_> I actually use Debian, and was using Fedora before.
[09:33] <hash_> But Majority of new Linux uses in SL use Ubuntu.
[09:34] <Kamion> Debian doesn't have the MOZ_DISABLE_PANGO optimisation
[09:35] <hash_> This particular problem was discovered in July: http://sinhala.linux.lk/enabling-pango-in-firefox-to-enable-sinhala
[09:35] <Kamion> so they don't run into the sort of problem you did here, but they also still get the slowness complaints
[09:35] <hash_> But I didn't get around to addressing it till now. Deadlines do wonders! hehe
[09:35] <Kamion> tell us about it ;-)
[09:36] <hash_> 0h yeah, sorry, completely forgot!
[09:36] <tfheen> hash_: usually, we appreciate if people do get around to telling us about those kinds of problems a bit earlier.  To put it this way; I wouldn't have accepted the update tomorrow.
[09:37] <pygi> Kamion: tell me more about hfs and hfs+ deadlines =)
[09:37] <hash_> tfheen: wow, that was a little too close then, lucky I stayed up - it's now 5:37am (AUS)
[09:37] <tfheen> hash_: and lucky that I felt like looking at IRC today.  It's sunday here and I'm supposedly not working.
[09:38] <hash_> tfheen: much appreciated!
[09:38] <hash_> is the 16th some kind of deadline?
[09:38] <Kamion> hash_: we're releasing Thursday week
[09:39] <Kamion> this coming Thursday is release candidate, so we lock down for everything non-essential a little before that
[09:40] <tfheen> the images which are done in ~12 hours are hopefully the release candidate image.
[09:40] <tfheen> +s
[09:40] <ajmitch> Kamion: universe continues as normal?
[09:40] <Kamion> tfheen: with 40+ RC bugs, mind you ...
[09:40] <Kamion> ajmitch: for a bit, yeah, but don't push it :)
[09:40] <tfheen> (ok, I don't really believe that, but at that point I'm going to really start rejecting uploads and removing milestones)
[09:40] <Kamion> (for your own sakes)
[09:40] <tfheen> ajmitch: requires approval, but yes.
[09:41] <Kamion> ajmitch: speaking of which, unapproved has telepathy-python 0.13.3-0ubuntu2 and xen-3.0 3.0.3~rc5-0ubuntu1
[09:41] <ajmitch> I don't plan to leave it right to the last minute, but we haven't had many fixes uploaded this last week
[09:41] <ajmitch> I'm happy with xen-3.0, of course. who did telepathy-python?
[09:42] <tfheen> Kamion: 40+ RC bugs > pft, they'll all be gone tomorrow morning.  *cough*
[09:42] <Kamion> hash_: ok, new firefox is building and should be in the archive in a few hours
[09:43] <Kamion> +telepathy-python (0.13.3-0ubuntu2) edgy; urgency=low
[09:43] <Kamion> +
[09:43] <Kamion> +  * Really dropped:
[09:43] <Kamion> +    debian/patches/01-from-darcs_update-to-new-manager-format.patch
[09:43] <Kamion> +
[09:43] <Kamion> + -- Riccardo Setti <giskard@ubuntu.com>  Sun, 15 Oct 2006 17:08:57 +0000
[09:43] <ajmitch> heh, ok
[09:43] <ajmitch> put it through
[09:43] <hash_> Kamion: Thanks again and good night
[09:43] <Kamion> ok, accepted
[09:43] <Kamion> hash_: no worries, it's my job ...
[09:44] <giskard> Kamion: ajmitch thank you
[09:44] <ajmitch> the rest of us just do it for fun :)
[09:45] <hash_> tfheen: thanks and if you need any Indic or Unicode help in general just contact Sri Lanka local team and they'll contact me
[09:45] <tfheen> hash_: coolie, thanks.
[09:45] <Kamion> oh, DAMN, that reminds me
[09:45] <tfheen> I'll try to remember. :-)
[09:45] <Kamion> I was supposed to remove Dzongkha and Khmer support from ubiquity for now due to lack of fonts and translations
[09:53] <hash_> Kamion: Changelong: "Disable Pango if a Sinhala locale is present." You meant Enable right?
[09:54] <Kamion> hash_: yes, I did, whoops
[09:54] <Kamion> sorry about that
[09:54] <tfheen> hash_: the switch is the wrong way around, it should really have been named _ENABLE_PANGO, not DISABLE_TANGO.  IMO, at least.
[09:54] <Kamion> I added it to that list, anyway, as per your patch
[09:54] <tfheen> s/TANGO/PANGO/
[09:57] <hash_> tfheen: true, not sure why it was done this way around
[09:58] <hash_> tfheen: my guess those would be that there was a lot of demand for *disabling* Pango at the time and hence the usage of _DISABLE_.
[09:58] <tfheen> yeah, I guess.
[10:00] <hash_> tfheen: BTW when does the next sync with Debian unstable occur?
[10:00] <sivang> when edgy+1 opens, AFAICR no?
[10:00] <hash_> sivang: when's that?
[10:00] <tfheen> hash_: when edgy+1 opens, so in about two weeks.
[10:01] <Kamion> plus next release setup and get-round-to-it time
[10:02] <Kamion> add another week or two in practice
[10:02] <Kamion> we need to bootstrap the new toolchain first
[10:02] <Kamion> that's being prepared already, so I hope it won't take too long
[10:02] <sivang> right
[10:03] <sivang> this soyuz responsibility? (new toolchain)
[10:03] <hash_> Ok thanks, will try to get any other changes into Debian before then.
[10:03] <hash_> or upstream.
[10:03] <Kamion> we'll be syncing on an almost-daily basis for a couple of months after that
[10:03] <Kamion> at least for automatic syncs (no Ubuntu changes)
[10:04] <sivang> Kamion: this is going to be regular cycle time this round right?
[10:04] <sivang> (we've caught up after the dapper delay by now)
[10:05] <hash_> Kamion: brilliant, *months* is good.
[10:06] <Kamion> sivang: yes, I expect so
[10:18] <Kamion> hmm, bug 66214 seems RC if true
[10:18] <Ubugtu> Malone bug 66214 in tasksel "Installation of daily build 10/14 fails" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66214
[10:22] <tfheen> Kamion: targetted
[10:23] <Kamion> I see what might be causing that. Hmm. Hmm.
[10:23] <Kamion> aptitude doesn't fail if the task is missing. apt-get does ...
[10:24] <tfheen> ouch.
[10:24] <tfheen> well, your cour.
[10:24] <tfheen> +t
[10:24] <Kamion> the fix might be to drop the stupid derivative-specific *-standard tasks and replace them with a single standard task
[10:24] <Kamion> since they're all the same anyway
[10:28] <Kamion> at least one good thing is that I don't need to change bits of Launchpad any more to do this kind of thing
[10:29] <Kamion> ok, going to do that, it's the sane answer
[10:29] <Kamion> tfheen: will be a seed change plus a tasksel chang
[10:29] <Kamion> e
[10:29] <tfheen> Kamion: big ones?
[10:29] <Kamion> nah
[10:29] <Kamion> -# Only per-derivative for historical reasons because the archive already has
[10:29] <Kamion> -# ubuntu-standard etc. We should fix this, since it's never really been
[10:29] <Kamion> plus automatic refresh of tasksel
[10:29] <Kamion> -# sensible for standard to be per-derivative.
[10:29] <Kamion> -Task-Per-Derivative: 1
[10:31] <Kamion> that will collapse the *-standard tasks down into a single standard task; as far as I can see and remember, only tasksel internals know about the standard task now
[10:31] <tfheen> it won't blow up upgrades?
[10:31] <Kamion> upgrades don't (yet) know about tasks at all
[10:32] <Kamion> the ubuntu-standard metapackage will stay the same
[10:33] <tfheen> oh, and we didn't use to have xubuntu-standard and kubuntu-standard langpacks?
[10:33] <Kamion> YM metapackages?
[10:34] <tfheen> yes, sorry.
[10:34] <tfheen> my brain is obviously confused.
[10:34] <Kamion> no, and it wouldn't matter anyway, the diff above only affects tasks not metapackages
[10:34] <tfheen> this'll be a fun last bit of a cycle.
[10:34] <tfheen> ok, coolio
[10:35] <shawarma> Does anyone know why user-mode-linux is not in edgy?
[10:40] <shawarma> Kamion: You usually know this kind of thing, don't you?
[10:41] <Kamion> shawarma: was removed ages ago IIRC; I think (a) it had been removed from Debian at the time and (b) we didn't have the time to keep it up to date with our kernel
[10:41] <Kamion> I see it's back in Debian now, but we certainly won't import it again for Edgy now
[10:42] <shawarma> Kamion: Well, it's a universe thing anyway, so I'm just curious why it never showed up in MoM..
[10:42] <Kamion> might've been blacklisted
[10:42] <Kamion> removed packages sometimes are
[10:42] <shawarma> Kamion: Oh. 
[10:42] <Kamion> yeah, apparently was
[10:42] <Kamion> http://people.ubuntu.com/~cjwatson/sync-blacklist.txt
[10:43] <shawarma> Kamion: I just fell over an e-mail to ubuntu-devel ml from late in the Dapper cycle asking where it went and now I discover that it's still gone. :-)
[10:44] <Kamion> I don't seem to have access to jackass any more to get at the pre-Soyuz removal log
[10:44] <shawarma> Kamion: Any reason why it couldn't be un-blacklisted now?
[10:44] <shawarma> jackass?
[10:44] <Kamion> shawarma: old ftp-master machine
[10:44] <shawarma> Kamion: oh.
[10:45] <Kamion> I dunno, it still falls over the "we do our own kernel" criterion
[10:46] <shawarma> Kamion: How so? We make our own versions of a lot of other stuff as well and we handle the "problems" that arise from that.
[10:46] <Kamion> ah, at the time I think it was still on 2.4
[10:46] <shawarma> oh dear.
[10:46] <Kamion> shawarma: kernel stuff's tricky, because we want to keep the amount of rebuilding we have to do for security updates as low as possibl
[10:46] <shawarma> Well, uml definitely works on 2.6 now.
[10:46] <Kamion> e
[10:46] <Kamion> and user-mode-linux is yet another package that would have to be rebuilt each time
[10:47] <shawarma> Kamion: Even if it was in universe?
[10:47] <Kamion> shawarma: I'd rather you talked to Ben Collins about this to see if you can work out a good solution
[10:47] <Kamion> shawarma: yes
[10:47] <Kamion> we removed all the kernel patches, similarly
[10:47] <Kamion> in Ubuntu, as much as possible goes into the mainline kernel
[10:48] <Kamion> any variations from that must be cleared with the kernel team
[10:48] <Kamion> because they're the ones who'll have to deal with the fallout if somebody isn't around to update dependent packages
[10:48] <shawarma> Kamion: Which patches were removed? I have a load of kernel-patch-* packages in my apt-cache?
[10:48] <Kamion> they *were* removed - some might have sneaked back in
[10:49] <Kamion> I don't care to go and investigate at the moment because I'm fixing multiple RC-targetted bugs
[10:49] <shawarma> Kamion: Ah, ok.
[10:49] <Kamion> since this is all post-Edgy anyway, I'd rather defer any investigation until later
[10:49] <shawarma> Kamion: That's fine. I'll take it up with BenC at some point.
[10:49] <shawarma> Kamion: Thanks for your time.
[10:49] <Kamion> it's all got his name attached in the sync blacklist
[10:50] <Kamion> which means he's the go-to person for any changes :)
[10:50] <Kamion> no problem
[11:01] <mikael_> hi there. i am trying to compile a package from its sourrce
[11:01] <mikael_> i just grabbed it via svn
[11:01] <mikael_> but no howto (on ubuntu.com) could help me
[11:01] <mikael_> i am using kubuntu 6.06
[11:01] <mikael_> and i have already apt the build-essential packages
[11:02] <mikael_> ./configure; ./make; ./make install won't lead me to a positive result
[11:02] <mikael_> maybe one has an idea?
[11:03] <mikael_> this is the page i grabbed it from:  http://www.willwap.co.uk/Programs/vbrfix.php#DL
[11:03] <mjg59> Woo
[11:03] <mjg59> Well, got usplash into a state where it oopses the kernel
[11:09] <tfheen> mjg59: I'm not sure I'd characterise that as progress..
[11:09] <tfheen> though, it's different.
[11:10] <mjg59> tfheen: The mmapping of the interrupt vectors can never work
[11:10] <mjg59> It's behaving as though they'll be mmaped to 0, which is just not going to happen
[11:11] <mjg59> tfheen: Hacking with that in vbetool seems to have changed how things behave, anyway. Not sure that it's /working/ yet, but still
[11:11] <tfheen> mjg59: won't it just have to be mmapped to the real_base?
[11:12] <mjg59> Yes
[11:12] <mjg59> But what's currently happening seems to be that they get mapped to 0x1000
[11:12] <mjg59> Which is then likely to result in things not working
[11:12] <mjg59> (surely?)
[11:12] <tfheen> that's weird, give we map it with MAP_FIXED.
[11:13] <tfheen> sure you're not looking at the first mmap call?
[11:13] <mjg59> Yes
[11:13] <mjg59> The manpage for mmap says that it will never return 0
[11:14] <mjg59>       m = mmap((void *)0, 0x502,
[11:14] <mjg59> (etc)
[11:18] <tfheen> RETURN VALUE On success, mmap() returns a pointer to the mapped area.  On error, the value MAP_FAILED (that is, (void *) -1) is returned, and errno is  set  appropriately. 
[11:20] <mjg59> "The actual place  where  the object is mapped is returned by mmap(), and is never 0."
[11:21] <tfheen> hmm, ok.
[11:21] <tfheen> I guess we should really pick some other mem_base, then?
[11:21] <mjg59> Yeah
[11:22] <tfheen> but does that fix the problem or just create a new problem?
[11:22] <tfheen> and how this did ever work?
[11:22] <mjg59> No idea
[11:23] <mjg59> Hrm.
[11:23] <mjg59> Why is it now exiting with a return code of 3?
[11:24] <sivang> laters all
[11:24] <sivang> (or good night)
[11:24] <mjg59> Oh, argh.
[11:32] <mjg59> tfheen: This turns out to be difficult, for subtle reasons
[11:32] <mjg59> Though I may have an idea
[11:35] <tfheen> what subtle reasons?
[11:35] <mjg59> alloc_real needs to return a pointer that refers to mapped memory
[11:35] <mjg59> But that then gets passed in as an argument and used as an offset from mem_base
[11:37] <tfheen> can't mem_base be subtracted from it?
[11:37] <tfheen> hmm
[11:37] <mjg59> Not without breaking compatibility with lrmi
[11:37] <mjg59> And having to change every call made
[11:37] <tfheen> that's a point.
[11:37] <mjg59> So, what we could do is just mmap it twice?
[11:37] <mjg59> Once to the absolute range and once to the relative range?
[11:38] <tfheen> are there that many calls which use memory returned from alloc_real?
[11:38] <mjg59> Yes
[11:38] <tfheen> ok
[11:39] <tfheen> we could do really, really evil tricks.
[11:40] <tfheen> like, look at the pointer, and if it's bigger than 10MB treat it as an absolute pointer, if not treat it as a relative pointer.
[11:41] <_ion> ;-)
[11:41] <mjg59> tfheen: Dude. So no.
[11:41] <mjg59> tfheen: We can mmap things twice, right?
[11:41] <tfheen> mjg59: sure, that's easy.
[11:41] <tfheen> but will it work?
[11:42] <mdeslaur> What's the process to get a patch added to gnomebaker in edgy/dapper backports?
[11:42] <pygi> mdeslaur: I dont think you can add a patch to backports
[11:43] <mdeslaur> pygi- ok, how about getting it added to edgy?
[11:44] <pygi> mdeslaur: that's also a no go for now
[11:44] <pygi> once edgy is released, it may go to -updates tho
[11:44] <pygi> mdeslaur: have you submited it upstream? 
[11:44] <mdeslaur> pygi: yes, it's in gnomebaker cvs
[11:45] <pygi> mdeslaur: oh, what does it fix? I'll talk to Luke Biddell to see how important that is
[11:45] <mdeslaur> pygi: gnomebaker 0.6 is seriously broken for people with a cd-reader and a cd-writer
[11:45] <mdeslaur> pygi- when you try to burn to a cd/dvd writer, it miscaculates and tries to burn to the wrong device
[11:46] <pygi> mdeslaur: could I see the diff pls?
[11:46] <mjg59> tfheen: Ehm. Well, it fails differently...
[11:46] <pygi> mdeslaur: ah, I know about that problem
[11:46] <pygi> mdeslaur: diff pls
[11:46] <mdeslaur> pygi: http://sourceforge.net/tracker/index.php?func=detail&aid=1576272&group_id=127397&atid=708501
[11:47] <Ubugtu> Sourceforge bug 1576272 "Patch to fix bug #1522258" [Pri: 5,Closed accepted]  
[11:47] <mjg59> tfheen: Now it blows up in X86EMU_setupPioFuncs
[11:48] <pygi> mdeslaur: sec pls
[11:49] <tfheen> that's a fairly trivial function; how does it blow up?
[11:49] <doko_> infinity: awake?
[11:49] <pygi> mdeslaur: the diff seems sane
[11:50] <pygi> mdeslaur: I don't think we'll change anything at this point, but if you file a bug and assign it to me I think it'll get in -updates
[11:51] <mdeslaur> pygi: ok, launchpad #63805. How do I assign it to you?
[11:51] <pygi> bug #63805
[11:51] <Ubugtu> Malone bug 63805 in gnomebaker "Gnomebaker 0.6 not recognizes my CD-RW" [Undecided,Unconfirmed]  http://launchpad.net/bugs/63805
[11:51] <tfheen> doko_: if you need a give-back or similar buildd admin tasks, I'm still awake.
[11:52] <pygi> mdeslaur: done, I'm assigned
[11:52] <mjg59> tfheen: So I've got it into a state where I think it ought to work, but instead it's failing in a bizarre manner
[11:52] <doko_> tfheen: just OOo uploads which should build on palmer to not disturb other things
[11:52] <pygi> mdeslaur: thanks for notification :)
[11:53] <Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/tasksel.diff FYI
[11:53] <mdeslaur> pygi- once it's in edgy-updates, it can go in dapper-backports?
[11:53] <pygi> mdeslaur: I could rebuild the package with patch if you want, so you could get it from my site
[11:53] <pygi> mdeslaur: uh, I can't promise anything, but I can try
[11:53] <pygi> I'm not sure on our backports policy
[11:54] <mdeslaur> thanks pygi
[11:54] <Kamion> mdeslaur: yes, assuming it builds cleanly on dapper
[11:54] <tfheen> Kamion: ok, looks good
[11:54] <pygi> Kamion: patch is trivial, I don't see any problems why it shouldn't
[11:55] <mdeslaur> Kamion: dapper had a working gnombaker 0.52 and dapper-backports has a broken gnomebaker 0.6
[11:55] <tfheen> Kamion: (approved)
[11:55] <pygi> (broken in sense of that patch)
[11:55] <pygi> mdeslaur: luke should just do point releases more often
[11:56] <mdeslaur> yes :)
[11:56] <Kamion> pygi: if you're really confident in it, and the problem is that serious, then edgy/universe is still somewhat open
[11:56] <tfheen> doko_: infinity told me how to do that, but I'm not sure I remember right now, so I'll leave it.
[11:57] <pygi> Kamion: oh, really? Would be very nice to get it in then. This way gnomebaker is broken if you have more then 1 drive
[11:57] <Kamion> um, OOo needs to build ASAP though?
[11:57] <doko_> tfheen: ok, I'll upload then before I go to bed, and send an email to infinity and you
[11:57] <Kamion> assuming that's OOo proper
[11:57] <tfheen> doko_: thanks.
[11:57] <doko_> Kamion: why?
[11:58] <tfheen> doko_: because it should be built before we start building candidate ISOs tomorrow morning.
[11:59] <doko_> hmm, ok. but then I would need palmer now ... to have it built in 6.5h ...
[11:59] <tfheen> is it accepted yet?
[12:00] <mjg59> tfheen: Hrm. Where does the stack usually end up?
[12:00] <pygi> Kamion: if it's not a problem it's: http://librarian.launchpad.net/4820538/gnomebaker-0.6.0-device.patch
[12:00] <pygi> Kamion: but if it makes any trouble for you, dont bother
[12:00] <doko_> no, test build is still in it's install stage ...
[12:00] <tfheen> mjg59: hmm, I can't really remmeber.  0x1000 maybe?
[12:00] <Kamion> tfheen: only thing in unapproved is xorg-server. what are we going to do about that, BTW? just accept it on the grounds that we should get something in
[12:00] <Kamion> pygi: er, sorry if I unintentionally misled you, but I didn't mean to suggest that I was going to take care of it
[12:01] <Kamion> pygi: a MOTU who uses gnomebaker should do it
[12:01] <doko_> -l10n will need another hour or so
[12:01] <tfheen> Kamion: the problem with it is that it patches debian/local from debian/patches?
[12:01] <Kamion> tfheen: yees
[12:01] <Kamion> yes
[12:01] <tfheen> Kamion: what's the changelog?
[12:01] <pygi> Kamion: ok, as long as universe is open 
[12:01] <adamh> What package holds /usr/lib/python2.5/pstats.py?
[12:01] <adamh> I tried python-profiler but it only works for python2.4.
[12:02] <Chipzz> adamh: this is not a support channel
[12:02] <Chipzz> adamh: try packages.ubuntu.com
[12:02] <adamh> Chipzz: I'm a deloper... this is a developer support channel, isn't it?
[12:02] <Chipzz> no it is not
[12:02] <Kamion> this is for development of Ubuntu, not development on Ubuntu
[12:02] <Chipzz> it is a channel about developing ubuntu, not developing *with* ubuntu
[12:03] <adamh> Ah, good point. Okay, let me rephrase: "I think there's no package that holds /usr/lib/python2.5/pstats.py -- is this a known bug?"
[12:03] <mjg59> tfheen: Ok, a little further. Moving REAL_MEM_BASE seems to have helped
[12:03] <tfheen> mjg59: hmm, ok.
[12:03] <Chipzz> speaking of which, packages.ubuntu.com seems a bit out-of-date
[12:04] <tfheen> mjg59: I have to go to bed now, but I'll be happy to be useful for you tomorrow.
[12:04] <mjg59> tfheen: In that I don't seem to be scribbling over the stack any more, at least
[12:04] <mjg59> tfheen: Ok
[12:04] <tfheen> mjg59: yay, good.
[12:04] <Kamion> tfheen: /usr/lib/python2.5/pstats.py
[12:04] <Kamion> err
[12:04] <mjg59> Now I'm just left with it segfaulting for no obvious reason
[12:04] <Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/xorg-server.diff
[12:04] <Kamion> Chipzz: known, the Soyuz guys need to do a Contents generation run
[12:04] <Kamion> it'll be done before release, probably just before
[12:05] <tfheen> Kamion: approve it; the patching of debian/local is wrong and slightly crackful, but should work just fine.
[12:05] <shining> adamh: try apt-file
[12:05] <tfheen> Kamion: unless you have serious complaints?
[12:05] <Chipzz> Kamion: that doesn't get run automagically?
[12:06] <adamh> shining: Ooh wow, never heard of that :). Thanks :)
[12:06] <Kamion> Chipzz: not at present, unfortunately
[12:06] <Chipzz> shining: packages.ubuntu.com does the same as apt-file
[12:06] <Kamion> shining: apt-file is out of date for the same reason packages.ubuntu.com is
[12:06] <Chipzz> adamh: don't use it
[12:06] <shining> Kamion: ah really? didn't know that
[12:06] <Kamion> adamh: I think python-profiler just hasn't been rebuilt to add python2.5 yet
[12:06] <Kamion> doko_: ?
[12:07] <Chipzz> you'll pull in a whole shitload of packages when installing it, and packages.ubuntu.com provides exactly the same functionality
[12:07] <Kamion> tfheen: ok, done
[12:07] <tfheen> Kamion: thanks.  Good night.
[12:07] <tfheen> see you in 8-9-ish hours.
[12:07] <Kamion> Chipzz: "don't use it" is a bit strong I think
[12:07] <Chipzz> Kamion: well, for one-time use he is better of using the website
[12:07] <Kamion> and "Depends: perl, gzip (>= 1.2.4), libconfigfile-perl, libapt-pkg-perl, wget" is hardly "a whole shitload"
[12:07] <Kamion> Chipzz: who are you to say it's one-time?
[12:08] <shining> apt-file and packages.ubuntu.com use both the same source, which is outdated?
[12:08] <Chipzz> Kamion: if you use it on a regular base, installing apt-file may be more usefull
[12:08] <Kamion> shining: correct
[12:08] <adamh> hehe, too late, I'm already done :P
[12:08] <Kamion> shining: it'll be sorted out before release
[12:08] <Chipzz> Kamion: just a hunch, since he didn't even know it existed in the first place
[12:08] <Kamion> Chipzz: remind me never to suggest any new and potentially useful tool to you
[12:08] <Kamion> you must know about them all already
[12:09] <Kamion> tfheen: sleep well
[12:09] <Kamion> doko_: also a bit odd that python-profiler only has a python2.4 module but Depends: python (<< 2.6), python (>= 2.4)
[12:09] <Chipzz> hrrm last time I considered installing it it pulled in more packages than that... must have installed some perl-packages since then
[12:10] <adamh> Kamion: Yeah, I noticed that
[12:10] <Toadstool> Kamion: hi, pygi asked me to upload the fix for gnomebaker. I just want to make sure that this ok for me to upload it. Just reviewed the patch, it's an upstream patch and it looks sane
[12:10] <Kamion> libconfigfile-perl and libapt-pkg-perl have no further perl module dependencies
[12:11] <Kamion> Toadstool: yes, although at this point in the freeze you should also be testing (or getting somebody else to test) it as well