bug#51258: emacs-next/git-master broken due to pdmp file naming changes

[Paxton Evans <paxton@riseup.net>]

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