Re: git instead of svn in DPMT policy

[Barry Warsaw]

On Oct 17, 2015, at 08:49 PM, Piotr Ożarowski wrote:

>I moved policy.rst to python-modules.git repo (it was available to edit
>by every team member in SVN as well). It's not OK to edit it and push it
>without having a discussion here (on this mailing list) first, though.

I will make a pass through the file and push a non-master branch for review.

Cheers,
-Barry


pgpLjPoGAQPma.pgp
Description: OpenPGP digital signature

Re: Git migration schedule

[Barry Warsaw]

On Oct 18, 2015, at 07:19 PM, Jean-Michel Vourgère wrote:

>Git multiple remotes is a nice feature. We can plug right into upstream
>tree.

Currently, our git workflow is tarball-based, since we primarily package PyPI
releases, which are tarball-centric, and because orig.tar is required for
uploads.  We've had debates about whether to release from upstream git
revisions, but currently consensus is against that model.

We value consistency across our packages.  TOOWTDI.

My personal opinion is that we should live with the current git workflow
recommendations for a while and see how it goes.  If there are things we can
improve on (e.g. DEP-14 compatibility) then sure, let's discuss the pros and
cons, but let's not change things right now.  I'd like to see how it works in
practice for a while.

>You labelled the wiki as "official" and use terms like "must". I dislike
>that.

I think everyone will agree that we want consistency within the team.  You
want to be able to walk up to any package and just know how it is set up in
git.  That means following the team guidelines -- but there's an escape hatch
for when you really have to (not want to) diverge from the team.  You write a
debian/README.source explaining the rationale and difference.

>Also, for patches, I'm used to source format 3.0 (quilt). Is that bad now?

No.  In the master branch you will see quilt formatted patches.  It's just
that we're saying that the git repo must be compatible with git-dpm, which is
a patch management regime on top of git and gbp.  If you need to generate a
new patch against upstream, we recommend git-dpm to do so.

Now, in practice, it doesn't matter if you ignore git-dpm and just use quilt
*as long as the final state of the repo is compatible with git-dpm*.  Meaning,
in general, you can make whatever local decisions you want as long as they
don't force other team members to go outside of team recommendations.

Think of it like this: nobody cares if you use vim, emacs, or some other
editor because it doesn't affect anybody else.  Nobody cares if you use sbuild
or pbuilder or something else to build your packages for upload because it
doesn't affect anybody else.  But we all have to agree on tag names, branch
names, etc. because those *do* affect everyone.

So if you just use quilt, I don't care, as long as I can walk up to the same
repo and use git-dpm.  Local differences are fine, global differences are not.

>I'm not using git-buildpakage, but a simple debuild (tests) or sbuild
>(for final uploads). sbuild is the tool used by buildd on the official
>packages. I can't begin to understand why it would be unacceptable.

