jiebi/CodeConvo huggingface dataset:
Code change:
<del> { stdenv, fetchFromGitHub, qtbase, qtx11extras, qmake, pkgconfig, boost }: </del> <ins> { lib, mkDerivation, fetchFromGitHub, qtbase, qtx11extras, qmake, pkgconfig, boost }: </ins> <del> stdenv.mkDerivation { </del> <ins> mkDerivation { </ins> name = "twmn-git-2018-10-01"; src = fetchFromGitHub {

Related discussion:
text: twmnd does not launch because qt5 library path is missing. Install the twmn package and run twmnd. twmnd works when I manually set the LDLIBRARYPATH to <qtbase/lib. System: NixOS 16.09.931. Nix version: 1.11.4 Nixpkgs version:16.09.931.
I noticed the same or similar thing when trying to run twmnd as a systemd user service. It just SIGABRTs: I could reproduce with Although works fine... So clearly there is some impurity in my local environment which is making twmnd work "by accident?" Possibly related?:
Code change:
, fetchFromGitHub }: <del> python3.pkgs.buildPythonApplication rec { </del> <ins> let python = python3.override { # FlexGet doesn't support transmission-rpc>=5 yet # https://github.com/NixOS/nixpkgs/issues/258504 packageOverrides = self: super: { transmission-rpc = super.transmission-rpc.overridePythonAttrs (old: rec { version = "4.3.1"; src = fetchPypi { pname = "transmission_rpc"; inherit version; hash = "sha256-Kh2eARIfM6MuXu7RjPPVhvPZ+bs0AXkA4qUCbfu5hHU="; }; doCheck = false; }); }; }; in python.pkgs.buildPythonApplication rec { </ins> pname = "flexget"; version = "3.9.10"; format = "pyproject";

Related discussion:
text: When flexget starts up, it crashes with this error: . The version of transmission-rpc in nixpkgs is currently 7.x.x. Steps to reproduce the behavior: a flexget config that uses transmission. . Flexget runs normally. (transmission-rpc) (flexget) Please run and paste the result.
Upstream flexget has some discussion about upgrading to transmission-rpc v7:
Workaround: the last transmission-rpc 4 version in nixpkgs to transmission-rpc-4.nix: it to an overlay
Code change:
sed -i 's,/etc/protocols,${iana-etc}/etc/protocols,' src/net/lookup_unix.go '' + lib.optionalString stdenv.isLinux '' <del> sed -i 's,/usr/share/zoneinfo/,${tzdata}/share/zoneinfo/,' src/time/zoneinfo_unix.go </del> <ins> # prepend the nix path to the zoneinfo files but also leave the original value for static binaries # that run outside a nix server sed -i 's,"/usr/share/zoneinfo/,"${tzdata}/share/zoneinfo/",nt&,' src/time/zoneinfo_unix.go </ins> # Find the loader dynamically LOADER="$(find ${lib.getLib libc}/lib -name ld-linux* | head -n 1)"

Related discussion:
text: A Go program compiled using nix-shell returns an error when running on a separate server and trying to load a timezone file. file with: $nix-shell $<inside shellgo build $exit $ ./app # name of the app you just created 2019/01/25 20:04:58 All went well: America/NewYork Now copy this file to another computer #./app 2019/01/26 01:01:34 could not load new york locationopen /nix/store/0596k27r6pacyx4jp1bcn8zqyjhji52l-go- no such file or directory The error includes the zip name due to internal reasons the Go team has, but the real problem is that nix replaced with I would be more than happy to send a Pull Request if you agree with the proposed solution of prepending instead of replacing. $ nix-shell -p nix-info --run "nix-info -m" these paths will be fetched (0.00 MiB download, 0.00 MiB unpacked): /nix/store/dzvh4f6ihkwg44mmf2awxg564k1s8khg-nix-info copying path '/nix/store/dzvh4f6ihkwg44mmf2awxg564k1s8khg-nix-info' from ''... system: host os: multi-user?: sandbox: version: channels(diego): nixpkgs: version is nixos-unstable-2019-01-22 The file replaces the path that the go runtime looks for the timezone information. Original Go code is: But nix changes the first entry, for This works fine if you end up running your go application in the same nix env you compiled it, but when you deploy your go program to a separate server, the path, that can look like isn't present on the separate server and then the lookup fails. is a very common path in Linux distributions. A better way to solve this would be to prepend the nix only path, as the first entry, and then keep and the other entries as they are in the original go source code. The benefits are that those who compile and run in the same nix environment will use the nix path, but those who deploy somewhere else won't have to do any extra work.
Code change:
sed -i 's,/etc/protocols,${iana-etc}/etc/protocols,' src/net/lookup_unix.go '' + lib.optionalString stdenv.isLinux '' <del> sed -i 's,/usr/share/zoneinfo/,${tzdata}/share/zoneinfo/,' src/time/zoneinfo_unix.go </del> <ins> # prepend the nix path to the zoneinfo files but also leave the original value for static binaries # that run outside a nix server sed -i 's,"/usr/share/zoneinfo/,"${tzdata}/share/zoneinfo/",nt&,' src/time/zoneinfo_unix.go </ins> # Find the loader dynamically LOADER="$(find ${lib.getLib libc}/lib -name ld-linux* | head -n 1)"

Related discussion:
text: I doubt anyone ever considered support for non-Nix and therefore I will mark it also as . I'll leave it open for now as maybe it can be supported (I doubt it).
would you accept a PR with my proposed solution? It won't hurt nix deployments but will help a use case of building a go program in nix but deploying outside of nix.
cross referencing a thread on the mailing list about this ticket/issue so both conversations are linked.
Your explanation and proposed solution seem to be very reasonable to me. I suggest that you submit a PR.
Code change:
assert "Failed to connect" not in status,  "Failed to connect to the daemon" <ins> with subtest("Daemon can be configured imperatively"): imperative.wait_for_unit("wpa_supplicant-wlan1.service") imperative.wait_until_succeeds("wpa_cli -i wlan1 status") imperative.succeed("wpa_cli -i wlan1 add_network") imperative.succeed("wpa_cli -i wlan1 set_network 0 ssid '"nixos-test"'") imperative.succeed("wpa_cli -i wlan1 set_network 0 psk '"reproducibility"'") imperative.succeed("wpa_cli -i wlan1 save_config") imperative.succeed("grep -q nixos-test /etc/wpa_supplicant.conf") </ins> machineSae.wait_for_unit("hostapd.service") machineSae.copy_from_vm("/run/hostapd/wlan0.hostapd.conf") with subtest("Daemon can connect to the SAE access point using SAE"):

Related discussion:
text: After installing a fresh system with the following configuration: the file is not created, hence wpasupplicant fails to start with the following error: nixpkgs
I don't know the logic of , but I think you're supposed to provide the file yourself. I guess it could be ed if wpa_supplicant fails without one.
You can do
That probably wouldn't work due to permissions. EDIT: wpa_supplicant is still running as root, so it should work.
Fixed in
Code change:
version = "8.0.0"; src = fetchurl { <del> url = "https://web.archive.org/web/20211130172544/https://tetr.io/about/desktop/builds/TETR.IO%20Setup.deb"; </del> <ins> url = "https://web.archive.org/web/20211228025517if_/https://tetr.io/about/desktop/builds/TETR.IO%20Setup.deb"; </ins> name = "tetrio-desktop.deb"; sha256 = "1nlblfhrph4cw8rpic9icrs78mzrxyskl7ggyy2i8bk9i07i21xf"; };

Related discussion:
text: Trying to install tetrio fails (see screenshots) Steps to reproduce the behavior: tetrio-desktop from nixpkgs-unstable (I did it using a flake) The package should install with no errors. ! <!-- 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.
Oops, it looks like I accidentally used a non-direct download link for the source. It also looks like audio is broken, so I'll start a PR soon.
Code change:
libPath = lib.makeLibraryPath [ alsa-lib cups <ins> libpulseaudio </ins> libX11 libXScrnSaver libXtst

Related discussion:
text: Trying to install tetrio fails (see screenshots) Steps to reproduce the behavior: tetrio-desktop from nixpkgs-unstable (I did it using a flake) The package should install with no errors. ! <!-- 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.
Oops, it looks like I accidentally used a non-direct download link for the source. It also looks like audio is broken, so I'll start a PR soon.
Code change:
<ins> diff --git a/src/Settings/ThemeSettings.vala b/src/Settings/ThemeSettings.vala index 589121b..8e9c81e 100644 --- a/src/Settings/ThemeSettings.vala +++ b/src/Settings/ThemeSettings.vala @@ -29,7 +29,7 @@ public class PantheonTweaks.ThemeSettings { var themes = new Gee.ArrayList<string> (); string[] dirs = { -            "/usr/share/" + path + "/", +            "/run/current-system/sw/share/" + path + "/", Environment.get_home_dir () + "/." + path + "/", Environment.get_home_dir () + "/.local/share/" + path + "/"}; </ins>

Related discussion:
text: Project description Pantheon Tweaks is a Switchboard plug allowing users to somewhat tweak Pantheon (elementary OS's DE) settings of the more hidden kind, not normally available from Switchboard. As NixOS has Pantheon packaged, it might be of use in Nixpkgs. Metadata homepage URL: source URL: license: platforms: same as Pantheon Depending on Pantheon version currently in Nixpkgs, the predecessor elementary-tweaks, also GPLv3, might be of more use:
As I maintain Pantheon in NixOS, I approve of this being packaged in the future, but not , because it's archived and IIRC I denied that .
Then we should probably do it once Pantheon in NixOS advances to whatever version elementary OS 6 Odin will have - this'll probably happen once elementary OS 6 will get released.
Ah yes, the repo says "Pantheon Tweaks is currently only supported on elementary OS Odin" :+1:
Did some initial work for this (), would you like to try that? Will need Pantheon 6 () and following line in your NixOS configuration file: Update: I will move this out from the pantheon namespace when creating the PR due to reasons below.
Did some initial work for this great! would you like to try that? of course works great. only the force darkmode did not work in minder program. haven't tested more... ! ! maybe it could be enabled by an option like ? So it's consistent with other options like .
Tested 1.13.1 on both elementary OS (installed via appcenter) and NixOS (btw minder in Nixpkgs seems out-of-date, just opened a PR: ), I guess this should be an issue to minder, as minder is trying to read information from of granite (, ), so it should respect settings from switchboard-plug-pantheon-shell, while what pantheon-tweaks does is (I guess) setting under you gtk config file and I am not sure how handle this. You can check this with: ! I am not sure as this is not an official part of Pantheon. I guess it should be okay to do this.
I am not sure as this is not an official part of Pantheon.
Code change:
<ins> diff --git a/src/Settings/ThemeSettings.vala b/src/Settings/ThemeSettings.vala index 589121b..8e9c81e 100644 --- a/src/Settings/ThemeSettings.vala +++ b/src/Settings/ThemeSettings.vala @@ -29,7 +29,7 @@ public class PantheonTweaks.ThemeSettings { var themes = new Gee.ArrayList<string> (); string[] dirs = { -            "/usr/share/" + path + "/", +            "/run/current-system/sw/share/" + path + "/", Environment.get_home_dir () + "/." + path + "/", Environment.get_home_dir () + "/.local/share/" + path + "/"}; </ins>

Related discussion:
text: yes, that is a concern, but we can make that clear in the description do you think it is acceptable to enable a third-party component (e.g. pantheon-tweaks) with an option like if we clarify that it is third-party in the description, which is for example displayed at the or in the documentation?
I would not recommend packaging this tweaks app. It regularly breaks since it references gsettings that aren't considered API. That's just my personal opinion though I'm not familiar with NixOS options or what that means so I can't really offer an opinion there
thanks for your opinion! the program exists and people want to use it and we at nixos want to empower users to do what they want, even if the choices could be considered bad, like installing proprietary software. that's why it's considered for advanced users. you are responsible for the choices you make and you can end up with a broken system, but it's easy to roll back to a working state. experimenting is encouraged So i think it's fine for us to offer the package, but we can clarify that "it's not recommended by elementary because it regularly breaks". I'm not familiar with NixOS options or what that means so I can't really offer an opinion there i try to explain quickly: on nixos the whole system is configured by one (or multiple) config. file. as a consequence is read-only if you want to use pantheon, you add this line to the config: that sets up pantheon with default settings. there are options to change those default, like to remove default apps you don't need... so the question here is, all current options with in the name relate to official pantheon software, but would relate to third party software, which is not visible from the name. so it might not be 100% clear all the time so my suggestion is to clarify it at least in the description of the option that it is third-party and not recommended the concern is that it could devaluate you branding like the name "pantheon"
ah okay yeah. If possible then it would great if that was not namespaced with actual parts of pantheon and instead namespaced the way you would hand extensions or apps if there's no special convention for extensions. Thanks!
i suggest then
Code change:
<ins> { stdenv, lib, pkg-config, fetchFromGitHub, xorg, libdrm, SDL2, }: stdenv.mkDerivation (finalAttrs: { pname = "switchres"; version = "2.2.1"; src = fetchFromGitHub { owner = "antonioginer"; repo = "switchres"; rev = "refs/tags/v${finalAttrs.version}"; hash = "sha256-/21RcpumWYNBPck7gpH6krwC3Thz/rKDPgeJblN2BDA="; }; nativeBuildInputs = [ pkg-config ]; buildInputs = [ xorg.libXrandr xorg.xorgproto libdrm SDL2 ]; patchPhase = '' runHook preHook substituteInPlace ./custom_video_xrandr.cpp  --replace-fail libX11.so ${xorg.libX11}/lib/libX11.so  --replace-fail libXrandr.so ${xorg.libXrandr}/lib/libXrandr.so substituteInPlace ./custom_video_drmkms.cpp  --replace-fail libdrm.so ${libdrm}/lib/libdrm.so  runHook postHook ''; env = { PREFIX = "$(out)"; }; preInstall = '' install -Dm755 switchres $out/bin/switchres ''; meta = { description = "Modeline generation engine for emulation"; homepage = "https://github.com/antonioginer/switchres"; changelog = "https://github.com/antonioginer/switchres/releases/tag/v${finalAttrs.version}"; license = lib.licenses.gpl2Only; mainProgram = "switchres"; maintainers = with lib.maintainers; [ bot-wxt1221 ]; platforms = lib.platforms.linux; }; }) </ins>

Related discussion:
text: Project description <!-- Describe the project a little: --Switchres is a modeline generation engine for emulation. Its purpose is on-the-fly creation of fully customized video modes that accurately reproduce those of the emulated systems. Based on a monitor profile, it will provide the best video mode for a given width, height, and refresh rate. Switchres features the most versatile modeline generation ever, ranging from 15-kHz low resolutions up to modern 8K, with full geometry control, smart scaling, refresh scaling, mode rotation, aspect ratio correction and much more. Metadata homepage URL: source URL: license: GPL-2.0+ platforms: linux, windows P.S. Switchres is used in RetroArch so there might be something to reference from there. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
<ins> { fetchFromGitHub, buildGoModule, buildLua, lib, }: let version = "1.6.1"; src = fetchFromGitHub { owner = "tnychn"; repo = "mpv-discord"; rev = "v${version}"; hash = "sha256-P1UaXGboOiqrXapfLzJI6IT3esNtflkQkcNXt4Umukc="; }; core = buildGoModule { name = "mpv-discord-core"; inherit version; src = "${src}/mpv-discord"; vendorHash = "sha256-xe1jyWFQUD+Z4qBAVQ0SBY0gdxmi5XG9t29n3f/WKDs="; }; in buildLua { pname = "mpv-discord"; inherit version src; scriptPath = "scripts/discord.lua"; postInstall = '' substituteInPlace $out/share/mpv/scripts/discord.lua  --replace-fail 'binary_path = ""' 'binary_path = "${core}/bin/mpv-discord"' ''; meta = { description = "Cross-platform Discord Rich Presence integration for mpv with no external dependencies"; homepage = "https://github.com/tnychn/mpv-discord"; license = lib.licenses.mit; platforms = lib.platforms.all; maintainers = with lib.maintainers; [ bddvlpr ]; }; } </ins>

Related discussion:
text: Project description A cross-platform Discord Rich Presence integration for mpv with no external dependencies. (MPV Userscript) Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, windows
I've already but haven't PR'ed this to nixpkgs yet. Will probably do this when I get home from vacation next week.
Code change:
githubId = 13000278; name = "Maksim Bronsky"; }; <ins> PlushBeaver = { name = "Dmitry Kozlyuk"; email = "dmitry.kozliuk+nixpkgs@gmail.com"; github = "PlushBeaver"; githubId = 8988269; }; </ins> pmahoney = { email = "pat@polycrystal.org"; github = "pmahoney";

Related discussion:
text: Would be a very useful package to have for ML Enthusiasts Project description Machine Learning Catboost Library Metadata CatBoost is a high-performance open source library for gradient boosting on decision trees homepage URL: source URL: license: Apache License 2.0 platforms: Linux installation instructions: Please let me know if I should stop tagging you in random issues and it bothers you (sorry, i'll stop), but I thought this might be of interest to you since you are very involved in tensorflow.
taggining maintainers of xgboost and lightgbm. Wondering if you could look into compiling catboost too?
I use tensorflow at work, which is why I care :). But I'm not a data-scientist
understood, thank you. GPU support for catboost would also be very welcome.
Looks like they have a non standard install script. But definitely doable. Sadly I don't think I have time in the near future but would be happy to point you in the right direction to get stared with a PR
both eyes wide open - i'll try to start this w/e, any pointers very welcome, thank you.
Currently failing to build on nix, although the file clearly exists.
- maybe it's easier if you create a work-in-progress pull request so other people can check? Two things that stand out are: looks like something is being downloaded during the build process. This won't work with sandboxing because there won't be a working network. builds should be isolated, i.e. access to should be rewritten to the local build directory, not (probably hardcoded somewhere in the build scripts). Packaging for nix can be quite fiddly - I think might be a good example for fetching complex dependencies + build script patches.
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 .
Code change:
# filters assert enableExtraPlugins || enableDitaaFilter || enableMscgenFilter || enableDiagFilter || enableQrcodeFilter || enableAafigureFilter -> unzip != null; <del> assert enableExtraPlugins || enableDitaaFilter -> jre != null; </del> <ins> assert (enableExtraPlugins && enableJava) || enableDitaaFilter -> jre != null; </ins> assert enableExtraPlugins || enableMscgenFilter -> mscgen != null; assert enableExtraPlugins || enableDiagFilter -> blockdiag != null && seqdiag != null && actdiag != null && nwdiag != null; assert enableExtraPlugins || enableMatplotlibFilter -> matplotlib != null && numpy != null;

Related discussion:
text: Since is provided by the non-free on aarch64, I'm not able to install asciidoc-full or any software that requires it to create e.g. the man pages. Can we make an option different from ? /cc
Making new granular options is fine, but I think enableStandardFeatures should still include java. (Or else the option is dishonest.) Alternatively, can we switch to openjdk (assuming that works on aarch64)?
It was just recently changed to in I'm fine with granular options, even though it will be quite some work to make packages not use anymore.
Oh, so this problem is due to licensing, not wanting to use non-free software? I didn't pick up on that earlier. How about adding a disableJava option, that has priority over enableStandardFeatures? Hm, this feels like a local solution to a global problem.
is a good idea! What do you think should be the default?
If enableStandardFeatures is true, you should get java. Setting disableJava then enables standard features except those requiring java. I'm not sure if doing this (per package) is a good idea though. Isn't this the start of a new whack-a-mole game?
Yes, it's certainly not a perfect solution, but I can then use an overlay which sets for . Alternatively, we could enable Java for x86 only by default.
Perhaps it would be less confusing to have so the additive condition is positive.
Code change:
<del> { lib, stdenv, fetchurl, unzip, pkgs, dataPath ? "/var/lib/rainloop" }: let </del> <ins> { lib, stdenv, fetchurl, unzip, writeText, dos2unix, dataPath ? "/var/lib/rainloop" }: let </ins> common = { edition, sha256 }: stdenv.mkDerivation (rec { pname = "rainloop${lib.optionalString (edition != "") "-${edition}"}"; version = "1.16.0"; <del> nativeBuildInputs = [ unzip ]; </del> <ins> nativeBuildInputs = [ unzip dos2unix ]; </ins> unpackPhase = '' mkdir rainloop

Related discussion:
text: via In short: rainloop, a php-based webmail client, features a trivially exploitable stored xss vulnerability. Upstream is unresponsive, and seem to have ceased development. This page explains how the XSS works and proposes an unofficial patch: Example of an other distro applying this very patch:
Code change:
let efiSysMountPoint = if args.efiSysMountPoint == null then args.path else args.efiSysMountPoint; efiSysMountPoint' = replaceChars [ "/" ] [ "-" ] efiSysMountPoint; <ins> initrdSecrets = config.boot.initrd.secrets != {}; </ins> in pkgs.writeText "grub-config.xml" (builtins.toXML { splashImage = f cfg.splashImage;

Related discussion:
text: Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.