[00:21] <psusi> so the usplash package has 239 open bugs.  It can no longer even be installed in Ubuntu because plymouth conflicts with it, and is required.  Shouldn't usplash then be dropped, and all bugs invalidated?
[00:21] <micahg> psusi: that's a devel decision, not a bugsquad decision
[00:22] <espen77> how do i make a patch for a source package?
[00:22] <psusi> which part is?  dropping it, or invalidating the bugs of a dropped package?
[00:22] <micahg> psusi: dropping it
[00:22] <psusi> ok.. so I should file a bug requesting that it be dropped, and if/when it is, then invalidate the bugs?
[00:23] <espen77> i already aptget source and fixed code
[00:23] <micahg> espen77: here's the process for getting a patch in Ubuntu: https://wiki.ubuntu.com/SponsorshipProcess
[00:23] <espen77> micahg: thanx
[00:24] <micahg> espen77: thank you for your pending contribution :)
[00:24] <micahg> psusi: yes, you can file a bug and subscribe ubuntu-sponsors to it
[00:25] <psusi> micahg, since it's a drop request, shouldn't it be ubuntu-archive instead?  or it needs sponsored first, then to archive?
[00:25] <micahg> psusi: a MOTU needs to ACK it
[00:25] <psusi> micahg, roger
[00:29] <espen77> isnt there a command to make a diff between .orig.tar.gz and unpacked directory?
[00:29] <micahg> espen77: care to hop in #ubuntu-motu to continue this?
[00:30] <espen77> oki, ty
[00:37] <psusi> when using the email interface to lp to change status or assignee, how do you specify which target you are talking about?
[00:38] <kklimonda> it may not be possible to do that, but ask on #launchpad :)
[00:38] <kklimonda> (the email interface could use some love)
[00:40] <micahg> psusi: https://help.launchpad.net/Bugs/EmailInterface
[00:43] <psusi> micahg, that's what I've been reading
=== AndrewMC is now known as SpockVulcan
=== SpockVulcan is now known as AndrewMC
[04:19] <micahg> psusi: you shouldn't just close all bugs against a package, they have to be evaluated if any qualify for an SRU
[04:20] <psusi> micahg, the package is dead.
[04:20] <micahg> psusi: that's irrelevant, we still have it in supported versions of Ubuntu
[04:21] <psusi> micahg, none of them will be fixed... the functionality the package provided was moved into the kernel years ago
[04:22] <psusi> the bugs were a mix of filed against wrong package, and should have been expired
[04:22] <psusi> mostly the latter
[04:22] <micahg> psusi: unless you've read all the bugs, you cannot know that, it's a community supported package in karmic on and in hardy it's in main which means it's canonical supported for another 2 months
[04:22] <micahg> psusi: filed against the wrong package means it needs to be triaged, not closed
[04:23] <psusi> I tried closing them out with a nice message explaining that and asking if any issues still persist, a new bug should be filed against linux instead, but slangasek said I should at least get the package removed from the archive first and reopened them.  I've since gotten it dropped from the archive and asked him if it was ok to close all the bugs now and he said yes
[04:29] <micahg> psusi: well, that's generally not how most bugs are handled, generally the only teams that do mass bug closure are the X and kernel teams
[04:29] <micahg> and even then, they'll just expire the bugs
[04:31] <psusi> micahg, my understanding is that a bug that does not apply to the current release should be closed, unless an SRU is warranted, in which case, a task against the old release should be opened... in this case, such tasks had not been opened, so no SRU was going to be done, so I closed out the tasks against the development release, since they do not apply since the package does not exist there
[04:31] <micahg> psusi: in this case, my guess is most of them weren't triaged, hence an SRU task couldn't be opened since no one new about it
[04:31] <micahg> *knew
[04:32] <psusi> probably because most of the bugs were unusable/junk ;)
[04:32] <micahg> Closing the task in the development release is fine if it's been triaged to the point where it's not an SRUable bug
[04:33] <micahg> most likely because most packages in universe don't have people watching after them
[04:33] <psusi> also if it hasn't managed to get triaged to the point where that can be determined within the 3 years since it was filed, I think
[04:33] <micahg> psusi: we don't close bugs because they're old, we can't fault the reporters for our lack of resources
[04:34] <psusi> a bug report that was filed long ago, and has never been duplicated/confirmed, and whose original reporter has wondered off and no longer applies to current releases does no good to keep open.. we don't fault reporters for lack of resources, but we don't need to keep open bugs that will never be fixed either
[04:35] <micahg> psusi: well, that's the question, is it SRUable or not, that's the only question to ask when reviewing those bugs, if not, close, if yes, triage fully
[04:37] <psusi> indeed... I tried to make such determinations last time I reviewed the bugs for that package a few months back... and tried to encorage the reporters to provdide more info to help finish triaging if possible... since that never panned out with any of them, it seems that now the correct thing to do is close them
[04:38] <psusi> if someone ever speaks up saying it is still an issue on an old but supported release, I can then figure out of it warrants an SRU or not
[04:40] <psusi> and if it does, open a task in that release
[04:41] <micahg> psusi: if you evaluated them before, that's fine
[04:42] <psusi> micahg, yea, I supose if I hand't evaluated them indivually before, then I would have set them to incomplete instead of invalid, adn let them either expire on their own, or evalute the responses
[04:43] <micahg> psusi: well, if you hadn't evaluated, mass incomplete is generally frowned upon as well except for the X and kernel teams
[04:44] <psusi> micahg, well, what else do you do with bugs against packages that don't exist any longer?  they certainly shouldn't remain valid against the development release
[04:44] <micahg> psusi: triage :)
[04:44] <psusi> micahg, nothing to triage against when the package no longer exists
[04:45] <lifeless> micahg: a bug on a gone package is invalid :)
[04:45] <micahg> lifeless: not if it's SRUable which what I was saying before
[04:45] <ScottK> lifeless: If it's in a supported release still I'd suggest wontfix.
[04:45] <lifeless> ScottK: fair point
[04:45] <micahg> psusi: in most of these cases, there aren't many bugs
[04:45] <psusi> lifeless, against the development release... it could still be valid against an older release, bug needs a task for that
[04:46] <psusi> and yes, likely would get set to wontfix in old release if removed from development
[04:46] <micahg> ScottK: weren't you the one who warned me against using won't fix unless I was sure?
[04:46] <ScottK> I don't think so.
[04:46] <psusi> the usplash package has 240 bugs in lp atm... going to get that purged next ;)
[04:47] <micahg> psusi: that's a different beast
[04:47] <psusi> micahg, how so?
[04:49] <lifeless> psusi: I think ScottK's point was wontfix in trunk
[04:49] <lifeless> psusi: and a task against older release could be $whatever-is-appropriate
[04:49] <micahg> psusi: it was a core part of Ubuntu, also is it just in natty it can't be used?
[04:50] <ScottK> Yes.  wontfix in trunk and just open a task against a release if you intend to SRU there.
[04:50] <psusi> ScottK, if trunk no longer exists?
[04:50] <ScottK> psusi: In that case trunk is a shorthand for "all supported releases".
[04:51] <psusi> micahg, package has been obsolete for years, has been dropped from the archive in natty
[04:51] <psusi> ScottK, I thought trunk always meant development release, and if it was different for previous supported releases, you opened a separate task to track there?
[04:52] <ScottK> psusi: Ubuntu bugs don't say they are against trunk, just that they are against "ubuntu"
[04:52] <ScottK> In theory, perhaps, but if the status is the same for all releases (not going to fix anything) it's a waste of effort and bombarding people's inboxes to try and do per release tasts.
[04:52] <psusi> ScottK, it can just say ubuntu, or it can say ubuntu(release)... my understanding is that just ubuntu meant development
[04:52] <ScottK> tasts/tasks
[04:53] <ScottK> psusi: It does, but how important is it really in a case where no SRU is intended?
[04:53] <psusi> ScottK, right... which is why you don't bother opening a task against the previous release and just set the trunk to invalid
[04:53] <ScottK> I think it's more important to work on fixing stuff than getting the state of the bug database exactly right.
[04:54] <ScottK> I've got better things to invest my time in than the merits of invalid/wontfix.
[04:55] <psusi> in other words, it is no longer valid in the trunk because the package has been removed, so that status becomes invalid.  If it is valid in a stable release, then a task should be opened for that and it should be fixed, or set to wontfix ( though if yuo know that, why bother opening the task )
[04:56] <micahg> psusi: yep, that sounds good
[04:58] <psusi> so I guess next time, I should batch invalidate only New bugs, and any that are confirmed/triaged, should take a look at and get a task opened in the supported release, even if it is set to wontfix
[05:00] <psusi> or better yet, incomplete rather than invalid
[05:02] <micahg> psusi: no, it's not worth going to incomplete, unless you think it's SRUable, and New bugs might have all the information necessary, the bugs should just be gone through to see if they meet the SRU criteria or not, the devel task should be invalid if the package is not in the archive, if you think it's SRUable, you can ask for a task to be opened and set that to incomplete if there's not enough info
=== tarun is now known as Guest86968
=== Guest86968 is now known as c2tarun
[06:50] <penalvch> Please mark Medium Importance for libreoffice bug 505188
[06:50] <ubot4> Launchpad bug 505188 in openoffice.org (Ubuntu) (and 2 other projects) "Impress mis-rotates text saving to .pptx (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/505188
[10:50] <game2> bug 662605 seems to have had a relapse, can someone here reset the status?
[10:50] <ubot4> Launchpad bug 662605 in unity (Ubuntu) (and 1 other project) "dash - wrong count of remaining items to see (affects: 2) (heat: 12)" [Low,Fix released] https://launchpad.net/bugs/662605
=== zyga is now known as zyga-food
[15:36] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 starting in 25 minutes in #ubuntu-classroom
=== zyga-food is now known as zyga
[16:09] <bdmurray> patrickmw: do you still have bug 727410 set up?
[16:09] <ubot4> Launchpad bug 727410 in gnome-session (Ubuntu Natty) (and 1 other project) "desktop UI does not load after logging as a fuse user via ltsp (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/727410
[16:12] <patrickmw> bdmurray: yes I do
[16:13] <bdmurray> patrickmw: maybe look at ~/.xsesssion-errors ?
[16:14] <bdmurray> patrickmw: also do you have a chance to choose your desktop environment? classic coke or new coke?
[16:15] <patrickmw> bdmurray: yes, let me try
[16:15] <bcurtiswx> classic or new coke... nice
[16:17] <patrickmw> bdmurray: hey hey, classic FTW
[16:19] <bdmurray> patrickmw: so note that and add the output of '/usr/lib/nux/unity_support_test -p'
[16:19] <patrickmw> bdmurray, will do, thanks!
[16:19] <bdmurray> patrickmw: actually it might just be a unity not start bug and unrelated to ltsp
[16:40] <CarlFK> I am trying to track down a bug report from over a year ago. bug is: "firewire express card not recognized when plugged in" (same for esata ec too)
[16:40] <CarlFK> I think it got fixed in jaunty, it is broken in maverick and natty
[16:41] <CarlFK> anyone know what package? would have been bugged?
[16:50] <bdmurray> patrickmw: have you used this test case before?
[16:51] <bdmurray> CarlFK: probably linux (the kernel)
[16:51] <CarlFK> bdmurray: I thought there was an "hp" (for hot plug) in the name
[16:53] <bdmurray> http://www.google.com/search?source=ig&hl=en&rlz=1G1GGLQ_ENUS330&q=site%3Abugs.launchpad.net+ubuntu+firewire+express+card+not+recognized&aq=f&aqi=&aql=&oq=
[16:54] <CarlFK>  "pciehp.pciehp_force=1"  yay!
[16:54] <CarlFK> bdmurray: thanks heaps
[16:54] <nigelb> bdmurray: hey, we have a session the day after tomorrow :)
[16:54] <CarlFK> pciehp is what I was trying to remember
[16:55] <nigelb> bdmurray: I'll probably prepare it some time tomorrow.  If you could take a look and help me with questions on friday, that'd be great :)
[16:55] <bdmurray> CarlFK: I don't see that in linux-source-2.6.38/Documentation/kernel-parameters.txt fwiw
[16:55] <CarlFK> bdmurray: grumble.
[16:55] <bdmurray> nigelb: of course also if you want me to review what you have I'm happy to do that
[16:56] <nigelb> bdmurray: I don't have anything yet.  Will write tomorrow daytime :)
[16:56] <nigelb> I'll probably just look at your old sessions which I used as starting points when I was writing a session
[16:56] <nigelb> s/session/hook
[16:57] <bdmurray> nigelb: another new launchpad feature worth mentioning would be the package bug reporting guidelines
[16:57] <nigelb> bdmurray: okay
[16:58] <bdmurray> nigelb: if you goto staging.bugs.launchpad.net/ubuntu/+source/xserver-xorg/+filebug and file a bug you'd see a good example
[16:59]  * nigelb does that
[16:59] <nigelb> bdmurray: is staging down?
[17:00] <bdmurray> nigelb: that works https://bugs.launchpad.net/ubuntu/+source/xorg/+filebug
[17:00] <bdmurray> you don't actually need to file it to see them
[17:01] <nigelb> oh, wow
[17:01] <nigelb> Neat feature
[17:01] <bdmurray> actually ubiquity is a better example
[17:03] <bdmurray> there is also a bug reported acknowledgement which appears after the bug report is filed
[17:03] <bdmurray> which is another way to convey information
[17:03] <nigelb> hrm :)
[17:05] <patrickmw> bdmurray: which test case?
[17:05] <bdmurray> patrickmw: ltsp and logging into a unity session
[17:06] <patrickmw> bdmurray: by used do you mean "successfully logged in"?
[17:07] <bdmurray> patrickmw: yes, have you ever logged in before and had unity running as an ltsp client?
[17:07] <patrickmw> bdmurray: not with unity
[17:07] <bdmurray> patrickmw: but unity runs in virtualbox fine?
[17:07] <patrickmw> yes
[17:08] <bdmurray> okay
[17:09] <patrickmw> bdmurray: you gave me an idea for something to try
[17:09] <patrickmw> bdmurray: standby :)
[17:13] <patrickmw> bdmurray: I installed the vbox guest additions to see if that would change anything.  It did not.
[17:14] <bdmurray> stgraber: do you think unity should work on an ltsp client?
[17:39] <charlie-tca> Reminder: QA meeting at 18:00 UTC in #ubuntu-quality
[17:55] <njin> Hello, can someone set bug 726008 to medium for me, thanks
[17:55] <ubot4> Launchpad bug 726008 in aptdaemon (Ubuntu) "<type 'exceptions.TypeError'>: enable_distro_comp() got multiple values for keyword argument 'component' (affects: 3) (dups: 2) (heat: 1766)" [Undecided,Confirmed] https://launchpad.net/bugs/726008
[17:58] <stgraber> bdmurray: nope, ltsp should use a classic gnome desktop, I thought didrocks fixed that
[17:59] <stgraber> bdmurray: with some specific hardware it "should" work (like full-intel hardware)
[18:00] <bdmurray> stgraber: okay, thanks for the help!
[18:07] <camelinahat> I'm a little confused.. I'm new to BugSquad and looking at the mentorship program. I can't see to figure out how to edit my Ubuntu-WikiPage (Or what should be on it once I have)
=== zyga is now known as zyga-afk
[18:28] <camelinahat> Is there anyone about who is comfortable with the ubuntu wiki able to assist me? I'm also getting weird errors when trying to update UserPreferences (e-mail is already in use)
[18:32] <yofel> camelinahat: for the wiki just go to the page that you want to be your new wiki page and click on the link to create it
[18:33] <camelinahat> yofel: I notice when I login it uses my launchpad.net userID should I use that as my wiki page or a more accurate WikiName?
[18:34] <yofel> I used my real name, but there's no rule on that, some people used their ID too
[18:34] <camelinahat> Any thoughts on why when I update my UserPreferences I'm getting an error that my e-mail address is already in use? (At no point do I even see an option for e-mail address)
[18:35] <yofel> what user preferences, the wiki ones?
[18:35] <camelinahat> Yep.
[18:35] <charlie-tca> since everything is tied to OpenID, it will use whatever email address you gave launchpad
[18:36] <camelinahat> charlie-tca: But the Launchpad one has no problem with my e-mail (no warnings/alerts that it's duplicated/already in use) only on the Wiki
[18:36] <charlie-tca> weird
[18:37] <yofel> camelinahat: just where do you try to set that? I can't find it in my wiki preferences
[18:38] <camelinahat> yofel: I added a Quick Link, (changed no other options), hit "save" and receive an alert near the top that says "This email already belongs to somebody else. Clear message"
[18:39] <yofel> ah, I have no quick links set
=== zyga-afk is now known as zyga
[19:31] <penalvch> Regarding bug 618024 the OP upgraded to Maverick OOo which fixed the problem, and it's fixed in LibreOffice PPA & Natty. This looks like Fixed Released w/ not SRU or Backportable response. What do you think?
[19:31] <ubot4> Launchpad bug 618024 in openoffice.org (Ubuntu) (and 1 other project) "[(U)OOo 3.2.1 Generated PDF-Files cannot be printed with Adobe Reader (affects: 1) (heat: 10)" [Undecided,Incomplete] https://launchpad.net/bugs/618024
[19:38] <CarlFK> http://dpaste.de/OeMm/  [ 2400.930093] Call Trace:[ 2400.930101]  [<ffffffff815befad>] schedule_timeout+0x26d/0x2e0
[19:40] <CarlFK> im bugging it - anyone want me to do anything before i reboot?
[19:40] <charlie-tca> right channel?
[19:40] <charlie-tca> Is it a bug that is filed?
[19:42] <CarlFK> charlie-tca: not yet... looking for the cli tool
[19:42] <CarlFK> apport-cli
[19:43] <CarlFK> "No pending crash reports."
[19:44] <charlie-tca> there is always https://help.ubuntu.com/community/ReportingBugs#Filing%20bugs%20at%20Launchpad.net
[19:44] <charlie-tca> file without apport
=== ogra is now known as Guest42737
=== Guest42737 is now known as ogra_
[21:41] <AndrewGee> Hi. I believe bug 728051 should be changed to wishlist importance. I have forwarded the bug upstream.
[21:41] <ubot4> Launchpad bug 728051 in quodlibet (Ubuntu) (and 1 other project) "Relocate files according to metadata (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/728051
[22:04] <CarlFK> bug 728033 -
[22:04] <ubot4> Launchpad bug 728033 in linux (Ubuntu) "firewire - "blocked for more than 120 seconds" (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/728033
[22:04] <CarlFK> whats the markup to make a ref to another bug?  #371434 didn't work.
[22:05] <yofel> literally 'bug 371434'
[22:05] <ubot4> Launchpad bug 371434 in linux (Ubuntu) "PCI ExpressCard hotplug requires pciehp.pciehp_force=1 (affects: 16) (dups: 3) (heat: 101)" [Undecided,Confirmed] https://launchpad.net/bugs/371434
[22:05] <CarlFK> thanks
[22:05] <yofel> # does nothing
[22:17] <CarlFK> natty install, pretty sure this is under 24 hours old: Mar  2 16:12:29 dhcp45 gnome-session[1543]: WARNING: Could not launch application 'libcanberra-login-sound.desktop': Unable to start application: Failed to execute child process "/usr/bin/canberra-gtk-play" (No such file or directory)
[22:18] <CarlFK> what package should I bug?
[22:18] <micahg> CarlFK: dpkg -S libcanberra-login-sound.desktop
[22:18] <CarlFK> thanks
[22:18] <seb128> CarlFK, it's a known bug
[22:19] <seb128> check the libcanberra open bugs if you want it
[22:19] <CarlFK> seb128: more thanks.  i'll ignore it then.
[22:36] <CarlFK> This preeseed line no longer works: d-i apt-setup/local1/repository string http://ppa.launchpad.net/carlfk/ppa/ubuntu natty main
[22:36] <CarlFK> known?  what do I bug?  did I stuff something up?
[22:37] <CarlFK> local0 line didn't get included either (only 2 I had in preeseed fiile)
[22:49] <javahorn> hi
[22:49] <javahorn> http://www.voria.org/forum/viewtopic.php?p=4409 -- this issue i am facing, what is the way out?
[23:02] <javahorn> hello..
[23:19] <javahorn> hello..
[23:24] <charlie-tca> javahorn: usually, you will get better responses to support in #ubuntu
[23:25] <javahorn> charlie-tca: they directed here!
[23:25] <javahorn> any idea for bug?
[23:25] <charlie-tca> Is there a bug filed?
[23:25] <javahorn> http://www.voria.org/forum/viewtopic.php?p=4409
[23:26] <charlie-tca> that is not an Ubuntu bug report
[23:26] <charlie-tca> file a bug using "ubuntu-bug linux" in a terminal, explain what is wrong, and let the developers see if they can fix it.
[23:28] <javahorn> charlie-tca: i am lost
[23:31] <charlie-tca> Ubuntu developers will not work on fixing something from a forum somewhere. They work on fixing bugs filed.
[23:31] <charlie-tca> The way to report the issue is to file a bug.
[23:31] <charlie-tca> That lets the developers know there is a problem, and they can work on it.
[23:32] <charlie-tca> You are giving a reference to someone's forum, and asking for a fix for it. It doesn't happen that way.
[23:41] <javahorn> charlie-tca: gmail account comes under OpenID?
[23:41] <charlie-tca> I don't know
[23:45] <javahorn> sorry i expected more support from ubuntu here or #ubuntu, my windows crashed and i came to ubuntu and no one seem that willing to help out!
[23:48] <chilicuil> hi there, what should I do if I want to fix some typos in po/ files?, in bug 725217 typos are in html & po files, the patch attached modify the html files but not the po/ ones, should I fix them as well, or is any other path I should follow?
[23:48] <ubot4> Launchpad bug 725217 in ubiquity-slideshow-ubuntu (Ubuntu) (and 2 other projects) "Typos in Edubuntu 11.04 slideshow (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/725217
[23:48] <charlie-tca> I am sorry you feel that way, but giving a forum reference and saying fix this, just is not a good way to look for help.
[23:49] <javahorn> charlie-tca: sorry, i did not know the norm here, i will file it
[23:49] <charlie-tca> chilicuil: not sure here. Might check with transations, #ubuntu-translations, I think it is, to make sure
[23:50] <charlie-tca> They deal with the po files, to the best of my knowledge
[23:51] <chilicuil> charlie-tca: I'll do it, thx
[23:51] <charlie-tca> javahorn: all of us are volunteers, both here and in #ubuntu. We just don't have the ability to drop everything to try and fix things
[23:52] <javahorn> charlie-tca: accepted, but seeing its prevalence i thought it will be easy go
[23:52] <charlie-tca> It is only prevalent if you own that machine. I never seen it before
[23:54] <javahorn> charlie-tca: to gain ubiquity(sounding bit same to ubuntu, at least first part), it has to run on all kinds of machine!