Re: KMail2 24.08

[Luigi Toscano]

Sedat Dilek ha scritto:
> Hi,
> 
> so Debian QT/KDE team is working on PIM + Akonadi + KMail version
> 24.08 from KDE/apps (Gears).
> 
> I do NOT know much about the internals/correlations of all involved
> parties, but I am very interessted in KMail2.
> 
> According to [1] Kmail2 has version 6.2.1 (2024-09-12).
> So, what version is included in 24.08?

6.2.x is the internal version of the KDEPIM bits which are part of Gear 24.08.x.

https://invent.kde.org/pim/kmail/-/blob/release/24.08/CMakeLists.txt?ref_type=heads#L41-L78

Ciao
-- 
Luigi

Re: Black folder icons in Dolphin

[Luigi Toscano]

Rik Mills ha scritto:
> The reason is that the kf6-breeze-icon-theme which replaced the kf5 version
> has some changes which are not supported by the Qt5/KF5 kiconthemes library.
> You are also likely to see black folder icons in the file picker of any
> Qt5/KF5 app when you enlarge the icon view enough to see coloured folders.
> 
> Some solutions might be:
> - downgrade to the KF5 breeze icon theme package and put that on hold with apt
> until Qt6/KF6 apps are ready.
> - as some have done, copy locally the old icon theme so that takes precedence.
> - persuade devs to revert the offending upstream change in the debian
> packaging, again until no longer required.
> 

Was this reported upstream? The icons are still supposed to work with KF5, so
this should probably be fixed upstream.
Even a comment in the offending commit
https://invent.kde.org/frameworks/breeze-icons/-/commit/931fc4520ceb9ef44f367979d233f2b5bdd4bbb7
may help.

Ciao
-- 
Luigi

Re: Situation KDE Apps 24.0x

[Luigi Toscano]

Martin Steigerwald ha scritto:
> Sedat Dilek - 16.08.24, 16:00:22 CEST:
>> kate has some minor DE/German translation issues in File (Datei) menu:
>>
>> Save as with Encoding...
>> Save Copy as...
> 
> There are other missing translations. Not many but a few here and there. 
> So for example the lock screen is in English as well.
> 
> I think at least some of the Plasma/KDE Gear packages share a common 
> translation package. Maybe that is not yet updated?

No, translations are bundled with each tarball. There hasn't been "global"
translations packages for Gear, Plasma or Frameworks for the lifecyle of 5.x.

Sadly the German translation team of the KDE community has lost some
translators lately and it is struggling to rebuild. That may be the reason.

-- 
Luigi

Re: KDE/Frameworks/Plasma/Apps + QT from experimental

[Luigi Toscano]

Alex Hermann ha scritto:
> On maandag 22 juli 2024 10:49:48 CEST Sedat Dilek wrote:
>> Then I was able to enjoy the new KDE plasma-desktop version 6.1.
> 
>> The upgrade was mostly done manually - some QT packages were required
>> from unstable.
> 
> I tried it too. Unfortunately, I found that the file dialogs in kate, 
> okular, etc all use QFileDialog, which doesn't support remote locations 
> via kio. I think those should be using KFileDialog instead.
> 
> Error message is:
> kate[41569]: Non-native QFileDialog supports only local files
> 
> Is this broken for everyone or am I missing some package?
> 

KFileDialog doesn't exist since Frameworks 5. Maybe you are missing a package?

The special feature are provided (if I remember correctly) by some integration
layer that uses the "hooks" provided by Qt to extend the behavior. If you use
Plasma, that's done by plasma-integration.

Ciao
-- 
Luigi

Re: Versions mismatch and upload methodology for KDE applications

[Luigi Toscano]

Shmerl ha scritto:
> I noticed that versions of KDE applications in Debian repos are
> all over the place. Examples:
> 
> kmail: 22.08.2
> konsole: 22.08.1
> okular: 22.04.3
> and etc.
> 
> So method of uploading them seems random or ad hoc.
> 
> Why aren't KDE maintainers uploading the whole suite of
> applications at once for all of them to have the same version?

I can't speak for the maintainers, but please consider that those programs are
part of KDE Gear, which is just a collection of software which is released
together, but it doesn't automatically imply a dependency between the various
applications. There may be some (for example, all bits which mades KDE PIM)
but that's not the general rule, so they can be updated separately.

-- 
Luigi

Re: Plasma 5.24 coming to unstable

[Luigi Toscano]

Miguel A. Vallejo ha scritto:
> The question is:
> 
> Why is APT not smart enough to see that the proposed upgrade will fail?
> 


No, it can't infer what humans think, unless the packages contain the
information that their versions are strictly linked together.

-- 
Luigi

Re: The future of KDE in Debian?

[Luigi Toscano]

(pushed the wrong reply button, replying to the list too)

Marco Valli ha scritto:
>> Marco, second time today. Please stop, or change your sources 
>> (hints: not the
>> site you just linked).
> 
> You're getting sickly. I sent the link to a news that appeared on a 
> reputable, 
> if not authoritative, site. I have not offended anyone. I have not made 
> references to anyone. Why do you bust my balls?
> Prejudice?
> 
Compare two scenarios:

--Scenario 1--




May be this prejudice? I don't know, there are relevant precedents and I think
there is space for improvement by tuning the messaging.

-- 
Luigi

Re: The future of KDE in Debian?

[Luigi Toscano]

Marco Valli ha scritto:
> O-h m-y g-o-d...
> 
> https://www.phoronix.com/scan.php?page=news_item&px=Qt-Digital-Advertising-1.0
> 

Marco, second time today. Please stop, or change your sources (hints: not the
site you just linked).



https://mastodon.technology/@kde/107678817876676116
https://twitter.com/kdecommunity/status/1485678307983216645

-- 
Luigi

Re: Future of KDE packages in Debian

[Luigi Toscano]

Marco Valli ha scritto:

Marco, please stop.

This is beyond the point of whether your starting point may have had some
merit if expressed differently or not.

-- 
Luigi

Re: 5.23 starting move to testing

[Luigi Toscano]

Erwan David ha scritto:
> Le 19/10/2021 à 21:52, Shai Berger a écrit :
>> On Tue, 19 Oct 2021 16:37:14 +0200 (CEST)
>> Borden  wrote:
>>
>>> 17 Oct 2021, 07:16 by b...@fineby.me.uk:
 Taking note of the thread regarding updating to 5.23 in Sid, I'll be
 holding off for a few days until migration to testing is complete.
  
>>> I'm sure this has been answered before, but this seems to be a
>>> perennial issue wherever there's a major upgrade. Since Testing is
>>> supposed to be free of known system-breaking errors, why can't the
>>> packages be held back until the it's all ready?
>>>
>> This not only has been answered before in general -- it has been
>> effectively discussed on this very list, only last week.
>>
>> As a user, you can use "apt upgrade" or "aptitude safe-upgrade". With
>> either of these, you will not get half-system updates. If the whole
>> upgrade is ready, you'll get it; if it isn't, you will get suggestions
>> to either keep older versions of packages with updates, or drop the
>> not-yet-updated packages. Then, you should choose what to do according
>> to your taste and the selection of not-yet-updated packages.
>>
>> Asking for any non-stable flavor to act like stable is making the
>> packagers' work harder, and IMO as a grateful user who is not involved
>> in packaging, that is completely uncalled for.
>>
>> Hope this helps,
>>  Shai.
>>
>>
> With apt upgrade on testing, you often get partial non working upgrade.
> I was recently told to "only do complete upgarde", but when I asked how
> to know the upgrade is compelte, I got no answer.
> 
> Tonight apt list --upgradable lists me

Exactly: safe-upgrade is not safe when you need a bunch of packages to
migrated at the same time. You would get a mix which is going to be worse. In
many cases the complete upgrade is better. This is about Shai's point.

That said, Erwin, I don't have an answer to your question. Probably stricter
constraints in the packages may help, but not completely and it  may be
complicated to implement.

-- 
Luigi

Re: Broken KDE in Sid/Unstable

[Luigi Toscano]

Miguel A. Vallejo ha scritto:
>> I somehow disagree. Since I started packaging KDE/plasma with 5.18 or
>> so, I have been tracking every single minor and major release within a
>> few days, and I never have seen any considerable change in
>> layout/design.
>>
>> So I am really surprised about your experience.
> 
> I am really surprised your experience is not the same if we are
> running the same KDE.
> 
> One or two months ago the main menu changed drastically. Now the
> taskbar is a only icons version, another drastic change. What is the
> secret to keep KDE the same across updates? I would love to hear from
> you.

The main manu (Application Launcher) changed in Plasma 5.21 (and in a few
weeks Plasma 5.23 will be released), we haven't seen it before due to the
Debian freeze:
https://kde.org/announcements/plasma/5/5.21.0/

The classic menu (Application Menu) hasn't changed.

I have the text for all applications in my taskbar, maybe just the default
changed but you can probably tune it.

-- 
Luigi

Re: Testing : do not upgrade to 5.21 (yet)

[Luigi Toscano]

Erwan David ha scritto:
> Le 23/08/2021 à 11:25, Luigi Toscano a écrit :
> u have a mix of Frameworks packages from 5.78 and 5.83:
>>
>> ii  libkf5plasma5 5.78.0-3
>> ii  libkf5plasmaquick5    5.78.0-3
>> ii  libkf5prison5 5.83.0-2
>>
>> Make sure you fully get all Frameworks 5.83 (which should be upgraded as a
>> single block).
>>
> 
> And what would be the best way to be sure ?
> Given I have some libkf5* packages with another numbering scheme :
> eg libkf5cddb5 : 4:20.12.0-1

Those are not the Frameworks product, they are shipped with a different cycle.


> There are alos many packages in the framework, what would be the best tool to
> be sure we upgrade the framework as a whole ?

I don't have an answer - I usually check whether all the packages are
available using also the version numbers.

-- 
Luigi

Re: Testing : do not upgrade to 5.21 (yet)

[Luigi Toscano]

Erwan David ha scritto:
> 
>  Message d'origine ----
> De : Luigi Toscano [mailto:luigi.tosc...@tiscali.it]
> Envoyé : lundi 23 août 2021 à 10:50 UTC+2
> Pour : Erwan David , Debian Kde 
> 
> Objet : Testing : do not upgrade to 5.21 (yet)
> 
>> Erwan David ha scritto:
>>> After upgrade to 5.21 this morning (plasma-workspace 4:5.21.5-3), I get
>>>
>>> kf.plasma.core:
>>> "/usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/applets/org.kde.plasma.systemtray.so"
>>>
>>> : this plugin is compiled against incompatible Plasma version 348928 This
>>> build is compatible with 5 .0.0 ( 327680 ) to 5.78.0 ( 347708 )
>>> kf.plasma.core: Applet "org.kde.plasma.systemtray" could not be loaded.
>>>
>>> So better wait for a newer version...
>>>
>>
>> plasma-workspace alone is not Plasma. You need all the packages which makes 
>> up
>> Plasma, those are the upstream sources
>> https://download.kde.org/stable/plasma/5.21.5/
>>
>> Please also consider that Frameworks is only partially migrated to testing,
>> which means other stuff may not work for different reasons than not having 
>> all
>> Plasma bits.
>>
> 
> I know; There were more than 400 packages, however error message is
> kf.plasma.core:
> "/usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/applets/org.kde.plasma.systemtray.so"
> : this plugin is compiled against incompatible Plasma version 348928 This
> build is compatible with 5 .0.0 ( 327680 ) to 5.78.0 ( 347708 )
> 
> and according to apt-file  org.kde.plasma.systemtray.so comes in
> plasma-workspace package.
> 
> See bug #992760
> 

You have a mix of Frameworks packages from 5.78 and 5.83:

ii  libkf5plasma5 5.78.0-3
ii  libkf5plasmaquick55.78.0-3
ii  libkf5prison5 5.83.0-2

Make sure you fully get all Frameworks 5.83 (which should be upgraded as a
single block).


-- 
Luigi

Re: Testing : do not upgrade to 5.21 (yet)

[Luigi Toscano]

Erwan David ha scritto:
> After upgrade to 5.21 this morning (plasma-workspace 4:5.21.5-3), I get
> 
> kf.plasma.core:
> "/usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/applets/org.kde.plasma.systemtray.so"
> : this plugin is compiled against incompatible Plasma version 348928 This
> build is compatible with 5 .0.0 ( 327680 ) to 5.78.0 ( 347708 )
> kf.plasma.core: Applet "org.kde.plasma.systemtray" could not be loaded.
> 
> So better wait for a newer version...
> 

plasma-workspace alone is not Plasma. You need all the packages which makes up
Plasma, those are the upstream sources
https://download.kde.org/stable/plasma/5.21.5/

Please also consider that Frameworks is only partially migrated to testing,
which means other stuff may not work for different reasons than not having all
Plasma bits.

-- 
Luigi

Re: Current status of KDE in Sid

[Luigi Toscano]

Miguel A. Vallejo ha scritto:
> This is really weird. Continuing with the example of dolphin:
> 
> 
> 
> apt install -V dolphin
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> dolphin is already the newest version (4:20.08.2-1).
> 0 upgraded, 0 newly installed, 0 to remove and 182 not upgraded.
> 
> 
> But and apt full-upgrade want to uninstall a lot of packages,
> including dolphin, so I don't understand anything:

What about listing the packages you want to keep after apt full-upgrade, one
by one, and see what happens?

apt full-upgrade dolphin ...


-- 
Luigi

Re: dolphin 20.08.2 crashes upon right-click

[Luigi Toscano]

Marco Möller ha scritto:
> On 31.10.20 14:24, Aurélien COUDERC wrote:
>> If you could file a bug in the Debian BTS to track the issue that would be
>> appreciated.
> 
> Done. It is here:
> https://bugs.kde.org/show_bug.cgi?id=428529
> 

Please note that bugs.kde.org is the KDE bugtracker, but this is a packaging
issue. I suspect that bug will be closed, because from the point of view of
kde.org. Aurélien was talking about bugs.debian.org.


-- 
Luigi

Re: Understanding apt-autoremovable KDE packages

[Luigi Toscano]

Sedat Dilek ha scritto:
> On Sat, Jun 20, 2020 at 1:05 PM Sedat Dilek  wrote:
>>
>> [ Please CC me I am not subscribed to this ML ]
> 
 libreoffice-kde5 is a metapackage that can be safely removed.
> 
>> Removing libreoffice-kde5 now shows...
>>
>>libreoffice-kf5 (1:6.4.5~rc1-1)
>>libreoffice-qt5 (1:6.4.5~rc1-1)
>>
>> ...as removable candidates.
>>
> 
> What helped:
> 
> dpkg --purge libreoffice-kde5 libreoffice-kf5 libreoffice-qt5
> 
> apt-get install --reinstall -t unstable libreoffice-kf5 libreoffice-qt5
> 
> Now, everything in sense of KDE auto-removables seems to be OK here.

A bit late to the party, but iirc you didn't need to remove them, nor
reinstall them, but simply explicitly install them:

apt-get install 

(yes, also when they are already installed).


-- 
Luigi

Re: digiKam 6.4.0

[Luigi Toscano]

Rik Mills ha scritto:
> On 17/02/2020 10:30, Michal BULIK wrote:
>>
>> 6.4.0 has entered testing. What about kipi-plugins ? Has it disappeared ?
>> Or has it been replaced by something else ?
>>
>> Thank you,
>> Michal
> 
> They were split to a new source by KDE, and made part of KDE
> applications/release-service.
> 
> The new source upload is in the ftp master's NEW queue:
> 
> https://ftp-master.debian.org/new.html

Also, please note that they have been kept around after digikam totally
dropped them just for compatibility purpose, but they are basically replaced
by the Purpose framework also in the other projects. See also:

https://mail.kde.org/pipermail/release-team/2019-April/011316.html
https://phabricator.kde.org/T10525

-- 
Luigi

Re: phonon-backend-gstreamer-common has been kept back

[Luigi Toscano]

Miguel A. Vallejo ha scritto:
>> Try to install phonon-backend-vlc, and then upgrade.
> 
> It's already installed
> 

What if you manually do:

apt-get install phonon-backend-gstreamer-common phonon phonon-backend-vlc
?


In any case it's just removing a few Qt4 applications and libraries, which you
don't need anyway (apart maybe from kopete).

Ciao
-- 
Luigi

Re: phonon-backend-gstreamer-common has been kept back

[Luigi Toscano]

Miguel A. Vallejo ha scritto:
> Hi
> 
>> I don't have that problem on my Sid box.
>> Can you share the output/result of
>> "aptitude safe-upgrade phonon-backend-gstreamer-common" ?
> 
> Here it is:
> 
> ~# aptitude safe-upgrade phonon-backend-gstreamer-common
> Resolving dependencies...
> The following packages have been kept back:
>  phonon-backend-gstreamer-common{a}
> No packages will be installed, upgraded, or removed.
> 0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
> Need to get 0 B of archives. After unpacking 0 B will be used.
> 
>> and if it's any different also from "full-upgrade"?
> 
> Yes, quite different:
> 
> ~# aptitude full-upgrade phonon-backend-gstreamer-common
> The following packages will be REMOVED:
>  phonon-backend-gstreamer-common{u}
> 0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
> Need to get 0 B of archives. After unpacking 38.9 kB will be freed.
> The following packages have unmet dependencies:
> phonon-backend-gstreamer : Depends: phonon-backend-gstreamer-common (=
> 4:4.9.1-1) but it is not going to be installed
> The following actions will resolve these dependencies:
> 
> Remove the following packages:
> 1) jovie [4:16.08.0-1+b1 (now)]
> 2) kde-runtime [4:17.08.3-2.1 (now)]
> 3) kopete [4:17.08.3-2.1 (now)]
> 4) phonon [4:4.10.3-2 (now)]
> 5) phonon-backend-gstreamer [4:4.9.1-1 (now)]
> 
> Leave the following dependencies unresolved:
> 6) kdelibs5-plugins recommends kde-runtime
> 7) libkopete4 recommends kopete (= 4:17.08.3-2.1)
> 

It simply removes the remaining Qt 4 applications.

Try to install phonon-backend-vlc, and then upgrade.

-- 
Luigi

Re: KDE PIM 19.08.2 in experimental

[Luigi Toscano]

Sandro Knauß ha scritto:
> Hey,
> 
> I started to upload KDE PIM 19.08.2 to experimental. It should be functional, 
> if it is compiled. As I switched the way how KDEPIM is handled (I now use 
> virtual packages instead of symbolsfiles), it can't detect if "external 
> applications" are  broken. This is fixed, if I get green light for
> #942415:
> https://release.debian.org/transitions/html/kdepim.html

At least kgpg has weird dependencies:

libkf5akonadicontact5 (>= 4:18.08.3), libkf5akonadicontact5-18.08,
libkf5akonadicore5-18.08, libkf5akonadicore5abi2 (>= 4:18.08.3), [...]
libkf5contacts5 (>= 4:18.08.3), libkf5contacts5-18.08,

which prevents its installation.

-- 
Luigi

Re: baloo, son of nepomuk

[Luigi Toscano]

Dietz Proepper ha scritto:
> Am Freitag, 30. August 2019, 23:08:19 CEST schrieb Luigi Toscano:
>> bw ha scritto:
>>> Just did an upgrade from stretch, baloo is now doing the same thing
>>> nepomuk did back in the day.  On logout, baloo_file process remains, so
>>> restarting the xserver causes duplicates, thus hanging up the
>>> baloo_file_extractor, and eating memory and cpu until crash...
>>
>>> quick and dirty workaround:
>> I can either disable it from systemsettings with a click, or at least ensure
>> that it only indexes the file names and not the contents.
> 
> How do you do the latter?

>From the same systemsettings panel (Workspace->Search). There are only two
options:
- "Enable File Search"
- "Also index file content"

-- 
Luigi

Re: baloo, son of nepomuk

[Luigi Toscano]

bw ha scritto:
> Just did an upgrade from stretch, baloo is now doing the same thing 
> nepomuk did back in the day.  On logout, baloo_file process remains, so 
> restarting the xserver causes duplicates, thus hanging up the 
> baloo_file_extractor, and eating memory and cpu until crash...
> 
> quick and dirty workaround:

I can either disable it from systemsettings with a click, or at least ensure
that it only indexes the file names and not the contents.

-- 
Luigi

Re: kompare doesn't

[Luigi Toscano]

Gary Dale ha scritto:
Has anyone tried kompare recently? I haven't used it before but needed it to 
track down why google maps won't load the new version of a kml file but still 
loads the old one (both pass the w3schools xml validation test).


I can point it to the two files I want to compare but the compare button 
remains grey even after I tell it where to find the diff program.





Known issue, there is a workaround:
https://bugs.kde.org/show_bug.cgi?id=390024

Ciao
--
Luigi

Re: Buster: Has anyone been able to run an app as root in KDE?

[Luigi Toscano]

local10 ha scritto:

Oct 11, 2018, 4:08 PM by mar...@lichtvoll.de:


lI simply have not tried and I see no reason to try it.



I don't do it often myself but occasionally it is useful, for example if I need 
to quickly browse through or compare a lot of files with root permissions or I 
need to make a lot of changes in a file with root perms  and I want use a 
decent editor like Kate while doing it.



It looks like you are referring to two specific programs, Dolphin and Kate.

Dolphin can be run (again) as root (with su, not sudo) since 18.08.0 
(currently in testing) with big warning, waiting for the feature which will 
allow users to browse all files even without running the whole program as root.


Kate can't run directly as root, but there is a way to edit files a root:
https://phabricator.kde.org/D4634
https://blog.martin-graesslin.com/blog/2017/02/editing-files-as-root/

--
Luigi

Re: KDEPIM broken after upgrades in Buster [Was: Re: KDEPIM 18.08 broken icons in Kontact application switcher toolbar]

[Luigi Toscano]

/dev/fra ha scritto:

On 08/10/18 15:26:25 CEST, Brad Rogers wrote:

On Sun, 07 Oct 2018 12:18:32 +0200
Martin Steigerwald  wrote:

Anyone else seeing this? I like to rule out an installation issue
before I report a bug.


Is this in testing?

Today, a few packages were upgraded to 18.08 from 17.2 in testing.  It
broke several things, including korganiser & kaddressbook.  A quick look
at packages.debian informs me that the 17.2 to 18.08 transition is far
from complete, and thus likely to break things in testing for a while.


Sorry to hijack the thread, but indeed the upgrades of today broke the entire
KDEPIM I suppose, as not even Kmail was working afterwards.

These the relevant packages that have been installed and upgraded:

- installed
   libkf5imap-data:amd64 (18.08.1-1, automatic)

- upgraded
   libkf5kontactinterface5:amd64 (17.12.3-1, 18.08.1-1)
   libkf5mime-data:amd64 (17.12.3-2, 18.08.1-1)
   libkf5grantleetheme5:amd64 (17.12.3-1, 18.08.1-1)
   libkf5grantleetheme-plugins:amd64 (17.12.3-1, 18.08.1-1)
   libkf5imap5:amd64 (17.12.3-2, 18.08.1-1)
   libkf5mime5abi1:amd64 (17.12.3-2, 18.08.1-1)
   libkf5kontactinterface-data:amd64 (17.12.3-1, 18.08.1-1)
   libkf5mbox5:amd64 (17.12.3-1, 18.08.1-1)

Uninstalling libkf5imap-data and downgrading back the other packages solved
the problem for now.



Or just upgrade every KDEPIM package to 18.08 from sid.

--
Luigi

Re: kdeconnect doesn't

[Luigi Toscano]

Eric Valette ha scritto:

On 09/28/2018 02:33 PM, Eric Valette wrote:

On 09/28/2018 02:29 PM, Luigi Toscano wrote:


If it was the case, it would have been broken for everyone. But for example 
it works for me (and other people). So it can't simply be a matter of 
packages mangled between different architectures.


What is strange is that android world devices see each others, linux worlds 
devices see each other, android world and Linux world devices do communicate 
at IP level (I have various application beside kdeconnect that work (DLNA, 
tvheadend, juicessh,...)) but fail to recognize devices as suitable for 
kdeconnect explained in the bug report.





Can you by chance try to see if any of your Android devices sees kdeconnect 
instance running on a PC on a different network? A friend's PC, or so.


--
Luigi

Re: kdeconnect doesn't

[Luigi Toscano]

Eric Valette ha scritto:
I keep reading wonderful things about KDEconnect but I've yet to experience 
them. My android phones can't see my Debian/Buster desktop and vice versa. 
Both devices are on the same network and I'm not running an internal 
firewall on my desktop. I've been trying KDEconnect intermittently for many 
months, during which time I've had a couple different Android phones, but 
have yet to have any success. I have no indication of any other network 
issues on my home network. Both IP addresses (phone & desktop) are assigned 
via DHCP, which is probably about as normal as you can get. Manually adding 
the desktop's current IP address to the phone app doesn't help either.

Any ideas?


I already reported this bug 
, even upstream 
**>, even on the kdeconnect dev 
mailing list. Nobody answered. Its has been so for month.


Most likely it's not reproducible for the developers.


Using wireshark I see packet exchanged netween android devices and PC  but 
probably the layout of the data are broken during network conversion when 
exchanged (arm 32 bits and amd64 64 bits) .


If it was the case, it would have been broken for everyone. But for example it 
works for me (and other people). So it can't simply be a matter of packages 
mangled between different architectures.


You mention that you see packages, but do you see the specific packages for 
kdeconnect? I don't see the firewall mentioned in the bug, I guess it was 
disabled, but just to be sure... (even if probably Debian does not enable it 
by default).


--
Luigi

Re: Buster: KDE questions/issues

[Luigi Toscano]

local10 ha scritto:

Sep 7, 2018, 10:53 AM by luigi.tosc...@tiscali.it:


I suspect (given the lack also of kwin-x11) that you installed disabling the packages 
marked as "Recommends", and most of the issues are coming from this.
Check for example the Recommends section of the plasma-desktop package:

https://packages.debian.org/buster/plasma-desktop 




Installing systemsettings package resolved the issue. Kind of strange that this package is not a part of  kde-standard, I use it often. 


systemsettings is a "recommended" dependency of plasma-desktop, which is an 
hard dependency by kde-plasma-desktop, which is an hard dependency kde-standard.


I strongly suspect you disabled recommends. If it's the case, it explains the 
other issues you have. You probably miss stuff like kscreen, or upower.

Please don't disable recommends unless you really know which packages you miss.

--
Luigi

Re: Buster: KDE questions/issues

[Luigi Toscano]

local10 ha scritto:




Sep 7, 2018, 8:04 AM by luigi.tosc...@tiscali.it:


I don't really know what to say. Can you start systemsettings from a graphical 
terminal? All control modules should be available there.




It doesn't look like I have systemsettings executable installed:



I suspect (given the lack also of kwin-x11) that you installed disabling the 
packages marked as "Recommends", and most of the issues are coming from this.

Check for example the Recommends section of the plasma-desktop package:

https://packages.debian.org/buster/plasma-desktop

--
Luigi

Re: Buster: KDE questions/issues

[Luigi Toscano]

local10 ha scritto:

More questions (questions 3 and 4 from my previous email I consider resolved, 1 
and 2 not yet resolved):

5. Installed kde-standard but it appears there are no Desktop, Mouse, Look and 
Feel themes were included with kde-standard, at least I don't see any.


I don't really know what to say. Can you start systemsettings from a graphical 
terminal? All control modules should be available there.


6. Don't see any way to set a screensaver.


There are no screensavers, but screen lockers, so look for that sections.

Animated wallpapers can be used as screen lockers.


--
Luigi

Re: Buster: KDE questions/issues

[Luigi Toscano]

local10 ha scritto:

Hi,

Some questions/issues I encountered while migrating from KDE in Wheezy to KDE 
in Buster :

1. KDE > Power / Session menu does not have Suspend or Hibernate options. How 
can I get them back, if possible?


I think it does not depend on Plasma, but on the underlying library. Can you 
suspend and resume as user using systemctl?




2. KDE in Wheezy had the System Preferences app (or something like that) which 
served as a central point from which many of KDE config properties could be 
accessed. I can't find anything like that in KDE in Buster. Some individual 
apps to configure mouse/keyboard/etc could be found but no central config app.


System Settings is still part of Plasma there and it has also elements to 
configure the input devices.





3. Device notifier widget shows Floppy Disk device even though my PC does not 
have a floppy disk. Is there a way to remove it?


Uhm, probably a leftover; did you try to clean up all the orphaned packages? 
And does it happen with a fresh user?




4. I was really disappointed when I saw the new Clipboard widget which I think 
replaced the good old Klipper. I used to configure Klipper to hold 30 items, 
and in Klipper it was possible to see them all and just click on the item I 
wanted to select it. Clipboard still allows to have a variable number of items 
but it shows ONLY THREE (3) latest items placed in the clipboard and there 
appears to be no way see them all. Also Clipboard takes a lot more space on the 
Task Bar then Klipper did. Is there a way to restore back the functionality as 
it was provided by Klipper?


I have configured 7 items and I see all of them.

No, the old clipper is gone.

--
Luigi

Re: krunner and systemtray broken in testing

[Luigi Toscano]

Erwan David ha scritto:

Le 08/27/18 à 22:46, Luigi Toscano a écrit :

Erwan David ha scritto:

Le 08/27/18 à 21:51, Luigi Toscano a écrit :

yaros ha scritto:

Dnia poniedziałek, 27 sierpnia 2018 21:25:21 CEST Erwan David pisze:

Since latest upgrade, krunner does not find anything outside the
latest
documents (and cannot execute command lines), sametime system tray
cannot start anymore (and this on 2 different machines)

Do someone have a hint on what happens ?

(or is there a workaround) ?




Look at the topic "[Debian/buster] Problems after Upgrade 4:5.13.1-1
to 4:5.13.4-1"
And https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907262




Namely this email:
https://lists.debian.org/debian-kde/2018/08/msg00030.html


Thanks. So what would be the safest way to get only the needed packages
from unstable and not keep getting them from unstable in the future ?


Discussed in the same thread:

https://lists.debian.org/debian-kde/2018/08/msg00032.html


My past tries whith this kind of commands lead to always using unstable
after such an install. I do not want to run unstable if avoidable.




Then disable the unstable repository immediately after the upgrade.
There are no other solutions: you need to install those packages, and unless 
you want to download each single deb file, the sequence of adding the unstable 
repositories, upgrading those packaging, removing the unstable repositories, 
is the only way.


Moreover, even if you keep unstable with a low-priority, one the Frameworks 
5.49 packages land in testing, everything will continue from testing as before.



Ciao
--
Luigi

Re: krunner and systemtray broken in testing

[Luigi Toscano]

Erwan David ha scritto:

Le 08/27/18 à 21:51, Luigi Toscano a écrit :

yaros ha scritto:

Dnia poniedziałek, 27 sierpnia 2018 21:25:21 CEST Erwan David pisze:

Since latest upgrade, krunner does not find anything outside the latest
documents (and cannot execute command lines), sametime system tray
cannot start anymore (and this on 2 different machines)

Do someone have a hint on what happens ?

(or is there a workaround) ?




Look at the topic "[Debian/buster] Problems after Upgrade 4:5.13.1-1
to 4:5.13.4-1"
And https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907262




Namely this email:
https://lists.debian.org/debian-kde/2018/08/msg00030.html


Thanks. So what would be the safest way to get only the needed packages
from unstable and not keep getting them from unstable in the future ?


Discussed in the same thread:

https://lists.debian.org/debian-kde/2018/08/msg00032.html

--
Luigi

Re: krunner and systemtray broken in testing

[Luigi Toscano]

yaros ha scritto:

Dnia poniedziałek, 27 sierpnia 2018 21:25:21 CEST Erwan David pisze:

Since latest upgrade, krunner does not find anything outside the latest
documents (and cannot execute command lines), sametime system tray
cannot start anymore (and this on 2 different machines)

Do someone have a hint on what happens ?

(or is there a workaround) ?




Look at the topic "[Debian/buster] Problems after Upgrade 4:5.13.1-1 to 
4:5.13.4-1"
And https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907262




Namely this email:
https://lists.debian.org/debian-kde/2018/08/msg00030.html

--
Luigi

Re: [Debian/buster] Problems after Upgrade 4:5.13.1-1 to 4:5.13.4-1

[Luigi Toscano]

Sedat Dilek ha scritto:

On Mon, Aug 27, 2018 at 10:41 AM, Luigi Toscano
 wrote:

Sedat Dilek ha scritto:


Hi,

my "quick-starter" is gone - the panel with the mini-programs like
network-manager, discover (showing upgradable packages) etc.

Trying to re-add the "quick-starter" (German "Schnell-Starter") via
"add mini-programs" fails.
Adding a different mini-program like "memoory status" (German
Speicherstatus) is OK.

Is there a known issue with that?
Any workarounds you know?



As I wrote on https://bugs.kde.org/show_bug.cgi?id=397875#c6 :

The issue seems to come from the missing update of Frameworks packages in
testing.
Only few packages from Frameworks 5.49 migrated to testing, and the vast
majority of them are still version 5.47, but the newer version of Plasma was
built against Frameworks 5.49. Just update all Frameworks 5.47 packages to
the unstable version (5.49) and Plasma should work again.

The bug should solve itself when all the packages migrate. Packagers should
ensure that the migration of Frameworks happens all at the same time, and it
blocks the dependent packages.



What is your ad-wi*s*e for upgrading?
Wait for the new packages as you wrote in the above comment is your
recomendation.

Do I need to upgrade all v5.47.0 packages to v5.49.0?
is it enough to do only for plasma-framework package?


I did upgrade all 5.47 packages to 5.49. All Frameworks bits are  supposed to 
be upgraded at the same time.


I use testing but I also have unstable repositories enabled using pinning, and 
what I did is:

apt-get -t unstable install $(dpkg -l | awk '/5.47.0/ { print $2 }')

I was told (thanks diederik on IRC) that this should work too:
aptitude -t unstable safe-upgrade ~i~V5.47.0

Ciao
--
Luigi

Re: [Debian/buster] Problems after Upgrade 4:5.13.1-1 to 4:5.13.4-1

[Luigi Toscano]

Sedat Dilek ha scritto:

Hi,

my "quick-starter" is gone - the panel with the mini-programs like
network-manager, discover (showing upgradable packages) etc.

Trying to re-add the "quick-starter" (German "Schnell-Starter") via
"add mini-programs" fails.
Adding a different mini-program like "memoory status" (German
Speicherstatus) is OK.

Is there a known issue with that?
Any workarounds you know?


As I wrote on https://bugs.kde.org/show_bug.cgi?id=397875#c6 :

The issue seems to come from the missing update of Frameworks packages in 
testing.
Only few packages from Frameworks 5.49 migrated to testing, and the vast 
majority of them are still version 5.47, but the newer version of Plasma was 
built against Frameworks 5.49. Just update all Frameworks 5.47 packages to the 
unstable version (5.49) and Plasma should work again.


The bug should solve itself when all the packages migrate. Packagers should 
ensure that the migration of Frameworks happens all at the same time, and it 
blocks the dependent packages.



Ciao
--
Luigi

Re: Update removal package

[Luigi Toscano]

MERLIN Philippe ha scritto:

HI,

On Debian SID AMD64

For more than 3 days in every update we want to remove 16 kde packages like :

   kde-plasma-desktop (5:102)
   kde-standard (5:102)
   kde-window-manager (4:5.12.3-1)
   kdeplasma-addons (4:4.14.2-1)
   kinfocenter (4:5.12.5-1)
   kscreen (4:5.12.3-1)
   kwin-common (4:5.12.5-1)
   kwin-x11 (4:5.12.5-1)
   libpowerdevilcore2 (4:5.12.5-1)
   libtaskmanager6 (4:5.12.5-1)
   plasma-desktop (4:5.12.5-1)
   plasma-netbook (4:4.11.22-3)
   plasma-widgets-addons (4:5.12.5-1)
   plasma-workspace (4:5.12.5-1)
   powerdevil (4:5.12.5-1)
   sddm-theme-breeze (4:5.12.5-1)
it's normal ?

Thanks for your notices.



Yes, until the migration of Plasma is completed. That's a reason why Sid has 
its name.


Unfortunately one of the packages is in the NEW queue (kdecoration), so it may 
take few days, depending on the workload of the FTP Masters. Maybe Plasma 5.13 
should have be uploaded to experimental first, but now we just need to wait.


PS. Regardless of any update, you can remove plasma-netbook: it's an old 
package and not used anymore.


Ciao
--
Luigi

Re: Compatibility plasma-nm and .ovpn files

[Luigi Toscano]

newbee...@nativobject.net ha scritto:
> Hi,
> 
> Is somebody knows if there is some work on importing openvpn profiles directly
> with an .ovpn file ?
> 
> This fonctionnallity could be very usefull for "basic" users to avoid
> misconfiguration...

You can import .ovpn files. When you create a new connection, the last item in
the list allows you to import a file (at least on sid, but I think it was the
same in stretch).

-- 
Luigi

Re: okular "cannot find latex executable"

[Luigi Toscano]

inkbottle ha scritto:
> On Thursday, April 19, 2018 3:22:26 PM CEST Lisandro Damián Nicanor Pérez 
> Meyer wrote:
>> El miércoles, 18 de abril de 2018 16:38:37 -03 Luigi Toscano escribió:
>>> Lisandro Damián Nicanor Pérez Meyer ha scritto:
>>>> El miércoles, 18 de abril de 2018 12:31:28 -03 inkbottle escribió:
>>>>> However the resulting Okular behavior is far from satisfactory:
>>>>> The inline note shows only the latex code: in order to see the result
>>>>> of
>>>>> it, one has to first double click the inline note, and then to click on
>>>>> "render latex code"; which is far from providing an immediate and
>>>>> intuitive view of the formulas.
>>>>>
>>>>> However, again, that could be use to compensate that poppler's utf8
>>>>> related
>>>>> bug: https://bugs.freedesktop.org/show_bug.cgi?id=65956
>>>>>
>>>>> Provided one possibly modify
>>>>> https://github.com/KDE/okular/blob/2aa006fa87240a89ff8446744ccd9f86a48c
>>>>> 8d
>>>>> d0/ ui/latexrenderer.cpp through the addition of latex packages to
>>>>> render
>>>>> desired fonts;
>>>>> not sure it is so easy, but is is probably easier than fixing a 5 years
>>>>> old
>>>>> poppler's bug.
>>>>
>>>> Maybe suggesting this to upstream?
>>>
>>> It would not fix the bug anyway: you don't want to strictly depend on a
>>> (huge deployment of) latex for this.
>>
>> Indeed, this is true.
> 
> So it boils done to a functionality: not very useful, not working very well, 
> and enabling it could clutter the system.
> 
> Which lead to a very straightforward bug reporting course of action: doing 
> noting. I like it.
> 
> 


What I don't like it is when someone reads what I didn't write.
I didn't say that that adding an optional dependency on latex is a problem.
I wrote that this is not *the* solution, because most of the deployments
don't, won't and can't have latex.

-- 
Luigi

Re: okular "cannot find latex executable"

[Luigi Toscano]

Lisandro Damián Nicanor Pérez Meyer ha scritto:
> El miércoles, 18 de abril de 2018 12:31:28 -03 inkbottle escribió:

> 
>> However the resulting Okular behavior is far from satisfactory:
>> The inline note shows only the latex code: in order to see the result of it,
>> one has to first double click the inline note, and then to click on "render
>> latex code"; which is far from providing an immediate and intuitive view of
>> the formulas.
>>
>> However, again, that could be use to compensate that poppler's utf8 related
>> bug: https://bugs.freedesktop.org/show_bug.cgi?id=65956
>>
>> Provided one possibly modify
>> https://github.com/KDE/okular/blob/2aa006fa87240a89ff8446744ccd9f86a48c8dd0/
>> ui/latexrenderer.cpp through the addition of latex packages to render
>> desired fonts;
>> not sure it is so easy, but is is probably easier than fixing a 5 years old
>> poppler's bug.
> 
> Maybe suggesting this to upstream?
> 
It would not fix the bug anyway: you don't want to strictly depend on a (huge
deployment of) latex for this.

-- 
Luigi

Re: Is KTimeTracker defunct?

[Luigi Toscano]

Borden Rhodes ha scritto:
> I noticed that KTimeTracker's been pulled from Debian Buster for a
> while. I tried to do some upstream research and it seems to be buried
> in KDEPIM's source code. Does anyone familiar with the KDE community
> know whether it's been abandoned?

It does not exist anymore even upstream:

http://famillemontel.org/index.php/2015/08/02/kdepim-5-0/

If you checked kdepim.git, that repository is not used anymore and its content
was split in other repositories.


-- 
Luigi

Re: Why is Konqueror part of `kde-baseapps`

[Luigi Toscano]

Albin Otterhäll ha scritto:
> Hi!
> 
> Why is `konqueror`, `kwrite` and `keditbookmarks` part of the metapackage 
> `kde-baseapps`? This seems to be packages that nobody needs or uses, but is 
> part of all predefined metapackages (by being part of `kde-baseapps`).

As it was pointed out already, they were part of the same tarball until some
point (it was the same for other programs released by KDE).

The last bits of that tarball were split with the release of KDE Applications
16.12:
https://community.kde.org/Applications/16.12_Release_Notes#Tarballs_that_we_have_split

In order to not break the upgrades, the metapackage is still in place. It will
disappear in some cycles.

-- 
Luigi

Re: Konqueror is hidden and can't be brought back, but is still running after "Quit"

[Luigi Toscano]

Il 26 gennaio 2018 10:39:29 CET, Samuel RIFFLE  ha 
scritto:
>Xavier:
>I strongly rely on Konqueor, as a file browser;
>Yes, the web part needs updated;
>
>Do you know if the current plan is to completely, eliminate the file
>browser functionality ?
>I would like to know if that functionality can be adopted, if necesary
>by
>myself and those with similar needs.

The file browsing functionality of Konqueror are provided (and have been 
provided for a long while) by Dolphin (namely Dolphin provides a component, the 
Dolphin KPart, which is used by Konqueror and potentially other KParts-based 
application).

Ciao

-- 
Luigi

Re: Some KDE applications still outdated

[Luigi Toscano]

On Tuesday, 28 November 2017 12:45:51 CET Martin Steigerwald wrote:
> Hello.
> 
> There are still some KDE Applications not at 17.08.

I appreciate the effort in sending out news, but this is incorrect: the news 
is that "Some KDE Applications have been updated to 17.08"

> 
> For example kdenetwork including Kopete which is still at a version that
> uses KDE SC 4.14.

Even if all applications from KDE Applications 17.08 were uploaded, kopete 
would still be using KDE Platform 4.14. 

-- 
Luigi

Re: Stable : how can I configure akonadi/Pim ?

[Luigi Toscano]

Erwan David wrote:
> I'd like to subscribe to a caldav calendar to get it in the digital
> Clack/Calendar widget.
> 
> However I cannot find any way to configure akonadi, be it the server or
> the accounts.
> 
> Where is the configuration ?

You can't do it in Stretch, unfortunately. The version of kdepim which ships
the plugin for the clock is newer than the version in stable.

Ciao
-- 
Luigi

Re: tmux and vim in konsole not display correctly

[Luigi Toscano]

On Friday, 29 September 2017 10:44:30 CEST Sandro Knauß wrote:
> Hey,
> 
> i had an annoying issue for some time. If I start a vim inside a tmux inside
> a konsole, the lines get corrupted, and i can't read anymore, if I jump
> bigger chunks up/down in a document [#876362]
> 
> As I learned from the bugreport the solution is easy: install konsole from
> experimental (4:17.08.1-1):
> apt install -t experimental konsole
> [...]
> The following packages will be upgraded:
>   kde-l10n-de konsole konsole-kpart
> [...]
> 
> Be aware, this fix may introduce strange translation bugs (aka more
> untransalted strings) in the German desktop for a while... Because now you
> have a system mostly 16.12.0 but the translations are 17.08.1.

You should have the transaltions for Plasma and Frameworks, and all 
translations for programs part of KDE Applications >= 17.04, which include the 
translations in the each tarball (and then package):
https://community.kde.org/Applications/17.04_Release_Notes#Translations

This will be solved as soon as most programs part of KDE Applications are 
updated to newer versions.

-- 
Luigi

Re: Spectacle

[Luigi Toscano]

Jimmy Johnson wrote:

> 
> And Ksnapshot does NOT have the problem I saw with Spectacle, I use Ksnapshot
> in Plasma 5.8.7 and anything older. Does anybody know why we are using
> Spectacle and not Ksnapshot?  A good reason and not just because it's the
> default.

The development of ksnapshot ended; no Qt5 versions. Spectacle replaced it
(and as bonus it will work under a Wayland environment).

Ciao
-- 
Luigi

Re: Note on Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on

[Luigi Toscano]

Lisandro Damián Nicanor Pérez Meyer wrote:
> I have been told that this creates an interesting impact on Qt's performance. 
> Maybe disabling it or removing at-spi2-core where not needed might be a good 
> idead until we find a proper solution.
> 
> Help with this bug will be highly appreciated, we need to make Debian better 
> for everyone.
> 
The Randa Meetings, a KDE coding sprint which will happen in few days, this
year is focused on accessibility:
https://randa-meetings.ch/2017/06/16/randa-meetings-2017-make-kde-more-accessible/

Maybe is it worth to relay the issue to them? Even if it is on the Qt level, a
it could get some more attention by expert Qt programmers.

Ciao
-- 
Luigi

Re: jessie upgrade deemed very difficult + there is no simple way not to install konqueror

[Luigi Toscano]

inkbottle ha scritto:
> task-kde-desktop depends on kde-standard
> which depends on plasma-desktop
> which depends on kde-baseapps
> which depends on konqueror
> which depends on tons of difficult to understand seemingly outdated 
> dependencies.
> 
> The upgrade is very difficult
> 
> In fact I give up the upgrade altogether.
> I'll have to come to it through another angle:
> There are tons of packages which I deem old and unnecessary, and I find no 
> simple way not to install them.
> 
> And there is no simple way not to install konqueror.

So to summarize: the upgrade itself is not complicated; it is complicated only
because you don't want konqueror.

Can you please try at least to complete it, and list which "tons of packages"
are old and unnecessary? Konqueror in Stretch is not so different from
Konqueror in Jessie from the point of view of dependencies, so you should have
those dependencies already.

-- 
Luigi

Re: improving the UX with the default KDE installation

[Luigi Toscano]

fradev ha scritto:
> I didn't received many feedbacks about this and I'm thinking to send a bug
> report (wishlist) proposing the changes highlighted above.
> 
> What concerns me the most here is apper. Summarising:
> [...]
> - plasma-discover is too bugged to be used as a replacement

Do you have a specific set of bugs? Think also in the long term, this is going
to happen for Buster, and Discover is definitely developed.

plasma-discover-notifier works for me.

> - what about muon?

Muon is still developed; it is deb-centric, which should not be an issue here.
But let's focus on discover and try to fix it too, as it's cross-distro.


-- 
Luigi

Re: [stretch] kdialog and okular still based on kde4

[Luigi Toscano]

On Monday, 20 March 2017 17:01:24 CET solitone wrote:
> On Monday, 20 March 2017 16:42:21 CET Luigi Toscano wrote:
> > On Monday, 20 March 2017 16:36:11 CET solitone wrote:
> 
> > > As well as okular, kde-baseapps-bin (providing kdialog) would need an
> > > upgrade to 16.12 to take advantage of kf5.
> > 
> > That would be more complicated: kde-baseapps does not exist anymore, it
> > has
> > been split into its components (konqueror, kfind, keditbookmarks,
> > kdialog).
> 
> Ouch  :-(

I mean, this case will be handled (for the migration between Stretch and 
Buster), just it's not trivial.

Ciao
-- 
Luigi

Re: [stretch] kdialog and okular still based on kde4

[Luigi Toscano]

On Monday, 20 March 2017 16:36:11 CET solitone wrote:
> On Monday, 20 March 2017 16:23:06 CET Luigi Toscano wrote:
> > > Anyway, for the reason you gave, I think it would be a good thing if
> > > that
> > > was included in stretch. It might give a better user experience.
> > 
> > I think it's a bit too late given the release cycle, but I'm not a
> > packager
> > for those components.
> 
> I fear that too. It would be nice thought that it'd be at least included in
> sid, so that we could backport it to stretch.

I guess you mean experimental. That will happen for sure when sid is open 
again for changes after the release; using sid now means some more 
complications in case a fix needs to go directly into testing and then stable.

> 
> As well as okular, kde-baseapps-bin (providing kdialog) would need an
> upgrade to 16.12 to take advantage of kf5.

That would be more complicated: kde-baseapps does not exist anymore, it has 
been split into its components (konqueror, kfind, keditbookmarks, kdialog).

-- 
Luigi

Re: [stretch] kdialog and okular still based on kde4

[Luigi Toscano]

On Monday, 20 March 2017 16:32:06 CET solitone wrote:
> On Monday, 20 March 2017 16:15:43 CET inkbottle wrote:
> > what made you find out that the 16.12 version was kf5 based?
> > I can see it there:
> >  > version=16.12.0#okular>
> > But I have to read hard.
> 
> Hi,
> 
> we had a discussion on the kde mailing list, and a gentoo user spotted this
> out. Looking at package versions in gentoo it's pretty easy to figure out
> whether something is based on kf5 or kf4.

The package name in gentoo seems to have no specific hints; but anyway, 
looking at the dependencies in Debian you can spot the version of Qt used 
(and/or whether it's kdelibs4 vs Frameworks).

Also, it's in the second paragraph on the official announcement:
https://www.kde.org/announcements/announce-applications-16.12.0.php

Ciao
-- 
Luigi

Re: [stretch] kdialog and okular still based on kde4

[Luigi Toscano]

On Monday, 20 March 2017 16:15:43 CET inkbottle wrote:
> On Monday, March 20, 2017 2:56:03 PM CET solitone wrote:
> > So my question is: is there any chance that relase 16.12 of okular and
> > kdialog (based on kde-frameworks5)  are included in stretch? Currently
> > we've got 16.08 (kde4 based), both in stretch an in sid.
> 
> That is interesting, I haven't spotted that Okular was based on kde4.
> Probably because it's so pivotal, that there is no question about
> installing it or not.
> 
> Also, what made you find out that the 16.12 version was kf5 based?
> I can see it there:
>  version=16.12.0#okular>
> But I have to read hard.

It's an implementation detail and normal users should not care, save 
unfortunately for this HiDPI issue.

> 
> Anyway, for the reason you gave, I think it would be a good thing if that
> was included in stretch. It might give a better user experience.

I think it's a bit too late given the release cycle, but I'm not a packager 
for those components.

Ciao
-- 
Luigi

Re: improving the UX with the default KDE installation

[Luigi Toscano]

On Friday, 17 March 2017 15:57:40 CET inkbottle wrote:
> I too vote it out of (almost) compulsory installation:
> 
> Konqueror "was" a really great idea, especially, to my mind, through the
> kpart things: One could open several Okular document simultaneously, have
> efficient tab organization, the possibility to bookmark them
> simultaneously... Unfortunately it never worked, since one of the most
> praised functionality, the annotation or review tools, never integrated
> with it -- by the way, this annotation functionality of Okular still lack
> support for utf-8, years after the bug have been reported,
> https://bugs.freedesktop.org/show_bug.cgi?id=65956
> (I know it's a poppler bug).
> 
> Also Konqueror doesn't integrate anymore with plasma, is redundant...
> 
> Konqueror depends on *Dolphin4*...

Regardless of the general decision about this, just remember that Konqueror 
from Applications 16.12 is based on Frameworks. (and dolphin4 is just a small 
library anyway).


> 
> I like the "file size view" feature which I find far superior to
> "filelight". This functionality "is" provided by "k4dirstat" (which is an
> outdated version of qdirstat, http://kdirstat.sourceforge.net/)
> The Konqueror version is faster and more convenient, to my mind.
> 
> *kde-plasma-desktop* (package), *depends* on kde-baseapps, which in turn
> *depends* on konqueror (and kfind...), which again depend on "outdated
> technologies", like *dolphin4*
This is probably an historical artifact before the split of kde-baseapps 
(which happened over time, the last part of the split few months ago).

> 
> The only thing bad if Konqueror is not forced in anymore, is that one will
> have to amend wikipedia article (https://en.wikipedia.org/wiki/Konqueror).
> 
> More and more Kde things are called Plasma nowadays... So suppressing it is
> not as bad as if it was called "Pomperor" (sorry about that).

Another note on naming (which I know that you know, but the sentence above 
could be a bit unclear). The number of components of the Plasma project did 
not did not change significantly in its history (check the upstream tarballs).


Ciao
-- 
Luigi

Re: What happened to kdesu?

[Luigi Toscano]

On Monday, 20 February 2017 07:59:55 CET Ferdinand Thommes wrote:
>  https://blog.martin-graesslin.com/blog/2017/02/editing-files-as-root/
> 

That's totally unrelated and affects code which is not in Debian yet.

> Am 20.02.2017 02:21 schrieb Rubin Abdi:
> > It seems like the package has disappeared from sid's repo?

Re: stretch/KDE5: icons disappeared from system tray

[Luigi Toscano]

On Tuesday, 24 January 2017 14:02:26 CET solitone wrote:
> Hi Andy, and thanks for your feedback!
> 
> On Tuesday, January 24, 2017 9:23:37 AM CET Andy G Wood wrote:
> > I have seen this in recent days on Debian testing.  It was caused by
> > updating my system part way through the very recent large KDE update.  In
> > other words, some packages were at the old version and some at the new.
> 
> Yes, that would be the only possible explanation. Although my last update
> was on 20th January, and since then I rebooted my system several times, but
> I noticed the issue only yesterday (23rd January). So I didn't relate the
> issue with that update, but perhaps I simply didn't notice it?

You probably did not notice it or you did some partial updates on the way.

> 
> > It took a few days for all the necessary package updates to flow though
> > into testing.  As of yesterday (23rd January), an up to date Debian
> > testing
> > does not exhibit this any more ... for me.
> 
> Few hours ago I got a notification showing I've got 293 packages upgradable
> (wow!), many of which are related to KDE. For instance, just to mention
> three KDE packages, it proposes to upgrade kde5 from 5.27.0-1 to 5.28.0-1,
> and plasma-desktop and plasma-widgets-addons from 4:5.8.2-1 to 4:5.8.4-1.
> What versions do you have of these packages? I'm a bit worried and I
> haven't yet confirmed this huge update!
> 

Yes, pieces of both Frameworks and Plasma ("kde5" does not map any existing 
artifact, so please don't use it) landed asynchronously in the last day (the 
last ones two days ago). The libraries part of Frameworks should be upgraded 
together, and probably most pieces part of Plasma should be upgraded together.

Now testing has Frameworks 5.28, and mostly Plasma 5.8.4.

-- 
Luigi

Re: stretch/KDE: system notifications at 100% volume

[Luigi Toscano]

On Monday, 16 January 2017 17:26:58 CET solitone wrote:
> Hi,
> 
> I'm on stretch, and use KDE plasma desktop. Whenever I get a notification,
> the Built-in Audio Analog Stereo volume jumps to 100%, irrespective of the
> volume level I previously set (e.g. 50%). This means that the notification
> sound is louder than I'd like. Besides, also all other later sounds are too
> loud. As a consequence, I need to lower again the volume manually, but at
> the next notification I have the same issue. If the Built-in Audio Analog
> Stereo output is muted, it stays muted even when notifications occur, but
> obviously this is just a workaound to avoid those loud sounds, not a real
> solution--I'd rather keep volume at 50% or something.

Try to disable flat-volumes in pulseaudio. See for example the discussion 
here:

https://bugzilla.redhat.com/show_bug.cgi?id=1265267

-- 
Luigi

Re: KDialog very slow on stretch

[Luigi Toscano]

solitone ha scritto:
> Thanks to Luigi's suggestion, I found out why KDialog was so slow. It 
> depended 
> on some shortcuts I put in the Places section, pointing to some NFS 
> directories. When those NFS directories are unavailable, KDialog takes 
> minutes 
> to open.
> 
> Now, while this appears to be a problem in KDialog, it is not in Dolphin. So 
> it seems something is wrong in KDialog. Should I submit a bug report on this 
> issue?

Do you mean that you can have the offending URL in the places pane of Dolphin
without issues, but they are slow in the open/save dialog?
Please keep in mind that if you talk about KDialog, you may end up with the
wrong product in bugzilla (the kdialog program).

There are few reports on bugs.kde.org which may be related, and some of them
still applies to the kdelibs4 version too.
This one seems to be the closest one (even if probably opened against the
wrong component, so it will be ignored forever):
https://bugs.kde.org/show_bug.cgi?id=352827

-- 
Luigi

Re: konsole --version crashes

[Luigi Toscano]

kamaraju kusumanchi ha scritto:
> On Thu, Dec 29, 2016 at 7:25 AM, Luigi Toscano  
> wrote:
>>
>> When the backtrace starts, do you get the prompt of (gdb) again?
> 
> Yes. I get the prompt of (gdb) again.
> 
>> Try to type:
>>
>> (gdb) thread apply all backtrace
>>
>> and see if it gives you more output.
> 
> The output looks pretty much the same even with this command.
> 
> % gdb konsole
> ...
> Reading symbols from konsole...Reading symbols from
> /usr/lib/debug/.build-id/2b/559c27a0259b9f5254ac6482a73ecd5f0fce6a.debug...done.
> done.
> (gdb) set args --version
> (gdb) thread apply all backtrace
> (gdb) r
> Starting program: /usr/bin/konsole --version
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7fffe414b700 (LWP 9523)]
> [New Thread 0x7fffe2268700 (LWP 9524)]
> konsole 16.08.2
> 
> Thread 3 "QDBusConnection" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffe2268700 (LWP 9524)]
> 0x744b03ef in QObject::disconnect (sender=0x557d7d90,
> signal=signal@entry=0x0,
> receiver=receiver@entry=0x7fffd40030f0, method=method@entry=0x0)
> at kernel/qobject.cpp:2956
> 2956kernel/qobject.cpp: No such file or directory.
> (gdb) bt
> #0  0x744b03ef in QObject::disconnect (sender=0x557d7d90,
> signal=signal@entry=0x0,
> receiver=receiver@entry=0x7fffd40030f0, method=method@entry=0x0)
> at kernel/qobject.cpp:2956
> #1  0x77edfd50 in QObject::disconnect (member=0x0,
> receiver=0x7fffd40030f0, this=)
> at ../../include/QtCore/../../src/corelib/kernel/qobject.h:336
> #2  QDBusConnectionPrivate::closeConnection
> (this=this@entry=0x7fffd40030f0) at qdbusintegrator.cpp:1145
> #3  0x77ecc7e2 in QDBusConnectionManager::run (
> this=0x77f41d60 <(anonymous
> namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
> qdbusconnection.cpp:188
> #4  0x742b0da8 in QThreadPrivate::start (
> arg=0x77f41d60 <(anonymous
> namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
> thread/qthread_unix.cpp:368
> #5  0x70b16464 in start_thread (arg=0x7fffe2268700) at
> pthread_create.c:333
> #6  0x778dd9df in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

I spoke with the QtBus maintainer (Thiago Macieira) and he mentioned few race
conditions which requires some (unmerged) patches (unmerged because they cause
regression on windows), quoting:
"https://codereview.qt-project.org/180231 and 232 at least"

They are not apparently applied to the Qt packages in Debian.

Ciao
-- 
Luigi
> 
> 
>> Just to be sure: did you restart after the last updates (not only kernel, 
>> also
>> Qt)?
> 
> I did not do that before. But now I rebooted the computer and the
> backtrace above is what I get after the reboot.
> 
> thanks
> raju
> 

Re: KDialog very slow on stretch

[Luigi Toscano]

solitone ha scritto:
> Hi,
> 
> I recently installed debian stretch with KDE. Everything works pretty well, 
> exept for KDialog, which is very slow. It takes 30 seconds or so to open, and 
> allow me to choose for a filename, a target directory, and so on. Everything 
> else in KDE is instantaneous, instead. When KDialog finally starts, it works 
> normally. It's just the initial time required to start it up that is bad.
> 
> My feeling is that it was some recent package upgrade that ruined it. If I 
> remember right, after installation I didn't have this problem. I'm not sure 
> though.

kdialog in stretch is part of kde-baseapps (it will be in its own package in
the future, as kde-baseapps has been split). The version in stretch is Qt4
based, and there have been no relevant updates to that code.
Which version of kde-baseapps do you use? Does it happen with any call to
kdialog, even with

kdialog --msgbox foo
?

-- 
Luigi

Re: konsole --version crashes

[Luigi Toscano]

kamaraju kusumanchi ha scritto:
> On Thu, Dec 29, 2016 at 2:00 AM, Andrey Rahmatullin  wrote:
>> On Thu, Dec 29, 2016 at 11:59:07AM +0500, Andrey Rahmatullin wrote:
>>> On Thu, Dec 29, 2016 at 01:52:20AM -0500, kamaraju kusumanchi wrote:
 Is the above link up to date? I ask because
 https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Debian
 says that there are -dbg packages that I should install to get
 backtrace. But I do not see any packages such as konsole-dbg or
 libqt5dbus5-dbg in the archive.
>>> They are now konsole-dbgsym and libqt5dbus5-dbgsym. For other packages the
>>> names may differ.
>> You also need to enable the debug repo, see
>> https://wiki.debian.org/AutomaticDebugPackages
> 
> Thanks. Just for the record, I also found
> https://wiki.debian.org/HowToGetABacktrace to be useful for this
> exercise. Here is the backtrace with all the symbols.
> 
> 
>  % gdb konsole
> ...
> Reading symbols from konsole...Reading symbols from
> /usr/lib/debug/.build-id/2b/559c27a0259b9f5254ac6482a73ecd5f0fce6a.debug...done.
> done.
> (gdb) set args --version
> (gdb) r
> Starting program: /usr/bin/konsole --version
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7fffe414b700 (LWP 23997)]
> [New Thread 0x7fffe2268700 (LWP 23998)]
> konsole 16.08.2
> 

When the backtrace starts, do you get the prompt of (gdb) again? Try to type:

(gdb) thread apply all backtrace

and see if it gives you more output.

Just to be sure: did you restart after the last updates (not only kernel, also
Qt)?


-- 
Luigi

Re: konsole --version crashes

[Luigi Toscano]

kamaraju kusumanchi ha scritto:
> On Wed, Dec 28, 2016 at 2:36 PM, solitone  wrote:
>> On Wednesday, December 28, 2016 10:09:18 PM CET Andrey Rahmatullin wrote:
>>> On Wed, Dec 28, 2016 at 12:05:43PM -0500, kamaraju kusumanchi wrote:
 Can someone reproduce the problem in testing and/or know how to fix it?
>>>
>>> Works for me on testing.
>>
>> Works also for me:
>>
>> solitone@alan:~$ konsole --version
>> konsole 16.08.2
> 
> Thanks Andrey and solitone. I guess I am the chosen one ;) Any ideas
> how to narrow down the problem? I get this crash with dolphin
> --version. But not with konqueror --version.

The available version of Konqueror is still kdelibs4 (Qt4) based.
> 
>  % dolphin --version
> dolphin 16.08.2
> KCrash: crashing... crashRecursionCounter = 2
> KCrash: Application Name = dolphin path = /usr/bin pid = 12741
> KCrash: Arguments: /usr/bin/dolphin --version
> KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi
> from kdeinit
> sock_file=/run/user/1000/kdeinit5__0
> zsh: suspended (signal)  dolphin --version

Do you see drkonqui starting? You should see the windows with the crash
information (including the stack trace); without that information there is no
much that we can do.

If the window does not appear, you can try to run konsole, dolphin or any
other crashing application using gdb and extract the stacktrace:

https://community.kde.org/Guidelines_and_HOWTOs/Debugging/Debugging_with_GDB
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports

-- 
Luigi

Re: Fwd: KDE Project Security Advisory: KMail: JavaScript access to local and remote URLs

[Luigi Toscano]

On Friday, 7 October 2016 15:36:01 CEST Martin Steigerwald wrote:
> Hi!
> 
> Did not yet open a Debian bug report.
> 
> Unfortunately needs Qt 5.7 to fully fix it :(.

Afaik developers are already aware of it.

It was discussed on IRC; only one bug apparently applies (as QtWebEngine is 
not available yet).

-- 
Luigi

Re: rar files and ARK

[Luigi Toscano]

On Thursday, 29 September 2016 12:23:33 CEST newbee...@nativobject.net wrote:
> Hi,
> 
> I have some trouble with ark (4:16.04.3-1).
> 
> When I'm trying to open rar file ark say
> 
> "Ark was unable to open XXX.rar No suitable plugin found.
> 
> Ark does not seem to support this file type."
> 
> rar (2:5.3.b2-1) and unrar (1:5.3.2-1) are installed and manage to
> uncompress this file...
> 
> Is there any trick to correct that issue ?

Most likely the breakage introduced by shared-mime-info 1.7.

https://bugs.kde.org/show_bug.cgi?id=368786

Fixed in the newer ark.

Ciao
-- 
Luigi

Re: Btrfs & Dolphin

[Luigi Toscano]

On Monday, 12 September 2016 11:20:24 CEST Leslie S Satenstein wrote:
> Would you not say that xfs is preferred over ext4?  In benchmarks and
> recovery exercises, it appears to come out ahead for performance and
> recovery. The negative aspect of deploying xfs is that once the partition
> size is set, you cannot add or reduce it's size without a reformat of that
> partition.

You can't shrink it, but you can grow it.

-- 
Luigi

Re: task bar missing

[Luigi Toscano]

Il 06.09.2016 08:50 Thom Castermans ha scritto:


2016-09-06 6:21 GMT+02:00 Gary Dale :

This has been going on for a few weeks. I was hoping that it would 
get

fixed but instead it's gotten worse.

I'm running Debian/Testing on an AMD64 machine - with KDE obviously.

When I reboot my computer, which I only do every week or so 
depending

on on how it's behaving, the task bar is missing after I log in. Up
until today, I could log out and it would reappear with the second
login.


By task bar, do you mean a Plasma panel? I am not experiencing the 
same

issue. Does it happen when you add another panel too (to that panel)?
Something may have gone wrong during an update at some point. Also, 
it
may help to not lock your widgets between reboots. Last week there 
was a
minor issue with icons not appearing in the system tray that was 
fixed by

that.



Few pieces of Plasma 5.7 are not in testing yet. plasma-desktop and 
plasma-workspace for example are still 5.6.x.


This may or not may related to the issue, but I would first recheck 
with all the components with the same version.


So either you get the missing pieces from unstable or you wait a bit.

--
Luigi



Con Smart 3 Giga a 9 euro/4 sett navighi veloce, chiami e invii SMS dal 
tuo smartphone verso tutti i fissi e mobili in Italia. Passa a Tiscali 
Mobile! http://casa.tiscali.it/mobile/

Re: Plasma 5.7.2 in Debian?

[Luigi Toscano]

Luigi Toscano ha scritto:
> Martin Steigerwald ha scritto:
>> Am Samstag, 27. August 2016, 17:15:30 CEST schrieb Luigi Toscano:
>>> Maximiliano Curia ha scritto:
>>>> plasma-workspace tests were failling in the 5.7.[0-2] releases and we
>>>> decided to wait till this gets fixed, this was finally fixed in 5.7.3 (by
>>>> moving the failling tests to a non packageable project). By that time 5.8
>>>> was announced to be the first lts, so it makes sense to wait for 5.8,
>>>> which should be released "real soon now"(tm).
>>>
>>> As this is no more true, as most of Plasma 5.7.x landed in unstable breaking
>>> the remaining 5.6 bits, would be possible to have the missing bits (from a
>>> quick glance, plasma-desktop, plasma-workspace and khotkeys for sure)?
>>
>> I just saw on debian-qt-kde-ml, plasma-workspace 5.7.4 uploaded again after 
>> an 
>> initial reject due to source only upload, so if ftpmasters accept it this 
>> time, at least this one is coming.
>>
> 
> The reject afaik does not depend on the package being source-only; it
> introduces new binaries.

I stand corrected sorry. The reject was, as you wrote, because it was a source
only-upload for a package with new binaries and that should have gone through 
NEW.

> 
> Maybe a way to solve this is a push to experimental, so that a block of new
> packages can "decant" in experimental without breaking the rest of the world.
> 

This is still a valid suggestion.

-- 
Luigi

Re: Plasma 5.7.2 in Debian?

[Luigi Toscano]

Diederik de Haas ha scritto:
> On zaterdag 27 augustus 2016 22:49:00 CEST Luigi Toscano wrote:
>> Nothing breaks for me, because I have all 5.6.x packages on hold. The fact
>> that 3 or 4 different users on IRC (including a DD) had their plasma-desktop
>> packages removed means that there is a conflict $somewhere.
> 
> I was one of them and the problem was because I used plasma-discover (for the 
> first time) on my laptop to update packages instead of aptitude what I 
> normally 
> do. While it did update several packages, it removed several others like 
> plasma-desktop, plasma-workspace, sddm and a bunch of other critical packages 
> for KDE *without* informing me about it and thus completely broke my KDE 
> system.
> The DD in question didn't pay proper intention and missed that the upgrade on 
> his system would remove sddm and others.
> On my desktop PC, I have several packages that don't get upgraded with 
> 'aptitude safe-upgrade' precisely because it would brake things. 
> If I'd do 'aptitude full-upgrade' it would indeed remove a bunch of packages, 
> including plasma-desktop and thus I don't do that.
> 
>>> I do think however it would be good to have all of plasma at same major 
>>> version at least. So I love to see these in the newer version as well.
>>
>> It's not a matter of good or bad, it's the same as Frameworks: maybe with
>> some exceptions of "leaf" packages (like the icons for Frameworks), but the
>> core packages should be available in the same version.
> 
> And that's precisely what's now being enforced and thus 'aptitude safe-
> upgrade' won't upgrade to these latest packages until all relevant packages 
> are at the same versions.

It's probably not this case, but in general safe-upgrade is not enough. In
some cases you need to remove a package to proceed and safe-upgrade (if I read
its documentation correctly (*)) does not do that. So the status is fine when
it's full-upgrade-proof (aka apt dist-upgrade).

(*) (Interesting enough I just discovered I don't have aptitude installed on
the my systems; never used it since it was trying to remove most of my KDE
programs few years ago).

-- 
Luigi

Re: Plasma 5.7.2 in Debian?

[Luigi Toscano]

Martin Steigerwald ha scritto:
> Am Samstag, 27. August 2016, 17:15:30 CEST schrieb Luigi Toscano:
>> Maximiliano Curia ha scritto:
>>> plasma-workspace tests were failling in the 5.7.[0-2] releases and we
>>> decided to wait till this gets fixed, this was finally fixed in 5.7.3 (by
>>> moving the failling tests to a non packageable project). By that time 5.8
>>> was announced to be the first lts, so it makes sense to wait for 5.8,
>>> which should be released "real soon now"(tm).
>>
>> As this is no more true, as most of Plasma 5.7.x landed in unstable breaking
>> the remaining 5.6 bits, would be possible to have the missing bits (from a
>> quick glance, plasma-desktop, plasma-workspace and khotkeys for sure)?
> 
> I just saw on debian-qt-kde-ml, plasma-workspace 5.7.4 uploaded again after 
> an 
> initial reject due to source only upload, so if ftpmasters accept it this 
> time, at least this one is coming.
> 

The reject afaik does not depend on the package being source-only; it
introduces new binaries.

Maybe a way to solve this is a push to experimental, so that a block of new
packages can "decant" in experimental without breaking the rest of the world.

Ciao
-- 
Luigi

Re: Plasma 5.7.2 in Debian?

[Luigi Toscano]

Martin Steigerwald ha scritto:
> Am Samstag, 27. August 2016, 17:15:30 CEST schrieb Luigi Toscano:
>> Maximiliano Curia ha scritto:
>>> ¡Hola Shmerl!
>>>
>>> El 2016-08-18 a las 16:46 -0400, Shmerl escribió:
>>>> I didn't monitor this topic, so I could have missed some announcements or
>>>> previous discussion, so please excuse me if it was already mentioned
>>>> before. When is Plasma 5.7.2 coming to Debian repos? I see some packages
>>>> like kwin-x11 are already 5.7.0, while others like plasma-desktop are
>>>> 5.6.5.
>>>>
>>>> In general, what is the reason that they are different versions, is it
>>>> because they are uploaded gradually, or there are some problems with
>>>> newer
>>>> versions of some of them and they aren't uploaded until those problems
>>>> are
>>>> fixed?
>>>
>>> plasma-workspace tests were failling in the 5.7.[0-2] releases and we
>>> decided to wait till this gets fixed, this was finally fixed in 5.7.3 (by
>>> moving the failling tests to a non packageable project). By that time 5.8
>>> was announced to be the first lts, so it makes sense to wait for 5.8,
>>> which should be released "real soon now"(tm).
>>
>> As this is no more true, as most of Plasma 5.7.x landed in unstable breaking
>> the remaining 5.6 bits, would be possible to have the missing bits (from a
>> quick glance, plasma-desktop, plasma-workspace and khotkeys for sure)?
> 
> Currently Maxy is uploading 5.7.4 to unstable already, I thought from the 
> above he would go for 5.8, but well its usual practice to at least wait to .1 
> versions.

I've noticed it, even if plasma-workspace will have to wait in NEW. Maybe
planned, waiting for the existing packages to land (even if is not required),
but it was not the status when I wrote.


> 
> Luigi, what breaks for you? I do have plasma-desktop and plasma-workspace at 
> 5.6.5 and khotkeys 5.7.0 currently and see no  obvious breakages from usage 
> point of view, or do you mean the tests?

Nothing breaks for me, because I have all 5.6.x packages on hold. The fact
that 3 or 4 different users on IRC (including a DD) had their plasma-desktop
packages removed means that there is a conflict $somewhere.


> I do think however it would be good to have all of plasma at same major 
> version at least. So I love to see these in the newer version as well.

It's not a matter of good or bad, it's the same as Frameworks: maybe with some
exceptions of "leaf" packages (like the icons for Frameworks), but the core
packages should be available in the same version.

-- 
Luigi

Re: Plasma 5.7.2 in Debian?

[Luigi Toscano]

Maximiliano Curia ha scritto:
> ¡Hola Shmerl!
> 
> El 2016-08-18 a las 16:46 -0400, Shmerl escribió:
>> I didn't monitor this topic, so I could have missed some announcements or
>> previous discussion, so please excuse me if it was already mentioned before.
>> When is Plasma 5.7.2 coming to Debian repos? I see some packages like
>> kwin-x11 are already 5.7.0, while others like plasma-desktop are 5.6.5.
> 
>> In general, what is the reason that they are different versions, is it
>> because they are uploaded gradually, or there are some problems with newer
>> versions of some of them and they aren't uploaded until those problems are
>> fixed?
> 
> plasma-workspace tests were failling in the 5.7.[0-2] releases and we decided
> to wait till this gets fixed, this was finally fixed in 5.7.3 (by moving the
> failling tests to a non packageable project). By that time 5.8 was announced
> to be the first lts, so it makes sense to wait for 5.8, which should be
> released "real soon now"(tm).

As this is no more true, as most of Plasma 5.7.x landed in unstable breaking
the remaining 5.6 bits, would be possible to have the missing bits (from a
quick glance, plasma-desktop, plasma-workspace and khotkeys for sure)?

-- 
Luigi

Re: digikam 5: then ksnapshot is removed

[Luigi Toscano]

Andrey Rahmatullin ha scritto:
> On Sun, Aug 14, 2016 at 03:19:01PM +0100, Brad Rogers wrote:
>>> in the KDE Daemon global hotkey section and it doesn't launch spectacle.
>> Delete ksnapshot, enter spectacle, hit 'Apply'.
> I didn't understand what do you mean but I've found that it's not a
> builting hotkey (unfortunately for a DE) but one manually configured via
> kmenuedit.
> 
spectacle should carry the proper configuration to allow the snapshot with the
Print button. khotkeys was even changed to not hardcode ksnapshot:
https://git.reviewboard.kde.org/r/126091/

Did you restart the Plasma session completely (including all the background
services) after installing kde-spectacle *and* removing ksnapshot?

-- 
Luigi

Re: KDEPIM: Display glitches

[Luigi Toscano]

Il 06 agosto 2016 16:16:50 CEST, Michael Schuerig  
ha scritto:
>
>As far as I can tell, yet, things are working. But there are a number
>of 
>display glitches in several programs.
>
>KMail
>* Message Headers are missing
>* Menu View > Headers does not have a submenu

Install kdepim-addons.


-- 
Luigi

Re: KDEPIM ready to be more broadly tested (libkpim.*4)

[Luigi Toscano]

Il 29 luglio 2016 20:30:43 CEST, inkbottle  ha scritto:
>Hi,
>
>So I did eventually upgraded to new KDEPIM.
>
>When doing my upgrade I saw some "libkpimindent.*4" and more generally 
>"libkpim.*4" things. I resolved to remove them for the sake of
>cleanness...
>
>Hence I had to remove "kopete" and hence kde-standard too.
>
>I understood kopete is something of the past (?); if so it could be
>removed 
>from kde-standard: is kde-standard a Debian thing?


Kopete is still developed and being ported to Frameworks. 
kde-standard is a Debian-specific metapackage, which probably has no sense 
given the evolution of the meaning of "KDE".

Ciao

-- 
Luigi

Re: kde 5.7

[Luigi Toscano]

Martin Steigerwald ha scritto:
> Am Samstag, 9. Juli 2016, 12:25:14 CEST schrieb Andrej Kacian:
>> On Sat, 09 Jul 2016 12:00:20 +0200
>>
>> Martin Steigerwald  wrote:
>>> Diederik, I think this is about "I want an always stable and releaseable
>>> testing" again.
>>
>> I disagree. This is more about knowing if the package combination
>> I am currently running is worth testing and reporting found bugs on, or
>> whether I am in some temporary state where some packages I should
>> have are still waiting in the queue, and any bug report I make would
>> only waste time of the packagers, or whoever else will be reviewing it.
> 
> That is part of what this list is for.
> 
> Or do you think Debian/Kubuntu Qt/KDE packagers always know which versions of 
> which packages go together nicely or not? These effects of mixed KDE 
> Frameworks packages between 5.22 and 5.23 have been unknown to them as well.
> 
> And heck, if you only want to test when all KF packages are at 5.23 thats 
> easy 
> enough to tell as well.

Which does not mean that testing users should find their distribution broken
every week because some random packages from a block (Frameworks, Plasma)
which was supposed to stay together were upgraded randomly.

> 
>> If the KDE packaging layout was simpler, and all packages followed
>> e.g. same naming policy or same versioning scheme, it wouldn't be an
>> issue, as it would be easy to verify whether I still have some packages
>> waiting for an upgrade. But there are various sets of packages
>> (around kf5, plasma, kdepim, ...), each having various and different
>> version numbers, and it is quite taxing trying to make heads or tails
>> of it all.
> 
> Feel free to bring this up with upstreams distributions mailing list.
> 
> Just bringing this up here is – again – a waste of energy.

It is not. We can identify what the problem is: some blocks of packages needs
to be handled together. Fedora does it, for example.

> 
>>> And, yes, while I think some improvements in the order packages enter
>>> testing, would certainly be nice, I also think that the main purpose of
>>> testing is just that: Preparing Debian for release by testing the heck
>>> out of it. That it is kind of a rolling distro, is in my eyes just a side
>>> effect of it. And I think for a rolling distro unstable is more suitable
>>> anyway.
>>>
>>> So that is where I will focus my energy: Testing out the new packages
>>> while
>>> fully understanding that there can be transitional states of breakage that
>>> do not even matter for the final stable distribution as it won´t have KF
>>> 5.22 packages.
>>
>> Fully agreed here, but first you have to be able to identify which are
>> the transitional states, otherwise you're just bringing more noise to
>> the packagers, as I described above.
> 
> Then help to make this possible.
> 
> Otherwise its a complaint. Its as easy as that. In my oppinion a complaint is 
> usually something that is not intended to create a real change. And thats 
> usually exactly the effect of it.
> 
> All of this discussion is a huge waste of time unless someone in here chooses 
> to *act*. See, we had this before. Every two months an epic discussion here. 
> Any real change up to now? *None*.

Throwing in new packages does not help. Let's start from here. For example,
Plasma 5.7 packages should have gone in until at least all 5.23 was in
testing. First solve the known issues, then adds new thing.

-- 
Luigi