Hi,
Our most recent FESCo meeting involved discussing the proposal to drop i686 builds of jdk8,11,17 from Fedora 37 onward. The topic quickly changed to the larger question of "what do people use i686 packages for?"
Rather than guess, we wanted to ask the community what you use i686 packages for in Fedora. There are no wrong answers here. We are seeking information.
Why? Since the removal of the i686 kernel in Fedora, we want to reduce the number of i686 packages provided in the repo. As time marches on, the ability to build a lot of things for i686 becomes unrealistic or even impossible. Remember it goes beyond providing builds...providing support, bug fixes, and security fixes for those packages too. Maybe some things using i686 packages now can move to x86_64 packages. We do not know yet, but a goal is to figure out what packages, if anything, can drop their i686 builds.
NOTE: Nothing is changing now. We are in an information gathering phase. ~~~~~~~~~~~~~~~~~~~~~~~~
If you use i686 packages for something now, please respond to this thread.
Thanks,
Felix Schwarz fschwarz@fedoraproject.org writes:
I use wine and lutris (+ 32bit mingw packages).
Yes, same here
On Wed, Mar 16, 2022 at 09:54:12AM -0400, David Cantrell wrote:
If you use i686 packages for something now, please respond to this thread.
Steam requires some i686 libs, but frankly I haven't run it recently due to Stadia.
On 16. 03. 22 14:54, David Cantrell wrote:
Hi,
Our most recent FESCo meeting involved discussing the proposal to drop i686 builds of jdk8,11,17 from Fedora 37 onward. The topic quickly changed to the larger question of "what do people use i686 packages for?"
Rather than guess, we wanted to ask the community what you use i686 packages for in Fedora. There are no wrong answers here. We are seeking information.
Why? Since the removal of the i686 kernel in Fedora, we want to reduce the number of i686 packages provided in the repo. As time marches on, the ability to build a lot of things for i686 becomes unrealistic or even impossible. Remember it goes beyond providing builds...providing support, bug fixes, and security fixes for those packages too. Maybe some things using i686 packages now can move to x86_64 packages. We do not know yet, but a goal is to figure out what packages, if anything, can drop their i686 builds.
NOTE: Nothing is changing now. We are in an information gathering phase. ~~~~~~~~~~~~~~~~~~~~~~~~
If you use i686 packages for something now, please respond to this thread.
- I use i686 packages to build my i686 packages. - I (randomly) use i686 packages to build my noarch packages. - I use nosync.i686 to build my i686 packages in mock. - The printer driver for my Brother printer is provided as i386 RPM, but I don't know if I need that, as it doesn't work currently anyway :(
On 16. 03. 22 15:15, Miro Hrončok wrote:
On 16. 03. 22 14:54, David Cantrell wrote:
Hi,
Our most recent FESCo meeting involved discussing the proposal to drop i686 builds of jdk8,11,17 from Fedora 37 onward. The topic quickly changed to the larger question of "what do people use i686 packages for?"
Rather than guess, we wanted to ask the community what you use i686 packages for in Fedora. There are no wrong answers here. We are seeking information.
Why? Since the removal of the i686 kernel in Fedora, we want to reduce the number of i686 packages provided in the repo. As time marches on, the ability to build a lot of things for i686 becomes unrealistic or even impossible. Remember it goes beyond providing builds...providing support, bug fixes, and security fixes for those packages too. Maybe some things using i686 packages now can move to x86_64 packages. We do not know yet, but a goal is to figure out what packages, if anything, can drop their i686 builds.
NOTE: Nothing is changing now. We are in an information gathering phase. ~~~~~~~~~~~~~~~~~~~~~~~~
If you use i686 packages for something now, please respond to this thread.
- I use i686 packages to build my i686 packages. - I (randomly) use i686 packages to build my noarch packages. - I use nosync.i686 to build my i686 packages in mock. - The printer driver for my Brother printer is provided as i386 RPM, but I don't know if I need that, as it doesn't work currently anyway :(
I made it work. I installed cups-libs.i686 so either that on or something in the dep chain is needed.
On Wednesday, 16 March 2022 at 14:54, David Cantrell wrote:
Hi,
Our most recent FESCo meeting involved discussing the proposal to drop i686 builds of jdk8,11,17 from Fedora 37 onward. The topic quickly changed to the larger question of "what do people use i686 packages for?"
Rather than guess, we wanted to ask the community what you use i686 packages for in Fedora. There are no wrong answers here. We are seeking information.
Why? Since the removal of the i686 kernel in Fedora, we want to reduce the number of i686 packages provided in the repo. As time marches on, the ability to build a lot of things for i686 becomes unrealistic or even impossible. Remember it goes beyond providing builds...providing support, bug fixes, and security fixes for those packages too. Maybe some things using i686 packages now can move to x86_64 packages. We do not know yet, but a goal is to figure out what packages, if anything, can drop their i686 builds.
NOTE: Nothing is changing now. We are in an information gathering phase. ~~~~~~~~~~~~~~~~~~~~~~~~
If you use i686 packages for something now, please respond to this thread.
I use the ancient Linux builds of Acrobat Reader and Adobe Air as well as Wine for some games.
For Adobe Air, there's some hope for a 64-bit redistributable version since it was taken over by Harman: https://airsdk.harman.com/ , but we're still not there yet: https://github.com/airsdk/Adobe-Runtime-Support/issues/1267#issuecomment-944...
Regards, Dominik
On Wed, Mar 16, 2022 at 09:54:12AM -0400, David Cantrell wrote:
If you use i686 packages for something now, please respond to this thread.
I use {glibc{,-devel,-static},{gmp,mpfr,libmpc}{,-devel}}.i686 for development and testing of GCC, even in Fedora packages I'd strongly prefer to keep the -m32 support around which also requires at least those packages (well, currently it requires far more so that it can build documentation etc.).
Jakub
On Wed, 2022-03-16 at 15:24 +0100, Jakub Jelinek wrote:
On Wed, Mar 16, 2022 at 09:54:12AM -0400, David Cantrell wrote:
If you use i686 packages for something now, please respond to this thread.
I use {glibc{,-devel,-static},{gmp,mpfr,libmpc}{,-devel}}.i686 for development and testing of GCC, even in Fedora packages I'd strongly prefer to keep the -m32 support around which also requires at least those packages (well, currently it requires far more so that it can build documentation etc.).
Same here :)
BR, Ali --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
On Wed, 16 Mar 2022 at 14:25, Jakub Jelinek wrote:
On Wed, Mar 16, 2022 at 09:54:12AM -0400, David Cantrell wrote:
If you use i686 packages for something now, please respond to this thread.
I use {glibc{,-devel,-static},{gmp,mpfr,libmpc}{,-devel}}.i686 for development and testing of GCC, even in Fedora packages I'd strongly prefer to keep the -m32 support around which also requires at least those packages (well, currently it requires far more so that it can build documentation etc.).
I'm a bit late to this thread, but I also use glibc i686 packages for upstream GCC development and testing. I build a 64-bit GCC and test with -m32 so I think I only need the 32-bit glibc packages for that.
I would prefer not to have to do that in a container using a different distro.
David Cantrell dcantrell@redhat.com writes:
Why? Since the removal of the i686 kernel in Fedora, we want to reduce the number of i686 packages provided in the repo. As time marches on, the ability to build a lot of things for i686 becomes unrealistic or even impossible. Remember it goes beyond providing builds...providing support, bug fixes, and security fixes for those packages too. Maybe some things using i686 packages now can move to x86_64 packages. We do not know yet, but a goal is to figure out what packages, if anything, can drop their i686 builds.
NOTE: Nothing is changing now. We are in an information gathering phase. ~~~~~~~~~~~~~~~~~~~~~~~~
If you use i686 packages for something now, please respond to this thread.
Nothing that couldn't be cross-built and provided as an x86_64 package.
I use wine, which as I understand it, requires 32-bit libraries to run 32-bit Windows binaries.
Given the weakness of x86 ASLR, it makes sense to ensure most of the i686 packages aren't actually getting used (e.g., no browsers). At that point, seems like we'd be better off not building for the arch at all, and doing cross-builds from x86_64 for the packages that need it.
Be well, --Robbie
On 3/16/22 10:35, Robbie Harwood wrote:
David Cantrell dcantrell@redhat.com writes:
Why? Since the removal of the i686 kernel in Fedora, we want to reduce the number of i686 packages provided in the repo. As time marches on, the ability to build a lot of things for i686 becomes unrealistic or even impossible. Remember it goes beyond providing builds...providing support, bug fixes, and security fixes for those packages too. Maybe some things using i686 packages now can move to x86_64 packages. We do not know yet, but a goal is to figure out what packages, if anything, can drop their i686 builds.
NOTE: Nothing is changing now. We are in an information gathering phase. ~~~~~~~~~~~~~~~~~~~~~~~~
If you use i686 packages for something now, please respond to this thread.
Nothing that couldn't be cross-built and provided as an x86_64 package.
I use wine, which as I understand it, requires 32-bit libraries to run 32-bit Windows binaries.
Given the weakness of x86 ASLR, it makes sense to ensure most of the i686 packages aren't actually getting used (e.g., no browsers). At that point, seems like we'd be better off not building for the arch at all, and doing cross-builds from x86_64 for the packages that need it.
+1 on cross-compilation. Native compilation on 32-bit is a dead end.
On Wed, Mar 16, 2022 at 07:27:05PM -0400, Demi Marie Obenour wrote:
On 3/16/22 10:35, Robbie Harwood wrote:
David Cantrell dcantrell@redhat.com writes:
Why? Since the removal of the i686 kernel in Fedora, we want to reduce the number of i686 packages provided in the repo. As time marches on, the ability to build a lot of things for i686 becomes unrealistic or even impossible. Remember it goes beyond providing builds...providing support, bug fixes, and security fixes for those packages too. Maybe some things using i686 packages now can move to x86_64 packages. We do not know yet, but a goal is to figure out what packages, if anything, can drop their i686 builds.
NOTE: Nothing is changing now. We are in an information gathering phase. ~~~~~~~~~~~~~~~~~~~~~~~~
If you use i686 packages for something now, please respond to this thread.
Nothing that couldn't be cross-built and provided as an x86_64 package.
I use wine, which as I understand it, requires 32-bit libraries to run 32-bit Windows binaries.
Given the weakness of x86 ASLR, it makes sense to ensure most of the i686 packages aren't actually getting used (e.g., no browsers). At that point, seems like we'd be better off not building for the arch at all, and doing cross-builds from x86_64 for the packages that need it.
+1 on cross-compilation. Native compilation on 32-bit is a dead end.
Cross-compilation isn't really practical for RPMs the way we do things now. We would have to go all-in the way OpenSUSE has done, but that's a huge change.
Rich.
On Wed, Mar 16, 2022 at 07:27:05PM -0400, Demi Marie Obenour wrote:
Native compilation on 32-bit is a dead end.
And I was going to add that this is wrong - 32 bit chroots running on 64 bit hosts work fine and run at full speed. (Or 32 bit VMs, but you need to still build kernel.i686 which we don't).
Rich.
* Richard W. M. Jones:
On Wed, Mar 16, 2022 at 07:27:05PM -0400, Demi Marie Obenour wrote:
Native compilation on 32-bit is a dead end.
And I was going to add that this is wrong - 32 bit chroots running on 64 bit hosts work fine and run at full speed.
No, not for everyone, they don't. Some Fedora packages need more than a 32-bit address space to build, and that becomes more and more common.
Thanks, Florian
On Thu, Mar 17, 2022 at 11:10:12AM +0100, Florian Weimer wrote:
- Richard W. M. Jones:
On Wed, Mar 16, 2022 at 07:27:05PM -0400, Demi Marie Obenour wrote:
Native compilation on 32-bit is a dead end.
And I was going to add that this is wrong - 32 bit chroots running on 64 bit hosts work fine and run at full speed.
No, not for everyone, they don't. Some Fedora packages need more than a 32-bit address space to build, and that becomes more and more common.
This is true, but what proportion of packages does this really affect? Also it's stuff like Firefox that we wouldn't want to compile for 32 bit anyway.
Rich.
On Thu, Mar 17, 2022 at 6:25 AM Richard W.M. Jones rjones@redhat.com wrote:
On Thu, Mar 17, 2022 at 11:10:12AM +0100, Florian Weimer wrote:
- Richard W. M. Jones:
On Wed, Mar 16, 2022 at 07:27:05PM -0400, Demi Marie Obenour wrote:
Native compilation on 32-bit is a dead end.
And I was going to add that this is wrong - 32 bit chroots running on 64 bit hosts work fine and run at full speed.
No, not for everyone, they don't. Some Fedora packages need more than a 32-bit address space to build, and that becomes more and more common.
This is true, but what proportion of packages does this really affect? Also it's stuff like Firefox that we wouldn't want to compile for 32 bit anyway.
It affects three major categories:
* Go/Rust (or anything static build+linking) since they need memory to load all sources and object code to compile * Firefox (because of Rust) * Chromium (because it does a unity build with gigabytes of C and C++ source code)
On Thu, Mar 17, 2022 at 6:25 AM Richard W.M. Jones rjones@redhat.com wrote:
On Thu, Mar 17, 2022 at 11:10:12AM +0100, Florian Weimer wrote:
- Richard W. M. Jones:
On Wed, Mar 16, 2022 at 07:27:05PM -0400, Demi Marie Obenour wrote:
Native compilation on 32-bit is a dead end.
And I was going to add that this is wrong - 32 bit chroots running on 64 bit hosts work fine and run at full speed.
No, not for everyone, they don't. Some Fedora packages need more than a 32-bit address space to build, and that becomes more and more common.
This is true, but what proportion of packages does this really affect? Also it's stuff like Firefox that we wouldn't want to compile for 32 bit anyway.
See my earlier comment about llvm and OpenGL.
- ajax
On Thu, Mar 17, 2022 at 09:07:50AM +0000, Richard W.M. Jones wrote:
On Wed, Mar 16, 2022 at 07:27:05PM -0400, Demi Marie Obenour wrote:
On 3/16/22 10:35, Robbie Harwood wrote:
David Cantrell dcantrell@redhat.com writes:
Why? Since the removal of the i686 kernel in Fedora, we want to reduce the number of i686 packages provided in the repo. As time marches on, the ability to build a lot of things for i686 becomes unrealistic or even impossible. Remember it goes beyond providing builds...providing support, bug fixes, and security fixes for those packages too. Maybe some things using i686 packages now can move to x86_64 packages. We do not know yet, but a goal is to figure out what packages, if anything, can drop their i686 builds.
NOTE: Nothing is changing now. We are in an information gathering phase. ~~~~~~~~~~~~~~~~~~~~~~~~
If you use i686 packages for something now, please respond to this thread.
Nothing that couldn't be cross-built and provided as an x86_64 package.
I use wine, which as I understand it, requires 32-bit libraries to run 32-bit Windows binaries.
Given the weakness of x86 ASLR, it makes sense to ensure most of the i686 packages aren't actually getting used (e.g., no browsers). At that point, seems like we'd be better off not building for the arch at all, and doing cross-builds from x86_64 for the packages that need it.
+1 on cross-compilation. Native compilation on 32-bit is a dead end.
Cross-compilation isn't really practical for RPMs the way we do things now. We would have to go all-in the way OpenSUSE has done, but that's a huge change.
Yes, I wouldn't bother thinking about cross compilation using Fedora, except for mingw. For Linux cross compilation it is easier to use Debian in a container from your Fedora host.
You can install library / devel packages from any Debian architecture no matter what the native arch this. This gives ability to get coverage of pretty much every architecture that still matters, and several that don't. Especially useful is that you can get big-endian build coverage. It isn't worth special casing the i686 arch to use Fedora if you also case about other archs IMHO.
Of course to actually run the unit tests, you would still need QEMU usermode emulation, except in the x86_64:i686 combination case.
In libvirt/qemu upstream we Debian based containers to cross compile for aarch64, armv6, armv7, i686, mips, mipsel, mips64el, ppc64el, s390x. Some examples:
https://gitlab.com/libvirt/libvirt/-/blob/master/ci/containers/debian-11-cro... https://gitlab.com/libvirt/libvirt/-/blob/master/ci/containers/debian-11-cro...
With regards, Daniel
* Daniel P. Berrangé:
Yes, I wouldn't bother thinking about cross compilation using Fedora, except for mingw. For Linux cross compilation it is easier to use Debian in a container from your Fedora host.
You can install library / devel packages from any Debian architecture no matter what the native arch this. This gives ability to get coverage of pretty much every architecture that still matters, and several that don't. Especially useful is that you can get big-endian build coverage. It isn't worth special casing the i686 arch to use Fedora if you also case about other archs IMHO.
I agree that the Debian approach is very nice: it reuses outputs from native builds for cross-compilation. That side-steps a lot of the issues inherent to cross-compilation.
Thanks, Florian
Hi,
+1 on cross-compilation. Native compilation on 32-bit is a dead end.
Cross-compilation isn't really practical for RPMs the way we do things now. We would have to go all-in the way OpenSUSE has done, but that's a huge change.
cross builds is a thing for kernel and firmware though and will continue to be. Those are freestanding though and don't need much beyond cross-gcc and cross-binutils (and in i686 case not even that, -m32 will do).
take care, Gerd
I'm not sure if I use any i686 executables, but I sure do use i686 builds of libraries for cross-compiling. By which I mean both i686-linux and i686-win32.
A.FI.
If you use i686 packages for something now, please respond to this thread.
I use glibc.i686 and libgcc.i686 to support customers whose i686 machines have not yet died. (Some are about 12 years old, and expected live another 3 years. The ability to use almost 4GB of address space when running ELF.i686 on Linux.x86_64 has provided room for data growth.) I build the software by using cross-platform tools not packaged in Fedora, and the -m32 option of gcc.x86_64.
On Wed, Mar 16, 2022 at 09:54:12AM -0400, David Cantrell wrote:
If you use i686 packages for something now, please respond to this thread.
I use i686 versions of libraries to do local 32-bit builds of C software I'm developing. (Something like 'sudo dnf install lib{one,two}-devel.i686 && meson build-32 -Dc_args=-m32 -Dc_link_args=-m32 -Dcpp_args=-m32 -Dcpp_link_args=-m32 --pkg-config-path=/usr/lib/pkgconfig && ninja -C build-32' .)
So I'd be interesting in keeping 32-bit versions of all BuildRequires for systemd.
Zbyszek
On Wed, Mar 16, 2022 at 11:55 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Mar 16, 2022 at 09:54:12AM -0400, David Cantrell wrote:
If you use i686 packages for something now, please respond to this thread.
I use i686 versions of libraries to do local 32-bit builds of C software I'm developing. (Something like 'sudo dnf install lib{one,two}-devel.i686 && meson build-32 -Dc_args=-m32 -Dc_link_args=-m32 -Dcpp_args=-m32 -Dcpp_link_args=-m32 --pkg-config-path=/usr/lib/pkgconfig && ninja -C build-32' .)
So I'd be interesting in keeping 32-bit versions of all BuildRequires for systemd.
Who uses those builds and what do they use them for?
josh
On Wed, Mar 16, 2022 at 12:54:23PM -0400, Josh Boyer wrote:
On Wed, Mar 16, 2022 at 11:55 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Mar 16, 2022 at 09:54:12AM -0400, David Cantrell wrote:
If you use i686 packages for something now, please respond to this thread.
I use i686 versions of libraries to do local 32-bit builds of C software I'm developing. (Something like 'sudo dnf install lib{one,two}-devel.i686 && meson build-32 -Dc_args=-m32 -Dc_link_args=-m32 -Dcpp_args=-m32 -Dcpp_link_args=-m32 --pkg-config-path=/usr/lib/pkgconfig && ninja -C build-32' .)
So I'd be interesting in keeping 32-bit versions of all BuildRequires for systemd.
Who uses those builds and what do they use them for?
They are purely local. I use them to compile and run tests locally so I know that the code works correctly on 32-bit. I'll also do test builds on arm/arm64/ppc64/riscv/anything-else-that-I-can-lay my hand on.
Zbyszek
On Wed, Mar 16, 2022 at 1:37 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Mar 16, 2022 at 12:54:23PM -0400, Josh Boyer wrote:
On Wed, Mar 16, 2022 at 11:55 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Mar 16, 2022 at 09:54:12AM -0400, David Cantrell wrote:
If you use i686 packages for something now, please respond to this thread.
I use i686 versions of libraries to do local 32-bit builds of C software I'm developing. (Something like 'sudo dnf install lib{one,two}-devel.i686 && meson build-32 -Dc_args=-m32 -Dc_link_args=-m32 -Dcpp_args=-m32 -Dcpp_link_args=-m32 --pkg-config-path=/usr/lib/pkgconfig && ninja -C build-32' .)
So I'd be interesting in keeping 32-bit versions of all BuildRequires for systemd.
Who uses those builds and what do they use them for?
They are purely local. I use them to compile and run tests locally so I know that the code works correctly on 32-bit. I'll also do test builds on arm/arm64/ppc64/riscv/anything-else-that-I-can-lay my hand on.
Are you aware of any upstream users of 32-bit systemd? Or some other distro that requires it?
I ask because I see several responses along the same lines (I use it to build 32-bit packages), but unless *Fedora* uses those resulting 32-bit builds it seems like an odd reason to keep i686 around. Yes, being able to build for i686 means you need i686 but the root of the question is why do you need to build for i686?
If there are other distros that still support 32-bit systemd, could you do your 32-bit build and test against those instead?
josh
On Wed, Mar 16, 2022 at 02:11:23PM -0400, Josh Boyer wrote:
On Wed, Mar 16, 2022 at 1:37 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Mar 16, 2022 at 12:54:23PM -0400, Josh Boyer wrote:
On Wed, Mar 16, 2022 at 11:55 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Mar 16, 2022 at 09:54:12AM -0400, David Cantrell wrote:
If you use i686 packages for something now, please respond to this thread.
I use i686 versions of libraries to do local 32-bit builds of C software I'm developing. (Something like 'sudo dnf install lib{one,two}-devel.i686 && meson build-32 -Dc_args=-m32 -Dc_link_args=-m32 -Dcpp_args=-m32 -Dcpp_link_args=-m32 --pkg-config-path=/usr/lib/pkgconfig && ninja -C build-32' .)
So I'd be interesting in keeping 32-bit versions of all BuildRequires for systemd.
Who uses those builds and what do they use them for?
They are purely local. I use them to compile and run tests locally so I know that the code works correctly on 32-bit. I'll also do test builds on arm/arm64/ppc64/riscv/anything-else-that-I-can-lay my hand on.
Are you aware of any upstream users of 32-bit systemd? Or some other distro that requires it?
I ask because I see several responses along the same lines (I use it to build 32-bit packages), but unless *Fedora* uses those resulting 32-bit builds it seems like an odd reason to keep i686 around. Yes, being able to build for i686 means you need i686 but the root of the question is why do you need to build for i686?
To build for 32 bits, I need not just the code, but a hefty set of libraries. I *could* build all of this myself, or use another distro, but that's not very appealing. Fedora gives me up-to-date dependencies in a very convenient fashion. It is also very useful to have the 32-bit deps in the same versions that I have the 64-bit ones, so I can compile and compare builds with the architecture being the only difference. I also don't want to use a container or a special environment, but I want to build and run the code "natively" as much as possible. (Or more precisely: I want to *also* run code "natively". For low-level software, running things directly on the local hardware can be quite useful for debugging of certain problems. Container and mock and VMs are useful at other times.)
So the short version is that this is for convenience and "native" development.
If there are other distros that still support 32-bit systemd, could you do your 32-bit build and test against those instead?
The code is portable to 32-bit and 32-bit builds are still supported, and as upstream developer, I need to make sure that the code works on a large set of architectures, even those not supported by Fedora (riscv, mips, x32, etc.).
I consider Fedora superior to other distros. If I can't use Fedora, I'd probably use Debian or Ubuntu or something else, but I'd prefer not to. Fedora is a great developer environment, and development for 32-bit architectures is still relevant.
Zbyszek
I have a bunch of old Loki game ports I'd prefer keep working. I also have some backburner projects that need enough 32-bit userspace to run old binary drivers, but tbh it's probably easier to just use like el7 for that at this point.
To the extent we keep i686 builds [1] I really think they need to be emitted from a 64-bit toolchain. I'm sympathetic to the argument that you shouldn't run a 32-bit web browser anyway, so I don't care _so_ much about linking like firefox or webkit. But something like llvm finds its way into the runtime for a lot of things, like the GL drivers that provide the compatibility with the game you're trying to run, and it's goofy to need to work around 32-bit address space limitations just to link a 32-bit libLLVM. Building with gcc.i686 is a choice we don't need to make.
[1] - My personal opinion here is we should try a little harder than necessary, because I think that kind of compatibility is a worthwhile goal, but also the specific things you need the compatibility have boundaries and 100% coverage for 32-bit builds is pointless.
- ajax
On Wed, Mar 16, 2022 at 9:54 AM David Cantrell dcantrell@redhat.com wrote:
Hi,
Our most recent FESCo meeting involved discussing the proposal to drop i686 builds of jdk8,11,17 from Fedora 37 onward. The topic quickly changed to the larger question of "what do people use i686 packages for?"
Rather than guess, we wanted to ask the community what you use i686 packages for in Fedora. There are no wrong answers here. We are seeking information.
Why? Since the removal of the i686 kernel in Fedora, we want to reduce the number of i686 packages provided in the repo. As time marches on, the ability to build a lot of things for i686 becomes unrealistic or even impossible. Remember it goes beyond providing builds...providing support, bug fixes, and security fixes for those packages too. Maybe some things using i686 packages now can move to x86_64 packages. We do not know yet, but a goal is to figure out what packages, if anything, can drop their i686 builds.
NOTE: Nothing is changing now. We are in an information gathering phase. ~~~~~~~~~~~~~~~~~~~~~~~~
If you use i686 packages for something now, please respond to this thread.
Thanks,
-- David Cantrell dcantrell@redhat.com Red Hat, Inc. | Boston, MA | EST5EDT _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Wed, Mar 16, 2022 at 8:54 AM David Cantrell dcantrell@redhat.com wrote:
Hi,
Our most recent FESCo meeting involved discussing the proposal to drop i686 builds of jdk8,11,17 from Fedora 37 onward. The topic quickly changed to the larger question of "what do people use i686 packages for?"
As it turns out, I only use i686 packages to build kernel-tools. I am not sure why we didn't turn off kernel-tools for i686 when we turned off the kernel. I suppose someone could have been linking to libbpf or libtraceevent, though those have been separate packages for a while now. I actually had to turn off dynamic linking to libtraceevent because i686 would no longer build against it.
Hi,
could you just post some magic dnf command to check which i686 packages are currently installed? Then many less savvy users could simply check what packages are currently installed on their systems. Maybe something like `dnf repoquery --installed |grep i686` works, but I think I have no 686 packages installed, so I cannot really test it. And I do not want to install i686 packages just for that test, who knows what will break.
Ah, and yes, I support removing i686 packages.
Best, laolux
On Wed, Mar 16, 2022 at 9:34 PM laolux laolux via devel < devel@lists.fedoraproject.org> wrote:
Hi,
could you just post some magic dnf command to check which i686 packages are currently installed? Then many less savvy users could simply check what packages are currently installed on their systems. Maybe something like `dnf repoquery --installed |grep i686` works, but I think I have no 686 packages installed, so I cannot really test it. And I do not want to install i686 packages just for that test, who knows what will break.
Ah, and yes, I support removing i686 packages.
For installed packages rpm is much faster:
$ rpm -qa | grep i686 | sort
Thanks, Richard
On Wed, Mar 16, 2022 at 09:54:12AM -0400, David Cantrell wrote:
If you use i686 packages for something now, please respond to this thread.
(1) To compile 32 bit binaries using gcc -m32.
Note that I don't actually care about using these binaries, I use them only to run the test suite for various projects in order to find implicit 64 bit assumptions in code, such as incorrect use of int instead of size_t. One day maybe 32 bit will be completely dead (like 16 bit) and I won't care about this.
(2) To run some 32 bit binaries.
This is getting rare now since I got rid of rubbish like Webex from my life, but happens occasionally.
(3) Needed by Wine (?)
I understand from existing conversations that 32 bit Wine needs the *.i686 packages. I use Wine quite a bit to test Windows cross-compiled builds, so I guess I'm using this.
Rich.
Hi, I use wine and steam (and some libraries which are required to run them) with total of 254 i686 packages. Matyáš
Same here. To be honest, most older games still use 32-bit binaries (even some more recent ones). That's one of the reasons why Windows will prolly never remove WoW64. Or at least for an extremely long time still.
Le lun. 16 janv. 2023, 18 h 13, Arthur Bols arthur@bols.dev a écrit :
On 17/03/2022 10:49, Matyáš Kroupa wrote:
Hi, I use wine and steam (and some libraries which are required to run them)
with total of 254 i686 packages.
Matyáš
I'm also using them for wine and steam.
-- Arthur Bols fas/irc: principis _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
The i686 packages I use are: gamemode, gperftools-devel (to provide a working version of libtcmalloc_minimal), SDL2, steam, and their dependencies.
I use wine and would need 32bit gstreamer; base, good, bad, ugly and libav for some Visual Novels that use MPEG for video.
On Wed, 16 Mar 2022 at 13:55, David Cantrell dcantrell@redhat.com wrote:
If you use i686 packages for something now, please respond to this thread.
steam / wine
On 3/17/22 18:14, Carlos "casep" Sepulveda wrote:
On Wed, 16 Mar 2022 at 13:55, David Cantrell <dcantrell@redhat.com mailto:dcantrell@redhat.com> wrote:
If you use i686 packages for something now, please respond to this thread.
steam / wine
Ditto. Not very often perhaps but that's the primary case.
Occasionally compiling purposes too, ie at least the gcc-glibc bits.
- Panu -
The issue on our home systems is 3rd party printer drivers.
Eg mfc9140cdncupswrapper-1.1.4-0.i386 dcpj4120dwlpr-3.0.1-1.i386 dcpj4120dwcupswrapper-3.0.1-1.i386 mfc9140cdnlpr-1.1.2-1.i386
These then pull in a whole load of dependencies relating to CUPs etc.
On Fri, Mar 18, 2022 at 12:30:52AM -0000, Steven Ellis wrote:
The issue on our home systems is 3rd party printer drivers.
Eg mfc9140cdncupswrapper-1.1.4-0.i386 dcpj4120dwlpr-3.0.1-1.i386 dcpj4120dwcupswrapper-3.0.1-1.i386 mfc9140cdnlpr-1.1.2-1.i386
Could you show 'rpm -qR mfc9140cdncupswrapper-1.1.4-0.i386 dcpj4120dwlpr-3.0.1-1.i386 dcpj4120dwcupswrapper-3.0.1-1.i386 mfc9140cdnlpr-1.1.2-1.i386' ?
Zbyszek
On 3/20/22 04:38 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Mar 18, 2022 at 12:30:52AM -0000, Steven Ellis wrote:
The issue on our home systems is 3rd party printer drivers.
Eg mfc9140cdncupswrapper-1.1.4-0.i386 dcpj4120dwlpr-3.0.1-1.i386 dcpj4120dwcupswrapper-3.0.1-1.i386 mfc9140cdnlpr-1.1.2-1.i386
Could you show 'rpm -qR mfc9140cdncupswrapper-1.1.4-0.i386 dcpj4120dwlpr-3.0.1-1.i386 dcpj4120dwcupswrapper-3.0.1-1.i386 mfc9140cdnlpr-1.1.2-1.i386' ?
On my system, for dcpl2540dwcupswrapper-3.2.0-1.i386 and dcpl2540dwlpr-3.2.0-1.i386, I get:
# rpm -qR dcpl2540dwcupswrapper-3.2.0-1.i386 dcpl2540dwlpr-3.2.0-1.i38 /bin/sh /bin/sh /bin/sh /usr/bin/perl cups dcpl2540dwlpr perl rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 /bin/sh /bin/sh /bin/sh /bin/sh /usr/bin/perl ghostscript perl perl(Cwd) perl(File::Copy) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Steve
I have ~230 i686 RPMs on my F34 system dedicated purely to gaming. Names I recognize are Wine and Steam. For the rest I can't tell whether they are just dependencies of those two, or something else.
I have zero i686 RPMs on my F35 system dedicated purely to work.
--
Michal Schorm Software Engineer Core Services - Databases Team Red Hat
--
On Sun, Mar 20, 2022 at 12:40 PM Steven A. Falco stevenfalco@gmail.com wrote:
On 3/20/22 04:38 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Mar 18, 2022 at 12:30:52AM -0000, Steven Ellis wrote:
The issue on our home systems is 3rd party printer drivers.
Eg mfc9140cdncupswrapper-1.1.4-0.i386 dcpj4120dwlpr-3.0.1-1.i386 dcpj4120dwcupswrapper-3.0.1-1.i386 mfc9140cdnlpr-1.1.2-1.i386
Could you show 'rpm -qR mfc9140cdncupswrapper-1.1.4-0.i386 dcpj4120dwlpr-3.0.1-1.i386 dcpj4120dwcupswrapper-3.0.1-1.i386 mfc9140cdnlpr-1.1.2-1.i386' ?
On my system, for dcpl2540dwcupswrapper-3.2.0-1.i386 and dcpl2540dwlpr-3.2.0-1.i386, I get:
# rpm -qR dcpl2540dwcupswrapper-3.2.0-1.i386 dcpl2540dwlpr-3.2.0-1.i38 /bin/sh /bin/sh /bin/sh /usr/bin/perl cups dcpl2540dwlpr perl rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 /bin/sh /bin/sh /bin/sh /bin/sh /usr/bin/perl ghostscript perl perl(Cwd) perl(File::Copy) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Steve
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Steven Ellis wrote:
The issue on our home systems is 3rd party printer drivers.
Eg mfc9140cdncupswrapper-1.1.4-0.i386 dcpj4120dwlpr-3.0.1-1.i386 dcpj4120dwcupswrapper-3.0.1-1.i386 mfc9140cdnlpr-1.1.2-1.i386
These then pull in a whole load of dependencies relating to CUPs etc.
According to https://openprinting.github.io/printers/ , both those printers allegedly support driverless printing through the Apple AirPrint standard, which is supported by current CUPS. This SHOULD include AirPrint over USB, if the standard is correctly and completely implemented. It may be worth trying, though it may expose fewer options than using the proprietary CUPS driver RPM.
I do not know whether these printers would also work with some Free as in Speech CUPS driver such as generic PostScript, PCL, or ESC/P, or such as the Gutenprint drivers for older Brother printer models, nor, if they would at all, whether that would lead to more flexibility than just using AirPrint.
Kevin Kofler
Hi,
On Tue, 22 Mar 2022 00:57 +0100 Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Steven Ellis wrote:
The issue on our home systems is 3rd party printer drivers.
Eg mfc9140cdncupswrapper-1.1.4-0.i386 dcpj4120dwlpr-3.0.1-1.i386 dcpj4120dwcupswrapper-3.0.1-1.i386 mfc9140cdnlpr-1.1.2-1.i386
These then pull in a whole load of dependencies relating to CUPs etc.
According to https://openprinting.github.io/printers/ , both those printers allegedly support driverless printing through the Apple AirPrint standard, which is supported by current CUPS. This SHOULD include AirPrint over USB, if the standard is correctly and completely implemented. It may be worth trying, though it may expose fewer options than using the proprietary CUPS driver RPM.
I do not have the above models, but I also need i686 for my Brother printer driver, even though my model (HL-L8250CDN) is also listed on that website.
This is because not even the basic functions work correctly using the out-of-the-box support -- the whole "printing options" page is blank.
I'm not sure if this is an error on the GNOME side or on the Brother side, but I do know that installing the driver which I have been unofficially packaging sinds ~ F23 makes it work again (at the expense of having the network-discovered printer appear as well, with the non-functional out-of-the-box "driver").
I did not report a bug about the missing options, I guess I can do that somewhere in the OpenPrinting organisation now that that has gained some momentum. In the meantime, the i686 driver is needed on this end.
I do not know whether these printers would also work with some Free as in Speech CUPS driver such as generic PostScript, PCL, or ESC/P, or such as the Gutenprint drivers for older Brother printer models, nor, if they would at all, whether that would lead to more flexibility than just using AirPrint.
No other driver I tried in the ~ F23 timeframe would give me any output at that time.
Regards,
Stijn
Stijn Hoop via devel wrote:
This is because not even the basic functions work correctly using the out-of-the-box support -- the whole "printing options" page is blank.
I'm not sure if this is an error on the GNOME side or on the Brother side,
… if it is even an error at all.
AirPrint is not exactly known for offering a lot of options, it is mostly Apple-style "print this thing for me", take it or leave it.
That said, the screenshots on Apple's own AirPrint page do show some basic options, e.g., enabling or disabling duplex mode on printers with a builtin duplexer.
What you will definitely not get in AirPrint mode is options such as printing using CMY instead of CMYK if you are out of black ink (though some printers do not even support that at the protocol level, because they take only RGB input and convert that to CMYK the way they fancy). (But does the proprietary driver even allow you to do that?)
So it is hard to tell whether the lack of options is a bug somewhere or whether it is just the printer exposing by design only the bare minimum interface to tick the AirPrint checkbox in some checklist.
I must say I have never tried AirPrint mode because I have only used printers with working Free drivers so far (HP printers supported by HPLIP without plugin, and now a Canon multi-function printer supported by Gutenprint and SANE).
Kevin Kofler
On Wed, Mar 16, 2022 at 9:54 AM David Cantrell dcantrell@redhat.com wrote:
Hi,
Our most recent FESCo meeting involved discussing the proposal to drop i686 builds of jdk8,11,17 from Fedora 37 onward. The topic quickly changed to the larger question of "what do people use i686 packages for?"
Rather than guess, we wanted to ask the community what you use i686 packages for in Fedora. There are no wrong answers here. We are seeking information.
Why? Since the removal of the i686 kernel in Fedora, we want to reduce the number of i686 packages provided in the repo. As time marches on, the ability to build a lot of things for i686 becomes unrealistic or even impossible. Remember it goes beyond providing builds...providing support, bug fixes, and security fixes for those packages too. Maybe some things using i686 packages now can move to x86_64 packages. We do not know yet, but a goal is to figure out what packages, if anything, can drop their i686 builds.
NOTE: Nothing is changing now. We are in an information gathering phase. ~~~~~~~~~~~~~~~~~~~~~~~~
If you use i686 packages for something now, please respond to this thread.
I use it because research on certain network controllers requires it. But, I can move said research to Debian so it is not a blocker to me.
On Wed, Mar 16, 2022 at 2:56 PM David Cantrell dcantrell@redhat.com wrote:
If you use i686 packages for something now, please respond to this thread.
There are some game-related packages (not dependencies) which need to be installed as i686 so that they can apply to 32bit games. I know of the following: * mangohud (performance overlay) * gamemode (performance and desktop UX tuning)
Perhaps there are more.
On Wed, Mar 16, 2022 at 9:54 AM David Cantrell dcantrell@redhat.com wrote:
Hi,
Our most recent FESCo meeting involved discussing the proposal to drop i686 builds of jdk8,11,17 from Fedora 37 onward. The topic quickly changed to the larger question of "what do people use i686 packages for?"
Rather than guess, we wanted to ask the community what you use i686 packages for in Fedora. There are no wrong answers here. We are seeking information.
Why? Since the removal of the i686 kernel in Fedora, we want to reduce the number of i686 packages provided in the repo. As time marches on, the ability to build a lot of things for i686 becomes unrealistic or even impossible. Remember it goes beyond providing builds...providing support, bug fixes, and security fixes for those packages too. Maybe some things using i686 packages now can move to x86_64 packages. We do not know yet, but a goal is to figure out what packages, if anything, can drop their i686 builds.
NOTE: Nothing is changing now. We are in an information gathering phase. ~~~~~~~~~~~~~~~~~~~~~~~~
If you use i686 packages for something now, please respond to this thread.
I use i686 packages for a few cases:
* Older (proprietary) Linux userspace drivers (e.g. printers, etc.) and applications * Substituting the Steam runtime components for Steam games for performance and reliability * Playing my Linux native games * Windows applications (most of my *currently developed* Windows apps are still 32-bit)
Hi,
On Wed, 16 Mar 2022 09:54:12 -0400 David Cantrell dcantrell@redhat.com wrote:
If you use i686 packages for something now, please respond to this thread.
As many others, I need 32-bit printer drivers for my ~10 year old color laser:
$ rpm -qa | grep i686 libgcc-11.2.1-9.fc35.i686 glibc-gconv-extra-2.34-28.fc35.i686 glibc-2.34-28.fc35.i686 brother-hl-l8250cdn-1.0-2.fc35.i686
Regards,
Stijn
Stijn Hoop via devel wrote:
As many others, I need 32-bit printer drivers for my ~10 year old color laser:
$ rpm -qa | grep i686 libgcc-11.2.1-9.fc35.i686 glibc-gconv-extra-2.34-28.fc35.i686 glibc-2.34-28.fc35.i686 brother-hl-l8250cdn-1.0-2.fc35.i686
According to https://openprinting.github.io/printers/ , this printer allegedly supports driverless printing through the Apple AirPrint standard, which is supported by current CUPS. This SHOULD include AirPrint over USB, if the standard is correctly and completely implemented. It may be worth trying, though it may expose fewer options than using the proprietary CUPS driver RPM.
I do not know whether this printer would also work with some Free as in Speech CUPS driver such as generic PostScript, PCL, or ESC/P, or such as the Gutenprint drivers for older Brother printer models, nor, if it would at all, whether that would lead to more flexibility than just using AirPrint.
Kevin Kofler
All these are somehow related to Steam and x86 32 bit games
# rpm -qa | grep 686 | sort alsa-lib-1.2.6.1-3.fc35.i686 atk-2.36.0-4.fc35.i686 at-spi2-atk-2.38.0-3.fc35.i686 at-spi2-atk-debuginfo-2.38.0-3.fc35.i686 at-spi2-atk-debugsource-2.38.0-3.fc35.i686 at-spi2-core-2.42.0-1.fc35.i686 avahi-libs-0.8-14.fc35.i686 bluez-libs-5.63-1.fc35.i686 bzip2-libs-1.0.8-9.fc35.i686 cairo-1.17.4-4.fc35.i686 cairo-gobject-1.17.4-4.fc35.i686 colord-libs-1.4.5-3.fc35.i686 cups-libs-2.3.3op2-16.fc35.i686 cyrus-sasl-lib-2.1.27-14.fc35.i686 dbus-libs-1.12.22-1.fc35.i686 dconf-0.40.0-5.fc35.i686 elfutils-debuginfod-client-0.186-1.fc35.i686 elfutils-libelf-0.186-1.fc35.i686 elfutils-libs-0.186-1.fc35.i686 expat-2.4.4-1.fc35.i686 fdk-aac-free-2.0.0-7.fc35.i686 flac-libs-1.3.4-1.fc35.i686 fontconfig-2.13.94-5.fc35.i686 freetype-2.11.0-3.fc35.i686 fribidi-1.0.10-5.fc35.i686 gamemode-1.6-3.fc35.i686 gdbm-libs-1.22-1.fc35.i686 gdk-pixbuf2-2.42.6-2.fc35.i686 gdk-pixbuf2-modules-2.42.6-2.fc35.i686 glib2-2.70.5-1.fc35.i686 glibc-2.34-29.fc35.i686 glibc-gconv-extra-2.34-29.fc35.i686 glib-networking-2.70.1-1.fc35.i686 gmp-6.2.0-7.fc35.i686 gnutls-3.7.2-3.fc35.i686 graphite2-1.3.14-8.fc35.i686 gsm-1.0.19-6.fc35.i686 gstreamer1-1.20.0-1.fc35.i686 gtk2-2.24.33-5.fc35.i686 gtk3-3.24.31-2.fc35.i686 harfbuzz-2.9.1-1.fc35.i686 inih-49-4.fc35.i686 jasper-libs-2.0.33-1.fc35.i686 jbigkit-libs-2.1-22.fc35.i686 json-glib-1.6.6-1.fc35.i686 keyutils-libs-1.6.1-3.fc35.i686 krb5-libs-1.19.2-2.fc35.i686 lcms2-2.12-2.fc35.i686 libasyncns-0.8-21.fc35.i686 libatomic-11.2.1-9.fc35.i686 libblkid-2.37.4-1.fc35.i686 libbrotli-1.0.9-6.fc35.i686 libcanberra-0.30-27.fc35.i686 libcanberra-gtk2-0.30-27.fc35.i686 libcanberra-gtk3-0.30-27.fc35.i686 libcap-2.48-3.fc35.i686 libcloudproviders-0.3.1-4.fc35.i686 libcom_err-1.46.3-1.fc35.i686 libcurl-7.79.1-1.fc35.i686 libdatrie-0.2.13-2.fc35.i686 libdb-5.3.28-50.fc35.i686 libdbusmenu-16.04.0-18.fc35.i686 libdbusmenu-gtk3-16.04.0-18.fc35.i686 libdrm-2.4.110-1.fc35.i686 libedit-3.1-40.20210910cvs.fc35.i686 libepoxy-1.5.9-1.fc35.i686 libevent-2.1.12-4.fc35.i686 libffi-3.1-29.fc35.i686 libgcc-11.2.1-9.fc35.i686 libgcrypt-1.9.4-1.fc35.i686 libglvnd-1.3.4-2.fc35.i686 libglvnd-glx-1.3.4-2.fc35.i686 libgpg-error-1.43-1.fc35.i686 libgusb-0.3.9-1.fc35.i686 libICE-1.0.10-7.fc35.i686 libicu-69.1-2.fc35.i686 libidn2-2.3.2-3.fc35.i686 libjpeg-turbo-2.1.0-3.fc35.i686 libldac-2.0.2.3-9.fc35.i686 libmodman-2.0.1-25.fc35.i686 libmount-2.37.4-1.fc35.i686 libnghttp2-1.45.1-1.fc35.i686 libnsl-2.34-29.fc35.i686 libogg-1.3.5-2.fc35.i686 libpciaccess-0.16-5.fc35.i686 libpng12-1.2.57-14.fc35.i686 libpng-1.6.37-11.fc35.i686 libproxy-0.4.17-3.fc35.i686 libpsl-0.21.1-4.fc35.i686 libsbc-1.5-2.fc35.i686 libselinux-3.3-1.fc35.i686 libsepol-3.3-2.fc35.i686 libSM-1.2.3-9.fc35.i686 libsndfile-1.0.31-6.fc35.i686 libsoup-2.74.2-1.fc35.i686 libssh-0.9.6-1.fc35.i686 libstdc++-11.2.1-9.fc35.i686 libstemmer-0-17.585svn.fc35.i686 libtasn1-4.16.0-6.fc35.i686 libtdb-1.4.4-3.fc35.i686 libthai-0.1.28-7.fc35.i686 libtiff-4.3.0-4.fc35.i686 libtool-ltdl-2.4.6-50.fc35.i686 libtracker-sparql-3.2.1-1.fc35.i686 libunistring-0.9.10-14.fc35.i686 libunwind-1.5.0-1.fc35.i686 libusb1-1.0.24-4.fc35.i686 libuuid-2.37.4-1.fc35.i686 libva-2.13.0-3.fc35.i686 libvdpau-1.5-1.fc35.i686 libverto-0.3.2-2.fc35.i686 libvorbis-1.3.7-4.fc35.i686 libwayland-client-1.20.0-1.fc35.i686 libwayland-cursor-1.20.0-1.fc35.i686 libwayland-egl-1.20.0-1.fc35.i686 libwebp-1.2.2-1.fc35.i686 libX11-1.7.3.1-1.fc35.i686 libX11-xcb-1.7.3.1-1.fc35.i686 libXau-1.0.9-7.fc35.i686 libxcb-1.13.1-8.fc35.i686 libXcomposite-0.4.5-6.fc35.i686 libxcrypt-4.4.28-1.fc35.i686 libxcrypt-compat-4.4.28-1.fc35.i686 libXcursor-1.2.0-6.fc35.i686 libXdamage-1.1.5-6.fc35.i686 libXext-1.3.4-7.fc35.i686 libXfixes-6.0.0-2.fc35.i686 libXft-2.3.3-7.fc35.i686 libXi-1.7.10-7.fc35.i686 libXinerama-1.1.4-9.fc35.i686 libxkbcommon-1.3.1-1.fc35.i686 libxml2-2.9.13-1.fc35.i686 libXrandr-1.5.2-7.fc35.i686 libXrender-0.9.10-15.fc35.i686 libXScrnSaver-1.2.3-9.fc35.i686 libxshmfence-1.3-9.fc35.i686 libXtst-1.2.3-15.fc35.i686 libXxf86vm-1.1.4-17.fc35.i686 libzstd-1.5.2-1.fc35.i686 lilv-0.24.10-4.fc35.i686 llvm-libs-13.0.0-4.fc35.i686 lz4-libs-1.9.3-3.fc35.i686 mesa-dri-drivers-21.3.7-1.fc35.i686 mesa-filesystem-21.3.7-1.fc35.i686 mesa-libGL-21.3.7-1.fc35.i686 mesa-libglapi-21.3.7-1.fc35.i686 mesa-vulkan-drivers-21.3.7-1.fc35.i686 ncurses-libs-6.2-8.20210508.fc35.i686 nettle-3.7.3-2.fc35.i686 nspr-4.32.0-5.fc35.i686 nss-3.75.0-1.fc35.i686 nss-softokn-3.75.0-1.fc35.i686 nss-softokn-freebl-3.75.0-1.fc35.i686 nss-util-3.75.0-1.fc35.i686 openldap-2.4.59-3.fc35.i686 openssl-libs-1.1.1l-2.fc35.i686 openssl-pkcs11-0.4.11-4.fc35.i686 opus-1.3.1-9.fc35.i686 p11-kit-0.23.22-4.fc35.i686 pango-1.50.4-1.fc35.i686 pcre2-10.39-1.fc35.i686 pcre-8.45-1.fc35.i686 pipewire-0.3.48-1.fc35.i686 pipewire-alsa-0.3.48-1.fc35.i686 pipewire-debuginfo-0.3.48-1.fc35.i686 pipewire-debugsource-0.3.48-1.fc35.i686 pipewire-libs-0.3.48-1.fc35.i686 pixman-0.40.0-4.fc35.i686 pulseaudio-libs-15.0-2.fc35.i686 rest-0.8.1-10.fc35.i686 serd-0.30.10-3.fc35.i686 sord-0.16.8-2.fc35.i686 sqlite-libs-3.36.0-3.fc35.i686 sratom-0.6.6-3.fc35.i686 steam-1.0.0.74-2.fc35.i686 steam-devices-1.0.0.74-2.fc35.i686 systemd-libs-249.9-1.fc35.i686 vulkan-loader-1.2.189.0-1.fc35.i686 webrtc-audio-processing-0.3.1-7.fc35.i686 xz-libs-5.2.5-7.fc35.i686 zlib-1.2.11-30.fc35.i686
I know for a fact you need at least a few i686 packages to run games on Lutris as well (Blizzard Agent/Overwatch being one)
On 3/23/22 08:03, Germano Massullo wrote:
All these are somehow related to Steam and x86 32 bit games
# rpm -qa | grep 686 | sort alsa-lib-1.2.6.1-3.fc35.i686 atk-2.36.0-4.fc35.i686 at-spi2-atk-2.38.0-3.fc35.i686 at-spi2-atk-debuginfo-2.38.0-3.fc35.i686 at-spi2-atk-debugsource-2.38.0-3.fc35.i686 at-spi2-core-2.42.0-1.fc35.i686 avahi-libs-0.8-14.fc35.i686 bluez-libs-5.63-1.fc35.i686 bzip2-libs-1.0.8-9.fc35.i686 cairo-1.17.4-4.fc35.i686 cairo-gobject-1.17.4-4.fc35.i686 colord-libs-1.4.5-3.fc35.i686 cups-libs-2.3.3op2-16.fc35.i686 cyrus-sasl-lib-2.1.27-14.fc35.i686 dbus-libs-1.12.22-1.fc35.i686 dconf-0.40.0-5.fc35.i686 elfutils-debuginfod-client-0.186-1.fc35.i686 elfutils-libelf-0.186-1.fc35.i686 elfutils-libs-0.186-1.fc35.i686 expat-2.4.4-1.fc35.i686 fdk-aac-free-2.0.0-7.fc35.i686 flac-libs-1.3.4-1.fc35.i686 fontconfig-2.13.94-5.fc35.i686 freetype-2.11.0-3.fc35.i686 fribidi-1.0.10-5.fc35.i686 gamemode-1.6-3.fc35.i686 gdbm-libs-1.22-1.fc35.i686 gdk-pixbuf2-2.42.6-2.fc35.i686 gdk-pixbuf2-modules-2.42.6-2.fc35.i686 glib2-2.70.5-1.fc35.i686 glibc-2.34-29.fc35.i686 glibc-gconv-extra-2.34-29.fc35.i686 glib-networking-2.70.1-1.fc35.i686 gmp-6.2.0-7.fc35.i686 gnutls-3.7.2-3.fc35.i686 graphite2-1.3.14-8.fc35.i686 gsm-1.0.19-6.fc35.i686 gstreamer1-1.20.0-1.fc35.i686 gtk2-2.24.33-5.fc35.i686 gtk3-3.24.31-2.fc35.i686 harfbuzz-2.9.1-1.fc35.i686 inih-49-4.fc35.i686 jasper-libs-2.0.33-1.fc35.i686 jbigkit-libs-2.1-22.fc35.i686 json-glib-1.6.6-1.fc35.i686 keyutils-libs-1.6.1-3.fc35.i686 krb5-libs-1.19.2-2.fc35.i686 lcms2-2.12-2.fc35.i686 libasyncns-0.8-21.fc35.i686 libatomic-11.2.1-9.fc35.i686 libblkid-2.37.4-1.fc35.i686 libbrotli-1.0.9-6.fc35.i686 libcanberra-0.30-27.fc35.i686 libcanberra-gtk2-0.30-27.fc35.i686 libcanberra-gtk3-0.30-27.fc35.i686 libcap-2.48-3.fc35.i686 libcloudproviders-0.3.1-4.fc35.i686 libcom_err-1.46.3-1.fc35.i686 libcurl-7.79.1-1.fc35.i686 libdatrie-0.2.13-2.fc35.i686 libdb-5.3.28-50.fc35.i686 libdbusmenu-16.04.0-18.fc35.i686 libdbusmenu-gtk3-16.04.0-18.fc35.i686 libdrm-2.4.110-1.fc35.i686 libedit-3.1-40.20210910cvs.fc35.i686 libepoxy-1.5.9-1.fc35.i686 libevent-2.1.12-4.fc35.i686 libffi-3.1-29.fc35.i686 libgcc-11.2.1-9.fc35.i686 libgcrypt-1.9.4-1.fc35.i686 libglvnd-1.3.4-2.fc35.i686 libglvnd-glx-1.3.4-2.fc35.i686 libgpg-error-1.43-1.fc35.i686 libgusb-0.3.9-1.fc35.i686 libICE-1.0.10-7.fc35.i686 libicu-69.1-2.fc35.i686 libidn2-2.3.2-3.fc35.i686 libjpeg-turbo-2.1.0-3.fc35.i686 libldac-2.0.2.3-9.fc35.i686 libmodman-2.0.1-25.fc35.i686 libmount-2.37.4-1.fc35.i686 libnghttp2-1.45.1-1.fc35.i686 libnsl-2.34-29.fc35.i686 libogg-1.3.5-2.fc35.i686 libpciaccess-0.16-5.fc35.i686 libpng12-1.2.57-14.fc35.i686 libpng-1.6.37-11.fc35.i686 libproxy-0.4.17-3.fc35.i686 libpsl-0.21.1-4.fc35.i686 libsbc-1.5-2.fc35.i686 libselinux-3.3-1.fc35.i686 libsepol-3.3-2.fc35.i686 libSM-1.2.3-9.fc35.i686 libsndfile-1.0.31-6.fc35.i686 libsoup-2.74.2-1.fc35.i686 libssh-0.9.6-1.fc35.i686 libstdc++-11.2.1-9.fc35.i686 libstemmer-0-17.585svn.fc35.i686 libtasn1-4.16.0-6.fc35.i686 libtdb-1.4.4-3.fc35.i686 libthai-0.1.28-7.fc35.i686 libtiff-4.3.0-4.fc35.i686 libtool-ltdl-2.4.6-50.fc35.i686 libtracker-sparql-3.2.1-1.fc35.i686 libunistring-0.9.10-14.fc35.i686 libunwind-1.5.0-1.fc35.i686 libusb1-1.0.24-4.fc35.i686 libuuid-2.37.4-1.fc35.i686 libva-2.13.0-3.fc35.i686 libvdpau-1.5-1.fc35.i686 libverto-0.3.2-2.fc35.i686 libvorbis-1.3.7-4.fc35.i686 libwayland-client-1.20.0-1.fc35.i686 libwayland-cursor-1.20.0-1.fc35.i686 libwayland-egl-1.20.0-1.fc35.i686 libwebp-1.2.2-1.fc35.i686 libX11-1.7.3.1-1.fc35.i686 libX11-xcb-1.7.3.1-1.fc35.i686 libXau-1.0.9-7.fc35.i686 libxcb-1.13.1-8.fc35.i686 libXcomposite-0.4.5-6.fc35.i686 libxcrypt-4.4.28-1.fc35.i686 libxcrypt-compat-4.4.28-1.fc35.i686 libXcursor-1.2.0-6.fc35.i686 libXdamage-1.1.5-6.fc35.i686 libXext-1.3.4-7.fc35.i686 libXfixes-6.0.0-2.fc35.i686 libXft-2.3.3-7.fc35.i686 libXi-1.7.10-7.fc35.i686 libXinerama-1.1.4-9.fc35.i686 libxkbcommon-1.3.1-1.fc35.i686 libxml2-2.9.13-1.fc35.i686 libXrandr-1.5.2-7.fc35.i686 libXrender-0.9.10-15.fc35.i686 libXScrnSaver-1.2.3-9.fc35.i686 libxshmfence-1.3-9.fc35.i686 libXtst-1.2.3-15.fc35.i686 libXxf86vm-1.1.4-17.fc35.i686 libzstd-1.5.2-1.fc35.i686 lilv-0.24.10-4.fc35.i686 llvm-libs-13.0.0-4.fc35.i686 lz4-libs-1.9.3-3.fc35.i686 mesa-dri-drivers-21.3.7-1.fc35.i686 mesa-filesystem-21.3.7-1.fc35.i686 mesa-libGL-21.3.7-1.fc35.i686 mesa-libglapi-21.3.7-1.fc35.i686 mesa-vulkan-drivers-21.3.7-1.fc35.i686 ncurses-libs-6.2-8.20210508.fc35.i686 nettle-3.7.3-2.fc35.i686 nspr-4.32.0-5.fc35.i686 nss-3.75.0-1.fc35.i686 nss-softokn-3.75.0-1.fc35.i686 nss-softokn-freebl-3.75.0-1.fc35.i686 nss-util-3.75.0-1.fc35.i686 openldap-2.4.59-3.fc35.i686 openssl-libs-1.1.1l-2.fc35.i686 openssl-pkcs11-0.4.11-4.fc35.i686 opus-1.3.1-9.fc35.i686 p11-kit-0.23.22-4.fc35.i686 pango-1.50.4-1.fc35.i686 pcre2-10.39-1.fc35.i686 pcre-8.45-1.fc35.i686 pipewire-0.3.48-1.fc35.i686 pipewire-alsa-0.3.48-1.fc35.i686 pipewire-debuginfo-0.3.48-1.fc35.i686 pipewire-debugsource-0.3.48-1.fc35.i686 pipewire-libs-0.3.48-1.fc35.i686 pixman-0.40.0-4.fc35.i686 pulseaudio-libs-15.0-2.fc35.i686 rest-0.8.1-10.fc35.i686 serd-0.30.10-3.fc35.i686 sord-0.16.8-2.fc35.i686 sqlite-libs-3.36.0-3.fc35.i686 sratom-0.6.6-3.fc35.i686 steam-1.0.0.74-2.fc35.i686 steam-devices-1.0.0.74-2.fc35.i686 systemd-libs-249.9-1.fc35.i686 vulkan-loader-1.2.189.0-1.fc35.i686 webrtc-audio-processing-0.3.1-7.fc35.i686 xz-libs-5.2.5-7.fc35.i686 zlib-1.2.11-30.fc35.i686
devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-leave@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
Hello,
I didn't think I needed i386 personally. In fact due to this thread I removed many i386 packages left on my machine. Just today I plugged in an 'IronKey' device. Its an encrypted USB drive. When plugged in a read only like mount is mounted, like a CD. On it is a binary to unlock the device. It no longer works, I get an "unable to execute ./ironkey: No such file or directory" likely because I'm now missing the i386 libraries or other requirements.
Sincerely,
One more update.
On Wed, 2022-04-06 at 16:24 +0000, Nathanael Noblet wrote:
Hello,
I didn't think I needed i386 personally. In fact due to this thread I removed many i386 packages left on my machine. Just today I plugged in an 'IronKey' device. Its an encrypted USB drive. When plugged in a read only like mount is mounted, like a CD. On it is a binary to unlock the device. It no longer works, I get an "unable to execute ./ironkey: No such file or directory" likely because I'm now missing the i386 libraries or other requirements.
Looks like I need glibc.i686 (and it installed glibc-gconv-extra.i686, libgcc.i686) for this ironkey device.
Sincerely,
It seems like my needs are pretty common: Steam, Wine, misc games (OpenGL, SDL, maybe vulkan, XWayland).