bug#44626: tests/build-utils, tests/guix-system: fail when build path contains "~"

When building from a build path containing a "~", such as: /build/guix-1WL3Dl/guix-1.2.0~rc1/ tests/build-utils.scm and tests/guix-system.sh both fail. I've observed this with v1.2.0rc1, as well as c6e8f40f2ce6082171c18b4aad9877b0ad022563. Building in such a directory revealed two failing

bug#44612: Read standard input in `guix repl'

Dear, On Fri, 13 Nov 2020 at 20:08, Bengt Richter wrote: > Would this enable people to type something like > wget -O - http:try.this.for.example.com/fun.mischief|guix repl - > and if so, can you suggest some options for automatic hash or signature > checking so that a paranoid could feel

bug#36376: bug#35594: bug#36376: Application menu of desktop environment not automatically updated

Ludovic Courtès skribis: >>From 7d03b2b823951219ece46c7f34e25ae36a8ba12c Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= > Date: Thu, 12 Nov 2020 16:35:24 +0100 > Subject: [PATCH] gnu: glib: Graft patch to detect changes to the installed > applications. > > Fixes

bug#44612: Read standard input in `guix repl'

Pierre, Pierre Neidhardt 写道： The only issue is that it needs to be passed a file, so I must create a temporary file so that I can call `guix repl` on it. A magic ‘-’ alias is nice, providing ‘guix repl -- -’ still DTRT (I know, who does that, but still). But why can't you just pipe your

bug#44612: Read standard input in `guix repl'

Hi Pierre, On +2020-11-13 10:41:38 +0100, Pierre Neidhardt wrote: > `guix repl` is a fantastic, hassle-free tool to bind Guix with > third-party languages. I've done it here: > > https://github.com/atlas-engineer/nyxt/blob/2-pre-release-4/libraries/ospama/ospama-guix.lisp > > It just works! >

bug#43579: g++ does not provide std::fegetround

Hi! Ludovic Courtès writes: >[...] > It’s the same story as . >[...] > So this is again #include_next not picking the right due to > search path ordering issues and/or duplicate entries. > > Thoughts anyone? > > I think we need a proper fix but the feedback we

bug#44619: [PATCH] Expose some functions for guix.el

Ludovic Courtès writes: > In general, code outside the repo should not use ‘@@’ at all to refer to > Guix internals; we should ensure this is the case for Emacs-Guix. > > Actually, even code within Guix should avoid it. :-) Indeed. I submitted some patches to emacs-guix to remedy this:

bug#44619: [PATCH] Expose some functions for guix.el

Hi John, John Soo skribis: > From 7f718484fe952b674c2cdaa70315d49df3c8aa57 Mon Sep 17 00:00:00 2001 > From: John Soo > Date: Thu, 12 Nov 2020 21:47:36 -0800 > Subject: [PATCH 1/2] guix pack: Expose some bindings for third-party use. > > * guix/scripts/pack.scm (compressor-name,

bug#43448: Closed by 41170

bug#44619: [PATCH] Expose some functions for guix.el

Hi zimoun, zimoun writes: >> diff --git a/guix/scripts/pack.scm b/guix/scripts/pack.scm >> index 8e694edbbe..b6dfcb5f6a 100644 >> --- a/guix/scripts/pack.scm >> +++ b/guix/scripts/pack.scm >> @@ -58,11 +58,14 @@ >>#:use-module (srfi srfi-37) >>#:use-module (ice-9 match) >>#:export

bug#41419: Closed by 41170

bug#44619: [PATCH] Expose some functions for guix.el

Hi John, Thank you for raising this. > diff --git a/guix/scripts/pack.scm b/guix/scripts/pack.scm > index 8e694edbbe..b6dfcb5f6a 100644 > --- a/guix/scripts/pack.scm > +++ b/guix/scripts/pack.scm > @@ -58,11 +58,14 @@ >#:use-module (srfi srfi-37) >#:use-module (ice-9 match) >

bug#44558: Mesa isn't update to date

Guillaume Le Vaillant writes: > I saw that issue 803 of gst-plugin-good has been closed with patch > 2ce5909f; are there other things blocking the merge of the 'staging' > branch into 'master'? Now 'gst-plugins-bad' fails on i686:

bug#25304: Libtool’s ltmain.sh still contains a /gnu/store shebang

Hi, I was looking through the lists because I have a patch that does exactly what you describe here. I guess this goes to core updates, so this version is on top of it. WDYT? Happy hacking! Miguel l...@gnu.org (Ludovic Courtès) writes: > Hi, > > Commit

bug#44619: [PATCH] Expose some functions for guix.el

Hi Guix, guix.el Has been broken for quite some time because it depends on @@ for some modules. After some review, I came to the conclusion that all of the bindings it uses can be safely exposed. In general, it uses mostly bindings from guix scripts (pack, build, etc). Those bindings seem

bug#44558: Mesa isn't update to date

Marius Bakke skribis: > Guillaume Le Vaillant writes: > >> Tobias Geerinckx-Rice via Bug reports for GNU Guix >> skribis: >> >>> Romulasry, are you suffering from specific Mesa 20.0.7 problems that 20.2.2 >>> might fix? Please let us know. An otherwise working package not being at >>> the