wayland meta issue

[01micko]

Just a TODO list for wayland stuffs

• link for bunsenlabs-session-wayland - bunsenlabs-session-wayland -> bunsenlabs-session
• line 15 in bunsen-configs-[base|lite].postinst should be GREETD="/etc/greetd"as inbunsen-configs.postinst` or was there a reason for the omission?
  

  bunsen-configs/debian/bunsen-configs-base.postinst

  Line 14 in 29f2893

  MAN1='/usr/share/man/man1'

• Where to put our wayland session desktop file? It has to end up in /usr/share/wayland-sessions
• Populate wayland/skel - (my job) - then figure out how to incorporate it - I'm guessing @johnraff you have an idea for that.
• How to handle the dependency on bunsen-configs | bunsen-configs-lite | bunsen-configs-base ?

If/when I think of more I'll add to this list.

[johnraff]

link for bunsenlabs-session-wayland - bunsenlabs-session-wayland -> bunsenlabs-session

That will go in the addon package bunsen-configs-wayland. (I don't know yet if we will need separate lite/base package variants, but I'm hoping not.) We can either install a physical symlink - there are a few already in bunsen-configs - or put a line in debian/bunsen-configs-wayland.links: /usr/bin/bunsenlabs-session /usr/bin/bunsenlabs-wayland-session Maybe the latter?

---

line 15 in bunsen-configs-[base|lite].postinst should be GREETD="/etc/greetd"as in bunsen-configs.postinst`

It should indeed - thanks for catching the omission! Now fixed and pushed.
That section still needs attention though - lintian revealed a security issue with a recursive permissions change over a whole directory:

W: bunsen-configs: recursive-privilege-change "chown -R" [postinst:41]
N:
N: The named maintainer script appears to call chmod or chown with a
N: --recursive/-R argument, or it uses find(1) with similar intent.
N:
N: All such uses are vulnerable to hardlink attacks on mainline (i.e.
N: non-Debian) kernels that do not set fs.protected_hardlinks=1.
N:
N: The security risk arises when a non-privileged user set links to files
N: they do not own, such as such as /etc/shadow or files in /var/lib/dpkg/. A
N: superuser's recursive call to chown or chmod on behalf of a role user
N: account would then modify the non-owned files in ways that allow the
N: non-privileged user to manipulate them later.
N:
N: There are several ways to mitigate the issue in maintainer scripts:
N:
N: - For a static role user, please call chown at build time
N: and not during the installation.
N: - If that is too complicated, use runuser(1) in the
N: relevant build parts to create files with correct ownership.
N: - Given a static list of files to change, use non-recursive calls
N: for each file. (Please do not generate the list with find.)
N:
N: Please refer to Bug#895597, Bug#889060, Bug#889488, and the runuser(1)
N: manual page for details.

Do we know in advance the names of the files whose perms need changing? If so then this:

• Given a static list of files to change, use non-recursive calls for each file.

looks like the way to go.

---

Where to put our wayland session desktop file? It has to end up in /usr/share/wayland-sessions

As with the bunsenlabs-session-wayland symlink, it will be installed by the (as yet nonexistent) package bunsen-configs-wayland. It should not be installed by bunsen-configs because that would cause a non-functioning boot menu item to appear for users without bunsen-configs-wayland.

As for its location in the source tree, I'm thinking of wayland/ as analagous with the root directory of the full source tree, so how about putting the .desktop file in wayland/ ? Its installed location will be determined by a line in debian/bunsen-configs-wayland.install so it could in principle go anywhere in the source.

The final organization of files in the source tree can be changed if it seems desirable for some reason. There are quite a lot of them though!

NOTE bunsen-configs-wayland will be an addon package that depends on bunsen-configs to provide most of the necessary files. Only the extra wayland-only files will be shipped in bunsen-configs-wayland.

---

Populate wayland/skel - (my job) - then figure out how to incorporate it - I'm guessing @johnraff you have an idea for that.

Yes, the files in wayland/skel can be installed by bunsen-configs-wayland into /usr/share/bunsen/skel, just like those from bunsen-configs. I don't see there being any files installed by both bunsen-configs-wayland and bunsen-configs?

[01micko]

I don't know yet if we will need separate lite/base package variants, but I'm hoping not.

Won't at all methinks. A meta package and a netinstall should both be fine dependent on any one of the parent bunsen-configs*

