KDE Gear Specific
As usual Dependency Freeze happens 1 week before beta, so in this case, it's November 22.
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to invent.kde.org and send the link to the release-team mailing list. We will check if the dependency is needed and is available on all platforms.
In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.
As mentioned above moving from Qt5 to Qt6 is an exception to this dependency freeze and can be done until RC1 (January 10)
I just tried kde6 alpha, following these instructions. After booting, I am facing a conflict issue between plasma-workspace and plasma-wayland-session. Also, I can not log in back using SDDM after locking the system. The password prompt is not visible.
PS: I am able to login using loginctl unlock-session from another terminal window.
Any solutions guys?
It is unfortunately source code being updated between the compile of separate components. Especially because we test for github commit updates (to not build packages over and over again, they only build if they have new commits).
So… latest commit is built with old-gen library, library is updated with symbol and, in this case spectacle is not.
Yeah, the plan is to put it on a chaotic github repo, everything (both the PKGBUILDS as well as the code to generate them and build them). The issue is on cleaning up stuff and making it good. But maybe its just better idea to do a “WIP-NOTCLEAN-DONTJUDGE” repo and then clean it up.
The cleaning thing is that the idea was to always follow upstream arch PKGBUILDs. But when we started this, there were no kde-unstable PKGBUILDS like the is now. So from, lets call it v1… where the scripts were mainly adapted from kde5, then manually check the .kdeci.yaml file of each project and fix dependencies, to now that we just piggy back out of the arch mantainers (following upstream like it was the goal all along).
Would it be reasonable and straight forward to change the compile scheme such that the entire code base is frozen and recompiled at certain intervals? For example, once a day. Otherwise there might be constant breakages whenever kio is updated. For example right now dolphin (9999.r7702.cb089cfa49.1-1) wouldn’t launch…
Alternately, if the PKGBUILDs are available, the user has the opportunity to recompile stuff and fix the issues themselves…
yes, there is! the issue is determing a “good interval”.
We were going to upload it to github (and will) … but got sidetracked. Dolphin is fixed, kwin is broken, doesnt build!
So, dont update right now (or update only dolphin).
EDIT: think we found the fix for it ! it was using an old plasma-wayland-protocols package! updated it, and then dependent libkscreen , kscreen and kwin (building here locally) should build.
Its weird, because arch unstable repo does not have plasma-wayland-protocols. when moved to arch kde-unstable repo, it was supposed to have everything! luckily I had a working backup from the PKGBUILD we did manually!
A small comment on all the pkgver()s… Would it make more sense to use the methods described in the wiki?
In particular, if we use git describe --long --tags --abbrev=7 | sed 's/\([^-]*-g\)/r\1/;s/-/./g;s/^v//' , we would get versions like 5.27.80.r10.g1e68eb3, instead of the current 9999.r2254.c1e68eb30.1-1. The versions would be in the same format as those in the officials repos, but would also be newer.
In addition, I think the pkgrel doesn’t need to be included in the output of pkgver().
Let me check… I will need to make some tests! (about the pkgver thingy).
Feel free to DM if you want or to open issues or pull requests on the github.
Just remember, all packages are to be “auto generated”, so changes to the PKGBUILDs may be done for quick fixes, but ultimately, they have to be done programmatically