Re: KDE Gear projects with failing CI (master) (12 September 2023)
On Wed, Sep 20, 2023 at 7:29 AM Albert Astals Cid wrote: > Please work on fixing them, otherwise i will remove the failing CI > jobs on their 4th failing week, it is very important that CI is passing > for > multiple reasons. > > Good news: We have 2 repositories less failing :) > > Bad news: We have 3 new repositories failing :/ > > = FLATPAK FAILING = > > kopete: > * https://invent.kde.org/network/kopete/-/pipelines/484176 > > > = FAILING UNIT TESTS = > > konsole: (2nd week) > * https://invent.kde.org/utilities/konsole/-/pipelines/484169 > * freebsd_qt515 tests are failing > Sysadmin has been asked to take a look into this one, as by all accounts there is no reason for this to suddenly start failing out of the blue with no changes in Konsole itself. I'm suspecting regressions within either our FreeBSD setup, or somewhere in Frameworks (KParts specifically) at the moment. > cantor: > * https://invent.kde.org/education/cantor/-/pipelines/484170 > * freebsd_qt515 tests are failing > > akonadi-search: > * https://invent.kde.org/pim/akonadi-search/-/pipelines/484177 > * freebsd_qt515 tests are failing > > > Cheers, Ben
Re: flatpak CI and stable builds - Re: KDE Gear projects with failing CI (release/23.08) (12 September 2023)
On Wed, Sep 20, 2023 at 9:42 AM Albert Astals Cid wrote:
> El dimarts, 19 de setembre de 2023, a les 22:18:40 (CEST),
> christ...@cullmann.io va escriure:
> > On 2023-09-19 21:35, 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 2 new repositories failing :/
> > >
> > > = FLATPAK FAILING =
> > >
> > > kate:
> > > * https://invent.kde.org/utilities/kate/-/pipelines/484147
> > >
> > > * This highlights a design problem, it's building markdown part from
> > >
> > > master
> > > instead of from stable branch. We can manually change the branch, but i
> > > would
> > > prefer a solution that doesn't mean changing lots and lots of flatpak
> > > manifests when we branch.
> >
> > Hmm, yes that sounds not nice.
> >
> > But not sure how that would work without that, seems
> >
> >
> https://invent.kde.org/utilities/kate/-/blob/master/.flatpak-manifest.json?r
> > ef_type=heads
> >
> > hard codes what to fetch.
> >
> > Given one hard codes there the
> >
> > "runtime-version": "5.15-22.08",
>
> That one is "fine", the 22.08 here it's related to the "flatpak kde/
> freedesktop sdk" not to Gear stuff.
>
> Yes, we will massively have to update them on master when we decide to
> depend
> on a new one, but it won't cause problems on the stable branches like the
> oner
> we're experiencing here.
>
> The problem here is
>
> {
> "name": "markdownpart",
> "buildsystem": "cmake-ninja",
> "sources": [
> {
> "type": "git",
> "url": "https://invent.kde.org/utilities/markdownpart.git";
> }
> ]
> }
>
> This unconditionally compiles the master branch of markdownpart repo
>
> As far as i can see there's three solutions:
>
> A) If this is just "to make sure it builds CI", we don't need markdownpart
> nor
> konsole on the flatpak since they are just runtime dependencies. This is a
> sub-optimal solution i'd say since it makes it so that we can't offer the
> package for testing in the future and makes the diff with the flathub
> manifest
> bigger than it needs to be
>
The overall intention is for the bundles produced by the Flatpak jobs to be
useful for people to locally test a project build.
In the not too distant future we'll have them available from a Flatpak
repository for actual mainline/release branches as well.
So the answer certainly isn't (a).
>
> B) Depend on released versions, i.e. a tarball in "sources" instead of a
> git
> repo. This is probably suboptimal too in the sense that will require
> constant
> updating on master and if we offer the resulting flatpak as "nightly" in
> the
> future for testing it's not "nightly" as it could be.
>
Guess it depends on the nature of the dependency, but in the case of
software released together you probably want to build against what you will
be shipping against yes.
>
> C) Add a marker in the .json like branch: "kde-same-branch" and then have
> the
> code in
> https://invent.kde.org/sysadmin/ci-utilities/raw/master/gitlab-templates/flatpak.yml
> replace that "kde-same-branch" either by "master" or by
> the appropriate stable branch before actually compiling the flatpak. I
> think
> this would be the optimal solution but needs work.
>
This is my preferred solution as well. it wouldn't be too difficult given
we have a Python script acting as a middle-man already.
In the past we did some rewriting of the .flatpak-manifest.yml already.
Depending on our requirements it may be worth tying into the same
branch-rules.yml logic that the rest of the CI system uses but this is
probably best answered by someone who knows the various Flatpak manifests
we have better.
In #flatpak:kde.org it was mentioned that this would mean that people
wouldn't be able to build it as easily themselves, but if we make it well
documented (comments in the .flatpak-manifest.yml, etc) then I think this
shouldn't be much of an issue.
>
> D) Something smarter I have not thought about.
>
> Cheers,
> Albert
>
Cheers,
Ben
>
> >
> > I assume one will need to hard code that, too, if one creates no own
> > scripting.
> >
> > But I might be wrong.
> >
> > Greetings
> > Christoph
> >
> > > = FAILING UNIT TESTS =
> > >
> > > konsole:
> > > * https://invent.kde.org/utilities/konsole/-/pipelines/484148
> > >
> > > * freebsd_qt515 tests are failing
>
>
>
>
>
Fwd: KDE Eco meetup, Wed. 20 September 17-18h UTC | Sustainable Software goal
For those interested in measuring the energy consumption of software, please join the KDE Eco meetup tonight at 17 UTC for a presentation of KEcoLab (see below for details, including BBB link). KEcoLab is the GSoC project of Karanjot Singh. The tool enables you to measure the energy consumption of software remotely using a CI/CD pipeline in GitLab. Here is the repository: https://invent.kde.org/teams/eco/remote-eco-lab Hope to see many of you there! Cheers, Joseph Forwarded Message Subject: KDE Eco meetup, Wed. 20 September 17-18h UTC | Sustainable Software goal Date: Fri, 1 Sep 2023 11:56:51 +0200 From: Joseph P. De Veaugh-Geiss Organization: KDE e.V. To: energy-efficie...@kde.org For a couple of reasons this month we will meet the third Wednesday on Wed. *20 September*! All are invited to join to make progress on the Sustainable Software goal. This meetup will be particularly exciting: it coincides with the launch of the KEcoLab, which Karanjot will present to the community! We will also discuss integration of KEcoLab into the development pipeline as well as measuring with Selenium. Looking forward to seeing many of you there :) I will send a reminder closer to the date. _Overview_ *When*: Wed. 20 September 17-18h UTC (ics calendar attached) *Where*: https://meet.kde.org/b/jos-l59-2i1-9yt *Topic*: Ideas under discussion are collected at this pad -- please add ideas of your own! https://collaborate.kde.org/s/cactBt4frrfTjbW Cheers, Joseph For general information about the Sustainable Software goal, see: https://community.kde.org/Goals/Sustainable_Software Workboard: https://invent.kde.org/teams/eco/sustainable-software-goal/-/boards -- Joseph P. De Veaugh-Geiss KDE Internal Communications & KDE Eco Community Manager OpenPGP: 8FC5 4178 DC44 AD55 08E7 DF57 453E 5746 59A6 C06F Matrix: @joseph:kde.org Generally available Monday-Thursday from 10-16h CET/CEST. Outside of these times it may take a little longer for me to respond. KDE Eco: Building Energy-Efficient Free Software! Website: https://eco.kde.org Mastodon: @be4foss@floss.socialBEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:Europe/Berlin BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T03 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20230830T132430Z LAST-MODIFIED:20230901T094038Z DTSTAMP:20230901T094038Z UID:97ef1cef-38d7-4279-b7fa-5d038870be47 SUMMARY:KDE Eco community meetup DTSTART;TZID=Europe/Berlin:20230920T19 DTEND;TZID=Europe/Berlin:20230920T20 TRANSP:OPAQUE LOCATION:https://meet.kde.org/b/jos-l59-2i1-9yt DESCRIPTION;ALTREP="data:text/html,%3Cbody%3E*When*%3A%20Wednesday%2013%20S eptember%2017-18h%20UTC%3Cbr%3E%0A%0A%0A%0A%0A%0A%3Cbr%3E%0A%0A%0A%0A%0A%0A *Where*%3A%20https%3A%2F%2Fmeet.kde.org%2Fb%2Fjos-l59-2i1-9yt%3Cbr%3E%0A%0A %0A%0A%0A%0A%3Cbr%3E%0A%0A%0A%0A%0A%3Cdiv%3E*Topic*%3A%20open%20discussion% 20(see%20pad)%3C%2Fdiv%3E%0A%0A%0A%0A%3Cdiv%3E%3Cbr%3E%0A*Pad*%3A%20https%3 A%2F%2Fcollaborate.kde.org%2Fs%2FcactBt4frrfTjbW%3C%2Fdiv%3E%0A%0A%0A%0A%0A %0A%0A%3Cbr%3E%0A%0A%0A%0A%0A%0AFor%20general%20information%20about%20the%2 0goal%2C%20see%3A%20%0Ahttps%3A%2F%2Fcommunity.kde.org%2FGoals%2FSustainabl e_Software%0A%3Cdiv%3E%3Cbr%3E%0A%3C%2Fdiv%3E%0A%0A%0A%0A%0A%3Cdiv%3EWorkbo ard%3A%20%0Ahttps%3A%2F%2Finvent.kde.org%2Fteams%2Feco%2Fsustainable-softwa re-goal%2F-%2Fboards%0A%0A%3C%2Fdiv%3E%0A%3C%2Fbody%3E":*When*: Wednesday 1 3 September 17-18h UTC\n\n*Where*: https://meet.kde.org/b/jos-l59-2i1-9yt\n \n*Topic*: open discussion (see pad)\n\n*Pad*: https://collaborate.kde.org/ s/cactBt4frrfTjbW\n\nFor general information about the goal\, see:\nhttps:/ /community.kde.org/Goals/Sustainable_Software\n\nWorkboard: https://invent. kde.org/teams/eco/sustainable-software-goal/-/boards\n SEQUENCE:1 X-MOZ-GENERATION:1 END:VEVENT END:VCALENDAR
Re: First round of feedback from Fedora 40 KDE Plasma 6 (Wayland-only) discussion
Hi everyone, Thanks Neal for including me! (For the people who don't know me, I work for Red Hat as the product owner in the GPU team, which has maintained (and some time ago deprecated) Xorg, as well as maitning other graphics APIs such as Wayland, OpenGL, Vulkan etc. I'm also a GNOME contributor in my free time and sometimes do Wayland advocacy in local communities.) I'll put my answers inline so we can keep things a bit structured here. On Mon, Sep 18, 2023 at 6:45 AM Neal Gompa wrote: > > Hey all, > > So unless you've been living under a rock for the past week, you might > have noticed a bunch of buzz about Fedora KDE proposing to drop the > X11 session with Plasma 6[1]. Those of you who were at Akademy last > year[2] or this year[3] knew that this was coming. For the rest of > you... 🤭 > > Over the past few days, I've gotten a deluge of use-cases and needs > that would be useful to sort through and figure out actions to move > forward on. Some of them, I've got ideas, others less so. Before deep-diving: thanks for writing this up! It's good to have some discussions going on each topic > The first thing that came up was that KiCad seems to need help and has > had a bad experience interfacing with some folks over resolving their > issues moving into a Wayland world. > * > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/6KLDR4WM7PMJ7VJTP4LH2HA4RAMCR6UJ/ > * https://groups.google.com/a/kicad.org/g/devlist/c/-glHquy0b20/m/nSBa_ntOAAAJ > I don't have any particular suggestions here, though David Edmundson > mentioned in the Fedora KDE Matrix room the idea of creating a new > protocol to support their particular need of positioning and plumbing > it through to Qt so that wxQt can use it. Also, some dedicated > outreach might be a good idea to get them to be more amenable to the > Wayland world. In terms of general outreach to the KiCad project: I looked into it a while ago after a friend of mine pointed out that they thought it was a shame it didn't have Wayland support. Basically, the community had closed the issue for Wayland support as WONTFIX due to the belief that Wayland wouldn't fix their issues, so I tried to clear up some of the confusion: https://gitlab.com/kicad/code/kicad/-/issues/7207#note_1356840266 . At the very least it _looks_ like things improved since then, but it still needs a bit of "massaging" to keep mindsets in a positive environment. At the very least, it seems like some of their features might be unblocked, and they reopened the issue as well. FWIW: I'm a contributor to GIMP as well, and I had to work through a similar mentality, where people have/had similar negative attitudes towards Wayland. The problem is that also for them, it takes patience and understanding the problems they face, as they fall into an "XY problem" (https://en.wikipedia.org/wiki/XY_problem): "I need to have global positioning" (which is a WONTFIX current for most Wayland developers) vs "I want to restore the positions of my toplevel windows" (which would be solved with the xdg-session-management protocol that's proposed upstream). > Session restore has come up a few times. It actually came up during > the initial discussion within the SIG too, and has come up again > during the proposal discussion in Fedora. > * https://pagure.io/fedora-kde/SIG/issue/347#comment-856399 > * > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/D76KHIPEPS6N7N3QHX6KBVDQ4RF5NVYO/ > GNOME designed a protocol for their use, can we reuse this as an > initial way to solve this problem? What's stopping us from doing > something here? In case anyone's interested, Philip Withnall (who worked on this) made a blog post about it at https://tecnocode.co.uk/2023/08/07/guadec-2023/ , which also contains a link to the video & slides of his talk. > Barrier/Input-Leap has come up as well. Seamless keyboard and mouse > handoff across computers is in demand. > * https://discussion.fedoraproject.org/t/89794/6 > * https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12 > The necessary portal frontends have landed in xdg-desktop-portal and > so we're just missing the requisite backend in xdg-desktop-portal-kde. Just a quick note that Input Leap should be supported starting GNOME 45 (which will be shipped with Fedora 39) > Something that was a little surprising to find out is that kwin's > support for the number pad seems to be in less than ideal condition. > * > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/5VHB34MWX5UTJE3CLOINE6OBREQIX4RY/ > This doesn't seem huge to fix, but I don't know a lot about key maps... > > A rather dominating part of the discussion has been color management > (or the current lack thereof). > * https://discussion.fedoraproject.org/t/89794/12 > * https://discuss.kde.org/t/fedora-kde-40-plans-to-completely-drop-x11/5047 > * https://invent.kde.org/plasma/kwin/-/issues/11 > This one seems to have b
Re: flatpak CI and stable builds - Re: KDE Gear projects with failing CI (release/23.08) (12 September 2023)
El dimecres, 20 de setembre de 2023, a les 13:17:22 (CEST), Ben Cooksley va
escriure:
> On Wed, Sep 20, 2023 at 9:42 AM Albert Astals Cid wrote:
> > El dimarts, 19 de setembre de 2023, a les 22:18:40 (CEST),
> >
> > christ...@cullmann.io va escriure:
> > > On 2023-09-19 21:35, 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 2 new repositories failing :/
> > > >
> > > > = FLATPAK FAILING =
> > > >
> > > > kate:
> > > > * https://invent.kde.org/utilities/kate/-/pipelines/484147
> > > >
> > > > * This highlights a design problem, it's building markdown part from
> > > >
> > > > master
> > > > instead of from stable branch. We can manually change the branch, but
> > > > i
> > > > would
> > > > prefer a solution that doesn't mean changing lots and lots of flatpak
> > > > manifests when we branch.
> > >
> > > Hmm, yes that sounds not nice.
> > >
> > > But not sure how that would work without that, seems
> >
> > https://invent.kde.org/utilities/kate/-/blob/master/.flatpak-manifest.json
> > ?r>
> > > ef_type=heads
> > >
> > > hard codes what to fetch.
> > >
> > > Given one hard codes there the
> > >
> > > "runtime-version": "5.15-22.08",
> >
> > That one is "fine", the 22.08 here it's related to the "flatpak kde/
> > freedesktop sdk" not to Gear stuff.
> >
> > Yes, we will massively have to update them on master when we decide to
> > depend
> > on a new one, but it won't cause problems on the stable branches like the
> > oner
> > we're experiencing here.
> >
> > The problem here is
> >
> > {
> >
> > "name": "markdownpart",
> > "buildsystem": "cmake-ninja",
> > "sources": [
> >
> > {
> >
> > "type": "git",
> > "url": "https://invent.kde.org/utilities/markdownpart.git";
> >
> > }
> >
> > ]
> >
> > }
> >
> > This unconditionally compiles the master branch of markdownpart repo
> >
> > As far as i can see there's three solutions:
> >
> > A) If this is just "to make sure it builds CI", we don't need markdownpart
> > nor
> > konsole on the flatpak since they are just runtime dependencies. This is a
> > sub-optimal solution i'd say since it makes it so that we can't offer the
> > package for testing in the future and makes the diff with the flathub
> > manifest
> > bigger than it needs to be
>
> The overall intention is for the bundles produced by the Flatpak jobs to be
> useful for people to locally test a project build.
> In the not too distant future we'll have them available from a Flatpak
> repository for actual mainline/release branches as well.
>
> So the answer certainly isn't (a).
>
> > B) Depend on released versions, i.e. a tarball in "sources" instead of a
> > git
> > repo. This is probably suboptimal too in the sense that will require
> > constant
> > updating on master and if we offer the resulting flatpak as "nightly" in
> > the
> > future for testing it's not "nightly" as it could be.
>
> Guess it depends on the nature of the dependency, but in the case of
> software released together you probably want to build against what you will
> be shipping against yes.
>
> > C) Add a marker in the .json like branch: "kde-same-branch" and then have
> > the
> > code in
> > https://invent.kde.org/sysadmin/ci-utilities/raw/master/gitlab-templates/f
> > latpak.yml replace that "kde-same-branch" either by "master" or by
> > the appropriate stable branch before actually compiling the flatpak. I
> > think
> > this would be the optimal solution but needs work.
>
> This is my preferred solution as well. it wouldn't be too difficult given
> we have a Python script acting as a middle-man already.
> In the past we did some rewriting of the .flatpak-manifest.yml already.
>
> Depending on our requirements it may be worth tying into the same
> branch-rules.yml logic that the rest of the CI system uses but this is
> probably best answered by someone who knows the various Flatpak manifests
> we have better.
>
> In #flatpak:kde.org it was mentioned that this would mean that people
> wouldn't be able to build it as easily themselves, but if we make it well
> documented (comments in the .flatpak-manifest.yml, etc) then I think this
> shouldn't be much of an issue.
I had not thought of that and it's indeed not great.
We could rename all the flatpak manifest that need this feature to .json.in to
make it clear "it's not their final form" and that they need to be pre-
processed.
This does not help a lot to the "non CI user" if they want to actually use the
manifest since they still need to pre-process it somehow :/
Solution E)
Since usually/mostly we have our projects be backwards API compatible it's
usually/mostly not a problem to that kate stable uses markdown master
(understanding the flatpaks generated by that CI are nightlies), we're only
[ANNOUNCE] CMake 3.27.6 available for download
We are pleased to announce that CMake 3.27.6 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! Changes made since CMake 3.27.5: Ben Boeckel (5): Tests/FortranModules: move issue 25112 fix from FortranOnly Tests/FortranModules: add a test case for #25223 add_custom_target: Fix regression with Fortran sources Tests/FortranModules: also test INTERFACE targets with Fortran sources Tests/FortranModules: add a test for iface Fortran sources Brad King (1): CMake 3.27.6
Re: KDE Gear projects with failing CI (master) (12 September 2023)
On Mittwoch, 20. September 2023 13:04:00 CEST Ben Cooksley wrote: > > = FAILING UNIT TESTS = > > > > konsole: (2nd week) > > > > * https://invent.kde.org/utilities/konsole/-/pipelines/484169 > > > > * freebsd_qt515 tests are failing > > Sysadmin has been asked to take a look into this one, as by all accounts > there is no reason for this to suddenly start failing out of the blue with > no changes in Konsole itself. > I'm suspecting regressions within either our FreeBSD setup, or somewhere in > Frameworks (KParts specifically) at the moment. I'm fixing the tests for Cantor now which started to fail after I pushed a change to master that is not related to the failing tests now. The tests are not stable against different timings and the async. communication with the external process needs to be handled better. So, I assume something was changed for the freeBSD setup that affects the performance and the timings during the test executions. Maybe newer or older hardware in use? Regards, Alexander
