Sway - an i3 compatible wayland compositor

[sdhd]

Just figured out, that the config “grade: devel” and classic will not upload to the snapstore.

So, i switched back to devmode.

Hope i can now upload again.

[jdstrand]

As discussed on IRC, the use of ‘classic’ requires a manual review and you must follow Process for reviewing classic confinement snaps.

I’ve taken a look at the snap and there are older revisions that are hanging up later revisions. I’m working through unclogging those since later revisions seem to address the issues.

As an aside: if you are doing a lot of changes to your snap, you may want to use the review-tools to verify before upload. Eg, snap install review-tools ; snap-review /path/to/your/snap

As another aside: packaging sway as a snap is a very interesting idea. I’ve wanted to try sway myself, but haven’t yet. It is going to need to be classic for the time being, but @alan_g has been working through various items for making desktop shells work under strict mode, so some day it may be able to be strict mode.

[sdhd]

Thank you.

I will look at the review tools.

Maybe i can help to build strict desktops

[tsloughter]

Yay! I actually tried doing this myself a year ago and failed Building a snap for a wayland compositor

Very glad to see this and will be giving it a try soon – assuming it is supposed to work as is with --classic right now? It is unclear from the discussion above.

Thanks!

[sdhd]

Hi @tsloughter,

yes, the version described above was tested in classic mode.

I will right now start to upload a new edge version, which starts in “devmode”.

“jailmode” and “strict” is still not worked.

[sdhd]

@tsloughter:

would you prefer classic or strict ?

[sdhd]

@alan_g

How is the progress to launching a snap from another snap?

[alan_g]

@sdhd

How is the progress to launching a snap from another snap?

A confined snap launching another snap? Slow.

There have been some discussions around the PR: some resolved with actions (e.g. I need to change the interface name) some not resolved yet.

Don’t expect anything you can use soon, as the initial proposal is intentionally very limited in scope to minimize the security “surface” exposed. Even so, it is taking time to ensure things are secure.

[sdhd]

@alan_g

There have been some discussions around the PR: some resolved with actions (e.g. I need to change the interface name) some not resolved yet.

oh, that’s odd.
I’ll see if I can find the PRs.

@alan_g

Don’t expect anything you can use soon, as the initial proposal is intentionally very limited in scope to minimize the security “surface” exposed. Even so, it is taking time to ensure things are secure.

Hmm. What they want to do? Write a protocol filter for the X11 socket?
An external application like a terminal only needs the graphic output, right?,

[sdhd]

Classic request for sway-classic

It is not possible to call any snap from a strict mode snap. The work to enable this is for an API for the shell to use to talk to snapd’s userd to ask it to launch a desktop file. It is understood that this is insufficient for terminal snaps, which for the foreseeable future will need to remain classic.

I also asked here for details:

Classic request for sway-classic

Well, the terminal only needs to draw on the screen. I think a classic application can communicate with the compositors over the wire-protocol socket. All i can see what userd is to do, is to launch the terminal and give them the socket information. To give foreign applications an own drawing space (an own headless wayland) it’s in my eyes questionable. ?

[tsloughter]

I’m not sure, but I’m fine with classic.

[tsloughter]

I’m not sure. I guess it would be cool if it worked with strict but I’m not sure what all it needs access to and if that is worth it.

[sdhd]

hi,

@tsloughter
now it’s difficult to mention, if you would use preinstalled drm and opengl packages. Or what should classic include?

What is your setup ? Did you already have a desktop (as backup) installed ?

[tsloughter]

I’m not sure what you mean?

Currently, I run sway by installing it and wlroots from source manually.

[sdhd]

Inside of sway i had to add all needed libraries.

Then every machine has different gpu’s with different needed packages.

Should i add all of them inside the snap or just use the libraries which are on the host.

Not sure.

[alan_g]

@sdhd

Should i add all of them inside the snap or just use the libraries which are on the host.

Not sure.

You cannot safely use libraries from the host. Assuming you use core18 you will be linked against libraries from Ubuntu 18.04, if your snap is installed on Arch, then there is no reason to expect the host libraries and their dependencies to be ABI compatible.

You have to ensure that you have all the userspace libraries you need from the snap. (And also ensure that any executable from the you launch doesn’t pick up anything from the snap - so be careful with environment variables that affect this.)

[sdhd]

thank you @alan_g

Good point.

Should i use mesa packages or better without mesa ?

[alan_g]

@sdhd

Should i use mesa packages or better without mesa ?

There’s no perfect answer. Yet.

What I do with https://github.com/MirServer/egmde-snap/ is include the mesa userspace.

Mesa is pretty good at maintaining compatibility with the corresponding kernel modules, so this works across a range of hosts.

In contrast, the EGLstream userspace for Nvidia needs to be the same version as in the host kernel, and that’s impossible to guarantee.

[cjp256]

@alan_g you’re my hero today! You had the secret ingredient I needed to make a snap I’ve been working on work (no-patchelf!)

I think there is value in consolidating the best approach for incorporating OpenGL support into a snap, and so I put up a PR using your example to create an extension: https://github.com/snapcore/snapcraft/pull/2890

As support for OpenGL changes/improves over time, the extension can be updated accordingly.

[sdhd]

@cjp256

As support for OpenGL changes/improves over time, the extension can be updated accordingly.

thank you