Mailing List Archive: SPF: Devel

Debian Package for pyspf 2.0.1 - Please Review

Index | Next | Previous | View Threaded

scott at kitterman

Dec 18, 2006, 10:24 PM

Post #1 of 10 (1380 views)
Permalink

Debian Package for pyspf 2.0.1 - Please Review

I just created a Debian package for pyspf 2.0.1. It is here:

http://www.kitterman.com/spf/deb/

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....

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

julian at mehnle

Dec 20, 2006, 4:43 AM

Post #2 of 10 (1315 views)
Permalink

Re: Debian Package for pyspf 2.0.1 - Please Review [In reply to]

-----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[at]kitterman.com>

differs from the package maintainer in debian/control:

Gustavo Franco <stratus[at]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

scott at kitterman

Dec 20, 2006, 7:51 AM

Post #3 of 10 (1329 views)
Permalink

Re: Re: Debian Package for pyspf 2.0.1 - Please Review [In reply to]

On Wednesday 20 December 2006 07:43, Julian Mehnle wrote:
> 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. ;-)

OK. I'm down to just warnings from lintian. Not sure if any of them are
important...

W: python-spf: binary-without-manpage spfquery.py
W: python-spf: binary-without-manpage type99.py
W: python-spf: script-with-language-extension usr/bin/type99.py
W: python-spf: script-with-language-extension usr/bin/spfquery.py
W: python-spf: script-not-executable
./usr/share/python-support/python-spf/spf.py
W: python-spf: executable-not-elf-or-script ./usr/bin/spfquery.py
W: python-spf: executable-not-elf-or-script ./usr/bin/type99.py

Please look again and then give me your update-alternatives patch.

Thanks,

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

julian at mehnle

Dec 22, 2006, 2:26 PM

Post #4 of 10 (1333 views)
Permalink

Re: Debian Package for pyspf 2.0.1 - Please Review [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Kitterman wrote:
> OK. I'm down to just warnings from lintian. Not sure if any of them
> are important...

With the package files I just grabbed from your HTTP directory, I'm getting
those:

| N: size is 561, argname is pyspf_2.0.1-0.1_i386.changes, filename is /home/julian/tmp/pyspf_2.0.1-0.1.dsc
| E: pyspf_2.0.1-0.1_i386.changes: file-size-mismatch-in-changes-file pyspf_2.0.1-0.1.dsc
| N:
| N: The actual file size does not match what's listed in the .changes
| N: file.
| N:
| E: pyspf_2.0.1-0.1_i386.changes: md5sum-mismatch-in-changes-file pyspf_2.0.1-0.1.dsc
| N:
| N: The actual md5sum checksum does not match what's listed in the
| N: .changes file.
| N:

I don't get where those come from. Did you do something weird with the
files (especially the .dsc file) after building the package?

| E: pyspf source: missing-build-dependency python-support (>= 0.3)

It seems that "Build-Depends: python-support" isn't sufficient and that at
least version 0.3 is required.

BTW, is there a reason why you build-depend on debhelper >= 5.0.37.1
specifically as opposed to just >= 5?

And is it really necessary to build-depend on python-all-dev? According to
that package's description, "the package currently depends on
python2.4-dev, in the future, dependencies on jython (Python for a JVM) and
ironpython (Python for Mono) may be added". Given that jython and
ironpython would probably depend on some JVM and Mono themselves,
respectively, that seems to be overkill to me.

| W: python-spf: binary-without-manpage spfquery.py
| W: python-spf: binary-without-manpage type99.py

You can ignore those.

| W: python-spf: script-with-language-extension usr/bin/type99.py
| W: python-spf: script-with-language-extension usr/bin/spfquery.py

Those are definitely important. Don't do that. Rename the programs in
debian/rules so as to remove their language-specific extensions.

| W: python-spf: script-not-executable ./usr/share/python-support/python-spf/spf.py

That one may be ignored, however if spf.py is supposed to be used as an
executable, then it should have the "x" bits set.

| W: python-spf: executable-not-elf-or-script ./usr/bin/spfquery.py
| W: python-spf: executable-not-elf-or-script ./usr/bin/type99.py

These executables should have "#!/usr/bin/python" shebang lines (perhaps
with a specific python version).

> Please look again and then give me your update-alternatives patch.

Will do after the next iteration. :-)

A few more things. When I build the package, I get the following warnings
several times:

| /usr/share/cdbs/1/class/python-distutils.mk:60: Use of XS-Python-Version
| and XB-Python-Version fields in 'debian/control' is deprecated with
| pysupport method, use 'debian/pyversions' if you need to specify
| specific versions

and:

| /usr/lib/python2.4/distutils/dist.py:236: UserWarning: Unknown
| distribution option: 'install_dir'

I also get:

| [...]
| dh_python: Doing nothing since dh_pycompat exists; dh_pysupport or
| dh_pycentral should do the work. You can remove dh_python from your
| rules file.
| [...]
| dpkg-genchanges: warning: unknown information field `Xb-Python-Version'
| in input data in package's section of control info file
| [...]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFjFuNwL7PKlBZWjsRAlKxAJ4k+293FfmTPh6FhTsvu6O9J4SNkACgghN7
fLJSU5CgU+MjQrWW4Frp0/o=
=znYy
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

scott at kitterman

Dec 22, 2006, 6:59 PM

Post #5 of 10 (1329 views)
Permalink

Re: Re: Debian Package for pyspf 2.0.1 - Please Review [In reply to]

On Friday 22 December 2006 17:26, Julian Mehnle wrote:
> Scott Kitterman wrote:
> > OK. I'm down to just warnings from lintian. Not sure if any of them
> > are important...
>
> With the package files I just grabbed from your HTTP directory, I'm getting
>
> those:
> | N: size is 561, argname is pyspf_2.0.1-0.1_i386.changes, filename is
> | /home/julian/tmp/pyspf_2.0.1-0.1.dsc E: pyspf_2.0.1-0.1_i386.changes:
> | file-size-mismatch-in-changes-file pyspf_2.0.1-0.1.dsc N:
> | N: The actual file size does not match what's listed in the .changes
> | N: file.
> | N:
> | E: pyspf_2.0.1-0.1_i386.changes: md5sum-mismatch-in-changes-file
> | pyspf_2.0.1-0.1.dsc N:
> | N: The actual md5sum checksum does not match what's listed in the
> | N: .changes file.
> | N:
>
> I don't get where those come from. Did you do something weird with the
> files (especially the .dsc file) after building the package?

No, just copied them to the web server using SFTP. Weird. Maybe the revised
version I just posted will be better...

> | E: pyspf source: missing-build-dependency python-support (>= 0.3)
>
> It seems that "Build-Depends: python-support" isn't sufficient and that at
> least version 0.3 is required.

Fixed.

> BTW, is there a reason why you build-depend on debhelper >= 5.0.37.1
> specifically as opposed to just >= 5?

That's what was in the Debian package for pyspf 1.6 that I started with.

> And is it really necessary to build-depend on python-all-dev? According to
> that package's description, "the package currently depends on
> python2.4-dev, in the future, dependencies on jython (Python for a JVM) and
> ironpython (Python for Mono) may be added". Given that jython and
> ironpython would probably depend on some JVM and Mono themselves,
> respectively, that seems to be overkill to me.

Agreed and fixed.

> | W: python-spf: binary-without-manpage spfquery.py
> | W: python-spf: binary-without-manpage type99.py
>
> You can ignore those.

Ignored.

> | W: python-spf: script-with-language-extension usr/bin/type99.py
> | W: python-spf: script-with-language-extension usr/bin/spfquery.py
>
> Those are definitely important. Don't do that. Rename the programs in
> debian/rules so as to remove their language-specific extensions.

I will work on figuring out how to do that next.

> | W: python-spf: script-not-executable
> | ./usr/share/python-support/python-spf/spf.py
>
> That one may be ignored, however if spf.py is supposed to be used as an
> executable, then it should have the "x" bits set.

That one is strange as it does have the X bits set AFAICT.

> | W: python-spf: executable-not-elf-or-script ./usr/bin/spfquery.py
> | W: python-spf: executable-not-elf-or-script ./usr/bin/type99.py
>
> These executables should have "#!/usr/bin/python" shebang lines (perhaps
> with a specific python version).

Fixed.

> > Please look again and then give me your update-alternatives patch.
>
> Will do after the next iteration. :-)
>
> A few more things. When I build the package, I get the following warnings
>
> several times:
> | /usr/share/cdbs/1/class/python-distutils.mk:60: Use of XS-Python-Version
> | and XB-Python-Version fields in 'debian/control' is deprecated with
> | pysupport method, use 'debian/pyversions' if you need to specify
> | specific versions

As I understand it from the Ubuntu people (who may not always agree with
Debian) that is still OK. Dunno for sure.

> and:
> | /usr/lib/python2.4/distutils/dist.py:236: UserWarning: Unknown
> | distribution option: 'install_dir'

Removed. It is aparrently a Redhat thing. I'll remove it upstream before the
next release.

> I also get:
> | [...]
> | dh_python: Doing nothing since dh_pycompat exists; dh_pysupport or
> | dh_pycentral should do the work. You can remove dh_python from your
> | rules file.
> | [...]

Not sure what I can do about that, since dh_python isn't in the control file.

> | dpkg-genchanges: warning: unknown information field `Xb-Python-Version'
> | in input data in package's section of control info file
> | [...]

