Re: Dolphin 24.08 on Plasma 6: protocols in kio-extras Qt 5/KF 5 only (was: Re: Some feedback on KDE6 install)

[Sedat Dilek]

INFO: Thumbnails / Preview now displays in systemsettings > wallpaper
and dolphin (e.g. PNG files).

-Sedat-

On Wed, Sep 4, 2024 at 3:26 PM Sedat Dilek  wrote:
>
> Hi Patrick,
>
> thanks for the upgrades of dolphin + kio-extras.
>
> So, the feedback looks promising and I will test this evening.
>
> Will you add yourself to uploaders?
>
> Best regards,
> -Sedat-
>
> https://deb.debian.org/debian/pool/main/d/dolphin/dolphin_24.08.0-3.dsc
> https://deb.debian.org/debian/pool/main/k/kio-extras/kio-extras_24.08.0-1.dsc
>
> On Tue, Sep 3, 2024 at 11:38 PM Patrick Franz  wrote:
> >
> > Hej,
> >
> > Am Montag, 2. September 2024, 17:19:38 CEST schrieb Martin Steigerwald:
> > [...]
> > > Hmm, I have an idea:
> > >
> > > kio-extras is still 4:23.08.4-2 and only contains Qt 5/KF 5 protocols.
> > > In there are all the protocols that Dolphin said were missing above
> > > and then some.
> > >
> > > I think once someone has updated KIO related packages things will work
> > > again.
> >
> > Just upload kio-extras 24.08.0 to experimental as well as an updated
> > version of dolphin that will now recommend kio-extras 24.08 or higher.
> >
> > I hope that solves some of the problems.
> >
> >
> > --
> > Med vänliga hälsningar
> >
> > Patrick Franz
> >
> >

Re: Dolphin 24.08 on Plasma 6: protocols in kio-extras Qt 5/KF 5 only (was: Re: Some feedback on KDE6 install)

[Martin Steigerwald]

Patrick Franz - 03.09.24, 23:37:39 CEST:
> Just upload kio-extras 24.08.0 to experimental as well as an updated
> version of dolphin that will now recommend kio-extras 24.08 or higher.
> 
> I hope that solves some of the problems.

I confirm that your upload fixes the reported issues.

Many thanks, Patrick!

-- 
Martin - please no carbon copy to me

Re: Dolphin 24.08 on Plasma 6: protocols in kio-extras Qt 5/KF 5 only (was: Re: Some feedback on KDE6 install)

[Sedat Dilek]

Hi Patrick,

thanks for the upgrades of dolphin + kio-extras.

So, the feedback looks promising and I will test this evening.

Will you add yourself to uploaders?

Best regards,
-Sedat-

https://deb.debian.org/debian/pool/main/d/dolphin/dolphin_24.08.0-3.dsc
https://deb.debian.org/debian/pool/main/k/kio-extras/kio-extras_24.08.0-1.dsc

On Tue, Sep 3, 2024 at 11:38 PM Patrick Franz  wrote:
>
> Hej,
>
> Am Montag, 2. September 2024, 17:19:38 CEST schrieb Martin Steigerwald:
> [...]
> > Hmm, I have an idea:
> >
> > kio-extras is still 4:23.08.4-2 and only contains Qt 5/KF 5 protocols.
> > In there are all the protocols that Dolphin said were missing above
> > and then some.
> >
> > I think once someone has updated KIO related packages things will work
> > again.
>
> Just upload kio-extras 24.08.0 to experimental as well as an updated
> version of dolphin that will now recommend kio-extras 24.08 or higher.
>
> I hope that solves some of the problems.
>
>
> --
> Med vänliga hälsningar
>
> Patrick Franz
>
>

Re: Dolphin 24.08 on Plasma 6: protocols in kio-extras Qt 5/KF 5 only (was: Re: Some feedback on KDE6 install)

[Matthieu Gallien]

Dear Patrick,

On mardi 3 septembre 2024 23:37:39 CEST Patrick Franz wrote:
> Hej,
> 
> Am Montag, 2. September 2024, 17:19:38 CEST schrieb Martin Steigerwald:
> [...]
> > Hmm, I have an idea:
> > 
> > kio-extras is still 4:23.08.4-2 and only contains Qt 5/KF 5 protocols.
> > In there are all the protocols that Dolphin said were missing above
> > and then some.
> > 
> > I think once someone has updated KIO related packages things will work
> > again.
> 
> Just upload kio-extras 24.08.0 to experimental as well as an updated 
> version of dolphin that will now recommend kio-extras 24.08 or higher. 
> 
> I hope that solves some of the problems.

This fixed the missing previews in dolphin.
Thanks a lot for this. I really appreciate it !

Best regards
--
Matthieu

signature.asc
Description: This is a digitally signed message part.

Re: Re: Dolphin 24.08 on Plasma 6: protocols in kio-extras Qt 5/KF 5 only (was: Re: Some feedback on KDE6 install)

[Eric Valette]

Just upload kio-extras 24.08.0 to experimental as well as an updated 
version of dolphin that will now recommend kio-extras 24.08 or higher. 


I hope that solves some of the problems.



Yes it does. Dolphin now works correctly. And the thumbnails for 
wallpapers in systemsettings do also.


Good catch Martin and thanks to uploader.


--
Eric Valette

Re: Dolphin 24.08 on Plasma 6: protocols in kio-extras Qt 5/KF 5 only (was: Re: Some feedback on KDE6 install)

[Martin Steigerwald]

Patrick Franz - 03.09.24, 23:37:39 CEST:
> Am Montag, 2. September 2024, 17:19:38 CEST schrieb Martin Steigerwald:
> [...]
> > kio-extras is still 4:23.08.4-2 and only contains Qt 5/KF 5 protocols.
> > In there are all the protocols that Dolphin said were missing above
> > and then some.
> > 
> > I think once someone has updated KIO related packages things will work
> > again.
> 
> Just upload kio-extras 24.08.0 to experimental as well as an updated
> version of dolphin that will now recommend kio-extras 24.08 or higher.
> 
> I hope that solves some of the problems.

Great! I will give it a try and report back.

-- 
Martin

Re: Dolphin 24.08 on Plasma 6: protocols in kio-extras Qt 5/KF 5 only (was: Re: Some feedback on KDE6 install)

[Patrick Franz]

Hej,

Am Montag, 2. September 2024, 17:19:38 CEST schrieb Martin Steigerwald:
[...]
> Hmm, I have an idea:
> 
> kio-extras is still 4:23.08.4-2 and only contains Qt 5/KF 5 protocols.
> In there are all the protocols that Dolphin said were missing above
> and then some.
> 
> I think once someone has updated KIO related packages things will work
> again.

Just upload kio-extras 24.08.0 to experimental as well as an updated 
version of dolphin that will now recommend kio-extras 24.08 or higher. 

I hope that solves some of the problems.


-- 
Med vänliga hälsningar

Patrick Franz

Re: Dolphin 24.08 on Plasma 6: protocols in kio-extras Qt 5/KF 5 only (was: Re: Some feedback on KDE6 install)

[Eric Valette]

The other two work, but I do get

kf.kio.core: couldn't create worker: "Unknown protocol 'thumbnail'."

messages when I run Dolphin from console.



Hummm. Maybe this could also explin why we do not get thumbnails for 
wallpapers in systemsettings also.


kio-extras is still 4:23.08.4-2 and only contains Qt 5/KF 5 protocols. In 
there are all the protocols that Dolphin said were missing above and then 
some.


Wait and see then. Thanks for the hints.

Have a nice day,

--
Eric Valette

Dolphin 24.08 on Plasma 6: protocols in kio-extras Qt 5/KF 5 only (was: Re: Some feedback on KDE6 install)

[Martin Steigerwald]

Hi Eric.

Eric Valette - 02.09.24, 11:02:01 CEST:
> On my side I have
> 
> LANG=C.UTF-8 balooctl6 status
> Baloo File Indexer is running
> Indexer state: Idle
> Total files indexed: 60,390
> Files waiting for content indexing: 0
> Files failed to index: 0
> Current size of index is 35.46 MiB

Looks good.

Some baloo processes running/waiting in the background?

> BUT in dolphin I do have only partial correct information for recent
> elements:
> 
> Recent File is empty although I created one today
> Recent location is also empty
> Modified Today is correct (I modified the file I copied).
> Modified Yesterday is also correct.

I can confirm. "Recent File" and "Recent Location" do not even open here. 
Dolphin continues to display whatever it has shown before.

The other two work, but I do get

kf.kio.core: couldn't create worker: "Unknown protocol 'thumbnail'."

messages when I run Dolphin from console. But maybe that error message is 
related to above non working locations. In further testing it seems that 
Dolphin standard output is one message late… i.e. I test sftp and then 
fish, but get another sftp error message and only when I test fish again the 
fish one (see below).

> So the two "recent item" are still empty. (NB I translated menu items
> from french I hope translation is correct or at least you can guess the
> item menu).

It appears to me those are not even working at all.

But search via KRunner works just fine also in contents of files.

I have an suspicion, maybe some kio stuff is missing for that?

Cause fish:// and sftp:// protocols also do not work:

kf.kio.core: couldn't create worker: "Unknown protocol 'sftp'."
kf.kio.core: couldn't create worker: "Unknown protocol 'fish'."

FTP protocol however works okay, like with:

ftp://ftp.de.debian.org

Hmm, I have an idea:

kio-extras is still 4:23.08.4-2 and only contains Qt 5/KF 5 protocols. In 
there are all the protocols that Dolphin said were missing above and then 
some.

I think once someone has updated KIO related packages things will work 
again.

Best,
-- 
Martin - please no carbon copy to me

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

[Aurélien COUDERC]

Le dimanche 11 août 2024, 07:27:14 CEST Shmerl a écrit :
> Looks like these couple of bugs handle breakage in plasma-desktoptheme
> and kwin-data:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078140
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078436

Exact.

I’ve just uploaded the fix for both (libplasma 6.1.3-4, kwin 4:6.1.3-4) so once 
they’re built on experimental you may want to give the plasma 6 install another 
try…


Happy hacking,
--
Aurélien

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

[Shmerl]

Looks like these couple of bugs handle breakage in plasma-desktoptheme
and kwin-data:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078140
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078436

Regards,
Shmerl.

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

[Aurélien COUDERC]

Le 6 août 2024 09:32:55 GMT+02:00, Shmerl  a écrit :
>On Tue, 06 Aug 2024 08:46:11 +0200 Aurélien COUDERC 
>wrote:
>
>*> If you could also share your dpkg logs we should be able to see what
>happened.*
>
>I managed to track down some terminal output from dpkg that was stored
>in /var/log/apt/term.log
>
>These errors happened:
>
>Unpacking kwin-data (4:6.1.3-3) over (4:5.27.11-2) ...
>dpkg: error processing archive
>/tmp/apt-dpkg-install-0sB9EX/53-kwin-data_4%3a6.1.3-3_all.deb
>(--unpack):
> trying to overwrite
>'/usr/share/kwin/tabbox/thumbnail_grid/contents/ui/main.qml', which is
>also in package kwin-addons:amd64 4:5.27.11-1
>
> Unpacking plasma-desktoptheme (6.1.3-3) ...
>dpkg: error processing archive
>/tmp/apt-dpkg-install-0sB9EX/61-plasma-desktoptheme_6.1.3-3_amd64.deb
>(--unpack):
> trying to overwrite
>'/usr/share/plasma/desktoptheme/breeze-dark/colors', which is also in
>package plasma-framework 5.115.0-2

OK great that's the issue.

If you feel like opening a bug against kwin with severity:serious you may do 
so. Otherwise I'll do it later.

This needs to be fixed in the next upload.


Cheers,
--
Aurélien

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

[Aurélien COUDERC]

Le 6 août 2024 03:02:46 GMT+02:00, Shmerl  a écrit :
>On Mon, 05 Aug 2024 22:03:15 +0200 Aurélien COUDERC  wrote:
>
>> If you don't mind sharing the summary of the apt command (it will show some
>> of the packages you've chosen to install), alongside the output of apt 
>> policy I'd
>> still be interested to check that nothing looks amiss.
>
>I didn't save that run unfortunately, but here is what I managed to
>pull from apt log:
>https://pastebin.com/raw/44XrZA2m
>
>apt policy in that scenario looks like this:
>https://pastebin.com/raw/JUa0LYCc
>
>If you really need it, I can try re-running the experiment, but
>breakage was a bit tangled

No need thanks. It's already useful.

The first install section says it's a dpkg error and not a dependency issue, 
which should never happen if we made our packages correctly. 🙂

If you could also share your dpkg logs we should be able to see what happened. 
The most common issue is a missing Breaks/Replaces relation between new and old 
packages, which is required for upgrades to go well when a file moves from one 
package to another.


Thanks !
--
Aurélien

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

[Shmerl]

On Mon, 05 Aug 2024 22:03:15 +0200 Aurélien COUDERC  wrote:

> If you don't mind sharing the summary of the apt command (it will show some
> of the packages you've chosen to install), alongside the output of apt policy 
> I'd
> still be interested to check that nothing looks amiss.

I didn't save that run unfortunately, but here is what I managed to
pull from apt log:
https://pastebin.com/raw/44XrZA2m

apt policy in that scenario looks like this:
https://pastebin.com/raw/JUa0LYCc

If you really need it, I can try re-running the experiment, but
breakage was a bit tangled

to revert, I had to raise priority of testing in apt settings and do
some more manual steps
to get back.

Regards,

Shmerl.

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

[Aurélien COUDERC]

Le 5 août 2024 08:19:45 GMT+02:00, Shmerl  a écrit :
>Luc Castermans  wrote on Mon, 05 Aug 2024
>05:24:37 +
>
>*> I am happy to confirm above, using Plasma 6 since few weeks, with most
>packages from Experimental.*
>
>*>*
>*> Luc*
>
>I tried doing
>
>sudo apt install -t experimental plasma-desktop
>
>from testing (with unstable and experimental enabled) but that resulted in
>some breakage / conflicts that
>looked too tangled to resolve, so I reverted that for now.

If you don't mind sharing the summary of the apt command (it will show some of 
the packages you've chosen to install), alongside the output of apt policy I'd 
still be interested to check that nothing looks amiss.


Thanks !
--
Aurélien

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

[Luc Castermans]

Hi, indeed, moving over is not straightforward at this moment in time.
It is an effort. Aurélien wrote: "happy hacking", which is correct.

Luc


Shmerl  schreef op 5 augustus 2024 06:19:45 UTC:
>Luc Castermans  wrote on Mon, 05 Aug 2024
>05:24:37 +
>
>*> I am happy to confirm above, using Plasma 6 since few weeks, with most
>packages from Experimental.*
>
>*>*
>*> Luc*
>
>I tried doing
>
>sudo apt install -t experimental plasma-desktop
>
>from testing (with unstable and experimental enabled) but that resulted in
>some breakage / conflicts that
>looked too tangled to resolve, so I reverted that for now. I suppose
>testing is too different at this point to
>do it cleanly, so I'd wait until things will start migrating.
>
>Regards,
>Shmerl.

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

[Luc Castermans]

"Besides the cosmetic wallpaper preview issue, I don't think we've seen 
anything really scary so far."

I am happy to confirm above, using Plasma 6 since few weeks, with most packages 
from Experimental.


Luc



"Aurélien COUDERC"  schreef op 4 augustus 2024 21:52:38 UTC:
>
>
>Le 4 août 2024 19:28:04 GMT+02:00, Shmerl  a écrit 
>:
>>Sat, 03 Aug 2024 20:31:37 +0200Aurélien COUDERC  wrote:
>>
>>
>>*>> we've both had the issue Patrick and I while having every single
>>KF6 and Plasma 6 packages installed.*
>>
>>So is it close to being pushed to unstable
>
>We don't give ETAs, the team is a handful of volunteers, some already quite 
>overworked keeping up with this huge stack.
>
>I can give you the anticipated order for things to reach unstable which (until 
>it changes) would be : kf6 > qt6.7 > plasma 6.
>
>> or there are still a bunch
>>of issues left to iron out?
>
>Besides the cosmetic wallpaper preview issue, I don't think we've seen 
>anything really scary so far.
>
>
>Happy hacking,
>--
>Aurélien
>

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

[Aurélien COUDERC]

Le 4 août 2024 19:28:04 GMT+02:00, Shmerl  a écrit :
>Sat, 03 Aug 2024 20:31:37 +0200Aurélien COUDERC  wrote:
>
>
>*>> we've both had the issue Patrick and I while having every single
>KF6 and Plasma 6 packages installed.*
>
>So is it close to being pushed to unstable

We don't give ETAs, the team is a handful of volunteers, some already quite 
overworked keeping up with this huge stack.

I can give you the anticipated order for things to reach unstable which (until 
it changes) would be : kf6 > qt6.7 > plasma 6.

> or there are still a bunch
>of issues left to iron out?

Besides the cosmetic wallpaper preview issue, I don't think we've seen anything 
really scary so far.


Happy hacking,
--
Aurélien

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

[Aurélien COUDERC]

Hi Nicholas,

Le 4 août 2024 01:12:19 GMT+02:00, Nicholas D Steeves  a écrit 
:
>Hi Aurélien,
>

>
>What I understood was that whoever updated the source package believed
>that our new bin:plasma-integration logically provided
>plasma5-integration (whether or not it had formal Provides).  I found
>this reasonable and didn't question it.

Yes but no. The new binary is plasma5-integration. It was just an oversight.

>
>Of course :)  So in this case I wonder if it would save time to somehow
>search for all versioned-2-unversioned bin:packages, and then add
>Recommends for the old Qt5/KF5/Plasma5 variant, 

See above we're not in that case here. I'm not convinced we would save time 
with such a thing but if you want to explore that and share feedback, feel free.


> run autopkgtests 

That would be very useful if it did anything. But it requires someone 
(upstream, us) to write some tests that can run under autopkgtest.

autopkgtest [1] runs against the installed system, not from the build tree so 
you need something that tests the result of apt install $package, not of 
cmake+make.

KDE didn't have that, that I now, but they started building some end user tests 
using Selenium ~recently.

If $someone wants to look at KDE packages with selenium tests and can make them 
run as autokpgtests, I'd be very interested in merging such changes !


[1] https://manpages.debian.org/bookworm/autopkgtest/autopkgtest.1.en.html


Happy hacking,
--
Aurélien

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

[Nicholas D Steeves]

Hi Aurélien,

Aurélien COUDERC  writes:

> Hi,
>
> Le vendredi 2 août 2024, 05:22:39 CEST Nicholas D Steeves a écrit :
>> Shai Berger  writes:
>> 
>> > On Thu, 01 Aug 2024 17:17:17 +0200
>> > Aurélien COUDERC  wrote:
>> >
>> >> Le 1 août 2024 15:59:44 GMT+02:00, Alex Hermann
>> >>  a écrit :
>> >> >
>> >> >Yes, thanks. plasma5-integration was the missing bit.
>> >> >
>> >> >Maybe some packages need a depend/recommend on this package. As of
>> >> >now, it stands completely on its own.
>> >> >
>> >> >$ apt-cache rdepends plasma5-integration
>> >> >plasma5-integration
>> >> >Reverse Depends:  
>> >> 
>> >> Yes, good idea, will do.
>> >> 
>> >
>> > FWIW, in testing there's "plasma-integration" and it has rdepends:
>> >
>> > $ aptitude why plasma-integration
>> > i   task-kde-desktop   Depends kde-standard
>> > i A kde-standard   Depends kde-plasma-desktop (>= 5:148)   
>> > i A kde-plasma-desktop Depends plasma-desktop (>= 4:5.27.11)   
>> > i A plasma-desktop Depends plasma-integration (>= 5.27.11~)
>> 
>> Package: plasma-desktop
>> Version: 4:6.1.3-1 [experimental]
>> [snip]
>> Depends: [snip] plasma-integration (>= 6.1.0~)
>
> … which is fine, this package is the integration for Qt6 apps. 
> plasma5-integration is required for Qt5 apps in addition.

Aha!

>> The other end up transitively depending on it because of this.  I'm
>> guessing that the nature of this issue is that one should never
>> 'dist-upgrade'/'full-upgrade' when mixing experimental; however, in this
>> case I'm guessing that this was needed in order to install a new
>> package.
>> 
>> Aurélien, do you think upgrades could be smoother for users if
>> plasma-integration (and/or any other packages) had stronger breaks &
>> replaces, or will everything 'just work'?
>
> I don’t get what you mean by that. Yes, we must have a working upgrade path 
> and we make what we can to make it happen.
> When someone finds an issue like here with missing plasma5-integration or 
> previously with qml6-qtmql-workerscript we fix it.

What I understood was that whoever updated the source package believed
that our new bin:plasma-integration logically provided
plasma5-integration (whether or not it had formal Provides).  I found
this reasonable and didn't question it.

Otherwise I expect to see a bin:"plasma6-integration" package.  In other
words, it looks like a transition from versioned (ie
plasma5-integration) to unversioned (ie plasma-integration) binary
packages.

Usually such transitions must include versioned breaks and replaces.  In
this case it would be wrong to have versioned provides.

> We generally install all packages from the stack when packaging to ensure 
> that nothing breaks when upgrading. So we don’t catch the missing package 
> issues immediately.

Of course :)  So in this case I wonder if it would save time to somehow
search for all versioned-2-unversioned bin:packages, and then add
Recommends for the old Qt5/KF5/Plasma5 variant, run autopkgtests and
piuparts, and make a list of failures.  These failures indicate where
the 5-variant package no longer exists, and these are the cases that
require actual investigation.  The success list can probably just be
skimmed by someone who would recognise if it's a likely case where the
old 5-variant is still required for compatibility.

Regards,
Nicholas


signature.asc
Description: PGP signature

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

[Aurélien COUDERC]

Le 3 août 2024 20:22:50 GMT+02:00, Edward Shornock  a 
écrit :
>
>Sedat Dilek kirjoitti 22.7.2024 klo 11.49 ap.:
>> KDE/apps partly from experimental like konsole - akonadi/kmail etc.
>> still works but from unstable.
>> 
>> The upgrade was mostly done manually - some QT packages were required
>> from unstable.
>
>I have done the upgrade to Plasma from experimental and everything appears to 
>be working quite well, other than System Settings → Wallpaper doesn't show any 
>images for the various wallpaper choices. I guess I'm probably missing a 
>package, but which one I haven't figured out yet.

Good to hear.

I don't think it's a missing package issue, we've both had the issue Patrick 
and I while having every single KF6 and Plasma 6 packages installed.

So either it's some other package missing that's not from the KDE stack, some 
hidden missing build dependency, some version incompatibility with what we have 
in Debian, some other bug ?

If someone has it working with our packages and/or can figure out what's 
missing, feedback would be highly appreciated.


Happy hacking,
--
Aurélien

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

[Edward Shornock]

Sedat Dilek kirjoitti 22.7.2024 klo 11.49 ap.:

KDE/apps partly from experimental like konsole - akonadi/kmail etc.
still works but from unstable.

The upgrade was mostly done manually - some QT packages were required
from unstable.


I have done the upgrade to Plasma from experimental and everything 
appears to be working quite well, other than System Settings → Wallpaper 
doesn't show any images for the various wallpaper choices. I guess I'm 
probably missing a package, but which one I haven't figured out yet.

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

[Aurélien COUDERC]

Hi,

Le vendredi 2 août 2024, 05:22:39 CEST Nicholas D Steeves a écrit :
> Shai Berger  writes:
> 
> > On Thu, 01 Aug 2024 17:17:17 +0200
> > Aurélien COUDERC  wrote:
> >
> >> Le 1 août 2024 15:59:44 GMT+02:00, Alex Hermann
> >>  a écrit :
> >> >
> >> >Yes, thanks. plasma5-integration was the missing bit.
> >> >
> >> >Maybe some packages need a depend/recommend on this package. As of
> >> >now, it stands completely on its own.
> >> >
> >> >$ apt-cache rdepends plasma5-integration
> >> >plasma5-integration
> >> >Reverse Depends:  
> >> 
> >> Yes, good idea, will do.
> >> 
> >
> > FWIW, in testing there's "plasma-integration" and it has rdepends:
> >
> > $ aptitude why plasma-integration
> > i   task-kde-desktop   Depends kde-standard
> > i A kde-standard   Depends kde-plasma-desktop (>= 5:148)   
> > i A kde-plasma-desktop Depends plasma-desktop (>= 4:5.27.11)   
> > i A plasma-desktop Depends plasma-integration (>= 5.27.11~)
> 
> Package: plasma-desktop
> Version: 4:6.1.3-1 [experimental]
> [snip]
> Depends: [snip] plasma-integration (>= 6.1.0~)

… which is fine, this package is the integration for Qt6 apps. 
plasma5-integration is required for Qt5 apps in addition.

> The other end up transitively depending on it because of this.  I'm
> guessing that the nature of this issue is that one should never
> 'dist-upgrade'/'full-upgrade' when mixing experimental; however, in this
> case I'm guessing that this was needed in order to install a new
> package.
> 
> Aurélien, do you think upgrades could be smoother for users if
> plasma-integration (and/or any other packages) had stronger breaks &
> replaces, or will everything 'just work'?

I don’t get what you mean by that. Yes, we must have a working upgrade path and 
we make what we can to make it happen.
When someone finds an issue like here with missing plasma5-integration or 
previously with qml6-qtmql-workerscript we fix it.

We generally install all packages from the stack when packaging to ensure that 
nothing breaks when upgrading. So we don’t catch the missing package issues 
immediately.


Happy hacking,
--
Aurélien

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

[Nicholas D Steeves]

Shai Berger  writes:

> On Thu, 01 Aug 2024 17:17:17 +0200
> Aurélien COUDERC  wrote:
>
>> Le 1 août 2024 15:59:44 GMT+02:00, Alex Hermann
>>  a écrit :
>> >
>> >Yes, thanks. plasma5-integration was the missing bit.
>> >
>> >Maybe some packages need a depend/recommend on this package. As of
>> >now, it stands completely on its own.
>> >
>> >$ apt-cache rdepends plasma5-integration
>> >plasma5-integration
>> >Reverse Depends:  
>> 
>> Yes, good idea, will do.
>> 
>
> FWIW, in testing there's "plasma-integration" and it has rdepends:
>
> $ aptitude why plasma-integration
> i   task-kde-desktop   Depends kde-standard
> i A kde-standard   Depends kde-plasma-desktop (>= 5:148)   
> i A kde-plasma-desktop Depends plasma-desktop (>= 4:5.27.11)   
> i A plasma-desktop Depends plasma-integration (>= 5.27.11~)

Package: plasma-desktop
Version: 4:6.1.3-1 [experimental]
[snip]
Depends: [snip] plasma-integration (>= 6.1.0~)

The other end up transitively depending on it because of this.  I'm
guessing that the nature of this issue is that one should never
'dist-upgrade'/'full-upgrade' when mixing experimental; however, in this
case I'm guessing that this was needed in order to install a new
package.

Aurélien, do you think upgrades could be smoother for users if
plasma-integration (and/or any other packages) had stronger breaks &
replaces, or will everything 'just work'?

To be fair, the usual time to find and fix this sort of issue is when
packages have been uploaded to unstable ;)

Cheers,
Nicholas


signature.asc
Description: PGP signature

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

[Shai Berger]

On Thu, 01 Aug 2024 17:17:17 +0200
Aurélien COUDERC  wrote:

> Le 1 août 2024 15:59:44 GMT+02:00, Alex Hermann
>  a écrit :
> >
> >Yes, thanks. plasma5-integration was the missing bit.
> >
> >Maybe some packages need a depend/recommend on this package. As of
> >now, it stands completely on its own.
> >
> >$ apt-cache rdepends plasma5-integration
> >plasma5-integration
> >Reverse Depends:  
> 
> Yes, good idea, will do.
> 

FWIW, in testing there's "plasma-integration" and it has rdepends:

$ aptitude why plasma-integration
i   task-kde-desktop   Depends kde-standard
i A kde-standard   Depends kde-plasma-desktop (>= 5:148)   
i A kde-plasma-desktop Depends plasma-desktop (>= 4:5.27.11)   
i A plasma-desktop Depends plasma-integration (>= 5.27.11~)

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

[Aurélien COUDERC]

Le 1 août 2024 15:59:44 GMT+02:00, Alex Hermann  a écrit :
>On donderdag 1 augustus 2024 14:51:57 CEST Luigi Toscano wrote:

[…]

>> 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.
>
>Yes, thanks. plasma5-integration was the missing bit.
>
>Maybe some packages need a depend/recommend on this package. As of now, 
>it stands completely on its own.
>
>$ apt-cache rdepends plasma5-integration
>plasma5-integration
>Reverse Depends:

Yes, good idea, will do.


--
Aurélien

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

[Alex Hermann]

On donderdag 1 augustus 2024 14:51:57 CEST Luigi Toscano wrote:
> Alex Hermann ha scritto:
> > 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.

Yes, thanks. plasma5-integration was the missing bit.

Maybe some packages need a depend/recommend on this package. As of now, 
it stands completely on its own.

$ apt-cache rdepends plasma5-integration
plasma5-integration
Reverse Depends:

-- 
Alex Hermann

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: KDE/Frameworks/Plasma/Apps + QT from experimental

[Alex Hermann]

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?
-- 
Alex

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

[Luc Castermans]

got it!

Besturingssysteem: Debian GNU/Linux 12
KDE Plasma-versie: 6.1.0
Versie van KDE-Frameworks: 6.4.0
Qt-versie: 6.6.2
Kernel-versie: 6.9.9-amd64 (64-bits)
Grafisch platform: X11
Processors: 12 × AMD Ryzen 5 3600 6-Core Processor
Geheugen: 31,3 GiB RAM
Grafische processor: NVIDIA GeForce GT 1030/PCIe/SSE2
Fabrikant: BIOSTAR Group
Productnaam: A320MH


After having looked at a black desktop with only moving mouse, 
installing below from SID made it work :=)


+ii  libqt6qmlworkerscript6:amd64  6.6.2+dfsg-4
+ii  qml6-module-qtqml-workerscript:amd64  6.6.2+dfsg-4

*Thanks to all who made this happen :=)    !!!*



Op 22-07-2024 om 10:49 a.m. schreef Sedat Dilek:

Hi,

just as an info:

$ kinfo
Operating System: Debian GNU/Linux 12
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.4.0
Qt Version: 6.6.2
Kernel Version: 6.9.10-amd64 (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-2467M CPU @ 1.60GHz
Memory: 7.7 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 3000

The last and missing bits to install QML/workerscript (not done
automatically here - kinfocenter/systemsettings/plasma-desktop
crashing):

+ii  libqt6qmlworkerscript6:amd64  6.6.2+dfsg-4
+ii  qml6-module-qtqml-workerscript:amd64  6.6.2+dfsg-4

Then I was able to enjoy the new KDE plasma-desktop version 6.1.

KDE/apps partly from experimental like konsole - akonadi/kmail etc.
still works but from unstable.

The upgrade was mostly done manually - some QT packages were required
from unstable.

Thanks.

Best regards,
-Sedat-


--
m.vr.gr.

Luc Castermans
mailto:luc.casterm...@gmail.com

KDE/Frameworks/Plasma/Apps + QT from experimental

[Sedat Dilek]

Hi,

just as an info:

$ kinfo
Operating System: Debian GNU/Linux 12
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.4.0
Qt Version: 6.6.2
Kernel Version: 6.9.10-amd64 (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-2467M CPU @ 1.60GHz
Memory: 7.7 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 3000

The last and missing bits to install QML/workerscript (not done
automatically here - kinfocenter/systemsettings/plasma-desktop
crashing):

+ii  libqt6qmlworkerscript6:amd64  6.6.2+dfsg-4
+ii  qml6-module-qtqml-workerscript:amd64  6.6.2+dfsg-4

Then I was able to enjoy the new KDE plasma-desktop version 6.1.

KDE/apps partly from experimental like konsole - akonadi/kmail etc.
still works but from unstable.

The upgrade was mostly done manually - some QT packages were required
from unstable.

Thanks.

Best regards,
-Sedat-

Re: QT target version for trixie

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Wed, 3 Jul 2024 at 08:07, Martin Steigerwald  wrote:
>
> Cc'd the mailing list I mentioned below.
>
> Alexandre Rossi - 03.07.24, 12:29:06 CEST:
> > (Please CC me, I'm not subscribed)
> >
> > Wanting to fix #1073004, I was wondering what was the target version of
> > QT for trixie? Should an application build against QT5 or QT6?
> >
> > I have not been able to find that information.
>
> A question like this is better directed to the debian-qt-kde mailing list,
> where developers discuss things.
>
> AFAIK Trixie will ship at least 6.6.2 of Qt, which is currently in
> Unstable. Of course it could also be a later version given that it is
> still some time till release. Qt 6 is already needed for Plasma 6.
>
> I don't know whether Qt 5 will be available in Trixie. It would be
> preferable to build with Qt 6 as at some time Qt 5 will be removed anyway.

There is no chance to drop Qt 5 for Trixie. But you should target Qt 6
as most as possible.

Re: QT target version for trixie

[Martin Steigerwald]

Cc'd the mailing list I mentioned below.

Alexandre Rossi - 03.07.24, 12:29:06 CEST:
> (Please CC me, I'm not subscribed)
>
> Wanting to fix #1073004, I was wondering what was the target version of
> QT for trixie? Should an application build against QT5 or QT6?
> 
> I have not been able to find that information.

A question like this is better directed to the debian-qt-kde mailing list, 
where developers discuss things.

AFAIK Trixie will ship at least 6.6.2 of Qt, which is currently in 
Unstable. Of course it could also be a later version given that it is 
still some time till release. Qt 6 is already needed for Plasma 6.

I don't know whether Qt 5 will be available in Trixie. It would be 
preferable to build with Qt 6 as at some time Qt 5 will be removed anyway.

Best,
-- 
Martin

Re: QT target version for trixie

[Martin Steigerwald]

Alexandre Rossi - 03.07.24, 12:29:06 CEST:
> (Please CC me, I'm not subscribed)
> 
> Hi,
> 
> Wanting to fix #1073004, I was wondering what was the target version of
> QT for trixie? Should an application build against QT5 or QT6?
> 
> I have not been able to find that information.

A question like this is better directed to the debian-qt-kde mailing list, 
where developers discuss things.

AFAIK Trixie will ship at least 6.6.2 of Qt, which is currently in 
Unstable. Of course it could also be a later version given that it is 
still some time till release. Qt 6 is already needed for Plasma 6.

I don't know whether Qt 5 will be available in Trixie. It would be 
preferable to build with Qt 6 as at some time Qt 5 will be removed anyway.

Best,
-- 
Martin

QT target version for trixie

[Alexandre Rossi]

(Please CC me, I'm not subscribed)

Hi,

Wanting to fix #1073004, I was wondering what was the target version of QT
for trixie? Should an application build against QT5 or QT6?

I have not been able to find that information.

Thanks,

Alex

Re: Qt upgrade

[Sedat Dilek]

Hi,

Thanks for the pointer.

After a full-upgrade to latest packages in Debian/unstable AMD64,
kinfocenter says:

Operating System: Debian GNU/Linux 12
KDE Plasma Version: 5.27.11
KDE Frameworks Version: 5.115.0
Qt Version: 5.15.13
Kernel Version: 6.8.10-1-amd64-clang18-kcfi (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-2467M CPU @ 1.60GHz
Memory: 7.7 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 3000
Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
Product Name: 530U3BI/530U4BI/530U4BH
System Version: 0.1

Hope this helps other interested people.

Best regards,
-Sedat-

Re: Qt upgrade

[Martin Steigerwald]

Aurélien COUDERC - 23.05.24, 11:50:08 CEST:
> Le 23 mai 2024 10:09:29 GMT+02:00, Andrey Rakhmatullin  
> a écrit :
> >On Thu, May 23, 2024 at 09:44:10AM +0200, Martin Steigerwald wrote:
> >> The new apt 2.9 and later makes it really obvious, so maybe warnings
> >> like this are no longer needed?
> >
> >It was always obvious *shrug*
> 
> Must depend on your kind of eyes :-), I do find the new feedback of
> packages to be removed *much* more obvious.

Well, if you looked for it and I always recommend people I trained with 
Linux to look out for it, then sure it was obvious. But before with a long 
output it was needed to scroll up. And given feedback here on the list and 
elsewhere I came to the conclusion that not everyone did. It was not that 
we had been there on this list: It has been a while, but I still remember 
the "I messed up my system, please help!" kind of o posts.

I did not count how often I said to participants of my Linux courses: Read 
that error message. Read it aloud if need be! And it was always nice to 
watch the conclusion appear in their face as they recognized: yes, the 
error message told exactly what was going on and they just did not read it 
or not *all* of it. Granted: Not all of the time it does. There are bad 
cryptic error messages, still.

Now with new apt it is really in the face even for those who skipped 
scrolling up, probably even despite better recommendations.

> And BTW it's in apt version 2.9.3 onwards if I remember correctly. Older
> versions didn't have that.

Thanks for the correction.

I also appreciate the faster initialization of apt. It is still not quite 
as fast as the apk package manager in Alpine Linux and derivatives and it 
may never be, but it at least initializes quite a bit faster than before 
and I have the impression even installation of packages might be a bit 
faster than before, but I am not sure on the latter. Difficult to say from 
subjective impression.

Really well done by apt developers. Kudos to them!

Best,
-- 
Martin

Re: Qt upgrade

[Aurélien COUDERC]

Le 23 mai 2024 10:09:29 GMT+02:00, Andrey Rakhmatullin  a 
écrit :
>On Thu, May 23, 2024 at 09:44:10AM +0200, Martin Steigerwald wrote:
>> The new apt 2.9 and later makes it really obvious, so maybe warnings like 
>> this are no longer needed? 
>It was always obvious *shrug*

Must depend on your kind of eyes :-), I do find the new feedback of packages to 
be removed *much* more obvious.

And BTW it's in apt version 2.9.3 onwards if I remember correctly. Older 
versions didn't have that.


Happy hacking,
--
Aurélien

Re: Qt upgrade

[Andrey Rakhmatullin]

On Thu, May 23, 2024 at 09:44:10AM +0200, Martin Steigerwald wrote:
> The new apt 2.9 and later makes it really obvious, so maybe warnings like 
> this are no longer needed? 
It was always obvious *shrug*

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Qt upgrade

[Martin Steigerwald]

Hi!

Unstable users already saw it, I bet:

There is a Qt upgrade ongoing.

As usual watch output of apt carefully and wait with full-upgrade until Qt 
related package building is complete.

The new apt 2.9 and later makes it really obvious, so maybe warnings like 
this are no longer needed? I mean "REMOVING:" at the end with all the 
package names in red. Kinda obvious, if you ask me.

Best,
-- 
Martin

Re: Package Qt WebEngine dictionaries

[Soren Stoutner]

I agree that it would be a good idea to discuss this in a central location 
where the 
largest number of hunspell maintainers are likely to see the discussion and a 
general consensus can be reached.  As I don’t see a mailing list for either 
Hunspell 
or for dictionaries in general, I have filed a bug report against dictionaries-
common.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387[1]

-- 
Soren Stoutner
623-262-6169
so...@stoutner.com


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387

Re: Package Qt WebEngine dictionaries

[Rene Engelhard]

@Agustin: context: 
https://lists.debian.org/debian-kde/2022/09/msg00011.html ff.


Hi again,

Am 20.09.22 um 20:02 schrieb Rene Engelhard:

Hi,

Am 20.09.22 um 18:38 schrieb Soren Stoutner:


I did speak to the maintainer of the English hunspell packages (Don 
Armstrong), which are based on the scowl source package.


But not with the maintainer of the hunspell engine itself. Who wrote 
the hunspell parts of


/usr/share/doc/dictionaries-common-dev/dsdt-policy.txt.gz

Neither with the dictionaries-common maintainers where this policy is 
in/from.



We could (and should) document stuff there anyway if we agreed on something.

Though I am actually not amused though that the people who care about 
hunspell dicts in Debian and wrote the policy weren't even asked (and 
this thread "hidden" in a KDE-centric _user list_, which -kde _is_)


Regards,


Rene

Re: Package Qt WebEngine dictionaries

[Rene Engelhard]

Hi,

Am 20.09.22 um 18:38 schrieb Soren Stoutner:


I did speak to the maintainer of the English hunspell packages (Don 
Armstrong), which are based on the scowl source package.


But not with the maintainer of the hunspell engine itself. Who wrote the 
hunspell parts of


/usr/share/doc/dictionaries-common-dev/dsdt-policy.txt.gz

Neither with the dictionaries-common maintainers where this policy is 
in/from.



I don’t have a strong preference either way.

I do, personally. Please keep it out of hunspell-*.
I also don’t know if the maintainers of the various hunspell packages 
in different languages do much coordination with each other.

There's no big coordination here, but they follow above policy.


This is his patch that enables the building of the Qt WebEngine binary 
dictionaries:



https://git.donarmstrong.com/?p=deb_pkgs/scowl.git;a=commitdiff;h=4510f7fed66204384fe8c39fc875e24fd874229b


You linked that already.


Note that you didn't answer my questions here either.

Regards,


Rene

Re: Package Qt WebEngine dictionaries

[Soren Stoutner]

On Tuesday, September 20, 2022 8:56:00 AM MST Rene Engelhard wrote:
> I'd argue for a separate package since this .bdic is QtWebengine
> specific isn't it? Nothing else uses it.
> 
> Whereas the hunspell dicts as-is are used by various applications.
> 
> > and if the proposed file locations and symlinks are the best way to
> > handle the installation
> 
> As the person who wrote the initial hunspell policy I don't like those
> .bdic files in /usr/share/hunspell.
> 
>  > My plan was to wait and see how things landed with the English
> 
> package and then reach out to the maintainers of the other Hunspell
> languages and offer assistance to add the Qt WebEngine dictionaries to
> their packages as well.
> 
> 
> One could have also talked to the hunspell maintainer

I did speak to the maintainer of the English hunspell packages (Don Armstrong), 
which are 
based on the scowl source package.  I originally felt that it would be better 
for these to be 
separate binary packages for the same reasons you have stated.  He was the one 
who felt, 
because of their small size, it would be better for these to be packaged in the 
existing 
binaries.

You can read that discussion here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017646[1]

I don’t have a strong preference either way.  I also don’t know if the 
maintainers of the 
various hunspell packages in different languages do much coordination with each 
other.

This is his patch that enables the building of the Qt WebEngine binary 
dictionaries:

https://git.donarmstrong.com/?p=deb_pkgs/
scowl.git;a=commitdiff;h=4510f7fed66204384fe8c39fc875e24fd874229b[2]

Soren

-- 
Soren Stoutner
623-262-6169
so...@stoutner.com


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017646
[2] https://git.donarmstrong.com/?p=deb_pkgs/
scowl.git;a=commitdiff;h=4510f7fed66204384fe8c39fc875e24fd874229b


signature.asc
Description: This is a digitally signed message part.

Re: Package Qt WebEngine dictionaries

[Rene Engelhard]

Hi,

Am 18.09.22 um 00:32 schrieb Soren Stoutner:
I noticed that Debian does not currently ship packages for Qt 
WebEngine dictionaries.  Qt WebEngine can use Hunspell dictionaries 
compiled into a special binary format using qwebengine_convert_dict 
from the qtwebengine5-dev-tools package.


https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker


The binary packages should be placed (currently) in the 
/usr/share/qt5/qtwebengine_dictionaries directory, although I would 
assume that it would make sense to create a symlink from 
/usr/share/qt6/qtwebengine_dictionaries, and I would assume that when 
qt6 becomes the default the binary files should move there.




Can't they be built at runtime by a trigger like PostgreSQL does?

I created a feature request to work with the maintainer of the English 
Hunspell dictionary package (src: scowl) and it seems like the best 
way to handle this would be to use the existing source to create these 
binary files

yup

, either in the existing binary package or in a separate package.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017646


I'd argue for a separate package since this .bdic is QtWebengine 
specific isn't it? Nothing else uses it.


Whereas the hunspell dicts as-is are used by various applications.

My questions for the Debian KDE community is if there is a preference 
for the naming convention of a possible new binary package



no comment for this :)


and if the proposed file locations and symlinks are the best way to 
handle the installation


As the person who wrote the initial hunspell policy I don't like those 
.bdic files in /usr/share/hunspell.


> My plan was to wait and see how things landed with the English 
package and then reach out to the maintainers of the other Hunspell 
languages and offer assistance to add the Qt WebEngine dictionaries to 
their packages as well.



One could have also talked to the hunspell maintainer


Regards,


Rene

Package Qt WebEngine dictionaries

[Soren Stoutner]

I am developing a Qt WebEngine based web browser named Privacy Browser.

https://www.stoutner.com/privacy-browser-pc/[1]

Currently it is in pre-alpha, but it will soon reach an alpha release stage, at 
which point I 
would like to package it for Debian.  I noticed that Debian does not currently 
ship packages 
for Qt WebEngine dictionaries.  Qt WebEngine can use Hunspell dictionaries 
compiled into 
a special binary format using qwebengine_convert_dict from the 
qtwebengine5-dev-tools 
package.
 
https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker[2]

The binary packages should be placed (currently) in the /usr/share/qt5/
qtwebengine_dictionaries directory, although I would assume that it would make 
sense to 
create a symlink from /usr/share/qt6/qtwebengine_dictionaries, and I would 
assume that 
when qt6 becomes the default the binary files should move there.

Once the binary dictionary files are in Debian any program that uses Qt 
WebEngine can 
take advantage of them (they do have to enable spell checking in their source 
code and 
select the desired language).

I created a feature request to work with the maintainer of the English Hunspell 
dictionary 
package (src: scowl) and it seems like the best way to handle this would be to 
use the 
existing source to create these binary files, either in the existing binary 
package or in a 
separate package.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017646[3]

My questions for the Debian KDE community is if there is a preference for the 
naming 
convention of a possible new binary package and if the proposed file locations 
and 
symlinks are the best way to handle the installation.

My plan was to wait and see how things landed with the English package and then 
reach 
out to the maintainers of the other Hunspell languages and offer assistance to 
add the Qt 
WebEngine dictionaries to their packages as well.

Soren

-- 
Soren Stoutner
623-262-6169
so...@stoutner.com 


[1] https://www.stoutner.com/privacy-browser-pc/
[2] https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017646


signature.asc
Description: This is a digitally signed message part.

Qt WebEngine subpixel antialiasing regression?

[Brendon Higgins]

Hi all,

I'm wondering if anyone else is experiencing this: Qt WebEngine text content 
is not getting subpixel antialiasing, even though subpixel antialiasing works 
correctly most other places (including other Qt/KDE widgets). For me I notice 
the problem particularly affects Falkon and KMail in the message pane: in those 
places, all text is antialiased greyscale and not subpixel RGB.

This old QT bug report is related and shows what I mean:
https://bugreports.qt.io/browse/QTBUG-62146
In fact, the test case attached to that report also fails for me - I get 
output like "Qt5.8.0.PNG".

It looks like that regression was once fixed and has now regressed again! 
Unless something's just weird on my install... I'm running Debian Testing with 
Qt 5.15.2 packages installed.

Best,
Brendon

Re: Plasma 5.19.5 and Qt 5.15 in unstable

[Luc Castermans]

great news.

Thanks for all efforts to all involved!

Luc

Op za 7 nov. 2020 10:04 schreef Martin Steigerwald :

> Hi!
>
> Qt 5.15 is completely in unstable now and already also migrated to
> testing. kdevelop had to be uninstalled on my system, but I bet a fix
> will be coming soon enough as well.
>
> Now Plasma 5.19.5 is also coming.
>
> As always just wait till apt dist-upgrade is safe to do. If you
> previously used experimental packages, the updates should be seamless,
> but if you still use 5.17, better wait till everything is complete.
>
> I already have Qt 5.15 and Plasma 5.19.5 experimental packages installed
> and they are working just fine. There was an issue with window rules
> editing pane in System Settings not displaying, but this was just a
> missing dependency that should be fixed with the next upload. To fix
> manually install:
>
> qml-module-org-kde-kitemmodels
>
> Thanks to the effort of the Qt/KDE team the Qt/Plasma/KDE Applications
> stuff is quite up to date in Debian by now!
>
> Thanks to everyone involved. This has been quite a large feat to
> complete. Thank you also very much for the nice cooperation I am seeing
> these days! It really shows that together it is easier to achieve all of
> this.
>
> You can help, too: In case you experience bugs it is good to first check
> whether you have all packages updated. At least to some extent packages
> should be updated in lock step due to versioned dependencies, but this
> is challenging to get completely right. If unsure ask here first before
> you report a bug report that is just due to some version mix that will
> not appear this way in next Debian stable. Also in case a bug is clearly
> an upstream bug, you can help by also reporting it upstream and provide
> a link to the Debian bug report.
>
> Many thanks!
>
> Best,
> --
> Martin
>
>
>

Plasma 5.19.5 and Qt 5.15 in unstable

[Martin Steigerwald]

Hi!

Qt 5.15 is completely in unstable now and already also migrated to 
testing. kdevelop had to be uninstalled on my system, but I bet a fix 
will be coming soon enough as well.

Now Plasma 5.19.5 is also coming.

As always just wait till apt dist-upgrade is safe to do. If you 
previously used experimental packages, the updates should be seamless, 
but if you still use 5.17, better wait till everything is complete.

I already have Qt 5.15 and Plasma 5.19.5 experimental packages installed 
and they are working just fine. There was an issue with window rules 
editing pane in System Settings not displaying, but this was just a 
missing dependency that should be fixed with the next upload. To fix 
manually install:

qml-module-org-kde-kitemmodels

Thanks to the effort of the Qt/KDE team the Qt/Plasma/KDE Applications 
stuff is quite up to date in Debian by now!

Thanks to everyone involved. This has been quite a large feat to 
complete. Thank you also very much for the nice cooperation I am seeing 
these days! It really shows that together it is easier to achieve all of 
this.

You can help, too: In case you experience bugs it is good to first check 
whether you have all packages updated. At least to some extent packages 
should be updated in lock step due to versioned dependencies, but this 
is challenging to get completely right. If unsure ask here first before 
you report a bug report that is just due to some version mix that will 
not appear this way in next Debian stable. Also in case a bug is clearly 
an upstream bug, you can help by also reporting it upstream and provide 
a link to the Debian bug report.

Many thanks!

Best,
-- 
Martin

Re: Plasma packages from experimental and Qt 5.15.1 transition

[Sandro Knauß]

Hey,

> As I was impatient, I rebuilt a few packages from the sources previously in
> experimental.
> I had to do one change for kwin-common to depend on the binary version
> instead of the source version. I do not yet have an account in the Debian
> Salsa server. Should I proceed and submit a merge request ?

Merge requests are always welcome. Feel free to to create a account and help 
packaging KDE packages.

hefee

signature.asc
Description: This is a digitally signed message part.

Re: Plasma packages from experimental and Qt 5.15.1 transition

[Matthieu Gallien]

Hello Norbert,

On lundi 2 novembre 2020 03:45:50 CET Norbert Preining wrote:
> Hi Matthieu,
> 
> > rebuilt but I would like to know if it is planned to have experimental
> > packages rebuilt against Qt 5.15.1 ?
> 
> We just uploaded a set of packages to experimental that should than be
> rebuilt with Qt 5.15.

Thanks they are working nicely.

As I was impatient, I rebuilt a few packages from the sources previously in 
experimental.
I had to do one change for kwin-common to depend on the binary version instead 
of the source version. I do not yet have an account in the Debian Salsa 
server. Should I proceed and submit a merge request ?

> Best
> 
> Norbert
> 
> --
> PREINING Norbert  https://www.preining.info
> Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Best regards

--
Matthieu

Re: Plasma packages from experimental and Qt 5.15.1 transition

[Eric Valette]

Hi Matthieu, > rebuilt but I would like to know if it is planned to have 
experimental > packages rebuilt against Qt 5.15.1 ? We just uploaded a set of 
packages to experimental that should than be rebuilt with Qt 5.15. 


I'm currentlu suing them sucessfully. Finding a part to upgrade without 
deleting packages is a bit complicated but for my setup the following command 
did the initial trick:

apt-get -t experimental install libqt5webenginecore5
then upgrade from unstable and then manullay from experimental...

-- 
Eric Valette

Re: Plasma packages from experimental and Qt 5.15.1 transition

[Norbert Preining]

Hi Matthieu,

> rebuilt but I would like to know if it is planned to have experimental 
> packages rebuilt against Qt 5.15.1 ?

We just uploaded a set of packages to experimental that should than be
rebuilt with Qt 5.15.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Plasma packages from experimental and Qt 5.15.1 transition

[Matthieu Gallien]

Hello,

so far, it seems that almost all packages involved in the transition have been 
rebuilt but I would like to know if it is planned to have experimental 
packages rebuilt against Qt 5.15.1 ?

This is my problem and not your problem but I would be curious to know what I 
will have to do on my development system.

Thanks for your work for the Debian users

Best regards

--
Matthieu

Re: Stepping down as Qt 6 maintainers

[Borden Rhodes]

On Tue, 18 Aug 2020 at 11:11, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> I was asked if this move has anything to do with code quality or
> licensing. The answer is a huge no, Qt is a **great** project which we
> love. As stated before it's mostly about lack of free time to properly
> maintain it.
>
> --
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
>

I'm very grateful for all the work that you've put into this project.
I've had my share of problems with KDE and I appreciate your efforts
to try to fix them.

It's too bad that the KDE project will probably lose another couple
dozen packages in the Qt6 upgrade - many of which I use - if precedent
is any guide. Someone really needs to tackle the economic problems of
open source one of these days.

Re: Stepping down as Qt 6 maintainers

[Lisandro Damián Nicanor Pérez Meyer]

I was asked if this move has anything to do with code quality or
licensing. The answer is a huge no, Qt is a **great** project which we
love. As stated before it's mostly about lack of free time to properly
maintain it.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Stepping down as Qt 6 maintainers

[Lisandro Damián Nicanor Pérez Meyer]

After quite some time maintaining Qt in Debian both Dmitry Shachnev
and I decided to not maintain Qt 6 when it's published (expected in
December 2020, see https://wiki.qt.io/Qt_6.0_Release). We will do our
best to keep the Qt 5 codebase up and running.

We **love** Qt, but it's a huge codebase and requires time and build
power, both things that we are currently lacking, so we decided it's
time for us to step down and pass the torch. And a new major version
seems the right point to do that.

We will be happy to review and/or sponsor other people's work or even
occasionally do uploads, but we can't promise to do it regularly.

Some things we think potential Qt 6 maintainers should be familiar
with are, of course, C++ packaging (specially symbols files) and
CMake, as Qt 6 will be built with it.

We also encourage prospective maintainers to remove the source's
-everywhere-src suffixes and just keep the base names as source
package names: qtbase6, qtdeclarative6, etc.

It has been an interesting ride all these years, we really hope you
enjoyed using Qt.

Thanks for everything,

  Dmitry and Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Status of Qt 6 (was: Re: Status of Plasma 5.18/5.19?)

[Martin Steigerwald]

Dear Marco,

Marco Möller - 07.07.20, 19:28:52 CEST:
> Looking also at the signature of your mail, I assume that you might
> have some insights also on the general situation. I am wondering
> about Qt itself moving to version 6 and having announced to change
> the license conditions by which KDE have used Qt in the past but
> appears to not be able to continue to use it in the future. Looking
> forward to reading good news, would you know about how KDE.org is
> planning to deal with this, is there a plan already?

I suggest bringing this up in a different thread and not hijack this one 
for upstream related things.

Best,
-- 
Martin

Re: Qt 5.14.2 coming to unstable

[Sedat Dilek]

Hi Martin,

thanks for the friendly pre-info.

This Friday June 26th I switched over to Qt 5.14.2 in Debian/testing AMD64.

Operating System: Debian GNU/Linux
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.70.0
Qt Version: 5.14.2
Kernel Version: 5.7.0-1-amd64
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-2467M CPU @ 1.60GHz
Memory: 7,7 GiB

Thanks.

Regards,
- Sedat -

Qt 5.14.2 coming to unstable

[Martin Steigerwald]

Hi!

As usual wait with dist-upgrade till complete.

Thanks to everyone involved with making that happen!

Best,
-- 
Martin

Bug for Qt Quick Controls2 with some styles

[gianluca]

Hello,

Machine: Debian Buster 10 x86_64

Emulated Architecture: armhf using QEMU (qemu-user-static) and a Debian 
Buster chrooted jailroot.


Running a QML based application on qemu-user-static way and Xorg running 
on a x86_64 host gives me some strange issues.
The xorg server is running on x86_64 host, and Qt executable is running 
inside a chrooted rootfilesystem and it is using X syscalls to display 
its gui.


On the x86_64 side, I have to use "xhost +" to accept connection from 
the chrooted system.


When running my application which uses QtQuickControl2 with the 
style=Material most of the interface is scrambled or does not work at 
all. If using other style like Fusion it works, but it is rendered 
differently.


My application is running fine within Debian x86_64 environment but no 
on the QEMU Side.


This can be easly checked if using the Qt Quick Example Gallery (in the 
example module: qtquickcontrols2-5-examples Debian package).


If compiled & ran inside a QEMU chrooted system, it gives me the exact 
issue I am facing of in my application.


Now I am trying to run in in a complete-system instead of running on the 
host CPU only (qemu-system-arm). At the moment I am downloading and 
installing Debian Buster 10 on my virtual disk image.

As soon as possible I will post the results.

Anyway if I am running it into a x86_64 machine it gives me the expected 
behaviour, so I suppose something ARM related into the way how 
qtquickcontrols2 and Qt for ARM is compiled...


Is this a well known bug? Can be workarounded to make it works on ARM 
platform?


Regards,
Gianluca Renzi
---
Eurek s.r.l.  |
Electronic Engineering| http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

Re: Issues with a Qt project and modules

[gianluca]

On 6/8/20 12:59 PM, Pino Toscano wrote:

In data lunedì 8 giugno 2020 12:13:17 CEST, gianluca ha scritto:

On 6/6/20 8:31 PM, Pino Toscano wrote:

Hi,

please use debian-kde@ as support list. debian-qt-kde@ is the packaging
list that gets the bug reports and the uploads/migrations only.



Thanks for clarification. I will do this as right now! ;-)


In data venerdì 5 giugno 2020 10:45:38 CEST, gianluca ha scritto:

Hello list,
I am trying to port a Qt project a friend of mine is developing in his
PC to my Debian Buster based ARM32bit Board (it is iMX6QuadPlus with 2GB
DDR3 SDRAM and 8Gb eMMC Storage with a 1024x600 lvds display).



Now the .pro has the following declarations:


QT += quick core gui widgets charts
QT += qml quick sql
QT += svg
CONFIG += c++11
QTPLUGIN += qtvirtualkeyboardplugin

In case the project actually uses the Qt virtualkeyboard library, your
change will make qmake happy as you said, but then still won't make the
project building.



and qmake and Makefile compiles everything (qml, cpp,...) happily.
And it works too!!

Thanks!
--
Eurek s.r.l.  |
Electronic Engineering| http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

Re: Issues with a Qt project and modules

[Pino Toscano]

In data lunedì 8 giugno 2020 12:13:17 CEST, gianluca ha scritto:
> On 6/6/20 8:31 PM, Pino Toscano wrote:
> > Hi,
> > 
> > please use debian-kde@ as support list. debian-qt-kde@ is the packaging
> > list that gets the bug reports and the uploads/migrations only.
> > 
> > In data venerdì 5 giugno 2020 10:45:38 CEST, gianluca ha scritto:
> >> Hello list,
> >> I am trying to port a Qt project a friend of mine is developing in his
> >> PC to my Debian Buster based ARM32bit Board (it is iMX6QuadPlus with 2GB
> >> DDR3 SDRAM and 8Gb eMMC Storage with a 1024x600 lvds display).
> >>
> >> His project is based on Qt 5.12.3 downloaded from Qt website (looking at
> >> .pro):
> >>
> >> QT += quick virtualkeyboard core gui widgets charts
> >> QT += qml quick sql
> >> CONFIG += c++11
> >>
> >> But when I am trying to run qmake on my PC to create the Makefile, it
> >> gives me these errors:
> >>
> >> Project ERROR: Unknown module(s) in QT: virtualkeyboard charts
> >>
> >> I have installed all qml modules and everything is related to charts and
> >> virtualkeyboard, but qmake refuses to build the Makefile.
> >>
> >> How I can proceed further?
> > 
> > "QT" represets Qt libraries, so it requires the virtualkeyboard and
> > charts libraries; you can get them by installing their -dev packages,
> > i.e. resp. libqt5virtualkeyboard5-dev and libqt5charts5-dev.
> > 
> Thank you for your advice, it was very helpful. I was missing the 
> libqt5charts-dev.
> 
> No way to go for the libqt5virtualkeyboard5-dev for Debian Buster. It is 
> not exists.

That's correct, the virtualkeyboard module provides a shared library
(and development files for it) starting from version 5.12. The whole
Qt stack in Buster is 5.11.

> I changed the .pro from:
> 
> QT += ... virtualkeyboard ...
> 
> to
> 
> QTPLUGINS += qtvirtualkeyboardplugin
> 
> and the qmake and Makefile were happy!

I don't think that's the same thing:
- "QT += virtualkeyboard" means that qmake will require the
  virtualkeyboard Qt library, using its headers when building and
  linking to it
- "QTPLUGINS += qtvirtualkeyboardplugin" means that qmake will require
  the qtvirtualkeyboardplugin Qt plugin, which will be statically
  linked in your application

In case the project actually uses the Qt virtualkeyboard library, your
change will make qmake happy as you said, but then still won't make the
project building.

-- 
Pino Toscano

signature.asc
Description: This is a digitally signed message part.

Re: Issues with a Qt project and modules

[gianluca]

On 6/6/20 8:31 PM, Pino Toscano wrote:

Hi,

please use debian-kde@ as support list. debian-qt-kde@ is the packaging
list that gets the bug reports and the uploads/migrations only.

In data venerdì 5 giugno 2020 10:45:38 CEST, gianluca ha scritto:

Hello list,
I am trying to port a Qt project a friend of mine is developing in his
PC to my Debian Buster based ARM32bit Board (it is iMX6QuadPlus with 2GB
DDR3 SDRAM and 8Gb eMMC Storage with a 1024x600 lvds display).

His project is based on Qt 5.12.3 downloaded from Qt website (looking at
.pro):

QT += quick virtualkeyboard core gui widgets charts
QT += qml quick sql
CONFIG += c++11

But when I am trying to run qmake on my PC to create the Makefile, it
gives me these errors:

Project ERROR: Unknown module(s) in QT: virtualkeyboard charts

I have installed all qml modules and everything is related to charts and
virtualkeyboard, but qmake refuses to build the Makefile.

How I can proceed further?


"QT" represets Qt libraries, so it requires the virtualkeyboard and
charts libraries; you can get them by installing their -dev packages,
i.e. resp. libqt5virtualkeyboard5-dev and libqt5charts5-dev.

Thank you for your advice, it was very helpful. I was missing the 
libqt5charts-dev.


No way to go for the libqt5virtualkeyboard5-dev for Debian Buster. It is 
not exists.


I changed the .pro from:

QT += ... virtualkeyboard ...

to

QTPLUGINS += qtvirtualkeyboardplugin

and the qmake and Makefile were happy!


Regards,
--
Eurek s.r.l.  |
Electronic Engineering| http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy  | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377  | Fax:   +39-(0)542-609212

Re: Issues with a Qt project and modules

[Pino Toscano]

Hi,

please use debian-kde@ as support list. debian-qt-kde@ is the packaging
list that gets the bug reports and the uploads/migrations only.

In data venerdì 5 giugno 2020 10:45:38 CEST, gianluca ha scritto:
> Hello list,
> I am trying to port a Qt project a friend of mine is developing in his 
> PC to my Debian Buster based ARM32bit Board (it is iMX6QuadPlus with 2GB 
> DDR3 SDRAM and 8Gb eMMC Storage with a 1024x600 lvds display).
> 
> His project is based on Qt 5.12.3 downloaded from Qt website (looking at 
> .pro):
> 
> QT += quick virtualkeyboard core gui widgets charts
> QT += qml quick sql
> CONFIG += c++11
> 
> But when I am trying to run qmake on my PC to create the Makefile, it 
> gives me these errors:
> 
> Project ERROR: Unknown module(s) in QT: virtualkeyboard charts
> 
> I have installed all qml modules and everything is related to charts and 
> virtualkeyboard, but qmake refuses to build the Makefile.
> 
> How I can proceed further?

"QT" represets Qt libraries, so it requires the virtualkeyboard and
charts libraries; you can get them by installing their -dev packages,
i.e. resp. libqt5virtualkeyboard5-dev and libqt5charts5-dev.

-- 
Pino Toscano

signature.asc
Description: This is a digitally signed message part.

Backported feature in Qt Creator: autodetection of compilers masked by ccache

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

Some time ago I requested a new feature to allow the autodetection of
ccache-masked compilers:



This got implemented and I backported the change to 4.11.0-2. If
anyone uses ccache please give it a try.

Thanks!

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Re: Qt 4 removed from Debian bullseye (current testing)

[Martin Steigerwald]

Hi Lisandro!

Lisandro Damián Nicanor Pérez Meyer - 09.01.20, 23:32:01 CET:
> Today Qt 4 (aka src:qt4-x11) has been removed from Debian bullseye,
> what as of today we know as "testing". We plan to remove it from
> unstable pretty soon.

Congratulations to everyone involved for this major achievement!

Best,
-- 
Martin

Qt 4 removed from Debian bullseye (current testing)

[Lisandro Damián Nicanor Pérez Meyer]

Today Qt 4 (aka src:qt4-x11) has been removed from Debian bullseye,
what as of today we know as "testing". We plan to remove it from
unstable pretty soon.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Re: Cross-build Qt Debian package

[Helmut Grohne]

Hi,

On Wed, Jan 08, 2020 at 11:53:28PM +, Paul Wise wrote:
> On Wed, Jan 8, 2020 at 12:21 PM Lisandro Damián Nicanor Pérez Meyer wrote:
> > On Wed, 8 Jan 2020 at 06:51, Carsten Behling wrote:
> > >
> > > I get the following error while trying to rebuild  
> > > 'qtbase-opensource-src_5.7.1+dfsg-3+deb9u1' for Debian Stretch armhf in a 
> > > pbuilder environment:
> >
> > qtbase can't be cross built "as is" in Stretch, and possibly not in
> > Bullseye either. That will most surely change with Qt 6.
> 
> CrossQA indicates that isn't possible in bullseye either, looks like
> it uses the compiles for the build arch instead of the host arch, so
> it finds the wrong libraries and doesn't find some headers for the
> host arch.
> 
> http://crossqa.debian.net/src/qtbase-opensource-src

Please move the discussion to #876131.

Note that the postgresql part got improved since the filing of the bug.
It might just work now.

Helmut

Re: Cross-build Qt Debian package

[Paul Wise]

On Wed, Jan 8, 2020 at 12:21 PM Lisandro Damián Nicanor Pérez Meyer wrote:
> On Wed, 8 Jan 2020 at 06:51, Carsten Behling wrote:
> >
> > I get the following error while trying to rebuild  
> > 'qtbase-opensource-src_5.7.1+dfsg-3+deb9u1' for Debian Stretch armhf in a 
> > pbuilder environment:
>
> qtbase can't be cross built "as is" in Stretch, and possibly not in
> Bullseye either. That will most surely change with Qt 6.

CrossQA indicates that isn't possible in bullseye either, looks like
it uses the compiles for the build arch instead of the host arch, so
it finds the wrong libraries and doesn't find some headers for the
host arch.

http://crossqa.debian.net/src/qtbase-opensource-src

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Cross-build Qt Debian package

[Lisandro Damián Nicanor Pérez Meyer]

Hi Carsten!

On Wed, 8 Jan 2020 at 06:51, Carsten Behling
 wrote:
>
> Hi,
>
> I get the following error while trying to rebuild  
> 'qtbase-opensource-src_5.7.1+dfsg-3+deb9u1' for Debian Stretch armhf in a 
> pbuilder environment:

qtbase can't be cross built "as is" in Stretch, and possibly not in
Bullseye either. That will most surely change with Qt 6.

What you can do is cross build packages *depending* on Qt.[snip]

> Further, obviously there are already build armhf packages from 
> 'qtbase-opensource-src'. How were those packages build from the sources?

On a real armhf machine.

If you want more info please feel free to keep debian-kde on CC (already added).

Cheers, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Re: Transition of Qt to 5.12.5

[luca.pedrielli]

Downloaded latest plasma-workspace 4:5.14.5.1-4 and it works.

Thanks!!


Il 24/10/19 07:32, Matthieu Gallien ha scritto:

On Wednesday, October 23, 2019 9:05:11 PM CEST Lisandro Damián Nicanor Pérez
Meyer wrote:

Hi!

Hello


El mié., 23 oct. 2019 16:01, luca.pedrielli  escribió:

Thanks for your workI'm still not very familiar with debian tools
Best, Luca.

I have just uploaded plasma-workspace, it should fix the crash

Thanks a lot for the very quick fix.
Thanks to all people involved in solving this.

Best regards





--
Saluti, Luca Pedrielli

Re: Transition of Qt to 5.12.5

[Matthieu Gallien]

On Wednesday, October 23, 2019 9:05:11 PM CEST Lisandro Damián Nicanor Pérez 
Meyer wrote:
> Hi!

Hello

> El mié., 23 oct. 2019 16:01, luca.pedrielli  escribió:
> > Thanks for your workI'm still not very familiar with debian tools
> > Best, Luca.
> 
> I have just uploaded plasma-workspace, it should fix the crash

Thanks a lot for the very quick fix.
Thanks to all people involved in solving this.

Best regards

Re: Transition of Qt to 5.12.5

[Martin Steigerwald]

Lisandro Damián Nicanor Pérez Meyer - 23.10.19, 21:05:11 CEST:
> El mié., 23 oct. 2019 16:01, luca.pedrielli  escribió:
> > Thanks for your workI'm still not very familiar with debian
> > tools
> > Best, Luca.
> 
> I have just uploaded plasma-workspace, it should fix the crash

Affected users who do not like to wait for the updated packages to appear
can download "right side" of the two files manually from the upstream
patch

[Notifications] Don't bind model inside headerItem]
https://phabricator.kde.org/D24654

and copy them to

/usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/Notifications.qml

/usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/main.qml

Make a copy of the old files first, just in case.

Then restarting plasmashell by first stopping the process and starting it
for example through krunner should fix the issue.

It did for me.

Thanks,
-- 
Martin

Re: Transition of Qt to 5.12.5

[Martin Steigerwald]

Lisandro Damián Nicanor Pérez Meyer - 23.10.19, 21:05:11 CEST:
> El mié., 23 oct. 2019 16:01, luca.pedrielli  
> escribió:
> > Thanks for your workI'm still not very familiar with debian
> > tools
> > Best, Luca.
> 
> I have just uploaded plasma-workspace, it should fix the crash

Now isn't that a great turn-around time?

And a good example of several people working together, everyone doing 
their part.

Thank you, Lisandro. Thanks also to Mitya who brought my digging for a 
fix to a conclusion.

Let's hope the fix works well. Until then my plasmashell will collect a 
few more crashes. Who has the high score on those? :)

Thanks,
-- 
Martin

How to report bugs (was: Re: Transition of Qt to 5.12.5)

[Martin Steigerwald]

luca.pedrielli - 23.10.19, 21:01:06 CEST:
> Thanks for your workI'm still not very familiar with debian tools
> Best, Luca.

reportbug PACKAGENAME

guides you through the process quite well.

You can read about how to report bugs at

https://www.debian.org/Bugs/Reporting

Some stuff may be outdated there, cause I usually recommend checking 
about upstream bug reports and report there as well if not already done 
– so the Debian package maintainer won't have to. This work can help the 
small Debian/Kubuntu Qt/KDE team a lot.

There is also some information about applicable severity levels:

https://www.debian.org/Bugs/Developer#severities

If unsure I tend to err on using a to low level. It can always be 
raised.

Best,
-- 
Martin

Re: Transition of Qt to 5.12.5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El mié., 23 oct. 2019 16:01, luca.pedrielli  escribió:

> Thanks for your workI'm still not very familiar with debian tools
> Best, Luca.
>

I have just uploaded plasma-workspace, it should fix the crash

>

Re: Transition of Qt to 5.12.5

[luca.pedrielli]

Thanks for your workI'm still not very familiar with debian tools
Best, Luca.

Il 23/10/19 20:37, Martin Steigerwald ha scritto:

Dear Luca.

Martin Steigerwald - 23.10.19, 18:51:19 CEST:

luca.pedrielli - 23.10.19, 11:45:46 CEST:

plasmashell crashes with notification :(

I can reproduce it everytime with:

$ kdialog --passivepopup 'text' 5

Thank you for report. I can reproduce it.

So while apt dist-upgrade worked smoothly so far, you may like to wait
with an upgrade until this is fixed or a generic work-around if
found.

plasma-workspace: plasmashell with Qt 5.12.5 crashes on any
notification https://bugs.debian.org/943344

[…]

Of course next time, Luca, feel free to report a bug yourself. I just
reported the issue straight away on bug tracker and pinged other Debian/
Kubuntu Qt/KDE team members on IRC channel so it can quickly be acted
upon.

A fix is being tested. If it works it may be uploaded soon.

Thank you again for your contribution.

Best,

Re: Transition of Qt to 5.12.5

[Martin Steigerwald]

Dear Luca.

Martin Steigerwald - 23.10.19, 18:51:19 CEST:
> luca.pedrielli - 23.10.19, 11:45:46 CEST:
> > plasmashell crashes with notification :(
> > 
> > I can reproduce it everytime with:
> > 
> > $ kdialog --passivepopup 'text' 5
> 
> Thank you for report. I can reproduce it.
> 
> So while apt dist-upgrade worked smoothly so far, you may like to wait
> with an upgrade until this is fixed or a generic work-around if
> found.
> 
> plasma-workspace: plasmashell with Qt 5.12.5 crashes on any
> notification https://bugs.debian.org/943344
[…]

Of course next time, Luca, feel free to report a bug yourself. I just 
reported the issue straight away on bug tracker and pinged other Debian/
Kubuntu Qt/KDE team members on IRC channel so it can quickly be acted 
upon.

A fix is being tested. If it works it may be uploaded soon.

Thank you again for your contribution.

Best,
-- 
Martin

Re: Transition of Qt to 5.12.5

[Martin Steigerwald]

luca.pedrielli - 23.10.19, 18:55:13 CEST:
> plasmashell crash on any notification debug info:
> 
> --
> -
> 
> Application: Plasma (plasmashell), signal: Segmentation fault
> Using host libthread_db library
> "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1
> (Thread 0x7f69a1ce4880 (LWP 15853))]
> 
> Thread 8 (Thread 0x7f697dca2700 (LWP 16144)):
> #0  0x7f69a52f0db5 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib/x86_64-linux-gnu/libpthread.so.0

Thank you.

Feel free to add this to the bug report I just created if its different 
enough from the backtrace I sent there.

Thanks,
-- 
Martin

Re: Transition of Qt to 5.12.5

[luca.pedrielli]

plasmashell crash on any notification debug info:

---

Application: Plasma (plasmashell), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f69a1ce4880 (LWP 15853))]

