Re: Automated usage of Gitlab
3. Juli 2022 um 13:43, "Nicolas Fella" schrieb: > > On 7/3/22 12:45, Ben Cooksley wrote: > > > > > Hi all, > > > > Recent analysis of the logs of our Giltab instance has revealed > > numerous instances of files being directly retrieved from Gitlab > > (using the /raw/ API). Much to my incredible sadness, this has > > included accesses being made by KDE Applications themselves. > > > > As a reminder, automated access to the "raw files" API of Gitlab is > > strictly prohibited and not permitted under any circumstances. The > > only use of it which is allowed is within .gitlab-ci.yml files to > > import job definitions from sysadmin/ci-utilities. > > > > At this time I am tracking: > > - Retrieval of qt/qt/qtbase - .qmake.conf and extra-cmake-modules - > > FindUDev.cmake and COPYING-CMAKE-SCRIPTS from systems operating in > > Microsoft Azure using curl. > > > > - Retrieval of *.colors files from the Breeze repositories, > > originating from KDE CI/CD servers, likely as a consequence of unit > > tests or Craft builds > > > > That looks like > https://invent.kde.org/packaging/craft-blueprints-kde/-/blob/master/kde/kdemultimedia/kdenlive/kdenlive.py#L116 > > That's the only usage of raw invent URLs I see in craft-blueprints-kde I removed that code now. It was introduced in a pre GitLab time and later just ported, but not need anymore. See https://invent.kde.org/packaging/craft-blueprints-kde/-/commit/26d86498d6deaf3183723575d487379f01525607 > > > > > - Retrieval of various code examples from various repositories, > > originating from KDE CI/CD servers, likely due to unit tests or Craft > > builds utilising them > > > > - Retrieval by Digikam itself of files from the Digikam code > > repository (see > > > > https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/onlineversion/onlineversionchecker.cpp) > > > > The last one is particularly upsetting, as this is how we ended up > > with a bad situation with Discover. > > > > Developers - please discuss with Sysadmin before implementing > > functionality in your software that communicates with KDE.org > > infrastructure so we can ensure that the endpoints you are contacting > > are highly scalable. > > Gitlab does not meet this criteria by any definition at all. > > > > If we could please get these corrected that would be appreciated. > > > > Thanks, > > Ben > > > Julius Künzel Volunteer KDE Developer, mainly hacking Kdenlive KDE GitLab: https://my.kde.org/user/jlskuz/ Matrix: @jlskuz:kde.org
Re: Per project repository snapcraft files?
To me it seems this discussion is quite abstract and there are several misunderstandings because not everybody knows every detail of snap packaging and/or the KDE infrastructure (me neither). I understand that from an organizational perspective most people like the idea of having the files in the repos, but have technical doubts. Hence, I wonder whether it would be a good idea to take one KDE app to try and showcase this suggestion? Cheers, Julius 20.08.2023 17:55:24 Laura David Hurka : > On Sunday, August 20, 2023 12:47:10 PM CEST Ben Cooksley wrote: >> On Sun, Aug 20, 2023 at 12:43 PM Scarlett Moore < >> >> scarlett.gately.mo...@gmail.com> wrote: >>> Only on release! We will not be building from master! We don't want >>> unstable snaps. >>> Thanks, >>> Scarlett >> >> In that particular case the jobs should be manually triggered only. >> >> Gitlab CI is really made for building artifacts for a given commit rather >> than for a specified version though, so this is definitely going to be a >> case of things not fitting quite right. >> >> Cheers, >> Ben >> [...] > > This confuses me too. > It seems Scarlett wants to use a “deploy” stage [1] and a job rule [2] > to run snap build&release jobs automatically when the release is done. > > If you mean that Gitlab CI should not be used to automate release jobs, > you should elaborate more how binary-factory is meant to be replaced. > > Otherwise, do you just note that Gitlab CI is suboptimal, > or do you recommend to use something else? > Like: “Release build: automatic is fine. Release publish: please only manual”? > > Cheers, David > > > [1] https://docs.gitlab.com/ee/ci/yaml/#stages > [2] like this: > snap-release-job: > rules: > -if: $CI_COMMIT_TAG =~ /^v[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]$/ > [...] > see also: > https://docs.gitlab.com/ee/ci/jobs/job_control.html#use-predefined-cicd-variables-to-run-jobs-only-in-specific-pipeline-types
Re: Bringing Glaxnimate into KDE
30.10.2023 18:07:44 Ben Cooksley : > On Tue, Oct 31, 2023 at 2:04 AM Carl Schwan wrote: >> On Monday, October 30, 2023 11:43:47 AM CET Mattia Basaglia wrote: Hi all, >> >>> Hi, >> >> Hi Matt, >> >>> I'm the maintainer of Glaxnimate (https://glaxnimate.mattbas.org/) a >>> vector graphics animation editor that has been integrated with kdenlive >>> through the MLT framework. I've been having talks with some of the >>> kdenlive devs and we came to the conclusion that it would be helpful to >>> bring Glaxnimate into KDE. >>> >>> With the help of jk from kdenlive, we've made the code reuse compliant, >>> and added some craft jobs to the CI. >>> I am very happy to see further progress on this! >> >>> I would need some guidance on how to push this further. >> >> First thing first, make sure you have read >> https://manifesto.kde.org/[https://manifesto.kde.org/commitments/] >> commitments/[https://manifesto.kde.org/commitments/] and >> https://manifesto.kde.org/benefits/ >> >> Then you need to find a sponsor and this mailing list is indeed the right >> place >> to do that. I think someone from the Kdenlive team with whom you already >> interacted (e.g. jk) would be the best for this task. In none of them has the >> time, I can probably also help. I am willing to sponsor Glaxnimate, however I never sponsored an app before and especially when it comes to releases etc. I would need some help myself (for Kdenlive we are in the comfortable situation to be part of Gear). So if someone else like you, Carl, will be around as a second sponsor would be great! >> >> >> Then create a sysadmin request to move your repo to the KDE infrastructure: >> https://phabricator.kde.org/maniphest/task/edit/form/2/ >> >> And ask to get a KDE developer account in https://identity.kde.org so you >> can >> keep your git write access to your project ;) > > These should be done simultaneously, and the requests should refer to each > other (doesn't need a link, just a note in there that this is part of > $project incubation) so we can ensure they're both processed at the same time. > While in most cases we pick up on these requests coming in simultaneously, it > has happened once or twice where people have lost access for a couple of days > as they didn't flag this. > >> >> Cheers, >> Carl > > Cheers, > Ben Cheers, Julius > > >> >>> >>> Thanks, >>> >>> Matt
Re: Interest in building an LLM frontend for KDE
02.12.2023 15:08:47 Carl Schwan : > On Friday, December 1, 2023 5:44:26?AM CET Andre Heinecke wrote: >> Hi. >> >> On Friday, 01 December 2023 03:53:22 CET Loren Burkholder wrote: >>> they can be quite useful for tasks like programming. >> >> I need it desperately for intelligent spellchecking / grammar fixes ?? >> >>> Should we be joining the mainstream push to put AI into everything or >>> should we stand apart and let Microsoft have its fun focusing on AI >>> instead of potentially more useful features? I don't recall seeing any >>> discussion about this before (at least not here), so I think those are >>> all questions that should be fairly considered before development on a >>> KDE LLM frontend begins. >> I don't think so. I have the slight feeling that you want to start an >> abstract discussion here and then magically the "KDE Community" will >> develop something. Just do it or don't. It will always be in the users >> freedom to use it or not. I would love to have an optional KMail plugin >> that interacts with an LLM. Others might not ?? > > I just want to point out that KMail has via KTextAddons already integration > with many AI technology both online and local. This is not enabled by default > and for many of the plugins this needs some extra configuration (e.g. API key) > to work. > > For translations, KTextAddons supports bergamot (local and open source), > libretranslate (local and open source) as well yandex, deepl, bing, google and > lingva. > > For grammar checks, KTextAddons supports languagetool (open core and self > hostable), grammalecte (open source but only for french). > > For speech to text, KTextAddons supports whishper (local and open source), > vosk (local and open source) and google > > For text to speech, KTextAddons uses QTextToSpeech underneath which uses a > varieties of local backend: https://doc.qt.io/qt-6/qttexttospeech-engines.html > > More details can be found in the repo > https://invent.kde.org/libraries/ktextaddons/ > > KTextAddons is currently used in Ruqola and the KDE PIM apps and I was hoping > to at some point also find the time to add it to some QML app. Laurent already > did some work to separete the core part from the widgets parts. > > Cheers, > Carl > >
Re: Interest in building an LLM frontend for KDE
02.12.2023 15:08:47 Carl Schwan : > On Friday, December 1, 2023 5:44:26?AM CET Andre Heinecke wrote: >> Hi. >> >> On Friday, 01 December 2023 03:53:22 CET Loren Burkholder wrote: >>> they can be quite useful for tasks like programming. >> >> I need it desperately for intelligent spellchecking / grammar fixes ?? >> >>> Should we be joining the mainstream push to put AI into everything or >>> should we stand apart and let Microsoft have its fun focusing on AI >>> instead of potentially more useful features? I don't recall seeing any >>> discussion about this before (at least not here), so I think those are >>> all questions that should be fairly considered before development on a >>> KDE LLM frontend begins. >> I don't think so. I have the slight feeling that you want to start an >> abstract discussion here and then magically the "KDE Community" will >> develop something. Just do it or don't. It will always be in the users >> freedom to use it or not. I would love to have an optional KMail plugin >> that interacts with an LLM. Others might not ?? > > I just want to point out that KMail has via KTextAddons already integration > with many AI technology both online and local. This is not enabled by default > and for many of the plugins this needs some extra configuration (e.g. API key) > to work. > > For translations, KTextAddons supports bergamot (local and open source), > libretranslate (local and open source) as well yandex, deepl, bing, google and > lingva. > > For grammar checks, KTextAddons supports languagetool (open core and self > hostable), grammalecte (open source but only for french). > > For speech to text, KTextAddons supports whishper (local and open source), > vosk (local and open source) and google > > For text to speech, KTextAddons uses QTextToSpeech underneath which uses a > varieties of local backend: https://doc.qt.io/qt-6/qttexttospeech-engines.html > > More details can be found in the repo > https://invent.kde.org/libraries/ktextaddons/ > > KTextAddons is currently used in Ruqola and the KDE PIM apps and I was hoping > to at some point also find the time to add it to some QML app. Laurent already > did some work to separete the core part from the widgets parts. > > Cheers, > Carl > > That is interesting, because we use Whisper and VOSK for subtitle generation (speech-to-text) in Kdenlive too. However unfortunately KTextAddons seem to have zero (API) documentation. I guess this might be one of the reasons its features are pretty unknown to devs outside of the pim universe. Cheers, Julius (Sorry for the empty message I accidentally sent before)
Re: KDE Gear projects with failing CI (master) (12 March 2024)
13.03.2024 08:40:20 Ingo Klöcker :
> On Mittwoch, 13. März 2024 00:12:17 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 repositories got fixed
>>
>> Bad news: 2 repository still failing and 7 new repositories failing this
>> week
>>
>>
>> filelight - 2nd week
>> * https://invent.kde.org/utilities/filelight/-/pipelines/628855
>> * craft fails
>
> One of the two macOS builds fails. No idea what the problem is because "Job's
> log exceeded limit of 4194304 bytes. Job execution will continue but no more
> output will be collected."
>
>> kig - NEW
>> * https://invent.kde.org/education/kig/-/pipelines/628852
>> * craft fails
>
> Both macOS builds failed.
>
> arm64: packaging failed, but there's not error message and no Craft logs for
> the packaging.
>
> x86-64: signing failed with
> ERROR macappsigner Error: Processing task '20240312T191325-education-
> kig_1647658' failed with ReadError('unexpected end of data').
> reported by tarfile
>
> I checked the tar file manually:
> tar: Unexpected EOF in archive
> tar: Error is not recoverable: exiting now
>
> Maybe the file wasn't closed/flushed before it was uploaded?
>
>> neochat - NEW
>> * https://invent.kde.org/network/neochat/-/pipelines/628957
>> * craft fails
>
> In this case the AppImage failed:
> Deploying dependencies for ELF file
> /builds/network/neochat/linux-64-gcc/build/
> kde/applications/neochat/archive/usr/lib/libQt6WebEngineCore.so.6.6.2
> ERROR: Could not find dependency: libtiff.so.5
> ERROR: Failed to deploy dependencies for existing files
>
> tiff isn't mentioned anywhere else in the log. Looks like a missing dependency
> on tiff, but I don't know in which Craft blueprint.
>
> Regards,
> Ingo
For filelight and kig: The logs for craft packaging are in the log named after
the package ie. filelight.log in this case. It failed at signing because the
codesign verification failed. Some binaries couldn't be signed.
I added an executable filter for both and redriggered the arm builds last night
before going to sleep. (For kig it failed again because I missed the return
super()... hence Craft considered it failed but without a log. This is fixed
meanwhile too.
Kdenlive Qt6 failure is fixed too.
Re: KDE Gear projects with failing CI (master) (19 March 2024)
Am 20. März 2024 um 06:02 schrieb "Justin Zobel" : > > On 20/3/24 08:55, Albert Astals Cid wrote: > > > > > Please work on fixing them, otherwise i will remove the failing CI jobs on > > > > their 4th failing week, it is very important that CI is passing for > > multiple > > > > reasons. > > > > Good news: 8 repositories got fixed > > > > Bad news: 1 repository still failing and 4 new repositories failing this > > week > > > > neochat - 2nd week > > > > * > > https://invent.kde.org/network/neochat/-/pipelines/637429 > > * craft_appimage_qt6_x86_64 fails > > > > kbruch - NEW > > > > * > > https://invent.kde.org/education/kbruch/-/pipelines/637302 > > * craft_macos_qt6_* fails > > > > kgeography - NEW > > > > * > > https://invent.kde.org/education/kgeography/-/pipelines/637304 > > * craft_macos_qt6_* fails > > > > kmplot - NEW > > > > * > > https://invent.kde.org/education/kmplot/-/pipelines/637305 > > * craft_macos_qt6_* fails > > > > kasts - NEW > > > > * > > https://invent.kde.org/multimedia/kasts/-/pipelines/637451 > > * flatpak fails > > > > * craft_windows_qt6_mingw64 fails > > > > Fixed the flatpak job, it just needed to be re-run as there was an issue > downloading the VLC tar. > > > > > Cheers, > > > > Albert > > > > Justin > I fixed the Craft macOS builds of KBruch, KMPlot and KGeography with the exception of the Intel macOS job for KGeography which fails with a differnt signing error now. I also fixed the QtWebengine dependency to tiff in Craft which fixes the NeoChat Appimage build hence I also re-enabled this job on the release/24.02 branch of NeoChat. Kasts Craft Windows build seems to have fixed itself. (BTW why does Kasts use MinGW Craft jobs while it seems to work with MSVC given that it has a Windows CI job which is MSVC based? MinGW should only be used if really needed) Julius Künzel Volunteer KDE Developer, mainly hacking Kdenlive KDE GitLab: www.invent.kde.org/jlskuz https://invent.kde.org/jlskuz Matrix: @jlskuz:kde.org https://go.kde.org/matrix/#/@jlskuz:kde.org
AppStream Metadata with our releases
Hi! (This mail goes to multiple lists, please reply to kde-devel) With Flathub beeing more strict on its AppStream metadata guidlines [1] there is yet another spotlight on AppStream metadata. 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]. For release info in particular the quality guidelines say: "Make sure all your releases have release notes, even minor ones." [3] As I think this makes perfectly sense, I like to propose two things that seem straight forward to me: - We should not remove older releases from the AppStream data as already suggested by Carl in a merge request [4]. - 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? I belive this makes it easier for developers to contribute to the release meta info and I hope it hence raises motivation to do so. I am happy to hear your opionions, thoughts and concerns! Cheers, Julius [1] https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines [2] https://apps.kde.org/ [3] https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/quality-guidelines/#release-notes [4] https://invent.kde.org/sysadmin/appstream-metainfo-release-update/-/merge_requests/6 Julius Künzel Volunteer KDE Developer, mainly hacking Kdenlive KDE GitLab: www.invent.kde.org/jlskuz https://invent.kde.org/jlskuz Matrix: @jlskuz:kde.org https://go.kde.org/matrix/#/@jlskuz:kde.org
Re: AppStream Metadata with our releases
22.03.2024 17:22:33 Albert Astals Cid : > El divendres, 22 de març de 2024, a les 0:37:00 (CET), Julius Künzel va > escriure: >> Hi! >> >> (This mail goes to multiple lists, please reply to kde-devel) >> >> With Flathub beeing more strict on its AppStream metadata guidlines [1] >> there is yet another spotlight on AppStream metadata. >> >> 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]. >> >> For release info in particular the quality guidelines say: "Make sure all >> your releases have release notes, even minor ones." [3] As I think this >> makes perfectly sense, I like to propose two things that seem straight >> forward to me: >> >> - We should not remove older releases from the AppStream data as already >> suggested by Carl in a merge request [4]. >> >> - 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? >> >> I belive this makes it easier for developers to contribute to the release >> meta info and I hope it hence raises motivation to do so. > > > My pessimistic opinion is that no one is going to add release notes, we've > tried multiple ways to do it, even just asking people to add a keyword to the > commit log if that commit log was release news worthy and no one did it past > the first few weeks/months. Well, that might happen, but we don't know if we don't try... And as I don't see this causing any extra work and (yet) can't see any downsides, it is even worth it if it helps just a single app or developer, no? > > It seems appstream has finally added the support (or maybe was there > forever?), so my suggestion is that we just add an release+url entry pointing > to > https://kde.org/announcements/gear/x.y.z/ > > This way we don't have to do the work twice and has the added bonus of already > translatable. > This is a nice suggestion too! However, I don't think this conflicts with my suggestion as the text in the appstream should usually be just a short summary of the highlights. So let's do both? > Only "problem" is that maybe if we get too many people contributing their > release news the announcements gets too long, but that'd be a nice problem to > have. > > Cheers, > Albert > > >> >> I am happy to hear your opionions, thoughts and concerns! >> >> Cheers, >> Julius >> >> [1] https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines >> [2] https://apps.kde.org/ >> [3] >> https://docs.flathub.org/docs/for-app-authors/metainfo-guidelines/quality-g >> uidelines/#release-notes [4] >> https://invent.kde.org/sysadmin/appstream-metainfo-release-update/-/merge_r >> equests/6 >> >> Julius Künzel >> Volunteer KDE Developer, mainly hacking Kdenlive >> KDE GitLab: www.invent.kde.org/jlskuz https://invent.kde.org/jlskuz >> Matrix: @jlskuz:kde.org https://go.kde.org/matrix/#/@jlskuz:kde.org
Re: icons in filelight on windows
Hi, it sounds as if reading this article would be the answer to your problem: https://cullmann.io/posts/kde-applications-and-icons/ at the end of the article there are some code examples. See also eg. https://invent.kde.org/utilities/kate/-/commit/a74a2657c7fb642c4062afb50a2c7920da315eca I hope this helps! Julius 22.06.2024 00:18:57 Harald Sitter : > Servas! > > Icons in filelight on windows are partially broken and I am not quite > sure why. What appears to happen is that the breeze icons are inside > the qresource system but don't get used by kirigami components because > they want to look in breeze-internal (which isn't actually resolving > through kiconthemes and as far as I can tell not in :/icons/* which is > probably why it fails to resolve). So then kiconthemes goes "yo, this > be missing, let's try fallback" except the fallback apparently is > hicolor and doesn't exist because we are on windows but it exists in > the qrc why that doesn't work is anyone's guess though. > > [7244] kf.iconthemes: Icon theme "breeze-internal" not found. > [7244] kf.iconthemes: Couldn't find current icon theme, falling back to > default. > [7244] kf.iconthemes: Standard icon theme "hicolor" not found! > > As ever I also don't know why filelight was ported to qt6 without > review by anyone. It's been a broken mess ever since, preventing me > from making a new release to the windows store. > > Everything is sad and I don't know what to do about it. Please help! :((
Re: KDE Gear projects with failing CI (master) (18 June 2024)
21.06.2024 09:56:54 christ...@cullmann.io: With make the problem doesn't seem to occur because it looks like the Makefiles serialize building of Test8 and Test8_cmake so that Test8_cmake is always built after Test8 where Test8 creates the headers that Test8_cmake uses. With ninja the builds of both targets don't seem to be serialized so that Test8_cmake could be built before Test8. -> Fail! >>> With that info, we got a fix in, but that won't fix CI since it uses >>> tarballs, should we get >>> https://invent.kde.org/frameworks/kconfig/-/merge_requests/314/diffs >>> added as a patch to Craft? >> In the meantime building of the KConfig tests has been disabled in Craft. We >> can just wait for KF 6.4. >> Actually, I'm wondering why we build tests in Craft at all. Craft doesn't run >> the tests, the tests are not packaged _and_ the purpose of the Craft jobs >> isn't CI. I'd say we should probably disable building of tests in general in >> Craft. Building them is just a waste of energy and time and I fail to see any >> benefit. When/if we want to start running the tests in Craft then we can >> simply >> re-enable their build. > > Ok, guess that would make sense and save power we just waste ATM. For macOS and MinGW we have no CI and hence I would prefer to keep them on to make sure they remain buildable. For all other platforms I 100% agree that we should disable them. > > Greetings > Christoph
Re: Guidelins for one codebase that builds with Qt5 and Qt6?
Hi Halla, you may also want to take a look at Kdenlive. Due to its complexity we also supported both Qt versions during the portion. Yet we have Qt6 as default and use it everywhere but still have Qt5 support which we plan to drop soon. Cheers, Julius 06.08.2024 09:23:39 Halla Rempt : > On maandag 5 augustus 2024 18:49:52 CEST Tobias Leupold wrote: >> E-Mail von Halla Rempt vom Montag, 5. August 2024, 16:15:19 MESZ: >>> Hi, >>> >>> We're finally working on porting Krita to Qt6, but that's going to be a long >>> road. I seem to remember that there were KDE apps that could be built with >>> both Qt6/Kf6 and Qt5/Kf5. Did I remember that right? And if so, is there >>> some howto or documentation for that? >>> >>> Thanks, >>> >>> Halla >> >> Hi, >> >> for https://invent.kde.org/tleupold/scandoc , I just set a "QT6" cmake switch >> (on/off) to decide if a Qt 5 or a Qt 6 build should be done. Just look at the >> CMakeFiles.txt, it's quite easy this way (I also do this exactly like that >> for >> https://muckturnier.org/ ; that's Qt-only, no KF, but after all, it's the >> same >> approach). > > I think I'll take that approach. > >> I think this depends on how much effort it would be to support both versions. >> For Scandoc, it wasn't much, so I decided to support Qt/KF 5 and 6 for now. >> That's also what I think I'll do for KGeoTag, once Marble will be ported to >> Qt >> 6. >> >> If it's a lot of work and/or manpower is limited (it's always, isn't it?!) it >> may be better to do a Qt-6-only port. That's what we're just doing for >> KPhotoAlbum. > > That's what I tried at first, but it soon became clear that while actual > porting is mostly mechanical, making Krita actually work with Qt6 is going to > be a long process. We cannot afford to not be able to release Krita again for > half a year or longer, so we have to find a way to keep releasing a working > Krita while keeping the Qt6 port up to date in the face of huge projects like > the text shape refactoring. > >> >> I don't think there's some official guideline about this, no? >> >> Cheers, Tobias >> >> >>