I found a reference that those were by design ignored by Dpkg and are OK.

Update uploaded. Except for renaming the two scripts, I think it's in
reasonably good shape.

http://www.kitterman.com/spf/deb/

I was working with Ubuntu too and they've accepted the package for their April
release:

https://launchpad.net/distros/ubuntu/+source/pyspf/2.0.1-0ubuntu1

I'd like to continue to work with you to refine the package. For the next
week or so my online time will be very limited due to the holidays.

Thanks again for all the help.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

julian at mehnle

Dec 23, 2006, 7:45 AM

Post #6 of 10 (1329 views)
Permalink

Re: Debian Package for pyspf 2.0.1 - Please Review [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Kitterman wrote:
> On Friday 22 December 2006 17:26, Julian Mehnle wrote:
> > With the package files I just grabbed from your HTTP directory, I'm
> > getting those:
> >
> > | N: size is 561, argname is pyspf_2.0.1-0.1_i386.changes, filename is /home/julian/tmp/pyspf_2.0.1-0.1.dsc
> > | E: pyspf_2.0.1-0.1_i386.changes: file-size-mismatch-in-changes-file pyspf_2.0.1-0.1.dsc
> > | N:
> > | N: The actual file size does not match what's listed in the .changes
> > | N: file.
> > | N:
> > | E: pyspf_2.0.1-0.1_i386.changes: md5sum-mismatch-in-changes-file pyspf_2.0.1-0.1.dsc
> > | N:
> > | N: The actual md5sum checksum does not match what's listed in the
> > | N: .changes file.
> > | N:
> >
> > I don't get where those come from. Did you do something weird with
> > the files (especially the .dsc file) after building the package?
>
> No, just copied them to the web server using SFTP. Weird. Maybe the
> revised version I just posted will be better...

I still got those errors. However, as soon as I rebuild the package myself
from the extracted source, the errors disappear (as would be expected).
Let's ignore them for now.

> > And is it really necessary to build-depend on python-all-dev?
> > According to that package's description, "the package currently
> > depends on python2.4-dev, in the future, dependencies on jython
> > (Python for a JVM) and ironpython (Python for Mono) may be added".
> > Given that jython and ironpython would probably depend on some JVM and
> > Mono themselves, respectively, that seems to be overkill to me.
>
> Agreed and fixed.

Hmm. I stumbled across <http://wiki.debian.org/DebianPython/NewPolicy>,
which says that a builddep on "python-all-dev (>= 2.3.5-11)" is required.
I put it back in with my patch (see below). Let's just hope python-all-dev
won't depend on some JVM and Mono one day...

> > | W: python-spf: script-with-language-extension usr/bin/type99.py
> > | W: python-spf: script-with-language-extension usr/bin/spfquery.py
> >
> > Those are definitely important. Don't do that. Rename the programs
> > in debian/rules so as to remove their language-specific extensions.
>
> I will work on figuring out how to do that next.

Since this directly intersects with what needs to be done for update-
alternatives support anyway, this is taken care of by my patch.

> > | W: python-spf: script-not-executable ./usr/share/python-support/python-spf/spf.py
> >
> > That one may be ignored, however if spf.py is supposed to be used as
> > an executable, then it should have the "x" bits set.
>
> That one is strange as it does have the X bits set AFAICT.

I still don't get why exactly the executable bits get reset, but I think it
has something to do with cdbs/debhelper/python-support and the fact that
"spf.py" is treated as a Python module (with regard to the path it gets
installed in) and not as an executable.

I think the cleanest solution would be to just remove its shebang line in
debian/rules and create a `pyspf` executable stub script in /usr/bin (that
just calls the spf.py module) for those applications and users on Debian
that do need the upstream `spf.py` executable behavior.

> > > Please look again and then give me your update-alternatives patch.

I'm attaching it. Besides the update-alternatives support and the things I
already mentioned above, it adds

| Conflicts: spfquery, libmail-spf-query-perl (<< 1:1.999.1-3)

to debian/control because those packages install their own `spfquery`
executables (without u-a support!) and thus cannot live next to any u-a-
enabled `spfquery` suppliers.

> > A few more things. When I build the package, I get the following
> > warnings several times:
> > [...]
>
> As I understand it from the Ubuntu people (who may not always agree with
> Debian) that is still OK. Dunno for sure.

OK. Let's ignore it.

> > I also get:
> > | [...]
> > | dh_python: Doing nothing since dh_pycompat exists; dh_pysupport or
> > | dh_pycentral should do the work. You can remove dh_python from
> > | your rules file.
> > | [...]
>
> Not sure what I can do about that, since dh_python isn't in the control
> file.

OK. Let's ignore it.

> Update uploaded. Except for renaming the two scripts, I think it's in
> reasonably good shape.
>
> http://www.kitterman.com/spf/deb/
>
> I was working with Ubuntu too and they've accepted the package for their
> April release:
>
> https://launchpad.net/distros/ubuntu/+source/pyspf/2.0.1-0ubuntu1

Can they accept the refined package with u-a support, too? :-)

As far as I can see, now really just the "W: python-spf: script-not-
executable ./usr/share/python-support/python-spf/spf.py" (`spf.py`/`pyspf`
wrapper executable) issue remains.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFjU8NwL7PKlBZWjsRAkqAAJ4mSK5gtwu9RB/UtZxcns2fzmoM5wCgvy18
8RG2R049bB5QvA7xsncz8uc=
=OGyE
-----END PGP SIGNATURE-----

Attachments:

pyspf-2.0.1-spfquery-update-alternatives.patch (2.87 KB)

scott at kitterman

Dec 23, 2006, 8:14 AM

Post #7 of 10 (1337 views)
Permalink

Re: Re: Debian Package for pyspf 2.0.1 - Please Review [In reply to]

On Saturday 23 December 2006 10:45, Julian Mehnle wrote:
> Scott Kitterman wrote:
> > On Friday 22 December 2006 17:26, Julian Mehnle wrote:
> > > With the package files I just grabbed from your HTTP directory, I'm
> > >
> > > getting those:
> > > | N: size is 561, argname is pyspf_2.0.1-0.1_i386.changes, filename is
> > > | /home/julian/tmp/pyspf_2.0.1-0.1.dsc E: pyspf_2.0.1-0.1_i386.changes:
> > > | file-size-mismatch-in-changes-file pyspf_2.0.1-0.1.dsc N:
> > > | N: The actual file size does not match what's listed in the
> > > | .changes N: file.
> > > | N:
> > > | E: pyspf_2.0.1-0.1_i386.changes: md5sum-mismatch-in-changes-file
> > > | pyspf_2.0.1-0.1.dsc N:
> > > | N: The actual md5sum checksum does not match what's listed in the
> > > | N: .changes file.
> > > | N:
> > >
> > > I don't get where those come from. Did you do something weird with
> > > the files (especially the .dsc file) after building the package?
> >
> > No, just copied them to the web server using SFTP. Weird. Maybe the
> > revised version I just posted will be better...
>
> I still got those errors. However, as soon as I rebuild the package myself
> from the extracted source, the errors disappear (as would be expected).
> Let's ignore them for now.

Weird. I'm open so suggestions on solving this.

> > > And is it really necessary to build-depend on python-all-dev?
> > > According to that package's description, "the package currently
> > > depends on python2.4-dev, in the future, dependencies on jython
> > > (Python for a JVM) and ironpython (Python for Mono) may be added".
> > > Given that jython and ironpython would probably depend on some JVM and
> > > Mono themselves, respectively, that seems to be overkill to me.
> >
> > Agreed and fixed.
>
> Hmm. I stumbled across <http://wiki.debian.org/DebianPython/NewPolicy>,
> which says that a builddep on "python-all-dev (>= 2.3.5-11)" is required.
> I put it back in with my patch (see below). Let's just hope python-all-dev
> won't depend on some JVM and Mono one day...

The feedback I got from Ubuntu was that since I don't actually bytecode
compile the modules when I install them, I didn't need to depend on
python-all-dev. I think it would be better to go ahead and compile them.
Next step would be for me to figure out how to do that. In any case python
is included in the python-all-dev metapackage so we don't need both.

> > > | W: python-spf: script-with-language-extension usr/bin/type99.py
> > > | W: python-spf: script-with-language-extension usr/bin/spfquery.py
> > >
> > > Those are definitely important. Don't do that. Rename the programs
> > > in debian/rules so as to remove their language-specific extensions.
> >
> > I will work on figuring out how to do that next.
>
> Since this directly intersects with what needs to be done for update-
> alternatives support anyway, this is taken care of by my patch.

Thanks.

> > > | W: python-spf: script-not-executable
> > > | ./usr/share/python-support/python-spf/spf.py
> > >
> > > That one may be ignored, however if spf.py is supposed to be used as
> > > an executable, then it should have the "x" bits set.
> >
> > That one is strange as it does have the X bits set AFAICT.
>
> I still don't get why exactly the executable bits get reset, but I think it
> has something to do with cdbs/debhelper/python-support and the fact that
> "spf.py" is treated as a Python module (with regard to the path it gets
> installed in) and not as an executable.
>
> I think the cleanest solution would be to just remove its shebang line in
> debian/rules and create a `pyspf` executable stub script in /usr/bin (that
> just calls the spf.py module) for those applications and users on Debian
> that do need the upstream `spf.py` executable behavior.

That makes sense.

> > > > Please look again and then give me your update-alternatives patch.
>
> I'm attaching it. Besides the update-alternatives support and the things I
> already mentioned above, it adds
>
> | Conflicts: spfquery, libmail-spf-query-perl (<< 1:1.999.1-3)
>
> to debian/control because those packages install their own `spfquery`
> executables (without u-a support!) and thus cannot live next to any u-a-
> enabled `spfquery` suppliers.

