01:12 wlb: weston Merge request !1210 opened by Vitaly Prosyak (vitalyp) color-lcms: Fix memory leak in join_curvesets https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1210
05:41 wlb: weston Issue #736 opened by bot crack (unintialized) 11.0.0 Weston screen sharing in embedded environment is very laggy with 100% CPU usage https://gitlab.freedesktop.org/wayland/weston/-/issues/736
06:29 ofourdan: e78: ImageMAgick "import" lockign the Wayland/Xwayland session is the same as https://bugzilla.redhat.com/1914021 fixed with https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/972
08:40 wlb: weston Issue #737 opened by Noah-Lijc (Noah-Lijc) QT Modal windows issus https://gitlab.freedesktop.org/wayland/weston/-/issues/737
08:45 pq: e78, no-one wants spying on their machine, which is why no arbitrary program should be allowed to take screenshots at arbitrary times, especially without the user noticing. However, the end user (not the screenshooting program) also needs to have a way of letting the screenshots they want to be taken, without disturbing. Making this difference is surprisingly difficult.
10:23 wlb: weston Issue #738 opened by Fredrik Gustafsson (fredrikg) Kiosk-shell keyboard focus lost after modal dialogs https://gitlab.freedesktop.org/wayland/weston/-/issues/738
10:27 akik: hi, what's the wayland version of the log file Xorg.0.log?
10:28 vsyrjala: -wi21
10:28 vsyrjala: meh
10:32 dottedmag: akik: Wayland is the protocol, not a software. You need to ask in the channel for the compositor you're using.
10:33 akik: dottedmag: i'm not using wayland now. just helping some person figure out a problem with sway+wayland
10:33 dottedmag: akik: So you should ask in Sway channel
10:33 akik: dottedmag: ok thanks
11:09 wlb: weston Merge request !1211 opened by Daniel Stone (daniels) input: Fix uint/enum declaration mismatch https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1211 [Input]
11:30 wlb: weston Issue #731 closed \o/ (Chromium not fullscreen after disconnect hdmi monitor and then reconnect https://gitlab.freedesktop.org/wayland/weston/-/issues/731)
11:30 wlb: weston/main: Marius Vlad * desktop-shell: Do not attempt to change the state https://gitlab.freedesktop.org/wayland/weston/commit/a991691eeeb0 desktop-shell/shell.c
11:30 wlb: weston Merge request !1197 merged \o/ (desktop-shell: Do not attempt to change the state https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1197)
11:50 wlb: weston Merge request !1211 merged \o/ (input: Fix uint/enum declaration mismatch https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1211)
11:50 wlb: weston/main: Daniel Stone * input: Fix uint/enum declaration mismatch https://gitlab.freedesktop.org/wayland/weston/commit/052e63eecf81 libweston/bindings.c
12:09 pq: emersion, could you invite swick[m] to the Wayland group in Gitlab, e.g. with Reporter access. I think that should allow him to run CI shared runners on his own, which is what his wayland-protocols fork needs I guess.
12:10 emersion: do we need to do this for all contributors?
12:10 emersion: if so, please investigate a better way
12:11 pq: I guess changing wayland-protocols CI rules might work
12:11 pq: which we would need to do on all projects, which might allow running CI on MRs only.
12:12 pq: I don't really understand much of this.
12:12 daniels: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/540#what-it-means-for-me-a-maintainer-of-a-project-part-of-gitlabfreedesktoporg
12:13 daniels: just enable detached MR pipelines for now and we can do something more nuanced later
12:14 pq: emersion, btw. why do we have *anyone* in the Wayland group?
12:15 emersion: not sure i understand the question
12:15 emersion: you think we should add people to projects instead?
12:15 pq: if we do not want to add anyone there ever, why are the existing people there?
12:15 emersion: it's not that we don't want to add anyone ever
12:15 pq: adding people to projects will not give them CI right, but adding to Wayland group does
12:15 emersion: it's just that we don't want to add each and every random contributor
12:16 pq: why not established contributors?
12:16 emersion: sure
12:17 emersion: but not for the purposes of CI
12:17 emersion: for the purposes of enabling contributors to contribute more only
12:17 pq: CI is the only reason to be in the group instead of projects
12:17 emersion: we want CI for all contributors, established or not
12:18 emersion: adding seb for CI works on the short term, but it's not a proper solution to your problem
12:19 swick[m]: the problem we have right now is that we develop a branch in my repo
12:20 pq: I have special CI access through gitlab groups, which is why my MRs targeting any repo do not have a problem.
12:20 pq: ...I believe
12:22 swick[m]: yeah, your pipeline succeeded but once I merged that it ran a pipeline on my branch which failed
12:22 pq: well, *I* can just go and click a button to run anyone's CI job, so I guess I'll just do that.
12:23 swick[m]: and that pipeline is not part of the MR on wayland-protocols even though its the same branch
12:23 swick[m]: so, detached pipelines didn't help here
12:23 pq: now that particular merged MR is green again
12:24 daniels: I agree that it would be great to give CI to everyone who registered accounts, but we had to not do that because we kept repeatedly getting DoSed by crypto miners
12:26 swick[m]: I don't really care about it as long as our workflow for the color stuff works but it doesn't and I don't know how to make it work again
12:26 emersion: if you want to trust a user for CI, there is a CI-OK group
12:27 jadahl: add a 'wip/color' branch to wayland/w-p and develop it there instead?
12:27 pq: If I understood right, https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/540#what-it-means-for-me-a-maintainer-of-a-project-part-of-gitlabfreedesktoporg will stop working for people who are not in the project (or the groups?).
12:28 pq: emersion, exactly the CI-OK group. That's why I asked you to add swick[m] to Wayland group which is part of the CI-OK group.
12:33 pq: The only thing I can understand working going forward is that either people get added to the groups that are members of the CI-OK group, or those who have CI-OK powers need to manually go and run each pipeline for anyone who does not have that power.
12:33 daniels: ^ yep
12:34 pq: all these temporary intermediate workarounds are just confusing me
12:36 pq: ok, so now that I've understood this, I know that every MR whose pipeline refuses to run, someone CI-OK-powered needs to make a quick review to make sure it's not abuse and click a button to let CI run.
12:39 pq: and you have to hit force-reload in Firefox to see the MR page updated, otherwise it stays red >_<
12:39 pq: regular reload is not enough
12:43 daniels: yeah, no-one likes the workarounds
12:43 pq: well, they completely stop working
12:44 pq: so why bother adjusting .gitlab-ci.yml at all
12:51 daniels: eh?
12:52 daniels: detached MR-context pipelines are the thing you want regardless of whether or not further restrictions are applied
12:53 pq: that I did not understand from the write-up
12:55 daniels: things may get more painful than they currently are if the abuse is persistent, but hopefully that won't be the case
12:55 daniels: even if it is the case, it's not like you'd need to delete that snippet in order to unbreak things - it's a good thing in and of itself
13:02 pq: Why was it a good thing in and of itself again?
13:05 daniels: because it means that the pipelines run associated with the MR itself and the parent project, rather than only running in the context of the user's forked branch linked only to the commit SHA with no indication that it's related to an MR
13:10 pq: ok, what's the benefit? Proposed new CI imaged get created directly in the project registry instead of the user's registry?
13:10 pq: *images
13:16 daniels: nah, it's a bit more nuanced than that, but basically it makes it less complicated to try and create sensible rules
13:16 daniels: I'm sorry if I'm not giving a concise five-point explanation of the differences, but that's because they're not easy to explain, unless you understand enough of how it works that you already know what the differences are
13:16 daniels: there are links from that issue which offer as much detail as you'd care to know
13:19 pq: oh, so it makes more complex rules possible, if one would happen to need those
13:23 pq: "Note that currently a non project member can run the CI with that workaround. In one month from now, only project members will get the policy validated for them. Drive-by contributors will require a manual action from a project member."
13:24 pq: Is that literally project members, or is it the group members?
13:26 daniels: group members are implicitly project members
13:27 pq: but project members are not implicitly group members, so which one does the policy check?
13:27 pq: only group members get CI powers now, project members don't
13:29 daniels: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/540#how-are-you-deciding-who-gets-to-run-what
13:29 daniels: this notes that it's both
13:29 daniels: it checks the ci-ok group to see if the user is allowed to execute ci - and that is members of the top-level wayland group
13:30 daniels: it further (and this is only possible with the .gitlab-ci.yml snippet) checks to see if the pipeline is running in MR context by a user who can push to that project
13:30 daniels: so: both work
14:00 pq: oh yeah, it wouldn't help anything if that too was checking group membership, so it has to be about project membership.
14:02 pq: I suppose adding people to a project is more common and easier and gives CI access only with that project, and not for everything like with the groups.
14:51 wlb: weston Merge request !1210 merged \o/ (color-lcms: Fix memory leak in join_curvesets https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1210)
14:51 wlb: weston/main: Vitaly Prosyak * color-lcms: Fix memory leak in join_curvesets https://gitlab.freedesktop.org/wayland/weston/commit/712fd0f5768c libweston/color-lcms/color-transform.c
14:53 wlb: weston Issue #707 closed \o/ (LCMS introduces leaks in tests https://gitlab.freedesktop.org/wayland/weston/-/issues/707)
14:57 wlb: weston Merge request !1212 opened by Pekka Paalanen (pq) Fix two tiny memory leaks https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1212 [Testing], [Weston frontend]
15:00 wlb: weston Merge request !1213 opened by Daniel Stone (daniels) input: Destroy tablet-tool bindings on exit https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1213 [Input], [Testing]
15:00 pq: arm runners seems to be having a bad day
15:01 psykose: well, have you ever tried to run with your arms? not great
15:01 pq: indeed, some broken bones today though
15:02 pq: daniels, will you be writing more trivial leak fixes for weston? :-)
15:02 pq: I have one open that I didn't get to yet, and won't today.
15:03 daniels: pq: not right now, no
15:03 daniels: I looked at the INI file one and it’s not a 3-minute
15:03 daniels: *job
15:03 pq: aha
15:04 pq: did you see one about logger-scopes? I suspect there should be one, but I didn't find it yet.
15:04 pq: in main.c
15:05 daniels: I haven’t seen that no, but xwl would presumably provoke that along with all the others
15:05 pq: yup
15:06 pq: xwl provokes quite a lot
15:06 daniels: srsly
15:06 pq: some of which might not even be ours, I guess
15:06 pq: anyway, let's clash another day :-)
15:10 daniels: yeah, that's definitely a problem for not-today-man
15:16 wlb: weston/main: Pekka Paalanen * tests: do not leak renderer argument https://gitlab.freedesktop.org/wayland/weston/commit/21f2fb99d5ab tests/weston-test-fixture-compositor.c
15:16 wlb: weston/main: Pekka Paalanen * compositor: free renderer string https://gitlab.freedesktop.org/wayland/weston/commit/8a1f56310cbc compositor/main.c
15:16 wlb: weston Merge request !1212 merged \o/ (Fix two tiny memory leaks https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1212)
15:23 wlb: weston Issue #739 opened by matoro1 (matoro1) Test-failures on big-endian architectures https://gitlab.freedesktop.org/wayland/weston/-/issues/739
16:20 wlb: weston Merge request !1214 opened by Daniel Stone (daniels) tests: Move prog_args_save() later https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1214 [Testing]
17:57 bwidawsk: To clarify, the wl_display errors (https://wayland.app/protocols/wayland#wl_display:enum:error) are available for use by any protocol request implementation?
17:59 emersion: yeah, but be careful to send them on the wl_display object
18:00 emersion: not on the protocol implementatiosn objects
18:01 bwidawsk: emersion: I see
18:01 bwidawsk: thanks