30 Sep
2005
30 Sep
'05
12:51 p.m.
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(a)winehq.org
30 Sep
30 Sep
1:09 p.m.
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(a)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(a)winehq.org
3:49 p.m.
Brian Vincent schreef:
On 9/30/05, Alexandre Julliard
<julliard(a)winehq.org> wrote:
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
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
1 Oct
1 Oct
2 p.m.
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..
4:24 p.m.
On 10/1/05, Molle Bestefich <molle.bestefich(a)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
4:43 p.m.
On 10/1/05, Brian Vincent <brian.vincent(a)gmail.com> wrote:
On 10/1/05, Molle Bestefich
<molle.bestefich(a)gmail.com> wrote:
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.
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
5:18 p.m.
On 10/1/05, Molle Bestefich <molle.bestefich(a)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-103615…
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
2 Oct
2 Oct
8:18 p.m.
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-103615…
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.....
9:20 p.m.
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
9:23 p.m.
Marcus Meissner wrote:
Hehe. Guess that's not an option, then.
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 ;)
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?
11:40 p.m.
On Sun, 2005-10-02 at 20:18 +0000, Molle Bestefich wrote:
Brian Vincent wrote:
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
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-103615…
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 :-/.
3 Oct
3 Oct
8:52 a.m.
James Liggett wrote:
Molle Bestefich wrote:
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.
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?
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.
3:20 p.m.
On 10/3/05, Molle Bestefich <molle.bestefich(a)gmail.com> wrote:
For now you have to use native comctl32 to install some apps.
--
James Hawkins
What sort of errors do you get?
The installer can't create it's installation directory.
Creating the directory manually does not help.
1 Oct
1 Oct
6:12 p.m.
On Sat, 1 Oct 2005, Brian Vincent wrote:
On 10/1/05, Molle Bestefich
<molle.bestefich(a)gmail.com> wrote:
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).
--
Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/
"Utilisateur" (nom commun) :
Mot utilisé par les informaticiens en lieu et place d'"idiot".
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 
3 Oct
3 Oct
4:37 a.m.
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.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
11 Oct
11 Oct
10:31 p.m.
On 10/1/05, Francois Gouget <fgouget(a)free.fr> wrote:
On Sat, 1 Oct 2005, Brian Vincent wrote:
I see this is done now.
On 10/1/05, Molle Bestefich
<molle.bestefich(a)gmail.com> wrote:
WineHQ's CVS page should be updated with instructions on how to get the
documentation:
http://www.winehq.com/site/cvs 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
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
2 Oct
2 Oct
9:07 p.m.
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
9:45 p.m.
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
3 Oct
3 Oct
1:53 a.m.
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
8:57 a.m.
Le dimanche 02 octobre 2005 à 15:45 -0600, Brian Vincent a écrit :
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,
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 ...
10:19 a.m.
Jonathan Ernst schreef:
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.
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.
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
10:42 a.m.
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
4:13 p.m.
On 10/3/05, Jonathan Ernst <Jonathan(a)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
4:25 p.m.
Le lundi 03 octobre 2005 à 10:13 -0600, Brian Vincent a écrit :
On 10/3/05, Jonathan Ernst
<Jonathan(a)ernstfamily.ch> wrote:
Yes everything is ok and Gentoo keeps bringing new releases of Wine much
faster than any other distro I know of.
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.)
Agreed.
5:15 p.m.
Brian Vincent schreef:
On 10/3/05, Jonathan Ernst
<Jonathan(a)ernstfamily.ch> 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).
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
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
8:22 p.m.
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/
6 Oct
6 Oct
10:39 a.m.
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
6780
days inactive
6791
days old
27 comments
15 participants
participants (15)
-
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