=== doko_ is now known as doko | ||
doko | jtaylor, fyi, https://bugs.launchpad.net/ubuntu/+source/python-scipy/+bug/1426841 | 09:28 |
---|---|---|
ubottu | Launchpad bug 1426841 in python-scipy (Ubuntu) "python-scipy autopkg test fails in vivid" [Undecided,New] | 09:28 |
doko | any idea? | 09:28 |
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:23 |
ubottu | bug 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/1425349 | 13:23 |
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 | 13:45 |
mitya57 | aeoril: UDD branch for gnome-shell is outdated, see http://package-import.ubuntu.com/status/gnome-shell.html | 16:15 |
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:16 |
mitya57 | Oh, you were needing mutter, not gnome-shell... But no much difference: http://package-import.ubuntu.com/status/mutter.html | 16:18 |
darkxst | aeoril, use pull-lp-source and create a debdiff with the fix for mutter | 20:03 |
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. | 20:06 |
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:29 |
aeoril | darkxst oh, am I to apply these new Ubuntu changes upstream? Is that what this is all about? | 21:30 |
aeoril | I guess in debian? | 21:31 |
aeoril | (not upstream - they are already in gnome - but in debian?) | 21:31 |
aeoril | well, new gnome changes ... | 21:32 |
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:39 |
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:40 |
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:41 |
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:42 |
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:43 |
aeoril | darkxst unless I am hunt around for a different commit for the fix? | 21:44 |
aeoril | bisecting and whatnot again ... | 21:44 |
darkxst | aeoril, if its even fixed | 21:46 |
darkxst | I actually don't see it here even on 3.14 (well I have a few but not exactly flooded) | 21:47 |
aeoril | darkxst 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 | ||
darkxst | aeoril, I wouldn't worry about it, only linked it since it looked like it was an easy fix | 21:57 |
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 ... :) | 21:58 |
darkxst | aeoril, bug 1315442 | 22:14 |
ubottu | bug 1315442 in gdm (Ubuntu) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] https://launchpad.net/bugs/1315442 | 22:14 |
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:16 |
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:52 |
ubottu | bug 1315442 in gdm (Ubuntu) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] https://launchpad.net/bugs/1315442 | 22:53 |
aeoril | darkxst I re-verified problem/fix worked in trusty Ubuntu GNOME though | 22:53 |
aeoril | (my vivid test was a daily build for vivid Ubuntu GNOME from around 2/27/2015 in a vm) | 22:54 |
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:55 |
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 | 22:56 |
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:01 |
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:02 |
aeoril | darkxst maybe I was in the wrong place ... | 23:03 |
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:04 |
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:05 |
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:06 |
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:07 |
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:10 |
darkxst | aeoril, yes in debian/control | 23:11 |
aeoril | darkxst ok, sure thing - thanks for the tip. Will do the fix then. | 23:12 |
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:15 |
aeoril | darkxst uggghhh ... no source control! | 23:23 |
darkxst | aeoril, no that doesnt really matter | 23:24 |
aeoril | darkxst but it makes it more painful! | 23:24 |
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:25 |
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:30 |
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:31 |
aeoril | or not? | 23:32 |
darkxst | no | 23:32 |
darkxst | but you should fix vivid first | 23:32 |
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:33 |
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:34 |
darkxst | aeoril, I build everying in sbuild, then mostly test in vm's | 23:36 |
darkxst | or jhbuild when writing GNOME patches | 23:36 |
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:37 |
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. | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!