## 1. Project Overview & Quickstart (LizardByte/legal) # legal Open-source repository LizardByte/legal ### Repository Details - **Repository:** [LizardByte/legal](https://github.com/LizardByte/legal) - **Primary Language:** Code *Note: High-volume repository documentation is actively indexed and synchronized by YakaAI.* ## 2. Official Technical Reference & Guides (LizardByte/LizardByte.github.io) ## File: README.md ## About This repo contains the source files for the [LizardByte](https://app.lizardbyte.dev) website. The page is built using jekyll and hosted on GitHub Pages. ### CrowdIn Localization ### Reusable Workflow This repo contains a reusable workflow to allow for building gh-pages subprojects using the same configuration. ```yml --- name: Jekyll CI permissions: contents: read on: pull_request: branches: - master types: - opened - synchronize - reopened concurrency: group: "${{ github.workflow }}-${{ github.ref }}" cancel-in-progress: true jobs: prep: runs-on: ubuntu-latest steps: # Prepare your site here if needed, you can run any build steps needed to generate the site # The structure of the artifacts must be exactly as you expect to find the files in the final site # e.g. `index.html` should be at the root of the artifact, not in a subdirectory - name: Sample build run: echo "Hello, world!" > hello.txt - name: Upload artifact uses: actions/upload-artifact@v4 with: name: prep # any name except 'site' is allowed path: hello.txt if-no-files-found: error include-hidden-files: true retention-days: 1 call-jekyll-build: needs: prep uses: LizardByte/LizardByte.github.io/.github/workflows/jekyll-build.yml@master secrets: GH_BOT_EMAIL: ${{ secrets.GH_BOT_EMAIL }} GH_BOT_TOKEN: ${{ secrets.GH_BOT_TOKEN }} with: gh_bot_name: ${{ vars.GH_BOT_NAME }} site_artifact: 'prep' # any name except 'site' is allowed target_branch: 'gh-pages' clean_gh_pages: true ``` For additional options see [jekyll-build.yml](.github/workflows/jekyll-build.yml) ### PR Previews Changes to gh-pages can be previewed, by setting up the project in ReadTheDocs. It is recommended to use the following manual configuration: Initial setup: ```yml Name: LizardByte-gh-pages- # the project slug cannot be changed after creation Repository URL: https://github.com/LizardByte/.git Default-branch: master Language: English ``` Project Settings: ```yml Connected-repository: https://github.com/LizardByte/.git URL-versioning-scheme: Multiple versions without translations Path-for-.readthedocs.yaml: # only set if not in the root of the repo Programming-Language: Other Project-homepage: https://app.lizardbyte.dev/ Build-pull-requests-for-this-project: true ``` Environment Variables: ```yml # REQUIRED GITHUB_WORKFLOW: call-jekyll-build / Build Jekyll SITE_ARTIFACT: prep.zip # the name of the artifact to look for in the workflow # OPTIONAL CONFIG_FILE: _config.yml EXTRACT_ARCHIVE: pre_built_database.zip # if there is a nested archive to extract GITHUB_TIMEOUT: 10 # timeout in minutes to use when searching for GitHub artifacts, max 15 THEME_REF: master ``` Additionally, do the following: 1. Deactivate the `stable` version 2. Make the `latest` version hidden 3. Update branch protection rules in GitHub repo settings to require status checks from ReadTheDocs 4. Add the below `.readthedocs.yaml` file to the root of the repo, or a custom path as specified in the project settings ```yml --- # Read the Docs configuration file # See https://docs.readthedocs.io/en/stable/config-file/v2.html for details version: 2 build: os: ubuntu-24.04 tools: ruby: "3.3" apt_packages: - 7zip - jq jobs: install: - | mkdir -p "./tmp" branch="master" base_url="https://raw.githubusercontent.com/LizardByte/LizardByte.github.io" url="${base_url}/refs/heads/${branch}/scripts/readthedocs_build.sh" curl -sSL -o "./tmp/readthedocs_build.sh" "${url}" chmod +x "./tmp/readthedocs_build.sh" build: html: - "./tmp/readthedocs_build.sh" ``` --- ## File: _posts/guides/1970-01-01-blog-guide.md --- layout: post title: Blog Guide gh-repo: LizardByte/LizardByte.github.io gh-badge: [follow, star] readtime: true tags: [] comments: false simple-tabs-example: - name: 'Tab A' content: 'Content of tab A' - name: 'Tab B' content: 'Content of tab B' indexed-tabs-example: - name: 'cURL' content: - | ```bash curl -L https://example.com ``` - | ```bash curl -L https://google.com ``` - name: 'Python' content: - | ```python import requests response = requests.get('https://example.com') print(response.text) ``` - | ```python import requests response = requests.get('https://google.com') print(response.text) ``` --- ## Admonitions ### Usage You can use admonitions with the following syntax: ```markdown {% raw %} {% include admonition.html type="important" body="This is information intended to draw attention." %} {% endraw %} ``` Optionally, a custom title can be added: ```markdown {% raw %} {% include admonition.html type="hint" title="Custom Title" body="This is information intended to draw attention." %} {% endraw %} ``` ### Types Valid types of admonitions are: - `attention` - `caution` - `danger` - `error` - `hint` - `important` - `note` - `seealso` - `tip` - `todo` - `warning` ### Examples {% include admonition.html type="attention" body="This is information intended to draw attention." %} {% include admonition.html type="caution" body="This is information intended to draw attention." %} {% include admonition.html type="danger" body="This is information intended to draw attention." %} {% include admonition.html type="error" body="This is information intended to draw attention." %} {% include admonition.html type="hint" body="This is information intended to draw attention." %} {% include admonition.html type="important" body="This is information intended to draw attention." %} {% include admonition.html type="note" body="This is information intended to draw attention." %} {% include admonition.html type="seealso" body="This is information intended to draw attention." %} {% include admonition.html type="tip" body="This is information intended to draw attention." %} {% include admonition.html type="todo" body="This is information intended to draw attention." %} {% include admonition.html type="warning" body="This is information intended to draw attention." %} ## Simple-Tabs ### Usage You can use simple tabs with the following syntax: ```markdown {% raw %} {% include tabs.html tabs=page.simple-tabs-example %} {% endraw %} ``` The tabs object must have a `name` and `content` field. The `content` field should be a string when using simple tabs. ### Example {% include tabs.html tabs=page.simple-tabs-example %} ## Indexed-Tabs ### Usage You can use indexed tabs with the following syntax: ```markdown {% raw %} {% include tabs.html tabs=page.indexed-tabs-examples index=0 %} {% endraw %} ``` The tabs object must have a `name` and `content` field. The `content` field should be an array of strings when using indexed tabs. ### Examples #### Index 0 {% include tabs.html tabs=page.indexed-tabs-example index=0 %} #### Index 1 {% include tabs.html tabs=page.indexed-tabs-example index=1 %} --- ## File: _posts/guides/2024-02-01-multi-platform-cpp-development-in-clion.md --- layout: post title: Multi-platform C++ development in CLion subtitle: How to set up CLion to handle Linux, macOS, and Windows development in a single project gh-repo: LizardByte/LizardByte.github.io gh-badge: [follow, star] readtime: true tags: [clion, c++, cpp, cmake, dev, guide, linux, macos, windows] thumbnail-img: /assets/img/thumbnails/clion.png comments: true authors: - github: ReenigneArcher --- ## Introduction When developing multiplatform C++ projects, it can be frustrating to have to switch between different systems to develop, inspect, and test your code. This is especially true when you are working on a project that has dependencies. Without the proper setup, you may find your IDE complaining about missing headers, libraries, etc. This example shows 975 problems in this single file. In this post, I will show you how to set up CLion to handle Linux, macOS, and Windows development in a single project, and from a single system. ## Prerequisites - CLion - Method(s) of Virtualization (Docker, WSL, or virtual machine) ## Setting up the remote environment ### Docker 1. Create a `Dockerfile` in your project, ensuring that all the project build dependencies are installed. Below is an example. ```Dockerfile FROM ubuntu:22.04 RUN DEBIAN_FRONTEND="noninteractive" apt-get update && apt-get -y install tzdata RUN apt-get update \ && apt-get install -y build-essential \ gcc \ g++ \ gdb \ clang \ make \ ninja-build \ cmake \ autoconf \ automake \ libtool \ valgrind \ locales-all \ dos2unix \ rsync \ tar \ python \ python-dev \ && apt-get clean ``` 2. Right-click on the `Dockerfile` and select `Modify Run Configuration`. 3. Set an image tag and container name. Optionally, enable BuildKit and set a context folder, depending on the content of your `Dockerfile`. 4. Right-click on the `Dockerfile` and select `Run ''`. ### WSL 1. Follow the [how to install Linux on Windows with WSL](https://learn.microsoft.com/en-us/windows/wsl/install) instructions. 2. Install the necessary build tools and dependencies according to the Linux distribution you have chosen. ### Virtual machines Due to the variety of hypervisors available, I will not go into detail on how to set up a virtual machine. The general idea is to install the OS of your choice, enable SSH, and install the necessary build tools and dependencies. Installing Linux and Windows virtual machines is generally straightforward. Installing a macOS virtual machine is more complicated. Therefore, I've decided to leave a link to the guide I used on how to set it up inside Proxmox. [installing macos 13 ventura on proxmox](https://www.nicksherlock.com/2022/10/installing-macos-13-ventura-on-proxmox/) ## Setting up CLion ### Add SSH configurations 1. Open CLion and go to `File` -> `Settings` -> `Tools` -> `SSH Configurations`. 2. Click the `+` button and add the SSH configurations for the remote environment(s). ### Adding toolchains 1. Open CLion and go to `File` -> `Settings` -> `Build, Execution, Deployment` -> `Toolchains`. 2. Click the `+` button and select the toolchain you want to add. #### Docker #### WSL #### SSH ### Adding CMake profiles 1. Open CLion and go to `File` -> `Settings` -> `Build, Execution, Deployment` -> `CMake`. 2. Click the `+` button and select the CMake profile you want to add. ## Update project The last step is to reload the project. 1. Open the CMake tab and click the reload button. Depending on the project and remote environment(s), this may take some time. However, once it is finished, you should be able to build, run, and debug your project on all the remote environments simultaneously. The number of problems detected by CLion was reduced from 975 to 367. ## Conclusion In this post, I showed you how to set up CLion to handle Linux, macOS, and Windows development in a single project, all from a single system. Hopefully, this will help you to be more productive and efficient when developing your C++ projects. --- ## File: _posts/guides/2024-12-08-git-commit-signing-in-windows.md --- layout: post title: Signing Git Commits in Windows subtitle: How to sign your Git commits in Windows using GPG and Kleopatra gh-repo: LizardByte/LizardByte.github.io gh-badge: [follow, star] readtime: true tags: [dev, git, github, guide, windows] comments: true authors: - github: ReenigneArcher --- ## Introduction Have you ever wanted to sign your Git commits, and get the fancy `Verified` badge on your commits in GitHub? This post will show you how to sign your Git commits in Windows using GPG and Kleopatra. ## Prerequisites 1. Download and install [Gpg4win](https://www.gpg4win.org/), ensuring that Kleopatra option is selected. ## Create new OpenPGP certificate 1. Open Kleopatra and select "New Key Pair" 2. Enter your GitHub username and email. The email must be one you have assigned to your GitHub account. You can find your no-reply email https://github.com/settings/emails on this page if you have one set. 3. Optionally, expand "Advanced Options" and change the "Key Material" option. I used "rsa4096". You can also change or disable the expiration date. 4. Select "OK". ## Configure git 1. Open terminal (cmd.exe or PowerShell) and run the following command. ```bash gpg --list-secret-keys --keyid-format LONG ``` 2. Copy the key id. `1234567890ABCDEF` is the id in the example below. ``` sec rsa4096/1234567890ABCDEF 2024-12-08 [SC] ABCDEF1234567890ABCDEFGH1234567890ABCDEF uid [ultimate] GitHub-Username ssb rsa4096/0987654321FEDCBA 2024-12-08 [E] ``` 3. Run the following command to configure git to use the key. ```bash git config --global user.signingkey ``` 4. If git cannot find gpg you may need to add the path to the gpg executable to your git configuration. You can find the path to gpg by running the following command. ```bash where gpg ``` Then add the path to your git configuration. ```bash git config --global gpg.program "C:\Program Files (x86)\GnuPG\bin\gpg.exe" ``` 5. Run the following command to enable commit signing. ```bash git config --global commit.gpgsign true ``` ## Configure GitHub 1. Right-click the key in Kleopatra, select "Details", then "Export". Select all the contents and copy them. 2. Go to your GitHub account settings, and select "SSH and GPG keys". 3. Click "New GPG key". Give the key a title, and paste the contents of the public key into the key field. 4. Click "Add GPG key". ## Automatically start Kleopatra 1. Open the Windows Task Scheduler. 2. Optionally, create a new folder for the task. 3. Select the folder, and then click "Create Task". 4. Enter a name for the task, such as "Open Kleopatra". 5. Select "Run only when user is logged on". 6. Click the "Triggers" tab, then "New". 7. Select "At log on" from the "Begin the task" dropdown. 8. Select "Specific user", and click "OK". 9. Click the "Actions" tab, then "New". 10. Click "Browse", and select the Kleopatra executable. The default location is `"C:\Program Files (x86)\Gpg4win\bin\kleopatra.exe"` 11. In the "Start in" field, enter `%HOMEDRIVE%%HOMEPATH%`, and click "OK". 12. On the "Conditions" tab, uncheck everything. 13. On the settings tab, ensure the following options are set. - Allow task to be run on demand (checked) - Run task as soon as possible after a scheduled start is missed (checked) - If the task fails, restart every 1 minute (checked) - Attempt to restart up to 3 times - Stop the task if it runs longer than (unchecked) - If the running task does not end when requested, force it to stop (checked) - If the task is not scheduled to run again, delete it after (unchecked) - If the task is already running, then the following rule applies (Do not start a new instance) 14. Click "OK". ## Revoking a Key In some cases you may need to revoke a key. To do this follow the steps below. 1. Open Kleopatra, right-click on the key, and select "Revoke Certificate". 2. Select the reason for revoking the key, and click "Revoke Certificate". 3. Right-click the key again, select "Details", then "Export". Select all the contents and copy them. 4. Go to your GitHub account settings, and select "SSH and GPG keys". 5. Remove the old key, and click "New GPG key". Give the key a title (such as "Revoked Key"), and paste the contents of the public key into the key field. Alternatively, this can be done via command line. See [How to actually revoke a GitHub GPG key](https://github.com/orgs/community/discussions/108355#discussioncomment-8476035) This approach will allow previously verified commits to remain verified. ## Caveats - Commits made before your key was created cannot be verified, even if you amend the commits. This can be annoying if you have any WIP commits that you want to amend. A simple workaround for this is to start an interactive rebase, and edit each commit to adjust. Finally, when you amend the commit do so with the following command. ```bash git commit --amend --date=now --no-edit ``` ## Conclusion You should now be able to sign your Git commits in Windows using GPG and Kleopatra. I'd like to give credit to Tom Auger for his [blog post](https://tau.gr/posts/2018-06-29-how-to-set-up-signing-commits-with-git/) which helped me figure out how to do this initially.