Profile for chimera

Display name
Chimera Linux
Username
@chimera@gts.chimera-linux.org
Role
admin

About chimera

Bio

A modern, general-purpose Linux distribution; posts by @q66

Formerly @chimera_linux

Stats

Joined
Posts
82
Followed by
1841
Following
0

Recent posts

all non-draft pull requests from before this month have been dealt with, and the remainder is less than 15 right now

next week we'll switch back to ordinary PR reviews (you'll see once the PR template changes)

meanwhile, news in service management and related things are shaping up:

- our zram device manager now supports minimal scripting in the configuration files, with a lisp-like syntax and support for a basic bunch of operators and math functions as well as variables, both builtin and user-defined (external commands can be used)
- work on new logging infrastructure has been started again, which will allow for race-free and less ad-hoc logging for both system and user services, with syslog integration (later) and safe rotation and cleanup
- our mount helper has become a lot more useful, particularly its "supervise" mode:
  - available for general use in $PATH as dinit-mount-supervise
  - by default, mounts a volume, stays up for as long as nothing unmounts it, and unmounts it by itself if terminated
  - can act as a pure monitor for existing mountpoints without touching them itself
  - can act as a generic mount command with the --no-supervise flag (exits as soon as the mountpoint has reliably appeared in mtab)
  - can use external (u)mount commands (e.g. for sshfs without superuser, or other specialty helpers)
  - supports readiness notification via fd
  - can be used to construct supervised mount services, akin to systemd mount units
  - does not use libmount or require mount(8) or similar
- fstab handling on boot will soon be reworked to use dynamically generated services per fstab line, using the above helper, and including support for auxiliary filesystems such as network mounts, with correct ordering and clean shutdown
- similar flexible treatment is planned for zfs and lvm2

gnome 51 landed in cports

in time for the release but still with gnome-session and gdm held back for the time being

other than that all the new stuff is in

hopefully in time for 52 we'll get the session stuff figured out

our core userland tools have been updated to freebsd 15.1 base (coming to repos once builders are done with chromium)

mostly minor improvements/fixes

most notable new feature is that find(1) now supports -xattr and -xattrname to match files that have extended attributes / a particular extended attribute

i've provisionally deployed a new build machine for aarch64 builds, since the other one was lagging behind the others (chromium hogging it for 28 hours)

so we're going from a 16-core cloud vm to an 80-core ampere altra baremetal

so it should be at least on par with the others now

with the new kde frameworks / gear release coming into the repositories in the next hours, make sure to always upgrade with the --available apk flag (this tends to be a good idea in general, particularly with interactive mode)

kmime has moved from gear to frameworks so its version number went down (from 26.04 to 6.29)

the soname it provides also changes which means things should implicitly pull in the new one either way (as they depend on it through the virtual so: name) but just in case

btw distrohopping is stupid

if a system appeals to you, use it, but jumping around on a weekly basis or whatever only places a burden on small communities and provides nothing of value to the project

SDDM now defaults to wayland in the repositories, with fixes for how the tty is chosen (a check for which getty services are active + a fallback override via config file)

additionally the packaging is fixed to actually default to the plasma breeze theme instead of the ugly builtin, and packaging reorg was done to make this more flexible

the only thing currently holding xorg server in the main/ repo is plasma-desktop (though it's optional at runtime and not installed by default); later this year it will be moved out, and its supporting bits (such as window managers) will be moved out earlier

there are no plans to drop it, but it won't be shipped in any images and will remain in the user/ repository

the PR clearing has been going well so most likely all non-recent PRs will be cleared within the next two weeks and the moratorium on review-heavy things will be dropped

afterwards the focus will shift to keeping the percentage of up to date packages close to 90% again (if you look at repology and similar sources, it has been stagnating over the past 1-2 years due to various circumstances, however this number is somewhat misleading as most important/security-sensitive/high profile packages like desktop environments and browsers are strictly kept updated and most other out of date things are only a couple patch versions behind)

right now the pace is stable and manageable

also, there is now a pull request to switch SDDM from X11 to wayland by default: https://github.com/chimera-linux/cports/pull/5815

this will become important as plasma 6.8 drops X11 support and we plan to move xorg to the user repository by that point

testing/feedback/fixes welcome, i'll leave it for a while before making the switch (it works fine here)

following the previously announced timeframe, the big-endian ppc64 and ppc builders have been shut down and removed from the infrastructure

cports will remain as is but there will be no more fixes; existing big endian specific tweaks will remain until they start getting in the way, at which point they will be dropped one by one

package repos for the dropped architectures will remain frozen for the time being

ppc64le for power8+ remains a first-tier platform

currently supported targets:

- aarch64
- loongarch64
- ppc64le
- riscv64
- x86_64

since the current idea is to clear the PR queue, pull requests for new packages or significant changes opened from now on will get closed unless the PR is in a good enough shape to undergo little to no review OR i have a personal interest in getting it in**

this is until further notice (which means, until all the lingering pull requests are gone)

which basically means, if you want new stuff in and it's not a really straightforward template as is, read CONTRIBUTING.md and the packaging manual quality requirements section really carefully, or don't be mad if stuff gets closed** (having stuff like incorrect commit messages out of the box is a reason not to bother looking further)

on the other hand, what is explicitly welcome is update PRs for existing packages provided they are well tested (particularly by people who have been around a while and can be trusted) because that saves me a lot of mechanical work

lower quality stuff will only be looked at once there is more breathing room, sorry; there is only so much mental capacity i have to review random RIIR programs or stuff that is to be used by exactly 1 person or some reddit tier fonts or themes or whatever assorted junk people try to submit

**since people seem to be consistently ignoring this, to be entirely clear, this means a near complete moratorium on new packages by inexperienced people, since unless you do have the experience, you are not qualified to judge what is straightforward and what is not

since noone has stepped up and july is coming up, the retirement of our big-endian power/powerpc platforms will proceed

this is the timeframe:

- july 13 the builders will be shut down and removed from the infrastructure (4 months after announcement)
- repositories will be frozen and the packages will remain until the end of the year
- build profiles, patches, and other support bits in cports will not be removed outright but will be gradually dropped when they start getting in the way of updates

it would be great to stop perpetuating the misconception that flatpak is somehow an official package manager or solution for things (this is implied on eg the wikipedia page and is entirely wrong)

flatpak is not supported any better than in any other distro that has it available for installation

it's considered a crutch for when something is missing and something being missing from apk repos is not a feature except in very specific cases

likewise cports is not a user-end package manager either, it's a maintenance tool for getting things into apk repos

the sole official, supported source of software is chimera's own apk repos

please stop asking about switching to codeberg

they do not provide infra we require (multi-architecture builds)

if they did, we don't want to abuse their infrastructure for a ton of random builds (abusing microsoft's is perfectly okay)

hosting your own ci runners is a can of worms we're not willing to open right now

in case of emergency we're fully capable of migrating to something else and are not bound to github

for now things stay on github

plasma six seven landed in cports

coming to repos near you... soon probably

(it's a joint update with qt 6.11.1, frameworks, and gear, so it'll take a bit)