jiebi/CodeConvo huggingface dataset:
Package name: imhex Latest released version: 1.27.1 <!-- Search your package here: --- Current version on the unstable channel: 1.26.2 Current version on the stable/release channel: 1.19.3 <!-- 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. --Note for maintainers: Please tag this issue in your PR.
I'm trying to build octave with QT5 and with GUI (of course, when I try to build it with GUI, right?). Unfortunately, after the build: Apply this patch: and then system: host os: multi-user?: sandbox: version: channels(m): nixpkgs:
I just noticed that I do not even get the GUI feature when building octave from nixpkgs (neither nor has a GUI).
Pinging: touched the package recently, is the maintainer of the package.
I’ll try to have a look when I have some time. I’ll let you know what I can achieve.
Here is what the configure script says:
yes, I got that and I fixed it. See for my attempt to build with Qt5 (which succeeds, but starting octave with gui fails - see PR).
Project description A modification of the Mesa Vulkan overlay. Including GUI improvements, temperature reporting, and logging capabilities. Metadata homepage URL: source URL: license: gpl3 platforms: linux
I tried myself at this and have a working package now for NUR based on But I haven't yet figured out how to create a 32 and 64-bit version. Depending on the game both are necessary. To just get a 32bit version I currently just use: instead of just
It might make sense to just build the 32bit and 64bit packages separately and then merge them together in a wrapper.
okay I did something similar, though not with a wrapper which is probably a little hackish I am not sure: but this allows me now to use mangohud with 64 and 32 bit applications
That seems like a reasonable solution, although it is a little bit hackish. I'm running into a similar issue with , and it's not really clear what the best approach is. recommended keeping the two builds separate for vkBasalt. However, to ensure we can install both builds we would have to do extra patching, and use separate names for the 32bit and 64bit build. Users might also expect to have both builds in one package like on other distros. I'm leaning towards something like this or like what I've done in my .
was just released but that changed quite a few things around. instead of using two different binaries it now uses  to decide where the 32/64bit libaries are, but it seems to me that this always expands to 'lib' on NixOS This is what I have so far. Having to ignore collisions is also not really that cool. Well having a running 0.4.1 version would be nice enough, just thought I write about this somewhere
The commit in question:
I marked this as stale due to inactivity. &rarr;
Still important to me.
For some reason, rasdaemon doesn't work. dmesg: systemctl: Steps to reproduce the behavior: rasdaemon should work. Unfortunately, ras-mc-ctl doesn't check if the daemon is working so it took me some time to discover that the daemon actually doesn't work. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
perhaps some build-time hardening is messing with it?
Looks like the latest tagged version is broken on AMD because it doesn't include Now I'm running from the latest commit and it works fine
oh, thanks for finding a solution! i'll open a PR with that patch in a few hours unless you beat me to it :)
adds that patch
is meant to show the current timezone. It doesn't. (I have some reason to believe that this is connected to Steam game failures, but still working on that. In any case...) Set time.timeZone to anything other than UTC. Rebuild your system. Run The output will be in UTC, with no timezone shown: lists only UTC. System: 17.03pre92039. (Gorilla) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: 17.03pre92039.
I think this is because of this line: We can patch this to not check prefix, but still wouldn't work. For discoverability of timezones we can add to and look for them in but I'm not sure this is a good idea.
See ,
When used through the command line, complains about imports and fails. <!-- 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]:
I've opened but haven't had the time to test it quite yet. If you get around to it before me feel free to merge it
I suggest another fix in
Contributors working on improving the nixpkgs manual would be redirected to the . This section is not up-to-date with all the syntax features supported by , forcing contributors to look for use examples over the whole manual. The same markdown syntax is used to write and generate the NixOS manual. However, this manual does not make any mention of the supported syntax. This makes it hard to contribute to the NixOS manual with relative isolation from the nixpkgs manual. Update in Nixpkgs manual to include reference material and examples on all the syntax features supported by . Link in Nixos manual for completion. [x] remove references to in the . : [x] remove references to in the . [x] add a redirecting to the syntax section in . [x] add reference to lack of support for [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support () () )
I'm reporting this for a friend of mine who wanted to install NixOS and ran into this issue. I hope that's okay. The problem is: fails if you have in your host's kernel config (which, I think, is reasonable if you're compiling it yourself and don't need swap). I took a cursory look into and saw that it reads from . This fails, apparently, because the file doesn't exist on systems without swap support. Can this be easily fixed by assuming there are no swap devices if the file cannot be found?
I'd say already assume this, but don't handle it gracefully.
Describe the bug On current nixos-unstable Scipy fails to build with a segmentation fault during testing: To Reproduce Steps to reproduce the behavior: the following as Expected behavior Should not segfault during test. Additional context SciPY seems to build just fine on current 20.03 release. Notify maintainers cc , Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(ente): nixpkgs:
Also fails with
Particular stacktrace is:
I believe the fix is contained in: and upstream tracking issue is: and Debian issue:
Opened to bump openblas to a version with that fix
fixes this for me - can you confirm?
builds for me
Works, thanks!
This still affects . Is there a simple fix we can backports (either in nixpkgs, or here locally)?
Backport openblas updates:
Thanks, I’ll try that. Would such a backport be eligible to go to ?
I don't really do backports, but since it fixes something known to be broken I assume it would be fine.
Pull request should target not .
ArmCord's wrapper seems unable to launch under Wayland, always chooses to launch under Steps to reproduce the behavior: sure and are properly set: Armcord: . ... 's on XWayland (as shown by ). I expect it to launch with Wayland instead of XWayland. Custom wrapper: Test case: Log output: <!-- 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]:
probably need makeShellWrapper instead of makeBinaryWrapper in the package
Thanks for jumping on a PR will review this evening.
Project description Fragments is a modern, responsive and graphical Gnome bittorrent client Metadata homepage URL: source URL: license: gpl3 platforms: linux The new version of Fragments depends on libutp which hopefully gets merged soon. I've opened a pull request for it . for Fragments.
We have transmission and torrential. Maybe that's something for you.
That's true but Fragments is a really neat, easy and modern looking torrent client. It has an adaptive interface which would also work quite well on mobile devices, for example NixOS mobile :+1:
I'm trying to use GZDoom, but the Vulkan backend isn't working. No errors, but it will silently fall back to OpenGL. Apparently this is the case if GZDoom can't find the correct Vulkan drivers. I have a Radeon RX 5700 XT, so my GPU definitely supports Vulkan. Steps to reproduce the behavior: basic without any mods <kbdesc</kbdthen <kbd~</kbdAt the end of its loading it should say what renderer it is using This is a screenshot of it running with Vulkan from someone else's system: ! This is a screenshot of what it looks like when it's using OpenGL: ! Note the lines. GZDoom uses Vulkan Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible- . nix-build '<nixpkgs' -A ... --check --keep-failed You can use to analyze the differences in the output of the two builds. To view the build log of the build that produced the artifact in the binary cache: nix-store --read-log $(nix-instantiate '<nixpkgs' -A ...) Seems to be a file ordering issue while generating : vs
Looks like this list is generated with the standard Ruby function, which in 2.x leaves the sorting up to the filesystem, but from 3.x onwards itself. So perhaps we should just update to Ruby 3.x. In general 2.7 is in mode, so it will only receive security updates and we should probably plan to move things to 3.x
The version of pillow rmfuse uses is vulnerable to CVE-2022-.
Since rmfuse is packaged using poetry2nix you are basically the only one willing to update it or its dependencies. That's problematic given that you don't do so even two weeks after being notified of a vulnerability.
I don't think interacting in this way is very constructive. There are different points of view regarding packaging Python packages, that's it. That an issue like this does not get picked up is not strange, people are typically busy. If you like to I suppose you could add the CVE to the expression. Whether the CVE can be considered a security issue in case of rmfuse should be considered as well.
Why not? I'm just articulating a problem with the way rmfuse is packaged right now that is obviously an actual problem. It's not technical though, just organizational.
vkBasalt is a Vulkan post processing layer to enhance the visual graphics of games. Metadata homepage URL: source URL: license: zlib platforms: linux
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 .
default: cc Until then, just edit manually.
Remember you can do this too: = [ "/ip4/0.0.0.0/tcp/4001" "/ip6/::/tcp/4001" ]; It seems reasonable to have this default, however, since the nixos module has no way of getting the daemon to reset options when the user removes an explicit option from Incidentally, some config needs special handling, since it can't be set without re-initializing the leveldb, etc. I don't like the idea of having to duplicate every default setting into a , but I guess there's no other way until the ipfs devs make the daemon's config less stateful. I would prefer they move this type of runtime config into command-line args whose absence indicates that defaults should be used. Perhaps we should file that upstream.
The script should report all sources used to build a package. It currently lacks support for patches? If we run find-tarballs on nethack, we should find the patch defined in nethack named we should get the url to download in the output, along with its name, hash and type.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I found why patches are skipped, they have "postFetch" attribute that has to be run to obtain the same file expected by nix. By applying this diff, patches are included in the result, but they won't have the expected checksum before applying postFetch on it. I don't know how to apply postFetch on the result right now.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
is built without X11 support on darwin because the Meson build file disables it. The GTK build system was changed to Meson by , and it removed the configure flags that enabled X11 on darwin: But the file of GTK3 disables X11 support on darwin, and : should provide X11 support on darwin. I was trying to fix on darwin and I found that is marked as broken () because of a missing GKT/X11 header. It seems that it is the same problem that motivated to change Vim to use "gtk2" (same missing header ). Maintainer information:
In that case I'd probably take the discussion upstream.
It was disabled in 3.24.9 by commit , without much explanation. But that commit never landed into master and GTK 4.x does build with X11 support as I understand ( and ).
Neovide fails to install via Steps to reproduce the behavior: up a terminal (currently I'm on aarch64-darwin, but I think this should be reproducible on different platforms) (or use home-manager/nix-darwin/nixOS) for it to give the mentioned error Neovide should install and run as expected <img width="1398" alt="image" src="https://user-"(text form) Might be a result of this: Please run and paste the result. Maintainer information:
Can you try this?
The meson build doesn't compile the schemas, opting to do it instead in a package shell script. Unfortunately it seems that compiling the schemas aren't enough to make all the extensions work. In particular at least and still won't work (seems to fix though). With the schemas installed Tweaks simply complains that the extension is incorrectly installed. complains about lacking any typelib file for . I'm not sure how well these extensions worked before 3.28, but a report on irc indicated that at least worked before. cc Run Tweaks on nixos-unstable, try to enable eg. the extension under or . Running a schema fix on top of system: host os: multi-user?: sandbox: version: channels(hed): channels(root): nixpkgs:
The extension works for me when I manually change the directory structure to: As for the , I removed from dependencies so that might explain this failure. The extension should probably be fixed like .
You're able to switch switch themes in in Tweaks? Might be something wrong on my end. I'll submit a PR fixing the schemas at least.
Testing out a fix for .
Hmm, I can enable it but the theme switching does not work. I seems to require the extension schemas in when running Tweaks. Maybe it got picked up from global for bash users, but the option was always disabled for me with fish.
We might want to add as a dependency to Tweaks so that it could work for non-bash users. Then we will need to fix the schemas: the schemas in and find a hack similar to to add the schemas path to the extension. like the following to put the schemas where extensions can find them and add symlink for Tweaks. same thing as the second point but accomplished by patching files.
Your suggested fix worked for at least :) I went with basically adding the code from to to fix the schema problem. Generating the directory structure you quoted above seems the most sane and keeping with upstream. Tested things out in a vm with bash, and didn't seem to work there either. So not sure if the problem is non bash. Anyway, adding to fixes , so I think that's appropriate. I should've got everything now, will submit a PR :)
I think it only works in bash and globally installed packages or something.
flameshot has two backends, one that works in KDE, and one that works in wlroots-based compositors, but the flag USEWAYLANDGRIM must be set in order to enable it. Steps to reproduce the behavior: to use flameshot in wlroots-based compositor like sway It works [nix-shell:~]$ env XDGCURRENTDESKTOP=sway XDGSESSIONDESKTOP=sway QTQPAPLATFORM=wayland flameshot gui flameshot: error: Unable to capture screen flameshot: error: Unable to capture screen Wayland does not support QWindow::requestActivate() flameshot: info: Screenshot aborted. Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The flag upstream:
It turns out that this flag is not yet available in a release. To use it, I created the following package override: and now flameshot works! For home-manager I also the following:
Not sure I'd call this a bug if there's no release with this code, though it seems like it will be some time before the next release:
I can confirm that the overlay above works for me. There's a small caveat: should be available in the PATH, otherwise the setup will be a little more janky.
Whether or not there's a release, it's still a bug. There were more attempts to fix this 2-3 years back, but as you can read in that linked issue, the authors are currently not working on updates. Since there's no official release, it might not make sense to issue an interim package update, but as long as I have my working flameshot, I'm happy. I just wanted to share this with others who run into the same problem
I hadn't noticed that... I've just updated buildInputs (to add grim) and removed grim from my default home-manager environment... I think that should take care of it, but I'll test to be sure.
After using for awhile, I can confirm. You need to add grim into your environment in order for this to work consistently.
I can't seem to get that to work on GNOME see
Yes, grim is for wlroots-based compositors, not mutter.
Unrelated to this issue then?
Describe the bug doesn't work, either on or . It works on and I have a bisect running at the moment (on some slow hardware, so the results might take some time). It fails with this log: To Reproduce Metadata Maintainer information:
The first bad commit could be any of: jfsutils: fix build with glibc=2.28 ppp: fix build with glibc=2.28 oathToolkit: fix build with glibc=2.28 postfix: fix build w/glibc 2.30 libffi: only run tests on musl targets stdenv: rebuild aarch64 bootstrap files with gcc8 expect: remove hack for aarch64 build expect: fix aarch64 build seasocks: fix build w/glibc-2.30 bzip2: fix aarch64 build xnbd: fix build w/glibc-2.30 glibc: remove outdated patches rr: 5.2.0 -5.3.0, fix build w/glibc-2.30 diod: fix build w/glibc-2.30 libunistring: disable tests distrho: fix build w/glibc-2.30 glibc: depend on libidn2 (and libunistring, transitively) stdenv bootstrap: disable dejagnu tests gcal: fix build w/glibc-2.30 sharutils: fix build with glibc=2.28 drbd: fix build w/glibc-2.30 gnum4: fix build with glibc=2.28 xen48: fix build w/glibc-2.30 gnulib: - mono: fix build w/glibc-2.30 glibc: 2.27 -2.30 foundationdb61: fix build w/glibc-2.30 spaceFM: fix build w/glibc-2.30 cpython: fetch darwin- to nixpkgs xen48-{light,
slim}: fix build bootstrap-files: bump WIP Merge branch 'staging' into glibc230 Ignoring 'fix build with glibc' commits libffi: only run tests on musl targets stdenv: rebuild aarch64 bootstrap files with gcc8 expect: remove hack for aarch64 build expect: fix aarch64 build bzip2: fix aarch64 build glibc: remove outdated patches libunistring: disable tests glibc: depend on libidn2 (and libunistring, transitively) stdenv bootstrap: disable dejagnu tests gnulib: - glibc: 2.27 -2.30 cpython: fetch darwin- to nixpkgs xen48-{light,slim}: fix build bootstrap-files: bump WIP Merge branch 'staging' into glibc230
stdenv bootstrapping of 32-bit ARMs is (hopefully) being fixed right now:
Thanks for the hard work
I don't use at all, but I'm getting this error when I'm trying to rebuild my flakes (same happens when I run ) and also I don't really use it or install it Steps to reproduce the behavior: or Expect or to work fine I ran before running <!-- 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.
By grepping through nixpkgs, depends on by default. (see ). However, abook is only lists linux as supported (Im not sure if this this is just nixpkgs or abook in general) Up until , lbdb has not depended on abook by default. Perhaps a mistake was made while refactoring. In the meantime, you can just override the package.
The Linux stdenv sets But that flag is specific to GNU strip, and LLVM's strip will fail if passed it. Conveniently, we silence all errors from stripping, so this has gone unnoticed until now: I noticed this while trying to fix . One of the reasons it doesn't work is that it has in , and strip should be removing that reference but isn't. What I'm not sure about here is the best way to fix this. There's nothing platform-specific about this option, so it shouldn't live in the Linux stdenv. (Other platforms like NetBSD use GNU binutils by default.) Ideally it would be a conditional in the strip setup hook, but we don't really have a bash equivalent to . So where (in Nix) should we check this and set the variable? cc
With what we have at the moment, I can only think of hacky workarounds like checking if ends in . However such an approach (and even checking ) is actually incorrect: and don't have to be matched, e. g. with as linker and GNU bintools is quite common actually. Looking at prior art in nixpkgs, I'm quite convinced that the cleanest solution for now would be to bite the bullet and extend to also wrap . In fact, we already seem to have a strip wrapper for darwin.
Hmm, I don't like the idea of globally adding a flag only to remove it again in a wrapper. Another idea I had was to do this in the definition of make- — the hardening flags are precedent for doing manipulation of environment variables for setup hooks in there. We could add an isGNU attribute to the possible values of , and use that? I don't much like this idea either, but I like it better than adding the flag globally and then wrapping to remove it. What do you think?
Since this flag is unconditionally in general, I think we can just remove it from the linux hook and instead add it in the binutils-wrapper. This should also solve the issue of this being binutils-specific and not linux-specific AIUI.
Oh, you mean wrap GNU binutils' strip to add this flag? That sounds fine to me.
If I understand correctly this is now done: