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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paxton Evans <paxton <at> riseup.net>
Subject: bug#51258: closed (Re: [PATCH v3] gnu: emacs: Handle pdump
 filenames that contain a fingerprint)
Date: Sun, 24 Oct 2021 08:53:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

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

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 51258 <at> debbugs.gnu.org.

-- 
51258: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=51258
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Morgan.J.Smith <at> outlook.com, 51258-done <at> debbugs.gnu.org, paxton <at> riseup.net
Subject: Re: [PATCH v3] gnu: emacs: Handle pdump filenames that contain a
 fingerprint
Date: Sun, 24 Oct 2021 10:52:30 +0200

Hi,

Am Samstag, den 23.10.2021, 21:00 -0400 schrieb
Morgan.J.Smith <at> outlook.com:
> From: Morgan Smith <Morgan.J.Smith <at> 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!

[Message part 3 (message/rfc822, inline)]

From: Paxton Evans <paxton <at> riseup.net>
To: bug-guix <at> gnu.org
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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.