Question: systemd.services = { "nextcloud-setup" = let <ins> c = cfg.config; writePhpArrary = a: "[${concatMapStringsSep "," (val: ''"${toString val}"'') a}]"; </ins> overrideConfig = pkgs.writeText "nextcloud-config.php" '' <?php <ins> ${optionalString (c.dbpassFile != null) '' function nix_read_pwd() { $file = "${c.dbpassFile}"; if (!file_exists($file)) { throw new RuntimeException(sprintf( "Cannot start Nextcloud, dbpass file %s set by NixOS doesn't exist!", $file )); } return trim(file_get_contents($file)); } ''} </ins> $CONFIG = [ 'apps_paths' => [ [ 'path' => '${cfg.home}/apps', 'url' => '/apps', 'writable' => false ],

If nobody else wants to take over, I'd volunteer to do this during the next week as investing time on improving the nextcloud module is one item on my todo list :) I was aware of being stateful, but thanks a lot for linking the corresponding ticket! I'll have a look at this as soon as I have sufficient time to :)
In the light of this issue, what's the correct way to upgrade nextcloud to a new major version? Do I just pull a newer , upgrade my system and hope that the systemd job will do the right thing?
The service runs an that should apply all changes like database migrations needed for the new Nextcloud version (beware, downgrades aren't possible). As long as you let Nextcloud do its job, you shouldn't get that much issues. IMHO the actual problem here is the configuration of the software within Nix(OS).
just a simple question (could not come to a conclusion after the lengthy thread) but I recently updated my nextcloud via nixops deploy and the update disabled the calendar module. Did I mess up or is that expected ? any way to configure this from nix ?
Assuming that you installed the calendar module via the UI, it is installed in . The beginning of my config reads: So in principle nextcloud can edit the apps installed via the web interface (otherwise you couldn't install them via the interface in the first place).
I don't think there's anything actionable here - the nextcloud nixos module is limited by how Nextcloud (imperatively) manages its configuration. The current state is properly documented in , and we raised our concerns to upstream in - closing this issue, feel free to reopen if there's more to be done.
I think one actionable item would be to have the nextcloud service fail with an explicit error if the configuration being used is not compatible with the configuration defined in the .nix. At least the user would be warned in practice that configuration is not really applied, and not only by the manual that they are relatively unlikely to actually read. Reopening for now, feel free to reclose if you think that's not a reasonable “solution” :)
The problem is we don't know whether the configuration on disk containing database connection information () differs from the one that would be generated through an installation via - we don't render the configuration on our own, but the installer writes it out as a side-effect.


Question: systemd.services = { "nextcloud-setup" = let <ins> c = cfg.config; writePhpArrary = a: "[${concatMapStringsSep "," (val: ''"${toString val}"'') a}]"; </ins> overrideConfig = pkgs.writeText "nextcloud-config.php" '' <?php <ins> ${optionalString (c.dbpassFile != null) '' function nix_read_pwd() { $file = "${c.dbpassFile}"; if (!file_exists($file)) { throw new RuntimeException(sprintf( "Cannot start Nextcloud, dbpass file %s set by NixOS doesn't exist!", $file )); } return trim(file_get_contents($file)); } ''} </ins> $CONFIG = [ 'apps_paths' => [ [ 'path' => '${cfg.home}/apps', 'url' => '/apps', 'writable' => false ],

If I'm not missing something obvious, checking configuration changes would translate to parsing/evaluating on every nextcloud startup as an , comparing every "interesting" key with the one provided through nixos configuration, and eventually then bailing out if they differ. I'm not sure if that's a road we'd like to go and keep up to date, while the underlying bug is a missing distinction between configuration and state upstream…
Since upstream mixes state and config it's questionable whether their configuration format is somehow supposed to be backwards-compatible (as it's only supposed to be used internally by Nextcloud). Hence I'm afraid that this will make i.e. upgrades even harder in case of configuration changes, so :-1: from me. As the issues are documented in the manual now, folks are warned and I think that this is a better option in contrast to adding more complexity to . I suggest we either close this for the reasons already stated or wait for an appropriate upstream fix.
I really don't feel good having stuff in that's actually a disguised command line… :/ Something that would sound nicer to me would be an executable that the user would have to manually run, and a bare-bones module that does not handle setup or configuration and just makes sure that the systemd unit is setup. At least the error is obvious (enabling the module without having run the executable would fail), all module options actually mean something, and the impure operation is made explicit. Either that or, similar to , rename all the options so it's explicit that they're used only for initial configuration. Would one of these solutions make sense to you?
Me neither, but currently we don't have much choice… I really like the fact that we can set up the Nextcloud instance in an unattended fashion, without having to worry about manual setting things up. I really don't want to end with more imperative setup steps than necessary. In theory, we could move some of the options in to to make it more obvious what isn't applied continuously. But TBH, I'd rather like to see the state/config mixing fixed upstream than having to introduce more mental complexity here, especially if this gets fixed and we end up with both incarnations. Really, this issue only occurs while a user changes nextcloud database parameters (mostly while tweaking his initial setup), and not having read the module documentation, where the behaviour is documented.


Question: systemd.services = { "nextcloud-setup" = let <ins> c = cfg.config; writePhpArrary = a: "[${concatMapStringsSep "," (val: ''"${toString val}"'') a}]"; </ins> overrideConfig = pkgs.writeText "nextcloud-config.php" '' <?php <ins> ${optionalString (c.dbpassFile != null) '' function nix_read_pwd() { $file = "${c.dbpassFile}"; if (!file_exists($file)) { throw new RuntimeException(sprintf( "Cannot start Nextcloud, dbpass file %s set by NixOS doesn't exist!", $file )); } return trim(file_get_contents($file)); } ''} </ins> $CONFIG = [ 'apps_paths' => [ [ 'path' => '${cfg.home}/apps', 'url' => '/apps', 'writable' => false ],

What about adding the following (subtile) log statement, to point users to the docs when they peek into the logs while things are not working as expected?
I agree that the log statement is the minimum we can do, and would at least give a hint about the way in which things are broken. Now, I guess the reason we're kind of disagreeing on the path forward is that you're much more hopeful than me that nextcloud will ever fix its stuff -- I'm assuming it'll get fixed in years at best (and even then…) -- and if it's in years then I'd much rather live with for years then spend a year deprecating it by making it conflict with new options than try to live with from now on and have users fail to understand what is going on. Now urhm, I'm investigating the module a bit deeper, and… is there any reason we can't put the database configuration etc. in ? We could then refresh on each activation, and it should be enough? If we have a way to couple it with something that automatically runs iff the database is not ready yet then the setup would actually be… almost perfect?
After having a deeper look at the sources ( at github, (6 commits ahead of v16.0.0RC1)) I guess that this should be possible (I didn't test it yet though). Configs will be loaded from using PHP's function[1] while all files ending with will be taken into account. Hence works as all config arrays will be merged together. This config will be loaded at [2] and is available as which is then used in the DI container[3]. If I understand the code correctly, I assume that it should be possible to render all config options in as config files found by glob will override values from [4]. [4]
Nice catch! This might indeed be possible - we should make very sure that config overrides work the way we think they will - seems to write the merged configuration, and not just the overrides (and merging this with other config in the wrong order can lead to wonderfully weird to debug issues) ;-) While I'd still prefer nextcloud splitting config and state properly, and being able to cope with read-only (base) config - it might be a direction worth exploring. What do you think?


Question: systemd.services = { "nextcloud-setup" = let <ins> c = cfg.config; writePhpArrary = a: "[${concatMapStringsSep "," (val: ''"${toString val}"'') a}]"; </ins> overrideConfig = pkgs.writeText "nextcloud-config.php" '' <?php <ins> ${optionalString (c.dbpassFile != null) '' function nix_read_pwd() { $file = "${c.dbpassFile}"; if (!file_exists($file)) { throw new RuntimeException(sprintf( "Cannot start Nextcloud, dbpass file %s set by NixOS doesn't exist!", $file )); } return trim(file_get_contents($file)); } ''} </ins> $CONFIG = [ 'apps_paths' => [ [ 'path' => '${cfg.home}/apps', 'url' => '/apps', 'writable' => false ],

Well, for the record it was actually idea :sweat_smile: I guess so, all the stuff from is also in my at the moment. I'll probably have sufficient time next weekend to check if I can trigger such a case. I can't promise that, but unless anybody beats me, I can hopefully prepare a fix for this :)
Did you gain some new insights on this?
Unfortunately not... I was pretty busy back then. But as this only requires some fiddling in the module and no patching of the actual package, the change shouldn't be too painful, so if you'd like to take over... :sweat_smile:
there's with a fix now :)


Question: , gobject-introspection , lib , libsoup <del> , llvmPackages_15 </del> , makeBinaryWrapper , nodejs <ins> , openssl </ins> , pango , pkg-config , pnpm

Package name: surrealist Latest released version: 2.0.1 <!-- Search your package here: --- Current version on the unstable channel: 1.11.7 Current version on the stable/release channel: - <!-- 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 Surrealist has now officially moved to the SurrealDB Github org, see Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Nvm the nix package is actually built from source, just Tauri builds a deb in that process
Working on it. I'm currently stuck at an issue with the frontend build. There is a transitive dependency to that does not get installed by pnpm.


Question: <ins> --- a/src/plugins/platforms/cocoa/qcocoawindow.mm +++ b/src/plugins/platforms/cocoa/qcocoawindow.mm @@ -404,8 +404,8 @@ void QCocoaWindow::setVisible(bool visible) removeMonitor(); monitor = [NSEvent addGlobalMonitorForEventsMatchingMask:NSLeftMouseDownMask|NSRightMouseDownMask|NSOtherMouseDownMask|NSMouseMovedMask handler:^(NSEvent *e) { QPointF localPoint = QCocoaScreen::mapFromNative([NSEvent mouseLocation]); -                            const auto button = e.type == NSEventTypeMouseMoved ? Qt::NoButton : cocoaButton2QtButton([e buttonNumber]); -                            const auto eventType = e.type == NSEventTypeMouseMoved ? QEvent::MouseMove : QEvent::MouseButtonPress; +                            const auto button = e.type == NSMouseMoved ? Qt::NoButton : cocoaButton2QtButton([e buttonNumber]); +                            const auto eventType = e.type == NSMouseMoved ? QEvent::MouseMove : QEvent::MouseButtonPress; QWindowSystemInterface::handleMouseEvent(window(), window()->mapFromGlobal(localPoint.toPoint()), localPoint, Qt::MouseButtons(uint(NSEvent.pressedMouseButtons & 0xFFFF)), button, eventType); }]; </ins>

It looks like Qt has broken support for SDK 10.10 in their latest release. Here is the log: Any ideas on how we can fix this?
fixes this.
We should probably keep this open tho, we can't keep using


Question: <ins> { "name": "gotify-ui", "version": "0.2.0", "private": true, "homepage": ".", "dependencies": { "@material-ui/core": "^4.4.3", "@material-ui/icons": "^4.4.3", "axios": "^0.19.0", "codemirror": "^5.43.0", "detect-browser": "^3.0.0", "js-base64": "^2.5.1", "mobx": "^5.1.1", "mobx-react": "^5.2.8", "mobx-utils": "^5.0.2", "notifyjs": "^3.0.0", "prop-types": "^15.6.2", "react": "^16.4.2", "react-codemirror2": "^5.1.0", "react-dom": "^16.4.2", "react-infinite": "^0.13.0", "react-markdown": "^4.0.6", "react-router": "^4.3.1", "react-router-dom": "^4.3.1", "react-timeago": "^4.1.9", "remove-markdown": "^0.3.0", "typeface-roboto": "0.0.54" }, "scripts": { "start": "react-scripts start", "build": "react-scripts build", "test": "react-scripts test --env=node", "eject": "react-scripts eject", "lint": "tslint --project .", "lintfix": "tslint --fix --project .", "format": "prettier "src/**/*.{ts,tsx}" --write", "testformat": "prettier "src/**/*.{ts,tsx}" --list-different" }, "devDependencies": { "@types/codemirror": "0.0.71", "@types/detect-browser": "^2.0.1", "@types/get-port": "^4.0.0", "@types/jest": "^23.3.1", "@types/js-base64": "^2.3.1", "@types/node": "^10.9.0", "@types/notifyjs": "^3.0.0", "@types/puppeteer": "^1.6.3", "@types/react": "^16.4.11", "@types/react-dom": "^16.0.7", "@types/react-infinite": "0.0.33", "@types/react-router-dom": "^4.3.0", "@types/remove-markdown": "^0.1.1", "@types/rimraf": "^2.0.2", "get-port": "^4.0.0", "prettier": "^1.14.2", "puppeteer": "^1.8.0", "react-scripts": "3.1.1", "rimraf": "^2.6.2", "tree-kill": "^1.2.0", "tslint": "^5.20.0", "tslint-sonarts": "^1.7.0", "typescript": "3.6.2", "wait-on": "^3.0.1" }, "eslintConfig": { "extends": "react-app" }, "browserslist": { "production": [ ">0.2%", "not dead", "not op_mini all" ], "development": [ "last 1 chrome version", "last 1 firefox version", "last 1 safari version" ] } } </ins>

Project description A simple server for sending and receiving messages in real-time per WebSocket. Includes a web UI, also has an Android client for receiving notifications and an optional CLI program (distributed separately) for sending notifications. Metadata homepage URL: source URL: license: MIT platforms: anything Go runs on
I started an attempt locally, however it failed due to some timeouts while fetching Go dependencies... will retry during this week :)
I think the main difficulty is the UI, which needs to be compiled with NPM. In essence, I think the build is three-staged: fetch UI dependencies, fetch Go dependencies, do the actual build.
You may want to take a look at .


Question: stdenv.mkDerivation rec { pname = "phoronix-test-suite"; <del> version = "10.8.1"; </del> <ins> version = "10.8.2"; </ins> src = fetchurl { url = "https://phoronix-test-suite.com/releases/${pname}-${version}.tar.gz"; <del> sha256 = "sha256-O1jqaUQZymCNcp+mznLtK0xRr0RHKe77zcbmcCkMqn8="; </del> <ins> sha256 = "sha256-hmgTQ9IEFYMasW72w9HDF+I0XncZJeBpiukgoDqeqrY="; </ins> }; buildInputs = [ php ];

, CVSSv3=4.3 (nixos-unstable) phoronix-test-suite is vulnerable to Cross-Site Request Forgery (CSRF) Scanned versions: nixos-unstable: . Cc


Question: xineramaSupport = true; xmlSupport = true; sdlSupport = true; <ins> mingwSupport = true; </ins> }; full = base.override {

Project description There is a great wine package currently in NixOS but it lacks mingw support for the DLLs. This is needed for a few games including World of Warcraft it seems. Basically we need to build WINE with "--with-mingw" compile flag. The problem I have here is - I have no idea how to actually include the mingw compiler as a dependency to WINE. Any help here would be appreciated. Metadata homepage URL: | source URL: n/a license: n/a platforms: linux
cc
I think something like this should work: You should see something like this in your build output: I've had to do something similar when trying build Guy1524's Easy Anti-Cheat fork:
Maybe it would make sense to add a parameter to handle this?
I am not sure what it actually does, but maybe
Thanks a lot for that - I also another problem which your linked code sorted - the "compiler cannot create executables" error - strictDeps looks to have solved it though. :+1: I can tell you - it uses the mingw compiler to compile "PE DLLs" (I believe this is in reference to Windows PE DLLs but could be wrong.) It then uses these in place of the normal fake builtin DLLs it uses. This enables a much more convincing Windows environment which some apps / games appear to need.
Ahhh makes perfect sense. Do I understand correctly that build closure grows quite a bit? Any impact on runtime closure? I will merge a PR adding an off-by-default MinGW option, absent some well-grounded onjections, but maybe it should indeed be off-by-default. I guess if runtime closure change is small and build closure change is within 20% or so, we could enable by default…
I'm not too sure what closure means in this context D: What I will say, however, is that this is OFF by default in most distros so I think it should be as an option and not enabled by default - just as you suggested. Your changes got me a lot further in to the build but I believe I am missing one critical change - the build runs correctly and starts building DLLs via mingw but then fails out with: Actual overlay pkg (including the fix for exactly this error from your code linked above.) I wonder if mingw is ignoring the hardeningDisable flag or is using defaults somewhere?


Question: xineramaSupport = true; xmlSupport = true; sdlSupport = true; <ins> mingwSupport = true; </ins> }; full = base.override {

We're so close to fixing this I can feel it! :+1: :
I think Arch builds wine with mingw: () In official wine repos for fedora () there are lines: and for Ubuntu (), there is mingw-w64 in . So, if it doesn't increase closure size by too much, I'd say it's a good idea to enable it by default.
Transitive closure: deps, deps-of-deps, deps-of-deps-of-deps-of-deps… This can go over runtime or build-time dependencies, of course But yes, no need to look too deeply into impact if the default is off.
Hmm, it worked for me when specifying . Maybe there is a problem with using ? The Nixpkgs manual strongly recommends using instead of . I think it's very likely that's the cause: I'll gather information about the closure sizes for each configuration (wine32, wine64, wineWow) and I'll also look into creating a PR that adds a new support flag.
I hadn't noticed that little difference - changed it to overrideAttrs and it's now building properly from the looks of things. Thanks again for all of your help on this - that's super helpful! :+1: It looks like it was disabled by default in Gentoo (in: ) due to the following bug: ^ This may not be all that relevant to NixOS - just wanted to bring it to your attention.
Hm, interesting. We'll see. if it is default-off, feel free to skip the closure-measuring step for anything you are not going to use anyway. No need to build something just for that.
I noticed that runtime closures were dramatically increased with this option: wine32 (minimal): 829.3M -2.6G wine64 (minimal): 912.5M -2.6G wineWow (minimal): 1.5G -4.9G It looks like development header files from are being referenced in all DLLS under . For example, these paths are referenced in the wine32 build: Right now I'm looking into why they're being and if they can be removed / reduced.
If mingw is disabled by default, perhaps it could be as a new attribute so that it's cached?


Question: xineramaSupport = true; xmlSupport = true; sdlSupport = true; <ins> mingwSupport = true; </ins> }; full = base.override {

Considering it's enabled by default in (at least) Arch and official wine repos, some users may expect it to be enabled by default in NixOS too. Having to override wine for e.g. lutris and also build wine (which takes a pretty long time) is a lot of friction for an unexperienced NixOS user (or someone with not so powerful hardware).
Preferably we would enable it by default. Once, binutils 2.34 is which contains the we can re-enable stripping to avoid the closure increase caused by the header references.
Considering the OP mentioned specifically games, I'll just mention that lutris now ships (via its "runners" machinery) wine 5.21 with mingw.
Now that has been merged you can just use: This isn't currently enabled by default or cached, but does this solve your issue? Hopefully we can enable this on the base build once is merged, and after stripping is enabled.
I don't seem to be able to overwrite to enable . It does work for though. It complains about a missing hexdump dependency and a patch that it is unable to apply.
Did you eventually get WoW 9.0.2 running? Starting ends in an Access Violation popup for me. This is on wine 5.22:
Just a heads up, I noticed a regression running Cities: Skylines (specifically the Paradox Launcher) with : It looks like this is a problem upstream (I have the exact same problem with Lutris wine), but for now I'm just forcing it to launch with a wine built with .
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Question: buildPythonApplication rec { pname = "protontricks"; <del> version = "1.4.4"; </del> <ins> version = "1.5.0"; </ins> src = fetchFromGitHub { owner = "Matoking"; repo = pname; rev = version; <del> sha256 = "0i7p0jj7avmq3b2qlcpwcflipndrnwsvwvhc5aal7rm95aa7xhja"; </del> <ins> hash = "sha256-IHgoi5VUN3ORbufkruPb6wR7pTekJFQHhhDrnjOWzWM="; </ins> }; patches = [

This issue is mainly a note to myself since the upgrade won't be trivial and will need a lot of testing. Protontricks is now using the Pressure Vessel runtime, so I have to refactor my patches with steam-run to account for this. <!-- 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 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: protontricks <!-- The current version can be found easily with the same process than 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: 1.4.4 desired version: 1.5.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: myself


Question: # Update the start menu for each user that is currently logged in system.userActivationScripts.plasmaSetup = activationScript; <del> services.xserver.displayManager.setupCommands = startplasma; </del> nixpkgs.config.firefox.enablePlasmaBrowserIntegration = true; })

On a fresh install, lightdm is writing several files to / These should probably be either in /root or in some other runtime .cache and .gtkrc-2.0 Steps to reproduce the behavior: NixOS with X enabled, using the default lightdm display manager. soon as the display manager starts, files are written to / That my / will stay clean. If I stop display-manager.service, delete the files, then restart it, the files return. Looking in my /etc/passwd, shows that lightdm does have a home directory set at /var/lib/lightdm. But for some reason these files are not being written there as they should be. Please run and paste the result.
I just realized after I posted this that I used an old iso from 21.11 to install. So I reinstalled with 22.05, and this still happens
Are you using KDE Plasma? Can you reproduce the issue with SDDM?
I am using KDE. The issue also happens with SDDM. I went ahead and tested GDM as well (while still using plasma,) and it does not happen.
I can reproduce. For my case, in I saw one single file with prefix, after some search it is likely cache for kbuildsycoca5 (). I have no idea what that package does so far though.
All the files in my / are exactly the files being generated in
I can reproduce this with Plasma 5/SDDM on nixpkgs-unstable.
I also observed these files, tracked down the problem and prepared a pull-request that -- hopefully -- fixes the issue: . I came to the conclusion that it is best to entirely remove the code that creates those file. However, I feel a bit unconfident about my solution, so it would be good to have it tested by more users. If you can spare the time, please have a look at my draft pull request, maybe try my solution, and feel free to report back or even drop a review. Thanks a lot!


Question: heimdall-gui = heimdall.override { enableGUI = true; }; <ins> headscale = callPackage ../servers/headscale { }; </ins> heisenbridge = callPackage ../servers/heisenbridge { }; helio-workstation = callPackage ../applications/audio/helio-workstation { };

Project description An open source implementation of the Tailscale control server Metadata homepage URL: source URL: license: bsd platforms: linux


Question: ''; postPatch = '' <del> # The next release will have support for later yara-python releases </del> <ins> # We have dex support enabled in yara-python </ins> substituteInPlace setup.py  <del> --replace "yara-python==3.11.0" "yara-python" </del> <ins> --replace "yara-python-dex>=1.0.1" "yara-python" </ins> ''; <del> pythonImportsCheck = [ "apkid" ]; </del> <ins> pythonImportsCheck = [ "apkid" ]; </ins> meta = with lib; { description = "Android Application Identifier";

<!-- 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: 2.1.1 desired version: 2.1.3 <!-- 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. It seems that this version has a few changed dependencies ( instead of )


Question: <ins> import ./make-test-python.nix ({ lib, pkgs, ... }: { name = "realm"; meta = { maintainers = with lib.maintainers; [ ocfox ]; }; nodes.machine = { pkgs, ... }: { services.nginx = { enable = true; statusPage = true; }; # realm need DNS resolv server to run or use config.dns.nameserver services.resolved.enable = true; services.realm = { enable = true; config = { endpoints = [ { listen = "0.0.0.0:1000"; remote = "127.0.0.1:80"; } ]; }; }; }; testScript = '' machine.wait_for_unit("nginx.service") machine.wait_for_unit("realm.service") machine.wait_for_open_port(80) machine.wait_for_open_port(1000) machine.succeed("curl --fail http://localhost:1000/") ''; }) </ins>

Project description A simple, high performance relay server written in rust. Metadata homepage URL: source URL: license: mit platforms: Linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: (onFullSupported "nixos.tests.networking.networkd.dhcpSimple") (onFullSupported "nixos.tests.networking.networkd.link") (onFullSupported "nixos.tests.networking.networkd.loopback") <del> (onFullSupported "nixos.tests.networking.networkd.macvlan") </del> <ins> # Fails nondeterministically (https://github.com/NixOS/nixpkgs/issues/96709) #(onFullSupported "nixos.tests.networking.networkd.macvlan") </ins> (onFullSupported "nixos.tests.networking.networkd.privacy") (onFullSupported "nixos.tests.networking.networkd.routes") (onFullSupported "nixos.tests.networking.networkd.sit")

Describe the bug The last several Hydra trunk-combined runs have been blocked by (among other problems) a , which was recently back(?) to release-combined in (). When I run the test locally it sometimes succeeds and sometimes hangs forever. To Reproduce Steps to reproduce the behavior: it succeeded, clear the result with (is there a better way to do that?) and try again. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(anders): nixpkgs: Maintainer information:
We have a lot of channel blockers currently, so I recommend to also purpose revert this one. Though it sounds like it's only with issues, so perhaps comment it linking to this issue. We can always re-add it.


Question: { stdenv, fetchurl, fetchpatch, openssl, zlib, pcre, libxml2, libxslt <del> , gd, geoip </del> <ins> , substituteAll, gd, geoip </ins> , withDebug ? false , withStream ? true , withMail ? false

If you serve files from , nginx will set last-modified header to unix timestamp 1. The result is that browser will cache indefinitely. Not sure what we should do about it really, following nginx configuration helps:
Why do you need to turn etag off?
Ah, I see. nginx's etags aren't hashes.
I wonder if we could find a way to pull the hash out of the nix store path and put it into an etag header.
Thanks for finding this. I've been having issues with broken caching on my nginx/nixos server. Even when the files on the server were updated (files in the nix store), the browser was told that no change had happened. If I'm understanding this correctly, since nginx's etags are based on filesystem modification time; you can't have proper cache invalidation (ie. it will always send 304 not modified). Or is there a workaround?
+1 this is a problem. And turning off etag seems like overkill. Is there some way to 1) set the date on a file so that Nginx can pick it up, or 2) do something else awesome?
Is the zero-timestamp rule set in stone in Nix, or is there some way to override it if you really want a file in /nix/store to have a particular timestamp?
I think we could get away with: It's not perfect, as it will change on each Nix evaluation instead of being content addressed. Another way would be to turn the store path passed to nginx directive to translate into an etag.
The etag function is at called from and . Making it dependent on the realpath of the file seems doable.
Explanation how to configure nginx to use the hash from the nix path:
In my testing, this sends the correct etag, but does not send the 304 not modified, when the etag matches. Also, the header gets stripped out when compression is enabled.
It's working perfectly for me. I've gzip compression enabled, the etag header is sent and the browser gets a 304 when querying the header.
Nice! An example with a directory would be more common:
I've to correct what I said. your statement seems to be correct. What happens in my case is that Cloudflare is actually handling the caching of the ETag correctly, not nginx.


Question: { stdenv, fetchurl, fetchpatch, openssl, zlib, pcre, libxml2, libxslt <del> , gd, geoip </del> <ins> , substituteAll, gd, geoip </ins> , withDebug ? false , withStream ? true , withMail ? false

So this approach is completely useless without external caching. I'll investigate further and see if I can come up with a solution.
Here is a patch: If real path (after dereferencing symlinks) of is in Nix store, it will use path's hash as ETag. For example: I'll take some time to double check everything and only then send a PR. However, feel free to test: nix { pkgs, ... }: { = { enable = true; package = with pkgs; nginx.overrideAttrs (super: { patches = (super.patches or []) ++ [(fetchpatch { url = ; sha256 = "16pa1vwcm7kibkjsxpk3szaa2vnxdinml6v0fp4038i2qaav113k"; })]; }); }; }
This is really great! or anyone, do you have a moment to write an explanation of this new feature and its practical ramifications for anyone configuring an nginx server? Since it isn't typical nginx behavior, I think the nixos manual should explain it somewhere so it doesn't catch people by surprise.
I think is a good explanation, just needs to be put into the manual.
Cool, submitted .


Question: AC_SUBST(pkgpython2dir) else enable_python_library="no (disabled, use --enable-python-library to enable)" <ins> diff --git a/data/dconf/Makefile.am b/data/dconf/Makefile.am index 5360f033..6d5e726f 100644 </ins> --- a/data/dconf/Makefile.am +++ b/data/dconf/Makefile.am <del> @@ -50,7 +50,7 @@ </del> <ins> @@ -50,7 +50,7 @@ man_5dir = $(mandir)/man5 </ins> install-data-hook: if test -z "$(DESTDIR)"; then

Upstream ibus-1.5.24 (in nixpkgs) supports gtk4. It will be good if we enable gtk4 support in nixpkgs. I fail to enable it with the following patch.


Question: # Keep consul.ui for backward compatability passthru.ui = consul-ui; <ins> preBuild = '' buildFlagsArray+=("-ldflags" "-X github.com/hashicorp/consul/version.GitDescribe=v${version} -X github.com/hashicorp/consul/version.Version=${version} -X github.com/hashicorp/consul/version.VersionPrerelease=") ''; </ins> meta = with stdenv.lib; { description = "Tool for service discovery, monitoring and configuration"; homepage = "https://www.consul.io/";

On 17.03: This is potentially problematic as consul may use the version number of peers to make decisions. Why is this?


Question: , cargo , copyDesktopItems , dbus <del> , electron_25 </del> <ins> , electron_26 </ins> , fetchFromGitHub , fetchpatch2 , glib

Steps to reproduce the behavior: bitwarden Please run and paste the result.
Will be fixed by


Question: , cmake, ninja, curl, git, pandoc, pkg-config, unzip, zip , libGL, libGLU, freeimage, freetype, assimp , catch2, fmt, glew, miniz, tinyxml-2, xorg <del> , qtbase, wrapQtAppsHook </del> <ins> , qtbase, qtwayland, wrapQtAppsHook </ins> , copyDesktopItems, makeDesktopItem }: stdenv.mkDerivation rec { pname = "TrenchBroom"; <del> version = "2023.1"; </del> <ins> version = "2024.1"; </ins> src = fetchFromGitHub { owner = "TrenchBroom"; repo = "TrenchBroom"; rev = "v${version}"; <del> sha256 = "sha256-62xcFKSqxPS+J54+kLo/hewM+Wu/rVBGD8oiECDCJpA="; </del> <ins> hash = "sha256-HNK/gLbew7MKN6GVStxDb2tyMgyw2l1+dhPr6fSaZ4A="; </ins> fetchSubmodules = true; }; # Manually simulate a vcpkg installation so that it can link the libraries

Package name: trenchbroom Latest released version: 2024.1 <!-- Search your package here: --- Current version on the unstable channel: 2023.1 Current version on the stable/release channel: 2023.1 <!-- 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]:


Question: , stdenv , mkDerivation , extra-cmake-modules <del> , fetchFromGitHub </del> <ins> , fetchurl </ins> , kconfig , kdoctools , kguiaddons

There is a hash mismatch for kstars in nixpkgs-unstable Steps to reproduce the behavior: Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Last updated by
As was spotted during the PR review , the ref is a branch not a tag.
The source of the problem is (also mentionned in a comment) a typo in the name of the latest version of kstars files (). There's now a 3.7.0 version out. So I'll suggest a new PR with this version, using the official source


Question: <ins> { lib , stdenvNoCC , fetchurl , makeWrapper # Softnet support ("--net-softnet") is disabled by default as it requires # passwordless-sudo when installed through nix. Alternatively users may install # softnet through other means with "setuid"-bit enabled. # See https://github.com/cirruslabs/softnet#installing , enableSoftnet ? false, softnet }: stdenvNoCC.mkDerivation (finalAttrs: { pname = "tart"; version = "1.6.0"; src = fetchurl { url = "https://github.com/cirruslabs/tart/releases/download/${finalAttrs.version}/tart.tar.gz"; sha256 = "1n052nwsccc3sr0jqnvhyl0six8wi46vysxjchwrdm8brnsdpf84"; }; sourceRoot = "."; nativeBuildInputs = [ makeWrapper ]; installPhase = '' runHook preInstall # ./tart.app/Contents/MacOS/tart binary is required to be used in order to # trick macOS to pick tart.app/Contents/embedded.provision profile for elevated # privileges that Tart needs mkdir -p $out/bin $out/Applications cp -r tart.app $out/Applications/tart.app makeWrapper $out/Applications/tart.app/Contents/MacOS/tart $out/bin/tart  --prefix PATH : ${lib.makeBinPath (lib.optional enableSoftnet softnet)} install -Dm444 LICENSE $out/share/tart/LICENSE runHook postInstall ''; meta = with lib; { description = "macOS VMs on Apple Silicon to use in CI and other automations"; homepage = "https://tart.run"; license = licenses.fairsource09; maintainers = with maintainers; [ emilytrau Enzime ]; platforms = [ "aarch64-darwin" ]; sourceProvenance = with sourceTypes; [ binaryNativeCode ]; }; }) </ins>

Project description <!-- Describe the project a little: --Metadata homepage URL: source URL: license: platforms: darwin


Question: }) ]; <ins> # fix implicit-int compile error in test code used in configure script postPatch = '' sed -i 's/^main()/int main()/' configure ''; </ins> hardeningDisable = [ "format" ]; outputs = [ "out" ] ++ lib.optional (with stdenv; buildPlatform.canExecute hostPlatform) "dev";

Steps to reproduce the behavior: builds fine on NixOS, not on darwin. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
does work for you? maybe something like will work while the PR is waiting to merge.
Yep! Thank you


Question: </configuration> ''; <ins> inherit (stdenv.hostPlatform.extensions) sharedLibrary; </ins> in stdenv.mkDerivation rec {

Steps to reproduce the behavior: msbuild Trying to build msbuild on a mac fails. <!-- 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.


Question: <ins> { lib , fetchFromSourcehut , makeWrapper , rustPlatform , wayland }: rustPlatform.buildRustPackage rec { pname = "waylevel"; version = "1.0.0"; src = fetchFromSourcehut { owner = "~shinyzenith"; repo = pname; rev = version; hash = "sha256-T2gqiRcKrKsvwGNnWrxR1Ga/VX4AyllYn1H25aIKt5s="; }; cargoHash = "sha256-gw5m1/btJ5zZP04C7BCnHqEOUBoeu0whK8W7xA+xSQo="; postFixup = '' patchelf --set-rpath ${lib.makeLibraryPath [wayland]} $out/bin/waylevel ''; meta = with lib; { description = "A tool to print wayland toplevels and other compositor info"; homepage = "https://git.sr.ht/~shinyzenith/waylevel"; license = licenses.bsd2; maintainers = with maintainers; [ dit7ya ]; platforms = platforms.linux; }; } </ins>

Project description A tool to print Wayland toplevels status and info. Metadata homepage URL: source URL: license: bsd platforms: linux


Question: dfilemanager = libsForQt5.callPackage ../applications/misc/dfilemanager { }; <ins> dht = callPackage ../applications/networking/p2p/dht { }; </ins> dia = callPackage ../applications/graphics/dia { inherit (pkgs.gnome2) libart_lgpl libgnomeui; };

Project description Fragments is a modern, responsive and graphical Gnome bittorrent client Metadata homepage URL: source URL: license: gpl3 platforms: linux The new version of Fragments depends on libutp which hopefully gets merged soon. I've opened a pull request for it . for Fragments.
We have transmission and torrential. Maybe that's something for you.
That's true but Fragments is a really neat, easy and modern looking torrent client. It has an adaptive interface which would also work quite well on mobile devices, for example NixOS mobile :+1:


Question: BindPaths = [ "${cfg.home}/${settingsDir}" cfg.settings.download-dir <ins> # Transmission may need to read in the host's /run (eg. /run/systemd/resolve) # or write in its private /run (eg. /run/host). "/run" </ins> ] ++ optional cfg.settings.incomplete-dir-enabled cfg.settings.incomplete-dir ++

I have transmission running inside a Nixos container which has been working without issue until I recently updated the system. It now fails to start inside the container, I have tried deleting the container and all its data but the same issue exists when creating a new one. I have also tried creating the path "" on both the host and container but it doesn't seem to care. Steps to reproduce the behavior: Run transmission inside of a container Transmission service starts and runs without issue Service status Here's where I have the container and transmission defined in my config. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Same here, not sure if it's an upstream or nixpkgs issue
For the time being and since it's inside a container anyway I'm overriding the root dir of the systemd unit:
Thanks your fix is working for me!
The problem is that is listed in : Which got introduced in to The original problem was that was not in the chroot. I'd say mounting all of as read-only is going too far, so a better fix would be to just mount and only if is true. It also seems weird to have this logic be part of Transmission, but whatever. So a workaround is: (And I'm not sure why this wasn't a problem for 3 years)
I've stumbled upon this issue as well, and wondering if there is anything we can do about it regarding the Transmission service. I had to disable the following is well, before it played nicely in my setup.
indeed, adding only was one the alternatives suggested in , so we can try your suggestion. IMHO disabling or should not be the default, we could make them use though, would that be enough for you?
This is actually still an issue and it isn't limited to containers. Adding the params that posted, unfortunately, does not work for me ;/


Question: sockperf = callPackage ../tools/networking/sockperf { }; <ins> softnet = callPackage ../tools/networking/softnet { }; </ins> solaar = callPackage ../applications/misc/solaar { }; solanum = callPackage ../servers/irc/solanum {


Question: }; preBuild = '' <del> makeFlags="V=1 DISABLE_JBIG=1 CUPSFILTER=$out/lib/cups/filter CUPSPPD=$out/share/cups/model" </del> <ins> makeFlags="$makeFlags CUPSFILTER=$out/lib/cups/filter CUPSDRV=$out/share/cups/drv" </ins> ''; <del> buildInputs = [cups zlib]; </del> <ins> buildFlags = [ "drv" "all" ]; makeFlags = [ "DRV_ONLY=1" ]; buildInputs = [ cups zlib jbigkit ]; </ins> meta = { <ins> description = "CUPS drivers for SPL (Samsung Printer Language) printers"; </ins> homepage = http://splix.sourceforge.net; platforms = stdenv.lib.platforms.linux; maintainers = [ stdenv.lib.maintainers.peti ];

I have a Samsung M2022W (usb) that works on a raspberrypi using raspbian (2017-11-29-raspbian-stretch-). I had to pick the ML-2160 driver in CUPS 2.2.1 as recommended by On NixOS (cups-2.2.2): [nawal nix-info system: "x8664-linux", multi-user?: yes, version: nix-env (Nix) 1.11.16, channels(nawal): "nixos-17.03-17.03.1082.", channels(root): "nixos-17.09.3149.", nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs If I use services.printing = { enable = true; drivers = [ pkgs.samsungUnifiedLinuxDriver ]; extraConf = '' LogLevel debug ''; extraFilesConf = '' FileDevice yes ''; }; and pick the same driver, I get garbage printed out. I tried to track down the ppd on raspbian, but only found: pi $ grep 2160 /usr/share/cups/drv/splix- ModelName "ML-2160" PCFileName "" and (i.e. it generated the ppd when I installed the printer apparently).


Question: }; preBuild = '' <del> makeFlags="V=1 DISABLE_JBIG=1 CUPSFILTER=$out/lib/cups/filter CUPSPPD=$out/share/cups/model" </del> <ins> makeFlags="$makeFlags CUPSFILTER=$out/lib/cups/filter CUPSDRV=$out/share/cups/drv" </ins> ''; <del> buildInputs = [cups zlib]; </del> <ins> buildFlags = [ "drv" "all" ]; makeFlags = [ "DRV_ONLY=1" ]; buildInputs = [ cups zlib jbigkit ]; </ins> meta = { <ins> description = "CUPS drivers for SPL (Samsung Printer Language) printers"; </ins> homepage = http://splix.sourceforge.net; platforms = stdenv.lib.platforms.linux; maintainers = [ stdenv.lib.maintainers.peti ];

On nixos: [nawal | grep 2160 /nix/store/6f2zx8dl4w0kzgw3wj8f466mvkcgc3dc-samsung-UnifiedLinuxDriver-4.00.39/opt/share/ppd/ML- /nix/store/nmp023llc8fix567f413a5rqbx4sw45g-cups-progs/share/cups/model/ML- Having diffed them, I notice amongst a huge number of differences: [nawal diff /nix/store/nmp023llc8fix567f413a5rqbx4sw45g-cups-progs/share/cups/model/ML- | grep Version < FileVersion: "2.0.0" < PSVersion: "(3010.000) 0" < QPDL QPDLVersion: "3" < *cupsVersion: 2.2 so raspbian is using a version "2.0.0" and "2.2" of something or other, whereas nixos is using a version "1.2" and "1.1" of similar things. I managed to get my printer to work by copying the ppd across, but I don't understand enough of cups (nor now have the inclination to learn) to figure out what's going on or how to make nixos do the right thing (i.e. in a word, print). I thought this might be useful for someone else who wants to pick it up? Happy to hack around the raspbian if you need more info, or try out things if you need me to while the sd card contains raspbian.
Can you find out what package on Raspbian provides the driver? Have you installed proprietary Samsung driver there? If not, can you try removing ? It seems we have latest version of but not the latest of the proprietary driver but you don't seem to use it.
I'll have a look tomorrow evening - how do i use the new splix without upgrading everything to the same commit?
Find out your current commit with (look at the suffix), then clone nixpkgs repository (), checkout current commit (), fetch my changes () and cherry-pick my patch atop your current commit (). Then you can rebuild nixpkgs with .
I can confirm this works.


Question: }; preBuild = '' <del> makeFlags="V=1 DISABLE_JBIG=1 CUPSFILTER=$out/lib/cups/filter CUPSPPD=$out/share/cups/model" </del> <ins> makeFlags="$makeFlags CUPSFILTER=$out/lib/cups/filter CUPSDRV=$out/share/cups/drv" </ins> ''; <del> buildInputs = [cups zlib]; </del> <ins> buildFlags = [ "drv" "all" ]; makeFlags = [ "DRV_ONLY=1" ]; buildInputs = [ cups zlib jbigkit ]; </ins> meta = { <ins> description = "CUPS drivers for SPL (Samsung Printer Language) printers"; </ins> homepage = http://splix.sourceforge.net; platforms = stdenv.lib.platforms.linux; maintainers = [ stdenv.lib.maintainers.peti ];

Thanks for the detailed instructions and for fixing it so quickly! NB: I had to do: (i.e. ) thanks


Question: src = fetchurl { url = "https://github.com/upscayl/upscayl/releases/download/v${version}/upscayl-${version}-linux.AppImage"; <del> hash = "sha256-33jJRMvRQxL7rPJ6VigEKcDhge46CAA0jJUOhzEyWzA="; </del> <ins> hash = "sha256-EoTFvlLsXQYZldXfEHhP3/bHygm+NdeDsf+p138mM8w"; </ins> }; appimageContents = appimageTools.extractType2 {

Steps to reproduce the behavior: Upscayl failed to build due to hash mismatch during (I'm nix beginner, I hope to that I write this bug report in right place.) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Strange! I wonder why I did not get that hash mismatch when I reviewed the PR. Upcoming PR!


Question: <del> --- ./third_party/ycmd/cpp/CMakeLists.txt +++ ./third_party/ycmd/cpp/CMakeLists.txt @@ -121,8 +121,8 @@ set( CPP11_AVAILABLE true ) endif() elseif( COMPILER_IS_CLANG ) -  set( CPP11_AVAILABLE true ) -  set( CMAKE_XCODE_ATTRIBUTE_CLANG_CXX_LANGUAGE_STANDARD "c++11" ) +  #set( CPP11_AVAILABLE true ) +  #  set( CMAKE_XCODE_ATTRIBUTE_CLANG_CXX_LANGUAGE_STANDARD "c++11" ) set( CMAKE_XCODE_ATTRIBUTE_CLANG_CXX_LIBRARY "libc++" ) endif() </del>

Building on Darwin fails. The problem seems very similar to which was solved by —however I do not know how to apply that solution here.
Wasn't this fixed by merging
This issue is fixed, but it broke again recently. Same issue as but we use
Proposed
Fixed by


Question: my $algo = $fetch->{type}; my $hash = $fetch->{hash}; my $name = $fetch->{name}; <ins> my $isPatch = $fetch->{isPatch}; </ins> if ($hash =~ /^([a-z0-9]+)-([A-Za-z0-9+/=]+)$/) { $algo = $1;

The script should report all sources used to build a package. It currently lacks support for patches? If we run find-tarballs on nethack, we should find the patch defined in nethack named we should get the url to download in the output, along with its name, hash and type.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I found why patches are skipped, they have "postFetch" attribute that has to be run to obtain the same file expected by nix. By applying this diff, patches are included in the result, but they won't have the expected checksum before applying postFetch on it. I don't know how to apply postFetch on the result right now.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Question: buildPythonPackage rec { pname = "chex"; <del> # As of 2021-12-29, the latest official version has broken tests with jax 0.2.26: # `AttributeError: module 'jax.interpreters.xla' has no attribute 'xb'` version = "unstable-2021-12-16"; </del> <ins> version = "0.1.2"; </ins> format = "setuptools"; src = fetchFromGitHub { owner = "deepmind"; repo = pname; <del> rev = "5adc10e0b4218f8ec775567fca38b68bbad42a3a"; sha256 = "00xib6zv9pwid2q7wcr109qj3fa3g3b852skz8444kw7r0qxy7z3"; </del> <ins> rev = "v${version}"; hash = "sha256-NtZYOHByKBcKmhRaNULwaQqxfoPRmgbtJ3cFHNfy4E8="; </ins> }; propagatedBuildInputs = [

Build of failed on x86_64-linux as of . Maintainer cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:


Question: wf-recorder = callPackage ../applications/video/wf-recorder { }; <ins> whatweb = callPackage ../tools/security/whatweb { }; </ins> whipper = callPackage ../applications/audio/whipper { }; whitebophir = callPackage ../servers/web-apps/whitebophir { };

Project description A scanner informing the technologies and headers a website uses. Metadata homepage URL: source URL: license: GPL-2.0 platforms: Agnostic (Darwin, Linux, Windows) See also:
I was able to build it, check it here
Thanks!


Question: exit 1 fi <del> nm -an "$libblas" | cut -f3 -d' ' > symbols </del> <ins> $NM -an "$libblas" | cut -f3 -d' ' > symbols </ins> for symbol in ${toString blasFortranSymbols}; do grep "^$symbol_$" symbols || { echo "$symbol" was not found in "$libblas"; exit 1; } done

Describe the bug To Reproduce Expected behavior The derivation to build an executable called Additional context It fails with also but succeeds with but so 1.3 seems to be a recent addition even though julia is on 1.4 and about to move to 1.5. Notify maintainers Metadata Please run and paste the result.
Same issue here: system: host os: multi-user?: sandbox: version: channels(root): channels(jfelice): nixpkgs: This prevents installing GNU octave on MacOS.
FWIW I was able to work around this issue by creating a to disable the checks in arpack: I was able to build octave successfully with that. I had to hack around a runtime issue finding , will log that as a separate issue.


Question: exit 1 fi <del> nm -an "$libblas" | cut -f3 -d' ' > symbols </del> <ins> $NM -an "$libblas" | cut -f3 -d' ' > symbols </ins> for symbol in ${toString blasFortranSymbols}; do grep "^$symbol_$" symbols || { echo "$symbol" was not found in "$libblas"; exit 1; } done

Describe the bug I'd like to build the python numpy package on an x86 machine for the armv7 architecture. numpy requires liblapack and blas, which require gfortran I already fixed one issue which is that liblapack couldn't find the gfortran compiler (see the overlay below) I'm trying to use the 20.03 release, latest commit. Here's what I'm running exactly: To Reproduce Steps to reproduce the behavior: -build here's the error I get Expected behavior The derivation builds Metadata Please run and paste the result. Maintainer information:
Maybe related to: ?
I'm not getting this in NixOS. It looks like a sandboxing issue. Can you try running this:
Thanks for responding! I launched this build on NixOs using an AMI on EC2 and I get the same result as in the issue report, here are the system details:
A similar issue exists on unstable when building for x86. Currently on: system: host os: multi-user?: sandbox: version: channels(root): channels(swflint): nixpkgs:


Question: in python.pkgs.buildPythonApplication rec { pname = "paperless-ngx"; <del> format = "other"; </del> <ins> pyproject = false; </ins> inherit version src; <ins> postPatch = '' # pytest-xdist makes the tests flaky substituteInPlace src/setup.cfg  --replace-fail "--numprocesses auto --maxprocesses=16" "" ''; </ins> nativeBuildInputs = [ gettext xorg.lndir ]; <del> propagatedBuildInputs = with python.pkgs; [ </del> <ins> dependencies = with python.pkgs; [ </ins> bleach channels channels-redis

Package name: paperless-ngx Latest released version: 2.12.1 <!-- Search your package here: --- Current version on the unstable channel: 2.11.6 <!-- 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. --


Question: { lib <ins> , stdenv </ins> , mkDerivation , fetchurl , fetchFromGitHub

Describe the bug When adding to the NixOS configuration the udev rules do not get installed. To Reproduce Steps to reproduce the behavior: mixxx with a DJ controller plugged in. controller is not recognized by mixxx Expected behavior The udev rules are in the correct folder i.e. or and therefore the udev service does not recognizes them. Additional context The fix in worked for me after a little modification (the rules file got renamed). Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Originally, mixxx did the right thing = install udev files to - see Later they changed the behaviour and they install to - see Sigh.


Question: stdenv.lib.optional crossCompiling "dev"; setOutputFlags = false; <ins> disallowedReferences = [ stdenv.cc ]; </ins> patches = [ ] # Do not look in /usr etc. for dependencies.

It's interesting that this doesn't happen on (x86_64-)linux, apparently.


Question: cython grpcio-tools mypy-protobuf <ins> pythonRelaxDepsHook </ins> ]; propagatedBuildInputs = [

Build of failed on x86_64-linux as of . This is currently breaking . python39Packages.tensorflow-datasets maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags:


Question: config = mkIf cfg.enable { services.xserver.displayManager.lightdm.enable = <del> let dmconf = cfg.displayManager; default = !(dmconf.gdm.enable || dmconf.sddm.enable || dmconf.xpra.enable ); in mkIf (default) true; </del> <ins> let dmConf = cfg.displayManager; default = !(dmConf.gdm.enable || dmConf.sddm.enable || dmConf.xpra.enable || dmConf.sx.enable || dmConf.startx.enable); in mkIf (default) (mkDefault true); # so that the service won't be enabled when only startx is used systemd.services.display-manager.enable  = let dmConf = cfg.displayManager; noDmUsed = !(dmConf.gdm.enable || dmConf.sddm.enable || dmConf.xpra.enable || dmConf.lightdm.enable); in mkIf (noDmUsed) (mkDefault false); </ins> hardware.opengl.enable = mkDefault true;

I believe that this prevents the use of other display managers -Don't force it?
if you enable a another dm you wouldn't get this error i submitted a pr so that this error does not happen when lightdm is disabled but a another dm isn't enabled


Question: buildInputs = [ glib <ins> glib-networking # see #311066 </ins> gtk3 json-glib libappindicator

Gives this error: , yet installing doesn't fix the problem. Steps to reproduce the behavior: Meteo That the Maps section works. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I have this exact issue. Hoping for some clarity.
should be here:


Question: { <ins> # Note: do not use Hydra as a source URL. Ask a member of the # infrastructure team to mirror the job. </ins> busybox = import <nix/fetchurl.nix> { <del> url = https://hydra.nixos.org/build/112609103/download/2/busybox; sha256 = "566a469dac214b31e4abdb0a91d32550bab1be5858d329e1b6074eef05370ca3"; </del> <ins> # from job: https://hydra.nixos.org/job/nixpkgs/cross-trunk/bootstrapTools.armv7l.dist/latest # from build: https://hydra.nixos.org/build/114203060 url = "http://tarballs.nixos.org/stdenv-linux/armv7l/0eb0ddc4dbe3cd5415c6b6e657538eb809fc3778/busybox"; # note: the following hash is different than the above hash, due to executable = true sha256 = "18qc6w2yykh7nvhjklsqb2zb3fjh4p9r22nvmgj32jr1mjflcsjn"; </ins> executable = true; }; bootstrapTools = import <nix/fetchurl.nix> { <del> url = https://hydra.nixos.org/build/112609103/download/1/bootstrap-tools.tar.xz; sha256 = "79fa2d7722aeb856c7c9b62a3fd64b6d261fd6f6bcbac486f0a2a7d823210550"; </del> <ins> # from job: https://hydra.nixos.org/job/nixpkgs/cross-trunk/bootstrapTools.armv7l.dist/latest # from build: https://hydra.nixos.org/build/114203060 url = "http://tarballs.nixos.org/stdenv-linux/armv7l/0eb0ddc4dbe3cd5415c6b6e657538eb809fc3778/bootstrap-tools.tar.xz"; sha256 = "cf2968e8085cd3e6b3e9359624060ad24d253800ede48c5338179f6e0082c443"; </ins> }; }

Describe the bug doesn't work, either on or . It works on and I have a bisect running at the moment (on some slow hardware, so the results might take some time). It fails with this log: To Reproduce Metadata Maintainer information:
The first bad commit could be any of: jfsutils: fix build with glibc=2.28 ppp: fix build with glibc=2.28 oathToolkit: fix build with glibc=2.28 postfix: fix build w/glibc 2.30 libffi: only run tests on musl targets stdenv: rebuild aarch64 bootstrap files with gcc8 expect: remove hack for aarch64 build expect: fix aarch64 build seasocks: fix build w/glibc-2.30 bzip2: fix aarch64 build xnbd: fix build w/glibc-2.30 glibc: remove outdated patches rr: 5.2.0 -5.3.0, fix build w/glibc-2.30 diod: fix build w/glibc-2.30 libunistring: disable tests distrho: fix build w/glibc-2.30 glibc: depend on libidn2 (and libunistring, transitively) stdenv bootstrap: disable dejagnu tests gcal: fix build w/glibc-2.30 sharutils: fix build with glibc=2.28 drbd: fix build w/glibc-2.30 gnum4: fix build with glibc=2.28 xen48: fix build w/glibc-2.30 gnulib: - mono: fix build w/glibc-2.30 glibc: 2.27 -2.30 foundationdb61: fix build w/glibc-2.30 spaceFM: fix build w/glibc-2.30 cpython: fetch darwin- to nixpkgs xen48-{light,


Question: { <ins> # Note: do not use Hydra as a source URL. Ask a member of the # infrastructure team to mirror the job. </ins> busybox = import <nix/fetchurl.nix> { <del> url = https://hydra.nixos.org/build/112609103/download/2/busybox; sha256 = "566a469dac214b31e4abdb0a91d32550bab1be5858d329e1b6074eef05370ca3"; </del> <ins> # from job: https://hydra.nixos.org/job/nixpkgs/cross-trunk/bootstrapTools.armv7l.dist/latest # from build: https://hydra.nixos.org/build/114203060 url = "http://tarballs.nixos.org/stdenv-linux/armv7l/0eb0ddc4dbe3cd5415c6b6e657538eb809fc3778/busybox"; # note: the following hash is different than the above hash, due to executable = true sha256 = "18qc6w2yykh7nvhjklsqb2zb3fjh4p9r22nvmgj32jr1mjflcsjn"; </ins> executable = true; }; bootstrapTools = import <nix/fetchurl.nix> { <del> url = https://hydra.nixos.org/build/112609103/download/1/bootstrap-tools.tar.xz; sha256 = "79fa2d7722aeb856c7c9b62a3fd64b6d261fd6f6bcbac486f0a2a7d823210550"; </del> <ins> # from job: https://hydra.nixos.org/job/nixpkgs/cross-trunk/bootstrapTools.armv7l.dist/latest # from build: https://hydra.nixos.org/build/114203060 url = "http://tarballs.nixos.org/stdenv-linux/armv7l/0eb0ddc4dbe3cd5415c6b6e657538eb809fc3778/bootstrap-tools.tar.xz"; sha256 = "cf2968e8085cd3e6b3e9359624060ad24d253800ede48c5338179f6e0082c443"; </ins> }; }

slim}: fix build bootstrap-files: bump WIP Merge branch 'staging' into glibc230 Ignoring 'fix build with glibc' commits libffi: only run tests on musl targets stdenv: rebuild aarch64 bootstrap files with gcc8 expect: remove hack for aarch64 build expect: fix aarch64 build bzip2: fix aarch64 build glibc: remove outdated patches libunistring: disable tests glibc: depend on libidn2 (and libunistring, transitively) stdenv bootstrap: disable dejagnu tests gnulib: - glibc: 2.27 -2.30 cpython: fetch darwin- to nixpkgs xen48-{light,slim}: fix build bootstrap-files: bump WIP Merge branch 'staging' into glibc230
stdenv bootstrapping of 32-bit ARMs is (hopefully) being fixed right now:
Thanks for the hard work


Question: , meson , ninja , systemd <del> , enableSystemd ? true </del> , pkg-config , docutils , doxygen

Steps to reproduce the behavior: for the pipewire package, e.g.: building it This can be fixed by either making sure that flag controls the Meson option in addtion to the , or by exposing a new option to control the directly. ping let me know which of the options above you guys prefer and I can open up a PR to fix as well. <!-- 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]:
Can we just remove that option instead?
Sorry do you mean set the to always be false or completely remove the as an option? Because I prefer the abilitiy to turn as many unnecessary dependencies as practically possible on my system (better stability and security).
Remove the option, yes, because we can't realistically maintain the exponential explosion of possible flag combinations.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I made two PRs: and Feel free to pick whichever PR looks better to you
arg removed in
How much maintenance burden does this actually cause? IMO the package options are one of Nixpkgs strengths (one of the things that attracted me, after I stopped working on Homebrew because package options started to be removed entirely), and they're critical for people working on systems where size matters.
To expand a bit, I don't think that package maintainers should generally be expected to support all combinations of options, but I also don't think they should block people who want to from doing so. Just having the flags there shouldn't cause any problems for package maintainers that don't want to maintain the flags, and it's fine IMO to respond to issues about flags not working by asking people to adopt the flag and send a patch.
No one's blocking people from overriding. It's just a bad idea to have some flags we haven't even looked at in months and pretend we support them by including them in the expression. Or in other words, keeping the flags is shipping broken code if people don't maintain them.
The enableSystemd flag had clearly been looked at recently, because there was a commit from me fixing it, and yet it was removed anyway.


Question: }; logLevel = mkOption { <del> type = types.enum ([ "error" "warn" "info" "debug" "trace" ]); </del> <ins> type = types.enum ([ "error" "warn" "info" "debug" "trace" ]); </ins> default = "info"; example = "debug"; description = "Garage log level, see <https://garagehq.deuxfleurs.fr/documentation/quick-start/#launching-the-garage-server> for examples.";

Steps to reproduce the behavior: -rebuild test on settings.datadir = "/mnt/garage0"; resolves fine Tested on nixos24.05 but code of the module is unchanged in nixos_unstable. I'm using flakes as well Please run and paste the result.
Looks like doesn't apply, maybe should tinker a bit on my own
It looks like the option type was adjusted, but not the other code in the module that checks that value. Shouldn't be too hard to fix.


Question: runHook preInstall <del> ${if stdenv.isDarwin then '' mkdir -p $out/Applications </del> <ins> ${ if stdenv.isDarwin then '' mkdir -p $out/Applications </ins> <del> cp -R packages/bruno-electron/out/**/Bruno.app $out/Applications/ '' else '' mkdir -p $out/opt/bruno $out/bin </del> <ins> cp -R packages/bruno-electron/out/**/Bruno.app $out/Applications/ '' else '' mkdir -p $out/opt/bruno $out/bin </ins> <del> cp -r packages/bruno-electron/dist/linux*-unpacked/{locales,resources{,.pak}} $out/opt/bruno </del> <ins> cp -r packages/bruno-electron/dist/linux*-unpacked/{locales,resources{,.pak}} $out/opt/bruno </ins> <del> makeWrapper ${lib.getExe electron} $out/bin/bruno  --add-flags $out/opt/bruno/resources/app.asar  --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations}}"  --set-default ELECTRON_IS_DEV 0  --inherit-argv0 </del> <ins> makeWrapper ${lib.getExe electron} $out/bin/bruno  --add-flags $out/opt/bruno/resources/app.asar  --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations}}"  --set-default ELECTRON_IS_DEV 0  --inherit-argv0 </ins> <del> for s in 16 32 48 64 128 256 512 1024; do size=${"$"}{s}x$s install -Dm644 $src/packages/bruno-electron/resources/icons/png/$size.png $out/share/icons/hicolor/$size/apps/bruno.png done ''} </del> <ins> for s in 16 32 48 64 128 256 512 1024; do size=${"$"}{s}x$s install -Dm644 $src/packages/bruno-electron/resources/icons/png/$size.png $out/share/icons/hicolor/$size/apps/bruno.png done '' } </ins> runHook postInstall '';

Attempt to build on Sample This is on an M2 chip, and it seems the issue is with node-canvas not being able to install due to missing giflib. Building with: Fixes this. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: }; <ins> pygmentex = python2Packages.buildPythonApplication rec { pname = "pygmentex"; inherit (src) version; src = stdenv.lib.head (builtins.filter (p: p.tlType == "run") texlive.pygmentex.pkgs); propagatedBuildInputs = with python2Packages; [ pygments chardet ]; dontBuild = true; doCheck = false; installPhase = '' runHook preInstall install -D ./scripts/pygmentex/pygmentex.py "$out"/bin/pygmentex runHook postInstall ''; meta = with stdenv.lib; { homepage = https://www.ctan.org/pkg/pygmentex; description = "Auxiliary tool for typesetting code listings in LaTeX documents using Pygments"; longDescription = '' PygmenTeX is a Python-based LaTeX package that can be used for typesetting code listings in a LaTeX document using Pygments. Pygments is a generic syntax highlighter for general use in all kinds of software such as forum systems, wikis or other applications that need to prettify source code. ''; license = licenses.lppl13c; maintainers = with maintainers; [ romildo ]; }; }; </ins> inherit biber; bibtexu = bibtex8; bibtex8 = stdenv.mkDerivation {

I have installed the TeXLive package on my system, but its binary script fails to run because: its directory is not found in it does not have an explicitly dependency on it does not have an explicitly dependency on the module for Python 2 cannot be found. Please fix this issues so that the script can be run. (Maybe can take a look at this.)
cc
Well, the first two bullets would be fixed very simply by but I don't yet have framework to add external python dependencies to the scripts.
Nothing new here? A similar problem happens with :
cc Maybe while a good solution is not engineered, a package for without the TeX stuff can be to . It would contain the binary with support for the needed Python dependencies. What do you think?
There aren't any true binaries, are there? It's just python scripts IIRC. But still, what you propose is probably the easiest way to resolve this somehow.
It is just a Python script that depends on the module.
My attempt at it:
So pygmentex works as expected now?
It works! It can be tested by downloading the example document from the distribution on , unzipping the downloaded files, removing the Python script and the LaTeX style class, and than compiling : The result is , with many examples of code listings typeset by Pygments.
OK, then I think we can close this.
Sorry for necromancing this (should I have opened a new issue instead?), but it doesn't "just work" – or needs further documentation on how to use it: The created by building the pygmentex texlive package can not find the module. gives us such an environment, just try running the command from there -The package though provides a executable which works just fine and finds the needed pygments python module. So how to combine these both packages? In particular I ran into this when trying to use the texlive package, as that seems to directly invoke the executable during build. Issue appears on release-18.09
I encountered the same issue, the latex package seems to be working fine tough (and can be used as a replacement)
I have in both with (which provides the style file and a non-functional Python script, because of missing Python dependencies) and (which provides the script). This setup works for me.
I still do not know a way of allowing Python module dependencies for Python scripts installed through .
This is to be fixed in


Question: hash = "sha256-cjmXKUGcrZ8RLDBmoS0AANpFCkVq3XsJTYkVUGnWgh4="; }; <del> nativeBuildInputs = [ pkg-config python3 glib ]; </del> <ins> nativeBuildInputs = [ copyDesktopItems pkg-config python3 glib ]; </ins> buildInputs = [ gtk2 readline ];

Package name: gnubg Latest released version: 1.07.001 <!-- Search your package here: --- Current version on the unstable channel: 1.06.002 Current version on the stable/release channel: 1.06.002 <!-- 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.
I packaged this in 2015 and I have no idea why.


Question: Legacy options have been mapped to the corresponding options under under <link xlink:href="options.html#opt-nix.settings">nix.settings</link> <del> but may be deprecated in the future. </del> <ins> and will be deprecated when NixOS 21.11 reaches end of life. </ins> </para> </listitem> <listitem>

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


Question: in stdenv.mkDerivation rec { <del> name = "mwprocapture-1.2.${version}-${kernel.version}"; version = "4177"; </del> <ins> name = "mwprocapture-1.3.0.${version}-${kernel.version}"; version = "4236"; </ins> src = fetchurl { <del> url = "http://www.magewell.com/files/drivers/ProCaptureForLinux_${version}.tar.gz"; sha256 = "1nf51w9yixpvr767k49sfdb9n9rv5qc72f5yki1mkghbmabw7vys"; </del> <ins> url = "https://www.magewell.com/files/drivers/ProCaptureForLinux_${version}.tar.gz"; sha256 = "1mfgj84km276sq5i8dny1vqp2ycqpvgplrmpbqwnk230d0w3qs74"; </ins> }; <del> nativeBuildInputs = [ kernel.moduleBuildDependencies ]; </del> <ins> nativeBuildInputs = kernel.moduleBuildDependencies; </ins> preConfigure = ''

I'm trying to use the mwprocapture nixos module (which uses the mwprocapture kernel package) on 20.09 (linuxPackageslatest), and I get the following: Is this known and/or already fixed somewhere? (Also, is it safe to use it anyways?) I'd love to try and fix it further myself, but I don't know how to splice in a local/development nix file into my for development purposes :sweatsmile: (also CC
Looks like upgrading the package version resolved things. Will create a PR soon.
Thanks for the heads up.


Question: postInstall = '' for f in lesspipe.sh lesscomplete; do <del> wrapProgram "$out/bin/$f" --prefix-each PATH : "${lib.makeBinPath [ file gnused procps ]}" </del> <ins> wrapProgram "$out/bin/$f" --prefix-each PATH : "${lib.makeBinPath [ binutils file gnused procps ]}" </ins> done '';

According to documentation of the app: there's a dozen dependencies we don't explicitly have a dependency on, so there's multitude of bugs that might appear depending on what's on $PATH.
Do we need a new maintainer of to move this issue forward?
We should pull the package from NixOS core...absolutely no reason to have such a bloated less ship by default.


Question: <del> { lib, stdenv, fetchFromGitHub, cmake, libminc }: stdenv.mkDerivation rec { pname = "EBTKS"; version  = "unstable-2017-09-23"; src = fetchFromGitHub { owner  = "BIC-MNI"; repo   = pname; rev    = "67e4e197d8a32d6462c9bdc7af44d64ebde4fb5c"; sha256 = "1a1qw6i47fs1izx60l1ysabpmyx9j5sjnbdv8b47wi2xcc9i3hpq"; }; # error: use of undeclared identifier 'finite'; did you mean 'isfinite'? postPatch = '' substituteInPlace templates/EBTKS/SimpleArray.h  --replace "#define FINITE(x) finite(x)" "#define FINITE(x) isfinite(x)" ''; nativeBuildInputs = [ cmake ]; buildInputs = [ libminc ]; cmakeFlags = [ "-DLIBMINC_DIR=${libminc}/lib/cmake" ]; meta = with lib; { homepage = "https://github.com/BIC-MNI/${pname}"; description = "Library for working with MINC files"; maintainers = with maintainers; [ bcdarwin ]; platforms = platforms.unix; license   = licenses.free; }; } </del>

For x8664-darwin, aarch64-darwin: build .#EBTKS x8664-darwin: aarch64-darwin:


Question: --replace-fail 'if [ "$1" == "snap" ]; then' 'exit 0; if [ "$1" == "snap" ]; then' ''; <del> ELECTRON_SKIP_BINARY_DOWNLOAD=1; </del> <ins> ELECTRON_SKIP_BINARY_DOWNLOAD = 1; # remove giflib dependency npmRebuildFlags = [ "--ignore-scripts" ]; preBuild = '' substituteInPlace node_modules/canvas/binding.gyp  --replace-fail "'with_gif%': '<!(node ./util/has_lib.js gif)'" "'with_gif%': 'false'" npm rebuild ''; </ins> dontNpmBuild = true; postBuild = ''


Question: wrap ${prefix}ld.bfd ${preWrap ./ld-wrapper.sh} ${binutils_bin}/bin/${prefix}ld.bfd fi <del> export real_cc=${prefix}cc export real_cxx=${prefix}c++ </del> <ins> # We export environment variables pointing to the wrapped nonstandard # cmds, lest some lousy configure script use those to guess compiler # version. export named_cc=${prefix}cc export named_cxx=${prefix}c++ </ins> export default_cxx_stdlib_compile="${default_cxx_stdlib_compile}" if [ -e $ccPath/${prefix}gcc ]; then wrap ${prefix}gcc ${preWrap ./cc-wrapper.sh} $ccPath/${prefix}gcc ln -s ${prefix}gcc $out/bin/${prefix}cc <del> export real_cc=${prefix}gcc export real_cxx=${prefix}g++ </del> <ins> export named_cc=${prefix}gcc export named_cxx=${prefix}g++ </ins> elif [ -e $ccPath/clang ]; then wrap ${prefix}clang ${preWrap ./cc-wrapper.sh} $ccPath/clang ln -s ${prefix}clang $out/bin/${prefix}cc <del> export real_cc=clang export real_cxx=clang++ </del> <ins> export named_cc=${prefix}clang export named_cxx=${prefix}clang++ </ins> fi if [ -e $ccPath/${prefix}g++ ]; then

Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.


Question: wrap ${prefix}ld.bfd ${preWrap ./ld-wrapper.sh} ${binutils_bin}/bin/${prefix}ld.bfd fi <del> export real_cc=${prefix}cc export real_cxx=${prefix}c++ </del> <ins> # We export environment variables pointing to the wrapped nonstandard # cmds, lest some lousy configure script use those to guess compiler # version. export named_cc=${prefix}cc export named_cxx=${prefix}c++ </ins> export default_cxx_stdlib_compile="${default_cxx_stdlib_compile}" if [ -e $ccPath/${prefix}gcc ]; then wrap ${prefix}gcc ${preWrap ./cc-wrapper.sh} $ccPath/${prefix}gcc ln -s ${prefix}gcc $out/bin/${prefix}cc <del> export real_cc=${prefix}gcc export real_cxx=${prefix}g++ </del> <ins> export named_cc=${prefix}gcc export named_cxx=${prefix}g++ </ins> elif [ -e $ccPath/clang ]; then wrap ${prefix}clang ${preWrap ./cc-wrapper.sh} $ccPath/clang ln -s ${prefix}clang $out/bin/${prefix}cc <del> export real_cc=clang export real_cxx=clang++ </del> <ins> export named_cc=${prefix}clang export named_cxx=${prefix}clang++ </ins> fi if [ -e $ccPath/${prefix}g++ ]; then

gcc5 and the dependant gfortran5 packages are failing as of 31 July Failures: ] ] Building either package using or fails. System: (MacOS 10.11.6 and MacOS 10.12.6, both nix-multiuser install) Nix version: (1.11.13) Nixpkgs version: (17.09pre-git) Sandboxing enabled: (relaxed)
has been looking into this but it seems pretty mysterious so far
git-bisect is pretty neat
cc
This is also needed to fix things that depend on gcc


Question: <del> { poetry2nix, pkgs, lib }: </del> <ins> { lib , python3 , fetchFromGitHub }: </ins> <del> let pythonPackages = (poetry2nix.mkPoetryPackages { projectDir = ./.; overrides = [ poetry2nix.defaultPoetryOverrides (import ./poetry-git-overlay.nix { inherit pkgs; }) (self: super: { </del> <ins> python3.pkgs.buildPythonApplication rec { pname = "rmfuse"; version = "unstable-2021-06-06"; </ins> <del> rmfuse = super.rmfuse.overridePythonAttrs(old: { meta = old.meta // { description = "RMfuse provides access to your reMarkable Cloud files in the form of a FUSE filesystem."; longDescription = '' RMfuse provides access to your reMarkable Cloud files in the form of a FUSE filesystem. These files are exposed either in their original format, or as PDF files that contain your annotations. This lets you manage files in the reMarkable Cloud using the same tools you use on your local system. ''; license = lib.licenses.mit; homepage = "https://github.com/rschroll/rmfuse"; maintainers = [ lib.maintainers.adisbladis ]; }; }); </del> <ins> format = "pyproject"; </ins> <del> reportlab = let ft = pkgs.freetype.overrideAttrs (oldArgs: { dontDisableStatic = true; }); in super.reportlab.overridePythonAttrs(old: { postPatch = '' substituteInPlace setup.py  --replace "mif = findFile(d,'ft2build.h')" "mif = findFile('${lib.getDev ft}','ft2build.h')" ''; </del> <ins> src = fetchFromGitHub { owner = "rschroll"; repo = "rmfuse"; rev = "3796b8610c8a965a60a417fc0bf8ea5200b71fd2"; hash = "sha256-W3kS6Kkmp8iWMOYFL7r1GyjSQvFotBXQCuTMK0vyHQ8="; }; </ins> <del> NIX_CFLAGS_COMPILE = "-I${pkgs.freetype}/include/freetype2"; </del> <ins> postPatch = '' substituteInPlace pyproject.toml  --replace 'bidict = "^' 'bidict = ">=' ''; </ins> <del> nativeBuildInputs = old.nativeBuildInputs ++ [ pkgs.pkg-config ]; buildInputs = old.buildInputs ++ [ pkgs.freetype ]; }); </del> <ins> nativeBuildInputs = with python3.pkgs; [ poetry-core ]; </ins> <del> }) ]; }).python.pkgs; in pythonPackages.rmfuse </del> <ins> propagatedBuildInputs = with python3.pkgs; [ bidict rmrl rmcl pyfuse3 xdg ]; meta = { description = "FUSE access to the reMarkable Cloud"; homepage = "https://github.com/rschroll/rmfuse"; license = lib.licenses.mit; longDescription = '' RMfuse provides access to your reMarkable Cloud files in the form of a FUSE filesystem. These files are exposed either in their original format, or as PDF files that contain your annotations. This lets you manage files in the reMarkable Cloud using the same tools you use on your local system. ''; maintainers = with lib.maintainers; [ adisbladis ]; }; } </ins>

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


Question: ./patchinstall.sh DESTDIR="$PWD/.." --all cd .. ''; <del> }) </del> <ins> })) // { meta = wineUnstable.meta // { description = wineUnstable.meta.description + " (with staging patches)"; }; } </ins>

Describe the bug repology reports some issues with the package name and version. It should end with the version, not "staging". So we could just call the package . But we should be consistent here! All the wine versions and attribute names are messed up. wine-4.0.2 | wine wine-4.0.2 | wine-4.14 | winePackages.unstable wine-4.14-staging | wine-staging wine-4.14-staging | winePackages.staging Why is "staging" in the package name but "unstable" not? Is there even a difference? So i would remove "staging" from "wine-4.14-staging". Metadata master Maintainer information:
Adding to this: I locally built and without issues with the current packages but I'm not sure what's actually required for a PR here. Seems odd that it was so easy and nobody else already PRed it.
Mind doing the PR then? :)
I'm not sure what's actually required for a PR here. I also don't know what the wine maintainers want. My motivation is to get the repology error fixed. So i would remove "staging" from "wine-4.14-staging". Seems odd that it was so easy and nobody else already PRed it. There is a lot that can be improved in nixpkgs that is quiet easy! For example i'm currently fixing package versions that produce errors in repology. There are 586 known problems left to fix: There are 4997 outdated packages in nixpkgs unstable: Most of them probably quiet easy to update, but someone has to invest the time. Maybe there is already a PR that is not merged yet. A review can help to speed it up! But we are already the best distro when it comes to up-to-date packages! And we might supersede AUR in the future with total number of packages. But at the same time, many common packages are not in nixpkgs...
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".


Question: ./patchinstall.sh DESTDIR="$PWD/.." --all cd .. ''; <del> }) </del> <ins> })) // { meta = wineUnstable.meta // { description = wineUnstable.meta.description + " (with staging patches)"; }; } </ins>

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 .
issue still exists cc maintainers
There is a difference between unstable and staging. Staging is the staging patches on top of unstable.
That makes sense. Can we add it to Long description? Repology seem to recognise the version now: !
Added to description, but if you think longDescription is better, or think the wording is not clear — please comment or PR.


Question: , xkeyboard_config , udisks2 <ins> , waylandSupport ? false, wayland-protocols, xwayland </ins> , bluetoothSupport ? true, bluez5 , pulseSupport ? !stdenv.isDarwin, libpulseaudio }:

I'm trying out NixOS 19.09 and notice that Enlightenment is still being built under X. Enlightenment 23.0 have some highlight. One of them being "Massive improvements to Wayland support".
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 .
It would be nice to hear about the recent progress.


Question: <ins> { stdenv, fetchFromGitHub }: stdenv.mkDerivation rec { name = "gradle-completion-${version}"; version = "1.3.1"; src = fetchFromGitHub { owner = "gradle"; repo = "gradle-completion"; rev = "v${version}"; sha256 = "02vv360r78ckwc6r4xbhmy5dxz6l9ya4lq9c62zh12ciq94y9kgx"; }; # we just move two files into $out, # this shouldn't bother Hydra. preferLocalBuild = true; dontBuild = true; installPhase = '' runHook preInstall mkdir -p $out install -Dm0644 ./_gradle $out/share/zsh/site-functions/_gradle install -Dm0644 ./gradle-completion.bash $out/share/bash-completion/completions/gradle runHook postInstall ''; meta = with stdenv.lib; { description = "Gradle tab completion for bash and zsh"; homepage = https://github.com/gradle/gradle-completion; license = licenses.mit; maintainers = with maintainers; [ ma27 ]; }; } </ins>

It would be nice if we are able to have , in the same way we have , and the other completion siblings. I know it's easy to just and store in , but doing that we have to allow the user in question to write to that location (I don't really know the repercussions of any) and really defeats the purpose, somehow, of Nix Packages.
as the modules (at least for bash and zsh) are fairly advanced it shouldn't be too hard. I'll try to have a look at it tonight %)
Hi, I installed on Arch Linux , but whenever I go into any Gradle-based project it doesn't work – as it works in macOS when I install it using Brew. It just doesn't discover, nor auto-completes any of the (currently available) tasks. Maybe it's not getting sourced into the shell? I do have also installed, not sure if that's an impediment (or not):
I actually confirmed that the package is doing its job, however it can be possible that I screwed something up (e.g. something in my system config made it work). I don't think that I'll have sufficient time to look at this tonight, by I'll definetely keep this in mind and have a deeper look at this as soon as I have time to.
I rechecked with the following vm config (which is basically the same as the settings I posted in my commit message): It seems to work perfectly fine with , however the validation breaks with (didn't test this, mostly use as it's easier to type :sweat_smile:) It shouldn't be too hard to fix this, I'll ping you when it's done.
For me, even if I try to use alone, when I hit (auto-complete) on the shell (), it does auto-complete what I have in the directory, which is fine, but I guess at some point the script(s) should take over the "normal" shell auto-completion.
I'm fairly confused, are you sure that it's not caused by something else? I tested it with a VM from master and inside and work perfectly fine: What I suspect now is that it could be caused by your user profile. I'm not sure if actually pulls completion scripts from . Would you mind checking this with a VM or by adding to in your ?
Hi I'm using Arch Linux and the Bash shell.


Question: <ins> { stdenv, fetchFromGitHub }: stdenv.mkDerivation rec { name = "gradle-completion-${version}"; version = "1.3.1"; src = fetchFromGitHub { owner = "gradle"; repo = "gradle-completion"; rev = "v${version}"; sha256 = "02vv360r78ckwc6r4xbhmy5dxz6l9ya4lq9c62zh12ciq94y9kgx"; }; # we just move two files into $out, # this shouldn't bother Hydra. preferLocalBuild = true; dontBuild = true; installPhase = '' runHook preInstall mkdir -p $out install -Dm0644 ./_gradle $out/share/zsh/site-functions/_gradle install -Dm0644 ./gradle-completion.bash $out/share/bash-completion/completions/gradle runHook postInstall ''; meta = with stdenv.lib; { description = "Gradle tab completion for bash and zsh"; homepage = https://github.com/gradle/gradle-completion; license = licenses.mit; maintainers = with maintainers; [ ma27 ]; }; } </ins>

I searched within my "home" directory for this file: and I couldn't find any. I did find a , but couldn't find on it. My Bash shell is the one that comes by default with Arch Linux. I did the same on a virtual machine with Ubuntu . Let me know if you want more info.
Ah good to know! I've been testing on NixOS, usually which defines the system's entire state. But I'm fairly certain that this is related to living in , please give me som etime to investigate, but this sounds like a bug in the bash packages themselves...
It might be a bug because right now that I'm on it, I should also have auto-completion for Git commands (due to the fact that I have ), and it doesn't work either. I even to , but still, nothing going on there: Thanks for the effort!
I see... Unfortunately I don't use the user profile for this so I might lack the required knowledge. I'd recommend to look for related tickets (or open a new one) as I'm fairly certain now that this is related to the integration of into .


Question: githubId = 84968; name = "Florian Paul Schmidt"; }; <ins> fptje = { email = "fpeijnenburg@gmail.com"; github = "FPtje"; githubId = 1202014; name = "Falco Peijnenburg"; }; </ins> fragamus = { email = "innovative.engineer@gmail.com"; github = "fragamus";

Proprietary HTML5 videos break the whole site Workaround is to disable . Steps to reproduce the behavior: Vivaldi package with the package in your Configuration (home-manager) YouTube YouTube should display and the video should play. !
I hit this issue myself yesterday as well. I had reported it to Vivaldi before I realized it was indeed an outdated chromium-ffmpeg dependency. See . I wrote a PR at to fix this. For a quick fix, here's the code I have in my overlay to work around this straight away:
I just saw it. Thanks a lot! I will close this issue now as you already created an issue for discussion.


Question: { stdenv, buildPythonApplication, fetchFromGitHub, isPyPy, lib <del> , future, psutil, setuptools </del> <ins> , defusedxml, future, psutil, setuptools </ins> # Optional dependencies: , bottle, pysnmp , hddtemp

, CVSSv3=9.8 (nixos-21.05) The package glances before 3.2.1 are vulnerable to XML External Entity (XXE) Injection via the use of Fault to parse untrusted XML data, which is known to be vulnerable to XML attacks. Scanned versions: nixos-21.05: . Cc Cc Cc
This was resolved by


Question: freeformType = settingsFormat.type; options = { source_directories = mkOption { <del> type = nullOr (listOf str); default = null; </del> <ins> type = listOf str; default = []; </ins> description = '' List of source directories and files to backup. Globs and tildes are expanded. Do not backslash spaces in path names.

I've set up a borgmatic backup script using the borgmatic service. I can run the backup manually by running as root, but fails with the following error: Here is the service definition I used: I then tried to pass an absolute path to cat, by replacing with and got the following similar error: Steps to reproduce the behavior: one of the service definitions above and observe that running it manually works. the output in No errors, as both and are present on the system, and I can run I also noticed that borgmatics default value for , , causes an error when the borgmatic service is run. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
As I know, NixOS package doesn't use your settings, which mean what you can use in your shell environment doesn't mean the package can use. User can use and whatever command they like in , I can't put everything in . So my suggestion is to use the format when using a command provided by other packages. As for your pgdump command not found, I suggest change it into Good caught, I will file a PR to change the default value.
This works, but I'm curious why it's not the default? As is, the service doesn't work for postgres dumps?
If we make this default, I think it will add those packages (pkgs.{mysql,postgresql,mariadb}) to nix store even the user doesn't need it. And I prefer to keep the package in minimal. Personally, I use the following code to use mysqldump
That's fair. Thanks for the feedback :-) Do we leave this issue open until has been merged?
You can keep it open, it will auto close once merged.


Question: callHackageDirect = {pkg, ver, sha256}@args: let pkgver = "${pkg}-${ver}"; in self.callCabal2nix pkg (pkgs.fetchzip { <del> url = "http://hackage.haskell.org/package/${pkgver}/${pkgver}.tar.gz"; </del> <ins> url = "mirror://hackage/${pkgver}/${pkgver}.tar.gz"; </ins> inherit sha256; });

During Hackage downtime, nix builds are needlessly broken. There are mirrors available; we should use them. See: Mirrors include: http://objects-us-east- I'm a third party reporting errors I've heard of, so I don't have precise repro steps. Do certain Haskell-related build stuff during Hackage downtime, I guess?
Mirror list is available at E. g. https://objects-us-east-


Question: ln -s --force "$emulator" /run/${dirName}/nix-emulators/ done <del> for helper in libexec/qemu-bridge-helper bin/qemu-pr-helper; do </del> <ins> for helper in bin/qemu-pr-helper; do </ins> ln -s --force ${cfg.qemu.package}/$helper /run/${dirName}/nix-helpers/ done

When attempting to create a volume on a physical node pool parted is not found. Steps to reproduce the behavior: Create a physical disk node pool. Attempt to create a volume using that node pool. In this case I have created a node pool called and I am attempting to create a volume called Volume is created normally. If applicable, add screenshots to help explain your problem. I have tried to add parted manually using and overriding the package in the libvirtd module: but this did not fix the issue.
That won't work, it seems like we need to wrap to include in its . I'll take a look.
You most likely need to add it to in because libvirtd will probably call it.