| === jordan_ is now known as jordan | ||
| mark06 | help please, http://vpaste.net/aMDor | 16:33 |
|---|---|---|
| mark06 | bzr 2.7.0dev1 | 16:33 |
| jelmer | mark06: that's a known issue; see the udd bug tracker | 16:37 |
| mark06 | ok so currently I'm stuck and can't use UDD for this package, right? | 16:39 |
| jelmer | mark06: there is some option you can set to prevent this | 16:41 |
| 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:42 |
| 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:44 |
| 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:45 |
| 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:47 |
| mark06 | is there any command to convert a series of commits into a series of separate patch files? | 16:52 |
| mark06 | is it possible to undo an specific commit in a branch? reverse cherry picking? | 17:14 |
| jelmer | mark06: there is uncommit, or reverse cherry pick | 17:22 |
| mark06 | done, thanks | 17:48 |
| mark06 | what should I use as replacement for bzr builddeb, since I can't do UDD? | 18:11 |
| mark06 | bzr -Olaunchpad.packaging_verbosity=off? | 18:18 |
| 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:19 |
| jelmer | mark06: yeah, that will disable the freshness check that is buggy | 18:42 |
| jelmer | (the exception you ran into before) | 18:42 |
| jelmer | LeoNerd: nobody is working on bzr-git as far as I know | 18:44 |
| mark06 | took a bit long but worked, thanks! | 18:44 |
| LeoNerd | jelmer: :( | 18:45 |
| mark06 | is it possible to somehow merge diverging branches? | 18:55 |
| 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/ | 18:56 |
| mark06 | bzr status | 19:04 |
| jelmer | LeoNerd: I might have a look at fixing it for the purpose of git-remote-bzr at some point | 19:38 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:44 |
| 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:46 |
| 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 | 21:53 |
| mark06 | hmmm I kind of cheated it with 1:2.10.9-rs137+0ubuntu3.1 | 22:12 |
| mark06 | it likes the '-0', it seems | 22:12 |
| 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:25 |
| jelmer | mark06: that's not bzr-builddeb asking it, but dpkg | 23:26 |
| 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:28 |
| jelmer | mark06: it could suggest you run "bzr dep3-patch" instead, I guess | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!