Bug#801213: RFS: python-privacyidea/2.7-1 [ITP]

2015-10-26 Thread Daniel Stender
On 26.10.2015 10:47, Cornelius Kölbel wrote:
> Hi Daniel,
> 
> what do you need me to do?
> As the poster of RFS do I need to take action?
> 
> Thanks
> Cornelius
> 
> Am Sonntag, den 25.10.2015, 22:00 +0100 schrieb Daniel Stender:
>> My idea with this would be, close the RFS for now, then file RFP and
>> wishlist-please-update bugs with blocks against the ITP as a todo list.
>>
>> Needs some afforestation, when everything is available privacyidea goes into
>> NEW. Like said, I think I've seen that most of the packages are group 
>> maintained
>> (with Python group in Maintainers field), that's good.
>>
>> Daniel

Yes, I didn't closed it because it's not my bug, that should do the reporter.

I've made a "afforestation" before for Prospector, there were ... I think ... 
more
than ten things outdated or not available. I'm going to help with uploads in 
the groups,
and I would really see Privacyidea in Debian at the year's turn (depends on how 
long
the missing packages are going to be in NEW), for Debian 9 there's nothing 
against it.
I'm on it (owner of the ITP bug)!

Best,
Daniel

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/



Bug#801213: RFS: python-privacyidea/2.7-1 [ITP]

2015-10-26 Thread Cornelius Kölbel
Hi Daniel,

what do you need me to do?
As the poster of RFS do I need to take action?

Thanks
Cornelius


Am Sonntag, den 25.10.2015, 22:00 +0100 schrieb Daniel Stender:
> My idea with this would be, close the RFS for now, then file RFP and
> wishlist-please-update bugs with blocks against the ITP as a todo list.
> 
> Needs some aforestation, when everything is available privacyidea goes into
> NEW. Like said, I think I've seen that most of the packages are group 
> maintained
> (with Python group in Maintainers field), that's good.
> 
> Daniel
> 



signature.asc
Description: This is a digitally signed message part


Bug#801213: RFS: python-privacyidea/2.7-1 [ITP]

2015-10-26 Thread Cornelius Kölbel
close 801213

Am Montag, den 26.10.2015, 11:01 +0100 schrieb Daniel Stender:
> On 26.10.2015 10:47, Cornelius Kölbel wrote:
> > Hi Daniel,
> > 
> > what do you need me to do?
> > As the poster of RFS do I need to take action?
> > 
> > Thanks
> > Cornelius
> > 
> > Am Sonntag, den 25.10.2015, 22:00 +0100 schrieb Daniel Stender:
> >> My idea with this would be, close the RFS for now, then file RFP and
> >> wishlist-please-update bugs with blocks against the ITP as a todo list.
> >>
> >> Needs some afforestation, when everything is available privacyidea goes 
> >> into
> >> NEW. Like said, I think I've seen that most of the packages are group 
> >> maintained
> >> (with Python group in Maintainers field), that's good.
> >>
> >> Daniel
> 
> Yes, I didn't closed it because it's not my bug, that should do the reporter.
> 
> I've made a "afforestation" before for Prospector, there were ... I think ... 
> more
> than ten things outdated or not available. I'm going to help with uploads in 
> the groups,
> and I would really see Privacyidea in Debian at the year's turn (depends on 
> how long
> the missing packages are going to be in NEW), for Debian 9 there's nothing 
> against it.
> I'm on it (owner of the ITP bug)!
> 
> Best,
> Daniel
> 

-- 


signature.asc
Description: This is a digitally signed message part


Bug#801213: RFS: python-privacyidea/2.7-1 [ITP]

2015-10-25 Thread Daniel Stender
My idea with this would be, close the RFS for now, then file RFP and
wishlist-please-update bugs with blocks against the ITP as a todo list.

Needs some aforestation, when everything is available privacyidea goes into
NEW. Like said, I think I've seen that most of the packages are group maintained
(with Python group in Maintainers field), that's good.

Daniel

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/



Bug#801213: RFS: python-privacyidea/2.7-1 [ITP]

2015-10-11 Thread Daniel Stender
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 11.10.2015 10:52, Cornelius Kölbel wrote:
> Hi Daniel,
> 
> thanks a lot for all the valuable feedback.
> 
> I will dive into it later.
> 
> Do you have any further recommendations on finding a sponser (after
> streamlining the package)?
> 
> THanks a lot and kind regards
> Cornelius

Getting it Lintian clean is a major step. That's a rather complicated package, 
and
somebody might wants to discuss issues beyond that like your architecture of 
subpackages.
The flaws must be out of the way for that.

And then, patience ... sponsorship-requests is the right place to seek for a 
sponsor.

Best,
Daniel

- -- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWGi3uAAoJEBXgmvTfUYLIXF4QAJRQbQ3HzZ6As8EhizQMMrLX
tATn1Aj5LhB7S2MHuwO6ytkJVkQUbG/3uvIoTqvCCBpEiYzUSp4eTJFsLSa26Wdz
H+bwkYlQlwj7/TWTqjBZ2b6wMPMw0J8dnhRur39CaNT25lJ0HLG69RLpkKeLOv9V
2r/D/eEoHuVDySqM1uncOXP+HQCTsMptlqr6BVR7sN1DYgf0L9ltpyQkj2eMyBPF
Qg1k15lpBkM5EehS5ri0YnGBqse6qxaUkYrrSuTOeOrTekF3QQjCRbq5CN9caqrc
4NCMcwm6YRVKYDZDWSLuK3ZUfrKh/Djo6gMQNalqWiqv0klDsxbayW8ZGDRJQgdT
rVqe4RKb/tKK8BmaFqR3zopJjc3/toACLlRIl5OlAd3B0c1Q1pnwbBRa5zbS0aEp
wXjHkkzZVInpsYNBwa2wo44cBWz3nx3JcozT9D4A6SqNY3s333oRwlobmmzoWiHy
pirb1QLhDTBHIu1xLqjZmiZ8cyjQhmepxY4pJ2oqOsFXkgMKgmlreJwvdKjY7NHF
jCgxLVZo/lMnPnnJU9F/MP4h6tfRlCkF8goSEo2TMGXp36NjIl+OHUl+jEyUfgGV
RIVuadM0I4HeX9qdKQMJqKoCxgaiVRXZMUiRWmfOGQPM3LKHa8h6tJpM8GvRxCBo
QZmBPl4iP7d+QkHDp33y
=8aR4
-END PGP SIGNATURE-



Bug#801213: RFS: python-privacyidea/2.7-1 [ITP]

2015-10-11 Thread Cornelius Kölbel
Hi Daniel,

thanks a lot for all the valuable feedback.

I will dive into it later.

Do you have any further recommendations on finding a sponser (after
streamlining the package)?

THanks a lot and kind regards
Cornelius

