=== jordan_ is now known as jordan
[16:33] <mark06> help please, http://vpaste.net/aMDor
[16:33] <mark06> bzr 2.7.0dev1
[16:37] <jelmer> mark06: that's a known issue; see the udd bug tracker
[16:39] <mark06> ok so currently I'm stuck and can't use UDD for this package, right?
[16:41] <jelmer> mark06: there is some option you can set to prevent this
[16:42] <jelmer> mark06: the bug report has details
[16:42] <mark06> I asked in packaging channel but no answer... any suggestion on the following issue?
[16:44] <mark06> it's been a while since I used PPAs and I moved from bare patches to bzr branch, which doesn't fit well with non-UDD packaging... I started my custom pidgin as a bzr branch based on upstream's tarball, well...
[16:45] <mark06> I guess I need to merge all ubuntu-specific changes introduced by the package, I can't simply build my own package from scratch... that'd be easy if I based my branch on the above (if it was ever working)... so I could simply merge....
[16:47] <mark06> so what approach should I do? I'm thinking of doing a bare diff and try applying in the source package... that isn't much elegant as from source code point of view all my commits will be compressed into a single big diff.... but I see no other way... suggestions?
[16:52] <mark06> is there any command to convert a series of commits into a series of separate patch files?
[17:14] <mark06> is it possible to undo an specific commit in a branch? reverse cherry picking?
[17:22] <jelmer> mark06: there is uncommit, or reverse cherry pick
[17:48] <mark06> done, thanks
[18:11] <mark06> what should I use as replacement for bzr builddeb, since I can't do UDD?
[18:18] <mark06> bzr -Olaunchpad.packaging_verbosity=off?
[18:19] <LeoNerd> jelmer: Offhand, do you know the latest progress on bzr-git, and the dulwich version problem? I'm still getting:  bzr: ERROR: exceptions.AttributeError: 'BazaarObjectStore' object has no attribute 'get_graph_walker'
[18:42] <jelmer> mark06: yeah, that will disable the freshness check that is buggy
[18:42] <jelmer> (the exception you ran into before)
[18:44] <jelmer> LeoNerd: nobody is working on bzr-git as far as I know
[18:44] <mark06> took a bit long but worked, thanks!
[18:45] <LeoNerd> jelmer: :(
[18:55] <mark06> is it possible to somehow merge diverging branches?
[18:56] <LeoNerd> Hah.. I have an interesting solution to bzr-git here. It seems the bzr-git plugin can checkout, and can do the pushing parts of commit/push, but can't actually fetch and update.
[18:56] <LeoNerd> So you can make a new checkout, in which you're allowed exactly one commit before it breaks.
[18:56] <LeoNerd> But that commit does at least make it back to github or wherever; so you can just blow away that checkout and make another one for next time. \o/
[19:04] <mark06> bzr status
[19:38] <jelmer> LeoNerd: I might have a look at fixing it for the purpose of git-remote-bzr at some point
[21:37] <mark06> is there any way to tweak bzr builddeb so it doesn't rely on the package version for fetching the upstream version?
[21:37] <jelmer> mark06: that's how debian packaging works, unless I'm misunderstanding?
[21:38] <mark06> I want to use version like 1:2.9.0-rs137-0ubuntu3.1 but it thinks upstream is 1:2.9.0-rs137
[21:39] <mark06> but this is very inconvenient for a *feature* ppa, it's really annoying that every debian/ubuntu update supersedes your features... then the user always get bizarre regression alternations...
[21:40] <mark06> I mean, it's inconvenient to attach rs137 after ubuntu3.1
[21:40] <mark06> unless there's a way to avoid this odd superseding
[21:41] <jelmer> mark06: what does rs137 indicate?
[21:41] <mark06> I didn't get well what exactly makes it guess what the upstream version is like
[21:41] <jelmer> mark06: it just uses the standard format for Debian packages
[21:42] <jelmer> even if you would get bzr-builddeb to use a different upstream version string, all other debian tools would break
[21:42] <mark06> rs137 is my naming scheme for my feature/bug patches to pidgin... http://pidgin.renatosilva.me/
[21:42] <jelmer> mark06: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
[21:42] <jelmer> mark06: if they're changes to the upstream branch and not the packaging, then you indeed want rs137 in the upstream version (as that reflects reality)
[21:44] <mark06> what I mean is given 1:2.9.0-rs137-0ubuntu3.1, why it splits into 1:2.9.0-rs137 ("the upstream") and 0ubuntu3.1, and given 1:2.9.0-0ubuntu3.1-rs137, why it splits into 1:2.9.0 (correct upstream) and 0ubuntu3.1-rs137? the rule is unclear to me
[21:46] <mark06> but in that case the diff from "2.10.9-rs137" upstream  would be essentially void from actual changes and include only debian/ubuntu packaging changes... even so, I don't know how to make it find "2.10.9-rs137" since I am trying to create the very source package and that one still doesn't exist
[21:53] <mark06> is that really the workflow, let this bizarre regression alternation just happen? what ppa developers are expected to do? foresee an upcoming debian/ubuntu update and build before that?
[21:53] <mark06> it would be nice if it automatically merged the debian/ubuntu changes into the ppa
[22:12] <mark06> hmmm I kind of cheated it with 1:2.10.9-rs137+0ubuntu3.1
[22:12] <mark06> it likes the '-0', it seems
[23:25] <mark06> so bzr builddeb could be smarter and create the patch from commit diff
[23:25] <mark06> it rather ignores all the dvcs thing and asks you to dpkg --commit or something, in a bare patch...
[23:26] <jelmer> mark06: that's not bzr-builddeb asking it, but dpkg
[23:28] <mark06> right, but bzr let it happen... it could have handled it automatically since the idea of UDD is not dealing with raw patches anymore right...
[23:35] <jelmer> mark06: it could suggest you run "bzr dep3-patch" instead, I guess