Carbon Bugs

greenjeans · 2025-03-15 16:34:39

unklar wrote:

Thank you both very much.
However, it does not change my opinion that libreoffice-writer, -calc etc. could be installed by each user himself, if he wants to. For me, this is essentially a question of the size of the ISO.

Just my opinion, but I would love to see a BL mini type iso, just the infrastructure but no major programs. Seems like it would also make it easier to test the basic system first, before adding the complexity of a full system. I'd download/install that in a heartbeat and be happy to test/report back on whatever y'all needed testing.

johnraff · 2025-03-16 06:39:35

unklar wrote:

...my opinion that libreoffice-writer, -calc etc. could be installed by each user himself, if he wants to. For me, this is essentially a question of the size of the ISO.

For the full - default - BL install the aim is that the user will be able to open most files they're likely to be sent. That means MS Office .doc .docx files etc, for which libreoffice writer will do the job. There are other apps which will work too, but they're harder to use or less reliable etc etc. So for a default install libreoffice-writer seemed to be a reasonable compromise. (You could probably search out the discussion somewhere on the forum.)

As for iso size, I don't think adding libreoffice-writer makes a huge difference. Drives are quite spacious these days.

greenjeans wrote:

I would love to see a BL mini type iso, just the infrastructure but no major programs.

There are no alternative isos, but there are bunsen-meta-lite and bunsen-meta-base metapackages. Either of them can be installed on top of a basic Debian command-line-only install for people who want to build their BL system from the ground up. The netinstall script also offers "full" "lite" and "base" installs.

Last edited by johnraff (2025-03-16 06:41:11)

greenjeans · 2025-03-17 15:07:57

johnraff wrote:

greenjeans wrote:
I would love to see a BL mini type iso, just the infrastructure but no major programs.
There are no alternative isos, but there are bunsen-meta-lite and bunsen-meta-base metapackages. Either of them can be installed on top of a basic Debian command-line-only install for people who want to build their BL system from the ground up. The netinstall script also offers "full" "lite" and "base" installs.

Niiiice, now you're playing my song brother. bunsen-meta-base it is.

johnraff · 2025-03-18 05:00:37

greenjeans wrote:

bunsen-meta-base it is

Please post if you run into any other packages that you think ought to be included in meta-base (or left out).

kozimodo · 2025-03-29 22:04:20

After a hiatus of many years and after acquiring an old Chromebook with a whopping 2 gigs of ram, I thought I'd try out Carbon. I installed Boron, edited source files and did an upgrade. Two small issues:

* There is no battery icon. I see xfce4-power-manager.desktop in the /etc/xdg/autostart folder but it is not running. I can start it from the command line and the tray icon appears so it is installed.
* The format for apt repositories has changed from .list to .sources. My problem is that the new bunsen .sources files need something in the "Signed-By" field. I assume it is because the repo signing key is in /etc/apt/trusted.gpg.d/ as an .asc file rather than a .gpg file in /usr/share/keyrings. What is the recommended way of fixing this?

Head_on_a_Stick · 2025-03-29 22:52:17

kozimodo wrote:

There is no battery icon

The trixie autostart file now only activates specifically under Xfce so you should instead add a line for xfce4-power-manager to ~/.config/bunsen/aotostart, as per johnraff's post here.

kozimodo wrote:

the new bunsen .sources files need something in the "Signed-By" field

See https://forums.bunsenlabs.org/viewtopic … 40#p141740 and my replies.

kozimodo · 2025-03-30 00:12:12

Thank you! All fixed!

cog · 2025-04-21 06:09:09

Not a bug in carbon but the Debian trixie and sid live-build packages..

live-build for trixie will fail unless you do one of the following:

You can either change the source format to quilt, bump the version past and patch the package like the git commit or edit the file locally to get around it. I patched it for my purposes but either way works. Hopefully they’ll push a newer live-build in between freezes.

https://salsa.debian.org/live-team/live … d6e9b20832

Just sharing some info in case yall need it too.

johnraff · 2025-04-21 06:53:01

