Nixpkgs: The state of Emacs

[oxij]

We had #6250 (melpa builder), #6641 (generic builder), #7431 (emacsWithPackages), #9060 (automatic metas) (should I mention more stuff here?) which got us to the new Emacs infrastructure we have now:

• dependencies just work and derivations are a pleasure to write, but
• using non-default Emacs within current framework is untrivial #10819 (#10811, #11004),
  /cc @peti here
• people are still updating the old emacsPackages because emacsPackagesNg don't reimplement those,
• people are rewriting default MELPA expressions into emacs-packages.nix by hand, which, IMHO, makes merging something like #7986 harder every week, which pains me, since #7986 looked almost ready,
• #7986 appeared and disappeared, it seems like emacs2nix is worked on, but what is the state of this?
• Was #7431 merged only partially? Why?
  /cc @ttuegel here

Even if emacs2nix it far from being usable yet shouldn't we

• organize a rewrite of emacsPackagesNg into overridable expressions that #7986 proposed?

I think we can safely adapt/reimplement the general outset of #7986 preparing for the generated MELPA attrset to be just plugged-in, so that we wouldn't need to merge a lot of stuff when it finally arrives, we'll just throw away derivations from emacs-packages.nix that are exact duplicates of MELPA packages and be done.

• merge emacsPackages into emacsPackagesNg?

My plan here would be to duplicate emacsPackages a bit by bit with trivialBuild, emacsPackages.package = emacsPackagesNg.package. Then, when everything gets successfully duplicated and built we just do emacsPackages = emacsPackagesNg. Then we remove the old packages by aliasing them to new MELPA versions (whenever autogenerated on not). If anything breaks at any stage we could just revert a small piece.

also /cc @gridaphobe @ardumont (by the top of blame on emacs-packages.nix)
and /cc @samuelrivas @vcunat @tohl (by the top recent blames on emacsPackages in all-packages.nix)

[ttuegel]

people are rewriting default MELPA expressions into emacs-packages.nix by hand, which, IMHO, makes merging something like #7986 harder every week, which pains me, since #7986 looked almost ready,

After #7986, we decided that the generated packages should not override the hand-written packages until they could be tested. In other words, the existing packages will be overrides on top of the generated packages (at least for a while). Therefore, I don't think this is a barrier to merging the generated packages. As you pointed out, there is the separate issue of rewriting the existing expressions to be overridable, but that doesn't have to happen at the same time.

7986 appeared and disappeared, it seems like emacs2nix is worked on, but what is the state of this?

I think I'll have the ELPA packages ready today. The MELPA packages will take a bit longer; I need to make a PR upstream to correct some bugs I found in the MELPA recipes.

[oxij]

After #7986, we decided that the generated packages should not
override the hand-written packages until they could be tested.

Yep.

In other words, the existing packages will be overrides on top of the
generated packages (at least for a while).

I think some will and should persist, because of propagatedUserEnv stuff
and, possibly, older stable versions.

Therefore, I don't think this is a barrier to merging the generated
packages. As you pointed out, there is the separate issue of rewriting
the existing expressions to be overridable, but that doesn't have to
happen at the same time.

So, if I understand you correctly, you're saying that merging the new
version of #7986 would be easy for you, no matter what I (or anybody
else for that matter) does in the middle of emacs-packages.nix? (I'd
really like to start moving older packages there.) If that is the case,
then awesome, but I think this to be unlikely, so I'm basically
proposing to implement (or take from your current branch if you have
any) and merge a kind scaffolding for autogenerated stuff so that people
could play with the rest of emacs-packages.nix without the
scary-future-merge-anxiety.

I think I'll have the ELPA packages ready today. The MELPA packages
will take a bit longer; I need to make a PR upstream to correct some
bugs I found in the MELPA recipes.

Woo, awesome!

[gridaphobe]

merge emacsPackages into emacsPackagesNg?

Yes, we should really do this. I would also go one step further and convert the trivialBuilds into melpaBuilds so they can integrate with package.el, but this can be done after the initial migration.

I think I'll have the ELPA packages ready today. The MELPA packages will take a bit longer; I need to make a PR upstream to correct some bugs I found in the MELPA recipes.

Very exciting! Thanks for all the work you've put into this @ttuegel!

[ttuegel]

The automatically-generated packages are merged now, adding several thousand builds to Hydra. There are quite a few cases where builds are failing due to dependencies being too old; e.g., many of the ac-* packages want newer versions of auto-complete. There is a newer version available for most of these dependencies, but I intentionally allowed older, hand-written packages to override the newer, automatically-generated packages.

The next step is to go through and remove the old expressions. If the old expressions made modifications to the packages (patches, etc.), then the generated expressions will need to be overridden. We can just override the parts of the generated expressions that need it; that way we still get new versions automatically. (I can help with that if it's not clear how to do it.) I think the responsibility for removing the old expressions should fall on their maintainers, so we need to track down all the maintainers and inform them. Controversial suggestion: old expressions that do not have a maintainer should just be removed in favor of the up-to-date expressions. Thoughts?

[gridaphobe]

Controversial suggestion: old expressions that do not have a maintainer should just be removed in favor of the up-to-date expressions. Thoughts?

Doesn't seem that controversial, if there's no listed maintainer we can't do much to contact them. I suppose we could git blame the expressions and ping the oldest committer. We could also post to nix-dev about our intentions (that's not a bad idea anyway to announce the newly improved emacs ecosystem!). But in general, I support removing outdated expressions with no listed maintainer.

[oxij]

I think moving old emacsPackages to Ng should be done first. I'll start
doing some of that this week (most notably, I plan to merge two
org-mode expressions into one that has *Support options so that one
could use gnuplot and diaa out of the box).

Controversial suggestion: old expressions that do not have a
maintainer should just be removed in favor of the up-to-date
expressions. Thoughts?

Pretty much all expressions don't have any.

Surely, removing derivations that produce byte-by-byte equal binaries
from emacs-packages.nix can be done without any drawbacks.

As for removing expressions updated in MELPA, I'd say it's okay, but it
should be done with one removal per commit so that stuff can be
reverted. Preferably, removals should be done by people that use those
packages to minimize reverts. E.g. I use org-mode like there's no
tomorrow and know how it supposed to work in 95% of its functions, so
I'm pretty sure I can work with those expressions, but, e.g. for helm
I use ~2% of it's functionality, so I'm unlikely to notice if something
breaks.

I'll look into packages added by me this week.

The next step is to go through and remove the old expressions. If the
old expressions made modifications to the packages (patches, etc.),
then the generated expressions will need to be overridden.

Btw, it would be nice to have a canonical example here on how one is to
do that. I suppose it should be something like

package = melpaPackages.package.override { melpaBuild = d: d // {... stuff ... }; };

or

package = melpaBuild {
  inherit (melpaPackages.package) pname src;
  ...
  stuff
  ...
};

but maybe not.

Finally, I noticed that

1) attributes in JSON files are sorted in peculiar ways, not
lexicographically. Is that by design?

2) there're no descriptions and licenses there, which is not that good.
Can we do something about that?

[ttuegel]

attributes in JSON files are sorted in peculiar ways, not lexicographically. Is that by design?

Yes, the JSON library I'm using sorts by the hash of the package name. It's a stable sort, so the update diffs will still be small.

there're no descriptions and licenses there, which is not that good.

I'm not sure how to get the license information out of the packages; I'll have to investigate further.

In the past, I have gotten description information from the packages, but Nix doesn't have full Unicode support, so it could not read all the descriptions. I removed them rather than trying to work around the problem, but I can see what it would take to fix Nix's Unicode support.

[oxij]

there're no descriptions and licenses there, which is not that good.

I'm not sure how to get the license information out of the packages; I'll have to investigate further.

As a simple hack, I would just concat all the source and documentation
files, remove all the spaces and '\n's and grep for literal texts
(transformed the same way) of all common licenses.

In the past, I have gotten description information from the packages, but Nix doesn't have full Unicode support, so it could not read all the descriptions. I removed them rather than trying to work around the problem, but I can see what it would take to fix Nix's Unicode support.

Can't you just replace (or just drop) non-ASCII characters with
something else there?

[ttuegel]

As a simple hack, I would just concat all the source and documentation files, remove all the spaces and '\n's and grep for literal texts (transformed the same way) of all common licenses.

Hm, I can probably even do a little better. I think all the packages are required to have a <package>.el file. The license text will be in the comments of that file. For the description, I could take the first paragraph after ;;; Commentary:. I could also load the description from the package.el interface, but it looks like it just takes the first paragraph of the commentary anyway. Unfortunately, package.el doesn't seem to have a notion of licensing, although most seem to be GPL-3.

[ttuegel]

After my last round of generated package updates, there are only a few packages still failing to build. Many of the build failures are due to outdated dependencies in Nixpkgs. The outdated packages (and the last person who updated them) are:

• [x] auto-complete: @gridaphobe
• [x] popup: @bcdarwin
• [x] yasnippet: @ardumont
• [x] deferred: @ardumont
• [x] paredit: @tohl
• [x] async: @gridaphobe
• [x] markdown-mode: @gridaphobe
• [x] dash: @aycanirican

If your name is on the list above, please try the generated expression for the listed package by _removing_ the corresponding entry from emacs-packages.nix. If the generated package works correctly, please make a PR to remove the hand-written expression so that the package will stay up-to-date in the future. If the generated package does not work correctly, please let me know.

[gridaphobe]

@ttuegel I removed my packages in b9e4cc83faf70877d90ae901214e91951fe98446, thanks!

[tohl]

OK, I will try to remove the old paredit.

What is the new way of getting emacs without any X dependencies
(e.g. for ARM, where it takes ages to compile X stuff)?
This used to work for me:

emacsWithPackagesNox = emacsWithPackages.override {emacs = self.emacs24-nox;};
emacsPackagesNox = self.emacsPackagesGen self.emacs24-nox self.emacsPackagesNox;
emacs24PackagesNgNox = self.recurseIntoAttrs (self.emacsPackagesNgGen self.emacs24-nox);
emacsNox = self.emacsWithPackagesNox [
self.emacsPackagesNox.bbdb
self.emacsPackagesNox.magit
self.emacs24PackagesNgNox.paredit
];

I tried to rewrite it as follows, but that tries to compile X
dependencies again:

emacsPackagesNox = emacsPackagesNg.override (super: self: {
emacs = emacs24-nox;
});
emacsNox = emacsPackagesNox.emacsWithPackages (epkgs: with epkgs; [
bbdb
magit
paredit
]);

Any suggestions?

Thank you,

Tomas

[aycanirican]

Removed dash in https://github.com/NixOS/nixpkgs/pull/12209

[tohl]

paredit and slime updated as requested
https://github.com/NixOS/nixpkgs/pull/12247

[ttuegel]

Thanks for the PRs! With those changes merged, we can track down the remaining failures.

[rvl]

Hi, this looks good, but how do I use package versions from melpa in preference to the elpa version? I have the following setup:

bigEmacs = with pkgs.emacs24PackagesNg; emacsWithPackages [
  company
  company-ghc
  # ... and a whole lot more
]

environment.systemPackages = [
  bigEmacs
];

Also do you need any help writing documentation?

[DamienCassou]

@rvl Thanks to your example, I wrote the following which takes everything from melpa stable.

bigEmacs = with pkgs.emacs24PackagesNg; emacsWithPackages (with melpaStablePackages; [
ag # ; search using the 'ag' command (better grep)
ace-link # ; type o in help-mode to go to a link
... ]);

[rvl]

Thanks @DamienCassou, this was very helpful.

[deepfire]

Where can one read up on the current status of this effort?

[rvl]

Hi @oxij, which of these points remain to be addressed? The release of Emacs 25.1 could be a good opportunity to fix names of attributes, etc.

[oxij]

The only issue left from the OP post is merging emacsPackages into
emacsPackagesNg. Current discussion about that happens in #18934.

[mogorman]

@oxij given the last issue has been closed can this bug be closed as well?

[jwiegley]

Just for future reference, in case others come across the ticket, here's what I've been doing lately that works well, allowing me to override everything I want to override, while preferring unstable packages to stable ones:

myPkgs = pkgs: epkgs: with epkgs;
  [ ... a list of all the Emacs packages I use ... ];

myEmacsPackageOverrides = emacs: super: self: with self;
  let withPatches = pkg: patches:
    overrideDerivation pkg (attrs: { inherit patches; }); in

  super.melpaPackages // {

  inherit (pkgs) fetchurl fetchgit fetchFromGitHub;
  inherit (pkgs) stdenv;
  inherit (stdenv) mkDerivation lib;
  inherit (lib) overrideDerivation;

  ... many packages overridden here, including Org ...
};

emacs26PackagesNg = pkgs.emacsPackagesNgGen emacs26;

