Application running under wine now unable to access the clipboard... time to downgrade wine?

Wine was updated on my system about 6 days before the last stable Manjaro release.

There is only one application I have installed under Wine, and that’s YNAB… my accounting software.

Previously, I would have no issues copy/pasting text dollar values to/from YNAB to my browser (i.e. when making a bill payment) or vice versa (copying the value of transactions from online into YNAB). What happens now is…

  • if I am in YNAB and copy the text value of a payment I’d like to make, when I go to Firefox I am not pasting that value. If I look inside my clipboard history, the value was never copied from YNAB
  • If I start in Firefox and copy the value of a transaction and try paste it into YNAB… the wine application basically hangs… caught in a loop trying to access a clipboard that apparently it no long can.

Since I don’t use YNAB every day, it’s hard for me to know for sure if my clipboard access issue started with the wine update or the stable update… but I thought I’d stick with focusing on wine first… and try to “downgrade” it.

I noticed in my /var/cache/pacman/pkg folder that I have the current and two versions back of wine


And according to man pacman I can use -U I can specify the “file path”…

       -U, --upgrade
           Upgrade or add package(s) to the system and install the required dependencies from sync repositories. Either a URL or file path can be specified. This is a “remove-then-add” process. See Upgrade
           Options below; also see Handling Config Files for an explanation on how pacman takes care of configuration files.

So can I downgrade wine by simply running pacman -U /var/cache/pacman/pkg/wine-6.21-1-x86_64.pkg.tar.zst? What concerns me is that wine has lots of dependencies, so I’m not sure if my command above will handle that on it’s own or if I’ll need to append more options.

But you should try creating a new prefix first, 6.23 uses wine-mono 7.0.

Thank you for the reply @wntr !

Hmm, so maybe another way to look at it is that I might not have all the dependencies in play I need?

I do recall wine prompting to install mono after the the update when I first launch the YNAB application (and it did whatever it needed to in the background)… but I also notice a wine-mono package in pamac that I do not have installed…

Plus Wine itself has a few “optional dependencies” that are not currently installed…

  • many lib32 variants of installed packages
  • opencl-icd-loader
  • dosbox

Might any these ideas be helpful before jumping to downgrade?

Truth is, I really don’t know much about wine and prefixes… Installing the YNAB package from AUR is what installed wine and set things up initially. If I do a search for “wine”" in my home folder I see 2 hits…
Are these folders potentially conflicting wine paths?

Hmm, I do recall hearing mention of people having to rebuild/reinstall AUR packages from time to time… although I can’t say I fully understood those topics when I read them. However, checking AUR (en) - ynab4 doesn’t indicate any recent updates related to mono 7 or the wine update… so even if I was to reinstall from AUR, I don’t think what I’d be any further ahead.

You can install wine-mono.

See Wine - ArchWiki on prefixes.

Probably symlinked; your existing data is under drive_c somewhere, it mirrors windows structure.

tl;dr in your case

env WINEPREFIX="/path/to/new/prefix" wineboot -u
cp /usr/share/ynab4/Setup.exe /path/to/new/prefix/drive_c/
env WINEPREFIX="/path/to/new/prefix" wine /path/to/new/prefix/drive_c/Setup.exe
# Start it the same way as with the setup above

If its still not working you can roll it back.

1 Like

Many thanks again @wntr for providing more information.

After looking at your commands and the wiki… I came to realize two things…

  1. that just running winecfg with no parameters (like I stumbled upon in the App Launcher) is not proper/complete
    …perhaps just running against the default prefix?
  2. that what I have are two prefixes… the default ~/.wine and one for YNAB at /.ynab/wine

So I started off by running winecfg properly for each prefix via the terminal…

  1. $ env WINEPREFIX="/home/<userid>/.wine" winecfg
  2. $ env WINEPREFIX="/home/<userid>/.ynab4/wine" winecfg

The only change I made in the YNAB config was removing a path it had created to my Ventoy USB drive (leaving it with the default C: and Z: mappings)… but more must have happened behind the scenes because now I can launch YNAB and copy/paste without issues!? This is great news!

Hmm, does this suggest that it’s always a good idea to run winecfg (for each prefix) after a wine update?

P.S. Should I still install wine-mono?

Yes, the default prefix is ~/.wine.

winecfg updates the prefix, but I had experience around early 6.x where you had to recreate it.
Depends on what changed, but if it works, thats good enough.

You could, if you have multiple prefixes it could save space.

1 Like

Not at all. Usually you define the working directory from the application and then Wine use the configuration there.
If you rightclick any *exe where no configuration exist, then wine use its own ‘drive_c’

But wine is some hard to configure. I use playonlinux to configure stuff, but its still difficult with wine.
I switched now to lutris, and things run better there with the lutris-fshack-xx runner without much tinkering around.

Thanks for the info @Joe_Ge

I generally stick to Steam/Proton myself where I haven’t had to worry about config’ing much other than sometimes selecting a different proton version or setting a load parameter via the Steam interface.

I actually have YNAB in Steam (where I originally purchased it), but I found I could not import my bank transaction files with it… The browser would not “see” it as an application to launch/interface with… and Steam’s YNAB crashed if I tried browsing the filesystem to import a file… so AUR’s YNAB saved my bacon :wink:

Maybe I’ll have to check if those issue got ironed out in newer proton versions… but I’m okay having one app loaded via wine directly.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.