Bug#801490: marked as done (RFS: knopflerfish-osgi/5.1.0+dfsg1-3)

[Debian Bug Tracking System]

Your message dated Mon, 12 Oct 2015 04:29:52 +
with message-id 
and subject line closing RFS: knopflerfish-osgi/5.1.0+dfsg1-3
has caused the Debian Bug report #801490,
regarding RFS: knopflerfish-osgi/5.1.0+dfsg1-3
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.)


-- 
801490: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801490
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: sponsorship-requests
Severity: normal

Dear mentors/debian-java,

I am looking for a sponsor for my package "knopflerfish-osgi"

* Package name: knopflerfish-osgi
  Version : 5.1.0+dfsg1-3
  Upstream Author : Makewave 
* URL : http://www.knopflerfish.org/
* License : BSD-3-clause
  Section : java

I just moved it from asm3 to asm5 (see #800860). It has been tested
locally with an r-dep and with pbuilder on sid.

It builds those binary packages:

libknopflerfish-osgi-framework-java - Java framework implementing the OSGi R5 
version
libknopflerfish-osgi-java-doc - Java framework implementing the OSGi R5 version 
(docs)

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

http://mentors.debian.net/package/knopflerfish-osgi

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

  dget -x 
http://mentors.debian.net/debian/pool/main/k/knopflerfish-osgi/knopflerfish-osgi_5.1.0+dfsg1-3.dsc

More information about knopflerfish can be obtained from 
http://www.knopflerfish.org/.

Changes since the last upload:

knopflerfish-osgi (5.1.0+dfsg1-3) unstable; urgency=medium

  * Move to libasm4-java (Closes: #800860)

Thanks and Best Regards,
-- 
Felix Natter
--- End Message ---
--- Begin Message ---
Package knopflerfish-osgi version 5.1.0+dfsg1-3 is in unstable now.
https://packages.qa.debian.org/knopflerfish-osgi--- End Message ---

Bug#792144: RFS: cunit/2.1-2.dfsg-3 -- Unit Testing Library for C [ITA]

[Azat Khuzhin]

On Thu, Oct 01, 2015 at 02:17:29PM +, Gianfranco Costamagna wrote:
> Hi Azat,
> 
> 
> 
> >No problem, replaced version in d/changelog and d/NEWS to
> >"2.1-3+dfsg-1".
> 
> 
> wonderful
> >Done using d/copyright, thanks.
> 
> 
> this is not really correct.
> 
> I see you remove Makefiles in copyright, but why?
> 
> that files-excluded needs to be used for non dfsg files, not for 
> autogenerated stuff that
> should be regenerated anyway.
> (if you want to be sure you regenerate the Makefiles you can clean them on 
> clean target)
> 
> cat debian/README.Debian |grep dsp
> Due to license issues all *.dsp files have been removed from the source 
> package.
> 
> 
> 
> find . -name "*.dsp"
> ./Examples/WinTest/WinTest.dsp
> ./Examples/ConsoleTest/ConsoleTest.dsp
> ./Examples/BasicTest/BasicTest.dsp
> ./Examples/AutomatedTest/AutomatedTest.dsp
> ./CUnit/CUnit.dsp
> 
> 
> so I guess *this* is what you need to remove :)

Oops, sorry about that, fixed and uploaded to mentors.
Thanks!

Re: dev-pkg-without-shlib-symlink lintian warning for libtool library using -release & -version-info

[Sebastiaan Couwenberg]

On 11-10-15 22:22, Jakub Wilk wrote:
> * Sebastiaan Couwenberg , 2015-10-08, 21:01:
>> To deal with the external usage of liblwgeom built from the postgis
>> sources, the upstream developers now use the -release libtool option
>> along with -version-info to better support installation of multiple
>> postgis versions.
>>
>> The -release option was added to support the multiple version use case
>> on Windows, for the Debian package the shared library approach with
>> -version-info is sufficient.
> 
> https://autotools.io/libtool/version.html suggests that instead of
> combining -release and -version-info, one should encode the version in
> the library's name.

Yeah, that my suggestion to upstream too [0], but they thought of it as
a feature that you can still link with -llwgeom [1].

>> Lintian currently warns about the missing symlinks from
>> liblwgeom-2.2.so to liblwgeom-2.2.so.2.2.0, because libtool only
>> creates the liblwgeom.so (and liblwgeom-2.2.so.2) symlink.
> 
> The code to determine name of the dev symlink name looks like this:
> 
> $link_file =~ s/-[\d\.]+\.so$/.so/o;
> $link_file =~ s/\.so.+$/.so/o;
> 
> So it doesn't seem to support the combination of -release and
> -version-info.

Thanks for this confirmation, I hadn't dug into the lintian source.

>> Am I correct in my assumption that this is a false positive?
> 
> Probably (sort of) yes...

Should we recommend upstream to follow the advice from Autotools Mythbuster?

I'm unable to suggest a good solution to the concerns raised by the
Windows maintainer of PostGIS, which is the reason for the current
compromise combining -release & -version-info. The Autotools Mythbuster
says:

"
 The first reaction would be to combine the two options, -release and
 -version-info; this would, though, be wrong. When using -release the
 static archive, the one with .a extension, the libtool archive (see
 Section 5, “Libtool Archives”) and the .so file used by the link
 editor would not have a revision appended, which means that two
 different version of the library can't be installed at the same time.
"

While this is true on Linux at least, I don't think is true for Windows.

PostGIS 2.2.0 final was shipped a bit too quickly, so there's going to
be an ABI break in 2.2.1, which seems a good opportunity to further
change the SONAME and library version handling.

[0] https://lists.osgeo.org/pipermail/postgis-devel/2015-October/025274.html
[1] https://lists.osgeo.org/pipermail/postgis-devel/2015-October/025279.html

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#799205: RFS: eviacam/2.0.1-5 [ITP] -- webcam based mouse emulator

[Cesar Mauri]

Hi,

Thanks both for your feedback.


First, if I try to build using debuild, I get the error
`dh_autoreconf: autoreconf -f -i returned exit code 1'. I think it is
because dh_autoreconf is running "naked" `autoreconf' instead of
`autogen.sh'. So I think the fix is to add the following entry into
debian/rule:

override dh_autoreconf:
dh_autoreconf ./autogen.sh
Running debuild after unpacking the tarball and the debian/ directory 
works for me. Not sure how to reproduce this issue.




Besides, if I try to re-build I get `dpkg-source: error:
unrepresentable changes to source'. Now I don't really know how to fix
since I don't know how translation works. Maybe Gianfranco could help?

I'm not sure which is the "correct" fix, but I presume the po files should be 
updated
"prior" to release the tarball, and not during the debian build (where the po 
should just
be compiled)

My fault. I forgot to run "make update-po" before generating the tarball.

Fixed and added a check to avoid forgetting about this in future.



I see some *.gmo files created and not deleted during clean, this should be 
fixed upstream or
with a simple
find po -name "*.gmo" -delete
in the dh_clean target
and also the "po/stamp-po" should be cleaned during clean,
and this seems to be an upstream issue too.
Currently, the tarball does not contain .gmo files, nor the 
"po/stamp-po". Anyway, the override_dh_clean now looks like this:


override_dh_clean:
debconf-updatepo
dh_clean
find po -name "*.gmo" -delete
-rm po/stamp-po



and please change
cd po; make update-po; cd ..


to "$(MAKE) -C po update-po"

but I'm pretty sure this is already done automatically.

So I would even drop the override_dh_auto_build targetw

Dropped and working properly :-)