customEmacs26Packages =
  emacs26PackagesNg.overrideScope (myEmacsPackageOverrides emacs26);

emacs26Env = pkgs.myEnvFun {
  name = "emacs26";
  buildInputs = [ (customEmacs26Packages.emacsWithPackages myPkgs) ];
};

[oxij]

Ok, as requested, an update on the state of this issue.

I think, nixpkgs Emacs infrastructure still has enough of problems to keep this issue open.

Two big open issues from the top of my head:

• someone just needs to put the work to do the conversion from emacsPackages and emacsPackagesNg to autogenerated packages (discussed above here, #33296 are a side-effect of the lack of this),

• emacsWithPackages needs proper conflict checks and simpler package overrides (discussed in #27083).

The biggest problem with the first issue, aside from just the sheer amount of work required, is that it needs patches to stdenv to be implemented properly. Because we currently lack a way to redirect users between package sets we end up reverting patches that try to do some of that work because people start complaining. (Too lazy to search for PRs that tried to do some of that and got reverted.)

Then it would "simply" become an issue of putting an enormous amount of work of properly merging those package sets.

As you can see from @jwiegley reports and others, we clearly also have some other issues with emacsWithPackages package overrides that I didn't even investigate.

If you look at my PRs you'll see that I'm chomping away at stdenv problems a bit by bit, so I'll get to that one eventually.
But, you see, I'm chomping at stdenv because it bites me elsewhere. Meanwhile my Emacs config is pretty much perfect, hence I only ever touch it if something breaks on update.

So, would implement stdenv warnings and package redirects? Yes, soonish.
Would do the merging of the packages sets? Unlikely. I will merge the packages I use, though.

In short, what needs to be done:

• stdenv needs lazy assert and warning systems on top of which we can implement "deprecated package" warnings. I'm working do this.

• emacsWithPackages needs a consistency check that checks that you didn't put two different versions of a package into a single env. I can do this.

• emacsWithPackages and package set overriding problems need to be investigated and fixed. I didn't even think about this.

• Maybe we really should just properly document the intended overriding method and disable direct access to package sets as @ttuegel proposed in #27083 as it looks more and more attractive to me as I think about it (much less work). But then there's a question of pushing overrideScope use to the whole of nixpkgs or being the strange kid on the block.

• Autogenerated packages that miss their binaries (see #33296) need to be fixed. This should be easy to fix, but I just didn't come around to doing it.

After stdenv issue gets fixed:

• All emacsPackages and emacsPackagesNg packages need to be replaced with or ported to (and then properly tested) autogenerated infrastructure or, if that is impossible, to emacsPackagesNg infrastructure. Old versions should be frozen, deprecated and then removed after a grace period.

• Packages with special considerations like optional dependencies and use flags, e.g. org-mode, need to be considered on case-by-case basis.

All of that needs to be done with separate commits for easy reverting in case things break (and they will, as we have seen with the previous attempts).

[periklis]

@oxij & @ttuegel: How often do we actually generate the melpa/melpaStable/elpa package sets?

[ttuegel]

There is not a regular schedule. There was an unintended hiatus a few months ago because package-build changed in a way that broke our updater. Currently, the updater is again broken by upstream changes.

[matthew-piziak]

Does anyone have pdf-tools successfully working with Emacs under NixOS? That's related to the emacsPackagesNg refactor, correct?

[jwiegley]

I override emacsPackagesNg to add this:

    pdf-tools = lib.overrideDerivation super.pdf-tools (attrs: {
      src = fetchFromGitHub {
        owner = "politza";
        repo = "pdf-tools";
        rev = "60d12ce15220d594e8eb95f4d072e2710cddefe0";
        sha256 = "1s8zphbd7k1ifdlisy894cg4mrkiq1rl2qk8x10njp1i596hz1fm";
        # date = 2018-04-29T18:31:04+02:00;
      };
    });

And then I build the helper tool using this overlay:

self: super: {

pdf-tools-server = with self; super.stdenv.mkDerivation rec {
  pname = "emacs-pdf-tools-server";
  version = "0.80";
  name = "${pname}-${version}";

  src = super.fetchFromGitHub {
    owner = "politza";
    repo = "pdf-tools";
    rev = "60d12ce15220d594e8eb95f4d072e2710cddefe0";
    sha256 = "1s8zphbd7k1ifdlisy894cg4mrkiq1rl2qk8x10njp1i596hz1fm";
    # date = 2018-04-29T18:31:04+02:00;
  };

  buildInputs = [
    clang gnumake automake autoconf pkgconfig libpng zlib poppler
  ];

  patches = [ ./emacs/patches/pdf-tools.patch ];

  preConfigure = ''
    cd server
    ./autogen.sh
  '';

  installPhase = ''
    echo hello
    mkdir -p $out/bin
    cp -p epdfinfo $out/bin
  '';

  meta = with stdenv.lib; {
    homepage = https://github.com/politza/pdf-tools;
    description = "Emacs support library for PDF files";
    maintainers = with maintainers; [ jwiegley ];
    license = licenses.gpl3;
    platforms = platforms.unix;
  };
};

}

Which needs this patch:

diff --git a/server/poppler-hack.cc b/server/poppler-hack.cc
index 427f9df..ca92716 100644
--- a/server/poppler-hack.cc
+++ b/server/poppler-hack.cc
@@ -54,7 +54,7 @@ GType poppler_annot_markup_get_type (void) G_GNUC_CONST;
   // This function does not modify its argument s, but for
   // compatibility reasons (e.g. getLength in GooString.h before 2015)
   // with older poppler code, it can't be declared as such.
-  char *_xpoppler_goo_string_to_utf8(/* const */ GooString *s)
+  char *_xpoppler_goo_string_to_utf8(const GooString *s)
   {
     char *result;

@@ -88,7 +88,7 @@ GType poppler_annot_markup_get_type (void) G_GNUC_CONST;
   // Set the rectangle of an annotation.  It was first added in v0.26.
   void xpoppler_annot_set_rectangle (PopplerAnnot *a, PopplerRectangle *rectangle)
   {
-    GooString *state = (GooString*) a->annot->getAppearState ();
+    const GooString *state = (GooString*) a->annot->getAppearState ();
     char *ustate = _xpoppler_goo_string_to_utf8 (state);

     a->annot->setRect (rectangle->x1, rectangle->y1,

[matthew-piziak]

This looks incredibly helpful, thank you! Is there somewhere that documents how to correctly override emacsPackagesNg, so that I can apply the pdf-tools = lib.overrideDerivation expression in the right place? Sorry, I'm quite green at NixOS!

[clhodapp]

One thing that I observe that at least seems to be super-off is that the "melpaStable" package set appears to close over unstable for its dependencies. That is... if you install an emacs package from Melpa Stable, all of the dependencies of that package seem to get pulled from the latest unstable.

What's worse: it would seem that if you happen to explicitly declare a direct dependency on whatever the depended-upon package is in the above situation, you actually get TWO versions of that packages on the load path, one stable and one unstable.

[matthew-piziak]

I ended up installing these dependencies…

  environment.systemPackages = (
    with pkgs; [
      autoconf
      gcc
      libpng
      pcre2
      pkgconfig
      poppler
      poppler_gi
      stdenv
      zlib
    ]
  );

…and letting Emacs' pdf-tools auto-installation mechanic take care of it.

  (use-package pdf-tools
    :straight t)

  (pdf-tools-install)

  (require 'let-alist)
  (require 'pdf-tools)
  (require 'pdf-occur)
  (require 'pdf-view)
  (require 'pdf-history)
  (require 'pdf-links)
  (require 'pdf-outline)
  (require 'pdf-annot)
  (require 'pdf-sync)

[ttuegel]

if you install an emacs package from Melpa Stable, all of the dependencies of that package seem to get pulled from the latest unstable.

This should not be a problem since we switch to using Melpa by default. (Melpa Stable is too old to really be useful.)

it would seem that if you happen to explicitly declare a direct dependency on whatever the depended-upon package is in the above situation, you actually get TWO versions of that packages on the load path, one stable and one unstable.

This is a problem we share in common with all interpreters. To mitigate the issue, I have done my best to make it difficult to declare direct dependencies, but Nix of course makes that difficult.

[clhodapp]

@ttuegel

This should not be a problem since we switch to using Melpa by default. (Melpa Stable is too old to really be useful.)

It's a problem in the sense that I, as a user, would expect emacsPackagesNg.melpaStablePackages to be a mostly-closed (maybe some dependency on GNU ELPA) set of packages based around MELPA Stable. It's quite possible that MELPA Stable itself is completely useless in general. I was actually just giving it a try for the first time so I don't know. It seems to me that the current setup for it in nixpkgs is broken by design, regardless, since it seems almost assured to generate brokenness and duplication on the load path & general nondeterminacy. No promises that I'll be technically able but I can maybe try my hand at fixing it or removing it. Would that be appreciated?

This is a problem we share in common with all interpreters. To mitigate the issue, I have done my best to make it difficult to declare direct dependencies, but Nix of course makes that difficult.

Perhaps we're talking past each other, since at least _some_ direct dependency seems necessary to produce a working emacs install with packages at all and it's honestly not that hard to create one:

emacsWithPackages (epkgs:
  [
    epkgs.melpaStablePackages.ivy
  ]
)

[ttuegel]

It's a problem in the sense that I, as a user, would expect emacsPackagesNg.melpaStablePackages to be a mostly-closed (maybe some dependency on GNU ELPA) set of packages based around MELPA Stable.

MELPA Stable is not closed itself: Stable packages can depend on un-Stable packages. So, it is not possible for us to provide a closed package set because unfortunately none exists.

Perhaps we're talking past each other, since at least _some_ direct dependency seems necessary to produce a working emacs install with packages at all and it's honestly not that hard to create one:

Yes, I thought you had something else in mind. To follow from your example, this would produce two versions on load-path:

.nix emacsWithPackages (epkgs: [ epkgs.melpaStablePackages.ivy epkgs.melpaPackages.ivy ]

We should detect that multiple packages with the same ename are on load-path, and fail the build in this case. We can reduce the likelihood of this happening by removing the nested package sets, i.e. not have epkgs.melpaStablePackages.ivy and epkgs.melpaPackages.ivy, but only epkgs.ivy.

[clhodapp]

MELPA Stable is not closed itself: Stable packages can depend on un-Stable packages. So, it is not possible for us to provide a closed package set because unfortunately none exists.

Whelp... wow then perhaps it really _is_ completely useless.

[matthew-piziak]

My solution no longer works. Does anyone have pdf-tools configured in their configuration.nix?

[matthew-piziak]

With @jwiegley's solution I get g++: error: unrecognized command line option '-stdlib=libstdc++'; did you mean '-static-libstdc++'?

[matthew-piziak]

If I use a more recently Clang I get

poppler-hack.cc: In function 'char* _xpoppler_goo_string_to_utf8(const GooString*)':
poppler-hack.cc:65:30: error: 'const class GooString' has no member named 'getCString'; did you mean 'GooString'?
       result = g_convert (s->getCString () + 2,
                              ^~~~~~~~~~
                              GooString
make[1]: *** [Makefile:565: epdfinfo-poppler-hack.o] Error 1
make[1]: Leaving directory '/tmp/nix-build-emacs-pdf-tools-server-0.80.drv-0/source/server'
make: *** [Makefile:366: all] Error 2

Which suggests the patch isn't taking, despite me seeing applying patch /nix/store/mlv9a4nfaa6cpjdna8ggw8bnyyd3zykh-pdf-tools.patch.

[matthew-piziak]

When I upgrade to af1a5949c2dae59ffcbcf21cc4299fa2fc57ce72 I get /nix/store/n2bbnm6kr9pd5qx484r2gqhpxf637vss-libkrb5-1.15.2/lib/libgssapi_krb5.so.2: undefined reference to glob@GLIBC_2.27. :confused:

[matthew-piziak]

Whoops, I was pulling unstable packages into buildInputs. I'll clean it up and post a complete solution tomorrow.

[matthew-piziak]

This is what I ended up with: https://gist.github.com/matthew-piziak/d7508c7d78fc77cebd170e9400fb4a9c

[adisbladis]

With the work done in https://github.com/NixOS/nixpkgs/pull/59189, https://github.com/NixOS/nixpkgs/pull/65874 and https://github.com/NixOS/nixpkgs/pull/66301 (and a lot of hard work done by a number of people) I think that the emacs infra situation is starting to look good.

@oxij I would love it if you could add any actionable things you'd still like addressed in https://github.com/NixOS/nixpkgs/issues/66303

[stale[bot]]

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:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[adisbladis]

I'm gonna go ahead and close this issue.
Feel free to report any remaining items that need to be worked on in separate issues with a clear scope. It's very hard to gauge from reading this thread what is still not addressed.