This is not normal

[Snowhog]

Yes, I’ve seen this. Just haven’t been inclined to inquire about why; what mechanism; causes this.

[claydoh]

Typing '#Number' with some punctuation posts fine, but using # 3 (without the space, or any punctuation connected) seems to insert a url, lol...like this: number 2: Forum aaand number 3 Blogs .

The bbcode that results is this:

 number 2: [NODE="2"]Forum[/NODE]  aaand number 3 [NODE="3"]Blogs[/NODE]

[claydoh]

Anyone care to explain what exactly happened and what I can do to avoid this in the future?

Basically, every time there is a library or some component that a KDE program uses, that isn't specifically KDE related, needs an update, there is a potential conflict when Neon provides an update to that thing, if they do not build a related 32-bit package to match,
Sometimes a dependency or sub-dependency is also needed by something Wine/Steam related , for 32-bit support. Usually Wine, and more often the third-party WineHQ packages.
They usually catch this, but historically there have been similar dep breakages off and on since at least 2018.

Apparently fixing this is not as straightforward as just building a 32 bit package. Ubuntu doesn't build many 32-bit packages, and the build-dependency chain to do so iirc can go deeper than what Ubuntu provide packages for.
Also, Neon use 64-bit build servers, and not all the packages for 32-bit are able to be cross-compiled, they need dedicated 32-bit systems.

Then there is the voodoo and incantations needed to properly pin the correct packages without breaking stuff elsewhere.

tl;dr it is too complex for me to fully grasp.

They have discussed creating more involved build tests to catch these 32-bit conflicts, but no idea where that actually sits.

Now, to avoid this, you have a few choices.

1. Don't use neon
2. Don't install Wine or WinHQ
3. Use a non-system-installed wine implementation, such as Lutris, and its Runners, or Bottles, or even the flatpak for Wine. Steam should be OK, it doesn't use as much of the 32-bit stack at all, and those are well-known and simple.

I use option #2, with an occasional #3, I am a wannabe Linux Steam gamer, and haven't used a system-installed Wine in many years. Lutris covers most of what I need, and its flatpak has ALL the 32 bit deps built-in. Both Lutris and Bottles can download different wine implementations, such as those based on Steam's Proton that offer fairly easy switching between versions, making finding a good setup for a specific game or application a lot easier. I have not bothered to try the WIne flatpak. I rarely need to run a Windows application that isn't a game these days. Lutris and Bottles have covered things when I have.

[mr_raider]

Anyone care to explain what exactly happened and what I can do to avoid this in the future?

[benny_fletch]

Solution:

https://forum.kde.org/viewtopic.php?...12b7a4259e41bb

This worked for me as well!

[claydoh]

BTW, users of some other distros are experiencing the same failures to install wine32 and not all are because of libpoppler.

That was specifically from neon not building a 32-bit package related to this, which broke dependencies for wine. 32- and 64-bit packages have to be identical in Debian/Ubuntu systems. This is unrelated to any other system or distro.
That one was fixed already, some time back (months?)
The new one is from a dependency for Digikam, with a different package.
This too has been fixed, but does need a workaround once the new packages lists and updated apt configs have been installed.

MY point was that they said that 32-bit was not a priority, which does NOT mean that there will no support or attempts to remedy things.

But it is not always as simple to just "build a 32 bit package", it often means setting up builds for the entire 32 bit stack, or more likely pretty deeply down the dependency chain, as Ubuntu only provide a limited set of 32 bit packages to begin with, and iirc not the whole build chain.

It does not matter if people are treating neon as a proper distro or not. Their focus is, and always has been a rolling Plasma, things outside it have less priority.
32 bit/wine breakages are not new at all, going back to at least to the 18.04 base.
And certain ancient and crusty version of Qt based applications from Ubuntu's Universe repos will not install with neon, as they are hard coded (by Debian, not Ubuntu) to require an exact version of a Qt package, one that isn't even necessary to run them. This has been an issue since the very beginning, as well as for some third party debs for Qt applications that are essentially modified from ones built for Debian.

[GreyGeek]

Neon is Ubuntu, and isn't even a distro. So, yes, it does not package wine32, or *anything* not related to Plasma, KDE packaging. So win32 is going to be an Ubuntu package, no matter what.
But you are reading far too much into that statement , since the poppler issue from that thread has already been addressed.


