Should i change to MX Linux? ---- Is archlinux32 dying?

arch322yes · 2020-12-12 19:41:09

Hello Users, hello developer,

schould i change to MX Linux i386?

In last time i have many trouble with archlinux32.
Only levi give support, other user, developers i don't see in this forum.

My archlinux amd64 works without problems.

Is archlinux32 dying?

Since 2017 i use archlinux32.

:-((

Greets

arch322yes

Last edited by arch322yes (2020-12-12 19:46:11)

deep42thought · 2020-12-12 20:36:21

Hi arch322yes,

well, there aren't many devs on arch32 - only me and andreasbaumann. levi is mostly active on the forums (big thanks!).

As you can imagine, this is not the only thing, I'm doing - so I'll sort my tasks w.r.t. my priorities: Things of arch32, that I need, will get fixed first (and even that may take a week or so - take a look at the latest python rebuild). Unfortunately for you, I'm not using firefox on arch32, so this is further to the end of things-to-be-fixed.

regards,
deep42thought

arch322yes · 2020-12-12 22:00:36

Thank you for your work.

abaumann · 2020-12-13 09:22:56

As deep42thought has said, we basically fix things we use personally. Firefox, Gnome, KDE are not things neither of us is using.

I might have some time left of Xmas holidays to do stuff, but currently not.

Firefox usually involves a complete bootstrapping of rust, so you easily spend several days just to get this up again.

On Archlinux32 dying: 32-bit IA32 software is dying. Distributors can not do all the coding and testing work original
authors should due if they truly still support IA32. And who pays developers and maintainers for keeping a dying
architecture alive?

Switching to other distros will only delay the situation, where you have the choice of either sticking to a release of
the software which was still supported or having to mainain the port yourself. For me it's quite logical Archlinux
hits the problems first, being on the bleeding edge.

egils · 2021-01-23 19:30:40

So what do you use? Could we remove all the failed packages or mark them unmaintained somehow?
Can I help somehow? I have some experience with building packages but no idea how to get involved.

abaumann · 2021-01-23 20:42:13

Patches are always welcome. :-)

The build system is a little bit tricky, as it involves formulating a diff-PKGBUILD to the orginal Archlinux PKGBUILD from upstream,
see for instance https://git.archlinux32.org/packages/tr … l/PKGBUILD

https://git.archlinux32.org/asp32/ is a nice little helper which works just as upstreams asp, but it also fetches the 32-bit specific
patches.

The there are https://git.archlinux32.org/devtools32/, which are a fork of the upstream devtools providing the build scripts like
'staging-pentium4-build'.

If more people send in patches (you can do it via mailing list or via mail), then I can also install gitea or something similar
on the buildmaster, so people can create pull request.

About disabling broken packages, first you have to know that they are broken, and then we usually try to fix them.
If fixing is not possible, they end up on a blacklist (https://git.archlinux32.org/packages/tree/blacklist) per architecture.
This information could be nicer presented on the packages overview page ( https://www.archlinux32.org/packages/)
as an idea.

As for testing: we gave up (or better never started) with automatic testing, we use a bunch of old machines to install and
update Archlinux32 installations, also some VMs.

abaumann · 2021-01-23 20:46:40

About other 32-bit distros:
- Slackware
- Debian
- Voidlinux

or see this list https://itsfoss.com/32-bit-os-list/

The problem is: if upstream authors drop an architecture, then you have to maintain a bunch of code on your own, sooner
or later any Linux distribution will stop to support 32-bit Intel or will freeze at a certain version.

Maybe the BSDs will last longer on 32-bit, who knows (but most likely only the core, not the 'ports')?

levi · 2021-01-23 22:16:50

That's true, but most authors deliver a clump of source code, which has fair to evens chance of running on anything turing complete with enough RAM, even if they only actually test it on their modern supercomputer. The problem comes when people rewrite bits of source code using embedded assembler I assume, which used to be a common tactic in coding old 8- and 16-bit computers where there were thousands or tens of thousands of more of less identical machines around the world, and has seen a resurgence in more recent times thanks to the rise in ARM based phones and things; I understand that for a while now the only way you got NEON coprocessor opcodes out of GCC was for you to drop to assembler and code them in yourself.

cx · 2021-01-26 14:47:19

If one must leave Arch under any circumstances but needs up-to-date software on an old machine Gentoo is also worth a try! [ Wikipedia ] · [ Gentoo's Handbook:X86 ]

Sure it's more DIY in a way, but if you're a bit familiar with Linux and Arch, and know what you're looking for, the learning curve is not that steep. Much is pretty similar, and some topics might be a bit more detailed though, since all stuff is being compiled from source, while Arch's official packages are precompiled; at first sight think about dealing with AURBUILDs – (very) roughly speaking. So for enjoying the benefits of a tailored Gentoo system it's quite advantageous to know the specs of your machine better (especially the processor flags, just as it is here)! But once the base is set up and you've become used to portage, you're in!

Ages ago Gentoo had been my favorite distro for a year or so, before I fell in love with Arch. So I already knew that a bit, when 32-Bit support on Arch had ended, and I first installed it on my pentium4. Yet my second installation from scratch (aka "stage1") went fine – until my graphics drivers for whatever reason ran into dep circles with weird audio stuff, and I couldn't proceed. – Later on for heaven's sake Arch32 came back from the crypt!

Gentoo is another great distro along with its helpful community, and you can also make and have everything you do in Arch – if not more regarding all its potentially supported architectures. Yet I don't mean one is superior to the other – I just like the Arch way better, and prefer to have it for both 64 and 32 bit!

levi · 2021-01-26 21:14:16

I suspect that if I did move to Gentoo, I'd have to give up using a full featured web browser. I use firefox because I can then tie it down using ublock origin. I guess I could switch to netsurf and ensure any experimental javascript is turned off, and still visit and post here and another forum I visit, but it would stop me managing my money and a few other things I do.

mistersmee · 2021-01-27 12:26:34

Yeah, that is precisely why I'm hesitant to switch to Gentoo anywhere, whether it be on this 32-bit machine, or any 64-bit machines.
People call Arch "timesink OS", but I feel Gentoo is more appropriate for that. Compiling any web browser, or anything massive like that will take a day minimum, every time they get an update. Which is not something I wish to do. Gentoo does have a binary for firefox in their repos, though I don't know if it is 64-bit and 32-bit. And most of the USE flags are disabled on that binary build, which kinda defeats the whole purpose of running Gentoo.

Bob Hill · 2021-02-10 09:30:55

FWIW, as well as Debian/Slackware/Voidlinux/etc/etc, openSUSE's rolling release "Tumbleweed" still seems to provide 32-bit builds.

I still use 32-bit hardware, and have been happily using Arch Linux for nearly eight years, so I really hope Arch Linux 32 keeps going!

mrfu · 2021-02-17 13:03:26

Thumbs up, you are doin great work. Hope you keep on beeing as solid as a rock.
I know, its hard to keep pace with development and I am luckily participating at your efforts.

Left manjaro32 behind. Had been a one man show, but great work too. Sadly the manjaro team announced the ultimate drop of 32bit support in the manjaro32 forum just two days before shutting down the servers. They did two weeks earlier in the manjaro forum. They really do great work there, including the concentration on evolving arm platforms. Communication about that matter had been a mess.

I really hope you two maintainers keep on track. It's hard and sometimes boring work to be done. Only thing I want to mark here is ... there are a lot of packages still relying on python 3.8

In archlinux I do like the possibility of 'freezing' the system to a certain state. So I keep the latest state, when all dependencies to python 3.8 are satisfied (2020/12/12).

All in all, thumbs up again for your great work and effort, hoping archlinux32 is not going the long paved way of anihilation of 32bit platforms in personal computing.

I think there are a lot of enthusiasts and people that don't like landfills that could help you in your effort to keep great archlinux for 32bit alive.

Don't like to switch systems and/or hardware that soon again . Archlinux32 rocks

archlinux32 - pentium4 - i3wm (since 2020/04/16 - before manjaro32 since 2017/11/17)
acer travelmate 290 from 2003 (formerly driven by XP)

levi · 2021-02-17 16:10:26

For the forseeable the kernel seems to continue to work without problems in older computers. Bash recently fell over on things identifying as < pentium4, because it depends on glibc. Maybe I should install tcsh as well, in case glibc starts rejecting my machines soon. tcsh claims to only depend on ncurses.

But if we stick on an old version we need to start to become more aware of the identifcation of security issues in these older versions of things, and either patch and release those or change our behavior to mitigate them. To be honest, if we're going to stick with old versions we may as well be using debian and perhaps rebuilding certain components ourselves for performance gains, even though the only guarantees debian makes about their i386 branch is that it'll run on the last ever produced 32-bit only chip.

These days you can buy a second hand computer that's perfectly good at running 64-bit opcodes. I'll have to retire this hunker one of these days, just not quite yet.

abaumann · 2021-02-17 16:58:34

@levi: concerning ISA levels and bash, if you had that it was a glitch with glibc. You still have it?

@mrfu: my NAS, my travel eeepc are still 32-bit and used on a daily basis, so I need Archlinux32.
about freezing, I'm not sure we can do this in the current build system. We try to stick to upstream
and fix the errors as they pop up (preferably in testing :-) ).

Concerning security: we rely 100% on upstream and we most likely only add security holes
(like when we have to disable libseccomp support because nobody cares to adapt it for
32-bit Intel).

levi · 2021-02-17 18:19:59

The glibc glitch didn't affect me since my machine supports SSE2. I'm just concerned that if they require that now, sooner or later they'll require SSE4 or something newer that I don't have.

mrfu · 2021-02-20 12:32:18

@ levi #14, @ abauman #15:

I know about the 'Sysiphus' work of beeing on par with upstream. Some packages I tried to compile by myself. It had been too time consuming for me and I don't have the infrastructure and programming knowledge to keep on track by myself. So I took a 'rest' on the 12 of Dezember last year.

I will be on rolling again, when the switch to python 3.9 or icu is made in every of my installed packages. I really appreciate the intermediate provisioning of icu67.

To be honest, in my garage there are some more modern 64bit machines waiting for a ride. Only thing, they are not running linux right now and/or need some minor fixes. Driving my elderly TravelMate is like driving an VW Beetle - it's running and running and running..... even on the Autobahn of modern internet . If I will change my workhorse some time in the next future, this one surely will not go it's way to the landfill or dusting in the attik.

'Merci vielmals' to you for doing great work

mrfu · 2021-02-20 12:45:49

Dear admins and hello again

would you please kindly update the last 45 remaining packages that are still on python 3.8

pacman -Fx 'usr/lib/python3.8' | awk -F" " '{ print $4"-"$5 }' | sort -u > still_python38

community/buildbot-2.5.1-2.0
community/calibre-python3-4.23.0-2.0
community/glom-1.32.0-2.1
community/gnuradio-fcdproplus-3.8.0-5.0
community/gnuradio-iqbal-0.38.1-1.0
community/gnuradio-osmosdr-0.2.0-4.0
community/gst-editing-services-1.16.2-1.0
community/gwakeonlan-0.7.0-1.0
community/hid-tools-0.2-5.0
community/libopenshot-0.2.5-3.0
community/mayavi-4.7.1-3.0
community/mopidy-3.0.2-2.0
community/opendht-1:1.10.1-7.0
community/python-aubio-0.4.9-7.5
community/python-brotlipy-0.7.0-6.1
community/python-build-0.1.0-1.0
community/python-jedi-0.17.2-1.0
community/python-libevdev-0.9-2.0
community/python-orjson-3.0.0-1.0
community/python-pyadi-iio-0.0.4-1.0
community/python-redbaron-0.9.2-3.1
community/python-sphinx-furo-2020.10.15.beta13-1.0
community/python-sphinx_rtd_theme-0.4.3-4.0
community/python-uproot-3.12.0-1.0
community/python-uproot-methods-0.7.4-1.0
community/qpid-proton-0.31.0-1.0
community/qtile-0.16.1-1.0
community/sssd-2.3.1-1.0
community/tpm2-pkcs11-1.5.0-3.0
community/uwsgi-plugin-python-2.0.18-7.0
community/vtk-8.2.0-17.0
extra/389-ds-base-1.4.4.1-1.0
extra/abiword-3.0.4-3.0
extra/bind-tools-9.16.5-1.0
extra/brltty-6.0-11.0
extra/gnome-builder-3.38.1-3.0
extra/libibus-1.5.23+1+gdd4cc5b0-1.0
extra/link-grammar-5.8.0-3.0
extra/opencv-4.3.0-4.0
extra/python-mlt-6.18.0-3.0
extra/python-protobuf-3.12.4-1.0
extra/python-virtualenv-20.1.0-1.0
extra/python-xdg-0.26-4.1
extra/python-zbar-0.23.1-1.0
extra/zbar-0.23.1-5.0

Thank you in advance

levi · 2021-02-20 14:03:31

Blimey, do you have *everything* installed? I can concur that jedi looks old. Some of the others look to be newer in testing, but I can't tell you whether they're new enough since I do not have a reason to have them installed.

abaumann · 2021-02-20 15:15:26

Yep, will do. The problem is neither build slaves nor triggering rebuilding, it's lack of hands..

I'm counting 1760 still_python38 on i686 and 1758 still_python38 on pentium4.

The problem is manifold. I see some rare caes like
Dec 6 2019 pool/python-nautilus-1.2.3-3.1-pentium4
(sort of the metusalix of packages)
Those are packages which most likely no longer build.

Most packages have timestamps around the begining of December.

extra/python-protobuf-3.12.4-1.0 has a problem upstream
(https://bugs.archlinux32.org/index.php?do=details&task_id=158&status[0]=)
those need fixing upstream.

sphinx is heavily broken (also due to schemes not "yarning"), this breaks
building documentation in quite some places.

Then there can be cirular dependencies which have to be broken manually.

Still, the count from my test servers seems a little bit high..?

And then there manypackages hang around in testing because of dependency issues
and just have not been published to stable yet..

abaumann · 2021-02-20 15:39:26

As I feared, those packages fail for a reason, for instance buildbot: https://bugs.archlinux32.org/index.php? … ask_id=161

mrfu · 2021-02-21 01:19:23

@levi: This evening I tested my archlinux32 installation again on a seperate drive. To be honest, I only found four packages from official repos installed on my system which lack python 3.9 support:

extra/brltty-6.0-11.0
extra/libibus-1.5.23+1+gdd4cc5b0-1.0
extra/python-virtualenv-20.1.0-1.0
extra/zbar-0.23.1-5.0

Seems to be minor effort -> then I'm happy rolling again

gameslayer · 2021-12-14 09:06:47

arch322yes wrote:

Hello Users, hello developer,
schould i change to MX Linux i386?
In last time i have many trouble with archlinux32.
Only levi give support, other user, developers i don't see in this forum.
My archlinux amd64 works without problems.
Is archlinux32 dying?
Since 2017 i use archlinux32.
:-((
Greets
arch322yes

As someone who has tried MX Linux I would say just don't, it's a bloated OS full of a lot of unnecessary customization's and software that just make it feel all over the place and managing software being a annoyance especially with the graphical software being a little confusing also using a mix of the repo options, flatpak and I think snap not to mention just missing software. It's much simpler on Arch with all the software you need all there either on the repo or AUR.

Last edited by gameslayer (2024-02-01 14:52:27)

Arch Linux

#1 2020-12-12 19:41:09

Should i change to MX Linux? ---- Is archlinux32 dying?

#2 2020-12-12 20:36:21

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#3 2020-12-12 22:00:36

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#4 2020-12-13 09:22:56

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#5 2021-01-23 19:30:40

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#6 2021-01-23 20:42:13

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#7 2021-01-23 20:46:40

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#8 2021-01-23 22:16:50

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#9 2021-01-26 14:47:19

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#10 2021-01-26 21:14:16

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#11 2021-01-27 12:26:34

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#12 2021-02-10 09:30:55

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#13 2021-02-17 13:03:26

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#14 2021-02-17 16:10:26

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#15 2021-02-17 16:58:34

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#16 2021-02-17 18:19:59

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#17 2021-02-20 12:32:18

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#18 2021-02-20 12:45:49

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#19 2021-02-20 14:03:31

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#20 2021-02-20 15:15:26

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#21 2021-02-20 15:39:26

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#22 2021-02-21 01:19:23

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

#23 2021-12-14 09:06:47

Re: Should i change to MX Linux? ---- Is archlinux32 dying?

Board footer