jiebi/CodeConvo huggingface dataset:
Is there anything presently blocking just getting julia 1.5 into nixpkgs? I don't care about ecosystem working with nixpkgs, just a good ol' fashioned julia install.
yes, see
If you just want Julia and don't mind about binary packages breaking you can just download Julia from the official site and patchelf it. On Sun, 4 Oct 2020, 09:32 Tyler Benster, <:
On the there was also the idea floated to patch to patchelf dynamically loaded binary dependencies.
Guix has a Julia package and it works quite well. Perhaps some ideas can be borrowed from there: It'd be really useful to get Julia working on Nix. It's the only big outstanding thing that doesn't work and prevents me from migrating some servers in my organization.
I tried to copy their expressions in and it doesn't work yet, but there's also another seemingly working attempt by at .
So, do we want anything else now that 1.5.3 is packaged (:greenheart: ? I think we: 't need clean up the expressions a bit - not use the file if it's not shared. I did (2) along with the julia_10 fix in As for (1) I will need a bit of feedback.
I guess some people like me still use julia_13 via test-disabling overrides, so a bit of time after 1.5 reaches channels for smooth transition could make sense?
Maybe backport 1.5 to 20.09?
OK so I disabled the tests for julia13 in and made the default there as well. All merged pull requests referenced here should be backported.
Synergy crashes without an X Display available, but the autostart option attempts to start synergy regardless of whether login is graphical or TTY. It would probably make more sense to spawn this after
(triage) status?
In case this is still relevant - would it make sense for those to run as user services instead to take advantage of recent changes merged in
I think this is probably still relevant, and I think your suggestion is probably a good one, . With this config: out of the box, I get the following: But if I kill the service and start the synergyc command manually as my unprivileged desktop user, it works just fine:
was looking to resume my work on espanso's (which has been somewhat impeded by ), and now I find that espanso no longer builds at all. As those issues haven't gotten much attention thought I'd reach out to to see if anyone can at least confirm (as my understanding is that the reproducibility on darwin can't be quite as good as NixOS -- especially when one ). Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thank you so much for the quick fix! I keep running into these issues on darwin, I really want / need to learn more so I can contribute back! Unfortunately I'm still getting a build error, which looks to be a sandbox issue: This seems to fix the issue: Could you take a look and if appropriate merge? Many thanks!
Rendering a project in Kdenlive with default rendering settings leads to the following error: Steps to reproduce the behavior: ( is the latest revision of at the moment of writing this) any clip to the timeline (for example, drag in an image) "Render..." "Render to File" You might need to use as your desktop manager to reproduce this issue. There is claiming that this crash doesn't happen on Plasma 6. I am using Plasma 5, but I am currently unable to verify if Plasma 6 would fix this issue (Plasma 6 is broken for me for unrelated reasons). Render should succeed. See issue for the previous instance of this problem. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Are you using the kdenlive matching to your desktop? Edit: nope, you are using the plasma 6 package. You want to use plasma5Packages.kdenlive.
is plasma6? Wow, that's quite a foot gun. Shouldn't it be called ? Also, fails with the same error.
It really should not matter, and will (once is entirely gone) be whatever versions upstream ships.
it seems that the problem either wasn't fixed or has resurfaced again? I was able to reproduce the exact same error with and (where is the latest revision of at the moment of writing this)
Please try again after the staging-next merge (which should make its way to unstable in a few hours).
I will. Could you explain why staging-next is relevant in this case, though? I am just curious. I checked using and in the github UI directly, and it seems that the changes from should be already present in revision .
staging-next reshuffles protobuf versions again.
I wasn't sure which staging-next merge you were originally talking about, so I tried the same thing with commits (current nixos-unstable), (current staging-next) and (current master) and I am still getting the same error. Can you reopen this issue, or should I open a new one?
Hm. Actually, I think that I figured out, what the problem is. It seems that actually saves some paths in .
For example, my had the following lines: Deleting the line fixes the issue, but then adds it back again with the new path, so it will almost certainly eventually break again. I am honestly not sure, why does do this, but we should probably either patch this behavior or report it upstream.
That sounds very wrong because you have defaults from two different kdenlive versions in there.
I can tell you that I've never touched prior to this debugging session. I didn't even know it existed. Those lines seem to be automatically populated on demand. Most likely, these lines were simply generated at different times, and so they picked up different paths to the "current" version of . Also, the fact that these paths are different from each other is mostly irrelevant in this case. The real problem is that they are cached once and aren't updated when a different version of is used.
Describe the bug fails to build on current master To Reproduce Steps to reproduce the behavior: a checkout of the current nixpkgs master Expected behavior Build succeeds Screenshots <details<summaryNot a screenshot, but build output </summary<p</p</detailsAdditional context The kind of error (not including a needed header) seems to be an upstream bug for me. Metadata Please run and paste the result. Maintainer information:
Fixed by upstream in See my PR
Opensnitch requires system- file to be placed under /etc/opensnitchd/system- to be able to enable its System rules/Firewall settings to be active and changeable. Steps to reproduce the behavior: to OpenSnitch Statistics to the button on the left navigation window just right of Rules/System Rules. cannot change the firewall settings there. the service complains about it. Being able to access that windows' setting. These screenshot shows the corrected version of the window. ! ! Can be solved temporarily with the nixos config below (the file can be found in opensnitch github repo): <!-- 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.
Explain this line to me My hardware wouldn't be "asus" how do I find the directory for that?
the latest change to the opensnitch module (in unstable) has again a change for deploying the system- file, see the file comes from the opensnitch package and is linked to /etc/openstnichd/system- configuring this file is currently not supported. what would your use case be?
Describe the bug Test  is broken on Master To Reproduce Steps to reproduce the behavior: Expected behavior For the test to pass Additional context I've bisected the problem to this commit:
Thank you for opening this :sparkles:
In that case let's it.
That is weird. How does depend on rsyslog?
This test is kind of flaky, there's some chance I incorrectly bisected it?
I'm bisecting again starting at
going to plug :grin: At a glance I don't see rysyslog having any relation, and likely if the tests are flakey enough bisecting can't give reliable results.
I didn't use that tool because I was bisecting by running the test thrice and only if all fail considering it a bad commit :P
cc. maybe add a flag to :P
That kind of unforseen usecase is exactly why nix-bisect is not just a tool, but a library ;) So you could write your own bisect script in python (a much more pleasant experience than doing so in bash). I may add that feature to the CLI at some poing though, since its probably a pretty common usecase. would probably be a better name, since we really want a minimum number of tries. Feel free to file an issue against :)
I tried bisecting again, but I think this result is also nonsense:
Core of the issue seems to be this:
I don't know &ndash; locally I'm getting this :arrow_up: error even on which (I tried several times).
Careful (manual) bisect lead me to a surprising result: I'll try a few more experiments now. Many my steps failed for other reasons (e.g. libselinux not building), so I suspect that's where you were led astray. I did 2-3 attempts on every step to be surer, but I found no non-determinism on my machine.
I had quite a few steps where the first attempt at building failed, but the second one succeeded, I was bisecting manually with this:
I re-confirmed that reverting that commit atop master () fixes the test for me. (Still no idea why so far.)
cc for the linux config change
Narrowed down just to the kernel option. I don't know... maybe the JIT has some bad interaction with the VM.
Describe the bug To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information:
Project description Mathematical modelling software Metadata homepage URL: source URL: license: gpl2 platforms: cross-platform
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
I marked this as stale due to inactivity. &rarr;
NixOS unstable is affected by on Wayland. Steps to reproduce the behavior: signal-desktop on Wayland. No crash. Add any other context about the problem here. Please run and paste the result.
I am also getting a crash every once in a while on startup. Starting it again works so far and it seems stable after that. Don't know what to do about that.
I've fixed this locally by using the following overlay:
Apparently, Signal beta works again on Wayland.
Just adding a data point. Having Wayland disabled actually caused more bugs for me. Re-enabling Wayland via 's overlay helped fix my compositor crashing whenever I clicked on certain UI like "preferences" in the "file" menu. Currently running: with set to and have the following env variables set:
I just discovered and i can't use it on NixOS Pulling image seems good Trying to run image fail because it try to mount some specials folders The : Trying without mounting folder fail because it can't find Start a shell with still fail because it can't find Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(pinage404): channels(root): nixpkgs:
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 .
It could still be important.
I marked this as stale due to inactivity. &rarr;
Describe the bug While the configuration contains no settings related to LVM, is launched during boot, and so on, and the "lvm2-activation-generator: lvmconfig failed" message is logged in the journal. Expected behavior At least, does not produce error messages. It might be better if the service is not activated if the system does not use LVM at all. Additional context may or may not be relevant. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(omasanori): nixpkgs: Maintainer information:
cc
I'll try to find some time to look into this, as I might be responsible for this.
I got this error when running in the console. It just froze, didn't reboot. Hitting enter put me back into the shell. Doing shutdown -h now worked. Very strange ..
I strongly suspect that your freeze was not caused by this warning message.
Yeah, so this was most likely caused by , which combined with the rest of leads to systemd being aware of lvm2 things. lvm2 was already in and for anything that's not a container, before this, but now it's also in . As for why this happens, it looks like it's , which fails when does not return what it expects. Since we do not install the default lvm config, it fails like so: The easiest solution to this is probably to install the default config file to . There is a problem with that though. If we use , we cannot use anymore to append any settings. We also cannot "copy" the defaults into e.g. with , because that would be import from derivation. So the remaining option is to simply set some default settings, which also kind of sucks, because then we need to track upstream on those, but it's probably our best option. If you have any other/better ideas, I'd gladly go for those, but if nobody does, I'll go with specifying some defaults, in a few days.
+1 to importing upstream defaults as it seems the safest option if it tracks upstream properly, even though it will certainly increase the maintenance cost.
I also would just create a default configuration if it is not possible to disable lvm2-activation-generator somehow if lvm is not used.
Detecting if lvm is used sadly isn't trivial.
, CVSSv3=6.5 (nixos-21.11, nixos-unstable) A NULL pointer dereference issue was found in the block mirror layer of QEMU in versions prior to 6.2.0. The pointer is dereferenced in mirrorwaiton_conflicts() without ensuring that it's not NULL. A malicious unprivileged user within the guest could use this flaw to crash the QEMU process on the host when writing data reaches the threshold of mirroring node. Scanned versions: nixos-21.11: ; nixos-unstable: . Cc Cc
This is fixed on master since we have QEMU 6.2.0. It's not included in 6.1.1 though, so needs to be fixed on stable. Probably after since it'd be a merge conflict.
Package name: osu-lazer-bin Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 2023.1026.0 Current version on the stable/release channel: 2023.511.0 <!-- 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 Note for maintainers: Please tag this issue in your PR.
The auto-multiple-choice program does not start, on NixOS 22.11 : Steps to reproduce the behavior: auto-multiple-choice auto-multiple-choice that it's not really working A clear and concise description of what you expected to happen.
I'm trying to reproduce, without success so far. Did you install AMC from , or through nix-env/nix-shell? (I'm rebuilding my system without the global AMC to test those cases, but it triggered a full Emacs recompilation which will take some time)
I installed it using nix-env. I'll try with the systemPackage option later today. I'm using wayland with sway.
I don't think that's the issue there (also I have the very same setup, on unstable though). This message means that the program can't find the perl source module of its gui component, which indicates an installation/path issue.
I really can't reproduce, sorry. Please let me know how things go with . Does exist?
Yup, it exists : After switching with the system version, I get the same error. After updating the channels () and rebuilding () I still get the same error.
Is there a /lib/ directory at your FS root?
Yup, there is, it contains a subdirectory (modules) which is empty. Deleting it makes auto-multiple-choice work as expected.
Ok, I believe that's the root issue, but I'm not sure how to fix this. If it's fully empty besides subdirs, you should just delete it.
Does that mean that auto-multiple-choice is also broken on non nixos installations ?
No, because on those, the Perl modules AMC needs are on the global , or , or whatever. The NixOS package, OTOH, is a self-contained, so-called "portable" build where everything (libs, executables, doc…) lives in a single directory. Your issue comes from the fact that AMC tries to detect such a portable build by first looking for a global , then defaulting to dir iff the former doesn't exist: I think I can solve this by just changing the default lib dir, please don't close the issue.
will fix this.
reverted the "fix" to that issue, because it broke everything else (my fault). For the time being you need to make sure there's no on your system for AMC to work.
No problem, good luck with that !
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]:
This looks to me like the compiler wrapper isn't respecting and/or , and it's inappropriately passing the libunwind shared object. I don't have immediate time to investigate further but did discover this minimal reproducer:
looks the same as which is due to (search path prefers .so files with ). i agree that passing in libunwind unconditionally seems not good. if one builds libcxx with the linker script at will result in but we don't so we add unconditionally. it is not clear to me why c code needs libunwind.
<!-- 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 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: dstp <!-- The current version can be found easily with the same process than 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: 0.3.0 desired version: 0.4.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: I'd love to update the package myself without annoying you :) If there is a documentation about how to upgrade packages, i'd love to learn it and try my best next time, thanks in advance!
For simple version updates, I update the version number and to get the new hash I run (in the nixpkgs top directory): For go packages, we also have to update the hash, that one is tricky, and what I do is to try to build the package. That will fail, but it gives us the new hash, I don't know a better way. There is also a bot () creating PR for those simple version updates. It uses repology to find the latest version:
Awesome, thanks!
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.
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]:
In executing ibus-setup-hangul, got this error message: .nix -rebuild switch ibus-setup-hangul in a shell System: NixOS 17.03.1584. (Gorilla) Nix version: 1.11.11 Nixpkgs version: 17.03.1584. Sandboxing enabled: build-use-sandbox = false
Might be due to . What was the reason to remove from dependencies?
I think that was because I noticed that it is propagated from some other package, but looking at this now it doesn't seem to be the case. I'll investigate this today!
This seems more deep than I thought. The bug is two-fold: script is not patched as needed for Python scripts; should be propagated from . However, only its output is propagated, so it's not as a Python library. I can fix the first one but not sure what to do about the second -- maybe we should change behaviour of this propagation in some way.
The same problem appears with anthy, and directly adding the same pyEnv to buildInputs like did in ibus definitely fixes the build fails (tested with both anthy and hangul), but the python environment isn't propagated by itself.
Steps to reproduce the behavior: ocf-resource-agents. Relevant: () Looks like a GCC update deprecated , which is used by ocf-resource-agents. This also causes the pacemaker build to fail, due to the circular dependency. system: host os: multi-user?: sandbox: version: nixpkgs: (I'm using commit ) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I fixed it in my flake for pcs / pacemaker here: