jiebi/CodeConvo huggingface dataset:
Change:
<ins> import ./make-test-python.nix ({ pkgs, ... }: { name = "maddy"; meta = with pkgs.lib.maintainers; { maintainers = [ onny ]; }; nodes = { server = { ... }: { services.maddy = { enable = true; hostname = "server"; primaryDomain = "server"; openFirewall = true; }; }; client = { ... }: { environment.systemPackages = [ (pkgs.writers.writePython3Bin "send-testmail" { } '' import smtplib from email.mime.text import MIMEText msg = MIMEText("Hello World") msg['Subject'] = 'Test' msg['From'] = "postmaster@server" msg['To'] = "postmaster@server" with smtplib.SMTP('server', 587) as smtp: smtp.login('postmaster@server', 'test') smtp.sendmail('postmaster@server', 'postmaster@server', msg.as_string()) '') (pkgs.writers.writePython3Bin "test-imap" { } '' import imaplib with imaplib.IMAP4('server') as imap: imap.login('postmaster@server', 'test') imap.select() status, refs = imap.search(None, 'ALL') assert status == 'OK' assert len(refs) == 1 status, msg = imap.fetch(refs[0], 'BODY[TEXT]') assert status == 'OK' assert msg[0][1].strip() == b"Hello World" '') ]; }; }; testScript = '' start_all() server.wait_for_unit("maddy.service") server.wait_for_open_port(143) server.wait_for_open_port(587) server.succeed("echo test | maddyctl creds create postmaster@server") server.succeed("maddyctl imap-acct create postmaster@server") client.succeed("send-testmail") client.succeed("test-imap") ''; }) </ins>

Discussion:
Maddy, a small and compact mail server written in Go, was merged as a package with by . Having a NixOS module to enable and configure it would be really great! If someone is interested in creating a PR, I will be happy to help and test it :+1: Best regards Jonas
Hi, I dont have any sort of way to properly test this within the actual nixos repo but I've got a personal working module/service you can try
I did something very similar to the above, but based my serviceConfig on the example . It contains quite a bit more of the systemd security features, so if you want to make something to include in nixpkgs I think all these things should be on! I also hooked it up to Dovecot, hence the waiting script, not sure if that's the best way of doing it.
How about this: Nice and simple.
Have you tried this? Somehow it doesn't work for me:
- it looks like the units aren't included in the nixpkgs package :man_shrugging:, but I created a PR to fix this in Please review, test, and approve PR. I have never used so I wouldn't want to merge that PR without you (or someone else) testing. Thanks!
Change:
, config , overlays , crossOverlays ? [ ] <ins> , bootstrapLlvmVersion ? if localSystem.isAarch64 then "11.1.0" else "7.1.0" </ins> # Allow passing in bootstrap files directly so we can test the stdenv bootstrap process when changing the bootstrap tools , bootstrapFiles ? if localSystem.isAarch64 then let

Discussion:
is now failing, and blocking the unstable channel cc
Minimal reproducer: Bisected to Relevant snippet of cc
Oh I see, the stdenv setup logic is wrong when stdenv's cc version doesn't match the bootstrap tools because it tries to use a nonexistent include dir. The following patch should fix it but rebuilds the world, is there a clever way we can avoid rebuilds?
The bootstrap files contain some version of llvm, we could make this an explicit part of the tools. More generally, the test here is quite strict: it builds all the way to with new bootstrap tools but using current stdenv structure. When there are significant changes being made to the bootstrap tools that require stdenv changes this test makes it almost impossible. We've previously temporarily disabled this test to make such changes (). <details<summaryExplicit versions patch</summary</deatils
Yeah, the next bootstrap tools will depend on so it's somewhat expected that the stdenv test fails. I missed that build when testing.
Change:
<ins> { lib , fetchFromGitHub , buildGoModule , gnumake }: buildGoModule { pname = "emacsclient-commands"; version = "unstable-2023-09-22"; src = fetchFromGitHub { owner = "szermatt"; repo = "emacsclient-commands"; rev = "8f5c8a877794ed51f8225036e36fd5ce272b17f3"; hash = "sha256-OlcB5VqWYdl0wz1y8nmG6Xgdf5IPOUQ31UG1TDxQAis="; }; vendorHash = "sha256-8oREed2Igz5UvUTDdOFwW5wQQy3H8Xj8epxo6gqnZFA="; buildInputs = [ gnumake ]; buildPhase = '' runHook preBuild DESTDIR=$out/ make install runHook postBuild ''; meta = with lib; { description = "A collection of small shell utilities that connect to a local Emacs server"; homepage = "https://github.com/szermatt/emacsclient-commands"; license = licenses.gpl2Only; maintainers = with maintainers; [ binarycat ]; }; } </ins>

