Bug#792096: borg packaging: Update
Hello everyone, borgbackup-0.27.0-1 has been packaged and uploaded, and is in the [new] queue. The package is being maintained in collab-maint, all extra repositories and branches on collab-maint or github have been deleted. Since python3-setuptools-scm will behave differently when called in a git clone (it will attempt to construct a version number from the current git commit, which will point to the debian packaging and not the upstream code), a gbp.conf file has been added that makes use of the [export-dir] mechanism. That way, python3-setuptools-scm falls back to reading the metadata files included in the directory (since it will be called outside the git clone), creating the correct (upstream) version number. - Danny [new]: https://ftp-master.debian.org/new.html [export-dir]: http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.building.html#GBP.BUILDING.EXPORT
Bug#792096: borg packaging
Hi Marc!
the problem is the metadata :)
you can see the thread here
https://github.com/borgbackup/borg/pull/290
HTH
G.
Il Giovedì 22 Ottobre 2015 17:57, Marc Haber
ha scritto:
On Tue, Oct 06, 2015 at 01:13:55AM -0400, Antoine Beaupré wrote:
> On 2015-10-06 00:12:19, Gianfranco Costamagna wrote:
> > Hi, Danny has finally got accepted in collab-maint
> > (I forgot that a signed mail was needed for the join).
> >
> > In the next few days I had many other Debian activities that kept
> > myself away from this bug, but I guess we will close it soon.
>
> Happy to hear that! Keep us in the loop here. :)
There seems to be code for 0.27 in alioth collab-maint, but that one
doesn't even survive a debian/rules clean in a minimal sid chroot:
[17/516]mh@salida[debian_chroot sid64]:~/packages/borgbackup/borgbackup$
fakeroot debian/rules clean
rm -f borg/chunker.c borg/compress.c borg/crypto.c borg/hashindex.c
borg/platform_darwin.c borg/platform_freebsd.c borg/platform_linux.c
dh clean --with python3,sphinxdoc --buildsystem=pybuild
dh_testdir -O--buildsystem=pybuild
dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:170: python3.4 setup.py clean
Traceback (most recent call last):
File "setup.py", line 170, in
install_requires=install_requires,
File "/usr/lib/python3.4/distutils/core.py", line 108, in setup
_setup_distribution = dist = klass(attrs)
File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 272, in
__init__
_Distribution.__init__(self,attrs)
File "/usr/lib/python3.4/distutils/dist.py", line 280, in __init__
self.finalize_options()
File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 327, in
finalize_options
ep.load()(self, ep.name, value)
File "/usr/lib/python3/dist-packages/setuptools_scm/integration.py", line 19,
in version_keyword
dist.metadata.version = get_version(**value)
File "/usr/lib/python3/dist-packages/setuptools_scm/__init__.py", line 67, in
get_version
version = version_from_scm(root)
File "/usr/lib/python3/dist-packages/setuptools_scm/__init__.py", line 29, in
version_from_scm
return ep.load()(root)
File "/usr/lib/python3/dist-packages/setuptools_scm/git.py", line 34, in parse
return meta(tag, distance=number, node=node, dirty=dirty)
File "/usr/lib/python3/dist-packages/setuptools_scm/version.py", line 85, in
meta
assert tag is not None, 'cant parse version %s' % tag
AssertionError: cant parse version None
E: pybuild pybuild:262: clean: plugin distutils failed with: exit code=1:
python3.4 setup.py clean
dh_auto_clean: pybuild --clean -i python{version} -p 3.4 --dir . returned exit
code 13
debian/rules:23: recipe for target 'clean' failed
make: *** [clean] Error 25
[18/517]mh@salida[debian_chroot sid64]:~/packages/borgbackup/borgbackup$
This only happens once in a while, being persistent with it sometimes
gives success. I don't understand what's going on here.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
--
To unsubscribe, send mail to 792096-unsubscr...@bugs.debian.org.
Bug#792096: borg packaging
On Tue, Oct 06, 2015 at 01:13:55AM -0400, Antoine Beaupré wrote:
> On 2015-10-06 00:12:19, Gianfranco Costamagna wrote:
> > Hi, Danny has finally got accepted in collab-maint
> > (I forgot that a signed mail was needed for the join).
> >
> > In the next few days I had many other Debian activities that kept
> > myself away from this bug, but I guess we will close it soon.
>
> Happy to hear that! Keep us in the loop here. :)
There seems to be code for 0.27 in alioth collab-maint, but that one
doesn't even survive a debian/rules clean in a minimal sid chroot:
[17/516]mh@salida[debian_chroot sid64]:~/packages/borgbackup/borgbackup$
fakeroot debian/rules clean
rm -f borg/chunker.c borg/compress.c borg/crypto.c borg/hashindex.c
borg/platform_darwin.c borg/platform_freebsd.c borg/platform_linux.c
dh clean --with python3,sphinxdoc --buildsystem=pybuild
dh_testdir -O--buildsystem=pybuild
dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:170: python3.4 setup.py clean
Traceback (most recent call last):
File "setup.py", line 170, in
install_requires=install_requires,
File "/usr/lib/python3.4/distutils/core.py", line 108, in setup
_setup_distribution = dist = klass(attrs)
File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 272, in
__init__
_Distribution.__init__(self,attrs)
File "/usr/lib/python3.4/distutils/dist.py", line 280, in __init__
self.finalize_options()
File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 327, in
finalize_options
ep.load()(self, ep.name, value)
File "/usr/lib/python3/dist-packages/setuptools_scm/integration.py", line 19,
in version_keyword
dist.metadata.version = get_version(**value)
File "/usr/lib/python3/dist-packages/setuptools_scm/__init__.py", line 67, in
get_version
version = version_from_scm(root)
File "/usr/lib/python3/dist-packages/setuptools_scm/__init__.py", line 29, in
version_from_scm
return ep.load()(root)
File "/usr/lib/python3/dist-packages/setuptools_scm/git.py", line 34, in parse
return meta(tag, distance=number, node=node, dirty=dirty)
File "/usr/lib/python3/dist-packages/setuptools_scm/version.py", line 85, in
meta
assert tag is not None, 'cant parse version %s' % tag
AssertionError: cant parse version None
E: pybuild pybuild:262: clean: plugin distutils failed with: exit code=1:
python3.4 setup.py clean
dh_auto_clean: pybuild --clean -i python{version} -p 3.4 --dir . returned exit
code 13
debian/rules:23: recipe for target 'clean' failed
make: *** [clean] Error 25
[18/517]mh@salida[debian_chroot sid64]:~/packages/borgbackup/borgbackup$
This only happens once in a while, being persistent with it sometimes
gives success. I don't understand what's going on here.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#792096: borg packaging
On 2015-10-06 00:12:19, Gianfranco Costamagna wrote: > Hi, Danny has finally got accepted in collab-maint > (I forgot that a signed mail was needed for the join). > > In the next few days I had many other Debian activities that kept > myself away from this bug, but I guess we will close it soon. Happy to hear that! Keep us in the loop here. :) A. -- feature, n: a documented bug | bug, n: an undocumented feature - Mario S F Ferreira
Bug#792096: borg packaging
Hi, Danny has finally got accepted in collab-maint (I forgot that a signed mail was needed for the join). In the next few days I had many other Debian activities that kept myself away from this bug, but I guess we will close it soon. cheers! G. Il Martedì 6 Ottobre 2015 2:06, anarcat ha scritto: Hi folks, So what's holding up the package now? I understand Mark's position, and I don't think the team's efforts should be distracted at this stage. :) Please keep going! The msgpack package was updated, so I am not sure why this is not pushed ahead now! Cheers, A.
Bug#792096: borg packaging
Hi folks, So what's holding up the package now? I understand Mark's position, and I don't think the team's efforts should be distracted at this stage. :) Please keep going! The msgpack package was updated, so I am not sure why this is not pushed ahead now! Cheers, A. signature.asc Description: Digital signature
Bug#792096: borg packaging
Hi Danny, On Thu, Sep 17, 2015 at 01:12:11PM +0200, Danny Edel wrote: > I was surprised to see the reaction my comments generated and like > Gianfranco, I also want to ask Marc to consider rethinking his decision. > I do not think you are spoiling the fun or that insisting on > oldfashioned keeping is a bad thing. I apologize that my choice of > words made you feel that way - I am not a native english speaker either, > so it may have sounded different than I intended. It was not your choice of words that made me decide to pull out. I just tend to not spend time on work that others can do faster and better. It is not that I am dying of boredom while not working on borgbackup ;-) > I chose github as a mirror because I have upload rights there, that's > the only reason. I would also prefer to work on *.debian.org and I will > do so once I have permission. I just thought hosting git repo online > somewhere makes looking at it easier than sending stuff by mail, and > using github seemed like the easier choice than hosting and maintaining > a git browser myself. Since git clones contain the entire history, > switching mirrors shouldn't be complicated once upload permission is > granted. You're fully right. > I chose the "ignore upstream tarball/use git tag" method also just > because it was simpler. Had I imported the release tarball, I would > have had to maintain the list of files that are auto-generated (a simple > *.c won't do, for example _chunker.c is handwritten), and add rules to > remove them from the build dir or change their timestamp so that they > get refreshed at build-time. I understand. Doing such kind of cleanup in debian/rules is just fine. And yes, a list of files needs to be maintained. I am not sure whether the "use git tag" strategy will interfere with Debian's current goal of reproducible builds. If you stay with the strategy, please document this. I think there is a debian/README.source standardized file for such things. > Not having them in the first place made that unnecessary. That's > the reason why upstream git tag seemed easier to create a working > example implementation of the "regenerate files" idea. > > The git tag is gpg-signed with the same key as the tar.gz release, so I > don't really see the difference in authenticity You're right. > Or am I getting this wrong? Not at all. You do the work, you decide. I might have another opinion, but that's just an opinion that you're free to ignore. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#792096: borg packaging
Hello everyone, I was surprised to see the reaction my comments generated and like Gianfranco, I also want to ask Marc to consider rethinking his decision. I do not think you are spoiling the fun or that insisting on oldfashioned keeping is a bad thing. I apologize that my choice of words made you feel that way - I am not a native english speaker either, so it may have sounded different than I intended. I chose github as a mirror because I have upload rights there, that's the only reason. I would also prefer to work on *.debian.org and I will do so once I have permission. I just thought hosting git repo online somewhere makes looking at it easier than sending stuff by mail, and using github seemed like the easier choice than hosting and maintaining a git browser myself. Since git clones contain the entire history, switching mirrors shouldn't be complicated once upload permission is granted. I chose the "ignore upstream tarball/use git tag" method also just because it was simpler. Had I imported the release tarball, I would have had to maintain the list of files that are auto-generated (a simple *.c won't do, for example _chunker.c is handwritten), and add rules to remove them from the build dir or change their timestamp so that they get refreshed at build-time. Not having them in the first place made that unnecessary. That's the reason why upstream git tag seemed easier to create a working example implementation of the "regenerate files" idea. The git tag is gpg-signed with the same key as the tar.gz release, so I don't really see the difference in authenticity, please elaborate why .tar.gz would be superior for validation of borgbackup. From what I understand, an end-user will trust whatever checksum the Maintainer puts into .changes and signs with maintainer key, so this is just an issue of what the maintainer trusts. Or am I getting this wrong? - Danny
Bug#792096: borg packaging
On Tue, Sep 15, 2015 at 09:24:27AM +, Gianfranco Costamagna wrote: > 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. No offense taken, I am just not adept in sharing git repositories. > 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) Go ahead. Actually, it would IMO be best to ditch the repository and push a clone of Danny's work or keep working on github. > For sure once we *all* agree, the repo will move on collab-maint and live > here :) Fine with me. > >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? I am not leaving because you offended me, I am leaving because I see that there are other people taking better care of the package that I could with my limited time. It was entirely my fault for not pushing the pristine-tar branch to the shared repo and for sitting on my local 0.24 version for a month because I wanted to have it verified working first. > (note: I'm not a native english speaker) Neither am I. > 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 :) ) Who does the work says how the work is done. I usually use gbp-import-orig --pristine-tar to maintain the pristine-tar branch and build with gbp buildpackage. Inside the repository there is a package in 3.0 (quilt) format. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
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.
Bug#792096: borg packaging
On Mon, Sep 14, 2015 at 04:28:48PM +, Gianfranco Costamagna wrote: > I'm afraid having a different upstream/pristine-tar messed up things. > even if the tarball is the same, git fails to see a common history. I have neve had such issues when maintaining Debian packages. > I did create a new repository > http://anonscm.debian.org/cgit/collab-maint/borgbackup-new.git > > (for some reasons your repo has the wrong permission bit set) > > > > But I honestly prefer Danny's repository, > https://github.com/dannyedel/pkg-borgbackup > > because he fixed a lot of stuff, including regeneration of built file > at build time. what do you think? 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. 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. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#792096: borg packaging
Hi Marc, I'm afraid having a different upstream/pristine-tar messed up things. even if the tarball is the same, git fails to see a common history. I did create a new repository http://anonscm.debian.org/cgit/collab-maint/borgbackup-new.git (for some reasons your repo has the wrong permission bit set) But I honestly prefer Danny's repository, https://github.com/dannyedel/pkg-borgbackup because he fixed a lot of stuff, including regeneration of built file at build time. what do you think? cheers, G.
Bug#792096: borg packaging
On Fri, Aug 28, 2015 at 11:05:14AM +, Gianfranco Costamagna wrote: > I pushed pristine-tar and upstream branches, for the updated 0.24.0 release, > and > I pushed my debian packaging into master-new. Was this intended to be merged into master? If so, I did something wrong: [51/546]mh@salida:~/packages/borgbackup$ git clone git://anonscm.debian.org/collab-maint/borgbackup.git Cloning into 'borgbackup'... remote: Counting objects: 207, done. remote: Compressing objects: 100% (178/178), done. remote: Total 207 (delta 67), reused 146 (delta 14) Receiving objects: 100% (207/207), 294.42 KiB | 0 bytes/s, done. Resolving deltas: 100% (67/67), done. Checking connectivity... done. [52/547]mh@salida:~/packages/borgbackup$ ls borgbackup/ [53/548]mh@salida:~/packages/borgbackup$ cd borgbackup/ /home/mh/packages/borgbackup/borgbackup [54/549]mh@salida:~/packages/borgbackup/borgbackup$ ls AUTHORS CHANGES docs/MANIFEST.in README.rst setup.cfg versioneer.py borg/debian/ LICENSE PKG-INFO scripts/setup.py [57/552]mh@salida:~/packages/borgbackup/borgbackup$ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/master remotes/origin/master-new remotes/origin/pristine-tar remotes/origin/upstream [60/555]mh@salida:~/packages/borgbackup/borgbackup$ git merge origin/master-new Auto-merging setup.py CONFLICT (add/add): Merge conflict in setup.py Auto-merging setup.cfg CONFLICT (add/add): Merge conflict in setup.cfg Auto-merging docs/usage/serve.rst.inc CONFLICT (add/add): Merge conflict in docs/usage/serve.rst.inc Auto-merging docs/usage/prune.rst.inc CONFLICT (add/add): Merge conflict in docs/usage/prune.rst.inc Auto-merging docs/usage/mount.rst.inc CONFLICT (add/add): Merge conflict in docs/usage/mount.rst.inc Auto-merging docs/usage/list.rst.inc CONFLICT (add/add): Merge conflict in docs/usage/list.rst.inc Auto-merging docs/usage/init.rst.inc CONFLICT (add/add): Merge conflict in docs/usage/init.rst.inc Auto-merging docs/usage/info.rst.inc CONFLICT (add/add): Merge conflict in docs/usage/info.rst.inc Auto-merging docs/usage/extract.rst.inc CONFLICT (add/add): Merge conflict in docs/usage/extract.rst.inc Auto-merging docs/usage/delete.rst.inc CONFLICT (add/add): Merge conflict in docs/usage/delete.rst.inc Auto-merging docs/usage/create.rst.inc CONFLICT (add/add): Merge conflict in docs/usage/create.rst.inc Auto-merging docs/usage/check.rst.inc CONFLICT (add/add): Merge conflict in docs/usage/check.rst.inc Auto-merging docs/usage/change-passphrase.rst.inc CONFLICT (add/add): Merge conflict in docs/usage/change-passphrase.rst.inc Auto-merging docs/usage.rst CONFLICT (add/add): Merge conflict in docs/usage.rst Auto-merging docs/quickstart.rst CONFLICT (add/add): Merge conflict in docs/quickstart.rst Auto-merging docs/internals.rst CONFLICT (add/add): Merge conflict in docs/internals.rst Auto-merging docs/installation.rst CONFLICT (add/add): Merge conflict in docs/installation.rst Auto-merging docs/index.rst CONFLICT (add/add): Merge conflict in docs/index.rst Auto-merging docs/faq.rst CONFLICT (add/add): Merge conflict in docs/faq.rst Auto-merging docs/conf.py CONFLICT (add/add): Merge conflict in docs/conf.py Auto-merging docs/_themes/local/sidebarusefullinks.html CONFLICT (add/add): Merge conflict in docs/_themes/local/sidebarusefullinks.html Auto-merging debian/watch CONFLICT (add/add): Merge conflict in debian/watch Auto-merging debian/patches/rm-github-ribbons.diff CONFLICT (add/add): Merge conflict in debian/patches/rm-github-ribbons.diff Auto-merging debian/control CONFLICT (add/add): Merge conflict in debian/control Auto-merging debian/changelog CONFLICT (add/add): Merge conflict in debian/changelog Auto-merging debian/borg.1 CONFLICT (add/add): Merge conflict in debian/borg.1 Auto-merging borg/xattr.py CONFLICT (add/add): Merge conflict in borg/xattr.py Auto-merging borg/testsuite/repository.py CONFLICT (add/add): Merge conflict in borg/testsuite/repository.py Auto-merging borg/testsuite/platform.py CONFLICT (add/add): Merge conflict in borg/testsuite/platform.py Auto-merging borg/testsuite/helpers.py CONFLICT (add/add): Merge conflict in borg/testsuite/helpers.py Auto-merging borg/testsuite/hashindex.py CONFLICT (add/add): Merge conflict in borg/testsuite/hashindex.py Auto-merging borg/testsuite/chunker.py CONFLICT (add/add): Merge conflict in borg/testsuite/chunker.py Auto-merging borg/testsuite/archiver.py CONFLICT (add/add): Merge conflict in borg/testsuite/archiver.py Auto-merging borg/testsuite/archive.py CONFLICT (add/add): Merge conflict in borg/testsuite/archive.py Auto-merging borg/testsuite/__init__.py CONFLICT (add/add): Merge conflict in borg/testsuite/__init__.py Auto-merging borg/repository.py CONFLICT (add/add): Merge conflict in borg/repository.py Auto-merging borg/remote.py CONFLICT (add/add): Merge conflict in borg/remote.py Auto-merging borg/lrucache.py CONFLICT (add/add): Merge conflict in borg/lrucache.py Auto-merging borg/key.py CONFLICT (
Bug#792096: borg packaging
Hi, >Sure you can join! Do you have access to collab-maint? >https://wiki.debian.org/Alioth/PackagingProject I'm a uploading-DD, so yes :) I offered a debdiff for msgpack package, and tweak a little bit borgbackup package. I pushed pristine-tar and upstream branches, for the updated 0.24.0 release, and I pushed my debian packaging into master-new. looks good to me now. cheers, G.
Bug#792096: borg packaging
On Thu, Aug 13, 2015 at 12:04:02PM +, Gianfranco Costamagna wrote: > Am I in? Sure you can join! Do you have access to collab-maint? https://wiki.debian.org/Alioth/PackagingProject Do you need a sponsor to upload a package? Marc, do you want to setup a more detailed packaging team? Others proposed joining the python app packaging team: https://wiki.debian.org/Teams/PythonAppsPackagingTeam or a new team can be made: https://wiki.debian.org/Teams Or just multiple Uploaders can be specified in the control file: https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer > On Wed, Aug 05, 2015 at 04:10:56PM +, Gianfranco Costamagna wrote: > > > Hi, in order to have the latest w3af in Debian, a new msgpack-python >= > > 0.4.4 > > is needed, can you please update it? > > Current version is 0.4.6, which is needed by borgbackup. Please update > ;-) ... indeed... a. -- Men often become what they believe themselves to be. If I believe I cannot do something, it makes me incapable of doing it. But when I believe I can, then I acquire the ability to do it even if I didn't have it in the beginning. - Mahatma Gandhi signature.asc Description: Digital signature
