[frameworks-kinit] [Bug 374706] starting a bash-script as "root" by clicking desktop-file fails

2022-11-23 Thread MaxiPunkt
https://bugs.kde.org/show_bug.cgi?id=374706

MaxiPunkt  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |WORKSFORME

--- Comment #7 from MaxiPunkt  ---
Up to now I worked around the problem by coyping the files to:
usr/local/share/applications/*.desktop
/usr/local/bin/*.sh

Like this I was able to execute the script as root.


Don't have most recent software version, but now tested again with:
plasma 5.25.4
frameworks 5.96.0

desktop file again was placed in: ~/Desktop


Now there initially is a new dialog box showing up to choose if I trust in the
script or not.
If I confirm to go on, then the script is executed and everything works as
expected now.

Someone seems to have fixed this issue.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kinit] [Bug 374706] starting a bash-script as "root" by clicking desktop-file fails

2017-03-14 Thread MaxiPunkt
https://bugs.kde.org/show_bug.cgi?id=374706

--- Comment #4 from MaxiPunkt  ---
Nope, on my system (FC25 / KF 5.32.0 / plasma 5.8.6) bug is still present.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kinit] [Bug 374706] New: starting a bash-script as "root" by clicking desktop-file fails

2017-01-07 Thread MaxiPunkt
https://bugs.kde.org/show_bug.cgi?id=374706

Bug ID: 374706
   Summary: starting a bash-script as "root" by clicking
desktop-file fails
   Product: frameworks-kinit
   Version: 5.29.0
  Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: fa...@kde.org
  Reporter: maxantis...@freenet.de
CC: kdelibs-b...@kde.org
  Target Milestone: ---

Hi there,

starting a bash-script by clicking on a desktop-file (which opens a new
"konsole" terminal on my system, then) as ordinary user is just fine.

But if I want to do the same with UID-substitution functionality (the
bash-script shall be run as user "root") the execution of bash-script fails.

UID-substitution is defined directly inside the desktop-file (or within
KDE-properties of the icon). Like this one is asked to authenticate (password)
and the script will be executed inside a new opened "konsole" terminal, then.

As described this worked for me for years (in particular I was using
backup-script which has to be run as "root"), now this is broken for a while
already.
It was introduced approx. mid of 2016 with some system-updates (in that times I
was still running Fedora 23). Unfortunatelly I can't name these updates
exactly, sorry.

Now being on Fedora 25, I additionally get the error-message saying "kinit5"
crashed. If my bug should not be related to "kinit5" but another component of
KDE please let me know.


Content of example bash-script:
---
#!/bin/bash
echo -n "I am: "
whoami


Content of example desktop-file:

[Desktop Entry]
Comment=A simple script for test proposes
Exec=/path/to/above/script/test.sh
GenericName=Bash script
Icon=application-x-shellscript
MimeType=
Name=My-Terminal-Script
Path=
StartupNotify=false
Terminal=true
TerminalOptions=\s--noclose
Type=Application
X-DBUS-ServiceName=
X-DBUS-StartupType=none
#X-KDE-SubstituteUID=true
#X-KDE-Username=root


Running the script above by clicking the icon works fine.
After uncommenting the last 2 lines (enables UID-substitution) it will fail.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 367582] 19Aug16 Updates (131) Crash Desktop Icon/Scripts

2017-01-03 Thread MaxiPunkt
https://bugs.kde.org/show_bug.cgi?id=367582

MaxiPunkt  changed:

   What|Removed |Added

 CC||maxantis...@freenet.de

--- Comment #7 from MaxiPunkt  ---
Hi there,

I've noticed similar issue on Fedora-23 & Fedora-25:

Found out that starting a bash-script via desktop-file as ordinary user is just
fine.

But same attempt in combination with UID-substitution functionality (the
bash-script shall be run as user "root") the execution of bash-script fails.

UID-substitution is defined directly inside the desktop-file (or within
KDE-properties of the icon). Like this one is asked to authenticate (password)
and the script will executed then.
This worked for me for years (in particular I run a backup-script as "root"),
now this is broken for a while already.


Content of example bash-script:
---
#!/bin/bash
echo -n "I am: "
whoami


Content of example desktop-file:

[Desktop Entry]
Comment=A simple script for test proposes
Exec=/path/to/above/script/test.sh
GenericName=Bash script
Icon=application-x-shellscript
MimeType=
Name=My-Terminal-Script
Path=
StartupNotify=false
Terminal=true
TerminalOptions=\s--noclose
Type=Application
X-DBUS-ServiceName=
X-DBUS-StartupType=none
#X-KDE-SubstituteUID=true
#X-KDE-Username=root


Check running the script by clicking the icon - works fine.
Uncomment the last 2 lines (enables UID-substitution) - will fail.


If my bug should not be related to the reported one please let me know.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kdoctools] [Bug 374435] kdoctools_install() use a wrong directory when the parameter ends with "docs"

2017-01-02 Thread MaxiPunkt
https://bugs.kde.org/show_bug.cgi?id=374435

--- Comment #2 from MaxiPunkt  ---
Hi there,

happy new year & thanks for your recent efforts.  :)

> If you use any name for the directory which does not end in docs,
> the macro works.
Cool, this is my (already successfully tested) workaround for now.
Right now I didn't check your patch of kdoctools, yet.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kdoctools] [Bug 357428] kf5-kdoctools: several issues with kdoctools_install()

2016-12-28 Thread MaxiPunkt
https://bugs.kde.org/show_bug.cgi?id=357428

--- Comment #19 from MaxiPunkt  ---
Created attachment 103043
  --> https://bugs.kde.org/attachment.cgi?id=103043&action=edit
kronometer DOC's & translations in separated DIRs (SVN)

As requested.
Please note that this tarball includes translations, only.
It can be combined with kronometer's GIT-source (c097a179).

I do this by extracting tarball into GIT-source & appending content of included
"CMakeLists.txt.l10n" to original CMakeLists.txt.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kdoctools] [Bug 357428] kf5-kdoctools: several issues with kdoctools_install()

2016-12-28 Thread MaxiPunkt
https://bugs.kde.org/show_bug.cgi?id=357428

--- Comment #17 from MaxiPunkt  ---
Now tested again:

translation DIR-structure N°1:
--
l10n-messages_docs//*.po
l10n-messages_docs//docs//*.docbook

=> DOC's & translations are "mixed" in a single directory

"CMakeLists.txt" N°1:
-
find_package(KF5I18n CONFIG REQUIRED)
ki18n_install(l10n-messages_docs)
find_package(KF5DocTools REQUIRED)
kdoctools_install(l10n-messages_docs)

=> Results in OK-installation
(btw. this DIR-strukture is currently used in kronometer tarball)


translation DIR-structure N°2:
--
l10n-messages//*.po
10n-docs//docs//*.docbook

=> DOC's & translations are in separate directories

"CMakeLists.txt" N°2:
-
find_package(KF5I18n CONFIG REQUIRED)
ki18n_install(l10n-messages)
find_package(KF5DocTools REQUIRED)
kdoctools_install(l10n-docs)

=> Results in bogus installation-path of DOC's,
as  is used _twice_ in the installation-path.
On my system: /usr/share/doc/HTML///docs//*.docbook


Acc.to what you've written in comment#3 KDocTools should be able to handle both
DIR-structure scenarios correctly:
> it works both when doc translations are "mixed" with interface translations
> and when they are in separate directories (tested back to 5.16).

> What version of KDocTools are you using?
My distro currently provides version 5.27.0

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kdoctools] [Bug 357428] kf5-kdoctools: several issues with kdoctools_install()

2016-12-27 Thread MaxiPunkt
https://bugs.kde.org/show_bug.cgi?id=357428

MaxiPunkt  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #15 from MaxiPunkt  ---
Recently I've checked this issue again - unfortunately installing translated
DOC's via "kdoctools_install()" still doesn't work as expected, yet:

The directory-structure for translated DOC's was done following comment#3,
which is:
./10n-docs//docs//*.docbook


The "CMakeLists.txt" contains the following lines:
find_package(KF5DocTools REQUIRED)
kdoctools_install(l10n-docs)

On my system the DOC's currently get installed into:
/usr/share/doc/HTML///docs//*.docbook


So for some reason  is used _twice_ in the installation-path by accident.
Like this the translated DOC's are not usable.

Could you please fix?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kdoctools] [Bug 357428] kf5-kdoctools: several issues with kdoctools_install()

2016-05-16 Thread MaxiPunkt via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357428

--- Comment #11 from MaxiPunkt  ---
Got it, before compiling I did the following:
$ rm -rf ./l10n-docs/pt_BR/
$ rm -rf ./l10n-docs/pt/

The code compiles fine then - with the help of your patch of kdoctools (comment
#8).
So in addition to the (fixed) problem in kdoctools some of krusader-DOC's seem
to be bogus.

Didn't test if installed DOC's are usable yet, as I still have to do finish my
RPM-SPEC to be able to install this software.

Anyhow - thanks for your help!

-- 
You are receiving this mail because:
You are watching all bug changes.


[frameworks-kdoctools] [Bug 357428] kf5-kdoctools: several issues with kdoctools_install()

2016-05-16 Thread MaxiPunkt via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357428

--- Comment #10 from MaxiPunkt  ---
Patching "kdoctools" was o.k., but unfortunatelly your patch doesn't work for
me.
Actually I'm not sure if the errors are related to "kdoctools", or to
krusader's DOC's (possibly not not up-to-date?).


[  3%] Generating l10n-docs/pt_BR/docs/krusader/index.cache.bz2
cd /home/maxipunkt/rpmbuild/BUILD/krusader-master-20160515-f6b5f186 &&
/usr/bin/meinproc5 --check --cache
/home/maxipunkt/rpmbuild/BUILD/krusader-master-20160515-f6b5f186/x86_64-redhat-linux-gnu/l10n-docs/pt_BR/docs/krusader/index.cache.bz2
l10n-docs/pt_BR/docs/krusader/index.docbook
I/O warning : failed to load external entity
"/usr/share/kf5/kdoctools/customization/xsl/pt-BR.xml"
No "pt_br" localization of "footer-doc-comment" exists; using "en".
No "pt_br" localization of "footer-doc-feedback" exists; using "en".
No "pt_br" localization of "footer-doc-teamname" exists; using "en".
...
...
...
[  3%] Generating l10n-docs/pt/docs/krusader/index.cache.bz2
cd /home/maxipunkt/rpmbuild/BUILD/krusader-master-20160515-f6b5f186 &&
/usr/bin/meinproc5 --check --cache
/home/maxipunkt/rpmbuild/BUILD/krusader-master-20160515-f6b5f186/x86_64-redhat-linux-gnu/l10n-docs/pt/docs/krusader/index.cache.bz2
l10n-docs/pt/docs/krusader/index.docbook
No "pt_br" localization of "footer-doc-comment" exists; using "en".
No "pt_br" localization of "footer-doc-feedback" exists; using "en".
No "pt_br" localization of "footer-doc-teamname" exists; using "en".
No "pt_br" localization of "footer-doc-comment" exists; using "en".
No "pt_br" localization of "footer-doc-feedback" exists; using "en".
No "pt_br" localization of "footer-doc-teamname" exists; using "en".
No "pt_br" localization of "footer-doc-comment" exists; using "en".
No "pt_br" localization of "footer-doc-feedback" exists; using "en".
No "pt_br" localization of "footer-doc-teamname" exists; using "en".
No "pt_br" localization of "footer-doc-comment" exists; using "en".
No "pt_br" localization of "footer-doc-feedback" exists; using "en".
No "pt_br" localization of "footer-doc-teamname" exists; using "en".
installation.docbook:1023: parser error : Entity 'kicon' not defined
a partir do &kmenu;. P.ex. no &Mandrake;-&Linux; 10.0 carregue no botão &kicon;
  
^
installation.docbook:1257: parser error : chunk is not well balanced
index.docbook:414: parser error : Failure to process entity installation
  &installation;
^
index.docbook:414: parser error : Entity 'installation' not defined
  &installation;
^
No "pt_br" localization of "footer-doc-comment" exists; using "en".
No "pt_br" localization of "footer-doc-feedback" exists; using "en".
No "pt_br" localization of "footer-doc-teamname" exists; using "en".
Error: `xmllint --noout` outputted text
CMakeFiles/l10n-docs-pt-docs-krusader-index-cache-bz2.dir/build.make:100:
recipe for target 'l10n-docs/pt/docs/krusader/index.cache.bz2' failed
make[2]: *** [l10n-docs/pt/docs/krusader/index.cache.bz2] Error 1
make[2]: Leaving directory
'/home/maxipunkt/rpmbuild/BUILD/krusader-master-20160515-f6b5f186/x86_64-redhat-linux-gnu'
CMakeFiles/Makefile2:366: recipe for target
'CMakeFiles/l10n-docs-pt-docs-krusader-index-cache-bz2.dir/all' failed
make[1]: *** [CMakeFiles/l10n-docs-pt-docs-krusader-index-cache-bz2.dir/all]
Error 2
make[1]: *** Waiting for unfinished jobs....
No "pt_br" localization of "footer-doc-comment" exists; using "en".
No "pt_br" localization of "footer-doc-feedback" exists; using "en".
No "pt_br" localization of "footer-doc-teamname" exists; using "en".
No "pt_br" localization of "footer-doc-comment" exists; using "en".
No "pt_br" localization of "footer-doc-feedback" exists; using "en".
No "pt_br" localization of "footer-doc-teamname" exists; using "en".
No "pt_br" localization of "footer-doc-comment" exists; using "en".
No "pt_br" localization of "footer-doc-feedback" exists; using "en".
No "pt_br" localization of "footer-doc-teamname" exists; using &q

[frameworks-kdoctools] [Bug 357428] kf5-kdoctools: several issues with kdoctools_install()

2016-05-16 Thread MaxiPunkt via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357428

--- Comment #9 from MaxiPunkt  ---
Thanks for your recent efforts.

To test this I would have to replace system's "kdoctools" with a patched
version first, as my system does not allow me to modify system-files (SELinux)
manually.  Hopefully this is not a time-consuming task, otherwise I will have
to give up for now...

-- 
You are receiving this mail because:
You are watching all bug changes.


[frameworks-kdoctools] [Bug 357428] kf5-kdoctools: several issues with kdoctools_install()

2016-05-15 Thread MaxiPunkt via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357428

--- Comment #7 from MaxiPunkt  ---
Created attachment 98995
  --> https://bugs.kde.org/attachment.cgi?id=98995&action=edit
krusader-translations from today's SVN

tar.xz includes "CMakeLists.txt.l10n"
It is intended to be appended to "CMakeLists.txt" of project-code.

-- 
You are receiving this mail because:
You are watching all bug changes.


[frameworks-kdoctools] [Bug 357428] kf5-kdoctools: several issues with kdoctools_install()

2016-05-15 Thread MaxiPunkt via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357428

--- Comment #6 from MaxiPunkt  ---
> Which version of cmake?
* cmake-3.4.1
* kf5-kdoctools-5.21.0

> Could you please share the example you are testing?
Currently I'm trying to compile krusader-kf5 with all bells & whistles
(including all translations).
Hopefully I'm able to upload current tar.xz I've made of the translations with
my self-made script...

-- 
You are receiving this mail because:
You are watching all bug changes.


[frameworks-kdoctools] [Bug 357428] kf5-kdoctools: several issues with kdoctools_install()

2016-05-15 Thread MaxiPunkt via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357428

--- Comment #4 from MaxiPunkt  ---
With a subdir added as suggested, during compilation CMake now complains:

> add_custom_target cannot create target  "BLA_BLA" because another target with 
> the same
> name already exists.  The existing target is a custom target created in 
> source directory
> ...
> ...
> See documentation for policy CMP0002 for more details."
Adding "cmake_policy(SET CMP0002 OLD)" doesn't help.


I still don't get the logic behind all this. Looking at other code-examples:
1) http://download.kde.org/stable/kronometer/2.1.0/src/kronometer-2.1.0.tar.xz
2) http://download.kde.org/stable/ktorrent/5.0/ktorrent-5.0.1.tar.xz

These projects include translated PO's
=> simplified directory-structure (w/o CMakeLists.txt in subdirs)
=> "ki18n_install()" is used in CMakeLists.txt (root-dir)

These projects include translated DOC's
=> old directory-structure (incl. CMakeLists.txt in any subdir)
=> "kdoctools_install()" is NOT used in CMakeLists.txt (root-dir)

Is it possible for these projects to use "kdoctools_install()" instead - how
would I do that?

If there would be no solution for this, what is the propose of
"kdoctools_install()", then?
Thought with "kdoctools_install()" one is able to get rid of these
CMakeLists.txt in subdirs by some magic of these CMake-helpers...

-- 
You are receiving this mail because:
You are watching all bug changes.


[frameworks-kdoctools] [Bug 357428] kf5-kdoctools: several issues with kdoctools_install()

2016-01-03 Thread MaxiPunkt via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357428

--- Comment #2 from MaxiPunkt  ---
Well, this is off-topic but I've made this script a while ago already (KDE4) to
be able to create tarballs named in a way I found it useful.

Seems that you're aiming at the files found in "releaseme.git".
But as far as I could see kdoctools_install()  won't be used here (yet?).

Instead it seems workarounds are used to add CMakeLists.txt containing the
functions kdoctools_create_handbook() and kdoctools_create_manpage() - which
IMHO should not be necessary anymore when using kdoctools_install().

In the moment I try do adapt my script to the needs of KF5. With some
particular cmake-magic implemented in KF5 my script should even be simpler than
to KDE4-times.

ki18n_install()  is working as expected.
kdoctools_install() is not - this is why I filled this report.

-- 
You are receiving this mail because:
You are watching all bug changes.


[frameworks-kdoctools] [Bug 357428] New: kf5-kdoctools: several issues with kdoctools_install()

2016-01-02 Thread MaxiPunkt via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357428

Bug ID: 357428
   Summary: kf5-kdoctools: several issues with kdoctools_install()
   Product: frameworks-kdoctools
   Version: unspecified
  Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kde-doc-engl...@kde.org
  Reporter: maxantis...@freenet.de
CC: kdelibs-b...@kde.org

I'm trying to use the cmake-magic to include translations (po's & doc's) in a
project.

For translations I'm using a self-made script which downloads l10n-data from
SVN-server:
* po-files are stored in a directory named: l10n-messages//*.po
* doc-files are stored in a directory named: l10n-docs//docs/*.docbook

The application-code was downloaded from GIT-server before.
To combine it with translations, I've copied the translation-dirs
(l10n-messages & l10n-docs) into the application-code. Then I tried to append
original CMakeLists.txt with the following lines:

find_package(KF5I18n CONFIG REQUIRED)
ki18n_install(l10n-messages)
find_package(KF5DocTools REQUIRED)
kdoctools_install(l10n-docs)

1. issue:
Found out that doc's strictly have to be placed into the same directory as the
po-files, otherwise cmake breaks while processing kdoctools_install() .

But shouldn't the functions kdoctools_install(DIR) and ki18n_install(DIR) work
independently from each other? It seems that it is not possible to have po's in
 and doc's in 

2. issue:
Because of 1st issue I changed my script to download l10n-data from SVN-server
like this:
* po-files are stored in a directory named: translations//*.po
* doc-files are stored in a directory named: translations//docs/*.docbook

But cmake still breaks while processing kdoctools_install(), now with the
following error: 

CMake Error at /usr/lib64/cmake/KF5DocTools/KF5DocToolsMacros.cmake:106
(message):
  SUBDIR needs to be defined when calling kdoctools_create_handbook
Call Stack (most recent call first):
  /usr/lib64/cmake/KF5DocTools/KF5DocToolsMacros.cmake:231
(kdoctools_create_handbook)
  CMakeLists.txt:116 (kdoctools_install)

How to define the missing "SUBDIR"?
Shouldn't this be done by kdoctools_install()  automatically?


Used kf5-kdoctools version: 5.17.0

Reproducible: Always

-- 
You are receiving this mail because:
You are watching all bug changes.