lzip-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lzip-bug] [PATCH] lzip on Windows


From: JonY
Subject: Re: [Lzip-bug] [PATCH] lzip on Windows
Date: Wed, 14 Oct 2009 21:32:47 +0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0

On 10/14/2009 18:36, Antonio Diaz Diaz wrote:
Hello JonY,

Thanks for the packages, and thanks to Tino for his feedback.

I have already uploaded the binary package here (see below about the
source)
http://download.savannah.gnu.org/releases-noredirect/lzip/lzip-1.8-win32-1.zip


Tomorrow I'll add the link to the home page, so that the mirrors have
time to catch up.



Thanks!

JonY wrote:
On 10/14/2009 16:03, Tino Lange wrote:
While you're in the mood :-) Do you think that you can port the lzlib
also to win32 / MinGW / MSYS ?

OK, I'll take a look at them over the weekends.

Great!

I have just discovered a site maintaining ports of unix tools for
windows (http://gnuwin32.sourceforge.net/). Perhaps you could take a
look and get some ideas. Maybe the lzip port could be placed there or in
a similar site. I don't know.


Placing the lzip source and binaries for gnuwin32 distribution is fine, but distributing the binary form of lzlib could be problematic, mostly due to compiler ABI issues.

I am not yet sure what is the best way of distributing modified sources.
The people at gnuwin32 distributes them as unified diffs
(http://gnuwin32.sourceforge.net/summary.html).


Distributing unified diffs should be fine, but I'm not sure if there are other implications.

In any case, could you please add a line stating something like "Ported
to Windows by <your_name>", or "Patched for Windows by <your_name>", or
"Windows modifications made by <your_name>", (you get the idea), under
the Copyright line in every file you modified in the source package? I
think the GPL requires modified versions be marked as such.


I tend to forget how strict GPL is with copyright assignments. Should I resend the patches and the source tarball?

Also I remember a bug report in Debian explaining the file
share/info/dir should not be included in binary packages. I don't know
if it matters for windows packages.


Windows itself does not have the info(1) tool, but I'll be sure to remove it next time.

BTW, I have just been told that signal handlers for CTRL-C and
CTRL-BREAK do not work for Windows, the program just ends. I don't
think that is will be a huge issue though.

I never expected perfect behaviour of a posix tool on windows.


That is to be expected, Windows doesn't try to be POSIX most of the time (unless you use interix/sua/unix subsystem, but thats a different issue). The MinGW maintainers are also hesitant about adding additional POSIX functions.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]