jiebi/CodeConvo huggingface dataset:
Originally spotted by (thank you!). Steps to reproduce the behavior (assuming and are both ): The environment variable contains semicolons and must be quoted, otherwise bash will interpret the semicolons as command separators.
- Hey, I am not sure how to clean up the mess I just made on . Really embarrassed. I intended to rebase and hit merge instead, which pulled in 10k changes.
No worries, Happens to everyone at some point :) Personally, I'd just open a new PR.
Here it is: . Does the commit history look clean enough? I'll try to rebase it later, but I am concerned about retagging all of those folks.
I'd say don't worry about it -- as far as best practice goes, I'm actually not sure what's recommended for commits. do we recommend squashing before merge? I know I typically just do force pushes to avoid any commit history :l
I went ahead and squashed, and I'll post a nixpkgs-review when it's finished.
I don't think we have an official stance on this. Contributors use their best judgement for whatever keeps the commit history simplest and easiest to use
Describe the bug In NixOS 20.09, Emacs now has the output of gtk+ in its closure, which in turn causes it to pull in stuff like mesa-drivers (424 MiB): This caused the closure size of Emacs to increase from 339 MiB in NixOS 20.03 to 1324 MiB in 20.09. Metadata NixOS 20.09..
cc
This was reverted in
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Package name: Latest released version: 555.42.02 <!-- Search your package here: --- Current version on the unstable channel: 550.78 Current version on the stable/release channel: 545.29.02 <!-- 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]:
I'm trying to install joblib for python 2.7 on a Mac, but the threading and multiprocessing tests fail. System: Darwin Kernel Version 13.4.0 Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: "16.09pre83147."
As I mentioned in you're not supposed to install Python libraries like that. Even so, the error is still a bug. Unfortunately I'm not using OSX myself so I can't be much of help I'm afraid. I do know there are issues with multiprocessing on OSX with Apple vecLib / Accelerate.
Ok, now I know you have to use nix-shell to load python libraries. Just adding here that gives the same error.
gv crashes with a segmentation fault immediately upon starting, before a window is visible. This happens even with an empty dummy document (created using latex and pdf2ps). For ease of reproducibility, you can find it . $ nix-shell -p gv [nix-shell:~]$ gv Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Thanks for merging! Glad that this is fixed. :-)
Steps to reproduce the behavior: error occurs is installed as a standalone binary. There is custom configuration: The test that fails is : I would, but it depends on coreutils. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Seems like a "known issue" without a solution with cephfs and that test: If you can use default path for store instead of: you won't have to build it yourself as it should be fetched from instead.
Unfortunately, I very much cannot use . Given that it's a known bug with that test, would a PR disabling that test likely be accepted into nixpkgs?
Maintainers for in nixpkgs would probably be able answer it better. But you can always overlay/add patch to your own config. Considering you are already building everything from scratch there won't be that much difference there.
Not sure why this wasn't auto closed.
During systemd-boot update step attempts to touch EFI variables, even when is set to . Steps to reproduce the behavior: NixOS 21.05 with systemd-boot and to NixOS 21.11 () switch fails with: An error is just an indication of update trying to touch EFI variables. (I have EFI vars touching disabled on that system because of some unrelated firmware breakage) Manually running properly finishes, further switches work fine. systemd-boot update should not touch EFI variables during upgrade. <!-- 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. Maintainer information:
I had a similar issue which I fixed by running "sudo nixos-rebuild --install-bootloader switch"
The fix for this got reverted in
Describe the bug fails to run because setuptools is no longer propagated implictly. If were purely a python application built with then we would just need to add to propagatedBuildInputs and be done. However, is not simply a Python application, but a wrapper around , and isn't built using. The derivation patches the script as follows: This does result in the site-packages directories from all python packages ending up in , including setuptools (e.g. ). I'm not that familiar with Python packaging but from experimenting I found that the full path to the Python egg needs to be included (e.g. ) in order for this method to work. I made an attempt at resolving the issue but being new to Python packaging in Nix, neither are likely to be ideal: We could use buildPythonPackage in place of mkDerivation, using and use Or continue to use mkDerivation and manually set for patchPythonScript: I'm happy to submit a PR but I'm not sure what the recommended solution is here. To Reproduce Steps to reproduce the behavior: Expected behavior should launch with the extension loaded: Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
It seems is normally used by adding a to , or calling with (what the wrapper registered in does). This script then just does some addition calculations to register itself (we probably don't that at all) and some python 2 specific fixups, and then calls , which starts executing some code on import. I'd suggest to package it as a regular python application first (via ), so you can successfully import it inside a . The python tooling should automatically take care of patching the python shebang properly if you make script executable.
proposed fix
Unfortunately I can not pinpoint the issue, but it seems that after a on Feb 1st, starts to omit a key file out of 3 key files and completely fails with a fresh system installation. Steps to reproduce the behavior: .nix contains the following lines All three files exist on disk. -rebuild switch produces a initrd-secret archive that is missing the third key file. system installation produces the following: All key files are included in generated initrd-secrets and does not fail. This issue does not exist before system update. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --This option is declared in <nixpkgs/nixos/modules/system/boot/stage-1.nix. Please run and paste the result.
I specifically installed an encrypted root on zfs system with . GRUB will decrypt disk on boot and initrd will re-decrypt disk partitions and swap with the keys embedded here.
I have that too, there seem to be a problem with here: Not sure where it is set from, but its value should be relative to the chroot, e.g. , not . It can be worked around by setting to an existing directory before installing/rebuilding, for example: Or by preparing a directory with yourself:
May be a duplicate of
Duplicate of indeed.
Building uses more () threads than it should (i.e. 2 if / ). Steps to reproduce the behavior: as the build will use way more than 2 cores. Build should honour properly. This was with . This does not in fact use just 1 thread. :smilingfacewith_tear:. ! Happens on master () and 22.11.
I don't have any time planned to fix this but if you figure it out please send a PR.
I ran into a problem when trying to install PHP + PECL extensions (via package). When PHP compiles, it installs extensions configured during build into a default directory like which differs for each PHP version and compile configurations (like ZTS support). When installing PECL extensions via ontop of PHP, they are installed into a fixed directory which makes it impossible to load those via (without knowing the absolute path) as PHP expects them to find in . In scenarios where you define your outside of nix context, it is impossible to load the PECL extensions. I wonder if a consistent extension directory for both PHP and PECL extensions could be established. Maybe the PHP package could set the (see ) environment variable to before like it is done in the . That would make it much easier to configure PHP extensions. See my profile to get an impression: /cc
Describe the bug I don't know if we should just update it or not. To Reproduce Steps to reproduce the behavior: on master Expected behavior Screenshots Additional context Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(bbigras): channels(root): nixpkgs: Maintainer information:
I can reproduce the issue locally It used to build previously The current is not in the Hydra cache because was never built by Hydra, so, unless someone else has the , we can't compare Upstream tag doesn't appear to be updated, git repo doesn't use export-subst It is not clear to me what has happened here.
Dear all, the tag v1.7.4 has been changed after October 2019. It was not published for long as it involuntarily got into a commit. There have been no public releases for v1.7.4 marked on Github or our the FIRESTARTER Website as of October 2019.
Thanks everyone for the help. :heart:
Package name: clipboard-jh Latest released version: 0.9.0 <!-- Search your package here: --- Current version on the unstable channel: 0.8.3 Current version on the stable/release channel: 0.8.3 <!-- 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]:
Describe the bug As of rust nightly 2020-06-22, Rust nightly cannot find This issue is not present in Rust nightly 2020-06-21. To Reproduce Steps to reproduce the behavior: Expected behavior rustc works Additional context This also happens with rust nightly from Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(jade): nixpkgs: Maintainer information:
We are currently using in internally to set the elf interpreter. Looks like we need to extend this to also extend the RPATH to add zlib. If someone makes a PR, I will review it! Not sure when I would get to implement that myself.
Here is where we add :
I'm working on a patch for this. This is definitely the issue, just need to find the right way to extend the RPATH. I have something replacing it with a path containing zlib, but that overwrites the existing , which breaks it. I would like to verify what is setting there but hardcoding it should provide an early fix
Extending the RPATH seems not to have worked
I'm investigating patching the files in lib This issue may have been introduced by rust-lang/rust so it's likely the new zlib dependency shows up in the LLVM libraries
tests link to , however is not explicitly included in of . This issue is normally hidden, because (for example) links to and so it is brought along as a transitive dependency of . However, may not always be set to . For example, doesn't link to . As a consequence, applying the following overlay and attempting to build results in the following errors: does list in its , however actually refers to that only includes the wrapped compiler binaries. If my understanding is correct, is provided by instead. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Describe the bug Just lost on two different NixOS machine my Signal Desktop history because of this faulty update... I don't know, probably doesn't make sense for people to downgrade who are already upgraded but for others it dataloss To Reproduce Steps to reproduce the behavior: Signal Desktop Signal Desktop you to delete db, if you interact in a wrong way it will delete your data Notify maintainers ( and
Sorry to hear that. I recently lost my history too... It's really frustrating! Yeah, unfortunately I don't think there's anything we can do about it (as downstream package maintainers). AFAIK the source of the bug is still unknown, it doesn't seem to affect all users, and all releases have a limited lifetime ("expire" 90 days after the release, see my comment in ). Thanks for saying that! This really bothered me too... I just didn't say anything because I was too angry to keep it nice enough. (I raged a bit here but after I realized that one cannot even import old backups I had to take a break.)
I just got hit by a similar issue by moving from Archlinux (encrypted database) to NixOS (non encrypted database). After many things, the easiest fix to ensure proper functionalities IMHO is installing: This will disable tracker3 and prevent SQLite to be loaded in the process which will replace SQLCipher and cause the SQLite3 API to be the original one (i.e. non-encrypted) and cause many issues down the road I guess. That might not fix everything though :upsidedownface: Opened a PR:
FYI, in case anyone has feedback/suggestions: We might merge soon and it should cause another "Database startup error: Error: SQLITE_NOTADB: file is not a database" error (which is really unfortunate but not easily avoidable).
Heads-up: I've just merged to hopefully resolve this once and for all and the Python wrapper script should take care of the database re-encryption when launching Signal-Desktop as usual but the user experience isn't that great and you probably want to backup first in case the script fails unexpectedly.
Thank you, I just upgraded Signal on my computer and the re-encryption did work as intended
The option, which enables by default on high-resolution displays like my 4K laptop screen, is supposed to set the console font within the initrd before displaying the LUKS password prompt. However, with , this does not happen until stage 2, so the prompt is tiny. Enable , , and . The console font should be switched before the LUKS password prompt, not after.
Relevant code is probably that it sets . should then properly set everything up if it can find its files in :
Does it work when you do ?
No, it can’t, because points to a font file that’s not present in the initrd.
This works though. It’s a little jarring in that the font is changed about a second before the framebuffer resolution is changed, so it’s temporarily huge. Ideally those would happen simultaneously. But at least they both happen in time for the LUKS prompt.
The emacs package fails to build against the poppler version introduced in . See upstream issue vedang/pdf-tools. Steps to reproduce the behavior: should build Build log: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I'm seeing the same thing.
Same for me
Here's a work around:
Since above PR is merged and pdf-tools builds on current HEAD, I will close this.
Scream does not compile with jack support when it is explicitly enabled through an overlay. nixpkgs.overlays = [ (final: prev: { scream = { jackSupport = true; }; }) ]
Error message?
There is no error, it just skips compiling it. someone else ran it and i think they said that it skips compiling it with jack support because soxr is missing -- Checking for module 'jack' -- Found jack, version 1.9.19 -- Checking for module 'soxr' -- No package 'soxr' found
See . In the meantime, you can try: nixpkgs.overlays = [ (final: prev: { scream = ( { jackSupport = true; }).overrideAttrs (old: { buildInputs = old.buildInputs ++ [ ]; }); }) ]
In the vault options, vaults can only be mounted as . Steps to reproduce the behavior: cryptomator to a vault options the tab, the combo box does not contain a FUSE item Vaults can be mounted as FUSE volumes In the console output, cryptomator seems to have access to the fuse3 libs in its PATH: Full console output:
I think this might be related to It seems since they switched to the new fuse integration they only search a predefined number of paths. This is also consistent as the nix build of cryptomator works on non nixos linux.
I have the same issue. Does somebody have some workaraound yet? EDIT: so what I am currently doing, which is really not ideal, is just mounting the webdav directory with rclone, which, well, uses FUSE. so yeah rclone has no problems with using FUSE...
The fix for this is merged but not yet released It's in the 4.0.0 milestone of fuse-nio-adapter. I'm currently using the flapak version of Cryptomator.
thank you for the answer! i don't quite understand what is. Is it a dependency of ? Is there a way to manually fetch this so that it works? I'm gonna try the flatpak version of Cryptomator out, thanks for the hint. I actually tried out appimage, but that didn't change anything.
In the 1.11.0-beta2 release of cryptomator, vaults are able to be mounted as FUSE volumes. So once 1.11.0 is fully released (and the nixpkgs version updated), this issue should be fixed. Until the new version of cryptomator is released, you could create an overlay to use the beta version, like I am doing at the moment. Apart from changing the version and hashes, I also needed to change the jdk used to a jdk21 and overriding it to enable JavaFX:
thank you for your response! i hope i am not rude to ask for your help in achieving this myself. i put the following in my : and i also did the overlay.
Hello, I recently submitted a pull request to update Tailscale in the NixOS repository (). After updating my laptop, I noticed that Tailscale has indeed been updated. However, upon checking the Tailscale dashboard, I discovered an issue with the displayed version number. Here's a screenshot that demonstrates the problem: ! It's possible that something has changed on Tailscale's end, which may require us to modify our build script accordingly. Unfortunately, I am not well-versed in Go yet and could use some assistance in resolving this issue. Any help or guidance would be greatly appreciated. Ping maintainers:
nix fails to build libjack2 and libpulseaudio on darwin too (probably another two issues should be filed?). mpd build log is the third one. After disabling libjack2: After disabling libpulseaudio: I'm no expert in c++ but quick googling shows that exceptions are disabled by default when building with xcode toolchain. On a side note, which way is proper to manage ? I'm editing expression in but not sure if that is the right way. I'm using OS X 10.10.4, nix-env 1.9, nixpkgs from master HEAD.
Compilation fails on throw from boost library and mpd sources are compiling with , so I've to mpd expression but still no luck here.
Seems like this didn't get resolved and it's been a while... I have mpd failing to build on Darwin also, but with a different error, CoreAudio related. I'm using a local nixpkgs checked out at , OS X 10.11.3. Here's the failure:
Package name: vorta Latest released version: 0.9.1 <!-- Search your package here: --- Current version on the unstable channel: 0.8.12 Current version on the stable/release channel: 0.8.12 <!-- 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]:
Describe the bug flatpak-builder for some reasons can't use rofiles-fuse To Reproduce Steps to reproduce the behavior: build any app using flatpak-builder Expected behavior flatpak-builder should use rofiles-fuse. Screenshots Additional context Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(piotrek): nixpkgs: Maintainer information:
installing solve this problem so maybe should be ?
We patch the paths to the executables to be hardcoded, so the program doesn't have to rely on something like ostree being installed. I believe one path isn't hardcoded with the current patch That looks it up in PATH, probably why it was working once you installed it.
cc
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
should fix that issue.
cudaPackages.cudagdb is broken for aarch64. Steps to reproduce the behavior: latest nix on system (e.g. Linux docker container on Apple Silicon Mac, Graviton instance on AWS, Nvidia Jetson device, Raspberry Pi) use , i.e. run command fails with Derivation success without an error. I also made an investigation and corresponding fix. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
In current master branch pythonPackages.mysqlclient fails to build. Checkout nixpkgs on revision and run: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Most likely caused by . Unfortunately, the config-tools are not very configuration friendly. Until is resolved, I would add to the package.
Unfortunately this does not change anything, still failing with the same error message..
Hmm, apparently just hardcodes the path without the ability to override it from the attrset passed to : Is that intentional, Until this is resolved, you can use :
When setting a registerPassword for the public server list, it doesn't actually write it to the file, forcing me to hardcode it with extraConfig. Steps to reproduce the behavior: the registerPassword option; the system; the contents of . The registerPassword option should be written to It may be a problem with at line 36 where it has a double equals instead of a exclamation mark equals like the other parameters in that code block, although I'm not really sure. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Oof that's exactly right. It seems to have been by by