carbon-wayland

johnraff · 2024-07-11 07:39:50

^OK I'd been putting off learning how to write those "JS based rules files", but will have to do it soonish...

johnraff · 2024-07-11 07:59:55

@Mick01 fast work (as usual)!!

micko01 wrote:

- missing package from trixie - polkitd-pkla

The axe fell. Nothing we can do except take it out of the package lists and learn those JS files.

- no os-release

bunsen-os-release is not in the "base" package list. You could try installing it.

- had to run bl-user-setup manually

I can't say I'm surprised to be honest. I know nothing as yet about the Wayland session handling, but bunsenlabs-session as set up in bunsen-configs depends very much on things with X in their name...

# force copy pkgs-recs-wbase and pkgs-norecs-wbase over pkgs-recs-base and pkgs-norecs-base

Since you've forked your own version of the netinstall script, why don't you either
1) edit pkgs-recs-base and pkgs-norecs-base yourself
or
2) edit the main install script at lines 257 & 258 https://github.com/01micko/bunsen-netin … stall#L257

Probably easier to do 1) right now. Eventually we'll have to decide how the Wayland/X choice will be handled.

Then comment out polkitd-pkla in pkgs-norecs-base

You could do that too at your end, save users having to think about it.

@johnraff - what logs do you want so we can debug this?

"This" being the failure of bl-user-setup to run? I think it will need a complete rewrite of the bunsenlabs-session, based on a grasp of how user sessions are handled in Wayland.

Bunsen-configs is going to need taking apart and putting back together eventually, possibly split into several packages.
Meanwhile it might be easier to rely on the netinstall script to set things up. You can put a user config tree in the "userfiles" directory and it will be installed to ~/ towards the end of the install script.

micko01 · 2024-07-12 03:33:09

johnraff wrote:

@Mick01 fast work (as usual)!!
micko01 wrote:
- missing package from trixie - polkitd-pkla
The axe fell. Nothing we can do except take it out of the package lists and learn those JS files.

I did a bit of webdev years ago with JS and PHP so hopefully I can lend a hand. Sounds like polkitd-pkla has been on it's death bed for a while.

- no os-release
bunsen-os-release is not in the "base" package list. You could try installing it.
- had to run bl-user-setup manually
I can't say I'm surprised to be honest. I know nothing as yet about the Wayland session handling, but bunsenlabs-session as set up in bunsen-configs depends very much on things with X in their name...

I did another VM test later with os-release installed and 'debian' still showed up in the boot screen. Further investigation is required but I'll keep you informed. I checked the logs about that too and there was something funny going on. As said, needs investigating.

# force copy pkgs-recs-wbase and pkgs-norecs-wbase over pkgs-recs-base and pkgs-norecs-base
Since you've forked your own version of the netinstall script, why don't you either
1) edit pkgs-recs-base and pkgs-norecs-base yourself
or
2) edit the main install script at lines 257 & 258 https://github.com/01micko/bunsen-netin … stall#L257
Probably easier to do 1) right now. Eventually we'll have to decide how the Wayland/X choice will be handled.
Then comment out polkitd-pkla in pkgs-norecs-base
You could do that too at your end, save users having to think about it.

Done - with caveat.

where you have commented the choices (# package list selection dialogue temporarily disabled:), below that I have added 'wbase' files that are copied over the 'base' files - actually it would also work for 'full' and 'lite' - later .

# temporary workaround to install wayland (wbase)

bigmsg "Do you want to install the wayland base package? (must type \"yes\" if so...)"
read answer
case $answer in
    yes)for i in *-base
        do
	    cp -f ${i/base/}wbase $i
	done
	log "Using wayland install"
	msg "Using wayland install"
      ;;
      *)log "Using standard install"
	msg "Using standard install"
      ;;
esac

@johnraff - what logs do you want so we can debug this?
"This" being the failure of bl-user-setup to run? I think it will need a complete rewrite of the bunsenlabs-session, based on a grasp of how user sessions are handled in Wayland.
Bunsen-configs is going to need taking apart and putting back together eventually, possibly split into several packages.
Meanwhile it might be easier to rely on the netinstall script to set things up. You can put a user config tree in the "userfiles" directory and it will be installed to ~/ towards the end of the install script.