32-bit not being a priority does not mean that it will never be addressed.
This recent snafu is directly from building the updated 32 bit packages to match the 64 bit versions needed by the upgraded Digikam

I'm familiar with the "neon isn't a distro" claim but common practice shows that users are treating it like it was, and most probably expect it to be.

Also, I wasn't "reading" anything into Riddell's post. Wine32 was working well in Neon's previous release but when neon released their latest point release I decided to to a clean install. My last of many methods tried in an effort to install wine32 failed precisely because libpoppler failed to install and while searching for YAS I found Riddell's post. Riddell was clear about the chances of libpoppler being modified in order to allow wine32 to be installed on neon, and never is a long time to wait. As for "non-neon" software not being supported, despite wine32 being supported in the previous point release, I understand that Riddell is making a policy decision and probably the right one, but it is a decision which tells folks who need or want wine32 to look elsewhere for a "distro" and give up their desire to run the Plasma desktop on the leading (not bleeding) edge, I moved back to Kubuntu 22.04.2 and wine32 installed easily, so the EKG program I need for my wife works beautifully.

The intent of my post was and is to warn people about the fact that wine32 doesn't work in the current point release of neon and to look elsewhere if they need wine32. Had I known in advance that neon wasn't going to have a working wine32 app in neon in the near future I would never have moved to it.

BTW, users of some other distros are experiencing the same failures to install wine32 and not all are because of libpoppler.

[claydoh]

So, unless Riddell caves to external pressure I doubt that wine32 will appear on neon in the future.

Neon is Ubuntu, and isn't even a distro. So, yes, it does not package wine32, or *anything* not related to Plasma, KDE packaging. So win32 is going to be an Ubuntu package, no matter what.
But you are reading far too much into that statement , since the poppler issue from that thread has already been addressed.


32-bit not being a priority does not mean that it will never be addressed.
This recent snafu is directly from building the updated 32 bit packages to match the 64 bit versions needed by the upgraded Digikam

[GreyGeek]

https://forum.kde.org/viewtopic.php?...176375#p458746
jriddell says:

Re: I cannot install Wine staging on Jammy-rebased KDE Neon

Tue Nov 01, 2022 4:38 pm

Yes I'm afraid our poppler build makes the neon archive incompatible with the wine-staging packages at least on i386. There's no easy way around this unfortunately and it's not a priority for Neon to be compatible with non-KDE software.

So, unless Riddell caves to external pressure I doubt that wine32 will appear on neon in the future.

[claydoh]

It isn't steam, I do use that myself. It doesn't have the depth of 32 bit dependencies that Wine does.
I also use Lutris and the new-ish Bottles project for the rare moments I need something run with Wine.

The Neon problem is that some upgrades ( a new Digikam in this case iirc) needs an updated library, that has a sub-dependency that also has a 32-bit version needed by a sub-dependency for wine.
It is sort of a whack-a-mole situation.
But the devs had mentioned creating tests to help find these beasties, so they can set up and build the 32-bit items as needed.
I don't think they have, yet lol.

[mr_raider]

Yeah. I stopped using system wide installs of wine and use wine only in bottle (i.e. Lutris). But removing wine i386 is likely to cause damage My guess is steam pulled in a lot dependencies.

[claydoh]

Solution:

https://forum.kde.org/viewtopic.php?...12b7a4259e41bb

Lol, you beat me too it I decided to take a shower instead of booting my PC and looking for updates.

One can use apt to install these, as you normally would.
I had these installed already, here, but I also don't have Wine or WineHQ packages installed.

[mr_raider]

Solution:

https://forum.kde.org/viewtopic.php?...12b7a4259e41bb

[claydoh]

I suggest waiting a day or so. Sometimes my local repo mirror ("Server for New Zealand") gets messed up, and switching (sudo software-properties-qt) to the "Main Server" for a while avoids the problem till it gets sorted out.

I also suggest waiting, but it isn't a repo issue in this case. Plus neon don't have mirrors like Ubuntu does.

This is iirc a fubar with 32 bit dependencies and/or apt config changes while trying to fix the last one people were having. But I don't know which specific things are involved yet.

[claydoh]

mr_raider@hk-47:~$
mr_raider@hk-47:~$ apt policy libldap-2.5-0

Sorry, it was nothing after all