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
