Re: RFS: plastex
to remove unneeded shebang lines, I usually use a small perl script
called at the end of debian/rules. I find this much more flexible than
maintaining a set of patches.
Or sed -i -re '1{/^#!/d}'
You have to maintain a list of files you want to apply this to anyway
(some files should probably get a chown instead), so maintaining this as
a patch is not too hard, also you can just take the patch and send it to
upstream, most of them are willing to apply such patches.
Cheers,
Bernd
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plastex
have uploaded a new package now, where I have been trying to get all the licenses correct. Hope they work fine. /Carl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plastex
On Fri, Jul 20, 2007 at 03:36:56PM +0200, François Févotte wrote:
Hello,
On 7/20/07, Carl Fürstenberg [EMAIL PROTECTED] 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.
to remove unneeded shebang lines, I usually use a small perl script
called at the end of debian/rules. I find this much more flexible than
maintaining a set of patches.
Or sed -i -re '1{/^#!/d}'
I note that sed -n -i is a dangerous combination..
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plastex
On 7/24/07, Justin Pryzby [EMAIL PROTECTED] wrote:
Or sed -i -re '1{/^#!/d}'
I note that sed -n -i is a dangerous combination..
How do you handle clean target then?
/Carl
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plastex
On Tue, Jul 24, 2007 at 11:01:06PM +0200, Carl Fürstenberg wrote:
On 7/24/07, Justin Pryzby [EMAIL PROTECTED] wrote:
Or sed -i -re '1{/^#!/d}'
I note that sed -n -i is a dangerous combination..
How do you handle clean target then?
Do you mean how can you reverse the change to satisfy the policy
requirement that the sources, after clean, are indistinguishable from
the sources before? Well, you can simply run the sed on only the
./debian/$package/{,usr/}{,s}bin/* since the whole installation
tree[s] are removed anyway. I think any build-time munging of scripts
consistent with strict interpretation of this section of the policy
will have to act on ./debian/$package/ only or do something much less
elegant.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plastex
Hello,
On 7/20/07, Carl Fürstenberg [EMAIL PROTECTED] 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.
to remove unneeded shebang lines, I usually use a small perl script
called at the end of debian/rules. I find this much more flexible than
maintaining a set of patches.
For example, this is the line I add in the debian/rules file:
perl debian/strip_shebang $(DESTDIR)/usr/share/exaile/plugins/*.py
and the perl script: debian/strip_shebang
#! /usr/bin/perl
use strict;
while (my $file = shift)
{
print STDERR Stripping shebang from file: `$file'\n;
my $tmpfile = $file.'.tmp';
system ('cp', $file, $tmpfile);
open IN, $tmpfile
or die (could not open file `$tmpfile': $!\n);
open OUT, $file
or die (could not open file `$file': $!\n);
# Only copy the first line if it is not a shebang line
$_ = IN;
print OUT unless (/^\#!/);
# Copy all other lines
while (IN)
{
print OUT;
}
close IN;
close OUT;
system ('rm', $tmpfile);
}
I'm sure this is not perfect and there is much room for improvement,
but still it seems to work pretty well.
Cheers,
François
PS: I am not a DD, so I can not sponsor your package. I hope you'll
find a sponsor very soon, though.
Re: RFS: plastex
How common is this? i.e. would it be time to implement something like
dh_pystrip debhelper thingi?
/Carl
On 7/20/07, François Févotte [EMAIL PROTECTED] wrote:
Hello,
On 7/20/07, Carl Fürstenberg [EMAIL PROTECTED] 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.
to remove unneeded shebang lines, I usually use a small perl script
called at the end of debian/rules. I find this much more flexible than
maintaining a set of patches.
For example, this is the line I add in the debian/rules file:
perl debian/strip_shebang $(DESTDIR)/usr/share/exaile/plugins/*.py
and the perl script: debian/strip_shebang
#! /usr/bin/perl
use strict;
while (my $file = shift)
{
print STDERR Stripping shebang from file: `$file'\n;
my $tmpfile = $file.'.tmp';
system ('cp', $file, $tmpfile);
open IN, $tmpfile
or die (could not open file `$tmpfile': $!\n);
open OUT, $file
or die (could not open file `$file': $!\n);
# Only copy the first line if it is not a shebang line
$_ = IN;
print OUT unless (/^\#!/);
# Copy all other lines
while (IN)
{
print OUT;
}
close IN;
close OUT;
system ('rm', $tmpfile);
}
I'm sure this is not perfect and there is much room for improvement,
but still it seems to work pretty well.
Cheers,
François
PS: I am not a DD, so I can not sponsor your package. I hope you'll
find a sponsor very soon, though.
Re: RFS: plastex
Carl Fürstenberg wrote: How common is this? i.e. would it be time to implement something like dh_pystrip debhelper thingi? imho you want to send a bugreport to upstream instead. Cheers, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plastex
On 7/20/07, Bernd Zeimetz [EMAIL PROTECTED] wrote: how do you mean by provide a way to repackage the upstream tarball? http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz I would need some help interpret that. 1. must contain detailed information how the repackaged source was obtained, and how this can be reproduced in the debian/copyright. It is also a good idea to provide a get-orig-source target in your debian/rules file that repeats the process, as described in the Policy Manual, Main building script: debian/rules. should the .orig.tar.gz include a file for that? and ehat should it be called and how should it look like? 2. should not contain any file that does not come from the upstream author(s), or whose contents has been changed by you. so I should/must use dpatch for the shebang fix? 4. should use packagename-upstream-version.orig as the name of the top-level directory in its tarball. This makes it possible to distinguish pristine tarballs from repackaged ones. orig? as it's modified from the upstream, it's not in my vocabulary original. /Carl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plastex
Carl Fürstenberg wrote: On 7/20/07, Bernd Zeimetz [EMAIL PROTECTED] wrote: how do you mean by provide a way to repackage the upstream tarball? http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz I would need some help interpret that. 1. must contain detailed information how the repackaged source was obtained, and how this can be reproduced in the debian/copyright. It is also a good idea to provide a get-orig-source target in your debian/rules file that repeats the process, as described in the Policy Manual, Main building script: debian/rules. should the .orig.tar.gz include a file for that? and ehat should it be called and how should it look like? no, not in the tar.gz. provide a get-orig-source target in debian/rules. debian/rules is not in the tar.gz. 2. should not contain any file that does not come from the upstream author(s), or whose contents has been changed by you. so I should/must use dpatch for the shebang fix? yes. or quilt. 4. should use packagename-upstream-version.orig as the name of the top-level directory in its tarball. This makes it possible to distinguish pristine tarballs from repackaged ones. orig? as it's modified from the upstream, it's not in my vocabulary original. add it to your vocabulary then, or propose a change in the policy. Probably reading the New Maintainer's reference and the other documents linked on http://www.debian.org/doc/devel-manuals#maint-guide could be useful for you. Best regards, Bernd Zeimetz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plastex
On 7/20/07, Bernd Zeimetz [EMAIL PROTECTED] wrote: Probably reading the New Maintainer's reference and the other documents linked on http://www.debian.org/doc/devel-manuals#maint-guide could be useful for you. Best regards, Bernd Zeimetz Hehe, have read that million of times :) I mostly wondred about the interpretation of the first point, as it said also. /Carl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plastex
Have updated the package now, and I think it's only the licensing issue still in need of taking care about. See: http://mentors.debian.net/debian/pool/main/p/python-plastex/ /Carl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: plastex
From: Carl Fürstenberg [EMAIL PROTECTED] To: debian-mentors@lists.debian.org Subject: RFS: plastex Dear mentors, I am looking for a sponsor for my package plastex. * Package name: plastex Version : 0.8.1-1 Upstream Author : Kevin Smith [EMAIL PROTECTED] * URL : http://plastex.sourceforge.net/ * License : Python (to be changed, probably to GPL or similar) Section : tex It builds these binary packages: plastex- a collection of Python frameworks that allow you to process LaTeX 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. The upload would fix these bugs: 433162 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/plastex - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/plastex/plastex_0.8.1-1.dsc I would be glad if someone uploaded this package for me. /Carl Fürstenberg
Re: RFS: plastex
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. - * 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. - 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'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. - 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 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 [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plastex
On 7/20/07, Bernd Zeimetz [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://bzed.de/ Thanks. /Carl On 7/20/07, Bernd Zeimetz [EMAIL PROTECTED] 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
Re: RFS: plastex
Sorry, gmail fnucked it up for me :( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plastex
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 why is the result included in the diff then? - * 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? http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz - 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. You'll need to poke upstream about that then. I can't speak for the ftp masters, but I'm 100% sure they'd reject the package. Probably interesting to read: http://ftp-master.debian.org/REJECT-FAQ.html - 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. 0 [EMAIL PROTECTED]:/tmp/plastex-0.8.1$ file ./build/scripts-2.4/cgpdfpng ./build/scripts-2.4/cgpdfpng: python script text executable doesn't look like something architecture dependant. Also you want to remove it, as it is using CoreGraphics it doesn't look portable at all. What I missed before: your package seems to build a python module, the proper package (not source) name is python-plastex then. Cheers, Bernd -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
