emacs: set 29 as default version and remove 28

[jian-lin]

Description of changes

follow-up of #247357
related #247627

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

Priorities

Add a 👍 reaction to pull requests you find important.

[jian-lin]

Result of nixpkgs-review pr 270558 run on x86_64-linux 1

12 packages marked as broken and skipped:

• cedille
• emacsPackages.cedille
• emacsPackages.eterm-256color
• emacsPackages.instapaper
• emacsPackages.magit-stgit
• emacsPackages.melancholy-theme
• emacsPackages.nemerle
• emacsPackages.per-buffer-theme
• emacsPackages.perl-completion
• emacsPackages.rcirc-menu
• emacsPackages.shm
• emacsPackages.sql-presto

7 packages failed to build:

• auctex
• auctex.tex
• emacsPackages.anki-editor-view
• emacsPackages.emacspeak
• emacsPackages.fixed-page-mode
• emacsPackages.flycheck-cfn
• emacsPackages.ox-leanpub

6067 packages built:

[jian-lin]

About build failure on x86_64-linux:

• AUCTeX 13.2 can1 be built using Emacs 29. However, bumping to that version causes a new build error. Help is welcome since I am not familiar with AUCTeX. Note that it is pkgs.auctex, not pkgs.emacs.pkgs.auctex. I am not sure if it is necessary to have two separate auctex packages.
• emacspeak can be built using Emacs 29 since 57.0. See emacsPackages.emacspeak: 56.0 -> 58.0 #270555.
• anki-editor-view, fixed-page-mode, flycheck-cfn and ox-leanpub fail to build because of wrong hash of src. These are not caused by this PR.

[slotThe]

• AUCTeX 13.2 can1 be built using Emacs 29. However, bumping to that version causes a new build error. Help is welcome since I am not familiar with AUCTeX. Note that it is pkgs.auctex, not pkgs.emacs.pkgs.auctex. I am not sure if it is necessary to have two separate auctex packages.

FWIW, the following works for me:

