Fedora 11 is nearly in beta, and thanks to some judicious cuts at the end, we made it to 100% feature complete. Thanks to the many people who helped out reviewing packages and testing.
What do we want to aim for in Fedora 12?
Some ideas - please add your own to this thread.
(1) Win64 support (see: http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-February/thread.h... )
(2)? Use mingw-w64 project to build 32 bit w32api/runtime, since mingw-w64 seems to be more active.
(3) Darwin / OS X support (see: https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00397.html )
(4) Get some of the issues resolved in the packaging guidelines: http://fedoraproject.org/wiki/MinGW/Packaging_issues
(5) Expand active members, particularly packagers. I would like to start by having a website which doesn't suck like our current one.
(6) Move educational materials to a single place.
(7) Have a FAQ.
(8) I'd like to have a reasonable Python story. I spent a lot of time trying to get Python and Python libs to cross-compile, without any success.
Rich.
On Fri, Mar 13, 2009 at 02:25:35PM +0100, Kevin Kofler wrote:
Richard W.M. Jones wrote:
(2)? Use mingw-w64 project to build 32 bit w32api/runtime, since mingw-w64 seems to be more active.
They're still missing some stuff though, e.g. the DDK headers.
Does anything support DDK (eg. current MinGW 32 bit)?
I don't really know much about this, but I do know that many people have asked if we can compile device drivers. This would be very useful for virt, for example (to compile virtio drivers for Windows).
Rich.
On Fri, Mar 13, 2009 at 9:41 AM, Richard W.M. Jones rjones@redhat.com wrote:
On Fri, Mar 13, 2009 at 02:25:35PM +0100, Kevin Kofler wrote:
Richard W.M. Jones wrote:
(2)? Use mingw-w64 project to build 32 bit w32api/runtime, since mingw-w64 seems to be more active.
They're still missing some stuff though, e.g. the DDK headers.
Does anything support DDK (eg. current MinGW 32 bit)?
I don't really know much about this, but I do know that many people have asked if we can compile device drivers. This would be very useful for virt, for example (to compile virtio drivers for Windows).
Rich.
We aren't missing directx-x stuff. They just aren't in the trunk, they're in the experimental area. The reason for this is that they were copied from Wine. If you want directx, you can either get the DDK and use it directly, or use what's from Wine, or use what we copied from Wine.
On Fri, Mar 13, 2009 at 09:47:04AM -0400, NightStrike wrote:
On Fri, Mar 13, 2009 at 9:41 AM, Richard W.M. Jones rjones@redhat.com wrote:
On Fri, Mar 13, 2009 at 02:25:35PM +0100, Kevin Kofler wrote:
Richard W.M. Jones wrote:
(2)? Use mingw-w64 project to build 32 bit w32api/runtime, since mingw-w64 seems to be more active.
They're still missing some stuff though, e.g. the DDK headers.
Does anything support DDK (eg. current MinGW 32 bit)?
I don't really know much about this, but I do know that many people have asked if we can compile device drivers. This would be very useful for virt, for example (to compile virtio drivers for Windows).
Rich.
We aren't missing directx-x stuff. They just aren't in the trunk, they're in the experimental area. The reason for this is that they were copied from Wine. If you want directx, you can either get the DDK and use it directly, or use what's from Wine, or use what we copied from Wine.
Can you explain what the different TLAs mean? DDK, etc?
As I say I don't know much about this stuff.
Rich.
On Fri, Mar 13, 2009 at 9:50 AM, Richard W.M. Jones rjones@redhat.com wrote:
On Fri, Mar 13, 2009 at 09:47:04AM -0400, NightStrike wrote:
On Fri, Mar 13, 2009 at 9:41 AM, Richard W.M. Jones rjones@redhat.com wrote:
On Fri, Mar 13, 2009 at 02:25:35PM +0100, Kevin Kofler wrote:
Richard W.M. Jones wrote:
(2)? Use mingw-w64 project to build 32 bit w32api/runtime, since mingw-w64 seems to be more active.
They're still missing some stuff though, e.g. the DDK headers.
Does anything support DDK (eg. current MinGW 32 bit)?
I don't really know much about this, but I do know that many people have asked if we can compile device drivers. This would be very useful for virt, for example (to compile virtio drivers for Windows).
Rich.
We aren't missing directx-x stuff. They just aren't in the trunk, they're in the experimental area. The reason for this is that they were copied from Wine. If you want directx, you can either get the DDK and use it directly, or use what's from Wine, or use what we copied from Wine.
Can you explain what the different TLAs mean? DDK, etc?
As I say I don't know much about this stuff.
Well actually, Kai just pointed out to me that I misread the original email. I thought he was talking about the directx SDK, not the Driver Development Kit (http://en.wikipedia.org/wiki/Windows_Driver_Kit). Too many acronyms, too little sleep :)
NightStrike wrote:
We aren't missing directx-x stuff. They just aren't in the trunk, they're in the experimental area. The reason for this is that they were copied from Wine. If you want directx, you can either get the DDK and use it directly, or use what's from Wine, or use what we copied from Wine.
DDK is the Device Development Kit, it has nothing to do with DirectX.
Kevin Kofler
Richard W.M. Jones wrote:
Does anything support DDK (eg. current MinGW 32 bit)?
I don't really know much about this, but I do know that many people have asked if we can compile device drivers. This would be very useful for virt, for example (to compile virtio drivers for Windows).
32-bit MinGW has some support for device driver development contributed by the ReactOS folks. At least some simple drivers can compile with it. I'm not sure how complete it is though. And unfortunately there's no 64-bit support, which is definitely needed for device drivers because you can't run a 32-bit device driver on a 64-bit OS. (That said, with 64-bit drivers there's also the problem that 64-bit Vista requires signed drivers unless you manually choose a boot option every single time you boot - every available method to automate this has been removed.)
Kevin Kofler
On Fri, Mar 13, 2009 at 02:54:34PM +0100, Kevin Kofler wrote:
(That said, with 64-bit drivers there's also the problem that 64-bit Vista requires signed drivers unless you manually choose a boot option every single time you boot - every available method to automate this has been removed.)
Nice ... and will whoever signs drivers sign ones developed using free software?
Rich.
2009/3/13 Richard W.M. Jones rjones@redhat.com:
On Fri, Mar 13, 2009 at 02:54:34PM +0100, Kevin Kofler wrote:
(That said, with 64-bit drivers there's also the problem that 64-bit Vista requires signed drivers unless you manually choose a boot option every single time you boot - every available method to automate this has been removed.)
Nice ... and will whoever signs drivers sign ones developed using free software?
Rich.
For signing (as for 32-bit and 64-bit) you sadly need the ms tools to do so. But of course it should work.
Kai
Kai Tietz wrote:
For signing (as for 32-bit and 64-bit) you sadly need the ms tools to do so. But of course it should work.
The problem is that if you sign things yourself with a test key, it won't be much more helpful for distributing it than not signing it at all. The drivers need to be signed by M$ for users to be able to install them without convoluted workarounds (and without losing HD video support, too).
Kevin Kofler
2009/3/13 Kevin Kofler kevin.kofler@chello.at:
Richard W.M. Jones wrote:
Does anything support DDK (eg. current MinGW 32 bit)?
I don't really know much about this, but I do know that many people have asked if we can compile device drivers. This would be very useful for virt, for example (to compile virtio drivers for Windows).
32-bit MinGW has some support for device driver development contributed by the ReactOS folks. At least some simple drivers can compile with it. I'm not sure how complete it is though. And unfortunately there's no 64-bit support, which is definitely needed for device drivers because you can't run a 32-bit device driver on a 64-bit OS. (That said, with 64-bit drivers there's also the problem that 64-bit Vista requires signed drivers unless you manually choose a boot option every single time you boot - every available method to automate this has been removed.)
We are staying in contact to ReactOS. They offered us to use their ported DDK package (yes, it has 64-bit capabilities). Things are getting stucked, because they try to find some authors of some files in the package, to re-license it to PD. Otherwise we can't put them into our base header-set, because we won't use GPLed code here.
Cheers, Kai
Richard W.M. Jones wrote:
Fedora 11 is nearly in beta, and thanks to some judicious cuts at the end, we made it to 100% feature complete. Thanks to the many people who helped out reviewing packages and testing.
What do we want to aim for in Fedora 12?
Some ideas - please add your own to this thread.
(1) Win64 support (see: http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-February/thread.h... )
yes.
(2)? Use mingw-w64 project to build 32 bit w32api/runtime, since mingw-w64 seems to be more active.
we can still use mingw32 until mingw-64 will be ready to switch and the changes can be done in the background.
(3) Darwin / OS X support (see: https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00397.html )
yes (if won't have license problems)
(4) Get some of the issues resolved in the packaging guidelines: http://fedoraproject.org/wiki/MinGW/Packaging_issues
imho we can write packaging guide for CC as an f12 feature and we can start a discussion about it.
(9) gstreamer support. we already working on it, but it's not too easy:-(
On Fri, Mar 13, 2009 at 10:11 AM, Farkas Levente lfarkas@lfarkas.org wrote:
(2)? Use mingw-w64 project to build 32 bit w32api/runtime, since mingw-w64 seems to be more active.
we can still use mingw32 until mingw-64 will be ready to switch and the changes can be done in the background.
We're ready now :)
NightStrike wrote:
On Fri, Mar 13, 2009 at 10:11 AM, Farkas Levente lfarkas@lfarkas.org wrote:
(2)? Use mingw-w64 project to build 32 bit w32api/runtime, since mingw-w64 seems to be more active.
we can still use mingw32 until mingw-64 will be ready to switch and the changes can be done in the background.
We're ready now :)
ok:-) then wouldn't it be useful for everybody to megre mingw32 with mingw64. or at least start the process...
On Fri, Mar 13, 2009 at 03:30:21PM +0100, Farkas Levente wrote:
NightStrike wrote:
On Fri, Mar 13, 2009 at 10:11 AM, Farkas Levente lfarkas@lfarkas.org wrote:
(2)? Use mingw-w64 project to build 32 bit w32api/runtime, since mingw-w64 seems to be more active.
we can still use mingw32 until mingw-64 will be ready to switch and the changes can be done in the background.
We're ready now :)
ok:-) then wouldn't it be useful for everybody to megre mingw32 with mingw64. or at least start the process...
I talked to NightStrike about this already, and said basically nothing will get done until Fedora 11 is released. This thread is for planning what happens *after* that.
Rich.
Richard W.M. Jones wrote:
On Fri, Mar 13, 2009 at 03:30:21PM +0100, Farkas Levente wrote:
NightStrike wrote:
On Fri, Mar 13, 2009 at 10:11 AM, Farkas Levente lfarkas@lfarkas.org wrote:
(2)? Use mingw-w64 project to build 32 bit w32api/runtime, since mingw-w64 seems to be more active.
we can still use mingw32 until mingw-64 will be ready to switch and the changes can be done in the background.
We're ready now :)
ok:-) then wouldn't it be useful for everybody to megre mingw32 with mingw64. or at least start the process...
I talked to NightStrike about this already, and said basically nothing will get done until Fedora 11 is released. This thread is for planning what happens *after* that.
i mean above that the upstream mingw32 and mingw64 merge.
On Fri, Mar 13, 2009 at 12:36 PM, Farkas Levente lfarkas@lfarkas.org wrote:
Richard W.M. Jones wrote:
On Fri, Mar 13, 2009 at 03:30:21PM +0100, Farkas Levente wrote:
NightStrike wrote:
On Fri, Mar 13, 2009 at 10:11 AM, Farkas Levente lfarkas@lfarkas.org wrote:
(2)? Use mingw-w64 project to build 32 bit w32api/runtime, since mingw-w64 seems to be more active.
we can still use mingw32 until mingw-64 will be ready to switch and the changes can be done in the background.
We're ready now :)
ok:-) then wouldn't it be useful for everybody to megre mingw32 with mingw64. or at least start the process...
I talked to NightStrike about this already, and said basically nothing will get done until Fedora 11 is released. This thread is for planning what happens *after* that.
i mean above that the upstream mingw32 and mingw64 merge.
Any chance of improving support for mingw-w64?
On Mon, Mar 15, 2010 at 11:32:20AM -0400, NightStrike wrote:
On Fri, Mar 13, 2009 at 12:36 PM, Farkas Levente lfarkas@lfarkas.org wrote:
Richard W.M. Jones wrote:
On Fri, Mar 13, 2009 at 03:30:21PM +0100, Farkas Levente wrote:
NightStrike wrote:
On Fri, Mar 13, 2009 at 10:11 AM, Farkas Levente lfarkas@lfarkas.org wrote:
> (2)? Use mingw-w64 project to build 32 bit w32api/runtime, since > mingw-w64 seems to be more active. we can still use mingw32 until mingw-64 will be ready to switch and the changes can be done in the background.
We're ready now :)
ok:-) then wouldn't it be useful for everybody to megre mingw32 with mingw64. or at least start the process...
I talked to NightStrike about this already, and said basically nothing will get done until Fedora 11 is released. This thread is for planning what happens *after* that.
i mean above that the upstream mingw32 and mingw64 merge.
Any chance of improving support for mingw-w64?
I'm afraid we're still waiting for someone to audit those header files.
Rich.
On Fri, Mar 13, 2009 at 03:11:24PM +0100, Farkas Levente wrote:
(9) gstreamer support. we already working on it, but it's not too easy:-(
Have you got any candidate packages for this? What does it involve?
Rich.
Richard W.M. Jones wrote:
On Fri, Mar 13, 2009 at 03:11:24PM +0100, Farkas Levente wrote:
(9) gstreamer support. we already working on it, but it's not too easy:-(
Have you got any candidate packages for this? What does it involve?
we've got a few but as i don't have time to look into them i'd not like to share them. first i'd like to review they are very experimental. unfortunately gstreamer has a lots of dependencies:-( and most of he has problems to compile on windows...
-
Farkas Levente -
Kai Tietz -
Kevin Kofler -
NightStrike -
Richard W.M. Jones