file encoding and eol marker in orig.tar.gz
Hi! I am polishing the packages for omegat (#448867) and libhtmlparser-java (#448872) and I have a few questions. The background is that I already have to repackage upstream tarball, because they contain compiled jars. 1) Should I convert eol markers (fromdos)? Or at least should I fix the half a dozen files which have CRLF+CR as eol markers? 2) Should I convert the encoding to utf-8? In libhtmlparser, there are two files without copyright notice. This is already corrected in upstream's svn, but upstream is slowly preparing a new major version and doesn't seem likely to release soon. May I introduce myself the notice, noting somewhere that it was 'backported' from svn? Thanks, Tiago. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: file encoding and eol marker in orig.tar.gz
On Thu, Nov 08, 2007 at 09:10:11AM -0200, Tiago Saboga wrote: I am polishing the packages for omegat (#448867) and libhtmlparser-java (#448872) and I have a few questions. The background is that I already have to repackage upstream tarball, because they contain compiled jars. 1) Should I convert eol markers (fromdos)? Or at least should I fix the half a dozen files which have CRLF+CR as eol markers? For many Java packages, I have had to do this, especially to have nice looking patches. 2) Should I convert the encoding to utf-8? I don't know about this. In libhtmlparser, there are two files without copyright notice. This is already corrected in upstream's svn, but upstream is slowly preparing a new major version and doesn't seem likely to release soon. May I introduce myself the notice, noting somewhere that it was 'backported' from svn? Again, this is also a debatable one. But since you are repackaging, you might want to merge these changes from upstream, or patch them, without hurting anyone's sentiments. But I think more knowledgeable persons should answer this. :-) Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: file encoding and eol marker in orig.tar.gz
On Thu, Nov 08, 2007 at 03:24:40PM +0100, Bas Wijnen wrote: I don't know much about java, but if those are just compilations of things for which the source is also in the tarball, there is no need to repackage. You can remove them in the clean target in debian/rules, for example, to make sure they are regenerated. But of course I may be completely missing the point. :-) The idea is that FTP master rejects abt binary content in your orig.tar.gz for which you don't have source. So, if you package for Java, remove all the jars, package them from their source, and repackage your original program (Build-)?Depending on the others. 1) Should I convert eol markers (fromdos)? Or at least should I fix the half a dozen files which have CRLF+CR as eol markers? I wouldn't do that. Repackaging is done to make the tarball complient with our standards, not to beautify it. If this conversion is a good idea (and I agree that it is), then that is an upstream issue, and it should be fixed there. Asking them about it is a good idea, changing it in the package is not IMO. I had to do this, because this caused some build failed for some reason (I don't recall, but my mentor asked me to do it). Also, my patches looked too ugly. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: file encoding and eol marker in orig.tar.gz
On Thu, Nov 08, 2007 at 08:22:06PM +0530, Kumar Appaiah wrote: On Thu, Nov 08, 2007 at 03:24:40PM +0100, Bas Wijnen wrote: I don't know much about java, but if those are just compilations of things for which the source is also in the tarball, there is no need to repackage. You can remove them in the clean target in debian/rules, for example, to make sure they are regenerated. But of course I may be completely missing the point. :-) The idea is that FTP master rejects abt binary content in your orig.tar.gz for which you don't have source. So, if you package for Java, remove all the jars, package them from their source, and repackage your original program (Build-)?Depending on the others. Ah, yes. If the source is in a different package, then you need to remove them indeed. 1) Should I convert eol markers (fromdos)? Or at least should I fix the half a dozen files which have CRLF+CR as eol markers? I wouldn't do that. Repackaging is done to make the tarball complient with our standards, not to beautify it. If this conversion is a good idea (and I agree that it is), then that is an upstream issue, and it should be fixed there. Asking them about it is a good idea, changing it in the package is not IMO. I had to do this, because this caused some build failed for some reason (I don't recall, but my mentor asked me to do it). Making changes to make the build work is always good, of course. However, when changes are made for the Debian package, this should be done in a way which doesn't hide them. When a user sees a package where the tarball is repackaged because some files had to be removed, she's not going to expect any changes other than the removal of some files. For other changes, we have a nicely working patch system. Also, my patches looked too ugly. And that's not an argument not to use it. :-) If you need to do ugly things, then it should look ugly. Putting those changes somewhere where they're hard to see may cause other problems which are hard to track down (not for you, but for other people who are expecting the have the original source). Especially if those changes are needed to make the build work, it is important that they are visible like other changes, and that's in the .diff.gz (directly or through a patch system, whatever you prefer). Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: file encoding and eol marker in orig.tar.gz
On Thu, Nov 08, 2007 at 09:10:11AM -0200, Tiago Saboga wrote: The background is that I already have to repackage upstream tarball, because they contain compiled jars. I don't know much about java, but if those are just compilations of things for which the source is also in the tarball, there is no need to repackage. You can remove them in the clean target in debian/rules, for example, to make sure they are regenerated. But of course I may be completely missing the point. :-) 1) Should I convert eol markers (fromdos)? Or at least should I fix the half a dozen files which have CRLF+CR as eol markers? I wouldn't do that. Repackaging is done to make the tarball complient with our standards, not to beautify it. If this conversion is a good idea (and I agree that it is), then that is an upstream issue, and it should be fixed there. Asking them about it is a good idea, changing it in the package is not IMO. 2) Should I convert the encoding to utf-8? Same thing, if it is a good idea, it should be done upstream. The tarball should look as much as possible like the original upstream. In fact, it should _be_ the original upstream, of course, but if it can't, then it should be as close as possible to it. Changes you want to make should be made using the diff.gz. In libhtmlparser, there are two files without copyright notice. This is already corrected in upstream's svn, but upstream is slowly preparing a new major version and doesn't seem likely to release soon. May I introduce myself the notice, noting somewhere that it was 'backported' from svn? If this is really a mistake, and this new notice is also valid for previous versions (this is likely, but I don't know the details), then you can safely add it. I don't think this is really needed, though. I would mention in the copyright file that those files really have the following license: ... with links to the upstream sources, or e-mail archives saying that they do. You can choose to also add the header to the file in the .diff.gz, but there's no real need IMO. It definitely isn't a reason to repackage the tarball, and thus not something you should fix in the repackaged tarball. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: file encoding and eol marker in orig.tar.gz
On Thu, Nov 08, 2007 at 03:59:44PM +0100, Bas Wijnen wrote: On Thu, Nov 08, 2007 at 08:22:06PM +0530, Kumar Appaiah wrote: On Thu, Nov 08, 2007 at 03:24:40PM +0100, Bas Wijnen wrote: I wouldn't do that. Repackaging is done to make the tarball complient with our standards, not to beautify it. If this conversion is a good idea (and I agree that it is), then that is an upstream issue, and it should be fixed there. Asking them about it is a good idea, changing it in the package is not IMO. I had to do this, because this caused some build failed for some reason (I don't recall, but my mentor asked me to do it). Making changes to make the build work is always good, of course. However, when changes are made for the Debian package, this should be done in a way which doesn't hide them. When a user sees a package where the tarball is repackaged because some files had to be removed, she's not going to expect any changes other than the removal of some files. For other changes, we have a nicely working patch system. In fact devref 6.7.8.2.2 discourages doing anything except removing files when repackaging. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: file encoding and eol marker in orig.tar.gz
On Thu, Nov 08, 2007 at 03:24:40PM +0100, Bas Wijnen wrote: On Thu, Nov 08, 2007 at 09:10:11AM -0200, Tiago Saboga wrote: The background is that I already have to repackage upstream tarball, because they contain compiled jars. I don't know much about java, but if those are just compilations of things for which the source is also in the tarball, there is no need to repackage. You can remove them in the clean target in debian/rules, for example, to make sure they are regenerated. But of course I may be completely missing the point. :-) It's good to know that it's possible to leave compiled things in the tarball, but in these cases there are also third-party jars without source code. As I am repackaging anyway, I will cut out all jars to save space. 1) Should I convert eol markers (fromdos)? Or at least should I fix the half a dozen files which have CRLF+CR as eol markers? I wouldn't do that. Repackaging is done to make the tarball complient with our standards, not to beautify it. If this conversion is a good idea (and I agree that it is), then that is an upstream issue, and it should be fixed there. Asking them about it is a good idea, changing it in the package is not IMO. Upstream recently changed it the other way around :( The main problem with not converting it is that it is a pain to write and maintain patches with broken/different eol markers. OTOH, I see the point to have as unchanged as possible sources. 2) Should I convert the encoding to utf-8? Same thing, if it is a good idea, it should be done upstream. The tarball should look as much as possible like the original upstream. In fact, it should _be_ the original upstream, of course, but if it can't, then it should be as close as possible to it. Changes you want to make should be made using the diff.gz. Ok. In libhtmlparser, there are two files without copyright notice. This is already corrected in upstream's svn, but upstream is slowly preparing a new major version and doesn't seem likely to release soon. May I introduce myself the notice, noting somewhere that it was 'backported' from svn? If this is really a mistake, and this new notice is also valid for previous versions (this is likely, but I don't know the details), then you can safely add it. I don't think this is really needed, though. I would mention in the copyright file that those files really have the following license: ... with links to the upstream sources, or e-mail archives saying that they do. You can choose to also add the header to the file in the .diff.gz, but there's no real need IMO. It definitely isn't a reason to repackage the tarball, and thus not something you should fix in the repackaged tarball. I will then point it out in the copyright file. I was just afraid of not complying with debian copyright rules. Thanks, Tiago. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450608: debhelper: [DH_FIXPERMS] bin/* are updated with v5 too (Re: Executable's execute permission not getting set)
Package: debhelper
Version: 5.0.42
Severity: minor
Tags: patch
File: /usr/bin/dh_fixperms
User: [EMAIL PROTECTED]
Usertag: dh_fixperms
X-Debbugs-Cc: debian-mentors@lists.debian.org
On Thu, Nov 08, 2007 at 04:16:06PM +0100, Bernd Zeimetz wrote:
Arnaud Fontaine wrote:
Bernd == Bernd Zeimetz [EMAIL PROTECTED] writes:
Hello,
Bernd if I understand dh_fixperms manpage correctly it does not
Bernd 'fix' the permissions for bin directories anymore. So you
Bernd just want to add a chmod 755 somewhere.
However, dh_fixperms seems to fix the permissions for bin directories if
compat = 4 according to the manpage (It makes all files in bin/
directories, /usr/games/ and etc/init.d executable (v4 only))
v4 only sounds like compat ==4 imho. If not it should probably updated
to since v4.
You're right:
| # v4 and up
| if (! compat(3)) {
| # Programs in the bin and init.d dirs should be executable..
| for my $dir (qw{usr/bin bin usr/sbin sbin usr/games etc/init.d}) {
--- /usr/bin/dh_fixperms
+++ /tmp/tmp.cCMEZ29704/dh_fixperms 2007-11-08 10:29:23.0 -0500
@@ -24,8 +24,8 @@
the permissions of all man pages to mode 644. It makes all files be owned
by root, and it removes group and other write permission from all files. It
removes execute permissions from any libraries that have it set. It makes
-all files in bin/ directories, /usr/games/ and etc/init.d executable (v4
-only). Finally, it removes the setuid and setgid bits from all files in the
+all files in bin/ directories, /usr/games/ and etc/init.d executable (since
+v4). Finally, it removes the setuid and setgid bits from all files in the
package.
=head1 OPTIONS
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: file encoding and eol marker in orig.tar.gz
On Thu, Nov 08, 2007 at 10:09:59AM -0500, Justin Pryzby wrote: Making changes to make the build work is always good, of course. However, when changes are made for the Debian package, this should be done in a way which doesn't hide them. When a user sees a package where the tarball is repackaged because some files had to be removed, she's not going to expect any changes other than the removal of some files. For other changes, we have a nicely working patch system. In fact devref 6.7.8.2.2 discourages doing anything except removing files when repackaging. If this is the case, I shall try to avoid it in the next revision. Thanks for pointing this out. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Executable's execute permission not getting set
Arnaud Fontaine wrote: Bernd == Bernd Zeimetz [EMAIL PROTECTED] writes: Hello, Bernd if I understand dh_fixperms manpage correctly it does not Bernd 'fix' the permissions for bin directories anymore. So you Bernd just want to add a chmod 755 somewhere. However, dh_fixperms seems to fix the permissions for bin directories if compat = 4 according to the manpage (It makes all files in bin/ directories, /usr/games/ and etc/init.d executable (v4 only)) v4 only sounds like compat ==4 imho. If not it should probably updated to since v4. But probably I'm just too paranoid about it ;) Cheers, Bernd -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: file encoding and eol marker in orig.tar.gz
On Thu, Nov 08, 2007 at 03:59:44PM +0100, Bas Wijnen wrote: Making changes to make the build work is always good, of course. However, when changes are made for the Debian package, this should be done in a way which doesn't hide them. When a user sees a package where the tarball is repackaged because some files had to be removed, she's not going to expect any changes other than the removal of some files. For other changes, we have a nicely working patch system. That is all documented in README.Debain-source. All the repackaged packages of mine have such a file which describe, in detail, what I do. In that sense, it is not hidden. Also, my patches looked too ugly. And that's not an argument not to use it. :-) If you need to do ugly things, then it should look ugly. Putting those changes somewhere where they're hard to see may cause other problems which are hard to track down (not for you, but for other people who are expecting the have the original source). Especially if those changes are needed to make the build work, it is important that they are visible like other changes, and that's in the .diff.gz (directly or through a patch system, whatever you prefer). I agree on this, and you are very correct. But my mentor recommended the change, as we were repackaging it anyway. Besides, noting whatever I've done in README.Debian-source does alleviate suffering a little. But it's always tough when repackaging... *sigh* Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Executable's execute permission not getting set
Bernd == Bernd Zeimetz [EMAIL PROTECTED] writes: Hello, Bernd if I understand dh_fixperms manpage correctly it does not Bernd 'fix' the permissions for bin directories anymore. So you Bernd just want to add a chmod 755 somewhere. However, dh_fixperms seems to fix the permissions for bin directories if compat = 4 according to the manpage (It makes all files in bin/ directories, /usr/games/ and etc/init.d executable (v4 only)) and its source code (around line 88). So it should correctly fixed permissions of /usr/bin (using chmod a+x in dh_fixperms). Regards, Arnaud Fontaine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
Dear mentors, I am looking for a sponsor for my package mediatomb. * Package name: mediatomb Version : 0.10.0-4 Upstream Author : Gena Batyan [EMAIL PROTECTED], Sergey Bostandzhyan [EMAIL PROTECTED], Leonhard Wimmer [EMAIL PROTECTED] * URL : http://mediatomb.cc/ * License : GPLv2 Section : net It builds these binary packages: mediatomb - UPnP MediaServer mediatomb-common - UPnP MediaServer mediatomb-daemon - UPnP MediaServer The package appears to be lintian clean. The upload would fix these bugs: 440199 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mediatomb - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mediatomb/mediatomb_0.10.0-4.dsc I would be glad if someone uploaded this package for me. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
On Fri, Nov 09, 2007 at 09:35:05AM +0930, Paul Wise wrote:
postinst should use dpkg-statoverride instead of chown
Really? I thought this was an administrator's tool, and the postinst
should do something like
getent $u /dev/null ||
adduser --system --group --home /var/... --shell /usr/sbin/nologin \
--disabled-{login,password} $u
dpkg-statoverride --list $f /dev/null ||
chown $u:$u $f
If the statoverride datafile gets filled with all sorts of
maintainer's default package data then it instead requires some
heureustic to try to determine whether the admin did chmod to a
different user/group.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
On Nov 9, 2007 9:43 AM, Justin Pryzby [EMAIL PROTECTED] wrote: On Fri, Nov 09, 2007 at 09:35:05AM +0930, Paul Wise wrote: postinst should use dpkg-statoverride instead of chown Really? I thought this was an administrator's tool, and the postinst should do something like I guess I meant chowning blindly instead of chown. I do note that a few postinst files in my /var/lib/dpkg/info/ use dpkg-statoverride rather than chown. I guess I should reread devref/policy. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dpkg-statoverride (Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface)
On Fri, Nov 09, 2007 at 10:35:00AM +0930, Paul Wise wrote: On Nov 9, 2007 9:43 AM, Justin Pryzby [EMAIL PROTECTED] wrote: On Fri, Nov 09, 2007 at 09:35:05AM +0930, Paul Wise wrote: postinst should use dpkg-statoverride instead of chown Really? I thought this was an administrator's tool, and the postinst should do something like I guess I meant chowning blindly instead of chown. I do note that a few postinst files in my /var/lib/dpkg/info/ use dpkg-statoverride rather than chown. I guess I should reread devref/policy. Policy mentions this in 10.9.1; it appears that it can be correct to do either dpkg-statoverride --update or use chown directly, as long as it's conditional on does dpkg-statoverride -l $f /dev/null. I note that using chown doesn't add the file to the override data, which I argue is a good thing due to no ambiguity about who put it there. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
ftp-master is down, so here is a review of your diff.gz: since you already use the Homepage field, you should remove it from the descriptions don't forget to send the desktop file upstream (and other relevant stuff) the Encoding field is obsolete in .desktop files (please use lintian next time) It would be good if the package descriptions weren't almost-copies of each other Who is Leonhard Wimmer, and why is he in the Maintainer field? The maintainer field is for the maintainer of the debian package, not the upstream code. might want to use debian/compat 5 postinst should use dpkg-statoverride instead of chown -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
