Project description An end-to-end encrypted, peer-to-peer file storage, sharing and communication network. It's written in Java and uses IPFS. A bit similar to Nextcloud. Metadata homepage URL: source URL: license: AGPL3 platforms: linux (JVM)
Related:
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Still important
I marked this as stale due to inactivity. →
Still important
I marked this as stale due to inactivity. →
I've a working package of peergos. after some testing i've experienced it a little buggy, so i don't want to push it into release. Let's see what i can do as it's my first package. The example bug: after i've created task, clicking "tasks" from left menu forces me to create new task. However thecreated task is visible in my drive.
Thanks!


Virtualbox corrupts guest filesystems by randomly flipping bits when the guest writes data to the virtual hard disks. virtualbox on the host with a new virtual machine for linux 2.6/3.x/4.x with default settings (1GiB RAM, 8GiB harddisk). "Insert" a linux live medium into the virtual CD drive. The virtual hard disk should be placed on a filesystem on a physical hard disk (the bug cannot be triggered if the virtual hard disk is placed on a tmpfs, see below). the machine and open a root shell after booting. these commands inside the guest's root shell to write random data onto the hard disk, then read it back and compare it: Caution: This will overwrite anything on the guest's virtual hard disk The shown hashes should match, but in 90% of test runs, they won't. This bug makes virtualbox quite unreliable: It is still possible to install NixOS inside a virtualbox, but during installation, Nix will report a couple of checksum failures, and sometimes the installation is to be tried more then once. After that, random failures of random programs occur. If btrfs is used, this will also complain about checksum errors. After observing this on my production machine with NixOS 22.05, I tried narrowing down the offending commit. To this end, I adapted the nixpkgs minimal live cd build recipe to build an image with virtualbox installed on it, and built this agains different nixpkgs versions. So most of my tests have been performed on a test machine booted from a usb flash drive. The offending commit seems to be . I guess that commit brings in some kernel patch, which is incompatible with the way virtualbox handles disk images. The bug occurs when the host's filesystem containing the disk image is or . In both cases, I tried with freshly created filesystems. The bug does not occur if the disk image is on (or it occurs with very low probablity). I haven't tried any other filesystems on the host. Just to be sure there isn't a general problem with virtualization: I failed to reproduce the bug with qemu and a qcow2 disk image. So it seems to be a virtualbox-only problem.


I observed the bug on three different machines (two desktop machines with NixOS 22.05 and NixOS 21.11, and one laptop with NixOS 21.11). I was also able to reproduce the bug with a linux live cd inside the guest. So the bug can probably be triggered by any linux in the guest. I haven't, however, tried with anything else (e.g. Windows). I was also able to reproduce the bug with a live iso based on (currently ), i.e., with virtualbox 6.1.30 (as opposed to virtualbox 6.1.34 from , currently ). By default, the virtual disk controller has it's checkmark "Use Host I/O cache" turned off in the vm config dialog. Turning it on doesn't help (). I cannot reproduce the bug with these linux kernel versions (all checked with current ) (4.19.247) (5.4.198) (5.18.4) So users of these kernel branches are safe ... until the breaking kernel patch also reaches these branches. <details<summaryFor the record: This is the build recipe I'm using for the live iso</summary<p</p</detailsMaybe I can try to bisect inside the kernel sources, but the compile-reboot-test cycle is quite slow on my machine. Strangely, I cannot find any reports about similar behaviour. The closest report might be . It would be interesting for me if this bug can be reproduced/verified by someone else. I'm not sure if this should be considered a kernel bug (the kernel should probably not change the way disk writes are handled), or a virtualbox bug (at the moment I don't know of any other software affected). kernel maintainer team: virtualbox maintainer: (by the way: I'm surprised there's only one maintainer for virtualbox. Thanks for your good work, ; I'm a heavy user!) This is my production system, which also shows that bug. But I did most of the tests to reproduce the bug and narrow down the cause with live iso images based on current ().
I bisected the linux kernel tree to find as the cause for the guest data corruption. Googling the commit's hash leads to this issue in the VirtualBox bug tracker.


According to the information therein, the bug only occurs on some CPU models. The issue there also contains two patches: from This one fixes the problem on linux 5.18. It got already included in nixpkgs' master branch with . It is on it's way to being backported to NixOS 22.05 with . Note that this patch contains several clauses and does not fix the problem on earlier LTS kernel versions. from This one fixes the problem on linux 5.18+, but also on LTS kernel versions. I tested the following combinations with (currently on , where VirtualBox 6.1.34 with and linux 5.15.51 are used by default): VirtualBox version & patch 5.18.8 -----------------------------:------: 6.1.34 + OK 6.1.34 + OK I also tested the following combinations with (currently on , where VirtualBox 6.1.30 and linux 5.15.49 are used by default): VirtualBox version & patch 5.18.6 -----------------------------:------------: 6.1.30 won't build 6.1.34 + OK 6.1.34 + OK To replace VirtualBox 6.1.30 with 6.1.34, I cherry-picked . All tests have been performed on an Intel Core i5-4460 as host, by repeatedly writing/reading 4GiB of random data onto/from a virtual hard disk. Based on these tests, I suggest to use VirtualBox 6.1.34 with the in NixOS 22.05 and in NixOS unstable, as currently, both channels will exhibit the bug in their default configurations (i.e., with kernel 5.15). I will submit a pull request for master shortly.


qimgv fails to build when . Steps to reproduce the behavior: No build errors. N/A. N/A. Maintainer information:
I am working on a patch to OpenCV to fix this issue correctly. In the meantime, you can replace with and it will build and operate properly. On my system I also had to add to to stop it crashing when I tried to open a file dialog but maybe that is just because I run Nix on Ubuntu instead of NixOS.


Cannot view any content when running the program because it complains about missing binaries. Steps to reproduce the behavior: to watch any stream No errors, stream works system: host os: multi-user?: sandbox: version: channels(admin): nixpkgs: Add and as runtime dependencies because the following works for me:


There are a few more flags we should enable on : - (I had to add these flags for the sake of something that depends on secp256k1 - I don't remember for sure, but I think it's bitcoinj.)
The schnorr flag appears to be gone in the latest version.


Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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]:


<!-- 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: gping <!-- 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.2.1 desired version: 1.2.6 <!-- 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.


