[00:31] <aeoril> darkxst would you be willing to help me a little with how to test this bug?  I think I know how to fix it, but have been unable to test it successfully:  https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1422176
[00:31] <aeoril> pitti helped me a little, and I asked him for further help, but I guess he is unable to respond
[00:34] <aeoril> darkxst I made the changes I think are necessary to /usr/share/apport/apport-gtk to test, but the apport gui failed to start when I did.  I am not sure if there is a way to test the gui from the source branch I downloaded from lp:apport
[00:35] <aeoril> darkxst also, for some reason apport only starts for the first bug, even if I do not muck with it - I think that may be a bug in apport
[00:36] <aeoril> (the gui, even for different executables that crash)
[02:26] <Snow-Man> oh, come *on*.  ipv6 is busted *again*? :(
[02:28] <stgraber> Snow-Man: if you mean bug 1426618, then yes
[02:29] <Snow-Man> stgraber: yes, I was on 1404558
[02:29] <stgraber> not really busted though, works great for about 24h, then you panic and reboot :)
[02:29] <Snow-Man> :þ
[02:30] <stgraber> problem is, in either bug it's not very easy to reproduce. The last time around we considered 24+ hours without a panic to be "fixed". So no easy reproducer typically means no good testcase to make sure that kind of stuff doesn't happen again.
[02:30] <stgraber> anyway, -45 works fine and I'm sure apw or someone else on the kernel team will figure it out quickly...
[02:30] <Snow-Man> I expect -46 probably included some security updates or something tho. :/
[02:33] <stgraber> it had one CVE related to KVM on x86 and it's backporting a bunch of security-related userns changes, no obvious remote security flaw fixes that I can see at least
[02:37] <ScottK> I guess I'm glad I didn't reboot yet.
[02:39] <Snow-Man> ScottK: see, that's the situation I'm in
[02:39] <Snow-Man> I just installed -46 earlier today, in fact.
[02:46] <darkxst> aeoril, use something like `ubuntu-bug gnome-shell`
[02:47] <aeoril> darkxst ok, thanks
[04:55] <aeoril> darkxst well, I fixed and tested the error icons but there is a function call that has deprecated constants in it in apport-gtk (STOCK_CANCEL and STOCK_OPEN).  Should I fix those as well?  If so, how to test?: https://gist.github.com/aeoril/5c906f901a1021594d78#file-gistfile1-txt
[05:17] <darkxst> aeoril, I think you would do something like gtk.button_new_with_label ("_Cancel");
[05:17] <darkxst> not sure how to test though, don't ever recall seeing a filechooser in apport
[05:20] <darkxst> however they are only Deprecated, so probably still there in Gtk?
[05:21] <darkxst> in which case you don't need to fix it
[05:27] <darkxst> aeoril, actually seems the filechooser is not used by any package hooks at all, so don't worry about it ;)
[09:43] <doko> Laney, can you/desktop forward this issue to gnome (?) ?
[19:41] <aeoril> darkxst I am ready to commit my fix for apport LP: #1422176 However, I wanted to make sure I pushed correctly this time.  The command on apport's launchpad page to push is as follows.  Do use this?  bzr push lp:~aeoril/apport/apport I was wondering if I just just do:  bzr push lp:~aeoril/apport instead?  Once you let me know, I will push and do a merge proposal.  Thanks for your help -
[19:41] <aeoril> againg :)
[19:43] <aeoril> Also, when I do the merge proposal, I am assuming I fill in "lp:apport" ...
[19:44] <aeoril> (just making sure before I do all this)
[19:54] <hjd> aeoril: When you create a merge proposal, it should pick the trunk of the project as default, unless you specify something else. (So yes, lp:apport will likely be the default option)
[19:55] <aeoril> hjd what I am really not sure about is the push command though - does that appear correct for lp:apport? bzr push lp:~aeoril/apport/apport
[19:55] <aeoril> (and thanks :
[19:55] <aeoril> :)
[19:55] <aeoril> not sure about the "double apports"
[19:57] <aeoril> Sorry about all the typos - it is cold here - at least I hope it is just that!
[19:58] <hjd> aeoril: I understand your question. To break it down a bit, it's really lp:~username/project/branchname. So it will store the branch under your username, but know that it is linked to a particular project (I would guess this is the part that makes it turn up on https://code.launchpad.net/apport) and the last part is basically some descriptive name so that you (and others) can see what the branch is about. For instance
[19:58] <hjd> ~username/apport/fixes-typos or ~username/apport/stop-crashing-on-startup
[20:03] <hjd> aeoril: Does that make sense? :)
[20:04] <aeoril> hjd oh, yes - I remember now from my first bug - yes, of course - so, for my fix, a good push command would be "bzr push lp:~aeoril/apport/fixes-bug-1422176"
[20:04] <aeoril> thanks!  I had already forgotten!
[20:04] <aeoril> hjd you explained it very well.  Thank you.
[20:10] <hjd> aeoril: You're welcome. Yes, that branchname sounds good.
[20:11] <aeoril> hjd ok, cool!
[20:20] <hjd> aeoril: Did you push your changes? :)
[20:22] <aeoril> hjd no, not yet - I am hunting around for the code I fixed for my first bug - lp: #1422113 to see what exactly I did with it, but cannot find it yet - it has been committed, but I am not having much luck finding the actually code diffs and stuff and how I phrased the commit message, etc. on launchpad - very frustrating!
[20:24] <aeoril> hjd I guess the merge proposals "disappear" once they are accepted and integrated?  I viewed all the merge proposals on lp:ubiquity, and did not find mine
[20:25] <hjd> aeoril: Yes closed ones are hidden. But fear no, if you go to you user page, and look under "Code" you should be able to toggle branches with any status which you have added to Launchpad. You should find it there.
[20:26] <aeoril> hjd ok, will do
[20:27] <hjd> aeoril: Another small trick is, on the branch page, you can click to link it up to a bug report. Then it will appear just below the description and tags (included the related merge proposal. This makes it easier to find, and also let's other people see that someone has a suggested fix for the issue in question. :))
[20:29] <aeoril> hjd doesn't "bzr commit --fixes lp:1422176" do that?  That is what I have been doing, and what I am about to do with this bug in my local repo before pushing ...
[20:30] <aeoril> but, I saw that link to click you are talking about previously - I thought that bzr commit option did that though
[20:35] <hjd> I'm not familiar with the --fixes option, so I'm not actually sure what it does. The ubiquity-bug you linked to only lists lp:ubiquity under Related branches, though.
[20:37] <aeoril> hjd ok, I pushed the branch.  Looks ok to me:  https://code.launchpad.net/~aeoril/apport/fixes-bug-1422176
[20:48] <aeoril> hjd darkxst ok, I linked the branch to the bug like you taught me, then did the merge proposal.  I hope the reviewer finds it acceptable!
[20:50] <aeoril> hjd - nice!  I see the "related branches" links now under the bug report - thanks! :)
[20:50] <hjd> aeoril: Yes, looks good.
[20:51] <aeoril> hjd cool, thanks for the help - my second one! :D
[20:51] <hjd> aeoril: Yes, it shows up there now. You may also want to change the status of the bug report to "In progress" and assign it to yourself to indicate that the bug is being actively worked on.
[20:52] <aeoril> hjd I can actually just do that?
[20:52] <aeoril> I figured I would have to have some kind of special status or something ...
[20:54] <hjd> No, there's only a couple of statuses are restricted (Triaged and Won't Fix, see also https://wiki.ubuntu.com/Bugs/Bug%20statuses).
[20:56] <hjd> It's a good habit to always leave a comment when changing status to explain why it was changed though. And if in doubt which status applies, just ask :)
[20:56] <aeoril> hjd I see that there are two places I can change the status - one for "Ubuntu GNOME" and one for "apport (Ubuntu)" - the Ubuntu GNOME was in "triage" so I changed it, but not sure if I should change "apport (Ubuntu)" since it is still "new" ...
[20:57] <aeoril> Unfortunately, I did not leave a comment - can I fix that?
[20:59] <hjd> Sure, it's just like leaving a normal comment at the end.
[21:00] <hjd> I don't know if Ubuntu GNOME has a specific workflow, but if you read the wikipage I linked to about the statuses above, things should hopefully become a bit clearer.
[21:00] <hjd> (I know there's a diagram showing how a bug goes from one status to the next, but couldn't find it right now)
[21:01] <aeoril> hjd ok, i'll read the link - right now I am going to take a break because I this process is still nerve wracking for me since I am new!
[21:02] <darkxst> aeoril, looks good
[21:03] <aeoril> darkxst thanks! :)  My second one!
[21:03] <hjd> aeoril: No problem. Just take it gradually, it can be a lot to digest all at once. :)
[21:03] <aeoril> darkxst would you still suggest looking at that second one you gave me along with this one as my third?
[21:04] <darkxst> aeoril, we mainly use the ubuntu GNOME project for milestone tracking (so they show up here https://launchpad.net/ubuntu-gnome/+milestone/vivid)
[21:05] <darkxst> aeoril, yes, that would be a good introduction to using quilt ;)
[21:10] <aeoril> darkxst ok, will do - if you have the bug number off the top of your head, could you give i to me again?  It will save me from having to look in my IRC logs ...
[21:11] <aeoril> why can't I type anymore?????
[21:11] <darkxst> bug 1425349
[21:11] <aeoril> I'll blame it on my keyboard...
[21:13] <aeoril> darkxst cool, bookmarked - now for a break!