bug#50596: Cannot get guix copy to work...

[zimoun]

Hi Stephen,

On Wed, 15 Sep 2021 at 19:32, Stephen Paul Weber  
wrote:
> Ah, finally found http://issues.guix.gnu.org/43739 -- guix pull as
> root and all fixed.

Thanks for the follow up.
Does it mean this bug can be closed?


All the best,
simon

bug#50613: guix copy does not respect --no-grafts

[Stephen Paul Weber]

If I use guix archive --export --no-grafts then import on another system, then
guix build -n --no-grafts it works as expected.  If instead I use guix copy
--no-grafts then the target system gets the version *with* grafts and guix build
-n --no-grafts says it would still need to build.


signature.asc
Description: PGP signature

bug#50596: Cannot get guix copy to work...

[Stephen Paul Weber]

Ah, finally found http://issues.guix.gnu.org/43739 -- guix pull as root and all 
fixed.


signature.asc
Description: PGP signature

bug#50596: Cannot get guix copy to work...

[Stephen Paul Weber]

It seems I get the same error even with just guix archive:

$ guix archive --export -r package

... snip lots of output ...

entry(nameunitnode(type 
directoryentry(namepromise_spec.rbnode(typeregulacontents�nguix archive: error: 
corrupt input while restoring archive from #


signature.asc
Description: PGP signature

bug#50567: [core-updates-frozen] icedtea-6 fails to build.

[Julien Lepiller]

Sorry for the possible confusion. These replies stacked up in my client and I 
didn't notice until they were sent just now. Please disregard :)

Le 14 septembre 2021 07:37:53 GMT-04:00, Julien Lepiller  a 
écrit :
>Again this is exactly where I was blocked. There is a checksum being generated 
>in classlist files from java code during the build. The classlist file is 
>exactly the same as the one in master, so it's correctly generated. Fowever, 
>at some point, the process needs toqload that file, and that ultimately calls 
>some C code (identical to the java code) that re-computes and compares the 
>checksum. After printing some values, it seems that it always computes "0…031" 
>as the hash of any classlist file, despite running the function and taking 
>everything into account. I think this is again an optimization issue, anl it's 
>not clear how to work around that.
>
>Le 14 septembre 2021 04:44:18 GMT-04:00, "Ludovic Courtès"  a 
>écrit :
>>Hi Guillaume,
>>
>>Guillaume Le Vaillant  skribis:
>>
>>> I'm trying to get icedtea-6 to build on the core-updates-frozen branch.
>>> I fixed a few C/C++ related issues,
>>
>>Thanks for fixing those!  After 
>>Julien mentioned on IRC that using an older GCC allowed us to work
>>around those C++ issues, but your approach looks nicer to me.
>>
>>> but then I get this error:
>>>
>>> Preload failed: checksum of class list was incorrect.
>>> make: *** [Makefile:2746: stamps/add-archive-ecj.stamp] Error 1
>>
>>Woow, never seen that.  Julien, Ricardo, does that ring a bell?
>>
>>Java is the main stumbling block on core-updates-frozen; making
>>progress!
>>
>>Thanks,
>>Ludo’.

bug#50604: [core-updates-frozen] make check-system tests broken

[muradm]

Hi,

Currently execution of any system tests with "make check-system 
..." seems
to be broken. Tests are getting executed, and their status is 
"pass" in
the log. But, some in some place around the test execution, below 
exception

is fired.

--8<---cut here---start->8---
This is the GNU system.  Welcome.
komputilo login: shepherd: changing HTTP/HTTPS proxy of 
'guix-daemon' to "http://localhost:8118;...

shepherd: Service guix-daemon has been stopped.
shepherd: Service guix-daemon has been started.
shepherd: clearing HTTP/HTTPS proxy of 'guix-daemon'...
shepherd: Service guix-daemon has been stopped.
shepherd: Service guix-daemon has been started.
Backtrace:
  4 (primitive-load 
  "/gnu/store/638i01a9gj6zknrcyp78n9pc434?")

In ice-9/eval.scm:
  191:35  3 (_ #f)
  196:35  2 (_ #f)
   263:9  1 (_ #(#(#) #f))
   155:9  0 (_ _)

ice-9/eval.scm:155:9: In procedure struct-vtable: Wrong type 
argument in position 1 (expecting struct): #f

QEMU runs as PID 10
connected to QEMU's monitor
read QEMU monitor prompt
connected to guest REPL
 Starting test basic  (Writing full log to "basic.log")
marionette is ready

;;; (services (console-font-tty2 user-homes mcron term-tty4 udev 
   term-tty2 syslogd console-font-tty5 user-processes 
   console-font-tty6 file-system-/sys/firmware/efi/efivars 
   loopback)

# of expected passes  27
# of skipped tests1
note: keeping build directory `/tmp/guix-build-basic.drv-1'
builder for 
`/gnu/store/2rk2jzv97s2cjipz8s64fv70ya9f8sii-basic.drv' failed 
with exit code 1
build of /gnu/store/2rk2jzv97s2cjipz8s64fv70ya9f8sii-basic.drv 
failed
View build log at 
'/var/log/guix/drvs/2r/k2jzv97s2cjipz8s64fv70ya9f8sii-basic.drv.bz2'.
guix build: error: build of 
`/gnu/store/2rk2jzv97s2cjipz8s64fv70ya9f8sii-basic.drv' failed

make: *** [Makefile:7039: check-system] Error 1
--8<---cut here---end--->8---

Thanks in advance,
muradm

bug#50600: Problem with package perl-lingua-translit

[Evgeny Pisemsky]

After installing the package perl-lingua-translit and trying to use its 
accompanied utility translit the following error appears:

$ translit -l
Can't locate Lingua/Translit.pm in @INC (you may need to install the 
Lingua::Translit module) (@INC contains: 
/gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/site_perl/5.30.2/x86_64-linux-thread-multi
 
/gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/site_perl/5.30.2
 
/gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/5.30.2/x86_64-linux-thread-multi
 /gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzjry-perl-5.30.2/lib/perl5/5.30.2) at 
/home/user/.guix-profile/bin/translit line 17.
BEGIN failed--compilation aborted at /home/user/.guix-profile/bin/translit line 
17.

bug#50606: Add support for other formats of Guix channels

[EuAndreh via Bug reports for GNU Guix]

As I've described in [0], one can't have a Guix channel served over Git's
"Dumb HTTP" protocol.  That is caused by libgit's inability to do so [1].

Guix channel authors may want to serve channels:
- via "Dumb HTTP" Git repositories;
- via other DVCS like Mercurial, Fossil, BitKeeper;
- decoupled from the backing versioning tool.

My initial though is that making Guix knowing how to handle channels served as
tarballs would suffice, and cover all of the above.  Those channels wouldn't
have the exact same caching and authentication characteristics as channels
served via Git repositories, but that seems OK.

WDYT?

[0]: 
https://yhetil.org/guix-user/162732098483.1190082.2428052336447457010@localhost/t/#m8bb1fc83a8eccd9819085432a59bad9257ef434a
[1]: https://github.com/libgit2/libgit2/issues/4652#issuecomment-390903142

bug#50567: [core-updates-frozen] icedtea-6 fails to build.

[Julien Lepiller]

I had the same issue on my previous attempt. It seems that using gcc-7 as an 
input fixes the issue (although when I tried, I had other fixes like yours 
too). Our gcc on core-updates seems to be too aggressive with this old code 
base.

Le 13 septembre 2021 09:01:55 GMT-04:00, Guillaume Le Vaillant 
 a écrit :
>I'm trying to get icedtea-6 to build on the core-updates-frozen branch.
>I fixed a few C/C++ related issues, but then I get this error:
>
>--8<---cut here---start->8---
>Preload failed: checksum of class list was incorrect.
>make: *** [Makefile:2746: stamps/add-archive-ecj.stamp] Error 1
>--8<---cut here---end--->8---
>
>Does someone know how to solve that?
>
>Here's the patch I'm using to get to this point:

bug#50567: [core-updates-frozen] icedtea-6 fails to build.

[Julien Lepiller]

Again this is exactly where I was blocked. There is a checksum being generated 
in classlist files from java code during the build. The classlist file is 
exactly the same as the one in master, so it's correctly generated. Fowever, at 
some point, the process needs toqload that file, and that ultimately calls some 
C code (identical to the java code) that re-computes and compares the checksum. 
After printing some values, it seems that it always computes "0…031" as the 
hash of any classlist file, despite running the function and taking everything 
into account. I think this is again an optimization issue, anl it's not clear 
how to work around that.

Le 14 septembre 2021 04:44:18 GMT-04:00, "Ludovic Courtès"  a 
écrit :
>Hi Guillaume,
>
>Guillaume Le Vaillant  skribis:
>
>> I'm trying to get icedtea-6 to build on the core-updates-frozen branch.
>> I fixed a few C/C++ related issues,
>
>Thanks for fixing those!  After 
>Julien mentioned on IRC that using an older GCC allowed us to work
>around those C++ issues, but your approach looks nicer to me.
>
>> but then I get this error:
>>
>> Preload failed: checksum of class list was incorrect.
>> make: *** [Makefile:2746: stamps/add-archive-ecj.stamp] Error 1
>
>Woow, never seen that.  Julien, Ricardo, does that ring a bell?
>
>Java is the main stumbling block on core-updates-frozen; making
>progress!
>
>Thanks,
>Ludo’.

bug#50605: go: Commit d36c73b8a8f breaks `go tool`

[Katherine Cox-Buday]

Aside from not being able to issue ~go tool~ commands, things like
~gopls~[1] are broken as well.

By design, ~GOTOOLDIR~ cannot be set from the user's environment[2].
This commit moved the directory, but did not update the ~GOTOOLDIR~
path.

#+begin_example
  $ env |grep GOTOOLDIR

  $ go env GOTOOLDIR
  /home/katco/.guix-profile/pkg/tool/linux_amd64

  $ export GOTOOLDIR=/tmp

  $ env |grep GOTOOLDIR
  GOTOOLDIR=/tmp

  $ go env GOTOOLDIR
  /home/katco/.guix-profile/pkg/tool/linux_amd64

  $ go env -w GOTOOLDIR=/tmp
  go env -w: GOTOOLDIR cannot be modified

  $ [ -e $(go env GOTOOLDIR) ] || echo Nope, not here.
  Nope, not here.

  $ [ -e /home/katco/.guix-profile/lib/go/pkg/tool ] && echo Here it is
  Here it is
#+end_example

I think these are the lines to blame:

#+begin_example
  d36c73b8a8f (Sarah Morgensen 2021-09-02  763)
(for-each
  d36c73b8a8f (Sarah Morgensen 2021-09-02  764) 
(lambda (file)
  d36c73b8a8f (Sarah Morgensen 2021-09-02  765) 
  (copy-recursively file (string-append out "/lib/go/" file)))
  d36c73b8a8f (Sarah Morgensen 2021-09-02  766) 
'("lib" "VERSION" "pkg/include" "pkg/tool"))
#+end_example

[1] - https://pkg.go.dev/golang.org/x/tools/gopls
[2] - https://github.com/golang/go/issues/10264#issuecomment-91394026

--
Katherine

bug#50483: [R] Package r-shiny: Shiny server logic inactive

[zimoun]

Hi,

Thanks for the report.

IIUC, the package uglify-js from gnu/packages/lisp-xyz was previously
used to minify and now replaced by the new uglifyjs package from the new
gnu/packages/uglifyjs.  Then something is incompatible.

I propose to revert to the Lisp JavaScript compressor instead of the
Node one.  JS people, WDYT?


On jeu., 09 sept. 2021 at 12:35, Todor Kondić  wrote:

> ```r
> library(ggplot2)
> library(shiny)
>
>
> app <- shinyApp(
> ui = bootstrapPage(
> numericInput('n', 'Number of obs', 100),
> plotOutput('plot')
> ),
> server = function(input, output) {
> output$plot <- renderPlot({ hist(runif(input$n)) })
> }
> )
>
>
> # Will show a warning, because the browser is not in the manifest, but
> # it it will serve the application on a listed port, which means it
> # can be accessed by a browser external to the environment.
> options(browser="itdoesnotmatter")
> shiny::runApp(app)
>
> ```

Using the R script above, and running:

guix time-machine --commit=
 -- environment --ad-hoc r r-shiny r-ggplot2
 -- R -e 'source("script.r")'

to bisect, the commit introducing a regression is:

--8<---cut here---start->8---
commit 385c485c651c0b1a467bdbbf31fa723dc4cabd9e
Author: Charles 
Date:   Mon Jul 12 22:50:44 2021 -0500
build: Update uglifyjs for minify-build-system.

* guix/build-system/minify.scm (default-uglify-js): Update uglifyjs package 
used.
* guix/build/minify-build-system.scm (minify): Use updated uglifyjs command 
name.

Signed-off-by: Efraim Flashner 
 guix/build-system/minify.scm   | 4 ++--
 guix/build/minify-build-system.scm | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)
--8<---cut here---end--->8---

with the Bisect Log (14):

816d52ba93 bad gnu: Add r-megadepth.
29745d23b8 good gnu: Use define-public in (gnu packages xiph).
aa6e6fb2e9 good gnu: Add ytfzf.
c8bcef2598 bad gnu: sameboy: Update to 0.14.4.
d84c24935b bad gnu: icedove: Update to 78.12.0 [security fixes].
026bd0b219 good gnu: r-matrixcalc: Update to 1.0-4.
7da8f66e52 good gnu: password-store: Fix passmenu paths substitution.
a49c5488bd good gnu: Add putty.
b019496fc3 good pack/deb: Add default section and priority fields to 
the control file.
bfa847dbe0 good gnu: Add node-acorn.
3436d3f801 bad gnu: Add emacs-zmq.
4cda5a4dab bad gnu: git-annex: Update to 8.20210714.
385c485c65 bad build: Update uglifyjs for minify-build-system.
d16148fcfd good gnu: Add node-uglify-js.
385c485c651c0b1a467bdbbf31fa723dc4cabd9e is the first bad commit


Cheers,
simon

bug#50264: ca-certificate-bundle fails to build

[Ludovic Courtès]

And for posterity, here’s the script I used to reproduce the problem:
it’d pick 10 packages at random and call ‘ca-certificate-bundle’ on them.

Since this bug depends on what’s in the store, I’d run it on my laptop,
which only contains a fraction of the 18K packages in Guix, so it would
reproduce the bug after a couple of iterations.

That, together with the inevitable ‘pk’ calls plus a bit of chance, voilà!

Ludo’.

;; https://issues.guix.gnu.org/50264

(use-modules (gnu) (guix)
 (guix profiles) (guix monads)
 (ice-9 match) (srfi srfi-1))

(define (all-packages)
  "Return the list of all the packages, public or private, omitting only
superseded packages."
  (fold-packages (lambda (package lst)
   (match (package-replacement package)
 (#f (cons package lst))
 (replacement
  (append (list replacement package) lst
 '()
 #:select? (negate package-superseded)))

(define (random-seed)
  (logxor (getpid) (car (gettimeofday

(define shuffle   ;from offload.scm
  (let ((state (seed->random-state (random-seed
(lambda (lst)
  "Return LST shuffled (using the Fisher-Yates algorithm.)"
  (define vec (list->vector lst))
  (let loop ((result '())
 (i (vector-length vec)))
(if (zero? i)
result
(let* ((j (random i state))
   (val (vector-ref vec j)))
  (vector-set! vec j (vector-ref vec (- i 1)))
  (loop (cons val result) (- i 1

(define (test packages)
  (pk 'testing-packages (map package-full-name packages))
  (let ((manifest (packages->manifest packages)))
(with-store store
  (let ((drv (run-with-store store
   (ca-certificate-bundle manifest
(pk 'drv drv)
(unless (find (lambda (input)
(let ((drv (derivation-input-derivation input)))
  (string-prefix? "glibc-utf8-locales"
  (derivation-name drv
  (derivation-inputs drv))
  (pk 'drv drv (derivation-inputs drv))
  (display-backtrace (make-stack #t) (current-error-port))
  (error "bah!" drv))
(newline) (newline)

(let loop ((packages (shuffle (all-packages
  (test (take packages 10))
  (loop (drop packages 10)))

bug#50264: ca-certificate-bundle fails to build

[Ludovic Courtès]

And for posterity, here’s the script I used to reproduce the problem:
it’d pick 10 packages at random and call ‘ca-certificate-bundle’ on them.

Since this bug depends on what’s in the store, I’d run it on my laptop,
which only contains a fraction of the 18K packages in Guix, so it would
reproduce the bug after a couple of iterations.

That, together with the inevitable ‘pk’ calls plus a bit of chance, voilà!

Ludo’.

;; https://issues.guix.gnu.org/50264

(use-modules (gnu) (guix)
 (guix profiles) (guix monads)
 (ice-9 match) (srfi srfi-1))

(define (all-packages)
  "Return the list of all the packages, public or private, omitting only
superseded packages."
  (fold-packages (lambda (package lst)
   (match (package-replacement package)
 (#f (cons package lst))
 (replacement
  (append (list replacement package) lst
 '()
 #:select? (negate package-superseded)))

(define (random-seed)
  (logxor (getpid) (car (gettimeofday

(define shuffle   ;from offload.scm
  (let ((state (seed->random-state (random-seed
(lambda (lst)
  "Return LST shuffled (using the Fisher-Yates algorithm.)"
  (define vec (list->vector lst))
  (let loop ((result '())
 (i (vector-length vec)))
(if (zero? i)
result
(let* ((j (random i state))
   (val (vector-ref vec j)))
  (vector-set! vec j (vector-ref vec (- i 1)))
  (loop (cons val result) (- i 1

(define (test packages)
  (pk 'testing-packages (map package-full-name packages))
  (let ((manifest (packages->manifest packages)))
(with-store store
  (let ((drv (run-with-store store
   (ca-certificate-bundle manifest
(pk 'drv drv)
(unless (find (lambda (input)
(let ((drv (derivation-input-derivation input)))
  (string-prefix? "glibc-utf8-locales"
  (derivation-name drv
  (derivation-inputs drv))
  (pk 'drv drv (derivation-inputs drv))
  (display-backtrace (make-stack #t) (current-error-port))
  (error "bah!" drv))
(newline) (newline)

(let loop ((packages (shuffle (all-packages
  (test (take packages 10))
  (loop (drop packages 10)))

bug#50264: ca-certificate-bundle fails to build

[Ludovic Courtès]

Hi!

Ludovic Courtès  skribis:

> I’m wondering whether this could be due to
> fa81971cbae85b39183ccf8f51e8d96ac88fb4ac somehow.

Confirmed!  In essence, ‘map/accumulate-builds’ would return the tail of
its ‘lst’ argument unprocessed when cutoff was reached (ouch!).  Fixed:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f72f4b48c6777da9465ab17baa6762476d6cb270

Let me know if you still experience fishy behavior!

Ludo’.

bug#50580: GDM doesn't start

[Maxime Devos]

Possibly related to:

https://issues.guix.gnu.org/35296 ‘gdm doesn't start at boot’

The message in Xorg.1.log is similar.

It seems suspicious to me that 'gdm-shepherd-service' doesn't have 'elogind'
in its requirements, but 'sddm-shepherd-service' does.  I tried adding
'elogind' but that didn't fix anything.

There's something else that seems suspicious to me: elogind can be started
by two methods: by 'elogind-shepherd-service' and via D-Bus.  It appears that,
if elogind is started via D-Bus, then it can't be started via 
elogind-shepherd-service
anymore, so herd can think elogind failed to start even though it was started 
with
D-Bus?  That didn't seem the case on the test VM though ...

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#47335: Hide GHC not used for building Was: xmonad fails to recompile on guix system

[zimoun]

Hi,

On Wed, 15 Sept 2021 at 13:02, Xinglu Chen  wrote:

> Agreed, but I guess using the ‘-next’ suffix was be the easiest
> workaround for now.

Yeah but more than often, the workarounds remain longer than expected
and thus they cannot be considered as workaround. ;-)

> Maybe running ‘guix install ghc’ should install the GHC package that the
> ‘ghc’ variable refers to.  Then this would not only apply to language
> ecosystems, but all packages in general.  Right now running ‘guix
> install rsync’ installs the ‘rsync-next’ package, but I would expect it
> to install the package that the ‘rsync’ variable is bound to.

Well, the name has to be distinguished from the symbol.  The symbol
name does not matter from a CLI point of view; and usually not so much
from a regular user perspective.

What really matters, IMHO, is the name and the version.  Basically,
"guix install foo" will install the latest version of the package
'foo'.  To avoid this, the trick is to tweak to the name of the latest
version.  It is what happens with 'rsync'; so to be in agreement with
the '-next' approach, the name should be 'rsync-next' and not 'rsync'.

Anyway, we all agree that something is odd. :-)

Cheers,
simon

bug#25138: guix import hackage darcs: fails due to flag executable

[Lars-Dominik Braun]

Hi,

this was fixed by the patch from #50588.

Cheers,
Lars

bug#50264: ca-certificate-bundle fails to build

[Ludovic Courtès]

Hi,

Lars-Dominik Braun  skribis:

> I started the Guix daemon with only the CI substitute server enabled
> explicitly, disabled local discovery, ran a `guix gc` and tried again. It
> still fails with exactly the same issue.

I’m wondering whether this could be due to
fa81971cbae85b39183ccf8f51e8d96ac88fb4ac somehow.

If you have a reliable way to test this hypothesis, that’d be great.

Thanks,
Ludo’.

bug#50580: GDM doesn't start

[Maxime Devos]

Maxime Devos schreef op di 14-09-2021 om 14:46 [+0200]:
> Hi,
> 
> The GDM service doesn't start anymore.  To test, you can use the attached
> xorg-repro.tmpl (guix system vm xorg-repro.tml && run the resulting script).
> QEMU will start, and it will start booting, but nothing graphical will start.
> If you switch to the last virtual terminal, you will see
> 
> [date] localhost shepherd[1]: Respawning xorg-server.
> [date] localhost shepherd[1]: Service host-name has been started.
> [date] localhost shepherd[1]: Service xorg-server has been started.
> [..]
> [date] localhost shepherd[1]:   (Respawning too fast.)
> 
> GDM used to work for me with commit 75a3413b4e5c1f7443eb944a36ff364f4c4085f4,
> but was broken with e9b87da1c3000c53cf9dbf5e737aa4d6546bd909.  To be bisected?

I did some bisecting.  9cd89b1206cf9288fc26b09f3f34883c6e309824 is a bad commit

commit 9cd89b1206cf9288fc26b09f3f34883c6e309824
Author: Tobias Geerinckx-Rice 
Date:   Fri Sep 3 20:45:34 2021 +0200

gnu: hplip: Update to 3.21.6.

* gnu/packages/cups.scm (hplip): Update to 3.21.6.

and the previous commit 7be258c0ddae175450622884920d42a758bbced6 is good.

> Greetings,
> Maxime.


signature.asc
Description: This is a digitally signed message part

bug#50580: GDM doesn't start

[Maxime Devos]

Maxime Devos schreef op di 14-09-2021 om 14:46 [+0200]:
> GDM used to work for me with commit 75a3413b4e5c1f7443eb944a36ff364f4c4085f4,
> but was broken with e9b87da1c3000c53cf9dbf5e737aa4d6546bd909.  To be bisected?

The second commit is wrong.  Prsumably it should have been
9875f9bca3976bf3576eab9be42164fde454597e.

> Greetings,
> Maxime.
> 
> (xorg-repro.templ is based on the vm-image.tmpl configuration)


signature.asc
Description: This is a digitally signed message part

bug#47335: Hide GHC not used for building Was: xmonad fails to recompile on guix system

[Xinglu Chen]

On Wed, Sep 15 2021, zimoun wrote:

> Hi,
>
> On Wed, 15 Sept 2021 at 09:43, Lars-Dominik Braun  wrote:
>
>> > I'd be very much in favor of the latter, or maybe rename it to ghc-next.
>> > I have some profiles ghc pinned to a version and upgrading those is
>> > always a mess because Guix tries to build the old version from source
>> > instead of using the next version.
>>
>> I renamed ghc@8.8 to ghc-next in commit
>> 39b43d0d0428474a1d0bf58779d0135163b9c6e3.
>
> Well, I am late to the party and probably out of point but I think
> this '-next' is not something we should introduce and generalize.
> Well, who knows if these '-next' will be the real next. ;-)   My
> comment is also about guile-next, emacs-next and python-next.  Noting
> that gcc-toolchain does not have a '-next'; packages are built using
> 7.5.0 but "guix install gcc-toolchain" will install 11.2.0 and then it
> could lead to the same issue as the one reported with GHC, I guess.
>
> Instead of this '-next' trick, we should find a better mechanism where
> "guix install ghc" would install the default GHC used by the Haskell
> build-system.  Idem for the others guile-next, python-next etc..  And
> any other version should be installed using  the explicit mention,
> i.e., "guix install ghc@8.8", IMHO.

Agreed, but I guess using the ‘-next’ suffix was be the easiest
workaround for now.

Maybe running ‘guix install ghc’ should install the GHC package that the
‘ghc’ variable refers to.  Then this would not only apply to language
ecosystems, but all packages in general.  Right now running ‘guix
install rsync’ installs the ‘rsync-next’ package, but I would expect it
to install the package that the ‘rsync’ variable is bound to.


signature.asc
Description: PGP signature

bug#47335: Hide GHC not used for building Was: xmonad fails to recompile on guix system

[zimoun]

Hi,

On Wed, 15 Sept 2021 at 09:43, Lars-Dominik Braun  wrote:

> > I'd be very much in favor of the latter, or maybe rename it to ghc-next.
> > I have some profiles ghc pinned to a version and upgrading those is
> > always a mess because Guix tries to build the old version from source
> > instead of using the next version.
>
> I renamed ghc@8.8 to ghc-next in commit
> 39b43d0d0428474a1d0bf58779d0135163b9c6e3.

Well, I am late to the party and probably out of point but I think
this '-next' is not something we should introduce and generalize.
Well, who knows if these '-next' will be the real next. ;-)   My
comment is also about guile-next, emacs-next and python-next.  Noting
that gcc-toolchain does not have a '-next'; packages are built using
7.5.0 but "guix install gcc-toolchain" will install 11.2.0 and then it
could lead to the same issue as the one reported with GHC, I guess.

Instead of this '-next' trick, we should find a better mechanism where
"guix install ghc" would install the default GHC used by the Haskell
build-system.  Idem for the others guile-next, python-next etc..  And
any other version should be installed using  the explicit mention,
i.e., "guix install ghc@8.8", IMHO.

Cheers,
simon

bug#50592: Can't guix system init with grub-efi-bootloader from system that boots using grub-bootloader

[pelzflorian (Florian Pelz)]

Hello Zacchaeus.

On Tue, Sep 14, 2021 at 06:33:17PM -0400, Zacchaeus Scheffer wrote:
> I want to put grub-efi-bootloader
> (EFI) on the new drive install (for use on another computer).

With ordinary configuration, I believe installing GRUB EFI for use on
another computer is impossible, because grub install for EFI wants to
store boot information on the main board’s NVRAM, not on the disk.
Except when installing on a USB flash drive using the --removable
option, that is.

You could try manually executing the command

On Tue, Sep 14, 2021 at 06:33:17PM -0400, Zacchaeus Scheffer wrote:
> '/gnu/store/w8v5d1i6xfqlpj78w89jg1x7f8dchh4k-grub-efi-2.06/sbin/grub-install
> --boot-directory /mnt/jake/boot --bootloader-id=Guix --efi-directory
> /boot/efi'

as if you were installing to a USB flash drive, by adding --removable
and otherwise using exactly the same command.  It might work, since
you already have installed the system successfully except for the
bootloader.

This is in imitation of what the GRUB manual says:
> For removable installs you have to use --removable and specify both 
> --boot-directory and --efi-directory: 
>
> # grub-install --efi-directory=/mnt/usb --boot-directory=/mnt/usb/boot 
> --removable

I’m not sure enough of what can be done, but I believe this bug is a
WONTFIX.  What do others think?

Regards,
Florian

bug#47335: Hide GHC not used for building Was: xmonad fails to recompile on guix system

[Lars-Dominik Braun]

Hi,

> I'd be very much in favor of the latter, or maybe rename it to ghc-next.
> I have some profiles ghc pinned to a version and upgrading those is
> always a mess because Guix tries to build the old version from source
> instead of using the next version.
I renamed ghc@8.8 to ghc-next in commit
39b43d0d0428474a1d0bf58779d0135163b9c6e3.

Cheers,
Lars

bug#50264: ca-certificate-bundle fails to build

[Lars-Dominik Braun]

Hi Leo,

> I wonder if the problem began after the introduction of
> bordeaux.guix.gnu.org, and if everyone who experiences the bug is using
> both substitute servers.
I started the Guix daemon with only the CI substitute server enabled
explicitly, disabled local discovery, ran a `guix gc` and tried again. It
still fails with exactly the same issue.

Lars