[02:11] <bigbash> ping Cheesehead
[02:17] <Cheesehead> bigbash: pong
[02:18] <bigbash> I was just going to leave a message for you
[02:18] <bigbash> I have a favor to ask please
[02:19] <bigbash> I am being summoned by my family to a baptism tomorrow and most likely won't' be back in time for the bug jam :( Do you think you might be able to be the facilitator/mentor?
[02:19] <Cheesehead> Consider it done.
[02:19] <bigbash> I'm not very happy I have to go, I'm still waiting to power to come back on at work so we can get our servers back up
[02:20] <bigbash> I appreciate it :)
[02:20] <Cheesehead> Are you asking for a just-in-case? Or do think it's pretty realistic you will be late/absent?
[02:20] <bigbash> pretty realistic
[02:20] <Cheesehead> No problem.
[02:21] <bigbash> I really appreciate it
[02:21] <Cheesehead> Family time is more important than anonymous internet geeks...
[02:21] <Cheesehead> ...or so my spouse keeps telling me.
[02:21] <Cheesehead> I believe her.
[02:21] <bigbash> ha, that's what my wife and parents said
[02:22] <Cheesehead> We can geek out on IRC anytime.
[02:22] <Cheesehead> Family time is rarer and wonderful.
[02:22] <bigbash> well I'll be reading the logs when I get back so I can learn from the master on how to facilitate a bug jam
[02:23] <Cheesehead> You'll need to watch a *real* master at work, then. I'm just the guy show showed up and lost the coin toss.
[02:23] <Cheesehead> /show/who
[02:24] <Cheesehead> And who apparently cannot spell
[02:24] <bigbash> I love the analogy
[02:24] <Cheesehead> If you saw the Brainstorm Jam, you'll see the participants did all the real work
[02:25] <bigbash> Thanks again, I'm going to head to bed, up early to check on the power situation for work before I get ready and head down to Milwaukee
[02:25] <Cheesehead> G'night
[02:25] <bigbash> I started reading the logs, but I didn't finish had to go to inlaws
[02:25] <bigbash> night everyone
[12:54] <Cheesehead> Event Reminder: Wisconsin LoCo is running an IRC Bug Jam, Sunday 1700 UTC (four hours from now), in this channel. Great training opportunity for people new to bugs. If you have a favorite bug, bring it along!
[14:08] <Cheesehead> Test: Bug 828346
[14:08] <Cheesehead> heh heh heh
[15:07] <trinikrono> bug jam?
[15:08] <trinikrono> i think i am 2 hours early lol
[15:18] <Cheesehead> trinikrono: Indeed, 1:42 from now
[15:44] <lostson>  hope you have a good turnout and squash some bugs
[16:01] <Cheesehead> lostson: Thanks
[16:33] <Cheesehead> Event Reminder: Bug Jam in this channel in 0:27
[16:46] <yotux> Cheesehead:  Thanks,  are we going to use two channels or just one like yesterday
[16:48] <Cheesehead> yotux: Let's start with one, and spread out as-needed
[16:48] <yotux> Cheesehead: okay
[16:50] <Cheesehead> We'll need to see how many new-to-bugs participants we have, and how many experienced-jump-right-in folks
[16:52] <yotux> Cheesehead: I understand it was fun yesterday,  bug are a little more scary to mean.  I am printing the triage guide at the moment to go over again
[16:52] <yotux> sorry I can't seem to type this morning  bugs are scary to me
[16:53] <Cheesehead> That's what makes the group-format nice. Nobody needs to know everything, and there's time to look stuff up
[16:53] <Cheesehead> ...and use the bathroom and eat lunch, etc
[16:54] <ashams> yotux: Hi, I never heared about such guide "the triage guide"
[16:54] <Cheesehead> ashams: https://wiki.ubuntu.com/Bugs/HowToTriage
[16:55] <Cheesehead> You don't know about it until somebody tells you.
[16:55] <yotux> ashams:  as cheeshead said https://wiki.ubuntu.com/Bugs/HowToTriage/
[16:55] <EgyParadox> did the ugj start?
[16:55] <Cheesehead> Not really, we're all just eager!
[16:55]  * Cheesehead goes to #ubuntu-bugs to give the 5-minute warning
[16:56] <ashams> Cheesehead: thanx, I assumed they finally made a consistent PDF :D
[16:56] <yotux> ashams:  it fits nicely into 10 pgs
[16:56] <yotux> I used lib office to paste and print
[16:57] <Cheesehead> The types of bugs change over time, so it's a dynamic guide.
[16:57] <Cheesehead> A few years ago, there were a lot more X and pulseaudio and printing bugs
[16:58] <trinikrono> i just got hggh to edit it
[16:59] <trinikrono> so it has a new piece in the section invaliditing
[16:59] <Cheesehead> trinikrono: Great! That's changed since I last invalidated a bug...I learn more about bugs each time I touch one.
[17:00] <Cheesehead> ..
[17:00] <Cheesehead> Hello, everyone here for the Wisconsin Bug Jam.
[17:00] <Cheesehead> Activity in this channel is logged - you can get the logs at http://irclogs.ubuntu.com/2011/09/04/%23ubuntu-us-wi
[17:00] <Cheesehead> All abilities are welcome, no experience necessary!
[17:00] <Cheesehead> ..
[17:00] <Cheesehead> Let's see how many participants we have here. Could everyone active in this channel please give a response?
[17:00] <trinikrono> +1
[17:00] <yotux> Here +2
[17:01]  * Cheesehead laughs
[17:01] <Cheesehead> I know we have more than that. Lag, perhaps.
[17:01] <Cheesehead> Everybody else, feel free to jump in!
[17:01] <ashams> o/
[17:01] <Cheesehead> There are a few goals here today:
[17:01] <Cheesehead> 1) Meet new people and have fun
[17:01] <Cheesehead> 2) If you brought a bug along, work it together
[17:01] <Cheesehead> 3) Learn how to Triage some of the wide variety of bugs
[17:01] <Cheesehead> 4) If you're new to bugs, learn the life cycle of bugs, the tools, and where to begin
[17:02] <Cheesehead> You *don't* need to be a bug guru already! The great thing about working together is that everybody learns
[17:02] <Cheesehead> ..
[17:02] <Cheesehead> SETTING UP
[17:02] <Cheesehead> A couple questions to gauge the expertise level in the room - feel free to throw out answers:
[17:02] <Cheesehead> Question: Did anybody bring a favorite bug that they want to work?
[17:02] <Cheesehead> Question: Does anybody here consider themselves pretty experienced with any kind of bugs?
[17:02] <Cheesehead> Question: Is anybody here interested in any particular kind of bug?
[17:03] <trinikrono> i just applied to bug control
[17:03] <trinikrono> o.o
[17:03] <yotux> didn't bring a bug,  new / some apport experience, open minded
[17:04]  * trinikrono goes looking for a bug
[17:05] <Cheesehead> ashams: How much bug experience do you want to have?
[17:05] <ashams> Cheesehead: a lot
[17:05] <Cheesehead> All right!  (Shallow end first)
[17:07] <ashams> Cheesehead: Have a nice dreams :D
[17:08] <yotux> I know what a lauchpad account is
[17:08] <trinikrono> go ahead
[17:08] <Cheesehead> Let's start with an easy one: Bug 828346
[17:08] <Cheesehead> Jump in and share your thoughts.
[17:08] <trinikrono> ok
[17:09] <Cheesehead> We'll reach a consensus before acting
[17:09]  * trinikrono raises hand
[17:09] <Cheesehead> trinikrono: go ahead anytime
[17:09] <trinikrono> no apport info!
[17:09] <Cheesehead> Is it a crash?
[17:09] <Cheesehead> (apport usually only generates a report during a crash)
[17:10] <yotux> seems the package is wrong
[17:10] <Cheesehead> yotux: Good eyes!
[17:10] <Cheesehead> It indeed lacks a package!
[17:10] <Cheesehead> What else?
[17:10] <ashams> lacks files
[17:10] <yotux> also the doc bar is not directly controlled by nvidia package.
[17:11] <Cheesehead> yotux: Great spotting!
[17:11] <yotux> what package did the user install?
[17:11] <Cheesehead> Perhaps we have an inexperienced reporter?
[17:11] <yotux> I would ask what package was installed
[17:11] <Cheesehead> What package would an inexperienced user claim 'recommends' a proprietary video driver?
[17:12] <yotux> I would assume this
[17:12] <yotux> but we can't send assumptions to devs / upstream
[17:12] <trinikrono> jockey?
[17:12] <Cheesehead> trinikrono: Yes!
[17:13] <yotux> I would says ask for me info.  wait a while and then possible invalid
[17:13] <Cheesehead> Possible.
[17:13] <Cheesehead> Let's explore Jockey for a second.
[17:13] <Cheesehead> Imagine you are the user.
[17:14] <Cheesehead> Jockey tells you to install NVIDAI proprietary
[17:14] <Cheesehead> You restart, and video is great...
[17:14] <Cheesehead> But now your FN-hotkeys  stop working
[17:14] <Cheesehead> Could this be what the user is trying to say?
[17:15] <yotux> It could be,   the screen shot makes it look like even gui stopped working
[17:15] <Cheesehead> trinikrono, ashams: What do you think?
[17:16] <trinikrono> i think
[17:16] <trinikrono> it sounds the same
[17:16] <trinikrono> but wont the nvidia package be at fault
[17:16] <trinikrono> and not jockey?
[17:16] <ashams> Cheesehead: don't know, maybe Xorg needs reconfig?
[17:17] <Cheesehead> trinikrono: Excellent point!
[17:17] <Cheesehead> How can we help the user narrow the possible problems?
[17:17] <trinikrono> try the nouveo driver :D
[17:18] <Cheesehead> Let's try something else - somebody try a quick Google search for the keywords. See if any similar complaints pop up.
[17:19] <Cheesehead> SOmebody else, try searching the Launchpad bugs, see if this might be a duplicate of an already-reported issue
[17:19] <trinikrono> you mean to search for similar bugs
[17:19] <Cheesehead> trinikrono: Correct!
[17:19] <ashams> Cheesehead: Why did he think that changing system name would help?
[17:20] <trinikrono> yes i wondered about that also
[17:20] <Cheesehead> ashams: People do all kinds of strange stuff.
[17:20]  * trinikrono needs to goto the grocery for 20mins brb sorry!
[17:20] <Cheesehead> trinikrono: See you back soon!
[17:21] <Cheesehead> When I have a problem, I do strange stuff, too.
[17:21] <Cheesehead> Then, later, I wonder - why did I do that?
[17:21] <Cheesehead> Another great place to check is https://wiki.ubuntu.com/Bugs/Responses
[17:22] <Cheesehead> to see if any similar class of bugs already has a prepared response
[17:23] <yotux> I have something close bug 128452
[17:25]  * Cheesehead is reading it...
[17:26] <ashams> Cheesehead: found a lot on lp, but none of them the same as ours
[17:27] <Cheesehead> Okay, so seems like nothing close enough to be considered a duplicate yet.
[17:27] <Cheesehead> What's your impression - is this really a bug? Or is it a support request?
[17:28] <yotux> I would lean toward support
[17:28] <ashams> Support reques
[17:28] <ashams> request*
[17:28] <ashams> is it in acpi pkg?
[17:28] <Cheesehead> Could it be a bug in the NVIDIA driver?
[17:28] <Cheesehead> Or int he way the kernel uses the driver?
[17:28] <ashams> Nvidia works fine
[17:29] <ashams> when the Nvidia got installed it changed some config
[17:29] <ashams> maybe in xorg or acpi I assume!
[17:29] <Cheesehead> So perhaps he should revert to the open driver and see if the issue goes away?
[17:29] <Cheesehead> ashams: Excellent point!
[17:29] <yotux> agree
[17:30] <ashams> let's order him to uninstall Nvidia then install open driver
[17:31]  * ashams brb after 10 mins, sorry
[17:31] <Cheesehead> ashams: See you back in 10
[17:31] <Cheesehead> !
[17:31] <Cheesehead> (oh, no, everybody's leaving!)
[17:32]  * Cheesehead laughs
[17:32] <yotux> Sorry I'm still here
[17:32] <Cheesehead> Well, what do you think we ought to do with the poor fellow?
[17:33] <yotux> I would say he need to revert to open source driver
[17:33] <yotux> See if this help out
[17:33] <yotux> I also noticed he install a custom doc bar on the button
[17:33] <Cheesehead> I missed that!
[17:33] <yotux> Other software could be effecting configs.  Start with open source driver
[17:34] <yotux> https://launchpadlibrarian.net/77473344/Screenshot-3.png
[17:34] <yotux> Volume doesn't appear disabled just muted
[17:34] <Cheesehead> He heh. A doc bar that undoes all the Unity design work...
[17:34] <Cheesehead> hi, komputes!
[17:35] <komputes> hi Cheesehead
[17:35] <Cheesehead> we were just admiring bug 828346
[17:36] <Cheesehead> yotux: Do you think it's possible that one of tose other cusomizations may be trapping the FN-keys?
[17:36] <yotux> Cheesehead: I not sure how the dock bar works
[17:36] <komputes> Cheesehead: looking...
[17:36] <yotux> Cheesehead:  it could change the way gnome interacts
[17:37] <Cheesehead> Nor I. If it were my system, I would revert to working, and install one-at-a-time untill it breaks...
[17:37] <Cheesehead> A few iterations in different order until I caould isolate the culprit
[17:37] <yotux> Cheesehead: I would agree
[17:38] <Cheesehead> ...assuming that installing something really is the culprit
[17:39] <yotux> Cheesehead:  https://help.ubuntu.com/community/CairoDock
[17:39] <yotux> looks like this is the doc bar he installed
[17:40] <komputes> Cheesehead: would be useful to get the hardware info. assign to linux and ask for apprt-collect bugnumber
[17:40] <Cheesehead> komputes: Is there a clue that this is a kernel issue?
[17:41] <komputes> Cheesehead: I was saying that just to get the hardware info, in fact these should be two seperate bugs AFAICT
[17:42] <Cheesehead> komputes: Whew. I questioned my grip on reality there for a moment!
[17:43] <yotux> so we need more info to proceed
[17:43] <yotux> I would say leave user a comment for more info,  possible even give instruction on how to get more info
[17:44] <Cheesehead> yotux: Agreed. I always try to hand-hold the user along the next step if more info is needed.
[17:44] <Cheesehead> If the user is new to the process (and who han;t been?), then how are they supposed to knw?
[17:45] <yotux> I myself am not sure what commands to tell him to run
[17:45] <yotux> I use apport to report most / all of my bugs
[17:46] <komputes> it's highly likely this is hardware specific
[17:46] <Cheesehead> Well, for the hardware data collection, I suppose 'apport-collect 828346'
[17:47] <Cheesehead> komputes: Do you think it's worthwhile for the user to check for an install conflict? The NVIDIA driver? Cairo-dock?
[17:48] <komputes> ask for apport info, mark incomplete.
[17:48] <komputes> and subscribe for the follow-up
[17:48] <crog> Cheesehead: hey there
[17:48] <Cheesehead> crog: Welcome!
[17:48] <Cheesehead> crog: Just arrived? Or been following?
[17:48] <crog> just arrived, but read everything up to now...
[17:49] <komputes> I would check (if the user has many customizations) to see if it's reproducable in a neutreal testing environment such as a USB installation or LiveCD (latter causing issues if testing nvidia binary)
[17:50] <Cheesehead> So apport info, check for reproducability, mark incomplete, assign to Linux, subscribe for follow-up?
[17:50] <Cheesehead> ...advise submitter to check for reproducability...
[17:50] <yotux> Cheesehead:  agree
[17:51] <crog> newbie question:  Does apport help if there wasn't a crash?
[17:51] <Cheesehead> Apport can be run manually
[17:51] <Cheesehead> It helps in some situations other than crashes
[17:51] <Cheesehead> Like gathering hardware info
[17:52] <Cheesehead> Ready for the next one?
[17:52] <crog> got it - we need to ask the submitter to run it on his machine, and we'll get config details....
[17:52] <Cheesehead> ..
[17:52] <Cheesehead> Next: Bug 831647
[17:53] <Cheesehead> This seems like a pretty easy one at first glance.
[17:54] <ashams> Cheesehead: Hi again, Ready for the next one
[17:55] <Cheesehead> Welcome back! We're admiring Bug 831647
[17:55] <crog> 3rd posted text file: couple local settings are set to gl_ES, but LANG still shows en_US.
[17:56] <crog> Is next step to try an reproduce?  (or possibly some searching first?)
[17:57] <yotux> first set would be to reproduce
[17:57] <ashams> I think that he's not using the right way, so let's advice him first
[17:57] <crog> also first sentence says: "trying to set language, and havn't found a proper way"
[17:57] <crog> So probably look for documentatoin...
[17:58] <yotux> also this is alpha distro so how important is this
[17:58] <yotux> suggest doc,  but doc may not be done yet if doc team hasn't gotten to it
[17:58] <Cheesehead> crog: I think you found a vital piece of evidence in that text file.
[17:59] <Cheesehead> Many locale settings were changed, but the system language was still en_us, not gl_es
[17:59] <yotux> I now see that
[17:59] <crog> regarding docs - I suspect something like "how to change your language" doesn't really change much from version to version
[18:00] <crog> community docs:  https://help.ubuntu.com/community/SwitchingLanguages
[18:01] <Cheesehead> I don't see the language-support-gl package in his list of installed packages
[18:01] <crog> This says.... this language will be used for newlyl created users, but not for your future sessions.
[18:01] <crog> To change for your next session, you need to change it from your login screen.
[18:02] <crog> I have 11.10 in a virtual machine.  Is it worth taking the time to follow these steps and see if there are any problems?
[18:02] <yotux> the names have changed and the structure has changed also
[18:03] <crog> Or should we just point the user to this wiki page?
[18:03] <yotux> I would say refer to wiki
[18:03] <yotux> its easy to get to the right place from there
[18:03] <yotux> system settings -> lang. support
[18:03] <yotux> This is the new unity was
[18:04] <Cheesehead> Launchpad has a feature to convert support requests into Launchpad Answers
[18:04] <yotux> was = way sorry
[18:04] <yotux> I read something about that
[18:04] <Cheesehead> Right-hand-column: Convert to a question
[18:04] <crog> Cheesehead: Yeah - seems like that's the way to go..
[18:05] <yotux> I agree
[18:05] <Cheesehead> So, the consensus is convert to a Launchpad Question, and the answer explains and points to the wiki?
[18:06] <yotux> Cheesehead:  since the wikik direction are from back in 2009 do we also need to make a doc request to update?
[18:06] <ashams> Cheesehead: wait
[18:06] <ashams> we need to ask him to use the right way before converting to a request
[18:06] <ashams> we're not sure if it's abug of not
[18:06] <Cheesehead> yotux: Most wiki updates are user-created. So you and I can do that.
[18:07] <Cheesehead> ashams: That's an excellent point!
[18:07] <crog> before updating wiki, I'd verify the steps, and try out another language for a session or two.
[18:07] <Cheesehead> crog: Definitely!
[18:08] <ashams> crog: gr8
[18:08] <Cheesehead> So the consensus is to:
[18:08] <Cheesehead> 1) Ask the user to try it the right way - confirm if it's a bug or not
[18:08] <Cheesehead> 2) If it's not a bug, convert to a question
[18:09] <Cheesehead> 3) Spend a bit of time updating the Wiki (submitter may want to help?)
[18:09]  * ashams agrees
[18:09] <Cheesehead> 4) Subscribe to the bug for follow-up, of course
[18:10] <Cheesehead> Any final comments on this bug?
[18:11] <Cheesehead> ..
[18:11] <crog> nope - sounds good
[18:11] <ashams> nope, sounds very good
[18:11] <Cheesehead> Here's one I had a second look at: Bug 86896
[18:12] <Cheesehead> Before trying to figure out the problem...
[18:12] <Cheesehead> ...see if there is anything strange going on.
[18:13] <crog> submitter changed to confirmed...
[18:13] <Cheesehead> crog: Yes indeed. Confirmiong your own bug is a big no-no
[18:14] <crog> other than that - this is for Jaunty - need to have him try on a current version
[18:15] <crog> I havne't had a chance to review the Triage guide in full, but I'd look for a way to mark it invalid
[18:15] <crog> If it's a problem, it can be resubmitted.
[18:15] <Cheesehead> Yeah, it's 4 years old.
[18:16] <Cheesehead> But, um...what's the problem?
[18:16] <crog> well, since you said not to look at that yet...  (jk)
[18:16] <ashams> Why would apt-get hang, bad connection, broken packages, a crash?
[18:17] <crog> might it be waiting for a lock as well?
[18:17] <crog> ahhh - any in his post marked "repeating"
[18:18] <crog> His apt is looking for a feisty file, and not finding it.
[18:18] <Cheesehead> crog: AWESOME spotting!
[18:18] <Cheesehead> Is this really a bug at all?
[18:19] <crog> small chance it could be, but most likely a confirguration issue
[18:19] <crog> man... irc lets through a whole lot more typos and mispellings than email.
[18:20] <Cheesehead> crog: Sure does.
[18:20] <ashams> crog: Excellent
[18:20] <ashams> It is a bug
[18:21] <crog> I don't know that it's a bug
[18:21] <ashams> because apt isn't updated by system update
[18:21] <Cheesehead> Is this issue (bug or misconfiguration) going to be reproducable?
[18:22] <ashams> I think it's not a misconfig, because it was made auto
[18:22] <crog> it's logging the reason
[18:22] <crog> ashams: do we know that?
[18:22] <ashams> crog: Not sure :P
[18:23] <crog> Cheesehead: not on those versions
[18:23] <Cheesehead> Shouldn't /var/lib/apt/lists be cleaned during a release-upgrade?
[18:23]  * ashams has no idea
[18:24] <crog> Cheesehead: perhaps... Again, it maybe something that has already been fixed.
[18:24] <crog> may also be that apt was fine, and there was a power outage when he upgraded from Feisty to Jaunty
[18:25] <Cheesehead> Or some other non-critical error that prevented the cleaning
[18:25] <crog> Someone with the expertise could re-read through the install scripts to see whether such a cleanup step exists
[18:25] <crog> to confirm whether it's a bug.
[18:26] <crog> brb...
[18:26] <Cheesehead> Since it's 4 years old, should we check with the submitter to see if it's still a issue?
[18:27] <ashams> Cheesehead: yep
[18:28] <Cheesehead> A response like https://wiki.ubuntu.com/Bugs/Responses#Old_untouched_bugs ?
[18:28] <Cheesehead> and mark incomplete, and subscribe to the bug for follow-up?
[18:28] <ashams> Cheesehead: I hate those tedious responses
[18:29] <Cheesehead> ashams: They do have their place.
[18:29] <ashams> Cheesehead: copy-n-paste reponses and reporters will fly away ;)
[18:30] <Cheesehead> It's nice to know that the pre-written response is polite, appropriate for the situation, and covers most use cases. You can always personalize it more.
[18:30] <Cheesehead> Perhaps "I've been looking this over, and I noticed that... and then a second paragraph incorparating the pre-written response."
[18:31] <Cheesehead> ashams: Great point - sometimes the pre-written response is mistaken nor not-caring.
[18:31] <Cheesehead> /nor/for
[18:32] <Cheesehead> I have seen copy-n-paste responses used inappropriately, too.
[18:32] <ashams> Cheesehead: I usually love to refine them before replying
[18:32] <ashams> Cheesehead: let's focus on triage :D
[18:32] <Cheesehead> Everyone having fun?
[18:33] <Cheesehead> Anyone learning anything?
[18:33] <crog> yep
[18:33] <crog> yep
[18:33] <ashams> yep, a lot
[18:33] <Cheesehead> How about Next: Bug 340417
[18:33] <yotux> yeah
[18:34] <Cheesehead> Here you see apport in action on a crash.
[18:35] <ashams> bad description:(
[18:35] <Cheesehead> ashams: What's bad about it?
[18:36] <ashams> Cheesehead: 1 line description, strange
[18:36] <Cheesehead> ashams: It can be hard to describe what's important, especially if you are too close ot the problem
[18:36] <Cheesehead> /ot/to
[18:37]  * ashams convinced
[18:37] <Cheesehead> In this case, when you get to the comments, you can see a triager has already been here.
[18:38] <crog> I think jdstrand has already asked the important questions
[18:38] <ashams> yeah, and no response since that
[18:38] <crog> based on the stacktrace - looks like it's mostly system calls
[18:38] <crog> Could be cron
[18:38] <crog> Could be kernel
[18:39] <crog> could be hard-ware dependant
[18:39] <Cheesehead> Question: When a triager asks a question, what change should you make to the bug to indicate that a reply is expected?
[18:39] <crog> It says this is in a virtual machine - so could be that
[18:39] <ashams> if HW-dependent, itmight be the VM
[18:39] <ashams> crog: bingo
[18:40] <Cheesehead> Anyone know how to mark a bug?
[18:40] <crog> Cheesehead: Change status to Incomplete...
[18:40] <Cheesehead> crog: ding ding ding!
[18:41] <crog> so for this one, we probbaly just do that and move on.
[18:41] <Cheesehead> That's right. So jdstrand didn't mark the bug Incomplete.
[18:42] <Cheesehead> What can we do about it?
[18:42] <Cheesehead> (Triage is all about people, and people make mistakes all the time. Just look at my spelling!)
[18:43] <crog> I think we should just mark the bug and go on...
[18:43] <ashams> YES
[18:43] <crog> we could (maybe should) send jdstrand an email
[18:44] <ashams> crog: why, he already did his job
[18:44] <Cheesehead> Or, perhaps, jump into #ubuntu-bugs, and see if he's there?
[18:44] <crog> I probably wouldn't
[18:44] <ashams> may be we need to remind the reporter
[18:44] <crog> because not everyone likes to see their errors pointed out.
[18:44] <crog> But... if we don't let them know, they may continue missing this important step.
[18:44] <ashams> 9.04 is almost at EOL
[18:45] <Cheesehead> "jdstrand: On bug 340417, is it okay if I mark the bug Incomplete?"
[18:45]  * trinikrono back :D
[18:45] <Cheesehead> welcome back!
[18:45] <Cheesehead> I generally recommend checking with a previous triager before trying to redo their work
[18:46] <Cheesehead> We have all been in a situation where two teachers try to teach the same thing...
[18:46] <crog> Cheesehead: Yes, Jamie is in that channel now - it's a good idea!
[18:46] <Cheesehead> and step all over each other.
[18:47] <Cheesehead> Or a restaurant or store where two people interfere with each other and give you (the customer) a bad experience
[18:47] <Cheesehead> and we have all had some work partner who made *more* work for us instead of less
[18:48] <Cheesehead> I predict 95% chance that jdstrand doesn;t remember this bug and has not problem with us going ahead and marking it incomplete...
[18:48] <crog> Cheesehead: a big factor is if you know the person...
[18:48] <Cheesehead> But in the Ubuntu community it's still polite to ask and check first
[18:49] <crog> if youre on the same page, it's probably find to just go ahead.
[18:49] <Cheesehead> crog: Well, now you'll know him.
[18:49] <crog> re: asking first - yes, great idea
[18:49] <crog> doh!
[18:50] <Cheesehead> heh heh. I just left a message fro crog in #ubuntu-bugs
[18:50] <trinikrono> lol
[18:50] <trinikrono> so what are we working on now
[18:50] <trinikrono> i see alot went on
[18:50] <Cheesehead> We're wrapping up 340417
[18:50] <crog> we're ready for another one, right?
[18:50] <Cheesehead> Is the consesnsus to check with jdstrand, then invalidate the bug?
[18:50] <Cheesehead> /invalidate/inccomplete
[18:51] <crog> righto
[18:51] <ashams> it's just a mistake, what can it be else?
[18:51] <ashams> jdstrand: made a simple mistake, no more, I assume
[18:51] <Cheesehead> Agreed, I'm sure it's a mistake. But it's polite to ask.
[18:52] <trinikrono> i think better to just mark it incomplete
[18:52] <trinikrono> unless you know jdstrand personally
[18:52] <Cheesehead> Is there a hurry? It's been open a year?
[18:52] <Cheesehead> I don't know jdstrand personally.
[18:52] <crog> Cheesehead: right, but if you don' change it, it will be another year
[18:53] <ashams> We can just reply again and mark it incomplete, thus we cover jdstrand ;)
[18:53] <trinikrono> it looks like it should of been marked incomplete in the first place
[18:53] <trinikrono> since it was questions he asked
[18:53] <Cheesehead> One more moment on this issue - this is actually pretty important.
[18:53] <trinikrono> i think the best thing
[18:53] <Cheesehead> In this case, I go back to the Code of Conduct
[18:53] <trinikrono> is to ask if the user still experiences the problem
[18:54] <ashams> what CoC can do?
[18:54] <Cheesehead> trinikrono: That's also a valid course of action.
[18:54] <ashams> can Coc do?*
[18:54] <Cheesehead> The Code of Conduct: Patience and Respect
[18:54] <Cheesehead> We don;t know the culture of either the submitter or jdstrand,
[18:54] <Cheesehead> so we should be as polite as possible
[18:55] <Cheesehead> There are cultures where it's okay to dive in (India), and other where it's not (Japan)
[18:55] <ashams> but if we told him about such a mistake, we may cause Embarrassment
[18:56] <Cheesehead> We can tell him in an indirect way, by asking if he approves this course of action.
[18:56] <Cheesehead> Every culture has a way of pointing out mistakes. Me must simply use an apprporate way
[18:57] <crog> Cheesehead: yes - your approach @ 13:45 is the best approach. In this case we know how to reach them.
[18:57] <Cheesehead> Ooh, lots of mispellings there!
[18:57] <crog> What if we didn't?  leave it open?
[18:57] <crog> I suspect this is not a huge important bug, or it would have been dealt with sooner.
[18:57] <Cheesehead> If we simply closed it, then we might be making extra wlor for somebody else.
[18:57] <crog> But a bug that sits in limbo doesn't healp anyone
[18:57] <Cheesehead> /wlor/work
[18:58] <crog> No - don't close it.
[18:58] <crog> make a best effort to ask first, and then mark incomplete
[18:58] <Cheesehead> crog: Agreed.
[18:58] <ashams> crog: I agree too
[18:58] <ashams> consensus ?
[18:58] <Cheesehead> We all make mistakes. We all want to be told nicely about them. We all want to improve.
[18:59] <Cheesehead> Consensus: Contact jdstrand, then makr Incomplete?
[18:59]  * Cheesehead curses his fumbly fingers
[19:00]  * Cheesehead laughs
[19:00] <crog> y
[19:00] <Cheesehead> Next: Bug 83389
[19:00] <Cheesehead> (Yes, a cron theme today)
[19:02] <Cheesehead> Is anyone unfamiliar with the apt-cache commands?
[19:03] <crog> eckhofer confirmed the bug, but the status is not confirmed
[19:03] <crog> Cheesehead: I am
[19:03] <crog> (unfamilar)
[19:03] <Cheesehead> crog: Good spotting of confirmation
[19:03] <Cheesehead> apt-cache is an incredibly handy little utility
[19:04] <Cheesehead> pop open a terminal and do a 'apt-cache search firefox'
[19:04] <Cheesehead> It will show you every package in the cache with the word firefox in the title or description
[19:04] <Cheesehead> Then, try apt-cache show firefox for the database entry for the package
[19:05] <Cheesehead> including description and dependencies
[19:05] <Cheesehead> Since it's all text, it's greppable (very handy)
[19:05] <Cheesehead> In this bug, do the comments indicate that we seem to have a missing dependency?
[19:06] <crog> right -  but I'd need to install htdig to check this.
[19:06] <Cheesehead> no, you just need apt-cache
[19:06] <crog> or I know synaptic lists the dependancies, so I'd probably go there.
[19:06] <crog> yeah - I see...
[19:06] <crog> thanks
[19:06] <Cheesehead> apt-cache and synaptic pull from the same source.
[19:07] <Cheesehead> Try 'apt-cache depends htdig'
[19:07] <crog> awesome tool then
[19:07] <Cheesehead> And then try 'apt-cache rdepends htdig', too.
[19:07] <Cheesehead> Very handy for looking for something specific, like packaged that handle dotty files: 'apt-cache search dotty'
[19:08] <Cheesehead> So, what are the current lockfile dependencies for htdig?
[19:08] <crog> the dependency is listed - so the problems' likely already fixed
[19:09] <Cheesehead> ashams: What do you think?
[19:09] <crog> Id' ask them to try again on a current version
[19:09] <Cheesehead> trinikrono: Any opinion?
[19:09] <crog> or better - track down the specific version that contains the fix
[19:09] <Cheesehead> crog: http://changelogs.ubuntu/com
[19:10] <Cheesehead> yotux: Still with us?
[19:10] <ashams> Cheesehead: I don't know why you check deps?
[19:11] <Cheesehead> ashams: Becasue of this comment: https://bugs.launchpad.net/ubuntu/+source/htdig/+bug/83389/comments/3
[19:11] <crog> ashams: the person that said they confirmed specifically mentioned that was the cause of the problem - a missing dependency
[19:11] <Cheesehead> But then they didn't do the next step...
[19:11] <Cheesehead> What is the next step?
[19:12] <crog> I think we want to assume they're correct - though its possible the submitter and confirmer are not looking at exactly the same problem, it's most likly the case
[19:12] <ashams> Cheesehead: Yeah, now I see, thanks :D
[19:12] <Cheesehead> ashams: That's way we do this together!
[19:13] <ashams> but why the daily runs when weekly does?
[19:13] <Cheesehead> Great question!
[19:14] <Cheesehead> Take a look at your crontabs. When do your daily and weekly run?
[19:15] <Cheesehead> One day each week, mine run 22 minutes apart.
[19:15] <Cheesehead> The daily has 22 minutes to finish before weekly runs.
[19:16] <ashams> yeah!
[19:17] <Cheesehead> In this case, weekly cannot create a lockfile.
[19:17] <Cheesehead> Normally, that should happen only if daily is still running.
[19:18] <ashams> I see
[19:18] <Cheesehead> Anacron will also affect it
[19:18] <crog> Cheesehead: you mentioned http://changelogs.ubuntu.com
[19:18] <crog> I think it was faster to go to
[19:18] <crog> https://launchpad.net/ubuntu/+source/htdig/+changelog
[19:18] <crog> unless there's a good way to search  the changlogs site
[19:19] <Cheesehead> ashams: If you turn oun your computer, sometime around when they bothe run, anacron will reschedule them so they don;t try to run at the same time.
[19:19] <crog> This was fixed in feisty
[19:19] <Cheesehead> crog: Great point! I never though of that!
[19:19] <crog> closed but #364022
[19:19] <Cheesehead> Bug 346022
[19:19] <Cheesehead> Bug 364022
[19:20] <crog> I mean closes bug #  yeah, you know
[19:20] <Cheesehead> Was that a gnome bug?
[19:20] <crog> maybe a typo in the bug number in the change log?
[19:20] <ashams> Cheesehead: you are brilliant :D
[19:21]  * ashams brb in 10 mins, sorry :(
[19:21] <Cheesehead> No, I'm just the guy who showed up. You should meet my brother. *He's* incredible.
[19:21] <crog> if we could find the bug it really fixes, we could mark as duplicate, link them, close this one
[19:21] <crog> Or... just mark this as fix released.
[19:21] <Cheesehead> crog: Exactly
[19:22]  * Cheesehead is cruising, looking for that bug
[19:23] <crog> Cheesehead: might the bug number in the change log be an upstream number, or is that a Ubuntu-specific thing?
[19:23] <Cheesehead> I googled the string "htdig now depends on lockfile-progs"
[19:24] <Cheesehead> It's a Debian bug number
[19:24] <Cheesehead> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=364022
[19:24] <Cheesehead> Another option is to upstream thi bug to Debian.
[19:25] <Cheesehead> Launchpad will figure out that it's fixed and close the bug for us.
[19:25] <crog> nice
[19:26] <Cheesehead> Changelog link (for reference): https://launchpad.net/ubuntu/+source/htdig/1:3.2.0b6-1
[19:26] <EgyParadox> Bug 1
[19:26] <Cheesehead> EgyParadox: Hello!
[19:26] <EgyParadox> Hii
[19:26] <EgyParadox> Hi*
[19:26] <Cheesehead> Funny that the 'bot didn;t pick it up
[19:26] <Cheesehead> Bug #1
[19:26] <EgyParadox> yeah lol
[19:26] <Cheesehead> Bug #0001
[19:27] <EgyParadox> the most important bug I believe
[19:27] <Cheesehead> Oh, well.
[19:27] <Cheesehead> True, working on it...
[19:27] <EgyParadox> Does anybody have issues with the document viewer?
[19:27] <EgyParadox> oneriic
[19:28] <Cheesehead> Well, mine doesn't make me a sandwich.
[19:28] <Cheesehead> But mine's not 11.10
[19:28] <Cheesehead> What sorts of problems?
[19:28] <ashams> Cheesehead: pick a bug for evince?
[19:29] <Cheesehead> Okay, one moment...
[19:29] <EgyParadox> it turns out the files are corrupt :S
[19:30] <Cheesehead> https://bugs.launchpad.net/ubuntu/+source/evince
[19:30] <ashams> EgyParadox: it might be the doc itself
[19:30] <Cheesehead> EgyParadox: Do they open in other viewers? Or older versions?
[19:30] <EgyParadox> nope
[19:30] <ashams> EgyParadox: Files relly corrupted
[19:30] <ashams> really*
[19:32] <Cheesehead> Here we are: Bug 287646
[19:32] <Cheesehead> (I like that bot)
[19:33] <Cheesehead> You can see that we haven;t even *touched* real traiging, we're still just wading through non-bugs, and old, un-followed-up stuff
[19:34] <Cheesehead> That's why it's considered good practice to subscribe to the bugs you work, and follow up on them
[19:34] <Cheesehead> So nobody comes along a year or three later and asks "Why is this still open?"
[19:35] <Cheesehead> You can see that following up on bugs is a weakness in our community.
[19:35] <crog> I'm not even seeing what the problem is...
[19:36] <Cheesehead> EgyParadox, ashams: What do you think?
[19:37] <ashams> not evince at all
[19:38] <Cheesehead> What could it be?
[19:38] <ashams> compiz
[19:39] <ashams> bug 730495 is fixed, we should ask reporter if it still exists
[19:39] <Cheesehead> Commets #5 and #6 on that blocking bug seem related to this problem
[19:40] <Cheesehead> Agreed that asking the submitter if it's still an issue is the way to go.
[19:41] <Cheesehead> But why didn't the last triager (Martin Wildam) do that?
[19:42] <Cheesehead> Any ideas on why our bug was left hanging?
[19:43] <crog> as i read the description, and see the screenshot - i think it's not a bug
[19:43] <Cheesehead> Also, take a look at the original report date
[19:44] <Cheesehead> crog: What do you think it is?
[19:44] <crog> Cheesehead: ??  user expectation?
[19:45] <crog> re: reported dates 08/intrepid... "same behavior in natty 2011"
[19:46] <Cheesehead> In Ubuntu, behavior that is clearly wrong or unexpected can be safely considered a bug.
[19:46] <Cheesehead> The developer didn't intend for the evince window to be unusably small
[19:48] <ashams> mwildam is not a bug triager, probably he didn't know what to do
[19:48] <crog> I'm still not seeing it - even zooming in on the screenshot - where is the "small unreadable" evince?
[19:48] <Cheesehead> ashams: Good spot! He was probably new, and untrained.
[19:49] <Cheesehead> ashams: Lots of new, untrained people hanging around, and he perhaps didn't ask for advice in #ubuntu-bugs
[19:49] <crog> agree w/ ashams
[19:50] <ashams> I just checked his lp profile, https://launchpad.net/~mwildam
[19:50] <ashams> he's not amember of bugsquad
[19:50] <ashams> :P
[19:50] <ashams> may be GreaseMonkey scripts can help on this
[19:50] <Cheesehead> When you run across somebody like this, interested but unskilled...
[19:51] <Cheesehead> we have all been in that position, too.
[19:51] <Cheesehead> And we will see many more as Ubuntu grows
[19:51] <ashams> yeah, just had to
[19:51] <Cheesehead> What can we do about this bug?
[19:52] <ashams> https://launchpad.net/launchpad-gm-scripts does the job every time i need to know some about reporters/commenters
[19:52] <Cheesehead> Yes it does!
[19:52] <Cheesehead> You can also just click on their name.
[19:53] <ashams> Cheesehead: If we're sure it's a dup of bug 730495, let's just mark it
[19:53] <Cheesehead> It may not be a dupe.
[19:53] <Cheesehead> Or, rather, I am not skilled enough to say that it's a dupe.
[19:53] <ashams> so...
[19:54] <Cheesehead> We could ask in #ubuntu-bugs if they think the two are dupes
[19:54] <ashams> nice idea, let's do it
[19:54] <ashams> ok?
[19:54] <Cheesehead> ashams: Go for it!
[19:55] <Cheesehead> ..
[19:55] <Cheesehead> Whoa! Look at the time!
[19:55] <Cheesehead> Has everyone had a good time?
[19:55] <Cheesehead> Learned anything?
[19:55] <crog> much! - thanks Cheesehead
[19:56] <ashams> MUCH
[19:56] <Cheesehead> crog: What do you think of bugs now?
[19:56] <Cheesehead> I hope you got something out of it.
[19:56] <ashams> Cheesehead: Thank you very nuch :D
[19:56] <crog> yes indeed
[19:56] <Cheesehead> ashams: Thanks for coming by and contributing so much!
[19:57] <ashams> Cheesehead: :D
[19:57] <ashams> crog: :D
[19:57] <Cheesehead> crog: Thanks for SIX HOURS of your holiday weekend!
[19:57] <crog> 5 1/2
[19:57] <crog> and as you say - no work tomorrow!!!
[19:57] <ashams> thanks all
[19:58] <Cheesehead> Thanks so much for a successful bug jam!
[19:58] <Cheesehead> #endevent!
[19:58]  * Cheesehead heads out to the atrium for a drink
[19:59] <ashams> Cheesehead: go to #ubuntu-bugs
[20:01] <Cheesehead> ashams: I saw
[20:02] <Cheesehead> I'll contact the previous triager, and ask the original submitter if it's still an issue.
[20:03] <ashams> Cheesehead: correct step
[20:03] <ashams> good luck
[20:04] <Cheesehead> You saw that the #ubuntu-bugs people are friendly and helpful.
[20:04] <Cheesehead> A great resource when you get stuck!
[20:06] <Cheesehead> komputes, trinkono, crog, ashams, EgyParadox, yotux: Thanks for coming by, contributing, and making this jam a success!
[20:06] <komputes> woohoo \0/
[20:06] <ashams> Cheesehead: thanks to you
[20:07] <crog> yeah - thanks a bunch
[20:10] <EgyParadox> thanks alot :D
[20:11] <EgyParadox> when will the ubj end?
[20:13] <ashams> It have just ended
[20:14] <EgyParadox> globally?
[20:18] <Cheesehead> Philospohy: Does anything ever truly end?
[20:19] <Cheesehead> (not including hardware warranties, which really do end)
[20:24] <EgyParadox> I mean
[20:24] <crog> ubj event site says Sept 2-4
[20:25] <crog> The WI loco event was today from 12-3pm (CST).
[20:25] <EgyParadox> The Ubuntu Global Jam is an incredible opportunity for the Ubuntu community to unite together around the weekend of 2 - 4 September 2011
[20:25] <EgyParadox> yeah
[20:25] <EgyParadox> oh ok
[20:25] <crog> I think EgyParadox  is asking if we're done in our channel... is there someplace else he can help out?
[20:25] <crog> Since the weekend isn't over yet...
[20:26] <crog> I don't know the answer...
[20:26] <crog> or maybe that's not what you were asking.
[20:26] <ashams> EgyParadox: In Egypt, we still have today, sept 4th, to do it again ;)
[20:27] <ashams> EgyParadox: 1 1/2 hrs left
[20:34] <Cheesehead> Hey, you don't need me. You guys did all the work anyway!
[20:36] <trinikrono>   thanks for having us :D
[20:36]  * Cheesehead goes to start preparing dinner for the family
[20:36] <trinikrono> not bread and cheese i hope
[20:37] <Cheesehead> September, so the in-deason foods are grilled corn and hamburgers.
[20:37] <Cheesehead> /deason/season
[20:40] <ashams> Cheesehead: Bon a Petit
[20:45] <ashams> bye guys, I had a real great time with you :D
[20:46] <ashams> Thanks for the gr8 session
[21:00] <EgyParadox> Cheesehead: Do you manage any projects on launchpad?
[21:01] <Cheesehead> EgyParadox: I do not. Why?
[21:01] <EgyParadox> just asking
[21:02] <Cheesehead> I spend quite a bit of time over at Brainstorm...
[21:02] <EgyParadox> brainstorm?
[21:03] <Cheesehead> http://brainstorm.ubuntu.com
[21:03] <Cheesehead> The I-have-an-idea-and-don't-know-what-to-do-about-it website.
[21:07] <EgyParadox> I see
[21:10] <EgyParadox> oh that portal for suggestions/ideas
[21:10] <Cheesehead> That's the one.


[00:54] <teward> guiverc: Fallen: the mailing list moderators and membership have been altered.  But because a ton of people had the old moderation/admin password I'm probably going to have to reset that (and PGP encrypt the password to everyone's PGP keys, and if there are no PGP keys available then they'll have to reach out to me individualy)
[01:36] <guiverc> ack


[00:37] <genii-around> No one has sent me any cupcake recipes!
[01:16]  * genii-around slurps
[02:39]  * genii-around smurches
[04:39] <dscassel> Sadly, I don't have any cupcake recipes. :(
[04:50] <Jeruvy> evenin'
[04:50] <dscassel> Evening, Jeruvy
[04:52] <Jeruvy> Hows things dscassel?
[04:55] <dscassel> Pretty good.  You just reminded me I need to send you and email. :
[04:55] <dscassel> :)
[04:56] <Jeruvy> I just returned from the pub after day one of Stanley Cup Playoffs.
[04:56] <Jeruvy> I'm confident Vancouver will pummel Chicago
[05:00] <dscassel> I'll take your word for it. :)
[05:01] <Jeruvy> The game was still going when I left so I'm fortelling.
[05:49] <Jeruvy> Van2-Chi0
[12:57] <xskydevilx> How can I make an .ISO image of a DVD disc in Maverick?
[14:31]  * genii-around sips
[14:33] <genii-around> Montreal vs Boston tonight :)
[14:37] <IdleOne> Does montreal have a chance?
[14:37] <IdleOne> s/m/M/
[14:37] <IdleOne> I don't follow hockey
[14:37] <genii-around> I'd like to think they do. Just them and Vancouver now left as the Canadian teams
[14:39] <IdleOne> hypatia: Can you please get the folks at hacklab to work on making me a USB coffee maker. PLEASE!!!!!!
[14:39] <IdleOne> not warmer but a machine that makes coffee
[14:40]  * IdleOne is so lazy
[14:40] <IdleOne> I don't even want to get up to get more coffee
[14:47]  * genii-around thinks about RFC 2324
[21:11] <KombuchaKip> Ubuntu Vancouver LoCo at our local farmer's market. https://frenchfortunecookie.wordpress.com/2010/09/23/learn-grow-share-ubuntu/
[21:14] <dscassel> That's awesome, KombuchaKip. Are you planning on doing it again this year?
[21:16] <KombuchaKip> dscassel: I hope so. I am pretty tied up with the game, but Randall takes care of most of these things. We will be presenting to Earthsave soon though, which is a vegetarian / vegan society.


[07:14] <ion> Huh. Why is a beta version of Firefox 5 in natty-proposed?
[07:17] <micahg> ion: to build the new language packs and for extended user testing, natty getting Firefox 5 as a security update on June 21
[07:18] <micahg> it's more of an RC, but it's from the "beta" channel
[07:20] <ion> Upgrading Firefox 4 to Firefox 5 is guaranteed not to break anything? All extensions will be compatible?
[07:20] <micahg> ion: no, but we have no choice
[07:21] <lifeless> ion: upstream are not supporting 4
[07:21] <ion> How nice
[07:21] <lifeless> ion: and backporting security fixes from 5 to 4 is ... an interesting proposition
[07:21] <micahg> ion: last number I saw was 76% extension compatibility
[07:22] <micahg> Lucid and Maverick will be upgraded in the future as well, but for the moment 3.6 is supported
[09:34] <directhex> okay. i've isolated the thing that breaks mono on arm.
[09:34] <directhex> well, "isolated"
[09:34] <cjwatson_> slangasek: given that debconf switched to git somewhere in there, perhaps the best strategy is either something like rebase-foreign, or else stitch something together with import-dsc; I expect it will be somewhat manual in any event ...
[09:35] <jamespage> morning
[09:35] <directhex> gcc 4.6. specifically ubuntu's gcc-4.6
[09:36] <jamespage> please could a member of the archive admin team reject 'libpam4j' from the new upload queue - thanks
[09:40] <cjwatson_> jamespage: done
[09:40] <jamespage> cjwatson: thankyou
[09:51] <cjwatson> slangasek: I've applied the GtkAssistant patch to debconf upstream now, for the next release
[09:57] <directhex> cjwatson: afaik both gcc 4.5 and 4.6 on ubuntu should target the same thing, right? i see the same --with-arch, --with-mode and --with-fpu flags for both
[09:58] <cjwatson> I hadn't heard of target changes there, which doesn't necessarily mean there are none
[10:00] <directhex> i see a few removed flags as the only differences (--enable-gold --enable-ld=default --with-plugin-ld=ld.gold)
[10:05] <directhex> i want to be absolutely sure that i've done everything possible on my side - but i can't see much more I can do with my area of competence than say "an unmodified upstream tarball is okay with ubuntu gcc-4.5, and 4.6 on all arches except arm, so I think the issue is gcc-4.6 on arm"
[10:20] <cjwatson> directhex: have you tried building with -O0 on armel?
[10:21] <directhex> cjwatson, no. i'll do that next. see you in some hours!
[10:21] <cjwatson> directhex: if that works, bisect optimisation flags to try to narrow it down
[10:21] <cjwatson> similarly if you're using any -fthingy options then play with those
[10:21] <cjwatson> directhex: there's no way to do anything incrementally?
[10:22] <directhex> cjwatson, not in a way i trust. it's "successfully" building the runtime, but the built runtime is "bad" and won't execute code properly. and i don't want to only partially rebuild when i don't know which thing is choking
[10:32] <cjwatson> directhex: *nod*
[10:32] <cjwatson> frustrating.
[10:33] <directhex> when you've been at it since friday morning, mostly waiting for builds to finish, yeah
[10:33] <directhex> anyone got a super fast ARM board to mail me?
[12:48] <debfx> cjwatson: http://people.canonical.com/~ubuntu-archive/seeds/kubuntu.oneiric/ doesn't seem to get updated from the branch
[12:51] <cjwatson> hmm
[12:51] <Daviey> pitti: Am i correct in saying with http://bugs.debian.org/616318 , you were expecting the Depends to remove dpkg-dev (Ubuntu delta) and NOT the Build-Depends which the DM has done?
[12:55] <cjwatson> debfx: fixed, sorry about that - thanks for the report
[13:11] <directhex> cjwatson, the complete build isn't finished, but it looks like the -O0 build is okay
[13:12] <cjwatson> OK, so now you get to figure out which optimisation broke it :-/
[13:13] <directhex> is O1 worth trying? i know it's the same as O2 on some compilers, i don't remember if that includes gcc
[13:14] <cjwatson> -O1 is not the same as -O2 and is worth trying
[13:15] <cjwatson> gcc.info has the list of exactly which optimisations each one turns on
[13:18] <directhex> look like about 27 extra -ffoo flags from o0 to 01, and same from o1 to o2. so really, o1 is a bisect anyway :p
[13:24] <cjwatson> directhex: sure, it's just the first obvious-and-useful bisect
[13:24] <directhex> i just wish this process were faster :p
[13:53] <speakman> http://askubuntu.com/questions/120/how-do-i-avoid-the-s-to-skip-message-on-boot
[13:53] <speakman> Looks like nobootwait doesn't work
[14:50] <directhex> cjwatson, getting there. O1 seems fine.
[15:19] <pitti> jelmer: any SRU needs a corresponding bug to track, so subscribing ~u-sru to the bug will do
[15:20] <pitti> jelmer: u-sru does sponsor the odd upload, but it's not its primary role indeed
[15:20] <jelmer> pitti: ok
[15:20] <pitti> Daviey: correct; it doesn't matter as a build dependency
[15:20] <jelmer> pitti: Thanks, I'll link a bug
[15:50] <smoser> in a modified debian package, should Vcs-* be changed ? it seems there are a fair amount of different solutions
[15:53] <smoser> XS-Debian-Vcs-* , Xs-Vcs-*, XSBC-Original-Vcs-*
[15:53] <smoser> the '-Debian' seems to make the most sense to me, but google doesn't seem to find anything clear cut on what we should be putting
[16:02] <smoser> other than this thread: https://lists.ubuntu.com/archives/ubuntu-devel/2007-March/023332.html but doesn't look like anything completely decided there.
[16:04] <cjwatson> smoser: we settled on XS-Debian-Vcs-*, but I don't have a reference for you
[16:05] <smoser> so should that always be changed if there is a change made ?
[16:10] <cjwatson> smoser: generally I think so, but it's not vital or anything
[16:53] <apw> does anyone have oneiric nerwork manager working with wifi ?
[16:53] <apw> and is the branding all sick or is something wrong with my install
[16:53] <jibel> a
[16:54] <jibel> apw, bug 796286
[16:54] <jibel> apw, it's private subscribing you
[16:54] <apw> jibel, thanks
[16:58] <apw> pitti, is the apport retracer working ok ?
[17:01] <apw> pitti, the bug above seems to be marked for retracing, but 22 hours has gone past ... hmm, suspect not so well
[17:27] <mterry> doko__, got a mir for you when you get a chance: bug 491644
[17:29] <mterry> kees, same for you -- I subscribed you to librsync in that bug  ^
[17:46] <micahg> mterry: kees is off this week
[18:03] <mterry> micahg, ah, thanks
[18:05] <directhex> cjwatson: bisecting is slow, but yielding results. it's one of these: -foptimize-sibling-calls -fpeephole2 -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop -fschedule-insns
[18:30]  * Daviey has come across 2 packages today where the only Ubuntu delta is dropping Depends on locales-all.. Why don't we have this?
[18:31] <Daviey> would it be cheaper to have a locales-all meta package to locales, than maintaining this?
[18:31] <slangasek> locales-all and locales aren't the same thing; locales-all is a package that contains pre-generated locales for all packages
[18:31] <slangasek> what packages have a dependency on this in Debian?
[18:32] <Daviey> slangasek, i just saw python-django... and there was another one i uploaded yesterday... lemme check
[18:32] <slangasek> a quick look at stable shows only openoffice.org-l10n packages, gforge-web-apache2, and libc6
[18:32] <slangasek> python-django> no earthly reason that should depend on locales-all in Debian either
[18:33] <slangasek> and I don't see that it *does* in unstable or stable
[18:35] <Daviey> slangasek, is your search returning build-depends aswell?
[18:35] <slangasek> oh, you didn't say build-depends ;)
[18:35] <Daviey> sorry
[18:36] <slangasek> locales-all as a metapackage depending on locales *definitely* wouldn't satisfy a build-dep
[18:36] <slangasek> packages that need locales at build time should really generate them themselves
[18:37] <slangasek> that's in both Debian and Ubuntu, I mean
[18:39] <Daviey> Hmm
[18:39]  * Daviey is looking for the other example
[18:44] <Daviey> Gah, can't find it - i was certain i saw another.
[19:11] <slangasek> Daviey: well, python-django in unstable seems to have added a build-dep alternative on the en langpack, so it looks like that delta could be dropped now
[19:12] <slangasek> also, I've just looked up the correct env vars and commandlines to use a locale from a local directory, so I'll probably submit that as a patch to python-django and blog the recipe for later use
[19:13] <Daviey> slangasek, I'll watch out for that, thanks.. Kinda frustrated i can't find the other package i saw it.
[19:17] <slangasek> Daviey: libapache2-mod-perl2? php5?
[19:17] <Daviey> slangasek, was just looking at php5 :)
[19:17] <Daviey> locales-all. -- Now has alternative language-pack-de for use in tests. <--
[19:19] <Daviey> but yes, the one i was thinking of was libapache2-mod-perl2
[19:19] <Daviey> thanks
[19:28] <smoser> Daviey, slangasek i had tried building python-django, tihnking it might just build
[19:28] <smoser> but http://paste.ubuntu.com/626043/
[19:44] <Daviey> slangasek: So, it seems the delta with python-django was never needed.. Seems that it was really an issue with sbuild's dep handling.
[19:44] <slangasek> Daviey: ah, heh
[19:44] <Daviey> (works in pbuilder, fails in smoser's sbuild)
[19:44] <slangasek> right
[19:45] <Daviey> guesing, http://bugs.debian.org/403246
[19:47] <micahg> that's a config option for sbuild IIRC, works fine in LP
[19:47] <micahg> as long as it's not a versioned build-dep first
[19:48] <Daviey> bah, it shouldn't matter
[19:49] <micahg> Daviey: in Debian, only the first alternative is used, so it makes sense as a default
[19:49] <Daviey> micahg: you are saying that it is OK for this to FTBFS, Build-Depend: foo (>=X) | bar ?
[19:50] <micahg> Daviey: no, that's due to LP using an old hacked version of sbuild IIRC, I have a bug filed for it
[19:50] <Daviey> ah, i see
[19:50] <slangasek> bug filed for what?
[19:50] <micahg> slangasek: versioned alternative build-deps failing
[19:50] <Daviey> against soyuz i assumed.
[19:50] <slangasek> oh, ok
[19:51] <micahg> bug 594916
[19:52] <Daviey> oh joy.
[19:52] <smoser> but this is not versioned.
[19:52] <smoser> so we should be fine on this as a sync at least.
[19:52] <micahg> smoser: so your local sbuild has a config option for that
[19:53] <Daviey> smoser: bah, we were quite happy spinning off on a tangent then.
[19:53] <Daviey> smoser: Yeah, switch to a sync please :)
[19:53] <smoser> micahg, oh? well i just built sbuild from oneiric for my natty system
[19:53] <smoser> so that will "just work" also i would hope
[19:53] <Daviey> smoser: lets see :)
[19:54] <smoser> although it failed, wanting me to run : sbuild-update --keygen
[19:54] <smoser> which is still waiting on some entropy
[19:54] <micahg> smoser: look for this line in /etc/sbuild/sbuild.conf: #$check_depends_algorithm = "first-only";
[19:54] <Daviey> i'm gonna dput the debian package to a PPA just to satisfy my curiosity, as i'm not sure i can wait for the sync. :)
[19:55] <smoser> so that needs to be 'alternatives', eh?
[19:56] <smoser> so is that bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403246 not valid ?
[19:56] <micahg> smoser: it is fixed, just not the default :)
[19:57] <smoser> ah. but it was fixed in 0.62, which was still > my natty version
[20:03] <Daviey> smoser: we'll see what happens: https://launchpad.net/~davewalker/+archive/junk/+sourcepub/1772041/+listing-archive-extra
[20:04] <smoser> i need 279 bytes of freaking entropy
[20:04] <smoser> oln my headless sytem
[20:04] <smoser> damamnana
[20:04] <Daviey> smoser: you need an entropy key :)
[20:05] <smoser> jdjdjdjdksadf
[20:05] <smoser> salkfirirmenw
[20:06] <sbeattie> smoser: does it have a working tpm chip?
[20:06] <smoser> wonder why i never had to do this before
[20:06] <smoser> probably not, sbeattie
[20:06]  * smoser apologizses for random keys to channel
[20:08] <mdeslaur> hehehe
[20:08] <nigelb> smoser: cat on the keyboard? :)
[20:08] <mdeslaur> smoser: those are the exact same random keys I use!!
[20:08] <smoser> yeah, every one can now guess my keys.
[20:08] <smoser> darn.
[20:09] <smoser> will start again
[20:11] <Daviey> smoser: if you still can't find enough entropy, let me know the details you want and i'll generate it here and email it across.
[20:11] <Daviey> (Don't worry, i'll encrypt the private key before emailing it!)
[20:17] <smoser> well, i did get enough.
[20:17] <smoser> i did the same thign on my laptop here.
[20:17] <smoser> but then ran into another issue... that sbuild doesn't seem to happy on natty.
[20:56] <jono> is ldm safe to use in Oneiric yet?
[21:02] <stgraber> jono: ldm has been perfectly usable for years ;) (ldm == LTSP display manager)
[21:02] <jono> stgraber, :-)
[21:02] <jono> LightDM :-)
[21:02] <stgraber> jono: now, for lightdm, I'm using it and it "works for me"
[21:02] <jono> stgraber, how do I enable it instead of GDM?
[21:02] <stgraber> jono: in my case I just tried it with: sudo stop gdm && sudo start lightdm
[21:03] <saamm> hello, what does mouse polling rate = 0 mean in Ubuntu?
[21:03] <stgraber> jono: not sure how to change the default though (but I got prompted when installing lightdm, so it's probably some debconf magic)
[21:04] <jono> thanks stgraber
[21:04] <LaserJock> would a dpkg-reconfigure gdm work?
[21:04] <stgraber> I'd think so, yes
[21:04] <stgraber> jono: np
[21:12] <saamm> is there a wiki page on mouse polling rate?
[22:46] <lynxman> ping slangasek
[22:47] <slangasek> lynxman: hi there
[22:47] <lynxman> slangasek: hi o/
[22:47] <slangasek> I assume you got my email :)
[22:47] <lynxman> slangasek: I've just got your email yeah :)
[22:48] <lynxman> slangasek: would it be okay if I fix all these issues and upload a new version tomorrow?
[22:48] <slangasek> lynxman: certainly
[22:48] <lynxman> slangasek: excellent, thank you very much for the email :)
[22:48] <slangasek> lynxman: when you've done so, please ping me to have another look at the package, so it doesn't just end up at the end of the queue for whichever archive admin next processes NEW
[22:49] <lynxman> slangasek: I'll do so, thanks :)
[22:49] <slangasek> lynxman: do you agree that it's ok to combine these plugins into a smaller number of packages, or are there reasons that we want one binary package per plugin?
[22:50] <slangasek> I'm assuming it's possible to enable/disable plugins at runtime using a config file
[22:50] <lynxman> slangasek: there's architectural reasons for it
[22:50] <lynxman> slangasek: exactly!
[22:50] <lynxman> slangasek: and each plugin has its own set of dependencies
[22:50] <slangasek> ok
[22:50] <slangasek> well, most of the plugins don't have interesting dependencies
[22:50] <slangasek> half of them depend on puppet and only puppet
[22:50] <lynxman> slangasek: hm yeah, I just copycatted the way they've done it upstream
[22:50] <lynxman> slangasek: I have direct contact with the author though, and he's in UK time
[22:51] <lynxman> slangasek: so I'll ping him tomorrow morning and see what he says about the suggestion as well, it sounds more than reasonable
[22:51] <slangasek> ok, let me know what you guys decide either way
[22:59] <lynxman> slangasek: will let you know as soon as I know as well ;)
[23:23] <slangasek> Daviey: Debian bug #630421, fwiw
[23:24] <directhex> -frerun-cse-after-loop
[23:25] <cjwatson> pitti: so, live-build seems to have saved a couple of megabytes, but it's obscured by (a) libegl1-mesa (b) python3.2 and (c) mono 2.10 (as warned by directhex) having eaten a chunk of space between them
[23:26] <cjwatson> pitti: unfortunately cdimage was ENOSPC for a couple of days so comparison data is hard to come by
[23:26] <directhex> once i've beaten this armel thing i can focus on getting mono apps and their disk usage back under control
[23:27] <directhex> this is my confirmation build right now as to the problem flag
[23:27] <cjwatson> pitti: you can look at successive livefs builds on http://cardamom.buildd/~buildd/LiveCD/oneiric/ubuntu/ from the DC - 20110613.2 is the first live-build one there
[23:41] <broder> cjwatson: +1, congrats, etc :)
[23:51] <Daviey> slangasek: looks elegant!
[23:55] <RAOF> What's pulling libegl1-mesa onto the CD?
[23:56] <RAOF> Ah, cairo.
[23:56] <slangasek> ah, python3 has found its way on now, has it?
[23:56] <cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.oneiric/rdepends/ALL/libegl1-mesa
[23:56] <bryce> RAOF, cairo??
[23:56] <slangasek> cairo?  sounds like a bug then :)
[23:57] <cjwatson> slangasek: lsb-release
[23:57] <bryce> RAOF, leftover from wayland?  (*small tear*)
[23:57] <slangasek> cjwatson: heh, ok
[23:57] <RAOF> slangasek, bryce: I don't think it's a bug; the ARM guys were porting the cairo gl backend to autoselected gl/egl.  If that's landed then I'd expect a dep on both.
[23:58] <slangasek> RAOF: "a dep on both" - I would certainly consider that a bug, intended or not
[23:58] <slangasek> I would expect an egl dep on armel, and a gl dep elsewhere
[23:58] <RAOF> Oh.  Ra raw.  Hello memory usage bugs on nvidia!
[23:58] <slangasek> or at most, an ORed dep satisfied by the sensible alternative on each arch
[23:59] <RAOF> slangasek: That would require cairo backends to be loadable; they aren't.
[23:59] <slangasek> no, it would just require us to build for the sensible backend on each arch :)
[23:59] <slangasek> who needs an egl backend on x86?