Re: KDE Gear projects with failing CI (release/24.05) (14 May 2024)
On Mittwoch, 15. Mai 2024 01:24:47 CEST Albert Astals Cid wrote: > kimap - 2nd week > * https://invent.kde.org/pim/kimap/-/pipelines/688337 > * freebsd tests fail >* This seems to work on master, can we backport the fix? Unfortunately not, there is no corresponding change in master, this is a notoriously unstable test. Regards, Volker signature.asc Description: This is a digitally signed message part.
[KDE Itinerary] [Bug 486495] Importing Indian rail ticket PDF does not import departure time
https://bugs.kde.org/show_bug.cgi?id=486495 Volker Krause changed: What|Removed |Added Latest Commit|https://invent.kde.org/pim/ |https://invent.kde.org/pim/ |kitinerary/-/commit/e51ef8f |kitinerary/-/commit/6074f00 |70420e3381d29504fa951252108 |2d9e754b33ac1808805dbb38c92 |9c1936 |eba07c --- Comment #2 from Volker Krause --- Git commit 6074f002d9e754b33ac1808805dbb38c92eba07c by Volker Krause. Committed on 03/05/2024 at 16:47. Pushed by vkrause into branch 'release/24.05'. Fix IRCTC departure time extraction There's apparently a second date/time format in use here, support that as well. (cherry picked from commit e51ef8f70420e3381d29504fa9512521089c1936) M +5-2src/lib/scripts/irctc.js https://invent.kde.org/pim/kitinerary/-/commit/6074f002d9e754b33ac1808805dbb38c92eba07c -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 486495] Importing Indian rail ticket PDF does not import departure time
https://bugs.kde.org/show_bug.cgi?id=486495 Volker Krause changed: What|Removed |Added Resolution|--- |FIXED Latest Commit||https://invent.kde.org/pim/ ||kitinerary/-/commit/e51ef8f ||70420e3381d29504fa951252108 ||9c1936 Status|REPORTED|RESOLVED --- Comment #1 from Volker Krause --- Git commit e51ef8f70420e3381d29504fa9512521089c1936 by Volker Krause. Committed on 03/05/2024 at 16:23. Pushed by vkrause into branch 'master'. Fix IRCTC departure time extraction There's apparently a second date/time format in use here, support that as well. M +5-2src/lib/scripts/irctc.js https://invent.kde.org/pim/kitinerary/-/commit/e51ef8f70420e3381d29504fa9512521089c1936 -- You are receiving this mail because: You are watching all bug changes.
Re: KDE Gear projects with failing CI (master) (30 April 2024)
On Mittwoch, 1. Mai 2024 02:40:16 CEST 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 The remaining Craft errors there should be solved by https://invent.kde.org/packaging/craft-blueprints-kde/-/merge_requests/833 signature.asc Description: This is a digitally signed message part.
[KDE Itinerary] [Bug 485004] Several issues with VR (Finish operator) imported train tickets
https://bugs.kde.org/show_bug.cgi?id=485004 --- Comment #16 from Volker Krause --- As I said 6 is only fixed in 24.05, so seeing that still if you are testing with 24.02.2 is expected. The new samples you sent me work here on initial testing, I have yet to find out why some of those are broken for you. -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 415613] KLM Flight booking not imported from pdf ticket
https://bugs.kde.org/show_bug.cgi?id=415613 --- Comment #4 from Volker Krause --- (In reply to Yogesh from comment #3) > This issue is affecting me too on the latest nightly version - 24.04.70 > (f883f40). The PDF ticket is pretty barebones and does not have any QR code. > I have mailed the PDF to you. Thanks! This looks like a web page printed to a PDF though? That is unfortunately not something we can easily consume at the moment. -- You are receiving this mail because: You are watching all bug changes.
Re: Proposal unify back our release schedules
On Sunday, 21 April 2024 00:37:03 CEST Ben Cooksley wrote: > 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 One approach to solve that is/was to actually turn those into frameworks. A bunch of PIM libraries were moved over time (KContacts, KCalendarCore, KDAV, etc) already. More were lined up, the KF6 transition just put a pause on that, but e.g. KMime not too long ago received a bunch of API fixes in preparation for this. However, before continuing down that road I'd like to see a decision on the KF release schedule first now. With a much longer release cycle this becomes a lot less interesting to do. Regards, Volker signature.asc Description: This is a digitally signed message part.
[KDE Itinerary] [Bug 485004] Several issues with VR (Finish operator) imported train tickets
https://bugs.kde.org/show_bug.cgi?id=485004 --- Comment #13 from Volker Krause --- 1, 2, 3, 4, 8 and 9 should be fixed in 24.02.2, but it will require a re-import of the tickets. 6 and 7 are only fixed in 24.05, but should work without re-importing. 5 is hopefully fixed in 24.05 as well, but I have no way to verify that in a Finnish network unfortunately. -- You are receiving this mail because: You are watching all bug changes.
Re: Proposal unify back our release schedules
On Freitag, 19. April 2024 11:04:33 CEST Carl Schwan wrote: > * 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. The fast feature-releases of KF have major advantages though, comparing to how things worked prior to 5. They allow apps to work against released (and thus distro-packaged) frameworks while still making it practical to contribute needed features to KF directly. The alternatives are: * Depend on KF master (like Plasma does), significantly increasing the threshold of entry for new contributors, especially for more self-contained apps, where you'd now have to build 70+ repos rather than a few. * Depend on the latest release but develop new features locally rather than in KF. I'm not sure whether we have meanwhile finally cleaned up all the forked kdelibs classes in PIM from the 3 and 4 era due to that. * Depend on the latest release and wait for new features to become available before making use of them in the app, effectively increasing the delay to reach users to twice the release cycle. Ie. this makes contributing to KF less attractive from an app developer perspective. The main issues with out-of-sync KF and Plasma should have been solved with some frameworks being moved to Plasma with KF6, if there is more of this remaining we should look at the specific cases, for the vast majority of frameworks I don't think we have a problem there. > * Helps with outside usage of our frameworks. These didn't get as much > success as we were hoping when splitting. I think having a stable branch > for Framework might help but this is only a guess. It would be interesting > to know of cases where people considered using some Framework and to know > why they decided against or for it and if this proposal would helps or not. I disagree with the often repeated statement that this wasn't successful. It might not happened as widely and visibly as we might want, but KF is most certainly used vastly more often than kdelibs ever was. And the release schedule isn't the impediment here, it's things like dependencies and the build system making it hard to vendor copies. > In effect this proposal would mean: > > * We do one major release every 4 months and then minor releases with a > frequency based on the Fibonacci numbers as this releases cycle works very > well for Plasma. Naming could be either YY.MM or Major.Minor.Path. We could > unify that for one or the other one. Or let each component keep their > current versioning scheme depending whether we want to merge Plama and Gear > as product or keep it separate. I'm a bit undecided about this. >From my app developer perspective that is fine, Fibonacci rather than equidistant patch releases look like an improvement to me. However, assuming the feature release interval basically remains the same. AFAIK Plasma is discussing a 6 month interval though, and I do understand longer cycles are better for promo, but it means users have to wait longer for features. It therefore also matters whether we are tying Plasma's release to Gear or Gear's releases to Plasma here. > * "KDE Framework" will still exists as an entity and its ABI and API > compatibility requirement. Only change is the release frequency and the > introduction of a stable branch in sync with the other components. That part I'm against for the above mentioned reasons, KF's release frequency is a major feature of it. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Proposal unify back our release schedules
On Freitag, 19. April 2024 11:04:33 CEST Carl Schwan wrote: > * 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. The fast feature-releases of KF have major advantages though, comparing to how things worked prior to 5. They allow apps to work against released (and thus distro-packaged) frameworks while still making it practical to contribute needed features to KF directly. The alternatives are: * Depend on KF master (like Plasma does), significantly increasing the threshold of entry for new contributors, especially for more self-contained apps, where you'd now have to build 70+ repos rather than a few. * Depend on the latest release but develop new features locally rather than in KF. I'm not sure whether we have meanwhile finally cleaned up all the forked kdelibs classes in PIM from the 3 and 4 era due to that. * Depend on the latest release and wait for new features to become available before making use of them in the app, effectively increasing the delay to reach users to twice the release cycle. Ie. this makes contributing to KF less attractive from an app developer perspective. The main issues with out-of-sync KF and Plasma should have been solved with some frameworks being moved to Plasma with KF6, if there is more of this remaining we should look at the specific cases, for the vast majority of frameworks I don't think we have a problem there. > * Helps with outside usage of our frameworks. These didn't get as much > success as we were hoping when splitting. I think having a stable branch > for Framework might help but this is only a guess. It would be interesting > to know of cases where people considered using some Framework and to know > why they decided against or for it and if this proposal would helps or not. I disagree with the often repeated statement that this wasn't successful. It might not happened as widely and visibly as we might want, but KF is most certainly used vastly more often than kdelibs ever was. And the release schedule isn't the impediment here, it's things like dependencies and the build system making it hard to vendor copies. > In effect this proposal would mean: > > * We do one major release every 4 months and then minor releases with a > frequency based on the Fibonacci numbers as this releases cycle works very > well for Plasma. Naming could be either YY.MM or Major.Minor.Path. We could > unify that for one or the other one. Or let each component keep their > current versioning scheme depending whether we want to merge Plama and Gear > as product or keep it separate. I'm a bit undecided about this. >From my app developer perspective that is fine, Fibonacci rather than equidistant patch releases look like an improvement to me. However, assuming the feature release interval basically remains the same. AFAIK Plasma is discussing a 6 month interval though, and I do understand longer cycles are better for promo, but it means users have to wait longer for features. It therefore also matters whether we are tying Plasma's release to Gear or Gear's releases to Plasma here. > * "KDE Framework" will still exists as an entity and its ABI and API > compatibility requirement. Only change is the release frequency and the > introduction of a stable branch in sync with the other components. That part I'm against for the above mentioned reasons, KF's release frequency is a major feature of it. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (16 April 2024)
On Dienstag, 16. April 2024 23:27:36 CEST Albert Astals Cid wrote: > itinerary - NEW > * https://invent.kde.org/pim/itinerary/-/pipelines/664435 > * craft android builds fail to compile libquotient https://invent.kde.org/packaging/craft-blueprints-kde/-/merge_requests/846 (also affects NeoChat) signature.asc Description: This is a digitally signed message part.
Re: Moving KUnifiedPush to KDE Gear
On Montag, 15. April 2024 23:22:00 CEST Albert Astals Cid wrote: > El dilluns, 15 d’abril del 2024, a les 18:06:30 (CEST), Volker Krause va > > escriure: > > Hi, > > > > I'd like to propose the KUnifiedPush library > > (https://invent.kde.org/libraries/ kunifiedpush) for inclusion in KDE > > Gear. > > My answer when someone else asked the same question for other apps on Matrix > this morning. > > I'd say feels a bit late with dependency freeze in 3 days and freeze freeze > in 10. > > I'd prefer 2 weeks before dependency freeze, could live with 2 weeks before > freeze freeze. [1] > > Can we wait for 24.08 for this? Fair enough, we can fill the gap with manual releases if needed. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks with failing CI (master) (14 April 2024)
On Montag, 15. April 2024 00:00: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. > > Good news: 1 repository has been fixed > > Bad news: 2 repositories are still failing > > kcontacts - 2nd week > * https://invent.kde.org/frameworks/kcontacts/-/pipelines/662687 > * AddressTest::formatTest fails in FreeBSD https://invent.kde.org/frameworks/kcontacts/-/merge_requests/69 signature.asc Description: This is a digitally signed message part.
Moving KUnifiedPush to KDE Gear
Hi, I'd like to propose the KUnifiedPush library (https://invent.kde.org/libraries/ kunifiedpush) for inclusion in KDE Gear. This was stalled for some time but we finally have a default server installation thanks to Carl, so this is now actually useful for people not running their own infrastructure as well. There's two users of this already, Neochat and Tokodon, both have it as an optional dependency at the moment. Thanks, Volker signature.asc Description: This is a digitally signed message part.
[KDE Itinerary] [Bug 485389] kmail, sncf mail, itinerary header does not appears
https://bugs.kde.org/show_bug.cgi?id=485389 Volker Krause changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED Latest Commit||https://invent.kde.org/pim/ ||kitinerary/-/commit/2efbcc6 ||414885a9f7c180001fe73ee5ed8 ||36ee80 --- Comment #1 from Volker Krause --- Git commit 2efbcc6414885a9f7c180001fe73ee5ed836ee80 by Volker Krause. Committed on 13/04/2024 at 08:56. Pushed by vkrause into branch 'master'. Fix check for prices in SNCF extractor script This broke when no price information was found and didn't produce any result at all anymore. M +2-2src/lib/scripts/sncf.js https://invent.kde.org/pim/kitinerary/-/commit/2efbcc6414885a9f7c180001fe73ee5ed836ee80 -- You are receiving this mail because: You are watching all bug changes.
[KOpeningHours] [Bug 452236] normalizeExpression output on monthday_range is simplified
https://bugs.kde.org/show_bug.cgi?id=452236 Volker Krause changed: What|Removed |Added Latest Commit|https://invent.kde.org/libr |https://invent.kde.org/libr |aries/kopeninghours/-/commi |aries/kopeninghours/-/commi |t/497444553d267b830494f0381 |t/bc12a820326f564e00c653300 |b7f820a46a3b2bc |8e027b321fa6644 --- Comment #6 from Volker Krause --- Git commit bc12a820326f564e00c6533008e027b321fa6644 by Volker Krause, on behalf of Fam Lam. Committed on 13/04/2024 at 08:46. Pushed by vkrause into branch 'release/24.02'. Keep year if months differ with day (undefined behaviour) (cherry picked from commit 497444553d267b830494f0381b7f820a46a3b2bc) M +4-0autotests/parsertest.cpp M +1-1src/lib/selectors.cpp https://invent.kde.org/libraries/kopeninghours/-/commit/bc12a820326f564e00c6533008e027b321fa6644 -- You are receiving this mail because: You are watching all bug changes.
Re: KDE Frameworks with failing CI (master) (7 April 2024)
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. > 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. Regards, Volker signature.asc Description: This is a digitally signed message part.
[KDE Itinerary] [Bug 485004] Several issues with VR (Finish operator) imported train tickets
https://bugs.kde.org/show_bug.cgi?id=485004 --- Comment #11 from Volker Krause --- Git commit 22a9a3e7e238fd73dbf9ae604f6565b18413aae5 by Volker Krause. Committed on 06/04/2024 at 08:24. Pushed by vkrause into branch 'release/24.02'. Add extractor script for VR mobile PDF tickets (cherry picked from commit c24a119bb2ad1367d2b3cfd66b1cb22d9015a0f2) M +17 -1src/lib/scripts/vr.fi.js https://invent.kde.org/pim/kitinerary/-/commit/22a9a3e7e238fd73dbf9ae604f6565b18413aae5 -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 485004] Several issues with VR (Finish operator) imported train tickets
https://bugs.kde.org/show_bug.cgi?id=485004 --- Comment #10 from Volker Krause --- Git commit 1f9a20976859f6528f8729c947448f3645cc3376 by Volker Krause. Committed on 05/04/2024 at 15:55. Pushed by vkrause into branch 'master'. Regenerate the train station database Among generally new data this now includes Finish train statations with VR station codes containing umlauts. M +3-0autotests/knowledgedbtest.cpp M +---src/lib/knowledgedb/trainstationdb_data.cpp https://invent.kde.org/pim/kitinerary/-/commit/1f9a20976859f6528f8729c947448f3645cc3376 -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 485004] Several issues with VR (Finish operator) imported train tickets
https://bugs.kde.org/show_bug.cgi?id=485004 --- Comment #8 from Volker Krause --- Git commit c24a119bb2ad1367d2b3cfd66b1cb22d9015a0f2 by Volker Krause. Committed on 05/04/2024 at 15:51. Pushed by vkrause into branch 'master'. Add extractor script for VR mobile PDF tickets M +17 -1src/lib/scripts/vr.fi.js https://invent.kde.org/pim/kitinerary/-/commit/c24a119bb2ad1367d2b3cfd66b1cb22d9015a0f2 -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 485004] Several issues with VR (Finish operator) imported train tickets
https://bugs.kde.org/show_bug.cgi?id=485004 --- Comment #9 from Volker Krause --- Git commit d1c8044fa6649eeaefcfc542b7a50246ea21e02f by Volker Krause. Committed on 05/04/2024 at 15:54. Pushed by vkrause into branch 'master'. Support VR station code umlauts That's outside of the ERA SSB spec, and needs some hacks to work with our compile-time generated train station index. M +24 -0autotests/knowledgedbtest.cpp M +4-2src/knowledgedb-generator/trainstationdbgenerator.cpp M +17 -5src/lib/knowledgedb/stationidentifier.cpp M +10 -6src/lib/knowledgedb/stationidentifier.h https://invent.kde.org/pim/kitinerary/-/commit/d1c8044fa6649eeaefcfc542b7a50246ea21e02f -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 485004] Several issues with VR (Finish operator) imported train tickets
https://bugs.kde.org/show_bug.cgi?id=485004 --- Comment #6 from Volker Krause --- Git commit 47a04a30d8c0e27566f891dd73efe78d5ecebaa9 by Volker Krause. Committed on 04/04/2024 at 16:03. Pushed by vkrause into branch 'release/24.02'. Consider berth number in VR ERA SSB ticket barcodes Also, validate the classOfTransport value to deal with class-less tickets. (cherry picked from commit 2075fe69babf17ffd257e3f66a5f5184ba64b951) M +3-2src/lib/scripts/vr.fi.js https://invent.kde.org/pim/kitinerary/-/commit/47a04a30d8c0e27566f891dd73efe78d5ecebaa9 -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 485004] Several issues with VR (Finish operator) imported train tickets
https://bugs.kde.org/show_bug.cgi?id=485004 --- Comment #5 from Volker Krause --- Git commit fe8edfa3feaa77fdecc42a07e73f19004b95c065 by Volker Krause. Committed on 04/04/2024 at 16:03. Pushed by vkrause into branch 'release/24.02'. Fix ERA SSB date conversion There's two issues here: - for SSBv1 we missed the end-of-year wrap around logic. - for SSBv2 the end-of-year wrap around was computed correctly but the result ended up being discarded. (cherry picked from commit 60181caf311d11fe0afbbf150e1f359a861728ae) M +16 -0src/lib/era/ssbticketbase.cpp M +8-2src/lib/era/ssbticketbase.h M +2-3src/lib/era/ssbv1ticket.cpp M +4-18 src/lib/era/ssbv2ticket.cpp https://invent.kde.org/pim/kitinerary/-/commit/fe8edfa3feaa77fdecc42a07e73f19004b95c065 -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 485004] Several issues with VR (Finish operator) imported train tickets
https://bugs.kde.org/show_bug.cgi?id=485004 --- Comment #4 from Volker Krause --- Git commit 60181caf311d11fe0afbbf150e1f359a861728ae by Volker Krause. Committed on 04/04/2024 at 15:52. Pushed by vkrause into branch 'master'. Fix ERA SSB date conversion There's two issues here: - for SSBv1 we missed the end-of-year wrap around logic. - for SSBv2 the end-of-year wrap around was computed correctly but the result ended up being discarded. M +16 -0src/lib/era/ssbticketbase.cpp M +8-2src/lib/era/ssbticketbase.h M +2-3src/lib/era/ssbv1ticket.cpp M +4-18 src/lib/era/ssbv2ticket.cpp https://invent.kde.org/pim/kitinerary/-/commit/60181caf311d11fe0afbbf150e1f359a861728ae -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 485004] Several issues with VR (Finish operator) imported train tickets
https://bugs.kde.org/show_bug.cgi?id=485004 --- Comment #2 from Volker Krause --- Git commit 2075fe69babf17ffd257e3f66a5f5184ba64b951 by Volker Krause. Committed on 04/04/2024 at 15:52. Pushed by vkrause into branch 'master'. Consider berth number in VR ERA SSB ticket barcodes Also, validate the classOfTransport value to deal with class-less tickets. M +3-2src/lib/scripts/vr.fi.js https://invent.kde.org/pim/kitinerary/-/commit/2075fe69babf17ffd257e3f66a5f5184ba64b951 -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 485004] Several issues with VR (Finish operator) imported train tickets
https://bugs.kde.org/show_bug.cgi?id=485004 --- Comment #3 from Volker Krause --- Git commit e909a3c153930b5c76a17242b937e1abb9009f5a by Volker Krause. Committed on 04/04/2024 at 15:53. Pushed by vkrause into branch 'master'. Decode Finish ERA SSB alphanumeric station codes correctly A few of those use an 'Ä' as part of the code, which isn't really part of the ERA specification as far as I can tell. In itself this doesn't help yet, we still need the train station database side of this. M +5-2src/lib/era/ssbticketbase.cpp https://invent.kde.org/pim/kitinerary/-/commit/e909a3c153930b5c76a17242b937e1abb9009f5a -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 484928] Importing of DB BC100 Deutschland-Ticket no longer works for April 2024
https://bugs.kde.org/show_bug.cgi?id=484928 --- Comment #12 from Volker Krause --- The above mentioned fix is not yet integrated, so I would not expect any change yet. -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 485004] Several issues with VR (Finish operator) imported train tickets
https://bugs.kde.org/show_bug.cgi?id=485004 --- Comment #1 from Volker Krause --- VR seems to have changed their PDF layout, so what you are seeing there is the fallback to just the barcode content (which e.g. doesn't have the full station names or exact times), that explains most of 2, 3, 4, 8 and 9. With the samples you provided this should be fixable though. For 5: when and more importantly in which country (from a network point of view) did you test 5? The Finish public transport API we use has had various counter-measures for a DDoS attack in place, including geo-blocking IPs. -- You are receiving this mail because: You are watching all bug changes.
Re: KDE Gear projects with failing CI (master) (2 April 2024)
On Mittwoch, 3. April 2024 00:39:36 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. > > Good news: 1 repositories got fixed > > kirigami-gallery - 2nd week > * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/650557 > * Android build fails >* Similar problem to the one in kirigami being discussed in the > frameworks mailing list my questions about whether we can merge the kf6 branch for this have gone unanswered so far unfortunately, which would at least hide that issue > calindori - NEW > * https://invent.kde.org/plasma-mobile/calindori/-/pipelines/650676 > * https://invent.kde.org/plasma-mobile/calindori/-/pipelines/650559 > * Craft builds fail >* It still had a Qt5 craft build when the code is now Qt6 based > I blindly pushed a change to make the craft builds Qt6 based > That was probably not a very smart move, the builds still fail https://invent.kde.org/plasma-mobile/calindori/-/merge_requests/82 > kitinerary - NEW > * https://invent.kde.org/pim/kitinerary/-/pipelines/650569 > * extractortest fails in FreeBSD frameworks/kcontacts shows the same issue, my guess would be it's related to changes to iso-codes or its translation catalogs in the FreeBSD image, the failures all appeared after a recent image update without corresponding code changes. Regards, Volker signature.asc Description: This is a digitally signed message part.
[KDE Itinerary] [Bug 484928] Importing of DB BC100 Deutschland-Ticket no longer works for April 2024
https://bugs.kde.org/show_bug.cgi?id=484928 --- Comment #5 from Volker Krause --- Any barcode scanning is broken since the Qt 6.6.2 update, https://invent.kde.org/packaging/craft-blueprints-kde/-/merge_requests/815 should fix it. -- You are receiving this mail because: You are watching all bug changes.
Re: KDE Gear projects with failing CI (master) (27 March 2024)
On Mittwoch, 27. März 2024 23:33:52 CET Albert Astals Cid wrote: > kirigami-gallery - NEW > * https://invent.kde.org/sdk/kirigami-gallery/-/pipelines/645400 > * Android build fails >* Similar problem to the one in kirigami being discussed in the > frameworks mailing list Asked in the Kirigami channel about remaining blockers for merging the existing and seemingly working kf6 branch. That would be more hiding than solving the problem here, but it's necessary longer term anyway. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks with failing CI (kf5) (24 March 2024)
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. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: AppStream Metadata with our releases
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? Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Licensing for models and datasets
On Montag, 25. März 2024 15:17:48 CET Halla Rempt wrote: > We're looking into adding an experimental AI-based feature to Krita: > automated inking. That gives us three components, and we're not sure about > the license we should use for two of them: the model and the datase. Would > CC be best here? Looking at https://community.kde.org/Policies/Licensing_Policy the closest thing would either be "media" files (generalized to "data files") and thus CC- BY-SA (and presumably CC-BY/CC0) or "source code" (xGPL, BSD/MIT). I think this is a bit more tricky though, depending on whether we assume a model is derivative work of the input data, and whether the output generated from a model is derivative work of the model (and thus potentially derivative work of the input data). The industry assumption so far seems to be that at least one of those isn't derivative work (AFAIK that has yet to be legally tested though), but I'm not sure that interpretation is in the best interest of FOSS developers or artists... One scenario that would work regardless I think is using a license with practically no constraints (CC0, MIT, etc), but that also offers no protection for the training or model data (which might or might not be what you want). Any other scenario I can think of involving more protective licenses runs into interesting issues: - if the output is derivative work, Krita users would be bound by e.g. the attribution or share-alike requirements of the license (which I guess is not what you want). - a Bison/Flex style "code generator exception" to state that the model output is free of any license requirements regardless of the model license itself requires that either the model isn't derivative work of the input or that the input data is licensed in a way compatible with that. - In the latter case we are back to essentially unprotected CC0-like input, or a protective license with a special exception, which then gets awfully close to developing new licenses. So I guess this boils down to how much protection you have in mind for the input and model data? Interesting topic, sorry if my ramblings on this are of limited help :) Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: AppStream Metadata with our releases
On Freitag, 22. März 2024 00:37:00 CET Julius Künzel wrote: > AppStream metadata are consumed by app stores like Flathub, Snapcraft, > Discover, our scripts to submit apps to the Microsoft Store and last but > not least by apps.kde.org [2]. Same for generating the package metadata on Android, both for our F-Droid repositories and the Google Play store. > - Also it would be convenient to add noteworthy changes to the metadata > together with the related code change. However at the moment for KDE Gear > the release is usually only added to the metadata a few days before > tagging. Would it be possible to add the next minor release to the release > branch right after the current one has been released and the next major > release to master ones the upcoming version has been branched? At least in the past the appstream validator complained about releases dated (too far) into the future, but that doesn't seem to be a problem anymore fortunately. As Itinerary was mentioned, the process there currently is to run David's KF changelog script over all repositories in Itinerary's dependency chain and take the top 5 or so most visible/important changes (which here are actually often from other repositories). The commit adding the release to appstream is my reminder for that currently, but there's other ways to do that, so for Itinerary the proposed change wouldn't make much of a difference either way. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks with failing CI (kf5) (24 March 2024)
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. 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? Regards, Volker signature.asc Description: This is a digitally signed message part.
[KDE Itinerary] [Bug 483974] unable to import OBB nightjet tickets
https://bugs.kde.org/show_bug.cgi?id=483974 Volker Krause changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED Version Fixed In||24.02.1 --- Comment #3 from Volker Krause --- Thank you! Fixed in 24.02.1 :) -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 483974] unable to import OBB nightjet tickets
https://bugs.kde.org/show_bug.cgi?id=483974 --- Comment #1 from Volker Krause --- This would need access to an affected ticket unfortunately, otherwise there isn't much we can do I'm afraid. If you have one that you can share non-publicly (email to vkra...@kde.org) that would help a lot! -- You are receiving this mail because: You are watching all bug changes.
Re: KDE Gear projects with failing CI (master) (12 March 2024)
On Mittwoch, 13. März 2024 10:19:32 CET Ben Cooksley wrote: > On Wed, Mar 13, 2024 at 12:12 PM Albert Astals Cid wrote: > > mimetreeparser - NEW > > > > * https://invent.kde.org/pim/mimetreeparser/-/pipelines/628865 > > > > * core-cryptohelpertest fails > > Don't understand how that could fail out of the blue... I don't think it did, it rather looks like it never worked. https:// invent.kde.org/pim/mimetreeparser/-/commit/ 12952b4f2ddb2d9743dfc7784caa349bf1a870ed introduced the broken test very recently. Regards, Volker signature.asc Description: This is a digitally signed message part.
[KOpeningHours] [Bug 483400] Specify which version of extra-cmake-modules provides the required ECMQmlModule
https://bugs.kde.org/show_bug.cgi?id=483400 Volker Krause changed: What|Removed |Added Latest Commit|https://invent.kde.org/libr |https://invent.kde.org/libr |aries/kopeninghours/-/commi |aries/kopeninghours/-/commi |t/75decfd53b779b7a1800abff4 |t/3f3a934fb179601325f0923d4 |2fad9d4d7e33538 |e54c28422687052 --- Comment #2 from Volker Krause --- Git commit 3f3a934fb179601325f0923d4e54c28422687052 by Volker Krause. Committed on 13/03/2024 at 16:35. Pushed by vkrause into branch 'release/24.02'. Include ECMQmlModule only when needed In particular don't include it when building the validator-only Python module, which has to build with much older ECM versions still. Fallout from 13550d7c38035d993833344cce83b5f142e203dc. (cherry picked from commit 75decfd53b779b7a1800abff42fad9d4d7e33538) M +0-1CMakeLists.txt M +1-0src/qml/CMakeLists.txt https://invent.kde.org/libraries/kopeninghours/-/commit/3f3a934fb179601325f0923d4e54c28422687052 -- You are receiving this mail because: You are watching all bug changes.
[KOpeningHours] [Bug 483400] Specify which version of extra-cmake-modules provides the required ECMQmlModule
https://bugs.kde.org/show_bug.cgi?id=483400 Volker Krause changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED Latest Commit||https://invent.kde.org/libr ||aries/kopeninghours/-/commi ||t/75decfd53b779b7a1800abff4 ||2fad9d4d7e33538 --- Comment #1 from Volker Krause --- Git commit 75decfd53b779b7a1800abff42fad9d4d7e33538 by Volker Krause. Committed on 13/03/2024 at 16:35. Pushed by vkrause into branch 'master'. Include ECMQmlModule only when needed In particular don't include it when building the validator-only Python module, which has to build with much older ECM versions still. Fallout from 13550d7c38035d993833344cce83b5f142e203dc. M +0-1CMakeLists.txt M +1-0src/qml/CMakeLists.txt https://invent.kde.org/libraries/kopeninghours/-/commit/75decfd53b779b7a1800abff42fad9d4d7e33538 -- You are receiving this mail because: You are watching all bug changes.
[KPublicTransport] [Bug 482357] hafasmgaterequesttest and efarequesttest fail based on unknown l10n/i18n factors
https://bugs.kde.org/show_bug.cgi?id=482357 Volker Krause changed: What|Removed |Added Latest Commit|https://invent.kde.org/libr |https://invent.kde.org/libr |aries/kpublictransport/-/co |aries/kpublictransport/-/co |mmit/bdfb93dad323b611f8bbe0 |mmit/3fb5f8d6a32fe0a7cc7c70 |9f6e9ef76dd026e3fd |a63af70d760853d500 --- Comment #2 from Volker Krause --- Git commit 3fb5f8d6a32fe0a7cc7c70a63af70d760853d500 by Volker Krause. Committed on 05/03/2024 at 16:39. Pushed by vkrause into branch 'release/24.02'. Fix locale overriding in request unit tests (cherry picked from commit bdfb93dad323b611f8bbe09f6e9ef76dd026e3fd) M +1-1autotests/efarequesttest.cpp M +1-1autotests/hafasmgaterequesttest.cpp https://invent.kde.org/libraries/kpublictransport/-/commit/3fb5f8d6a32fe0a7cc7c70a63af70d760853d500 -- You are receiving this mail because: You are watching all bug changes.
[KPublicTransport] [Bug 482357] hafasmgaterequesttest and efarequesttest fail based on unknown l10n/i18n factors
https://bugs.kde.org/show_bug.cgi?id=482357 Volker Krause changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED Latest Commit||https://invent.kde.org/libr ||aries/kpublictransport/-/co ||mmit/bdfb93dad323b611f8bbe0 ||9f6e9ef76dd026e3fd --- Comment #1 from Volker Krause --- Git commit bdfb93dad323b611f8bbe09f6e9ef76dd026e3fd by Volker Krause. Committed on 04/03/2024 at 17:44. Pushed by vkrause into branch 'master'. Fix locale overriding in request unit tests M +1-1autotests/efarequesttest.cpp M +1-1autotests/hafasmgaterequesttest.cpp https://invent.kde.org/libraries/kpublictransport/-/commit/bdfb93dad323b611f8bbe09f6e9ef76dd026e3fd -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 481739] Add support for Ferry boarding pass from eckeroline.com
https://bugs.kde.org/show_bug.cgi?id=481739 Volker Krause changed: What|Removed |Added Latest Commit|https://invent.kde.org/pim/ |https://invent.kde.org/pim/ |kitinerary/-/commit/1b44fd2 |kitinerary/-/commit/d2bda00 |c810f4735db0bc7d4b646ae5d11 |78d691b326db1d5dfe7bad75003 |34fbda |4b3053 --- Comment #4 from Volker Krause --- Git commit d2bda0078d691b326db1d5dfe7bad750034b3053 by Volker Krause. Committed on 02/03/2024 at 13:19. Pushed by vkrause into branch 'release/24.02'. Add extractor script for Eckerö Line ferry tickets (cherry picked from commit 1b44fd2c810f4735db0bc7d4b646ae5d1134fbda) A +20 -0src/lib/scripts/eckeroline.js A +12 -0src/lib/scripts/eckeroline.json M +2-0src/lib/scripts/extractors.qrc https://invent.kde.org/pim/kitinerary/-/commit/d2bda0078d691b326db1d5dfe7bad750034b3053 -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 481739] Add support for Ferry boarding pass from eckeroline.com
https://bugs.kde.org/show_bug.cgi?id=481739 Volker Krause changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED Latest Commit||https://invent.kde.org/pim/ ||kitinerary/-/commit/1b44fd2 ||c810f4735db0bc7d4b646ae5d11 ||34fbda --- Comment #3 from Volker Krause --- Git commit 1b44fd2c810f4735db0bc7d4b646ae5d1134fbda by Volker Krause. Committed on 27/02/2024 at 16:25. Pushed by vkrause into branch 'master'. Add extractor script for Eckerö Line ferry tickets A +20 -0src/lib/scripts/eckeroline.js A +12 -0src/lib/scripts/eckeroline.json M +2-0src/lib/scripts/extractors.qrc https://invent.kde.org/pim/kitinerary/-/commit/1b44fd2c810f4735db0bc7d4b646ae5d1134fbda -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 481739] Add support for Ferry boarding pass from eckeroline.com
https://bugs.kde.org/show_bug.cgi?id=481739 --- Comment #1 from Volker Krause --- To check what's possible here I'd indeed need access to the PDF (email to vkra...@kde.org). Thank you! -- You are receiving this mail because: You are watching all bug changes.
Reminder: KF6 Meeting
Hello everyone, please remember the final KF6 meeting tomorrow, Tuesday 17:00 CET: https://meet.kde.org/b/ada-mi8-aem Topics and notes are collected here: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/77 Thank you, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks with failing CI (master) (25 February 2024)
On Sonntag, 25. Februar 2024 23:18:40 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. > > Good news: 1 repository has been fixed > > Bad news: 3 NEW repository are failing > > 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?) That's the flatpak for the admin and analytics tool. The problem is the same we have pretty much everywhere with the Flatpak jobs at the moment, they contain components requiring KF 6.0, but we don't have a final KF6.0 runtime yet. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Post-MegaRelease projects
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 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. Right, the Android emulator is probably the first thing to look at for this. That alone isn't enough though, we can't just copy over a unit test executable and run it there,
Re: Post-MegaRelease projects
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 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. Right, the Android emulator is probably the first thing to look at for this. That alone isn't enough though, we can't just copy over a unit test executable and run it there,
[KDE Itinerary] [Bug 481623] About page does not show up on Android in landscape mode
https://bugs.kde.org/show_bug.cgi?id=481623 Volker Krause changed: What|Removed |Added Resolution|--- |FIXED Latest Commit||https://invent.kde.org/fram ||eworks/kirigami/-/commit/0d ||3cf45559f295063399895a9f2c1 ||c11d2beb610 Status|ASSIGNED|RESOLVED --- Comment #2 from Volker Krause --- Git commit 0d3cf45559f295063399895a9f2c1c11d2beb610 by Volker Krause. Committed on 22/02/2024 at 16:52. Pushed by vkrause into branch 'master'. Handle URL inputs for pushDialogLayer verifyPages() explicitly allows those, but the case wasn't handled here so we end up with dialog being undefined subsequently. M +5-0src/controls/PageRow.qml https://invent.kde.org/frameworks/kirigami/-/commit/0d3cf45559f295063399895a9f2c1c11d2beb610 -- You are receiving this mail because: You are watching all bug changes.
Re: KDE Gear projects with failing CI (master) (20 February 2024)
On Mittwoch, 21. Februar 2024 13:59:19 CET Ingo Klöcker wrote: > On Mittwoch, 21. Februar 2024 11:43:39 CET Ben Cooksley wrote: > > On Wed, Feb 21, 2024 at 12:01 PM Albert Astals Cid wrote: > > > 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. > > Fixed. Additional fix, just to be sure :) https://invent.kde.org/utilities/keysmith/-/merge_requests/130 Regards, Volker signature.asc Description: This is a digitally signed message part.
Reminder: KF6 Meeting
Hello everyone, please remember the KF6 meeting tomorrow, Tuesday 17:00 CET: https://meet.kde.org/b/ada-mi8-aem Topics and notes are collected here: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/76 Thank you, Volker signature.asc Description: This is a digitally signed message part.
[KDE Itinerary] [Bug 481407] 23.08.4 Tuxedo os 2 Wayland cannot start
https://bugs.kde.org/show_bug.cgi?id=481407 --- Comment #1 from Volker Krause --- Is the/Are the kirigami-addons package(s) installed? Not sure how exactly that's called and/or how it's split on this distribution, but this error indicates that those might be missing. -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 481281] Scanning of boarding pass from Air Europa does not show the boarding time nor the departure time.
https://bugs.kde.org/show_bug.cgi?id=481281 Volker Krause changed: What|Removed |Added Latest Commit|https://invent.kde.org/pim/ |https://invent.kde.org/pim/ |kitinerary/-/commit/e7959d6 |kitinerary/-/commit/b3f8b6d |4e27a98ca2d6ed22dcdabe730ae |bbc10d9b439b33dfe5e474c3f76 |e4995d |2676cc --- Comment #4 from Volker Krause --- Git commit b3f8b6dbbc10d9b439b33dfe5e474c3f762676cc by Volker Krause. Committed on 14/02/2024 at 18:33. Pushed by vkrause into branch 'release/24.02'. Handle time quadruples in the generic boarding pass extractor This now also covers the cases check-in or baggage drop close and/or gate close times. Not all variations with this wrapping around at midnight are implemented though lacking corresponding samples. While at it, also use chrono types more consistently in the associated code. (cherry picked from commit e7959d64e27a98ca2d6ed22dcdabe730aee4995d) M +49 -18 src/lib/extractors/genericboardingpassextractor.cpp M +4-4src/lib/flightpostprocessor.cpp M +2-1src/lib/flightpostprocessor_p.h M +4-4src/lib/flightutil.cpp M +3-1src/lib/flightutil_p.h https://invent.kde.org/pim/kitinerary/-/commit/b3f8b6dbbc10d9b439b33dfe5e474c3f762676cc -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 481281] Scanning of boarding pass from Air Europa does not show the boarding time nor the departure time.
https://bugs.kde.org/show_bug.cgi?id=481281 Volker Krause changed: What|Removed |Added Latest Commit||https://invent.kde.org/pim/ ||kitinerary/-/commit/e7959d6 ||4e27a98ca2d6ed22dcdabe730ae ||e4995d Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #3 from Volker Krause --- Git commit e7959d64e27a98ca2d6ed22dcdabe730aee4995d by Volker Krause. Committed on 14/02/2024 at 18:20. Pushed by vkrause into branch 'master'. Handle time quadruples in the generic boarding pass extractor This now also covers the cases check-in or baggage drop close and/or gate close times. Not all variations with this wrapping around at midnight are implemented though lacking corresponding samples. While at it, also use chrono types more consistently in the associated code. M +49 -18 src/lib/extractors/genericboardingpassextractor.cpp M +4-4src/lib/flightpostprocessor.cpp M +2-1src/lib/flightpostprocessor_p.h M +4-4src/lib/flightutil.cpp M +3-1src/lib/flightutil_p.h https://invent.kde.org/pim/kitinerary/-/commit/e7959d64e27a98ca2d6ed22dcdabe730aee4995d -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 481281] Scanning of boarding pass from Air Europa does not show the boarding time nor the departure time.
https://bugs.kde.org/show_bug.cgi?id=481281 --- Comment #1 from Volker Krause --- If you tried to import the PDF I'd indeed need the file in order to see what we can do about it (email to vkra...@kde.org). If you tried scanning the barcode then this is unfortunately the expected result, boarding pass barcodes don't contain travel times. -- You are receiving this mail because: You are watching all bug changes.
Reminder: KF6 Meeting
Hello everyone, please remember the KF6 meeting tomorrow, Tuesday 17:00 CET: https://meet.kde.org/b/ada-mi8-aem Topics and notes are collected here: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/75 Thank you, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks with failing CI (master) (4 February 2024)
On Sonntag, 11. Februar 2024 01:06:53 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. > > Good news: 4 repositories have been fixed > > Bad news: 1 repository is still failing > > > kdav - 2nd week > * https://invent.kde.org/frameworks/kdav/-/pipelines/604710 > * davcollectionsmultifetchjobtest fails both in Linux and FreeBSD >* Volker identified a MR that broke it, but needs acting on. Do I > remember that Nico is on holiday? May need someone else to have a look at. Harald did, it's fixed now :) signature.asc Description: This is a digitally signed message part.
Re: Flatpak jobs on KDE CI vs. continuous integration on main/master/devel branches
On Mittwoch, 7. Februar 2024 19:48:27 CET Friedrich W. H. Kossebau wrote: > Am Sonntag, 4. Februar 2024, 19:22:28 CET schrieb Ben Cooksley: > > On Mon, Feb 5, 2024 at 4:28 AM Friedrich W. H. Kossebau > > > > wrote: > > > Hi, > > > > > > ((cc:kde-frameworks-devel for heads-up, replies please only to > > > kde-core-deve)) > > > > > > I hit the problem that when working on a repo which would like to use > > > latest > > > KF development state to integrate some new KF API just added in > > > cooperation > > > with that very repo wanting to use it, I cannot do so when someone had > > > added a > > > flatpak job on CI to that repo. > > > > > > Because with such flatpak jobs it seems they are limiting the available > > > KF > > > version not to the current latest one, as expected for continuous > > > integration, > > > > > > but some older (anywhere documented?) snapshot: > > > "runtime-version": "6.6-kf6preview", > > > > Please see https://invent.kde.org/packaging/flatpak-kde-runtime/-/tree/kf6 > > for what is in the KF6 preview. > > Thanks. So documented by implementation :) > > > > What can be done here to reestablish the old immediate continuous > > > integration > > > workflow? Where new APIs (also from KF) are instantly available? > > > > With Flatpak new APIs were never instantly available - there has always > > been a delay as the Flatpak Runtime uses the most recent released version > > of our software. > > I guess this was shadowed by feature development of KF having stalled during > the Qt5/KF5->Qt6/KG6 porting phase as well as Qt6-based flatpaks jobs only > activated recently. > > > > Right now this is a new extra burden which makes working on new features > > > with > > > KF and apps more complicated. Thus less interesting, and one/I would > > > rather > > > duplicate code in apps to get things done. > > > > > > Blocking latest KF API from usage also means less testing of that before > > > the > > > initial release. > > > > > > > > > Besides all the resource costs to create flatpaks on master builds by > > > default > > > every time, when those are usually not used by anyone anyway. > > > > Those applications that have a hard dependency on features being added to > > Frameworks are not good candidates for making use of our Continuous > > Delivery systems i'm afraid. > > Both Flatpak and Craft based (Linux Appimages, Android APKs, Windows and > > macOS) CD jobs are best optimised for those applications that rely on the > > stable Frameworks releases. > > > > There are ways (in .craft.ini) to make newer Frameworks available, but > > that > > requires that the system recompiles that Framework each time you trigger a > > build and is therefore not recommended. > > > > Allowing those systems to use the "latest" artifacts of Frameworks would > > be > > a non-trivial exercise. > > So effectively this means: > * KF - no CI on new API with non-KF repos, only KF-internal CI > * KF - no CD, only released versions > > Which makes KF a second class product, with lesser testing :( > And less interesting to contribute to, given it gets worse CI/CD care. CI builds can (as they always could on Gitlab and currently mostly do) use latest KF master. CD builds can't (and never could, binary factory had the same limitation). Nothing is getting worse here, the only thing you cannot have is unconditionally using latest KF and expect CD builds for that based on cached runtime/platform parts. The most common way of working for apps seems to be supporting at least the last released version of KF, if needed with version ifdefs to already integrate newer code. In most cases that is very limited effort, and as soon as more than one contributor is involved that is usually highly desired anyway to not randomly force full rebuilds on others. There are cases where this is not feasible, e.g. in case of very tight coupling or QML code that cannot easily be ifdef'ed. In that case you either wait for the next release, or you can only have CD builds in the release branch I'd say. Using expensive "full-stack" CD builds for that would need a very good justification given the cost IMHO. I can't speak for KDE Games obviously, but for the stuff I am involved in I most definitely wouldn't want to miss CD builds anymore. There's a bunch of people daily-driving Itinerary from those for example, and that is such a big help for QA. Bug reports are practically always still relevant, the turnaround time for feedback is days or even hours rather than weeks or months, and a whole bunch of issues gets caught before even hitting the releases. On top of that the Flatpak build provides an extra safety net there for finding incompatibilities with two major external dependencies (poppler and zxing), by using the latest versions of those. One thing I do agree on though is that there is no point in running jobs (CI nor CD) that really /nobody/ cares about anymore, and the occasional cleanup there is probably
Re: KDE Gear projects with failing CI (release/24.02) (6 February 2024)
On Dienstag, 6. Februar 2024 22:24:22 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. > > Good News: 7 failing repositories from previous report got fixed > > Bad news: 3 repositories are still failing and 11 new repositories started > failing > > > gwenview - 3rd week > * https://invent.kde.org/graphics/gwenview/-/pipelines/601196 > * cfitsio SHA doesn't match on flatpak build That has been fixed by backporting the corresponding fix from master. Regards, Volker signature.asc Description: This is a digitally signed message part.
Reminder: KF6 Meeting
Hello everyone, please remember the KF6 meeting tomorrow, Tuesday 17:00 CET: https://meet.kde.org/b/ada-mi8-aem Topics and notes are collected here: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/75 Thank you, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks with failing CI (master) (4 February 2024)
On Sonntag, 4. Februar 2024 13:26:54 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. > > Good news: 3 repository has been fixed > > Bad news: 2 repositories are still failing, 3 new ones have started failing > > > kdav - NEW > * https://invent.kde.org/frameworks/kdav/-/pipelines/598256 > * davcollectionsmultifetchjobtest fails both in Linux and FreeBSD Bisecting points to the following KIO MR as the cause: https://invent.kde.org/frameworks/kio/-/merge_requests/1543 Regards, Volker signature.asc Description: This is a digitally signed message part.
[KDE Itinerary] [Bug 480744] No option to plan flights
https://bugs.kde.org/show_bug.cgi?id=480744 --- Comment #1 from Volker Krause --- Yes, the only option to get flights in at the moment is via import boarding passes (works most of the time) or flight booking documents/emails (works for some airlines), a manual editor like we have for other modes of transport is still missing. We definitely want that, although I'd not expect an actual flight search as to my knowledge there's no API/data available for free to implement that. -- You are receiving this mail because: You are watching all bug changes.
Re: KDE Gear projects with failing CI (release/23.08) (23 January 2024)
On Donnerstag, 1. Februar 2024 10:52:46 CET Ben Cooksley wrote: > On Thu, Feb 1, 2024 at 6:40 AM Volker Krause wrote: > > On Mittwoch, 31. Januar 2024 00:12:20 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. > > > > > > Good news: 10 repositories that were failing are fixed :) > > > > > > Bad news: 6 repositories are still failing and 2 new repositories are > > > failing > > > > > > > > > akonadi-search - 2nd week > > > > > > * https://invent.kde.org/pim/akonadi-search/-/pipelines/594413 > > > > > > * various tests are failing in FreeBSD > > > > Same as with 24.02, half-fixed by backporting https://invent.kde.org/pim/ > > akonadi/-/merge_requests/171 > > <https://invent.kde.org/pim/akonadi/-/merge_requests/171>, the remaining > > issues are due to the missing > > MySQL support in QtSQL. > > I've investigated this and there are a combination of two issues here, > however when it comes to the MySQL driver: it appears that there is a > packaging conflict preventing it from being installed. > @tcberner - apparently it wants mysql80-client explicitly and wants to > throw out mariadb106-client and mariadb106-server? > > Even if we fix this, it looks like MySQL has the same dependency on System > V IPC that Postgres has, which is not supported within FreeBSD Jails... Ok, in that case https://invent.kde.org/pim/akonadi/-/merge_requests/177 is the only option then I guess. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/23.08) (23 January 2024)
On Mittwoch, 31. Januar 2024 00:12:20 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. > > Good news: 10 repositories that were failing are fixed :) > > Bad news: 6 repositories are still failing and 2 new repositories are > failing > > > akonadi-search - 2nd week > * https://invent.kde.org/pim/akonadi-search/-/pipelines/594413 > * various tests are failing in FreeBSD Same as with 24.02, half-fixed by backporting https://invent.kde.org/pim/ akonadi/-/merge_requests/171, the remaining issues are due to the missing MySQL support in QtSQL. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/24.02) (30 January 2024)
On Dienstag, 30. Januar 2024 22:36:35 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. > > Good News: 6 failing repositories from previous report got fixed > > Bad news: 5 repositories are still failing and 5new repositories started > failing > > > akonadi-search - 2nd week > * https://invent.kde.org/pim/akonadi-search/-/pipelines/594267 > * FreeBSD tests are failing Partially fixed by backporting https://invent.kde.org/pim/akonadi/-/ merge_requests/171, the remaining issues are the same as in master. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: What can we expect from our developers
On Dienstag, 30. Januar 2024 22:05:16 CET Ingo Klöcker wrote: > On Dienstag, 30. Januar 2024 21:47:51 CET Friedrich W. H. Kossebau wrote: > > I think I understand where you are coming from, that all the work on > > software done here makes the more sense the more users there are. IMHO > > though reaching more users of Free Software should be done in ways and for > > platforms which are not giving more power to monopolists or those which > > seem set to become some. Flatpak, Snap, Windows, macOS... they are all > > about binaries. There is no simple way, part of the concept, to get the > > sources, patch something to one's likes and then regenerate the very same > > package, just as custom one. Or is there? > > Yes, there is. They can simply use our infrastructure for this. We are doing > much more than just providing the sources. We provide the fully functional > CI/ CD machinery for building custom versions (minus digital signatures > which we reserve for our official release artifacts). That, and for Flatpak specifically this is very much part of the concept/ toolchain even. I find the support/integration in e.g. GNOME Builder for this particular impressive, I don't think many other packaging formats/toolchains are getting anywhere close in terms of "time to modified app running locally", with no need to deal with dependencies manually, and with no risk of impacting the rest of your system. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (30 January 2024)
On Dienstag, 30. Januar 2024 21:33:40 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. > > Good news: 5 repositories got fixed > > Bad news: 7 repo still failing and 5 new this week > > akonadi-search - 2nd week > * https://invent.kde.org/pim/akonadi-search/-/pipelines/594243 > * FreeBSD tests are failing The problem here is the still the missing MySQL support in QtSql. We can do the equivalent of https://invent.kde.org/pim/akonadi/-/merge_requests/171 for MySQL as well if that remains unavailable, but IIRC this was being looked into. (this affects more repositories, they just haven't enabled required passing tests) Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks with failing CI (master) (29 January 2024)
On Dienstag, 30. Januar 2024 19:08:50 CET Ben Cooksley wrote: > On Wed, Jan 31, 2024 at 5:10 AM Volker Krause wrote: > > On Dienstag, 30. Januar 2024 09:57:32 CET Ben Cooksley wrote: > > > On Tue, Jan 30, 2024 at 8:47 PM Sune Vuorela wrote: > > > > On 2024-01-29, Albert Astals Cid wrote: > > > > > Bad news: 6 repositories have started failing > > > > > > > > > > baloo: > > > > > kconfig: > > > > > kcontacts > > > > > kfilemetadata: > > > > > ki18n: > > > > > > > > > > threadweaver: > > > > > * FreeBSD tests are failing > > > > > > > > I haven't studied these, and don't know if they are frequent or > > > > occasional failures. I have seen, after the fbsd builder changes, that > > > > test execution times have gone up 20-50%. If it is big tests that is > > > > already close to the limit, then that might be the reason. > > > > > > > > Or for others with occasional timeout tests on freebsd. > > > > > > Having a quick look at this, it seems that quite a few of those failures > > > are i18n related. > > > Given we are seeing locale warnings I have a suspicion that is the cause > > > > of > > > > > many of those failures. > > > > For ki18n and kcontacts another possible cause could be the iso-codes > > translation catalogs missing. Are those by any chance packaged separately > > as > > on some Linux distributions? > > I've checked and we do have iso-codes installed within the FreeBSD > containers. > The files are located at /usr/local/share/iso-codes/ though - will our > logic find them there? Yes, the iso-codes data file are found, the tests would show very explicit error messages and fail in many more places otherwise. We however also need the corresponding translation catalogs, not just the data files. On Linux those are in /usr/share/locale/*/LC_MESSAGE/iso_3166*.mo (but often separately packaged and thus missing). Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks with failing CI (kf5) (29 January 2024)
On Montag, 29. Januar 2024 23:59:18 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: 11 repositories started failing > kemoticons: > * https://invent.kde.org/frameworks/kemoticons/-/pipelines/593601 > * Fails because of ecm_feature_summary All the ecm_feature_summary changes need to be reverted, David's mass editing script apparently ran amok there and changed deprecated frameworks in their kf5 branch. I started to do that now. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks with failing CI (master) (29 January 2024)
On Dienstag, 30. Januar 2024 09:57:32 CET Ben Cooksley wrote: > On Tue, Jan 30, 2024 at 8:47 PM Sune Vuorela wrote: > > On 2024-01-29, Albert Astals Cid wrote: > > > Bad news: 6 repositories have started failing > > > > > > baloo: > > > kconfig: > > > kcontacts > > > kfilemetadata: > > > ki18n: > > > > > > threadweaver: > > > * FreeBSD tests are failing > > > > I haven't studied these, and don't know if they are frequent or > > occasional failures. I have seen, after the fbsd builder changes, that > > test execution times have gone up 20-50%. If it is big tests that is > > already close to the limit, then that might be the reason. > > > > Or for others with occasional timeout tests on freebsd. > > Having a quick look at this, it seems that quite a few of those failures > are i18n related. > Given we are seeing locale warnings I have a suspicion that is the cause of > many of those failures. For ki18n and kcontacts another possible cause could be the iso-codes translation catalogs missing. Are those by any chance packaged separately as on some Linux distributions? Regards, Volker signature.asc Description: This is a digitally signed message part.
Reminder: KF6 Meeting
Hello everyone, please remember the KF6 meeting tomorrow, Tuesday 17:00 CET: https://meet.kde.org/b/ada-mi8-aem Topics and notes are collected here: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/74 Thank you, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Review: Skladnik (t.g.f.k.a. KSokoban), returning a KDE1-KDE3 age dino
On Samstag, 27. Januar 2024 18:22:35 CET Friedrich W. H. Kossebau wrote: > There are only 2 open checkboxes: > > [ ] Passing CI job for Reuse linting > > The challenge is that there are a number of old files where the contributors > might be hard to contact for an explicit license statement (CMakeLists.txt, > AUTHOR, Messages.sh, ...) > > Given the same is true for most other KDE games and then some KDE software, > and Skladnik is actually some (very) old KDE software, just other than its > KDE games siblings for some time had been excluded from release coverage, I > would ask us to make a pragmatic exception on the requirement here. Yes, and doing that is actually existing practice. This point applies primarily to new code, we obviously can't expect this to get magically fixed in preexisting code that just moved around or got renamed. Regards, Volker signature.asc Description: This is a digitally signed message part.
[KDE Itinerary] [Bug 480273] Support for City mobil in Deutche Bahn Online Ticket
https://bugs.kde.org/show_bug.cgi?id=480273 --- Comment #3 from Volker Krause --- (In reply to cquike from comment #2) > Great! Do I understand that you have all the information and you don't need > an example pdf? > Thanks! Correct, I have plenty of those myself :) -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 480273] Support for City mobil in Deutche Bahn Online Ticket
https://bugs.kde.org/show_bug.cgi?id=480273 --- Comment #1 from Volker Krause --- Makes sense. We do have the necessary information in the ticket parser already, this is "just" a matter of forwarding this accordingly and showing it in the UI somewhere. -- You are receiving this mail because: You are watching all bug changes.
Re: KDE Gear projects with failing CI (master) (23 January 2024)
On Dienstag, 23. Januar 2024 21:35:56 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. > > Good news: 5 repositories got fixed > > Bad news: 2 repo still failing (1 with a different failure) and *10* new > this week KMime is fixed in all branches now, the test regression in akonadi-search in master is also fixed, but the general FreeBSD fallout breaking MySQL and PostgreSQL Akonadi tests remains. Regards, Volker signature.asc Description: This is a digitally signed message part.
Reminder: KF6 Meeting
Hello everyone, please remember the KF6 meeting tomorrow, Tuesday 17:00 CET: https://meet.kde.org/b/ada-mi8-aem Topics and notes are collected here: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/73 Thank you, Volker signature.asc Description: This is a digitally signed message part.
[KDE Itinerary] [Bug 479819] Flatpak version gives error
https://bugs.kde.org/show_bug.cgi?id=479819 Volker Krause changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Volker Krause --- The fixes have propagated to Flathub meanwhile. -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 479819] Flatpak version gives error
https://bugs.kde.org/show_bug.cgi?id=479819 --- Comment #5 from Volker Krause --- Git commit dc8bebdf031c26219ac17264d077ad3ffc82b199 by Volker Krause. Committed on 17/01/2024 at 17:53. Pushed by vkrause into branch 'release/23.08'. Build ZXing statically to avoid clashing with the one in the platform The org.kde.Platform contains an internal dynamically linked ZXing, if our version differs in an ABI-incompatible way things break. Avoid that by linking our one statically into KItinerary, the only place needing it here. (cherry picked from commit a637744a176eb8f89c01189a0115b1393cb57cc6) M +1-1.flatpak-manifest.json https://invent.kde.org/pim/itinerary/-/commit/dc8bebdf031c26219ac17264d077ad3ffc82b199 -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 479908] Footnote on local weather page doesn't show weather provider URL nor license
https://bugs.kde.org/show_bug.cgi?id=479908 Volker Krause changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #2 from Volker Krause --- Yep, that's blue text on a blue background on Android, fixed in 24.02 already. -- You are receiving this mail because: You are watching all bug changes.
[KDE Itinerary] [Bug 479819] Flatpak version gives error
https://bugs.kde.org/show_bug.cgi?id=479819 --- Comment #3 from Volker Krause --- Git commit a637744a176eb8f89c01189a0115b1393cb57cc6 by Volker Krause. Committed on 15/01/2024 at 17:44. Pushed by vkrause into branch 'master'. Build ZXing statically to avoid clashing with the one in the platform The org.kde.Platform contains an internal dynamically linked ZXing, if our version differs in an ABI-incompatible way things break. Avoid that by linking our one statically into KItinerary, the only place needing it here. M +1-1.flatpak-manifest.json https://invent.kde.org/pim/itinerary/-/commit/a637744a176eb8f89c01189a0115b1393cb57cc6 -- You are receiving this mail because: You are watching all bug changes.
Reminder: KF6 Meeting
Hello everyone, please remember the KF6 meeting tomorrow, Tuesday 17:00 CET: https://meet.kde.org/b/ada-mi8-aem Topics and notes are collected here: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/72 Thank you, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/24.02) (Branching edition)
On Freitag, 12. Januar 2024 19:36:34 CET Volker Krause wrote: > On Freitag, 12. Januar 2024 10:59:27 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: We have more things failing than we should have, but it's kind > > of > > expected on a branching > > > > kitinerary: > > * https://invent.kde.org/pim/kitinerary/-/pipelines/580364 > > > > * static-extractor fails to compile > > That's a job not even meant to run automatically... anyway, fixed. > > > kosmindoormap: > > * https://invent.kde.org/libraries/kosmindoormap/-/pipelines/580051 > > > > * It's trying to find packages in a wrong branch > > > > itinerary: > > * https://invent.kde.org/pim/itinerary/-/pipelines/580366 > > > > * Fails because kosmindoormap failed > > That issue is fixed (and thus the CI stage passes), but both are now stuck > on the Craft APK packaging error from the Android NDK update, Ingo is > looking into that I think. And fixed with https://invent.kde.org/frameworks/extra-cmake-modules/-/ merge_requests/419 Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/24.02) (Branching edition)
On Freitag, 12. Januar 2024 10:59:27 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: We have more things failing than we should have, but it's kind of > expected on a branching > > kitinerary: > * https://invent.kde.org/pim/kitinerary/-/pipelines/580364 > * static-extractor fails to compile That's a job not even meant to run automatically... anyway, fixed. > kosmindoormap: > * https://invent.kde.org/libraries/kosmindoormap/-/pipelines/580051 > * It's trying to find packages in a wrong branch > > itinerary: > * https://invent.kde.org/pim/itinerary/-/pipelines/580366 > * Fails because kosmindoormap failed That issue is fixed (and thus the CI stage passes), but both are now stuck on the Craft APK packaging error from the Android NDK update, Ingo is looking into that I think. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Why (some) KDE software are not available in Android stores?
On Mittwoch, 10. Januar 2024 15:44:27 CET Ingo Klöcker wrote: > On Mittwoch, 10. Januar 2024 15:22:50 CET Filipe Saraiva wrote: > > Just a doubt, KDE has several interesting mobile software which support > > Android but they are not available in Android stores, like Neochat, > > Tokodon, Alligator, Kasts, etc. > > Those apps are available in our F-Droid "stores": > https://community.kde.org/Android/F-Droid > > But I guess you mean the Google store (and maybe other proprietary Android > stores). > > > Why? Is that some technical reason related to our stack, person-power > > hour to work in provide these releases, or other thing? > > The lack of person-power is the most important reason. The technical process > is pretty straightforward nowadays, but someone needs to check if the apps > comply with the store policies. > > No. Wait. For new apps there's also a technical reason. For new apps Google > Play requires application bundles (AAB) instead of APKs. We can build AAB > (at least for Qt 5) on invent, but we cannot sign them yet. Shouldn't be to > hard to add given that it's mostly identical to APK signing. I'm going to > work on this once signing of Windows binaries is done. Related to that: we probably want to use a new key for the AAB signing, as we have to hand that one out to Google when publishing AABs to their store AFAIU? Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/23.08) (9 January 2024)
On Mittwoch, 10. Januar 2024 09:09:35 CET Ingo Klöcker wrote: > On Mittwoch, 10. Januar 2024 01:00:06 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. > > > > Good news: The 2 repositories that were failing are fixed :) > > > > Bad news: 1 new repository failing > > > > itinerary - NEW > > > > * https://invent.kde.org/pim/itinerary/-/pipelines/577504 > > > > * All craft_android builds are failing > > Probably related to khealthcertificate becoming Qt6-only on Monday. Yep, should be fixed now. Regards, Volker signature.asc Description: This is a digitally signed message part.
Reminder: KF6 Meeting
Hello everyone, please remember the KF6 meeting tomorrow, Tuesday 17:00 CET: https://meet.kde.org/b/ada-mi8-aem Topics and notes are collected here: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/71 Thank you, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/23.08) (2 January 2024)
On Dienstag, 2. Januar 2024 23:18:58 CET Ben Cooksley wrote: > On Wed, Jan 3, 2024 at 10:51 AM Volker Krause wrote: > > On Dienstag, 2. Januar 2024 22:01:25 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 new repositories are failing :( > > > > > > > > > == Something is up with kdiagram == > > > > > > kdepim-addons: > > > * https://invent.kde.org/pim/kdepim-addons/-/pipelines/572121 > > > > Build is still running on FreeBSD, but this should be fixed. > > > > > == Something is up with kweathercore == > > > > > > kweather: > > > * https://invent.kde.org/utilities/kweather/-/pipelines/572137 > > > > This one is more complicated. KWeatherCore master is Qt6-only, but there > > is no > > branch for past releases, only tags. So the CI has no Qt5 build of it > > anymore, > > which however is needed for the Qt5-based KWeather build. > > > > The best I can think of right now is adding a dummy kf5 branch on the v0.7 > > tag? > > That is what I would recommend at this point. We don't support publishing > CI artifacts from tags at the moment as that requires marking them as > protected (which may cause other issues and would need to be looked into > seperately) That almost worked: the v0.7 tag is so old that it still has the dysfunctional CI template include style. So I had to move the kf5 branch to right before the Qt5 support removal, but I don't think that matters much here. One more reason for KWeatherCore to also move to one of the automated release schemes IMHO. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (release/23.08) (2 January 2024)
On Dienstag, 2. Januar 2024 22:01:25 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 new repositories are failing :( > > > == Something is up with kdiagram == > > kdepim-addons: > * https://invent.kde.org/pim/kdepim-addons/-/pipelines/572121 Build is still running on FreeBSD, but this should be fixed. > == Something is up with kweathercore == > > kweather: > * https://invent.kde.org/utilities/kweather/-/pipelines/572137 This one is more complicated. KWeatherCore master is Qt6-only, but there is no branch for past releases, only tags. So the CI has no Qt5 build of it anymore, which however is needed for the Qt5-based KWeather build. The best I can think of right now is adding a dummy kf5 branch on the v0.7 tag? Regards, Volker signature.asc Description: This is a digitally signed message part.
Reminder: KF6 Meeting
Hello everyone, please remember the KF6 meeting tomorrow, Tuesday 17:00 CET: https://meet.kde.org/b/ada-mi8-aem Topics and notes are collected here: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/70 Thank you, Volker signature.asc Description: This is a digitally signed message part.
[KOSMIndoorMaps] [Bug 478699] Building for Qt6 fails with a missing find_package line
https://bugs.kde.org/show_bug.cgi?id=478699 Volker Krause changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DOWNSTREAM --- Comment #1 from Volker Krause --- Side-effect of Fedora breaking up the protobuf package more than CMake expects, installing protobuf-lite-devel fixes this. -- You are receiving this mail because: You are watching all bug changes.
Reminder: KF6 Meeting
Hello everyone, please remember the KF6 meeting tomorrow, Tuesday 17:00 CET: https://meet.kde.org/b/ada-mi8-aem Topics and notes are collected here: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/69 Thank you, Volker signature.asc Description: This is a digitally signed message part.
Reminder: KF6 Meeting
Hello everyone, please remember the KF6 meeting tomorrow, Tuesday 17:00 CET: https://meet.kde.org/b/ada-mi8-aem Topics and notes are collected here: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/68 Thank you, Volker signature.asc Description: This is a digitally signed message part.
Re: Unified internal communications channel
On Donnerstag, 7. Dezember 2023 18:04:24 CET Carl Schwan wrote: > On Thursday, December 7, 2023 4:15:36?PM CET Nate Graham wrote: > > What I'm proposing is some kind of place that *only* has internal > > announcements and is very log signal-to-noise such that we can > > fearlessly recommend that *everybody* subscribe to it. In addition, > > ideally those who want to subscribe via mailing list could do so, but > > its content would automatically appear in other places too, such as > > discuss.kde.org and an invent.kde.org project. That way people can > > subscribe by whatever means is most comfortable to them. > > > > Thoughts? > > I fear this will just create a new source of information instead of unifying > the source of information. We already have the following channels for > announcements: > > - planet.kde.org: contains release announcements, gear release schedule > announcement from Albert as well as random development updates > - kde-code-de...@kde.org: contains mostly news about new apps and modules > - kde-de...@kde.org: contains the gear release schedule announcements and > other technical announcements > - plasma-devel@kde.org: contains important for plasma developers and the > meeting notes of the monday chat meeting. > - kde-commun...@kde.org contains general community (non technical) > announcements > > Adding a new channel that is either a mailing list, rss feed or a forum > category won't help and will probably only makes it worse. It's also very > difficult to defines that is an important internal news for the whole > community is as it will be different for every subproject in KDE. The > plasma logo discussion would have not been very relevant for any app > developers. Similarly discussion about the new default database backend for > Akonadi won't be interesting for Plasma developers but might be interesting > for KMyMoney and other non-PIM apps using Akonadi. Technically we do have a low-traffic channel for everyone even, kde-cvs- announce. That one is even mandatory for people with contributor accounts AFAIK, you get added to that by default. However that is really only for things relevant for everyone, such as important infrastructure changes. A topic like the one that triggered this discussion obviously doesn't qualify for that, that was mostly relevant for people involved in Plasma. So we'd need to clarify who we mean by "everybody" here, and I suspect that will be a subset of people varying from topic to topic. If so, one more channel is unlikely to magically fix things I think. > Something that might help is merging the kde-core-devel and kde-devel > mailing lists as those are very similar and should hopefully not be too > complicated to do. And/or kde-frameworks-devel, yes, we probably don't need all three of those anymore. While it might help a bit in finding appropriate channels to address the subset of people you want/need to reach it's somewhat orthogonal to Nate's proposal and would not have made any difference for the Plasma logo discussion I think. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Unified internal communications channel
On Donnerstag, 7. Dezember 2023 18:04:24 CET Carl Schwan wrote: > On Thursday, December 7, 2023 4:15:36?PM CET Nate Graham wrote: > > What I'm proposing is some kind of place that *only* has internal > > announcements and is very log signal-to-noise such that we can > > fearlessly recommend that *everybody* subscribe to it. In addition, > > ideally those who want to subscribe via mailing list could do so, but > > its content would automatically appear in other places too, such as > > discuss.kde.org and an invent.kde.org project. That way people can > > subscribe by whatever means is most comfortable to them. > > > > Thoughts? > > I fear this will just create a new source of information instead of unifying > the source of information. We already have the following channels for > announcements: > > - planet.kde.org: contains release announcements, gear release schedule > announcement from Albert as well as random development updates > - kde-code-de...@kde.org: contains mostly news about new apps and modules > - kde-devel@kde.org: contains the gear release schedule announcements and > other technical announcements > - plasma-de...@kde.org: contains important for plasma developers and the > meeting notes of the monday chat meeting. > - kde-commun...@kde.org contains general community (non technical) > announcements > > Adding a new channel that is either a mailing list, rss feed or a forum > category won't help and will probably only makes it worse. It's also very > difficult to defines that is an important internal news for the whole > community is as it will be different for every subproject in KDE. The > plasma logo discussion would have not been very relevant for any app > developers. Similarly discussion about the new default database backend for > Akonadi won't be interesting for Plasma developers but might be interesting > for KMyMoney and other non-PIM apps using Akonadi. Technically we do have a low-traffic channel for everyone even, kde-cvs- announce. That one is even mandatory for people with contributor accounts AFAIK, you get added to that by default. However that is really only for things relevant for everyone, such as important infrastructure changes. A topic like the one that triggered this discussion obviously doesn't qualify for that, that was mostly relevant for people involved in Plasma. So we'd need to clarify who we mean by "everybody" here, and I suspect that will be a subset of people varying from topic to topic. If so, one more channel is unlikely to magically fix things I think. > Something that might help is merging the kde-core-devel and kde-devel > mailing lists as those are very similar and should hopefully not be too > complicated to do. And/or kde-frameworks-devel, yes, we probably don't need all three of those anymore. While it might help a bit in finding appropriate channels to address the subset of people you want/need to reach it's somewhat orthogonal to Nate's proposal and would not have made any difference for the Plasma logo discussion I think. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Report of packaging issues with mega release
Thanks, these reports are very helpful! On Samstag, 2. Dezember 2023 00:12:04 CET Antonio Rojas wrote: > This list is based on the beta tarballs with some (already committed) fixes > on top to fix build with latest kdiagram and plasma-activities. > > Frameworks: > > - ktexteditor: conflicts with KF5 > > /usr/share/dbus-1/system-services/org.kde.ktexteditor.katetextbuffer.servic > e /usr/share/dbus-1/system.d/org.kde.ktexteditor.katetextbuffer.conf > /usr/share/polkit-1/actions/org.kde.ktexteditor.katetextbuffer.policy https://invent.kde.org/frameworks/ktexteditor/-/merge_requests/643 > Gear: > - kpublictransport: Qt5/6 versions collide. Qt5 version needed by > kosmindoormap and itinerary. Blocks packaging itinerary. I hope we get Itinerary switched in time as well, which would resolve this and the Quotient issue below. That was mainly blocked by Android Qt6 packages not working at all until recently, but we made good progress on that recently. Regards, Volker signature.asc Description: This is a digitally signed message part.
Reminder: KF6 Meeting
Hello everyone, please remember the KF6 meeting tomorrow, Tuesday 17:00 CET: https://meet.kde.org/b/ada-mi8-aem Topics and notes are collected here: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/67 Thank you, Volker signature.asc Description: This is a digitally signed message part.
Re: KDE Gear projects with failing CI (master) (22 November 2023)
On Donnerstag, 23. November 2023 12:04:24 CET Ingo Klöcker wrote: > On Donnerstag, 23. November 2023 00:09:48 CET Albert Astals Cid wrote: > > == kuserfeedback woes == > > > > kate > > > > * https://invent.kde.org/utilities/kate/-/pipelines/538985 > > > > dolphin > > > > * https://invent.kde.org/system/dolphin/-/pipelines/538986 > > > > kuserfeedback isn't available for Windows in the registry. Looking at it, > > it hasn't compiled for days, what's going on there? > > Windows CI has recently been switched to Qt 6.6. If kuserfeedback master > wasn't built since then then it's obvious why no Qt 6.6 build is available > in the registry. Our CI doesn't magically rebuilt all projects if we update > the CI images. Could this be fixed? Probably. That's what the seed jobs are for, they were just not adapted yet to KUserFeedback moving to Frameworks: https://invent.kde.org/sysadmin/ci-management/-/merge_requests/88 Regards, Volker signature.asc Description: This is a digitally signed message part.
Reminder: KF6 Meeting
Hello everyone, please remember the KF6 meeting tomorrow, Tuesday 17:00 CET: https://meet.kde.org/b/ada-mi8-aem Topics and notes are collected here: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/66 Thank you, Volker signature.asc Description: This is a digitally signed message part.