It would be nice if generated and options (only ). Processors without microcode update might run with misbehaving flashed microcode: /cc
Do you mean like setting it to or just mentioning it? It's a good thing for sure to have working hardware as opposed to not working, but OTOH it pulls non free code...
Of course setting it to true (actually to ), mentioning it would have no effect. First, already pulls in literal unfree code, e.g. Wi-Fi drivers on MacBook Air 6,x, not even redistributable. Second, non-free code is already running on Intel processors, I don't see any difference whether it's flashed or not (I know this is controversial). Third, for purposes of Nixpkgs, is free. And of course the kernel contains a whole lot of firmware blobs.
Strongly disagree here as its an equivalent of setting = true; thus will taint every installation by default, which is a reverse policy of the current nixos from optin to optout. That said, being complete new user, I have myself figured and found these options myself. My system booted without them likewise fine. In general, AMD patches CPUs with AGEISA BIOS updates, so does Intel - however these updates are optional and up to the user. This is should be mentioned on a) Installation page b) NIxos wiki - not be made default option, because this action is in conflict with policy.
I disagree that this is equivalent. CPU comes preflashed with microcode, BIOS comes with updated microcode for the processor to boot correctly (microcode that comes with CPU is very buggy and usually can't go through boot sequence correctly). It's not clear how it would add to the problem if we were to load an up-to-date microcode image. This is equivalent to shipping firmware to users that haven't set flag, which is current NixOS policy. Intel microcode is freely redistributable AFAIK.
The default state for these two switches is very clearly "disabled", plus they have no affect on non-AMD/intel CPUs. Flipping the switch in hardware-, is basically flipping the default state in the backstage, which is much worse than setting the defaults to "enabled", as it creates distrust and inconsistency cases. Further, firmware updates can cause real issues, not only solve them.


It is irresponsible to think that they only solve issues. AMD AGEISA updates on 785G on has actually been broken for over a year for me, refusing to react to USB events on boot until I manually bypassed the tier 1&2 support (which is hell of a job for Linux user) to get to actual support for testing. About Intel, I have only encountered issues with gen3 PCIe cards in Intel motherboard for 2nd gen Core CPUs, but fixing this also required a year of waiting and UEFI reflash. Also speaking as an owner of HP() and Epson(sx525wd) printers - updating ucode actually caused hardware reflash and made legally purchased cartridges worthless. I am yet to encounter a CPU that can't pass boot sequence due to buggy ucode, but I doubt hot-loading it on OS stage would fix it, because it needs first to get to this stage. However I can clearly imagine the unpredictability if these switches are properly enabled.
Microcode is essentially a firmware for the CPU. NixOS, more specifically, the Linux kernel, will load firmwares for any device with support for that without asking the user. Loading microcode updates does not require a policy change, if anything, this would make the policy more consistent across the board. On a tangent, I don't understand why anyone would tolerate a blob flashed on CPU, and in BIOS, but would not tolerate the same blob being loaded by the kernel. That can be said about any software. Usually, the opposite is true. What I mean is that every BIOS except Libreboot contains microcode blobs that it loads onto the processor early in the boot sequence. Without that blob, boot sequence will most likely fail somewhere along the way. That's the reason why Libreboot doesn't support modern Intel/AMD CPUs, and why there is Coreboot/Libreboot split in the first place.
You are mixing very different cases into one bottle. Some hardware requires ucode to be loaded to function and won't function without. Some hardware has optional ucode updates. For this hardware, some classes load firmware update and then flash themselves - some lock the possibility to install previous revision, and some classes load the ucode as temporary override (which is case with AMD/Intel). Some hardware has open firmware (sources), but majority does not offer source.


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


Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.


via In short: rainloop, a php-based webmail client, features a trivially exploitable stored xss vulnerability. Upstream is unresponsive, and seem to have ceased development. This page explains how the XSS works and proposes an unofficial patch: Example of an other distro applying this very patch:


Package name: keepmenu Latest released version: 1.3.1 Current version on the unstable channel: 1.2.2 Current version on the stable/release channel: 1.2.2 Notify maintainers Note for maintainers: Please tag this issue in your PR.


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.


There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


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


Project description Yark lets you continuously archive all videos and metadata for YouTube channels. You can also view your archive as a seamless offline website. Not a high priority request, but could be useful. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin (anything with Python 3)


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


Steps to reproduce the behavior: auth0-cli from the unstable Failing to fetch sources following The 1.5.0 release from Auth0-cli has disapeared from GitHub Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


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


Project description A dbus api to start programs on a different GPU Metadata homepage URL: source license: gpl3 platforms: linux
Duplicate


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


We already have in , but only with iptables support. It would be nice to have the nftables version available as well.
Being worked on in , I'm trying to test myself but couldn't make it to work yet.
I think the PR is ready now, testing welcome!
Maybe add an option for will be better?


Project description Hardened patchset got released for Linux 6.6. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi, created the following merge request. Would appreciate a review.
will try to check that tomorrow's morning if my ibs allows me to, thanks


Originally spotted by (thank you!). Steps to reproduce the behavior (assuming and are both ): The environment variable contains semicolons and must be quoted, otherwise bash will interpret the semicolons as command separators.
- Hey, I am not sure how to clean up the mess I just made on . Really embarrassed. I intended to rebase and hit merge instead, which pulled in 10k changes.
No worries, Happens to everyone at some point :) Personally, I'd just open a new PR.
Here it is: . Does the commit history look clean enough? I'll try to rebase it later, but I am concerned about retagging all of those folks.
I'd say don't worry about it -- as far as best practice goes, I'm actually not sure what's recommended for commits. do we recommend squashing before merge? I know I typically just do force pushes to avoid any commit history :l
I went ahead and squashed, and I'll post a nixpkgs-review when it's finished.
I don't think we have an official stance on this. Contributors use their best judgement for whatever keeps the commit history simplest and easiest to use


Describe the bug In NixOS 20.09, Emacs now has the output of gtk+ in its closure, which in turn causes it to pull in stuff like mesa-drivers (424 MiB): This caused the closure size of Emacs to increase from 339 MiB in NixOS 20.03 to 1324 MiB in 20.09. Metadata NixOS 20.09..
cc
This was reverted in
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Steps to reproduce the behavior: g810-led Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Package name: Latest released version: 555.42.02 <!-- Search your package here: --- Current version on the unstable channel: 550.78 Current version on the stable/release channel: 545.29.02 <!-- 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]:


I'm trying to install joblib for python 2.7 on a Mac, but the threading and multiprocessing tests fail. System: Darwin Kernel Version 13.4.0 Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: "16.09pre83147."
As I mentioned in you're not supposed to install Python libraries like that. Even so, the error is still a bug. Unfortunately I'm not using OSX myself so I can't be much of help I'm afraid. I do know there are issues with multiprocessing on OSX with Apple vecLib / Accelerate.
Ok, now I know you have to use nix-shell to load python libraries. Just adding here that gives the same error.


, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc


, CVSSv3=9.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc


gv crashes with a segmentation fault immediately upon starting, before a window is visible. This happens even with an empty dummy document (created using latex and pdf2ps). For ease of reproducibility, you can find it . $ nix-shell -p gv [nix-shell:~]$ gv Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Thanks for merging! Glad that this is fixed. :-)


Steps to reproduce the behavior: error occurs is installed as a standalone binary. There is custom configuration: The test that fails is : I would, but it depends on coreutils. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Seems like a "known issue" without a solution with cephfs and that test: If you can use default path for store instead of: you won't have to build it yourself as it should be fetched from instead.
Unfortunately, I very much cannot use . Given that it's a known bug with that test, would a PR disabling that test likely be accepted into nixpkgs?
Maintainers for in nixpkgs would probably be able answer it better. But you can always overlay/add patch to your own config. Considering you are already building everything from scratch there won't be that much difference there.
Not sure why this wasn't auto closed.


Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: -


The Haskell package chell does not build due to missing dependency . I think this the culprit: Try to get a nix-shell with purescript and nixpgks pinned to . Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(stefan): nixpkgs: (Note that this fails with a pinned nixpkg, see above.)


During systemd-boot update step attempts to touch EFI variables, even when is set to . Steps to reproduce the behavior: NixOS 21.05 with systemd-boot and to NixOS 21.11 () switch fails with: An error is just an indication of update trying to touch EFI variables. (I have EFI vars touching disabled on that system because of some unrelated firmware breakage) Manually running properly finishes, further switches work fine. systemd-boot update should not touch EFI variables during upgrade. <!-- 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. Maintainer information:
I had a similar issue which I fixed by running "sudo nixos-rebuild --install-bootloader switch"
The fix for this got reverted in


Describe the bug The menu icon for Stepmania is missing. To Reproduce Steps to reproduce the behavior: to find it in the Applications menu. Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I marked this as stale due to inactivity. →


Steps to reproduce the behavior:
I don't have an M1 to test
Oh, it suffices to use . I'll open a pull request.


Steps to reproduce the behavior: truststore Output of : Adding to solves this issue. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Describe the bug fails to run because setuptools is no longer propagated implictly. If were purely a python application built with then we would just need to add to propagatedBuildInputs and be done. However, is not simply a Python application, but a wrapper around , and isn't built using. The derivation patches the script as follows: This does result in the site-packages directories from all python packages ending up in , including setuptools (e.g. ). I'm not that familiar with Python packaging but from experimenting I found that the full path to the Python egg needs to be included (e.g. ) in order for this method to work. I made an attempt at resolving the issue but being new to Python packaging in Nix, neither are likely to be ideal: We could use buildPythonPackage in place of mkDerivation, using and use Or continue to use mkDerivation and manually set for patchPythonScript: I'm happy to submit a PR but I'm not sure what the recommended solution is here. To Reproduce Steps to reproduce the behavior: Expected behavior should launch with the extension loaded: Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
It seems is normally used by adding a to , or calling with (what the wrapper registered in does). This script then just does some addition calculations to register itself (we probably don't that at all) and some python 2 specific fixups, and then calls , which starts executing some code on import. I'd suggest to package it as a regular python application first (via ), so you can successfully import it inside a . The python tooling should automatically take care of patching the python shebang properly if you make script executable.
proposed fix


Unfortunately I can not pinpoint the issue, but it seems that after a on Feb 1st, starts to omit a key file out of 3 key files and completely fails with a fresh system installation. Steps to reproduce the behavior: .nix contains the following lines All three files exist on disk. -rebuild switch produces a initrd-secret archive that is missing the third key file. system installation produces the following: All key files are included in generated initrd-secrets and does not fail. This issue does not exist before system update. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --This option is declared in <nixpkgs/nixos/modules/system/boot/stage-1.nix. Please run and paste the result.
I specifically installed an encrypted root on zfs system with . GRUB will decrypt disk on boot and initrd will re-decrypt disk partitions and swap with the keys embedded here.
I have that too, there seem to be a problem with here: Not sure where it is set from, but its value should be relative to the chroot, e.g. , not . It can be worked around by setting to an existing directory before installing/rebuilding, for example: Or by preparing a directory with yourself:
May be a duplicate of
Duplicate of indeed.


When trying to start the App from the launcher, nothing happens. In the terminal starts the text based version, but typing throws the following error =Source: Also check: And this is my system: !


Building uses more () threads than it should (i.e. 2 if / ). Steps to reproduce the behavior: as the build will use way more than 2 cores. Build should honour properly. This was with . This does not in fact use just 1 thread. :smilingfacewith_tear:. ! Happens on master () and 22.11.
I don't have any time planned to fix this but if you figure it out please send a PR.


I ran into a problem when trying to install PHP + PECL extensions (via package). When PHP compiles, it installs extensions configured during build into a default directory like which differs for each PHP version and compile configurations (like ZTS support). When installing PECL extensions via ontop of PHP, they are installed into a fixed directory which makes it impossible to load those via (without knowing the absolute path) as PHP expects them to find in . In scenarios where you define your outside of nix context, it is impossible to load the PECL extensions. I wonder if a consistent extension directory for both PHP and PECL extensions could be established. Maybe the PHP package could set the (see ) environment variable to before like it is done in the . That would make it much easier to configure PHP extensions. See my profile to get an impression: /cc


Describe the bug I don't know if we should just update it or not. To Reproduce Steps to reproduce the behavior: on master Expected behavior Screenshots Additional context Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(bbigras): channels(root): nixpkgs: Maintainer information:
I can reproduce the issue locally It used to build previously The current is not in the Hydra cache because was never built by Hydra, so, unless someone else has the , we can't compare Upstream tag doesn't appear to be updated, git repo doesn't use export-subst It is not clear to me what has happened here.
Dear all, the tag v1.7.4 has been changed after October 2019. It was not published for long as it involuntarily got into a commit. There have been no public releases for v1.7.4 marked on Github or our the FIRESTARTER Website as of October 2019.
Thanks everyone for the help. :heart:


Package name: clipboard-jh Latest released version: 0.9.0 <!-- Search your package here: --- Current version on the unstable channel: 0.8.3 Current version on the stable/release channel: 0.8.3 <!-- 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]:


