I finally figured out how to successfully compile the 32bit version of Chromium (and its un-Googled sibling) on Slackware, now that this requires the Rust compiler to build it. Pat added the final bits that I needed to the rust.SlackBuild script in Slackware recently.
Why did it take so long? Basically ‘real life’ intervened and I did not have time left to investigate.
I assume there may be one or two users left who use my 32bit Chromium package, the rest of you simply don’t care whether I can produce these 32bit packages or not. No one reached out and asked, can I help?
Prime example of slackers, right? It is what it is, and I respect that, and honestly I understand; there’s no fun in having to deal with all these Chromium developer assumptions that everyone uses Ubuntu. Kudos to the Ungoogled-chromium team however – they have been really helpful whenever I got stuck.
The bottom-line is, that I will resume my builds of a 32bit version of Ungoogled Chromium, once per month, for Slackware 15.0 and -current, until the process breaks again and then it’s goodbye to 32bit Ungoogled Chromium.
In any case, there will not be further 32bit packages for the regular Chromium browser going forward. I will remove the existing 32bit chromium packages from my repository because I want to prevent people downloading a vulnerable browser.
Eric
Update – I have uploaded 32bit packages:
+--------------------------+ Mon Aug 12 20:13:12 UTC 2024 chromium-ungoogled: updated 32bit to 127.0.6533.99 (Slackware 15.0 & onwards). If your browser keeps crashing with seccomp errors, add this as startup parameter: "--disable-seccomp-filter-sandbox". For reference: https://alien.slackbook.org/blog/chromium-90-packages-again-32bit-related-issues/
>…Why did it take so long? Basically ‘real life’ intervened
I think you may qualify for one of the cloning trials. I’ll send you the link so you can sign up, as soon as I remember what it was.
This worked for me before retirement: Write down everything you need to get done today; go back and prioritize each one, put a number 1-10 next to each item; make a new list in order of priority; focus 100% on the item at the top of the list until you finish the task; then do the same for the next item on the list. Writing stuff down lets you analyze with detachment, instead of juggling everything in your head. There is no such thing as multi-tasking. This is a technique for success. Try it for just one day.
> There is no such thing as multi-tasking.
Clearly, you’ve never worked in a restaurant kitchen.
>…Writing stuff down lets you analyze with detachment, instead of juggling everything in your head. There is no such thing as multi-tasking. This is a technique for success. Try it for just one day.
I think this is kind of uncalled for, Henry, especially if you cared to take notice of what actually happened in Eric’s life.
Eric, your effort is appreciated, it really is.
I’d have jumped in to help if
1. I was any good at these things
2. If I had 32bit Slackware installed
3. If I ever used Chromium, with or without googly bits
My backup server still runs 12.2 – it just works!
I’ve been 64-bit or multilib for some time, but it sounds like there’s still a few quiet people on 32-bit.
Anyway, your efforts are very much appreciated. I’ve never tried building chromium. obs-studio’s about as complicated as I’ve done.
Nice work Eric. Be well !
thanks for your work on chromium (and libreoffice and vlc). I tend to download both bit versions just for completeness, even if I don’t currently have a 32bit slackware (outside of a vm for slackbuilds). I guess it is just for those old 486/pentium legacy type machines that someone might have, or running a vps, where 32bit binaries are smaller so use less disk space. (which i did until this year). At least with syswow64 added to wine, there isn’t the need of pure 32bit, or multilib for running 32bit windows executables on linux.
Hi Eric firstly thank you for your work on chromium vlc ffmpeg and your repo of packages you make available. Only last night you saved me several hours compile time when I used your wxGTK3-3.2.1-x86_64-1alien.txz package to be able to build a package. That looks like I’ll only use a couple of times to edit and edid binary.
I have a question for you relating to the addition of -march=x86-64 -mtune= generic, am I right in assuming that I could also use bdver1 with the flag
-mtune=. bdver1 is in the option’s listed along with generic in the GCC documentation for x86-64 optimizations. I was just not completly sure if it would work in slackware does it need including in the aaa_glibc-solibs packages or now that the -march=x86-64 is included the range of option’s for -mtune= can be used.
Any info advice much appreciated.
Sam aka UrbanMusic
bdver1 sets tune for amd FX bulldozer version 1 cpu’s.
My builds follow Slackware’s conventions for CFLAGS, so I can not give you any advice on custom rebuilds. Best is to ask in a #gcc forum probably.
Well, Eric, I’m using the *regular* 32bit version, and plan to do for the forseeable future. I’ve even managed to get a process going to create my own source packages for up to 120 LTS (to stay on the safe side) and succeeded quite some time ago, so I’m currently running on the resulting .319 that I’ve also compiled on my own (was into adapting it for past-Rust-mandatory versions, but only before solving the same problems with llvm and Rust as you had). Even dwelved deep into revamping SlackBuilds for llvm myself in my attempt to be helpful with solving the 32bit compiler puzzle (Rust put aside), but had to cease my efforts for the time being since, similarly like in your case, real life kicked in – broken drainpipe & wet walls, ISP giving me discharge after it changed hands, etc.. In a pinch things that wont wait and there was (and in fact, unfortunately, still is) no time left.
So please do not think that that if noone has publicly jumped in means that actually there *isnt* one who would be willing to help, or that the 32bit user base is zero; it is simply not true; in my close vicinity I know of 2 other Chromium Slackware users.
I personally wish you’d continue to provide ordinary 32bit builds or at least verify that your 32bit SlackBuild process works (which I hope will still do if I choose to build myself without -ungoogled patches applied).
If permitted by you, I could even put my ordinary (non-ungoogled) 32bit LTS builds of regular chromium (based on your SlackBuild) for download somewhere, should anyone want to use these as me.
Btw, to date, the M120 32bit chromium version (running as ordinary user) appears to have all sandbox-related problems fixed, according to my experience.
-cal
The same SlackBuild script creates the chromium and the chromium-ungoogled packages, it’s a matter of setting “USE_UNGOOGLED” variable to “0” or “1”. The regular 32bit package builds and runs successfully.
Thanks for sharing with me that you are still running this 32bit version of the browser.
On Slackware 15.0 I do not see the seccomp related crashes, but on -current I do.
Very nice. Thanks a lot! I help out at an NGO where we sometimes have older PCs we want to use and 32bit definitely isnt dead yet 🙂
Your contributions to Slackware have been invaluable and you are among the most respected members of the community. Thank you for all these years of hard work, which undoubtedly, took a lot from your free time.
However, this left me puzzled:
> No one reached out and asked, can I help?
> Prime example of slackers, right?
Are we supposed to feel guilty?
best,
Petar
If you are on 64bit Slackware and never used a 32bit Chromium, the case is irrelevant really. You can ignore my rant.
The message I sent in this post, was:
You don’t have to feel guilty for slacking, but then also you should not complain once I stop building 32bit Chromium packages.
Since nobody came knocking during the period of not providing 32bit packages, I concluded that nobody cares whether I provide these packages or not. Resulting in a simple matter of priority setting.
Hi Eric.
Just to thank you for your time and effort to support a smal number of users of this 32bit version chrome.
I appreciate it.
Regards. Francisco