Re: git-buildpackage pattern question

[Charles Plessy]

Le Mon, Mar 21, 2016 at 06:43:58PM -0700, Sean Whitton a écrit :
> 
> In my usage of git-buildpackage, I've been using a different approach to
> that suggested by Russ and I thought it might be useful to share it in
> this thread.
> 
> I think of (local) branches as things that I expect to make commits to,
> and use tags to keep track of work done by upstream that is read-only
> from my point of view.  So in my repository I have all of upstreams tags
> (1.0.0, 1.1.0, 1.0.2 etc.) and a master branch which contains both
> upstream's code and my debian/ directory.  There is no upstream branch.

Hi Sean,

not to nitpick your workflow itself, but I was wondering: with your approach,
what is the advantage using git-buildpackage instead of simply
`dpkg-buildpackage -i -I` ?  For the sake of curiosity (and sorry to sidetrack
the thread), what `gbp` commands are you still using in your workflow ?

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Bug#818948: RFS: gap-grape/4r7+ds-1 [ITP] -- GRaph Algorithms using PErmutation groups for GAP

[Jerome Benoit]

Package: sponsorship-requests
Severity: normal

Dear Mentors,

I am looking for a sponsor for the new Debian package gap-grape, a 
package
for the Computer Algebra System (CAS) GAP. This package brings nauty to 
GAP.

Thanks in advance,
Jerome

[1] https://anonscm.debian.org/git/debian-science/packages/gap-grape.git

-- System Information:
Debian Release: Jessie*
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.7-ckt20-0001-mbp62 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Re: git-buildpackage pattern question

[Sean Whitton]

Hello,

On Sun, Mar 20, 2016 at 04:35:27PM -0700, Russ Allbery wrote:
> Ross Vandegrift  writes:
> 
> > In my packaging, I've worked on 1.0.0, and updated for 1.0.1 and 1.0.2.
> > So my packaging looks like this:
> 
> > o---ooooo master
> >  \  \
> >   o---o 1.0.0o---o 1.1.0
> >\  \
> > o---o 1.0.1o---o 1.1.1
> >  \
> >   o---o 1.0.2
> >\
> > o  debian/sid
> 
> > To update to 1.1.1, I've read that I should merge 1.1.1 into debian/sid.
> > But this is painful - upstream 1.1.1 conflicts with 1.0.2.
> 
> This is exactly why git-buildpackage by default uses an upstream/latest
> branch that tracks upstream releases. [...]

In my usage of git-buildpackage, I've been using a different approach to
that suggested by Russ and I thought it might be useful to share it in
this thread.

I think of (local) branches as things that I expect to make commits to,
and use tags to keep track of work done by upstream that is read-only
from my point of view.  So in my repository I have all of upstreams tags
(1.0.0, 1.1.0, 1.0.2 etc.) and a master branch which contains both
upstream's code and my debian/ directory.  There is no upstream branch.

When there's a new release, I fetch upstraem's tags and then run
something like `git merge 1.1.1 && dch -v1.1.1`.  In the case you
describe where 1.1.1 cannot be cleanly merged with 1.0.2, I would just
run `git merge --strategy recursive --strategy-option theirs 1.1.1 &&
dch -v1.1.1` which is similar to what Russ suggests, though it avoids
overwriting anything in debian/.  This will always work because all my
modifications are quilt patches so it's okay to overwrite anything
outside of debian/ with the newer upstream version.

The advantage of this is that you don't need to worry about maintaining
an upstream branch.  You just merge tags into your packaging branch,
using the merge strategy to make sure the merges succeed as necessary.
And you don't need to go anywhere near upstream tarballs (you can
generate some using gbp's integration with pristine-tar -- these are
just as good as e.g. the tarballs generated by GitHub).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#818902: RFS: arrayfire/3.3.1+dfsg1-1~exp1

[Ghislain Vaillant]

Indeed, I did not update d/copyright accordingly since the 3.3.x series
of releases. I have just rectified this and uploaded the new version on
mentors.

Thanks,
Ghislain


On 21/03/16 17:20, Gianfranco Costamagna wrote:

control: tags -1 moreinfo
control: owner -1 !

+ * Site:http://NadeauSoftware.com/
+ * License: Creative Commons Attribution 3.0 Unported License
+ *  http://creativecommons.org/licenses/by/3.0/deed.en_US
+ * Source:  
http://nadeausoftware.com/sites/NadeauSoftware.com/files/getMemorySize.c


not listed in copyright file.

the other stuff looks good, but please check carefully all the CC licenses :)

(this is a regression in 3.3.0 to be honest I think)

cheers!

G.





Il Lunedì 21 Marzo 2016 15:57, Ghislain Vaillant  ha 
scritto:
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "arrayfire"

* Package name: arrayfire
Version : 3.3.1+dfsg1-1~exp1
Upstream Author : ArrayFire Development Group
* URL : http://arrayfire.com/
* License : BSD
Section : science

It builds those binary packages:

libarrayfire-cpu-dev - Development files for ArrayFire (CPU backend)
libarrayfire-cpu3 - High performance library for parallel computing
(CPU backend)
libarrayfire-cpu3-dbg - Debugging symbols for ArrayFire (CPU backend)
libarrayfire-dev - Common development files for ArrayFire
libarrayfire-doc - Common documentation and examples for ArrayFire
libarrayfire-opencl-dev - Development files for ArrayFire (OpenCL
backend)
libarrayfire-opencl3 - High performance library for parallel
computing (OpenCL backend)
libarrayfire-opencl3-dbg - Debugging symbols for ArrayFire (OpenCL
backend)
libarrayfire-unified-dev - Development files for ArrayFire (unified
backend)
libarrayfire-unified3 - High performance library for parallel
computing (unified backend)
libarrayfire-unified3-dbg - Debugging symbols for ArrayFire (unified
backend)

To access further information about this package, please visit the
following URL:

   http://mentors.debian.net/package/arrayfire

Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/a/arrayfire/arrayfire_3.3.1+dfsg1-1~exp1.dsc

Successful build logs on debomatic:

[amd64]
http://debomatic-amd64.debian.net/distribution#experimental/arrayfire/3.3.1+dfsg1-1~exp1/buildlog
[i386]
http://debomatic-i386.debian.net/distribution#experimental/arrayfire/3.3.1+dfsg1-1~exp1/buildlog

Changes since the last upload:

* New upstream release.
* Refresh patch Fix-LAPACKE-detection.patch.

Regards,
Ghislain Vaillant

Bug#818921: RFS: python-neovim-gui/0.1.1-1 [ITP]

[Víctor Cuadrado Juan]

I messed up and used Cc instead of X-Debbugs-Cc, please remove
the Cc if answering to this e-mail. Sorry for the noise.

-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.

Bug#818921: RFS: python-neovim-gui/0.1.1-1 [ITP]

[Víctor Cuadrado Juan]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-neovim-gui"

* Package name: python-neovim-gui
  Version : 0.1.1
  Upstream Author : Thiago de Arruda 
* URL : https://github.com/neovim/python-gui
* License : Apache 2.0
  Section : editors
  Description : Simple nvim gui implemented using Gtk

It builds this binary package:
   python3-neovim-gui - Simple nvim gui implemented using Gtk (Python 3)

I intend to maintain it under the DPMT umbrella, which I am part of.

To access further information about this package, please visit the following 
URL:
   https://anonscm.debian.org/cgit/python-modules/packages/python-neovim-gui.git


Regards,


-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.


signature.asc
Description: PGP signature

Bug#814456: RFS: libpam-ufpidentity/1.0-1 [ITP] -- UFP Identity PAM Module

[Richard Levenberg]

The test credentials (example.com) are provided to allow for testing
with the services without having to register. The test credentials only
allow a username 'guest.' The test credentials are only used in the main
method which is only enabled in the static compilation when PIC is NOT
enabled. The main method is not compiled into the library.

The remote service requires registration of a client key/CSR which is
described here:

https://www.ufp.com/identity/integration.html#getting_started

Then send the CSR to i...@ufp.com.

Did you do that?

On 3/21/16 10:45 AM, Gianfranco Costamagna wrote:
> Hi, some questions about the identity4c package:
> why there is an example.com hardcoded in the sources?
> I see also some pem certificates provided here.
> 
> 
> how does it interface with the libpam-ufpidentity?
> I guess in no ways, because it is in the main, right?
> 
> second question: is the remote pam service something under a fee?
> I tried to register on ufp.com or whatever was written on readme, but I got 
> no confirmation email.
> 

Bug#814456: RFS: libpam-ufpidentity/1.0-1 [ITP] -- UFP Identity PAM Module

[Gianfranco Costamagna]

Hi, some questions about the identity4c package:
why there is an example.com hardcoded in the sources?
I see also some pem certificates provided here.


how does it interface with the libpam-ufpidentity?
I guess in no ways, because it is in the main, right?

second question: is the remote pam service something under a fee?
I tried to register on ufp.com or whatever was written on readme, but I got no 
confirmation email.


