Re: CLISP test failures on ‘core-updates’

Guillaume Le Vaillant skribis: > Maybe the CI just had a hiccup... I restarted the build, maybe it will > be enough. It looks like it worked. signature.asc Description: PGP signature

Re: CLISP test failures on ‘core-updates’

Ludovic Courtès skribis: > Hello Lisp team! :-) > > The ‘clisp’ package has a few test failures on ‘core-updates’ > (x86_64-linux): > > --8<---cut here---start->8--- > finished 57 files: 6 errors out of 11,960 tests > 1

Packages in lisp-xyz.scm are now sorted

Hi jgart. I saw that you just added the cl-asn1, cl-pem and cl-jose libraries. Since commit 51966d1bae8d9c2d0e8cd4a9dfbc8b7cf7af18d9, the packages in "lisp-xyz.scm" are sorted in alphabetical order (well, the sbcl-* are sorted, but the cl-* and ecl-* packages are still just below the matching

Re: Why bash-minimal is part of sbcl package

Pan Xie skribis: > Hello > > I find this interesting thing but I don't have an explanation. When query the > "references" of my Gnu Store item "sbcl", it shows that sbcl references > bash-mininal, as the following output shows: > > # guix gc --references

Re: Building and caching old Guix derivations for a faster time machine

Maxim Cournoyer skribis: > Hi Simon, > > Simon Tournier writes: > >> Hi, >> >> On mer., 22 nov. 2023 at 19:27, Ludovic Courtès wrote: >> >>> For long-term storage though, we could choose to keep lzip only (because >>> it compresses better). Not something we can really do with the current >>>

Re: Help Packaging Incudine (Common Lisp)

Hi. It looks like there's a bug in "contrib/cl-sndfile/cffi-sndfile.lisp". The 'make-sndinfo' function definition tries to get the size of the 'info' foreign structure before this foreign structure is defined. After moving the definition of 'make-sndinfo' at the end of the file, compilation

Re: Help Packaging Incudine (Common Lisp)

Hi. Could you send the package definition you made for Incudine? I could take a look at it and try to find where the issue comes from. signature.asc Description: PGP signature

Re: Is this a bug in guix refresh with respect to Common Lisp packages?

"jgart" skribis: >> I don’t see any difference in behavior here. > > The difference is that the common lisp example I gave doesn't contain the > output with the packages that would be rebuilt. Hi. The "guix refresh -l" command doesn't print the complete list of dependents. I think it only

Re: CI job for lisp-team branch

Guillaume Le Vaillant skribis: > I reported the issue upstream at > <https://bugs.launchpad.net/sbcl/+bug/2034713> with your log file. > Let's see what they say... I downgraded sbcl to 2.3.7 on the lisp-team branch for now. signature.asc Description: PGP signature

Re: Cross compilation status

Mathieu Othacehe skribis: > In order for Guix to become an alternative to tools such as Yocto and > Buildroot, having most or all our packages cross-compiling is a > prerequisite. > > Here is a status of cross-compilation in Guix. For cross-compilation to > work, the build-system needs to

Re: CI job for lisp-team branch

I reported the issue upstream at with your log file. Let's see what they say... signature.asc Description: PGP signature

Re: CI job for lisp-team branch

Efraim Flashner skribis: > On Wed, Sep 06, 2023 at 03:47:01PM +0300, Efraim Flashner wrote: >> >> I commented on IRC but figured I should post to the mailing list. >> >> I tested sbcl@2.3.8 on riscv64-linux and the build failed in the contrib >> section. I see the patch was removed, presumably

Re: CI job for lisp-team branch

Maxim Cournoyer skribis: > Hi Guillaume, > > I've also created a TLS client certificate and emailed it to you > (encrypted) so that you can manage your branch yourself via the Cuirass > web interface, restart failing builds (which are sometimes spurious > failures due to not yet resolved

CI job for lisp-team branch

Hi. I created a lisp-team branch to work one some updates for clisp and sbcl. Could someone with admin access to the CI things add a job for it? Thanks. signature.asc Description: PGP signature

IPv6 access for ci.guix.gnu.org

Hi. The substitute server at ci.guix.gnu.org is not reachable via IPv6. I found messages from 4 years ago indicating that the network where the CI machine is was not ready for IPv6 (see [1]). Is it still the case today? [1] https://lists.gnu.org/archive/html/guix-devel/2019-08/msg00096.html

Re: stateful caches (was Re: OBS Studio memory leak)

Giovanni Biscuolo skribis: > Hi Guillaume Le Vaillant and Guix Devels, > > sorry for cross-posting but IMHO the workaround you found [1] for the memory > leak affecting a number of media processing applications is of interest > for many people potentially not subscribed to help

Re: 01/03: gnu: sbcl: Update to 2.3.5.

Christopher Baines skribis: > guix-comm...@gnu.org writes: > >> glv pushed a commit to branch master >> in repository guix. >> >> commit b019b49c74e51e42230da471f39bff9f642fbc24 >> Author: Guillaume Le Vaillant >> AuthorDate: Fri Jun 2 13:32:55 2023

Re: How many bytes do we add (closure of guix) when adding one new package?

Simon Tournier skribis: > Hi Jack, > > On Tue, 30 May 2023 at 16:55, Jack Hill wrote: > >> $ ~/.config/guix/current/lib/guile/3.0/site-ccache/gnu [env]$ sudo compsize . >> Processed 595 files, 1659 regular extents (1659 refs), 0 inline. >> Type Perc Disk Usage Uncompressed

Re: Core-updates, the last metres

John Kehayias skribis: > If things continue looking good, are we planning to see the merge in > the next few days? Any other more leaf packages anyone has noticed > needs a fix someone should look at? Hi, Here are a few leaf packages that don't build because of some failing dependencies: -

Re: Core-updates after the staging merge

Andreas Enge skribis: > Hello all, > > the merge of staging to master, and the subsequent merge of master to > core-updates did break a few things; but on the positive side, we are > halfway there with getting rid of the staging and core-updates branches ;-) > CI has almost caught up on x86_64;