Hi @cog thanks for this heads-up.
We'll be starting to run builds before long, so until a new live-build shows up, one of your fixes will be needed.
(I guess an alternative workaround would be to build live-build from source somewhere after commit 95cbab4b.)

Since that bug completely blocks builds, I'm sure that commit will make it to the Trixie release before too long though.

---
The last few releases, I've been using a mechanism I made for applying local patches when running l-b, then unapplying to keep everything clean. Just in case you're interested (I've left in the commented-out obsolete code):

auto/build

#!/bin/sh

set -e

# maximum possible squashfs compression, at the expense of build time
# https://lists.debian.org/debian-live/2017/02/msg00028.html
# https://techoverflow.net/2013/01/11/creating-a-highly-compressed-squashfs-from-a-folder/
# '-Xdict-size 100%' is probably redundant, because 100% seems to be the default.

# Now disabled even in "lite" 32-bit build because 700MB limit has been dropped.
#export MKSQUASHFS_OPTIONS='-b 1048576 -Xbcj x86 -Xdict-size 100%'

# config/lb_patches is a script to make temporary changes to live-build.
# Please keep these to a minimum!

trap : INT QUIT HUP PIPE TERM # ensure EXIT trap works with 'set -e' on dash
# see https://unix.stackexchange.com/a/596985
# This is so user can interrupt build with Ctrl+C and patched files will be restored.
trap restore_files EXIT

apply_patches() {
    if [ -x config/lb_patches.sh ]
    then
        patch_msg=''
        echo "Applying live-build patches..." | tee -a build.log
        if patch_msg=$( config/lb_patches.sh apply 2>&1 )
        then
            echo "$patch_msg" | tee -a build.log
            applied_patches=true
            sleep 4
        else
            echo "$patch_msg" | tee -a build.log
            echo "ERROR Patching live-build failed!
    Check config/lb_patches.sh" | tee -a build.log
            exit 1 # exit now, before trying to run live-build
        fi
    else
        echo 'Not applying any patches to live-build.'
        sleep 2
    fi
}

restore_files() {
    if [ "$applied_patches" = 'true' ]
    then
        echo ""
        if [ -x config/lb_patches.sh ]
        then
            patch_msg=''
            echo "Removing live-build patches..." | tee -a build.log
            if patch_msg=$( config/lb_patches.sh remove 2>&1 )
            then
                echo "$patch_msg" | tee -a build.log
            else
                echo "$patch_msg" | tee -a build.log
                echo "ERROR Unpatching live-build failed!" | tee -a build.log
                exit 1
            fi
        else
            echo "ERROR Failed to execute 'lb_patches remove'" | tee -a build.log
            exit 1
        fi
    else
        echo ""
        echo 'No files were patched - nothing to restore.'
    fi
}

echo "Starting build at $( date )" | tee build.log

applied_patches=false

apply_patches

echo "
Starting live-build...
" | tee -a build.log
sleep 2

lb build noauto "${@}" 2>&1 | tee -a build.log

# Now handled with trap above.
#restore_files

config/lb_patches.sh

#!/bin/sh

# - script to make temporary changes to live-build while building iso -
# Please do not over-use this!

case $1 in
apply)
    mode=apply
    ;;
remove)
    mode=remove
    ;;
*)
    echo "usage: $0 [apply|remove]" >&2
    exit 1
    ;;
esac

do_patching=f

# 1 and 2 are now (tag debian/1%20210407) unnecessary due to changes in live-build.
# 3 dropped for non-cd build

for i in 4 5
do
    case "$i" in
