jiebi/CodeConvo huggingface dataset:
Package name: astro-language-server Latest released version: 2.14.2 <!-- Search your package here: --- Current version on the unstable channel: 2.10.0 Current version on the stable/release channel: None <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm on it ^^. I've got a working version. Gonna soon open a PR :+1:
Steps to reproduce the behavior: floorp Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi, Please elaborate - there does not seem to be any actual build failure here. What's the actual error? Are you sure your build machine has enough resources? A browser build is pretty demanding and can take even multiple hours on low-to-mid-end machines. Can you please also post the complete derivation log, as obtained using ?
I have the same problem (with floorp and floorp-unwrapped). Here’s the error: ! That feature was removed in February, so either update the qcms crate to 0.3 or downgrade the rust compiler version (1.76 could work).
is the log in the link not enough ?
Oh, I see, Github just truncated the file in the UI. That's what you get from hosting projects on crappy, proprietary software .. Pointing out the exact error too from the get-go would have been helpful in any case. Anyway - seems it broke with a recent rustc upgrade in nixpkgs. This is already fixed with 11.14.1, as it updates the firefox base source. See .
Okay, I will host my opengist instance for the next time ;) Thanks for your prompt response, waiting for your pr to be merged.
Any ETA on the PR merge?
Floorp is now in version 11.14.1 on unstable.
When installing a PWA using the Floorp browser (experimental toggle in settings), the installed desktop file uses /usr/bin/floorp as the path for the browser to run said PWA. Steps to reproduce the behavior: Floorp experimental PWAs in settings a PWA, e.g. Github or Excalidraw the newly spawned PWA window to launch the same PWA from your DE's application launcher The PWA opens. ! , using flakes, installed via <!-- 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]:
Thanks for reporting! As well as the upstream report! I can look into it what we can do as I get time. But as I'm the only maintainer for Floorp and currently pretty much out of time due to university and $dayjob, I cannot promise any timeline unfortunately. But happy to review patches, of course, if you'd like to fix it yourself. Can you provide such a generated file for further investigation?
sure, one such generated desktop file with the example of excalidraw can be found (github doesn't allow for drag and drop of .desktop files)
Hello! I don't have experience maintaining and modifying large packages like Firefox (floorp), and I currently don't have much free time. However, I've discovered how floorp generates the .desktop file for PWA applications: Maybe it will be helpful to you.
Thanks, that is indeed helpful! Should be relatively easy patchable by us then, from the looks of it.
upstream has and now it will use the path it was in at the time of creating the PWA. It may not be too big of an issue if what they say about fixing it in the next version is true but now the patching will probably fail.
Panel applets are being picked up from environment variable in and a completely hardcoded path in . First, we will need to patch the latter manager to use an environment variable as well. Second, we will need to do something similar to what . Or better, create  derivation. Originally posted by in
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 .
I'd like to tackle this, do you have any pointers? We need to get it to pick up at least right?
Package name: kitty Latest released version: 0.29.2 <!-- Search your package here: --- Current version on the unstable channel: 0.29.2 Current version on the stable/release channel: 0.28.1 <!-- 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.
inadyn enabled via doesn't cache the discovered IP address. Therefore every time the service runs it forces an update with the DDNS provider. Enable inadyn service, e.g.: Review the service logs and observe that it forces an update with the DDNS provider every time it runs, even when the IP address is the same. Notice the cache directory is empty. With the above config there should be a file created after the first run with the IP address as contents. When the service runs again at the specified interval and the IP address is the same, it should not update the DDNS provider. N/A The relevant service definition is: According to the env var is the absolute path defined by , so it is not . Therefore the command line is setting inadyn's cache directory configuration to , which doesn't exist, and it silently ignores the missing directory. should then be: Manually overriding is working for me. <!-- 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]:
thanks for the investigation, this sounds right to me! Would you mind opening a PR doing the proposed change, and link it from here? Happy to take a look :+1:
Thanks for the report. I won't be able to make a PR for a couple of days so it would be great if could. I think this should also be backported to 24.05.
fails to run most basic commands when installed via nix, due to an error seemingly related to it's vendoring of some dependencies. On a NixOS machine or Darwin with Nix installed, run: <details<summaryPEXVERBOSE=9 nix shell -c pex</summary</detailsA pex-managed python repl should open, same behavior as in a venv. For comparision: <details<summarynix shell nixpkgs#python3 -c sh -c "python -m venv ./venv; ./venv/bin/pip install pex; ./venv/bin/pex"</summary</detailsthe site-packages path where pex lies is in the /nix/store, so read-only. however, the the vendored dependencies are included in the closure; exists and includes attrs, pip, etc. maybe could help us interpret the error and/or how to debug this efficiently? :) some simple commands such as do work. same commands run fine in a venv on the same machines using the same python intepreter. same symptoms on NixOS and when installed via nixpkgs unstable on darwin. the tempdir path mentioned in the error message is writeable, but non existent or cleaned up. the alternative script/entrypoint shows similar symptoms: <details<summaryPEX_VERBOSE=9 nix shell -c pex3 lock create requests</summary</detailsHope you don't mind the pings (maintainer) (done multiple recent updates) (pex developer)
NixOS is pretty exotic in my world. Can you confirm that I can use a container to emulate this? I assume I can, but just to check. I'll be back at a keyboard August 3rd to repro, but I expect the workaround for now is to set PEX_ROOT somewhere writable. Pex does try to detect the default is unwritable and fall back to tmp, but perhaps all these measures are foiled in this environment.
wow, that was fast! :) Should be able to emulate in a container or almost anywhere you can get a recent nix with flakes enabled running. Let me know if can assist you with that!
(contact info in profile) Many environment variables like and are different when run via nix (symlinks to /nix/store), but "~/" and other filesystems are not namespaced or sandboxed in any way here. is writable by my user. I've tried with PEXROOT set, but that didn't incfluence the output. Going to have another look tomorrow, but it's quite late already here in CEST.
I don't think notifications are sent for linked issues; think I found a fix in Thanks to for pointing me into the right direction
Ok, this works perfectly fine in nixos (N.B.: I 1st used the vanilla image which is not sandboxed and everything worked fine; so I went through a bit of extra effort below to enable sandboxing in the image and prove it out to see if the sandboxing behavior was relevant to repro): So I'll try to repro using .
Ok, after following the multi-user install instructions for the command here: and enabling flakes, etc - I do repro: So, for someone with knowledge of nixos vs nix shell vs flakes, this would presumably mean something. I'll continue to dig in my shell to see what's up.
Alright, Pex 2.1.141 should fix. Please let me know either way
Sandboxed builds do not work inside Docker as we can't create required namespaces from an unprivileged container.
I've tested a build against your tag and that works just fine on NixOS (with sandboxing enabled).
Ok, great. I used in addition to mounting in that custom nix config.
Steps to reproduce the behavior: -rebuild test on settings.datadir = "/mnt/garage0"; resolves fine Tested on nixos24.05 but code of the module is unchanged in nixos_unstable. I'm using flakes as well Please run and paste the result.
Looks like doesn't apply, maybe should tinker a bit on my own
It looks like the option type was adjusted, but not the other code in the module that checks that value. Shouldn't be too hard to fix.
Ffmpeg 6.1 supports vulkan video, but it is not enabled in the default version of ffmpeg, it is only enabled in ffmpeg-full. The default version of ffmpeg should support vulkan video so that applications like mpv can use it. Arch enables vulkan by . Vulkan video already works with amd GPUs using ffmpeg-full with this command: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This seems reasonable. I'm in favor.
EDIT: Error on my end, skip reading this. Hm, your command doesn't work for me on Mesa 23.3.3: Another aspect to consider is closure size.
If you haven't tried already, can you try with something in h264? Vulkan video currently only supports h264, h265 and av1(experminental), and only if you gpu supports them.
Indeed it's h.265, let me try h.264. This looks like a generic VK issue though.
As suspected, this happens on h.264 too.
Do you have multiple GPUs in your system except the amd one perhaps? This chooses the first one arbitrarily.
Same error for all.
Then I am not sure about what's causing it, that's the exact same error I receive when using ffmpeg 6.1 instead of ffmpeg-full 6.1.
Uhhh about that... So and that commit didn't seem to have been pulled into this brain thingy of mine... It works as expected with ffmpeg-full.
Project description Formatter for typst. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ...
There is no CLI:
Looks like the author use .
looks like it is still a WIP in
what do you mean wrong default branch? Hi there, I wasn't sure there was interest for a cli, I'll merge the cli in a few days, want a ping then?
I merged my change, it should be good to package!
has renamed the project from typst-fmt to typstfmt in
The build attribute of the last state of the package contains a expression to substitute tool names with its Nix packages. The scrip substitutes with the git package, which includes and similar regex used in the script. Script : Packaged script in my nix store: Steps to reproduce the behavior: the package and inspect its output The regex keys aren't substituted by the git binaries store location. <!-- 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]:
In the pre-start script for , we symlink the template from the nix store into : However, if changes are made to CUPS via the GUI -- for example, enabling network access -- this symlink is overwritten with a plain file. And it contains a line with paths into the nix store. This effectively freezes some version of the cups binaries into this config file, which is no longer managed by nix. As a result, CUPS can break, e.g. when deletes the referenced store paths. For me, this meant nothing would print, and I started seeing this error in : Manually editing to update the store paths on the line (while the systemd service was stopped) got printing working again for me. I guess we could make the pre-start script do this (with a sed or something), but that seems kind of hacky ... cc commit seems especially relevant here. System: Nix version: Nixpkgs version:
Hm, maybe the right approach is to make just put in the template, and then have it also ensure that points to the correct location in the nix store? Then CUPS can write whatever other changes it wants to its config file, while the nix expression continues to have control over the "final destination" of the path ... ?
I think we want Nix to take priority here because that's what would be expected of declarative configuration and what's already done in other places. So as a quick fix towards this we can force replacement by symlinks. This should also be documented. However, we can leave some option (like currently exists for users) that reverses this and instead makes just insert and other required options. The best of both worlds, of course, would be to split the configuration into generated by Nix and values changed in CUPS on top but I doubt this can be implemented. Thoughts?
For the record, I had the same problem in OctoPrint service. It was solved by writing a small piece of software for updating YAML trees (like in Nix) and making "patch" current configuration with Nix-overridden values. Works perfectly but it would be much more difficult in CUPS ( is some kind of ad-hoc mix between XML and custom plain format).
Yeah, I don't see any directive on the manpage for .
:-( Overwriting the config file on every restart of might lead to confusion if folks are trying to use the GUI to get things configured the way they want. In particular, when I made changes in the GUI to enable remote access, it modified some of the stanzas that're currently hard-coded in at So I'm not sure how I would preserve that under this approach. (I tried to just set via , but that wasn't enough -- I don't really understand why ...)
Its man page says: ... but a bit of googling didn't turn up any pre-existing programs designed to read / write that format. (Maybe there is something buried in apache , who knows?)
There is But then you need to write Perl, which might not be an improvement.
This configuration: If you poke around in the configuration I linked, you should see that I disable NetworkManager and use a static configuration for my main NIC. I can't think of anything special in my config or with this machine that would affect my usage of Wireguard, but I'm also new to using Wireguard. I'm currently on nixpkgs with a few of my own commits on top of . Please run and paste the results.
It doesn't seem happy when already exists... I have done two things, both of which were necessary, to resolve this: the link manually () sure the path to the private key exists (if not, you get a different failure in the journal, with failing). (It's possible that fixing the private key path and rebooting would have been sufficient). I'm leaving this open for two reasons: user should receive a better error message in both cases. that we're in NixOS, we should assume full control of the interface and just re-configure it, instead of failing in the setup script.
I ran into this issue after trying to debug my wireguard setup. My setup is essentialy identical and I get the same error message. Running the start script that is causing the error results in this output. The offending 2 lines are .
I had to go one step further than deleting the interface. I needed to stop the via then redeploy configuration. But this solved it for me. Nixos should handle this much more gracefully.
I had to remove the routes with etc.
The command is . You can build it in your conf as pre-setup command, but it has the nasty side effect that it possible interferes with other connections.
I am still running into this issue.
branch to nixos-unstable to your with
Bisect has identified (specifically ) as the source of this failure in nixpkgs, cc See also upstream issue
If you're using a flake, this is how I was able to mitigate this until it's fixed. I rolled back the changes from in a branch on my fork, and used it as an overlay for the affected packages like this: This is how you would add them to your overlay: Ofc, depending on how you do stuff, you'll have to fiddle with it a bit to get it to work. I found this helpful:
The fix is now on the nixos-unstable branch, but I still cannot build my system after updating, with the same build failure for opencolorio. Is this expected?
Probably not, since and both build on Hydra.
Oh thank you, this is very bizarre. I will ask on the forum what's going on
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Describe the bug VIber package in nixpkgs repo is broken/outdated. Getting this errors when trying to install it: To Reproduce Steps to reproduce the behavior: to install viber via config file/nix-env. Expected behavior Successful viber installation. Metadata system: host os: multi-user?: sandbox: version: nixpkgs:
have the same issue
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
Describe the bug When installing viber, the download step won't complete because the package has an incorrect sha256. My nixos version is 19.03.. (Koi) To Reproduce Steps to reproduce the behavior: Ensure that you can install non-free packages: a) For you can set { = true; } in to override this. b) For , , or any other Nix command you can add { allowUnfree = true; } to then: Expected behavior Viber should install Screenshots Additional context Add any other context about the problem here. Metadata Please run and paste the result. Maintainer information:
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 .
This is still reproducible. Is there an archive of Viber versions anywhere so we can pin Viber versions or do we have to constantly play catch-up with them?
I have the same issue, but in my case the SHA got is different:
I marked this as stale due to inactivity. &rarr;
Package name: pdm Latest released version: 2.19.1 <!-- Search your package here: --- Current version on the unstable channel: 2.18.2 Current version on the stable/release channel: 2.15.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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Project description Raze is a fork of Build engine games backed by GZDoom tech and combines Duke Nukem 3D, Blood, Redneck Rampage, Shadow Warrior and Exhumed/Powerslave in a single package. It is also capable of playing Nam and WW2 GI. Metadata homepage URL: source URL: wiki URL: license: non-build code: , build engine & tools: platforms: linux The build instructions should be the same as for gzdoom, so I want to notify the maintainer of gzdoom if he/she is interested in this. Also I want to notify the maintainer of eduke32 because this project could more or less replace eduke32(?)
I can take a look, but my current schedule is pretty full. maybe at the end of the year? But if someone else is happy to do it, feel free and ping me on the PR
Might take a look next week. EDuke32 replacement probably won't do, because iirc HRP runs only on it etc.
Thank both of you to possibly have a look into this. I think you're right. But I see that three projects: Enhanced Resource Pack Fixes for Duke Nukem 3D Duke!Zone II Fixed Release of the got raze support, already. Possibly HRP will follow sometime...