I looked at it and it all makes sense.

> > > A few more things. When I build the package, I get the following
> > > warnings several times:
> > > [...]
> >
> > As I understand it from the Ubuntu people (who may not always agree with
> > Debian) that is still OK. Dunno for sure.
>
> OK. Let's ignore it.
>
> > > I also get:
> > > | [...]
> > > | dh_python: Doing nothing since dh_pycompat exists; dh_pysupport or
> > > | dh_pycentral should do the work. You can remove dh_python from
> > > | your rules file.
> > > | [...]
> >
> > Not sure what I can do about that, since dh_python isn't in the control
> > file.
>
> OK. Let's ignore it.
>
> > Update uploaded. Except for renaming the two scripts, I think it's in
> > reasonably good shape.
> >
> > http://www.kitterman.com/spf/deb/
> >
> > I was working with Ubuntu too and they've accepted the package for their
> > April release:
> >
> > https://launchpad.net/distros/ubuntu/+source/pyspf/2.0.1-0ubuntu1
>
> Can they accept the refined package with u-a support, too? :-)

They should be able to. The reason I went ahead and submitted it is that they
had what they call a "REVU sprint" this week where a lot of their senior
people were focused on getting new packages reviewed and uploaded.

They are still taking new packages for their next release, but I probably
can't get it done nearly as quickly because we've passed the immediate window
where they are focused on this.

> As far as I can see, now really just the "W: python-spf: script-not-
> executable ./usr/share/python-support/python-spf/spf.py" (`spf.py`/`pyspf`
> wrapper executable) issue remains.

Stuart committed some changes to the pyspf2.0 branch and I committed the
changes I had needed to make when packaging it to the branch. Perhaps the
thing to do is work on this over the next couple of weeks and then fold your
packaging inprovements in with an upstream update for 2.0.2.

Thanks again for all the help on this.

You might want to consider submitting Mail::SPF to Ubuntu. I have the
impression they are rather more open to outside submission than Debian. They
also synch stuff back up to Debian unstable periodically too.

The basic process is here:

https://wiki.ubuntu.com/MOTU/Packages/REVU

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

julian at mehnle

Dec 23, 2006, 8:41 AM

Post #8 of 10 (1330 views)
Permalink

Re: Debian Package for pyspf 2.0.1 - Please Review [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Kitterman wrote:
> On Saturday 23 December 2006 10:45, Julian Mehnle wrote:

> The feedback I got from Ubuntu was that since I don't actually bytecode
> compile the modules when I install them, I didn't need to depend on
> python-all-dev. I think it would be better to go ahead and compile
> them. Next step would be for me to figure out how to do that. In any
> case python is included in the python-all-dev metapackage so we don't
> need both.

Understood. IANADPE (I am not a Debian Python expert). :-)

