Bug#792096: borg packaging
Hi Marc,
first, sorry for have messed up your repository, I tried to fix it, but you forgot to push
the pristine tar branch and my branch was different (different hash because of different commit id and timestamp)
please assume good faith, I tried to fix, but I failed because of wrong permissions.
Actually seems that this is fixed.
So the question is: can I rebase your repository and fix it?
(note: this might lead to an history rewrite, sorry in advance)
>I have neve had such issues when maintaining Debian packages.
sure, because your local repository had the pristine-tar branch and the upstream one, maybe :)
>I think that the code that builds a Debian package should be on Debian
>infrastructure. And I think that we should use the pristine tarballs
>released by upstream to have the possibility to compare the tarballs
>by checksum.
ok, let me explain.
I sponsored several packages for Danny, and he told me he wanted to be more involved in Debian.
Actually he wasn't a member of collab-maint (not sure if the situation has changed in the meanwhile)
and since he lost his home partition I took the possibility to show him a package needing a comaintainer,
to see his python packaging skills.
the reason for the github repository is not any kind of "new Debian style of doing things", but the *only*
reason was his inability to work on collab-maint.
For sure once we *all* agree, the repo will move on collab-maint and live here :)
as Debian wiki says
https://wiki.debian.org/PackagingWithGit
there are two good workflows with upstream git repositories, one with upstream tarballs, and the other
with upstream git branches
the first has a pristine-tar with the hash, the second is also trivial to use because you just need to compare with
the upstream git tag.
but this isn't a real problem, I guess Danny's approach can change, or he can have a separate branch to track upstream master branch
(that would be useful to cherry-pick upstream commits easily).
For python packages bisecting doesn't work well, because usually being interpreted means that you can just debug it while running it.
>Currently, it looks like a working team has formed to work on the
>package. That means than I am out. One less cook to spoil the fun, and
>one less old fart to insist on old fashioned package keeping.
>
>If you settle on maintaining borgbackup on github, please make sure to
>kill the repositories on alioth.
After saying I'm sorry for messing up things, I can just only ask you:
can you please rethink your decision and accept my apologies?
(note: I'm not a native english speaker)
please check the borgbackup-new.git collab-maint repository, and let me know if it fits your needs.
If yes, I can just add some patches from Danny's repository on github (rebuilding cython files during builds and so on), and then
we can fix the borgbackup.git repository.
Sorry again, I hope we can cooperate to a common workflow if you still want to help us :)
I updated the borgbackup-new.git repository to 0.25.0 and added some of the fixes from Danny's github repo.
Let me know if the workflow is ok for you
I usually build with dpkg-buildpackage, but for creating the upstream tarball I use git-buildpackage
or origtargz
pristine-tar: successfully generated ../borgbackup_0.25.0.orig.tar.gz
(I see many different workflows in Debian, I would be happy to know your if it differs from mine :) )
cheers!
G.
Reply to: