Carbon TODO

johnraff · 2025-09-28 23:42:41

This is a place to drop things that should be fixed before the Carbon official release.
Feel free to post - devs still reserve the right to ignore suggestions they don't agree with!

johnraff · 2025-09-28 23:49:33

BLOB needs going over so users who like the Boron (or other) look will easily be able to go back to it.

N.B. BLOB isn't a kind of system snapshot - it only preserves the appearance of other setups. This means, for example, there's no need to have a mechanism to restore tint2 for older looks - it's enough if we ship configs for xfce4-panel to look like the Boron (or whatever) tint2 panel.

But that means creating xfce4-panel config files for all the BLOB presets we plan to ship with Carbon. I think that's still easier than putting in things like prompts to install tint2? Or not?

Maybe long-term it would be simpler to have only xfce4-panel configs? (I think tint2 is on the way out anyway.)

Last edited by johnraff (2025-09-29 00:02:18)

johnraff · 2025-09-28 23:58:02

Put the repo signing key in /usr/share/keyrings and add a "signed-by" entry to our sources list so apt will use it.

✅ DONE

EDIT: upgraded bunsen-archive-keyring now uploaded. It puts a .pgp keyring in /usr/share/keyrings, and continues to drop an .asc in /etc/apt/trusted.gpg.d. I think we should make an announcement that the /etc/apt/trusted.gpg.d file will go away with Nitrogen, so people should make sure they add the "signed-by" entry by then. For iso installs we can handle it, but users upgrading from an earlier release will have to do it themselves.

DEB822 SOURCES NOT DONE:

And also (related issue) decide if we're going to ship deb822 sources or stay with the old version for another release.

Or possibly add a page to bl-welcome so the conversion can be done post-install.

EDIT: I think the first thing we can try wrt deb822 sources is to run 'apt --yes modernize-sources' in the BL preseed script that gets run at the end of the installation. Since the Debian sources.list has just been created by D-I there should be nothing odd to throw off the apt script. When I tried it on a recently installed Carbon (alpha4) it successfully detected the Debian key locations and put them in the sources file, leaving only BunsenLabs' sources to do. Since the key is now available at /usr/share/keyrings/bunsen-release.pgp a simple sed substitution on /etc/apt/sources.list.d/bunsen.list before running modernize-sources should be enough to get it added correctly. Let's put it in the next iso build anyway, and see if it works.

Last edited by johnraff (2025-10-21 08:05:21)

johnraff · 2025-09-30 06:17:18

packages, dependencies and upgrades

✅ DONE

Our package bunsen-themes isn't actually used in Carbon, which gets its themes from bunsen-yaru-gtk

Up till now themes were organized like this:
bunsen-themes-base: contains only the theme(s) needed for the default desktop
bunsen-themes: contains the theme files used in the previous release, along with a few other popular ones - mainly those used by BLOB presets
bunsen-themes-extra: more themes...

So, how about making the carbon bunsen-themes-base empty, but making it Depend on bunsen-yaru-gtk?
The advantage for users is that upgrades should go a bit more smoothly. They'll already have bunsen-themes-base installed and when upgrading to Carbon it will pull in bunsen-yaru-gtk.

(We can move the Boron theme files to bunsen-themes, and possibly a couple of less used themes from bunsen-themes to bunsen-themes extra.)

I don't think that's too controversial?

There's an advantage for developers too, that when there's a new BL release they don't have to update the theme package in the three different package lists we maintain (live-build for the iso, bunsen-meta-all and bunsen-netinstall) - just changing the dependency in bunsen-themes-base is enough (or optionally putting the actual files back there).

---

Perhaps we could also create an empty bunsen-icons-base package too, that would depend on whatever icon theme is currently used? Again, smoother upgrades and less work for developers. (It could be named bunsen-icons, but the -base name leaves us free to add another bigger icon package later, if we want to, and harmonizes with bunsen-themes-base and bunsen-images-base.)

Last edited by johnraff (2025-10-08 03:02:54)

hhh · 2025-09-30 12:48:54

^ I'm fine with this. Thumbs up.

johnraff · 2025-10-01 01:29:06

^Thanks! It's quite easy to do, so I'll put out those two packages soon, and substitute the names in our package lists.

johnraff · 2025-10-06 02:01:53

default locale

✅ DONE (see post #10)

On first boot the default user locale seems to be set to C.UTF-8, whereas we would like it to be whatever the user has set when they were interacting with Debian-Installer.

I suspect this might be because we added a preseed line to install en_US.UTF-8 along with whatever $User had chosen.
The issue was pointed out by @Head_on_a_Stick https://forums.bunsenlabs.org/viewtopic … 46#p141146
and I tentatively added this line to the d-i preseed file:

d-i localechooser/supported-locales multiselect en_US.UTF-8

That seems to have successfully added en_US.UTF-8 to the installed locales, but with the side-effect that the user's previously chosen locale no longer gets set as default.

I'm going to have a look round the d-i code, try to figure out what's happening and see if there's a hidden config or environment variable we could set, but probably it will be easiest to replace that "multiselect" line with the fix that @HoaS posted:

d-i preseed/late_command string sed -i '/en_US.UTF-8/s/^#//' /target/etc/locale.gen ; in-target locale-gen

Either directly in preseed.cfg or in the BL script that gets triggered from a late_command there.

Last edited by johnraff (2025-10-21 07:55:22)

Head_on_a_Stick · 2025-10-06 07:05:11

johnraff wrote:

On first boot the default user locale seems to be set to C.UTF-8

In my system the desktop locale is set correctly to en_GB.UTF-8 in the output of locale but localectl & /etc/default/locale are both set to C.UTF-8 unless dpkg-reconfigure locales is passed.

That sed preseed hack didn't work for me btw, which is why I switched to multiselect for the trixie release.

Anyway, I've just got a job so I will have to post back after work...

johnraff · 2025-10-06 09:05:01

^It looks like a bug in debian-live*, not from our multiselect preseed. Even the debian-live iso
https://cdimage.debian.org/debian-cd/cu … andard.iso
booted up to a C.UTF-8 locale, not my chosen en_GB.UTF-8. The GB locale had been generated though.

Trixie netinstall (not live) didn't have this bug.
https://cdimage.debian.org/debian-cd/cu … etinst.iso

Nor did our Boron CD.

*) or possibly live-build, by which the debian live images are built

EDIT:
looks like this bug: https://bugs.debian.org/cgi-bin/bugrepo … ug=1111214

If it does turn out to be a live-build bug we should be able to apply a local patch for our builds (we've done it before) until the official fix comes in.

Last edited by johnraff (2025-10-06 09:26:23)

johnraff · 2025-10-21 07:53:55

johnraff wrote:

^It looks like a bug in debian-live*, not from our multiselect preseed. Even the debian-live iso
https://cdimage.debian.org/debian-cd/cu … andard.iso
booted up to a C.UTF-8 locale, not my chosen en_GB.UTF-8.
*) or possibly live-build, by which the debian live images are built
looks like this bug: https://bugs.debian.org/cgi-bin/bugrepo … ug=1111214

Roland Clobus (a major live-build developer) is working on it, and in the meantime someone else has posted a fix:
https://bugs.debian.org/cgi-bin/bugrepo … 1111214#24

It looks like a hack, but I've tested it out in a build and it does the job. Until a "proper" fix is available we can go ahead with that in our Carbon build configs and get the right locale setting, so I've marked this issue as done.

johnraff · 2025-10-21 08:03:43

johnraff wrote:

Put the repo signing key in /usr/share/keyrings and add a "signed-by" entry to our sources list so apt will use it.

Adding "signed-by" to the apt line in our live-build config worked right off, no bother, so this part of the issue is done.

And also (related issue) decide if we're going to ship deb822 sources or stay with the old version for another release.
Or possibly add a page to bl-welcome so the conversion can be done post-install.
EDIT: I think the first thing we can try wrt deb822 sources is to run 'apt --yes modernize-sources' in the BL preseed script that gets run at the end of the installation. Since the Debian sources.list has just been created by D-I there should be nothing odd to throw off the apt script. When I tried it on a recently installed Carbon (alpha4) it successfully detected the Debian key locations and put them in the sources file, leaving only BunsenLabs' sources to do. Since the key is now available at /usr/share/keyrings/bunsen-release.pgp a simple sed substitution on /etc/apt/sources.list.d/bunsen.list before running modernize-sources should be enough to get it added correctly. Let's put it in the next iso build anyway, and see if it works.

No, that didn't work. The apt modernization part ran OK in the preseed but the changed sources format messed up some other scripts that run in Debian-Installer. It has to be left in the old sources.list format during the install.

But there's no reason why bl-welcome can't offer to modernize the sources on first boot.

sleekmason · 2025-10-21 14:02:57

But there's no reason why bl-welcome can't offer to modernize the sources on first boot.

It can also be run after any third party repo additions from outside sources. Pretty dang handy to keep everything together.

I don't know how backports inclusions are set up in BL, but I had to remember the signing key for backports as well, as apt will throw a warning after the addition without the signing.

Last edited by sleekmason (2025-10-21 14:03:54)

unklar · 2025-10-21 14:26:08

done

Last edited by unklar (2025-10-21 15:33:51)

johnraff · Yesterday 01:54:45

sleekmason wrote:

But there's no reason why bl-welcome can't offer to modernize the sources on first boot.
It can also be run after any third party repo additions from outside sources. Pretty dang handy to keep everything together.

