Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 171526 - Review Request: wine - A Windows 16/32 bit emulator
Summary: Review Request: wine - A Windows 16/32 bit emulator
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Linus Walleij
QA Contact: David Lawrence
URL: http://www.winehq.org
Whiteboard:
Depends On:
Blocks: FE-ACCEPT
TreeView+ depends on / blocked
 
Reported: 2005-10-22 10:05 UTC by Andreas Bierfert
Modified: 2009-04-01 16:30 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-01-07 23:59:35 UTC
Type: ---
Embargoed:
dennis: fedora-cvs+


Attachments (Terms of Use)
Screenshot of winecfg on FC4 (106.97 KB, image/png)
2005-11-08 20:47 UTC, Linus Walleij
no flags Details
Make spec file universal (914 bytes, patch)
2005-11-29 16:39 UTC, Dmitry Butskoy
no flags Details | Diff

Description Andreas Bierfert 2005-10-22 10:05:23 UTC
Spec Name or Url: http://fedora.lowlatency.de/review/wine.spec
SRPM Name or Url: http://fedora.lowlatency.de/review/wine-20050930-2.src.rpm
Description:
While Wine is usually thought of as a Windows(TM) emulator, the Wine
developers would prefer that users thought of Wine as a Windows
compatibility layer for UNIX. This package includes a program loader,
which allows unmodified Windows 3.1/95/NT binaries to run under Intel
Unixes. Wine does not require MS Windows, but it can use native system
.dll files if they are available.

Comment 1 Rudolf Kastl 2005-10-22 10:29:01 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?

Comment 2 Rudolf Kastl 2005-10-22 10:32:37 UTC
A Windows 16/32 bit emulator -> A Windows 16/32/64 bit emulator

Comment 3 Rudolf Kastl 2005-10-22 10:34:14 UTC
Windows 3.1/95/NT -> Windows 3.x/9.x/NT

Comment 4 Rudolf Kastl 2005-10-22 10:35:22 UTC
to run under Intel Unixes -> to run on x86 and x86_64

Comment 5 Rudolf Kastl 2005-10-22 10:37:58 UTC
(In reply to comment #3)
Windows 3.1/95/NT -> Windows 3.x/9x/NT



Comment 6 John Ellson 2005-10-22 12:05:32 UTC
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


Comment 7 Per Bjornsson 2005-10-23 04:44:18 UTC
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.

Comment 8 Per Bjornsson 2005-10-23 04:51:16 UTC
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.


Comment 9 Andreas Bierfert 2005-10-23 07:17:32 UTC
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...

Comment 10 Patrick Barnes 2005-10-23 07:28:54 UTC
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.

Comment 11 Rudolf Kastl 2005-10-24 07:32:47 UTC
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.

Comment 12 Rudolf Kastl 2005-10-24 07:34:08 UTC
and just as another comment... those snapshots arent just random snapshots... 
theres alot time invested to make the snapshots a "release".

Comment 13 Patrick Barnes 2005-10-24 08:11:06 UTC
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

Comment 14 Rudolf Kastl 2005-10-24 08:18:20 UTC
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.





Comment 15 Andreas Bierfert 2005-10-24 08:47:27 UTC
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?

Comment 16 Thorsten Leemhuis 2005-10-24 09:14:00 UTC
(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)

Comment 17 Patrick Barnes 2005-10-24 09:20:03 UTC
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.

Comment 18 Andreas Bierfert 2005-10-24 09:31:05 UTC
(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 :)

Comment 19 Rudolf Kastl 2005-10-24 10:05:01 UTC
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.



Comment 20 Rudolf Kastl 2005-10-24 10:07:08 UTC
are my above suggestions going to be fixed in the spec too?

Comment 21 Rudolf Kastl 2005-10-24 10:09:47 UTC
(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.

Comment 22 Andreas Bierfert 2005-10-24 11:58:15 UTC
(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 ^^

Comment 23 Rudolf Kastl 2005-10-24 12:22:04 UTC
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.




Comment 24 Thorsten Leemhuis 2005-10-24 13:01:10 UTC
/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.

Comment 25 Rudolf Kastl 2005-10-24 13:24:47 UTC
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.



Comment 26 Tom "spot" Callaway 2005-10-26 04:14:12 UTC
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.


Comment 27 Andreas Bierfert 2005-10-26 06:38:45 UTC
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

Comment 28 Dmitry Butskoy 2005-10-27 13:23:37 UTC
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?

Comment 29 Dmitry Butskoy 2005-10-27 13:29:38 UTC
Splitting: I've read comment #19 and comment #22, but it seems too many however.

Comment 30 Andreas Bierfert 2005-10-27 13:42:20 UTC
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.

Comment 31 Rudolf Kastl 2005-10-27 13:59:45 UTC
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.



Comment 32 Rudolf Kastl 2005-10-27 14:01:09 UTC
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.

Comment 33 Andreas Bierfert 2005-10-27 14:11:14 UTC
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...

Comment 34 Dmitry Butskoy 2005-10-27 14:12:19 UTC
> 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... 

Comment 35 Andreas Bierfert 2005-10-27 14:19:21 UTC
(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.

Comment 36 Rudolf Kastl 2005-10-27 14:24:26 UTC
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 ;)



Comment 37 Rudolf Kastl 2005-10-27 14:30:54 UTC
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. 

Comment 38 Andreas Bierfert 2005-10-27 14:34:08 UTC
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.

Comment 39 Dmitry Butskoy 2005-10-27 14:43:52 UTC
> 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-*" ...


Comment 40 julian 2005-10-27 15:46:07 UTC
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

Comment 41 Andreas Bierfert 2005-10-27 15:48:51 UTC
Nope... it works just fine here with my package and has been for some time...

Comment 42 Rudolf Kastl 2005-10-27 15:57:52 UTC
id recommend checking with cvs head ;)

Comment 43 Andreas Bierfert 2005-10-27 16:01:03 UTC
SO many changes already? ;)

Comment 44 Andreas Bierfert 2005-10-27 19:04:17 UTC
Maybe this makes your more happy ;)


http://fedora.lowlatency.de/review/wine-0.9-2.src.rpm
http://fedora.lowlatency.de/review/wine.spec

Comment 45 John Ellson 2005-10-27 20:41:43 UTC
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


Comment 46 Andreas Bierfert 2005-10-27 20:48:59 UTC
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...

Comment 47 Rudolf Kastl 2005-10-28 06:41:24 UTC
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.

Comment 48 Andreas Bierfert 2005-10-28 06:57:03 UTC
Sounds good to me :) maybe we can work something out via jabber or irc or so.. =)

Comment 49 Rudolf Kastl 2005-10-28 07:37:39 UTC
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 ;))



Comment 50 Rudolf Kastl 2005-10-28 07:41:42 UTC
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".

Comment 51 Dmitry Butskoy 2005-10-28 09:55:44 UTC
What is a reason to have separated "wine" and main "libwine" packages?

Comment 52 Andreas Bierfert 2005-10-28 10:14:52 UTC
So that people who want to link against wine libs can just pull in libwine...

Comment 53 Rudolf Kastl 2005-10-28 10:28:26 UTC
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).

Comment 54 Dmitry Butskoy 2005-10-28 10:51:32 UTC
> 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-*" ... :)

Comment 55 Andreas Bierfert 2005-10-28 11:13:34 UTC
k... you convinced me but if someone complains I will be the first to mention
that I said so from the start :P

Comment 56 Rudolf Kastl 2005-10-28 11:19:51 UTC
i am always open for new arguments on the matter ;). sure thing.

Comment 58 Dmitry Butskoy 2005-10-31 12:03:17 UTC
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.



Comment 59 Rudolf Kastl 2005-10-31 21:56:11 UTC
wine-suite has to go... virtual packages are deprecated. -> yum group

Comment 60 Dmitry Butskoy 2005-11-01 10:40:54 UTC
(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...



Comment 61 Jochen Schmitt 2005-11-01 18:37:07 UTC
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

Comment 62 Rahul Sundaram 2005-11-02 14:32:52 UTC
(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

Comment 63 Linus Walleij 2005-11-08 16:40:52 UTC
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.

Comment 64 Linus Walleij 2005-11-08 20:47:23 UTC
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?

Comment 65 Linus Walleij 2005-11-08 20:54:51 UTC
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...

Comment 66 Andreas Bierfert 2005-11-08 22:30:49 UTC
Did you use my spec/srpm file?

I don't see these problems here...

Comment 67 Linus Walleij 2005-11-09 12:02:08 UTC
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.

Comment 68 Andreas Bierfert 2005-11-12 11:16:01 UTC
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

Comment 69 Linus Walleij 2005-11-12 20:01:22 UTC
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.

Comment 70 Linus Walleij 2005-11-12 20:09:27 UTC
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)

Comment 71 Linus Walleij 2005-11-15 17:42:38 UTC
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

Comment 72 Andreas Bierfert 2005-11-15 18:11:11 UTC
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....

Comment 73 Andreas Bierfert 2005-11-17 07:53:57 UTC
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?

Comment 74 Alex Lancaster 2005-11-17 08:22:25 UTC
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?

Comment 75 Andreas Bierfert 2005-11-17 09:52:41 UTC
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...

Comment 76 Linus Walleij 2005-11-17 11:43:03 UTC
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.

Comment 77 Andreas Bierfert 2005-11-17 11:48:09 UTC
Sure I am just do a grep Bierfert owners.list ^^

But having some FESCO members probably would do no harm... =)

Comment 78 Adrian Reber 2005-11-17 12:50:39 UTC
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.

Comment 79 Andreas Bierfert 2005-11-17 13:37:57 UTC
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... =)

Comment 80 Andreas Bierfert 2005-11-17 15:19:51 UTC
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/

Comment 81 Thorsten Leemhuis 2005-11-17 17:56:43 UTC
(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?

Comment 82 Linus Walleij 2005-11-23 19:16:26 UTC
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.

Comment 83 Andreas Bierfert 2005-11-23 21:36:32 UTC
(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... :)

Comment 84 Andreas Bierfert 2005-11-24 20:10:51 UTC
And version upgrade again :)

