jiebi/CodeConvo huggingface dataset:
Describe the bug Libvirt usually handles virtual network devices, interfaces, bridges and also the DHCP range. This seems to be broken. To Reproduce Steps to reproduce the behavior: a VM connected to the default network 't get an IP Expected behavior DHCP is working Screenshots If applicable, add screenshots to help explain your problem. Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Likely fixed by If you are fine with rebuilding libvirt your could use this locally. Alternatively if this is your home computer and you are in a safe network you could temporarily set to disable your whole system's firewall but this is not recommended. Edit: Rebuliding should be really quick (on a decent laptop)
Thanks - looks right. I will try to use the overlay first.
I think it's related... When I try to start a VM using Gnome-boxes or Virtual-manager with VM using bridge this error happens:
have you updated to the latest nixos-unstable version? This issue itself should be fixed and you should probably create a new issue if your problem persists.
it's still happening, even with the last version.
then you should probably create a new issue as I don't think it's the same issue. It may still be related so maybe reference this issue. There wasn't an error with the original issue I think
Describe the bug results in the following error on : Seems like the writer expects to be executed in a stdenv environment to find instead of knowing the path to it. To Reproduce Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (rust maintainers)
This should work as long as GHC is proper dep, because libiconv is propagated.
This should be independent of GHC entirely: only relation to GHC is probably that I mistook the error for one coming from GHC initially, but this is not the case ( doesn't allow building the writers individually what confused me).
I'm facing this issue trying to build from on macOS Big Sur. (wasmer is a dependency of FastAPI, which is the package I'm actually interested in) <details<summaryLogs:</summary</details
I think adding to could also help there.
Fix here:
The last fzf update in nixos-unstable breaks certain bash-completions, for example git. This happens since Then try bash completion for git. My looks like this <details</detailsThe regular bash completions for git should work. As a fix I found this old issue in fzf To test this, I tried simply replacing with an edited version that puts the fzf eval after the bash completions code (and before the alias declarations). This fixes the issue. However, I am not sure how to solve this cleanly in NixOS. The bash completion code is inserted using but I don't know how to enforce ordering so that the fzf eval happens after the completions. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for the report, I started a PR super-seeded by fixing this issue. As what I found this issue was already there previously but as most people didn't had the full integration enabled it didn't triggered the issue.
Is there any progress on this? Solution PRs seem to have been closed?
The fix already got merged and will be soon on unstable - otherwise you might cherry-pick/overlay it.
Cool, so we can close this presumably?
I looked at this in master and now we're basically back to how the fzf module was previously, right? So then it should still be an issue when enabling .
Alright, so now I'm just gonna try my luck with a PR. It definitely works for me and makes a difference.
The laptop screen freezes with the current contents (systemd startup messages) at the point starts. Nothing else visible happens. I can switch VT's back to text consoles, switching back to VT7 again just freezes the display. All the normal processes seem to be running, but they don't draw anything. I'm using gnome and wayland. Updated to today's () Booted previous system generation, was working again. With some excellent help on Matrix from I have confirmed that: building from previous branch revision () and switching (no reboot) makes gdm work again. building from current revision () with also works. building from the previous revision with that line fails to evaluate, because the multi-version package change isn't there yet. So / are clearly implicated. K900 suggested raising this as an upstream Mesa bug. I had some issues registering there, but may try again later and will add a link here in case system: host os: multi-user?: sandbox: version: channels(root): channels(dan): nixpkgs: bits of relevant config: note that the displaylink driver is not in use (no device connected) at this point, it's all on the internal display only. Hardware is a Dell XPS 13 9360
If gdm is enabled with Gnome enabled, gdm will crash and not load into the login screen after logout or reboot. This is due to gdm using wayland as the default. Once wayland is disabled in gdm, the login works. Steps to reproduce the behavior: channel nixos-unstable, "sudo nixos-rebuild switch upgrade-all" with Gnome enabled and gdm enabled in will hang at the gdm check point. gdm wayland in and the reboot works but with Wayland not working. Reboot into gdm with Wayland <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I just hit the same issue. After updating to latest nixos-unstable, the boot hangs just before login screen I think this is related to , at least the workaround posted there worked for me also
Would be relevant with a machine without AMD graphics and without KDE? As, I am running Intel's build in graphics and using Gnome. Also, I did find a "workaround" by disabling wayland in gdm then nixos-unstable will boot.
I managed to work around this issue with on GNOME Wayland. Graphic card: Intel Xe Graphics (TGL GT2)
Totally worked! Thanks and ! Should I leave this open as this is a bug or a new config that needs to be applied to 23.05?
Describe the bug A clear and concise description of what the bug is. Rambox apps cause rambox to crash when attempting to upload a file. It gives the message: To Reproduce Steps to reproduce the behavior: rambox rambox in terminal any app that has file upload functionality (I tested Google Messages, Element, and Slack) to upload file Expected behavior Rambox apps should be able to upload files from filesystem Additional context I've seen from browsing other issues that this has been solved before for riot-desktop at first by adding gsettings schema to the package wrapper but currently fixed by using in electron. However, for some reason this did not fix the issue in Rambox. 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. these paths will be fetched (0.05 MiB download, 0.28 MiB unpacked): /nix/store/d43v6bx7r6fcaq3fbbfd5mwh1f5s7rmg-bash-interactive-4.4-p23-dev copying path '/nix/store/d43v6bx7r6fcaq3fbbfd5mwh1f5s7rmg-bash-interactive-4.4-p23-dev' from ''... system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Add wrapGAppsHook to
, CVSSv3=9.8 (nixos-20.03, nixos-unstable) CVSSv3=7.5 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.
needs 1.3.2 for CVE-2016- needs 1.3.1 for CVE-2016-3092
After enable HBase module , and rebuild. The service unit cannot start, it says JVM option not exists. Steps to reproduce the behavior: HBase by adding config . , it should be failed. shows VM option is Unrecognized. I found the same issues on the StackOverFlow, it seems jre 15 dropped the option: I fixes this by adding this line, but it should be fixed in module. I can do the fixes PR if you want. Maintainer information:
go for it. I'm also not maintaining this anymore, so may be best to also remove from .
Project description This project is used by programmers looking to explore the Rust programming language and learn more about it while doing exercises. These exercises are meant to get you comfortable with the language itself and its features. Metadata homepage URL: source URL: license: MIT platforms: MacOS, Linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Interesting package request. But does it make sense given that you need to modify the rustling files in order to use it? I personally used the that's included in the project. which I think are removed in the new release :(
Take a look at . The maintainer of rustlings explained why the was removed.
TL;DR: All required files are embedded in the binary now. The exercises are dumped on initialization. I am the new author. If you need any help, don't hesitate to ping me. Note that a new version was published yesterday.
I'm using Nix 1.9 on OS X 10.10.4 (Yosemite) with the package. It installs without issues, but when I try to use the tool I get this error: I'm using the unstable channel:
Hrm, I get (also Nix 1.9 and OS X 10.10.4) It seems to be an issue with the shebang in as seems to work just fine. I don't see anything obviously wrong with though... (PS hi long time no see :)
I just hit this issue too. Weirdly, just running from different shells would give different errors (I use fish normally, so it's always an early suspect around problems like this). I would get an error like got from , and an error like from . When I change my to this: Everything works, and in all shells the same way. Is this a valid fix? (By "works", I mean I get , but maybe that's a separate issue, or due to a lack of familiarity with Elixir/Erlang...)
Nice catch. Doing will generate a new app skeleton if everything is working as it should.
Turns out I just forgot to put the at the end of my fixed version, so no args were getting through :P Is what I mentioned above an acceptable fix? If so, I can submit a PR.
I have installed sage thorough the nix package manager and it is the only thing I use nix for so it is entirely possible I am doing something stupid and wrong. I have the latest from here build When I try to get to the index for all entries which is located on my computer, I get a page with very few entries (see the screenshot) below ! While I expect something more like Compare /nix/store/r77k14kq9iw92w32bd9sny7d98dbrq32-sagedoc-9.6/share/doc/sage/html/en/reference/genindex- and A full fledged index. I want to use to generate a docset which I can then search following the answer here I can build a docset after copying the reference directory to somewhere I have write access to. However when I try to search there are almost no results and I think this might be responsible. Please run and paste the result.
I'm not very involved in sage maintenance these days, I mostly contribute by reviewing and PRs every now and then. They are probably better qualified to help you :) Maybe we should drop me from the maintainers list, or at least change the order to reflect reality?
Sorry for the bother then! I was actually going by the information here which looked outdated but I didn't have any better idea.
Thanks for the report! Will take a look today.
Thanks a lot!
No bother :) Thanks for the pointer, I have updated the maintainer information there.
I have an EPSON DS-530 scanner, that I can't use to scan anymore. Prior to upgrading to NixOS 22.05, it worked perfectly fine. Steps to reproduce the behavior: scanning as follows: a sheet of paper in the scanner and scan it using utsushi, scanimage, simple-scan, xscan, … scanner pulls the paper through, but this does not result in a scanned document with any of the programs I tested. The (probably) relevant lines of the full log output (see below) are: The page is scanned successfully. The symptoms look exactly like those described in . The full debug output is as follows: <details<summaryLog</summary</details
I just noticed that utsushi reports version 0.65.0, which doesn't match the supposed version 3.65.0 in the channel. Though it seems kinda plausible to me that utsushi just reports major version 0, as the rest matches?
Trying to debug this further by scanning with , I got the following lines of output: The line () looked suspicious to me. I attempted to narrow this down further using strace: Interestingly, this refers to a file called , that supposedly should exist in the / package's directory, but doesn't as the strace indicates. The only reference to this that I could find is in the . If not provided with a different engine as a command line parameter, it should just use tesseract. This in turn led me to in the utsushi codebase, which calls the filter. I stopped my investigation there for now. Maybe can give more context, as they came up in many of my searches regarding this.
can you try adding to and see if that works? It looks like calls out to and expects to have it in , so probably falls back to ?
can you check if fixes this?
Thank you but unfortunately this didn't help. I'm still seeing references to in the where I suspect that I should see references to tesseract instead. It would be sufficient for me to deactivate all the postprocessing that happens, but this doesn't seem intended feature in utsushi :/
As I had amassed quite a backlog of documents to scan, I started a nix shell with the utsushi version I used previously, using the following command: This works.
However, this is only a workaround, as this means that I need to use the interface for scanning, which is somewhat cumbersome to use and this also pulls in a lot of old packages via the dependencies. I'd be happy to try out anything at this point.
Hey, I started looking into this again and noticed that in you switched the sources from the to the repository on gitlab. I'm wondering what the reason for this was. Do you remember?
I think back than the maintainer of utsushi suggested this. Imagescan just tries to mirror the driver as it is release by epson, while utsushi contains community maintained patches, but unfortunately no clear versioning scheme.
I just bisected the changes and it turns out that is indeed the commit at which utsushi stops working for me.
That is unfortunate. Maybe we should offer both utsushi and imagescan as packages, than the user can choose.
This could be a solution. I am not sure yet, whether the problem may also stem from one of the patches introduced or the command removed in that commit. As I am getting a error, I think it possible that the problem may be related to the imagick (or a similar) dependency.
It turns out, that this problem had a . Adding the following line back to the derivation makes utsushi work again. PR adds it back to the derivation and fixes scanning on my machine.
Describe the bug After upgrading to nixos-20.03 and enabling pulseaudio support I started experiencing the "Gah! tab crashed" error too often, to the point that browsing sites with certain types of embedded media (mostly audio/video) instantly triggers the error (e.g browsing ). While troubleshooting this I also noticed that opening crashes not the tab but the browser. On the console I can see: This crash is present with default options (i.e. and ). In addition, after several crashes Tor asks to start in "Safe mode". I'm not sure what safe mode disables but it allows opening without crashing and/or triggering the segfault. This seems to hint at some interaction with external libraries and my assumption that this is somehow related to pulseaudio. To Reproduce Steps to reproduce the behavior: the URL will crash Notify maintainers Metadata The following expression was used to enable and : and installed with .
Can you try with override ?
This helps. On a quick test I didn't see any "Gah! Tab crashed" error and works fine.
It should be off by default then, it used to work :(
Could this be triggered by a missing or mismatched library? I also only started noticing this after enabling pulseaudio system-wide. If this helps diagnosing the issue...
I think it's simply because the firefox jemalloc is incompatible with the hardened allocator. firefox has to be built with for that to work. I wonder why this appears to have worked before; maybe the tbb build has changed. Relevant mailing list thread here (fair warning: it turns into a not-so-productive exchange after a few messages):
I think that at this point it'd be appropriate to revert the commit that hardened alloc support, with a note as to why, maybe opening an issue to track work (if anyone cares) to make hardened malloc work with tbb/firefox.
I'm not into the differences/advantages of each allocator. In this case I have the user hat on and unless there's a critical aspect of relevance I'm happy to trade that in favour of a functional browser.
Project description A cross platform front-end GUI of the popular youtube-dl written in wxPython. This makes the awesome commandline tool usable for more people! Most repositories use the package name youtube-dl-gui, so i recommend to use it tool. Schould be quiet easy to package. Metadata homepage URL: source URL: license: The Unlicense platforms: unix, linux, darwin, ... (Python)
Sadly the project is not maintained anymore and has issues. We shouldn't add it.
There is an active fork:
The systemd initrd (or stage1) does not work with a volatile root when there are 9p mounts present. A result of this is that VMs built with nixos/qemu-vm do not work when disabling the (and thus running on a tmpfs) and using the systemd initrd. Create a test that sets these options: The test should work just like the test works in who has identified the root cause (an ordering issue where the tmpfs is mounted before the 9p infrastructure is up) and found a hack around this behaviour.
I this to the board because it will require a test when it is fixed.
As a side note, we should consider using to implement volatile root with systemd stage 1.
As far as I can tell we could only do this if we mounted under .
So this works probabilistically. Sometimes it succeeds, and sometimes it fails with for one of the 9p file systems.
Ok this patch seems to fix it Which begs the question... why does it ever work, with or without volatile root? EDIT: Oh I bet it's a race condition caused by not depending on . In order for to appear, virtio modules need to have already been loaded. So, because gets mounted first, and needs to wait for to appear, that means virtio modules are definitely already loaded before any children of are mounted. And indeed, switching from to just does the trick as well.
When opted in to the latest Steam Beta (version ) starting Steam fails with the error Looking at the log output, it looks like it fails to load : Steps to reproduce the behavior: into Steam Beta steam Steam runs ! stdout when running : Please run and paste the result.
i'm able to reproduce this as well
In case anyone experiences this and wants a temporary workaround, you can opt out of the Steam Beta by running
I think this might be due to a change in nixpkgs rather than steam, since this works for me on: But it breaks for me when I update to:
Building with running with and using the bad commit is part of cc
Please test .
Specs-nvim does not work in Neovim 0.10 and the author has not updated the upstream version. The derivation should point to the updated fork instead: Steps to reproduce the behavior: specs-nvim with Neovim 0.10 specs-nvim errors Should I have used the out-of-date packaging report issue template instead? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
no pb for me. Feel free to submit a PR. Pinging as he might know better.
What does no pb mean? I'll make a PR
I guess that it means "go for it, let's switch to the fork".
crashes, even when installed into the system. Steps to reproduce the behavior: shell "nixpkgs#gnome-frog" -c frog Program doesn’t crash Please run and paste the result.
Interestingly, I was able to build and run the app in commit (I also rebuild it with just to double check). ! Though, it does fail to build and run in recent revisions (at least in ). It needs to apply to be able to build. Running it however gives me the following error: Not exactly familiar with GTK development but I'll see what I can do. Thank you for reporting!
Running it on my end gives me another error:
frog+main+Application' doesn't support property gobject-introspectionbuildInputsnativeBuildInputswrapGAppsHookGITYPELIB_PATH`, resulting in typelibs being picked up from the environment.
Thank you for the explanation, . Simply putting into did build and run the app (at least in the recent commits).
Describe the bug Shell with and will fail to start with a following message: This is an issue because depends on so they would be always included to the shell started by nix-review. I noticed this issue while reviewing . I suspect this is caused by . To Reproduce Steps to reproduce the behavior: This does not reproduce on release-19.09 Expected behavior Shell will start, shell prompt will appear. Metadata Please run and paste the result. Maintainer information: cc
I'm getting "CLASSPATH: unbound variable" since updating master an hour ago from last Sunday, and reports "JAVA_HOME: unbound variable" started happening while working on eleven hours ago.
The IGV package freezes and crashed when a file dialog should open (open file, save as, etc.). Steps to reproduce the behavior: igv: igv "File" -"Load from File.." application crashes The file dialog should open and allow me to open a file. If I open igv through the terminal, then this error is shown: This error is the same as previously reported issues for other application, e.g. I'll shortly open a PR with the same fix. I'll rather do that in the PR with the fix. Please run and paste the result. NA
Running shows a version that is different from the one in the Nix store file name. Run The output will look something like: Notice the store path says while the command show that the version is actually 0.19.12. The two versions match. I ran into this because I tried to use and got the error "has no attribute 'replace'": According to this part of the API was released at least in version 0.19.16, so it would confirm that the version I have installed is in fact 0.19.12. <!-- 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]:
PR only updated the version and not the hash.
Thanks, well spotted! when I merely update the hash I end up with this error:
hey, after having had just a quick look, I've opened I haven't tested though, could you help with testing and let me know if that works ?
ah, I've just had a compilation failure. This is because the maturin used currently is 1.3.0 and polars requires 1.3.2. the bump is also going to require a maturin bump. Are you interested in taking care of it ? Otherwise I should be able to make some time at some point.
Thanks for this! I might try it out in the next few days :)
alright, I've tried with maturin 1.3.2, but I still get a rust compilation failure. I've checked their MSRV and it's only 1.71. So I don't know what could be causing this compilation failure. if you have any ideas, feel free to re-use anything from that PR without any need for attribution. I'll be happy to help merge a solution.
might be worth setting the version back to in the meantime so the package will build on a cache miss.
so version has been set back to 0.19.12. I have finally had some luck in compiling the latest polars version in if anyone is interested to test the PR, feel free to post a comment. I'm running a nixpkgs-review to check what the update breaks