Updated version available in mentors and sf.


Regards, Cesar

Re: dev-pkg-without-shlib-symlink lintian warning for libtool library using -release & -version-info

[Jakub Wilk]

* Sebastiaan Couwenberg , 2015-10-08, 21:01:
To deal with the external usage of liblwgeom built from the postgis 
sources, the upstream developers now use the -release libtool option 
along with -version-info to better support installation of multiple 
postgis versions.


The -release option was added to support the multiple version use case 
on Windows, for the Debian package the shared library approach with 
-version-info is sufficient.


https://autotools.io/libtool/version.html suggests that instead of 
combining -release and -version-info, one should encode the version in 
the library's name.


Lintian currently warns about the missing symlinks from 
liblwgeom-2.2.so to liblwgeom-2.2.so.2.2.0, because libtool only 
creates the liblwgeom.so (and liblwgeom-2.2.so.2) symlink.


The code to determine name of the dev symlink name looks like this:

$link_file =~ s/-[\d\.]+\.so$/.so/o;
$link_file =~ s/\.so.+$/.so/o;

So it doesn't seem to support the combination of -release and 
-version-info.



Am I correct in my assumption that this is a false positive?


Probably (sort of) yes...

--
Jakub Wilk

Bug#790104: Fwd: Bug#790104: RFS: lightdm-gtk-greeter-settings/1.2.0-1 [ITP]

[James Lu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
(This was supposed to go to the maintainers for lightdm-gtk-greeter in
Debian, not the upstream list; sorry for the noise.)

Hi everyone,

Recently I've been trying to get lightdm-gtk-greeter-settings into
Debian, since it's a nifty utility! Right now, my packaging work has an
RFS (request for sponsorship) bug at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790104. If there's
anyone interested in reviewing, the source is at mentors.d.n
 and Git
at
https://anonscm.debian.org/cgit/collab-maint/lightdm-gtk-greeter-settings.git.

Best,
James
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQIcBAEBCAAGBQJWGptZAAoJEC7D9g3nHAudT14P/2zF0ZoiOJQPqCO/o54qrGU6
ph4bQxdbWNtA7uGk3QMad0yNh6TXYapKAodTVaEGDsevDSvqVYsT9FC6bEi0fI5/
EcY89ImAg11/Zx1Mcj0UouF6hbURrDFp5K9xB+31vOET5sZoXJnfQQLaoNLwB804
QCPA6L7fsaYhfnqcf4NVE+PcILbJ1dH1/AtufFccvPii2tIAi/5eFA5/NdhsnZue
04y6G1LBTiPLHk2Eetrm4PWMZo21GbhmxouLPYKEiUL20gTR6lvh/fp8qLbTKuxu
9gIeZ/1qy64+/SHf8Fxf/xtsXXQ3K5ZeTx1V3Aw57SSdE2MnPK3P2lwl0LW8G387
Ywq6d3M8Nj8+GCEvM+aKOXb2is3VU1zT67823cUjtWosaLx19k+q0wEJCoXJFuL6
cbCsgFWUBn5kuvB9xVuJzxroGSX8HJz0BEbt4t9BJKEr7RjA9ZP6T6vfy1E+owo5
NX0bsWcD3EiunPbZumcOGPapym++JdA/1N8ddBva4+yGMqJdx4KXk5d77j425XAC
H0NslF2zU3mVZoWVnavivWZpJsGMg/Yl6NcgDF3OhKyRH3BvLFv/IVAGahrOd5Kz
wZzOol9yW97T5RpkwnjERgF/SqBmnMTdAuCD4PRV42ySxBuCHMJo4Y4BAF5O92bD
tsaGLpVbqTDOxNH0qyvO
=ys49
-END PGP SIGNATURE-

Bug#790104: RFS: lightdm-gtk-greeter-settings/1.2.0-1 [ITP]

[James Lu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
 
On 11/10/2015 2:37 AM, Christian Kastner wrote:
> On 2015-10-11 07:54, James Lu wrote:
>>> d/copyright:
>>>  - The license appears to be GPL-3, not GPL-3+ (at least in the handful
>>>of files I checked). This also requires correction of the free-
>>>standing license block (the last paragraph)
>>
>> I see. Ubuntu's packaging wrote the license as GPL-3+ for both the
>> packaging and the source, but I guess the license of the individual
>> files must prevail here. Fixed.
>
> Hm, I just realized that I overlooked something here, namely the license
> of the packaging that came from Ubuntu :-/
>
> that makes things a bit more complicated, because:
> * It is clear that upstream wanted GPL-3 for the upstream source
> * It is clear that Ubuntu's packager wanted GPL-3+ for the
> packaging, even if this motive was inspired by the erroneous
> assumption of the GPL-3+ for the upstream source (asking the
> packager directly might resolve that)
>
> IOW, my initial advice was wrong. You need to keep GPL-3+ for the
> packaging, and add GPL-3 for the upstream source.
>
> Sorry about the mixup!

That's what I did here (forgot to mention it more clearly). The upstream
source (*) is set to GPL-3 and the Ubuntu packaging + my changes (the
debian/ folder) is GPL-3+.

>
>>>  - There's a formatting issue in the free-standing license text (line
>>>27 is not indented)
>>
>> I'm not sure what this means. Is it supposed to be indented to the width
>> of "X-Comment: "? That's what I did.
>
> Oh, I see what you meant to do now -- it wasn't lacking indentation, it
> was beginning a new field.
>
> However, in that case, the field's name is just "Comment" [1], without
> the "X-" prefix.
>
> [1]
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#stand-alone-license-paragraph
>
> Regards,
> Christian
>
Done. I'll fix the other email too.

Best,
James
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
 
iQIcBAEBCAAGBQJWGpomAAoJEC7D9g3nHAudhHgQAKHfBGL6+thgDlU6egJVxFu8
PjGRHafdRRyyupFkxbLlTU3u4BIzPn68Mcl9+dqlUVOMiDI0YCnzBAqnH22mRAt8
VbUxt/SAwzFKb0eZOsIQcYNXkaxhkrXudqs0sPi6+HyJ++oXQLKZBfMpp+l/ndnP
r5einjxeSEKkK2uXwOoh+O4lUgubhS3cUGnIfhufaN1btl5MvBybwgOCM1q5OQ87
fn1DvqvlaAbkjvMkp7BAjDdAwMpASgcHnPW97FomO3JbdCrXzYSk0n85alLtv7xa
mEF6F7woKtwwzmj6FYTXk7F8lqV0ccMktbiTUsb0lzyGRJWeryAH9U2sptLAizm5
G46lNHLFrmnTWZ7cjHuJ/kbFRIKbJhpXSUV+oCivCfVrxnOHY1qnt2Mqb8f339Dc
Z/sXLaWqW1KSxGi3uhtGtL7F5a4xy/ME+6u7EoIAwC/KoBgbRxaNIbb8RCXx7s/S
hdvnnBAhM9hQl6hqeoR28uxy/a0BDDNAA/K+NtrjdJrmHDM/kAIkthqIhgSfUbF3
HeH20EyCEmd8yMKhXL/AllmdkWm8hZFwVUB2FdXvJqYtCsSdGJvCVpqe/6/gtVLb
U54fr8gueBSS5pDCrbIbgYwN8YePENlckxe6PVe0xPCBkWQoSnTNisszf3Zbn1gI
TUKysudqNq8OrP1riYoo
=C+Q6
-END PGP SIGNATURE-

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

[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]
https://www.debian.org/doc/debian-policy/ch-relationships.html

Bug#790104: RFS: lightdm-gtk-greeter-settings/1.2.0-1 [ITP]

[Christian Kastner]

On 2015-10-11 07:54, James Lu wrote:
>> d/copyright:
>>  - The license appears to be GPL-3, not GPL-3+ (at least in the handful
>>of files I checked). This also requires correction of the free-
>>standing license block (the last paragraph)
> 
> I see. Ubuntu's packaging wrote the license as GPL-3+ for both the
> packaging and the source, but I guess the license of the individual
> files must prevail here. Fixed.

Hm, I just realized that I overlooked something here, namely the license
of the packaging that came from Ubuntu :-/

that makes things a bit more complicated, because:
* It is clear that upstream wanted GPL-3 for the upstream source
* It is clear that Ubuntu's packager wanted GPL-3+ for the
packaging, even if this motive was inspired by the erroneous
assumption of the GPL-3+ for the upstream source (asking the
packager directly might resolve that)

IOW, my initial advice was wrong. You need to keep GPL-3+ for the
packaging, and add GPL-3 for the upstream source.

Sorry about the mixup!

>>  - There's a formatting issue in the free-standing license text (line
>>27 is not indented)
> 
> I'm not sure what this means. Is it supposed to be indented to the width
> of "X-Comment: "? That's what I did.

