Web lists-archives.com

Re: KDE in prefix install

On Wed, Mar 28, 2018 at 12:52:16PM +0200, Allan Sandfeld Jensen wrote:
> So after leaving neon to use a newer ubuntu (needed it for my hardware), I 
> have started building KDE myself again and tried setting my tradition install 
> in /opt and building with kdesrc-build.
> I ran into a number of issues, many minor things I have already fixed by 
> patches. But there were two bigger issues with dbus-1 and polkit.
> First kscreen doesn't work because it can't find its backends. While not 
> easily found, I did eventually find suggestions online to fix this by adding a 
> file in /etc/dbus-1/session.d with the prefix service dir. I talked to the 
> dbus people and they seemed positive about automatically using XDG env 
> variables to do that automatically in the future, but currently you still need 
> to add that file. Perhaps kdesrc-build could document that and maybe have a 
> sudo install mode that installs that?

I can document that.  I assume the Wiki page for building from source is
where you would expect to find that?  Or were you looking at the
docs.kde.org documentation for kdesrc-build?

However you find it, you can use the "make-install-prefix" option to
control use of sudo, su -c, or other super-user programs.


options kscreen
    make-install-prefix sudo
end options

This might be good to put into the sample configuration available in the
kdesrc-build repository as well, which might even be what you were
talking about.

> The second issue was that powerdevil brighness controls didn't work. This was 
> because of something similar with the actions and services not installed for 
> polkit-1, this is a bit more complicated as polkit-1 does not allow you to add 
> extra prefix directories. So you need to add the actions in /usr/share/
> polkit-1/actions. And those files you need to install are not even generated. 
> I have tracked it down abit and found that kauth actually has a tool to 
> generate the action files and have a cmake command kauth_install_actions that 
> is even used by powerdevil, but the .policy files are still not generated nor 
> installed in prefix or /usr/share by kdesrc-build. Anyone know why this is?

So, the lame answer is that kdesrc-build didn't do it because you didn't
ask it to.  I've tried to avoid being too prescriptive within
kdesrc-build, to avoid making it impossible for users to make their own

You can see some of this in the transition for how one would specify
which module to build.

First you just specified the module name and (then-) kdecvs-build knew
where to find it automagically.  And if it found it wrong, well, too

So new options kept getting added to make it possible to properly
specify where to find the right source code and how to refer to the
resultant source directory.  There was a "branch" option which tried to
guess the right SVN folder path and a matching "dest-dir" to rename the
module name in the source/build directories, then "module-base-path"
when it became clear that "branch" path guessing wasn't foolproof,
followed by "override-url" when I gave up trying to get it magical.

At least with git we still only have "repository", "branch", and "tag"
(and "git-repository-base", but that's more for custom module-sets than
for git).

With the excuses out of the way, kdesrc-build is intended to make it
/easier/ for developers, power users, and testers, so if this is a
function that should properly be in kdesrc-build instead of in the CMake
build system or ECM then we'll put it there.  I just ask that we try to
avoid making it too magical, it's often very difficult to get it right.

First I'd want to understand whether kauth generates these .policy files
already and just doesn't install them (maybe it would with
"make-install-prefix sudo" enabled)?  Or do we just need to add some
appropriate flags to cmake when building kauth?

 - Michael Pyne