jiebi/CodeConvo huggingface dataset:
I have transmission running inside a Nixos container which has been working without issue until I recently updated the system. It now fails to start inside the container, I have tried deleting the container and all its data but the same issue exists when creating a new one. I have also tried creating the path "" on both the host and container but it doesn't seem to care. Steps to reproduce the behavior: Run transmission inside of a container Transmission service starts and runs without issue Service status Here's where I have the container and transmission defined in my config. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Same here, not sure if it's an upstream or nixpkgs issue
For the time being and since it's inside a container anyway I'm overriding the root dir of the systemd unit:
Thanks your fix is working for me!
The problem is that is listed in : Which got introduced in to The original problem was that was not in the chroot. I'd say mounting all of as read-only is going too far, so a better fix would be to just mount and only if is true. It also seems weird to have this logic be part of Transmission, but whatever. So a workaround is: (And I'm not sure why this wasn't a problem for 3 years)
I've stumbled upon this issue as well, and wondering if there is anything we can do about it regarding the Transmission service. I had to disable the following is well, before it played nicely in my setup.
indeed, adding only was one the alternatives suggested in , so we can try your suggestion. IMHO disabling or should not be the default, we could make them use though, would that be enough for you?
This is actually still an issue and it isn't limited to containers. Adding the params that posted, unfortunately, does not work for me ;/
Project description A simple and easy to use mod manager for several Unity games using Thunderstore. Support for Risk of Rain 2, Dyson Sphere Program, Valheim, GTFO, Outward, TaleSpire, H3VR, ROUNDS, Mechanica, Muck, BONEWORKS, Lethal League Blaze, and Timberborn. Metadata homepage URL: source URL: license: mit platforms: linux
I marked this as stale due to inactivity. &rarr;
Describe the bug The Thunar bulk-rename dialog doesn't support regular expressions. To Reproduce Steps to reproduce the behavior: multiple files. -Click → Rename. "Search & Replace" Expected behavior The "Regular Expression" option can be checked. Screenshots ! Additional context This appears to be because it is not using PCRE or PCRE doesn't support UTF-8. I support it isn't being built with PCRE at all. Notify maintainers No maintainers, touched it last. Metadata system: host os: multi-user?: sandbox: version: channels(kevincox): channels(root): nixpkgs: Maintainer information:
cannot access my devices. Here's an example log: I'm almost certain, that the issue is an empty , as the service runs fine without it, but I'd like a second opinion before sending a PR. Steps to reproduce the behavior: and set [Optional] Override DeviceAllow list: The service will work now. should run without errors. Adding has the same issue, overriding fixes it aswell. Possible offending code: Not sure why the override is not working, though: <!-- 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.
What does your resulting systemd unit look like? Also default priority is 1000, so overriding it with priority 100 should work.
I agree, it should work, here is the before and after (created with systemctl cat) Stock nixpkgs: With my changes: Evaluating results in for me.
Yup, that looks like the problem. That would mean they share the same priority, so we should likely try going down to 50 with the override.
I'm not sure if [the wiki][1] is up to date, but 100 seems to be the default, 1000 is the default for defaults. It might be more future-proof to change to , but it's probably more disruptive for the other modules. Overriding with 50 seems to be the smarter option. [1]: I could assemble a PR, seems like a very small fix
Feel free!
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Stressful Application Test (or stressapptest, its unix name) is a memory interface test. It tries to maximize randomized traffic to memory from processor and I/O, with the intent of creating a realistic high load situation in order to test the existing hardware devices in a computer. It has been used at Google for some time [...] In my experience it's an absolute monster in finding random memory errors that don't show up over weeks of real world usage. Until ECC is commonplace, running this software is necessary. Metadata source URL: license: Apache 2.0 platforms: linux
could you please give a try?
worked no problem, thanks a lot!
Package name: poop Latest released version: 0.5.0 <!-- Search your package here: --- Current version on the unstable channel: 0.4.0 Current version on the stable/release channel: 0.4.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 <!-- 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 have installed, and as of 24-05-2021 it fails with the following output: To Reproduce on stable channel 21.05 Notes and findings I do not use pipewire. This bug seems to happen regardless. This bug seems fresh. See on the Manjaro forums. As far as I can tell, is not available in nixpkgs. This may be fixed in the new Steam runtime. Notify maintainers Thank you! Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(matt): nixpkgs: Maintainer information:
btw is in nixpkgs, i use this tool to find what package a file is in
FYI, this seems to only happen on the steam beta, workaround (for now) would be to switch back to steam stable.
The workaround of deleting works! Having a flag file is great, since it allows you to switch to stable without launching the beleaguered application. Thank you! I use the same tool, but I must have an out of date index. I think it's time to add reindexing to a cron job.
After reindexing, I see the Nix reference: Users who want to use the beta could presumably use the following override, though I have not tested it on my machine:
Deleting worked for me too, thanks for the help.
When using the new module, packages are automatically picked up from :
Looks like this beta release just made mainline. Vanilla Steam install is broken.
fixes it
so... could you create a pull request to fix it for everyone? that would be great :)
i can make a pr for it
related:
For people that are "stuck", and just want to play games
Going to pin this until we have another unstable / stable release
Just updated on unstable after 2 weeks to find this and... Steam just segfaults with this. Think that's my cue to go back to stable.
works for me, can you give more info about your environment? this will be backported to 20.09 and 21.05
It still is segfaulting on my 2 week old configuration that worked yesterday, so idk if even going to stable is going to fix it. Guess I'll be without games for a bit.
yields CPU: Intel i7 4790k GPU: AMD RX 5500 XT Configuration is
Updating completely (completely as in like 30m ago) resulted in broken vscode as well. Full reboots after each update. No dice.
Logs:
Nevermind. Apparently something broke my steam profile. fixed the issue. Time to copy all my games over...
move the games its faster also steam automatically detects the games so you dont have to go through and install them all again for it detect them
Yea, I think valve just oof'ed on this one
if anyone is still stuck with the command that I had above, you might be able to use: which will add pipewire, and make the steam check happy
So it just corrupts the profile every time I close and re-open Steam. So much for it being fixed.
did you try the one I just posted?
Yes :(
Interesting, your channels are quite old, if you don't use flakes, it might be worth while to
I use flakes :) Nothing is really installed from those channels.
that's what I assumed when your installation said something significantly newer
Same issue right?
Looks like it. Good catch!
Unfortunately, the linked issue doesn't seem to actually have a fix that works, but I think it's still out of scope for this issue, so it can probably stay closed. I'll just have to use the flatpak until Valve fixes whatever they broke. Update: broken in flatpak too :/
The patch seems insufficient for my system
Ditto previous comment. Running 20.09 steam still not happy.
That also doesn't work for me: Full log: EDIT: Sorry wrong ping! x.x
It's not that the issue is not fixed, but the system API (seem to be X11 here or libc) is not compatible with the package. Try this for 20.09 until it's available in the channel ():
I still think we should move forward with as it's current needed for the beta runtime, and will eventually be needed when the runtime gets bumped
works for me. But I've done 2 channel updates and nixos rebuilds and my vanilla steam install is still broken. shows it was last built 08/06 with commit .
That commit is exactly the commit for this issue: Forgive my ignorance, but shouldn't a channel update + nixos-rebuild pull this in and 'just work' ?
Run nix-channel with sudo Or rebuild with --upgrade which does it for you
Do games run with Proton anymore for you? I can get Yooka-Laylee to work using the nix-shell command, but not Foxhole, which requires Proton. I'm on unstable, if that changes anything.
For those who are like me and install user software with , this workaround works, at /home/[username]
Your snippet helped me get steam running in my flakes based setup. Thank you! Properly learning nix averted for yet another day. Hooray!
My crasher was solved by adding to . It's a different, unrelated bug, so I will create a separate issue tonight probably.
I did a and steam started working for me again. Thanks for fixing this!
... Ironically, all channels have updated with fixes except unstable...
Latest unstable now has this fix and my steam is working again. Thanks folks.
cc (Apologies for the ping, please let me know if it's inappropriate) I've encountered some strange behavior trying to get this to work. Steam will notably fail with the following error despite running to bump the and channels: I've also tried using and attempted to add the override to both channels, like: Unfortunately, none of these approaches worked. In a surprising twist, the following does work, although I can't figure out how it's different :thinking::
Do you have a stale installed under your user account, or otherwise have a stale in your path somewhere? Try a to see where is coming from.
I don't think so, unless I've done so accidentally.
That is installed in your user account via . only upgrades "declarative-style" packages referenced by your . It will not update packages installed via . Do one of the following: If you want to manage steam declaratively, enable in your , for example, by setting and then run to uninstall older versions installed via If you want to manage via , remember to periodically to upgrade those packages. I recommend picking one strategy or the other exclusively for managing your packages.
great eye, thank you for the advice and thorough explanation! After running , I can see it now uses the updated path and loads correctly.
honk-initdb.service attempts tu run even though already exists, causing it to fail and prevent honk.service from starting. I think honk-initdb.service is supposed to be skipped since already exists? Please run and paste the result.
Hi, Thanks for the bug report. That's weird, because that service shouldn't run since the file already exists. I will try to investigate during the week.
Do you know if there is any way I can make honk.service believe its dependencies are met, as a workaround?
What I did precisely in I have no clue why this is not working yet.
I pushed a PR here: Could you try it and let me know if this is fixing the issue ?
Dear is your issue fixed now ?
Ping ^^
The condition seems to work but the issue remains?
Describe the bug repology reports some issues with the package name and version. It should end with the version, not "staging". So we could just call the package . But we should be consistent here! All the wine versions and attribute names are messed up. wine-4.0.2 | wine wine-4.0.2 | wine-4.14 | winePackages.unstable wine-4.14-staging | wine-staging wine-4.14-staging | winePackages.staging Why is "staging" in the package name but "unstable" not? Is there even a difference? So i would remove "staging" from "wine-4.14-staging". Metadata master Maintainer information:
Adding to this: I locally built and without issues with the current packages but I'm not sure what's actually required for a PR here. Seems odd that it was so easy and nobody else already PRed it.
Mind doing the PR then? :)
I'm not sure what's actually required for a PR here. I also don't know what the wine maintainers want. My motivation is to get the repology error fixed. So i would remove "staging" from "wine-4.14-staging". Seems odd that it was so easy and nobody else already PRed it. There is a lot that can be improved in nixpkgs that is quiet easy! For example i'm currently fixing package versions that produce errors in repology. There are 586 known problems left to fix: There are 4997 outdated packages in nixpkgs unstable: Most of them probably quiet easy to update, but someone has to invest the time. Maybe there is already a PR that is not merged yet. A review can help to speed it up! But we are already the best distro when it comes to up-to-date packages! And we might supersede AUR in the future with total number of packages. But at the same time, many common packages are not in nixpkgs...
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 .
issue still exists cc maintainers
There is a difference between unstable and staging. Staging is the staging patches on top of unstable.
That makes sense. Can we add it to Long description? Repology seem to recognise the version now: !
Added to description, but if you think longDescription is better, or think the wording is not clear — please comment or PR.
Package name: linuxKernel.kernels.linux_zen Latest released version: 6.7.6-zen1 <!-- Search your package here: --- Current version on the unstable channel: 6.7.5 Current version on the stable/release channel: 6.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]:
Oh, forgot to do it. Currently not at home. Will see how late it is when I get back. PR will be up tomorrow at the very latest.
PR is up. When it get's merged, I'll close this one.
Package name: wayland-protocols Latest released version: 1.32 <!-- Search your package here: --- Current version on the unstable channel: 1.31 Current version on the stable/release channel: 1.31 <!-- 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.
fixed in
The file does not exist so ODBC connections fail. The offending line is which should reference . In add: to nixpkgs Create/Edit and add the following: [MyNewDSN] Driver = MariaDB Server = localhost Port = 3306 Database = MyDatabase User = MyUser Password = MyPassword Run Then run: and you get the error: [][unixODBC][Driver Manager]Can't open lib '/nix/store/4cnh6dg7mwhsw0yy7c5ajxhw29l6hwa8-mariadb-connector-odbc-2.0.10/lib/libmyodbc3-' : file not found [ISQL]ERROR: Could not SQLConnect system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Fixed in
Project description There is a great wine package currently in NixOS but it lacks mingw support for the DLLs. This is needed for a few games including World of Warcraft it seems. Basically we need to build WINE with "--with-mingw" compile flag. The problem I have here is - I have no idea how to actually include the mingw compiler as a dependency to WINE. Any help here would be appreciated. Metadata homepage URL: | source URL: n/a license: n/a platforms: linux
cc
I think something like this should work: You should see something like this in your build output: I've had to do something similar when trying build Guy1524's Easy Anti-Cheat fork:
Maybe it would make sense to add a parameter to handle this?
I am not sure what it actually does, but maybe
Thanks a lot for that - I also another problem which your linked code sorted - the "compiler cannot create executables" error - strictDeps looks to have solved it though. :+1: I can tell you - it uses the mingw compiler to compile "PE DLLs" (I believe this is in reference to Windows PE DLLs but could be wrong.) It then uses these in place of the normal fake builtin DLLs it uses. This enables a much more convincing Windows environment which some apps / games appear to need.
Ahhh makes perfect sense. Do I understand correctly that build closure grows quite a bit? Any impact on runtime closure? I will merge a PR adding an off-by-default MinGW option, absent some well-grounded onjections, but maybe it should indeed be off-by-default. I guess if runtime closure change is small and build closure change is within 20% or so, we could enable by default…
I'm not too sure what closure means in this context D: What I will say, however, is that this is OFF by default in most distros so I think it should be as an option and not enabled by default - just as you suggested. Your changes got me a lot further in to the build but I believe I am missing one critical change - the build runs correctly and starts building DLLs via mingw but then fails out with: Actual overlay pkg (including the fix for exactly this error from your code linked above.) I wonder if mingw is ignoring the hardeningDisable flag or is using defaults somewhere?
We're so close to fixing this I can feel it! :+1: :
I think Arch builds wine with mingw: () In official wine repos for fedora () there are lines: and for Ubuntu (), there is mingw-w64 in . So, if it doesn't increase closure size by too much, I'd say it's a good idea to enable it by default.
Transitive closure: deps, deps-of-deps, deps-of-deps-of-deps-of-deps… This can go over runtime or build-time dependencies, of course But yes, no need to look too deeply into impact if the default is off.
Hmm, it worked for me when specifying . Maybe there is a problem with using ? The Nixpkgs manual strongly recommends using instead of . I think it's very likely that's the cause: I'll gather information about the closure sizes for each configuration (wine32, wine64, wineWow) and I'll also look into creating a PR that adds a new support flag.
I hadn't noticed that little difference - changed it to overrideAttrs and it's now building properly from the looks of things. Thanks again for all of your help on this - that's super helpful! :+1: It looks like it was disabled by default in Gentoo (in: ) due to the following bug: ^ This may not be all that relevant to NixOS - just wanted to bring it to your attention.
Hm, interesting. We'll see. if it is default-off, feel free to skip the closure-measuring step for anything you are not going to use anyway. No need to build something just for that.
I noticed that runtime closures were dramatically increased with this option: wine32 (minimal): 829.3M -2.6G wine64 (minimal): 912.5M -2.6G wineWow (minimal): 1.5G -4.9G It looks like development header files from are being referenced in all DLLS under . For example, these paths are referenced in the wine32 build: Right now I'm looking into why they're being and if they can be removed / reduced.
If mingw is disabled by default, perhaps it could be as a new attribute so that it's cached?
Considering it's enabled by default in (at least) Arch and official wine repos, some users may expect it to be enabled by default in NixOS too. Having to override wine for e.g. lutris and also build wine (which takes a pretty long time) is a lot of friction for an unexperienced NixOS user (or someone with not so powerful hardware).
Preferably we would enable it by default. Once, binutils 2.34 is which contains the we can re-enable stripping to avoid the closure increase caused by the header references.
Considering the OP mentioned specifically games, I'll just mention that lutris now ships (via its "runners" machinery) wine 5.21 with mingw.
Now that has been merged you can just use: This isn't currently enabled by default or cached, but does this solve your issue? Hopefully we can enable this on the base build once is merged, and after stripping is enabled.
I don't seem to be able to overwrite to enable . It does work for though. It complains about a missing hexdump dependency and a patch that it is unable to apply.
Did you eventually get WoW 9.0.2 running? Starting ends in an Access Violation popup for me. This is on wine 5.22:
Just a heads up, I noticed a regression running Cities: Skylines (specifically the Paradox Launcher) with : It looks like this is a problem upstream (I have the exact same problem with Lutris wine), but for now I'm just forcing it to launch with a wine built with .
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Describe the bug The last several Hydra trunk-combined runs have been blocked by (among other problems) a , which was recently back(?) to release-combined in (). When I run the test locally it sometimes succeeds and sometimes hangs forever. To Reproduce Steps to reproduce the behavior: it succeeded, clear the result with (is there a better way to do that?) and try again. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(anders): nixpkgs: Maintainer information:
We have a lot of channel blockers currently, so I recommend to also purpose revert this one. Though it sounds like it's only with issues, so perhaps comment it linking to this issue. We can always re-add it.
Package name: trenchbroom Latest released version: 2024.1 <!-- Search your package here: --- Current version on the unstable channel: 2023.1 Current version on the stable/release channel: 2023.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]: