jiebi/CodeConvo huggingface dataset:
Change:
file intltool gobject-introspection <ins> makeBinaryWrapper </ins> wrapGAppsHook3 python3.pkgs.pytest-runner ];

Discussion:
Something about terminator and the way it uses python messes with your PATH setting, which interferes with Nix working properly. For example, echoing my path in xterm: But after launching into terminator, it looks like this: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Unsurprisingly perhaps, but FWIW I can reproduce. Do you know if this is (or isn't) the behavior when using terminator in other environments? Anyway mostly wanted to let you know it's not just you :).
Hm, I guess with new buildPythonPackage it just doesn't run? And there is double wrapping, indeed…
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 . on the on .
I'll just go ahead and un-stale this. It's still an issue and I ran into it. The wrappers also set , which could probably also cause some trouble.
I marked this as stale due to inactivity. &rarr;
Still an issue
Also:
Hello, I have this same issue here.
I have the following issue: Within (e.g.) Gnome Console, my looks as it should: However, within terminator, it's messed up with several additional paths: (Both tested with bash.)
Yeah, that seems like the same issue. Problem is that it isn't straightforward to solve properly. If you want a slightly hacky workaround, some of the discussions on the equivalent kitty bug I linked above may help. Basically just use your shell init script to clean the terminator-only bits from . Something like: Should do the trick, I think.

In very rare cases, this won't quite work right, such as if you start terminator from inside a , in which case it will obliterate the shell's additions, but it's pretty tough to get around that limitation here, and it's probably not a big issue. EDIT: scratch that, I'm being silly. will point to python, not terminator itself... you'd probably have to analyze to get a proper distinction. Like so:
Change:
buildPythonPackage, dotmap, fetchFromGitHub, <ins> packaging, </ins> pexpect, protobuf, pygatt,

Discussion:
Running the meshtastic CLI (python3Packages.meshtastic) fails with this error: It works if you run it using . Steps to reproduce the behavior: . The program runs correctly. <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Seems like just adding to the dependencies works
Change:
}; host = mkOption { <del> description = "Remote host where snapshots should be sent."; </del> <ins> description = "Remote host where snapshots should be sent. <literal>lz4</literal> is expected to be installed on this host."; </ins> example = "example.com"; type = types.str; };

Discussion:
Describe the bug I'm testing out with the following configuration: Which yields the following: The error message, decoded, says: To Reproduce Steps to reproduce the behavior: to expected zfs datasets, create snapshot, generate keys, etc... client host with the above configuration. Expected behavior A transmission of a snapshot from the client to Notify maintainers Metadata
At first glance this looks like the remote host doesn't have lz4 in its path when root logs in. Can you confirm this by starting an SSH session to that host as root and doing a whereis lz4?
That was it: installing fixed it; a snaphot is currently being transmitted. A note about being expected should probably be to the documentation of .
Change:
, perl }: <ins> let pythonEnv = python3.withPackages (pp: with pp; [ dbus-python setproctitle pygobject3 pycairo pp.xapp # don't omit `pp.`, see #213561 pillow pyinotify # for looking-glass pytz tinycss2 python-pam pexpect distro requests ]); in </ins> stdenv.mkDerivation rec { pname = "cinnamon-common"; version = "5.6.7";

Discussion:
I have 2 clear bugs for cinnamon that I can't find a way to solve 1- not working due to missing of 2- doesn't show events due to missing of both of the issues related to Steps to reproduce the behavior: in any of the bugged apps
Change:
]; }; }; <del> in graalvmXXX-ce </del> <ins> in graalvmXXX-ce </ins>

Discussion:
Usage of flag without , and it is known in the Clojure community that its usage causes issues. This is because without the binaries are statically linked with , and I tried to create a GraalVM derivation compatible with . The result is here: However, this can't be upstreamed since it brokes all compilations with (including dynamically linked programs as used in nixpkgs). The major issue is that, to make compilation work, . This approach works fine for when we have only one lib C, however if we have two separate lib C we will have name conflicts and either we will have a compilation with glibc symbols on musl libraries or vice-versa. So, what are the options? One approach I can think is extend the wrapper from binary to conditionally include either or depending on the context (e.g.: if the flag is passed or not). We can do this using the flag, as below: For this to work we also need to remove the symbolic links to glibc library, otherwise this can conflict with musl libraries. This should also fix this . However, this looks like a very ugly solution, and I am open for better ones. Steps to reproduce the behavior: . Keep in mind after , it expects binary as . You can create a symbolic link and add it to your a file with contents: (segfaults) It should compile and run successfully. N/A Add any other context about the problem here. <!-- 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:
Change:
openal = if stdenv.isDarwin then null else openal; libmfx = if stdenv.isDarwin then null else intel-media-sdk; libpulseaudio = if stdenv.isDarwin then null else libpulseaudio; <del> rav1e = null; </del> <ins> rav1e = if stdenv.isDarwin then null else rav1e; </ins> samba = if stdenv.isDarwin then null else samba; vid-stab = if stdenv.isDarwin then null else vid-stab; x265 = if stdenv.isDarwin then null else x265;

Discussion:
cc:
It appears that there is a bad interaction between cargo-c and cargo's LTO.
Change:
src = fetchurl { url = "mirror://sourceforge/flightgear/release-${shortVersion}/${pname}-${version}.tar.bz2"; <del> sha256 = "1z52r28xg05q6hdlh4szzfjlpgkvbdyn2dpaji9b57y58ccrqsfh"; </del> <ins> sha256 = "1l8kiicm0klbx0b05994vqd8a8wj7k0djbbg41a6i3q5d17jrnk6"; </ins> }; nativeBuildInputs = [ cmake ];

Discussion:
Describe the bug Trying to build fails To Reproduce Additional context Apparently it was already broken here: Maybe it makes sense to update to recently released version 2020.1. Notify maintainers
I'll try and fix by updating.
Change:
<ins> diff --git a/src/extensions.c b/src/extensions.c index 038dcb2..830465d 100644 --- a/src/extensions.c +++ b/src/extensions.c @@ -121,16 +121,7 @@ daemon_read_extension_directory (GHashTable  *ifaces, continue; } -                /* Ensure it looks like "../../dbus-1/interfaces/${name}" */ -                const gchar * const prefix = "../../dbus-1/interfaces/"; -                if (g_str_has_prefix (symlink, prefix) && g_str_equal (symlink + strlen (prefix), name)) { -                        daemon_read_extension_file (ifaces, filename); -                } -                else { -                        g_warning ("Found accounts service vendor extension symlink %s, but it must be exactly " -                                   "equal to '../../dbus-1/interfaces/%s' for forwards-compatibility reasons.", -                                   filename, name); -                } +                daemon_read_extension_file (ifaces, filename); } g_dir_close (dir); </ins>

Discussion:
Describe the bug AccountsService refuses to read the extensions files, and emits this warning This why I believe people noticed issue, because from lightdm won't exist because of this. This is particularly problematic for Pantheon, which plans to use AccountsService extensions for a variety of things, and currently for a harmonized time_format setting. The actual warning in the source code is at and it's because this returns false. These symlinks checks are tricky for NixOS, where the symlink they expect is a symlink to a symlink to a... :smile:
cc
I would just drop the checks. The assumptions might not make sense even with FHS systems, since AccountsService uses XDGDATADIRS to find the extensions.
I think we could drop the then.

LightDM seems not installing dbus interface of AccountsService. Systemd journal: In package, it is contained: But in the current system: system: host os: multi-user?: sandbox: version: channels(root): channels(mnacamura): nixpkgs:
Hmm, apparently it is some kind of extension to : Weird that it is not linked – the lightdm module contains .
Actually, the dbus module does not use , it creates a configuration file: The directory is probably just a side effect of something adding to .
Ah I see. So, the is put in : I examined : <sI guess lightdm 's should also be included in these paths?</sNo. The interface file has .xml extension. It is not a config file.
Probably, interfaces files should be linked in ?
No idea – I thought the interface files were only for introspection or something. I tried linking to by adding it to but that does not seem to help. You can try the route but I do not see it documented anywhere. Though, I do not see the one in data dirs documented either – perhaps it is really just for applications like d-feet. But the data should be available through dbus interface so I do not see the need for installing the XML files. On a side note, for the interface symlinks in , so something like the following might be good:
Thanks for suggestion. I tried this: Apparently the interface file appears, but I still see the error.
Does this look relevant ?
Hopefully fixed by the above PR.
Change:
let warn = if verbose then builtins.trace else (x: y: y); <del> references = import (runCommand "references.nix" { exportReferencesGraph = [ "graph" drv ]; } '' </del> <ins> references = import (runCommandLocal "references.nix" { exportReferencesGraph = [ "graph" drv ]; } '' </ins> (echo { while read path do

Discussion:
Currently when distributed builds enabled each derivation is uploaded to the remote server to have their hashes rewritten. Within pkgs/build-support/replace- the 'replaceHashes; derivation should be marked in such a way so that the replacement is done locally for those people who have enabled distributed builds. I believe there is a simple way to do this, but I need to look up how it is done. I've assigned myself this issue, but you might also be interested in fixing it.
, I suppose.
(triage) , any update on this ? Have you fixed it ?
Are there any updates to this issue, please?
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 . on the on .
Change:
<ins> diff --git a/server_test.go b/server_test.go index fc225ce..2df3608 100644 --- a/server_test.go +++ b/server_test.go @@ -446,63 +446,6 @@ func TestPostJSONUpload(t *testing.T) { } } -func TestPostJSONUploadMaxExpiry(t *testing.T) { -	mux := setup() -	Config.maxExpiry = 300 - -	// include 0 to test edge case -	// https://github.com/andreimarcu/linx-server/issues/111 -	testExpiries := []string{"86400", "-150", "0"} -	for _, expiry := range testExpiries { -		w := httptest.NewRecorder() - -		filename := generateBarename() + ".txt" - -		var b bytes.Buffer -		mw := multipart.NewWriter(&b) -		fw, err := mw.CreateFormFile("file", filename) -		if err != nil { -			t.Fatal(err) -		} - -		fw.Write([]byte("File content")) -		mw.Close() - -		req, err := http.NewRequest("POST", "/upload/", &b) -		req.Header.Set("Content-Type", mw.FormDataContentType()) -		req.Header.Set("Accept", "application/json") -		req.Header.Set("Linx-Expiry", expiry) -		if err != nil { -			t.Fatal(err) -		} - -		mux.ServeHTTP(w, req) - -		if w.Code != 200 { -			t.Log(w.Body.String()) -			t.Fatalf("Status code is not 200, but %d", w.Code) -		} - -		var myjson RespOkJSON -		err = json.Unmarshal([]byte(w.Body.String()), &myjson) -		if err != nil { -			t.Fatal(err) -		} - -		myExp, err := strconv.ParseInt(myjson.Expiry, 10, 64) -		if err != nil { -			t.Fatal(err) -		} - -		expected := time.Now().Add(time.Duration(Config.maxExpiry) * time.Second).Unix() -		if myExp != expected { -			t.Fatalf("File expiry is not %d but %s", expected, myjson.Expiry) -		} -	} - -	Config.maxExpiry = 0 -} - func TestPostExpiresJSONUpload(t *testing.T) { mux := setup() w := httptest.NewRecorder() @@ -1301,5 +1244,4 @@ func TestPutAndGetCLI(t *testing.T) { if !strings.HasPrefix(contentType, "text/plain") { t.Fatalf("Didn't receive file directly but %s", contentType) } - } </ins>

Discussion:
Project description Self-hosted file/code/media sharing website. Metadata homepage URL: source URL: license: GPLv3 platforms: Linux
to confirm you are keen on getting the fork, not original tool packaged:
Yes.
Change:
"Microsoft.NETCore.App.Host.linux-musl-x64"  "Microsoft.NETCore.App.Host.linux-x64"  "Microsoft.NETCore.App.Host.osx-x64"  <del> "Microsoft.NETCore.App.Host.win-arm"  </del> "Microsoft.NETCore.App.Host.win-arm64"  "Microsoft.NETCore.App.Host.win-x64"  "Microsoft.NETCore.App.Host.win-x86" 

Discussion:
Package name: , Latest released version: 8.0.100-preview.6..14 Current version on the unstable channel: 8.0.100-preview.5..2 Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR.
I have a PR for the other dotnet versions (), unfortunately the 8.0 version has problems with missing system nuget versions. Due to that I was planning on skipping this version (it's unstable and should not be dependended upon anyway). Are there any features in this new version that you consider important? I can try hacking up the update script in that case.
Change:
]; propagatedBuildInputs = [ <del> # TODO: re-add liblouis when it is fixed pygobject3 pyatspi dbus-python pyxdg brltty speechd gst-python setproctitle </del> <ins> pygobject3 pyatspi dbus-python pyxdg brltty liblouis speechd gst-python setproctitle </ins> ]; <ins> strictDeps = false; </ins> buildInputs = [ python gtk3 at-spi2-atk at-spi2-core dbus gsettings-desktop-schemas gst_all_1.gstreamer gst_all_1.gst-plugins-base gst_all_1.gst-plugins-good

Discussion:
has been broken on master for a while now, blocking orca. I opened an but they are not sure how to fix it.
I removed it from orca in
Change:
++ lib.optionals (guiModule == "ntk") [ ntk cairo libXpm ] ++ lib.optionals (guiModule == "zest") [ libGL libX11 ]; <del> cmakeFlags = [ "-DGuiModule=${guiModule}" ] </del> <ins> cmakeFlags = [ "-DGuiModule=${guiModule}" "-DZYN_DATADIR=${placeholder "out"}/share/zynaddsubfx" ] </ins> # OSS library is included in glibc. # Must explicitly disable if support is not wanted. ++ lib.optional (!ossSupport) "-DOssEnable=OFF"

Discussion:
I upgraded Zynaddsubfx (latest unstable), and was surprised to discover the new amazing interface (whooa)... and that I had no more loaded instrument (empty bank). I solved that problem by removing the user zynaddsubfx configuration and bank cache (I think the problem is the bank cache): and indeed, once you reload zynaddsubfx, you can see that the instruments are back. Also, a new file is created, and the bank path is hardcoded, like: I guess that in other distributions this path does not change when zynaddsubfx is updated, but with nix the bank path changes on upgrade, so the user needs to manually clear the cache on each upgrade. I'm not sure what's the best way to solve this problem. I was thinking that the best solution may be to add a small wrapper around zynaddsubfx which clears the cache if it detects in a path to another nix executable. The other possibility may be to use instead of the one, but it won't work outside of NixOs. If these options are not working, at least it would be nice to document that bank cache should be cleared on upgrades. Steps to reproduce the behavior: zynaddsubfx and potentially garbage collect the old version zynaddsubfx: instruments may disapear
Yeah it's really nice :blush: It was a lot of work to get it built. I'm not sure if any other distro even uses the new Zyn-Fusion interface, because it's not the default UI when building from source. I also noticed this problem before between upgrading & running . I tried working on a patch to avoid dumping the default paths into the config, but I never finished it. I'll try looking into it again!
I marked this as stale due to inactivity. &rarr;
still relevant, just haven't gotten around to fixing it
I think this issue should not be closed as for now it is based on a non-accepted PR , so I'll re-open waiting for the changes to be merged upstream.
Change:
ddcutil glib hwdata <ins> libdrm </ins> libpulseaudio libselinux libsepol

Discussion:
uses and to convert PCI device ID to human-readable product name. Currently their paths are hard coded as and . It won't work with NixOS of course. I found some packages that have similar issues. They are patched directly before building: Fastfetch needs to be patched too. Steps to reproduce the behavior: N/A Fastfetch can properly find and N/A Reference: Fastfetch provided cmake config option  for but not for . I can add one if needed. N/A Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi thanks for the detailed issue report! This should be pretty straightforward to fix. If you could add a config option for the path that would be great! Many thanks.
.
was released with support
Many thanks! Much appreciated.
Change:
{ lib <ins> , fetchpatch </ins> , python3Packages , fetchFromGitHub , wrapQtAppsHook

Discussion:
When using inkcut as an inkscape extension, it cannot 'open current document' Steps to reproduce the behavior: inkscape with the inkcut extension as above some objects 'Extensions'-'Inkcut'-'Open current document' Nothing happens, and the console says: Open the image in inkcut Indeed seems to have disappeared from the inkscape extensions folder, it is now a directory of its own. Possibly needs an upstream fix in inkcut. Seems to be broken since Please run and paste the result.
Change:
<ins> { stdenv , lib , fetchFromGitHub , buildMozillaMach , nixosTests }: ((buildMozillaMach rec { pname = "floorp"; packageVersion = "11.5.0"; applicationName = "Floorp"; binaryName = "floorp"; version = "155.4.0"; src = fetchFromGitHub { owner = "Floorp-Projects"; repo = "Floorp"; fetchSubmodules = true; rev = "v${packageVersion}"; hash = "sha256-adK3LAu3cDh6d+GvtnkWmSnxansnSZoIgtA9TAqIMyA="; }; extraConfigureFlags = [ "--with-app-name=${pname}" "--with-app-basename=${applicationName}" "--with-branding=browser/branding/official" "--with-distribution-id=app.floorp.Floorp" "--with-unsigned-addon-scopes=app,system" "--allow-addon-sideload" ]; meta = { description = "A fork of Firefox, focused on keeping the Open, Private and Sustainable Web alive, built in Japan"; homepage = "https://floorp.app/"; maintainers = with lib.maintainers; [ christoph-heiss ]; platforms = lib.platforms.unix; badPlatforms = lib.platforms.darwin; broken = stdenv.buildPlatform.is32bit; # since Firefox 60, build on 32-bit platforms fails with "out of memory". # not in `badPlatforms` because cross-compilation on 64-bit machine might work. maxSilent = 14400; # 4h, double the default of 7200s (c.f. #129212, #129115) license = lib.licenses.mpl20; }; tests = [ nixosTests.floorp ]; }).override { privacySupport = true; enableOfficialBranding = false; }).overrideAttrs (prev: { MOZ_REQUIRE_SIGNING = ""; }) </ins>

Discussion:
Project description Floorp is a firefox fork. Metadata homepage URL: source URL: license: MPLv2.0 platforms: windows, macos, linux
Change:
partOf = systemdMountPoints; bindsTo = systemdMountPoints; unitConfig.RequiresMountsFor = stateDir; <ins> # This a HACK to fix missing dependencies of dynamic libs extracted from jars environment.LD_LIBRARY_PATH = with pkgs.stdenv; "${cc.cc}/lib"; </ins> preStart = '' # Ensure privacy of state

Discussion:
Version: 16.03pre75740. (Emu) To reproduce: to run set-inform on a gateway device to point it to the nixos host running unifi. device will fail to be adopted, repeatedly. status -l unifi will show: This is because the java service extracts an embedded snappy-1.0.5- to /tmp and tries to use it. It fails, since this is a binary compiled without nixos. Since this package is built from a tarball of binaries, I don't know if it's even possible to remedy this cleanly. My workaround is adding the following to This allows the java parent process to find at runtime. I don't know any better way to handle this requirement; hopefully a more experienced contributor knows a better solution.
I'd imagine we'd either have to extract the tarball, the contents, and then tar it up again, or perhaps just use a wrapper around the main binaries, so that you don't need to modify the environment in the service.
Feel free to cherry-pick
Unfortunately, that fix doesn't address the problem, since the .so in question is inside a .jar and extracted conditionally(?) at runtime: ./UniFi/lib/snappy-java- ./UniFi/lib/snappy-java- ./UniFi/lib/snappy-java- ./UniFi/lib/snappy-java- ./UniFi/lib/snappy-java- ./UniFi/lib/snappy-java- Reconstructing the jar files seems tedious and error-prone. It's also impossible in cases where a signed jar is used (not here, but possibly in the future), I think? Probably wrapping the java invocation in the service file is the way to go, as it should accommodate more unpleasant surprises possibly to come in the future. I'm not familiar enough to work out the exact way to do it. LDLIBRARYPATH may be appropriate, but I don't know how, at runtime, to get the nix-store path that contains the proper (hence my use of the system-wide lib dir). Is that even possible and safe? Seems like libstdc++ must be part of the unifi's buildInputs since the manager will need to track the store path as a dependency.
It seems reasonable to add and to ld library path of the service in that case. Eric Litak wrote:
Okay.

Would you like me to pull request a patch for the nixos module or do you want to do it?
Go ahead Eric Litak wrote:
Okay, sorry it took me so long, but I had to first figure out how to replace the "nixos" channel system-wide,--which is notably absent from nixos manual, btw--then rebuild a lot of packages from source as a result. Here's the pull request: Please advise on whether it's safer/better to include the libc path as well (they seem to be already handeld) or if just the gcc libs will suffice.