jiebi/CodeConvo huggingface dataset:
Code change:
build Full logs: Errors happen when building for musl, dynamic. Alpine package: Nixpkgs package:
This can be fixed by a , but I'm not sure if we want this?

Related discussion:
text: "--with-app-defaults=$(out)/lib/X11/app-defaults" ] ++ lib.optional enableDecLocator "--enable-dec-locator"; <del> # Work around broken "plink.sh". NIX_LDFLAGS = "-lXmu -lXt -lICE -lX11 -lfontconfig"; </del> <ins> env = { # Work around broken "plink.sh". NIX_LDFLAGS = "-lXmu -lXt -lICE -lX11 -lfontconfig"; } // lib.optionalAttrs stdenv.hostPlatform.isMusl { # Various symbols missing without this define: TAB3, NLDLY, CRDLY, BSDLY, FFDLY, CBAUD NIX_CFLAGS_COMPILE = "-D_GNU_SOURCE"; }; </ins> # Hack to get xterm built with the feature of releasing a possible setgid of 'utmp', # decided by the sysadmin to allow the xterm reporting to /var/run/utmp
Code change:
I want to change a configuration variable to onlyoffice. Currently, the NixOS module adapts on the fly in the upstream configuration with a call. I'd like to make my own adaptation. For now it's not possible due to ExecStartPre being not declared as a list, but as a direct value.

