Folks,
I just released 20050930, this should be considered the pre-0.9 release, so please give it some good testing. In particular, please test the things that new users will encounter first, like the automatic .wine creation and winecfg.
Even if you normally build from source, please for once try the binary package for your distro and check if you spot anything the packager is doing wrong.
Bugzilla has had a good cleanup lately (thanks guys!) and most of the irrelevant bugs have been closed, so please have a look at the remaining ones to see if there's anything you know how to fix.
We also still need many documentation updates, so please consider helping with that.
If you have scripts that handle releases, now is the time to ensure they can cope with a version number not in the YYYYMMDD format...
If all goes well, and if the documentation is updated by then, the real 0.9 should be released in a couple of weeks. In the meantime we should consider ourselves in a code freeze, so please don't submit new features or large changes, only small bug fixes will be allowed in.
Thanks everybody for your help, it has been a long trip but we are getting there...
I think we need some more clean up of bugzilla, we need to close bugs till 2003/04 which have not updates since 6 months. And also those which cannot be replicatable.
bye, Vijay
On 9/30/05, Alexandre Julliard julliard@winehq.org wrote:
Folks,
I just released 20050930, this should be considered the pre-0.9 release, so please give it some good testing. In particular, please test the things that new users will encounter first, like the automatic .wine creation and winecfg.
Even if you normally build from source, please for once try the binary package for your distro and check if you spot anything the packager is doing wrong.
Bugzilla has had a good cleanup lately (thanks guys!) and most of the irrelevant bugs have been closed, so please have a look at the remaining ones to see if there's anything you know how to fix.
We also still need many documentation updates, so please consider helping with that.
If you have scripts that handle releases, now is the time to ensure they can cope with a version number not in the YYYYMMDD format...
If all goes well, and if the documentation is updated by then, the real 0.9 should be released in a couple of weeks. In the meantime we should consider ourselves in a code freeze, so please don't submit new features or large changes, only small bug fixes will be allowed in.
Thanks everybody for your help, it has been a long trip but we are getting there...
-- Alexandre Julliard julliard@winehq.org
On 9/30/05, Alexandre Julliard julliard@winehq.org wrote:
We also still need many documentation updates, so please consider helping with that.
Is anyone actually working on this? I might have some time this weekend, but I don't want to step on any toes.
-Brian
Brian Vincent schreef:
On 9/30/05, Alexandre Julliard julliard@winehq.org wrote:
We also still need many documentation updates, so please consider helping with that.
Is anyone actually working on this? I might have some time this weekend, but I don't want to step on any toes.
-Brian
Yes, actually, but right after I volunteered I caught a really bad cold that took me some time to get over. Today is the first day that I feel healthy enough to think about complex things (but unfortunately my boyfriend caught the bug from me, so I'm not getting back up to speed as fast as I might want).
In any case, now that there's a new monthly, I can install it this evening and start "doing things like a new user" to see what the process currently looks like from that angle and what seems like it might need to be written down.
So I'm here/back.
Holly
Alexandre Julliard wrote:
We also still need many documentation updates, so please consider helping with that.
I'd like to help wherever I can. Developer docs ok?
For instance, in: http://www.winehq.com/site/docs/wine-devel/wine-debugger
the IDA debugger is hyperlinked several times.
I've searched Google for ever so long, and that file just isn't anywhere around anymore.
If it's legal and anyone has a copy, it could be stuffed on the WineHQ web site. (I'm serious - it's nowhere to be found!)
Otherwise the documentation should just be updated to mention some other debugger, GoVest for instance.
Question is, how do I convey updates to the documentation to you guys?
Running 'diff' is not hard, but.... Where can I find the source for the documentation?
It's not in the SVN repo I'm pulling off Troy's server, it seems.. I assume you store it in a CVS repository next to the source code repo? Where do I find it?
Apologies for being so noob :-p..
On 10/1/05, Molle Bestefich molle.bestefich@gmail.com wrote:
Question is, how do I convey updates to the documentation to you guys?
Tom described it here: http://www.winehq.com/?issue=291#Docs%20Needed
-Brian
On 10/1/05, Brian Vincent brian.vincent@gmail.com wrote:
On 10/1/05, Molle Bestefich molle.bestefich@gmail.com wrote:
Question is, how do I convey updates to the documentation to you guys?
Tom described it here: http://www.winehq.com/?issue=291#Docs%20Needed
Oops. Thanks!
If anyone has the copy of IDA that the current guide mentions, or know whether it is functionally equivalent with some other product, please speak up.
On 10/1/05, Molle Bestefich molle.bestefich@gmail.com wrote:
If anyone has the copy of IDA that the current guide mentions, or know whether it is functionally equivalent with some other product, please speak up.
That's odd..
Anyway, the filename here has "demo" in it, so I'm not sure if this is the full IDA Pro everyone has used in the past. Uwe would probably know since he seems to use/test it a lot. http://www.download.com/IDA-The-Interactive-Disassembler/3000-2218_4-1036151...
If that isn't it, maybe one of these will work: http://www.themel.com/idafree.zip http://www.dirfile.com/ida_pro_freeware_version.htm#
From the IDA Pro page about why they don't host it:
"The distribution of our freeware version was using insane amounts of bandwdith, several hundreds of them are delivered each day. Here is for example an Analog report for Dec 2002 and Jan 2003
20013: 93.98%: 27/Jan/03 23:18: /freefiles/freeware.zip
One of our hopes in distributing this freeware version had been that it would diminish the number "pirate" contacts. Unfortunately, this has not been the case. That is why, after having delivered hundreds of thousands of copies of IDA Freeware, we have decided not to host this file anymore. Note that the IDA Pro freeware license doesn't change : the freeware version remains freeware, and anyone willing to host it is welcome to do so."
-Brian
Brian Vincent wrote:
Anyway, the filename here has "demo" in it, so I'm not sure if this is the full IDA Pro everyone has used in the past. http://www.download.com/IDA-The-Interactive-Disassembler/3000-2218_4-1036151...
No-go, that version expires in 1998.
There's a newer (4.8) IDA Pro demo, but alas, it cannot be installed under WINE CVS HEAD :-/.
Same goes for IDA Pro 4.3 freebie edition.
If that isn't it, maybe one of these will work: http://www.themel.com/idafree.zip
Seems to run, but after that it just hangs. Anyone?
From the IDA Pro page about why they don't host it: "The distribution of our freeware version was using insane amounts of bandwdith, several hundreds of them are delivered each day.
Thanks!
Thanks!
Francois Gouget wrote:
WineHQ's CVS page should be updated with instructions on how to get the documentation:
http://www.winehq.com/site/cvs
Thanks!
Where we're at now: * None of the IDA versions actually both install and work under Wine. * WDASM installs but, ehrr, it looks .. wrong. * GoVest looks good, except that it cries about MapDebugInformation and SymInitialize being stubs. * Also, the documentation is horribly outdated and plain wrong in some places.
I've updated the docs to reflect the current state of affairs. Patch forthcoming.....
Where we're at now:
- None of the IDA versions actually both install and work under Wine.
You can buy it. It then comes with a Linux console version.
Its however pretty high priced.
The Windows GUI version of IDA works fine, the Win32 console version too. Don't remember the install anymore ;)
Ciao, Marcus
Marcus Meissner wrote:
Where we're at now:
- None of the IDA versions actually both install and work under Wine.
You can buy it. It then comes with a Linux console version.
Its however pretty high priced.
Hehe. Guess that's not an option, then.
The Windows GUI version of IDA works fine, the Win32 console version too. Don't remember the install anymore ;)
The broken installer is a show-stopper, as far as a debugging guide goes. We can't very well tell people reading the guide that they should install IDA when that in fact is impossible.
For now, I've referenced GoVest at the top of the page (although the IDA references are still there). If IDA starts working again, I'd be happy to update the documentation to reflect this.
Other options? Maybe mention in the guide how to manually extract the IDA executables from the installer? Anybody knows how this can be accomplished?
On Sun, 2005-10-02 at 20:18 +0000, Molle Bestefich wrote:
Brian Vincent wrote:
Anyway, the filename here has "demo" in it, so I'm not sure if this is the full IDA Pro everyone has used in the past. http://www.download.com/IDA-The-Interactive-Disassembler/3000-2218_4-1036151...
No-go, that version expires in 1998.
There's a newer (4.8) IDA Pro demo, but alas, it cannot be installed under WINE CVS HEAD :-/.
That's odd...I got IDA 4.8 demo to install and work without any problems at all. Perhaps something broke recently? What sort of errors do you get?
James
James Liggett wrote:
Molle Bestefich wrote:
There's a newer (4.8) IDA Pro demo, but alas, it cannot be installed under WINE CVS HEAD :-/.
That's odd...I got IDA 4.8 demo to install and work without any problems at all. Perhaps something broke recently?
Must have. Recently? Not so sure. I've tweaked the docs to reflect this (point to idafree 3.85b, which is the only ida that works right now - sort of, and GoVest) in the meantime.
What sort of errors do you get?
The installer can't create it's installation directory. Creating the directory manually does not help. Creating the directory it would've created - manually, then pointing the installer to the parent directory does not help. Using UNC paths and similar hacks does not help, as the installer truncates '\' to ''. Tried with CVS from yesterday and about a week ago. Tried nuking ~/.wine and recreating it, that didn't help either.
Now that I think about it, there's one more thing I could try: Replacing \ with / - I'll give that a shot when I get near a Wine box again.
If you get it working, let me know, I'll be happy to tweak the docs again.
On 10/3/05, Molle Bestefich molle.bestefich@gmail.com wrote:
What sort of errors do you get?
The installer can't create it's installation directory. Creating the directory manually does not help.
For now you have to use native comctl32 to install some apps.
-- James Hawkins
On Sat, 1 Oct 2005, Brian Vincent wrote:
On 10/1/05, Molle Bestefich molle.bestefich@gmail.com wrote:
Question is, how do I convey updates to the documentation to you guys?
Tom described it here: http://www.winehq.com/?issue=291#Docs%20Needed
WineHQ's CVS page should be updated with instructions on how to get the documentation:
http://www.winehq.com/site/cvs
Btw, why not put the Wine documentation in the same CVS as the Wine sources, Website, the AppDB, etc. It seems like this would simplify explaining how to get it a lot (and it would automatically work with cvsup too).
On Sat, 2005-10-01 at 20:12 +0200, Francois Gouget wrote:
Btw, why not put the Wine documentation in the same CVS as the Wine sources, Website, the AppDB, etc. It seems like this would simplify explaining how to get it a lot (and it would automatically work with cvsup too).
It's just simpler this way, we can easily add committers, etc. We can add some info on the CVS page about it though, that should help, right now we don't have anything about it up on the site. No wonder people are confused.
On 10/1/05, Francois Gouget fgouget@free.fr wrote:
On Sat, 1 Oct 2005, Brian Vincent wrote:
On 10/1/05, Molle Bestefich molle.bestefich@gmail.com wrote:
Question is, how do I convey updates to the documentation to you guys?
Tom described it here: http://www.winehq.com/?issue=291#Docs%20Needed
WineHQ's CVS page should be updated with instructions on how to get the documentation:
http://www.winehq.com/site/cvs
I see this is done now.
Btw, why not put the Wine documentation in the same CVS as the Wine sources, Website, the AppDB, etc. It seems like this would simplify explaining how to get it a lot (and it would automatically work with cvsup too).
When Newman gets a chance it would be a good idea to sync the FAQ currently on WineHQ with the current FAQ on source forge. There is a Q/A in the FAQ that points out how to get the Doc's.
-Tom
Alexandre Julliard schreef:
Folks,
I just released 20050930, this should be considered the pre-0.9 release, so please give it some good testing. In particular, please test the things that new users will encounter first, like the automatic .wine creation and winecfg.
Even if you normally build from source, please for once try the binary package for your distro and check if you spot anything the packager is doing wrong.
I'm a Gentoo user, and when I installed the package, I received the following rather alarming message at the end of the output (end of compile and beginning of merge included so you can see where it falls, but you'll easily be able to identify the message I'm talking about):
make[2]: Leaving directory `/var/tmp/portage/wine-20050930/work/wine-20050930/tools/wrc' ../tools/mkinstalldirs -m 755 /var/tmp/portage/wine-20050930/image//usr/bin /var/tmp/portage/wine-20050930/image//us r/share/man/man1 /bin/install -c ./winemaker /var/tmp/portage/wine-20050930/image//usr/bin/winemaker /bin/install -c -m 644 ./winemaker.man /var/tmp/portage/wine-20050930/image//usr/share/man/man1/winemaker.1 make[1]: Leaving directory `/var/tmp/portage/wine-20050930/work/wine-20050930/tools' ./tools/mkinstalldirs -m 755 /var/tmp/portage/wine-20050930/image//usr/share/aclocal mkdir -m 755 -p -- /var/tmp/portage/wine-20050930/image//usr/share/aclocal /bin/install -c -m 644 ./aclocal.m4 /var/tmp/portage/wine-20050930/image//usr/share/aclocal/wine.m4 /bin/true ************************************************* ************************************************* The installed Wine libraries will not be found! You can either: Add the line '/var/tmp/portage/wine-20050930/image//usr/lib' to /etc/ld.so.conf and run /sbin/ldconfig export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/var/tmp/portage/wine-20050930/image//usr/lib ************************************************* ************************************************* man: fixing man page symlink: wineg++.1.gz removing old symlink: wineg++.1 gzipping man page: winedbg.1 gzipping man page: winegcc.1 gzipping man page: wmc.1 gzipping man page: wrc.1 gzipping man page: winebuild.1 gzipping man page: winemaker.1 gzipping man page: widl.1 gzipping man page: wine.1 gzipping man page: wineserver.1 gzipping man page: winedump.1 prepallstrip: strip: i686-pc-linux-gnu-strip --strip-unneeded strip: i686-pc-linux-gnu-strip --strip-unneeded usr/bin/wmc usr/bin/wrc usr/bin/widl usr/bin/wine usr/bin/wineserver usr/bin/winebuild usr/bin/wine-pthread usr/bin/wine-kthread usr/bin/winedump usr/bin/winegcc usr/bin/wine-preloader usr/lib/wine/mapi32.dll.so
There are a number of problems with this instruction:
1) Many users won't see it, since many users prefer not to watch their output (certainly not for long compiles like Wine), and if they don't have a long scrollback buffer like I do, the only thing they will see is that the emerge completed successfully (so they will not do this step, with unknown consequences);
2) This message is not an einfo (thus not present in the ebuild, it is, of course in the emerge.log file for this emerge); it appears to be generated by the compile process itself, so I'm unsure if it's an ebuild problem or a global compilation problem. Further, I have no indication whatsoever whether the Portage performed this operation on my behalf or not;
3) The directory /var/tmp/portage/wine-20050930 does not exist on my system (which is abnormal in and of itself, as directories from all other Wine emerges do exist in /var/tmp/portage, as do directories for all other applications I've emerged), and even if it did, if the emerge completed successfully, there should be no files remaining in /var/tmp/portage/whatever, since a successful emerge leaves only a /temp directory containing a .keep file and a eclass-debug.log file (at least that's what's left in all the other /var/tmp/portage/wine-version directories I do have on my system). So I cannot even follow this instruction after the emerge is completed (which would be my first opportunity to do so), as the files I'm supposed to update my environment with no longer exist at the location I'm asked to use.
I don't even know how to debug this-- or even if it needs debugging-- as I don't know how to tell the difference between how Wine would act if the libraries cannot be found because of a lack of this update, and how Wine acts when the environment has been correctly updated.
I don't know if this is a flaw in the Gentoo emerge process, or the Wine compilation, or even if it's a problem at all (maybe the environment has been updated properly, but I got this message anyway, in error).
And if it needs to be fixed (i.e., if I do need to add information to /etc/ld.so.conf), I don't know what to add.
At this point, I've got Wine installed, but haven't even tried firstrun, as I don't know if my install is good or not, or whether I might cause even more obfuscation by running wine, winecfg, or by attempting to actually use Wine to install something.
Can anyone clarify what's going on here, and whether I'm worrying unnecessarily or not?
Thanks, Holly
I don't even know how to debug this-- or even if it needs debugging-- as I don't know how to tell the difference between how Wine would act if the libraries cannot be found because of a lack of this update, and how Wine acts when the environment has been correctly updated.
My $.02 is if you're crazy enough to use a distro that requires everything to be compiled from scratch, then you better be capable of understanding everything that entails. The same goes for anyone compiling Wine from source. If that means editing /etc/ld.so.conf so the linker can find your libraries, then so be it. Otherwise, it's best to stick with the binaries.
Maybe we need to collect things like this into a "Release Notes" page on the wiki? In this case it would look something like, "GENTOO USERS: After placing the bullets in the chamber, pointing the gun at your foot, and typing emerge you'll need to make some small changes. As root, type "(echo '/usr/local/lib' >> /etc/ld.so.conf) && ldconfig -v".
WTF is with /var/tmp/portage/wine-20050930/image//usr/lib ...
-Brian
On Sunday 02 October 2005 5:45 pm, Brian Vincent wrote:
Maybe we need to collect things like this into a "Release Notes" page on the wiki? In this case it would look something like, "GENTOO USERS: After placing the bullets in the chamber, pointing the gun at your foot, and typing emerge you'll need to make some small changes. As root, type "(echo '/usr/local/lib' >> /etc/ld.so.conf) && ldconfig -v".
IMO the ebuild sounds slightly broken
WTF is with /var/tmp/portage/wine-20050930/image//usr/lib ...
portage builds/installs the package in a sandbox located in /var/tmp/portage, once the build is successful it copies the files to the appropriate locations and records which files it copied where
Le dimanche 02 octobre 2005 à 15:45 -0600, Brian Vincent a écrit :
I don't even know how to debug this-- or even if it needs debugging-- as I don't know how to tell the difference between how Wine would act if the libraries cannot be found because of a lack of this update, and how Wine acts when the environment has been correctly updated.
My $.02 is if you're crazy enough to use a distro that requires everything to be compiled from scratch, then you better be capable of understanding everything that entails. The same goes for anyone compiling Wine from source. If that means editing /etc/ld.so.conf so the linker can find your libraries, then so be it. Otherwise, it's best to stick with the binaries.
Maybe we need to collect things like this into a "Release Notes" page on the wiki? In this case it would look something like, "GENTOO USERS: After placing the bullets in the chamber, pointing the gun at your foot, and typing emerge you'll need to make some small changes. As root, type "(echo '/usr/local/lib' >> /etc/ld.so.conf) && ldconfig -v".
WTF is with /var/tmp/portage/wine-20050930/image//usr/lib ...
Gentoo builds everything in some sandbox in /var/tmp and then copies everything in the right places. Wine seems to think files will stay in that directory altough they won't. However I'm quite sure everything will work as expected.
IMO you should open a bug in gentoo's bugzilla telling them to apply a patch that removes this warning before to build wine as this warning doesn't apply to gentoo users.
Altough it can seem crazy to compile everything from scratch, I never had to fix any paths in ld.so.conf under gentoo; if something works well under gentoo, that'd be the emerge process configuration update tool.
Bye,
Jonathan Ernst schreef:
Le dimanche 02 octobre 2005 à 15:45 -0600, Brian Vincent a écrit :
I don't even know how to debug this-- or even if it needs debugging-- as I don't know how to tell the difference between how Wine would act if the libraries cannot be found because of a lack of this update, and how Wine acts when the environment has been correctly updated.
My $.02 is if you're crazy enough to use a distro that requires everything to be compiled from scratch, then you better be capable of understanding everything that entails. The same goes for anyone compiling Wine from source. If that means editing /etc/ld.so.conf so the linker can find your libraries, then so be it. Otherwise, it's best to stick with the binaries.
Well, obviously, the ebuild + source tarball *is* my binary, as it were. It's not like I can effectively use SuSE or FC 4 rpms.
So we 'crazy' source-based distro users can go jump, huh? Thanks :) . Funny, I'd call some of the 'pure' users on Wine-Users a lot crazier than I am, given some of the ways they try to use Wine....
Maybe we need to collect things like this into a "Release Notes" page on the wiki? In this case it would look something like, "GENTOO USERS: After placing the bullets in the chamber, pointing the gun at your foot, and typing emerge you'll need to make some small changes. As root, type "(echo '/usr/local/lib' >> /etc/ld.so.conf) && ldconfig -v".
Well that was actually my ultimate question, since I'm working on docs-- if this was in fact a step I needed to find a way to perform, I would document it. But for that I'd have to know what to do, which required knowing the nature of the problem, which I didn't.
WTF is with /var/tmp/portage/wine-20050930/image//usr/lib ...
Gentoo builds everything in some sandbox in /var/tmp and then copies everything in the right places. Wine seems to think files will stay in that directory altough they won't. However I'm quite sure everything will work as expected.
IMO you should open a bug in gentoo's bugzilla telling them to apply a patch that removes this warning before to build wine as this warning doesn't apply to gentoo users.
OK, thanks for the pointer-- my main problem was knowing if the issue was the ebuild or the actual compilation process.
bugzilla.gentoo.org (b.g.o.) I can handle.
And thanks for the confirmation that everything ought to work normally (which I would have expected, despite the warning)-- but given our past and current issues with binary compilation, and given that we were specifically asked to check for anomalies in binary installation, I just wanted to be sure.
Altough it can seem crazy to compile everything from scratch, I never had to fix any paths in ld.so.conf under gentoo; if something works well under gentoo, that'd be the emerge process configuration update tool.
It really depends on your usage needs as to whether compiling everything from scratch is crazy or not. Clearly a 500-seat or more enterprise workstation farm does not have the time or energy most of the time, but I do. And it gives me a nice sandbox to learn in, since Portage does generally work very well, and since I can see what it did, I can begin to 'understand everything that the compilation process entails'.
But OK, enough chitchat, I'm off to post a bug for this-- I'll post the bug number here in case anyone wants to follow it.
Thanks for the help, I'm looking forward to taking 20050930 for a spin.
Holly
P.S. --Jonathan, been meaning to ask you; is it possible for you to upload your public GPG to a server somewhere? It would be nice to get rid of the yellow "Unverified Signature" warning I get from Enigmail every time I read a mail from you. Obviously not critical but thought I'd ask.
Holly
Le lundi 03 octobre 2005 à 12:19 +0200, Holly Bostick a écrit : [...]
P.S. --Jonathan, been meaning to ask you; is it possible for you to upload your public GPG to a server somewhere? It would be nice to get rid of the yellow "Unverified Signature" warning I get from Enigmail every time I read a mail from you. Obviously not critical but thought I'd ask.
I sent them to keyserver.net; hope it works
On 10/3/05, Jonathan Ernst Jonathan@ernstfamily.ch wrote:
Gentoo builds everything in some sandbox in /var/tmp and then copies everything in the right places. Wine seems to think files will stay in that directory altough they won't. However I'm quite sure everything will work as expected.
There were reports about 6 to 9 months ago of Gentoo having problems with Wine. Can you guys confirm everything is ok now? If so, we should just get that fixed in Gentoo's build process.
(By the way, I wasn't knocking Gentoo. I've used it and I've been pleasantly surprised that it just works. Honestly, I don't see any realy improvement that would make me think it was better than other distros, but it is pretty neat. My only gripe is we have some local LUG members who push it as a beginning Linux distro and I don't think it's a good choice for that.)
-Brian
Le lundi 03 octobre 2005 à 10:13 -0600, Brian Vincent a écrit :
On 10/3/05, Jonathan Ernst Jonathan@ernstfamily.ch wrote:
Gentoo builds everything in some sandbox in /var/tmp and then copies everything in the right places. Wine seems to think files will stay in that directory altough they won't. However I'm quite sure everything will work as expected.
There were reports about 6 to 9 months ago of Gentoo having problems with Wine. Can you guys confirm everything is ok now? If so, we should just get that fixed in Gentoo's build process.
Yes everything is ok and Gentoo keeps bringing new releases of Wine much faster than any other distro I know of.
(By the way, I wasn't knocking Gentoo. I've used it and I've been pleasantly surprised that it just works. Honestly, I don't see any realy improvement that would make me think it was better than other distros, but it is pretty neat. My only gripe is we have some local LUG members who push it as a beginning Linux distro and I don't think it's a good choice for that.)
Agreed.
Brian Vincent schreef:
On 10/3/05, Jonathan Ernst Jonathan@ernstfamily.ch wrote:
Gentoo builds everything in some sandbox in /var/tmp and then copies everything in the right places. Wine seems to think files will stay in that directory altough they won't. However I'm quite sure everything will work as expected.
There were reports about 6 to 9 months ago of Gentoo having problems with Wine. Can you guys confirm everything is ok now? If so, we should just get that fixed in Gentoo's build process.
(By the way, I wasn't knocking Gentoo. I've used it and I've been pleasantly surprised that it just works. Honestly, I don't see any realy improvement that would make me think it was better than other distros, but it is pretty neat. My only gripe is we have some local LUG members who push it as a beginning Linux distro and I don't think it's a good choice for that.)
-Brian
As far as I know, Gentoo (along with many other distros) cleaned up their act w.r.t wine several months ago (when Mike Hearn, I believe, got the various maintainers to *pay attention* to Wine development, rather than just assuming that everything built the same as it had previously month after month-- when it couldn't because so many changes were going on).
So Wine has been working fine for me for some time (or rather, it's been working so fine as possible, without any issues I would specifically attribute to the distribution build process).
In any case, the bug on b.g.o. can be found here:
http://bugs.gentoo.org/show_bug.cgi?id=107971
If you don't want to go by, the bug has been downgraded from 'normal' to 'trivial' (which it rather is), and a suggestion has been made that, rather than writing a patch against the wine sources (and having to maintain it), an einfo should be added to the ebuild telling users to ignore the message from the compilation process.
Which seems a quite reasonable solution that I would expect will be implemented. So I'd call that 'off my plate', myself :) . But then again, I've got plenty to do, so....
Holly
Holly Bostick wrote:
If you don't want to go by, the bug has been downgraded from 'normal' to 'trivial' (which it rather is), and a suggestion has been made that, rather than writing a patch against the wine sources (and having to maintain it), an einfo should be added to the ebuild telling users to ignore the message from the compilation process.
Which seems a quite reasonable solution that I would expect will be implemented. So I'd call that 'off my plate', myself :) . But then again, I've got plenty to do, so....
Is anyone building wine for Debian anymore?
//Jakob
deb http://wine.sourceforge.net/apt/ binary/
On Mon, 03 Oct 2005 19:15:20 +0200, Holly Bostick wrote:
As far as I know, Gentoo (along with many other distros) cleaned up their act w.r.t wine several months ago (when Mike Hearn, I believe, got the various maintainers to *pay attention* to Wine development, rather than just assuming that everything built the same as it had previously month after month-- when it couldn't because so many changes were going on).
While I'd love to take credit for that, it was actually Vincent Beron who beat up the Gentoo guys. I just bitched about it a lot :)
thanks -mike
-
Alexandre Julliard -
Brian Vincent -
Dimi Paun -
Francois Gouget -
Holly Bostick -
Jakob Eriksson -
James Hawkins -
James Liggett -
Jonathan Ernst -
Kevin Koltzau -
Marcus Meissner -
Mike Hearn -
Molle Bestefich -
Tom Wickline -
Vijay Kiran Kamuju