jiebi/CodeConvo huggingface dataset:
Change:
lib, stdenv, buildPythonPackage, <del> hypothesis, fetchPypi, setuptools, setuptools-scm, </del> <ins> fetchFromGitHub, </ins> cloudpickle, cython, <ins> hypothesis, </ins> jinja2, numpy, <ins> nvidia-ml-py, </ins> psutil, pynvml, <del> nvidia-ml-py, </del> pytestCheckHook, pythonOlder, rich, <ins> setuptools-scm, setuptools, </ins> }: <ins> let heap-layers-src = fetchFromGitHub { owner = "emeryberger"; repo = "heap-layers"; name = "Heap-Layers"; rev = "a2048eae91b531dc5d72be7a194e0b333c06bd4c"; sha256 = "sha256-vl3z30CBX7hav/DM/UE0EQ9lLxZF48tMJrYMXuSulyA="; }; printf-src = fetchFromGitHub { owner = "mpaland"; repo = "printf"; name = "printf"; rev = "v4.0.0"; sha256 = "sha256-tgLJNJw/dJGQMwCmfkWNBvHB76xZVyyfVVplq7aSJnI="; }; in </ins> buildPythonPackage rec { pname = "scalene"; <del> version = "1.5.43.2"; </del> <ins> version = "1.5.44.1"; </ins> pyproject = true; disabled = pythonOlder "3.9"; <del> src = fetchPypi { inherit pname version; hash = "sha256-LtD7v3pLz4UCnh6xlhkPdcEjyu3mt+YQPYZ0nNCLuDw="; </del> <ins> src = fetchFromGitHub { owner = "plasma-umass"; repo = "scalene"; rev = "v${version}"; hash = "sha256-XMz+gwiNaKiKplD4kOE1yhcg+dkzjEdDYjW0JsDEMQE="; </ins> }; <ins> patches = [ ./01-manifest-no-git.patch ./02-pyproject-unpin-setuptools.patch ]; prePatch = '' cp -r ${heap-layers-src} vendor/Heap-Layers mkdir vendor/printf cp ${printf-src}/printf.c vendor/printf/printf.cpp cp -r ${printf-src}/* vendor/printf sed -i"" 's/^#define printf printf_///&/' vendor/printf/printf.h sed -i"" 's/^#define vsnprintf vsnprintf_///&/' vendor/printf/printf.h ''; </ins> nativeBuildInputs = [ cython setuptools

Discussion:
Steps to reproduce the behavior: python312Packages.scalene Per , this failure is intentional due to some behaviour changes in setuptools. I'm not completely familiar with the change or setuptools overall, but the gist seems to be that setuptools now "prefers installed dependencies over vendored ones", whatever that means in this case. fails on () Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
EDIT: Filed a PR to fix this in Scalene.
As soon as Emery has a fix on his end, we can bump the version number or apply the patch. Edit: Watch this PR
Updated in the original sources. We need Emery to cut a new release of Scalene as we're building from the published binary. (The scalene source build is complicated.)
FYI, I managed to make source builds work. That will make future bug responses quicker.
Change:
<del> { stdenv, lib, fetchFromGitHub, cmake, ninja, python , withGodef ? true, godef , withGotools? true, gotools , withTypescript ? true, typescript , abseil-cpp, boost, llvmPackages , fixDarwinDylibNames, Cocoa }: stdenv.mkDerivation { pname = "ycmd"; version = "unstable-2023-11-06"; disabled = !python.isPy3k; # required for third_party directory creation src = fetchFromGitHub { owner = "ycm-core"; repo = "ycmd"; rev = "0607eed2bc211f88f82657b7781f4fe66579855b"; hash = "sha256-SzEcMQ4lX7NL2/g9tuhA6CaZ8pX/DGs7Fla/gr+RcOU="; fetchSubmodules = true; }; nativeBuildInputs = [ cmake ninja ] ++ lib.optional stdenv.hostPlatform.isDarwin fixDarwinDylibNames; buildInputs = with python.pkgs; with llvmPackages; [ abseil-cpp boost libllvm.all libclang.all ] ++  [ jedi jedi-language-server pybind11 ] ++ lib.optional stdenv.isDarwin Cocoa; buildPhase = '' export EXTRA_CMAKE_ARGS="-DPATH_TO_LLVM_ROOT=${llvmPackages.libllvm} -DUSE_SYSTEM_ABSEIL=true" ${python.pythonOnBuildForHost.interpreter} build.py --system-libclang --clang-completer --ninja ''; dontConfigure = true; # remove the tests # # make __main__.py executable and add shebang # # copy over third-party libs # note: if we switch to using our packaged libs, we'll need to symlink them # into the same spots, as YouCompleteMe (the vim plugin) expects those paths # to be available # # symlink completion backends where ycmd expects them installPhase = '' rm -rf ycmd/tests chmod +x ycmd/__main__.py sed -i "1i #!${python.interpreter} " ycmd/__main__.py mkdir -p $out/lib/ycmd cp -r ycmd/ CORE_VERSION *.so* *.dylib* $out/lib/ycmd/ mkdir -p $out/bin ln -s $out/lib/ycmd/ycmd/__main__.py $out/bin/ycmd # Copy everything: the structure of third_party has been known to change. # When linking our own libraries below, do so with '-f' # to clobber anything we may have copied here. mkdir -p $out/lib/ycmd/third_party cp -r third_party/* $out/lib/ycmd/third_party/ '' + lib.optionalString withGodef '' TARGET=$out/lib/ycmd/third_party/godef mkdir -p $TARGET ln -sf ${godef}/bin/godef $TARGET '' + lib.optionalString withGotools '' TARGET=$out/lib/ycmd/third_party/go/src/golang.org/x/tools/cmd/gopls mkdir -p $TARGET ln -sf ${gotools}/bin/gopls $TARGET '' + lib.optionalString withTypescript '' TARGET=$out/lib/ycmd/third_party/tsserver ln -sf ${typescript} $TARGET ''; # fixup the argv[0] and replace __file__ with the corresponding path so # python won't be thrown off by argv[0] postFixup = '' substituteInPlace $out/lib/ycmd/ycmd/__main__.py  --replace __file__ "'$out/lib/ycmd/ycmd/__main__.py'" ''; meta = with lib; { description = "A code-completion and comprehension server"; mainProgram = "ycmd"; homepage = "https://github.com/ycm-core/ycmd"; license = licenses.gpl3; maintainers = with maintainers; [ rasendubi lnl7 siriobalmelli ]; platforms = platforms.all; }; } </del>

Discussion:
Steps to reproduce the behavior: Running in a development shell yields a better error message: I will submit a PR to fix this myself. Will do on the PR. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
# See: https://github.com/NixOS/nixpkgs/pull/122023 export LC_ALL=C.UTF-8 <ins> config_dir=pkgs/development/haskell-modules/configuration-hackage2nix echo "Obtaining Hackage data" </ins> extraction_derivation='with import ./. {}; runCommandLocal "unpacked-cabal-hashes" { } "tar xf ${all-cabal-hashes} --strip-components=1 --one-top-level=$out"' unpacked_hackage="$(nix-build -E "$extraction_derivation" --no-out-link)" <del> config_dir=pkgs/development/haskell-modules/configuration-hackage2nix </del> <ins> echo "Generating compiler configuration" compiler_config="$(nix-build -A haskellPackages.cabal2nix-unstable.compilerConfig --no-out-link)" </ins> echo "Starting hackage2nix to regenerate pkgs/development/haskell-modules/hackage-packages.nix ..." "$HACKAGE2NIX"  --hackage "$unpacked_hackage"  --preferred-versions <(for n in "$unpacked_hackage"/*/preferred-versions; do cat "$n"; echo; done)  --nixpkgs "$PWD"  <ins> --config "$compiler_config"  </ins> --config "$config_dir/main.yaml"  --config "$config_dir/stackage.yaml"  --config "$config_dir/broken.yaml" 

Discussion:
The values of these options can easily be determined using and , so it should be very easy to just remove this part of the configuration from and generate it on demand in .
Change:
install -Dm444 -t $udev/etc/udev/rules.d rules.d-uinput/*.rules ''; <ins> dontWrapGApps = true; preFixup = '' makeWrapperArgs+=("''${gappsWrapperArgs[@]}") ''; # no tests doCheck = false; pythonImportsCheck = [ "solaar" ]; </ins> meta = with lib; { description = "Linux devices manager for the Logitech Unifying Receiver"; longDescription = ''

Discussion:
If I try to run Solaar via Rofi nothing happens, when trying it via terminal the following error occurred: If I open a nix-shell with and run solaar it opens and works without issues. Relevant configuration: Steps to reproduce the behavior: system from unstable to run solaar Solaar GUI main windows opens I've tried to find out more and was directed from that it could be related to missing but regardless where I it it didn't solve the issue. Please run and paste the result. nixos-unstable -
see
Thanks :)
Change:
<ins> { lib, stdenv, fetchFromGitLab, makeWrapper, coreutils, findutils, gnugrep, jre, openssl, util-linux, wget, which, zenity, libGL, libpulseaudio, nix-update-script, }: stdenv.mkDerivation (finalAttrs: { pname = "pokemmo-installer"; version = "1.4.8"; src = fetchFromGitLab { owner = "coringao"; repo = "pokemmo-installer"; rev = "refs/tags/${finalAttrs.version}"; hash = "sha256-uSbnXBpkeGM9X6DU7AikT7hG/emu67PXuGdm6xfB8To="; }; nativeBuildInputs = [ makeWrapper ]; installFlags = [ "PREFIX=${placeholder "out"}" # BINDIR defaults to $(PREFIX)/games "BINDIR=${placeholder "out"}/bin" ]; postFixup = '' wrapProgram "$out/bin/pokemmo-installer"  --prefix PATH : ${ lib.makeBinPath [ coreutils findutils gnugrep jre openssl util-linux wget which zenity ] }  --prefix LD_LIBRARY_PATH : ${ lib.makeLibraryPath [ libGL libpulseaudio ] } ''; passthru.updateScript = nix-update-script { }; meta = with lib; { description = "Installer and Launcher for the PokeMMO emulator"; homepage = "https://pokemmo.eu"; license = licenses.gpl3Only; maintainers = with maintainers; [ kira-bruneau ]; platforms = platforms.linux; mainProgram = "pokemmo-installer"; }; }) </ins>

Discussion:
Project description: PokeMMO is a multiplayer online game where players can explore various regions from Pokémon games, battle with others, and trade Pokémon in a persistent online world. Metadata homepage URL: source URL: Closed source (can be downloaded from ) license: Proprietary platforms: linux, unix, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Oh I had this packaged a while ago in my NUR: , I'll open a PR for it!
Change:
construct pykeepass pyotp <del> ] ++ [ libpwquality # using the python bindings </del> <ins> libpwquality </ins> ]; <del> postPatch = '' substituteInPlace meson_post_install.py --replace "gtk-update-icon-cache" "gtk4-update-icon-cache"; ''; </del> # Prevent double wrapping, let the Python wrapper use the args in preFixup. dontWrapGApps = true;

Discussion:
When trying to start gnome-secrets it fails with the message: Steps to reproduce the behavior: -shell -p gnome-secrets --run "secrets" Please run and paste the result.
Also gnome-secrets 6.4 is available. Updating it to the latest version doesn't solve the issue :(
Fixed by
Thank you for your work!
Change:
<del> { stdenv, fetchurl, unzip, sqlite, makeWrapper, mono54, ffmpeg }: </del> <ins> { stdenv, fetchurl, unzip, sqlite, makeWrapper, dotnet-sdk, ffmpeg }: </ins> stdenv.mkDerivation rec { name = "emby-${version}"; <del> version = "3.5.2.0"; </del> <ins> version = "3.5.3.0"; </ins> # We are fetching a binary here, however, a source build is possible. # See -> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=emby-server-git#n43

Discussion:
The latest version of Emby is only available in the dotnet core version : I can't find any documentation on how to package a dotnet app in NixOS. Help would be much appreciated ! I found that the dotnet-sdk package is providing the dotnet executable, is it a simple swap between mono and this ?
I am interested in using dotnet with nixpkgs. The dotnet-sdk is up to date and can build and run applications but there is also , which is just the runtime. It might be a good practice to use dotnet-sdk for building but build the wrapper with coreclr. This should result in smaller runtime closures. There is also which is actually using mono.
Change:
# Upstream PR: https://gitlab.freedesktop.org/cairo/cairo/-/issues/420 (fetchpatch { url = "https://gitlab.freedesktop.org/cairo/cairo/-/commit/e22d7212acb454daccc088619ee147af03883974.diff"; <del> sha256 = "sha256-8G98nsPz3MLEWPDX9F0jKgXC4hC4NNdFQLSpmW3ay2s="; </del> <ins> hash = "sha256-8G98nsPz3MLEWPDX9F0jKgXC4hC4NNdFQLSpmW3ay2s="; </ins> }) # Fix clang build failures on newer LLVM versions

Discussion:
Steps to reproduce the behavior: (My is rooted at so it cannot use prebuilt binaries.) Relevant excerpt: The URL of CVE-2020- is now dead. See Added by in Please run and paste the result.
Change:
let <del> fontDirs = config.fonts.fonts; localDefs = with pkgs.builderDefs; pkgs.builderDefs.passthru.function rec { src = "";/* put a fetchurl here */ buildInputs = [pkgs.xorg.mkfontdir pkgs.xorg.mkfontscale]; inherit fontDirs; installPhase = fullDepEntry (" list=''; for i in ${toString fontDirs} ; do if [ -d $i/ ]; then list="$list $i"; fi; done list=$(find $list -name fonts.dir -o -name '*.ttf' -o -name '*.otf'); fontDirs=''; for i in $list ; do fontDirs="$fontDirs $(dirname $i)"; done; mkdir -p $out/share/X11-fonts/; find $fontDirs -type f -o -type l | while read i; do j="${i##*/}" if ! test -e "$out/share/X11-fonts/${j}"; then ln -s "$i" "$out/share/X11-fonts/${j}"; fi; done; cd $out/share/X11-fonts/ rm fonts.dir rm fonts.scale rm fonts.alias mkfontdir mkfontscale cat $( find ${pkgs.xorg.fontalias}/ -name fonts.alias) >fonts.alias ") ["minInit" "addInputs"]; }; x11Fonts = with localDefs; stdenv.mkDerivation rec { name = "X11-fonts"; builder = writeScript (name + "-builder") (textClosure localDefs [installPhase doForceShare doPropagate]); }; </del> <ins> x11Fonts = pkgs.runCommand "X11-fonts" { } '' mkdir -p "$out/share/X11-fonts" find ${toString config.fonts.fonts}  ( -name fonts.dir -o -name '*.ttf' -o -name '*.otf' )  -exec ln -sf -t "$out/share/X11-fonts" '{}' ; cd "$out/share/X11-fonts" rm -f fonts.dir fonts.scale fonts.alias ${pkgs.xorg.mkfontdir}/bin/mkfontdir ${pkgs.xorg.mkfontscale}/bin/mkfontscale cat $(find ${pkgs.xorg.fontalias}/ -name fonts.alias) >fonts.alias ''; </ins> in

Discussion:
The documentation for states that setting the option to should cause a directory of fonts to be generated. However, this option is set on my system, but the system does not have a fonts directory: Enable in . Rebuild system. Observe lack of directory.System: (NixOS: , Ubuntu/Fedora: , ...) [twey nixos-version 16.09pre82105. (Flounder) Nix version: (run ) [twey nix-env --version nix-env (Nix) 1.11.2 Nixpkgs version: (run ) [twey nix-instantiate --eval '<nixpkgs' -A lib.nixpkgsVersion "16.09pre82105."
I can reproduce the issue
:+1:, same here, for a loooong time now (sorry for not reporting earlier).
BTW, what's this option good for?
It gives a place to point applications that want to know about fonts (e.g. LuaTeX). On 7 May 2016 11:20, Vladimír Čunát wrote:BTW, what's this option good for? —You are receiving this because you authored the thread.Reply to this email directly or view it on GitHub
I assumed everything uses fontconfig nowadays, but there may be some exceptions...
Could you please write this in (and not in as you said in the issue description)? Do you have the directory now?
I have this in and no directory.
I believe this is fixed by I don't use nor really care about this feature, though, so I have no idea whether linking into really does anything useful ...
Change:
enableParallelBuilding=true; buildFlags = [ "magma" "magma_sparse" ]; <del> # MAGMA's default CMake setup does not care about installation. So we copy files directly. installPhase = '' mkdir -p $out mkdir -p $out/include mkdir -p $out/lib mkdir -p $out/lib/pkgconfig cp -a ../include/*.h $out/include #cp -a sparse-iter/include/*.h $out/include cp -a lib/*.so $out/lib cat ../lib/pkgconfig/magma.pc.in                   |  sed -e s:@INSTALL_PREFIX@:"$out":          |  sed -e s:@CFLAGS@:"-I$out/include":    |  sed -e s:@LIBS@:"-L$out/lib -lmagma -lmagma_sparse": |  sed -e s:@MAGMA_REQUIRED@::                        > $out/lib/pkgconfig/magma.pc ''; </del> meta = with lib; { description = "Matrix Algebra on GPU and Multicore Architectures"; license = licenses.bsd3;

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking . python3Packages.pytorchWithCuda maintainers cc: magma maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
This looks like another gcc11 failure. could you take a look?
Sure thing
Going to attempt to bump from 2.5.4 (2020) to 2.6.2 (2022)
Change:
, hyp2mat }: <del> stdenv.mkDerivation { </del> <ins> stdenv.mkDerivation rec { </ins> pname = "openems"; <del> version = "unstable-2020-02-15"; </del> <ins> version = "0.0.36"; </ins> src = fetchFromGitHub { owner = "thliebig"; repo = "openEMS"; <del> rev = "ba793ac84e2f78f254d6d690bb5a4c626326bbfd"; sha256 = "1dca6b6ccy771irxzsj075zvpa3dlzv4mjb8xyg9d889dqlgyl45"; </del> <ins> rev = "v${version}"; sha256 = "sha256-wdH+Zw7G2ZigzBMX8p3GKdFVx/AhbTNL+P3w+YjI/dc="; </ins> }; nativeBuildInputs = [

Discussion:
Package name: OpenEMS Latest released version: 0.0.36 <!-- Search your package here: --- Current version on the unstable channel: 2020-02-15 Current version on the stable/release channel: 2020-02-15 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR.
Change:
<del> { stdenv, fetchFromGitHub, fetchpatch, lib, enableUnfree ? false }: </del> <ins> { lib, stdenv, fetchFromGitHub, enableUnfree ? false }: </ins> <del> stdenv.mkDerivation rec { </del> <ins> stdenv.mkDerivation (finalAttrs: { </ins> pname = "p7zip"; <del> version = "17.04"; </del> <ins> version = "17.05"; </ins> src = fetchFromGitHub { <del> owner  = "jinfeihan57"; repo   = pname; rev    = "v${version}"; </del> <ins> owner = "p7zip-project"; repo = "p7zip"; rev = "v${finalAttrs.version}"; </ins> sha256 = { <del> free = "sha256-DrBuf2VPdcprHI6pMSmL7psm2ofOrUf0Oj0qwMjXzkk="; unfree = "sha256-19F4hPV0nKVuFZNbOcXrcA1uW6Y3HQolaHVIYXGmh18="; </del> <ins> free = "sha256-5r7M9BVcAryZNTkqJ/BfHnSSWov1PwoZhUnLBwEbJoA="; unfree = "sha256-z3qXgv/TkNRbb85Ew1OcJNxoyssfzHShc0b0/4NZOb0="; </ins> }.${if enableUnfree then "unfree" else "free"}; # remove the unRAR related code from the src drv # > the license requires that you agree to these use restrictions,

Discussion:
p7zip source is gone try to build without substituters cc
What commit are you having the issue from? it works for me at
Current master, that is sets to . There is no such tag at
Maybe the fork cleared the tags by force pushing?
Hmm, I wonder if all the changes got merged into with the fork then rebasing and force-pushing…
Yeah, looks like it. A bunch of jinfeihan57's commits are now in the commit history I'll change it to point back to p7zip-project's copy now
Change:
#!/usr/bin/env Rscript library(data.table) <ins> library(jsonlite) </ins> library(parallel) library(BiocManager) cl <- makeCluster(10)

Discussion:
relies on MRAN mirror, which at the end of this month. Could we switch to another mirror such as CRAN/posit package manager?
We do need to switch, not just the update script but currently CRAN packages are fetched from MRAN. Official CRAN mirrors would be preferable but the organisation is not ideal as the archive tarballs are at a different path to the latest release.
is a similar service. I'm not sure if it's equivalent to MRAN. or could work
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
sway-unwrapped.overrideAttrs (oldAttrs: rec { pname = "swayfx"; <del> version = "0.2"; </del> <ins> version = "0.3"; </ins> src = fetchFromGitHub { owner = "WillPower3309"; repo = "swayfx"; rev = version; <del> sha256 = "sha256-nVy7GdAnheWhjevcCPE407xWSLN8F4Le0uq2RDwv/Zc="; </del> <ins> sha256 = "sha256-3Odyeb10AGbNf6TI1W79sLiwB4PrszC5VzjCr7FuPz4="; </ins> }; <ins> # This patch was backported into SwayFX # remove when next release is rebased on Sway 1.9 patches = let removePatches = [ "LIBINPUT_CONFIG_ACCEL_PROFILE_CUSTOM.patch" ]; in builtins.filter (patch: !builtins.elem (patch.name or null) removePatches) (oldAttrs.patches or [ ]); </ins> meta = with lib; { <del> description = "A Beautiful Sway Fork"; </del> <ins> description = "Sway, but with eye candy!"; </ins> homepage = "https://github.com/WillPower3309/swayfx"; maintainers = with maintainers; [ ricarch97 ]; license = licenses.mit;

Discussion:
Package name: swayfx Latest released version: 0.3 <!-- Search your package here: --- Current version on the unstable channel: 0.2 Current version on the stable/release channel: not packaged <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR.
c.f.
Change:
<link xlink:href="https://github.com/NixOS/nixpkgs/issues/89205">#89205</link>. </para> </listitem> <ins> <listitem> <para> In the <literal>resilio</literal> module, <xref linkend="opt-services.resilio.httpListenAddr"/> has been changed to listen to <literal>[::1]</literal> instead of <literal>0.0.0.0</literal>. </para> </listitem> </ins> </itemizedlist> </section>

Discussion:
By default resilio listen to 0.0.0.0. I wanted to know if it would not be more reasonable to listen on 127.0.0.1 It is only an admin interface that has no influence on the other components of the application.
Perhaps. According to this article the application default is 127.0.0.1. On the other hand we have the firewall enabled by default.
ping
Yes. would be more sensible.
Change:
stdenv.mkDerivation rec { pname = "furnace"; <del> version = "0.6pre18"; </del> <ins> version = "0.6"; </ins> src = fetchFromGitHub { owner = "tildearrow"; repo = "furnace"; rev = "v${version}"; fetchSubmodules = true; <del> hash = "sha256-RLmXP/F3WnADx/NUPAJZpGSQZ7CGm1bG4UJYAcIeHME="; </del> <ins> hash = "sha256-8we7vKyGWjM9Rx0MJjSKLJcKBHiHt5vjuy17HHx/pP8="; </ins> }; postPatch = lib.optionalString stdenv.hostPlatform.isLinux ''

Discussion:
Package name: furnace Latest released version: 0.6 <!-- Search your package here: --- Current version on the unstable channel: 0.6pre18 Current version on the stable/release channel: 0.6pre7 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- For some reason this update did not add an automatic pull request... Now that the update spam is over, I wonder if it might be time to update the release channel as well. Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --PS: I am once again asking y'all to prepare an escape plan from github - what with repeated false bans, including some of our members, that are so strong they are more-or-less removed from history, and unnerving serves of direction form host to social to ai... can't trust this site. Note for maintainers: Please tag this issue in your PR.
Sounds interesting, link?
On-topic stuff: r-ryantm update PRs don't happen instantly, I'm not sure if the exact timing is documented anywhere. Still disagree with the idea. Our 23.11 release is , so that one will likely end up with a proper 0.6 release. If upstream doesn't do the same year-long, feature-packed pre-release hell again then I'd be fine with backporting patch releases with fixes onto 23.11. Off-topic stuff: Read for past stances & discussions about this, and where future discussions about this are supposed to be done. Only similar situation I can think of is volth, I'm not sure if that can be considered a false ban though? Unfortunate nonetheless though.
iirc joepie91 got this sledgehammer treatment. Here's a link to someone else who got dragged through hell: <hr/ don't worry, from what i hear 0.7 is going to be mostly minor patches and work for hardware export, so i doubt tildearrow will machine-gun prereleases for a while.