http://fedora.lowlatency.de/review/wine-0.9.2-1.src.rpm

Comment 85 Szabo Akos 2005-11-25 07:45:49 UTC
Can You make for modular X dependencies?
It would be nice :)

Comment 86 Andreas Bierfert 2005-11-25 07:50:37 UTC
Yes on my list =)

Comment 87 Szabo Akos 2005-11-25 11:44:34 UTC
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 :)


Comment 88 Paul Howarth 2005-11-25 11:51:54 UTC
(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.




Comment 89 Ralf Corsepius 2005-11-25 14:20:47 UTC
(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.

Comment 90 Szabo Akos 2005-11-25 19:14:16 UTC
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


Comment 92 Dmitry Butskoy 2005-11-29 16:39:21 UTC
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 :)

Comment 93 Andreas Bierfert 2005-11-29 16:42:14 UTC
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...

Comment 95 Adrian Reber 2005-12-12 13:26:21 UTC
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


Comment 96 Andreas Bierfert 2005-12-13 10:12:27 UTC
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?

Comment 97 Kevin Kofler 2005-12-13 12:48:33 UTC
Try -fno-stack-protector. 

Comment 98 Andreas Bierfert 2005-12-13 13:28:56 UTC
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...

Comment 99 Linus Walleij 2005-12-26 11:00:40 UTC
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.

Comment 100 Andreas Bierfert 2005-12-31 09:24:57 UTC
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...

Comment 101 Dmitry Butskoy 2005-12-31 11:16:22 UTC
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. :)

Comment 102 Linus Walleij 2005-12-31 13:20:28 UTC
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.

Comment 103 Linus Walleij 2005-12-31 13:31:44 UTC
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.

Comment 104 Linus Walleij 2005-12-31 14:31:23 UTC
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...

Comment 105 Linus Walleij 2005-12-31 23:47:46 UTC
Here is another problem:

%dir %{_datadir}/fonts/wine

need to be added so wine owns the %{_datadir}/fonts/wine/ directory.

Comment 106 Linus Walleij 2006-01-01 00:13:18 UTC
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.


Comment 107 Andreas Bierfert 2006-01-01 12:34:34 UTC
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.

Comment 108 Thorsten Leemhuis 2006-01-01 12:48:38 UTC
(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.

Comment 109 Ignacio Vazquez-Abrams 2006-01-01 13:06:32 UTC
(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.

Comment 110 Thorsten Leemhuis 2006-01-01 13:26:49 UTC
(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.


Comment 111 Thorsten Leemhuis 2006-01-01 15:33:54 UTC
(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}".

Comment 112 Linus Walleij 2006-01-01 17:23:59 UTC
The architecture exclusion stuff will obviously solve itself during build.
All other problems are successfully resolved.

APPROVED.

Comment 113 Andreas Bierfert 2006-01-02 12:10:35 UTC
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?

Comment 114 Enrico Scholz 2006-01-02 12:32:01 UTC
Adding '-fno-stack-protector' to the CFLAGS should solve comment #113

Comment 115 Enrico Scholz 2006-01-04 14:45:26 UTC
Why is there a

| Requires(postun): perl

?

Comment 116 Andreas Bierfert 2006-01-05 10:51:20 UTC
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?

Comment 117 Hans de Goede 2006-01-06 10:37:10 UTC
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


Comment 118 Alex Lancaster 2006-01-06 11:07:52 UTC
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.

Comment 119 Andreas Bierfert 2006-01-06 11:19:38 UTC
Until devel is resolved I want to keep this open ...

Comment 120 Alex Lancaster 2006-01-06 11:24:42 UTC
(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.

Comment 121 Linus Walleij 2006-01-06 20:25:54 UTC
Fixed blocking bug, sorry... (My first review.)

Comment 122 Andreas Bierfert 2006-01-07 00:02:54 UTC
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?

Comment 123 Hans de Goede 2006-01-07 08:23:02 UTC
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 .



Comment 124 Andreas Bierfert 2006-01-07 10:39:34 UTC
Hm it just inlcudes gl.h und glu.h which should be present from the mesa requires...

Comment 125 Tom "spot" Callaway 2006-01-07 15:44:12 UTC
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)

Comment 126 Ralf Corsepius 2006-01-07 17:35:21 UTC
The spec in CVS still contains:
BR: mesa-libGLw-devel

Though I haven't checked (yet), I am pretty sure wine doesn't used.



Comment 127 Andreas Bierfert 2006-01-07 23:59:35 UTC
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.

Comment 128 Andreas Bierfert 2007-04-27 23:13:26 UTC
Package Change Request
======================
Package Name: wine
New Branches: EL-5

Comment 129 Andreas Bierfert 2009-03-31 04:23:50 UTC
Package Change Request
======================
Package Name: wine
New Branches: F-11

Comment 130 Dennis Gilmore 2009-04-01 16:30:11 UTC
CVS Done


Note You need to log in before you can comment on or make changes to this bug.