-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Scott Kitterman wrote:
> I just created a Debian package for pyspf 2.0.1. It is here:
>
> http://www.kitterman.com/spf/deb/
Thanks a lot for your effort!
> I'd appreciate comments. There is an open upload window in Ubuntu right
> now that I'd like to take advantage of.
>
> Please be gentle, this is my first Debian package....
I'll let lintian do the harsh criticism and just comment a bit myself. ;-)
| $ lintian -i pyspf_2.0.1-1_i386.changes
| W: pyspf source: changelog-should-mention-nmu
| N:
| N: When you NMU a package, that fact should be mentioned on the first
| N: line in the changelog entry.
| N:
| N: Maybe you didn't intend this upload to be a NMU, in that case,
please
| N: doublecheck that the most recent entry in the changelog is
| N: byte-for-byte identical to the maintainer or one of the uploaders.
| N:
| W: pyspf source: source-nmu-has-incorrect-version-number 2.0.1-1
| N:
| N: A source NMU should have a Debian revision of '-x.x'. This is to
| N: prevent stealing version numbers from the maintainer (and the -x.x.x
| N: version numbers are reserved for binary-only NMU's).
| N:
| N: Maybe you didn't intend this upload to be a NMU, in that case,
please
| N: doublecheck that the most recent entry in the changelog is
| N: byte-for-byte identical to the maintainer or one of the uploaders.
| N:
Since this package is not part of the Debian or Ubunto distributions (yet),
I'd just use the package version number "2.0.1" instead of "2.0.1-1" (the
"-1" part would be the Debian/Ubuntu package revision). (For instance, I
am distributing the debian/ sub-dir in the Mail::SPF upstream package, so
DEBs can be built by users without having to rely on the latest package
being included in their OS distro. In that case, a Debian/Ubuntu revision
isn't appropriate because it would eventually conflict with a distro
package.)
However, if your package is inteded as an update to the package currently
in Debian, then "2.0.1-1" is OK.
Your package is considered an NMU by lintian because the uploader in the
latest debian/changelog entry
Scott Kitterman <scott@kitterman.com>
differs from the package maintainer in debian/control:
Gustavo Franco <stratus@debian.org>
Given that Gustavo hasn't given up maintainership of the package, it would
probably be best if you changed the package version number to "2.0.1-0.1"
(the "-0.1" Debian revision indicating an NMU).
| E: pyspf source: build-depends-indep-should-be-build-depends python |
python-dev | python-all-dev
| N:
| N: The specified package is required to run the clean target of
| N: debian/rules and therefore must be listed in Build-Depends, even if
no
| N: architecture-dependent packages are built.
| N:
| N: Refer to Policy Manual, section 7.6 for details.
| N:
| E: pyspf source: missing-build-dependency python-support (>= 0.3)
| N:
| N: The package doesn't specify a build dependency on a package that is
| N: used in debian/rules.
| N:
| N: Refer to Policy Manual, section 4.2 for details.
| N:
Essentially what the error descriptions say. Ask if you don't understand
what they want you to do.
| W: python-spf: binary-without-manpage spfquery.py
| N:
| N: Each binary in /usr/bin, /usr/sbin, /bin, /sbin or /usr/games should
| N: have a manual page
| N:
| N: Note, that though the `man' program has the capability to check for
| N: several program names in the NAMES section, each of these programs
| N: should have its own manual page (a symbolic link to the appropriate
| N: manual page is sufficient) because other manual page viewers such as
| N: xman or tkman don't support this.
| N:
| N: Refer to Policy Manual, section 12.1 for details.
| N:
| W: python-spf: binary-without-manpage type99.py
These are just warnings, so if you don't have the time to create man-pages,
then ignore them.
| W: python-spf: script-with-language-extension usr/bin/type99.py
| N:
| N: When scripts are installed into a directory in the system PATH, the
| N: script name should not include an extension such as .sh or .pl that
| N: denotes the scripting language currently used to implement it. The
| N: implementation language may change; if it does, leaving the name the
| N: same would be confusing and changing it would be disruptive.
| N:
| N: Refer to Policy Manual, section 10.4 for details.
| N:
| W: python-spf: script-with-language-extension usr/bin/spfquery.py
Right. Don't install programs with language-specific extensions into the
(s)bin dirs. Even if you do that upstream, make your debian/rules rename
those files during package creation.
| E: python-spf: python-script-but-no-python-dep ./usr/bin/type99.py
| N:
| N: Packages with scripts that are executed with python must depend on
the
| N: package python. Those that have scripts executed with a versioned
| N: python package need a dependency on the equivalent version of
python.
| N:
| N: For example, if a script in the package uses #!/usr/bin/python, then
| N: the package needs a dependency on "python". If a script uses
| N: #!/usr/bin/python2.2, then the package need a dependency on
| N: "python2.2".
| N:
| N: In some cases a weaker relationship, such as Suggests or Recommends,
| N: will be more appropriate.
| N:
| E: python-spf: python-script-but-no-python-dep ./usr/bin/spfquery.py
| W: python-spf:
script-not-executable ./usr/share/python-support/python-spf/spf.py
| N:
| N: This file starts with the #! sequence that marks interpreted
scripts,
| N: but it is not executable.
| N:
Essentially what the error descriptions say. Ask if you don't understand
what they want you to do.
When you make another revision, I'll review it manually.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFiS/gwL7PKlBZWjsRAnxWAKC/kPxmAWENyHwtXm4PxayDS/rr3gCfd4Wh
2siks4RV/eHCqAPRM/IXP7U=
=Z90w
-----END PGP SIGNATURE-----
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to
http://v2.listbox.com/member/?list_id=1007
