[00:00] <darkxst> aeoril, you could build vivid vim and try run that in 14.10
[00:00] <darkxst> or test with gnome-terminal from gnome3-staging ppa
[00:00] <darkxst> against standard 14.10 vim
[00:00] <aeoril> darkxst vivid vim works, so that is exactly what I was thinking - just shortcut to the vivid vim and if it solves the problem
[00:01] <aeoril> If not, try gnome-terminal as you suggested
[00:01] <aeoril> darkxst how do I find the build source for the vivid vim?
[00:01] <aeoril> is it in launchpad?
[00:01] <aeoril> (bazaar)
[00:01] <darkxst> pull-lp-source vim vivid
[00:02] <aeoril> pull-lp-source is an actual command at the command line?
[00:02] <darkxst> yes
[00:02] <aeoril> cool - that makes it easy!
[00:02] <darkxst> in ubuntu-dev-tools package
[00:02] <aeoril> gotcha - still gotta install those, but there is a developer wiki for that
[00:03] <aeoril> (to set up my build environment)
[00:03] <aeoril> darkxst doesn't someone need to independently verify the bug also?
[00:03] <aeoril> (confirm?)
[00:05] <aeoril> darkst how do I pull and build gnome-terminal from the ppa?
[00:06] <aeoril> pull-lp-source vivid gnome-terminal?
[00:07] <darkxst> aeoril, you would need to install the whole ppa probably, it needs gtk3.14 and an update libvte compared to 3.14
[00:08] <aeoril> ok, how do I install a ppa?  I can google that if it is involved
[00:08] <aeoril> (maybe I need to go through the beginner developer tutorial and steps at this point ...) darkxst
[00:09] <sarnold> apt-add-repository lp:.... ought to take care of much of it for you
[00:09] <darkxst> aeoril, there are instuctions at the top of any ppa's web page
[00:09] <aeoril> darkxst cool, I think I can take it from here
[00:11] <aeoril> sarnold cool, thanks!
[00:14] <aeoril> sarnold darkxst will installing the gnome-terminal ppa package update gtk3.14 and libvte systemwide?  e.g., do I need to do it on a test virtual machine that I can throw away after figuring out this bug because it will not be plain vanilla 14.4.1 anymore?
[00:15] <sarnold> aeoril: whatever packages in the ppa have higher version numbers than ones on your system will replace the system ones with the next apt-get update -- unless you go to some efforts to pin package versions.
[00:15] <sarnold> aeoril: VM would be best -- I know that might make it harder to reproduce the problem, though, your issue feels like a racy thing that might be harder (or easier?) to reproduce in  VM
[00:15] <darkxst> aeoril, it will update most of GNOME to 3.14, maybe safer to do it in a VM
[00:15] <aeoril> sarnold ok, I'll make a new vm so I can screw around without any worries
[00:16] <aeoril> sarnold it happens equally and very reproducably on a vm in VMWare, Hyper-V and on my 14.04 regular Ubuntu install
[00:16] <sarnold> yay :)
[00:17] <aeoril> sarnold it happens *rarely* on 14.10, but it did happen twice - much less reproducable on 14.04.  It has never happened on my 15.04 vm after many tries
[00:17] <aeoril> sarnold no kidding!
[00:17] <aeoril> much less reproducable on *than* on 15.04* (misworded)
[00:18] <aeoril> whoops, screwed up the fix - "*than* on 14.04*" :(
[00:18] <sarnold> aha :) I'm glad it's easily reproducable in vms, that makes it far easier to deal with :)
[00:18] <aeoril> yes, this particular problem does not seem to care about vms
[00:19] <aeoril> what do you guys do if vms fail to reproduce problems on bare metal machines?  Dual boots, quad boots, etc?
[00:19] <aeoril> (not sure how many different versions of Ubuntu you can have as alternate boots)
[00:20] <aeoril> I have read about chroot ...
[00:20] <darkxst> aeoril, for GNOME bugs there is jhbuild which is handy
[00:20] <aeoril> sarnold I am also glad it has *never* happened (so far) on 15.04 - I probably need to try it out a bunch more times though to make sure because 14.10 is pretty rare ...
[00:21] <aeoril> darkxst ok, I am writing down all this as I get it here so I can remember
[00:23] <aeoril> sarnold darkxst if I find that vivid vim works on 14.04/14.10, can we just use vivid vim for the backport?
[00:23] <aeoril> vivid's vim version*
[00:23] <darkxst> aeoril, no, only bug-fix only releases can be bugported to a stable release
[00:24] <aeoril> ahhh, ok - so I would have to see if the latest bug-fix only release of vim in launchpad fixes the problem, and use it if it does?
[00:25] <aeoril> darkxst ^
[00:25] <darkxst> aeoril, vim doesnt really seem to do proper releases
[00:26] <aeoril> darkxst I was just thinking that - the guy on #vim said their release/bug versioning was a mess ... or really not existant ...
[00:26] <darkxst> in which case you would want to backport the one patch that fixes the problem
[00:27] <aeoril> darkxst hmmm ... sounds difficult and laborious to find the individual patch I guess ...
[00:27] <darkxst> sometimes, often its pretty easy though
[00:27] <aeoril> darkxst oh, ok - that is good to know
[00:28] <darkxst> but first determine if its gnome-terminal or vim
[00:28] <aeoril> darkxst I was just exploring while I had you available
[00:31] <aeoril> darkxst what about confirmation from someone else?  What if the bug is somehow in my personal hardware/software setup?  Probably not, since two different machines do it, one normal install the other vms under Win 8.1, very different hardware darkxst
[00:32] <darkxst> you don't necessaraily need confirmation from someone else, especially if you can reproduce in clean installs on different  hardware
[00:32] <darkxst> atleast not at this stage
[00:33] <aeoril> darkxst yes, clean installs on all vms, and on the regular machine as well
[00:33] <aeoril> darkxst well, gotta knock off for a while - I'll try to get back to it tonight.  Thanks!
[00:34] <aeoril> sarnold thank you as well!
[01:58] <aeoril> darkxst you still there?  I am back and firing up a new vm with 14.04.1 to test vim and/or gnome.  I'll let you know how it goes.  Thanks.
[01:59] <aeoril> sarnold ^
[01:59] <sarnold> hey aeoril :)
[02:00] <aeoril> sarnold hey - I am back and starting to work on the steps outlined by you and darkxst for the vim/gnome-terminal bug
[02:00] <sarnold> aeoril: nice, happy hunting :)
[02:00] <aeoril> sarnold This is fun!
[02:00] <aeoril> yah, this is totally cool ... :)
[02:01] <aeoril> sarnold I am just glad I can use vms!  SOOOO much easier, I hope!
[02:01] <aeoril> vms are just tooooo easy - almost makes you feel guilty or something!
[02:02] <aeoril> I am sure they can also be problematic for many scenarios, though ...
[02:05] <aeoril> sarnold something actually cool - I built my machine to run lots of vms for various scenarios, this one included, so I have 32GB memory, so can have lots of vms running with lots of memory and just switch easily
[02:05] <sarnold> aeoril: ooh yeah, 32 gigs is a lot of breathing room :)
[02:06] <sarnold> especially since VMs typically can get away with less ram themselves -- their backing block devices are cached by the host, too
[02:07] <aeoril> sarnold yah, the guys on #hardware thought I was an idiot to do it, but it has already proved its worth.  I have 12GB used right now with 4 vms running simulataneously, 19GB still free!
[02:08] <aeoril> It is very convenient and easy to switch to various running configurations ...
[02:10] <aeoril> sarnold vmware says it uses 768MB for the video card by default, more if you choose
[02:11] <sarnold> aeoril: hah, fancy. I always use kvm and it has the lowest of low-end video cards; most of the time I just ssh in. heh. that might not work so well for your problem though...
[02:12] <aeoril> sarnold the hardware was pretty cheap though really, and the software is all free, so ...
[02:13] <sarnold> aeoril: pretty amazing, right? my first PC had 4 megabytes RAM..
[02:14] <aeoril> sarnold my first pc had 4K!
[02:14] <aeoril> lol
[02:15] <sarnold> aeoril: PC? :)
[02:15] <aeoril> Apple II ...
[02:15] <sarnold> hehe
[02:15] <aeoril> My XT had 640K - and a hard drive!
[02:16] <aeoril> oh, maybe 1GB, but 640 usable, other stuff was reserved, I think
[02:18] <sarnold> "640k ought to be enough for anyone" :)
[02:20] <aeoril> sarnold yes, there was a guy at my old place of work that had that in his signature
[02:59] <aeoril> sarnold darkxst how do I install this?  I tried sudo apt-get install ncurses but it did not work (not found):  https://launchpad.net/ubuntu/+source/ncurses
[02:59] <aeoril> sarnold darkxst ./configure for vim needs it ...
[03:00] <sarnold> aeoril: it probably needs libncurses5-dev -- but a neat thing is apt-get build-dep -- it'll install all the packages needed to build a specific package
[03:01] <sarnold> aeoril: (of course, better is to use a tool like sbuild to make repeatable builds that don't require installing new packages in your 'main' system -- but I assume you're doing the development on the VM, where it doesn't matter)
[03:01] <aeoril> sarnold yes, vm
[03:02] <aeoril> sarnold not sure how to use apt-get build-dep ...
[03:02] <sarnold> aeoril: try: apt-get build-dep vim
[03:03] <aeoril> sarnold I downloaded the vivid version of the vim source from lp - will apt-get build-dep vim still be ok for that?  I am on a 14.04.1 trying to build the vivid version of vim to test it on a 14.04.1 system ...
[03:03] <sarnold> aeoril: it'll get close most of the time
[03:04] <aeoril> sarnold I did this: pull-lp-source vim vivid
[03:05] <aeoril> sarnold this seems gunky - maybe I should use sbuild?
[03:06] <sarnold> aeoril: I wouldn't bother yet, faster iteration is probably more important at this point
[03:06] <aeoril> yes, sbuild seems involved ...
[03:12] <aeoril> sarnold making, thanks ...
[03:12] <sarnold> woo
[03:20] <aeoril> sarnold sssswwwwweeeeeettt!  That appeared to fix it!  Ran vim out of the temp directory from build, no problems, reran vim from normal spot, crapped out as usual!
[03:21] <Unit193> Heh, what can I say?  I use pbuilder. :P
[03:21] <sarnold> aeoril: oh good, now you get to figure out what changed :)
[03:21] <aeoril> sarnold lol there lies the rub!
[03:22] <aeoril> sarnold should I do something to the bug report at this point?
[03:22] <sarnold> aeoril: probably not, not much to be done yet
[03:23] <aeoril> this is still pretty cool ...
[03:24] <aeoril> sarnold so now I have to put on my developer hat? lol
[03:24] <sarnold> aeoril: you may have success bisecting their revision control, if they've got public trees..
[03:25] <aeoril> sarnold they've got public trees, but the revision control apparently sucks ... they use mercurial and the guy on #vim said that the revision control is a mess
[03:25] <aeoril> sarnold I think it is safe to say we have at least narrowed it down to a vim problem ...
[03:26] <darkxst> aeoril, bisecting would still find the commit
[03:26] <darkxst> regardless of how messy it is
[03:27] <sarnold> I'm seeing lots of checkins per day; it might not be ideal, but it's liable to give small enough checkins that'd it be useful
[03:27] <sarnold> I was afraid it was going to be tarball imports or something else fairly .. ghetto
[03:32] <aeoril> darkxst sarnold can I do anything with the lp source code instead?
[03:33] <aeoril> bisect on Ubuntu lp source/patches or whatever?
[03:34] <sarnold> aeoril: no :(
[03:37] <aeoril> sarnold how did you see their source code history?  Do you have mercurial and fetched their source code and looked at the commits in your local repo you fetched?
[03:37] <sarnold> aeoril: https://code.google.com/p/vim/source/list
[03:37]  * sarnold <-- lazy
[03:41] <aeoril> sarnold looks like they have issues tracked though
[03:41] <sarnold> aeoril: yeah, if you can find an issue, so much the better :)
[03:41] <aeoril> sarnold lots of issues ...
[03:42] <sarnold> I'm not surprised, they support a lot of crazy platforms
[03:45] <aeoril> sarnold like Windows?
[03:46] <darkxst> aeoril, I think a bisect would be your best bet here
[03:46] <aeoril> darkxst yes, I think so
[03:46] <darkxst> probably quicker than trawling through undescriptive commit messages!
[03:47] <aeoril> darkxst quick search on issues found nothing, lots of commits
[03:50] <aeoril> sarnold darkxst so, I guess once I download the latest source repo, I just checkout commits bisecting from my local repo, bisecting dates, until I hit the right commit?
[03:51] <aeoril> s/right commit/commit that fixes the problem/
[03:51] <darkxst> vcs should provide a bisect command (never tried in mercurial though)
[03:51] <aeoril> darkxst ok, that would be better then (much)
[03:51] <darkxst> don't try and do it manually!
[03:52] <darkxst> atleast with git bisect, you provide the last know bad commit and then a known good commit
[03:52] <darkxst> git chooses the commits to checkout and you tell it if each one was good or broken
[03:53] <darkxst> it would be a similar concept for mercurial
[03:53] <aeoril> http://www.selenic.com/hg/help/bisect :)
[03:53] <sarnold> hg does have a bisect sub-command, but I have no idea how you tell it success / failure; if it works, it'll be awesome...
[03:53] <aeoril> sarnold ^
[03:54] <darkxst> or there is a git mirror of vim on github -> https://github.com/vim-jp/vim/commit/f69eb7659a7bf4a586c569ae63fc2cc6ad364710
[03:54] <sarnold> :)
[03:54] <aeoril> darkxst oh, that is good to know - which do you suggest I use?
[03:55] <darkxst> probably git, given I know it works!
[03:55] <aeoril> lol ok, I would rather use git!
[03:56] <aeoril> darkxst sarnold wow, this is really cool - I am learning a lot rapidly ...
[03:56] <aeoril> Your help is immensely cool and appreciated ...
[03:57] <aeoril> darkxst sarnold I think I have lucked out with my first bug being relatively easy, at least so far (I know, famous last words ...)
[03:57] <sarnold> hah, normally terminal bugs don't get called "easy" :)
[03:58] <aeoril> sarnold terminal bugs?
[03:58] <aeoril> you mean terminal as in gnome-terminal?
[03:58] <sarnold> aeoril: anything involving ncurses, terminfo, terminals...
[03:58] <darkxst> aeoril, and you haven't found the solution just yet
[03:58] <aeoril> sarnold well, i said "so far" ...
[03:59] <sarnold> you might fix gnome-terminal but break xterm, rxvt, urxvt, aterm, wterm, Eterm, konsole, or the virtual terminals...
[03:59] <aeoril> I am an optimist!
[03:59] <sarnold> :)
[04:00] <aeoril> ahhh, I see ... right, didn't even think about that ...
[04:00] <aeoril> I am just a babe in the woods!
[04:00] <aeoril> Ready for the wolves to start circling!
[04:00] <aeoril> lol
[04:01] <sarnold> it's a good start though, the best way to get involved is to fix a bug that annoys you :) once you've gotten started, future problems will seem that much easier..
[04:02] <aeoril> sarnold yes, I am learning a lot - the funny thing is, with this particular bug, I just realized using screen I don't need to mess with the problem behavior, but it is good to learn on I guess
[04:03] <aeoril> screen or tmux
[04:04] <sarnold> aeoril: hah :) but similarly, gnome-terminal --geom .... -c "screen -e vim ..." is a bit much just to get a working vim in terminal.
[04:05] <aeoril> sarnold well, I have them as scripts, so "pup vi .bashrc" means "pop up a new gnome terminal sized per the script and run vi in it on .bashrc"
[04:06] <aeoril> So, pup <something> becomes useful for a variety of things
[04:09] <aeoril> sarnold can you think of a better way?
[04:10] <aeoril> sarnold well, I think tmux or screen are the best ways
[04:10] <sarnold> aeoril: tmux / screen would do it fine, but you're already on this path, might as well keep going :)
[04:10] <aeoril> sarnold yes, I am going to try to complete this bug fix
[04:11] <sarnold> sweet
[04:11] <darkxst> aeoril, get bisecting then ;)
[04:11] <aeoril> darkxst not tonight - already late - tomorrow ... :)
[04:12] <sarnold> indeed, goodnight aeoril, darkxst :)
[04:13] <aeoril> sarnold night~
[04:13] <darkxst> aeoril, night
[04:13] <aeoril> night, darkxst ~
[06:42] <pitti> Good morning
[06:42] <pitti> bdmurray: yes, I'll do one today, I got darkxst' wayland hook
[06:54] <darkxst> hey pitti
[06:54] <darkxst> also bug 1418766
[06:56] <pitti> darkxst: do our GTK packages have native wayland support, or do we need to explicitly check for xwayland?
[06:56] <pitti> darkxst: because, under xwayland you ought to have $DISPLAY?
[06:56] <pitti> [ ! -z "$DISPLAY" -o -z "$WAYLAND_DISPLAY"]
[06:56] <pitti> ITYM -a there (will fix when merging)
[06:57] <pitti> oh, and why the ! ?
[07:00] <darkxst> pitti, initially when you launch you only have $WAYLAND_DISPLAY, I think you won't get into XWAYLAND until gtk is initialized
[07:01] <pitti> darkxst: I mean, will GTK work without xwayland too?
[07:01] <pitti> darkxst: i. e. does GTK have native wayland support in our packages?
[07:01] <pitti> darkxst: if not, we need to check [ -n $WAYLAND_DISPLAY ] && (xwayland installed)
[07:02] <darkxst> pitti, GTK does have native wayland support, however apport isnt completely safe yet due to the couple of GdkX11 calls
[07:04] <darkxst> only core stuff is running native wayland by default
[07:04] <darkxst> and Xwayland gets installed with the session, so it wouldnt be possible to have WAYLAND_DISPLAY set and xwayland not installed
[07:07] <darkxst> and right that expression isn't quite right
[07:10] <pitti> darkxst: ah, ok; so existance of $WAYLAND_DISPLAY implies xwayland is present?
[07:11] <darkxst> I guess [ -z "$DISPLAY" -a -z "$WAYLAND_DISPLAY"] is right
[07:11] <darkxst> pitti, atleast on GNOME
[07:12] <darkxst> maybe not for weston
[07:16] <darkxst> I guess it wouldnt hurt to check if installed
[07:19] <pitti> darkxst: http://paste.ubuntu.com/10087059/ ?
[07:20] <darkxst> pitti, yep looks good to me
[07:26] <darkxst> pitti, and its really only set_modal_for() that would break under native wayland, although I don't think there an equivalent of that implemented in wayland yet
[07:26] <pitti> darkxst: ah, perhaps we could more gracefully intercept that failure, and just not make it modal then?
[07:28] <dholbach> good morning
[07:29] <pitti> hey dholbach!
[07:30] <dholbach> hi pitti
[07:32] <darkxst> pitti, right, should be simple enough but for 3.14 normal GTK apps all default to Xwayland unless the user forces things with GDK_BACKEND
[07:32] <darkxst> no probably not too urgent
[07:33] <darkxst> s/no/so/
[07:39] <darkxst> pitti, and I actually don't know how to check for that in python/introspection, atleast in C its GDK_IS_X11_DISPLAY()
[07:43] <pitti> darkxst: do you have a way to quickly test apport-gtk under native wayland?
[07:43] <darkxst> pitti, yes
[07:45] <pitti> darkxst: ok, so ATM this crashes on the Gdk bits; do you have a backtrace?
[07:45] <pitti> darkxst: I need to know what/where to intercept, to skip the set_modal_for bits
[07:46] <pitti> darkxst: I suppose Wnck also wouldn't work under wayland
[07:48] <darkxst> pitti, actually it doesnt crash but it probably should
[07:48] <pitti> darkxst: ah, so what happens?
[07:48] <darkxst> am getting an "Error: no display specified" though
[07:49] <pitti> darkxst: something like http://paste.ubuntu.com/10087376/ should be enough, if the actual imports work
[07:54] <darkxst> pitti, yes seems so
[07:54] <pitti> darkxst: great, thanks for testing; committing that then
[07:57] <darkxst> gah, still
[07:57] <darkxst> getting no dispay specified errors after clicking send though
[07:57] <darkxst> even in Xwayland
[08:03] <darkxst> seems like the browser call fails since there is no DISPLAY set
[08:03] <pitti> darkxst: ah, that's from xdg-open?
[08:05] <darkxst> pitti, yes
[08:09] <darkxst> pitti, xdg-open really needs a $DISPLAY
[08:09] <pitti> darkxst: ah, so that one also needs to be fixed for wayland then
[08:11] <darkxst> pitti, yeh looks like it
[08:17] <darkxst> pitti, by why doesnt the try catch the failure and fall back to webbrowser?
[08:17] <darkxst> I suppose it considers the subprocess.call successful?
[08:17] <darkxst> but it shoudn't right?
[08:17] <darkxst> or xdg-open isnt returning proper exit codes?
[08:18] <pitti> darkxst: I suppose xdg-open erroneously returns 0?
[08:20] <darkxst> pitti, yep it does
[08:23] <darkxst> pitti, or its really coming from firefox ;(
[08:26] <pitti> darkxst: does ffox actually work under wayland?
[08:27] <pitti> it's still GTK 2
[08:28] <darkxst> pitti, seems it works under Xwayland, but only when $DISPLAY is set
[08:37] <alkisg> slangasek: good morning, could I ping you about putting an update-manager SRU in precise-proposed, if you happen to have some time today?  https://launchpad.net/ubuntu/precise/+queue?queue_state=1 and https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
[08:59] <slangasek> alkisg: several of the bugs fixed in this upload are still waiting for the information required by the SRU process
[09:00] <alkisg> slangasek:  ah sorry I didn't realize that, I thought mvo had only uploaded one particular bug I'd reported...
[09:00]  * alkisg as at a loss on how to help with that sru now
[09:00] <alkisg> Split my own bug in a different SRU? Help in the other bug reports that are in the same upload?
[09:10] <slangasek> alkisg: filling out the other SRU bugs with the required information would be a good idea
[09:11] <alkisg> slangasek: thanks, I hope I'll be able to find test cases for them... E.g. "install ubuntu 12.04.4" doesn't sound so quick...
[09:11]  * alkisg tries
[09:11] <pitti> bdmurray: uploaded now
[09:12] <slangasek> alkisg: test cases aren't required to be quick, but correct
[09:12] <alkisg> slangasek: I'll obviously need to do the verification-done step afterwards too though, for 3 bugs that didn't get enough attention from their reporters...
[09:12] <alkisg> It's a bit unfair for me, considering I reported another bug :)
[09:13] <alkisg> I'd prefer it if it was possible to upload an SRU with just my bug fix, but OK I understand the deal
[09:13] <alkisg> I'll try to give all the appropriate feedback for the other bug reports
[09:16] <slangasek> alkisg: then you can talk to the uploader (mvo?)
[09:16] <slangasek> alkisg: talk to him about a reupload without the other changes
[09:17] <alkisg> slangasek: yes, I understand, but of course it'll be more burden for mvo then. I'll see first if I can easily do the SRU steps for the other bug reports.
[09:20] <alkisg> Hmm I think I'll try pinging the reporters as a first step :)
[09:21] <mpt> Help, I’m trying to push an Ubuntu packaging bug fix but Launchpad won’t let me
[09:21] <mpt>  😌 09:19:58@libnotify> bzr push lp:~mpt/libnotify/533631-timeout-doc
[09:21] <mpt> bzr: ERROR: Permission denied: "~mpt/libnotify/533631-timeout-doc/": : Project 'libnotify' does not exist.
[09:21] <mpt>  😠 09:20:21@libnotify> bzr push lp:~mpt/ubuntu/libnotify/533631-timeout-doc
[09:21] <mpt> bzr: ERROR: Invalid url supplied to transport: "lp:~mpt/ubuntu/libnotify/533631-timeout-doc": No such distribution series libnotify.
[09:22] <mpt> I got the branch from lp:ubuntu/libnotify, so why can’t I push to lp:~mpt/ubuntu/libnotify?
[09:29] <mpt> Do I need to specify vivid/?
[09:30] <mvo> slangasek, alkisg: I look at this, in a call right now
[09:30] <Odd_Bloke> mpt: I think I have done so in the past.
[09:31] <seb128> slangasek, hey, what's the status of systemd by default? ;-)
[09:31] <ogra_> mpt, perhaps it gets confused by all the smileys :)
[09:32] <alkisg> 😁
[09:38] <cjwatson> mpt: The namespace for personal source package branches is lp:~OWNER/DISTRIBUTION/DISTROSERIES/SOURCE/BRANCHNAME
[09:38] <cjwatson> mpt: so yes, you must include vivid/
[10:01] <mpt> Ok, that works. Thanks Odd_Bloke, cjwatson
[10:02] <darkxst> pitti, changelog had me a little worried for a sec "Also check for $WAYLAND_SESSION"
[10:03] <darkxst> but the code is ok!
[10:03] <mpt> ogra_, I set that up as an easy way to tell whether the last command succeeded or failed :-) (Only bzr diff messes it up)
[10:13] <cjwatson> Plain "diff" does the same
[10:13] <cjwatson> Interestingly, "git diff" doesn't
[10:14] <cjwatson> Ah, you have to say --exit-code if you want diff-style exit codes
[10:14] <cjwatson> Shocking, I think that's actually a good UI design decision by git
[10:29] <mpt> Human sacrifice … cats and dogs living together … mass hysteria … and good UI decisions in Git
[10:54] <pitti> darkxst: ah, should I have described that differently?
[10:55] <darkxst> pitti, wayland session or  $WAYLAND_SESSIO
[10:55] <darkxst> $WAYLAND_DESKTOP
[10:55] <darkxst> cut and paste fail there
[10:55] <ogra_> $WAYLAND_WAY
[10:55] <darkxst> DISPLAY
[10:55] <ogra_> :)
[10:56] <pitti> darkxst: ah, you mean _DISPLAY instead of _SESSION; fixed in NEWS in bzr
[10:57] <darkxst> pitti, yes exactly
[10:57] <pitti> (and fixed on https://launchpad.net/apport/trunk/2.16)
[10:58] <darkxst> ta
[13:07] <pitti> jdstrand: I'd like to point out bug 1418928
[14:12] <jdstrand> pitti: thanks!
[14:13] <jdstrand> tyhicks: fyi ^
[14:13] <pitti> jdstrand: ah, should I ping tyhicks in the future about security updates?
[14:15] <jdstrand> pitti: either is fine, but typically, yes
[16:13] <zul> mterry:  ping can you have a look at the  libxml-xpath-perl MIR please
[16:13] <smoser> :)
[16:13] <zul> mterry:  its blocking libvirt
[16:43] <Bluefoxicy> sigh
[16:43] <Bluefoxicy> why does every Linux distro install a 200MB /boot?
[16:43] <Bluefoxicy> before you know it, you've got three kernel images installed somehow, and /boot is full
[17:22] <cyphermox> flexiondotorg_: how far how we for reviewing your packages? are you still looking for a second reviewer?
[22:29] <aeoril> darkxst I am looking at github.  I found two mirrors of google mercurial vim.  One is outdated, the other is vim-jp.  How do I know I can trust these mirrors?
[22:32] <aeoril> darkxst is there a way to do a checksum or something on a commit?
[22:33] <darkxst> aeoril, it would just be an autosync repo, should be fine
[22:34] <aeoril> darkxst I wonder why one of the mirror repos is not up to date though?  That is what got me thinking ...
[22:34] <darkxst> not sure you can checksum, both git and mercurial hash commits differently
[22:35] <aeoril> darkxst https://github.com/b4winckler/vim
[22:35] <aeoril> darkxst yes, I see - good point ...
[22:35] <darkxst> idk, autosync can break from time to time I guess
[22:36] <aeoril> darkxst oh well, I will start bisecting on the japanese github mirror repo ...
[22:42] <darkxst> aeoril, ok
[22:59] <aeoril> darkxst what is the best way to figure out the starting/ending commits in the github vim repo based on the lp versions that are in the ubuntu builds?
[22:59] <aeoril> for the bisection
[23:01] <sarnold> easiest is probably to just select one at random from two years ago and the most recent
[23:01] <sarnold> you'll cut off half of them with the third test right in the middle, so there isn't too much reason to optimize finding the first and last ones to work with :)
[23:04] <aeoril> sarnold I feel like I am asking too many dumb questions ... I don't see anyone else doing so ...
[23:04] <sarnold> aeoril: ask away :)
[23:07] <darkxst> aeoril, though don't go back to far, if this used to work pre trusty
[23:07] <darkxst> I would start with first 7.4 commit
[23:10] <aeoril> darkxst sarnold Viewing the trusty revision history, the last revision for release is 57 dated 2010-03-08: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/vim/trusty/changes/57
[23:11] <aeoril> darkxst sarnold wouldn't I just choose that date as a good approximation?  But that is almost 5 years ago ...
[23:12] <sarnold> aeoril: I have no idea what that ubuntu-branches thing is..
[23:12] <aeoril> then, choose the latest and go from there?
[23:12] <aeoril> sarnold really?
[23:12] <sarnold> aeoril: yeah :) I don't think I've seen it before. and 2010 was a looooong time ago. I assume it's a process that predates my involvement.
[23:13] <darkxst> sarnold that is the packaging revisions
[23:13] <darkxst> nothing to do with vim commits
[23:13] <sarnold> aeoril: from this thing you can see that trusty shipped with a 7.4.052-based package: https://launchpad.net/ubuntu/+source/vim
[23:13] <aeoril> sarnold darkxst I got to it from here:  https://code.launchpad.net/ubuntu/+source/vim
[23:13] <aeoril> sarnold lol ok - same link!
[23:14] <darkxst> aeoril, really just start at 'v7-4'
[23:15] <aeoril> darkxst I am just looking around, trying to learn ... sorry if I am asking too many questions ...
[23:16] <aeoril> darkxst where do you see the info that it was v7-4?  I am clicking around and do not see that
[23:17] <darkxst> its a tag
[23:18] <darkxst> aeoril, you should just be able to run git bisect v7-4
[23:18] <darkxst> ^insert bad though
[23:21] <aeoril> darkxst sarnold oh, I was under the code section on launchpad - I see the tag now
[23:21] <aeoril> (launchpad for vim)
[23:21] <darkxst> aeoril, go to your git tree! launchpad is just confusing you!
[23:22] <FOSS_drivers_FTW> Hello
[23:22] <FOSS_drivers_FTW> is there any reason why xserver-xorg-video-ati is still at 7.4.0 in vivid?
[23:22] <FOSS_drivers_FTW> see:
[23:22] <FOSS_drivers_FTW> http://packages.ubuntu.com/vivid/xserver-xorg-video-ati
[23:22] <FOSS_drivers_FTW> Debian already has 7.5.0, see:
[23:23] <FOSS_drivers_FTW> https://packages.debian.org/search?keywords=xserver-xorg-video-ati&searchon=names&suite=all&section=all
[23:23] <FOSS_drivers_FTW> 7.5.0 is the latest version, see:
[23:23] <FOSS_drivers_FTW> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/
[23:23] <FOSS_drivers_FTW> so, is there any reason why vivid is still using an old version? why hasn't the latest version been imported from Debian?
[23:29] <aeoril> sarnold darkxst please bear with me - I am trying to understand.  I see on the launchpad site (https://launchpad.net/ubuntu/+source/vim) a line next below "The Trusty Tahr" that says "2:7.4.052-1ubuntu3" ... "release (main)" ... "2014-01-02" - what exactly do those three things mean there? (the version, release(main) and date)?
[23:29] <darkxst> aeoril, 7.4.052 was the upstream version
[23:29] <darkxst> -1ubuntu3 is the ubuntu version
[23:30] <darkxst> the rest doesnt matter
[23:30] <aeoril> what is the 2:?
[23:30] <darkxst> an epoch
[23:30] <darkxst> part of ubuntu version also
[23:30] <darkxst>  7.4.052 is the bit you wanted to know I suspect
[23:34] <darkxst> aeoril, go to your git tree
[23:35] <darkxst> git bisect start
[23:35] <darkxst> git bisect bad v7-4
[23:35] <darkxst> git bisect good
[23:35] <darkxst> then start building!
[23:36] <aeoril> darkxst ok, thanks - but still learning here - give a man a fish, feed him for a day, teach a man to fish, feed him his whole life ... :)
[23:37] <darkxst> aeoril, and 'man git bisect' will give you even better instructions
[23:37] <aeoril> ok, cool - thanks
[23:38] <sarnold> heh, every time I need git manpages I always think of http://git-man-page-generator.lokaltog.net/
[23:38] <darkxst> aeoril, most of the git man pages have nice simple examples
[23:39] <aeoril> darkxst so, to find out I needed to start "bad" at 7-4, you looked at the launchpad page at that 7-4-52 and figured "spitball at 7-4?"
[23:40] <aeoril> darkxst or, did you just go by the date of the trusty release as a rough estimate?
[23:40] <darkxst> first
[23:40] <aeoril> I noticed precise was 7.3 and switched to 7.4 in trusty looking at the launchpad page'
[23:40] <aeoril> darkxst ok, that is the piece of information I was searching for - thanks (I know you already answered it previously, but just checking)
[23:42] <aeoril> darkxst sarnold ok, I'll clone the github repo now and start bisecting - thanks for your patience
[23:42] <brainwash> FOSS_drivers_FTW: it's not automatically synced from debian, because the current ubuntu package has some ubuntu delta
[23:43] <FOSS_drivers_FTW> brainwash: thanks for the reply. so what can be done to make sure it will be synced before Debian Import Freeze?
[23:44] <brainwash> FOSS_drivers_FTW: you could file a report and request that the new version is synced
[23:45] <aeoril> darkxst sarnold do the debian/ubuntu versions always try to include the versioning scheme of the underlying package in their version names?  What if vim had some completely insane version names?
[23:46] <aeoril> here, it really helped us
[23:46] <darkxst> aeoril, versions are always [upstream]-[debian][ubuntuX]
[23:46] <sarnold> is "requestsync" the right tool for that job?
[23:47] <brainwash> FOSS_drivers_FTW: maybe also ask in #ubuntu-x
[23:47] <darkxst> if the ubuntu delta can be dropped it is
[23:47] <sarnold> aeoril: I haven't yet seen a case where the upstream version isn't included; sometimes when projects change their version scheme, the epoch is needed..
[23:48] <aeoril> darkxst upstream means vim here? (7-4-052, for instance)
[23:48] <darkxst> aeoril, yes
[23:48] <darkxst> "-1" is the debian version
[23:48] <darkxst> "ubuntu3" the ubuntu version
[23:49] <aeoril> just about to ask that darkxst
[23:49] <darkxst> sometimes the debian version is "-0" which means the package is not based of a debian revision
[23:49] <aeoril> so we had an epoch change here because of the 2: ?
[23:50] <darkxst> aeoril, the epochs, seem to have come from many years ago
[23:50] <darkxst> but yes at some point (twice) vim must have changed versioning schemes
[23:52] <darkxst> although there are occassions when the epoch's come from packaging changes (not upstream)
[23:55] <aeoril> darkxst ok, cool