Wine installer broken in non ahs version (Solved) [Solved]

[JayM]

I'll have to do that tomorrow. I had to reset my BIOS earlier and forgot to re-enable virtualization so I can't start 64-bit VMs and I can't reboot right now due to a process that's currently running.

[tony37]

an attempted solution for problems as in post 14:

Code: Select all

sudo apt install $(echo $(aptitude search '?source-package(^ffmpeg$) ?installed' -F %p | sed -n s/$/=$(apt-cache policy ffmpeg | grep -m1 ' 500' | awk '{print $(NF-1)}')/gp && aptitude search '?source-package(^libva$) ?installed' -F %p | sed -n s/$/=$(apt-cache policy libva2 | grep -m1 '500' | awk '{print $(NF-1)}')/gp))

This should downgrade the ffmpeg and libva packages to the current stable version. Command can take 10-15 seconds to show results.

Now it is possible that apt will propose to remove a lot of packages that may depend on the newer versions of ffmpeg and libva. In that case I propose to use the versions from the mx test repo (instead of trying to downgrade), but since I suppose that people don't want the test version of wine (otherwise you just install wine from the test repo in MXPI), we'll have to write a preferences file:

Code: Select all

echo -e "Package: $(echo $(aptitude search '?source-package(^libva$)' '?source-package(^ffmpeg$)' -F %p))\nPin: release a=mx,c=test\nPin-Priority:500" | sudo tee /etc/apt/preferences.d/pin_ffmpeg_libva

You'll also have to enable the test repo for this and now you should be able to install Wine with MX Package Installer, or with:

Code: Select all

sudo apt update && sudo apt install winehq-staging

[SwampRabbit]

@tony37 I think you guys are on to something. There is/was a known nuance, which would manifest under certain circumstances where if the ffmpeg libraries were installed (or pulled by another package) from the MX Test repo, and then a user manually tried to install ffmpeg from the AHS repo, this it would create broken packages that would need flipped.

When Stevo and I talked about it before the last AHS release cycle, we decided to stop chasing after it in part because it was hard to reproduce at the time and because the versions of the related -dev packages might have been needed by users. So we decide to stop more changes rather than cause more breakage.

Not sure if it’s related or make sense, it’s early lol.

If you guys determine the issue, where ever it is, we’ll fix it. Appreciate the extra effort by you two.

[tony37]

I think it's just a general problem that once you install a package from a certain repo, other packages from the same source-package should come from the same repo as well. But for newbies this is almost impossible to figure out, partly because the error messages from apt are not helpful.
Other recent examples: viewtopic.php?f=136&t=63769&p=628539#p628539 and viewtopic.php?f=127&t=63739&p=628211#p628211

In an ideal world, apt would at least propose to install from another repo if that would solve dependency problems.

[tony37]

The problem is not so difficult to reproduce: you start with a non-ahs iso (19.3 or 19.4 doesn't matter), then you go to MXPI > Test repo and upgrade (for example) libavcodec58. And then you try to install the default wine version.
Or more realistic example: install Kodi 19 from the test repo, and try installing Wine after that. Or: first install Blender from test repo... (or Streamlink, you get the point, anything that needs updated ffmpeg libraries, or that simply wants to install the ffmpeg package)

[SwampRabbit]

The problem is not so difficult to reproduce: you start with a non-ahs iso (19.3 or 19.4 doesn't matter), then you go to MXPI > Test repo and upgrade (for example) libavcodec58. And then you try to install the default wine version.
Or more realistic example: install Kodi 19 from the test repo, and try installing Wine after that. Or: first install Blender from test repo... (or Streamlink, you get the point, anything that needs updated ffmpeg libraries, or that simply wants to install the ffmpeg package)

I get what you are saying, but several weeks ago I was able to reproduce the same issue on AHS in our pre-release testing as well.

What you said and what I said are the same, but now some people are saying its just the Stable MX, but not also AHS.
ffmpeg and friends are/were a lower version in AHS than in MX Test, so it makes sense both Stable and AHS would have the same issue.

ffmpeg was a bit higher in AHS than Stable for a bit off and on, which is why I believe the issue would come and go infrequently.

[tony37]

If ahs has a lower version of ffmpeg than the test repo, then it can happen there as well. The main problem is just that once the ffmpeg packages come from test, then the 32-bit versions (needed for wine) need to come from there as well. So how to solve this? Maybe doing a preinstall check which version is installed, and installing some packages from the test repo if needed? Could become complicated

[JayM]

Code: Select all

$ apt-history libva2
2021-01-29 14:11:43 upgrade libva2:amd64 2.4.0-1 2.6.1-1mx19+1

ffmpeg isn't installed. Here's what's been installed on this virtual machine.

[tony37]

Code: Select all

$ apt-history libva2
2021-01-29 14:11:43 upgrade libva2:amd64 2.4.0-1 2.6.1-1mx19+1

Ok, and what else did you install/upgrade that time?

Code: Select all

apt-history 2021-01-29

[JayM]

Code: Select all

$ apt-history libva2
2021-01-29 14:11:43 upgrade libva2:amd64 2.4.0-1 2.6.1-1mx19+1

Ok, and what else did you install/upgrade that time?

Code: Select all

apt-history 2021-01-29

See attachment.