We can either install a physical symlink - there are a few already in bunsen-configs - or put a line in debian/bunsen-configs-wayland.links: /usr/bin/bunsenlabs-session /usr/bin/bunsenlabs-wayland-session Maybe the latter?

I prefer the latter.

---

line 15 in bunsen-configs-[base|lite].postinst should be GREETD="/etc/greetd"as in bunsen-configs.postinst

That section still needs attention though - lintian revealed a security issue with a recursive permissions change over a whole directory:

Right: should be enough to do the following:

    if [ -d "$GREETD" ] && id _greetd >/dev/null 2>&1
    then
        chown  _greetd:_greetd "$GREETD/greetd.conf"
        usermod -a -G video _greetd
    fi

or even a wildcard should do it: chown _greetd:_greetd "$GREETD/* but

Given a static list of files to change, use non-recursive calls for each file.

"each file" - probably forbidden.

IIRC - we have to do something similar with /var/cache/nwg-hello/cache.json too.

---

As with the bunsenlabs-session-wayland symlink, it will be installed by the (as yet nonexistent) package bunsen-configs-wayland. It should not be installed by bunsen-configs because that would cause a non-functioning boot menu item to appear for users without bunsen-configs-wayland.

And we don't want that. Ok, so I'll think of something for that.

The final organization of files in the source tree can be changed if it seems desirable for some reason. There are quite a lot of them though!

No need for that. Everthing wayland can go in wayland/ and the debian/bunsen-configs-wayland* files can sort it all out.

NOTE bunsen-configs-wayland will be an addon package that depends on bunsen-configs to provide most of the necessary files. Only the extra wayland-only files will be shipped in bunsen-configs-wayland.

Yes, that makes sense.

---

Yes, the files in wayland/skel can be installed by bunsen-configs-wayland into /usr/share/bunsen/skel, just like those from bunsen-configs. I don't see there being any files installed by both bunsen-configs-wayland and bunsen-configs?

Yes /usr/shar/bunsen/skel is the target - no problem. All files will have unique names, so no conflicts with parents. Happy children!

[johnraff]

line 15 in bunsen-configs-[base|lite].postinst should be GREETD="/etc/greetd"as in bunsen-configs.postinst
That section still needs attention though - lintian revealed a security issue with a recursive permissions change over a whole directory:
Right: should be enough to do the following:

    if [ -d "$GREETD" ] && id _greetd >/dev/null 2>&1
    then
        chown  _greetd:_greetd "$GREETD/greetd.conf"
        usermod -a -G video _greetd
    fi

Sure, if greetd.conf is the only file that concerns us, that should be fine.

or even a wildcard should do it: chown _greetd:_greetd "$GREETD/* but

Given a static list of files to change, use non-recursive calls for each file.

"each file" - probably forbidden.

A wild card is effectively the same as the -R chown option. I think the issue is that arbitary files will have their permissions changed, so we need to explicitly name them.

IIRC - we have to do something similar with /var/cache/nwg-hello/cache.json too.

Yes I remember having to do that so the greeter could remember the previous login.
nwg-piotr/nwg-hello#16 (comment)

As with the bunsenlabs-session-wayland symlink, it will be installed by the (as yet nonexistent) package bunsen-configs-wayland. It should not be installed by bunsen-configs because that would cause a non-functioning boot menu item to appear for users without bunsen-configs-wayland.

And we don't want that. Ok, so I'll think of something for that.

I think it's OK. Let bunsen-configs-wayland install bunsenlabs-wayland.desktop in /usr/share/wayland-sessions. The file can go in wayland/ in the source tree.

The final organization of files in the source tree can be changed if it seems desirable for some reason. There are quite a lot of them though!
No need for that. Everthing wayland can go in wayland/ and the debian/bunsen-configs-wayland* files can sort it all out.

That's what I thought.

[johnraff]

line 15 in bunsen-configs-[base|lite].postinst should be GREETD="/etc/greetd"as in bunsen-configs.postinst
That section still needs attention though - lintian revealed a security issue with a recursive permissions change over a whole directory:
Right: should be enough to do the following:

    if [ -d "$GREETD" ] && id _greetd >/dev/null 2>&1
    then
        chown  _greetd:_greetd "$GREETD/greetd.conf"
        usermod -a -G video _greetd
    fi

Sure, if greetd.conf is the only file that concerns us, that should be fine.

IIRC - we have to do something similar with /var/cache/nwg-hello/cache.json too.

Yes I remember having to do that so the greeter could remember the previous login. nwg-piotr/nwg-hello#16 (comment)

In fact, we ought to be testing for the existence of the file - not just the directory - greetd.conf before trying to operate on it. And if bunsen-configs happens to be installed before greetd then the file won't exist. Since greetd isn't a dependency of bunsen-configs (has no reason to be) then that isn't guaranteed at all. We need to think a bit more about this - at least move that postinst code from bunsen-configs to bunsen-configs-wayland and make greetd a Recommend of bunsen-configs-wayland. (It doesn't have to be a hard Depend because LightDM is an alternative.)

The same all applies to /var/cache/nwg-hello/cache.json too. Actually I don't know if that file is installed at all or created on the fly when running nwg-hello.

Ideally the Debian package maintainers of greetd and nwg-hello should handle these file permissions rather than us. Maybe that will happen in future releases?

[01micko]

^I was thinking that. And nwg-hello.

Actually I don't know if that file is installed at all or created on the fly when running nwg-hello.

I checked the package, and it is installed by the package.

The thing is, we are the ones who discovered these things, well you for nwg-hello cache and @nwg-piotr about the greetd.conf file.

About /etc/greetd/greetd.conf it is not shipped, it has to be created so it's not overwritten on upgrade. If you edit the original /etc/greetd/config.toml it works but I don't want to take the chance that it won't be overwritten. The debian maintainers can't know what greeter we will use for greetd so we have to handle that.

Since nwg-hwllo does have hard dependency on greetd then perhaps a bug should be filed with debian regarding the ownership of /var/cache/nwg-hello/cache.json

[johnraff]

About greetd.conf, I was forgetting that it doesn't come with greetd, but as you say, has to be created. Presumably it will be installed by bunsen-configs-wayland, in which case it's our responsibility and no worries about whether greetd was previously installed or not. Still probably good practice to do a test for its existence before chowning it in .postinst though.

(/var/cache/nwg-hello/cache.json)

And nwg-hello.

Actually I don't know if that file is installed at all or created on the fly when running nwg-hello.

I checked the package, and it is installed by the package.
nwg-hwllo does have hard dependency on greetd

In that case, as you say, it sounds as if nwg-hello should apply the right permissions to cache.json.
Sounds like a Debian issue rather than upstream, since it's Debian who set the daemon name to _greetd.
If there's no sign of movement in the next month or two then yes maybe we should file a bug.

[01micko]

About greetd.conf, I was forgetting that it doesn't come with greetd, but as you say, has to be created. Presumably it will be installed by bunsen-configs-wayland, in which case it's our responsibility and no worries about whether greetd was previously installed or not. Still probably good practice to do a test for its existence before chowning it in .postinst though.

My emphasis added.

By that rationale, we should remove the greetd stuffs from bunsen-configs[-lite|-base].postinst and create a postinst for bunsen-configs-wayland.postinst. Makes sense anyway.

---

An aside: how in debian/control should we handle Depends: field when it can depend on bunsen-configs, bunsenconfigs-lite, bunsenconfigs-base? I'm note too concerned with the syntax, I believe its something like:

some_ dep, some_other, dep0 | dep1 | dep2

How does dpkg actually handle that at install time? Does user get a choice in the install process?

[johnraff]

About greetd.conf, I was forgetting that it doesn't come with greetd, but as you say, has to be created. Presumably it will be installed by bunsen-configs-wayland, in which case it's our responsibility and no worries about whether greetd was previously installed or not. Still probably good practice to do a test for its existence before chowning it in .postinst though.

My emphasis added.

By that rationale, we should remove the greetd stuffs from bunsen-configs[-lite|-base].postinst and create a postinst for bunsen-configs-wayland.postinst. Makes sense anyway.

Yes, good question. I don't have much time today, but please let me think about that... I seem to remember there might have been a reason to put the greetd stuff in bunsen-configs & friends.

---

An aside: how in debian/control should we handle Depends: field when it can depend on bunsen-configs, bunsenconfigs-lite, bunsenconfigs-base? I'm note too concerned with the syntax, I believe its something like:

some_ dep, some_other, dep0 | dep1 | dep2

Looks right.

How does dpkg actually handle that at install time? Does user get a choice in the install process?

No user interaction. I think dpkg will check if any of the three is installed, and if not will install the first in the list.

[johnraff]

About greetd.conf, I was forgetting that it doesn't come with greetd, but as you say, has to be created. Presumably it will be installed by bunsen-configs-wayland, in which case it's our responsibility and no worries about whether greetd was previously installed or not. Still probably good practice to do a test for its existence before chowning it in .postinst though.

By that rationale, we should remove the greetd stuffs from bunsen-configs[-lite|-base].postinst and create a postinst for bunsen-configs-wayland.postinst. Makes sense anyway.

Yes, good question. I don't have much time today, but please let me think about that... I seem to remember there might have been a reason to put the greetd stuff in bunsen-configs & friends.

Yes, I was a bit careless above - it looks at first as if there's no need for greetd configs in the Carbon Xorg system, but what I was thinking is: we don't want to have to switch between Display Managers when installing bunsen-configs-wayland on top of bunsen-configs. In fact I'm not sure how changing between LightDM and greetd-cage-nwg-hello could even be done on the fly. https://forums.bunsenlabs.org/viewtopic.php?pid=136436#p136436

So I think we'll have to choose eventually one of those two options for Carbon, and make it the default for both Xorg and Wayland. So for now I wanted to have the config files for both options available in bunsen-configs. A couple of text files don't add much bloat.

If it looks possible, I'd like to stay with LightDM even for launching Wayland sessions because it's better looking than nwg-hello, has more flexibility and the interface works a bit better. But if the annoyances prove unfixable* and we have to use greetd and friends, that option can be made available now to make things smoother down the road.

*) The 1s delay in startup script helps a lot with LightDM.

[01micko]

Yes, I was a bit careless above - it looks at first as if there's no need for greetd configs in the Carbon Xorg system, but what I was thinking is: we don't want to have to switch between Display Managers when installing bunsen-configs-wayland on top of bunsen-configs. In fact I'm not sure how changing between LightDM and greetd-cage-nwg-hello could even be done on the fly. https://forums.bunsenlabs.org/viewtopic.php?pid=136436#p136436

Changing is manual and painful! Done it a few times but can't recall the exact commands but pretty much disable lightdm service, enable greetd service, reboot and hope for the best! I know my way round different TTY's so that's partly why I didn't use cage to begin with because the TTY support was rather new.

So I think we'll have to choose eventually one of those two options for Carbon, and make it the default for both Xorg and Wayland. So for now I wanted to have the config files for both options available in bunsen-configs. A couple of text files don't add much bloat.

That's fair. And I do hope we can make everything get along with lightdm.

If it looks possible, I'd like to stay with LightDM even for launching Wayland sessions because it's better looking than nwg-hello, has more flexibility and the interface works a bit better. But if the annoyances prove unfixable* and we have to use greetd and friends, that option can be made available now to make things smoother down the road.

I'm sure we'll figure it out. I have a few bare metal test beds (including the troublesome HP) so one way or another I think we'll get lightdm to work in 99.9% of cases.

*) The 1s delay in startup script helps a lot with LightDM.

Wouldn't matter if was 2 so long as it works.

[johnraff]

That pesky double-cursor thing doesn't seem to be LightDM - I got it today on a nwg-hello window. Probably qemu.

[01micko]

Never seen that, maybe a graphics driver issue? What native machine you using?

[01micko]

Deleted the proposed fixes for yaru/adwaita focus bug, the CSS breaks the rubberband. I'm afraid the CSS has to be fixed at the base level but I can't figure it out :(

[hhhorb]

^ As you gents know, I've been dealing with other things. But...

What fix is this? I saw briefly on the forums that there is a particular focus issue for a particular instance, but has anyone filed a bug with the Ubuntu Yaru team?

The major reason I proposed using Yaru as the default theme, instead of us hacking a theme via Oomox or hacking another theme, was that Ubuntu has major resources and an astronomical user base, while we're a small team of eager, well informed hobbyists (no offense).

So let's file a bug first, and we can hack this issue later if nothing happens upstream.

[01micko]

^Of course you are 100% right.

The bug starts at the adwaita level though. Not sure how to file a bug there, their github is read only and no issues section. Of course no one listens to bug reports unless you are on the latest version. I'll try latest yaru and see if that works. At least it's on github.

[01micko]

@johnraff post on the forum yesterday illustrates the bug https://forums.bunsenlabs.org/viewtopic.php?pid=139467#p139467

I can get it looking much better with a small external CSS file - almost not noticeable and fixed the rubber band. So if bug reports fall on deaf ears at least we have a work around.

[johnraff]

It's also very easy to set file highlights off by default in the user Thunar configs:
https://forums.bunsenlabs.org/viewtopic.php?pid=139487#p139487
That at least hides the bug from first-time users.

[hhhorb]

Isn't Adwaita now libadwaita? If so...

https://gitlab.gnome.org/GNOME/libadwaita/-/issues

But I think the Yaru git is a better place to post the bug, as it's the current default Ubuntu gnome-shell/GTK/icon theme.

Nice job finding workarounds! A small team of eager, well informed hobbyists indeed!

[johnraff]

That pesky double-cursor thing doesn't seem to be LightDM - I got it today on a nwg-hello window. Probably qemu.

Never seen that, maybe a graphics driver issue? What native machine you using?

An oldish HP Desktop (HP ProDesk 600 G1 SFF)
Graphics info from inxi (on host):

Graphics:
  Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics
    vendor: Hewlett-Packard driver: i915 v: kernel arch: Gen-7.5 ports:
    active: VGA-1 empty: DP-1, DP-2, HDMI-A-1, HDMI-A-2 bus-ID: 00:02.0
    chip-ID: 8086:0412 class-ID: 0300
  Display: x11 server: X.Org v: 1.21.1.7 compositor: Picom v: 9.1 driver: X:
    loaded: modesetting unloaded: fbdev,vesa dri: crocus gpu: i915
    display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 1440x900 s-dpi: 96 s-size: 381x238mm (15.00x9.37")
    s-diag: 449mm (17.69")
  Monitor-1: VGA-1 model: BenQ E900W serial: <filter> res: 1440x900 hz: 60
    dpi: 90 size: 408x255mm (16.06x10.04") diag: 481mm (18.9") modes:
    max: 1440x900 min: 720x400
  API: OpenGL v: 4.6 Mesa 22.3.6 renderer: Mesa Intel HD Graphics 4600 (HSW
    GT2) direct-render: Yes

on Carbon/Wayland VM:

Graphics:
  Device-1: Red Hat QXL paravirtual graphic card driver: qxl v: kernel ports:
    active: Virtual-1 empty: Virtual-2,Virtual-3,Virtual-4 bus-ID: 00:01.0
    chip-ID: 1b36:0100 class-ID: 0300
  Display: wayland server: X.org v: 1.21.1.14 with: Xwayland v: 24.1.4
    compositor: LabWC driver: X: loaded: modesetting unloaded: fbdev,vesa
    gpu: qxl display-ID: 0
  Monitor-1: Virtual-1 res: 1024x768 hz: 60 scale: 1 size: N/A modes:
    max: 1024x768 min: 640x480
  API: EGL Message: EGL data requires eglinfo. Check --recommends.

on Carbon/Xorg VM:

Graphics:
  Device-1: Red Hat QXL paravirtual graphic card driver: qxl v: kernel ports:
    active: Virtual-1 empty: Virtual-2,Virtual-3,Virtual-4 bus-ID: 00:01.0
    chip-ID: 1b36:0100 class-ID: 0300
  Display: unspecified server: X.org v: 1.21.1.14 with: Xwayland v: 24.1.4
    driver: X: loaded: modesetting unloaded: fbdev,vesa gpu: qxl
    display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 1024x768 s-size: <missing: xdpyinfo>
  Monitor-1: Virtual-1 res: 1024x768 hz: 60 size: N/A modes: max: 1024x768
    min: 640x480
  API: OpenGL Message: Unable to show GL data. glxinfo is missing.

The issue only occurs when running Wayland, either a logged-in session or sometimes nwg-hello too.

I don't know if this could be a hint:
API: EGL Message: EGL data requires eglinfo. Check --recommends.

[01micko]

Issue filed - ubuntu/yaru#4154

[01micko]

I don't know if this could be a hint:
API: EGL Message: EGL data requires eglinfo. Check --recommends.

Could be as wayland relies a lot on EGL

[01micko]

Same as I posted in the yaru bug report but does a decent job of working around the issue:

/* goes to $HOME/.config/gtk-3.0/gtk.css */
.thunar .view:selected { background-color: @theme_selected_bg_color; }
.thunar .view { background-color: alpha(@theme_bg_color, 0.8); }

[johnraff]

So it looks as if we can deal with the Adwaita/Yaru highlights issue one way or another. :)

---

Anyway, since /etc/greetd/greetd.conf will be installed by bunsen-configs, then each configs, configs-lite, configs-base .postinst file can have the code @01micko posted above, just with a changed test for the existence of the file instead of the directory. I'll edit the postinsts like this:

    GREETD="/etc/greetd/greetd.conf"

    if [ -f "$GREETD" ] && id _greetd >/dev/null 2>&1
    then
        chown  _greetd:_greetd "$GREETD"
        usermod -a -G video _greetd
    fi

Since bunsen-meta-wayland-addon (see various notes and edits below) will Depend on one of the bunsen-configs packages it can count on that job already having been done.

---

EDIT: after all, I don't think bunsen-configs-wayland-addon will be needed, if bunsen-meta-wayland-addon has the needed dependencies instead. Maybe more useful will be to later split off a bunsen-configs-xorg package that the pure Wayland session needn't install?

Just something I thought of while writing about dependencies - maybe the Wayland configs package we're currently talking about should be named bunsen-configs-wayland-addon? Because some time in the future there might be a standalone BL Wayland setup depending on its own bunsen-configs-wayland package, with no Xorg-related dependencies. This way we'll avoid a possible name clash down the road.

---

Dependencies

Almost a topic in itself, but just to put down how I'm now thinking the pieces will fit together - of course this might turn out to need changing.

EDIT: some rethinking of dependencies is needed, so please see the post I'm just about to add below.

bunsen-meta-wayland-addon will Depend on bunsen-meta-all | bunsen-meta-lite | bunsen-meta-base, bunsen-configs-wayland-addon, and Depend on or Recommend a suitable set of extra packages needed for a Wayland session.

bunsen-configs-wayland-addon will Depend on bunsen-configs | bunsen-configs-lite | bunsen-configs-base

All the bunsen-configs variants will Depend on (or possibly Recommend) whichever Display Manager we choose for Carbon - either LightDm or a greetd-cage-<some wayland greeter> chain - and configs files for [i]both[/i] those options will be shipped.

(Right now <some wayland greeter> looks like nwg-hello which is in Debian, but there are a couple of alternatives - eg ReGreet )

Does that make sense?

[01micko]

Does that make sense?

Yes, but I can't have a good look until the WE. Busy IRL atm.

[johnraff]

Sure, there's no hurry - I just wanted to get something down "on paper".
There's plenty of other stuff I can be looking at in the meantime...

[johnraff]

EDIT: I've finally realized that there's probably no need for a separate bunsen-configs-wayland-addon package at all.
That confusion was because I was originally imagining the current Xorg configs would be pulled in by a dependency of the wayland addon configs package. That's unnecessary IMO - it looks better to have everything needed for the Wayland addon system to be pulled in by dependencies of the metapackage bunsen-meta-wayland-addon instead. I'm editing this post accordingly. Sorry about all this editing!

Dependencies

bunsen-meta-wayland-addon will Depend on bunsen-meta-all | bunsen-meta-lite | bunsen-meta-base, bunsen-configs-wayland-addon, and Depend on or Recommend a suitable set of extra packages needed for a Wayland session.

bunsen-configs-wayland-addon will Depend on bunsen-configs | bunsen-configs-lite | bunsen-configs-base

Further thought: an example of a file that both bunsen-configs-wayland-addon and a hypothetical future bunsen-configs-wayland would have to ship is /usr/share/wayland-sessions/bunsenlabs-wayland.desktopOf course it's not allowed for two packages to ship the same file. (That's just an example, I'm sure there are other files.)

EDIT: I don't think there will be any need for bunsen-configs-wayland-addon

I think this will probably mean having both bunsen-configs-wayland-addon and bunsen-configs-wayland available from the start, with bunsen-meta-wayland-addon depending on both of them. Most of the necessary wayland config will be in bunsen-configs-wayland. In fact, it might not be necessary to have bunsen-configs-wayland-addon after all. If its only purpose is to depend on one of the Xorg config packages then that dependency can just as easily come from the metapackage bunsen-meta-wayland-addon.

Packages' internal details can be tweaked later - we just want to avoid making things difficult for ourselves when we put out the "pure" Wayland system (I don't know if that will come with Carbon/Trixie or not). Probably just getting the package names and dependencies right will do for now.

So another attempt at a provisional "Dependencies" map:

---

Dependencies

bunsen-meta-wayland-addon will Depend on bunsen-meta-all | bunsen-meta-lite | bunsen-meta-base, bunsen-configs-wayland, bunsen-configs-wayland-addon (if that package turns out to be needed) , bunsen-configs | bunsen-configs-lite | bunsen-configs-baseand Depend on or Recommend a suitable set of extra packages needed for a Wayland session (perhaps also as a further metapackage).

bunsen-configs-wayland-addon will Depend on bunsen-configs | bunsen-configs-lite | bunsen-configs-base

All the bunsen-configs variants will Depend on (or possibly Recommend) whichever Display Manager we choose for Carbon - either LightDm or a greetd-cage-<some wayland greeter> chain - and configs files for [i]both[/i] those options will be shipped.

(Right now <some wayland greeter> looks like nwg-hello which is in Debian, but there are a couple of alternatives - eg ReGreet )

---

We want to keep code duplication to a minimum and there will be a lot of common config needed by both Xorg and Wayland sessions. This is starting to look to me as if we might need a bunsen-configs-xorg with Xorg-only stuff, along with bunsen-configs-wayland and also bunsen-configs to hold the stuff needed by both Xorg and Wayland. (That would include the Display Manager stuff I guess.) There's a lot of stuff in the -configs- package and I want to look it all over at some point, but I think most of it might turn out to be session-agnostic, at least wrt Xorg vs Wayland.

I hope the light/base variants can be kept out of the Xorg/Wayland split - I'd hate to have to maintain all the permutations of bunsen-configs-wayland-lite, bunsen-configs-xorg-base...

It's all rather complicated I'm afraid. Let's try and build it up bit by bit.

[01micko]

Ok, a bit to digest there. Let's hope we don't need greetd/some-greeter and the lightdm new package at my repo can solve the issues + that sleep in bunsenlabs-session. That will vastly simplify things. Hopefully early next year we can do a few tests with net-installs and see how things work and tune things to suit. We can't really seriously test until trixie has entered the freeze stage where packages aren't going to change too much.

Q. Can we write a greeter GUI in shell? gtk3dialog would certainly be capable as it supports fullscreen in wayland and X and the widgets can be placed anywhere on screen. Doesn't need to be bash either, can be dash or even #!/usr/bin/busybox ash which is far more capable than dash. Anyway, just an idea, rather stick to something tried and true.

---

We want to keep code duplication to a minimum and there will be a lot of common config needed by both Xorg and Wayland sessions. This is starting to look to me as if we might need a bunsen-configs-xorg with Xorg-only stuff, along with bunsen-configs-wayland and also bunsen-configs to hold the stuff needed by both Xorg and Wayland. (That would include the Display Manager stuff I guess.) There's a lot of stuff in the -configs- package and I want to look it all over at some point, but I think most of it might turn out to be session-agnostic, at least wrt Xorg vs Wayland.

So many things can be

if [ X is true ]; then 
    do this
elif [ W is true ]; then
    do that
else
    do other
fi

Part of the problem it seems is that only you, @hhhorb and me are working on any kind of wayland stuff, although I have seen the odd new forum member express some interest, Engineer comes to mind, and I'm sure he's posted to the labwc github discussions. (under a different handle, so I could be wrong).

Anyway, as you said..

I'd hate to have to maintain all the permutations of bunsen-configs-wayland-lite, bunsen-configs-xorg-base...
It's all rather complicated I'm afraid. Let's try and build it up bit by bit.

This is where we have to K.I.S.S. and I think we are on the right track.

[johnraff]

Let's hope we don't need greetd/some-greeter and the lightdm new package at my repo can solve the issues + that sleep in bunsenlabs-session. That will vastly simplify things.

It would be nice if we can continue using LightDm. I've reverted to the standard Debian version in my Carbon VM and right now I'm not getting any issues. If something should come up in the future we can try switching to the git HEAD version in your repo and see if any of the post-release commits have fixed things.

Hopefully early next year we can do a few tests with net-installs and see how things work and tune things to suit. We can't really seriously test until trixie has entered the freeze stage where packages aren't going to change too much.

I'm hoping to get an improved bunsen-configs out soon with a cleaned-up startup script. (One think I want to look at is how much of the Debian Xsession script is Wayland-compatible.) If you were OK with a very-first-steps wayland config tree (like what you put in the netinstall script some time ago) being released in an alpha bunsen-configs-wayland-addon then maybe that could go out soon too? Using lightdm for now anyway.

As we've discussed, it looks as if the DM is one thing that both the Xorg and Wayland sessions will need to agree on, at least for now.

Q. Can we write a greeter GUI in shell? gtk3dialog would certainly be capable as it supports fullscreen in wayland and X and the widgets can be placed anywhere on screen. Doesn't need to be bash either, can be dash or even #!/usr/bin/busybox ash which is far more capable than dash. Anyway, just an idea, rather stick to something tried and true.

As an alternative to nwg-greet that does have its appeal for sure. An in-house app means it can be exactly the way we want it, and shell is good for maintainability.

But as long as LightDm is working I'd be for staying with that - all the features it offers would be a lot of coding work to emulate.

BTW your recent work with gtk3dialog and the new wallpaper setter is truly impressive! I'm just about to install them both on my VM...

...we might need a bunsen-configs-xorg with Xorg-only stuff, along with bunsen-configs-wayland and also bunsen-configs to hold the stuff needed by both Xorg and Wayland...

So many things can be

if [ X is true ]; then 
    do this
elif [ W is true ]; then
    do that
else
    do other
fi

Yes indeed. Having all the code together in the same file makes life easier for devs, and the extra bloat for users is minimal.

Part of the problem it seems is that only you, @hhhorb and me are working on any kind of wayland stuff, although I have seen the odd new forum member express some interest, Engineer comes to mind, and I'm sure he's posted to the labwc github discussions. (under a different handle, so I could be wrong).

We aren't exactly over-staffed. Then when users do come up with useful ideas, they so often seem to get dropped. Novice had a beautiful theme suggestion: https://forums.bunsenlabs.org/viewtopic.php?pid=139476#p139476 but after posting a couple of links, that was it. If he'd come up with some complete files etc I would have been very happy to drop them in the Carbon themes package, but I don't have the time to do the work myself right now.

To be honest, I think we might be getting more involvement from community members if we had discussions like this one over on the forum. I doubt if many people browse GitHub for interesting topics.

This is where we have to K.I.S.S. and I think we are on the right track.

Yes I think so too.

[johnraff]

Before I forget, some of this was gone over a bit in July - I think it's still more or less in line with what we're saying now.
Possible reorganization of bunsen-configs, shelved
Organizing the Carbon BunsenLabs sessions for Wayland and X11

[01micko]

Before I forget, some of this was gone over a bit in July - I think it's still more or less in line with what we're saying now. Possible reorganization of bunsen-configs, shelved Organizing the Carbon BunsenLabs sessions for Wayland and X11

Yes, just looked. All fairly relevant.

[johnraff]

I've been allowing myself to be distracted by one thing after another, but finally committed this:

Anyway, since /etc/greetd/greetd.conf will be installed by bunsen-configs, then each configs, configs-lite, configs-base .postinst file can have the code @01micko posted above, just with a changed test for the existence of the file instead of the directory. I'll edit the postinsts like this:

    GREETD="/etc/greetd/greetd.conf"

    if [ -f "$GREETD" ] && id _greetd >/dev/null 2>&1
    then
        chown  _greetd:_greetd "$GREETD"
        usermod -a -G video _greetd
    fi

[01micko]

Hopefully, with xfce working on wayland, lightdm issues will be solved and we won't need nwg-hello/greetd.

I tried the xfce wayland session and while it uses labwc the xfce-panel was still thinking it was using X (and consequently did not show - it was however running) so they have some work to do, although they did have their menu working on right click.

[johnraff]

xfce committed a workaround for the lightdm VT-switch-time issue in November: xfce-mirror/xfce4-session@268e2fc
and there is daily activity on the xfce4-session package: https://gitlab.xfce.org/xfce/xfce4-session/activity

So we can probably expect improvements to come down the pipe fairly quickly.
As long as LightDM remains xfce's display manager then something should work out.

[johnraff]

BL threads, in case you have any comments to add:
https://forums.bunsenlabs.org/viewtopic.php?pid=140270#p140270
https://forums.bunsenlabs.org/viewtopic.php?pid=140278#p140278