Right. I found if some sources were in old format and some on deb822, then 'apt modernize-sources' would do the right thing: modernize the old sources and leave the deb822 sources alone.

I don't know how backports inclusions are set up in BL

Of course users can do it themselves, but bl-welcome will offer to add Debian or BunsenLabs backports.
Here's the addDebianBackports() function:
https://github.com/BunsenLabs/bunsen-we … kports#L23
It looks complicated but boils down to this line:

sudo tee <<< "${bp_repo_msg}${bp_repo_line}"$'\n' "$bp_repo_file" >/dev/null

Plug in all the variables for trixie/carbon to get:

sudo tee <<< "'Suitable message'$'\n'deb https://deb.debian.org/debian trixie-backports main contrib non-free non-free-firmware'$'\n' /etc/apt/sources.list.d/debian-trixie-backports.list >/dev/null

(I may have dropped a quote somewhere)
But anyway, all it does is write a new line into a file in /etc/apt/sources.list.d/ and later do an apt update.

...but I had to remember the signing key for backports as well, as apt will throw a warning after the addition without the signing.

I don't know what's happening there. As far as I can tell, the same debian keyring works for regular sources, security, updates and backports, and I've never had to worry about it. Just add the new line and do an apt upgrade, and it works - has been my experience to date.

sleekmason · Yesterday 03:26:09

I don't know what's happening there. As far as I can tell, the same debian keyring works for regular sources, security, updates and backports, and I've never had to worry about it. Just add the new line and do an apt upgrade, and it works - has been my experience to date.

For Bookworm, I was adding a single line to /etc/apt/sources.list.d/backports.list to keep it separated from the main /etc/apt/sources.list.

From what I can tell, the modernize-sources script was expecting to find a signing key line within the backports.list file. Easy enough to remedy once I found out it was throwing a warning. Just one of those unexpected odd issues I guess.

Last edited by sleekmason (Yesterday 03:26:43)

johnraff · Yesterday 04:29:18

^Ah, an issue with 'modernize-sources' not with the apt keys themselves. Yes, it expects to be able to find the key - it can do that with regular debian lines, but not with 3rd-party sources, unless there's a [signed-by...] entry. That's one thing I've just added to the iso build configs. Live-build seems to handle [signed-by...] in the config/archives sources without a problem. It just gets passed through to the built iso as-is.

But I hadn't thought about the implication for bl-welcome, so thanks for the reminder! I'm just about to add a 'modernize-sources' page, so I'll do the signed-by bit at the same time.

...choosing the right order to do things in bl-welcome is also a bit tricky. I was hoping to modernize the sources close to the start, but that would mean having to rewrite the backport-adding sections using deb822 format. First, I'll see if it makes sense to modernize the sources later, after the backports have been done. That would save having to rewrite any of the early stuff, since 'modernize-sources' seems to handle mixed sources, whatever you give it. (And the apt sources checker near the start handles sources independent of the format - but writes out edits in the old format.)

Last edited by johnraff (Yesterday 04:39:01)

sleekmason · Yesterday 14:03:30

I was hoping to modernize the sources close to the start, but that would mean having to rewrite the backport-adding sections using deb822 format.

Ya know, for BL, it might make sense to modernize sources at initial apt update, as it might be expected that BL would have them already converted? ... unless there is still reason to keep the old sources.list method. (and there might be, see below) If this is the case, having the change in Live-builld makes sense, but apparently that isn't going to happen this round from what you said earlier.

Whether to ask it as a separate question or not (people do like groovy control items:), or just add it in on the update/upgrade question because the assumption may be that BL would have already modernized the sources 'automagically',
and possibly adding a simple message assuring the user they are good to go with the new method.

^ As far as I can see, in BL, this has been the way of it for technical items of this nature, in that it will eventually be the default, so we're doing it now.

The possible issue I found:
So far, the optimize sources script has been rock solid, requiring zero extra checks or steps , except in one case where I was adding prerequisite kernel building dependencies, and one of the dev packages needed a proper debian address to proceed. In other words, still looking for the line in /etc/apt/sources.list. Don't remember which package right off, but can recreate the situation pretty quick if desired.

As to the backports file... In bookworm, I was just using a simple "echo | tee" combination to replace the line if needed.

In Trixie, I'm using the full power of the force and doing a full cp -f "/some/root/config/extras/folder" "/etc/apt/sources.list.d" This just makes the process bomb proof for my current needs, and was way simpler than adding echo lines or sed. While I try to keep away from this method to add files, I think there is just six files or so I do this with. Anything where flubs can be difficult to remedy.

Anyway, the important part here is that folks can add backports by rerunning the welcome script at any time, or through a separate installer script (if in LD), so having the correct format is crucial to not running into the error I talked about in the post above, and also to not cause the user to have to mess with any other sources they may want left alone. Especially if they don't change to the new method. Trixie will pick up both, so it's not an issue.

