Re: Upstream tarballs with varying line endings
Paul Wise writes: > On Sat, Nov 23, 2013 at 4:02 PM, Felix Natter wrote: > >> Unfortunately libjgoodies-forms-java 1.6 renames some classes so you >> can't have a source code/patch that works with both 1.4 and 1.6... > > Is there really no way to do #ifdef in Java? No, unless you're doing code generation. > I wonder if you could have two implementations and have ant choose > which one based on the available libjgoodies-forms-java. Or have one > implementation with the class names undefined and have ant fill those > in at build time. Only as a last resort, since several source files are affected. > Good luck with line ending issue. Thanks, it should be easy (unless we rely on the permissions of the original source tarball that is to be repacked, but that is unlikely since it's built on Windows). Best Regards, -- Felix Natter -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fvqno6hy@bitburger.home.felix
Re: Upstream tarballs with varying line endings
On Sat, Nov 23, 2013 at 4:02 PM, Felix Natter wrote: > Unfortunately libjgoodies-forms-java 1.6 renames some classes so you > can't have a source code/patch that works with both 1.4 and 1.6... Is there really no way to do #ifdef in Java? I wonder if you could have two implementations and have ant choose which one based on the available libjgoodies-forms-java. Or have one implementation with the class names undefined and have ant fill those in at build time. Good luck with line ending issue. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6ffb6ywz1uz-m7yetuwpoupv3ahrt+i+3noyco3knc...@mail.gmail.com
Re: Upstream tarballs with varying line endings
Paul Wise writes: hi Paul, > On Fri, Nov 22, 2013 at 2:17 AM, Felix Natter wrote: > >> This is not possible for all patches. For instance, Freeplane also has a >> Mageia linux package and so due to the lack of a recent Mageia >> libjgoodies-forms-java package, we cannot update upstream to the new >> libjgoodies-forms-java... > > It is almost always possible to merge patches upstream or rewrite > patches to make them flexible enough to merge upstream. Unfortunately libjgoodies-forms-java 1.6 renames some classes so you can't have a source code/patch that works with both 1.4 and 1.6... > I'd suggest you don't need to wait for Mageia, they will update > libjgoodies-forms-java when they have a need for that. Yeah, I already told my "packaging colleague" to ask for that. > BTW, you might want to add DEP-3 headers to your patches: > > http://dep.debian.net/deps/dep3/ I'll probably do that for 1.3.x. >> It's not possible. We have decided that we want to stick with this git >> line ending policy and that means that checkouts on Windows will have >> CRLF line endings (I am part of upstream but I wasn't involved in the >> discussion). > > Ugh. > >> So what solution would you prefer? > > Would it be possible to ensure only non-Windows users make release tarballs? I'd rather not rely on that. > Would it be possible to have a release process that produces two > release tarballs, one with Windows line endings and one with normal > line endings, no matter which platform it runs on? Only with solution (1) below. The git checkout on Windows contains CRLF. >> 1. integrate http://ant.apache.org/manual/Tasks/fixcrlf.html upstream >> (generate tarball, extract, fix line endings, generate tarball) > > This sounds like the best option so far. Generating the tarball twice > sounds a bit hacky though, is there no way to copy the files to the > tarball dir, fix line endings and tar that? That is the usual way to > generate tarballs for the build systems I'm familiar with, except the > fix line endings step isn't needed. > >> 2. write a get-orig-source target that does the same? >> If yes, shall I append "+dfsg1" to the version number? > > That could work if upstream doesn't want to be helpful but is usually > frowned on by Debian. > > +dfsg isn't appropriate in this situation because you aren't repacking > for DFSG-related reasons. We usually use +ds (Debian source) when > repacking for other reasons. Ok, then I will stick to (1). >> => I guess both are possible are OK for Debian? > > Right, the second one not so much. I agree. > There is a third option you could use that I would prefer if an > upstream fix doesn't work out: > > Searching for quilt patch line endings on the web found me this bug > where it was pointed out you could just reimport the patches after > every new upstream release using this command: > > QUILT_PATCH_OPTS="-l" quilt import thepatch > http://bugs.debian.org/383431 Good point, but I'd rather fix this once and forever :-) Thanks! -- Felix Natter -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hab3pmto@bitburger.home.felix
Re: Upstream tarballs with varying line endings
On Fri, Nov 22, 2013 at 2:17 AM, Felix Natter wrote: > This is not possible for all patches. For instance, Freeplane also has a > Mageia linux package and so due to the lack of a recent Mageia > libjgoodies-forms-java package, we cannot update upstream to the new > libjgoodies-forms-java... It is almost always possible to merge patches upstream or rewrite patches to make them flexible enough to merge upstream. I'd suggest you don't need to wait for Mageia, they will update libjgoodies-forms-java when they have a need for that. BTW, you might want to add DEP-3 headers to your patches: http://dep.debian.net/deps/dep3/ > It's not possible. We have decided that we want to stick with this git > line ending policy and that means that checkouts on Windows will have > CRLF line endings (I am part of upstream but I wasn't involved in the > discussion). Ugh. > So what solution would you prefer? Would it be possible to ensure only non-Windows users make release tarballs? Would it be possible to have a release process that produces two release tarballs, one with Windows line endings and one with normal line endings, no matter which platform it runs on? > 1. integrate http://ant.apache.org/manual/Tasks/fixcrlf.html upstream > (generate tarball, extract, fix line endings, generate tarball) This sounds like the best option so far. Generating the tarball twice sounds a bit hacky though, is there no way to copy the files to the tarball dir, fix line endings and tar that? That is the usual way to generate tarballs for the build systems I'm familiar with, except the fix line endings step isn't needed. > 2. write a get-orig-source target that does the same? > If yes, shall I append "+dfsg1" to the version number? That could work if upstream doesn't want to be helpful but is usually frowned on by Debian. +dfsg isn't appropriate in this situation because you aren't repacking for DFSG-related reasons. We usually use +ds (Debian source) when repacking for other reasons. > => I guess both are possible are OK for Debian? Right, the second one not so much. There is a third option you could use that I would prefer if an upstream fix doesn't work out: Searching for quilt patch line endings on the web found me this bug where it was pointed out you could just reimport the patches after every new upstream release using this command: QUILT_PATCH_OPTS="-l" quilt import thepatch http://bugs.debian.org/383431 -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6h0gl_rjcwpkjh3_dlj8d3t34fqu9qcdborkco9wm8...@mail.gmail.com
Re: Upstream tarballs with varying line endings
On 21-11-13 19:17, Felix Natter wrote: > 1. integrate http://ant.apache.org/manual/Tasks/fixcrlf.html upstream > (generate tarball, extract, fix line endings, generate tarball) Sound like a good solution. > 2. write a get-orig-source target that does the same? > If yes, shall I append "+dfsg1" to the version number? > > => I guess both are possible are OK for Debian? The second option is usually frowned upon. Line-endings does not sound like a good reason to deviate from the upstream tar-ball. Acceptable reasons are thinks like non-dfsg material. See the developers-reference, section 6.7.8.2 http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-origtargz Paul signature.asc Description: OpenPGP digital signature
Re: Upstream tarballs with varying line endings
Paul Wise writes: > On Wed, Nov 20, 2013 at 3:15 AM, Felix Natter wrote: > >> The patches don't apply with line ending changes. > > The best course of action appears to be to get your patches included > upstream This is not possible for all patches. For instance, Freeplane also has a Mageia linux package and so due to the lack of a recent Mageia libjgoodies-forms-java package, we cannot update upstream to the new libjgoodies-forms-java... > and also ask them to stop exporting tarballs with Windows > line endings. It's not possible. We have decided that we want to stick with this git line ending policy and that means that checkouts on Windows will have CRLF line endings (I am part of upstream but I wasn't involved in the discussion). So what solution would you prefer? 1. integrate http://ant.apache.org/manual/Tasks/fixcrlf.html upstream (generate tarball, extract, fix line endings, generate tarball) or 2. write a get-orig-source target that does the same? If yes, shall I append "+dfsg1" to the version number? => I guess both are possible are OK for Debian? Thanks and Best Regards, -- Felix Natter -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gc1sjor@bitburger.home.felix
Re: Upstream tarballs with varying line endings
On Wed, Nov 20, 2013 at 3:15 AM, Felix Natter wrote: > The patches don't apply with line ending changes. The best course of action appears to be to get your patches included upstream and also ask them to stop exporting tarballs with Windows line endings. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6Hc8MDXZu8JoSXhxVQvzk4YY=4_ybupfktcoa_ym4x...@mail.gmail.com
Re: Upstream tarballs with varying line endings
Dominik George writes: hi Dominik, > Felix Natter schrieb: >>hello, >> >>my problem is that Freeplane's git is configured such that native line >>endings (LF on UNIX, CRLF on Windows) are used in checkouts and thus >>the >>Upstream tarballs are either CR or CRLF, depending on on whose computer >>the release(-tarball) was generated. > > In any case, you should go and slap upstream for that very hard, but how is > it an issue for packaging, assuming the build runs fine in both cases? The patches don't apply with line ending changes. Thanks and Best Regards, -- Felix Natter -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9h0fbiu@bitburger.home.felix
Re: Upstream tarballs with varying line endings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Felix Natter schrieb: >hello, > >my problem is that Freeplane's git is configured such that native line >endings (LF on UNIX, CRLF on Windows) are used in checkouts and thus >the >Upstream tarballs are either CR or CRLF, depending on on whose computer >the release(-tarball) was generated. In any case, you should go and slap upstream for that very hard, but how is it an issue for packaging, assuming the build runs fine in both cases? Cheers, Nik -BEGIN PGP SIGNATURE- Version: APG v1.0.9 iQFNBAEBCgA3BQJSi7TTMBxEb21pbmlrIEdlb3JnZSAobW9iaWxlIGtleSkgPG5p a0BuYXR1cmFsbmV0LmRlPgAKCRAvLbGk0zMOJYXpB/9lEmvBn4817tIvF2QSfgAG 2Oe/TpgYCSbHERJ7JKBwz0EBMQABlGLAo6fifJvmHYPd9UgPMdotXeef+bhuDY58 lm3nWT1BZz4He/sU8cFrpwIXOhsPjsw/fEsE0fG03aB5iChuCFHuJXTb3dfmBnhb Nox3ZGEpodjq8uXhQ/+r+B7I3HYV1Z9TPJjDmamaeJU0frTOJYFN0U6PYYck626U hx5lcEyMQu2jxaTsgv0C5GILsQlTie/OYGT5omU/SrSG0xhMAXzh6lMzSeLiE6/L omdKU8I0E1eYNtpyTWUCC4TjG59pin3Rya3ewebEH6oT8m24Gs5aaFC9gdwvoGR9 =PaWd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/6a0e24d3-6cc9-4cdc-9d20-28f0c27d3...@email.android.com
