[01:37] <CarlFK> bug 254668
[01:38] <Hobbsee> Yes, that is a bug.
[01:38] <CarlFK> "Loading a custom DSDT should be fixed for Intrepid. So you just can give it a try."   http://launchpadlibrarian.net/17103921/DSDT.aml
[01:38] <CarlFK> what do I do with that file?
[01:38]  * Hobbsee looks
[01:41] <Hobbsee> CarlFK: i *think* the latter part of http://gaugusch.at/kernel.shtml should help you
[01:41] <Hobbsee> CarlFK: you won't need the first part of it, as that's the patch which they say should be fixed in intrepid
[01:52] <CarlFK> thanks - trying now
[02:09] <CarlFK> Hobbsee: I did the initrd-add-dsdt script, rebooted, and dmesg | grep "Looking for DSDT in initramfs"  doesn't show anything
[02:09] <CarlFK> any ideas?
[02:10] <Hobbsee> CarlFK: none, sorry.  i only found that much by looking on google
[02:10] <Hobbsee> CarlFK: smb was the guy who last responded to your question, though
[03:16]  * greg-g waves
[03:55] <Hobbsee> bug 259867
[04:21] <CarlFK> s/j #ubuntu+1
[04:21] <CarlFK> whoops.
[06:41] <dholbach> good morning
[06:48] <sbeattie> Hrm, once I upload crash info via apport, shouldn't it give me some sort of feedback as to whether it was successful or something?
[06:53] <sbeattie> No automatically opened web browser for me. Hrm.
[10:18] <XiXaQ> Can someone look at this report and tell me if I did it correctly? https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/261789
[15:58] <Ampelbein> hi! could some member of bug-control please check on bug #250540 ? I think it could be set to triaged. Regarding importance i would suggest low. Opinions?
[16:03] <pedro_> Ampelbein: looking
[16:03] <pedro_> Ampelbein: done, thanks you for helping ;-)
[16:04] <Ampelbein> thank you for looking into it.
[16:10] <bddebian> Boo
[17:08] <pwnguin> god
[17:09]  * pwnguin wonders if pedro is paid to mark bugs invalid
[17:11] <ogra> yes, we developers do a montly collection we transfer to his account ... want to participate ?
[17:12] <pwnguin> of course not :P
[17:42] <LaserJock> bdrung: bah, thanks for the matplotlib bug. I knew I was gonna forget something :(
[17:55] <pedro_> QA Team meeting at #ubuntu-meeting in 5 minutes
[17:56] <LaserJock> pedro_: thanks ;-)
[17:57] <pedro_> you're welcome :-)
[17:58] <tuxmaniac> Can someone set bug 257996 as wishlist?
[18:00] <pedro_> tuxmaniac: only if you can confirm it ;-)
[18:03] <LaserJock> bdrung: I don't understand why python-pkg-resources is needed for matplotlib, could you explain?
[18:07] <tuxmaniac> pedro_: I just had a closer look and it makes me think. It is a "feature request" actually and might not be accepted since 1/x is very much a user action. Do you think I should confirm and forward the feature request upstream?
[18:09] <LaserJock> tuxmaniac: for sure it should be sent upstream, not sure what the current workflow for those kinds of bugs is though
[18:10] <tuxmaniac> hmm
[18:12] <bdrung> LaserJock: Build the package without python-pkg-resources installed and then with python-pkg-resources installed. Compare the two build log and you will see, that python-enthought-traits is missing under "EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES"
[18:14] <LaserJock> bdrung: hmm, but would that mean that python-enthought-traits should be a depends?
[18:15] <bdrung> LaserJock: i am not 100% shure.
[18:16] <bdrung> LaserJock: we should contact upsteam and ask if it is ok to build the package with python-enthought-traits but do not install it by default.
[18:17] <LaserJock> bdrung: do you use matplotlib?
[18:17] <bdrung> yes
[18:17] <LaserJock> cool
[18:17] <LaserJock> I think contacting upstream would be a good idea
[18:18] <bdrung> LaserJock: i have to write an application and i use it for drawing ecgs
[18:18] <bdrung> s/have/had
[18:18] <LaserJock> it's not clear to me how optional python-enthought-traits is
[18:18] <bdrung> we should look through all depends/recommends/suggests and check / ask upstream if they are needed
[18:19] <bdrung> LaserJock: http://matplotlib.sourceforge.net/doc/html/users/installing.html
[18:19] <macd> There is an SRU bug a user keeps marking fix released, when it isnt. is there someone that can lock that status of a bug (like a qa person)
[18:19] <tuxmaniac> macd: bug number? May be we could tell him politely
[18:20] <LaserJock> bdrung: hmm, reading that it makes me think it should be removed altogether until upstream thinks it's usable
[18:20] <macd> bug 222804
[18:20] <macd> I think they're under the impression the bug was filed against intrepid not hardy.
[18:21] <macd> it should most likely be moved to hardy-backports as well
[18:21] <james_w> macd: it is Fixed Released
[18:21] <bdrung> LaserJock: what do you think about bug #246239? should we package matplotlib 0.91.4 or backport matplotlib?
[18:22] <james_w> macd: there's two statuses, one for Intrepid, one for Hardy, it is fixed in Intrepid, but not Hardy, and that's what it currently says.
[18:22] <macd> james_w, it shouldnt be, as its not ;)
[18:22] <macd> I cant see where its filed against intrepid, only the hardy milestone
[18:22] <macd> am I really reading it that wrong
[18:22] <tuxmaniac> I think the status is correct. the nominated release for hardy is still Confirmed
[18:23] <james_w> "fail2ban (Ubuntu) Fix Released " <- it is fixed in Intrepid
[18:23] <macd> I dont think it was ever broke in intrepid
[18:23] <james_w> "Hardy  Confirmed " <- still needs to be fixed in Hardy
[18:23] <macd> but ok :)
[18:23] <macd> thanks
[18:27] <LaserJock> bdrung: well, we aren't going to put 0.91.4 in hardy
[18:27] <LaserJock> bdrung: we can either try to fix that specific bug in an SRU or go for a backport
[18:28] <macd> so part of the bug process is taking bugs filed against one release, and when they dont get fixed by the next release go back and triage them for the release they were originally filed against
[18:28] <macd> that sounds odd, but Im on board ;)
[18:40] <LaserJock> bdrung: ok, I just chatted with Sandro
[18:41] <LaserJock> bdrung: he'd like to keep python-enthough-traits and will be adding python-pkg-resources to the Build-Depends in Debian
[18:41] <LaserJock> bdrung: as long has it stays in Suggests it doesn't hurt anybody
[18:42] <bdrung> bdrung: in which channel is sandro?
[18:42] <LaserJock> he's morph in #debian-python on OFTC
[18:46] <tuxmaniac> hi. bug 198173 seems to be fixed in Hardy itself and published in Intrepid. Can someone confirm its closure so that I can mark the bug "Fix released" . I confirm that bug is fixed from wahtever little testing I did on Hardy
[18:52] <LaserJock> bdrung: in the mean time I'm uploading your debdiff
[18:52] <LaserJock> bdrung: if we want to take out python-enthought-traits later we can, but we need to fix the wxgtk2.8 issue
[18:56] <LaserJock> tuxmaniac: yeah, close that
[18:56] <tuxmaniac> thanks for the added confirmation
[18:58] <LaserJock> tuxmaniac: well, I use it regularly and uploaded the fixed version to Ubuntu ;-)
[18:59] <tuxmaniac> LaserJock: I saw your name in the last upload and hence asked here knowing you will respond immediately ;-)
[19:09] <tuxmaniac> I was just wondering whether it is possible to make Launchpad automatically close bugs, that are fixed upstream (say in Debian) and it has been synced. The changelog will contain Closes #debbug. Hence the origianl LP bug remains open
[19:10] <LaserJock> tuxmaniac: I think if the Debian maintainer also puts the LP bug it'll work
[19:10] <tuxmaniac> LaserJock: yeah but is it too much to ask from the LP devels, to get a bug closed on LP once the sync is trhough and a linked debbug is closed?
[19:11]  * tuxmaniac may be stupid. :-(
[19:11] <LaserJock> no, that does make sense
[19:11] <LaserJock> I'm trying to think of any reasons why that'd cause problems
[19:12] <LaserJock> I can't think of any off the top of my head
[19:12] <LaserJock> tuxmaniac: maybe email bugsquad or ubuntu-qa about it?
[19:13] <tuxmaniac> LaserJock: yeah I will. thanks.
[19:17] <hggdh> tuxmaniac, as long as you accept not all of the bugs will be closed, it might work
[19:17] <hggdh> tuxmaniac, for example, there are usually LP bugs that do not refer to an upstream bug. No link, no closure
[19:18] <tuxmaniac> hggdh: no link, no closure :-) yes. thats normal
[19:18] <tuxmaniac> but if linked and still not closed after sync then I think we are unnecessarily having a few bugs open though they are closed
[19:18] <tuxmaniac> and we cant expect deb maintainers to put LP bugs in Closes
[19:18] <tuxmaniac> :-)
[19:18] <tuxmaniac> just a thought
[19:19] <hggdh> this is usually the Ubuntu packager's action (closed lp#, I mean)
[19:21] <hggdh> tuxmaniac, propose it on bugsquad and QA. It will get a wider discussion there, and it seems a good idea
[19:22] <pwnguin> well, its not closed in debian until an upload happens
[19:23] <pwnguin> oh, i read that wrong
[19:27] <LaserJock> the issue is that there's no real way to auto-close bugs via syncs
[19:28] <LaserJock> but we do want to make sure they 1) affect Ubuntu, 2) actually are fixed in Ubuntu
[19:28] <LaserJock> linking sets up a relationship with the bug, but I'm not exactly sure about 2)
[19:29] <LaserJock> Debian could fix a bug but something in Ubuntu could make the fix not work
[19:29] <pwnguin> what kind of bug would be in both a debian and ubuntu package, but not fixed by syncing them?
[19:30] <tuxmaniac> LaserJock: thats exactly what I am thinking. But I am unable to think a sample situation where this could happen
[19:30] <LaserJock> pwnguin: something that depends on other packages
[19:30] <LaserJock> for instance, say a bug was fixed in Debian, but with our gcc version the bug fix doesn't work
[19:31] <pwnguin> here's an idea: regression tests
[19:31] <pwnguin> im not sure if regression is the right word
[19:31] <LaserJock> on what and how?
[19:32] <pwnguin> provide a test to reproduce the bug and verify the bug exists, then we dont need human intervention to tell when it's fixed ;)
[19:32] <pwnguin> just human intervention to write the test in the first place...
[19:35] <pwnguin> if human interaction is nessecary, then perhaps use a tag; when the sync happens and there's a bug fixed in debian linked in LP, tag it for people to check. gives high signal
[19:37] <thekorn> bdmurray, thanks for the merge and the fix
[19:40] <pwnguin> i have a really fun bug
[19:41] <pwnguin> https://bugs.launchpad.net/ubuntu/+source/rrootage/+bug/261189
[20:00] <bdmurray> thekorn: no problem, I think that is the only api change needing a wrapper.  What do you think?
[20:45] <dupondje> any id when mysql will be fixxed ? :(
[20:47] <thekorn> bdmurray, yes, I agree
[20:49] <bdmurray> thekorn: okay, great
[20:50] <daradib> I have a question: if a new upstream application is available, but Debian has not packaged it yet, how should the bug be filed?
[20:51] <daradib> should universe sponsors be subscribed?
[20:52] <bdmurray> thekorn: What should we do about the Exceptions part of https://wiki.ubuntu.com/BugHelper/Dev/python-launchpad-bugs/changes_0.3
[20:55] <LaserJock> daradib: you mean the package is not in Debian yet?
[20:55] <daradib> the new version, yes
[20:55] <LaserJock> or just the newer version
[20:56] <daradib> just the newer version
[20:56] <daradib> a bug has been filed in Debian
[20:56] <LaserJock> ah, cool
[20:56] <LaserJock> daradib: you could file a bug, tag it "upgrade" and link to the Debian bug
[20:56] <daradib> ok
[20:56] <daradib> thanks
[20:57] <LaserJock> don't subscribe ubuntu-universe-sponsors until there's something for them to do, either approve a sync or upload a merge/new package
[20:57] <daradib> yes, that is what I was thinking
[20:57] <LaserJock> daradib: awesome, thanks for helping out
[20:58] <daradib> once Debian unstable packages the new version, I will edit the bug description to sync instead and add the sponsors, ok?
[20:58] <nullack> Folks Ive found a number of bugs with Intrepid's new 2.6.27 kernel. My testing has come to a stop though as I'm out of ideas for triaging a bug Ive encounted. Full explanation is here: http://ubuntuforums.org/showthread.php?t=902707
[20:58] <nullack> Any help would be appreciated to get me restesting on the new build
[20:59] <LaserJock> daradib: does the current package have an "ubuntu" version?
[20:59] <daradib> no
[20:59] <LaserJock> daradib: ok
[20:59] <daradib> LaserJock: thanks
[21:00] <LaserJock> daradib: if you make it a sync bug set the status back to New
[21:00] <daradib> LaserJock: ok
[21:00] <daradib> LaserJock: thanks for all the help and clarification
[21:01] <LaserJock> daradib: no problem
[21:07] <LaserJock> bdrung: I've extracted a patch from matplotlib SVN for bug #246239
[21:17] <thekorn> bdmurray, I would leave it unchanged, because it is still the "right" way to handle exceptions
[21:18] <thekorn> we can add a sentence saying that the old way is still supported, but that's al IMHO
[21:21] <bdmurray> thekorn: okay, I'll add a sentence along those lines then
[21:23] <thekorn> thank you
[22:14] <Ampelbein> hi! could some member of bug-control please have a look at bug #139595 ? I think it could be set to status triaged. The importance i think should be set to low.
[23:40] <greg-g> umm, I don't have the list of bugs for the hug day, but the email and UbuntuBugDay wiki page reference a non-existent webpage.
[23:41] <greg-g> bdmurray: ^
[23:42] <bdmurray> It looks like somebody has the month wrong
[23:42] <bdmurray> UbuntuBugDay/20080728
[23:43] <mrooney> does anyone think a linux hug day would be useful, due to the new kernel
[23:44] <bdmurray> mrooney: I think ogasawara has a plan for that already
[23:44] <mrooney> okay, cool
[23:45] <ogasawara> mrooney: yup, I'm gonna put out a call for testing to bug reports tomorrow
[23:45] <bdmurray> mrooney: hey you!  I wanted to ask you something last week. :)
[23:45] <mrooney> bdmurray: oh yeah?
[23:45] <greg-g> bdmurray: shall I rename the page
[23:46] <bdmurray> greg-g: that'd be great
[23:46] <mrooney> bdmurray: I also wanted to point out bug 224797 to you, I wasn't sure what to do about it
[23:46] <greg-g> bdmurray: just making sure you weren't on it
[23:46] <bdmurray> mrooney: Does the bug bot have any record of what he says?
[23:46] <mrooney> bdmurray: not-a-one, should it?
[23:47] <mrooney> is there something specific you want, someone in the channel may log their chats and have all of it
[23:47] <bdmurray> mrooney: It was quiet for 15 minutes last week sometime I was wondering what the longest pause between bugs was ... so it might be neat.
[23:47] <bdmurray> mrooney: Not as neat as the package regex's though! :-)
[23:48] <bdmurray> mrooney: oh, and I fixed lp_karma_suffix just for you
[23:48] <mrooney> well, since it transitioned to hggdh's generous hosting, it has been getting timeouts a bunch of times, so recently it has been announcing 2-3 at once
[23:48] <mrooney> so those aren't quite accurate in that sense
[23:48] <mrooney> and, thanks for that suffix fix :)
[23:49] <bdmurray> is it slow announcing or slow finding out about new bugs?
[23:51] <mrooney> slow at finding out, it seems to be getting http timeouts randomly on grabbing them
[23:52] <bdmurray> mrooney: hmmm, I bet it'd be faster at finding out in the Canonical data center. ;)
[23:52] <mrooney> bdmurray: yes please find hosting there! :D
[23:52] <mrooney> okay dinner time be back soon
[23:53] <bdmurray> mrooney: I can probably do that
[23:53] <bdmurray> or at least look into it
[23:53] <mrooney> hooray!
[23:57] <hggdh> mrooney, you did not see any reason yet for the timeouts?
[23:58]  * hggdh will sniff the connection to LP, but...
[23:58] <hggdh> it sounds more like a python thingie