jiebi/CodeConvo huggingface dataset:
Code change:
externalDeps' = lib.filter (dep: !lib.isDerivation dep) externalDeps; in toLuaModule ( lua.stdenv.mkDerivation ( <del> builtins.removeAttrs attrs ["disabled" "checkInputs" "externalDeps"] // { </del> <ins> builtins.removeAttrs attrs ["disabled" "checkInputs" "externalDeps" "extraVariables"] // { </ins> name = namePrefix + name;

Related discussion:
text: I think the root problem here is that luarocks has a poor implementation of "move". Combined with the build's behavior being affected by filesystem ordering the result is essentially random. The [implementation of move][] calls out to the operating system commands [][] and [][]. Building with will contain a sequence of , and . I've extracted the [relevant part of the log][]. The critical aspect here is that by default, unix will dereference symlinks and copy their contents. [implementation of move]: []: []: [relevant part of the log]: My theory: luarocks scans the directory for external libraries in filesystem order and attempts to move all shared libraries from to . At which point one of 3! things will happen, but the two main ones are: is copied and deleted and , now broken symlinks, fail to copy and are copied by dereferencing, and deleted is copied and deleted Either way is wrong to some degree, but one of them happens to work well enough for downstream packages to build. If I build locally, the filesystem order I get seems to work, so we can inspect the two results: I've been focusing on this for darwin since the failure case happens to be cached, but I believe it applies equally to linux.
is that sthg you have already witnessed ?
What LuaRocks version is this happening with? I have pushed fixes related to the file deployment stage in 3.3.1.
I've tested 3.2.1 (current nixpkgs master) and 3.3.1 (hasty upgrade locally), they both have similar results, except on 3.3.1 the errors now propagate correctly. I've uploaded a [log of a failed build][] with 3.3.1. [log of a failed build]:
I was hoping to find time to write a proper issue report and a test lua package for this, but haven't yet. My test case would have a directory structure made with , that looks like: In order to succeed the deployment stage would have to produce both the file and its symlink.
Code change:
externalDeps' = lib.filter (dep: !lib.isDerivation dep) externalDeps; in toLuaModule ( lua.stdenv.mkDerivation ( <del> builtins.removeAttrs attrs ["disabled" "checkInputs" "externalDeps"] // { </del> <ins> builtins.removeAttrs attrs ["disabled" "checkInputs" "externalDeps" "extraVariables"] // { </ins> name = namePrefix + name;

Related discussion:
text: Describe the bug I have neovim in my systemPackages, I did and today and it stuck at building luajit: To Reproduce Steps to reproduce the behavior: to Expected behavior The system should upgrade properly. Additional context Output: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(kj): nixpkgs: Maintainer information:
Possible fix is in . There was already an open issue about it () but from an unclear reason people have reached the conclusion it was fixed on latest master.
Oh I meant , not .
Well, I agree with that conclusion. For me, on the build is broken with the error above and on current master it isn't. EDIT: note that the channels lag behind, usually less than a couple days, but sometimes we get a week or two due to some harder regression.
Yea right. For me on NixOS I tried with the nixpkgs-unstable channel and could install successfully. The nixos-unstable still fails though.
Code change:
device = mkOption { example = "/dev/sda3"; <del> type = types.str; </del> <ins> type = types.nonEmptyStr; </ins> description = lib.mdDoc "Path of the device or swap file."; };

Related discussion:
text: When using to create and activate a swapfile on btrfs, it fails with messages like this: The kernel says: I am not very familiar with Nix, but after reading the corresponding and , it seems that creating a swapfile on btrfs requires disabling copy-on-write for that file (via ) as well. However, doesn't do it currently. BTW, manually creating the swapfile and letting NixOS activating it works fine for me. to ( is supposed to be mounted as btrfs). . Swapfile is created and activated without any issue. There is a workaround on NixOS Discourse: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
I have the same issue. I already tried disabling copy-on-write for the partition but it still fails: I also still get the warning like even though I the attribute to my mount options (afterwards). My current swap configuration can be found .
Mounting with attribute won't work because: [^1]:
I came up with this yesterday, which seems to work (or at least you can follow the general pattern): I have as a separate subvolume, nothing else on it. Once you've run this to create the swapfile, it seems to mount and function properly from there on out. But yes, it would be nice if this were taken care of automatically. EDIT: Fix link
brilliant, that helped me solve my issue. While your script didn't work out for me, I was able to adjust it so it did. I noticed the following warning when running your script: So, I searched for this and found the following note on ArchWiki: — Replacing with made the warning disappear for me but running still failed with . Then I compared the script to what I've used in and noticed that I used instead of to create the empty swapfile. The full script I ended up with:
Thanks for the update. I originally used , but switched after reading that should be much faster (and have to admit I can't remember if I tested that change yet -- thank you for the feedback). I've switched it back to .
Code change:
sha256 = "sha256-IlrfqwNyaSHE9Ct0mn7MUxEg7p1Ku34eOMYelEAYFW8="; }; <ins> patches = [ # based on https://github.com/rustdesk/rustdesk/pull/1900 ./fix-for-rust-1.65.diff ]; </ins> cargoSha256 = "sha256-1OMWEk+DerltF7kwdo4d04rbgIFLHBRq3vZaL7jtrdE="; LIBCLANG_PATH="${llvmPackages.libclang.lib}/lib";

Related discussion:
text: Steps to reproduce the behavior: <!-- 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.
This is due to the upgrade to Rust 1.65 in I'm sorry for the inconvenience and will take care of fixing this. The caveat is that I need to fix my system first, which I broke somehow trying to install the new version of nix
Thank you very much!
Code change:
BINARY = 64; TARGET = setTarget "ATHLON"; DYNAMIC_ARCH = setDynamicArch true; <ins> NO_AVX512 = !enableAVX512; </ins> USE_OPENMP = false; MACOSX_DEPLOYMENT_TARGET = "10.7"; };

Related discussion:
text: Describe the bug In the AVX512 support was turned back on in openblas, allowing for the use of dynamic, AVX512 optimized compute kernels. started to discover problems with AVX512 while working on the and I can confirm that this problem affects multiple packages that are built against openblas. The problem already manifest itself in that packages fail their unit tests, when build on an AVX512 enabled machine (see for a detailed list). The tests either fail due to a wrong result or time out. I could indentify 5 different packages which are affected by this bug, leading to the conclusions this very likely affects many more packages. Affected versions of openblas, which I have tested, are 0.3.13 (master/release-21.05) and 0.3.15 (in staging at the moment). The problem disappears when: is complied with in is injected into the test phase or just set at runtime. Note that any core type that does not use AVX512 works fine here (tested: , or , but , which uses AVX512 fails). is turned off at openblas build time and is set to a non-AVX512 target (see point 2). you seem to be making use AVX512 optimizations. Did you notice any problems? I suggest to revert and thus re-introduce the makeFlag in openblas. To Reproduce an affected program which is linked against openblas on an Intel CPU that supports AVX512 instructions (e.g. Xeon Scalable) and check the results. In nixpkgs it is at least that is affected (delivers wrong results). , for example, on an Intel CPU with AVX512: the self tests/unit tests never finish in this case. external packages fail to run their tests on and AVX512 enabled machine: Notify maintainers CC Metadata This should affect since (~January 2021) and . The tests I have carried out were run with versions from the ~last week.
Sorry to hear that :(. Then we should indeed revert that change again.
Can this be closed?
The PR has been merged into staging. Should we wait to close the issue until the fix reaches master?
Code change:
imageTag="latest" fi <del> "$skopeoCmd" inspect "docker://$imageName:$imageTag" | jq '.Digest' -r </del> <ins> skopeo --insecure-policy --tmpdir=$TMPDIR inspect "docker://$imageName:$imageTag" | jq '.Digest' -r </ins> } get_name() {

Related discussion:
text: Describe the bug Running fails with To Reproduce Extra info On of that script scopeoCmd isn't called correctly. Seems like introduced the problem in this PR
Code change:
}; headersFetcher = vers: hash: fetchurl { <del> url = "https://atom.io/download/electron/v${vers}/node-v${vers}-headers.tar.gz"; </del> <ins> url = "https://artifacts.electronjs.org/headers/dist/v${vers}/node-v${vers}-headers.tar.gz"; </ins> sha256 = hash; }; tags = { <del> i686-linux = "linux-ia32"; </del> x86_64-linux = "linux-x64"; armv7l-linux = "linux-armv7l"; aarch64-linux = "linux-arm64"; x86_64-darwin = "darwin-x64"; <del> aarch64-darwin = "darwin-arm64"; </del> <ins> } // lib.optionalAttrs (lib.versionAtLeast version "11.0.0") { aarch64-darwin = "darwin-arm64"; } // lib.optionalAttrs (lib.versionOlder version "19.0.0") { i686-linux = "linux-ia32"; </ins> }; <del> get = as: platform: as.${platform.system} or "Unsupported system: ${platform.system}"; </del> <ins> get = as: platform: as.${platform.system} or (throw "Unsupported system: ${platform.system}"); </ins> common = platform: { inherit pname version meta;

Related discussion:
text: Element v1.11.0 updated to Electron 19, so we need this packaged in Nixpkgs: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- 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! --- name: <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 18.1.0 desired version: 19.0.7 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
When I run the script tries to download which does not exist. Do you know where to get the electron headers?
PR that brings electron19 but does not provide electron19 headers:
I believe that states that they migrated storage. So, I think the new url would be
Great find, thanks! Updated PR to include this change and electron_19 now provides the headers.
electrum_19 to master via - feel free to update your package
Code change:
vendorSha256 = "0szs9yc49fyh55ra1wf8zj76kdah0x49d45cgivk3gqh2hl17j6l"; <ins> agents = fetchzip { name = "mutagen-agents-${version}"; # The package architecture does not matter since all packages contain identical mutagen-agents.tar.gz. url = "https://github.com/mutagen-io/mutagen/releases/download/v${version}/mutagen_linux_amd64_v${version}.tar.gz"; stripRoot = false; extraPostFetch = '' rm $out/mutagen # Keep only mutagen-agents.tar.gz. ''; sha256 = "0k8iif09kvxfxx6qm5qmkf3lr7ar6i98ivkndimj680ah9v1hkj8"; }; </ins> doCheck = false; subPackages = [ "cmd/mutagen" "cmd/mutagen-agent" ]; <ins> postInstall = '' install -d $out/libexec ln -s ${agents}/mutagen-agents.tar.gz $out/libexec/ ''; </ins> meta = with lib; { description = "Make remote development work with your local tools"; homepage = "https://mutagen.io/";

Related discussion:
text: Describe the bug Trying to run mutagen results in an error: The mutagen- which is supposed to have binaries for different platforms is missing. To Reproduce mutagen a mutagen session Metadata system: host os: multi-user?: sandbox: version: channels(alex): channels(root): nixpkgs: Maintainer information:
Hey, author of Mutagen here, super excited to see a Nix package for it! I just thought I'd mention that the bundle currently needs to be placed in the same directory as the executable itself. This is something I've been meaning to improve for a while now (by allowing it to be put in a directory), but I haven't had a chance to implement it yet, mostly because it's a little tricky to get right with package managers like Homebrew that symlink binaries into a different target location. I'm not very familiar with Nix, but I'm sure that it would prefer to avoid having this tarball in the directory. So I'm happy to push ahead on trying to support the -based layout if that's helpful here (or perhaps something more general if NixOS prefers a different layout).
cc
A quick update: Mutagen v0.11.2 and later support looking for the bundle in a directory (assuming a Filesystem Hierarchy Standard layout), so a layout of the form: should now work (in addition to the option of installing the bundle directly alongside the executable). This also works in a -style setup where the binary is symlinked into a larger directory.
Thanks! Is the available for direct download?
The bundle ships as part of the official releases (e.g. in the ). It needs to be kept in sync with the version of the binary being installed, but it should work just fine with a binary built locally, so long as the versions are the same (to the patch level). The bundle can also be built locally, but doing so requires running a custom script inside the Mutagen source tree that performs the necessary cross-compilation (this bundle is a collection of cross-compiled binaries that get injected to remote systems to facilitate file synchronization and network forwarding). I'm not sure the best way of handling that in the context of the NixOS packaging system. Perhaps there are some custom hooks available?
Code change:
vendorSha256 = "0szs9yc49fyh55ra1wf8zj76kdah0x49d45cgivk3gqh2hl17j6l"; <ins> agents = fetchzip { name = "mutagen-agents-${version}"; # The package architecture does not matter since all packages contain identical mutagen-agents.tar.gz. url = "https://github.com/mutagen-io/mutagen/releases/download/v${version}/mutagen_linux_amd64_v${version}.tar.gz"; stripRoot = false; extraPostFetch = '' rm $out/mutagen # Keep only mutagen-agents.tar.gz. ''; sha256 = "0k8iif09kvxfxx6qm5qmkf3lr7ar6i98ivkndimj680ah9v1hkj8"; }; </ins> doCheck = false; subPackages = [ "cmd/mutagen" "cmd/mutagen-agent" ]; <ins> postInstall = '' install -d $out/libexec ln -s ${agents}/mutagen-agents.tar.gz $out/libexec/ ''; </ins> meta = with lib; { description = "Make remote development work with your local tools"; homepage = "https://mutagen.io/";

Related discussion:
text: At the moment, this script doesn't have a flag for building just this bundle (it will only be built as part of a full set of release bundles for all platforms), though I suppose such a flag could be . One of the downsides of doing the cross-compilation locally on Linux (or any non-macOS system) is that the C FFI bindings needed for efficient filesystem watching on macOS won't be available, so file synchronization between NixOS systems and macOS systems will suffer. That might not be a huge loss, though. This is why the Homebrew packages just use the official pre-built release bundles as their "source code." It's a bit non-idiomatic, but it saves on local build times and allows for cross-compiled binaries with C FFI support. Of course, I totally understand if that doesn't work with the NixOS package philosophy, in which case just building the bundle locally is probably the best bet.
As a reference point, here's what the Mutagen Homebrew formula looks like:
I agree, setting up the cross-compilation would not be trivial so the nix derivation must download the prebuilt agents binaries from somewhere while still being able to build the agent on the platform it is running on. I see three possibilities: (No changes on the mutagen side). Nix derivation downloads the full mutagen release and extracts . the version number to the and add it to the downloads. The nix derivation would just download it. the individual downloads for the agents similarly to for all the platforms and have the nix derivation create the itself. That way it would be very easy to even parametrize it to only download the agents the user wants and the nix derivation would supply the binary for the platform it is running on.
All three options are reasonable ideas, though I would prefer to avoid (3) since it would significantly increase the number of assets attached to each GitHub release (which is probably already too high). The individual agent binaries for linux/amd64 that you mentioned are sort of a special case for some experimental container integration features, so I'd prefer to avoid expanding them to every platform.
Code change:
vendorSha256 = "0szs9yc49fyh55ra1wf8zj76kdah0x49d45cgivk3gqh2hl17j6l"; <ins> agents = fetchzip { name = "mutagen-agents-${version}"; # The package architecture does not matter since all packages contain identical mutagen-agents.tar.gz. url = "https://github.com/mutagen-io/mutagen/releases/download/v${version}/mutagen_linux_amd64_v${version}.tar.gz"; stripRoot = false; extraPostFetch = '' rm $out/mutagen # Keep only mutagen-agents.tar.gz. ''; sha256 = "0k8iif09kvxfxx6qm5qmkf3lr7ar6i98ivkndimj680ah9v1hkj8"; }; </ins> doCheck = false; subPackages = [ "cmd/mutagen" "cmd/mutagen-agent" ]; <ins> postInstall = '' install -d $out/libexec ln -s ${agents}/mutagen-agents.tar.gz $out/libexec/ ''; </ins> meta = with lib; { description = "Make remote development work with your local tools"; homepage = "https://mutagen.io/";

Related discussion:
text: I also don't know if many users want to go through the trouble of filtering the remote platform support that they want, though if that's something users are interested in then I'm certainly willing to try to support that.<sup1</supOption (2) is possible without too much effort, though I don't think it adds much value over option (1). Additionally, if option (1) is already going to be used to download the release bundle, it might as well just pull the binary out of the release bundle as well and save the complexity of a local build. In any case, the current package should have the build of removed since it won't really be of any use. Let me know if option (1) will work and if there's anything I can do to help. <sup1</supI think a better long-term solution is to provide two download variants: a "full" agent bundle that includes all platforms and a "slim" agent bundle that just includes commonly used platforms. P.S. Thanks for helping to support this!
Given the usual problems with pre-compiled binaries, reading the discussion above I thought we might have another problem : nixos needing its own agent in mutagen- But to my surprise, the amd64 binaries work on nixos without the need to patch the ELF interpreter or anything else, it seems that everything is self-contained with no external dependencies. So why not make a binary installation directly?
I can open a brand new issue about this, but wanted to get a quick check from you about a problem I'm having with this. I'm getting the following when extracting an agent: The libexec path appears to be appended to the directory for some reason. I don't know if this is an issue w/ nixpkgs or mutagen but would be happy to help track it down and (maybe) fix it. So, it looks like the file is there, but the search path is treating the absolute path for as if it was relative to the path. I suspect it has to do with the liberal usage of symlinks in nix tripping something up. I'm just too new to golang and nix to have any idea how to fix this.
Hey I believe this is fixed in Mutagen (thanks to who reported it in mutagen-io/mutagen and fixed it in mutagen-io/mutagen).
Code change:
vendorSha256 = "0szs9yc49fyh55ra1wf8zj76kdah0x49d45cgivk3gqh2hl17j6l"; <ins> agents = fetchzip { name = "mutagen-agents-${version}"; # The package architecture does not matter since all packages contain identical mutagen-agents.tar.gz. url = "https://github.com/mutagen-io/mutagen/releases/download/v${version}/mutagen_linux_amd64_v${version}.tar.gz"; stripRoot = false; extraPostFetch = '' rm $out/mutagen # Keep only mutagen-agents.tar.gz. ''; sha256 = "0k8iif09kvxfxx6qm5qmkf3lr7ar6i98ivkndimj680ah9v1hkj8"; }; </ins> doCheck = false; subPackages = [ "cmd/mutagen" "cmd/mutagen-agent" ]; <ins> postInstall = '' install -d $out/libexec ln -s ${agents}/mutagen-agents.tar.gz $out/libexec/ ''; </ins> meta = with lib; { description = "Make remote development work with your local tools"; homepage = "https://mutagen.io/";

Related discussion:
text: It looks like the corresponding NixOS package needs to be updated — we're currently at Mutagen v0.16.4. If you want to open a NixOS/nixpkgs PR for that, that's probably the way to go. Feel free to @ mention me in that PR, otherwise I'll see if I can find some time to open it during this week.
Thanks for the information. :) I spent some time yesterday trying to get my local system running on Mutagen 0.16.4. I got it working in terms of correctly locating the agents, but I noted in the PR that it isn't working for docker containers because Mutagen running as root does not seem to be able to find Docker installed via nix. I'm happy to move any additional discussion to .
Code change:
(lport: "sshd -G -T -C lport=${toString lport} -f ${sshconf} > /dev/null") cfg.ports} ${concatMapStringsSep "n" <del> (la: "sshd -G -T -C ${escapeShellArg "laddr=${la.addr},lport=${toString la.port}"} -f ${sshconf} > /dev/null") </del> <ins> (la: concatMapStringsSep "n" (port: "sshd -G -T -C ${escapeShellArg "laddr=${la.addr},lport=${toString port}"} -f ${sshconf} > /dev/null") (if la.port != null then [ la.port ] else cfg.ports) ) </ins> cfg.listenAddresses} touch $out '')

Related discussion:
text: I just tried upgrading to 23.11, and my ssh config no longer works. I specify and during a rebuild I get: , seem to have been in here last. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --I have a PR incoming as soon as git finishes pushing my branch to GitHub.
There's the PR,
Code change:
libreoffice = hiPrio libreoffice-still; <ins> libreoffice-qt = hiPrio libreoffice-qt-still; libreoffice-qt-unwrapped = libreoffice-qt.unwrapped; </ins> libreoffice-unwrapped = libreoffice.unwrapped; libreoffice-args = {

Related discussion:
text: 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.
Code change:
meta = vscode.meta; } '' mkdir -p "$out/bin" <ins> mkdir -p "$out/share/applications" mkdir -p "$out/share/pixmaps" ln -sT "${vscode}/share/applications/code.desktop" "$out/share/applications/code.desktop" ln -sT "${vscode}/share/pixmaps/code.png" "$out/share/pixmaps/code.png" </ins> ${if [] == vscodeExtensions then '' ln -sT "${vscode}/bin/${wrappedExeName}" "$out/bin/${exeName}"

Related discussion:
text: Rofi doesn't seem to find the application for VSCode even though the .desktop file seems to be there. It shows the command when running but when running it doesn't seem it show.