Re: gitlab: failing check-merge-request on non MR branches
On Thu, Feb 15, 2024 at 12:15:52PM +0100, Enrico Weigelt, metux IT consult wrote: > Hello friends, > > > is it intended that the check-merge-request job is always failing on > non MR branches ? See commit 88637d42dbc5c488c9a75a6042e6778c4928b007 in ci-templates for the motivation. I think that default has been fixed in gitlab since (can't immediately find a setting for it though). Now that we have workflows we can probably make that job dependent on CI_PIPELINE_SOURCE == 'merge_request_event' or something. Cheers, Peter > Fortunately it's just classified as warning instead of fail, but still > troubling: either one has to check the indivual job results or risks > not noticing other warnings that indeed are also relevant for non-MRs. > > > --mtx > > -- > --- > Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert > werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren > GPG/PGP-Schlüssel zu. > --- > Enrico Weigelt, metux IT consult > Free software and Linux embedded engineering > i...@metux.net -- +49-151-27565287
Re: Stepping in as Xnest maintainer
Hi, Whilst I'm sure this is a nice thing to do -- is there any reason why you're wanting to invest your time in maintaining Xnest, when Xephyr seems to have a lot of additional features already? Kindly, Thomas On Thu, 15 Feb 2024 at 15:30, Enrico Weigelt, metux IT consult wrote: > > Hello folks, > > > since Xnest seems to be unmaintained for quite some time now, I've > decided to step in as it's maintainer. > > Here's a PR for that - including some Xnest fixes. > > https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1299 > > > --mtx > > -- > --- > Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert > werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren > GPG/PGP-Schlüssel zu. > --- > Enrico Weigelt, metux IT consult > Free software and Linux embedded engineering > i...@metux.net -- +49-151-27565287
Stepping in as Xnest maintainer
Hello folks, since Xnest seems to be unmaintained for quite some time now, I've decided to step in as it's maintainer. Here's a PR for that - including some Xnest fixes. https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1299 --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: gitlab: failing check-merge-request on non MR branches
On Thu, Feb 15, 2024 at 12:15:52PM +0100, Enrico Weigelt, metux IT consult wrote: > Hello friends, > > > is it intended that the check-merge-request job is always failing on > non MR branches ? > When requesting a merge, I had errors with the CI. But this had to do with the git commit messages. A message shall have a one brief line of description. Then an empty line. And then, perhaps, a more precise description of the modifications commited. The failure had, for me, nothing to do with the fact that it was a fork, but simply CI checks that failed (about the commit messages). You have to look at the exact messages about the failure to understand and hopefully fix what is wrong. HTH, -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: Licenses: being finicky
On Thu, Feb 15, 2024 at 12:04:42PM +0100, Enrico Weigelt, metux IT consult wrote: > On 14.02.24 21:37, tlaro...@kergis.com wrote: >[...] > > I think that the correct way is to state 'X11' or 'MIT' or > > whatever matches COPYING or COPYRIGHTS or whatever file explains the > > license status and to conform, simply because this exists and is > > standardized, to the SPDX list of identifiers. > > > > What do other think about this? > > IMHO we should first start moving to spdx tags on per case basis (get > rid of all the long redundant texts), review the status quo and then > decide on future standard license (on per-package basis - libraries > might need different one than tools or the Xserver) IMHO, a rule should be set when doing new stuff, reviewing the licenses being not high on priority levels---there is more urgent things to do. And, for new stuff, perhaps just a SPDX line with a supplementary line with the name of the author, and sticking to some developers' decided license: I have no problem, for my work, with 'MIT' or 'X11'---being defined as given on the SPDX published list: there is a difference---or, if a project has a license, to stick to the license of the project. I'd like not to start a bikeshedding thread about licenses ;-) I'd like just to have some guideline in order to not introduce "noise" in contributions. But as about converting 'X11' to 'MIT', IMHO: no. It's not the same (once again: sticking to the identification given by SPDX; I do not take it as a holly reference, but just as an existing standard whose purpose was precisely to clarify licensing issues) and should just be stated exactly, conforming to the license text expressed in an existing project. My two cents, -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
gitlab: failing check-merge-request on non MR branches
Hello friends, is it intended that the check-merge-request job is always failing on non MR branches ? Fortunately it's just classified as warning instead of fail, but still troubling: either one has to check the indivual job results or risks not noticing other warnings that indeed are also relevant for non-MRs. --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: Licenses: being finicky
On 14.02.24 21:37, tlaro...@kergis.com wrote: Hi, Some meson.build, for example, have a SPDX-License-Identifier: tag, you're raising a good point. I've already been thinking about replacing the repeated long lincense text all over the source files by tiny SPDX-License-Identifier (possibly even on per-subdir / module basis). where "MIT" is mentionned, applying (I think) to the file itself, and the project has an entry with a pair (license: 'MIT') applying to the data by itself. Since we've got lots of different license texts (not checked whether it's just editorial differences), I'd assume it's per-file basis. Makes sense to me: as soon as somebody's writing some (non-trivial) text (on his own), he's the copyright holder and thus can decide on licensing of his work (or could transfer that right to somebody else via contract). And it doesn't seem that X (at least the server tree) ever had some clear rules on what licenses are being accepted for mainlining. this is identified as "X11", the "MIT" being the same without this fourth paragraph. (I suspect this distinction is rather new.) The difference between X11 and MIT seems to be the first is explicitly mentioning the X consortium as authors. My interpretation this is more a formalized placeholder and pretty much the same as MIT. IANAL, but I'd assume that we could change from X11 to MIT, even if it meant a being different license. IMHO, the paragraph about names / trademarks is redundant, since using speaking in anybody else's name or using his trademarks needs explicit grant anyways, and that even isn't subject to copyright at all (at least in the jurisdictions I know) By the way, we (or anybody who forks) could even relicense as GPL. I wonder whether that would trigger some interesting media coverage. hmm, let's have a long flamewar about that, big enough that it can't be overseen by the media ;-) When creating meson files for building, is there some rule regarding this? I'd like to extend this question to any new code / files. I think that the correct way is to state 'X11' or 'MIT' or whatever matches COPYING or COPYRIGHTS or whatever file explains the license status and to conform, simply because this exists and is standardized, to the SPDX list of identifiers. What do other think about this? IMHO we should first start moving to spdx tags on per case basis (get rid of all the long redundant texts), review the status quo and then decide on future standard license (on per-package basis - libraries might need different one than tools or the Xserver) --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
