On Thu, Jun 18, 2020 at 5:58 pm, Michael Catanzaro
wrote:
It seems all privileged runners have disappeared. All my glib-net CI
pipelines are stalled. :(
Looks like this was some sort of temporary infrastructure problem last
night, because it's fixed again now.
It seems all privileged runners have disappeared. All my glib-net CI
pipelines are stalled. :(
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
On Sun, Jun 14, 2020 at 1:42 pm, philip.chime...@gmail.com wrote:
Is GJS really the only project that tests merge requests using ASan
and LSan? If not, please speak up so we can have a better idea of how
many projects are affected.
No, glib-networking also requires asan for every merge
On Thu, Mar 26, 2020 at 5:26 AM Jordan Petridis via desktop-devel-list <
desktop-devel-list@gnome.org> wrote:
> On Sunday, March 22, 2020 12:56 AM, Michael Catanzaro <
> mcatanz...@gnome.org> wrote:
>
> > On Sat, Mar 21, 2020 at 1:21 pm, Christian Hergert
> > christ...@hergert.me wrote:
> >
>
> >
On Sunday, March 22, 2020 12:56 AM, Michael Catanzaro
wrote:
> On Sat, Mar 21, 2020 at 1:21 pm, Christian Hergert
> christ...@hergert.me wrote:
>
> > Those words sound incompatible to me in the same way that if you have
> > access to Linux's perf, you can sniff pretty much any data you want
On Sat, Mar 21, 2020 at 1:21 pm, Christian Hergert
wrote:
Those words sound incompatible to me in the same way that if you have
access to Linux's perf, you can sniff pretty much any data you want on
the system.
We're talking about CI runners... we only need privileged access inside
the
On 3/21/20 12:09 PM, Philip Chimento via desktop-devel-list wrote:
>
> I'd really appreciate if we could find a way to have the unprivileged
> runners have CAP_SYS_PTRACE added to them.
Those words sound incompatible to me in the same way that if you have
access to Linux's perf, you can sniff
On Sat, Mar 21, 2020 at 6:47 AM Michael Catanzaro
wrote:
> On Fri, Mar 20, 2020 at 8:20 pm, philip.chime...@gmail.com wrote:
> > Has anyone managed to get lsan/asan to work without CAP_SYS_PTRACE
> > yet or otherwise have any suggestions on what would need to be done
> > to support it in an
On Fri, Mar 20, 2020 at 8:20 pm, philip.chime...@gmail.com wrote:
Has anyone managed to get lsan/asan to work without CAP_SYS_PTRACE
yet or otherwise have any suggestions on what would need to be done
to support it in an unprivileged setup?
I marked my CI as privileged:
On Tue, Mar 3, 2020 at 6:29 AM Michael Catanzaro
wrote:
> On Mon, Mar 2, 2020 at 9:41 pm, Philip Chimento via desktop-devel-list
> wrote:
> > Also, has anyone successfully gotten a CI job that uses lsan or asan
> > to work in the unprivileged setup? (See my previous question about
> >
Hi again,
> this seems to be because of
> https://gitlab.com/gitlab-org/gitlab/issues/198518
Thanks Ondrej for finding the root cause of the change!
I just pushed [1] a change to the template which should workaround the issue
for now. Also left a comment on the upstream issue [2]
If your
Hi all,
this seems to be because of
https://gitlab.com/gitlab-org/gitlab/issues/198518 and it is enough to
use some custom stages instead of .pre/.post to fix this, which I did
recently for Nautilus:
https://gitlab.gnome.org/GNOME/nautilus/-/commit/e7c2a0182a4ba2d6eb05fe170cc9b4d018a70feb.
Am Sonntag, den 08.03.2020, 18:34 + schrieb Jordan Petridis:
> Hi Felix,
Hi!
> I've noticed that a while ago as well, but I was certain it wasn't
> caused by the recent changes cause we had extensively
> test them.
Yes, I found the templates in gitlab after writing the mail and the
changes
Hi Felix,
I've noticed that a while ago as well, but I was certain it wasn't caused by
the recent changes cause we had extensively
test them.
Today I found some time to track down the issue and looks like its a regression
on gitlab itself, probably on the latest update.
The issue is that the
Am Mittwoch, den 19.02.2020, 14:50 +0100 schrieb Bartłomiej Piotrowski:
> Hello,
Hi!
> For past few days I've been working to ensure that Flatpak builds are
> still functional without additional privileges. If your project is
> using
> citemplates[1], the configuration change should be invisible
On Tue, Mar 3, 2020 at 1:36 PM Bartłomiej Piotrowski
wrote:
> I've poked around yesterday and it's apparently not as trivial to run
> buildah unprivileged in a container as it was the last time I tried. I
> don't see better way than tagging jobs privileged at the moment.
Thanks, tagging the job
On Mon, Mar 2, 2020 at 9:41 pm, Philip Chimento via desktop-devel-list
wrote:
Also, has anyone successfully gotten a CI job that uses lsan or asan
to work in the unprivileged setup? (See my previous question about
CAP_SYS_PTRACE.)
Hm, looks like my glib-networking CI is broken due to this. I
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
On Tue, Mar 3, 2020 at 6:42 AM Philip Chimento via desktop-devel-list
wrote:
> Does anyone have any advice on what to do with this? I followed Sam's helpful
> hint about Tracker's CI images working to [1], copied the things that looked
> like they might be relevant from there into my own
On Fri, Feb 28, 2020 at 6:18 AM Michael Catanzaro
wrote:
> On Mon, Feb 24, 2020 at 6:46 pm, Jordan Petridis via desktop-devel-list
> wrote:
> > No there isn't, it was working properly when it was first rolled out.
> > I've started seen this issue today and looks like it only affecting
> > some
On Mon, Feb 24, 2020 at 6:46 pm, Jordan Petridis via desktop-devel-list
wrote:
No there isn't, it was working properly when it was first rolled out.
I've started seen this issue today and looks like it only affecting
some runners, so I am guessing something got updated or new runners
where
Hi,
> Is there anything else that needs to be done?
No there isn't, it was working properly when it was first rolled out. I've
started seen this issue today and looks like it only affecting some runners, so
I am guessing something got updated or new runners where added. Bart is on
vacation
On Mon, Feb 24, 2020 at 11:08 am, Michael Catanzaro
wrote:
I have two failed builds on flatpak-gcc176 (also broken) and two
failed builds on flatpak-gcc150.fsffrance.org (also broken). My plan
is to keep retrying until I get flatpak-progress again. I need a
successful build urgently because
On Mon, Feb 24, 2020 at 4:48 pm, Bastien Nocera
wrote:
Ran it 3 separate times, on 3 different runners, to no avail.
I'm struggling with this currently.
From yesterday:
https://gitlab.gnome.org/GNOME/epiphany/pipelines/10/builds
I have a failed build on flatpak-gcc175 (broken), then a
On Mon, 2020-02-24 at 08:19 -0600, Michael Catanzaro wrote:
> On Mon, Feb 24, 2020 at 10:11 am, Bastien Nocera
> wrote:
> > It uses the flatpak_ci_initiative.yml template and throws this
> > error:
> > bwrap: Creating new namespace failed, likely because the kernel
> > does
> > not support user
On Mon, Feb 24, 2020 at 10:11 am, Bastien Nocera
wrote:
It uses the flatpak_ci_initiative.yml template and throws this error:
bwrap: Creating new namespace failed, likely because the kernel does
not support user namespaces. bwrap must be installed setuid on such
systems.
I'm seeing this
On Wed, 2020-02-19 at 14:50 +0100, Bartłomiej Piotrowski wrote:
> 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
>
19.02.2020 23:18, Bartłomiej Piotrowski пишет:
However, I did not test it after described changes. I recall it used to
be possible to run buildah in an unprivileged container, but just in
case, I have also configured additional privileged runner available only
to projects in GNOME group. Add
On Wed, Feb 19, 2020 at 11:18 AM Bartłomiej Piotrowski <
bpiotrow...@gnome.org> wrote:
> 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
On Wed, 2020-02-19 at 13:14 -0600, Michael Catanzaro wrote:
> On Wed, Feb 19, 2020 at 8:00 pm, Sam Thursfield
> wrote:
> > We've been using podman successfully to build the Tracker CI
> > images.
> > The exact build instructions are here:
> >
> >
> >
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
On Wed, Feb 19, 2020 at 8:00 pm, Sam Thursfield
wrote:
We've been using podman successfully to build the Tracker CI images.
The exact build instructions are here:
https://gitlab.gnome.org/GNOME/tracker-oci-images/blob/master/.gitlab-ci.yml
These containers are working fine in GitLab CI,
On Wed, Feb 19, 2020 at 7:53 PM 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
On Wed, Feb 19, 2020 at 2:50 pm, Bartłomiej Piotrowski
wrote:
If your project's pipeline is using Docker to build an image from
Dockerfile, consider switching to podman or buildah as they should
work
unprivileged.
Have you tested this? I've tried many times and afaik GitLab is simply
34 matches
Mail list logo
