[RC2 now out] Carbon alpha iso available for testing

sleekmason · 2025-10-28 01:32:23

The system itself - not our package - installs a symlink from the old location /etc/os-release to /usr/lib/os-release, so any app reading the file in /etc will just see /usr/lib/os-release. I don't see how writing to /etc/os-release would be any different from writing to /usr/lib/os-release. Unless you actually delete the symlink first? That would mean there are two separate os-release files, and apps would read one or the other, depending on how modern they are...

Thank you for going over all that.

The /etc/os-release takes precedence over the two in case of separation. Sounds like I should make a change there from what I'm doing. I would rather see it correct if I can.

I would think if a program reads from the debian version in /usr/lib, everything should still function the same, considering the 'ID_LIKE="debian"' line that is part of the distro version?

johnraff · 2025-10-28 02:01:41

sleekmason wrote:

The /etc/os-release takes precedence over the two in case of separation.

Indeed you're right:
https://www.freedesktop.org/software/sy … lease.html

The file /etc/os-release takes precedence over /usr/lib/os-release. Applications should check for the former, and exclusively use its data if it exists, and only fall back to /usr/lib/os-release if that is missing. Applications should not combine the data from both files. /usr/lib/os-release is the recommended place to store OS release information as part of vendor trees. /etc/os-release should be a relative symlink to /usr/lib/os-release, to provide compatibility with applications only looking at /etc/.

So /etc/os-release takes precedence, but vendors (like BL) should install to /usr/lib/os-release. And anyway /etc/os-release should be a symlink... OK

As for specific keys like 'ID_LIKE="debian"', I think it's up to individual apps how much attention they're going to pay to them. We just put it in and hope for the best.

But grub, anyway, currently looks at /etc/os-release in /etc/default/grub:

GRUB_DISTRIBUTOR=`( . /etc/os-release && echo ${NAME} )`

(There's a lot of archaic-looking code in grub.)

sleekmason · 2025-10-28 02:12:33

But grub, anyway, currently looks at /etc/os-release in /etc/default/grub:

I wouldn't have thought the path would be in the general config. I've probably stared at that line dozens of times without it really being relevant before now. Good to know.

Symlink it is then.

johnraff · 2025-10-28 05:55:25

A hint in the debian-installer log (/var/log/installer/syslog):

Oct 23 09:02:37 in-target: Selecting previously unselected package bunsen-os-release.^M
Oct 23 09:02:37 in-target: Preparing to unpack .../bunsen-os-release_13.0-1_all.deb ...^M
Oct 23 09:02:37 in-target: Unpacking bunsen-os-release (13.0-1) ...^M
Oct 23 09:02:39 in-target: Setting up bunsen-python-apt-template (13.0-1) ...
Oct 23 09:02:39 in-target: ^M
Oct 23 09:02:39 in-target: Setting up bunsen-os-release (13.0-1) ...^M
Oct 23 09:02:40 in-target: Generating grub configuration file ...^M
Oct 23 09:02:41 in-target: Found background image: /usr/share/images/desktop-base/desktop-grub.png^M
Oct 23 09:02:42 in-target: Found linux image: /boot/vmlinuz-6.12.48+deb13-amd64^M
Oct 23 09:02:42 in-target: Found initrd image: /boot/initrd.img-6.12.48+deb13-amd64^M
Oct 23 09:02:42 in-target: Generating custom entry for: /boot/vmlinuz-6.12.48+deb13-amd64^M
Oct 23 09:02:42 in-target: Found initrd image: /boot/initrd.img-6.12.48+deb13-amd64^M
Oct 23 09:02:43 in-target: Warning: os-prober will not be executed to detect other bootable partitions.^M
Oct 23 09:02:43 in-target: Systems on them will not be added to the GRUB boot configuration.^M
Oct 23 09:02:43 in-target: Check GRUB_DISABLE_OS_PROBER documentation entry.^M
Oct 23 09:02:43 in-target: Adding boot menu entry for UEFI Firmware Settings ...^M
Oct 23 09:02:43 in-target: grub background_image is BL default, setting text colors
Oct 23 09:02:43 in-target: ^M
Oct 23 09:02:43 in-target: done
Oct 23 09:02:43 in-target: ^M
Oct 23 09:02:43 in-target: Adding 'diversion of /usr/lib/os-release to /usr/lib/os-release.bunsen-orig by bunsen-os-release'
Oct 23 09:02:43 in-target: ^M
Oct 23 09:02:43 in-target: dpkg-divert: warning: diverting file '/usr/lib/os-release' from an Essential package with rename is dangerous, use --no-rename
Oct 23 09:02:43 in-target: ^M
Oct 23 09:02:43 in-target: Adding 'diversion of /etc/dpkg/origins/default to /etc/dpkg/origins/default.bunsen-orig by bunsen-os-release'^M

See?
Setting up bunsen-os-release (13.0-1)...
Generating grub configuration file...
then later
Adding 'diversion of /usr/lib/os-release to /usr/lib/os-release.bunsen-orig by bunsen-os-release

It looks as if grub is being updated just after the install of bunsen-os-release, as it should be because it's in the postinst script. But the diverting of /usr/lib/os-release comes later, after the grub menu has already been generated.

Here's debian/bunsen-os-release.postinst:

#!/bin/sh
# postinst script for bunsen-os-release

# Summary of ways this script is called:
#    postinst configure most-recently-configured-version(null if not upgrade)
#    old-postinst abort-upgrade new-version
#    conflictor's-postinst abort-remove in-favour package new-version
#    deconfigured's-postinst abort-deconfigure in-favour failed-install-package version removing conflicting-package version

set -e

case $1 in
configure|abort-upgrade|abort-deconfigure|abort-remove)
    # grub menu entry name has been edited from output of:
    # 'lsb_release -i -s' ( from ID in /usr/lib/os-release )
    if command -v update-grub > /dev/null ; then
        sync
        update-grub || true
    fi
    ;;
esac

# dh_installdeb will replace this with shell code automatically
# generated by other debhelper scripts.

#DEBHELPER#

exit 0

I wonder if moving the #DEBHELPER# entry to the beginning of the script would get the new os-release file in place before 'update-grub' is run? I'll give it a try in an experimental iso build...

johnraff · 2025-10-31 02:39:51

...and as for file-roller, anyway after revisiting xarchiver I'm coming round to switching to that, if no-one objects.
https://forums.bunsenlabs.org/viewtopic … 65#p146665

But even if we do that, there will probably still be a few GTK4 apps around.

sleekmason · 2025-10-31 02:40:24

No, Realistically, it's probably going to be Engrampa or Xarchiver. However, I saw where you had said Engrampa wouldn't open an archive of some sort? That's not good. Guessing you checked the depends. could it just be a missing package?

johnraff · 2025-10-31 02:57:47

^Of course all the depends would have been automatically installed, and I checked the Recommends: they were all present too.
I got this error with engrampa:

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now

But as I said, the other two had no problems, and 'tar --list -f <file>' threw no warnings.

Considering engrampa's install was ~16MB while xarchiver was a few hundred kB, and didn't look outstandingly worse, at least with our Carbon dark themes...

sleekmason · 2025-10-31 03:06:00

Lol, I should be more specific I suppose. I use 'apt depends' to check the recommends for any packages. I've used Xarchiver throughout Bookworm, and currently in Trixie, in a minimal build without problems. So far so good. :)

Last edited by sleekmason (2025-10-31 03:17:42)

sleekmason · 2025-10-31 03:32:27

johnraff wrote:

I got this error with engrampa:
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
But as I said, the other two had no problems, and 'tar --list -f <file>' threw no warnings.

Is it possible your file is just labeled incorrectly and can't be read by engrampa?

file file.tar.gz

hhh · 2025-10-31 04:23:54

Just a reminder not to get jammed up by details. We're allowed a post-release upgrade. Trixie is already at 13.1. and LTS for trixie goes till 2030, so there is time for adjustments.

https://www.debian.org/releases/stable/

johnraff · 2025-11-04 06:33:45

sleekmason wrote:

johnraff wrote:
I got this error with engrampa:
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
But as I said, the other two had no problems, and 'tar --list -f <file>' threw no warnings.
Is it possible your file is just labeled incorrectly and can't be read by engrampa?
file file.tar.gz

Something like that:

john@trixie-tester:~/Downloads$ file labbe-bark.tar.gz 
labbe-bark.tar.gz: POSIX tar archive (GNU)

Some tag or something must be missing, though other archivers are OK with it. I think that's still a point against engrampa though.

johnraff · 2025-11-04 06:36:20

hhh wrote:

Just a reminder not to get jammed up by details. We're allowed a post-release upgrade. Trixie is already at 13.1...

Right. When your iconned wallpapers and debian installer banner are ready I'll run off a beta iso that will only be missing the refurbished BLOB.

johnraff · 2025-11-05 04:22:14

sleekmason wrote:

I use 'apt depends' to check the recommends for any packages.

Cool. I had no idea apt had that command - it's not in 'man apt' nor in 'man apt-get' (which doesn't support 'depends' anyway).

hhh · 2025-11-05 12:05:34

@johnraff, the same way I didn't know you could use 'apt policy' instead of 'apt-cache policy', you can shorten 'apt-cache depends' and 'apt-cache rdepends' (I can't find much documentation either)...

https://manpages.debian.org/trixie/apt/ … .8.en.html

johnraff · 2025-11-06 00:12:26

^Ah, I didn't think of looking at 'apt-cache' for 'depends'. Thanks!

It's convenient how 'apt' incorporates a selection of commands from apt-get and apt-cache (others?) but confusing till you know.

hhh · 2025-11-07 03:17:22

They are apt wrapper scripts, I have no idea why they're not documented. We're in the secret club now, I guess!

johnraff · 2025-11-07 05:08:37

^btw @hhh I'm working on the bunsen images packages right now - need a bit of feedback from you.
https://forums.bunsenlabs.org/viewtopic … 11#p146811
For the image archives package wallpapers - keep the logo or plain version?

hhh · 2025-11-10 22:15:06

^ Right, I'll bump it up to 60%.

johnraff · 2025-11-16 05:11:29

The wallpapers discussion has been moved to a dedicated thread: https://forums.bunsenlabs.org/viewtopic.php?id=9590

johnraff · 2026-01-12 07:33:12

johnraff wrote:

A hint in the debian-installer log (/var/log/installer/syslog):
See?
Setting up bunsen-os-release (13.0-1)...
Generating grub configuration file...
then later
Adding 'diversion of /usr/lib/os-release to /usr/lib/os-release.bunsen-orig by bunsen-os-release
It looks as if grub is being updated just after the install of bunsen-os-release, as it should be because it's in the postinst script. But the diverting of /usr/lib/os-release comes later, after the grub menu has already been generated.
Here's debian/bunsen-os-release.postinst:
#!/bin/sh
# postinst script for bunsen-os-release

# Summary of ways this script is called:
#    postinst configure most-recently-configured-version(null if not upgrade)
#    old-postinst abort-upgrade new-version
#    conflictor's-postinst abort-remove in-favour package new-version
#    deconfigured's-postinst abort-deconfigure in-favour failed-install-package version removing conflicting-package version

set -e

case $1 in
configure|abort-upgrade|abort-deconfigure|abort-remove)
    # grub menu entry name has been edited from output of:
    # 'lsb_release -i -s' ( from ID in /usr/lib/os-release )
    if command -v update-grub > /dev/null ; then
        sync
        update-grub || true
    fi
    ;;
esac

# dh_installdeb will replace this with shell code automatically
# generated by other debhelper scripts.

#DEBHELPER#

exit 0
I wonder if moving the #DEBHELPER# entry to the beginning of the script would get the new os-release file in place before 'update-grub' is run? I'll give it a try in an experimental iso build...

That did work, but not at first. While debian-installer is running there are two os-release files: both /etc/os-release and /usr/lib/os-release are present (I think this is a change since Bookworm). bunsen-os-release operates on /usr/lib/os-release, while grub, when setting the menu, looks at /etc/os-release which still has Debian data.

The final fix was to change /etc/os-release to a symlink in the BL preseed script, and then to install bunsen-os-release. The #DEBHELPER# bit in bunsen-os-release.postinst fixed up /usr/lib/os-release, and update-grub got run after that, so saw the BL data in /etc/os-release because by then it's been changed to a symlink. It finally worked, but took some time getting there.

#81 2025-10-28 01:32:23

Re: [RC2 now out] Carbon alpha iso available for testing

#82 2025-10-28 02:01:41

Re: [RC2 now out] Carbon alpha iso available for testing

#83 2025-10-28 02:12:33

Re: [RC2 now out] Carbon alpha iso available for testing

#84 2025-10-28 05:55:25

Re: [RC2 now out] Carbon alpha iso available for testing

#85 2025-10-31 02:39:51

Re: [RC2 now out] Carbon alpha iso available for testing

#86 2025-10-31 02:40:24

Re: [RC2 now out] Carbon alpha iso available for testing

#87 2025-10-31 02:57:47

Re: [RC2 now out] Carbon alpha iso available for testing

#88 2025-10-31 03:06:00

Re: [RC2 now out] Carbon alpha iso available for testing

#89 2025-10-31 03:32:27

Re: [RC2 now out] Carbon alpha iso available for testing

#90 2025-10-31 04:23:54

Re: [RC2 now out] Carbon alpha iso available for testing

#91 2025-11-04 06:33:45

Re: [RC2 now out] Carbon alpha iso available for testing

#92 2025-11-04 06:36:20

Re: [RC2 now out] Carbon alpha iso available for testing

#93 2025-11-05 04:22:14

Re: [RC2 now out] Carbon alpha iso available for testing

#94 2025-11-05 12:05:34

Re: [RC2 now out] Carbon alpha iso available for testing

#95 2025-11-06 00:12:26

Re: [RC2 now out] Carbon alpha iso available for testing

#96 2025-11-07 03:17:22

Re: [RC2 now out] Carbon alpha iso available for testing

#97 2025-11-07 05:08:37

Re: [RC2 now out] Carbon alpha iso available for testing

#98 2025-11-10 22:15:06

Re: [RC2 now out] Carbon alpha iso available for testing

#99 2025-11-16 05:11:29

Re: [RC2 now out] Carbon alpha iso available for testing

#100 2026-01-12 07:33:12

Re: [RC2 now out] Carbon alpha iso available for testing

Board footer