Rémi?  (as you packaged wine)
Thierry? (as you updated wine-mono last)

I think wine and wine-mono must to be updated together and pushed to updates simultaneously?

CC: (none) => rverschelde, thierry.vignaud
Whiteboard: (none) => mutual(?) version dependency

Regarding version, maybe wine-mono should get updated regardless;
Our version 4.7.5 is a year old, and current is 4.9.4 from november.

CC Anssi and David G from last time maybe this same happened, Bug 16273

CC: (none) => anssi.hannula, geiger.david68210
Whiteboard: mutual(?) version dependency => mutual(?) build/version dependency
Summary: wine-mono must be rebuilt because we have a new wine version => wine-mono must be rebuilt because we have a new wine version (+ update would be good)

Thank you Morgan for your detective work; and Rémi for the quick work on Wine in that other bug.
Assigning to you [R] as just having done wine-4.0.3-1 for bug 26093.

From https://bugs.mageia.org/show_bug.cgi?id=26093#c6
> AFAIK wine-mono needs to be *updated*
> to include the version required by wine
> maybe wine-mono should get updated regardless  [from comment 2]
And what about wine-gecko?
And is it possible to update these in advance of Wine itself? Just a thought.

Summary: wine-mono must be rebuilt because we have a new wine version (+ update would be good) => wine-mono must be updated because we have a new wine version (+ update would be good)
CC: rverschelde => (none)
Assignee: bugsquad => rverschelde

Good question, Lewis.
I found a list of wine version ranges and gecko version:
https://wiki.winehq.org/Gecko

Oddly our wine version 4.x is not listed, but recent 3 needed gecko 2.47, and upcoming 5.0 (for Mageia 8?) need 2.47.1.

So i would guess our wine 4.0.x is fine with our current gecko in mga7.

Re concurrency, i think that we best aim to put both in testing to test together, and push updates at the same time.  And best to have latest wine-mono 4.9.4.

@Morgan: No, wine-mono should not be updated. Each wine version has a strict dependency on a specific wine-mono version, and for wine 4.0.3, it's wine-mono 4.7.5:
http://svnweb.mageia.org/packages/updates/7/wine/current/SPECS/wine.spec?view=markup#l31

The wine %build section actually checks that, it wouldn't build against another version.

wine-mono 4.9.4 is used by wine 5.0 rc currently.

I am not familiar with this, so i take your word for it.

I fail to find any version matching info upstream.

How do we decide suitable wine-mono version?

As i read that line you link we should set it to the wine-mono version we provide.  I and if we update wine-mono, we should change the version number in line 35 and rebuild wine.

Summary: wine-mono must be updated because we have a new wine version (+ update would be good) => wine-mono must be rebuilt(?) because we have a new wine version

See line 33:

33 	# Dependencies hardcoded in dlls/appwiz.cpl/addons.c

The required versions are written in wine's source code, and those are the ones we have to package for wine-mono and wine-gecko.

Ah thank you.
Sorry i somehow did not interprete that line.

I'm only seeing the old version of wine-mono. Will it be updated? Or should I test wine with the current wine-mono version?

$ urpmq -f wine-mono
wine-mono-4.7.5-1.mga7.noarch|wine-mono-4.7.5-1.mga7.noarch

CC: (none) => mageia

As Rémi told, we must keep to version 4.7.5.

See if that works for you.

If it does not work, maybe a rebuild is needed / or there is another problem.

To be fair, I've always had warnings that wine can't find wine-mono, and I don't think the update in bug 26093 changes anything to that issue. I don't know how to reproduce it reliably but it comes us quite frequently when initializing a new wine prefix.

I'll throw in a blank rebuild of wine-mono to match the update candidate, but I'm not sure it will make a difference. If it doesn't, I think it should not block the update as it's a pre-existing bug.

Looking at Fedora's wine-mono, they don't seem to ever need to rebuild it against an updated wine: https://src.fedoraproject.org/rpms/wine-mono/commits/master

While they do update wine *a lot* in the meantime. So I think this is an invalid bug, the real issue is that even though we have wine and wine-mono in matching versions, wine still can't find wine-mono.

This is likely the same issue as bug 12253 which was closed as WORKSFORME because it's elusive and not so easy to trigger reliably. But I do see this warning every now and then (which doesn't prevent running applications).

If you can confirm my assumption from https://bugs.mageia.org/show_bug.cgi?id=26093#c8 (that you were testing Lutris' own Wine version and not Mageia's), then this can be closed.

You seem to be correct.
Lutris seem to always use internal wine.

If i uninstall all wine, and in lutris try to install something it pops up a dialogue suggesting to install my distros wine in order to have all dependencies supplied.
There clicking Continue, it continues anyway, and later in the process tell it cannot find wine-mono, offer to install it, and i click to let it install it, and it continues. After a while same procedure with wine-gecko.

It makes sense it is not satisfied with our wine-mono, as i suppose it internally have a later wine version, not compatible with our wine-mono.

I dont have a windows program i know needs .net/mono, - optimally that should be tested, but have to leave that test due to lack of time.

Resolution: (none) => INVALID
Status: NEW => RESOLVED