Re: KDE in prefix install

2018-03-31 Thread Michael Pyne
On Thu, Mar 29, 2018 at 12:19:26PM +0200, Allan Sandfeld Jensen wrote:
> On Donnerstag, 29. März 2018 03:26:08 CEST Michael Pyne wrote:
> > 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.
> > 
> > e.g.
> > 
> > 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.
> > 
> 
> Note we would need something additional, since kscreen currently doesn't try 
> to install those /etc/dbus-1 files, plus more than just kscreen needs them, 
> and it can be done with two simple files like I said in another email. So 
> this 
> should probably be something done by more generic module, by kdesrc-build 
> itself, or maybe by a small script provided by kdesrc-build and mentioned in 
> documentation.

I haven't thought how I want to fix this in the meantime so I've opened
a bug so I don't forget.  Bug 392581 for this one, and 392580 for the
documentation improvement in the other thread.

Regards,
 - Michael Pyne


Re: KDE in prefix install

2018-03-30 Thread Sebastian Kügler
Very useful, thanks Allan! :)

On woensdag 28 maart 2018 17:37:18 CEST Allan Sandfeld Jensen wrote:
> On Mittwoch, 28. März 2018 17:14:36 CEST Sebastian Kügler wrote:
> > What I usually do is copy the dbus files into the system paths, see
> > attached script. That should also make it work (after dbus restart).
> 
> You don't need that if you just set the dirs:
> 
> /etc/dbus-1/session.d/plasma-opt.conf:
>  1.0// EN"
>  "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";>
> 
>   /opt/kde5/share/dbus-1/services/
> 
> 
> /etc/dbus-1/system.d/plasma-opt.conf:
>  1.0// EN"
>  "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";>
> 
> /opt/kde5/share/dbus-1/system-services
> /opt/kde5/etc/dbus-1/system.d
> 
> 
> But that still leaves the problem that he polkit-1 policy files for actions
> are neither generated nor installed. Any idea why that is the case?
> 
> 'Allan


-- 
sebas

http://www.kde.org | http://vizZzion.org




Re: KDE in prefix install

2018-03-29 Thread Allan Sandfeld Jensen
On Donnerstag, 29. März 2018 03:26:08 CEST Michael Pyne wrote:
> 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.
> 
> e.g.
> 
> 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.
> 

Note we would need something additional, since kscreen currently doesn't try 
to install those /etc/dbus-1 files, plus more than just kscreen needs them, 
and it can be done with two simple files like I said in another email. So this 
should probably be something done by more generic module, by kdesrc-build 
itself, or maybe by a small script provided by kdesrc-build and mentioned in 
documentation.

'Allan




Re: KDE in prefix install

2018-03-29 Thread Allan Sandfeld Jensen
On Donnerstag, 29. März 2018 03:26:08 CEST Michael Pyne wrote:
> 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.

I was thinking there are two or three way of installing ḰDE, to /, to /usr/
local and to a non-system prefix (under /opt or home-dir). It wouldn't be too 
much to at least describe what configuration or manual corrections post 
install is needed for those combinations. 

> 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?
> 
The files weren't even generated in the build directory, and I couldn't find 
commands supposed to make them in the makefiles. So I assume cmake somehow 
doesn't know what it is supposed to do. On reason this can go wrong is because 
kauth has multiple different backend modes, and only the polkit-1 mode needs 
these files, kauth did detect the correct mode during its cmake setup, so I am 
gusesing something during kauth install needs to install cmake files that are 
found by cmake during powerdevil building.

'Allan




Re: KDE in prefix install

2018-03-28 Thread Michael Pyne
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.

e.g.

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
settings.

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
bad.

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?

Regards,
 - Michael Pyne


Re: KDE in prefix install

2018-03-28 Thread Allan Sandfeld Jensen
On Mittwoch, 28. März 2018 17:14:36 CEST Sebastian Kügler wrote:
> What I usually do is copy the dbus files into the system paths, see attached
> script. That should also make it work (after dbus restart).
> 
You don't need that if you just set the dirs:

/etc/dbus-1/session.d/plasma-opt.conf:
http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";>

  /opt/kde5/share/dbus-1/services/


/etc/dbus-1/system.d/plasma-opt.conf:
http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";>

/opt/kde5/share/dbus-1/system-services
/opt/kde5/etc/dbus-1/system.d


But that still leaves the problem that he polkit-1 policy files for actions 
are neither generated nor installed. Any idea why that is the case?

'Allan




Re: KDE in prefix install

2018-03-28 Thread Sebastian Kügler
What I usually do is copy the dbus files into the system paths, see attached 
script. That should also make it work (after dbus restart).

-- sebas

On woensdag 28 maart 2018 12:52:16 CEST 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?
> 
> 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?
> 
> 'Allan


-- 
sebas

http://www.kde.org | http://vizZzion.org

sync-dbus-services.sh
Description: application/shellscript


KDE in prefix install

2018-03-28 Thread Allan Sandfeld Jensen
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?

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?

'Allan