Upstream plasma-desktop 8f2b38aee (HEAD ATM): Modernize X11-related cmake code Use imported targets instead of variables Use PkgConfig directly instead of wrapping calls in a find module That pretty well kills gentoo/kde's override-include-dirs.patch as some of the files no longer exist at all while others are changed enough the patch can't apply. The upstream rework looks major enough that I suspect the whole idea of the patch will need reworked to match (IOW not a trivial rebase). For now I just commented the patches= lines in the ebuild and it worked as-is (with only USE=handbook on for this package). But I've not looked into the implications.
I should add... and only xorg-server and the libinput driver installed of the four, no synaptics or evdev.
There are some new commits upstream that fix things for this. synaptics: https://invent.kde.org/plasma/plasma-desktop/-/commit/1e804fd94cdb29ab4926edc91913326467ee2272 I have removed all lines from the ebuild related to the patch: -XORGHDRS="${PN}-override-include-dirs-0" -SRC_URI+=" https://dev.gentoo.org/~asturm/distfiles/${XORGHDRS}.tar.xz" LICENSE="GPL-2" # TODO: CHECK SLOT="5" @@ -118,10 +116,6 @@ RDEPEND="${COMMON_DEPEND} policykit? ( sys-apps/accountsservice ) " -PATCHES=( - "${WORKDIR}/${XORGHDRS}/override-include-dirs.patch" # downstream patch -) - src_prepare() { ecm_src_prepare @@ -139,10 +133,6 @@ src_prepare() { src_configure() { local mycmakeargs=( -DCMAKE_DISABLE_FIND_PACKAGE_PackageKitQt5=ON # not packaged - -DEvdev_INCLUDE_DIRS="${WORKDIR}/${XORGHDRS}"/include - -DXORGLIBINPUT_INCLUDE_DIRS="${WORKDIR}/${XORGHDRS}"/include - -DXORGSERVER_INCLUDE_DIRS="${WORKDIR}/${XORGHDRS}"/include - -DSynaptics_INCLUDE_DIRS="${WORKDIR}/${XORGHDRS}"/include That's in output of configure phase: -- The following features have been disabled: * Synaptics, Synaptics libraries are needed for the synaptics touchpad KCM -- The following OPTIONAL packages have not been found: * Synaptics, Synaptics libraries are needed for the synaptics touchpad KCM -- Found XdgUserDir: /usr/bin/xdg-user-dir -- <<< Gentoo configuration >>> Build type Gentoo Install path /usr Compiler flags: C -march=native -mtune=native -O2 -pipe -fno-common -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wmissing-format-attribute -Wwrite-strings -Werror=implicit-function-declaration C++ -march=native -mtune=native -O2 -pipe -fno-operator-names -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -Wsuggest-override -Wlogical-op -fdiagnostics-color=always -pedantic -Wzero-as-null-pointer-constant Linker flags: Executable -Wl,--enable-new-dtags -Wl,-O1 -Wl,--as-needed Module -Wl,--no-undefined -Wl,--enable-new-dtags -Wl,-O1 -Wl,--as-needed Shared -Wl,--no-undefined -Wl,--enable-new-dtags -Wl,-O1 -Wl,--as-needed -- Configuring done -- Generating done CMake Warning: Manually-specified variables were not used by the project: CMAKE_DISABLE_FIND_PACKAGE_IBus CMAKE_DISABLE_FIND_PACKAGE_SCIM I don't have a touchpad.
Do we still support evdev? I thought it was superseded by libinput. -- Checking for module 'xorg-libinput' -- Found xorg-libinput, version 0.30.0 -- Checking for module 'xorg-evdev>=2.8.99.1' -- No package 'xorg-evdev' found -- Checking for module 'xorg-server' -- Found xorg-server, version 1.20.99.1 -- Checking for module 'xorg-synaptics' -- No package 'xorg-synaptics' found Looks normal for me.
(In reply to jospezial from comment #2) > There are some new commits upstream that fix things for this. > synaptics: > https://invent.kde.org/plasma/plasma-desktop/-/commit/ > 1e804fd94cdb29ab4926edc91913326467ee2272 > I don't have a touchpad. (And you don't say but I'm assuming you're still on X and not familiar with the wayland issues below either, since plasma-wayland isn't really stable yet.) The larger context for the above commit is the (relatively) new and still-not-yet-stable introduction of kde/plasma on wayland, which is actually my own default now (with X as a fallback)... with a (non-synaptics, logitech FWIW) touchpad as my primary/only pointing device. Back in the X-only era, the touchpad kcm was for synaptics alone and synaptics was required to build it. Other touchpads used the normal X pointing device configuration. And AFAIK, on plasma on X, that's still the usual config, altho it may now be possible to use the libinput touchpad kcm on X too (I'm not actually sure). Then wayland became a thing, with libinput as its default input driver for both key input and pointing devices. In ordered to standardize on libinput everywhere an X-driver shim for libinput was developed too, with it becoming the default on X. But on the new plasma-wayland with libinput being the normal driver, touchpad-specific configuration was needed for it too, so the touchpad kcm grew libinput support. But unlike on X where generic mouse support can be used for touchpads too, touchpads on plasma-wayland are *exclusively* configured with the touchpad kcm -- the mouse kcm and mouse configuration doesn't work for touchpads and there's no standardized config files analogous to xorg.conf either, with each configurator doing its own thing, so while it's possible to edit config files, there's no third-party utilities beyond straight text-editors for doing so as they'd have to support each compositor's config-file locations and formats individually. Single-sentence summary, the context for the above commit is that for people with touchpads running on plasma-wayland the libinput portion of the touchpad kcm is critical and having it built only when the synaptics headers are available is no longer reasonable. Thus the change. > I have removed all lines from the ebuild related to the patch: FWIW all I (originally) removed was this bit, since it's what actually hooked the rest up and triggered the patch and therefore build failure: > -PATCHES=( > - "${WORKDIR}/${XORGHDRS}/override-include-dirs.patch" # downstream patch > -) That worked, but as I was (originally) doing the patch manually as an in-place one-shot after syncing, I was redoing it each time I synced. After about the second update I shortened the three-line delete to a single-line add below the above three which now remain in-place: unset PATCHES Since it effectively just undoes what the three lines above it were doing it works, but I was still doing it in-place every sync, which was irritating, but because live-9999 ebuilds are updated in-place instead of bumping/rev-bumping, I didn't want to pull it into my own overlay and risk overlooking future gentoo updates to the ebuild. Luckily, back in the gentoo/kde4-requires-semantic-desktop era I developed a set of ebuild patching scripts that work much like /etc/portage/patches does but for ebuilds so I could auto-apply my no-semantic-desktop patches, and once it became obvious the fix for this bug wasn't going to be immediate, I was able to drop an ebuild patch with that "unset PATCHES" line into /etc/portage/patches.ebuild/kde-plasma/plasma-desktop, and it's been auto-applying after each sync since. =:^) (In reply to jospezial from comment #3) > Do we still support evdev? I thought it was superseded by libinput. AFAIK it's still supported on X, both by upstream kde/plasma and by gentoo, and likely will be for some years yet, I'd guess until wayland is the assumed default and X is far enough into legacy to justify dropping non-core support. For people on X running an exotic pointer driver, say the synaptic touchpad driver for features not available with the libinput driver, who had evdev configured for keyboard before there was a libinput, there's little reason to be in any big hurry to switch, since in that case libinput would be for the keyboard only anyway, and their existing evdev config works perfectly fine for it. > -- Checking for module 'xorg-libinput' > -- Found xorg-libinput, version 0.30.0 > -- Checking for module 'xorg-evdev>=2.8.99.1' > -- No package 'xorg-evdev' found > -- Checking for module 'xorg-server' > -- Found xorg-server, version 1.20.99.1 > -- Checking for module 'xorg-synaptics' > -- No package 'xorg-synaptics' found > > Looks normal for me. Normal, but automagic, since the deps aren't explicit in the ebuild. If you had X configured with exotic drivers so xorg-libinput wasn't on the system (and possibly not xorg-evdev either) would it still work? Of course I'm doing the same thing ATM, but it's a temporary hackaround, not a proper solution that gentoo/kde can adopt. A deeper examination of the deps and either deciding to add libinput as a dep, or ensuring that it actually works without it, is required.
(In reply to Duncan from comment #4) Yes. And thanks for the very interesting text to read. I have the plasma wayland stuff installed but as you write, it is to buggy to use it. Related automagic I think that has to be fixed upstream.
(In reply to jospezial from comment #5) > And thanks for the very interesting text to read. LOL. You should have seen the draft before I trimmed half of it.! =:^) > I have the plasma wayland stuff installed but as you write, it is to buggy > to use it. Agreed plasma-wayland is definitely buggy still -- I'm on it already only because I took some extra pandemic down-time to do the transition, including a number of hack-patches to make things at least tolerable-work for me. But for me the transition was actually far easier than the infamous kde3/kde4 transition, when kde devs were *insisting* the still incredibly buggy kde4 code was ready for normal use, apparently because they were simply tired of maintaining the still working far better kde3 code. I believe that's down to three things: (1) The kde devs apparently learned their lesson and both the kde4/kde5 upgrade and the plasma X/wayland upgrade have/are maintaining the old version thru the upgrade process (and actually, in the X/wayland case, I believe kde's planning on maintaining X anyway for the BSDs, which don't have wayland), allowing people to make the transition at their own convenience instead of demanding that it be at the devs' convenience. (2) I'm personally more mature/cynical/experienced now, and for some things the buggy kde4 transition forced me to actually-working non-kde alternatives, so there's literally less for me to transition now. (3) The pandemic /did/ give me the extra time to do it without having to rush things, and to come up with alternatives, be they workflow modifications, hack-patches (which while still hack-patches are an alternative I simply didn't have in the kde4 transition as I just didn't have that ability yet), or transitioning to other software, as I needed them. > Related automagic I think that has to be fixed upstream. I believe either you or I (both?) misunderstood what the other meant by "automagic". For upstream it's generally working as expected. For mandatory deps they detect and refuse to proceed if the deps aren't found. For optional deps like this one that determines which optional components are built, they provide the traditional build-configure-time hard-on/hard-off/auto-detect options. Normal binary-distro users building the occasional one-off package themselves can just go with the default auto-detect and it "just works". Then distros choose the hard-on/hard-off as appropriate to the level of dependencies vs. functionality they want for the specific package in question, a choice which gentoo as a meta-distro normally wires up to USE flag options for the users to decide. For releases versions that's what gentooers see, USE flags wired up by their gentoo maintainers to build-configure-time options and corresponding dependencies. But here we're dealing with live-git, which exposes upstream changes to their configuration to those using it, before the gentoo package maintainers have had time to react to the upstream changes and rewire the USE flags that toggle the now changed build-time-configuration and the corresponding package-manager-tracked dependencies. So it's not surprising in the least that left to its own defaults, the new upstream configuration is auto-detecting and creating automagic dependencies that if not ultimately fixed will result in headaches if the users then happen to unmerge the automagically-depended packages... because the gentoo package dependency tracking mechanism hasn't yet been updated to warn them about the dependencies they're breaking by doing so. Tho admittedly in the short term, it's unlikely anyone's going to be unmerging core dependencies such as libinput, both because enough other stuff pulls them in, and because were said users considering doing so, the /last/ thing they'd be likely to do would be run live-git versions of stuff that they know has general dependencies on stuff they're considering unmerging. Thus, it's a reasonable risk to take for a one-shot short-term workaround that's 99.9% likely to be unnecessary well before you forget you took that risk, even if on a system-wide and distro-wide scale it'd be absolute chaos so isn't an appropriate choice for the gentoo package maintainers once they do get to rewiring to accommodate this particular upstream change.
*** Bug 778995 has been marked as a duplicate of this bug. ***
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=32456f3678e8cdaa43089647b251a084aa4991ea commit 32456f3678e8cdaa43089647b251a084aa4991ea Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2021-05-14 08:54:55 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2021-05-14 12:06:20 +0000 kde-plasma/plasma-desktop: Rebase override-include-dirs.patch on 5.22 Bump XORGHDRS to override-include-dirs-1. Upstream commits: 8f2b38aeec93da0c20af3c1ca7dc6c4c75f4c6f1 4a3f69dd34e83654721cb35b02618ff33a14ff11 Closes: https://bugs.gentoo.org/775131 Package-Manager: Portage-3.0.18, Repoman-3.0.3 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> kde-plasma/plasma-desktop/Manifest | 2 +- kde-plasma/plasma-desktop/plasma-desktop-9999.ebuild | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-)
