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