zext-screencopy-unstable-v1

.builds/alpine.yml

@@ -18,7 +18,7 @@ packages:
   - xwayland
   - libseat-dev
 sources:
-  - https://github.com/swaywm/wlroots
+  - https://gitlab.freedesktop.org/wlroots/wlroots.git
 tasks:
   - setup: |
       cd wlroots

.builds/archlinux.yml

@@ -19,18 +19,18 @@ packages:
   - vulkan-headers
   - glslang
 sources:
-  - https://github.com/swaywm/wlroots
+  - https://gitlab.freedesktop.org/wlroots/wlroots.git
 tasks:
   - setup: |
       cd wlroots
-      CC=gcc meson build-gcc --fatal-meson-warnings --default-library=both -Dauto_features=enabled --prefix /usr
+      CC=gcc meson build-gcc --fatal-meson-warnings --default-library=both -Dauto_features=enabled --prefix /usr -Db_sanitize=address,undefined
       CC=clang meson build-clang --fatal-meson-warnings -Dauto_features=enabled
   - gcc: |
       cd wlroots/build-gcc
       ninja
       sudo ninja install
       cd ../tinywl
-      make
+      CFLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer" make
   - clang: |
       cd wlroots/build-clang
       ninja

.builds/freebsd.yml

@@ -26,7 +26,7 @@ packages:
   - sysutils/seatd
   - gmake
 sources:
-  - https://github.com/swaywm/wlroots
+  - https://gitlab.freedesktop.org/wlroots/wlroots.git
 tasks:
   - wlroots: |
       cd wlroots

.editorconfig

@@ -7,6 +7,7 @@ charset = utf-8
 trim_trailing_whitespace = true
 indent_style = tab
 indent_size = 4
+max_line_length = 80
 
 [*.xml]
 indent_style = space

.gitlab-ci.yml

@@ -0,0 +1,7 @@
+include: https://git.sr.ht/~emersion/dalligi/blob/master/templates/multi.yml
+alpine:
+  extends: .dalligi
+archlinux:
+  extends: .dalligi
+freebsd:
+  extends: .dalligi

CONTRIBUTING.md

@@ -1,21 +1,21 @@
 # Contributing to wlroots
 
