Gitlab update - CI future proofing required

[Ben Cooksley]

Hi all,

Over this weekend I completed a series of updates to invent.kde.org, moving
it to the latest supported version of Postgres (14) and Gitlab (16.6).

As part of that Gitlab update, additional security policies began to be
enforced by Gitlab which mean our existing method of including CI templates
is now beginning to be problematic.

To correct this, we need to port our .gitlab-ci.yml files over to the
include:project syntax (see
https://docs.gitlab.com/ee/ci/yaml/#includeproject)

As an example, this might look like for a Qt 6 only project with Linux,
FreeBSD and Windows builds:

include:
  - project: sysadmin/ci-utilities
file:
  - /gitlab-templates/linux-qt6.yml
  - /gitlab-templates/freebsd-qt6.yml
  - /gitlab-templates/windows-qt6.yml

While we've been able to permit the existing syntax to work for now, it is
recommended that projects please look into porting their CI configurations
now to avoid future issues.

Thanks,
Ben

Gitlab update - CI future proofing required

[Ben Cooksley]

Hi all,

Over this weekend I completed a series of updates to invent.kde.org, moving
it to the latest supported version of Postgres (14) and Gitlab (16.6).

As part of that Gitlab update, additional security policies began to be
enforced by Gitlab which mean our existing method of including CI templates
is now beginning to be problematic.

To correct this, we need to port our .gitlab-ci.yml files over to the
include:project syntax (see
https://docs.gitlab.com/ee/ci/yaml/#includeproject)

As an example, this might look like for a Qt 6 only project with Linux,
FreeBSD and Windows builds:

include:
  - project: sysadmin/ci-utilities
file:
  - /gitlab-templates/linux-qt6.yml
  - /gitlab-templates/freebsd-qt6.yml
  - /gitlab-templates/windows-qt6.yml

While we've been able to permit the existing syntax to work for now, it is
recommended that projects please look into porting their CI configurations
now to avoid future issues.

Thanks,
Ben

Gitlab update - CI future proofing required

[Ben Cooksley]

Hi all,

Over this weekend I completed a series of updates to invent.kde.org, moving
it to the latest supported version of Postgres (14) and Gitlab (16.6).

As part of that Gitlab update, additional security policies began to be
enforced by Gitlab which mean our existing method of including CI templates
is now beginning to be problematic.

To correct this, we need to port our .gitlab-ci.yml files over to the
include:project syntax (see
https://docs.gitlab.com/ee/ci/yaml/#includeproject)

As an example, this might look like for a Qt 6 only project with Linux,
FreeBSD and Windows builds:

include:
  - project: sysadmin/ci-utilities
file:
  - /gitlab-templates/linux-qt6.yml
  - /gitlab-templates/freebsd-qt6.yml
  - /gitlab-templates/windows-qt6.yml

While we've been able to permit the existing syntax to work for now, it is
recommended that projects please look into porting their CI configurations
now to avoid future issues.

Thanks,
Ben

Gitlab update - 16.2

[Ben Cooksley]

Good morning KDE Developers,

Just to let you know, in the last couple of hours i've updated out Gitlab
instance to the latest version - Gitlab 16.2

Details of the new features can be found at
https://about.gitlab.com/releases/2023/07/22/gitlab-16-2-released/

Things you will find most notable are:
1) The new rich text editor experience
2) Keyboard shortcuts within the Gitlab UI
3) Improvements to the MR suggestions when reviewing

Please let us know if there are any issues.

Cheers,
Ben

Re: Gitlab update, 2FA now mandatory

[Kevin Kofler]

Kevin Kofler wrote:
> What am I expected to use with my PinePhone? Does
> https://apps.kde.org/keysmith/ work?

To answer my own question: Yes, Keysmith works, both on the desktop (and 
notebook) and on the PinePhone. It is also easily possible to synchronize 
the keyring between different devices using Keysmith just by copying 
~/.config/org.kde.keysmith/Keysmith.conf to the other device over SFTP. Then 
any of the devices can be used to generate the TOTP. (They will generate the 
exact same one-time passwords, I can see it by running both instances in 
parallel.)

GNOME Secrets (formerly known as Password Safe) also works on the PinePhone 
(which is useful because that app can also store the permanent password, and 
is mobile-friendly unlike KWalletManager, though I presume it will also work 
fine on desktops/notebooks). If I enter the same secret there, it also 
generates the exact same one-time passwords.

Kevin Kofler

Re: GItlab update

[Eugen Mohr]

Hi Ben

Since the update “Project information” -> “activity” doesn’t show
“Issues” anymore. The tab “Issues events” doesn’t show issues neither.

Example: https://invent.kde.org/multimedia/kdenlive/activity vs.
https://invent.kde.org/multimedia/kdenlive/-/issues.

Eugen

Am 08.01.2023 um 11:03 schrieb Ben Cooksley:

Hi all,

This evening I updated our Gitlab instance at invent.kde.org
 to the latest version - 15.7.1.
The release notes for this can be found at
https://about.gitlab.com/releases/2022/12/22/gitlab-15-7-released/

Of particular note for folks are the following:
- Gitlab CLI Tool: https://docs.gitlab.com/ee/integration/glab/
- Using a SSH key to sign your commits:
https://docs.gitlab.com/ee/user/project/repository/ssh_signed_commits/
- New Web IDE: https://docs.gitlab.com/ee/user/project/web_ide_beta/
(based on VS Code)

Please note that the new VS Code based Web IDE is currently in beta,
if you experience issues with it you can disable it in your
preferences: https://invent.kde.org/-/profile/preferences

Should there be any issues, please let us know.

Thanks,
Ben

Re: GItlab update

[Ben Cooksley]

On Mon, Jan 9, 2023 at 1:05 AM Thomas Baumgart  wrote:

> On Sonntag, 8. Januar 2023 11:03:09 CET Ben Cooksley wrote:
>
> > Hi all,
> >
> > This evening I updated our Gitlab instance at invent.kde.org to the
> latest
> > version - 15.7.1.
> > The release notes for this can be found at
> > https://about.gitlab.com/releases/2022/12/22/gitlab-15-7-released/
> >
> > Of particular note for folks are the following:
> > - Gitlab CLI Tool: https://docs.gitlab.com/ee/integration/glab/
> > - Using a SSH key to sign your commits:
> > https://docs.gitlab.com/ee/user/project/repository/ssh_signed_commits/
> > - New Web IDE: https://docs.gitlab.com/ee/user/project/web_ide_beta/
> (based
> > on VS Code)
> >
> > Please note that the new VS Code based Web IDE is currently in beta, if
> you
> > experience issues with it you can disable it in your preferences:
> > https://invent.kde.org/-/profile/preferences
> >
> > Should there be any issues, please let us know.
>
> As suggested by tsdgeos, not sure if it's related to/caused by the update
> though:
>
>  11:37:28  bcooksley[m]: hi. any chance that CI pipelines are no
> longer triggered after the gitlab update?
>  11:38:20  though push does not yet show up on
> https://invent.kde.org/dashboard/activity, so perhaps some processing
> still happening?
>  11:39:34  https://invent.kde.org/sdk/kdesvn/-/commits/master
> shows the commits (4 min old), but
> https://invent.kde.org/sdk/kdesvn/activity also does not yet show the push
>  12:32:24  we also seem to be hitting some gitlab problem in
> https://invent.kde.org/network/neochat/-/merge_requests/752
>  12:33:14  This looks similar to
> https://invent.kde.org/office/kmymoney/-/merge_requests/191
>  12:34:33  I also noticed, that windows jobs take a long time to
> setup and then fail. Now it doesn't even start after re-launch
>  12:42:05  Kind of late for bcooksley[m] so i'd say answer his
> email to the community mailing list?
>

This has now been corrected, apologies for the disruption.

For those curious, Gitlab accomplishes the large part of it's processing
using a background worker, Sidekiq.
This background worker has a supervisor process, sidekiq-cluster, which
launched successfully but was unable to spawn it's worker processes due to
an issue with Bundler.

That has been fixed now and it has caught up on all the missed processing.

CI has approximately 200 jobs to work through at this time, which the nodes
are busy working on at this very moment.

Thanks,
Ben


>
> --
>
> Regards
>
> Thomas Baumgart
>
> -
> An optimist laughs to forget.
> A pessimist forgets to laugh.
> -
>

Re: GItlab update

[Ben Cooksley]

On Mon, Jan 9, 2023 at 1:05 AM Thomas Baumgart  wrote:

> On Sonntag, 8. Januar 2023 11:03:09 CET Ben Cooksley wrote:
>
> > Hi all,
> >
> > This evening I updated our Gitlab instance at invent.kde.org to the
> latest
> > version - 15.7.1.
> > The release notes for this can be found at
> > https://about.gitlab.com/releases/2022/12/22/gitlab-15-7-released/
> >
> > Of particular note for folks are the following:
> > - Gitlab CLI Tool: https://docs.gitlab.com/ee/integration/glab/
> > - Using a SSH key to sign your commits:
> > https://docs.gitlab.com/ee/user/project/repository/ssh_signed_commits/
> > - New Web IDE: https://docs.gitlab.com/ee/user/project/web_ide_beta/
> (based
> > on VS Code)
> >
> > Please note that the new VS Code based Web IDE is currently in beta, if
> you
> > experience issues with it you can disable it in your preferences:
> > https://invent.kde.org/-/profile/preferences
> >
> > Should there be any issues, please let us know.
>
> As suggested by tsdgeos, not sure if it's related to/caused by the update
> though:
>
>  11:37:28  bcooksley[m]: hi. any chance that CI pipelines are no
> longer triggered after the gitlab update?
>  11:38:20  though push does not yet show up on
> https://invent.kde.org/dashboard/activity, so perhaps some processing
> still happening?
>  11:39:34  https://invent.kde.org/sdk/kdesvn/-/commits/master
> shows the commits (4 min old), but
> https://invent.kde.org/sdk/kdesvn/activity also does not yet show the push
>  12:32:24  we also seem to be hitting some gitlab problem in
> https://invent.kde.org/network/neochat/-/merge_requests/752
>  12:33:14  This looks similar to
> https://invent.kde.org/office/kmymoney/-/merge_requests/191
>  12:34:33  I also noticed, that windows jobs take a long time to
> setup and then fail. Now it doesn't even start after re-launch
>  12:42:05  Kind of late for bcooksley[m] so i'd say answer his
> email to the community mailing list?
>

This has now been corrected, apologies for the disruption.

For those curious, Gitlab accomplishes the large part of it's processing
using a background worker, Sidekiq.
This background worker has a supervisor process, sidekiq-cluster, which
launched successfully but was unable to spawn it's worker processes due to
an issue with Bundler.

That has been fixed now and it has caught up on all the missed processing.

CI has approximately 200 jobs to work through at this time, which the nodes
are busy working on at this very moment.

Thanks,
Ben


>
> --
>
> Regards
>
> Thomas Baumgart
>
> -
> An optimist laughs to forget.
> A pessimist forgets to laugh.
> -
>

Re: GItlab update

[Eugen Mohr]

Hi Ben

Since the update “Project information” -> “activity” doesn’t show
“Issues” anymore. The tab “Issues events” doesn’t show issues neither.

Example: https://invent.kde.org/multimedia/kdenlive/activity vs.
https://invent.kde.org/multimedia/kdenlive/-/issues.

Eugen

Am 08.01.2023 um 11:03 schrieb Ben Cooksley:

Hi all,

This evening I updated our Gitlab instance at invent.kde.org
 to the latest version - 15.7.1.
The release notes for this can be found at
https://about.gitlab.com/releases/2022/12/22/gitlab-15-7-released/

Of particular note for folks are the following:
- Gitlab CLI Tool: https://docs.gitlab.com/ee/integration/glab/
- Using a SSH key to sign your commits:
https://docs.gitlab.com/ee/user/project/repository/ssh_signed_commits/
- New Web IDE: https://docs.gitlab.com/ee/user/project/web_ide_beta/
(based on VS Code)

Please note that the new VS Code based Web IDE is currently in beta,
if you experience issues with it you can disable it in your
preferences: https://invent.kde.org/-/profile/preferences

Should there be any issues, please let us know.

Thanks,
Ben

Re: GItlab update

[Thomas Baumgart]

On Sonntag, 8. Januar 2023 11:03:09 CET Ben Cooksley wrote:

> Hi all,
> 
> This evening I updated our Gitlab instance at invent.kde.org to the latest
> version - 15.7.1.
> The release notes for this can be found at
> https://about.gitlab.com/releases/2022/12/22/gitlab-15-7-released/
> 
> Of particular note for folks are the following:
> - Gitlab CLI Tool: https://docs.gitlab.com/ee/integration/glab/
> - Using a SSH key to sign your commits:
> https://docs.gitlab.com/ee/user/project/repository/ssh_signed_commits/
> - New Web IDE: https://docs.gitlab.com/ee/user/project/web_ide_beta/ (based
> on VS Code)
> 
> Please note that the new VS Code based Web IDE is currently in beta, if you
> experience issues with it you can disable it in your preferences:
> https://invent.kde.org/-/profile/preferences
> 
> Should there be any issues, please let us know.

As suggested by tsdgeos, not sure if it's related to/caused by the update 
though:

 11:37:28  bcooksley[m]: hi. any chance that CI pipelines are no 
longer triggered after the gitlab update?
 11:38:20  though push does not yet show up on 
https://invent.kde.org/dashboard/activity, so perhaps some processing still 
happening?
 11:39:34  https://invent.kde.org/sdk/kdesvn/-/commits/master shows 
the commits (4 min old), but https://invent.kde.org/sdk/kdesvn/activity also 
does not yet show the push
 12:32:24  we also seem to be hitting some gitlab problem in 
https://invent.kde.org/network/neochat/-/merge_requests/752
 12:33:14  This looks similar to 
https://invent.kde.org/office/kmymoney/-/merge_requests/191
 12:34:33  I also noticed, that windows jobs take a long time to 
setup and then fail. Now it doesn't even start after re-launch
 12:42:05  Kind of late for bcooksley[m] so i'd say answer his email 
to the community mailing list?

-- 

Regards

Thomas Baumgart

-
An optimist laughs to forget.
A pessimist forgets to laugh.
-


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

Re: GItlab update

[Thomas Baumgart]

On Sonntag, 8. Januar 2023 11:03:09 CET Ben Cooksley wrote:

> Hi all,
> 
> This evening I updated our Gitlab instance at invent.kde.org to the latest
> version - 15.7.1.
> The release notes for this can be found at
> https://about.gitlab.com/releases/2022/12/22/gitlab-15-7-released/
> 
> Of particular note for folks are the following:
> - Gitlab CLI Tool: https://docs.gitlab.com/ee/integration/glab/
> - Using a SSH key to sign your commits:
> https://docs.gitlab.com/ee/user/project/repository/ssh_signed_commits/
> - New Web IDE: https://docs.gitlab.com/ee/user/project/web_ide_beta/ (based
> on VS Code)
> 
> Please note that the new VS Code based Web IDE is currently in beta, if you
> experience issues with it you can disable it in your preferences:
> https://invent.kde.org/-/profile/preferences
> 
> Should there be any issues, please let us know.

As suggested by tsdgeos, not sure if it's related to/caused by the update 
though:

 11:37:28  bcooksley[m]: hi. any chance that CI pipelines are no 
longer triggered after the gitlab update?
 11:38:20  though push does not yet show up on 
https://invent.kde.org/dashboard/activity, so perhaps some processing still 
happening?
 11:39:34  https://invent.kde.org/sdk/kdesvn/-/commits/master shows 
the commits (4 min old), but https://invent.kde.org/sdk/kdesvn/activity also 
does not yet show the push
 12:32:24  we also seem to be hitting some gitlab problem in 
https://invent.kde.org/network/neochat/-/merge_requests/752
 12:33:14  This looks similar to 
https://invent.kde.org/office/kmymoney/-/merge_requests/191
 12:34:33  I also noticed, that windows jobs take a long time to 
setup and then fail. Now it doesn't even start after re-launch
 12:42:05  Kind of late for bcooksley[m] so i'd say answer his email 
to the community mailing list?

-- 

Regards

Thomas Baumgart

-
An optimist laughs to forget.
A pessimist forgets to laugh.
-


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

GItlab update

[Ben Cooksley]

Hi all,

This evening I updated our Gitlab instance at invent.kde.org to the latest
version - 15.7.1.
The release notes for this can be found at
https://about.gitlab.com/releases/2022/12/22/gitlab-15-7-released/

Of particular note for folks are the following:
- Gitlab CLI Tool: https://docs.gitlab.com/ee/integration/glab/
- Using a SSH key to sign your commits:
https://docs.gitlab.com/ee/user/project/repository/ssh_signed_commits/
- New Web IDE: https://docs.gitlab.com/ee/user/project/web_ide_beta/ (based
on VS Code)

Please note that the new VS Code based Web IDE is currently in beta, if you
experience issues with it you can disable it in your preferences:
https://invent.kde.org/-/profile/preferences

Should there be any issues, please let us know.

Thanks,
Ben

GItlab update

[Ben Cooksley]

Hi all,

This evening I updated our Gitlab instance at invent.kde.org to the latest
version - 15.7.1.
The release notes for this can be found at
https://about.gitlab.com/releases/2022/12/22/gitlab-15-7-released/

Of particular note for folks are the following:
- Gitlab CLI Tool: https://docs.gitlab.com/ee/integration/glab/
- Using a SSH key to sign your commits:
https://docs.gitlab.com/ee/user/project/repository/ssh_signed_commits/
- New Web IDE: https://docs.gitlab.com/ee/user/project/web_ide_beta/ (based
on VS Code)

Please note that the new VS Code based Web IDE is currently in beta, if you
experience issues with it you can disable it in your preferences:
https://invent.kde.org/-/profile/preferences

Should there be any issues, please let us know.

Thanks,
Ben

Re: Gitlab update, 2FA now mandatory

[Kevin Kofler]

Kevin Kofler wrote:
> What am I expected to use with my PinePhone? Does
> https://apps.kde.org/keysmith/ work?

To answer my own question: Yes, Keysmith works, both on the desktop 
(and notebook) and on the PinePhone. It is also easily possible to 
synchronize the keyring between different devices using Keysmith just by 
copying ~/.config/org.kde.keysmith/Keysmith.conf to the other device over 
SFTP. Then any of the devices can be used to generate the TOTP. (They will 
generate the exact same one-time passwords, I can see it by running both 
instances in parallel.)

GNOME Secrets (formerly known as Password Safe) also works on the 
PinePhone (which is useful because that app can also store the permanent 
password, and is mobile-friendly unlike KWalletManager, though I presume it 
will also work fine on desktops/notebooks). If I enter the same secret 
there, it also generates the exact same one-time passwords.

Kevin Kofler

Re: Gitlab update, 2FA now mandatory

[Raghavendra Kamath]

On Sunday, 23 October, 2022 12:02:23 PM IST Ben Cooksley wrote:
> I
> have also enabled Mandatory 2FA, which Gitlab will ask you to configure
> next time you access it.

Is the 2FA in KDE identity website same as this. The KDE identity shows a grid 
based system where you combine the grid and your password for 2FA. 

I have also already enabled 2FA for KDE identity with totp, does this 
supersede it?


-- 
Raghavendra Kamath
emblik.studio

Re: Gitlab update, 2FA now mandatory

[Kevin Kofler]

Ingo Klöcker wrote:
> You are the only person in this thread (on kde-core-devel) who has voiced
> their disagreement with using 2FA and who demand its immediate
> deactivation. Why do you think a single person (you) who isn't tasked with
> keeping our infrastructure and the data stored thereon secure should be
> able to decide this?

To be honest, I am genuinely surprised that there are not more complaints 
about that. I would have expected lots more. (On kde-community, there are a 
few posts by Christoph Cullmann worrying about the impact on new 
contributors, but even he does not seem to be opposed to 2FA for KDE 
developers. Other than that, I do not see any kind of criticism either.)

Unfortunately, it seems that people have learned to put up with pretty much 
any annoyance in the name of "security". (I blame airport "security".)

> I for one applaud the requirement to use 2FA on invent. I would love to
> see this on more websites.

That just confirms that this is NOT actually an "industry standard best 
practice" as Ben Cooksley is claiming, but a completely non-standard PITA 
that only a handful websites dare imposing on their users. (Invent is the 
ONLY website that I use that requires this. Note that I do not use online 
banking, and the ever-increasing security theater banks are imposing is the 
main reason why. There is a reason mandatory 2FA has not caught on outside 
of the banking sector.)

A lot of websites allow users to opt into 2FA (letting the security nerds 
have their toy to play around with without bothering the rest of the world), 
but forcing it down our throat is a wholely different matter.

