[12:45] <enyc> I have changed the. status tags on bugs 78005 77485 ... was this right for me to do this as per the new MOTU-SRU policy?
[12:45] <ubotu> Malone bug 78005 in qpsmtpd "[SRU]  request: dapper:qpsmtpd fix for bug #72602" [Undecided,Fix committed]  https://launchpad.net/bugs/78005
[12:45] <enyc> I'm a little confused whom is now supposed to do the release- upload.... or how I do it....
[12:45] <enyc> Please let me know what todo ?? [??] 
[12:46] <enyc> (note that both bugs have now passed the ">=7 days aging and >=2 'worksforme' requirements!
[12:46] <enyc> )
[12:46] <enyc> next-step suggestion needed please ;-)
[01:51] <andre_pl_> i seem to still be plagued by this bug: https://launchpad.net/ubuntu/+source/udev/+bug/53923 with the tifm 5-in-1 media card reader. 
[01:51] <ubotu> Malone bug 53923 in udev "Texas Instruments Card reader (8039) not working" [Medium,Confirmed]  
[01:51] <andre_pl_> but its apparently fixed.
[01:52] <andre_pl_> wait, no its not. Lol.
[01:52] <andre_pl_> how can I help to fix it?
[01:54] <Chipzz> andre_pl_: I guess most developers are asleep now; but you may get more response on #ubuntu-kernel (just a wild gues without looking at the bug)
[01:54] <sladen> andre_pl_: confirm your experiences in the bug report
[01:54] <sladen> andre_pl_: they'll get recorded there, but will just scroll past here :)
[01:55] <andre_pl_> sladen: thanks
[01:55] <Chipzz> sladen: you can disregard my last comment about hal and the nvidia driver and suspend btw :)
[01:55] <sladen> andre_pl_: when it comes to eventually doing a test it's important to know who can test the result
[01:55] <sladen> Chipzz: I didn't see it in IRC hilights, was it on launchpad?
[01:55] <Chipzz> yeah, launchpad
[01:56] <Chipzz> made it last week
[01:56] <sladen> Chipzz: okay, I'll get to it in-time, but if the comment isn't correct/is now out of date, can you comment again so that we know what the status quo is
[01:56] <Chipzz> sladen: thanx for the comments and hints in that bugreport btw :)
[01:57] <Chipzz> I will, but not now ;)
[06:09] <fabbione> morning
[06:10] <sladen> just, getting, light
[06:15] <thoreauputic> Just wanted to say - Feisty is looking great! Congrats to all ... :-)
[08:23] <Mithrandir> lifeless: is there any reason why opensync is a few versions behind upstream?
[08:33] <ajmitch> hi Mithrandir 
[08:35] <manchicken__> Anybody know what "ubuntu-linux.withishow.com" is all about?
[08:35] <ajmitch> yet another planet ripoff?
[08:36] <ajmitch> there are a couple I've seen
[08:36] <manchicken__> It looks like they're trying to syndicate stuff from the ubuntu planet, and then comment on blogs to attract people to their advertising.
[08:36] <ajmitch> back later
[08:37] <Mithrandir> hiya Andrew.
[09:01] <pitti> Mithrandir: FF-wise, would you be ok with me adding a --confirm switch to debcommit? (see mdz's mail re bzr package maintenance)
[09:04] <Mithrandir> pitti: sure
[09:06] <pitti> Mithrandir: hmm, if I touch the package anyway, I guess I'll also include requestsync, to get rid of another long-standing low-priority TODO item
[09:09] <Mithrandir> sure
[09:38] <tuxcrafter> good day eveyone
[09:39] <lifeless> Mithrandir: I suck ?
[09:40] <lifeless> or azeem does. Or we both do.
[09:40] <lifeless> the theory is that azeem and I are co-maintaining the suite. However it seems to have panned out that I maintain libopensync* and he maintains the plugins and gui.
[09:40] <Mithrandir> ook
[09:41] <Mithrandir> I have a personal interest in getting my phone to sync with evo, you see, and I think the newer upstream versions fixes that.
[09:43] <Mithrandir> tepsipakki: regarding the ndiswrapper UVFe.. it's a fairly big diff which is hard to review due to the traceexit => exit changes (and other similar ones).  Do you have any reports from people running your latest package and where it works for them?
[09:48] <lifeless> Mithrandir: I have a 'anyone can NMU' policy on all my packages.
[09:48] <lifeless> Mithrandir: so if you ahve the time, upload away. It will want an ABI change though, I'm pretty sure upstream fucked the current release of the plugins et all across the recent version releases.
[09:49] <Mithrandir> lifeless: it'd require a motu-uvf exception too, so I'm trying to get somebody else to do it.
[09:49] <lifeless> Mithrandir: haha
[09:52] <tepsipakki> Mithrandir: not yet, but as you can see, most of the changes are in driver/ which isn't used in ubuntu
[09:52] <tepsipakki> the driver is in our kernel
[09:52] <Mithrandir> tepsipakki: point.
[09:52] <tepsipakki> and that is already 1.38, it's just a matter of updating the utils
[09:53] <Mithrandir> hurrah, I get to review somebody else's perl code.
[09:54] <carlos> pitti: Hi, would you like to try latest fesity export?
[09:54] <azeem> lifeless: there's the problem that opensync-0.22 or so has some different database format, so users need to remove parts of their ~/.opensync
[09:54] <carlos> pitti: it should have the weird new line chars removed completely
[09:54] <azeem> huh, opensync-0.22, my terminal is acting up
[09:54] <carlos> pitti: I did it also for the other distros
[09:54] <pitti> carlos: I already dist-upgraded today
[09:54] <carlos> dist-upgraded?
[09:55] <Mithrandir> azeem: just make the tools notice it and run opensync --reset (or the equivalent) when they detect the older database format?
[09:55] <pitti> carlos: current daily langpacks are from 20070327 timestamp
[09:55] <carlos> so you pushed yesterday tarball?
[09:55] <pitti> carlos: no, the daily ones on people
[09:55] <pitti> I didn't upload them to feisty yet, since you asked me to wait
[09:55] <seb128> hi carlos
[09:56] <seb128> carlos: did you do the french translations change yet? ;)
[09:56] <azeem> Mithrandir: that's the second problem, the GTK GUI "tool" currently in feisty is rotten and not really usable
[09:56] <azeem> a first step would be to use the one from unstable, but I wasn't sure whether this is still possible
[09:56] <carlos> seb128: no, I hadn't time, I was finishing the cleanup and run out of time to do that, but I plan to request it today
[09:56] <Mithrandir> azeem: kitchensync or multisync0.90 you mean?
[09:56] <pitti> carlos: oh, there's a 20070328 tarball from 2 o'clock today; that's the good one now?
[09:56] <carlos> pitti: would be possible to force a refresh now?
[09:56] <azeem> multisync0.09
[09:56] <Mithrandir> kitchensink is maybe the kde one?
[09:56] <carlos> pitti: yeah
[09:57] <carlos> I had to do some fixes so it was built later than expected
[09:57] <pitti> carlos: sure; I usually build them in the afternoon, but I'll crank up one now
[09:57] <azeem> Mithrandir: yes, and AFAIK nobody packaged an opensync-enabled kitchensync until now
[09:57] <carlos> pitti: thank you
[09:57] <seb128> carlos: ok, thank you, let me know when it's done
[09:57] <carlos> seb128: sure
[09:57] <seb128> cool
[09:57] <azeem> but maybe somebody from kubuntu did in the meantime, I haven't checked in a while
[09:57] <pitti> carlos: oh, in fact it's already running; I forgot, I build them at 0800 rookery time
[09:58] <carlos> but those are for Edgy, Hoary and Dapper, isn't them?
[09:58] <Mithrandir> azeem: http://www.in.fh-merseburg.de/~jahn/opensync-0.21/pool/main/o/opensync-integration-kitchensync/ isn't it?
[09:58] <pitti> carlos: no, I build dailies for feisty, too
[09:59] <carlos> oh, so you always use an old Feisty package
[09:59] <carlos> ?
[10:00] <azeem> Mithrandir: yes
[10:00] <lifeless> azeem: yeah
[10:00] <azeem> hrm right, Matthias did it in the meantime, could've guessed
[10:00] <lifeless> azeem: its why I haven't packaged it, I know it needs testing
[10:01] <lifeless> and doco and stuff
[10:10] <dholbach> hello
[10:10] <siretart> hallo dholbach 
[10:14] <dholbach> hey siretart
[10:14] <dholbach> how's it going?
[10:14] <siretart> oh, thanks. 
[10:20] <tuxcrafter> i got a very anoying bug here, i am testing openoffice 2.2 in feisty and my odt documents from v2.1 are not opened the same in 2.2 how does this come, i mean odt is a open standard and should be backwards compatible?! do you feisty users have the same problem?
[10:25] <tepsipakki> if someone would like to test the new upstream intel driver (1.9.93 aka 2.0rc3), here it is: http://users.tkk.fi/~tjaalton/xorg72/new/
[10:25] <tepsipakki> that's xserver-xorg-video-intel
[10:25] <tepsipakki> modesetting-branch merged in
[10:25] <StevenK> Mithrandir: When you have a sec, I'm curious why the 1.4-12build1 upload of imaze didn't register a build on amd64 or ia64.
[10:25] <tepsipakki> it needs the new server -3ubuntu6 I just uploaded, but a deb is available from the url
[10:25] <Mithrandir> StevenK: might be a fallout of yesterday's hiccups; I'm running the queue builder again and we can see if that helps.
[10:26] <Mithrandir> StevenK: ah, it's in PaS
[10:27] <Mithrandir> does it work and run on amd64/ia64?
[10:27] <StevenK> Hrm. I know it builds and installs fine.
[10:27] <tuxcrafter> bye
[10:27] <Mithrandir> mail infinity or lamont to get PaS updated in Debian and we'll pick it up.
[10:28] <StevenK> On amd64, anyway, since I'm too cheap to buy an Itanic :-P
[10:28] <Fujitsu> StevenK: I was going to ask how you'd tested that :P
[10:29] <StevenK> Fujitsu: There's always merkel.debian.org. For me, anyway.
[10:29] <Fujitsu> You and your evil uber-powers.
[10:29] <Mithrandir> hm, no, that's just imaze-xview.
[10:29] <Mithrandir> I can't read.
[10:30] <StevenK> Mithrandir: xview is in the archive for amd64.
[10:32] <Mithrandir> StevenK: I don't know, I'll have to ask cprov.
[10:33] <doko> ARGH!!! feisty shuts down my laptop way too often due to "critical" temparature
[10:34] <StevenK> doko: Where critical is it might make the desk slightly warm? :-P
[10:34] <Treenaks> doko: open it up,remove dust :)
[10:45] <Lure> azeem, Mithrandir: I can work on kitchensync update if you will do opensync upgrade
[10:46] <geser> StevenK: as you uploaded xview with amd64 support, does it work without the patch from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320155 ?
[10:46] <ubotu> Debian bug 320155 in xview "xview: amd64 support" [Wishlist,Open]  
[10:46] <Mithrandir> Lure: opensync is in universe, so it'd require motu-uvf approval, not ubuntu-release approval, but I would be quite happy if somebody did the work to make it work.
[10:47] <Lure> Mithrandir: afair, we need to package it as debian is not on latest, right?
[10:47] <Mithrandir> yes.
[10:48] <Mithrandir> Lure: but you'd be better off starting talking to motu-uvf to see if they think it's worth it.
[10:49] <Lure> Mithrandir: will check this first, the problem is it is hard to discuss it as nobody has tried it to confirm the benefits
[10:49] <Lure> Mithrandir: I can probably try it now, that bluetooth is fixed in kubuntu ;-)
[10:50] <_ion> pitti: "Yo inicie efectos del escritorio y me marco que no tengo el composite habilitado y luego marco el error."  yeah, thanks a lot for the bug report! ;-)
[10:51] <pitti> _ion: comprehende, amigos?
[10:52] <Mithrandir> "Tango and Composite makes my Luggage report an error".
[10:53] <pochu> _ion: I started desktop-effects and it told me I don't have composite enabled, and after that there was an error ;)
[10:55] <_ion> pochu: Hehe, thanks. The bug report *did* contain apport info, which explained everything, though, so i was just joking.
[10:55] <pochu> _ion: you could told it before :p
[10:55] <pochu> however, it wasn't a great effort, since my spanish is great :)
[10:56] <tepsipakki> eh, why do we have ndiswrapper-1.1 in main?
[10:56] <pitti> tepsipakki: it's on the kill list
[10:56] <tepsipakki> pitti: groovy
[10:56] <pochu> well, it was a great effort, because my enghish isn't :(
[10:56] <pitti> tepsipakki: bug 92622
[10:56] <ubotu> Malone bug 92622 in ndiswrapper-1.1 "[REMOVE]  Please remove ndiswrapper-1.1 from archives" [Undecided,Confirmed]  https://launchpad.net/bugs/92622
[10:56] <tepsipakki> pochu: new, working intel driver available
[10:56] <_ion> pochu: Sorry for causing extra work. :-)
[10:56] <pitti> tepsipakki: I just wante to wait for the last reverse dependency to be fixed
[10:56] <tepsipakki> pitti: ok
[10:57] <tepsipakki> just looking at the list of ndiswrapper bugs
[10:57] <pochu> tepsipakki: cool! :)
[10:57] <tepsipakki> removing -1.1 would fix bug 59983, I think
[10:57] <ubotu> Malone bug 59983 in ndiswrapper "ndiswrapper in edgy broken" [Low,Confirmed]  https://launchpad.net/bugs/59983
[10:58] <Mithrandir> pitti: there doesn't seem to be any reverse deps on ndiswrapper-1.1's binaries?
[10:59] <pitti> Mithrandir: right, because it was fixed recently (see bug trail)
[10:59] <tepsipakki> no low hanging fruits left there, it seems
[10:59] <Mithrandir> ahkay.
[10:59] <Mithrandir> tepsipakki: 59983 is one of those where I think we'll just have to work around in the update manager
[10:59] <tepsipakki> guess so
[11:37] <janimo> pitti: hi, is there a guideline in naming locales, in particular in the mozilla-firefox-locale packages? When is it recommenede to us lo_LO vs lo ?
[11:37] <janimo> pitti: as there are locales which are specific to a single country but still use the longer form (hu_HU, ro_RO) while other the simpler (sk, af)
[11:38] <pitti> janimo: the longer ones are mainly for hysterical raisins
[11:38] <janimo> pitti: what I am confronted with is, that there's a ro.xpi for ff 2.0 and it uses the ro locale all over, but teh current packaging stub have ro_RO
[11:38] <pitti> janimo: just to save us from renaming the existing packages yet again
[11:39] <pitti> janimo: for new languages, we should use whatever upstream uses
[11:39] <janimo> pitti: ok, I file a bug on mozilla-firefox-locales-all and attach the ro.xpi, is that the procedure?
[11:40] <pitti> janimo: you don't need to attach it if upstream has it
[11:40] <pitti> asac: ^ we should update m-f-local-all to 2.0.0.3, right?
[11:40] <pitti> janimo: ^ or just file a general bug about that
[11:40] <pitti> ugh, it's still at .1
[11:41] <janimo> pitti: I am not sure it's in upstream firefox, I think it's provided asa separate extension. I'll check though
[11:41] <pitti> janimo: in this case, attaching it is fine
[11:53] <dholbach> ogra: will we get dia 0.96-final?
[11:54] <dholbach> ogra: it seems to fix bug 93303
[11:54] <ubotu> Malone bug 93303 in dia "Program Dia crashes when deleting a diagram object" [Medium,Confirmed]  https://launchpad.net/bugs/93303
[12:12] <pitti> _ion: hm, did you see bug 93209? yet another missing ID
[12:12] <ubotu> Malone bug 93209 in restricted-manager "Fails to detect Nvidia 3D driver" [Medium,In progress]  https://launchpad.net/bugs/93209
[12:13] <pitti> _ion: hm, current package does not have 'manual' lists any more, does it?
[12:16] <opi> guys, can you point me to the person who owns ubuntu-*.org DNS servers? We're moving our servers and need small change in IN A records. :)
[12:17] <opi> Smurfix was the BOHF in 2004, but I renember his server went down and the DNS moved somewhere
[12:17] <highvoltage> opi: you can reach the admins on #canonical-sysadmin
[12:17] <opi> highvoltage: oh! Thanks!
[12:17] <highvoltage> opi: any time
[12:18] <kwwii> dholbach: btw. I commited another session splash last night (fixed a small problem)
[12:21] <dholbach> kwwii: uploaded
[12:21] <kwwii> dholbach: excellent, thanks :-)
[12:22] <dholbach> de rien
[12:24] <_ion> pitti: % modinfo -F alias nvidia | grep 01D8
[12:24] <_ion> pci:v000010DEd000001D8sv*sd*bc03sc*i*
[12:24] <_ion> pitti: Perhaps that was one of the IDs the amd64 port doesn't support, or something.
[12:24] <pitti> _ion: hmm, that's with your new l-r-m patch-of-doom?
[12:24] <pitti> _ion: aah, that's entirely possible; I generated it on amd64
[12:24] <pitti> _ion: thanks
[12:25] <_ion> pitti: Yeah, but the list is exactly the same as the modules.alias.override list generated from the 9631 x86 driver.
[12:25] <ajmitch> hi
[12:26] <_ion> pitti: Yeah, the amd64 port indeed doesn't list 01D8, whereas the x86 port of both 96xx and 97xx list that.
[12:27] <pitti> _ion: I changed the bug accordingly
[12:27] <_ion> pitti: It would be a huge pain to maintain both x86 and amd64 lists in the restricted-manager package. We probably should just wait until l-r-m generates the listings.
[12:27] <pitti> _ion: right, that's what I wrote in the bug
[12:28] <_ion> pitti: Btw, if it's ever needed to add manual entries, they would go to something like /usr/share/restricted-manager/modalias_override/nvidia.manual. The filename doesn't matter, but i think it's good to add '.manual' to manually edited files.
[12:29] <pitti> ah, great
[12:29] <pitti> well, I hope that this entire crack will soon disappear at all from r-m ;)
[12:30] <_ion> Yeah. :-)
[12:30] <_ion> /usr/share/restricted-manager/modalias_override/ipw3945.manual probably needs to stay, though.
[12:30] <_ion> since it doesn't seem to be a kernel module, but some kind of a daemon.
[12:31] <pitti> ah, right
[12:36] <ogra> dholbach, yes, i'm on it, the documentation is horribly broken, wroking on a patch here 
[12:36] <dholbach> ogra: ok
[12:36] <ogra> somehow the xml is messed up 
[12:42] <pochu> if any archive-admin can take a look at bug 98532 :)
[12:42] <ubotu> Malone bug 98532 in liferea "[UVFe]  Liferea 1.2.10b" [Undecided,Unconfirmed]  https://launchpad.net/bugs/98532
[12:44] <pitti> pochu: nothing to do for archive admin
[12:45] <pochu> sorry, release-admin :)
[12:45] <pitti> pochu: if you want a sync, please turn this into a sync request and get UVF exception approval from Mithrandir 
[12:45] <pochu> it's not a sync, since it's not in debian
[12:45] <pitti> ah, ok
[12:45] <pochu> but an uvf exception, yes :)
[12:46] <Mithrandir> pochu: that's not "admin" at all, it's "ubuntu-release" or "the release team". :-P
[12:46] <pochu> hehe
[12:47] <Mithrandir> anyway, looks sane, approved
[12:47] <pochu> so you or cjwatson should look at it, as the LP team page says :)
[12:47] <pochu> Mithrandir: cool, thanks :)
[12:47] <azeem> Mithrandir: I filed https://bugs.launchpad.net/ubuntu/+source/multisync0.90/+bug/98545 now for multisync0.90
[12:47] <ubotu> Malone bug 98545 in multisync0.90 "[UVFe Sync Request]  multisync0.90 0.91.0-3" [Undecided,Unconfirmed]  
[12:49] <Mithrandir> azeem: cheers.  I think it would make sense to get an approval for the whole suite, not just multisync.
[12:49] <azeem> Mithrandir: well, the rest isn't packaged yet, this one has been in unstable for a while
[12:59] <dholbach> ogra: dia 0.96.1 is out
[12:59] <dholbach> ogra: brown paper bag release
[01:02] <ogra> meh
[01:03] <ogra> ok
[01:03] <ogra> thanks dholbach 
[01:03] <dholbach> de rien ogra
[01:13] <_lemsx1_> in Feisty when i choose to switch to another user (local) the computer goes to a black screen and the switch never happens
[01:14] <_lemsx1_> this is an ATI card running fglrx driver. i'll try in another computer to see if there is a difference
[01:15] <pitti> lemsx1|gone: I noticed the same on nvidia
[01:15] <pitti> lemsx1|gone: one user had compiz, the other didn't
[01:15] <lemsx1|gone> pitti: ahh, so it's not the card
[01:15] <pitti> probably a composite bug in X.org
[01:15] <lemsx1|gone> pitti: no compiz used here
[01:16] <lemsx1|gone> pitti: did you try turning off composite? in my case it's explicitly off since fglrx doesn't support it
[01:16] <pitti> lemsx1|gone: no, I didn't
[01:16] <lemsx1|gone> pitti: i wonder under what package this bug should be filed
[01:16] <pitti> lemsx1|gone: xorg-server AFAICS
[01:17] <lemsx1|gone> pitti: ok. i see that there are two X processes running. one on :0 and another on :20
[01:17] <john> Hello. I am running Feisty, and i would like to report a bug again "Disk Usage Analyzer" aka baobab. Launchpad doesn't allow me to report said bug on the gnome-utils section. So where can i do that?
[01:17] <lemsx1|gone> pitti: if you login via ssh and kill gdm and the X processes, the machine hard-locks and you have to press the button to reset it
[01:17] <lemsx1|gone> john: try #ubuntu-bugs
[01:18] <cjwatson> pitti: should bug 71560 be milestoned for 7.04 final? even just some kind of "this crash will take a while to process - do you want to proceed" heuristic might help, if that's what it takes
[01:18] <ubotu> Malone bug 71560 in apport "Crash information collection depletes resources, clogs up and crashes system" [Medium,Confirmed]  https://launchpad.net/bugs/71560
[01:18] <john> thanks
[01:19] <pitti> cjwatson: it already has that jumping progress bar; it usually should take less than a minute, but for the guy in the last comment it took 40 minutes or so; I don't have an idea how to predict that
[01:20] <cjwatson> size of core dump?
[01:21] <pitti> cjwatson: I could just limit the core dump to, let's say, 500 MB; that should help already
[01:21] <pitti> cjwatson: but TBH I'm rather inclined to disable crash interception for the final release completely
[01:22] <pitti> we neither have the retracing nor the triaging capacity for the flood of crashes in feisty stable, nor will we fix most of the crasher bugs in stables
[01:22] <Keybuk> really?
[01:22] <cjwatson> mm, somebody asked about that on the QA call last night
[01:22] <Keybuk> I would strongly advocate having it enabled
[01:22] <pitti> and for high-prio bugs we can still ask users to enable it again locally
[01:22] <Keybuk> a friend has been much happier with feisty simply because apps don't just vanish, and she at least sees that dialog
[01:23] <Keybuk> (she nearly always clicks "No")
[01:23] <cjwatson> if it's easy to switch back on, I'd be in favour of disabling it by default
[01:23] <pitti> it's on today's meeting agenda
[01:23] <Keybuk> not to mention that sometimes you don't know there's been a crash
[01:23] <pitti> cjwatson: it's changing /etc/default/apport back to enabled ATM
[01:23] <cjwatson> I don't see why we can't say "an application crashed; do you want to do something about it?" without expensive core processing
[01:23] <pitti> in feisty+1 we might have automatic dup detection and better malone handling and all that
[01:24] <cjwatson> even in the typical case, what is it doing for that less-than-a-minute before it says "something crashed"?
[01:24] <pitti> cjwatson: would be theoretically possible
[01:25] <cjwatson> it should be SIGSEGV -> kernel writes core -> inotify -> dialog surey
[01:25] <cjwatson> surely
[01:25] <pitti> cjwatson: it reads the report and unpacks the core along with that; I know that this is suboptimal, but takes some invasive code changes to fix
[01:25] <pitti> oh, the 'less than a minute' I alluded to was the gdb/dpkg processing
[01:26] <pitti> for displaying the initial notification it just needs to read the file in /var/crash
[01:27] <pitti> this entire process could do with some optimization and some rewriting of the lower-level classes, but that's not something I would do for feisty final
[01:27] <cjwatson> perhaps a quick approach would be to simply notice that the file is there and (by default) display a notification before spending time reading it
[01:27] <cjwatson> presumably even just reading (and parsing?) it can be pretty slow and memory-intensive for large core dumps
[01:27] <pitti> right
[01:28] <pitti> but in that case I like the idea of limiting the core dump size better
[01:28] <pitti> if even merely writing/compressing the dump lasts 10 minutes on that user's machine
[01:28] <cjwatson> that would have the benefit of simplicity, although I'd have thought that 500MB is too big
[01:29] <pitti> since at that time we cannot really display any UI
[01:29] <cjwatson> can it be related heuristically to free memory available?
[01:29] <cjwatson> I suspect that in that user's case apport is running into swap trying to parse the crash dump and then the system starts thrashing
[01:29] <pitti> cjwatson: certainly, yes
[01:30] <cjwatson> and in that case, we're turning the situation from the random user's perspective from "it crashed. bugger. ok, restart it and worry about it later" to "it crashed. bugger. oh, now my system is unresponsive."
[01:30] <cjwatson> which is suboptimal :)
[01:30] <Keybuk> pitti: why does it need to "read" the file?
[01:30] <Keybuk> can't it just mmap it?
[01:31] <pitti> Keybuk: it's RFC822/base64 encoded
[01:31] <Keybuk> heh
[01:31] <pitti> however, due to the way we sort the fields, it would be enough to just read the top
[01:31] <pitti> Keybuk: but as I said, merely writing the crash report when the crash itself happens already triggers that trashing problem
[01:32] <Keybuk> sure, but at that point, they've clicked "Report Problem" so they're gonna expect some work
[01:32] <Keybuk> no?
[01:32] <cjwatson> it's three minutes from the crash to the initial dialog, not 10
[01:32] <Keybuk> the computer is visibly playing pong
[01:32] <pitti> Keybuk: no, when the crash happens, not when the UI pops up
[01:32] <Keybuk> why does it do it then?
[01:33] <cjwatson> oh, sorry, apparently nobody said it was 10 and I just misread something
[01:33] <pitti> Keybuk: it needs to turn the kernel's stdin into a compressed report in /var/crash
[01:34] <cjwatson> Keybuk: I think it's building it all in memory and then writing it out
[01:34] <pitti> so, I think from all the optimizations that would be possible, the only thing that would be reasonable for feisty is to cap the core size to the free memory
[01:34] <cjwatson> the core dump size limit would have to be in kernel_hook
[01:34] <pitti> right
[01:35] <cjwatson> can we notify the user that the crash happened, but that they didn't have enough free memory to deal with the crash?
[01:35] <cjwatson> at least for Keybuk's "you don't know there's been a crash" thing
[01:36] <pitti> cjwatson: yes, we could make the UI check for that case (no CoreDump in /var/crash/foo.crash)
[01:36] <cjwatson> perhaps a CoreDumpSuppressed key in the report or something, and then teach frontends to avoid filing bugs about that
[01:36] <cjwatson> can't just be lack-of-CoreDump because python crashes don't have that
[01:36] <cjwatson> CoreDumpTooBig
[01:37] <pitti> cjwatson: right, that's already taken care of; I meant lack of core dump for signal crashes
[01:37] <cjwatson> ok
[01:37] <cjwatson> so, going back, can I milestone this bug for 7.04 and summarise this conversation?
[01:37] <cjwatson> ah, you're doing it
[01:38] <cjwatson> thanks
[01:38] <pitti> thanks for the discussion
[01:41] <pitti> cjwatson: done; I'll file a separate bug about the optimization steps mentioned above (for feisty+1)
[01:57] <Keybuk> rofl
[02:21] <_ion> pitti: :-)
[02:26] <jwendell> any openoffice maintainer here?
[02:27] <Seveas> doko is :)
[02:31] <jwendell> doko, could you take a looh at bug 75478? It seems to be trivial to fix
[02:31] <ubotu> Malone bug 75478 in openoffice.org "No shortcut to OpenOffice::Draw" [Medium,Confirmed]  https://launchpad.net/bugs/75478
[02:33] <doko> jwendell: no, works as designed. https://wiki.ubuntu.com/MenusRevisited
[02:36] <jwendell> doko, i don't understand why we have shortcuts for calc, write, etc... but none for draw. That wiki page does not explain this
[02:41] <kwwii> my guess would be that nobody uses the paint program to draw pics except for those needed in  the other OO apps
[02:42] <sn-> my guess is as openoffice is a office clone, it acts similar to the way ms office used to
[02:43] <sn-> which i believe didn't have a seperate shortcut for the draw package, instead opened through whichever app you were using
[02:51] <lemsx1> hello all. just wanted to add that switching users works perfectly fine on Intel graphic cards
[02:51] <lemsx1> maybe the issue has something to do with ATI's and nvidia's only
[02:52] <jsgotangco> lemsx1: pretty much
[02:52] <pitti> lemsx1: it usually works for me as well, I just saw it once, ever
[02:52] <jsgotangco> pitti!
[02:52] <pitti> hi jsgotangco
[02:53] <pitti> seb128, carlos: there, fresh new feisty langpacks, candidate for an official upload; wanna test?
[02:53] <carlos> pitti: sure!
[02:54] <carlos> pitti: daily snapshot repositories?
[02:54] <seb128> without the french changes then? :/
[02:54] <pitti> carlos: yep
[02:54] <seb128> pitti: will test sure
[02:54] <carlos> seb128: no, sorry
[02:54] <pitti> seb128: -v ?
[02:54] <carlos> seb128: but I will try to get a new tarball with that for tomorrow, not sure whether pitti would be able to use that, though
[02:54] <pitti> seb128: I can mangle the french ones manually
[02:55] <seb128> pitti: GNOME translator complained that they work go to /dev/null so carlos is going to do some rosetta magic to use upstream translations when available
[02:55] <carlos> pitti: it depends on Rosetta export data
[02:55] <carlos> maybe we could delay the French one until tomorrow
[02:55] <pitti> seb128: ah, so it's not something I could fix by changing a couple of po files in the source?
[02:55] <pitti> carlos: we can also update the French one tomorrow again
[02:55] <seb128> pitti: no, it's "rosetta taking over nice translated with outdated broken ones"
[02:55] <seb128> pitti: ok, let's do that
[02:55] <seb128> update french again tomorrow
[02:55] <pitti> seb128: updating four packages won't hurt anyone tomorrow
[02:56] <pitti> seb128: and I'll update them again at least once, don't worry
[02:56] <seb128> pitti: ok, cool
[02:56] <carlos> ok
[02:57] <carlos> I will handle everything to get it done today
[02:58] <seb128> thank you
[03:03] <lemsx1> pitti: usually works but lately is not working? that used to work for me on Dapper/Edgy
[03:09] <izi_> pitti: i just uploaded a new patch for bug #97726 (you're martin right ?)
[03:09] <ubotu> Malone bug 97726 in restricted-manager "Restricted Drivers Manager's "computer restart" icon is not consistent with other restart icons" [Low,Confirmed]  https://launchpad.net/bugs/97726
[03:09] <pitti> izi_: splendid! thanks
[03:09] <pitti> izi_: yes, I am Martin Pitt
[03:09] <izi_> pitti, ok :)
[03:09] <_ion> (There's the 'whois' command in your IRC client, too. :-) )
[03:09] <izi_> sure
[03:56] <bddebian> Heya
[04:07] <_ion> benc: Any comments about the third patch? :-) I realized that i should have put the change_module_aliases script under debian/. Should i send a new patch to change its location?
[04:10] <mvo> Riddell: my modification to make the kde dist-upgrader use kde debconf seems to work. we just need to ensure that libqt-perl is installed (is that default?)
[04:11] <Hobbsee> mvo: it appears that...if a user upgrades while the proposed updates repository is enabled, they'll end up with an orphaned copy of app-install-data-commercial because edgy 6.3 > feisty 6
[04:11] <Hobbsee> mvo: known?
[04:11] <mvo> Hobbsee: no, good that you report it!
[04:12] <StevenK> It's still probably an issue because 6.2 is in edgy-updates
[04:13] <Hobbsee> mvo: right.  getting the original person to report it :)
[04:20] <Hobbsee> mvo: will you just bump the version number, or do you have other stuff to add?
[04:20] <Hobbsee> mvo: if it's just bumping the version number, i could probably do it, and give StevenK something to do with his new shiny upload powers
[04:20] <Hobbsee> (to give you time to focus on other, mroe complicated stuff)
[04:20] <Keybuk> Holy X Crash! Nvidia Man!
[05:12] <seb128> dholbach: do you know why Tango theme inherit on crystalsvg?
[05:12] <pitti> hey, it's not long any more until we will get the 100.000th bug report
[05:12] <dholbach> seb128: because that's the 'desktop independent thing' - you can use it in kde too
[05:12] <dholbach> so it can fall back to crystal
[05:12] <dholbach> (for them)
[05:14] <seb128> dholbach: it breaks the evolution icon
[05:14] <dholbach> oh?
[05:14] <dholbach> how so?
[05:14] <seb128> dholbach: upstream install its own to hicolor
[05:15] <seb128> and crystal is used before
[05:15] <seb128> so we get the crystal one on the Human theme
[05:15] <seb128> which is ugly
[05:15] <dholbach> if you have crystal installed
[05:15] <iwj> siretart: See my comment on bug 75681.  Aurelien managed to get some informative but unfortunately not sufficient debug info.  I've asked him and you for some more.
[05:15] <ubotu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Confirmed]  https://launchpad.net/bugs/75681
[05:15] <dholbach> seb128: hm, what do you suggest?
[05:16] <seb128> dholbach: get a nice evolution icon to Human or Tangerine? ;)
[05:16] <dholbach> seb128: ok, which icon is that?
[05:16] <seb128> evolution
[05:16] <tkamppeter> Anyone here who has a printer from HP?
[05:17] <seb128> tkamppeter: I've an HP deskjet
[05:17] <seb128> dholbach: dpkg -L evolution-common | grep icon
[05:17] <tkamppeter> If so, please go to bug 98520 and follow the steps in my "CALL FOR TESTING" (2nd posting).
[05:17] <ubotu> Malone bug 98520 in hplip "Feisty UVF ER: New HPLIP 1.7.3 release fixes lots of bugs" [Medium,Needs info]  https://launchpad.net/bugs/98520
[05:17] <seb128> ok
[05:18] <tkamppeter> seb128, thanks in advance.
[05:18] <tkamppeter> Any other volunteers?
[05:22] <siretart> iwj: sorry, I was on a buisness trip on monday and tuesday, and have managed to keep up with the mail backlog this morning. I'll test and provide the info this evening
[05:22] <siretart> I had to deal with a lawer regarding REVU as well, but at least he was pretty kind
[05:25] <siretart> iwj: you might be interested that since some weeks I don't obseve my raid devices coming up in degraded mode anymore (this was rather sporadic that time as well, though). what I'm rather observing is that only one of four raid devices "come up" automatically. `udevtrigger` does fix things for me however, and I can continue booting with CTRL-d
[05:26] <Hobbsee> siretart:  a lawyer regarding REVU?
[05:26] <Mithrandir> hiya Hobbsee 
[05:26] <Hobbsee> hey Mithrandir!!!!
[05:27] <siretart> Hobbsee: yes, someone uploaded a package with a cracked licence key inside
[05:27] <siretart> Hobbsee: they asked me to have it removed from revu + google cache
[05:28] <Hobbsee> siretart: fun.....
[05:28] <pitti> siretart: hm, maybe REVU should have a robots.txt
[05:29] <siretart> pitti: it does have now
[05:29] <jcapote> anyone know where i can get the gnome.applet module for python?
[05:29] <Hobbsee> siretart: that person now got banned from REVU?
[05:29] <siretart> Hobbsee: I'm still waiting for him to answer my email
[05:30] <lamont> pitti: is langpack stuff you or doko?
[05:30] <pitti> lamont: me
[05:30] <pitti> lamont: hello!
[05:30] <lamont> oo.o/ia64 is giving ia64 livecd fits
[05:30] <lamont> rather, the lack of oo.o binaries,  which get sucked in by task:ubuntu-desktop
[05:31] <pitti> lamont: I cannot parse that, sorry
[05:31] <lamont> task ubuntu-desktop pulls in oo.o pieces (lang pack depends on oo.o english help or some such??) and so the livecdfs build fails
[05:32] <doko> lamont: get a bigger CD ;-P
[05:32] <lamont> the longterm fix is to actually port oo.o to ia64, but the trampolines require someone with painfully intense knowledge of C++ vs C calling conventions, and assembly for the architecture in question...
[05:33] <lamont> The following packages have unmet dependencies:
[05:33] <lamont>   openoffice.org-help-en-us: Depends: openoffice.org-writer but it is not installable
[05:33] <lamont> actually.... WHY IN THE HELL DOES oo.o-help DEPEND on OO.O binaries?
[05:33] <lamont> doko: ^^???
[05:34] <doko> lamont: because you need -writer to get it working
[05:35] <lamont> vi doesn't work?
[05:35] <siretart> isn't the -help package just data?
[05:35] <doko> lamont: it's a db4.x database
[05:35] <lamont> dropping that depends would allow ia64 to have a livecd (without oo.o, mind  you)
[05:36] <lamont> and oo.o-writer is in task ubuntu-desktop itself, no?
[05:36] <siretart> I had the impression that it was common practice to have -data packages to recommend the 'base' package rather than depend in order to break circular dependencies
[05:36] <lamont> Task: ubuntu-desktop, kubuntu-desktop, edubuntu-desktop
[05:36] <pitti> Keybuk: wrt. apport core dump size limit, do you agree that MemFree+Cached-Writeback (in /proc/meminfo) is a reasonable size?
[05:37] <doko> siretart: but then people complain that help is broken, if -writer is not installed
[05:37] <lamont> siretart: oo.o-help-en-us isn't a dep of -writer
[05:37] <pitti> lamont: we could just drop language-support-en from the ia64 seed
[05:37] <lamont> that means making it and the oo.o-help packages arch-any instead of arch-all
[05:37] <lamont> otherwise the task install cataches them
[05:37] <lamont> catches, even
[05:38] <pitti> lamont: ah, true that
[05:38] <pitti> lamont: erm, it is already
[05:38] <siretart> doko: that's why there is the recommends. we have a spec to have 'Recommends' to be installed by default, after all
[05:38] <pitti> lamont: ubuntu-meta produces arch:any binaries for that reason
[05:39] <Keybuk> pitti: yeah
[05:39] <lamont> pitti: any arch_all package that is in Task ubuntu-desktop makes us lose
[05:39] <siretart> doko: if people are deliberatly not installing recommends, they shouldn't complain here, imo
[05:40] <lamont> rather, in task: ubuntu-live
[05:40] <lamont> see oo.o-h-e-us
[05:40] <Lutin> glatzor: ping
[05:42] <lamont> Mithrandir: any objections to me creating an oo.o-writer dummy package that is Arch: ia64?
[05:42] <lamont> iz big huge crowbar
[05:43] <doko> pitti: install language-support-xx doesn't create the C locales; wasn't this fixed sometime?
[05:43] <doko> lamont: the dummy package seems to be the best solution IMO
[05:43] <pitti> doko: urgh, no, seems to have slipped
[05:43] <lamont> doko: anything besides oo.o-writer that you know I need?
[05:44] <pitti> some java maybe?
[05:44] <cjwatson> Mithrandir,seb128,pitti: FYI, I'm reviewing the glassfish/glassfish-bin/netbeans/imq/sunwderby cluster in NEW - feel free to ignore it
[05:45] <pitti> ah, nice
[05:46] <cjwatson> I assumed it was sun-dub-ill-yew-dar-bee
[05:46] <cjwatson> or der-bee, I guess, since they're USian
[05:47] <doko> cjwatson: dholbach will happily assist ;-p
[05:48] <thom> ew, derby 
[05:49] <doko> lamont: need for what?
[05:49] <lamont> to satisfy other *^*^80 oo.o-$mumble  dependencies that are in my way. :0)
[05:52] <doko> lamont: I don't know of any other.
[05:59] <dholbach> doko: ?
[06:01] <iwj> siretart: Only one of four raid devices come up ?  Err, but surely you only need one to boot from.  Or do you mean one of the four components ?
[06:02] <iwj> siretart: Anyway, thanks for your effort to provide info.
[06:02] <Riddell> mvo: libqt-perl isn't default in edgy no
[06:10] <LaserJock> I need an archive admin, there's a problem with a broken SRU in edgy-updates
[06:12] <pitti> LaserJock: in the queue, or released?
[06:12] <LaserJock> released
[06:13] <pitti> LaserJock: how broken?
[06:13] <pitti> LaserJock: there's little that an archive admin can do, apart from waving through an updated package
[06:13] <LaserJock> well, as far as I can tell it's an archive issue
[06:13] <LaserJock> I did an SRU for python-imaging
[06:14] <LaserJock> but I got a couple reports of people not being able to upgrade
[06:14] <LaserJock> I *think* the issue is that one of the binaries moved from Universe to Main for feisty
[06:15] <Mithrandir> lamont: feel free.
[06:15] <Mithrandir> cjwatson: yay, thanks.
[06:15] <LaserJock> the bug reports I got so far are bug #96729 and bug #98550
[06:15] <ubotu> Malone bug 96729 in python-imaging "updating asks to install python-imaging which would break the system." [Undecided,Needs info]  https://launchpad.net/bugs/96729
[06:15] <ubotu> Malone bug 98550 in python-imaging "python-imaging-tk dependency problems in kubuntu-edgy" [Undecided,Unconfirmed]  https://launchpad.net/bugs/98550
[06:15] <pitti> LaserJock: hm, the package has always been in main
[06:16] <LaserJock> pitti: source package yes, but I think python-imaging-tk was in Universe for dapper/edgy
[06:16] <LaserJock> but it's in Main for Feisty
[06:17] <pitti> python-imaging-tk | 1.1.5-10build1 | edgy/universe | amd64, i386, ia64, powerpc, sparc
[06:17] <pitti> python-imaging-tk | 1.1.5-10ubuntu1 | edgy-updates/universe | amd64, i386, ia64, powerpc, sparc
[06:17] <pitti> python-imaging-tk | 1.1.5-10ubuntu1~prop1 | edgy-proposed/universe | amd64, i386, ia64, powerpc, sparc
[06:17] <lamont> openoffice.org-ia64-dummy_1.0_source.changes uploaded
[06:17] <pitti> LaserJock: it seems fine within edgy
[06:17] <LaserJock> ok
[06:18] <pitti> LaserJock: maybe broken apt-get or so? e. g. md5sum mismatch on edgy-updates/universe or so?
[06:19] <LaserJock> pitti: well, one guy was using dselect, the other looks like he was using aptitude
[06:20] <mvo> Riddell: hm, not ideal
[06:20] <pitti> $ dpkg -I python-imaging-tk_1.1.5-10ubuntu1_i386.deb|grep Depends:
[06:20] <pitti>  Depends: python-imaging (= 1.1.5-10ubuntu1), [...] 
[06:20] <pitti> hmm
[06:20] <pitti> LaserJock: apt-cache policy python-imaging-tk would be interesting to see from those guys
[06:21] <LaserJock> pitti: ohhhh, I think I found something
[06:21] <LaserJock> pitti: one of the guys has edgy-updates turned on for Main but not Universe
[06:21] <pitti> that would be it
[06:21] <mvo> Riddell: well, if libqt-perl is installed it will use the proper kde frontend now
[06:22] <LaserJock> pitti: phew, I thought I somehow busted Edgy
[06:22] <LaserJock> I did test installs/upgrades and rechecked the deps and I just couldn't figure out what was going on
[06:26] <bddebian> suuuuure ;-)
[06:29] <bddebian> :-(
[06:29] <LaserJock> yeah, you better be :-(
[06:29] <LaserJock> ;-)
[06:31] <bddebian> :) Hi poningru
[06:31] <poningru> yarr
[06:31] <bddebian> back in a bit..
[06:31] <bddebian> Freakin' meetings :-(
[06:32] <poningru> thesaltydog: where are you from?
[06:32] <thesaltydog> rome- italy
[06:32] <poningru> there is a local 'pub' here called ' the salty dog'
[06:32] <poningru> nm
[06:32] <thesaltydog> nm = New Mexico?
[06:32] <poningru> hehe never mind
[06:32] <poningru> but I am in gainesville florida
[06:33] <thesaltydog> gimme the wensite of that pub!
[06:33] <thesaltydog> s/wensite/website
[06:33] <poningru> not sure they have one
[06:33] <poningru> but let me look
[06:33] <poningru> its a hole in the wall where all the grad students go
[06:33] <poningru> dirty hole in the wall
[06:33] <thesaltydog> :-)
[06:34] <poningru> http://www.saltydogsaloon.com/
[06:34] <thesaltydog> thank you! bye
[06:34] <poningru> hehe cya
[06:45] <Lutin> glatzor: is there a reason to make webboard depend on python2.4 rather than 2.5 in feisty ?
[07:17] <Lure> Mithrandir: should this be milestoned for release - bug 91009?
[07:17] <ubotu> Malone bug 91009 in wireless-tools "wireless-tools / wireless extension version mismatch" [Undecided,Confirmed]  https://launchpad.net/bugs/91009
[07:19] <Mithrandir> Lure: quite possibly.
[07:19] <kwwii> dholbach: did you see https://launchpad.net/ubuntu/+source/human-icon-theme/+bug/96497
[07:19] <ubotu> Malone bug 96497 in human-icon-theme "Evolution icons are wrong" [Wishlist,Unconfirmed]  
[07:19] <kwwii> dholbach: I have absolutely no idea why it is looking/finding a file in crystalsvg
[07:20] <dholbach> kwwii: yes, that's cause because tango falls back to crystal and gnome
[07:20] <kwwii> I think that the problem is that before it used the "email" icon from tango
[07:20] <kwwii> ahhhh, now I get it
[07:20] <dholbach> it's the "desktop environment independent thing" of tango
[07:21] <dholbach> we'd probably need a nice icon in human or something
[07:21] <dholbach> that'd just fix it
[07:21] <dholbach> evo ships its own in hicolor
[07:21] <kwwii> dholbach: and which one is better/which one do we want to use?
[07:21] <dholbach> but normal icon themes are considered before hicolor
[07:21] <kwwii> the tango email icon seems to be the one we were using in edgy
[07:22] <kwwii> at least, that is the one that I saw
[07:22] <kwwii> well, I'll pick one and perhaps touch it up a bit and add it to the human theme
[07:22] <kwwii> dholbach: thanks for the info
[07:22] <dholbach> that's probably the easiest
[07:22] <dholbach> kwwii: i only know because seb128 asked me about it earlier already
[07:22] <kwwii> ;-)
[07:38] <carlos> pitti: I just started a new lang pack export with the French changes asked by seb
[08:01] <MisterN> hi. may i ask some question about SSP and its use in Ubuntu?
[08:01] <pitti> carlos: ah, great
[08:03] <MisterN> i'll just ask and see if i get ignored :D
[08:03] <MisterN> is stack-protector/SSP really necessary when you have NX?
[08:04] <kylem> most people don't have NX.
[08:05] <MisterN> well SSP is default on x86-64, too. there, all processors should have it. right?
[08:06] <kylem> istr no.
[08:07] <MisterN> "istr"?
[08:07] <kylem> i think a few revs of Pentium 4 with em64t are missing it.
[08:07] <kylem> 'i seem to recall'
[08:07] <MisterN> :/
[08:09] <keescook> MisterN: it's all about making things harder.
[08:09] <keescook> MisterN: without SSP, an attacker could still leverage an attack that doesn't execute the stack
[08:10] <keescook> MisterN: imagine them using code snippets from the running program to setup system calls via a long chain of stack return locations.
[08:10] <MisterN> the question is whether it is worth it
[08:11] <MisterN> but i understand that systems without NX need to be supported
[08:11] <keescook> I think it's worth it even with NX processors.  :)
[08:12] <MisterN> i was not so pleasantly surprised when i learned about an hour ago that all my programs are compiled with ssp enabled by default
[08:12] <Mithrandir> MisterN: why not?
[08:12] <MisterN> because that makes benchmarking my own programs harder
[08:13] <MisterN> i don't, for example, fear buffer overflow attacks in some obscure coding contest entry :)
[08:14] <Mithrandir> then use -fno-stack-protector.
[08:14] <wick2o> afternoon
[08:14] <MisterN> well i think that NX alone would be good enough. but as it's not portable...
[08:16] <keescook> MisterN: if you're curious about why SSP is still needed with NX, I recommend reading through http://www.suse.de/~krahmer/no-nx.pdf
[08:17] <MisterN> keescook: well the safest is just not having buffer overflows :)
[08:17] <Mithrandir> sure, and I would like to get rid of global warming too.
[08:18] <MisterN> well i suspect that my own code has any buffer overflows :)
[08:18] <LaserJock> Mithrandir: really? it's kinda chilly here right now ;-)
[08:21] <_ion> benc: Online? :-)
[08:22] <BenC> _ion: always :)
[08:22] <_ion> benc: Sorry to bug you, but is there something in the third patch i sent that i should fix?
[08:23] <BenC> _ion: Haven't looked yet, I think I'll get back to nvidia in a few hours
[08:23] <_ion> benc: Alright.
[08:23] <_ion> benc: I probably should have put the change_module_aliases under the debian directory.
[08:24] <_ion> s/under/script under/
[08:27] <mjg59> Hm. The lists.ubuntu.com archives don't seem to be updating?
[08:28] <pochu> they're laggy :)
[08:33] <mjg59> 3 days laggy?
[08:35] <carlos> pitti: do you have 5 minutes?
[08:39] <Adri2000> Mithrandir, doko: is it possible to fix MoM please? it's not been updated for ages...
[08:39] <Mithrandir> Adri2000: can you ask me during my workday, please?  Or just send me an email.
[08:40] <LaserJock> Adri2000: you need MoM output?
[08:40] <Adri2000> LaserJock: yes
[08:42] <Adri2000> Mithrandir: I already asked Keybuk a while ago, he said it was a problem with some debian mirror... so he should be aware of that, but I can send a mail if you want
[08:43] <Mithrandir> Adri2000: thanks.
[08:44] <david> anyone use gspca for webcam?
[08:46] <elmo> mjg59: yes, 3 days laggy.  pipermail is a hideous evil piece of crap
[08:47] <Mithrandir> david: yes, why?
[08:47] <elmo> the stupid thing has a 2.4Ghz opteron dedicated to just doing archiving and it can't keep up right now - we're look at options, but I'm probably going to disable ubuntu-bugs archiving soon
[08:47] <Mithrandir> fsvo use, at least.
[08:47] <david> I can't get the controls to work. driver works and I can see image.
[08:47] <Mithrandir> elmo: ouch; is it doing it on demand or out of cron?
[08:47] <david> in kopete the autobright option does nothing as the other bright,cnt,color ctls...
[08:47] <elmo> Mithrandir: it's a daemon
[08:48] <Mithrandir> elmo: you can try turning that off and just having it deliver to mboxes which you generate nightly or every four hours or something; pipermail supports that with just minimal changes.
[08:48] <Mithrandir> (until you switch to lurker or mhonarc or whatever)
[08:48] <elmo> Mithrandir: I don't want to break archiving for the entire site
[08:48] <elmo> and transitioning is non-trivial
[08:49] <Mithrandir> ok
[08:49] <david> the only control that works is the automatic color correction checkbox.
[08:51] <Mithrandir> david: let me see that mine still works; which tool are you using to capture?
[08:52] <david> kopete
[08:52] <david> or camorama
[08:57] <Mithrandir> the color/hue/white balance ones doesn't work for me, but constrast and brightness work just fine
[08:57] <Mithrandir> (using camorama)
[08:59] <david> can you tell me what your cat /sys/module/gspca/parameters/autoexpo show
[09:05] <glatzor> Lutin: No, I don't think so. I am surprised that it was actually used by somebody :)
[09:05] <david> Mithrandir: can you tell me what your cat /sys/module/gspca/parameters/autoexpo shows
[09:06] <Mithrandir> david: 1
[09:07] <glatzor> Lutin: I haven't found the time to look at for quite some time or release a later version - although there are many changes for it in my local bzr tree
[09:07] <david> Mithrandir: Do you know how to send params to the module?
[09:09] <Lutin> glatzor: ok, so it should work with python2.5 as is ? (look at bug #96842 and bug #844)
[09:09] <ubotu> Malone bug 96842 in webboard "[apport]  webboard-applet crashed with ImportError in <module>()" [Undecided,Confirmed]  https://launchpad.net/bugs/96842
[09:09] <ubotu> Malone bug 844 in rosetta "WordPress  export MO is not working (dup-of: 214)" [Medium,Fix released]  https://launchpad.net/bugs/844
[09:09] <ubotu> Malone bug 214 in rosetta "Getting system error while generating .mo file" [Medium,Fix released]  https://launchpad.net/bugs/214
[09:09] <Lutin> err bug #96844
[09:09] <ubotu> Malone bug 96844 in webboard "[apport]  webboard crashed with ImportError in <module>()" [Undecided,Confirmed]  https://launchpad.net/bugs/96844
[09:10] <Lutin> glatzor: this can be fix by either stick to python2.4 or moving to python2.5, so I wanted to know what you think is the best
[09:14] <Mithrandir> david: what do you want me to do?
[09:20] <david> Mithrandir: Just wanted to know if you knew how to send parms to the module. Sort of manual config the driver.
[09:20] <siretart> iwj: I hope https://beta.launchpad.net/ubuntu/+source/mdadm/+bug/75681/comments/79 contains all information you need
[09:20] <ubotu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Confirmed]  
[09:21] <iwj> siretart: Thanks must go have food talk to you later
[09:22] <siretart> iwj: enjoy your meal!
[09:23] <sladen> BenC: what was that commit you did a while back for i965 DRM?  I've just noticed that on this i915 I have no direct rendering rendering or Xv
[09:23] <Lutin> glatzor: still here ?
[09:24] <glatzor> Lutin: yes, had to make a phone call :)
[09:24] <glatzor> wait, I will look at those bugs
[09:25] <glatzor> Lutin: hm. I think I will reply tomorrow.
[09:25] <glatzor> You are subscribed to the bugs?
[09:25] <BenC> sladen: userspace or kernel side problem?
[09:27] <Lutin> glatzor: basically the bugs are caused by dependancies on python2.4 whereas it's executed with python2.5
[09:27] <sladen> BenC: should I expect to be seeing some mention of 'dri' or 'drm' in lsmod?
[09:27] <mjg59> Yes
[09:27] <glatzor> Lutin: basically there should be no reason against using python2.5
[09:28] <Lutin> glatzor: ok, cool
[09:29] <Lutin> glatzor: if you want to fix the package the package when you have some time, feel free to do it (and un-assign me ;) )
[09:31] <Lutin> glatzor: otherwise, just tell me and I'll fix it
[09:36] <pitti> carlos: pong
[09:36] <carlos> pitti: hi
[09:36] <carlos> pitti: did you see any error like with previous language packs related to the weird new line char?
[09:37] <pitti> carlos: not yet, but it's been a while since I saw such an error
[09:37] <carlos> I think you said it was in Feisty
[09:37] <pitti> right, maybe two weeks ago or so
[09:38] <carlos> pitti: would be helpful if you could try to reproduce it with new language packs
[09:38] <kwwii> pitti: just added a comment to bug #96510 , we are using the wrong icon in the menus for apport I think
[09:38] <ubotu> Malone bug 96510 in ubuntu-artwork "Report a problem icon doesn't match other icons" [Undecided,Unconfirmed]  https://launchpad.net/bugs/96510
[09:41] <pitti> carlos: I can just grep for those characters
[09:41] <pitti> kwwii: oh, thanks
[09:41] <carlos> pitti: don't worry, I can do it myself
[09:42] <kwwii> pitti: does that seem right to you?
[09:42] <kwwii> pitti: although sabdfl liked the one we are using now
[09:44] <pitti> kwwii: in fact, the icon in the context menu is not the apport one, but the stock gnome warning
[09:44] <kwwii> ;-)
[09:44] <pitti> kwwii: anyway, this is a bug against apport, so reassinging it with some guidance where I should change what is appreciated
[09:44] <kwwii> pitti: hrm, then let's wait to change it
[09:45] <pitti> kwwii: in today's meeting we'll discuss about entirely removing it from the final release anyway
[09:45] <kwwii> pitti: hehe, that would solve the problem very well indeed :-)
[09:46] <carlos> pitti: btw, The spanish language pack doesn't seem to be broken
[09:46] <carlos> good night!
[09:46] <MisterN> n8
[09:47] <pitti> bye carlos
[10:11] <Lutin> seb128: could you have a look to the debdiff attached to bug #92538 when you have some time ?
[10:11] <ubotu> Malone bug 92538 in libgpod "python-gpod should depend on python-eyed3" [Undecided,In progress]  https://launchpad.net/bugs/92538
[10:15] <seb128> Lutin: I'll have a look, not now though, I'm in the middle of a meeting
[10:18] <Lutin> seb128: ok, np. thanks
[10:23] <ajmitch> morning
[10:23] <dholbach> hi ajmitch
[10:29] <siretart> is bug #98739 for acpi-support or for the kernel?
[10:29] <ubotu> Malone bug 98739 in Ubuntu "Module acerhk is not loaded" [Undecided,Unconfirmed]  https://launchpad.net/bugs/98739
[10:29] <_ion> seb128: A couple months back, we had a short discussion about the compiz/beryl 'state' plugin allowing one to create rules that define the default brightness for various windows. Here's a screenshot that should demonstrate what it's good for: http://johan.kiviniemi.name/pictures/screenshots/beryl_per_window_brightness/original
[10:31] <seb128> _ion: either I'm using my windows and want them with a normal light or I'm watching a movie and not doing something else
[10:31] <seb128> that's doesn't look something we need
[10:31] <mjg59> siretart: Right now there's no good way to fix that
[10:31] <mjg59> It's certainly not an acpi-support issue
[10:33] <seb128> _ion: I get what it's doing though ;)
[10:33] <siretart> mjg59: oh? I thought acpi-support had some infrastructure to do notebook specific fixes
[10:34] <siretart> mjg59: actually, I told nobse to file that bug. the actual fix looks rather easy to me
[10:36] <mjg59> siretart: acpi-support handles acpi. acerhk bangs hardware directly.
[10:37] <siretart> mjg59: just to understand the issue, why is ibm-acpi loaded automatically on thinkpads?
[10:39] <mjg59> Because it can precisely determine whether something is a Thinkpad or not
[10:44] <sladen> siretart: the default of acerhk is to assume it Acer type XYZ.  Which is wrong.  The default should be to fail loading without a definite positive match
[10:45] <sladen> siretart: so it's not even possible to "try attempting to load acerhk regardlessly", as it'll just end up screwing the hardware
[10:56] <siretart> sladen: any idea how to have this fixed in the mid-term?
[10:57] <fabbione> Mithrandir: rm something is ok for who knows what to look for.. that's not disabling a service in a nice way..
[10:57] <Mithrandir> fabbione: people who have configured IPv6 statically are power users.
[10:58] <Mithrandir> if you want to provide patches which add IPv6 support to NM, please, but it's not a blocker in any way.
[10:58] <fabbione> Mithrandir: not necessarely..
[10:58] <fabbione> Mithrandir: it might not be a blocker.. it's still a regression.. 
[10:59] <Mithrandir> fabbione: I haven't said it's not a regression, I've said it's not something I care about for the release.
[11:00] <sladen> siretart: needs to be done in the kernel module, and have the module exit instead of default (actually a fairly small change)
[11:00] <Keybuk> we have hundreds of thousands of regressions every time we make a release
[11:00] <Keybuk> we only care about breaking those things we previously cared about
[11:00] <Keybuk> (ie supported)
[11:00] <Keybuk> we have never supported ipv6
[11:00] <fabbione> Keybuk: FYI: ipv6 is in main and therefor supported
[11:00] <Keybuk> (if we did, we would have high-level tools to configure it and use it!)
[11:00] <siretart> sladen: so this bug should be reassigned to the kernel, then?
[11:00] <fabbione> Mithrandir: right.. it's still a regression
[11:00] <Keybuk> fabbione: that means it's security supported
[11:01] <cjwatson> "regression" is something to pay attention to but it is not a big stick that trumps everything else. The release manager still has discretion
[11:01] <Keybuk> not that we care about it
[11:01] <sladen> siretart: yes, bit if you do that, can you mark it low-priority, it's not a regression in any way
[11:01] <fabbione> Keybuk: also.. if we were introducing that many regressions we wouldn't be here at the Nth release
[11:01] <Keybuk> see the number of bugs with launcher icon paths changing
[11:01] <sladen> *blink*
[11:02] <Mithrandir> fabbione: I feel like I'm repeating myself.  Yes, it's a regression.  No, it's not something which will be fixed for the release.  If you want to fix it, please send patches for it.
[11:02] <Mithrandir> and with that, I'm off to bed.
[11:03] <fabbione> Mithrandir: sure.. good night.. 
[11:03] <sladen> WONTFIX
[11:03] <maswan> fabbione: if you want to fix it, please look at my recent bugs on the trouble I've had in actually getting a statically configured ipv6 working. :)
[11:03] <cjwatson> wontfix is wrong
[11:03] <cjwatson> wontfix != not-for-this-release
[11:03] <Keybuk> fabbione: seriously, I'm sure NM upstream would welcome IPv6 patches
[11:04] <sladen> (I'm with Mithrandir on this one)
[11:04] <fabbione> maswan: i removed NM.. problem solved.. 
[11:04] <maswan> fabbione: I had a really hard time getting it to not autoconf on bootup
[11:04] <Lure> Mithrandir: it would make sense to make network-manager-gnome only Recommends (already done for kubuntu-desktop and knetworkmanager)
[11:05] <Lure> Mithrandir: this will allow removal
[11:05] <Mithrandir> Lure: yes, it would.  Feel free to fix.
[11:05] <Lure> Mithrandir: do not know how (Riddell does this for me in Kubuntu) ;-)
[11:06] <fabbione> maswan: i am talking about NM messing up my ipv6 setup... what are you talking about?
[11:06] <cjwatson> mm, I wasn wondering that earlier too
[11:06] <cjwatson> was
[11:06] <heno> tkamppeter: I posted a request for printer testing in the forums: http://www.ubuntuforums.org/showthread.php?t=396588
[11:06] <heno> quite a few feisty users there
[11:06] <maswan> fabbione: Oh, sorry, perhaps you don't read comments on your old bugs.
[11:06] <cjwatson> any core dev can do that by changing "network-manager-gnome" to "(network-manager-gnome)" in the ubuntu.feisty seeds
[11:06] <fabbione> maswan: give me a reference please :)
[11:06] <Keybuk> tkamppeter: random Q; HPLIP doesn't do anything for my HP printer, is that deliberate?
[11:06] <fabbione> maswan: i can't possibly remember everything
[11:07] <Keybuk> it's a HP LaserJet 1018
[11:07] <maswan> fabbione: I will, digging it up.
[11:09] <maswan> (... if only I can manage to navigate)
[11:10] <maswan> fabbione: https://launchpad.net/ubuntu/+bug/7091 is mostly what I was talking about
[11:10] <ubotu> Malone bug 7091 in Ubuntu "IPv6 module is not loaded early enough" [Low,Needs info]  
[11:11] <sladen> cjwatson: s/ \* network-manager-gnome/ * (network-manager-gnome)/ ?
[11:11] <fabbione> maswan: ehhe ok.. now i understand..
[11:12] <Keybuk> maswan: it's a bug that it's automatically loaded at all
[11:12] <Keybuk> it should be blacklisted by default until people want it
[11:12] <Keybuk> since it breaks nastily for people without ipv6
[11:13] <fabbione> Keybuk: no it breaks only for people with broken hardware
[11:13] <maswan> Keybuk: Oh? I've never had any problems with it though.
[11:13] <Keybuk> fabbione: which is most of the world
[11:13] <cjwatson> fabbione: considerably more people than those who actually use IPv6
[11:13] <Keybuk> cheap DSL routers that most people use can't do IPv6
[11:13] <Keybuk> and since there are only 2 goats that have a direct IPv6 connection, we care more about the real world
[11:14] <fabbione> Keybuk: cheap DL routers that don't follow RFC
[11:14] <fabbione> s/DL/DSL
[11:14] <fabbione> not even for ipv4
[11:14] <fabbione> that's why ipv6 break
[11:14] <Keybuk> who cares?
[11:14] <maswan> Keybuk: the ammounts of hits I get for updates via ipv6 says slightly more than 2 goats
[11:15] <maswan> but yeah, it's less than 10%
[11:15] <fabbione> Keybuk: we do.. given some recent movements towards IPv6 from some big fat govs
[11:15] <maswan> less than 1% I mean
[11:15] <Keybuk> we seriously don't
[11:15] <Keybuk> if someone pays us to do ipv6, we'll care
[11:15] <cjwatson> it doesn't seem at all inconceivable that we could avoid ipv6 being loaded for people without IPv6 addresses while still loading it for those who do
[11:15] <Keybuk> if someone joins core-dev and patches everything for ipv6, and fixes all the bugs, we'll care
[11:16] <fabbione> Keybuk: do you realize that 99.9% of the stuff in main already support ipv6?
[11:16] <cjwatson> I don't think "ipv6 loaded for everyone" is necessary to satisfy fabbione's requests
[11:16] <fabbione> cjwatson: no i don't need everybody to load ipv6 at all
[11:16] <Keybuk> fabbione: apparently a major feature of feisty doesn't support ipv6
[11:16] <maswan> cjwatson: Yeah. Like if I have typed in an inet6 section into interfaces.
[11:16] <Keybuk> and our resident ipv6 expert on staff doesn't appear to have fixed it
[11:16] <fabbione> Keybuk: it's not a matter that supports.. but that it break
[11:17] <cjwatson> maswan: right
[11:17] <fabbione> Keybuk: if NM didn't care.. i wouldn't have minded at all.. that it breaks a working setup.. then yes i do care
[11:17] <tormod> (didn't see the whole discussion, but) can NM - ipv6 trouble be related to bug #92299 (not only ipv6)?
[11:17] <cjwatson> do you care enough to fix it? :-)
[11:17] <ubotu> Malone bug 92299 in network-manager "network-manager breaks static configuration" [Undecided,Confirmed]  https://launchpad.net/bugs/92299
[11:17] <Keybuk> fabbione: fix it then :)
[11:18] <Keybuk> care = fix
[11:18] <fabbione> cjwatson: i don't care about NM because on a fixed workstation doesn't make any sense to me..
[11:18] <Keybuk> fabbione: you care about NM because it's part of our default installation
[11:18] <Keybuk> unless, of course, you don't care about our default installation?
[11:18] <maswan> Anyway, I'll poke around at these bugs that I've reported after feisty, I think caring about them _right now_ is a misdirection of effort.
[11:18] <cjwatson> fabbione: <fabbione> [...]  yes i do care
 i don't care
