jiebi/CodeConvo huggingface dataset:
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. &rarr;
The same thing is happening here on NixOS unstable:
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):