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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 1 août 2024 15:59:44 GMT+02:00, Alex Hermann <[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 01 Aug 2024 17:17:17 +0200
Aurélien COUDERC <[email protected]> wrote:

Le 1 août 2024 15:59:44 GMT+02:00, Alex Hermann
<[email protected]> 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~)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Shai Berger <[email protected]> writes:

On Thu, 01 Aug 2024 17:17:17 +0200
Aurélien COUDERC <[email protected]> wrote:

Le 1 août 2024 15:59:44 GMT+02:00, Alex Hermann
<[email protected]> 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

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmasUP8QHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYcsAEADNrsGic1UzH37NL5wmn/Q3HkBoOQ1q26Tb Joo/Gre4sJLGYM9QxdhlcUlMxI3LdLxDViIUSL//qdX2p0TpbkBfGHT6M7izbggY caqbKfzSXz/WDOhtx5vLVX2lCA87MfgCZXQBXCniloRYS8+RlAGhx6Lx/6spKt3F gd6ETY5NN4n69cRQDrim9Kzrf/irsXc31LkhdQipRfOxZBCsFwk60s1ZhxFtdZe1 2I8A0qnzmGexfCP3gCByqruX8AinNSr/apA0zxIhQ5Jsu9Gbz5oq90AsBGzb+VEq WxTeHPRvsHUywy8SP76KzV9uwVTHTtoh8yU3n4eRaI/IgzxoYM2yhmo+t8FL776Q d8XoaUHae3CVzIqnylmZD6xU8QUqudHhHCNl05RVMU/P5AYZbKZZ6T7MjuskKGKq uFX1Zm3mqFCM+NzkwanKWqd/4Ml2zl36SRaG5VARMopNq0YQEglhbkBZd79pGibF QH6mM4VVXFV2i8LRx0B6VjC+F/fKsjMNS0ZBUMVEm3rr7COZvTGST+YENu6nNtUh cq1XvB+VjPV0fkTdqkNrm2sHxreFnoLTB+7LfxZIWS2O2kgezSel47lfFyv7wpcj L+nZZ7xsYdLZ7QinqbVepqKuLyoKuftMOuwFNZhrVAs0Lcx98WD4qxi5Zeg/1CWi i7Y3qw8nyA==8wW7
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Le vendredi 2 août 2024, 05:22:39 CEST Nicholas D Steeves a écrit :

Shai Berger <[email protected]> writes:

On Thu, 01 Aug 2024 17:17:17 +0200
Aurélien COUDERC <[email protected]> wrote:

Le 1 août 2024 15:59:44 GMT+02:00, Alex Hermann
<[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 3 août 2024 20:22:50 GMT+02:00, Edward Shornock <[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Aurélien,

Aurélien COUDERC <[email protected]> writes:

Hi,

Le vendredi 2 août 2024, 05:22:39 CEST Nicholas D Steeves a écrit :

Shai Berger <[email protected]> writes:

On Thu, 01 Aug 2024 17:17:17 +0200
Aurélien COUDERC <[email protected]> wrote:

Le 1 août 2024 15:59:44 GMT+02:00, Alex Hermann
<[email protected]> 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

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmauuVMQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYVy8EACc42MBEc1I1JMqbFOYTAUSLe2dUA2bFczG sBX5DNHmr/nov2duUkaPEruTnVEoWcKBHUR9A9Rnhlu27lIBtyoI86b3NiPAZNgh uA9Rv7hLWvT9WXCbsyXEmzcPa4UzePS/f3c9kySSRJD0ZG4ELchmiXHJOqRgmq0K TKcXZqjmnPpLSdPoFHPq1OmuFiWOF2ofi+yrDS/lSr8TrBC7zr0Z2xVpszIAijSr 6OvHNNAHJusrVIiXmKUmCMEA7xikWzRIC8/CsyOLqSXl+x8zCJ/Rsfzs5iWkTtjr hbQ0PAinPCgKqa5NPLQmgRysuRruU+beTtY7tIUEqDHm0cFnDrGqB32RoIcf3Osl 1P2Xkgz94ROAt7UJ6oezFVWwiP4U8J3MDWgFgCoyJJICFzRNL4e5rbX+UlO4UcoS lBG6GuiFH91+9J0Xw3LHeMtNFVi3atY3qg7SROC5rRRBE5jdoU28mKTLPqPn5n3b 39mFGS9ytVMluFP082iYvnGaabV2WLqnW57leQRV55t0KBe1BAVXdcD4qncbnrOW ZpwW0r92P2ggbyJ7IdCQqle5Ta2E+Jh0XNYjnq06dEZ7WjbioejPDSRaiVMXb8qB NuNEsmnnpPQlmmq2EXGP/r3HPkV6IbqhKsOIkYxU/Kazf55SHp7XNJFO599IoypX mlZyNMNV8A==1V3+
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Nicholas,

Le 4 août 2024 01:12:19 GMT+02:00, Nicholas D Steeves <[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)