#    1)
#        # This patch enables squashfs X* options to be passed in MKSQUASHFS_OPTIONS.
#        # (Such options must be passed *after* '-comp xz'.)
#        file=/usr/lib/live/build/binary_rootfs
#        patch=config/patches/binary_rootfs-squashfs_options.patch
#        ;;
#    2)
#        # No longer needed from live-build 1:20210407
#        # This patch removes the comments at the top of md5sum.txt,
#        # created by /usr/lib/live/build/binary_checksums.
#        # Such comments break the "Check the CD-ROM(s) integrity" menu item
#        # in Debian Installer.
#        file=/usr/lib/live/build/binary_checksums
#        patch=config/patches/binary_checksums-nocomment.patch
#        ;;
#    3)
        # This patch adds any files in config/dpkg to chroot/etc/dpkg/dpkg.cfg.d
        # This will be done before chroot package installation,
        # allowing customization of dpkg behaviour.
        # Currently, this is used to add some path-exclude options
        # for locales, doc and man files.
        # This is to squeeze the CD iso size down as much as possible.
#        file=/usr/lib/live/build/chroot_dpkg
#        patch=config/patches/chroot_dpkg-configs.patch
#        ;;
    4)
        # This patch enables live-* packages to be treated as such.
        # They will be added to live/filesystem.packages-remove on the disk
        # to be removed at install time.
        file=/usr/lib/live/build/config
        patch=config/patches/config-live.list.patch
        ;;
    5)
        # This patch prevents unwanted ARM firmware from being installed on an X86 system
        # (or vice versa).
        # It implements commit 8eaf20da on live-build:
        # https://salsa.debian.org/live-team/live-build
        file=/usr/share/live/build/functions/firmwarelists.sh
        patch=config/patches/8eaf20daf1cf79669975b1acfe4d6fa453eb6307.patch
        ;;
    *)
        echo "${0}: bad loop index" >&2
        exit 1
        ;;
    esac

    do_patching=t

    if ! [ -w "$file" ]
    then
        echo "Cannot write to ${file}." >&2
        exit 1
    fi
    if ! [ -r "$patch" ]
    then
        echo "Cannot read from ${patch}." >&2
        exit 1
    fi

    case $mode in
    apply)
        if mv "$file" "${file}-bak" && cp "${file}-bak" "$file"
        then
            if patch -u "$file" -i "${patch-X}" # patch will hang on unset variable, waiting for stdin
            then
                echo "Patched ${file}."
            else
                echo "Failed to patch ${file}." >&2
                exit 1
            fi
        else
            echo "Failed to make backup of ${file}." >&2
            exit 1
        fi
        ;;
    remove)
        if ! [ -f "${file}-bak" ]
        then
            echo "Cannot restore $file, backup does not exist." >&2
            exit 1
        fi
        if mv -f "${file}-bak" "$file"
        then
            echo "Restored ${file} to former state."
        else
            echo "Failed to restore ${file}." >&2
            exit 1
        fi
        ;;
    esac
done

if [ "$do_patching" = f ]
then
    case $mode in
    apply)
        echo "No patches to apply"
        ;;
    remove)
        echo "No patches to remove"
        ;;
    esac
fi

exit

Patch files go in config/patches

Last edited by johnraff (2025-04-21 06:54:42)

cog · 2025-04-21 07:07:49

^ cool setup. Might try that in the future between packages. Hopefully they’ll push out a new tag before long. What got me worried was the fact a newer tag wasn’t even in Sid yet.

cog · 2025-04-21 07:24:19

Besides the fuse thing the isos build good on trixie. Surprise surprise they’re several hundred MB bigger in file size.

Last edited by cog (2025-04-21 07:24:42)

johnraff · 2025-04-22 01:08:17

^Every Debian upgrade brings a chubbier iso. "Several hundred megabytes" is quite a jump though.

DeepDayze · 2025-04-22 02:03:24

johnraff wrote:

^Every Debian upgrade brings a chubbier iso. "Several hundred megabytes" is quite a jump though.

No doubt and most likely won't be able to offer a CD-size ISO unless things on the ISO are a bare bare minimum.

cog · 2025-04-22 05:34:47

johnraff wrote:

^Every Debian upgrade brings a chubbier iso. "Several hundred megabytes" is quite a jump though.

It's the same ole story but wanted to give you a heads up. As far as I can tell we're talking about 500MB.

This is after they've incorporated the patch to strip out raspi-firmware etc that was borking out the bookworm builds a couple years ago.

