Carbon alpha iso available for testing

sleekmason · 2025-10-27 12:39:37

johnraff wrote:
^I set both color-scheme to 'prefer-dark' and gtk-theme to 'bunsen-yaru-bark-dark' but file-roller and transmission are still white. I couldn't find a dconf-editor "apply" button though.

hhh wrote:
Try setting the dconf-editor window to maximize or full-screen, the "Apply" button should appear lower-right.

Here, the button is at the top right-hand corner, and kinda unobtrusive. It only shows when a change has ocurred.

Last edited by sleekmason (2025-10-27 12:40:02)

sleekmason · 2025-10-27 12:45:36

Quick note on the picom issue before I forget.. bl-welcome will not appear correctly unless compositing is already disabled, so that may alter our thoughts on this a bit.

sleekmason · 2025-10-27 13:21:27

sleekmason wrote:

johnraff wrote:
Let me guess... "the line" meant the top entry of the grub boot window?
Yes. Of interest is that while I updated, I do not believe I installed anything that would have updated grub... Oh boy. I'm doing a reinstall and testing further.
I saw no issues with the os-release file. Are you placing it in /etc? or /usr/lib for the build?
I noted I had changed from /usr/lib to /etc for the file placement due to some non-specific issue or another. I did not notate the change as such, so not sure exactly why. Could be something is getting lost in the transfer from /usr/lib.

Okay, double checked this, AND seem to remember this was indeed the issue, so hope the switch to /etc will work. Pretty sure I made the change on a whim hoping it would work and never thought about it again.

So not populating before grub in the installer I suppose. No, doesn't really make sense, given it hasn't changed since at least buster that I am aware of, but there it is.

Last edited by sleekmason (2025-10-27 19:17:04)

johnraff · 2025-10-28 00:39:55

sleekmason wrote:

Quick note on the picom issue before I forget.. bl-welcome will not appear correctly unless compositing is already disabled, so that may alter our thoughts on this a bit.
https://i.postimg.cc/zHb3r0NH/vm2.png

I noticed that too, but it's only in the case of a VM where OpenGL is not enabled. It would seem a bit harsh to cripple our pretty compositing for the sake of that corner case? Why not just post somewhere that VMs should have 3D acceleration enabled, or else compositing should be switched off?

hhh · 2025-10-28 00:52:04

johnraff wrote:

sleekmason wrote:
Quick note on the picom issue before I forget.. bl-welcome will not appear correctly unless compositing is already disabled, so that may alter our thoughts on this a bit.
https://i.postimg.cc/zHb3r0NH/vm2.png
I noticed that too, but it's only in the case of a VM where OpenGL is not enabled. It would seem a bit harsh to cripple our pretty compositing for the sake of that corner case? Why not just post somewhere that VMs should have 3D acceleration enabled, or else compositing should be switched off?

+1. This is the way. No cripple the pretty, until it's necessary.

johnraff · 2025-10-28 00:55:49

sleekmason wrote:

johnraff wrote:
Let me guess... "the line" meant the top entry of the grub boot window?
Yes. Of interest is that while I updated, I do not believe I installed anything that would have updated grub...
I saw no issues with the os-release file. Are you placing it in /etc? or /usr/lib for the build?

bunsen-os-release installs os-release.bunsen to /usr/lib/, where config-package-dev does a dpkg-divert to rename it and move the original os-release aside. This has been happening with no issues for multiple releases.

I noted I had changed from /usr/lib to /etc for the file placement due to some non-specific issue or another. I did not notate the change as such, so not sure exactly why. Could be it wasn't getting read properly from /usr/lib.

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...

Anyway, I'm going to dig into this (new) issue some more.

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-30 08:10:15

If you put the gtk theme in the environment, then file-roller uses it.
There are many ways to do that, but for example, add this line to ~/.config/bunsen/environment:

export GTK_THEME='bunsen-yaru-bark-dark'

Log out and back in and file-roller will use that theme.

But that means if a user changes the theme in lxappearance then file-roller won't follow (it wouldn't anyway of course), so some kind of hook would be needed to rewrite that line when the theme is changed. Not impossible at all.

johnraff · 2025-10-31 01:19:13

^ No forget that. With GTK_THEME set in the environment then all other apps get locked up too. Lxappearance can't change the theme.

Another idea though - a wrapper script around any uncooperative app like file-roller, that checks ~/.config/gtk-3.0/settings.ini for the current GTK theme and force-feeds it to the app before running it. Let me play with it...

...this seems to work.
file-roller.wrapper

#!/bin/bash

gtk_file=~/.config/gtk-3.0/settings.ini
gtk3_theme=$( sed -nE 's/[[:blank:]]*gtk-theme-name[[:blank:]]*=[[:blank:]]*([[:alnum:]-]+).*$/\1/p' "$gtk_file" )

GTK_THEME="$gtk3_theme" file-roller "$@"

file-roller will come up using the currently set GTK theme. The theme must have a gtk4 directory though (as the bunsen-yaru themes do). Make such a .wrapper script for whichever uncooperative apps need to be told the GTK theme - there shouldn't be very many right now, and that *.wrapper command can go in a user .desktop file too.
Just call 'fileroller.wrapper' instead of file-roller.

Alternatively, a script that will do the same thing for whatever app you tell it:
gtkset

#!/bin/bash

app=$1
shift
gtk_file=~/.config/gtk-3.0/settings.ini
gtk3_theme=$( sed -nE 's/[[:blank:]]*gtk-theme-name[[:blank:]]*=[[:blank:]]*([[:alnum:]-]+).*$/\1/p' "$gtk_file" )

GTK_THEME="$gtk3_theme" "$app" "$@"

That way you only need one script but you have to call it like this:

gtkset file-roller <file>

Last edited by johnraff (2025-10-31 02:30:08)

sleekmason · 2025-10-31 02:26:04

johnraff wrote:

Another idea though - a wrapper script around any uncooperative app like file-roller, that checks ~/.config/gtk-3.0/settings.ini for the current GTK theme and force-feeds it to the app before running it. Let me play with it...

Will this method work for any theme without gtk-4.0 support? Those running older themes will still be presented with white dialogs.

johnraff · 2025-10-31 02:32:21

^

johnraff wrote:

The theme must have a gtk4 directory though

So, no. I don't think any method will work to set a non-GTK4 theme with a GTK4 app.

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/

#81 2025-10-27 12:39:37

Re: Carbon alpha iso available for testing

#82 2025-10-27 12:45:36

Re: Carbon alpha iso available for testing

#83 2025-10-27 13:21:27

Re: Carbon alpha iso available for testing

#84 2025-10-28 00:39:55

Re: Carbon alpha iso available for testing

#85 2025-10-28 00:52:04

Re: Carbon alpha iso available for testing

#86 2025-10-28 00:55:49

Re: Carbon alpha iso available for testing

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

Re: Carbon alpha iso available for testing

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

Re: Carbon alpha iso available for testing

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

Re: Carbon alpha iso available for testing

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

Re: Carbon alpha iso available for testing

#91 2025-10-30 08:10:15

Re: Carbon alpha iso available for testing

#92 2025-10-31 01:19:13

Re: Carbon alpha iso available for testing

#93 2025-10-31 02:26:04

Re: Carbon alpha iso available for testing

#94 2025-10-31 02:32:21

Re: Carbon alpha iso available for testing

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

Re: Carbon alpha iso available for testing

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

Re: Carbon alpha iso available for testing

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

Re: Carbon alpha iso available for testing

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

Re: Carbon alpha iso available for testing

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

Re: Carbon alpha iso available for testing

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

Re: Carbon alpha iso available for testing

Board footer