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]
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: 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]
