[pkg-wine-party] Bug#858242: libwine: winemenubuilder creates .desktop files with invalid WINEPREFIX

Sven Joachim svenjoac at gmx.de
Sun Oct 29 19:43:13 UTC 2017


On 2017-10-29 19:24 +0100, Jens Reyer wrote:

> On 10/11/2017 08:08 PM, Sven Joachim wrote:
>> On 2017-10-08 14:58 +0200, Jens Reyer wrote:
>> 
>>> control: tags -1 + moreinfo unreproducible
>>> 
>>> On 03/20/2017 05:22 PM, Jens Reyer wrote:
>>>> On 03/20/2017 11:20 AM, Sven Joachim wrote:
>>>>> wine: invalid directory "/home/sven/.wine" in WINEPREFIX: not
>>>>> an absolute path
>>>>> 
>>>>> Apparently the program was trying to run winebrowser from one
>>>>> of my .desktop files under ~/.local/share/applications/, those
>>>>> look like this:
>>>> 
>>>> This was already mentioned in #845334 (wine32: breaks xdg-open,
>>>> which wants to start wine and crashes).  As a result of that
>>>> report the .desktop files aren't generated anymore for some
>>>> standard mimetypes, e.g. pdf.  So the mentioned file should be a
>>>> relic from older times (please verify its timestamp).
>>>> Unfortunately we can't simply remove these existing files,
>>>> because we can't know if they are still wanted by the user.
>>>> 
>>>> I never saw this behavior here, but since it's now observed again
>>>> I'd really like to fix it (assuming it might also be triggered by
>>>> the .desktop files created by some Windows applications).
>>> Tagging unreproducible because I can't reproduce it, although it 
>>> happened both here and in #845334.
>>> 
>>> Tagging moreinfo because I wonder if this was some issue with
>>> previous versions.  Please check the timestamp of any issue-causing
>>> .desktop file and report the wine version and its origin installed
>>> at that time.
>> 
>> I just had a look at the .desktop files, and the most recent ones
>> are from July 23, 2017, just after I upgraded wine to 2.0.2-1.  And
>> they still have WINEPREFIX="/home/sven/.wine" in them, causing the
>> same complaints as mentioned in my original report.
>
> Sorry for my permanent delays.
>
> Files for common extensions like
> ~/.local/share/applications/wine-extension-pdf.desktop don't get created
> automatically anymore since wine-development/2.0_rc4-1 and wine/1.8.6-2.
>  So if your answer was for one of these files, then I assume they simply
> got touched during a Wine upgrade.  So looking for the timestamp is of
> no use here.

IIRC those were not touched at all, but I am not totally sure since I
have deleted them in the meantime.  Also, the 2.0.3 upgrade apparently
left all files in ~/.local/share/applications alone.

> However I'm still absolutely clueless and ask for help to solve this
> issue at its root:
>
> I see the check for the wineprefix starting with a "/" (slash, no
> quotation marks) in libs/wine/config.c[1], which is indeed the only
> place in the code which has the mentioned warning.  But I assume (I'm
> not a C coder) that the quotation marks are not relevant here.

I am not the greatest C programmer, but they seem very relevant, since
in the generated .desktop files the first character is a quotation mark
rather than a slash.

> I still triple-checked debian/patches/debsuffix/winemenubuilder.patch,
> but I don't find any issue with it.  The quotation marks after
> WINEPREFIX= are added by upstream, not our patch.  What we do here
> instead is replacing the name of the Wine binary loader in the PATH
> "wine" with "wine-stable" or "wine-development".

I stand corrected on that.  Indeed the quotation marks have been
introduced upstream in commit 94462664c5ca[1] ("File associations should
set wineprefix.").  What really surprises me is that this has not upset
more users, so far I have only come across a question on stackexchange[2].

Thanks for your help and for maintaining wine!

Cheers,
       Sven


1. https://source.winehq.org/git/wine.git/?a=commit;h=94462664c5cac1b8e72bf8d2258731d796d9dc9d
2. https://unix.stackexchange.com/questions/231092/firefox-tries-to-open-tex-files-with-wined-notepad



More information about the pkg-wine-party mailing list