diff --git a/pkgs/tools/typesetting/tex/auctex/default.nix b/pkgs/tools/typesetting/tex/auctex/default.nix
index b0fcc3b4d476..bd46955578d4 100644
--- a/pkgs/tools/typesetting/tex/auctex/default.nix
+++ b/pkgs/tools/typesetting/tex/auctex/default.nix
@@ -4,14 +4,14 @@ let auctex = stdenv.mkDerivation ( rec {
   # Make this a valid tex(live-new) package;
   # the pkgs attribute is provided with a hack below.
   pname = "auctex";
-  version = "12.3";
+  version = "13.2";
   tlType = "run";

   outputs = [ "out" "tex" ];

   src = fetchurl {
     url = "mirror://gnu/${pname}/${pname}-${version}.tar.gz";
-    hash = "sha256-L9T+MLaUV8knf+IE0+g8hHK89QDI/kqBDXREBhdMqd0=";
+    hash = "sha256-Hn5AKrz4RmlOuncZklvwlcI+8zpeZgIgHHS2ymCUQDU=";
   };

   buildInputs = [
@@ -22,6 +22,7 @@ let auctex = stdenv.mkDerivation ( rec {

   preConfigure = ''
     mkdir -p "$tex"
+    export HOME=$TMPDIR
   '';

   configureFlags = [

[jian-lin]

Thanks @slotThe. I created #270810.

[Atemu]

I don't think we should be removing 28 already. Let's do that closer to next release.

While we should obviously not carry around old baggage forever, having the two most recent Emacs versions at once is not a huge burden. 28 certainly doesn't have a rotten smell yet if you know what I mean.

The 29 by default bump should have probably already happened. Whoops. cc @figsoda @RaitoBezarius do you think we can smuggle that into the release still or is it too late?

This needs a release note either way.

[vcunat]

40k rebuilds on nixpkgs master? That's too much, right? It's certainly not just emacsPackages.

[Atemu]

Hm, the eval report only lists emacsPackages.

Where are you seeing 40k packages? Is that one arch or multiple?

[vcunat]

All platforms. And I see I counted previous eval as well. So "only" over 36k new ones over a few hours of nixpkgs master, but maybe several different pull requests added up in there: https://hydra.nixos.org/eval/1802673

[vcunat]

I mean, maybe Hydra is slow, but I think adding 40k builds like this (then replicated in staging-next, etc.) will delay the work by at least one full day.

[vcunat]

Even with cheap builds its speed is 1-2 build steps per second over longer term.

[mweinelt]

Reverted in #272785. Please resubmit into staging.

[jian-lin]

Created #272822 which retargets this to staging.

[ckiee]

I know I'm coming in very late here, but the last working build of nix-doom-emacs is on Emacs 28 and 29 does not build unfortunately. I depend on this for my day-to-day, some others probably do too though that number is dwindling.

I'm not sure if this should be a blocker, but there it is.

(For me personally I guess I'd just revert in my fork or overlay and it's whatever. But it does break the already very broken NDE even more.)

[jian-lin]

For keeping the old 28, a natural question is how long it should be kept.

[Atemu]

Note that these *24k builds are all tiny; usually just one or two files to be compiled each.

On my dog slow 2.2GHz 10W Celeron J4105, the randomly chosen emacs.pkgs.smalltalk-mode takes 10s (including eval) and a few other random packages I tried were in the same ballpark.

emacs.pkgs.magit and emacs.pkgs.helm are about the largest emacs packages I can think of and these two only take 1-2m to build. On my dog slow Celeron mind you.

A bit of back of the napkin math tells me that this extremely slow machine by itself would take about half a day to build all emacsPackages for its platform. I highly doubt this could block hydra for anything more than a few hours.

[vcunat]

I posted 1-2 build steps per second max. 24k on trunk, all again on staging-next, and half of it cached to trunk-combined. That's more than half a day on my napkin.

[Atemu]

What exactly do you mean by "build steps"? Is that just the emacsPackages or also including the 16k unrelated packages?

[vcunat]

It's one /nix/store/*.drv (I think).

[Atemu]

Is that just the emacsPackages or also including the 16k unrelated packages?

[vcunat]

So, simple example: 24k with master and staging-next, one full build per second = over 13 hours.

24000*2/3600

[ckiee]

For keeping the old 28, a natural question is how long it should be kept.

( ~ @jian-lin )

Until it causes trouble and then it can get sniped away? Like on first signs of Problems arising from it. I'm not sure.

[Atemu]

So, simple example: 24k with master and staging-next, one full build per second = over 13 hours.

24000*2/3600

I'd just like to know whether the one build/s metric was just for the emacsPackages or whether it was for the entire 40k builds that included 16k non-emacs packages. I'm asking because I'd expect those to take 10-100x as long as your typical emacs package would, thus massively skewing the average.
For example, if it took 3h to build all 24k emacsPackages and 10h to build the 16k other rebuilds, that'd still be 13h in total but the cause wouldn't really be the emacsPackages in that hypothetical scenario.

I find it kind of hard to believe that, with all its parallelism, the entire build farm takes about as long to build four platforms as my dog slow NAS CPU needs to build one platform.
Since separate platforms are parallel to build by definition, that must mean that one platform must have been progressing at the speed of a 10W Celeron. That doesn't seem right to me.

---

@ckiee I'd recommend you to contribute to the discussion on the new PR.

[vcunat]

1-2 build steps per second are empiric maximum over long term. For any kind of builds apparently. (i.e. I've seen no period longer than an hour or two where Hydra exceeded that)

[vcunat]

You know, the central place of Hydra is in Germany, but the S3 is in USA and builders are often in Finland I think or other non-Germany... i.e. the efficiency of cheap builds is nowhere near to what you get at home, and especially NixOS tests (with all the /etc/foo derivations) are very painful.

[vcunat]

I can't have numbers for hydra.nixos.org just for emacs packages. We'd have to stop building everything else and start building just those (for some time).

[Atemu]

I can't have numbers for hydra.nixos.org just for emacs packages. We'd have to stop building everything else and start building just those (for some time).

Hm, would it be possible to do a rebuild of all emacs packages (i.e. no-op change in emacsPackages builder) when there's relatively little else going on?
That way we could take end time - start time and divide by the amount of builds to get a rather good idea how many emacs package builds/s hydra can do.

[vcunat]

Theoretically yes, but it's again like... commits are waiting in staging* for a couple weeks and I should tell those people that they need to wait some more because I won't trigger those builds yet?

[vcunat]

So possible, but at least right now I'm not perfectly comfortable with it.

[mweinelt]

I think h.n.o is pretty busy these days through keeping up with the release branches and staging cycles.

There are regularly bigger PRs that get tested on hydra, but their feedback cycles are a few days long.

I'm running python-updates on my private infrastructure, because I can't get enough feedback from h.n.o fast enough to finish it in a meaningful timeframe.

[Atemu]

Oh, this wasn't a "we need to know this right now" request. As I said, this would necessarily be run when there's little else going on, so if there's anything else in need to be built, it's probably a higher priority than this.