jiebi/CodeConvo huggingface dataset:
Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: tdmupdater tdm Expected behavior tdm starts. Actual behaviour tdm starts with a black error and has stderr errors such as: Additional context It looks like the problem might be that and the assets downloaded via tdmupdater are different versions: Workaround (Steam isn't actually used for this. This is just a lazy way to run FHS programs.) Notify maintainers Metadata** Maintainer information:
There's a version update in master. I don't know when it'll land in unstable (maybe it already did?) or stable.
Is it possible to have NixOS stable not break when upstream changes? Either: (a) NixOS stable should include the TDM assets (in which case tdm_update is not needed) (b) becomes solely a shim to grab assets from the TDM assets, so it doesn't matter which version of is used.
require patching the path to ELF interpreter, along with worrying about lib dependencies. complicated: TDM players are accustomed to dowloading extra missions, which requires a writable directory to hold the data. Do you have a proposal how to do this securely? Hardlinking the default install to /home would break if /home is on a different FS. Suid wrappers smell. World-writable bits in /nix smell too.
Surely the engine supports multiple asset directories, so we can load the assets from the nix store in addition to whatever was installed manually into a local directory.
The comments on suggest The Dark Mod stores save games in its installation directory. tracks this issue.
I have another issue that seem to be related. Running tdm via the ` work however. The relevent line are: When it doesn't work and with the second option
I poked around - and I don't have any ideas why OpenAL might not be finding hardware. Right now, it seems that the best course of action is to remove TDM from repos (to avoid creating false expectations), and run it with steam-run. and do you agree?
Project description Scalene is a high-performance CPU, GPU and memory profiler for Python that does a number of things that other Python profilers do not and cannot do. It runs orders of magnitude faster than many other profilers while delivering far more detailed information. It is also incorporates AI-powered optimization suggestions. Metadata homepage URL: source URL: license: Apache 2 platforms: unix, linux, darwin, windows Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The build is failing on master; it has been reproduced at . An example of the failure is below: There is a new release () which also doesn't pass, so I didn't send the PR as it'd fail on CI. Steps to reproduce the behavior:
Those aren't the failing tests (BROKEN means they are known to fail). These are the real failures: Looks like a broken test directory setup in the build environment.
fixed in the next point release I think
prior work
Tailscale package is not using the unless is set. Steps to reproduce the behavior: tailscale and set a flag ==no flags are used Flags are used If applicable, add screenshots to help explain your problem. Code reference: extraUpFlags is only used inside the if of auth key not being null check. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This caught me out too - could just be as simple as a warning/error when setting without ?
I don’t think that is adequate as you can run tail scale as server just fine without argument. An is only valid for up to 90 days.
Sure, but it would be a good start to alert users to the current behavior.
I was managing personal nixpkgs only because of this issue... (simply patching package doesn't seem to work for modules) Created PR for this. Hope someone can review this.
Steps to reproduce the behavior: status: status: status: This was discovered via pr <!-- 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]:
It seems like some tests have began to fail. When testing, the traceback shows the following tests fail because they don't initialize the module correctly (with ). - These tests don't undermine the functionality of when building from source, so I'm inclined to believe that the culprit is itself. Looking further, throws various deprecation warnings when the tests run. I fear that the more NixOS receives updates to , the more the tests will become more deprecated. It's unclear how NixOS feels about packages and their tests (particularly whether it's necessary for a maintainer to maintain package tests), but the current workaround is to disable these tests. Adding the tests to the field produces the result package, and continues to work as normal. I'd like some input on how to approach as this does feel pretty hacky.
We could override pytest back to a previous working version. I looked to the upstream package and it hasn't been updated in a year, to which was just a readme update.
Wouldn't this affect newer packages (assuming they use as a unit test framework) who utilize newer features of ? Though hacky, the solution I've suggested gets the job done. As mention previously, the failure of the tests don't influence 's functionality.
Disabling problematic tests is done a lot across nixpkgs. Since we know its still working when they are disabled it should be fine.
<!-- 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: 1.7.3 desired version: <!-- 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.
I started preparing the update in . Cc:
There is a license violation in the package. The package contains the code for under the old MAME license which is non-commercial and incompatible with the GPL code in the rest of the program. I tried to notify upstream, but that didn't seem to go well...
Hello! It seems that upstream actually an option to disable in version of . , from my testing, gives me an error when I try to run it. You can find more info in this . So, i think merging the pull request linked to this issue is the best option right now.
The repo URL is missing for: To fix it, you can fork (I forked it for preservation but neither of us made changes: ) then change the GitHub username in the nix file to yours. I don't have NixOS or have any way to test this. I ran into your nix file while trying to find the maintainer: I asked whether the repo has moved because it is deleted from GitHub. I contacted him via 's contact form and I'm awaiting a response (I didn't try an e-mail address found here yet: ).
Recently I have read somewhere that the author was absent from some social media, and that for personal reasons he has removed his account on github, and that this software is still available on launchpad. Github was just a second home for it. But I am not finding this info anymore.
Ok, the author responded to me via e-mail that the launchpad URL is correct, but that he isn't maintaining it. He says he's more likely to rewrite it in Rust rather than update it. The nix file can be corrected to use launchpad, but in light of that information, using one of the GitHub forks or forking one of them yourself and turning on the "Issues" feature is probably the best route to a future for it, even to a minimal extent of getting bugfixes.
I am changing the upstream source to the launchpad repository, as it is the most correct. I am also watching the two forks on github, so that I will be notified of new actions on them.
Package name: Apx Latest released version: 1.8.2 <!-- Search your package here: --- Current version on the unstable channel: 0-1 Current version on the stable/release channel: N/A <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Note for maintainers: Please tag this issue in your PR.
I just filed a to update our version of CEF to fix a . The previous version was released on 2019-07-27— that's almost 2 years! For a piece of software that's functionally a web browser, we certainly shouldn't be using an out-of-date version: web browsers have a massive attack surface and it's very important to keep them updated at all times. I don't have the time to work on this right at the moment, but it shouldn't be too difficult. There's a containing metadata for every CEF release. All that should be necessary is to grab the latest stable version for the right platform. While we're at it, we could also consider building for i686 and AArch64. Tagging the maintainer
IDK how it works, but it sounds like a job for the bot ().
HTTP Toolkit is an open-source tool for debugging, testing and building with HTTP(S) on Windows, Linux & Mac. Metadata homepage URL: source URL: license: AGPL v3.0 platforms: linux, darwin
Sorry, wasn't able to get it working. The httptoolkit-server is the difficult part. I tried building from source, however one of the dependencies tries to npm install more stuff in prebuild, so it wasn't building properly. I tried packaging the prebuilt binary but it's trying to do some auto updating and also package node with itself. I could have patched this when building from source, however the prebuilt one is minified & obfuscated so I couldn't do that.
Have you a branch to continue the work ?
+1
I've started a small bounty of 20$ on this: It's not much but it would be great to have this tool on nix!
I made another attempt at packaging this and I'm pretty close to getting httptoolkit-server to compile from source. This should help with patching out stuff, since we can do it before it gets obfuscated.
if anyone needs to run this on nix the appimage provided by HttpToolkit works pretty well on nix with no extra dependencies. See and then Would still be great to have this as a nix package though.
Hey thanks for adding this! You can claim the gitpay bounty here: (I've tried to find your email to invite you but didn't have much luck) or email me at
Sent you an email,
<!-- 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: mednafen <!-- 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: 1.26.1 (dated November 10, 2020) desired version: 1.29.0 (dated January 19, 2022) <!-- 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.
Steps to reproduce the behaviour: PyInstaller on Darwin It fails to build at gcc as gcc is not avlible on macOS CC <!-- 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]:
Is it possible that you can make gcc only in linux but clang if pyinstaller uses clang for darwin to use that?
I got it working I am willing to contribute a fix to this.
I will need to some how package since requires it for macos systems.
But first of all since gcc is required on linux is there a possible if linux include gcc instead of clang.
Based on , it seems like and the stuff is only required on linux. Maybe we could just throw in a here? Do you know if more needed to be done to fix the darwin build? Feel free to open a PR if you'd like.
You need which I am looking to make a package for and I think I still have to test if you need . I am looking to make a pr in a couple of days to fix both pyinstaller and package
I think gcc can be replace with clang which is compatible with both linux and darwin.
Macholib is now in a pr:
Now I am looking to fix pyinstaller for darwin.
The [monado] package doesn't install the udev rules generated by the [xr-hardware util] from the Monado project. Install the package and check the lack of udev rules in It was expected for the udev rules to be installted with the package. The udev rules are needed as some hmd's have some strange and specific permissions. Maybe instead of adding this to the package, monado could turn into an option like . <!-- 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]: [monado]: [xr-hardware util]:
Trying packaging the udev rules similar to how . [brscan4]:
I was working on a Monado NixOS module. Perhaps I can deal with udev rules there. See
I set up a brand new NixOS system with nothing but . After switching to the new configuration, I ran and was surprised to find in there in a and state. I poked around and it turns out that our module refers to in its section: It sort of makes sense, because presumably you want your webserver to spin up after your database, but it feels kinda icky to give completely unrelated (in principle) services dependencies on one another, especially when some of them might not even be on your system. I suppose we could make that entry conditional on , but I'm not sure what the pros and cons of that are.
Yes, I'd think it would better be conditional. Units should get reloaded on system switch IIRC, before starting new services, so I see no danger in that.
I think, this link should be broken unconditionally. In my scenario apache-httpd is used solely for SVN web interface, and while I have running Postgresql instance, they are orthogonal (postgresql is acompanied by tomcat container/nginx pair)
Perhaps, yeah. It also appears to depend on , which I think is a nixops-ism.
Describe the bug Building neovim doesn't work anymore. To Reproduce Checkout master branch, commit (latest as of now), then build: Expected behavior Building neovim should succeed.
The failing code is (...-stdenv-linux/setup: line 320):
Having the same issue when updating my system.
Ping I think this has something to do with the recent stdenv changes. Do you know how to fix it?
This is from which breaks this manual sourcing of setup hooks I say this is a good thing! We should make those proper dependencies. I will fix shortly.
I have a similar issue in stdenv-linux/setup /nix/store/fiaj00zrmb7dynd2q9xmcrh5rn0mjwj0-stdenv-linux/setup: line 97: $'r': command not found builder for '/nix/store/frqmqjyg649bkqivqhzq041fxbfvsikw-cockpit-' failed with exit code 127
Thanks!
This is especially important for Home Assistant, which and fails to build without it. Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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.
Can you tell me what nixpkgs version you are using? On master home-assistant builds just fine, with bcrypt at 4.0.0, because we do in fact relax its constraints a bit. Added variables. nix-replhome- «derivation /nix/store/044cr7v736265qjiq2b3vc7r7hxbaqfd-python3.10-bcrypt-»
I'm on . More build logs:
Upon further inspection, the file does appear to be patched correctly, but there are still in and . Maybe those have something to do with it?
My bad, I just realised I was overriding without including the original
That explains it.
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I opened a PR here: Thanks in advance for reviewing :-)
The  package (which I and maintain) has a that is rendering wrong at It seems that I used the wrong markup language. I'd like to ask: what is the markup language that we're supposed to use in s? I've been unable to find an answer to this in the documentation, and unable to find a working example in some package's file, even though IIRC I've come across some description in search results that correctly rendered some quoted code with extra styling. When I first wrote my package's description, it was 4 months ago with NixOS 21.05, and I'd somehow thought that DocBook was the correct language to use. Looking at other packages' descriptions, I see some other attempts to use markup (or Markdown), which is maybe what influenced me, but now I see that these are also rendering wrong. My longer more-structured description looks especially bad, so it should be fixed.
As far as is just plain text.
A config file is read-only, which causes the program to fail entirely. The leo text editor should run when invoked. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Not fixed:
this has been fixed on the master branch however has not been backported. I'll create a PR to backport this, in the meantime if using flakes you can update nixpkgs to follow master or nixpkgs-unstable otherwise you can update your channel to follow unstable. works fine for me. EDIT:
Are you sure? Are you sure?
!
works on my machine, which makes it extra strange that installing it locally with a flake that is pinned to does not.
<!-- 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 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: mpv <!-- The current version can be found easily with the same process than 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: 0.33.1 desired version: 0.34.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.
They're trying to be smart: We should probably patch that check out, but maybe people with actual Java experience will have better ideas.
We need to patch that. Neither do we want to provide cygpath nor can we wslpath because that would most likely try to escape the sandbox.
The thing here is that they see WSL and automatically assume we're cross-compiling to a Windows target, which we're not. We can patch this out, or maybe we can force it to not cross-compile somehow, or maybe we can make lie.
I would recommend to just patch that out.
I'm trying to use it on aarch64 and this is failing: [6/257] Building CXX object FAILED: /nix/store/fsn9mccnjinl212ypa3rx8b8647s9klh-gcc-wrapper-12.2.0/bin/g++ -DCEFUSESANDBOX -DNDEBUG -DWRAPPINGCEFSHARED -DFILEOFFSETBITS=64 -DSTDCCONSTANTMACROS -DSTDCFORMATMACROS -I/build/source/thirdparty/cef/cefbinary104.4.26+g4180781+chromium-104.0.5112.102linux64minimal -O3 -DNDEBUG -fno-strict-aliasing -fPIC -fstack-protector -funwind-tables -fvisibility=hidden --param=ssp-buffer-size=4 -pipe -pthread -Wall -Werror -Wno-missing-field-initializers -Wno-unused-parameter -Wno-error=comment -Wno-comment -Wno-deprecated-declarations -m64 -march=x86-64 -fno-exceptions -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -std=c++14 -Wsign-compare -Wno-undefined-var-template -Wno-literal-suffix -Wno-narrowing -Wno-attributes -O2 -fdata-sections -ffunction-sections -fno-ident -UFORTIFYSOURCE -DFORTIFYSOURCE=2 -MD -MT -MF -o -c /build/source/thirdparty/cef/cefbinary104.4.26+g4180781+chromium- g++: error: unrecognized command-line option '-m64' ninja: build stopped: subcommand failed. error: builder for '/nix/store/a7r53z6050vvhlmwnxac6c6kp41gcz2g-jcef-jetbrains-' failed with exit code 1; last 10 log lines: For full logs, run 'nix log /nix/store/a7r53z6050vvhlmwnxac6c6kp41gcz2g-jcef-jetbrains-'.
error: 1 dependencies of derivation '/nix/store/9mds0h6675lnh8hgam63xycvv8lrb01v-jetbrains-jdk-jcef-17.0.6-' failed to build
WSL2 on aarch64? Also, this error is for Chromium.
Sorry, never mind. I'm having an issue with , that has a dependency on CEF. I posted in an incorrect place. I opened a separate ticket. Please ignore.
The package is failing to build Steps to reproduce the behavior: The package to build successfully without errors
I'm sorry, I haven't used in years - but also nothing with that package has changed in some while. I'd assume an upstream problem?
I don't use but took a look out of curiosity. It was an upstream problem that is fixed by a few commits after the latest 2.4.0 release. There hasn't been a new release since then. Is the best thing to do here pull down that commit as an isolated patch or to bump the revision that's pulled down to that (untagged) revision?
Can we use in the meantime?
I get this error when the packages i build contain any musl one. Blocking me from reviewing PRs. Full error: Issue for a more helpful error message: Steps to reproduce the behavior: No error. I think the solution would be to disable musl libc on i686-linux until it actually works. So Nix or nixpkgs-review don't even try to build it. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Collecting information: this looks fine maybe here needs to be a check for 64-bit