Describe the bug As of rust nightly 2020-06-22, Rust nightly cannot find This issue is not present in Rust nightly 2020-06-21. To Reproduce Steps to reproduce the behavior: Expected behavior rustc works Additional context This also happens with rust nightly from Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(jade): nixpkgs: Maintainer information:
We are currently using in internally to set the elf interpreter. Looks like we need to extend this to also extend the RPATH to add zlib. If someone makes a PR, I will review it! Not sure when I would get to implement that myself.
Here is where we add :
I'm working on a patch for this. This is definitely the issue, just need to find the right way to extend the RPATH. I have something replacing it with a path containing zlib, but that overwrites the existing , which breaks it. I would like to verify what is setting there but hardcoding it should provide an early fix
Extending the RPATH seems not to have worked
I'm investigating patching the files in lib This issue may have been introduced by rust-lang/rust so it's likely the new zlib dependency shows up in the LLVM libraries


tests link to , however is not explicitly included in of . This issue is normally hidden, because (for example) links to and so it is brought along as a transitive dependency of . However, may not always be set to . For example, doesn't link to . As a consequence, applying the following overlay and attempting to build results in the following errors: does list in its , however actually refers to that only includes the wrapped compiler binaries. If my understanding is correct, is provided by instead. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


name: hilbish I guess? dunno how to use current version: 1.0.4 desired version: maintainers: Please tag this issue in your PR. I tried to update it myself: But that's not enough to get it to build and I have no experience with Golang stuff: Also: This is outdated. , and the releases have pre-compiled builds for both of them as well: !


