Additional packages which have a vendored libwebp that I found on my system via the that posted in Matrix: slack obs-studio (via ) openutau (via embedded , also oops this package is mine )
Same method as mentioned by Lily, found: android-studio discord idea-community vial (via ) joplin jetbrains-jdk-jcef (via ) qtimageformats (via )
I looked more into .NET apps that depend on Avalonia and I've also confirmed these vendor libwebp (all via ). I've not confirmed that any of them use the vulnerable version directly, but it seems highly likely they do given a new SkiaSharp release has still not been made since the release of the CVE fix: BeatSaberModManager alttpr-opentracker avalonia-ilspy denaro galaxy-buds-client git-credential-manager jellyfin mission-planner mqttmultimeter ryujinx scarab space-station-14-launcher wasabiwallet
same method as hexa and liliy
currently working on a betterbird update. Not sure about thunderbird and I don't really have the time to check it right now. edit
Also going to add onlyoffice-bin, libsForQt5.qt5.qtimageformats, libsForQt6.qt6.qtimageformats and remarkable{,2}-toolchain to the naughty vendoring list.
If it uses buildMozillaMach it uses our system package.
Got a match for "no memory during frame initialization." in : /nix/store/z613gjk28c3q0ypjsdch9vshdlydc9fm-vscodium-1.82.0./lib/vscode/codium
I've ran a grep on ~200K Nix store paths from a full Hydra evaluation - here are the results: Let's start categorizing that a bit and translating it into trackable tasks :) I've already listed all the SkiaSharp dependents. A few other categories I see: CEF users Vendored Electron users Qt libs Flutter Go binaries (e.g. mautrix-whatsapp, but not sure what package the dep is coming from)
For reference, I believe that all supported channels (6) have updated past the patching (the non-vendored one). This weekend turned out to be a pessimistic estimate.


