gmane.comp.gnu.mingw.devel

Re: groff package in MSYS -- pdfroff fails dismally

Keith Marshall — 2012-05-09T19:18:32

Thanks.


Debian have a long standing history of rejected groff patches, to the
extent that they locked their users into a 5+ year time warp, stuck at
groff-1.17, when the rest of the world had already progressed to 1.20.
(Most of us just ignored the APT repository, and built from source).


The problem with distro-specific patch sets is precisely that ... they
are distro-specific.  What works for Debian may be, (and very likely
*will* be), inappropriate for MSYS, (or indeed, any other distro).


Except, that I didn't reject them out of any sense of pride in the
original code; I rejected them because they were *broken* on other
platforms, on other platforms on which I personally use groff, (of which
MSYS was just one).


$(LN_S) used *not* to be a problem; AC_PROG_LN_S used to set it to
`ln -s' on MSYS, but it now seems to choose `cp -p' instead; `ln -s'
works fine, but `cp -p' doesn't.  Furthermore, this is only one of two
issues I never encountered before, building stock FSF groff-1.20.1 for
MinGW on MSYS

Re: w32api, mingw64, licensing, and provenance

Charles Wilson — 2012-05-06T04:31:39

And my question is...what code, exactly, have I referenced that is GPL? 
The WINE headers and libs are ***L*** GPL.

http://wiki.winehq.org/Licensing

That's still probably not ok for cygwin, but let's be precise.

I'm not arguing against the proposition that any LGPL code should be 
excluded, were we to go trolling in mingw64 for additions to w32api.  In 
fact, I tend to agree that it should be excluded.  But the LGPL is a 
wholly different license than the GPL (they share a lot of the same 
legal language, but the small bits where they differ have a huge impact 
on the ultimate meaning).

--
Chuck

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: w32api, mingw64, licensing, and provenance

Earnie Boyd — 2012-05-06T03:44:47

On Sat, May 5, 2012 at 10:46 AM, Charles Wilson
<cwilso11< at >users.sourceforge.net> wrote:

My reference is to the windows api (w32api).  Cygwin cannot use GPL
code for its runtime since they have allowed for commercial exception
licensing.  I am not talking about any other software since it would
have been OT for the post.


Again, I mean Cygwin runtime.  It's parts and pieces that use the
runtime are not relative to the conversation.


The point again is the commercial exception licensing allowance that
is provided by Cygwin.  They cannot extend the commercial license
beyond their own runtime so they cannot use others code that is GPL.


Understand, I'm at the time of year I must do 2 long and lengthy
installations of updates to systems.  This is the first, I'm planning
for 20 hours of work.

Re: w32api, mingw64, licensing, and provenance

Charles Wilson — 2012-05-05T14:46:55

...

Red herring.  Nowhere has ANYONE ever suggested that ANY of the 
*runtime* code (that is, the stuff that makes it into the binaries you 
create with the toolchain) in mingw64 is (nonL)GPL -- other than the gcc 
runtime libs themselves which are GPL-with-exception, but that applies 
to mingw.org's gcc offerings as well.


Not sure about either of those points. There's no rule that says you 
can't use cygwin as a platform, and its various tools (like cross 
compilers) to create totally unfree applications (assuming those unfree 
apps don't link to cygwin1.dll or any (nonL)GPL libraries).  So there's 
no legal bar to cygwin shipping bits of header files that come from Wine 
or ReactOS.  /Maybe/ a spirit-of-the-law violation, or some 
semi-official policy, but no legal bar.  IANAL, etc etc.

Now, if cygwin64's own build process somehow links in some of those WINE 
bits in such a way as to make cygwin64 a "derived work" of WINE...yeah, 
then there'd be problems except that the WINE bits are LGPL not pure 
GP

Re: groff package in MSYS -- pdfroff fails dismally

Keith Marshall — 2012-05-04T14:51:31

Sheesh!  Thanks, I wasn't expecting such a detailed reply.  It deserves
a detailed review, but I'll have to get back to you with that.

Re: www.mingw.org pages added

Keith Marshall — 2012-05-04T14:48:05

I had a couple of observations, but I'll have to get back to you with them.

Re: w32api, mingw64, licensing, and provenance

Earnie Boyd — 2012-05-04T18:07:11

I can understand this reasoning.


Yes, but Fedora is all straight GPL.


And Cygwin cannot use GPL code because of their modified and
commercial license so their may be some roadblock still for Cygwin.
Especially some parts and pieces.


Again, we may need to still be careful because of the Cygwin license.


The WINE parts will need to vanish if I understand the Cygwin position
correctly.  I thought parts came from ReactOS as well but I don't see
it mentioned in the license document.


I'll be looking for it.

w32api, mingw64, licensing, and provenance

Charles Wilson — 2012-05-04T14:23:17

In February, Fedora replaced their mingw.org-based 32bit cross compiler 
and related packages with mingw64, for Fedora 17 (due out this month). 
Until this action, Fedora supported only 32 bit windows, using our 
compiler.  In order to support 64bit windows, they needed at least the 
64bit version from mingw64, but decided also to use mingw64's offerings 
for 32bit as well.

To do this, they had to consider the licensing issues that we often 
discuss here ("we received some signals in the past that a legal
audit should be done for these packages") -- and they had a team of 
lawyers to do so.

http://fedoraproject.org/wiki/Features/Mingw-w64_cross_compiler

Legal approval from the Red Hat lawyers:
http://lists.fedoraproject.org/pipermail/mingw/2012-February/004533.html
"the mingw-w64 toolchain is no longer subject to any known legal blocks"


There are two primary consumers of w32api: mingw and cygwin (and cygwin 
is a Red Hat product). Cygwin has already begun discussing the use of 
the mingw64 w32api bits f

FRS news

Earnie Boyd — 2012-05-03T13:00:03

SF has changed login and directory structure again. See
http://sourceforge.net/apps/wordpress/sourceforge/2012/03/09/file-release-system-permissions-updates/
for details.

Re: www.mingw.org pages added

Earnie Boyd — 2012-05-03T13:00:53

On Wed, Apr 25, 2012 at 8:55 AM, Earnie Boyd
<earnie< at >users.sourceforge.net> wrote:

Ping.  Anyone?

Re: groff package in MSYS -- pdfroff fails dismally

Charles Wilson — 2012-05-03T02:56:55

...and that hour+ spent answering one email was pretty much all of my 
MinGW/MSYS time for the week.  Sigh.

--
Chuck

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: groff package in MSYS -- pdfroff fails dismally

Charles Wilson — 2012-05-03T02:55:19

Upstream groff-1.20.1, plus debian-1.20.1-9-patches, plus

1) 01-doc-gfdl-msys.patch
Say "MSYS" instead of "Debian" in man pages (debian 'doc-gfdl.patch' 
added a reference to "Debian" while pointing to the GNU FDL).

2) 02-msys-install.patch
Use lndir instead of symlinks, when replicating $(version)$(revision) as 
'current'



I generally have had good results for many packages, on both cygwin and 
msys, by picking up patchsets from debian or gentoo (or even sometimes 
Red Hat or Mandriva) since the distros generally update their packages 
on a more rapid basis than any 'upstream'.

It appears that may not necessarily be true in this case; looking closer 
I can't really see any reason to prefer the giant 'perl.exe' to the slim 
'awk.exe' -- even if it simplifies mdate.sh to a single line.

Not to mention your aforementioned mktemp problem.


Ah, see now here's where we disagree.  You have a more intimate 
relationship with the groff source than I do -- but from my third party 
perspective there's no immedi

groff package in MSYS -- pdfroff fails dismally

Keith Marshall — 2012-05-02T13:26:58

Chuck,

Where did you get the source for the groff-1.20.1 in MSYS?

I ask because, while setting up a new machine at work, I thought that
I would give it a try, rather than seek out a backup of my own native
build, but after

  mingw-get install msys-man-bin
  mingw-get install msys-groff-doc msys-groff-ext

and having also installed the PortableApps.com version of GhostScript,
pdfroff refused to run, (failing on a mktemp command invocation).

Now, I *know* that pdfroff isn't *supposed* to require mktemp; (I know
this because *I* am the original author).  On investigating, I notice
that the pdfroff in msys-groff-ext includes a Debian patch which I
rejected upstream; I rejected it because I knew it was going to break
any platform which didn't provide mktemp, (and, at the time, MSYS was
one such platform).

I know we do, now, provide an msys-mktemp implementation, so the Q&D fix
could be to add the dependency to msys-groff-ext, but I really would
prefer a distribution based on original FSF source, not polluted

Re: RFC: setting mingw-get options within profile.xml

Keith Marshall — 2012-04-28T03:23:23

That was my initial preference too, but what if there is no value?

  <preferences>
    <option name="desktop" />
    ...
  </preferences>

vs.

  <preferences>
    <enable option="desktop" />
    ...
  </preferences>

when the intent is to create desktop shortcuts for current user only,
rather than for all users?  It's trivially easy to implement it one way
or the other, but I definitely want only one.  On balance, I think I
still prefer the former; just thinking aloud, in an effort to convince
myself that it's no less logical than the latter.


Hadn't thought of that one.  Thanks!  Something to maybe bear in mind,
for a rainy day...

One that I did think of:

  <preferences>
    <policy release-status="beta" option="decline" />
  </preferences>

to indicate that, if I've already installed a better quality release,
I'd prefer to stick with it, rather than upgrade to a "beta" (or lesser
quality) release on a newer development branch; another possibility for
that rainy day.

Re: RFC: setting mingw-get options within profile.xml

Charles Wilson — 2012-04-26T21:42:00

Of the four proposed syntaxes, I prefer #2, in Keith's original RFC:

  <preferences>
    <option name="desktop" value="all-users" />
    ...
  </preferences>

It clearly represents the intent: the user has certain preferences. Some
of those are "options" which have a "name" and "value(s)". There may be
other preferences that are not options, which would be represented as
other <elements/> within <preferences/>.

What sort of preference would not be an option? Maybe auto-triggers
(e.g. whenever I do a source action, I *always* want to add "--recurse
--download-only" to the option list, but only for that action.

  <preferences>
    <action-defaults name="source"
      type="append-options"
      value="recurse download-only"/>
  </preferences>

But, since SHTDI, and Keith is the guy who is actually Doing It, I won't
object to any of the four current proposals.

--
Chuck

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will

www.mingw.org pages added

Earnie Boyd — 2012-04-25T12:55:36

I've been adding pages to MinGW.org indexed in a block on the right
titled "What Can You Do for MinGW?"  I would like feedback for the
content in those pages.

Re: RFC: setting mingw-get options within profile.xml

Earnie Boyd — 2012-04-23T11:47:45

Yes, I meant okay.


I can live with this.  It is a set it once item so it works.

Re: RFC: setting mingw-get options within profile.xml

Keith Marshall — 2012-04-21T17:54:44

Which would be okay, right?  Or did you mean unnatural?


This would not lend itself well to the implementation.


Having played a bit with implementation, I'm now leaning toward:

  <preferences>
    <enable option="desktop" [value="all-users"] />
    <enable option="start-menu" [value="all-users"] />
    ...
  </preferences>

or maybe:

  <preferences>
    <enable option="desktop" [preferences="all-users"] />
    <enable option="start-menu" [preferences="all-users"] />
    ...
  </preferences>

where the general form of the "enable" tag would be:

  <enable option="option-name" [preferences="attribute[,...]] />

Not a big deal, I guess, but using the same spelling of the keyword
"preferences" for both the container element tag, and for the attribute
name, saves defining both the singular and plural forms as independent
keywords.

The idea, for now, is to relieve users of the need to specify the
--desktop[=all-users] and the --start-menu[=all-users] command line
options, (see 'mingw-get --help' for the min

Re: RFC: setting mingw-get options within profile.xml

Earnie Boyd — 2012-04-21T16:17:48

On Fri, Apr 20, 2012 at 4:27 PM, Keith Marshall
<keithmarshall< at >users.sourceforge.net> wrote:

This sounds a bit natural.


or

<preferences>
  <preference desktop="all-users" />
  <preference start="mingw" />
</preferences>

Since we have preferences we should have a preference.


Ditto.

RFC: setting mingw-get options within profile.xml

Keith Marshall — 2012-04-20T20:27:41

I'm thinking primarily of options such as --desktop and --start-menu,
(added in mingw-get-0.5), for which users may wish to establish their
own preferred default settings.  To accommodate this, I propose to add
handling for a <preferences>...</preferences> section in profile.xml

The implementation will ensure that any option specified on the command
line will override a default setting in profile.xml

I'd welcome your thoughts on preferred syntax for the XML; which of the
following would you prefer?

  <preferences>
    <set option="desktop" class="all-users" />
    ...
  </preferences>

or

  <preferences>
    <option name="desktop" value="all-users" />
    ...
  </preferences>

or some alternative tag/attribute combination, conveying the concept?

Re: Another MINGW project

Chris Sutcliffe — 2012-04-19T17:31:55

I agree with Chuck, their w*api is a lot more feature complete then
our w32api.  They have a more active group of contributors to their
w*api and have more than 1 person committing the changes.
Unfortunately these days I'm finding it hard to find cycles to commit
patches (never mind developing patches) to the w*api and mingwrt.

If we decide to not merge the development effort, then I'd be greatful
if someone would be willing to step up to help out with / take over
maintaining the w32api and mingwrt rather then having these packages
suffer as a result of my lack of time.

Chris