I have avoided looking at bunsenlabs-session until last night.

There are many issues with it for wayland - similar ones in the user autostart, but one problem at a time.

There is no way to tell what session (W or X) we are about to start because obviously it hasn't started so envars that we use in a graphical environment to distinguish which graphical server we are using are not available.

I propose that we let bunsenlabs-session accept one, and only 1, argument; something like '-w', 'W' or whatever to tell the script we are about to launch a wayland session, or if no arg X. Any other arg and we throw the error if ithe arg isn't 'W' (or whatever we choose).

Another way is to symlink busenlabs-wayland-session -> bunsenlabs-session and put in a 'who called here' condition based on $0.

Then we can filter stuff as needed and keep both X and wayland happy while still setting up our needed stuff.

johnraff · 2024-07-12 05:57:16

micko01 wrote:

...learn those JS files.
I did a bit of webdev years ago with JS and PHP so hopefully I can lend a hand.

My first taste of "programming" was also PHP on web pages, also years ago, but I haven't touched it since entering the Linux world and shell scripts. Javascript, I never got beyond the absolute basics so a bit of help might well be nice to have.
I'll have a look at what apps like Thunar have done - they used to ship a pkla file.

- no os-release
bunsen-os-release is not in the "base" package list. You could try installing it.
I did another VM test later with os-release installed and 'debian' still showed up in the boot screen. Further investigation is required but I'll keep you informed.

Up to now, boot screen entry goes from /etc/default/grub:

GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`

So if you could run lsb_release -i -s 2> /dev/null it would give us a hint. Should return 'Bunsenlabs'.
Installing bunsen-os-release should have triggered sudo update grub but you could run that one more time just in case.
Ah, the package lsb-release is only a Recommends of bunsen-os-release so maybe you need to install that too.

# force copy pkgs-recs-wbase and pkgs-norecs-wbase over pkgs-recs-base and pkgs-norecs-base
Eventually we'll have to decide how the Wayland/X choice will be handled.
Then comment out polkitd-pkla in pkgs-norecs-base
You could do that too at your end, save users having to think about it.
Done - with caveat.
where you have commented the choices (
# package list selection dialogue temporarily disabled:
), below that I have added 'wbase' files that are copied over the 'base' files - actually it would also work for 'full' and 'lite' - later .
# temporary workaround to install wayland (wbase)

bigmsg "Do you want to install the wayland base package? (must type \"yes\" if so...)"
read answer
case $answer in
    yes)for i in *-base
        do
	    cp -f ${i/base/}wbase $i
	done
	log "Using wayland install"
	msg "Using wayland install"
      ;;
      *)log "Using standard install"
	msg "Using standard install"
      ;;
esac

That will work, yes.
I think, just because..., I'd feel happier keeping all the package files intact and setting the variables instead, so if your code, slightly adapted, went in line 260 of 'install', like this:

# temporary override, use "base" package list:
pkgs_norecs_file=pkgs-norecs-base
pkgs_recs_file=pkgs-recs-base
bigmsg "Installing the minimal \"base\" package list"
# this is line 260
# temporary workaround to install wayland (wbase)

bigmsg "Do you want to install the wayland base package? (must type \"yes\" if so...)"
read answer
case $answer in
    yes)
        pkgs_norecs_file=pkgs-norecs-wbase
        pkgs_recs_file=pkgs-recs-wbase
	log "Using wayland install"
	msg "Using wayland install"
      ;;
      *)log "Using standard install"
	msg "Using standard install"
      ;;
esac
for i in "$pkgs_norecs_file" "$pkgs_recs_file"
do
    [[ -r $i ]] || giveup "Cannot read package list $i" 1
done

It might work OK?

- had to run bl-user-setup manually
I can't say I'm surprised to be honest. I know nothing as yet about the Wayland session handling, but bunsenlabs-session as set up in bunsen-configs depends very much on things with X in their name...

The whole xsession as Debian (and hence BL) run it is a user session, ending up running bl-user-setup and the openbox-style ~/config/bunsen/autostart. The big question is what happens under Wayland, and how much it depends on which display manager is being used.

I did some websearching this morning, got no clear answers, but some links: https://forums.bunsenlabs.org/viewtopic … 64#p135964

"This" being the failure of bl-user-setup to run? I think it will need a complete rewrite of the bunsenlabs-session, based on a grasp of how user sessions are handled in Wayland.
I have avoided looking at bunsenlabs-session until last night.
There are many issues with it for wayland - similar ones in the user autostart, but one problem at a time.

I think they are the same thing. The BL session is modelled on what other small DEs like lxde and xfce do - we put a desktop file in /usr/share/xsessions which runs bunsenlabs-session, bl-user-setup and ultimately openbox (or some other WM). So does bunsenlabs-session even get run in a Wayland session?

I propose that we let bunsenlabs-session accept one, and only 1, argument; something like '-w', 'W' or whatever to tell the script we are about to launch a wayland session, or if no arg X. Any other arg and we throw the error if ithe arg isn't 'W' (or whatever we choose).
Another way is to symlink busenlabs-wayland-session -> bunsenlabs-session and put in a 'who called here' condition based on $0.
Then we can filter stuff as needed and keep both X and wayland happy while still setting up our needed stuff.

OK so we can create a second desktop file which invokes bunsenlabs-session -w. I think that should work, the symlink way too, though I wonder if there's any benefit over passing an argument. Let's have a look at what other people are doing (if any).

The thing with bunsen-configs is that it's setting the xsession up, setting up the bl-* alternative apps, various system tweaks and bug workarounds, as well as bl-user-setup and the skel directory trees. It's a monster that really needs splitting up - that would make creating Wayland versions easier too I think.

micko01 wrote:

one problem at a time

Last edited by johnraff (2024-07-12 06:00:21)

micko01 · 2024-07-12 06:42:15

Just a quick reply, have stuff to do.

I'll take on board your recommendations.

* use variable instead of force-copy in install
* I'm going the symlink way for session - less code (and tests seem to work out of tree with an exit at appropriate place)
* moving bunsen-os-release to pkgs-recs-wbase
* have created a bunsenlabs-wayland.desktop like this: (goes to /usr/share/wayland-sessions)

[Desktop Entry]
Name=BunsenLabs
Comment=Log in to a BunsenLabs wayland session
Exec=/usr/bin/bunsenlabs-wayland-session
TryExec=/usr/bin/bunsenlabs-wayland-session
Icon=bunsenlabs
Type=Application

I have created 'staging' branches of netinstall and configs - you can see them on github but not pushed yet - a bit later.

johnraff · 2024-07-12 08:23:59

I have to go now too, but thanks!

unklar · 2024-07-12 08:26:23

micko01 wrote:

@unklar you can try it right now if you do a trixie netinstall and get the bunsen-netinstall from my github:
wget  https://github.com/01micko/bunsen-netinstall/archive/refs/heads/carbon-13.tar.gz
# force copy pkgs-recs-wbase and pkgs-norecs-wbase over pkgs-recs-base and pkgs-norecs-base
Then comment out polkitd-pkla in pkgs-norecs-base
Run ./install as normal

^ I had to create a free partition first

Congratulations, @micko01, your script ran flawlessly and I was greeted by your wonderful nwg-hello login screen. Thank you!

After that I had the labwc original state.
After rough settings it looks like this:

https://postimg.cc/jC9C1Vnj

Now I have to see how I can get a BL desktop. I don't know at the moment.

Last edited by unklar (2024-07-12 08:28:11)

micko01 · 2024-07-12 09:44:38

@unklar great work! Why don't you use a VM?

sudo apt install qemu-system -y

Here are my helper scripts, work flawlessly

Just make a qemu (or whatever dir in $HOME) and run the first script then the second, I'll add demos too.

# img-make

#!/bin/sh

## edit as you see fit, say up the disk size if you want, change the image name

qemu-img create -f qcow2 c13w-$(date +%Y%m%d).img 5000M

# rqemu.sh

#!/bin/sh
modprobe kvm-intel >/dev/null 2>&1
modprobe kvm-amd >/dev/null 2>&1
VGA_TYPE=${VGA_TYPE:-virtio}
REDIR_PORT=${REDIR_PORT:-3222}
SND_TYPE=${SND_TYPE:-AC97}
USB_TYPE=${SND_TYPE:-qemu-xhci}
MEM=${MEM:-4096}
QEMU=qemu-system-x86_64
! type $QEMU > /dev/null && QEMU=qemu-system-x86
! type $QEMU > /dev/null && QEMU=qemu-system-i386
! type $QEMU > /dev/null && echo "Sorry I can't find qemu" && exit
[ "$REDIR" ] && REDIR="-redir tcp:$REDIR_PORT::22"

usage() {
	echo "$0 [-f (for full-screen), -iso some_distro.iso -img some_qcow2.img]"
	exit
}

#parameters
while [ $# -gt 0 ]; do
    case "$1" in
        -iso) shift; CD="$1";; # if booting iso
        -img) shift; QCOW=$1 ;;  # qcow2 image
        -f) FSCR='-full-screen' ;;
        -h)usage;;
        *) echo "Invalid argument: $1";usage;;
    esac
    shift
done

if [ -n "$CD" ];then 
	$QEMU -display sdl -vga $VGA_TYPE -enable-kvm -device $SND_TYPE -m $MEM $REDIR -drive file=$QCOW $FSCR -cdrom $CD -boot order=d 
else
	$QEMU -display sdl -vga $VGA_TYPE -enable-kvm -device $SND_TYPE -device $USB_TYPE -m $MEM $REDIR -drive file=$QCOW $FSCR
fi

To create the qcow2 image just run the img-make script - adds today's date.

# boot cd image command

./rqemu.sh -img c13w-20240712.img -iso debian-testing-amd64-netinst.iso

Once the debian (or whatever you use) is done then you jusr drop the '-iso' option.

./rqemu.sh -img c13w-20240712.img

Been using those scripts for about 2 years with minimal changes.

micko01 · 2024-07-12 11:18:24

Latest changes work as expected!

Special thanks to @johnraff , @unklar , @hhh and of course @malm !!! Wouldn't be possible without open source!

BunsenLabs Carbon Wayland (YouTube)

unklar · 2024-07-12 12:30:40

@micko01

Thanks, I liquidated QEMU with KDE-Plasma last year. Since then I have not reinstalled it because I have 'too many' hard disks.

unklar · 2024-07-12 18:31:07

Bunsenlab-Wayland after bl-setup
Thank you micko01
unfortunately I have an american keyboard layout at the moment

altman · 2024-07-12 19:20:32

Weird, just happenned to find this video on YT today;

https://www.youtube.com/watch?v=SwC3Hpf4rr4

https://www.youtube.com/watch?v=xNCsFLc2Ysk

Last edited by altman (2024-07-12 19:25:41)

johnraff · 2024-07-13 02:47:38

micko01 wrote:

* moving bunsen-os-release to pkgs-recs-wbase

Yes that's a reasonable way to handle it. Alternative would be to leave it in pkgs-norecs-wbase and add lsb-release to the list. Systemd is another Recommends of bunsen-os-release (sorry I forget right now why it was added) which would be brought in if installed with recommends. Probably most users will be installing systemd anyway, but there are a few who try to set up with other init systems.

Most of the BL packages' dependencies are Recommends instead of hard Depends. This is so that if users don't need a certain functionality, or have found another app that does the job better for them, they aren't obliged to install that dependency. But it means people making install lists have to be more careful.

In the -full and -lite netinstall package lists, all the BL packages go in the "with recommends" lists, but in -base the idea is to get the install as small as possible.

Bearded_Blunder · 2024-07-13 07:02:25

I had a look at those JS polkit rules files a couple of releases back when I was having to compile Polkit from Experimental (with a minor patch) to make Debian function with sysvinit, they don't look difficult as such, more a bit tedious... Though I dodged it at the time, since I decided to bypass the issue using lxqt-sudo.

That dodge worked then, for X sessions, but isn't going to long-term with Wayland incoming.

If I wasn't snowed under with other things I'd take a look at some re-writing, using rules from other things as an example..

As I said, they look more tedious to redo than actually difficult.

Last edited by Bearded_Blunder (2024-07-13 07:08:33)

unklar · 2024-07-13 08:01:03

I was able to solve the problem with the keyboard layout in ~/.config/labwc/environment with

XKB_DEFAULT_LAYOUT=de

solve the problem.

in the bl-setup I had

blob
conky
dmenu
geany
jgmenu
nitrogen
openbox
terminator
tint2

deselected (by feeling).

With GTK-Settings (nwg-look) the change of the settings was without problems.

In the meantime I replaced lxterminal with xfce4-terminal and foot.

Since I never got along with dillo, I installed firefox-esr. Also keepassxc with the wonderful KeePassXC browser add-on for easy login to websites.

Last edited by unklar (2024-07-13 08:07:14)

unklar · 2024-07-13 08:17:02

I have os-release here:

ls -l /etc/os-release*
lrwxrwxrwx 1 root root 21  6. Jun 00:35 /etc/os-release -> ../usr/lib/os-release

ls -l /usr/lib/os-release*
lrwxrwxrwx 1 root root  17 11. Jul 16:44 /usr/lib/os-release -> os-release.bunsen
-rw-r--r-- 1 root root 399 25. Jun 07:41 /usr/lib/os-release.bunsen
-rw-r--r-- 1 root root 222  6. Jun 00:35 /usr/lib/os-release.bunsen-orig

micko01 · 2024-07-13 21:55:09

Notice

The netinstall for wayland will be in a broken state for the several hours today.

I don't expect to have it up until Sun 14 Jul 2024 05:00:00 UTC.

Reason: conflict with the official bunsen-configs-base

Apologies for inconvenience.

johnraff · 2024-07-14 01:08:48

^Micko you seem to have this this well in hand.

Last edited by johnraff (2024-07-14 02:01:49)

micko01 · 2024-07-14 02:59:55

Doing a netinstall test now. Won't take long

micko01 · 2024-07-14 04:30:52

Posting from Dillo in a VM right now

Desktop came up perfectly!

Thanks every one for the help!

Sun Jul 14 04:30:06 UTC 2024 - half an hour early!

#21 2024-07-11 07:39:50

Re: carbon-wayland

#22 2024-07-11 07:59:55

Re: carbon-wayland

#23 2024-07-12 03:33:09

Re: carbon-wayland

#24 2024-07-12 05:57:16

Re: carbon-wayland

#25 2024-07-12 06:42:15

Re: carbon-wayland

#26 2024-07-12 08:23:59

Re: carbon-wayland

#27 2024-07-12 08:26:23

Re: carbon-wayland

#28 2024-07-12 09:44:38

Re: carbon-wayland

#29 2024-07-12 11:18:24

Re: carbon-wayland

#30 2024-07-12 12:30:40

Re: carbon-wayland

#31 2024-07-12 18:31:07

Re: carbon-wayland

#32 2024-07-12 19:20:32

Re: carbon-wayland

#33 2024-07-13 02:47:38

Re: carbon-wayland

#34 2024-07-13 07:02:25

Re: carbon-wayland

#35 2024-07-13 08:01:03

Re: carbon-wayland

#36 2024-07-13 08:17:02

Re: carbon-wayland

#37 2024-07-13 21:55:09

Re: carbon-wayland

Notice

#38 2024-07-14 01:08:48

Re: carbon-wayland

#39 2024-07-14 02:59:55

Re: carbon-wayland

#40 2024-07-14 04:30:52

Re: carbon-wayland

Board footer