Re: Packaging new version of ZODB (Zope Object Database)
On Friday, November 04, 2016 10:47:32 AM Barry Warsaw wrote: > On Nov 03, 2016, at 08:36 PM, Julien Muchembled wrote: > >I'm used to gbp. I don't know git-dpm (or I forgot after seeing I would not > >like?) > > git-dpm is usually pretty easy, but it's really only used in a few cases, > such as importing a new upstream, managing the patch stack, and tagging. > We document the team's use cases pretty well so you don't even really have > to remember much: > > https://wiki.debian.org/Python/GitPackaging#New_upstream_release > > For a lot of other package management tasks (e.g. building source packages, > cloning, pulling, etc.), gbp works just fine. > > That said, we know git-dpm has not been developed in a very long time, and > is for all intents and purposes, abandonware. It works, so I don't think > there's a huge urgency to get rid of it (obviously, since we haven't ;) but > it should be in our long-term team goals to move away from it. > > >Not sure if all python-modules repositories are like persistent, but for > >me, mixing Debian work with imported tarballs in the same branch is > >terrible. When possible, I prefer to fork the upstream repository, > >otherwise no upstream source at all. > > You're not alone, but I think that's still a minority opinion in the team. > Our packages are so tightly integrated with PyPI, and source tarballs are > such an ingrained aspect of that service, that a pristine-tar based > approach for team packages still makes sense, IMHO. You can integrate a new upstream directly from an upstream git repository with git-dpm if that's what makes sense for a particular upstream. Scott K
Re: Packaging new version of ZODB (Zope Object Database)
On Nov 03, 2016, at 08:36 PM, Julien Muchembled wrote: >I'm used to gbp. I don't know git-dpm (or I forgot after seeing I would not >like?) git-dpm is usually pretty easy, but it's really only used in a few cases, such as importing a new upstream, managing the patch stack, and tagging. We document the team's use cases pretty well so you don't even really have to remember much: https://wiki.debian.org/Python/GitPackaging#New_upstream_release For a lot of other package management tasks (e.g. building source packages, cloning, pulling, etc.), gbp works just fine. That said, we know git-dpm has not been developed in a very long time, and is for all intents and purposes, abandonware. It works, so I don't think there's a huge urgency to get rid of it (obviously, since we haven't ;) but it should be in our long-term team goals to move away from it. >Not sure if all python-modules repositories are like persistent, but for me, >mixing Debian work with imported tarballs in the same branch is >terrible. When possible, I prefer to fork the upstream repository, otherwise >no upstream source at all. You're not alone, but I think that's still a minority opinion in the team. Our packages are so tightly integrated with PyPI, and source tarballs are such an ingrained aspect of that service, that a pristine-tar based approach for team packages still makes sense, IMHO. Cheers, -Barry
RFS python-udatetime/0.0.11-1 [ITP]
Hello team, Could someone please review/sponsor my package "python-udatetime"? The udatetime module offers faster datetime object instantiation, serialization and deserialization of RFC3339 date-time strings, than Python's datatime module. This package offers both a Python 2 and Python 3 library. I plan to maintain this within the DPMT team, and have already created the corresponding git repo[1]. I have also uploaded the package on mentors[2]. Regards, Ilias [1] https://anonscm.debian.org/git/python-modules/packages/python-udatetime.git [2] https://mentors.debian.net/package/python-udatetime signature.asc Description: PGP signature
Bug#843158: ITP: gpxpy -- GPX file parser and GPS track manipulation library
Package: wnpp Severity: wishlist Owner: Dominik George -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: gpxpy Version : 1.1.1 Upstream Author : Tomo Krajina * URL : http://www.trackprofiler.com/gpxpy/index.html * License : Apache Programming Lang: Python Description : GPX file parser and GPS track manipulation library gpxpy is a simple Python library for parsing and manipulating GPX files. GPX is an XML based format for GPS tracks. . The library also contains utility functions that are used in GPX file handling, but can also be used separately, e.g. simple functions for calculating geographical coordinates. The package shall be maintained inside the Debian Python Modules Team. -BEGIN PGP SIGNATURE- iQJhBAEBCABLBQJYHHOWMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW B0IQAL+ktbh5pDNo0fc//HC8AMOf2qybGXZgPl7CDyXEMNuMaY3AvzDOFXKOAC0B Xt+grZF06HcMIxCNVwpyn3KeHWbtXAPzbVUzASyBfb6lFj2UQ3zKUD7zFiiY4rwn NqmIK3BIJ9wV7OtS2mcCInd/i+umQzQR3G4XVhB9Yn/7MpzzIfOqctnduT0Bvzyy ry+lhUQWp/I5/uXb3QmKYKXaO7cdweudkqiqLj9hi8QpmVsgCk8Q45vFxZk+iuOr seObj46NmlInluS0BvAvWZR8RBdUbxufrbQvYDSN2FDycGQQi4eHaUgIibGwyX96 5ZS1LAiAf4yuCAr76/VCXtk6auqPiJLgZi89lARIrYP5o4CnPdOZfa1611UXIdXt Am2w5ZWmOpQkljjsL1HfcNJqcD9AtLck6k4zyv1vqOvIaRInml1l7EEiZPM1TPFM nSADDSCyatywWOLAeZCg9nvU+Ud4gdWVEeAKadLQUXbgeCSDlqzrOKxc7AlsFmUg m41GAJP48Ov5RsuhCzU7dC3PQnQBBIPoQ7z35m0dp75SwWKmAVMCke/6jQIqkz8X UPY0Wj1Y9XYkF6932EKGn3tNEJiady2rYdfTrv/P0xYksLGhSiOZ2DQDdgCb0miS abkZXXdYus5fKrYb46xYtoT1B1Dx7X6ujwCPJXw0Tf4eyKmG =lJUx -END PGP SIGNATURE-
