| View previous topic :: View next topic |
| Author |
Message |
Luke-Jr
n00b
Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org
|
 Posted: Wed Apr 20, 2016 7:05 am Post subject: HOWTO: KDE 5 & LxQt without ANY Wayland |
 |
|
I didn't want to install kwayland, so I made the trivial changes required to build libkscreen without it.
Use this at your own risk. I make no warranties, and I expect Gentoo won't support you if it messes anything up.
| Code: | mkdir -p /etc/portage/patches/kde-plasma/libkscreen
( cd /etc/portage/patches/kde-plasma/libkscreen && wget http://luke.dashjr.org/tmp/code/no-kwayland.patch; )
mkdir -p /etc/portage/profile
echo kde-frameworks/kwayland-9999 >>/etc/portage/profile/package.provided
|
(Edit: updated kde-plasma to kde-frameworks above, due to category change)
It'd be nice to get this merged either upstream or in Gentoo's ebuild, but I don't care enough to make sure the changes don't break kwayland support (I'd have to install kwayland to test that, which kinda defeats my point in making it).
So if anyone with kwayland already wants to confirm whether this breaks their build or not (just skip the package.provided steps above), that'd be good to know.
Ideally, please confirm the kwayland backend tests run properly too.
Upstream has basically said they won't accept the change, even if we do the work to make it.
So it seems the most likely bet at this point is to get Gentoo to add it as a "wayland" USE flag - which AFAIK just needs the patch to be well-tested in both configurations.
Last edited by Luke-Jr on Tue May 17, 2016 11:13 pm; edited 1 time in total |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Apr 20, 2016 12:32 pm Post subject: |
|
|
Good one, luke-jr.
Hopefully we can get some actual review out of upstream.
Adding it to IUSE in local overlay is simple enough; if it's working for you, submit the patch to bugzilla, along with a patch for the ebuild, and the upstream bug URL.
Then other Gentoo users can test and confirm, which the upstream will be able to access and consider (add a note to their bug.)
That may all be obvious to you, as a long-term user, but it's always good to reiterate the fundamentals. ;) |
|
| Back to top |
|
|
Luke-Jr
n00b
Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org
|
| Posted: Wed Apr 20, 2016 7:37 pm Post subject: |
|
|
Seems this patch breaks wayland support entirely.
I don't really have time to figure out why, though. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Apr 22, 2016 4:56 am Post subject: |
|
|
I don't see why it matters if we break wayland support, given that we don't want to use it.
It's just another configure --without-wayland. |
|
| Back to top |
|
|
Luke-Jr
n00b
Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org
|
| Posted: Fri Apr 22, 2016 5:00 am Post subject: |
|
|
| steveL wrote: | I don't see why it matters if we break wayland support, given that we don't want to use it.
It's just another configure --without-wayland. |
I was under the impression that patches should not be conditional on USE flags, and also someone in #gentoo-kde told me they wouldn't take a hacky patch.
(Which is IMO totally reasonable, unlike upstream.) |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Apr 22, 2016 2:53 pm Post subject: |
|
|
| Luke-Jr wrote: | | I was under the impression that patches should not be conditional on USE flags |
Untrue; if the USE flag does not alter what is installed, it should not be a USE flag at all.
It's hard to see how that can be the case when a USE flag is not allowed to determine whether to patch or not.
In general they're configure options, true, but you can definitely trigger patch off them: the user is meant to be aware that a different build will result from different USE flags.
| Quote: | and also someone in #gentoo-kde told me they wouldn't take a hacky patch.
(Which is IMO totally reasonable, unlike upstream.) |
Hah, every patch is "hacky" by definition; though we've got the confirm that it is pretty much what they'd do, anyway, so it should be okay. (Looked okay to me but I'm not a #cmake expert; ##workingset is the best place for toolchain/build-system advice, ime.)
wrt upstream I have a feeling we're running into the newer "enthusiasts".
Martin I recall from a couple of wacky blog-posts along the systembust way.
I find it kinda cute how the "modern" "developers" do their classroom-level verbal reasoning on blogs, in public, and rush to shaky judgement on architectural design, based on the corner they just argued themselves into.
Hard to backtrack from that kind of dodgy conclusion, afaict, which is a shame when it's so easy to think in private, and thus see the obvious flaws in one's own premises. |
|
| Back to top |
|
|
Luke-Jr
n00b
Joined: 28 Apr 2003
Posts: 33
Location: Jabber: luke@dashjr.org
|
| Posted: Sat Apr 23, 2016 3:25 am Post subject: |
|
|
| steveL wrote: | | Luke-Jr wrote: | | I was under the impression that patches should not be conditional on USE flags |
Untrue; if the USE flag does not alter what is installed, it should not be a USE flag at all.
It's hard to see how that can be the case when a USE flag is not allowed to determine whether to patch or not. |
The patched CMakeLists could take a "configure option", for example.
But if someone else will take responsibility for getting it merged, I'd be happy to do the git / merge request side for this patch. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Apr 29, 2016 12:36 pm Post subject: |
|
|
| steveL wrote: | ..if the USE flag does not alter what is installed, it should not be a USE flag at all.
It's hard to see how that can be the case when a USE flag is not allowed to determine whether to patch or not. |
| Luke-Jr wrote: | | The patched CMakeLists could take a "configure option", for example. |
Exactly; that is the original basis for USE-flags: to set configuration options, so that we don't have to, thus automating from-source compilation.
More recent trends toward overarching USE flags, for feature-sets rather than (in|ex)cluding specific dependencies (that usually have associated maintenance costs) seems to me better done at a higher-level.
BSD ports have package-specific OPTIONS, equiv to Gentoo USE when applied to configuration eg X11, and USE as a broader setting describing implications, such as USE_GMAKE, USE_XORG, or USE_KDE.
Though neither is at the level the newer uses of Gentoo USE are at, which is more like "gui" rather than "qt4".
Personally I find that a bit obfuscatory, for a meta-distribution built and maintained from-source by the administrator.
Either way I think it better done elsewhere, rather than adding yet another conceptual layer to an overloaded identifier.
| Quote: | | But if someone else will take responsibility for getting it merged, I'd be happy to do the git / merge request side for this patch. |
We need to show it working in an overlay, for a few users who want the option of a leaner, more stable install, then see about inclusion in the main tree, as a distro-side patch that gets wider testing.
So, patched ebuild and files/ directory, carrying the patch, as well as manifest in local overlay, then push to git.
All it is in ebuild terms, is a +wayland flag in (I)USE.
You have a collaborative git account already, just show us the working product. ;)
Don't forget to modify the project name/version as displayed to any user, eg: libkscreen-xorg, as opposed to libkscreen.
There is no need to change installed basenames (file or soname) as the admin has configured it for no wayland. (We're just making sure any bug-reports are obvious as upstream asked: changing bug-url would also be good.) |
|
| Back to top |
|
|
Athenian200
n00b
Joined: 27 Nov 2005
Posts: 22
Location: Dallas, TX USA
|
| Posted: Sun May 29, 2016 11:47 pm Post subject: |
|
|
EDIT: This patch still seems to work for LxQt, but not for KDE.
I've recently encountered some frustration trying to emerge kde-plasma/plasma-meta. I don't want KWayland on my machine either. I have X, and I want to use X. If I wanted Wayland libraries and methods used on my machine, then I would have installed them. There's no respect for user preferences these days, they just slap in whatever trendy library they like and expect everyone to be okay with it. No option to configure without it or anything. It's a really clumsy attempt to get Wayland functionality without switching from X, and essentially just adds an unneeded layer of cruft because some guy at KDE just HAD to use some Wayland features in his ultra-secure lockscreen project.
I managed to get most of KDE without Wayland, so I don't know why they're letting a few packages make it into a forced dependency. Your patch worked for me as far as installing libkscreen and kscreen, but I still have the following packages that won't seem to build properly without Wayland:
kde-plasma/plasma-integration
kde-plasma/kscreenlocker
kde-plasma/kwin
kde-plasma/powerdevil
kde-plasma/khotkeys
kde-plasma/kdeplasma-addons
kde-plasma/plasma-workspace
kde-plasma/plasma-meta
kde-plasma/plasma-desktop
Apparently you can't do it with configure options... I've tried very, very hard. Even going as far as using ebuild at a low-level and modifying CMakeFiles.txt to remove all references to Wayland. I can get it a little further along in the configure process, but it always fails eventually before it even starts trying to build the project.
If anyone is still following this, just know that there are still people out there that don't want KWayland on their X session and have no interest in having pieces of Wayland doing their own thing on top of X. Further patches along the lines of this one would be appreciated. Thank you for your consideration. |
|
| Back to top |
|
|
acmondor
n00b
Joined: 08 Aug 2014
Posts: 59
Location: Canadian Prairies
|
| Posted: Mon Oct 10, 2016 3:37 pm Post subject: |
|
|
This patch worked for me with LxQt (0.10.0) until today when libkscreen was upgraded to 5.7.5 (from 5.6.5-r1). The patch broke due to slight changes between libkscreen 5.6.5 and 5.7.5, so created a new patch (https://acmondor.ca/tmp/gentoo/patches/no-kwayland.patch) that works with 5.7.5. This new patch does exactly what original (http://luke.dashjr.org/tmp/code/no-kwayland.patch) did, plus it removes the new kscreen-doctor app from the libkscreen build since it would not build for me and it did not look like it was actually required.
As per Luke-Jr's original patch: Use this at your own risk. I make no warranties, and I expect Gentoo won't support you if it messes anything up. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Unsupported Software
