I'm requesting to add/update wine port for amd64 I'm not sure if this should be as separate port wine-amd64 (as other similar ports). Already compiled binaries in package format: http://people.freebsd.org/~ivoras/wine/ Patches: http://drop.io/wine_fbsd64 Link to the thread: http://forums.freebsd.org/showthread.php?t=18797 What are the steps to release wine port for amd64?
The correct way to do this is to create the port and submit it for inclusion to the ports collection. If you can't do that yourself, the you can try to find or hire someone to do it for you. There are mailing lists where you can communicate about that. PR database is not the best medium for the wishlists. -- Andriy Gapon
Responsible Changed From-To: freebsd-amd64->gerald Make this a ports PR and assign.
Responsible Changed From-To: gerald->ports I won't have time to work on this anytime soon, and the approach in the patch looks way, way too messy for my taste. I will be happy to support a volunteer and possibly make changes to emulators/wine along these lines, but from what I can tell this is not material for that regular port (yet).
Responsible Changed From-To: ports->freebsd-ports-bugs Canonicalize assignment.
Addendum: I believe doing this with a specific port for amd64, at least initially is a good idea, and making this a slave port of emulators/wine so that things like constantly changing pkg-plist and general updates come for free. I am also happy to make adjustments to that port, as long as the "uglier" pieces remain in the slave port itself. Gerald k
I'm the auther of the patches referenced in this PR. The main objective of those patches are to: - include all 32bit libraries in the package so it can run standalone in an amd64 system. - ensure all binaries have the proper library paths set (FreeBSD doesn't appear to realise the binaries are 32bit and uses 64bit libaries). I do not know of a way to build the port in an amd64 environment since FreeBSD does not support cross compiling from amd64 to i386. So under amd64 the port is package only. The patches and packages are now hosted at http://mediafire.com/wine_fbsd64 .
On Mon, 29 Nov 2010, David Naylor wrote: > The patches and packages are now hosted at > http://mediafire.com/wine_fbsd64 . I had a closer look, and this is really a cool hack. The problem is that FreeBSD lacks support for mixed 64-bit/32-bit environments, and this approach, among others, would not get (security) updates in one of the basic libraries used; it is the equivalent of static linking. If there is a way to move most of the code into the slave port and have fewer changes to emulators/wine itself, I'd be open to consder those.
On Sunday 02 January 2011 13:08:48 Gerald Pfeifer wrote: > On Mon, 29 Nov 2010, David Naylor wrote: > > The patches and packages are now hosted at > > http://mediafire.com/wine_fbsd64 . > > I had a closer look, and this is really a cool hack. The problem is > that FreeBSD lacks support for mixed 64-bit/32-bit environments, and > this approach, among others, would not get (security) updates in one > of the basic libraries used; it is the equivalent of static linking. I never thought of it that way but yes, you are right. I rebuild everything so updates should propergate every wine release (~ every two weeks). Maybe it would be easier to get wine to statically link? > If there is a way to move most of the code into the slave port and > have fewer changes to emulators/wine itself, I'd be open to consder > those. I have attempted to do just that. See attached for the patch. I have compile tested the patch (for wine and wine-fbsd64) and wine-fbsd64 produce the same list of files for packaging. Currently the wine-fbsd64 port is i386 only. I have considered a method of getting the port to work under amd64: by using the package produced from the i386 build. Is there any interest in that? Any ideas on how to do that?
On Thu, 6 Jan 2011, David Naylor wrote: > I never thought of it that way but yes, you are right. I rebuild > everything so updates should propergate every wine release (~ every > two weeks). Maybe it would be easier to get wine to statically link? That does not strike me as desirable, both in terms of security but als general updates (or stability) as well as resource usage. The only real fix is for FreeBSD to start handling a 32-bit environment on a 64-bit platform as well as several Linux distributions have been doing for about a decade. > Currently the wine-fbsd64 port is i386 only. I have considered a method > of getting the port to work under amd64: by using the package produced > from the i386 build. Is there any interest in that? Any ideas on how > to do that? Sadly that exceeds my area of expertise. I will look into your patch and see whether/how I can feel comfortable adjusting the general wine port to support your efforts. Gerald
-CONFIGURE_ARGS= --datadir=${DATADIR} --verbose --disable-tests \ +CONFIGURE_ARGS+= --datadir=${DATADIR} --verbose --disable-tests \ I will include this as part of my next update for the wine port. +CONFLICTS?= wine-fbsd64.* +.if !defined(USE_LDCONFIG32) USE_LDCONFIG= ${PREFIX}/lib ${PREFIX}/lib/wine +.endif +WINELIBDIR?= ${PREFIX}/lib Shouldn't WINELIBDIR be defined first and then used for USE_LDCONFIG? I will include this as part of my next update for the wine port, and also the other changes around WINELIBDIR. -post-install: +# This target allows hooks for wine-fbsd64 +.if !target(post-install-wine) +post-install-wine: +.endif Does this have to be in emulators/wine, or is there a way to handle this from a slave port? That definitely would be my preference. --- /usr/ports/emulators/wine/files/binbounce 1970-01-01 02:00:00.000000000 +0200 +++ wine/files/binbounce 2011-01-01 12:32:55.000000000 +0200 Ugh, does _this_ need to become part of emulators/wine? --- /usr/ports/emulators/wine-fbsd64/Makefile 1970-01-01 02:00:00.000000000 +0200 +++ wine-fbsd64/Makefile 2011-01-07 23:14:50.000000000 +0200 +USE_LDCONFIG32= ${PREFIX}/lib32 ${PREFIX}/lib32/wine +WINELIBDIR= ${PREFIX}/lib32 Shouldn't USE_LDCONFIG32 use WINELIBDIR instead of repeating the stuff? post-install-wine: is really brutal; I'd hope FreeBSD will gain proper combined 32-/64-bit support at one point. Gerald
On Mon, 31 Jan 2011, David Naylor wrote: >> Shouldn't USE_LDCONFIG32 use WINELIBDIR instead of repeating the >> stuff? > Agreed. Looking into the patch, I believe we can avoid the introduction of WINE_SLAVE_BUILD by making this .if !defined(USE_LDCONFIG32) USE_LDCONFIG= ${WINELIBDIR} ${WINELIBDIR}/wine .endif and will give it a try. Also, do we really need the CONFLICTS? emulators/wine is ONLY_FOR_ARCHS=i386, whereas your port is for AMD64 only. >> post-install-wine: is really brutal; I'd hope FreeBSD will gain >> proper combined 32-/64-bit support at one point. > Agreed but I do not think there is sufficient demand to warrant the > effort. I suspect an approach similar to this one will suffice for > the few ports that are required to run under amd64. As time goes by, 32-bit support in a 64-bit OS becomes less important. It has been hugely important for customer in $DAYJOB, and I would not underestimate the amount of 32-bit legacy applications out there. Gerald
gerald 2011-02-06 14:58:27 UTC FreeBSD ports repository Modified files: emulators/wine Makefile Log: Make CONFIGURE_ARGS overridable for slave ports. Introduce and use WINELIBDIR. [1] Set USE_LDCONFIG only if USE_LDCONFIG32 has not been set (which would indicate this being used by the amd64 child port). All of this is in support of the amd64 child port. Submitted by: David Naylor <naylor.b.david@gmail.com> [1] PR: 151747 Feature safe: yes Revision Changes Path 1.362 +7 -4 ports/emulators/wine/Makefile _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
On Sunday 06 February 2011 16:31:14 Gerald Pfeifer wrote: > On Mon, 31 Jan 2011, David Naylor wrote: > >> Shouldn't USE_LDCONFIG32 use WINELIBDIR instead of repeating the > >> stuff? > > > > Agreed. > > Looking into the patch, I believe we can avoid the introduction of > WINE_SLAVE_BUILD by making this > > .if !defined(USE_LDCONFIG32) > USE_LDCONFIG= ${WINELIBDIR} ${WINELIBDIR}/wine > .endif > > and will give it a try. Yes, that is the way I originally did it but I felt WINE_SLAVE_BUILD was less cryptic. Either way is fine for me. > Also, do we really need the CONFLICTS? emulators/wine is > ONLY_FOR_ARCHS=i386, whereas your port is for AMD64 only. Actually, wine-fbsd64 is also ONLY_FOR_ARCHS=i386. Since FreeBSD does not support cross building ports this port has to be built in an i386 environment. This port does run in an i386 environment. The only way I know of to deliver an amd64 port is to use binary packages. The intention of this port is for those who want to build wine/i386 that will work with FreeBSD/amd64 (using the patches I have provided), and since it is fairly easy to build an i386 chroot this will greatly reduce the complexity. > >> post-install-wine: is really brutal; I'd hope FreeBSD will gain > >> proper combined 32-/64-bit support at one point. > > > > Agreed but I do not think there is sufficient demand to warrant the > > effort. I suspect an approach similar to this one will suffice for > > the few ports that are required to run under amd64. > > As time goes by, 32-bit support in a 64-bit OS becomes less important. > It has been hugely important for customer in $DAYJOB, and I would not > underestimate the amount of 32-bit legacy applications out there. > > Gerald
Just some random comments from the sidelines: Please don't name the port wine-fbsd64 as it is *not* a port for 64bit FreeBSD platforms, but for amd64 *only*. It would be best to name it wine-amd64 if it is the one package that amd64 users should install (I know that there are i386 binaries inside it ... tricky). Also, a blue bikeshed would be nice :)
On Sun, 6 Feb 2011, David Naylor wrote: > Actually, wine-fbsd64 is also ONLY_FOR_ARCHS=i386. Since FreeBSD does > not support cross building ports this port has to be built in an i386 > environment. This port does run in an i386 environment. The only way I > know of to deliver an amd64 port is to use binary packages. You're right. I explicitly preapprove the addition of whatever CONFLICTS statement to emulators/wine will be appropriate by whoever is going to commit that new port of yours. (I won't be able to test this on amd64, but I am hopeful some other committer will grab it. If not, nudge them at emulators@FreeBSD.org or ports@FreeBSD.org. ;-) Thank you very much for your perseverence on this matter, David! I do believe it made the result all the better. Gerald
On Monday 07 February 2011 23:36:28 Ulrich Spörlein wrote: > Just some random comments from the sidelines: Please don't name the port > wine-fbsd64 as it is *not* a port for 64bit FreeBSD platforms, but for > amd64 *only*. It would be best to name it wine-amd64 if it is the one > package that amd64 users should install (I know that there are i386 > binaries inside it ... tricky). Yes, this is the port amd64 uses should install to run their *i386* Windows binaries. The future is likely to hold a wine port that runs amd64 Windows binaries. wine-amd64 was my original name for the port but some mistook that port to be the amd64 port of wine, not the i386 port of wine for amd64 FreeBSD. I suppose wine-i386 may be less ambiguous but then that may lead some to think that port is for i386 only. > Also, a blue bikeshed would be nice :) I prefer the colour that prevents people from accidental mistaking the bikeshed for a carshed (and trying to fit their car in the bikeshed). Luminous pink would be a good start ;-) Seriously, the port currently is ONLY_FOR_ARCH=i386 since FreeBSD does not support cross building and I have not added the ability for the port to install from an i386 package (although the idea is currently fermenting).
On Tuesday 08 February 2011 01:06:27 Gerald Pfeifer wrote: > On Sun, 6 Feb 2011, David Naylor wrote: > > Actually, wine-fbsd64 is also ONLY_FOR_ARCHS=i386. Since FreeBSD does > > not support cross building ports this port has to be built in an i386 > > environment. This port does run in an i386 environment. The only way I > > know of to deliver an amd64 port is to use binary packages. > > You're right. I explicitly preapprove the addition of whatever CONFLICTS > statement to emulators/wine will be appropriate by whoever is going to > commit that new port of yours. (I won't be able to test this on amd64, > but I am hopeful some other committer will grab it. If not, nudge them > at emulators@FreeBSD.org or ports@FreeBSD.org. ;-) As mentioned in my previous email, this port does not work as expected since it is i386 only at the moment. Do you have a server to host some packages on (the i386 packages from the FreeBSD build infrastructure)? If so I could create a script that will automatically update the amd64 portion of the port when a change is detected (perhaps a dailly periodic script). > Thank you very much for your perseverence on this matter, David! I do > believe it made the result all the better. It has been a pleasure. And thank you for your advice. David
On Tue, 8 Feb 2011, David Naylor wrote: > Do you have a server to host some packages on (the i386 packages from > the FreeBSD build infrastructure)? Hmm, I am wondering, could you leverage pkg_add -r or something like that? --dry-run perhaps, if you just want to get the URL? Gerald
After 1.5 years of baking the wine-fbsd64 port stands as follows: - the hosting has moved to www.mediafire.com/wine_fbsd64 (as drop.io closed down) - packages are created and uploaded for every release (FreeBSD 8/9/10) - the port now supports automatic patching for nVidia graphic cards - the port now supports the pkgng format (it changes the package arch to 64bit) - it now does not change the base wine port (thanks to the changes made by Gerald) - it still can only be built under FreeBSD/i386 I would like to submit this port for inclusion in the ports tree. As it stands now I expect it to have some outstanding issues however I am looking for feedback as to what needs to be change for, and if, this port can live in the main tree. If the port can live in the main tree, and after some investigation, I propose the following to get this port "building" under amd64: - assume the packages don't change (this step requires investigation) - have the wine-fbsd64 become two-in-one (an i386 mode and amd64 mode) - the i386 mode continues as normal - the amd64 mode will download the i386 packages (for the corresponding FreeBSD version) - do an installation of that package (either manually, tar -xf, etc, or using a package tool) - the amd64 port will be independent of the underlying port (i.e. it will have it's own version) - once the i386 packages have been built the amd64 version can be updated using the i386 package version and checksums (NOTE: this step is "manual", although it can be scripted, but will require a separate commit to the ports tree). Comments please. Regards
Responsible Changed From-To: freebsd-ports-bugs->dbn Over to emulators/i386-wine maintainer.
State Changed From-To: open->closed The port is now in the Collection as emulators/i386-wine-devel.