Re: I'm blocked from editing the KDE Community Wiki
On Mon, May 27, 2024 at 8:26 PM Tobias Leupold wrote:
> Hi all, and possibly Sysadmin!
>
Hey Tobias,
>
> I just tried to to edit KGeoTag's Community Wiki page at
> https://community.kde.org/KGeoTag
>
> I wanted to add some more info about dependencies you need to build it,
> i.e. I
> wanted to change
>
> cmake build-essential extra-cmake-modules qtbase5-dev libkf5coreaddons-dev
> libkf5i18n-dev libkf5xmlgui-dev libkf5crash-dev libkf5doctools-dev
> libkf5kexiv2-dev libmarble-dev
>
> to
>
> {{Input|1=
> git cmake build-essential gettext extra-cmake-modules qtbase5-dev
> libkf5coreaddons-dev libkf5i18n-dev libkf5xmlgui-dev libkf5crash-dev
> libkf5doctools-dev libkf5kexiv2-dev libmarble-dev
> }}
>
> I logged in using my Identity user name and the 2FA password. But the Wiki
> won't let me save the change:
>
> Sorry, you have been blocked
> You are unable to access kde.org
>
> The site tells me I should contact the site owner (maybe Sysadmin in this
> case?!) and tell the "Cloudflare Ray ID", which was 88a47f9ed8b0b398.
>
> What's wrong here?! I tried with Firefox and Chrome, using my normal wired
> internet connection (not TOR or whatever), with the same result.
>
> Thanks a lot for fixing this -- I think the project maintainer should be
> allowed to edit the project's wiki ;-)
>
This is most certainly something that only Sysadmin can fix. Thankfully it
is relatively easy as you've provided the Cloudflare Ray ID.
This appears to have been a false positive, with you managing to trip the
Command Injection - Common Attack Commands rule that Cloudflare provides as
part of their WAF.
Not the first time, alas - unfortunately the rules do tend to not handle
developer oriented content terribly well.
I've now disabled that particular rule, so you should be able to submit
your changes.
> Cheers, Tobias
>
>
>
Cheers,
Ben
Re: KDE Gear projects with failing CI (master) (21 May 2024)
On Sun, May 26, 2024 at 6:59 PM Volker Krause wrote: > On Samstag, 25. Mai 2024 13:34:53 CEST Ben Cooksley wrote: > > On Sat, May 25, 2024 at 3:09 AM Volker Krause wrote: > > > On Freitag, 24. Mai 2024 12:24:16 CEST Ben Cooksley wrote: > > > > On Fri, May 24, 2024 at 4:13 AM Volker Krause > wrote: > > > > > On Mittwoch, 22. Mai 2024 10:27:07 CEST Ben Cooksley wrote: > > > > > > On Wed, May 22, 2024 at 9:24 AM Albert Astals Cid > > > > > > > wrote: > > > > > > > Please work on fixing them, otherwise i will remove the > failing CI > > > > > > > > > > jobs on > > > > > > > > > > > > their 4th failing week, it is very important that CI is passing > > > > > > > for > > > > > > > multiple > > > > > > > reasons. > > > > > > > > > > > > > > Good news: 8 repositories fixed > > > > > > > > > > > > > > Bad news: 6 new repositories started failing > > > > > > > > > > > > > > > > > > > > > kio-gdrive - NEW > > > > > > > > > > > > > > * > https://invent.kde.org/network/kio-gdrive/-/pipelines/693840 > > > > > > > > > > > > > > * Qt 5.15 is unbuildable because needs libkgapi and we don't > > > > > > have a > > > > > > > > Qt5 > > > > > > > > > > > > CI > > > > > > > build of libkgapi anymore. This is REAL BAD. > > > > > > > > > > > > Looks like kio-gdrive needs to drop the support it has for Qt 5? > > > > > > Can't really see another path forward as libkgapi has no support > for > > > > > > Qt > > > > > > > > > 5 > > > > > > anymore. > > > > > > > > > > > > This is alas one of those very difficult to solve issues, > especially > > > > > > when > > > > > > semi-leaf projects like libkgapi are used more widely. > > > > > > > > > > Would it work to have a kf5 branch rule for libkgapi pointing to > the > > > > > > last > > > > > > > > branch with Qt 5 support (and similar for all its dependencies)? > > > > > > > > Unfortunately not possible i'm afraid - as release/23.08 is no longer > > > > supported (as no further releases are being made). > > > > I therefore terminated all CI support for that branch to ensure that > any > > > > issues like this one were forced to the surface. > > > > > > But do we actually need CI for libkgapi for this? We only need it > > > available as > > > a dependency, so theoretically even distro packages in the CI image > would > > > work > > > (I'm very reluctant to try that though, as that might have all kinds of > > > surprising side-effects due to whatever else that might pull in (e.g. > > > ECM)). > > > Therefore the idea to let the seed job provide it, by means of a kf5 > > > branch > > > rule. > > > > Distribution packages definitely won't work :) > > > > Unfortunately the seed jobs can't help here, as the entirety of > > release/23.08 has been dropped from the CI system. > > There are also rules in place to continually re-drop any release/23.08 > > packages that do appear in the system. > > ah, so the problem isn't that the seed job wouldn't be able to build this, > but > the result wont be persisted? > Correct. That is assuming that libkgapi doesn't have any other dependencies within KDE Gear of course. > > Next idea: add a kf5 branch to libkgapi, pointing to the latest > release/23.08 > state, and change the branch rules accordingly. We did that for a few non- > branched repos during the transition period of their (branched) consumers > IIRC > (e.g. kweathercore, kirigami-addons). > This would work totally fine. For distributions, do we have any kind of release plan for this as they will need this in order to be able to build kio-gdrive? > > > > > The dependency chain is also @same as both are part of KDE Gear so > from > > > > a > > > > technical perspective that doesn't work either. > > > > > > It's @stable and @latest-kf6 depending on the Qt version in kio-gdrive, > > > and > > > inside libkgapi it's @latest for its KF5 de
Re: Migrating Windows CI to Qt 6.7 - Roadblocks
On Sun, May 26, 2024 at 12:22 AM wrote: > On 2024-05-25 10:06, Volker Krause wrote: > > On Samstag, 25. Mai 2024 05:40:26 CEST Ben Cooksley wrote: > >> Hi all, > >> > >> Been looking into what is needed to migrate Windows CI over to Qt 6.7 > >> this > >> afternoon and alas have run into a few roadblocks, related to > >> QDBusConnection. > >> > >> https://invent.kde.org/sysadmin/ci-management/-/jobs/1848501 > >> https://invent.kde.org/sysadmin/ci-management/-/jobs/1848502 > >> > >> Not entirely sure why, but it seems that something in the way headers > >> are > >> installed for QtDBus has changed for 6.7 and Dolphin and kio-extras > >> are now > >> unhappy. > > > > The 6.6 CI already shows this, it's rather fallout from recent changes > > in KIO > > I think. > > > >> Could someone take a look please? > > > > Dolphin: > > https://invent.kde.org/system/dolphin/-/merge_requests/780 > > > > kio-extras was fixed by Nico yesterday already but those changes aren't > > backported yet. > > Hi, > > Thanks, you were faster than me. > > Now that frameworks is QDBus free on Windows and macOS I would even > propose that in a next update of the stuff we really not have QtDBus > around at all on these systems and make the use optional for the apps > that want to support them. > > We go to great lengths to avoid that dbus stuff is ever called, even > deleting the dll and the most freezes you will get if that is not done > is just dbus related. > > It would be great if people could join the effort to get that right. > > https://invent.kde.org/packaging/craft-blueprints-kde/-/issues/17 I've said for a number of years that the non-desktop platforms (ie. non-Linux / FreeBSD) really shouldn't have any D-Bus support at all. I would be happy to support removing availability of D-Bus on those platforms CI next time we update (ie. the change to Qt 6.8) as long as the necessary binaries are available naturally. Not sure how this will go for some applications as I think some explicitly rely on D-Bus for certain functionality? (that should really be replaced with something else though) > > > Greetings > Christoph > Cheers, Ben > > > > > > Regards, > > Volker >
Re: KDE Gear projects with failing CI (master) (21 May 2024)
On Sat, May 25, 2024 at 3:09 AM Volker Krause wrote: > On Freitag, 24. Mai 2024 12:24:16 CEST Ben Cooksley wrote: > > On Fri, May 24, 2024 at 4:13 AM Volker Krause wrote: > > > On Mittwoch, 22. Mai 2024 10:27:07 CEST Ben Cooksley wrote: > > > > On Wed, May 22, 2024 at 9:24 AM Albert Astals Cid > wrote: > > > > > Please work on fixing them, otherwise i will remove the failing CI > > > > > > jobs on > > > > > > > > their 4th failing week, it is very important that CI is passing for > > > > > multiple > > > > > reasons. > > > > > > > > > > Good news: 8 repositories fixed > > > > > > > > > > Bad news: 6 new repositories started failing > > > > > > > > > > > > > > > kio-gdrive - NEW > > > > > > > > > > * https://invent.kde.org/network/kio-gdrive/-/pipelines/693840 > > > > > > > > > > * Qt 5.15 is unbuildable because needs libkgapi and we don't > have a > > > > > > Qt5 > > > > > > > > CI > > > > > build of libkgapi anymore. This is REAL BAD. > > > > > > > > Looks like kio-gdrive needs to drop the support it has for Qt 5? > > > > Can't really see another path forward as libkgapi has no support for > Qt > > > > 5 > > > > anymore. > > > > > > > > This is alas one of those very difficult to solve issues, especially > > > > when > > > > semi-leaf projects like libkgapi are used more widely. > > > > > > Would it work to have a kf5 branch rule for libkgapi pointing to the > last > > > branch with Qt 5 support (and similar for all its dependencies)? > > > > Unfortunately not possible i'm afraid - as release/23.08 is no longer > > supported (as no further releases are being made). > > I therefore terminated all CI support for that branch to ensure that any > > issues like this one were forced to the surface. > > But do we actually need CI for libkgapi for this? We only need it > available as > a dependency, so theoretically even distro packages in the CI image would > work > (I'm very reluctant to try that though, as that might have all kinds of > surprising side-effects due to whatever else that might pull in (e.g. > ECM)). > Therefore the idea to let the seed job provide it, by means of a kf5 > branch > rule. > Distribution packages definitely won't work :) Unfortunately the seed jobs can't help here, as the entirety of release/23.08 has been dropped from the CI system. There are also rules in place to continually re-drop any release/23.08 packages that do appear in the system. > > > The dependency chain is also @same as both are part of KDE Gear so from a > > technical perspective that doesn't work either. > > It's @stable and @latest-kf6 depending on the Qt version in kio-gdrive, > and > inside libkgapi it's @latest for its KF5 dependencies, which seems correct > IIUC? > @stable for the relationship between libkgapi and kio-gdrive isn't correct as they're both within KDE Gear no? > > > From a practical perspective, i'm not sure you can really release > something > > as part of a bundle that needs something from an older release of that > same > > bundle in order to build... > > We already have that mixed scenario anyway in 24.02 it seems, so that is > apparently working. > I'm only aware of one case where that happened, which was a special one off as KF5 apps needed the Qt 5 plugins still? (I think this was kio-extras) Perhaps we need to ask distributions to treat kio-gdrive the same? > > > The only fix is to either drop Qt 5 support from kio-gdrive, or to > restore > > Qt 5 support to libkgapi. > > Don't get me wrong, I'm all for retiring Qt5 stuff as soon as we can, but > I > fear this isn't the only place where we will hit this problem, and not all > of > those might be able to do that just yet. > In an ideal world, applications (the leaves) would drop Qt 5 support first, and then once all consumers had migrated away the libraries would start dropping support. Not sure why libkgapi had to rush to drop Qt 5 > > Regards, > Volker Cheers, Ben
Re: Migrating Windows CI to Qt 6.7 - Roadblocks
On Sat, May 25, 2024 at 10:52 PM wrote: > On 2024-05-25 05:40, Ben Cooksley wrote: > > Hi all, > > > > Been looking into what is needed to migrate Windows CI over to Qt 6.7 > > this afternoon and alas have run into a few roadblocks, related to > > QDBusConnection. > > > > https://invent.kde.org/sysadmin/ci-management/-/jobs/1848501 > > > > https://invent.kde.org/sysadmin/ci-management/-/jobs/1848502 > > > > Not entirely sure why, but it seems that something in the way headers > > are installed for QtDBus has changed for 6.7 and Dolphin and > > kio-extras are now unhappy. > > > > Could someone take a look please? > > I think the issue is that most of our frameworks no longer requires dbus > on Windows and these apps/plugins did miss to > add explicit cmake finds/use of QDBus. > Ouch, yes that would cause it. Understandable that we're cleaning that up, just not ideal timing :) > > I can patch that in master, actually even better I patch the use out on > that systems. > > If we need that in stable, one will need to backport that, did it > already for Kate. > If we could ensure the necessary fixes land on both master and stable that would be good - not so sure about Dolphin but i'm pretty sure kio-extras at least is used somewhere in the dependency stack as a build time dependency. > > Greetings > Christoph > Thanks, Ben > > > > > > Thanks, > > Ben >
Migrating Windows CI to Qt 6.7 - Roadblocks
Hi all, Been looking into what is needed to migrate Windows CI over to Qt 6.7 this afternoon and alas have run into a few roadblocks, related to QDBusConnection. https://invent.kde.org/sysadmin/ci-management/-/jobs/1848501 https://invent.kde.org/sysadmin/ci-management/-/jobs/1848502 Not entirely sure why, but it seems that something in the way headers are installed for QtDBus has changed for 6.7 and Dolphin and kio-extras are now unhappy. Could someone take a look please? Thanks, Ben
[bugs.kde.org] [Bug 487450] Long URIs cause bug information to rendered off-screen.
https://bugs.kde.org/show_bug.cgi?id=487450 Ben Cooksley changed: What|Removed |Added Latest Commit||https://invent.kde.org/webs ||ites/bugs-kde-org/-/commit/ ||309d942fdb3425890abc61c2189 ||b9b45570b7918 Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #3 from Ben Cooksley --- Git commit 309d942fdb3425890abc61c2189b9b45570b7918 by Ben Cooksley. Committed on 24/05/2024 at 10:50. Pushed by bcooksley into branch 'kde-5.0'. Fix display of Long URIs on show_bug.cgi. M +8-0skins/standard/additions/global.css https://invent.kde.org/websites/bugs-kde-org/-/commit/309d942fdb3425890abc61c2189b9b45570b7918 -- You are receiving this mail because: You are watching all bug changes.
Re: KDE Gear projects with failing CI (master) (21 May 2024)
On Fri, May 24, 2024 at 4:13 AM Volker Krause wrote: > On Mittwoch, 22. Mai 2024 10:27:07 CEST Ben Cooksley wrote: > > On Wed, May 22, 2024 at 9:24 AM Albert Astals Cid wrote: > > > Please work on fixing them, otherwise i will remove the failing CI > jobs on > > > their 4th failing week, it is very important that CI is passing for > > > multiple > > > reasons. > > > > > > Good news: 8 repositories fixed > > > > > > Bad news: 6 new repositories started failing > > > > > > > > > kio-gdrive - NEW > > > > > > * https://invent.kde.org/network/kio-gdrive/-/pipelines/693840 > > > > > > * Qt 5.15 is unbuildable because needs libkgapi and we don't have a > Qt5 > > > > > > CI > > > build of libkgapi anymore. This is REAL BAD. > > > > Looks like kio-gdrive needs to drop the support it has for Qt 5? > > Can't really see another path forward as libkgapi has no support for Qt 5 > > anymore. > > > > This is alas one of those very difficult to solve issues, especially when > > semi-leaf projects like libkgapi are used more widely. > > Would it work to have a kf5 branch rule for libkgapi pointing to the last > branch with Qt 5 support (and similar for all its dependencies)? Unfortunately not possible i'm afraid - as release/23.08 is no longer supported (as no further releases are being made). I therefore terminated all CI support for that branch to ensure that any issues like this one were forced to the surface. The dependency chain is also @same as both are part of KDE Gear so from a technical perspective that doesn't work either. >From a practical perspective, i'm not sure you can really release something as part of a bundle that needs something from an older release of that same bundle in order to build... The only fix is to either drop Qt 5 support from kio-gdrive, or to restore Qt 5 support to libkgapi. > > > Regards, > Volker > Cheers, Ben
Re: KDE Gear projects with failing CI (master) (21 May 2024)
On Wed, May 22, 2024 at 9:24 AM Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for > multiple > reasons. > > Good news: 8 repositories fixed > > Bad news: 6 new repositories started failing > > > kio-gdrive - NEW > * https://invent.kde.org/network/kio-gdrive/-/pipelines/693840 > * Qt 5.15 is unbuildable because needs libkgapi and we don't have a Qt5 > CI > build of libkgapi anymore. This is REAL BAD. > Looks like kio-gdrive needs to drop the support it has for Qt 5? Can't really see another path forward as libkgapi has no support for Qt 5 anymore. This is alas one of those very difficult to solve issues, especially when semi-leaf projects like libkgapi are used more widely. > > > massif-visualizer - NEW > * https://invent.kde.org/sdk/massif-visualizer/-/pipelines/693832 > * appstreamtest fails because https://apps.kde.org/massif-visualizer > doesn't > exist > > > baloo-widgets - NEW > * https://invent.kde.org/libraries/baloo-widgets/-/pipelines/693837 > * filemetadataitemcounttest failed in Linux Qt 6.7 > > > tokodon - NEW > * https://invent.kde.org/network/tokodon/-/pipelines/693844 > * TimelineTest failed in Linux Qt 6.7 > > > okular - NEW > * https://invent.kde.org/graphics/okular/-/pipelines/693821 > * craft mac and windows failed, possibly in codesign? > > > kdenlive - NEW > * https://invent.kde.org/multimedia/kdenlive/-/pipelines/693822 > * craft windows failed, possibly in codesign? > * craft mac has been stuck for hours, builder down? > > > > Cheers, > Albert > Cheers, Ben
Re: Where to find build logs of cached packages
On Thu, May 16, 2024 at 6:12 PM Thomas Friedrichsmeier < thomas.friedrichsme...@kdemail.net> wrote: > Hi! > Hi Thomas, > > Where would I find the actual build log for a package in the binary > cache? > > (Looking specifically for libs/qt6/qtwebengine to further understand bug > #486905) > I'd suggest looking through the artifacts and build logs of the various Craft jobs at invent.kde.org/sysadmin/ci-management/ to see those. > > Regards > Thomas > Cheers, Ben
[bugs.kde.org] [Bug 487087] want to delete my account of bugs.kde.org
https://bugs.kde.org/show_bug.cgi?id=487087 Ben Cooksley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Ben Cooksley --- Account has now been closed. -- You are receiving this mail because: You are watching all bug changes.
[bugs.kde.org] [Bug 487087] want to delete my account of bugs.kde.org
https://bugs.kde.org/show_bug.cgi?id=487087 Ben Cooksley changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|ASSIGNED --- Comment #1 from Ben Cooksley --- This is the last email you will receive from Bugzilla. Account removal is an admin only action. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 411585] KDevelop always segfaults when indexing my project
https://bugs.kde.org/show_bug.cgi?id=411585 --- Comment #1 from Ben Cooksley --- The content of attachment 122484 has been deleted for the following reason: Removed due to complaint from original poster -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 400984] KDevelop 5.3.0 hangs randomly
https://bugs.kde.org/show_bug.cgi?id=400984 --- Comment #2 from Ben Cooksley --- The content of attachment 116269 has been deleted for the following reason: Removed due to complaint from original poster -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 410731] UI freezes multiple times
https://bugs.kde.org/show_bug.cgi?id=410731 --- Comment #2 from Ben Cooksley --- The content of attachment 122016 has been deleted for the following reason: Removed due to complaint from original poster -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 400769] Crash and unusual behavior after upgrading KDevelop to 5.3.0 [crash in Clazy::JobParameters::JobParameters]
https://bugs.kde.org/show_bug.cgi?id=400769 --- Comment #14 from Ben Cooksley --- The content of attachment 116146 has been deleted for the following reason: Removed due to complaint from original poster -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 417919] KDE Neon 5.18.1 crashes on startup
https://bugs.kde.org/show_bug.cgi?id=417919 --- Comment #6 from Ben Cooksley --- The content of attachment 126198 has been deleted for the following reason: Removed due to complaint from original poster -- You are receiving this mail because: You are watching all bug changes.
Re: CI moved to Qt 6.7 for Linux builds
On Wed, May 8, 2024 at 11:22 PM Kai Uwe Broulik wrote: > Hi, > HI Kai, > > (only posting to plasma-devel only below is about Plasma) > > > i'd also like to schedule removing CI support for [...] Plasma/5.27 > > Plasma 5.27 is our LTS release and we’ve just had Kubuntu 24.04 ship > with it. I’m also aware of at least one other major deployment that’s > also on 5.27 for the forseeable time. > > I think we need to keep this around for at least another year, maybe > longer, so we can still backport important fixes and do a few more 5.27 > releases. One year of support isn’t exactly “LTS” imho particularly with > a major version jump. Think of how long Qt 5.15 has been around and > still will be in the industry. > The problem I see with this is that if you head to https://invent.kde.org/teams/ci-artifacts/suse-qt5.15/-/packages? you will find that the Plasma packages were last rebuilt 5-6 months ago by and large. This doesn't look terribly active to me / something receiving much in the way of release activity? > > Cheers > Kai Uwe > > PS: Though we should probably disable this stupid appstream test on 5.27 > Yes, that test drives many of us crazy. Cheers, Ben
Re: KDE Gear projects with failing CI (master) (7 May 2024)
On Wed, May 8, 2024 at 10:03 AM Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for > multiple > reasons. > > > Bad news: 1 repository is still failing and 3 new ones started failing > > > tokodon - 3rd week > * https://invent.kde.org/network/tokodon/-/pipelines/682294 > * suse_tumbleweed_qt67 fails > This looks to be a broken test that is relying on the selenium-webdriver-at-spi scaffolding (that i've warned against previously) and crashing for reasons not quite known. It is unlikely you will see this on a developer system as the CI system compiles everything in Debug mode (which means asserts are enabled) while developer systems won't have them enabled (due to using RelWithDebInfo). Probably best to just disable that test. > > kdenlive - NEW > * https://invent.kde.org/multimedia/kdenlive/-/pipelines/682483 > * craft_windows_qt6_x86_64 fails to compile kdenlivesettingsdialog.cpp > > > dolphin - NEW > * https://invent.kde.org/system/dolphin/-/pipelines/682230 > * craft_windows_qt6_x86_64 fails without any discernible error > > > kdeconnect-kde - NEW > * https://invent.kde.org/network/kdeconnect-kde/-/pipelines/682282 > * craft_windows_qt6_x86_64 fails without any discernible error > > > Cheers, > Albert > Cheers, Ben
Re: KDE Gear projects with failing CI (release/24.05) (7 May 2024)
On Wed, May 8, 2024 at 7:19 PM Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for > multiple > reasons. > > Bad news: 9 repositories have started failing and 1 is still failing > > > cantor - 3rd week > * https://invent.kde.org/education/cantor/-/pipelines/676922 > * suse_tumbleweed_qt515 and windows_qt515 tests fail > > > tokodon - NEW > * https://invent.kde.org/network/tokodon/-/pipelines/682468 > * craft android fails > Will be fixed by https://invent.kde.org/packaging/craft-blueprints-kde/-/merge_requests/833 > > > kimap - NEW > * https://invent.kde.org/pim/kimap/-/pipelines/682429 > * freebsd tests fail > Do we know what this test is trying to do and what hostname it is assuming is invalid? > > > kig - NEW > * https://invent.kde.org/education/kig/-/pipelines/682321 > * craft_macos_x86_64 fails to compile Qt5 > > > gwenview - NEW > * https://invent.kde.org/graphics/gwenview/-/pipelines/682335 > * flatpak fails to compile > The Flatpak job likely needs to depend on a more stable tarball > > > craft_windows_qt6_x86_64 broken in several repos: no easy to understand > error > * https://invent.kde.org/utilities/kate/-/pipelines/682305 > * https://invent.kde.org/system/dolphin/-/pipelines/682309 > * https://invent.kde.org/graphics/okular/-/pipelines/682346 > * https://invent.kde.org/utilities/filelight/-/pipelines/682349 > * https://invent.kde.org/network/neochat/-/pipelines/682465 All fixed by Ingo restarting the signer process. > > > > Cheers, > Albert > Cheers, Ben
Re: KDE Frameworks with failing CI (master) (5 May 2024)
On Sun, May 5, 2024 at 10:50 PM Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for > multiple > reasons. > > Good news: 1 repo was fixed > > Bad news: 2 repo started failing > > kimageformats: > * https://invent.kde.org/frameworks/kimageformats/-/pipelines/680495 > * andoid fails >* Needs a newer ECM than what the Andoid CI has > > The .kde-ci.yml file for this is broken, it does not list Android as a supported platform and therefore is receiving the ECM from the image rather than from the CI builds directly. Will be fixed by https://invent.kde.org/frameworks/kimageformats/-/merge_requests/217 > > kuserfeedback: > * https://invent.kde.org/frameworks/kuserfeedback/-/pipelines/680497 > * flatpak fails >* Needs a newer ECM than what flatpak SDK has > > > Cheers, > Albert > Cheers, Ben
Re: RFC: Theming and styles of KDE applications
On Sun, May 5, 2024 at 8:37 AM wrote: > On 2024-05-04 21:56, Akseli Lahtinen wrote: > > On Saturday 4 May 2024 14:47:35 GMT+3 christ...@cullmann.io wrote: > >> My proposal: we enforce Breeze as icon set and style everywhere. And > >> we > >> provide still a way to overwrite that for the user, but if the user > >> didn't set something manually, idenpendent what the system propose, > >> we > >> just use Breeze. And we depend on that as dep e.g. in Kate, if you > >> install Kate, that icon set and theme is installed. > > > > +1. For me as someone who changes icons sometimes just to see and > > tinker > > around, > > i think this makes sense. We have reliable fallback, but we still allow > > users to customize things which is, well, our thing! :) > > > > And if the custom icons break i do not end up with broken apps, so > > i really do not see any downside here, as user or dev perspective. > > Yes, if some user switches a theme or style in our system settings > or in the application (like we do it with the color scheme switcher some > applications like Kate have) that is fine. > > But beside that, we should just force our default style and icon set, > like we do on Windows and macOS already, that will even make some > patches > and ifdef's useless we need now to sprinkle in all apps we really > support on > these platforms. > Definitely agree with this, having to add special handling to every application to get a good experience on that platform is not ideal. Having our Frameworks handle this in one place, with a consistent approach, will overall improve the quality of the experience users get with our software outside of a Plasma desktop environment (and reduce developer porting workload) - and might help break some of the age-old stigma that KDE apps have to be used with a KDE desktop environment. > > Greetings > Christoph > Cheers, Ben > > > > > - Akseli > > > > ps. I am bad with mailing lists, lets hope this sends to right place > > lol >
Re: RFC: Theming and styles of KDE applications
On Sun, May 5, 2024 at 8:37 AM wrote: > On 2024-05-04 21:56, Akseli Lahtinen wrote: > > On Saturday 4 May 2024 14:47:35 GMT+3 christ...@cullmann.io wrote: > >> My proposal: we enforce Breeze as icon set and style everywhere. And > >> we > >> provide still a way to overwrite that for the user, but if the user > >> didn't set something manually, idenpendent what the system propose, > >> we > >> just use Breeze. And we depend on that as dep e.g. in Kate, if you > >> install Kate, that icon set and theme is installed. > > > > +1. For me as someone who changes icons sometimes just to see and > > tinker > > around, > > i think this makes sense. We have reliable fallback, but we still allow > > users to customize things which is, well, our thing! :) > > > > And if the custom icons break i do not end up with broken apps, so > > i really do not see any downside here, as user or dev perspective. > > Yes, if some user switches a theme or style in our system settings > or in the application (like we do it with the color scheme switcher some > applications like Kate have) that is fine. > > But beside that, we should just force our default style and icon set, > like we do on Windows and macOS already, that will even make some > patches > and ifdef's useless we need now to sprinkle in all apps we really > support on > these platforms. > Definitely agree with this, having to add special handling to every application to get a good experience on that platform is not ideal. Having our Frameworks handle this in one place, with a consistent approach, will overall improve the quality of the experience users get with our software outside of a Plasma desktop environment (and reduce developer porting workload) - and might help break some of the age-old stigma that KDE apps have to be used with a KDE desktop environment. > > Greetings > Christoph > Cheers, Ben > > > > > - Akseli > > > > ps. I am bad with mailing lists, lets hope this sends to right place > > lol >
Re: KDE Gear projects with failing CI (master) (30 April 2024)
On Wed, May 1, 2024 at 12:57 PM Nicolas Fella wrote: > On 01.05.24 01:54, Albert Astals Cid wrote: > > Please work on fixing them, otherwise i will remove the failing CI jobs > on > > their 4th failing week, it is very important that CI is passing for > multiple > > reasons. > > > > > > Good news: 4 repositories got fixed > > > > Bad news: 1 repository is still failing > > > > > > tokodon - 2nd week > > * https://invent.kde.org/network/tokodon/-/pipelines/676920 > >* suse_tumbleweed_qt67 fails > Triggering a rebuild of selenium-webdriver-at-spi seems to have fixed it > Unfortunately selenium-webdriver-at-spi has a number of dependency tree problems associated with it (largely related to it requiring KWin master rather than using a generic window manager as the rest of CI does). I'd therefore recommend against making use of it as doing so may result in a contaminated CI environment for your project, with the corresponding test failures, etc. that go along with it. Cheers, Ben
Re: KDE Frameworks with failing CI (master) (28 April 2024)
On Sun, Apr 28, 2024 at 9:23 PM Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for > multiple > reasons. > > Bad news: 1 repo started failing > > kconfig: > * https://invent.kde.org/frameworks/kconfig/-/pipelines/675292 > * kconfigcore-kdesktopfiletest fails on Linux > * windows fails to compile >* There have not been changes lately? Qt/ECM regressions? > These are not Qt regressions, as Qt is provided by the image and the Windows image hasn't been rebuilt in weeks. CMake is the same. They must be regressions within KConfig or ECM. > > Cheers, > Albert > Cheers, Ben
[bugs.kde.org] [Bug 481077] delete account
https://bugs.kde.org/show_bug.cgi?id=481077 Ben Cooksley changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #5 from Ben Cooksley --- This account has now been closed. -- You are receiving this mail because: You are watching all bug changes.
[bugs.kde.org] [Bug 481077] delete account
https://bugs.kde.org/show_bug.cgi?id=481077 --- Comment #4 from Ben Cooksley --- Please don't hijack others closed reports. I'll process this removal shortly. -- You are receiving this mail because: You are watching all bug changes.
[www.kde.org] [Bug 485961] KDE Subversion site references non-existent review board URI.
https://bugs.kde.org/show_bug.cgi?id=485961 Ben Cooksley changed: What|Removed |Added Resolution|--- |INTENTIONAL Status|REPORTED|RESOLVED --- Comment #4 from Ben Cooksley --- Yeah, in this case we'll leave it in place for historical accuracy as it isn't harming anything. -- You are receiving this mail because: You are watching all bug changes.
[www.kde.org] [Bug 485960] Trying to sign in to the Akademy Volunteers site caused the site to crash.
https://bugs.kde.org/show_bug.cgi?id=485960 Ben Cooksley changed: What|Removed |Added Summary|Signing in to the Akademy |Trying to sign in to the |login page caused the site |Akademy Volunteers site |to crash. |caused the site to crash. --- Comment #2 from Ben Cooksley --- The site is currently not in use (wasn't used at the last two Akademy's I believe) so not sure whether we'll need to bring it into operation. -- You are receiving this mail because: You are watching all bug changes.
[www.kde.org] [Bug 485961] KDE Subversion site references non-existent review board URI.
https://bugs.kde.org/show_bug.cgi?id=485961 --- Comment #2 from Ben Cooksley --- Subversion is by-and-large deprecated and no longer in use except for translations. As translations don't use code review tools not sure what the harm of this is? -- You are receiving this mail because: You are watching all bug changes.
Mailing list unsubscription incident
Hi all, It has been brought to Sysadmin's attention that a number of subscribers to the konsole-devel mailing list were automatically unsubscribed from the list in the past few days. This was an action taken correctly by the system, albeit in error due to a number of badly formed emails that were sent to the list. These badly formed emails originated from KDE Bugzilla, and ended up being badly formed as a result of a user with a uniquely formatted name that contained a JSON string that was improperly handled by Bugzilla. The users name has now been expunged from their Bugzilla account to avoid continued repeats of this incident. If someone who has a degree of expertise with Perl (and familiarity with it's Email modules in particular, as the bug appears to be within those) and would like to assist with correcting this please contact Sysadmin. In the long term we expect this issue to be resolved as part of work Bugzilla upstream are currently doing (see https://www.bugzilla.org/blog/2023/08/26/bugzilla-celebrates-25-years/) Thanks, Ben
CI moved to Qt 6.7 for Linux builds
Hi all, I have just flipped the switch that has moved the CI system over to using Qt 6.7 for Linux builds on our SUSE images. Should you see any issues with builds failing as a result of packages being missing in the registry then please submit a merge request to sysadmin/ci-management to ensure that build dependency is added to our seed jobs. I'll leave the Qt 6.6 package registry and container images in place for another week or so then will schedule them for removal. As part of this I have also updated the list of projects with Qt 6 only master branches. Any residual Qt 5 build artifacts the CI system was holding for those projects have now been purged, which may impact downstream projects that depend on those projects that are still on Qt 5. On an adjacent note, i'd also like to schedule removing CI support for release/23.08 and Plasma/5.27 builds (by purging all their binaries we currently hold) for the Qt 5.15 series. While checking however I note that several projects still have activity on those branches. Can we please confirm whether any further releases are expected, as i'd prefer to remove anything that isn't being properly maintained anymore. Thanks, Ben
CI moved to Qt 6.7 for Linux builds
Hi all, I have just flipped the switch that has moved the CI system over to using Qt 6.7 for Linux builds on our SUSE images. Should you see any issues with builds failing as a result of packages being missing in the registry then please submit a merge request to sysadmin/ci-management to ensure that build dependency is added to our seed jobs. I'll leave the Qt 6.6 package registry and container images in place for another week or so then will schedule them for removal. As part of this I have also updated the list of projects with Qt 6 only master branches. Any residual Qt 5 build artifacts the CI system was holding for those projects have now been purged, which may impact downstream projects that depend on those projects that are still on Qt 5. On an adjacent note, i'd also like to schedule removing CI support for release/23.08 and Plasma/5.27 builds (by purging all their binaries we currently hold) for the Qt 5.15 series. While checking however I note that several projects still have activity on those branches. Can we please confirm whether any further releases are expected, as i'd prefer to remove anything that isn't being properly maintained anymore. Thanks, Ben
CI moved to Qt 6.7 for Linux builds
Hi all, I have just flipped the switch that has moved the CI system over to using Qt 6.7 for Linux builds on our SUSE images. Should you see any issues with builds failing as a result of packages being missing in the registry then please submit a merge request to sysadmin/ci-management to ensure that build dependency is added to our seed jobs. I'll leave the Qt 6.6 package registry and container images in place for another week or so then will schedule them for removal. As part of this I have also updated the list of projects with Qt 6 only master branches. Any residual Qt 5 build artifacts the CI system was holding for those projects have now been purged, which may impact downstream projects that depend on those projects that are still on Qt 5. On an adjacent note, i'd also like to schedule removing CI support for release/23.08 and Plasma/5.27 builds (by purging all their binaries we currently hold) for the Qt 5.15 series. While checking however I note that several projects still have activity on those branches. Can we please confirm whether any further releases are expected, as i'd prefer to remove anything that isn't being properly maintained anymore. Thanks, Ben
CI moved to Qt 6.7 for Linux builds
Hi all, I have just flipped the switch that has moved the CI system over to using Qt 6.7 for Linux builds on our SUSE images. Should you see any issues with builds failing as a result of packages being missing in the registry then please submit a merge request to sysadmin/ci-management to ensure that build dependency is added to our seed jobs. I'll leave the Qt 6.6 package registry and container images in place for another week or so then will schedule them for removal. As part of this I have also updated the list of projects with Qt 6 only master branches. Any residual Qt 5 build artifacts the CI system was holding for those projects have now been purged, which may impact downstream projects that depend on those projects that are still on Qt 5. On an adjacent note, i'd also like to schedule removing CI support for release/23.08 and Plasma/5.27 builds (by purging all their binaries we currently hold) for the Qt 5.15 series. While checking however I note that several projects still have activity on those branches. Can we please confirm whether any further releases are expected, as i'd prefer to remove anything that isn't being properly maintained anymore. Thanks, Ben
CI moved to Qt 6.7 for Linux builds
Hi all, I have just flipped the switch that has moved the CI system over to using Qt 6.7 for Linux builds on our SUSE images. Should you see any issues with builds failing as a result of packages being missing in the registry then please submit a merge request to sysadmin/ci-management to ensure that build dependency is added to our seed jobs. I'll leave the Qt 6.6 package registry and container images in place for another week or so then will schedule them for removal. As part of this I have also updated the list of projects with Qt 6 only master branches. Any residual Qt 5 build artifacts the CI system was holding for those projects have now been purged, which may impact downstream projects that depend on those projects that are still on Qt 5. On an adjacent note, i'd also like to schedule removing CI support for release/23.08 and Plasma/5.27 builds (by purging all their binaries we currently hold) for the Qt 5.15 series. While checking however I note that several projects still have activity on those branches. Can we please confirm whether any further releases are expected, as i'd prefer to remove anything that isn't being properly maintained anymore. Thanks, Ben
Please cleanup old forks
Hi all, As part of routine maintenance on Invent (Gitlab) i've been reviewing the total amount of space currently being consumed by repositories. At this time, the top 100 largest repositories on Invent (we have 14,000 or so for context) are consuming around 21% of the total space. It would therefore be good if we could please clean this up. To add a bit of context, we currently have around 140GB of repositories, and a further 30GB of pooled repository data (shared among the canonical repository and it's forks). Those top 100 repositories currently use 30GB of space - so as much as all of the pools. Forks of KDevelop and docs-krita-org feature heavily on the list of large repositories. Of particular interest are old forks (created more than 2-3 years ago) as these are often not participating in Gitlab's mechanism to reduce the disk space taken by forks (known as pool repositories). As an additional note: please do not fork a fork, as these forks-of-forks cannot participate in a pool and must carry a full copy of the upstream repository data. If you have a situation where a network of forks of forks has developed please consider options to resolve this. I know Krita at least has this situation presently with their fork of various parts of Qt that is being maintained in people's personal namespaces. Thanks, Ben
Please cleanup old forks
Hi all, As part of routine maintenance on Invent (Gitlab) i've been reviewing the total amount of space currently being consumed by repositories. At this time, the top 100 largest repositories on Invent (we have 14,000 or so for context) are consuming around 21% of the total space. It would therefore be good if we could please clean this up. To add a bit of context, we currently have around 140GB of repositories, and a further 30GB of pooled repository data (shared among the canonical repository and it's forks). Those top 100 repositories currently use 30GB of space - so as much as all of the pools. Forks of KDevelop and docs-krita-org feature heavily on the list of large repositories. Of particular interest are old forks (created more than 2-3 years ago) as these are often not participating in Gitlab's mechanism to reduce the disk space taken by forks (known as pool repositories). As an additional note: please do not fork a fork, as these forks-of-forks cannot participate in a pool and must carry a full copy of the upstream repository data. If you have a situation where a network of forks of forks has developed please consider options to resolve this. I know Krita at least has this situation presently with their fork of various parts of Qt that is being maintained in people's personal namespaces. Thanks, Ben
Please cleanup old forks
Hi all, As part of routine maintenance on Invent (Gitlab) i've been reviewing the total amount of space currently being consumed by repositories. At this time, the top 100 largest repositories on Invent (we have 14,000 or so for context) are consuming around 21% of the total space. It would therefore be good if we could please clean this up. To add a bit of context, we currently have around 140GB of repositories, and a further 30GB of pooled repository data (shared among the canonical repository and it's forks). Those top 100 repositories currently use 30GB of space - so as much as all of the pools. Forks of KDevelop and docs-krita-org feature heavily on the list of large repositories. Of particular interest are old forks (created more than 2-3 years ago) as these are often not participating in Gitlab's mechanism to reduce the disk space taken by forks (known as pool repositories). As an additional note: please do not fork a fork, as these forks-of-forks cannot participate in a pool and must carry a full copy of the upstream repository data. If you have a situation where a network of forks of forks has developed please consider options to resolve this. I know Krita at least has this situation presently with their fork of various parts of Qt that is being maintained in people's personal namespaces. Thanks, Ben
Re: Proposal unify back our release schedules
On Sun, Apr 21, 2024 at 1:51 AM Kevin Ottens wrote: > Hello, > > On Saturday 20 April 2024 15:12:48 CEST Ingo Klöcker wrote: > > On Freitag, 19. April 2024 22:40:38 CEST Ben Cooksley wrote: > > > On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens wrote: > > > > The example you give shows Plasma depending on Gear, this shouldn't > > > > happen, so > > > > I'd argue: let's fix that instead. > > > > In my opinion the same goes for Gear depending on Plasma. > > Agreed, just didn't want to muddy my message and so focused on only one > direction. But it's definitely a topic to explore as well. > > One thing I'm unsure for instance is: do we want to make Gear -> Plasma > dependencies completely forbidden? > > We might consider this going one step too far. I could understand if a > Gear > app wants to provide "more integration" in a Plasma session. So mandatory > Gear > -> Plasma dependencies, I agree are to forbid, but optional ones? I'm less > certain. > I've considered whether it was feasible to ban such dependencies in the past, however always ended up in the position that it wasn't feasible to do so. This will require a degree of projects being moved around, code being broken out into separate modules, etc. but I think it is solvable given enough commitment to do so. We probably need a home for "not quite Frameworks but shared libraries none the less" to make this achievable. The usual tripping points ended up being: - Various graphics and multimedia libraries such as libkdcraw, libkexiv2, etc - Various PIM libraries, often related to Akonadi integration for Workspace - Components of Workspace that were sitting over in Gear, such as Baloo (which shouldn't be used anywhere outside Plasma - yet is heavily integrated in Dolphin, which arguably really belongs in Plasma not Gear as well) - Applications that published components and libraries that were reusable by others such as Marble, Kompare and Okteta. - Addon collections that due to shared D-Bus interfaces ended up being both build and runtime dependencies (less so now, but kio-extras sits in this territory to a certain extent) - Components of Workspace, such as KSysguard that provide libraries whose functionality is used I'm not sure where KWin sits these days, but it's hard (and I mean very hard) dependency on KWindowSystem within Frameworks was a source of quite a bit of trouble in the past. Dolphin is a serial offender in the same department when it comes to KIO - it has a similarly hard dependency. > > > > > > * We currently don't have a stable branch for Framework and it > takes > > > > > often > > > > > up to one month for fixes to be deployed. The Framework releases is > > > > > also > > > > > not in sync with either Gear nor Plasma while these two modules > > > > > heavily > > > > > make use of Framework and contribute to Framework. > > > > > > Changing the Frameworks release cadence away from monthly isn't going > to > > > get fixes out any faster - as if you are using distribution packages it > > > still has to be packaged. > > > If anything it will make them take longer as the Frameworks release > would > > > end up being every couple of months instead of monthly? (you can always > > > build Frameworks locally if you need the fixes now) > > > > For (non-rolling) distributions that update packages on patch releases > but > > not on minor releases it would make a difference if there where patch > > releases of Frameworks. Not all distributions can follow and backport > > important fixes in Frameworks. At worst, users will have to suffer a bug > in > > Frameworks until the next LTS release. > > > > Regards, > > Ingo > -- > Kevin Ottens, http://ervin.ipsquad.net > > enioka Haute Couture - proud supporting member of KDE > https://hc.enioka.com/en Cheers, Ben
Re: kdewebkit status
On Sun, Apr 21, 2024 at 5:07 AM Ashark wrote: > Hello. > Hey Andrew, > > I have seen a bug that kdewebkit is failing to build (406342). I was > looking > why the person was building that module in the first place. > > Afaict, this module is not used in any project. Searching in repo-metadata > by > "kdewebkit" word, I see it is: > > Listed in `dependency-data-kf5-qt5` and in > `dependency-data-stable-kf5-qt5`, > without any dependency, and no any other project points to it as a > dependency. > > Listed in `kf5-frameworks.ksb` to be ignored: > ``` > module-set frameworks > repository kde-projects > use-modules frameworks > > #tag v5.75.0-rc1 > branch kf5 > ignore-modules kdewebkit kuserfeedback > end module-set > ``` > > and also listed in `kf6-frameworks.ksb` as ignored: > ``` > module-set frameworks > repository kde-projects > use-modules frameworks > ignore-modules kdelibs4support kdewebkit khtml kjsembed kmediaplayer > kinit > kjs kross kdesignerplugin kemoticons kxmlrpcclient > cmake-options -DBUILD_WITH_QT6=ON > end module-set > ``` > > The projects-invent/frameworks/kdewebkit/metadata.yaml contains the entry > ``` > repoactive: true > ``` > > Maybe this should be marked as `repoactive: false` and removed from ignore- > modules? > The repoactive flag mirrors the status of the repository on Gitlab (whether it is active or archived). As Frameworks as a compatibility promise, this repository will need to continue to limp around unfortunately until KF5 ceases to make releases. > > The project readme says that it is removed from kf6. > > > Cheers, Ben
Re: Proposal unify back our release schedules
On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens wrote: > Hello, > Hi all, > > Unsurprisingly I'll be pretty much aligned with Luigi, Sune and Volker > here I > think. I'll try to add a couple of extra aspects to feed the thinking on > this > topic. > On Friday 19 April 2024 11:04:33 CEST Carl Schwan wrote: > > I know this might be a controversial idea, but I would like to propose > > reunify our release schedules. I feel like splitting our releases > schedules > > between Frameworks, Plasma and Gear is not working as well as we intended > > it to be when we split the releases schedules for Plasma 5. This is for > > multiple reasons: > > > > * We end up with 3 different products which are released at different > times > > but are connected together. Apps and Plasma both need Framework, Plasma > > needs some packages from gear like kio-extra, Gear needs some package > from > > Plasma like Breeze. Coordinating all these inter-groups dependencies is > > complex and was one the reason we had to do a megarelease for Plasma 6. > > Also for the end user, one product is a lot easier to understand. > > This is an engineering topic in this case. > > And, to me, this is an excellent reason not to reunify release schedules! > Because what it tells me is that we're still having dependency issues > which > need to be solved. > > The example you give shows Plasma depending on Gear, this shouldn't > happen, so > I'd argue: let's fix that instead. > Further cutting these links would be quite beneficial from a CI perspective, so i'm definitely in favour of this. Some of the most complicated bits of maintaining the system involve the interconnections between Gear / Plasma / Independent. Unfortunately libplasma / kpipewire / plasma-activities will be fairly hard to avoid if you're targeting certain types of integration. > > Aligning the release schedules would only hide such structural issues. > > This was one of the main engineering motives to split things up: when it > wasn't splitted this would stay hidden much longer everyone being comfy > with > it. > > Now it's creating pain: perfect, that makes the issue obvious, but it > should > be addressed not masked. > > This is in part what Volker highlighted pointing out this should be less > of a > problem with key components being moved to Plasma. Again, if there are > more, > let's just address them. > > So as pointed out by Sune and Volker: this is a feature (at least in the > Frameworks case) not a bug. > > > * This results in very frequent releases which creates a lot of work for > > distros and talking with some distro maintainers they seems to agree that > > having a big releases every 4 months is better than having constantly a > new > > minor or major release from either Framework, Gear or Plasma. > > This is a downstream relationship topic in this case. > > I'm honestly unsure where the problem is though. They could decide to pick > a > set of version for the three and focus on that. They don't have and never > had > to package every single version of KDE Frameworks. > > That being said it indicates to me that we're not good at communicating > which > KDE Frameworks version a given Plasma or Gear release targets. More > coordination and communication here would make sense. > > * We currently don't have a stable branch for Framework and it takes > often > > up to one month for fixes to be deployed. The Framework releases is also > > not in sync with either Gear nor Plasma while these two modules heavily > > make use of Framework and contribute to Framework. > Changing the Frameworks release cadence away from monthly isn't going to get fixes out any faster - as if you are using distribution packages it still has to be packaged. If anything it will make them take longer as the Frameworks release would end up being every couple of months instead of monthly? (you can always build Frameworks locally if you need the fixes now) I should note that due to a combination of Gitlab configuration and various projects essentially having a hard dependency on Frameworks master (Plasma, Dolphin, looking at both of you) the CI system always supplies Frameworks master regardless of what is being built (the Gitlab configuration is fixable, but there isn't much motivation to do so when it will just cause issues and not be used) > > This is a QA and testing topic in this case. > > The intent is that master is the stable branch (as Luigi pointed out). If > it's > not stable in practice we're failing on testing on QA. So extra automated > tests, more QA and so on should be provided. Yes this is work but it has a > chance of increasing quality, changing the release cadence won't do > anything > about it. > > * We could have an unified LTS release including more than just Plasma. > This > > is something that distros have been asking for some time already because > > having just Plasma receiving bug-fixes but not Framework nor the apps is > > not that helpful. > > This is a
Re: Proposal unify back our release schedules
On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens wrote: > Hello, > Hi all, > > Unsurprisingly I'll be pretty much aligned with Luigi, Sune and Volker > here I > think. I'll try to add a couple of extra aspects to feed the thinking on > this > topic. > On Friday 19 April 2024 11:04:33 CEST Carl Schwan wrote: > > I know this might be a controversial idea, but I would like to propose > > reunify our release schedules. I feel like splitting our releases > schedules > > between Frameworks, Plasma and Gear is not working as well as we intended > > it to be when we split the releases schedules for Plasma 5. This is for > > multiple reasons: > > > > * We end up with 3 different products which are released at different > times > > but are connected together. Apps and Plasma both need Framework, Plasma > > needs some packages from gear like kio-extra, Gear needs some package > from > > Plasma like Breeze. Coordinating all these inter-groups dependencies is > > complex and was one the reason we had to do a megarelease for Plasma 6. > > Also for the end user, one product is a lot easier to understand. > > This is an engineering topic in this case. > > And, to me, this is an excellent reason not to reunify release schedules! > Because what it tells me is that we're still having dependency issues > which > need to be solved. > > The example you give shows Plasma depending on Gear, this shouldn't > happen, so > I'd argue: let's fix that instead. > Further cutting these links would be quite beneficial from a CI perspective, so i'm definitely in favour of this. Some of the most complicated bits of maintaining the system involve the interconnections between Gear / Plasma / Independent. Unfortunately libplasma / kpipewire / plasma-activities will be fairly hard to avoid if you're targeting certain types of integration. > > Aligning the release schedules would only hide such structural issues. > > This was one of the main engineering motives to split things up: when it > wasn't splitted this would stay hidden much longer everyone being comfy > with > it. > > Now it's creating pain: perfect, that makes the issue obvious, but it > should > be addressed not masked. > > This is in part what Volker highlighted pointing out this should be less > of a > problem with key components being moved to Plasma. Again, if there are > more, > let's just address them. > > So as pointed out by Sune and Volker: this is a feature (at least in the > Frameworks case) not a bug. > > > * This results in very frequent releases which creates a lot of work for > > distros and talking with some distro maintainers they seems to agree that > > having a big releases every 4 months is better than having constantly a > new > > minor or major release from either Framework, Gear or Plasma. > > This is a downstream relationship topic in this case. > > I'm honestly unsure where the problem is though. They could decide to pick > a > set of version for the three and focus on that. They don't have and never > had > to package every single version of KDE Frameworks. > > That being said it indicates to me that we're not good at communicating > which > KDE Frameworks version a given Plasma or Gear release targets. More > coordination and communication here would make sense. > > * We currently don't have a stable branch for Framework and it takes > often > > up to one month for fixes to be deployed. The Framework releases is also > > not in sync with either Gear nor Plasma while these two modules heavily > > make use of Framework and contribute to Framework. > Changing the Frameworks release cadence away from monthly isn't going to get fixes out any faster - as if you are using distribution packages it still has to be packaged. If anything it will make them take longer as the Frameworks release would end up being every couple of months instead of monthly? (you can always build Frameworks locally if you need the fixes now) I should note that due to a combination of Gitlab configuration and various projects essentially having a hard dependency on Frameworks master (Plasma, Dolphin, looking at both of you) the CI system always supplies Frameworks master regardless of what is being built (the Gitlab configuration is fixable, but there isn't much motivation to do so when it will just cause issues and not be used) > > This is a QA and testing topic in this case. > > The intent is that master is the stable branch (as Luigi pointed out). If > it's > not stable in practice we're failing on testing on QA. So extra automated > tests, more QA and so on should be provided. Yes this is work but it has a > chance of increasing quality, changing the release cadence won't do > anything > about it. > > * We could have an unified LTS release including more than just Plasma. > This > > is something that distros have been asking for some time already because > > having just Plasma receiving bug-fixes but not Framework nor the apps is > > not that helpful. > > This is a
[libalkimia] [Bug 459128] CI job using docker image 'kdeorg/ci-suse-qt515:latest' fails with timeout at running alkonlinequotestest
https://bugs.kde.org/show_bug.cgi?id=459128 --- Comment #28 from Ben Cooksley --- (In reply to Ralf Habacker from comment #26) > (In reply to Ralf Habacker from comment #22) > > (In reply to Ben Cooksley from comment #17) > > > > > For Windows, that installation issue is a matter for the Craft developers > > > in #kde-craft:kde.org i'm afraid. > > According to https://invent.kde.org/office/alkimia/-/jobs/1740161#L25 craft > does not appear to be involved here. Instead, a script from the > sysadmin/ci-utilities repo is used here (see > https://invent.kde.org/sysadmin/ci-utilities/-/blob/master/run-ci-build. > py?ref_type=heads). Craft is used to provide everything not provided by Visual Studio / the Windows SDK on Windows systems. This includes Qt. See https://invent.kde.org/sysadmin/ci-images/-/blob/master/windows-msvc2022/Dockerfile?ref_type=heads followed by https://invent.kde.org/sysadmin/ci-images/-/blob/master/windows-msvc2022-qt66/Dockerfile?ref_type=heads and -- You are receiving this mail because: You are watching all bug changes.
[libalkimia] [Bug 459128] CI job using docker image 'kdeorg/ci-suse-qt515:latest' fails with timeout at running alkonlinequotestest
https://bugs.kde.org/show_bug.cgi?id=459128 --- Comment #28 from Ben Cooksley --- (In reply to Ralf Habacker from comment #26) > (In reply to Ralf Habacker from comment #22) > > (In reply to Ben Cooksley from comment #17) > > > > > For Windows, that installation issue is a matter for the Craft developers > > > in #kde-craft:kde.org i'm afraid. > > According to https://invent.kde.org/office/alkimia/-/jobs/1740161#L25 craft > does not appear to be involved here. Instead, a script from the > sysadmin/ci-utilities repo is used here (see > https://invent.kde.org/sysadmin/ci-utilities/-/blob/master/run-ci-build. > py?ref_type=heads). Craft is used to provide everything not provided by Visual Studio / the Windows SDK on Windows systems. This includes Qt. See https://invent.kde.org/sysadmin/ci-images/-/blob/master/windows-msvc2022/Dockerfile?ref_type=heads followed by https://invent.kde.org/sysadmin/ci-images/-/blob/master/windows-msvc2022-qt66/Dockerfile?ref_type=heads and -- You are receiving this mail because: You are the assignee for the bug.
[KDE MediaWiki] [Bug 485522] KDE Connect: "Learn More" links from download page give fatal error
https://bugs.kde.org/show_bug.cgi?id=485522 Ben Cooksley changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED Product|www.kde.org |KDE MediaWiki Assignee|kde-...@kde.org |schwanc...@protonmail.com Component|apps.kde.org|general --- Comment #1 from Ben Cooksley --- Thanks for reporting this - this has now been corrected and was due to incompatibilities between the Mediawiki EmbedVideo extension and our version of Mediawiki. -- You are receiving this mail because: You are watching all bug changes.
Re: KDE Gear projects with failing CI (release/24.02) (2 April 2024)
On Thu, Apr 11, 2024 at 1:15 AM Ralf Habacker wrote: > Am 10.04.24 um 10:51 schrieb Ben Cooksley: > > umbrello - 3rd week > > * https://invent.kde.org/sdk/umbrello/-/pipelines/657665 > > <https://invent.kde.org/sdk/umbrello/-/pipelines/657665> > >* craft_windows_qt515_x86_64 fails > > > > This issue depends on a special dependency requirement in a third party > package, see > > https://invent.kde.org/packaging/craft-blueprints-kde/-/blob/master/extragear/kdevelop/kdevelop/kdevelop.py?ref_type=heads#L30 > > Currently I have no idea how to fix this - Any hint welcome. > This was discussed in #kde-craft a week or so ago. Hopefully https://invent.kde.org/packaging/craft-blueprints-kde/-/merge_requests/827 will resolve this. > > Regards > Ralf > > Cheers, Ben
Re: KDE Frameworks with failing CI (master) (7 April 2024)
On Wed, Apr 10, 2024 at 4:33 AM Volker Krause wrote: > On Sonntag, 7. April 2024 23:02:06 CEST Albert Astals Cid wrote: > > Please work on fixing them, otherwise i will remove the failing CI jobs > on > > their 4th failing week, it is very important that CI is passing for > multiple > > reasons. > > > > Bad news: 3 repositories have started failing > > > > kconfigwidgets - NEW > > * https://invent.kde.org/frameworks/kconfigwidgets/-/pipelines/655246 > > * klanguagenametest fails in Linux > >* > https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/234 > > > > > > kcontacts - NEW > > * https://invent.kde.org/frameworks/kcontacts/-/pipelines/655247 > > * AddressTest::formatTest fails in FreeBSD > > That's the same issue that also hit kitinerary. As I haven't gotten any > answers for my questions about what changed on the CI there I've now > disabled > this test for FreeBSD for kitinerary, I can do the same for KContacts I > guess. > To give a public answer about this - there was a general image rebuild to take into account a number of updates to various libraries. It seems something in the FreeBSD stack has gotten loose as part of this so we'll need to do some more investigation. > > > kuserfeedback - NEW > > * https://invent.kde.org/frameworks/kuserfeedback/-/pipelines/655248 > > * The code requires unreleased versions so flatpak fails > > Hm, that's a systematic problem: We cannot do Flatpak builds in a KF > master > branch on top of an existing runtime. > > Doing Flatpak builds only in the stable branch wont work here given there > is > no such branch. So the options I can think of are either building all KF > dependencies explicitly here rather than using those from the runtime, or > splitting the management/analytics tools (which is what the Flatpak is > actually for) from the library. > I'd probably suggest splitting them at this stage given the issues we keep hitting here... > > Regards, > Volker Cheers, Ben
Re: KDE Gear projects with failing CI (release/24.02) (2 April 2024)
On Wed, Apr 10, 2024 at 9:33 AM Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for > multiple > reasons. > > Good news: 1 repository was fixed > > Bad news: 2 repositories are still failing and 6 repositories has started > failing > > kirigami-gallery - 3rd week > * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/657676 > * Android build fails > > > umbrello - 3rd week > * https://invent.kde.org/sdk/umbrello/-/pipelines/657665 > * craft_windows_qt515_x86_64 fails > > > krdc - NEW > * https://invent.kde.org/network/krdc/-/pipelines/657666 > * Linux builds fail because of missing dependencies > Christophe sent some merge requests earlier for Qt 6 which resolved that side of our CI images, however Qt 5.15 was missed. I've aligned that this evening and rebuilt the SUSE CI images. > > > ktrip - NEW > * https://invent.kde.org/utilities/ktrip/-/pipelines/657677 > * craft builds fail > > tokodon - NEW > * https://invent.kde.org/network/tokodon/-/pipelines/657678 > * tokodon-searchtest fails in Linux and FreeBSD > > > dolphin - NEW > * https://invent.kde.org/system/dolphin/-/pipelines/657664 > * flatpak fails because it is building baloo from master instead of > stable > > > arianna - NEW > * https://invent.kde.org/graphics/arianna/-/pipelines/657679 > * flatpak fails because it is building baloo from master instead of > stable > > > pim-sieve-editor - NEW > * https://invent.kde.org/pim/pim-sieve-editor/-/pipelines/657670 > * flatpak fails because it is building ktexttemplate from master instead > of > stable > > > Cheers, > Albert > Cheers, Ben
Re: KDE Gear projects with failing CI (master) (9 April 2024)
On Wed, Apr 10, 2024 at 9:26 AM Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for > multiple > reasons. > > Good news: 3 repositories got fixed > > Bad news: 2 repositories still failing and new 5 repositories failing this > week > > > umbrello - 3rd week > * https://invent.kde.org/sdk/umbrello/-/pipelines/657654 > * craft_windows_qt515_x86_64 fails > > > kirigami-gallery - 3rd week > * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/657659 > * Android build fails Waiting on Craft to be ready to bump to Qt 6.7 which will be soon. > > > > kdenlive - NEW > * https://invent.kde.org/multimedia/kdenlive/-/pipelines/657653 > * flatpak fails, shasum changed? > > > kldap - NEW > * https://invent.kde.org/pim/kldap/-/pipelines/657656 > * Windows build fails because it can't find Qt6Keychain > > > kmailtransport - NEW > * https://invent.kde.org/pim/kmailtransport/-/pipelines/657657 > * Windows build fails because it can't find Qt6Keychain > > > pim-sieve-editpr - NEW > * https://invent.kde.org/pim/pim-sieve-editor/-/pipelines/657658 > * Windows build fails because it can't find Qt6Keychain > Carl has temporarily patched these to keep the lower version in place for Windows. PIM developers are reminded to not just arbitrarily bump dependencies but to use merge requests and ask/file tickets before bumping dependencies. Craft will soon update here as part of the Qt 6.7 bump. > > > ktrip - NEW > * https://invent.kde.org/utilities/ktrip/-/pipelines/657661 > * craft_android builds fail > Probably worth waiting for the Craft Qt 6.7 bump to see how this works out. > > Cheers, > Albert > > > Cheers, Ben
[sysadmin/ci-images] /: Ensure we include QtKeychain in our Windows images for Qt 5.15 and Qt 6.6.
Git commit 9b33873bf75e362f24d6b03a2c7873fb5fa16668 by Ben Cooksley. Committed on 10/04/2024 at 08:42. Pushed by bcooksley into branch 'master'. Ensure we include QtKeychain in our Windows images for Qt 5.15 and Qt 6.6. This dependency on QtKeychain was added by PIM developers to KLDAP, KMailTransport and PIM Sieve Editor without any form of advance notice to Sysadmin. PIM Developers: You are reminded yet again, please give advance notice of changes to external dependencies. CCMAIL: kde-devel@kde.org CCMAIL: kde-...@kde.org M +3-0windows-msvc2019-qt515/CI-Craft-Packages.list M +3-0windows-msvc2022-qt66/CI-Craft-Packages.shelf https://invent.kde.org/sysadmin/ci-images/-/commit/9b33873bf75e362f24d6b03a2c7873fb5fa16668 diff --git a/windows-msvc2019-qt515/CI-Craft-Packages.list b/windows-msvc2019-qt515/CI-Craft-Packages.list index 10f19da..23541c3 100644 --- a/windows-msvc2019-qt515/CI-Craft-Packages.list +++ b/windows-msvc2019-qt515/CI-Craft-Packages.list @@ -88,6 +88,9 @@ libs/fluidsynth # KCalCore libs/libical +# KMailTransport, KLDAP and PIM Sieve Editor +qt-libs/qtkeychain + # Analitza libs/glew diff --git a/windows-msvc2022-qt66/CI-Craft-Packages.shelf b/windows-msvc2022-qt66/CI-Craft-Packages.shelf index 852233c..845b029 100644 --- a/windows-msvc2022-qt66/CI-Craft-Packages.shelf +++ b/windows-msvc2022-qt66/CI-Craft-Packages.shelf @@ -101,6 +101,9 @@ blueprintrepositories = https://invent.kde.org/packaging/craft-blueprints-kde.gi ## KCalCore [libs/libical] +## KMailTransport, KLDAP and PIM Sieve Editor +[qt-libs/qtkeychain] + ## Analitza [libs/glew]
Re: KDE Gear projects with failing CI (master) (9 April 2024)
On Wed, Apr 10, 2024 at 9:51 AM Ingo Klöcker wrote: > On Dienstag, 9. April 2024 23:26:32 CEST Albert Astals Cid wrote: > > ktrip - NEW > > * https://invent.kde.org/utilities/ktrip/-/pipelines/657661 > > * craft_android builds fail > > *sigh* Why does kirigami master depend on the not yet released ECM 6.1.0? > Likely as Kirigami itself is a Framework - that being said, it seems a bit weird for the version bumps to be pushed to Frameworks before the release has been made public (because Craft cannot use them until they're public...) The real question I have though is why does KTrip depend on Frameworks master instead of released Frameworks? Depending on Frameworks master is something applications should avoid unless it is absolutely necessary. > > Regards, > Ingo Cheers, Ben
Re: Should we stop distributing source tarballs?
On Mon, Apr 8, 2024 at 1:55 AM Marc Deop i Argemí wrote: > On Saturday, 6 April 2024 18:22:22 CEST Sven Brauch wrote: > > This is basically a discussion about whether it is less risky to trust > > the individual developers, or the people with access to the CI signing > > key. You are trading likeliness of there being one bad actor vs. impact > > one bad actor can have. It's a matter of personal opinion; there is no > > right or wrong choice here. > > No, it is not. > > The key is that the infrastructure creation needs to also be automated. > > Once you have the *bootstrap* , you can trust the automation because you > can > review and audit it ( to a certain degree, of course, there is nothing > bullet > proof). > > I have been surprised for years on how the KDE infrastructure is handled > (so > many things done manually) but as I am not _in_ I cannot really judge > because > I don't know all of the circumstances and context. > The trust issue has nothing to do with the infrastructure - problems such as the XZ compromise cannot be resolved with technological barriers. The solution to them is social measures. Having the infrastructure itself hold the key makes it more difficult to distinguish between the various maintainers publishing the build, and makes it more likely that someone evil is able to publish a build without anyone noticing, and also makes it easier for an evil-doer to tamper with tarballs that are sitting on our infrastructure. Keeping the key material segregated from the actual release infrastructure (the key being on the release managers system, and the release infrastructure being download.kde.org) protects against this. I appreciate you are trying to protect against evil maintainers/release managers tampering with tarball contents, however there are other ways of addressing that. > > Best regards > > Marc Cheers, Ben
Re: KDE Frameworks with failing CI (kf5) (7 April 2024)
On Mon, Apr 8, 2024 at 9:03 AM Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for > multiple > reasons. > > Bad news: 1 repositories is still failing and 1 has started failing > > kirigami - 3rd week > * https://invent.kde.org/frameworks/kirigami/-/pipelines/649285 > * Android build fails >* Something qt related needs a rebuild? > This will likely be resolved as part of the upcoming Craft cache rebuild that is currently being worked on as part of rolling out Qt 6.7. I'd estimate 1-2 weeks before we start to roll that out, at which point this should be fixed. > > > kcontacts - NEW > * https://invent.kde.org/frameworks/kcontacts/-/pipelines/655262 > * AddressTest fails on FreeBSD (Same as in master) > > > Cheers, > Albert > Cheers, Ben
Re: Should we stop distributing source tarballs?
On Sat, Apr 6, 2024 at 4:23 AM Johannes Zarl-Zierl wrote: > Am Freitag, 5. April 2024, 13:45:35 CEST schrieb Carl Schwan: > > On Friday, April 5, 2024 12:04:28 PM CEST Albert Vaca Cintora wrote: > > > - Tarballs should only be generated in a reproducible manner using > > > scripts. Ideally by the CI only. > > > - We should start to sign tarballs in the CI. > > > > I disagree. I want my tarball to be signed with my GPG key stored in my > > Yubiky and not by a generic KDE key. It should be a proof that I as a > > maintainer of a project did the release and not someone else. Same with > the > > upload to download.kde.org, while this adds some overhead in the > process, I > > think it is important that KDE Sysadmins are the one who move the tarball > > to their final location and do some minimal check (checksum match, it's > not > > a random person doing the release, ...). > > Signing with a KDE key could have some benefits, though. It's far easier > for > distros (or users) to check KDE software against a single, well known key. > > On could mitigate the downside that you mentioned by having the script > check > the tag signature against a keyring of trusted keys. > Please see https://invent.kde.org/sysadmin/release-keyring/ - our process for validating tarballs for release already includes ensuring the GPG signatures provided are included in that keyring. All modern releases of KDE software that come with a GPG signature whose key is not in that keyring should be rejected. Developers should also consider adding their keys to Gitlab at https://invent.kde.org/-/profile/gpg_keys Following this, your GPG key will be published at https://invent.kde.org/$username.gpg > > Cheers, > Johannes Cheers, Ben
Re: Should we stop distributing source tarballs?
On Sat, Apr 6, 2024 at 1:43 AM Heiko Becker wrote: > On Friday, 5 April 2024 12:04:28 CEST, Albert Vaca Cintora wrote: > > It seems a lot of people feel conservative in favor of tarballs, so > > maybe I aimed too far. At least I think the discussion brought some > > interesting points that we can explore further. Some I identified: > > > > - The tarballs should contain no changes with respect to git, or > > minimal changes obviously justifiable in a diff. > > Like I wrote earlier in this thread, this should hold true already since > the translations are synced to git. > I would consider any tarball that contains modified files (ie. is not a one to one representation of the git tag it represents) to be invalid for the purposes of KDE project releases. Now that translations are synced into our Git repositories there is no reason why we should have differences. > > > - Tarballs should only be generated in a reproducible manner using > > scripts. Ideally by the CI only. > > - We should start to sign tarballs in the CI. > > The scripts already exists for the bundles and users of releasme. Letting > the CI create tarballs seems indeed like a good way to reduce > possibilities > of human tampering. > With regard to signing: At first I thought that it means something that > the > person responsible for the release is also signing the tarballs. But maybe > there could even be two signatures in the future, one by CI and one by the > release person (although that would probably mean a few challenges for the > tooling). > > > - We should start to sign commits and tags. Git recently made this > > super easy by allowing signing with the ssh keys that we all are > > already using to push things, so no excuses for not enabling this. > > We already sign commits for the 3 release bundles and users of relaseme. > > But I'm surprised about the total absence of social aspects of the xz > incidence during this discussion. > Admittedly we fall back to community maintenance if a maintainer becomes > unavailable, so the exact xz scenario doesn't seem likely. But there are > probably a few projects on the fringes. Do we have safeguards in place if > a > nefarious person tries to steps up as maintainer? Can we do something to > help projects, which are struggling? > This is really the key issue at hand. If you look at the timeline in question, the malicious actor(s) in the XZ incident moved slowly, starting as a general contributor, accruing trust and eventually made their way up to getting maintainer access and the ability to make releases. Even with the various checks and balances we have in place around granting developer accounts, who gets permissions to update our websites, requiring people to go through tickets to publish releases on download.kde.org, etc. a similar kind of attack played out over a long enough period of time is still one that none of our technological protections would be able to stop - as people who have been long term contributors and have worked their way up to being a maintainer will tend to obtain the necessary permission or trust of those with permissions. Such attacks however will always fail when confronted with enough sunlight however, something that Linus' law of "with enough eyes all bugs are shallow" covers fairly well. To adequately protect ourselves we need to ensure that projects that only have 1 or 2 maintainers, as well as those that are "community maintained" are monitored (historically a function that kde-commits@ has filled). There is also something to be said that for larger projects such as ours (ie. the ones who are targets) that we should also be keeping an eye on the smaller libraries that we depend on - as while we may be too hard to attack it is much easier to attack those we depend on who don't have the same resources we do (which is basically what happened with XZ/OpenSSH). These would be projects with just one or two maintainers with fairly infrequent activity, and that are often located in a maintainers personal namespace on GitHub or Gitlab.com, or on personal hosting of their own. Examples of projects in this sort of space would be the likes of QtKeychain or kColorPicker (just picking two that immediately spring to mind), but there is no reason that shouldn't also cover non-Qt libraries. There are probably a couple of different options we could explore in this space as to how to best accomplish this. We should also consider whether it is acceptable for us to depend on any project that uses a build system that is either bespoke or not modern (ie. autotools, self-written bash scripts, etc) - as that was a significant contributor to how the XZ attack was able to be perpetrated. My vote would be that it is not acceptable and we should be strongly pushing any project that does not use a modern build system to migrate to one that is. > > Regards, > Heiko > Cheers, Ben
Re: Should we stop distributing source tarballs?
On Thu, Apr 4, 2024 at 10:48 PM Sune Vuorela wrote: > On 2024-04-03, Albert Vaca Cintora wrote: > > What's the advantage of providing tarballs? > > I do think there is an advantage in being able to verify that the soure > tarball is the same across distributions. Using a checksum on the > tarball is an easy way of doing it. Different git invocations for git > archive, different tar options and so on can create different checksums > for the same content. > For those wondering, for all content served by download.kde.org and files.kde.org, you can fetch a sha256 hash of the file in question by just appending ".sha256" to the URL in question. See https://download.kde.org/stable/release-service/24.02.1/src/okular-24.02.1.tar.xz.sha256 for instance. These won't show up in the file listings, and are not files that are provided to mirrors - they are provided by our mirror management system (MIrrorbits) directly. As an additional aside - we don't currently GPG sign our Git tags, so there is nothing validating that the person who made the release is actually the person whose name is on it. With GPG signatures we can at least validate who owns the key. > > I do also think it is nice if we get someone else to verify that the > tarball we ship actually matches the tag. I think some people in > distributions have already started looking into verifying that. > Hopefully they'll be gentle with tooling that does this? > > Also, git tags can be moved. > > /Sune > > Cheers, Ben
Re: KDE Gear projects with failing CI (release/24.02) (2 April 2024)
On Wed, Apr 3, 2024 at 11:41 AM Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for > multiple > reasons. > > Good news: 1 repository was fixed > > Bad news: 2 repositories are still failing and 1 repository has started > failing > > kirigami-gallery - 2nd week > * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/650570 > * Android build fails >* Similar problem to the one in kirigami being discussed in the > frameworks > mailing list > I suspect we're up for a cache rebuild to resolve this one, although once again there is debate about how functional / supported Qt 5 Android builds are anymore. > > > > umbrello - 2nd week > * https://invent.kde.org/sdk/umbrello/-/pipelines/650565 > * craft_windows_qt515_x86_64 fails >* Same as in the master report, something is up with qtwebengine? > I had a quick look and couldn't see any reason why this is occurring. Nowhere is the ignore for WebEngine set except for MacOS, and this is a Windows MSVC build so it should be fine. This will be one for #kde-craft:kde.org I fear. > > > kitinerary - NEW > * https://invent.kde.org/pim/kitinerary/-/pipelines/650569 > * extractortest fails in FreeBSD > Likely fallout of the image rebuild, i'll need to work with Tobias on straightening this out. > > > Cheers, > Albert > > > Cheers, Ben
[kmymoney] [Bug 484759] Transaction report fails to update when I expand the date range to include a large number of transactions
https://bugs.kde.org/show_bug.cgi?id=484759 --- Comment #1 from Ben Cooksley --- The content of attachment 167943 has been deleted for the following reason: Removing confidential information -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 484759] Transaction report fails to update when I expand the date range to include a large number of transactions
https://bugs.kde.org/show_bug.cgi?id=484759 --- Comment #1 from Ben Cooksley --- The content of attachment 167943 has been deleted for the following reason: Removing confidential information -- You are receiving this mail because: You are watching all bug changes.
[www.kde.org] [Bug 464394] [develop.kde.org] Breeze icon browser doesn't work
https://bugs.kde.org/show_bug.cgi?id=464394 --- Comment #5 from Ben Cooksley --- That MR is incorrect as the artifact in question will only be around as long as that particular build is around. That means that the next time breeze-icons is rebuilt, once the CI artifact cleanup job is run that artifact will be removed (as it will be an older build, and we only keep the latest build artifact around) -- You are receiving this mail because: You are watching all bug changes.
[www.kde.org] [Bug 464394] [develop.kde.org] Breeze icon browser doesn't work
https://bugs.kde.org/show_bug.cgi?id=464394 Ben Cooksley changed: What|Removed |Added CC||bcooks...@kde.org --- Comment #3 from Ben Cooksley --- It appears that this is yet another hidden dependency on the old Jenkins setup. This should be ported to pull from https://invent.kde.org/teams/ci-artifacts/suse-qt6.6/-/packages much like how apps.kde.org already does. Not sure how comparable it is, but we also have https://cdn.kde.org/breeze-icons//icons.html -- You are receiving this mail because: You are watching all bug changes.
signon-kwallet-extension
Hi all, Due to recent updates in SUSE around signond, i've just had to remove signond-libs-devel from our SUSE Qt 5.15 images. This is due to signond now being built with Qt 6 - and therefore being incompatible with Qt 5. Looking in signon-kwallet-extension though I see it is still Qt 5 code that is unported. It will therefore lose CI coverage support on LInux from today onward until it is ported to Qt 6. Cheers, Ben
signon-kwallet-extension
Hi all, Due to recent updates in SUSE around signond, i've just had to remove signond-libs-devel from our SUSE Qt 5.15 images. This is due to signond now being built with Qt 6 - and therefore being incompatible with Qt 5. Looking in signon-kwallet-extension though I see it is still Qt 5 code that is unported. It will therefore lose CI coverage support on LInux from today onward until it is ported to Qt 6. Cheers, Ben
Re: AppStream Metadata with our releases
On Wed, Mar 27, 2024 at 5:40 AM Volker Krause wrote: > On Dienstag, 26. März 2024 08:59:29 CET Heiko Becker wrote: > > On Monday, 25 March 2024 23:23:01 CET, Albert Astals Cid wrote: > > > El dissabte, 23 de març de 2024, a les 21:06:46 (CET), Julius Künzel va > > > > > > escriure: > > >> 22.03.2024 17:22:33 Albert Astals Cid : ... > > > > > > It is some extra work (not a lot, but some). > > > > > > You're asking for the workflow of creating to be releases to be > changed by > > > creating the entry in the file earlier, that alone is a bit of work, > but > > > it > > > > > > has several other consequences: > > > * https://apps.kde.org/okular/ shows releases from the appstream > file (i > > > > > > think) meaning that the code should learn to ignore releases in the > > > future. > > > Arguably we would need also now, but given the data is added > > > just a few days > > > before the actual release i think users can understand "this release > will > > > happen soon)" compared to a thing one month in the future > > > > > > * What happens if we have to change the release date or release > version > > > > > > number (hasn't happened in a good while, but wouldn't be a bad thing to > > > prepare for it). We would need to update the string or date of an > existing > > > entry, as far as I know we don't have tooling for that (because we only > > > add > > > the data to the file when we're almost sure abiyt it). > > > > In addition I'm a litte bit wary of conflicts when cherry-picking the > > appstream changes between branches, which the script does after > > incrementing the version. I saw at least conflicts in itinerary's > releases > > notes and e.g. kdeconnect's or okular's windows releases in the past, > which > > isn't that much of a problem but it could become one with the 245 modules > > of gear (to be fair not all have appstream metadata (yet)). > > Sorry about that! I try to keep both branches in sync usually, if there is > anything I can do/do differently to not impact your work I'm happy to do > that > of course. > > > Otherwise I'd just miss the opportunity to trigger a CI build for > > everything again shortly before the release, but I'd guess that's easy to > > get over. > > Albert seems to have an alternative way using API (?) for the weekly build > status reports, I guess that could be reused/combined somehow? > Please see https://docs.gitlab.com/ee/api/pipelines.html#create-a-new-pipeline I imagine he uses https://docs.gitlab.com/ee/api/pipelines.html#get-the-latest-pipeline to fetch the outcome of that. Note that the above API is not suitable for building a public dashboard due to the number of queries we would need, but it is fine for one off runs like what Albert does. > > Regards, > Volker Cheers, Ben
Re: KDE Frameworks with failing CI (kf5) (24 March 2024)
On Wed, Mar 27, 2024 at 5:55 AM Volker Krause wrote: > On Dienstag, 26. März 2024 00:42:53 CET Albert Astals Cid wrote: > > El dilluns, 25 de març de 2024, a les 18:03:27 (CET), Volker Krause va > > > > escriure: > > > On Sonntag, 24. März 2024 23:14:12 CET Albert Astals Cid wrote: > > > > Please work on fixing them, otherwise i will remove the failing CI > jobs > > > > on > > > > their 4th failing week, it is very important that CI is passing for > > > > multiple reasons. > > > > > > > > Bad news: 2 repositories have started failing > > > > > > > > kirigami - NEW > > > > > > > > * https://invent.kde.org/frameworks/kirigami/-/jobs/1679118 > > > > > > > > * Android build fails > > > > > > > >* Something qt related needs a rebuild? > > > > > > Yep, looks like a version mix due to the patch collection rebase. > > > > But why has this happened? I mean how is it that some Qt has different > than > > some other Qt? Was there a rebuild of Android Qt while i was doing the > > rebase? > > > > If I understand that right there's a QtSvg is 5.15.13 but QtWidgets is > only > > 5.15.12? > > Not sure what caused it specifically here, but this happens as soon as > anything > triggers a rebuild of a part of Qt for whatever reason. That part is then > taken from the kde/5.15 head, which is newer than the rest of Qt in the > cache. > > The effect used to spread/worsen over time as more things in the cache > become > outdated (not sure if that got better or worse with the significantly > reduced > Qt5-related activity nowadays). > > > > I'm wondering how we want to proceed here longer term, as this will > > > continue to need active maintenance while most of our Android apps have > > > meanwhile moved to Qt 6. > > > > > > Pin the Qt version in Craft to a fixed revision? Drop Android KF5 CI > > > builds? Find volunteers to do the work of keeping this running/working? > > > > If we're saying Kirigami works on Android ideally we should keep a CI. > > Pinning the Qt5 version might be a good compromise then? Keeping Kirigami > working in a fixed environment should be fine, but dealing with the > movement in > Qt, Android and Craft for one major version is hard enough already. > This issue has existed for a while now as you've pointed out. The only real fix is for us to fully rebuild the Craft cache each time the KDE Qt 5 Patch Collection is rebased. Without the existence of version specific stable branches of the patch collection for us to point Craft to, that is the best we'll be able to do unfortunately, as currently we've basically got Craft pointed at a moving target. Alternatively, we can move Qt 5 support in Craft to an LTS branch which should ensure the amount of movement in the blueprints (which triggers the rebuilds of parts of Qt in the cache) is minimised (keeping the cache valid, even if outdated) > > Regards, > Volker > Cheers, Ben
[Craft] [Bug 481455] kiconthemes master failed
https://bugs.kde.org/show_bug.cgi?id=481455 --- Comment #4 from Ben Cooksley --- Building master versions of software with Craft is generally not supported - which is why it fails. The patch will be removed when the next Frameworks release takes place and the Craft cache is rebuilt. -- You are receiving this mail because: You are watching all bug changes.
[Craft] [Bug 481455] kiconthemes master failed
https://bugs.kde.org/show_bug.cgi?id=481455 --- Comment #4 from Ben Cooksley --- Building master versions of software with Craft is generally not supported - which is why it fails. The patch will be removed when the next Frameworks release takes place and the Craft cache is rebuilt. -- You are receiving this mail because: You are on the CC list for the bug.
[digikam] [Bug 483228] Error when accessing digikam.org and docs.digikam.org : SSL certificates needs updates.
https://bugs.kde.org/show_bug.cgi?id=483228 --- Comment #8 from Ben Cooksley --- This is an issue that has also struck Kdenlive and Krita. I've now rewound the repository and have applied a safety measure that should hopefully prevent it from recurring. -- You are receiving this mail because: You are watching all bug changes.
Re: KDE Gear projects with failing CI (master) (12 March 2024)
On Wed, Mar 13, 2024 at 12:12 PM Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for > multiple > reasons. > > Good news: 6 repositories got fixed > > Bad news: 2 repository still failing and 7 new repositories failing this > week > > > filelight - 2nd week > * https://invent.kde.org/utilities/filelight/-/pipelines/628855 > * craft fails > > > klickety - 2nd week > * https://invent.kde.org/games/klickety/-/pipelines/628858 > * appstreamtest fails Hm, I thought I had fixed all the Appstream failures. Anyway, this is fixed now. > > > > kalgebra - NEW > * https://invent.kde.org/education/kalgebra/-/pipelines/628851 > * flatpak fails, needs libplasma > > > kig - NEW > * https://invent.kde.org/education/kig/-/pipelines/628852 > * craft fails > > > kdenlive - NEW > * https://invent.kde.org/multimedia/kdenlive/-/pipelines/628926 > * Qt6 code fails to compile > > > akregator - NEW > * https://invent.kde.org/pim/akregator/-/pipelines/628861 > * appstreamtest fails Fixed as well. No idea how this passed last week given nothing has changed here? > > > > neochat - NEW > * https://invent.kde.org/network/neochat/-/pipelines/628957 > * craft fails > Likely caused by libtiff being present on the system when the cache was built, but not being marked as a dependency of QtWebEngine. Craft folks, will adding libtiff as a dependency of QtWebEngine without bumping the patch version cause any issues? (that should fix this) > > > mimetreeparser - NEW > * https://invent.kde.org/pim/mimetreeparser/-/pipelines/628865 > * core-cryptohelpertest fails > > Don't understand how that could fail out of the blue... > > > francis - NEW > * https://invent.kde.org/utilities/francis/-/pipelines/628866 > * reuse fails > Fixed by Carl in https://invent.kde.org/utilities/francis/-/commit/a3749a7f74ed2bdffeb3b4bc17835ae7ccd6fa64 > > > Cheers, > Albert > > > Cheers, Ben
Re: KDE Gear projects with failing CI (release/24.02) (12 March 2024)
On Wed, Mar 13, 2024 at 12:34 PM Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for > multiple > reasons. > > > VERY BAD NEWS: > * Cantor made it to its 4th week with FreeBSD tests failing > * I have disabled them > * > https://invent.kde.org/education/cantor/-/commit/5b2a8285e2f6ecac28f4ae07c602b9b8f8c7f7fa > > Good News: 6 failing repositories from previous report got fixed > > Bad news: 2 repositories are still failing and 2 new repositories started > failing > > > kimap - 3rd week > * https://invent.kde.org/pim/kimap/-/pipelines/628890 > * testsession fails on FreeBSD > > > neochat - 3rd week > * https://invent.kde.org/network/neochat/-/pipelines/628898 > * craft build fails > > > kdenlive - NEW > * https://invent.kde.org/multimedia/kdenlive/-/pipelines/628930 > * Qt6 code fails to compile > > > akregator - NEW > * https://invent.kde.org/pim/akregator/-/pipelines/628861 > * appstreamtest fails No idea why this has suddenly shown up as a failure. Appstream makes no sense sometimes - either way, should be fixed now. > > > > > Cheers, > Albert > Cheers, Ben
[libalkimia] [Bug 459128] CI job using docker image 'kdeorg/ci-suse-qt515:latest' fails with timeout at running alkonlinequotestest
https://bugs.kde.org/show_bug.cgi?id=459128 --- Comment #17 from Ben Cooksley --- Given that both KIO and Curl are working fine, i'd suggest that something isn't quite right with how your test is utilising WebEngine - especially given it fails on both FreeBSD and Linux. For Windows, that installation issue is a matter for the Craft developers in #kde-craft:kde.org i'm afraid. It is likely WebEngine is highly untested as very little software makes use of it. -- You are receiving this mail because: You are the assignee for the bug.
[libalkimia] [Bug 459128] CI job using docker image 'kdeorg/ci-suse-qt515:latest' fails with timeout at running alkonlinequotestest
https://bugs.kde.org/show_bug.cgi?id=459128 --- Comment #17 from Ben Cooksley --- Given that both KIO and Curl are working fine, i'd suggest that something isn't quite right with how your test is utilising WebEngine - especially given it fails on both FreeBSD and Linux. For Windows, that installation issue is a matter for the Craft developers in #kde-craft:kde.org i'm afraid. It is likely WebEngine is highly untested as very little software makes use of it. -- You are receiving this mail because: You are watching all bug changes.
Re: KDE Frameworks with failing CI (master) (10 March 2024)
On Mon, Mar 11, 2024 at 12:46 PM Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for > multiple > reasons. > > Bad news: 1 repository is still failing and 1 new has started failing > > > kimageformats - 3rd week > * https://invent.kde.org/frameworks/kimageformats/-/pipelines/627271 > * kimageformats-read-xcf fails in Linux CI >* https://invent.kde.org/frameworks/kimageformats/-/merge_requests/211 > fixes it but then breaks the BSD builder (because it is on an older Qt) > Can we > update Qt in the BSD builder to 6.6.2? > Please file a ticket for that update. > > > kpackage - NEW > * https://invent.kde.org/frameworks/kpackage/-/pipelines/627276 > * appstream check fails > It would appear that this will require changes to the KPackage format to ensure that we allow (require?) plugins to specify a homepage to comply with Appstream requirements. > > Cheers, > Albert > > > Regards, Ben
[libalkimia] [Bug 459128] CI job using docker image 'kdeorg/ci-suse-qt515:latest' fails with timeout at running alkonlinequotestest
https://bugs.kde.org/show_bug.cgi?id=459128 --- Comment #15 from Ben Cooksley --- Not sure why we're trying to launch WebEngine here? -- You are receiving this mail because: You are the assignee for the bug.
[libalkimia] [Bug 459128] CI job using docker image 'kdeorg/ci-suse-qt515:latest' fails with timeout at running alkonlinequotestest
https://bugs.kde.org/show_bug.cgi?id=459128 --- Comment #15 from Ben Cooksley --- Not sure why we're trying to launch WebEngine here? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 483228] Error when accessing digikam.org and docs.digikam.org : SSL certificates needs updates.
https://bugs.kde.org/show_bug.cgi?id=483228 Ben Cooksley changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Ben Cooksley --- This is supposed to automatically renew, however the decommissioning of a subdomain of digikam.org broke this. Has now been corrected and the certificate renewed. -- You are receiving this mail because: You are watching all bug changes.
[libalkimia] [Bug 459128] CI job using docker image 'kdeorg/ci-suse-qt515:latest' fails with timeout at running alkonlinequotestest
https://bugs.kde.org/show_bug.cgi?id=459128 --- Comment #12 from Ben Cooksley --- Running curl against that URL works fine in a CI container, your test must be doing something else to trigger the failure (either IPv4/IPv6 related, or otherwise cannot handle the high bandwidth connection the server has) -- You are receiving this mail because: You are watching all bug changes.
[libalkimia] [Bug 459128] CI job using docker image 'kdeorg/ci-suse-qt515:latest' fails with timeout at running alkonlinequotestest
https://bugs.kde.org/show_bug.cgi?id=459128 --- Comment #12 from Ben Cooksley --- Running curl against that URL works fine in a CI container, your test must be doing something else to trigger the failure (either IPv4/IPv6 related, or otherwise cannot handle the high bandwidth connection the server has) -- You are receiving this mail because: You are the assignee for the bug.
Linking to Gitlab CD build results
Hi all, For those that have been experimenting with the Craft Continuous Delivery jobs on Gitlab, one of the many questions we've been receiving is how to best link to those from your websites. I'm happy to advise that going forward build results will now be published for release branches on mainline repositories at https://cdn.kde.org/ci-builds/. This location is fully scalable and can be freely linked to for the purpose of offering downloads of nightly builds of your projects. One key thing to note is that because Craft includes an incrementing number in the filename, you should link to the appropriate folder not the artifact directly. Additionally, please note that any slashes in branch names will be converted into dashes as part of the publishing process. Because this service is only available for release branches and master on mainline repositories, builds from personal forks, or from work branches on our mainline repositories will not be published here. Please note that this is not a home for permanent release builds. On making a release projects should download the latest build results (either from Gitlab directly or from cdn.kde.org/ci-builds/), validate them and then release them the same as any other tarball artifact. Older builds may be removed from cdn.kde.org/ci-builds/ on a periodic basis. With regards to Android and Flatpak, those will not be covered by those service. For Android builds, usage of our F-Droid repositories (at https://cdn.kde.org/android/) is recommended, while for Flatpak it is recommended to make use of the Flatpak repositories we publish at https://cdn.kde.org/flatpak/. These mechanisms are being preferred for these two as they are native to those two platforms (while Linux appimages, Windows installers and macOS images do not have those delivery mechanisms available). Thanks, Ben
Linking to Gitlab CD build results
Hi all, For those that have been experimenting with the Craft Continuous Delivery jobs on Gitlab, one of the many questions we've been receiving is how to best link to those from your websites. I'm happy to advise that going forward build results will now be published for release branches on mainline repositories at https://cdn.kde.org/ci-builds/. This location is fully scalable and can be freely linked to for the purpose of offering downloads of nightly builds of your projects. One key thing to note is that because Craft includes an incrementing number in the filename, you should link to the appropriate folder not the artifact directly. Additionally, please note that any slashes in branch names will be converted into dashes as part of the publishing process. Because this service is only available for release branches and master on mainline repositories, builds from personal forks, or from work branches on our mainline repositories will not be published here. Please note that this is not a home for permanent release builds. On making a release projects should download the latest build results (either from Gitlab directly or from cdn.kde.org/ci-builds/), validate them and then release them the same as any other tarball artifact. Older builds may be removed from cdn.kde.org/ci-builds/ on a periodic basis. With regards to Android and Flatpak, those will not be covered by those service. For Android builds, usage of our F-Droid repositories (at https://cdn.kde.org/android/) is recommended, while for Flatpak it is recommended to make use of the Flatpak repositories we publish at https://cdn.kde.org/flatpak/. These mechanisms are being preferred for these two as they are native to those two platforms (while Linux appimages, Windows installers and macOS images do not have those delivery mechanisms available). Thanks, Ben
Re: KDE Gear projects with failing CI (release/24.02) (5 March 2024)
On Wed, Mar 6, 2024 at 1:22 PM Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for > multiple > reasons. > > Good News: 7 failing repositories from previous report got fixed > > Bad news: 3 repositories are still failing and 6 new repositories started > failing > > > cantor - 3rd week > * https://invent.kde.org/education/cantor/-/pipelines/622239 > * FreeBSD tests fail > > > kimap - 2nd week > * https://invent.kde.org/pim/kimap/-/pipelines/622338 > * testsession fails on FreeBSD > > > neochat - 2nd week > * https://invent.kde.org/network/neochat/-/pipelines/622783 > * craft builds fail > > > kwave - 1st week > * https://invent.kde.org/multimedia/kwave/-/pipelines/622278 > * Linux build fails, complains that neither rsvg nor convert are > installed > KWave is now incompatible with building on OpenSUSE i'm afraid, as they don't provide rsvg as an executable under the "rsvg" name. The best they can do is rsvg-convert (which is hopefully the same thing). I suspect they removed SVG support from ImageMagick (likely for security reasons). > > > kdebugsettings - 1st week > * https://invent.kde.org/utilities/kdebugsettings/-/pipelines/622265 > * appstreamtest fails > Fix from master has now been cherry picked. > > > pim-sieve-editor - 1st week > * https://invent.kde.org/pim/pim-sieve-editor/-/pipelines/622340 > * appstreamtest fails Justin fixed this but it exposed a Flatpak failure. That fix has been cherry picked as well now. > > > > kbackup - 1st week > * https://invent.kde.org/utilities/kbackup/-/pipelines/622344 > * appstreamtest fails Should be fixed now along with master. > > > > kweather - 1st week > * https://invent.kde.org/utilities/kweather/-/pipelines/622781 > * flatpak fails, needs libplasma > > > kclock - 1st week > * https://invent.kde.org/utilities/kclock/-/pipelines/622372 > * The appstream job didn't get a runner, should this be removed? > > > Cheers, > Albert > Cheers, Ben
Re: New blogs.kde.org website
On Mon, Mar 4, 2024 at 10:07 PM David Redondo wrote: > Am Sonntag, 3. März 2024, 13:27:56 CET schrieb Carl Schwan: > > Hello, > > > > The blogs.kde.org which was powered by Drupal previously was switched > to Hugo > > this week. This is mostly relevant to the people using or interested to > use > > blogs.kde.org for their blogging need. I wrote a bit more info about > this > > here: https://blogs.kde.org/2024/03/03/new-blogs.kde.org/ > > > > Happy blogging, > > Carl > > > > Cool stuff. I think we should finally redirect blogs.kde.org to > planet.kde.org in order to only have one entry point for KDE blogs. > I'm afraid that is not possible - blogs.kde.org provides hosting for people's blogs using Hugo and therefore cannot be redirected to planet.kde.org. > > David > > Cheers, Ben
Re: KDIff3 Craft CI for MacOS broken
On Tue, Feb 27, 2024 at 1:12 PM Michael Reeves wrote: > Does anyone have insight as to why this is happeing: > > > /Resources/qml/org/kde/i18n/localeData/libki18nlocaledataqmlplugin.dylib'] > succeeded with exit code 0 > Library dependency > '/Users/gitlab/ws/builds/GZwHuM5x/0/sdk/kdiff3/macos-arm-clang/build/extragear/kdiff3/archive/Applications/KDE/kdiff3.app/Contents/Frameworks/libKF6I18nLocaleData.6.dylib' > does not exist > /Users/gitlab/ws/builds/GZwHuM5x/0/sdk/kdiff3/macos-arm-clang/build/extragear/kdiff3/archive/Applications/KDE/kdiff3.app/Contents/Resources/qml/org/kde/i18n/localeData/libki18nlocaledataqmlplugin.dylib: > Failed to add library dependency > '/Users/gitlab/ws/builds/GZwHuM5x/0/sdk/kdiff3/macos-arm-clang/build/extragear/kdiff3/archive/Applications/KDE/kdiff3.app/Contents/Frameworks/libKF6I18nLocaleData.6.dylib' > into bundle > Action: package for extragear/kdiff3:1.11 FAILED > > Hi Michael, This is extremely bad timing to be trying to do anything in the application packaging space, as the constant version bumping within Frameworks and elsewhere is causing carnage and breakage just about everywhere. See Flatpak for instance. I'd suggest waiting a good week or so before trying again, as we will need to get Craft updated to the 6.0 release made public yesterday. Have a sneaking suspicion that this will be symlink related though. Regards, Ben
Re: KDE Gear projects with failing CI (release/24.02) (28 February 2024)
On Wed, Feb 28, 2024 at 9:45 PM Sune Vuorela wrote: > On 2024-02-28, Albert Astals Cid wrote: > > konversation - 1st week > > * https://invent.kde.org/network/konversation/-/pipelines/616933 > > * cmake fails to find dbus on Linux CI > > This seems like intentional sillyness from the konversation developers. > Let's fail at build time for runtime components that are used in fringe > usecases. > My suggestion is to revert the offending commits. > Will be fixed following https://invent.kde.org/sysadmin/ci-images/-/commit/dd1c968e2d16bd96bf091365f34afdee12b39e42 and the corresponding image builds. > > /Sune > > Cheers, Ben
Re: KDE Frameworks with failing CI (master) (25 February 2024)
On Mon, Feb 26, 2024 at 11:18 AM Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for > multiple > reasons. > > Good news: 1 repository has been fixed > > Bad news: 3 NEW repository are failing > > > extra-cmake-modules - NEW > * > https://invent.kde.org/frameworks/extra-cmake-modules/-/pipelines/615155 > * "This job is stuck because the project doesn't have any runners online > assigned to it." on the "docs" job > This job is no longer needed following improvements to the process that generates api.kde.org so i've removed the job from both KF6 (master) and KF5. > > > kimageformats - NEW > * https://invent.kde.org/frameworks/kimageformats/-/pipelines/615158 > * kimageformats-read-xcf fails in Linux CI > > > kuserfeedback - NEW > * https://invent.kde.org/frameworks/kuserfeedback/-/pipelines/615161 > * flatpak fails for versioning (why does this even have a flatpak? > that's > the user case for a kuserfeedback flatpak?) > > > Cheers, > Albert > Cheers, Ben
Re: Post-MegaRelease projects
On Sat, Feb 24, 2024 at 11:35 PM Konstantin Kharlamov wrote: > On Sat, 2024-02-24 at 23:07 +1300, Ben Cooksley wrote: > > On Sat, Feb 24, 2024 at 10:27 PM Konstantin Kharlamov > wrote: > > On Sat, 2024-02-24 at 22:16 +1300, Ben Cooksley wrote: > > On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov > wrote: > > On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote: > > On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela wrote: > > On 2024-02-22, Nate Graham wrote: > > I've started pondering post-megarelease projects. We've spent so long on > > porting and bugfixing that I think it might be useful to shift gears to > > feature work, and I'd like to brainstorm potential large-scale projects > > and gauge the level of interest in putting resources into them soon. > > A bit more from the devops end that I'd love to see people tackle: > > - Ensure frameworks and app unit tests interacting with windows can run >on Windows. >More details: The following fails on our windows CI >https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp >I find it weird that we are spending resources on putting things in >the windows store and making apps available on windows, but we can't >actually have passing tests in our CI. > > > This unfortunately will not be easy to solve. > > One of the key things that we've learned out of doing CI, as has been > showcased by FreeBSD in particular, is that the builders need to be > ephemeral - that is only around for the build in question that is being run. > We're currently accomplishing this by using containers - via Podman (for > Linux/Android/FreeBSD) and Docker (for Windows). > > Containers also offer us the advantage of allowing people to easily > reproduce the CI environment on their local system without too much trouble. > > For Windows however, Microsoft has limited the container stack to not > allow anything GUI related to work. The underlying libraries may be there, > but the equivalent display server components are not operational. > > To complicate things further, on Windows certain permissions are > restricted to the interactive console and are not possible to do as either > a scheduled task or as a system service. > Usage of existing Windows automation frameworks such as Powershell > Remoting or SSH will therefore not work if we want things to perfectly > replicate a end user environment - because those will run the command(s) as > part of a non-interactive session (even if the user we connect as is the > same one logged in on the desktop console). > > > Idk if it's a silly question, but… If Windows native containers have so > many restrictions, why not just use Linux containers with WINE inside? > > > Because Wine is not Windows either, and there could be subtle differences > in how things run / interact with the system. > > > Fair point, no sw is bugless. Although, from my shallow experience WINE > seems to have an excellent test suite. I remember reporting a regression > once, which turned out to be due to some obscure surfaces manipulation by > an old Heroes Ⅲ game. WINE devs not only quickly fixed that, but they also > added tests for that case, so I'd presume such regression is just not gonna > happen anymore. > > Plus some of our software would like to test certain system level > infrastructure (like say KDE Connect). > > > Out of curiosity, what does this infrastructure include? I thought KDE > connect only uses network sockets and system tray. > > > No idea, I saw their commentary on debugging issues they were having in > their unit tests in #kde-devel. > Those issues were due to a lack of permissions, specifically around the > interactive console - that is how I know some of our tests need those > additional permissions and why running as a scheduled task / system service > will not be sufficient for "fully working" CI tests on Windows. > > > Sorry, it seems there's some misunderstanding… Judging by what you say you > seem to be referring to the restrictions that Windows containers have on > Windows. But that was the point that started this thread, to which I > replied that running Linux containers with WINE might be a solution > What i'm referring to here is that KDE Connect interacts with various components of the system in order to do what it does. See for instance the ability to share Notifications between devices, or ability to act as a presenter device. That requires accessing various system level APIs which WINE very well may not support - and we wouldn't support a scenario of using it under WINE because there is a native Linux version already. > > Plus, we have to have native Windows to compile things anyway
Re: Post-MegaRelease projects
On Sat, Feb 24, 2024 at 11:35 PM Konstantin Kharlamov wrote: > On Sat, 2024-02-24 at 23:07 +1300, Ben Cooksley wrote: > > On Sat, Feb 24, 2024 at 10:27 PM Konstantin Kharlamov > wrote: > > On Sat, 2024-02-24 at 22:16 +1300, Ben Cooksley wrote: > > On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov > wrote: > > On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote: > > On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela wrote: > > On 2024-02-22, Nate Graham wrote: > > I've started pondering post-megarelease projects. We've spent so long on > > porting and bugfixing that I think it might be useful to shift gears to > > feature work, and I'd like to brainstorm potential large-scale projects > > and gauge the level of interest in putting resources into them soon. > > A bit more from the devops end that I'd love to see people tackle: > > - Ensure frameworks and app unit tests interacting with windows can run >on Windows. >More details: The following fails on our windows CI >https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp >I find it weird that we are spending resources on putting things in >the windows store and making apps available on windows, but we can't >actually have passing tests in our CI. > > > This unfortunately will not be easy to solve. > > One of the key things that we've learned out of doing CI, as has been > showcased by FreeBSD in particular, is that the builders need to be > ephemeral - that is only around for the build in question that is being run. > We're currently accomplishing this by using containers - via Podman (for > Linux/Android/FreeBSD) and Docker (for Windows). > > Containers also offer us the advantage of allowing people to easily > reproduce the CI environment on their local system without too much trouble. > > For Windows however, Microsoft has limited the container stack to not > allow anything GUI related to work. The underlying libraries may be there, > but the equivalent display server components are not operational. > > To complicate things further, on Windows certain permissions are > restricted to the interactive console and are not possible to do as either > a scheduled task or as a system service. > Usage of existing Windows automation frameworks such as Powershell > Remoting or SSH will therefore not work if we want things to perfectly > replicate a end user environment - because those will run the command(s) as > part of a non-interactive session (even if the user we connect as is the > same one logged in on the desktop console). > > > Idk if it's a silly question, but… If Windows native containers have so > many restrictions, why not just use Linux containers with WINE inside? > > > Because Wine is not Windows either, and there could be subtle differences > in how things run / interact with the system. > > > Fair point, no sw is bugless. Although, from my shallow experience WINE > seems to have an excellent test suite. I remember reporting a regression > once, which turned out to be due to some obscure surfaces manipulation by > an old Heroes Ⅲ game. WINE devs not only quickly fixed that, but they also > added tests for that case, so I'd presume such regression is just not gonna > happen anymore. > > Plus some of our software would like to test certain system level > infrastructure (like say KDE Connect). > > > Out of curiosity, what does this infrastructure include? I thought KDE > connect only uses network sockets and system tray. > > > No idea, I saw their commentary on debugging issues they were having in > their unit tests in #kde-devel. > Those issues were due to a lack of permissions, specifically around the > interactive console - that is how I know some of our tests need those > additional permissions and why running as a scheduled task / system service > will not be sufficient for "fully working" CI tests on Windows. > > > Sorry, it seems there's some misunderstanding… Judging by what you say you > seem to be referring to the restrictions that Windows containers have on > Windows. But that was the point that started this thread, to which I > replied that running Linux containers with WINE might be a solution > What i'm referring to here is that KDE Connect interacts with various components of the system in order to do what it does. See for instance the ability to share Notifications between devices, or ability to act as a presenter device. That requires accessing various system level APIs which WINE very well may not support - and we wouldn't support a scenario of using it under WINE because there is a native Linux version already. > > Plus, we have to have native Windows to compile things anyway
Re: Post-MegaRelease projects
On Sat, Feb 24, 2024 at 10:27 PM Konstantin Kharlamov wrote: > On Sat, 2024-02-24 at 22:16 +1300, Ben Cooksley wrote: > > On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov > wrote: > > On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote: > > On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela wrote: > > On 2024-02-22, Nate Graham wrote: > > I've started pondering post-megarelease projects. We've spent so long on > > porting and bugfixing that I think it might be useful to shift gears to > > feature work, and I'd like to brainstorm potential large-scale projects > > and gauge the level of interest in putting resources into them soon. > > A bit more from the devops end that I'd love to see people tackle: > > - Ensure frameworks and app unit tests interacting with windows can run >on Windows. >More details: The following fails on our windows CI >https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp >I find it weird that we are spending resources on putting things in >the windows store and making apps available on windows, but we can't >actually have passing tests in our CI. > > > This unfortunately will not be easy to solve. > > One of the key things that we've learned out of doing CI, as has been > showcased by FreeBSD in particular, is that the builders need to be > ephemeral - that is only around for the build in question that is being run. > We're currently accomplishing this by using containers - via Podman (for > Linux/Android/FreeBSD) and Docker (for Windows). > > Containers also offer us the advantage of allowing people to easily > reproduce the CI environment on their local system without too much trouble. > > For Windows however, Microsoft has limited the container stack to not > allow anything GUI related to work. The underlying libraries may be there, > but the equivalent display server components are not operational. > > To complicate things further, on Windows certain permissions are > restricted to the interactive console and are not possible to do as either > a scheduled task or as a system service. > Usage of existing Windows automation frameworks such as Powershell > Remoting or SSH will therefore not work if we want things to perfectly > replicate a end user environment - because those will run the command(s) as > part of a non-interactive session (even if the user we connect as is the > same one logged in on the desktop console). > > > Idk if it's a silly question, but… If Windows native containers have so > many restrictions, why not just use Linux containers with WINE inside? > > > Because Wine is not Windows either, and there could be subtle differences > in how things run / interact with the system. > Plus some of our software would like to test certain system level > infrastructure (like say KDE Connect). > > > Out of curiosity, what does this infrastructure include? I thought KDE > connect only uses network sockets and system tray. > No idea, I saw their commentary on debugging issues they were having in their unit tests in #kde-devel. Those issues were due to a lack of permissions, specifically around the interactive console - that is how I know some of our tests need those additional permissions and why running as a scheduled task / system service will not be sufficient for "fully working" CI tests on Windows. > > Plus, we have to have native Windows to compile things anyway as we need > to use MSVC (otherwise you have no Qt Web Engine support, as that cannot be > built with MingW) > > > But I presume it can be built with Clang? In particular, Google Chrome on > Windows is being built with Clang — and Web Engine is basically a fork of > Chromium. > Qt 6 as a whole does not list Clang as a supported compiler - see https://doc.qt.io/qt-6/supported-platforms.html Given Windows is a bit strange in the first place, i'd be quite reluctant to step outside of what they list as supported. > > (and you cannot really mix MingW / MSVC binaries due to incompatible > compiler ABIs for C++ code) > > > Well, if for testing purposes Qt was pre-built with Clang, I guess there > won't be any ABI issues. > Would require that everything else we have is rebuilt, and that all downstream users of our Craft cache also switch to Clang. Note that like most open source projects, we don't know the full extent to which Craft is used outside of our own project. Historically we have seen through Microsoft provided data that dependencies which we built and signed have shown up in surprising places (such as Snoretoast - which was used by something Node.js based at one point or another I believe) Cheers, Ben
Re: Post-MegaRelease projects
On Sat, Feb 24, 2024 at 10:27 PM Konstantin Kharlamov wrote: > On Sat, 2024-02-24 at 22:16 +1300, Ben Cooksley wrote: > > On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov > wrote: > > On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote: > > On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela wrote: > > On 2024-02-22, Nate Graham wrote: > > I've started pondering post-megarelease projects. We've spent so long on > > porting and bugfixing that I think it might be useful to shift gears to > > feature work, and I'd like to brainstorm potential large-scale projects > > and gauge the level of interest in putting resources into them soon. > > A bit more from the devops end that I'd love to see people tackle: > > - Ensure frameworks and app unit tests interacting with windows can run >on Windows. >More details: The following fails on our windows CI >https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp >I find it weird that we are spending resources on putting things in >the windows store and making apps available on windows, but we can't >actually have passing tests in our CI. > > > This unfortunately will not be easy to solve. > > One of the key things that we've learned out of doing CI, as has been > showcased by FreeBSD in particular, is that the builders need to be > ephemeral - that is only around for the build in question that is being run. > We're currently accomplishing this by using containers - via Podman (for > Linux/Android/FreeBSD) and Docker (for Windows). > > Containers also offer us the advantage of allowing people to easily > reproduce the CI environment on their local system without too much trouble. > > For Windows however, Microsoft has limited the container stack to not > allow anything GUI related to work. The underlying libraries may be there, > but the equivalent display server components are not operational. > > To complicate things further, on Windows certain permissions are > restricted to the interactive console and are not possible to do as either > a scheduled task or as a system service. > Usage of existing Windows automation frameworks such as Powershell > Remoting or SSH will therefore not work if we want things to perfectly > replicate a end user environment - because those will run the command(s) as > part of a non-interactive session (even if the user we connect as is the > same one logged in on the desktop console). > > > Idk if it's a silly question, but… If Windows native containers have so > many restrictions, why not just use Linux containers with WINE inside? > > > Because Wine is not Windows either, and there could be subtle differences > in how things run / interact with the system. > Plus some of our software would like to test certain system level > infrastructure (like say KDE Connect). > > > Out of curiosity, what does this infrastructure include? I thought KDE > connect only uses network sockets and system tray. > No idea, I saw their commentary on debugging issues they were having in their unit tests in #kde-devel. Those issues were due to a lack of permissions, specifically around the interactive console - that is how I know some of our tests need those additional permissions and why running as a scheduled task / system service will not be sufficient for "fully working" CI tests on Windows. > > Plus, we have to have native Windows to compile things anyway as we need > to use MSVC (otherwise you have no Qt Web Engine support, as that cannot be > built with MingW) > > > But I presume it can be built with Clang? In particular, Google Chrome on > Windows is being built with Clang — and Web Engine is basically a fork of > Chromium. > Qt 6 as a whole does not list Clang as a supported compiler - see https://doc.qt.io/qt-6/supported-platforms.html Given Windows is a bit strange in the first place, i'd be quite reluctant to step outside of what they list as supported. > > (and you cannot really mix MingW / MSVC binaries due to incompatible > compiler ABIs for C++ code) > > > Well, if for testing purposes Qt was pre-built with Clang, I guess there > won't be any ABI issues. > Would require that everything else we have is rebuilt, and that all downstream users of our Craft cache also switch to Clang. Note that like most open source projects, we don't know the full extent to which Craft is used outside of our own project. Historically we have seen through Microsoft provided data that dependencies which we built and signed have shown up in surprising places (such as Snoretoast - which was used by something Node.js based at one point or another I believe) Cheers, Ben
Re: Post-MegaRelease projects
On Sat, Feb 24, 2024 at 9:21 PM Volker Krause wrote: > On Saturday, 24 February 2024 04:31:49 CET Ben Cooksley wrote: > > On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela wrote: > > > On 2024-02-22, Nate Graham wrote: > > > > I've started pondering post-megarelease projects. We've spent so > long on > > > > porting and bugfixing that I think it might be useful to shift gears > to > > > > feature work, and I'd like to brainstorm potential large-scale > projects > > > > and gauge the level of interest in putting resources into them soon. > > > > > > A bit more from the devops end that I'd love to see people tackle: > > > - Ensure frameworks and app unit tests interacting with windows can > run > > > > > >on Windows. > > >More details: The following fails on our windows CI > > > > https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp > > >I find it weird that we are spending resources on putting things in > > >the windows store and making apps available on windows, but we can't > > >actually have passing tests in our CI. > > > > This unfortunately will not be easy to solve. > > And that's fine, we are in dreaming territory here anyway :) > > > One of the key things that we've learned out of doing CI, as has been > > showcased by FreeBSD in particular, is that the builders need to be > > ephemeral - that is only around for the build in question that is being > run. > > We're currently accomplishing this by using containers - via Podman (for > > Linux/Android/FreeBSD) and Docker (for Windows). > > > > Containers also offer us the advantage of allowing people to easily > > reproduce the CI environment on their local system without too much > trouble. > > > > For Windows however, Microsoft has limited the container stack to not > allow > > anything GUI related to work. The underlying libraries may be there, but > > the equivalent display server components are not operational. > > > > To complicate things further, on Windows certain permissions are > restricted > > to the interactive console and are not possible to do as either a > scheduled > > task or as a system service. > > Usage of existing Windows automation frameworks such as Powershell > Remoting > > or SSH will therefore not work if we want things to perfectly replicate a > > end user environment - because those will run the command(s) as part of a > > non-interactive session (even if the user we connect as is the same one > > logged in on the desktop console). > > > > Resolving this will therefore not only require running full sized Windows > > VMs (on an ephemeral basis to avoid the recently resolved issues that > used > > to plague FreeBSD), but would also need the VM to automatically login and > > spawn an agent as part of the interactive desktop session that we would > > connect to in order to run the CI tests. > > > > The spawning of a VM would require refactoring the setup of our poor CI > > workers (again - after they were only just recently completely rebuilt to > > allow the transition to Podman to fix flatpak-builder) to make use of > > something like: > > - > > > https://forum.gitlab.com/t/custom-executor-into-windows-vm-using-linux-kvm-l > > ibvirt/72713/5 - > > https://docs.gitlab.com/runner/executors/custom_examples/libvirt.html > > > > We would still have to write the agent that receives our commands > > (something like > > https://gist.github.com/cschwede/3e2c025408ab4af531651098331cce45 maybe) > > > > We would still have to solve the issue of how to share disk images among > > our nodes so they were built (ideally would be able to use Gitlab's > > Container Registry for this, which is something Tart can do - Tart being > a > > virtualisation management utility for ARM based Macs), as well as > > automating the installation of the various OSes we need to run this way. > > See > > > https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/autom > > ate-windows-setup?view=windows-11 for some notes on that for Windows. > > > > The big downside to all of that of course is that the worker nodes would > > take longer to startup, and it would make sharing build artifacts much > more > > difficult and/or less efficient. > > > > > - Find a way to run unit tests on android CI. > > > > Likewise, this is very non-trivial - from my understanding our tooling > > currently for building Android software is centered around it all b
Re: Post-MegaRelease projects
On Sat, Feb 24, 2024 at 9:21 PM Volker Krause wrote: > On Saturday, 24 February 2024 04:31:49 CET Ben Cooksley wrote: > > On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela wrote: > > > On 2024-02-22, Nate Graham wrote: > > > > I've started pondering post-megarelease projects. We've spent so > long on > > > > porting and bugfixing that I think it might be useful to shift gears > to > > > > feature work, and I'd like to brainstorm potential large-scale > projects > > > > and gauge the level of interest in putting resources into them soon. > > > > > > A bit more from the devops end that I'd love to see people tackle: > > > - Ensure frameworks and app unit tests interacting with windows can > run > > > > > >on Windows. > > >More details: The following fails on our windows CI > > > > https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp > > >I find it weird that we are spending resources on putting things in > > >the windows store and making apps available on windows, but we can't > > >actually have passing tests in our CI. > > > > This unfortunately will not be easy to solve. > > And that's fine, we are in dreaming territory here anyway :) > > > One of the key things that we've learned out of doing CI, as has been > > showcased by FreeBSD in particular, is that the builders need to be > > ephemeral - that is only around for the build in question that is being > run. > > We're currently accomplishing this by using containers - via Podman (for > > Linux/Android/FreeBSD) and Docker (for Windows). > > > > Containers also offer us the advantage of allowing people to easily > > reproduce the CI environment on their local system without too much > trouble. > > > > For Windows however, Microsoft has limited the container stack to not > allow > > anything GUI related to work. The underlying libraries may be there, but > > the equivalent display server components are not operational. > > > > To complicate things further, on Windows certain permissions are > restricted > > to the interactive console and are not possible to do as either a > scheduled > > task or as a system service. > > Usage of existing Windows automation frameworks such as Powershell > Remoting > > or SSH will therefore not work if we want things to perfectly replicate a > > end user environment - because those will run the command(s) as part of a > > non-interactive session (even if the user we connect as is the same one > > logged in on the desktop console). > > > > Resolving this will therefore not only require running full sized Windows > > VMs (on an ephemeral basis to avoid the recently resolved issues that > used > > to plague FreeBSD), but would also need the VM to automatically login and > > spawn an agent as part of the interactive desktop session that we would > > connect to in order to run the CI tests. > > > > The spawning of a VM would require refactoring the setup of our poor CI > > workers (again - after they were only just recently completely rebuilt to > > allow the transition to Podman to fix flatpak-builder) to make use of > > something like: > > - > > > https://forum.gitlab.com/t/custom-executor-into-windows-vm-using-linux-kvm-l > > ibvirt/72713/5 - > > https://docs.gitlab.com/runner/executors/custom_examples/libvirt.html > > > > We would still have to write the agent that receives our commands > > (something like > > https://gist.github.com/cschwede/3e2c025408ab4af531651098331cce45 maybe) > > > > We would still have to solve the issue of how to share disk images among > > our nodes so they were built (ideally would be able to use Gitlab's > > Container Registry for this, which is something Tart can do - Tart being > a > > virtualisation management utility for ARM based Macs), as well as > > automating the installation of the various OSes we need to run this way. > > See > > > https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/autom > > ate-windows-setup?view=windows-11 for some notes on that for Windows. > > > > The big downside to all of that of course is that the worker nodes would > > take longer to startup, and it would make sharing build artifacts much > more > > difficult and/or less efficient. > > > > > - Find a way to run unit tests on android CI. > > > > Likewise, this is very non-trivial - from my understanding our tooling > > currently for building Android software is centered around it all b
Re: Post-MegaRelease projects
On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov wrote: > On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote: > > On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela wrote: > > On 2024-02-22, Nate Graham wrote: > > I've started pondering post-megarelease projects. We've spent so long on > > porting and bugfixing that I think it might be useful to shift gears to > > feature work, and I'd like to brainstorm potential large-scale projects > > and gauge the level of interest in putting resources into them soon. > > A bit more from the devops end that I'd love to see people tackle: > > - Ensure frameworks and app unit tests interacting with windows can run >on Windows. >More details: The following fails on our windows CI >https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp >I find it weird that we are spending resources on putting things in >the windows store and making apps available on windows, but we can't >actually have passing tests in our CI. > > > This unfortunately will not be easy to solve. > > One of the key things that we've learned out of doing CI, as has been > showcased by FreeBSD in particular, is that the builders need to be > ephemeral - that is only around for the build in question that is being run. > We're currently accomplishing this by using containers - via Podman (for > Linux/Android/FreeBSD) and Docker (for Windows). > > Containers also offer us the advantage of allowing people to easily > reproduce the CI environment on their local system without too much trouble. > > For Windows however, Microsoft has limited the container stack to not > allow anything GUI related to work. The underlying libraries may be there, > but the equivalent display server components are not operational. > > To complicate things further, on Windows certain permissions are > restricted to the interactive console and are not possible to do as either > a scheduled task or as a system service. > Usage of existing Windows automation frameworks such as Powershell > Remoting or SSH will therefore not work if we want things to perfectly > replicate a end user environment - because those will run the command(s) as > part of a non-interactive session (even if the user we connect as is the > same one logged in on the desktop console). > > > Idk if it's a silly question, but… If Windows native containers have so > many restrictions, why not just use Linux containers with WINE inside? > Because Wine is not Windows either, and there could be subtle differences in how things run / interact with the system. Plus some of our software would like to test certain system level infrastructure (like say KDE Connect). Plus, we have to have native Windows to compile things anyway as we need to use MSVC (otherwise you have no Qt Web Engine support, as that cannot be built with MingW) (and you cannot really mix MingW / MSVC binaries due to incompatible compiler ABIs for C++ code) Cheers, Ben
Re: Post-MegaRelease projects
On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov wrote: > On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote: > > On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela wrote: > > On 2024-02-22, Nate Graham wrote: > > I've started pondering post-megarelease projects. We've spent so long on > > porting and bugfixing that I think it might be useful to shift gears to > > feature work, and I'd like to brainstorm potential large-scale projects > > and gauge the level of interest in putting resources into them soon. > > A bit more from the devops end that I'd love to see people tackle: > > - Ensure frameworks and app unit tests interacting with windows can run >on Windows. >More details: The following fails on our windows CI >https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp >I find it weird that we are spending resources on putting things in >the windows store and making apps available on windows, but we can't >actually have passing tests in our CI. > > > This unfortunately will not be easy to solve. > > One of the key things that we've learned out of doing CI, as has been > showcased by FreeBSD in particular, is that the builders need to be > ephemeral - that is only around for the build in question that is being run. > We're currently accomplishing this by using containers - via Podman (for > Linux/Android/FreeBSD) and Docker (for Windows). > > Containers also offer us the advantage of allowing people to easily > reproduce the CI environment on their local system without too much trouble. > > For Windows however, Microsoft has limited the container stack to not > allow anything GUI related to work. The underlying libraries may be there, > but the equivalent display server components are not operational. > > To complicate things further, on Windows certain permissions are > restricted to the interactive console and are not possible to do as either > a scheduled task or as a system service. > Usage of existing Windows automation frameworks such as Powershell > Remoting or SSH will therefore not work if we want things to perfectly > replicate a end user environment - because those will run the command(s) as > part of a non-interactive session (even if the user we connect as is the > same one logged in on the desktop console). > > > Idk if it's a silly question, but… If Windows native containers have so > many restrictions, why not just use Linux containers with WINE inside? > Because Wine is not Windows either, and there could be subtle differences in how things run / interact with the system. Plus some of our software would like to test certain system level infrastructure (like say KDE Connect). Plus, we have to have native Windows to compile things anyway as we need to use MSVC (otherwise you have no Qt Web Engine support, as that cannot be built with MingW) (and you cannot really mix MingW / MSVC binaries due to incompatible compiler ABIs for C++ code) Cheers, Ben
Re: Post-MegaRelease projects
On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela wrote: > On 2024-02-22, Nate Graham wrote: > > I've started pondering post-megarelease projects. We've spent so long on > > porting and bugfixing that I think it might be useful to shift gears to > > feature work, and I'd like to brainstorm potential large-scale projects > > and gauge the level of interest in putting resources into them soon. > > A bit more from the devops end that I'd love to see people tackle: > > - Ensure frameworks and app unit tests interacting with windows can run >on Windows. >More details: The following fails on our windows CI >https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp >I find it weird that we are spending resources on putting things in >the windows store and making apps available on windows, but we can't >actually have passing tests in our CI. > This unfortunately will not be easy to solve. One of the key things that we've learned out of doing CI, as has been showcased by FreeBSD in particular, is that the builders need to be ephemeral - that is only around for the build in question that is being run. We're currently accomplishing this by using containers - via Podman (for Linux/Android/FreeBSD) and Docker (for Windows). Containers also offer us the advantage of allowing people to easily reproduce the CI environment on their local system without too much trouble. For Windows however, Microsoft has limited the container stack to not allow anything GUI related to work. The underlying libraries may be there, but the equivalent display server components are not operational. To complicate things further, on Windows certain permissions are restricted to the interactive console and are not possible to do as either a scheduled task or as a system service. Usage of existing Windows automation frameworks such as Powershell Remoting or SSH will therefore not work if we want things to perfectly replicate a end user environment - because those will run the command(s) as part of a non-interactive session (even if the user we connect as is the same one logged in on the desktop console). Resolving this will therefore not only require running full sized Windows VMs (on an ephemeral basis to avoid the recently resolved issues that used to plague FreeBSD), but would also need the VM to automatically login and spawn an agent as part of the interactive desktop session that we would connect to in order to run the CI tests. The spawning of a VM would require refactoring the setup of our poor CI workers (again - after they were only just recently completely rebuilt to allow the transition to Podman to fix flatpak-builder) to make use of something like: - https://forum.gitlab.com/t/custom-executor-into-windows-vm-using-linux-kvm-libvirt/72713/5 - https://docs.gitlab.com/runner/executors/custom_examples/libvirt.html We would still have to write the agent that receives our commands (something like https://gist.github.com/cschwede/3e2c025408ab4af531651098331cce45 maybe) We would still have to solve the issue of how to share disk images among our nodes so they were built (ideally would be able to use Gitlab's Container Registry for this, which is something Tart can do - Tart being a virtualisation management utility for ARM based Macs), as well as automating the installation of the various OSes we need to run this way. See https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/automate-windows-setup?view=windows-11 for some notes on that for Windows. The big downside to all of that of course is that the worker nodes would take longer to startup, and it would make sharing build artifacts much more difficult and/or less efficient. > > - Find a way to run unit tests on android CI. > Likewise, this is very non-trivial - from my understanding our tooling currently for building Android software is centered around it all being cross compiled rather than being built on the native architecture it will be run on. Naturally tests cannot be run (unless you emulate, which I guess we could consider...) if the CPU architectures are not compatible. Even if you emulate though, I imagine we would need to provide a full Android system setup (including all of it's relevant bits of system infrastructure, such as it's display server DisplayFlinger) in order for tests to truly be of use. The path of least resistance is probably by making use of Google's existing Android emulator - although i've no idea how you would tie that into CI. We would need to have our build chains ready to build on a native system before we could think about this I think. Building Android x86/x64 wouldn't cover things off properly due as it won't reflect the actual CPUs being used on end-user devices (and ARM processors can expose issues that don't happen on x86/x64 based systems) > > - Make autotests guarding on all our CI's. > > - Clazy and clang-tidy and cppcheck on all our repositories in CI > > /Sune > Hopefully
Re: Post-MegaRelease projects
On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela wrote: > On 2024-02-22, Nate Graham wrote: > > I've started pondering post-megarelease projects. We've spent so long on > > porting and bugfixing that I think it might be useful to shift gears to > > feature work, and I'd like to brainstorm potential large-scale projects > > and gauge the level of interest in putting resources into them soon. > > A bit more from the devops end that I'd love to see people tackle: > > - Ensure frameworks and app unit tests interacting with windows can run >on Windows. >More details: The following fails on our windows CI >https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp >I find it weird that we are spending resources on putting things in >the windows store and making apps available on windows, but we can't >actually have passing tests in our CI. > This unfortunately will not be easy to solve. One of the key things that we've learned out of doing CI, as has been showcased by FreeBSD in particular, is that the builders need to be ephemeral - that is only around for the build in question that is being run. We're currently accomplishing this by using containers - via Podman (for Linux/Android/FreeBSD) and Docker (for Windows). Containers also offer us the advantage of allowing people to easily reproduce the CI environment on their local system without too much trouble. For Windows however, Microsoft has limited the container stack to not allow anything GUI related to work. The underlying libraries may be there, but the equivalent display server components are not operational. To complicate things further, on Windows certain permissions are restricted to the interactive console and are not possible to do as either a scheduled task or as a system service. Usage of existing Windows automation frameworks such as Powershell Remoting or SSH will therefore not work if we want things to perfectly replicate a end user environment - because those will run the command(s) as part of a non-interactive session (even if the user we connect as is the same one logged in on the desktop console). Resolving this will therefore not only require running full sized Windows VMs (on an ephemeral basis to avoid the recently resolved issues that used to plague FreeBSD), but would also need the VM to automatically login and spawn an agent as part of the interactive desktop session that we would connect to in order to run the CI tests. The spawning of a VM would require refactoring the setup of our poor CI workers (again - after they were only just recently completely rebuilt to allow the transition to Podman to fix flatpak-builder) to make use of something like: - https://forum.gitlab.com/t/custom-executor-into-windows-vm-using-linux-kvm-libvirt/72713/5 - https://docs.gitlab.com/runner/executors/custom_examples/libvirt.html We would still have to write the agent that receives our commands (something like https://gist.github.com/cschwede/3e2c025408ab4af531651098331cce45 maybe) We would still have to solve the issue of how to share disk images among our nodes so they were built (ideally would be able to use Gitlab's Container Registry for this, which is something Tart can do - Tart being a virtualisation management utility for ARM based Macs), as well as automating the installation of the various OSes we need to run this way. See https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/automate-windows-setup?view=windows-11 for some notes on that for Windows. The big downside to all of that of course is that the worker nodes would take longer to startup, and it would make sharing build artifacts much more difficult and/or less efficient. > > - Find a way to run unit tests on android CI. > Likewise, this is very non-trivial - from my understanding our tooling currently for building Android software is centered around it all being cross compiled rather than being built on the native architecture it will be run on. Naturally tests cannot be run (unless you emulate, which I guess we could consider...) if the CPU architectures are not compatible. Even if you emulate though, I imagine we would need to provide a full Android system setup (including all of it's relevant bits of system infrastructure, such as it's display server DisplayFlinger) in order for tests to truly be of use. The path of least resistance is probably by making use of Google's existing Android emulator - although i've no idea how you would tie that into CI. We would need to have our build chains ready to build on a native system before we could think about this I think. Building Android x86/x64 wouldn't cover things off properly due as it won't reflect the actual CPUs being used on end-user devices (and ARM processors can expose issues that don't happen on x86/x64 based systems) > > - Make autotests guarding on all our CI's. > > - Clazy and clang-tidy and cppcheck on all our repositories in CI > > /Sune > Hopefully
[bugs.kde.org] [Bug 481732] Delete my Account
https://bugs.kde.org/show_bug.cgi?id=481732 Ben Cooksley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Ben Cooksley --- Account has been closed now. -- You are receiving this mail because: You are watching all bug changes.
[bugs.kde.org] [Bug 481732] Delete my Account
https://bugs.kde.org/show_bug.cgi?id=481732 Ben Cooksley changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|ASSIGNED --- Comment #1 from Ben Cooksley --- This is the last email you will receive from Bugzilla, your account has been scheduled for removal. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 481483] force close applications
https://bugs.kde.org/show_bug.cgi?id=481483 --- Comment #4 from Ben Cooksley --- The bug has now been cleansed of the sensitive information. -- You are receiving this mail because: You are watching all bug changes.
Re: KDE Gear projects with failing CI (master) (20 February 2024)
On Wed, Feb 21, 2024 at 12:01 PM Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI jobs on > their 4th failing week, it is very important that CI is passing for > multiple > reasons. > > VERY BAD NEWS: > * Cantor made it to its 4th week with FreeBSD tests failing > * I have disabled them > * > https://invent.kde.org/education/cantor/-/commit/0f94f381bda4d8f7f52a432d0a846c2ca6bee1e8 > > Good news: 8 repositories got fixed > > Bad news: 2 repo still failing and 5 new this week > > ark - 3rd week > * https://invent.kde.org/utilities/ark/-/pipelines/611869 > * tests fail on FreeBSD > Wonder if the tests properly handle umask being set? > > > merkuro - 3rd week > * https://invent.kde.org/pim/merkuro/-/pipelines/611879 > * tests fail on FreeBSD > > > korganizer - 1st week > * https://invent.kde.org/pim/korganizer/-/pipelines/611877 > * Fails to compile, complains about Akonadi::CollectionCalendar > constructor > Going to assume this is just poor propagation of API changes within PIM. I have triggered the seed jobs for PIM for all platforms, across both master and stable to cleanup the breakage. > > > klickety - 1st week > * https://invent.kde.org/games/klickety/-/pipelines/611870 > * appstreamtest fails on FreeBSD > Fixed now by the FreeBSD image rebuild. > > > okular - 1st week > * https://invent.kde.org/graphics/okular/-/pipelines/611868 > * Android fails to compile >* It works for me locally so help needed > Possibly caused by different versions of the Android SDK/NDK - do we need to rebuild everything due to BIC in Android? The Android images have been rebuilt in the past week which may have caused this. > > keysmith - 1st week > * https://invent.kde.org/utilities/keysmith/-/pipelines/611882 > * craft android builds fail > Looks like it depends on Qt5Compat but misses the dependency that was previously dragged in transitively. Will need a fix to the Craft blueprint for Keysmith. > > > kbruch - 1st week > * https://invent.kde.org/education/kbruch/-/pipelines/611867 > * craft window build fails, but i don't see any error? > > Cheers, > Albert > Cheers, Ben