For my own use, I have the welcome script start with a simple apt update and upgrade with no changes. Gives the user assurance life is groovy without making them jump hoops first.
Then I'm using netselect-apt to find a faster mirror if desired. (Gotta script it) I leave the security line alone.
Then the modernize sources question, which also takes your new super fast mirrors and adds them to the mix. lol (what do you mean? of course their faster!)
Then at some point, I ask if wanting to add backports? with the next question being do you want to install the backports kernel? (which also adds the sources) Because it's a full copy, it just doesn't matter as to when.

...choosing the right order to do things in bl-welcome is also a bit tricky.

Right? Can't say the number of times I was going to make just a small adjustment, to only have to adjust four more files in a snowball effect afterwards. lol I tend to miss half of them on the first go. Jeez.

hhh · Yesterday 16:40:09

Just a note... Back when trixie was testing, apt prompted to modernize sources, but apt in trixie stable doesn't give a damn. There's no prompt, unless I'm mistaken.

johnraff · Today 02:48:07

^@hhh I think the devs decided to tone it down a bit, after getting some complaints.

^^@sleekmason thanks for the insights on modernizing sources. It is quite tricky juggling the two formats.

Both live-build and debian-installer are still using the traditional one-line format, and both of them are complex multi-file systems that I think would be next to impossible to patch to handle deb822. I expect the respective developers will have it done in time, but it looks like a lot of work.

So patching live-build won't work unless debian-installer is also involved. My first idea was to add a "late command" to the d-i preseed, which would run 'modernize-sources' at the end of the install. Unfortunately d-i still has some important work to do after the preseed late commands have run, some of which involves apt, and breaks if the sources have been modernized.

Now I'm looking at adding a page to bl-welcome. Of course, right now the deb822 format is not compulsory and everything will go on working with the old style sources, so we don't have to force modernizing on all users. Maybe someone has a reason to keep the old format.

So, where in the bl-welcome sequence?

Luckily, our first apt-checking script in bl-welcome is format-agnostic - it doesn't look at the sources files, but asks apt about sources directly. But if a necessary source is missing, it writes it in with the old format. Likewise with the scripts which add backports.

So, two possible approaches?

1) Let everything be written in the old format, as now, and then run 'apt modernize-sources' after all that's been done. It will detect any sources that can be modernized and allow the user to choose yes or no. I think that should be OK, without having to prompt the user first, because m-s itself has the user choice built-in.

2) Run 'modernize-sources' early in the sequence and rewrite the scripts which write sources to use deb822.

Considering:

folks can add backports by rerunning the welcome script at any time

I'm leaning towards 1) right now, simply because it's less work. Users who re-run bl-welcome and add a backport will then see the m-s info about sources that can be converted - which they can decline by entering 'N' if they want.

johnraff · Today 06:12:02

sleekmason wrote:

The possible issue I found:
So far, the optimize sources script has been rock solid, requiring zero extra checks or steps , except in one case where I was adding prerequisite kernel building dependencies, and one of the dev packages needed a proper debian address to proceed. In other words, still looking for the line in /etc/apt/sources.list. Don't remember which package right off, but can recreate the situation pretty quick if desired.

I missed this section before, but yes please - if you can give me the info I need to try to reproduce this issue. Much appreciated!

If there are many things like this, it could possibly be an argument for forgetting all about deb822 till Forky maybe...

Last edited by johnraff (Today 06:13:25)

#1 2025-09-28 23:42:41

Carbon TODO

#2 2025-09-28 23:49:33

Re: Carbon TODO

#3 2025-09-28 23:58:02

Re: Carbon TODO

#4 2025-09-30 06:17:18

Re: Carbon TODO

#5 2025-09-30 12:48:54

Re: Carbon TODO

#6 2025-10-01 01:29:06

Re: Carbon TODO

#7 2025-10-06 02:01:53

Re: Carbon TODO

#8 2025-10-06 07:05:11

Re: Carbon TODO

#9 2025-10-06 09:05:01

Re: Carbon TODO

#10 2025-10-21 07:53:55

Re: Carbon TODO

#11 2025-10-21 08:03:43

Re: Carbon TODO

#12 2025-10-21 14:02:57

Re: Carbon TODO

#13 2025-10-21 14:26:08

Re: Carbon TODO

#14 Yesterday 01:54:45

Re: Carbon TODO

#15 Yesterday 03:26:09

Re: Carbon TODO

#16 Yesterday 04:29:18

Re: Carbon TODO

#17 Yesterday 14:03:30

Re: Carbon TODO

#18 Yesterday 16:40:09

Re: Carbon TODO

#19 Today 02:48:07

Re: Carbon TODO

#20 Today 06:12:02

Re: Carbon TODO

Board footer