jiebi/CodeConvo huggingface dataset:
Since it's not possible to use PHPINISCANDIR variable to pass additional php configuration. That breaks tools also. To Reproduce Steps to reproduce the behavior: 1 . Install php74 Expected behavior Notify maintainers Metadata
Env variable concatenation should fix it
This was intentional to avoid impure state, IIRC. The expressions we have now are very flexible. You can create a executable to include any configuration desired on the fly like so: nix-shell -p 'php.buildEnv { extraConfig = "memorylimit = -1"; }'. Also keep in mind you can pass configuration via to any instance.
By the way... are you familiar with ? Combine with and you have a really powerful combo that accomplishes what you want and more.
sure, I'm working on this kind of setup for my long running projects and I love it. Just migrated from 20.03 where we haven't soo much options. However, for some short term scenarions (like clone, patch, test, remove) creating nix config is not an option. Most of projects maintain their own and symfony tool use them both for cli and web/fpm without any additional setup and cost. I'm ok to use php -d / php -c , but still ignores custom ini files on 20.09
I didn't know that HPINISCANDIR can have multiple directories, but if that's the case, prefixing it in is fine. I mean, we also do that for many other env vars such as , etc.
Yeah I think that should be fine. I would like and to give a thumbs up first, just to make sure the idea is congruent in their minds. You're still happy if we don't automatically import though, right?
This claim seems interesting to me, I have, probably never seen a project provide a And I've been working professionally with PHP for about 10 years. And from what I can recall I haven't ever seen this before. Even working with symfony components along that way. So maybe some does, but I wouldn't say that "most projects does". I wasn't aware of this either, but from reading the documentation again: It's kinda clear that it allows the variable to be separated as any other like variable. I'm fine with introducing the possibility for such impurity just for flexibility for usages such as
there is backported version also can we merge it too?
Describe the bug Bazel is currently broken on the latest master, tested at . Bazel was built fine back at . I'm currently bisecting trying to find the offending commit. To Reproduce Steps to reproduce the behavior: -build . -A bazel Expected behavior Bazel builds correctly on Darwin. Additional context <details<summaryError log</summary</detailsNotify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
I suppose this might be related:
It's possible. I reverted , , and but I could not verify that it works because gcc failed to build. <details<summarygcc error</summary</details
perhaps or can provide some guidance here. I'm not familiar with how it's all wired up together in nixpkgs.
What’s the content of that fails?
I'm trying to compare the environment of the working build against the one not working. As far as Nix environment variables go, there are no differences except for these that are missing: However, exporting them does not seem to make a difference.
I've tried several different iterations, I'm unsure how to fix this. Anyone else would like to take a stab at this? Things I've tried: Adding clang to the buildInputs, nativeBuildInputs and propagatedBuildInputs. This was a long shot but gave it a try anyway. Exported the and . Added to the and of the bazelrc construction at line 421. Added various files in to NIXLDFLAGS and NIXCFLAGSCOMPILE I also compared the NIXLDFLAGS and NIXCFLAGS_COMPILE between the working version and HEAD, I did not find anything different.
I am not quite sure what the actual error message produced by bazel. However to debug this, you can do to see what flags are passed to the actual gcc.
This is not set if c++ usage is not detected. See also this bit: If you want to include those manually you need to put them in instead. This can affect C programs however.
proposed to check whether it’s a similar issue than what was solved in (He’s not available the next few days though.)
did fix this?
This should be fixed in
Steps to reproduce the behavior: dosbox-staging on darwin Complaining that alsa-lib not available on darwin I suggest referencing the derivation of in which use to opt-in dependencies P.S. wonder why the maintenance of this package is separated from and Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I don't have a Darwin machine. Nice. A full log would be nicer of course, but nice nonetheless. Wonder why they should be maintained by the same people.
Vulkan/dxvk doesnt work on bottles. Vulkan is working correctly on my laptop as vkcube, vulkaninfo and the game im trying to run on bottles (that i ran thru wineWowPackages.staging + dxvk install from the official archive file) run perfectly. Steps to reproduce the behavior: bottles a bottle for gaming a game. the "directx error" pop up. Also, the dxvk log files say that the "VKKHRsurface" extension failed to load. DXVK/Vulkan should work on bottles. ! Please run and paste the result.
Having the exact same Issue on 22.11pre393800. (Raccoon)
If fails then there is a driver issue. Vulkan wont be able to draw anything to screen without it. When it occurs in proton issues it's usually a missing 32bit Vulkan library. Tho there can ofc probably be other causes
update: using the system wine doesn't fix dxvk either. only running thru the command line does. As i said, running it thru wine on the terminal does work, so something in the bottles thing is not working right.
I found the cause: these hardcoded paths right there: With this extra lines in , Vulkan will work on Bottles: I'm not sure if this is the best way to solve it, though. Tested only on a 64-bit bottle (I don't know if 32-bit bottles need to also link ). .
!!! nice find!
<!-- 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: bottles <!-- 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.5.28-trento-3 desired version: 2022.7.14-brescia-1 <!-- 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.
While automatic update using was removed by in you need to wait while we will "get auto updates from r-rynatm"
That not true. I removed the over complicated updater in which wasn't necessary at all. Since r-ryantm also uses nix-update there was also no need to replace it. That's wrong. You can always create an update PR yourself by running ` or by manually update the package and create a PR with that. r-ryantm goes through all packages so it can sometimes take a few days until the update PR is created. Also nix-update is very lightweight with minimal dependencies, so there is not really a reason to not use it. It also does not require any kind of token or authentication.
Bottles the version released after the one currently present in nixpkgs, was released on June 13. Over one month has passed, so something about the auto-updater isn't working.
The latest r-ryantm log is here . Not sure why that is not working like it should.
I guess a update script is needed for this case :disappointed: Since the package is using , it HAS a fallback update script , so nixpkgs-update is no longer trying to figure out the latest version itself but just run the script.
However seems like cannot handle the version , so it will fail at You may just try Repology gets software latest version from various Linux distributions that ships this app, so since AUR and OpenMandriva have 2022.6.14 (no suffix) the latest version is 2022.6.14. Looks like there is also an related report in Note that nixpkgs-update does not really tries to bump package in this way because it has an fallback update script.
This is . Trying to build bcachefs-tools` for an aarch64-linux from x86_64-linux produces: I think comes from binutils. Adding binutils to nativeBuildInputs wasn't enough to fix it.
It's using a non-prefixed version of , it should instead be using
And after that we need to pass something like to cargo (or maybe directly to rustc?) somewhere. And we're spoiled for choice here: from in the Makefile to and env variables to maybe even .
I was able to fix this partially with this diff: That fixed the issue but seems like our libraries are incompatible? <details</details
Something has to be substituted in the source because ar is hardcoded
Applying that patch and adding The build now fails at
command encounters an error? Weird.
The built file is in instead of
is not included in the version of xivlauncher in nixpkgs, meaning that xivlauncher is currently broken. The update will need a backport to 22.05. <!-- 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: xivlauncher <!-- 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: xlcore 1.0.0.9 (upstream release 6.2.33, which I think is probably a more useful version number to use, since xlcore remains at 1.0.0.9 in the most recent release) desired version: 6.2.44 <!-- 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 adding a local directory to spotify client, it always fails due to missing gsettings schema(s) and spotify crashes. This issue is the same as the one from 2021 Works as expected on arch based distros indicating that this an issue with nixpkgs Steps to reproduce the behavior: spotify Settings on Show Local Files ADD A SOURCE button Open a file chooser to select which directory to be . <!-- 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]:
I can't actually reproduce the issue, but I do see some inherent packaging issues that I attempted to address. Can you test the linked PR?
I also cannot reproduce the issue. However, I have never actually had local files appear after I have their directories (without crashing).
Yes your PR solves the issue!!! Thanks a lot for the fast reply :) I would really like to learn more about packaging programs for nixpkgs so I can contribute more myself. Do you have any recommendations on how to learn the different options for mkDerivation, the different phases, wrapping programs and libraries, etc.? I feel like the documentation is basically non-existend. If anything comes to mind (including workshops, etc.) feel free to just send me an email (this issue is probably the wrong place to discuss this)
Project description mgmt: next generation config management! Metadata homepage URL: source URL: license: GNU3 platforms: unix, linux, darwin
After fixing up the mgmt make scripts , from !/bin/bash to !/usr/bin/env bash trying to build from 'nix-shell -p go git' git clone cd mgmt make path make deps make Building: mgmt, os/arch: linux-amd64, version: 0.0.21-90-g5c6a66e-dirty. go build runtime/cgo: copying /run/user/1000/go-build892927552/b057/pkg.a: open /nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.8/share/go/pkg/linuxamd64/runtime/cgo.a: read-only file system make: * [Makefile:175: build/mgmt-linux-amd64] Error 1 go env GO111MODULE="" GOARCH="amd64" GOBIN="/home/demo/gopath/bin/" GOCACHE="" GOENV="" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/demo/gopath/" GOPRIVATE="" GOPROXY=",direct" GOROOT="/nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.8/share/go" GOSUMDB="" GOTMPDIR="" GOTOOLDIR="/nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.
8/share/go/pkg/tool/linuxamd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGOENABLED="1" GOMOD="" CGOCFLAGS="-g -O2" CGOCPPFLAGS="" CGOCXXFLAGS="-g -O2" CGOFFLAGS="-g -O2" CGOLDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/run/user/1000/go-build275716735=/tmp/go-build -gno-record-gcc-switches"
mgmt now compiles under a I'm going to need a little bit of help to turn this into a nix package, as i'm not too sure how to handle it , as there are buildgopackage, buildgomodule , vgo2nix etc etc . Any pointers welcomed. to avoid I had to remove the -i from the go build this seems to be related to this NixOS/nixpkgs golang/go to run
I marked this as stale due to inactivity. &rarr;
Project description <!-- Describe the project a little: --Tools to manipulate pdf files. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'll see what I can do, should be good practice working with Gradle apps
Thank you Tom, much appreciated, best of luck.
By the way, I have pretty much succeeded in packaging it, and it seemed to run fine. Just forgot about it a little. The only issue with the package currently is that jar files are created non-deterministically by default (timestamps are not set to a fixed time). After using the fixup hook made for this situation (unzip and rezip the jar file) springboot doesn't recognise its files anymore, which is really weird. So it stayed non-deterministic. So I have two options: A) use the non-deterministic package or B) use the prebuilt jar from GitHub. The latter one is much less complex to work with.
See if this helps you.. or this discussion from the top (concerning java apps)...
Thanks for the pointers, though the second thing linked is my own post :) I finally managed to figure out how to fix the jar timestamps, so I'll open a PR adding the package
Thank you for your help . Much appreciated.. sorry for the delay. had a rough week last and it spilled into this one. Looking forward to using stirling-pdf on nixos.
When trying to install firefox with , I get the following error: It seems is already gone on : Considering it doesn't work on 18.03 anyway, could we cherry-pick the commit to 18.03 to disable the VLC functionality? system: host os: multi-user?: sandbox: version: channels(sepp): channels(root): nixpkgs:
For whatever reason, on master I seem to be getting this error even without this (or other firefox configurations). So the issue could be broader than this. I suppose for you it worked after removing this option then?
This is now caused by another source on ; it should be fixed by (in branch, half of binaries built ATM).
The other issue is also fixed on master since .
Wanted to install and start sweethomed.application. the build worked without problems but when i started it, it didnt started. Steps to reproduce the behavior: sweethome3d.application via configuration file to start it Starting the Application stucks at the start screen ! Add any other context about the problem here. At the moment its installed in my user context. When i try to start it as my user over the terminal i get no errors. When i start it with "sudo sweethome3d" I get the following error, and it also dont start, also start at starting screen and vanishing from the task bar: I think these happens because its not installed as user, but propably it helps to find the issue.
Starting random applications as root seems like an unwise idea.
Apologies, I misread the error, this appears to be a separate issue
Just to confirm, which GPU do you use?
I've got the same issue, and none of the solutions given in appear to work. On my side says my GPU is . EDIT: I should mention SH3D 7.02 works fine on my setup Mmh, I just tried with , and things work just fine (even though I'm on NixOS + tells me OpenGL is happy)...
Same problem here, on NIXOS unstable. Stuck on the starting blue window. Had to install it with flatpak in the mean time... Any idea?
sorry for delay i dont get informations from messages in last time from github... really annoying... I have an Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics]
Same here, also on Intel hardware.
Based on the NixGL idea, applying the following patch works to update to the latest version and fix the driver issue on Intel. But this does not seem like the best way to go about it; I can't find a single other package messing with , and it seems more like a debugging tool than something that should be in a package.
I forgot to mention, to avoid getting terrible performance (< 1 fps), I also had to set Not sure if it's needed for others. Maybe related to my using Wayland/Sway. I also have to use to get the window displayed properly, but that's a common issue for most Java apps and tiling windowing managers.
I also ran into this issue with a Nvidia card.
Describe the bug When the filesystem scrubbing service configured via is running, the system cannot shutdown until the scrubbing is completed. To Reproduce Steps to reproduce the behavior: the autoscrub server on some Btrfs file system, e.g. by the resulting service, e.g. the system: that the system only shuts down once the scrub has finished Expected behavior The scrub should be aborted properly when the system needs to shut down. Potential solution By default, running services are stopped by a SIGTERM, but apparently the btrfs scrubbing doesn't react to that. We need to introduce a custom into the service definition. This approach still needs to tested properly though. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs: Maintainer information:
This will also need a fires of a iirc, and then exit immediately, so there is nothing to as the oneshot exists immediately and then gets removed from systemd memory. So to get this to work we need:
Is really needed with ? Also cancel does not accept .
Oh my manpage-in-my-head read as block device .. not as blocking.... Scrub what I said! should be enough here I think. Also I think this is a great thing to add a NixOS VM test for
While I'd love to have some tests for this, these may not be so easy: We need a filesystem large enough that the scrubbing doesn't immediately finish before the shutdown is initiated.
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.
This weekend I tried these games, all deadlocked in the menu or character selection. Nyheim Oh...Sir! The Insult Simulator Reigns Unturned (free to play) You don't have to be worried to waste money in case you want to test a game. I have had no problem when requesting refunds, just go to I have played these games and found no issues with them: Dota 2 Counter-Strike TIS-100 World of goo Faster Than Light You Must Build a Boat Risk of Rain System: (NixOS: , Ubuntu/Fedora: , ...) 03pre99759. (Gorilla) Nix version: (run ) nix-env (Nix) 1.11.6 Nixpkgs version: (run ) "17.03pre99759." Integrated graphics card, 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
This is normal with steam on nixos unfortunately. There are many steam games that don't work for various reasons, unfortunately many linux steam game developers only make sure their games run on ubuntu and don't really care about relying only on dependencies from the steam runtime. Some games don't play nice with certain graphics cards or drivers as well. If you want to get a particular game working (I can list 150 games that work under nixos with nvidia card and drivers at least) then you'll need to do some work, or at least post any relevant logs from the game/steam so people can actually help you solve the problem. That is assuming that they own the game. :)
There's a slowly-growing list of extra dependencies in the Steam package. If you can figure out what's missing, you can add it there; e.g. as in
I don't have enough motivation to actually buy games for the sole purpose of fixing them and then refunding, sorry. Nevertheless, I'm happy to help if you can post logs and/or s -- those two are the most helpful for determining FHS-related problems.
hooks with work by . This fails because is a plain binary that doesn’t have in its environment. Steps to reproduce the behavior:
A workaround is to use the binary from instead.
It seems the above fix is insufficient. While works correctly, the hook installed into doesn't have the Python environment with the pygrep package. tested on:
Still same problem...
If you pull in the above mentioned into your environment, it should work. For best results, I recommend putting it into your (& use direnv) or systemPackages.
Potential fix which doesn't require changing the python provided in the nix shell: