Re: Should we consider project basenames unique?

2021-11-29 Thread Ben Cooksley
On Thu, Nov 25, 2021 at 1:20 AM  wrote:

> > 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 see. It sounds like the basename of the folder is not even guaranteed
based on the above statement, in which case it wouldn't even matter if the
repository names themselves were unique (instead of just our identifier for
them) as your distribution tooling would potentially discard them.

Given you are wanting to include translations, it sounds like the real fix
is something we discussed in a meeting at some point where scripty would
maintain a copy of the latest translations for a project in the actual
project repository.
I think that was being tested in one of our repositories but not sure on
the status of this.


> 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.
>
>
Cheers,
Ben


> 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.
>
>
> HS
>
>
> Regards,
> Ben
>
>


Re: Announcing General Availability of Gitlab CI for Linux, FreeBSD and Android

2021-11-29 Thread Ben Cooksley
On Mon, Nov 29, 2021 at 9:11 PM Ingo Klöcker  wrote:

> On Sonntag, 28. November 2021 23:07:50 CET Albert Astals Cid wrote:
> > El dissabte, 27 de novembre de 2021, a les 19:30:08 (CET), Ben Cooksley
> va
> escriure:
> > > As mentioned in the subject, i'm happy to announce the general
> > > availability
> > > of native Gitlab CI for all KDE projects for Linux, FreeBSD and
> Android.
>
> That's great news! Thanks, Ben and other admins!
>
> > Do we have any plan for "category pages" [1] like in Jenkins?
> > [1] i.e. something like
> >
> https://build.kde.org/job/Applications/view/Platform%20-%20WindowsMSVCQt5.15/
>
> At my old workplace I had set up
> https://github.com/heikkipora/gitlab-radiator
> The maintainer was quite responsive to my contributions.
>
> It talks to the GitLab API and uses caching to avoid hammering the GitLab
> server with requests if many people use it. It uses npm which may not be
> the
> best/most secure backend.
>
> I'm sure there are other Free Software GitLab monitors. GitLab seems to
> have
> something similar, but not in the Community Edition.
>

Ingo is correct that GitLab itself (at least in the Community Edition)
lacks this functionality.

I can confirm that this is on our radar and is something we do plan on
addressing.


> Regards,
> Ingo
>

Cheers,
Ben


Re: Announcing General Availability of Gitlab CI for Linux, FreeBSD and Android

2021-11-29 Thread Ingo Klöcker
On Sonntag, 28. November 2021 23:07:50 CET Albert Astals Cid wrote:
> El dissabte, 27 de novembre de 2021, a les 19:30:08 (CET), Ben Cooksley va 
escriure:
> > As mentioned in the subject, i'm happy to announce the general
> > availability
> > of native Gitlab CI for all KDE projects for Linux, FreeBSD and Android.

That's great news! Thanks, Ben and other admins!

> Do we have any plan for "category pages" [1] like in Jenkins?
> [1] i.e. something like
> https://build.kde.org/job/Applications/view/Platform%20-%20WindowsMSVCQt5.15/

At my old workplace I had set up
https://github.com/heikkipora/gitlab-radiator
The maintainer was quite responsive to my contributions.

It talks to the GitLab API and uses caching to avoid hammering the GitLab 
server with requests if many people use it. It uses npm which may not be the 
best/most secure backend.

I'm sure there are other Free Software GitLab monitors. GitLab seems to have 
something similar, but not in the Community Edition.

Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.