Oh, I see what you meant to do now -- it wasn't lacking indentation, it
was beginning a new field.

However, in that case, the field's name is just "Comment" [1], without
the "X-" prefix.

[1] 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#stand-alone-license-paragraph

Regards,
Christian




signature.asc
Description: OpenPGP digital signature

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

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

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

Bug#801490: RFS: knopflerfish-osgi/5.1.0+dfsg1-3

[Felix Natter]

Package: sponsorship-requests
Severity: normal

Dear mentors/debian-java,

I am looking for a sponsor for my package "knopflerfish-osgi"

* Package name: knopflerfish-osgi
  Version : 5.1.0+dfsg1-3
  Upstream Author : Makewave 
* URL : http://www.knopflerfish.org/
* License : BSD-3-clause
  Section : java

I just moved it from asm3 to asm5 (see #800860). It has been tested
locally with an r-dep and with pbuilder on sid.

It builds those binary packages:

libknopflerfish-osgi-framework-java - Java framework implementing the OSGi R5 
version
libknopflerfish-osgi-java-doc - Java framework implementing the OSGi R5 version 
(docs)

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

http://mentors.debian.net/package/knopflerfish-osgi

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

  dget -x 
http://mentors.debian.net/debian/pool/main/k/knopflerfish-osgi/knopflerfish-osgi_5.1.0+dfsg1-3.dsc

More information about knopflerfish can be obtained from 
http://www.knopflerfish.org/.

Changes since the last upload:

knopflerfish-osgi (5.1.0+dfsg1-3) unstable; urgency=medium

  * Move to libasm4-java (Closes: #800860)

Thanks and Best Regards,
-- 
Felix Natter