Paul Wise <[email protected]> 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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
