llvm_11: patch to recognize Genode platform triples

Motivation for this change
Genode is a low-tier platform in Nixpkgs. This PR would make it possible to combine the standard Nixpkgs LLVM with a custom Clang and runtime libraries to build a Genode stdenv.
This is a low-priority patch and should only be merged if LLVM is going to be rebuilt anyway.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip" (some pkgs tested, not all)
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

This is a low-priority patch and should only be merged if LLVM is going to be rebuilt anyway.

Staging usually rebuilds stdenv anyway so as long as it does not break things it can be safely merged.

Shit, I pushed my staging to origin when it should have been my fork.

Well I can't reopen this PR now because the changes are already on staging, even if they sit ahead of a revert commit.

Shit, I pushed my staging to origin when it should have been my fork.

Thanks for the honesty and swift response! Such things can unfortunately happen very easily. But given that it wasn't a force-push and you've already reverted it everything should be fine now :)
(Btw: If you don't need to push directly to Nixpkgs you could e.g. use git remote set-url --push origin to set the push URL to your fork. There are also other tricks.)

Well I can't reopen this PR now because the changes are already on staging, even if they sit ahead of a revert commit.

The commit in ehmry:staging needs a new ID/hash now. You could e.g. cherry-pick your original commit (9ddb9c0021ede97e981c3dee2250bbd1abc50c6f) onto the current NixOS:staging or revert 35e12d8343f560c7498032ab34a8729cbd6857e3 in ehmry:staging. Then it should work again.

Btw: If you don't need to push directly to Nixpkgs you could e.g. use git remote set-url --push origin to set the push URL to your fork

If you create you branches from upstream that does not work. Happened to me the last week but thankfully I have a wrapper around git push -f that replaces it with --force-with-lease.

If you create you branches from upstream that does not work.

Why? I think you used something else (in this case the remote named origin points to the upstream repository). If Git doesn't know a URL to push directly to Nixpkgs then there should be no way you'll accidentally push to it (in theory external tools could do strange things and you could have scripts/aliases that provide the URL directly but these would be super uncommon edge-cases). And --force-with-lease wouldn't've changed anything here (it only reduces the risks of using --force a bit).

git checkout -b X upstream/master points for me to this repository and pushes to upstream.

See #112990

git checkout -b X upstream/master points for me to this repository and pushes to upstream.

@SuperSandro2000 yeah, this is expected and that's exactly why it works! You're starting to drive me crazy thb... (excuse my directness but this is getting very annoying for me)
Here is proof for you that this does work (feel free to try to reproduce it):
$ git clone --depth=1 --sparse  https://github.com/NixOS/nixpkgs.git
Cloning into 'nixpkgs'...
remote: Enumerating objects: 40119, done.
remote: Counting objects: 100% (40119/40119), done.
remote: Compressing objects: 100% (26840/26840), done.
remote: Total 40119 (delta 916), reused 27151 (delta 566), pack-reused 0
Receiving objects: 100% (40119/40119), 25.97 MiB | 10.40 MiB/s, done.
Resolving deltas: 100% (916/916), done.

$ cd nixpkgs/

$ git remote rename origin upstream

$ git remote -v
upstream        https://github.com/NixOS/nixpkgs.git (fetch)
upstream        https://github.com/NixOS/nixpkgs.git (push)

$ git remote set-url --push upstream https://github.com/SuperSandro2000/nixpkgs.git

$ git remote -v
upstream        https://github.com/NixOS/nixpkgs.git (fetch)
upstream        https://github.com/SuperSandro2000/nixpkgs.git (push)

$ git checkout -b X upstream/master
Branch 'X' set up to track remote branch 'master' from 'upstream'.
Switched to a new branch 'X'

$ git status
On branch X
Your branch is up to date with 'upstream/master'.

nothing to commit, working tree clean

$ git commit --allow-empty -m test
[X 82e032ba] test

$ git push upstream HEAD:master
Username for 'https://github.com': X
Password for<EMAIL_ADDRESS>remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/SuperSandro2000/nixpkgs.git/'

As you can clearly see Git attempted to push to https://github.com/SuperSandro2000/nixpkgs.git/ and NOT https://github.com/NixOS/nixpkgs.git.
Please show me a reproducible (and realistic) case where this doesn't work or I take it as an acknowledgement that it does work.
Thanks!

git remote set-url --push upstream https://github.com/SuperSandro2000/nixpkgs.git

I didn't know you can do that. I just always have two remotes and my git config is set up that I always push to the current branch to make first time pushes easier.


feat[music]: immersive mode

Yet another answer to the "floating window occupying the bottom right space" problem.

[x] Support for mobile devices

[x] Toggle between floating and immersive mode

[x] Find a way to switch mode without rebuilding DOM (= without using two portals)

All elements have moved down?

@stu43005 :Pekora_Yabai:
I'll fix it

Small bug: remove the bump down when the content is backgrounded. Otherwise LGTM!

I would prefer to leave it as it is for desktop only, because that space makes the background pv look better and enjoyable.
For the mobile version, the bump is sure unnecessary thing.


Update Streamable.lua

export type x = typeof(x.new()) doesn't actually call x.new(), this is tested using:
local Object = {}
Object.__index = Object

function Object.new()
	print("Object.new")
	return setmetatable({}, Object)
end

export type Object = typeof(Object.new())
return Object

Ah interesting, good to know. Thanks!


Dependency Workflow: File issue on failure

We should add a step to the new dependency workflow (implementation/.github/workflows/update-dependencies-from-metadata.yml) that files an issue on the repository when it fails, as we have done in other workflows.
This will help maintainers become aware when dependency updates fail.

this is done


Versioning and Tests

Since you mentioned you are working on a significant new feature branch, I thought I would bring up some nice-to-haves. You have no doubt thought of many or all of them already, so this issue is more to get an idea of what your plans are.
Versioning
I hope you will label a version before merging a major new feature branch. It makes it easier for outside projects to reference the project with a submodule. Some projects use tags, others use branches, and some use both. I have found version branches to be particularly helpful because it is easy to find them, especially in a git GUI frontend.
At some point it may become necessary to drop support for C++17. Or it may be that you would like to refactor for C++23 eventually and drop C++20. All of this can be easily controlled and documented with version branches.
Tests
I did not run the tests yesterday on C++17, because there is no build script for them. I'm guessing you may have one privately. It might be nice to have a test script in the repo that builds and runs the test on any supported C++.
It might also be nice to set up a GitHub Action that builds and runs the tests on every PR to master. This is something I might be able to contribute if you are interested.

Regarding versioning, I have seen that being done but I have never been doing that. The current master could be called version 0.1 or something.
Regarding tests, this CMake script should work:
cmake_minimum_required(VERSION 3.5)

project(EzGz LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

add_executable(ezgz_test ezgz_test.cpp)
add_executable(ezgz_decompress ezgz_decompress.cpp)

target_compile_options(ezgz_test PRIVATE "-g")
target_compile_options(ezgz_test PRIVATE -Wall -Wextra -Wpedantic)

target_compile_options(ezgz_decompress PRIVATE "-g")
target_compile_options(ezgz_decompress PRIVATE -Wall -Wextra -Wpedantic)

set(THREADS_PREFER_PTHREAD_FLAG ON)
find_package(Threads REQUIRED)
target_link_libraries(ezgz_test PRIVATE Threads::Threads)
target_link_libraries(ezgz_decompress PRIVATE Threads::Threads)

I have no idea how to set up GitHub Actions. If you know how to do it, I would gladly accept your help.

How would you feel about moving the tests into a subfolder? I think it might be cleaner and underscore the fact that the only thing one needs is the header.

I'm hitting a snag, which is that ezgz_test.cpp contains a bug on line 199 when it calls reader.getBits(29). That value (29) causes an index-out-of-bounds assert on line 412 of ezgz.hpp:
result &= upperRemovals[amount];

It's weird that neither Clang nor GCC care about this, but MSVC sure does. I added an explicit assert bounds check (as a test) in ezgz, and that fails on Clang (and presumably GCC as well).
Meanwhile, MSVC is reporting lots of lint that the other compilers don't, so I am going to work on a delint PR.

Okay, I have the GitHub workflow ready to go. It builds and runs ezgz_test on unbuntu, macos, and windows for both C++17 and C++20 (a total of 6 jobs). The bug I discovered only manifests in the Debug build on Windows, so by using Release config it will allow the workflow to complete without errors.
Before I can create a PR I need decisions on

Whether and/or how much of #8 you want to include.
Whether to put the tests (along with the CMakeLists.txt file) in a subdirectory.

It's possible that the out of bounds read is an actual bug. I haven't seen any warnings even when using valgrind, so I a not sure why it suddenly starts happening.
By the way, MSVC does bound checking for all containers in debug mode while Clang and GCC don't. This is a double edged blade since it also makes it slower and triggers false positives in case the value is used only to obtain a behind-the-end pointer.

I'm almost certain the out of bounds read is an actual bug. You can make it happen every time by adding a bounds check assert right before line 412. The number passed in is 29, but the size of the array is something like 11.
FWIW I've made significant changes to the CMakeLists file, to accommodate different compilers with different options and the like for the GitHub action. I was going to include it with that PR. One of the main reasons I would like to put the tests in a subfolder is to but the CMakeLists file there. Having only exgz.hpp in the root folder underscores and reassures that it is truly a single header only.

All right, commit the CMakeFiles, I will include my changes into it.

I added CMakeLists and .gitignore to #8.


FancyZones does not respond on Virtual Desktop 2,3,... until recreated.

Microsoft PowerToys version
v0.35.0
Running as admin
Yes
Area(s) with issue?
FancyZones
Steps to reproduce

Add Virtual Desktop (2).
Switch back to Default desktop (1).
Update Powertoys to v0.35.0.
Configure FancyZones zones on Default Desktop (1).
Use FancyZones on Default Desktop (1). (Succes)
Switch to a preexisting Virtual Desktop (2).
Try to use FancyZones. (Fail) Nothing happens.  Even after reconfiguring FancyZones on Virtual desktop (2).
(Workaround) Delete and Recreate Virtual Desktop (2). (Succes.)  Now FancyZones works on all desktops as expected.

I don't know if a reboot would have fixed the problem without the need to recreate virtual desktops.
✔ Expected Behavior
Virtual desktops should not need to be recreated for FancyZones to activate and control the snap location of dragged windows.
❌ Actual Behavior
FancyZones did not activate and control the snap location of dragged windows on Virtual desktop 2.
Other Software
No response

@Michael-Daugherty we've done a few fixes, can you try out .47 and see if this is still an issue?


Add nats uploader

I would much rather the uploaders all be possible rather than an either or. Same for things like saving locally. Some people may want to do that for testing or for their own thing but while still contributing to the overall network.


Issue marked as unreleased but unable to locate closing commit in repo history

The bot commented "Issue marked as unreleased but unable to locate closing commit in repo history" on several of my closed issues.
At the time the issues were closed, the Insider's was based on the release branch, not main, so it's expected that they're marked unreleased, but I did not expect to see this comment.
https://github.com/microsoft/vscode/issues/215579#issuecomment-2260858173
https://github.com/microsoft/vscode/issues/213641#issuecomment-2260858376
https://github.com/microsoft/vscode/issues/223352#issuecomment-2260856613
https://github.com/microsoft/vscode/issues/223706#issuecomment-2260855013

@bpasero seeing this too