liri shell for ubuntu?

[zoecarver]

No description provided.

[plfiorini]

I would do Debian first since sid usually have Qt updated and then rebuild the packages on Ubuntu, but yeah it's going to be supported.

[zoecarver]

is there a ppa for it? or is there an easy way to install it without tracking down all the dependency?

[plfiorini]

Not yet, need to update the packaging files someone made a few months ago and start spinning builds.
I will start looking into this at least in two weeks not before.

[zoecarver]

OK cool! I think that I am going to try to make a Debian ppa for it if no one else has (I have always wanted to learn how to do that :) I will probably not succeed but, hey who knows. Has anyone else that you know of stated this? or is there anything that I should be aware of? thanks for your help!

[zigapk]

@funfood I tried that once. I know I did it somehow (don't remember how), but be prepared to smash your head against the wall for a few days.

[zoecarver]

thanks! sounds like most of my other project! :)

[plfiorini]

Need help on this issue as I won't complete this any time soon due to lack of time and Debian/Ubuntu knowledge.

[SunRain]

As I know, it's not easy to run on Debian/Ubuntu(especially on Ubuntu) due to the version of Qt.

[plfiorini]

Yeah doing snaps seems like the best way to go, see #80
With snap we already have a platform for apps with the Qt version we want and Fluid, the remaining part is to make a snap for the shell

[Maxwell175]

Is it possible to just static link Qt to overcome the version gap?

[plfiorini]

@MDTech-us-MAN Unfortunately static link doesn't solve the issue since you need Qt anyway

[Maxwell175]

Well... if you include Qt inside the binary, there should be no additional dependencies. Or you could distribute your version of Qt in the package and install it to /opt and link to that.

[plfiorini]

The problem here is that we don't want to maintain our Qt packages in addition to those of the shell.

[timsueberkrueb]

Also, as @plfiorini said, Qt is no longer the issue with our already existing platform snap.

With snap we already have a platform for apps with the Qt version we want and Fluid, the remaining part is to make a snap for the shell

[plfiorini]

For the sake of full disclosure: one can make a Liri PPA that depends on the KDE Neon one (they maintain updated Qt packages, at the time of this writing they have Qt 5.10.0 and qbs 1.9.0, not the latest versions but it's pretty close and should work for Liri), but having to install a couple of PPAs doesn't seem very easy to use to me.

As always, if someone is really interested in contributing to the project and want to go that route please contact us should you need information.

[SunRain]

Hi, is there any guid to build/install Liri from source code, I mean FULL components of Liri desktop environment?

[plfiorini]

This is the documentation for contributors: http://liri-dev.readthedocs.io/en/latest/
Do you need something specific for packagers?

[plfiorini]

BTW, I installed Debian to get a clue on how things works there and sadly I learned they don't want to package private headers. Some QtWayland APIs are still private especially all the client side APIs and since we implement a client-side decoration, a shell integration and a custom client protocol we cannot package the shell unless we remove those parts.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894472

[plfiorini]

With "remove those parts" I mean we can make those optional.
We should also re-evaluate if usage of private APIs in protocol implementations can be avoided.

And of course with Snap we can build qtwayland from sources and overcome this problem, so the issue here is with Debian and Ubuntu packages.

[dsoprea]

I'm looking for this, too.

[ItzSwirlz]

I actually tried building Liri Shell for myself and basically, you'll have to build a LOT of Liri.

A liri-team in debian might be nice but you would need to find all of the libraries, install them, and then do the work, and then you need to create the debian package along with managing the git repo in the process.

If you wanted to ADD A DEBIAN FOLDER to MAKE a package be built in a separate branch or whatnot, you would have to do that with like, almost every repo but as said it would take a long time... and this is for Liri OS. so, debian of course also has their own stuff and it would require a lot of work, especially since it might not be worth it after all.

But as time goes on we will see, I don't know what other distro's besides Liri have built this DE but it'd take time, lemme tell you.

[plfiorini]

Some things got changed meanwhile.
The client-side decoration is now optional because there are server-side decorations enabled by default.
Shell integrations were upstreamed.
Should be easier now.

[plfiorini]

The first repository to try to package is https://github.com/lirios/wayland that is a library with Wayland protocol implementations.

[plfiorini]

@ItzSwirlz Perhaps preparing the debian/ packaging might not be hard for the majority of repositories since they are easy to build. Maybe there is a way to generate it.
Now with GitHub actions it's easy to set up an automated build of the packages and upload them somewhere.
To be honest it would be better if some Debian developer decided to include the Liri desktop in Debian.
They know how to build packages and it would take less time for them. I can offer help with Liri knowledge.

[plfiorini]

Update on QtWayland private headers on Debian
Finally 894472 is fixed and Debian now has the qtwayland5-private-dev package.

[stellarpower]

Are there any updates on this? I'm trying, rather desperately now, to find a lightweight compositor I can run using waypipe to get graphical access to a server. Am yet to have had any option function, should liri compile from source without too much dfficulty on debian/ubuntu? I know the Qt libraries are badly out of date, but I can download a local copy and hopefully link against them under /opt, so I can work around that for the time being.