[opensuse-kde] Leap packaging/polish issues
Unfortunately I'm very late to the Leap testing, but I found some issues in RC1 which are important to the overall impression, and are probably pretty easy to fix: * There's no video player included in the default installation at all. I would suggest to include vlc-qt. Secondly kaffeine, third dragon. * An upstream Plasma wallpaper is used by default, not the Leap wallpaper, which is available in the desktop settings. * On login KMix crashes cuz of PulseAudio breakage. But I thought KMix shouldn't be started on Plasma >=5.4 by default. Maybe not even be installed by default on a fresh installation? Or is this a conscious decision? * File indexing is enabled by default. I haven't seen to many complaints about Baloo recently, but it still seems a risky default. Given that file indexers have a tendency to blow up sooner or later. * The adwaita GTK style is used by default. Is this intentional? (breezygtk is not installed by default either, but I guess it's not very mature, and can potentially crash gtk apps). But overall I'm looking forward to finally migrating to Plasma5! And some other issues, which aren't so easy, but probably already handled: * Gwenview5 is not installable. Because it requires "application- appdata(gwenview.appdata.xml)". I guess this might be caused by the inconsistent state with a mix of 15.04 and 15.08 applications. I'd still prefer gwenview"4" anyway cuz of the kipiplugins. * Amarok crashes on startup. But I'm pretty sure that's also related to the pulseaudio breakage. * Sddm is not themed. But that's probably not that easy to do. And most users probably use autologin anyway. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Lørdag den 17. oktober 2015 18:05:00 skrev Martin Schlander:
Unfortunately I'm very late to the Leap testing, but I found some issues in RC1 which are important to the overall impression, and are probably pretty easy to fix:
* An upstream Plasma wallpaper is used by default, not the Leap wallpaper, which is available in the desktop settings.
Oops. The wallpaper issue was my mistake. The correct wallpaper _is_ used by default. But in turn I forgot another point: * Classic application menu is used by default. Is this intended? I would prefer kickoff, and seconly the fullscreen dashboard. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data sabato 17 ottobre 2015 18:05:00 CEST, Martin Schlander ha scritto:
* On login KMix crashes cuz of PulseAudio breakage. But I thought KMix
At this point anythign using audio will crash. However the fix will be checked in for the final release already (it's a bug in PA).
* The adwaita GTK style is used by default. Is this intentional? (breezygtk is not installed by default either, but I guess it's not very mature, and
The breezy-gtk theme hasn't had an official release yet, as far as I can see.
inconsistent state with a mix of 15.04 and 15.08 applications. I'd still
PIM 15.08 was blocked due to legal review (some issues on kdepimlibs licensing). Those have been solved.
* Sddm is not themed. But that's probably not that easy to do. And most users probably use autologin anyway.
Do you mean it uses upstream KDE (not the SDDM upstream theme, which is another) theme? -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: A29D259B
Lørdag den 17. oktober 2015 18:27:07 skrev Luca Beltrame:
In data sabato 17 ottobre 2015 18:05:00 CEST, Martin Schlander ha scritto:
* On login KMix crashes cuz of PulseAudio breakage. But I thought KMix
At this point anythign using audio will crash. However the fix will be checked in for the final release already (it's a bug in PA).
But in order to crash it first has to try to start. And I don't get why KMix is even installed and trying to start on a fresh, default RC1 installation - where the PA plasmoid is also installed and running. Imho KMix should not be installed by default on RC1. And if it _is_ installed it should somehow be blocked from starting in parallel with the plasmoid.
* Sddm is not themed. But that's probably not that easy to do. And most users probably use autologin anyway.
Do you mean it uses upstream KDE (not the SDDM upstream theme, which is another) theme?
I meant it doesn't have an openSUSE theme. But like I said, that's in the "nice-to-have" category anyway. So no biggie. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Saturday, October 17, 2015 06:05:00 PM Martin Schlander wrote:
Unfortunately I'm very late to the Leap testing, but I found some issues in RC1 which are important to the overall impression, and are probably pretty easy to fix:
Hi Martin, tnx for the feedback!
* There's no video player included in the default installation at all. I would suggest to include vlc-qt. Secondly kaffeine, third dragon. Submitted a patterns change to devel project & Leap (with vlc-qt as default).
* An upstream Plasma wallpaper is used by default, not the Leap wallpaper, which is available in the desktop settings.
* On login KMix crashes cuz of PulseAudio breakage. But I thought KMix shouldn't be started on Plasma >=5.4 by default. Maybe not even be installed by default on a fresh installation? Or is this a conscious decision? Submitted a patterns change to devel project & Leap.
* File indexing is enabled by default. I haven't seen to many complaints about Baloo recently, but it still seems a risky default. Given that file indexers have a tendency to blow up sooner or later. File indexer is in good enough state to leave it on (and there haven't been any requests to disable it till now).
* The adwaita GTK style is used by default. Is this intentional? (breezygtk is not installed by default either, but I guess it's not very mature, and can potentially crash gtk apps). Fixed in devel project and submitted to Leap. If it proves to be crashy, we can revert. No indication for that yet though =)
But overall I'm looking forward to finally migrating to Plasma5!
And some other issues, which aren't so easy, but probably already handled:
* Gwenview5 is not installable. Because it requires "application- appdata(gwenview.appdata.xml)". I guess this might be caused by the inconsistent state with a mix of 15.04 and 15.08 applications. I'd still prefer gwenview"4" anyway cuz of the kipiplugins. Fixed in devel project and submitted to Leap.
* Amarok crashes on startup. But I'm pretty sure that's also related to the pulseaudio breakage.
* Sddm is not themed. But that's probably not that easy to do. And most users probably use autologin anyway. Fixed in devel project and submitted to Leap.
Cheers, Hrvoje
Søndag den 18. oktober 2015 19:28:05 skrev šumski:
On Saturday, October 17, 2015 06:05:00 PM Martin Schlander wrote:
Unfortunately I'm very late to the Leap testing, but I found some issues in RC1 which are important to the overall impression, and are probably pretty easy to fix:
tnx for the feedback!
Thanks for the fixes. These details should ensure that openSUSE Leap will be the best Plasma 5 experience out there ;-) -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Samstag, 17. Oktober 2015, 18:05:00 schrieb Martin Schlander:
* There's no video player included in the default installation at all. I would suggest to include vlc-qt. Secondly kaffeine, third dragon.
VLC is "broken" by default with Qt 5.5 at the moment. See e.g.: https://trac.videolan.org/vlc/ticket/15574 https://bugreports.qt.io/browse/QTBUG-48321 So maybe one of the other two might be a better choice? Or maybe we should build VLC against Qt4 again for now...
* File indexing is enabled by default. I haven't seen to many complaints about Baloo recently, but it still seems a risky default. Given that file indexers have a tendency to blow up sooner or later.
File indexing was enabled in 13.2 too, and actually ever since Baloo appeared in KDE 4.13. But at the moment, file searching (in dolphin at least) is broken on a fresh installation (also in Tumbleweed), because the KDE4 baloo-kioslaves are still installed by default, not the required baloo5-kioslaves. I think that should be fixed as well till the release, if we are talking about polishing... ;-) I'm not sure, but probably baloo5-tools instead of baloo-tools might make sense too. And I personally would like to see (but likely other users too) that we would _un_break Konqueror (for file management and things like ftp and smb) too. http://lists.opensuse.org/opensuse-factory/2015-10/msg00558.html Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Tirsdag den 20. oktober 2015 16:52:36 skrev Wolfgang Bauer:
VLC is "broken" by default with Qt 5.5 at the moment.
See e.g.: https://trac.videolan.org/vlc/ticket/15574 https://bugreports.qt.io/browse/QTBUG-48321
So maybe one of the other two might be a better choice? Or maybe we should build VLC against Qt4 again for now...
Hmm. Whatever we do, it needs to be somewhat coordinated with what Packman does. It's no use if we ship a working Qt4 VLC and users then switch to a broken Qt5 Packman build. I guess we should just go with Dragon player then. It's KF5 based and uses Phonon. So same codecs needed as Amarok.
* File indexing is enabled by default. I haven't seen to many complaints about Baloo recently, but it still seems a risky default. Given that file indexers have a tendency to blow up sooner or later.
File indexing was enabled in 13.2 too, and actually ever since Baloo appeared in KDE 4.13.
But at the moment, file searching (in dolphin at least) is broken on a fresh installation (also in Tumbleweed), because the KDE4 baloo-kioslaves are still installed by default, not the required baloo5-kioslaves.
Correct. Installating those packages made baloo features in Dolphin work quite nicely. I just never expect desktop search related things to work, so I didn't even comment on it not working before.
I'm not sure, but probably baloo5-tools instead of baloo-tools might make sense too.
And I personally would like to see (but likely other users too) that we would _un_break Konqueror (for file management and things like ftp and smb) too. http://lists.opensuse.org/opensuse-factory/2015-10/msg00558.html
That would be nice too. But less critical than the others. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Dienstag, 20. Oktober 2015, 19:03:10 schrieb Martin Schlander:
Hmm. Whatever we do, it needs to be somewhat coordinated with what Packman does. It's no use if we ship a working Qt4 VLC and users then switch to a broken Qt5 Packman build.
That's actually no problem at all. Packman's package is just a link to the one in Factory, so any change there will be inherited. Well, it's not a KDE problem anyway (except that the bug seems to be in Qt5.5), I mainly mentioned it here because it was about the default media player in a KDE installation.
I guess we should just go with Dragon player then. It's KF5 based and uses Phonon. So same codecs needed as Amarok.
Yeah, that's what I thought too. Probably good that I submitted dragonplayer to Leap 2 weeks ago, because I noticed it was still missing... ;-)
Correct. Installating those packages made baloo features in Dolphin work quite nicely. I just never expect desktop search related things to work, so I didn't even comment on it not working before.
I only noticed it because of this bug report: http://bugzilla.novell.com/show_bug.cgi?id=948810 I see now that šumski submitted a fix for this already, thanks!
That would be nice too. But less critical than the others.
I guess that depends whether you use Konqueror regularly or not... ;-) But well, personally I don't really care either as I build my own packages anyway. I just think that Konqueror is pretty much crippled currently, unnecessarily IMHO. And I think it is still installed by default even (I'm not sure about that though). Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Another thing that just crossed my mind when it comes to "polishing" the Leap release, so I want to mention it here... We don't have an update notifier yet in a default installation, or do we? This might be ok for Tumbleweed, but I really think there should be one for a released version. Many users (especially newbies) likely don't know that they should check YaST->Online Update or run zypper patch/up for getting updates, I suppose. Apper has not been ported yet. Well, the application itself has been but it isn't released yet, and especially the background service that actually checks for updates isn't and the plasmoid neither. Muon seemed to work nice with PackageKit when I last tried it, but that hasn't been submitted to Leap and is still at an outdated version 5.3.95 in KDE:Frameworks5 (although that was the version I tried, there were grave problems before). So probably not an option. But plasma5-pk-updates is in Leap, shouldn't we install (and enable it necessary) that by default too? The main problem here is probably that there are no translations. Still better than nothing I think. Opinions? Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On 10/20/2015 03:17 PM, Wolfgang Bauer wrote:
Another thing that just crossed my mind when it comes to "polishing" the Leap release, so I want to mention it here...
We don't have an update notifier yet in a default installation, or do we?
This might be ok for Tumbleweed, but I really think there should be one for a released version. Many users (especially newbies) likely don't know that they should check YaST->Online Update or run zypper patch/up for getting updates, I suppose.
Apper has not been ported yet. Well, the application itself has been but it isn't released yet, and especially the background service that actually checks for updates isn't and the plasmoid neither.
Muon seemed to work nice with PackageKit when I last tried it, but that hasn't been submitted to Leap and is still at an outdated version 5.3.95 in KDE:Frameworks5 (although that was the version I tried, there were grave problems before). So probably not an option.
But plasma5-pk-updates is in Leap, shouldn't we install (and enable it necessary) that by default too? The main problem here is probably that there are no translations. Still better than nothing I think.
Opinions?
I agree that this is very important if openSUSE wishes to be a general purpose distro, and not just for techies. zypper is great, but average users expect a gui update widget that just works without the need for them to understand details, or remember to do anything manually. Another thing that needs polishing are the shutdown and reboot buttons on the SDDM login screen--the ones that allow you to shutdown or reboot without having to login first. They don't work. A 30 second countdown starts, but when it reaches 0, instead of rebooting or shutting down, it just keep counting into negative numbers. The buttons to shutdown or logout immediately have no effect. I'm using 13.2, but I assume the same holds for Leap/Tumbleweed. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data martedì 20 ottobre 2015 18:18:02 CEST, mournblade ha scritto:
just keep counting into negative numbers. The buttons to shutdown or logout immediately have no effect. I'm using 13.2, but I assume the same holds for Leap/Tumbleweed.
The buttons work fine here. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: A29D259B
On 10/21/2015 12:11 AM, Luca Beltrame wrote:
In data martedì 20 ottobre 2015 18:18:02 CEST, mournblade ha scritto:
just keep counting into negative numbers. The buttons to shutdown or logout immediately have no effect. I'm using 13.2, but I assume the same holds for Leap/Tumbleweed. The buttons work fine here.
I am specifically referring to shutting down or restarting from the login screen after logging out from your session first or not having logged into a session yet. The buttons to directly shutdown or reboot from inside a live session work ok (except when plasmashell has become unstable). Could be 13.2 specific, I suppose. Not sure what would account for the difference though. Here is debian user reporting the exact same issue I'm having in openSUSE 13.2: https://lists.debian.org/debian-kde/2015/08/msg00166.html Someone also filed a bug report on github about this issue. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Mittwoch, 21. Oktober 2015, 02:04:36 schrieb mournblade:
Could be 13.2 specific, I suppose. Not sure what would account for the difference though.
Hm, I don't have this problem either, and I am using 13.2. But AIUI the problem is not the countdown, but that shutdown/reboot is not working for some reason. sddm uses systemd's systemctl by default, in the bug report you mentioned, the user still used sysvinit. It might also be a permissions problem. Does "systemctl reboot" work? (as normal user) Have you tried another SDDM theme? Only breeze shows that countdown AFAIK. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data martedì 20 ottobre 2015 22:17:42 CEST, Wolfgang Bauer ha scritto:
Well, the application itself has been but it isn't released yet, and especially the background service that actually checks for updates isn't and the plasmoid neither.
To be honest I would want to steer clear of Apper. Upstream is absolutely not interested in maintaining it.
But plasma5-pk-updates is in Leap, shouldn't we install (and enable it necessary) that by default too?
That should work, probably, -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: A29D259B
On 10/21/2015 12:37 AM, Luca Beltrame wrote:
In data martedì 20 ottobre 2015 22:17:42 CEST, Wolfgang Bauer ha scritto:
Well, the application itself has been but it isn't released yet, and especially the background service that actually checks for updates isn't and the plasmoid neither. To be honest I would want to steer clear of Apper. Upstream is absolutely not interested in maintaining it.
But plasma5-pk-updates is in Leap, shouldn't we install (and enable it necessary) that by default too? That should work, probably,
I think the muon update widget would be the best choice. It seems to work smoothly in Kubuntu 15.04 (using plasma 5). -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Wednesday, 21 October 2015 02:18:22 CEST mournblade wrote:
I think the muon update widget would be the best choice. It seems to work smoothly in Kubuntu 15.04 (using plasma 5).
Unfortunately this has one issue. Muon doesn't support zypper as a backend, so it doesn't integrate with the openSUSE packagemanager. Until this is fixed, Muon is not an alternative for openSUSE. Regards Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Mittwoch, 21. Oktober 2015, 19:11:44 schrieb Raymond Wooninck:
On Wednesday, 21 October 2015 02:18:22 CEST mournblade wrote:
I think the muon update widget would be the best choice. It seems to work smoothly in Kubuntu 15.04 (using plasma 5).
Unfortunately this has one issue. Muon doesn't support zypper as a backend, so it doesn't integrate with the openSUSE packagemanager. Until this is fixed, Muon is not an alternative for openSUSE.
It does have a PackageKit backend, and as mentioned the current version does seem to work on openSUSE. But I saw now that it doesn't even build on Leap... It build-requires appstream-qt5 which also fails to build on Leap. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Mittwoch, 21. Oktober 2015, 02:18:22 schrieb mournblade:
I think the muon update widget would be the best choice. It seems to work smoothly in Kubuntu 15.04 (using plasma 5).
Yeah, but it doesn't use PackageKit in KUbuntu (it has a specific apt backend). ;-) Months ago it didn't work at all in openSUSE. The current version (5.3.95) in KDE:Frameworks did work in my limited tests, but again the problem is that the package is not in Leap yet (nor in Tumbleweed), and it probably should be updated to the latest version too (5.4.2). Advantage: this is officially part of Plasma5 meanwhile, and released together with Plasma5. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On 21.10.2015 07:37, Luca Beltrame wrote:
In data martedì 20 ottobre 2015 22:17:42 CEST, Wolfgang Bauer ha scritto:
Well, the application itself has been but it isn't released yet, and especially the background service that actually checks for updates isn't and the plasmoid neither.
To be honest I would want to steer clear of Apper. Upstream is absolutely not interested in maintaining it.
But plasma5-pk-updates is in Leap, shouldn't we install (and enable it necessary) that by default too?
That should work, probably,
Tested on my test machine and it works properly - it's a bit strange that it always shows the same icon, but the notifications are correct I consider this a highly critical issue, so please adapt patterns and plasma branding ;( On the topic of branding: it would be cool if someone fixed the kde splash not to scale the background - I bet it has some options, but I don't understand the config. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Wednesday, 21 October 2015 07:37:08 CEST Luca Beltrame wrote:
In data martedì 20 ottobre 2015 22:17:42 CEST, Wolfgang Bauer ha scritto:
Well, the application itself has been but it isn't released yet, and especially the background service that actually checks for updates isn't and the plasmoid neither.
To be honest I would want to steer clear of Apper. Upstream is absolutely not interested in maintaining it.
Apper should be dropped in favor of plasma5-pk-updates. plasma5-pk-updates is maintained by the same people as the plasma networkmanager applet, so I believe this is the best way forward. I have been using it for quite some time and so far it hasn't shown any of the issues that we had with Apper. Which proves actually that Apper was the weak link with PackageKit, but at that time there was no alternative. Let's remove apper and replace it with plasma5-pk-updates as soon as possible. Regards Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Wed, 21 Oct 2015 19:09, Raymond Wooninck <tittiatcoke@...> wrote:
On Wednesday, 21 October 2015 07:37:08 CEST Luca Beltrame wrote:
In data martedì 20 ottobre 2015 22:17:42 CEST, Wolfgang Bauer ha scritto:
Well, the application itself has been but it isn't released yet, and especially the background service that actually checks for updates isn't and the plasmoid neither.
To be honest I would want to steer clear of Apper. Upstream is absolutely not interested in maintaining it.
Apper should be dropped in favor of plasma5-pk-updates. plasma5-pk-updates is maintained by the same people as the plasma networkmanager applet, so I believe this is the best way forward.
I have been using it for quite some time and so far it hasn't shown any of the issues that we had with Apper. Which proves actually that Apper was the weak link with PackageKit, but at that time there was no alternative.
Let's remove apper and replace it with plasma5-pk-updates as soon as possible.
+1 for dropping apper and apper related stuff from the patterns asap. (dropping it from Leap completly is an other matter, not that pressing, if not installed by any pattern.) Can plasma5-pk-updates get a "Obsoletes: apper" in the spec-file? Muon is missing a libzypp backend for full integration, but, as Muon has an active development, could be an option for the near future. Thanks for getting rid of apper, - Yamaban.
On Wednesday, 21 October 2015 19:38:19 CEST Yamaban wrote:
+1 for dropping apper and apper related stuff from the patterns asap.
An request has already been submitted for this one.
(dropping it from Leap completly is an other matter, not that pressing, if not installed by any pattern.)
As soon as the changes have been accepted, then we will hand over the apper package to the lxqt team. They use it also as an update applet and I am not sure if the new plasma5-pk-updates can be used on lxqt.
Can plasma5-pk-updates get a "Obsoletes: apper" in the spec-file?
Yes, this will be done in the next few minutes and then be submitted to Tumblweed and beyond.
Muon is missing a libzypp backend for full integration, but, as Muon has an active development, could be an option for the near future.
I know that in the past the suggestion was given to the authors to also implement support for Zypper. They choose to start the implementation of PackageKit, but I have only tried it in the early beginnings where most of the times the PackageKit backend didn't even build. I believe that the plasma5-pk-updates is the right plasmoid that people would like to have. It is small, out of the way and gives you a notification where there are updates available. And then you could install them from there. Indeed the same as Apper, but this time it really works :) Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Mittwoch, 21. Oktober 2015, 19:57:44 schrieb Raymond Wooninck:
Can plasma5-pk-updates get a "Obsoletes: apper" in the spec-file?
Yes, this will be done in the next few minutes and then be submitted to Tumblweed and beyond.
Well, the submitted package won't really obsolete apper. It has "Obsoletes: apper < %{version}", and the package version is 0.2, so it obsoletes apper-0.2. But the current apper version is 0.9.2... OTOH, I actually find this a bit too much anyway. Especially if lxqt are going to use it... That Provides/Obsoletes would make it uninstallable even if you don't have Plasma5 installed, no? I don't really see a need to actively remove it, it won't do anything by itself in Plasma5 anyway. Neither the background service nor the applet will even be found by Plasma5/KF5. There would just be the entry in the application menu, and the possibility to use it to open (i.e. install) .rpm files (in dolphin e.g.).
I believe that the plasma5-pk-updates is the right plasmoid that people would like to have. It is small, out of the way and gives you a notification where there are updates available. And then you could install them from there. Indeed the same as Apper, but this time it really works :)
I have no problem with apper on 13.2. It works fine here. So I can't really agree with your statements that apper was the weak link and so on. What issues exactly were you talking about? But well, doesn't matter for Leap anyway. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data mercoledì 21 ottobre 2015 21:14:52 CEST, Wolfgang Bauer ha scritto:
I have no problem with apper on 13.2. It works fine here.
Upstream has de facto abandoned it. I wouldn't want to rely too much on abaondoned software. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: A29D259B
Am Mittwoch, 21. Oktober 2015, 21:48:23 schrieb Luca Beltrame:
In data mercoledì 21 ottobre 2015 21:14:52 CEST, Wolfgang Bauer ha scritto:
I have no problem with apper on 13.2. It works fine here.
Upstream has de facto abandoned it. I wouldn't want to rely too much on abaondoned software.
How is this related? It is stable, released software (the KDE4 version at least). And it is just a frontend to PackageKit. So actually I rely on PackageKit for doing the work. Btw, following your statement one should not use e.g. KDEPIM (the KDE4 version) either, as it is de facto abandoned (but this is what will be shipped with Leap...). And nobody should use the KDE4 desktop on 13.2 any more, as it is also abandoned upstream. And there are plenty of other examples I suppose. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data mercoledì 21 ottobre 2015 22:31:17 CEST, Wolfgang Bauer ha scritto:
Btw, following your statement one should not use e.g. KDEPIM (the KDE4
KF5 PIM has been labeled as a technology preview by PIM people themselves, which are stilll working on improving the software (and although rarely, the KDE/4.14 branch still gets a few fixes). OTOH, Apper has a number of open bugs, IIRC, and no one will ever fix them. To be down to earth, I don't even *expect* upstream to fix them. Also, the new applet is much better integrated than Apper. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: A29D259B
Onsdag den 21. oktober 2015 19:57:44 skrev Raymond Wooninck:
I believe that the plasma5-pk-updates is the right plasmoid that people would like to have. It is small, out of the way and gives you a notification where there are updates available. And then you could install them from there. Indeed the same as Apper, but this time it really works :)
Indeed. The fact that it doesn't pull in an entire package manager, causing people to be confused about which package manager is the canonical one (of course YaST is), is great in itself. It needs further testing to see if it can manage to accept license agreements, avoid blocking the rpm database 90% of the time and refusing to let go without the use of a hammer etc. But like coolo said, it's untranslated. I was looking to translate it on KDE infrastructure, but I couldn't find it. I wonder if developers simply forgot to set up localization. Or if it's not officially released yet or some other explanation? -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data giovedì 22 ottobre 2015 18:10:37 CEST, Martin Schlander ha scritto:
forgot to set up localization. Or if it's not officially released yet or some other explanation?
It's hosted on GitHub rather than on KDE AFAICS. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: A29D259B
On 22.10.2015 18:15, Luca Beltrame wrote:
In data giovedì 22 ottobre 2015 18:10:37 CEST, Martin Schlander ha scritto:
forgot to set up localization. Or if it's not officially released yet or some other explanation?
It's hosted on GitHub rather than on KDE AFAICS.
What are our options to get this fixed? From a first look of it, it looks like a lot of strings are actually taken from apper, so possibly we can reuse a lot of those translations. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data venerdì 23 ottobre 2015 10:32:11 CEST, Stephan Kulow ha scritto:
What are our options to get this fixed? From a first look of it, it looks like a lot of strings are actually taken from apper, so possibly
From a quick look at the code, translations are already enabled (translation domain is "pkupdates"), we just need to provide suitable files. I wonder if somehow ripping translations from apper would work... However I'm not too familiar with i18n code. I can ask upstream KDE for advice, though. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: A29D259B
On 23.10.2015 10:51, Luca Beltrame wrote:
In data venerdì 23 ottobre 2015 10:32:11 CEST, Stephan Kulow ha scritto:
What are our options to get this fixed? From a first look of it, it looks like a lot of strings are actually taken from apper, so possibly
From a quick look at the code, translations are already enabled (translation domain is "pkupdates"), we just need to provide suitable files. I wonder if somehow ripping translations from apper would work...
However I'm not too familiar with i18n code. I can ask upstream KDE for advice, though.
Ouch. Your comment made me browse https://www.openhub.net/p/kf5/commits?page=11&sort=oldest and I had to realize that 18 years have passed ;-) But I also found documentation: https://techbase.kde.org/Development/Tutorials/Localization/i18n_Build_Syste... Greetings, Stephan -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-10-23 10:51, Luca Beltrame wrote:
In data venerdì 23 ottobre 2015 10:32:11 CEST, Stephan Kulow ha scritto:
What are our options to get this fixed? From a first look of it, it looks like a lot of strings are actually taken from apper, so possibly
From a quick look at the code, translations are already enabled (translation domain is "pkupdates"), we just need to provide suitable files. I wonder if somehow ripping translations from apper would work...
However I'm not too familiar with i18n code. I can ask upstream KDE for advice, though.
I am, perhaps, being one of the openSUSE translators ;-) openSUSE should do nothing. As it is an upstream package, it must be translated upstream, by upstream teams. The persons may be (partially) the same, though. We have, sometimes, provided translations for upstream packages, and it is a nightmare when upstream starts providing their translations. There are clashes: a partial translation from them, even a single string, would destroy all our local work. If you see as urgent to translate that package, as an exception, please ask in the opensuse-translation mail list, and we can consider what can be done. However, the translation process is in a big turmoil, it is very difficult currently to translate anything for Leap. HTH. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlYrqXQACgkQtTMYHG2NR9X8KgCfQHHvQA24C9iSwyfaa8UiWA0+ a4wAoIWAoZjgTSvCE8CyaUMz9f58s7GS =eCEd -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 23.10.2015 um 10:51 schrieb Luca Beltrame:
In data venerdì 23 ottobre 2015 10:32:11 CEST, Stephan Kulow ha scritto:
What are our options to get this fixed? From a first look of it, it looks like a lot of strings are actually taken from apper, so possibly
From a quick look at the code, translations are already enabled (translation domain is "pkupdates"), we just need to provide suitable files. I wonder if somehow ripping translations from apper would work...
However I'm not too familiar with i18n code. I can ask upstream KDE for advice, though.
Anything coming back from that? Greetings, Stephan - -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlYzlwgACgkQwFSBhlBjoJZxIQCgt/pL34uY/f8ydy0MuNTMUWzU UkkAnjq/JitEW9ojF3RNamoNpBVvTawn =ffqc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Op vrijdag 30 oktober 2015 17:13:04 schreef Stephan Kulow:
Am 23.10.2015 um 10:51 schrieb Luca Beltrame:
In data venerdì 23 ottobre 2015 10:32:11 CEST, Stephan Kulow ha
scritto:
What are our options to get this fixed? From a first look of it, it looks like a lot of strings are actually taken from apper, so possibly
From a quick look at the code, translations are already enabled (translation domain is "pkupdates"), we just need to provide suitable files. I wonder if somehow ripping translations from apper would work...
However I'm not too familiar with i18n code. I can ask upstream KDE for advice, though.
Anything coming back from that?
Greetings, Stephan
Any untranslated strings in a package with the proper use of Translation Memory of lokalize, that in fact come from another package, will be translated when using the the combination Ctrl+Alt+B. So after that most of the work is done. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On 21.10.2015 19:09, Raymond Wooninck wrote:
On Wednesday, 21 October 2015 07:37:08 CEST Luca Beltrame wrote:
In data martedì 20 ottobre 2015 22:17:42 CEST, Wolfgang Bauer ha scritto:
Well, the application itself has been but it isn't released yet, and especially the background service that actually checks for updates isn't and the plasmoid neither.
To be honest I would want to steer clear of Apper. Upstream is absolutely not interested in maintaining it.
Apper should be dropped in favor of plasma5-pk-updates. plasma5-pk-updates is maintained by the same people as the plasma networkmanager applet, so I believe this is the best way forward.
I have been using it for quite some time and so far it hasn't shown any of the issues that we had with Apper. Which proves actually that Apper was the weak link with PackageKit, but at that time there was no alternative.
Let's remove apper and replace it with plasma5-pk-updates as soon as possible.
I have 2 issues with it (still prefering it over apper): - it only debug logs if the update requires a relogin or a reboot, that's quite crucial - but easy to fix - it has 0 translations (which makes the previous issue easier to fix though :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Mittwoch, 21. Oktober 2015, 07:37:08 schrieb Luca Beltrame:
In data martedì 20 ottobre 2015 22:17:42 CEST, Wolfgang Bauer ha scritto:
Well, the application itself has been but it isn't released yet, and especially the background service that actually checks for updates isn't and the plasmoid neither.
To be honest I would want to steer clear of Apper. Upstream is absolutely not interested in maintaining it.
I mainly mentioned it for completeness. And because it was used upto 13.2, so it probably would be the first one that would spring to mind... It's no option anyway, as the KDE4 version basically doesn't work in Plasma5 (as update notifier, that is, the application itself should work fine) and a KF5 version hasn't been released yet and is not even finished.
But plasma5-pk-updates is in Leap, shouldn't we install (and enable it necessary) that by default too?
That should work, probably,
It does IME. Btw, it has "X-KDE-PluginInfo-EnabledByDefault=true" in its .desktop file, so should be added to the system tray automatically if it gets installed. So it would only have to be added to the installation patterns. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
participants (10)
-
Carlos E. R. -
Freek de Kruijf -
Luca Beltrame -
Martin Schlander -
mournblade -
Raymond Wooninck -
Stephan Kulow -
Wolfgang Bauer -
Yamaban -
šumski