jiebi/CodeConvo huggingface dataset:
Change:
s2geometry = callPackage ../development/libraries/s2geometry { }; <del> /*  This package references ghc844, which we no longer have. Unfortunately, I have been unable to mark it as "broken" in a way that the ofBorg bot recognizes. Since I don't want to merge code into master that generates evaluation errors, I have no other idea but to comment it out entirely. sad = callPackage ../applications/science/logic/sad { }; */ </del> safefile = callPackage ../development/libraries/safefile { }; sbc = callPackage ../development/libraries/sbc { };

Discussion:
There's two "sad" packages, with one being not used at-all top-level/all- in a text-editor (as of writing but beware this will lag, so open it locally) at this comment: at this what happened Should be just one We should just drop the old pkg's nix files after notifying the maintainer of the old package, but I'm opening this issue for discussion, because there might be more left to cleanup. Perhaps we should check if we have files in-tree that are no longer being referenced and do a prune of those files (and maybe check it in ci afterwards, or at least occasionally during hydra builds). <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
The package of which I'm the maintainer has nothing to do with the other package, these are completely different packages. I am not using this application anymore, it is commented (and probably broken) since at least and , which were committed in July 2020. This is nearly 3 years ago. I'm not maintaining it anymore. So yes, let's remove it. I think deleting the folder and the commented reference in all- should remove all references to it.
Change:
services.nginx.enable = mkDefault true; services.nginx.virtualHosts.${cfg.hostName} = { <del> root = cfg.package; </del> <ins> root = webroot; </ins> locations = { "= /robots.txt" = { priority = 100;

Discussion:
The extraApp called displays as blank. This was working fine on nextcloud27. Rest of the site is working fine. Steps to reproduce the behavior: am currently on to webpage is blank on: Firefox Chrome Edge It should display the normal forms page. ! Found non-nixos issue relating to it here: Seems it may be a related issue? <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
{ lib , stdenv <del> , mkDerivation </del> , fetchFromGitHub , cmake , asciidoc

Discussion:
Steps to reproduce the behavior: i noticed the break after the nheko 0.10.2 -0.11.0 upgrade landed in nixos-unstable: hydra failure (click for the build log): build is currently broken in both master () and has been fixed in nixos-22.11, see for having initiated the backport. tagging as maintainer of both mtxclient and nheko. Please run and paste the result.
tested against the outstanding mtxclient 0.9.0 -0.9.1 PR: still broken.
I have no idea why a standard library would depend, let alone be missing, on a different architecture.
Likely due to us using outdated gcc (gcc9) on aarch64-linux. The story is complicated, but is being addressed.
Forcing it to use gcc11Stdenv may fix the issue.
It seems so: I tested by cross-compiling mtxclient (I don't have an aarch64 system).
Opened
Great... now coeurl fails to build. EDIT: Fixed, but nheko is still broken.
hope nobody minds this extra notification that is me thanking you all for jumping in so readily to fix things, even for someone you’ve never met. anyone reading this: what you’re doing here has more impact than you know.
Change:
` { fetchurl }: fetchurl { <del> url = "https://github.com/denoland/rusty_v8/releases/download/v${version}/librusty_v8_release_${arch.rust}.a"; </del> <ins> url = "https://github.com/denoland/rusty_v8/releases/download/v${version}/librusty_v8_release_${arch.rust}.a.gz"; </ins> } `, ]);

Discussion:
Package name: deno Latest released version: 1.42.3 Current version on the unstable channel: 1.41.3 Current version on the stable/release channel: 1.38.2 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi I'll look into why there hasn't been a PR opened yet by the bot. The update will probably only go into unstable, just to be clear upfront. There will be a new stable release in the next month or so for . Also I can't edit your issue but your versions for unstable/stable are backwards :)
, in case you didn't find it already. Fixed.
Change:
buildGoModule rec { pname = "hishtory"; <del> version = "0.215"; </del> <ins> version = "0.266"; </ins> src = fetchFromGitHub { owner = "ddworken"; repo = pname; rev = "v${version}"; <del> hash = "sha256-XDxAzMQjtCfufWnEO5NXP8Zv823a85qYhkZcEZKxIXs="; </del> <ins> hash = "sha256-AyUdmzrHBPXzDSOvhNz270D1AP7UdIpeaSqSyIFyQLY="; </ins> }; <del> vendorHash = "sha256-aXHqPk8iBMbe0NlsY3ZR7iozBGCAKlOOQ23FAD/5hL8="; </del> <ins> vendorHash = "sha256-yk1ryXQ750xW7BYTMg0UQYb5DEIJ5ZWvoLLKSo3nx6k="; </ins> ldflags = [ "-X github.com/ddworken/hishtory/client/lib.Version=${version}" ]; <ins> subPackages = [ "." ]; </ins> excludedPackages = [ "backend/server" ]; postInstall = ''

Discussion:
Package name: hishtory Latest released version: 0.264 <!-- Search your package here: --- Current version on the unstable channel: 0.215 Current version on the stable/release channel: 0.215 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
boot = { kernelModules = [ "zfs" ]; <ins> # https://github.com/openzfs/zfs/issues/260 # https://github.com/openzfs/zfs/issues/12842 # https://github.com/NixOS/nixpkgs/issues/106093 kernelParams = lib.optionals (!config.boot.zfs.allowHibernation) [ "nohibernate" ]; </ins> extraModulePackages = [ (if config.boot.zfs.enableUnstable then

Discussion:
Describe the bug Suspend to disk / hibernation in combination with ZFS may lead to filesystem corruption. To Reproduce The problem only shows up occasionally about once on every 30 startups. I had been using suspend to disk on my laptop without problem for several years. After changing from BTRFS to ZFS the import of the ZFS pool occasionally stalls when resuming from hibernate. A message says that the pool is corrupted and gets reconstructed. Once the pool was corrupted irreparably. Root cause ZFS does not support filesystem freeze and thaw under Linux at the moment. (see ) The problem is that when resuming from hibernation the initrd tries to import the pool (it also tries to fix a corrupted pool and effectively modifies the pool/partition). This happens before checks for a possible resume from hibernation and before the system returns to the state in which it had been suspended. Expected behavior It may be possible to fix the problem by reordering the sequence of actions in initrd. Unless there is a fix for this NixOS should disable the combination of ZFS and hibernation. (More precisely, initrd should either contain the setup scripts for ZFS or the scripts for return-from-hibernate). At least there should be a warning.
BTRFS is native to Linux, so its suspension mechanism and Linux's were (presumably) always set up to work with each other. On the other hand, ZFS's suspension code has not yet been hooked up to Linux's properly: I agree that— One potential problem seems to be that there seem to be multiple packages that can cause suspension. In my NixOS configuration, I tell and not to suspend, but I don't know whether that's everything that might cause suspension.
Thanks for adding the link. I've a corresponding line of warning here:
Do you suspend to disk with a zvol swap? Because I'm running with root on ZFS on my laptop and I have never encountered problems with suspend to disk, but I'm also using a separate regular swap partition.
I for one use a regular swap partition. I recall hearing that swap-on-ZVOL is dangerous independently of hibernation.
I marked this as stale due to inactivity. &rarr;
Would it make sense to automatically add in cases where zfs is in use?
This.

A note in wiki or manual will be good too. EDIT: Done ().
I marked this as stale due to inactivity. &rarr;
Let's see if we can close this with
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
src = fetchFromGitHub { owner = "akopytov"; repo = "sysbench"; <del> rev = "1.0.14"; sha256 = "0mp1wqdm87zqyn55z23qf1izqz7ijgcbsysdwqndd98w6m5d86rp"; </del> <ins> rev = "1.0.15"; sha256 = "0ddj4mxxqlnlp817ix2qad0v3p83azi9wyz4h7mffchgp3mndp9z"; </ins> }; meta = {

Discussion:
What I expected: I installed vimconfigurable and I should have expected python to work arrording shlevy it is on by default. What I got: What I got was pythong did not work either :python print "hi" or plugins that needed python. What I expected: After getting python working by adding ; to I expected removing ; would remove vim's access to python after nix-env -i vimconfigurable. What I got: Vim still had access to python. The step below demonstrate the above and an additional difference between my nixos 1.1pre2714... and nix 1.1 on ubuntu. Nixpkgs "remembers" ; after it is removed form Reproduced in NixOS on VMware and nix on Ubuntu: Each invocation of vim happens in a new shell created after the nix-env install is finished. nix-env -i vimconfigurable.  Vim can not access python test by :python print "Hi" in vim. Should result in error. Add ; to nix-env -i vimconfigurable.  Vim can now access python test by :python print "Hi" in vim. nix-env -e vimconfigurable. Remove ; in nix-env -i vimconfigurable  Vim can still access python test by :python print "Hi" in vim. Add ; to nix-env -i vimconfigurable.  Vim can not access python test by :python print "Hi" in vim. -"Sorry, the command is not available in this version remove ; in nix-env -i vimconfigurable.  :python print "Hi" in vim. -(ubuntu nix 1.0: vim crashes and gives error report) (nixos 1.1pre27142f3f413: vim has acces to python) Add ; to nix-env -i vimconfigurable.  :python print "Hi" in vim. -(ubuntu nix 1.0: vim crashes and gives error report) (nixos 1.1pre2714_2f3f413: vim has acces to python) There is some some state that is saved in-between installs which seems undesirable.

There's something strange happening here, but I don't think it's due to (and it's definitely not due to nixpkgs config being saved somewhere). has: , which means that if is not set it defaults to true. Perhaps vim_configurable needs some other flag for python support to be on? ? I'll try to reproduce this later.
I will document here as I did on irc that I could not get my test of :python print "hi", or a pandoc extension that called on python, to work before either adding "python" to the flags in all-packages or setting ; in on nixos 1.1pre2714... or on my ubuntu nix 1.1 install.
Do I remember correctly that we resolved this?
The symptom has been resolved with this merge: There is still probably an under lying problem/issue. I don't know if it is worth keeping open though. , Shea Levy wrote:
Change:
<del> { fetchzip }: fetchzip { name = "lmmath-0.903"; url = "http://www.gust.org.pl/projects/e-foundry/lm-math/download/lmmath0903otf"; postFetch = '' unzip $downloadedFile mkdir -p $out/texmf-dist/fonts/opentype mkdir -p $out/share/fonts/opentype cp *.{OTF,otf} $out/texmf-dist/fonts/opentype/lmmath-regular.otf cp *.{OTF,otf} $out/share/fonts/opentype/lmmath-regular.otf ln -s -r $out/texmf* $out/share/ ''; sha256 = "19821d4vbd6z20jzsw24zh0hhwayglhrfw8larg2w6alhdqi7rln"; meta = { description = "Latin Modern font"; }; } </del>

Discussion:
A grep of : The latest version is 1.959 per I'd say that the texlive and fonts/lm-math versions can stay as they have different paths ( vs ), although ideally just the texlive version would stay, but the others are not helping anything at all.
cc for comments
– has meta, unpacks only the needed files – resides in the same directory with , tries to provide texmf So, perhaps, we should keep the implementation of under the name and make an alias. The satysfi needs to be fixed to use existing packages (also implements a duplicate of ).
Well, for texmf one would presumably use the TexLive package, as it has separated and outputs unlike the other packages. And it auto-updates along with the rest of TexLive. The only issue with using it as the sole package is that it's not a multiple output derivation so using it in the fonts list looks like rather than just . It shouldn't be that hard to set up TexLive to have attributes usable directly, by setting and so forth. Nix doesn't support multiple outputs for fixed-output derivations, so it'd be a bit of a hack.
The "packages" in are set up to be used with . They were not intended to be used in any other way.
Change:
let inherit (stdenv) isDarwin isFreeBSD isLinux isAarch32; <del> inherit (stdenv.lib) optional optionals enableFeature; </del> <ins> inherit (stdenv.lib) optional optionals optionalString enableFeature; </ins> cmpVer = builtins.compareVersions; reqMin = requiredVersion: (cmpVer requiredVersion branch != 1);

Discussion:
Describe the bug In mpv, CUDA-accelerated playback worked a few months ago after landed, but now no longer does. To Reproduce Steps to reproduce the behavior: NixOS master with an NVIDIA card and and observe: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(at): nixpkgs: Maintainer information:
I will see if doing helps
Change:
application = mkSweetHome3D rec { pname = lib.toLower module + "-application"; <del> version = "7.2"; </del> <ins> version = "7.3"; </ins> module = "SweetHome3D"; description = "Design and visualize your future home"; license = lib.licenses.gpl2Plus; src = fetchzip { url = "mirror://sourceforge/sweethome3d/${module}-${version}-src.zip"; <del> hash = "sha256-RVuwxL/YATqHoQuc25ZaYgZ+o2rMOqnzU8/LLxb5Ra4="; </del> <ins> hash = "sha256-adMQzQE+xAZpMJyQFm01A+AfvcB5YHsJvk+533BUf1Q="; </ins> }; desktopName = "Sweet Home 3D"; icons = {

Discussion:
Package name: sweethome3d Latest released version: 7.3 Current version on the unstable channel: 7.2 Current version on the stable/release channel: 7.2 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
<del> { lib, fetchFromGitHub, rustPlatform, libseccomp }: rustPlatform.buildRustPackage rec { pname = "railcar"; version = "1.0.4"; src = fetchFromGitHub { owner = "oracle"; repo = "railcar"; rev = "v${version}"; sha256 = "09zn160qxd7760ii6rs5nhr00qmaz49x1plclscznxh9hinyjyh9"; }; # Submitted upstream https://github.com/oracle/railcar/pull/44 cargoPatches = [ ./cargo-lock.patch ]; cargoSha256 = "1zsch6gpbw96j5wa68ksbk4x6nbsl7dbvdhdprljpcyrwwkhz47x"; buildInputs = [ libseccomp ]; meta = with lib; { description = "Rust implementation of the Open Containers Initiative oci-runtime"; homepage = "https://github.com/oracle/railcar"; license = with licenses; [ asl20 /* or */ upl ]; maintainers = [ maintainers.spacekookie ]; }; } </del>

Discussion:
I was curious about railcar and noted that it's marked as so I decided to give it a try. The first attempt failed at an error over a missing in libseccomp: I gather this is Linux-only and could find at least one other PR that fixed a macOS build of a different project by just removing it as a buildInput () and the cargo build fell over on some issues with caps: Other notes: I looked to see if Hydra was building this for darwin and don't see any builds. I guess hydra is smart enough not to bother with darwin given the libseccomp input. I noticed that ofborg didn't bother with building darwin on the original PR, either. Also, I noticed that oracle has archived the railcar repo. I only see at the moment. They've done some work on the CI earlier this year, at least, which seems to be a good signal? Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(abathur): nixpkgs:
I marked this as stale due to inactivity. &rarr;
Change:
exit 1 fi <del> ln -sf ${cfg.package}/apps ${cfg.home}/ # Install extra apps ln -sfT  ${pkgs.linkFarm "nix-apps" (mapAttrsToList (name: path: { inherit name path; }) cfg.extraApps)}  ${cfg.home}/nix-apps </del> <ins> ${concatMapStrings (name: '' if [ -d "${cfg.home}"/${name} ]; then echo "Cleaning up ${name}; these are now bundled in the webroot store-path!" rm -r "${cfg.home}"/${name} fi '') [ "nix-apps" "apps" ]} </ins> # create nextcloud directories. # if the directories exist already with wrong permissions, we fix that <del> for dir in ${datadir}/config ${datadir}/data ${cfg.home}/store-apps ${cfg.home}/nix-apps; do </del> <ins> for dir in ${datadir}/config ${datadir}/data ${cfg.home}/store-apps; do </ins> if [ ! -e $dir ]; then install -o nextcloud -g nextcloud -d $dir elif [ $(stat -c "%G" $dir) != "nextcloud" ]; then

Discussion:
The extraApp called displays as blank. This was working fine on nextcloud27. Rest of the site is working fine. Steps to reproduce the behavior: am currently on to webpage is blank on: Firefox Chrome Edge It should display the normal forms page. ! Found non-nixos issue relating to it here: Seems it may be a related issue? <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
buildGoPackage rec { pname = "etcd"; <del> version = "3.3.22"; </del> <ins> version = "3.3.25"; </ins> goPackagePath = "github.com/coreos/etcd";

Discussion:
, CVSSv3=7.7 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) CVSSv3=7.1 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) CVSSv3=6.5 (nixos-unstable) Scanned versions: nixos-unstable: . Cc Cc
Change:
let inherit (python3.pkgs) cython buildPythonApplication; <del> xf86videodummy = callPackage ./xf86videodummy { }; </del> <ins> xf86videodummy = xorg.xf86videodummy.overrideDerivation (p: { patches = [ ./0002-Constant-DPI.patch ./0003-fix-pointer-limits.patch ./0005-support-for-30-bit-depth-in-dummy-driver.patch ]; }); xorgModulePaths = writeText "module-paths" '' Section "Files" ModulePath "${xorgserver}/lib/xorg/modules" ModulePath "${xorgserver}/lib/xorg/modules/extensions" ModulePath "${xorgserver}/lib/xorg/modules/drivers" ModulePath "${xf86videodummy}/lib/xorg/modules/drivers" EndSection ''; </ins> in buildPythonApplication rec { pname = "xpra"; version = "3.0.7";

Discussion:
Describe the bug Attempting to start xpra fails with the following X server log: To Reproduce Steps to reproduce the behavior: run start :200
Change:
<ins> { buildGoModule, fetchFromGitHub, lib }: buildGoModule rec { pname = "csvq"; version = "1.17.11"; src = fetchFromGitHub { owner = "mithrandie"; repo = "csvq"; rev = "v${version}"; sha256 = "sha256-jhj03xpWBcLVCCk1S9nsi8O6x1/IVwNT3voGfWBg2iw="; }; vendorSha256 = "sha256-C+KQHSp4aho+DPlkaYegjYSaoSHaLiQOa1WJXIn9FdQ="; meta = with lib; { description = "SQL-like query language for CSV"; homepage = "https://mithrandie.github.io/csvq/"; changelog = "https://github.com/mithrandie/csvq/releases/tag/v${version}"; license = licenses.mit; maintainers = with maintainers; [ tomodachi94 ]; }; } </ins>

Discussion:
csvq From the homepage: Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, bsd, netbsd, openbsd, (windows) Note I'm just getting started with nix and don't have a lot of experience with the nix DSL. If I find time I could look into this myself but some pointers where to start when submitting new packages are appreciated. If someone else is interested in doing this, that's also fine for me (and will probably be a lot quicker :smile:)
I beat you to it! The PR is .
Change:
, stdenv , fetchurl , appimageTools <ins> , appimage-run </ins> , makeWrapper <del> , electron </del> , git }:

Discussion:
When exporting the graph, logseq throws a permission exception. Steps to reproduce the behavior: a new graph a few pages them public ()) the graph The graph should successfully export and opening it should show a read-only view of the graph. The logseq documentation itself is an example thereof. If applicable, add screenshots to help explain your problem. Bug was first reported in the original repo When running the AppImage with it's fine because it's extracted into , but when the app is in then it won't work because of the read-only status. I tested the flatpak version because I suspected the same problem would occur, but the directories are mounted read-write in a read-only volume. So, 2 options exist as I see it: fix it upstream, but I don't know Clojure nor Electron start the AppImage with instead of extracting it Please run and paste the result.