bug#48682: recursive import between (gnu packages chez) and (gnu packages racket)

On 5/27/21 10:02 PM, raingloom wrote: Well, here is a quick and obvious fix for now. This looks good to me. -Philip

bug#48682: recursive import between (gnu packages chez) and (gnu packages racket)

On 5/29/21 4:15 PM, Ludovic Courtès wrote: > In general we cannot use #:select for (gnu packages …) modules because > that doesn’t play well with circular module dependencies. Ah, interesting, I'll keep that in mind. I'm used to Racket, where all cyclic module dependencies cause errors at

bug#48682: recursive import between (gnu packages chez) and (gnu packages racket)

Hi, thanks! That said… what problem is this fixing raingloom? Usually, circular top-level references lead things like ‘guix show chez-scheme’ (this amounts to loading (gnu packages chez)), but it worked fine for me. It seems like some other commit may have broken the cycle in the mean time.

bug#48682: recursive import between (gnu packages chez) and (gnu packages racket)

Hi, I've been working on Racket packaging. I haven't looked into this much yet---hopefully I can tomorrow---but here are a few quick thoughts. On 5/26/21 2:54 PM, raingloom wrote: > I also haven't found any other mention of chez-scheme in racket.scm > other than the line that imports it, which

bug#47204: DrRacket fonts issue

Hi Jack, I haven't been able to reproduce this yet, but I'm on a foreign distro, and I don't have any fonts explicitly installed via Guix. (For that matter, I don't have a monitor connected, just now: I've done this with X forwarding.) I do have a few debugging ideas you could try and see if

bug#47614: [security] Chunked store references in .zo files in Racket 8 #47614

Ah, I see the thread for https://issues.guix.gnu.org/47614 wasn't cc'ed here: Forwarded Message Subject: Re: Racket 8 and store references (was [security] Chunked store references in .zo files in Racket 8 #47614) Date: Tue, 6 Apr 2021 21:38:57 -0400 From: Philip McGrath

bug#47064: [racket-users] bytevector-uncompress: internal error uncompressing

I've submitted a patch at https://issues.guix.gnu.org/47180 that I hope will resolve this issue. -Philip

bug#47064: [racket-users] bytevector-uncompress: internal error uncompressing

Jack, thanks for the pointer: I hadn't noticed this earlier. On 3/15/21 12:49 AM, Jack Hill wrote: ``` $bytevector-uncompress: internal error uncompressing

bug#47064: [racket-users] bytevector-uncompress: internal error uncompressing

I can reproduce the error with just: ``` $ racket -l mred/private/wx/gtk/utils $bytevector-uncompress: internal error uncompressing

bug#47064: [racket-users] bytevector-uncompress: internal error uncompressing

Aha! Running: guix environment --ad-hoc --no-grafts racket -- drracket launches DrRacket just fine. My guess is that Racket CS is compressing string literals in compiled code. Currently, Guix patches Racket source files to include the absolute paths to foreign libraries in the store as

bug#47614: [security] Chunked store references in .zo files in Racket 8

Hi Ludo’, On 4/16/21 11:46 AM, Ludovic Courtès wrote: IIUC, now that has been closed, this bug is fixed. Am I right? Yes, it seems to be fixed with respect to Racket, though Mark mentioned here in (also now fixed)

bug#47064: [racket-users] bytevector-uncompress: internal error uncompressing

Hi Mark and everyone, On 4/14/21 1:54 AM, Mark H Weaver wrote: Recall that the grafting code performs a set of substitutions, replacing store item names (i.e. file names in /gnu/store) with replacement store items of the same length, with rules like:

bug#50118: Racket: `raco exe` can't find Racket executable for variant cs

Thanks for the report! It seems that Guix's change in 8.2 to make `racket` a layered/tethered installation chaining to `racket-minimal` exposed a bug in Racket's `setup/variant` module. I've reported it upstream here: https://github.com/racket/racket/issues/3969 Hopefully it will be

bug#50118: Racket: `raco exe` can't find Racket executable for variant cs

The bug was fixed upstream, and I've submitted a patch at backporting the repair for Guix. -Philip

bug#52749: G-expressions don't consistently preserve #nil

Hi! Just as a general disclaimer, I'm a Racketeer and only incidentally a Schemer, so I'm not very familiar with the universe of Guile libraries. On 12/23/21 01:59, Maxime Devos wrote: > Philip McGrath schreef op wo 22-12-2021 om 23:25 [-0500]: >> G-expressions currently do not con

bug#53011: Possible to Update qtbase-5 to v5.15.8?

Hi, On 1/4/22 13:04, Florian Bruhin wrote: Hey, qutebrowser upstream here. On Tue, Jan 04, 2022 at 05:35:54PM +, Jaft wrote: Partially because it's the latest version but primarily because there's a bug in the current version for QTwebengine. Note that qtbase releases after 5.15.2 are

bug#52749: G-expressions don't consistently preserve #nil

G-expressions currently do not consistently preserve the distinction between #nil and '(), which causes trouble for programs that rely on that distinction. In particular, the issue affects programs that use (guix build json), because that library uses #nil to represent the JSON value `null',

bug#50118: Racket: `raco exe` can't find Racket executable for variant cs

This was fixed in Guix commit fd22921490f40044d58be8ddc3b38b8be12188a6 (September 10, 2021). See: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50419 -Philip

bug#54292: Commit e8518c43 breaks guix pull on i686

On Tuesday, March 8, 2022 10:32:48 AM EST Liliana Marie Prikler wrote: > > The error appears to be that nix-system->chez-machine was rather poorly > coded and overlooked in review. In particular, i686 should probably > also default to the i386 case. > I must for some reason not have been

bug#53907: font-ibm-plex has a nonfree dependency

Hi, On 2/9/22 16:39, Greg Farough wrote: Hi, Guix developers: As far as I can tell, the IBM Plex family of fonts requires the nonfree program FontLab Studio to build. ... This is one of the reasons Debian[3] has moved the font to the "contrib" section of its repos. IBM releases Plex as

bug#56376: emacs-guix missing from package-activated-list

Hi, I've been looking into managing my Emacs packages with Guix. I found that the `emacs-guix` package doesn't seem to show up in the `package-activated-list`, even though its dependencies do, which seems like a bug. Here's an illustration: ``` philip@avalon:/tmp/emacs-bug$ guix describe

bug#57593: Racket 8.6 is not reproducible

Hi, On Mon, Sep 5, 2022, at 6:04 AM, Ludovic Courtès wrote: > Hey, > > Just noticed that Racket does not build in a reproducible fashion: > > --8<---cut here---start->8--- > $ guix describe > Generation 227 Sep 04 2022 23:39:52(current) > guix aae98c2 >

bug#59299: Sequoia OpenPGP (libsequoia) build fails

The Sequoia OpenPGP packages are failing to build due to an error while building libsequoia. Here's the tail of the build log; I've attached the full log: ---8<---cut here---start->8--- Compiling openssl-macros v0.1.0 Compiling sequoia-ffi-macros v0.22.0

bug#61809: (gnu home services xdg): Wrong value for $XDG_STATE_HOME

Hi, The following part of the definition of `home-xdg-base-directories-configuration` in `(gnu home services xdg)` is wrong: ``` (state-home (path "$HOME/.local/var/lib") "Base directory for programs to store state files, like databases, analogus to @file{/var/lib}, but for user. It is