Cockpit is a server manager that makes it easy to administer your GNU/Linux servers via a web browser. Website: http://cockpit- Upstream: License: LGPL2.1 Arch Linux package: !
Could be a lot of effort to port: ... I have not looked at the code how many assumption it makes about the system, but in terms of system configuration nixos is a special snow flake.
Probably only a subset will work. But I think there is some stuff in cockpit that is helpful even on NixOS: View journald logs and systemd services Manage virtual machines via libvirt Get a shell terminal from the Web UI Some general system information like disk usage etc. It's mostly read only stuff but I'm not sure how easy it is to only use parts of cockpit that would work.
+1, would love to have this
Given that NixOS is pitched as a server os first, this would be very helpful. I already tried to but got stuck because it requires a few npm packages
try with
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
I still think it would be good to have this in NixOS.
Well as pointed out, there will be quite a lot of patching up paths to do, as well as the NPM packages that need installing (try yarn2nix or npm2nix for that) Seeing as it's non-trivial, it will have to be packaged by someone with real interest in getting it, and we can assist (make a draft PR and tag us on questions)
node is only required for the dev environment I have made packaging cockpit, it still fails to compile tho Any help would be greatly appreciated
building build flags: SHELL=/nix/store/5hplxs3kprdp6v62qk3di6a1m1s1paiq-bash-4.4-p23/bin/bash GEN src/ws/mock-dbus-tests.h Traceback (most recent call last): File "/nix/store/5zajbm8674d93nix4h8b0hxgglj2pbir-glib-2.64.3-dev/bin/gdbus-codegen", line 53, in <modulefrom codegen import codegenmain File "/nix/store/5zajbm8674d93nix4h8b0hxgglj2pbir-glib-2.64.3-dev/share/glib-", line 24, in <moduleimport argparse File "/nix/store/jli50q24fvik6pfsnjs1jd90g3dy4p6y-python3-", line 88, in <moduleimport re as _re File "/nix/store/jli50q24fvik6pfsnjs1jd90g3dy4p6y-python3-", line 145, in <moduleclass RegexFlag(enum.IntFlag): AttributeError: module 'enum' has no attribute 'IntFlag' make: * [Makefile:: src/ws/mock-dbus-tests.h] Error 1 error: --- Error
----------- nix-build error: --- Error --- nix-daemon builder for '/nix/store/mdiihwskfp862y17wp70skdy74kh33v5-cockpit-' failed with exit code 2; last 10 log lines: File "/nix/store/5zajbm8674d93nix4h8b0hxgglj2pbir-glib-2.64.3-dev/bin/gdbus-codegen", line 53, in <modulefrom codegen import codegenmain File "/nix/store/5zajbm8674d93nix4h8b0hxgglj2pbir-glib-2.64.3-dev/share/glib-", line 24, in <moduleimport argparse File "/nix/store/jli50q24fvik6pfsnjs1jd90g3dy4p6y-python3-", line 88, in <moduleimport re as _re File "/nix/store/jli50q24fvik6pfsnjs1jd90g3dy4p6y-python3-", line 145, in <moduleclass RegexFlag(enum.IntFlag): AttributeError: module 'enum' has no attribute 'IntFlag' make: * [Makefile:: src/ws/mock-dbus-tests.h] Error 1 Seems like an error in the package itself.
The enum thing is due to a stray enum34 dependency in - enum34 is a backport of the enum module, and breaks things if it's installed on Python = 3.4. You'll need to look at why pyscss is pulling in enum34 - it's not immediately obvious to me from pyscss's , it looks correct. A pthread link error happens if that's fixed or if Python is removed from the deps entirely. That pthread link error is, I believe, a problem with the Cockpit makefiles; I made to fix it. With that change applied, I get I don't know anything about the Javascript packaging, so no idea how to progress from here. Good luck!
It compiles but gets stuck writing it's systemd.service files. I don't have much experience packaging applications which hook into systemd
How’s the effort? :crossedfingers: :crossedfingers: :crossed_fingers:
If this gonna work I could start replacing my with
I have updated nix to solve the issue of beside updating the version and it built successfully
I built the derivation posted by by including in my . It built successfully, producing . The output includes many things for like systemd units that do not get installed on the system - I'm wondering if these should be symlinked in as-is, or do they need to be converted to Nix? Most systemd units look OK but will need a fix to replace a reference to :
If is changed to (in patch below), and is to , the units get installed but are not enabled. The package also has references to and , please let me know if you know how best to patch these: I patched the reference to , and replaced with just due to build warning. Here's what I have, building entirely on what others have contributed to this thread:
I considered running the docker container, but it requires and proceeds to modify the host's PAM config. Not something I personally like to see in a docker container... Back to the Nixpkgs. I was able to use so that has references to coreutils programs and patched the certificate paths to be . was because of patches to . Right now it fails running with SIGSEGV. I thought it might be systemd's setting, but it does the same outside invocation by systemd. I tried building newer versions of cockpit, but I kept running into There are some notes that might be helpful. Here's the latest packaging attempt: Even though I've posted like 4 times in a row, I think I'm done trying to do this. I hope someone else can pick up the effort.
I was able to get past this by changing the interpreter in from to . Note that, for some reason, doesn't work. You also have to run , because Nix resets its date and that breaks the "is packages- newer than " check. I also had to replace with in . What's odd is that all of the scripts run correctly when run from . When this is done, will just error with "Cannot find module stdio".
Spent some time learning nix by giving this a shot and actually ended up getting things to start. A lot of things are not working, but some might be possible to fix. For anyone interested I have left things here:
Another take on it Tested features: Logs Virtual Machines (cockpit-machines module, only managing works, creation of new VMs doesn't work) Services Terminal Code:
Tried to create a virtual machine, no luck, OS list is empty. Cannot create VM without choosing the operating system. I tried to fix it but I got the following error: !
I came across this discussion in the upstream project and figured it might be helpful to cross-reference:
You require libosinfo, and osinfo-db
I would to keep working on this issue, any hints you got for me would be welcomed. I do see any errors in my log
I am also working on this Here is what I have so far: It's building only. I was able to solve some documentation build bugs.
:eyes: !


Currently, the retpoline mitigation is only available in gcc7 . However, it still exists some old kernels that only compile with , such as those in Ubuntu Trusty LTS (kernel 3.13). Moreover, kernel modules loaded on these kernel have also to be compiled with the retpoline mitigation. Ubuntu (and Debian) integrated retpoline mitigation in their releases . Latest Ubuntu 3.13 kernel now requires kernel modules compiled with retpoline mitigation. They can no longer be built with Nix gcc toolchain. What do you think about backporting these patches? Someone could help on this?
sounds good to me.


When saving a plot figure to pdf in Octave, the program panics and aborts Reproducible with both and from . If the GUI is used, the program exits with signal 6.
Does suffer from the same problem?
Yes, same problem with .
Requires in , which we have not packaged yet.
this should be reopened, octave lacks in so the issue still stands. I think should be included in both and . Mainly so command line users can still save graphs to a file. I can make the necessary changes eventually or if someone else wants to that would be nice.
Oops sorry


The MTU of the ethernet should be set to 1460 on google cloud platform, but it is set to 1500. For me this has occasionally, but not always caused the ssh terminal to hang when lots of data is being printed, and I assume could be causing other people issues. from - Create a google compute engine nixos image from observe the mtu on eth0 is 1500. Set the following: to fix the issue. system: host os: multi-user?: sandbox: version: nixpkgs:
I created based on what you wrote but didn't test it.
Thanks, that fix was enough for me, though I don't know if it works in all situations, or if DHCP is not picking up some parameter like it is supposed to. I don't really know how to proceed with a fix for sure, but I thought I would document the issue.


Darling is a compatibility layer for running macOS apps on Linux (think Wine for macOS). I think it would be interesting to work on with macOS support. They have reverse engineered some headers that Apple doesn't release publicly so having them in "libdarling" could be useful.
We already have this part:
Just heard of Darling. I would be delighted if it could be used for running builds on NixOS!
It seem to be packaged by but only for macOS. If i understand the project correctly, that makes no sense. We want it on linux, to run macOS apps. Also, the package has no version. That's probably because they havn't tagged a version yet. So this is pre-alpha state software. could you update the package to the commit the "stable" AUR package uses and add a version as described here: ? Then we can close this issue.
It looks like the project has started using tagged versions:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
I'd still be very interested in seeing this , especially with the hope of future cross-compilation support
This would even make it possible to package Mac binaries for Linux!
I'm interested in this so that I can test cross compiled binaries when running tests.
I marked this as stale due to inactivity. →
Not stale!!
darling-dmg is just part of . To be exact, it is included as a submodule in the source tree of darling. The darling build will come with kernel modules. It would need someone with kernel-packaging experience to pack it into Nixpkgs. Build instructions in the Darling Docs:
I marked this as stale due to inactivity. →
I'd still like to see this, though largely for much the same reason Andrew mentions at this point -- I've started working with zig and being able to test cross-compiled macos binaries would be brilliant.
I have got most of a Darling build file running, but I have found an interesting issue. Wever I build I get the following error: From this cmake file: As far as I can tell, the command is a special MacOS thing, and I unfortunately do not understand CMake well enough to fix it...
Well, turns out the issue is that Darling relies on git-submodules, and it looks like this must be built against the Git repo directly, not against the released tarball...
What would therefore be a derivation?
What do you mean It's just a with .
I tried to re-package the prebuilt deb from darling GitHub releases. Here is the nix code darling- Save these 2 snippets as and darling-, then run . With 2 problems: needs setuid/setgid perms, while nix-build would fail if dpkg-deb -x executed directly. I use fakeroot to ignore this problem. always fails. I am not a darling expert, have no idea.
Ah, fantastic, thanks! Looking forward to having this in nixpkgs anyway, but let's see how we go there.
It could be named when entering Nixpkgs.
Good suggestion. I've edited those two scripts.
I got as far as finding out that darlingserver doesn't start with that script because it expects /usr/bin, so updating my to a version, the next issue was that darlingserver was trying to mount overlayfs on "lowerdir=/usr/libexec/darling,up" (may be incomplete, this is strace output) which did not exist.
After a bit of tinkering I got Darling to build from source. I opened with more info. Please give it a try!
It seems that they now use instead of the kernel module. This would make packaging easier.
What's the purpose of ? If it is only the sandbox part of Darling, a new name like would bring less confusion. Update: Opened PR to do the renaming.


The bullet points under Chapter 2, section 8 (the fdisk process) don't match up with what the real partitions are after write. The last four lines of fdisk setup are relevant: Earlier in the fdisk process, we create the partitions with the following numbering: I believe the re-numbers the partitions based on their location within the partition label. Since the boot partition is at the front of the disk and our partition is at the end, fdisk reorders the partitions as follows: The problem is when making the file systems. The manual still uses the initial partition numbers instead of the new, ordered numbers. Thus: Creates an ext4 partition that is 512M big and is supposed to be boot. And: Creates a FAT32 partiton that's supposed to be our root labeled . Swap isn't affected being in the middle.
Hi! Closing this issue since the partitioning instructions are now re-written for 18.09. (See ) As far as the ordering of partitions is concerned, the newly re-written partitioning instructions were written to ensure it wouldn't be an issue.


has been broken on master for a while now, blocking orca. I opened an but they are not sure how to fix it.
I removed it from orca in


Tried to make a system upgrade, got this: Obviously, upgrade can't be completed. have in . run Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
This looks like the offending line: This could be related to what file system you are using?
Actually this looks like unrelated to glslang. Works on master:


does not build after "boto{3,core}: {1.6.0,1.9.3} -{1.7.9,1.10.9}" by system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Whoops, sorry about that! I keep forgetting they're all linked


Open a gnome-terminal and go to any directory other than $HOME. Right-click in the terminal and click "New Terminal" A new terminal opens, but the current directory is $HOME. This has probably always been like this in NixOS. On traditionally systems is sourced which exposes the shell $PWD to the terminal. In NixOS that file lies "dormant" in the store: Users can workaround this by manually sourcing the file: (probably best to pick the one in gnome-terminal's clousure) system: host os: multi-user?: sandbox: version: channels(ole): channels(root): nixpkgs: Gnome installed by
Is that supposed to be done for new windows? It works for me with new tabs, I think.
It does after sourcing the file so I assume it's intended. I'll check on an other system when I get the chance. I get the same behavior with new tabs (does not preserve $PWD when is not sourced) Can you check the content of (bash) or (zsh)?
I use fish-shell and the pwd just seems to be preserved.
Seems fish notifies various terminals . More context:
Would something like the following work? This global solution is not very nice but I am not sure how to address it correctly.
The alternative might be to add something like the linked fish config to : The script checks if the shell isn't bash or zsh, so it should be safe to do so. Did a quick test in a VM and it seems to do the trick.
For some reason the above snippet doesn't "initialize" for me. I have to manually run . Weird. I even some manual trace and see that is sourced. But still it doesn't work. I'm using bash, but perhaps I have some untracked stuff in .bashrc that is interfering? I'm currently unable to debug using the NixOS VM. stops in stage-1 at "mke2fs 1.44.1 (24-Mar-2018)". EDIT: typo
hmm, weird, I'm specifically running this diff on unstable: I'm able to launch bash (from zsh) and the directory successfully updates when creating new terminals, though I can't quite remember if I tested things out with bash in a VM. edit: managed to do ctrl-return
Thanks to I am now able to use "nixos-rebuild build-vm" again (on NixOS 18.03). I can confirm the above patch () fixes it. (I guess why it doesn't work on my physical laptop is due to some imperative changes in my $HOME.) Would you like to make a PR?
This seems to strangely only work in bash, has anyone gotten this to work with ZSH? I suppose I could source the file manually though I'm not sure which path the ${} refers to?
I have this patch in my tree which works for ZSH: Edit: I see I posted this exact diff above :laughing: Kinda forgot about this, should really subit a PR.
I've that bit into my config and have done a rebuild, but don't get the desired behavior. Where does the actually output to (which file) - would this not be needed in my .zshrc?
It should show up in . The exact patch I posted relies on btw. You could also include it straight in your configuration if you're not using gnome.
Many thanks - I'm a bit cautious to try that line as I've previously had various issues with fonts / themes / icons. I've found a direct copy of from my old Arch installation and just sourcing that manually for now -works perfectly! In the event it's useful to someone:
Sorry, guess I wasn't clear. I meant including in your , that way it isn't hidden behind the flag.
I'm struggling to find a way to represent that configuration snippet as a nixos option that can be generalized to just mean or support for vte terminals. For example it could be but vte isn't a program.
Since the VTE lib comes from , what about something like ? In the same way we have . also have a bunch of shell configuration (, , , ...), so it could make sens.
Yay, great suggestion I can do that :+1:
My old solution posted no longer seems to work after upgrading to nixos 20.09. I can't seem to find the actual solution to this, any pointers?
What was your old solution? If you enable gnome-terminal you will have the vte module enabled. If not enable them manually
I've got: However I still seem to run into the same issue, after running . As for the old solution - that was sourcing the file I had from arch linux. I also tried: And sourcing that file with - that still does not seem to work.
I managed to fix this by setting to instead of . No idea if this setting perhaps got reset somehow - but it worked previously. :)


nixpkgs rev
I wonder if this is another case of the socket path being too long...
Tests appear to work iff sandboxing is disabled.
Same issue reproduced locally on
If the hydra build failed, how did this get released to the 18.03 stable channel?
It is not a release blocking build. Here are the constituents: I'm more curious how it ever worked. I can't really imagine that it hasn't changed since the sandbox was enabled on Hydra.
I tried some older revisions and it really looks like DBD-Pg tests never worked in a sandbox. The package was last updated 2015. Bumping to current DBD-Pg 3.7.4 doesn't help either - it first results in an error about the socket path being too long, and after patching that the tests freeze at the same point as with 3.5.3. So let's stick to 3.5.3 and just set .
Sounds good to me, will you or shall I?
I'm working on it.


pxelinux (from syslinux) is compiled without support for UEFI PXE boot: I had a quick look at getting it to compile uefi support but I didn't get very far. system: host os: multi-user?: sandbox: version: channels(root): channels(peter): nixpkgs:
Does the NixOS netboot image support UEFI boot? I did try netbooting NixOS (18.03) a few weeks ago with a pre-compiled iPXE UEFI loader. It started booting the kernel but failed to mount the initrd (kernel panic no root).
The image is using pxelinux.0 instead of lpxelinux.0 it seems and you need lpxelinux for HTTP support so maybe that's what is going on.
The http support seemed to worked just fine in my case. I did serve the iPXE UEFI loader via tftp, the kernel image and the initrd via http (initrd is too big to load trouble-free via tftp). The iPXE loader pulled bzImage and initrd via http and began booting the kernel. The kernel then failed to mount the ramdisk for some reason I do not understand. I solved the problem by setting 'Legacy mode' in the firmware (Supermicro) and booting everything in classical BIOS/PXE mode (no UEFI components involved). I can try to reproduce the problem and send you some screenshots if that helps. My vague guess is that the NixOS netboot image needs some modifications to be UEFI capable. I just wanted to raise awareness that there are potential problems with UEFI-PXE down the road.
IIRC, specifying on the kernel command line is required with EFI booting for some reason (edit: when booting with iPXE, that is).
would fix this.


When using with and the build fails when trying to write to a in the It works fine if the list of packages is empty or only contains packages that are normally in the environment. Oddly enough, if you run in the it does not produce an error, but it also does not actually include the package, No idea if this is related to system: "x86_64-darwin" host os: Darwin Kernel Version 16.7.0, Sierra multi-user?: no version: nix-env (Nix) 1.11.4 nixpkgs: nixpkgs-channels, commit
I believe the root cause of this problem is that the libraries like , etc are being installed in but the extra packages by are being installed in and the is only looking in one of those locations. I have a work-around hack which I will post when I get a chance.
Can you confirm that fixes this for you?


This should be . A similar issue happens for 7.59.
Ha! Yes! Currently this happens: Will submit a PR for this shortly, thanks!


After got merged, and is in the nixos-unstable channel, I noticed after I rebuilt my system that when sddm starts and I type in my password it just goes black and restarts sddm. Meaning that I can never reach the desktop :( I could also not find anything useful in the journal. cc
In a VT, try this as root:
Ahh that makes perfect sense and worked :hand: Is there any real way to make sure this doesn't happen for someone else?
There was a PR some time ago that was supposed to address this (it was merged) that would simply clear out the directory on start but it looks like that didn't do the trick. I don't remember which. IMHO, the proper way to handle this is something like this:
I also often have this problem.. could you open a pull request that removes the old solution and that adds your solution?
The commit was - I'll PR this.


Passing to a Haskell package has no effect, the resulting binary is . CC
I have checked that at the time runs, shows as but shows as .
The solution seems to be to pass  in when is given.
PR with the fix at


I expect all of these to not return "No such file or directory" and I expect the "bad interpreter" to be patched. I think it still "works", but compilation output should be clean such that when debugging something in the future there is not first a mess of other warnings to go through. Multiple issues: system: host os: multi-user?: sandbox: version: nixpkgs:
cc maintainers
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 .
The build currently complains that is missing: This program comes from ; I believe needs in .
I marked this as stale due to inactivity. →
As above, I think this is just a matter of adding the right .
I marked this as stale due to inactivity. →


seem the Keras preprocessing routines were split off into their own package in 2.0. The Nix version was then updated to 2.0 in commit without verifying that it worked. This broke the package as it is now necessary to also package the new package and provide it as a dependency to
We do semi-automatic batch upgrades to the Python packages because not all of them are well maintained. This also means we cannot fix all breakage that occurs during these batch upgrades, however we try to fix as much as possible. If you have the time, please package the new dependency and make a pull request.
Thanks for taking care of that.


Commit introduced type specification for (which was absent before), but this specification is wrong. From within release-18.03, import the tomcat module from the master branch, and create a minimal Tomcat configuration that uses : And see it fails: When using the native module from release-18.03, everything works. system: host os: multi-user?: sandbox: version: channels(paul): channels(root): nixpkgs:
It's only semi-related, but why on earth is the type of a list of packages, and not just a list of paths or strings?? It severely limits the configuration options for no apparent gain.
For the record, was an issue about overly restrictive type of .


Not sure if I'm doing something wrong, but while returns all ghc822 packages, throws an error: Do I need to somehow feed ghc-compact into this? My info:
gets the listing of packages going again, but the package depending on still don't build, as they have a constrain and ghc 8.0.2 has base 4.9.*


Shotcut in theory supports LADSPA plugins. However, LADSPA plugins are not found by Shotcut on NixOS version Install a bunch of LADSPA plugins (by listing them in ) Open Shotcut Add effects to a track Look for audio effects: no LADSPA plugins are shown Please run and paste the results.
cc maintainers
I tried to build shotcut and mlt with ladspa-sdk and set LADSPA_PATH, but did not manage to get the ladspa plugins working yet. ,-(
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 .
found out why: configure is using , which is not available, and therefore does disable ladspa. Preparing a PR.


when trying to build vim with configuration from it fails with: 'gdk/gdkx.h' file not found This issue just started to happen 5 days ago when I updated my nix to 2.1.2, before that it did build this derivation. On Darwin: Try to run in nix repl: system: host os: multi-user?: sandbox: version: channels(oren): nixpkgs:
So this only seems to affect the configurable vim, not the regular one? That would suggest that there's a simple compatibility fix that someone made to the main derivation that wasn't applied to configurable. I can't look at it right now but anyone in know what's up with this header?
Did you override guiSupport or set ?
my call to configurablenixpath as gui = "auto", if this what you mean.
Yeah that's the problem, gtk is included conditionally depending on what version is requested.
Running without it(leaving the default value for the GUI) is still causing the error.
I'm still having this issue - did you get it working in the end? Would you mind sharing how..?
I had my vim pkgs set pinned to 1803 and it worked. today I was trying to update the latest nixpkgs to build vim with and I still get this error.
In Darwin(MacOS 10.15) I was not able to compile a vim from vim/configurable but for what I was looking for (compile it with python and Lua support) I was able to compile from this is what worked for me:
Worked around this by disabling the GUI, works well if you don't need it:


If account-daemon restarts in a gnome3 session it totally breaks and becomes unusable. What happens for me if account-daemon restarts is that I see the screen flash like the login animation from gdm. All programs are still up. But the mouse is frozen and I can't even switch to a tty with my keyboard. The only thing that it actually responds to seems to be Ctrl+Alt+Delete which triggers a reboot. And this indicates that I'm actually in a tty but I see an image of my gnome-session. This is a problem when doing nixos-rebuild switch etc. I had a proposed fix in but dropped my branch because I was unsure if that fixed the issue, but I'm having that overriden in my personal config here: And it's much better while doing or or so than it was before. This can be tested by just doing a . system: host os: multi-user?: sandbox: version: channels(etu): channels(root): nixpkgs: cc
This is also breaking my ui whenever I try activate a configuration. Stack trace of , with and compiled with . Stack trace of from a coredump, with regular libraries:
Filed bug upstream:
For those looking to work around this, it should be sufficient to remove any config. (Untested).
This still an issue
oh, sorry. I've forgotten about this issue and stopped running gnome like 8 months ago. So I have no idea :D
I'm able to confirm that when using in GDM that restarting the accounts-daemon does crash the session. And isn't a sufficient workaround.
I'm seeing a very similar stack trace from in my user session after a -triggered . I'm not using GDM auto-login. I don't have debug symbols but here's the stack trace from . Note that the top of the stack is still in in libaccountsservice. When I went looking at the source for these functions, the only thing which made sense was that returned , which led me to the upstream bug and then to here.
Had the exact same issue today. my backtrace is identical to that of
This needs an upstream fix as reported in This is very confirmed.
I've been testing the workaround on one laptop and not on another. On the laptop without the workaround, upgrading from to caused to crash. On the laptop with the workaround, upgrading to that version from an older version () did not lead to a crash. why did you say this is not a sufficient workaround? It's kind of a pain to test so I can easily believe I'm missing something. Is it important to restart on upgrade? I assume no other distro has reported this bug or there'd hopefully be more activity in the upstream bug report. Are other distros just not restarting it on upgrade for some reason, maybe? Perhaps it's that… because NixOS treats as changed if any of its transitive dependencies change, we upgrade+restart it a lot more frequently than anybody else does? Maybe nobody else is noticing because changes rarely and other distros aren't triggering the crash often enough to annoy people into investigating?
I'm also seeing this crash and UI hang during . I am not using at all (I'm using ). I'm able to recover the hung session if I can get to a terminal by running . I left a note in with log output.
Still happens on NixOS 20.03 because the fix was never ported. Here is my backtrace from gdm, which seems to be exactly the same as reported earlier in this thread.


Run , observe: Please run and paste the results.
Very weird... It must have come in from a recent update. You can find libLLDB in the lldb derivation:
/cc


On running I get: Add to and run. system: host os: multi-user?: sandbox: version: channels(lev): channels(root): nixpkgs:
Well, the output has at least changed a bit:
my pull request fixes the . It broke down because the package had moved to but requires . But according to the browser is discontinued and `firefox-esr-5.2' is marked as unsecure so I would rather advocate for removing this package altogether.


Whenever I try to install both and I get a collision error because both derivations contain : Do files need to be in the packages? The same problem can be reproduced by building a environment where both and are in:
I have the same problem between and .


Commit from updated the default version of the GNU Privacy Guard a.k.a. GPG to version 2.1. Unfortunately, this update broke the gpg-related tests of , , apparently because there is some subtle change in the behavior of the GPG 1.x compatibility layer (git-annex relies on rather than using gpg2 directly). To remedy that issue, I fixed to use version 2.0 in . This is no good solution, unfortunately, because now people who rely on `gnupg1' end up having a version of GnuPG 2.0 in their profile that cannot talk to the gpg-agent from version 2.1, which happens to be the one that's installed in the system by default. In it's current state, gpg1 does not work reliably in NIxOS. To work around this issue, I would suggest that we revert to version 2.0 until we've had time to figure out what exactly has changed between versions 2.1 and 2.0 and why this affects .
FYI: Another thing I came across, due to a broken clawsmail pgp, was that the handling of gpg-agent differs from version 2.0 . GnuPG 2.1 do not use GPGAGENTINFO anymore. Instead it search for the gpg-agent socket in
For now at least, setting GPGAGENTINFO to $ seems to make claws-mail work.


repstopdf does not seem to be included anywhere in texlive or ghostscript. This means that texlive can't include .eps figures in pdf output.
Thanks!


dvc () is version control system for "biggish" data and code It integrates with Git but offers a solution for managing and versioning big data sets that come with code commits. Related technology () are like git annex and git lfs. If nobody gets around to this, I may work on this later.
Need to first package the Python dependencies nanotime, grandalf and asciimatics dependencies.
The extra dependencies: These will need to be packaged as optional dependencies and provided as a separate alias. Something like and or something like that. What are some good suggestions for names? The and don't appear to be packaged.
Google cloud storage is packaged already here: However is still not packaged as is though. The pypi is:
Initial PR for azure-storage:
Inital PR for nanotime:
Initial PR for grandalf:
Initial PR for asciimatics:
For the smaller dependent packages that are unrelated it would have been preferred to group them in one pr.
However too late now :smile: so just to know in the future.
Yea that would have been better as I could have then worked on dvc commit as well, but now that all dependent packages are separated between different branches, that's not possible. So I'm just waiting for those to be merged to master.
Initial PR for dvc:


Anyone want to collaborate? I will try my hand at packaging it in a bit, and will probably add it to the wayland/windowmanager overlay I'm maintaining along with a nixpkgs PR if I get it working. Arcan "Arcan - [Display Server, Multimedia Framework, Game Engine] -"Desktop Engine" http://arcan-" Durden "Desktop Environment for Arcan "
I've succeeded in building and running Arcan and Durden. works but I'm sure there are things in the closure that don't belong (X11?). I started with Void Linux's dependency list and kept adding things cmake complained about until it built. Getting it running was challenging because it depends on a bunch of environment variables being set correctly and neither the error messages or the documentation are all that clear. It also wants its binary to be SUID. Here's what I've been doing while working on the package and figuring out how to run the binary: From a virtual terminal: Here are my settings for the environment variables: I created all the directories in $HOME which are referenced in the variables. I don't have a package for Durden. I installed it by cloning it off github and then making a symbolic link to its subdirectory from . I'm running this on a laptop with Intel graphics, and have been working on it in a virtual terminal with my x session left running in another. The one time I switched back to xserver without killing arcan first, it hung my laptop.
That is great to hear thank you for sharing. I'm pretty occupied right now with some traveling, but I'll try to take a look at this soon. Thank you for writing it up though, I'm sure someone will stumble on that and be thankful too! EDIT: oops, I thought this was on a different repo, I probably would've worded this differently otherwise. Either way, still excited to see this. :)
I've and am typing this in Firefox running in an X server in a window on Arcan. The package definition builds an executable called and you can invoke it from a shell prompt in a Durden window to run it. To run a second instance, use . To start an application or window manager in the X server from a shell prompt, set first as in . It doesn't automatically detect when its window size changes, but works. The font path part of the derivation isn't right. I made two attempts at making it work and left them both in the derivation. The code in puts a font path into the configure flag provided for that purpose, but the resulting executable can't find the fonts. The other chunk of code in links fonts into the derivation, and that part gets the truetype fonts to work but not the bitmap fonts. I'm happy to run so I stopped there, but someone who knows more about X fonts than me should take a look.
I was curious about the various Arcan tools (clipboard, image viewer, network proxy, wayland bridge) so I packaged them. There had been a lot of change in the tools directory between the last release and master, so I packaged the tools from master. So the latest commit in adds , and several child packages under . I haven't figured out how to get the Wayland bridge to work, but I wasn't using Wayland before this so may be missing something obvious. I have been running and with Durden on my laptop for about a week now and am finding it very usable and stable.
Hey there and Wish I had found this thread earlier. I had a go at packaging Arcan at . It builds, however it still has some rough edges at runtime (most glaringly, mouse and keyboard don't work if not running as root - addressing that now). I'm going to study what the two of you have discovered so far, and maybe we can join forces in bringing this very interesting piece of software to the Nix ecosystem.
Hey I've just updated with a commit to make it build more recent versions of and . I've had no problems with but the recent litters the screen with mouse cursor trails. It would be great to get it running not as root so keep us posted on your progress.
To get the keyboard and mouse to work when not running as root, just add the user running to the group.
thanks, that worked! I brushed the dust off my Arcan/Nix code just to try out your suggestion. Now I have Arcan, its core utilities and the example compositors (except which fails to find something or other) running on my system, including a terminal - one more thing to run besides , , or in a vanilla console! Neat! I skipped the whole overlays thing and ended up with a file that can be submitted to Nixpkgs (or imported into ). Guess I should share that part of my config as a gist or something before submitting a PR? Or is there something missing, as might be suggested by Food for thought a.k.a. "and then what?": Port my i3 keys to a fork of Durden, ripping some features from Prio to finally organize my daily terminal-browser-devtools grind in a sane way :grin: We have a powerful engine on our hands and a whole lot of Lua ricing to do. Would be cool if some logic from can be ported over to an environment outside X.
Gist: (Sure is cool how Durden and Prio have different mouse capture behavior btw)
I marked this as stale due to inactivity. →
There is still some good progress over at the gist.
I found this while looking into a new project (, ) posted to today. (By same developers as arcan, and uses arcan, so I was curious if we had it packaged.) Just cross-referencing on the off-chance it helps anyone here. I'll also add this to the gist.


Data that was once config and recorded on doesn't get updated when the configuration changes. This is a violation of purity. And more than that, it's very surprising when trying to install, hesitating between pgsql and sqlite, and struggling before understanding that the configuration doesn't get used anyway :p cc
that's a bit tough. We have a unit, that's supposed to do the installation. We use the command to install nextcloud (passing the configured database and adminpass settings as command parameters). This CLI generates , and installs nextcloud. The script checks the presence of , and skips installation on following starts. If you now change configuration from the module, we won't run the install command again, as the config file already exists, and assumes nextcloud is already installed.
Hmm… Maybe it would be possible to generate the somewhere in the store, and symlink to it? This way the next time runs it can in addition check whether points to the correct store path. Now, I don't really know what exactly does, so maybe it's not actually possible to do this because eg. one would need to re-run on certain configuration changes? In which case it'd be hard :/ but at least we can maybe make fail or something like that, so that the issue is at least noisy?
I don't recommend to do this, I just tried that (after upgrading one of my personal systems) and this tries to recreate a database schema which can end in very bad results. Unfortunately I doubt that this will work properly, nextcloud wants to merge this during the runtime. E.g. it adds a after a successful or adds trusted domains when running the corresponding command. I'm using this as well now and hitting these issues, unfortunately I don't have useful ideas either ATM, but I'm happy to discuss better solutions :)
Nextcloud edits it's in a lot of different places, so having it generated through Nix currently isn't possible. digs into that already, I a comments about our use case here too.
to avoid other people running into the reconfiguration issue for now, what about documenting that, maybe in ?
That's certainly a good thing to do. If nobody else wants to take over, I'd volunteer to do this during the next week as investing time on improving the nextcloud module is one item on my todo list :) I was aware of being stateful, but thanks a lot for linking the corresponding ticket! I'll have a look at this as soon as I have sufficient time to :)
In the light of this issue, what's the correct way to upgrade nextcloud to a new major version? Do I just pull a newer , upgrade my system and hope that the systemd job will do the right thing?
The service runs an that should apply all changes like database migrations needed for the new Nextcloud version (beware, downgrades aren't possible). As long as you let Nextcloud do its job, you shouldn't get that much issues. IMHO the actual problem here is the configuration of the software within Nix(OS).
just a simple question (could not come to a conclusion after the lengthy thread) but I recently updated my nextcloud via nixops deploy and the update disabled the calendar module. Did I mess up or is that expected ? any way to configure this from nix ?
Assuming that you installed the calendar module via the UI, it is installed in . The beginning of my config reads: So in principle nextcloud can edit the apps installed via the web interface (otherwise you couldn't install them via the interface in the first place).
I don't think there's anything actionable here - the nextcloud nixos module is limited by how Nextcloud (imperatively) manages its configuration. The current state is properly documented in , and we raised our concerns to upstream in - closing this issue, feel free to reopen if there's more to be done.
I think one actionable item would be to have the nextcloud service fail with an explicit error if the configuration being used is not compatible with the configuration defined in the .nix. At least the user would be warned in practice that configuration is not really applied, and not only by the manual that they are relatively unlikely to actually read. Reopening for now, feel free to reclose if you think that's not a reasonable “solution” :)
The problem is we don't know whether the configuration on disk containing database connection information () differs from the one that would be generated through an installation via - we don't render the configuration on our own, but the installer writes it out as a side-effect. If I'm not missing something obvious, checking configuration changes would translate to parsing/evaluating on every nextcloud startup as an , comparing every "interesting" key with the one provided through nixos configuration, and eventually then bailing out if they differ. I'm not sure if that's a road we'd like to go and keep up to date, while the underlying bug is a missing distinction between configuration and state upstream…
Since upstream mixes state and config it's questionable whether their configuration format is somehow supposed to be backwards-compatible (as it's only supposed to be used internally by Nextcloud). Hence I'm afraid that this will make i.e. upgrades even harder in case of configuration changes, so :-1: from me. As the issues are documented in the manual now, folks are warned and I think that this is a better option in contrast to adding more complexity to . I suggest we either close this for the reasons already stated or wait for an appropriate upstream fix.
I really don't feel good having stuff in that's actually a disguised command line… :/ Something that would sound nicer to me would be an executable that the user would have to manually run, and a bare-bones module that does not handle setup or configuration and just makes sure that the systemd unit is setup. At least the error is obvious (enabling the module without having run the executable would fail), all module options actually mean something, and the impure operation is made explicit. Either that or, similar to , rename all the options so it's explicit that they're used only for initial configuration. Would one of these solutions make sense to you?
Me neither, but currently we don't have much choice… I really like the fact that we can set up the Nextcloud instance in an unattended fashion, without having to worry about manual setting things up. I really don't want to end with more imperative setup steps than necessary. In theory, we could move some of the options in to to make it more obvious what isn't applied continuously. But TBH, I'd rather like to see the state/config mixing fixed upstream than having to introduce more mental complexity here, especially if this gets fixed and we end up with both incarnations. Really, this issue only occurs while a user changes nextcloud database parameters (mostly while tweaking his initial setup), and not having read the module documentation, where the behaviour is documented. What about adding the following (subtile) log statement, to point users to the docs when they peek into the logs while things are not working as expected?
I agree that the log statement is the minimum we can do, and would at least give a hint about the way in which things are broken. Now, I guess the reason we're kind of disagreeing on the path forward is that you're much more hopeful than me that nextcloud will ever fix its stuff -- I'm assuming it'll get fixed in years at best (and even then…) -- and if it's in years then I'd much rather live with for years then spend a year deprecating it by making it conflict with new options than try to live with from now on and have users fail to understand what is going on. Now urhm, I'm investigating the module a bit deeper, and… is there any reason we can't put the database configuration etc. in ? We could then refresh on each activation, and it should be enough? If we have a way to couple it with something that automatically runs iff the database is not ready yet then the setup would actually be… almost perfect?
After having a deeper look at the sources ( at github, (6 commits ahead of v16.0.0RC1)) I guess that this should be possible (I didn't test it yet though). Configs will be loaded from using PHP's function[1] while all files ending with will be taken into account. Hence works as all config arrays will be merged together. This config will be loaded at [2] and is available as which is then used in the DI container[3]. If I understand the code correctly, I assume that it should be possible to render all config options in as config files found by glob will override values from [4]. [4]
Nice catch! This might indeed be possible - we should make very sure that config overrides work the way we think they will - seems to write the merged configuration, and not just the overrides (and merging this with other config in the wrong order can lead to wonderfully weird to debug issues) ;-) While I'd still prefer nextcloud splitting config and state properly, and being able to cope with read-only (base) config - it might be a direction worth exploring. What do you think?
Well, for the record it was actually idea :sweat_smile: I guess so, all the stuff from is also in my at the moment. I'll probably have sufficient time next weekend to check if I can trigger such a case. I can't promise that, but unless anybody beats me, I can hopefully prepare a fix for this :)
Did you gain some new insights on this?
Unfortunately not... I was pretty busy back then. But as this only requires some fiddling in the module and no patching of the actual package, the change shouldn't be too painful, so if you'd like to take over... :sweat_smile:
there's with a fix now :)


Our current legacy nvidia driver of the 340 branch does not work with kernel version 4.19.2: NixOS is currently on the 340.104 version, but upstream is on 340.107: I hope that updating to 340.107 resolves the issue, but I don't understand how to update the different checksums for the nvidia driver. /nix/store/kic17fw8wil74k04kzh3dha43izrr9j3-bash-interactive-4.4-p23-dev copying path '/nix/store/kic17fw8wil74k04kzh3dha43izrr9j3-bash-interactive-4.4-p23-dev' from ''... system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
The hashes are located at and can be generated like so: Please try:
Thanks alot for giving me a hand and teaching me how to get those four hashes! :+1: Updating to 340.107 indeed resolves this issue. PR:


During configure, ’s configuration script checks for certain features of the command, to quote the source: The latter two are not available on macOS, but nevertheless get enabled (I suppose is in when configuring?). Things we can do: with on darwin. haven’t really looked into how this build system works, but maybe we can pass configure flags to explicitly disable these features no matter what on darwin? it away.
For searchability, a typical error would be:
FTR I’m not quire sure where to apply any of the fixes, probably in . (/cc


(this is a qt specific test): Loc: [t-(458)] PASS : TofuInfoTest::cleanupTestCase() Totals: 7 passed, 1 failed, 0 skipped, 0 blacklisted, 1047ms This seems to affect master too, but for some reason it's been built successfully once. The aarch64 build started failing when updating qt5 from 5.11 to 5.12 making it the likely root cause: Edit: the cause was expired testing keys: cc maintainer cc as you've been active in keeping plasma/kde up to date lately. ping staging next:
Did you found ? Sounds very similar and should be fixed...
No didn't find that, but yeah, that sure looks exactly like the same issue. I'm guessing the qt issue were never actually fixed: Blame on the test gives no change at least:
And applying the suggested patch does fix the test: diff +++ gpgme-1.10.0/lang/qt/tests/t- -455,7 +455,7 private Q_SLOTS: QVERIFY(result.numSignatures() == 1); auto sig = result.signatures()[0]; QVERIFY(sig.validity() == Signature::Marginal); QVERIFY(sig.validity() == Signature::Marginal sig.validity() == Signature::Unknown); auto stats = ().userID(0).tofuInfo(); QVERIFY(!stats.isNull());
So, what are we want to do? Do you maybe want to comment on the upstream issue?
Hmm, strange, I'm getting the same failure on master (using ), forcing single core does not fix the problem though, so probably not a race condition. I've reported the failure as you suggested:
The cause is most likely qt 5.11 to 5.12 upgrade, as the aarch64 build started failing the test then:
So the keys used in this test expired on 2019-01-06, which explains why we suddenly saw this without any apparent reason. :
Thanks for fixing this and sorry for my late reply... (Edit: And of course also thanks


An update of zip-archive package from 0.3.3 to 0.4 in is causing a runtime error in elm compiler (). It would be good to set the elm's dependency on zip-archive to version < 0.4 until this gets fixed.
probably best to patch it
I think fixes it, will try to find more time to test tomorrow morning.
Shoot, I forgot all about this -- I did confirm that commit fixes it, I will clean up and open a PR soon.


should be enables horizontal scrolling
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 .


I tried to enable syncing Unix passwords to Samba via PAM using the option. However, I see a bunch of errors in the logs because the library PAM is looking for, , doesn't exist. Use the following config: Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(USER): channels(root): nixpkgs:
Same issue here. The folder it was searching for () only contains on my system. Additionally, querying for presents no results.
Just experienced exactly same issue on 19.03. Is samba broken in this release?
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 .
It's still relevant now. I noticed this issue in my system logs as well. Samba is not broken, they've just deprecated this feature. See and . Here's a PR for us:


always has the same , and the same filename inside. Build NixOS with , look into I think it would be sometimes more convenient if the kernel version would be clear for each (which is actually initramfs). I think it would be better to literally include the as a suffix to .
This sounds like a sane idea to me.


I have been burned by this several times; and I am not alone: When calling with multiple arguments, we should either patch all of them or print an error. Ignoring arguments silently should be a crime. cc


building some cross-compiled packages and inspecting their run-time closures: will show that depends on (on master ). this is because the package isn't spliced correctly: The cross compiled packages depend on the folder, but this path also contains x86 binaries in it! (like ). This causes a bunch of other run-time x86 dependencies to be packaged with the cross-compiled binaries. pointed me here: , which is possibly broken. Trying to move the ARM libs into the output caused a cyclic dependency between the lib output and the normal output :( so I'm stuck & posting this issue. build a cross-compiled binary with a cross , notice that it has x86 binaries in it's run-time closure (assuming the build system is x86): system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:


fails with the vdirsyncer version from nixos-unstable. it works if I install vdirsyncer with pip. Output of :
Which do you get via ? Is it the old 0.16 branch or the new 0.17 one (which was mostly rewritten in rust)? We have the latest git version of 0.17 in nixpkgs. Unfortunately, so it might be some time before this bug is fixed.
outputs this:
Same problem here. Was there any reason to go for an alpha release except for the issue referenced in ? If not, a downgrade to 0.16.7 should be fine, since the original bug is still open and probably won't be fixed for a while without anyone maintaining vdirsyncer.
There are , so I'd rather not downgrade. I'd be happy with a package for the 0.16 branch though.
That'd be great! I haven't looked into packaging yet, so it would take some time if I tried. Would you mind helping out?
I just opened a PR. It’s my first time contributing to , so I hope it’s up to snuff.


After in nixops, we can remove the locally pinned version in nixpkgs.
Not yet, I would like to keep those for building nixops v1.6.1 for any users of the Azure backend.
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 .


It should always show the NixOS version. Reproducible on: Lenovo Thinkpad X230 with grub Not reproducible on: Apple iMac 11,3 with systemd-boot (EFI) Thinkpad L470 with systemd-boot (EFI) system down system system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs:
I can second this. It's been the case for ages.
Yes, I'm not sure why this is. It used to show it at startup, and I don't think anything much has changed there.
I did an update yesterday and bootet the system today and the version was shown. It's a Thinkpad L470. I will see if it fixes it also on the system i used when reporting this issue. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Doesn't work here on latest unstable.
Seems to be a problem specifically with GRUB.
I'm using systemd-boot, not GRUB.
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 .
Problem persists.
This is because the Plymouth plugin is missing from the initrd, along with a font with which to render the text. See .


The rust crate "built" assumes that certain environment variables are always set -- to an empty string if necessary. This is what cargo does, so let's emulate that. See for more details. See I am preparing a patch to fix this, so I skip this.


This expression fails to build on 19.03: The problem is that its checkPhase is not correct as the command cannot be found. I believe that should be in the for it to succeed. Run the below inside The error is: Please run and paste the results.
It can be put in as is usual for pytest because we have multiple versions of it within . However, the tests fail:
Not sure what is causing that error, but I use it fine for my purposes.
How do you use it if it doesn't build? Would you mind making a PR with the fix?
It does build, I use a custom pytest- because I was using it before asking it for inclusion in nixpkgs. Anyway it's now being addressed in:


build of gpgme-1.13.0 fails on macosx . . . nix-env -i gpgme Please run and paste the results.
I can reproduce this on , but it builds fine on current master
Closing since seems to be fixed after , but feel free to reopen if you continue having issues
i am seeing this again on
bisecting suggests it started with or (in the latter commit, indent fails to build, rather than getting the File name too long error, though)
Same here (seeing this again)
It seems like this is caused by a of unix socket path length limit (which is just 104 on darwin). A workaround that works for me is to build it with a different TMPDIR:
Related to
Thanks for the workaround using it, gpgme install gets stuck at
I had the same problem. I think this might be an unrelated issue. It did build successfully on the second attempt for me.
It would be nice if somebody could investigate how to disable just the problematic tests instead of completely turning them off with .
Turning off the tests didn’t work for me, it seemed to fail on the build step
we could add a patch to disable these tests on darwin:


application can't find help files Install from nixos release channel, go to main application screen, click on Help menu and select either "tutorial and concepts guide" or "contents". Application complains with a modal reporting "GnuCash could not find the files for the help documentation. This is likely because 'gnucash-docs' package is not installed." system: host os: multi-user?: sandbox: version: channels(root): channels(zarel): nixpkgs:
As a workaround: the very same documentation is available online at this address:
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 happening
Pinging maintainers
There is more to it. Gnucash installs its document files into plain without subdirectory. Because of that common files like do have collisions with analogous files in other packages. Edit: Ah, that's another issue. Which was resolved in
Documentation for Gnucash is a separate project: It should be separately build and installed in order for help files to be available.
I marked this as stale due to inactivity. →
I've built the documentation and put the documentation in the XDGDATADIRS. I can browse the manual and the tutorial via but running gnucash in debug mode says "Unsupported action" and according to strace the application doesn't try to open the documentation directories... and the same happens for evince (can see the documentation in yelp but the application won't display it), maybe it's the same issue
Not stale, I'm still having this issue
I marked this as stale due to inactivity. →
issue remains.
Thank you for the fix! Do you think is there a way to warn the user about not having yelp in a profile?
I don't think there are any convenient/good ways to tell the user about it. At best, we could add it to the description?
If gnucash documentation depends on yelp, would it make sense to express this dependency in the gnucash derivation?
Apparently, it must also be in MIME. This sort of stupid behaviour looks like an upstream bug to me.
If an application shipped its help files as HTML and required you to have a web browser installed to view them, I think it would be silly to add a dependency on any specific web browser. Likewise with help files - if (at least theoretically) Yelp is just one of several possible help file viewers, I don't think it makes sense to add a dependency on it. A better indication of what's wrong ("you need to install a help viewer" rather than "couldn't find the docs") would be nice, though, which I presume is only really doable upstream.


On today's master () - and probably others - building the attribute of many package produces an output that differs from the output on another architecture. Nix will display a hash mismatch. I tried with x8664-linux and aarch64-linux. Execute this on aarch64 and x8664. The aarch64 build produces the below output while x8664 is happy with the hash in nixpkgs. Please run and paste the results. system: host os: multi-user?: sandbox: version: nixpkgs: and system: host os: multi-user?: sandbox: version: channels(root): channels(andi): nixpkgs:
x8664 build produces same output for me: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
I noticed something similar on macOS in Could some recent change have caused this? Perhaps ?
I reverted in a branch on my fork. My x86_64-linux laptop doesn't complain about the hash sum - as before. The aarch64-linux community box also doesn't complain anymore. Can anyone else confirm this?
I just made a diff of : The left side is aarch64, the right side is x86_64. Both are done on the same git revision ().
What a weird behavior that is missing.
Probably related:
I think this may be related: I also see different hashes on NixOS 19.03 vs. stable. I use the branch, but when CI builds the derivation on 19.03, the hashes do not match. If I build on NixOS 19.03 with from master, the hashes do match. This is quite annoying, because it makes it impossible to have package sets that work on NixOS stable and unstable without using rustPlatform from a nixpkgs newer than 19.03. I'll try to revert and see if I get the same hashes on 19.03 and master.
That's indeed it. When I revert , I get the same as 19.03. Maybe this change should be reverted? Since NixOS is not a rolling distribution and people run both stable and unstable, it would really be nice if package sets and overlays work on both versions. This also makes backporting changes easier.
Diff between the vendored dependencies: Here the differences also seem to be missing dotfiles (e.g. and ). I think this is the upstream PR that changed this behavior: (Edit: oops, I just saw that already mentioned the associated commit.)
is a critical update and reverting it will break multiple Rust packages. Rather I think we should get that change pushed into the channel, and then update any Rust packages whose changes as a result.
The only bummer is that it also breaks people's own packages on the channel as well.
Yeah, it would be bad to break people's derivations as an update to a stable release. At any rate, the 19.09 release notes should probably have a blurb that points out that hashes will change due to changes, so that people who update from 19.03 to 19.09 are prepared. There are probably also derivations in that have incorrect hashes now, since the file that is generated by is now excluded vendored dependencies.
I’ve updated the title of the issue to better reflect what I think we now know. Additionally, I’ve opened to update the hashes for all packages that haven’t been updated in master yet. I would appreciate a review on it. Once that’s merged, I can do the same thing for the affected release branch.
Looks like I misunderstood and this hasn’t made its was into a release branch yet, so we’re almost done here. Somebody just needs to add the release note for 19.09.
with the changelog PR () being merged, is there anything else missing?
Don't think so. :) Somebody can shout if I'm wrong.


. The short of it is that doesn't have a flag on OS X.
The in use is from .
It seems that removing from solves this issue. I'll drop that in a PR to continue the discussion.


Right now if you update the unstable tree and install ddclient the shebang patch is not applied properly and the first line of the script starts with: This reference doesn't exist so the actual binary cannot be started. ) Install ddclient ) Attempt to start ddclient


In there was an option introduced that indefinitely tries to restart the wireguard service until all peer hostnames are resolved. Instead it should use as introduced by instead. This feature will be available in the next snapshot release of wireguard. cc
Alright 0.0. has been released for the purpose of this disaster being fixed. care to cleanup the mess?
I fail to see what mess/disaster you're refering to.


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


aborts and produces the following error: I suspect it's due to , but when I started building a NixOS vm with the merge commit checked out, Nix started building ; I just don't have the computing resources to build from such a starting point. What I do know is that the problem exists in but not in
It's indeed likely due to that PR. As mentioned in the message, its up to the maintainers/community to fix the usage of the wrapper in the various packages.
Yep. I have a fix for the "Qt platform plugin" error, but the missing Qtml module has stumped me. I've -ed my way toward the culprit, but I'm not there yet; Compiling LLVM, Qt, PyQt... takes a LONG time on my computer ;)
According to git bisect, the first bad commit is This implies that somewhere within that commit the PyQt build changed such that the Qtml module is no longer being built.
Can confirm the issue.
I dug into this further yesterday, and though I don't have a solution, the problem points to three things: package needs to be modified to use . That part is easy, and I already have a commit for it. is building in such a way that not all of its modules are included, namely the QtQml module. This results in another runtime error; visible after has been applied. reason is building with missing modules is because during the build process it uses tooling to determine whether said modules should be built. In the past, the tooling would return in the affirmative, causing the module to be build. However, as of late the tooling returns in the negative, thus the modules don't get built. This can be seen in the trunk/master python37Packages.pyqt5 builds on Hydra; just search for QtQml. It is number 3 above where I'm stuck. It seems like it's due to a change in , but I don't know what that change could be, nor how to test for it. Note: I ruled out the mismatch between PyQt 5.11 and Qt 5.22 as a potential cause by forcing PyQt 5.11 to build against Qt 5.11.
Yeah, I've been at least aware that we needed to update PyQt I think is working on this.
Fix in
Unfortunately, did not fix it. I: out a vm with qutebrowser within the vm The error is the same as I originally reported. I noticed that adds as a dependency to qutebrowser, but doesn't utilize nor . In contrast, my workaround is to --after applying a hack to PyQt 5.11 -- change qutebrowser as follows:
I think the cases were working for me because my environment has the right plugins. But indeed, wrapping should fix this.


Currently python packages in propagatedBuildInputs are included into PYTHONPATH and are referenced by a file in the output (propagated-build-native-inputs), which makes them run-time dependencies: For ELF programs nix can figure out the run-time dependencies by scanning the executables, this fails for python as the dependencies are not referenced in any file. DISCUSSION: pth files could include such references and would handle PYTHONPATH manipulation a nix-support/python-build-inputs could list python buildInputs, turning them into run-time dependencies and further they would be used in the above _addToPythonPath
pth files it is


Describe the bug qutebrowser doesn't start To Reproduce Steps to reproduce the behavior: the latest nixos-unstable qutebrowser Expected behavior qutebrowser starts Screenshots ! Metadata system: host os: multi-user?: sandbox: version: channels(philipp): channels(root): nixpkgs: Maintainer information:
The issue is present since I will figure out what commit from staging it was, but for now my computer is busy compiling :)
maintainers:
Related to
And
Thanks to for this valuable piece of information: Adding wrapQtAppsHook only address plugins, such as xcb, not loading. It does not address the missing PyQt5.QtQml module. According to a working build of qutebrowser, that module is actually missing from PyQt5. This can be seen by comparing the PyQt5 referenced by working and non-working builds of qutebrowser. In the working build you'll see the files and in `/nix/store/PyQt/lib/python*/site-packages/PyQt5/. In the non-working build those two files will not be present. In fact, I recall seeing other missing files, such as QtWebEngine. I tried some stuff and it seems like since the propagatedBuildInputs are somehow ignored and can not find webengine or qml, even when adding qtdeclarative to propagatedBuildInputs. I have no idea why, but only when I put them in nativeBuildInputs, can pick up those dependency and will produce a pyqt version with webengine and qml modules and qutebrowser will start successfully. I know this is wrong, so maybe someone can find the cause of this and a proper solution.
fixes this, but it is not a proper fix.
Fix in
Does anyone know a way to work around this bug, and get a working Qutebrowser, without having to compile it?
You can install a qutebrowser version from an old nixpkgs revision to your user profile. If you have cloned nixpkgs somewhere:
Cool, thanks. But doesn't that build the whole thing? Building a web browser like this takes several hours, no?
This package should have a binary cache now.
Not really: the engine (QtWebEngine) does, but the browser itself is just a relatively small collections of python scripts, so it's pretty fast. QtWebEngine, being part of the base Qt package set should always be cached, even if you modify qutebrowser.
When I installed the version mentioned above, it was still cached. Usually old packages are removed from the cache quite a while after they were replaced. But as worldofpeace mentioned in current unstable qutebrowser should work just fine again.
Cool, I didn't know about that. Thanks!


Describe the bug grpc doesn't build on macOS. To Reproduce Steps to reproduce the behavior: -shell -p grpc Expected behavior Should have built without errors. Additional context Build log here: Metadata system: host os: multi-user?: sandbox: version: channels(kaali): nixpkgs: Maintainer information:
grpc appears to be pretty out of date , so I'm suspecting that updating all of the pieces would resolve this.
Seems to fail in CI even with an updated version:
That particular package requires manual intervention, as that PR was automatically generated by a bot.


write python expressions (5.2 in nixpkgs manual) use virtualenv create nix python environments
Does this documentation exist? Should it be completed before the release?


, (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives.
` will take some effort.


Project description Imageboard/booru downloader which can download thousands of images from multiple boorus very easily. Metadata homepage URL: source URL: license: Apache-2.0 platforms: Windows, Mac, and Linux
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 not packaged for NixOS. So still important (at least to me). I'm trying to package it myself, but it doesn't work due to dependencies on packages from NPM.
Going to take a look at this after I open a PR for .


Describe the bug In mpv, CUDA-accelerated playback worked a few months ago after landed, but now no longer does. To Reproduce Steps to reproduce the behavior: NixOS master with an NVIDIA card and and observe: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(at): nixpkgs: Maintainer information:
I will see if doing helps


Describe the bug A clear and concise description of what the bug is. When running dolphin on plasma5, getting this error: /cc To Reproduce Steps to reproduce the behavior: dolphin "Search for -Document" error Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(mbauer): nixpkgs: Maintainer information:
It looks like adding to systemPackage fixes it.
cc
There is also a similar bug with Kmail if you don't include Akonadi in system path. Something must have changed in the way binaries are found.
We should make sure that puts in ; actually, anything that provides a should.


Describe the bug Currently the python 3.7 module (the other versions likely too, but I have not tested this yet) fails due to some numeric discrepancy caused by a recent upgrade of . This breaks ~26 downstream packages. I'm filing this to keep track of this for and am currently bisecting to confirm and test some other versions too. This is caused by a singular test failure: Upstream issue: Full hydra log: To Reproduce Steps to reproduce the behavior: on or . fails Expected behavior Tests should pass. Maintainer information:
Fixed by


, (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives.


libwebsockets 3.2.0 changed its behaviour in a way that breaks all versions of Mosquitto that use websockets, resulting in incoming connections being intermittent and very slow. It is fixed in their repository and will be in the next release presumably, but for now 3.2.0 is no good. If Mosquitto is the only other package using libwebsockets, I would suggest downgrading to 3.1.0, which behaves fine. Mosquitto 1.6.5, which should be released today, will refuse to compile with libwebsockets 3.2.0.
cc
mosquitto 1.6.5 fixes it - just haven't packaged it yet.
Mosquitto 1.6.5 does not fix this. There is a changelog entry which was written prior to this issue that is probably why you think it does have the fix. Sorry about that, I changed the changelog on the website post but not in the repo. The only fix for this is in libwebsockets itself.
it's pretty awesome having upstream providing proactive updates like this - much appreciated!


Describe the bug On opening Anki, I get this error My guess is the fix would be similar to (add ).
Intermediate fix: I put this in my in :


I'm trying out NixOS 19.09 and notice that Enlightenment is still being built under X. Enlightenment 23.0 have some highlight. One of them being "Massive improvements to Wayland support".
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
It would be nice to hear about the recent progress.


I am by no means an expert on database systems, so this may be a stupid question ... but I can't help wondering why does not refer to PostgreSQL version 11 on current versions of ? Is there a reason we haven't updated yet?
Maybe or can answer this... :thinking:
Good question. In my case I'm no longer using PostgreSQL 9 by myself and switched to 10 and 11 a long time ago, but I also wasn't aware of this because I'm not using the module from NixOS in my deployments.
Made a PR for that... If you think it's too rush to include it to 19.09, then I can delay it to 20.03 As for , it really shouldn't be used. It should be split to , and , and / may be continuosly updated, but should be used only with explicit version. But this server/client split is not straightforward, so it was not yet done.


Describe the bug to the find call. This prevents things in the that are symlinks from being wrapped. Noticed this during office-hours when wasn't wrapped anymore. We should add some code like there is in or revert the . To Reproduce Steps to reproduce the behavior: a binary into or the thing and notice the binary isn't wrapped.


Describe the bug In , if you enable both xserver.services.desktopManager.plasma5 and , assertion fails. Failed assertions: cmt and libinput are incompatible, you cannot enable both (in services.xserver). To Reproduce Steps to reproduce the behavior: both and Expected behavior Failed assertion should happen Additional context Build with works fine. Metadata Maintainer information: kcalvinalvin a list of nixpkgs attributes affected by the problem a list of nixos modules affected by the problem
Found the culprit. Can we disable by default so that users can choose? The default generated has the option by default so I don't see the reason why it needs to also be defaulted in


seems to be broken in more than one way. I get (also on ) Pinging maintainer:
That is, a build against current master with succeeds for me on NixOS 18.09 Will work on fixing that, but in the meantime you have a workaround.
Not able to reproduce this one yet
Mh yeah I wrote a patch for to handle the case of not being present and after that, this error log showed up. Edit: I found my patch. Its really simple, just to fix the error. By building with that patch, I get the error log shown above.
i build scylladb under redhat7(3.10.0-693.17.1.el7.x86_64) it fail with following information: i have enough disk for it, but i don't understand why it occupy so huge size.
The final build is for me. Haven't looked into why that is, yet. Could you open a separate issue for that? Thanks!


Describe the bug is broken on Darwin. git bisect shows (part of ) as the first failing commit To Reproduce Try to build on Darwin at <details<summarynix-build -A gobject-introspection </summary</detailsExpected behavior Able to build on Darwin Additional context <!-- There is a 10 years old bug report with the same error message --Metadata Maintainer information: cc:
Looks like this upstream issue: . It's fixed on master so we should probably pick the patches.
Our jobset needs to be building on the darwin platform if we don't want things breaking like this.


Describe the bug Build fails when trying to install . I get: To Reproduce Expected behavior The package should install without error. Metadata Maintainer information:
cc
Related to
Tried the following: It doesn't even bother about the C-core Version 6 that I asked: What am I doing wrong ?
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
Refreshed. My PR will fix this issue. Thanks for your patience.


Describe the bug Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(hyper): channels(root): nixpkgs: Maintainer information:
I've also encountered this. I bisected it to . says there's a newer version (1.) whose release notes say "Fix two test failures on newer versions of gtk+/gnome-shell/mutter". However, updating to it does not fix this test failure. :( With 1., the exact failure I'm getting is:
When updating to GNOME 3.34 I did indeed notice this and tried the exact things did. We probably need to report it so it can be fixed, I just didn't have the time to do this. Guess the testsuite could be disabled.
Disabling tests got it to build for me. I'll try to find some time to open a PR for that, and to report it upstream.
Reported upstream:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .


Describe the bug sane-backends provides a configuration file, which is also produced by To Reproduce Steps to reproduce the behavior: Expected behavior No file conflict Additional context Add any other context about the problem here. Metadata Maintainer information:
Something isn't right there. I have in my , but I have no whatsoever:
The sane config is not written to /etc but only pointed at by the environment variable.
This is really just us being noisy about collisions, this one is harmless.
Even if it's harmless, what would be the preferred way of getting rid of this warning?
It doesn't really serve any purpose for nixos users, so it was fine to remove.


Describe the bug To Reproduce Metadata
In darwin building graalvm results in:
Which version of Nixpkgs is this? Please use the template...
sorry I overlooked the metadata; updated it now;


Running reports: To Reproduce on NixOS 19.09. . Metadata I ran but got .
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 .
I had this same problem today.
I marked this as stale due to inactivity. →
Not stale; this is still a problem on a flakes based NixOS system using


Describe the bug As of 19.09, dolphin can't connect to smb network drives becasue kpasswdserver is unable to start up but chrashes kiod5. To Reproduce Steps to reproduce the behavior: dolphin in the address bar, or any other smb share in your network displays a timeout or access denied, check for the actual error Expected behavior Dolphin shows the smb share's content, using stored passwords if available. Screenshots : Additional context I guess this is caused by but I don't know enough about where kpasswdserver actually lives and comes from to fix this myself. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information: cc
This does not only happen when trying to connect to samba shares, in my case this issue is triggered by the baloofileextractor indexer running in background, frequently causing kiod5 to dump core.
This is the backtrace of in my case:
We need to wrap in .
What exactly needs to be wrapped there?


I've tried the following: which should assign an alias ( happily accepts the colon syntax in NixOS). Instead it tells me: "invalid character ‘:’ in name ‘unit-network-addresses-lo:metadata.service'" I also tried: which doesn't throw an error but also doesn't get me an alias. Is it not currently possible to alias the loopback interface via NixOS configuration, or am I missing something?
(triage) any leads?
More than question I think it's a bug that it doesn't work. any thoughts?
Resolved in
Sorry, is this actually resolved? I try this in my config: And I get this: If I run the setup script by hand, it works fine. is this working for you now?
use instead: we cannot support arbitrary device names here due limitation of the script generator. Should be fine with though.
I finally had a chance to follow up on this. Using the config that suggested above, I still get these errors: does actually get the address. However, boot-up and NixOps takes a lot longer, presumably because of the timeouts. So something is still not quite right here.
That device dependency should be not according to this source code: Are you running the latest NixOS 17.09?
Ahh, no, I’m running but from a few weeks ago. I’ll try again once I’ve updated.
I still recommend to people to switch to since the scripted module is just a hack... well.
So with a recent , assigning an IP address to still causes timeouts. However, the IP address does successfully get assigned.
if the service file assign ip addresses contains a dependency, something went wrong.
I see the same:
The bug appears to be here: compared to this:
Testing this patch:


Describe the bug Packages with potentially newer versions available inside Emacs will be overriden by ELPA packages. I am running an overlay with Emacs (27) built from master. On Emacs (27) master the package has the built-in version . The package provided by ELPA is . This is currently not an issue since Emacs has not been upgraded to 27. But when it does, this is going to cause a nasty "issue": To Reproduce Steps to reproduce the behavior: the load-path and notice that it includes the seq-2.20 elpa package. Expected behavior Perhaps not not included in the load-path... This is kind of the expected behavior, but I am raising this issue as from next version if not a new seq package is released to ELPA, people will end up in an infinite loop. Additional context Add any other context about the problem here. Metadata system: host os: multi-user?: sandbox: version: nixpkgs:
Any ideas what to do about this case, is there any other packages where there potentially is a later version contained within Emacs and an older one available in ELPA?
already contains a few things mapping builtins that used to be separate packages to . This ensures that anything depending on will get the correct dependency graph while actually using the emacs builtins. The correct fix here is to map to , maybe with a conditional checking the emacs version.
I've been using a locally patched nixpkgs to remove those seq dependencies, but the solution suggested here by is so much better that I went ahead and implemented it. Please can you also take a look at the PR to see if it resolves things for you? For me the breakage was pretty severe, so easy to notice (the package did not work; so I saw the problem at startup).
Thank you, I can verify that this is working for me as well. I am sorry to let more people experience this and not patching it earlier. I already spent some initial time finding the issue and then I made a patch within my own overlay like you. Glad to see it fixed, thanks :+1:
I just discovered we have the same case for . Should that perhaps also be under a conditional? I guess if you are on an older version of Emacs you want to use the ELPA version, but if you are on the latest version you want the one bundled with Emacs as the version is more recent.
Could you make a PR to nixpkgs?


Describe the bug Neovim crashes when resizing windows under some circumstances. To Reproduce There are many different ways to repro, these are some reliable steps to reproduce the behavior: to create a split to open a terminal to go to other window to maximize window Expected behavior Windows should resize and there should be no crash. Additional context Originally filed at but it seems to only be affecting NixOS. The crashes only started since I upgraded from NixOS 19.03 to 19.09. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information: cc
If you have a known-good nixos revision and a known-bad nixos revision you could try the issue.
The earliest local generation on which this happens is from . The latest known-good generation is from . I'm not sure these are accurate though, I'd have expected this to have happened later.
narrowed it down to which was part of
That looks helpful. Maybe you can report upstream that the libvterm update is responsible, and ask if someone on non-nixos can reproduce it with that version of libvterm (or report which version they use).
Thanks for guiding me in the right path I opened a PR with a fix. :point_up:
Thanks for fixing this :)


Project description A cross-platform SSH client with cloud data sync and more. Metadata homepage URL: source URL: license: unfree platforms: linux
It would be really cool, I need it too!


I was getting errors with the version of dvisvgm bundled with texlive 2019 so I created a separate, texlive-independent version which works well. (If you're curious about the issue I was seeing it was related to compatibility between ghostscript and dvisvgm. I can be more specific if anyone wants, but reporting that issue is not the main purpose of this). Here's the build expression I'm using ( is ): How would people feel about a PR with a dvisvgm package uncoupled from the texlive version in addition to the one currently there? I could name it or or something like that. Note that I'm currently using this as a separate build expression but for a PR I'd put it in the texlive bin nix file. Note also that this package can be used identically to any other texlive package. The only difference to the end user is to get an option of a newer version.
What is the issue, though?
it's been reported . The issue is apparently fixed in dvisvgm 2.7.2 (ours is 2.6.3). Here's an additional MWE to test. The same example with v2.8.1 (in the build expression above) works fine.
So what you say, is that our dvisvgm is broken because of the incompatible ghostscript version. Then, I think, we should be fixing dvisvgm for all of our users, not just those who opt into using the separate package you propose. I would prefer to just patch the version from texlive, but, unfortunately, doesn't apply cleanly, so we would have to craft our own patch or pin to 2.8.1 (in this case, need to leave a TODO comment to remind to unpin for texlive 2020).
To clarify, the idea is to generate a patch from a newer texlive version of dvisvgm and apply that to the existing derivation (along with the code comment about this being a temporary fix until 2020)?
Does fix the issue for you?


, CVSSv3=9.8 (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
Unstable/master: PR ; 19.09: (staging ATM, but should get into channel within days).


Describe the bug Fails to build with some not-supported instructions: <details</detailsTo Reproduce Steps to reproduce the behavior: (on an aarch64 machine) Expected behavior Kernel builds Maintainer information: May be caused by
Fixed already by bumping to 5.4.x, 19.09 channel just hasn't caught up yet.
Never mind, I'm not very good at interpreting bisects.
I had the same issue (I think?) when trying to install NixOS 19.09 on Raspberry Pi 3B+
Fixed in .


Describe the bug NixOS manual combined fails to build since commit . This was introduced by the changes to the package awstats. This is the output: To Reproduce Steps to reproduce the behavior: Expected behavior It should be possible to build the nixos-manual-combined without errors. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(terje): nixpkgs:
this issue was resolved in there is one more issue with docs - a warning What should it be? You can test manual builds with
this was my mistake :disappointed: I had the entry to the manual. Unfortunately I confused myself by checking the manual on another PR, and then thinking I had checked the manual for the PR. The issue was compounded by me being rather occupied on Christmas day (mostly with only cell phone but no computer), which I supposed in hindsight was a reason I shouldn't have merged the change on Christmas eve after the kids were in bed. I apologize for all the hassle. It looks like the option lost its during this PR... another thing I would have noticed if I had checked the manual... When is back they can create a PR to add a description along the lines of , unless this pressing enough you want me to file a PR today. Thanks again to all who helped out on this!
no pressure!
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Project description A tiny IRC client Metadata homepage URL: source URL: license: mit platforms: linux


Upstream , but we still have many packages depending on it. I know of no issues since the last release, so I'm not marking it as vulnerable yet, but the dependents would better start migrating in advance. Stable: it's unclear to me what we do about these in 19.09, but perhaps there won't be any notable vulnerabilities before 19.09 support ends :-) 1.0.2 is the default in 19.03, but we don't support that anymore.
List of files:
I think we should mark it vulnerable. Other EOL packages have been marked vulnerable because of the EOL before, e.g. Firefox, and if there’s any package we should be extra-careful with, its OpenSSL.
I bumped it to fix the last CVE minutes before opening this ticket, so I was obviously biased against marking it immediately ;-)
BTW, it's still a decision to make, as there's surely some LTS distro that will keep shipping 1.0.2 for some time, so patching the worst probably won't be too difficult. I'm personally not willing to invest significant time into it, though :-)
Best way to motivate somebody to volunteer is to mark it as insecure. ;)
OK, I think the we've given enough time and now we should press on a bit: