Deprecation of i686 based systems

[supechicken]

Overview

The last official release of i686 Chrome OS (excluding CloudReady) was released in 2017 (5 years ago). That means the lack of security patches and an older system base, which makes it more and more unreliable in daily use.

Currently, some online features (like extension store and Chrome history syncing) on these systems are no longer working, even some of the Chromebrew applications are broken due to a lack of tests.

Although there are not many efforts required for us to maintain existing i686 packages, there are very very few users (or nobody) using crew on those platforms or even the OS itself (which means our efforts are meaningless)

So this might be a perfect time to say goodbye :)

Timeline

Note

All plans below have been put on hold, everything remains currently.

However, please notice that the support of i686 might be dropped soon.

• Now: No changes
• 01/2023: New packages will not provide prebuilt binary for i686 (can still build from source)
• 02/2023: Disable i686 compatibility for sommelier and all X11 applications.
• 05/2023: New updates will not provide prebuilt binary for i686 (except core packages/compilers) (can still build from source)
• 09/2023: Stop providing prebuilt binary for i686 on all packages (existing binaries will be kept on gitlab)
• 12/2023: No new bug fixes on crew command regarding i686
• 01/2024 future plan: Completely remove support and prebuilt binaries for i686

[uberhacker]

It's even worse than you mentioned. The Chrome browser has many more issues that make it incompatible with several sites. Even Google Drive doesn't work on older releases anymore. But...a lot of cli apps still work great. I definitely think it's not worth the effort to continue to struggle with the gui stuff but cli apps are fine to continue to build.

[alexsch01]

@supechicken I agree that 32-bit x86 systems should eventually be depreciated.
However, how does this work for things like Wine and Steam that require 32-bit x86 packages?

[satmandu]

Wine emulation of x86 requires multilib (x86 libraries on x86_64) which Chromebrew has never supported...

[alexsch01]

Google has also dropped support for all ARMv7 chromebooks

[satmandu]

Google has also dropped support for all ARMv7 chromebooks

I think that just means Chromebooks with an armv7l kernel. All arm Chromebooks still use an armv7l userspace...

[satmandu]

@alexsch01 worth noting that wine 8, which we now have, is well on its way to supporting 32-bit x86 win32 binaries without requiring i686 linux libraries...

[alexsch01]

Google has also dropped support for all ARMv7 chromebooks

I think that just means Chromebooks with an armv7l kernel. All arm Chromebooks still use an armv7l userspace...

Should you drop support for devices with ARM 32-bit kernel? I can't tell when the last chromebook with that kernel was released

[uberhacker]

@alexsch01: As @satmandu mentioned earlier, arm Chromebooks (including aarch64) still use a 32-bit userspace, although recently some aarch64 systems now have a 64-bit userspace. There are still many Chromebooks that currently require armv7l binaries so we cannot drop support yet.

[alexsch01]

any update on this?

[uberhacker]

We have been slowly updating packages that are unable to build i686 binaries. I imagine as long as there are some packages that can still build from source, we won't be deprecating those. The effort to try and maintain i686 has fallen off significantly, however.

[Zopolis4]

Adding my two cents to this in light of some upcoming changes I'm making-- the way I see it, we should maintain i686 support as long as it does not require too much effort or otherwise negatively affect the functionality of chromebrew.

"too much effort" is whatever the maintainer decides, nobody should feel under any obligation to ensure the functionality of i686 beyond the bare functionality of chromebrew itself (i.e. being able to install chromebrew and install at least some packages)