cog · 2025-04-22 05:36:35

@deepdaze, definitely. If it is indeed a 500MB increase there's your cd joilet right there. (almost)

Head_on_a_Stick · 2025-04-22 07:44:39

I built a trixie version of deadbang using the latest git commit for live-build:

~$ ls -lh deadbang-13.0-0.1-amd64.hybrid.iso 
-rw-r--r--  1 empty empty  1.9G Apr 21 12:42 deadbang-13.0-0.1-amd64.hybrid.iso
~$

The bookworm images are 1.5GiB

johnraff · 2025-04-22 07:55:15

Boron is 1.8GB so you win there, by a bit.
But a GiB is a little bit bigger than a GB...

greenjeans · 2025-04-22 16:37:01

Saw the comments above in the script about xz, don't know if this is helpful or not, but months ago I switched from xz to zstd once a 700 mb limit was no longer feasible even in a mini, squashfs accepts it at it's highest compression level (22). It makes for an iso that's about 10% bigger, but it de-compresses way faster than xz does, Arch claims it's 13 times faster at decompression.

In practice everything works a lot faster during a live-session, and installing from that live-session is faster too.

Edit: It does take a fair bit longer than xz to compress, I usually set my machine to work then go to lunch, lol.

Last edited by greenjeans (2025-04-22 16:43:18)

johnraff · 2025-04-23 01:49:35

^Thanks for the suggestion about zstd. Compression time only affects the builder (us) while a fast decompression time benefits all users, so it's something we should look at for Carbon.

(In the past xz was live-build's only compression option.)

I think the remaining active patches in the above script are no longer needed with the current Trixie live-build, but new things might come up...

greenjeans · 2025-04-23 15:11:07

johnraff wrote:

(In the past xz was live-build's only compression option.)
.

That I didn't know, and to be clear I still don't know as I don't use live-build, I use a snapshot program.

I was just running through the mksquashfs man page months ago, actually checking to see if there were any new squishies that might get me smaller and no joy there, but did see zstd was added at some point, did the research, then did a TON of side-by-side testing and zstd was clearly superior. It hurt my minimalist head to have an even slightly larger iso, but the benefits to the user won out.

I've squashed some 70+ isos since then, if you choose the load-to-ram option at the live-boot menu it always runs faster in session, but zstd is something special, it's lightning in a bottle when run that way, but even using the "default" load is so much quicker in session. Install as I mentioned is a lot faster too.

Of course all this is on a 2012 very low spec machine, so it's easy for me to see even small differences, on a modern machine with a lot of cores and ram it might not be very noticeable.

#101 2025-03-15 16:34:39

Re: Carbon Bugs

#102 2025-03-16 06:39:35

Re: Carbon Bugs

#103 2025-03-17 15:07:57

Re: Carbon Bugs

#104 2025-03-18 05:00:37

Re: Carbon Bugs

#105 2025-03-29 22:04:20

Re: Carbon Bugs

#106 2025-03-29 22:52:17

Re: Carbon Bugs

#107 2025-03-30 00:12:12

Re: Carbon Bugs

#108 2025-04-21 06:09:09

Re: Carbon Bugs

#109 2025-04-21 06:53:01

Re: Carbon Bugs

#110 2025-04-21 07:07:49

Re: Carbon Bugs

#111 2025-04-21 07:24:19

Re: Carbon Bugs

#112 2025-04-22 01:08:17

Re: Carbon Bugs

#113 2025-04-22 02:03:24

Re: Carbon Bugs

#114 2025-04-22 05:34:47

Re: Carbon Bugs

#115 2025-04-22 05:36:35

Re: Carbon Bugs

#116 2025-04-22 07:44:39

Re: Carbon Bugs

#117 2025-04-22 07:55:15

Re: Carbon Bugs

#118 2025-04-22 16:37:01

Re: Carbon Bugs

#119 2025-04-23 01:49:35

Re: Carbon Bugs

#120 2025-04-23 15:11:07

Re: Carbon Bugs

Board footer