jiebi/CodeConvo huggingface dataset:
Code change:
autoSuspend = mkOption { default = true; description = '' <del> Suspend the machine after inactivity. </del> <ins> On the GNOME Display Manager login screen, suspend the machine after inactivity. (Does not affect automatic suspend while logged in, or at lock screen.) </ins> ''; type = types.bool; };

Related discussion:
text: Describe the bug It seems you can't disable GDM's auto suspend behaviour. Disable has no effect. To Reproduce laptop will auto suspend after timeout Expected behavior Suppress auto suspend. Additional context Follow up from Notify maintainers Metadata
I'm on Wayland if that matters.
I believe it only touches the dconf profile in gdm, and sets these settings You probably still have those set in your actual session. See the OP of for more details.
Though I could be misremembering things
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Not sure if it will work yet, but I ran these commands to make my settings match the autosuspend = false settings:
After making these changes, it still suspended. Then I killed , and since it has restarted it has not auto suspended. I'm not sure if this is the simplest thing, but what worked for me was: set , rebuild NixOS Kill so it restarts
returns nothing for me on unstable. I have set to false and it still suspends. (I not 100% sure this is caused by gdm).
Well, it started auto-suspending for me again, even with the above settings.
I'm trying this now:
Seems to be working!
In my case it was xorg, not gdm at all. I disabled screensaver and autosuspend with:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Wow, it's 2023, and this still appears to be the solution To clarify I actually did the suggestion in here, which has an additional line
I vote to reopen this. The fix is easy to configure, but difficult to understand.
It seems like "don't suspend my system, i'm running this as a server" should just be a single config option
Code change:
npmDepsHash = "sha256-157hm7h5FWuOuxoo6WTtlMPq5LcRZIsSt5NDg0pvim8="; npmFlags = [ "--legacy-peer-deps" ]; <del> nativeBuildInputs = [ (writeShellScriptBin "phantomjs" "echo 2.1.1") pkg-config ] ++ lib.optionals (! stdenv.isDarwin) [ makeWrapper copyDesktopItems ]; buildInputs = [ pixman cairo pango ] ++ lib.optionals stdenv.isDarwin [ darwin.apple_sdk_11_0.frameworks.CoreText giflib ]; </del> <ins> nativeBuildInputs = [ (writeShellScriptBin "phantomjs" "echo 2.1.1") pkg-config ] ++ lib.optionals (!stdenv.isDarwin) [ makeWrapper copyDesktopItems ]; buildInputs = [ pixman cairo pango ] ++ lib.optionals stdenv.isDarwin [ darwin.apple_sdk_11_0.frameworks.CoreText ]; </ins> desktopItems = [ (makeDesktopItem {

Related discussion:
text: 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]:
Code change:
stdenv.mkDerivation (finalAttrs: { pname = "quickemu"; <del> version = "4.9.4"; </del> <ins> version = "4.9.4-unstable-2024-05-28"; </ins> src = fetchFromGitHub { owner = "quickemu-project"; repo = "quickemu"; <del> rev = finalAttrs.version; hash = "sha256-fjbXgze6klvbRgkJtPIUh9kEkP/As7dAj+cazpzelBY="; </del> <ins> rev = "d78255b097b599e8ab3713cb61c4085cc45f5a95"; # TODO: return to version on next release hash = "sha256-fF306CdGqKM+779OLm0NNyqPBtm7TuU7UN/NanT12y8="; </ins> }; postPatch = ''

Related discussion:
text: There is a bug in the latest release of quickemu (present in nixpkgs), that sends invalid flags to qemu and thus doesn't work for MacOS (maybe others too). The fix I was planning to PR was to simply move the src to point to the most current revision. I wasn't 100% sure if that was something that I should do however, given it would set the precedent that we follow revisions for this package instead of the version tag, which may add maintenance burden. Just wanted opinions before I made a PR, would it be acceptable to bump the revision temporarily to avoid this issue? It's niche but its real and could affect users of this package. Steps to reproduce the behavior: Pops open a Qemu window with the appropriate screens. Fails with a strange "macos-ventura/macos- file not found", but it is related to the bugged release. <!-- 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]:
Don't know of any official policy on this. My opinion: If it's a single commit that fixes the issue, you can add a patch. If it's spread out over multiple commits, use current unstable, but that may introduce other unknown regressions and breaking changes. And in any case we'd go back to the release tag on the next release.
Patching sounds like a good idea, hopefully it is just one commit. Though honestly from personal testing the newest release worked perfectly fine (I tested via an override).
Code change:
User = "unifi"; UMask = "0077"; WorkingDirectory = "${stateDir}"; <ins> # Hardening AmbientCapabilities = ""; CapabilityBoundingSet = ""; # ProtectClock= adds DeviceAllow=char-rtc r DeviceAllow = ""; DevicePolicy = "closed"; LockPersonality = true; NoNewPrivileges = true; PrivateDevices = true; PrivateMounts = true; PrivateTmp = true; PrivateUsers = true; ProtectClock = true; ProtectControlGroups = true; ProtectHome = true; ProtectHostname = true; ProtectKernelLogs = true; ProtectKernelModules = true; ProtectKernelTunables = true; ProtectSystem = "strict"; RemoveIPC = true; RestrictNamespaces = true; RestrictRealtime = true; RestrictSUIDSGID = true; SystemCallErrorNumber = "EPERM"; SystemCallFilter = [ "@system-service" ]; # Required for ProtectSystem=strict BindPaths = [ stateDir ]; # Needs network access PrivateNetwork = false; # Cannot be true due to OpenJDK MemoryDenyWriteExecute = false; </ins> }; };

Related discussion:
text: Describe the bug The unifi controller has dropped a present in my : Seeing as Unifi support has asked me about "temp", the "device tab", and my network topology, I'm not holding out on getting a good answer as to what it's doing. Short of that, I'd like to prevent it from having any access anywhere except a single temp, non-executable location managed by systemd.
I marked this as stale due to inactivity. &rarr;
Code change:
meta = with stdenv.lib; { homepage = "https://01.org/linuxmedia"; license = licenses.mit; <del> description = "Intel driver for the VAAPI library"; platforms = platforms.unix; maintainers = with maintainers; [ ]; </del> <ins> description = "VA-API user mode driver for Intel GEN Graphics family"; longDescription = '' This VA-API video driver backend provides a bridge to the GEN GPUs through the packaging of buffers and commands to be sent to the i915 driver for exercising both hardware and shader functionality for video decode, encode, and processing. VA-API is an open-source library and API specification, which provides access to graphics hardware acceleration capabilities for video processing. It consists of a main library and driver-specific acceleration backends for each supported hardware vendor. ''; platforms = [ "x86_64-linux" "i686-linux" ]; maintainers = with maintainers; [ primeos ]; </ins> }; }

Related discussion:
text: Describe the bug Upstream intel-vaapi-driver removed the --enable-drm ./configure option. It is now turned on by default. Happened in commit To Reproduce Steps to reproduce the behavior: the package and read through compile log Additional context This is a warning, package builds just fine despite this. Metadata Please run and paste the result. Maintainer information: (I don't know if I am dealing with attribute or module. I think attribute, but just to cover all bases.)
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 .
Code change:
pydf = callPackage ../applications/misc/pydf { }; <del> pygmentex = callPackage ../tools/typesetting/pygmentex { }; </del> pympress = callPackage ../applications/office/pympress { }; pythonIRClib = pythonPackages.pythonIRClib;

Related discussion:
text: 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
Code change:
<del> { lib, buildPythonPackage, fetchPypi , billiard, click, click-didyoumean, click-plugins, click-repl, kombu, pytz, vine , boto3, case, moto, pytest, pytest-celery, pytest-subtests, pytest-timeout </del> <ins> { lib , billiard , boto3 , buildPythonPackage , case , click , click-didyoumean , click-plugins , click-repl , fetchPypi , kombu , moto , pymongo , pytest-celery , pytest-subtests , pytest-timeout , pytestCheckHook , pythonOlder , pytz , vine </ins> }: buildPythonPackage rec { pname = "celery"; version = "5.2.1"; <ins> format = "setuptools"; disabled = pythonOlder "3.7"; </ins> src = fetchPypi { inherit pname version; sha256 = "sha256-tBpZC0nK+OZJilfbYo5YDV+Nxv69oPQt5deDrtW3+Ag="; }; <del> propagatedBuildInputs = [ billiard click click-didyoumean click-plugins click-repl kombu pytz vine ]; </del> <ins> propagatedBuildInputs = [ billiard click click-didyoumean click-plugins click-repl kombu pytz vine ]; checkInputs = [ boto3 case moto pymongo pytest-celery pytest-subtests pytest-timeout pytestCheckHook ]; disabledTestPaths = [ # test_eventlet touches network "t/unit/concurrency/test_eventlet.py" # test_multi tries to create directories under /var "t/unit/bin/test_multi.py" "t/unit/apps/test_multi.py" ]; </ins> <del> checkInputs = [ boto3 case moto pytest pytest-celery pytest-subtests pytest-timeout ]; </del> <ins> disabledTests = [ "msgpack" "test_check_privileges_no_fchown" ]; </ins> <del> # ignore test that's incompatible with pytest5 # test_eventlet touches network # test_mongodb requires pymongo # test_multi tries to create directories under /var checkPhase = '' pytest -k 'not restore_current_app_fallback and not msgpack and not on_apply and not pytest'  --ignore=t/unit/contrib/test_pytest.py  --ignore=t/unit/concurrency/test_eventlet.py  --ignore=t/unit/bin/test_multi.py  --ignore=t/unit/apps/test_multi.py  --ignore=t/unit/backends/test_mongodb.py ''; </del> <ins> pythonImportsCheck = [ "celery" ]; </ins> meta = with lib; { <del> homepage = "https://github.com/celery/celery/"; </del> description = "Distributed task queue"; <ins> homepage = "https://github.com/celery/celery/"; </ins> license = licenses.bsd3; <del> maintainers = [ ]; </del> <ins> maintainers = with maintainers; [ ]; </ins> }; }

Related discussion:
text: Octoprint can't build on unstable due to a conflict of the required version for . octoprint , while the dependency requires (due to ) . Octoprint builds successfully I ran a between and (known good) , the first bad commit was I suspect that it's necessary to pin the additional dependencies (and maybe some more), too, but I'm not that experienced with packaging python packages. made the first bad commit Octoprint maintainers: system: host os: multi-user?: sandbox: version: channels(root): channels(richard): nixpkgs: Maintainer information:
Code change:
<ins> diff --git a/hotspot/src/os/linux/vm/os_linux.cpp b/hotspot/src/os/linux/vm/os_linux.cpp index c477851c1b..ff5e28d95b 100644 --- a/hotspot/src/os/linux/vm/os_linux.cpp +++ b/hotspot/src/os/linux/vm/os_linux.cpp @@ -368,13 +368,13 @@ void os::init_system_properties_values() { //        ... //        7: The default directories, normally /lib and /usr/lib. #if defined(AMD64) || defined(_LP64) && (defined(SPARC) || defined(PPC) || defined(S390)) -#define DEFAULT_LIBPATH "/usr/lib64:/lib64:/lib:/usr/lib" +#define DEFAULT_LIBPATH "" #else -#define DEFAULT_LIBPATH "/lib:/usr/lib" +#define DEFAULT_LIBPATH "" #endif // Base path of extensions installed on the system. -#define SYS_EXT_DIR     "/usr/java/packages" +#define SYS_EXT_DIR     "" #define EXTENSIONS_DIR  "/lib/ext" #define ENDORSED_DIR    "/lib/endorsed" @@ -437,13 +437,13 @@ void os::init_system_properties_values() { strlen(v) + 1 + sizeof(SYS_EXT_DIR) + sizeof("/lib/") + strlen(cpu_arch) + sizeof(DEFAULT_LIBPATH) + 1, mtInternal); -    sprintf(ld_library_path, "%s%s" SYS_EXT_DIR "/lib/%s:" DEFAULT_LIBPATH, v, v_colon, cpu_arch); +    sprintf(ld_library_path, "%s%s", v); Arguments::set_library_path(ld_library_path); FREE_C_HEAP_ARRAY(char, ld_library_path, mtInternal); } // Extensions directories. -  sprintf(buf, "%s" EXTENSIONS_DIR ":" SYS_EXT_DIR EXTENSIONS_DIR, Arguments::get_java_home()); +  sprintf(buf, "%s" EXTENSIONS_DIR, Arguments::get_java_home()); Arguments::set_ext_dirs(buf); // Endorsed standards default directory. </ins>

Related discussion:
text: I don't have a lot of experience yet with the JDK derivation (8.nix etc..)
I don't have a lot of experience with that either, but I do implement RubberDuck and I'm happy to review Nix+Java ecosystem stuff.
Tagging who seems to do a lot of JVM Java work as well.
Reopening: more versions to be done
I marked this as stale due to inactivity. &rarr;
[x] OpenJDK 8: [x] OpenJDK 11: [ ] OpenJDK 17
why does openjdk 17 not have a mr?
Do you have a specific problem? With the example above I could not reproduce the jvm crash.
sorry, i thought i was hitting this bug, but turns out that the bug i hit is different
Is there a way to reproduce this issue for openjdk17? Otherwise I'd propose to close the issue.
Afaict, it has not been written yet. You may not have the "right" libraries in to make it crash. I don't think we need a reproducer. We know that the unpatched behavior is bad, and it is highly unlikely that upstream's behavior changes, because the rest of the world depends on it. did you have a specific reason not to patch OpenJDK 17? Could you patch it?
That patch does not seem to be too complicated. I could prepare it, but I'd feel better if I had some use case to test if the patch is working.
I mostly just forgot about it sadly. Some other stuff picked up and it kind of fell by the wayside sorry about that. On Thu, Jul 28, 2022, 2:19 AM Benjamin Asbach
Closing since it looks like the last bit of this was fixed by . Happy to reopen if I'm mistaken.
Code change:
installShellFiles = callPackage ../build-support/install-shell-files {}; <ins> # See doc/builders/special/invalidateFetcherByDrvHash.section.md or # https://nixos.org/manual/nixpkgs/unstable/#sec-pkgs-invalidateFetcherByDrvHash invalidateFetcherByDrvHash = f: args: let drvPath = (f args).drvPath; # It's safe to discard the context, because we don't access the path. salt = builtins.unsafeDiscardStringContext (lib.substring 0 12 (baseNameOf drvPath)); in f (args // { name = "${args.name or "source"}-salted-${salt}"; }); </ins> lazydocker = callPackage ../tools/misc/lazydocker { }; ld-is-cc-hook = makeSetupHook { name = "ld-is-cc-hook"; }

Related discussion:
text: Fetchers are hard to test because when the output sha is verified, Nix won't download it again. This leads to confusion and PRs that are effectively untested because the others do not realize that they need to remove the store path before testing. Examples: Steps to reproduce the behavior: a fetcher -build the fetcher -build "success" but the fetcher is broken a PR effort The fetcher runs every time. This is expected but not realistic, because Nix can not guess what to re-fetch. Instead, we can make fetcher testing easier by adding fetcher tests following the pattern: So this uses IFD which is probably ok for ofborg? Regarding ; instead of somewhere, we'll have to use to set on the fetchers because they're functions. The salt may need to be passed externally in case of pure evaluation. We could make it a Nixpkgs parameter that defaults to . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Maintainer information:
Workaround: Use followed by
Or we can just put the salt in the parameter. Nix isn't clever enough to find same-hash renames in the store :)
And the salt can be derived from the unsalted drv path, which is exactly what we want. See
Code change:
path = with pkgs; [ iptables ipset iproute systemd ]; postStart = '' <del> ${pkgs.ipset}/bin/ipset -quiet create -exist sshguard4 hash:ip family inet ${pkgs.ipset}/bin/ipset -quiet create -exist sshguard6 hash:ip family inet6 </del> ${pkgs.iptables}/bin/iptables  -I INPUT -m set --match-set sshguard4 src -j DROP ${pkgs.iptables}/bin/ip6tables -I INPUT -m set --match-set sshguard6 src -j DROP '';

Related discussion:
text: When the service starts, the following message is printed to the logs: sshguard[]: sshg-fw-ipset: Could not initialize firewall Blocking does not actually work. Blocked hosts can still initialize ssh connections. Default sshguard config. system: host os: multi-user?: sandbox: version: channels(root): channels(XXXX): nixpkgs:
It seems like that is due to ipsets being created of different types than intended. I'm not sure where it's getting created with that though: # ipset -L Name: sshguard4 Type: hash:ip Revision: 4 Header: family inet hashsize 1024 maxelem Size in memory: 88 References: 1 Number of entries: 0 Members: Name: sshguard6 Type: hash:ip Revision: 4 Header: family inet6 hashsize 1024 maxelem Size in memory: 104 References: 2 Number of entries: 0 Members: Whereas the script intends to create types which is why it returns with an error. I do not see where in the sshguard is type of ipset getting created. I came across though.
Code change:
{ stdenv, fetchurl, nss, python3 , blacklist ? [] <del> , includeEmail ? false </del> <ins> # Used for tests only , runCommand , cacert , openssl </ins> }: with stdenv.lib;

Related discussion:
text: Describe the bug Putting a valid certificate name in will cause nixos-rebuild to fail. To Reproduce Steps to reproduce the behavior: this line in . This command will fail. Expected behavior finishes sucessfully. Additional context This error message is related to : I guess this error is caused by switching to python 3. 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 Please run and paste the result. Maintainer information:
isn't compatible with Python 3, it seems. We'll need to update or carry a patch.
MRTC:
Code change:
import ../make-test-python.nix ( <del> { pkgs, lib, ... }: { </del> <ins> { pkgs, lib, ... }: let quadletContainerFile = pkgs.writeText "quadlet.container" '' [Unit] Description=A test quadlet container [Container] Image=localhost/scratchimg:latest Exec=bash -c 'trap exit SIGTERM SIGINT; while true; do sleep 1; done' ContainerName=quadlet Volume=/nix/store:/nix/store Volume=/run/current-system/sw/bin:/bin [Install] WantedBy=default.target ''; in { </ins> name = "podman"; meta = { maintainers = lib.teams.podman.members;

Related discussion:
text: Unable to use Podman's quadlets feature for a user, since the service unit files are not generated by systemd. Steps to reproduce the behavior: a quadlet file in (say, ) . Systemd says that no unit files were found. Caddy service should have been generated and its status displayed. This issue is caused by not symlinking the provided by the package to . Does not occur at the system level, since is already symlinked to Fix: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Confirmed the quadlet systemd user generator is not found in /etc/systemd. I'm gonna take this one and try to come up with a fix in NixOS module.
Code change:
wrapFirefox = { browser, browserName ? "firefox", desktopName ? "Firefox", nameSuffix ? "" <del> , icon ? "${browser}/lib/${browser.name}/icons/mozicon128.png" }: </del> <ins> , icon ? "${browser}/lib/${browser.name}/browser/icons/mozicon128.png" }: </ins> let cfg = stdenv.lib.attrByPath [ browserName ] {} config; enableAdobeFlash = cfg.enableAdobeFlash or false;

Related discussion:
text: firefox package is missing its icon in the KDE4 menu whatever its called today.
Any update on this issue? Is it a license problem?
Try firefoxWrapper.
Code change:
{ stdenv, lib, fetchurl, docbook_xsl, docbook_xsl_ns, gettext, libxslt, glibcLocales, docbook_xml_dtd_412, docbook_sgml_dtd_41, texlive, opensp <del> , perl, buildPerlPackage, ModuleBuild, TextWrapI18N, LocaleGettext, TermReadKey, SGMLSpm, UnicodeLineBreak, PodParser, YAMLTiny }: </del> <ins> , perl, buildPerlPackage, ModuleBuild, TextWrapI18N, LocaleGettext, TermReadKey, SGMLSpm, UnicodeLineBreak, PodParser, YAMLTiny , fetchpatch }: </ins> buildPerlPackage rec { pname = "po4a";

Related discussion:
text: Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible- . nix-build '<nixpkgs' -A --check --keep-failed You can use to analyze the differences in the output of the two builds. To view the build log of the build that produced the artifact in the binary cache: nix-store --read-log $(nix-instantiate '<nixpkgs' -A ) Tested on nixpkgs
PR was merged and made it to nixos-unstable, so this should be fixed