User Details
- User Since
- Dec 17 2014, 10:23 PM (482 w, 5 d)
- Roles
- Administrator
- Availability
- Available
Feb 8 2024
Space isn't too much of an issue on cdn.kde.org:
Filesystem Size Used Avail Use% Mounted on /dev/md1 1.9T 1.2T 631G 65% / none 492K 4.0K 488K 1% /dev /dev/mapper/vg0-archives 4.9T 1.6T 3.4T 32% /srv
We just have to ensure that they are expired in a reasonably efficient manner (and with some kind of sensible naming convention that is scalable). Discussing how to implement all of this is probably best done elsewhere though rather than here.
Jan 28 2024
Spam - account has been banned.
Dec 24 2023
This has now been provisioned.
Dec 19 2023
Ping?
Dec 16 2023
Problem solved going forward I guess, but what do we do about those who are already members?
Hmm, I thought Donorbox had functionality to record that - https://donorbox.org/nonprofit-blog/ask-donor-subscribe-mailing-list?
I've sent merge requests for all our sites that are either:
a) Static; or
b) Built using a Static Site Generator
Are we able to get a CSV of people and their email addresses out of Donorbox that have ticked a box to receive quarterly updates?
Oct 17 2023
Sorry it looks like you created a generic task not a Sysadmin task, so this went nowhere.
Oct 2 2023
Most virtual machine hosting providers don't provide any GPU compute capacity by default (in fact all 5 of our CI nodes just have a basic VGA adapter with no 3D capabilities at all) which I imagine won't make for a very good user experience with this demo.
Jul 22 2023
Jun 27 2023
Jun 26 2023
Jun 25 2023
We've usually kept the KDE e.V. out of governance matters, so not sure it is a good idea to require that a KDE e.V. member supports infrastructure proposals.
Having Sysadmin buy-in / approval definitely makes sense as something may look awesome but actually not be practical to deploy.
Jun 24 2023
Jun 15 2023
The maliciously built binary is why we wouldn't sign them - in that case all we have done is provide hosting for the binary, but no actual legitimacy.
Jun 14 2023
There are two different sets of expiry times we're referring to here i'm afraid:
- Being the job timeout (which is what you've referred to) - being the maximum amount of time the job is allowed to run for
- Being the artifact expiry time (which is what I was referring to) - being the maximum amount of time Gitlab will keep the artifacts of a given CI job around before it schedules them for deletion.
For the cache and artifact folders, you can use:
- KDECI_CC_CACHE=C:/Gitlab/Caches/krita-windows/
- KDECI_CACHE_PATH=C:/Gitlab/Artifacts/krita-windows/
Jun 9 2023
Lightweight would definitely be key here. Historically decisions have been made by discussion on our mailing lists.
May 29 2023
Now that I have figured it out, extending to stable will be straight forward.
We won't be supporting stable-kf6-qt6 until that is a thing, but kf6-qt6 can be supported.
I have been looking into this for the record.