| darkxst | aeoril, you could build vivid vim and try run that in 14.10 | 00:00 |
|---|---|---|
| === salem_ is now known as _salem | ||
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| aeoril | darkst how do I pull and build gnome-terminal from the ppa? | 00:05 |
| aeoril | pull-lp-source vivid gnome-terminal? | 00:06 |
| darkxst | aeoril, you would need to install the whole ppa probably, it needs gtk3.14 and an update libvte compared to 3.14 | 00:07 |
| 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:08 |
| 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:09 |
| aeoril | sarnold cool, thanks! | 00:11 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| aeoril | darkxst ok, I am writing down all this as I get it here so I can remember | 00:21 |
| 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:23 |
| 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:24 |
| aeoril | darkxst ^ | 00:25 |
| darkxst | aeoril, vim doesnt really seem to do proper releases | 00:25 |
| 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:26 |
| 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:27 |
| darkxst | but first determine if its gnome-terminal or vim | 00:28 |
| aeoril | darkxst I was just exploring while I had you available | 00:28 |
| 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:31 |
| 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:32 |
| 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:33 |
| aeoril | sarnold thank you as well! | 00:34 |
| 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:58 |
| aeoril | sarnold ^ | 01:59 |
| sarnold | hey aeoril :) | 01:59 |
| 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:00 |
| 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:01 |
| aeoril | I am sure they can also be problematic for many scenarios, though ... | 02:02 |
| 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:05 |
| sarnold | especially since VMs typically can get away with less ram themselves -- their backing block devices are cached by the host, too | 02:06 |
| 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:07 |
| aeoril | It is very convenient and easy to switch to various running configurations ... | 02:08 |
| aeoril | sarnold vmware says it uses 768MB for the video card by default, more if you choose | 02:10 |
| 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:11 |
| aeoril | sarnold the hardware was pretty cheap though really, and the software is all free, so ... | 02:12 |
| sarnold | aeoril: pretty amazing, right? my first PC had 4 megabytes RAM.. | 02:13 |
| aeoril | sarnold my first pc had 4K! | 02:14 |
| aeoril | lol | 02:14 |
| sarnold | aeoril: PC? :) | 02:15 |
| aeoril | Apple II ... | 02:15 |
| sarnold | hehe | 02:15 |
| aeoril | My XT had 640K - and a hard drive! | 02:15 |
| aeoril | oh, maybe 1GB, but 640 usable, other stuff was reserved, I think | 02:16 |
| sarnold | "640k ought to be enough for anyone" :) | 02:18 |
| aeoril | sarnold yes, there was a guy at my old place of work that had that in his signature | 02:20 |
| 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 ... | 02:59 |
| 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:00 |
| 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:01 |
| aeoril | sarnold not sure how to use apt-get build-dep ... | 03:02 |
| sarnold | aeoril: try: apt-get build-dep vim | 03:02 |
| 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:03 |
| aeoril | sarnold I did this: pull-lp-source vim vivid | 03:04 |
| aeoril | sarnold this seems gunky - maybe I should use sbuild? | 03:05 |
| sarnold | aeoril: I wouldn't bother yet, faster iteration is probably more important at this point | 03:06 |
| aeoril | yes, sbuild seems involved ... | 03:06 |
| aeoril | sarnold making, thanks ... | 03:12 |
| sarnold | woo | 03:12 |
| 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:20 |
| 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:21 |
| 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:22 |
| aeoril | this is still pretty cool ... | 03:23 |
| 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:24 |
| 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:25 |
| darkxst | aeoril, bisecting would still find the commit | 03:26 |
| darkxst | regardless of how messy it is | 03:26 |
| 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:27 |
| aeoril | darkxst sarnold can I do anything with the lp source code instead? | 03:32 |
| aeoril | bisect on Ubuntu lp source/patches or whatever? | 03:33 |
| sarnold | aeoril: no :( | 03:34 |
| 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:37 | |
| 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:41 |
| sarnold | I'm not surprised, they support a lot of crazy platforms | 03:42 |
| aeoril | sarnold like Windows? | 03:45 |
| 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:46 |
| aeoril | darkxst quick search on issues found nothing, lots of commits | 03:47 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| darkxst | probably git, given I know it works! | 03:55 |
| aeoril | lol ok, I would rather use git! | 03:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | :) | 03:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| aeoril | screen or tmux | 04:03 |
| 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:04 |
| 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:05 |
| aeoril | So, pup <something> becomes useful for a variety of things | 04:06 |
| aeoril | sarnold can you think of a better way? | 04:09 |
| 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:10 |
| sarnold | sweet | 04:11 |
| darkxst | aeoril, get bisecting then ;) | 04:11 |
| aeoril | darkxst not tonight - already late - tomorrow ... :) | 04:11 |
| sarnold | indeed, goodnight aeoril, darkxst :) | 04:12 |
| aeoril | sarnold night~ | 04:13 |
| darkxst | aeoril, night | 04:13 |
| aeoril | night, darkxst ~ | 04:13 |
| === work_alkisg is now known as alkisg | ||
| pitti | Good morning | 06:42 |
| pitti | bdmurray: yes, I'll do one today, I got darkxst' wayland hook | 06:42 |
| === alkisg is now known as work_alkisg | ||
| darkxst | hey pitti | 06:54 |
| darkxst | also bug 1418766 | 06:54 |
| ubottu | bug 1418766 in apport (Ubuntu) "ubuntu-bug launches in CLI mode under wayland session" [Undecided,New] https://launchpad.net/bugs/1418766 | 06:54 |
| 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:56 |
| pitti | oh, and why the ! ? | 06:57 |
| darkxst | pitti, initially when you launch you only have $WAYLAND_DISPLAY, I think you won't get into XWAYLAND until gtk is initialized | 07:00 |
| 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:01 |
| darkxst | pitti, GTK does have native wayland support, however apport isnt completely safe yet due to the couple of GdkX11 calls | 07:02 |
| 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:04 |
| darkxst | and right that expression isn't quite right | 07:07 |
| pitti | darkxst: ah, ok; so existance of $WAYLAND_DISPLAY implies xwayland is present? | 07:10 |
| darkxst | I guess [ -z "$DISPLAY" -a -z "$WAYLAND_DISPLAY"] is right | 07:11 |
| darkxst | pitti, atleast on GNOME | 07:11 |
| darkxst | maybe not for weston | 07:12 |
| darkxst | I guess it wouldnt hurt to check if installed | 07:16 |
| pitti | darkxst: http://paste.ubuntu.com/10087059/ ? | 07:19 |
| darkxst | pitti, yep looks good to me | 07:20 |
| === kickinz1|afk is now known as kickinz1 | ||
| 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:26 |
| dholbach | good morning | 07:28 |
| pitti | hey dholbach! | 07:29 |
| dholbach | hi pitti | 07:30 |
| 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:32 |
| darkxst | s/no/so/ | 07:33 |
| 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:39 |
| pitti | darkxst: do you have a way to quickly test apport-gtk under native wayland? | 07:43 |
| darkxst | pitti, yes | 07:43 |
| 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:45 |
| pitti | darkxst: I suppose Wnck also wouldn't work under wayland | 07:46 |
| 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:48 |
| pitti | darkxst: something like http://paste.ubuntu.com/10087376/ should be enough, if the actual imports work | 07:49 |
| darkxst | pitti, yes seems so | 07:54 |
| pitti | darkxst: great, thanks for testing; committing that then | 07:54 |
| darkxst | gah, still | 07:57 |
| darkxst | getting no dispay specified errors after clicking send though | 07:57 |
| darkxst | even in Xwayland | 07:57 |
| === work_alkisg is now known as alkisg | ||
| darkxst | seems like the browser call fails since there is no DISPLAY set | 08:03 |
| pitti | darkxst: ah, that's from xdg-open? | 08:03 |
| darkxst | pitti, yes | 08:05 |
| 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:09 |
| darkxst | pitti, yeh looks like it | 08:11 |
| 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:17 |
| pitti | darkxst: I suppose xdg-open erroneously returns 0? | 08:18 |
| darkxst | pitti, yep it does | 08:20 |
| darkxst | pitti, or its really coming from firefox ;( | 08:23 |
| pitti | darkxst: does ffox actually work under wayland? | 08:26 |
| pitti | it's still GTK 2 | 08:27 |
| darkxst | pitti, seems it works under Xwayland, but only when $DISPLAY is set | 08:28 |
| === stub` is now known as stub | ||
| 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:37 |
| slangasek | alkisg: several of the bugs fixed in this upload are still waiting for the information required by the SRU process | 08:59 |
| 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:00 |
| slangasek | alkisg: filling out the other SRU bugs with the required information would be a good idea | 09:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:16 |
| 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:17 |
| alkisg | Hmm I think I'll try pinging the reporters as a first step :) | 09:20 |
| 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:21 |
| mpt | I got the branch from lp:ubuntu/libnotify, so why can’t I push to lp:~mpt/ubuntu/libnotify? | 09:22 |
| mpt | Do I need to specify vivid/? | 09:29 |
| 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:30 |
| seb128 | slangasek, hey, what's the status of systemd by default? ;-) | 09:31 |
| ogra_ | mpt, perhaps it gets confused by all the smileys :) | 09:31 |
| alkisg | 😁 | 09:32 |
| 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/ | 09:38 |
| === vrruiz_ is now known as rvr | ||
| === pete-woods is now known as pete-woods|afk | ||
| mpt | Ok, that works. Thanks Odd_Bloke, cjwatson | 10:01 |
| darkxst | pitti, changelog had me a little worried for a sec "Also check for $WAYLAND_SESSION" | 10:02 |
| 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:03 |
| cjwatson | Plain "diff" does the same | 10:13 |
| cjwatson | Interestingly, "git diff" doesn't | 10:13 |
| 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:14 |
| === alkisg is now known as work_alkisg | ||
| mpt | Human sacrifice … cats and dogs living together … mass hysteria … and good UI decisions in Git | 10:29 |
| === kickinz1 is now known as kickinz1|away | ||
| pitti | darkxst: ah, should I have described that differently? | 10:54 |
| 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:55 |
| pitti | darkxst: ah, you mean _DISPLAY instead of _SESSION; fixed in NEWS in bzr | 10:56 |
| darkxst | pitti, yes exactly | 10:57 |
| pitti | (and fixed on https://launchpad.net/apport/trunk/2.16) | 10:57 |
| darkxst | ta | 10:58 |
| === 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 | ||
| pitti | jdstrand: I'd like to point out bug 1418928 | 13:07 |
| ubottu | 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 | 13:07 |
| === MacSlow|lunch is now known as MacSlow | ||
| jdstrand | pitti: thanks! | 14:12 |
| jdstrand | tyhicks: fyi ^ | 14:13 |
| pitti | jdstrand: ah, should I ping tyhicks in the future about security updates? | 14:13 |
| jdstrand | pitti: either is fine, but typically, yes | 14:15 |
| === brainwash_ is now known as brainwash | ||
| === matsubara is now known as matsubara-lunch | ||
| === kickinz1 is now known as kickinz1|afk | ||
| 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:13 |
| 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 | 16:43 |
| === PaulW2U_ is now known as PaulW2U | ||
| cyphermox | flexiondotorg_: how far how we for reviewing your packages? are you still looking for a second reviewer? | 17:22 |
| === 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 | ||
| 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:29 |
| aeoril | darkxst is there a way to do a checksum or something on a commit? | 22:32 |
| darkxst | aeoril, it would just be an autosync repo, should be fine | 22:33 |
| 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:34 |
| 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:35 |
| aeoril | darkxst oh well, I will start bisecting on the japanese github mirror repo ... | 22:36 |
| darkxst | aeoril, ok | 22:42 |
| 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 | 22:59 |
| 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:01 |
| 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:04 |
| 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:07 |
| 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:10 |
| aeoril | darkxst sarnold wouldn't I just choose that date as a good approximation? But that is almost 5 years ago ... | 23:11 |
| 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:12 |
| 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:13 |
| darkxst | aeoril, really just start at 'v7-4' | 23:14 |
| aeoril | darkxst I am just looking around, trying to learn ... sorry if I am asking too many questions ... | 23:15 |
| aeoril | darkxst where do you see the info that it was v7-4? I am clicking around and do not see that | 23:16 |
| darkxst | its a tag | 23:17 |
| darkxst | aeoril, you should just be able to run git bisect v7-4 | 23:18 |
| darkxst | ^insert bad though | 23:18 |
| 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:21 |
| 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:22 |
| FOSS_drivers_FTW | https://packages.debian.org/search?keywords=xserver-xorg-video-ati&searchon=names&suite=all§ion=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:23 |
| 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:29 |
| 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:30 |
| darkxst | aeoril, go to your git tree | 23:34 |
| 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:35 |
| 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:36 |
| darkxst | aeoril, and 'man git bisect' will give you even better instructions | 23:37 |
| aeoril | ok, cool - thanks | 23:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:42 |
| 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:43 |
| brainwash | FOSS_drivers_FTW: you could file a report and request that the new version is synced | 23:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| darkxst | although there are occassions when the epoch's come from packaging changes (not upstream) | 23:52 |
| aeoril | darkxst ok, cool | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!