Steps to reproduce the behavior: firefox-unwrapped from master branch Please run and paste the result.
The hash listed in has apparently changed at 16:36 UTC today. The tarball was already available earlier than that, so the release apparently changed later that day. That would also line up with the hash you are seeing. ` In fact, we have the same hash as e.g. . Will investigate the change shortly, then update the hash.


Describe the bug Just lost on two different NixOS machine my Signal Desktop history because of this faulty update... I don't know, probably doesn't make sense for people to downgrade who are already upgraded but for others it dataloss To Reproduce Steps to reproduce the behavior: Signal Desktop Signal Desktop you to delete db, if you interact in a wrong way it will delete your data Notify maintainers ( and
Sorry to hear that. I recently lost my history too... It's really frustrating! Yeah, unfortunately I don't think there's anything we can do about it (as downstream package maintainers). AFAIK the source of the bug is still unknown, it doesn't seem to affect all users, and all releases have a limited lifetime ("expire" 90 days after the release, see my comment in ). Thanks for saying that! This really bothered me too... I just didn't say anything because I was too angry to keep it nice enough. (I raged a bit here but after I realized that one cannot even import old backups I had to take a break.)
I just got hit by a similar issue by moving from Archlinux (encrypted database) to NixOS (non encrypted database). After many things, the easiest fix to ensure proper functionalities IMHO is installing: This will disable tracker3 and prevent SQLite to be loaded in the process which will replace SQLCipher and cause the SQLite3 API to be the original one (i.e. non-encrypted) and cause many issues down the road I guess. That might not fix everything though :upsidedownface: Opened a PR:
FYI, in case anyone has feedback/suggestions: We might merge soon and it should cause another "Database startup error: Error: SQLITE_NOTADB: file is not a database" error (which is really unfortunate but not easily avoidable).
Heads-up: I've just merged to hopefully resolve this once and for all and the Python wrapper script should take care of the database re-encryption when launching Signal-Desktop as usual but the user experience isn't that great and you probably want to backup first in case the script fails unexpectedly.
Thank you, I just upgraded Signal on my computer and the re-encryption did work as intended


With and , I still have to type my LUKS passphrase in qwerty. The logs say this: but not much else apparently. The vconsole is set up fine by the time I get a login prompt.
Dup of


The option, which enables by default on high-resolution displays like my 4K laptop screen, is supposed to set the console font within the initrd before displaying the LUKS password prompt. However, with , this does not happen until stage 2, so the prompt is tiny. Enable , , and . The console font should be switched before the LUKS password prompt, not after.
Relevant code is probably that it sets . should then properly set everything up if it can find its files in :
Does it work when you do ?
No, it can’t, because points to a font file that’s not present in the initrd.
This works though. It’s a little jarring in that the font is changed about a second before the framebuffer resolution is changed, so it’s temporarily huge. Ideally those would happen simultaneously. But at least they both happen in time for the LUKS prompt.


The is from over 3 months ago. Some background info: Previously it was updated automatically by bot that runs . But the last builds have failed, e.g.:


The emacs package fails to build against the poppler version introduced in . See upstream issue vedang/pdf-tools. Steps to reproduce the behavior: should build Build log: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I'm seeing the same thing.
Same for me
Here's a work around:
Since above PR is merged and pdf-tools builds on current HEAD, I will close this.


Scream does not compile with jack support when it is explicitly enabled through an overlay. nixpkgs.overlays = [ (final: prev: { scream = { jackSupport = true; }; }) ]
Error message?
There is no error, it just skips compiling it. someone else ran it and i think they said that it skips compiling it with jack support because soxr is missing -- Checking for module 'jack' -- Found jack, version 1.9.19 -- Checking for module 'soxr' -- No package 'soxr' found
See . In the meantime, you can try: nixpkgs.overlays = [ (final: prev: { scream = ( { jackSupport = true; }).overrideAttrs (old: { buildInputs = old.buildInputs ++ [ ]; }); }) ]


In the vault options, vaults can only be mounted as . Steps to reproduce the behavior: cryptomator to a vault options the tab, the combo box does not contain a FUSE item Vaults can be mounted as FUSE volumes In the console output, cryptomator seems to have access to the fuse3 libs in its PATH: Full console output:
I think this might be related to It seems since they switched to the new fuse integration they only search a predefined number of paths. This is also consistent as the nix build of cryptomator works on non nixos linux.
I have the same issue. Does somebody have some workaraound yet? EDIT: so what I am currently doing, which is really not ideal, is just mounting the webdav directory with rclone, which, well, uses FUSE. so yeah rclone has no problems with using FUSE...
The fix for this is merged but not yet released It's in the 4.0.0 milestone of fuse-nio-adapter. I'm currently using the flapak version of Cryptomator.
thank you for the answer! i don't quite understand what is. Is it a dependency of ? Is there a way to manually fetch this so that it works? I'm gonna try the flatpak version of Cryptomator out, thanks for the hint. I actually tried out appimage, but that didn't change anything.
In the 1.11.0-beta2 release of cryptomator, vaults are able to be mounted as FUSE volumes. So once 1.11.0 is fully released (and the nixpkgs version updated), this issue should be fixed. Until the new version of cryptomator is released, you could create an overlay to use the beta version, like I am doing at the moment. Apart from changing the version and hashes, I also needed to change the jdk used to a jdk21 and overriding it to enable JavaFX:
thank you for your response! i hope i am not rude to ask for your help in achieving this myself. i put the following in my : and i also did the overlay.


i get the following error when building: haven't been able to successfully find a solution via search engines...
For overlays, I simply copy the nix files and doing the following overlay: This is quite crude, and there is probably a better way to do it, but it at least avoids any weird errors like the one you are having.


Hello, I recently submitted a pull request to update Tailscale in the NixOS repository (). After updating my laptop, I noticed that Tailscale has indeed been updated. However, upon checking the Tailscale dashboard, I discovered an issue with the displayed version number. Here's a screenshot that demonstrates the problem: ! It's possible that something has changed on Tailscale's end, which may require us to modify our build script accordingly. Unfortunately, I am not well-versed in Go yet and could use some assistance in resolving this issue. Any help or guidance would be greatly appreciated. Ping maintainers:


Steps to reproduce the behavior: stig I got this when switching from 23.05 to 23.11 system: host os: multi-user?: sandbox: version: channels(root): channels(ao): nixpkgs:
Thanks for the report, this is supposed to be fixed in . I will wait for Darwin CI to be green there and merge it. Ping me if I forget. Follow that PR at:
Great, thanks!


Steps to reproduce the behavior: spotdl I just tried to install it, doing it from or gives the same result. Let me know if I can provide more useful information.


nix fails to build libjack2 and libpulseaudio on darwin too (probably another two issues should be filed?). mpd build log is the third one. After disabling libjack2: After disabling libpulseaudio: I'm no expert in c++ but quick googling shows that exceptions are disabled by default when building with xcode toolchain. On a side note, which way is proper to manage ? I'm editing expression in but not sure if that is the right way. I'm using OS X 10.10.4, nix-env 1.9, nixpkgs from master HEAD.
Compilation fails on throw from boost library and mpd sources are compiling with , so I've to mpd expression but still no luck here.
Seems like this didn't get resolved and it's been a while... I have mpd failing to build on Darwin also, but with a different error, CoreAudio related. I'm using a local nixpkgs checked out at , OS X 10.11.3. Here's the failure:


, CVSSv3=7.5 (nixos-20.03) Scanned versions: nixos-20.03: . Cc Cc
Fixed by


Package name: vorta Latest released version: 0.9.1 <!-- Search your package here: --- Current version on the unstable channel: 0.8.12 Current version on the stable/release channel: 0.8.12 <!-- 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]:


Describe the bug flatpak-builder for some reasons can't use rofiles-fuse To Reproduce Steps to reproduce the behavior: build any app using flatpak-builder Expected behavior flatpak-builder should use rofiles-fuse. Screenshots Additional context Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(piotrek): nixpkgs: Maintainer information:
installing solve this problem so maybe should be ?
We patch the paths to the executables to be hardcoded, so the program doesn't have to rely on something like ostree being installed. I believe one path isn't hardcoded with the current patch That looks it up in PATH, probably why it was working once you installed it.
cc
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 . 3. Ask on the on .
should fix that issue.


cudaPackages.cudagdb is broken for aarch64. Steps to reproduce the behavior: latest nix on system (e.g. Linux docker container on Apple Silicon Mac, Graviton instance on AWS, Nvidia Jetson device, Raspberry Pi) use , i.e. run command fails with Derivation success without an error. I also made an investigation and corresponding fix. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


In current master branch pythonPackages.mysqlclient fails to build. Checkout nixpkgs on revision and run: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Most likely caused by . Unfortunately, the config-tools are not very configuration friendly. Until is resolved, I would add to the package.
Unfortunately this does not change anything, still failing with the same error message..
Hmm, apparently just hardcodes the path without the ability to override it from the attrset passed to : Is that intentional, Until this is resolved, you can use :


Steps to reproduce the behavior: Confirmed locally against recent master () system: host os: multi-user?: sandbox: version: nixpkgs:
There's already a PR fixing this build failure:
looks like this is being addressed in
Can confirm, fixes build-issues on unstable :)
Fix has been merged. Feel free to reopen if the issue persists after the next channel bump


When setting a registerPassword for the public server list, it doesn't actually write it to the file, forcing me to hardcode it with extraConfig. Steps to reproduce the behavior: the registerPassword option; the system; the contents of . The registerPassword option should be written to It may be a problem with at line 36 where it has a double equals instead of a exclamation mark equals like the other parameters in that code block, although I'm not really sure. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Oof that's exactly right. It seems to have been by by


Steps to reproduce the behavior: distutils module was removed in python 3.12 <!-- 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]:


Can't run insomnia in the latest . It works <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- I use flakes, but From
Having the same error
I'm facing the same issue (gonna submit a PR to fix this), do you know when did this issue get introduced?
Not at all, first time insomnia user, I had a bad timing


The application fails to start with the following error: Steps to reproduce the behavior: to run the application The application should start and work properly.
Same issue with  (
I was looking at fractal-next as well, and found possibly related - [HELP] "Failed to retrieve template child" for Rust 1.67.0-nightly - Dec 4, 2022 - closed with Fixed in 0.5.3 a day later.
Ah, I see. There is a related PR for Amberol:
What commit did you build from? I’d like to bisect
My first try of fractal-next was about a week ago and it was failing already. I've tried HEAD and branch () although I'm not entlrely sure is the correct way to refer to that branch.
if you’re updating the version to point to an unreleased version the should
Indeed, thanks. What I meant was that I'm not entirely sure that setting in to (via ) does indeed let me build from a branch. I could not find a definitive reference for that, but it seems to work. I've the rust backtrace to - Draft: general: Use AdwDualPaneView and AdwAdaptiveState_
Hi there :) This is an unfortunate gtk-rs bug, and there's nothing to do on the app side for this. In addition, draft MRs are not expected to be packaged. That MR in particular depends on unstable libadwaita features and unstable bindings.
Is the gtk-rs package version something I can control? I was under the impression that this is managed in . I understand the branches/merge-requests I tried are not to be packaged. I'm merely trying to get fractal-next to run at all, as element is unusable on my phone.
In it is the minimum version we want to use. The pinned version (the one that is compiled) is in , and it is currently  on . This issue should have been fixed in . I don't know much about packaging for Nix but looking at the diff you posted , have you tried with the whole commit hash? Also don't you need to update the sha256 hash?
We’re not building from , we’re building from . I’m gonna check if we can just bump the version in to and leave it at that.
(how naive of me.


maybe just building from is better)
Opened a PR that should solve this, assuming it's accepted. In the meantime you can use it in an overlay if you want a fix now.
You were right - thanks for the hint! - I was indeed still building fractal-next from before the fix :disappointed:


Describe the bug Seems like some updates to pango broke a few packages Among the broken ones: ettercap (see ) pangox-compat (which anydesk needs) probably a few more To Reproduce Steps to reproduce the behavior: to build ettercap or anydesk from master will fail to build with some pango-related errors Expected behavior It should work Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata system: host os: multi-user?: sandbox: version: channels(maciej): nixpkgs: Maintainer information:
Also remmina is broken But doesn't seem to depend on pango directly, so unsure which dependency actually is broken
Here's an issue for pangox-compat
Lutris is broken too - not an urgent requirement but just making you fine folks aware!
Not sure why Lutris is broken, but Lutris-unwrap is fine.
It's a failure in the dependency chain, in this case .
no longer depends on on its master branch: We should probably switch to that. should not be needed in according to the README in , I suspect it was only there because we did not propagate it until ebassi also suggests switching to HEAD and says we need not worry about ABI changes:
Not having pangox_compat fixed is definitively still an issue. Can this be re-opened?
After , the only program depending on this is anydesk and openmodelica which is broken.
So it breaks anydesk thus either we mark anydesk as broken or we fix that?
Anydesk shouldn't use this deprecated library. Yes, we can mark it as broken.


<!-- 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 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: miller <!-- The current version can be found easily with the same process as 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: 5.10.3 desired version: 6.1.0 miller is now written in Go; there's still a configure script and a makefile, but I don't know if it's now more complicated to package because of fetching dependencies in a reproducible way or whatever. <!-- 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 see Metadata homepage URL: source URL: license: unfree platforms: darwin, linux
I was just checking myself and it's been there since November apparently
Ah, don't mind me, not checking the platforms...


When I try to open a file dialog in Bitwig Studio 4.1.0 I am getting that error: I can manually start from command line and I'm seeing the file dialog and it returns the selected file. Unsure if this is of any use but is the decompiled class that calls . Steps to reproduce the behavior: bitwig (or open any other file dialog in bitwig) GTK file dialog opens Maintainer information: EDIT: more information
I am not a maintainer of bitwig sudio. Just because I changed some lines does not make me knowledgeable about this issue.
Sorry for that. I just did what the bug report template told me:
I played a little bit around with that problem. It seems to be connected to a change of to . further references: As a quick workaround you can launch the application with: is using an embedded version of java 16.
/cc
The cause may be here: We must not wrap :
Two ways to fix: Fix the embedded JDK. Replace the embedded JDK with package.
Thanks for having a look into this. I guess we should fix the embedded JDK as it's the way how it is shipped and it should be a compatible version. I tried to add to which does not improve the situation.
I tried to do the same thing and I noticed that the exact error message changed to: but I can still run . Not sure what that means. EDIT: I've found in another package that they do run patchelf on jspawnhelper. I've also this to the postFixup: and that made it work. Not sure if this is the most elegant way to do it but I can open a PR and we can discuss that there. Thanks :)


introduced systemd syscall filtering which seems overly restrictive for common use cases. We use for coverage reports of our Rust projects which makes use of the ptrace(2) system call (denied by ). Android projects commonly rely on which uses chown(2) (denied by ). In my opinion, those use cases are too common and should work out of the box. Also, workflow failures are difficult to debug if syscall filtering (or any hardening) steps in. I'd suggest to revise the syscall filtering: Also, it might help with debugging or employing a custom hardening configuration if we add a module option which defaults to . Please run and paste the result.
I agree that if the hardening make github-runner not to work as expected or as "standard" installation, we should remove them or make them optional with new option Do you want it to default to ? Maybe better with so it work as expected out of box?
also noted problems with makefile workflows in that I have been able to reproduce. I am sorry I did not catch this when making the changes originally. My usecase was running binaries on uncommon targets (e.g. ) connected over USB; and I only had light testing for other usecases. I have since a makefile test to the runner I use for testing package/module updates and will add a coverage workflow now too. I am ok with removing the harderning entirely, or making it more permissive. I only this because at the time I thought it would be a sane default for majority of applications. I would prefer we keep some hardening. Most people probably do not want a CI process to change the clock, hostname, or reboot the system entirely. I have been working on this in the background since reported issues; this is what I have come up with so far, I have not tested it with yet (will do that later this weekend); but it does allow and debug related tools such as to function. In addition to changes should also be changed to so that nix does not emit warnings when running.
:+1: :+1: Yes, all this hardening is already available and entirely optional! Every user is free to add anything to that they want.


I understand that NixOS developers are super keen on hardening, which is generally good, but for certain applications I just don't think it makes sense to go over the top... or even provide "curated" selections behind 'enableHardening' type flags. CI software is so broad I think we're providing more trouble and confusion than value here. My personal recommendation for this specific module is to follow what suggested as a reasonable default and let users decide any hardening they want for themselves. But I'm not the maintainer of this module in NixOS, just a user, so I defer to those who are volunteering their time to maintain this module :bowing_man:
PR to fix is here: Mentions do not generate notifications, just making a comment so that anyone subscribed to this issue gets a notification.


low priority qt6.qtdeclarative is a large package, so it should be excluded for non-GUI qt apps () currently, when i build a package with and empty buildInputs, it pulls qt6.qtwayland qt6.qtdeclarative qt6.qtshadertools the problem is wrapQtAppsHook and its deps and qtwayland pulls qtdeclarative the problem is fixed by removing from deps wrapQtAppsHook should use only the declared buildInputs disabling wrapQtAppsHook (dontWrapQtApps = true) is no option, as also CLI qt apps need the qt wrapper qtwayland is there, so that users dont need to add it to buildInputs assuming that all qt apps are GUI apps im in favor of making this consistent with cmake so that all GUI apps must add qtwayland to buildInputs CLI qt app: GUI qt app: since cc
I'm in favour of this change, but the proportion of qt cli app night be relatively small, and it's not immediately clear that qtwayland should be if the build log yields Qt6::Widgets is missing.
Actually we are abusing qtwayland as a shortcut to bringing in qtdeclarative, this should be fixed too.
we could patch the cmake message to "please add qtdeclarative to your propagatedBuildInputs" the alternative would be to add a flag, but thats more obscure than buildInputs
Adding the lines to nixpkgs manual is sufficient.
By the way, is not only needed to pull in , but it's required for all GUI apps so that they work seamlessly on X11 or Wayland.


Hi, I'm a Keybase developer and some of our users reported that the Nix packages were out of date. Keybase 4.1.0 was released a while ago, so I believe these need to be updated: Additionally, the KBFS nix should point to the new remote, with , and be on the same version as the other packages (4.1.0). Please let me know if you have any questions, happy to answer! Thanks. N/A N/A
if the users are using the stable branch, then the update will need to be backported. Otherwise if they are unstable then it should be just a few short moments ;)
KBFS has not been updated as directed here.


Project description <!-- Describe the project a little: --An implementation of the Language Server Protocol for . Metadata homepage URL: source URL: license: mit platforms: unix Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: It has a pnpm lockfile for which we for yet, this package request should wait.


Build on () and when running I find the following in the runtime closure: pytest shouldn't be a runtime dependency Seems to be a regression, did not have this issue Might be able to bisect this one, but it'll take a while <!-- 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]:
After bisecting, first bad commit is (


System hangs during boot when the timer configured via fires during the boot sequence. option. option such that the timer will be due to run immediately upon the next reboot of the system. ; allow sufficient amount of time to pass. Boot the system, observe the system to hang during the boot sequence. system: host os: multi-user?: sandbox: version: channels(pbogdan): nixpkgs:
Does setting help?
but otherwise yes, it does help, thank you.
Hi, I reproduced this on 19.03 yesterday. The unit already contained , so it seems it is not sufficient to fix this. Some data about my system:


Package name: rnnoise Latest released version: 0.2 <!-- Search your package here: --- Current version on the unstable channel: 2021-01-22 Current version on the stable/release channel: 2021-01-22 <!-- 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. Tried building with but it got a missing file. There’s also warning about not using SSE3/AVX/AVX2, but Nix only supports the bottom of the barrel, common x86 instructions, but I usually compile this one out with some flags. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: [^1] or offering a non-proprietary, non-US-corporate-controlled mirror for this free software project. I wish to delete this Microsoft account in the future, but I need more projects like this to support alternative methods to send patches & contribute.
The missing file is downloaded as part of the '' It looks like they a step to the build process.
Perhaps it can be fetched using fetchurl/fetchpatch?
You're correct. The relevant file is retrieved in the script . It fetches a single file from the URL , where the version is extracted from the file , currently set to . Hence, we can emulate the download script and execute something similar to:
Alternatively you could use instead of a separate model + . While we are at it, we should be using the main repository instead just Microsoft GitHub which is explicitly listed as a mirror, not the primary code forge. Something like Referencing both mirrors would be more resilient for when one of these platforms goes down.
Made a PR , but still having trouble designing a .


only returns the hostname, even when both and are set. Steps to reproduce the behavior: and . . should return the FQDN defined by and . The breakage happens when is used, which is now the default in NixOS after Stopping causes to return the correct value. reproduces the issue. It broke at , which is when became enabled by default. It's still broken on which is at time of writing. Possibly related issues:
This seems to happen because the resolution flow (when nscd is running) looks like: calls , which uses the nodename (), which is the short hostname then calls , which invokes the nss machinery gets the request and processes the request according to the NSS rules; on my NixOS system this is (from systemd) doesn't match (from systemd) does match, and returns a synthesized record; systemd internally determines the hostname for this using only the nodename, so unless the nodename is already the FQDN then we fail here, and it does this before checking /etc/hosts. I wonder if we can fix this by patching out the support in systemd-resolved for looking up the nodename, which will make it fall back to the result from /etc/hosts instead; on NixOS we can (probably) always assume that /etc/hosts will actually have the correct system hostname in it.
No, this is most likely We wanted to polish that PR in the next days, and once merged, bump our nixpkgs pin (and resurrect the upstreaming attempts). If you want, can you check if using nsncd from this PR fixes the problem for you?
Ah, actually, I think I'm just talking out of my ass. systemd-resolved seems to be able to cope with this properly when I query it over DNS, so it probably isn't to blame.
tests fail at that PR. Setting gets a successful build, which then passes the test in , but it fails on the test.
This is a pretty weird behavior. What's (likely) failing here is the IPv6 resolution of . The test does pass on some NixOS setup, like my desktop (and the Ubuntu CI) but does fail on my laptop. I'm still not sure what's happening, is present in .


There's something wrong with some NixOS setup, it'd be nice to fix that as well. By any chance, did you disable systemd-resolved? Thanks for the heads up wrt. . I'll have a look today.
The behavior I described is from the Nix build environment. I used the nixpkgs derivation for nsncd and updated the source to the PR.


In NixOS 22.05, the domain name is not set correctly when is set to . 1) It's working with IPv6: 2) .. but broken without: Obviously, it should work in both cases. The issue seems to be related to : also fixes the problem. Similar issues seem to have been discussed in , and , but it's still broken. Please run and paste the result.
I also seem to have hit this, but do not run , but a customized . I have however not tested removing , as my servers rely on the configuration section to run. Have a feeling it may be a fragile section when changes in happens. Also stopping solves it as well. Running nixos unstable.
I can reproduce this on nixos-unstable (without disabling IPv6), but also managed to get it working when stopping nscd. I found while googling around. And while points out a possible solution[^1], I did not find this to be working for me. [^1]: Effectively translating to
I've also encountered this issue, with the same reproduction and issues as Any idea how to resolve this? I particularly need to be able to set for containers using ...
FWIW, setting to seems to resolve this issue. cc
Hmm, this doesn't make too much sense - I'd assume and should behave the same when it comes to that. They're simply calling out to the same NSS modules to do the work. We do have which tests that works. It currently seems to be failing in the testcase, when run with nsncd, and succeeds when setting to . - cc Let's figure out this regression first, and not draw too early conclusions about this being a "IPv6 is disabled issue".
So, there's definitely something wrong with the current nsncd implementation. Dumping the Nscd socket, we can see that nsncd is lacking some getai entries. Entries that are probably used by hostname to get the FQDN: Let's track and fix this issue on the Nsncd repo.


Project description EveBox is a Suricata alert and event management tool for the Suricata IDS/NSM Engine. 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]:


Project description A terminal based slideshow tool. Metadata homepage URL: source URL: license: bsd 2 clause platforms: unix, linux CC:
- You can follow the status of the pr/package .
Please include presenterm-export as well, or a new presenterm-export package


Steps to reproduce the behavior: build .#fdroidserver Git bisect predictably found the culprit as , so it is related to the Python 3.12 upgrade. I suspect that all setuptools-based modules are broken; e.g. also stops building. Interestingly, built before, but not after. Not sure what that implies. (Originally I had notified the Python team, but I removed them from this list because I am suspecting this regression may not be the result of any problem with the version flip itself, but the broken packages instead. Sorry.) Notifying from fdroidserver maintainers. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Version 1.8.0 is available and . It looks like this should be a trivial bump in the luarocks csv. <!-- 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 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: <!-- The current version can be found easily with the same process as 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.7.0-2 desired version: 1.8.0-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.
Wanna take a stab at it then ? we can help you through the process


When defining the desktop shortcut that gets installed globally doesn't point to the correct executable. The executable that it points to is the one of the non-wrapped package, causing any plugins that are installed to fail to load. Steps to reproduce the behavior: the following in a launching the application from your desktop menu/launcher the command pallete inside of the program in - THIS fails HOWEVER, if we launch octave from the commandline instead by issuing the command, everything works as it should. When you launch octaveFull from the desktop menu it should behave the same as if it was launched from the commandline. When launched from the OS desktop menu. ! When launched from the command-line ! Inside of your octave-env derivation that's generated when you do a system rebuild, theres a file located, there you'd be able to see that the wrong executable path is used for it. Please fix this. <!-- 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]:
Thanks for the report! Indeed we never thought about this detail. I pushed a fix in . Here's how I tested it: And note how the paths in the line above is the same as the path to the wrapping derivation (from ). I also checked with that I can in the GUI. Your approval on will be welcomed.
Will take a while to build as I don't use unstable, there's a ton of dependencies


Describe the bug I have configured the new ACME module (from 20.03) and after a rebuild nothing happened. I expected to have a certificate or a (failed) certificate request, but neither of these happened. Apparently I have to wait four days until my certificates would automatically appear, that is a bit long. To Reproduce Steps to reproduce the behavior: a certificate through certificate request doesn't happen before the systemd-timer is due Expected behavior I should have a certificate as soon as possible. Metadata Maintainer information:
presumably you have a service which requires this certificate. You should make that service require your certificate service. Both and services do this with their options and could demonstrate for you how to do this. If any part of what I said isn't clear, or any part of the code please do not hesitate to ask for details.
Got it, I can make that work. But is that really the intended behaviour?
Would you want each certificate to renew each and every time you rebuilt your system? That sounds like much more of a problem. You could always manually execute the certificate service any time you want, but the intention is that you utilize systemd and make services depend on other services. Why provision a certificate unless you need it. If you need it, declare it so and it will be provisioned.
It wouldn't renew on every rebuild: Starting the renew service doesn't do anything if no renew is needed. I think having the certificate be created when a rebuild is done sounds reasonable. I think it might simply be a matter of adding to the acme services.
That and also making sure on boot that the certificate is in order is also a good practice.
thanks for clarifying that. I think I was mistaking the implementation which did attempt to renew every time it was called, if I recall correctly :thinking:


remarkable-mouse doesn't work for me, exiting with the following traceback: Digging through github issues led me to , and the following traceback: I guess this is a problem with screeninfo's packaging, but I'm unsure what exactly the issue is, or how to fix it; maybe related to ? screeninfo (and, by extension, remarkable-mouse) should work. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
As far as I know there is no infrastructure in place that lets (in ) work correctly, since it has no knowledge about the Nix store or the buildInputs of screeninfo. There used to be a call which replaced all findlibrary calls with store paths, but it was removed in I think the two load_library related substitutions need to be back in (compare with , which contains comparable code).
Replacing calls seems sensible, I will try to make a PR. A workaround for now (e.g. for remarkable-mouse users) is to set $LDLIBRARY_PATH to , but that probably isn't usable within the library itself.


waveterm Modern open-source terminal emulator supporting inline rendering. homepage URL: source URL: license: Apache-2.0 platforms: linux, darwin
I've tried, got stuck at packaging waveterm with scripthaus. However i have packaged scripthaus which is required here. Maybe someone with better understanding of nodejs will make it.
Here's my attempt at cobbling something together for linux, which seems to be working locally for me (well, it's "working" in the sense that it builds, the GUI shows up and the basic shell features seem to be working): I wasn't able to get it building using the provided scripthaus scripts yet, but I'm also quite inexperienced in this area so that could be why. I'm currently using and instead, basing it off from a bunch of other electron and go packages on nixpkgs. I haven't carried across all the build flags from waveterm's provided scripthaus scripts though, and you might also see some vestigial code that I copied from other packages that don't apply for waveterm which I haven't cleaned up yet. If I have time I might give the scripthaus scripts another try. Some other remaining todos that I'm aware of include the desktop icon, getting it working on darwin, checking the AI features, checking that the package includes all the dependencies it needs at runtime, and fixing a failing test regarding command completions. Please feel free to continue working off from what I have if it helps, especially if I don't get back to this soon.
Waveterm offers a packages. I was installing and noticed that it fetched a package and installed it. Is it not possible to do the same? I also saw in this that packages are pulled for Opera and Skype as well. So, is it possible to do the same for Waveterm as well?
Forced M1 user here, tried packaging wave but didn't manage to make the scripthaus scripts run without fails, mainly because both go and scripthaus try to create cache directories and I didn't manage to disable this behaviour.


I also tried to use package but due to it requiring electron and it not being available for the M1 architecture I couldn't compile the application from source, so I think packaging for the M1 will have to be done through the .dmg that they have on the realeases page. I'll try packaging the application when I have time this weekend.
In the end I couldn't resist and worked something out for M1 in my free time, this works and creates a ./result directory with an application I can open, so I think it's pretty much done. The only thing missing is integrating with solution... I'll try doing it this weekend.
where did you get that info from?
When I searched for electron on Nix packages it never appeared a platform for darwin... I know it should be possible to have electron in M1 but at least on Nix it isn't packaged for it already. <img width="313" alt="image" src=""
Oh, nice! I thought the panel with platforms displayed all of them, clearly it doesn't. I'll first merge the linux build mentioned previously and then I'll try using that electron to build the app from scratch. Thank you!


I enabled the following chromium enterprise policy: This created a .desktop file in But the command crashes, because it tries to start the unwrapped binary directly from the nix store. We should try to point Exec at just so the wrapper from PATH is used.
CC
Not sure what's happening here. On my system it seems to be fine:
Please read the description again, specifically I am talking about the .desktop files created by chromium, at runtime.
Ok, I was assuming NixOS put it there. Chromium creating files at runtime sucks... (unfortunately it's not even surprising :o)
setting the env var in the wrapper script may help ;drc=;l=405
I marked this as stale due to inactivity. →
(as already mentioned) would probably work for Chromium too. Just in case someone's still interested and has time and motivation to test it and submit a PR ;)
This is not exactly a NixOS caused issue. As chrome creates the shortcut wherever the binary is currently installed, and there is no nice way (other than patching chrome) to solve this. While discussion of patching chromium to always point to relative chrome i cant say much about. To get this working today, you need to edit each desktop file manually from to its relative name . and use at the top of the file. While this adds a minor security issue due to executable being relative and not absolute, it seems like the simplest solution for now. There is also this flake that will run a service in the background to do this editing automatically for you: Hope this helps! :D