> And, for what it's worth, since invent keeps personal information and
> since the GDPR requires using state-of-the-art technology to protect
> personal information, using 2FA is, in my opinion (but I'm not a lawyer),
> a must for any website that stores personal information.

See above, almost nobody else does this, so that interpretation of the GDPR 
is pure nonsense.

Kevin Kofler

Re: Gitlab update, 2FA now mandatory

[Ben Cooksley]

On Mon, Oct 24, 2022 at 11:56 PM Raghavendra Kamath 
wrote:

> On Sunday, 23 October, 2022 12:02:23 PM IST Ben Cooksley wrote:
> > I
> > have also enabled Mandatory 2FA, which Gitlab will ask you to configure
> > next time you access it.
>
> Is the 2FA in KDE identity website same as this. The KDE identity shows a
> grid
> based system where you combine the grid and your password for 2FA.
>
> I have also already enabled 2FA for KDE identity with totp, does this
> supersede it?
>

Gitlab will be replacing KDE Identity for authentication, so this 2FA setup
supersedes that yes.

Cheers,
Ben


>
>
> --
> Raghavendra Kamath
> emblik.studio
>
>
>

Re: Gitlab update, 2FA now mandatory

[Ben Cooksley]

On Mon, Oct 24, 2022 at 11:56 PM Raghavendra Kamath 
wrote:

> On Sunday, 23 October, 2022 12:02:23 PM IST Ben Cooksley wrote:
> > I
> > have also enabled Mandatory 2FA, which Gitlab will ask you to configure
> > next time you access it.
>
> Is the 2FA in KDE identity website same as this. The KDE identity shows a
> grid
> based system where you combine the grid and your password for 2FA.
>
> I have also already enabled 2FA for KDE identity with totp, does this
> supersede it?
>

Gitlab will be replacing KDE Identity for authentication, so this 2FA setup
supersedes that yes.

Cheers,
Ben


>
>
> --
> Raghavendra Kamath
> emblik.studio
>
>
>

Re: Gitlab update, 2FA now mandatory

[Raghavendra Kamath]

On Sunday, 23 October, 2022 12:02:23 PM IST Ben Cooksley wrote:
> I
> have also enabled Mandatory 2FA, which Gitlab will ask you to configure
> next time you access it.

Is the 2FA in KDE identity website same as this. The KDE identity shows a grid 
based system where you combine the grid and your password for 2FA. 

I have also already enabled 2FA for KDE identity with totp, does this 
supersede it?


-- 
Raghavendra Kamath
emblik.studio

Re: Gitlab update, 2FA now mandatory

[Ingo Klöcker]

On Montag, 24. Oktober 2022 01:37:23 CEST Kevin Kofler wrote:
> In short, the 2FA requirement is unacceptable and needs to be disabled
> immediately.

You are the only person in this thread (on kde-core-devel) who has voiced 
their disagreement with using 2FA and who demand its immediate deactivation. 
Why do you think a single person (you) who isn't tasked with keeping our 
infrastructure and the data stored thereon secure should be able to decide 
this?

I for one applaud the requirement to use 2FA on invent. I would love to see 
this on more websites.

And, for what it's worth, since invent keeps personal information and since 
the GDPR requires using state-of-the-art technology to protect personal 
information, using 2FA is, in my opinion (but I'm not a lawyer), a must for 
any website that stores personal information.

Regards,
Ingo

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

Re: Gitlab update, 2FA now mandatory

[Ben Cooksley]

On Mon, Oct 24, 2022 at 12:37 PM Kevin Kofler 
wrote:

> Ben Cooksley wrote:
> > On Mon, Oct 24, 2022 at 3:36 AM Kevin Kofler 
> > wrote:
> >> IMHO, this is both an absolutely unacceptable barrier to entry and a
> >> constant annoyance each time one has to log in.
> >
> > You shouldn't have any issues with remaining logged in as long as your
> > browser remains open.
>
> I wrote "each time one has to log in", not "remaining logged in".
>
> I sure hope that I just have to jump through the 2FA hoops only once per
> log
> in and not several times. But that is still one time too many.
>
> And "as long as your browser remains open" is at most one day. I turn the
> computer off while I sleep. So if this change forces me to log in each
> time
> I restart the browser, and hence at least each time I restart the computer
> (which is currently *not* the case, I can remain logged in for days
> throughout hundreds of browser sessions), that would mean going through
> the
> 2FA procedure at least every day.
>

The 2FA prompt (for normal users) is only applied on login yes.
Note that I can't examine your experience exactly as admins get prompted to
reauthenticate more frequently, especially when undertaking sensitive
actions.

See https://gitlab.com/gitlab-org/gitlab/-/issues/16656 for more
surrounding 2FA on each login.

With respect to logins being remembered, I have just performed a test using
a vanilla version of Firefox as shipped by OpenSUSE.
Logging into invent.kde.org (with the "Remember me" box ticked), completing
2FA authentication, performing a few actions and then closing the browser
followed by reopening it a few moments later led to the result I expected -
that I was still logged into Gitlab.


> > I did not supply a list of applications that people should be using as
> > there is a diverse range of devices and appstore ecosystems in use by
> > different people, and I don't have access to hardware such as a PinePhone
> > to validate any of that.
>
> So you are single-handedly forcing a new requirement on everyone, but are
> not willing to help us in any way with it, even just by telling us how to
> fulfill it. That is very unhelpful.
>

I could have provided links to a few applications.
They wouldn't have suited everyone though, so I opted not to do so on the
basis that there are dozens of apps that support handling TOTP.


>
> And you conveniently evaded my main questions:
> * why such a change can be decided by one person suddenly on a Sunday
> morning, with no warning (well, the software "gracefully" gives us 2 days
> to
> comply… only two days!), let alone (transparent) discussion.
>

As mentioned in my initial email - securing us against suspicious activity
that has been detected.
This is also why there was no discussion in advance.

One of the responsibilities that Sysadmin is charged with is ensuring our
data is protected and kept safe.
That is exactly what I am doing - using industry standard best practices.


> * what the point of two-factor is at all considering that you have no way
> to
> prevent the developer from storing the password and the OTP generator on
> the
> same device.
>

** Caution - a strawman argument has been detected **

The point of 2FA is to prevent stolen credentials from being misused by an
attacker.
If your device is compromised, 2FA isn't going to stop anything because
they can just wait (or otherwise prompt) for you to login to the site and
steal your session to do whatever it is they want to do.


>
> In short, the 2FA requirement is unacceptable and needs to be disabled
> immediately.
>

On that we disagree fundamentally.

Regards,
Ben


>
> Kevin Kofler
>
> PS/OT:
>
> > For most people the set of addresses they will be logging in from won't
> > change much (given that the vast majority of people use always-on
> internet
> > connections now, which means IP addresses - even if theoretically dynamic
> > - are in practice fairly static).
>
> "fairly static" does not mean it never changes, as in my case. But we need
> not discuss this tangent any further. The mandatory 2FA nonsense is the
> real
> issue, let us please focus on that.
>

Re: Gitlab update, 2FA now mandatory

[argonel]

On Sun, Oct 23, 2022 at 7:37 PM Kevin Kofler  wrote:

> * what the point of two-factor is at all considering that you have no way to
> prevent the developer from storing the password and the OTP generator on the
> same device.

The point is to add an authentication factor that isn't of any value
if it is accidentally shared, phished, or intercepted. The window of
opportunity for the reuse of a TOTP code is typically only 30 seconds,
and it's rather time intensive to derive the secret key from previous
codes for the account. You only need to see the secret key during
initial setup, so future logins aren't vulnerable to shoulder surfing.
Reuse of the secret key is unlikely, because services typically only
use the ones they generate.

Having more than one device able to authenticate is mostly a matter of
convenience, especially in the event of a hardware failure. Someone
having access to your single device sufficient to capture the password
and the secret key for the account is - hopefully - unlikely.

Re: Gitlab update, 2FA now mandatory

[Kevin Kofler]

Ben Cooksley wrote:
> On Mon, Oct 24, 2022 at 3:36 AM Kevin Kofler 
> wrote:
>> IMHO, this is both an absolutely unacceptable barrier to entry and a
>> constant annoyance each time one has to log in.
> 
> You shouldn't have any issues with remaining logged in as long as your
> browser remains open.

I wrote "each time one has to log in", not "remaining logged in".

I sure hope that I just have to jump through the 2FA hoops only once per log 
in and not several times. But that is still one time too many.

And "as long as your browser remains open" is at most one day. I turn the 
computer off while I sleep. So if this change forces me to log in each time 
I restart the browser, and hence at least each time I restart the computer 
(which is currently *not* the case, I can remain logged in for days 
throughout hundreds of browser sessions), that would mean going through the 
2FA procedure at least every day.

> I did not supply a list of applications that people should be using as
> there is a diverse range of devices and appstore ecosystems in use by
> different people, and I don't have access to hardware such as a PinePhone
> to validate any of that.

So you are single-handedly forcing a new requirement on everyone, but are 
not willing to help us in any way with it, even just by telling us how to 
fulfill it. That is very unhelpful.

And you conveniently evaded my main questions:
* why such a change can be decided by one person suddenly on a Sunday 
morning, with no warning (well, the software "gracefully" gives us 2 days to 
comply… only two days!), let alone (transparent) discussion.
* what the point of two-factor is at all considering that you have no way to 
prevent the developer from storing the password and the OTP generator on the 
same device.

In short, the 2FA requirement is unacceptable and needs to be disabled 
immediately.

Kevin Kofler

PS/OT:

> For most people the set of addresses they will be logging in from won't
> change much (given that the vast majority of people use always-on internet
> connections now, which means IP addresses - even if theoretically dynamic
> - are in practice fairly static).

"fairly static" does not mean it never changes, as in my case. But we need 
not discuss this tangent any further. The mandatory 2FA nonsense is the real 
issue, let us please focus on that.

Re: Gitlab update, 2FA now mandatory

[Ben Cooksley]

On Mon, Oct 24, 2022 at 3:36 AM Kevin Kofler  wrote:

> Hi,
>

Hi Kevin,


>
> Ben Cooksley wrote:
> > As part of securing Invent against recently detected suspicious activity
>
> What kind of suspicious activity would that be? Yesterday, Invent even
> considered it "suspicious" enough to send a warning e-mail that my semi-
> static IP address (TV-cable broadband ISP) has changed after several
> months.
> Dynamic IP addresses are not exactly unusual.
>

It was likely just flagging that you were logging in from a different IP
address to your usual address.
For most people the set of addresses they will be logging in from won't
change much (given that the vast majority of people use always-on internet
connections now, which means IP addresses - even if theoretically dynamic -
are in practice fairly static).

The suspicious activity is not related to static/dynamic IP addresses, and
as it is an ongoing matter i'd prefer not to comment until it is
satisfactorily resolved.


>
> > I have also enabled Mandatory 2FA, which Gitlab will ask you to configure
> > next time you access it.
>
> IMHO, this is both an absolutely unacceptable barrier to entry and a
> constant annoyance each time one has to log in.
>

You shouldn't have any issues with remaining logged in as long as your
browser remains open.

If this is not the behaviour you are seeing then please check the browser
addons/extensions you are using as these can often break functionality in
unexpected ways.
This is especially when they claim to offer benefits relating to privacy or
security (the EFF's HTTPS Everywhere extension several years back broke
links for some KDE sites by completely changing the subdomain)


>
> > This can be done using either a Webauthn token (such as a Yubikey) or
> TOTP
> > (using the app of choice on your phone)
>
> What am I expected to use with my PinePhone? Does
> https://apps.kde.org/keysmith/ work?
>

Please see the other responses to this thread.

I did not supply a list of applications that people should be using as
there is a diverse range of devices and appstore ecosystems in use by
different people, and I don't have access to hardware such as a PinePhone
to validate any of that.


>
> And how do you intend to prevent users from running the TOTP app on the
> same
> device as the web browser (both on the smartphone or even both on the
> desktop/notebook)? You just cannot. (As far as I know, even Yubikeys can
> be
> emulated in software.) Two-factor is a farce.


> Kevin Kofler
>

Regards,
Ben

Re: Gitlab update, 2FA now mandatory

[Kevin Kofler]

PS:

Kevin Kofler wrote:
> Ben Cooksley wrote:
>> I have also enabled Mandatory 2FA, which Gitlab will ask you to configure
>> next time you access it.
> 
> IMHO, this is both an absolutely unacceptable barrier to entry and a
> constant annoyance each time one has to log in.

Why is such a major policy change that affects all KDE developers taken 
overnight by a single person, with no discussion or vote of any kind?

Kevin Kofler

Re: Gitlab update, 2FA now mandatory

[Kevin Kofler]

Hi,

Ben Cooksley wrote:
> As part of securing Invent against recently detected suspicious activity 

What kind of suspicious activity would that be? Yesterday, Invent even 
considered it "suspicious" enough to send a warning e-mail that my semi-
static IP address (TV-cable broadband ISP) has changed after several months. 
Dynamic IP addresses are not exactly unusual.

> I have also enabled Mandatory 2FA, which Gitlab will ask you to configure
> next time you access it.

IMHO, this is both an absolutely unacceptable barrier to entry and a 
constant annoyance each time one has to log in.

> This can be done using either a Webauthn token (such as a Yubikey) or TOTP 
> (using the app of choice on your phone)

What am I expected to use with my PinePhone? Does 
https://apps.kde.org/keysmith/ work?

And how do you intend to prevent users from running the TOTP app on the same 
device as the web browser (both on the smartphone or even both on the 
desktop/notebook)? You just cannot. (As far as I know, even Yubikeys can be 
emulated in software.) Two-factor is a farce.

Kevin Kofler

Gitlab update, 2FA now mandatory

[Ben Cooksley]

Hi all,

This afternoon I updated invent.kde.org to the latest version of Gitlab,
15.5.
Release notes for this can be found at
https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/

There isn't much notable feature wise in this release, however there have
been some bug fixes surrounding the "Rebase without Pipeline"
functionality that was introduced in an earlier update.

As part of securing Invent against recently detected suspicious activity I
have also enabled Mandatory 2FA, which Gitlab will ask you to configure
next time you access it. This can be done using either a Webauthn token
(such as a Yubikey) or TOTP (using the app of choice on your phone)

Should you lose access to your 2FA device you can obtain a recovery token
to log back in via SSH, see
https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#generate-new-recovery-codes-using-ssh
for more details on this.

Please let us know if there are any queries on the above.

Thanks,
Ben

Gitlab update, 2FA now mandatory

[Ben Cooksley]

Hi all,

This afternoon I updated invent.kde.org to the latest version of Gitlab,
15.5.
Release notes for this can be found at
https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/

There isn't much notable feature wise in this release, however there have
been some bug fixes surrounding the "Rebase without Pipeline"
functionality that was introduced in an earlier update.

As part of securing Invent against recently detected suspicious activity I
have also enabled Mandatory 2FA, which Gitlab will ask you to configure
next time you access it. This can be done using either a Webauthn token
(such as a Yubikey) or TOTP (using the app of choice on your phone)

Should you lose access to your 2FA device you can obtain a recovery token
to log back in via SSH, see
https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#generate-new-recovery-codes-using-ssh
for more details on this.

Please let us know if there are any queries on the above.

Thanks,
Ben

Gitlab update

[Ben Cooksley]

Hi all,

This evening I updated invent.kde.org to the latest version of Gitlab
15.3.1.

The release notes didn't have too much interesting things for us aside from
one item that people may find of interest:
https://docs.gitlab.com/ee/user/project/merge_requests/methods/index.html#rebase-without-cicd-pipeline

The release notes are at
https://about.gitlab.com/releases/2022/08/22/gitlab-15-3-released/ for
those curious.

Please let us know if you see anything unusual with the operation of Gitlab.

Cheers,
Ben

Gitlab update

[Ben Cooksley]

Hi all,

This evening I completed updating our Gitlab instance to 15.1.1, which
brings some performance improvements and general bug fixes.

While everything appears to be operating normally, please let us know if
you find anything non-functional.

Please note that due to abuse we've had to disable the ability to import
projects, as unknown actors were using this to import a reverse-shell CI
job to let them use our CI workers for their own personal purposes. While
we have banned the responsible accounts, it seems they're more than happy
to register new accounts, which has required us to take additional measures
to counteract this abuse.

Unfortunately the host of the repositories they are importing (GitHub) has
failed to respond to our abuse reports concerning this - should anyone have
any inside contacts I can pass along the necessary details.

Thanks,
Ben

Re: Namespaces for a few repositories on invent (was Re: Migration to Gitlab -- Update)

[Ben Cooksley]

On Mon, May 11, 2020 at 1:40 AM Bhushan Shah  wrote:
>
> On Sun, May 10, 2020 at 02:54:35PM +0200, Luigi Toscano wrote:
> > I went through the list of the new structure, and I can only imagine the 
> > work
> > needed to reshuffle
> > Am I still on time to propose some fine tuning?
>
> Sure, feel free to make suggestions on final place of items on structure
>
> > == Proposed moves:
> > kio-upnp-ms: applications -> network
> > mark: applications -> education
> > kdecoration-viewer: applications -> sdk
> > kolorfill: applications -> games
> > klook: applications -> graphics
> > peruse: applications -> graphics
>
> done!
>
> > == A bit more open questions about:
> > libkdegameai: libraries -> games (like libkdegames)
>
> done!
>
> > macports-kde: sdk -> packaging (not 100% sure)
>
> this kinda looks unmaintained to me, last commit is in 2014/15, and
> otherwise seems untouched, should unmaintained be better place for this?
>
> > kup: system -> utilities (like kbackup!)
>
> Good that we have backup for backup applications , anyway
> would it make sense to move this otherway around? (kbackup -> system?) I
> kind of consider backup "system"/"core" stuff...
>
> > mangonel seems a bit of place too in system (which has mostly lower-level
> > configuration stuff), maybe utilities?
>
> done!
>
> >
> > == There are a few second-level namespaces, are we going to keep them? I 
> > can see:
>
> Thanks for noticing the second-level namespaces, I completely overlooked
> it seems
>
> > * graphics/digikam/
> >   - it only contains digikam-doc, which should maybe just go under graphics/
> > * graphics/libs
> >   - a few libraries which be moved under graphics/ directly (or libraries, 
> > but
> > they are graphics-related)
> > * network/telepathy
> >   - only telepathy-logger-qt, it could go under network/ directly
>
> I've flattened these ones.
>
> > * others/kde-edu-courses/
> >   - why not directly under education ?
>
> I guess it can go into education, but looking at content I am more
> inclined to think that this belongs into unmaintained, aren't those
> applications instead using the GHNS? I am not even sure where this
> content is hosted if at all (seems to have .php files in there)

I suspect we're going to find one of two things out here:

1) That these data files are currently not in use
2) They're source files for content currently on
files.kde.org/edu.kde.org (which has some Edu applications pulling new
content directly from it, using one of the pre-OCS variants of GHNS)

>
> > Also unmaintained/ contains two of them (necessitas, strigi), but it doesn't
> > matter much I guess.
>
> I've flattened necessitas and strigi.
>
> > Ciao!
> > --
> > Luigi

Cheers,
Ben

>
> --
> Bhushan Shah
> http://blog.bshah.in
> IRC Nick : bshah on Freenode
> GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D

Re: Namespaces for a few repositories on invent (was Re: Migration to Gitlab -- Update)

[Ben Cooksley]

On Mon, May 11, 2020 at 1:40 AM Bhushan Shah  wrote:
>
> On Sun, May 10, 2020 at 02:54:35PM +0200, Luigi Toscano wrote:
> > I went through the list of the new structure, and I can only imagine the 
> > work
> > needed to reshuffle
> > Am I still on time to propose some fine tuning?
>
> Sure, feel free to make suggestions on final place of items on structure
>
> > == Proposed moves:
> > kio-upnp-ms: applications -> network
> > mark: applications -> education
> > kdecoration-viewer: applications -> sdk
> > kolorfill: applications -> games
> > klook: applications -> graphics
> > peruse: applications -> graphics
>
> done!
>
> > == A bit more open questions about:
> > libkdegameai: libraries -> games (like libkdegames)
>
> done!
>
> > macports-kde: sdk -> packaging (not 100% sure)
>
> this kinda looks unmaintained to me, last commit is in 2014/15, and
> otherwise seems untouched, should unmaintained be better place for this?
>
> > kup: system -> utilities (like kbackup!)
>
> Good that we have backup for backup applications , anyway
> would it make sense to move this otherway around? (kbackup -> system?) I
> kind of consider backup "system"/"core" stuff...
>
> > mangonel seems a bit of place too in system (which has mostly lower-level
> > configuration stuff), maybe utilities?
>
> done!
>
> >
> > == There are a few second-level namespaces, are we going to keep them? I 
> > can see:
>
> Thanks for noticing the second-level namespaces, I completely overlooked
> it seems
>
> > * graphics/digikam/
> >   - it only contains digikam-doc, which should maybe just go under graphics/
> > * graphics/libs
> >   - a few libraries which be moved under graphics/ directly (or libraries, 
> > but
> > they are graphics-related)
> > * network/telepathy
> >   - only telepathy-logger-qt, it could go under network/ directly
>
> I've flattened these ones.
>
> > * others/kde-edu-courses/
> >   - why not directly under education ?
>
> I guess it can go into education, but looking at content I am more
> inclined to think that this belongs into unmaintained, aren't those
> applications instead using the GHNS? I am not even sure where this
> content is hosted if at all (seems to have .php files in there)

I suspect we're going to find one of two things out here:

1) That these data files are currently not in use
2) They're source files for content currently on
files.kde.org/edu.kde.org (which has some Edu applications pulling new
content directly from it, using one of the pre-OCS variants of GHNS)

>
> > Also unmaintained/ contains two of them (necessitas, strigi), but it doesn't
> > matter much I guess.
>
> I've flattened necessitas and strigi.
>
> > Ciao!
> > --
> > Luigi

Cheers,
Ben

>
> --
> Bhushan Shah
> http://blog.bshah.in
> IRC Nick : bshah on Freenode
> GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D

Re: Namespaces for a few repositories on invent (was Re: Migration to Gitlab -- Update)

[Bhushan Shah]

On Sun, May 10, 2020 at 02:54:35PM +0200, Luigi Toscano wrote:
> I went through the list of the new structure, and I can only imagine the work
> needed to reshuffle
> Am I still on time to propose some fine tuning?

Sure, feel free to make suggestions on final place of items on structure

> == Proposed moves:
> kio-upnp-ms: applications -> network
> mark: applications -> education
> kdecoration-viewer: applications -> sdk
> kolorfill: applications -> games
> klook: applications -> graphics
> peruse: applications -> graphics

done!

> == A bit more open questions about:
> libkdegameai: libraries -> games (like libkdegames)

done!

> macports-kde: sdk -> packaging (not 100% sure)

this kinda looks unmaintained to me, last commit is in 2014/15, and
otherwise seems untouched, should unmaintained be better place for this?

> kup: system -> utilities (like kbackup!)

Good that we have backup for backup applications , anyway
would it make sense to move this otherway around? (kbackup -> system?) I
kind of consider backup "system"/"core" stuff...

> mangonel seems a bit of place too in system (which has mostly lower-level
> configuration stuff), maybe utilities?

done!

> 
> == There are a few second-level namespaces, are we going to keep them? I can 
> see:

Thanks for noticing the second-level namespaces, I completely overlooked
it seems

> * graphics/digikam/
>   - it only contains digikam-doc, which should maybe just go under graphics/
> * graphics/libs
>   - a few libraries which be moved under graphics/ directly (or libraries, but
> they are graphics-related)
> * network/telepathy
>   - only telepathy-logger-qt, it could go under network/ directly

I've flattened these ones.

> * others/kde-edu-courses/
>   - why not directly under education ?

I guess it can go into education, but looking at content I am more
inclined to think that this belongs into unmaintained, aren't those
applications instead using the GHNS? I am not even sure where this
content is hosted if at all (seems to have .php files in there)

> Also unmaintained/ contains two of them (necessitas, strigi), but it doesn't
> matter much I guess.

I've flattened necessitas and strigi.

> Ciao!
> -- 
> Luigi

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Re: Migration to Gitlab -- Update

[Bhushan Shah]

Hello,

On Sun, May 10, 2020 at 01:20:23PM +0200, Johan Ouwerkerk wrote:
> On Sun, May 10, 2020 at 9:49 AM Ben Cooksley  wrote:
> >
> > Following lengthy discussion in the original thread, it was agreed
> > that the original sysadmin proposal of various categories would be
> > implemented, with repositories organised according to that structure.
> >
> > You can find this documented at
> > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> >
> > -- Conclusion --
> >
> > Should anyone have any questions regarding the above, please let us know!
> >
> 
> Just to confirm, by documented you mean that the layout of the various
> `metadata.yaml` files indicates what the layout of the repositories
> will become? Becuase looking at Keysmith for example, it seems that
> the metadata repopath has not been updated yet:
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent/utilities/keysmith/metadata.yaml?h=bshah/invent

Yes, that is correct, currently directory structure is what will be
final structure, repopath and other bits will migrated all at once when
actual move happens

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Re: Namespaces for a few repositories on invent (was Re: Migration to Gitlab -- Update)

[Bhushan Shah]

On Sun, May 10, 2020 at 02:54:35PM +0200, Luigi Toscano wrote:
> I went through the list of the new structure, and I can only imagine the work
> needed to reshuffle
> Am I still on time to propose some fine tuning?

Sure, feel free to make suggestions on final place of items on structure

> == Proposed moves:
> kio-upnp-ms: applications -> network
> mark: applications -> education
> kdecoration-viewer: applications -> sdk
> kolorfill: applications -> games
> klook: applications -> graphics
> peruse: applications -> graphics

done!

> == A bit more open questions about:
> libkdegameai: libraries -> games (like libkdegames)

done!

> macports-kde: sdk -> packaging (not 100% sure)

this kinda looks unmaintained to me, last commit is in 2014/15, and
otherwise seems untouched, should unmaintained be better place for this?

> kup: system -> utilities (like kbackup!)

Good that we have backup for backup applications , anyway
would it make sense to move this otherway around? (kbackup -> system?) I
kind of consider backup "system"/"core" stuff...

> mangonel seems a bit of place too in system (which has mostly lower-level
> configuration stuff), maybe utilities?

done!

> 
> == There are a few second-level namespaces, are we going to keep them? I can 
> see:

Thanks for noticing the second-level namespaces, I completely overlooked
it seems

> * graphics/digikam/
>   - it only contains digikam-doc, which should maybe just go under graphics/
> * graphics/libs
>   - a few libraries which be moved under graphics/ directly (or libraries, but
> they are graphics-related)
> * network/telepathy
>   - only telepathy-logger-qt, it could go under network/ directly

I've flattened these ones.

> * others/kde-edu-courses/
>   - why not directly under education ?

I guess it can go into education, but looking at content I am more
inclined to think that this belongs into unmaintained, aren't those
applications instead using the GHNS? I am not even sure where this
content is hosted if at all (seems to have .php files in there)

> Also unmaintained/ contains two of them (necessitas, strigi), but it doesn't
> matter much I guess.

I've flattened necessitas and strigi.

> Ciao!
> -- 
> Luigi

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Namespaces for a few repositories on invent (was Re: Migration to Gitlab -- Update)

[Luigi Toscano]

Ben Cooksley ha scritto:
> -- Structure --
> 
> Following lengthy discussion in the original thread, it was agreed
> that the original sysadmin proposal of various categories would be
> implemented, with repositories organised according to that structure.
> 
> You can find this documented at
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent

I went through the list of the new structure, and I can only imagine the work
needed to reshuffle
Am I still on time to propose some fine tuning?


== Proposed moves:
kio-upnp-ms: applications -> network
mark: applications -> education
kdecoration-viewer: applications -> sdk
kolorfill: applications -> games
klook: applications -> graphics
peruse: applications -> graphics

== A bit more open questions about:
libkdegameai: libraries -> games (like libkdegames)
macports-kde: sdk -> packaging (not 100% sure)
kup: system -> utilities (like kbackup!)
mangonel seems a bit of place too in system (which has mostly lower-level
configuration stuff), maybe utilities?


== There are a few second-level namespaces, are we going to keep them? I can 
see:

* graphics/digikam/
  - it only contains digikam-doc, which should maybe just go under graphics/
* graphics/libs
  - a few libraries which be moved under graphics/ directly (or libraries, but
they are graphics-related)
* network/telepathy
  - only telepathy-logger-qt, it could go under network/ directly
* others/kde-edu-courses/
  - why not directly under education ?

Also unmaintained/ contains two of them (necessitas, strigi), but it doesn't
matter much I guess.


Ciao!
-- 
Luigi

Namespaces for a few repositories on invent (was Re: Migration to Gitlab -- Update)

[Luigi Toscano]

Ben Cooksley ha scritto:
> -- Structure --
> 
> Following lengthy discussion in the original thread, it was agreed
> that the original sysadmin proposal of various categories would be
> implemented, with repositories organised according to that structure.
> 
> You can find this documented at
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent

I went through the list of the new structure, and I can only imagine the work
needed to reshuffle
Am I still on time to propose some fine tuning?


== Proposed moves:
kio-upnp-ms: applications -> network
mark: applications -> education
kdecoration-viewer: applications -> sdk
kolorfill: applications -> games
klook: applications -> graphics
peruse: applications -> graphics

== A bit more open questions about:
libkdegameai: libraries -> games (like libkdegames)
macports-kde: sdk -> packaging (not 100% sure)
kup: system -> utilities (like kbackup!)
mangonel seems a bit of place too in system (which has mostly lower-level
configuration stuff), maybe utilities?


== There are a few second-level namespaces, are we going to keep them? I can 
see:

* graphics/digikam/
  - it only contains digikam-doc, which should maybe just go under graphics/
* graphics/libs
  - a few libraries which be moved under graphics/ directly (or libraries, but
they are graphics-related)
* network/telepathy
  - only telepathy-logger-qt, it could go under network/ directly
* others/kde-edu-courses/
  - why not directly under education ?

Also unmaintained/ contains two of them (necessitas, strigi), but it doesn't
matter much I guess.


Ciao!
-- 
Luigi

Re: Migration to Gitlab -- Update

[Bhushan Shah]

Hello,

On Sun, May 10, 2020 at 01:20:23PM +0200, Johan Ouwerkerk wrote:
> On Sun, May 10, 2020 at 9:49 AM Ben Cooksley  wrote:
> >
> > Following lengthy discussion in the original thread, it was agreed
> > that the original sysadmin proposal of various categories would be
> > implemented, with repositories organised according to that structure.
> >
> > You can find this documented at
> > https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
> >
> > -- Conclusion --
> >
> > Should anyone have any questions regarding the above, please let us know!
> >
> 
> Just to confirm, by documented you mean that the layout of the various
> `metadata.yaml` files indicates what the layout of the repositories
> will become? Becuase looking at Keysmith for example, it seems that
> the metadata repopath has not been updated yet:
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent/utilities/keysmith/metadata.yaml?h=bshah/invent

Yes, that is correct, currently directory structure is what will be
final structure, repopath and other bits will migrated all at once when
actual move happens

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Re: Migration to Gitlab -- Update

[Johan Ouwerkerk]

On Sun, May 10, 2020 at 9:49 AM Ben Cooksley  wrote:
>
> Following lengthy discussion in the original thread, it was agreed
> that the original sysadmin proposal of various categories would be
> implemented, with repositories organised according to that structure.
>
> You can find this documented at
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
>
> -- Conclusion --
>
> Should anyone have any questions regarding the above, please let us know!
>

Just to confirm, by documented you mean that the layout of the various
`metadata.yaml` files indicates what the layout of the repositories
will become? Becuase looking at Keysmith for example, it seems that
the metadata repopath has not been updated yet:
https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent/utilities/keysmith/metadata.yaml?h=bshah/invent

Regards,

- Johan

Re: Migration to Gitlab -- Update

[Johan Ouwerkerk]

On Sun, May 10, 2020 at 9:49 AM Ben Cooksley  wrote:
>
> Following lengthy discussion in the original thread, it was agreed
> that the original sysadmin proposal of various categories would be
> implemented, with repositories organised according to that structure.
>
> You can find this documented at
> https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent
>
> -- Conclusion --
>
> Should anyone have any questions regarding the above, please let us know!
>

Just to confirm, by documented you mean that the layout of the various
`metadata.yaml` files indicates what the layout of the repositories
will become? Becuase looking at Keysmith for example, it seems that
the metadata repopath has not been updated yet:
https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent/utilities/keysmith/metadata.yaml?h=bshah/invent

Regards,

- Johan

Migration to Gitlab -- Update

[Ben Cooksley]

Good morning all,

We recently had a rather lengthy discussion concerning the final
manner in which Gitlab will be deployed for KDE.

To ensure everything is clear, we'd like to summarise that and present
the final structure which has been agreed upon, along with details on
tools that will be able to assist Developers with the migration and
working with Gitlab in the long term.

-- Timeline --

At the moment we are intending to perform a bulk migration of all
repositories from git.kde.org to invent.kde.org on 16 May 2020.

When this transition commences, git.kde.org will be made read-only.

Following this, the current system will be kept active in a read-only
configuration for two weeks (until 30 May 2020) to allow for everyone
to smoothly transition local clones and any automated systems over to
the new Gitlab setup.

-- Structure --

Following lengthy discussion in the original thread, it was agreed
that the original sysadmin proposal of various categories would be
implemented, with repositories organised according to that structure.

You can find this documented at
https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent

-- Tooling --

To assist developers with the transition process, Sysadmin has
developed a utility ('git kpull') which once setup on a developers
system will automatically migrate any git.kde.org/anongit.kde.org to
the new structure automatically, before proceeding with a regular 'git
pull' when run in a Git repository.

Additionally, as some developers had concerns regarding locating
repositories, an additional utility known as 'git kclone' is being
shipped as well. This will allow developers to run "git kclone
" to clone a repository.

In the majority (95%) of cases we expect "" to be
identical to the repository name (frameworks/kcoreaddons being
kcoreaddons for instance), however where the name is common (such as
'dialer') then it will be prefixed by the name of the originating
project (so maui/dialer would have an identifier of maui-dialer)
following the convention we use at the moment for projects wishing to
have a repository using a common name.

It should be noted that 'git kclone' is also able to perform bulk
clones based on wildcard patterns (which you could use to clone all
frameworks by running "git kclone frameworks/*" for example)

Instructions on how to set this up on your system will be sent out
closer to the migration commencing.

-- Continuous Integration --

Following the migration, we will continue to use our existing Jenkins
based setup. Migration to using Gitlab for CI purposes will take place
at a later date once the necessary adjustments to the CI
infrastructure have been completed.

During the intervening time CI capability will be available on Gitlab
for evaluation and testing purposes only.

This is not supported as a standard production level service by
Sysadmin and therefore should not be relied upon by projects as part
of their workflow.

-- Tasks --

Tasks will be migrated from Phabricator at a future point in time.
These will remain on Phabricator for the time being and are not
affected by the migration.

Projects wishing to start entirely new boards and not needing to work
with  existing boards on Phabricator should feel free to begin making
use of their new Gitlab boards following the migration.

-- Migration from Phabricator --

Existing code reviews will not be migrated from Phabricator as part of
this migration process and will need to be completed using the usual
process on Phabricator. It is expected that following the completion
of the migration of code hosting that no further new reviews will be
started on Phabricator.

Please note that because Phabricator is dependent on the existing
git.kde.org/anongit.kde.org setup, once those are shutdown the hooks
that automatically close reviews will no longer operate.

Tasks will be migrated in a future step, following which Phabricator
will be shutdown. Based on initial testing we expect to be able to
provide a static copy of Phabricator (for reviews only as tasks will
have been migrated at this stage) for long term archival purposes.

-- Conclusion --

Should anyone have any questions regarding the above, please let us know!

Thanks,
Ben Cooksley
KDE Sysadmin

Migration to Gitlab -- Update

[Ben Cooksley]

Good morning all,

We recently had a rather lengthy discussion concerning the final
manner in which Gitlab will be deployed for KDE.

To ensure everything is clear, we'd like to summarise that and present
the final structure which has been agreed upon, along with details on
tools that will be able to assist Developers with the migration and
working with Gitlab in the long term.

-- Timeline --

At the moment we are intending to perform a bulk migration of all
repositories from git.kde.org to invent.kde.org on 16 May 2020.

When this transition commences, git.kde.org will be made read-only.

Following this, the current system will be kept active in a read-only
configuration for two weeks (until 30 May 2020) to allow for everyone
to smoothly transition local clones and any automated systems over to
the new Gitlab setup.

-- Structure --

Following lengthy discussion in the original thread, it was agreed
that the original sysadmin proposal of various categories would be
implemented, with repositories organised according to that structure.

You can find this documented at
https://cgit.kde.org/sysadmin/repo-metadata.git/tree/projects-invent?h=bshah/invent

-- Tooling --

To assist developers with the transition process, Sysadmin has
developed a utility ('git kpull') which once setup on a developers
system will automatically migrate any git.kde.org/anongit.kde.org to
the new structure automatically, before proceeding with a regular 'git
pull' when run in a Git repository.

Additionally, as some developers had concerns regarding locating
repositories, an additional utility known as 'git kclone' is being
shipped as well. This will allow developers to run "git kclone
" to clone a repository.

In the majority (95%) of cases we expect "" to be
identical to the repository name (frameworks/kcoreaddons being
kcoreaddons for instance), however where the name is common (such as
'dialer') then it will be prefixed by the name of the originating
project (so maui/dialer would have an identifier of maui-dialer)
following the convention we use at the moment for projects wishing to
have a repository using a common name.

It should be noted that 'git kclone' is also able to perform bulk
clones based on wildcard patterns (which you could use to clone all
frameworks by running "git kclone frameworks/*" for example)

Instructions on how to set this up on your system will be sent out
closer to the migration commencing.

-- Continuous Integration --

Following the migration, we will continue to use our existing Jenkins
based setup. Migration to using Gitlab for CI purposes will take place
at a later date once the necessary adjustments to the CI
infrastructure have been completed.

During the intervening time CI capability will be available on Gitlab
for evaluation and testing purposes only.

This is not supported as a standard production level service by
Sysadmin and therefore should not be relied upon by projects as part
of their workflow.

-- Tasks --

Tasks will be migrated from Phabricator at a future point in time.
These will remain on Phabricator for the time being and are not
affected by the migration.

Projects wishing to start entirely new boards and not needing to work
with  existing boards on Phabricator should feel free to begin making
use of their new Gitlab boards following the migration.

-- Migration from Phabricator --

Existing code reviews will not be migrated from Phabricator as part of
this migration process and will need to be completed using the usual
process on Phabricator. It is expected that following the completion
of the migration of code hosting that no further new reviews will be
started on Phabricator.

Please note that because Phabricator is dependent on the existing
git.kde.org/anongit.kde.org setup, once those are shutdown the hooks
that automatically close reviews will no longer operate.

Tasks will be migrated in a future step, following which Phabricator
will be shutdown. Based on initial testing we expect to be able to
provide a static copy of Phabricator (for reviews only as tasks will
have been migrated at this stage) for long term archival purposes.

-- Conclusion --

Should anyone have any questions regarding the above, please let us know!

Thanks,
Ben Cooksley
KDE Sysadmin

Gitlab Update

[Ben Cooksley]

Hi all,

This afternoon we completed the move of Gitlab from it's initial
server (which was for the evaluation) to the production server that
will hopefully serve us well for many years to come. As part of this
we also upgraded it from Gitlab 12.3 to 12.5.

Should anyone notice any problems, please let us know.

As part of the move we also enabled support for Incoming Email on our
Gitlab instance.

This means that tasks and merge requests can now be created by sending
emails to certain addresses (which are available from the Gitlab web
interface), and discussions on Gitlab can now be replied to by email
as well.

See 
https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#create-new-merge-requests-by-email
and 
https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#new-issue-via-email
for more information on these features.

Please note that the addresses are specific to you and allow anyone
with them to perform actions as if they were you, so it is important
that they are not disclosed to anyone else.

Thanks,
Ben Cooksley
KDE Sysadmin