Deluge 1.3.12 is incompatible with current libtorrent-rasterbar 1.1 introduced in . There are a few exceptions thrown in the log and several core features do not work as expected, e.g. seeding torrents get queued, although queues are disabled. The Deluge team does not plan to fix this, but it looks like libtorrent might in version 1.1.1. References: System: 16.09pre87431. Nix version: 1.11.2 Nixpkgs version: 16.09pre87431.
Should we include an older version of libtorrent-rasterbar in the repos alongside current? We can point deluge to use it instead.
Yes, that would probably best in the meantime. 1.0.9 should work as expected.
Looks like the PR that fixes this has been merged.


In this blog post [1], Google states that after March 15, 2021, they will be limiting access to various Google APIs that they are now describing as "private" and "only intended for Google's use". The most notable of this apparently includes "Chrome sync" which allows syncing bookmarks / browser history / etc. across multiple browsers logged-in to a given Google account. Additionally, emails [2] have been sent out to chromium maintainers from other Linux distros stating that users of their chromium-based browser will no longer be able to sign in to their Google accounts. They recommend these chromium-based browsers remove and from the build configuration, or alternatively, set at startup. Did we get a similar email as the one shown in [2]? [1] [2] CC
Further discussion With actual "answer" edit looks like this was cross-posted across two lists... I was confused by the interface... the content was already in the previous link. Basically, unless Google backtracks, the API key will become unusable for a distro-level deployment. We could continue providing the derivation, with bring-your-own API keys. This would be expensive to build for end-users. I wonder if the keys are trivially replaceable in the resulting binary though. If they are, we could produce prebuilt unusable binaries, and let users "finish" the build with their own keys. edit: The archlinux devs state that . Pinging and as we probably will have to apply the same resolution to 20.09.
Some will poo-poo the thought because "not FLOSS" and similar ideologies, let's think about end-users first here. We're smaller than those distros, but if there's a common front to talk with Google about it, we should participate or approve of such a This will end-up hurting a part of our end-users.
Personally, I don't use chrome. Google does, what google wants. I don't think we have much of a choice, and will just provide what we can. I'm sure users will be aware that the limitation exists regardless of platform.
Yes, we should be able to pass these API keys from the environment instead of baking them in.


From (This of course doesn't change anything about our API keys becoming unusable after March 15, 2021)
Quoting a couple lines here from the email thread, since it was initially unclear to me exactly which keys we needed to remove: and So, we'll just need to remove and , but not from our builds.
I drafted a PR: . Feedback is welcome (I lost track of this for a bit). Thanks for this issue btw :)


Package name: tutanota-desktop Latest released version: 3.110.0 <!-- Search your package here: --- Current version on the unstable channel: 3.108.12 Current version on the stable/release channel: 3.98.20 <!-- 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.


Package name: Latest released version: 0.0.22.post7 <!-- Search your package here: --- Current version on the unstable channel: (This version never existed but whatever!) Current version on the stable/release channel: None <!-- 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. Priorities Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
let me know if you have time to test


Project description hwatch - A modern alternative to the command, records the differences in execution results (Rust, currently distributed via [Homebrew], [MacPorts], [Arch Linux AUR], and [Rust]) At the moment hwatch is only available for on nixpkgs Metadata source URL: license: MIT platforms: All
It has been available since 22.11:
That's weird, it didn't work for me when I tried it last time so I switched it to homebrew via nix-darwin. Let me retry
I see the issue, it's Linux only
updated, thank you!
could you take a look at ?
Approved, thank you for being awesome


<details<summary<codenix log /nix/store/xglq4zgrfjp92jrjn1d740wgssrzbqpy-python3.10-tpm2-pytss-</code</summary</detailsSeems to be the same error as , but the current (as of ) has the supposed fix (). Maybe one of the other patches since then ( ) re-introduced the build failure? Please run and paste the result.
I can confirm this failure
I am also hitting this issue. Both of the above mentioned commits build for me.
Build failure was introduced with
From the commits from that merge, narrowed it down to
Followed merges back up to , though both parents have the failure there... :(
I have this issue too. This is my error message: This is the full log:
I have the problem, too
I don't have a patch for it yet, but adding -DFORTIFYSOURCE=0 to this list gets it to build.
Unless I'm mistaken, that was the fix applied by — first patch in the list here:
It only add on L207, not on L187
[deleted]
Yeah, the overlay I build isn't working for me either. Not sure where I was that made it work...
find out it and u will be the hero hhh
Ok, found the exact PR causing the issue:
The issue is that nixpkgs now forces the fortify setting, ignoring whats set in project's files. So old method of disabling fortify for just one invocation is not enough I've been trying to use and then setting fortify settings in the environment, but that is not working. With , the package builds, but with that set, it seems that trying to enable fortification in the environment has no effect. So not sure how to enable fortify for the built object files.
The overlay I'm using until there is a better fix is:
Sorry for the lag, I'm out in holidays with family without much internet. I posted a fix in but I'm not sure I'll be able to follow up on it.


The doesn't start 'cause probably the wlroots it's causing a compatibility issue. Everytime that i try start river, it doesn't open. I searched on official repository and i found this issue: The current river's version on nixpkgs repository use wlroots 0.13.0, however the available on repository it's 0.14.1. Maintainers:
I'm not maintainer for months so I don't really care.
I'll get to updating it in about ~2 hours.


Steps to reproduce the behavior: <!-- 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 is due to the upgrade to Rust 1.65 in I'm sorry for the inconvenience and will take care of fixing this. The caveat is that I need to fix my system first, which I broke somehow trying to install the new version of nix
Thank you very much!


I just tried upgrading to 23.11, and my ssh config no longer works. I specify and during a rebuild I get: , seem to have been in here last. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --I have a PR incoming as soon as git finishes pushing my branch to GitHub.
There's the PR,


<!-- 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.


Project description LDtk is an open source level editor that's used to make video games such as Dead Cells. It's just reached a big milestone and recently hit 1.0.0 release (now on 1.1.1). I apologise to the people of nixpkgs for requesting for so many new packages today! Metadata homepage URL: source URL: license: mit platforms: linux, mac, windows


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.


Submenus (rendered as popups) in some qt apps (happens a lot in telegram-desktop) can make the app crash if one clicks outside while they are shown. It's a bug in qt6.6 that is foxed by this patch: Other distros (Arch at least) include the patch already.


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 .


Steps to reproduce the behavior: X 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.


currently fails It requires 3.12. I believe this in pinned to 3.10 somewhere in NixPkgs, but do not know where. Add any other context about the problem here. No maintainers Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
please add "Haskell" label
fixed here


Beginning around commit , postgres < 14 will not build with musl: Postgresql successfully builds Here is the full output: The patches introduced in the above commit appear to be specific to Postgresql 14.x <!-- 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.


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. →
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 !


Steps to reproduce the behavior: nixpkgs master (currently ) This seems to be directly caused by introduced in No update of is availble upstream. (author of the PR) ( maintainer) Please run and paste the result.


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.


→
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.


This link is invalid: It is used to download the build Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Steps to reproduce the behavior: , build v2ray-geoip Probably we can pin to buildGo120Module?


NixOS's gzip 1.11 contained , but gzip 1.12 does not. This was probably caused by Please run and paste the result.


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.


Project description Microsoft Azure Command-Line Tools Storage-preview Extension Metadata homepage URL: source URL: license: mit platforms: unix, linux, windows This package is distinct from the package that is already in 24.05 and unstable. It enables azcopy utility in the azure-cli, which is useful for interacting with large storage accounts in Azure.
Code for extension
please give a try and leave some feedback. :)


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 :)


, (nixos-19.03) Scanned versions: nixos-19.03: . May contain false positives.


Package name: cardinal Latest released version: 23.10 Current version on the unstable channel: 23.09 Current version on the stable/release channel: 22.12 Notify maintainers Note for maintainers: Please tag this issue in your PR.


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.


Describe the bug The following warning logs are produced in my server. To Reproduce Steps to reproduce the behavior: a NixOS server Expected behavior No warning should be logged. Additional context It should be noted the interfaces of my server are named and and not and as referred to in the warning logs. Notify maintainers Metadata Please run and paste the result. Maintainer information:
(exact) duplicate of .
It may seem related but it is not a duplicate. First the concerning logs are warning (PRIORITY=4) which makes me less inclined to whitelist it in journalwatch. Also, there are no interfaces named and . It seems is not respected.
Sorry, I didn't notice the interface names. That message is surely coming from the IPv6 privacy udev rules. To see their content: The interfaces are not set from NixOS but are coming from the kernel. I'm not sure why you're seeing and . Maybe the traditional scheme is used first and later the interfaces are converted to the new scheme so the udev rules are fired twice.
The message seems indeed to come from the udev rules:
indicates (emphasis is mine): as well as: So it seems the kernel does not respect . you worked on the following code, do you know what is happening?
The interfaces are renamed according to the logs: - I do not know much about udev, maybe the udev is triggered as soon as the network interface is detected and by the time the command is executed, the kernel has already renamed the interface.
I marked this as stale due to inactivity. →
The same thing is happening here on NixOS unstable:


is missing a dependency, hence the build fails. Steps to reproduce the behavior: to : end up with this error: should build without any issues - -
If doesn't work, that is a bug but kind:bug and not kind:build-failure so another issue not to mix stuff…


after suspend the network-manager applet in plasma5/kde disappears suspend resume search for nm applet log out log in its back
Does this still happen on ? I cannot reproduce it.
i am no longer using nixos


Project description Prometheus exporter for Free Range Routing Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


When trying to run , I am with the following Qt error: I'm fairly new to nix in general, and definitely not familiar enough with the Qt wrapping mechanism. I would expect the derivation to somehow set the "Qt plugin path" (?) properly so that is found upon startup of the application. I've found the section in the NixOS Qt documentation page which recommends using the in your derivation, but as far as I can tell, the derivation ? A dirty workaround I've found is to manually specify as follows, after which the application can be successfully launched: I've looked for a way to patch this properly into 's derivation, but I'm not comfortable enough with nix to figure out how to do this. I've found that other packages such as QGIS do : but it seemed to have no effect in , maybe because the derivation uses , and not ? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Please test
I merged the above PR. please give it a try once it hits the channel you follow:
It works like a charm, many thanks for your fix :heart:


consider the following which is running inside of a container: and the corresponding system profile: the original produces a store path of now let's modify to add a simple file to : instead of immediately ing to this new configuration, let's set it to activate on : looking at the system profile it looks like everything is in order here... the symlink has been switched appropriately: the new produces a store path of let's , the new profile, and look at the file we to : :thinking: what happened? what does our system profile say? :explodinghead: somehow an additional system generation, the old system generation, was created, symlinked, and activated! additionally worth noting is that + works absolutely fine at this point i'm completely lost :manshrugging: any help? :bowing_man: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --... maybe has run into this before and has some insight because he seems to know what he is doing with running on ? or at least he can confirm whether he has this issue as well? :heart: Please run and paste the result.
I can confirm I'm seeing the same thing. I followed basically the steps you laid out for testing this. Before running , I am on . My profiles look like this: I then run , and I'm now on . I then run , and my profiles look like: I then run and restart the LXC container. After logging back in, I can confirm a new profile has been created and it is pointing to the previous profile for some reason: Although, at this point, if I jump into and look at the nixos version, it does appear to be pointing to the latest NixOS version (which is system-16-link in my example). So this at least looks correct?? I'm not sure I understand exactly the semantics of vs , or how exactly the works. It is not clear to me what is the "correct" thing to happen at each of these steps. edit: Oh, I did a little more digging and I think I know why gives the seemingly correct nixpkgs version.


After I've rebooted, still has the correct channel setup: So 's channel does seem like it is setup correctly, it is just the system that is not: Here, you can see that both and are pointed at the previous version (as you would expect from the state of the directory, as shown above).
I should add the following two things: I can also confirm that doing followed by , and then booting the machine back up does get the correct profile setup, as reported.I'm not able to confirm that was ever working for me in my LXC container. Looking at some of my previous system profiles, I see the same Nixpkgs commit hash being reused over and over again (corresponding to the bug you'd expect). It is possible that has never worked in an LXC container. I don't have any ideas here, except that maybe the module is doing something bad?
Thanks for looking and confirming I'm not sure the answer lies in the script... but it is somewhere down that path so I'll ping our expert in case they can take a look and provide any useful insight. I'm also not exactly sure who else to ping specifically about this... so I'll just ping some random people who know a fair bit about the lower levels of NixOS in case they can provide any insight ping
Could you comment the switch-to-configration output as well?
I don't know a lot about lxc, but these unconditional commands look rather suspicious:
Thanks for the comments everyone! I spent a few minutes poking around and found a few things. By commenting out this line the new generation is not created, though + still doesn't activate the new generation. More on that below... The doesn't do much when called via - it . The script, which calls , looks to be as it should. Our module includes which will use to boot the new system... but since we are running this replacement of never happens, which is the cause of the problem here! I confirmed that if I manually replace and reboot everything regarding works as expected. I don't think will execute any code from the module system directly (ie. activation scripts). So how do we teach to run ? I appreciate any and all thoughts on this topic :bowing_man:
I found some time to dig into the depths of how NixOS builds systems and now have the understanding I was missing to solve this problem.


Steps to reproduce the behavior: Notable part: @ lines 43..48: Looks like a cmake incompatibility?? possibly connected to ? <!-- 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. system: host os: multi-user?: sandbox: version: channels(root): channels(anna): nixpkgs:
Can you try building it manually against the latest nixpkgs-unstable revision using ?
This is really weird. Looks like something went and replace the first occurrence of in the source files with in . This is how it's supposed to look:
This was already built against the latest at the time, around an hour ago. My system flake registry pins to it. I get the same result with .
this looks completely normal. what is going on?
I have done a bisection and it appears that the first bad commit was
After bisecting Meson, this bug was introduced by and is still present in master.
Yes, I am writing a fix right now
has been merged, but do you think you could make a PR to master to have prismlauncher use its own overriden meson and another PR to staging to undo that change, so that way prismlauncher is at least fixed in the master branch sooner than a few weeks from now and when staging hits master, it won't have that temp fix anymore? Thank you again!
Note that the package that's actually broken here is . But yes using a fixed version of Meson for this sounds like a good idea.


Mention key types that people actually use and don’t mention ones that have been removed. <!-- make sure this issue is not redundant or obsolete --- [x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions [latest Nixpkgs manual]: [latest NixOS manual]: [nixpkgs-source]: [nixos-source]: [open documentation issues]: [open documentation pull requests]: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Let me start off by saying that I'm completely new to nixos (this is my first install that I did today) so there might be something obvious that I don't see yet. I'm installing nixos in vmware fusion on macos and I'm trying to enable vmware guest additions in nixos. I enabled: and got an error say that it's unavailable on the hostPlatform "aarch64-unknown-linux-gnu". Steps to reproduce the behavior: nixos 23.05 (minimal) in vmware fusion on macos to enable vmware guest additions. error It should configure nixos for vmware. ! I found which makes me think this should be supported. I noticed that aarch64 isn't listed under There don't seem to be any maintainers for xf86-input-vmmouse Please run and paste the result.
if you enable headless mode ( ie = true ) this should work, with the caveat is that this will install the headless version of open-vm-tools. AFAICT xf86-input-vmmouse is not supported on aarch64 (there is no other distro that ships a aarch64 package and the for it does not reference aarch64). Ill see about sending a PR to fix this case, just need to set an env where i can test this. (where you want xserver installed and you enable virtualization tools).
comments out some stuff that's actually not problematic at all on Aarch64, since only the ps2 mouse thing is, and ps2 is not even useful these days: I'm thinking just this part should be conditioned by !Aarch64 (or maybe x86_64):