jiebi/CodeConvo huggingface dataset:
waveterm Modern open-source terminal emulator supporting inline rendering. homepage URL: source URL: license: Apache-2.0 platforms: linux, darwin
I've tried, got stuck at packaging waveterm with scripthaus. However i have packaged scripthaus which is required here. Maybe someone with better understanding of nodejs will make it.
Here's my attempt at cobbling something together for linux, which seems to be working locally for me (well, it's "working" in the sense that it builds, the GUI shows up and the basic shell features seem to be working): I wasn't able to get it building using the provided scripthaus scripts yet, but I'm also quite inexperienced in this area so that could be why. I'm currently using and instead, basing it off from a bunch of other electron and go packages on nixpkgs. I haven't carried across all the build flags from waveterm's provided scripthaus scripts though, and you might also see some vestigial code that I copied from other packages that don't apply for waveterm which I haven't cleaned up yet. If I have time I might give the scripthaus scripts another try. Some other remaining todos that I'm aware of include the desktop icon, getting it working on darwin, checking the AI features, checking that the package includes all the dependencies it needs at runtime, and fixing a failing test regarding command completions. Please feel free to continue working off from what I have if it helps, especially if I don't get back to this soon.
Waveterm offers a packages. I was installing and noticed that it fetched a package and installed it. Is it not possible to do the same? I also saw in this that packages are pulled for Opera and Skype as well. So, is it possible to do the same for Waveterm as well?
Forced M1 user here, tried packaging wave but didn't manage to make the scripthaus scripts run without fails, mainly because both go and scripthaus try to create cache directories and I didn't manage to disable this behaviour.
I also tried to use package but due to it requiring electron and it not being available for the M1 architecture I couldn't compile the application from source, so I think packaging for the M1 will have to be done through the .dmg that they have on the realeases page. I'll try packaging the application when I have time this weekend.
In the end I couldn't resist and worked something out for M1 in my free time, this works and creates a ./result directory with an application I can open, so I think it's pretty much done. The only thing missing is integrating with solution... I'll try doing it this weekend.
where did you get that info from?
When I searched for electron on Nix packages it never appeared a platform for darwin... I know it should be possible to have electron in M1 but at least on Nix it isn't packaged for it already. <img width="313" alt="image" src=""
Oh, nice! I thought the panel with platforms displayed all of them, clearly it doesn't. I'll first merge the linux build mentioned previously and then I'll try using that electron to build the app from scratch. Thank you!
I enabled the following chromium enterprise policy: This created a .desktop file in But the command crashes, because it tries to start the unwrapped binary directly from the nix store. We should try to point Exec at just so the wrapper from PATH is used.
CC
Not sure what's happening here. On my system it seems to be fine:
Please read the description again, specifically I am talking about the .desktop files created by chromium, at runtime.
Ok, I was assuming NixOS put it there. Chromium creating files at runtime sucks... (unfortunately it's not even surprising :o)
setting the env var in the wrapper script may help ;drc=;l=405
I marked this as stale due to inactivity. &rarr;
(as already mentioned) would probably work for Chromium too. Just in case someone's still interested and has time and motivation to test it and submit a PR ;)
This is not exactly a NixOS caused issue. As chrome creates the shortcut wherever the binary is currently installed, and there is no nice way (other than patching chrome) to solve this. While discussion of patching chromium to always point to relative chrome i cant say much about. To get this working today, you need to edit each desktop file manually from to its relative name . and use at the top of the file. While this adds a minor security issue due to executable being relative and not absolute, it seems like the simplest solution for now. There is also this flake that will run a service in the background to do this editing automatically for you: Hope this helps! :D
We need to standardize and document this. The current contents in nixpkgs manual seems obsolete (section 4.2). I suggest at least these should be standardized: preference for usage of <codelib.licenses.*</codeinstead of the choice from some strings, meta.licenses semantics (any license at your choice, or different parts under different licenses?).
:+1:
I'd go for a documentation changes with pull request and point people to read that.
Is someone working on this? Would be good to get into (which also will presumably have with its new way of handling attributes)
First bullet is addressed in . For more complicated cases when it's not all one single license, I don't know how deep should we go. Choice from multiple licenses is probably the most common and using nix lists for that is suggestive, but it occasionally happens that multiple licenses need to be complied to at once (different files/parts under different licenses) or even more complex combinations. I don't see any possibility of "smooth extension" in such directions.
Solutions I encountered: Debian has per-file license granularity , and offers some RDF-based solution.
what's missing here?
I see the first bullet was fixed in . Attribute is still unspecified, but IMHO describing the licensing precisely in all cases is out of the scope of nixpkgs.
BTW, thanks for the notification. I forget to pass through old open issues.
Describe the bug libbladeRF fails to build on the nixos-unstable channel and latest master: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Cannot reproduce this in master. I am on . Was this fixed in ?
I have just tried on , here is a full log:
Can also confirm that the build fails on .
This appears to me a genuine error in the source. Live bladerf1.c:841 (and also bladerf2.c:283) reference , but it should be . With , we stop the build on purpose. Luckily the typo is not of further consequence, since both values are numerically the same (both zero). I will try to report this to upstream.
Oh nice, this has already been fixed in upstream master (in from last May to be precise), but there isn't yet a new release containing a fix. I'll prepare a pull request cherrypicking this patch. Be aware though that I cannot test libbladeRF (in fact I don't even know what it is about :-)).
maybe also add . This options is meant for development where there is control over the compiler, but in nixpkgs we want to update gcc without breaking half the packages due to warnings.
I see, thank you for the suggestion! Generally I'm in favor of , but your argument is quite reasonable. I'll force-push in a second.
After installing a fresh system with the following configuration: the file is not created, hence wpasupplicant fails to start with the following error: nixpkgs
I don't know the logic of , but I think you're supposed to provide the file yourself. I guess it could be ed if wpa_supplicant fails without one.
You can do
That probably wouldn't work due to permissions. EDIT: wpa_supplicant is still running as root, so it should work.
Fixed in
When I try and install the package it fails because the installation procedure iterates over all the test-short executable's dependencies and is unable to locate the required It seems this dependency comes from the test-short binary being linked against the that comes with . This has a record that says it is This results in test-short requiring the library The only provides a though, so the installation then explodes when it tries to loop over the dependencies of the binary it just created and finds it can't find It is not clear to me if this would be considered an issue with or . Two possibly fixes are to for before , or a step to to provide the symlink. Try and install package System: Nix version: Nixpkgs version: Sandboxing enabled:
I decided to give the latest unstable a try as well. It dies during the as it cannot find at all anymore. Looking through the source it looks like the recent commit stripped out all together. I guess that makes (1) above the correct solution.
forgot to CC relevant people on this issue with (should be an easy fix -- just add to the )
<!-- 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 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: minio <!-- The current version can be found easily with the same process as 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: 2022-05-08 desired version: 2022-07-15 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
When flexget starts up, it crashes with this error: . The version of transmission-rpc in nixpkgs is currently 7.x.x. Steps to reproduce the behavior: a flexget config that uses transmission. . Flexget runs normally. (transmission-rpc) (flexget) Please run and paste the result.
Upstream flexget has some discussion about upgrading to transmission-rpc v7:
Workaround: the last transmission-rpc 4 version in nixpkgs to transmission-rpc-4.nix: it to an overlay
Package name: rgbds Latest released version: 0.7.0 <!-- Search your package here: --- Current version on the unstable channel: 0.6.1 Current version on the stable/release channel: 0.6.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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I ran gimp from terminal and noticed that it prints out following warnings: I don't see anything clearly broken in the UI, but just thought that probably this is some issue that could be fixed. Run Gimp from a terminal. Please run and paste the results.
Oh, and in case it makes a difference, I'm not running GNOME but i3+none.
Try installing , GTK 2 is weird.
Thanks for the suggestion. I still get the warnings: I also noticed it warns about interpreters. Maybe those should be fixed too? I have some issues with one plugin, not sure if that interpreter issue is related to that.
Yeah, you would need to install it globally, so that GTK can find it under . Alternately, adding it to env var should also work.
Thanks, that fixed the theme issue! So maybe that should be as a propagated build input for gimp? The interpreter warnings are still there. Should I open another issue for those?
Propagating will not do anything. You would need to add it to the wrapper is citrix does.
Yeah, please open a new issue for the interpreters.
Thanks! I made a pull request. Seems to fix the issue.
The NixOS manual's section on Emacs has a . It states which is at the very least misleading and potentially confusing since the docbook migration. Either remove these references to the manual being in docbook, or remove the section in its entirety, since (with the completion of the docbook migration) it seems unclear what relevance xml editing in emacs has to NixOS at all, and people interested in the topic will presumably look to other resources elsewhere (e.g. ). (I'd open a PR for either, but am unsure which one to prefer, hence this issue) <!-- make sure this issue is not redundant or obsolete --- [x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions [latest Nixpkgs manual]: [latest NixOS manual]: [nixpkgs-source]: [nixos-source]: [open documentation issues]: [open documentation pull requests]:
The latest heisenbridge version doesn't build on nixpkgs-unstable (). Steps to reproduce the behavior: error: This repro's on darwin and on linux, using this nixpkgs revision. I believe this may be due to , where mautrix was bumped to version 0.11.3, but heisenbridge requires 0.10.x. build success. Please run and paste the result. Maintainer information:
The requirement is adjusted in heisenbridge 1.7.0:
I noticed my locatedb hasn't been updated in ~34 days. The is failing. Here's the full output: And for some reason, some of the log lines are missing from that, so here's the systemctl status output for that service: Relevant lines:
I can't find any trace of (with a ), at least on master and the latest unstable channel. What service do you mean?
Argh, sorry, I read it (notice ). Sorry, sleepy.
has problems on my unstable NixOS system too:
I confirm the problem
I have the same problem and see this in systemd's journal: The systemd service seems to have been defined like this: So it seems that is not being correctly specified.
This is what I wanted to write: However, this is still not fixed: returns (after a call to (which has exit status 0)) So, this is not fixed in 16.03. Please reopen. If is not meant to be callable as root, then should be a wrapper of some kind which would say However, I think pretty much anyone with some Linux experience wants to be able to easily build a new index when they want and has historically been the UI/API to do that. Changing that, if that was the intention, is a rather ill-conceived idea.
So, is this supposed to be working? I am still getting the same error.
This issue was about the systemd service failing with a / , it wasn't about not being able to find the file, even after running manually (I would file a separate issue for that). is the error you are still getting the failure in the systemd service? If so, which release / branch / channel are you running?
I still get the same error "read-only filesystem." I suspect this is because the only service I have running that wants to create /var/cache is the one for updatedb, which still doesn't have write permissions to /var to do so. Manually creating /var/cache as root fixes the problem.
Just installed nixos. I to get this errror. Is there any fix for this.?
Same here on a fresh install as root: nixos /nix/store/w1gzi0342kiha08pym7qj09w09ffzhj4-findutils-4.6.0/bin/updatedb: line 323: /nix/store/w1gzi0342kiha08pym7qj09w09ffzhj4-findutils-4.6.0/var/locatedb.n: Read-only file system
just installed 16.09 and I'm getting the same, Read-only file system on updatedb
VERSION="16.09.1836. (Flounder)" nix-env (Nix) 1.11.7 works fine if updatedb is used with --output and later locate is used with --database when invoked by root in a login shell, updatedb tries to write to: /nix/store/95vfigaqdg8jg5bk961k1x06j86p5fh0-findutils-4.6.0/var/locatedb.n: Read-only file system when invoked by user in a login shell, updatedb tries to write to: /nix/store/95vfigaqdg8jg5bk961k1x06j86p5fh0-findutils-4.6.0/var/locatedb.n: Read-only file system this path comes from updatedb shell script which was modified in nix (this line is different in the gnu sources): 186: ${LOCATE_DB=/nix/store/95vfigaqdg8jg5bk961k1x06j86p5fh0-findutils-4.6.0/var/locatedb} systemd service seems to be updating the db: but doesn't have access to some dirs: I'm not surprised it doesn't have access to home, but shouldn't the service be able to list /nix/store files? There are no error messages for /nix/store: the ticket is about service failing to write to /var/cache/locatedb, but it works fine on 16.09, so I think it can be closed.
I see two other problems though: update-locatedb service not being able to process /nix/store running updatedb on the cli tries to write to /nix/store which is a read-only file system
is caused by an option, now named , which contains "/nix/store" by default, the issue is closed already. is resolved by merged , the issue can be closed. is about using updatedb from cli and missing /var/cache directory and needs a decision.
When booting up SABnzbd having done an update recently (5min ago at time of writing), I'm getting the following errors: ! Steps to reproduce the behavior: your on NixOS using current unstable, include the following: . I expected it to pick up SABCtools 7.1.2, but it got 7.0.2 instead. See above N/a
Opened a PR to fix this and provide better testing.
:+1: thanks
GitLab service do not start with configuration . TLDR should be used instead of when creating config file. There is an error message in the log: To Reproduce Steps to reproduce the behavior: to Expected behavior GitLab service should be running after switching to new configuration. Additional context The file mentioned in the error: Note the missing value for . The problem seems to be at , generates empty string: Notify maintainers Metadata Maintainer information:
Thank you for reporting this! I've fixed this on master and will backport the fix to 20.03 and 19.09.
When "set as default browser" is clicked from within Firefox, it places a custom .desktop file in , and points to this from in the same directory. This file launches Firefox without the wrapper when it's opened using xdg-open. The result is that if xdg-open is used when no Firefox window exists, it will be opened without environment variables set correctly, and without plugins.
This is a great example why wrappers are error prone.
Is there a easy way to fix this? I don't see one
The easy way is to use a non-absolute path in the .desktop file, i.e. . This also ensures that after an upgrade, the new Firefox will be invoked.
This .desktop file is generated by Firefox when "set as default browser" is clicked - it's not one of nixpkgs's .desktop files. That'd involve a patch (which would have to be kept up to date with each Firefox release).
Right, shouldn't be hard to do.
Testing a patch now...
I can't see the patch anywhere -- did it work?
Chromium .desktop file includes and suffers from the same problem.
This is handled and detected with mimetypes.
Would be really nice to fix this one, any takers?
I think I have solved it for Firefox; as for Chromium — apparently it is non-trivial to test for me (StumpWM, not a DE)
There's still no obvious way to set the default browser that I can find - anyone know what the status is here?
A possibly reasonable option in the case of Firefox would be to disable the default browser check using the preferences file, and write a custom dialog for selecting the default browser in the wrapper itself, a very rough basis being: According to a google, similar should work for Chrome/Chromium, except passing instead of messing with config files. Opinions?
Is there no way to trick firefox into thinking its executable name is the wrapper ?
Yes: but this needs some testing, and it affects many browsers.
I fixed the wrapper to work with (), but we get another issue. When we update firefox, we end up with a different /nix path, which firefox considers as a different browser. If you restart firefox (for example when installing addons) then you get the not-your-default-browser" warning. Investaigating MOZAPPLAUNCHER as solution, but I start to think that may be the most general solution.
Package name: senpai Latest released version: 0.3.0 <!-- Search your package here: --- Current version on the unstable channel: 0.2.0 Current version on the stable/release channel: 0.2.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. Has new maintainer There are issues where the pulled dependencies don’t work with the 1.16 specified version. + (as well as 19) created a new batch of errors I decided to give up on. I did ask about in on their SourceHut issue tracker: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The package has been . Trying to install results in the following error: Why was the package marked as broken? Is there a way to help fix it? System: Nix version: Nixpkgs version:
According to the project homepage it requires a different version of the vte library: If you package this one and add it as a dependency the package should work again.
Thanks for the response . Could you help understand the reasoning behind the commit that marked it as broken? Was the problem that was being packaged with the wrong dependency?
The dependency it needs is not in NixPkgs, so it has to be packaged and nobody cared enough to do it.
We had the patched vte under gnome-3.20, but 3.20 was now removed whole without porting that to the vte in 3.22. EDIT: refs and .
I've wasted hours trying to fix building the special vte library, you may try to continue: This fails with: I don't see marking one package broken preferable to keeping the whole gnome-3.20 in tree, sadly. Please open a pull request if you manage to succeed, but I don't see myself wasting more time on this otherwise soon.
I fixed the errors you found during compilation and submitted a PR to upstream VTE. As the changes may take a while to propagate down into vte-ng, I them as patches to the vte-ng package, which is now used to compile termite.
Package name: feishin Latest released version: 0.7.1 <!-- Search your package here: --- Current version on the unstable channel: 0.6.1 Current version on the stable/release channel: 0.5.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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for reporting this, just noticed I hadn't subscribed to release notifications. Shouldn't miss any from now on :) Fixed by (awaiting review).
Describe the bug nix-gitignore lets the hash of the source change when some file changes in .git (notably .git/FETCHHEAD) To Reproduce Steps to reproduce the behavior: a git repo in a as follows: Expected behavior Hash does not change Additional context I intend to open a PR to fix this soon Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(symphorien): channels(foo): nixpkgs: Maintainer information:
Package name: blesh Latest released version: unstable-2022-07-29 <!-- Search your package here: --- Current version on the unstable channel: unstable-2022-07-29 Current version on the stable/release channel: unstable-2022-07-29 <!-- 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.