--- Begin Message ---
|
Subject: |
emacs-next/git-master broken due to pdmp file naming changes |
|
Date: |
Sun, 17 Oct 2021 14:20:52 -0700 |
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
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: [PATCH v3] gnu: emacs: Handle pdump filenames that contain a fingerprint |
|
Date: |
Sun, 24 Oct 2021 10:52:30 +0200 |
|
User-agent: |
Evolution 3.34.2 |
Hi,
Am Samstag, den 23.10.2021, 21:00 -0400 schrieb
Morgan.J.Smith@outlook.com:
> From: Morgan Smith <Morgan.J.Smith@outlook.com>
>
> * gnu/packages/emacs.scm (emacs) [restore-emacs-pdmp]: Change regex
> to handle
> filenames that have a fingerprint in them. Remove #t at the end of
> the
> phase. Don't bother deleting the old files because rename will
> overwrite them
> anyways.
> ---
>
> find-files does sort its return so my previous 2 patches probably
> work great regardless of the number of pdmps we encounter (which will
> only ever be 1 anyways).
You are completely right, thanks for pointing that out. I've pushed an
adjusted v2 with updated comments and everything. I also verified that
emacs-next could be updated with a little hacking around patches that
don't apply.
Thanks!
--- End Message ---