On Mon, 2008-07-07 at 23:43 +0100, Richard W.M. Jones wrote:
> On Mon, Jul 07, 2008 at 03:53:14PM -0600, Brendan Conoboy wrote:
> > Any particular reason to go with MinGW rather than Cygwin? Is there
> > room for both in the SIG?
>
> Cygwin has a licensing issue -- namely that it is GPL and so prevents
> any proprietary development on top of our libraries.
How can a toolchain not supporting proprietary development be an issue
to Fedora? It may-be sufficient reason for some users not use Cygwin,
but this his hardly Fedora's problem.

Ralf


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, Jul 08, 2008 at 08:07:52AM +0200, Ralf Corsepius wrote:
> On Mon, 2008-07-07 at 23:43 +0100, Richard W.M. Jones wrote:
> > On Mon, Jul 07, 2008 at 03:53:14PM -0600, Brendan Conoboy wrote:
> > > Any particular reason to go with MinGW rather than Cygwin? Is there
> > > room for both in the SIG?
> >
> > Cygwin has a licensing issue -- namely that it is GPL and so prevents
> > any proprietary development on top of our libraries.
> How can a toolchain not supporting proprietary development be an issue
> to Fedora? It may-be sufficient reason for some users not use Cygwin,
> but this his hardly Fedora's problem.

If you didn't selectively quote me, you'd see I said it's not a
problem for the MinGW SIG (ie. Fedora), but it is a problem for the
libvirt project.

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, Jul 08, 2008 at 08:07:52AM +0200, Ralf Corsepius wrote:
> On Mon, 2008-07-07 at 23:43 +0100, Richard W.M. Jones wrote:
> > On Mon, Jul 07, 2008 at 03:53:14PM -0600, Brendan Conoboy wrote:
> > > Any particular reason to go with MinGW rather than Cygwin? Is there
> > > room for both in the SIG?
> >
> > Cygwin has a licensing issue -- namely that it is GPL and so prevents
> > any proprietary development on top of our libraries.
> How can a toolchain not supporting proprietary development be an issue
> to Fedora? It may-be sufficient reason for some users not use Cygwin,
> but this his hardly Fedora's problem.

You are in essense saying that only GPL software is allowed in Fedora
which is utter nonsense. We want to use MinGW so that we can provide
LGPL software, since Cygwin is GPL only, which is a perfectly legitimate
choice to make.

Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, 2008-07-08 at 08:55 +0100, Daniel P. Berrange wrote:
> On Tue, Jul 08, 2008 at 08:07:52AM +0200, Ralf Corsepius wrote:
> > On Mon, 2008-07-07 at 23:43 +0100, Richard W.M. Jones wrote:
> > > On Mon, Jul 07, 2008 at 03:53:14PM -0600, Brendan Conoboy wrote:
> > > > Any particular reason to go with MinGW rather than Cygwin? Is there
> > > > room for both in the SIG?
> > >
> > > Cygwin has a licensing issue -- namely that it is GPL and so prevents
> > > any proprietary development on top of our libraries.
> > How can a toolchain not supporting proprietary development be an issue
> > to Fedora? It may-be sufficient reason for some users not use Cygwin,
> > but this his hardly Fedora's problem.
>
> You are in essense saying that only GPL software is allowed in Fedora
> which is utter nonsense.
Absolute not - I am actually saying the opposite:

* The fact Cygwin appears to be GPL'ed only, is an issue to Cygwin
users, because it may prevent them from using Cygwin for proprietary
packages/development (must not link against non-GPL'ed libs).

* The fact Cygwin appears to be GPL'ed only, is not an issue to Fedora.
There is no reason for not including Fedora->Cygwin cross-compilers into
Fedora.

> We want to use MinGW so that we can provide
> LGPL software, since Cygwin is GPL only, which is a perfectly legitimate
> choice to make.
Of cause, ...

Ralf


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Mon, Jul 07, 2008 at 10:15:54PM +0100, Richard W.M. Jones wrote:
> I've got a self-building, mostly working set of Fedora packages for
> the MinGW cross-compiler (no optional libraries yet). You can get the
> spec files and instructions by doing:
>
> hg clone http://hg.et.redhat.com/misc/fedora-mingw--devel

What primarily concerns me is that plan around keeping this in sync
with patches/updates to the main gcc, binutils, libpng, libgcrypt,
gnutls, etc RPMS already in Fedora.

The idea of maintaining 2 near identical specs & builds for all these
packages isn't that nice, particularly since many of these are security
sensitive packages

Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, Jul 08, 2008 at 02:30:10PM +0100, Daniel P. Berrange wrote:
> On Mon, Jul 07, 2008 at 10:15:54PM +0100, Richard W.M. Jones wrote:
> > I've got a self-building, mostly working set of Fedora packages for
> > the MinGW cross-compiler (no optional libraries yet). You can get the
> > spec files and instructions by doing:
> >
> > hg clone http://hg.et.redhat.com/misc/fedora-mingw--devel
>
> What primarily concerns me is that plan around keeping this in sync
> with patches/updates to the main gcc, binutils, libpng, libgcrypt,
> gnutls, etc RPMS already in Fedora.
>
> The idea of maintaining 2 near identical specs & builds for all these
> packages isn't that nice, particularly since many of these are security
> sensitive packages

So there's a bit of confusion going around, partly my own.

Mingw-binutils (https://bugzilla.redhat.com/show_bug.cgi?id=454408)
starts with a forked version of binutils maintained by mingw. They
have their own release schedule for this so I'm not sure how viable it
is to have a single binutils SPEC file generating both the normal
binutils and a 'binutils-mingw' subpackage. (Ignoring for now whether
or not the Fedora binutils maintainer is even interested in this).

Mingw-gcc (https://bugzilla.redhat.com/show_bug.cgi?id=454410) starts
from plain gcc 4.3.1 source, so combining these into Fedora's gcc
package might be more hopeful. However there are some nasty
dependencies (mingw-runtime and mingw-w32api, neither of which can be
built ab initio because of circular dependencies) and I suspect that
any time there is any sort of mingw related trouble with this package,
the gcc-mingw subpackage will be the first to be dropped. I don't
want this.

As for the remainder we get into asking question like -- should we
generate the mingw-gnutls library (as an example) from the main gnutls
SPEC file? There are going to be dozens of such libraries and we'll
have to coordinate with a large number of existing Fedora contributors
to make this happen.

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, 2008-07-08 at 15:46 +0100, Richard W.M. Jones wrote:
> On Tue, Jul 08, 2008 at 02:30:10PM +0100, Daniel P. Berrange wrote:
> > On Mon, Jul 07, 2008 at 10:15:54PM +0100, Richard W.M. Jones wrote:
> > > I've got a self-building, mostly working set of Fedora packages for
> > > the MinGW cross-compiler (no optional libraries yet). You can get the
> > > spec files and instructions by doing:
> > >
> > > hg clone http://hg.et.redhat.com/misc/fedora-mingw--devel
> >
> > What primarily concerns me is that plan around keeping this in sync
> > with patches/updates to the main gcc, binutils, libpng, libgcrypt,
> > gnutls, etc RPMS already in Fedora.
> >
> > The idea of maintaining 2 near identical specs & builds for all these
> > packages isn't that nice, particularly since many of these are security
> > sensitive packages
>
> So there's a bit of confusion going around, partly my own.
>
> Mingw-binutils (https://bugzilla.redhat.com/show_bug.cgi?id=454408)
> starts with a forked version of binutils maintained by mingw. They
> have their own release schedule for this so I'm not sure how viable it
> is to have a single binutils SPEC file generating both the normal
> binutils and a 'binutils-mingw' subpackage. (Ignoring for now whether
> or not the Fedora binutils maintainer is even interested in this).
>From my experience, using a unified spec is non-viable.

All it does is to add avoidable package deps and unnecessarily
complicates things, because a MinGW-binutils is widely independent from
Linux (and Fedora).

Furthermore, binutils is comparatively small, easy to package and easy
to maintain - GCC is a completely different matter.

> Mingw-gcc (https://bugzilla.redhat.com/show_bug.cgi?id=454410) starts
> from plain gcc 4.3.1 source, so combining these into Fedora's gcc
> package might be more hopeful.
I would not do this - MinGW is a different OS, suffers from different
issues and has a different upstream (RH-branch vs. FSF-trunk vs. MinGW
hacked GCC).

> However there are some nasty
> dependencies (mingw-runtime and mingw-w32api, neither of which can be
> built ab initio because of circular dependencies) and I suspect that
> any time there is any sort of mingw related trouble with this package,
> the gcc-mingw subpackage will be the first to be dropped. I don't
> want this.

> As for the remainder we get into asking question like -- should we
> generate the mingw-gnutls library (as an example) from the main gnutls
> SPEC file?
Same as above. I would not want to merge any MinGW package's specs with
Linux/Fedoras. They share a common upstream somewhere, but MinGW's
upstream isn't necessarily identical to Fedora.

> There are going to be dozens of such libraries and we'll
> have to coordinate with a large number of existing Fedora contributors
> to make this happen.
Only if you merge them. IMO, this is not useful for cross-toolchains,
because you actually will want to use their sources, not Fedoras.

For my own cross-toolchains, I even go one step further - I repackage a
cross-toolchain's library-binaries, and only build the cross-tools,
because only a target's binaries are guaranteed to be compatible with
the "native upstream".

Ralf


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, Jul 08, 2008 at 04:13:56PM +0100, Daniel P. Berrange wrote:
> This is where it gets non-scalable if we have a forked SPEC for every
> library we want to build for mingw. We need to make it easy for the
> maintainence of all the libs to be devolved to the existing maintainers
> of the libraries, preferably with little-to-no extra work for these
> maintainers. We shouldn't get into the world of maintaining two
> independant copies of things like GNUTLS, libpng, libvirt, etc.
>
> If we can get away with only having mingw custom packages for gcc,binutils,
> and the runtime, and then sub-RPM for all the other bits I'd be reasonably
> satisfied.

I think it's reasonable to have a 'sample' spec file snippet for
existing maintainers to use & modify when they feel they want to add
MinGW support. I'll give it a go with some existing libraries to see
what they would look like.

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 59 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, Jul 08, 2008 at 03:46:40PM +0100, Richard W.M. Jones wrote:
> On Tue, Jul 08, 2008 at 02:30:10PM +0100, Daniel P. Berrange wrote:
> > On Mon, Jul 07, 2008 at 10:15:54PM +0100, Richard W.M. Jones wrote:
> > > I've got a self-building, mostly working set of Fedora packages for
> > > the MinGW cross-compiler (no optional libraries yet). You can get the
> > > spec files and instructions by doing:
> > >
> > > hg clone http://hg.et.redhat.com/misc/fedora-mingw--devel
> >
> > What primarily concerns me is that plan around keeping this in sync
> > with patches/updates to the main gcc, binutils, libpng, libgcrypt,
> > gnutls, etc RPMS already in Fedora.
> >
> > The idea of maintaining 2 near identical specs & builds for all these
> > packages isn't that nice, particularly since many of these are security
> > sensitive packages
>
> So there's a bit of confusion going around, partly my own.
>
> Mingw-binutils (https://bugzilla.redhat.com/show_bug.cgi?id=454408)
> starts with a forked version of binutils maintained by mingw. They
> have their own release schedule for this so I'm not sure how viable it
> is to have a single binutils SPEC file generating both the normal
> binutils and a 'binutils-mingw' subpackage. (Ignoring for now whether
> or not the Fedora binutils maintainer is even interested in this)

It is rather a shame Mingw can't submit their changes upstream, or at
least provide patches against upstream rather than re-spinning the
entire tar.gz. But since that's the way they've done it I guess we
have no choice but to work with it as a forked package in the short
term.

> Mingw-gcc (https://bugzilla.redhat.com/show_bug.cgi?id=454410) starts
> from plain gcc 4.3.1 source, so combining these into Fedora's gcc
> package might be more hopeful. However there are some nasty
> dependencies (mingw-runtime and mingw-w32api, neither of which can be
> built ab initio because of circular dependencies) and I suspect that
> any time there is any sort of mingw related trouble with this package,
> the gcc-mingw subpackage will be the first to be dropped. I don't
> want this.

I must say the complexity of the existing GCC RPM in Fedora is pretty
scary, and more to the point seems to want pretty strict versions of
binutils which given the fork'ing of binutils by MinGW is a pain point.

> As for the remainder we get into asking question like -- should we
> generate the mingw-gnutls library (as an example) from the main gnutls
> SPEC file? There are going to be dozens of such libraries and we'll
> have to coordinate with a large number of existing Fedora contributors
> to make this happen.

This is where it gets non-scalable if we have a forked SPEC for every
library we want to build for mingw. We need to make it easy for the
maintainence of all the libs to be devolved to the existing maintainers
of the libraries, preferably with little-to-no extra work for these
maintainers. We shouldn't get into the world of maintaining two
independant copies of things like GNUTLS, libpng, libvirt, etc.

If we can get away with only having mingw custom packages for gcc,binutils,
and the runtime, and then sub-RPM for all the other bits I'd be reasonably
satisfied.

Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

"Richard W.M. Jones" <rjones@redhat.com> writes:

> [...] I said it's not a problem for the MinGW SIG (ie. Fedora), but
> it is a problem for the libvirt project.

So it is that important to you to permit someone to distribute
proprietary libvirt-based applications that run *on windows*?
Is providing this sort of enablement important to Fedora?

- FChE

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list