bug#24736: `make check` fails in tests/scripts-build.scm

[Mekeor Melire]

`make check` failed for me, using the latest HEAD in the master branch.
See the logs: http://lpaste.net/3131976193323040768

bug#24736: `make check` fails in tests/scripts-build.scm

[Mekeor Melire]

Am 19.10.2016 um 05:30 schrieb Leo Famulari:
> On Wed, Oct 19, 2016 at 02:04:48AM +0200, Mekeor Melire wrote:
>> `make check` failed for me, using the latest HEAD in the master branch.
>> See the logs: http://lpaste.net/3131976193323040768
> Hi, thanks for the report!
>
> --
> FAIL: tests/scripts-build.scm
>
> [...]
>
> 
> Testsuite summary for GNU Guix 0.11.0
> 
> # TOTAL: 635
> # PASS:  619
> # SKIP:  15
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> See ./test-suite.log
> [...]
> --
>
> Can you send 'test-suite.log'?
===
   GNU Guix 0.11.0: ./test-suite.log
===

# TOTAL: 635
# PASS:  619
# SKIP:  15
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

SKIP: tests/base32
==

sh: 1: nix-hash: not found
test-name: bytevector->base32-string
location: /home/mekeor/cod/em/guix/tests/base32.scm:48
source:
+ (test-assert
+   "bytevector->base32-string"
+   (fold (lambda (bv expected result)
+   (and result
+(string=?
+  (bytevector->base32-string bv)
+  expected)))
+ #t
+ (map string->utf8
+  '("" "f" "fo" "foo" "foob" "fooba" "foobar"))
+ '(""
+   "my"
+   "mzxq"
+   "mzxw6"
+   "mzxw6yq"
+   "mzxw6ytb"
+   "mzxw6ytboi")))
actual-value: #t
result: PASS

test-name: base32-string->bytevector
location: /home/mekeor/cod/em/guix/tests/base32.scm:65
source:
+ (test-assert
+   "base32-string->bytevector"
+   (every (lambda (bv)
+(equal?
+  (base32-string->bytevector
+(bytevector->base32-string bv))
+  bv))
+  (map string->utf8
+   '("" "f" "fo" "foo" "foob" "fooba" "foobar"
actual-value: #t
result: PASS

test-name: nix-base32-string->bytevector
location: /home/mekeor/cod/em/guix/tests/base32.scm:73
source:
+ (test-assert
+   "nix-base32-string->bytevector"
+   (every (lambda (bv)
+(equal?
+  (nix-base32-string->bytevector
+(bytevector->nix-base32-string bv))
+  bv))
+  (map string->utf8
+   '("" "f" "fo" "foo" "foob" "fooba" "foobar"
actual-value: #t
result: PASS

test-name: &invalid-base32-character
location: /home/mekeor/cod/em/guix/tests/base32.scm:81
source:
+ (test-equal
+   "&invalid-base32-character"
+   #\e
+   (guard (c ((invalid-base32-character? c)
+  (invalid-base32-character-value c)))
+  (nix-base32-string->bytevector
+(string-append (make-string 51 #\a) "e"
expected-value: e
actual-value: e
result: PASS

test-name: sha256 & bytevector->nix-base32-string
location: /home/mekeor/cod/em/guix/tests/base32.scm:92
source:
+ (test-assert
+   "sha256 & bytevector->nix-base32-string"
+   (let ((file (search-path %load-path "tests/test.drv")))
+ (equal?
+   (bytevector->nix-base32-string
+ (sha256
+   (call-with-input-file file get-bytevector-all)))
+   (let* ((c (format
+   #f
+   "~a --type sha256 --base32 --flat \"~a\""
+   %nix-hash
+   file))
+  (p (open-input-pipe c))
+  (l (read-line p)))
+ (close-pipe p)
+ l
result: SKIP


SKIP: tests/snix


test-name: factorize-uri
location: /home/mekeor/cod/em/guix/tests/snix.scm:36
source:
+ (test-assert
+   "factorize-uri"
+   (every?
+ (match-lambda
+   ((uri version '-> expected)
+(equal? (factorize-uri uri version) expected)))
+ '(("http://example.com/foo.tgz";
+"1.0"
+->
+"http://example.com/foo.tgz";)
+   ("http://example.com/foo-2.8.tgz";
+"2.8"
+->
+("http://example.com/foo-"; version ".tgz"))
+   ("http://example.com/2.8/foo-2.8.tgz";
+"2.8"
+->
+("http://example.com/";
+ version
+ "/foo-"
+ version
+ ".tgz")
actua

bug#25422: GIT_SSL_CAINFO set incorrectly

[Mekeor Melire]

I'm experiencing the same issue. I recently installed GuixSD freshly
and encountered this bug.

Adding an option to `search-path-specification' seems like a good idea.
Still, I wonder what this snippet from (gnu system) does:

(define (operating-system-environment-variables os)
  "Return the environment variables of OS for
@var{session-environment-service-type}, to be used in 
@file{/etc/environment}."
  `(("LANG" . ,(operating-system-locale os))
("TZ" . ,(operating-system-timezone os))
("TZDIR" . ,(file-append tzdata "/share/zoneinfo"))
;; Tell 'modprobe' & co. where to look for modules.
("LINUX_MODULE_DIRECTORY" . "/run/booted-system/kernel/lib/modules")
;; These variables are honored by OpenSSL (libssl) and Git.
("SSL_CERT_DIR" . "/etc/ssl/certs")
("SSL_CERT_FILE" . "/etc/ssl/certs/ca-certificates.crt")
("GIT_SSL_CAINFO" . "/etc/ssl/certs/ca-certificates.crt")

bug#25422: GIT_SSL_CAINFO set incorrectly

[Mekeor Melire]

> > Adding an option to `search-path-specification' seems like a good idea.
> > Still, I wonder what this snippet from (gnu system) does:
> >
> > (define (operating-system-environment-variables os)
> >   "Return the environment variables of OS for
> > @var{session-environment-service-type}, to be used in 
> > @file{/etc/environment}."
> >   `(("LANG" . ,(operating-system-locale os))
> > ("TZ" . ,(operating-system-timezone os))
> > ("TZDIR" . ,(file-append tzdata "/share/zoneinfo"))
> > ;; Tell 'modprobe' & co. where to look for modules.
> > ("LINUX_MODULE_DIRECTORY" . "/run/booted-system/kernel/lib/modules")
> > ;; These variables are honored by OpenSSL (libssl) and Git.
> > ("SSL_CERT_DIR" . "/etc/ssl/certs")
> > ("SSL_CERT_FILE" . "/etc/ssl/certs/ca-certificates.crt")
> > ("GIT_SSL_CAINFO" . "/etc/ssl/certs/ca-certificates.crt")  
> 
> It defines the content of /etc/environment.

Is there any reason why GIT_SSL_CAINFO has to be set without Git being 
installed?

I mean, I think the variable just shouldn't be set in /etc/environment by 
default. It should be set as soon as Git is installed, IMHO.

bug#25758: Should zathura depend on zathura-pdf-poppler?

[Mekeor Melire]

zathura is a document viewer:

synopsis: Lightweight keyboard-driven PDF viewer
description: Zathura is a customizable document viewer.  It provides a 
minimalistic interface and an interface that mainly focuses on keyboard 
interaction.

Meanwhile, when you only install zathura itself, it's not usable for any 
format. You have to install zathura-pdf-poppler in order to be able to open PDF 
files.

So, shouldn't zathura depend on zathura-pdf-poppler so that PDFs are viewable 
by default?

On IRC, we agreed that zathura should depend on zathura-pdf-poppler:

 i just installed 'zathura', a PDF viewer. it doesn't work. i 
get this error first: "could not open plugin directory". can anyone reproduce 
this?
 oh, i think i have to additionally install another package.
 zathura-pdf-poppler
 mekeor: If that's the cause, we should fix it!
 lfam: yes, it was the cause.
 lfam: there are several different backends for zathura. it's 
imaginable that a person wants to install zathura without PDF support but only 
postscript support, isn't it?
 mekeor: It's imaginable, but we generally intend to provide 
fully featured packages
 question is - is there anyone who would like to have 
zathura and not zathura-pdf-poppler?
 and I agree that it is unlikely
 that is moment where weaker dependency like 'recommends' 
would come handy

If you have a different opinion, let me know. Otherwise, I'm going to send a 
patch next week which implements this dependency.

bug#25759: Should 'surf' depend on 'xprop' and 'dmenu'?

[Mekeor Melire]

The Guix package for the 'surf' browser (from suckless project) does not depend 
on the packages 'xprop' and 'dmenu'.

Thus, when you only install 'surf' (and do not have 'xprop' and 'dmenu' 
installed), you can only open a new URL, by re-running 'surf' with that new URL 
as command-line argument, like "surf example.org". But it's not possible to 
open a new URL from within 'surf' itself because that requires both 'xprop' and 
'dmenu'. This is comprehensible in these lines of the code:
http://git.suckless.org/surf/tree/config.def.h#n38

On #guix IRC channel, we agreed that 'surf' should depend on these packages:

 the package for the 'surf' browser (from suckless) has a 
similar issue: if you only install surf, you can't open a new URL within the 
browser because that requires the xprop package.  what do you think about that 
case?
 you mean dmenu, right?
 Sleep_Walker: yeah, that would be awesome
 ah
 right
 Sleep_Walker: uhm... i'm not sure. maybe it's both?
 ctrl+l
 that IIRC runs dmenu to have URL entered
 Sleep_Walker: it's Ctrl-g for me
 and yes, that should be fixed as well
 mekeor: right
 alright.

Unless you have a different opinion, I'm going to submit a patch next week 
which implements this dependency.

bug#26558: Opening URLs with xdg-open fails (eg. Gajim, Pumpa)

[Mekeor Melire]

Ben Sturmfels  writes:

> When I click an embedded URL within Gajim or Pumpa, I'm expecting a
> browser window to pop up, but nothing happens and I get an error on the
> command line:
>
>   /home/ben/.guix-profile/bin/xdg-open: line 341: gnome-open: command
>   not found
>
> The same error shows up if you attempt try the URL with xdg-open
> directly:
>
>   $ xdg-open https://www.gnu.org/software/guix/
>   /home/ben/.guix-profile/bin/xdg-open: line 341: gnome-open: command not
>   found
>
> As this message suggests, "gnome-open" is hard-coded into the "xdg-open"
> script on line 341.

I don't think so because this is what I get when running xdg-open:

# this does not work:
$ xdg-open http://gnu.org
/home/mekeor/.guix-profile/bin/xdg-open: line 369: firefox: command not 
found
/home/mekeor/.guix-profile/bin/xdg-open: line 369: mozilla: command not 
found
/home/mekeor/.guix-profile/bin/xdg-open: line 369: netscape: command not 
found
xdg-open: no method available for opening 'http://gnu.org'

# this works just fine:
$ BROWSER="icecat" xdg-open http://gnu.org

As you might have guessed, I do not use GNOME.

Did you try to set BROWSER environment variable?

-- 
mekeor ~ EDD3 DFFA 76F6 11C0 145F 9A99 AC85 BAD8 A2F8 C868

bug#27418: `guix pull` gets stuck at "updating substitutes from 'https://mirror.hydra.gnu.org'... 100.0%"

[Mekeor Melire]

Hello Guix!

Yesterday, I installed GuixSD on yet another device. (I did `guix pull`
before `guix system init ...`, so I guess I installed the latest version
from the master-branch of the Guix' Git-repository on the system.)

After rebooting, I ran `guix pull` (as root) but it didn't stop printing

substitute: updating list of substitutes from 
'https://mirror.hydra.gnu.org'... 100.0%

even after letting it run over night for like 8 hours.

I asked for help on #guix@freenode and rekado confirmed my issue:

 mekeor: I see the same with master
 but a couple of commits back it seems fine

(And finally, assuming this bug gets fixed, I wonder if/how I will be
able to pull a working version of Guix if I only have one=this
non-functional version of Guix installed.)

--
mekeor ~ EDD3 DFFA 76F6 11C0 145F 9A99 AC85 BAD8 A2F8 C868

bug#27425: substitute queries never finish

[Mekeor Melire]

Joshua Sierles  writes:

> Since a couple days ago, many attempts to run 'guix package' or 'guix
> pack' lead to:
>
> substitute: updating list of substitutes from
> 'https://mirror.hydra.gnu.org'... 100.0%
> substitute: updating list of substitutes from
> 'https://mirror.hydra.gnu.org'... 100.0%
> updating list of substitutes from 'https://mirror.hydra.gnu.org'...
> 100.0%g'...   0.0%
>
> This fetching stops after a few lines and never finishes, even after
> leaving it running for a day.
>
> Command:  guix package -i r-minimal
>
> I've attached a trace of the substitute processes.

This bug-report is almost a duplicate of #27418:

 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27418

beside that I reported #27418 for `guix pull` only, although the bug
affects many sub-commands of guix.

bug#27418: `guix pull` gets stuck at "updating substitutes from 'https://mirror.hydra.gnu.org'... 100.0%"

[Mekeor Melire]

Following rekado's friendly advice, I was able to downgrade guix with:

guix pull 
--url=https://git.savannah.gnu.org/cgit/guix.git/snapshot/01049bb0c1f3f69afb8d1782f99ca5c0adaed946.tar.gz
 --no-substitutes

where both options (--url and --no-substitutes) were neccessary. Now,
everything seems to work again: commands like `guix package -i` and
`guix system reconfigure` no longer get stuck at "updating list of
substitutes".

Thanks, rekado.

Still, I wonder
  * what caused this issue;
  * if anybody else is/was experiencing it; and
  * when it will be fixed in master-branch (i.e. when I will be able to
`guix pull` and `guix pull` again successfully).

bug#27418: `guix pull` gets stuck at "updating substitutes from 'https://mirror.hydra.gnu.org'... 100.0%"

[Mekeor Melire]

Ludovic Courtès  writes:
> Ricardo Wurmus  skribis:
>> Mekeor Melire  writes:
>>
>> I’m not sure but it may have been caused by a hung “guix publish”
>> process.
>
> Indeed, yesterday I realized ‘guix publish’ on hydra.gnu.org was stuck
> for unknown reasons, meaning that it would not reply to HTTP requests
> nor would it “bake” archives.  That’s likely the root cause.

Yes, this issue no longer appears for me. Thank y'all. Could you close
the bug?

-- 
mekeor ~ EDD3 DFFA 76F6 11C0 145F 9A99 AC85 BAD8 A2F8 C868

bug#27425: closing

[Mekeor Melire]

bug#27425: substitute queries never finish

[Mekeor Melire]

Joshua Sierles  writes:

> Since a couple days ago, many attempts to run 'guix package' or 'guix
> pack' lead to:

> substitute: updating list of substitutes from
> 'https://mirror.hydra.gnu.org'... 100.0%

> This fetching stops after a few lines and never finishes, even after
> leaving it running for a day.

Joshua, are you still experiencing this issue?

I'd rather guess, it was caused by the same as bug#27418. I'm closing it
for now.

bug#29219: CUPS filter still can't access Ghostscript (gs)

[Mekeor Melire]

I added two printers through CUPS' web interface (localhost:631) using
the PPD driver file which I downloaded (from openprinting.org): one
called ljet4 (which calls Ghostscript) and one called Postscript (which
just calls `cat`)⁰. The latter worked.


But although I was expecting commit
1728c411718e3b358c06561d6e80b47d7b331617¹ to fix this issue, when I try
the ljet4² driver, I still get this error in /var/log/cups/error_log³:


sh: gs: command not found
Process is dying with \"Unable to determine number of pages, page count: -1
\", exit stat 3


Is anybody able to reproduce this issue?

How can I be sure that the cups-service I'm running is the recent one
which includes that commit? (I tried pulling guix and rebuilding the
system afterwards and restarting cups-service afterwards.)

What am I doing wrong?


⁰: 
https://www.openprinting.org/ppd-o-matic.php?driver=Postscript&printer=Kyocera-FS-920&show=1
¹: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=1728c411718e3b358c06561d6e80b47d7b331617
²: 
https://www.openprinting.org/ppd-o-matic.php?driver=ljet4&printer=Kyocera-FS-920&show=1
³: http://sprunge.us/EMbF


--
mekeor ~ EDD3 DFFA 76F6 11C0 145F 9A99 AC85 BAD8 A2F8 C868

bug#25759: (no subject)

[Mekeor Melire]

bug#25758: (no subject)

[Mekeor Melire]

bug#29219: CUPS filter still can't access Ghostscript (gs)

[Mekeor Melire]

Ludovic Courtès  writes:

> Mekeor Melire  skribis:

>> But although I was expecting commit
>> 1728c411718e3b358c06561d6e80b47d7b331617¹ to fix this issue, when I try
>> the ljet4² driver, I still get this error in /var/log/cups/error_log³:

>> sh: gs: command not found
>> Process is dying with \"Unable to determine number of pages, page count: 
>> -1
>> \", exit stat 3

> Just make sure to reconfigure from a recent-enough commit (run ‘guix
> --version’ as root to see which commit you’re using.)

Done. I'm running a recent-enough commit. (Namely
46dea1241c801af5aa65e0c7b4e84bb0aff11273.)

> If it turns out you’re already using CUPS with commit
> 1728c411718e3b358c06561d6e80b47d7b331617, could you reproduce the issue
> while running “strace -p PID -f -s 345 -o log”, where PID is the PID of
> cupsd as shown by ‘herd status cups’?

You can find the log here: <http://sprunge.us/UDOY>. These might be the
interesting lines:

$ grep -E '[^a-zA-Z0-9]gs' log
31377 execve("/gnu/store/…-bash-static-4.4.12/bin/sh", ["sh", "-c", "gs 
-dNODISPLAY -q -c '/pdffile (/var/spool/cups/tmp/foomatic-4ngnEr) (r) file def 
pdfdict begin pdffile pdfopen begin (PageCount: ) print pdfpagecount == flush 
currentdict pdfclose end end quit'"], 0x149e810 /* 33 vars */ 
31377 stat("/gnu/store/…-cups-server-bin/lib/cups/filter/gs", 
0x7ffd7921b5c0) = -1 ENOENT (No such file or directory)
31377 stat("/gnu/store/…-cups-2.2.4/bin/gs", 0x7ffd7921b5c0) = -1 ENOENT 
(No such file or directory)
31377 stat("/gnu/store/…-cups-2.2.4/sbin/gs", 0x7ffd7921b5c0) = -1 ENOENT 
(No such file or directory)
31377 stat("/bin/gs", 0x7ffd7921b5c0)   = -1 ENOENT (No such file or 
directory)
31377 stat("/usr/bin/gs", 0x7ffd7921b5c0) = -1 ENOENT (No such file or 
directory)
31377 write(2, "sh: gs: command not found\n", 26) = 26
15154 <... read resumed> "sh: gs: command not found\n", 2047) = 26
15154 write(4, "D [09/Nov/2017:20:06:50 +0100] [Job 13] sh: gs: command not 
found\n", 66) = 66

Thank you for your help! How could we continue debugging?

--
mekeor ~ EDD3 DFFA 76F6 11C0 145F 9A99 AC85 BAD8 A2F8 C868

bug#57583: Guix cannot resume after hibernation

[Mekeor Melire]

2022-09-05 15:05 bug-guix@gnu.org:

> Jack, Yusuf, Ludo',
>
> Yusuf: you could try pulling, reconfiguring, hibernating, and resuming, if
> you're brave-ish.

I also use an X200 (but not with Libreboot, yet). I just tried out
hibernation (I didn't even know I had to be brave for that :D) and it
worked like a charm. So, I'll attempt to close this bug now. Feel free
to re-open, if you're still experiencing the bug, Yusuf.

> Ludovic Courtès 写道：
> > I believe this is fixed by this: […] The patch in question fell
> > through the cracks
>
> Pushed as ec16f88522041dc285a35705ff9ee95672b78143, thanks Jack!

bug#35727: Connecting Geiser to Guile listening to a socket: No prompt found! (.guile to blame)

[Mekeor Melire]

2019-05-14 06:17 sirga...@zoho.com:

I'm getting a "No prompt found!" error when I try to connect 
Geiser to a Guile REPL like this:


1. In a terminal, run "$ guile --listen=/tmp/guile-socket"
2. In Emacs, "M-x geiser-connect-local", then "guile", and 
finally "/tmp/guile-socket"


When the Guile REPL start in Emacs, I get a "No prompt found!" 
in the echo area, and the prompt in the REPL looks like this:


https://multimedialib.files.wordpress.com/2019/05/emacs-geiser-guile-repl-no-prompt-found-2019-05-13.png

After trying some things out with help from str1ngs on #guix, we 
found out that the problem is related to the ".guile" file that 
seems to be generated by the system by default. In my case, 
".guile" looks like this:


##
(cond ((false-if-exception (resolve-interface '(ice-9 
readline)))

   =>
   (lambda (module)
 ;; Enable completion and input history at the REPL.
 ((module-ref module 'activate-readline
  (else
   (display "Consider installing the 'guile-readline' 
   package for

convenient interactive line editing and input history.\n\n")))

  (unless (getenv "INSIDE_EMACS")
(cond ((false-if-exception (resolve-interface '(ice-9 
colorized)))

   =>
   (lambda (module)
 ;; Enable completion and input history at the 
 REPL.

 ((module-ref module 'activate-colorized
  (else
   (display "Consider installing the 
   'guile-colorized' package

for a colorful Guile experience.\n\n"
##

When I remove this file and try to connect again, the "No prompt 
found!" error disappears, and the prompt looks normal.


Does it work when you start the Guile REPL with an 
environment-variable called INSIDE_EMACS? That way, it worked fine 
for me:


#+begin_src sh
INSIDE_EMACS=true guix repl --listen=tcp:37146
#+end_src

If this works, then I'd suggest that this is not a bug but rather 
you got to know that you need to deliver that environment variable 
to guix/guile. We could then close this ticket.


Personally, I think this is only a bug in Geiser which should be 
able to parse colored prompts.

bug#31642: closed in plenum at guix days 2023

[Mekeor Melire]

bug#62711: Suspend-to-disk with LUKS-encrypted root doesn’t work

[Mekeor Melire]

2023-04-07 14:42 l...@gnu.org:

Since my laptop’s battery died, I set up suspend-to-disk as 
documented
in the manual (info "(guix) Swap Space").  I use a swap file on 
top of

my LUKS-encrypted root partition, so I added:

 "resume=/swap"
 "resume_offset=OFFSET"


I use the following configuration which works fine for me. (Except 
sometimes I have to wait for 2-3 minutes for the Linux kernel 
modules to get loaded; but that might be due to the special Linux 
kernel I'm using.)


#+begin_src scheme
(mapped-devices
 (list
   (mapped-device
 (source
   (uuid "SNIP"))
 (target "cryptroot")
 (type luks-device-mapping

(file-systems
 (cons
   (file-system
 (mount-point "/")
 (device "/dev/mapper/cryptroot")
 (type "ext4")
 (dependencies mapped-devices))
   %base-file-systems))

(kernel-arguments
 (cons*
   "resume=/dev/mapper/cryptroot"
   "resume_offset=5308416"
   %default-kernel-arguments))
#+end_src

bug#63258: GCC package lacks librt.so (and instead only provides versioned librt.so.1)

[Mekeor Melire]

The "gcc" package (as well as the "gcc-toolchain" package) (since 
version 12?) lacks the librt.so file which some stuff links to.


As a consequence, in bug#63012, Josselin Poiret (CC) had to patch 
Zig to not link to that file. Another consequence is that I had to 
install gcc-toolchain:static in order to make GHC compile XMonad.


On #guix IRC channel, Josselin Poiret stated that we should 
include an empty librt.a in the output of the "gcc" package. And 
Ludo (CC) suggested to temporarily include that file only in 
gcc-toolchain, in order to avoid world rebuild.


Here's the full relevant IRC log:

--8<---cut here---start->8---
2023-05-04 09:49:54 mekeor: bjc: for me, gcc-toolchain@12 is 
shipped with librt.so.1 which is present in my ~/.guix-profile/lib 
folder which is listed in my $LIBRARY_PATH variable. still, ghc 
can't find it :/
2023-05-04 09:56:15 jpoiret: mekeor: that's because ghc and others 
look for librt.so, not librt.so.1
2023-05-04 09:56:31 jpoiret: we forgot to include an empty librt.a 
in the out output of gcc unfortunately
2023-05-04 09:56:59 jpoiret: you can add gcc-toolchain:static for 
now
2023-05-04 09:57:04 mekeor: jpoiret: is there a workaround? :) 
also, is there a patch already

2023-05-04 09:57:08 mekeor: oh cool
2023-05-04 09:57:12 jpoiret: I don't think so
2023-05-04 09:57:50 jpoiret: basically librt.so.1 is empty now, 
since everything is provided by libc
2023-05-04 09:59:43 mekeor: the "static" output fixes my problem. 
thank you very much, jpoiret!
2023-05-04 09:59:47 jpoiret: the problem is that it'll require a 
world rebuild so it's not an easy change to make now. But we'll 
probably have to do it anyway
2023-05-04 10:00:01 jpoiret: might as well batch some other 
important changes like updating the glibc again

2023-05-04 10:00:08 jpoiret: just to break everything again :)
2023-05-04 10:00:41 civodul: jpoiret: we could add an empty 
librt.a in gcc-toolchain, rather than gcc?
2023-05-04 10:01:00 civodul: that would address most practical 
issues, no?

2023-05-04 10:01:26 jpoiret: ah, that's right :)
2023-05-04 10:01:55 jpoiret: but still, it's probably a good idea 
to have it in gcc, zig wanted it and I had to patch out -librt

2023-05-04 10:01:59 jpoiret: -lrt *
2023-05-04 10:02:54 civodul: yes, that'd be the right fix, but in 
the meantime we could have the easy fix :-)

--8<---cut here---end--->8---

bug#63728: GHC cannot find lrt

[Mekeor Melire]

2023-05-25 22:25 bug-guix@gnu.org:

Attempting to build a trivial Haskell program using ghc fails, 
as the linker cannot find the rt library:


Does installing gcc-toolchain:static help as a work-around?

bug#63728: GHC cannot find lrt

[Mekeor Melire]

2023-05-25 22:25 bug-guix@gnu.org:

Attempting to build a trivial Haskell program using ghc fails, 
as the linker cannot find the rt library:


```
~ $ ghc -O2 test.hs
Linking test ...
/home/a/.guix-profile/bin/ld: cannot find -lrt: No such file or 
directory

collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
```

Glibc and gcc-toolchain are installed in the profile, and
~/.guix-profile/lib/librt.so.1 exists.

Maybe this is related to this new bug, or the recent 
core-updates merge? https://issues.guix.gnu.org/63238


There is also this bug I had reported:

https://issues.guix.gnu.org/63258

I suggest to merge this bug (63728) and the bug I just linked 
(63258). What do you think?

bug#63728: GHC cannot find lrt

[Mekeor Melire]

2023-05-26 15:44 ant...@mailbox.org:

The gcc-toolchain:static workaround fixes the rt problem, but 
now the binaries aren't linked to libgmp and libffi, even though 
gmp and libffi packages are installed in the profile:


Maybe there should be a ghc-toolchain package that has libgmp 
and libffi as inputs, and makes sure GHC links them correctly?


Hm. Alternatively, we could just fix gcc-toolchain (so that it 
includes rt). But maintainers (understandably) hesitate because 
this will trigger a world rebuild.

bug#63920: Emacs Packages should have an output built with emacs-next(-minimal)

[Mekeor Melire]

Hello dear Guix community,

if I understand correctly, all Emacs-packages that are packaged in 
Guix proper, are built with Emacs version 28 (or more precisely, 
emacs-minimal@28, emacs@28, emacs-no-x@28, emacs-no-x-toolkit@28 
or emacs-wide-int@28 (except emacs-jsdoc which is and needs to be 
built with emacs-next@29)). (You may grep the Guix repository for 
":emacs" to find out by yourself.)


When using these Emacs-packages with emacs-next* (i.e. version 29 
or 30), this can lead to misbehavior because Emacs will still 
prefer the compiled .elc or .eln files which may depend on version 
28 specifics.


My concrete experience is that, when using emacs-next-tree-sitter 
and emacs-consult packages, evaluating (require 'consult-register) 
fails because it has emacs-major-version-specific code: 
https://github.com/minad/consult/blob/3c0f87ebd20b25f03568fb9ef8fd36b5a2a6eb84/consult-register.el#L82 
(A workaround is to instead evaluate (load 
"consult-register.el").)


I propose:

1. Introduce a package emacs-next-minimal.

2. For all Emacs-packages, create one output corresponding to each 
Emacs major-version packaged in Guix proper. For example, the 
output "emacs-next" would be built with emacs-next-minimal.


What do you think? I'd guess this should be hard to implement, 
right?


Kindly
Mekeor

bug#64586: Emacs-Packages should contain native-compiled files

[Mekeor Melire]

Emacs can interpret/load at least four kinds of source files. 
Listed with increasing performance:


- Emacs-Lisp source code: *.el
- Byte-compiled Emacs-Lisp: *.elc
- Native-compiled Emacs-Lisp: *.eln
- Shared-object files: *.so

Guix installs el- and elc-files into ~/.guix-profile/share/emacs/site-lisp which is added to the 
environment-variable EMACSLOADPATH. eln-files are installed into 
~/.guix-profile/lib/emacs/native-site-lisp which is added to 
EMACSNATIVELOADPATH. For Emacs-related so-files, Guix currently 
does not have any convention; see 
.


If I understand correctly, it is only the following Emacs-packages that ship 
with eln-files when installed with Guix, because they specify `#:emacs ,emacs` 
in the package declaration, so that native-compilation is available during 
build-time which is used if it's available: 
https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/emacs-utils.scm?h=6d0b3684628fe24555055d4a97d703a1b0b59660#n144

   emacs-auctex
   emacs-citeproc-el
   emacs-zig-mode
   emacs-flycheck-grammalecte
   emacs-sudo-edit
   emacs-elquery
   emacs-cov
   emacs-pos-tip
   emacs-posframe
   emacs-xelb
   emacs-exwm
   emacs-xelb-no-x-toolkit
   emacs-exwm-no-x-toolkit
   emacs-exwm-x
   emacs-jabber
   emacs-ement
   emacs-circe
   emacs-esxml
   emacs-nov-el
   emacs-wordgen
   emacs-picpocket
   emacs-lsp-mode
   emacs-jsdoc
   emacs-tramp
   emacs-elpher
   emacs-telega

So, if my understanding is correct, and assuming that we want to ship 
eln-files, Emacs-packages should all be built with a package of Emacs that 
supports native-compilation.

bug#66864: emacs-build-system builds .eln-files with mismatching path-hashes

[Mekeor Melire]

BUG EXPLANATION

Emacs's natively-compiled .eln-files have a basename following the pattern 
"{feature-name}-{path-hash}-{content-hash}.eln". [0]

Guix' emacs-build-system is used to build Emacs-related packages. By 
default, it uses the "emacs-minimal" package during build, which 
does not support native-compilation. But if you replace the 
"emacs-minimal" input with "emacs-no-x", e.g. by using 
--with-input=emacs-minimal=emacs-no-x, then emacs-build-system 
will make use of emacs-no-x' support of native-compilation [1]: 
The build will contain .eln-files.


Hereby I'd like to report the bug that consists of mismatched path-hashes in 
the .eln-files that builds of Emacs-related packages contain when build with 
emacs-no-x (or any other Emacs that supports native compilation).

BUG REPRODUCTION

To reproduce this bug follow the following steps. Please note that guix-shell seems to leak .eln-files. (This should be reported as 
another bug.) That why the reproduction steps avoid guix-shell. 
Instead, we'll work with the current user profile.


Delete Emacs' eln-cache (so that we can later see if new 
.eln-files have been generated):


rm -rf ~/.emacs.d/eln-cache

Remove all Emacs- and Emacs-related packages from Guix profile:

guix package -I | cut -f 4 | grep emacs | xargs guix remove

Install Emacs and emacs-unfill, as exemplary package, while 
replacing input "emacs-minimal" with "emacs", so that .eln-files 
are generated during the build:


	guix install emacs emacs-unfill 
	--with-input=emacs-minimal=emacs


Launch the freshly installed Emacs and load the "unfill" package. 
If the .eln-files that the emacs-unfill package provides match 
Emacs' expectations (path- and content-hash), it'll use it; 
otherwise, Emacs will compile a new .eln-file and save it into 
~/.emacs.d/eln-cache/*/unfill-{path-hash}-{content-hash}.eln.


emacs -q --eval "(require 'unfill)"

Close Emacs after some seconds. Now determine the path-hash from 
Guix' build:


	basename 
	~/.guix-profile/lib/emacs/native-site-lisp/*/unfill-*.eln \

  | cut -d - -f 2

Determine the path-hash from Emacs' native-compilation, which 
apparently has happened:


basename ~/.emacs.d/eln-cache/*/unfill*.eln \
  | cut -d - -f 2

The path-hashes from the last two steps are not equal.

BUG SOLUTION HINTS

In the #guix:libera.chat IRC channel, jpoiret pointed out: "the .eln file hash problem is due to grafts, grafts change the 
final output name, but they can't also update the file hashes... 
we'd need to modify emacs' behavior for this to work".


CITATIONS

[0]: Emacs' source code documents the meaning of the two hashes here: 
https://git.sv.gnu.org/cgit/emacs.git/tree/src/comp.c?h=194a8f5c1406dd7e762376bdfde78d1b7d01b6b1#n4405

[1]: Here you can see that emacs-no-x supports native-compilation unlike 
emacs-minimal: 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/emacs.scm?h=92913703448c8e1a488ab066f60741262cdbf923#n294

bug#66864: emacs-build-system builds .eln-files with mismatching path-hashes

[Mekeor Melire]

2023-11-01 12:52 liliana.prik...@gmail.com:

Am Dienstag, dem 31.10.2023 um 23:49 + schrieb Mekeor 
Melire:


> To reproduce this bug follow the following steps. Please note 
> that
> guix-shell seems to leak .eln-files. (This should be reported 
> as

> another bug.)



What do you mean by "leaks .eln-files"?


To be honest, I can't reproduce the leakage right now. I'll create another bug 
report if I can.

> That why the reproduction steps avoid guix-shell.  Instead, 
> we'll

> work with the current user profile.
>
> Delete Emacs' eln-cache (so that we can later see if new
> .eln-files have been generated):
>
> rm -rf ~/.emacs.d/eln-cache
>
> Remove all Emacs- and Emacs-related packages from Guix 
> profile:

>
> guix package -I | cut -f 4 | grep emacs | xargs guix 
> remove

>
> Install Emacs and emacs-unfill, as exemplary package, while
> replacing input "emacs-minimal" with "emacs", so that 
> .eln-files

> are generated during the build:
>
> guix install emacs emacs-unfill
> --with-input=emacs-minimal=emacs


Just deleting the eln-cache should be enough for a MWE.  When 
doing an

MWE, make sure that its actually minimal :)


I wanted to make sure that an Emacs-related package is installed, and 
specifically with the --with-input=emacs-minimal=emacs transformation because 
otherwise .eln-files won't be built. The MRE is minimal in that sense that it 
ensures what's needed; only one Emacs-related package is installed; and 
commands are kept simple.

> Launch the freshly installed Emacs and load the "unfill" 
> package.

> If the .eln-files that the emacs-unfill package provides match
> Emacs' expectations (path- and content-hash), it'll use it;
> otherwise, Emacs will compile a new .eln-file and save it into
> ~/.emacs.d/eln-cache/*/unfill-{path-hash}-{content-hash}.eln.
>
> emacs -q --eval "(require 'unfill)"
>
> Close Emacs after some seconds. Now determine the path-hash 
> from

> Guix' build:
>
> basename
> ~/.guix-profile/lib/emacs/native-site-lisp/*/unfill-*.eln 
> \

>   | cut -d - -f 2
>
> Determine the path-hash from Emacs' native-compilation, which
> apparently has happened:
>
> basename ~/.emacs.d/eln-cache/*/unfill*.eln \
>   | cut -d - -f 2


This is already the bug.  There should not be a file written to 
the
eln-cache (save for the trampolines that we still write there, 
which is

also a known bug among those who care).


Yes, this is already the bug. The reason for the eln-cache to be created is 
that the two path-hashes do not equal.


> The path-hashes from the last two steps are not equal.
>
> BUG SOLUTION HINTS
>
> In the #guix:libera.chat IRC channel, jpoiret pointed out: 
> "the .eln

> file hash problem is due to grafts, grafts change the
> final output name, but they can't also update the file 
> hashes...

> we'd need to modify emacs' behavior for this to work".


As jpoiret points out, this has to do with the file naming 
choices of
Emacs, not with emacs-build-system per se.  We would need to get 
rid of

a lot of hashes if we wanted interoperable native-compiled Emacs
libraries.  I wonder what upstream has to say about this.


The problem is that the .el-file-path that is passed to the Emacs function comp-el-to-eln-filename during build [1] does not equal to the 
.el-file-path when Emacs is invoked. Personally, I do not 
understand how grafting causes this. But I can confirm that when 
--no-grafts is passed to "guix install emacs emacs-unfill 
--with-input=emacs-minimal=emacs", then no eln-cache is created.


[1]: See these lines of code:
https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/emacs-build-system.scm?h=92913703448c8e1a488ab066f60741262cdbf923#n133
https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/emacs-utils.scm?h=92913703448c8e1a488ab066f60741262cdbf923#n149

bug#66864: emacs-build-system builds .eln-files with mismatching path-hashes

[Mekeor Melire]

2023-11-01 15:16 liliana.prik...@gmail.com:

I think Emacs might be calculating its own hash at runtime 
rather than

baking in the value at build time.


Exactly. That's what I was trying to express.

bug#67292: emacs / emacs-transient collisions and bundling

[Mekeor Melire]

Hello Maxime,

2023-11-20 13:39 maximede...@telenet.be:


Op 20-11-2023 om 11:22 schreef Simon Tournier:


> On Sun, 19 Nov 2023 at 23:44, Maxime Devos 
> 

> wrote:



>> Bug 1: emacs bundles emacs-transient.
>> (Likewise for quite a few other Emacs packages.)


> This is not a bug.  transient.el is part of Emacs since 
> version 28,



This does not answer how the bundling is not a bug.

Unbundling is not incompatible with keeping builtins -- for 
example,
emacs-minimal could be the ‘minimalistic Emacs, without the 
typical
bundled ‘built-in’ stuff’, and emacs could be 'emacs-minimal + 
the

unbundled stuff in propagated-inputs’.

(Well, preferably not propagated, but that's just a matter of 
wrapping

or unions etc..)

Another option could be to unbundle things in the 'source' of 
emacs /
emacs-minimal and copy over source code from the 
'emacs-‘builtin’'

packages during a build phase.

(IIUC, emacs-minimal is for compiling Emacs packages and for 
scripts,
of which most probably have no need for keyboard-driven menus -- 
and

if they do have need,)


It might be possible to cut out some parts of Emacs so that emacs-minimal is 
more minimal. But I think this could become quite complicated because we don't 
know exactly which parts of Emacs are needed to build Emacs-related packages 
since they might rely on any Elisp code during compile-time. Also, more 
generally, it'd be hard to decide which parts are not needed, i.e. where to 
draw the line etc. All in all, I don't think that it's worth the effort and 
maintenance.


>> Bug 2: no collision handling.


As far as I know, Guix does not provide a facility to prioritize a 
file from one package over the same file from another package.


But also, I don't think this is necessary here, because in a Guix-installed 
Emacs, the paths to Guix-installed Emacs-related packages appear first in 
Emacs' load-path variable, whereas the paths to the elisp-directories from 
Emacs itself come last. Thus, emacs-transient's transient.el is always 
preferred over Emacs' transient.el.

Finally, here's a list an incomplete list of Emacs-related packages that are 
both built into Emacs itself, as well as distributed separately over GNU Elpa 
and thus also as separate packages in Guix:

   emacs-eglot
   emacs-eldoc
   emacs-external-completion
   emacs-jsonrpc
   emacs-let-alist
   emacs-map
   emacs-ntlm
   emacs-project
   emacs-so-long
   emacs-soap-client
   emacs-use-package
   emacs-xref

If you want to know which built-in packages are distributed separately via GNU Elpa, 
search the following file for ":core". Note that only a subset of those might 
be packaged separately in Guix.

https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/elpa-packages

TANGENTIALLY: I'd like to mention that this topic becomes sort of a problem when (1) you have 
installed Emacs with "guix install emacs-next --with-branch=emacs-next=master" or 
similar; and (2) you installed some Emacs-related package via Guix, which propagates another 
Emacs-related package that is also built into Emacs. This would cause a downgrade of that 
propagated, built-in, Emacs-related package. E.g. this happens with emacs-consult-eglot which 
propagates emacs-eglot which is also built into Emacs itself. A work-around is to overwrite the 
input like this: "guix install emacs-next emacs-consult-eglot 
--with-input=emacs-eglot=emacs-next --with-branch=emacs-next=master".

bug#67292: emacs / emacs-transient collisions and bundling

[Mekeor Melire]

2023-11-28 01:58 maximede...@telenet.be:


[[PGP Signed Part:Undecided]]
Op 23-11-2023 om 15:17 schreef Mekeor Melire:
>> >> Bug 2: no collision handling.
> As far as I know, Guix does not provide a facility to 
> prioritize a

> file from one package over the same file from another package.

As I mentioned in a previous e-mail in #67292, it does provide a
facility -- not mentioned: by default, the first package in the 
list

is prioritized.


Sorry for the oversight. Which list are you referring to?

If the collision is not a problem then Guix shouldn't be warning 
about
it -- as such, the collision handling needs to be adjusted to 
not emit

a warning in this case.


True. That'd be nice. Should we discuss this here, in this bug-report or in 
another, new bug-report that is dedicated to the problem of unnecessary 
collision-warnings?

bug#67292: emacs / emacs-transient collisions and bundling

[Mekeor Melire]

2023-11-28 02:47 maximede...@telenet.be:

Op 22-11-2023 om 21:53 schreef Simon Tournier:
> On mar., 21 nov. 2023 at 19:01, Maxime Devos 
>  wrote:


For widget and woman, sure, I'll take your word for it is fully 
merged
in Emacs (both the literal code & development (& maintenance)). 
But
I'm talking about emacs-transient (not widget or woman), and 
note, as
I pointed out previously, emacs-transient development location 
appears
to be  (which is not the 
Savannah
Emacs Tree) -- there's even a new commit 8 hours ago, and it 
doesn't

seem to be disappearing anytime soon.


Note that transient.el from Emacs-master and from github.com/magit/transient 
actually have diverged. In particular, the following commit is present on 
Emacs-master while it is not present on magit/transient: 
https://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/transient.el?id=7705bdfa5b89f78dab049f73f636b9680a3c12bc

The relation between the possibly-existing separate repository of an 
Emacs-core-package (e.g. github.com/magit/transient) to the Emacs-repository 
itself seems to depend on the concrete package. As we just saw, for 
transient.el, that its version in the separate repository and in the 
Emacs-repository may temporarily diverge. Tarsius, the transient-maintainer, 
merges changes into Emacs after version bumps.

Another example is eglot.el. It also has a separate repository but that 
repository is only occasionally synced with the more progressed version that is 
tracked in the Emacs repository itself.


--- (From: Mekeor Milere)


It's "Melire". Why did you respond to my mail in a separate thread?

If making emacs-mnimal more minimal is too complicated, don't do 
it

then, just replace the bundled copy with an up-to-date (source)
version, as I proposed previously.


Replacing the "bundled copy" could erase fixes, that are only present in Emacs, 
and not present in github.com/magit/transient.

> TANGENTIALLY: I'd like to mention that this topic becomes sort 
> of a

> problem when (1) you have installed Emacs with "guix install
> emacs-next --with-branch=emacs-next=master" or similar; and 
> (2) you
> installed some Emacs-related package via Guix, which 
> propagates
> another Emacs-related package that is also built into Emacs. 
> This
> would cause a downgrade of that propagated, built-in, 
> Emacs-related
> package. E.g. this happens with emacs-consult-eglot which 
> propagates
> emacs-eglot which is also built into Emacs itself. A 
> work-around is

> to overwrite the input like this: "guix install emacs-next
> emacs-consult-eglot --with-input=emacs-eglot=emacs-next
> --with-branch=emacs-next=master".

No?  Unless you do "--with-branch=emacs-next=something-old" or 
the
like, you will never get a downgrade -- you will not get an 
automatic

upgrade to what's bundled in Emacs-next, but:

 (a) you won't get anything older than what is currently 
 packaged in

 Guix. (Hence, not a downgrade.)
 (b) and you asked for a latest emacs, not a latest emacs-eglot.

You might even get something newer than in the master branch of 
Emacs,
if the Emacs maintainers haven't merged in the latest version 
yet.


As elaborated before, some packages (like Eglot) are primarily developed in the 
Emacs repository. (Unlike Transient.)


Also, I don't get what "--with-input=emacs-eglot=emacs-next" is
supposed to do.


It effectively removes emacs-eglot as input for the installed packages and 
their dependencies


> If you want to know which built-in packages are distributed
> separately via GNU Elpa, search the following file for 
> ":core". Note
> that only a subset of those might be packaged separately in 
> Guix.

> https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/elpa-packages

I don't want to know.  I use Guix as package manager, not Emacs 
-- I
don't really care whether a hypothetical package is distributed 
via

Elpa.


The point is that Guix downloads the source code of (some?) Elpa-distributed 
packages from Elpa. For example: 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/emacs-xyz.scm?h=60c97924e9519361494aaf0686e28eb831a42315#n1011

bug#69201: Emacs master-branch renamed comp-write-bytecode-file which emacs-utils depends on

[Mekeor Melire]

On Emacs' master-branch, the emacs-lisp function
comp-write-bytecode-file has been renamed to comp--write-bytecode-file
(i.e. to include a double dash) in this commit [1]:

faa46eb8667c11a0725500a50e957eb78021c99f
Author: Andrea Corallo 
AuthorDate: Sun Feb 11 12:31:13 2024 +0100
Commit: Andrea Corallo 
CommitDate: Sun Feb 11 15:26:12 2024 +0100

Rename a number of native compiler functions

Guix' function emacs-compile-directory from module (guix build
emacs-utils) [2] depends on this emacs-lisp function.

Thus, when emacs-next-minimal is build from the above mentioned commit
or later, it won't be possible to build packages that use
emacs-build-system, when using
--with-input=emacs-minimal=emacs-next-minimal, or in Guile code,
argument "#:emacs emacs-next-minimal". This might be considered to be a
minor issue as of right now.

It'll become a more general problem, when Emacs 30 is released.


[1] 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=faa46eb8667c11a0725500a50e957eb78021c99f

[2] 
https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/emacs-utils.scm?h=08ed3ec64ecd571d92d497b2493f5c0225102c99#n153