I use sbuild and pbuilder in different contexts.  Again, that's a local
decision so nobody cares.  (I personally always build to source package first
because that gives me maximum flexibility, e.g. to run autopkgtests or
whatever, but that's just me.)

>So basically, I'm out of line. Please soften the new rules.

Not yet please.  We've been using git for 10 days.  Let's give it time to
settle down.

>Can someone point me to some advantages of using gpb?

Again, much of this is a local decision.  Use whatever you want as long as it
doesn't affect other team members.  Where you have to create artifacts such as
tag names that are visible outside your local environment, they must conform
to team conventions, otherwise that defeats much of the purpose of being in
the team.

Cheers,
-Barry

Python Policy

[Barry Warsaw]

So we currently have several places where we have team policy described.

* The Debian wiki
  https://wiki.debian.org/Python and subpages

* Another wiki page:
  https://wiki.debian.org/Teams/PythonModulesTeam

* https://www.debian.org/doc/packaging-manuals/python-policy/
  which comes from the python-defaults (*not* python3-defaults!) in the bzr
  repo at
  http://alioth.debian.org/anonscm/bzr/pkg-python/python-defaults-debian

* "PMPT" policy
  http://python-modules.alioth.debian.org/
  git+ssh://git.debian.org/git/python-modules/tools/python-modules.git
  except that that page specifically isn't represented in the git repo, only
  policy.rst

and maybe more.  This is crazy!  We really need to consolidate all this
information.

That said, I did a pass through policy.rst in the git repo above and pushed
the 'git-policy' branch for review.  `git diff master` to see the proposed
changes.  Here's a summary:

* PMPT -> DPMT - it seems like we mostly refer to ourselves as Debian Python
  Modules Team and rarely if ever Python Modules Packaging Team any more.
  Another opportunity for more consistency.

* Clarified slightly the wording in policy differences between
  team-in-Maintainer and team-in-Uploaders.

* Remove all the references to Subversion and add a short blurb about Git,
  pointing to the GitPackaging wiki page.

Cheers,
-Barry


pgpwsh5ZOfqhd.pgp
Description: OpenPGP digital signature

Re: Python Policy

[Scott Kitterman]

On October 19, 2015 1:31:37 PM EDT, Barry Warsaw  wrote:
>So we currently have several places where we have team policy
>described.
>
>* The Debian wiki
>  https://wiki.debian.org/Python and subpages
>
>* Another wiki page:
>  https://wiki.debian.org/Teams/PythonModulesTeam
>
>* https://www.debian.org/doc/packaging-manuals/python-policy/
>which comes from the python-defaults (*not* python3-defaults!) in the
>bzr
>  repo at
> http://alioth.debian.org/anonscm/bzr/pkg-python/python-defaults-debian
>
>* "PMPT" policy
>  http://python-modules.alioth.debian.org/
>  git+ssh://git.debian.org/git/python-modules/tools/python-modules.git
>except that that page specifically isn't represented in the git repo,
>only
>  policy.rst
>
>and maybe more.  This is crazy!  We really need to consolidate all this
>information.
>
>That said, I did a pass through policy.rst in the git repo above and
>pushed
>the 'git-policy' branch for review.  `git diff master` to see the
>proposed
>changes.  Here's a summary:
>
>* PMPT -> DPMT - it seems like we mostly refer to ourselves as Debian
>Python
>Modules Team and rarely if ever Python Modules Packaging Team any more.
>  Another opportunity for more consistency.
>
>* Clarified slightly the wording in policy differences between
>  team-in-Maintainer and team-in-Uploaders.
>
>* Remove all the references to Subversion and add a short blurb about
>Git,
>  pointing to the GitPackaging wiki page.
>
>Cheers,
>-Barry

That looks good.  The actual Python policy needs to remain separate.  That's 
something intended for the entire archive and not just the team.

Scott K

Re: Python Policy

[Piotr Ożarowski]

[Barry Warsaw, 2015-10-19]
> So we currently have several places where we have team policy described.

no.

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.

Please do not confuse DPMT with this mythic "Python team" which doesn't
exist.

> * The Debian wiki
>   https://wiki.debian.org/Python and subpages

wiki is something everyone can edit. It's a place that can help with
various tasks, it can even be a place where policy is prepared, but it's
not a place to store official documents.

> * Another wiki page:
>   https://wiki.debian.org/Teams/PythonModulesTeam

this is wiki page, not a policy

> * https://www.debian.org/doc/packaging-manuals/python-policy/
>   which comes from the python-defaults (*not* python3-defaults!) in the bzr
>   repo at
>   http://alioth.debian.org/anonscm/bzr/pkg-python/python-defaults-debian

this it THE policy (¹)

> * "PMPT" policy
>   http://python-modules.alioth.debian.org/
>   git+ssh://git.debian.org/git/python-modules/tools/python-modules.git
>   except that that page specifically isn't represented in the git repo, only
>   policy.rst

DPMT and PAPT are two different things

> 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.

> That said, I did a pass through policy.rst in the git repo above and pushed
> the 'git-policy' branch for review.  `git diff master` to see the proposed
> changes.  Here's a summary:

please paste the diff here, on this mailing list

> * PMPT -> DPMT - it seems like we mostly refer to ourselves as Debian Python
>   Modules Team and rarely if ever Python Modules Packaging Team any more.
>   Another opportunity for more consistency.

+1

> * Clarified slightly the wording in policy differences between
>   team-in-Maintainer and team-in-Uploaders.

will comment later, once I have access to git repo

> * Remove all the references to Subversion and add a short blurb about Git,
>   pointing to the GitPackaging wiki page.

as above
-- 
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

[Piotr Ożarowski]

[Piotr Ożarowski, 2015-10-19]
> DPMT and PAPT are two different things

ups, PMPT != PAPT :)

