[00:01] <mrooney> I am just wondering what the proper way to do it is
[00:01] <mrooney> ideally we could differentiate between versions of Ubuntu
[00:01] <mrooney> and say, mark it Invalid in Hardy and Confirmed in Intrepid
[00:02] <mrooney> that would be a slick way to handle these sorts of things near release
[00:03] <bdmurray> mrooney: by default the bug is considered to apply to the latest version of ubuntu and not a particular release
[00:03] <bdmurray> So just leaving it the way it is means it will apply to Intrepid
[00:06] <bdmurray> We could open a Hardy task and mark it "Won't Fix" but that could be considered busy work
[00:06] <crimsun> not to mention I realised several days ago that a Hardy task apparently implies hardy-{proposed,updates}
[00:07] <mrooney> bdmurray: yeah, but I mean for cases where the status is different for different versions
[00:08] <mrooney> ie a Won't Fix or Invalid for something in FeatureFreeze, but say Confirmed and Medium Importance for +1
[00:08] <mrooney> otherwise the status is deceptive at some point
[00:10] <bdmurray> Hmm, I think I see your point.
[04:00] <nabcore> Does anyone acx within ubuntu?
=== asac_ is now known as asac
[07:04]  * DOOM_NX good morning all
=== bdmurray changed the topic of #ubuntu-bugs to: Ubuntu BugSquad | http://wiki.ubuntu.com/BugSquad | Documentation: http://wiki.ubuntu.com/HelpingWithBugs | If you have been triaging bugs for a while, please apply to https://launchpad.net/~ubuntu-bugcontrol/ - http://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
=== doko_ is now known as doko
[10:06] <WarrenDum> hi
[10:06] <WarrenDum> someone knows if ther's progress on the kubuntu bug where gdebi-kde can't install any package/memory issue?
[10:11] <WarrenDum> Please: https://bugs.launchpad.net/ubuntu/+source/gdebi/+bug/153943
[10:11] <ubotu> Launchpad bug 153943 in gdebi "Gdebi-kde uses massive amounts of memory!" [Undecided,Confirmed]
[10:12] <WarrenDum> if this isn't fixed for hardy, it will create some problems
[10:20] <Tuv0k> W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/hardy-security/Release  Unable to find expected entry  web/binary-i386/Packages in Meta-index file (malformed Release file?)
[10:42] <WarrenDum> https://bugs.launchpad.net/ubuntu/+source/gdebi/+bug/153943
[10:42] <ubotu> Launchpad bug 153943 in gdebi "Gdebi-kde uses massive amounts of memory!" [Undecided,Confirmed]
[11:09] <afflux> morning
[11:12] <james_w> hi afflux
[12:23] <Iulian> Hey
[12:30] <james_w> hey Iulian, how are you?
[12:35] <Iulian> Hello james. I'm doing fine, thanks. And you?
[12:36] <james_w> I'm good thanks.
[12:36]  * Iulian is thinking to change his nick from Iulian to iulian.
[12:37] <james_w> why's that?
[12:37] <Iulian> A lot of people complains about it. They can't see the difference between I and l ;-)
[12:39] <Iulian> What do you think? Should I change it?
[12:43] <james_w> ah, it shows fine in my font.
[12:44]  * Iulian shrugs
[13:00] <pedro_> morning!
[13:03] <james_w> hi pedro_
[13:07] <Iulian> Hello pedro!
[13:09] <pedro_> hey hey! :-)
=== chuck_ is now known as zul
=== BjornT_ is now known as BjornT
[14:04] <effie_jayx> hey all... if a package fails to install due to the fact that dependencies won't be installed, does that make it a bug?
[14:04] <effie_jayx> or is it just a glitch in the development cycle. and I just wait for it to be fixed
[14:04] <james_w> effie_jayx: is there a bug on launchpad I could look at?
[14:05] <james_w> it can be either, sometimes you just need to wait a little, sometimes there's a real problem.
[14:05] <james_w> so there's a need to investigate
[14:06] <effie_jayx> james_w,  not actually. I have been trying to install virtualbox, and I find that it can't be installed but I am trying to learn if it is just a bug or that the packages it depends on are not build yet
[14:06] <effie_jayx> the error reads something like "The dependencies won't be installed"
[14:07] <james_w> effie_jayx: if you are on up to date hardy then there is a problem at the moment as the virtualbox kernel modules are not available for the latest hardy kernel.
[14:07] <james_w> that may be the problem, or something else.
[14:07] <_MMA_> Anyone know about /dev/vboxdrv not being created currently? I'm trying to see if this is a bug, or just a missing update for Hardy.
[14:08] <effie_jayx> james_w,  I am up to date, right. I saw the revision update yesterday. it seems like the dependencies are not built yet. I shall wait a day or two and see
[14:08] <effie_jayx> thanks
[14:09] <james_w> _MMA_: I think it's the issue that the kernel modules are not available yet
[14:09] <james_w> https://bugs.edge.launchpad.net/ubuntu/+source/virtualbox-ose/+bug/211351
[14:09] <ubotu> Launchpad bug 211351 in virtualbox-ose "virtual box packages need an update for kernel 2.6.24-14." [Undecided,Fix committed]
[14:10] <_MMA_> james_w: Ok. I thought most of that was sorted last night/this morning.
[14:10]  * _MMA_ looks.
[14:13] <_MMA_> james_w: Ok. I see. Thanx man.
[14:14] <james_w> no problem
[14:24] <qense> hello
[14:25] <james_w> hi qense
[14:45] <bddebian> Boo
[14:45] <qense> hello
[15:02] <qense> does anyone know what I should do with bug 186264 ?
[15:02] <ubotu> Launchpad bug 186264 in hal "keyboard randomly goes dead; takes a logout to restore functionality." [Undecided,Incomplete] https://launchpad.net/bugs/186264
[15:03] <qense> It has quite some logs attached but I don't know how to decide if the package is right.
[15:03] <qense> and of course it should be forwared upstream
[15:03] <qense> But is it complete enough?
[15:04] <prana> Would the list admin of ubuntu-bugsquad be willing to help get it imported into gmane? http://gmane.org/import.php
[15:05] <qense> I don't think so actually
[15:05] <qense> Ubuntu uses it own archive system
[15:06] <prana> qense: there are plenty of other ubuntu lists already archived on gmane.
[15:06] <qense> which lists?
[15:06] <prana> http://dir.gmane.org/search.php?match=ubuntu
[15:07] <prana> mirroring a list into gmane is very easy... you send them the mbox archive (which mailman keeps anyway) and then subscribe a special address @gmane.org to the list and it keeps everything up to date.
[15:08] <prana> you can then read lists via rss or nntp, which is super convenient.
[15:13] <qense> so it's basically a way to add more ways to read the maillist
[15:13] <prana> sure.
[15:14] <qense> ok
[15:14] <qense> I think I missunderstood you at first
[15:14] <qense> you could ask the admin, but I don't know who that is :)
[15:14] <prana> thanks... ;-)
[15:16] <qense> at this page you can find more information about the list: https://lists.ubuntu.com/mailman/listinfo/Ubuntu-bugsquad
[15:16] <qense> I think the maintainer of the list is at the bottom of the page
[15:21] <james_w> qense: yeah, I don't know what package that would be
[15:21] <james_w> I don't think it's been narrowed down enough to be sure.
[15:21] <james_w> is there any clues in the log (didn't bother to read them, sorry)
[15:21] <qense> I think it's a freedesktop package, but I'm not sure.
[15:22] <james_w> yeah, hal is freedesktop
[15:22] <qense> yes, but it could also be in X
[15:23] <prana> Is it worth continuing to update bugday topic pages after the fact?
[15:23] <prana> qense: thanks, just e-mailed the list owner.
[15:23] <qense> ok ;)
[15:24] <Pici> not again
[15:24] <qense> is it a bot?
[15:24] <Pici> !ops | _Czessi excess flooding
[15:24] <ubotu> _Czessi excess flooding: Help! Seveas, Hobbsee, gnomefreak, coleSLAW, or dholbach
[15:25] <Pici> LjL: -motu and #kubuntu too
[15:26] <james_w> prana: I don't think it's worth updating them.
[15:27] <james_w> qense: It could be X, perhaps the kernel, there's also a suggestion in the bug that it's g-s-d accessibility features.
[15:27] <qense> so it needs more triaging. But how?
[15:28] <qense> we could ask at #ubuntu-dev
[15:28] <james_w> qense: yeah, that's one option
[15:28] <james_w> I don't really know what else to ask for I'm afraid.
[15:29] <qense> ok, I'll ask them
[15:30] <qense> not again
[15:30] <qense> oh
[15:30] <qense> :)
[15:30] <qense> I was scrolled up
[15:30] <qense> and saw the czessi thing
[15:36] <james_w> :-)
[15:42] <prana> james_w: there ought to be a better way to track shared to-do lists than having to manually update the wiki after every action.
[15:42] <james_w> prana: yes, there should really
[15:44] <prana> james_w: is there some sort of moinmoin plug-in perhaps?
[15:45] <james_w> prana: there's something called editmoin
[15:45] <james_w> there's also something called hugday-tools that se
[15:45] <james_w> that uses editmoin to update the hug day pages for you
[15:48] <prana> james_w: ah, investigating.
[15:49]  * thekorn_ waves
[15:50] <james_w> hi thekorn
[15:50] <thekorn_> hey james_w
=== thekorn_ is now known as thekorn
[15:53] <prana> james_w: that's pretty cool; should definitely mention it on the hugday page b/c hunting down the right line and editing it manually is a pain!
[16:30] <bdmurray> Hello all!
[16:31] <thekorn> hello bdmurray
[16:32] <Iulian> Hi bdmurray, thekorn
[16:33] <thekorn> hi Iulian
[16:33] <bdmurray> prana: I'll take care of gmane and the mailing list
[16:34] <prana> bdmurray: cool thanks
[16:34] <bdmurray> prana: no problem, its a good idea. thank you!
[16:41] <bdmurray> yuriy: Have you seen bug 153943?
[16:41] <ubotu> Launchpad bug 153943 in gdebi "Gdebi-kde uses massive amounts of memory!" [Undecided,Confirmed] https://launchpad.net/bugs/153943
=== sdh_ is now known as sdh
[16:46] <afflux> morning bdmurray
[16:46] <bdmurray> hello afflux
[16:46] <prana> for a bug reported against gutsy that has a fix in hardy (due to updated upstream) ... mark as fix released?
[16:47] <bdmurray> prana: Yes, and mention the backport or SRU process where appropriate.
[16:47] <afflux> should a bug that existed in gutsy but is not reproducible in current hardy become fix released if we cannot find a specific version where it was fixed? (it just isn't there anymore)
[16:48] <bdmurray> I don't think it should be Fix Released if we don't know what the fix was.
[16:48] <afflux> so rather invalid?
[16:48] <prana> sorry, what's SRU?
[16:48] <afflux> stable release updates
[16:48] <afflux> prana: https://wiki.ubuntu.com/StableReleaseUpdates
[16:48] <bdmurray> Yes, that's what I use.
[16:50] <prana> looking at bug 211635, the hardy network manager has solved this problem, i think.
[16:50] <ubotu> Launchpad bug 211635 in network-manager "user-friendly way to delete stored ssid's" [Undecided,New] https://launchpad.net/bugs/211635
[16:52] <prana> i was going to indicate that Network Manager seems to now have the requested feature.
[16:54] <prana> i assume network manager is too tied into current gnome/hal/etc to ever be backported.
[16:57] <bdmurray> prana: probably, you check via rmadison to see if there are any backports for it.
[16:58] <prana> ah. could i use packages.ubuntu.com too?
[16:59] <prana> bdmurray: but either method would only show if a backport exists vs whether one is planned?
[16:59] <bdmurray> prana: Yes, it would only show if it existed.  I thought it might be a way of checking if a precedent for backporting it existed.
[17:00] <bdmurray> rmadison is handy command line utility for finding package versions across releases of ubuntu
[17:01] <prana> ah, cool.
[17:02] <bdmurray> You mentioned this bug is a feature request in which case it wouldn't be worth of an SRU>
[17:02]  * prana has been educated.
=== WarrenDum is now known as WarrenDumX
[17:51] <yuriy> bdmurray: yes, known bug
[17:51] <bdmurray> yuriy: It is a duplicate then?
[17:52] <yuriy> bdmurray: no, metabug
[18:24] <bdmurray> mrooney: there is a patch in bug 193617 for testing if you have time.
[18:24] <ubotu> Launchpad bug 193617 in gnome-power-manager "Hardy rhythmbox stops screen from blanking on laptop lid close" [High,Confirmed] https://launchpad.net/bugs/193617
[18:57] <pochu> does "wget https://launchpad.net/ubuntu/gutsy/+source/amule/2.1.3-3ubuntu1/+files/amule_2.1.3-3ubuntu1.dsc" work for someone in Hardy?
[18:57] <pochu> that's bug 74315, but reading the report it should work since edgy
[18:57] <bdmurray> pochu: works for me
[18:57] <ubotu> Launchpad bug 74315 in launchpad "wget https://launchpad.net fails with certificate error" [Undecided,Confirmed] https://launchpad.net/bugs/74315
[18:58] <pochu> bdmurray: ok, thanks
[18:58] <bdmurray> np should I comment on the bug?
[18:58] <seb128> wgeting sources from launchpad doesn't work for me
[18:58] <pochu> err, ca-certificates isn't installed...
[18:58] <pochu> seb128: do you have ca-certificates installed?
[18:58] <seb128> I face the issue often enough to know it's annoying
[18:59] <seb128> pochu: yes
[18:59] <pochu> ok
[18:59] <pochu> lol, works for me now after installing ca-certificates
[18:59] <pochu> seb128: ^
[18:59] <pochu> dget works now \o/
[19:00] <seb128> pochu: ah, I might get the issue only from my laptop, not sure now
[19:00] <Pici> aah
[19:21]  * broonie has a query regarding the followup on bug #207633
[19:21] <ubotu> Launchpad bug 207633 in dovecot "Fails with commented SSL configuration" [Undecided,Incomplete] https://launchpad.net/bugs/207633
[19:22] <bdmurray> broonie: what do you mean?
[19:23] <prana> which program generates the dialog box for password when you click on "Unlock" in an app like users-admin? is it users-admin itself?
[19:23] <bdmurray> policykit in Hardy
[19:25] <broonie_> bdmurray: I'm not entirely impressed with the response to the report; the person who followed up doesn't appear to have made any effort to look at the report at all.
[19:25] <bdmurray> prana: Actually the Unlock button only exists in Hardy
[19:26] <prana> bug 211805 is probably an easy fix (failure to parse gecos field after getpwent?) so just trying to figure out where the source file is.
[19:26] <ubotu> Launchpad bug 211805 in policykit "Username combo has 3 commas appended" [Undecided,New] https://launchpad.net/bugs/211805
[19:26] <bdmurray> broonie_: It seems like a vaild question to me as it isn't obvious which release and version of dovecot you noticed this with.
[19:26] <broonie_> bdmurray: Two problems. One is that Launchpad doesn't ask for this information. The other is that it is trivial to verify the report.
[19:28] <broonie_> If the response had been "I can't see this in version X, could you confirm which version you're using" it'd come over a bit differently.
[19:28] <bdmurray> broonie_: The guided bug filing instructions ask for information regarding the release and package version.
[19:28] <broonie_> I guess my query is if this is an expected response.
[19:30] <bdmurray> I don't think the response is ideal but is understandable given that we are very close to the Hardy release and people are quite busy getting it ready.
[19:31] <broonie_> Looking at the guided bug filing instructions they bury the request for the version in the second page of the report
[19:31] <broonie_> (for my browser config)
[19:32] <broonie_> I'd really expect to at least be able to pick the affected release in a dropdown (given that LP does actually record that info)
[19:34] <broonie_> Indeed, it looks like someone fixed the hardy package shortly after I reported the problem.
[19:37] <bdmurray> Okay, that's great.  Did you not see the guided the bug filing instructions or were they not clear for some reason?
[19:38] <broonie_> Didn't see them, they are well off-screen in my browser.
[19:52]  * broonie notes that the issue with not being prompted more obviously for version information is one of the earliest bugs against lp
[21:41] <stephantom> Hey there :-) If there's anyone familiar with gksu/kdesu or the su-to-root script, we could use a hand in https://bugs.launchpad.net/ubuntu/+bug/198884
[21:41] <ubotu> Launchpad bug 198884 in wireshark "Wireshark 0.99.7 halted in Hardy" [Undecided,Confirmed]
[21:59] <bdmurray> stephantom: does it hang or crash?
[22:09] <james_w> bdmurray: hang apparently, but that seems to be caused by a crash in an exec()ed program
[22:10] <bdmurray> james_w: How did you determine that?
[22:10] <james_w> bdmurray: there's an strace output attached
[22:10] <stephantom> bdmurray, it hangs
[22:11] <stephantom> there is also no output to the system log
[22:11] <bdmurray> james_w: which part of the strace though?
[22:11] <james_w> write(2, "21:46:19          Warn Unknown m"..., 15021:46:19          Warn Unknown message from dumpcap, try to show it as a string: capset(): Operation not permitted
[22:11] <james_w> capset(): Operation not permitted
[22:11] <james_w> ) = 150
[22:11] <james_w> wait4(-1,  <unfinished ...>
[22:11] <james_w> bdmurray: the end, always a good place to start :-)
[22:12] <james_w> it's hanging in a wait4 call, which I think means it's waiting for the termination of a child.
[22:12] <james_w> the message above may have something to do with the reason that it is not getting what it wants.
[22:12] <bdmurray> Okay, I was looking at the same stuff.
[22:13] <stephantom> the funny thing is that this does not happen if you call it through plain old console sudo
[22:14] <james_w> that's probably the vital clue
[22:14] <james_w> "capset(): Operation not permitted" suggests gksudo isn't granting you all the rights that you need, but I don't know why that would be
[22:14] <bdmurray> I was looking at the gksu changelog and didn't see anything that jumped out at me
[22:15] <james_w> I was under the impression that gksudo and sudo got you root permissions the same way.
=== wolfger_ is now known as wolfger
[22:17] <stephantom> I'll try downgrading the gksu package, maybe I can isolate it to a specific version
[22:18] <bdmurray> I might make sense to look in debian's bug tracker too
[22:18] <crimsun> stephantom: does passing -S or -w or gksu affect it?
[22:18] <bdmurray> incidentally I tired kdesu wireshark and i was able to capture packets
[22:18] <crimsun> sorry, that should be "-S or -w to gksu"
[22:19] <stephantom> crimsun, no it does not make a difference
[22:20] <james_w> bdmurray: that's interesting.
[22:21] <james_w> bdmurray: probably enough to make it worth reassigning
[22:22] <stephantom> downgrading to the gutsy versions of libgksu2 and gksu did nothing for me
[22:23] <crimsun> stephantom: is the environment cleared?  i.e., see gksu -k
[22:23] <james_w> stephantom: thanks. I don't see anyone saying this is a regression from gutsy, is that the case?
[22:23] <stephantom> james_w, nope ircc this was no problem in gutsy
[22:24] <james_w> stephantom: ok, so that suggests it's not entirely gksu's fault if the gutsy versions don't work in hardy.
[22:24] <stephantom> crimsun, I unchecked "preserve environment" now, but that doesn't change anything either
[22:25] <crimsun> right
[22:32] <james_w> stephantom: is there any terminal output when you run it under gksudo?
[22:32] <stephantom> james_w, no. nothing.
[22:32] <james_w> does wireshark have a log file?
[22:33] <james_w> write(2, "21:46:19          Warn Unknown m"
[22:33] <james_w> that makes it look like it does, I'd be interested in seeing the file.
[22:36] <stephantom> not according to the manpage, as far as I can tell, but I'll look into it
[22:37] <james_w> I do have wireshark installed actually
[22:37] <james_w> after the meeting I'm in I'll fire it up
[22:41] <crimsun> ok, looking in dumpcap.c
[22:45] <crimsun> yeah, I can reproduce it locally
[22:45] <crimsun> b43 [BCM94311MCG wlan mini-PCI (rev 01)]
[22:46] <crimsun> interestingly, the child is "/usr/bin/dumpcap -S -M"
[22:52] <crimsun> ok, so what's happening is that when invoked with gksu, the dumpcap child process is only invoked as the above command
[22:52] <crimsun> ("/usr/bin/dumpcap -S -M")
[22:52] <crimsun> when invoked with sudo, the dumpcap child process is invoked with the appropriate interface passed as a parameter
[22:52] <james_w> wow, 60 line comment about privilege handling.
[22:52] <crimsun> ("/usr/bin/dumpcap -i wlan0 -Z none")
[22:52] <james_w> crimsun: nice work.
[22:52] <stephantom> nicely done
[22:55] <stephantom> this might be the corresponding upstream bug: http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1740
[22:56] <ubotu> bugs.wireshark.org bug 1740 in Wireshark "window "capture->Interfaces" cannot be closed" [Minor,New]
[22:59] <stephantom> well, not excatly the same thing, but I guess the reasons for this happening are the same
[22:59] <crimsun> ok, let's enable Glib debugging
[23:24] <stephantom> actually, which each failed try, I leave a stray instance of dumpcap behind that is not terminated. much like the upstream report says.
[23:25] <james_w> there's an upstream report?
[23:25] <stephantom> I think http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1740 could at least be related
[23:25] <ubotu> bugs.wireshark.org bug 1740 in Wireshark "window "capture->Interfaces" cannot be closed" [Minor,New]
[23:26] <stephantom> but this one hasn't been touched since september
[23:26] <stephantom> which is a bit long for such a major showstopper
[23:26] <james_w> and if you kill that dumpcap instance what happens?
[23:28] <stephantom> james_w, the capture starts :-)
[23:29] <james_w> woo :-)
[23:29] <stephantom> so, the way I see it, the problem is that dumpcap does not terminate, which is what the 'Interfaces' window is expecting before it closes.
[23:29] <stephantom> dumpcap does not terminate, so the whole thing hangs
[23:31] <james_w> so the problem seems to be that if cap_set_proc fails dumpcap doesn't exit.
[23:32] <james_w> though there is another issue that under gksudo you don't have permissions to capset().
[23:32] <james_w> and we need to fix the latter to have wireshark be useful, but the latter is a problem that should be fixed at some point as well.
[23:59] <secretlondon> james_w, I've used wireshark since sept, only problem was that capture files were set with root only read perms
[23:59] <stephantom> secretlondon, under GNOME or KDE?
[23:59] <james_w> hi secretlondon
[23:59] <james_w> that's odd