GitLab migration: Thursday, March 26, starting 23 CET

Hello, gitlab.gnome.org will be down during migration to the new data center starting today at 23 CET. Unfortunately due to the amount of data it is not feasible to migrate without downtime. As transferring the data will take about 6 hours, we estimate it will be operational again between 9 and

Re: GitLab migration: Thursday, March 26, starting 23 CET

On 26/03/2020 14.37, Michael Catanzaro wrote: > On Thu, Mar 26, 2020 at 10:59 am, Milan Crha via desktop-devel-list > wrote: >> I also moved to release on >> Friday, instead of Monday (weekend is out of question here), > > Tarballs are always due on Saturday. We don't have Monday deadlines >

Planned GitLab maintenance scheduled for Friday, 2022-08-26 at 6:00 UTC

Hello everyone, Be advised that a planned maintenance for GitLab is scheduled for tomorrow, Friday 2022-08-26 at 6:00 UTC. The outage may also cause intermittent issues with GitLab Pages. The total maintenance period should last less than 2 hours. As part of the PostgreSQL move to

Re: Planned GitLab maintenance scheduled for Friday, 2022-08-26 at 6:00 UTC

The maintenance is now concluded and GitLab is back online. If you notice anything usual, please reach out to Infrastructure Team via the usual contact channels. Thanks, Bart ___ desktop-devel-list mailing list desktop-devel-list@gnome.org

Matrix.org security breach

The team behind Matrix.org announced[1] yesterday that an attacker gained access to the production database, including users passwords used for NickServ authentication with bridged network like Freenode or irc.gnome.org. While Matrix bridge is still down, we recommend users who were using

Re: Changes to GitLab runners configuration

On 28/02/2020 15.17, Michael Catanzaro wrote: > Please revert the runner changes until you have time to fix this. Our CI > has been basically unusable all week and that blocks flatpak pushes. All issues with user namespaces on gcc* runners should be resolved by now. It slipped my mind to set it

Changes to GitLab runners configuration

Hello, For historical reasons™ all GitLab runners were running with privileged mode enabled. The happy side effect of this fact is that nothing special was ever needed to run Docker or flatpak builds. It also means we were extremely lucky that no one abused CAP_SYS_ADMIN and other elevated

Re: Changes to GitLab runners configuration

On 19/02/2020 19.52, Michael Catanzaro wrote: > Have you tested this? I've tried many times and afaik GitLab is simply > incompatible with podman images. I don't remember the exact error > message  offhand, but GitLab fails to detect podman containers as valid > containers, even when using 'podman

Re: Matrix IRC bridge considered harmful

On 12/02/2020 19.30, Michael Catanzaro wrote: > Personally, I think native Matrix would be a *lot* nicer than IRC, if we > have sysadmin time to get it set up, but I'm not going to be picky here. > I'd just like us to be able to trust that we're not missing important > messages. I have

aarch64 runners are now available in GitLab

Hi everyone, I have repurposed aarch64 hardware that has been previously used by Flathub as GitLab runners on gitlab.gnome.org. These are not the fastest servers in the world but are more than enough to test if software builds properly on non-x86_64 architecture(s). The runners consume jobs

Re: GitLab Container Registry scheduled maintenance, Friday May 29, 10 UTC

On 28/05/2020 19.16, Milan Crha via desktop-devel-list wrote: > On Thu, 2020-05-28 at 17:13 +0200, Bartłomiej Piotrowski wrote: >> We're sorry for this inconvenience and at your disposal in case of >> your questions. > > Hi, > this is the second time you plan somet

GitLab Container Registry scheduled maintenance, Friday May 29, 10 UTC

Hello, Starting tomorrow at 10 UTC, container registry service provided by GitLab will be set to read-only mode. As it has accumulated over 5TB of images, we plan to perform pruning job to remove unused tags and unreachable image layers. Given it's the first time it will be run since the switch

Distributed cache enabled for GitLab CI runners

Hi, One more announcement. I have configured all Linux-based runners to use distributed cache. It is stored on S3 and automatically removed after 90 days. Common usage and examples are described in GitLab documentation[1]. In case of any problems, please poke me somewhere. Bart [1]

Re: GitLab Container Registry scheduled maintenance, Friday May 29, 10 UTC

Hello, The pruning job has finished and container registry is available to write again. Bart ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab Container Registry scheduled maintenance, Friday May 29, 10 UTC

On 29/05/2020 16.31, Ondrej Holy wrote: > Hi, > > I also see failures for Nautilus CI: > https://gitlab.gnome.org/GNOME/nautilus/pipelines. Various permission > denied, or space left errors. But I guess that it rather relates to > the distributed cache enablement. Bartłomiej, can you please take

Re: GitLab Container Registry scheduled maintenance, Friday May 29, 10 UTC

On 30/05/2020 17.02, Michael Catanzaro wrote: > On Fri, May 29, 2020 at 5:08 pm, Bartłomiej Piotrowski > wrote: >> gnome-robots failure is indeed caused by the cache and our glorious >> Docker/flatpak/AppArmor/SELinux/seccomp combination. Disabled >> distributed c

Re: GitLab Container Registry scheduled maintenance, Friday May 29, 10 UTC

On 30/05/2020 18.19, Michael Catanzaro wrote: > On Thu, May 28, 2020 at 7:46 pm, Zander Brown wrote: >> Good luck sysadmining, sure it'll all be fine > > So I also thought this would be low-risk maintenance, but half our CI > runs are still failing and that halts development on projects that >

Re: GitLab Container Registry scheduled maintenance, Friday May 29, 10 UTC

On 31/05/2020 19.23, Matthias Clasen wrote: > On Sun, May 31, 2020 at 12:46 PM Michael Catanzaro > wrote: > > In GTK, I see the majority of ci runs now fails with:  "The script > exceeded the maximum execution time set for the job" Two runners in London have very

Re: GitLab Container Registry scheduled maintenance, Friday May 29, 10 UTC

On 31/05/2020 18.46, Michael Catanzaro wrote: > On Sun, May 31, 2020 at 11:35 am, Michael Catanzaro > wrote: >> Still failing, now on a different runner: >> >> https://gitlab.gnome.org/GNOME/epiphany/-/jobs/744761 >> >> Can you please try triggering a new CI run to make sure it actually >>

Re: GitLab Container Registry scheduled maintenance, Friday May 29, 10 UTC

On 31/05/2020 20.14, Bartłomiej Piotrowski wrote: > I have the impression that CI changes made by infrastructure team are > whims It should be "are considered whims". ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https:

Re: GitLab Container Registry scheduled maintenance, Friday May 29, 10 UTC

On 31/05/2020 16.09, Michael Catanzaro wrote: > It's still broken as of right now, see e.g. > > https://gitlab.gnome.org/Vanadiae/epiphany/-/jobs/744498 > > Or: > > https://gitlab.gnome.org/GNOME/epiphany/-/jobs/744499 > > Or: > > https://gitlab.gnome.org/jbrummer/epiphany/-/jobs/744537 > >

meet.gnome.org is now available to Foundation members

Hello, As our first virtual GUADEC[1] has concluded, we're opening up meet.gnome.org[2] to all Foundation members. You can log in with your GNOME account credentials by going to "Sign in" screen and then clicking "Sign in with LDAP" button. Local accounts have been removed except for those of

Intent to deprecate Jabber server

Hello, During routine infrastructure review, we found out that our Jabber server usage is very low, i.e. fewer than 5 users login regularly. We would like to shut it down, but as we could have missed some serious use case, we would like to give the community a heads up. Please reach out within 2

Re: GitLab scheduled maintenance, Wednesday, December 02, 9 AM UTC

On 30/11/2020 16.40, Bartłomiej Piotrowski wrote: > Hi everyone, > > This Wednesday (2020-12-02) at 9 AM UTC, gitlab.gnome.org will be down > for scheduled maintenance for approximately 2 hours. > > We will be using this time to migrate "built-in" PostgreSQL database

Re: Wrapping up Bugzilla migration

On 20/05/2021 09.38, Ondrej Holy wrote: > Hi, > > po 17. 5. 2021 v 16:45 odesílatel Bartłomiej Piotrowski > napsal: >> Infrastructure team will be accepting bugs migration requests till the >> end of May 2021. After this date, we intend to turn bugzilla.gnome.or

Wrapping up Bugzilla migration

Hi all, I have been looking at Bugzilla migration requests today and have some related announcements. First of all, if for some reason you are still using Bugzilla, you should stop and move to GitLab. I hope it's not a surprise to anyone. Infrastructure team will be accepting bugs migration

Re: Wrapping up Bugzilla migration

On 19/05/2021 15.35, Alexandre Franke wrote: > Hi, > > On Wed, May 19, 2021 at 2:49 PM Andre Klapper via desktop-devel-list > mailto:desktop-devel-list@gnome.org>> wrote: > > before turning Bugzilla read-only > and then converting it to static HTML. Happy to help with that. > > > Does

Re: Wrapping up Bugzilla migration

On 19/05/2021 14.38, Andre Klapper via desktop-devel-list wrote: > I'd prefer adding a heads-up comment[1] and mass-close remaining open > tickets as a courtesy to reporters, before turning Bugzilla read-only > and then converting it to static HTML. Happy to help with that. Good point. We'll do

Re: Wrapping up Bugzilla migration

On 17/05/2021 16.44, Bartłomiej Piotrowski wrote: > Hi all, > > I have been looking at Bugzilla migration requests today and have some > related announcements. > > First of all, if for some reason you are still using Bugzilla, you > should stop and move to GitLab. I hop