> > I think the cleanest solution would be to just remove [spf.py's]
> > shebang line in debian/rules and create a `pyspf` executable stub
> > script in /usr/bin (that just calls the spf.py module) for those
> > applications and users on Debian that do need the upstream `spf.py`
> > executable behavior.
>
> That makes sense.
>
> [...]
>
> > As far as I can see, now really just the "W: python-spf: script-not-
> > executable ./usr/share/python-support/python-spf/spf.py"
> > (`spf.py`/`pyspf` wrapper executable) issue remains.
>
> Stuart committed some changes to the pyspf2.0 branch and I committed the
> changes I had needed to make when packaging it to the branch. Perhaps
> the thing to do is work on this over the next couple of weeks and then
> fold your packaging inprovements in with an upstream update for 2.0.2.

OK. Out of pure interest, are you planning on distributing the "debian/"
dir in your upstream package?

> Thanks again for all the help on this.

You're welcome.

> You might want to consider submitting Mail::SPF to Ubuntu. I have the
> impression they are rather more open to outside submission than Debian.
> They also synch stuff back up to Debian unstable periodically too.
>
> The basic process is here:
> https://wiki.ubuntu.com/MOTU/Packages/REVU

I'm not an Ubuntu user currently and I have LOTS of other important stuff
to do at the moment (such as getting Mail::SPF into Debian), so this isn't
a priority for me right now. I might look into it next year.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFjVxNwL7PKlBZWjsRAgFBAJ9l7uLrakfLHZAmFTOVEkbgVMC2jwCfaXbf
27+Caq8CimCHoKuUUupIrks=
=xTZ4
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

scott at kitterman

Dec 23, 2006, 8:52 AM

Post #9 of 10 (1332 views)
Permalink

Re: Re: Debian Package for pyspf 2.0.1 - Please Review [In reply to]

On Saturday 23 December 2006 11:41, Julian Mehnle wrote:
> Scott Kitterman wrote:

> OK. Out of pure interest, are you planning on distributing the "debian/"
> dir in your upstream package?

I'm not sure about that one. Right now I've got two versions because there
are things that Debian and Ubuntu would want to be different. They are minor
AFAIK (distribution name and Ubuntu doesn't want NMU in the changelog), but
as long as I'm pursuing two paths for this, I'm not sure it makes sense.

I'm open to suggestions.

> > Thanks again for all the help on this.
>
> You're welcome.
>
> > You might want to consider submitting Mail::SPF to Ubuntu. I have the
> > impression they are rather more open to outside submission than Debian.
> > They also synch stuff back up to Debian unstable periodically too.
> >
> > The basic process is here:
> > https://wiki.ubuntu.com/MOTU/Packages/REVU
>
> I'm not an Ubuntu user currently and I have LOTS of other important stuff
> to do at the moment (such as getting Mail::SPF into Debian), so this isn't
> a priority for me right now. I might look into it next year.

Do you mind if I submit it?

Are you comfortable with the current state of the package for submission?

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

julian at mehnle

Dec 23, 2006, 9:06 AM

Post #10 of 10 (1330 views)
Permalink

Re: Debian Package for pyspf 2.0.1 - Please Review [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Kitterman wrote:
> On Saturday 23 December 2006 11:41, Julian Mehnle wrote:
> > Out of pure interest, are you planning on distributing the "debian/"
> > dir in your upstream package?
>
> I'm not sure about that one. Right now I've got two versions because
> there are things that Debian and Ubuntu would want to be different.

True, however there will always be diffs from the upstream source in Debian
or Ubuntu, and I don't see any reasons why those diffs couldn't contain
differences in the debian/* files.

> They are minor AFAIK (distribution name and Ubuntu doesn't want NMU in
> the changelog), but as long as I'm pursuing two paths for this, I'm not
> sure it makes sense.

I have been including the debian/ dir in all my Perl CPAN packages for
years. Some have been packaged for Debian, and it hasn't caused problems
so far, even though the debian/* files in the official Debian source
packages usually are slightly different.

I think supplying my own debian/ dirs is valuable because that way I can
convey useful information on how I think the modules should be packaged
(e.g. separate "libmail-spf-perl" and "spf-tools-perl" packages for
Mail::SPF, containing the plain Mail::SPF Perl modules and the spfquery/
spfd tools, respectively).

> > > You might want to consider submitting Mail::SPF to Ubuntu. [...]
> >
> > I'm not an Ubuntu user currently and I have LOTS of other important
> > stuff to do at the moment (such as getting Mail::SPF into Debian), so
> > this isn't a priority for me right now. [...]
>
> Do you mind if I submit it?
>
> Are you comfortable with the current state of the package for
> submission?

No, I don't mind at all. Mail::SPF 2.002 is solid.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFjWH8wL7PKlBZWjsRAltnAKCu/tJhrT28NH5V6VSwJyMogdqfBwCbBbMW
nplCNJSe//a3MHGvqAgHBQs=
=a2Dc
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com