Carbon Bugs

hhh · 2025-05-09 17:56:55

^ Right, so that's a nightmare. Commented out in ~/.config/bunsen/autostart the xfce4-panel line I added and uncommented bl-tint2-session, only to realize tint2 wasn't installed. Installed it, still nothing, and it disable jgmenu, so I had to drop to TTY to fix it. If I had done that first edit from the jgmenu 'User Settings>Bunsenlabs Session>Edit autostart' menu item and I was a n00b, I would have no idea where that file was located.

@johnraff, IMO we need a carbon Alpha ISO so everyone can be on the same page from the get-go. I have no clue what alterations I made to my netinstall, except for having to add the themes and icons myself afterwards.

I know it's a ton of work, let me know what I can do to help! I would really like to see x-session carbon released in coordination with the trixie release, and I suggest everyone drop wayland work until that's under control.

/my two cents

hhh · 2025-05-09 18:07:33

^ So the xfce4-panel bluetooth solution is blueman, of course, but I swear it wasn't installed after choosing the option in bl-welcome. Am I wrong?

Not even gonna try and troubleshoot why tint2 wouldn't start for me. Happily listening to Garbage via Bluetooth instead.

hhh · 2025-05-09 18:23:46

hhh wrote:

^ So the xfce4-panel bluetooth solution is blueman, of course, but I swear it wasn't installed after choosing the option in bl-welcome. Am I wrong?

I am wrong, I hit Enter instead of 'y'. However, hitting 'y' prompts this...

INSTALL PACKAGES
  ----------------
  
  This script will now execute some deferred actions.
  
  These packages will be installed:
   bunsen-meta-bluetooth
  
  
  Would you like to perform these actions? [Y/n] 

  Installing packages...
Reading package lists...
Building dependency tree...
Reading state information...
Solving dependencies...
The following additional packages will be installed:
  acl avahi-daemon bc blueman bluez-cups bluez-meshd bluez-tools colord
  colord-data cups cups-browsed cups-client cups-common cups-core-drivers
  cups-daemon cups-filters cups-filters-core-drivers cups-ipp-utils cups-ppdc
  cups-server-common ipp-usb libasound2-plugins libavahi-core7 libcolorhug2
  libcupsfilters1t64 libdaemon0 libell0 libfontembed1t64 libgusb2
  libieee1284-3t64 liblouis-data liblouis20 liblouisutdml-bin
  liblouisutdml-data liblouisutdml9t64 libnss-mdns libpoppler-cpp2 libpulsedsp
  libqpdf30 libsane-common libsane1 libsnmp-base libsnmp40t64 libwrap0 lynx
  lynx-common mailcap poppler-utils pulseaudio pulseaudio-module-bluetooth
  pulseaudio-utils rtkit sane-airscan sane-utils ssl-cert
Suggested packages:
  avahi-autoipd colord-sensor-argyll cups-bsd cups-pdf
  foomatic-db-compressed-ppds | foomatic-db smbclient antiword docx2txt
  imagemagick ooo2dbk rtf2xml avahi-autoipd | zeroconf hplip
  snmp-mibs-downloader pavumeter paprefs unpaper
The following packages will be REMOVED:
  pipewire-alsa pipewire-audio
The following NEW packages will be installed:
  acl avahi-daemon bc blueman bluez-cups bluez-meshd bluez-tools
  bunsen-meta-bluetooth colord colord-data cups cups-browsed cups-client
  cups-common cups-core-drivers cups-daemon cups-filters
  cups-filters-core-drivers cups-ipp-utils cups-ppdc cups-server-common
  ipp-usb libasound2-plugins libavahi-core7 libcolorhug2 libcupsfilters1t64
  libdaemon0 libell0 libfontembed1t64 libgusb2 libieee1284-3t64 liblouis-data
  liblouis20 liblouisutdml-bin liblouisutdml-data liblouisutdml9t64
  libnss-mdns libpoppler-cpp2 libpulsedsp libqpdf30 libsane-common libsane1
  libsnmp-base libsnmp40t64 libwrap0 lynx lynx-common mailcap poppler-utils
  pulseaudio pulseaudio-module-bluetooth pulseaudio-utils rtkit sane-airscan
  sane-utils ssl-cert
0 upgraded, 56 newly installed, 2 to remove and 0 not upgraded.
Need to get 24.5 MB of archives.
After this operation, 94.5 MB of additional disk space will be used.
Do you want to continue? [Y/n] n

So that's going to screw with pipewire/wireplumber, and install avahi, cups and sane which I don't want. acl? colord? No. All I need is...

sudo apt install blueman

Time to buckle down...

https://release.debian.org/testing/freeze_policy.html

This sounds terse, and I assure you that is not my intention. I am not the Wolf.

Winston Wolf wrote:

So, pretty please, with sugar on top. Clean the f***ing car."

johnraff · 2025-05-10 03:12:37

hhh wrote:

@johnraff, IMO we need a carbon Alpha ISO so everyone can be on the same page from the get-go.
...I would really like to see x-session carbon released in coordination with the trixie release, and I suggest everyone drop wayland work until that's under control.

Agreed.
My own VM Wayland test session is badly broken since a couple of weeks ago, but getting a nice clean X session ready will probably help.

We're nearly there in terms of putting out a new bunsen-configs with provisional settings for GTK theme, wallpaper, icons, picom and xfce4-panel. There will be a fair bit of cleaning up to do, especially with xfce4-panel I think (I'm not a fan to be honest, but we have no choice). So yes, that's a good reason to get an alpha iso out.

A new live-build is in Sid and we should see it in Trixie in a few days. Once bunsen-configs is done and micko01's new packages are in the main repo, I'll try an iso build...

johnraff · 2025-05-10 04:04:59

hhh wrote:

...hitting 'y' prompts this...

INSTALL PACKAGES
  These packages will be installed:
   bunsen-meta-bluetooth
    
  Would you like to perform these actions? [Y/n] 

  Installing packages...
The following additional packages will be installed:
  acl avahi-daemon bc blueman bluez-cups bluez-meshd bluez-tools colord
  colord-data cups cups-browsed cups-client cups-common cups-core-drivers
  cups-daemon cups-filters cups-filters-core-drivers cups-ipp-utils cups-ppdc
  cups-server-common ipp-usb libasound2-plugins libavahi-core7 libcolorhug2
  libcupsfilters1t64 libdaemon0 libell0 libfontembed1t64 libgusb2
  libieee1284-3t64 liblouis-data liblouis20 liblouisutdml-bin
  liblouisutdml-data liblouisutdml9t64 libnss-mdns libpoppler-cpp2 libpulsedsp
  libqpdf30 libsane-common libsane1 libsnmp-base libsnmp40t64 libwrap0 lynx
  lynx-common mailcap poppler-utils pulseaudio pulseaudio-module-bluetooth
  pulseaudio-utils rtkit sane-airscan sane-utils ssl-cert
Suggested packages:
  avahi-autoipd colord-sensor-argyll cups-bsd cups-pdf
  foomatic-db-compressed-ppds | foomatic-db smbclient antiword docx2txt
  imagemagick ooo2dbk rtf2xml avahi-autoipd | zeroconf hplip
  snmp-mibs-downloader pavumeter paprefs unpaper
The following packages will be REMOVED:
  pipewire-alsa pipewire-audio

So that's going to screw with pipewire/wireplumber, and install avahi, cups and sane which I don't want. acl? colord? No. All I need is...

sudo apt install blueman

That's the issue that came up a couple of weeks ago, I guess?
https://forums.bunsenlabs.org/viewtopic … 07#p142707 (and following)
It looks as if the bluetooth metapackage needs two versions, for pulse and pipewire.

Current depends of bunsen-meta-bluetooth are

Package: bunsen-meta-bluetooth
Section: metapackages
Architecture: all
Depends:
 bluez,
 blueman,
 pulseaudio-module-bluetooth,
 bluez-cups,
 bluez-meshd,
 bluez-obexd,
 bluez-tools

So, for now, you might want to check if there's anything you need in that list apart from blueman.

micko01 · 2025-05-10 08:20:42

johnraff wrote:

A new live-build is in Sid and we should see it in Trixie in a few days. Once bunsen-configs is done and micko01's new packages are in the main repo, I'll try an iso build...

I think the most important things on my end are:

labbe-icons-ng - mostly complete
material-solarized-suruplusplus-ng - nearly done
xwwall - nearly done, which depends on the next point
gtk3dialog which is done but needs to be formally introduced to the bunsen repo. As it's external, because it is available to any linux/*nix system, it presents different requirements for inclusion

I'll get most, if not all, of this done by the end of next weekend.

johnraff · 2025-05-10 08:46:13

^Yes those four packages are the things I was thinking of.

gtk3dialog being "external" touches on what I was referring to about the icons, and a pending new dev discussion thread.

Anyway, for packages which don't need any special modification for BL how about we just clone the repo into our GitHub BL repo collection and build from that? Wouldn't that apply to xwwall too? If there turn out to be some changes needed for BL then we can put them on a dedicated local "carbon" branch, leaving your upstream repo clean.

micko01 · 2025-05-10 22:04:56

hhh wrote:

@johnraff, IMO we need a carbon Alpha ISO so everyone can be on the same page from the get-go. I have no clue what alterations I made to my netinstall, except for having to add the themes and icons myself afterwards.
I know it's a ton of work, let me know what I can do to help! I would really like to see x-session carbon released in coordination with the trixie release, and I suggest everyone drop wayland work until that's under control.
/my two cents

Once the x-session carbon release is out it will be much simpler to integrate any wayland work anyway.

Most stuff is already in place except for specific configs. I'll continue in the background but I'll reserve space on one of my machines for the carbon release cycle; alpha, beta, rc etc. I have a neat little old dell laptop (core i5, 16GB RAM) with BT that I can reformat as whatever I need is mostly backed up anyway - and windows 10 is still on it wasting space! Dual boot of course but the linux on it is getting long in the tooth.

johnraff · 2025-05-11 02:55:58

johnraff wrote:

gtk3dialog being "external" touches on what I was referring to about the icons, and a pending new dev discussion thread.
Anyway, for packages which don't need any special modification for BL how about we just clone the repo into our GitHub BL repo collection and build from that? Wouldn't that apply to xwwall too? If there turn out to be some changes needed for BL then we can put them on a dedicated local "carbon" branch, leaving your upstream repo clean.

EDIT This was meant to be a rhetorical question:
BTW Why clone repos into the BL collection at all? If upstream have already built and have orig & debian tarballs, why not just add them with reprepro?

Technically that would still satisfy Open Source requirements because the source is available in the tarballs, which people can download from the apt repo. But I think it's valuable for people to be able to browse the source in a git repo, view the commit history etc, and to know that our packages have been built from exactly the same source code that they have been browsing.

So I think it's good that we can guarantee that the code in our GitHub collection is what our packages are built from.

Last edited by johnraff (2025-06-01 05:14:45)

micko01 · 2025-05-11 11:19:43

johnraff wrote:

johnraff wrote:
gtk3dialog being "external" touches on what I was referring to about the icons, and a pending new dev discussion thread.
Anyway, for packages which don't need any special modification for BL how about we just clone the repo into our GitHub BL repo collection and build from that? Wouldn't that apply to xwwall too? If there turn out to be some changes needed for BL then we can put them on a dedicated local "carbon" branch, leaving your upstream repo clean.
BTW Why clone repos into the BL collection at all? If upstream have already built and have orig & debian tarballs, why not just add them with reprepro?
Technically that would still satisfy Open Source requirements because the source is available in the tarballs, which people can download from the apt repo. But I think it's valuable for people to be able to browse the source in a git repo, view the commit history etc, and to know that our packages have been built from exactly the same source code that they have been browsing.
So I think it's good that we can guarantee that the code in our GitHub collection is what our packages are built from.

Would probably be worth having a BL repo just for debian/

I have made a release of gtk3dialog - https://github.com/01micko/gtk3dialog/r … alog-0.1.2

wget https://github.com/01micko/gtk3dialog/archive/refs/tags/gtk3dialog-0.1.2.tar.gz

I built it and it's all good

There was a minor bug in the code but was an easy fix, which is why I bumped the version.

So here's my repo for gtk3dialog/debian/ - https://github.com/01micko/gtk3dialog-debian - which might be worthwhile putting in bunsen's github. Same will probably go for xwwall - which has a 'debian' branch which we'll see how that goes.

micko01 · 2025-05-11 12:00:37

^Ok, I've deleted the debian branch of xwwall and made it a separate repo. https://github.com/01micko/xwwall-debian

I've also updated and made a release of xwwall - https://github.com/01micko/xwwall/releases

I'm pretty much done! (for a week early, not bad - https://forums.bunsenlabs.org/viewtopic … 71#p143071 )

I should find a bit of time this week to tidy any loose ends.

hhh · 2025-05-11 14:30:41

johnraff wrote:

hhh wrote:
@johnraff, IMO we need a carbon Alpha ISO so everyone can be on the same page from the get-go.
...I would really like to see x-session carbon released in coordination with the trixie release, and I suggest everyone drop wayland work until that's under control.
Agreed.
My own VM Wayland test session is badly broken since a couple of weeks ago, but getting a nice clean X session ready will probably help.

