Re: Impossible to push patches to codeberg

Ludovic Courtès skribis: > After a fruitless debugging session with Vagrant on IRC, I opened this > issue: > > https://codeberg.org/Codeberg/Community/issues/1974 > > Ludo’. Hi. Gusted's fix worked for me. I can push patches again. signature.asc Description: PGP signature

Re: Impossible to push patches to codeberg

Ludovic Courtès skribis: > Hello, > > I do see you among “collaborators” at > https://codeberg.org/guix/guix/settings/collaboration (visible to “owners” > I presume). It indeed looks like this page is only accessible to owners of the repository. I get a 404 error when I try to load it. In the s

Re: Impossible to push patches to codeberg

Ludovic Courtès skribis: > Hello! > > Vagrant Cascadian writes: > >> > git push --set-upstream origin vagrantc-test >> Enumerating objects: 44, done. >> Counting objects: 100% (44/44), done. >> Delta compression using up to 8 threads >> Compressing objects: 100% (10/10), done. >> Wri

Re: Impossible to push patches to codeberg

Leo Famulari skribis: > Is this still a problem? It worked fine for me yesterday. Yes, I still get the "Forgejo: User permission denied for writing" error. signature.asc Description: PGP signature

Impossible to push patches to codeberg

Hi. I reviewed a few patches and tried to push them to the master branch, but it fails with: --8<---cut here---start->8--- Total 25 (delta 20), réutilisés 0 (delta 0), réutilisés du paquet 0 (depuis 0) remote: remote: Forgejo: User permission denied for writing

Re: Committers: create and share your Codeberg account

Ludovic Courtès skribis: > Hello Guix! > > If you’re a committer, please consider creating an account on Codeberg. > > To avoid problems, I suggest you send your account name as a public > reply to this message, in a signed message. > > You will be given rights on Codeberg according to the “Right

Re: [bug#76503] [GCD] Deliberation on: Migrating repositories, issues, and patches to Codeberg

Ludovic Courtès skribis: > Hello Guix, > > It’s been two months since we started discussing GCD 002, entitled > “Migrating repositories, issues, and patches to Codeberg”. Its final > version is attached below. > > In accordance with the GCD process, team members have until May 6th to > participa

Re: Deliberation period for GCD 003 "Rename the default branch" has technically started

Liliana Marie Prikler skribis: > Hi Guix, > > as the date for the GCD 003 was set to February 18th, the discussion > period actually ended on Saturday already. I have incorporated some > changes on Sunday to realign the proposal with GCD 002 (the Codeberg > one), but barring any emergency change

Re: Common Lisp packaging conventions

Konrad Hinsen skribis: > Hi everyone, > > I have packaged but not yet submitted CommonDoc > (https://github.com/CommonDoc/common-doc) for Guix. What has kept me so > far from submitting it is an uncertainty about conventions for > packaging Common Lisp code. > > The repository cited above contain

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 allte

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 sbc

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 /gnu/store/sbbp9nvslqcf3bmcnz5wgxf2qpsi757

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 works

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 print

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 support

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/infra

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 sign

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 Referenced

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: - ble

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; l

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 mak

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 thi

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: > > https://git.sr.h

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 --asdf-sy

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 "gu

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`: > > https://git.sr.ht

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 v

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

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&

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: ~/.config/common-lisp/source-registry.

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 i

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 way

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 package

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 is

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 libxmlplusplu

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, fee

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? :) &

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

[core-updates-frozen] Bug in binutils 1.37

rks, should I push this fix 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

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 b

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 a

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 pro

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 best

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 p

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 g

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 levels,

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 '/gnu/store/shv4x9d7ghpxgvxira3hy85hs3c2b73j

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 here-

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 s

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 (sources)

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

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

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 in

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 p

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 > texliv

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 > > https://old.reddit.com/r/linuxquestions/comments/g7t38d/mounting_an_encrypted_zfs_home_fi

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 the

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'. signa

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 hdf

Re: Looking for help with packaging a Common Lisp library

7d408bc57 Mon Sep 17 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

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 here---start-

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 occurred

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 2b

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 occurred

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 > definiti

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 "236

  1   2   >