=== Hellow_ is now known as Hellow
=== BUGabundo1 is now known as BUGabundo
[00:43] <grepory> is there a google calendar or something that i can subscribe to that will give me bugdays and the like?
[00:43] <grepory> because that, my friends, would be awesome.
[00:47] <mrooney|w1> grepory: that is true, a calendar with bugsquad/control/qa meeting would be neat
=== mrooney|w1 is now known as mrooney|w
[00:48] <grepory> mrooney|w: super useful.  and bug days.  basically any of these events that i get e-mails about.  or even just attaching ics invites would be handy.
=== BUGabundo1 is now known as BUGabundo
[00:52] <hggdh> I think there is one somewhere...
[00:54] <hggdh> well here it is: http://fridge.ubuntu.com/calendar but it is not listing bugsquad meetings right now (we moved out of -meetings into here
[00:54] <micahg> I thought they were thinking about that with the fridge
[00:55] <grepory> nice
[00:55] <grepory> that is so awesome
[00:57] <grepory> i guess a separate QA calendar that isn't so noisy would be nice, too.
[00:57] <grepory> or i can just turn off the ubuntu calendar when i don't want to see it. :)
[00:58] <grepory> or just copy events from the fridge calendar to a calendar of my own when i want to attend.  regardless.. very nice.
[01:21] <grepory> should bug 358339 be set to confirmed?  i'm not sure there needs to be more action taken on it
[01:21] <ubot4> Launchpad bug 358339 in notify-osd "Use a slight gradient in notifications" [Wishlist,New] https://launchpad.net/bugs/358339
[01:22] <crimsun> it's already assigned to someone, so i'd let mpt adjust status
[01:22] <grepory> kk
[01:23] <grepory> i think that most of the remaining new bugs are in situations like this one.
[01:23] <grepory> or not.
[01:30] <micahg> If anyone thinks that bug 406454 would be helpful, maybe you should select This bug affects me too
[01:30] <ubot4> Launchpad bug 406454 in malone "[Usability] cannot figure out in which package version a fix was released" [Undecided,Confirmed] https://launchpad.net/bugs/406454
[01:31] <hggdh> just did it
[01:31]  * kklimonda too :)
[01:32] <kklimonda> I also don't like that package branches are linked to bugs :/
[01:33] <micahg> hmmm
[01:33] <micahg> that can be helpful for packagers :)
[01:33] <micahg> so they don't have to work to hard to patch something
[01:34] <micahg> you can just branch the branch and then they can pull the revision with the patch (or something of the sort)
[01:35] <bdmurray> kklimonda: why don't you like it?
[01:38] <kklimonda> bdmurray: when I click on a branch linked to bug I'd expect to get to the page where I can see a branch that fixes a bug and not packaging branch linked to 3 dozens of other bugs
[01:40] <micahg> kklimonda: that's the branch home page
[01:41] <micahg> maybe LP 3.0 would have better UI
[01:41] <micahg> *will
[01:42] <micahg> kklimonda: on the LP-dev list, they are talking about 3.0 UI right now, maybe you want to sign up and comment?
[01:42] <kklimonda> micahg: I know where does the link take me. What I don't get is how is packaging branch linked to actual fix of a bug if it doesn't contain a fix itself and only a "metadata" (i.e. debian/ directory)
[01:43] <bdmurray> kklimonda: could you provide an example?
[01:43] <micahg> kklimonda: so whoever is going to fix it, knows where to pull the code from for the most updated version
[01:44] <micahg> AFAIUI
[01:44] <kklimonda> bdmurray: for example https://code.edge.launchpad.net/~ubuntu-desktop/transmission/ubuntu
[01:45] <kklimonda> bdmurray: now, I don't see a connection between this branch and fix for any SIGSEGV.
[01:45] <kklimonda> (for example)
[01:45] <micahg> kklimonda: it can load the latest upstream source code
[01:46] <micahg> and show you the latest ubuntu/debian dir associated
[01:46] <kklimonda> micahg: hmm?
[01:46] <micahg> so depending on where the changes are needed you can make them
[01:46] <bdmurray> these are more interesting
[01:46] <micahg> generally, an ubuntu fix will become a patch in the debian dir
[01:46] <bdmurray> https://code.edge.launchpad.net/ubuntu/+source/transmission
[01:47] <bdmurray> and https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/karmic/transmission/karmic
[01:47] <kklimonda> bdmurray: I agree - here at least I have whole code so I can actually try to find a piece that fixes a bug
[01:48] <micahg> maybe the wrong branch was linked?
[01:48] <bdmurray> yes, that's what I would think
[01:49] <kklimonda> no, both branches - ~ubuntu-desktop/<package>/ubuntu and ~ubuntu-branches/<release>/<package>/ are now linked to bugs
[01:49] <micahg> kklimonda: maybe ask the maintainer of the branches the purpose?
[01:49] <kklimonda> (I think it's a step forward and so my understanding is that it's still work in progress..)
[01:53] <kklimonda> I think I'll have to take to james_w about his work on bzr-buildpkg and whole vcs-pkg idea. I'm really interested in it
[03:07] <crimsun> andresmujica: you probably want to idle in #ubuntu-audio-help
[03:07] <crimsun> since you're triaging these linux+pulseaudio bugs
[03:08] <andresmujica> done :)
=== scream is now known as NonvocalScream
[07:01] <dholbach> good morning
=== _Ranakah is now known as Ranakah
=== persia` is now known as persia
=== persia is now known as persia`
=== persia` is now known as persia
[09:32] <matti> *blink*
=== ejat is now known as e-jat
=== dholbach_ is now known as dholbach
[14:28] <Awsoonn> fresh install of karmic with encrypted home, first login gives an error "Could not update ICEauthority file /home/dereck/.ICEathority" what package whould this be reported against?
[14:38] <dez> Hi, I just want to start helping on ubuntu development and thought the first step should be bugfxing. anyone can help me with some questions?
[14:39] <pedro_> dez, best place to ask is #ubuntu-devel
[14:39] <pedro_> here we discuss bug management rather than fixing
[14:39] <pedro_> look at the topic
[14:40] <dez> pedro_: sorry I have just joined this channel because I read it on bugsquad/gettingInvolved webpage
[14:42] <Awsoonn> dez: I'll take any questions you have in either channel
[14:42] <Awsoonn> welcome to the community :)
[14:43] <dez> Awsoonn: thanks :)
[14:43] <dez> Awsoonn: the point is that I am computer engineer and since I have beed using ubuntu for years I want to start helping
[14:44] <dez> Awsoonn: and I really don't know how to start... :P
[14:44] <Awsoonn> great! I assume you know c/c++?
[14:44] <dez> yes
[14:45] <Awsoonn> awesome, well the best way to start is to find somethign that annoys you and fix it. It's prety generic advice I know, but it works. :)
[14:45] <dez> Awsoonn: I assume there is a bug list or something like this, right?
[14:45] <Awsoonn> of course, http://launchpad.net
[14:46] <Awsoonn> there are a few 100,000 bugs there though
[14:46] <dez> cool! so this will be my entrance point... :)
[14:46] <Awsoonn> what kind of area of development are you most interested?
[14:47] <dez> I prefer working on core features, but for starting I will be glad to help on whatever needed
[14:49] <Awsoonn> cool, I am interested in the same area. You can do it to, my first patch ever was in apt afterall, and it doesn't get much more core than that. :)
[14:49] <dez> yes, you are right :)
[14:51] <dez> I supposse the first fix is hard to implement, mostly in the how-to-start and how-to-pack-it rather than the coding side
[14:51] <Awsoonn> *nods*
[14:52] <Awsoonn> you might even try fixing a typo for your firxt bug just to learn the workflow. :)
[14:54] <dez> I will check the buglist and then read some info. I will come back with more questions later
[14:54] <dez> many thanks Awsoonn :)
[14:54] <Awsoonn> anytime ;)
[14:55] <dez> Awsoonn, is there any page where the bugfixing workflow is explained?
[14:56] <Awsoonn> yes and no, there is a 'bug fixing tutorial' somewhere in there
[14:56]  * Awsoonn looks for the link
[14:57] <Awsoonn> https://wiki.ubuntu.com/Bugs/HowToFix
[14:58] <dez> Awsoonn, many thanks again.
[16:22] <ColdWind> cans omeone raise importance on bug #409673 ?
[16:22] <ubot4> Launchpad bug 409673 in poppler "latest poppler prevents pdftex/pdflatex from working correctly" [Low,Confirmed] https://launchpad.net/bugs/409673
[16:22] <ColdWind> seb128: ping? ^^^
[16:22] <seb128> ColdWind, changing status will not make any difference
[16:22] <seb128> it just needs sponsoring
[16:22] <ColdWind> it affects basic functionality of pdftex, pdflatex, kile, and probably other programs based on those
[16:22] <ColdWind> seb128: ok :p
[16:22] <seb128> try asking #ubuntu-devel
[16:23] <seb128> I would upload if that was not so much to download
[16:23] <ColdWind> thanks seb128
[18:26] <charles_> is there anyone here who can do admin-type work on brainstorm.ubuntu.com?
[18:27] <Pici> charles_: Have you tried asking in #ubuntu-brainstorm ?
[18:27] <charles_> yes, I'm asking there too :)
[18:28] <charles_> just trying to cast a wider net
[18:28] <Pici> Just making sure ;)
[18:33] <chrisccoulson> hggdh - can you trigger bug 413660?
[18:33] <ubot4> Launchpad bug 413660 in brasero "nautilus crashed with SIGSEGV in strcmp()" [Medium,Triaged] https://launchpad.net/bugs/413660
[18:33] <hggdh> chrisccoulson, under gnome it was immediate, and made the system unusable. Under kde, I could
[18:33] <hggdh> at will
[18:34] <chrisccoulson> hggdh - would you mind posting the output of "gvfs-mount -li" to somewhere like pastebin?
[18:34] <chrisccoulson> i can see where the issue is but i'm just interested;)
[18:36] <chrisccoulson> it seems to be related to the fact you have a GVolume without an associated unix device path, which is quite believable, but I'm not sure of what sort of volume that would be
[18:36] <hggdh> chrisccoulson, http://pastebin.com/f3525b313
[18:38] <chrisccoulson> hggdh - thanks
[18:38] <chrisccoulson> as suspected, you've got a volume with no unix-device property
[18:38] <chrisccoulson> that's wierd though :-/
[18:38] <chrisccoulson> would be good to attach that to the bugzilla report
[18:42] <chrisccoulson> hggdh - do you have a CD in your drive?
[18:49] <hggdh> chrisccoulson, I *should* not, let me check
[18:49] <hggdh> nope, no CD loaded
[18:50] <chrisccoulson> hggdh - thanks. i just chatted to davidz on #gnome-hackers and he said that nothing should assume that a GVolume has a unix-device property. so the fix i have on my computer here seems correct
[18:52] <hggdh> cool. Fix to libbrasero, or to Nautilus?
[18:56] <hggdh> chrisccoulson, if you want me to test it, no prob. I can build it here
[19:08] <chrisccoulson> hggdh - if you don't mind building it, the patch i was going to propose is here: http://pastebin.com/m49c24780
[19:08] <chrisccoulson> i've got to disappear to make some dinner now
[19:08] <hggdh> chrisccoulson, will build it
[19:08] <chrisccoulson> thanks:)
[19:19] <hggdh> ok, now building a2~ppa1 to test (locally)
[19:22] <hggdh> huh? I am getting "only garbage was found in patch input". Time to look at it :-(
[20:42] <hggdh> chrisccoulson, it works. At least, so far ;-)
[21:03] <chrisccoulson> hggdh - thanks for testing. it's fixed upstream now too, although there are some extra checks in the upstream fix too
[21:04]  * albert23 just verified the upstream patch :-)
[21:09] <hggdh> chrisccoulson, welcome. At least now I have a working gnome ;-). I guess we can wait for the upstream fix (we do have a bypass)
[21:10] <chrisccoulson> hggdh - upstream already fixed it too. i'm going to push the change to bzr now - probably not a good idea to wait for the next upstream tarball with this one ;)
[21:12] <hggdh> chrisccoulson, personally, I agree with pushing it now, since I am not sure on what conditions will cause the error (yes, I did understand the patch, but am still unsure on *why* I got it
[21:12] <hggdh> and a lot of people did not
[21:12] <hggdh> albert23, so you are all set?
[21:13] <albert23> hggdh: yes I am
[21:13] <hggdh> cool. One more bug bites the dust
[21:13] <chrisccoulson> hggdh, you got it because the GduVolumeMonitor on your machine lists a GVolume without a unix-device property (that's as much as I can say, as I'm not sure why that volume doesn't have this property though)
[21:13] <chrisccoulson> i chatted with davidz, and he said that property is not mandatory
[21:13] <albert23> hggdh: do you also see a non existing cdrom drive in nautilus? I think that might trigger the bug?
[21:13] <chrisccoulson> so it's totally normal for it to be not there
[21:14] <chrisccoulson> a non-existing cdrom drive could be related actually
[21:14] <chrisccoulson> you mean there is an icon for a drive which isn't there?
[21:14] <hggdh> chrisccoulson, yes. But I *do* have a DVD/CD unit
[21:14] <albert23> If I click it it says /dev/scd1 does not exist, which is correct, the real cd is scd0
[21:15] <chrisccoulson> albert23 - could you post the output of "devkit-disks --dump" and "gvfs-mount -li" somewhere (pastebin)?
[21:15] <chrisccoulson> hggdh - in your case then, i think there is probably no other issue than the brasero bug :)
[21:15] <hggdh> heh
[21:15] <hggdh> bloody brasero, mesays
[21:17] <hggdh> I correct myself -- there is a cdrom0, pointed to /dev/hda
[21:17] <chrisccoulson> hmmm, that is a bit wierd then
[21:19] <hggdh> I wonder if this is a left over, this machine has gone through Hardy to Karmic upgrades
[21:20] <albert23> chrisccoulson: http://paste.ubuntu.com/253344/ is devkit-disks
[21:21] <albert23> and http://paste.ubuntu.com/253346/ is gvfs-mount
[21:22] <chrisccoulson> do you have a CD drive anywhere in your /etc/fstab?
[21:22] <hggdh> there you go!
[21:22] <albert23> chrisccoulson: arg, yes indeed
[21:22] <hggdh> yay. Certainly a left over
[21:22] <chrisccoulson> could you try deleting it?
[21:23] <hggdh> http://pastebin.com/f6f3e1001
[21:23] <hggdh> much better, now
[21:24] <albert23> chrisccoulson: yes, it's gone now
[21:24] <hggdh> so, I guess, this might impact only users that have been upgrading since before devkit
[21:24] <chrisccoulson> albert23 - fantastic:)
[21:24] <chrisccoulson> yeah, i will mention this to pitti when he's back and ask him what he thinks
[21:24] <hggdh> btw, my fstab entry was for /dev/hda, so there
[23:04] <BUGabundo> hey guys
[23:27] <plars> bdmurray, or anyone else that might know... I'm curious if there are any documented policies concerning a pragmatic support to old bugs, for instance, bugs that say "hey I tested this daily build of {hardy, intrepid, jaunty, etc} and it won't install for me"
[23:29] <plars> is it realistic to go through the process of "install the final intrepid image and see if it was still broke", wait 3 months for them to never respond, then mark it invalid?  Or is there any problem with saying "hey, sorry this went so long with nobody responding, but we're in karmic now.  Would appreciate your further testing with karmic and file a new bug if it's still not working for you"
[23:34] <mrooney|w> plars: I think either is acceptable
[23:34] <mrooney|w> If the bug sounds easy to reproduce, I'd try to verify on a livecd / VM
[23:34] <mrooney|w> on Karmic
[23:35] <plars> mrooney|w: my particular issue is with bugs that are very very old, and on things like daily images for a past release cycle
[23:35] <plars> mrooney|w: right, on current release it's a whole different story
[23:35] <greg-g> the most common thing done is option 2, if it is fixed in Karmic/$DevVersionOfUbuntu and really important to backport to older supported releases, they can file  a SRU
[23:35] <mrooney|w> plars: yeah it doesn't matter so much if it is fixed in Intrepid final, unless it is important enough to warrant an SRU
[23:36]  * greg-g nods
[23:36]  * mrooney|w waves to greg-g
[23:36] <greg-g> heya mrooney|w, how goes?
[23:37] <mrooney|w> pretty good, how about yourself?
[23:38] <plars> to take the notion a step further...
[23:39] <plars> would it be worth considering writing a quick script to generate a list of all the bugs file before hardy development started
[23:39] <plars> exclude things like bug#1 of course
[23:39] <plars> and have a bug day where that list is searched for bugs that are obviously against versions where support has long expired
[23:39] <plars> and close them with some friendly stock reply
[23:40] <greg-g> mrooney|w: doing really good, actually. :)
[23:40] <plars> I don't think you could just script the whole process... there may be some things lurking in there that are clearly reaching further than the current release
[23:40] <greg-g> plars: bugs filed from that era could still be around
[23:41] <greg-g> no reason why a bug in vrsion 1.2 in some package isn't inherently  valid in version 1.9 in Karmic
[23:41] <greg-g> which is why we need someone to test the test case for each bug in Karmic
[23:41] <plars> greg-g: true, but I suspect there's a lot of cruft that could easily be removed
[23:41] <plars> packages that don't exist any more, image doesn't work, etc
[23:42] <greg-g> if the package doesn't edist anymore in any support Ubuntu version, then yeah
[23:42] <plars> additionally - unless someone is willing to go back and retest, the bug is not going to progress
[23:42] <greg-g> well, again,  the prefered/most common method is to test in development, and if fixed and need to backport, do an SRU
[23:42] <greg-g> no need to test old images of Ubuntu until the fix is in Karmic
[23:43] <greg-g> of course, I'm not the bugmaster
[23:43] <greg-g> :)
[23:43] <plars> greg-g: but in this case, if the bug was against a version for which an SRU can no longer be filed...
[23:43] <greg-g> plars: make sure that the bug is not present in Karmic, still.
[23:43] <plars> sorry, it's friday afternoon and I'm just being philosophical :)
[23:44] <greg-g> 'tis cool :)
[23:44] <greg-g> always test in Dev, move on from that outcome of that.
[23:48] <greg-g> does my reasoning make sense?
[23:49] <plars> of course, just thinking about the general volume of bugs problem
[23:50] <greg-g> yeah, that one is a tough one to deal with.
[23:51] <greg-g> I've mostly just tried to find packages that I use a lot myself and sign up for the bug mail so i can stay on top of it (in theory)
[23:51] <greg-g> we just need more of that and $some_awesome_new_process
=== BUGabundo1 is now known as BUGabundo