Bug 171526
Summary: | Review Request: wine - A Windows 16/32 bit emulator | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Andreas Bierfert <andreas.bierfert> | ||||||
Component: | Package Review | Assignee: | Linus Walleij <triad> | ||||||
Status: | CLOSED NEXTRELEASE | QA Contact: | David Lawrence <dkl> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | rawhide | CC: | bnocera, che666, dmitry, fedora-extras-list, gauret, hdegoede, nphilipp, paul, perbjornsson | ||||||
Target Milestone: | --- | Flags: | dennis:
fedora-cvs+
|
||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
URL: | http://www.winehq.org | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2006-01-07 23:59:35 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 163779 | ||||||||
Attachments: |
|
Description
Andreas Bierfert
2005-10-22 10:05:23 UTC
few points real quick: update-desktop-database &>/deb/null || : <- typo doesent the build depend on arts like that? wine doesent need arts though to work... ;) just as an example... autodep tracking wont do the proper job in this case. atleast not unless its split up ;). .desktop menu entrys are missing for the wine programs that come with wine... like uninstaller notepad etc... i thought dlldir=%{buildroot}%{_libdir}/wine \ <-> $RPM_BUILD_ROOT%{_initrddir}/wine mixing of macro and var shouldnt be done according to package policy? A Windows 16/32 bit emulator -> A Windows 16/32/64 bit emulator Windows 3.1/95/NT -> Windows 3.x/9.x/NT to run under Intel Unixes -> to run on x86 and x86_64 (In reply to comment #3) Windows 3.1/95/NT -> Windows 3.x/9x/NT Build fails on x86_64 /usr/bin/gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DNO_LIBW INE_PORT -DWINE_UNICODE_API="" -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasi ng -gstabs+ -Wdeclaration-after-statement -Wpointer-arith -O2 -g -pipe -Wall -W p,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 - m64 -mtune=nocona -D__i386__ -o casemap.o casemap.c In file included from ../../include/windef.h:218, from ../../include/wine/unicode.h:26, from casemap.c:4: ../../include/winnt.h:729:1: warning: "CONTEXT_CONTROL" redefined ../../include/winnt.h:688:1: warning: this is the location of the previous defin ition ../../include/winnt.h:730:1: warning: "CONTEXT_INTEGER" redefined ../../include/winnt.h:689:1: warning: this is the location of the previous defin ition ../../include/winnt.h:731:1: warning: "CONTEXT_SEGMENTS" redefined ../../include/winnt.h:690:1: warning: this is the location of the previous defin ition ../../include/winnt.h:732:1: warning: "CONTEXT_FLOATING_POINT" redefined ../../include/winnt.h:691:1: warning: this is the location of the previous defin ition ../../include/winnt.h:733:1: warning: "CONTEXT_DEBUG_REGISTERS" redefined ../../include/winnt.h:692:1: warning: this is the location of the previous defin ition ../../include/winnt.h:734:1: warning: "CONTEXT_FULL" redefined ../../include/winnt.h:693:1: warning: this is the location of the previous defin ition In file included from ../../include/windef.h:218, from ../../include/wine/unicode.h:26, from casemap.c:4: ../../include/winnt.h:846: error: conflicting types for 'CONTEXT' ../../include/winnt.h:695: error: previous declaration of 'CONTEXT' was here I haven't had time to test yet, but perhaps you should think more about using some lower version number? The current "date version" is really just a snapshot date - as far as I have understood the "beta release" will be numbered 0.9 and it would be a shame to have to bump the epoch immediately just because the first package had a huge version number! I think that knowingly forcing epoch=1 (which you'll need once the official beta comes out unless you want to diverge drastically from upstream version numbers) is a large price to pay just to stick with conventions from the upstream-produced RPMs of earlier versions. Fedora packages generally haven't made too much in the way of concessions to please external packages - sometimes that's annoying, but often it's a sane engineering policy. Oops. So I probably wasn't very clear with what I was actually suggesting in my comment above. What I meant to suggest was: Version: 0.0 Release: 20050930.X%{dist} (where the X in the release is the digit that is bumped per iteration, of course). If you really dislike 0.0 as a version number, choose whatever else that you like that you are sure is smaller than what the first beta version will be labeled with - something like 0.1 is probably safe too, but it sure is a bit hard to explain why it's better than 0.0 as far as I can see. This way you'll get a sane upgrade path to the beta which you have label (assuming that the verision number is actually 0.9 as I believe that I have heard) Version: 0.9 Release: X%{dist} just like any other package. I see your point but as I see it we need to bump epoch anyway. winehq snapshots have had this version numbering for a long time and we need to assume that people in lack of the fc/fe package installed winehq's version. That way we ensure that those people get the fedora extras packages as well. So I would anyway bump epoch and as 0.9 is around the corner (Tuesday I believe) I would like to see that happen if you can agree... I'm inclined to agree on bumping the epoch. It is best to avoid using epoch loosely, but it fits in this case. This is basically why we have the epoch. Follow the version scheme that has been used upstream and in all other Wine RPMs, and bump the epoch with the beta release to make everything work. snapshots will continue to exist and will most probably always be newer than "releases"... therefor i dont understand why you want to force upgrade/downgrade the users. lots of people will want to continue to use latest snapshots unless you plan to update wine every 4 weeks. and just as another comment... those snapshots arent just random snapshots... theres alot time invested to make the snapshots a "release". Neither versioning scheme (epoch vs. 0.0) solves that issue. The use of the date without any other sort of prefix for the snapshot presents and awkward situation. We can thank upstream for this. There is no perfect solution that solves all of the problems. We'd have to have the cooperation of all Wine packagers to come up with one. A lot of how we should proceed would depend upon whether or not we intend to package snapshot versions after the beta is released. My thinking is this: Use epoch=0 and version=snapshot date for now Bump epoch when the beta is released Suffix '-0' to all non-snapshot releases, prior to the release # Prefix the last release to any snapshot packages (eg. wine-0.9-20060101-0:1) I may be missing something, but it seems like this would fix most problems. Third-party packagers would need to use the the same method in order to avoid trouble, but that really isn't our concern, IMHO. wine-20050101-1:0 < wine-0.9-0-1:1 < wine-0.9-20060101-1:1 < wine-0.9.1-0-1:1 < wine-1.0-0-1:1 well thats bs since what do you do if the no concern 1st party (upstream) does also bump the epoch? an epoch race makes just things worse without fixing anything. with an "i dont care" about other stuff attitude you might just get the same back. wine-<release>-0.1.<date> looks better to me... well "fixing" ... id say if someone used snapshots before theres a good chance he wants to continue to use snapshots ;) well i dont care... just wanted to point out to the potential trouble. 3rd party packages containing snapshots will just most likely bump their epoch too ;). umm and not all wine packages around are really 3rd party... most i know are done from wine developers. Hm, thats a good point maybe this should be discussed together with the wine folks. What I would like to see here for FE is something like this: _One_ initial epoch bump with 0.9 and then have a sheme like: wine-0.9-0.1%{?dist} -> wine-0.9-0.2%{?dist} -> wine-0.9-0.date%{dist} -> ... -> wine-1.0-0.1 If you really need to override something you can do so by doing a wine-0.9-1.1%{?dist] eg. Then I would like to make a difference for devel and fc{3,4}: fc3 and fc4 I would like to keep at the beta releases and for devel I would go with whatever is newest. If there are important changes/patches they can either be applied to the beta version or you could also (on good knowledge and judgement) upgrade to the snapshot if desired. Can we agree on something like this? Flaws? (In reply to comment #15) > _One_ initial epoch bump with 0.9 I don't think we should do that -- for other packages we ignored other repos/older packages in the past and started with the right solution and without epochs. So IMHO it should be like this: Start: wine-0.0-0{?dist}.$(date) Beta: wine-0.9-1{?dist} And if you want to ship snapshots in devel do: wine-0.9-1{?dist}.$(date) This is definitely something you should talk to upstream about. The first problem I see with that scheme in comment #15 is a situation where there is an update to the release after a snapshot. wine-0.9-0.1:1 < wine-0.9-0.20060101:1 < wine-0.9-0.3 or wine-0.9-1.1:1 My earlier suggestion actually also fails in this situation. Perhaps: wine-0.9-1:1 < wine-0.9.1-1:1 < wine-0.10-0.20060101:1 < wine-0.10-1:1 < wine-1.0-1:1 Basically, increment the version number by one, keeping the following number < 1 for snapshots, making the release number 1 (or greater, as applies) for the actual releases. This works in my head. Again, probably best to discuss the possibilities with upstream. This solution doesn't exactly seem elegant, it just works... I think. These ideas apply equally without regard to the epoch. (In reply to comment #16) > (In reply to comment #15) > > _One_ initial epoch bump with 0.9 > > I don't think we should do that -- for other packages we ignored other > repos/older packages in the past and started with the right solution and without > epochs. So IMHO it should be like this: You have a good point there... I just took a look at the wine module in fe cvs and it hast 0.0 as version so lets continue like this sheme and add dist :) > Start: > wine-0.0-0{?dist}.$(date) > > Beta: > wine-0.9-1{?dist} > > And if you want to ship snapshots in devel do: > wine-0.9-1{?dist}.$(date) That sounds all good to me. I could very much settle with this. If there are no futher vetos against this I will aplly these changes and throw some new spec at you :) basically yes but why not just leave the epoch out and start with 0.9 for distro packages? the solution is that if someone wants a stable 0.9 rel he just has to uninstall his installed snapshot or disable his snapshot repo. generally i just dont like the idea of automatic downgrading. i dont see where this situation is much different from a ximian gnome install back in the days... actually redhat back then didnt increase the epoch with every rel but just asked the users to uninstall the 3rd party packages if they want a clean update. actually if you raise the epoch you got the same situation as before if some snapshot provider also raises his epoch. so the epoch spiral is good for nothing really. latest monthly atleast for rawhide sounds reasonable. in the past it made no sense at all to report bugs for old wine versions ;).´since i just really run rawhide that solves the "problem" for me. backporting patches also sounds nice but... have you yet checked how many patches go into wine in 4 weeks? i once identified a regression problem with a patch and the day the patch was checked in there were 170 patches commited ;). its a rather complex situation then. sure a simple compile fix isnt an issue to backport but functionality wise... you might have trouble to handle it. what else can be done: 1. binary handler must be able to detect mono vs wine stuff... theres a patch around for solving that somewhere on the patch list. can be done with binfmt_misc 2. theres a handler for creating desktop entrys... there needs to be a new menu category created for the links of installed win programs. 3. patches for 64 bit wine are also on the patch tracker (have fun) ;)) theres lots of other stuff to do for better integration but oh well ;) most importantly though the dependency issues must be solved.. i dont want to get half of kde installed just because theres also the arts sound module in the package ;)). in my eyes a clean way to solve that would be to split only certain things off the monolithic tree into subpackages. i am against the debian approach though of 50 subpackages... the basic monolithic tree should work properly with the default installation in my eyes. snapshot problem is trivial name-version-release.date like i basically wrote above already. are my above suggestions going to be fixed in the spec too? (In reply to comment #16) > (In reply to comment #15) > > _One_ initial epoch bump with 0.9 > I don't think we should do that -- for other packages we ignored other > repos/older packages in the past and started with the right solution and without > epochs. So IMHO it should be like this: > Start: > wine-0.0-0{?dist}.$(date) > Beta: > wine-0.9-1{?dist} > And if you want to ship snapshots in devel do: > wine-0.9-1{?dist}.$(date) hi thl! yeah see my comment below... epoch spiral is good for nothing. (In reply to comment #20) > are my above suggestions going to be fixed in the spec too? Yes they will be. First step when I get home is to fix up the smaller issues mentioned below, change versioning sheme (without epoch) and then try to split wine up. 1 & 2 from #19 should not be to bad so I will try to get this in as well. 3 will probablly be due to the next release ^^ i am currently busy discussing a solution for #19 3 with other wine devs. My current problem is atm basically that i dont have access to my x86_64 buildbox at home and no inet still.. besides at work. various people are working on the subject already though. its just that one must be aware of the problematics. currently building 64 bit packages doesent make sense for various reasons (yet!). especially one has to find a sane way of solving the following problems in a sane way: 1. 64 bit wine must be able to run win64 binaries 2. 64 bit wine must have a way to run 32 bit win binaries if backwards compat libs are installed, or there must be a sane way of parallel installing and a kinda solution for "binary type detection". currently 64 bit wine doesent run 32 bit win apps. 3. all of the above must be totally noninteractive (autodetection of kind of binaries etc) and it must be a clean solution aswell. of course the functional improvements besides the integration has to be done on the wine side for sure. /me wonders if we should just ship a 32-bit wine in the x86-64-repo for now. Most people probably want to run 32-bit binaries atm. We could ship a 64-bit wine after upstream has a solution. well this will work given theres 32 bit compat libs available for all the used components. The question for the future is mainly how it will work out to solve #23 properly. One relatively minor point: Please keep the %{?dist} as the last item in the release string. The packaging guidelines would have you do: wine-1.0-1%{?dist} (this is the formal release of wine 1.0) wine-1.0-2%{?dist} (this is a bugfix build to the 1.0 release) wine-1.0-3.20050515cvs%{?dist} (move to a post-release cvs checkout) wine-1.0-4.20050515cvs%{?dist} (bugfix to the post-release cvs checkout) wine-1.0-5.20050517cvs%{?dist} (new cvs checkout, note the increment of %{X}) You can leave the "cvs" off if it is not relevant. If there is no formal version number (and the date is in effect, the version number), then I would suggest that you use: wine-20050515-1%{?dist} -> wine-20050515-2%{?dist} -> wine-20050517-1%{?dist} I understand that there are epoch issues particular to this package, but let's assume that going forward, we will do everything possible to avoid its usage. Thanks for the this... sounds good as well. I now agree that epoching this can be prevented and thus I will stick to this sheme. Here is the promised version... it was late yesterday so please don't shout at me ;) it is just the first step of integration: http://fedora.lowlatency.de/review/wine.spec http://fedora.lowlatency.de/review/wine-0.9-1.src.rpm Just some comments: Why too many sub-packages? What is the reason to start splitting? libwine-* etc. formaly don't follow PackageNamingGuidelines... *-suite package: the reason is clear, but is such technic allowable in FC/FE? Are there any precedents? Splitting: I've read comment #19 and comment #22, but it seems too many however. Ok there is a reason behind this. The initial tought was that just because you install the arts part of wine together with wine you have to install half of kde alongside it. So I started with splitting out arts (looking at the debian example of how they solved this) but if you do this for one sound module you need to do it for all the sound models to be consistant hence: libwine-arts-0.9-1 libwine-esd-0.9-1 libwine-jack-0.9-1 libwine-alsa-0.9-1 libwine-nas-0.9-1 After that the debian split up actually made sense: e.g. libwine-cms-0.9-1 requires something not everybody will want just like libwine-gl or -twain or... the other special things. So if you really want wine split up consistantly the debian approach makes sense. For me however I am lazy and I like to have whole wine installed and I would suspect that there is a certain user group which has never even heard about what half of the libwine- suffixes mean so they will want to have wine work and not fiddel with this stuff so I created wine-suite (see koffice-suite for another example of this). Third an last to the naming sheme: actually all the things in the libwine packages are 'libs' and if you would like to link a program against them you would think this is called libsomething so the name libwine. For the -devel however I used both names so that both fronts are covered as this packages makes sense for wine-devel and libwine-devel and I would say there is no harm in that. in my opinion the debian approach doesent make sense at all... what one should do is choose a preferred sound method... like leaving alsa in the monolithic part and split all the other sound stuff off it. picking good defaults and leaving the unnecassery stuff optional. from experience in packaging wine since rh9 i know that users dont want a cluttered up solution and it will definitely create support overhead, thats why the winehq packages arent split up at all... vincent just turns off autodep tracking... and so did i when i packaged it on newrpms. sure thats not a clean solution... but creating a safe defaults monolithic package actually is a sane solution without pulling loads of unnecassery stuff in and leaves the user with a completly working wine by just doing yum install wine. splitting off gl support in my eyes also doesent make much sense at this point, will also just lead to bogus bug reports. if users do yum install wine* because they cant handle the complexity of all subpackages in a sane way on the commandline nothing at all is achieved in my eyes, cause the user doesent know what he wants. additionally why are the subpackages called lib%{name} ... since its a split of the wine package it shouldnt change name should it? dont know the fe policys behind it ... just doesent sound rh like to me. Ok I agree about the alsa part.. alsa is pretty much the default for fc so that could go back in. For -gl I don't think thats a good idea. There are people out there using wine one non-x boxes maybe? And what else would you consider default? twain is not default imho and neither is capi stuff. cms maybe could go in and print stuff as well. For ldap I would like to keep it out. I would still leave the split up as is and just require those -sub we consider default in wine... > install the arts part together with wine you have to install half of kde Surely, I agree with arts. But should "alsa" be splitted? IMHO it is some FC default thing... Normaly the "lib" prefix is used for packages with usual libraries -- i.e. libraries for native Linux applications. Most libwine-* contain %{_libdir}/wine/*.dll.so . If it is not useful for native Linux linking, then it is better to not prefix them with "lib", just "wine-<something>". As you have mentioned KDE, may be better to split as "wine-gnome", "wine-kde", "wine-gui" etc? Just a suggestion... > so I created wine-suite (see koffice-suite for another example of this) It is an unique precedent in the latest Fedora Extras. AFAIK Fedora does not use this way currently, i.e. there are no such things as "mozilla-suite", "gimp-suite", "perl-suite" etc... (In reply to comment #34) > > install the arts part together with wine you have to install half of kde > Surely, I agree with arts. But should "alsa" be splitted? IMHO it is some FC > default thing... See comment #33. I agree with that and will change it for the next release. > Normaly the "lib" prefix is used for packages with usual libraries -- i.e. > libraries for native Linux applications. Most libwine-* contain > %{_libdir}/wine/*.dll.so . If it is not useful for native Linux linking, then it > is better to not prefix them with "lib", just "wine-<something>". I got your point but as they can be used as a stand alone lib I just thought that this split up would make sense > As you have mentioned KDE, may be better to split as "wine-gnome", "wine-kde", > "wine-gui" etc? Just a suggestion... That is not the problem... just for the heck of it do a 'yum remove arts' or 'yum install arts' depending on if you have it installed or not... that is where the kde part kicks in... > this way currently, i.e. there are no such things as "mozilla-suite", > "gimp-suite", "perl-suite" etc... Yes and why is this? Because most packages are not split up and users don't get the choice of installing only parts of them and I doubt that for most packages this makes sense. koffice and ooo in my opinion are good examples where these make sense and wine for that matter as well. Just my opinion. since we basically agree on how to handle sound stuff now id like to discuss the other stuff in detail ;) theres only a very small amount of users in my eyes that would use wine-devel on non x boxes ;). sure for the wine compiler it makes perfect sense to have a non x setup solution. on the other hand none of the regular wine users will use wine without x really. the wine-gl issue should be discussed further in my eyes. for the other things id really love to see a case by case decision. the question in my eyes is mainly if its really worth splitting that stuff off or not, sure for half kde its worth it but for a few small libs... one has to look at the whole dep chain to decide that. creating a split to save a few kb of disc space and upgrade bandwidth probably isnt worth it and really just leaves users unhappy because they cant get stuff to work because they have no clue what twain does ;) well its true that with rh and fedora theres not that much splitting like with other distros as mdk e.g.: %{name} lib%{name} lib%{name}-devel ... but then again... i never really liked the extreme cluttering without real sense idea... sure it saves a few kb in some cases... but with todays discspaces that surely isnt a real problem. again we assume the end user has no clue. with that in mind id come to the following conclusion: if you have a module more or less installed doesent hurt... unless it really is not necassery by default or not even really recommended... and/or pulls loads of unnecassery deps in. again theres the support overhead problem (from a devs point of view) and the usability prob (from an end users point of view) if you clutter stuff too much. OK... from reading lates WWN I get the impression we will be done with that before 1.0 ;) libwine-alsa-0.9-1: Will move into libwine upon next release libwine-arts-0.9-1: Will stay out libwine-capi-0.9-1: From the requires I guess it could be moved back in again libwine-cms-0.9-1: I am not sure about this one. lcms is not that big but I don't think it is that important anyway libwine-esd-0.9-1: Should stay outside libwine-gl-0.9-1 Maybe we should move it back in and see if someone complains as I would suspect peolple using wine with X >> people using wine strictly without it libwine-jack-0.9-1 Should stay outside libwine-ldap-0.9-1 I don't think normal users will need this and the others well know what ldap ist ^^ libwine-nas-0.9-1 Should stay outside libwine-print-0.9-1 Should move in libwine-twain-0.9-1 I guess sane is something most people will have so this could go in. > libwine-gl-0.9-1 > Maybe we should move it back in and see if someone complains as I would suspect > peolple using wine with X >> people using wine strictly without it Good idea. BTW if a user can decide to use wine without X... Such a user usually build wine from the scratch into /usr/local/... :) > I got your point but as they can be used as a stand alone lib I just thought > that this split up would make sense Split up can make a sense, but rename "libwine-*" to "wine-*" ... doesn't bug 169652 actually completely block this? (recent wine versions don't work on recent fedora at all) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169652 Nope... it works just fine here with my package and has been for some time... id recommend checking with cvs head ;) SO many changes already? ;) Maybe this makes your more happy ;) http://fedora.lowlatency.de/review/wine-0.9-2.src.rpm http://fedora.lowlatency.de/review/wine.spec wine-0.9-2 still won't build on x86_64: In file included from ../../include/windef.h:226, from ../../include/wine/unicode.h:26, from casemap.c:4: ../../include/winnt.h:846: error: conflicting types for 'CONTEXT' ../../include/winnt.h:695: error: previous declaration of 'CONTEXT' was here Thanks... I did not mean to ignore you just wanted to sort out the other issues first. I will get to the x86_64 stuff etc soon it is just that I don't have a x86_64 I can test on and I would like to see if there is a way to package wine with support for 32bit and wine with support for 64bit in a good manner its just without a test box... since we decided to maintain the wine rpm stuff together anyways andreas id offer to handle the x86_64 stuff and do the required testing. i will be at home monday and tuesday next week and have my x86_64 box available for testing then. especially for the future x86_64 build working close with upstream is desireable for that anyways. Sounds good to me :) maybe we can work something out via jabber or irc or so.. =) right now building for x86_64 other than for development purpose doesent make sense btw ;). if it compiles it doesent mean it does much useful stuff yet ;) so the x86_64 build problem the user has is pretty secondary in my eyes yet, people are working on it though... there are various x86_64 patches on the patch list ;)) i will email you my icq and i will be monday/tuesday on irc.freenode.org #winehq #winehackers #fedora #fedora-de #fedora-devel with nick "che". What is a reason to have separated "wine" and main "libwine" packages? So that people who want to link against wine libs can just pull in libwine... that would be the case for alot stuff that is in fedora/redhat/extras but in none of em the lib is split of seperatly. the deal is that software (e.g. win software where the source code is available) doesent run really different if its linked vs its run with wine. getting that kinda software to compile with the wine compiler helps with porting... for the user theres no real benefit though. other software that links vs wine librarys is not known to me. generally i dont know of any case offhand where this is done atm. so i am still at the stance that its pretty much unnecassery to seperate the lib(s). > I am still at the stance that it is pretty much unnecessary to separate the
lib(s).
Completely agree.
Let's act with it as well as with "-gl" stuff -- if people will request such a
separation, we will separate it in the future.
And sorry for importunity, but rename the rest to "wine-*" ... :)
k... you convinced me but if someone complains I will be the first to mention that I said so from the start :P i am always open for new arguments on the matter ;). sure thing. hrhr I guess so: http://fedora.lowlatency.de/review/wine-0.9-3.src.rpm http://fedora.lowlatency.de/review/wine.spec Looks good now :) I would suggest to move subpackage's specific BuildRequires tags to appropriate subpackage's sections. For example, move "BuildRequires: openldap-devel" to "%package ldap" section. wine-suite has to go... virtual packages are deprecated. -> yum group (for comment #59): > virtual packages are deprecated Can you give some links for this (docs/guides/lists)? It could convince guys finally. Also it would be good idea to open a bug for "koffice" package, as it has "*-suite' too... When I try to make $ moch wine-0.9-3.src.rpm I will got the following messages: gcc -o wine-kthread -Wl,--export-dynamic -Wl,--section-start,.interp=0x7bf00400 kthread.o main.o -L../libs/wine -lwine -L../libs/port -lwine_port gcc -c -I. -I. -I../include -I../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wpointer-arith -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables -o pthread.o pthread.c gcc -o wine-pthread -Wl,--export-dynamic -Wl,--section-start,.interp=0x7bf00400 pthread.o main.o -L../libs/wine -lwine -L../libs/port -lwine_port -lpthread gcc -c -I. -I. -I../include -I../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wpointer-arith -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables -o preloader.o preloader.c gcc -o wine-preloader -static -nostartfiles -nodefaultlibs -Wl,-Ttext=0x7c000000 preloader.o -L../libs/port -lwine_port preloader.o: In function `map_so_lib': /builddir/build/BUILD/wine-0.9/loader/preloader.c:734: undefined reference to `__stack_chk_fail' preloader.o: In function `wld_printf': /builddir/build/BUILD/wine-0.9/loader/preloader.c:360: undefined reference to `__stack_chk_fail' collect2: ld returned 1 exit status make[1]: *** [wine-preloader] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/wine-0.9/loader' make: *** [loader] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.60875 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.60875 (%build) This may be solve, if you add the following line on top of the SPEC file: %define __global_cflags -O2 -g -pipe -fexceptions Best Regards: Jochen Schmitt (In reply to comment #60) > (for comment #59): > > > virtual packages are deprecated > Can you give some links for this (docs/guides/lists)? It could convince guys > finally. I dont think its documented yet as a guideline but do post to the extras list about this When I tried to build locally under FC4 I got a lot of unpackaged files, all fonts, for the main wine package. Rewriting by removing all %{_datadir}/fonts/wine/foo.fon and replacing with just the very simple one-line directive: %{_datadir}/fonts/wine/ which implicitly takes the whole subdiectory for the main package solved the problem. Consider this solution instead since none of the subpackages produce any stuff in /fonts/wine anyway. Created attachment 120826 [details]
Screenshot of winecfg on FC4
This weird looking winecfg was the result of compiling and installing
wine and wine-tools (only these two) on FC4.
It was compiled with mentioned font-fix, which appear to work so I
don't think that is the problem. However it is most certainly
font-related.
Does it look familiar? Is it all my fault?
Update: I tried putting some Windows native .ttf fonts into ~/.fonts and lo and behold then it works. However I believe WINE should be able to go with only the fonts found in /usr/share/fonts/wine/ or am I wrong here... Did you use my spec/srpm file? I don't see these problems here... Yep I used the latest spec/RPM. Is it possible that the font stuff will build differently on different hosts depending on what's available? Anyway it's probably all my own fault, just don't know how. Part of it may have to do with running winecfg without any previously existing .wine/ configuration directory containing copies of the system fonts in its c_drive. Hm could you try to figure out what BR is missing here so that you get the extra fonts or tell me which font files are missing... ? And maybe try with this new version^^ http://fedora.lowlatency.de/review/wine-0.9.1-1.src.rpm http://fedora.lowlatency.de/review/wine.spec Yeah, heh sorry I must have put my brain on the shelf... Looking into the WINE configure.ac you find that it looks for (the excellent program) fontforge, and if present, it will use the stuff in the fonts/ subdirectory to prepare a number of fonts, so it's a BR: fontforge. If you have fontforge (I believe, nota bene), the following build error log appears: fel: Installerade (men opaketerade) filer funna: /usr/share/fonts/wine/coue1255.fon /usr/share/fonts/wine/coue1256.fon /usr/share/fonts/wine/coue1257.fon /usr/share/fonts/wine/coure.fon /usr/share/fonts/wine/couree.fon /usr/share/fonts/wine/coureg.fon /usr/share/fonts/wine/courer.fon /usr/share/fonts/wine/couret.fon /usr/share/fonts/wine/cvgasys.fon /usr/share/fonts/wine/hvgasys.fon /usr/share/fonts/wine/jvgasys.fon /usr/share/fonts/wine/marlett.ttf /usr/share/fonts/wine/ssee1255.fon /usr/share/fonts/wine/ssee1256.fon /usr/share/fonts/wine/ssee1257.fon /usr/share/fonts/wine/ssee874.fon /usr/share/fonts/wine/sserife.fon /usr/share/fonts/wine/sserifee.fon /usr/share/fonts/wine/sserifeg.fon /usr/share/fonts/wine/sserifer.fon /usr/share/fonts/wine/sserifet.fon /usr/share/fonts/wine/svgasys.fon /usr/share/fonts/wine/vgas1255.fon /usr/share/fonts/wine/vgas1256.fon /usr/share/fonts/wine/vgas1257.fon /usr/share/fonts/wine/vgas874.fon /usr/share/fonts/wine/vgasys.fon /usr/share/fonts/wine/vgasyse.fon /usr/share/fonts/wine/vgasysg.fon /usr/share/fonts/wine/vgasysr.fon /usr/share/fonts/wine/vgasyst.fon (Sorry for Swedish locale, it means found but uninstalled files found.) My fontforge is: fontforge-20050502-1, luckily it is already in Fedora Extras. The other bug (the weird screenshot) is (I have found) that winecfg needs the Arial.ttf font. If I put this in my ~/.fonts everything works. I guess it could also be available system-wide. But obviously wine doesn't find anything on my system until I put it in some obvious place like ~/.fonts. I will experiment more with this and see if there is some package adding the Arial.ttf font system-wide. You don't happen to have it installed somewhere on your machine, have you? (find /usr |grep Arial) I believe the font problem is actually an upstream issue so I have filed a bug in the WINE bugzilla: http://bugs.winehq.org/show_bug.cgi?id=3842 ok thanks I will add myself there... I tried to rebuild wine with fontforge but something went wrong I habe to take a closer look today or tomorrow when I get around to it.... Ok here you go =) new version with fontforge requires: http://fedora.lowlatency.de/review/wine-0.9.1-2.src.rpm http://fedora.lowlatency.de/review/wine.spec http://fedora.lowlatency.de/review/i386/ So what is missing to get this ready for prime time fe? How will we handle the x86_64 version? just don't build there for now and let users use the i386 version? Given the number of comments and reviews on this package request, it's strange that it does not appear to have been even formally accepted for review (i.e. the block is still FE-NEW, not FE-REVIEW and it has not been ACCEPTed) let alone ready to check into CVS. I'm not volunteering (as I'm not an official contributor, just somebody interested having wine in FE), but has somebody actually meant to accept this and just not changed the status? That is a valid question and I would know that myself... =) Maybe we can agree on an agenda maybe something like stuff that has to be fixed/integrated before first release and points that should be fixed/integrated soon and then stuff that should be done in the future... Would probably help the whole package... Andreas, are you sponsored? If you're not sponsored one of the "root admins" have to be both reviewer and sponsor of this package. Since this is an important package I would also prefer that just for the sake of these people's experience of how things need to fit into the general Fedora framework. Sure I am just do a grep Bierfert owners.list ^^ But having some FESCO members probably would do no harm... =) I have successfully build wine in mock for FC-4. But it doesn't build in mock-development: No Package Found for xorg-x11-devel In the wine-tools package is a small typo. In the desktop file for winefile it tries to start "winfile" this should be "winefile". Not a packaging bug, but my Lotus Notes doesn't work anymore with this version. Thanks for the type... fixed... for xorg-x11-devel I willl see what I can do once my rawhide box (366 Celeron ^^) can upgrade again... =) Here is a typo fixed version which also (and I think thats a better solution) not edits ld.so.conf but drops in a file for /usr/lib/wine... Thanks for the mock testing btw... http://fedora.lowlatency.de/review/wine-0.9.1-2.src.rpm http://fedora.lowlatency.de/review/wine.spec http://fedora.lowlatency.de/review/i386/ (In reply to comment #73) > How will we handle the x86_64 version? just don't build there for now and let > users use the i386 version? I was able to install wine.i386 on x86_64 after I installed lcms.i386 from extras. yum was able to install all other i386 deps for a i386-wine automatically. Notepad and winemime both worked fine. From everything I know about it I'd vote for copying wine and lcms from the i386 to the x86_64 tree for now. Che, Aurélien, you both used wine on x86_64 iirc. Do you agree? Or do you think there will be other problems? Should be: http://fedora.lowlatency.de/review/wine-0.9.1-3.src.rpm I think... It's been silently updated. I have applied for reviewer group membership so I can formally review this package (though so many have been involved that it ought to be considered a collective process) so we finally get some movement in the process. (In reply to comment #82) > Should be: > http://fedora.lowlatency.de/review/wine-0.9.1-3.src.rpm > > I think... It's been silently updated. Yes, bad bad second me *slap* > I have applied for reviewer group membership so I can formally > review this package (though so many have been involved that it ought > to be considered a collective process) so we finally get some movement > in the process. Sounds great... there probably are things that should get done before a push but having it in review is probably a good first step... :) And version upgrade again :) http://fedora.lowlatency.de/review/wine-0.9.2-1.src.rpm Can You make for modular X dependencies? It would be nice :) Yes on my list =) Maybe, I collect I new, what need for a cleen conpile: remove BuildRequires: xorg-x11-devel and add: BuildRequires: libX11-devel BuildRequires: mesa-libGL-devel mesa-libGLU-devel mesa-libGLw-devel BuildRequires: libXxf86dga-devel libXxf86vm-devel BuildRequires: xorg-x11-proto-devel BuildRequires: libXrandr-devel libXrender-devel libXext-devel I use only modular X, so I dont do any if statements, if You want, I make it :) (In reply to comment #87) > Maybe, I collect I new, what need for a cleen conpile: > remove > > BuildRequires: xorg-x11-devel > > and add: > > BuildRequires: libX11-devel > BuildRequires: mesa-libGL-devel mesa-libGLU-devel mesa-libGLw-devel > BuildRequires: libXxf86dga-devel libXxf86vm-devel > BuildRequires: xorg-x11-proto-devel > BuildRequires: libXrandr-devel libXrender-devel libXext-devel > > I use only modular X, so I dont do any if statements, if You want, I make it :) xorg-x11-proto-devel could be omitted because it's required by libX11-devel. (In reply to comment #88) > (In reply to comment #87) > > BuildRequires: mesa-libGLw-devel Is this true? If yes, wine is blocked by PR 173879. No, mesa-libGLw-devel is not needed, sorry, I just make a fast "lib find" with configure script output, and I install mesa*devel*...: checking for X11/Xlib.h... yes checking for X11/XKBlib.h... yes checking for X11/Xutil.h... yes checking for X11/extensions/shape.h... yes checking for X11/extensions/XInput.h... yes checking for X11/extensions/XShm.h... yes checking for X11/extensions/Xrandr.h... yes checking for X11/extensions/Xrender.h... yes checking for X11/extensions/xf86dga.h... yes checking for X11/extensions/xf86vmode.h... yes checking for XkbQueryExtension in -lX11... yes checking for XShmQueryExtension in -lXext... yes checking for XShapeQueryExtension in -lXext... yes checking for XDGAQueryExtension in -lXxf86dga... yes checking for XF86VidModeQueryExtension in -lXxf86vm... yes checking for XRenderSetPictureTransform in -lXrender... yes checking for GL/gl.h... yes checking for GL/glx.h... yes checking for GL/glext.h... yes checking for up-to-date OpenGL version... yes checking for glXCreateContext in -lGL... yes checking for gluLookAt in -lGLU... yes checking for glutMainLoop in -lglut... yes Ok I will have to specs for now: - fc{3,4}: http://fedora.lowlatency.de/review/wine.spec http://fedora.lowlatency.de/review/wine-0.9.2-1.src.rpm - devel: http://fedora.lowlatency.de/review/wine-fc5.spec http://fedora.lowlatency.de/review/wine-0.9.2-1.fc5.src.rpm Created attachment 121594 [details]
Make spec file universal
Do not provide two spec files, there are too small differences between them!
Separate stuff for FC5+ can be handled using rpm macros.
The attached patch is against wine.spec (not wine-fc5.spec).
I hope I was not mistaken in %if conditions, else correct me somebody :)
Thanks for the patch... I know you can do this but I figure if this goes to cvs anytime soon *dreaming* then this needs to be split up anyway... New version: http://fedora.lowlatency.de/review/wine.spec http://fedora.lowlatency.de/review/wine-0.9.3-1.src.rpm http://fedora.lowlatency.de/review/wine-fc5.spec http://fedora.lowlatency.de/review/wine-0.9.3-1.fc5.src.rpm build fails in "mock -r fedora-development-i386-core": gcc -o wine-preloader -static -nostartfiles -nodefaultlibs -Wl,-Ttext=0x7c000000 preloader.o -L../libs/port -lwin e_port preloader.o: In function `wld_printf': /builddir/build/BUILD/wine-0.9.3/loader/preloader.c:360: undefined reference to `__stack_chk_fail' preloader.o: In function `map_so_lib': /builddir/build/BUILD/wine-0.9.3/loader/preloader.c:734: undefined reference to `__stack_chk_fail' collect2: ld returned 1 exit status make[1]: *** [wine-preloader] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/wine-0.9.3/loader' make: *** [loader] Error 2 Without testing this I would bet that if you add -lgcc it will work... Though this is not a good way to fix this. Anybody got a clue what is wrong here? Try -fno-stack-protector. Hm, would like to know if this really fixes it because on some other packages that was the first thing that came to my mind but had no effect... Now needs BuildRequires: autoconf since you run that after patching. rpmlint complains on source RPM: W: wine strange-permission wine.init 0755 can that file be 0644 instead? There are a lot of rpmlint complaints on the binary RPMs but most seem silly. Will look into them more at some point to be sure. Otherwise builds fine for me. Thanks for the comments I fixed the perms and the BR autoconf: I still wonder why we are stuck here and what needs to be fixed, added and so on to get this out. Comments and or suggestions as to what is needed to push this are always welcome: http://fedora.lowlatency.de/review/wine.spec http://fedora.lowlatency.de/review/wine-0.9.4-1.src.rpm http://fedora.lowlatency.de/review/wine-fc5.spec http://fedora.lowlatency.de/review/wine-0.9.4-1.fc5.src.rpm and as always http://fedora.lowlatency.de/review/i386/ for the fc4 bins... Perhaps people are too busy... After New Year I'll try to look on it under FC3. Someone (I guess) already have success under FC4... If all formal items are OK, then the next step is to put wine into CVS and start to solve problems in building wine in the plague build system. :) Sorry Andreas, I will go over this bugs comments top see if there is anything major that need to be done, then make a final check against the FC checklist, and if it's all OK by then I will simply accept it. So the following things seem fixed: * Naming and epoching issues resolved. * Subpackaging naming conventions have a rough consensus and noone is complaining about it anymore. * All build requirements are in place. I proceed to check against the baseline criteria. Does the fact that we're using the 32bit packages for the 64bit architectures mean that the package must have an ExcludeArch:-tag for the 64bit architectures? This need to be resolved... Here is another problem: %dir %{_datadir}/fonts/wine need to be added so wine owns the %{_datadir}/fonts/wine/ directory. Formal review: * Package naming OK. * The spec file name matches the base package %{name}. * Meets packaging guidelines. * Package has a open source compliant license (LGPL). * The License: field matches the actual license. * License included with %doc tag. * Spec file is written in American English. * Spec file is readable (and very straight forward). * Sources match upstream (same md5sum). * Builds successfully on FC4 i386 and i386smp. * Problems with 64bit builds solved by using 32bit RPM versions, if ExcludeArch: tags are needed for this they will be imminent during package build. * Build requirements seem fine now. * Mulilingual stuff is handled internally by Wine. (No gettext.) * ldconfig is properly called. * Package does not support relocations. * Wine owns the directories it creates (when %{_datadir}/fonts/wine/ is fixed) * No duplicate files. * Correct %clean section. * Spec file uses apropriate macros. * Package contains only permissible content. * Separate -docs package created, even has its own spec file. * Proper -devel package exists. * Wine does not use pkgconfig so no .pc files. * There are a lot of .so (no numbers) files in %_libdir/wine but this is acceptable in this case because these are actually win32 DLL files and not usable by the dynamic link library loader as such. Also these do not have any matching .1.1 etc files. * The POSIXish .so (no numbers) files are in the -devel package. * -devel package requires base package, same for all subpackages actually. * Libtool archives not included in any packages. * .desktop files included for all WINE applications as far as the reviewer can see. * .a files includes: %{_libdir}/wine/*.a is this really needed? rpmlint runs: wine-0.9.4-1 produce no messages. wine-0.9.4-1.i386.rpm: W: wine no-version-in-last-changelog E: wine statically-linked-binary /usr/bin/wine-preloader W: wine non-conffile-in-etc /etc/ld.so.conf.d/wine-32.conf W: wine service-default-enabled /etc/rc.d/init.d/wine E: wine subsys-not-used /etc/rc.d/init.d/wine Both errors seem to be ignorable. Warnings are confused. wine-tools-0.9.4-1.i386.rpm W: wine-tools no-version-in-last-changelog W: wine-tools no-documentation wine-arts-0.9.4-1.i386.rpm W: wine-arts no-version-in-last-changelog W: wine-arts no-documentation wine-esd-0.9.4-1.i386.rpm W: wine-esd no-version-in-last-changelog W: wine-esd no-documentation wine-jack-0.9.4-1.i386.rpm W: wine-jack no-version-in-last-changelog W: wine-jack no-documentation wine-nas-0.9.4-1.i386.rpm W: wine-nas no-version-in-last-changelog W: wine-nas no-documentation wine-ldap-0.9.4-1.i386.rpm W: wine-ldap no-version-in-last-changelog W: wine-ldap no-documentation wine-cms-0.9.4-1.i386.rpm W: wine-cms no-version-in-last-changelog W: wine-cms no-documentation wine-twain-0.9.4-1.i386.rpm W: wine-twain no-version-in-last-changelog W: wine-twain no-documentation wine-capi-0.9.4-1.i386.rpm W: wine-capi no-version-in-last-changelog W: wine-capi no-documentation wine-devel-0.9.4-1.i386.rpm W: wine-devel summary-ended-with-dot Wine development environment. W: wine-devel no-version-in-last-changelog Fix the summary problem with the -devel package. Uncertain about what causes the "no-version-in-last-changelog" message. The others seem OK. Documentation is elsewhere. If these (small) things are fixed, we are very close to accepting. Also the two last remarks made for this package by me should be taken into account. Thanks for you time: http://fedora.lowlatency.de/review/wine.spec http://fedora.lowlatency.de/review/wine-0.9.4-2.src.rpm http://fedora.lowlatency.de/review/wine-fc5.spec http://fedora.lowlatency.de/review/wine-0.9.4-2.fc5.src.rpm Fix the things you pointed out. > Uncertain about what causes the "no-version-in-last-changelog" message. This is caused because the version is in a new line but with my long name/mail combination the line would be to long. This has been accepted before if you take a look at my other packages and the reviews for them. ExcludeArch: x86_64 is probably the right way to go for now so I added that as well. (In reply to comment #107) > ExcludeArch: x86_64 is probably the right way to go for now so I added that as well. No, it's not exactly the right way. You should have added ppc there, too, because otherwise the buildsys will try to build it on ppc -- and I suspect it builds/works there. A "ExclusiveArch: i386" probably is the right thing to do. (In reply to comment #108) > (In reply to comment #107) > > ExcludeArch: x86_64 is probably the right way to go for now so I added that as > well. > > No, it's not exactly the right way. You should have added ppc there, too, > because otherwise the buildsys will try to build it on ppc -- and I suspect it > builds/works there. A > "ExclusiveArch: i386" > > probably is the right thing to do. "ExclusiveArch: %{ix86}" would be better since it does in fact work properly on any IA-32 archiecture. (In reply to comment #109) > "ExclusiveArch: %{ix86}" would be better since it does in fact work properly on > any IA-32 archiecture. Theoretical: Yes. But see fedora-extras list from some days ago -- it seems that plague in some situations builds such packages for i386, i586, i686 (probably others). But we still don't know for sure if the extras buildsys really does it. (In reply to comment #110) > (In reply to comment #109) > > "ExclusiveArch: %{ix86}" would be better since it does in fact work properly on > > any IA-32 archiecture. > > Theoretical: Yes. Practically also. I just tried (Job 2430). Go ahead with "ExclusiveArch: %{ix86}". The architecture exclusion stuff will obviously solve itself during build. All other problems are successfully resolved. APPROVED. Build for FC-{3,4}... devel does not work because of: preloader.o: In function `wld_printf': /builddir/build/BUILD/wine-0.9.4/loader/preloader.c:360: undefined reference to `__stack_chk_fail' preloader.o: In function `map_so_lib': /builddir/build/BUILD/wine-0.9.4/loader/preloader.c:734: undefined reference to `__stack_chk_fail' collect2: ld returned 1 exit status Anybody gcc who can comment on this? Adding '-fno-stack-protector' to the CFLAGS should solve comment #113 Why is there a | Requires(postun): perl ? Hm, the perl bit ist probably left over from the first spec... removed it. As to the -fno-stack-protector: Is it ok to disable this? I mean people using fc5 and fe for fc5 probably think that all packages use the standard cflags and the security implications that come with them... Is there a policy for this? I've been playing with wine today (using winehq RPMS, building i386 cvs on x86_64 is a pain) and encountered the following bug, which is really a show stopper for wine on devel: bug 177097 Since this package has been APPROVED, and built, it should be CLOSED NEXTRELEASE and the blocker bug should be switched to FE-ACCEPT. All further bugs should be filed under the "wine" component in Fedora Extras. Until devel is resolved I want to keep this open ... (In reply to comment #119) > Until devel is resolved I want to keep this open ... Fair enough, I was more concerned about other non-devel (such as on FC3 and FC4) related wine issues that people may continue to post to this bug. At least the bug blocker should be switched from FE-REVIEW to FE-ACCEPT because the package has been APPROVED, even if devel hasn't been built. Fixed blocking bug, sorry... (My first review.) Ok, devel is down to 1 issue: http://buildsys.fedoraproject.org/logs/fedora-development-extras/2607-wine-0.9.5-1.fc5/i386/build.log It does not detect libglut from the freeglut package and thus does not create the dll.so. If you compare builds for FC4 and devel BR freeglut-devel seems to work for fc4 but not for devel. glutMainLoop is present in 2.2.x (fc4) and 2.4.x (devel) so I don't see what causes this to fail. Ideas? Most likely a missing modular Xorg devel require in freeglut-devel so try adding libX****-devel to BR . You could take a look at the freeglut headers to see which other headers they need. Might even be zlib-devel . Hm it just inlcudes gl.h und glu.h which should be present from the mesa requires... Looks like you're missing: BuildRequires: libXmu-devel, libXi-devel If you look at the configure.ac definition for that failed test case, the reasoning should be clear. :) dnl Check for glut32 library. AC_CHECK_LIB(glut,glutMainLoop, [AC_SUBST(GLUT_LIBS,"-lglut -lXmu -lXi") AC_SUBST(GLUT32FILES,'$(GLUT32FILES)')],, $OPENGL_LIBS $X_LIBS $X_PRE_LIBS -lXmu -lXi -lX11 $X_EXTRA_LIBS) The spec in CVS still contains: BR: mesa-libGLw-devel Though I haven't checked (yet), I am pretty sure wine doesn't used. Thanks to all the people here wine is built for fc3 and fc4 and now also for devel. I will close this bug in the hope that more work and integration will be discussed in other wine bugs along the way. Thank you all very much. Package Change Request ====================== Package Name: wine New Branches: EL-5 Package Change Request ====================== Package Name: wine New Branches: F-11 CVS Done |