-Contributing just involves sending a pull request. You will probably be more
+Contributing just involves sending a merge request. You will probably be more
 successful with your contribution if you visit [#sway-devel on Libera Chat]
 upfront and discuss your plans.
 
 Note: rules are made to be broken. Adjust or ignore any/all of these as you see
 fit, but be prepared to justify it to your peers.
 
-## Pull Requests
+## Merge Requests
 
-If you already have your own pull request habits, feel free to use them. If you
+If you already have your own merge request habits, feel free to use them. If you
 don't, however, allow me to make a suggestion: feature branches pulled from
 upstream. Try this:
 
 1. Fork wlroots
-2. `git clone git@github.com:<username>/wlroots.git && cd wlroots`
-3. `git remote add upstream https://github.com/swaywm/wlroots`
+2. `git clone git@gitlab.freedesktop.org:<username>/wlroots.git && cd wlroots`
+3. `git remote add upstream https://gitlab.freedesktop.org/wlroots/wlroots.git`
 
 You only need to do this once. You're never going to use your fork's master
 branch. Instead, when you start working on a feature, do this:
@@ -24,11 +24,11 @@ branch. Instead, when you start working on a feature, do this:
 2. `git checkout -b add-so-and-so-feature upstream/master`
 3. Add and commit your changes
 4. `git push -u origin add-so-and-so-feature`
-5. Make a pull request from your feature branch
+5. Make a merge request from your feature branch
 
-When you submit your pull request, your commit log should do most of the talking
+When you submit your merge request, your commit log should do most of the talking
 when it comes to describing your changes and their motivation. In addition to
-this, your pull request's comments will ideally include a test plan that the
+this, your merge request's comments will ideally include a test plan that the
 reviewers can use to (1) demonstrate the problem on master, if applicable and
 (2) verify that the problem no longer exists with your changes applied (or that
 your new features work correctly). Document all of the edge cases you're aware
@@ -80,15 +80,15 @@ cmd_move"* or *"Improve performance of arrange_windows on ARM"* or similar.
 
 The subsequent lines should be separated from the subject line by a single
 blank line, and include optional details. In this you can give justification
-for the change, [reference Github issues], or explain some of the subtler
+for the change, [reference issues], or explain some of the subtler
 details of your patch. This is important because when someone finds a line of
 code they don't understand later, they can use the `git blame` command to find
 out what the author was thinking when they wrote it. It's also easier to review
-your pull requests if they're separated into logical commits that have good
+your merge requests if they're separated into logical commits that have good
 commit messages and justify themselves in the extended commit description.
 
-As a good rule of thumb, anything you might put into the pull request
-description on Github is probably fair game for going into the extended commit
+As a good rule of thumb, anything you might put into the merge request
+description on GitLab is probably fair game for going into the extended commit
 message as well.
 
 See [How to Write a Git Commit Message] for more details.
@@ -101,18 +101,25 @@ changes will typically see review from several people. Be prepared to receive
 some feedback - you may be asked to make changes to your work. Our code review
 process is:
 
-1. **Triage** the pull request. Do the commit messages make sense? Is a test
+1. **Triage** the merge request. Do the commit messages make sense? Is a test
    plan necessary and/or present? Add anyone as reviewers that you think should
-   be there (using the relevant GitHub feature, if you have the permissions, or
+   be there (using the relevant GitLab feature, if you have the permissions, or
    with an @mention if necessary).
 2. **Review** the code. Look for code style violations, naming convention
    violations, buffer overflows, memory leaks, logic errors, non-portable code
    (including GNU-isms), etc. For significant changes to the public API, loop in
    a couple more people for discussion.
 3. **Execute** the test plan, if present.
-4. **Merge** the pull request when all reviewers approve.
+4. **Merge** the merge request when all reviewers approve.
 5. **File** follow-up tickets if appropriate.
 
+## Code of Conduct
+
+Note that as a project hosted on freedesktop.org, wlroots follows its
+[Code of Conduct], based on the Contributor Covenant. Please conduct yourself
+in a respectful and civilized manner when communicating with community members
+on IRC and bug tracker.
+
 ## Style Reference
 
 wlroots is written in C with a style similar to the [kernel style], but with a
@@ -396,6 +403,7 @@ static void subsurface_handle_surface_destroy(struct wl_listener *listener,
 [#sway-devel on Libera Chat]: https://web.libera.chat/gamja/?channels=#sway-devel
 [linear, "recipe" style]: https://www.bitsnbites.eu/git-history-work-log-vs-recipe/
 [git-rebase.io]: https://git-rebase.io/
-[reference Github issues]: https://help.github.com/articles/closing-issues-via-commit-messages/
+[reference issues]: https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically
+[Code of Conduct]: https://www.freedesktop.org/wiki/CodeOfConduct/
 [How to Write a Git Commit Message]: https://chris.beams.io/posts/git-commit/
 [kernel style]: https://www.kernel.org/doc/Documentation/process/coding-style.rst

README.md

@@ -32,9 +32,8 @@ to implement yourself.
 Check out our [wiki] to get started with wlroots. Join our IRC channel:
 [#sway-devel on Libera Chat].
 
-wlroots is developed under the direction of the [sway] project. A variety of
-[wrapper libraries] are available for using it with your favorite programming
-language.
+A variety of [wrapper libraries] are available for using it with your favorite
+programming language.
 
 ## Building
 
@@ -75,9 +74,8 @@ Install like so:
 See [CONTRIBUTING.md].
 
 [Wayland]: https://wayland.freedesktop.org/
-[wiki]: https://github.com/swaywm/wlroots/wiki/Getting-started
+[wiki]: https://gitlab.freedesktop.org/wlroots/wlroots/-/wikis/Getting-started
 [#sway-devel on Libera Chat]: https://web.libera.chat/gamja/?channels=#sway-devel
-[Sway]: https://github.com/swaywm/sway
-[wrapper libraries]: https://github.com/search?q=topic%3Abindings+org%3Aswaywm&type=Repositories
+[wrapper libraries]: https://gitlab.freedesktop.org/wlroots/wlroots/-/wikis/Projects-which-use-wlroots#wrapper-libraries
 [libseat]: https://git.sr.ht/~kennylevinsen/seatd
-[CONTRIBUTING.md]: https://github.com/swaywm/wlroots/blob/master/CONTRIBUTING.md
+[CONTRIBUTING.md]: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/CONTRIBUTING.md