golden-cheetah-bin: PR to mark insecure: Also reported upstream:
opencv seems like a relatively common package (with multiple versions). Maybe the maintainer could have a look?
High priority things that I think are still to be updated: Chat apps / browsers / mail clients: fluffychat (uses vendored flutter < v3.13.4, cc upstream has a commit in master which updates flutter to 3.13.4, but I don't think that's released yet. gitter (cc upstream seems unmaintained anyway, should be removed?) mautrix-whatsapp (vendored via some Go dep, cc signal-desktop-beta (cc who took care of Signal, can you maybe have a look?) threema-desktop (lib/threema/threema-web - is this even used? since we use nixpkgs electron, cc tutanota-desktop (opt/tutanota-desktop/tutanota-desktop - similar to threema-desktop, also cc
mattermost-desktop (share/mattermost-desktop/mattermost-desktop, cc
rocketchat-desktop (cc I think just needs a bump to 3.9.7 for
Yeah removing gutter seems fine
do you recommend moving FluffyChat from stable -a git commit temporarily? By the way, flutter itself seems to have a bad vendored version. Need to push out 3.13.4.
There's a mautrix-whatsapp bump here: , not sure how I can check whether this is fixed by that PR? Edit: looked into the upstream source, definitely not fixed by that PR. From what I can see mautrix-whatsapp uses libwebp in a vulnerable way. I'll try to work with upstream to get this resolved.
If cherry-picking the patch is an option it's probably less invasive, if upstream is planning a release in the next 2-3 days I think I wouldn't mind waiting too. If neither of these options apply (or if you don't mind bumping twice in rapid succession if upstream pushes a new release) going to an unstable version SGTM.
was updated and merged recently (). Would that count?
Looks like that new version contains which is a proper fix. Thanks for the pointer! Just needs backport to 23.05 now.
It was mentioned in the changelog, please read them when updating a package.


It will count once the backport to release-23.05 has happened.
I had already reported the issue to mautrix-whatsapp in private to lessen the chance of exploitation (they use the webp dependency to decode webp images and are thus vulnerable). I've had no response yet though.
Heh, I don't think there's much value in reporting this in private (and making coordination/tracking harder) given that it's a publicly disclosed vulnerability already. I noticed you said you'd talk to upstream but couldn't find any trace of that, so I went ahead and filed that bug... Sorry for stepping on your toes - it's hard for me to know exactly how actively maintainers are going to handle the remediation by themselves, so I've been proactive in making sure upstream issues are filed when I don't see one
Godot (godot3, godot_4, godot3-headless, godot3-server, godot3-export-templates): upstream has merged which I think is getting backported to the 3.x branch. But it also appears that, at least for 4.x, libwebp can be unvendored: I think that's what we should be doing while waiting for new releases, and this is likely true of many other dependencies that can be unvendored via the same mechanism. cc maintainers: (please cc me on any fix PR and make sure to backport to 23.05).
Fix for mautrix-whatsapp here: (backport here: )
Worth noting is vulnerable, upstream fix was in PR Kong/insomnia, though it hasn't gotten a release yet.
is a fix for signal-desktop-beta, thanks
:heart: to all who have contributed to this.
Explicitly pinging the maintainers for the remaining high-risk use cases: armcord still uses vulnerable Electron 26.1.0. Please get upstream to fix their security vulnerabilities. caprine-bin is presumably built by upstream from Electron 24.1.3 from 151 days ago. Please get upstream to fix their security vulnerabilities. (Additionnally, why is this a binary build instead of something we build from source?) - mailspring uses Electron 17, which is hopelessly out of date, EOL, and insecure. Please get upstream to fix their security vulnerabilities.


mattermost-desktop is out of date in nixpkgs. Their latest release is based on Electron 26.1.0, which is also insecure. Please get upstream to fix their security vulnerabilities. rocketchat-desktop also needs a bump in release-23.05. I've started the backport process via the master PR, please test it and let me know when it's ready to be merged. - Everything in this list that hasn't been updated by Friday 2023-09-29 00:00 UTC will be marked as insecure next weekend.
Also mentioned this on Matrix, but for posterity: SideQuest is also affected (and frequently loads untrusted content). It appears to use a bundled Electron 13, which has not received and will not receive a patch. I've e-mailed the upstream in the hopes that they can update to a newer Electron ASAP.
Using and then checking the output of by opening DevTools (Ctrl+Shift+I) : <- patched according to GH security advisory : <- patched according to GH security advisory : <- vulnerable? Tested on
Great, thanks for looking into it! Hopefully they'll roll out that update to the stable branch soon... I guess it's difficult for a small indie developer like them, it's only been 2 weeks since the fix was made available! :-)
just got updated in master so it's not in nixos-unstable yet. thanks for checking it out, I couldn't figure out a way to check the electron ver.
Thanks! I checked 0.0.30 (which is on master and 23.05 as of yesterday) and it seems to be on Electron 22.3.24. Marking as fixed
Thanks for pinning me. Just created an issue there: Because the source build failed the time I tried to package Caprine (some years ago). It's a pain to an build Electron app from source in Nixpkgs.
Regarding Mailspring there is , I will ask about their plans to move forwards
There should be a pre-release with electron 27 for armcord, will dig in tomorrow.
Currently we are not building koreader from source (see for some efforts).


Since the released upstream deb package has not fixed CVE-2023-4863 ( fixed it, but it is not released yet), we have to wait a while for a new koreader release.
To make it better, I reported them this like 2 weeks ago! They're still working on running the npm command on the stable branch, give them some time!
fluffychat and flutter updates have been backported now:
I made a draft PR that contains the caprine-bin update (), but the updated app turns out to be unusable (sindresorhus/caprine).
The above issue is resolved in Caprine 2.58.3. Please take a look at .
it was brought to my attention that the Darwin version for Discord was not bumped in 6 months, and is thus still vulnerable to this libwebp vuln. If nobody maintains this software can it be removed and/or marked as knownVulnerable? Thanks!
I'd say that after a bit of wait you mark packages as vulnerable and that is the main way of finding out whether someone is really willing to keep it alive.
I have bumped them in . The main issue is that r-ryantm isn't helping us out here, as there is no for the darwin packaging. Not sure if any of the other Discord maintainers are using Darwin, but I certainly don't and would need some assistance testing these.
is affected. I created mifi/lossless-cut to remind the LosslessCut upstream to make a new patch release, so that me can update .
is affected, fix:
All the packages I evaluated as being high-risk have now been taken care of (and most of them did actually get updates, woo! only marked 2 or 3 as insecure). Right now I don't think anyone has the bandwidth to try and track the rest. I'm going to close this bug - if someone does want to take over the remediation for the rest of the impacted packages, feel free to reopen and assign yourself. (Note however that there is a large overlap between vulnerable to this libwebp vuln and vulnerable to the recent libvpx vuln... so maybe just go help over there instead of reusing this bug.)
Unpinning due to closing
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Package name: kitty Latest released version: 0.34.1 <!-- Search your package here: --- Current version on the unstable channel: 0.34.0 Current version on the stable/release channel: 0.31.0 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- 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 Virter is a command line tool for simple creation and cloning of virtual machines based on libvirt Metadata homepage URL: source URL: Blogs: , license: Apache v2 platforms: Linux only written in: go Thanks a ton!


prints The message seems misleading as everything works as expected, even as a regular user. = { enable = true; locate = pkgs.mlocate; }; System: (NixOS: ) Nix version: () Nixpkgs version: ()
This still happens, although its a correct warning
That's surprising since it works for me without root. I only experienced issues when the wrong binary is used. If I recall correctly has higher priority and causes this. Can you check the output of or paste whatever error you get?
Sorry hit the wrong button by accident.
The warning is correct, but the wording is misleading. What it’s trying to warn you is not that will only run as , but rather that will run as . You can prevent the warning from being shown (with no other effect) by explicitly requesting that run as with .
This is warning is still confusing to me. If I'm building an index of files, I'd expect that if I run it as a non privileged user many files will not be reachable and therefore these won't end up in the locate database/index. Given the way works, I'd also expect to have one database per system, not one per user. So from this my expectation is that can only successfully index everything if run as . In other words, I'm still not sure what is the purpose or goal of the message. Is it just that the command needs to run as ? is this bad in any way? why is this special given the purpose of the tool? Is it that the fact that it runs as is in some way a security concern? Is this to clarify that despite the existence of an group (and user?) these are not actually used for indexing, or is the point something else entirely. Do other tools work in such a different way that justifies the existence of this warning for ?
mlocate’s doesn’t have a option like findutils’ does. Therefore, the NixOS module ignores when using mlocate (). It prints a warning to indicate that your expectation has been violated. The group is there so that the mlocate binary can be setgid rather than setuid . Given that mlocate is designed with an that indexes everything and a that only shows you your own files, there doesn’t seem to be much point in running mlocate’s as another user.


If you want that, why not switch back to findutils?
I see, in this context, the above makes sense. I actually want the full system indexing. To me has always been a synonym of , except several times faster. Thanks for the clarification!
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 .
Could you include your commit in a pull request? I think that's a good solution and we can close this issue.
It’s been in this whole time.
My bad, I read only the latest updates and the pull request was higher up. Did a bit of noise on the pull request. It's a harmless change so I was surprised to see it sitting there for this long.
To avoid , this is needed: it's needed because it creates the group. That error happens when using: with or without: and then doing something like . But if not using the (so only using the alone) then there's no error, because the service itself uses a different package's by default, it's from package. The source: EDIT: I made some mistakes initially, you can see post history for that.


The pijul fetcher throws a certificate error when used, for example with the following command: Related: Steps to reproduce the behavior: fetchpijul (for example like in the command above) fails with above error Repository gets fetched successfully Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Oh my, thanks for notifying, I'll make a PR to fix that ASAP!


Project description Railway lets you look up travel information for many different railways, all without needing to navigate through different websites. Metadata homepage URL: source URL: license: gpl3 platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Describe the bug xscreensaver-demo is both a way to preview individual screensavers and the frontend for configuring xscreensaver. It should be installed alongside all the other xscreensaver binaries; however, it isn't, although its man page is. To Reproduce Steps to reproduce the behavior: Expected behavior is available in . Notify maintainers (raskin) Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:


firejail bash . Error: cannot establish communication with the parent, exiting. . [milan ~]$ firejail --debug bash ~ Autoselecting /nix/store/fibk8jc2iwswn1q1d7aw98pcw2l3lzjf-bash-4.4-p12/bin/bash as shell Command name #bash# Attempting to find default.profile. Found default profile in /nix/store/y4ai4pgjizcanjahcfcd785i7n0h6r4q-firejail-0.9.44.8/etc/firejail directory Reading profile /nix/store/y4ai4pgjizcanjahcfcd785i7n0h6r4q-firejail-0.9.44.8/etc/firejail/default.profile Reading profile /nix/store/y4ai4pgjizcanjahcfcd785i7n0h6r4q-firejail-0.9.44.8/etc/firejail/disable- Reading profile /nix/store/y4ai4pgjizcanjahcfcd785i7n0h6r4q-firejail-0.9.44.8/etc/firejail/disable- Reading profile /nix/store/y4ai4pgjizcanjahcfcd785i7n0h6r4q-firejail-0.9.44.8/etc/firejail/disable- Note: you can use --noprofile to disable default.profile DISPLAY :0, 0 Using the local network stack Parent pid , child pid Initializing child process Host network configured PID namespace installed Mounting tmpfs on /run/firejail/mnt directory Mounting read-only /bin, /sbin, /lib, /lib32, /lib64, /usr, /etc, /var Mounting tmpfs on /var/lock Mounting tmpfs on /var/tmp Mounting tmpfs on /var/log Create the new utmp file Mount the new utmp file Cleaning /home directory Sanitizing /etc/passwd, UIDMIN 1000 Sanitizing /etc/group,


GIDMIN 1000 Disable /run/firejail/network Disable /run/firejail/bandwidth Disable /run/firejail/name Disable /run/firejail/x11 Remounting /proc and /proc/sys filesystems Remounting /sys directory Disable /sys/firmware Disable /sys/hypervisor Disable /sys/module Disable /sys/power Disable /sys/kernel/debug Disable /sys/kernel/vmcoreinfo Disable /proc/sys/fs/binfmtmisc Disable /proc/sys/kernel/corepattern Disable /proc/sys/kernel/modprobe Disable /proc/sysrq-trigger Disable /proc/sys/vm/paniconoom Disable /proc/irq Disable /proc/bus Disable Disable /proc/timerlist Disable /proc/timerstats Disable /proc/kcore Disable /proc/kallsyms Disable /boot Disable /dev/port Disable /dev/kmsg Disable /proc/kmsg Disable /home/milan/.gnuplothistory Disable /home/milan/.zshhistory Disable /home/milan/.bashhistory Mounting read-only Disable Error: cannot establish communication with the parent, exiting. [milan ~]$ System: (NixOS: , Ubuntu/Fedora: , .) (Hummingbird) Nix version: (run ) nix-env (Nix) 1.11.8 Nixpkgs version: (run ) ""
May be caused by . Does the same occur with , and not with ?
I'm having the same issue on Nixos 17.03. There at least it is exactly as you have described it, hence almost certainly the referenced issue.
Failure: [milan nixpkgs]$ firejail --noprofile -- firefox /etc/nixos/nixpkgs Parent pid , child pid Error: invalid whitelist path Error: cannot establish communication with the parent, exiting... Success: [milan nixpkgs]$ firejail --noprofile firefox /etc/nixos/nixpkgs Parent pid , child pid Child process initialized
Yep, that does look like it's that issue.


refuses to work since it requires the directories containing the scripts to have mode 755, but the nixos module creates them with mode 750. Steps to reproduce the behavior: (re)-configure an interface (for example by unplugging and replugging a network cable) something like in the journal and that does not exist, i.e. the hook was never run. networkd-dispatcher works. <!-- 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.
Thank you for the report! I'm thinking about adding a rules option to the networkd-dispatcher module so this might solve your issue


Project description fre:ac is a free audio converter and CD extractor for Microsoft Windows, Linux, macOS and FreeBSD, distributed under the GNU General Public License.[1] Besides extracting audio from compact discs (with various features including hidden track detection), fre:ac can also convert audio files from one format to another or to the same format but a lower bitrate. fre:ac is compatible with many audio formats such as Ogg Vorbis, FLAC, MP3, MP4/M4A, AAC, WAV, WMA and more.[2][3] fre:ac uses the CDex library to convert from CDs and uses freedb to retrieve artist/song information from the internet which is written to the files as various types of ID3 tags; this library supports cdparanoia which aims to improve audio quality.[4] The user interface is multilingual with 43 languages and is able to be a portable install on a USB drive. Metadata homepage URL: source URL: license: GNU General Public License v2.0 platforms: Windows, macOS, Linux, FreeBSD, HaikuOS
freac is already available on my nur repo If you want to avoid building it, it should be on my cachix https://scott- (for nixos-20.9, nixpkgs-unstable and nixos-unstable)


I'm using , and I'm trying to perform an update: The update works. (information found from )
What does have to do with ? Can you reproduce the problem with just & ?
Beginner here. I think that is using under the hood. I don't know how. Should I report this issue to instead?
Sounds like breaks vscodium darwin build :upsidedownface: I will do a PR


defines a package option, but does not use it in the service definition. Steps to reproduce the behavior: an alternative package to use system is ignored As there is an option to set an alternative package, this setting should be honored. The current version of pkgs.pgmanage is broken, which was the motivation to actually use the package option.


, CVSSv3=5.5 (nixos-21.11, nixos-unstable) CVSSv3=4.9 (nixos-21.11, nixos-unstable) CVSSv3=4.9 (nixos-21.11, nixos-unstable) CVSSv3=4.9 (nixos-21.11, nixos-unstable) CVSSv3=4.9 (nixos-21.11, nixos-unstable) CVSSv3=4.3 (nixos-21.11, nixos-unstable) Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Compiling). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Federated). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Stored Procedure). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior.


Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Parser). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges). Supported versions that are affected are 5.7.36 and prior and 8.0.27 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 4.3 (Integrity impacts).


CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N). Scanned versions: nixos-21.11: ; nixos-unstable: .
See also: , , , , , ,
Fixed: nixos-21.11: mysql-5.7.37, mysql-8.0.28 nixos-unstable: mysql-5.7.39, mysql-8.0.30


Project description Universal Scene Description (USD) is an efficient, scalable system for authoring, reading, and streaming time-sampled scene description for interchange between graphics applications. OpenUSD is AFAIK the library to work with the USD format. Metadata homepage URL: source URL: license: Modified Apache 2.0 License platforms: unix, linux, darwin
I've got a working derivation, but I'm not sure if this is already in a state that is good enough for a PR. In particular, packaging the pyside tools properly didn't seem straightforward to me. AFAICT, it just copies some binaries from other QT parts and wraps them with extra arguments, so that's what I'm doing here. While the python package seems to be working properly, I ran into an issue before when trying to include the headers into a C++ project, and I believe it failed to find some python headers? Maybe that needs some extra buildInput? I haven't investigated more. Locally, I've just been using a version compiled with for that. The binaries, such as , are working by my testing, besides requiring on wayland. I'd be happy to make a PR for this if this is a good-enough state.


CLion 2021.3.3 derivation fails to build. Steps to reproduce the behavior: to system/user packages The system rebuilds. Seems the folder has been renamed to just : Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(zane): channels(root): nixpkgs:
Same issues here, waiting for fix : (
cc


, CVSSv3=7.5 (nixos-20.03, nixos-unstable) CVSSv3=7.5 (nixos-20.03, nixos-unstable) CVSSv3=5.9 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives. Cc Cc
A security update 1.6.24 addressing the vulnerabilities exists. I'd suggest marking openafs-1.6 as broken, now, to enforce migration to openafs-1.8. I am unaware of plans to further maintain openafs-1.6 beyond 1.6.24. Edit: Maybe, we should do both, update to 1.6.24 and mark it broken. So, users have a secure version as of now and still get the hint to take action.
Alternative idea: Go with only openafs 1.8 on master and upgrade to openafs 1.6.24 on NixOS 20.03. This way, user must migrate to 1.8 when upgrading to NixOS 20.09 which is the only sensible action security wise.
This is fixed with the move to 1.6.24 for 20.09. Closed.


Steps to reproduce the behavior: cryptowatch-desktop download url redirects to a blog Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
As of September the 30th 2023, Cryptowatch was sunset and users were advised to use their parent companies offering Kraken Pro. I'll create a pull request to remove cryptowatch from nixpkgs as there aren't any archives available that contain it that are reliable


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


Using on macOS requires using . Steps to reproduce the behavior: a new nix file: it with error The derivation and the built docker image work fine, and should build correctly even without . I believe this might be due to , while it's true docker cannot run macOS binaries, nix can be used to build Linux binaries on macOS, either by downloading them from a binary cache or by cross compiling, and those binaries can be put in docker images. cc
The fix is as simple as you suggest. I don't expect any problems with . Some users already do what you're doing but with .


Describe the bug The desktop file packaged with VSCodium specifies the wrong StartupWMClass To Reproduce VSCodium on the started application Expected behavior Step 4 prints . Therefore step 5 should print one of those strings. But instead, the file contains . Additional context Those must match or else the application won't be linked to the .desktop file when started. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels: nixpkgs: Maintainer information:
I'm surprised says that the is . After all, for it seems to be , as , and as I also just tested on my system: After all, the executable for vscode is and for vscodium it's . Nevertheless, I can reproduce your output. Since I don't know whether that could be changed, it's probably easier to simply change the file. Will push a PR in a moment.
I wish I could assign myself to this issue.
I had a quick look at the history of the and they had it this way since the beginning. So I think it's safe to assume this won't change anytime soon.


Project description Keeweb webapp is a browser and desktop password manager compatible with KeePass databases. It features an Electron-based desktop application. Metadata homepage URL: source URL: license: mit platforms: Electron (unix, linux, darwin, windows) and Web
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 important to me
While PR to nixpkgs is still open, I've keeweb to NUR repo () as well.


Gives this error: , yet installing doesn't fix the problem. Steps to reproduce the behavior: Meteo That the Maps section works. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I have this exact issue. Hoping for some clarity.
should be here:


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


This might just be darwin; haven't tried on Linux. $ nix-shell -p these derivations will be built: /nix/store/dpcwgrlydrrlbdrnf0mi9hmr0kjvia89-python3.7-fire- building '/nix/store/dpcwgrlydrrlbdrnf0mi9hmr0kjvia89-python3.7-fire-'... unpacking sources unpacking source archive /nix/store/20rzw7yi3yvjb7w2ixzj6aqa5fim6p1q-source source root is source setting SOURCEDATEEPOCH to timestamp of file patching sources configuring building running bdistwheel The [wheel] section is deprecated. Use [bdistwheel] instead. running build running buildpy creating build creating build/lib creating build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire installing to running install running installlib creating creating creating copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - running installegginfo running egginfo creating writing writing dependencylinks to writing requirements to writing top-level names to writing manifest file '' reading manifest file '' reading manifest template '' writing manifest file '' Copying to running installscripts creating creating 'dist/fire-0.1.3-py2.


py3-none-' and adding '' to it adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding '' adding 'fire-' adding 'fire-' adding 'fire-' adding 'fire-' adding 'fire-' removing installing /private/var/folders/8g/qgvf93s1b40dd8nhsvqkm0000gn/T/nix-build-python3.7-fire- /private/var/folders/8g/qgvf93s1b40dd8nhsvqkm0000gn/T/nix-build-python3.7-fire- Processing ./fire-0.1.3-py2.py3-none- Requirement already satisfied: six in /nix/store/qayyh24znx8kixy7wqz6i5416nyljzxk-python3.7-six-1.12.0/lib/python3.7/site-packages (from fire==0.1.3) (1.12.0) Installing collected packages: fire Successfully installed fire-0.1.3 /private/var/folders/8g/qgvf93s1b40dd8nhsvqkm0000gn/T/nix-build-python3.7-fire- post-installation fixup strip is /nix/store/3ibh116gnggzgsvrq8vvalmqyipk8cy9-cctools-binutils-darwin/bin/strip stripping (with command strip and flags -S) in /nix/store/b96a60g0apqx015sscpv8jywnjd8svcq-python3.7-fire-0.1.3/lib patching script interpreter paths in /nix/store/b96a60g0apqx015sscpv8jywnjd8svcq-python3.7-fire-0.1.3 running install tests ============================= test session starts ============================== platform darwin -- Python 3.7.2, pytest-4.2.1, py-1.7.0, pluggy-0.8.


1 hypothesis profile 'default' -database=DirectoryBasedExampleDatabase('/private/var/folders/8g/qgvf93s1b40dd8nhsvqkm0000gn/T/nix-build-python3.7-fire-') rootdir: /private/var/folders/8g/qgvf93s1b40dd8nhsvqkm0000gn/T/nix-build-python3.7-fire-, inifile: plugins: hypothesis-4.7.3 collected 160 items . [ 0%] ...... [ 4%] ... [ 6%] .. [ 7%] .............. [ 16%] ............. [ 24%] ........... [ 31%] ... [ 33%] ...............F........F..................... [ 61%] .F........ [ 68%] .F....... [ 73%] .. [ 75%] .................... [ 87%] .. [ 88%] ... [ 90%] ............... [100%] =================================== FAILURES =================================== _ FireTest.testFireKeywordArgs _ self = <fire.firetest.FireTest testMethod=testFireKeywordArgsdef testFireKeywordArgs(self): self.assertEqual( fire.Fire( tc.Kwargs, command=['props', '--name', 'David', '--age', '24']), {'name': 'David', 'age': 24}) # Run this test both with a list command and a string command.


self.assertEqual( fire.Fire( tc.Kwargs, command=['props', '--message', '"This is a message it has -- in it"']), # Quotes stripped {'message': 'This is a message it has -- in it'}) self.assertEqual( fire.Fire( tc.Kwargs, command=['props', '--message', 'This is a message it has -- in it']), {'message': 'This is a message it has -- in it'}) self.assertEqual( fire.Fire( tc.Kwargs, command='props --message "This is a message it has -- in it"'), {'message': 'This is a message it has -- in it'}) self.assertEqual( fire.Fire(tc.Kwargs, command=['upper', '--alpha', 'A', '--beta', 'B']), 'ALPHA BETA') self.assertEqual( fire.Fire( tc.Kwargs, 'alpha beta') component = <class 'fire.testcomponents.Kwargs'command = ['upper', '--alpha', 'A', '--beta', 'B', '-', ...], name = '' def Fire(component=None, command=None, name=None): """This function, Fire, is the main entrypoint for Python Fire. Executes a command either from the argument or from by recursively traversing the target object 's members consuming arguments, evaluating functions, and instantiating classes as it goes. When building a CLI with Fire, your main method should call this function. Args: component: The initial target component. command: Optional. If supplied, this is the command executed. If not supplied, then the command is taken from instead. This can be a string or a list of strings; a list of strings is preferred. name: Optional. The name of the command as entered at the command line. Used in interactive mode and for generating the completion script. Returns: The result of executing the Fire command. Execution begins with the initial target component. The component is updated by using the command arguments to either access a member of the current component, call the current component (if it's a function), or instantiate the current component (if it's a class). When all arguments are consumed and there's no function left to call or class left to instantiate, the resulting current component is the final result. Raises: ValueError: If the command argument is supplied, but not a string or a sequence of arguments.


FireExit: When Fire encounters a FireError, Fire will raise a FireExit with code 2. When used with the help or trace flags, Fire will raise a FireExit with code 0 if successful. """ name = name or ([0]) # Get args as a list. if isinstance(command, six.stringtypes): args = (command) elif isinstance(command, (list, tuple)): args = command elif command is None: # Use the command line args by default if no command is specified. args = [1:] else: raise ValueError('The command argument must be a string or a sequence of ' 'arguments.') # Determine the calling context.


caller = ()[1] callerframe = caller[0] callerglobals = callerframe.fglobals callerlocals = callerframe.flocals context = {} (callerglobals) (callerlocals) componenttrace = Fire(component, args, context, name) if componenttrace.HasError(): for helpflag in ['-h', '--help']: if helpflag in componenttrace.elements[-1].args: command = '{cmd} -- --help'.format(cmd=componenttrace.GetCommand()) print(('WARNING: The proper way to show help is {cmd}.n' 'Showing help anyway.n').format((command)), ) print('Fire trace:n{trace}n'.format(trace=componenttrace), ) result = componenttrace.GetResult() print( helputils.HelpString(result, componenttrace, componenttrace.verbose), ) E 2 FireExit ----------------------------- Captured stdout call ----------------------------- name: David age: 24 message: This is a message it has -- in it message: This is a message it has -- in it message: This is a message it has -- in it ALPHA BETA ----------------------------- Captured stderr call ----------------------------- Fire trace: Initial component Instantiated class "Kwargs" (/private/var/folders/8g/qgvf93s1b40dd8nhsvqkm0000gn/T/nix-build-python3.7-fire-) Accessed property "upper" (/private/var/folders/8g/qgvf93s1b40dd8nhsvqkm0000gn/T/nix-build-python3.7-fire-) Called routine "upper" (/private/var/folders/8g/qgvf93s1b40dd8nhsvqkm0000gn/T/nix-build-python3.7-fire-) Accessed property "lower" ('The function received no value for the required argument:', 'self') Type: builtinfunctionormethod String form: <built-in method lower of str object at 0x1116ffef0Docstring: Return a copy of the string converted to lowercase.


Usage: upper --alpha A --beta B - lower SELF upper --alpha A --beta B - lower --self SELF _ FireTest.testFireObjectWithDict _ self = <fire.firetest.FireTest testMethod=testFireObjectWithDictdef testFireObjectWithDict(self): self.assertEqual( fire.Fire(tc.TypedProperties, command=['delta', 'echo']), 'E') self.assertEqual( component = <class 'fire.testcomponents.TypedProperties'command = ['delta', 'echo', 'lower'], name = '' def Fire(component=None, command=None, name=None): """This function, Fire, is the main entrypoint for Python Fire. Executes a command either from the argument or from by recursively traversing the target object 's members consuming arguments, evaluating functions, and instantiating classes as it goes. When building a CLI with Fire, your main method should call this function. Args: component: The initial target component. command: Optional. If supplied, this is the command executed. If not supplied, then the command is taken from instead. This can be a string or a list of strings; a list of strings is preferred. name: Optional. The name of the command as entered at the command line. Used in interactive mode and for generating the completion script. Returns: The result of executing the Fire command. Execution begins with the initial target component. The component is updated by using the command arguments to either access a member of the current component, call the current component (if it's a function), or instantiate the current component (if it's a class). When all arguments are consumed and there's no function left to call or class left to instantiate, the resulting current component is the final result. Raises: ValueError: If the command argument is supplied, but not a string or a sequence of arguments. FireExit: When Fire encounters a FireError, Fire will raise a FireExit with code 2. When used with the help or trace flags, Fire will raise a FireExit with code 0 if successful. """ name = name or ([0]) # Get args as a list. if isinstance(command, six.stringtypes): args = (command) elif isinstance(command, (list, tuple)): args = command elif command is None: # Use the command line args by default if no command is specified.


args = [1:] else: raise ValueError('The command argument must be a string or a sequence of ' 'arguments.') # Determine the calling context. caller = ()[1] callerframe = caller[0] callerglobals = callerframe.fglobals callerlocals = callerframe.flocals context = {} (callerglobals) (callerlocals) componenttrace = Fire(component, args, context, name) if componenttrace.HasError(): for helpflag in ['-h', '--help']: if helpflag in componenttrace.elements[-1].args: command = '{cmd} -- --help'.format(cmd=componenttrace.GetCommand()) print(('WARNING: The proper way to show help is {cmd}.n' 'Showing help anyway.n').format((command)), ) print('Fire trace:n{trace}n'.format(trace=componenttrace), ) result = componenttrace.GetResult() print( helputils.HelpString(result, componenttrace, componenttrace.verbose), ) E 2 FireExit ----------------------------- Captured stdout call ----------------------------- E ----------------------------- Captured stderr call ----------------------------- Fire trace: Initial component Instantiated class "TypedProperties" (/private/var/folders/8g/qgvf93s1b40dd8nhsvqkm0000gn/T/nix-build-python3.7-fire-) Accessed property "delta" Accessed property "echo" Accessed property "lower" ('The function received no value for the required argument:', 'self') Type: builtinfunctionormethod String form: <built-in method lower of str object at 0x1100c7340Docstring: Return a copy of the string converted to lowercase.


Usage: delta echo lower SELF delta echo lower --self SELF __ HelpUtilsTest.testHelpStringBuiltin _ self = <fire.helputilstest.HelpUtilsTest testMethod=testHelpStringBuiltindef testHelpStringBuiltin(self): helpstring = helputils.HelpString('test'.upper) self.assertIn('Type: builtinfunctionormethod', helpstring) self.assertIn('String form: <built-in method upper of', helpstring) E AssertionError: 'Usage: [VARS ...] [--KWARGS ...]' not found in 'Type: builtinfunctionormethodnString form: <built-in method upper of str object at 0x11028d458nDocstring: Return a copy of the string converted to uppercase.nnUsage: SELFn --self SELF' AssertionError _ InspectUtilsTest.testGetFullArgSpecFromBuiltin _ self = <fire.inspectutilstest.InspectUtilsTest testMethod=testGetFullArgSpecFromBuiltindef testGetFullArgSpecFromBuiltin(self): spec = inspectutils.GetFullArgSpec('test'.upper) E AssertionError: Lists differ: ['self'] != [] E E First list contains 1 additional elements.


E First extra element 0: E 'self' E E - ['self'] E + [] AssertionError =============================== warnings summary =============================== /private/var/folders/8g/qgvf93s1b40dd8nhsvqkm0000gn/T/nix-build-python3.7-fire- DeprecationWarning: 'U' mode is deprecated self.fromlines = open(fromfile, 'U').readlines() /private/var/folders/8g/qgvf93s1b40dd8nhsvqkm0000gn/T/nix-build-python3.7-fire- DeprecationWarning: 'U' mode is deprecated self.tolines = open(tofile, 'U').readlines() -- Docs: ============== 4 failed, 156 passed, 12 warnings in 1.80 seconds =============== builder for '/nix/store/dpcwgrlydrrlbdrnf0mi9hmr0kjvia89-python3.7-fire-' failed with exit code 1 error: build of '/nix/store/dpcwgrlydrrlbdrnf0mi9hmr0kjvia89-python3.7-fire-' failed nix-shell -p nix-info --run "nix-info -m" system: host os: multi-user?: sandbox: version: channels(abathur): nixpkgs: FWIW, I'm also running bash 5 () as my default shell atm, but I see the same error when I manually run launch a bash 4 () shell to run this in. I haven't updated channel in a bit but I don't see any open/recent issue or PR.


Relevant snippet while building it fails with I copied over the for debugging, this is the full output: Steps to reproduce the behavior: snippet as flake default output Build should succeed and images should be loadable via Patching the as follows: fixes the problem, but would probably hide other cp errors. Maybe the behavior of coreutils/cp changed in the recent versions. At least the current manual states it will fail silently. I'm using a linux-builder on my machine.
Thank you for reporting this. I’ll try to replicate this locally. The lines do not look like errors to me. It looks like is informing that those files already exist in the output and thus are skipped (--no-clobber). However, if the build is failing there’s something going wrong.
Thank you for linking the manual. It looks like will exit with a non-zero status code in case of files that are already present now. The coreutils changelog states that now reproduces the behavior had at the time I wrote the mergeImages script. I was able to build by changing to . I don't know how to best go about obtaining the behavior everywhere, should the flag be dependent on the version of somehow? Maybe we can just assume that in will be a new version from now so that we can use everywhere? Given that all files that are present in both docker images apart from the and repositories files should be content addressed the only issue with removing is that time is spent unnecessarily writing content that's already present, so removing the flag altogether might make sense.
Thanks for investigating! I'm not familiar with the backward compatibility policy of the nix ecosystem, but I would assume that the most recent version of can assume most recent coreutils. Might happen that someone is overlaying old coreutils but then you might just need to overlay the old too, if you can pinpoint it down to coreutils cp.
True, but then apparently they have a legacy software problem, in which case they should use overrides only where it is necessary, instead of a blanket override in an overlay. It is not realistic to expect all of Nixpkgs to work with arbitrary changes. The cost of such compat logic isn't worth it; certainly not in this case, until proven otherwise. If they contribute a full time maintainer it is worth it, and if they have a legacy software problem they probably can.


Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.


gcc5 and the dependant gfortran5 packages are failing as of 31 July Failures: ] ] Building either package using or fails. System: (MacOS 10.11.6 and MacOS 10.12.6, both nix-multiuser install) Nix version: (1.11.13) Nixpkgs version: (17.09pre-git) Sandboxing enabled: (relaxed)
has been looking into this but it seems pretty mysterious so far
git-bisect is pretty neat
cc
This is also needed to fix things that depend on gcc


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


Steps to reproduce the behavior: FWIW: my fix is here, - but it is using a fork of . If somebody has the time to create a minimal patch on top of the current source, please feel free to. Please run and paste the result.
Looks like you are on a good path. Unfortunately I have no access to Apple hardware at all, but would be happy to merge a PR.
Yes, is working on it. There is a more active fork of luabind here: - how about we switch to using it? It'll obviate a bunch of patches as well.
I agree, sounds sensible.


I get the error: It seems that this problem is related to There is no problem for System: 17.03pre94121. (Gorilla) and on master Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: 17.03pre94121.
it seems the tests depend on a package like


XOrg crashes when certain applications are launched. More details here: Steps to reproduce the behavior: any of the IntelliJ IDEs. You may have to set anti aliasing to greyscale. Xorg will crash. Xorg doesn't crash. This is the bug: It looks like a security fix caused this regression. Ubuntu has already applied patches that fix this for Xorg and Xwayland: see this message from the above Ubuntu thread: NixOS should use the same patches until this is fixed upstream in XOrg. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Sounds like this will be addressed by this update:
xwayland too: looks like updating xorg and xwayland to their latest versions will do the trick then
xwayland was bumped to the latest version in PR


Installing results in a broken application that exits on startup with the message "GEGL operation missing! Glimpse requires the GEGL operation "gegl:introspect". This operation cannot be found. Check your GEGL install and ensure it has been compiled with any dependencies required for Glimpse." Steps to reproduce the behavior: to Glimpse Glimpse should work! works fine for me. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
Thanks for the report, Unfortunately I cannot reproduce your issue. Neither on as you reported nor on current . Could you elaborate on your setup a bit? Which window manager/desktop environment are you using? Is it possible that you modified glimpse in an overlay? I'm running Sway (Wayland) and deleted and before testing to make sure I didn't have any leftover state in my home directory.
I'm using i3wm (with no separate desktop manager); I installed Glimpse by adding it to environment.systemPackages in , I don't think there's any chance I did anything special with overlays there. I can't think of anything else I've done that might have affected this – I only installed NixOS a few days ago. I do have Home Manager installed, so I guess is it possible that something I've installed via that is causing a problem? (I don't have that much stuff installed, though, I don't think.) on my system is a tmpfs, so if something put a file outside of /nix or /home on install and is expecting it to still be there then it'll be unhappy, but I think I tried running Glimpse immediately after installing it with and it didn't work even then, so it shouldn't be anything related to that. Deleting changes the icon in the popup, which is weird, it looks like this if that directory isn't present at statup: ! and like this if I leave the directory there: ! but nothing else seems to change. (I noticed there's a directory in and , but removing it doesn't seem to do anything.)
aha, I found the problem: works just fine, and adding graphviz to environment.systemPackages fixes it permanently. see e.g.


Ooh nice, didn't think about using a pure nix-shell to circumvent already installed packages clouding the issue. Now I'm able to reproduce the issue. Will add graphviz as runtime dependency then.
Looks like Gimp is not affected, as they got it . Glimpse didn't receive that fix, and it won't in the foreseeable future as the project .


Steps to reproduce the behavior: (warning: veeery long) Seems caused by Also previously reported (if I'm reading the many thousands of lines of output right) to be another instance of Breaks: .
This appears to have been fixed somewhere between and
I have no idea how you tested, but after a (pulling branch), I fail to build this same package. Now with the newer hash: I vote for this issue to be marked as "prematurely-closed", and thus re-opened.
debugpy was blocking my nixos rebuilds through . Updating to resolved it for me. That's about all the testing I did at the time, and figured it was good. Sorry about that.
Yep! Looks like this is related to flaky process test timeouts (which are more likely to fail on less powerful / overworked devices). should fix this!
You can checkout to see when the fix will be applied to the channel you're using.


Project description Flawfinder is a simple program that scans C/C++ source code and reports potential security flaws. It can be a useful tool for examining software for vulnerabilities, and it can also serve as a simple introduction to static source code analysis tools more generally. It is designed to be easy to install and use. Flawfinder supports the Common Weakness Enumeration (CWE) and is officially CWE-Compatible. Metadata homepage URL: source URL: license: gpl2 platforms: unix, linux, darwin
could you please test Thanks
Works for me on NixOS. I wrote a simple c program that it found the vuln in: where it gave:


<!-- 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: <!-- 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: 4.6.3 desired version: 4.11.2 <!-- 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.


Not all the executables of the /contrib directory are patched, so some functionalities of the theorem prover fail. For instance, running the Sledgehammer tool (subwindow in the bottom bar of Isabelle starting window) always fail with: The directory: The sub directories marked with a star contain the x64 executables I tried to execute manually and I got: "Not such file or directory" Run Isabelle and try to use Sledgehammer. Then try to execute the executables in the marked directories, and you will obtain "Not such file or directory". System: 16.03.1171. (Emu) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: "16.03.1171." I am definitely new to NixOS, but with my nonexistent experience I think at least two solutions are available: 1) I can substitute the broken software with the packaged one, as it is done with Java and Polyml in the Isabelle2016 derivation; 2) I can patch the executables with patchelf (hopefully). I did not have time to try these so far, but I was wondering how difficult would be the 2nd: I think that using (1) can potentially break Isabelle since we would use different versions of the software in /contrib. You guys are amazing! Thanks a lot for NixOS!!! It is the most elegant OS I ever tried!
Hello, after some experimenting, I found a hack to make Isabelle work in Nixos Emu x64: this derivation substitutes the broken provers and rebuilds the exec-process executable. What I do not like of this solution: the provers are not the same (versions) of the Isabelle distribution, and this works only for x64 -- if you use a 32 bit you have just to change (take away the_64 bit from the target directory name) the derivation after the comment in the postPatch phase. However it works. Hopefully someone more expert than me can propose a better solution! Thanks again!!


<!-- 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: 2.1.1 desired version: 2.1.3 <!-- 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 seems that this version has a few changed dependencies ( instead of )


The is failing to build Steps to reproduce the behavior: Package should build
related to
This is unrelated, GNOME 43 is not yet released. Most likely this was caused by gobject-introspection changes.
gobject-introspection should be in nativeBuildInputs instead of buildInputs


fails when building the wheel for pip. (Building the wheel for wheel succeeds.) Steps to reproduce the behavior: Build succeeds as it does for regular Python: (there are no maintainers given)
Which branch is this on?
~Can't reproduce this on master nor on nixos-22.05.~ pypy version succeeds, pypy3 version fails. master and nixos-22.05
Probably also on 21.11. -No, 21.11 is fine. -
Encountered on Nixpkgs 21.11 system: host os: multi-user?: sandbox: version: nixpkgs:
Bisected to the 7.3.7 update. Newer pypy3 versions exhibit the same problem. Our pypy3 package set is clearly unmaintained. cc
Fixed in .


The package hard-codes various X11 libraries as dependencies while making many other features optional, including GUIs. It would be nice to have an option to disable the X11 feature and the related . The use case I have in mind is installing a custom Vim on a remote server. Pulling X libraries, even without enabling a GUI, adds a few dozen megabytes for something essentially useless. An approach is doing something like this: but it doesn't feel very clean... Any thoughts from or ?
I agree. It would have been nice if these X dependencies would have been to only if is or .
/me whispers neovim~~~
I'm all for testing new things and neovim is on my list. But according to , the neovim package pulls 428MiB of dependencies, half of which for Ruby, the other half for both Python 3 and Python 2 (seriously?). Is there a way, by any chance, to configure neovim to avoid this bloat ?
admittedly I've never tried to configure a mininmal version but one can unselect these ecosystems:
See .


is empty. As a result plugin is not loaded and there is no socket. Relevant part of build log: There must be python instead of : before ./format- ^^^


Package name: sqlx-cli Latest released version: 0.7.3 <!-- Search your package here: --- Current version on the unstable channel: 0.7.1 Current version on the stable/release channel: 0.7.1 <!-- 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'll take a look at this tomorrow. Thanks for the ping.


Project description This allows applications like Discord that use xwayland to capture Wayland windows. Metadata homepage URL: source URL: license: GPL2+ platforms: Linux
I wanted to test this and packaged it my config repo. I'm not interested in being a maintainer, but I can submit a PR or someone else can feel free to use mine as a base. The project is definitely beta though cause it segfaulted when resizing Dolphin and crashed Plasma entirely.
If this is the wrong place to post, please let me know. I can see the package here under However I'm getting the following error after adding to systemPackages when switching:
I guess you jsut want to "cherry-pick" xwaylandvideobridge from unstable, but the rest of your system follows e.g. stable by default? First you add unstable channel if not already done and refresh the package definitions: Import it in your And then you add it to your systemPackages via .


Describe the bug getting when trying to scan over network (scanning from the , scanner device connected to via usb) To Reproduce Steps to reproduce the behavior: server config: client config: on the : choose the network scanner : stops scanning immediately, server logs have an entry: from Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Guessing here, looking at the commit log for the service definition, apologies for pinging a lot of people: Metadata Please run and paste the result. server (managed via nixpkgs): client: Maintainer information:
I marked this as stale due to inactivity. →
Please test
nice ! will do in few days as I'm moving house :)
Hi just tested it now and it works very well !
approve the pr


Describe the bug The recent Haskell generic-builder changes for Darwin (in particular according to bisect) have broken . To Reproduce from a nixpkgs at or later on Darwin. This fails with . Additional context is a pure Haskell package, that depends on , which is what actually uses the C dynamic library. So the problem seems to be that fails to include the C library in its closure. Interestingly, this C library has filename not , even though it looks exactly like a dylib as far as I can tell (I'm not expert in macOS linking): So I can see why would fail to be included into by . However, I don't see why broke it. Nothing to do with the C or Haskell packages involved has changed for months. Updating the generic-builder to include as well as files does fix the problem for me, and seems benign, so I'll submit a PR for that. But I don't feel I understand everything going on here, so I'm opening the issue in case more qualified folks can identify a better root cause fix. Metadata system: host os: multi-user?: sandbox: version: channels(simon): nixpkgs: Maintainer information: Ping from the original changes - thanks for all your efforts!
Just noting here that there is some useful discussion .


Not sure if this is known, but I'm seeing the following error when trying to do . System: Fedora 23 Nix version: 1.11.2 Nixpkgs version: 16.09pre81657.


I currently cannot execute any 32 bit Linux binaries on my 64 bit system and this breaks updates, since I have 32 bit support enabled in the nix options: I remember that this worked about a week ago, so something has changed. I am new to NixOS, so its possible that I have done something wrong. I used ArchLinux for about 9 years before that and now NixOS for just 3 months and its concepts are still foreign for me. As a long term linux user (about 15 years) I do feel a bit out of place in NixOS. So I am not sure how to fix that myself. Not sure. I have wine installed and support for 32 bit games enabled. Then I normally do just 'nixos-rebuild switch --upgrade' to upgrade, and sometimes 'nix-channel --update'. I also regularly do 'nix-collect-garbage -d'. No idea if that is reproducible or not.
This might be from Could you see if it works without that commit? Also verify that /nix/store/4qj9vzggfzsc34ci79ckaim5cjrwc6ns-bash-4.4-p23/bin/bash executes. I can run it on my system. You can run this to verify that your store is not corrupted:
I solved it now for me. Instead of using the 'linuxPackagestestinghardened' 4.20 linux kernel I switched back to 'linuxPackages419' 4.19.2 kernel and now executing 32 binaries work again. So I guess the hardened kernel does not support executing 32 bit binaries. Does it make sense to have some kind of visible warning here? I normally would not have used the hardened kernel, if that wouldn't have been the only 4.20 version is I get. Its not clear to me when and how those changes in master appear in my nixpkgs/nixos channel (I am on unstable). I would like to use the master branch directly, but I haven't figured out how to best do that yet.
The same here, hardened kernel 4.18.17 and build failed.


building '/nix/store/6h9asn7rc93dbwfcs6xaj3k0qgxmg0vh-libtxcdxtn-'... while setting up the build environment: executing '/nix/store/xgf4vra77qrww0n228hd80jsdccdp54w-bash-4.4-p23/bin/bash': Exec format error builder for '/nix/store/6h9asn7rc93dbwfcs6xaj3k0qgxmg0vh-libtxcdxtn-' failed with exit code 1 building '/nix/store/cfwj5yjby2xvagyj69zd1yx8hdhi27ay-'... cannot build derivation '/nix/store/maynq4fxxjc217figygdrgg5q9xnw6yy-mesa-drivers+txc-': 1 dependencies couldn't be built cannot build derivation '/nix/store/wv9b4ayvgnpkvwz81zkk0lm9w4v5pd1y-opengl-drivers-': 1 dependencies couldn't be built cannot build derivation '/nix/store/q61vc27rdbcsrhxifiw89w1qdjax1amh-nixos-system-brix-': 1 dependencies couldn't be built error: build of '/nix/store/q61vc27rdbcsrhxifiw89w1qdjax1amh-nixos-system-brix-' failed Thanks
Maybe the hardened kernel shouldn't set when NixOS' is an ?
It should be 64 bit for the x86_64-linux stdenv. But some packages use the i686 stdenv.
I am not too familiar with stdenv. Is this expected behaviour that a 64-bit system uses 32-bit binaries? This issue is reproducible building as well.
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 .
This should be resolved by - please reopen if there's still a problem.


<!-- 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: rtl-sdr <!-- 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: 0.6.0 desired version: 0.8.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: This package is currenty using but it should probably switch to Please tag this issue in your PR.


Describe the bug Gitlint fails to build due to a dependency on click v7.1.2 To Reproduce Steps to reproduce the behavior: Expected behavior Successful build of gitlint Screenshots ! Additional context Looks like click got separated into two packages, one where it updated to 8.0.1 and is present in and one where it was kept back for . Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(david): nixpkgs: Maintainer information:
Yeah this is interesting. As far as I know, things shouldn't just break like this. I assume this is a regression, as it used to build, it seems a LOT of stuff has started breaking.
doesn't work with later releases. We have 8.0.1 and is pinning all releases (affects also , I guess). It would requires that is overriding the releases.
could you please give a try?
Looks to be good on my system. Runs as intended with


Project description The elevator pitch: But it's mostly used to install and run AI applications pretty easily, the creator made this video: Which is the same as on the homepage. Metadata homepage URL: https://pinokio.computer/ source URL: license: MIT platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I created a PR based on this packaging request.


On a fresh install, lightdm is writing several files to / These should probably be either in /root or in some other runtime .cache and .gtkrc-2.0 Steps to reproduce the behavior: NixOS with X enabled, using the default lightdm display manager. soon as the display manager starts, files are written to / That my / will stay clean. If I stop display-manager.service, delete the files, then restart it, the files return. Looking in my /etc/passwd, shows that lightdm does have a home directory set at /var/lib/lightdm. But for some reason these files are not being written there as they should be. Please run and paste the result.
I just realized after I posted this that I used an old iso from 21.11 to install. So I reinstalled with 22.05, and this still happens
Are you using KDE Plasma? Can you reproduce the issue with SDDM?
I am using KDE. The issue also happens with SDDM. I went ahead and tested GDM as well (while still using plasma,) and it does not happen.
I can reproduce. For my case, in I saw one single file with prefix, after some search it is likely cache for kbuildsycoca5 (). I have no idea what that package does so far though.
All the files in my / are exactly the files being generated in
I can reproduce this with Plasma 5/SDDM on nixpkgs-unstable.
I also observed these files, tracked down the problem and prepared a pull-request that -- hopefully -- fixes the issue: . I came to the conclusion that it is best to entirely remove the code that creates those file. However, I feel a bit unconfident about my solution, so it would be good to have it tested by more users. If you can spare the time, please have a look at my draft pull request, maybe try my solution, and feel free to report back or even drop a review. Thanks a lot!


crashes instantly and won't start with the new Darwin stdenv. My is bundled with quite a few Emacs packages, so this may be a bit hard to isolate, but hopefully it's reproducible anyway. Build with recent . This is with . Partial Problem Report included below. I've elided most of it for privacy reasons; let me know if you need more info:
Can reproduce on current "master". "open " won't start anything, but I don't get a crash report, nothing appears in ~/Library/Logs/DiagnosticReports/. edit: got my crash report a bit later, it's the same stacktrace as reported
The regular works.
Looks like libdispatch is too old. Working on it now
I've opened up a draft that I think might fix it: I'm building it now, but if you have a beefy machine it might help to try to build it as well
I'm afraid that doesn't fix the issue. Here's a gist with the new crash, which looks more or less identical to the one I posted above: I built this with my fork here: I'm trying to confirm that this has been built with the updated . I'm having trouble tracking it down. Can you tell me how to figure it out?
Here's a simpler repro case. This happens when I try to build using and the melpa Emacs pacakge:
So the short term fix is just to use llvm6. At some point, I'll try to dig into what is actually happening, but I suspect something has changed in how llvm handles threads.
Thank you! I’m happy to use a work-around and didn’t expect you to address this complex issue so quickly! I was resigned to using the vanilla emacs for the foreseeable future, so this is a very welcome development.
I can confirm that this appears to be fixed in my Hydra builds, as well.


Gitlint CLI tool and pre-commit hook plugin to lint commit messages with presets Metadata homepage URL: source URL: license: MIT platforms: linux, unix, darwin (python3)
This isn't my library, I simply requested for this package. should i still be included as maintainer?
Also, do I make a PR with the code above? Or is there already a PR
There is no PR yet. New packages need a maintainer and I don't want to maintain this.
I'll do it. I'll send in a PR now.


chia farmer fails to register with a pool over https. Relevant log contains: Steps to reproduce the behavior: a new-style chia plot with a pool up a farming node Chia should successfully run. If applicable, add screenshots to help explain your problem. Based on , the missing file is . Upstream normally but this appears to fail here. (This is in an LXC container so it's a bit weird) system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:


Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: python311Packages.astropy maintainers cc: Other cc: n/a nixpkgs at commit Contents of : This issue was automatically generated by . that created this issue. Internal tags: -
Looks like may be the problematic line. Looks like a flaky test, we should prob disable it.
seems to fix this. If anyone wants to review it you are welcome. I will merge it otherwise myself because CI is green there.


Project description Metadata homepage URL: source URL: license: idk, its not obvious and im not a lawyer platforms: unix/linux?


Rofi doesn't seem to find the application for VSCode even though the .desktop file seems to be there. It shows the command when running but when running it doesn't seem it show.


Thunderbird fails to compile with " error: undefined symbol: wlproxymarshal_flags" when rebuilding system configuration. Steps to reproduce the behavior: updated my system configuration flake inputs () run system rebuild () Thunderbird compiles successfully. Relevant lines from the build log: So it looks like the error has something to do with Wayland support. nixpkgs lock: nix-info:
Please, search before opening issues:


I believe that this prevents the use of other display managers -Don't force it?
if you enable a another dm you wouldn't get this error i submitted a pr so that this error does not happen when lightdm is disabled but a another dm isn't enabled


A frontend in GTK 4 and Libadwaita for Apx. GUI for tool for (both are already packaged in nixpkgs) Metadata homepage URL: source URL: license: GPL-3.0 platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Using the NixOS option to specify the configuration, I noticed that if an ampersand () is present, the password field of isn't generated correctly. the option along with the option. The environment file should contain . the field "password= the content of . The password is decrypted to . The password shuld be decrypted to . The global variable's name shouldn't show. Here are some nix code that is tested to trigger this issue instead. The environment file: Generated in the aforementioned path, note how the field is erroneous. A hack to get around this is to split your password in two halves, and put the & in plain text. . Of course I would still like to see this get fixed :p Thank you for maintaining this module and reading this issue ! Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It looks like a missed a metacharacter: I don't know if escaping it as works, or it interacts somehow with other systemd/shell/nix metacharacters. I lost counts of how many level of escaping we are in. I hope to get rid of all of this nonsense with , but next release of wpasupplicant is taking forever.
Done in The fix should be in NixOS 24.05.


Currently we build with support for . Sonnet typically looks in for dictionaries That means it won't be able to find any dictionaries and thus spellchecking won't work.
Is this still a problem? It seems that hunspell paths are not hardcoded in hunspelldict.h anymore: But they are still hardcoded in
Yes, this is still a problem. It seems like we should disable hunspell and use aspell, which is configured correctly in NixOS.
I marked this as stale due to inactivity. →
I marked this with "good first bug" because I think we need only to change to depend on , and do some testing.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


package lists and as dependencies but upstream uses instead. Steps to reproduce the behavior: dependencies of package it to the dependencies listed by upstream and should not be in the dependencies list, but should n/a <!-- 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]:
That's a bot.
Thank you for the quick turnaround!


Using AtLauncher to launch Minecraft 1.20.6 crashes immediately: <details<summarylog</summary[13/06/2024 11:48:21 AM] Checking for updated files! [13/06/2024 11:48:24 AM] Preparing for launch! [13/06/2024 11:48:24 AM] Launching pack Minecraft 1.20.6 (Vanilla) for Minecraft 1.20.6 [13/06/2024 11:48:24 AM] Logging into Minecraft! [13/06/2024 11:48:24 AM] Using Java runtime java-runtime-delta (Java 21.0.3) at path USERSDIR/runtimes/minecraft/java-runtime-delta/linux/java-runtime-delta [13/06/2024 11:48:24 AM] Launching Minecraft with the following arguments (user related stuff has been removed): [gamemoderun, USERSDIR/runtimes/minecraft/java-runtime-delta/linux/java-runtime-delta/bin/java, -Xmx4096M, -XX:MetaspaceSize=256M, -Duser.language=en, -Duser.country=US, -, -Dlog4j.configurationFile=USERSDIR/assets/logconfigs/client-, -XX:+UnlockExperimentalVMOptions, -XX:+UseG1GC, -XX:G1NewSizePercent=20, -XX:G1ReservePercent=20, -XX:MaxGCPauseMillis=50, -XX:G1HeapRegionSize=32M, -Xss1M, -, -, -, -, -, -Dminecraft.launcher.version=3.4.36.4, -cp, USERSDIR/libraries/com/github/oshi/oshi-core/6.4.10/oshi-core-, , --username, REDACTED, --version, 1.20.6, --gameDir, USERSDIR/instances/Minecraft1206, --assetsDir, USERSDIR/assets, --assetIndex, 16, --uuid, REDACTED, --accessToken, REDACTED, --userType, msa, --versionType, release, --width=854,


--height=480] [13/06/2024 11:48:27 AM] [Datafixer Bootstrap/INFO] 222 Datafixer optimizations took 173 milliseconds [13/06/2024 11:48:29 AM] [Render thread/INFO] Environment: Environment[, , name=PROD] [13/06/2024 11:48:29 AM] [Render thread/INFO] Setting user: MINECRAFTUSERNAME [13/06/2024 11:48:29 AM] [Render thread/INFO] Backend library: LWJGL version 3.3.3+5 [13/06/2024 11:48:29 AM] ---- Minecraft Crash Report ---- [13/06/2024 11:48:29 AM] // Don't be sad, have a hug! <3 [13/06/2024 11:48:29 AM] [13/06/2024 11:48:29 AM] Time: 2024-06-13 11:48:29 [13/06/2024 11:48:29 AM] Description: Initializing game [13/06/2024 11:48:29 AM] [13/06/2024 11:48:29 AM] Failed to initialize GLFW, errors: GLFW error during init: [0x1000E]Failed to detect any supported platform [13/06/2024 11:48:29 AM] at (SourceFile:78) [13/06/2024 11:48:29 AM] at (SourceFile:846) [13/06/2024 11:48:29 AM] at ffh.<init(SourceFile:509) [13/06/2024 11:48:29 AM] at (SourceFile:223) [13/06/2024 11:48:29 AM] [13/06/2024 11:48:29 AM] [13/06/2024 11:48:29 AM] A detailed walkthrough of the error,


its code path and all known details is as follows: [13/06/2024 11:48:29 AM]
[13/06/2024 11:48:29 AM] [13/06/2024 11:48:29 AM] -- Head -- [13/06/2024 11:48:29 AM] Thread: Render thread [13/06/2024 11:48:29 AM] Stacktrace: [13/06/2024 11:48:29 AM] at (SourceFile:78) [13/06/2024 11:48:29 AM] at (SourceFile:846) [13/06/2024 11:48:29 AM] at ffh.<init(SourceFile:509) [13/06/2024 11:48:29 AM] [13/06/2024 11:48:29 AM] -- Initialization -- [13/06/2024 11:48:29 AM] Details: [13/06/2024 11:48:29 AM] Modules: [13/06/2024 11:48:29 AM] Stacktrace: [13/06/2024 11:48:29 AM] at (SourceFile:223) [13/06/2024 11:48:29 AM] [13/06/2024 11:48:29 AM] -- System Details -- [13/06/2024 11:48:29 AM] Details: [13/06/2024 11:48:29 AM] Minecraft Version: 1.20.6 [13/06/2024 11:48:29 AM] Minecraft Version ID: 1.20.6 [13/06/2024 11:48:29 AM] Operating System: Linux (amd64) version 6.1.92 [13/06/2024 11:48:29 AM] Java Version: 21.0.3, Microsoft [13/06/2024 11:48:29 AM] Java VM Version: OpenJDK 64-Bit Server VM (mixed mode),


Microsoft [13/06/2024 11:48:29 AM] Memory: bytes (468 MiB) / bytes (704 MiB) up to bytes (4096 MiB) [13/06/2024 11:48:29 AM] CPUs: 16 [13/06/2024 11:48:29 AM] Processor Vendor: AuthenticAMD [13/06/2024 11:48:29 AM] Processor Name: AMD Ryzen 7 5800H with Radeon Graphics [13/06/2024 11:48:29 AM] Identifier: AuthenticAMD Family 25 Model 80 Stepping 0 [13/06/2024 11:48:29 AM] Microarchitecture: Zen 3 [13/06/2024 11:48:29 AM] Frequency (GHz): 4.46 [13/06/2024 11:48:29 AM] Number of physical packages: 1 [13/06/2024 11:48:29 AM] Number of physical CPUs: 8 [13/06/2024 11:48:29 AM] Number of logical CPUs: 16 [13/06/2024 11:48:29 AM] Graphics card name: unknown [13/06/2024 11:48:29 AM] Graphics card vendor: unknown [13/06/2024 11:48:29 AM] Graphics card VRAM (MB): 0.00 [13/06/2024 11:48:29 AM] Graphics card deviceId: unknown [13/06/2024 11:48:29 AM] Graphics card versionInfo: version: a1 [13/06/2024 11:48:29 AM] Graphics card name: amdgpudrmfb [13/06/2024 11:48:29 AM] Graphics card vendor: unknown [13/06/2024 11:48:29 AM] Graphics card VRAM (MB): 0.00 [13/06/2024 11:48:29 AM] Graphics card deviceId: unknown [13/06/2024 11:48:29 AM] Graphics card versionInfo: version: c5 [13/06/2024 11:48:29 AM] Virtual memory max (MB): .


45 [13/06/2024 11:48:29 AM] Virtual memory used (MB): 9594.43 [13/06/2024 11:48:29 AM] Swap memory total (MB): .00 [13/06/2024 11:48:29 AM] Swap memory used (MB): 0.00 [13/06/2024 11:48:29 AM] JVM Flags: 9 total; -Xmx4096M -XX:MetaspaceSize=256M -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=32M -Xss1M [13/06/2024 11:48:29 AM] Launched Version: 1.20.6 [13/06/2024 11:48:29 AM] Launcher name: ATLauncher [13/06/2024 11:48:29 AM] Backend library: LWJGL version 3.3.3+5 [13/06/2024 11:48:29 AM] Backend API: Unknown [13/06/2024 11:48:29 AM] Window size: <not initialized[13/06/2024 11:48:29 AM] GL Caps: Using framebuffer using OpenGL 3.2 [13/06/2024 11:48:29 AM] GL debug messages: <disabled[13/06/2024 11:48:29 AM] Using VBOs: Yes [13/06/2024 11:48:29 AM] Is Modded: Probably not. Client jar signature and brand is untouched [13/06/2024 11:48:29 AM] Universe: 404 [13/06/2024 11:48:29 AM] Type: Client () [13/06/2024 11:48:29 AM] Locale: enUS [13/06/2024 11:48:29 AM] CPU: <unknown[13/06/2024 11:48:29 AM] # Game crashed!


Crash report saved to: # USERSDIR/instances/Minecraft1206/crash-reports/crash-2024-06-1311.48.29- [13/06/2024 11:48:29 AM] Oh no. Minecraft crashed. Please check the logs for any errors and provide these logs when asking for support. </detailsSteps to reproduce the behavior: (from nixos-24.05 channel) by adding it to user packages in and then nixos-rebuild. AtLauncher. In "Create Pack", select 1.20.6 in the version list, and click "Create Instance". it successfully created the instance, in "Instances", click "Play" under the instance just created. crushes without showing any game interface. The log above appears. Launches the game as expected. Using proprietary NVIDIA driver on X11. OpenGL is enabled in <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
That's weird. I'm not able to reproduce this issue with the same configuration you've mentioned: ATLauncher version Minecraft version Proprietary NVIDIA drivers on X11 As an initial debug attempt, could you run and see if that fixes your issue? If it does, then there's some missing library and I can try to find what that is.
Yes, it runs fine with steam-run.
Great, at least we have a temporary solution until I can fix this issue. Thanks for reporting this! I'll get to it as soon as I can.
I suspect that the latest upstream version may fix this issue. Could you please confirm this by trying out that version?
Not fixed. Neither 3.4.36.6 nor 3.4.36.8 fixes the issue. I also tried 3.4.36.9, but it's not good either. Launching with is still fine.
All right, so it's definitely something missing in the Nix expression. Will look into it.


I narrowed down the issue to the lib not being able to dynamically load. I it to while having nix-ld enabled as a workaround for myself. Additionally my mouse is always visible in front of the crosshair unless I also add . I have no idea if this issue exists under wayland.
Thanks for helping debug this, The package for ATLauncher has a function parameter called , could you try putting the libraries you mentioned within that? The syntax would look something like: I would try this myself but I can't reproduce the error. ATLauncher wouldn't run under Wayland at all (without ) as with all GUI apps built with Java.
Yep, that works perfectly.
could you please confirm that the above fix works for you as well? Meanwhile, I'll open a PR to fix this in the package itself.
It works.


This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
Hi Already opened a PR for that ().


To prevent issues like , meson setup hook should define install directories just like stdenv and cmake do Unfortunately, simple patch like the following will not work Meson does not like it very much when the directories are not descendants of prefix See also


Project description Alternate Discord and Fosscord client made to be private, secure, customizable, and Linux friendly. Metadata homepage URL: source URL: license: MIT platforms: x86_64 and aarch64 on linux, darwin, windows
I had a shot at trying to package this from source, but it seems that for whatever reason, the nixpkgs' Electron crashes with SIGTRAP when trying to run with source. I haven't had much luck using on Electron to find a root cause either. Haven't tried using the AppImage yet, though.
I don't think the appimage will have much difference, but I've also gotten the same error. There is now a that uses dream2nix to package it properly
I made a derivation that doesn't use dream2nix, and it's available at if it's of any use. The SIGTRAP issue was just a bad Electron version, from what I could tell. I haven't submitted this to nixpkgs yet purely because I want merged first.
Ah it would make sense for the SIGTRAP to be an electron version issue, I've had it on a few other electron apps too. Your derivation looks pretty good, might try it out. Wonder how long it will take the pr you mentioned to be finished tho
The PR has been marked as a blocker for 22.11, so at the very latest, end of November. May be an excessive amount of time to wait, though.
Now that is mostly done and merged, I've used it to make a nice and simple derivation for it:
Looks great. Not sure if you're planning on submitting this to nixpkgs, but if you are it might be worth adding arm64 support as well.
Yeah it would be nice to get this to work on aarch64 and/or darwin too, but I don’t have any devices to test it on. Can you help with this? The package might already even work on arm since we're just wrapping nixpkgs electron. I’m also down to put this on nixpkgs, might wanna do a bit more testing and tweaking; if you can see any places for improvement that'd be great!
is there anything that would stop this package from running on i686?


Steps to reproduce the behavior: also yields the "got" hash. The hash was last changed in nixpkgs @
we just hit the same issue in Alpine - it looks like the upstream uses format specifiers for that change depending on the state of the repo: (found by [here][1]) in your case it might help to do instead ( provided that doesn't just do on the remote URL, but fetches the repo in some other way ): [1]:
thanks for the new upstream issue and the infos!


Steps to reproduce the behavior: pyside6 Please run and paste the result. :sweat_smile: I guess it says not found because i have no channels (i use flakes)
This same failure is causing syncplay to fail to install on my system.
yeah thats how i knew lol
To confirm, I can reproduce this issue.
I'm trying to package something which relies on pyside6. Package builds fine on nixos-stable but fails under nixos-unstable due to pyside6 not building.


Package name: picom-next Latest released version: regrettably, v10.2 (released December 2022) is still the latest upstream release <!-- Search your package here: --- Current version on the unstable channel: unstable-2023-01-29 Current version on the stable/release channel: unstable-2023-01-29 <!-- 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! --- There's at least one bugfix since the start of the year that would be nice to have: 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.
Can you help reviewing it?
Apologies for not testing this for you, I couldn't immediately work out how to do so. I've now opened to hopefully make it a little easier next time.


Octoprint can't build on unstable due to a conflict of the required version for . octoprint , while the dependency requires (due to ) . Octoprint builds successfully I ran a between and (known good) , the first bad commit was I suspect that it's necessary to pin the additional dependencies (and maybe some more), too, but I'm not that experienced with packaging python packages. made the first bad commit Octoprint maintainers: system: host os: multi-user?: sandbox: version: channels(root): channels(richard): nixpkgs: Maintainer information:


Geary and are . I suppose updating might remove its dependency on the insecure . (I think i remember having seen somewhere in an issue tracker that this dependency was removed in Geary source code, but i cannot find now where i saw it.)
By the way, I do not really understand these GTK and WebKitGTK issues and versions, but, just for reference, there is an open issue about previous versions of Geary using GTK2 instead of GTK3: .
In Geary 0.12 there are some fresh bugs (for example, ). It looks like version 0.12.1 is in the beginning of November.
Running shows gtk2 as a transitive dependency from webkitgtk (which depends on both GTK 2 and GTK 3) and gnome-themes-standard. I do not think the latter is necessary for GTK 3 applications since Adwaita is built into GTK 3.


cliphist wayland clipboard manager Metadata homepage URL: source URL: license: gplv3+ platforms: linux


Describe the bug fails to compile with Additional context See for a possible cause. Notify maintainers cc (sorry for notifying you here and in the PR!)
Gonna try to just switch it to . We should probably update gnome docs for Rust+Gnome packages
Yeah, I think that would be best. The idea of the hooks is that is not necessary anymore in mixed projects. I will also do a PR for cargoBuildHook, since it should not be used when is set explicitly.


Describe the bug neovim fails to build with missing , similar to , on . To Reproduce Steps to reproduce the behavior: to from master () Expected behavior The package should successfully build. Metadata On master () Maintainer information:
via in
so you could do until a proper fix.
Reverting the luarocks bump doesn't work for me. That fix is also very surprising to me, since neovim broke (for me) after the latest nixos-unstable channel update.
Interesting. It worked fine for me. Running the above revert command and then (inside my local nixpkgs with it reverted) let me build neovim properly. I don't think it's particularly surprising if updating a channel that happens to include the luarocks bump causes it to break, unless I'm misunderstanding you.
I updated from a channel where the luarocks bump had already happened, and neovim worked on that channel. In fact, I reverted to the previous hydra evaluation to make my system evaluate again.
This was actually before and it was working without problems and then suddenly the problem appeared again. I can also report that I cam getting this in the same way described (updated latest nixos-unstable channel and then neovim stopped building again).
I confirm this fixed by on master (channels may take a while). For now I'll assume that charvp's failure to resolve the issue with that revert was some kind of mistake; we can re-open otherwise, perhaps separately if it's a different kind of error.
Does anyone know why updating the luarocks dependency is so brittle? Is it possible to at least add a test so we don't regress again in the future?
the tool exists (nixpkgs-review) but it takes CPU and disk space to run plus some reviewer time (and was not run in this case). Also for this specific case, the luarocks update broke in subtle ways the build so I wouldn't call it . It is called unstable for a reason. The good thing about nixpkgs is you can pin neovim to an older version while keeping your system on unstable.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Are we sure this is fixed on Darwin? still shows failing with logs of: Or is this a different issue?


I think the root problem here is that luarocks has a poor implementation of "move". Combined with the build's behavior being affected by filesystem ordering the result is essentially random. The [implementation of move][] calls out to the operating system commands [][] and [][]. Building with will contain a sequence of , and . I've extracted the [relevant part of the log][]. The critical aspect here is that by default, unix will dereference symlinks and copy their contents. [implementation of move]: []: []: [relevant part of the log]: My theory: luarocks scans the directory for external libraries in filesystem order and attempts to move all shared libraries from to . At which point one of 3! things will happen, but the two main ones are: is copied and deleted and , now broken symlinks, fail to copy and are copied by dereferencing, and deleted is copied and deleted Either way is wrong to some degree, but one of them happens to work well enough for downstream packages to build. If I build locally, the filesystem order I get seems to work, so we can inspect the two results: I've been focusing on this for darwin since the failure case happens to be cached, but I believe it applies equally to linux.
is that sthg you have already witnessed ?
What LuaRocks version is this happening with? I have pushed fixes related to the file deployment stage in 3.3.1.
I've tested 3.2.1 (current nixpkgs master) and 3.3.1 (hasty upgrade locally), they both have similar results, except on 3.3.1 the errors now propagate correctly. I've uploaded a [log of a failed build][] with 3.3.1. [log of a failed build]:
I was hoping to find time to write a proper issue report and a test lua package for this, but haven't yet. My test case would have a directory structure made with , that looks like: In order to succeed the deployment stage would have to produce both the file and its symlink.