[00:42] <pace_t_zulu> hggdh: thanks for your help
=== yofel_ is now known as yofel
=== cjohnston_ is now known as cjohnston
[02:40] <pace_t_zulu> hggdh, ping
[03:02] <pace_t_zulu> anyone around?
[03:04] <micahg> pace_t_zulu: yes
[03:04] <Linux000> pace_t_zulu
[03:04] <Linux000> yes
[03:07] <Linux000> does anyone know where the xorg.conf file is for ubuntu 10.04
[03:07] <micahg> Linux000: there's isn't one by default
[03:08] <Linux000> ? How does that work? X is set up default everytime?
[03:09] <micahg> Linux000: idk, I would think it just uses the defaults
[03:09] <Linux000> Okay
=== tester01_ is now known as uaa
[03:23] <pace_t_zulu> micahg: Linux000 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/535297
[03:23] <ubot4> Launchpad bug 535297 in linux (Ubuntu) "BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 (affects: 13) (dups: 2)" [High,Confirmed]
=== uaa is now known as damascene
=== EzraR_ is now known as EzraR
[05:18] <rockfx01> hello
[05:20] <rockfx01> just wondering - if I want to request a bugsquad mentor, the instructions say i need to create a wiki entry ....
[05:20] <rockfx01> Is that really necessary or can i just change my homepage content in launchpad with the necessary details?
[05:48] <persia> rockfx01: You're going to want to have a wiki page later anyway, so it's best to create it now.  Just add your name, contact details, and a short blurb about yourself or about your involvement with Ubuntu.
[05:48] <persia> rockfx01: This reserves the wiki namespace for you later, for when you need it, allows others to write testimonials to your excellent work, etc.
[05:56] <ddecator> if i've been approved to be a mentor, am i supposed to add myself to the wiki page?
[06:06] <micahg> ddecator: Help -> Report A Bug in Firefox 3.6 is broke until the next ubufox upload to lucid :)
[06:07] <ddecator> micahg, good to know
[06:08] <ddecator> you spend a few days writing papers, and you fall behind o.o
[06:10] <kermiac> pedro - pind re your message earlier
[06:11] <ddecator> hey kermiac
[06:12] <kermiac> hey ddecator - haven't seen you for a couple of days. Congrats mate :)
[06:12] <ddecator> kermiac, thanks =) i've been working on writing papers for my finals. just finishing up tonight so i can get work done again starting tomorrow
[06:13] <ddecator> kermiac, are you talking about pedro v.?
[06:14] <kermiac> yeah, but I just noticed he's not here
[06:15] <ddecator> haha, thought so. he's usually on around 1100 - 2000 utc
[06:16] <kermiac> ah, so at least another 5 hours or so
[06:17] <kermiac> just need to clarify something with him as he sent me a message earlier - nothing major :)
[06:17] <ddecator> most likely. i'm not sure if he gets on consistently at the same time or not, but he's always been on at 1500 when i've been on before
[06:18] <ddecator> come to think of it, i need to talk to him too...
[06:21] <rockfx01> ok done and done
[06:22] <ddecator> not sure what you're talking about, but congrats!
[06:26] <ddecator> micahg, i think that's the first time i've seen 3.7 used as a milestone
[06:30] <ddecator> alright, i should probably get these papers finished so i can finally get some sleep...i'll be back tomorrow night
[07:16] <nonix4> Which would be the recommended method for reporting a bug that is making (still active) firefox infinite-loop?
[07:23] <persia> nonix4: `ubuntu-bug firefox` is a good start.  Attach whatever other useful data you can.
[07:27] <nonix4> With one main caveat: it will try to use firefox, which is in infinite loop. Guess "ubuntu-bug PID" outside X is better?
[07:31] <persia> nonix4: Hrm.  I'm not sure.  I have a feeling that will crash also.
[07:31] <persia> But it ought get you a .crash file, and then you can run apport-bug on the .crash file to make the report (when firefox isn't hung)
[07:45] <nonix4> Managed to submit using w3m from console :)
[07:45] <nonix4> (with w3m being launched by ubuntu-bug)
[07:49] <persia> heh.  Nice.
[07:53] <nonix4> #537158 in case somebody is interested in firefox infinite loops :)
[08:00] <persia> bug #536158
[08:01] <ubot4> Launchpad bug 536158 in widelands "_WIN32 versus __WIN32__ (affects: 1)" [Undecided,Fix released] https://launchpad.net/bugs/536158
[08:01] <persia> bug #537158 !
[08:01] <ubot4> Launchpad bug 537158 in firefox-3.5 (Ubuntu) "Firefox infinite loop, cursor changing between pointer and hand (affects: 1)" [Undecided,New] https://launchpad.net/bugs/537158
[09:06] <BUGabundo_remote> buns di@s
[09:09] <jibel> bonjour BUGabundo_remote
=== yofel_ is now known as yofel
[12:17] <kamusin> :)
[15:32] <ikt> anyone have a log of the meeting?
[15:33] <persia> ikt: irclogs.ubuntu.com doesn't have it?
[15:33]  * persia does but hopes the public resource avoids the complications of file transfers
[15:39] <ikt> yeah it is, cheers :)
[15:39] <persia> Excellent.
=== plars` is now known as plars
[16:12] <m0ar> Filezilla isn't installable from the repos :c
[16:12] <m0ar> Was a few days ago, but somehow it dissapeared from my system and in addition to that it's unreachable from the repos
[16:12] <m0ar> Can someone try to install it, so I can see if it's my end?
[16:13] <BUGabundo_remote> m0ar: $ dpkg -l | grep fire | pastebinit if you please
[16:13] <m0ar> grep file* ?
[16:14] <BUGabundo_remote> fire
[16:14] <BUGabundo_remote> as in firefox
[16:15] <m0ar> I don't see how that's relevant, but sure
[16:17] <m0ar> http://paste.pocoo.org/show/188425/
[16:17] <m0ar> Says I have got FZ installed, but it can't find it
[16:17] <m0ar> meh
[16:17] <m0ar> or is that from the servers?
[16:18] <persia> m0ar: Try dpkg -L filezilla
[16:18] <m0ar> Package filezilla doesn't contain any files
[16:18] <persia> Note that it says "rc" at the beginning.  That means "removed, config files", roughly.  You likely need to install it again.
[16:19] <persia> (and asking in #ubuntu should have gotten this answer)
[16:19] <m0ar> persia: Yeah, but installing doesn't work
[16:19] <m0ar> Ill pastebin
[16:19] <m0ar> http://paste.pocoo.org/show/188426/
[16:20] <m0ar> I posted here since I wasn't able to install it, look at my first message ;D
[16:20] <BUGabundo_remote> m0ar: try #ubuntu-mozillateam
[16:20] <persia> That's because you're on amd64, and it's not ready yet.
[16:21] <persia> Wait.
[16:21] <BUGabundo_remote> ohh fileziila
[16:21]  * BUGabundo_remote needs rest
[16:21] <BUGabundo_remote> soory m0ar
[16:21] <m0ar> BUGabundo_remote: Np ;D
[16:22] <persia> m0ar: Running `rmadison filezilla filezilla-common` will show why.
[16:22] <persia> (and given the versions, #ubuntu+1 would be better than #ubuntu)
[16:23] <m0ar> persia: True. Stilla bug :D
[16:23] <persia> No.
[16:23] <persia> Just a timing issue.
[16:23] <ogra> but in the archive, not in fileziolla
[16:24] <ogra> persia, its definately a bug of the publisher :)
[16:24] <m0ar> ogra: Wonderful, since this isn't #filezilla-bugs
[16:24] <persia> ogra: Do you really think so?  Why should the publisher track cross-arch dependencies?
[16:24] <ogra> persia, i think cjwatson agrees :)
[16:25] <persia> with?
[16:25] <ogra> persia, it should handle arch all/any
[16:25] <m0ar> persia: But it worked a day ago or so?
[16:25] <persia> m0ar: Yeah, a new version was uploaded.
[16:25] <persia> ogra: What should handle arch all/any?
[16:25] <m0ar> persia: Then it's waiting?
[16:26] <persia> m0ar: As I said "Wait"
[16:26] <ogra> persia, the publisher ... well actually Packages.gz
[16:27] <persia> m0ar: https://launchpad.net/ubuntu/+source/filezilla/3.3.1-1ubuntu1/+build/1555594
[16:27] <persia> ogra: So what happens when e.g. ia64 falls behind?
[16:27] <persia> Or sparc?
[16:27] <persia> Or something FTBFS?
=== deryck is now known as deryck[lunch]
[16:28] <ogra> Packages.gz holds the old packages until all binaries are there
[16:32] <persia> ogra: Thanks for the explanation.  I have mixed feelings about it, because sometimes I catch stuff on i386 before it hits other architectures, but I can see the argument.
=== yofel_ is now known as yfoel
=== yfoel is now known as yofel
[16:51] <jcastro> qense: around?
[16:52] <qense> jcastro: yes I am!
[16:52] <persia> jcastro!  Hey.  Is your "How to deal with bugs" one-page flyer PDF up-to-date?
[16:52] <persia> If so, can you point me at it?
[16:53] <qense> jcastro: I'm just rereading my script for the session.
[16:53] <qense> I was*
[16:53] <m0ar> What PDF? :)
[16:53] <jcastro> persia: I didn't have a bug one, that was someone else's, I can look for it though
[16:53] <jcastro> qense: ok I was just making sure I was in the right place/time. :D
[16:53] <jcastro> persia: mine was kind of a high level workflow thing
[16:54] <qense> persia: Ubuntu One has a very nice work-flow for bugs on one of its wiki pages
[16:55] <qense> the .dia file is provided, so it should be very easy to adapt it.
[16:55] <persia> jcastro: Sorry for the misdirect then.
[16:55] <persia> qense: Thanks : I may grab that, but was hoping for a flyer :)
[16:55] <jcastro> no worries
[16:55] <qense> jcastro: Of course, if I would have forgotten the time the session would have been saved
[16:56] <jcastro> qense: I kind of paniced too when I got the email reminder, hah
[17:02] <seb128> bdmurray, hi
[17:03] <bdmurray> seb128: hello
[17:03] <seb128> bdmurray, is there some documentation on the wiki or somewhere about the json searches you run?
[17:03] <seb128> bdmurray, or how to get some extra ones added
[17:03] <bdmurray> seb128: no, not really.  Is there one I could make for you?
[17:03] <seb128> bdmurray, what sort of criterious can you use for those?
[17:04] <bdmurray> seb128: anything launchpadlib can do
[17:04] <bdmurray> this from arsenal is somewhat similar to what I do
[17:04] <bdmurray> http://bazaar.launchpad.net/~arsenal-devel/arsenal/master/annotate/head%3A/scripts/ls-tag-json.py
[17:04] <seb128> bdmurray, so things like "give me bugs on those <list of ubuntu_sources> which have a lucid task" are easy to do?
[17:05] <bdmurray> seb128: yes, mostly easily
[17:05] <bdmurray> er mostly easy ;-)
[17:05] <seb128> thanks for the arsenal pointer
[17:06] <seb128> can I build and test a .json locally to test that easily and then hand it to you?
[17:06] <seb128> I'm not sure how to build those or the format
[17:06] <bdmurray> lines 41-43 are what shows up in bughugger
[17:06] <seb128> do you have some examples?
[17:06] <seb128> do you start from bughugger to build those?
[17:07] <seb128> I basically know what I want bug not how to transode it in a format your tools can deal with ;-)
[17:07] <bdmurray> no, you'd use ls-tag-json.py and the output would be the json data file
[17:07] <seb128> and is there anything I can give the json data file to locally to check it does what I want?
[17:07] <bdmurray> so ./ls-tag-json.py apport-crash evolution firfox will give you all the bugs tagged apport-crash about evolution and firefox
[17:08] <bdmurray> What you are looking for, lucid only tasks, would take a bit more work
[17:09] <bdmurray> Why don't you send me what you are looking for and I'll whip something up and then in the future you could write it and I'll stick it on qa.ubuntu.com?
[17:10] <seb128> bdmurray, in this case I wanted a dx indicators summary
[17:10] <seb128> so one minute I make a list of sources I'm interested in ;-)
[17:15] <seb128> "ido indicator-applet indicator-application indicator-me indicator-messages indicator-session indicator-sound libdbusmenu libindicate libindicator" + bugs tagged indicator-application if possible
[17:15] <seb128> bdmurray, ^ I would like to list all the bugs with a lucid tasks on those
[17:18] <bdmurray> seb128: okay, I'll have something by the end of my day
[17:18] <seb128> bdmurray, you rock, thanks
[17:21] <jcastro> qense: you're doing great!
[17:21] <qense> jcastro: thanks! :)
[17:22] <dako3256> Could someone set Bug #518865 to wish-list
[17:22] <ubot4> Launchpad bug 518865 in blogtk "Enable customisation of toolbar and date/time button (affects: 1)" [Undecided,New] https://launchpad.net/bugs/518865
[17:26]  * persia looks
[17:28] <persia> You'll want to contact the blogtk team about that.  We only set priorities for Ubuntu bugs.
=== deryck[lunch] is now known as deryck
[17:41] <dako3256> I thought Bug Squad could do that?
[17:42] <hggdh> dako3256: we can, but we should not. This bug is an upstream bug, not an Ubuntu one
=== astechgeek is now known as Guest56662
[17:42] <persia> actually, we can't.
[17:43] <hggdh> heh. I thought we could -- but never really tried
[17:43] <persia> We only do it for Ubuntu tasks and Ubuntu bugs (and only have permission, as a group, to do it for those)
[17:43] <persia> hggdh: Go visit the bug : I suspect you don't have access (I don't)
=== Guest56662 is now known as techgeek
[17:49] <hggdh> persia: yeah... I cannot change Importance (but can change Status and package)
[17:50] <persia> hggdh: You can't change the status to Triaged or Won'tFix, can you?
[17:51] <hggdh> persia: indeed I cannot :-)
[17:59] <persia> qense: Great session!
[18:00] <qense> persia: thanks!
[18:01] <qense> afk now!
=== radoe_ is now known as radoe
[18:53] <maco2> what do folks think about adding a "patch-good" tag if a bug report includes people saying they tested the patch or patched-package-in-ppa and found it works, that way people looking for known-good patches to package up have an easier time of it?
[18:56] <persia> maco2: How many patches do we expect to find that are both known-good and don't better belong upstream?
[18:59] <persia> maco2: To put that differently, I think it's a good idea, I'm just unsure how many patches fall into that category, and how many will only be discovered by non-developers.
[19:00] <maco2> persia: oh i do think theyd need to go upstream
[19:00] <maco2> but no harm in putting it in now while waiting for it to be upstreamed, is there?
[19:01] <radoe> persia: many of the patches backported for a SRU? Any one of the "patched-in-debian-unstable-but-too-late-to-wait-for-debian-testing"
[19:01] <maco2> so maybe tag it *and* submit it upstream at the same time?
[19:01] <persia> maco2: I guess.  I'd prefer a tag indicating it was sent upstream if it was.
[19:02] <maco2> persia: there is a tag to say its awaiting upstream input. patch-upstreaminput
[19:03] <persia> radoe: I'd hope that the SRUable bugs and tracking-debian bugs were being given closer review by developers really, where "patch-good" isn't useful when they should just be getting it uploadeed.
[19:03] <persia> maco2: That seems clearer.
[19:04] <maco2> i dont think we have a way of knowing what's SRUable either though
[19:04] <maco2> i mean, read through the whole report...
[19:04] <persia> We have nominations that we ought be using to track that.
[19:05] <maco2> cherry-picks from upstream VCS would be an example of something that we know is already upstream but we cant really find easily in lp
[19:06] <persia> maco2: But why do we even want those in LP in the first place?
[19:06] <persia> Or if we find them, why not have a developer just upload them?
[19:07] <maco2> because the person who finds them may not be a developer?
[19:07] <persia> (and I have a feeling this is on the edge of on-topic here, and probably belongs in #ubuntu-reviews)
[19:07] <maco2> ah that's the channel name
[19:07] <maco2> irssi told me last time i tried /list that i shouldnt do that, so i didnt know how to find other channels
[19:07] <persia> Ah, so you want some escalation path where non-developer reviewers can highlight stuff for higher-priority developer attention?
[19:08] <maco2> right
[19:08] <persia> Generally asking gets channel names :)
[19:09] <persia> OK.  My worry is that by creating that we mind end up with no developers looking at the patches that were not prioritised, and I think we need a mix of triagers and developers looking over *all* the patches.
[19:10] <maco2> i think bugsquad non-devs probably read through more bug reports than devs do as when a dev hits a report they may sit down and spend a few hours fixing it, so probably more people non-devs will see more of these sitting around
[19:10] <maco2> seems like these would be low-hanging fruit
[19:10] <maco2> but right now there's no way to identify them
[19:11] <persia> I see what you're saying.  If you also see what I'm saying then we know the gap :)
[19:12] <maco2> you're saying you hope people don't forget about the higher-level fruit
[19:12] <persia> I'm saying I don't like systems that create distinctions.
[19:13] <persia> And I'm concerned that many patches may be complex enough that non-developers don't know how to review and developers are ignoring them.
[19:17] <maco2> im thinking of throughput
[19:18] <maco2> there's a lot of patches to go through... some are ready to go right now, and some aren't. why not get the ones that are ready uploaded? ...because we can't find them
[19:19] <persia> I'd be willing to consider "patch-good" as a stricltly temporary measure to push through the first bundle, but I think it's a poor solution socially long-term.
[19:19] <maco2> fair enough
[19:21] <persia> As long as we recognise that we're setting a priority because we've only managed to stay even the past year or two, and then we drop it when we get to a manageable point, I think we'll be OK.
[19:21] <persia> But I think the temporary nature of the prioritisation needs to be made clear at the outset.
[19:22] <persia> Otherwise it creates exclusionary boundaries (That's not developer work)
[19:28] <maco2> and see i'm thinking in the other direction as "make it more obvious to non-devs that they can be helpful in this area too, so maybe more of them will do so"
[19:28] <persia> I guess.
[19:29] <persia> I think we have lots of non-devs chasing bugs and making things happen.
[19:29] <persia> I think that developers ignore too much of this.
[19:29] <persia> I think that's part of why we have a backlog.
[19:29] <persia> But I'll agree that the various fusses about "Don't touch workflow bugs" and the like probably complicated matters.
[19:30] <maco2> i still dont quite know what "dont touch workflow bugs" means
[19:30] <persia> I don't think anyone does, which I suspect is part of the problem.
[19:30] <maco2> that greasemonkey script that inserted "WORKFLOW BUG" at the top was useful for knowing what not to touch though :)
[19:36] <persia> Well, no, not really.
[19:36] <persia> Some of that ought get touched.
[19:37] <persia> Others of that ought get moved out of the bugtracker
[19:37] <persia> etc.
[19:37] <persia> Anyway, those are longer-term efforts (but progress is being made).
[19:38] <HandeH> Could somebody help a bit on an odd hardware dependent bug of 3G mobile broadband: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/525049 What do we need more to solve that issue?
[19:38] <ubot4> Launchpad bug 525049 in linux (Ubuntu) (and 1 other project) "3G download speed is very slow compared to Hardy on elderly PIII laptop or Microsoft Windows OSs (affects: 5)" [Undecided,Confirmed]
[19:39] <maco2> O_O the bot now tells the affects count? coooool
[21:54] <blueyed> bdmurray: re bug 514212.. where's the patch? and why ubuntu-reviewers? this is a ffe..
[21:54] <ubot4> Launchpad bug 514212 in jedit (Ubuntu) "Please update jEdit to new stable version 4.3.1 (affects: 1)" [Wishlist,New] https://launchpad.net/bugs/514212
[21:55] <bdmurray> blueyed: because "Upstream changelog diff" was set as a patch once I'd guess
[21:56] <blueyed> bdmurray: no, it said looks like a patch, and asked me.. but that page loaded for trillions of millions of seconds (~30 minutes or so). so in the meantime it was a patch probably.
[21:57] <bdmurray> okay and my script happened to catch it when it was flagged a patch
[21:57] <blueyed> your script subscribes reviewers then, too?
[21:57] <bdmurray> blueyed: yes
[21:58] <blueyed> wouldn't it be easier to search for bugs with a patch (which does not require a tag even)?
[21:58] <blueyed> but ok.. :)
[21:59] <bdmurray> blueyed: well the team is only be subscribed to 'recent' ones and then (in theory) we'll go back and look at older patch attachments
[21:59] <bdmurray> blueyed: the patch was originally only added due to a launchpad notification bug
[21:59] <bdmurray> s/patch/patch tag/
[22:00] <blueyed> I see. Thanks for explaining it.
[22:00] <bdmurray> yep, and I've unsubbed the team
[22:20] <mrmookie> anyone familiar with the following bug? https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/456806
[22:20] <ubot4> Launchpad bug 456806 in mountall (Ubuntu Karmic) (and 1 other project) "mountall vomits a shell onto virtual console when you run vi (affects: 25) (dups: 4)" [High,Fix committed]
[22:20] <mrmookie> it still is not fixed?
[22:21] <charlie-tca> fix committed says there is a fix someplace for it
[22:22] <charlie-tca> It looks to be fixed in lucid, and the fix is pending for karmic
[22:22] <micahg> seems like it was never pushed to -updates after verification
[22:23] <charlie-tca> failed verification on 9.10
[22:23] <mrmookie> lame
[22:23] <charlie-tca> see comment 6, fixed, but a user changed it
[22:26] <charlie-tca> mrmookie: did you try the patch they give?
[22:29] <mrmookie> charlie is that the debdiff?
[22:31] <Linux000> yes, the debdiff is the patch
[22:32] <mrmookie> what's the proper way to patch using the debdiff? I've not patched with one before
[22:34] <mrmookie> I'm pretty new to debian
[22:34] <Linux000> https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff#Applying a Debdiff
[22:35] <mrmookie> thx
[22:41] <mrmookie> says it patched.. rebooting
[22:45] <mrmookie> no change.. :( can't use recovery console.. can't use vi.
[22:46] <mrmookie> "mountall: Cancelled General error mounting filesystems" is overwritten on top of the recovery console when I use the arrow keys
[22:47] <mrmookie> says CONTROL-D will terminate this sheel and re-try but it doesn't do anything
[22:47] <mrmookie> shell
[22:49] <mrmookie> this affects everyone who uses 9.10 server?
[22:57] <mrmookie> wow this is lame.. looks like I can kill mountall and vi works again
[22:58] <charlie-tca> I don't use vi, so it doesn't affect me
[22:58] <mrmookie> it's all editors
[22:58] <mrmookie> and recovery console
[22:58] <mrmookie> not just vi
[22:58] <charlie-tca> I have still never seen the issue
[22:59] <charlie-tca> I have run servers in 6.06, 7.10, 8.04, 8.10, and now in 9.10
[22:59] <mrmookie> strange.. you have a default fstab?
[22:59] <charlie-tca> yup
[23:01] <mrmookie> encrypted home directories?
[23:02] <charlie-tca> no
[23:02] <mrmookie> seems those who are affected are those with custom fstab and/or encrypted home dir's
[23:04] <mrmookie> I still get an error about mounting at boot up but at least now it's not writing over my editor
[23:21] <yofel> hm, anyone familiar with xulrunner?
[23:23] <yofel> (from #ubuntu+1): mediatom-common in lucid depends on libmozjs0d which was part of xulrunner 1.8, that doesn't exist in lucid anymore. In debian testing/unstable there is a libmozjs2d package as part of xulrunner-1.9.1, but that doesn't exist in ubuntus 1.9.1 -> huh?
[23:23] <yofel> the bug in mediatomb-common is clear
[23:23] <yofel> but xulrunner is confusing...