[09:28] <doko> jtaylor, fyi, https://bugs.launchpad.net/ubuntu/+source/python-scipy/+bug/1426841
[09:28] <doko> any idea?
[13:23] <aeoril> darkxst I did this for bug 1425349 :  https://gist.github.com/aeoril/45d72cf33fdccfae4df3  It said it was out of date, but he revision I branched seems to be newer - did I do that correctly?
[13:45] <aeoril> darkxst oh, I guess the branch I downloaded is older - version 3.2 vs. branch 3.14
[13:45] <aeoril> darkxst not sure how to get the right branch then
[16:15] <mitya57> aeoril: UDD branch for gnome-shell is outdated, see http://package-import.ubuntu.com/status/gnome-shell.html
[16:16] <mitya57> There is lp:~ubuntu-desktop/gnome-shell/ubuntu but it also looks abandoned :(
[16:16] <mitya57> So if you want to submit a patch, you will have to use traditional techniques
[16:18] <mitya57> Oh, you were needing mutter, not gnome-shell... But no much difference: http://package-import.ubuntu.com/status/mutter.html
[20:03] <darkxst> aeoril, use pull-lp-source and create a debdiff with the fix for mutter
[20:06] <aeoril> darkxst oh, reading about I see pull-lp-source pulls the latest version - I had thought it would pull the version in my distro.  I had already thought of that, but thought it would not pull the latest.  Thanks.
[21:29] <aeoril> darkxst I seem to be missing something - code already seems updated in latest Ubuntu mutter code:  https://gist.github.com/aeoril/8f00a26d369fec544330
[21:29] <aeoril> darkxst you mentioned quilt - is there something other than updating this code that needs to be done with patches somehow?
[21:30] <aeoril> darkxst oh, am I to apply these new Ubuntu changes upstream?  Is that what this is all about?
[21:31] <aeoril> I guess in debian?
[21:31] <aeoril> (not upstream - they are already in gnome - but in debian?)
[21:32] <aeoril> well, new gnome changes ...
[21:39] <darkxst> aeoril, ok, I didnt actaually check that was already there
[21:39] <darkxst> clearly that commit does not fix this bug
[21:39] <aeoril> darkxst yes, I was thinking that ... :)
[21:39] <darkxst> quilt is used to apply upstream (or custom) patches via packaging
[21:40] <darkxst> patches go into debian/patches/ folder
[21:40] <aeoril> darkxst upstream -> quilt -> Ubuntu right?  In that direction?
[21:40] <darkxst> no quilt is a tool, used to add patches to an Ubuntu package
[21:41] <aeoril> darkxst yes, sorry for my unclear visual - that is what I meant ...
[21:41] <aeoril> (I have already read about quilt some)
[21:41] <darkxst> aeoril, yes
[21:42] <aeoril> darkxst I was just trying to show "quilt is a tool that applies upstream (or custom) patches via packaging *to* ubuntu" - verifying the direction (ie, quilt is not used to apply Ubuntu patches to upstream, if that even ever makes any sense)
[21:43] <aeoril> darkxst I am sure this bug is too much for me then, at this stage ...
[21:43] <aeoril> (if the fix is not known)
[21:44] <aeoril> darkxst unless I am hunt around for a different commit for the fix?
[21:44] <aeoril> bisecting and whatnot again ...
[21:46] <darkxst> aeoril, if its even fixed
[21:47] <darkxst> I actually don't see it here even on 3.14 (well I have a few but not exactly flooded)
[21:51] <aeoril> darkxst wouldn't it be more appropriate to give it to upstream to fix then, if it is not fixed?
[21:53] <aeoril> (I learned from my first bug try how difficult things can get)
[21:57] <darkxst> aeoril, I wouldn't worry about it, only linked it since it looked like it was an easy fix
[21:58] <aeoril> darkxst ok - if you have any other good ones for me, just let me know.  Thanks!
[21:58] <darkxst> aeoril, see https://launchpad.net/ubuntu-gnome/+milestone/vivid
[21:58] <aeoril> darkxst ok, cool - will do ... :)
[22:14] <darkxst> aeoril, bug 1315442
[22:16] <aeoril> darkxst I was looking at the bugs in the link you gave, but you seem to have given me another nice one!  Thanks! :)
[22:52] <aeoril> darkxst bug 1315442 appears in trusty, but the code is redone in vivid and the bug no longer appears to happen - line 79 no longer refers to the same code, and testing has no problem in Ubuntu GNOME vivid - this is just booting off a liveCD in a vm from around 02/27/2015.  the trusty I tested was ubuntu, the vivid I tested was Ubuntu GNOME, however - should I go ahead and thoroughly check
[22:52] <aeoril> from trusty forwards?  (Ubuntu 14.04, Ubuntu/Ubuntu GNOME 14.10, Ubuntu 15.04) - it looks like it just needs to be fixed for 14.04[.x] and maybe 14.10 but may be OK for vivid ... would the script be different for Ubuntu GNOME vs. Ubuntu regular?  If you don't know, I can go ahead and load up in various VMs and see.  Also, where would that script live on launchpad?  I did not find it in
[22:52] <aeoril> the source directory when I branched from lp:gdm???
[22:53] <aeoril> darkxst I re-verified problem/fix worked in trusty Ubuntu GNOME though
[22:54] <aeoril> (my vivid test was a daily build for vivid Ubuntu GNOME from around 2/27/2015 in a vm)
[22:55] <aeoril> darkxst I guess I need to do all that testing and see when the bug went away, but I would really like to know where to get my hands on the script from launchpad - I have no idea at this point
[22:56] <darkxst> if its fixed in vivid, then it atleast needs to be fixed via SRU to trusty
[22:56] <darkxst> the file is in the debian folder of gdm package
[23:01] <darkxst> aeoril, except it isnt fixed in vivid yet
[23:01] <darkxst> so you would fix in vivid, then SRU to trusty
[23:01] <aeoril> darkxst I tried in vivid from the live cd - it did not seem to have the problem???
[23:02] <darkxst> the syntax error is definitely there though
[23:02] <aeoril> darkxst the code isn't even the same in that area ...
[23:02] <darkxst> its just a different line number
[23:02] <aeoril> really?  I counted the then/fi's - I can check again ...
[23:03] <aeoril> darkxst maybe I was in the wrong place ...
[23:04] <aeoril> darkxst gosh darn it!  I was looking down a little - no wonder the code looked all different!  Yes, will fix - where does that script live where I can fix it on launchpad?  What source package or branch do I use?
[23:05] <aeoril> (it is not in the gdm source from what I could grep)
[23:05] <darkxst> pull-lp-source gdm
[23:05] <darkxst> its in the debian folder
[23:05] <aeoril> darkxst hmmm ... I did "bzr branch lp:gdm" - I'll do that instead
[23:06] <darkxst> aeoril, many of the udd branches are dead and/or broken
[23:06] <aeoril> darkxst so, I should generally use pull-lp-source?
[23:06] <aeoril> not bzr branch?
[23:07] <darkxst> aeoril, well if the bzr branch is upto date that is fine to use
[23:07] <darkxst> if the package lists a Vcs-bzr in control then you should use that branch
[23:10] <aeoril> darkxst ok, I'll remember that then - do you mean if it has a line in it that says "To get the code use 'bzr branch lp:ubiquity" for instance (paraphrasing) on the launchpad web page?
[23:10] <aeoril> darkxst or do you mean in debian/control?
[23:11] <darkxst> aeoril, yes in debian/control
[23:12] <aeoril> darkxst ok, sure thing - thanks for the tip.  Will do the fix then.
[23:15] <aeoril> darkxst should I be worried about this? gpgv: Can't check signature: public key not found | dpkg-source: warning: failed to verify signature on ./gdm_3.14.1-0ubuntu2.dsc
[23:15] <aeoril> (when I did pull-lp-source)
[23:23] <aeoril> darkxst uggghhh ... no source control!
[23:24] <darkxst> aeoril, no that doesnt really matter
[23:24] <aeoril> darkxst but it makes it more painful!
[23:25] <darkxst> aeoril, why? its a very simple fix, just make a debdiff
[23:25] <aeoril> darkxst how do I push to launchpad without bzr?
[23:25] <darkxst> attach a debdiff to the bug report
[23:30] <aeoril> darkxst oh, ok - so no problem then.  So, just to make sure, 'dhc -i' (add my comment to ChangeLog), (make my code change), 'sudo apt-get build-dep gdm', 'builddeb -S', 'debdiff old.dsc new.dsc > debdiff_name.debdiff', then attach debdiff to bug ... /??
[23:31] <darkxst> you shouldnt need build-dep in this case, but everything else is correct
[23:31] <aeoril> darkxst oh, since I am working on trusty, I guess I need to do sbuild before debdiff?
[23:32] <aeoril> or not?
[23:32] <darkxst> no
[23:32] <darkxst> but you should fix vivid first
[23:33] <aeoril> darkxst so I need to do all this from a vivid vm?  I was going to build on my trusty build machine then scp over the .debs and install on a vivid LiveCD to test ...
[23:33] <aeoril> hence, sbuild
[23:33] <darkxst> yes then sbuild it
[23:34] <aeoril> darkxst do you typically have a vivid vm and do fixes for vivid on it, then have a trusty vm and do fixes on it, have a 14.10, etc?  As opposed to a single machine using sbuild?
[23:36] <darkxst> aeoril, I build everying in sbuild, then mostly test in vm's
[23:36] <darkxst> or jhbuild when writing  GNOME patches
[23:37] <aeoril> darkxst so, that is what I am doing - good to know.  I will continue to do that then.  My sbuild machine is 14.04.1, with various sbuilds for diffferent releases to build/test, then shoot over .debs and install on vms to test
[23:45] <aeoril> darkxst just as an fyi, I have to stop for today, but should be able to get the fix in and tested for tomorrow.  Thanks.