8:54 a.m.
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(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
9:04 a.m.
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.
--
Tomasz Torcz “God, root, what's the difference?”
tomek(a)pipebreaker.pl “God is more forgiving.”
9:15 a.m.
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 :(
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4:29 p.m.
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
9:16 a.m.
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-...
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
9:24 a.m.
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
10:17 a.m.
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.
11:34 a.m.
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.
9:35 a.m.
David Cantrell <dcantrell(a)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
6:27 p.m.
On 3/16/22 10:35, Robbie Harwood wrote:
David Cantrell <dcantrell(a)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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
4:07 a.m.
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(a)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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
4:10 a.m.
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 Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
5:10 a.m.
* 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
5:24 a.m.
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
6:17 a.m.
On Thu, Mar 17, 2022 at 6:25 AM Richard W.M. Jones <rjones(a)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)
--
真実はいつも一つ！/ Always, there's only one truth!
8:39 a.m.
On Thu, Mar 17, 2022 at 6:25 AM Richard W.M. Jones <rjones(a)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
4:37 a.m.
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(a)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-...
https://gitlab.com/libvirt/libvirt/-/blob/master/ci/containers/debian-11-...
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
5:11 a.m.
* 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
8:26 a.m.
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
10:01 a.m.
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.
10:02 a.m.
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.
10:53 a.m.
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
11:54 a.m.
On Wed, Mar 16, 2022 at 11:55 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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
12:36 p.m.
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(a)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
1:11 p.m.
On Wed, Mar 16, 2022 at 1:37 PM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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(a)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
5:20 p.m.
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(a)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(a)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
11:52 a.m.
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(a)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(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
12:17 p.m.
On Wed, Mar 16, 2022 at 8:54 AM David Cantrell <dcantrell(a)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.
9:33 p.m.
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
9:35 p.m.
On Wed, Mar 16, 2022 at 9:34 PM laolux laolux via devel <
devel(a)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
4:05 a.m.
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
4:49 a.m.
Hi,
I use wine and steam (and some libraries which are required to run them) with total of 254
i686 packages.
Matyáš
5:22 a.m.
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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
9:58 a.m.
The i686 packages I use are: gamemode, gperftools-devel (to provide a working version of
libtcmalloc_minimal), SDL2, steam, and their dependencies.
10:11 a.m.
I use wine and would need 32bit gstreamer; base, good, bad, ugly and libav for some Visual
Novels that use MPEG for video.
11:14 a.m.
On Wed, 16 Mar 2022 at 13:55, David Cantrell <dcantrell(a)redhat.com> wrote:
If you use i686 packages for something now, please respond to this thread.
steam / wine
--
"Never, never, in nothing great or small, large or petty, never give in
except to convictions of honour and good sense. Never yield to force; never
yield to the apparently overwhelming might of the enemy.''
Winston Churchill
https://stackoverflow.com/users/3670118/casep
3:10 a.m.
On 3/17/22 18:14, Carlos "casep" Sepulveda wrote:
On Wed, 16 Mar 2022 at 13:55, David Cantrell <dcantrell(a)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 -
7:30 p.m.
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.
3:38 a.m.
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
6:38 a.m.
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
12:56 p.m.
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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
6:57 p.m.
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
1:02 a.m.
Hi,
On Tue, 22 Mar 2022 00:57 +0100
Kevin Kofler via devel <devel(a)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
10:47 a.m.
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
7:54 p.m.
On Wed, Mar 16, 2022 at 9:54 AM David Cantrell <dcantrell(a)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.
4:19 a.m.
On Wed, Mar 16, 2022 at 2:56 PM David Cantrell <dcantrell(a)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.
8:01 a.m.
On Wed, Mar 16, 2022 at 9:54 AM David Cantrell <dcantrell(a)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)
--
真実はいつも一つ！/ Always, there's only one truth!
2:33 p.m.
Hi,
On Wed, 16 Mar 2022 09:54:12 -0400
David Cantrell <dcantrell(a)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
6:58 p.m.
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
7:03 a.m.
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
8:19 a.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email todevel-leave(a)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.fedora...
Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
11:24 a.m.
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,
--
Nathanael
11:29 a.m.
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,
--
Nathanael
10:46 p.m.
It seems like my needs are pretty common: Steam, Wine, misc games (OpenGL, SDL, maybe
vulkan, XWayland).
464
days inactive
771
days old
59 comments
44 participants
participants (44)
-
Aaron Stern -
Adam Jackson -
Arthur Bols -
Artur Frenszek-Iwicki -
Carlos "casep" Sepulveda -
Dan Čermák -
Daniel P. Berrangé -
David Cantrell -
Demi Marie Obenour -
Dominik 'Rathann' Mierzejewski -
Felix Schwarz -
Florian Weimer -
Gerd Hoffmann -
Germano Massullo -
Jakub Jelinek -
Jeremy Newton -
John Reiser -
Jonathan Wakely -
Josh Boyer -
Justin Forbes -
Kamil Paral -
Kevin Kofler -
Koroglu, Ali Erdinc -
laolux laolux -
Marius Schwarz -
Matyáš Kroupa -
Mauricio Tavares -
Michal Schorm -
Miro Hrončok -
Nathanael D. Noblet -
Nathanael Noblet -
Neal Gompa -
Panu Matilainen -
Richard Shaw -
Richard W.M. Jones -
Robbie Harwood -
Steve Cossette -
Steven A. Falco -
Steven Ellis -
Stijn Hoop -
Tom Seewald -
Tomasz Torcz -
Vitaly Zaitsev -
Zbigniew Jędrzejewski-Szmek