Am Sonntag, den 11.10.2015, 00:18 +0200 schrieb Daniel Stender:
> Hi Cornelius,
> 
> I can't sponsor an upload of your work, but here are the results of my review
> of your package I was doing for my DD application process (I am CCing this 
> email
> to the application manager and the archives for this purpose).
> 
> Here are some collected suggestions for improvement,
> 
> 1) debian/changelog: the target distribution can't be "jessie". Jessie is the 
> current
> stable release, and new packages are not going to be added to that. If 
> there's no
> special reason to want to get uploaded into experimental you are heading for 
> unstable,
> codename "sid". But "unstable" is the suite resp. target name, which is going 
> to be
> used here [a].
> 
>[a] 
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#distribution
> 
> 2) debian/changelog: you have release information in the changelog entry of 
> your
> package, but debian/changelog is reserved for changes of the Debian version of
> the package [a]. For there are no changes on the package yet, "Initial 
> release"
> is all what's happening with this package.
> 
>[a] http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog
> 
> 3) debian/changelog: the ITP bug usually gets closed by the initial upload 
> through
> a "Closes:" in the deb/changelog, which should be added to the "Initial 
> release"
> line [a].
> 
>[a] https://lintian.debian.org/tags/new-package-should-close-itp-bug.html
> 
> 4) debian/watch: uscan scan fails because the watch line is missing the actual
> Perl regex pattern matching the tarball. But direct scanning of Pypi for 
> upstream
> tarballs is deprecated, anyway [a]. The Python team maintains a great Pypi
> redirector, which allows easy installation of a proper watch file [b]:
> $ curl -o debian/watch http://pypi.debian.net/privacyidea/watch
> 
>[a] 
> https://lintian.debian.org/tags/debian-watch-file-unsupported-pypi-url.html
> 
>[b] https://wiki.debian.org/Python/LibraryStyleGuide#debian.2Fwatch
> 
> 5) debian/control: better is to use the current debhelper (>= 9~), that also 
> needs
> a bump of the compat level to "9" in debian/compat [a].
> 
>[a] 
> https://lintian.debian.org/tags/package-uses-old-debhelper-compat-version.html
> 
> 6) debian/control: the "X-Python-Version" element doesn't belong in the 
> binary package
> section, but above into the source package section [a]
> 
>[a] 
> https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions
> 
> 7) debian/control: though not mandatory nor recommended by the policy [a], if 
> the
> "Homepage:" field is present in the source package section, it's easy to 
> browse to
> it from the package tracker page.
> 
>[a] https://www.debian.org/doc/debian-policy/ch-controlfields.html
> 
> 8) debian/control: the build-dependency against python-setuptools is 
> redundant, and
> the versioning against >= 0.6b3 is obsolete, even oldstable has 0.6.24.
> 
> 9) debian/rules: since the tarball ships a testsuite, the tests should be run 
> during
> build time (for the package has a lot of dependencies, it would be great if 
> also a
> DEP-8 compatible test setup for Debian CI could be installed, even if you are 
> upstream
> [a,b]).
> 
>[a] 
> http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD
> 
>[b] 
> http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/debci_and_the_Debian_Continuous_Integration_project.webm
> 
> 10) debian/control: there are some errors in the package descriptions like 
> that
> "python" isn't capitalized, "authenticaion" etc. (please recheck and see the 
> related
> Lintian complaints). The description text looks like it's just a copy of the 
> program's
> documentation, and copyright statements should not be included here [a].
>
>[a] https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions
> 
> 11) debian/control: you've got Breaks and Replaces against a package 
> "privacyidea",
> but which isn't in the archive. I would guess that's a non-official package 
> around
> somewhere? I'm not sure if a use like that could be discussed, but another 
> use (maybe
> you mean the upstream version) would be unwanted, definitely [a].
> 
>[a] https://www.debian.org/doc/debian-policy/ch-relationships.html
> 
> 12) debian/rules: "python_distutils" is usually put by py2dsc/stdeb as 
> buildsystem
> but you might want to use "pybuild" (that's commonly used for new packages). 
> That
> also needs a build-dep on "dh-python" in debian/control (that's recommended 
> anyway
> when you run the dh sequencer "--with python2", see the complaint in the 
> 

Bug#801213: RFS: python-privacyidea/2.7-1 [ITP]

2015-10-11 Thread Alex Vong
Hi Cornelius,

I recommend reading
 if you
haven't. The guide mentions suggestions 1), 2) and 3) mentioned by
Daniel and more.

Cheers,
Alex

On 11/10/2015, Cornelius Kölbel 
wrote:
> Hi Daniel,
>
> thanks a lot for all the valuable feedback.
>
> I will dive into it later.
>
> Do you have any further recommendations on finding a sponser (after
> streamlining the package)?
>
> THanks a lot and kind regards
> Cornelius
>
> Am Sonntag, den 11.10.2015, 00:18 +0200 schrieb Daniel Stender:
>> Hi Cornelius,
>>
>> I can't sponsor an upload of your work, but here are the
results of my
>> review
>> of your package I was doing for my DD application process (I am
 CCing this
>> email
>> to the application manager and the archives for this purpose).
>>
>> Here are some collected suggestions for improvement,
>>
>> 1) debian/changelog: the target distribution can't be "jessie".
 Jessie is
>> the current
>> stable release, and new packages are not going to be added to
that. If
>> there's no
>> special reason to want to get uploaded into experimental you
are heading
>> for unstable,
>> codename "sid". But "unstable" is the suite resp. target name,
which is
>> going to be
>> used here [a].
>>
>>[a]
>>
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#distribution
>>

>> 2) debian/changelog: you have release information in the
changelog entry
>> of your
>> package, but debian/changelog is reserved for changes of the
Debian
>> version of
>> the package [a]. For there are no changes on the package yet,
"Initial
>> release"
>> is all what's happening with this package.
>>
>>[a]
>>
http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog
>>
>> 3) debian/changelog: the ITP bug usually gets closed by the
initial upload
>> through
>> a "Closes:" in the deb/changelog, which should be added to the
"Initial
>> release"
>> line [a].
>>
>>[a]
>>
https://lintian.debian.org/tags/new-package-should-close-itp-bug.html
>>
>> 4) debian/watch: uscan scan fails because the watch line is
missing the
>> actual
>> Perl regex pattern matching the tarball. But direct scanning of
 Pypi for
