jiebi/CodeConvo huggingface dataset:
I am new to nixos... When I try to use printScr Key on keyboard. it not responding. non of the printScreen optins working.. Steps to reproduce the behavior: ... press Key PrintScr ... ... Should take a screen shot ask for location to save to. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- 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.
I am not too sure but according to the , cinnamon does not have a "native" screenshot tool but gnome-screenshot could be used. I am not too sure if enabling cinnamon auto includes gnome-screenshot. If it doesn't you can just add it and see if it solves your problem.
I have user-installed Cinnamon applets, desklets, extensions, themes, which have been installed in the home folder by a different OS (as far as i remember). Many of them work under NixOS (some do not: ). However, i cannot update them. When i try, i get the message: The same happens if i try to install a new applet. Steps to reproduce the behavior: up Cinnamon desktop on NixOS and log in. to install an applet. Should be able to install and update user-installed applets, desklets, extensions, themes. ! I am just beginning to switch over to Cinnamon from GNOME 3 (having been fed up with GNOME, especially under NixOS).
Installing [][gettext] that provided solved the issue. Shouldn't be a dependency of Cinnamon desktop then? [gettext]:
Describe the bug building the package fails. To Reproduce Steps to reproduce the behavior: and wait Expected behavior Successfully building swift to be used. Notify maintainers Maintainer: Last 4: … Metadata Error
Seems as is used for building rather than . Probably happened during experiments to declare . Apart from that I'm not a swift maintainer, so if the issue is more complex, I can't help I'm afraid.
I think the Python warning is actually benign. I see a build error related to a change in the handling of . Commit appears to break it for me. I can offer a , which you can try like this: But I am not sure what the proper fix is. I would like to ask for comment.
I have pushed a new fix to my . This uses the proper fix as suggested by It would be nice, if someone can confirm it works. I have also opened PR with this fix.
OpenSCAD seems to be built without support for PDF exports. (This is a very useful feature to print projections on paper to check the dimensions of a design for example). Version: OpenSCAD version 2021.01 On nixpkgs: master (2022-09-18) Open OpenSCAD Go to File -Export -Export as PDF… Save to some file Observe the following error in the OpenSCAD console: CC package maintainers:
Any idea what dependency they need for PDF? (image file export has been enough for me so I never looked)
I think cairo. (I was looking into this earlier today.)
Yes, cairo was missing:
"ownCloud Infinite Scale Stack" or owncloud rewritten in Go. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: asl20 platforms: unix
There are some hassles to deal with on this one. PNPM usage: Image assets downloaded with curl (and no hashes or revisions) Code generation tools and code repositories downloaded by
Note that ownCloud provide prebuilt binaries for oCIS. It's fairly simple to get these working on NixOS: Perhaps this can be used as a temporary solution until we can build it ourselves?
I used your derivation and opened . I tested it a bit, and will work on a proper module over next few days/weeks, can you share if you are already using above derivation, and if yes, how stable are rc releases?
I've been using the rc for a while and haven't had any major issues. It's probably better to go with the stable release by default though. Perhaps we could package both?
Has the situation changed where the OCIS can be built from source now? I'd rather not use a proprietary binary.
Configuration snippet like this: yield a configuration like: However nbd-server expects section to always appear before export sections, otherwise it complains about not being able to find general section. I'd say this is upstream's fault because this order should not matter, but here we are. section to always appear before export sections. <!-- 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.
This looks like it should be easy to fix. I'll probably get around to it tomorrow morning.
For reference, the error looks like this:
When I update nix I can't copy to our binay cache anymore. All I get is I bisected nixpkgs and found that the bug was introduced by . Run The parent commit works: This error here is fine because our cache has a different name of course. Please run and paste the result.
Just wondered if here is the right place for the issue but I’m quite lost on this. Maybe this is a nix bug?
No you're correct to open this here, this is a good place to start. I'll try to bisect further to see which aws-sdk-cpp commit broke this functionality, hopefully that will tell us more about how to proceed.
Bisected to , but unfortunately the commit is very large so I don't see an obvious cause. Maybe it's best to take this upstream to the Nix repo now.
Thanks for reporting, and sorry if this broke your workflow. I've bookmarked this issue and I'm going to look into adding an installCheck regression test to ensure s3 stays functional on future updates.
Thank you all for the quick response. This was a really sneaky one. Luckily nix allows rollbacks. That would be great. I’m sorry I cannot think of anything better than checking the error message of . When I do I let you know.
I have installed a very barebones server with NixOS. Whenever I run it shows the following warnings: I get that it does not matter that much which of these are used, but it makes these commands not very transparent. Why is being used from and not , while is apparently part of ? Should we make sure these packages will not both be part of or should we make sure the files are only available in one of the two packages? up a minimal version of NixOS. the log
These are usually fixable by just setting priority values. coreutils should probably have a lower priority as they are usually cross platform but not as many supported features. The getconf and getent are interesting because they are actually symlinks to glibc. But we might as well make unixtools lower priority as well.
Is this something we should do nixpkgs-wide? Will that avoid the warning messages? I was thinking why these are providing the same files and why both packages are being used. For instance, do we really need openresolv or is that included unintentionally? The priorities is a way to solve this safely, but I feel like there shouldn't be any conflicts for the base packages at all.
Maybe openresolv we can leave out of systemPackages. But, some of these collisions are kind of unavoidable. We need both procps and coreutils even though they both provide kill bunary. It might be interesting to see which other distros use but IIRC they are almost identical
For coreutils, ArchLinux seems to leave out the kill binary: This also feels a bit wrong, as it isn't the original package anymore. Changing the priority does indeed sound like a better option. Coreutils should have a lower priority.
I tried giving coreutils a lower priority, but it doesn't seem to have made a difference for those warnings.
oh it already has lowprio: but it doesn't really work when everything has the same priority.
systemd-resolved is not enable by default so resolvconf shouln't be really pointing to resolvectl. I think the dummy command provided for compatibility doesn't work correctly if resolved is not running and dhcpcd needs it to configure interfaces.
Should we just give openresolv a higher priority than systemd?
Yes, correct.
The dhcpcd resolvconf hook check if resolvconf is installed and, because the command is in the PATH, it won't fall back to writing directly but will attempt to execute something like this: echo 'nameserver 10.0.1.1' | resolvconf -a wlan0 Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.
Reproducible way to see these collisions: With a file set to I ran in the (the latest commit on the branch), and I get these collision messages:
ping
Hi all nixos-version 03. (Koi) I have the same collision on kill gnutar resolvconf but also on collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/128x128/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/64x64/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/22x22/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/16x16/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/scalable/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.
0/share/icons/hicolor/48x48/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/128x128/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/64x64/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/22x22/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/16x16/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/scalable/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/48x48/apps/phonon-'
This seems to include many more collisions than related to this issue.
Maybe rather than changing the nix-env priority, a better solution is to remove some of these programs (e.g. delete in util-linux's ).
That seems hacky to me. What if you want util-linux's version of kill? Presumably if the maintainer thinks it's worth including, someone has a use for it. Nixpkgs shouldn't be making these decisions at the derivation level. Something like meta seems ideal because you can change it without effecting the derivation.
Since and were merged, does that mean this issue can be closed now?
I think so, I don't see these collisions anymore.
Let me know if this isn't fixed after all.
sorry, but i see these collisions.
none Please run and paste the result.
I started to bisect this with at nix started to download ~4GB of derivations and I aborted the process. The is
it seems like the issue already got fixed upstream in but there is no new release yet. We either have to target commit which contains the fix, or wait for the new release.
you are right, pdfpc/pdfpc fixes this. I tried it with this patch on nixpkgs:
Describe the bug I copied a closure from one system (19.03) to a USB thumb drive and from that to another system (19.09), but the program don't work. I think nix packages should be pure and work also on another system running a different NixOS channel. (Right?) To Reproduce Steps to reproduce the behavior: sweethome3d installed in thumb drive thumb drive (i use pantheons files app and open a terminal from there, then ) a folder on the thumb drive. mine is "nixpkgs" to that folder: the nix store path of the program: the usb drive into another system and mount it, get the path the nix store path to your system: you can install it for the current user if you like: or just open a nix shell: run the program: Expected behavior Program just work. Additional context I moved to a new flat with most of my computers and want to plan where to put my furniture. I installed sweethome3d on my notebook, but it is not powerfull enough. So i want to copy the program to my iMac. I have internet from my tethered mobile phone, so i can't just install it from the internet! sweethome3d is about 500 MB, that would be 1/4 of my data plan!!! Metadata X230: system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs: imac: system: host os: hangs after that Maintainer information:
Looks like this problem again: cc
When i run the package from unstable on stable, i get the same error: (but it will hopefully work on the imac when i copy it there again)
I get the same error when i run the package from unstable on my 19.09 branch. So it might be generally broken on unstable.
Yes, looks like be some kind of impurity. It runs on my NixOS 19.03 system, both from the stable and unstable channels. And I did the "nix run" thing you said and it works there too (I'm not sure how much isolation gives, apparently not enough).
It looks like the program copies some so files to on start-up: Two of the programs match to libraries in the but I could not match the other two; also I do not have the same filenames as you. Not sure what libraries’ RPATH should be patched but perhaps adding the following to wrapper would work as well:
For the reference, the libraries loaded are listed here:
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 . on the on .
Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)
Project description A simple server for sending and receiving messages in real-time per WebSocket. Includes a web UI, also has an Android client for receiving notifications and an optional CLI program (distributed separately) for sending notifications. Metadata homepage URL: source URL: license: MIT platforms: anything Go runs on
I started an attempt locally, however it failed due to some timeouts while fetching Go dependencies... will retry during this week :)
I think the main difficulty is the UI, which needs to be compiled with NPM. In essence, I think the build is three-staged: fetch UI dependencies, fetch Go dependencies, do the actual build.
You may want to take a look at .
Mainline / hardened / testing / ... kernels can be painlessly modified via : Sadly, this does not work with a bunch of other kernel variants: All kernels should honor I am not entirely sure how dynamic binding is implemented in kernel stuff, however slightly changing xanmod parts this way seems to fix : zen and lqx look similar to xanmod, no idea about libre Pinging people who seem to update affected packages often Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same underlying issue as it seems
Can confirm that this patch fix the issue for zen and lqx kernels:
have you submitted these changes as a PR that I can review?
sorry for the late response. I created a new PR with this changes.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Looks like it now uses .NET 8 which probably made all existing plugins incompatible - Package name: ArchiSteamFarm Latest released version: 5.5.0.11 <!-- Search your package here: --- Current version on the unstable channel: 5.4.13.4 Current version on the stable/release channel: 5.4.12.5 <!-- 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]:
The package/module has no official way to use plugins, so there is no way to use them unless people are using overlays which should be constructed in a smart way to re-use the same methods as archisteamfarm does. Anyway, here is the update
Project description This flag is available in most other major distros. It is necessary to enable screen sharing on wayland inside of chromium, combined with xlr-desktop-portal-wlr and pipewire. It requires the build flag and a dependency on libpipewire02. See as an example. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ...
that would definitely be nice to have :) I actually also noticed this but unfortunately cannot test this easily as I'm not using screen sharing. If you could contribute a PR that would be awesome (but be aware that Chromium does unfortunately take quite some time to compile). Alternatively (but less preferably) we could make the required changes with the next update and test the core functionality (as always) and you could test screen sharing after the new version is available in the binary caches. Additionally we would need to package in Nixpkgs to make this work on wlroots based compositors. On Gnome/KDE this might work out-of-the-box, but I don't know what they currently implement/provide.
was just merged w/ . I'll try building chromium w/ the flag - as you say it takes a while, so I can leave it overnight and give it a shot.
how does the situation look like with ? Is the flag available there, as in, screensharing with wayland already works there?
yes, it's available in google-chrome. ! I'm still trying to get it to work with xlr-desktop-portal-wlr - I've done this in the past, but it's not working out of the box yet with
And just to make sure, you also did set as described there?
yes I did. I'm almost got it working I think. There are a few issues out of the box: -chrome is missing the pipewire 0.2 runtime dependency, so I it as (I'm on 20.03 so pkgs.pipewire is 0.2): .pipewire service doesn't work - it doesn't seem to be setting up the path correctly. I'm trying to fix this now: My current config on 20.03 looks like: Where is the same package that was recently merged.
yeah, I'm currently already looking at it - pipewire wants to execute , but it's not in . We can patch to contain the absolute path. I'll check if it works and will get back to you.
Btw, we /really/ need a sway NixOS test, and better documentation on how to use sway. I was trying stuff until it worked, and does autologin me into a sway, but there might be a smarter way to do this, without also starting X.
The sway recommendation is to just run sway from the terminal after login - that's how I do it at least. I was able to workaround the environment issue by doing (but this is a kludge I think and shouldn't be necessary). But unfortunately it's now crashing and I'm not sure why:
Yeah, even my sddm config I also had to , otherwise pipewire complained about not being able to reach dbus: Afterwards, it segfaulted, as it wasn't able to find ; I patched to be able to find the path to , and that error message is gone. Now (apart from not being able to find bluez or rtkit) it /might/ only be some version incompatibilities, not sure: I'll see if I can get as far with your chromium PR, will merge that then, and also submit the pipewire patch.
Okay, with the pipewire patch and , It seems I'm able to share at least my own application window :tada:. I don't know yet why the alacritty window nearby isn't shown, and why "Entire Screen" is black, but that's probably due to me running sway inside X via ssdm.
pipewire PRs:
I don't think you're using pipewire in that case. xdg-desktop-portal-wlr only supports full screen sharing atm. If it is black that means it's not working. By the way I had to add pipewire02 to my system packages to prevent xdg-desktop-portal from crashing. But now there seems to be some incompatibility in the pipewire service logs when chrome tries to connect:
you should be able to cherry-pick the to not have to manually add this to $PATH.
Thanks! I'm suspecting google-chrome is compiled with a too old version of pipewire.
Enabling pipewire debug logs, it seems to be sending an incompatible format to the pipewire server (similar to ). I have got this working with chromium compiled against pipewire 0.2.7 in the past, so I'm pretty sure it should work assuming the client library is recent enough. Once the chromium package has that flag enabled I'll try to retest.
I just confirmed my last comment by building chromium locally w/ rtcusepipewire=true. It works perfectly for fullscreen sharing.
Hmm take that back - it worked the first time but not anymore :/. Not sure what lib is missing where.
Seems like xdg-desktop-portal is crashing:
This might be yet another version incompatibility problem. I propose merging (as it's built with 0.2 everywhere else too), and then see if we can get it to work if the system pipewire also is 0.2. I asked upstream about these problems in - maybe 0.3 needs to support 0.2 clients for some time until we should switch.
Heads-up: the bad client situation should have been fixed with the latest pipewire release, PR at
Thanks for your help! I'm still getting the xdg-desktop-portal crash, however. I'm guessing there is something missing from my dbus environment - or perhaps it's trying to access a file/directory not available in nixos.
could you open a new issue with some more details, like logs etc.?
Okay, I made
Freenet installs successfully but fails to run for both the service and the package with Steps to reproduce the behavior: Failure with Or alternatively with the service = true; to config For Freenet to start and be able to access setup wizard on 127.0.0.1:8888 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]: