just learned of the new spins, krypton and argon

Okay, I updated.

There was a file conflict between “kimageformat” and “krita”. I continued anyway. Both appear to be from KUE.

Webkit is there after the update. And it showed up as the default (probably because I hadn’t changed that setting).

When I look at konqueror settings, it says that cookie management cannot be started. I’m not sure if that means that I will lose all cookies on closing the browser. Okay, I’m still logged into a site after closing the browser then restarting. So I guess it does remember cookies across sessions.

A couple of notes about my installed “krypton”.

(1) There was a major collision when updating this morning. I have reported that as bug 968709. The update wanted to install “calligra-krita” from the main repo, which collided with “krita” from the unstable-extras repo.

(2) There seems to be something broken with the “Folder view” widget. On original install, there wasn’t such a widget. So I added it. But, on login to KDE, it takes 3-5 minutes for the Folder-View to appear on the desktop. I have the panel set to “autohide”. And I am unable to access the panel until the Folder-View widget appears.

So I have now removed the Folder-View widget. And now there is no delay in accessing the auto-hide panel.

I have not reported a bug for this.

This has been fixed already.

I continued anyway. Both appear to be from KUE.

No, kimageformat is from KUF. It is part of KDE Frameworks and contains image file format plugins for Qt5.
The kra (Krita file format) and ora (OpenRaster) plugins have recently been added to kimageformat, but were still part of krita too.

Webkit is there after the update. And it showed up as the default (probably because I hadn’t changed that setting).

Yes. It is preferred.

When I look at konqueror settings, it says that cookie management cannot be started.
I’m not sure if that means that I will lose all cookies on closing the browser.

No, that just means that the cookies configuration module does not work.
The cookies service itself should work fine.

Yes. the krita package does not conflict with or obsolete calligra-krita (the KDE4 version) at all. That’s why you get file conflicts when installing both. And they will overwrite each others files, so if you install calligra-krita afterwards, you will only have the stable KDE4 version.

And calligra-krita is part of a default Tumbleweed installation, that’s probably why “zypper dup” wanted to install it in the first place.

(2) There seems to be something broken with the “Folder view” widget. On original install, there wasn’t such a widget.

Yes, I mentioned this on the factory mailinglist a few days ago.
The openSUSE branding is installed, so it should be there. It should be added to the desktop when logging in for the first time. But something apparently seems to go wrong there, although it seems to work on some systems as the Krypton creator cannot reproduce this.
I suspect some timing problem, i.e. a bug in (the unstable) upstream Plasma5.

Funny enough, I tried the Wayland ISO today, and there it worked for me.

So I added it. But, on login to KDE, it takes 3-5 minutes for the Folder-View to appear on the desktop. I have the panel set to “autohide”. And I am unable to access the panel until the Folder-View widget appears.

The folderview widget appears when plasmashell runs, which also controls the panel. So it’s obvious that you cannot access the panel before that.

So I have now removed the Folder-View widget. And now there is no delay in accessing the auto-hide panel.

So apparently the Folderview widget is causing the slow start of plasmashell.

Lots of brokenness with krypton after updating today.

(1) SDDM: I cannot change which desktop to login. It is currently stuck on Icewm. I had to switch to “lightdm” to be able to login to KDE.

(2) Desktop settings. It comes up as an empty window. So I cannot change wallpaper or layout or anything else.

(3) Task manager settings, system tray settings – both come up as an empty window. Perhaps the same bug as (2), and maybe (1) is also the same bug.

(4) Logout – doesn’t work. I can click on it, but nothing happens. I need to use CTRL-ALT-BACKSPACE to kill the session. This might also be the same bug as (2).

(5) Changing init levels: I did “telinit 3”. I intended to follow that with “telinit 5” to restart the display manager, after switching to “lightdm”. But either of those commands logs me out (as root). Maybe this one is a feature rather than a bug, and I’m guessing it is systemd related.

