jiebi/CodeConvo huggingface dataset:
Installing causes large dependencies such as and to be pulled in at run-time Steps to reproduce the behavior: that some of the large dependencies such as are pulled in. I'd expect and to be build-time dependencies, and as such shouldn't be needed at run-time The additional dependencies are being pulled in due to , which itself should be a build dependency. FWIW, declares as a make* dependency Please run and paste the result.
not the maintainer for -qt ( is), but I took a quick look at it nevertheless and it seems that gets to in the invocation for even if it is moved to . Unfortunately I don't know enough about the Qt ecosystem to tell why this is the case.
I think that the issue lies in qttools itself, for some reason after , qttools depends on clang and llvm at runtime This doesn't seem to be the case on and
qttools provides a qt plugin so wrapQtAppsHook will add to ‘QTPLUGINPATH’ automaticallyUnfortunately, the packaging of qttools is not subdivided, all output is almost in one packagethis leads to the addition of unnecessary runtime dependencies. ( Actually even may not be needed is required by and , lupdate seems to be just a optional feature dependency on clangbut is not feasiblewe have to recompile to disable this feature Splitting into multiple packages should be a better solutionqdoc/lupdate are often used to generate documentation/translations, almost no packages runtime depends on them This pr should solve the problem of qalculate-qt but this may cause some packages fail to find lupdate. it‘s not an elegant solution
I think it's easier to add a flag to qttools, and only use that variant for building the docs.
should be , set can prevent qttools from being recognized as a runtime dependency the pull request to disable clang-based c++ parser by default
If that helps, maybe is no longer necessary?
For this issue, yes But not sure if there is a package need qttools (qt plugin ) as runtime dependency
I checked all packages that depends on qttools, and found that most if not all of them have a runtime reference on qttools due to it being in . So this problem is actually widespread, we can have the workaround in for now.
Currently we have two expressions that both build the kernel, whose only interface differences are in whether or not the .config is generated or provided. These builds should be merged with the two different interfaces simply being two ways to call the same underlying function, reducing code duplication and allowing the generic kernel builds to benefit from the IMO better structure of the newer manual kernel builds.
+1 on getting rid of duplication What is the "better structure"?
Structure may have been the wrong word, but the manual kernel build uses multiple outputs (suboptimally currently, which was part of the problem with the old PR) and uses the official kernel build system for building and installing, while the generic one (last I checked) had a manually maintained shell script to handle the install and parts of the build.
Fixed by
Our can no longer link executables. For example: This issue is present in current versions of . Compiling and linking works fine with an older revision, say . It looks like this might be related to some change in binutils, maybe?
This is probably from
Yes, it is. came to the same conclusion.
This probably is GHC bug though. Things like gmp and libiconv get their paths hardcoded so this isn't a problem. I would expect the same treatment for elfutils. should provide a arg.
/cc
I guess now I know why there's a patch in branch.
I'll reopen the PR fixing the linking issues.
I opened while we wait on upstream fix.
Which one, from
Yes, although it doesn't help. See
Yes, it would have surprised me a bit if it helped against that symptom -- my patch fixes that DWARF-enabling is skipped completely.
I'm surprised this worked for you back then and now there are linking errors.
Steps to reproduce the behavior:  nixos-unstable Noticed when setting and rebuilding &lt;!-- 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]:
You won't get a reply if you leave that empty.
I'm having the same issue I didn't notice when it happened, but I also have sambaFull
Same error whit the package .
This seems related to
That turned out not to be the issue. The actual error: In colour so that one can actually make sense of C++ error messages: ! One potential problem here: This is because of having: Switching to : Builds Removing entirely (which swiches to ): Fails on new related errors (see below) Removing and : Fails because Ceph requires lua = 5.3 and nixpkgs's default is still 5.2: CMake saysCould NOT find Lua (missing: LUAINCLUDEDIR) (Required is at least version "5.3")` Build failure with : <details</detailsI noticed Arch . But we can just use to fix the build.
PR for the
TEXMF defines the order in which files are read in The idea is that TEXMFSYSVAR and TEXMFCONFIG files take precedence over files distributed with TEXMFDIST, so there is a way for the user to override configuration files. Our lists: This seems all fine, except that our derivation also makes TEXMFLOCAL point to TEXMFDIST as well, and this destroys override-ability. My suggestion is to use a separate and empty $out/share/texmf-local for TEXMFLOCAL.
Could you please provide an example of the override that doesn't work?
I dropped my customization here: It boils down to adding a custom package (minionpro availble for my ) and running: in postBuild.
I investigated your override. I see that you sneak the original , then add your font to it and regenerate the mappings which go to share/texmf-var. At the same time our texlive setup just reuses prebuilt maps provided by (for pdftex), individual font packages and others and those are installed into share/texmf which happens to be also pointed by TEXMFLOCAL. I also now discover that the line does nothing for us. Your change makes sense to me. Makes me wonder if we could do better. For example, not deleting should not hurt anything. I could not find any way to automatically scan for new entries for The Gentoo documentation mentions [1] concatenating it from /etc/texmf/updmap.d. [1]
First of all thank you for taking such a careful look at my code snippet. I really appreciate it! First, yes, I sneak out and later sneak back in. I do think that there are no adverse side-effects from not deleting in texlive.combine. I will submit a PR to remove it. This will minimize my postBuild override to just: That looks much cleaner :) As there is no real "hooks" functionality in our texlive package derivation, it seems to be a good idea to optimistically merge (by concatenation) separate snippets. I will file a separate issue to discuss this.
Thank you!
Describe the bug To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers and edited it last Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I really have no idea, contains it, even bumping gnunet-gtk to be the same release version still doesn't fix it.
Have you tried applying
Describe the bug hides clang arguments in a "response file" by default if is true, but ccache does not support this and responds with "no input files" instead. Additional context The following workaround can be used to disable response files in a result , fixing the issue: Notify maintainers Maintainer information:
I've run into this issue as well. Edit: my bad, that doesn't work; we need the env var to be set before the outer layer of stdenv wrapper machinery runs. By the time we're in the ccache wrapper it's too late. It's also not clear to me if this is a bug in or intended behavior (I was not able to find an issue for it upstream) but it's definitely reproducible:
I tried to build a package with debug symbols today and failed. NixOS wiki and nixpkgs repository comments say the following should work: Please run and paste the result.
It worked in Aug 2018: Bisected down to breakage at : Looks like it stems from the fact that does not expose anymore, only . /cc
Woah. master and both work for me with nix stable.
That's surprising. Here is my attempt at current master checkout: I tried removing and seeing the same failure. I wonder why it works for you. Might be a different stdenv?
Does it mean and are the same object?
i can reproduce
I can also reproduce with stable Nix (2.3.14):
Hmm, the issue is that / slaps the on after is defined, closing over the old . In Smalltalk paralance, this would be an issue of insufficiently "late binding".
Still reproducible on current master ()
I ran into this.
Bump, ran into this while updating the Nixpkgs pin on a project of mine.
There should be a test for this :)
Gonna spend next hour or two trying to fix this.
Things that are also missing:
So, this function is not executed on passed through stdenv. Not yet sure why.
Yeah, I've fixed it (thanks, for being there :heart:)
Post-mortem: always read threads. Solution was kinda already provided in , but I delved right in without knowing that)
atleast you now know more about stdenv :slightlysmilingface:
How is the PR looking? I've been waiting on this for a couple of weeks to debug an intermittent crash I'm having with xfce4-sesion :)
Describe the bug when a root-owned process dumps core (eg recent sshd, due to a known bug) and coredumps are enabled, systemd-coredump warns (but proceeds successfully). To Reproduce Steps to reproduce the behavior: systemd coredumps enabled a SIGABRT to any root-owned process (eg by running ) Expected behavior coredumps succeeds with proper privsep Screenshots Additional context Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Can you reproduce this with a simple c binary you interactively run as root user?
yes, as root does it. amended the original post addendum: if you want a minimal C example that causes it:
still happening regularly due to a bug in openssh (race conditions in process shutdown can cause seccomp filters to trigger)
I am also observing this problem, both sshd dumping core and the systemd-coredump error when it happens. I can also reproduce it with as root.
I can confirm I see the log messages: I looked at . It seems systemd-coredump wants to drop privileges to a user (but falls back to root if it can't find it). suggests we should create it (like we create one for ). I opened , which does that.
(the .0 version has a bug that breaks ) <!-- 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: matrix-nio <!-- 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: 0.18.0 desired version: 0.18.1 <!-- 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.
When attempting to create a volume on a physical node pool parted is not found. Steps to reproduce the behavior: Create a physical disk node pool. Attempt to create a volume using that node pool. In this case I have created a node pool called and I am attempting to create a volume called Volume is created normally. If applicable, add screenshots to help explain your problem. I have tried to add parted manually using and overriding the package in the libvirtd module: but this did not fix the issue.
That won't work, it seems like we need to wrap to include in its . I'll take a look.
You most likely need to add it to in because libvirtd will probably call it.
I sometimes create a qemu VM in libvirt in "session mode", meaning that the libvirt daemon is running as my non-root user, and the system-wide libvirtd does not need to be running (). This VM has a network bridge, which libvirt apparently creates by calling , which in turn uses . The problem is that doesn't get fully populated until the system libvirtd gets started. Previously, in nixpkgs (from February), this wasn't noticeable because libvirtd.service was WantedBy libvirt-guests.service (which is WantedBy multi-), so libvirtd would always be started on boot to populate that directory. Now, with , this is no longer the case, and libvirtd.service does not get started (presumably, if libvirt-guests.service actually needed to start a VM, then libvirtd.service would be socket-activated, but for me this is not the case). As a result, doesn't get populated and my session-mode libvirt can't find . python: The VM's XML file defines a network bridge, which is why gets involved. the following output: The libvirt user session should be usable without first starting the system-wide libvirtd. If you start (and optionally stop) the system libvirtd.service before following the steps to reproduce, everything works fine, because the directory gets populated. Probably, should be put somewhere else, where session-mode daemons can use it without needing to have previously started system-mode libvirtd. (The same may be true of other stuff in too.) libvirt maintainers: Okay, but I'm using flakes and that channel looks old. See relevant commit hashes above.
Oof, happy to find this, it would have taken me a long time to figure out I needed to run first. Can't the sudo wrapper point to the file in the nix store?
It is possible to use Plasma’s native file dialogues in Firefox 64 to open or save a file. Currently this feature is not working in NixOS, and it seems to me some small changes would need to be made to derivation in order to enable it. I propose we include this option together with as a Firefox option in NixOS (see also: ). I followed the explanation on how to enable this feature as it was published on : Firefox (64 is current stable) from a terminal emulator But it produces the following error: system: host os: multi-user?: sandbox: version: channels(root): channels(hook): nixpkgs:
You'll probably have to do something like this to expose the dbus service:
Where? In:
It needs to go into a nixos module or your .
Directory renaming is now out of scope This directory is also being used as the way to get access to the host machines gpu drivers. I think it's another source of confusion for many users to have to add so that they can get a vulkan game / cuda workload / opencl workload to work. I think we should deprecate this prior to the 21.11 release, and fully move it to something like or something more representative of the desired affect. This was done in cc EDIT: roadmap (2.5 years later... lol): addOpenGLRunpath -addDriverRunpath Init addDriverRunpath: Deprecate : -autoAddDriverRunpath Init autoAddDriverRunpath: Deprecate cudaPackages.autoAdd{OpenGLRunpathHook,DriverRunpath}: NixOS Module changes: TODO
For the transition period ( NixOS 21.11), I think keeping the old would help alleviate a lot of the pain, would just like to get the ball rolling away from using explicitly
I agree. Also, on a related note, having to specify your graphics driver at the xserver level in the module system feels wrong to me. I'm still not exactly sure how it maps given names to driver packages either.
I propose two changes: move -- make a symlink to for backwards compatibility of existing derivations -- add a
potential future work as well: -- Until 21.11 EOL, have it add both and , to avoid system vs package invariance
I'm also kind of wondering whether is just another fallacy in naming, and we should really be exposing something like, would be even more appropriate, as other hardware-accelerated devices such as tpus, fpga's, and others would also likely need to import "libraries which are determined by the system, and need to be available at runtime".
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Should we, in addition, consider using a libc-versioned directory? Motivated by
Decided to rename this issue since renaming the underlying path was deemed too risky for potential breakages.
Could you provide some context as to why? My naive assumption was that we'd have a new path but: have both new and legacy path to rpath via the hook; new path preferred provide a legacy symlink pointing at the new path in NixOS which would be quite trivial.
TBH, I'm not sure how much value there is to migrating the filesystem path (unless we splay the paths further to increase granularity). I suspect what users see in practice is the nixos option path
For the NixOS module change, I came up with these terms: acceleration API = an API standard which intends to provide hardware-assisted compute acceleration such as OpenGL, Vulkan or CUDA driver = userspace library component which implements one or more hardware-based acceleration APIs The usage of the NixOS options API would then look a little like this: Individual drivers would also have a option which is a package selector for the specific package to use aswell as driver-specific settings. (More on the package selector data type when I have a more concrete implementation but it'd allow setting 64/32 bit using a single value.) Each acceleration API would have a option which is an attrset with driver names as keys and package selectors as values. These could then be overridden indivually. The intention behind this is to enable use-cases where e.g. different versions of the same driver are required for different APIs or a specific driver must be disabled for one API but enabled in all others. All enabling a driver would do would be to insert the driver's package into the options of all APIs that it implements. Additionally, accel APIs have a option if the API supports setting one and of course API-specific knobs. Here's an example of how a non-trivial driver config could look like: It's currently not possible to know which implements which driver and all drivers are thrown into the same directory but the NixOS API drafted above requires this information for fine-grained control, so we will have to define an interface here. I've been thinking of defining the output to contain all driver bits and subdivide it into driver subdirs like this vulkan/... cuda/... opengl/... Alternatively, I had thought of using multiple outputs; one for each driver. I kinda like that approach more as it generally strikes me as cleaner and has the potential to reduce closure size ( is ~200M) but am not sure about potential naming conflicts or other downsides of those. In light of this, I'd also like to propose to split the global lib dirs into accel API subdirs for clean separation. Though as said, the NixOS options are a lot more critical to UX and therefore the first steps.
Global path name and other changes are almost entirely tangential and could happen independantly but I'd appreciate if they came after the NixOS options changes such that we can let the knowledge we gained from the NixOS options influence their design. Anyhow, that's my current draft. Let me know what you think.
My naive assumption was that we'd have a new path but: That was my initial take as well, but there's community projects like nixGL and others who likely have hard coded the path. And there's a potential that we could never fully remove it without breaking someone
Forgive my ignorance, but wouldn't it be ok to make those kinda breaking changes by deprecating in one release and then removing one or two releases later? Surely nixos isn't promising to never change paths because someone might be using the old location? EDIT:I don't mean to imply we shouldn't consider non-breaking options where possible
nixGL only sets the LDLIBRARYPATH? Although in all probability we must break someone's workflow... Fun fact: cudaPackages don't ship the driver (except for for jetsons). All the relevant stuff comes with nvidia_x11 or with the datacenter driver. Interesting. Would we somehow have to filter the glvnd/opencl loader/vulkan loader configs that come with the drivers to enforce that the declarative configuration be implemented?
nixGL appears to be actively maintained. I don't think we need to worry about breaking it as they can simply adapt. Also, we could simply keep providing the old path in both NixOS and binaries with a preference for the new path and that should work out fine. Oh, okay. I'll leave it to you CUDA people to figure that out. I will only be lifting drivers to this interface on a best-effort basis and the rest will keep using their legacy interface with a minor implementation change. Though if you forsee possible issues you could have mapping your driver to this interface, let me know so that we can design the interface better from the start. That or simply write our own. Though I'll only be adding the option where it is feasible; currently, I only know that Vulkan has sane mechanisms for this. Some issues I still need to think about:How to handle drivers that only support 64 bit?
Will have to filter that somehow How to handle APIs that can only have a single exclusive driver? Only have a option on the API, rather than ? Have but only install the default driver?
I think NixGL doesn't care about , it probably just exports an ?
The original protest against renaming the path: I feel more strongly about the NixOS options being intuitive than the implementation consistent.
I think was more concerned with it being placed under rather than some other directory in because is very much NixOS-specific while the current is not.
I believe I got all of the packages. Once merged, I should be able to deprecate
This thread is over my head, but I would like to check it , , and need the same? All three have GPU or CUDA support options.
This is more about deprecating usage of the term , as it's a bit of a misnomer. I don't see usage of the legacy OpenGL helpers in those packages.
Talked to , we concluded that we can close this ticket and have a more "NixOS options" specific ticket to represent that work.
Going to do one last pass on documentation to ensure all references have been updated. I'll close this ticket after that sweep
I wonder if needs an update. I'm not offering a PR because I'm out of context. Arrived here from a warning in nixos-rebuild. And I'm still wondering how this is being triggered [still investigating].
Arrived here from a warning in nixos-rebuild. And I'm still wondering how this is being triggered [still investigating]. It should come from the toplevel scope now, so it should never need to default to pulling them out of cudaPackages. I can update the nix expression though.
Currently it's only possible to configure kanata by specifying specific parts one at a time. It's not possible to read a configuration from a file and use that instead of the specific parts. I use HomeManager to manage the kanata configuration file and because it's also used for Windows this is the most platform neutral way for me without duplicating parts of the configuration. As a workaround I did it like this for now: But clearly that is not ideal. What I would want is to just keep the 'readFile' and uncomment the 'defcfg' part from the configuration file ()
I created to address this issue. Could you help test it?
Thanks a lot for the fast solution! I tested it with my config and it works without any issues.