Tom "spot" Callaway wrote:

The next Fedora Packaging Committee Meeting will be held on Tuesday,
July 22, 2008. (Note: Normally, the FPC meets every other week, but this
meeting was scheduled since we did not have quorum on July 15, 2008)

Meeting time is at 17:00 UTC. FPC members, please try to be on-time, as
the Fedora Board meets at 18:00 UTC.

Items scheduled to be discussed:

Python virtual Provides: PackagingDrafts/Python
Haskell: PackagingDrafts/Haskell
Font bundles amendement to Fonts policy:
PackagingDrafts/Packaging_font_bundles
Lisp: PackagingDrafts/Lisp


As a reminder, the process for getting items onto the FPC's agenda is
documented here:
http://fedoraproject.org/wiki/Packaging/Committee#Guideline_Change_Procedure



Wat is the plan with this meeting, is it going through ? I'm asking
because there have been some cancellations so I wonder how usefull it is
to get together. I'll be there this time, sorry for missing the last few
times.


Regards,

Hans

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

On Mon, Jul 21, 2008 at 01:22:09PM -0400, Tom spot Callaway wrote:
> Again, to reiterate, the Board simply said that it was in support of
> MinGW in Fedora, but it should be separated, and that FESCo should
> handle the technical specifics.

What is the board's rationale for putting MinGW packages in a separate
repository, when other cross-compiler toolchain (eg ARM) are in the main
Fedora repository. Seems to me like we're penalizing MinGW just
because it happens to be related to Windows, even though MinGW's code
is still just as open source as anything else in our repos.

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-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Tue, 2008-07-22 at 10:29 +0100, Daniel P. Berrange wrote:
> What is the board's rationale for putting MinGW packages in a separate
> repository, when other cross-compiler toolchain (eg ARM) are in the main
> Fedora repository. Seems to me like we're penalizing MinGW just
> because it happens to be related to Windows, even though MinGW's code
> is still just as open source as anything else in our repos.

