Re: Closing fixed bugs
On Saturday 14 February 2009, Dan Kegel wrote: A few months ago, Alexandre started including lists of fixed bugs in his release announcements. See e.g. http://www.winehq.org/announce/1.1.15, which says Bugs fixed in 1.1.15: 5694 Lionhead Black White 2 demo crashes 7014 Unhandled page fault when exiting Commandos - BEL 7297 MIDI in/out fails, ports recognized ... I rather like those lists. He generates them by simply querying for open but fixed bugs right when he does the release; he then closes the bugs. They're good for PR if nothing else. For this to work, we have to let Alexandre be the only person to close fixed bugs. (Of course, it's ok for other people to mark bugs fixed, and it's ok for anyone to close invalid or dup bugs.) If anybody else closes a fixed bug, it won't show up in the list of fixed bugs for any release. A corner case is when a bug is marked fixed sometime after release. I think it's ok to leave it for Alexandre to close; that way it shows up in at least one release announcement. Even if it shows up a few releases late, that's better than not showing up at all. Sound reasonable? I ask because Vitaliy closed http://bugs.winehq.org/show_bug.cgi?id=10923 even after I tried to explain this to him, so I figured it needed a wider discussion. - Dan Couldn't you just query Bugzilla for all the bugs closed between $release and $lastrelease? - Neil
Re: Regression in wined3d: Add read_from_framebuffer_texture which combines code from read_from_framebuffer (drawpixels) and LoadLocation.
On Friday 23 May 2008, Markus wrote: Hi, after investigating reports for the game 'World in Conflict', I identified the following patch to cause the game graphics to freeze (ambient sounds are still played though): ba90a740beb9ce9a839cc843db8d87f5a37becdd is first bad commit commit ba90a740beb9ce9a839cc843db8d87f5a37becdd Author: Roderick Colenbrander [EMAIL PROTECTED] Date: Sun Feb 10 22:20:15 2008 +0100 wined3d: Add read_from_framebuffer_texture which combines code from read_from_framebuffer (drawpixels) and LoadLocation. This makes the code easier to read and the pieces borrowed from read_from_framebuffer are more correct than the code in LoadLocation. :04 04 74e4bdc73e367c8f38cd3d0818df0fc86eb788bf 3e54409be7c9d2964efbf3d3c2f3d3b84a267047 M dlls The freezes only seem to occur if the native (Windows) dxdiagn.dll is used, as it lets the game properly detect the graphics card and thus enables additional graphics options (highend shaders, high-res textures, etc.). Apparently the freeze is only triggered with these options active. The game uses events in its drawing code and (always) hangs after the following output: fixme:d3d9:D3DPERF_BeginEvent (color 0x, name LUpdate verlet cloth) : stub fixme:d3d9:D3DPERF_EndEvent (void) : stub At one point, it was followed by this error: err:d3d_surface:surface_prepare_system_memory Surface without memory or pbo has SFLAG_INSYSMEM set! The point of the freeze appears to depend on many factors. If I move the camera around, it appears to freeze earlier than just letting the game run (e.g. a replay of a match). But once the patch is excluded, the game no longer freezes. If more info is needed, please specify how I can obtain it. Could you file a bug with the above information? Otherwise it's likely to get lost/forgotten. - Neil
Re: Wine broken in feisty/git
On Tuesday 01 April 2008, Alexandre Julliard wrote: Austin English [EMAIL PROTECTED] writes: On 4/1/08, Lei Zhang [EMAIL PROTECTED] wrote: Git bisect says: 0a44a778f00c5283347646083f682333c11bccf3 is first bad commit commit 0a44a778f00c5283347646083f682333c11bccf3 Author: Aric Stewart [EMAIL PROTECTED] Date: Mon Mar 31 09:15:29 2008 -0500 imm32: Begin to add basic framework for loading IMEs as dlls. Yep, broken on Hardy as well, haven't tested gutsy. Reverting that commit fixes it. I committed a fix. This broke for me on Gentoo too, the fix also fixed things for me. - Neil
Re: developing hints appreciated
On Thursday 20 March 2008, Marcel Partap wrote: Then run wine with LD_LIBRARY_PATH=/pathtoyourwinetree/libs /pathtoyourwinetree/wine something.exe... I'm pretty sure you don't need to set LD_LIBRARY_PATH there, at least I've never needed to (and the wine script appears to do that). - Neil
Re: [1/10] - [10/10] WineD3D
On Wednesday 14 February 2007, Mirek wrote: Luke Bratch napsal(a): Wow, great work! 3DMark 2006 with fbo looks realy coool!! And some Nvidia SDK demos are completly fixed! How did you test 3DMark2006? When I try and run it, it tells me I need Pixel Shader 2.0 support. I have UseGLSL set to enabled and OffscreenRenderMode set to fbo, and the Pixel Shader 2 test in 3DMark03 works fine. Yes, but after accept this error message i can select some test and run benchmark, i have full version v102. I can't run any PS3 HDR test, GT1 and GT2 tests are almost perfect, but very slow (fbo is slower than backbuffer, so I am not using it in other applications), you should also disable post procesing (very very slow) in 3DMark. Here are some screenshots with latest wine and latest Stefan patches: http://62.240.181.87/Mirek/3DMark2006/ PS: I have GF 6800GS, Core 2 Duo [EMAIL PROTECTED] and about 2 FPS, but it works! :) Mirek 3DMark 05 and 06 are quite picky about caps, there's a few that are slightly off and it refuses to run, you can apply this hack to make it work: http://otc.dyndns.org/stuff/wineshots/3dmark_capshack.patch This may also be of interest: http://bugs.winehq.org/show_bug.cgi?id=7434 - Neil
Re: Looking for sound testers
On Thursday, December 28, 2006 10:04, Maarten Lankhorst wrote: Hi all, I've forward ported the old patches of Davin McCall (dsound.patch). With them I have no more sound underruns etc, I'm therefore looking for other people to test them as well. I'm welcoming comments on how it works and possible issues with it. I also attached my patch to alsa, I'm aware of the things I need to fix for that, but I thought it might be good to test dsound with winealsa, to see if other things still need to be fixed. Cheers, Maarten I've given this a spin with Icewind Dale, and while it does seem to remove the underrun issues (at least I don't see them spit out anymore), the sound still stutters and crackles just as much as before. - Neil
Re: Wine Version String
On Saturday, November 18, 2006 18:17, Robert Lunnon wrote: Somewhere between Version 0.9.23 and Version 0.9.25 the version string format changed from Wine X.X.X to wine-X.X.X Can we please decide on a version string format and stick to it so packaging can be reasonably automated. Bob I think that's a result of the new git version magic, for example: $ ./wine --version wine-0.9.25-gef2c062 Presumably the gef2c062 allows one to identify the exact sources used to build that version, but for release builds just the tag is sufficient. - Neil
Re: Question: Convert source tarball to GIT repository
On Thursday, October 19, 2006 17:04, Matthew Kehrer wrote: Is there a way I can convert a source tarball I download to a local GIT repository? I have dial-up a home, but I know of a place where I can bring my flash drive and use it to get the tarball as GIT does not have resume support. Is this possible? Thanks. I doubt it. Is there any reason you can't copy the git repository onto your flash drive? - Neil
Re: compiling wine for amd64 on ubuntu dapper 6.06
On Monday, October 02, 2006 10:28, Gerald Britton wrote: Is there a command to verify if the libs are 32- or 64-bit? Try file: [EMAIL PROTECTED] ~ $ file /lib/libz.so.1.2.3 /lib/libz.so.1.2.3: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped [EMAIL PROTECTED] ~ $ file /emul/linux/x86/lib/libz.so.1.2.3 /emul/linux/x86/lib/libz.so.1.2.3: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped - Neil
Re: a-10 cuba directdraw regression
On Sunday, October 01, 2006 15:24, Matheus Izvekov wrote: Hi, a-10 cuba used to work on older versions of wine, but now there are 2 regressions: when you are in the mission selection window and you start the game by clicking in fly mission button, this window keeps on top of the directdraw window, making the game unplayable. Changing resolution in the preferences window doesnt change the resolution per se, but the game draws in-game windows and fonts bigger, making everything look weird. What looks suspect is this: fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x16cfd0)-((nil),0008) fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x16cfd0)-(0x10046,0013) Ive read the description of this function, and those 2 errors seem related to that. you can download the demo (7mb) from: http://www.gamershell.com/download_8121.shtml It exhibits those 2 problems as well, exactly like the full game. Other than that, and directplay and joystick support, the game is 100% fine, and i hope by fixing that the game could go silver. Thank you. For something like this, you should create a bug in Bugzilla for this, see here: http://bugs.winehq.org. Add the url for the demo and keyword the bug with regression and download. Also, it would be ideal if you could do a regression test with git, then you can pinpoint the specific patch which broke it, see section 6 here: http://wiki.winehq.org/GitWine. I tried the demo in today's git and it seems to be fine (although I had to set the Windows version to 98, when reporting 2000 it bombs out saying that it doesn't support NT yet), although setting the resolution to 1024x768 didn't seem to change anything. Were you running this in a virtual desktop? I was. - Neil
Re: compiling wine for amd64
On Thursday, September 21, 2006 15:30, Gerald Britton wrote:
Hi -- I'm running ubuntu dapper on amd64. I want to compile wine
but am hitting problems. I got the dependencies just fine, but the
compile died. Here's what I get:
$ sudo apt-get -y --build source wine
Reading package lists... Done
Building dependency tree... Done
Skipping the already downloaded file
'wine_0.9.21~winehq0~ubuntu~6.06-1.dsc' Skipping the already downloaded
file
'wine_0.9.21~winehq0~ubuntu~6.06.orig.tar.gz'
Skipping the already downloaded file
'wine_0.9.21~winehq0~ubuntu~6.06-1.diff.gz' Need to get 0B of source
archives.
Skipping unpack of already unpacked source in
wine-0.9.21~winehq0~ubuntu~6.06 dpkg-buildpackage: source package is wine
dpkg-buildpackage: source version is 0.9.21~winehq0~ubuntu~6.06-1
dpkg-buildpackage: source changed by Scott Ritchie [EMAIL PROTECTED]
dpkg-buildpackage: host architecture amd64
debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp
# Add here commands to clean up after the build process.
/usr/bin/make distclean
make[1]: Entering directory `/home/jerryb/wine-0.9.21~winehq0~ubuntu~6.06'
make[1]: *** No rule to make target `distclean'. Stop.
make[1]: Leaving directory `/home/jerryb/wine-0.9.21~winehq0~ubuntu~6.06'
make: [clean] Error 2 (ignored)
#-/usr/bin/make -C documentation clean
cp -f /usr/share/misc/config.sub config.sub
cp -f /usr/share/misc/config.guess config.guess
dh_clean
debian/rules build
dh_testdir
# Add here commands to configure the package.
CFLAGS=-Wall -g -O2 ./configure --host=x86_64-linux-gnu
--build=x86_64-linux-gnu --prefix=/usr --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking whether make sets $(MAKE)... yes
checking for x86_64-linux-gnu-gcc... gcc -m32
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
make: *** [config.status] Error 77
Build command 'cd wine-0.9.21~winehq0~ubuntu~6.06 dpkg-buildpackage
-b -uc' failed.
E: Child process failed
I attached the config.log. What must I do to complete the compiles?
You probably don't have any 32 bit emul libraries installed. See
http://wiki.winehq.org/WineOn64bit for more details.
- Neil
Re: Problem with a Turbolog4.exe application under wine
On Sunday, September 17, 2006 06:02, James Courtier-Dutton wrote: Hi, A demo version of Turbolog4 can be downloaded from: http://www.turbolog.de/ The program installs ok, but fails to run correctly. It asks for a License key, one should be able to press cancel and bypass it into demo mode where a window is displayed for entering log records. Can anyone help be diagnose why it fails. James Things like this tend to get lost in wine-devel. If you open a bug in Bugzilla (http://bugs.winehq.org/) about this, it's less likely to get forgotten. - Neil
Re: missing link??
On Monday, August 28, 2006 15:30, Andreas Mohr wrote: What's the exact status of 64bit support, anyone? [CC'd wd] It works well for me at least. I compile Wine on amd64 using the following (that's all one line): CFLAGS=-L/emul/linux/x86/usr/lib/ LDFLAGS=-L/emul/linux/x86/usr/lib/ ./configure --x-libraries=/emul/linux/x86/usr/lib/ make clean make depend make -j3 I'm using Gentoo, so YMMV with other distros. The regular Wine packages in Portage also work well if you just want the actual releases. - Neil
Re: Benchmarking Wine
On Tuesday, August 01, 2006 10:39, H. Verbeet wrote: It might be a good idea to fix that 3DMark03 performance regression caused by VBOs :-) Yes, http://bugs.winehq.org/show_bug.cgi?id=5546 for reference. As for tests #3 and #4 in 3DMark 03, they both run, although 3DMark 03 frequently crashes while loading test #3. Test #4 requires using GLSL instead of ARB shaders though. As for 3DMark 05 and 06, they don't seem to think we support Pixel Shader 2.0, even when using GLSL, so I'm not sure how valuable those would be to benchmark in that state. - Neil
Re: please help with patch submission
On Monday, July 31, 2006 06:37, Damjan Jovanovic wrote: + WCHAR guidStringWithBraces[MAX_GUID_STRING_LEN]; You need MAX_GUID_STRING_LEN + 1 to store the null too, if I'm not mistaken. +CopyMemory(guidStringWithBraces[1], lpGuidString, +(MAX_GUID_STRING_LEN - 3) * sizeof(WCHAR)); Why MAX_GUID_STRING_LEN - 3? Wouldn't that miss the last 3 characters? - Neil
Re: assumed graphic card memory
On Wednesday, July 12, 2006 16:26, Molle Bestefich wrote:
Christoph Frick wrote:
within the dlls/wined3d/device.c there is a define for
the fake size of the graphic-card memory.
Odd. Isn't it relatively easy to figure out?
Perhaps something like:
# ls -lS /sys/class/graphics/fb0/device/resource* | head -n1 | awk '{print
$5}' 134217728
or
# ls -lS /sys/devices/pci:00/:00:01.0/:01:00.0/resource*
| head -n1 | awk '{print $5}'
134217728
Does that work / is it correct for any card?
Is the AGP aperture size also needed?
This reports the wrong values for me in one machine with a 32M video card:
[EMAIL PROTECTED] ~ $ ls -lS /sys/class/graphics/fb0/device/resource*
-rw--- 1 root root 134217728 Jul 12
17:12 /sys/class/graphics/fb0/device/resource0
-rw--- 1 root root 65536 Jul 12
17:12 /sys/class/graphics/fb0/device/resource2
-r--r--r-- 1 root root 4096 Jul 12
07:57 /sys/class/graphics/fb0/device/resource
-rw--- 1 root root 256 Jul 12
17:12 /sys/class/graphics/fb0/device/resource1
...and doesn't work at all in another:
[EMAIL PROTECTED] ~ $ ls -lS /sys/class/graphics/fb0/device/resource*
ls: /sys/class/graphics/fb0/device/resource*: No such file or directory
- Neil
Re: Ole-BSTR-Concat broken?
On Saturday, June 24, 2006 05:47, Olaf Schmidt wrote: Hi *.*, seems, that the Ole-BSTR-Concat doesn't work anymore: (Debian Sid, from wine 0.9.12 upwards - wine configured, to use the builtin Ole-Stuff) In VB-Applications (wich are using (wide) Ole-BSTRs under the hood), I can reduce the problem to the following: If I define two Strings with the Content: S1, containing a Zero WChar (BSTR-LenDescriptor=2, ByteSequence 0 0) and S2, containing A|Zero|B (BSTR-LenDescriptor=6, ByteSequence 65 0 | 0 0 | 66 0) and then do the concat: SResult = S1 + S2 the resulting string contains only an A (BSTR-LenDescriptor=2, ByteSequence 65 0) instead of the correct ByteSequence: 0 0 | 65 0 | 0 0 | 66 0 That means, that the current implementation does not use the BSTR-Len-Descriptor anymore (it has worked in 0.9.10 or 0.9.11 - not very sure, but think it was 0.9.11 in my last tests) Instead it now behaves like routines, wich have to concat Zero-Terminated Strings. Nothing changed in my wine-configuration - only apt-getted to 0.9.12 first - then to the latest 0.9.16 (ubuntu-deb) - same problem. Do you handle the OLE-BSTR-stuff directly in wine, or do you give that jobs to other Libs in the system (the 0.9.12er winelib- update has also changed some dependencies (Gtk, libc* and others)? Olaf Schmidt If you could do a regression test and find the specific patch that broke things, that would be very helpful. See section 6.1 of http://wiki.winehq.org/GitWine for regression testing. - Neil
Re: Linux noob
On Tuesday, June 06, 2006 13:42, Molle Bestefich wrote: I'm annoyed that .wine is inaccessible through KDE and Gnome apps. You can always type .wine in to access it, even if it isn't visible. - Neil
Re: msi: Fix some copy/paste bugs in the implementation of condition operators.
On Monday, June 05, 2006 12:58, EA Durbin wrote:
Okay what am i misunderstanding?, explain it to me as its imperative I
learn, and I'd love to learn.
%u is an unsigned integer which is 0 to +32,767.
%i is a signed integer 32,767 to +32,767.
If the sequence number is always going to be a positive number why should
we allot it the extra 32,767 value range?
Not quite...
[EMAIL PROTECTED] ~ $ cat tmp.c EOF
#include stdint.h
#include stdio.h
int main(void)
{
uint16_t i = -1;
printf(%u\n, i);
return 0;
}
EOF
[EMAIL PROTECTED] ~ $ gcc tmp.c
[EMAIL PROTECTED] ~ $ ./a.out
65535
[EMAIL PROTECTED] ~ $
if you inspect the memory that's at i, you'll find it's 0x. If you read it
as signed, you interpret it using two's complement[1], if you read it as
unsigned, you still use all the bits, but there's no sign bit*.
[1] http://en.wikipedia.org/wiki/Two's_complement
* Strictly speaking it's not a sign bit, but is frequently referred to as one
anyways.
- Neil
Re: How are we doing?
On Friday, June 02, 2006 07:25, Mike McCormack wrote:
lack of comments in the code
+1, I think it's horrifying.
void the_function_that_adds_one_to_i(int i)
{
/* this adds one to i */
i = i + 1;
/* this returns i to the caller */
return i;
}
Horrifying, yes :)
Mike
Particularly horrifying is the return i in a void function! Is there a test
for what native does in this case?
- Neil
Re: Wine 1.0 Tasks
On Tuesday, May 30, 2006 09:56, Dan Kegel wrote: I'm not sure lotus notes problems should block 1.0, as IBM has a native Linux client now, but if someone wants to fix them (especially the ones in usp10.dll netapi32.dll, that would be great. They do? I would be very interested to see that... There are Linux packages of Lotus Notes, but every one I've seen uses Wine. - Neil
Re: Wine 1.0 Tasks
On Tuesday, May 30, 2006 23:51, Dan Kegel wrote: On 5/30/06, Neil Skrypuch [EMAIL PROTECTED] wrote: On Tuesday, May 30, 2006 09:56, Dan Kegel wrote: I'm not sure lotus notes problems should block 1.0, as IBM has a native Linux client now, but if someone wants to fix them (especially the ones in usp10.dll netapi32.dll, that would be great. They do? I would be very interested to see that... There are Linux packages of Lotus Notes, but every one I've seen uses Wine. It's Java-based, on the Eclipse platform, if you can believe it. I don't know when it'll be released. - Dan I've heard murmuring to that effect before (specifically, the Rich Client Platform portion of Eclipse), although I've yet to see anything concrete. Not that I don't expect it to happen (Notes already has some Java components, at least to the point where it bundles it's own jre/jdk and has a Java logo/symbol on the splash screen), but my impression of Notes is that it's a pretty big beast, and I don't think a complete port to anything would go without a fight. Having said that, it's hard to know how long Notes for Linux has been in development, and Notes certainly has been used on other platforms before. Either way, native Notes for Linux isn't here yet, but neither is Wine 1.0. - Neil
Re: Problems compiling older wine-versions
On Monday, May 22, 2006 04:27, Louis. Lenders wrote: Hi, i just upgraded to fedora core 5 (from fedora 3) In my old system i had about 20 wine-versions (back to april 2004) installed which was great for tracking down regressions. Trying to compile older wineversions now on my new installation fails with various errors (like wine-20050419 fails with error: union anonymous has no member named a_ptr) Even wine-0.9 (first beta release) won't compile anymore. I guess that's due to newer gcc/glibc versions. Is there a (easy) way to get older wine-versions compiling again? Send instant messages to your online friends http://uk.messenger.yahoo.com There was an issue with flex a few months ago, where Wine wouldn't compile with the newer version of flex. Wine was modified so that it would compile again, but older versions wouldn't compile anymore with the newer version of flex. Try using flex-2.5.4a to compile the older versions of Wine. (At least I'm pretty sure it was flex, it might have been bison though, try bison-1.875d if you have no luck with older flex.) - Neil
Re: Error compiling wine on dapper amd64
On Monday, May 08, 2006 00:20, Vitaliy Margolen wrote:
Saturday, May 6, 2006, 12:48:50 PM, Marco Eminente wrote:
CFLAGS=-Wall -g -O2 ./configure --host=x86_64-linux-gnu
--build=x86_64-linux-g nu --prefix=/usr --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking whether make sets $(MAKE)... yes
checking for x86_64-linux-gnu-gcc... gcc -m32
checking for C compiler default output file name... configure: error: C
compiler cannot create executables
See `config.log' for more details.
make: *** [config.status] Error 77
Comando di costruzione 'cd wine-0.9.12~winehq1 dpkg-buildpackage -b
-uc' fallito.
E: Processo figlio fallito
Hope this can help
Wine does not compiles as 64-bit ATM. See for more information
http://wiki.winehq.org/WineOn64bit
Vitaliy.
He was trying to build it as a 32-bit application (see gcc -m32), but he's
missing all of the 32-bit libs to do so.
Marco: You need to install the 32-bit compatibility libs to build Wine, as
suggested by the link above.
- Neil
Re: Dogfood report: Firefox autoupdate works
On Wednesday, May 03, 2006 12:23, Dimi Paun wrote: Firefox is solid for my uses lately. Performance could use some work (reading the wine-devel archive index gets annoying towards the end of the month when it's long, as firefox takes a long time to fetch it (?)). Hm, AFAIK 1.5 should cache rendered pages when you go back. In fact, it is the first version of any brower on Linux that I can confortably use to read LKML archives, all others would take way too long to render it every time I went back to the index. (Sadly, IE was always much faster at this particular task). Including Konqueror? On my machine at least, the initial render in Konqueror is quite a bit faster than Firefox 1.5. Cached pages are both pretty much instantaneous. - Neil
Re: sfd2ttf
On Friday, April 28, 2006 18:31, Travis Watkins wrote: On 4/28/06, Dimi Paun [EMAIL PROTECTED] wrote: As I said, virtually any Java project in existance checks in .jar files, and none of them suffer from any negative ill effect. jar == zip, not such a big deal -- Travis Watkins http://www.realistanew.com A zip of class (binary) files. - Neil
Re: What's in mmbranch
On Saturday, April 29, 2006 09:11, Molle Bestefich wrote: Molle Bestefich wrote: Eep. Cogito on Gentoo is broken: [snip] If it's not too much work for you, could you set up git:// access to your branch? Oops, never mind that. Enabling curl and webdav USE flags on Gentoo makes git-http-fetch work. (Also causes my HTTP server to compile with WebDAV support and various other side effects, but hey, welcome to Gentoo and the world of multi-app use flags...) Do echo dev-util/cogito curl webdav /etc/portage/package.use to only enable those use flags for cogito. - Neil
Re: Wine missing from repositories?
On Sunday, April 16, 2006 01:54, Dee Ayy wrote:
1) I installed wine at work from kubunu breezy repositories (standard and
maybe universe and multiverse repositories are added) on wednesday
4/12/2006, yet on thursday 4/13/2006 I installed ubuntu breezy at home and
definitely had standard, universe, multiverse, and even the *deb
http://wine.sourceforge.net/apt/ binary/* repository added, yet could not
see wine available for installation. Is Wine missing from repositories?
2) I thought I might be able to build wine from source for my AMD64 using
the info on this page http://www.winehq.com/site/download-deb , but I seem
to be getting a ubuntu compiler problem. But I am posting the error in
case it is a winehq problem and this helps you (and attaching config.log):
[EMAIL PROTECTED]:/home/user1/apt_sources# apt-get --build source wine
Reading package lists... Done
Building dependency tree... Done
Need to get 13.6MB of source archives.
Get:1 http://wine.sourceforge.net source/ wine 0.9.11~winehq1-1 (dsc)
[1209B]
Get:2 http://wine.sourceforge.net source/ wine 0.9.11~winehq1-1 (tar) [
13.5MB]
Get:3 http://wine.sourceforge.net source/ wine 0.9.11~winehq1-1 (diff) [
47.1kB]
Fetched 3B in 0s (4B/s)
Skipping unpack of already unpacked source in wine-0.9.11~winehq1
dpkg-buildpackage: source package is wine
dpkg-buildpackage: source version is 0.9.11~winehq1-1
dpkg-buildpackage: source changed by Scott Ritchie [EMAIL PROTECTED]
dpkg-buildpackage: host architecture amd64
debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp
# Add here commands to clean up after the build process.
/usr/bin/make distclean
make[1]: Entering directory `/home/user1/apt_sources/wine-0.9.11~winehq1'
make[1]: *** No rule to make target `distclean'. Stop.
make[1]: Leaving directory `/home/user1/apt_sources/wine-0.9.11~winehq1'
make: [clean] Error 2 (ignored)
#-/usr/bin/make -C documentation clean
dh_clean
debian/rules build
dh_testdir
# Add here commands to configure the package.
CFLAGS=-Wall -g -O2 ./configure --host=x86_64-linux-gnu
--build=x86_64-linux-gnu --prefix=/usr --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking whether make sets $(MAKE)... yes
checking for x86_64-linux-gnu-gcc... gcc -m32
checking for C compiler default output file name... configure: error: C
compiler cannot create executables
See `config.log' for more details.
make: *** [config.status] Error 77
Build command 'cd wine-0.9.11~winehq1 dpkg-buildpackage -b -uc' failed.
E: Child process failed
Please advise.
**
Wine builds as a 32-bit app by default. Judging by your config.log, you don't
have any 32-bit emulation libraries installed, and a variety of these are
needed to build Wine. If you build Wine as a 64-bit app, you'll only be able
to run 64-bit Windows applications.
I don't use the apt packages, so I won't comment on them beyond noting that
there does appear to be packages here:
http://wine.sourceforge.net/apt/breezy/
- Neil
Re: Starcraft vs. fullscreen
On Friday, April 14, 2006 05:34, you wrote: Neil Skrypuch wrote: Molle Bestefich wrote: I can switch to 640x480 just fine using [CTRL] [ALT] [-], That uses xvidmode to switch resolutions (and really just changes the amount you can view, the desktop size stays the same, try moving the mouse to the edges of the screen). xrandr is a different way of switching resolutions, which actually changes the resolution on the fly, try using 'krandrtray' or 'xrandr' to use xrandr instead. Thanks!! That's the missing piece of information. krandrtray doesn't work either, so my X.org configuration is apparently borked. See refresh rates in attached screenshot ;-). Sorry for the noise on wine-devel. You should see the following in your Xorg.0.log file, if xrandr is enabled: (==) RandR enabled (II) Initializing built-in extension RANDR Yep, got those exact lines (no ensuing warnings/errors). You can tell Wine to use xvidmode instead of xrandr. Add UseXVidMode as Y and UseXRandR as N in \HKEY_CURRENT_USER\Software\Wine\X11 Driver. - Neil
Re: winebrowser: Use user's preferred browser
On Friday, April 14, 2006 09:31, Jeremy White wrote: +kfmclient exec,gnome-open,kmail,mozilla-thunderbird,thunderbird,evolution; A Gnome user will be offended if you spool up the entire KDE environment just to launch a URL; a KDE user will be similarly offended by gnome-open. Further, if I'm a Gnome user, I may have KDE on my system, and kfmclient exec may work, but it's likely to not be the browser I *really* want used. The standard that's developing is that you don't invoke a KDE program unless KDE_FULL_DESKTOP is set and you don't invoke a Gnome session unless GNOME_DESKTOP_SESSION_ID is set. Cheers, Jeremy I had thought about this, though I wasn't aware of any good way of detecting KDE/Gnome running. A quick googling shows that it's actually KDE_FULL_SESSION though, not KDE_FULL_DESKTOP. I'll add in this feature and post an updated patch shortly. - Neil
Re: winebrowser: Use user's preferred browser
On Friday, April 14, 2006 11:07, Hans Leidekker wrote: On Friday 14 April 2006 15:31, Jeremy White wrote: +kfmclient exec,gnome-open,kmail,mozilla-thunderbird,thunderbird,evolution; Have you tested the clients you added? kmail doesn't understand mailto URLs passed on the command line last I looked. -Hans Yes, I tested all of the items I added, except for gnome-open, which I asked someone with Gnome to test for me. KMail understands mailto:[EMAIL PROTECTED] URLs for me at least (tested on KDE 3.5.2 and KDE 3.4.3). 'kmail mailto:[EMAIL PROTECTED]' brings up a new message addressed to [EMAIL PROTECTED], as expected. - Neil
Re: Starcraft vs. fullscreen
On Thursday, April 13, 2006 09:50, Molle Bestefich wrote: Jesse Allen wrote: Molle Bestefich wrote: Looks like xrandr [support] is broken. It says Changing Resolution to 640x480, so that sounds great - only it doesn't. I'd maybe look through xorg.conf or you X.org log and see what is going on with those refresh frequencies. Dumb question time. I can switch to 640x480 just fine using [CTRL] [ALT] [-], does that mean that my xrandr is working? At least it means that my xorg.conf is fine, right. Nothing is written to Xorg.0.log when switching resolution manually or starting the game. Hmm. That uses xvidmode to switch resolutions (and really just changes the amount you can view, the desktop size stays the same, try moving the mouse to the edges of the screen). xrandr is a different way of switching resolutions, which actually changes the resolution on the fly, try using 'krandrtray' or 'xrandr' to use xrandr instead. You should see the following in your Xorg.0.log file, if xrandr is enabled: (==) RandR enabled (II) Initializing built-in extension RANDR - Neil
