You are not logged in.
Pages: 1
The 64-bit version of wine installs and works fine, but when attempting to install wine32, wine:i386, or wine32:i386 I get the following:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
e2fsprogs : PreDepends: libblkid1 (>= 2.36) but it is not installable
Recommends: e2fsprogs-l10n but it is not going to be installed
init : PreDepends: sysvinit-core but it is not going to be installed or
runit-init but it is not going to be installed
libglib2.0-0 : Depends: libmount1 (>= 2.35.2-7~) but it is not installable
Recommends: shared-mime-info
util-linux : PreDepends: libblkid1 (>= 2.37.2) but it is not installable
PreDepends: libmount1 (>= 2.38) but it is not installable
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.I have the i386 architecture enabled in dpkg. I found a similar thread but the output was completely different. Even using the WineHQ repository I get the same error trying to install those packages.
Offline
This has been written about a number of times. Do not attempt to mix the architectures for WINE. Cannot work (been there, done that).
Offline
Most applications people would want/need in WINE are 32-bit.
Offline
Most applications people would want/need in WINE are 32-bit.
Agree. Which is why WINE is (IMO) deprecated for modern Linux, which almost entirely is powered by 64-bit cpus.
Offline
You're running Ceres - the unstable development version.
One should not be using unstable developer tools if they are not willing+able to debug simple package dependency issues.
Since the two problem packages do currently exist in ceres repository, it's possible the error message is correct - that this was a local issue caused by held packages - but it's also possible it was a temporary issue caused by the fact that Ceres is an unstable development version.
Last edited by boughtonp (2023-07-27 13:51:34)
3.1415P265E589T932E846R64338
Offline
You're running Ceres - the unstable development version.
One should not be using unstable developer tools if they are not willing+able to debug simple package dependency issues.
I migrated from Bookworm which is newer than Chimaera so I would only have the option of Daedulus or Ceres. Testing doesn't get security updates in a timely manner and it doesn't seem Daedulus will become stable soon (despite Bookworm already being here) so I went with Ceres.
Since the two problem packages do currently exist in ceres repository, it's possible the error message is correct - that this was a local issue caused by held packages - but it's also possible it was a temporary issue caused by the fact that Ceres is an unstable development version.
I already unheld the one held package and tried it again, it runs into the same issue.
Offline
Bookworm is now on version 12.1 which is usually taken as a sign that initial bugs have been sorted and sysadmins. can safely upgrade.
So I would expect Daedalus, which exactly the same packages as Bookworm in most cases should equally be ready, apart from the installation isos which are still being tested.
Most security updates appear on Daedalus as soon as they appear on Bookworm since Devuan merges Bookworm packages with the very limited number of 'devuan modified' packages. For example the Zenbleed AMD firmware patch appeared very quickly.
For myself, having upgraded my desk PC from Chimaera to Daedalus a few weeks ago without issue I've now upgraded my two others machines, one a mail server and all seems good.
Offline
I migrated from Bookworm which is newer than Chimaera so I would only have the option of Daedulus or Ceres. Testing doesn't get security updates in a timely manner and it doesn't seem Daedulus will become stable soon (despite Bookworm already being here) so I went with Ceres.
Neither Testing nor Unstable get security updates in a timely manner, but using Unstable is worse than using Testing:
10.1.3. Avoid using the unstable branch
Unless you want to dedicate time to patch packages yourself when a vulnerability arises, you should not use Debian's unstable branch for production-level systems. The main reason for this is that there are no security updates for unstable.
The fact is that some security issues might appear in unstable and not in the stable distribution. This is due to new functionality constantly being added to the applications provided there, as well as new applications being included which might not yet have been thoroughly tested.
At least with Testing, packages have probably had 2-10 days of testing - with Unstable they haven't even had that.
If security matters, your options are:
* use Devuan Stable (Chimaera).
* put up with Debian Stable (Bookworm) until Daedalus is ready.
* learn the necessary skills to manually patch vulnerabilities yourself along with regularly monitoring the status of all software you have installed so that you can apply patches in a timely manner.
That last one involves a lot of time and effort, and is not recommended.
-
I already unheld the one held package and tried it again, it runs into the same issue.
If the issue is the same than the solution is the same.
Apt is stating that the dependency requirements cannot be met and identifies the two packages which cannot be installed.
There are two possibilities: it's on the remote repositories side of things or it's down to changes on your machine.
If it's the former, you can only wait for those responsible to resolve it.
If it's the latter, you need to identify what you have changed to cause the situation.
3.1415P265E589T932E846R64338
Offline
Neither Testing nor Unstable get security updates in a timely manner, but using Unstable is worse than using Testing:
So are you saying the Debian wiki is wrong, because it says right here:
It is a good idea to install security updates from unstable since they take extra time to reach testing and the security team only releases updates to unstable.
Offline
did you use "forky" from winehq?
https://gitlab.winehq.org/wine/wine/-/w … ian-Ubuntu
it says "Enable the 32-bit repository" -- but donùt know if it installs actually wine 32-bit or 64-bit.
it used to function, you just have to see which repository is ok for you, eg. stable, develop, staging.
if forky not function, you could try with trixie sources.
EDIT: sorryz , it seemt to be answered on einehq already
Ubuntu 25.10 and later/ Debian Testing
The WineHQ packages are WoW64. This means that the 32-bit packages are unnecessary. The new WoW64 wine-devel package is set to conflict with and replace wine-devel-i386 and wine-devel-amd64, which are no longer separate packages. Upgrading users should get a message about the replacement and asked if they want to continue. If updating an older Wine version does not work, uninstall the old packages first.
sudo apt remove winehq-devel wine-devel wine-devel-amd64 wine-devel-i386:i386
Last edited by kapqa (Today 07:52:04)
Offline
Pages: 1