jiebi/CodeConvo huggingface dataset:
<!-- 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: remmina <!-- 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: 1.4.13 desired version: 1.4.20 <!-- 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.
Brave browser keeps reporting a failed autoupdate. ! It should be possible to avoid it just adding a CLI option in the entry: install the package open "Brave Web Browser" from the Gnome applications menu click the menu button (it is displaying an alert even before clicking) Please run and paste the result.
Btw, this is much less relevant, but all icons are missing from the package.
The icons are there. They are symlinks to the directory.
Indeed, I realized right after writing it, but then forgot to update: I thought I was two directories upper in the hierarchy (I could have realized, simply noticing it was missing ...). My bad.
I was checking out the above PR, but I cant seem to recreate the issue. right now I've got brave 1.62.162, and the latest version available online is 1.62.165. It doesn't seem to be checking for updates. Is there a trick to getting it to check, or is it just sorta auto-updating for you?
Exploring Brave issues, like the one linked above, apparently the auto-update is a Chromium feature, even not so easy to mask for the Brave crew. However, within Nix, Brave is prevented to auto-update, so that's not an issue on its own. But it's attempting to, and just reporting the failure. So, no trick. I will soon check the version and report, but in case it helps, I'm using through a flake: and installing through NixOS:
Yeah, that's what I mean, it doesn't even appear to be trying to update when I try it.
Since I provided the whole flake (and I'm also not doing anything other than requesting the package), I'm not sure what else can I do to improve reproducibility. In case, I could provide further screenshots. But the one above is essentially the issue on its own.
Recreated with the flake :+1:
Do you understand why is it showing up with the flake and not without?
Didn't bother figuring it out. Figuring it's probably just that my version wasn't out-of-date enough.
Package name: uutils-coreutils Latest released version: 0.0.27 <!-- Search your package here: --- Current version on the unstable channel: 0.0.25 Current version on the stable/release channel: 0.0.25 <!-- 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]:
Steps to reproduce the behavior: I came up with the idea of building julia19 for that platform as a possible resort as the binary artifact does not work as is on my hardware, causing a , see also . <!-- 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.
The failure is also reproducible on hydra: , looks like the flaky tests that have been plaguing us for a long time.
Describe the bug When renaming a submodule, the makes the child options reappear in the docs at the old location. This did not happen before (ping I've encountered the problem in the arion docs when its tooling to nixpkgs 20.03. The move is -. The regression makes the docs start with a mountain of legacy options comprising just under half of all options. Reverting fixes the problem. To Reproduce Steps to reproduce the behavior: an option to is in the docs, despite Expected behavior The option docs should have at most one entry per renamed option. Any suboptions should be omitted. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata Please run and paste the result. Maintainer information:
Describe the bug It is not able to build 3.4.2 with To Reproduce Steps to reproduce the behavior: Expected behavior Successfully build Additional context It looks like there is a build issue with 3.4.2 (, , ). It would be better to update to version 3.5.1 from Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(jjc93): nixpkgs: Maintainer information:
I tried to update it locally, and failed. It still gives me .
Request for a new nix package for openmesh : library for polygonal meshes Thank you. OpenMesh is a generic and efficient data structure for representing and manipulating polygonal meshes. OpenMesh is developed at the Computer Graphics Group, RWTH Aachen. It was funded by the German Ministry for Research and Education ( BMBF). It was designed with the following goals in mind: Flexibility : provide a basis for many different algorithms without the need for adaptation. Efficiency : maximize time efficiency while keeping memory usage as low as possible. Ease of use : wrap complex internal structure in an easy-to-use interface.
I think it would help if you described why you need the library packaged. Do you plan to include any software that uses the library into the distribution?
Yes it will be feasible later. At the moment I would like to develop and launch continuous integration with Nix. I have 7/8 libraries and I need this last one under Nix to start. Note that this library is very stable, recognized in the domain of meshes, simpler than CGAL, small, without dependency... It is also on Mac with HomeBrew for example.
I don't want to maintain it, but this derivation will get you up off the ground:
Thanks a lot, I will look that maybe after summer and maybe I will propose to be the maintainer of this package, we will see ! Thanks
I marked this as stale due to inactivity. &rarr;
Have you tried to package this?
No time for the moment. But I will look that when I can... or or
Modified from version to fit the URL for versions 10.0: Hi I saw your comment about the PR. If you have time now, that would be great. If not, I'd be happy to help and create the PR.
Hi No time sorry, so you can do that. Thanks !
Cc (PowerShell maintainer) Describe the bug Powershell uses telemetry unless explicitly told not to do it. In addition to its own environment variable (already set in the wrapper), it should require another one to disable telemetry from the underlying .NET platform, i.e. should be set to To Reproduce Steps to reproduce the behavior: powershell with (assumes you have the unstable channel installed) it with and verify that it's not set (i.e. no output) Expected behavior should be set to : Additional context Example of PowerShell's own CI config that disables telemetry on Linux: This should be fairly easy to change here: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs: Maintainer information:
Describe the bug I'm trying to get Steam big picture to work with , xbox wireless adapter and a couple of xbox controllers. But if Steam is already running and I turn on my controllers, they successfully connect to the dongle, but steam doesn't detect them. If i first turn on the controllers, and then i start Steam, it recognizes them and they work fine. xow: I couldn't use the service file provided by the package because it would never start. I read somewhere that systemd is picky with symlinks, so i defined it myself, now it's starting fine. I also had to blacklist else xow would crash. Steam: To Reproduce Steps to reproduce the behavior: sure xow is running fine Steam on steam controllers to see if they work (they dont) Additional context I think xow is working fine. I tried the latest version (0.5) and the last commit, importing udev rules from the package and adding them to I also tried adding my user to the group. It doesn't matter if steam is running in big picture or not, i also tried steam native, still not working. Metadata Edit: Steam won't detect controllers even when using the wire. And also i tested the controllers with and and they work as expected. So i'm pretty sure the issue must be with steam.
This might be an upstream problem with , have you tried using it on a non NixOS system? I also maintain (a kernel driver for Xbox controllers) and I don't have this problem with Steam. Maybe try to test if there's still a problem on your system with xpadneo?
You might also want to try enabling xow using the NixOS module instead of writing a custom service:
Yes, i have another system with Arch and it's working fine there. Steam detects controller connections even when it's already running. That's what i tried at first, but xow wouldn't start, the service was hanging in an state. And I think it might be because when importing the service from the package, nix is creating a symlink to the service and it might cause some issues.
Also I did some more tests with xow and controllers are working fine, , , this website https://gamepad- everywhere it works as expected, even Stardew Valley is able to detect them, but not Steam (well unless i restart it with controllers connected, then they are detected and working). It's really weird, I am able to pair them, xpadneo detects them, but they are totally unresponsive, everywhere. I uninstalled xow, and removed the wireless dongle when i tested this. Since xow it's working fine in browser with https://gamepad- and with some games, then udev rules should be fine , right? I would say it's an upstream issue with Steam, but it's working fine on Arch, so there might be some issues with some libs?
The xow NixOS module is fixed now. The problem was that NixOS specifically bypasses the Install section of service files and the module wasn't setting WantedBy for the service explicitly.
I am wih something similar here, I am using the gamepad via USB , before the config all software detected the control, and I was able to play without problems except for steam, which prevented me from using the big picture, after enabling this option I have the same behavior as steam for all applications, if I plug in the control it does not work until the next reboot. Any suggestions on where to debug to understand why this behavior? Dmesg and lsusb look ok.
Having a similar issue, since I'm not using xow or anything but kernel drivers: Steam isn't able to detect a hotplugged Xbox one wired controller. It works perfectly fine if I plug it in before starting Steam. I can also confirm this behavior works on Arch.
that's my situation too
I guess no news on this? :(
i'll take a look, probably something to do with udev rules. i dont have a xbox controller though, only a steam controller
This problem sufficiently annoys me at this point that if there are any instructions I can follow to provide information I'm happy to do so. Thanks for offering to look. I am currently in possession of 2 xbox controllers, several controllers that show up as xbox controllers, and some controllers that don't show up as xbox controllers. I have this issue with all these controllers to the best of my recollection.
the steam udev rules are almost the same as on other distros, though arch does i'll try borrowing a xbox controller. does this happen with only the xbox one or does it happen with 360 too
sadly i can't find a xbox one controller. the udev rules provided by the steam package are the same as on other distros, maybe it has something to do with our other udev rules. may also have something to do with bubblewrap
It seems to be related to linux usernamespaces which to my understanding remaps the id of the sender of udev events (from 0 to a big number) leading udev to ignore these messages if it's not zero. Running directly on my system and under (running as root and as a normal user) led me to believe this (). This issue may need to be fixed with bubblewrap, I don't think something can be done here. Unfortunately I don't have a solution :sweatsmile: PS : I don't know if fixing this issue will make everything work, .
these look related
I merged someone who has this issue please look into using the patched systemd with the steam fhsenv
I've just tested on latest NixOS unstable. A hotplugged Xbox One controller was successfully detected by Steam Big Picture. Thank you!
i haven't done anything that would have fixed this
Well that is exceptionally weird! Because it's definitely working for me, looks like an unrelated PR fixed it? This is straight out of my terminal, after starting Steam with no controller, disconnecting and connecting again:
This must be a change to how steam recognizes controllers. The program from still does not show events when started within There is still something odd: My joystick Logitech X52 HOTAS is recognized as a gamepad, while when I run steam packages on flatpak, it works properly. I don't know what they do differently in the flatpak version to get it working. Maybe using libgudev or a flatpak specific version of udev in the runtime packages? I have tested adding patched systemd to the fhs of steam, but this did not change anything (maybe some other udev library version was shadowing it)
I marked this as stale due to inactivity.
&rarr;
I still have this issue, with both an xbox 360 controller with the wireless adapter as well with an 8Bitdo SN30+ in both wired and wireless mode. Starting steam with any of these already connected works, but if one gets connected after starting steam (or worse - shortly disconnects while playing) it will not be reconnected until a Steam restart. However, with a Steam Controller hotplugging works just fine! This happens with Steam Big Picture mode (and also in games, but I guess Big Picture mode is more readily reproducable). I assume I am doing something wrong as others have it fixed, is this really no longer an issue for others? Happy for any pointers and to assist in debugging. (my config is at in case it is needed, i am currently on )
I assume I am doing something wrong as others have it fixed, is this really no longer an issue for others? I have the same issue, with PS5 DualSense controllers. I debugged a bit during the christmas holiday, based on some info in either this issue or some other... By applying a patch (linked from the issue) I was able to see udev starting to detect hotplugging the controller in the Steam FHS env (it didn't detect these events by default), but still Steam wouldn't pick up the hotplugged controller.
I found my experimental config snippet from back then: AFAIR, I was worried that steam itself didn't use the patched libudev, but I'm pretty sure I looked up the process map and found it had (only) loaded the patched libudev, so I'm not sure what's going on. Didn't look at it since.
If anyone just wants to throw money at this problem I highly suggest the to solve it. The real win with this gamepad is that it always shows up as connected to your PC, even when it is powered off. It achieves this by coming with a usb dongle that shows up effectively as a wired joystick regardless if the gamepad is being used or not. Perfect solution for this problem... I have 3.
I'll mention a potential con, though: Make sure you have good line of sight between the usb dongle and the gamepad (don't worry, it comes with a ~1m usb extension cable to allow good line of sight) and aren't too far away (3-4 m I would guess) or else the signal is really spotty. In my last setup I used this through the wall and it absolutely wouldn't work for any serious gaming, but now I have the pc in the same room as the gamepads with direct line of sight and it is perfect. But yeah... a real solution would be better and still appreciated by me. Just thought I'd post this in case anyone could benefit from it. :man_shrugging:
Another alternative is to use : in the config: then install and run it: I didn't have any issues since doing it since flatpak was updated to = 1.12
I still have this issue on Nix's version of steam using nixos-unstable. Enabling xpadneo did not fix it either.
may have fixed this
Seems like didn't fix it. I see that it is in nixos-unstable and it seems like Steam still displays the same issue with my DualSense controller. I need to restart Steam before it detects it
I am having this issue on every controller I have: Steam Controller Nintendo Switch Pro Controller PS3 Controller Gulikit King Kong Pro 2 Controller in all 4 modes (Switch, XInput, DInput, Android/iOS) USB adapters for NES, SNES, and Gamecube controllers It occurs when using both Bluetooth and USB, so I am 90% certain it has nothing to do with which controller you are using. The behavior is the same for all of them; when I connect any USB/Bluetooth controller it is not recognized or noticed by Steam if it is already running, but only when Steam is starting up while the controller is currently plugged in. Here's some information on what happens when I use the Gulikit controller (XInput mode via bluetooth): Controller connected and Steam is not started At this point, and are now created Now I start Steam And reports: And now and are created (???)
Disconnected the controller with Steam running Nothing new in I reconnect the controller with Steam running* And and is back TL;DR - So it looks like Steam will normally start up and find the controller and then it will create the virtual input devices and . However, it won't create these devices when they are connected after Steam is already running. The question I have is why this happens and what can be done to fix it. It looks to be a NixOS specific issue as the problem doesn't appear to be on other Linux distributions like Arch (just reading off of what's in this thread, I haven't tried myself). If anyone wants me to try anything and test it on a fair variety of USB/Bluetooth controllers please let me know. I think something might be wrong with how the FHS wrapper () seems to be binding the devices that prevents new devices from being seen. EDIT: I just confirmed the and device files are appearing and disappearing in the environment that Steam runs in, so the FHS is actually properly creating those devices. The only difference I can see is that they are owned by in the FHS environment (versus in the normal environment). I can still properly access both. I did see : However, that would imply this is not NixOS specific and instead is default Steam behavior. No indication of how to change that default behavior though, so I can't find a way to confirm it.
This seems related:
Just as an datapoint: The Steam Controller is actually one that does not exhibit this issue for me, at least not when wirelessly connected with the Dongle that came with it. If I connect it via cable then it is the same as usual, only recognized when restarting steam. Also if connected via dongle and I replug the dongle, the controller only gets recognized when restarting steam. But if the dongle stays put and I shutdown the controller (by holding the Steam button for a few seconds) and start it again it works just fine with steam running. I guess it might be similar to the controller described in
I was surprised as well, and a little bit of digging reveals that SDL2 being inside flatpak and disables the unreliable udev-based discovery. And disabling it manually ! I opened to fix this.
Can confirm that it fixed the issue for me. Good job in discovering this
This is resolved for me now as well.
I cannot install on my Apple M1 PowerBook any more (potentially due to ?) I'm tracking (commit ) Steps to reproduce the behavior: Here's the output of
I'm afraid I don't have a Mac around to test with, but from glancing at the build log it appears the problem may go away if you remove from in the jsonnet derivation, or make it conditional on stdenv.hostPlatform.isStatic as suggested in .
I can confirm this issue. We worked around this in our own overlay by reverting to the last known (to us) NixPkgs version for the Jsonnet package only (i.e. we overlayed the derivation with one that is basically . No idea what exactly causes the problem, though.
didn't fix this, I still can't build jsonnet on Darwin.
This is fixed in , PTAL.
Describe the bug A lot of kde widgets and functions broke after recent updates on the unstable channel (nixos-unstable). Opening the bluetooth widget shows this error message: Other broken widgets/functions includes bluetooth widget, printer widget and desktop (the desktop disappeared resulting in a black background) xsession log: To Reproduce Steps to reproduce the behavior: plasma plasma Expected behavior Plasma widgets should work normally Screenshots A broken widget: ! Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
cc I believe Qt was updated on unstable.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
That was just me asking if it was broken. In my case, The activities and taskbar went down. I am also having the black screen as background. The errors messages I've noticed are: Ocorreu um erro ao carregar o arquivo QML: file:///nix/store/aril5n1mllyyfdgjp23va4wh8d8mbl13-plasma-desktop- module "" is not installed system: host os: multi-user?: sandbox: version: channels(wjjunyor): channels(root): nixpkgs:
The likely culprit (though I'm not super familiar with QML) is that these lines: Are not present in the 5.14 version of the patch:
That sounds about correct to me. All the patches had to be redone for 5.14 so I guess that hunk got dropped
30 minutes into rebuild with it readded, will report if it works :)
Just a recommendation, not sure if it will be helpful to you specifically, but the time to rebuild should be relatively short, and it could be even shorter if you test via running the nixos test interactively
Yeah, that's exactly the command I've been waiting for... it seems to rebuild all dependencies of qt; I'm currently on qtwebengine, which hydra says takes 5 hours :/
It works :)
What do I do now?
the fix was merged into master, so wait for the next update of nixos-unstable (or switch your system to master :)
Package name: csvkit Latest released version: 1.1.1 <!-- Search your package here: --- Current version on the unstable channel: 1.0.5 Current version on the stable/release channel: 1.0.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. --attn upstream at upstream docs at Note for maintainers: Please tag this issue in your PR.
contains the update.