04:37 ishitatsuyuki: gitlab seems slow and timing out sometimes
07:40 hakzsam: gitlab fdo is still mostly unuseable today :/
07:44 airlied: it has moments of lucidty but yes mostly bad
07:50 BMaxV: Hello again, I would like to propose to add css to the automatically generated htmls of the specs. But the fork button is grey, so my "learned pattern" of how to do stuff doesn't work. Should file an issue first? Do I need some kind of permission on the gitlab instance? Thanks.
08:48 Hazematman: <hakzsam> "gitlab fdo is still mostly..." <- yeah I'm having the same problem :( trying to push and getting "remote: GitLab: Internal API unreachable"
12:06 manuels2: Is there something like a spec for default terminals?
12:06 manuels2: I read about xdg-terminal
12:07 manuels2: Shouldn't we have a standardized way to launch user configured terminals?
12:07 manuels2: Like having a mime handler for shell script mime types?
12:08 manuels2: I wrote a keyboard Launcher
12:09 manuels2: One of its key features is to launch a terminal for several things (like commands, directories, scripts and such)
12:09 manuels2: It's a pain to offer a hard coded list of terminals out there
12:11 manuels2: It would be rather nice if the terminal projects could specify that they are able to handle shell scripts
12:11 manuels2: And as such the user could define a default
12:23 manuels2: https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/3
12:23 manuels2: fonud this
12:23 manuels2: why is there nothing happening
12:28 BMaxV: seems like it's still being discussed?
12:29 BMaxV: but I am also here waiting for people who are in the know to speak up in general :)
12:41 manuels2: why not just merge it and improve from there on?
12:41 manuels2: is see gnome does something in this direction
12:41 manuels2: I just need a spec to report upstream bugs in terminal projects
12:42 manuels2: they are not going to implement a draft
12:42 manuels2: actually the xdg-terminal-exec tool is not that important imho
12:43 manuels2: its rather about the standard on how terminals should behave
12:43 manuels2: as stated in the specs xterm -e is the defacto standard (some use -x)
12:43 manuels2: the real problem is how to find the terminals
12:44 manuels2: there is not a single deterministic (standardized) across platforms to tell if a desktop entry is a terminal and how to run it yet
12:44 manuels2: *way
12:46 manuels2: atm i have to go through some fragile heuristic hardcoding executable name patterns and match them
12:47 manuels2: because e.g. blackbox term is blackbox and on other systems blackbox-terminal (because blackbox is also a window manager)
12:48 manuels2: not only the heuristic sucks
12:48 manuels2: i also have to hardcode the ExecArgs
12:49 manuels2: incredible for a platform commonly referred to as dev-centric platform
12:52 manuels2: maybe it makes sense to just improve on the desktop entry spec before
12:57 BMaxV: idk yet, maybe "the correct way" to contact is the mailing list, I have not tried that yet.
12:58 manuels2: Where can I find that mailing list?
12:58 manuels2: And who is actually in charge of merging?
13:03 manuels2: there is none https://lists.freedesktop.org/mailman/listinfo/
13:05 BMaxV: https://www.freedesktop.org/wiki/
13:05 BMaxV: https://lists.freedesktop.org/mailman/listinfo/freedesktop
13:05 BMaxV: that one?
13:06 BMaxV: I mean, if nobody speaks up, "reply all" to a wider circle of people? :)
13:43 bl4ckb0ne: how's marge feeling today
14:12 bilboed: remote: calling pre_receive endpoint: http post to gitlab api /pre_receive endpoint: Internal API unreachable Just got this while pushing to my personal repo. Rings a bell ?
14:16 bilboed: ah, and now fatal: Could not read from remote repository. So same issue as others
14:16 bilboed:checks pub opening time
14:26 manuels2: that wiki is horribly outdated
14:26 manuels2: latest destop entry spec 1.1
14:39 manuels2: Okay
14:39 manuels2: I mailed on the list
14:39 manuels2: How can I send a PR?
14:40 manuels2: This is something that annoys me for like a decade
14:40 manuels2: And we have a defacto standard
14:41 manuels2: Let's carve it into stone
14:41 manuels2: It's going to take another decade to take effect
14:42 manuels2: At least I'll have a less frustrated retirement then😀
15:45 bl4ckb0ne: are the marge CI pipeline labeled Blocked a marge issue or a setting issue? the pipeline is all green on the MR but when I assign it to marge it looks like this https://gitlab.freedesktop.org/BarthPaleologue/monado/-/pipelines/1221993
15:51 eric_engestrom: bl4ckb0ne: marge (the script itself) is failing randomly at various steps because gitlab is randomly returning errors, which itself is (I think?) because we've been ddos'ed for a week now
15:52 eric_engestrom: re-assigning is the only workaround I know
15:52 MrCooper: bl4ckb0ne: that looks like a branch pipeline, not an MR pipeline
15:52 bl4ckb0ne: thanks, I got unsure because i managed to merge something else without any issue
15:52 bl4ckb0ne: but I did got a `ERROR: Internal API unreachable` when pushing a few minutes ago
15:53 bl4ckb0ne: MrCooper: what do you mean?
15:53 MrCooper: if the MR page links to this pipeline, either the CI config is broken or the MR has hit the bug where GitLab picks the wrong pipeline
15:53 MrCooper: which MR is it?
15:54 bl4ckb0ne: https://gitlab.freedesktop.org/monado/monado/-/merge_requests/2276
15:55 eric_engestrom: MrCooper: I think it's just that the user creating the developer+ on the project so their MR creates pipelines in the user namespace instead of the target project namespace
15:55 eric_engestrom: *the user creating the MR is not developer+
15:57 MrCooper: it's not about the namespace but about the type of pipeline
15:59 eric_engestrom: oh, I didn't see a mention of the type
15:59 MrCooper: the CI configuration of this project is such that each push generates two separate pipelines, one for the source branch and one for the MR
15:59 eric_engestrom: ack
15:59 MrCooper: the referenced pipeline is the branch pipeline
15:59 bl4ckb0ne: anything the user can do to get the right type of pipeline?
15:59 MrCooper: there's a GitLab bug where it sometimes incorrectly associates the MR with the branch pipeline
16:03 MrCooper: looks like assigning to Marge should work now, since the MR is now associated with an MR pipeline which passed
16:30 eric_engestrom: MrCooper: I think it's a marge bug actually, it looks at the first item on the list of pipelines in the MR, instead of limiting to MR pipelines, because it can't have that filter because some project don't have MR pipelines
16:31 eric_engestrom: the "solution" I came up with in mesa was getting rid of branch pipelines when there's an MR pipeline
16:31 eric_engestrom: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/.gitlab-ci.yml#L30-32
16:32 eric_engestrom: https://gitlab.freedesktop.org/mesa/mesa/-/commit/717cff829c51bd084a1592ab1b35408b52ca6b22
16:33 eric_engestrom: if that's acceptable to the monado project then they can put the same line in their gitlab config
17:35 bl4ckb0ne: CI pipeline by marge is running on the MR, thanks!
17:36 bl4ckb0ne: that do not duplicate rule seems nice, i'll see what I can do with our ci
19:28 steelswords: Hi there! I'm running into trouble with cloning this repo: https://anongit.freedesktop.org/git/gstreamer/common.git I keep getting an HTTP 504 error. Is there an outage or something going on? I just want to make sure the right people see this.
20:04 bl4ckb0ne: i have a private fork of a private repo, when adding CI and building images I get a `requested access to the resource is denied` on the image, did I miss a permission somewhere?
20:05 steelswo1ds: ?
20:06 steelswo1ds: Sorry, typo. I'm not even getting that far.
20:21 bl4ckb0ne: hm not sure what I changed but I think I got it!
21:32 steelswo1ds: Man... I'm still not having any luck. The gitlab seems to work okay for now.
21:34 steelswo1ds: But I'd still like to get it fixed. Not least of all because https://anongit.freedesktop.org/git/gstreamer/common.git is the upstream for a submodule burried like three layers of depenencies deep in a yocto build I'm trying to run :-S