Re: Telepathy Contact Runner
El diumenge, 19 de juny de 2022, a les 19:20:40 (CEST), alexander.loh...@gmx.de va escriure: > Hello, > > regarding the „Telepathy Contact Runner“ plugin in > https://invent.kde.org/network/ktp-contact-runner, I wanted to ask if we > could move it to unmaintained. There has been very little development in > the ktp* repos and even less in this one. Also, it causes > https://bugs.kde.org/show_bug.cgi?id=452011. A less radical solution is to > ask the distributors to no longer ship this plugin as part of a default > Plasma installation. > What do you think? Seems a problem with installations shipping the runner and not the kded module. I don't see why that would mean we have to move this to unmaintained, just bug distributions to find their dependencies? Cheers, Albert > > Regards > Alexander
Re: Debugging CI test failures
On Sun, 19 Jun 2022 22:43:54 +1200 Ben Cooksley wrote: [...] > We therefore have no choice but to address this as annoying as it is. > > Would you like to start this process off with a MR to > https://invent.kde.org/sysadmin/ci-images/-/blob/master/windows-msvc2019/Dockerfile > ? Can do, but I won't be fast. Regards Thomas pgpDhA6B02IZG.pgp Description: OpenPGP digital signature
Re: Telepathy Contact Runner
+1 in absence of a fix On Sun, Jun 19, 2022 at 10:30 PM wrote: > > Hello, > > regarding the „Telepathy Contact Runner“ plugin in > https://invent.kde.org/network/ktp-contact-runner, I wanted to ask if we > could move it to unmaintained. > There has been very little development in the ktp* repos and even less in > this one. Also, it causes https://bugs.kde.org/show_bug.cgi?id=452011. > A less radical solution is to ask the distributors to no longer ship this > plugin as part of a default Plasma installation. > > What do you think? > > Regards > Alexander
Telepathy Contact Runner
Hello, regarding the „Telepathy Contact Runner“ plugin in https://invent.kde.org/network/ktp-contact-runner, I wanted to ask if we could move it to unmaintained. There has been very little development in the ktp* repos and even less in this one. Also, it causes https://bugs.kde.org/show_bug.cgi?id=452011. A less radical solution is to ask the distributors to no longer ship this plugin as part of a default Plasma installation. What do you think? Regards Alexander
Re: [QML] Having different imports depending on Qt version
Le dim. 19 juin 2022 à 13:05, Albert Astals Cid a écrit :
> El dissabte, 18 de juny de 2022, a les 14:24:21 (CEST), Johnny Jazeix va
> escriure:
> > Hi,
> >
> > for GCompris (compiled in Qt5 only), we have activities using the
> Calendar
> > qml object.
> >
> > Previously, we imported the one from QtQuick.Controls 1 but this module
> has
> > been deprecated and we switched to QtQuick.Controls 2. This component
> > hasn't been implemented in QtQuick.Controls 2 before Qt6.3 (via "import
> > QtQuick.Controls").
> >
> > This one is available in Qt Marketplace (
> > https://code.qt.io/cgit/qt-extensions/qtquickcalendar.git) and supports
> Qt5
> > and Qt 6.0-> 6.2 (via "import QtQuick.Calendar 1.0") but requires
> > QtControls private headers to be installed and they are not present on
> some
> > distributions (Ubuntu < 21.04...), which we would like to still support
> for
> > the next version.
> >
> > There is the one in Qt.labs which is available in Qt5 but not Qt6 (via
> > "import Qt.labs.calendar 1.0").
> >
> > GCompris' code works fine with any of the import (
> >
> https://invent.kde.org/education/gcompris/-/blob/master/src/activities/calen
> > dar/Calendar.qml#L14) but I didn't find any "if(Qt_version < ...) use
> one,
> > else the other" except doing a Calendar.qml.cmake with a @GOOD_IMPORT@
> that
> > would be set by cmake and a configure_file.
> > Is there a better way?
> >
> > For now, we only target Qt5, so we could use Qt.labs without having to
> > handle the other two but once we switch to Qt6, we will face the issue
> with
> > distributions using Qt6.2 so I'd rather prepare this transition sooner
> than
> > later.
>
> As you have found, tou need to have two different codebases for Qt5 and
> Qt6.
>
> QML doesn't have "ifdef", the only way I've been able to simulate
> something
> like in pure QML that is having a Loader loads "the old version" and then
> reacting to the Loader status changing to Loader.Error and trying to old
> "the
> new version".
>
> Another somewhat less ugly way way is simply having a C++ singleton or
> something that tells you the Qt version and then also using a Loader to do
> the
> same
>
> Loader {
> source: Singleton.isQt6 ? "Qt6Code.qml" : "Qt5Code.qml"
> }
>
>
Thank you for confirming there is no "clean" (as without duplicating the
code) way to do it.
I've still used the "configure_file" solution as it is the one that does
not duplicate files.
Cheers,
Johnny
> Cheers,
> Albert
>
> >
> > Cheers,
> >
> > Johnny
>
>
>
>
>
Re: [QML] Having different imports depending on Qt version
El dissabte, 18 de juny de 2022, a les 14:24:21 (CEST), Johnny Jazeix va
escriure:
> Hi,
>
> for GCompris (compiled in Qt5 only), we have activities using the Calendar
> qml object.
>
> Previously, we imported the one from QtQuick.Controls 1 but this module has
> been deprecated and we switched to QtQuick.Controls 2. This component
> hasn't been implemented in QtQuick.Controls 2 before Qt6.3 (via "import
> QtQuick.Controls").
>
> This one is available in Qt Marketplace (
> https://code.qt.io/cgit/qt-extensions/qtquickcalendar.git) and supports Qt5
> and Qt 6.0-> 6.2 (via "import QtQuick.Calendar 1.0") but requires
> QtControls private headers to be installed and they are not present on some
> distributions (Ubuntu < 21.04...), which we would like to still support for
> the next version.
>
> There is the one in Qt.labs which is available in Qt5 but not Qt6 (via
> "import Qt.labs.calendar 1.0").
>
> GCompris' code works fine with any of the import (
> https://invent.kde.org/education/gcompris/-/blob/master/src/activities/calen
> dar/Calendar.qml#L14) but I didn't find any "if(Qt_version < ...) use one,
> else the other" except doing a Calendar.qml.cmake with a @GOOD_IMPORT@ that
> would be set by cmake and a configure_file.
> Is there a better way?
>
> For now, we only target Qt5, so we could use Qt.labs without having to
> handle the other two but once we switch to Qt6, we will face the issue with
> distributions using Qt6.2 so I'd rather prepare this transition sooner than
> later.
As you have found, tou need to have two different codebases for Qt5 and Qt6.
QML doesn't have "ifdef", the only way I've been able to simulate something
like in pure QML that is having a Loader loads "the old version" and then
reacting to the Loader status changing to Loader.Error and trying to old "the
new version".
Another somewhat less ugly way way is simply having a C++ singleton or
something that tells you the Qt version and then also using a Loader to do the
same
Loader {
source: Singleton.isQt6 ? "Qt6Code.qml" : "Qt5Code.qml"
}
Cheers,
Albert
>
> Cheers,
>
> Johnny
Re: Debugging CI test failures
On Sun, Jun 19, 2022 at 7:58 PM Thomas Friedrichsmeier < thomas.friedrichsme...@kdemail.net> wrote: > On Sun, 19 Jun 2022 00:44:08 +1200 > Ben Cooksley wrote: > > [...] > > > Looks like DirectX and it's corresponding components are missing: > > > > PS C:\> Get-ChildItem -Path C:\ -Recurse -ErrorAction SilentlyContinue > > -Force -Filter ddraw.dll > > PS C:\> Get-ChildItem -Path C:\ -Recurse -ErrorAction SilentlyContinue > > -Force -Filter glu32.dll > > PS C:\> Get-ChildItem -Path C:\ -Recurse -ErrorAction SilentlyContinue > > -Force -Filter MFCaptureEngine.dll > > > > Looks like to make QtWebEngine work we would need to make some > > changes to our Windows image: > > - > > > https://social.msdn.microsoft.com/Forums/en-US/b646b841-c9fb-4f39-9662-5b59f02279ab/installing-servermediafoundation-in-a-docker-container?forum=windowscontainers > > - > > > https://social.msdn.microsoft.com/Forums/lync/en-US/386adbc4-3e43-4896-8cbb-ba9cc7fc6b72/how-to-install-directx-to-windows-server-core-docker-container?forum=windowscontainers > > That looks like a bit of a mess, too. What is your (and everybody's) > take on how we should proceed? Are those changes to the image more > trouble than it's worth? > In the long term we will need to be able to build Qt within a simpler version of this container - specifically kdeorg/windows-msvc2019. This will be needed to support the Craft Cache on which the kdeorg/windows-qt515 image depends, as well as the Binary Factory builds (which when implemented in the context of Gitlab will likely use the kdeorg/windows-msvc2019 image too). We therefore have no choice but to address this as annoying as it is. Would you like to start this process off with a MR to https://invent.kde.org/sysadmin/ci-images/-/blob/master/windows-msvc2019/Dockerfile ? > I still have the alternative option to factor out any linkage to > QWebEngine from the testcase. Annoying but possible. > > (Is there a way to detect that it's a CI build?) > Yes, via environment variables, but it is probably not best that conditional behaviour like this is added - let's fix this... > > Regards > Thomas > Cheers, Ben
Re: Debugging CI test failures
On Sun, 19 Jun 2022 00:44:08 +1200 Ben Cooksley wrote: [...] > Looks like DirectX and it's corresponding components are missing: > > PS C:\> Get-ChildItem -Path C:\ -Recurse -ErrorAction SilentlyContinue > -Force -Filter ddraw.dll > PS C:\> Get-ChildItem -Path C:\ -Recurse -ErrorAction SilentlyContinue > -Force -Filter glu32.dll > PS C:\> Get-ChildItem -Path C:\ -Recurse -ErrorAction SilentlyContinue > -Force -Filter MFCaptureEngine.dll > > Looks like to make QtWebEngine work we would need to make some > changes to our Windows image: > - > https://social.msdn.microsoft.com/Forums/en-US/b646b841-c9fb-4f39-9662-5b59f02279ab/installing-servermediafoundation-in-a-docker-container?forum=windowscontainers > - > https://social.msdn.microsoft.com/Forums/lync/en-US/386adbc4-3e43-4896-8cbb-ba9cc7fc6b72/how-to-install-directx-to-windows-server-core-docker-container?forum=windowscontainers That looks like a bit of a mess, too. What is your (and everybody's) take on how we should proceed? Are those changes to the image more trouble than it's worth? I still have the alternative option to factor out any linkage to QWebEngine from the testcase. Annoying but possible. (Is there a way to detect that it's a CI build?) Regards Thomas pgpeZAKOsgsod.pgp Description: OpenPGP digital signature
Fwd: Compile failures with kdesrc-build
Forwarded Message Subject:Compile failures with kdesrc-build Date: Tue, 22 Feb 2022 17:23:39 -0500 From: o lu To: kde-devel@kde.org I am trying to compile some applications form the latest KDE with kdesrc-build. My system is Ubuntu 20.04. Command line ./kdesrc-build knights ... --include-dependencies --stop-on-failure Output Updating sysadmin-repo-metadata (to branch master) Building Qt5 from qt5-set (1/132) Error updating Qt5, removing from list of packages to build. > Failed to make initial clone of Qt5 Cloning Qt5 Unable to update Qt5, build canceled. Qt5 didn't build, stopping here. No source update, but /build/kde/build/kcoreaddons/cmake_install.cmake is missing No source update, but the build directory doesn't exist No source update, but the build directory doesn't exist No source update, but the build directory doesn't exist Error updating kdoctools, removing from list of packages to build. > Unable to stash local changes (if any) for kdoctools, aborting update. No source update, but the build directory doesn't exist No source update, but the build directory doesn't exist No source update, but the build directory doesn't exist No source update, but the build directory doesn't exist Error updating kdbusaddons, removing from list of packages to build. > Unable to perform git fetch for origin (kde:frameworks/kdbusaddons.git) Error updating kguiaddons, removing from list of packages to build. > Unable to perform git fetch for origin (kde:frameworks/kguiaddons.git) No source update, but the build directory doesn't exist No source update, but the build directory doesn't exist ^CSignal received, terminating. Unable to save persistent module data: No such file or directory Your logs are saved in file:///build/kde/down/log/2022-02-22-13 Also for some reason "Updating sysadmin-repo-metadata (to branch master)" always seems to take a long time. Thanks
