Re: RFS: plastex
On 7/20/07, Bernd Zeimetz <bernd@bzed.de> wrote:
> lintian spits out warnings about -x flag on the py-files, as they all
> has a shebang, also the setup.py generates a cgpdfpng that only will
> work under OSX, but I don't know a good way to fix that.
patch the source?
For example by using dpatch. There're examples for that in every second
python package in http://svn.debian.org/wsvn/python-modules/packages
If it creates something that doesn't work - it should be fixed, or
removed if you don't need it. It makes no sense to ship broken software.
A few more comments:
- you could create the manpage while building the package, that would
make sure you don't forget to update it accidentally.
The manpage is created at build time, by using xsltproc
- * Removed the CVS directories - that's not neede din the first
changelog entry. If you change the upstream's source, explain it in
README.Debian-source and provide a way to repackage the upstream
tarball. If it doesn't make sense to repackage an upstream tarball for
that, overriding the lintian warnings for the source is an idea.
how do you mean by "provide a way to repackage the upstream tarball"?
- debian/copyright is missing the license. Add the full license test,
also 'Python License' could be non-free, as licenses before version 2
were non-free.
I know, I emailed the upstream author, and just got this reply:
"You're right. I basically put that in as a placeholder and never got
back to it. I'll try to fix this in the next couple of days and put
out a new release. I'll notify you when this is finished."
- I'm not sure what you need the stuff in debian/mk for - although I
have to admit that I don't know what's the really proper way to create
manpages using cdbs, but there're far more simple ways (if anybody knows
how cdbs handles manpages - please point me to it, otherwise have a look
into ll-xist in the svn mentioned up there, the way I'm using there at
least works well) Also remember that you files probably won't work with
cdbs anymore at one time - you should not add stuff to cdbs at build
time imho.
It was mostly temporarly, I posted a wishlist bug report to cdbs about
adding that. perhaps remove the po4a thingi that followed with the
original source
- as far as I've seen on the first look there's no architecture
dependent stuff in your package, so it should be Architecture: all in
debian/control
Thought about that, but I still don't know how to handle the
executable that is created that will only work under OSX.
This was a 2 minutes review on the fly, and I'm not a DD so I can't
sponsor you. But I hope that my hints are helpful for you.
Probably you want to join the python modules team and maintain your
package in the svn? join #debian-python on OFTC if you need any help.
Best regards,
Bernd
--
Bernd Zeimetz
<bernd@bzed.de> <http://bzed.de/>
Thanks.
/Carl
On 7/20/07, Bernd Zeimetz <bernd@bzed.de> wrote:
> lintian spits out warnings about -x flag on the py-files, as they all
> has a shebang, also the setup.py generates a cgpdfpng that only will
> work under OSX, but I don't know a good way to fix that.
patch the source?
For example by using dpatch. There're examples for that in every second
python package in http://svn.debian.org/wsvn/python-modules/packages
If it creates something that doesn't work - it should be fixed, or
removed if you don't need it. It makes no sense to ship broken software.
A few more comments:
- you could create the manpage while building the package, that would
make sure you don't forget to update it accidentally.
The manpage is created at build time, by using xsltproc
- * Removed the CVS directories - that's not neede din the first
changelog entry. If you change the upstream's source, explain it in
README.Debian-source and provide a way to repackage the upstream
tarball. If it doesn't make sense to repackage an upstream tarball for
that, overriding the lintian warnings for the source is an idea.
how do you mean by "provide a way to repackage the upstream tarball"?
- debian/copyright is missing the license. Add the full license test,
also 'Python License' could be non-free, as licenses before version 2
were non-free.
I know, I emailed the upstream author, and just got this reply:
"You're right. I basically put that in as a placeholder and never got
back to it. I'll try to fix this in the next couple of days and put
out a new release. I'll notify you when this is finished."
- I'm not sure what you need the stuff in debian/mk for - although I
have to admit that I don't know what's the really proper way to create
manpages using cdbs, but there're far more simple ways (if anybody knows
how cdbs handles manpages - please point me to it, otherwise have a look
into ll-xist in the svn mentioned up there, the way I'm using there at
least works well) Also remember that you files probably won't work with
cdbs anymore at one time - you should not add stuff to cdbs at build
time imho.
It was mostly temporarly, I posted a wishlist bug report to cdbs about
adding that. perhaps remove the po4a thingi that followed with the
original source
- as far as I've seen on the first look there's no architecture
dependent stuff in your package, so it should be Architecture: all in
debian/control
Thought about that, but I still don't know how to handle the
executable that is created that will only work under OSX.
This was a 2 minutes review on the fly, and I'm not a DD so I can't
sponsor you. But I hope that my hints are helpful for you.
Probably you want to join the python modules team and maintain your
package in the svn? join #debian-python on OFTC if you need any help.
Best regards,
Bernd
--
Bernd Zeimetz
<bernd@bzed.de> <http://bzed.de/>
Thanks.
/Carl
Reply to: