Bug 338434 – app-emulation/wine 1.3.x: file open / save dialog broken after reemerge

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Quasimodo 2010-09-23 11:29:46 UTC]

Updating my wine from 1.3.2 to 1.3.3 results in a broken file open dialog, where all the folder names on the real filesystem are followed by an unprintible char (displayed as a box). All foldernames on virtual drives like on c: or z: are still correct, but don't work anymore. Trying to load a file will end in an error message about an "Invalid Path" and after that the file dialog is directed to the real drive with the garbled folder names.

Reverting back to wine-1.3.2 doesn't correct the problem. Also this happens on 2 different computers - one x86 and one amd64. The last time I've updated wine was around September 12th.

Reproducible: Always

[Comment 1 Markos Chandras (RETIRED) 2010-09-24 11:16:24 UTC]

emerge --info please

[Comment 2 Quasimodo 2010-09-24 11:27:12 UTC]

Created attachment 248505 [details]
emerge --info on amd64

As you wished, here is my emerge --info from my amd64 machine

[Comment 3 Quasimodo 2010-09-24 11:32:08 UTC]

Created attachment 248506 [details]
emerge --info on x86

And from my x86 machine

[Comment 4 Vadim Dyadkin 2010-09-24 11:34:40 UTC]

I have exactly the same problem

[Comment 5 Anton Baklanov 2010-09-24 14:33:35 UTC]

have the same problem

[Comment 6 Anton Baklanov 2010-09-24 15:57:41 UTC]

Created attachment 248529 [details]
emerge --info

i've reverted wine to 1.1.44 and deleted my ~/.wine and it does not fix the problem.

[Comment 7 Marcos Vicente Cruz 2010-09-24 16:02:56 UTC]

I'm having the same problem here.

[Comment 8 SpanKY 2010-09-24 20:22:45 UTC]

if you remove the wine-1.3-shell32-fortify.patch, does it make a difference ?

[Comment 9 Anton Baklanov 2010-09-24 21:46:01 UTC]

(In reply to comment #8)
> if you remove the wine-1.3-shell32-fortify.patch, does it make a difference ?

will try it tomorrow, thanks

[Comment 10 savalas 2010-09-25 01:29:14 UTC]

Removing that patch from the ebuild fixes it for me.

Now I have some very conflicting feelings about this. On the one hand I am glad this bug is resolved, on the other hand I am very disappointed that I have spent hours splitting hairs inspecting my emerge logs, recompiling my toolchain and recompiling wine numerous times with different settings and generally be confused to no end because __every Wine ebuild has been modified yet their version remained the same__. This is a terrible practice. I haven't checked Gentoo's guidelines regarding ebuilds but I thought that in ebuilds, the number after "-r" meant "revision" and I expected that everytime an ebuild is modified that number would be increased.

So yeah, no wonder that downgrading to Wine 1.3.2 would not fix it, the last working wine-1.3.2.ebuild doesn't exist anymore, it's been replaced with a broken wine-1.3.2.ebuild.

Please don't ever alter an ebuild again without changing its number. Thanks.

[Comment 11 Richard Grenville 2010-09-25 04:16:48 UTC]

I was experienced the same problem on a ~amd64 Gentoo. Removing wine-1.3-shell32-fortify.patch fixes the problem.

[Comment 12 SpanKY 2010-09-25 05:34:35 UTC]

ive dropped the fortify patch then.  back to the drawing board in bug 336887.