jiebi/CodeConvo huggingface dataset:
Describe the bug There are reasons to want a system, that has no user that can log in by SSH or with their password, for example in a declarative container To Reproduce Steps to reproduce the behavior: up a minimal declarative container asserts that I will be locked out from the system and refuses to build the configuration with Expected behavior nix generates me a container that I can log in with , or maybe I don't want to log into it at all (because it's a disposable VM or something of the like). I think there should be a check whether the generated system is a container and an additional "I know what I'm doing" override for other cases. I'll create a PR once we agreed on what's best. Maintainer information: Code causing the problem: mentioning since you the check.
Is it an option to set a randomly-generated (the hash itself would be generated, not obtained by honestly hashing a password)? Recovering the password from such a hash is probably harder than a lot of other attack vectors. But an override «doLockOutEveryone» sounds fine.
Setting a password would certainly be a possibility, but somewhat (for lack of a better word) really lame. Having slept a night over it, I propose , that disables all the assertions at the bottom. I can see scenarios where two users with the same uid could be wanted. I want my unixoid to always give me enough rope to shoot myself in the leg.
What about not enabling ssh and disabling the getty? It should completely lock anyone out, unless I am missing something. Take a look at the profile.
In case of a nixos declaratively defined nixos container, you are not logged out because the root system(d) can generate a root shell without any authentication, which is why I consider this a bug. Having to "fool" the assertion to actually lock oneself out is another matter, I could live with that but I don't think it's nice behavior.
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.
Package name: gnuradio Latest released version: 3.10.8.0 <!-- Search your package here: --- Current version on the unstable channel: 3.10.7.0 Current version on the stable/release channel:3.10.7.0 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Tnx. Update is proposed at
Project description From the project page: A tool to sign PDF files with Linux support. Why There appears to be a lack of applications that run on Linux and allow for attaching free-hand signatures to PDF files in a good way. (Non-)alternatives include: Xournal and Xournal++: Allows free-hand annotations but not saving those for later use. Allows inserting images and .pdf files but will rasterize them rather than retain the vector graphics, resulting in lower quality. LibreOffice Draw: Allows inserting images and .pdf files but will rasterize them rather than retain the vector graphics, resulting in lower quality. Okular: Allows free-hand annotations but not saving those for later use. Allows inserting custom saved stamps, but these will not be visible in other PDF readers. Evince: Allows certain kinds of annotations, but nothing that can look like a free-hand signature. pdftk, Ghostscript, and other command-line tools: Allows superimposing .pdf files, but not interactively selecting where. Metadata homepage URL: source URL: license: MIT platforms: linux
Working on it
, (nixos-19.03) (nixos-19.03) (nixos-19.03) (nixos-19.03) (nixos-19.03) Scanned versions: nixos-19.03: . May contain false positives.
See also
Can be fixed by bumping the debian patchseries we pull from -6 to -11. Already fixed by the -6 debian patchseries. Fixed, indirectly, by the patches for CVE-2014-9638 and CVE-2014-9639 (above). This CVE was a fulldisclosure publication, so it didn't get triaged and fixed... But it is fixed. Conclusion: we can close this bug by pulling in the new debian patch series from 1.4.0-11 (up from 1.4.0-6). Sending PRs.
Describe the bug I need to list the out paths of cross compiled packages beforehand which causes an eval error. To Reproduce Steps to reproduce the behavior: Expected behavior List all out paths like `. Additional context I need this feature for nixpkgs-review when cross compiling. 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 system: host os: multi-user?: sandbox: version: channels(user): nixpkgs: Maintainer information:
I think its because of the lack of splicing for perl-packages. Note however, that when that is fixed, other package sets will fail with the same issue. cc
Probably multiple issues. Have seen that problem with building xwayland for aarch64 too. Removing makeWrapper helps but probably breaks it :(. But the deps don't cross-build anyway so never got that far for now. Was thinking about opening an issue but got caught up trying to find the issue -- to no avail. Not currently at my machine, might post it later.
I marked this as stale due to inactivity. &rarr;
still important to me
Fix in
Steps to reproduce the behavior: for the pipewire package, e.g.: building it This can be fixed by either making sure that flag controls the Meson option in addtion to the , or by exposing a new option to control the directly. ping let me know which of the options above you guys prefer and I can open up a PR to fix as well. <!-- 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]:
Can we just remove that option instead?
Sorry do you mean set the to always be false or completely remove the as an option? Because I prefer the abilitiy to turn as many unnecessary dependencies as practically possible on my system (better stability and security).
Remove the option, yes, because we can't realistically maintain the exponential explosion of possible flag combinations.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I made two PRs: and Feel free to pick whichever PR looks better to you
arg removed in
How much maintenance burden does this actually cause? IMO the package options are one of Nixpkgs strengths (one of the things that attracted me, after I stopped working on Homebrew because package options started to be removed entirely), and they're critical for people working on systems where size matters.
To expand a bit, I don't think that package maintainers should generally be expected to support all combinations of options, but I also don't think they should block people who want to from doing so. Just having the flags there shouldn't cause any problems for package maintainers that don't want to maintain the flags, and it's fine IMO to respond to issues about flags not working by asking people to adopt the flag and send a patch.
No one's blocking people from overriding. It's just a bad idea to have some flags we haven't even looked at in months and pretend we support them by including them in the expression. Or in other words, keeping the flags is shipping broken code if people don't maintain them.
The enableSystemd flag had clearly been looked at recently, because there was a commit from me fixing it, and yet it was removed anyway.
Describe the bug My server uses an encrypted filesystem /data that I have to mount manually after reboot. Gitolite is configured to use /data/gitolite. I have configured gitolite-init to only run once /data is mounted. Mounting of /data always fails, as gitolite uses to generate directories and thus the mountpoint is not empty. Manual cleanup is required every time. Expected behavior Gitolite should create its directories in gitolite-init.service. Additional context systemd-tmpfiles-setup.service runs before the system is fully initialized, so I cannot delay that service. 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 system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I'll try to address this in the next few days.
<!-- 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: dt-schema <!-- 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.1 desired version: 2022.12 <!-- 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.
A new version is out: Should I just update this and my PR to make use of this new version?
Hi, i need to use open-zwave as a dependency for a build, but the version built in the Nix package is a specific fork for supporting home-assistant, which does not work for my package build due to linking errors. I will happily contribute a new package, but I'm not sure how to proceed, with regards to how it would fit in with this package, or if indeed the best way would be to modify this package to use the upstream repo. Pinging people who have maintained the package, apologies for the noise!
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 .
We should replace the package with an official version and make use the fork.
Describe the bug Tensorflow binary builds don't work on mac os. (neither do the source build, but that's a separate issue) To Reproduce $ nix-build '<nixpkgs' --show-trace -A python37Packages.tensorflow-bin_2 this derivation will be built: /nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow- building '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-'... Sourcing python-recompile-bytecode- Sourcing python-remove-tests-dir-hook Sourcing python-catch-conflicts- Sourcing python-remove-bin-bytecode- Sourcing wheel setup hook Using wheelUnpackPhase Sourcing pip-install-hook Using pipInstallPhase Sourcing python-imports-check- Using pythonImportsCheckPhase Sourcing python-namespaces-hook unpacking sources Executing wheelUnpackPhase Finished executing wheelUnpackPhase patching sources configuring /private/tmp/nix-build-python3.7-tensorflow- /private/tmp/nix-build-python3.7-tensorflow- Unpacking to: unpacked/tensorflow-2.1.0...OK substitute(): ERROR: file '--replace' does not exist error: --- Error
--------------------------------------------------------------------------- nix-build builder for '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-' failed with exit code 1 host os: multi-user?: sandbox: version: channels(noah): nixpkgs: yaml attribute: module:
Describe the bug tensorflow-bin_2 wants gast-3.2.0 due to but gast has been updated to 3.3.0 so tensorflow refuses to install: To Reproduce Notify maintainers Metadata Maintainer information:
There are also other dependencies that fail the version checks: scipy==1.4.1 and tensorflow-estimator<2.2.0,=2.1.0rc0.
This compiles i'll test it, any feedback appreciated
Got some issues
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Related .
It looks like fixes this.
Package name: bibata-cursors Latest released version: 2.0.4 <!-- Search your package here: --- Current version on the unstable channel: 2.0.3 Current version on the stable/release channel: 2.0.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.
<!-- 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: zotero <!-- 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: 5.0.96.3 desired version: 6.0 <!-- 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.
It would be nice if we are able to have , in the same way we have , and the other completion siblings. I know it's easy to just and store in , but doing that we have to allow the user in question to write to that location (I don't really know the repercussions of any) and really defeats the purpose, somehow, of Nix Packages.
as the modules (at least for bash and zsh) are fairly advanced it shouldn't be too hard. I'll try to have a look at it tonight %)
Hi, I installed on Arch Linux , but whenever I go into any Gradle-based project it doesn't work – as it works in macOS when I install it using Brew. It just doesn't discover, nor auto-completes any of the (currently available) tasks. Maybe it's not getting sourced into the shell? I do have also installed, not sure if that's an impediment (or not):
I actually confirmed that the package is doing its job, however it can be possible that I screwed something up (e.g. something in my system config made it work). I don't think that I'll have sufficient time to look at this tonight, by I'll definetely keep this in mind and have a deeper look at this as soon as I have time to.
I rechecked with the following vm config (which is basically the same as the settings I posted in my commit message): It seems to work perfectly fine with , however the validation breaks with (didn't test this, mostly use as it's easier to type :sweat_smile:) It shouldn't be too hard to fix this, I'll ping you when it's done.
For me, even if I try to use alone, when I hit (auto-complete) on the shell (), it does auto-complete what I have in the directory, which is fine, but I guess at some point the script(s) should take over the "normal" shell auto-completion.
I'm fairly confused, are you sure that it's not caused by something else? I tested it with a VM from master and inside and work perfectly fine: What I suspect now is that it could be caused by your user profile. I'm not sure if actually pulls completion scripts from . Would you mind checking this with a VM or by adding to in your ?
Hi I'm using Arch Linux and the Bash shell.
I searched within my "home" directory for this file: and I couldn't find any. I did find a , but couldn't find on it. My Bash shell is the one that comes by default with Arch Linux. I did the same on a virtual machine with Ubuntu . Let me know if you want more info.
Ah good to know! I've been testing on NixOS, usually which defines the system's entire state. But I'm fairly certain that this is related to living in , please give me som etime to investigate, but this sounds like a bug in the bash packages themselves...
It might be a bug because right now that I'm on it, I should also have auto-completion for Git commands (due to the fact that I have ), and it doesn't work either. I even to , but still, nothing going on there: Thanks for the effort!
I see... Unfortunately I don't use the user profile for this so I might lack the required knowledge. I'd recommend to look for related tickets (or open a new one) as I'm fairly certain now that this is related to the integration of into .
Describe the bug Upstream intel-vaapi-driver removed the --enable-drm ./configure option. It is now turned on by default. Happened in commit To Reproduce Steps to reproduce the behavior: the package and read through compile log Additional context This is a warning, package builds just fine despite this. Metadata Please run and paste the result. Maintainer information: (I don't know if I am dealing with attribute or module. I think attribute, but just to cover all bases.)
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 .
Proprietary HTML5 videos break the whole site Workaround is to disable . Steps to reproduce the behavior: Vivaldi package with the package in your Configuration (home-manager) YouTube YouTube should display and the video should play. !
I hit this issue myself yesterday as well. I had reported it to Vivaldi before I realized it was indeed an outdated chromium-ffmpeg dependency. See . I wrote a PR at to fix this. For a quick fix, here's the code I have in my overlay to work around this straight away:
I just saw it. Thanks a lot! I will close this issue now as you already created an issue for discussion.
Package name: aws-workspaces Latest released version: 4.5.0 <!-- Search your package here: --- Current version on the unstable channel: 4.1.0.1523 Current version on the stable/release channel: 4.1.0.1523 <!-- 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.
fails with the vdirsyncer version from nixos-unstable. it works if I install vdirsyncer with pip. Output of :
Which do you get via ? Is it the old 0.16 branch or the new 0.17 one (which was mostly rewritten in rust)? We have the latest git version of 0.17 in nixpkgs. Unfortunately, so it might be some time before this bug is fixed.
outputs this:
Same problem here. Was there any reason to go for an alpha release except for the issue referenced in ? If not, a downgrade to 0.16.7 should be fine, since the original bug is still open and probably won't be fixed for a while without anyone maintaining vdirsyncer.
There are , so I'd rather not downgrade. I'd be happy with a package for the 0.16 branch though.
That'd be great! I haven't looked into packaging yet, so it would take some time if I tried. Would you mind helping out?
I just opened a PR. It’s my first time contributing to , so I hope it’s up to snuff.
There is a hash mismatch for kstars in nixpkgs-unstable Steps to reproduce the behavior: 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]:
Last updated by
As was spotted during the PR review , the ref is a branch not a tag.
The source of the problem is (also mentionned in a comment) a typo in the name of the latest version of kstars files (). There's now a 3.7.0 version out. So I'll suggest a new PR with this version, using the official source
Project description Metadata homepage URL: source URL: license: BSD-3-Clause license platforms: linux The version compatible with NixOS 23.11 is 1.3.3. Below is the code for this Python package, which might be useful: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
please test edit: i tried to add a quippy command to test this, but the new nix cli doesn't construct python environments like the old cli did, and the old cli can't trivially use github pull as input...
Element v1.11.0 updated to Electron 19, so we need this packaged in Nixpkgs: <!-- 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: <!-- 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: 18.1.0 desired version: 19.0.7 <!-- 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 I run the script tries to download which does not exist. Do you know where to get the electron headers?
PR that brings electron19 but does not provide electron19 headers:
I believe that states that they migrated storage. So, I think the new url would be
Great find, thanks! Updated PR to include this change and electron_19 now provides the headers.
electrum_19 to master via - feel free to update your package