kdewebkit status

[Ashark]

Hello.

I have seen a bug that kdewebkit is failing to build (406342). I was looking 
why the person was building that module in the first place.

Afaict, this module is not used in any project. Searching in repo-metadata by 
"kdewebkit" word, I see it is:

Listed in `dependency-data-kf5-qt5` and in `dependency-data-stable-kf5-qt5`, 
without any dependency, and no any other project points to it as a dependency.

Listed in `kf5-frameworks.ksb` to be ignored:
```
module-set frameworks
repository kde-projects
use-modules frameworks

#tag v5.75.0-rc1
branch kf5
ignore-modules kdewebkit kuserfeedback
end module-set
```

and also listed in `kf6-frameworks.ksb` as ignored:
```
module-set frameworks
repository kde-projects
use-modules frameworks
ignore-modules kdelibs4support kdewebkit khtml kjsembed kmediaplayer kinit 
kjs kross kdesignerplugin kemoticons kxmlrpcclient
cmake-options -DBUILD_WITH_QT6=ON
end module-set
```

The projects-invent/frameworks/kdewebkit/metadata.yaml contains the entry
```
repoactive: true
```

Maybe this should be marked as `repoactive: false` and removed from ignore-
modules?

The project readme says that it is removed from kf6.

Please start testing kde-builder if using kdesrc-build

[ashark]

Hello.Many of kde developers already heard of kde-builder - a replacement for kdescr-build. But if you did not - it is a reimplementation of kdesrc-build, rewritten in Python. The reason to rewrite was to make it easier to hack with/contribute to.If you are using kdesrc-build tool, please try out kde-builder: https://invent.kde.org/sdk/kde-builder The current state of the tool is that it is ready to use. But I want to ensure that every developer is satisfied with it. I.e., try to use it for every scenario you use kdesrc-build for. And please provide feedback: did you not noticed any differences or did you found some bug?In the end, the kdesrc-build would be archived. And when introducing big changes, such as for example, metadata format update, we would need to code in only one tool. The kdesrc-build would then become incompatible. This is why it is important to ensure that everybody are switched, and not staying with kdesrc-build because "it works for you currently". Please visit this forum post for discussion: https://discuss.kde.org/t/please-start-testing-kde-builder-if-using-kdesrc-build/13698Waiting for your feedback.

KDE Builder: request for review

[ashark]

Hi all!

I've been working on KDE Builder project. This is a reimplementation of kdesrc-build in Python. At this point, the tool is rather mature, but some minor bugs may probably be unnoticed. I'd like to officially request a review of KDE Builder for declaring it official tool, and deprecating the kdesrc-build. That way we can move forward with new tool.

You can reach me on Matrix at @ashark:kde.org for more instant communications.

Re: Should we consider project basenames unique?

[ashark]

> I have no idea why this is all of a sudden a problem for Arch Linux.In makepkg we do not have origin with project path (see comments in pkgbuild linked in https://invent.kde.org/sdk/releaseme/-/merge_requests/13). We have directory path to which the project was cloned, and it may (and man not) be named as project name. In pkgbuild I want to download and build translations for project, for that I use KDE_L10N_SYNC_TRANSLATIONS=ON. And then cmake module wants to call fetchpo.rb from releaseme. And as it was unable to detect project path (because origin is local path, not matching regex to extract it), it fallbacks to cmake project name: https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/9f519983d628c7c2a68ee1a8dc7a1cbb83c8f535/kde-modules/KDECMakeSettings.cmake#L321. And currently fetchpo.rb fails to determine the project by that. I wanted to get rid of that function, and use directly cmake project name https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/199#note_339860. Then modification of releaseme is required (that I created mr 13 for). Can we use cmake_project_name as project identifiers? If yes, then I see it is no problem to add a from_identifier() to releaseme::project. And then the problem will be solved.24.11.2021, 13:02, "Ben Cooksley" :On Wed, Nov 24, 2021 at 10:28 PM Harald Sitter  wrote:On Wed, Nov 24, 2021 at 10:02 AM Ben Cooksley  wrote:
> Which means you either provide the path (plasma-mobile/plasma-dialer) or you need to go look in the metadata anyway.

If names are unique (not persistent, just unique) and plasma-dialer is
what I want to release then I know plasma-dialer is called
plasma-dialer because I'm a plasma-dialer dev. I can then call
releasme with the argument  'plasma-dialer' and releaseme can work out
the path from that because the name is global unique so there is only
one plasma-dialer and that will be what I want to release.In the specific case of releaseme for 99% of projects the situation you've described is true, so what you are talking about is a non-issue.There are only a small handful of projects where identifier != repository name, and the developers in charge of those projects should be able to handle that and be aware of the difference - usually because they requested it.I have no idea why this is all of a sudden a problem for Arch Linux.

HSRegards,Ben