[00:20] <Yfrwlf> So has anyone else noticed the bug where when you mouse over System > Preferences, and then (or immediately) mouse over Administration, it pauses for a second or so?
[00:20] <Yfrwlf> Really weird, but seems like it might be a bug. ^^
[00:21] <Yfrwlf> It's been doing that in Gnome for as long as I can remember
[00:21] <Hobbsee> Yfrwlf: sounds strange.
[00:21] <Yfrwlf> and it only does it the first time, like it's a menu loading problem, no clue
[00:22] <Hobbsee> unless it's building an index the very first time, i've no idea.
[00:22] <Yfrwlf> I'd be really surprised if I'm the only one who has seen it happen. :P
[00:23] <Hobbsee> is it just on first install, or the first time it gets done after boot?
[00:23] <Yfrwlf> maybe it's the menu freezing until all the icons in Preferences have loaded, before it will display the Administration menu.
[00:24] <Hobbsee> i would expect that's the case
[00:24] <Yfrwlf> I think it's when ever the menu isn't in RAM or something, it's after every login or after a while of not using that menu maybe?  Would have to experiment with it.  Very minor thing, but I've actually seen it freak out new users and such, it's just a cosmetic thing. ^^
[00:24] <Hobbsee> how much ram do you actually have in that machine?
[00:24] <Hobbsee> (that you're seeing it on?)
[00:25] <Yfrwlf> it happens on all different machines on all different Gnome versions that I've used for the past several years
[00:25] <Yfrwlf> though I'm sure it's less noticeable on faster machines obviously
[00:25] <Hobbsee> very strange.
[00:26] <Hobbsee> my machine's likely too high specced to see it, then.
[00:26] <Yfrwlf> wow, I can easily reproduce it on the fly, too.
[00:26] <Hobbsee> you could probably try reporting it to gnome directly, as it sounds like a gnome 'bug' that it's not optimised fully.
[00:27] <Yfrwlf> yeah, alright. ^^
[00:27] <Hobbsee> under metacity, presumably?  or compiz?
[00:28] <Yfrwlf> I created another user, test, and then logged onto test, (on this same computer), and was able to reproduce it.  After the first time though like I said, it doesn't happen anymore until you log out or possibly unless it leaves RAM.
[00:28] <Yfrwlf> I don't *think* it's the window manager, but let me check.
[00:32] <Yfrwlf> Great, now I'm just finding other bugs >.<
[00:34] <Yfrwlf> After switching to Metacity and logging in as test again, the menu bug isn't there, but maybe it's like saved in memory already or something...when I went in as test, it was Metacity.  Then I switched back to my user, switched to Compiz, and logged in as test again to find that Metacity was running.  When I then tried to turn on Compiz as test, it said desktop effects couldn't be enabled.  Oiy =P
[00:34] <Yfrwlf> fun stuff ^^
[00:37] <Hobbsee> hrm.  that wasn't friendly.
[00:37] <Yfrwlf> oh wow, even after disabling Compiz on my user, and logging into test and trying to enable it there, it won't let me.
[00:37] <Yfrwlf> What wasn't friendly?
[00:38] <Hobbsee> locking my screen on jaunty wouldn't let me unlock it again.
[00:38] <Yfrwlf> That's what I'm using too btw.
[00:38] <Yfrwlf> I haven't had that problem before though, how did you manage to do that?
[00:41] <Hobbsee> not sure.  it's probably transient, as i hadn't rebooted after some updates which it was telling me to
[00:41] <Yfrwlf> that may have been it then, I remember when you could keep on using programs even if they had been updated, but I notice some problems with doing that sometimes.
[00:42] <Hobbsee> yup
[00:43] <Yfrwlf> but, just restart X at the very least, and that should fix the screen locking problem you're having, if that's the cause of it.
[00:43] <Yfrwlf> should be using the new versions of everything at that point
[00:43] <Yfrwlf> to my knowledge
[00:44] <Hobbsee> i thought i'd done so, from the last time it locked up, but then it happened again
[00:44] <Hobbsee> ah well, will look again later
[01:32] <kylezoa> Bug #319393 to wishlist please
[01:48] <kylezoa> Bug #319776 to the lovely wishlist please
[01:49]  * Hobbsee doesn't think the first one is a wishlist item.
[01:49] <Hobbsee> and i'm surethat second one is a dupe.
[01:50] <Hobbsee> in fact, the guest account already accounts for that.
[01:52] <kylezoa> k, Hobbsee, could you please leave that note on the bug as it'll be better for you to note it
[01:53] <Hobbsee> sigh, he's left.
[01:53] <hggdh> heh
[01:53] <hggdh> shoot & run
[01:54] <Hobbsee> he could have actually *tested* it, to see that the bug reporter was mostly wrong, but no...
[01:54] <Hobbsee> lets just smack it with a 'wishlist' status, and be done with it.
[01:54] <hggdh> all one needs is to read and mis-interpret, I guess
[01:55] <hggdh> there is also one thing -- a lot of the new folks are worried of doing something wrng, and would rather somebody else did it
[01:56] <hggdh> weird. I thought the second one would be a question of capabilities
[01:57] <Hobbsee> presumably because they don't actually know what htey're doing, and suspect they're not being so helpful anyway, and don't want to get jumped on when it's wrong.
[01:58] <Hobbsee> but the first is the classic "original reporter is known competent, so please don't put rubbish (ie, it's not a bug.  BRAINSTORM IT!) on their bugs"
[01:58] <Hobbsee> which i don't think there's a solution for yet
[02:00]  * Hobbsee invalidates it, and claims it for 5-a-day
[02:11] <hggdh> heh
[07:18] <thekorn> good morning
[07:27] <dholbach> good morning
[07:36] <thekorn> hi dholbach
[07:36] <dholbach> hiya thekorn
[11:28] <pedro_> folks don't forget that today we have a hug day : https://wiki.ubuntu.com/UbuntuBugDay/20090122
[11:29] <pedro_> there's still a lot of bugs to be triaged, feel free to grab anyone and squash it
[13:11] <jan_here> I found a bug concerning powersaved, is it oky to discuss this here?
[13:55] <pedro_> there's still a lot of bugs to squash, join the fun : https://wiki.ubuntu.com/UbuntuBugDay/20090122
[13:55] <pedro_> good day MrKanister
[13:56] <MrKanister> hello pedro_
[13:59] <MrKanister> pedro_: Sorry, I have to deliver some magazines. Will be back in about two hours.
[13:59] <MrKanister> pedro_: Then I will join the fun ;). Bye
[13:59] <pedro_> MrKanister: see you later!
[15:21] <bddebian> Boo
[15:41] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek - Day 4 to kick off in #ubuntu-classroom in 19m. :-)
[16:13] <steve555> hI EVERYONE.
[16:13] <BUGabundo> hi steve555
[16:14] <steve555> Hi BUGabundo.What is the progress of triarging Firefox3.0?
[16:15] <BUGabundo> I have no idea!
[16:15] <BUGabundo> just logon
[16:15] <steve555> I haven't got it installed yet,but I have done in the past.I personally use Opera10.0 Alppha
[16:15] <BUGabundo> aint even got the courage to look into my inbox
[16:16] <steve555> I thought this was the channel to help out if we can.Which one is it?
[16:16] <BUGabundo> ask dholbach
[16:17] <dholbach> BUGabundo: about what?
[16:17] <BUGabundo> dholbach: please refer to steve555 ^^^^^^^^
[16:18] <dholbach> I have no idea about Firefox
[16:18] <dholbach> asac is the mastermind there :)
[16:18] <steve555> Where can I reach him?I have treid to get on a hug day and a even a Ubuntu classroom,but I seem to miss them,as I live in the U.K G.M.T
[16:20] <steve555> I'm curently using Kubuntu Jaunty Jackalope Alpha3.
[16:20] <dholbach> he's in here :)
[16:21] <steve555> Ok,I'll ask him.
[16:21] <steve555> asac,do you need help with Firefox3.0?
[16:23] <BUGabundo> steve555: please visit #ubuntu-mozillateam
[16:23] <steve555> Ok,thanks BUGabundo.
[16:24] <charlie-tca> steve555: The firefox hugday is today. https://wiki.ubuntu.com/UbuntuBugDay/20090122
[16:25] <steve555> Yeah I know,am I in time?it's Greenwich Mean Time where I live.
[16:27] <charlie-tca> yes, it's only 4:27pm there
[16:28] <charlie-tca> And, the bugs can be triaged anytime :-)
[16:51] <steve555> Before I go,I'm have a bit of trouble importing some keys from Launchpad.When I refrseh my repositoires with Synaptic,I get this error:: GPG error: http://ppa.launchpad.net jaunty Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7D2C7A23BF810CD5
[17:02] <pedro_> omg the graphs for the hug day are looking amazing!
[17:02] <pedro_> http://people.ubuntu.com/~brian/complete-graphs/firefox-3.0/plots/firefox-3.0-week-new.png <- wow
[17:04] <bdmurray> pedro_: see http://status.qa.ubuntu.com/qapkgstatus/firefox-3.0 for more details
[17:08] <pedro_> -300 WOW
[17:26] <asac> here
[17:27] <asac> does Martin Mai hang out here sometimes?
[17:27] <asac> pedro_: ?
[17:27] <asac> ffox 3 got 300 new bugs eliminated from yesterday to today
[17:27] <pedro_> asac: yes Mrkanister is his nickname
[17:27] <asac> thats really awesome
[17:28] <asac> https://wiki.ubuntu.com/MozillaTeam/Bugs/TriagersHandbook
[17:28] <pedro_> asac: yeah that's pretty awesome, did you looked at the graphs today?
[17:28] <asac> pedro_: the graph is not up-to-date ... NEw count is now 420
[17:28] <asac> ;)
[17:29] <pedro_> woohoo ;-)
[17:29] <pedro_> we can reduce them to less to 400, right charlie-tca, chrisccoulson ? ;-)
[17:29] <asac> pedro_: i would stick the triagers handbook in topic ... would be much more efficient if folks would remember those few points
[17:30] <pedro_> asac: alright, i'm editing the hug day page with that information
[17:30] <asac> pedro_: i will update topic... you can just stick the same info there too
[17:31] <asac> pedro_: i cannot do that
[17:31] <asac> not an op
[17:31] <asac>  /topic Ubuntu BugSquad | http://wiki.ubuntu.com/BugSquad | Documentation: http://wiki.ubuntu.com/HelpingWithBugs | Firefox NEW/Incomplete processing: https://wiki.ubuntu.com/MozillaTeam/Bugs/TriagersHandbook | If you have been triaging bugs for a while, please apply to https://launchpad.net/~ubuntu-bugcontrol/ | Want to report a bug? Read https://help.ubuntu.com/community/ReportingBugs | User support (not related to triage) is in #ubuntu
[17:32] <asac> thats what i wanted to do
[17:32] <pedro_> bdmurray: ^
[17:32] <bdmurray> on it
[17:32] <ccm> hi there
[17:32] <asac> bdmurray: wait a sec ;)
[17:32] <ccm> (from the ubuntu berlin bug jam)
[17:32] <asac>  /topic Ubuntu BugSquad | http://wiki.ubuntu.com/BugSquad | Documentation: http://wiki.ubuntu.com/HelpingWithBugs | FFox New/Incomplete processing: https://wiki.ubuntu.com/MozillaTeam/Bugs/TriagersHandbook | If you have been triaging bugs for a while, please apply to https://launchpad.net/~ubuntu-bugcontrol/ | Want to report a bug? Read https://help.ubuntu.com/community/ReportingBugs | User support (not related to triage) is in #ubuntu
[17:32] <asac> bdmurray: ^^
[17:32] <asac> shortened and adjusted case
[17:33] <asac> thanks
[17:33] <pedro_> ccm: hello there
[17:34] <bdmurray> asac: Could we get some package bug guidelines setup for firefox?
[17:36] <asac> bdmurray: just the triagers handbook should be enough
[17:36] <asac> a link
[17:36] <asac> bdmurray: and maybe a direct reference to https://wiki.ubuntu.com/MozillaTeam/NormalizedBugFormat
[17:36] <bdmurray> asac: I meant information to show when people report a bug about firefx
[17:36] <asac> bdmurray: for that lets just use the NormalizedBugFormat page ;)
[17:36] <bdmurray> Maybe a link to https://wiki.ubuntu.com/MozillaTeam/Bugs ?
[17:37] <asac> would be helpful if folks file directly in that format
[17:37] <asac> so we can foward
[17:37] <asac> yes. lets use that and the normalized format thing
[17:38] <asac> bdmurray: how do we get those instructions there?
[17:39] <bdmurray> asac: https://lists.ubuntu.com/archives/ubuntu-devel/2009-January/027206.html
[17:39] <asac> ok so not me ;)
[17:39] <asac> so lets state:
[17:40] <bdmurray> Well, you could stick a firefox file in the package-bug-guidelines folder and I'd update the instructions for it / them.
[17:40] <asac> bdmurray: package-bug-guidlines? is that abranch?
[17:40] <bdmurray> its a folder in ubuntu-qa-tools branch
[18:04] <CrownAmbassador> Hi guys. Do you think I can list these 2 bugreports together? https://bugs.launchpad.net/ubuntu/+bug/320105 and https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/319553 the last one happens to be mine.
[18:20] <charlie-tca> pedro_: I'll grab some bugs in a bit; got my 3-month old grandson right now
[18:23] <MrKanister> How often are is the status of packages updated at http://status.qa.ubuntu.com/qapkgstatus/ ?
[18:23] <bdmurray> the graphs are updated hourly
[18:25] <MrKanister> bdmurray: Thanks. And the information on the left of a package page (for example http://status.qa.ubuntu.com/qapkgstatus/firefox-3.0) ?
[18:25] <bdmurray> ogasawara: that's ^ hourly too right?
[18:26] <ogasawara> bdmurray, MrKanister:  yup I believe it is hourly
[18:26] <MrKanister> bdmurray: Maybe. If yes it gets updated in 14 minutes. Was just curious :)
[18:27] <MrKanister> thanks ogasawara
[18:27] <ogasawara> MrKanister: although I'm not positive if it on the hour or half past
[18:29] <MrKanister> ogasawara: hm. ok
[18:29] <ogasawara> MrKanister: ah, every 30min - or at least that's what it used to be
[18:30] <MrKanister> ogasawara: Don't think so because the last update was at 17:42 UTC (so more than half an hour back)
[18:31] <bdmurray> the raw data comes from http://people.ubuntu.com/~brian/complete-graphs/firefox-3.0/firefox-3.0-changes.html
[18:32] <MrKanister> bdmurray: Thanks. Maybe the data is then updated once a day
[18:33] <ogasawara> MrKanister: is there a specific stat you're noticing is not updating
[18:35] <MrKanister> ogasawara: No. As I said, I was just curious about it.
[18:36] <MrKanister> ogasawara: uh, you were right with the half an hour update. Now it reads: "Last updated at 18:10 UTC"
[18:59] <MrKanister> wow...thats what I call a BugDay
[18:59] <CrownAmbassador> Hi guys. Do you think I can list these 2 bugreports together? https://bugs.launchpad.net/ubuntu/+bug/320105 and https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/319553 the last one happens to be mine.
[18:59]  * MrKanister huggs pedro_ and charlie-tca
[19:00]  * pedro_ hugs the hug day hero MrKanister
[19:02]  * MrKanister wishes more people would start on BugDays because everyone is able to
[19:02] <bdmurray> CrownAmbassador: it's hard to tell without hardware information for bug 320105
[19:02] <CrownAmbassador> bdmurray: Thanks, I'll ask for hardware info then.
[19:13] <asac> MrKanister: hi. i added a link for ffox triaging to topic ... please take a look ;)
[19:13] <asac> and thanks for all the work :) ... i definitly owe you a few beers ;)
[19:13] <MrKanister> asac: Thank you. This is a very useful site
[19:14] <MrKanister> Unfortunately the fun is nearly over ;)
[19:14] <asac> MrKanister: most important for the further upstream triage is to get the description in the normalized format mentioned there
[19:14] <asac> MrKanister: how comes?
[19:14] <MrKanister> asac: No problem. I like to work with nice people :)
[19:15] <MrKanister> asac: No worries. I mean for the bug day this week
[19:15] <asac> heh
[19:15] <asac> sure
[19:15] <asac> but i think i saw your mails outside of hug days ;)
[19:15] <MrKanister> asac: What do you mean? (maybe my english is to bad)
[19:16] <MrKanister> oh..you mean nromal bugs?
[19:16] <MrKanister> *normal
[19:16] <asac> MrKanister: yeah ;)
[19:16] <asac> https://wiki.ubuntu.com/MozillaTeam/NormalizedBugFormat
[19:17] <MrKanister> hm...with that information I think we should do another BugDay on firefox
[19:18] <MrKanister> we nearly halved the number of "new" bugs
[19:19] <asac> MrKanister: true. there will surely be more new bugs.
[19:20] <MrKanister> asac: Oh, yes. I very much hope more people will participate on BugDays because it is not difficult. Everyone can do it
[19:21] <asac> thats why i tried to keep the handbook as simple as possible. New/Incomplete bugs can all be processed really easily
[19:21] <asac> and Confirmed too most of the time
[19:22] <asac> at least for firefox i cannot really forward bugs wher ei have to digg the important info out of the lengthy discussion.
[19:22] <MrKanister> asac: yup, the handbook is really awesome ;)
[19:23] <asac> MrKanister: how do you reach the triagers? just the hug day announce mail?
[19:23] <MrKanister> asac: Yes, via some mailing-lists -> https://wiki.ubuntu.com/UbuntuBugDay/Organizing#Announcement%20E-mail
[19:24] <MrKanister> asac: I hate the bug tracker of mozilla, too
[19:24] <MrKanister> asac: The gnome but tracker is soo much more user friendly
[19:25] <asac> MrKanister: what exactly is more user friendly?
[19:25] <MrKanister> asac: *the gnome bug tracker
[19:25] <MrKanister> asac: (sorry, typo)
[19:25] <asac> MrKanister: yes, but makes that more user friendly?
[19:25] <asac> personally, i think processing bugs for gnome is easier because you have lots of small apps
[19:25] <asac> with a small number of bugs
[19:26] <asac> so you can usually see everything on one or a few patges
[19:26] <MrKanister> asac: I mean it is easier to use, so it's "user friendly"
[19:26] <asac> the tricky thing about firefox is that you have to find the right component in bugzilla to get any sensible search results
[19:26] <MrKanister> (or doesn't that phrase exist in English?)
[19:26] <asac> MrKanister: yes, but both is bugzilla ... so my question is: why is it easier to use?
[19:27] <asac> my guess is that its easier to use because of the reasons i gave above
[19:27] <MrKanister> asac: Oh, your are right, it's because of a better overview over the packages
[19:28] <asac> MrKanister: sure. thats hard to do for a huge app like firefox. if you want to triage bugs upstream and wonder about which component to file against/look just ask
[19:28] <asac> at best in #ubuntu-mozillateam
[19:29] <MrKanister> asac: Thanks. Will bookmark that
[19:29] <asac> thanks
[19:29] <asac> cu then ;)
[19:30] <MrKanister> asac: See you
[19:32] <steve555> Hi guys,I'm having trouble uploading traces produced by Apport-qt to Launchpad.It comes up with this error:
[19:32] <steve555> Could not upload report data to crash database:
[19:32] <steve555> <urlopen error The write operation timed out>
[19:36] <MrKanister> asac: I wonder if https://wiki.ubuntu.com/MozillaTeam/Bugs/TriagersHandbook should replace https://wiki.ubuntu.com/MozillaTeam/Bugs/Procedures which is linked on https://wiki.ubuntu.com/MozillaTeam/
[19:36] <maco> steve555: apport hasnt worked since jaunty started
[19:36] <maco> steve555: just file the bug manually and attach a retrace
[19:37] <steve555> Is there another package I could use to upload?
[19:37] <maco> your web browser
[19:39] <steve555> Hmmm,I'll give it a go,is it ok to attach the .crash to the bug report that apport created?
[19:39] <charlie-tca> steve555: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/314212 ; even better, add to this one
[19:39] <maco> use apport-retrace to get just a stack trace
[19:40] <maco> (that's what i was told to do when i asked a couple days ago)
[19:43] <hggdh> so it is still broken?
[19:43] <maco> yes
[19:44] <hggdh> sigh
[19:44] <bdmurray> I'll look at it today
[19:44] <hggdh> yay, just ran it. At least now I do not get a file://... URL, but the (common) url error
[19:44] <bdmurray> hggdh: which one?
[19:45] <hggdh> urlopen timed out
[19:47] <bdmurray> hggdh: when uploading?
[19:47] <bdmurray> the last comment in bug 314212 has a workaround that might be worth trying
[19:48] <hggdh> let me run it again
[19:48] <asac> MrKanister: not sure. procedures is definitly work-in-stalled-progress ... but is suppsoed to be more complete than handbook
[19:49] <asac> but we should definitly link the handbook from there
[19:49] <MrKanister> asac: ok, a link would be good
[19:50] <hggdh> darn! now I am back to file:// on the FFox call
[19:51] <bdmurray> hggdh: its still an improvement though ;)
[19:51] <hggdh> bdmurray, heh. At least the blob was uploaded
[19:57] <chrisccoulson> hey mrkanister, are there any more firefox bugs left to triage ;)
[19:57] <MrKanister> chrisccoulson: hehe, hundreds :)
[19:58] <MrKanister> chrisccoulson: But we managed to halve the new bugs
[19:58] <chrisccoulson> thats good. sorry i haven't helped out much - been busy doing some other stuff
[19:59] <MrKanister> chrisccoulson: no problem. I think many also preferred the UbuntuDeveloperWeek to triaging bugs :D
[20:00] <chrisccoulson> i'd completely forgotten about that. i wouldn't have minded getting involved
[20:01] <MrKanister> chrisccoulson: You forgot the DeveloperWeek? That's sad, I was a great event and I learned  alot
[20:01] <MrKanister> *it was
[20:01] <chrisccoulson> which sessions did you go along too?
[20:02] <asac> MrKanister: check  https://wiki.ubuntu.com/MozillaTeam/Bugs/Procedures please
[20:02] <MrKanister> chrisccoulson:  The Launchpad API, Baazar for packaging, Boot performance, etc
[20:02] <maco> i forgot too, what with the couple million people converging on every spare bit of sidewalk and empty chair in every restaurant/cafe around my apartment
[20:03] <MrKanister> asac: Looks great. That way we don't have a page without content ;) Thanks
[20:04] <chrisccoulson> 3 guesses where maco lives
[20:04] <chrisccoulson> lol
[20:05] <maco> ^_^
[20:05] <maco> i lack internets in my apartment, so those cafes are somewhat necessary for me to get online
[20:07] <chrisccoulson> that's not good. i couldn't live without my internet connection :(
[20:07] <maco> my old roommate moved out and took the internet with her. i get new internet tomorrow.
[20:07] <chrisccoulson> thats good then. i bet you're looking forward to that!
[20:07] <maco> yes
[20:15] <andersk> Is anyone interested in looking at the one-line patch in bug 296925?
[20:16] <maxb> bug 319204 was just mentioned in #ubuntu-motu - IIUC it doesn't make sense to say "Please sync from DEHS". Is there a standard phrasing for a "Please update to newer upstream" bug?
[20:30] <maxb> Is the needs-packaging tag appropriate for a "please package new upstream version" bug?
[20:35] <maco> i think needs-packaging is just for new (not in the archive at all) packages
[20:37] <savvas> maxb: bug number?
 bug 319204 was just mentioned in #ubuntu-motu - IIUC it doesn't make sense to say "Please sync from DEHS". Is there a standard phrasing for a "Please update to newer upstream" bug?
[20:38] <savvas> https://wiki.ubuntu.com/SyncRequestProcess
[20:40] <savvas> 0.5.3 ?
[20:45] <savvas> maxb: I linked it to the debian new upstream request
[20:46] <savvas> maxb: I'll try and see if it's easy to upgrade
[20:46] <maxb> You make a good point, linking it makes sense, but I was wondering what to do to the bugtitle, since it's falsely masquerading as a sync request at present
[20:48] <savvas> well there's no upstream debian package yet :P
[20:49] <savvas> Can you change it to something appropriate and set the needs-packaging tag?
[20:49] <savvas> I think it's ok to use it in this case
[20:53] <savvas> hm.. lool..
[20:55] <savvas> maxb: I the user with nickname lool in freenode is the maintainer of flumotion. In #ubuntu-devel or #ubuntu-motu probably
[20:55] <savvas> -I
[21:10] <savvas> maxb: let me know if you talk with the maintainer
[21:11] <maxb> I don't really mind, actually my interest in this is mainly limited to not having a non-sync bug masquerading as a sync bug
[21:11] <maxb> :-)
[21:13] <savvas> ok, but it happened to me twice to upgrade new packages and then the maintainer comes and says "Oh, I've had this packaged all along, I just forgot/been busy/some excuse here"
[21:39] <thekorn_> bdmurray, what do you think, should we workaround bug 314212 and temporary increase the timeout in storeblob.py?
[21:43] <bdmurray> thekorn_: yes, it seems like the fastest solution
[21:44] <thekorn_> bdmurray, ok, let me prepare a patch
[21:59] <thekorn_> bdmurray, I think this is the best solution: http://paste.ubuntu.com/108389/
[22:00] <thekorn_> but it is untested on jaunty
[22:01] <hggdh> thekorn_, no timeout is dangerous
[22:01] <thekorn_> hggdh, why, that's the default
[22:01] <hggdh> this is then a bad default. Never to timeout can cause some other problems
[22:02] <hggdh> instead set it -- say -- to 180 seconds.
[22:02] <hggdh> never timeout -> leads to hanging
[22:02] <thekorn_> hggdh, so this need to be fixed in python itself
[22:02] <hggdh> probably, I agree. But, right now, I like your approach, at least it bypasses the issue
[22:03] <hggdh> a very low timeout is as bad as a very large timeout
[22:03] <Rocket2DMn> hey guys, when youre finished with your current debate, can you have a quick look at bug 319825 and let me know if you think its a kernel issue or a problem with NM (see daemon.log).  No rush.
[22:03] <hggdh> thekorn_, it is just my opinion
[22:04] <thekorn_> hggdh, yeah, I totally agree with you,
[22:05] <thekorn_> but since launchpad is "a bit slow" sometimes, I'm unable to judge which is the best timeout
[22:05] <chrisccoulson> Rocket2DMn - it would be nice to see the output of "lshal" for that bug report
[22:05] <Rocket2DMn> alright chrisccoulson , ill ask for that, what specifically are we looking for in that?
[22:07] <chrisccoulson> i haven't checked the whole report yet, but any object with the capability "killswitch"
[22:07] <chrisccoulson> just to get a more complete picture of the hardware
[22:08] <chrisccoulson> i think from the description that its not a nm bug
[22:08] <thekorn_> bdmurray, I'm going to sleep now, I would be nice if you could apply the patch, otherwise I will do it tomorrow morning,
[22:08] <thekorn_> feel free to adjust the timeout
[22:09] <bdmurray> thekorn_: okay, I think using something other than none would be best
[22:09] <thekorn_> if you think it makes more sense
[22:09]  * hggdh has had some very bad experiences with no TCP timeouts
[22:10] <Rocket2DMn> chrisccoulson, based on how the user gets around the behavior by removing a module, it seems that it is kernel.  However, daemon.log has problems with NM which had me thinking that maybe NM isn't communicating well with the correct driver/module
[22:10] <bdmurray> thekorn_: thanks for the patch
[22:10] <thekorn_> np, no big deal
[22:12] <Rocket2DMn> chrisccoulson, there is also a link to a bug in daemon.log that is still Confirmed against NM, whereas everything else seems to be fixed in intrepid.
[22:12] <Rocket2DMn> im not sure what to make of that
[23:13] <chrisccoulson> hi Rocket2DMn - sorry, i had to disappear somewhere
[23:13] <Rocket2DMn> thats ok
[23:13] <chrisccoulson> i'll take another look in a second
[23:14] <Rocket2DMn> ok, theres really no rush
[23:14] <Rocket2DMn> ill be here
[23:14] <savvas> someone set the bug #319204 as triaged please, I'm sending a new upstream package to debian as we speak
[23:16] <charlie-tca> savvas: wishlist?
[23:16] <savvas> charlie-tca: yes, thanks :)
[23:17] <charlie-tca> You are welcome. done
[23:17] <savvas> a really weird package
[23:17] <charlie-tca> Yeah, it happens
[23:18] <savvas> It probably needs some adjustments, but at least I made it a bit easier for the maintainer :)
[23:19] <charlie-tca> My thought is every bit helps :-)
[23:21] <chrisccoulson> Rocket2DMn - the bug report number referenced in that reporters daemon.log is just displayed because NM found an unmanaged device (a device specified in /etc/network/interfaces). the "state CONNECTED forced" bit just means that NM will tell any application which asks that the particular connection is connected, regardless of the actual state of the connection
[23:21] <chrisccoulson> it seems that the killswitch state from HAL doesn't get updated
[23:22] <chrisccoulson> it would probably be good also to run "lshal -m", then toggle the killswitch and see if anything changes state
[23:22] <seb128> chrisccoulson: hi
[23:22] <chrisccoulson> hi seb128
[23:22] <seb128> chrisccoulson: is the new mixer applet working now for you?
[23:23] <chrisccoulson> not entirely
[23:23] <seb128> chrisccoulson: and are your session dialog correctly themed since the gnome-session update?
[23:23] <seb128> chrisccoulson: is it starting correctly rather
[23:23] <chrisccoulson> 1 second - i'll try that in a moment
[23:23] <chrisccoulson> the volume control actually appears to be suffering a race with pulseaudio
[23:23] <chrisccoulson> the status icon doesn't update when pulseaudio comes on and off-line
[23:24] <chrisccoulson> if the applet starts before pulseaudio, no icon displays
[23:24] <chrisccoulson> theres a report upstream somewhere
[23:24] <seb128> ok, so there is probably a race during session start there
[23:24] <chrisccoulson> it seems so. the applet and pulseaudio start in the same phase
[23:24] <seb128> I get an error in .xsession-errors which seems to indicate that the applet is started before the sound server there
[23:25] <chrisccoulson> yeah, i get that too. i tried writing a patch, but i cant get it to work
[23:26] <chrisccoulson> gnome bug 564311 is the applet problem
[23:27] <seb128> right, the new comment seems to be the issue
[23:27] <chrisccoulson> pulseaudio started before gnome-session in intrepid, but that's not a good solution
[23:28] <Rocket2DMn> chadwik, what should the reporter do when monitoring in order to trigger the killswitch?  is that a keyboard function key, or removal of the module, or something else?
[23:28] <Rocket2DMn> chrisccoulson, ** ^
[23:29] <chrisccoulson> Rocket2DMn - they can run "lshal -m" in a terminal and then physically move the killswitch. if it changes state, then the reporter will see some output on the terminal
[23:29] <chrisccoulson> if he doesn't, then it's almost certainly a kernel bug
[23:29] <chrisccoulson> seb128 - i see the problem with gnome-session dialog too
[23:29] <seb128> chrisccoulson: ok, good, I need to ping vuntz about it
[23:30] <seb128> the dialog is a distro patch, I need to try if the upstream dialog get the same issue
[23:30] <chrisccoulson> yeah, thats a good idea
[23:30] <chrisccoulson> i might try building it without in a bit
[23:31] <Rocket2DMn> what do you mean physically move the killswitch?  i guess i dont fully understand what a killswitch is then.  i thought this was like a power switch, though laptops dont typically have an actually switch, they use a key combo or a dedicated button i guess
[23:31] <chrisccoulson> ah, you might be correct
[23:32] <maco> Rocket2DMn: sometimes they're slidey things
[23:32] <chrisccoulson> i got the impression that whatever button or switch he was using actually physically turned the RF off. he seems to suggest that
[23:32] <Rocket2DMn> hey maco, i dont think ive ever seen a laptop with a slide power switch for wireless
[23:32] <Rocket2DMn> i suppose they are out there ethough
[23:32] <chrisccoulson> my old company dell had a slider
[23:33] <Rocket2DMn> nice
[23:33] <dtchen> rfkill switches are increasing massively in popularity
[23:33] <chrisccoulson> i don't have a laptop anymore to know:(
[23:33] <chrisccoulson> new company won't give me one!
[23:33] <chrisccoulson> cheapskates
[23:34] <Rocket2DMn> so we want the user to toggle with killswitch while the acer_wmi module is loaded then right?
[23:34] <chrisccoulson> i think so
[23:35] <Rocket2DMn> ok, what if something shows when he does it then?
[23:35] <chrisccoulson> it depends what shows i suppose
[23:35] <chrisccoulson> if the state of the killswitch changes then it might be a NM problem. but i think thats unlikely having read the description
[23:36] <Rocket2DMn> when i toggle on my laptop, it doesnt say anything about a killswitch, but it shows something else about ButtonPressed = wlan
[23:36] <seb128> chrisccoulson: http://bugzilla.gnome.org/show_bug.cgi?id=567958
[23:37] <dtchen> chrisccoulson: were you referring to bug 319443 earlier?
[23:37] <chrisccoulson> seb128 - that makes sense. so, it seems like it's definately an upstream issue unless the reporter is a jaunty user
[23:38] <seb128> chrisccoulson: there is a screenshot and that's the upstream dialog
[23:38] <seb128> chrisccoulson: and he's using jhbuild
[23:38] <chrisccoulson> ah, ok
[23:38] <Rocket2DMn> alright chrisccoulson , thanks for the help.  i expect the user will get back to us by tomorrow
[23:38] <chrisccoulson> dtchen - thats the one. but it should be a gnome-media bug. the applet should refresh the status icon when pulseaudio loads or disappears really
[23:42] <maco> Rocket2DMn: the HP Mini netbook, as dtchen discovered by accident 2 days ago, has a slidey switch for both wifi and power. bump the slidey thingy, and the computer turns off. oddly, you have to hold the switch in the pushed position to turn it on, but just bump it to shut it off
[23:43] <dtchen> the wifi rfkill is also broken in Windows
[23:43] <maco> on that hp mini you were playing with?
[23:43] <dtchen> you can do nefarious things with it in every OS, actually, due to the wiring
[23:45] <Rocket2DMn> maco, that is brilliant design
[23:46] <maco> oh, i didnt phrase that clearly. there are two slidey switches. 1 for each, 1 on each side of the front edge of the laptop, where your wrist goes
[23:47] <Rocket2DMn> even better!
[23:47] <dtchen> the rfkill is on the right; the power, on the left
[23:49] <Rocket2DMn> why cant they just use an old fashioned button for power