Thread 8 (Thread 0x7f697dca2700 (LWP 16144)):
#0  0x7f69a52f0db5 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7f69a64097ef in QWaitConditionPrivate::wait (deadline=..., 
this=0x55f1425ba9c0) at thread/qwaitcondition_unix.cpp:146
#2  QWaitCondition::wait (this=, mutex=0x55f1425aaae0, 
deadline=...) at thread/qwaitcondition_unix.cpp:225
#3  0x7f69a64098d9 in QWaitCondition::wait (this=0x55f1425aaae8, 
mutex=0x55f1425aaae0, time=) at 
../../include/QtCore/../../src/corelib/kernel/qdeadlinetimer.h:68
#4  0x7f69a8205009 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#5  0x7f69a82052ad in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#6  0x7f69a64038d2 in QThreadPrivate::start (arg=0x55f1425aaa60) at 
thread/qthread_unix.cpp:361
#7  0x7f69a52eafb7 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0

#8  0x7f69a60a72ef in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 7 (Thread 0x7f697e4e0700 (LWP 16143)):
#0  0x7f69a609cd2f in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f69a459609e in ?? () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f69a45961bf in g_main_context_iteration () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f69a661880b in QEventDispatcherGlib::processEvents 
(this=0x7f697b20, flags=...) at kernel/qeventdispatcher_glib.cpp:424
#4  0x7f69a65c171b in QEventLoop::exec 
(this=this@entry=0x7f697e4dfce0, flags=..., flags@entry=...) at 
../../include/QtCore/../../src/corelib/global/qflags.h:140
#5  0x7f69a6402751 in QThread::exec (this=) at 
../../include/QtCore/../../src/corelib/global/qflags.h:120
#6  0x7f697f8fa2a8 in KCupsConnection::run() () from 
/usr/lib/x86_64-linux-gnu/libkcupslib.so
#7  0x7f69a64038d2 in QThreadPrivate::start (arg=0x55f14255d540) at 
thread/qthread_unix.cpp:361
#8  0x7f69a52eafb7 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0

#9  0x7f69a60a72ef in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 6 (Thread 0x7f6985166700 (LWP 16117)):
#0  0x7f69a6098900 in read () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f69a45dccef in ?? () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f69a4595bee in g_main_context_check () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f69a4596042 in ?? () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f69a45961bf in g_main_context_iteration () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7f69a661880b in QEventDispatcherGlib::processEvents 
(this=0x7f6978000b20, flags=...) at kernel/qeventdispatcher_glib.cpp:424
#6  0x7f69a65c171b in QEventLoop::exec 
(this=this@entry=0x7f6985165ce0, flags=..., flags@entry=...) at 
../../include/QtCore/../../src/corelib/global/qflags.h:140
#7  0x7f69a6402751 in QThread::exec (this=) at 
../../include/QtCore/../../src/corelib/global/qflags.h:120
#8  0x7f69a817aeb6 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#9  0x7f69a64038d2 in QThreadPrivate::start (arg=0x55f13fa79f20) at 
thread/qthread_unix.cpp:361
#10 0x7f69a52eafb7 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0

#11 0x7f69a60a72ef in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 5 (Thread 0x7f69874e9700 (LWP 16102)):
#0  0x7f69a52f0db5 in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#1  0x7f69a64097ef in QWaitConditionPrivate::wait (deadline=..., 
this=0x55f13fa762c0) at thread/qwaitcondition_unix.cpp:146
#2  QWaitCondition::wait (this=, mutex=0x55f14008cc50, 
deadline=...) at thread/qwaitcondition_unix.cpp:225
#3  0x7f69a64098d9 in QWaitCondition::wait (this=0x55f14008cc58, 
mutex=0x55f14008cc50, time=) at 
../../include/QtCore/../../src/corelib/kernel/qdeadlinetimer.h:68
#4  0x7f69a8205009 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#5  0x7f69a82052ad in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#6  0x7f69a64038d2 in QThreadPrivate::start (arg=0x55f14008cbd0) at 
thread/qthread_unix.cpp:361
#7  0x7f69a52eafb7 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0

#8  0x7f69a60a72ef in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 4 (Thread 0x7f699abe7700 (LWP 15923)):
#0  0x7f69a8a473f0 in __tls_get_addr () from /lib64/ld-linux-x86-64.so.2
#1  0x7f69a6402de6 in get_thread_data () at thread/qthread_unix.cpp:239
#2  QThreadData::current 
(createIfNecessary=createIfNecessary@entry=true) at 
thread/qthread_unix.cpp:239
#3  0x7f69a6618ef1 in postEventSourcePrepare (timeout=0x

Re: Transition of Qt to 5.12.5

[Martin Steigerwald]

Hi Luca.

luca.pedrielli - 23.10.19, 11:45:46 CEST:
> plasmashell crashes with notification :(
> 
> I can reproduce it everytime with:
> 
> $ kdialog --passivepopup 'text' 5

Thank you for report. I can reproduce it.

So while apt dist-upgrade worked smoothly so far, you may like to wait 
with an upgrade until this is fixed or a generic work-around if found.

plasma-workspace: plasmashell with Qt 5.12.5 crashes on any notification
https://bugs.debian.org/943344

Backtrace should be there soon, just send a mail with it a moment ago.

For now it is also here:

https://paste.debian.net/1109353/

Thanks,
-- 
Martin

Re: Transition of Qt to 5.12.5

[luca.pedrielli]

plasmashell crashes with notification :(

I can reproduce it everytime with:

$ kdialog --passivepopup 'text' 5

--

Saluti, Luca Pedrielli

Re: Transition of Qt to 5.12.5

[luca.pedrielli]

after latest update plasmashell segfault on login, but restart.

as workaround I have disabled network-manager active connection 
notification in systemsettings.


-
Saluti, Luca Pedrielli

Re: Transition of Qt to 5.12.5

[Diederik de Haas]

On maandag 21 oktober 2019 21:20:38 CEST Martin Steigerwald wrote:
> Careful with "apt dist-upgrade"

Use safe-upgrade 

signature.asc
Description: This is a digitally signed message part.

Re: Transition of Qt to 5.12.5

[MERLIN Philippe]

Le lundi 21 octobre 2019, 21:20:38 CEST Martin Steigerwald a écrit :
> Hi!
> 
> Mitya started transition of Qt to 5.12.5 . Careful with "apt dist-
> upgrade"! Wait until completion.
> 
> Best,

Good news. 
I hope that he solved the problem of kmail and print message.
Cheers.
Philippe Merlin

Transition of Qt to 5.12.5

[Martin Steigerwald]

Hi!

Mitya started transition of Qt to 5.12.5 . Careful with "apt dist-
upgrade"! Wait until completion.

Best,
-- 
Martin

Re: Some information about the removal of Qt 4 and remaining KDE SC 4.14

[Rob Brewer]

Hi Martin,

Martin Steigerwald wrote:

> Hmmm… yes. KNode is not maintained by upstream anymore:
> 
> https://kde.org/applications/unmaintained/org.kde.knode
> 
> See also:
> 
> [kdepim4] Future Qt4 removal from Buster
> 
> https://bugs.debian.org/874947
> 
> There has been thoughts to integrate news reading into Akonadi based
> KMail, but this has never been completed.
> 
> So unless someone ports KNode to KF 5 / Qt 5, it would be gone for now.
> 

I wish I could help but I did look at porting it last year but decided that 
I didn't have sufficient background in kde to support doing it. 

I did look at Pino's Akonadi version at 
https://cgit.kde.org/scratch/pino/akonadi-nntp.git/
but didn't use it. Probably the way to go for kde if knode does finally die 
but I don't think I'm sufficiently qualified to help make it happen.

> 
> You can delay this by not cleaning up and hoping it will be able to
> remain installed for at least a little longer. But sooner or later… it
> would be time to say goodbye (or work on it).
> 
> You may opt to subscribe to the mailing list. I use KMail with it and it
> works okay. I still use POP3 so I let it download and filter locally into
> a folder. KMail has good mailing list support, so answers go to the
> list, unless the sender set a Reply-To to a different location. (I do not
> recommend the latter.)
> 
For me it's historical since I have a local inn2 newsserver which also 
maintains a feed of newsgroups from an external news server. These days I 
have some quite vigorous filter rules which remove most of the junk and 
makes news reading acceptable. Knode integrates with this well set up and 
with other kde applications so its loss  to me would be substantial.

I'll try Gnome's Pan newsreader in the meantime since it looks like this may 
be better supported in the future. Shame its gtk based and not qt though. I 
did look at Thunderbird but couldn't get on with its interface.

> It is a bit of a pity. For many the Internet is just Web 2.0 anymore.
> That there is a lot of other services with usable fat clients…
> 
I guess a lot of the many don't know what they're missing :)


Regards


Rob

Hmmm... will this be the last message i send from knode ??

Re: Some information about the removal of Qt 4 and remaining KDE SC 4.14

[Martin Steigerwald]

Hi Rob.

Rob Brewer - 26.08.19, 09:57:19 CEST:
> Andrey Rahmatullin wrote:
> >> Also most of the stuff above is RM'd from Debian archive already
> >> and *won't* receive any security updates from now on anymore.
> > 
> > As usual, you can find such packages with
> > $ apt-show-versions | fgrep 'No available'
> 
> " knode:amd64 4:4.14.10-7+b3 installed: No available version in
> archive "
> 
> So this will presumably leave kde without a working newsreader and
> since I use a mail to news gateway to read this list and several
> others will mean I will no longer be able to see if this is resolved
> unless I jump through  a lot of hoops.
> 
> I was aware this would happen someday but it's very sad.

Hmmm… yes. KNode is not maintained by upstream anymore:

https://kde.org/applications/unmaintained/org.kde.knode

See also:

[kdepim4] Future Qt4 removal from Buster

https://bugs.debian.org/874947

There has been thoughts to integrate news reading into Akonadi based 
KMail, but this has never been completed.

So unless someone ports KNode to KF 5 / Qt 5, it would be gone for now.


You can delay this by not cleaning up and hoping it will be able to 
remain installed for at least a little longer. But sooner or later… it 
would be time to say goodbye (or work on it).

You may opt to subscribe to the mailing list. I use KMail with it and it 
works okay. I still use POP3 so I let it download and filter locally into 
a folder. KMail has good mailing list support, so answers go to the 
list, unless the sender set a Reply-To to a different location. (I do not 
recommend the latter.)

It is a bit of a pity. For many the Internet is just Web 2.0 anymore. 
That there is a lot of other services with usable fat clients…

Best,
-- 
Martin

Re: Some information about the removal of Qt 4 and remaining KDE SC 4.14

[Rob Brewer]

Andrey Rahmatullin wrote:

>> Also most of the stuff above is RM'd from Debian archive already and
>> *won't* receive any security updates from now on anymore.
> As usual, you can find such packages with
> $ apt-show-versions | fgrep 'No available'
> 

" knode:amd64 4:4.14.10-7+b3 installed: No available version in archive "

So this will presumably leave kde without a working newsreader and since I 
use a mail to news gateway to read this list and several others will mean I 
will no longer be able to see if this is resolved unless I jump through  a 
lot of hoops.

I was aware this would happen someday but it's very sad.


Rob

Re: Some information about the removal of Qt 4 and remaining KDE SC 4.14

[Andrey Rahmatullin]

On Mon, Aug 26, 2019 at 09:19:49AM +0200, Martin Steigerwald wrote:
> Also most of the stuff above is RM'd from Debian archive already and *won't*
> receive any security updates from now on anymore.
As usual, you can find such packages with 
$ apt-show-versions | fgrep 'No available'

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Some information about the removal of Qt 4 and remaining KDE SC 4.14

[Martin Steigerwald]

Hi!

Debian/Kubuntu Qt/KDE work on finally removing Qt 4 and KDE SC 4.14

On my system it is now possible to do this:

% LANG=C apt purge kdelibs5-plugins kdelibs5-data kdelibs-bin
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer required:
  amarok-utils kde-runtime-data libgpgme++2v5 libkactivities6 libkcalcore4 
libkdeclarative5 libkjsembed4 libkntlm4 libkrosscore4 libmariadbd19 
libpolkit-qt-1-1
  libqtscript4-gui libqtscript4-network libqtscript4-sql libqtscript4-uitools 
libqtscript4-xml libxi6:i386 libxtst6:i386
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  amarok* kaccessible* kde-runtime* kdelibs-bin* kdelibs5-data* 
kdelibs5-plugins* kdesdk-misc* kdesudo* kfilereplace* kmtrace* kommander* kppp* 
kremotecontrol* kscd*
  ktimetracker* kuser* pairs*
0 upgraded, 0 newly installed, 17 to remove and 1 not upgraded.
After this operation, 55.1 MB disk space will be freed.
Do you want to continue? [Y/n]


Which means bye, bye Amarok again *sniff*.


And then this:

% LANG=en apt purge libqtcore4
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer required:
  kate-data kde-runtime-data libgpgme++2v5 libkonq5-templates libmariadbd19 
libxi6:i386 libxtst6:i386 qt4-qmake qtcore4-l10n scribus-data
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  amarok-utils* appmenu-qt* automoc* katepart* kde-style-breeze-qt4* 
kde-style-oxygen-qt4* kde-style-qtcurve-qt4* kdoctools* kpart-webkit* 
libattica-dev* libattica0.4*
  libdbusmenu-qt2* libgwengui-qt4-0* libkabc4* libkactivities6* 
libkatepartinterfaces4* libkcalcore4* libkcmutils4* libkde3support4* 
libkdeclarative5* libkdecore5*
  libkdesu5* libkdeui5* libkdewebkit5* libkdnssd4* libkemoticons4* libkfile4* 
libkhtml5* libkio5* libkjsapi4* libkjsembed4* libkldap4* libkmediaplayer4* 
libkmime4*
  libknewstuff2-4* libknewstuff3-4* libknotifyconfig4* libkntlm4* 
libkonq-common* libkonq5abi1* libkopete4* libkparts4* libkpimidentities4* 
libkpimtextedit4*
  libkpimutils4* libkprintutils4* libkpty4* libkresources4* libkrosscore4* 
libktexteditor4* liblastfm1* libmygpo-qt1* libntrack-qt4-1* libphonon-dev* 
libphonon4*
  libplasma3* libpolkit-qt-1-1* libqca2* libqca2-dev* libqca2-plugins* 
libqimageblitz4* libqjson-dev* libqjson0* libqt4-dbus* libqt4-declarative* 
libqt4-designer*
  libqt4-dev* libqt4-dev-bin* libqt4-help* libqt4-network* libqt4-opengl* 
libqt4-qt3support* libqt4-script* libqt4-scripttools* libqt4-sql* 
libqt4-sql-mysql*
  libqt4-sql-psql* libqt4-sql-sqlite* libqt4-svg* libqt4-test* libqt4-xml* 
libqt4-xmlpatterns* libqtcore4* libqtdbus4* libqtgui4* libqtscript4-core* 
libqtscript4-gui*
  libqtscript4-network* libqtscript4-sql* libqtscript4-uitools* 
libqtscript4-xml* libqtwebkit4* libsolid4* libthreadweaver4* phonon* 
phonon-backend-gstreamer*
  phonon-backend-vlc* plasma-scriptengine-javascript* plasma-theme-oxygen* 
plasma-widget-folderview* qdbus* qt-at-spi* qt4-dev-tools* qt4-linguist-tools* 
qt4-qmlviewer*
  qt4-qtconfig* scribus* sni-qt*
0 upgraded, 0 newly installed, 108 to remove and 1 not upgraded.
After this operation, 233 MB disk space will be freed.
Do you want to continue? [Y/n]


If you rely on some of the things being removed here, just do not do this for
now. And hope that in more KF 5 / Qt 5 ports become available and
are packaged, before …

… sooner or later apt may ask for the removal of something you used when
upgrading the system.

Also most of the stuff above is RM'd from Debian archive already and *won't*
receive any security updates from now on anymore.

Those who rely on Scribus: Install scribus-ng, which is Qt 5 based.

The removal of Qt 4 and KDE SC 4.14 has been overdue. It is not supported
by upstream for quite some time now.

Best,
-- 
Martin

Re: [Pkg-xmpp-devel] Qt/KDE XMPP/Jabber client with OMEMO

[Martin Steigerwald]

Hi,

Linus Jahn - 19.08.19, 19:31:33 CEST:
> On Mon, 19 Aug 2019 19:18:13 +0300
> 
> Boris Pek  wrote:
> > >>  Then there is kaidan.im which is not packaged yet.
> > 
> > I saw mentions of this project few times (in qxmpp related
> > discussions) but have not looked on program yet.
> > 
> > As I see there is related team on Salsa:
> > https://salsa.debian.org/kaidan-team
> > 
> > But I have no idea why these packages are not in Debian repos yet
> > and
> > why its maintainers have decided to maintain these packages outside
> > of Debian XMPP Maintainers team.
> > 
> > Probably Jonah may comment this. (CC-ing)
> 
> We don't "have decided" to maintain it outside of debian, we just
> didn't have an idea how to get it into debian. Kaidan is still in
> development: the basic functionality is not implemented completely
> yet. Also, we only recently became a KDE project, so we didn't have
> the contact to the debian team.
> 
> However recently there were some mails about packaging Kaidan in
> debian on the Qt/KDE-list, so I hope it can get into debian soon.

Ah, I did not notice these. Thanks for the pointer. Looking forward to 
it.

> OMEMO is on our roadmap and also PEP (a dependency of OMEMO) has been
> implemented for QXmpp (still needs to be upstreamed). But don't expect
> OMEMO earlier than in one year.

I understand. I am willing to test kaidan.im Debian package. So in case 
you like anyone to test it, tell me. I can also build it myself from 
source.

However for productive use OMEMO is a must for me. So I will wait until 
OMEMO support being completed before considering kaidan.im for 
productive use.

All the best,
-- 
Martin

Re: Qt/KDE XMPP/Jabber client with OMEMO

[Martin Steigerwald]

Dropping CC to Jonah as my reply is mostly not related to Kaidan.im.

Hi!

Thank you for your detailed mail.

Boris Pek - 19.08.19, 18:18:13 CEST:
> >>  Is there such a thing available in Debian?
> 
> You may ask XMPP related questions in Debian XMPP Maintainers team
> mailing list: https://wiki.debian.org/Teams/pkg-xmpp

I was aware of this list, however thought that it was for development 
stuff only.

> >>  Kopete 17.08 does not do it.
> 
> Yes, IIRC Kopete has support only for GnuPG and OTR.

I found that very recent versions might support it, but those are not 
packaged in Debian yet. And I was not sure whether that would be really 
the case.

> >>  PSI is said to have OMEMO, but does not appear to have it in
> >>  Debian.
> 
> Yes, unfortunately psi package in Debian is outdated and psi-plugins
> package is not in official repos yet. This is in my TODO list, but
> progress is slow...

Ah, I see. Thank you.

> > I now also tried psi-plus. And found I missed two things before:
> > 
> > There is a OMEMO plugin and I can activate.
> > 
> > Messages send are still not encrypted as I can see in dino.im
> > 
> > There is supposed to be a OMEMO plugin symbol in toolbar in chat
> > window but there is not, even tough it is supposed to be there
> > according to settings window.
> > 
> > I leave it at that for today.
> 
> Current version of Psi+ OMEMO plugin in Debian supports all necessary
> features:
> * e2e encryption in private chats
> * e2e encryption in group chats (all members of group chats should
> have enabled OMEMO plugins in their XMPP clients)
> * e2e encryption of files uploaded to XMPP server using HTTP Upload
> Plugin 
> * etc.

I see.

> It is comprehensive tested with Gajim and Conversations.
> 
> Please check:
> 
> 1) Have you tried to restart application after enabling of OMEMO
> plugin?

Yes.

> 2) Do you have OMEMO buttons on toolbars in chat windows? If
> not you may enable them in Psi+ Options dialog in Toolbars section.

Yes. And I now found them as well.

Either they have not been there before or I just did not find them. I 
thought the lock symbol might be it, but it seems that this refers to 
the built-in encryption.

I clicked on "Enable OMEMO" with a contact and according to dino-im it 
seems to work okay.

> 3) In some rare cases you may face with broken databases.
>Try to remove files:
>~/.local/share/psi+/profiles/default/omemo-*.sqlite
>and restart Psi+.

I did so before, as I thought I had uninstalled Psi+, but I kept it 
around. So maybe there was an issue with that, maybe not.
 
> Also there is no global option to enable OMEMO encryption in all chats
> of Psi+: you should explicitly enable encryption in each chat
> manually.

Yep, I see that now.

> > dino.im works out of the box.
> > 
> >>  Only working (!) XMPP client I found in Debian so far is: dino.im
> >>  which is GTK based.
> 
> Great! Martin (debacle) may be proud of his work! =)

:)

> 
> >>  Gajim is supposed to be working, but gives a Python traceback on
> >>  activating OMEMO. Its also GTK based.
> 
> It is strange. Last time I have used Gajim for testing of OMEMO plugin
> in Psi+ it works fine. Except Gajim could not send OMEMO encrypted
> files to server. But is was able to decrypt such files sent from
> other XMPP clients!

Well I could test it again, but as I prefer an Qt based client, I'd go 
with psi+ for now. If you like I give it another test and open a bug 
report in case it still gives a backtrace.

> >>  Apparently there more than a dozen XMPP clients for Linux, but
> >>  none of them works as nicely as Conversations.im on Android for
> >>  far.
>
> Conversations is not that perfect (it lucks support of some popular
> features), but it is really convenient and simple in usage by regular
> users, yes.

Well, yes, that is what I meant.

> >>  One thing to try still would be KDE Telepathy, as I read somewhere
> >>  it
> >>  would do OMEMO. But it appears to be similarly outdated as Kopete.
> 
> And after news like this one:
> https://dot.kde.org/2019/02/20/kde-adding-matrix-its-im-framework
> I do not believe that any noticeable amount of KDE developers will be
> interested in development of XMPP client inside KDE project.
> Hope I am wrong here.

I look forward to newer releases of Konservation and Kopete in Debian. 
In my point of view there are some shortcomings regarding KDE/Qt based 
applications. One being chat applications and another being a decent 
music player. While Amarok is not fully ported to Qt 5, Elisa just is 
not there yet.

> >>  Then there is kaidan.im which is not packaged yet.
> 
> I saw m

Re: [Pkg-xmpp-devel] Qt/KDE XMPP/Jabber client with OMEMO

[Martin]

On 2019-08-19 22:23, Boris Pek wrote:
> And now you have a choice between Debian XMPP team and Debian Qt+KDE team:
> https://salsa.debian.org/qt-kde-team

In fact, I suggested to Jonah and Linus, that Kaidan may be
better off in the latter team. Mainly, because Qt/KDE perform
complex transitions every some years, so packaging work will
need more knowledge around those frameworks than about XMPP.
Also, the KDE team is larger than the XMPP team, which might
help the Kaidan developers. When the package has landed in
Debian, they can easily change teams, if they like.

Re: [Pkg-xmpp-devel] Qt/KDE XMPP/Jabber client with OMEMO

[Boris Pek]

>>  >> Then there is kaidan.im which is not packaged yet.
>>
>>  I saw mentions of this project few times (in qxmpp related
>>  discussions) but have not looked on program yet.
>>
>>  As I see there is related team on Salsa:
>>  https://salsa.debian.org/kaidan-team
>>
>>  But I have no idea why these packages are not in Debian repos yet and
>>  why its maintainers have decided to maintain these packages outside
>>  of Debian XMPP Maintainers team.
>>
>>  Probably Jonah may comment this. (CC-ing)
>
> We don't "have decided" to maintain it outside of debian, we just
> didn't have an idea how to get it into debian.

I mean outside of XMPP team in Debian, but not outside of Debian.

Now git repos for your packages are in independent Salsa group:
https://salsa.debian.org/kaidan-team
and I have found them only because I was searching for kaidan mentions in
Debian infrastructure.

As for adding of kaidan into Debian repos, then joining to specialized Debian
team usually simplify finding Debian Developers who are interested in
checking and uploading of your packages into Debian.

See this as an advertisement of our team:
https://salsa.debian.org/xmpp-team
=)

> Kaidan is still in
> development: the basic functionality is not implemented completely yet.

And this is absolutely normal. Dino.im is not released yet and lucks some
features too, but it is already available in Debian and may work fine for
some not exacting users.

> Also, we only recently became a KDE project, so we didn't have the
> contact to the debian team.

These are great news! Congratulations!

And now you have a choice between Debian XMPP team and Debian Qt+KDE team:
https://salsa.debian.org/qt-kde-team

> However recently there were some mails about packaging Kaidan in debian
> on the Qt/KDE-list, so I hope it can get into debian soon.

Excellent!

> OMEMO is on our roadmap and also PEP (a dependency of OMEMO) has been
> implemented for QXmpp (still needs to be upstreamed). But don't expect
> OMEMO earlier than in one year.

And this is fine. We are not in a hurry to anywhere.

Best wishes,
Boris

Re: [Pkg-xmpp-devel] Qt/KDE XMPP/Jabber client with OMEMO

[Linus Jahn]

On Mon, 19 Aug 2019 19:18:13 +0300
Boris Pek  wrote:

> >>  Then there is kaidan.im which is not packaged yet.  
> 
> I saw mentions of this project few times (in qxmpp related
> discussions) but have not looked on program yet.
> 
> As I see there is related team on Salsa:
> https://salsa.debian.org/kaidan-team
> 
> But I have no idea why these packages are not in Debian repos yet and
> why its maintainers have decided to maintain these packages outside
> of Debian XMPP Maintainers team.
> 
> Probably Jonah may comment this. (CC-ing)

We don't "have decided" to maintain it outside of debian, we just
didn't have an idea how to get it into debian. Kaidan is still in
development: the basic functionality is not implemented completely yet.
Also, we only recently became a KDE project, so we didn't have the
contact to the debian team.

However recently there were some mails about packaging Kaidan in debian
on the Qt/KDE-list, so I hope it can get into debian soon.

OMEMO is on our roadmap and also PEP (a dependency of OMEMO) has been
implemented for QXmpp (still needs to be upstreamed). But don't expect
OMEMO earlier than in one year.

Re: Qt/KDE XMPP/Jabber client with OMEMO

[Boris Pek]

Hi Martin,

>>  Is there such a thing available in Debian?

You may ask XMPP related questions in Debian XMPP Maintainers team
mailing list: https://wiki.debian.org/Teams/pkg-xmpp

>>  Kopete 17.08 does not do it.

Yes, IIRC Kopete has support only for GnuPG and OTR.

>>  PSI is said to have OMEMO, but does not appear to have it in Debian.

Yes, unfortunately psi package in Debian is outdated and psi-plugins package
is not in official repos yet. This is in my TODO list, but progress is slow...

> I now also tried psi-plus. And found I missed two things before:
>
> There is a OMEMO plugin and I can activate.
>
> Messages send are still not encrypted as I can see in dino.im
>
> There is supposed to be a OMEMO plugin symbol in toolbar in chat window
> but there is not, even tough it is supposed to be there according to
> settings window.
>
> I leave it at that for today.

Current version of Psi+ OMEMO plugin in Debian supports all necessary features:
* e2e encryption in private chats
* e2e encryption in group chats (all members of group chats should have enabled
  OMEMO plugins in their XMPP clients)
* e2e encryption of files uploaded to XMPP server using HTTP Upload Plugin
* etc.

It is comprehensive tested with Gajim and Conversations.

Please check:

1) Have you tried to restart application after enabling of OMEMO plugin?
2) Do you have OMEMO buttons on toolbars in chat windows? If not you
   may enable them in Psi+ Options dialog in Toolbars section.
3) In some rare cases you may face with broken databases.
   Try to remove files:
   ~/.local/share/psi+/profiles/default/omemo-*.sqlite
   and restart Psi+.

Also there is no global option to enable OMEMO encryption in all chats of Psi+:
you should explicitly enable encryption in each chat manually.

> dino.im works out of the box.
>
>>  Only working (!) XMPP client I found in Debian so far is: dino.im
>>  which is GTK based.

Great! Martin (debacle) may be proud of his work! =)

>>  Gajim is supposed to be working, but gives a Python traceback on
>>  activating OMEMO. Its also GTK based.

It is strange. Last time I have used Gajim for testing of OMEMO plugin in Psi+
it works fine. Except Gajim could not send OMEMO encrypted files to server. But
is was able to decrypt such files sent from other XMPP clients!

>>  Apparently there more than a dozen XMPP clients for Linux, but none of
>>  them works as nicely as Conversations.im on Android for far.

Conversations is not that perfect (it lucks support of some popular features),
but it is really convenient and simple in usage by regular users, yes.

>>  Pidgin also does not do it.

Pidgin is multi-protocol IM client and this significantly influences to its
structure and development process.

>>  One thing to try still would be KDE Telepathy, as I read somewhere it
>>  would do OMEMO. But it appears to be similarly outdated as Kopete.

And after news like this one:
https://dot.kde.org/2019/02/20/kde-adding-matrix-its-im-framework
I do not believe that any noticeable amount of KDE developers will be
interested in development of XMPP client inside KDE project.
Hope I am wrong here.

>>  Then there is kaidan.im which is not packaged yet.

I saw mentions of this project few times (in qxmpp related discussions) but
have not looked on program yet.

As I see there is related team on Salsa:
https://salsa.debian.org/kaidan-team

But I have no idea why these packages are not in Debian repos yet and why its
maintainers have decided to maintain these packages outside of Debian XMPP
Maintainers team.

Probably Jonah may comment this. (CC-ing)

>>  There are in part contradicting informations on which client can do it
>>  or not:
>>
>>  https://omemo.top/
>>
>>  versus
>>
>>  https://riseup.net/de/chat/clients
>>
>>  for example.

These tables are very useful in general, but they miss some information about
OMEMO support. For example: in which versions of XMPP clients it was
implemented.

For example, Psi IM 2.0 with OMEMO support is not released yet. OMEMO plugin
is currently available only in daily builds of Psi (from git master branch).

Best wishes,
Boris

Re: Qt/KDE XMPP/Jabber client with OMEMO

[Martin Steigerwald]

Martin Steigerwald - 29.07.19, 22:53:59 CEST:
> Is there such a thing available in Debian?
> 
> Kopete 17.08 does not do it.
> 
> PSI is said to have OMEMO, but does not appear to have it in Debian.

I now also tried psi-plus. And found I missed two things before:

There is a OMEMO plugin and I can activate.

Messages send are still not encrypted as I can see in dino.im

There is supposed to be a OMEMO plugin symbol in toolbar in chat window 
but there is not, even tough it is supposed to be there according to 
settings window.

I leave it at that for today.

dino.im works out of the box.
 
> Only working (!) XMPP client I found in Debian so far is: dino.im
> which is GTK based.
> 
> Gajim is supposed to be working, but gives a Python traceback on
> activating OMEMO. Its also GTK based.
> 
> Apparently there more than a dozen XMPP clients for Linux, but none of
> them works as nicely as Conversations.im on Android for far.
> 
> Pidgin also does not do it.
> 
> 
> One thing to try still would be KDE Telepathy, as I read somewhere it
> would do OMEMO. But it appears to be similarly outdated as Kopete.
> 
> Then there is kaidan.im which is not packaged yet.
> 
> 
> There are in part contradicting informations on which client can do it
> or not:
> 
> https://omemo.top/
> 
> versus
> 
> https://riseup.net/de/chat/clients
> 
> for example.
> 
> Thanks,


-- 
Martin

Qt/KDE XMPP/Jabber client with OMEMO

[Martin Steigerwald]

Hi!

Is there such a thing available in Debian?

Kopete 17.08 does not do it.

PSI is said to have OMEMO, but does not appear to have it in Debian.


Only working (!) XMPP client I found in Debian so far is: dino.im which 
is GTK based.

Gajim is supposed to be working, but gives a Python traceback on 
activating OMEMO. Its also GTK based.

Apparently there more than a dozen XMPP clients for Linux, but none of 
them works as nicely as Conversations.im on Android for far.

Pidgin also does not do it.


One thing to try still would be KDE Telepathy, as I read somewhere it 
would do OMEMO. But it appears to be similarly outdated as Kopete.

Then there is kaidan.im which is not packaged yet.


There are in part contradicting informations on which client can do it 
or not:

https://omemo.top/

versus

https://riseup.net/de/chat/clients

for example.

Thanks,
-- 
Martin