Re: [bug#42738] [PATCH v4] gnu: emacs: Update to 27.1.
Mark H Weaver writes: > Agreed, or perhaps 'emacs' itself should have been updated on a separate > branch. +1 for WIP-emacs branch in future. Brett Gilio
Re: [bug#42738] [PATCH v4] gnu: emacs: Update to 27.1.
Hi Ludovic,
Ludovic Courtès wrote:
> Mark H Weaver skribis:
>
>> (define-public emacs-next
>> (let ((commit "c36c5a3dedbb2e0349be1b6c3b7567ea7b594f1c")
>> (revision "0")
>> (emacs-version "27.0.91"))
>> (package
>> (inherit emacs)
>> (name "emacs-next")
>> (version (git-version emacs-version revision commit))
>> (source
>>(origin
>> (inherit (package-source emacs))
>> (method git-fetch)
>> (uri (git-reference
>>(url "https://git.savannah.gnu.org/git/emacs.git;)
>>(commit commit)))
>
> This can be handled with ‘--with-git-url’.
I think that wouldn't work in this case, because we also need to
preserve the existing 'patches' and 'snippet' fields, which I arranged
to inherit above via (inherit (package-source emacs)). That probably
deserves a comment, since it's easily overlooked.
>> (sha256
>> (base32 "0mlrg2npy1r79laahkgzhxd1qassfcdz8qk1cpw7mqgf6y5x505h"))
>> (file-name (git-file-name name version
>> (native-inputs
>>`(("autoconf" ,autoconf) ; needed when building from trunk
>> ,@(package-native-inputs emacs)))
>
> For this, we’d need a new ‘--with-extra-input’ package transformation
> option or similar. That way, we wouldn’t even need an ‘emacs-next’
> package: people would just run
>
> guix install emacs --with-git-url=… --with-extra-input=autoconf
There's also the 'native-search-paths' field, which cannot simply be
inherited because of the version number embedded within EMACSLOADPATH.
This particular issue could be avoided if the 'native-search-paths'
field were a function of the version number, but that raises migration
issues and I'm not sure it's worth it.
What do you think?
Best regards,
Mark
Re: [PATCH v4] gnu: emacs: Update to 27.1.
Hi Morgan, Morgan Smith wrote: > It seems I am taking some credit for Jack Hill's patch. I simply took > Jack's patch (labeled as patch v3 in the debbugs thread) and attempted > to build it with my personal config. Indeed, I see that now. Sorry for the mistake. I suppose it happened because it was presented to me as "the patch Morgan submitted", but it would have been better if I had taken the time to read the bug report more carefully. Also, I regret if my comments on the preliminary patch made anyone feel badly. To be clear, there's no shame in submitting an unfinished patch for review. On the contrary, it is a *very* useful contribution. In this case, it makes sense to start by updating the main 'emacs' package, and to worry about the other variants later. There's no fault in that. The only fault here lies with me. I should have looked more carefully for prior work, and I probably also pushed it prematurely. > (Also just my 2 cents, we should have upgraded emacs-next to 27.1 and > only upgraded emacs a week later. Emacs deserves more care than most > packages due to its dependence on so many other packages. Not trying to > shame anyone, just something to think of for next time.) Agreed, or perhaps 'emacs' itself should have been updated on a separate branch. In the past, when this was a smaller community and there were far fewer emacs packages in Guix, I did major updates of Emacs a few times without causing any obvious problems, but that was a different time. It's also possible that Emacs 27 was a more disruptive update than usual. Thanks very much for your comments and contributions. Best regards, Mark
Re: [PATCH v4] gnu: emacs: Update to 27.1.
Mark H Weaver writes: [...] > Pierre Neidhardt wrote: >> I confirm that with Mark's commit >> emacs-clojure-mode I've filed bug#43090 with a trivial patch for emacs-clojure-mode, no need to revert Emacs 27.1 for this bug IMHO. > and emacs-elisp-refs are also broken. is there a specific bug report for this plz? there is also bug#43093 for emacs-ess can we coordinate our efforts in order to avoid to revert emacs 27.1 by tagging relevant [1] open emacs packages bugs as critical? [2] [...] Thanks! Gio' [1] can we define "relevant" as: all bugs that breaks a previously compiling emacs package? [2] https://issues.guix.gnu.org/search?query=subject%3Aemacs+is%3Aopen+severity%3Acritical -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: merge wip-haskell?
Nice! Thanks Tim!
Re: merge wip-haskell?
Hi again, Timothy Sample writes: > I‘ll take a look at PureScript and check Elm, since maybe the Agda fix > will work for them. I’m not sure about Idris – it needs a bit more > effort. Good news! Elm and PureScript are fine, and I just pushed a fix for Idris: 5aaa1995922285d53a97824f2b83bdb71ec9fdd0. -- Tim
Re: [bug#42738] [PATCH v4] gnu: emacs: Update to 27.1.
Hi,
Mark H Weaver skribis:
> (define-public emacs-next
> (let ((commit "c36c5a3dedbb2e0349be1b6c3b7567ea7b594f1c")
> (revision "0")
> (emacs-version "27.0.91"))
> (package
> (inherit emacs)
> (name "emacs-next")
> (version (git-version emacs-version revision commit))
> (source
>(origin
> (inherit (package-source emacs))
> (method git-fetch)
> (uri (git-reference
>(url "https://git.savannah.gnu.org/git/emacs.git;)
>(commit commit)))
This can be handled with ‘--with-git-url’.
> (sha256
> (base32 "0mlrg2npy1r79laahkgzhxd1qassfcdz8qk1cpw7mqgf6y5x505h"))
> (file-name (git-file-name name version
> (native-inputs
>`(("autoconf" ,autoconf) ; needed when building from trunk
> ,@(package-native-inputs emacs)))
For this, we’d need a new ‘--with-extra-input’ package transformation
option or similar. That way, we wouldn’t even need an ‘emacs-next’
package: people would just run
guix install emacs --with-git-url=… --with-extra-input=autoconf
OTOH it’s more typing and not necessarily obvious…
Ludo’.
Re: Dealing with foreign distros without nscd
Hi! Ricardo Wurmus skribis: > Ludovic Courtès writes: > >> The workaround I found is to add ‘sssd’ to the pack, like so: >> >> guix pack -RR -S /lib=lib -S /bin=bin sssd guile >> >> That way, on the other machine, you can set LD_LIBRARY_PATH such that >> Guix’ libnss_sss.so gets loaded: >> >> tar xf /path/to/pack.tgz >> LD_LIBRARY_PATH=$PWD/lib ./bin/guile -c '(pk (getpw (getuid)))' >> >> It works! However, if people have ideas of less arcane workarounds, I’m >> interested. > > Interesting! I wonder if this really is a general solution or if it > only works under special circumstances (like the cluster node using sssd > already). Will, for example, accounts that are managed via Active > Directory / LDAP be visible if all we do is preload the Guix sssd > libraries? In general, you have to put the modules /etc/nsswitch.conf refers to in $LD_LIBRARY_PATH. The example above works for ‘sss’ but you would do something similar for ‘mdns’, ‘ldap’, or whatever. It’s clunky because you have to know beforehand, when you make the pack, what nsswitch.conf requires. Ludo’.