I have not filed any bug reports on these. Unless requested to file, I’ll just check what happens after the next time that I update.

Okay, I updated today. And problems (1-4) have all gone away. I’m guessing that they were all symptoms of the same bug.

Note that there was no Tumbleweed update. But some of those unstable repos had been updated.

Might also have been a temporary inconsistency in the repos.
Can happen with the unstable repos.

But good to hear that the problems are gone.

Note that there was no Tumbleweed update. But some of those unstable repos had been updated.

Yes, they are updated all the time. Depends on the package though of course (and whether there are upstream changes to that specific application/bundle). Some packages are updated more often than others, and sometimes even multiple times a day…

Some more notes on “krypton”. Again, I don’t plan to report bugs on these unless requested.

Today I installed “rekonq5”.

According to the description shown by Yast, that’s a terminal application. Fortunately the description is wrong, and it is the plasma5 version of “rekonq”. The description is just wrong.

I experimented with “rekonq” (which is “rekonq5”), with “konqueror” and with “akregator” (both are also the “5” versions).

I mostly wanted to check the interaction of rekonq, akregator and konqueror.

Good news: rekonq and konqueror still share the same bookmarks and the same cookies. If I login to a site with “konqueror”, then I am seen as logged in when using “rekonq”.

Not so good: “akregator” does not appear to be sharing those cookies. So opening a page in the “akregator” builtin browser shows me as not logged in, when I am seen as logged into that site with “rekonq” and “konqueror”. I don’t know if this is something to be implemented in the future, or if this is a feature change since the way it worked with KDE4.

The more annoying problem is opening an “akregator” article in an external browser. It works fine with “firefox” as the default browser, but not with “konqueror” or “rekonq”.

If I type in “konqueror” as the default browser entry (in system settings), then it does open the article in “konqueror”. But it always opens a new “konqueror” window. I can’t get it to open in a new tab. The trick in KDE4 was to set the default browser to “an application based on file type”. And that still works after a fashion in Leap (with “akregator4” and “konqueror4”). But in “krypton”, that just uses “firefox” as default browser. And, yes, I check file associations, and set “konqueror” as first listed for “text/html”.

With “rekonq” it is worse. If I type in “rekonq” as the default browser, the use “akregator” to open an article in the external browser, it does open in “rekonq”. But every new article opened starts a new “rekonq”. And it is not just a new window for the running “rekonq”. I get a message showing on “rekonq” saying something like “the browser was not properly shutdown: restore previous session? Yes/No”. Even weirder, this improper shutdown message sometimes shows in the newly opened “rekonq” and sometimes in the already opened older “rekonq”.

And a reminder – I’m treating “krypton” as a play system for experimenting. I’m not using it for serious work. So the weird behavior isn’t a major problem for me (yet).

Okay, I got that wrong. The problem is the summary line which says “KDE terminal”. The description is fine.

I have just noticed something odd.

On my “krypton” system, the directory “/boot/grub2” and everything in that directory has group “users”. On all of my other opensuse systems, it uses group “root”.

To me, this looks like a mistake (perhaps a mistake made preparing the krypton live iso).

I don’t see anything that’s group-writable, so probably not a serious mistake.

Yes, the description is “KDE Terminal” for some reason. Apparently the person who created the unstable package months (or actually over a year) ago used the konsole spec file as template and forgot to change that.

I’ll fix it.

Not so good: “akregator” does not appear to be sharing those cookies. So opening a page in the “akregator” builtin browser shows me as not logged in, when I am seen as logged into that site with “rekonq” and “konqueror”. I don’t know if this is something to be implemented in the future, or if this is a feature change since the way it worked with KDE4.

I’m not sure, but I think akregator has been ported away from WebKit and uses WebEngine now (i.e. chromium).

The more annoying problem is opening an “akregator” article in an external browser. It works fine with “firefox” as the default browser, but not with “konqueror” or “rekonq”.

Sounds like the old problem with setting the default browser…

Well, that seems to come from Tumbleweed, I suppose.

Definitely not caused by the unstable KDE packages… :wink:

I agree that it doesn’t come from the unstable KDE packages. But I have not previously seen this in Tumbleweed, and I don’t see it on the lastest live KDE Tumbleweed (which does not seem to have an installer so I couldn’t install).

Possibly it comes from how the krypton live media was prepared. I used the original krypton release when I installed, so it might have changed by now.

I ran into some issues today, updating “krypton”:


File /usr/lib64/qt5/plugins/kf5/kio/ldap.so
  from install of
     libKF5Ldap5-16.07.70git.20160403T203827~be1dda4-34.1.x86_64 (KUA)
  conflicts with file from install of
     kio-pimlibs-16.07.70git.20160403T112015~e3de1cd-283.1.x86_64 (KUA)

It looks as if two packages in the same repo are providing the same file. I postponed the update for now, though I’m probably not using that plugin.

And there was an earlier dependency conflict:


Problem: plasma5-unstable-pkglist-5.5.90-29.1.x86_64 requires akonadi-server, but this requirement cannot be provided
  deleted providers: akonadi-16.07.70git.20160330T031216~bf2fddd-89.1.x86_64
uninstallable providers: akonadi-server-15.12.3-1.1.i586[repo-oss]
                   akonadi-server-15.12.3-1.1.x86_64[repo-oss]
 Solution 1: keep obsolete akonadi-16.07.70git.20160330T031216~bf2fddd-89.1.x86_64
 Solution 2: deinstallation of plasma5-unstable-pkglist-5.5.90-29.1.x86_64
 Solution 3: break plasma5-unstable-pkglist-5.5.90-29.1.x86_64 by ignoring some of its dependencies

I took solution 1 for that. Though I guess that didn’t take effect either, since I aborted on the file conflict.

I’ll try again after the next tumbleweed snapshot is out.

There’s a major splitting and reshuffling going on currently in KDEPIM upstream.
So there may be temporary duplications.
That’s something you actually have to expect when using unstable packages (though it shouldn’t happen that often either).

We could workaround it in our packages, but it’s probably not worth the effort as it should be fixed upstream with one of the next updates I suppose. (and of course it might not even have been noticed yet, the packages are built automatically and updated semi-automatically)

I postponed the update for now, though I’m probably not using that plugin.

The file conflict should not cause a problem, especially if you are not using the ldap kio-slave anyway.

And there was an earlier dependency conflict:

Problem: plasma5-unstable-pkglist-5.5.90-29.1.x86_64 requires akonadi-server, but this requirement cannot be provided
deleted providers: akonadi-16.07.70git.20160330T031216~bf2fddd-89.1.x86_64
uninstallable providers: akonadi-server-15.12.3-1.1.i586[repo-oss]
akonadi-server-15.12.3-1.1.x86_64[repo-oss]
Solution 1: keep obsolete akonadi-16.07.70git.20160330T031216~bf2fddd-89.1.x86_64
Solution 2: deinstallation of plasma5-unstable-pkglist-5.5.90-29.1.x86_64
Solution 3: break plasma5-unstable-pkglist-5.5.90-29.1.x86_64 by ignoring some of its dependencies

I took solution 1 for that. Though I guess that didn’t take effect either, since I aborted on the file conflict.

You shouldn’t have plasma5-unstable-pkglist installed in the first place. That just contains the list of packages that should be included in the LiveCD image.
So Solution 2 is the correct one.

The reason for this conflict seems to be that akonadi-server has been renamed to akonadi in the unstable repo apparently, but the package list has not been adjusted yet.
Not a problem unless wanting to build a new Argon/Krypton LiveCD image.

PS: The upstream developer apparently “forgot” to remove the ldap kio-slave from kdepimlibs when moving it to kldap, it has been fixed already though:
https://quickgit.kde.org/?p=kdepimlibs.git&a=commit&h=a86db8844e9438760e6488ff0b344f626f32aa7b

So the file conflict should be gone in the next package update.

Thanks for the feedback.

Surprisingly stable , but some videos freezes the entire desktop , have tested both VLC and beta no difference normally after one minute guess some codec don’t work yet?

> Krypton Wayland 64bit

“elin@idefix:~> vlc & sleep 195 ; kill $!
[1] 9032
VLC media player 3.0.0-git Vetinari (revision 3.0.0-git)
[0000000002369be8] core libvlc: Running vlc with the default interface. Use ‘cvlc’ to use vlc without interface.
libva info: VA-API version 0.38.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function vaDriverInit_0_38
libva info: va_openDriver() returns 0
[00007f48880009d8] core input error: ES_OUT_SET
(GROUP
)PCR is called too late (pts_delay increased to 300 ms)
[00007f48880009d8] core input error: ES_OUT_RESET_PCR called
[00007f48880009d8] core input error: ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased to 1025 ms)
[00007f48880009d8] core input error: ES_OUT_RESET_PCR called
[00007f48880009d8] core input error: ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased to 1376 ms)
[00007f48880009d8] core input error: ES_OUT_RESET_PCR called
[00007f48880009d8] core input error: ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased to 2344 ms)
[00007f48880009d8] core input error: ES_OUT_RESET_PCR called
elin@idefix:~> [00007f48880009d8] core input error: cannot delete callback 0x7f48d4f1f120 from nonexistent variable ‘next-title’
[00007f48880009d8] core input error: cannot delete callback 0x7f48d4f1f120 from nonexistent variable ‘prev-title’
[00007f48880009d8] core input error: cannot delete callback 0x7f48d4f1f120 from nonexistent variable ‘menu-popup’
[00007f48880009d8] core input error: cannot delete callback 0x7f48d4f1efe0 from nonexistent variable ‘next-chapter’
[00007f48880009d8] core input error: cannot delete callback 0x7f48d4f1efe0 from nonexistent variable ‘prev-chapter’”

So for today’s update, I went with solution 2.
That gave me another conflict:


2 Problems:
Problem: plasma5-unstable-5.5.90-5.1.x86_64 requires plasma5-unstable-pkglist, but this requirement cannot be provided

Problem:plasma5-unstable-pkglist-5.5.90-29.1.x86_64 requires akonadi-server, but this requirement cannot be provided

So I reverted to using solution 1. Maybe I could just have uninstalled plasma5-unstable, but I wasn’t sure enough of that.

If I should not have “plasma5-unstable-pkglist” or “plasma5-unstable” one wonders why they are still in the repo.

After going with solution 1 (keep the previous “akonadi”, I finished with 5 file conflicts. But they were all PIM related, so I went ahead anyway. So far, it looks okay.

That’s exactly the same problem. You could (should?) remove both plasma5-unstable and plasma5-unstable-pkglist.

If I should not have “plasma5-unstable-pkglist” or “plasma5-unstable” one wonders why they are still in the repo.

The package description of both says this:

Summary     : Patterns for Installation (full ftp tree)
Description :
This is an internal package that is used to create the patterns as part
of the installation source setup.  Installation of this package does
not make sense.

They are required to build the LiveCD images. They probably shouldn’t have been published in the repo though.

After going with solution 1 (keep the previous “akonadi”, I finished with 5 file conflicts. But they were all PIM related, so I went ahead anyway. So far, it looks okay.

Well, the kdepimlibs package is updated meanwhile, and kio-pimlibs (which caused the file conflict you posted earlier) has been removed.
Maybe you still have it installed? Try to uninstall it, its contents is moved elsewhere as mentioned, the package has been dropped.

Thanks. I’ll try that today. Maybe I’ll remove them first before starting the update.

Well, the kdepimlibs package is updated meanwhile, and kio-pimlibs (which caused the file conflict you posted earlier) has been removed.

Okay, thanks. That package was in all five file conflicts. I’ll remove it before I update today.e