Phew! There's always some ambiguity with web posts, I'm relieved my suggestion was taken in the right spirit!

hhh · 2025-05-11 15:26:36

johnraff wrote:

It looks as if the bluetooth metapackage needs two versions, for pulse and pipewire.

Why? We're not releasing both a pipewire/wireplumber and a pulseaudio version of Carbon, are we?

greenjeans · 2025-05-11 16:19:07

hhh wrote:

johnraff wrote:
hhh wrote:
@johnraff, IMO we need a carbon Alpha ISO so everyone can be on the same page from the get-go.
...I would really like to see x-session carbon released in coordination with the trixie release, and I suggest everyone drop wayland work until that's under control.
Agreed.
My own VM Wayland test session is badly broken since a couple of weeks ago, but getting a nice clean X session ready will probably help.
Phew! There's always some ambiguity with web posts, I'm relieved my suggestion was taken in the right spirit!

+1, great idea IMO. Forgive my temerity in posting again in a dev thread, but would also like to request that it be a hybrid-iso for ease of testing. My machines are stuffed full of build partitions, so it's really hard to clear space and I do 90% or better of my testing in a live-session anyway.

I've got a build of trixie myself that i'm already testing and reporting bugs from, and i'd be happy to do the same with Carbon if it would be helpful.

hhh · 2025-05-11 20:52:26

@greenjeans, we use Debian's live-build to produce our ISOs and we'll need to test the live session anyway (so, yes).

The more users testing, the better.

micko01 · 2025-05-11 22:52:00

@greenjeans I use Ventoy and have a 32GB USB stick with several ISO images on it including Boron and debian testing netinstall. They boot live for testing and install fine on real kit and you can install to a VM.

johnraff · 2025-05-12 03:19:38

johnraff wrote:

Anyway, for packages which don't need any special modification for BL how about we just clone the repo into our GitHub BL repo collection and build from that? Wouldn't that apply to xwwall too? If there turn out to be some changes needed for BL then we can put them on a dedicated local "carbon" branch, leaving your upstream repo clean.
...I think it's valuable for people to be able to browse the source in a git repo, view the commit history etc, and to know that our packages have been built from exactly the same source code that they have been browsing.

micko01 wrote:

Would probably be worth having a BL repo just for debian/
...So here's my repo for gtk3dialog/debian/ - https://github.com/01micko/gtk3dialog-debian - which might be worthwhile putting in bunsen's github. Same will probably go for xwwall - which has a 'debian' branch which we'll see how that goes.

micko01 wrote:

^Ok, I've deleted the debian branch of xwwall and made it a separate repo. https://github.com/01micko/xwwall-debian

Yeh, this wasn't really what I was thinking of to be honest. It would mean that users who want to browse the source code of the (eg xwwall) package that we ship would have to go to an external site (in this case yours). I was pushing for having all the code here in the BL collection. As I said above, it's not necessary for Open Source Principles or anything, just that it's more convenient for our users.

I am advocating cloning your xwwall repo, complete with debian/ since you've done all the work, forking a "carbon" branch and using the code there to build our package. In cases where upstream haven't made debian/ then we'd do that in our "carbon" branch, leaving "main" a clean copy of upstream.

That means that if you want to fix a bug or add a feature you can just go ahead and commit to your "main" branch on your GitHub, and the code here in BL will stay the same. Then we (either you or I could do it) sync the BL repo with yours (just a click), and the "carbon" branch is still unaffected. Finally, when we decide to release the new xwwall to BL users we update carbon by merging in your changes from main (usually quite simple), add a new stanza to debian/changelog (as maintainer you'll probably do that), build the new package, add it with reprepro and upload it to our server (for now I'll do those steps).

The important point is that regardless of what you do upstream the code here on BL is what our package has been built from.

Maybe I'm being too fussy?

I guess a separate Debian repo would work too but I'd still prefer to have a clone of the app code here in BL anyway, and it looks like more complication to juggle two separate repos for one package, instead of two branches.

If you want to maintain a debian/ packaging directory (a lot of people make a separate "debian" or "packaging" branch just for that directory) for general non-BL users then you can do that upstream, although the suite name "carbon" in d/changelog would be wrong for other distros.

johnraff · 2025-05-12 03:24:16

hhh wrote:

johnraff wrote:
It looks as if the bluetooth metapackage needs two versions, for pulse and pipewire.
Why? We're not releasing both a pipewire/wireplumber and a pulseaudio version of Carbon, are we?

No, that's true. How about people upgrading from Boron though? If they've installed bunsen-meta-bluetooth then they'll have the pulse package removed and pipewire added. As long as the rest of their system has been upgraded to pipewire I guess it should be OK just to edit the metapackage...

(Probably good to test at some point.)

hhh · 2025-05-12 13:37:29

johnraff wrote:

How about people upgrading from Boron though?

Good point, I hadn't thought of that. The switch to Pipewire will be in our Release Notes, though, and we can put together a walk-through for upgrading from Boron.

hhh · 2025-05-13 23:46:52

Saw this with today's kernel upgrade...

bishop@weyland-yutani:~$ sudo nala autopurge
[sudo] password for bishop: 
===========================================================================================
 Auto-Purging                                                                              
===========================================================================================
  Package:                      Version:                                            Size:  
  linux-image-6.12.22-amd64     6.12.22-1                                        111.6 MB  
                                                                                           
===========================================================================================
 Summary                                                                                   
===========================================================================================
 Auto-Purge 1 Packages                                                                     
                                                                                           
 Disk space to free  111.6 MB   
                                
Do you want to continue? [Y/n] 
Removing:   linux-image-6.12.22-amd64 (6.12.22-1)
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-6.12.22-amd64

Generating grub configuration file 

Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-6.12.27-amd64
Found initrd image: /boot/initrd.img-6.12.27-amd64
Found linux image: /boot/vmlinuz-6.12.25-amd64
Found initrd image: /boot/initrd.img-6.12.25-amd64
Warning: version_find_latest() is deprecated. Use version_sort() instead.
Warning: version_test_gt() is deprecated. Use version_sort() instead.
Warning: version_test_gt() is deprecated. Use version_sort() instead.
Warning: version_test_numeric() is deprecated. Use version_sort() instead.
Generating custom entry for: /boot/vmlinuz-6.12.27-amd64
Found initrd image: /boot/initrd.img-6.12.27-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Debian GNU/Linux trixie/sid on /dev/nvme0n1p3
Adding boot menu entry for UEFI Firmware Settings 
grub background_image is BL default, setting text colors
done

Purging configuration files for linux-image-6.12.22-amd64 (6.12.22-1) 
╭─────────────────────────────────────────────────────────────────────────────────────────╮
│✔ Running dpkg … ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100.0% • 0:00:00 • 3/3│
╰─────────────────────────────────────────────────────────────────────────────────────────╯

Notices:
  Warning: version_find_latest() is deprecated. Use version_sort() instead.
  Warning: version_test_gt() is deprecated. Use version_sort() instead.
  Warning: version_test_numeric() is deprecated. Use version_sort() instead.
  Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Finished Successfully
bishop@weyland-yutani:~$

Anything worth noting? Usually warnings can be ignored, but thought I'd ask.

I should have checked with apt before removing it, to see if it also spit out warnings. Nala has had a bug that I think has only been fixed with a recent Debian maintainer upgrade, so it might be a Nala issue only.

#141 2025-05-09 17:56:55

Re: Carbon Bugs

#142 2025-05-09 18:07:33

Re: Carbon Bugs

#143 2025-05-09 18:23:46

Re: Carbon Bugs

#144 2025-05-10 03:12:37

Re: Carbon Bugs

#145 2025-05-10 04:04:59

Re: Carbon Bugs

#146 2025-05-10 08:20:42

Re: Carbon Bugs

#147 2025-05-10 08:46:13

Re: Carbon Bugs

#148 2025-05-10 22:04:56

Re: Carbon Bugs

#149 2025-05-11 02:55:58

Re: Carbon Bugs

#150 2025-05-11 11:19:43

Re: Carbon Bugs

#151 2025-05-11 12:00:37

Re: Carbon Bugs

#152 2025-05-11 14:30:41

Re: Carbon Bugs

#153 2025-05-11 15:26:36

Re: Carbon Bugs

#154 2025-05-11 16:19:07

Re: Carbon Bugs

#155 2025-05-11 20:52:26

Re: Carbon Bugs

#156 2025-05-11 22:52:00

Re: Carbon Bugs

#157 2025-05-12 03:19:38

Re: Carbon Bugs

#158 2025-05-12 03:24:16

Re: Carbon Bugs

#159 2025-05-12 13:37:29

Re: Carbon Bugs

#160 2025-05-13 23:46:52

Re: Carbon Bugs

Board footer