Re: Lisp team: Should we package Quicklisp?

"jgart" skribis: > Hi, what do you think if we package Quicklisp? > > For example, we have emacs-straight packaged which is a purely functional > package manager for the Emacs hacker that is not Guix. > > I think it could be convenient to have. > > https://www.quicklisp.org/ Hi. Do you mean

Re: monero-gui-wallet does not show up in GNOME

Guillaume Le Vaillant skribis: > "jgart" skribis: > >> Hi, >> >> Even after logging out and in I still can't see `monero-wallet-gui` >> executable show up when I press the "windows" key in the GNOME desktop. >> >> See this scr

Re: monero-gui-wallet does not show up in GNOME

"jgart" skribis: > Hi, > > Even after logging out and in I still can't see `monero-wallet-gui` > executable show up when I press the "windows" key in the GNOME desktop. > > See this screenshot: > > https://up.nixnet.services/vyv1z6ia.png > > I installed monero-gui like this: > >

Re: Licence of the Guix blog posts

Ludovic Courtès skribis: > You might remember that I started long ago asking people who had > contributed to the blog whether they would agree to licensing their work > under CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant > Sections, no Front-Cover Texts, and no Back-Cover Texts¹.

Re: Package Argument #:asd-systems Missing & Guix Provides

Charles skribis: > Hello Guix Developers. > > [...] > > Full Context: > > I am trying to make a guix-provides script that would take some artifact > (name of asd-system) as input and give the packages that create those > artifacts. > Examples: > > Find by asdf-system > $ guix provides

Re: Release progress, week 3

Ludovic Courtès skribis: > Release progress: week 3. > > • Architectures: > [...] > - armhf-linux: No progress so far. I tried doing a "guix pull" for armhf-linux on a Raspberry Pi 2 B (Raspberry Pi OS with Guix as package manager), and also on a more powerful x86_64 machine with

Re: Guix and Coleslaw Home Recipe!

jgart skribis: > jgart ponders to self: > > Will this package build the `coleslaw` CLI command with our current > asdf-build-system? > > What's missing? > > https://github.com/coleslaw-org/coleslaw > > Here's my attempt but there's no executable in the store for `coleslaw`: > >

Re: r-mathjaxr

Ricardo Wurmus skribis: > Ricardo Wurmus writes: > >> unfortunately I had to revert commits >> 9078c651e8d50e08b46e3b2da1c532c15af5ddb6 (Add r-mathjaxr) and >> 00056eafaefed0af8535f219760fbbe01dd6f240 (updating r-metafor). > […] >> The good news is that we can soon build a >> slightly degraded

Re: Reproducible Builds Status Summary for Guix

Ludovic Courtès skribis: > Hi! > > Vagrant Cascadian skribis: > >> Some rough summaries about the types of issues: >> >> * ecl-* packages account for nearly half of the issues (~500 out of >> ~1000 packages) > > This seems to be a problem with generated identifiers at first sight; > would

Re: Tensorflow fixes on core-updates-frozen

Ricardo Wurmus skribis: > Ricardo Wurmus writes: > >> Unfortunately, this is not enough to build tensorflow. At the very end >> we have this problem: […] > > This should now be fixed with commit e1c91aae23af12bccab615902a08ebc86defc1ac. Thanks! signature.asc Description: PGP signature

Tensorflow fixes on core-updates-frozen

guix-comm...@gnu.org skribis: > rekado pushed a change to branch core-updates-frozen > in repository guix. > > new d503194 gnu: python2-entrypoints: Add missing input. > new 672c7a2 gnu: tensorflow: Do not unpack directory. > new 6d3439b gnu: eigen-for-tensorflow: Build with GCC

Re: cl-gsll fails to load

may be a way to patch our CFFI package to fix the links to all the GCC toolchain things, which would allow us to remove gcc-toolchain in the command above, but it will probably not be super easy. From 7613cc6c054bfc5dc66f657aeb2987a22c342b80 Mon Sep 17 00:00:00 2001 From: Guillaume Le Vaillant Date: Fri,

Re: cl-gsll fails to load

Foo Chuan Wei skribis: > On 2021-12-07 12:27 +0000, Guillaume Le Vaillant wrote: >> I think the problem comes from the fact that the build system for >> cl-xxx packages doesn't use the custom phases added to some sbcl-xxx >> packages (like the 'fix-cffi-paths' phase o

Re: cl-gsll fails to load

Foo Chuan Wei skribis: > I am using Guix on Ubuntu 20.04, and SBCL 2.1.9 (installed using `guix > install sbcl`). I have installed cl-gsll (`guix install cl-gsll`), but > `(asdf:load-system :gsll)` fails. Why? > > This is my ASDF configuration > > File:

Re: Common Lisp package: all test cases pass but 'check' phase fails

Katherine Cox-Buday skribis: > Foo Chuan Wei writes: > >> In lisp-xyz.scm, I see that the "cl-locale" package has the same problem >> with its tests. >> >> Does anyone here know the cause of the error above? > > Without having time to look at the code, but with the hope that this points > you

Re: Making `python-next` the next `python`

Tanguy LE CARROUR skribis: > Excerpts from Guillaume Le Vaillant's message of November 8, 2021 10:26 am: >> Tanguy LE CARROUR skribis: >>> I've just started working on packaging Python 3.10 and realized >>> that Guix's default version for Python is still 3.8. >>> >>> What would be the proper

Re: Making `python-next` the next `python`

Tanguy LE CARROUR skribis: > Dear Guix, > > I've just started working on packaging Python 3.10 and realized > that Guix's default version for Python is still 3.8. > > What would be the proper way to make 3.9 the default version? > Do I "just" have to submit a patch that rename the related

Re: Upgrade cl-hunchentoot to version 1.3.0

Tim Lee skribis: > In Guix, the latest version of Hunchentoot is 1.2.38 (released on > 2017-12-03). There is a new upstream version 1.3.0 (released on > 2021-05-07). Can someone upgrade cl-hunchentoot? I am not familiar with > the Guix packaging process, but it appears that the following patch

Re: Duplicated libxml++ packages

Tobias Geerinckx-Rice skribis: > Guillaume Le Vaillant 写道： >> I just noticed on the core-updates-frozen branch that there are libxml++ >> packages (in gnome.scm) and also libxmlplusplus packages (in xml.scm). >> I checked the sources of libxml++-2.40.1 and libxmlplusplus-2.

Duplicated libxml++ packages

