Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1065688 - 'declarativescript script engine' service not found when installing KWin script.
Summary: 'declarativescript script engine' service not found when installing KWin script.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kde-workspace
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kevin Kofler
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-15 21:46 UTC by Piotr Dobrogost
Modified: 2014-03-08 03:31 UTC (History)
10 users (show)

Fixed In Version: kdelibs-4.12.2-3.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-22 00:45:26 UTC


Attachments (Terms of Use)
update notification with special message icon next to kdelibs entry (deleted)
2014-02-22 13:24 UTC, Piotr Dobrogost
no flags Details

Description Piotr Dobrogost 2014-02-15 21:46:34 UTC
Description of problem:
'declarativescript script engine' service not found when installing KWin script.

Version-Release number of selected component (if applicable):
KDE 4.11.5

How reproducible:
Always

Steps to Reproduce:
1. git clone https://github.com/faho/kwin-tiling.git && cd kwin-tiling/ && plasmapkg –type kwinscript -i .

Actual results:
I get a dialog window titled 'Install Plasma Resources' with the following content:

    Plasma requires an additional service for this operation
    declarativescript script engine
    The following service is required. Do you want to search for this now?
    [Continue] [Cancel]

When I press Continue button I get the following error

    Failed to search for Plasma service
    Could not find service in any configured software source
    [Close]


Expected results:
Missing service ('declarativescript script engine') being found and installed.

Comment 1 Rex Dieter 2014-02-15 22:49:28 UTC
Kevin, any suggestions/clues why this dependency isn't satisified by kde-workspace's
kwin/scripting/scripting.cpp
code already?

I believe this is one reason why we added this snippet to kde-workspace.spec awhile back:

# kwin apparently provides this internally, kwin/scripting/scripting.cpp
# our scripts can't grok it automatically
Provides: plasma4(scriptengine-declarativescript)
Provides: plasma-scriptengine-declarativescript = %{version}-%{release}

Comment 2 Kevin Kofler 2014-02-15 23:13:47 UTC
The problem is that plasmapkg knows neither about the RPM database (i.e. our explicit Provides) nor about the stuff internally provided by KWin. It (in my kdelibs patch 0002) asks Plasma for whether it has the needed script engine, and, if not, triggers the PackageKit prompt.

This is the code I'm using:
+    // check for missing dependencies
+    QString requiredScriptEngine = meta.implementationApi();
+    if (!requiredScriptEngine.isEmpty()) {
+        // figure out the component type to query for
+        ComponentTypes componentTypes = static_cast<ComponentTypes>(0);
+        QStringList serviceTypes = meta.serviceType().split(',');
+        if (serviceTypes.contains("Plasma/Applet")) {
+            componentTypes |= AppletComponent;
+        }
+        if (serviceTypes.contains("Plasma/DataEngine")) {
+            componentTypes |= DataEngineComponent;
+        }
+        if (serviceTypes.contains("Plasma/Runner")) {
+            componentTypes |= RunnerComponent;
+        }
+        if (serviceTypes.contains("Plasma/Wallpaper")) {
+            componentTypes |= WallpaperComponent;
+        }
+        if (!knownLanguages(componentTypes).contains(requiredScriptEngine)) {
+            // install the missing script engine
+            // force prompting because the user has just explicitly installed a widget
+            ComponentInstaller::self()->installMissingComponent("scriptengine", requiredScriptEngine, 0, true);
+        }
+    }
+    QStringList requiredDataEngines = meta.requiredDataEngines();
+    if (!requiredDataEngines.isEmpty()) {
+        QStringList knownDataEngines = DataEngineManager::self()->listAllEngines(meta.application());
+        foreach (const QString &requiredDataEngine, requiredDataEngines) {
+            if (!knownDataEngines.contains(requiredDataEngine)) {
+                // install the missing data engine
+                // force prompting because the user has just explicitly installed a widget
+                ComponentInstaller::self()->installMissingComponent("dataengine", requiredDataEngine, 0, true);
+            }
+        }
+    }

I'll have a look into how to best handle the KWin stuff. (Maybe I should just skip the whole ComponentInstaller code when the service type is not one of the 4 expected ones.)

Comment 3 Kevin Kofler 2014-02-16 00:28:56 UTC
This should fix it:
http://pkgs.fedoraproject.org/cgit/kdelibs.git/commit/?id=558270b8dcb1f6aabc57394f64b82e48a758227a
(currently only built for Rawhide, and the ARM build is still running there).

Comment 4 Kevin Kofler 2014-02-16 20:45:43 UTC
Can you please test the following scratch build?
http://koji.fedoraproject.org/koji/taskinfo?taskID=6535919

(That's a kdelibs-4.11.5 build for Fedora 20 with the fix. I did it as a scratch build because the official update will be for 4.12.2, which is now in updates-testing.)

Comment 5 Piotr Dobrogost 2014-02-16 22:31:29 UTC
(In reply to Kevin Kofler from comment #4)

Thanks for acting so quicky on this.

> Can you please test the following scratch build?
> http://koji.fedoraproject.org/koji/taskinfo?taskID=6535919

I'd like to but being new to Linux/Fedora/KDE I need some help.
I guess I need to install all rpms from http://koji.fedoraproject.org/koji/taskinfo?taskID=6535935
As there are inter dependencies I figured I would try to pass all rpms to yum: 
--------
[piotr@demon tmp]$ sudo yum install ./kde*
(...)
Transaction Summary
Install  2 Packages (+39 Dependent packages)
Upgrade  3 Packages

Total size: 922 M
--------

I take these 39 Dependent packages to mean it's not the right way...
So I tried to install kdelibs-4.11.5-2.fc20.x86_64.rpm:
--------
[piotr@demon tmp]$ sudo yum install ./kdelibs-4.11.5-2.fc20.x86_64.rpm
Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit
Examining ./kdelibs-4.11.5-2.fc20.x86_64.rpm: 6:kdelibs-4.11.5-2.fc20.x86_64
Marking ./kdelibs-4.11.5-2.fc20.x86_64.rpm as an update to 6:kdelibs-4.11.5-1.fc20.x86_64
Resolving Dependencies
--> Running transaction check
---> Package kdelibs.x86_64 6:4.11.5-1.fc20 will be updated
---> Package kdelibs.x86_64 6:4.11.5-2.fc20 will be an update
--> Processing Dependency: kdelibs-common = 6:4.11.5-2.fc20 for package: 6:kdelibs-4.11.5-2.fc20.x86_64
--> Finished Dependency Resolution
Error: Package: 6:kdelibs-4.11.5-2.fc20.x86_64 (/kdelibs-4.11.5-2.fc20.x86_64)
           Requires: kdelibs-common = 6:4.11.5-2.fc20
           Installed: 6:kdelibs-common-4.11.5-1.fc20.x86_64 (@updates)
               kdelibs-common = 6:4.11.5-1.fc20
           Available: 6:kdelibs-common-4.11.3-9.fc20.x86_64 (fedora)
               kdelibs-common = 6:4.11.3-9.fc20
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
--------

As it depends on kdelibs-common-4.11.5-2.fc20 I tried to install this first:
--------
[piotr@demon tmp]$ sudo yum install ./kdelibs-common-4.11.5-2.fc20.x86_64.rpm
Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit
Examining ./kdelibs-common-4.11.5-2.fc20.x86_64.rpm: 6:kdelibs-common-4.11.5-2.fc20.x86_64
Marking ./kdelibs-common-4.11.5-2.fc20.x86_64.rpm as an update to 6:kdelibs-common-4.11.5-1.fc20.x86_64
Resolving Dependencies
--> Running transaction check
---> Package kdelibs-common.x86_64 6:4.11.5-1.fc20 will be updated
--> Processing Dependency: kdelibs-common = 6:4.11.5-1.fc20 for package: 6:kdelibs-4.11.5-1.fc20.x86_64
---> Package kdelibs-common.x86_64 6:4.11.5-2.fc20 will be an update
--> Finished Dependency Resolution
Error: Package: 6:kdelibs-4.11.5-1.fc20.x86_64 (@updates)
           Requires: kdelibs-common = 6:4.11.5-1.fc20
           Removing: 6:kdelibs-common-4.11.5-1.fc20.x86_64 (@updates)
               kdelibs-common = 6:4.11.5-1.fc20
           Updated By: 6:kdelibs-common-4.11.5-2.fc20.x86_64 (/kdelibs-common-4.11.5-2.fc20.x86_64)
               kdelibs-common = 6:4.11.5-2.fc20
           Available: 6:kdelibs-common-4.11.3-9.fc20.x86_64 (fedora)
               kdelibs-common = 6:4.11.3-9.fc20
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
--------
And here I'm lost...

Btw, could you elaborate on the reason for this error which you briefly described in comment 2 so that someone like me without knowledge of KDE and Fedora could understand?

Comment 6 Kevin Kofler 2014-02-16 22:59:16 UTC
You need to update kdelibs and kdelibs-common together, as they depend on each other. (The unwanted additional dependencies when you tried with kde* probably come from kdelibs-devel. The -devel, -apidocs and -debuginfo packages are all optional, and you apparently don't have them installed, so you don't have to update them either.)

So in short, you want:
sudo yum install ./kdelibs-4.11.5-2.fc20.x86_64.rpm ./kdelibs-common-4.11.5-2.fc20.x86_64.rpm
(all in one line).

So, does that fix your problem?


And to answer your question, the problem in my code I quoted in comment #2 is that it asks Plasma for what script engines it has available for applets (widgets) if you are installing a Plasma applet (widget), data engines if you are installing a Plasma data engine, runners if you are installing a Plasma runner or wallpapers if you are installing a Plasma wallpaper (the ones animated by scripts). Now the problem is that what you are installing is none of these, but a KWin script. That is not a Plasma component to begin with, but only reuses the "Plasma package" infrastructure. Therefore, Plasma cannot know what script engines are available for KWin scripts. (There is, in fact, exactly one, declarativescript, hardcoded in KWin itself.)

Therefore, I fixed the code so that if what you are installing is not one of the 4 known Plasma component types listed above, it will just not ask Plasma for whether the script engine is available, and instead assume it is available. At least for KWin scripts, the "declarativescript" script engine (the only allowed one) is provided by KWin itself and therefore always available. If the script engine is really missing at runtime (when KWin tries to load it), you get a PackageKit prompt for it at runtime, but in KWin, that should never happen.

(Sorry, given that you are installing KWin scripts from git, I was somehow expecting you to be familiar with KWin development, or I would have written something more detailed right away.)

Comment 7 Piotr Dobrogost 2014-02-17 20:25:21 UTC
(In reply to Kevin Kofler from comment #6)
> You need to update kdelibs and kdelibs-common together, as they depend on
> each other. 

That kdelibs package depends on kdelibs-common I can see looking at 'Requires: kdelibs-common = 6:4.11.5-2.fc20' line. But how would I know that kdelibs-common depends on kdelibs if all I see is 'Requires: kdelibs-common = 6:4.11.5-1.fc20' when trying to install/up kdelibs-common?

> (The unwanted additional dependencies when you tried with kde*
> probably come from kdelibs-devel. The -devel, -apidocs and -debuginfo
> packages are all optional, and you apparently don't have them installed, so
> you don't have to update them either.)
> 
> So in short, you want:
> sudo yum install ./kdelibs-4.11.5-2.fc20.x86_64.rpm
> ./kdelibs-common-4.11.5-2.fc20.x86_64.rpm
> (all in one line).

Thanks for info.
 
> So, does that fix your problem?

Yes, it does. After installing with
sudo yum install ./kdelibs-4.11.5-2.fc20.x86_64.rpm ./kdelibs-common-4.11.5-2.fc20.x86_64.rpm
the problem is gone:
[piotr@demon kwin-tiling]$ plasmapkg --type kwinscript -i .
Successfully installed /var/tmp/kwin-tiling

> And to answer your question, the problem in my code I quoted in comment #2
> is that it asks Plasma for what script engines it has available for applets
> (widgets) if you are installing a Plasma applet (widget), data engines if
> you are installing a Plasma data engine, runners if you are installing a
> Plasma runner or wallpapers if you are installing a Plasma wallpaper (the
> ones animated by scripts).

What's the reason for probing for these? Is it to avoid installing something already installed or is it to make sure some dependencies are met?

> Now the problem is that what you are installing
> is none of these, but a KWin script. That is not a Plasma component to begin
> with, but only reuses the "Plasma package" infrastructure. Therefore, Plasma
> cannot know what script engines are available for KWin scripts. (There is,
> in fact, exactly one, declarativescript, hard-coded in KWin itself.)

It sounds like "promoting" scripts to component status would allow for clean integration with existing infrastructure which apparently is designed around component model.

> Therefore, I fixed the code so that if what you are installing is not one of
> the 4 known Plasma component types listed above, it will just not ask Plasma
> for whether the script engine is available, and instead assume it is
> available. At least for KWin scripts, the "declarativescript" script engine
> (the only allowed one) is provided by KWin itself and therefore always
> available. If the script engine is really missing at runtime (when KWin
> tries to load it), you get a PackageKit prompt for it at runtime, but in
> KWin, that should never happen.
 
I take "At least for KWin scripts(...)" to mean there are other types of scripts. If so then could it be that changing behavior to "not ask Plasma for whether the script engine is available" could lead to them not functioning in part or in whole?

Also after I read your statement from comment #2:

> The problem is that plasmapkg knows neither about the RPM database (i.e. our
> explicit Provides) nor about the stuff internally provided by KWin. It (in

it seems like plasmapkg is neither integrated with the distribution ("knows neither about the RPM database") nor with KDE/Plasma itself ("nor about the stuff internally provided by KWin"). If that's the case then it's rather glaring shortcoming of plasmapkg if not the whole packaging model.  Are there any plans to fix this?

> (Sorry, given that you are installing KWin scripts from git, I was somehow
> expecting you to be familiar with KWin development, or I would have written
> something more detailed right away.)

Sure. Thank you for taking time to answer all my questions. I'm aware my questions are rather general and are not directly relevant to this issue. If you could point me to some docs where I could read more about packaging in KDE/Plasma that would be nice.


The last question – would you agree with faho's statement (https://github.com/faho/kwin-tiling/issues/14#issuecomment-35181315) that "It's a Fedora bug"?

Comment 8 Rex Dieter 2014-02-17 20:50:12 UTC
Not strictly a fedora-only
 bug.  It's a bug in a feature we helped develop for upstream, to dynamically install plasma resources on demand via PackageKit.  Fedora happens to be one distro that enables this feature by default.  Some don't.

Comment 9 Kevin Kofler 2014-02-17 21:07:01 UTC
> That kdelibs package depends on kdelibs-common I can see looking at 'Requires:
> kdelibs-common = 6:4.11.5-2.fc20' line. But how would I know that
> kdelibs-common depends on kdelibs if all I see is 'Requires: kdelibs-common =
> 6:4.11.5-1.fc20' when trying to install/up kdelibs-common?

Well, strictly speaking, kdelibs-common does not depend on kdelibs, but kdelibs depends on the exact version of kdelibs-common ('=' versioned dependency, not '>='), so you cannot upgrade one (no matter which one) without also upgrading the other.

> > So, does that fix your problem?
>
> Yes, it does.

Great. I'm going to push official updates.

> It sounds like "promoting" scripts to component status would allow for clean
> integration with existing infrastructure which apparently is designed around
> component model.

That's why they use the Plasma package infrastructure in the first place. My point is that the script is not a PLASMA component, but a KWin component, so libplasma doesn't know what script engines are available to it. (Only KWin knows.)

> I take "At least for KWin scripts(...)" to mean there are other types of
> scripts.

Actually, I don't know whether there are any other components other than the 4 types of Plasma components I listed and KWin scripts using the Plasma package infrastructure. "At least for KWin scripts" means that I cannot speak about anything else because I don't know if it even exists, let alone how it works if it does.

> If so then could it be that changing behavior to "not ask Plasma for whether
> the script engine is available" could lead to them not functioning in part or
> in whole?

It will definitely work no worse than in upstream because the feature to prompt for script engine installation with PackageKit exists only in Fedora. (Upstream only carries the first part of my 3-part patchset, which snuck in accidentally after the kdelibs 4 permanent feature freeze, and it is now disabled by default upstream (because they refused to merge the other 2 patches and I refused to maintain the incomplete feature in that state). The feature which causes the problem here is part of the patch 2 (of 3), which is not upstream at all.)

> it seems like plasmapkg is neither integrated with the distribution ("knows
> neither about the RPM database") nor with KDE/Plasma itself ("nor about the
> stuff internally provided by KWin").

Plasmapkg is integrated with Plasma. KWin is not part of Plasma. (We are talking about the software actually called Plasma here, not about the marketing term "Plasma Workspace" which includes the whole KDE workspace including KWin. Blame upstream for their ambiguous terminology.)

@Rex Dieter:
> Not strictly a fedora-only bug.

This is definitely a Fedora-only bug. Patch 0002 is not upstream and will never be (because kdelibs 4 is feature-frozen). In fact, patch 0001 only entered by accident in the first place (which is one of the reasons it's now disabled by default upstream).

> It's a bug in a feature we helped develop for upstream, to dynamically install
> plasma resources on demand via PackageKit.  Fedora happens to be one distro
> that enables this feature by default.  Some don't.

AFAIK, Fedora happens to be THE one distro that enables this feature by default, unfortunately. :-(

Comment 10 Fedora Update System 2014-02-18 02:09:32 UTC
kdelibs-4.12.2-3.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/kdelibs-4.12.2-3.fc20

Comment 11 Fedora Update System 2014-02-18 02:10:41 UTC
kdelibs-4.11.5-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/kdelibs-4.11.5-2.fc19

Comment 12 Piotr Dobrogost 2014-02-19 20:38:29 UTC
After some updates have been installed (currently KDE is 4.12.2) I see this error again. How to make sure I have KDE with the patch applied (kdelibs-4.12.2-3.fc20)?

Comment 13 Kevin Kofler 2014-02-19 22:03:26 UTC
It will hit updates-testing in the next push, if you want it now, get it from:
http://koji.fedoraproject.org/koji/buildinfo?buildID=498598
and install it the same way you had installed 4.11.5-2.fc20.

Comment 14 Fedora Update System 2014-02-20 00:41:32 UTC
Package kdelibs-4.12.2-3.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kdelibs-4.12.2-3.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-2715/kdelibs-4.12.2-3.fc20
then log in and leave karma (feedback).

Comment 15 Kevin Kofler 2014-02-20 01:02:09 UTC
So, effective now, you should be able to install the fixed version with:
sudo yum --enablerepo=updates-testing --advisory=FEDORA-2014-2715 update

(Don't ask me why Bodhi still fails to tell you that instead of the line it gives you, which doesn't always work when subpackages are involved. That said, in this case, the line suggested by Bodhi should also work.)

Comment 16 Fedora Update System 2014-02-22 00:45:26 UTC
kdelibs-4.12.2-3.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 17 Piotr Dobrogost 2014-02-22 13:24:23 UTC
Created attachment 866381 [details]
update notification with special message icon next to kdelibs entry

Why do I see this special message icon next to kdelibs entry in update notification?

Comment 18 Kevin Kofler 2014-02-22 13:46:04 UTC
That's the icon of one of the .desktop files in kdelibs. PackageKit/Apper tries to be helpful and show icons from .desktop files, which makes sense for application packages, not so much for libraries of course.

Comment 19 Piotr Dobrogost 2014-02-22 14:07:22 UTC
Ok, but why do I see this icon next to kdelibs and no other entry? Also it's the first time I see this icon although I've seen several update notifications in the past. Coincidentally the information is about fixing this very bug which I raised...

Comment 20 Kevin Kofler 2014-02-22 14:13:30 UTC
Because the other packages do not have any .desktop files in them.

Comment 21 Fedora Update System 2014-03-08 03:31:19 UTC
kdelibs-4.11.5-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.