jiebi/CodeConvo huggingface dataset:
Change:
dropbear = callPackage ../tools/networking/dropbear { }; <del> dsview = qt6Packages.callPackage ../applications/science/electronics/dsview { }; </del> <ins> dsview = libsForQt5.callPackage ../applications/science/electronics/dsview { }; </ins> dtach = callPackage ../tools/misc/dtach { };

Discussion:
Decoders fail to load due to . Steps to reproduce the behavior: Working Module Imports (no ) Working decoders Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Can you check if the above PR fixes the issue. I'm not able to test it right now as I don't have access to a DSLogic device ATM.
I'm unable to test the PR ATM, but the issue didn't require any device to be attached. Just install and run DSView as per bug report.
Ok just running and playing around did work for me after the update.
Hey, I checked this on my box, and I don't seem to be able to reproduce this issue, decoders seem to work for me when trying the demo device.
Change:
{ <del> mkDerivation, lib, </del> <ins> mkDerivation, lib, makeWrapper, </ins> extra-cmake-modules, kdoctools, kbookmarks, kcompletion, kconfig, kconfigwidgets, kcoreaddons, kguiaddons, ki18n, kiconthemes, kinit, kdelibs4support, kio, knotifications,

Discussion:
The arrow keys, and also Home, End etc. don't work in konsole or yakuake. Pressing them does nothing - in particular it does not print an escape code, which makes me think that this isn't a problem. I am using these from XFCE, rather than KDE, but I would hope that that would be supported. Install konsole. Try to use the arrow keys. System: 18.03pre116572. (Impala) Nix version: 1.11.15 Nixpkgs version: 18.03pre116572. Sandboxing enabled: yes
I think it was that mentioned this on the ~mailing list~ #nixos as well. Did you find a solution?
I didn't, I switched to Plasma.
Possibly relevant: running I get output for arrow keys, but nothing when running .
i switched to xfce4-terminal but we need to fix this, konsole is rather important for us.
I also switched to Plasma, where it works. One thing I think I discovered when trying to debug this is that it is not a issue, or anything relating to interpretation of escape sequences. Rather than getting uninterpreted escape sequences, it appears that konsole just doesn't get sent the sequences at all.
xev started from konsole can still get cursor keys, konsole still can't receive them.
The navigation keys are not working because konsole can't find the data file for the . As a temporary workaround, I manually placed in my home directory under . For a real fix, konsole would need to look at the correct path in the nix store. Right now it relies on . Maybe this should include ?
this solution is awesome, can you also fix the problem in nixpkgs? afterwards contact me to get a reward!
Change:
}; config = lib.mkIf cfg.enable { <ins> warnings = lib.optional (lib.hasAttr "Touch" cfg.config) '' The option `services.iptsd.config.Touch` has been renamed to `services.iptsd.config.Touchscreen`. ''; </ins> systemd.packages = [ pkgs.iptsd ]; environment.etc."iptsd.conf".source = configFile; systemd.services."iptsd@".restartTriggers = [ configFile ];

Discussion:
The option declared is invalid in IPTSD v3, because it has been renamed to differentiate it from . It does not have any effect. Steps to reproduce the behavior: to configuration that neither option is effective. I expected the options to work as documented. You can find the relevant commit in IPTSD or consult the sample configuration file that is linked in the docstring for to confirm. I would suggest that that link is updated to a permalink pointing to the version that is built by the nix package, instead of pointing to the latest. Further, I would suggest that all options in be removed, due to the following reasons: There are far more options than currently documented The fact that some of them are, while others aren't, can potentially be confusing As one can see here, they are subject to change Other packages that implement a subset of available options similar to this follow a pattern where you can find those options in the "root" of the module options, e.g. , and additionally have an attribute set option called or similar that is empty by default Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
That's why it's a . See
That would require the documentation to built with access to packages which is discouraged.
They should still be effective:
Ah, okay, that makes sense. Damn it, that means I need to fiddle with the other options... Sorry about that. Thanks for the quick response :)
It's the other way around: This has no effect! Since the declaration of the default values comes first. That's where my confusion came from. Is there a good way to avoid this? Maybe set those options at the end of the ini, instead of the beginning? I assume it is parsed top-down and re-declarations are ignored.
My PR will fix it. You can keep using Touch and it will override whichever default is set for Touchscreen.
Change:
onlyoffice-documentserver = callPackage ../servers/onlyoffice-documentserver { }; <ins> outline = callPackage ../servers/web-apps/outline { }; </ins> openbgpd = callPackage ../servers/openbgpd { }; openafs_1_8 = callPackage ../servers/openafs/1.8 { tsmbac = null; ncurses = null; };

Discussion:
Project description Outline is a modern web application for creating documentation, kind of a Wiki. Metadata homepage URL: source URL: license: Custom platforms: linux
I marked this as stale due to inactivity. &rarr;
Closing in favor of

Project description Team wiki, documentation, meeting notes, playbooks, onboarding, work logs, brainstorming, & more… Metadata homepage URL: source URL: license: Business Source License 1.1 platforms: unix
I marked this as stale due to inactivity. &rarr;
Change:
uudeview = callPackage ../tools/misc/uudeview { }; <ins> uutils-coreutils = callPackage ../tools/misc/uutils-coreutils { inherit (pythonPackages) sphinx; }; </ins> zabbix-cli = callPackage ../tools/misc/zabbix-cli { }; ### DEVELOPMENT / EMSCRIPTEN

Discussion:
I would absolutely love for somebody to package up :)
will attempt to reserve some time to give it a try in the next days :-)
I created a first working version which compiles on my machine ( ): Unfortunately I had to use an older revision since the latest revisions require language features from Rust 1.19 and I'll have to bump it in nixpkgs before using the latest revision, after that I'll open a PR :-)
btw do we want to add an option which allows to change the coreutils pkg from to ? Something like and every module should start start using .
I had contemplated using a package override and just make equal to . Not sure how well that would work out... This may be something where is one of the few qualified to chime in.
Please don't introduce this as a NixOS option. This rewrite is not compatible with the GNU coreutils. This will certainly break NixOS. The package override will break lots of packages and will trigger a full rebuild anyway. Packaging these for testing is fine. :+1:
Could you just wrap this into a PR then? I will certainly test this and create some aliases to replace the GNU tools (in the user environment)
sorry for the delay at first. I'm aware of this. I just proposed an approach to switch the package just for system-wide testing purposes. This is actually the better approach. Furthermore this is something anyone can do locally, so shouldn't have concers with it as it shouldn't affect code in for now :-) I'll certainly do. However we have to wait for since the latest revisions of require Rust 1.19 (I'm currenty using an older revision from July 2017 locally). I checked out this change tried to compile uutils-coreutils against the new Rust compiler, but it cargo builds seem to fail ()
Ah, of course. Let's wait for then.
after has been merged it should be possible to finally implement this. Will open a PR in th next days...
Change:
disabled by default. ''; }; <ins> useQtScaling = mkOption { type = types.bool; default = false; description = "Enable HiDPI scaling in Qt."; }; </ins> }; };

Discussion:
We should add a NixOS option to set the environment variable. This variable is very useful for HiDPI displays, but it is not enabled by default.
I marked this as stale due to inactivity. &rarr;
This is still an issue, and a good first one at that.
Hey, i'd like to try and get this working, as a first issue :), seems within my grasp and i'd love to start contributing. Just to make sure, this variable being unset has the exact same effect of it being set to 0, right? So i can safely make the NixOS option (which would be the default?) explicitly set it to zero without changing current behaviour?
Change:
buildInputs = [ pam libkrb5 cyrus_sasl miniupnpc ]; <del> configureFlags = ["--with-libc=libc${stdenv.targetPlatform.extensions.sharedLibrary}"]; </del> <ins> configureFlags = if !stdenv.isDarwin then [ "--with-libc=libc.so.6" ] else [ "--with-libc=libc${stdenv.targetPlatform.extensions.sharedLibrary}" ]; </ins> dontAddDisableDepTrack = stdenv.isDarwin;

Discussion:
Describe the bug Running the binary from the package produces the following error message: To Reproduce Metadata system: host os: multi-user?: sandbox: version: channels(me): channels(root): nixpkgs: Maintainer information:
cc I've dug through the source a little bit, and it seems that the configure scripts are setting preloading support to false. Unfortunately I do not really understand the autoconf tooling or the preload mechanism, so I'm having a hard time debugging, do you have any tips?
It's caused by the same breakage I mentioned . I've set a reminder to PR a fix for it once I'm home tonight, but here's the fix in overlay format if you like:
Change:
log = "0.4.21" nix = { version = "0.28.0", features = ["fs", "signal"] } regex = "1.10.4" <del> rust-ini = "0.21.0" </del> <ins> rust-ini = { git = "https://github.com/zonyitoo/rust-ini", rev = "5748ae57a178216a920b88dfac1296618e967447", features = [ "inline-comment", ] } </ins> syslog = "6.1.1" [build-dependencies]

Discussion:
See title. It also may fail to correctly parse comments within such blocks as well, but unsure. a systemd unit in config e.g. to switch configuration (though this might only happen on the second switch, trying to parse existing config?) with Per , this is valid syntax: The value of should thus be parsed to (I may have gotten the spaces wrong there) If applicable, add screenshots to help explain your problem. Patch for failing example test case (may not be perfect): also due to authoring Please run and paste the result. I was running dry-activate to a config using nixpkgs @ Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for the report! I've looked a little into this so far and switch-to-configuration doesn't actually use that much of the unit file contents, which could be fine considering that systemd's DBus interface exposes almost all of their unit properties as DBus properties. However, since NixOS uses some custom unit properties (think ), these aren't exposed as DBus properties. So instead I've gone the route of adding support for multi-line values in the INI parser used for switch-to-configuration-ng, with the eventual goal of upstreaming this support to that crate. This isn't going to be something that's immediately ready though, I should have a PR for review within the coming days. For now, I would recommend opting out of the switch-to-configuration-ng implementation with the following config until it's fixed:
The problem with INI in general is that there is no standard. The systemd syntax, after all, “is inspired by XDG Desktop Entry Specification .desktop files, which are in turn inspired by Microsoft Windows .ini files”.
Change:
fetchFromGitHub { owner = "CodeDownIO"; repo = "General"; <del> rev = "de80ad56e87f222ca6a7a517c69039d35437ab42"; sha256 = "0pz1jmmcb2vn854w8w0zlpnihi470649cd8djh1wzgq2i2fy83bl"; # date = "2023-12-22T03:28:12+00:00"; </del> <ins> rev = "998c6da1553dc0776dfff314d2f1bd5af488ed71"; sha256 = "sha256-57RiIPTu9895mdk3oSfo7I3PYw7G0BfJG1u+mYkJeLk="; # date = "2024-07-01T12:22:35+00:00"; </ins> }

Discussion:
Steps to reproduce the behavior: -shell -p 'julia.withPackages ["Plots"]' or any other way to build julia.withPackages["Plots"] Also fails for makie and gadfly Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Yes, there are some problems with Julia 1.10 I've been meaning to investigate. In the meantime 1.9 should work:
Change:
# please do not unpin these even if they match the defaults, xivlauncher is sensitive to .NET versions dotnet-sdk = dotnetCorePackages.sdk_8_0; <del> dotnet-runtime = dotnetCorePackages.runtime_6_0; </del> <ins> dotnet-runtime = dotnetCorePackages.runtime_8_0; </ins> dotnetFlags = [ "-p:BuildHash=${rev}"

Discussion:
Package name: xivlauncher Latest released version: Current version on the unstable channel: 1.0.8 Current version on the stable/release channel: 1.0.8 <!-- 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 Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
9 also released yesterday but I don't see a PR or issue for it. Quite likely there will be sever more releases as they work on fixes for the new expansion that dropped today.
9 (which is recent enough to successfully download and play Dawntrail) was merged to master yesterday, and 24.05 today; we're at the mercy of Hydra for that to show up in the release channels. Hopefully that will be fairly soon. I'll get around to 1.1.0 at some point – it fixes repair, but that's it, and I'm currently enjoying the new expansion.
Ah! I didn't see 1.0.9 got in when I search! Enjoy Dawntrail!
Change:
<ins> { lib, buildGoModule, fetchFromGitHub, }: buildGoModule rec { pname = "zoraxy"; version = "3.0.5"; src = fetchFromGitHub { owner = "tobychui"; repo = "zoraxy"; rev = "refs/tags/${version}"; sha256 = "sha256-bTd6IwzVYxs1xvoy7AdB7WTGfgtHJI+qM3335OWkOEo="; }; sourceRoot = "${src.name}/src"; vendorHash = "sha256-YI6LSccPDnVhGyPIEFIF41ex0WJlHtb3nP+8+1G/LA0="; checkFlags = let # Skip tests that require network access skippedTests = [ "TestExtractIssuerNameFromPEM" "TestReplaceLocationHost" "TestReplaceLocationHostRelative" "TestHandleTraceRoute" "TestHandlePing" ]; in [ "-skip=^${builtins.concatStringsSep "$|^" skippedTests}$" ]; meta = { description = "A general purpose HTTP reverse proxy and forwarding tool written in Go"; homepage = "https://zoraxy.arozos.com/"; changelog = "https://github.com/tobychui/zoraxy/blob/v${version}/CHANGELOG.md"; license = lib.licenses.agpl3Only; maintainers = [ lib.maintainers.luftmensch-luftmensch ]; mainProgram = "zoraxy"; }; } </ins>

Discussion:
Project description "A general purpose HTTP reverse proxy and forwarding tool." Metadata homepage URL: source URL: license: agpl-3.0 platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
leatherman = callPackage ../development/libraries/leatherman { }; <ins> lact = callPackage ../tools/system/lact { }; </ins> ledit = callPackage ../tools/misc/ledit { inherit (ocaml-ng.ocamlPackages_4_12) ocaml camlp5; };

Discussion:
Project description LACT is an AMD GPU controller on Linux that doesn't have to run in background like corectrl. It uses GTK4 and rust. Metadata homepage URL: source URL: license: MIT platforms: Linux
Thank you so much!
Change:
testScript = '' client.wait_for_unit("dnsmasq") client.wait_for_unit("dnscrypt-proxy2") <ins> client.wait_until_succeeds("ss --numeric --udp --listening | grep -q ${toString localProxyPort}") </ins> ''; })

Discussion:
On (nixos-unstable), services.dnscrypt-proxy2 is crashing (core dumping) on startup, due to SECCOMP error. Steps to reproduce the behavior: () () The tests succeeds but dnscrypt-proxy2 actually fails to start. Excerpt from VM log: From dmesg: dnscrypt-proxy2 should startup, and listen for DNS requests.
looks like it could a fix for this? (Update: Confirmed this fixes it.) Also, we should look into: why the test passes, despite dnscrypt-proxy2 failing to start. what triggered this issue? I see no recent changes to dnscrypt-proxy2 pkg or service.
I think does reach state briefly, and so succeeds, but then the binary crashes when it runs the Setrlimit syscall. should have stronger assertions, e.g. that dnscrypt-proxy2 manages to listen on port 43 (). I've raised a PR for this:
Hypothesis: A recent Go runtime update that now calls setrlimit? (Update: Reverting . didn't stop the issue occurring)
It's probably introduced in Go 1.19 because I didn't find significant changes on systemd side. We'd expect this kind of issues popping out in the near future.
Confirmed. Changing dnscrypt2-proxy to use Go 1.18 fixes this (but allowing syscalls is the better fix, as MidAutumnMoon has proposed). introduces the setrlimit syscall in an init function (matching the stack trace), released in Go 1.19. This issue should be closed once the following are merged:
This also affects .
Some Go programs crashed but some didn't. For example has set but still runs pretty fine. (However its tests failed for unknown reasons.)
cc Could you take a look at 's tests?
cc tests failed on my machine. Could you take a look?
cc Could you take a look at 's tests?
I think I've caught 'em all.
So, anything left?
Nothing :)
Great work for searching for all the occurrences of this, and fixing them before users noticed!
And thank for sorting out this issue and reviewing changes.
Change:
"../${afl.src.name}/qemu_mode/patches/memfd.diff" # nix-specific patches to make installation more well-behaved ./qemu-patches/no-etc-install.patch <ins> # patch for fixing qemu build on glibc >= 2.30 ./qemu-patches/syscall-glibc2_30.diff </ins> ]; configureFlags =

Discussion:
Describe the bug Building afl is broken because a dependency (qemu 2.8) can't be built. This seems to be related to an update of glibc. Probably applying the fix here will solve this partially, but I think further investigation is needed. Probably the fix would be somewhere along the lines of: Replace the call with Replace with Replace with To Reproduce Steps to reproduce the behavior: (see below for my current nixpkgs version) that qemu build starts build fails with the errors below. <details<summaryBuild error log</summary</detailsExpected behavior AFL builds correctly. Additional context See also the issue in AFLplusplus: Remove QEMU support is useful as a temporary workaround, but this prevents any users of that part of AFL (blackbox fuzzing) to be able to use the QEMU from nixpkgs. This fix might help solve the missing SIOC* defines: See also the HYDRA build and Metadata system: host os: multi-user?: sandbox: version: channels(rick): channels(root): nixpkgs: Maintainer information:
Change:
boot.growPartition = true; boot.loader.grub.device = "/dev/sda"; <ins> swap.swapDevices = { device = "/var/swap"; size = 2048; }; </ins> virtualisation.virtualbox.guest.enable = true; };

Discussion:
The VirtualBox ova file runs out of memory pretty quickly. As a backup we should have a swap file to store excess memory, especially for memory hungry programs like Nix.

Running an upgrade () runs out of memory using the default NixOS demo VM image with 1.5GB of RAM, despite the Nix manual recommending only 768MB RAM. Run default NixOS VM Image with 1.5GB RAM. Install , to user-profile. run . Adding a swapfile is enough to fix this issue. My recommendation is to edit the default Nix VM Image to include a swapfile by default. Users who wish to add a swapfile themselves can simply do the following as root Then edit to add an entry for the swap file: System: NixOS 16.09.1502. (Flounder) Nix version: 1.11.6 Nixpkgs version: 16.09.1502.
The manual sais on Chapter 2. 9.: "If your machine has a limited amount of memory, you may want to activate swap devices now" So when you carefully follow the manual to install NixOS it should be fine. Do you agree
That is all well and good, but that is in the section for installing NixOS from scratch. I am referring to the default NixOS VM provided under the . It would make sense if that VM had swap configured and enabled by default. Or if not, then it would make sense to add the swap recommendation in the "" section of the manual. I haven't tried the AWS AMIs, but I think the same goes for them.
a Live CD should not alter the HDD. you can't just automatically create a 1 GB partition on a Windows install. If you have already a swap partition, you could mount that. Would it be ok to just add some documentation? You can create a PR for that. Here is the code for the linked page:
I'm not referring to a liveCD, I'm referring to the VirtualBox image provided by NixOS. It is under the header "VirtualBox appliances" on Excerpt: This is a demo appliance for VirtualBox (in OVA format) that has X11 and KDE enabled, as well as the VirtualBox guest additions. To use it, download the OVA file, open VirtualBox, run “File → Import Appliance” from the menu, select the OVA file, and click “Import”. You can then start the virtual machine.

When the KDE login screen appears, you can log in as user demo, password demo. To obtain a root shell, run sudo -i in the KDE terminal (konsole). I also am curious if the AWS AMIs on that same page have the same issue. I doubt there is a way to submit a pull request to alter the Virtualbox OVA or the AWS AMIs
:+1: to this. I don't know what the solution is. But it definitely seems like the VirtualBox VM should get swap.
Change:
{ description = "Initialisation of swap device ${sw.device}"; wantedBy = [ "${realDevice'}.swap" ]; before = [ "${realDevice'}.swap" ]; <ins> # If swap is encrypted, depending on rngd resolves a possible entropy starvation during boot after = mkIf (config.security.rngd.enable && sw.randomEncryption.enable) [ "rngd.service" ]; </ins> path = [ pkgs.utillinux ] ++ optional sw.randomEncryption.enable pkgs.cryptsetup; script =

Discussion:
Describe the bug Since upgrading to 19.09, my laptop's boot process is delayed by about one minute due to entropy starvation during the boot process To Reproduce Steps to reproduce the behavior: configuration: { device = "/dev/disk/by-id/yadayada-part2"; = true; = "/dev/random"; } [possibly configure other services that also need entropy during boot] Expected behavior A quick boot as in 19.03 with max 1 second used by the swap initalization. Screenshots $ systemd-analyze plot | fgrep mkswap <text class="left" x="1018.920" y="694.000"mkswap-dev-disk-byx2did-nvmex2dSamsungSSD970EVO2TBS464NB0M401994Dx2dpart2.service (1min 723ms)</textAdditional context This is on physical hardware, not on VM. Replacing random with urandom leads to instant boot, but has the obvious problem with the missing entropy. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Basically there are two ways to fix this issue: 1) Find out why 19.03 had enough entropy but 19.09 seems to lack entropy during swap initialization and mitigate this 2) setup swap at a later time during boot, which obviously only works if the swap is not critical to the boot process I'm going to work on this later, but if you have any ideas or suggestions, feel free to comment.
I had a similar issue. it might be related to changes in the kernel ? I had a similar problem in VMs, managed to work around it with via (+virtio but you should only need this setting)
cannot solve this, as it starts after swap configuration and thus after the long delay. It may be possible to move it to an earlier point in the boot process, as it just requires hardware devices that should be available before swap.