jiebi/CodeConvo huggingface dataset:
Fetchers are hard to test because when the output sha is verified, Nix won't download it again. This leads to confusion and PRs that are effectively untested because the others do not realize that they need to remove the store path before testing. Examples: Steps to reproduce the behavior: a fetcher -build the fetcher -build "success" but the fetcher is broken a PR effort The fetcher runs every time. This is expected but not realistic, because Nix can not guess what to re-fetch. Instead, we can make fetcher testing easier by adding fetcher tests following the pattern: So this uses IFD which is probably ok for ofborg? Regarding ; instead of somewhere, we'll have to use to set on the fetchers because they're functions. The salt may need to be passed externally in case of pure evaluation. We could make it a Nixpkgs parameter that defaults to . <!-- 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:
Workaround: Use followed by
Or we can just put the salt in the parameter. Nix isn't clever enough to find same-hash renames in the store :)
And the salt can be derived from the unsalted drv path, which is exactly what we want. See
When using ffsend from nixpkgs, after uploading a file, the program segfaults. Using Nix on macOS with an M1 chip, but also tested it in a NixOS VM (arm64). Don't know if it works on x86. Steps to reproduce the behavior: The link to the file should be shown. Using the version from homebrew on macOS works. It even works when compiling it from source using cargo through nixpkgs (on macOS): only changed the version last time and last edit was four years ago Please run and paste the result. macOS: NixOS:
What version of rustc are you using to compile ffsend outside of nix?
I'm not familiar with Rust, I just ran in the ffsend git directory and it "just worked" so whichever version is currently in nixpkgs (at least on macOS). I haven't installed Rust on my machine.
Thanks, I have performed a bisection on nixpkgs and the regression was introduced in , so I just wanted to check that it could work with the latest rustc
Project description awatcher is a window watcher designed to be used in combination with Activitywatch, an open-source time tracker that is already in nixpkgs. Activitywatch needs a window watcher program running to get info on what programs are open and for how long. nixpkgs already includes the default window watcher (aw-watcher-window) and the WIP wayland version (aw-watcher-window-wayland), but awatcher supports both X11 and Wayland, while featuring better Wayland support than aw-watcher-window-wayland. This would allow using Activitywatch in combination with KDE or Gnome on Wayland or when running Hyprland. Metadata homepage URL: source URL: license: Mozilla Public License 2.0 platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
A recent update on unstable broke compatibility between OneDriveGui and OneDrive client. Steps to reproduce the behavior: unstable to current version ( ) a OneDrive profile configured in OneDriveGui OneDriveGui window OneDriveGui correctly recognizing the cli client ! After some investigation on their respective repos, it appears that OneDriveGui 1.0.3 is not compatible with OneDrive 2.5.x, now in rc (and in Nixos unstable) so this is going to stay broken until OneDriveGui releases their 1.1.0 version. There's an open issue on their repository... which points to an alpha release of the new gui... it might be of interest to package that one on unstable. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
FYI , v2.5.0 will GA 16th September 2024 AEST
Describe the bug When running the Mixxx package it fails to open and prints: Steps to reproduce the behaviour: 1) Run 3) Run from the command line. Expected behavior Mixxx opens its GUI Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
this needs a fix in
Can confirm running for example on my machine works.
Does not fix this for me. I've created: which does
Describe the bug causes Lego to fail. To Reproduce Steps to reproduce the behavior: set on an enabled certificate. to this configuration. fail. Lego complains about an unrecognized (really misplaced) flag. Expected behavior The certificate will be successfully fetched, with Must-Staple enabled. Screenshots Additional context I think the problematic code is here: should not be in commonOpts, it should instead be in runOpts and renewOpts. Lego runs successfully when is to and . Notify maintainers (the acme team) Metadata Maintainer information:
Thanks for the report :) It appears that the --must-staple option is common to both "run" and "renew" modes, but is not actually a common option that can be specified before the mode. I'll get a PR ready for this.
Steps to reproduce the behavior: system configuration with Freetube in it. See and for the exact same issue with Morgen. Electron version lock seems to have been introduced with . Upstream seems to be at Electron 27: . and
Maybe we could add the patches from It looks like they were waiting for a nixos user to test it and eventually gave up on us.
are you able to test ?
Looks good as far as I can tell.
fails on this branch, for whatever reason.
Related to Project description Jitsi Meet desktop application powered by Electron Metadata homepage URL: source URL: license: Apache-2.0 platforms: unix, linux, darwin,
+1 as the App seems to have some benefits over using just a browser. Whoever starts working on this, please remember to deactivate the auto-update functionality.
Also I would suggest to make sure we are using a recent version of Electron and nodejs, as don in this fork:
There was a 2.0.0 release two days ago: I think this fixes the outdated dependencies issue mentioned in the previous comment.
Yes a pull request from the fork I mentioned before was accepted.
I fixed the outstanding issues and PR is ready for review
When building chromium with args like this and the gn args aren't known/accepted by chromium (like the above one actually is that is still given incorrectly in 18.03), it will print: but continue to build anyway, which can be super surprising when your build doesn't do what you expect. We should catch that when building. Unfortunately doesn't seem to have a feature to warn. But we can run to see the in stdout and grep for it: I have confirmed that only seems to work that way when giving a build target, like . CC
Suggestion: We switch to
PR
pull request was merged.
Describe the bug I'm trying to use NixOS in a UPS client (not server). When , the and services shouldn't be running. There is a note that says that is not used currently. To Reproduce Steps to reproduce the behavior: Error: and fail. Expected behavior only upsmon should be running Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Maintainer information: See also
Looks like there's a pretty simple workaround:
I marked this as stale due to inactivity. &rarr;
Describe the bug The following snippet: results in services failing to start due to missing config files etc. : : ( fails too, but that could be down to the fact that I haven't plugged the UPS in yet -- but for the record, it complains ) Expected behavior I'd expect the services to start successfully (and probably complain about the missing actual UPS). Notify maintainers (The UPS module appears to have received only drive-by changes for the last several years, so no idea who to bug personally). Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
OK, should've read the whole module: I'm supposed to supply the missing /etc/nut files myself because it's unwise to keep them in the store (they could contain passwords and whatnot, I guess?). Declaring (in the service definitions) the state directory to be but creating for the purpose appears to be a real bug, though :)
Also (sorry for the semi-off-topic) what are best practices for referencing hand-written config files without their contents winding up in the store? Double-symlinking? If this is documented somewhere, then I haven't found where.
I was struggling with the same problem as until I noticed this bug report. After copying and editing , , and from to (and setting on all those files), I was able to get it to work. I think this should be more discoverable. If it's not appropriate to copy those sample files to on the users behalf, there should at least be detailed instructions on the option to explain what else needs to be done.
I marked this as stale due to inactivity. &rarr;
Agreed this should be more discoverable. Perhaps at least could be defaulted to empty and written, since I seem to be getting away without anything in there. In case it helps anyone, I got it working with something like this:
I was hit this bug today, too. Maybe we can fix it by using a startup unit that handles the secrets and setup the state directories like nextcloud or syncthing do
Been working on today and wanted to put some notes here. Using version 2.7.4. First, isn't used by for PIDs and it will try to write to .
flags , , may be needed instead of environment variables until a 2.7.5 release. Ref: Using for debug makes it non-forking, requiring a change to the systemd unit . I was able to get to run as non-root: I'm still working on understanding how to manage state directories in NixOS but this was needed:
I set out to get my UPS (cyberpower CP1500 AVR UPS) working with NixOS today. This was the first issue I came across, I figured this was the best place to share my configuration. I probably made this more complex than it needed to be because I have no idea what I am doing, and it is definitely not secure; one problem at a time.
Not stale; still relevant
Thanks for providing your standalone config! I learned a ton tweaking it into a netserver config! The below config creates a working NUT netserver that other machines on your local network can be connected to. The only thing I have yet to figure out is a secure way to include passwords in .nix files that won't show up if I push my local copy to github. Any ideas? If you want to tweak when NUT shuts down your computers you can modify the values of " = <percentage" and " = <seconds" under "directives". SHUTDOWNCMD will be triggered when both conditions are met. The "ignorelb" directive is necessary to have NUT ignore the UPS's defaults. Anyone using this config may want to make sure SHUTDOWNCMD and NOTIFYCMD point to the correct binaries in their filesystem. One other thing of note is to check the value of the "schedulerRules" field under below. You must give it the path to your file. I just put a copy of it inside my /etc/nixos. Could probably add another variable to hold the path for convenience. `
For secrets in nix config, I think the current recommendation is to put it in a separate file and not include it in the repo. See also
I have been using sops-nix to commit encrypted passwords to my NixOS repo, but I have yet to put in the elbow grease to make this work with my upsmon password.
is my attempt at making generate the config files necessary for basic operation. If you are using , could you try out the changes and leave a review?
Using the latest packages from the unstable channel I am unable to enable the default virsh network. The error indicates an issue with the firewall backend, but I disabled the firewall systemwide through: = false; What am I missing here? system: host os: multi-user?: sandbox: version: channels(root): channels(tim): nixpkgs:
Have you looked into libvirtd logs for a better characterization of the issue ?
Yes but I could not find anything meaninful, but I'll continue trying to find something
I'm seeing this the 2019-12-19 04:34:37.251+0000: 4078: error : virFileReadAll:1431 : Failed to open file '/sys/class/net/virbr0-nic/operstate': No such file or directory 2019-12-19 04:34:37.251+0000: 4078: error : virNetDevGetLinkInfo:2460 : unable to read: /sys/class/net/virbr0-nic/operstate: No such file or directory Also, I noticed that ebtables was updated recently.
I'm facing the same issue. I have the nixos firewall enabled, and it complains it can't find ebtables. If I install it separately that error goes away but I still see the errors posted by above
I confirmed that reverting ebtables to 2.0.10-4 fixes this. Not sure what the next step is.
Idea: set EBTABLES_PATH=/sbin/ebtables-legacy in libvirt config.
When bumped from 2.0.10-4 to 2.0.11, the binary was renamed to , so the configure script fails to find it at build time.
Impure workaround for the desperate: add the package to , and symlink to . (I also tried from the package, which does not seem to work.)
Another workaround for less desperate: in your overlay.
I verified that providing an to the right binary in the derivation allows my VMs to work again. I tested in a overlay I maintain, from which a minimal (untested) extract to work around the issue until someone has time to come up with a more correct patch to submit upstream is:
I've confirmed that the overlay in works.
I also have the issue.
Steps to reproduce the behavior: nomachine-client Seems like nomachine changed their tar file. <!-- 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]:
It seems that NoMachine has removed the from their website and the link is now a redirect to the homepage. The new latest version is .
? this url works
Package name: nix23 Latest released version: 2.3.17 (see ) Current version on the unstable channel: 2.3.16 Current version on the stable/release channel: 2.3.16 Notify maintainers Note for maintainers: Please tag this issue in your PR. See for context. The release script apparently doesn't upload source tarballs anymore, so 2.3.17 sources look more like the other ones. There's a bunch of expressions in that might need to be revisited.
The current process for renames puts out-of-tree modules in a situation where users are confronted with warnings they can't solve, and neither can the maintainers. Steps to reproduce the behavior: one change, create the new option/package/..., create the alias with a deprecation warning that goes into effect immediately -of-tree modules, such as home-manager, nix-darwin, start emitting warnings reports warning -of-tree module maintainer can't do anything, because stable release does not have the new option All generated warnings can be resolved by the user. Suggested process: one change, create the new option/package/... and the alias but no deprecation warning 1-7 months pass. All current branches now support the new way. enable the warning on master (more on that) -of-tree modules, such as home-manager, nix-darwin, start emitting warnings warnings can now be fixed To facilitate the process, we can add an argument to functions like to indicate the first release that will support the change. We'll maintain two (hidden?) version numbers that we update during the NixOS release process. For example, at the time of writing, the only supported stable version is 21.11 and 22.05 has not been released yet. To enable warnings on , we only need to update . Interestingly, we'll be deprecating functions that deprecate without . Sounds meta, but it's not complicated. It just means that some old style deprecations will slip through the net for some more time. (also a big one, but no complaints yet)
This is also related to NixOS/rfcs, which was a previous attempt at establishing general such deprecation behaviors
I've just set on my laptop while on holiday. The timezone never updates (tried restarting, waiting a while). Running I see: I see in that the service is run as the user. If I run: I also see the message . Whereas if I run there is no output and the timezone immediately updates (as shown by an immediate change in the time in my status bar, and confirmed by running ). It seems that the user just doesn't have permission to set the timezone. in (and unset ) to see if timezone changes , look for messages with "Failed to set timezone" (will only appear if the timezone it would need to set is different than the current timezone) system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
It worked for me after a reboot. Maybe the polkit rules are not getting appliead during a ?
Steps to reproduce the behavior: unar from Full build: <!-- 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 could be related to GNUstep being updated??
Yes, that PR is the cause.
Ouch, sorry. Could've sworn I ran nixpkgs-review against it, but maybe I didn't. I'll try to see what I can do, although maybe only next week. We can also revert, if I can't find the time or nobody else comes up with a fix.
For the status on Hydra:
shows this for me: When I try to upgrade my system, I get the error “could not find any previously installed systemd-boot”. This is because the script can't deal with systemd-boot versions with a minor version appended to it, since the regex is : Fixing this is not quite straightforward sadly, since the version is later used for comparison, so fixing this requires adding support for proper major/minor version comparison in this script. <!-- 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:
related
Despite the bintools for riscv64-linux advertises the existence of , it is actually missing. Steps to reproduce the behavior: , returns the output, there is only , no the same process for , is both advertised and available. Either evaluates to , or is available in <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Looking at ;a=blob;;h=;hb=HEAD is not supported on riscv64. tracks it upstream. I don't expect progress implementing the support any time soon.
Then we should accept the second solution: mark as false, we should also double check the availability of gold on other ELF platforms.
, CVSSv3=7.5 (nixos-unstable) CVSSv3=5.3 (nixos-unstable) CVSSv3=5.3 (nixos-unstable) In InvoicePlane 1.5.11 a misconfigured web server allows unauthenticated directory listing and file download. Allowing an attacker to directory traversal and download files suppose to be private without authentication. In InvoicePlane 1.5.11, the upload feature discloses the full path of the file upload directory. InvoicePlane 1.5.11 doesn't have any rate-limiting for password reset and the reset token is generated using a weak mechanism that is predictable. Scanned versions: nixos-unstable: . Cc
Describe the bug fcitx-qt5 fails to build on unstable: To Reproduce Metadata nixos unstable
It's trying to install into qtbase . Probably should set this to be within the proper prefix.
yep I've seen that as well. Seems like some packages set to work around this but haven't had the time to test it yet. EDIT: that fixed the first problem but not the second one:
will fix this.
This is still an issue on stable -- Installing: /nix/store/phkl5sfpn4jvncjd2sa29g182gpmmja7-fcitx-qt5-1.2.3/share/locale/zhCN/LCMESSAGES/fcitx- -- Installing: /nix/store/phkl5sfpn4jvncjd2sa29g182gpmmja7-fcitx-qt5-1.2.3/share/locale/zhTW/LCMESSAGES/fcitx- -- Installing: /nix/store/g83143pyn6sc1x1nqqjcamap4c2b1rbw-qtbase-5.12.0-bin/lib/qt- CMake Error at (file): file INSTALL cannot copy file "" to "/nix/store/g83143pyn6sc1x1nqqjcamap4c2b1rbw-qtbase-5.12.0-bin/lib/qt-".
Call Stack (most recent call first): (include) make: * [Makefile:106: install] Error 1 builder for '/nix/store/ypfmrmajq452nmskg0ffwa27hm58l492-fcitx-qt5-' failed with exit code 2 cannot build derivation '/nix/store/hdsvn6hc7h7wf29kdnpvr7iaivplyyb8-fcitx-with-plugins-': 1 dependencies couldn't be built cannot build derivation '/nix/store/4lwxfbacn5fcymlm3jpv6wl4anllxmzd-system-': 1 dependencies couldn't be built cannot build derivation '/nix/store/d4k8dywj47xrbxfmvdaw4gywnwdn874r-xsession-': 1 dependencies couldn't be built cannot build derivation '/nix/store/fj8xinm3fjd7sp9s20iqg23yx27zc193-nixos-system-voyagertwo-': 1 dependencies couldn't be built error: build of '/nix/store/fj8xinm3fjd7sp9s20iqg23yx27zc193-nixos-system-voyagertwo-' failed Note that I have a following setting in environment.extraOutputsToInstall = ["out"]; environment.pathsToLink = [ "/share/locale" ];
:confused: Didn't expect that to broken the same way on stable. please open a separate issue requesting some sort of backport for the relevant commit
Still seems to fail on unstable?
, (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
On it
Done
Describe the bug build of OpenEXR fails to find -lImath24 To Reproduce Expected behavior Successful build. Screenshots Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(jfelice): nixpkgs: Maintainer information:
Something seems to be mangling the library names incorrectly? The ilmbase package contains: Notice the periods.
cc.
I lack the hardware to debug this. any ideas?
Repro'd on 10.14
seems to indicate that autoconf-based builds are only supported on linux - we may want to switch this to cmake. Building outside of nix via cmake is working fine for me.
can you give a try?
I can confirm this still builds on at least.
appears to fix this for me (macos 10.14). Reopen if it's still a problem for you.
While deploying a machine via deploy-rs, I had this error: Then stop docker or deploy the service from scratch, my belief is that docker-prune can start before docker.service and thus fail since it can't access the docker daemon. No systemd error whatever the configuration. I believe a patch like this should fix it but I am no systemd expert: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- from blame current unstable
I think the patch you propose makes sense. Could you open an PR for it?