Re: Two django packages for Debian?
Hi, On Tue, 05 Aug 2014, Matthew Vernon wrote: > https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-grappelli.git > https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-stronghold.git [...] > Naturally, I'd like to upload these as maintained by > python-modules-t...@lists.alioth.debian.org. Is that going to be OK? If > so, I'll make some ITPs, and initial uploads. I would feel uncomfortable having the name of the team on it while the package is not on a repository writable by all members. (That said I'm also rather annoyed by the fact that the team hasn't switched to git yet.) Looking on git.debian.org, it looks like that some people started using git for team maintained packages: $ ls -al /git/python-modules/packages/ total 48 drwxrwsr-x+ 6 bzed scm_python-modules 4096 juil. 22 09:26 . drwxrws---+ 5 root scm_python-modules 4096 janv. 30 2014 .. drwxrwsr-x+ 7 obergix scm_python-modules 4096 nov. 29 2013 django-ldapdb.git drwxrwsr-x+ 7 azatoth-guest scm_python-modules 4096 mars 18 2013 plastex.git drwxrwsr-x+ 7 zigo scm_python-modules 4096 mai 16 2013 python3-pyparsing.git lrwxrwxrwx 1 aelmahmoudy-guest scm_python-modules 36 juil. 22 09:26 python-whoosh.git -> ../../collab-maint/python-whoosh.git drwxrwsr-x+ 7 dkg scm_python-modules 4096 mars 18 2013 python-xlrd.git So please move your git repository there. /me notes to switch python-django to git. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140806064730.ga13...@x230-buxy.home.ouaza.com
Re: Two django packages for Debian?
On 6 August 2014 03:11, Matthew Vernon wrote: > I've packaged up django-grappelli and django-stronghold (since we have > need for them at work). I think my debianisations are sane, but I've > done them in git not subversion. Repos: > Please make sure these work with Django 1.7 in experimental... -- Brian May
Re: policy for source package names
On Aug 05, 2014, at 04:09 PM, Hans-Christoph Steiner wrote: >I think it is a good practice to make the source package name the same as the >binary package name as long is there isn't a good reason to do otherwise. So >with any source package that produces one binary package, those names should >match. That keeps the Debian namespace smaller and more easy to understand. > >If a source package produces more than one binary package, then I think it >makes the most sense to name the source package using the upstream name, >barring name conflicts, too general a name, etc. In the context of Python libraries, please try to be pro-active, especially if you know that the upstream is or will be supporting both Python 2 and 3. plan-for-success-ly y'rs, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140805161421.1728f...@anarchist.wooz.org
Re: policy for source package names
olivier.sal...@codeless.fr wrote: > > On 08/05/2014 12:04 AM, Vincent Cheng wrote: >> On Mon, Aug 4, 2014 at 2:17 PM, Antonio Valentino >> wrote: >>> Hi list, >>> I read in [1] and [2] that binary packages with public modules should >>> have the python- (or python3-) prefix in the name. >>> I'm wondering if the same naming rules should be used for source packages. >>> >>> I'm preparing some new packages so I would like to be sure I'm using the >>> correct naming before the first upload. >>> >> AFAIK, no, there aren't any hard and fast rules regarding source >> package names. In fact, I don't think there are any rules at all; just >> don't pick a source package name that's already taken, and pick one >> that is relevant to your package (if you take a look at existing DPMT >> packages [1], most of them either use their module name, or prefix it >> with python-). > We have discussed some times about this in different groups (DebianMed > Debian Java ). > I think that usual way is to use for source package the name of the > upstream software (if not already taken of course and matching general > name rules). > > Olivier >> Regards, >> Vincent I think it is a good practice to make the source package name the same as the binary package name as long is there isn't a good reason to do otherwise. So with any source package that produces one binary package, those names should match. That keeps the Debian namespace smaller and more easy to understand. If a source package produces more than one binary package, then I think it makes the most sense to name the source package using the upstream name, barring name conflicts, too general a name, etc. .hc -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e139e0.7060...@at.or.at
Re: [Python-modules-team] Bug#756872: RM: gnupginterface -- ROM; No human maintainer left, dead upstream
On Sunday, August 03, 2014 22:01:00 Dmitry Shachnev wrote: > On Sun, Aug 3, 2014 at 7:06 PM, Barry Warsaw wrote: > > On Aug 02, 2014, at 06:23 PM, Scott Kitterman wrote: > >>If someone on the team is interested in this package staying in Debian and > >>willing to be added to uploaders, please speak up. I don't mind doing the > >>work to modernize the packaging, but don't care to be responsible for it > >>long term. > >> > > I personally don't think it's worth spending time on gnupginterface. We > > have the PyPI package python-gnupg in the archive and its upstream seems > > relatively active. I don't think we have gnupg 1.3.1 (top PyPI hit for > > "gnupg") and that has an even more recent PyPI release. I haven't looked > > at the latter, but I use the former in several projects, including Python > > 3 projects. > > FWIW, that 1.3.1 version is a fork of original python-gnupg. > > According to Github repo description [1], it is "a modified version of > python-gnupg, including security patches, extensive documentation, and > extra features". > > [1] https://github.com/isislovecruft/python-gnupg Thanks for the feedback everyone. gnupginterface is removed from Unstable as of today. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1492557.LLhoBq6Xn3@scott-latitude-e6320
Two django packages for Debian?
Hi, I've packaged up django-grappelli and django-stronghold (since we have need for them at work). I think my debianisations are sane, but I've done them in git not subversion. Repos: https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-grappelli.git https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-stronghold.git Resulting packages: http://www-uxsup.csx.cam.ac.uk/~mcv21/debian/pool/main/d/django-grappelli/ http://www-uxsup.csx.cam.ac.uk/~mcv21/debian/pool/main/d/django-stronghold/ Description: Grappelli, a jazzy skin for the Django admin interface Grappelli is a grid-based alternative/extension to the Django administration interface. Description: makes all Django views default to login_required Stronghold is a small Django app that makes your Django project default to requiring login for all views. Naturally, I'd like to upload these as maintained by python-modules-t...@lists.alioth.debian.org. Is that going to be OK? If so, I'll make some ITPs, and initial uploads. Cheers, Matthew -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e1102e.5070...@debian.org
Re: policy for source package names
On 08/05/2014 12:04 AM, Vincent Cheng wrote: > On Mon, Aug 4, 2014 at 2:17 PM, Antonio Valentino > wrote: >> Hi list, >> I read in [1] and [2] that binary packages with public modules should >> have the python- (or python3-) prefix in the name. >> I'm wondering if the same naming rules should be used for source packages. >> >> I'm preparing some new packages so I would like to be sure I'm using the >> correct naming before the first upload. >> > AFAIK, no, there aren't any hard and fast rules regarding source > package names. In fact, I don't think there are any rules at all; just > don't pick a source package name that's already taken, and pick one > that is relevant to your package (if you take a look at existing DPMT > packages [1], most of them either use their module name, or prefix it > with python-). We have discussed some times about this in different groups (DebianMed Debian Java ). I think that usual way is to use for source package the name of the upstream software (if not already taken of course and matching general name rules). Olivier > Regards, > Vincent > > [1] > https://qa.debian.org/developer.php?login=python-modules-t...@lists.alioth.debian.org > > > > -- > gpg key id: 4096R/326D8438 (keyring.debian.org) > Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e0d5d9@codeless.fr
Re: Help needed to test packages with Django 1.7
On 08/04/2014 11:30 PM, Barry Warsaw wrote:
> On Aug 04, 2014, at 11:05 PM, Thomas Goirand wrote:
>
>> Well, I'm doing my best to add Python 3 support everywhere I can.
>
> \o/
>
>> I've been doing this for months already. I know it wont be possible to fix
>> everything. Currently, I have 2 blockers which I am working on:
>>
>> - python-memcache
>> - beautifulsoup
>
> Would it be better to port to dependencies to beautifulsoup4 which is already
> Python 3 compatible upstream and available in Debian as python{,3}-bs4? The
> upstream docs claim it's pretty compatible, albeit with some deprecated
> (non-PEP 8 compliant) names.
>
> http://www.crummy.com/software/BeautifulSoup/bs4/doc/#porting-code-to-bs4
>
> Cheers,
> -Barry
I also just saw that there's already python-bs4 in Debian! :)
Thomas
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e08b5d.8030...@debian.org
