Re: Help needed: Bug#802354: python-matplotlib-venn: FTBFS: AttributeError: can't set attribute
Hi Konstantin,
the full story of the problem with tests can be read here:
https://bugs.debian.org/802354
I'll keep you updated if we find a solution but may be you might have
one yourself and can help solving the issue.
On Tue, Oct 20, 2015 at 07:37:57AM +0200, Olivier Sallou wrote:
> > The package fails to build:
> >
> > == 49 passed in 1.17 seconds
> > ===
> > pybuild --test --test-pytest -i python{version} -p 3.4 --test
> > --system=custom "--test-args=cp -a README.rst {home_dir}/build && cd
> > {home_dir}/build && {interpreter} /python-matplotlib-venn-0.11/setup.py
> > test && rm README.rst" --dir .
> > I: pybuild base:170: cp -a README.rst
> > /python-matplotlib-venn-0.11/.pybuild/pythonX.Y_3.4/build && cd
> > /python-matplotlib-venn-0.11/.pybuild/pythonX.Y_3.4/build && python3.4
> > /python-matplotlib-venn-0.11/setup.py test && rm README.rst
> > running test
> > Traceback (most recent call last):
> > File "/python-matplotlib-venn-0.11/setup.py", line 56, in
> > entry_points=''
> I am not an expert, but it seems that entry_points is expected to be a
> dict ( = {} ) . As it is empty, I think it could just be removed.
The problematic chunk is probably not entry_points but rather
self.test_args = []
> Olivier
> > File "/usr/lib/python3.4/distutils/core.py", line 148, in setup
> > dist.run_commands()
> > File "/usr/lib/python3.4/distutils/dist.py", line 955, in run_commands
> > self.run_command(cmd)
> > File "/usr/lib/python3.4/distutils/dist.py", line 973, in run_command
> > cmd_obj.ensure_finalized()
> > File "/usr/lib/python3.4/distutils/cmd.py", line 107, in ensure_finalized
> > self.finalize_options()
> > File "/python-matplotlib-venn-0.11/setup.py", line 21, in finalize_options
> > self.test_args = []
> > AttributeError: can't set attribute
I tried a web search for this kind of error and found
https://github.com/marshmallow-code/marshmallow/issues/300
which was solved in this patch
https://github.com/marshmallow-code/marshmallow/commit/1dbcae9c439d1a268717feb089351fc3c5180ac3#diff-2eeaed663bd0d25b7e608891384b7298
I tried to implement this idea in python-matplotlib-venn but the change
relies on the existence of a dir tests/ which is not part of the download
tarball (but of the upstream Git repository[1]).
If I apply the attached patch *and* copy the tests/ dir from upstream
Git repository I get
$ python3.4 setup.py test
running test
Searching for pytest
Best match: pytest 2.8.2
Processing pytest-2.8.2-py3.4.egg
Using
/home/andreas/debian-maintain/repack/python-matplotlib-venn/python-matplotlib-venn-0.11/.eggs/pytest-2.8.2-py3.4.egg
Searching for py>=1.4.29
Best match: py 1.4.30
Processing py-1.4.30-py3.4.egg
Using
/home/andreas/debian-maintain/repack/python-matplotlib-venn/python-matplotlib-venn-0.11/.eggs/py-1.4.30-py3.4.egg
running egg_info
writing dependency_links to matplotlib_venn.egg-info/dependency_links.txt
writing top-level names to matplotlib_venn.egg-info/top_level.txt
writing requirements to matplotlib_venn.egg-info/requires.txt
writing matplotlib_venn.egg-info/PKG-INFO
reading manifest file 'matplotlib_venn.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'matplotlib_venn.egg-info/SOURCES.txt'
running build_ext
--
Ran 0 tests in 0.000s
OK
Hmmm, doing all the things without any test run does not seem sensible.
I'm out of ideas now and any help would be welcome.
Kind regards
Andreas.
[1] https://github.com/konstantint/matplotlib-venn
--
http://fam-tille.de
Description: https://github.com/marshmallow-code/marshmallow/commit/1dbcae9c439d1a268717feb089351fc3c5180ac3#diff-2eeaed663bd0d25b7e608891384b7298
Ends-Up-in:
running build_ext
Traceback (most recent call last):
File "/build/python-matplotlib-venn-0.11/setup.py", line 41, in
test_suite='tests'
File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
dist.run_commands()
File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
self.run_command(cmd)
File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File "/usr/lib/python2.7/dist-packages/setuptools/command/test.py", line 146, in run
self.with_project_on_sys_path(self.run_tests)
File "/usr/lib/python2.7/dist-packages/setuptools/command/test.py", line 127, in with_project_on_sys_path
func()
File "/usr/lib/python2.7/dist-packages/setuptools/command/test.py", line 167, in run_tests
testRunner=self._resolve_as_ep(self.test_runner),
File "/usr/lib/python2.7/unittest/main.py", line 94, in __init__
self.parseArgs(argv)
File "/usr/lib/python2.7/unittest/main.py", line 149, in parseArgs
self.createTests()
File "/usr/lib/python2.7/unittest/main.py", line 158, in createTests
self.module)
File "/usr/lib/python2.7/unittest/loader.py", line 130,
Bug#802457: ITP: APLpy -- Astronomical Plotting Library in Python
Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: APLpy Version : 1.0 Upstream Author : Thomas Robitaille and Eli Bressert * URL : http://aplpy.github.io/ * License : MIT Programming Lang: Python Description : Astronomical Plotting Library in Python APLpy is a Python module aimed at producing publication-quality plots of astronomical imaging data in FITS format. The module uses Matplotlib, a powerful and interactive plotting package. It is capable of creating output files in several graphical formats, including EPS, PDF, PS, PNG, and SVG. It will maintained within the Debian Astronomy Working Group. A git repository will be created on alioth [2]. Best regards Ole [1] http://www.astropy.org/affiliated/index.html [2] https://anonscm.debian.org/cgit/debian-astro/packages/aplpy.git
Bug#802468: ITP: spectral-cube -- Read, manipulate, analyze, and write astronomical data cubes
Package: wnpp Owner: Ole Streicher Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org * Package name: spectral-cube Version : 0.3 Upstream Author : Adam Ginsburg et al. * URL : http://spectral-cube.readthedocs.org * License : BSD-3-Clause Programming Lang: Python Description : Read, manipulate, analyze, and write astronomical data cubes The spectral-cube package provides an easy way to read, manipulate, analyze, and write data cubes with two positional dimensions and one spectral dimension, optionally with Stokes parameters. spectral-cube aims to be a versatile data container for building custom analysis routines. It provides the following main features: * A uniform interface to spectral cubes, robust to the wide range of conventions of axis order, spatial projections, and spectral units that exist in the wild. * Easy extraction of cube sub-regions using physical coordinates. * Ability to easily create, combine, and apply masks to datasets. * Basic summary statistic methods like moments and array aggregates. * Designed to work with datasets too large to load into memory. It will maintained within the Debian Astronomy Working Group. A git repository will be created on alioth [2]. Best regards Ole [1] http://www.astropy.org/affiliated/index.html [2] https://anonscm.debian.org/cgit/debian-astro/packages/spectral-cube.git
Re: Git migration schedule
On Oct 20, 2015, at 08:30 AM, Brian May wrote: >I suspect some packages may end up needing DEP-14 names for security >fixes and backports. Possibly so. >The problem here is with the naming of the upstream branches is >different. Although security updates and backports are unlikely to use >new upstream versions, git-dpm appears to use upstream- as >the upstream branch name if the debian branch is not master. Either >should be upstream or upstream/. > >Also see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801666 > >I don't (yet) see a significant problem with using master instead of >debian/master, unless you want to maintain seperate branches for Ubuntu >and Debian packages (a level of complexity I prefer not to think too >much about right now...) I've done this for a few packages where I have to have Ubuntu deltas. pex was a good example, although the delta has been resolved, so now the Debian and Ubuntu versions are identical. It does seem like DEP-14 has thought of these complications. My concern is that these should be rare so it seems nicer to optimize for the common (simple) case and allow for the more complicated branch names when needed. Cheers, -Barry
Re: DPMT Policy
On Oct 19, 2015, at 11:59 PM, Piotr Ożarowski wrote: >[Brian May, 2015-10-19] >> Is policy.rst automatically kept in sync somehow in between >> python-modules.git and http://python-modules.alioth.debian.org/? > >no, I do it by hand (any other team member can do it as well). How? Cheers, -Barry
Re: Python Policy
Thanks for the feedback Piotr. I've made all the changes you suggest, except one. I'll discuss that below and include an updated diff against master. On Oct 19, 2015, at 11:26 PM, Piotr Ożarowski wrote: >I'm against this change. If we want all team packages to follow some >rules, these rules need to be in policy document, not on the wiki page. >I don't want this page to be removed, policy can even point to it, but I >want it to be crystal clear that the binding document is the policy, not >any other document in the internet (even if it's very helpful). > >What am I missing here is a set of branch/tag names and procedures >(f.e. I didn't know that git pull is not enough and I should gbp pull or >update pristine-tar branch by hand) and debian/patches related set of rules >(do we require git-dpm or can one use plain quilt of some other rules >are followed?) Here's my concern: I don't want too much duplication of information in multiple locations. That's a sure recipe for bitrot, and I know no one wants to have to edit information in more than one place. Until now, the wiki has been the more convenient place to make these changes, but I agree in principle with your opinion that some of that information must be captured in policy. So here's what I suggest. For standards we must all adhere to, such as branch and tag names, source-full branches, the use of git-dpm, and maybe a few other points, these should go in policy.rst. The wiki page points to the policy document but doesn't otherwise describe those details. That way, there's only one place to change when/if these standards change. The wiki then goes on to describe common workflows, how to create new repositories, mr, etc. These aren't specifically policy related but are mostly there to help developers get started, or handle tricky situations. If you're in agreement with that split, I'll update both the policy and wiki. Cheers, -Barry diff --git a/policy.rst b/policy.rst index c09f03a..aed57c0 100644 --- a/policy.rst +++ b/policy.rst @@ -1,19 +1,19 @@ - - Python Modules Packaging Team - Policy - += + Debian Python Modules Team - Policy += -:Author: Gustavo Franco , Raphaël Hertzog +:Author: Gustavo Franco , Raphaël Hertzog , Barry Warsaw :License: GNU GPL v2 or later :Introduction: - Python Modules Packaging Team aims to improve the python modules situation - in Debian, by packaging available modules that may be useful and providing - a central location for packages maintained by a team, hence improving - responsiveness, integration and standardization. - - PMPT or just python-modules is hosted at alioth.debian.org, the Debian - GForge installation. We currently have a SVN repository and a mailing list - whose email address can be used in the Maintainer field on co-maintained + The Debian Python Modules Team (DPMT) aims to improve the Python modules + situation in Debian, by packaging available modules that may be useful and + providing a central location for packages maintained by a team, hence + improving responsiveness, integration, and standardization. + + The DPMT is hosted at alioth.debian.org, the Debian GForge installation. We + currently have a git repository and a mailing list whose email address can + be used in the ``Maintainer`` or ``Uploaders`` fields on co-maintained packages. For more information send a message to: debian-python@lists.debian.org @@ -24,16 +24,21 @@ Joining the team -The team is open to any python-related package maintainer. To be added on -the team, please send your request on debian-python@lists.debian.org -indicate why you want to join the team: maintain your current packages -within the team, help maintain some specific packages, etc. -Don't forget to indicate your Alioth login ! +The team is open to any Python-related package maintainer. To be added to +the team, please send your request to debian-python@lists.debian.org. Include +the following in your request: -Any Debian developer who wishes to integrate his packages in the team can do so -without requesting access (as the repository is writable by all DD). If one +* Why you want to join the team: e.g. maintain your current packages within + the team, help maintain some specific packages, etc. +* Your Alioth login. +* A statement that you have read + https://python-modules.alioth.debian.org/policy.html and that you accept it. + +Any Debian developer who wishes to integrate his packages in the team can do +so without requesting access (as the repository is writable by all DD). If one wants to be more involved in the team, we still recommend requesting_ access -so that he appears in the public member list displayed on Alioth's project page. +so that they appear in the public member list displayed on Alioth's project +page. The team accepts all c
Re: Python Policy
On Oct 19, 2015, at 09:04 PM, Piotr Ożarowski wrote: >Debian Python Policy¹ is something every single packages that extends >Python should follow. There are many teams (more than 4) each of them >can have their own policy that extends DPP. This is an important distinction that I don't think is really captured anywhere. Let me rephrase it to see if I'm capturing your sentiment. There is Debian Python Policy which describes the standards for publishing Python libraries and applications within the Debian archive. It is a Debian Project-wide standard, irrespective of which team, if any, is maintaining the Python package. There is the DPMT, a team for co-maintaining Python libraries. It has its own policy document for how those libraries are maintained, and adheres to DPP for publishing those libraries in the archive. There is the PAPT, a team for co-maintaining Python applications. While there may be overlap with DPMT (e.g. some upstream packages provide both libraries and applications), PAPT has its own policy document for how those applications are maintained, and adheres to DPP for publishing those applications in the archive. >> and maybe more. This is crazy! We really need to consolidate all this >> information. > >why? again, if you want to describe common Python related things - DPP >is the place, if it's team specific, please allow each team to have >their own rules. My concern here is discoverability and knowing the procedures for making changes to the various policies. Am I the only one who thinks that it's harder than necessary to find the right information? Cheers, -Barry
Re: Python Policy
On Oct 20, 2015, at 12:37 AM, Piotr Ożarowski wrote: >should we also document that we're not OpenStack Packaging Team? Or zope-packaging? . Agreed that there are different teams here, but I am hoping that we can do some consolidation. E.g. I posted on the zope list that I'd like to pull those packages into DPMT. I heard *zero* responses, so I'm honestly not sure there's still anybody who cares about that team. (I'll post on the wider debian lists to follow up, but I will take silence as assent at some point.) >there is one HUGE difference, one is about packaging MODULES and the >other one is packaging APPLICATIONS. One provides python-, python3- >and/or pypy- packages, the other cannot do that. Although there is often overlap. Some packages intentionally provide both libraries and applications. These usually end up in DPMT, which I think is fine. I also think it would be fine to *eventually* merge the two teams. I suspect there isn't really much benefit to keeping them separate and a lot of unnecessary cost. Is there anybody on PAPT who doesn't want to be on DPMT? Is there any reason why team policy couldn't be expanded to describe the few differences between packaging libraries and pure-applications? >> There are packages that do not provide public modules that are aimed at >> developers. I imagine there are also packages that are end user >> applications that do provide public modules, for end user >> programming. These end user's may require the first group of packages >> aimed at developers too. > >if something installs into dist-packages, it should (I'd make it a >"must", but it's just me) provide python-/python3-/pypy- binary >package. Python application should not (again, "must" is much better >here IMO) pollute global Python namespace I'm not sure I'd go as far as MUST, but aside from that, there's no inherent reason IMHO why these two policies and procedures couldn't co-exist within the same team. Cheers, -Barry
Re: Python Policy
[Barry Warsaw, 2015-10-20] > On Oct 19, 2015, at 09:04 PM, Piotr Ożarowski wrote: > > >Debian Python Policy¹ is something every single packages that extends > >Python should follow. There are many teams (more than 4) each of them > >can have their own policy that extends DPP. > > This is an important distinction that I don't think is really captured > anywhere. Let me rephrase it to see if I'm capturing your sentiment. > > There is Debian Python Policy which describes the standards for publishing > Python libraries and applications within the Debian archive. It is a Debian > Project-wide standard, irrespective of which team, if any, is maintaining the > Python package. > > There is the DPMT, a team for co-maintaining Python libraries. It has its own > policy document for how those libraries are maintained, and adheres to DPP for > publishing those libraries in the archive. correct > There is the PAPT, a team for co-maintaining Python applications. While there > may be overlap with DPMT (e.g. some upstream packages provide both libraries > and applications), PAPT has its own policy document for how those applications > are maintained, and adheres to DPP for publishing those applications in the > archive. just to make it even clearer: if package provides a tiny script that uses library, it should go to DPMT. If package provides an app and a tiny library (I'm thinking about real library, not just those where maintainer forgot to set --install-lib correctly and installs app into dist-packages) - it's a PAPT candidate. --install-lib is the main difference between DPMT and PAPT. There are different set of problems when you install into dist-packages and outside this directory. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Python Policy
[Barry Warsaw, 2015-10-20] > I also think it would be fine to *eventually* merge the two teams. I suspect > there isn't really much benefit to keeping them separate and a lot of > unnecessary cost. Is there anybody on PAPT who doesn't want to be on DPMT? /me puts his PAPT admin hat on WHAT? You want us to learn about all these weird package name rules? All these transitions? All these so name abi ext whatever weird tags? GO AWAY! /me puts his DPMT admin hat on WHAT? Do you know these guys despise our belowed dist-packages? And they have weird package names that do not start with python-! GO AWAY! ;P > I'm not sure I'd go as far as MUST, but aside from that, there's no inherent > reason IMHO why these two policies and procedures couldn't co-exist within the > same team. DPMT is already too big, please don't add applications to make it even more complicated -- evil general Piotr
Re: DPMT Policy
> >> Is policy.rst automatically kept in sync somehow in between > >> python-modules.git and http://python-modules.alioth.debian.org/? > > > >no, I do it by hand (any other team member can do it as well). > > How? scp policy.rst alioth:dpmt_home/public_html -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Python Policy
[Barry Warsaw, 2015-10-20] > Here's my concern: I don't want too much duplication of information in > multiple locations. That's a sure recipe for bitrot, and I know no one wants > to have to edit information in more than one place. > > Until now, the wiki has been the more convenient place to make these changes, > but I agree in principle with your opinion that some of that information must > be captured in policy. So here's what I suggest. > > For standards we must all adhere to, such as branch and tag names, source-full > branches, the use of git-dpm, and maybe a few other points, these should go in > policy.rst. > > The wiki page points to the policy document but doesn't otherwise describe > those details. That way, there's only one place to change when/if these > standards change. > > The wiki then goes on to describe common workflows, how to create new > repositories, mr, etc. These aren't specifically policy related but are > mostly there to help developers get started, or handle tricky situations. > > If you're in agreement with that split, I'll update both the policy and wiki. if policy describes f.e. tag name convention and our tools create correct configuration out of the box, then there's no need to mention it on the wiki so yes, I agree with what you said. I don't even mind to list only few things in policy now and extend it later, once we figure out whats best for us (and work on wiki only for now), but at some point I want a set of rules (a "standard"!) that will make my life as sponsor easier and this is F*G important for me. I will leave this team the moment I have to read README.sources each day when I sponsor a package. If you want help from me, make it easier for me to review your work. (most of RFS emails I get contain "RFS: DPMT: foo version" subject and nothing else, it works for me, I'm lazy and I prefer to read non-technical books rather than RFS mails :P) -- evil general Piotr
Re: Python Policy
On Oct 20, 2015, at 05:16 PM, Piotr Ożarowski wrote: >I will leave this team the moment I have to read README.sources each day when >I sponsor a package. Nobody wants that! (either you leaving or having to read README.source for every package). Cheers, -Barry
Re: Python Policy
Latest diff against master. If you're happy with this, I'll merge to master, update the web page, and trim the wiki. Cheers, -Barry diff --git a/policy.rst b/policy.rst index c09f03a..123792c 100644 --- a/policy.rst +++ b/policy.rst @@ -1,39 +1,44 @@ - - Python Modules Packaging Team - Policy - += + Debian Python Modules Team - Policy += -:Author: Gustavo Franco , Raphaël Hertzog +:Author: Gustavo Franco , Raphaël Hertzog , Barry Warsaw :License: GNU GPL v2 or later :Introduction: - Python Modules Packaging Team aims to improve the python modules situation - in Debian, by packaging available modules that may be useful and providing - a central location for packages maintained by a team, hence improving - responsiveness, integration and standardization. - - PMPT or just python-modules is hosted at alioth.debian.org, the Debian - GForge installation. We currently have a SVN repository and a mailing list - whose email address can be used in the Maintainer field on co-maintained + The Debian Python Modules Team (DPMT) aims to improve the Python modules + situation in Debian, by packaging available modules that may be useful and + providing a central location for packages maintained by a team, hence + improving responsiveness, integration, and standardization. + + The DPMT is hosted at alioth.debian.org, the Debian GForge installation. We + currently have a git repository and a mailing list whose email address can + be used in the ``Maintainer`` or ``Uploaders`` fields on co-maintained packages. For more information send a message to: debian-python@lists.debian.org .. contents:: - + Joining the team - + -The team is open to any python-related package maintainer. To be added on -the team, please send your request on debian-python@lists.debian.org -indicate why you want to join the team: maintain your current packages -within the team, help maintain some specific packages, etc. -Don't forget to indicate your Alioth login ! +The team is open to any Python-related package maintainer. To be added to +the team, please send your request to debian-python@lists.debian.org. Include +the following in your request: -Any Debian developer who wishes to integrate his packages in the team can do so -without requesting access (as the repository is writable by all DD). If one +* Why you want to join the team: e.g. maintain your current packages within + the team, help maintain some specific packages, etc. +* Your Alioth login. +* A statement that you have read + https://python-modules.alioth.debian.org/policy.html and that you accept it. + +Any Debian developer who wishes to integrate his packages in the team can do +so without requesting access (as the repository is writable by all DD). If one wants to be more involved in the team, we still recommend requesting_ access -so that he appears in the public member list displayed on Alioth's project page. +so that they appear in the public member list displayed on Alioth's project +page. The team accepts all contributors and is not restricted to Debian developers. Several Debian developers of the team will gladly sponsor packages of non-DD @@ -43,91 +48,129 @@ discussion list or on #debian-python IRC channel (OFTC network). All team members should of course follow the main discussion list: debian-python@lists.debian.org --- + Maintainership --- +== A package maintained within the team should have the name of the team either -in the Maintainer field or in the Uploaders field. +in the ``Maintainer`` field or in the ``Uploaders`` field. Maintainer: Debian Python Modules Team This enables the team to have an overview of its packages on the DDPO_website_. -* Team in Maintainers is a strong statement that fully collaborative - maintenance is preferred. Anyone can commit to the vcs and upload as - needed. A courtesy email to Uploaders can be nice but not required. +* Team in ``Maintainers`` is a strong statement that fully collaborative + maintenance is preferred. Anyone can commit to the git repository and upload + as needed. A courtesy email to ``Uploaders`` can be nice but not required. -* Team in Uploaders is a weak statement of collaboration. Help in maintaining - the package is appreciated, commits to vcs are freely welcomed, but before - uploading, please contact the Maintainer for the green light. +* Team in ``Uploaders`` is a weak statement of collaboration. Help in + maintaining the package is appreciated, commits to the git repository are + freely welcomed, but before uploading, please contact the ``Maintainer`` for + the green light. Team members who have broad interest should subscribe to the mailing list python-modules-t...@lists.alioth.debian.org whereas mem
Re: Python Policy
thanks a lot for preparing all this. On 10/20/2015 10:53 PM, Barry Warsaw wrote: > +DPMT requires upstream tarballs; releases cannot be made from upstream git > +repositories directly. This is because PyPI contains upstream tarballs, and > +tarballs are what we upload to the Debian archive. i find the justification a bit weird: "no releases can be made from upstream git because some upstreams use tarballs"? in any case, i don't think that there is actually a need for the policy to justify the decision to require tarballs (let's put that in the wiki for those interested). gfmsadr IOhannes signature.asc Description: OpenPGP digital signature
Re: Python Policy
[Barry Warsaw, 2015-10-20] > Latest diff against master. If you're happy with this, I'll merge to master, > update the web page, and trim the wiki. I have few comments, but even if I didn't, please wait at least until after the weekend (or better: 7 days) so that others have time to review it and comment / propose changes. I removed everything that sounds fine to me. > +DPMT requires upstream tarballs; releases cannot be made from upstream git > +repositories directly. This is because PyPI contains upstream tarballs, and > +tarballs are what we upload to the Debian archive. I'd remove this paragraph. Releases can be made via `git archive` and I did that many times (assuming pristine-tar will still keep needed data to regenerate exact same tarball). If you meant that we don't want to keep complete upstream git history, then I agree completely, but I'd made it a "should" rather than "must". > +``gbp build-package`` is used to build the package, either as a source > package s/build-package/buildpackage/ > +for use with ``pbuilder``, ``sbuild``, etc. or as a binary package directory. gbp can use sbuild/pbuilder, here's my ~/.gbp.conf: [buildpackage] builder=sbuild > +Use the following ``git-dpm`` tag formats for the three branches named above. > +Put these lines at the *end* of your ``debian/.git-dpm`` file:: > + > +debianTag="debian/%e%v" > +patchedTag="patches/%e%v" > +upstreamTag="upstream/%e%u" I will update `py2dsp --profile dpmt ...` to do that out of the box, but even then, it's better to suggest that tool in the wiki only, I guess > +All packages which have been automatically converted from the old Subversion > +repository should already have these lines present, but you will need to add > +them for any new packages. that's something for the wiki, not policy, IMO other comment: I'm wondering about something that bit me recently: `gbp pull` instead of `git pull` - should we put that into policy or is wiki warning enough? -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: DPMT Policy
> > >> Is policy.rst automatically kept in sync somehow in between > > >> python-modules.git and http://python-modules.alioth.debian.org/? > > > > > >no, I do it by hand (any other team member can do it as well). > > > > How? > > scp policy.rst alioth:dpmt_home/public_html rst2html policy.rst > policy.html scp policy.* alioth:/srv/alioth.debian.org/chroot/home/groups/python-modules/htdocs/ -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Python Policy
"IOhannes m zmölnig (Debian/GNU)" writes: > thanks a lot for preparing all this. > > On 10/20/2015 10:53 PM, Barry Warsaw wrote: > > +DPMT requires upstream tarballs; releases cannot be made from upstream git > > +repositories directly. This is because PyPI contains upstream tarballs, > > and > > +tarballs are what we upload to the Debian archive. > > i find the justification a bit weird: "no releases can be made from > upstream git because some upstreams use tarballs"? Yes, that is weird, and it's not what you quoted. I don't know how you get that meaning from the text you quoted: This is because PyPI contains upstream tarballs, and tarballs are what we upload to the Debian archive. > in any case, i don't think that there is actually a need for the > policy to justify the decision to require tarballs (let's put that in > the wiki for those interested). On the contrary, I think the Policy document should document the rationale for contingent decisions like this. When it is inevitably discussed again in the future, it is always better to know the intent of the authors. -- \ “Our products just aren't engineered for security.” —Brian | `\ Valentine, senior vice-president of Microsoft Windows | _o__)development, 2002 | Ben Finney
Re: Python Policy
On Oct 21, 2015, at 11:17 AM, Ben Finney wrote: >On the contrary, I think the Policy document should document the >rationale for contingent decisions like this. When it is inevitably >discussed again in the future, it is always better to know the intent of >the authors. +1 Cheers, -Barry
Re: Python Policy
On Oct 20, 2015, at 11:30 PM, Piotr Ożarowski wrote: >I have few comments, but even if I didn't, please wait at least until after >the weekend (or better: 7 days) so that others have time to review it and >comment / propose changes. Fair enough. Of course, it's in a vcs so it's easy to change! :) >I'd remove this paragraph. Releases can be made via `git archive` and I did >that many times (assuming pristine-tar will still keep needed data to >regenerate exact same tarball). If you meant that we don't want to keep >complete upstream git history, then I agree completely, but I'd made it a >"should" rather than "must". What I'm trying to express is the team decision (a couple of debconfs ago) for pristine-tars rather than releasing from upstream git. I do want to keep the rationale in the policy doc; it's one sentence and it seems to come up often enough. Suggestions for better phrasing welcome! >> +``gbp build-package`` is used to build the package, either as a source >> package > >s/build-package/buildpackage/ Fixed, thanks. >> +for use with ``pbuilder``, ``sbuild``, etc. or as a binary package >> directory. > >gbp can use sbuild/pbuilder, here's my ~/.gbp.conf: > > [buildpackage] > builder=sbuild This is the kind of thing that should go in the wiki. >> +Use the following ``git-dpm`` tag formats for the three branches named >> above. >> +Put these lines at the *end* of your ``debian/.git-dpm`` file:: >> + >> +debianTag="debian/%e%v" >> +patchedTag="patches/%e%v" >> +upstreamTag="upstream/%e%u" > >I will update `py2dsp --profile dpmt ...` to do that out of the box, but >even then, it's better to suggest that tool in the wiki only, I guess I think so. The tag format (and IMHO the mechanism to ensure it) should go in policy though. >> +All packages which have been automatically converted from the old >> Subversion +repository should already have these lines present, but you >> will need to add +them for any new packages. > >that's something for the wiki, not policy, IMO Sure. I reworded the policy docs a little bit here. >other comment: >I'm wondering about something that bit me recently: `gbp pull` instead >of `git pull` - should we put that into policy or is wiki warning enough? I think wiki is enough. It is possible to operate with just straight `git pull` because it will still fetch all commits, but when you switch to one of the other branches, you'll see that its head is out of date, and git will prompt you to pull in that branch to update it. `gbp pull` is mostly convenience. Cheers, -Barry
