[02:30] <nullack> ping hggdh
[02:33] <hggdh> nullack, pong
[03:16] <greg-g> bdmurray: do you have a list of all the wiki pages you need to update for each new Hug Day?  I've come across a couple so far during my w.u.c/Bugs review
[03:39] <jesseboi> Anyone know if this bug should be closed?  https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/269656
[03:41] <RAOF> jesseboi: I'd suggest against it.
[03:41] <jesseboi> Too early?
[03:42] <jesseboi> I mean it does seem like a moot point now doesn't it?:  http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/120b0b6241b74538
[03:53] <bcurtiswx> that is a good point for closing that bug... but i think you'll have to wait until its implemented and set as fix released
[03:54] <bcurtiswx> but maybe post that link and set as Fix Committed?

[03:56] <jesseboi> On second thought though...  they say "Open source version of FF".  So I'm not sure if they mean the unbranded version (IceWeasel) or what?  Is there a Closed Source version of Firefox?
[03:57] <bcurtiswx> i've always thought FF was open source to Ubuntu (hence why its in ubuntu)
[03:57] <bcurtiswx> would break ubuntu promise if it wasn't IMO
[03:59] <jesseboi> It just seems like they've got their words mixed up.  I guess clarity should be sought.
[03:59] <bcurtiswx> agreed
[03:59] <bcurtiswx> sleep time for me
[03:59] <bcurtiswx> nite room
[04:00] <jesseboi> nite!
[04:09] <bdmurray> greg-g: just in my head - bugsquad header, desktop team header and bugday
[04:13] <greg-g> bdmurray: cool, just making sure/wondering if you wanted one :)
[04:14] <bdmurray> greg-g: what are you reviewing?
[04:15] <greg-g> the changes jorge/pedro made
[04:15] <greg-g> pedro sent me an email asking for a review/look over
[04:17] <greg-g> bdmurray: I emailed jorge/pedro my comments.  Really just one (it was for the Fixing Bugs page, suggested possibly adding a suggestion to look at other bug tackers, especially upstream, for work in progress)
[04:17] <bdmurray> greg-g: cool, isn't it pretty? ;)
[04:18] <greg-g> very, the new images really make a difference :)
[04:18] <nullack> ping bdmurray
[04:18] <bdmurray> nullack: hi
[04:19] <nullack> bdmurray : evening for you, we can talk later
[06:06]  * Hobbsee wonders who exactly sent out the hug day mail this time.
[06:20] <nellery> Hobbsee, that would be Dereck (Awsoonn) as always
[06:21] <Hobbsee> nellery: ahh, i'd not seen the irc nick conversion, thanks.
[06:21] <Hobbsee> nellery: can i strangle him?  :)
[06:21] <nellery> Hobbsee: heh, why?
[06:21] <Hobbsee> nellery: well, i don't particularly appreciate attempts to get around email filters.
[06:22] <Hobbsee> i have filters for a reason - for whatever reason, i don't want to read the mail.
[06:22] <Hobbsee> why then, must they attempt to get around it?
[06:23] <nellery> was it the topic?
[06:23] <Hobbsee> Fellow Ubuntu Lovers!
[06:23] <Hobbsee> Its me again, giving your spam filters the slip, and you know what that
[06:23] <Hobbsee> means, this week's HUG DAY!
[06:24] <Hobbsee> yeah, they changed the topic, so it wasn't the usual "[B|H]ug Day: <topic>" subject line.
[06:24] <greg-g> I'm not sure if Dereck has ever used that as his standard topic
[06:25]  * Hobbsee is fairly sure that it has been like that, as she's not recieved the mails every month, for a few months now.
[06:26] <nellery> I think before it was just "Hug Day!!"
[06:26] <greg-g> ah, his last few were "Hug Day!!"
[06:26] <techno_freak> subject was "Hug Day!!" most of the time
[06:26] <nellery> HA!
[06:26] <greg-g> heh
[06:26] <nellery> would adding a * to the beginning of the filter work?
[06:27] <Hobbsee> nellery: well, i was matching on ?ug Day, which worked.
[06:27] <Hobbsee> nellery: yes, it should work.  i'm just trying not to filter more widely than i have to
[06:27] <greg-g> Hobbsee: but what about Rug Day? You're going to miss Rug day! ;)
[06:28] <Hobbsee> although i'm now trying to filter on any X-Launchpad* header, which i seem to have failed about again
[06:28] <Hobbsee> greg-g: oh dear :P
[06:28] <Hobbsee> greg-g: i'm sure it'll be mentioned on irc.  I don't need 5 mails telling me about it :)
[06:28] <nellery> it would probably be 3 ;)
[06:28] <Hobbsee> i used to often get more than 3.
[06:28] <Hobbsee> i'd get k-devel, u-motu, u-devel, u-d-a, and u-bugs, at least.
[06:29] <nellery> yea, it's been narrowed down to -users, -devel-annouce, -bugsquad, and -news-team
[06:29] <greg-g> Hobbsee: the mailing list list is good now, right?
[06:29] <Hobbsee> greg-g: for the most part, i don't see it :)
[06:29] <Hobbsee> greg-g: i've had 1 mail so far, and the other will be in u-d-a queue.
[06:29]  * persia doesn't see any value whatsoever in sending to all of u-m u-d-a, and u-d.  Anyone subscribed to u-m and u-d ought also be subscribed to u-d-a
[06:30] <Hobbsee> persia: you'd have thought so.
[06:30] <Hobbsee> nellery: that's much better.
[06:30]  * persia wants nested inheritance for mailing list subscriptions to enforce that
[06:30] <Hobbsee> persia: now *that* would be cool.
[06:32] <persia> Hobbsee: Indeed.  Something like (((u-d-a) u-d) u-m) and (((u-d-a) u-qa) u-b) would be two I'd like to see, just as a start.
[06:32] <Hobbsee> persia: yeah...
[06:32] <persia> Probably also (((u-d-a) u-d) u-d-d)
[06:32] <persia> Hobbsee: So, you're good with list management software, right?
[06:33] <Hobbsee> persia: well, i can use listadmin :P
[06:33] <persia> Cool, so you can set this up, right?
[06:33]  * Hobbsee hmmm.
[06:33] <Hobbsee> does mailman even support that currently?
[06:34] <persia> No idea.  I avoid reading mail, let alone administering it
[06:35] <Hobbsee> i've not seen a setting for it
[06:35] <Hobbsee> but mailman is somewhat like launchpad.
[06:35] <persia> You could add one :)
[06:35] <Hobbsee> full of options, but totally difficult to remember where each option is, or navigate it in a logical sense.
[08:11] <\sh> morning
[08:12]  * thekorn hands \sh some gummi bears and chocolate
[08:12] <thekorn> hi \sh ;)
[08:13] <\sh> nullack: please don't touch assigned bugs (especially when they are already in progress) anymore...don't nominate development releases on bugs, because development releases are the main tracked one..if the bug report deals also with a problem occuring on other releases, nominate those
[08:13] <\sh> nullack: furthermore, please update the bugsquad documentation accordingly...so I don't have to come around and complain again...
[08:14] <\sh> nullack: thank you for your cooperation...kind regards, \sh :)
[08:18] <Hobbsee> speaking of assigned bugs...i s hould do that dput merge.
[08:19] <nullack> \sh Which assigned bugs are you referring too?
[08:20] <\sh> nullack: bug #246911
[08:21] <nullack> \sh I dont see what the issue with nominating for release is
[08:21] <nullack> \sh I spoke with Brian about it, it was accepted the process isnt ideal
[08:22] <Hobbsee> nullack: everything you do causes another mail.
[08:22] <nullack> I dont consider that an issue
[08:23] <Hobbsee> well, that's probably part of your problem.
[08:23] <\sh> nullack: the process is totally crap...intrepid e.g. is the development release, any bug filed is being tracked for the latest development release...only when a bug, which is being fixed in the development release is also occuring or happning in other releases older then the development release, you nominate those releases, not the development release..
[08:23] <nullack> Hobbsee Its not my problem
[08:24] <\sh> nullack: furthermore, you deal with bugs already assigned to other people...that's not a good behaviour
[08:24] <Hobbsee> nullack: i think i'll start forwarding all my unwanted bugmail to you then.
[08:24] <Hobbsee> then you can see just how annoying it gets.
[08:24] <persia> Umm.  Just as information perhaps assistive to discussion, the nominations aren't used for tracking the releases by the release managers.  There are milestones for that.
[08:24] <nullack> Hobbsee Your being unnecessarily combative
[08:24] <Hobbsee> nullack: as are you, saying that it's OK to spam people.
[08:24] <Hobbsee> or cause useless mails.
[08:24] <nullack> Hobbsee: Grow up please, if your subscribed to it, youll get mail on it
[08:25] <persia> OK.  Stop.  This is getting into ad-hominem.
[08:25]  * Hobbsee sighs, notes code of conduct.
[08:25] <persia> So, there are two issues at hand.
[08:25] <persia> Firstly, those working on an issue usually already have most of the information, and don't want additional notifications for things that cause them to have to press extra buttons in LP in order to proceed.
[08:26] <persia> Secondly, those attempting to track the state of a release want to be able to identify what bugs ought be targetted to a given release.
[08:26] <persia> Have I represented both desires correctly?
[08:26] <persia> \sh: ?  nullack?  Hobbsee ?
[08:26] <Hobbsee> nullack: if you haven't found this out yet, there are implicit subscriptions.  So any often these mails, often multiple per bug, are coming from teams, not people - which can't be unsubscribed from.
[08:27] <Hobbsee> nullack: so while your idea should work in theory - unsubscribe if you don't want it - it doesn't work in practice.
[08:27]  * Hobbsee also notes that you should go somewhere else, if you're wanting to personally attack those who don't agree with you.
[08:28] <nullack> The facts are, the release nomination facility is there
[08:28] <nullack> Hobbsee It's more than once that I see you have a go at people
[08:28] <Hobbsee> persia: yes, reasonably.
[08:28] <nullack> Hobbsee: Like yesterday with your crazy girl comment to the woman who came here
[08:28] <Hobbsee> nullack: leave emma out of this.  she's a special case.
[08:28] <nullack> Hobbsee: I know your young, but please try, ok
[08:28] <persia> \sh: nullack?
[08:29] <nullack> persia: I spoke with Brian about the problems with release nominations for those who cant milestone
[08:29] <persia> nullack: OK.  So?
[08:30] <persia> nullack: Have I accurately represented your use case?
[08:30] <nullack> persia: Which is what led to the email I sent about how to raise awarness of bugs
[08:30] <Hobbsee> nullack: please do not persist in these personal attacks.
[08:30] <nullack> Hobbsee: Im not attacking, Im giving feedback
[08:30] <nullack> Hobbsee: And Id remind you of the same, thanks
[08:30] <Hobbsee> nullack: telling me that i'm young is not giving feedback.  It's discrimination, among other things.
[08:31] <persia> Hobbsee: nullack: Please concentrate on the substantive issue, rather than the history of the discussion.
[08:31] <persia> nullack: Have I represented your use case correctly?
[08:31] <nullack> persia No
[08:31] <persia> nullack: OK.  What is your use case?
[08:31] <nullack> persia: Its understood that nomination process is not perfect
[08:32] <persia> nullack: Sure.  What are you trying to accomplish?
[08:32] <nullack> persia: Which is why I developed the email after working with Brian
[08:32] <nullack> persia: A mechanism for bug squadders and not bug controllers to raise awarness
[08:32] <nullack> persia: Because the nomination thing has problems
[08:33] <persia> OK.  To whom is this awareness being raised?
[08:33] <nullack> persia: Brian suggested to send it to the QA and Bug Squad mailing lists
[08:33] <nullack> persia: Which I did
[08:33] <nullack> \sh I would appreciate you engaging me in a better way next time
[08:34] <nullack> \sh: Im not your wipping toy to instruct to do doco
[08:34] <persia> nullack: Sure.  I'm still not understanding what you are trying to accomplish.  I suspect there is a solution that meets the needs of all parties to this discussion, but I need to know the goal in order to make a suggestion.
[08:34] <RAOF> nullack: Would it be fair to say that you're after a button to press which says "I believe that fixing this bug should be a priority for Intrepid"?
[08:34] <nullack> Yes Chris, but thats a longer term issue that as Brian said, isnt there now
[08:35] <persia> nullack: Is that an accurate represenation of your goal, or is there an intermediate goal you are seeking first?
[08:35] <nullack> Which is why I sent out the email on raising bug awarness
[08:35] <nullack> persia : Its longer term cos it requires dev effort to implement, and Brian raised concerns about noise in such a facility
[08:36] <persia> OK.
[08:36] <persia> \sh: Is it the noise that is causing your complaint?
[08:36] <nullack> persia : so the process I emailed about was seen as a solution till then
[08:37] <Hobbsee> nullack: either way, an assigned, and in-progress or above bug should also remain the property of whoever it's assigned to, as they're cleraly dealing with it.
[08:37] <persia> Hobbsee: Is it the noise that is causing your defence of \sh's complaint?
[08:37] <nullack> Hobbsee: I dont agree
[08:37] <Hobbsee> nullack: which your mail doesn't contain - is it possible for you to add that to your mails?
[08:38] <nullack> Hobbsee: No, because I dont agree
[08:38] <Hobbsee> persia: yes.
[08:38] <Hobbsee> nullack: why?
[08:38] <persia> OK.
[08:38] <nullack> Hobbsee: Because the issue of whos working on it is not the issue at hand in this case
[08:38] <persia> nullack: Is a list of these nominated-for-intrepid-but-not-approved bugs generated anywhere, or used for anything?
[08:38] <Hobbsee> nullack: let me put it another way - if someone's working on it already, then why does it need the bugsquad to put it up as a bug that needs to be fixed before release?
[08:38] <nullack> Hobbsee: The process need is about being able to get it onto the release teams IRC meeting for those that arent in bug control
[08:39] <persia> nullack: Ah.  That's entirely different.  Does the release team have a procedure that looks at bugs in this state?
[08:39] <nullack> persia: The release team has a number of processes that can manage the timing issues with it
[08:40] <nullack> persia: To give better history
[08:40]  * persia notices that Hobbsee is a member of ubuntu-release
[08:40] <nullack> persia: I sent a contribution to the QA Team's status report for the release team meeting
[08:40] <Hobbsee> nullack: if someone's already working on it, then it's *more* than likely that it is going to be finished by the release.  Also, remember that the developers are *also* QA people, and have thus already made the judgement call about whether it should be on the release team radar.
[08:40] <persia> nullack: OK.  I can see that.  I think the process needs wider discussion.
[08:40] <nullack> persia: And the feedback was, thats some good stuff and its scary we didnt do this sooner
[08:40] <Hobbsee> nullack: why should the bugsquad duplicate effort here, and step on toes of other qa members?
[08:41] <persia> I think I share Brian's concern about the noise, especially with developer complaints.
[08:41] <nullack> persia: So the obvious question then becomes, whats the optimal way to do so, which I asked, got no response, so I asked Brian directly
[08:41] <persia> Essentially, if we generate a QA process that annoys developers, we'll have fewer developers.
[08:41] <Hobbsee> persia++, and this seems to be happening more and more frequently.
[08:41] <persia> nullack: Right.  So would it not be possible for those not in bug control to ask those in bug control to make the adjustment in this channel?
[08:41] <nullack> persia: Perhaps then Developers need to consider their attitude with these things
[08:42] <persia> nullack: We have all sorts of people.  I don't think there is a general answer for attitudes for anyone.
[08:42] <nullack> Hobbsee: Your point doesnt change the situation
[08:42] <persia> Since most people are volunteers, we need to make it enjoyable, or we'll not have the volunteers.
[08:42] <Hobbsee> nullack: why not?
[08:42] <nullack> Hobbsee: Its not about the developers, thats why
[08:43] <Hobbsee> nullack: it's not solely about the qa team, either.
[08:43] <nullack> Hobbsee: No, its also about what gets released
[08:43] <RAOF> nullack: I disagree.  Much of our infrastructure, is all about helping the developers.
[08:43] <Hobbsee> ultimately, the bugs are waiting there for the developers to fix, and the release to happen as a result.
[08:43] <nullack> RAOF: Thats fine and I support helping Developers ofcourse
[08:44] <\sh> persia: it's the noise..and the disturbance of my own bugwork...I don't touch other bugs when they are assigned to someone (status wise) and I tend to think that other people don't touch my bugs while I'm working on it (status wise)
[08:44] <nullack> The issue at hand is that not all bugs that should be are being recognised for release nomination or milestoning
[08:44]  * persia asserts the lack of useful means to distinguish members of the development team from members of the QA teams.
[08:44] <nullack> \sh You dont own the bug, your working on it, its different
[08:45] <Hobbsee> nullack: do you think that all bugs, whether main or universe, should be on the ubuntu-release radar, if they're to be fixed before release?
[08:45] <nullack> And I object with the notion that working on release issues is "noise"
[08:45] <persia> \sh: OK.  That makes sense.  Might there be an exception for release targeting?
[08:45] <nullack> Its insulting
[08:45] <persia> nullack: Working on release issues *isn't* noise.  Generating unwanted bugmail may be perceived as noise.
[08:45] <persia> That's why we need a procedure that works for everyone.
[08:46] <nullack> What Brian meant by noise is different
[08:46] <\sh> persia: if it's an RC, yes...but universepackage bugs are mostly not  RC candidates (forgetting the MIRs)
[08:46] <persia> nullack: What do you think Brian meant?
[08:46] <nullack> Its not a developers right to claim ownership of a bug if they are assigned to it, ask no one else to touch it and then direct me to do doco
[08:47] <nullack> Thats just plain wrong
[08:47] <Hobbsee> maybe not the last part.
[08:47] <Hobbsee> but the first part - why not?
[08:47] <Hobbsee> they're the one fixing it?  it finishes with them.
[08:47] <persia> \sh: As a participant in *two* universe-based flavours of Ubuntu, I'm not sure that's true, and further think a lot of universe packages are important, but I see what you are saying.
[08:47] <nullack> Because the world isnt centered on a developers perception of what needs to be done
[08:47] <nullack> Development isnt the only "work"
[08:48] <nullack> It needs to be build, deployed, tested
[08:48] <Hobbsee> nullack: no, but we do need ways of making sure 2 people don't work on the same bug, and therefore one spending useless energy on it, at the same time
[08:48] <Hobbsee> ie, if both come up with a fix.
[08:48] <\sh> persia: I don't say, universe is not important...but having a bug which is a blocker to a release, I tend to agree, that a status change is sane, regarding the fact, that most valuable devs of core are doing this assignment
[08:48] <persia> Certainly.  It just needs a procedure that works for developers, testers, etc.
[08:48] <nullack> Hobbsee: Agreed
[08:48] <Hobbsee> currently, assigning is done for that.
[08:48] <Hobbsee> thus, the "please don't touch it, i'm aware of it" is the protocol used, in current ubuntu.
[08:48] <nullack> And the final part of the puzzle thats most important is the user experience
[08:49] <persia> \sh: OK.  So your assertion is that release-tracking ought be done by release management and flavour developers, and not the QA teams?
[08:49] <nullack> And often there is bugs with serious user experience problems not on the release teams radar and not on the qa status report
[08:49] <nullack> Since the nominate for release function isnt working too well
[08:49] <Hobbsee> nullack: so, in your proposals, how many bugs would you be expecting to have resolved at the end of each milestone, for the release team to deal with?
[08:50] <nullack> What Brian and I worked on was where bug squadders would raise it on the list
[08:50] <\sh> persia: yes...because release managers and flavour relengs do know more about the underlaying problems then QA...(that's why in most companies QA is a _testing_ department and not a department which decides what's RC critical and what not)
[08:50] <Hobbsee> just for a ballpark figure, so that the release team can actually check if that's something it wants to do, or not.
[08:50] <persia> nullack: Ah, so the procedure would be to raise the bugs on the mailing list?
[08:50] <seb128> there is too many bugs to do that
[08:50] <persia> \sh: What about those who just do QA?  How about the release testers who rigourously check each daily build?
[08:50] <Hobbsee> seb128: that would have been my thought, yes.
[08:50] <seb128> the reason why the nomination doesn't work correctly is that hundred of bugs are nominated
[08:51] <seb128> if hundred of mails are sent on the list that will not scale either
[08:51] <persia> seb128: So you think the issue is that we have more nominations than developer time to fix them?
[08:51] <seb128> persia: clearly
[08:51] <nullack> seb128 you have to consider that launchpad is pretty public but the member of bug squad is not
[08:51] <Hobbsee> persia: I'd agree with that, with my RM hat on.
[08:51] <seb128> and people tend to nominate their pet bugs because they think their usecase is important for everybody
[08:51] <Hobbsee> persia: many things get dropped from the milestone lists, or deferred, just because it won't get fixed.
[08:52] <Hobbsee> (in time)
[08:52] <persia> nullack: Given seb128's concern (and he's one of the *most* active developers for Ubuntu Desktop), how do you think we can increase developer time to scale to the identified issues?
[08:52] <nullack> persia Your getting into bifurcation
[08:52] <Hobbsee> s/RM/Release Team/, etc.
[08:52] <\sh> persia: well, daily cd testing doesn't mean finding RC bugs..but it can be, that a bug which is found by some qa people is RC critical...and yes, a QA role person can also have RELENGS role position...but we should definitly make a difference
[08:52] <nullack> persia Those issues are release management issues
[08:52] <nullack> persia What the testers are saying is we need to get better reports to the release management meeting
[08:53] <nullack> persia And then the meeting can debate priorities and allocation of resources
[08:53] <Hobbsee> nullack: then i hope they'll be more, but filtered.
[08:53] <persia> nullack: OK.  I'm not sure how it helps release management if we don't have enough developers, but I can see prioritisation.
[08:53] <Hobbsee> nullack: a lot of those meetings don't include universe-based stuff, though.
[08:53] <Hobbsee> nullack: mainly because the universe people don't tend to be on the payroll, and so demanding they get it fixed, on time, isn't going to work.
[08:54]  * persia needs to run, and is already late.  Apologies to all: this is a very interesting discussion, and I firmly believe there is a solution that meets everyone's goals (but we're not there yet)
[08:54] <Hobbsee> (i understand that you probably haven't had to deal with the above situation before)
[08:54] <nullack> Hobbsee: Thats a release management issue
[08:54]  * persia notes that many main people are not on any payroll for their work in Ubuntu as well, and really leaves
[08:54] <nullack> Hobbsee: If they decide to priority something in MOTU, they need to figure out how to do that
[08:54] <Hobbsee> persia: oh, sure, but the people who are in that meeting tend to be.
[08:55] <seb128> I joined in the middle of the discussion but I'm not sure why you want an another workflow
[08:55] <Hobbsee> nullack: you appear to want to give the release teams more work, without asking if they actually want it.
[08:55] <seb128> what is wrong in the current nominations one?
[08:55] <persia> Hobbsee: Many of them, but not all.
[08:55]  * persia really leaves
[08:55] <Hobbsee> seb128: stuff doesn't get fixed from it
[08:55] <Hobbsee> persia: yes, hense the "tends to be" :)
[08:55] <seb128> that's a manpower issue, changing the workflow will not make a difference
[08:55] <Hobbsee> *hence.
[08:55] <nullack> seb128 It will
[08:56] <nullack> seb128 If the release management meeting raises a critical user experience problem
[08:56] <nullack> seb128 Release management milestones will be set
[08:56] <seb128> those guys should go on a regular basis through the nomination lists
[08:56]  * Hobbsee notes this tends to happen already.
[08:56] <seb128> if they don't that's the issue
[08:57] <nullack> seb128 the problem is bug control cant see them all
[08:57] <seb128> I'll talk to slangasek when he's around
[08:57] <seb128> it's his job to look at those lists
[08:57] <nullack> seb128 and when people nominate for release some others gets uneccasirly agitated like \sh
[08:57] <Hobbsee> seb128: what brought this up was the fact that lots of developers are getting "needless" bugmail from all the switches being pressed, and the fact that assigned, in progress bugs, are then being filled with by the QA team - and they view this as stepping on toes.
[08:57] <Hobbsee> s/filled/fiddled/
[08:57] <seb128> that's a launchpad issue
[08:57] <Hobbsee> (if that helps for context)
[08:57] <Hobbsee> seb128: sure, but we need to work around LP
[08:58] <nullack> seb128 Its not about the devs and their toes, I have tremendous respect for all the devs
[08:58] <seb128> Hobbsee: launchpad doesn't bug mail on nominations
[08:58] <nullack> seb128 The issue is user experience problems need to have a way of being flagged as hey, this needs release management attention
[08:58] <seb128> use tagging?
[08:59] <nullack> seb128 Well, you could imagine some more sensitive devs might see that as fiddling as well
[08:59] <\sh> nullack: first, I got mail, second, I have to click on some strange "approve/decline" links just to say "no" because it's useless, because devel release bug tracking is already done without nominating...only when bugs are also in former releases the nomination makes sense, so that assigned dev knows, he needs to work on the very same package in older archives, too...
[08:59] <seb128> that's not true
[08:59] <\sh> nullack: furthermore, you don't have the rights for nominating, so someone else needs to work to resolve those nominations
[08:59] <nullack> \sh Perhaps you should focus on helping improve the process isnt of getting up me
[08:59] <seb128> you should read the current processes, nominations are used for bug which should be fixed in the current cycle too
[09:00] <nullack> \sh I do have rights for nominating and I did
[09:00] <seb128> any bug which is nominated and has a milestone is something to fix for this milestone
[09:00] <Hobbsee> seb128: oh, i thought it did.  It certainly does for everything else - which I usually see done in tandem.
[09:00] <\sh> seb128: that's why on lp its written: the actual status and bug info is tracked on the mainline, which means: devel release of today
[09:00] <\sh> seb128: and yes, it could be, that LP is wrong here, then we need to fix LP
[09:00] <seb128> you can nominate a bug for intrepid
[09:00] <Hobbsee> seb128: ew, tags :)
[09:00] <nullack> seb128 Thats right
[09:00] <seb128> and that's how slangasek tracks the intrepid targets for example
[09:01] <Hobbsee> seb128: they *also* create a whole stack of bugmail :)
[09:01] <\sh> nullack: you don't have the rights...you just clicked, but approval is coming from someone else...
[09:01] <nullack> \sh Yes, the release management group, which is where it should be
[09:01] <nullack> \sh The objective is for testers to be able to flag this stuff
[09:01] <nullack> \sh Honestly, its not about your work on the bug, its a release issue
[09:01] <\sh> nullack: no...the developer who is working on it, or the security team, or motu-release, or just me can approve or decline...many people can, because they have to
[09:02] <nullack> \sh I understand, but what your really doing in that context is release management not development, if you see my point
[09:03] <\sh> nullack: what in your eyes is Release critical on ia32-libs?
[09:03] <\sh> nullack: what is release critical on a buggy flashplayer10 ?
[09:03] <nullack> \sh The flash user experience on 64 bit systems is release critical
[09:03] <\sh> nullack: did you read the bugreport really well?
[09:03] <nullack> \sh Did you?
[09:04] <Hobbsee> nullack: have you asked the release managers what sort of information they want, before putting everything that you view is important, no matter what the section, on their radar?
[09:04] <\sh> nullack: because what's written there is: "Flashplayer10 needs some add libs", I'm the reporter of the initial bug about FMS (both adobe) ... did you ever thought about "oh this guy knows something about that?"
[09:04] <Hobbsee> nullack: and if not, should you?
[09:04] <seb128> those flash issues are on their list
[09:04] <nullack> Hobbsee: Ive allready explained what I asked and then I what I did from there
[09:05] <nullack> \sh Im warning you to pull your head in
[09:05] <nullack> \sh Youve already insulted me enough here
[09:05] <\sh> just on a sidenote: "flashplayer10 is just so buggy, that some really hardcore flex apps are not running correctly"
[09:05] <Hobbsee> nullack: you said you asked brian.  i asked if you asked the *release team*.  Brian, afaik, is not the release team.
[09:05] <seb128> could everybody calm down and stay correct?
[09:07] <seb128> having a decent way to track bugs that should be considered is a valid request
[09:07] <\sh> nullack: If I would start insulting you, that would sound different...really...
[09:07] <\sh> anyways, it's not going to work...
[09:07] <Hobbsee> seb128: but not 10 billion of them.
[09:07] <seb128> the current system uses launchpad nominations
[09:07] <seb128> and I don't think changing the workflow is the solution there
[09:08] <seb128> we just need to figure what doesn't work in the current way and to fix that rather than design a new one
[09:09] <nullack> seb128 Brians feeling was that in the short term if testing folk discussed it on the bug squad list thats atleast treating the issue
[09:09] <nullack> seb128 Which is what I shared on the squad list and qa list
[09:09] <Hobbsee> nullack: i don't think anyone's objecting to that.
[09:09] <seb128> would be nice to have concrete cases of where the current workflow didn't work to understand what are the issues
[09:09] <seb128> and yes, testing guys can use the list
[09:10] <Hobbsee> nullack: however, that doesn't involve actually touching the bugs, which, afaik, is what \sh and others are complaining about.
[09:10] <nullack> Hobbsee: Look at the bug history
[09:10] <seb128> but the recommendation should not be that any user finding a bug which might be to consider should mail the list because that will not scale
[09:10] <nullack> Hobbsee: I nominated it for release under the old process which Sebastien thinks is ok
[09:10] <nullack> seb128 Its not any user
[09:10] <Hobbsee> seb128: that was my other concern.
[09:11] <nullack> serb128 Were talking about bug squadders
[09:11] <seb128> not only it's ok, but that's the documented way to nominate issues and the one which is used to track those by the current teams
[09:11] <nullack> seb128 Right, so why I am copping grief from \sh about it then?
[09:12] <nullack> seb128 Especially when Ive gone to the extra effort of discussing how to improve the process with Brian and bug squadders
[09:12] <seb128> just ignore him, he has not been constructive in this discussion and seems to doesn't know the way ubuntu works currently
[09:14] <nullack> Everyone, can I honestly say, were all trying our best I know that
[09:14] <nullack> Maybe the problem is the current process isnt well documented or understood
[09:14] <nullack> And the talk about changing it might be confusing it further
[09:14] <Hobbsee> seb128: even any bug squad member highlighting multiple bugs won't scale, will it?.
[09:15] <seb128> I'm not sure to understand what issue mailing the bugsquad list should fix
[09:15] <seb128> it's probably be fine to discuss whether a bug should be nominated or not when unsure
[09:15] <seb128> but that should not be the standard way to discuss any bug
[09:16] <nullack> seb128 : The idea was to ask people to raise a bug they found on the bug squad list to raise awareness of it
[09:16]  * Hobbsee wishes nullack would actually ask her questions.
[09:16] <Hobbsee> er, answer
[09:16] <\sh> anyways
[09:16] <seb128> but they can suggest it for nomination
[09:16] <seb128> why wouldn't that work correctly?
[09:17] <nullack> Hobbsee: Which question Sarah? I did not see it I thought the last one you asked was to Seb
[09:17] <slangasek> what are we suggesting for nomination? :)
[09:17] <Hobbsee> [17:49] <Hobbsee> nullack: so, in your proposals, how many bugs would you be expecting to have resolved at the end of each milestone, for the release team to deal with?
[09:17] <seb128> slangasek: some people seem to think that the current process to nominate bugs doesn't work correctly
[09:17] <seb128> slangasek: too many of those are being ignored
[09:18] <nullack> Hobbsee: I dont know, honestly, and thats not the issue. The issue is how to get it to the release team. I understand there will be further issues but Im focused on this one first
[09:18] <slangasek> well, I agree that it doesn't work correctly
[09:18] <Hobbsee> slangasek: every bug that the QA team thinks is a critical bug from a users POV (including things such as nonfree flash on amd64, it seems), even if it's already assigned and in progress, and someone is clearly dealing with it.
[09:18] <slangasek> because it's a one-shot deal in launchpad; I've complained to kiko before about this workflow being a problem
[09:18] <Hobbsee> slangasek: aiui, anyway.
[09:18] <seb128> slangasek: and they are trying to suggest alternative workflow using the bugsquad mailing list to raise attention on some issues
[09:19] <seb128> slangasek: my impression was that we are not active enough on accepting or declining things which are suggested for nominations
[09:19] <gnomefreak> mvo: landscape-common needs to be held back its broken
[09:19] <gnomefreak> s/needs/should
[09:19] <seb128> gnomefreak: how broken?
[09:19] <mvo> gnomefreak: broken in what way? is there a bugnumber?
[09:19] <Hobbsee> nullack: i'm sorry, but it *is* a valid issue that you need to address here.  If you want to get stuff changed, and significantly add to a team's workload, then it would be a *very* wise idea to estimate the impact, and check that it's something that they want, rahter than trying to blindly change things.
[09:19] <gnomefreak> seb128: DOESNT INSTALL
[09:19] <seb128> gnomefreak: it's in binary new no?
[09:19] <slangasek> seb128: yes, because once a nomination has been declined (which is the appropriate workflow for any nominated bug that's still incomplete or new), it can't be re-nominated
[09:19] <gnomefreak> Errors were encountered while processing: /var/cache/apt/archives/landscape-common_1.0.18-0ubuntu2_all.deb
[09:20] <nullack> Hobbsee: I guess thats where I differ to your opinion
[09:20] <nullack> Hobbsee: I see the problem right now as being a test issue
[09:20] <seb128> gnomefreak: copying the actual error would be useful
[09:21] <Hobbsee> nullack: it would be great to make the testing better, I agree.  However, are you just pushing the bottleneck further up?
[09:21] <nullack> Hobbsee: Lets try not to be defeatist eh :)
[09:21] <gnomefreak> seb128: mvo http://pastebin.mozilla.org/538170 is full
[09:22] <seb128> "trying to overwrite `/usr/lib/python2.5/site-packages/landscape/patch.py', which is also in package landscape-client"
[09:22] <seb128> is the error
[09:22] <seb128> lack of correct replaces
[09:22] <gnomefreak> strange its held back but tryies to install
[09:22] <gnomefreak> seb128: if that ws it --force-overwrite would work
[09:22] <nullack> seb128 You can reinstall the landscape client and it works but it then complains about no setup as per my bug comment
[09:22] <Hobbsee> nullack: and I can see your point - that it's not your problem if it's above the QA team - it's for the release team to deal with.  But, if you want to stay in good standing with the release team, you'll need to actually work with them, rather than throwing information in their faces, and flooding their processes.
[09:23] <Hobbsee> nullack: no, i'm being a realist, having worn a lot of the hats before.
[09:23] <slangasek> gnomefreak: already fixed in the -0ubuntu3 upload
[09:23] <seb128> slangasek: there is no such upload?
[09:23] <gnomefreak> hmmmmm it hasnt hit archives than
[09:23] <seb128> ps
[09:23] <nullack> Hobbsee: I would expect the release team to be less alarmist and to discuss things in an open and friendly way. Process improvement should be a continual thing
[09:23] <seb128> there is
[09:23] <slangasek> seb128: of landscape-client?  theer is
[09:23] <seb128> slangasek: ignore my comment ;-)
[09:23] <slangasek> and it's in NEW.  Hmm!
[09:23] <gnomefreak> yep
[09:24] <seb128> slangasek: I was just looking at that
[09:24] <slangasek> seb128: shall I let you keep looking?
[09:24] <Hobbsee> nullack: I have been.  I've been asking stuff like "how much change do you think will be made here?", so that hte release team can have a fair idea of the impact, and so can then deal with how to react as a result, but you keep telling me it's a non-issue, and not your problem.
[09:24] <seb128> slangasek: I've a command line ready to accept it if you are not faster :-p
[09:25] <slangasek> seb128: go ahead :)
[09:25] <nullack> Hobbsee: I believe I said I dont know what the impact will be, I dont see how I can be more clear than that
[09:25] <seb128> slangasek: accepted to main
[09:25] <Hobbsee> nullack: you can't estimate it, based on how many bugs you'd milestone/etc if that were the process?  Aren't you dealing with a lot of these bugs, and trying to push them higher now?
[09:27] <nullack> Hobbsee: Theres alot of bugs Im not involved with, any one person wont be involved with any significant portion of the total number. Its huge. And, we dont know yet how well the raising bug awareness issue will go within the bug squad team so its too early to give any meaningul numbers to the release team
[09:27] <Hobbsee> nullack: right, so you can't really even give a ballpark (ie, how many 0's would follow the number).  Pity.
[09:27] <seb128> I'm going to ask again, but what is that you are trying to fix exactly?
[09:28] <nullack> Hobbsee: I dont believe anyone could give you a meaningul number, But how about I monitor it, and let you know ok? :)
[09:28] <Hobbsee> nullack: that'd be cool.
[09:28] <nullack> Hobbsee: ok :)
[09:28] <Hobbsee> nullack: ultimately, i really only want to know the power of 10 of bugs it would be, or so
[09:28]  * slangasek squints at bug #246141, which has been confirmed, nominated for intrepid, and... never assigned to the right package.
[09:29]  * Hobbsee would tentatively guess 10's or low 100's.
[09:29] <nullack> seb128 : The nominate for release process is not optimal
[09:29] <seb128> right, slangasek confirming he agrees on that
[09:30] <nullack> seb128 : When I discussed it with Brian it come out that he felt it better for now too
[09:30] <nullack> seb128 : Email the squad list to raise awareness of any big user issues that should be targeted for a specific release target
[09:30] <nullack> seb128 : that way provide visibility atleast
[09:31] <seb128> why can't you use the standard nomination?
[09:31] <\sh> slangasek: bug #196526 is really important, never nominated, nor touched and they are annoying, because not only ~ubuntu-drivers can approve/decline them
[09:31] <slangasek> \sh: "and they are annoying"? what "they"?
[09:31] <nullack> seb128 : Because it was seen that the lp nominate was too noisy because many people with only a casual interest in stuff were marking it up
[09:32] <\sh> slangasek: nominations (when it's not been a security bug or an -update bug)
[09:32] <nullack> seb128 : By limiting it to the bug squad list, it was seen as a less noisy solution
[09:32] <seb128> that's not a good answer
[09:32] <nullack> seb128 : Its an interim
[09:32] <seb128> nominations are the documented way to list those issues
[09:32] <nullack> seb128 Its not supposed to be final
[09:32] <seb128> people complaining should raise the issue and open launchpad bugs about their annoyances
[09:33] <seb128> or set up mail filtering
[09:33] <nullack> seb128 Well it seems easier to abuse the testers
[09:33] <seb128> not using the standard workflow just because some people complain about bug mails is not a good reason
[09:33] <\sh> seb128: for what? "In Progress" + "Assigned" means, someone is working on it, right?
[09:34] <seb128> the issue is not to mean that somebody is working on those
[09:34] <seb128> but that they are issue the ubuntu team wants to consider for intrepid
[09:34] <nullack> seb128 Thats right, Ive said before and Ill say again, its a release management issue not a dev issue
[09:35] <Hobbsee> \sh: it appears, from what nullack's saying, that having someone working on it isn't enough - he's wanting it to be on the release radar as well.
[09:35] <seb128> because nobody is working on something doesn't mean that the issue should not be considered
[09:35] <\sh> seb128: again...the bug in question was filed during the timeline of latest devel release...the change needs only available for intrepid, and for a special version of flashplugin-nonfree (version 10, which is still buggy and the needed libs can change, regarding adobe)..so there is no serious problem , no RC bug, not even a supported package...
[09:35] <seb128> those are orthogonal issues
[09:36] <seb128> you consider flash crashing for lot of users not a real issue?
[09:36] <nullack> \sh I disagree. The flash user experience is seriously broken in Intrepid and in my view its essential this become a release management item for action
[09:36] <Hobbsee> \sh: as to what practical benefit that gives us, for packages based in universe, i'm unsure.  It will make sure bugs won't get forgotten about, but i'd also bet that those will be the first ones to be deferred if they don't get done, they generally will be fixed by volunteers (who tend not to have, or need people breathing down their necks about it), and it'll greatly increase the release management queues.
[09:36] <\sh> seb128: does flash crash because of missing libs in hardy?
[09:37] <seb128> dunno why it crashes, but it does and that's a real issue for ubuntu users
[09:37] <\sh> nullack: if you use flashplayer10, so yes, that's intended, because flash10 is even buggy on windows or mac...I know, because I work with it every day...really
[09:37] <seb128> again nomination and bug work are orthogonal issues
[09:37] <seb128> the nominations are there to list issues to consider
[09:37] <slangasek> I'm pretty sure I've completely lost the thread of this discussion
[09:37] <seb128> that doesn't mean the bug has a fix available
[09:38] <\sh> seb128: it crashes because of other things, but we are talking about flash10 which is still in beta mode of adobe (the version in multiverse/intrepid is even the alpha)
[09:38] <nullack> \sh Ive done cross platform testing on flash to see, actually, and Linux has particular issues all to its own
[09:38] <nullack> \sh For example, the adobe flash 10 demo site doesnt work on Intrepid but does work on Mac OSX
[09:38] <seb128> don't focus on one bug
[09:38] <\sh> nullack: I can give you at least 2 flex apps which are not runningon flash10
[09:38] <seb128> it might have been nominated wrongly, errors happen sometime
[09:38] <seb128> can you stop focussing on this stupid flash10 thing?
[09:38] <nullack> I dont think it is nominated wrongly
[09:38] <\sh> nullack: did you ever try proxy server and rtmp connects with flash? it doesn't work either, it worked in 2004 but not in 2008...and adobe doesn't fix it in time,
[09:38] <Hobbsee> slangasek: out of general curiousity, do you regard the fact that flashplugin-nonfree breaks on amd64 a RC issue?
[09:39] <Hobbsee> slangasek: and something you'd want on your radar?
[09:39] <seb128> nullack: "upgrade to flash10" might not be the right solution to the flash issues users are having
[09:39] <nullack> seb128 Yes, but this is necessary to upgrade the flash 10
[09:39] <nullack> seb128 theres another bug about upgrading the rc
[09:40] <seb128> anyway let's not focus on this particular issue
[09:40] <\sh> nullack: and the same happens on all three main OS...and much better, winxp 64/vista64 + flash10 is also broken...so far for RC issues on amd64
[09:40] <nullack> seb128 and Alexander said he'd wait until after A6 is done
[09:40] <seb128> fighting on a detail doesn't help on the workflow discussion
[09:40] <slangasek> Hobbsee: uhm, I'm not aware that flashplugin-nonfree is broken on amd64
[09:40] <slangasek> I mean, any moreso than usual :P
[09:40] <nullack> So to be clear
[09:40] <seb128> slangasek: have you read bug #192888? ;-)
[09:41] <slangasek> so I imagine I would want to review the claim, but it sounds inflated to me
[09:41] <nullack> 1. Ive been abused for following a documented process
[09:41] <nullack> 2. Were actually trying to fix the process by improving it
[09:41] <seb128> slangasek: over 300 comments and 60 duplicates
[09:41] <nullack> 3. I really wish we'd try to engage each other in a more open way next time, please
[09:41] <nullack> I have respect for all the hard work that you all do
[09:42] <nullack> But testers work hard too you know
[09:42] <\sh> seb128: and nobody has a clue what's the source of the actionscript2 flash app? most of the crashes are coming because of some strange behaviour of coding in AS2 or AS3 in flash/flex...
[09:42] <slangasek> seb128: "Adobe's code is crap" is not an RC bug; I don't see any evidence of firefox itself crashing, here...
[09:42] <\sh> or the usage of some strange sound architecture which is not supported by adobe in the first place.
[09:43] <\sh> the usage of flash on x86_64 is not the usecase of adobe here...if it would be the usecase, they would provide native builds of their plugins...they don't
[09:44] <seb128> there is lot of amd64 ubuntu users though
[09:44] <seb128> and they want to use flash websites
[09:44] <slangasek> seb128: oh, this is the libflashsupport bug, I should read the bug titles more closely maybe
[09:45] <slangasek> do I think that should be fixed? yes
[09:45] <slangasek> do I think escalating it to the RM is the most effective way of accomplishing that?  ...no, probably not
[09:46] <seb128> slangasek: the question is "how to make a visible lists of issues that should be considered for a cycle so people can try to work on those"
[09:46] <\sh> seb128: TBH, http://bugs.adobe.com/jira/browse/FP-519 <- check this out...this bug is a real bug...the pointer inside the bug, it's me reporting it nicely and with a technical background..this bug is not fixed since 2006...I just wonder why..and then you know, how adobe works...flashplayer plugin doesn't bring any money...so it's low prio for them...adobe connect with a improved flashplayer is something different...
[09:47] <Hobbsee> seb128: and the related question is "what is the general criteria of which bugs should be raised?"
[09:47] <slangasek> so, er, assuming that we're talking about fixing them during a /development/ cycle, and not as SRUs... why is a list of all open bugs, priority high or critical, found in Ubuntu, an appropriate starting point?
[09:47] <nullack> Hobbsee: I think anything important to the common user experience
[09:47] <slangasek> you can get that from LP without any need for nominating
[09:54] <slangasek> am I asking rhetorical questions? :)
[10:00] <seb128> slangasek: I'm not sure only the high importance bugs should be considered, there is lot of small details which count for the user experience
[10:03] <slangasek> well, sure there are
[10:03] <slangasek> but there'd better be a better system for getting people to work on those than having the RM bless them
[10:10] <nullack> seb128 \sh and I have been talking, and we think we should pursue the raising awarness of bugs through the bug squad mailing list for when bug control arent available and dont have an existing milestone
[10:10] <nullack> seb128 Its not perfect but its a short term idea until LP gets improved
[10:10] <wgrant> s/short/LP/
[10:10] <wgrant> LP time is like geological time - it needs its own name.
[10:10] <seb128> I'm still not sure what bugs should be considered but not nominated though
[10:11] <nullack> seb128 The problem is its open to more or less the public and this generates alot of "noise" with nominations
[10:13] <nullack> seb128 The idea being that bug squadders have probably put more thought into the reasons why
[10:13] <nullack> seb128 Unlike a random drive by I want this fixed cos I want it nomination by some random person
[10:13] <Hobbsee> nullack: s/bugsquad/qa/ - bugsquad's an open team, last i knew.
[10:14] <nullack> Hobbsee: Good point, but it takes some effort to join, not just a random thing
[10:14] <Hobbsee> nullack: it does?
[10:15]  * Hobbsee did it a long time ago, but doesn't remember it being restricted at all
[10:15] <nullack> Hobbsee: Just that its more effort than a person searching for a bug in launchpad and doing a nomination
[10:15] <nullack> Hobbsee: They have too find out the team exists, join it, theres wiki doco etcetc
[10:16] <nullack> Hobbsee: IMHO all that is more effort than the more random Ive got one issue and Im commenting type work
[10:16] <Hobbsee> nullack: that's true - but various people don't read, and try to join all sorts of teams that they shouldn't.
[10:16] <Hobbsee> nullack: i know that's the way it *should* be.  Unfortunately, that's not quite the way it turns out happening :-/
[10:17]  * Hobbsee is still stunned at the number of non-motu's who attempted to join the sponsoring team, to upload to the archive, even when the description said quite clearly that it wasn't for them.
[10:17] <nullack> Hobbsee: Do you consider it better to stick to launchpad nominations for the time being?
[10:18] <Hobbsee> nullack: hmmm.  I'm not sure, tbh.  Neither scale so well.
[10:18] <Hobbsee> nullack: one of the things i'd like to see in the future, though, is people picking important user issues off the forum, and making sure that bugs, etc, exist for it.
[10:18] <Hobbsee> (if you're looking for ideas)
[10:19] <nullack> Hobbsee: Yeah its a tricky problem I can see both sides
[10:19] <nullack> Hobbsee: I do that alot, actually :)
[10:20] <nullack> seb128 I think there is no clear consensus on this issue, but what if we still allow the bug squad mailing list idea just to see how it works out?
[10:20] <nullack> Hobbsee: To see if it helps at all? maybe
[10:21] <Hobbsee> nullack: that's probably a fair idea.  it'd at least say how much it gets used.
[10:21] <seb128> no objection from me but I'm not really an active bugsquader, I'm rather a desktop team guy
[10:21] <Hobbsee> nullack: i fear that it's a bandaid solution, and not dealing with the core issues, though.  But it's a start.
[10:21] <nullack> Hobbsee: I think your right - its not meant to be long term
[10:21] <Hobbsee> nullack: if anything, i hope you deal with the core issues, from the ubuntu side, as far as possible, rather than focus on workarounds :)
[10:21] <Hobbsee> but i suspect you're planning to do that anyway.
[10:22] <nullack> Hobbsee: Me too :)
[10:41] <nullack> seb128 : I closed off 255554 and I will go upstream and post its fixed there too
[10:41] <nullack> Havent been able to replicate that problem in sometime
[10:41] <seb128> bug #255554
[10:41] <seb128> ok thanks, I think it was fixed in a gtk update and there has been no recent duplicate that's why I asked on the bug
[12:43] <dpgravjob> Hi want some help trying to find out if the problem i have on my computer is a bug,
[12:43] <dpgravjob> to me looks like kernel panic.
[12:43] <dpgravjob> related question https://answers.launchpad.net/ubuntu/+question/44988
[13:13] <hggdh> dpgravjob, first, why do you think it is related to the Azalia?
[13:14] <hggdh> dpgravjob, anyways, what it sounds like is that you are getting a kernel panic, and system dies. Yes, it is worth a bug.
[13:21] <dpgravjob> can someone please post what logs i need to put on my question and will try to produce a bug report
[13:27] <hggdh> dpgravjob, see https://wiki.ubuntu.com/DebuggingProcedures
[13:28] <hggdh> specially the kernel & sound parts
[13:51] <hwilde> my firefox bookmarks disappeared
[13:51] <hwilde> including the bookmark toolbar at the top
[13:52] <hwilde> and now all pages never stop loading, the little circle thing in the tab just keeps spinning
[14:16] <hwilde> nevermind my filesystem was in read-only mode
[14:16] <hwilde> several rounds of e2fsck later the bookmarks are saved!
[14:18] <Hobbsee> hwilde: that'll be teh parallel fsck bug, then.
[14:20] <hwilde> can I get them chocolate covered
[14:20] <Hobbsee> you can try!
[14:21] <hwilde> tasty
[14:21] <hwilde> high in protein too
[14:22] <hwilde> Hobbsee, so if the file system was in read only mode, why wouldn't it read my bookmarks :)
[14:24] <Hobbsee> hwilde: i think it's more that it won't let you log in with  /home/username as your home directory, as it needs to write to there then.
[14:24] <Hobbsee> thus, it's not in your path, so appears to not be there.
[14:25] <Hobbsee> apart from that, i'm not sure if it actually ends up mounting, as I think it has a busy flag set while it's doing the fsck.
[14:25] <Hobbsee> because i've not been able to mount it manually during those times
[14:25] <hwilde> I was totally logged in tho
[14:25] <Hobbsee> strange, then.
[14:25] <hwilde> I was on here talking
[14:25] <Hobbsee> no warnings?
[14:25] <hwilde> and firefox opened pages
[14:25] <hwilde> just no bookmarks
[14:25] <hwilde> I thought my system was working fine actually
[14:26] <hwilde> until I went to rm -rf .mozilla/firefox/ and it said read-only
[14:26] <Hobbsee> very odd.
[14:31] <mrooney> should I mark bug 223408 as triaged? and are there general cases where a bug has been sent/linked upstream and you don't want triaged?
[15:11] <bddebian> Boo
[15:40] <mrooney> bug 271364
[15:40] <mrooney> does that belong in transmission, and is a needs-packaging correct?
[15:40] <mrooney> 1.34 doesn't appear to be in Debian unstable so I am not quite sure what the proper action is
[15:43] <persia> mrooney: "needs-packaging" isn't correct, because we already have a transmission package.  "upgrade" would be the right tag.
[15:44] <mrooney> okay, the reporter appears to be upstream transmission so I don't want to subvert him if he knows what he is doing
[15:44] <persia> While most packages are pulled from Debian unstable, some packages are pulled from Debian Experimental, other Debian-format packaging repositories (e.g. Debian Multimedia), or upstream directly.
[15:45] <persia> IF upstream transmission opened the bug, they want us to pull from upstream directly, and are engaged enough with Ubuntu that it may be a sensible choice (although it needs developer review).
[15:45] <persia> It's definitely an "upgrade" bug though, rather than "needs-packaging".  We have packaging for transmission, but we don't have the latest version (apparently).
[15:46] <persia> Note that at this point in the development cycle, we're fairly frozen, so it needs some developer review, and depending on the nature of the upstream changes, may need a freeze exception.
[15:47] <persia> Is anyone subscribed to the bugs for the transmission pacakge?  If so, they'll probably take a look.  If not, it might be worth pointing out that upstream requested an upgrade to one of the people who touched the package recently, and ask if they have time to provide some feedback (as upstream devs tend to be more equal than other users)
[16:00] <mrooney> persia: hmm I don't know, I see MOTU Torrent and MOTU-P2P subscribed
[16:00] <persia> mrooney: Sounds well covered then :)
[16:01] <mrooney> persia: okay, should I remove my needs-packaging tag and replace it with upgrade?
[16:01] <persia> I'd still change "needs-packaging" to "upgrade", but other than that, let those teams work with upstream to get it updated or not.
[16:01] <mrooney> okay!
[16:11] <CarlFK> ﻿how do I ﻿ "uninstall both nvidia-glx-* and x-x-v-nv" (trying to help with https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/261977
[16:13] <james_w> I think MOTU torrent is one person at the moment
[16:15] <james_w> ah, bobbo wanted to get it started again, may be worth dropping him a note
[16:30] <persia> james_w: jdong?
[16:31] <james_w> persia: he said he was interested, but had no time, might be worth pinging him as well though
[16:31] <persia> Oh.  I thought he *was* MOTU Torrent.
[16:31]  * persia checks LP to understand more
[16:32] <persia> Maybe fta would be interested as well
[16:35] <jdong> ah, yes, motu-torrent; forgot about that again.
[16:35] <jdong> stupid busy schedule. Yeah since bluekuja left motu-torrent has been pretty crippled
[16:36] <persia> Yeah.  If someone wants to step up, the team admin can be changed, but that's probably more on-topic in #ubuntu-motu
[16:40] <mrooney> I need to learn more so I can help more :)
[16:42] <persia> mrooney: As do we all :)
[18:59] <pibe86> hello, any help for this http://paste.ubuntu.com/47845/ it happens while installing alternative cd
[19:01] <chrisccoulson> pibe86: never seen that before. which alternate CD are you using?
[19:01] <chrisccoulson> i havent done an install yet with the alternate CD so i'm a bit unfamiliar
[19:02] <pibe86> chrisccoulson: intrepid-alternate-i386 beta 5
[19:03] <pibe86> chrisccoulson: and  ubuntu-8.04.1-alternate-i386 same error
[19:03] <chrisccoulson> i'm trying an alternate CD atm. 1 second
[19:04] <pibe86> chrisccoulson: ok
[19:04] <chrisccoulson> at which stage did you get the error?
[19:04] <pibe86> chrisccoulson: install base system around 81%
[19:04] <chrisccoulson> i'm at partitioning, but i can't really commit the changes and go further without building a new virtual machine first
[19:05] <chrisccoulson> i can build a new machine but it will take a bit longer
[19:07] <pibe86> chrisccoulson: i am not using a virtual machine
[19:07] <chrisccoulson> thats ok. i just wanted to try and familiarise myself with the options for installing from the alternate CD, so I know what questions to ask
[19:12] <chrisccoulson> pibe86 - i don't experience your problem
[19:12] <chrisccoulson> what CPU do you have?
[19:15] <chrisccoulson> pibe86 - when you experience the error, could you press CTRL+ALT+F4 and have a look at the console output?
[19:19]  * LimCore wonders why is https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/268925 marked as INVALID instead say need-feedback
[19:22] <chrisccoulson> LimCore: I think Scott may have interpreted it as more of a support request. that is how I read it, because it seems you are having issues configuring kgpg
[19:22] <LimCore> what do you mean configuring kgpg?
[19:23] <LimCore> kmail should out of the box keep the entered passphrase, not keep asking it 10 times even a second later,  that is how it always worked before,  but in current ubuntu, for me, it does NOT work this way
[19:24] <LimCore> this is one problem.    and second: even applying the changes described in wiki, it still does not work it seems;   if I verify again that it does not work after using that officiall solution I linked to, should I reopen it?
[19:25] <chrisccoulson> if you feel that it was closed in error, then please feel free to reopen it, and point out again that you are experiencing this behaviour on a fresh install and that you don't think the behaviour is correct
[19:32] <pibe86> please help me!!! http://ubuntuforums.org/showthread.php?p=5807299#post5807299
[19:41] <LimCore> hi pibe86. for support, try as well ##ubuntu
[22:19] <bdmurray> Does anybody else see gnome-keyring-daemon errors in /var/log/auth.log?
[22:20] <bdmurray> on Intrepid
[22:22] <LimCore> bdmurray: I have various issues with gpg agent on 8.04... btw
[22:23] <bdmurray> sbeattie: could you check?
[22:25] <maco> LimCore: with seahorse?  i haven't upgraded to intrepid yet, but if there are seahorse bugs, i'll upgrade to take a look
[22:25] <maco> that's one of two packages with which i'm familiar
[22:26] <LimCore> maco: I use 8.04 hardy.  I was talking about kmail being unable to store openpgp passphrase; but I think I also seen some strange errors elsewhere related to gpg agent. Didnt had time to check yet
[22:28] <sbeattie> bdmurray: booting intrepid now.
[22:29] <Ampelbein> bdmurray: gnome-keyring-daemon: couldn't lookup keyring component setting ?
[22:31] <bdmurray> Ampelbein: right, failed to autolaunch D-Bus session etc...
[22:31] <Ampelbein> yeah.
[22:32] <bdmurray> looks like bug 262357
[22:33] <bdmurray> minus the whole exported home directories bit ;)
[22:34] <Ampelbein> seems so. but i did not notice any functionality regression. works fine here.
[22:36] <bdmurray> Maybe I'm looking at two different problems then
[22:40] <sbeattie> bdmurray: are you using ldap, as in bug 262357
[22:40] <Ampelbein> bdmurray: gdm[6944]: Autolaunch error: X11 initialization failed. this is what's different from my logs
[22:41] <bdmurray> Ampelbein: you don't have that?
[22:42] <Ampelbein> bdmurray: nope, i'm using mysql as authentication backend
[22:42] <Ampelbein> and no, i don't have these autolaunch messages
[22:43] <bdmurray> hmm, I see those Autolaunch errors on 2 of my systems
[22:43] <sbeattie> bdmurray: I see the autolaunch X11 errors as well.
[22:43] <bdmurray> and then I've noticed my DBUS_SESSION_BUS_ADDRESS env variable is wrong
[22:44] <bdmurray> well, I think it's wrong ;)
[22:45] <Ampelbein> and i'm an idiot. i get those autolaunch errors too, just grepped for gnome-keyring-daemon....
[22:45] <Ampelbein> mea culpa.
[22:47] <Ampelbein> bdmurray: why do you think it's wrong?
[22:47] <bdmurray> the env variable because there is no /tmp/dbus* file
[22:48] <Ampelbein> indeed.
[22:49] <sbeattie> bdmurray: I think the "abstract=" portion means that it lives outside the filesystem and in the abstract AF_UNIX namespace. See unix(7)
[22:53] <sbeattie> bdmurray: if you grep for the string in /proc/net/unix you probably will find it.
[22:55] <bdmurray> sbeattie: really?
[22:57] <bdmurray> well, great it works on one system and not the other
[23:00] <sbeattie> steve@intrepid-a5desktop-test:~$ echo $DBUS_SESSION_BUS_ADDRESS
[23:00] <sbeattie> unix:abstract=/tmp/dbus-z91CHzS0c1,guid=e5e572407af1cd1b8227044a48d17917
[23:00] <sbeattie> steve@intrepid-a5desktop-test:~$ grep -a /tmp/dbus-z91CHzS0c1 /proc/net/unix | wc -l
[23:00] <sbeattie> 50
[23:01] <sbeattie> what failure besides what's reported in the auth.log are you seeing?
[23:05] <bdmurray> sbeattie: I was looking at that seahorse bug we were talking about last week - which really isn't the same bug I'm having
[23:08] <bdmurray> sbeattie: and I think it might be related to bug 107169 too
[23:09] <bdmurray> which of course you can't see now ;)
[23:10] <sbeattie> mu
[23:11] <bdmurray> it's about bzr-dbus plugin failing
[23:11] <crimsun> note to self: 64967 is a dupe of 68659/68876
[23:11] <crimsun> ->fix released
[23:14] <LimCore> woah, 3rd crash of kde application today. wth
[23:15] <sbeattie> bdmurray: it's odd, using d-feet, I saw that gnome-keyring-daemon-wrapper was sitting on the session d-bus, but then d-feet kind of crashed when I tried to look at its objects.
[23:15] <sbeattie> bdmurray: not sure why it was registered as gnome-keyring-daemon-wrapper and not gnome-keyring-daemon...
[23:23] <bdmurray> sbeattie: d-feet?
[23:24] <sbeattie> bdmurray: it's a dbus browser.
[23:32] <LimCore> ERROR SUMMARY: 4566 errors from 50 contexts (suppressed: 14 from 2)   definitely lost: 10,968 bytes in 226 blocks.
[23:33] <LimCore> ^- while debugging a reproducable bug in krusader/xml. heh. perhaps it would be nice to introduce some quality stanrds for apps?  say, app must NOT leak to be marked as quality-appl. etc
[23:41] <crimsun> LimCore: work better done upstream :)
[23:41] <LimCore> yes, but the pressure by marking apps would be nice
[23:46] <sbeattie> bdmurray: what's in your .gnome2/keyrings/ ?
[23:47] <bdmurray> sbeattie: just login.keyring
[23:47] <sbeattie> does file read it correctly?
[23:48] <LimCore> can someone please confirm - https://bugs.launchpad.net/ubuntu/+source/krusader/+bug/209492
[23:49] <bdmurray> sbeattie: yep