Related discussion:
text: wantedBy = [ "multi-user.target" ]; serviceConfig = { ExecStart = "${cfg.package.fhs}/bin/onlyoffice-wrapper DocService/docservice /run/onlyoffice/config"; <del> ExecStartPre = onlyoffice-prestart; </del> <ins> ExecStartPre = [ onlyoffice-prestart ]; </ins> Group = "onlyoffice"; Restart = "always"; RuntimeDirectory = "onlyoffice";
Code change:
SpamAssassin generates and compiles C code from anti-spam rules. This currently fails because the generated code makes use of the function, which is not available during the rule compilation process. Steps to reproduce the behavior: the SpamAssassin service that sa-update.service fails with the error message: that, consequently, spamd.service will not function. Alternatively, the error can also be observed by invoking directly. sa-update.service succeeds <!-- 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.
A smoke-test that serves as a reproducer is available in .
In theory, this could be addressed by making libxcrypt available when compiling rules, but care must probably also be taken so that the dynamic linker can find it at rule run-time.
Rule compilation seems to complete without errors for the rule if we set . However, of course the resulting binary is not linked against libxcrypt then. I’m not sure when Spamassassin will generate code that actually calls functions from that library.

Related discussion:
text: - `services.lemmy.settings.federation` was removed in 0.17.0 and no longer has any effect. To enable federation, the hostname must be set in the configuration file and then federation must be enabled in the admin web UI. See the [release notes](https://github.com/LemmyNet/lemmy/blob/c32585b03429f0f76d1e4ff738786321a0a9df98/RELEASES.md#upgrade-instructions) for more details. <ins> - `spamassassin` no longer supports the `Hashcash` module. The module needs to be removed from the `loadplugin` list if it was copied over from the default `initPreConf` option. </ins> ## Other Notable Changes {#sec-release-23.11-notable-changes} - The Cinnamon module now enables XDG desktop integration by default. If you are experiencing collisions related to xdg-desktop-portal-gtk you can safely remove `xdg.portal.extraPortals = [ pkgs.xdg-desktop-portal-gtk ];` from your NixOS configuration.
Code change:
SpamAssassin generates and compiles C code from anti-spam rules. This currently fails because the generated code makes use of the function, which is not available during the rule compilation process. Steps to reproduce the behavior: the SpamAssassin service that sa-update.service fails with the error message: that, consequently, spamd.service will not function. Alternatively, the error can also be observed by invoking directly. sa-update.service succeeds <!-- 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.
A smoke-test that serves as a reproducer is available in .
In theory, this could be addressed by making libxcrypt available when compiling rules, but care must probably also be taken so that the dynamic linker can find it at rule run-time.
Rule compilation seems to complete without errors for the rule if we set . However, of course the resulting binary is not linked against libxcrypt then. I’m not sure when Spamassassin will generate code that actually calls functions from that library.

Related discussion:
text: loadplugin Mail::SpamAssassin::Plugin::Check #loadplugin Mail::SpamAssassin::Plugin::DCC loadplugin Mail::SpamAssassin::Plugin::DKIM <ins> loadplugin Mail::SpamAssassin::Plugin::DMARC </ins> loadplugin Mail::SpamAssassin::Plugin::DNSEval loadplugin Mail::SpamAssassin::Plugin::FreeMail <del> loadplugin Mail::SpamAssassin::Plugin::Hashcash </del> loadplugin Mail::SpamAssassin::Plugin::HeaderEval loadplugin Mail::SpamAssassin::Plugin::HTMLEval loadplugin Mail::SpamAssassin::Plugin::HTTPSMismatch
Code change:
SpamAssassin generates and compiles C code from anti-spam rules. This currently fails because the generated code makes use of the function, which is not available during the rule compilation process. Steps to reproduce the behavior: the SpamAssassin service that sa-update.service fails with the error message: that, consequently, spamd.service will not function. Alternatively, the error can also be observed by invoking directly. sa-update.service succeeds <!-- 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.
A smoke-test that serves as a reproducer is available in .
In theory, this could be addressed by making libxcrypt available when compiling rules, but care must probably also be taken so that the dynamic linker can find it at rule run-time.
Rule compilation seems to complete without errors for the rule if we set . However, of course the resulting binary is not linked against libxcrypt then. I’m not sure when Spamassassin will generate code that actually calls functions from that library.

Related discussion:
text: <ins> diff -ru orig/t/sa_compile.t new/t/sa_compile.t --- orig/t/sa_compile.t	2022-12-14 06:03:26.000000000 +0000 +++ new/t/sa_compile.t	2023-06-25 12:30:39.735577152 +0000 @@ -40,7 +40,7 @@ # we now have an "installed" version we can run sa-compile with.  Ensure # sarun() will use it appropriately -$scr = "$instdir/$temp_binpath/spamassassin"; +$scr = "$perl_cmd -T $instdir/$temp_binpath/spamassassin"; $scr_localrules_args = $scr_cf_args = "";      # use the default rules dir, from our "install" &set_rules(' @@ -86,8 +86,8 @@ # ------------------------------------------------------------------- rmtree( glob "~/.spamassassin/sa-compile.cache". { safe => 1 }); # reset test -system_or_die "TMP=$instdir TMPDIR=$instdir $instdir/$temp_binpath/sa-compile --quiet -p $cwd/$workdir/user.cf --keep-tmps -D 2>$instdir/sa-compile.debug";  # --debug -$scr = "$instdir/$temp_binpath/spamassassin"; +system_or_die "TMP=$instdir TMPDIR=$instdir $perl_cmd -T $instdir/$temp_binpath/sa-compile --quiet -p $cwd/$workdir/user.cf --keep-tmps -D 2>$instdir/sa-compile.debug";  # --debug +$scr = "$perl_cmd -T $instdir/$temp_binpath/spamassassin"; $scr_localrules_args = $scr_cf_args = "";      # use the default rules dir, from our "install" %patterns = ( </ins>
Code change:
SpamAssassin generates and compiles C code from anti-spam rules. This currently fails because the generated code makes use of the function, which is not available during the rule compilation process. Steps to reproduce the behavior: the SpamAssassin service that sa-update.service fails with the error message: that, consequently, spamd.service will not function. Alternatively, the error can also be observed by invoking directly. sa-update.service succeeds <!-- 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.
A smoke-test that serves as a reproducer is available in .
In theory, this could be addressed by making libxcrypt available when compiling rules, but care must probably also be taken so that the dynamic linker can find it at rule run-time.
Rule compilation seems to complete without errors for the rule if we set . However, of course the resulting binary is not linked against libxcrypt then. I’m not sure when Spamassassin will generate code that actually calls functions from that library.

Related discussion:
text: <ins> diff -ru orig/t/SATest.pm new/t/SATest.pm --- orig/t/SATest.pm	2023-06-25 11:26:27.663204415 +0000 +++ new/t/SATest.pm	2023-06-25 11:34:08.902174669 +0000 @@ -65,9 +65,12 @@ # Clean PATH so taint doesn't complain if (!$RUNNING_ON_WINDOWS) { -    $ENV{'PATH'} = '/bin:/usr/bin:/usr/local/bin'; +    # untaint PATH +    $ENV{'PATH'} =~ /^(.+)$/; +    $ENV{'PATH'} = $1; +    # $ENV{'PATH'} = '/bin:/usr/bin:/usr/local/bin'; # Remove tainted envs, at least ENV used in FreeBSD -    delete @ENV{qw(IFS CDPATH ENV BASH_ENV)}; +    # delete @ENV{qw(IFS CDPATH ENV BASH_ENV)}; } else { # Windows might need non-system directories in PATH to run a Perl installation # The best we can do is clean out obviously bad stuff such as relative paths or .. </ins>
Code change:
SpamAssassin generates and compiles C code from anti-spam rules. This currently fails because the generated code makes use of the function, which is not available during the rule compilation process. Steps to reproduce the behavior: the SpamAssassin service that sa-update.service fails with the error message: that, consequently, spamd.service will not function. Alternatively, the error can also be observed by invoking directly. sa-update.service succeeds <!-- 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.
A smoke-test that serves as a reproducer is available in .
In theory, this could be addressed by making libxcrypt available when compiling rules, but care must probably also be taken so that the dynamic linker can find it at rule run-time.
Rule compilation seems to complete without errors for the rule if we set . However, of course the resulting binary is not linked against libxcrypt then. I’m not sure when Spamassassin will generate code that actually calls functions from that library.

Related discussion:
text: }; }; <ins> MailDMARC = buildPerlPackage { pname = "Mail-DMARC"; version = "1.20230215"; src = fetchurl { url = "mirror://cpan/authors/id/M/MB/MBRADSHAW/Mail-DMARC-1.20230215.tar.gz"; hash = "sha256-V9z1R1nLkkSOVukUE0D2E0QnTFjZ3WWqkKqczw5+uQM="; }; buildInputs = [ ExtUtilsMakeMaker FileShareDirInstall ]; doCheck = false;  # uses actual DNS at runtime checkInputs = [ XMLSAX XMLValidatorSchema TestException TestFileShareDir TestMore TestOutput ]; propagatedBuildInputs = [ ConfigTiny DBDSQLite DBIxSimple EmailMIME EmailSender Encode FileShareDir GetoptLong IOCompress IO IOSocketSSL NetDNS NetIDNEncode NetIP NetSSLeay RegexpCommon Socket6 SysSyslog URI XMLLibXML ]; meta = { description = "Perl implementation of DMARC"; homepage = "https://github.com/msimerson/mail-dmarc"; license = with lib.licenses; [ artistic1 gpl1Plus ]; }; }; </ins> MailMaildir = buildPerlPackage { version = "1.0.0"; pname = "Mail-Maildir";
Code change:
SpamAssassin generates and compiles C code from anti-spam rules. This currently fails because the generated code makes use of the function, which is not available during the rule compilation process. Steps to reproduce the behavior: the SpamAssassin service that sa-update.service fails with the error message: that, consequently, spamd.service will not function. Alternatively, the error can also be observed by invoking directly. sa-update.service succeeds <!-- 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.
A smoke-test that serves as a reproducer is available in .
In theory, this could be addressed by making libxcrypt available when compiling rules, but care must probably also be taken so that the dynamic linker can find it at rule run-time.
Rule compilation seems to complete without errors for the rule if we set . However, of course the resulting binary is not linked against libxcrypt then. I’m not sure when Spamassassin will generate code that actually calls functions from that library.

Related discussion:
text: }; }; <ins> NetLibIDN2 = buildPerlModule { pname = "Net-LibIDN2"; version = "1.02"; src = fetchurl { url = "mirror://cpan/authors/id/T/TH/THOR/Net-LibIDN2-1.02.tar.gz"; hash = "sha256-0fMK/GrPplQbAMCafkx059jkuknjJ3wLvEGuNcE5DQc="; }; propagatedBuildInputs = [ pkgs.libidn2 ]; meta = { description = "Perl bindings for GNU Libidn2"; homepage = "https://github.com/gnuthor/Net--LibIDN2"; license = with lib.licenses; [ artistic1 gpl1Plus ]; }; }; </ins> NetNetmask = buildPerlPackage { pname = "Net-Netmask"; version = "2.0001";
Code change:
Building uses more () threads than it should (i.e. 2 if / ). Steps to reproduce the behavior: as the build will use way more than 2 cores. Build should honour properly. This was with . This does not in fact use just 1 thread. :smilingfacewith_tear:. ! Happens on master () and 22.11.
I don't have any time planned to fix this but if you figure it out please send a PR.

Related discussion:
text: propagatedBuildInputs = [ six protobuf ] ++ lib.optionals (isPy27) [ enum34 futures ]; <del> preBuild = lib.optionalString stdenv.isDarwin "unset AR"; </del> <ins> preBuild = '' export GRPC_PYTHON_BUILD_EXT_COMPILER_JOBS="$NIX_BUILD_CORES" if [ -z "$enableParallelBuilding" ]; then GRPC_PYTHON_BUILD_EXT_COMPILER_JOBS=1 fi '' + lib.optionalString stdenv.isDarwin '' unset AR ''; </ins> GRPC_BUILD_WITH_BORING_SSL_ASM = ""; GRPC_PYTHON_BUILD_SYSTEM_OPENSSL = 1;
Code change:
Building uses more () threads than it should (i.e. 2 if / ). Steps to reproduce the behavior: as the build will use way more than 2 cores. Build should honour properly. This was with . This does not in fact use just 1 thread. :smilingfacewith_tear:. ! Happens on master () and 22.11.
I don't have any time planned to fix this but if you figure it out please send a PR.

Related discussion:
text: # does not contain any tests doCheck = false; <ins> enableParallelBuilding = true; </ins> pythonImportsCheck = [ "grpc" ]; meta = with lib; {
Code change:
According to documentation of the app: there's a dozen dependencies we don't explicitly have a dependency on, so there's multitude of bugs that might appear depending on what's on $PATH.
Do we need a new maintainer of to move this issue forward?
We should pull the package from NixOS core...absolutely no reason to have such a bloated less ship by default.

Related discussion:
text: <del> { lib, stdenv, fetchFromGitHub, makeWrapper, perl, procps, file, gnused, bash, binutils }: </del> <ins> { lib , stdenv , fetchFromGitHub , makeWrapper , perl , procps , bash # shell referenced dependencies , resholve , binutils-unwrapped , file , gnugrep , coreutils , gnused , gnutar , iconv , ncurses }: </ins> stdenv.mkDerivation rec { pname = "lesspipe";
Code change:
According to documentation of the app: there's a dozen dependencies we don't explicitly have a dependency on, so there's multitude of bugs that might appear depending on what's on $PATH.
Do we need a new maintainer of to move this issue forward?
We should pull the package from NixOS core...absolutely no reason to have such a bloated less ship by default.

Related discussion:
text: installFlags = [ "DESTDIR=$(out)" ]; postInstall = '' <del> for f in lesspipe.sh lesscomplete; do wrapProgram "$out/bin/$f" --prefix-each PATH : "${lib.makeBinPath [ binutils file gnused procps ]}" done </del> <ins> # resholve doesn't see strings in an array definition substituteInPlace $out/bin/lesspipe.sh --replace 'nodash strings' "nodash ${binutils-unwrapped}/bin/strings" ${resholve.phraseSolution "lesspipe.sh" { scripts = [ "bin/lesspipe.sh" ]; interpreter = "${bash}/bin/bash"; inputs = [ coreutils file gnugrep gnused gnutar iconv procps ncurses ]; keep = [ "$prog" "$c1" "$c2" "$c3" "$c4" "$c5" "$cmd" "$colorizer" "$HOME" ]; fake = { # script guards usage behind has_cmd test function, it's safe to leave these external and optional external = [ "cpio" "isoinfo" "cabextract" "bsdtar" "rpm2cpio" "bsdtar" "unzip" "ar" "unrar" "rar" "7zr" "7za" "isoinfo" "gzip" "bzip2" "lzip" "lzma" "xz" "brotli" "compress" "zstd" "lz4" "archive_color" "bat" "batcat" "pygmentize" "source-highlight" "vimcolor" "code2color" "w3m" "lynx" "elinks" "html2text" "dtc" "pdftotext" "pdftohtml" "pdfinfo" "ps2ascii" "procyon" "ccze" "mdcat" "pandoc" "docx2txt" "libreoffice" "pptx2md" "mdcat" "xlscat" "odt2txt" "wvText" "antiword" "catdoc" "broken_catppt" "sxw2txt" "groff" "mandoc" "unrtf" "dvi2tty" "pod2text" "perldoc" "h5dump" "ncdump" "matdump" "djvutxt" "openssl" "gpg" "plistutil" "plutil" "id3v2" "csvlook" "jq" "zlib-flate" "lessfilter" ] ++ lib.optional stdenv.isDarwin [ # resholve only identifies this on darwin # call site is gaurded by || so it's safe to leave dynamic "locale" ]; builtin = [ "setopt" ]; }; execer = [ "cannot:${iconv}/bin/iconv" ]; }} ${resholve.phraseSolution "lesscomplete" { scripts = [ "bin/lesscomplete" ]; interpreter = "${bash}/bin/bash"; inputs = [ coreutils file gnugrep gnused gnutar ]; keep = [ "$prog" "$c1" "$c2" "$c3" "$c4" "$c5" "$cmd" ]; fake = { # script guards usage behind has_cmd test function, it's safe to leave these external and optional external = [ "cpio" "isoinfo" "cabextract" "bsdtar" "rpm2cpio" "bsdtar" "unzip" "ar" "unrar" "rar" "7zr" "7za" "isoinfo" "gzip" "bzip2" "lzip" "lzma" "xz" "brotli" "compress" "zstd" "lz4" ]; builtin = [ "setopt" ]; }; }} </ins> ''; meta = with lib; {
Code change:
According to documentation of the app: there's a dozen dependencies we don't explicitly have a dependency on, so there's multitude of bugs that might appear depending on what's on $PATH.
Do we need a new maintainer of to move this issue forward?
We should pull the package from NixOS core...absolutely no reason to have such a bloated less ship by default.

Related discussion:
text: <del> { lib, stdenv, fetchFromGitHub, makeWrapper, perl, procps, file, gnused, bash }: </del> <ins> { lib, stdenv, fetchFromGitHub, makeWrapper, perl, procps, file, gnused, bash, binutils }: </ins> stdenv.mkDerivation rec { pname = "lesspipe";
Code change:
According to documentation of the app: there's a dozen dependencies we don't explicitly have a dependency on, so there's multitude of bugs that might appear depending on what's on $PATH.
Do we need a new maintainer of to move this issue forward?
We should pull the package from NixOS core...absolutely no reason to have such a bloated less ship by default.

Related discussion:
text: postInstall = '' for f in lesspipe.sh lesscomplete; do <del> wrapProgram "$out/bin/$f" --prefix-each PATH : "${lib.makeBinPath [ file gnused procps ]}" </del> <ins> wrapProgram "$out/bin/$f" --prefix-each PATH : "${lib.makeBinPath [ binutils file gnused procps ]}" </ins> done '';
Code change:
LibreSSL 3.4 is no longer supported upstream. It became unsupported on October 14th 2022, one year after . At the time of writing, 3.5 and 3.6 are both supported. that fixes a serious vulnerability: I suspect (but haven’t verified) that this vulnerability is present in LibreSSL 3.4. It is time to remove it from Nixpkgs. However, there are some packages that still depend on it. all depend on . I tried building against and , but both fail. I don’t see any packages that depend on , so I think we could remove the older versions, if we can first update FoundationDB to a version that is compatible with a more recent LibreSSL release. Maybe will be sufficient for this. Alternatively, we might patch FoundationDB. The compilation errors are about an incomplete type for which only a forward declaration is known. I haven’t looked into it deeply but it may be easy to fix. as the maintainers of , what are your thoughts on this? This has been addressed by . <details<summaryOriginal comment</summaryThe other package that explicitly depends on LibreSSL 3.4 is . This is a proprietary package so I couldn’t test if it is compatible with a more recent LibreSSL release, it might actually be. as the maintainers of , could you try and see if it is compatible with a newer LibreSSL release? </details
The x400Address issue that was patched recently is present in LibreSSL 3.4. The fix is very small and applies to all older versions that have it, so it might be an option [patch it][1] while you sort out the other issues. If you could share build logs for the foundationdb issues I can take a look if you want. [1]:
You can drop this. uses their bundled OpenSSL and drops the dependency since it's incompatible with even this LibreSSL version. It's about to merge.
all of darwin depends on 34 at the moment. You've pinned to 3.4, do you know if by any chance we can upgrade to 3.5 ? maybe ?
I'm quite sure we can't. My history with that package is and . happened, because someone did . iirc happened, because this package depends on ancient long unsupported openssl APIs that weren't part of anymore.
Small rectification, after a bit more testing, it doesn't appear to be all of darwin that is impacted by that change. So perhaps we don't need to put too much effort into this. I'm still trying to figure out the impact.
I’m working on a fix for , which drops the dependency on from by unconditionally dropping Unbound from the build (instead of only on aarch64-darwin). Apple doesn’t even include Unbound in macOS anymore, and it’s not present in newer source releases. That should remove as a blocker for dropping LibreSSL 3.4.

Related discussion:
text: }; inherit (callPackages ../development/libraries/libressl { }) <del> libressl_3_4 </del> libressl_3_6 libressl_3_7;
Code change:
I wanted to setup unbound on a server. I did have this configuration: I then manually created the file using in the folder as it did not automagically create one. The folder was set to 0777 permissions and the key to 0666. I checked then the systemd status: All looked fine. Port 5335 also opened on the firewall. Basically running PiHole container there that should call unbound for recursive resolution. As systemd showed unbound running, I tried to do a query but it errored out: Interestingly I run unbound on another server. On the other server I did not set the as it does not wipe everything that's not explicitely saved (see ). I thought I would need the on this setup, as everything gets wiped on reboot that is not explicitely set to save. After removing the option from the configuration, unbound works as expected. So there are two problem with the option: does not get automagically created don't work system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:

Related discussion:
text: LockPersonality = true; RestrictSUIDSGID = true; <ins> ReadWritePaths = [ cfg.stateDir ]; </ins> Restart = "on-failure"; RestartSec = "5s"; };
Code change:
p7zip source is gone try to build without substituters cc
What commit are you having the issue from? it works for me at
Current master, that is sets to . There is no such tag at
Maybe the fork cleared the tags by force pushing?
Hmm, I wonder if all the changes got merged into with the fork then rebasing and force-pushing…
Yeah, looks like it. A bunch of jinfeihan57's commits are now in the commit history I'll change it to point back to p7zip-project's copy now

Related discussion:
text: rm 7z 7z.so ln -s ${p7zip}/bin/7z 7z <del> ln -s ${p7zip}/lib/p7zip/7z.so 7z.so </del> <ins> ln -s ${lib.getLib p7zip}/lib/p7zip/7z.so 7z.so </ins> popd '';