jiebi/CodeConvo huggingface dataset:
While going through the documentation I came about a that explicitly requires matplotlib with the TkAgg backend. I tried to generate a nix-shell with matplotlib and tcl/tk and tkinter. However, the script does not execute and instead I get the following error message: In a simplified form: Start nix-shell:Start Python:Try to import matplotlib, configure the backend, and import parts of Tk:Observe the following error message:System: NixPkgs on openSuse 13.2 (Harlequin) (x86_64) Nix version: nix-env (Nix) 1.10 Nixpkgs version: "16.09pre83147." Matplotlib Maintainer:
Judging from the matplotlib expression we don't build against tcl/tk.
I made an attempt to build matplotlib against tcl/tk with the following patch: Unfortunately, compilation fails with the following error message: The linker cannot find the tcl/tk libraries. The linker flags are quite off: They include and the like. This must be due to matplotlib's own build script, as no such flags are set in my bash environment and is executed with the flag anyway.
CoolerControl does not detect Nvidia GPU when enabled via options Steps to reproduce the behavior: GPU with proprietary drivers (version 555, but might not matter) spits out error about missing and CoolerControl to detect Nvidia GPU ! Logging output: If I manually stop the systemd process and start it detects the requested binaries correctly, which makes me think that the coolercontrold binary just doesn't search the correct paths. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The tools should be on PATH if you check the generated service file. And restarting the daemon would support that I think, since it shouldn't pick up any new paths from the env AFAIU. So might not like whatever state your system is in whenever first launches? I sadly don't have any nvidia system to test this with… I think if you try something like this you could delay the service startup to check if the above guess is correct? (Or override the package with an overlay and patch it into the service that way if this doesn't work the way I think it does)
Restarting the service does not work, as that throws out the same identical error. After adding that to my config, rebuilding and restarting the service, I get this output: which looks like sleep succeeded, but not sure how that would help so I did this instead: Which I either did wrong, but it seems to print the GPU fine? But that made me realize one difference. I am on beta drivers, but as per your code block, you pull in the stable ones... Could that be the distinguishing factor? In which case, maybe it might be better if it pulled in the field rather than hardcode to stable drivers?
Oh sorry, I thought that read "restart coolercontrold". Maybe. Likely.
Build . Because this hash was updated not long ago by , I think the package may still need some refactor? We may also expect to get everything settled. <!-- 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. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Huh, weird. When I wrote that hash worked fine. I wonder what changed?
Yes I was wondering about the same thing because I knew you updated that hash not long ago. Does that hash depend on any online resources that may change or on other packages? If not, then this package may have some obscure reproducibility issues. This package is so complex that I cannot see what it is doing there at glances.
Yes, but it is my understanding that its pulling resources that are hash-fixed in bazel-land, so iiuc they shouldn't change unless changes... but then again clearly i have some misunderstanding of the behavior here
builds fine for me on .
Is this issue still reproducible for you?
Yes. I just tested on master branch at commit . The exact same error.
Are you using any overlays? Have you set any nixpkgs flags?
I have a local clone of nixpkgs at , and I ran the command Does it depend on my nixos system config?
iirc it will depend on eg but i'm not sure about the nixos system config. What commit of nixpkgs are you on? Does it reproduce on the latest master?
I don't have . I said I was on , which is the latest.
Latest (at the time of writing) is does building on that commit work for you?
That commit does not build either.
Hi, I'm also having the same issue with same hash mismatch. I tested the build on two different systems. If you happen to have a system in which the build runs fine, would you mind sharing the output of the derivation: so I can diff it? I could also send you mine.
Should be fixed by
Fixed by
Hi everyone, sorry to reactivate this issue but if I check out the current master branch and run , I end up with the same error as above (just with different hashes). Can anyone reproduce this behaviour?
what hashes are you seeing now?
I can rebuild the package just fine...
! These are the hashes I get after running on the current master (). I am puzzled by the fact that this exact commands builds fine for . My expectation would have been that the behaviour should be the same if we are on the same platform (I am on x86_64-linux). Do you have an idea how we can dig deeper into this?
I also just stumbled upon this issue and I do get the exact same hash mismatch as :
Well, my only hypothesis is that the bazel dependencies derivation is nothing more than non-deterministic :'(
Does this still build for you? If it does I can offer to send you an archive of my jaxlib with the changed hash so you can run a diff to find out what is wrong. (Or the other way round ofc)
Yes, I have tried once again right now and it works fine... Sure, Send me what you have :)
Alright, I've updated today and will build against nixpkgs . My machine will probably take some time to completely build it though, so I'll post back once it's done.
I'm getting a similar problem when I'm trying to compile . The commit is from the branch. The commit was the only commit I found after going through multiple issues and threads which worked on my system. I have also observed this issue when compiling (), so the issue of build failures due to bazel hash mismatch isn't just limited to . So, I don't think that this issue has been properly resolved yet.
I'm not sure if this is helpful--or noise!--but I just hit a similar issue with (see below for output, repro, and system info).
Btw we're tracking the hash issues in .
systemd seems to use the term split-usr to refer to an attribute of a system, where: is a mount point. is not mounted "at boot". Since systemd v248, support for a split-usr system is deprecated: While don't seem to mention a formal removal of support of split-usr, it seems that . According to : It seems that if is a mount point, this unit calls with on it, regardless of whether it is already mounted — making the assumption that it had already been mounted "at boot". When I installed my first NixOS on my workstation, I made a filesystem for each path under . This let me customize options per directory as I wished, both at install and later on. ZFS's sharing of storage space between filesystems in the same zpool takes the cost out of being "generous" with the number of filesystems. I didn't know that is merely that happens to be generated at boot. I also didn't know that systemd deprecated split-usr. So I did not mark as . The system built successfully and booted successfully. Except for an error in the logs: The failure seems to be due to the attempt to remount using with the option a non-mounted filesystem — . is later successfully mounted along with the rest of the filesystems. Since systemd seems to expect that if is a mount point it would have already been mounted "at boot", I would expect NixOS to: 's to by default, . to build when 's is (that could be ). Understanding this error took around three hours of collaborative debugging with the tremendous help of A workaround is to set for , or to not have a mount point at all. The suggested solution (expected behavior) is with the goal of sparing all future users an investigation of this error. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Not sure who to mention. Please ignore if you no longer wish to be involved. If you happen to know who should be mentioned here and is not, please comment mentioning them. Please run and paste the result. Maintainer information:
gentoo notes this in their wiki as well
ping a couple people who might care: and probably others.
Describe the issue In the opencv build for mac, why is off by default? What needs to be done to enable it? (either development work, dependencies that aren't yet nixpkgs, or, if possible, how to manually override the argument and simply set to ) To Reproduce See above Expected behavior There may be a good reason it's disabled, so I can't say that I'd expect videoio to be enabled by default. Notify maintainers Metadata Please run and paste the result. Maintainer information:
It was removed here 15 months ago: See this PR: due to apple removing most of QTkit in 10.12 Brew does not use this option. You can use an overlay or a nixpkgs checkout with this patch to build with videoio The following will drop you into a nix-shell with the patched opencv, which you can use for testing. I'm not sure if it builds. FWIW, I get the following build failure which indicates the upstream issue might not be resolved, or we're missing some thing in our derivation.
I was originally attempting to use an overlay. After getting nowhere, I made a , which is what redirected me to the nix build. So if you want to help me close that thread, that'd be awesome cause both me and the person that helped me still don't know how to access/change the from an overlay.
Describe the bug After electron 12 came out, adding in home-manager succeeds, but trying to start the app fails mentioning a missing javascript function from an older version of electron. To Reproduce Steps to reproduce the behavior: to home-manager's app from terminal with Expected behavior Expected the application start as it had before. Additional context I was able to get it working locally by providing an overlay to home-manager: I would have created a PR myself, but I'm still new to nix and not sure entirely how to require a different electron version in the package derivation. Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(jon): nixpkgs: Maintainer information:
thanks for catching this! Just fixed in the PR above.
Steps to reproduce the behavior: So when I wanted to dig deeper, with I'm trying to recreate with a toolchain that's on hydra so I don't have to compile GCC for myself (twice!) Please run and paste the result. In particular, is pinned to:
Diff-ing the two files, I get: I suspect the problem comes from in the that isn't present in the . I wonder why so many differences are present though? I've confirmed this by adding to the derivation, but again why are the differences present? Even if they have been helpful to track this down
I suspect there were impurities in your environment but the difference is still weird. I don't know why would be there but not Adding to the mingw build in
Fail to connect to a l2tp + ipsec VPN after putting in all information. This happens on both Latest Gnome ISO and after NixOS installation. Message received on Gnome Desktop: Connection Failed Activation of network connection failed Steps to reproduce the behavior: Live Gnome ISO. l2tp + ipsec (strongswan) details in NetworkManager. on VPN connection. There are several fixes listed in this issue I was able to fix the problem by creating the file AFTER creating the connection and failing to connect once. (I also created the file BEFORE creating the connection, but that did not fix the issue.) After successfully connecting, this was content of file include The following is the failure output from journalctl From ISO system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
I was also having issues and tried the above suggested by and was able to connect only after a failed connection !
This seems to fix the bug May we have this to the default package?
Fix in
Phew, a big title! Trying to write down as much as I can before I forget. First, the last part: If doesn't exist, will show failing like: fixes this problem. NixOS should probably create this file. I'm not sure if this file should be writable or not, when it exists, I have only ever seen it contain: I don't know what writes that there. Now for can't edit L2TP VPNs, but (GUI) can, even though nm-applet doesn't work under sway. If you see this in the system logs: try enabling "legacy proposals" in nm-connection-editor's IPSec Settings and try again. system: host os: multi-user?: sandbox: version: channels(root): channels(grahamc): nixpkgs:
Side note, how do I know for sure fixes it? I erased my dozens of times nailing it down, reproducing it to exactly this.
I think the strongswan module creates that file and the actual L2TP plugin appends that line to this file.
Nice find that the strongswan module does create that file! I don't have the strongswan module enabled, it seems something else in the stack would periodically create this file?
I'm not sure what does create it eventually, but it appears the plugin expects the file to exist so we should just do exactly that. It doesn't help that it expects it to be mutable, so maybe we can handle this within the NM module to add more secrets. Though it would probably duplicate what the strongswan module does.
^ does this make sense to you?
So I just remembered about this module I have: maybe instead we should have the networkmanager do when it detects the l2tp plugin but I am not sure how to do that. Maybe we would need to introduce a new option in networkmanager to add the nm-l2tp plugin and create the file. I tend to connect physically to the private network and only as a last resort rely to nm-l2tp since it tends to not work regularly and I am not sure if it's blocked by the network or some l2tp breakage.
We could add an option to networkmanager in the same way there's one for strongswan there
Was there ever any follow up on :
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
i guess, it's still relevant, maybe not so urgent. this helped me big time:
I marked this as stale due to inactivity. &rarr;
I just ran into this on 21.05. Seeing a log like this: <details<summaryjournalctl log when starting vpn</summary<pre<codecharon[2059]: 00[CFG] loading ca certificates from '/nix/store/va01sq5aqg6p7yakvpg2zlnsdj4pm9dj-strongswan-5.8.1/etc/ipsec.d/cacerts' charon[2059]: 00[CFG] loading aa certificates from '/nix/store/va01sq5aqg6p7yakvpg2zlnsdj4pm9dj-strongswan-5.8.1/etc/ipsec.d/aacerts' charon[2059]: 00[CFG] loading ocsp signer certificates from '/nix/store/va01sq5aqg6p7yakvpg2zlnsdj4pm9dj-strongswan-5.8.1/etc/ipsec.
d/ocspcerts' charon[2059]: 00[CFG] loading attribute certificates from '/nix/store/va01sq5aqg6p7yakvpg2zlnsdj4pm9dj-strongswan-5.8.1/etc/ipsec.d/acerts' charon[2059]: 00[CFG] loading crls from '/nix/store/va01sq5aqg6p7yakvpg2zlnsdj4pm9dj-strongswan-5.8.1/etc/ipsec.d/crls' charon[2059]: 00[CFG] loading secrets from '/nix/store/va01sq5aqg6p7yakvpg2zlnsdj4pm9dj-strongswan-5.8.1/etc/ipsec.secrets' charon[2059]: 00[CFG] expanding file expression '/etc/ipsec.secrets' failed charon[2059]: 00[CFG] opening triplet file /nix/store/va01sq5aqg6p7yakvpg2zlnsdj4pm9dj-strongswan- failed: No such file or directory charon[2059]: 00[CFG] loaded 0 RADIUS server configurations charon[2059]: 00[CFG] no script for ext-auth script defined,
disabled charon[2059]: 00[LIB] loaded plugins: charon unbound pkcs11 aesni aes des rc2 sha2 sha1 md5 mgf1 rdrand random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey dnscert pem openssl af-alg fips-prf gmp curve25519 chapoly xcbc cmac hmac curl attr kernel-netlink resolve socket-default connmark forecast farp stroke vici updown eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-radius xauth-generic xauth-eap xauth-pam dhcp counters charon[2059]: 00[JOB] spawning 16 worker threads ipsecstarter[2058]: charon (2059) started after 660 ms charon[2059]: 11[CFG] received stroke: add connection '-ebef-4658-8991-' charon[2059]: 11[CFG] configuration '-ebef-4658-8991-' charon[2059]: 13[CFG] rereading secrets charon[2059]: 13[CFG] loading secrets from '/nix/store/va01sq5aqg6p7yakvpg2zlnsdj4pm9dj-strongswan-5.8.1/etc/ipsec.secrets' charon[2059]: 13[CFG] expanding file expression '/etc/ipsec.secrets' failed charon[2059]: 14[CFG] received stroke: initiate '-ebef-4658-8991-' charon[2059]: 15[IKE] initiating Main Mode IKESA -ebef-4658-8991-[1] to 123.111.111.111 charon[2059]: 15[IKE] initiating Main Mode IKESA -ebef-4658-8991-[1] to 123.111.111.
111 charon[2059]: 15[ENC] generating IDPROT request 0 [ SA V V V V V ] charon[2059]: 15[NET] sending packet: from 192.168.1.11[500] to 123.111.111.111[500] (304 bytes) charon[2059]: 03[NET] received packet: from 123.111.111.111[500] to 192.168.1.11[500] (204 bytes) charon[2059]: 03[ENC] parsed IDPROT response 0 [ SA V V V V V V ] charon[2059]: 03[IKE] received NAT-T (RFC 3947) vendor ID charon[2059]: 03[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID charon[2059]: 03[IKE] received draft-ietf-ipsec-nat-t-ike-02n vendor ID charon[2059]: 03[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID charon[2059]: 03[IKE] received draft-ietf-ipsec-nat-t-ike-00 vendor ID charon[2059]: 03[IKE] received DPD vendor ID charon[2059]: 03[CFG] selected proposal: IKE:AESCBC128/HMACSHA196/PRFHMACSHA1/MODP2048 charon[2059]: 03[ENC] generating IDPROT request 0 [ KE No NAT-D NAT-D ] charon[2059]: 03[NET] sending packet: from 192.168.1.11[500] to 123.111.111.111[500] (372 bytes) charon[2059]: 04[NET] received packet: from 123.111.111.111[500] to 192.168.1.11[500] (356 bytes) charon[2059]: 04[ENC] parsed IDPROT response 0 [ KE No NAT-D NAT-D ] charon[2059]: 04[IKE] no shared key found for 192.168.1.11 - 123.111.111.
111 charon[2059]: 04[ENC] generating INFORMATIONALV1 request [ N(INVALKE) ] charon[2059]: 04[NET] sending packet: from 192.168.1.11[500] to 123.111.111.111[500] (56 bytes) NetworkManager[2277]: initiating Main Mode IKESA -ebef-4658-8991-[1] to 123.111.111.111 NetworkManager[2277]: generating IDPROT request 0 [ SA V V V V V ] NetworkManager[2277]: sending packet: from 192.168.1.11[500] to 123.111.111.111[500] (304 bytes) NetworkManager[2277]: received packet: from 123.111.111.111[500] to 192.168.1.11[500] (204 bytes) NetworkManager[2277]: parsed IDPROT response 0 [ SA V V V V V V ] NetworkManager[2277]: received NAT-T (RFC 3947) vendor ID NetworkManager[2277]: received draft-ietf-ipsec-nat-t-ike-03 vendor ID NetworkManager[2277]: received draft-ietf-ipsec-nat-t-ike-02n vendor ID NetworkManager[2277]: received draft-ietf-ipsec-nat-t-ike-02 vendor ID NetworkManager[2277]: received draft-ietf-ipsec-nat-t-ike-00 vendor ID NetworkManager[2277]: received DPD vendor ID NetworkManager[2277]: selected proposal: IKE:AESCBC128/HMACSHA196/PRFHMACSHA1/MODP2048 NetworkManager[2277]: generating IDPROT request 0 [ KE No NAT-D NAT-D ] NetworkManager[2277]: sending packet: from 192.168.1.11[500] to 123.111.111.111[500] (372 bytes) NetworkManager[2277]: received packet: from 123.111.111.111[500] to 192.168.1.11[500] (356 bytes) NetworkManager[2277]: parsed IDPROT response 0 [ KE No NAT-D NAT-D ] NetworkManager[2277]: no shared key found for 192.168.1.11 - 123.111.111.
111 NetworkManager[2277]: generating INFORMATIONALV1 request [ N(INVALKE) ] NetworkManager[2277]: sending packet: from 192.168.1.11[500] to 123.111.111.111[500] (56 bytes) NetworkManager[2277]: establishing connection '-ebef-4658-8991-' failed NetworkManager[2283]: Stopping strongSwan IPsec. charon[2059]: 00[DMN] signal of type SIGINT received. Shutting down ipsecstarter[2058]: child 2059 (charon) has quit (exit code 0) ipsecstarter[2058]: ipsecstarter[2058]: charon stopped after 200 ms ipsecstarter[2058]: ipsec starter stopped nm-l2tp-service[2039]: gdbusmethodinvocationtake_error: assertion 'error != NULL' failed NetworkManager[954]: <warn[.6803] vpn-connection[0x24c60a0,-ebef-4658-8991-,"my-l2tp-vpn",0]: VPN connection: failed to connect: 'Message recipient disconnected from message bus without replying' .nm-applet-wrap[1470]: Failed to show notification: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Notifications was not provided by any .service files </pre</code</detailsRunning the following command fixed my error and allowed me to connect: The networking part of my only has .
This still appears relevant in 21.11. Adding this (as mentioned above) to my config appears to get an L2TP and IPSec VPN working with NetworkManager:
Still relevant in 22.05. I am confirming that with a clean install, trying to set up L2TP/IPsec VPNs fail with the following indicator: fixed the issue for me straight away as well.
Fix in
Describe the bug Thunderbird 78.2.1 is working. master (Thunderbird 78.2.2) has rendering issues (see screenshot). Most buttons do not react to clicks and the menu is also not reacting. To Reproduce Switch to the mentioned commit and rebuild. Expected behavior Normally working thunderbird. Screenshots ! Notify maintainers Metadata
This was also a bug in Ubuntu, it was fixed there with:
Upstream bug appears to be
Btw temporary workaround would be to switch to thunderbird-bin-78 if you are not opposed to binaries
Steps to reproduce the behavior: 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
might be fixed by confirmed. closing.
Hello. I'm new to NixOS, and also facing this problem: How can I apply that fix? I just updated my NixOS system flake to latest version: But still getting error during system rebuild:
try and update again, the fix is in unstable now.
When adding a text in Gimp, a green border is visible: ! However, I would expect something like that: ! After , a on both Gimp (need 3.10.30) and (need 1.18 apparently). However, in NixOs Cairo 1.16 is used instead, so I guess it is necessary to upgrade cairo. Steps to reproduce the behavior: some text on gimp, say white text on black background I expect Cairo does not have maintainers so I'm pinging random people that contributed: Running NixOs with KDE Plasma.
Looking at no distributions ship 1.18 yet. I wonder why. Is it an API-breaking release?
Proposed cairo one-liner backport as
The 1.18 branch yet. We could switch to development snapshots (1.17.x) if there are more concerns. But cherry-picks will probably be enough for now.
The above PR solved the issue, thanks a lot! For people wanting to test before it gets into unstable you can do: but it takes a few hours to compile until Hydra compiles it.
Actually I'll maybe let it open until it's merged to unstable (for now it's in stagging) and backported.
GitHub should auto-close once the fixing commit reaches master branch. Though I'm not sure if that wasn't broken by closing and reopening.
It's reached all channels.