jiebi/CodeConvo huggingface dataset:
Code change:
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 ],

Related discussion:
text: 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?
Code change:
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 ],

Related discussion:
text: 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 :)
Code change:
, gobject-introspection , lib , libsoup <del> , llvmPackages_15 </del> , makeBinaryWrapper , nodejs <ins> , openssl </ins> , pango , pkg-config , pnpm

Related discussion:
text: 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.
Code change:
<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>

Related discussion:
text: 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
Code change:
<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>

Related discussion:
text: 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 .
Code change:
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 ];

Related discussion:
text: , CVSSv3=4.3 (nixos-unstable) phoronix-test-suite is vulnerable to Cross-Site Request Forgery (CSRF) Scanned versions: nixos-unstable: . Cc
Code change:
xineramaSupport = true; xmlSupport = true; sdlSupport = true; <ins> mingwSupport = true; </ins> }; full = base.override {

Related discussion:
text: 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?
Code change:
xineramaSupport = true; xmlSupport = true; sdlSupport = true; <ins> mingwSupport = true; </ins> }; full = base.override {

Related discussion:
text: 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?
Code change:
xineramaSupport = true; xmlSupport = true; sdlSupport = true; <ins> mingwSupport = true; </ins> }; full = base.override {

Related discussion:
text: 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:
Code change:
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 = [

Related discussion:
text: 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
Code change:
# 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; })

Related discussion:
text: 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!
Code change:
heimdall-gui = heimdall.override { enableGUI = true; }; <ins> headscale = callPackage ../servers/headscale { }; </ins> heisenbridge = callPackage ../servers/heisenbridge { }; helio-workstation = callPackage ../applications/audio/helio-workstation { };

Related discussion:
text: Project description An open source implementation of the Tailscale control server Metadata homepage URL: source URL: license: bsd platforms: linux
Code change:
''; 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";

Related discussion:
text: <!-- 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 )
Code change:
<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>

Related discussion:
text: 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]:
Code change:
(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")

Related discussion:
text: 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.