>> upstream
>> tarballs is deprecated, anyway [a]. The Python team maintains a
 great
>> Pypi
>> redirector, which allows easy installation of a proper watch
file [b]:
>> $ curl -o debian/watch http://pypi.debian.net/privacyidea/watch
>>
>>[a]
>>
https://lintian.debian.org/tags/debian-watch-file-unsupported-pypi-url.html
>>

>>[b]
https://wiki.debian.org/Python/LibraryStyleGuide#debian.2Fwatch
>>
>> 5) debian/control: better is to use the current debhelper
(>= 9~), that
>> also needs
>> a bump of the compat level to "9" in debian/compat [a].
>>
>>[a]
>>
https://lintian.debian.org/tags/package-uses-old-debhelper-compat-version.html
>>

>> 6) debian/control: the "X-Python-Version" element doesn't
belong in the
>> binary package
>> section, but above into the source package section [a]
>>
>>[a]
>>
https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions
>>

>> 7) debian/control: though not mandatory nor recommended by the
policy [a],
>> if the
>> "Homepage:" field is present in the source package section,
it's easy to
>> browse to
>> it from the package tracker page.
>>
>>[a]
https://www.debian.org/doc/debian-policy/ch-controlfields.html
>>
>> 8) debian/control: the build-dependency against
python-setuptools is
>> redundant, and
>> the versioning against >= 0.6b3 is obsolete, even oldstable
has 0.6.24.
>>
>> 9) debian/rules: since the tarball ships a testsuite, the tests
 should be
>> run during
>> build time (for the package has a lot of dependencies, it would
 be great
>> if also a
>> DEP-8 compatible test setup for Debian CI could be installed,
even if you
>> are upstream
>> [a,b]).
>>
>>[a]
>>
http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD
>>

>>[b]
>>
http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/debci_and_the_Debian_Continuous_Integration_project.webm
>>

>> 10) debian/control: there are some errors in the package
descriptions like
>> that
>> "python" isn't capitalized, "authenticaion" etc. (please
recheck and see
>> the related
>> Lintian complaints). The description text looks like it's just a
 copy of
>> the program's
>> documentation, and copyright statements should not be included
here [a].
>>
>>[a]
>>
https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions
>>
>> 11) debian/control: you've got Breaks and Replaces against a
package
>> "privacyidea",
>> but which isn't in the archive. I would guess that's a
non-official
>> package around
>> somewhere? I'm not sure if a use like that could be discussed,
but another
>> use (maybe
>> you mean the upstream version) would be unwanted, definitely
[a].
>>
>>[a]

Bug#801213: RFS: python-privacyidea/2.7-1 [ITP]

2015-10-10 Thread Daniel Stender
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Cornelius,

I can't sponsor an upload of your work, but here are the results of my review
of your package I was doing for my DD application process (I am CCing this email
to the application manager and the archives for this purpose).

Here are some collected suggestions for improvement,