I just noticed on the core-updates-frozen branch that there are libxml++ packages (in gnome.scm) and also libxmlplusplus packages (in xml.scm). I checked the sources of libxml++-2.40.1 and libxmlplusplus-2.40.1, and it looks like it is the same library. I think we could keep only the

Re: [core-updates-frozen] Blockers for working system

Jonathan Brielmaier skribis: > Hi Guix folks, > > here are the blockers which prevent me from using core-updates-frozen on > my personal machine. So those 14 derivations failed for me this morning: > > [...] > > /gnu/store/7mz3ci5gydg606wmh2y6yl7q53mp5x68-materialdecoration-1.1.0-9.6a5de23.drv >

Re: Batching world-rebuilding changes for the core-updates-frozen branch

Maxim Cournoyer skribis: > Hello Guix! > > Since there's going to be at least this change [0] causing a world > rebuild of the core-updates-frozen branch, I'd like to know if there are > other world-rebuilding but low-risk changes you'd like to see integrated > into the branch. > > If you do,

Re: [core-updates-frozen] Bug in binutils 2.37

Guillaume Le Vaillant skribis: > Leo Famulari skribis: > >> On Mon, Sep 06, 2021 at 03:39:52PM +0000, Guillaume Le Vaillant wrote: >>> There's a bug in binutils 1.37, which we are using on the >>> core-updates-frozen branch. >> >> 2.37, right? :) >&g

Re: [core-updates-frozen] Bug in binutils 2.37

Leo Famulari skribis: > On Mon, Sep 06, 2021 at 03:39:52PM +0000, Guillaume Le Vaillant wrote: >> There's a bug in binutils 1.37, which we are using on the >> core-updates-frozen branch. > > 2.37, right? :) > Indeed. :) >> It's a file descriptor leak that

[core-updates-frozen] Bug in binutils 1.37

on core-updates-frozen, or does someone have an idea that would lead to less rebuilds? P.S.: The patch I'm trying is in attachment. From d90e95640f0c2bd3271e370516e51fac56929be7 Mon Sep 17 00:00:00 2001 From: Guillaume Le Vaillant Date: Mon, 6 Sep 2021 17:32:38 +0200 Subject: [PATCH] gnu: binutils: Fix

Duplicate package in lisp-xyz

Hi Pierre, One of your recent commits (22796f1ad16abb7b1519d11332175d147ae10b82) adds pathname-utils to "lisp-xyz.scm", however there was already a definition for this package (starting at line 16030). As far as I can see it doesn't break anything because the previous definition is just shadowed

Re: branch master updated: gnu: Add html2text.

Tobias Geerinckx-Rice skribis: > Guillaume, > > guix-comm...@gnu.org 写道： >> gnu: Add html2text. > > Thanks! > > This package is good but would've benefited from review. Please submit all > non-trivial patches to guix-patc...@gnu.org first (if you did, I couldn't find > it). We've been too lax

Re: GNOME 3.34 in GNU Guix and security

Danny Milosavljevic skribis: > Hello, > > core-updates is still in a pretty bad state. > > [...] > > A short summary of what is at least broken: > > [...] > (2) Source files have been in-place replaced upstream with a lot of packages > (see my bug report about the topic). fldigi has such a

Re: When substitute download + decompression is CPU-bound

Nicolò Balzarotti skribis: > Which hardware did you use? Since you are fixing the download speed, > those results really depend on cpu speed. I ran these tests on a laptop from 2012 with an Intel i7-3630QM CPU. When the CPU speed increases, the download speed limit below which Lzip is the

Re: When substitute download + decompression is CPU-bound

Pierre Neidhardt skribis: > Hi Ludo! > > Ludovic Courtès writes: > >> I suppose a possible agenda would be: >> >> 1. Start providing zstd susbstitutes anytime. However, most clients >> will keep choosing lzip because it usually compresses better. >> >> 2. After the next release, stop

Re: Staging branch [kwayland test failure]

It looks like the kwayland test failure on x86-64 doesn't happen all the time. I just built it successfully on master and on staging by trying again when the build failed. signature.asc Description: PGP signature

Re: When substitute download + decompression is CPU-bound

Pierre Neidhardt skribis: > Wow, impressive! :) > > Guillaume Le Vaillant writes: > >> Note that the plots only show the results using only 1 thread and > > Doesn't 1 thread defeat the purpose of parallel compression / decompression? > It was just to get a

Re: When substitute download + decompression is CPU-bound

I compared gzip, lzip and zstd when compressing a 580 MB pack (therefore containing "subsitutes" for several packages) with different compression levels. Maybe the results can be of some use to someone. Note that the plots only show the results using only 1 thread and standard compression

Re: Failing CI evaluation for staging branch

Guillaume Le Vaillant skribis: > Guillaume Le Vaillant skribis: > >> Ludovic Courtès skribis: >> >>> Hi Guillaume, >>> >>> Guillaume Le Vaillant skribis: >>> >>>> Currently no substitutes are built for the testing branch bec

Re: Failing CI evaluation for staging branch

Guillaume Le Vaillant skribis: > Ludovic Courtès skribis: > >> Hi Guillaume, >> >> Guillaume Le Vaillant skribis: >> >>> Currently no substitutes are built for the testing branch because the >>> evaluation fails. The log at https://ci.guix.gnu

Re: Failing CI evaluation for staging branch

Ludovic Courtès skribis: > Hi Guillaume, > > Guillaume Le Vaillant skribis: > >> Currently no substitutes are built for the testing branch because the >> evaluation fails. The log at https://ci.guix.gnu.org/eval/16794/log/raw >> ends with: > > You mean t

Failing CI evaluation for testing branch

Hi, Currently no substitutes are built for the testing branch because the evaluation fails. The log at https://ci.guix.gnu.org/eval/16794/log/raw ends with: --8<---cut here---start->8--- Generating package cache for

Re: Improve ASDF build system for Common Lisp libraries

Pierre Neidhardt skribis: > I've retested wip-lisp on 851abcf6c9c15d90cb77c57b40d10c3b4835, > everything seems to work! Thanks for testing. > Nit: Maybe enable tests in ecl-numcl ? Done. > I've successfully tested Nyxt with the following recipe: > > --8<---cut

Re: Improve ASDF build system for Common Lisp libraries

Katherine Cox-Buday skribis: > Ricardo Wurmus writes: > >> Pierre Neidhardt writes: >> >>> Some .asd definitions have dependencies (declared with >>> :system-depends-on). >>> A common dependency is prove-asdf. >>> >>> If we read all .asd then we must drag all ASDF dependencies. This can be a

Re: Improve ASDF build system for Common Lisp libraries

To further simplify package definitions, I thought we could remove the need for the 'asd-files' keyword in the package's arguments by just reading all the '.asd' files in the directory tree of the sources. Can you think of a case where this would cause an issue? signature.asc Description: PGP

Re: Improve ASDF build system for Common Lisp libraries

I was thinking about what the package definitions would look like if we put pre-compiled files in package outputs instead of in their own packages. For example with a cl-xyz package having cl-abc as native input and cl-def as input: - cl-xyz package needs to propagate cl-abc and cl-def

Re: Improve ASDF build system for Common Lisp libraries

Pierre Neidhardt skribis: > Guillaume Le Vaillant writes: > >> I thought about having the sources, SBCL compiled files and ECL compiled >> files respectively in the 'out', 'sbcl' and 'ecl' packages outputs; >> however I thought there could be issues in some

Re: Improve ASDF build system for Common Lisp libraries

Pierre Neidhardt skribis: > Guillaume Le Vaillant writes: > >> Actually, it looks like the files generated by the groveler can't be >> removed. When doing '(asdf:load-system "osicat")', if these files are >> not there cffi tries to generate them (and fails bec

Re: Improve ASDF build system for Common Lisp libraries

Guillaume Le Vaillant skribis: > Pierre Neidhardt skribis: > >> About Osicat: There are grovel left overs that could be removed. >> The former build system used to do that automatically. Maybe we can >> restore this behaviour? > > The former build system deleted

Re: Improve ASDF build system for Common Lisp libraries

Pierre Neidhardt skribis: > What do you think about the moving the SBCL / ECL definitions to package > outputs? I thought about having the sources, SBCL compiled files and ECL compiled files respectively in the 'out', 'sbcl' and 'ecl' packages outputs; however I thought there could be issues

Improve ASDF build system for Common Lisp libraries

Hi, I've been working on some changes to the asdf-build-system for Common Lisp libraries and programs: - Switching from compile-bundle-op to regular compile-op. Using the regular compilation operation of ASDF instead of bundles gives us automatic support for component-less systems and

Re: Profile hook in build environment?

Ricardo Wurmus skribis: > Guillaume Le Vaillant writes: > >> Is there a way to generate files and add them to the environment created >> by 'guix build' as it can be done with profile hooks? > > Yes, the build system can do whatever it wants. The > texlive-build-

Profile hook in build environment?

Hi, I'm currently experimenting with modifications of the asdf-build-system to see if it can be simplified. I tried adding a profile hook that creates the ASDF configuration files in 'etc/common-lisp/' based on the lisp packages that are present in the manifest. When using 'guix environment -C

Re: Unencrypted boot with encrypted root

Pierre Neidhardt skribis: > Have you tried to unlock a ZFS-encrypted home with pam_mount? > > I found these related links: > > https://blogs.oracle.com/solaris/user-home-directory-encryption-with-zfs-v2 > >

Re: Some packages failing to build

Guillaume Le Vaillant skribis: > Guillaume Le Vaillant skribis: > >> Vagrant Cascadian skribis: >> >>> On 2020-05-10, Marius Bakke wrote: >>>> Guillaume Le Vaillant writes: >>>> >>>>> Guillaume Le Vaillant skribis: >

Re: Some packages failing to build

Guillaume Le Vaillant skribis: > Vagrant Cascadian skribis: > >> On 2020-05-10, Marius Bakke wrote: >>> Guillaume Le Vaillant writes: >>> >>>> Guillaume Le Vaillant skribis: >>>> >>>>> Hi, >&g

Re: Some packages failing to build

Vagrant Cascadian skribis: > On 2020-05-10, Marius Bakke wrote: >> Guillaume Le Vaillant writes: >> >>> Guillaume Le Vaillant skribis: >>> >>>> Hi, >>>> >>>> After pulling guix with the merged core updates (guix at commit &

Re: Some packages failing to build

Guillaume Le Vaillant skribis: > Hi, > > After pulling guix with the merged core updates (guix at commit > 95ffdfe86cb1b8a8e4fff1386a147718400b76e0), I found a few packages > failing to build: > > - fbreader > - gnubg > - gnubik > - postgis > - python-chee

Some packages failing to build

Hi, After pulling guix with the merged core updates (guix at commit 95ffdfe86cb1b8a8e4fff1386a147718400b76e0), I found a few packages failing to build: - fbreader - gnubg - gnubik - postgis - python-cheetah - python-trezor I have not yet had the time to try and fix them, so I just list

Re: branch master updated: gnu: gnuradio: Fix runtime python environment for plugins.

Hi, Ludovic Courtès skribis: > Hi Guillaume, > > guix-comm...@gnu.org skribis: > >> (native-search-paths >> + ;; Variables required to find third-party plugins at runtime. >> (list (search-path-specification >> (variable "GRC_BLOCKS_PATH") >> -(files

Re: Merging ham-radio and sdr modules?

Done in commit 0493ead644196bb1c933719d4c0e63e665fd102d.

Merging ham-radio and sdr modules?

Hi, I was thinking of merging 'ham-radio.scm' and 'sdr.scm' (which contains only one package so far) into a new 'radio.scm' module. Does anyone have an objection? signature.asc Description: PGP signature

Re: Unencrypted boot with encrypted root

Ellen Papsch skribis: > Am Freitag, den 03.04.2020, 18:13 +0200 schrieb Pierre Neidhardt: >> >> By the way, is it possible to use the user password to unlock the >> $HOME partition? >> > > AFAIK GNU/Linux userland does not support it. GDM or another login > manager would have to integrate that

Re: Looking for help with packaging a Common Lisp library

A maintainer of ASDF answered that only the dependencies declared in 'depends-on' should be put in the generated asd file for the bundle. Therefore my patch is not necessary, and concerning hdf5-cffi, the cffi-grovel system should be listed in both 'defsystem-depends-on' and 'depends-on'.

Re: Looking for help with packaging a Common Lisp library

Konrad Hinsen skribis: > Pierre Neidhardt writes: > >> Indeed. What I meant is that if the Common Lisp package (the code >> inside the src folder) depends on cffi-grovel, then I believe it >> should be added to :depends-on as well. We can ask ASDF and >> hdf5-cffi. > > I'd be happy to ask

Re: Looking for help with packaging a Common Lisp library

00:00:00 2001 From: Guillaume Le Vaillant Date: Sat, 25 Jan 2020 18:07:37 +0100 Subject: [PATCH] build: lisp-utils: Take defsystem dependencies into consideration. * guix/build/lisp-utils.scm (system-dependencies): Add the dependencies declared with ':defsystem-depends-on' in asd-file to th

Re: Looking for help with packaging a Common Lisp library

I think the generated '...-sbcl-hdf5-cffi-1.8.18/lib/sbcl/hdf5-cffi.asd' file is missing a dependency. It contains ':depends-on ("cffi")', but I think it should be ':depends-on ("cffi" "cffi-grovel")', because the original asd file has: --8<---cut

Re: Moving Lisp libraries to lisp-xyz.scm?

Hi, Concerning the 'wip-lisp-xyz' branch, there are some Lisp libraries as inputs for some packages in 'machine-learning.scm' and 'web-browsers.scm'. So I guess the '(gnu packages lisp-xyz)' module should replace (or be added next to) the '(gnu packages lisp)' module in these files.

Re: Question about sbcl-package->ecl-package

Pierre Neidhardt skribis: > I've merged your last 3 patches, thank you so much for your continuous > contribution to the best Common Lisp package manager ;) Thanks!

Re: Question about sbcl-package->ecl-package

Pierre Neidhardt skribis: > Great! :) > Can you send a patch for all this? I'll merge as soon as I can. I sent the patches (bug#37791).

Re: Question about sbcl-package->ecl-package

Pierre Neidhardt skribis: > Cool! Thanks for working on this! :) > > Does it work for dexador? I just tried compiling ecl-dexador, and it failed. However I think it fails for a different reason. The error is: --8<---cut here---start->8--- An error

Re: Question about sbcl-package->ecl-package

Pierre Neidhardt skribis: > Maybe an easier fix: replace "sbcl" with (%lisp-type). Should work. Indeed, with the following changes, building ecl-dexador works. --8<---cut here---start->8--- diff --git a/gnu/packages/lisp.scm b/gnu/packages/lisp.scm index

Re: Question about sbcl-package->ecl-package

Pierre Neidhardt skribis: > Cool! Thanks for working on this! :) > > Does it work for dexador? I just tried compiling ecl-dexador, and it failed. However I think it fails for a different reason. The error is: --8<---cut here---start->8--- An error

Re: Question about sbcl-package->ecl-package

Guillaume Le Vaillant skribis: > However, when I try to compile 'ecl-simple-parallel-tasks', guix first > tries to build a different derivation of 'ecl-chanl', which fails > because it apparently doesn't have the modified phases declared in the > definition of 'ecl-chanl'. I was

Re: Question about sbcl-package->ecl-package

Efraim Flashner skribis: > On Wed, Oct 16, 2019 at 01:59:01PM +0200, Pierre Neidhardt wrote: >> I've encountered the same problem a couple of times. >> If you try to compile ecl-dexador, you'll see it fails because it does >> not re-use the arguments of sbcl-dexador which patches out a failing

Question about sbcl-package->ecl-package

Hi, I'm trying to package a Common Lisp library and I have a strange problem. In 'gnu/packages/lisp.scm', there are packages called 'sbcl-chanl' and 'ecl-chanl' whose definitions are: --8<---cut here---start->8--- (define-public sbcl-chanl (let ((commit

Re: Using CLISP instead of CCL to bootstrap SBCL

Hi, According to the NEWS file, SBCL 1.5.0 and later can also be bootstrapped using ECL: --- changes in sbcl-1.5.0 relative to sbcl-1.4.16: [...] * build enhancement: new host quirks mechanism, support for building under ABCL and ECL (as well as CCL, CMUCL, CLISP and SBCL itself)