jiebi/CodeConvo huggingface dataset:
I was not able to properly test this right now (sorry :bowingwoman:), but here are some random things you can try: See if you can reproduce this with nautilus, thunar, also some old version of nemo, some old nixpkgs checkouts, ... If you find it previously working, a bisect point will be appreciated. Install debug symbols and reproduce the crash, not tested but should be something like: Then get list of crashes with , run and enter . Based on the above step, try to patch away (remove) some of the lines in  according to your stack trace and try reproduce the issue, you can also e.g. try swapping the order they distroy widgets to see if it matters. Sorry I have no idea how killactive "closes" a window, is that the only way to trigger the crash? Did you spot the crash when closing nemo normally, i.e. clicking (File) - (Close All Windows) and/or (File) - (Close)?
Sorry I haven't got time to debug it, but I've tested with "close all windows" or "close" several times, they didn't crash and "close" works correctly. Thunar don't (since it doesn't share the same pid across windows?), and nautilus refuses to open a second window when one exists.
Okay here is the coredump:
Weird, did you trigger the crash after rebuilding nemo? :thinking:
Yes, by the same killactive sended by hyprland
in my nixos configuration, and installed with home manager (home manager as a module of nixos). This rebuilds nemo (I saw it) when applying config.
Can you try adding to () instead?
Okay it seem to work, and now I get this:
Pretty fun though, it happens even without triggering the 'search window'. I just open and close the nemo, and do nothing else.
Make sense to me! If I hit the search button to trigger the search widget, then close it, it won't crash (tested 10 times). So the problem is trying to destroy a widget that doesn't exist.
However, there is another question: fedora and archlinux with the exact nemo 5.6.3, hyprland latest, xdg-desktop-portal-hyprland, doesn't, and the code makes sense. So what is happening to nixos?
Unsure of memory leaks, but anyway it works. This seems like a upstream bug and caused by gtk or glib version compatibility. Will close it for now.
Hmmm, please consider reporting this to linuxmint. I checked nautilus and they after so we are on our own. I actually wonder whether a check is needed But it is unclear to me why the null check is not enough :upsidedown_face:
Tested, this is not enough however.
Did this ever get fixed? I seem to be having this same issue still with version 6.0.2
I totally forgot that. I'm using my patches for more than one year. This is also useful for Would be better to report it upstream, though.
Thanks for the info. This does in fact fix it. It's worth noting for anyone who might travel this path in the future - the patch has to be applied to , even if using . Totally didn't spend 45 minutes trying to figure out why it wasn't working just to figure that out
Please try .
seems to work?
Project description ClickUp is a project management solution, similar to Trello Metadata homepage URL: source URL: N/A license: unfree platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Seems like it's needs to be archived with (currently it's down). Download URL is:
I also found this PR, but it has been a year
Yeah I did give packaging it a shot but I could not find a reliable way to get it downloaded because there doesn't seem to be an exposed way to get a specific version?
Yeah, I also checked PR URL, and it doesn't seem to give reliable version package. Even AUR has some problems. That's why I suggested
When you try to connect to the Tor network using the Tor browser you get the error message ! When you try to visit a website after being shown the big red error message your get the error message ! This problem appeared between one and two weeks ago. ; can't find an existing Nixpkgs issue. Steps to reproduce the behavior: the Tor browser from Nixpkgs the Tor browser on error message to go to a website When clicking on the browser should connect to the Tor network and be able to browse. The . browsers says that it can detect my internet connection. ! Tor logs doesn't seem to indicate any problems (from what I can interpret) I live in Sweden and this issue has appeared both when I've connected to the internet using my home connection (Sunet) and when I've connected over a VPN. I.e. no fuckery by an oppressive government. The timeline match up-ish with when would have become available in the binary caches. Unsure if the error appeared before or after updating around that time. After checking the original PR I see that this problem was noticed, but a workaround was applied. Doesn't seem to work for me :-/ The value is for me. I'm using root on tmpfs, and nothing under is persistently saved between boots. ! <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- and because you seem to have actually researched the problem. The system is fully up-to-date as of 2023-03-05 22:15 CEST.
The red error message indicates that Tor cannot find the tor socket. Everything else is bound to not work unless it goes over the normal internet. Please see and for the underlying problem and please check if the firefox setting points to the right socket file.
I tested to set to , but that didn't help.
Setting to also doesn't work.
Just to avoid ambiguities, did you set to (with file name part)? TBB is still working fine for me with the workaround. Likewise for me, is a tmpfs. Have you modified (and forgotten about it) your torrc, e.g. to use a different control port/mechanism? What is your XDGSESSIONTYPE?
The person on uses wayland (with sway). I currently still use x11 (with i3) and haven't tested it with wayland.
That did it! I missed that you should specify the file in the path. I'm using AwesomeWM.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
The person on had the same problem and the same solution :-)
Why did you close this issue You can't seriously think that this temporary workaround is an acceptable permanent solution to this problem? While we still don't have a permanent solution, it should be as easy as possible for users to find information about this workaround. By closing this issue we signal to people that this problem has been solved. And people currently experiencing this problem on a fully up-to-date system will probably not think about looking into closed issues, because the issue is still there.
I am also experiencing this issue. The fix worked for me.
Confirmed. The issue is still present. Default installed value of is 127.0.0.1. Changing it to resolves the problem.
This issue only started happening on my machine after deleting today.
Still an issue. I'm using TBB with firejail and I have to apply the workaround at every restart. TBB creates the folder but not a profile inside (this wouldn't be a problem for me if connection works out of the box). about:config - = tor-browser-bundle-bin 12.0.5 firejail-0.9.72 nixos-unstable
By default, the service runs on port 9050 and the control port on 9051. This is configured in the torrc file: Your firewall may be blocking some of these ports bound by default to localhost which normally point to 127.0.0.1
The PR for Tor Browser 13 removes the current workaround again, because it seems the issue was fixed upstream: I would be grateful if some of you could give this a try and report if it's still working (or working again).
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.3.0 desired version: 1.3.3 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Project description is a library that provides strong cryptographic hashes for password hashing, such as bcrypt and yescrypt, as well as a number of legacy ones for backward compatibility (e.g. sha256). It is API- and ABI-compatible with provided by glibc. glibc intends to drop the library eventually: This is a first step towards transitioning whole nixpkgs from libcrypt bundled in glibc, as described here: Metadata homepage URL: source URL: license: lgpl2.1+ platforms: unix
Describe the bug Since upgrading v8 to 8.4 () it no longer builds on darwin (at least on my 11.2.3 machine) To Reproduce Steps to reproduce the behavior: Expected behavior A successful v8 build Additional context By default it fails when trying to find the macos sdk, which I patched around with: This then gets as far as , which is avoidable with: which then produces ... and I had to admit defeat. Notify maintainers Metadata Maintainer information:
Hi! Thanks for reporting this! I've opened which I hope fixes this - at least it builds fine for me on 10.15. Please give it a try on your machine too.
Yep, looks good!
Describe the bug wendy, one of the big-parallel build hosts used by , cannot successfully build This blocks advancing nixos-unstable. To Reproduce Steps to reproduce the behavior: wendy to build Observe :( or, more realistically: the attached CMOV16rm-, and run (a reduced commandline that produces the same assertion failure is ) Expected behavior A clear and concise description of what you expected to happen. Additional context The assertion that's tripped by this YAML file is: 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 Please run and paste the result. Maintainer information:
is the CMOV16rm- (can't upload it here because it's not a supported GitHub filetype, apparently). To be more precise, the test that is failing is this one:
This has primarily become apparent because the configuration was changed in NixOS/nixos-org-configurations to make wendy only build big-parallel jobs. Since llvm is big-parallel, this means that wendy will now usually get selected for building llvm, since the load is otherwise pretty low. Previous successful builds of have been using one of the packet builders instead, which are using a newer CPU for which LLVM has a scheduling machine model.
FWIW, this probably affects other LLVM versions as well, but they have current versions in the cache. If wendy rebuilds the other packages (e.g. stdenv bump or something), they'll likely start failing as well.
If you spin up a VM using the CPU profile that at least virt-manager calls "OpteronG1", then you can reproduce this using the LLVM tests. That's not quite the same as the CPU reported on wendy (OpteronG1: k8-sse3; wendy: amdfam10), but it exhibits the same problem.
I don't know why, but wendy as disabled now.
it's probably late for you (I hope I didn't confuse names), but you this issue some time ago.
uh, same full name but this GitHub name is in .
Filed upstream for this.
Steps to reproduce the behavior: I updated nixpkgs and now nixops does not work anymore. I don't even use gce, so I'm baffled why it's failing. was still working. In both cases I used the same nixops version 1.7. My config did not change and can be found at <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
In the future, please ping the maintainers as instructed in the template. cc
Thanks for doing that, I didn't know who to ping
loaOf was removed in after many years of being deprecated nixops at 1.7 still had loaOf being used as it was released(2019) before the type was deprecated also cc
I've switched to morph in the meantime. I keep this issue open for if someone wants to fix it.
Not everyone may be able to switch away easily. Simple nixops deployment without cloud resources and static hosts may be easy, but that's not all deployments. Reverting in
Emacs mozc looks to only package the file, but it requires other binaries to work. Specifically 'mozcemacshelper' is required for it to run, as well as the mozcserver. I suppose the server can be installed with ibus-mozc, or fcitx-mozc, etc, but either way I did not find 'mozcemacs_helper'. Steps to reproduce the behavior: emacs to require it - and run mozc Japanese input via the Mozc IME should be functional <!-- 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.
I made a patch Could you try it?
I have a feeling this will not work for you now due to Apparently just changed paths (it's in now under the ibus-mozc store path). So I think it should continue to work as long as the emacs variable is updated. (I'm using fcitx5 so it didn't hit me, but I came across this by chance and thought I should let you know)
Package name: Latest released version: Current version on the unstable channel: Current version on the stable/release channel: Notify maintainers I attempted to update the version myself, but encountered an issue: Unfortunately, I don't have the time to investigate further at the moment. Therefore, I would appreciate it if someone else could take it from here. Note for maintainers: Please tag this issue in your PR.
I've updated the issue to reflect that the same error persists even with version .
Any expression on darwin which sets fails to build claiming that the C compiler cannot create executables. This is the same issue as , but it more serious than I thought, so I'm raising it as a separate issue. To reproduce just change anything to use on darwin, like the build.
I'm beginning to suspect executables built on 10.9 which don't use clangStdenv, but rather use the gcc 4.8.2 which Nix builds. I'm seeing frequent and consistent general protection faults (EXCI386GPFLT) from several different executables built in my Nix store. It's still possible these frequent GPT faults could be due to a faulty processor, so I'm waiting on delivery of a new desktop machine to do some comparison testing.
For future note: Those GPT faults were from a bad memory module in my machine. After fixing that module, I was able to rebuild all of my Nix packages using , and it succeeded as expected.
should hide the cursor but does not on X11. I have not tested this on Wayland or Cocoa. Steps to reproduce the behavior: GLFW 3.3.x (to match unstable, which is currently 3.3.4) GLFW's dependencies ( on X11), build the library's examples. The default CMake build should do the job: using or equivalent. Verify that left clicking the window hides the cursor since is set. NixOS's , build the example manually with . Execute it and now clicking moves the cursor to the center of the window but does not hide it. NixOS build should behave the same as the hand-built one. GLFWCURSOR_HIDDEN is also affected. and
Could you send a strace of you running the example?
Yes I could. It seems that it's not due to how GLFW is built by nix but how dynamic libraries are looked up at runtime. Since the handmade executable only works with I made the wrong assumption: the one linked against nixpkgs' GLFW also work correctly. For the ease of reproducibility this is the program for producing the straces: I'm not sure if this is the cause but something is definitely wrong:
Describe the bug Themes are not listed anymore in the Appearance Preferences for the Mate desktop environment. Some screenshots of a VM running Mate to demonstrate the issue: ! ! Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Is the value of clobbered in the session? In an unwrapped program like , what is its value?
In in a VM with almost only Mate installed:
With the following patch find the themes.
It seems that the function to locate the system themes. This function is returning something like , which is not suitable for NixOS, I suppose. If this is really true, than is not being used. How it used to work before, I do not know.
 uses the environment variable , if it is defined. Does it used to be defined in some NixOS module, and has that changed?
We patch gtk2 like so that function works there without having to set which isn't good. By all means mate shouldn't use this totally deprecated function at all, especially in gtk3.
I may patch it to use and submit upstream.
Describe the bug When using krb5 together with samba & winbind for login in an AD, login works everywhere except . So or for example work just fine. However, when is used (either through the binary in the shell or through a tty or display manager), I get: Up on further inspection, I noticed a difference in the respective pam service files. Most of these files have with one notable difference: has If I change the in by , I can login to AD accounts without problem even using or . To Reproduce Steps to reproduce the behavior: (It's not realistically possible to reproduce the full setup) an AD with krb5, samba (+winbind) and a custom pam winbind service ` Expected behavior Login works for AD users with , and all the same. Additional Notes I'm by no means an expert in the domain of domains. What I however wonder is, how others solved this issue when integrating NixOS machines in an AD. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Update: This seems to be related to the section following in the pam module. Namely, if any of , , , , , or is true, is , breaking any remote auth (like LDAP/AD/...). Why is this the case? Do these things (like kwallet or gnome-keyring) only work when called after ?
I marked this as stale due to inactivity. &rarr;
This is not stale.
At least for sssd, it looks like gnome keyring would be propagated correctly (). So probably the comment pamunix is marked as 'sufficient' on NixOS which means nothing will run after it succeeds. Certain modules need to run after pamunix prompts the user for password so we run it once with 'required' at an earlier point and it will run again with 'sufficient' further down. We use tryfirst_pass the second time to avoid prompting password twice from is likely not true anymore for sssd
Fixed by .
When building nixos top level, will be too long to consume. I don't have a minimal config to generate the drv but here is an example: No Error Related code: Not entirely sure which version is causing the failure --- used to be able to built on but seems to be failing afterwards. Will update once find the exact hash. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The module list grows over time, so it would make sense to hit the limit at some point. I suppose you could write the expression to a file and pass to fix the problem. I don't get why this derivation is called "lazy" though.
I want to use the TTS Mimic on a Debian 11. After installation, I Tried reading a text. Cli usage give me an "alsa lib error". Steps to reproduce the behavior: -env -iA -t "hello world" A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Please run and paste the result. Maintainer information:
works perfectly on NixOS 21.05. Can you elaborate more about your sound setup? While geared toward NixOS, this thread might give useful information to debug further: Also try running ALSA tools or CLI audio applications natively from Debian and via to observe any differences in behaviour.
The above works for me too on NixOS, at least. I'm not familiar with how ALSA and PulseAudio in nixpkgs integrate with non-NixOS systems; perhaps a thread on Discourse might be of more help.
I was able to reproduce your issue on Ubuntu 20.04. It seems this is . A few workarounds are mentioned in the linked issue.
It seems mimic just needs a proper wrapper: should give you some output.
Ok, I found a solution with inspiration. alsa-lib-1.2.4 doesn't containt but if i installed alsaPlugin (nix-build -A alsaPlugins '<nixpkgs'), this works for me : However, not really user friendly.
Describe the bug Because snappy does not install a pkgconfig file, you can't take snappy as a buildInput, packages will never find it. To Reproduce Expected behavior Metadata system: host os: multi-user?: sandbox: version: channels(seb): nixpkgs: Maintainer information: cc
I have opened a PR on the snappy codebase: It is waiting for review and then nixpkgs will need to be updated. Note how the PR has to handle the absolute path being configured in cmake by nix
has decided not to take the patch upstream, so I will work on adding the pkg-config file as part of the nix installation
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 .
Describe the bug librealsense cannot be built on/for aarch64-linux. I see that the derivation says it is not supported on aarch64-linux but I also know it is possible to compile the library normally on that platform as I have done it before. So I think its just a problem with the derivation for now. I am willing to help in the work to fix the recipe, and test the fixes, but I am relatively new to the nix language and build system. I have attached the error message I get, could someone point me in the direction I should be looking to fix it? To Reproduce Steps to reproduce the behavior: Screenshots 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 Maintainer information:
Hello! I tried it and got similar errors building graphite, though I can get it to build when I use the versions of the libraries so maybe that's a good place to start? I'm not sure what the issue is unfortunately.
I fixed the build of on aarch64-darwin and aarch64-linux in PR will not work on aarch64 unless somebody fixes the build of package on aarch64 theoretically should work, but in reality the build of which is a dependency fails on aarch64 Will you please open two new issues for and not available for aarch64? The build failures you see have nothing to do with librealsense.
Package name: paperless-ngx Latest released version: 2.12.1 <!-- Search your package here: --- Current version on the unstable channel: 2.11.6 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --