[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#816169: RFS: fake-factory/0.5.3-1



On 19/03/16 14:11, Mattia Rizzolo wrote:
>>   dget -x
>> http://mentors.debian.net/debian/pool/main/f/fake-factory/fake-factory_0.5.3-1.dsc
>>
>> It is also available on git.debian.org:
>>
>>   https://anonscm.debian.org/cgit/python-modules/packages/fake-factory.git/
> 
> being in DPMT and given that by team policy the git repo should reflect
> what's packaged, I'm going to ignore what's on mentors.d.n.
> 
> * debian/changelog:
>   + bump the date, Dec 2015 is really too old
> * debian/control:
>   + bump Standards-Version
>   + u.U this is in DPMT, git is *mandatory*, how could you miss Vcs-Git
>     and Vcs-Browser here?

I began packaging this before my application to join the team was
approved, and when this happened and I pushed the package to the
repository, I forgot to add the related metadata in to the control file.

>   + I: fake-factory source: duplicate-long-description python-fake-factory python3-fake-factory
>   + I: python-fake-factory: extended-description-is-probably-too-short
>   + I: python3-fake-factory: extended-description-is-probably-too-short
> * debian/copyright:
>   + the 'License: Expat' paragraph contains a copyright statment, please
>     remove it, after this is a *license* paragraph, not copyright.
>   + I can clearly see that you did work in 2016, so please also claim
>     copyright over 2016 too.
> * debian/gbp.conf:
>   + how so there is this file?  DPMT mandates git-dpm, and the content
>     of this file is worrisome

It just allowed me to use gbp to build the package (as this is what I
find convenient). As it happens, fixing the tagging also removed the
need for this file.

> * debian/.git-dpm:
>   + you haven't initialized it to follow the DPMT rules, so the tag you
>     created are in the wrong format.  See
>     https://wiki.debian.org/Python/GitPackaging#Tag_style then delete
>     those tags.
>     - more: there is tag "patched-0.5.3-1", but that one is done once
>       the package is ready, togheter with the debian/* one, so don't
>       create/push that tag after you'll remove it.
> 
> 
> Now, something maybe more difficult:
> as lintian notices:
> X: python-fake-factory: library-package-name-for-application usr/bin/faker2
> X: python-fake-factory: application-in-library-section python usr/bin/faker2
> X: python3-fake-factory: library-package-name-for-application usr/bin/faker3
> X: python3-fake-factory: application-in-library-section python usr/bin/faker3
> 
> you are installing something in PATH.  ok.
> I see this was done by upstream, but providing /usr/bin/faker{2,3} where
> the only difference is the python version used is very confusing.
> Nowdays the better way to fix that is to ship only one binary, using the
> python3 library, in a separate package (maybe named "faker")

Ah, cool :)

> Another thing: please build the manpage at build time, by calling
> help2man directly there.

Thanks for your review. I have now fixed most of the issues you have
highlighted. The manpage still needs a bit of work, the help output
contains some long lines, and I think this is causing a lintian warning
(but I'm not sure how to fix this?).

The other issue that has arisen since making this sponsorship request,
is that the upstream maintainers have announced that the project is
changing name in September (fake-factory -> faker). This is good, but it
means that the Debian source package and binary packages should also
make this change. I am not sure of the process around changing source
package name, but I guess the two options would be to upload, change
name upload in September, or just wait until September before uploading
this package?


Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: