[01:36] <xnox> Logan_: yeah, unlike debian we don't auto-close bugs because (i) this package is still in previous releases (ii) the package might be reintroduced later (iii) it's actually useful information
[02:11] <Logan_> xnox: kk
=== Ursinha-afk is now known as Ursinha
=== yofel_ is now known as yofel
[12:31] <mapreri> help
[12:33] <mapreri> Sorry i used /amsg by mistake
[13:39] <om26er> Hi! could anyone on Quantal with nvidia binary driver please see if bug 1058391 is happening
[13:39] <ubot2> Launchpad bug 1058391 in unity "[nvidia] Desktop rolls over vertically when i open the dash or hud" [Critical,New] https://launchpad.net/bugs/1058391
[14:23] <abuchbinder> Hi! I'm trying to backport a patch into Lucid--it's an isolated bug, simple patch, comes with a test suite, and fixes a loses-user-data bug. Good candidate for SRU, I think.
[14:23] <abuchbinder> The bug is here: https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1059085
[14:24] <ubot2> Launchpad bug 1059085 in vim "recovery silently deletes data in large files." [Undecided,New]
[14:24] <abuchbinder> Ah, convenient. So, if anyone's around--what's the next step here? Do I format a debdiff? Make a bzr branch? If this were Debian, I'd send in a debdiff, but Ubuntu seems to have changed processes at some point. What do I do next for an SRU?
[14:26] <penguin42> abuchbinder: https://wiki.edubuntu.org/StableReleaseUpdates
[14:28] <penguin42> abuchbinder: https://wiki.ubuntu.com/StableReleaseUpdates  (that's the same I think, but from the ubuntu.com )
[14:28] <abuchbinder> Right; I've got that, but how do I format the actual patch?
[14:29] <penguin42> abuchbinder: I've not done SRUs, but debdiffs seem OK, but if you can do a bzr branch they seem happier
[14:30] <penguin42> oh that page doesn't have that on does it
[14:31] <penguin42> abuchbinder: http://developer.ubuntu.com/packaging/html/fixing-a-bug.html
=== emma is now known as em
[14:59] <abuchbinder> So, I want to do an SRU, and I made a branch here: http://bazaar.launchpad.net/~adam-buchbinder/ubuntu/lucid/vim/vim-large-file-recovery/revision/58
[14:59] <abuchbinder> Err, here: https://code.launchpad.net/~adam-buchbinder/ubuntu/lucid/vim/vim-large-file-recovery
[15:00] <abuchbinder> I filed a bug here: https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1059085
[15:00] <ubot2> Launchpad bug 1059085 in vim "recovery silently deletes data in large files." [High,Triaged]
[15:00] <penguin42> abuchbinder: Did you see my http://developer.ubuntu.com/packaging/html/fixing-a-bug.html post before you dropped off before?
[15:02] <abuchbinder> Ah, missed it. Thanks!
[15:04] <penguin42> abuchbinder: I think it might be worth editing the bug description to note that precise and quantal already have versions new enough
=== Jikan is now known as Jikai
[15:04] <abuchbinder> I made a branch and linked it to the bug. So now I run pbuilder to test it, and then run 'bzr lp-propose' to propose merging. There's no extra steps because it's an SRU?
[15:06] <penguin42> abuchbinder: I've not done SRUs, just non-SRU fixes
[15:08] <abuchbinder> (Edited to specify Lucid in the bug report.)
[15:08] <penguin42> abuchbinder: I'd give it a few days and see if anyone responds to your bug and then if you don't get a response see if you can find someone to prod
[15:11] <TJ-> abuchbinder: the main thing with SRUs is the patch should usually be in the development release already, and/or upstream. It can vary, though.
[15:13] <penguin42> TJ-: Looking at packages.u.c precise and quantal have vim versions after the one referenced in teh bug
[15:15] <TJ-> penguin42: We usually check to see if upstream has fixed the issue. If so, we try to backport the same patch with minor fixups if necessary. If the code-base has changed too drastically then a stand-alone patch is acceptable.
=== yofel_ is now known as yofel
[15:37] <abuchbinder> TJ: Yeah; that's what I did.
[15:37] <abuchbinder> See: https://code.launchpad.net/~adam-buchbinder/ubuntu/lucid/vim/vim-large-file-recovery/+merge/127161
[15:37] <abuchbinder> Please let me know if this is reasonable, or if I should be doing something else process-wise.
[15:39] <TJ-> abuchbinder: You'll be good to go, then :)
[15:42] <abuchbinder> Thanks, everyone! I'll be back to nudge people if the patch doesn't get looked at in a few days.
=== jbicha is now known as Guest28143
=== Guest28143 is now known as jbicha_
=== jbicha__ is now known as jbicha
=== glebihan_ is now known as glebihan