jiebi/CodeConvo huggingface dataset:
Change:
nextcloud17 = generic { version = "17.0.x"; sha256 = "0000000000000000000000000000000000000000000000000000"; <del> insecure = true; </del> <ins> eol = true; </ins> }; }</programlisting> </para>

Discussion:
In line of the nextcloud nixos module the current default is nextcloud 19. On the one hand, this is not represented in the documentation. On the other, this yields the error that there are unpatched security issues.
Retroactively changing the default on 20.09 is not just a breaking change, but effectively breaks the upgrade path from 20.03: the problem with Nextcloud (and the main reason for this complex package-selection thing) is that they don't support upgrades across multiple major releases (i.e. you can't go from v18 to v20). The whole point of this option is that one can install an arbitrary Nextcloud version while we (as maintainers) can set "conservative" defaults for working upgrade paths. In your case it would be sufficient to set . Regarding CVE-2020-8259 and CVE-2020-8152: both vulnerabilities affect the encryption module which is turned off by default (IIRC it can only be enabled in the admin UI anyways). It's unfortunate that Nextcloud upstream doesn't care about older yet still active majors and rates security issues as "Low" even though the CVEs are rated as "High" by e.g. NIST, but that's where we are. In other words: if you don't use the affected features it's still OK to use (which can be allowed by setting .
I see your point, thanks. The issue is that I, as a user, install Nextcloud and see a security warning. Given the above, maybe the message could state that you may use the option and use nextcloud20. Would that be feasible? Or given the fact that 21.03 is 'around the corner' would it be worth it?
why did you mark this as security-relevant? Both CVEs in question are disclosed by upstream and will warn about them by default. This is merely an issue with documentation and helpful warnings IMHO.
The issue seems to be about undocumented path towards using nextcloud while staying secure
Yes, it's about documentation, no immediate action is pending to fix a security issue! Nextcloud versions with known vulnerabilities yield an evaluation error, this is primarily about suggesting what to do if one stumbles upon this.
Change:
timeout = optionalString (config.boot.loader.timeout != null) config.boot.loader.timeout; <del> editor = if cfg.editor then "True" else "False"; </del> configurationLimit = if cfg.configurationLimit == null then 0 else cfg.configurationLimit; <del> inherit (cfg) consoleMode graceful; </del> <ins> inherit (cfg) consoleMode graceful editor; </ins> inherit (efi) efiSysMountPoint canTouchEfiVariables;

Discussion:
See title. nixos-unstable (), set is missing from . is present in . n/a Regression caused by (which I verified by reverting the commit, and the expected behaviour is restored). <!-- 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]:
Change:
<ins> # blueman service { config, lib, pkgs, ... }: with lib; let cfg = config.services.blueman; in { ###### interface options = { services.blueman = { enable = mkEnableOption "blueman"; }; }; ###### implementation config = mkIf cfg.enable { environment.systemPackages = [ pkgs.blueman ]; services.dbus.packages = [ pkgs.blueman ]; systemd.packages = [ pkgs.blueman ]; }; } </ins>

Discussion:
Blueman package cannot just be used from when installing it from user. It is expected to be an OS level service. See: We should have a NixOS module for it: . Try installing blueman using nix-env and then run .
should work when is enabled. Have you tried it?
When did this happen? I had the same problem as rycee/home-manager
Where does this mention blueman?
Change:
./no-build-info.patch ]; <ins> # This prevents cmake from using libraries in impure paths (which causes build failure on non NixOS) postPatch = '' sed -i '/Add these standard paths to the search paths for FIND_LIBRARY/,/^s*$/{d}' CMakeLists.txt ''; </ins> outputs = [ "out" "dev" ]; buildInputs =

Discussion:
running nix-shell . with that sets enableCuda to true causes opencv to fail building with impure path `' used in link collect2: error: ld returned 1 exit status nix-shell . System: (NixOS: , Ubuntu/Fedora: , ...) Centos 7 10.0-327.22.2.el7.x8664 Nix version: (run ) nix-env (Nix) 1.11.4 Nixpkgs version: (run ) 03pre97542.
I forgot to mention that I had to add this file { allowUnfree = true; }
I also encountered the exact same problem on Arch Linux. I would guess causes problem, because Arch Linux also have and opencv's cmake detects it.
Status? No matter how I run or modify opencv always finds and fails
cc opencv maintainers Maybe patch opencv's CMakeLists to stop it from using libraries in /lib/ is a possible solution?
Change:
deactivate ''; <ins> # Propagating dependencies leaks them through $PYTHONPATH which causes issues # when used in nix-shell. postFixup = '' rm $out/nix-support/propagated-build-inputs ''; </ins> disabledTests = [ # ERROR: The install method you used for conda--probably either `pip install conda` # or `easy_install conda`--is not compatible with using conda as an application.

Discussion:
If you install pre-commit alongside python311, the python311 site-packages directory disappears from the PYTHONPATH, which (I think) causes other packages to break. has PYTHONPATH entries: Notice that the above list does not include any python 3.11 entries. To get those you have to remove pre-commit (): The actual problem that lead me here had to do with being unable to satisfy its . The problem went away when I removed . , but haven't filed it as an issue yet. I'm not 100% sure that PYTHONPATH is the issue, but it does seem like pre-commit is being a noisy neighbor in some way or another. Contrast the output of these commands: with the output of these... I'm not sure, but whatever it is I don't think that installing pre-commit should hide
I'm working around this by just commenting in my whenever I want to run my app, and then re-adding it whenever I want to run pre-commit. If there's a smarter workaround I'd love to know about it.
In my case it's sort of the opposite. I had a Python env () using Python 3.10 with together in a and that worked fine. I bumped the env to Python 3.11 recently and that made stop working: . When I printed the just before was run I noticed everything references Python 3.11, even though was running via Python 3.10. That gave me the hint to roll back the env to 3.10, which fixes .
I'm sorry to apply "touched it last" logic here, but I can see that you're active and you probably know a bit more about how this works than I do. Would you be willing to share any thoughts you have about this?
this needs to be done
That's very helpful, thanks I'll attempt a PR to fix this, hopefully this weekend.
I get a similar error using on this flake Weirdly, I cannot reproduce it with
Change:
<ins> gettextDataDirsHook() { if [ -d "$1/share/gettext" ]; then addToSearchPath GETTEXTDATADIRS "$1/share/gettext" fi } envHooks+=(gettextDataDirsHook) </ins>

Discussion:
There should really be no need to propagate , it is only used for generating the gir files. We should encounter only minor issues with packages like or , which do not list the dependency explicitly. Yet when I try to build the depending packages, fails with the following, seemingly unrelated error: We need to find out why this error happens before removing the dependency.
Apparently, the issue is that its files from are not to . setup hook does that. Should we add a similar setup hook to ? What about other derivations providing files?
Since the command that fails without files is from — see its — I think that derivation is responsible either for populating , or, less likely, for propagating a build dependency that does nothing but populate .
Still need to do the actual unpropagation, basically build everything and see what’s broken. WIP branch:
Change:
unstable = fetchurl rec { # NOTE: Don't forget to change the SHA256 for staging as well. <del> version = "6.16"; </del> <ins> version = "6.17"; </ins> url = "https://dl.winehq.org/wine/source/6.x/wine-${version}.tar.xz"; <del> sha256 = "sha256-aVCSBQ2YoSnE1/MVPLDkkjJIuuXz2SBjn6SrGnP4+ug="; </del> <ins> sha256 = "sha256-nbHyQ12AJiw3dzF98HWFWu6j5qUst3xjDsGysfuUjwg="; </ins> inherit (stable) gecko32 gecko64; ## see http://wiki.winehq.org/Mono

Discussion:
The readme of yabridge says: And my plugins are not loading anymore. I tried this: but that gives me GLIBC2.33' not found (required by /home/user/Bitwig )` plugins loading
Looks like there is a patch that we could apply to wine? Don't know if that one will end up in 6.16 already - that should be just around the corner.
With this shouldn't be a problem anymore!
Change:
<del> --- a/src/dummy.h	2016-12-17 23:33:33.279533389 +0100 +++ b/src/dummy.h	2016-12-17 23:33:56.695739166 +0100 @@ -69,7 +69,7 @@ int overlay_offset; int videoKey; int interlace; -    dummy_colors colors[256]; +    dummy_colors colors[1024]; pointer* FBBase; Bool        (*CreateWindow)() ;     /* wrapped CreateWindow */ Bool prop; --- a/src/dummy_driver.c	2016-12-17 23:33:47.446657886 +0100 +++ b/src/dummy_driver.c	2016-12-17 23:33:56.696739175 +0100 @@ -317,6 +317,7 @@ case 15: case 16: case 24: +        case 30: break; default: xf86DrvMsg(pScrn->scrnIndex, X_ERROR, @@ -331,8 +332,8 @@ pScrn->rgbBits = 8; /* Get the depth24 pixmap format */ -    if (pScrn->depth == 24 && pix24bpp == 0) -	pix24bpp = xf86GetBppFromDepth(pScrn, 24); +    if (pScrn->depth >= 24 && pix24bpp == 0) +	pix24bpp = xf86GetBppFromDepth(pScrn, pScrn->depth); /* * This must happen after pScrn->display has been set because @@ -623,7 +624,7 @@ if(!miCreateDefColormap(pScreen)) return FALSE; -    if (!xf86HandleColormaps(pScreen, 256, pScrn->rgbBits, +    if (!xf86HandleColormaps(pScreen, 1024, pScrn->rgbBits, DUMMYLoadPalette, NULL, CMAP_PALETTED_TRUECOLOR | CMAP_RELOAD_ON_MODE_SWITCH)) </del>

Discussion:
Describe the bug Attempting to start xpra fails with the following X server log: To Reproduce Steps to reproduce the behavior: run start :200
Change:
{ "EncConv": { "owner": "Alexey-T", <del> "rev": "2020.06.15", "sha256": "07dpvq3ppfq3b70i1smkf7vwdlzq8qnxs3fk94hi9h1z36bz2rw3" </del> <ins> "rev": "2021.01.01", "sha256": "18fp7yz2rl80a6xw7v4bgc4092l74fb6p6z4yf312r7gw7b8naq6" </ins> }, "ATBinHex-Lazarus": { "owner": "Alexey-T", <del> "rev": "2020.09.05", "sha256": "022yx5vic4hnc9lz53wvr4h7hf0h71801dzlilj55x5mf8p59072" </del> <ins> "rev": "2020.11.22", "sha256": "0dkvzm32ls03pfp40fxvsyrkfmyznc5yrj65cp4a8pp9kpkvzlz7" </ins> }, "ATFlatControls": { "owner": "Alexey-T", <del> "rev": "2020.11.02", "sha256": "0shihlm1hg74m04qyrj2iic2ik0x7qggihmnylvvdry3y79d07fy" </del> <ins> "rev": "2021.01.12", "sha256": "1mavv3krs4srdp362prf4sncssxjh11la5j4lkx0wk5csrmd1pc9" </ins> }, "ATSynEdit": { "owner": "Alexey-T", <del> "rev": "6560bc35a2cf31399be8713ac189216afabf9f01", "sha256": "1bjnd6pcd9ddkvl7ma05z7f8svq609kljwc7gvbszc76hdb8d54x" </del> <ins> "rev": "2021.01.19", "sha256": "0lpgfwljwh9mypscbpj5c7fivhza0hizjgqypval3v0209cx38d1" </ins> }, "ATSynEdit_Cmp": { "owner": "Alexey-T", <del> "rev": "2459ea2a2e50050f7e6ee59a17a52aae05ca4433", "sha256": "155cwcmr9f23j4x13pidvb3vcgglawkxxpizjw90ajwhmg831acr" </del> <ins> "rev": "2021.01.17", "sha256": "14i4jdpbmh6sjpvbwipdvvmmqqw8wg592b34a9wdf2f9qxq2p4ly" </ins> }, "EControl": { "owner": "Alexey-T", <del> "rev": "2020.10.04", "sha256": "0ypbaca3y5biw2207yh3x5p28gm8g51qf7glm5622w3cgbrf9mdq" </del> <ins> "rev": "2021.01.12", "sha256": "107zyd65vc72fl4mvyirhv2a9m47l9bs6gwqiwar7hrn02zns6bq" </ins> }, "ATSynEdit_Ex": { "owner": "Alexey-T",

Discussion:
For this patch I to CudaText the global variable which you can change to False. to disable "Help / Check for updates".
OK, I will use it with next release.
Change:
, unzip , wget }: mkDerivation rec { pname = "megasync"; <del> version = "4.3.5.0"; </del> <ins> version = "4.4.0.0"; </ins> src = fetchFromGitHub { owner = "meganz"; repo = "MEGAsync"; rev = "v${version}_Linux"; <del> sha256 = "0rr1jjy0n5bj1lh6xi3nbbcikvq69j3r9qnajp4mhywr5izpccvs"; </del> <ins> sha256 = "1xggca7283943070mmpsfhh7c9avy809h0kgmf7497f4ca5zkg2y"; </ins> fetchSubmodules = true; }; <del> nativeBuildInputs = [ autoconf automake doxygen lsb-release pkg-config qttools swig unzip ]; </del> <ins> nativeBuildInputs = [ autoconf automake doxygen libtool lsb-release pkg-config qttools swig unzip ]; </ins> buildInputs = [ c-ares cryptopp

Discussion:
Describe the bug Latest MEGAsync app fails to start (Segmentation fault), probably because of . Not sure if it is NixOS related or just a MEGAsync bug. To Reproduce Steps to reproduce the behavior: it fault Expected behavior No crash Additional context Crash dump: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Maintainer information:
Yep I have this too. Actually the most recent commit version doesn't open at all, just dumps core - but the previous commit before that () does open and reopens on startup and everything fine, despite giving me the segmentation fault when I open it manually. <details<summaryCrashdump</summary
Same for me. Reported upstream: Bumping the version to does not help. It is still usable for me on 20.09 stable with this overlay:
Does anyone know how to specify an older version of cryptopp, as a stopgap until this is fixed upstream? I'm in desperate need of getting Megasync to work again. The overlay above isn't working for me on Unstable.
can't you just use michojel's overlay above, or an older version of the megasync package entirely? The latter is what I'm doing rn, just stick this in your : Which pins commit (which still uses megasync 4.3.5.0)
Looks like 4.4.0.0 addressed the issues. Works for me at least. See
Change:
dieHook = makeSetupHook {} ../build-support/setup-hooks/die.sh; <del> dockerTools = callPackage ../build-support/docker { }; </del> <ins> # go 1.9 pin until https://github.com/moby/moby/pull/35739 dockerTools = callPackage ../build-support/docker { go = go_1_9; }; </ins> docker_compose = pythonPackages.docker_compose;

Discussion:
nixos/tests for docker-tools and kubernetes fail to build on current master It looks like this is caused by being broken under go 1.10. On current master (with go 1.10): Fails with: Similar error for kubernetes test: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Here's an example of what I think is wrong with Given a tar file on stdin, it should print a checksum on stdout but results in an error:
Any idea what the Discard is doing? If I comment it out, it builds, but I'm not sure the hashes produced are correct. if _, err = io.Copy(ioutil.Discard, ts); err != nil { fmt.Println(err) os.Exit(1) }
might know.
Oh, yeah, getting rid of that is definitely nonsense. Every hash will be the same. :)
: makes sense, let docker upstream take care of this.
Change:
"upperdir=/nix/.rw-store/store" "workdir=/nix/.rw-store/work" ]; <ins> depends = [ "/nix/.ro-store" "/nix/.rw-store/store" "/nix/.rw-store/work" ]; </ins> }; boot.initrd.availableKernelModules = [ "squashfs" "overlay" ];

Discussion:
Describe the bug Edit: After looking at it for a while, it seems the real problem is that this function is too strict: I think it should be something like this instead: To Reproduce Because comes before alphabetically, it's mounted first (which fails). You can read the file using: Expected behavior The list of file systems to be topologically sorted. Additional context Originally found this while trying to try out root-on-tmpfs. Notify maintainers Couldn't find anyone. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(jakob): nixpkgs: Maintainer information:
This is also a problem when using since the dependencies are specified in not or and for this problem is not enough to fix the issue. The option sugested by in would solve it. Actually the only reason the current ISO and netboot images aren't broken because of this (they use ) is solely because and comes alphabetically before .
I marked this as stale due to inactivity. &rarr;
This is still an issue, and for me a fairly big one, since I can't generate secrets with agenix with my current setup:
Change:
, libsepol , vulkan-headers , vulkan-loader <del> , valgrind </del> , libthai , libdrm , libdatrie

Discussion:
This means nearly all qt6 packages depend on gdb which is 641M on its own. Why is that the case? I can't imagine needing Valgrind for "production" qt6 builds but I have no knowledge in this domain. cc
valgrind was not in my qt6 draft in valgrind was in but valgrind or gdb dont show up in the closure of <details </summaryto compare, </detailsso ... no problem? edit: <details </summary</details
The inputs are only propagated in the output and that's what other packages use. I only came across this because I found gdb in my system closure. showed <the package-quazip -qtbase -valgrind -gdb why did you add valgrind to qt6's propagatedBuildInputs?
It should have been a build time dependency for qtbase. And as it is only referenced in dev output, it should normally not be referenced in system closures, except for issues like Edit, quazip wasn't fixed by that, let me look into it tomorrow.
... so should not be there &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; propagatedBuildInputs &rarr; propagatedBuildInputs also may be relevant: in , are copied to
For the , they should have been in dev output, but and do not have dev output, adding it back should be enough. For , it should be of the same problem as in , maybe we should add that in the hooks of qtbase, or we can fix this ad-hoc.
Change:
# - options: something starting with a '-' # - environment variables: foo=bar if $(echo "$arg0" | grep -q -- "^-.*|.*=.*"); then <del> echo "$f: unsupported interpreter directive "$oldInterpreterLine" (set dontPatchShebangs=1 and handle shebang patching yourself)" </del> <ins> echo "$f: unsupported interpreter directive "$oldInterpreterLine" (set dontPatchShebangs=1 and handle shebang patching yourself)" >0 </ins> exit 1 fi

Discussion:
I have been burned by this several times; and I am not alone: When calling with multiple arguments, we should either patch all of them or print an error. Ignoring arguments silently should be a crime. cc
Change:
if [ -z "''${CUDAHOSTCXX-}" ]; then export CUDAHOSTCXX=${cc}/bin; fi <del> export NVCC_PREPEND_FLAGS+=' --compiler-bindir=${cc}/bin' </del> <ins> export NVCC_PREPEND_FLAGS+=' --compiler-bindir=${cc}/bin -Xfatbin=-compress-all' </ins> EOF ''; });

Discussion:
Steps to reproduce the behavior: magma From : Also may be interested.
Is this related to the race condition error you saw before?
can you tell me more about what hardware you're using, and what your looks like? For reference, runs without issue for me with using a 4090 and an i9 13900k: EDIT: Would you also try building with I made some changes there that moved the CUDA runtime stub and NVCC into . I'm curious if that helps at all.
I don't think so -- closest I can remember to this was the linking error AMD HIP had with 2.7.x (which is why its stuck on magma 2.6.x), but that was a different inscrutable error from .
CPU is a Xeon Gold 5218 with Quadro RTX 8000 GPUs. I haven't set any configuration other than and .
I don't know why this issue isn't affecting your builds but most likely the fix is to set :
Haven't tried yet either, sorry.
Any idea when this failure started occurring?
magma 2.6.2 I believe works but 2.7.1 fails. I can try to bisect at some point if needed.
What channel were you building from by the way? I'm gonna try to find a way to match your setup but I need to know exactly which version of nixpkgs you're using to build.
Okay, I was able to reproduce it. It happened while a Nixpkgs-review for that magma PR I linked earlier. I suspect it has something to do with either my disabling or restricting . Time to investigate ‍
Something for me to look at later tonight; if it is the case that the increased number of cuda capabilities being targeted is causing the binary to bloat, check that we're using , like PyTorch : IIRC Magma doesn't set that flag. Also, I remember being unable to find specifically in the NVCC docs. Since PyTorch also ships binaries targeting a bunch of different CUDA capabilities, their configs are a goldmine of flags we might need to look into. EDIT: Haven't built with it yet, but it seems like it should fix it.

Apache MXNet had the same issue: EDIT2: Reminder to self: if that is the fix, add here: and here:
I know it's still a draft but can you try building again with I think it should fix your issue. Unrelated, but if you're building anything from source and you want faster builds I highly recommend specifying the single compute capability you need to build for (like I do here ) because it results in massively faster builds. HEAD right now builds for 14 different capabilities and that PR gets it down to 8, but it's much faster to build for just one.
is building for me from that branch (without any configuring compute capabilities yet), thanks.
Change:
maturin = callPackage ../development/tools/rust/maturin { inherit (darwin.apple_sdk.frameworks) Security; }; <del> panamax = callPackage ../development/tools/rust/panamax { inherit (darwin.apple_sdk.frameworks) Security; }; </del> <ins> panamax = callPackage ../development/tools/rust/panamax { }; </ins> ograc = callPackage ../development/tools/rust/ograc { };

Discussion:
<!-- 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: panamax <!-- 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: 1.0.3 desired version: 1.0.6 <!-- 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.
Change:
owner = "plymouth"; repo = "plymouth"; rev = finalAttrs.version; <del> hash = "sha256-71QMhQqWpa4FID9vPEL2QuOaGxuk7+sXKRynCa1n2tw="; </del> <ins> hash = "sha256-Uun4KtrbkFCiGq3WpZlZ8NKKCOnM+jcgYa8qoqAYdaw="; </ins> }; patches = [

Discussion:
On my work laptop, the boot is often stuck at “Starting Show Plymouth Boot Screen” (After a timeout, rescue prompt will appear but it will be possible to enter any commands because “cannot open access to console the root account is locked”. If I set , I am able to proceed.) The logs reveal that Plymouth crashed: Happens even if I remove console font = "Lat2-Terminus16";systemd-vconsole-setup.service. Steps to reproduce the behavior: on a computer. that full-disk-encryption password prompt never appears. User should be asked for LUKS password, either by Plymouth, or if it crashes, by systemd. I managed to pinpoint it to plymouth crash with 23.356.9 but the same symptoms appeared in earlier generations as well (although less frequently). coredumpctl cannot find any coredumps in the emergency shell. Relevant configuration: cc NixOS Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Same issue on