jiebi/CodeConvo huggingface dataset:
Code change:
./scripts/light-scrubber.sh ''; <ins> postInstall = '' mkdir -p $doc/share/doc/shogun/examples mv $out/share/shogun/examples/cpp $doc/share/doc/shogun/examples cp ../examples/undocumented/libshogun/*.cpp $doc/share/doc/shogun/examples/cpp rm -r $out/share ''; </ins> meta = with lib; { description = "A toolbox which offers a wide range of efficient and unified machine learning methods"; homepage = "http://shogun-toolbox.org/"; license = if withSvmLight then licenses.unfree else licenses.gpl3Plus; <del> maintainers = with maintainers; [ edwtjo ]; </del> <ins> maintainers = with maintainers; [ edwtjo smancill ]; </ins> }; }

Related discussion:
text: shogun fails to build since the eigen 3.4.0 bump: The package is a likely candidate for removal. Upstream is unresponsive and development has halted. Removed from debian: Removed from fedora: Blocking vcpkg update: Please run and paste the result. Maintainer information:
I think you were the last one to modify this package, so please speak up if you need it. Also pinging Last call - if no one responds within the next week, I'll open a PR to remove this package.
Yes, I was working on making it build on Darwin and adding it as a Python 3 module. Well, I did, but I didn't feel motivated to create a PR. As you comment, upstream has been inactive for almost a year, the latest release is several years old, and it becomes harder and harder to make it work, and the patches would start to accumulate. To make it work on Darwin we need two upstream patches that fix the build with newer compiler versions. In the current derivation, the Python interface is not built because the CMake flag is not the right one. When enabled, Swig 3 is used to generate the Python interface, but Swig 3 doesn't support Python 3.8+ (and with Swig 4 just fails). It can be fixed with a patch, that feels more like a hack, intercepting the Makefile build, so I am not happy with it: Another small patch is needed to fix the deprecated . Also, I wasn't happy that adding it as a Python module will recompile the entire library again, which takes too much time IMO. I haven't checked if it is possible to build with Eigen 3.4 because it takes forever to compile. It could probably work on the development version. Note that the development version doesn't support Eigen 3.4 because of this, but it may work: But there is no such limitation on the 6.1.4 release, which probably means it would require another patch to fix the code, if somebody figures out. So, I'd argue that the package is too old now, and the derivation has too many issues, and it's too much of a hassle to maintain it, so it's probably better to just remove it.
I decided to sit and take a look at the error, and I actually fixed it.
Code change:
./scripts/light-scrubber.sh ''; <ins> postInstall = '' mkdir -p $doc/share/doc/shogun/examples mv $out/share/shogun/examples/cpp $doc/share/doc/shogun/examples cp ../examples/undocumented/libshogun/*.cpp $doc/share/doc/shogun/examples/cpp rm -r $out/share ''; </ins> meta = with lib; { description = "A toolbox which offers a wide range of efficient and unified machine learning methods"; homepage = "http://shogun-toolbox.org/"; license = if withSvmLight then licenses.unfree else licenses.gpl3Plus; <del> maintainers = with maintainers; [ edwtjo ]; </del> <ins> maintainers = with maintainers; [ edwtjo smancill ]; </ins> }; }

Related discussion:
text: I don't really use Eigen but the patch makes sense. So, I can send a PR to keep this package on the repo for another cycle at least. I mean, I already did all of the work and it builds. Other distros end up removing it because nobody cares to maintain it.
Nice! Thanks for looking into it. Like you said, if you've already done the work to get it working I don't see why not. If it's too much work to keep it working in the future we can always revisit this and drop it.
Code change:
<ins> --- old/build/pkgs/python3/spkg-install	2017-07-21 14:10:00.000000000 -0500 +++ new/build/pkgs/python3/spkg-install	2017-10-15 13:11:17.769261404 -0500 @@ -22,6 +22,9 @@ cd src +LDFLAGS="-lcrypt $LDFLAGS" +export LDFLAGS + if [ "$SAGE_DEBUG" = "yes" ]; then echo "Building Python with pydebug" PYTHON_CONFIGURE="$PYTHON_CONFIGURE --with-pydebug" </ins>

Related discussion:
text: Since Sage is huge and complicated, I figured I would make this issue to collaboratively track progress and share branches. One big issue is that Sage 7 , instead they use some with scant documentation . has the correct SHA256 for Sage 7.6 and updates a patch file. It currently fails when Sage tries to build . Some nice things to do for the future: ) cc:
thanks for picking this up
Me myself being a miserable loser who has failed to update Sage in the past, I hope you succeed… My attempt hit the following wall. It is unbearably slow to let Sage build everything, but when I had convinced it to use the system versions of majority of dependencies it began to complain cryptically about their interaction in some case.
Can you elaborate? Do you have a branch that has that work? Also, to be clear: I probably don't have the skills or time to upgrade Sage by myself, I was hoping that if we shared our knowledge and de-duplicated efforts we might be able to get closer together
I think it was 6-dot-something; it required a metric ton of adding options to the packages in NixPkgs (I have pushed that all to master long ago), and the Sage tricks are most likely too version-specific. It was long enough ago that I have since abandoned and lost the changes.
In case anybody in here is still waiting for this: I got sage to compile and run. I'm currently trying to minimize the dependencies and check that everything is working correctly (there is one doctest failure, but it was mentioned multiple times in the mailing list and apperas to be harmles -- just a timeout). I'll probably make a PR in the next couple of days.
Code change:
<ins> --- old/build/pkgs/python3/spkg-install	2017-07-21 14:10:00.000000000 -0500 +++ new/build/pkgs/python3/spkg-install	2017-10-15 13:11:17.769261404 -0500 @@ -22,6 +22,9 @@ cd src +LDFLAGS="-lcrypt $LDFLAGS" +export LDFLAGS + if [ "$SAGE_DEBUG" = "yes" ]; then echo "Building Python with pydebug" PYTHON_CONFIGURE="$PYTHON_CONFIGURE --with-pydebug" </ins>

Related discussion:
text: Sage needs texlive-core-2014, which is deprecated. Run with modern nixpkgs (i.e. from git) System: NixOS: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version:
Code change:
# }); libnix = dontCheck super.libnix; <del> # https://github.com/jmillikin/chell/issues/1 chell = super.chell.override { patience = self.patience_0_1_1; }; </del> # The test suite tries to mess with ALSA, which doesn't work in the build sandbox. xmobar = dontCheck super.xmobar;

Related discussion:
text: The Haskell package chell does not build due to missing dependency . I think this the culprit: Try to get a nix-shell with purescript and nixpgks pinned to . Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(stefan): nixpkgs: (Note that this fails with a pinned nixpkg, see above.)
Code change:
hash = "sha256-3fax57oaJvOgbTDPCiiUdtsfAGhICfPkuMihawq06SA="; }; <del> outputs = [ "out" "dev" ]; </del> <ins> outputs = [ "out" "dev" ]; </ins> strictDeps = true; nativeBuildInputs = [ cmake ninja pkg-config ]; buildInputs = [ libnice openssl

Related discussion:
text: HTTP Toolkit is an open-source tool for debugging, testing and building with HTTP(S) on Windows, Linux & Mac. Metadata homepage URL: source URL: license: AGPL v3.0 platforms: linux, darwin
Sorry, wasn't able to get it working. The httptoolkit-server is the difficult part. I tried building from source, however one of the dependencies tries to npm install more stuff in prebuild, so it wasn't building properly. I tried packaging the prebuilt binary but it's trying to do some auto updating and also package node with itself. I could have patched this when building from source, however the prebuilt one is minified & obfuscated so I couldn't do that.
Have you a branch to continue the work ?
+1
I've started a small bounty of 20$ on this: It's not much but it would be great to have this tool on nix!
I made another attempt at packaging this and I'm pretty close to getting httptoolkit-server to compile from source. This should help with patching out stuff, since we can do it before it gets obfuscated.
if anyone needs to run this on nix the appimage provided by HttpToolkit works pretty well on nix with no extra dependencies. See and then Would still be great to have this as a nix package though.
Hey thanks for adding this! You can claim the gitpay bounty here: (I've tried to find your email to invite you but didn't have much luck) or email me at
Sent you an email,
Code change:
rm $out/bin/slack makeWrapper $out/lib/slack/slack $out/bin/slack  --prefix XDG_DATA_DIRS : $GSETTINGS_SCHEMAS_PATH  <del> --prefix PATH : ${xdg-utils}/bin </del> <ins> --prefix PATH : ${lib.makeBinPath [xdg-utils]} </ins> # Fix the desktop link substituteInPlace $out/share/applications/slack.desktop 

Related discussion:
text: Describe the bug Starting slack doesn't show the window in 8 out of 10 runs To Reproduce Steps to reproduce the behavior: Expected behavior Slack window should open Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata system: host os: multi-user?: sandbox: version: channels(ymatsiuk): channels(root): nixpkgs: Maintainer information:
Code change:
webSettingsJSON = pkgs.writeText "settings.json" (builtins.toJSON webSettings); # TODO: Should this be RFC42-ised so that users can set additional options without modifying the module? <del> mtaConfig = pkgs.writeText "mailman-postfix.cfg" '' </del> <ins> postfixMtaConfig = pkgs.writeText "mailman-postfix.cfg" '' </ins> [postfix] postmap_command: ${pkgs.postfix}/bin/postmap transport_file_type: hash

Related discussion:
text: Describe the bug Mailman module in NixOS requires postfix enabled and has no way to configure Mailman to work with other MTAs supported by both NixOS and mailman upstream. To Reproduce Steps to reproduce the behavior: postfix mailman the evaluation with an assertion Expected behavior The Mailman module allows to select an MTA of choice (or even adapts to the currently enabled MTA) Screenshots n/a Additional context Notify maintainers cc Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(vika): nixpkgs: Maintainer information:
It looks like exim's configuration should be RFC42-ised first if we want to inject Mailman-related settings into Exim config, which is a requirement (Mailman requires a custom Exim router and transport).
Yes, the module is currently quite opinionated. If you're willing to contribute exim support that's great.
I see how I could make it work, but the first version of it will require manual editing of Exim's config files (because RFC42-ising Exim will be a pain, even though I have some drafts on how to translate Nix into the syntax that's required), and I'm not sure if it will be merge-worthy enough :3
Exim config is complicated enough as is, I'm not sure adding an intermediate layer from nix will help that much. I also don't really see this integrating well with existing or other exim config. I'm honestly kind of surprised this works for postfix.
Code change:
/nixos/modules/services/networking/babeld.nix @mweinelt /nixos/modules/services/networking/kea.nix @mweinelt /nixos/modules/services/networking/knot.nix @mweinelt <ins> nixos/modules/services/networking/networkmanager.nix @Janik-Haag </ins> /nixos/modules/services/monitoring/prometheus/exporters/kea.nix @mweinelt /nixos/tests/babeld.nix @mweinelt /nixos/tests/kea.nix @mweinelt /nixos/tests/knot.nix @mweinelt <ins> /nixos/tests/networking/* @Janik-Haag </ins> # Web servers /doc/packages/nginx.section.md @raitobezarius

Related discussion:
text: Describe the bug NetworkManager is a particularly important component and we don't have any tests for it that could block a channel advance. In particular, a change can happen on nixos-unstable leaving users without functioning networking, and while rollbacks are possible it isn't an excuse to allow that to reach production systems. NixOS doesn't produce either. Manual testing is also cumbersome if we want to make a new stable release. Upstream NetworkManager does have some integration testing but obviously not useful to us. I think to start, if we at least had a test that verifies the services start without issues would be great.
Agreed. While developing tests for the multipath TCP module I was surprised to see no networkmanager module. I had some difficulties with the nixos test infrastructure at first because the test infra will by default install a slirp interface () and it messed up the interface naming. Like I would clear but interfaces would still be named starting from instead of . Just thought I would mention it in case the brave soul writing the test is interested in multihoming. (but that's more a concern I have with the test infra).
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
Bleh.
I marked this as stale due to inactivity. &rarr;
consequences of our inactions
Code change:
<ins> diff --git a/tests/test_climat2.py b/tests/test_climat2.py index cede642..2d5ad77 100644 --- a/tests/test_climat2.py +++ b/tests/test_climat2.py @@ -10,12 +10,7 @@ import glob from libmat2 import images, parser_factory -mat2_binary = ['./mat2'] - -if 'MAT2_GLOBAL_PATH_TESTSUITE' in os.environ: -    # Debian runs tests after installing the package -    # https://0xacab.org/jvoisin/mat2/issues/16#note_153878 -    mat2_binary = ['/usr/bin/env', 'mat2'] +mat2_binary = [os.environ['out'] + '/bin/mat2'] class TestHelp(unittest.TestCase): </ins>

Related discussion:
text: Project description Metadata proposed package name: homepage source URL: license: platforms: probably portable to all platforms which Nix supports. requires python3, exiftool, gobject introspection
Code change:
if installed_version < available_version: print("updating systemd-boot from %s to %s" % (installed_version, available_version)) <del> subprocess.check_call(["@systemd@/bin/bootctl", "--esp-path=@efiSysMountPoint@", "update"]) </del> <ins> subprocess.check_call(["@systemd@/bin/bootctl", "--esp-path=@efiSysMountPoint@"] + bootctl_flags + ["update"]) </ins> os.makedirs("@efiSysMountPoint@/efi/nixos", exist_ok=True) os.makedirs("@efiSysMountPoint@/loader/entries", exist_ok=True)

Related discussion:
text: During systemd-boot update step attempts to touch EFI variables, even when is set to . Steps to reproduce the behavior: NixOS 21.05 with systemd-boot and to NixOS 21.11 () switch fails with: An error is just an indication of update trying to touch EFI variables. (I have EFI vars touching disabled on that system because of some unrelated firmware breakage) Manually running properly finishes, further switches work fine. systemd-boot update should not touch EFI variables during upgrade. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Maintainer information:
I had a similar issue which I fixed by running "sudo nixos-rebuild --install-bootloader switch"
The fix for this got reverted in
Code change:
nativeBuildInputs = [ cmake nasm ]; buildInputs = [ <del> gtk2 glib ffmpeg_4 alsa-lib libmad libogg libvorbis glew libpulseaudio udev </del> <ins> alsa-lib ffmpeg_6 glew glib gtk2 libmad libogg libpulseaudio libvorbis udev xorg.libXtst </ins> ]; cmakeFlags = [

Related discussion:
text: Describe the bug The menu icon for Stepmania is missing. To Reproduce Steps to reproduce the behavior: to find it in the Applications menu. Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I marked this as stale due to inactivity. &rarr;
Code change:
owner = "maxbachmann"; repo = "RapidFuzz"; rev = "refs/tags/v${version}"; <del> hash = "sha256-a83Vww9dEh0nNylnZwCm6PJYmfKvw5RnMLerfKfN1dY="; </del> <ins> hash = "sha256-hx8DNFxzD41tvxcKaSqqKkxJMlcrxAaihulUdkzyOt0="; </ins> }; nativeBuildInputs = [

Related discussion:
text: Steps to reproduce the behavior: python3Packages.rapidfuzz Introduced in . Please run and paste the result.
It appears that cmake selects an incorrect linker. I am currently unsure what's the reason for this. Following I think I might need to set: I have zero experience with nix os + no access to a mac. Is there any way to patch in the build system here to check whether this solves the issue?
Code change:
}; lp_solve = callPackage ../applications/science/math/lp_solve { <del> inherit (darwin) cctools; </del> <ins> inherit (darwin) cctools autoSignDarwinBinariesHook; </ins> }; fabric-installer = callPackage ../tools/games/minecraft/fabric-installer { };

Related discussion:
text: Steps to reproduce the behavior:
I don't have an M1 to test
Oh, it suffices to use . I'll open a pull request.
Code change:
with python.pkgs; buildPythonApplication rec { pname = "pdm"; <del> version = "2.10.4"; format = "pyproject"; disabled = pythonOlder "3.7"; </del> <ins> version = "2.12.1"; pyproject = true; disabled = pythonOlder "3.8"; </ins> src = fetchPypi { inherit pname version; <del> hash = "sha256-bf2dTLWQQ+3sstC0fSCOVdidMzunGX3rBcyi37x6S/s="; </del> <ins> hash = "sha256-OaKroZmGyUWnm/WEw3dSheJOnH+O2KYDgVthxfrF20w="; </ins> }; nativeBuildInputs = [

Related discussion:
text: Steps to reproduce the behavior: truststore Output of : Adding to solves this issue. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
pwnat = callPackage ../tools/networking/pwnat { }; <del> pwndbg = python3Packages.callPackage ../development/tools/misc/pwndbg { }; </del> <ins> pwndbg = callPackage ../development/tools/misc/pwndbg { }; </ins> pycangjie = pythonPackages.pycangjie;

Related discussion:
text: Describe the bug fails to run because setuptools is no longer propagated implictly. If were purely a python application built with then we would just need to add to propagatedBuildInputs and be done. However, is not simply a Python application, but a wrapper around , and isn't built using. The derivation patches the script as follows: This does result in the site-packages directories from all python packages ending up in , including setuptools (e.g. ). I'm not that familiar with Python packaging but from experimenting I found that the full path to the Python egg needs to be included (e.g. ) in order for this method to work. I made an attempt at resolving the issue but being new to Python packaging in Nix, neither are likely to be ideal: We could use buildPythonPackage in place of mkDerivation, using and use Or continue to use mkDerivation and manually set for patchPythonScript: I'm happy to submit a PR but I'm not sure what the recommended solution is here. To Reproduce Steps to reproduce the behavior: Expected behavior should launch with the extension loaded: Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
It seems is normally used by adding a to , or calling with (what the wrapper registered in does). This script then just does some addition calculations to register itself (we probably don't that at all) and some python 2 specific fixups, and then calls , which starts executing some code on import. I'd suggest to package it as a regular python application first (via ), so you can successfully import it inside a . The python tooling should automatically take care of patching the python shebang properly if you make script executable.
proposed fix
Code change:
<ins> diff --git a/actions/system/CMakeLists.txt b/actions/system/CMakeLists.txt index ca861145..3e3d3d3b 100644 --- a/actions/system/CMakeLists.txt +++ b/actions/system/CMakeLists.txt @@ -66,8 +66,6 @@ set(HEADERS ${HEADERS_PREFIX}/actions/playsoundinstance.hpp ${HEADERS_PREFIX}/actions/systemdefinition.hpp ${HEADERS_PREFIX}/actions/systeminstance.hpp -    ${HEADERS_PREFIX}/actions/texttospeechdefinition.hpp -    ${HEADERS_PREFIX}/actions/texttospeechinstance.hpp ${HEADERS_PREFIX}/code/mediaplaylist.hpp ${HEADERS_PREFIX}/code/notify.hpp ${HEADERS_PREFIX}/code/process.hpp @@ -131,7 +129,6 @@ find_package(Qt5 ${ACT_MINIMUM_QT_VERSION} COMPONENTS DBus Multimedia MultimediaWidgets -    TextToSpeech REQUIRED) target_include_directories(${PROJECT} @@ -153,7 +150,6 @@ target_link_libraries(${PROJECT} Qt5::DBus Qt5::Multimedia Qt5::MultimediaWidgets -    Qt5::TextToSpeech ${LIBNOTIFY_LIBRARIES} ${BLUEZ_LIBRARIES} ${UDEV_LIBRARIES} diff --git a/actions/system/src/actionpacksystem.hpp b/actions/system/src/actionpacksystem.hpp index c5768415..27a899d6 100644 --- a/actions/system/src/actionpacksystem.hpp +++ b/actions/system/src/actionpacksystem.hpp @@ -31,10 +31,6 @@ #include "actions/playsounddefinition.hpp" #include "actions/findimagedefinition.hpp" -#if QT_VERSION >= QT_VERSION_CHECK(5, 10, 0) -#include "actions/texttospeechdefinition.hpp" -#endif - #include "code/system.hpp" #include "code/mediaplaylist.hpp" #include "code/notify.hpp" @@ -67,9 +63,6 @@ public: addActionDefinition(new Actions::DetachedCommandDefinition(this)); addActionDefinition(new Actions::PlaySoundDefinition(this)); addActionDefinition(new Actions::FindImageDefinition(this)); -#if QT_VERSION >= QT_VERSION_CHECK(5, 10, 0) -        addActionDefinition(new Actions::TextToSpeechDefinition(this)); -#endif } QString id() const override							{ return QStringLiteral("system"); } </ins>

Related discussion:
text: Project description mouse macro Actiona is a task automation tool. It allows you to create and execute action lists. You don't need to know any programming language to use it: its intuitive interface allows you to create action lists (scripts) using drag & drop. Advanced users can use JavaScript (EcmaScript) to extend its functionality. Actiona is free software and runs under Windows and GNU/Linux. Binaries are available for Windows and Ubuntu for both 32 and 64 bits. The program is developed in C++ and uses the Qt framework. Metadata homepage URL: source URL: license: gpl3 platforms: cross-platform
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .