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

[Jens Reyer]

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.

Use something like this to remove this specific set of unwanted files
and update your desktop database:

  rm
~/.local/share/applications/wine-extension-{chm,gif,hlp,htm,html,ini,jfif,jpe,jpeg,jpg,msp,pdf,png,rtf,txt,url,vbs,wri,xml}.desktop

  update-desktop-database ~/.local/share/applications/

Then report any new issue causing file (this is the info that I need to
work on this bug).

If these specific files reappear please report a separate bug!


Now, I assume without these files for the common extensions the issue
won't be observed very often.  But as soon as someone installs an
application which adds its own association that should cause this issue.
 Therefore keeping the moreinfo tag and not closing the bug for now.


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 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".

Please someone tell me what I miss here.

Greets
jre


[1]: libs/wine/config.c:
[...]
    /* build config_dir */

    if (prefix)
    {
        config_dir = xstrdup( prefix );
        remove_trailing_slashes( config_dir );
        if (config_dir[0] != '/')
            fatal_error( "invalid directory %s in WINEPREFIX: not an
absolute path\n", prefix );
[...]