/srv/irclogs.ubuntu.com/2015/03/01/#ubuntu-devel.txt

=== doko_ is now known as doko
dokojtaylor, fyi, https://bugs.launchpad.net/ubuntu/+source/python-scipy/+bug/142684109:28
ubottuLaunchpad bug 1426841 in python-scipy (Ubuntu) "python-scipy autopkg test fails in vivid" [Undecided,New]09:28
dokoany idea?09:28
aeorildarkxst 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:23
ubottubug 1425349 in mutter (Ubuntu) "Don't pass configure events on the composite overlay window to MetaStackTracker (aka: STACK_OP_RAISE_ABOVE: window not in stack)" [Medium,Triaged] https://launchpad.net/bugs/142534913:23
aeorildarkxst oh, I guess the branch I downloaded is older - version 3.2 vs. branch 3.1413:45
aeorildarkxst not sure how to get the right branch then13:45
mitya57aeoril: UDD branch for gnome-shell is outdated, see http://package-import.ubuntu.com/status/gnome-shell.html16:15
mitya57There is lp:~ubuntu-desktop/gnome-shell/ubuntu but it also looks abandoned :(16:16
mitya57So if you want to submit a patch, you will have to use traditional techniques16:16
mitya57Oh, you were needing mutter, not gnome-shell... But no much difference: http://package-import.ubuntu.com/status/mutter.html16:18
darkxstaeoril, use pull-lp-source and create a debdiff with the fix for mutter20:03
aeorildarkxst 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.20:06
aeorildarkxst I seem to be missing something - code already seems updated in latest Ubuntu mutter code:  https://gist.github.com/aeoril/8f00a26d369fec54433021:29
aeorildarkxst you mentioned quilt - is there something other than updating this code that needs to be done with patches somehow?21:29
aeorildarkxst oh, am I to apply these new Ubuntu changes upstream?  Is that what this is all about?21:30
aeorilI guess in debian?21:31
aeoril(not upstream - they are already in gnome - but in debian?)21:31
aeorilwell, new gnome changes ...21:32
darkxstaeoril, ok, I didnt actaually check that was already there21:39
darkxstclearly that commit does not fix this bug21:39
aeorildarkxst yes, I was thinking that ... :)21:39
darkxstquilt is used to apply upstream (or custom) patches via packaging21:39
darkxstpatches go into debian/patches/ folder21:40
aeorildarkxst upstream -> quilt -> Ubuntu right?  In that direction?21:40
darkxstno quilt is a tool, used to add patches to an Ubuntu package21:40
aeorildarkxst yes, sorry for my unclear visual - that is what I meant ...21:41
aeoril(I have already read about quilt some)21:41
darkxstaeoril, yes21:41
aeorildarkxst 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:42
aeorildarkxst I am sure this bug is too much for me then, at this stage ...21:43
aeoril(if the fix is not known)21:43
aeorildarkxst unless I am hunt around for a different commit for the fix?21:44
aeorilbisecting and whatnot again ...21:44
darkxstaeoril, if its even fixed21:46
darkxstI actually don't see it here even on 3.14 (well I have a few but not exactly flooded)21:47
aeorildarkxst wouldn't it be more appropriate to give it to upstream to fix then, if it is not fixed?21:51
aeoril(I learned from my first bug try how difficult things can get)21:53
=== wgrant_ is now known as wgrant
darkxstaeoril, I wouldn't worry about it, only linked it since it looked like it was an easy fix21:57
aeorildarkxst ok - if you have any other good ones for me, just let me know.  Thanks!21:58
darkxstaeoril, see https://launchpad.net/ubuntu-gnome/+milestone/vivid21:58
aeorildarkxst ok, cool - will do ... :)21:58
darkxstaeoril, bug 131544222:14
ubottubug 1315442 in gdm (Ubuntu) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] https://launchpad.net/bugs/131544222:14
aeorildarkxst I was looking at the bugs in the link you gave, but you seem to have given me another nice one!  Thanks! :)22:16
aeorildarkxst 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 check22:52
aeorilfrom 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 in22:52
aeorilthe source directory when I branched from lp:gdm???22:52
ubottubug 1315442 in gdm (Ubuntu) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] https://launchpad.net/bugs/131544222:53
aeorildarkxst I re-verified problem/fix worked in trusty Ubuntu GNOME though22:53
aeoril(my vivid test was a daily build for vivid Ubuntu GNOME from around 2/27/2015 in a vm)22:54
aeorildarkxst 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 point22:55
darkxstif its fixed in vivid, then it atleast needs to be fixed via SRU to trusty22:56
darkxstthe file is in the debian folder of gdm package22:56
darkxstaeoril, except it isnt fixed in vivid yet23:01
darkxstso you would fix in vivid, then SRU to trusty23:01
aeorildarkxst I tried in vivid from the live cd - it did not seem to have the problem???23:01
darkxstthe syntax error is definitely there though23:02
aeorildarkxst the code isn't even the same in that area ...23:02
darkxstits just a different line number23:02
aeorilreally?  I counted the then/fi's - I can check again ...23:02
aeorildarkxst maybe I was in the wrong place ...23:03
aeorildarkxst 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:04
aeoril(it is not in the gdm source from what I could grep)23:05
darkxstpull-lp-source gdm23:05
darkxstits in the debian folder23:05
aeorildarkxst hmmm ... I did "bzr branch lp:gdm" - I'll do that instead23:05
darkxstaeoril, many of the udd branches are dead and/or broken23:06
aeorildarkxst so, I should generally use pull-lp-source?23:06
aeorilnot bzr branch?23:06
darkxstaeoril, well if the bzr branch is upto date that is fine to use23:07
darkxstif the package lists a Vcs-bzr in control then you should use that branch23:07
aeorildarkxst 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
aeorildarkxst or do you mean in debian/control?23:10
darkxstaeoril, yes in debian/control23:11
aeorildarkxst ok, sure thing - thanks for the tip.  Will do the fix then.23:12
aeorildarkxst 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.dsc23:15
aeoril(when I did pull-lp-source)23:15
aeorildarkxst uggghhh ... no source control!23:23
darkxstaeoril, no that doesnt really matter23:24
aeorildarkxst but it makes it more painful!23:24
darkxstaeoril, why? its a very simple fix, just make a debdiff23:25
aeorildarkxst how do I push to launchpad without bzr?23:25
darkxstattach a debdiff to the bug report23:25
aeorildarkxst 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:30
darkxstyou shouldnt need build-dep in this case, but everything else is correct23:31
aeorildarkxst oh, since I am working on trusty, I guess I need to do sbuild before debdiff?23:31
aeorilor not?23:32
darkxstno23:32
darkxstbut you should fix vivid first23:32
aeorildarkxst 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
aeorilhence, sbuild23:33
darkxstyes then sbuild it23:33
aeorildarkxst 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:34
darkxstaeoril, I build everying in sbuild, then mostly test in vm's23:36
darkxstor jhbuild when writing  GNOME patches23:36
aeorildarkxst 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 test23:37
aeorildarkxst just as an fyi, I have to stop for today, but should be able to get the fix in and tested for tomorrow.  Thanks.23:45

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!