jiebi/CodeConvo huggingface dataset:
Code change:
<del> { lib, stdenv, fetchurl </del> <ins> { lib, stdenv, fetchurl, makeWrapper </ins> , pkg-config, intltool , perl, gettext, libX11, libXext, libXi, libXt , libXft, libXinerama, libXrandr, libXxf86vm, libGL, libGLU, gle , gtk2, gdk-pixbuf, gdk-pixbuf-xlib, libxml2, pam <del> , systemd </del> <ins> , systemd, coreutils </ins> , forceInstallAllHacks ? false , withSystemd ? stdenv.isLinux }:

Related discussion:
text: Since commit the command is missing. It is used by xscreensaver to display text inside the screensavers like system information and kernel versions. It used to be in the package, as can be seen from this diff: The same applies to which was also removed by that commit Steps to reproduce the behavior: Text is printed when running instead of If applicable, add screenshots to help explain your problem. Add any other context about the problem here. system: host os: multi-user?: sandbox: version: channels(root): channels(pinpox): nixpkgs: Maintainer information:
«removed» here means «same lack of special measures as before» (the lines you cite are just fixes for the installed stuff), but upstream underwent a major rewrite. (Not saying that fix is not most welcome, just that this was not a removal as much as lack of finding out what to do now) Apparently the scripts are there in the tarball, maybe they need manual copying now, not sure
I just noticed it seems to work fine in the previewer application that comes with xscreensaver . E.g.: ! The same screensaver does not work though, when it starts "on it's own" after some idle time. The text then only reads Not sure what the difference is.
xscreensaver-text and others are in $out/libexec/xscreensaver btw speeds up the build of xscreensaver by a lot
Hm, is not in my path, but hacks launched via XScreenSaver proper find text just fine. And the daemon source code implies that is indeed to PATH in a normal situation.
Not sure if it's related, but it is also missing commands like and (output is shown in some of the screensavers). I have enabled xsceensaver with the home-manager option
Code change:
buildGoPackage rec { pname = "singularity"; <del> version = "3.2.1"; </del> <ins> version = "3.6.1"; </ins> <del> src = fetchFromGitHub { owner = "sylabs"; repo = "singularity"; rev = "v${version}"; sha256 = "14lhxwy21s7q081x7kbnvkjsbxgsg2f181qlzmlxcn6n7gfav3kj"; </del> <ins> src = fetchurl { url = "https://github.com/hpcng/singularity/releases/download/v${version}/singularity-${version}.tar.gz"; sha256 = "070jj6kbiw23sd2p4xhvmyb8gd83imwgisdf18ahkwp7dq85db3c"; </ins> }; goPackagePath = "github.com/sylabs/singularity"; goDeps = ./deps.nix; <del> buildInputs = [ openssl ]; nativeBuildInputs = [ removeReferencesTo utillinux which makeWrapper ]; </del> <ins> buildInputs = [ gpgme openssl libuuid ]; nativeBuildInputs = [ removeReferencesTo utillinux which makeWrapper cryptsetup ]; </ins> propagatedBuildInputs = [ coreutils squashfsTools ]; <del> prePatch = '' substituteInPlace internal/pkg/build/copy/copy.go  </del> <ins> postPatch = '' substituteInPlace internal/pkg/build/files/copy.go  </ins> --replace /bin/cp ${coreutils}/bin/cp '';

Related discussion:
text: , CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives. Cc Cc Cc
Backporting update that resolves these ().
Fixed in 20.03 and master.
Code change:
push @kernelModules, "kvm-intel" if hasCPUFeature "vmx"; push @kernelModules, "kvm-amd" if hasCPUFeature "svm"; <ins> push @attrs, "hardware.cpu.amd.updateMicrocode = lib.mkDefault config.hardware.enableRedistributableFirmware;" if cpuManufacturer "AuthenticAMD"; push @attrs, "hardware.cpu.intel.updateMicrocode = lib.mkDefault config.hardware.enableRedistributableFirmware;" if cpuManufacturer "GenuineIntel"; </ins> # Look at the PCI devices and add necessary modules.  Note that most # modules are auto-detected so we don't need to list them here.

Related discussion:
text: It would be nice if generated and options (only ). Processors without microcode update might run with misbehaving flashed microcode: /cc
Do you mean like setting it to or just mentioning it? It's a good thing for sure to have working hardware as opposed to not working, but OTOH it pulls non free code...
Of course setting it to true (actually to ), mentioning it would have no effect. First, already pulls in literal unfree code, e.g. Wi-Fi drivers on MacBook Air 6,x, not even redistributable. Second, non-free code is already running on Intel processors, I don't see any difference whether it's flashed or not (I know this is controversial). Third, for purposes of Nixpkgs, is free. And of course the kernel contains a whole lot of firmware blobs.
Strongly disagree here as its an equivalent of setting = true; thus will taint every installation by default, which is a reverse policy of the current nixos from optin to optout. That said, being complete new user, I have myself figured and found these options myself. My system booted without them likewise fine. In general, AMD patches CPUs with AGEISA BIOS updates, so does Intel - however these updates are optional and up to the user. This is should be mentioned on a) Installation page b) NIxos wiki - not be made default option, because this action is in conflict with policy.
I disagree that this is equivalent. CPU comes preflashed with microcode, BIOS comes with updated microcode for the processor to boot correctly (microcode that comes with CPU is very buggy and usually can't go through boot sequence correctly). It's not clear how it would add to the problem if we were to load an up-to-date microcode image. This is equivalent to shipping firmware to users that haven't set flag, which is current NixOS policy. Intel microcode is freely redistributable AFAIK.
The default state for these two switches is very clearly "disabled", plus they have no affect on non-AMD/intel CPUs. Flipping the switch in hardware-, is basically flipping the default state in the backstage, which is much worse than setting the defaults to "enabled", as it creates distrust and inconsistency cases. Further, firmware updates can cause real issues, not only solve them.
Code change:
push @kernelModules, "kvm-intel" if hasCPUFeature "vmx"; push @kernelModules, "kvm-amd" if hasCPUFeature "svm"; <ins> push @attrs, "hardware.cpu.amd.updateMicrocode = lib.mkDefault config.hardware.enableRedistributableFirmware;" if cpuManufacturer "AuthenticAMD"; push @attrs, "hardware.cpu.intel.updateMicrocode = lib.mkDefault config.hardware.enableRedistributableFirmware;" if cpuManufacturer "GenuineIntel"; </ins> # Look at the PCI devices and add necessary modules.  Note that most # modules are auto-detected so we don't need to list them here.

Related discussion:
text: It is irresponsible to think that they only solve issues. AMD AGEISA updates on 785G on has actually been broken for over a year for me, refusing to react to USB events on boot until I manually bypassed the tier 1&2 support (which is hell of a job for Linux user) to get to actual support for testing. About Intel, I have only encountered issues with gen3 PCIe cards in Intel motherboard for 2nd gen Core CPUs, but fixing this also required a year of waiting and UEFI reflash. Also speaking as an owner of HP() and Epson(sx525wd) printers - updating ucode actually caused hardware reflash and made legally purchased cartridges worthless. I am yet to encounter a CPU that can't pass boot sequence due to buggy ucode, but I doubt hot-loading it on OS stage would fix it, because it needs first to get to this stage. However I can clearly imagine the unpredictability if these switches are properly enabled.
Microcode is essentially a firmware for the CPU. NixOS, more specifically, the Linux kernel, will load firmwares for any device with support for that without asking the user. Loading microcode updates does not require a policy change, if anything, this would make the policy more consistent across the board. On a tangent, I don't understand why anyone would tolerate a blob flashed on CPU, and in BIOS, but would not tolerate the same blob being loaded by the kernel. That can be said about any software. Usually, the opposite is true. What I mean is that every BIOS except Libreboot contains microcode blobs that it loads onto the processor early in the boot sequence. Without that blob, boot sequence will most likely fail somewhere along the way. That's the reason why Libreboot doesn't support modern Intel/AMD CPUs, and why there is Coreboot/Libreboot split in the first place.
You are mixing very different cases into one bottle. Some hardware requires ucode to be loaded to function and won't function without. Some hardware has optional ucode updates. For this hardware, some classes load firmware update and then flash themselves - some lock the possibility to install previous revision, and some classes load the ucode as temporary override (which is case with AMD/Intel). Some hardware has open firmware (sources), but majority does not offer source.
Code change:
push @kernelModules, "kvm-intel" if hasCPUFeature "vmx"; push @kernelModules, "kvm-amd" if hasCPUFeature "svm"; <ins> push @attrs, "hardware.cpu.amd.updateMicrocode = lib.mkDefault config.hardware.enableRedistributableFirmware;" if cpuManufacturer "AuthenticAMD"; push @attrs, "hardware.cpu.intel.updateMicrocode = lib.mkDefault config.hardware.enableRedistributableFirmware;" if cpuManufacturer "GenuineIntel"; </ins> # Look at the PCI devices and add necessary modules.  Note that most # modules are auto-detected so we don't need to list them here.

Related discussion:
text: In essence, ucode is a blackbox and live-updating ucode is unpredictable black box. For some devices, ucode loading is a must, for others its optional. I suggest that we limit ourselves to specific case of Intel/AMD ucode, for which ucode updates are optional and crucial updates are applied only via hardware flashing. I am pretty sure that the reason why Libreboot supports less hardware has to do purely with acceptance criteria for how tainted ("blackboxed") the firmware is, and that both support little of x86, because Intel refused to provide specifications and AMD was open to some extent, but then closed up the AGESA after Phenom II because they most possibly implemented TPM in firmware(fTPM). About EULA-d + encrypted software, we are talking about closed-source hardware. For manufacturers of such software, surely opposite is true and the updates are usually used to keep their policy consistent and enforced, for users it means giving up and restricting all rights. That said, I found those options myself easily as a new user (yet my hardware functioned without issues without them) and I see a problem if they default to one value, but change "automatically" and unnoticed at run-time. Either way, this option should be documented better - and this includes places where its flipped.
It's not clear what difference does it make. Say, from freedom perspective, it would not be OK to use Windows even if I were to ignore any updates for it. If we ship updated microcode, which includes security fixes foremost, how would that taint installs any more than they currently are, with in-kernel blobs and such?
It has to do with blobs for the most part. See:
It replaces non-free code with a more up2date non-free code. Given Meltdown and Spectre this should be the default. Especially since it would be generated at installation time. Accompanied with the right comment, users who really want to have outdated CPUs will be notified and can delete one line. (well two with the comment).
I would like this to default to (microcode essentially is firmware). isn't supposed to be edited, it should just use so that user can override it in their config.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days.
Code change:
push @kernelModules, "kvm-intel" if hasCPUFeature "vmx"; push @kernelModules, "kvm-amd" if hasCPUFeature "svm"; <ins> push @attrs, "hardware.cpu.amd.updateMicrocode = lib.mkDefault config.hardware.enableRedistributableFirmware;" if cpuManufacturer "AuthenticAMD"; push @attrs, "hardware.cpu.intel.updateMicrocode = lib.mkDefault config.hardware.enableRedistributableFirmware;" if cpuManufacturer "GenuineIntel"; </ins> # Look at the PCI devices and add necessary modules.  Note that most # modules are auto-detected so we don't need to list them here.

Related discussion:
text: 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 . on the on .
still think this should be done, as new users probably don't know this option exists at all and that you have to enable it by yourself in NixOS. With concerns on, this should at least be generated as commented out, with a hint "while you will probably want this, note that it is unfree software".
I marked this as stale due to inactivity. &rarr;
Why is this no longer in discussion? As someone new to the NixOS universe and coming from Ubuntu I wasn't aware that I had to explicitely include this in my hardware configuration on NixOS until I stumbled across other people's configuration files. I definitely think it should at least be prominently featured in the installation manual or even better be enabled by default, as mentioned.
One way or another, needs to be enabled by default. These updates fix security issues, there are probably a lot of NixOS users now that don't even know that they're running insecure microcode. See also the discussion in
I've never replied to the first comment! While I still support the open hardware movement (and thus free software firmware) I also believe that having QEMU misbehave because of a missing update is not really a good default option. If the user is concerned about the microcode updates or about managing security at this level then they will probably read the auto-generated configuration and immediately spot an and will comment it out :-) So thanks for the PR, I can't review because I don't know perl :-p
Code change:
Use `lib.mkForce` to forcefully specify the overridden package. ''; }; <ins> enableExternalLocalStateDir = mkOption { type = types.bool; default = true; example = false; description = mdDoc '' Whether to use top-level directories as LOCALSTATEDIR instead of the store path ones. This affects the SESSIONDIR of Apptainer/Singularity. If set to true, the SESSIONDIR will become `/var/lib/''${projectName}/mnt/session`. ''; }; </ins> enableFakeroot = mkOption { type = types.bool; default = true;

Related discussion:
text: The derivation is missing the directory to work properly. Steps to reproduce the behavior: A clear and concise description of what you expected to happen. is output without error. This can be fixed by creating the directory manually (). I guess this could be to the derivation. <!-- 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.
NixOS module provides those top-level directories. discussed with one of the main Apptainer developer in . He think it should be easy to specify a directory that will always exist at build time. Regalding this, I'm considering the possibility to put those dilectories under the derivation store path. Not sure if there would be potential problem using a store path as a mount point, but it seems to work without problem.
Could you help me take a look at ?
If you have time, please help me test the PR . It should fundamentally solve this issue. If applied, you no longer need the NixOS module or just to run images. It specifies the LOCALSTATEDIR as , making both Apptainer and Sylabs SingularityCE works without . (The image running still depends on and to run images, which might be the final obstacle to build images as a package without invoking a virtual machine. Other than that, it should not be an issue for most users, as are available on most of the UNIX/UNIX-like systems.)
I removed (the temporary fix for this issue) and ran the following and it seems to work fine: Thank you for this fix!
Glad to hear that! Would you mind ? I've heard that committers tend to merge PRs getting two approvals.
Done!
Code change:
then "localSystem" else "crossSystem"} = { parsed = makeMuslParsedPlatform stdenv.hostPlatform.parsed; }; <del> } else throw "Musl libc only supports Linux systems."; </del> <ins> } else throw "Musl libc only supports 64-bit Linux systems."; </ins> # All packages built for i686 Linux. # Used by wine, firefox with debugging version of Flash, ...

Related discussion:
text: I get this error when the packages i build contain any musl one. Blocking me from reviewing PRs. Full error: Issue for a more helpful error message: Steps to reproduce the behavior: No error. I think the solution would be to disable musl libc on i686-linux until it actually works. So Nix or nixpkgs-review don't even try to build it. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Collecting information: this looks fine maybe here needs to be a check for 64-bit
Code change:
<ins> { lib , ninja , meson , fetchFromGitLab , systemd , libgudev , pkg-config , glib , python3 , gobject-introspection }: python3.pkgs.buildPythonApplication rec { pname = "switcheroo-control"; version = "2.3"; format = "other"; src = fetchFromGitLab { domain = "gitlab.freedesktop.org"; owner = "hadess"; repo = pname; rev = version; hash = "sha256-1Pze2TJ9mggfcpiLFwJ7/9WhsdJx4G3GoA7+Z47shuc="; }; nativeBuildInputs = [ ninja meson pkg-config # needed for glib-compile-resources glib ]; buildInputs = [ systemd libgudev ]; propagatedBuildInputs = [ python3.pkgs.pygobject3 ]; mesonFlags = [ "-Dsystemdsystemunitdir=${placeholder "out"}/etc/systemd/system" "-Dhwdbdir=${placeholder "out"}/etc/udev/hwdb.d" ]; meta = with lib; { description = "D-Bus service to check the availability of dual-GPU"; homepage = "https://gitlab.freedesktop.org/hadess/switcheroo-control/"; changelog = "https://gitlab.freedesktop.org/hadess/switcheroo-control/-/blob/${version}/NEWS"; license = licenses.gpl3Plus; maintainers = [ ]; platforms = platforms.linux; }; } </ins>

Related discussion:
text: Project description A dbus api to start programs on a different GPU Metadata homepage URL: source license: gpl3 platforms: linux
Duplicate
Code change:
(lib.enableFeature polkitSupport "polkit") ] ++ lib.optionals stdenv.isLinux [ "--enable-ipcdir=/run/pcscd" <del> "--with-systemdsystemunitdir=${placeholder "bin"}/lib/systemd/system" </del> <ins> "--with-systemdsystemunitdir=${placeholder "out"}/lib/systemd/system" </ins> ]; makeFlags = [

Related discussion:
text: uses two actions and do get necessary authorization via . but these actions are not properly registed, leading to error: (It can be verified that these actions don't exist by using ) This breaks and . I tried both pcsclite 1.9.5 and 2.0.1 ending up with the same error. Steps to reproduce the behavior: and in , configure your smartcard (yubikey) to use yubikey error There actions are registered correctly and usable. Please run and paste the result. I'm using flakes (no channels). Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
correct description of your effect, i am not able to use my yubikey with gpg.
This can be solved by
this works, thanks! but this is really unintuitive, given that is already adding the package to : I am leaving this open as I believe a proper fix should be provided in the module itself.
Same issue here. It was working approx. last Dec. I don't have a specific commit hash. Adding to works for me.
Looks like a regression in () - is implying to me that polkit actions get included in the output, however: isn't included, which explains why adding to fixes the issue. Solution ideas: Add to . Not sure about this one? seems to also contain some libraries that probably don't need to be installed. Install polkit actions to instead of . IMO this one makes the most sense, especially as it seems to have been the previous behaviour before this change.
I was bitten by this when attempting to update over the weekend as well. In my case it prevented login because I use smartcards for user login which made debugging difficult due to the number of reboots required. I tend to agree with that going back to having the polkit actions file in the output instead of makes the most sense. That will mean that of the pcsc module will again result in the polkit action file being to the system configuration.
Cc: ()
I also think the location should be fine, the files are also there.
I ran into this issue when I couldn't access my yubikey anymore via pcsc for commits. The above solution worked for me.
Code change:
(lib.enableFeature polkitSupport "polkit") ] ++ lib.optionals stdenv.isLinux [ "--enable-ipcdir=/run/pcscd" <del> "--with-systemdsystemunitdir=${placeholder "bin"}/lib/systemd/system" </del> <ins> "--with-systemdsystemunitdir=${placeholder "out"}/lib/systemd/system" </ins> ]; makeFlags = [

Related discussion:
text: I'm going to add some comments for SEO so this is easier to find
I think you have found the right culprit that caused the issue, but I suppose the issue has more to do with the itself, where it only includes if . This has been rectified in from what it seems. For now the proper solution seems to enabling polkit with .
I think that makes more sense based on the existing file structure but maybe we just switch bin to out, so it is the default and move the libs to lib instead of being in out.
I've created to make the outputs a lot more expected by moving the udev file and the systemd service to the out output and the libraries to the lib output: I didn't test it yet, so it is still in draft. If someone could verify that it doesn't break security keys again, that would be great and then please undraft it, otherwise I do it in the evening.
I do not think I can fully test this due to the amount of rebuilds, so please chime in for reviews and find the one mistake I might have done (which I hope I didn't)
Tried to build but it fails on my machine:
I've xdist to dulwich here . Let me see if we can just disable some tests as a speed up from 66s to 9s is quite good.
This should be a lot better with . I did a lot of rebuilds locally on a low and high core machine and didn't encounter any failures anymore.
This was fixed in , works fine for me.
Code change:
#   rev-version = /* human readable version; i.e. "unstable-2022-26-07" */; #   sha256 = /* checksum for this release, can omit if specifying your own `monorepoSrc` */; # } <del> , officialRelease ? { version = "18.1.4"; sha256 = "sha256-LyQEb4ZJXm2hkPOM9XITIploMT2VKIQWxUFio7SXrc0="; } </del> <ins> , officialRelease ? { version = "18.1.5"; sha256 = "0n44chqn96xsa00ryhwk8g0vv3zx908xjakkgjsa14sjr9mcsq8q"; } </ins> # i.e.: # { #   version = /* i.e. "15.0.0" */;

Related discussion:
text: Package name: LLVM Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 18.1.4 Current version on the stable/release channel: 18.1.4 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Want to submit a PR? The last upgrade was very straightforward:
I'll give it a shot