jiebi/CodeConvo huggingface dataset:
Code change:
The version of pillow rmfuse uses is vulnerable to CVE-2022-.
Since rmfuse is packaged using poetry2nix you are basically the only one willing to update it or its dependencies. That's problematic given that you don't do so even two weeks after being notified of a vulnerability.
I don't think interacting in this way is very constructive. There are different points of view regarding packaging Python packages, that's it. That an issue like this does not get picked up is not strange, people are typically busy. If you like to I suppose you could add the CVE to the expression. Whether the CVE can be considered a security issue in case of rmfuse should be considered as well.
Why not? I'm just articulating a problem with the way rmfuse is packaged right now that is obviously an actual problem. It's not technical though, just organizational.

Related discussion:
text: <del> [tool.poetry] name = "rmfuse-env" version = "0.1.0" description = "" authors = [] [tool.poetry.dependencies] python = "^3.8" rmfuse = {git = "https://github.com/rschroll/rmfuse.git", extras = ["pyfuse3"]} [tool.poetry.dev-dependencies] [build-system] requires = ["poetry-core>=1.0.0"] build-backend = "poetry.core.masonry.api" </del>
Code change:
The version of pillow rmfuse uses is vulnerable to CVE-2022-.
Since rmfuse is packaged using poetry2nix you are basically the only one willing to update it or its dependencies. That's problematic given that you don't do so even two weeks after being notified of a vulnerability.
I don't think interacting in this way is very constructive. There are different points of view regarding packaging Python packages, that's it. That an issue like this does not get picked up is not strange, people are typically busy. If you like to I suppose you could add the CVE to the expression. Whether the CVE can be considered a security issue in case of rmfuse should be considered as well.
Why not? I'm just articulating a problem with the way rmfuse is packaged right now that is obviously an actual problem. It's not technical though, just organizational.

Related discussion:
text: <del> #!/usr/bin/env nix-shell #! nix-shell -i bash -p poetry poetry2nix.cli set -eu poetry lock poetry2nix lock </del>
Code change:
Steps to reproduce the behavior: in nixos-unstable -note build will failed Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
You can override paper-note by adding the following section and it should work fine.

Related discussion:
text: gtksourceview5 ]; <ins> postPatch = '' substituteInPlace src/meson.build  --replace "1.2.0" "${libadwaita.version}" ''; </ins> postInstall = '' ln -s $out/bin/io.posidon.Paper $out/bin/paper '';
Code change:
Project description It would be nice to have libreoffice-still-qt, to have a stable version of libreoffice (still) with kde integration (qt). In my undestranding, so far we only have libreoffice-qt which is the fresh version cf.

Related discussion:
text: libreoffice = hiPrio libreoffice-still; <ins> libreoffice-qt = hiPrio libreoffice-qt-still; libreoffice-qt-unwrapped = libreoffice-qt.unwrapped; </ins> libreoffice-unwrapped = libreoffice.unwrapped; libreoffice-args = {
Code change:
Project description It would be nice to have libreoffice-still-qt, to have a stable version of libreoffice (still) with kde integration (qt). In my undestranding, so far we only have libreoffice-qt which is the fresh version cf.

Related discussion:
text: boost = boost179; }; <del> libreoffice-qt = lowPrio (callPackage ../applications/office/libreoffice/wrapper.nix { </del> <ins> libreoffice-qt-fresh = lowPrio (callPackage ../applications/office/libreoffice/wrapper.nix { </ins> unwrapped = libsForQt5.callPackage ../applications/office/libreoffice (libreoffice-args // { kdeIntegration = true; variant = "fresh"; }); }); <ins> libreoffice-qt-fresh-unwrapped = libreoffice-qt-fresh.unwrapped; libreoffice-qt-still = lowPrio (callPackage ../applications/office/libreoffice/wrapper.nix { unwrapped = libsForQt5.callPackage ../applications/office/libreoffice (libreoffice-args // { kdeIntegration = true; variant = "still"; }); }); libreoffice-qt-still-unwrapped = libreoffice-qt-still.unwrapped; </ins> libreoffice-fresh = lowPrio (callPackage ../applications/office/libreoffice/wrapper.nix { unwrapped = callPackage ../applications/office/libreoffice
Code change:
Project description Metadata homepage URL: source URL: license: SIL Open Font License 1.1 platforms: all

Related discussion:
text: <ins> { lib , stdenvNoCC , fetchurl , unzip }: stdenvNoCC.mkDerivation rec { pname = "roboto-serif"; version = "1.007"; src = fetchurl { url = "https://github.com/googlefonts/roboto-serif/releases/download/v${version}/RobotoSerifFonts-v${version}.zip"; hash = "sha256-A14GztkTvaLBvcm1i3A0Vi9vaz77nFYYoSNggqbffFo="; }; sourceRoot = "."; nativeBuildInputs = [ unzip ]; installPhase = '' runHook preInstall install -Dm644 variable/*.ttf -t $out/share/fonts/truetype runHook postInstall ''; meta = with lib; { description = "The Roboto family of fonts"; longDescription = '' Google’s signature family of fonts, the default font on Android and Chrome OS, and the recommended font for Google’s visual language, Material Design. ''; homepage = "https://github.com/googlefonts/roboto-serif"; license = licenses.ofl; maintainers = with maintainers; [ wegank ]; platforms = platforms.all; }; } </ins>
Code change:
Project description Metadata homepage URL: source URL: license: SIL Open Font License 1.1 platforms: all

Related discussion:
text: roboto-mono = callPackage ../data/fonts/roboto-mono { }; <ins> roboto-serif = callPackage ../data/fonts/roboto-serif { }; </ins> roboto-slab = callPackage ../data/fonts/roboto-slab { }; hasklig = callPackage ../data/fonts/hasklig {};
Code change:
gamescope crashes with this error when run from within steam's fhsenv: This check in wlroots causes that error because inside steam's fhsenv the /tmp/.X11-unix directory is owned by nobody:nogroup. I have tried simply removing the check from wlroots but in that case gamescope simply hangs. (Note that it's gamescope that depends on wlroots so this bug happens under x11 window managers too.) Steps to reproduce the behavior: steam to the launch options of any game the game
This seems to be a very old issue with NixOS
would allow to run with without having to manually chown /tmp/.X11-unix but running from within steam as described above is still broken. gamescope dies with this error: However : So that symbol is actually defined but Xwayland thinks it's not for some reason.
I've encountered this issue too! I know got gamescope to run on NixOS - maybe we're missing something? See my comment here: Related:
Hi, I just wanted to real quickly add some context with my knowledge of how Steam works. this part is not the issue and is an ""issue"" about the steam overlay, it happens because there is both a 32 bit and 64 bit version of the overlay both of which are loaded when you launch a 32bit or 64bit game, so this is not related. It happens every time you launch a game on any distro without fail since a game cannot both be 32 and 64 bit. ERROR: object '' from LDPRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. Everything else in this log seems normal, outside of this part: which could point to a missing library. the mentioned "" might be what we need to look at here. Also, thank you so much to for posting the workaround too, I was getting a headache dealing with this.
Hi, i wanted to ask if someone is working on this issue?
It's an open-source project, so unless someone with the necessary knowledge is interested in the issue (could be yourself), then you'll probably have to wait.
I ran into this same issue before. The only thing that let me run gamescope through steam so far has been the solution from , but I am not sure why it works.
I'm trying to add the patch in in , eagering for testing from you.
There seem to be multiple issues conflated here. The original issue with X11 socket ownership has been addressed. If there's another issue that prevents running gamescope in Steam, please report it separately.

Related discussion:
text: then [ package ] ++ extraPackages else [ package32 ] ++ extraPackages32; in prevLibs ++ additionalLibs; <ins> extraPkgs = p: (cfg.extraPackages ++ lib.optionals (prev ? extraPkgs) (prev.extraPkgs p)); </ins> } // lib.optionalAttrs (cfg.gamescopeSession.enable && gamescopeCfg.capSysNice) { buildFHSEnv = pkgs.buildFHSEnv.override {
Code change:
gamescope crashes with this error when run from within steam's fhsenv: This check in wlroots causes that error because inside steam's fhsenv the /tmp/.X11-unix directory is owned by nobody:nogroup. I have tried simply removing the check from wlroots but in that case gamescope simply hangs. (Note that it's gamescope that depends on wlroots so this bug happens under x11 window managers too.) Steps to reproduce the behavior: steam to the launch options of any game the game
This seems to be a very old issue with NixOS
would allow to run with without having to manually chown /tmp/.X11-unix but running from within steam as described above is still broken. gamescope dies with this error: However : So that symbol is actually defined but Xwayland thinks it's not for some reason.
I've encountered this issue too! I know got gamescope to run on NixOS - maybe we're missing something? See my comment here: Related:
Hi, I just wanted to real quickly add some context with my knowledge of how Steam works. this part is not the issue and is an ""issue"" about the steam overlay, it happens because there is both a 32 bit and 64 bit version of the overlay both of which are loaded when you launch a 32bit or 64bit game, so this is not related. It happens every time you launch a game on any distro without fail since a game cannot both be 32 and 64 bit. ERROR: object '' from LDPRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. Everything else in this log seems normal, outside of this part: which could point to a missing library. the mentioned "" might be what we need to look at here. Also, thank you so much to for posting the workaround too, I was getting a headache dealing with this.
Hi, i wanted to ask if someone is working on this issue?
It's an open-source project, so unless someone with the necessary knowledge is interested in the issue (could be yourself), then you'll probably have to wait.
I ran into this same issue before. The only thing that let me run gamescope through steam so far has been the solution from , but I am not sure why it works.
I'm trying to add the patch in in , eagering for testing from you.
There seem to be multiple issues conflated here. The original issue with X11 socket ownership has been addressed. If there's another issue that prevents running gamescope in Steam, please report it separately.

Related discussion:
text: ''; }; <ins> extraPackages = lib.mkOption { type = lib.types.listOf lib.types.package; default = [ ]; example = lib.literalExpression '' with pkgs; [ gamescope ] ''; description = '' Additional packages to add to the Steam environment. ''; }; </ins> extraCompatPackages = lib.mkOption { type = lib.types.listOf lib.types.package; default = [ ];
Code change:
gamescope crashes with this error when run from within steam's fhsenv: This check in wlroots causes that error because inside steam's fhsenv the /tmp/.X11-unix directory is owned by nobody:nogroup. I have tried simply removing the check from wlroots but in that case gamescope simply hangs. (Note that it's gamescope that depends on wlroots so this bug happens under x11 window managers too.) Steps to reproduce the behavior: steam to the launch options of any game the game
This seems to be a very old issue with NixOS
would allow to run with without having to manually chown /tmp/.X11-unix but running from within steam as described above is still broken. gamescope dies with this error: However : So that symbol is actually defined but Xwayland thinks it's not for some reason.
I've encountered this issue too! I know got gamescope to run on NixOS - maybe we're missing something? See my comment here: Related:
Hi, I just wanted to real quickly add some context with my knowledge of how Steam works. this part is not the issue and is an ""issue"" about the steam overlay, it happens because there is both a 32 bit and 64 bit version of the overlay both of which are loaded when you launch a 32bit or 64bit game, so this is not related. It happens every time you launch a game on any distro without fail since a game cannot both be 32 and 64 bit. ERROR: object '' from LDPRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. Everything else in this log seems normal, outside of this part: which could point to a missing library. the mentioned "" might be what we need to look at here. Also, thank you so much to for posting the workaround too, I was getting a headache dealing with this.
Hi, i wanted to ask if someone is working on this issue?
It's an open-source project, so unless someone with the necessary knowledge is interested in the issue (could be yourself), then you'll probably have to wait.
I ran into this same issue before. The only thing that let me run gamescope through steam so far has been the solution from , but I am not sure why it works.
I'm trying to add the patch in in , eagering for testing from you.
There seem to be multiple issues conflated here. The original issue with X11 socket ownership has been addressed. If there's another issue that prevents running gamescope in Steam, please report it separately.

Related discussion:
text: ''; }; <ins> fontPackages = lib.mkOption { type = lib.types.listOf lib.types.package; default = config.fonts.packages; defaultText = lib.literalExpression "fonts.packages"; example = lib.literalExpression "with pkgs; [ source-han-sans ]"; description = '' Font packages to use in Steam. Defaults to system fonts, but could be overridden to use other fonts — useful for users who would like to customize CJK fonts used in Steam. According to the [upstream issue](https://github.com/ValveSoftware/steam-for-linux/issues/10422#issuecomment-1944396010), Steam only follows the per-user fontconfig configuration. ''; }; </ins> remotePlay.openFirewall = lib.mkOption { type = lib.types.bool; default = false;
Code change:
gamescope crashes with this error when run from within steam's fhsenv: This check in wlroots causes that error because inside steam's fhsenv the /tmp/.X11-unix directory is owned by nobody:nogroup. I have tried simply removing the check from wlroots but in that case gamescope simply hangs. (Note that it's gamescope that depends on wlroots so this bug happens under x11 window managers too.) Steps to reproduce the behavior: steam to the launch options of any game the game
This seems to be a very old issue with NixOS
would allow to run with without having to manually chown /tmp/.X11-unix but running from within steam as described above is still broken. gamescope dies with this error: However : So that symbol is actually defined but Xwayland thinks it's not for some reason.
I've encountered this issue too! I know got gamescope to run on NixOS - maybe we're missing something? See my comment here: Related:
Hi, I just wanted to real quickly add some context with my knowledge of how Steam works. this part is not the issue and is an ""issue"" about the steam overlay, it happens because there is both a 32 bit and 64 bit version of the overlay both of which are loaded when you launch a 32bit or 64bit game, so this is not related. It happens every time you launch a game on any distro without fail since a game cannot both be 32 and 64 bit. ERROR: object '' from LDPRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. Everything else in this log seems normal, outside of this part: which could point to a missing library. the mentioned "" might be what we need to look at here. Also, thank you so much to for posting the workaround too, I was getting a headache dealing with this.
Hi, i wanted to ask if someone is working on this issue?
It's an open-source project, so unless someone with the necessary knowledge is interested in the issue (could be yourself), then you'll probably have to wait.
I ran into this same issue before. The only thing that let me run gamescope through steam so far has been the solution from , but I am not sure why it works.
I'm trying to add the patch in in , eagering for testing from you.
There seem to be multiple issues conflated here. The original issue with X11 socket ownership has been addressed. If there's another issue that prevents running gamescope in Steam, please report it separately.

Related discussion:
text: }; }; <ins> programs.steam.extraPackages = cfg.fontPackages; </ins> programs.gamescope.enable = lib.mkDefault cfg.gamescopeSession.enable; services.displayManager.sessionPackages = lib.mkIf cfg.gamescopeSession.enable [ gamescopeSessionFile ];
Code change:
Steps to reproduce the behavior: to build from source Please run and paste the result.
cc maintainers
Can you check if is working? Looks very close to the regression fixed in (did not get to yet).
is there a cache for that branch? using with that started building the world
does have an incomplete cache. If you are accessing at inopportunate time you might catch a few rebuilds. You can pick a specific commit from with most builds done. Most recent it yesterday's
that commit did not fix the issue
edit: scratch that, tried a fresh build. works now
Closing since it sounds like this was fixed by the merge of . Happy to reopen if I'm mistaken.

Related discussion:
text: # compile, because it uses "#include_next <limits.h>" to find the # limits.h file in ../includes-fixed. To remedy the problem, # another -idirafter is necessary to add that directory again. <del> # # We use --sysroot=/nix/store/does/not/exist to drop embedded default # path to glibc headers gcc was built against. Without it -idirafter # only appends to the list and outdated glibc headers end up being # used. 'cc-cflags-before' is used to allow user's --sysroot= option # to override our default. </del> + optionalString (libc != null) ('' touch "$out/nix-support/libc-cflags" touch "$out/nix-support/libc-ldflags" echo "-B${libc_lib}${libc.libdir or "/lib/"}" >> $out/nix-support/libc-crt1-cflags '' + optionalString (!(cc.langD or false)) '' <del> echo "--sysroot=/nix/store/does/not/exist" >> $out/nix-support/cc-cflags-before </del> echo "-idirafter ${libc_dev}${libc.incdir or "/include"}" >> $out/nix-support/libc-cflags '' + optionalString (isGNU && (!(cc.langD or false))) '' for dir in "${cc}"/lib/gcc/*/*/include-fixed; do
Code change:
Steps to reproduce the behavior: to build from source Please run and paste the result.
cc maintainers
Can you check if is working? Looks very close to the regression fixed in (did not get to yet).
is there a cache for that branch? using with that started building the world
does have an incomplete cache. If you are accessing at inopportunate time you might catch a few rebuilds. You can pick a specific commit from with most builds done. Most recent it yesterday's
that commit did not fix the issue
edit: scratch that, tried a fresh build. works now
Closing since it sounds like this was fixed by the merge of . Happy to reopen if I'm mistaken.

Related discussion:
text: git ]; <del> # Workaround cc-wrapper's --sysroot= value for `staging-next`: it # breaks library lookup via RUNPATH: #   ld: warning: libm.so.6, needed by ./generated/linux/release/64/lib.so, not found (try using -rpath or -rpath-link) #   ld: /build/druntime/generated/linux/release/64/libdruntime.so: undefined reference to `log10@GLIBC_2.2.5' # TODO(trofi): remove the workaround once cc-wrapper is fixed. NIX_CFLAGS_COMPILE = [ "--sysroot=/" ]; </del> buildInputs = [ curl tzdata
Code change:
Steps to reproduce the behavior: to build from source Please run and paste the result.
cc maintainers
Can you check if is working? Looks very close to the regression fixed in (did not get to yet).
is there a cache for that branch? using with that started building the world
does have an incomplete cache. If you are accessing at inopportunate time you might catch a few rebuilds. You can pick a specific commit from with most builds done. Most recent it yesterday's
that commit did not fix the issue
edit: scratch that, tried a fresh build. works now
Closing since it sounds like this was fixed by the merge of . Happy to reopen if I'm mistaken.

Related discussion:
text: NIX_CFLAGS_COMPILE = lib.optionals stdenv.isDarwin [ "-fno-common" ] ++ lib.optionals enableOpenCL [ "-UPIPE_SEARCH_DIR" "-DPIPE_SEARCH_DIR="${placeholder "opencl"}/lib/gallium-pipe"" <del> # Work around regression from https://github.com/NixOS/nixpkgs/pull/210004 # TODO(trofi): remove "--sysroot=/" </del> ]; passthru = {
Code change:
Steps to reproduce the behavior: to build from source Please run and paste the result.
cc maintainers
Can you check if is working? Looks very close to the regression fixed in (did not get to yet).
is there a cache for that branch? using with that started building the world
does have an incomplete cache. If you are accessing at inopportunate time you might catch a few rebuilds. You can pick a specific commit from with most builds done. Most recent it yesterday's
that commit did not fix the issue
edit: scratch that, tried a fresh build. works now
Closing since it sounds like this was fixed by the merge of . Happy to reopen if I'm mistaken.

Related discussion:
text: passAsFile = [ "extraConfig" ]; <del> # Workaround '-idirafter' ordering bug in staging-next: #   https://github.com/NixOS/nixpkgs/pull/210004 # where libc '-idirafter' gets added after user's idirafter and # breaks. # TODO(trofi): remove it in staging once fixed in cc-wrapper. preConfigure = '' export NIX_CFLAGS_COMPILE_BEFORE_${lib.replaceStrings ["-" "."] ["_" "_"] buildPackages.stdenv.hostPlatform.config}=$(< ${buildPackages.stdenv.cc}/nix-support/libc-cflags) export NIX_CFLAGS_COMPILE_BEFORE_${lib.replaceStrings ["-" "."] ["_" "_"]               stdenv.hostPlatform.config}=$(<               ${stdenv.cc}/nix-support/libc-cflags) ''; </del> configurePhase = '' runHook preConfigure
Code change:
Steps to reproduce the behavior: to build from source Please run and paste the result.
cc maintainers
Can you check if is working? Looks very close to the regression fixed in (did not get to yet).
is there a cache for that branch? using with that started building the world
does have an incomplete cache. If you are accessing at inopportunate time you might catch a few rebuilds. You can pick a specific commit from with most builds done. Most recent it yesterday's
that commit did not fix the issue
edit: scratch that, tried a fresh build. works now
Closing since it sounds like this was fixed by the merge of . Happy to reopen if I'm mistaken.

Related discussion:
text: substituteInPlace src/util/genfsimg --replace "	syslinux " "	true " ''; # calling syslinux on a FAT image isn't going to work <del> # Workaround '-idirafter' ordering bug in staging-next: #   https://github.com/NixOS/nixpkgs/pull/210004 # where libc '-idirafter' gets added after user's idirafter and # breaks. # TODO(trofi): remove it in staging once fixed in cc-wrapper. preConfigure = '' export NIX_CFLAGS_COMPILE_BEFORE_${lib.replaceStrings ["-" "."] ["_" "_"] buildPackages.stdenv.hostPlatform.config}=$(< ${buildPackages.stdenv.cc}/nix-support/libc-cflags) export NIX_CFLAGS_COMPILE_BEFORE_${lib.replaceStrings ["-" "."] ["_" "_"]               stdenv.hostPlatform.config}=$(<               ${stdenv.cc}/nix-support/libc-cflags) ''; </del> # not possible due to assembler code hardeningDisable = [ "pic" "stackprotector" ];