jiebi/CodeConvo huggingface dataset:
I did some digging around to know why the line has disappeared from the with the update. This is what I found out: on the home-assistant repository, the code for the mqtt sensor was moved from the to between and this means that the is now in the When I define a mqtt sensor in my nixos config, will the nixos module be able to do the conversion from to (I don't fully understand the code in the nixos module, especially the code) ?
Not yet. I will implement that once I was able to solve the stack overflow issue.
The problem should be solved once you upgrade your system since is now in the channel. Can you please try again?
I can confirm that I don't have the build error anymore, thank you ! However, the home-assistant environment is missing component dependencies. Same as stated previously, home-assistant code has been refactored, but config is the same, which means that dependencies are not found. For example, I have declared in config, but dependencies are at the key.
Adjusting the code for is on my TODO list. For now, please override the package's .
Ok, at the moment, I am using manual config because I am testing home-assistant, using and the automation editor, so I have manually set the . Do you think we could add a package (something like ) which would have all possible dependencies (the idea being that I would also be built by hydra) - a little like the docker/distro image that distributes ?
Sure, no problem. However, I suscpect that will often not build due to some Python packages not building. Do you want to make a PR or should I do it?
I can surely try, but I am not sure how I should proceed : I define a new option for package that populates to all packages referenced in should I call the package with all packages referenced in (in a new file next to ), and call it in a new in . Which option do you think is best ?
I guess the first option comes close to the best one. However, please don't use for that but directly add the packages to . Maybe we could also add a few lines to to add a list of all packages to so that we don't go through all components to generate that list.
NixOS's wrappers for gcc also apply for gcj, which is a Java compiler. The wrappers add the flag to gcj's command line, however the Java language does not have a preprocessor, and means a different thing for gcj. This means that gcj cannot compile anything. Another issue is that gcj links to zlib by default, but does not pull zlib into the environment. This means that, even if the former issue is silenced with , compilation still wouldn't work.
A similar problem for gfortran:
I marked this as stale due to inactivity. &rarr;
, CVSSv3=5.5 (nixos-20.03, nixos-20.09, nixos-unstable) CVSSv3=5.5 (nixos-20.03, nixos-20.09, nixos-unstable) CVSSv3=5.5 (nixos-20.03, nixos-20.09, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-20.09: ; nixos-unstable: . Cc
CVE-2020- doesn't seem to have a patch yet. The rest (for all mentioned branches) is going to be addressed in .
Package name: matrix-synapse Latest released version: v1.113.0 <!-- Search your package here: --- Current version on the unstable channel: 1.112.0 Current version on the stable/release channel: 1.112.0 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Minor cosmetic issue: when using kpcli, the prompt shown to the user says ".kpcli-wrapped:/" instead of the usual "kpcli:/". system: host os: multi-user?: sandbox: version: channels(delroth): channels(root): nixpkgs:
Usually this can be fixed with the --argv0 flag:
kpcli uses wrapProgram which already sets --argv0 correctly AFAICT. Looks like this is a kpcli specific problem:
OK, I understand the reason why --argv0 did not work now. Since this is an interpreted script, we are indeed setting Perl's argv[0] to the right value, but within Perl 0) - Sent to just wrap the script manually and thus control the basename of the wrapped script.
Fixed in
Describe the bug clones each submodule in sequence instead of in parallel, which is unnecessarily slow for repos that have a lot of submodules (such as which has 64 direct submodules). At first I thought this was because git's setting defaults to , but it turns out doesn't even use that, it instead recursively clones the submodules by hand. it looks like you this 10 years ago; is there any reason we can't just use today? I don't know why it doesn't just use git's built-in submodule handling, doing so would make fixing this trivial. Parallelizing the manual clone loop seems a lot more complicated (especially because of the problem of mixed output). To Reproduce Steps to reproduce the behavior: from scratch. (Edit: was recently updated to not use submodules anymore. This can be reproduced using an older version) Expected behavior It should clone the repo in a reasonable amount of time. Notify maintainers Last few changes to were and Metadata system: host os: multi-user?: sandbox: version: channels(lily): nixpkgs: Maintainer information:
I marked this as stale due to inactivity. &rarr;
See
Simplified in
I used Genymotion for a long time on macOS but with Virtualbox. I switch to Linux/nixOS about 5 months ago and was pleasantly surprised to read Genymotion now supported the QEMU engine. Alas, myself and a few other of my friends were never able to get Genymotion to work using QEMU, which is the preferred Hypervisor. I've tried to source some help at but to no avail. Steps to reproduce the behavior: a running working QEMU installation. Presumably with at least 1 functional VM too Genymotion Genymotion, ensure QEMU is selected as the Hypervisor a random Android device, add it and run it. 'll first get a 'can't start virtual device' error trying to start the Android device again gives a 'Another QEMU process appears to be using the same resources' error I'd expect Genymotion to start the Android device using QEMU, naturally 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: ! !
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
! !
Duplicate of . Does the workaround in work for you?
I'm not really sure this is a duplicate but that's up to you. I'm not a coder so had no idea what to do with that old 'work-around' either. I had a colleague who kindly looked at it, spent some time, and turned it in to a flake which can be found at And now the broken Genymotion functions great with QEMU. Perhaps the flake code can help in fixing the package. Thanks for the pointer to the old work-around
Steps to reproduce the behavior: ... ... ... A clear and concise description of what you expected to happen. 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.
Hey have you ever made Genymotion work under Wayland ? For instance, on any other distribution ? I'm not sure the support for Wayland has dropped quite officially for Genymotion or I might be wrong, maybe there is no need since it's a QT based graphic interface and platform plugins do exist for Wayland nowadays. EDIT: To add more information, on ArchLinux, here is what I'm getting as an error you might want to share your exact genymotion logs I'm running Sway and I have the following env variables set : QTQPAPLATFORMTHEME="qt5ct" QTQPAPLATFORM=wayland #QTWAYLANDFORCEDPI=physical #QTWAYLANDDISABLEWINDOWDECORATION=1 XDGSESSIONTYPE=wayland XDGSESSIONDESKTOP=sway XDGCURRENTDESKTOP=sway
Okay so I made it work on my end but I'm not under NixOS/not using Genymotion installed from Nix, try
I have run with , but still get error. and this is the QT relate envs and this is XDG relate envs
Could you give a try and use every single platform listed here :
Also please share your genymotion logs, there might be more to the error in there And finally, please let us know your exact Desktop Environnement, Wayland is being used, I suppose.
One more thing, could you retry using xcb as a platform after having installed in the environnement ? EDIT : Also set So to sum up run :
I am using wayland + plasma, so I think the dependencies is ok and this is
This may not fix your issue, but try it with this : ! EDIT: Also are you running with an Nvidia GPU or not Wayland ? If yes, you should try everything related as well.
EDIT2: I've found this so I believe it should work, but something may be wrong, I may need to look at the Nix definition of the package and compare with the way it is packaged for ArchLinux and see if there is anything that could explain what's going on. ! There could be also issues regarding Wayland + Plasma : If you could try another desktop environment, maybe Sway if possible, if you cannot, I will give this a try in a VM under the latest NixOS when I have some time.
See this commit too this maybe a fix, that you don't have yet, maybe you have it already because it's been backported.
Could you please the run of the command ? And uploads the logs to a GitHub Gist. If you can't or are busy, let me know, I'll try to reproduce inside a VM and investigate.
This is the log
I know what causes this problem, because I have different qt version, so I have to add to , and it works for me, thanks for your patience and help
Should I make a PR?
Hm I'm not familiar with the process but I believe you should make a PR if you can or maybe let's tag the maintainer of Genymotion here ? I believe it is
Let's wait a week or 2, if he answers back and can make the PR then you can wait to close this issue once the PR gets merged.
Still relevant. Genymotion tries to load some Qt plugins from nixpkgs and fails for whatever reason. I was able to workaround it by doing . used to work before too but is failing now (and it's unclear why, since its effects are similar to , I guess genymotion still picks something from env vars besides plugins)
Hi! I'm there is seems no this issue on unstable, but I've found another one - Can't start virtual device: qemu libpixmin not found. Here is log: Should I create another issue?
That's weird, I believe you should open a new issue yes however I'm not sure if including as a dependency in the derivation of might fix your issue : Running outputs :
as the maintainer of genymotion's package in Nixpkgs any advice/idea, what's going wrong ?
Seems like you were trying to launch genymotion with qemu instead of virtualbox.
Describe the bug The static build of is broken. To Reproduce Steps to reproduce the behavior: Expected behavior It builds. Screenshots See log output. Additional context In the version was bumped but the patch was not adjusted. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (+ author of ?) Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Project description Tana is an outliner, a note-taking application that sits between Roam Research and Notion. It's a great up and coming productivity platform, with a unique feature called Supertags. Supertags are basically templates you can graft on to tags. They currently have a deb and a RPM, but as it's a closed source application, the source is not available. Metadata homepage URL: source URL: license: Proprietary platforms: Linux (Deb and RPM), windows, mac Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I have it working locally, need to clean up some stuff and then will create the PR! I still have to figure out the license they're using (for the metadata)
That's amazing! I'm so happy thank you so much!
Steps to reproduce the behavior: oh-my-posh package as part of a system flake on nixos-unstable branch broke today, however most recent working commit I have found is: which is obviously confusing package author says not their issue, but also says the package is out of date as they are on 19.5.2 and the package is on 18.26.1 My system config is: Dont judge im kinda new I havent worked on secrets yet so I just dont have any secrets in it
Looks like an update PR is in progress that'll probably fix it:
In latest version of Adw-gtk3, window title bar on Electron-based app be weird transparent Steps to reproduce the behavior: Adw-gtk3 to latest version (from Nixpkgs) it as usual Electron based app title bar be weird transparent It looks as usual I show screenshots from my installed Electron-based apps, VS Code & YouTube Music by th-ch ! ! I haven't idea sources of this bugs <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Based on upstream issue, it needs GTK 4.16 for v5.4 version. I wish it can solved soon as possible
This for Gnome 47 needs to merge first.
!
Maybe we could just revert and update it again once GNOME 47 is merged?
I override it on my configurations and it works properly
Apparmour service doesn't reload correctly after a system switch. Steps to reproduce the behavior: anything in config with apparmor enabled nixos-rebuild switch error of apparmor service failing to restart No error, apparmor starting as it should Here my service log: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm encountering the exact same error here.
Same issue here
Same for the issues after . However do a after that just fine.
Someone once told me that the state of AA in NixOS wasn't great. But I don't know first hand. Could be wrong. I lack any knowledge at all to even figure out the root cause of the issue. :/
AA seems to work fine in general. Just the service restart after a nixos-rebuild doesn't work.
Tested just now on nixos-23.11. AppArmor service restarts without any issues after nixos-rebuild. I think this issue is resolved.
Reopening this issue as unresolved. Currently on 24.05.. and this issue seems to be persisting after a nixos-rebuild: reloading the following units: apparmor.service, dbus.service Job for apparmor.service failed. See "systemctl status apparmor.service" and "journalctl -xeu apparmor.service" for details.
I did some more investigation on this. I have one system with a custom apparmor profile and another system with no profiles. On the system I have with a custom apparmor profile, nixos-rebuild works fine. On the other system without any apparmor profiles, nixos-rebuild fails with the message in this bug report. After nixos-rebuild, journalctl reports: In I tried running "sudo aa-remove-unknown" from zsh: The error message matches what is in the system log. I think this may be related to the aa-remove-unknown step.
As a workaround, adding this to appears to work: After this, the first nixos-rebuild switch will still cause the issue (because the profile is not installed yet). But on the second and subsequent nixos-rebuilds, there is no error message on my system.
RStudio is missing most of the text from its UI (see screenshots), the text one being displayed is in the top menu bar. Icons are displayed correctly though. or to the environment (for example ) The main interface starts in a new window with version information in the left pane, environment information in the top-right pane, and filesystem overview (with file and folder names and not only a logo to represent them) What I observe: ! Expected (here taken from archlinux's rstudio package) : !
Confirmed, fixed on my side, thank you!
I also have this issue and the PR does not solve it... Please let me know what information I can provide to help you in debugging.
Please just forget about it : my pinned version was not building the new version that you packaged. Thank you for your help !
Describe the bug The current downloads 2 patches, both of them 404. I realized this when I tried to build my system from scratch without substitors. To Reproduce a system that somehow depends on mercurial (not exactly sure if this is reproducible with just or similar, this was also on a content addressed machine, and reproducing the issue in a more isolated way would require another toolchain bootstrap which takes several days) the system from scratch using see errors like this: Expected behavior mercurial builds without errors Screenshots See log output from reproduction. Also ing the URLs as in the derivation linked in the description result in 404. Additional context The exact commit the system was build from is nixos/nixpkgs/, though as the same path URLs are used in nixos/nixpkgs/master, this is probably only partially relevant. Notify maintainers cc Metadata nix shell nixpkgs#nix-info --option trusted-substituters -c nix-info -m system: host os: multi-user?: sandbox: version: channels(nmelzer): nixpkgs: Maintainer information:
When I set in , the rebuild fails as is no longer a valid option. Steps to reproduce the behavior: thrown: The option definition /nix/store/bfg7xzgvbhxhs7vnl7lynaxmjhmvc4j0-' no longer has any effect; please remove it. See the 16.09 release notes for more information. should not fail. - - Please run and paste the result.
Having had a look at that module (), IMO it should just be removed. ? really?
The module in general looks outdated and incomplete. I share the opinion of either dropping it or actually correcting and finishing it.
Other question is when you look at the history they removed lsh 7 years ago because it was unmaintained, but then the commit got reverted later?
This module doesn't make sense at all. GNU stuff and non-GNU ones usually can't fully replace each other, and it's up to the users to decide which one to use.
Please add rust-gdbgui to in the post install script of rustup. rust-gdbgui was recently to the list of proxied tools in rustup. However, the change that's now present in latest master of rustup is not yet part of a tagged release. I'm assuming that updates to a package are only done to tagged releases? I'm also not sure how disruptive updating the is. So, I think this issue cannot be resolved until the next release of rustup. name: rustup current version: 1.24.2 desired version: 1.24.3 (not yet released) maintainers: Please tag this issue in your PR.
Can you make a pull request? We should wait for a release so.
Sure. I'll make a PR on the next rustup release.
I marked this as stale due to inactivity. &rarr;
See pr
Project description Dr. Robotnik's Ring Racers is a kart racing video game originally based on the 3D Sonic the Hedgehog fangame , itself based on a modified version of . Metadata homepage URL: source URL: or license: gpl2+ platforms: linux cc (this is kart v2) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Done. Test it out and let me know if you encounter any issues :+1:
and fail in this fashion: This seems to have started to happen in December of last year (see ). This effectively means that using the avr toolchain in nixpkgs means re-compiling gcc on every channel update. Not sure what is causing the log size, unfortunately there's no special hydra meta attr to change the log limit. cc Maintainer information:
From doing local rebuilds of this package and noting how much output it gives, the long logs are from echoing back the compiler commands from make when compiling all of the soft float routines for each different AVR chip. It started dumping all this output when we moved from GCC 9 to GCC 10. Looking at the logs prior to that version bump, make must have been quiet because I see no compiler commands getting echoed back. Is it possible to add something like here?
may be worth a try:
When is installed with , works fine. When is installed with , then prints an error message. When installing with , I get this log: So, it might be that git-with-svn-2.6.3 is fine but not . System: NixOS: = () Nix: = Nixpkgs version: () /cc
I think you have nixpkgs and nixos channel. One might be coming from root. So on one channel it works, on the other it doesn't.
This is a bug in the Perl bindings generated as a part of our Subversion build. The library depends on , but it has no RPATH set that allows it to find library. Curiously enough, is the only dependency with that problem: other library like are found properly using a full path into the Nix store. Cc: and
and it was working fine in :
As I said, this as nothing to do with Git. It's that provides broken Perl bindings.
Ran into same problem. git bisect log of checking ldd /nix/store/-subversion-1.9.3/lib/perl5/siteperl//x8664-linux-thread- follows. there's some big binutils related changes in the middle yet.
On NixOS 21.05, when setting , I could see the result of this settings by running: Since NixOS 21.11 however, altought the masquerade works, I cannot see anything with iptables commands: As discussed on the Discourse topic , I suspect this is linked to the following change in NixOS 21.11 (PR ): Steps to reproduce the behavior: an interface with on a system running NixOS 21.11 the lack of information about the IP masquerade The IP masquerade should be visible like in NixOS 21.05:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Actually, this is due to systemd since v248 preferring to use nftables if available, see Systemd does not use the iptables binaries and but a separate library that creates iptables rules directly without translation to nft by iptables-nft. So even without using the legacy iptables tools, these rules in nftables by networkd would not be visible. Other services that need to add firewall rules like libvirtd, docker or podman are likely getting proper nftables support soon and users still using iptables will run into the same issues. Since we are not the only distribution dealing with this, this should either be solved in systemd (can rules be generated that are compatible to and can be parsed by iptables-nft?) or in iptables-nft by displaying a warning that other nftables rules are active. The only related problem remaining in NixOS is that since our module is heavily based around iptables, our users assume NixOS is using iptables when in fact it is using nftables with iptables compatibility. cc
This particular issue is also giving me issues running docker on NixOS 21.11 in WSL2 on Windows 10. It requires iptables and the docker service fails to start due to docker trying to issue iptables a command and the nftables reply throws docker as an error. Same configuration using systemd v247 via 21.05 works fine
What you're seeing is directly caused by and has nothing to with this issue since the problem described here is that not all active rules are visible. Are we even supporting WSL officially?