"TakeoffGW"

"TakeoffGW"

[Andy Koppe]

Yay, another Cygwin 1.3.3 (aka MSYS) distribution, this time using
Cygwin's latest setup.exe:

http://sourceforge.net/projects/takeoffgw

Andy

Re: "TakeoffGW"

[Charles Wilson]

On 5/31/2010 8:43 AM, Andy Koppe wrote:
> Yay, another Cygwin 1.3.3 (aka MSYS) distribution, this time using
> Cygwin's latest setup.exe:
> 
> http://sourceforge.net/projects/takeoffgw

So far, it's only a fork of setup.exe.  It doesn't actually include any
installable components.  Looking at the patches, the "mirror.lst" points to:
http://takeoffgw.sourceforge.net/R0/  -- which doesn't exist, and
ftp://localhost/takeoffgw/

I think "pier11" neglected to test his new brainchild on a different
computer...

The fun part is, he forked the cygwin-1.7 version of setup.exe.  I have
a hunch that our latest setup.exe does a lot of NTSEC things that might
not actually play very well with cygwin-1.3.3/MSYS.

In any case, I think this is more a concern for the MinGW/MSYS fellas:
"Accompanying files (setup.hint) contain reference to original binary
packages on MinGW site: https://sourceforge.net/projects/mingw/files/"

In otherwords, if he ever actually uploads the setup.ini, it'll point to
the mingw project's tarballs (for MinGW gcc, MSYS components, etc).
'Course, they don't ptovide any md5sum signatures, so I kinda wonder
what this new setup.exe fork will think about that...

--
Chuck

Re: "TakeoffGW"

[Christopher Faylor]

On Mon, May 31, 2010 at 09:44:52AM -0400, Charles Wilson wrote:
>On 5/31/2010 8:43 AM, Andy Koppe wrote:
>> Yay, another Cygwin 1.3.3 (aka MSYS) distribution, this time using
>> Cygwin's latest setup.exe:
>> 
>> http://sourceforge.net/projects/takeoffgw
>
>So far, it's only a fork of setup.exe.  It doesn't actually include any
>installable components.  Looking at the patches, the "mirror.lst" points to:
>http://takeoffgw.sourceforge.net/R0/  -- which doesn't exist, and
>ftp://localhost/takeoffgw/
>
>I think "pier11" neglected to test his new brainchild on a different
>computer...

It looks like "pier11" also neglected to understand the GPL since only
patches are provided and no the actual source code.

Anyone feel like telling him/her?  Hmm.  Does sourceforge have a method
for reporting GPL violations?

cgf

Re: "TakeoffGW"

[Andy Koppe]

On 31 May 2010 14:44, Charles Wilson wrote:
>> Yay, another Cygwin 1.3.3 (aka MSYS) distribution, this time using
>> Cygwin's latest setup.exe:
>>
>> http://sourceforge.net/projects/takeoffgw
>
> So far, it's only a fork of setup.exe.  It doesn't actually include any
> installable components.  Looking at the patches, the "mirror.lst" points to:
> http://takeoffgw.sourceforge.net/R0/  -- which doesn't exist

Seems it's just that listing that directory is blocked. Accessing
setup.ini within works fine, as does running setup.exe, although I
cancelled it while it was trying to download 65MBs worth of
msys-coreutils.

Andy

Re: "TakeoffGW"

[Charles Wilson]

On 5/31/2010 2:25 PM, Andy Koppe wrote:

> Seems it's just that listing that directory is blocked. Accessing
> setup.ini within works fine, as does running setup.exe, although I
> cancelled it while it was trying to download 65MBs worth of
> msys-coreutils.

Oh, that's hysterical.  The previous version of msys-coreutils was built
with i18n support via a statically linked version of libintl, because
the then-current msys gcc was based on gcc-2.95.3, and Bruno's
fancy-schmancy mechanism for avoiding auto-import didn't work with that
old version.  Hence, msys-libintl was static only.  This meant that
every single app in coreutils was 1.2MB or bigger, even /bin/true.exe.

You wouldn't BELIEVE the howls of outrage. You'd think disk space was
paid for in gold bricks, or something.

Now, the msys project compressed all those tarballs using lzma, which
has a 4MB dictionary -- so all that repeated code in each exe compressed
VERY well.  This guy repackaged using bz2, which doesn't (dictionary too
small) -- even though the version of setup that he forked DOES support
.lzma (and .xz)

But the really funny bit is this: he's pointing at all the msys packages
released prior to May 2010 -- AND the msys-gcc-3.4.4 compiler.  Which
means half of his libraries are circa gcc-2.x, and half are circa
gcc-3.x.  Given that there was an ABI change in the cygwin-based
compilers between 2.x and 3.x (to support the C++ exceptions across
DLLs, but it affected C code too) -- I'm thinking...FAIL.

AND...he's also pointing at the "msysDVLPR" package, which will
clobber/conflict with msys-gcc(3.4), msys-g++(3.4), msysCORE-dev, and
msys-w32api...

I happen to know about this because I spent the last several months,
since msys-gcc-3.4.4 was released, updating all of the msys packages to
that new compiler, and rolled them out over the last few weeks. (On the
plus side, with the new msys-gcc, libintl CAN be built as a DLL, so all
those msys-coreutils apps are back down to ~20k as they should be).

Boy, this guy's running afoul of two different developer communities
simultaneously, which don't normally agree. First there's the whole GPL
setup.exe thing (plus we cygwinner's despair at yet another unsupported
installation method for cygwin-derived stuff).  Then, there's the
massive expansion of many additional tools to the "msys" platform. The
MSYS guys do NOT want to replace cygwin; they don't want to have an msys
port of apache, or pidgen, or GNOME ...  It's supposed to be a "Minimal
SYStem" -- just barely enough posix support and tools to run configure
scripts, with tweaks tuned for use with MinGW's gcc, rather than
"cygwin's" gcc.

Yeesh.

And no, pier11 never mentioned these plans "over there", either.  The
really REALLY funny thing, is in just a few weeks, the MinGW folks are
going to (finally) release an installer of their own, which is
extensible and allows to "include by reference" other repositories of
addons. Which means a lot of his "repackaging" work -- and setup.exe
fork -- was totally unnecessary.

--
Chuck