gstreamer v1 is still in the distro and has been around since 2012. If projects still need v0, I'm sure it will be picked up on SBo.

I don't know what the point of your post is, but if it's that steam is a 32bit client (which is not mentioned anywhere here), then that is Valve's decision and Slackware has no control over it. If you want to run steam, you either need a 32bit OS or multilib. Pat has made no indications that 32bit Slackware won't see a 15.0 release.

Tried re-installing the older packages, but that didn't solve the problem.
So, I just did a fresh installation from an .iso dated prior to the 8 February updates. WINE once again works as it should. I did install the 5.10.14 kernel, but I won't be installing the rest of 8 Feb. updates.

1 members found this post helpful.

Looks like it's been added today:

Shouldn't make much difference, though, since it's essentially a rename of a package. The libraries are the same, or should be the same?

The reason I wondered if something got clobbered in your upgrade is because I had the same issue a few months ago, and it turned out I was missing a package. (I thought i"d run "upgrade-all/upgrade multilib" and "install-new/install multilib, but I was missing a package in multilib. I've got Alien Bob's WINE package on my laptop, and my own on my desktop and both are OK.

I encounter similar problem, after change the line requests seems still working fine.

That is how Steam use it, Steam needs 32bits files because the developers still compile the games with 32bits. Blame the Game Developers not Steam. Also, this is just a folder, not related with the distro at all, all steam version installed in others distro have this folder. If you use multilib this is not a issue, if you don't use it, stop playing games on Linux 64 bits. This now is your specific issue, not Slackware issue.

What to speak - open Steam catalogue - system req !
More 4Gb RAM 64-bit PC for most all games !
You don't know about this ?
This talk not about Steam, read again my message.

Battle.net application if run at Windows, start from 64-bit, process show 32-bit.

Slackware - Firefox - open pls at i686 web...
one firefox jam ram... work from i386 to also i686 (ex Pentium D) is IMPOSSIBLE today !
https://www.mozilla.org/en-US/firefo...-requirements/

OS...
My favorite game is to start building the OS,
from the very beginning - from the boot record. Step by step. To understand how it.
Start simple. For example, just write the text you want to see at system startup.
Think about what speed do you expect from work and how much speed will you get?
https://www.youtube.com/watch?v=_WcCLmg7YRg

Regarding glibc-2.33 32bit and openssh,
I have found this.

http://git.yoctoproject.org/cgit/cgi...905948e573ceb9
7638070405a2d1a7b94ce6fe

2 members found this post helpful.

Looks like the patch was committed in the openssh github in late November, but that was after the latest release (which is in the Slackware source tree).

EDIT: 32-bit virtual machine (VirtualBox), fully updated. I wrote the new lines into the openssh source code and tried it out with the new glibc from testing; ssh'ing in was successful.

Attached Files

openssh.time64.diff.txt (264 Bytes, 13 views)

2 members found this post helpful.

e2fsprogs 1.46.1
https://mirrors.edge.kernel.org/pub/...-1.46.1.tar.xz
https://mirrors.edge.kernel.org/pub/....46.1.tar.sign

I also tested on my QEMU environment on Slackware-64 box.
After fully updated the 32bit Slackware-current VM, I built openssh package on glibc-2.32 with the patch, but holded to install.
Then, I installed glibc-2.33 from testing directory and rebooted the VM.
After confirming ssh failed to connect, I installed the newly built package from console and rebooted the VM again.
After the second reboot, ssh works again on glibc-2.33.

2 members found this post helpful.

eudev-3.2.10:

https://github.com/gentoo/eudev/commits/master
https://dev.gentoo.org/~blueness/eud...-3.2.10.tar.gz

the '0004-Pavilion-13-x360-keys.patch' is applied in this new release.

Why should 64bit users be required to install multilib just to run steam? Steam is just a platform to run other programs. If those other programs don't run because of their arch, that's understandable, but I shouldn't be forced to install multilib to be able to even open the steam client.

There's plenty of steam games that are 64bit... why can't steam offer both a 32bit and 64bit client and then just a toggle for games that will work on the current system, whether it be pure 32, pure 64, or multilib (like they already have for OS)? They already have a pure 64bit client for Macs, since Apple dropped 32bit support in newer versions of OSX (and in that case, 32bit games simply aren't supported).

NOTE: This isn't directed specifically at you, but it's a complaint I've had about steam for quite some time. I have no *need* for multilib, but if I want to get some casual gaming in, then I am forced to install it, even when the games I play are available as 64bit.

2 members found this post helpful.

I agree with gbschenkel. If you have enough disk space to support 64bit games, I guess you have enough disk space to install multilib, and since alienBOB is kind enough to be doing all the heavy lifting for us on multilib, what specifically is your problem with using it? Are you on dialup or metered cellphone internet? Those are the only issues my limited imagination can come up with. If you want to vent to Steam that they should pay their developers to create 64bit only client for linux when linux users are only 1% of their customers (and most linux distos support multlib so 64bit only client is sort of a low priority feature); I think it far more is appropriate to do so in one of Steam's own forums and not in linux distro forums, because Steam developers are the people in a position to implement such a feature.
Three cheers for alienBOB!!! His multilib, steamclient, and wine packages work great for gaming on Slackware. HOORAH.HOORAH.HOORAH.

It has absolutely nothing to do with space (I have 70+TB total space on my desktop with 14.2 being installed to a 1TB NVMe which is at about 40% capacity) and everything to do with complexity. I ran multilib from 13.0 to 14.1 and decided to try out pure 64bit when I installed 14.2 on my main machine, so my history is not from some pleb that doesn't have experience with it.

Yes, the multilib and compat32 packages that Alien Bob provides (and all his other work) are an amazing contribution and I am thankful of the time he so graciously spends to help support Slackware. However, the packages included in Slackware (and in turn, Alien's compat32 packages) aren't always the only dependencies needed when running 32bit software. Sometimes you need to install additional software from something like SBo. This means needing to load the 32bit dev environment, and compiling on the 32bit dev environment isn't always perfect. Not to mention having multilib can also break building 64bit packages as is documented on the SBo FAQ (yes, the workaround usually works, but, again, complexity). 64bit processors have been available since 2003 (Windows XP was released only 2 years earlier). We're going on almost 20 years of 64bit and we're still forced to use 32bit to run a digital distribution client (which is all steam is).

By no means am I suggesting that users shouldn't use multilib, as it is still very much needed for certain software, but for a relatively simple distribution client, Valve shouldn't be forcing us to use multilib and should only require it if you want to run software on their platform that is only available as 32bit. I mean how many years were there games grayed out since that game didn't support Linux (before Proton was released)?

A 64bit client is already being created since newer versions of OSX do not support any 32bit software (they completely excised multilib from their OS), so I doubt it would take much time at all to port those changes to a Linux client since they're such similar bases.

I know venting on this forum does no good to actually get a 64bit client available, but there's tons of posts on the steam forum already requesting a 64bit client, so I'd just be a drop in the ocean. I just wanted to vent (although, I realize this is not the ideal thread for this).

3 members found this post helpful.

The topic is not that Steam, but that 32-bit support, the 32-bit era, is over. Absolutely.
This is very important to understand.

1 members found this post helpful.