Notices by Chimera Linux (chimera_linux@floss.social)

@shebang @famfo only if you have the executable bit set and the right dependencies

we will soon be dropping #riscv support from the repositories for the time being, read about why:

https://chimera-linux.org/news/2025/03/dropping-riscv.html

@Ze_Andarilho no explicit plans no

also, since we are still evaluating switching bootloaders on live images, it'd be very helpful if everyone willing tried booting this iso and reporting whether it boots:

https://repo.chimera-linux.org/live/testing/chimera-linux-x86_64-LIVE-20250307-base.iso

all combos are wanted, i.e. efi, bios, from usb stick, from optical media (but few probably have the option nowadays), please test the ones that you can

btw, if you're curious why not a lot of updates are coming in the last couple days: we're currently in the process of introducing the loongarch64 architecture into the repos/build fleet

once the build queue has cleared, updates and pull request reviews will resume

a testing loongarch64 image is now available at https://repo.chimera-linux.org/live/testing (of course, without public repos it's not yet very useful)

reminder: free software without its politics is called "open source" and it's what corporates and certain other entities want to gaslight you into thinking is the appropriate soul-draining default

we don't do that; chimera is not a product and will always act in the interest of the community + try to be self-sustaining without external control

and it will always strive to be a fun and safe space where everyone can feel comfy and appreciated (except nazis, bigots, and other disruptive elements)

since we have apk-tools 3.0_rc4 now, it comes with modernization and resolves some old pain:

1) repos provide v3-style index names (Packages.adb) alongside v2-style (APKINDEX.tar.gz) for compat
2) we have a stable way for the user to select their system repo mirror, without modifying the repo packages, read about it here: https://chimera-linux.org/docs/apk/mirrors

x86_64 and ppc64le repos are done (others are still building and may take some hours)

unrelatedly, gcc packages (14.2.0) are coming on all platforms

as a minor surprise to end the year, there is an upcoming 32-bit powerpc architecture support, the repos of which are currently in the process of being built (a local prototype can already boot on bare metal as well as in a virtual machine)

of course, it wil be a tier-3 architecture (like big-endian ppc64)

apk-tools has been updated to a rc version, and with that, i am declaring the project officially beta

announcement post: https://chimera-linux.org/news/2024/12/entering-beta.html

there is still much to be done next year, but overall we're in a much better shape than last year

the last half a year of development has been under sponsorship by netgate, allowing me to dedicate half my igalia time; they've also been contributing to cports, overall a big help, this will go on in 2025

here's to another year full of improvements :)

now for the good things - the new system keeps backups while also automatically pruning old kernels, so you don't need chimera-prunekernels anymore; after the upgrade, you can run `chimera-prunekernels rm all` (the command will remain for a while) to ditch all the pre-transition stuff and from now on you won't have to worry about it

it also has much nicer initramfs regen behavior, centralized depmod handling, and finally no package pre/post hooks

CAUTION: the new kernel management/backup system has landed in https://github.com/chimera-linux/cports/compare/a40feaf75b9c...b0dd53277ee4

this will result in your most recent kernel before the updated one disappearing due to package hooks going away

also be extra careful everything is intact after upgrade especially if you use out of tree modules (e.g. zfs) and report issues if you run into any

i tried my best to iron out any edge cases, so hopefully i got it all right, but still

so ahead of beta, there is now one more new image set out today; this is a prerequisite for implementing a new kernel backup/prune system that we want to deploy before the beta phase, as a new apk-tools feature was necessary to implement this

while at it, the project has two new committers (congrats :)) and lost one :(

https://chimera-linux.org/news/2024/12/new-images-committers.html

apk-tools is bumped to latest version in master again (will take a bit to get to users) so please take extra care upgrading and report any potential issues if they arise

it should be safe this time, but anyway...

if something goes wrong, @q66 is to blame :)

how to get minecraft working on chimera:

`doas apk add prismlauncher openal-soft openjdk17 gcompat`

(contrib repo needs to be enabled)

add your account, install the game; right-click the game, "edit", go to settings, custom commands, check 'custom commands'

in wrapper command: `env LD_PRELOAD=/usr/lib/libgcompat.so.0`

now go to java tab, check 'java arguments', and add:

`-Dorg.lwjgl.openal.libname=/usr/lib/libopenal.so.1`

nothing needs setting in workarounds tab

chimera is now an option for vps images at https://vpsfree.cz @vpsfree_cz

it's also where a lot of our infrastructure is hosted - the build master server, the repo server, and our ppc64le build hardware is in vpsfree's rack in Brno, CZ

@twojays wrong chimera...

we are deprecating per-template maintainer metadata: https://github.com/chimera-linux/cports/pull/2013

@danderson in any case, i see this as an opportunity; whenever we are creating new APIs, they are vendor-neutral abstractions so that software utilizing them can work on top of anything (whether it's our own stuff, or systemd, or something completely different like a BSD)

it's fine for systemd to have its own APIs, but it's not a correct abstraction level for higher level applications to rely on (the low level systemd api is not even that pleasant to work with in the first place)

@danderson @valpackett @nogweii @bitprophet additionally i'm also not a fan of their blatant disregard of cost vs usefulness; for instance it has some iirc 1500 lines of code whose sole purpose is printing ellipsis in unicode in the logs; the code for doing so is non-trivial and possibly a source of annoying bugs and corner cases, while the actual usefulness of it seems dubious at best

@danderson @valpackett @nogweii @bitprophet there is some entirely non-portable and sketchy functionality used by systemd that imo has no justification whatsoever; for instance the way it assumes object sizes via malloc_usable_size rather than tracking its own memory properly is really bad and has bitten them even on glibc before (https://github.com/systemd/systemd/issues/22801) and the basis for using it is entirely misguided