[11:18] <fabbione> Keybuk: the reason why i am arguing is because i do care of our default installation
[11:18] <Keybuk> fabbione: so fix NM then
[11:18] <Keybuk> care = fix
[11:18] <Keybuk> not bitch
[11:20] <fabbione> cjwatson: i said that i care because it breaks.. i don't care about NM as an application itself.. slightly different thing
[11:20] <fabbione> cjwatson: because i don't find it of any use on something != laptop
[11:21] <Keybuk> so you're saying that IPv6 isn't useful on a laptop? :p
[11:21] <fabbione> Keybuk: not yet no.. i am being realistic
[11:21] <cjwatson> so should the bugs about it be assigned to you or not?
[11:21] <cjwatson> (I'm assuming there is a bug about n-m vs. ipv6 - haven't looked)
[11:22] <fabbione> cjwatson: i filed it...
[11:22] <ubotu> Malone bug 93636 in network-manager "[regression]  breaks static ipv6 setup" [High,Unconfirmed]  https://launchpad.net/bugs/93636
[11:22] <cjwatson> bug 93636
[11:23] <cjwatson> fabbione: I think it would be appropriate to assign that bug to you. Do you disage??
[11:23] <cjwatson> er, disagree?
[11:24] <maswan> Some other day I can provide relative numbers on the ipv6 usage on the users that hit se.archive for package updates. But now sleep. :)
[11:24] <fabbione> cjwatson: i don't know NM code base.. you are welcome to reassign.. just no idea how to fix it
[11:25] <cjwatson> I'm sure somebody can help with that
[11:25] <pitti> cjwatson: 'disage' is an interesting concept, though
[11:25] <cjwatson> AFAIK there are no other core devs with the breadth of IPv6 experience you have
[11:25] <fabbione> cjwatson: probably not, who can i bitch about NM code base then?
[11:26] <neuralis> fabbione: if this is present in upstream, i can almost certainly get it fixed
[11:26] <Keybuk> upstream would be a good bet
[11:26] <Keybuk> they're GNOME guys, so they hang out on IRC and e-mail, etc.
[11:26] <pitti> cjwatson: I emailed upstream a while ago, and he was quite responsive
[11:26] <Keybuk> and are pretty responsive
[11:26] <Burgwork> fabbione: one of NMs upstream is currently on irc right now
[11:26] <pitti> erm, fabbione ^
[11:26] <pitti> cjwatson: sorry, wrong address; it's getting late...
[11:26] <fabbione> Keybuk: i am asking in our team.. not upstream :)
[11:26] <Keybuk> fabbione: you don't need help from somebody in our team
[11:26] <Keybuk> upstream will provide the help you need
[11:27] <fabbione> neuralis: i am pretty sure it's upstream too
[11:27] <Lure> Keybuk: not really if it is in debian backend (filtering out static interfaces)
[11:28] <Keybuk> Lure: they'd help him fix the backend
[11:28] <Keybuk> but I suspect the bug is more that it's tearing down configured IPv6 interfaces
[11:28] <Keybuk> which will be more internal than that
[11:33] <fabbione> it's actually only the backend
[11:33] <fabbione> it seems also pretty simple to fix
[11:33] <fabbione> given the way backends work
[11:38] <fabbione> cjwatson: bug #98764 looks to me like we are missing modules in the installer (ide*) ?
[11:38] <ubotu> Malone bug 98764 in Ubuntu "Installation of Feisty beta cannot detect disk drive on Gigabyte 965G-DS3" [Undecided,Unconfirmed]  https://launchpad.net/bugs/98764
[11:40] <fabbione> actually it might be another one of those jmcron thingy
[11:40] <cjwatson> fabbione: we're certainly not missing them or I'd have way more people screaming at me, but it probably can't detect his hardware
[11:40] <cjwatson> fabbione: I'll look at it tomorrow
[11:40] <fabbione> cjwatson: ok thanks
[11:40] <fabbione> BenC: ^^^ this might be your... 
[11:41] <BenC> fabbione: 70% possibility that bug is fixed by -13 kernel in repo, 99.9% possibility that it's fixed by current git
[11:42] <fabbione> BenC: ok.. i will ask cr3 to test a daily
[11:42] <BenC> fabbione: No chance of us missing modules for storage, since we just copy drivers/ata/ drivers/scsi/ and drivers/ide/ now
[11:43] <fabbione> BenC: yes.. there is a message from d-i that's misleading.. the modprobe happens a bunch of lines above that
[11:43] <fabbione> cjwatson: nevermind. that's definetely not for you
[11:44] <pitti> cjwatson: FYI, I implemented that heuristic coredump capping, testsuited and uploaded now
[11:45] <cjwatson> fabbione: ok, thanks
[11:45] <cjwatson> pitti: neat, thanks
[11:52] <tkamppeter> Keybuk: There are some HP printers which are not supported by HPLIP, especially the HP LaserJet 1000, 1005, 1018, 1020, Color LaserJet 1500, 2600n
[11:53] <tkamppeter> Keybuk, more are listed on http://hplip.sf.net/
[12:06] <firephoto> tepsipakki: I commented on bug 90213 and attached my xorg.log about those new intel drivers.
[12:06] <ubotu> Malone bug 90213 in xserver-xorg-video-i810-modesetting "xf86-video-intel 1.9.91 (2.0 RC1) is out, and would be nice to have as the source for the xserver-xorg-video-i810-modesetting package" [Undecided,Needs info]  https://launchpad.net/bugs/90213
[12:09] <tepsipakki> firephoto: oh, it was still using i2c debugging..
[12:09] <tepsipakki> I'll build a new one
[12:10] <firephoto> tepsipakki: ok. that explains all those messages then.
[12:10] <tepsipakki> yes, I needed those