anyway, there are only documents each DPMT should know:
* https://www.debian.org/doc/packaging-manuals/python-policy/
* https://python-modules.alioth.debian.org/policy.html

everything else can help, but if in doubt: check in above documents
-- 
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

Help needed: Bug#802354: python-matplotlib-venn: FTBFS: AttributeError: can't set attribute

[Andreas Tille]

Hi Python team,

I have no idea why this package now fails to build but was building
before.

Any hint would be welcome

 Andreas.

- Forwarded message from "Chris West (Faux)" 
 -

Date: Mon, 19 Oct 2015 19:05:55 +0100
From: "Chris West (Faux)" 
To: Debian Bug Tracking System 
Subject: Bug#802354: python-matplotlib-venn: FTBFS: AttributeError: can't set 
attribute
X-Debian-PR-Message: report 802354
X-Debian-PR-Package: src:python-matplotlib-venn
X-Debian-PR-Keywords: sid stretch
X-Debian-PR-Source: python-matplotlib-venn

Source: python-matplotlib-venn
Version: 0.11-1
Severity: serious
Justification: fails to build from source
Tags: sid stretch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

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=''
  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
E: pybuild pybuild:262: test: plugin custom failed with: exit code=1: 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
dh_auto_test: 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 . returned exit code 13
debian/rules:10: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 25

Full build log:
https://reproducible.debian.net/rb-pkg/unstable/amd64/python-matplotlib-venn.html

-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

___
Debian-med-packaging mailing list
debian-med-packag...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging


- End forwarded message -

-- 
http://fam-tille.de

Re: Python Policy

[Ben Finney]

Piotr Ożarowski  writes:

> [Piotr Ożarowski, 2015-10-19]
> > DPMT and PAPT are two different things
>
> ups, PMPT != PAPT :)

So which of the following are redundant, and which names are canonical?

* Debian Python Modules Team
* Python Module Packaging Team
* Debian Python Maintainers Team

For symmetry with “Python Application Packaging Team” I was under the
impression this is the “Python Module Packaging Team”.

