jiebi/CodeConvo huggingface dataset:
In essence, ucode is a blackbox and live-updating ucode is unpredictable black box. For some devices, ucode loading is a must, for others its optional. I suggest that we limit ourselves to specific case of Intel/AMD ucode, for which ucode updates are optional and crucial updates are applied only via hardware flashing. I am pretty sure that the reason why Libreboot supports less hardware has to do purely with acceptance criteria for how tainted ("blackboxed") the firmware is, and that both support little of x86, because Intel refused to provide specifications and AMD was open to some extent, but then closed up the AGESA after Phenom II because they most possibly implemented TPM in firmware(fTPM). About EULA-d + encrypted software, we are talking about closed-source hardware. For manufacturers of such software, surely opposite is true and the updates are usually used to keep their policy consistent and enforced, for users it means giving up and restricting all rights. That said, I found those options myself easily as a new user (yet my hardware functioned without issues without them) and I see a problem if they default to one value, but change "automatically" and unnoticed at run-time. Either way, this option should be documented better - and this includes places where its flipped.
It's not clear what difference does it make. Say, from freedom perspective, it would not be OK to use Windows even if I were to ignore any updates for it. If we ship updated microcode, which includes security fixes foremost, how would that taint installs any more than they currently are, with in-kernel blobs and such?
It has to do with blobs for the most part. See:
It replaces non-free code with a more up2date non-free code. Given Meltdown and Spectre this should be the default. Especially since it would be generated at installation time. Accompanied with the right comment, users who really want to have outdated CPUs will be notified and can delete one line. (well two with the comment).
I would like this to default to (microcode essentially is firmware). isn't supposed to be edited, it should just use so that user can override it in their config.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
still think this should be done, as new users probably don't know this option exists at all and that you have to enable it by yourself in NixOS. With concerns on, this should at least be generated as commented out, with a hint "while you will probably want this, note that it is unfree software".
I marked this as stale due to inactivity. &rarr;
Why is this no longer in discussion? As someone new to the NixOS universe and coming from Ubuntu I wasn't aware that I had to explicitely include this in my hardware configuration on NixOS until I stumbled across other people's configuration files. I definitely think it should at least be prominently featured in the installation manual or even better be enabled by default, as mentioned.
One way or another, needs to be enabled by default. These updates fix security issues, there are probably a lot of NixOS users now that don't even know that they're running insecure microcode. See also the discussion in
I've never replied to the first comment! While I still support the open hardware movement (and thus free software firmware) I also believe that having QEMU misbehave because of a missing update is not really a good default option. If the user is concerned about the microcode updates or about managing security at this level then they will probably read the auto-generated configuration and immediately spot an and will comment it out :-) So thanks for the PR, I can't review because I don't know perl :-p
uses to determine the substitute for the shebang path. This selects the wrong path during cross-builds and results in x8664 binaries getting pulled in as dependencies to cross-built binaries that can't possibly use them at runtime. I don't know if we can reliably pick the correct /bin/sh without it being in the PATH envvar. I presume patchShebangs works fine for binaries that don't overlap with stdenv's and are included in buildInputs. If you cross-build some packages to ARM platforms, patchShebangs runs in the fixup phase and run , you'll see it points to the native /bin/sh rather than the cross one. I was considering a PR to just add to the cross build of glibc, but figured it'd be better if the root issue were fixed instead. System: "16.03pre75806." Nix version: nix-env (Nix) 1.12pre1234abcdef Nixpkgs version: (Gorilla)
/participate. (I've stumbled across this too.)
Is it safe to assume are the only paths that will ever realistically have this problem? If so, how and where would we pull in as a buildInput without it clobbering the native /bin/sh used by stdenv to run the builder? Once we're already executing , it's too late to find any s. This problem overlaps with another, , which is that crossDrvs clobber stdenv's binaries in the PATH. The best solution I can come up with is to manually include in of e.g. glibc, add logic in to not add to the PATH when crossbuilding, based on some new derivation attr like , then search during , independently of what's set in the PATH. Or we could just make smarter about importing /bin/ PATHs that contain elements of the stdenv, namely: .
is essential to fix this without greatly complicating bootstrapping.
don't forget to close. :)
Addressed in
Describe the bug VAAPI records repeated frames (see upstream bug report). upstream fix: To Reproduce Steps to reproduce the behavior: ... open OBS ... try recording using VAAPI (possible AMD hardware required?) ... watch replay Expected behavior full FPS. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
As for 21.0, the fix contained in upstream release = 21.0.2 so e.g. PR
Sadly a look at that thread, it's blocked because something broke, and they're not pushing it to 21.05, so this bug is going to exist until someone figures this out the regression, this patch is only one line of code, maybe it can be supplied as a patch until they get 21.0.3 working? Is there a way to build a patched mesa without rebuilding my entire desktop stack? It's currently stupidly slow on my computer when doing a packageOverride.
This will not be the only bug people will have to deal with on 21.05 unless we backport a more recent mesa (=21.1). Alternative we could also start to includes as well. Without it, this will lead to crashes in wine (incl. steam proton) when on some hardware ( for reference). While one can set as a workaround, it is hardly ideal and difficult to diagnose from within steam alone. Would it be possible to backport the mesa update currently in staging-next () once it is merged?
I don't know... this is hard. Maybe after a version has been a couple weeks in , we might be sufficiently confident that it won't make things worse overall.
I'm okay with backporting it, but probably as its own job set, just to get a better idea of regressions.
I'm not afraid of build-time regressions in this case. Those would be easy (to find). And mesa isn't such a big rebuild now anyway.
If it's been on unstable for a while, I guess I'm okay with it as well
I guess we can close this now, I haven't noticed any problems recently.
Describe the bug nixpkgs has moved to unified cgroups (woo :tada:) as of recently (). Unfortunately, k3s fails to start correctly with unified cgroups without , which isn't included in a release yet. Until that lands in a release and nixpkgs is updated, it can be worked around by setting I intend to work on fixing this; I'll drop any notes along the way in this issue.
I've updated the title to be more specific, since my actual errors are coming from using k3s with , and the error is specifically about kubelet and docker's cgroup driver mismatching. I see that the unified cgroup PR did disable unified cgroups in the k3s module, so that probably should work before adding in the docker runtime. I need to do a little more investigation here.
Please let me know, if this is related: I'm trying to follow the wiki article on kubernetes on nixos: With the configs shown there I run into an error when starting The full error is very long, I've uploaded it here:
Thanks for looking into this.
Just tried the workaround mentioned above: Setting also fixes the problem for the kubernetes service
We have observed that unified cgroups also breaks Kubernetes-in-Docker for node images prior to 1.19. The observed behavior is that the kubelet fails to start, with the message: Also able to work around with
For k3s, the v1.20.4+k3s1 release includes unified cgroups support. It fixes my use of k3s, though I also had to set a flag in the nixos module ( to make docker+kubelet match). I've opened up a PR to bump the package (), and I'll make a separate PR to fix the nixos module to pass that arg. I think those two changes together should fix this issue. It sounds like there's other work to be done for other ways of running kubernetes on nixos too, but I think we should open separate issues for those to avoid conflating too many issues at once.
This would be the fix: I was not invested enough at the time to also write release notes, but if you want you can pick up the change.
see
This PR should also help:
This issue has been mentioned on NixOS Discourse.
Running a fresh fails, the core message being: Steps to reproduce the behavior: a rust project (or if you already have one) Either the rustup gcc/ld to be patched for NixOS use, or rust to use the system gcc/ld. Please run and paste the result.
Actually, it looks like this is an issue specifically appearing with ; so I'll try to pass the message upstream.
Very specifically, introducing the issue, when it has been decided to switch from the system linker to . I suppose the new binaries should also be elf-patched?
Patching those binaries will make them execute, but they also need the applied so that the binaries they build will also get patched automatically.
Trying to compile fails with Install (not ) Create with run observe error
has gmp but doesn't have Base or Prelude (which is needed for stuff as simple as )
For reference, I think this issue is related:
You are meant to use to install additional packages with the compiler. I don't understand why the attribute it broken though from a brief look.
I bisected to the commit that caused this: This was in the idris update from 1.3.0 to 1.3.1 Currently looking into how this can be solved elegantly
In the meantime, is there a workaround for this?
Yes, the PR linked above () fixes this, but I'm not sure what to do with it, because it breaks Darwin in weird ways.
Olaris server requires ffmpeg to be available and raises an error when it can't be found: Steps to reproduce the behavior: olaris-server a library. The software runs correctly. There are two main ways to fix this: the software to use the full path to the ffmpeg dependency (ideally upstream). the program to add ffmpeg to its path. Please run and paste the result.
In fact it looks like it needs a custom image as it passes arguments that only exist on the modified version.
Actually it looks like the fork is no longer required: But this doesn't seem to be released yet. But probably is still a better option than packaging the custom ffmpeg.
yep, this looks like an easy fix EDIT: I was keen to try building the ffmpeg fork so that we can stick to a released version, however that proved prohibitively difficult, so tip of the default branch it is
no action required, but note the way I used in the pr and commit, means this issue would have autoclosed when the change merged
That is what happened.
sorry, I only saw this issue's update and assumed that you manually closed it; I assume most people involved in nixpkgs prs do not have merge perms, and github really needs to work on their ux. terribly sorry for the hassle, and assuming you were a more novice user.
No worries, GitHub really doesn't make it clear.
The current wxmac port fails to build. Build wxmac from latest git. wxWidgets uses some deprecated CoreFoundation functions, which are no longer there. Upstream version 3.0.4 still uses these functions. Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(sperber): nixpkgs:
That's very annoying! There has been a recent update of CF by that uses CF from Apparently they don't implement these deprecated APIs. We should be able to patch it to fix these references and use updated APIs. For now though you will probably be stuck on 18.03 or 18.09 if you need wxmac.
Yeah, I looked into that for a while, but the references to the now-unsupported FSRef type are pretty widespread in the wxmac codebase. :-( (I don't need wxmac directly, but erlang depends on it.)
Yeah, I patched those calls out of QT 4 but haven't gone and looked for other stuff that uses them.
Looking at source, it doesn't look like those functions are really used in any essential way. If you look at who calls , it doesn't really seem to be used anywhere much, and is used to set some icons. Or vice versa, but either way doesn't seem like it would be hard to patch out.
I was thinking the same thing, but my impression was that these are part of the public API of wxWidgets.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Steps to reproduce the behavior: Tested on a MacOS 12.6.7 (Monterey) on a MacBook Pro 2016 (x86) Please run and paste the result.
The logs above say 1.6.1, not 1.5.1 - I think the title needs to be edited to reflect the correct version I'm seeing the same error with poetry 1.6.1 on macOS Venture 13.4.1, 2018 MacBook.
Thanks , that's strange, I'm new on nix and I thought the version nix were installing was the one I got using (). Looking on github the official poetry version is 1.5.1 () while poetry-core is 1.6.1 () but it seems that poetry-1.5.1 is failing. If not, can I ask your support to "decode" the logs? :) Thanks
It's poetry-core 1.6.1 that's failing to build. Try building .
Oh, that's right, thank you. I'll update the title and the notes.
Package name: cypress Latest released version: 13.13.2 <!-- Search your package here: --- Current version on the unstable channel: 13.2.0 Current version on the stable/release channel: 13.2.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! --- The following PR exists but seems to be abandoned: Weirdly enough I am also experiencing that the 13.2.0 version actually delivers 12.17.1, I don't know why...: ! Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
the python binding for krita are not build correctly. Please run and paste the results.
more details wouldn't hurt...
well I don't exactly know what is happening here, to build the python binding, it requires and . So when are to the buildInputs, cmake finds all the dependencies correctly; however, at around 98% the compilation fails due to not finding some sip bindings. Alternatively, if is to the buildInputs, everything works fine as intended. But the python interpreter overwrite the python interpreter in the nix-env, so that doesn't seem to be the right fix.
also tried setting the variable, but that didn't work either.
cc who worked on / in
A clear and concise description of what the bug is. Prism Launcher doesn't allow enabling Feral GameMode or MangoHud under the "Performance" tab because it can't find it. Steps to reproduce the behavior: GameMode ( ) MangoHud ( ) Prism Launcher ( ) new instance in Prism Launcher instance and go to "Performance" tab A clear and concise description of what you expected to happen. GameMode and MangoHud should be able to be enabled when installed. 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.
Addressed here -
Neovim frequently coredump It is hard to reproduce the behavior, it always breaks down in unexpected situations no core dump ! <!-- 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.
It might be caused by neo-tree. I haven't seen any crashes since I moved from neo-tree to nvimtree.
Also pretty sure it's neo-tree, I have the same issue . I've already built debug symbols for and am waiting for the next crash to get a detailed report.
not nixpkgs relevant (report to neovim with stacktrace).
Project description Scala 3 is more than a year old. It would be nice to have it packaged in nixpkgs as well. Maybe it is, but I couldn't find it under "scala-3" or respective versions. Metadata homepage URL: https://scala- source URL: license: Apache-2.0 License platforms: unix, linux, darwin, ...
is already packaged.
Indeed: the Scala 3 compiler started out under the codename 'dotty', and that's how it was packaged initially in nixpkgs. Now that dotty has become the 'official' scala 3 compiler (see also ), we should probably rename the package to as well? /cc
Feel free to update, rename and alias the old name :) Maybe should point at and can be
In combination with 21.11 adding it to the job, this prevents channel. The keymap tests don't have any maintainers. That's quite an issue for channel-blocking jobs, I think.
Well, we could remove from the blocking set, at least for now. It certainly doesn't feel so critical to me. (Though qwertz layout gets vast majority in my country actually.)
In it was discussed wether Linux 5.15 could be the cause, but the way I see it the test is running with Linux 5.10? 5.15 seems only to be used for the stdenv.
Yes, It is at least surprising that a large part of the channel tests is about keyboard layouts.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
if the keymap tests have no maintainers, perhaps they should be removed, or at leat disabled for now.
it looks like its random which one symbol fails azerty fails sometimes too
This test has been flaky since and does not provide much value. I propose to simply remove it from the tested job.
I'm thinking this is a race condition with sending keys too fast, maybe made worse when a builder is under high load. Something like this perhaps?
EDIT: it takes way too long to run the test without kvm so i didn't i'll run the test with and without that. and with running to mimic high load i had to apply this patch to run the test vm because kvm was failing but its very very slow now
So, at least the simple step for now?
the sleep patch does indeed fix the issue, at least when building on my Honeycomb. I do think it's odd though that the test fails in exactly the same way every time I run it. I'd expect it to fail less consistently, or in different ways…
azerty test fails sometimes too
While it's far from elegant, I'd be fine with adding the sleep patch. Since it's only 10ms per character, I don't think the performance impact will be significant, and I'd prefer to start verifying the functionality again (major use case: encryption passphrase input, where the results aren't even visible).
i've run some tests on my rpi4b and found that applying this patch fixes the issue even with load and no delay(i still think we should leave the delay) <pre<del0.02 sometimes works if there is no other load at least 0.04 is needed to sometimes not fail when i run 1 is safe according to this the average inter-key interval of a human is 238ms INTER-KEY INTERVALS Average inter-key interval is 238.656 ms (SD = 111.6). A lower bound of about 60 ms can be observed.</del</pre
Since commit the command is missing. It is used by xscreensaver to display text inside the screensavers like system information and kernel versions. It used to be in the package, as can be seen from this diff: The same applies to which was also removed by that commit Steps to reproduce the behavior: Text is printed when running instead of If applicable, add screenshots to help explain your problem. Add any other context about the problem here. system: host os: multi-user?: sandbox: version: channels(root): channels(pinpox): nixpkgs: Maintainer information:
«removed» here means «same lack of special measures as before» (the lines you cite are just fixes for the installed stuff), but upstream underwent a major rewrite. (Not saying that fix is not most welcome, just that this was not a removal as much as lack of finding out what to do now) Apparently the scripts are there in the tarball, maybe they need manual copying now, not sure
I just noticed it seems to work fine in the previewer application that comes with xscreensaver . E.g.: ! The same screensaver does not work though, when it starts "on it's own" after some idle time. The text then only reads Not sure what the difference is.
xscreensaver-text and others are in $out/libexec/xscreensaver btw speeds up the build of xscreensaver by a lot
Hm, is not in my path, but hacks launched via XScreenSaver proper find text just fine. And the daemon source code implies that is indeed to PATH in a normal situation.
Not sure if it's related, but it is also missing commands like and (output is shown in some of the screensavers). I have enabled xsceensaver with the home-manager option
Package name: LLVM Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 18.1.4 Current version on the stable/release channel: 18.1.4 <!-- 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]:
Want to submit a PR? The last upgrade was very straightforward:
I'll give it a shot