Discussion:
Project description Metadata homepage URL: source URL: license: GPL-2.0 license platforms: probably linux, macos, windows; guessed from the fact that both Go and Emacs are available on these. Note: The project uses Go language and the building section is small: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
programs.feedbackd.enable = true; <del> # https://source.puri.sm/Librem5/phosh/-/issues/303 security.pam.services.phosh = { text = '' auth    requisite       pam_nologin.so auth    required        pam_succeed_if.so user != root quiet_success auth    required        pam_securetty.so auth    requisite       pam_nologin.so ''; }; </del> <ins> security.pam.services.phosh = {}; </ins> services.gnome.core-shell.enable = true; services.gnome.core-os-services.enable = true;

Discussion:
Describe the bug The phosh lockscreen will accept any pin. To Reproduce Steps to reproduce the behavior: phosh screen with 1 even if it isn't your pin! Expected behavior Probably use the numeric password of the user Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Solution The PAM configuration seems to be at fault. I can't PAM my way out of a paper bag, but I tried one attempt: Why ? Here's why: That doesn't explain the issue. Only a plausible fix. With this, only the user password is accepted. We should get someone who understand PAM to look at this. Metadata Ran on top of . Maintainer information:
Uh, so the problem is that does not exist, so there are no requirements enforced? Or what does our pam file for phosh look like? The better approach would likely be to add here:
Sorry, I probably misexplained a bit here: we're not using the manjaro pam bit at all. So I suspect those are not good at all. When using the manjaro bit verbatim, you just can't unlock! I guess adding to that list you linked to could do it too? If the other snippet is removed.
Ouch, that pam file is not testing for anything meaningful, so it shouldn't come as a surprise. Login works if you are not root. pamnologin is a PAM module that prevents users from logging into the system when /etc/nologin exists is designed to succeed or fail authentication based on characteristics of the account belonging to the user being authenticated. pamsecuretty is a PAM module that allows root logins only if the user is logging in on a "secure" tty, (Quoting from their individual manpages) Because we have no pam.d file.
Change:
, gtk4 , gst_all_1 , libadwaita <ins> , appstream-glib , libsoup </ins> }: stdenv.mkDerivation rec {

Discussion:
(init 0.4 version) cannot start, shows log and exit with code 1. Here is the full log: (): Gjs-CRITICAL : 10:24:13.181: JS ERROR: Error: Requiring Soup, version 2.4: Typelib file for namespace 'Soup', version '2.4' not found (): Gjs-CRITICAL : 10:24:13.181: Script /nix/store/x9fvn8b614lg6xmdc259q6cx9crbrqpx-clapper- threw an exception Steps to reproduce the behavior: the package. (nix-shell -p clapper) to start it. (clapper) shows error and exit with code 1. I checkout the package in nixpkgs: It seems missing a build deps & a runtime deps libsoup. Add them together to buildInputs fixes this issues. If the mantainer agrees, I can do a PR : ) Maintainer information:
works fine for me on my amd64 desktop, but I can reproduce your error on my Pinephone. Sounds good to me! :)
To try to reproduce this problem, I make these files to build-vm: It cannot start on the QEMU VM too. I'll make a PR right now.
Change:
}; fileSystems."/nix/store" = <del> { fsType = "unionfs-fuse"; device = "unionfs"; options = [ "allow_other" "cow" "nonempty" "chroot=/mnt-root" "max_files=32768" "hide_meta_files" "dirs=/nix/.rw-store=rw:/nix/.ro-store=ro" ]; </del> <ins> { fsType = "overlay"; device = "overlay"; options = [ "lowerdir=/nix/.ro-store" "upperdir=/nix/.rw-store/store" "workdir=/nix/.rw-store/work" ]; </ins> }; <del> boot.initrd.availableKernelModules = [ "squashfs" ]; </del> <ins> boot.initrd.availableKernelModules = [ "squashfs" "overlay" ]; </ins> <del> boot.initrd.kernelModules = [ "loop" ]; </del> <ins> boot.initrd.kernelModules = [ "loop" "overlay" ]; </ins> # Closures to be copied to the Nix store, namely the init # script and the top-level system configuration directory.

Discussion:
got it working with this for the AArch64 community box: Presumably the hackiness could be lowered by doing a thing like we already do for unionfs-fuse:
Change:
diff --git a/tools/gyp/pylib/gyp/xcode_emulation.py b/tools/gyp/pylib/gyp/xcode_emulation.py <del> index c002b11..eeb0400 100644 </del> <ins> index 407ead0..8bf64e7 100644 </ins> --- a/tools/gyp/pylib/gyp/xcode_emulation.py +++ b/tools/gyp/pylib/gyp/xcode_emulation.py @@ -446,10 +446,16 @@ class XcodeSettings(object):

Discussion:
All builds of fail. When I try to build nixpkgs/master locally, I get the same failure as Any ideas what might cause this?
I think the issue is that it's reaching out to the host Xcode and needs to be patched not to do that. I don't have time to look and although I know about darwin impurities a fair amount, know nothing about nodejs. Someone who actually uses it needs to step up and fix it properly. The fix will likely look like a patch that tells it not to reach out to Xcode and instead teaches it where to find the things it needs. Also relevant is a project is working on to present a fake Xcode to our , but I don't think that's ready yet.
For what it is worth. I have Xcode installed and if I add this line back in it builds for me:
That's weird. I took it out because I couldn't even find that line in the source, but I might have missed it somehow. Feel free to push it back in!
Change:
<del> From 5eb4d6a384753896d495b09d8651c48672ef234d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20Thalheim?= <joerg@thalheim.io> Date: Wed, 25 Nov 2020 11:26:49 +0100 Subject: [PATCH] replace git with normal python package MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Jörg Thalheim <joerg@thalheim.io> --- requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/requirements.txt b/requirements.txt index ef25aad..b4246a4 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,2 +1,2 @@ -git+https://github.com/Yubico/yubikey-manager.git +yubikey-manager ./py/qr -- 2.29.2 </del>

Discussion:
Describe the bug On current nixos-unstable, yubioath-desktop starts up, but does not detect a connected yubikey and spews error messages to the terminal. I believe this is related to and might be fixable by updating the package. To Reproduce Steps to reproduce the behavior: a yubikey (4 nano); set and rebuild (optional, I believe) Expected behavior Would expect the key to be discovered and silence on the terminal. Screenshots Additional context (none) Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: nixpkgs: `/nix/store/d7bsnyyw1wbmkv197krfd0fbaw1rqcpv-source Maintainer information:
Version 5.0.5 seems to include the fix and will probably be released soon. I'll update the package once it has made it to their release website.
Thank you! I could work around the issue by using: for now (this may break some of the things fixed in patches)
Looks like 5.0.5 is released:
tarballs haven't been published yet.
Change:
INSTALL_PATH="${placeholder "out"}/share/fzf-tab"; in stdenv.mkDerivation rec { pname = "zsh-fzf-tab"; <del> version = "unstable-2021-11-12"; </del> <ins> version = "unstable-2022-02-10"; </ins> src = fetchFromGitHub { owner = "Aloxaf"; repo = "fzf-tab"; <del> rev = "190500bf1de6a89416e2a74470d3b5cceab102ba"; sha256 = "1dipsy0s67fr47ig5559bcp1h5yn8rdjshhs8zsq7j8plvvh99qb"; </del> <ins> rev = "e8145d541a35d8a03df49fbbeefa50c4a0076bbf"; sha256 = "h/3XP/BiNnUgQI29gEBl6RFee77WDhFyvsnTi1eRbKg="; </ins> }; buildInputs = [ ncurses ];

Discussion:
crashes shell when tab completing a command with more than one group if and are set. Steps to reproduce the behavior: in Home Manager. in Home Manager. shell and type . starts completion. The crash does not occur if the plugin is loaded like The crash only occurs when from Nixpkgs is used. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- I just switched to flakes, and I'm not sure of the flake equivalent of .
It has been confirmed. It is caused by the compiled . I need some time to debug. Temporarily, you can run after loading fzf-tab(nixpkgs version)
The problem is caused by upstream. I create a vm of kali and bulid the which has the same issue.
Change:
sed -i '/pip>=/d' requirements/bootstrap.txt ''; <del> nativeBuildInputs = [ </del> <ins> build-system = [ </ins> installShellFiles flit-core ]; <del> propagatedBuildInputs = [ </del> <ins> dependencies = [ </ins> awscrt bcdoc botocore

Discussion:
Steps to reproduce the behavior: awscli2 New to NixOS, I ran and . Removing and reinstalling the package did not fix the issue. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hello Thank you for reporting the issue. Indeed, I have a PR to upgrade awscli2 to 2.15.29 whose the build is failing now after rebasing it with master: Looks like the issue could be caused by this python-updates PR merged into staging branch: (and then merged into master yesterday: ) Looks like could be the cause. I will take a look.
Indeed, used to check if the installed dependencies meets constraints does only supports simple version numbers (X.Y.Z). And version does not parse and the script fails ( is also not semver compliant, and using ).
I am also experiencing the same issue
Looks like upstream may be trying to avoid this version too for now, they made recently pinning it to . Overriding the package to use (and adding a substitution for 's version string and some test weirdness) seems to let it build -- maybe just worth doing that in your upgrade PR?
Thanks for your help. Indeed, looks like pinning python-dateutil to 2.8.2 is a resolution: Yes, I the fix in my upgrade PR.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
The build has just passed on Hydra:
Its arrived in . I think this can be closed now
Yes we can close now :)
Awesome, thank you for your help !
Change:
<ins> { lib, symlinkJoin, makeBinaryWrapper, testers, av1an-unwrapped, ffmpeg, python3Packages, libaom, svt-av1, rav1e, libvpx, x264, x265, libvmaf, withAom ? true, # AV1 reference encoder withSvtav1 ? false, # AV1 encoder/decoder (focused on speed and correctness) withRav1e ? false, # AV1 encoder (focused on speed and safety) withVpx ? true, # VP8 & VP9 de/encoding withX264 ? true, # H.264/AVC encoder withX265 ? true, # H.265/HEVC encoder withVmaf ? false, # Perceptual video quality assessment algorithm }: # av1an requires at least one encoder assert lib.assertMsg (lib.elem true [ withAom withSvtav1 withRav1e withVpx withX264 withX265 ]) "At least one encoder is required!"; symlinkJoin { name = "av1an-${av1an-unwrapped.version}"; paths = [ av1an-unwrapped ]; nativeBuildInputs = [ makeBinaryWrapper ]; postBuild = let runtimePrograms = [ (ffmpeg.override { inherit withVmaf; }) ] ++ lib.optional withAom libaom ++ lib.optional withSvtav1 svt-av1 ++ lib.optional withRav1e rav1e ++ lib.optional withVpx libvpx ++ lib.optional withX264 x264 ++ lib.optional withX265 x265 ++ lib.optional withVmaf libvmaf; in '' wrapProgram $out/bin/av1an  --prefix PATH : ${lib.makeBinPath runtimePrograms}  --prefix PYTHONPATH : ${python3Packages.makePythonPath [ python3Packages.vapoursynth ]} ''; passthru = { # TODO: uncomment when upstream actually bumps CARGO_PKG_VERSION #tests.version = testers.testVersion { #  package = av1an; #  inherit (av1an-unwrapped) version; #}; }; meta = { inherit (av1an-unwrapped.meta) description longDescription homepage changelog license maintainers mainProgram ; }; } </ins>

Discussion:
Project description Cross-platform command-line AV1 / VP9 / HEVC / H264 encoding framework with per scene quality encoding Metadata homepage URL: source URL: license: GPLv3 platforms: unix, linux, darwin, windows
Change:
config = mkIf cfg.enable { environment.systemPackages = [ pkgs.apparmor-utils ]; <ins> boot.kernelParams = [ "apparmor=1" "security=apparmor" ]; </ins> systemd.services.apparmor = let paths = concatMapStrings (s: " -I ${s}/etc/apparmor.d") ([ pkgs.apparmor-profiles ] ++ cfg.packages);

Discussion:
Upgrading to kernel 5.1.0 from breaks apparmor, preventing it from loading. Furthermore, this also breaks , requiring a kernel downgrade to (kernel 5.0.13) to fix this. The error is: I believe the main issue is from this line here: and should be sufficient to reproduce the problem, although apparmor was already implicitly enabled on my system. I believe it's because of lxd.
It can alternatively be reproduced with and . I've removed the second part as a workaround.
I can reproduce the apparmor issue (on unstable-small 19.09pre179342.), but I can keep rebuilding once apparmor.service fails. Not sure if I'm understanding that part right though...
Off the top of my head I'd guess that this is related to not being mounted; is it? (should be at ). I recently tweaked the ordering of the apparmor unit, so this could be fallout from that (EDIT: probably not).
Hm, from my testing it seems that the selinux lsm is selected by the kernel at boot instead of apparmor for whatever reason under 5.1. I do note that no longer explicitly sets the default boot parameter to . Can you check output? When apparmor is selected, you should see something like "AppArmor: AppArmor Filesystem Enabled"; if that is missing, look for mentions of selinux. Explicitly setting fixes the issue on my end; I'll push a patch to that effect.
I believe this has been fixed. Please reopen if the problem persists.
This is a problem again. Would somebody please re-open this issue?
Hmmm, this seems to be fixed by a reboot. Is there some way to say "reboot required" from ?
I just had the same issue and reboot indeed fixed it, thanks a lot
Just reproduced this by adding to . Making a reboot unnecessary would be even better :-) Either way the problem still exists and significantly impacts usability... any plans on addressing it?
Change:
./programs/qt5ct.nix ./programs/screen.nix ./programs/sedutil.nix <ins> ./programs/seahorse.nix </ins> ./programs/slock.nix ./programs/shadow.nix ./programs/shell.nix

Discussion:
Describe the bug Currently, the gnome3 module automatically adds the following to I know that is still experimental, and probably shouldn't be installed by default. Does GNOME3 document their distribution defaults anywhere? I think we could clean this up slightly. Note that if we remove anything from here it would be a good idea to conditionally add them based off the users . That way current users won't see these packages magically disappear from their machine. Or perhaps it's better document that in the release notes.
cc
If I recall correctly, we should be concerned about core and world:
Ahh, looks like there's a bit to do here. For example should be :wave:
I think it is just CI breakage after they removed , see
So after discussing briefly in irc, I guess we can implement profiles for gnome-world-packages gnome-games-packages And the module will continue to bring in , , and . In the future we can split that up so we can use flashback without gnome3. Then we can eliminate the lists in since that should be in the profiles where it's useful. One thing I'm unclear on is how to organize the profiles, and do they have options to enable?
Thinking about it more, the main benefit of profiles is that they would not need options. But if we want parts of the profiles to be disableable, we would need to have options for them anyway. Also with options, we get generated documentation for free. I am not sure that is a way to go an more. As for the subdivision, maybe it would make more sense to look on it from users’ perspective: Hard-core hacker wants a bare-bones GNOME Shell with minimum necessary services, not even file manager or terminal emulator – they already have favourite ones. Casual user might have some favourite apps but they are generally happy to use whatever comes with the desktop environment. Here we would ship the core apps. An organization such as a library might want a full desktop environment for their shared workstations, with programs for all possible purposes. But they probably have a sysadmin who wants to have a fine control over what gets installed on the workstations. For that reason, creating a profile that bundles all the world apps probably does not make sense.

Non-GNOME users who want to use GNOME apps probably do not want to use all GNOME apps either, so a core collection might not make sense for them. A parent wants to install various games on the children’s computer. This is kind of similar to the organization but here the collection is more useful. …
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
<del> --- old/source/Makefile	2014-04-14 13:00:22.331058910 +0000 +++ new/source/Makefile	2014-04-14 13:02:11.102204544 +0000 @@ -672,6 +672,7 @@ FREETYPE_LDFLAGS := $(shell $(PKGCONFIG) freetype2 --libs-only-L) $(shell $(PKGCONFIG) freetype2 --libs-only-l) SDL_INCLUDE := $(shell $(PKGCONFIG) sdl --cflags-only-I) +SDL_IMG_INCLUDE := $(shell $(PKGCONFIG) SDL_image --cflags-only-I) SDL_CFLAGS  := $(shell $(PKGCONFIG) sdl --cflags-only-other) SDL_LDFLAGS := $(shell $(PKGCONFIG) sdl --libs-only-L) $(shell $(PKGCONFIG) sdl --libs-only-l) @@ -694,7 +695,7 @@ endif DEFINES_L += $(PNG_CFLAGS) $(FREETYPE_CFLAGS) $(SDL_CFLAGS) -INCLUDES_L += $(PNG_INCLUDE) $(FREETYPE_INCLUDE) $(SDL_INCLUDE) +INCLUDES_L += $(PNG_INCLUDE) $(FREETYPE_INCLUDE) $(SDL_INCLUDE) $(SDL_IMG_INCLUDE) endif # TILES </del>

Discussion:
Here is the output from nixos-rebuild: I'm not sure if this is a known issue or not, but I made sure to upgrade as well and it is still failing.
Change:
<ins> { lib , stdenv , fetchFromGitHub , python3 }: let pname = "wtfis"; version = "0.5.1"; in python3.pkgs.buildPythonApplication { inherit pname version; src = fetchFromGitHub { owner = "pirxthepilot"; repo = "wtfis"; rev = "v${version}"; hash = "sha256-XoQ/iJTdZoekA5guxI8POG4NEhN8Up3OuIz344G75ao="; }; patches = [ # TODO: get rid of that newbie patch ./000-pyproject-remove-versions.diff ]; format = "pyproject"; propagatedBuildInputs = [ python3.pkgs.hatchling python3.pkgs.pydantic python3.pkgs.rich python3.pkgs.shodan python3.pkgs.python-dotenv ]; meta = { homepage = "https://github.com/pirxthepilot/wtfis"; description = "Passive hostname, domain and IP lookup tool for non-robots"; license = lib.licenses.mit; maintainers = [ lib.maintainers.AndersonTorres ]; }; } </ins>

Discussion:
Project description As stated by the developer: Metadata homepage URL: source URL: license: MIT platforms: unix, linux, darwin