1) debian/changelog: the target distribution can't be "jessie". Jessie is the 
current
stable release, and new packages are not going to be added to that. If there's 
no
special reason to want to get uploaded into experimental you are heading for 
unstable,
codename "sid". But "unstable" is the suite resp. target name, which is going 
to be
used here [a].

   [a] 
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#distribution

2) debian/changelog: you have release information in the changelog entry of your
package, but debian/changelog is reserved for changes of the Debian version of
the package [a]. For there are no changes on the package yet, "Initial release"
is all what's happening with this package.

   [a] http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog

3) debian/changelog: the ITP bug usually gets closed by the initial upload 
through
a "Closes:" in the deb/changelog, which should be added to the "Initial release"
line [a].

   [a] https://lintian.debian.org/tags/new-package-should-close-itp-bug.html

4) debian/watch: uscan scan fails because the watch line is missing the actual
Perl regex pattern matching the tarball. But direct scanning of Pypi for 
upstream
tarballs is deprecated, anyway [a]. The Python team maintains a great Pypi
redirector, which allows easy installation of a proper watch file [b]:
$ curl -o debian/watch http://pypi.debian.net/privacyidea/watch

   [a] 
https://lintian.debian.org/tags/debian-watch-file-unsupported-pypi-url.html

   [b] https://wiki.debian.org/Python/LibraryStyleGuide#debian.2Fwatch

5) debian/control: better is to use the current debhelper (>= 9~), that also 
needs
a bump of the compat level to "9" in debian/compat [a].

   [a] 
https://lintian.debian.org/tags/package-uses-old-debhelper-compat-version.html

6) debian/control: the "X-Python-Version" element doesn't belong in the binary 
package
section, but above into the source package section [a]

   [a] 
https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-specifying_versions

7) debian/control: though not mandatory nor recommended by the policy [a], if 
the
"Homepage:" field is present in the source package section, it's easy to browse 
to
it from the package tracker page.

   [a] https://www.debian.org/doc/debian-policy/ch-controlfields.html

8) debian/control: the build-dependency against python-setuptools is redundant, 
and
the versioning against >= 0.6b3 is obsolete, even oldstable has 0.6.24.

9) debian/rules: since the tarball ships a testsuite, the tests should be run 
during
build time (for the package has a lot of dependencies, it would be great if 
also a
DEP-8 compatible test setup for Debian CI could be installed, even if you are 
upstream
[a,b]).

   [a] 
http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD

   [b] 
http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/debci_and_the_Debian_Continuous_Integration_project.webm

10) debian/control: there are some errors in the package descriptions like that
"python" isn't capitalized, "authenticaion" etc. (please recheck and see the 
related
Lintian complaints). The description text looks like it's just a copy of the 
program's
documentation, and copyright statements should not be included here [a].
   
   [a] https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions

11) debian/control: you've got Breaks and Replaces against a package 
"privacyidea",
but which isn't in the archive. I would guess that's a non-official package 
around
somewhere? I'm not sure if a use like that could be discussed, but another use 
(maybe
you mean the upstream version) would be unwanted, definitely [a].

   [a] https://www.debian.org/doc/debian-policy/ch-relationships.html

12) debian/rules: "python_distutils" is usually put by py2dsc/stdeb as 
buildsystem
but you might want to use "pybuild" (that's commonly used for new packages). 
That
also needs a build-dep on "dh-python" in debian/control (that's recommended 
anyway
when you run the dh sequencer "--with python2", see the complaint in the build 
log).

13) in python-privacyidea and privacyidea-pam, you have a five executable 
scripts in
/usr/bin without manpages. There is a "should have" in the policy on this issue 
[a],
but missing manpages are considered being a bug. And if missing manpages adds 
to a couple
of other issues like that (like sub standard descriptions) the chance of being 
rejected
by the FTP team rises [b].

   [a] https://www.debian.org/doc/debian-policy/ch-docs.html#s12.1

   [b] 

Bug#801213: RFS: python-privacyidea/2.7-1 [ITP]

2015-10-08 Thread Daniel Stender
I'm going to review this. Please expect the results, soon.

Best,
Daniel Stender

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/