Re: [PATCH v4] gnu: emacs: Update to 27.1.
Hello!
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. I noticed that it wouldn't build
properly since emacs wanted libxaw and emacs-no-x wanted some image
librarys (libtiff, libjpeg, etc). The only contributions I made, where
to add libxaw to emacs and to add the configure flags to emacs-no-x. I
made these changes and posted them as patch v4. However, the patch Mark
committed does build for me so you can ignore my contributions (which
weren't well thought out to begin with).
The rest of your questions should be directed to Jack.
(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.)
Thanks,
Morgan
On 8/28/20 2:57 PM, Mark H Weaver wrote:
> Looking now, here are the main differences I see between our patches:
>
> * I found that I had to remove the 'restore-emacs-pdump' phase from most
> of the other emacs variants, namely the ones that use
> 'gnu-build-system', because otherwise the inherited
> 'restore-emacs-pdump' phase would fail. Morgan's patch seems not to
> consider most of the other emacs variants, and I'm not sure if they
> were tested. I briefly tested all of them except for 'guile-emacs'.
>
> * Morgan removed the snippet code that deletes "eshell/esh-groups.el",
> whereas I replaced it with a call to 'find-files' to remove it only if
> present, as the previous comment suggested. I'm not sure if this is
> still needed, though.
>
> * Morgan's patch adds "libxaw" to inputs and "texinfo" to native-inputs.
> What's the rationale for these?
>
> * I added 'pango' to the inputs, because the Emacs NEWS mentioned that
> Pango was used for font rendering when "--with-cairo" is used.
> However, it may be that "pango" finds its way into the build inputs
> without being explicitly mentioned.
>
> * Morgan removed 'libxft' from the inputs of 'emacs', whereas I didn't.
> This was an oversight on my part. However, if we remove it, it's
> possible that we might need to add it back to 'emacs-no-x-toolkit'.
> The references that I see to Pango in the Emacs code are within
> "#ifdef HAVE_GTK3".
>
> * In 'emacs-no-x', my patch removes the new graphical library inputs
> (cairo, pango, and harfbuzz) and the "--with-cairo" flag, whereas
> Morgan's patch leaves "cairo" and "harfbuzz" as inputs, and overwrites
> the inherited configure-flags to be precisely ("--with-jpeg=no"
> "--with-gif=no" "--with-tiff=no"), apparently discarding the inherited
> "--with-modules" and "--disable-build-details" flags.
>
> * Morgan made 'emacs-wide-int' into a deprecated package, whereas I
> thought that it might still be useful. My rationale was this: from a
> brief skim, it looks like '--with-wide-int' might make *immediate*
> integers wider, which for some applications might perform much better
> than the heap-allocated arbitrary-size integers supported by Emacs 27.
> However, I didn't look carefully at this.
>
> * I updated "emacs-exec-path.patch" and removed
> "emacs27-exec-path.patch", whereas Morgan's patch keeps both files and
> possibly leaves "emacs-exec-path.patch" orphaned.
>
> * I updated the patches to apply cleanly to Emacs 27, although this was
> not strictly needed.
>
> * I updated 'notmuch' in the previous commit to a version that builds
> successfully with Emacs 27.
>
> Pierre Neidhardt wrote:
>> I confirm that with Mark's commit
>> emacs-clojure-mode and emacs-elisp-refs are also broken.
>
> Sorry about that. If the Emacs 27 update breaks important packages, it
> might be that reverting it is the proper action. If the maintainers
> decide to do this, I would not object.
>
>Best regards,
>Mark
>
Re: [bug#42738] [PATCH v4] gnu: emacs: Update to 27.1.
Hi Amin,
Amin Bandali wrote:
> Brett Gilio writes:
>
> [...]
>>
>> Also, are we planning to keep emacs-next and have it track 28.x or
>> remove it?
>>
>> Brett Gilio
>
> I would like it if it's kept. Though, if it is truly meant to track the
> "next" release of Emacs, it should be pointed at the `emacs-27' branch,
> as there will likely be one or more point releases in the 27 series.
Feel free to re-add it. I was torn about whether to remove it. Anyway,
most of its code is now integrated into the main 'emacs' package, so it
should be a lot simpler now. Here's a first draft (untested), but of
course it should be updated to a later commit:
--8<---cut here---start->8---
(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)))
(sha256
(base32 "0mlrg2npy1r79laahkgzhxd1qassfcdz8qk1cpw7mqgf6y5x505h"))
(file-name (git-file-name name version
(native-inputs
`(("autoconf" ,autoconf) ; needed when building from trunk
,@(package-native-inputs emacs)))
;; TODO: consider changing `emacs' to use a more robust way of
;; specifying version for "EMACSLOADPATH", so as to avoid having to
;; duplicate native-search-paths here.
(native-search-paths
(list (search-path-specification
(variable "EMACSLOADPATH")
;; The versioned entry is for the Emacs' builtin libraries.
(files
(list "share/emacs/site-lisp"
(string-append "share/emacs/" emacs-version "/lisp"
(search-path-specification
(variable "INFOPATH")
(files '("share/info"
--8<---cut here---end--->8---
Regards,
Mark
Re: [PATCH v4] gnu: emacs: Update to 27.1.
Hello Guix,
Ludovic Courtès wrote:
> morgan.j.sm...@outlook.com skribis:
>
>> From: Morgan Smith
>>
>> * gnu/packages/emacs.scm (emacs): Update to 27.1.
>> [arguments]: Add --with-cairo and --with-modules to #:configure-flags. Add
>> restore-emacs-pdump phase.
>> [inputs]: Add cairo, libxaw, jansson, gmp, and harfbuzz. Remove imagemagick
>> and libxft.
>> [native-inputs]: Add texlive.
>> (emacs-wide-int): Mark as deprecated package.
>> (emacs-no-x):
>> [arguments]: Add --with-jpeg=no --with-gif=no --with-tiff=no
>> to #:configure-flags.
>
> I see that Mark committed a similar patch just yesterday:
>
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=36a09d185343375a5cba370431870f9c4435d623
>
> I suppose Mark hadn’t seen the ongoing discussion.
Indeed, I hadn't. Gah, I'm terribly sorry about this. I had done some
quick web searches for preexisting work on this, but clearly they were
insufficient, and I've never subscribed to the patches list. In the
future, I'll know not to rely on web search engines for this.
> Mark, Morgan: could you see if there’s anything we’re missing from the
> patch Morgan submitted?
Looking now, here are the main differences I see between our patches:
* I found that I had to remove the 'restore-emacs-pdump' phase from most
of the other emacs variants, namely the ones that use
'gnu-build-system', because otherwise the inherited
'restore-emacs-pdump' phase would fail. Morgan's patch seems not to
consider most of the other emacs variants, and I'm not sure if they
were tested. I briefly tested all of them except for 'guile-emacs'.
* Morgan removed the snippet code that deletes "eshell/esh-groups.el",
whereas I replaced it with a call to 'find-files' to remove it only if
present, as the previous comment suggested. I'm not sure if this is
still needed, though.
* Morgan's patch adds "libxaw" to inputs and "texinfo" to native-inputs.
What's the rationale for these?
* I added 'pango' to the inputs, because the Emacs NEWS mentioned that
Pango was used for font rendering when "--with-cairo" is used.
However, it may be that "pango" finds its way into the build inputs
without being explicitly mentioned.
* Morgan removed 'libxft' from the inputs of 'emacs', whereas I didn't.
This was an oversight on my part. However, if we remove it, it's
possible that we might need to add it back to 'emacs-no-x-toolkit'.
The references that I see to Pango in the Emacs code are within
"#ifdef HAVE_GTK3".
* In 'emacs-no-x', my patch removes the new graphical library inputs
(cairo, pango, and harfbuzz) and the "--with-cairo" flag, whereas
Morgan's patch leaves "cairo" and "harfbuzz" as inputs, and overwrites
the inherited configure-flags to be precisely ("--with-jpeg=no"
"--with-gif=no" "--with-tiff=no"), apparently discarding the inherited
"--with-modules" and "--disable-build-details" flags.
* Morgan made 'emacs-wide-int' into a deprecated package, whereas I
thought that it might still be useful. My rationale was this: from a
brief skim, it looks like '--with-wide-int' might make *immediate*
integers wider, which for some applications might perform much better
than the heap-allocated arbitrary-size integers supported by Emacs 27.
However, I didn't look carefully at this.
* I updated "emacs-exec-path.patch" and removed
"emacs27-exec-path.patch", whereas Morgan's patch keeps both files and
possibly leaves "emacs-exec-path.patch" orphaned.
* I updated the patches to apply cleanly to Emacs 27, although this was
not strictly needed.
* I updated 'notmuch' in the previous commit to a version that builds
successfully with Emacs 27.
Pierre Neidhardt wrote:
> I confirm that with Mark's commit
> emacs-clojure-mode and emacs-elisp-refs are also broken.
Sorry about that. If the Emacs 27 update breaks important packages, it
might be that reverting it is the proper action. If the maintainers
decide to do this, I would not object.
Best regards,
Mark
Re: [bug#42738] [PATCH v4] gnu: emacs: Update to 27.1.
Brett Gilio writes: [...] > > Also, are we planning to keep emacs-next and have it track 28.x or > remove it? > > Brett Gilio I would like it if it's kept. Though, if it is truly meant to track the "next" release of Emacs, it should be pointed at the `emacs-27' branch, as there will likely be one or more point releases in the 27 series. On the other hand, as an Emacs developer, I would appreciate having a package that tracks `master' that I could use. Perhaps emacs-trunk would be a more appropriate name for that package. I know it's not typical for guix.git to contain package definitions that point to non-release commits; but perhaps Emacs could be an exception to that. Thoughts? signature.asc Description: PGP signature
Re: merge wip-haskell?
Hi John, John Soo writes: > Does anyone know why idris, agda, and purescript are failing? The really short version is that we now use shared libraries for Haskell dependencies, which mostly works, except for some of the more complicated builds. I did fix Agda a little while ago, so I think it’s okay now. The issue was it couldn’t run the Agda compiler because it didn’t know where it’s own shared libraries were before installing. I fixed it by setting “LD_LIBRARY_PATH” during the build. Idris has a similar problem, but not similar enough that the same solution works. I imagine PureScript is in the same boat, but I didn’t know about it until now. This makes me wonder about Elm, too. > I have only been able to do very little recently to look at them. Me too. 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. -- Tim
Re: [bug#42738] [PATCH v4] gnu: emacs: Update to 27.1.
On Fri, 28 Aug 2020, Brett Gilio wrote: Also, are we planning to keep emacs-next and have it track 28.x or remove it? I believe bandali was planning to track 28.x. Best, Jack
Re: [bug#42738] [PATCH v4] gnu: emacs: Update to 27.1.
Ludovic Courtès writes: > Hi Morgan, Mark, and all, > > morgan.j.sm...@outlook.com skribis: > >> From: Morgan Smith >> >> * gnu/packages/emacs.scm (emacs): Update to 27.1. >> [arguments]: Add --with-cairo and --with-modules to #:configure-flags. Add >> restore-emacs-pdump phase. >> [inputs]: Add cairo, libxaw, jansson, gmp, and harfbuzz. Remove imagemagick >> and libxft. >> [native-inputs]: Add texlive. >> (emacs-wide-int): Mark as deprecated package. >> (emacs-no-x): >> [arguments]: Add --with-jpeg=no --with-gif=no --with-tiff=no >> to #:configure-flags. > > I see that Mark committed a similar patch just yesterday: > > > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=36a09d185343375a5cba370431870f9c4435d623 > > I suppose Mark hadn’t seen the ongoing discussion. > > Mark, Morgan: could you see if there’s anything we’re missing from the > patch Morgan submitted? > > At any rate, thanks a lot for the work everyone put in! > > Ludo’, a happy Emacs user. Also, are we planning to keep emacs-next and have it track 28.x or remove it? Brett Gilio
python-docker-py
Hello, commit 3146b6da6dd3124f8693f48a9ed7ff8208324e23 moves python-docker-py from version 1.10.6 to 3.7.3. I think that at the same time, it should have been renamed to python-docker: - as can be seen in the source, it is downloaded from the "docker" project on pypi; - it advertises itself as "Name: docker" in lib/python3.8/site-packages/docker-3.7.3-py3.8.egg-info/PKG-INFO Are you okay with renaming the package? There are only 2 dependent packages (fdroidserver, on which I am currently working; and docker-compose)? Do we need a special field to mark the replacement? I do not expect that users have installed this package independently of fdroid or docker-compose. Andreas
Re: [PATCH v4] gnu: emacs: Update to 27.1.
I confirm that with Mark's commit emacs-clojure-mode and emacs-elisp-refs are also broken. Cheers! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: [PATCH v4] gnu: emacs: Update to 27.1.
Hi Morgan, Mark, and all, morgan.j.sm...@outlook.com skribis: > From: Morgan Smith > > * gnu/packages/emacs.scm (emacs): Update to 27.1. > [arguments]: Add --with-cairo and --with-modules to #:configure-flags. Add > restore-emacs-pdump phase. > [inputs]: Add cairo, libxaw, jansson, gmp, and harfbuzz. Remove imagemagick > and libxft. > [native-inputs]: Add texlive. > (emacs-wide-int): Mark as deprecated package. > (emacs-no-x): > [arguments]: Add --with-jpeg=no --with-gif=no --with-tiff=no > to #:configure-flags. I see that Mark committed a similar patch just yesterday: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=36a09d185343375a5cba370431870f9c4435d623 I suppose Mark hadn’t seen the ongoing discussion. Mark, Morgan: could you see if there’s anything we’re missing from the patch Morgan submitted? At any rate, thanks a lot for the work everyone put in! Ludo’, a happy Emacs user.
Re: merge wip-haskell?
On another note: Does anyone know why idris, agda, and purescript are failing? I have only been able to do very little recently to look at them. - John
Re: merge wip-haskell?
Hi! Ricardo Wurmus skribis: > Ludovic Courtès writes: > >> Ricardo Wurmus skribis: >> >>> Yes, and for the case of pandoc it’s significant. The closure of >>> ghc-pandoc is >3GiB right now and with the changes it’s <200MiB. This >>> affects lots of R packages that need Rmarkdown, and lots of bioinfo >>> packages. >> >> Are those changes part of what was merged? I get: >> >> --8<---cut here---start->8--- >> $ guix describe >> Generacio 153Aug 24 2020 10:53:47(nuna) >> guix c687299 >> repository URL: https://git.savannah.gnu.org/git/guix.git >> branch: master >> commit: c6872990b51971922f3064cba54ab752fcdc1559 >> $ guix size ghc-pandoc | tail -1 >> total: 2033.0 MiB >> --8<---cut here---end--->8--- >> >> Or am I missing something? > > Try the “pandoc” package instead. There are now two packages: > “ghc-pandoc” for the regular old shared library thing and “pandoc” for > this static linking abomination. Oh, the abomination is much nicer, thanks! (Do we actually still need ‘ghc-pandoc’?) > (Similarly for “ghc-pandoc-citeproc” and “pandoc-citeproc”.) > > I should note that it doesn’t help with one case I had in mind: “guix > pack” still includes way too much, unfortunately, so there is no impact > on application bundle size yet. How come? It should include exactly what ‘guix size pandoc’ shows, no? Thanks! Ludo’.
Re: Improving CI throughput
Hello! Mathieu Othacehe skribis: >> Yeah, this is a ridiculous situation. We should do a hackathon to get >> better monitoring of useful metrics (machine load, >> time-of-push-to-time-to-build-completion, etc.), to clearly identify the >> bottlenecks (crashes? inefficient protocol? scheduling issues? Cuirass >> or offload or guix-daemon issue?), and to address as many of them as we >> can. >> >> Any volunteers? :-) > > I'd really like to improve the situation! A hackathon seems like a > nice idea. > > As a matter of fact, I already spent some times improving the stability > of Cuirass web interface[1]. Much appreciated! > Now I can see multiple topics that could be approached in parallel: > > * Add metrics to Cuirass as you suggested. There's an open ticket about > that here[2]. > > * Investigate offloading issues[3]. > > * Fix database contention[4]. > > * Fix guix-daemon deadlocking[5]. > > * Monitor closely what's happening on Berlin and decide if it is > opportune to add a build scheduler mechanism somewhere. See what Hydra > is doing[6] and what Chris is proposing[7]. I’m happy to help tackle daemon/offload issues, but I’ll be more motivated if others join. :-) > As most of the issues are only observed on Berlin machines, which access is > restricted, we will also have to find a way to reproduce them locally. Yeah, and these are usually non-deterministic issues and not that frequent. > Anyway, if some people are motivated, we could try to plan a day or > week-end to work on those topics :). I can try and spend some time on it this week-end. I suggest that people join the IRC channel and shout “CI!” as a way to rally, and then share what they’re looking at and how they feel. How does that sound? Thanks for cooking up this list of issues! Ludo’.
Re: Guix containers 'advertised' in git repos
Hello, Pjotr Prins skribis: > We are using Guix containers for deployment and software development. > I was thinking it would be nice to advertise them in the git repos. > > Maybe we can standardise on that. What I have now is have a file > > .git-deploy > > for deployment. E.g., > https://github.com/encryption4genetics/HEGP-website/blob/master/.guix-deploy > > and > > .git-dev > > for development. E.g., > https://github.com/genetics-statistics/GEMMA/blob/master/.guix-dev [...] David Dashyan skribis: > We do the same thing, kind of, but due to our CLA restrictions we have > everything in separate repository. > > https://github.com/ipdb/bigchaindb-guix > > I've named the file "activate" which is python's idiom taken from There’s a rather widespread convention for ‘guix.scm’, to be passed to ‘guix environment -l’ or ‘guix package -f’. However, there’s currently no tool to declare the container parameters, which is why your ‘.guix-deploy’ file above is essentially a shell script. A long time ago Dave Thompson suggested having an (or similar) data type on top of , which would describe that sort of thing. Perhaps something to keep in mind for ‘guix shell’? Ludo’.
Re: Dealing with foreign distros without nscd
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? -- Ricardo
Dealing with foreign distros without nscd
Hello Guix! One of the most important pieces of advice we give to use Guix on foreign distros is to make sure the distro runs nscd, so we don’t end up dlopening NSS modules in Guix-produced programs: https://guix.gnu.org/manual/en/html_node/Application-Setup.html#Name-Service-Switch A situation where this is not possible is HPC clusters: you would like to run packs there, but you’re not root and cannot spawn nscd, and those machines typically use a Red Hat derivative with ‘sssd’: --8<---cut here---start->8--- $ grep sss /etc/nsswitch.conf passwd: files sss shadow: files sss group: files sss services: files sss netgroup: files sss automount: files sss --8<---cut here---end--->8--- If you try to run binaries from ‘guix pack’ there, they’ll fail to find libnss_sss.so, and so user name lookups etc. (e.g., getpw(3)) will fail. 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. For the record, I pushed one commit that fixes ‘sssd’¹ and another one to have LD_LIBRARY_PATH honored when using GUIX_EXECUTION_ENGINE=fakechroot². Ludo’. ¹ https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8df6900dffa9e1c74ac3f64877f067974eee0eeb ² https://git.savannah.gnu.org/cgit/guix.git/commit/?id=28dce8f02db38a41e59ecdf3786baa6f732636ff
Re: [PATCH] hydra: Use the new 'systems' field for build-machine definitions.
Hello Maxim,
> (fast/hurd (filter (compose childhurd-ip? build-machine-name) fast)))
>(append overdrive (map aarch64->armhf overdrive)
> armv7
> - x86_64 (map x86_64->i686 x86_64)
> + x86_64
> (map x86_64->qemu-aarch64 fast)
> (map x86_64->qemu-armhf fast)
>(map x86_64->childhurd fast/hurd)))
You could also get rid of "x86_64->qemu-aarch64" and
"x86_64->qemu-armhf" adding:
--8<---cut here---start->8---
(define template-x86_64
(match-lambda
;; Prefer building on the new nodes.
((name key 128)
(build-machine
(name name)
(user "hydra")
(systems ("x86_64-linux" "i686-linux"
"aarch64-linux" "armhf-linux"))
(host-key key)
(compression "no")
--8<---cut here---end--->8---
Otherwise, this looks good :)
Thanks,
Mathieu
