Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 338434

Summary: app-emulation/wine 1.3.x: file open / save dialog broken after reemerge
Product: Gentoo Linux Reporter: Quasimodo <quasi>
Component: Current packagesAssignee: Wine Maintainers <wine>
Status: RESOLVED FIXED    
Severity: normal CC: antonbaklanov
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: emerge --info on amd64
emerge --info on x86
emerge --info

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) gentoo-dev 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 gentoo-dev 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 gentoo-dev 2010-09-25 05:34:35 UTC
ive dropped the fortify patch then.  back to the drawing board in bug 336887.