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'

  
  Now fixed, but checking the file, not directory.
• 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.