-- 
 \   “If you always want the latest and greatest, then you have to |
  `\  buy a new iPod at least once a year.” —Steve Jobs, MSNBC |
_o__) interview 2006-05-25 |
Ben Finney

Re: Python Policy

[Piotr Ożarowski]

[Ben Finney, 2015-10-19]
> So which of the following are redundant, and which names are canonical?
> 
> * Debian Python Modules Team
> * Python Module Packaging Team

these two are the same thing

> * Debian Python Maintainers Team

this doesn't exist AFAIK

> For symmetry with “Python Application Packaging Team” I was under the
> impression this is the “Python Module Packaging Team”.

it's completely different thing, f.e. we package applications in PAPT
-- 
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

[Piotr Ożarowski]

| diff --git a/policy.rst b/policy.rst
| index c09f03a..9a9abb4 100644
| --- a/policy.rst
| +++ b/policy.rst
| @@ -1,20 +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.
| +  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.
|  
| -  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
| -  packages.
| +  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

+1 to all above

| +  be used in the ``Maintainer`` field on co-maintained packages.

I suggest:

s/``Maintainer`` field/``Maintainer`` or ``Uploaders`` fields/

|  
|For more information send a message to: debian-python@lists.debian.org
|  
| @@ -24,16 +23,17 @@
|  Joining the team
|  
|  
| -The team is open to any python-related package maintainer. To be added on
| +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.

how about adding (taken from the wiki :) this:

  In your email please state that you have read
  https://python-modules.alioth.debian.org/policy.html and
  that you accept it.

| -Don't forget to indicate your Alioth login !
| +Don't forget to indicate your Alioth login!
|  
| -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
| +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
| @@ -48,71 +48,35 @@ 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 members who are only
|  interested in some packages should use the Package Tracking System to
|  follow the packages.
|  
| --
| -Subversion Procedures
| --
| -
| -We're using a Subversion repository to maintain all the packages, th

Re: Git migration schedule

[Brian May]

Barry Warsaw  writes:

> My personal opinion is that we should live with the current git workflow
> recommendations for a while and see how it goes.  If there are things we can
> improve on (e.g. DEP-14 compatibility) then sure, let's discuss the pros and
> cons, but let's not change things right now.  I'd like to see how it works in
> practice for a while.

I suspect some packages may end up needing DEP-14 names for security
fixes and backports.

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...)
-- 
Brian May 

Re: Git migration schedule

[Brian May]

Barry Warsaw  writes:

> Now, in practice, it doesn't matter if you ignore git-dpm and just use quilt
> *as long as the final state of the repo is compatible with git-dpm*.  Meaning,
> in general, you can make whatever local decisions you want as long as they
> don't force other team members to go outside of team recommendations.

I don't see how you could use quilt and maintain compatability with
git-dpm. git-dpm expects all patches to be in git, and will update
debian/patches automatically from git. quilt writes patches directly in
debian/patches/* and doesn't support git.

Not something that concerns me personally, quilt was starting to become
very painful for me. I regularly ended up forgetting the "quilt add"
operation before editing files, resulting in invalid patches.
-- 
Brian May 

Re: Python Policy

[Brian May]

Barry Warsaw  writes:

> * "PMPT" policy
>   http://python-modules.alioth.debian.org/
>   git+ssh://git.debian.org/git/python-modules/tools/python-modules.git

Is policy.rst automatically kept in sync somehow in between
python-modules.git and http://python-modules.alioth.debian.org/?
-- 
Brian May 

Re: DPMT Policy

[Piotr Ożarowski]

[Brian May, 2015-10-19]
> Barry Warsaw  writes:
> 
> > * "PMPT" policy
> >   http://python-modules.alioth.debian.org/
> >   git+ssh://git.debian.org/git/python-modules/tools/python-modules.git
> 
> 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).

I don't see a problem with adding a hook to git to do it. It's not that
we update policy every day, though.
-- 
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

[Brian May]

Piotr Ożarowski  writes:

>> * The Debian wiki
>>   https://wiki.debian.org/Python and subpages
>
> wiki is something everyone can edit. It's a place that can help with
> various tasks, it can even be a place where policy is prepared, but it's
> not a place to store official documents.
>
>> * Another wiki page:
>>   https://wiki.debian.org/Teams/PythonModulesTeam
>
> this is wiki page, not a policy
>
>> * https://www.debian.org/doc/packaging-manuals/python-policy/
>>   which comes from the python-defaults (*not* python3-defaults!) in the bzr
>>   repo at
>>   http://alioth.debian.org/anonscm/bzr/pkg-python/python-defaults-debian
>
> this it THE policy (¹)
>
>> * "PMPT" policy
>>   http://python-modules.alioth.debian.org/
>>   git+ssh://git.debian.org/git/python-modules/tools/python-modules.git
>>   except that that page specifically isn't represented in the git repo, only
>>   policy.rst
>
> DPMT and PAPT are two different things

Are DAPT and PAPT the same thing?

This information should be documented somewhere.

In my words, for Debian project there is a wiki and a policy. For each
team there is a wiki and policy that apply for that team.

The wikis are not official policy, only the policy if official policy.

I don't understand why we need two teams for Python in Debian. DPMT and
DAPT share this mailing list. The only significant difference I see is
one is using git and the other is using subversion.

The description on the DAPT wiki says "We are taking care of Python
applications, i.e. end user programs written in Python that usually do
not provide public modules. We are not about packaging Python modules or
Python interpreter."

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.
-- 
Brian May 

Re: DPMT Policy

[Brian May]

Piotr Ożarowski  writes:

> no, I do it by hand (any other team member can do it as well).

Just as long as it does happen. My main concern was I saw to different
files, and thought that they would be two different versions. Seems this
is not actually a problem.
-- 
Brian May 

Re: Python Policy

[Piotr Ożarowski]

[Brian May, 2015-10-20]
> Are DAPT and PAPT the same thing?

no such thing as DAPT

> This information should be documented somewhere.

should we also document that we're not OpenStack Packaging Team?

> In my words, for Debian project there is a wiki and a policy. For each
> team there is a wiki and policy that apply for that team.
> 
> The wikis are not official policy, only the policy if official policy.
> 
> I don't understand why we need two teams for Python in Debian. DPMT and
> DAPT share this mailing list. The only significant difference I see is
> one is using git and the other is using subversion.

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.

> 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
-- 
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

git-dpm merge conflicts

[Brian May]

Hello,

When the following error occurs, how can I tell what patch it was
attempting to apply at the time?

In this particular case I can guess, however it occurred to me that
there had to be a better way...

git diff in this case shows upstream changes, not my changes. Possibly
because the changes have been applied upstream and the patch is a
NOP. Trying to work out what is going on without reference to the
original patch is somewhat confusing however.

Regards



git-dpm import-new-upstream --ptc --rebase-patched 
../python-mkdocs_0.14.0.orig.tar.gz 

Switched to a new branch 'patched'
Rebasing changes in 'patched' since '9c3e1c4fe92d2eb23173b4ee88efd8e603d859b9' 
onto 'upstream'...
First, rewinding head to replay your work on top of it...
Auto-merging mkdocs/themes/mkdocs/base.html
CONFLICT (content): Merge conflict in mkdocs/themes/mkdocs/base.html

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

Once you finished rebase, don't forget to call update-patches


-- 
Brian May 

Re: git-dpm merge conflicts

[Stefano Rivera]

Hi Brian (2015.10.20_03:54:40_+0200)
> When the following error occurs, how can I tell what patch it was
> attempting to apply at the time?

It's an aborted git rebase, so you should be able to:

git show HEAD

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: Help needed: Bug#802354: python-matplotlib-venn: FTBFS: AttributeError: can't set attribute

[Olivier Sallou]

On 10/19/2015 09:23 PM, Andreas Tille wrote:
> Hi Python team,
>
> I have no idea why this package now fails to build but was building
> before.
>
> Any hint would be welcome
>
>  Andreas.
>
> - Forwarded message from "Chris West (Faux)" 
>  -
>
> Date: Mon, 19 Oct 2015 19:05:55 +0100
> From: "Chris West (Faux)" 
> To: Debian Bug Tracking System 
> Subject: Bug#802354: python-matplotlib-venn: FTBFS: AttributeError: can't set 
> attribute
> X-Debian-PR-Message: report 802354
> X-Debian-PR-Package: src:python-matplotlib-venn
> X-Debian-PR-Keywords: sid stretch
> X-Debian-PR-Source: python-matplotlib-venn
>
> Source: python-matplotlib-venn
> Version: 0.11-1
> Severity: serious
> Justification: fails to build from source
> Tags: sid stretch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org
>
> Dear Maintainer,
>
> 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.

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
> E: pybuild pybuild:262: test: plugin custom failed with: exit code=1: 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
> dh_auto_test: 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 . returned exit code 13
> debian/rules:10: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Error 25
>
> Full build log:
> https://reproducible.debian.net/rb-pkg/unstable/amd64/python-matplotlib-venn.html
>
> -- System Information:
> Debian Release: stretch/sid
> APT prefers unstable
> APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
>
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>
>
> - End forwarded message -
>

-- 
Olivier Sallou
IRISA / University of Rennes 1
Campus de Beaulieu, 35000 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438