Re: Building and packaging Wine Gecko
On Tue, Dec 15, 2009 at 7:20 PM, Anssi Hannula an...@mandriva.org wrote: Apparently it is not easily possible (even if one could compile wine-gecko, .cab creation would be an obstacle). Therefore I've packaged the Wine provided prebuilt binary .cab as wine-gecko, and put it into the non-free repository (Cooker, and backports for 2010.0,2009.1,2009.0). Future builds and backports of Wine will contain a soft dependency (Suggests) on wine-gecko, thus installing it automatically if the non-free repository is available. -- Anssi Hannula To create CAB files in Linux, you need the lcab[1] utility. To extract CAB files, you need the cabextract[2] utility. [1]: http://ohnobinki.u.ohnopublishing.net/~ohnobinki/lcab/ [2]: http://www.cabextract.org.uk/
Re: Building and packaging Wine Gecko
On Fri, Dec 11, 2009 at 5:06 PM, Ove Kaaven o...@arcticnet.no wrote: Ben Klein skrev: Have you looked at my wine-gecko-1.0.0 package at the lamaresh.net repository? It's just the pre-packaged cab file stored in /usr/share/wine/gecko. That's the reason I'm not looking at it. I don't think I have seen any distribution include wine-gecko. Fedora seems to be in the best position to finally make a wine-gecko package, since it now provides a MinGW toolchain. I haven't used Mandriva in years, so I have no idea if Mandriva includes a full blown toolchain like Fedora does. If it does, you might want to look into using that toolchain to help make a package for wine-gecko.
Re: Building and packaging Wine Gecko
On Fri, Dec 11, 2009 at 5:37 PM, Ove Kaaven o...@arcticnet.no wrote: Sir Gallantmon skrev: I don't think I have seen any distribution include wine-gecko. Fedora seems to be in the best position to finally make a wine-gecko package, since it now provides a MinGW toolchain. Why does *that* put Fedora in the best position? Debian has had a MinGW toolchain for years, the building wine-gecko wiki page even mentions attempts to use it. Only problem with it is that it's not the newest version. Perhaps if you meant that Fedora also has built a whole bunch of libraries using mingw and packaged them as rpms, then that *might* give it an edge. Still won't make me ever use Fedora, though. Sorry, I think of the word toolchain differently I guess. I always considered a toolchain to include both tools and common libraries, as Fedora did. I was aware of the MinGW compiler offered in the Debian package repository, but with no libraries, I considered it useless.
Re: Building and packaging Wine Gecko
On Fri, Dec 11, 2009 at 9:07 PM, Ove Kaaven o...@arcticnet.no wrote: Sir Gallantmon skrev: Sorry, I think of the word toolchain differently I guess. I always considered a toolchain to include both tools and common libraries, as Fedora did. I was aware of the MinGW compiler offered in the Debian package repository, but with no libraries, I considered it useless. Well, to be fair, the libraries included with mingw32 include the whole Win32 API, including the standard C runtime (msvcrt). What more could you possibly need from a minimalist GNU for Windows compiler for it to be useful...? It almost certainly doesn't include the whole API set for Windows. It includes the minimal Win32 API, yes, but not all the Win32 APIs. I don't care for your bias on RPM based distros, so meh. I respect Debian's decision not to include common libraries under cross-arching, but I personally like the convenience that Fedora offers, especially given all the circular dependencies some of the libraries that Fedora provides would require if built from source.
Re: Wine sound discussion summary
On Sun, Dec 6, 2009 at 4:37 PM, Roderick Colenbrander thunderbir...@gmail.com wrote: On Sun, Dec 6, 2009 at 11:34 PM, Stefan Dösinger stefandoesin...@gmx.at wrote: Am 06.12.2009 um 23:21 schrieb Maarten Lankhorst: I wouldn't be surprised if this still was the case, we could keep the midi interfaces around and just report 0 wave in/out devices for oss/coreaudio/alsaa once we complete wine7audio.drv. So you mean keeping the existing infrastructure around just for midi and have something entirely different for the rest of the audio features? Apparently winmm is still the only way to do MIDI on Windows Vista, and if winmm uses wasapi and friends there must be some way to tell the devices to talk to MIDI instruments. I mainly wonder how Vista is able to sync MIDI with audio playback? I would say that's an important feature e.g. be able to enable light effects on a podium in sync with the music you play from your computer. Roderick DirectMusic is the other way to work with MIDI I think.
Re: dual platform win32/linux malware
On Mon, Nov 30, 2009 at 8:53 PM, Dan Kegel d...@kegel.com wrote: The apocalypse approaches: http://ask.slashdot.org/article.pl?sid=09/12/01/0025213 Perhaps this will drive people towards using totally locked down systems... Or just cause more insanity
Re: Running server applications under Wine?
On Fri, Nov 20, 2009 at 11:07 AM, Dan Kegel d...@kegel.com wrote: 임은지 wrote: What do you think about implementing wineserver kernel module or handling only performance critical items in kernel? There has long been talk of doing that. Linus is even willing to take patches to implement win32 APIs in the linux kernel. But it turns out to not be what most people need. If you want to do some server performance stress testing and file bugs for problems you find, by all means, go ahead! - Dan What do you mean by that? Wouldn't it be a good idea to be able to support some parts of Wine in the kernel level to be more efficient?
Re: Running server applications under Wine?
On Fri, Nov 20, 2009 at 12:11 PM, Dan Kegel d...@kegel.com wrote: On Fri, Nov 20, 2009 at 9:57 AM, Sir Gallantmon ngomp...@gmail.com wrote: On Fri, Nov 20, 2009 at 11:07 AM, Dan Kegel d...@kegel.com wrote: What do you think about implementing wineserver kernel module or handling only performance critical items in kernel? There has long been talk of doing that. Linus is even willing to take patches to implement win32 APIs in the linux kernel. But it turns out to not be what most people need. What do you mean by that? Wouldn't it be a good idea to be able to support some parts of Wine in the kernel level to be more efficient? Of course. It's just hard, and it isn't needed for the things we tend to use Wine for at the moment. Somebody actually had a shot at implementing this back in 2000, see http://lwn.net/2000/0914/a/lt-wine.php3 And that work lives on, it seems, as a part of http://en.wikipedia.org/wiki/Linux_Unified_Kernel So go try it out if you like (although I'm not sure how safe it is for production). I think the Wine team doesn't need to worry about that stuff; we have our hands full just making the win32 userland work well. - Dan I would think that maybe the work Wine does for Direct3D could be moved into a state tracker for Gallium, that way it shouldn't be necessary to convert from Direct3D to OpenGL to make it work. I doubt Direct3D and OpenGL include equivalents for everything, so it might be a good idea to have for a SoC project to hook up Wine's D3D implementation into Gallium.
