Files could not be expanded: openSUSE:Factory/plasma5-workspace: package 'plasma5-workspace' does not exist

plasma5-workspace

Edit Package plasma5-workspace
No description set
Refresh
Refresh
Source Files

Sources could not be expanded: openSUSE:Factory/plasma5-workspace: package 'plasma5-workspace' does not exist

Show unmerged sources

Comments 12

Andreas Kilgus's avatar

Hi Wolfgang,

upstream removed the functionality to let konqueror show the favicon of the currrently displayed website in the taskbar instead of its application icon. This renders my taskbar almost useless in most of (not only) my usecases. There's a patch known to bring back this functionality - that upstream refuses to apply. AFAIK the package I comment is the package the patch is aimed for.

http://linux.overshoot.tv/wiki/konqueror_taskbar_icon https://bugs.kde.org/show_bug.cgi?id=369658

Since I assume that you don't like the idea of patching your package "against upstreams will" (and I can understand that), I'm thinking about a package of my own with this patch applied. Ideally located in build service in my own home directory (to create then) and based on your package, so I can technically stand on your shoulders (g) and get patched updates without manual intervention. Before I start digging in build service docs: Can something like that work using build service? You update your package, my build directory clones your update, applies the patch, builds my package, this package reaches me using zypper?

Best Andi


Wolfgang Bauer's avatar

Since I assume that you don't like the idea of patching your package "against upstreams will" (and I can understand that) Well, I'm not strictly opposed to that, this is my personal home repo after all... ;-) I do have some patches that are clearly "against upstreams will", but are necessary to have KDE4 and Plasma5 coexist in the first place.

I'm not sure about this particular one though. It apparently changes the behavior, and one of the goals of this repo was (and is) to follow the upstream development (I also use it to test or investigate reported bugs). It also means I have to maintain the patch and adapt it to new Plasma versions. It may even change things for other applications as I understand it.

So I'm probably not going to add it, I think...

I'm thinking about a package of my own with this patch applied. Ideally located in build service in my own home directory (to create then) and based on your package, so I can technically stand on your shoulders (g) and get patched updates without manual intervention. Before I start digging in build service docs: Can something like that work using build service? You update your package, my build directory clones your update, applies the patch, builds my package, this package reaches me using zypper?

Yes that's possible, and quite easy even. (actually that's how I "maintain" all the KF5/Plasma5 packages here... ;-) )

Just click on "Branch Package", this will create a linked copy in your home repo (actually in a sub repo named "home:xxx:branches:...". You can make your own changes there, and changes in the original will "dripple" through too.

Alternatively, you can click on "Branch a package" in your home repo and type in the repo and package you want to branch from.

Be aware that there may be conflicts though if the original changes that OBS cannot manage to resolve itself, your package will be in state "broken" then. I have no idea how much knowledge you have about OBS, but feel free to ask me if you encounter such problems.


Andreas Kilgus's avatar

Thanks for your answer and the explanations. I must have missed the corresponding info e-mail normally sent - I just got to see your comment by chance right now.

Anyway, this all sounds quite better and probably easier to manage than expected. Which is very good news - as my knowledge about the build service other than using it for getting software not found in the official repos is an euphemistic zero at the time being. :-)

Some time this week I'm going to try to follow your instructions above. I'm curious how far I'm going to get. :-)

... all these circumstances for that "much" of a patch:


diff --git a/libtaskmanager/xwindowtasksmodel.cpp b/libtaskmanager/xwindowtasksmodel.cpp index ad0bdf6..e18d573 100644 --- a/libtaskmanager/xwindowtasksmodel.cpp +++ b/libtaskmanager/xwindowtasksmodel.cpp @@ -458,12 +458,6 @@ AppData XWindowTasksModel::Private::appData(WId window)

QIcon XWindowTasksModel::Private::icon(WId window) {

- const AppData &app = appData(window);

  • if (!app.icon.isNull()) {
  • return app.icon;

- }

 QIcon icon;

 icon.addPixmap(KWindowSystem::icon(window, KIconLoader::SizeSmall, KIconLoader::SizeSmall, false));

A simple configuration option ("display favicons in taskbar" - yes/no) would have made both sides smile ... sigh


Andreas Kilgus's avatar

OK, posting code seems to get partly misinterpreted as markup. Here's the patch, if you're interested:: https://bugsfiles.kde.org/attachment.cgi?id=103788


Wolfgang Bauer's avatar

Yes, I am aware of the patch. My reply was based on looking at that too... (and the upstream reactions of course)

And yes, the webinterface seems to mess up things sometimes, my reply to you too... ;-(


Andreas Kilgus's avatar

Successfully branched your package - favicons have returned. :-) Maybe I additionally branch LTS and the official 42.2 repo adding the patch so others not using your repo (or a possible future me using LTS) can have back favicons, too.

But in the not so long term I am that much annoyed by the ease my workflow once again gets significantly broken (and not for the first time just because of "by design", concerning KDE) that I am looking for an alternative. Either I am going to try to write a taskbar replacement of my own (though I am not that keen on tying me even stronger to KDE and I am new to the API) or I am going to try to implement some as far as possible DE-independent session-within-a-session concept I am using Plasma's activities for at the moment to be able to switch to e.g. XFCE.

Anyway - thanks for your help.


Andreas Kilgus's avatar

Is there a way to build the packages so they are available for interested users, but let the packages not be listed/found via http://software.opensuse.org/package/plasma5-workspace - since the only difference for all repositories I branched is the favicon patch?


Wolfgang Bauer's avatar

Sorry for the late reply. But no, I don't think there is a way unfortunately.


Andreas Kilgus's avatar

Never mind and thanks. FTR: I branched plasma5-workspace of 42.2-Update, Frameworks5 and Frameworks5-LTS. I deleted my branch of your repo at the moment the source of your branch switched to beta versions, I will delete my branch of Frameworks5, since this repo switched recently to supply beta packages, too. Without any info on https://de.opensuse.org/KDE_Repositorys and https://en.opensuse.org/SDB:KDE_repositories. At the moment there seem to be no repos available that supply the current stable releases of Plasma5, KF5 and Applications for Leap - correct?


Wolfgang Bauer's avatar

Correct, except that KF5 and Applications are the latest stable releases in KDE:Applications and KDE:Frameworks5. Plasma currently is the latest beta release in KDE:Frameworks5.

But 5.10.0 is going to be released in less than two weeks already.


Andreas Kilgus's avatar

I have no idea how much knowledge you have about OBS, but feel free to ask me if you encounter such problems.

Thanks for the offer - here I am. ;-)

For quite some time my derived repo https://build.opensuse.org/package/show/home:akilgus:branches:KDE:Frameworks5/plasma5-workspace had worked without any hassle (almost), but now I am stuck because I have no idea how to get rid of the following error message and the resulting build lock:

"unresolvable: nothing provides cmake(Breeze) >= 5.25.2, (got version 5.25.1 provided by breeze5-style)"

The only differences of my branched project compared to the parent project are my two patch files and the corresponding changes in plasma5-workspace.spec. Do you have any suggestions where I should have a look to make the build work again?


Andreas Kilgus's avatar

Solved. There was nothing I had to change - "osc rebuild -f" lead to successfully built packages. Seems to have been some kind of race condition in the build service that stopped any future attempts to build the packages automatically again.

openSUSE Build Service is sponsored by