cheers,


G.

Bug#814921: RFS: sphde/1.1.0-1 [ITP] -- sphde -- Shared Persistent Heap Data Environment library

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hi,
control: std-version is now 3.9.7

libjs-query can be left as-is, because using the internal debian jquery might 
result in a bad documentation
package (look e.g. https://lists.debian.org/debian-devel/2014/10/msg00774.html;)

this can simplify rules, control and so on

debian/*.manpages, you can remove the "debian/tmp" prepending path I think

copyright: is the debian directory under the same author as upstream?
so you can avoid mentioning it.


package FTBFS on i386 and probably everywhere except amd64 (tested amd64, arm64 
and i386 for now).


check-all-the-things:
flawfinder -Q -c .

[lots]
codespell --quiet-level=3
[lots]
some stuff autogenerated seems to be GPL-2 (check-all-the-things output)

the other stuff LGTM.

cheers,

G.



Il Martedì 16 Febbraio 2016 17:03, Frederic Bonnard  
ha scritto:
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sphde"

Package name: sphde
Version : 1.1.0-1
Upstream Author : SPHDE team
URL : https://github.com/sphde/sphde
License : EPL-1
Section : devel

It builds those binary packages:

  libsphde-dev - Shared Persistent Heap Data Environment library development 
files
  libsphde-doc - Shared Persistent Heap Data Environment library documentation 
files
  libsphde1  - Shared Persistent Heap Data Environment library

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/sphde


Alternatively, one can download the package with dget using this command:

dget -x http://mentors.debian.net/debian/pool/main/s/sphde/sphde_1.1.0-1.dsc

More information about sphde can be obtained from https://github.com/sphde/sphde

Regards,
Frederic Bonnard

Bug#818902: RFS: arrayfire/3.3.1+dfsg1-1~exp1

[Gianfranco Costamagna]

control: tags -1 moreinfo
control: owner -1 !

+ * Site:http://NadeauSoftware.com/
+ * License: Creative Commons Attribution 3.0 Unported License
+ *  http://creativecommons.org/licenses/by/3.0/deed.en_US
+ * Source:  
http://nadeausoftware.com/sites/NadeauSoftware.com/files/getMemorySize.c


not listed in copyright file.

the other stuff looks good, but please check carefully all the CC licenses :)

(this is a regression in 3.3.0 to be honest I think)

cheers!

G.





Il Lunedì 21 Marzo 2016 15:57, Ghislain Vaillant  ha 
scritto:
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "arrayfire"

* Package name: arrayfire
   Version : 3.3.1+dfsg1-1~exp1
   Upstream Author : ArrayFire Development Group
* URL : http://arrayfire.com/
* License : BSD
   Section : science

It builds those binary packages:

   libarrayfire-cpu-dev - Development files for ArrayFire (CPU backend)
   libarrayfire-cpu3 - High performance library for parallel computing 
(CPU backend)
   libarrayfire-cpu3-dbg - Debugging symbols for ArrayFire (CPU backend)
   libarrayfire-dev - Common development files for ArrayFire
   libarrayfire-doc - Common documentation and examples for ArrayFire
   libarrayfire-opencl-dev - Development files for ArrayFire (OpenCL 
backend)
   libarrayfire-opencl3 - High performance library for parallel 
computing (OpenCL backend)
   libarrayfire-opencl3-dbg - Debugging symbols for ArrayFire (OpenCL 
backend)
   libarrayfire-unified-dev - Development files for ArrayFire (unified 
backend)
   libarrayfire-unified3 - High performance library for parallel 
computing (unified backend)
   libarrayfire-unified3-dbg - Debugging symbols for ArrayFire (unified 
backend)

To access further information about this package, please visit the 
following URL:

  http://mentors.debian.net/package/arrayfire

Alternatively, one can download the package with dget using this command:

   dget -x 
http://mentors.debian.net/debian/pool/main/a/arrayfire/arrayfire_3.3.1+dfsg1-1~exp1.dsc

Successful build logs on debomatic:

   [amd64] 
http://debomatic-amd64.debian.net/distribution#experimental/arrayfire/3.3.1+dfsg1-1~exp1/buildlog
   [i386] 
http://debomatic-i386.debian.net/distribution#experimental/arrayfire/3.3.1+dfsg1-1~exp1/buildlog

Changes since the last upload:

   * New upstream release.
   * Refresh patch Fix-LAPACKE-detection.patch.

Regards,
Ghislain Vaillant

Bug#818902: RFS: arrayfire/3.3.1+dfsg1-1~exp1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "arrayfire"

* Package name: arrayfire
  Version : 3.3.1+dfsg1-1~exp1
  Upstream Author : ArrayFire Development Group
* URL : http://arrayfire.com/
* License : BSD
  Section : science

It builds those binary packages:

  libarrayfire-cpu-dev - Development files for ArrayFire (CPU backend)
  libarrayfire-cpu3 - High performance library for parallel computing 
(CPU backend)

  libarrayfire-cpu3-dbg - Debugging symbols for ArrayFire (CPU backend)
  libarrayfire-dev - Common development files for ArrayFire
  libarrayfire-doc - Common documentation and examples for ArrayFire
  libarrayfire-opencl-dev - Development files for ArrayFire (OpenCL 
backend)
  libarrayfire-opencl3 - High performance library for parallel 
computing (OpenCL backend)
  libarrayfire-opencl3-dbg - Debugging symbols for ArrayFire (OpenCL 
backend)
  libarrayfire-unified-dev - Development files for ArrayFire (unified 
backend)
  libarrayfire-unified3 - High performance library for parallel 
computing (unified backend)
  libarrayfire-unified3-dbg - Debugging symbols for ArrayFire (unified 
backend)


To access further information about this package, please visit the 
following URL:


  http://mentors.debian.net/package/arrayfire

Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/a/arrayfire/arrayfire_3.3.1+dfsg1-1~exp1.dsc


Successful build logs on debomatic:

  [amd64] 
http://debomatic-amd64.debian.net/distribution#experimental/arrayfire/3.3.1+dfsg1-1~exp1/buildlog
  [i386] 
http://debomatic-i386.debian.net/distribution#experimental/arrayfire/3.3.1+dfsg1-1~exp1/buildlog


Changes since the last upload:

  * New upstream release.
  * Refresh patch Fix-LAPACKE-detection.patch.

Regards,
Ghislain Vaillant

Bug#813813: RFS: msi-keyboard -- command line tool to change MSI steelseries keyboards color setup

[Giulio Paci]

On 20/03/2016 22:37, Jakub Wilk wrote:
> * Giulio Paci , 2016-03-20, 03:05:
>>> I'm looking partly shocked at the commit
>>> 6fc1eec66c259cefeeb13453c3ceeb206fb24a55 why did you *substituted* the 
>>> pristine-tar data?  You should always just add them.
>>
>> This is just because upstream never tagged a version, nor released a package.
>> I imported one using 0.0.1 version, but later noticed that 1.0 was set in 
>> the source and so I renamed the package.
> 
> Um. If upstream didn't make a release, then you ask them to make one, instead 
> of declaring yourself that this random git snapshot will be called 1.0.
> 
> That the source says it's "1.0" is not very relevant, unless upstream bumps 
> version in every commit; and they don't.

You are right. I wrote an email to Brad asking for a release.

> Also, you probably want to fix your debian/watch. :)

This for sure. Although steelskin is an interesting project as well... ;-)

Thank you for these comments.

Bests,
Giulio

Bug#816261: RFS: django-prometheus/1.0.6-1

[Mattia Rizzolo]

On Mon, Mar 21, 2016 at 10:17:43AM +, Mattia Rizzolo wrote:
> Uploading :)

while tagging the release I noticed that the format of the patched tag
was wrong.  I had already uploaded, so I did a commit fixing it *after*
the tag, please pull (and pull the tags)


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#816261: marked as done (RFS: django-prometheus/1.0.6-1 [ITP])

[Debian Bug Tracking System]

Your message dated Mon, 21 Mar 2016 10:17:43 +
with message-id <20160321101743.gd21...@chase.mapreri.org>
and subject line Re: Bug#816261: RFS: django-prometheus/1.0.6-1
has caused the Debian Bug report #816261,
regarding RFS: django-prometheus/1.0.6-1 [ITP]
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
816261: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816261
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for "django-prometheus"

 * Package name: django-prometheus
   Version : 1.0.6-1
   Upstream Author : Uriel Corfa 
 * URL : https://github.com/korfuri/django-prometheus
 * License : Apache
   Section : python

It builds those binary packages:

  python-django-prometheus - Django middlewares to enable monitoring
with Prometheus (Python 2)
  python3-django-prometheus - Django middlewares to enable monitoring
with Prometheus (Python 3)

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/django-prometheus

Alternatively, one can download the package with dget using this command:

  dget -x
http://mentors.debian.net/debian/pool/main/d/django-prometheus/django-prometheus_1.0.6-1.dsc

It is also available on git.debian.org:


https://anonscm.debian.org/cgit/python-modules/packages/django-prometheus.git/

Thanks,

Chris



signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
On Mon, Mar 21, 2016 at 09:39:41AM +, Christopher Baines wrote:
> Thanks for the review, I have now made some changes which should fix the
> above issues.

yes they do :)

> > Then, on github the newest tag is 1.0.5, but you are packaging 1.0.6,
> > which makes me think you are not using github by pypi (checking... not
> > even, the tarballs are different).  Where did you get that tarball?
> 
> I got it from GitHub. I reminded the upstream maintainer to publish a
> tag, and they have now done so.

ok, I see how the content of the files is the same.
But please try to always use the same tarball they release, pristine
maybe.


Uploading :)



-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
--- End Message ---

Bug#816261: RFS: django-prometheus/1.0.6-1

[Christopher Baines]

On 20/03/16 04:26, Mattia Rizzolo wrote:
>> http://mentors.debian.net/debian/pool/main/d/django-prometheus/django-prometheus_1.0.6-1.dsc
>> It is also available on git.debian.org:
>> https://anonscm.debian.org/cgit/python-modules/packages/django-prometheus.git/
> 
> DPMT package → ignoring mentors.d.n, just using the git repository
> 
> * debian/control:
>   + lack of VCS information, this is mandatory in the team.
> * debian/copyright:
>   + please name the license "Apache-2.0"
>   + why normal people don't put license and copyright on
> the header of the files?? :(
> * debian/rules:
>   + you should be able to do that thing with the tests with pybuild
> tooling, like by using (untested)
> PYBUILD_TEST_ARGS="{interpreter} ./test/end2end/manage.py test 
> --verbosity=2"
> note that you may also need to cp the tests or cd to {dir}.
> Please have a look at pybuild(1) and the wiki page
> https://wiki.debian.org/Python/Pybuild for more information
>   + what's that notice about automatically generated file?

Thanks for the review, I have now made some changes which should fix the
above issues.

> Then, on github the newest tag is 1.0.5, but you are packaging 1.0.6,
> which makes me think you are not using github by pypi (checking... not
> even, the tarballs are different).  Where did you get that tarball?

I got it from GitHub. I reminded the upstream maintainer to publish a
tag, and they have now done so.




signature.asc
Description: OpenPGP digital signature

Bug#816004: RFS: [ITP] python-nameparser/0.3.11-1

[Mattia Rizzolo]

On Mon, Mar 21, 2016 at 08:37:06AM +, Edward Betts wrote:
> Edward Betts  wrote:
> > Mattia Rizzolo  wrote:
> > > Edward Betts wrote:
> > > > I will write to the upstream author and attempt to convince them that 
> > > > the
> > > > tests should be included in the pypi tarball.
> > 
> > This is done. I've filed a pull request.
> > 
> > https://github.com/derek73/python-nameparser/pull/46
> 
> Upstream merged my pull request. I will update the package using the next pypi
> release tarball.

oh, so cool!  (also the stuff on the other email wrt the tarballs!)

Just ping when you'd like to upload the release, considering how quickly
upstream cut the last releases I too think he'll do another very soon.

:)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#816004: RFS: [ITP] python-nameparser/0.3.11-1

[Edward Betts]

Edward Betts  wrote:
> Mattia Rizzolo  wrote:
> > Edward Betts wrote:
> > > I will write to the upstream author and attempt to convince them that the
> > > tests should be included in the pypi tarball.
> 
> This is done. I've filed a pull request.
> 
> https://github.com/derek73/python-nameparser/pull/46

Upstream merged my pull request. I will update the package using the next pypi
release tarball.

-- 
Edward.

Bug#816004: RFS: [ITP] python-nameparser/0.3.11-1

[Edward Betts]

Mattia Rizzolo  wrote:
> Edward Betts wrote:
> > I will write to the upstream author and attempt to convince them that the
> > tests should be included in the pypi tarball.

This is done. I've filed a pull request.

https://github.com/derek73/python-nameparser/pull/46

> Given that what I'm mainly complaining here is the presence of all those
> old releases compressed inside dist/* that I can't figure what they are
> for, have you tried asking upstream to just delete them?

Upstream removed these files two days ago, but there hasn't been a release yet.

https://github.com/derek73/python-nameparser/commit/69468b4

I will base my package on the next release, which should be soon. If upstream
accepts my pull requests the tests will be in the pypi tarball and I'll use it. 
-- 
Edward.