As of Emacs commit e81f1faca4382ed5c8f15fec84fb7c900a5468f9, building emacs-next with the git-master branch will cause some problems on Guix. The "emacs-next" build itself will work without any errors, but it will complain whenever you try run it:
> emacs: could not load dump file > "/gnu/store/a5bx5v96snvgiv9r1b7i1im5ccn5mz54-emacs-next-git.master/libexec/emacs/29.0.50/x86_64-pc-linux-gnu/emacs-66e6890a5565f2bed1ee56075d21e0051d891a59200cdd092c0946403fb84ac2.pdmp": > not a dump file This will also cause new builds of packages that use emacs-next/git-master as an input to fail as well, with a version of the same error. Here's a (failed) build log for emacs-pdf-tools: > [top part snipped] > > make[1]: Leaving directory > '/tmp/guix-build-emacs-pdf-tools-0.90-2.5f77dae.drv-0/source/server' > phase `install' succeeded after 0.3 seconds > starting phase `patch-shebangs' > phase `patch-shebangs' succeeded after 0.0 seconds > starting phase `strip' > stripping binaries in > "/gnu/store/swfjir05k1bg22l50yawhibbv0y5qhr9-emacs-pdf-tools-0.90-2.5f77dae/bin" > with "strip" and flags ("--strip-debug" "--enable-deterministic-archives") > phase `strip' succeeded after 0.0 seconds > starting phase `validate-runpath' > validating RUNPATH of 1 binaries in > "/gnu/store/swfjir05k1bg22l50yawhibbv0y5qhr9-emacs-pdf-tools-0.90-2.5f77dae/bin"... > phase `validate-runpath' succeeded after 0.0 seconds > starting phase `validate-documentation-location' > phase `validate-documentation-location' succeeded after 0.0 seconds > starting phase `delete-info-dir-file' > phase `delete-info-dir-file' succeeded after 0.0 seconds > starting phase `patch-dot-desktop-files' > phase `patch-dot-desktop-files' succeeded after 0.0 seconds > starting phase `install-license-files' > installing 0 license files from '.' > phase `install-license-files' succeeded after 0.0 seconds > starting phase `reset-gzip-timestamps' > phase `reset-gzip-timestamps' succeeded after 0.0 seconds > starting phase `compress-documentation' > phase `compress-documentation' succeeded after 0.0 seconds > starting phase `enter-lisp-dir' > phase `enter-lisp-dir' succeeded after 0.0 seconds > starting phase `emacs-patch-variables' > emacs: could not load dump file > "/gnu/store/rv72rvqa3vh2vw7jpkm3d9ww0xb4ibxv-emacs-next-git.master/libexec/emacs/29.0.50/x86_64-pc-linux-gnu/emacs-4588128eef9937d195927b0cccee280697619db43041dd08b620788b8dd59b77.pdmp": > not a dump file I think this is because of some recent changes made to the naming of the Emacs pdmp file in the master branch. Previously, it just made a file called "emacs.pdmp" but now it appends the version or commit hash, i.e. "emacs-4588128eef9937d195927b0cccee280697619db43041dd08b620788b8dd59b77.pdmp". This new naming scheme started with Emacs commit e81f1faca4382ed5c8f15fec84fb7c900a5468f9. This might be confusing Guix's Emacs package recipe, which has a regexp that simply looks for "emacs.pdmp" when it does some cleanup after building Emacs. guix/gnu/packages/emacs.scm:182 and following: > (lambda* (#:key outputs target #:allow-other-keys) > (let* ((libexec (string-append (assoc-ref outputs "out") > "/libexec")) > ;; each of these find-files should return one file > (pdmp (find-files libexec "^emacs\\.pdmp$")) > (pdmp-real (find-files libexec > "^\\.emacs\\.pdmp-real$"))) So I think that regexp might need to be changed a little to accommodate those recent Emacs changes. That's as far as I'm able to get with it, though, as I'm not very good at Guile or regexps. -paxton