Hi Rutherther,
Rutherther <[email protected]> writes:
Hi Ian,
This will map the packages in packages list, but it doesn't have
to be
all packages in the profile. The packages also come from
services
extending the home-profile-service-type. I can't really think of
an
easy way to map it over all packages other than going through
all the
service records and mapping all fields (people already wrote
code for
that). And even that won't work if packages are hard coded
somewhere.
Hmm, yeah.
guix home: error: profile contains conflicting entries for
emacs-s
guix home: error: first entry: [email protected]
/gnu/store/gv32m8dn3l7f3678vy2v4dy5kzk7a7q6-emacs-s-1.13.0
guix home: error: ... propagated from [email protected]
guix home: error: ... propagated from
[email protected]
guix home: error: second entry: [email protected]
/gnu/store/vgs5nsgjf2n5x8f3bfavqxq6srnmz2fk-emacs-s-1.13.0
guix home: error: ... propagated from [email protected]
The second package, the one propagated by emacs-lemon, is the
untransformed package:
$ guix build emacs-s
/gnu/store/vgs5nsgjf2n5x8f3bfavqxq6srnmz2fk-emacs-s-1.13.0
What am I missing? Does `package-mapping' not change
propagated-inputs? Does anyone have a working setup they can
share?
It definitely does, otherwise you wouldn't get any of the
propagated inputs changed.
Are you sure you don't have the emacs package emacs-lemon added
from any of the services?
Definitely not.
I got a little further on this, but have run into new and exciting
problems. The package conflict was becasue other Emacs packages
were getting added in after the transformation, in a part of my
home-configuration I didn’t share. Oops.
Making sure I transformed packages after everything was added, I
got:
guix/packages.scm:1546:23: In procedure struct-vtable: Wrong
type argument in position 1 (expecting struct): (#<package
[email protected] gnu/packages/version-control.scm:613 7fd120f45420>
"send-email")
Which is because I have `(,git "send-email") in my package list,
which package-mapping doesn’t understand. This is pretty
surprising to me, and quite annoying to work around; I came up
with this:
(define (with-full-emacs pkg)
(if (and (package? pkg)
(eq? (package-build-system pkg)
emacs-build-system))
(package
(inherit pkg)
(arguments
(ensure-keyword-arguments
(package-arguments pkg)
(list #:emacs emacs))))
pkg))
(define (+emacs-native-comp home-env)
(let* ((xform (package-mapping with-full-emacs #:deep? #t)))
(letrec ((xform'
(lambda (pkg-or-list)
(cond
((package? pkg-or-list) (xform pkg-or-list))
((list? pkg-or-list)
(map xform' pkg-or-list))
(else pkg-or-list)))))
(home-environment
(inherit home-env)
(packages
(map xform' (home-environment-packages
home-env)))))))
That seems to mostly do the right thing, but the reconfigure
fails:
sha256 hash mismatch for
/gnu/store/9kgk2qvqbp2f6krarma86hhk7yl9s8qf-adaptive-wrap-0.8.tar:
expected hash:
1gs1pqzywvvw4prj63vpj8abh8h14pjky11xfl23pgpk9l3ldrb0
actual hash:
1dz5mi21v2wqh969m3xggxbzq3qf78hps418rzl73bb57l837qp8
I was initially thinking this was the transformation going wrong
somehow, but the package is actually broken and doesn’t build, but
I guess substitutes have been hiding this. The original 0.8
release was on 2024-01-11[1], but was overwritten on
2024-03-31[2], so the hash no longer matches. I compared the
substitue to the current tarball and only see differences in
adaptive-wrap-pkg.el.
I’ll send a patch for this package and try again once it lands.
This reinforces my belief that we shouldn’t build Emacs packages
from M/ELPA tarballs.
-- Ian
[1]:
https://web.archive.org/web/20210618050357/https://elpa.gnu.org/packages/adaptive-wrap.html
[2]:
https://web.archive.org/web/20250516050146/https://elpa.gnu.org/packages/adaptive-wrap.html