Actually I think the prevailing thought that the Board has (although
it's up to FESCo to really nail it down) is that the mingw tools
themselves are absolutely suitable for Fedora. The libraries compiled
against it for windows use are what should be in another repo.

My personal opinion is that if you're going to need to munge spec files
in order to produce packages built against mingw, those munges need to
be done outside our cvs repo as well.

However that's just my opinion, and since the board has asked FESCo to
sort out the technical details, and I'm not in FESCo anymore, that
opinion doesn't amount to much (:

--
Jesse Keating
Fedora -- Freedom² is a feature!
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Tue, Jul 22, 2008 at 08:06:59AM -0400, Jesse Keating wrote:
> On Tue, 2008-07-22 at 10:29 +0100, Daniel P. Berrange wrote:
> > What is the board's rationale for putting MinGW packages in a separate
> > repository, when other cross-compiler toolchain (eg ARM) are in the main
> > Fedora repository. Seems to me like we're penalizing MinGW just
> > because it happens to be related to Windows, even though MinGW's code
> > is still just as open source as anything else in our repos.
>
> Actually I think the prevailing thought that the Board has (although
> it's up to FESCo to really nail it down) is that the mingw tools
> themselves are absolutely suitable for Fedora. The libraries compiled
> against it for windows use are what should be in another repo.

[I'm going to prepare something more detailed, hopefully integrating
efforts with the cross-compiler folks, but just on these two points ...]

If we ship only the four base packages (mingw-gcc, mingw-binutils,
mingw-w32api and mingw-runtime) then the only software that can be
compiled is software which doesn't use any libraries. That's pretty
restrictive.

To compile, for example, libvirt, one needs six other libraries. As
with Linux, you need the library around (foo-0.dll) in order to link.
Anyone compiling libvirt would need to download the source for each of
these six libraries and './configure --host=i686-pc-mingw32 ; make ;
make install' before they could start on libvirt, and of course it
isn't really that simple since those libraries don't all just
cross-compile without needing tweaks and patches. Tweaks and patches
are what spec files are for. This is why we'd like to ship
pre-compiled DLLs (only) of those six libs.

I think people have somehow got the impression we want to (a) ship
FIREFOX.EXE and/or (b) cross-compile every library in Fedora. I'd
like to say that (a) is not our intention, ever, and (b) isn't even
technically possible, nevermind that it is completely undesirable.

> My personal opinion is that if you're going to need to munge spec files
> in order to produce packages built against mingw, those munges need to
> be done outside our cvs repo as well.

There are two ways that we've proposed that one could build
'mingw-gnutls'. One is as a completely separate package, another is
as a subpackage of the ordinary gnutls. I investigated and built
packages both ways (see links below) just to see what was technically
feasible. It turns out that both methods are *technically* feasible.
Which is better from technical, organizational or political points of
view is a completely different question.

http://hg.et.redhat.com/misc/fedora-mingw--devel/?cmd=manifest;manifest=91a808c59de63589367c7bd9750 da1fca342c529;path=/gnutls/
http://hg.et.redhat.com/misc/fedora-mingw--devel/?cmd=manifest;manifest=91a808c59de63589367c7bd9750 da1fca342c529;path=/gnutls-fragment/

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-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

Richard W.M. Jones wrote:

On Tue, Jul 22, 2008 at 08:06:59AM -0400, Jesse Keating wrote:

On Tue, 2008-07-22 at 10:29 +0100, Daniel P. Berrange wrote:

What is the board's rationale for putting MinGW packages in a separate
repository, when other cross-compiler toolchain (eg ARM) are in the main
Fedora repository. Seems to me like we're penalizing MinGW just
because it happens to be related to Windows, even though MinGW's code
is still just as open source as anything else in our repos.

Actually I think the prevailing thought that the Board has (although
it's up to FESCo to really nail it down) is that the mingw tools
themselves are absolutely suitable for Fedora. The libraries compiled
against it for windows use are what should be in another repo.


[I'm going to prepare something more detailed, hopefully integrating
efforts with the cross-compiler folks, but just on these two points ...]

If we ship only the four base packages (mingw-gcc, mingw-binutils,
mingw-w32api and mingw-runtime) then the only software that can be
compiled is software which doesn't use any libraries. That's pretty
restrictive.

To compile, for example, libvirt, one needs six other libraries. As
with Linux, you need the library around (foo-0.dll) in order to link.
Anyone compiling libvirt would need to download the source for each of
these six libraries and './configure --host=i686-pc-mingw32 ; make ;
make install' before they could start on libvirt, and of course it
isn't really that simple since those libraries don't all just
cross-compile without needing tweaks and patches. Tweaks and patches
are what spec files are for. This is why we'd like to ship
pre-compiled DLLs (only) of those six libs.

When people talk about a separate repo, it's something that would still
allow this workflow to happen. The separate repo exists on the Fedora
master mirror but mirrors of us have the option to include or exclude
these other repos depending on their ability to carry the extra packages.


This separate repo will have a yum configuration file that I think
should be shipped by default. I think it should also be turned on by
default. This would make the fact that there is a different repo for
the packages transparent to end users. (However, this portion is
something that FESCo decides, not FPC... this case would need to be
argued in front of FESCo).



I think people have somehow got the impression we want to (a) ship
FIREFOX.EXE and/or (b) cross-compile every library in Fedora. I'd
like to say that (a) is not our intention, ever, and (b) isn't even
technically possible, nevermind that it is completely undesirable.

Who is "we"? That is the crux of your statements. If a group of Fedora
contributors who are not the libvirt team decide that they want to have
a complete cross-compilation environment to be able to build firefox.exe
for windows under Fedora at some point in the future, I'd like us to
not stand in their way. OTOH, even if that never happens, there is
still the issue that MingW is not the only crosscompilation system that
we want in Fedora. To scale across architectures as well as in depth on
one os-architecture also has an impact on mirrors which can be mitigated
by having a separate repo.



My personal opinion is that if you're going to need to munge spec files
in order to produce packages built against mingw, those munges need to
be done outside our cvs repo as well.


There are two ways that we've proposed that one could build
'mingw-gnutls'. One is as a completely separate package, another is
as a subpackage of the ordinary gnutls. I investigated and built
packages both ways (see links below) just to see what was technically
feasible. It turns out that both methods are *technically* feasible.
Which is better from technical, organizational or political points of
view is a completely different question.

This is partially a FPC issue and partially a FESCo/Board issue. The
four people present for the FPC meeting last week discussed this
informally and there was consensus that separate packging made more
sense. However, FESCo will need to decide how having a separate
download repository maps to our cvs repository. The two options I see
are separate packages (as discussed by FPC) and separate branches within
CVS. Which one is decided will have some influence over any eventual
Guidelines that the FPC writes and/or approves.


-Toshio

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

On Tue, 2008-07-22 at 17:22 +0100, Richard W.M. Jones wrote:
> On Tue, Jul 22, 2008 at 08:06:59AM -0400, Jesse Keating wrote:
> > On Tue, 2008-07-22 at 10:29 +0100, Daniel P. Berrange wrote:
> > > What is the board's rationale for putting MinGW packages in a separate
> > > repository, when other cross-compiler toolchain (eg ARM) are in the main
> > > Fedora repository. Seems to me like we're penalizing MinGW just
> > > because it happens to be related to Windows, even though MinGW's code
> > > is still just as open source as anything else in our repos.
> >
> > Actually I think the prevailing thought that the Board has (although
> > it's up to FESCo to really nail it down) is that the mingw tools
> > themselves are absolutely suitable for Fedora. The libraries compiled
> > against it for windows use are what should be in another repo.
>
> [I'm going to prepare something more detailed, hopefully integrating
> efforts with the cross-compiler folks, but just on these two points ...]
>
> If we ship only the four base packages (mingw-gcc, mingw-binutils,
> mingw-w32api and mingw-runtime) then the only software that can be
> compiled is software which doesn't use any libraries. That's pretty
> restrictive.
This is way too restrictive. In fact, such a restriction closes out
any cross-toolchain from Fedora.

> > My personal opinion is that if you're going to need to munge spec files
> > in order to produce packages built against mingw, those munges need to
> > be done outside our cvs repo as well.
Building cross-toolchains inevitably needs some target-libraries. If you
want to see cross-toolchain packages in Fedora, these target-libraries
must be shipped as part of Fedora.

Ralf


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

On Tuesday, 15 July 2008 at 19:25, Tom spot Callaway wrote:
> The next Fedora Packaging Committee Meeting will be held on Tuesday,
> July 22, 2008. (Note: Normally, the FPC meets every other week, but this
> meeting was scheduled since we did not have quorum on July 15, 2008)
>
> Meeting time is at 17:00 UTC. FPC members, please try to be on-time, as
> the Fedora Board meets at 18:00 UTC.

I couldn't make it, again, and I'm sorry. The current meeting time is consistently
overlapping with my sport activities which can't be rescheduled. That time
might change after the vacations are over, but I won't know until then.
I'd very much like to change that meeting time or step down from FPC if that's
not possible. I don't see any point in being on the Committee if I can't attend
the meetings.

Moreover, I'm on vacation for the most of August and will only have Internet
connectivity via a cellphone, if at all, and that's expensive, so I'll
be limiting it as much as possible.

Regards,
R.

--
Fedora http://fedoraproject.org/wiki/User:Rathann
Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

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