bug#52808: Guix home should not assume that all targets are dot files

[Andrew Tropin]

On 2022-03-05 23:44, Ludovic Courtès wrote:

> Hi Andrew,
>
> The patches reached my mailbox around the time I went on vacation and
> then fell through the cracks.  Sorry about that!

No problem, I hope you had a good rest and got some fun!

>
> Andrew Tropin  skribis:
>
>> After that patch series is merged we can give a time for users to
>> migrate their self-made home services to xdg-configuration-files and
>> after for example 2 weeks, remove special handling of dots for
>> home-files.
>
> Sounds like a plan!
>
>> From 0cd37bbc724f9c793898c2655bdd1c335045c5f0 Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin 
>> Date: Fri, 11 Feb 2022 10:55:01 +0300
>> Subject: [PATCH 1/5] home: Explicitly connect home-file and symlink-manager
>>  services.
>>
>> * gnu/home/services.scm (home-files-directory): New variable.
>> * gnu/home/symlink-manager.scm (update-symlinks-script): Use
>> home-files-directory variable from (gnu home services).
>
> [...]
>
>> -(description "Configuration files for programs that
>> -will be put in @file{~/.guix-home/files}.")))
>> +(description (format #f "Files that will be put in
>> +@file{~~/.guix-home/~a}, and further processed during activation."
>> + home-files-directory
>
> This hunk would prevent i18n so I suggest dropping it (you can mention
> ‘home-files-directory’ in a margin comment for good measure).
>
> Otherwise LGTM.
>

Will fix it.

>> From 23f7095d60b18b52de0d1aa314c4012cdf55a046 Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin 
>> Date: Fri, 11 Feb 2022 11:03:02 +0300
>> Subject: [PATCH 2/5] home: Add home-xdg-configuration-files service.
>>
>> * gnu/home/services.scm (home-xdg-configuration-files): New variable.
>
> [...]
>
>> +(define xdg-configuration-files-subdir "config")
>>
>> +(define (xdg-configuration-files files)
>> +  (map (lambda (lst)
>> + (cons (string-append xdg-configuration-files-subdir
>> +  "/" (car lst)) (cdr lst)))
>> + files))
>
> I’d just call it “.config” (instead of “config”).  That way, there
> wouldn’t be any special treatment.  WDYT?

This is a patch series, which introduces preliminary changes and keeps
backward compatibility, so people, who have their personal home services
will be able to gradually migrate them to home-xdg-configuration-files.
In the next patch series special treatment of the dots will be removed
and this directory will become ".config".

>
> Also: s/subdir/directory/, and please use ‘match’ instead of car/cdr
> (info "(guix) Coding Style").
>

Sure.

>> +(description (format #f "Files that will be put in
>> +@file{~~/.guix-home/~a/~a}, and further processed during activation."
>> + home-files-directory
>> + xdg-configuration-files
>
> Same as above: drop ‘format’ and write ~/.guix-home/files/.config.
>
>> From 11f23a48d480a91d6bfba0ff55c1a9831585a4ee Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin 
>> Date: Fri, 11 Feb 2022 15:03:44 +0300
>> Subject: [PATCH 3/5] home: shells: Migrate zsh to xdg-configuration-files.
>>
>> * gnu/home/services.scm (home-zsh-service-type): Additionally extend
>> home-xdg-configuration-files-service-type.
>
> [...]
>
>> From ef4c3bbcc0c8c1a251f4ad6c494f8ed30adf45f2 Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin 
>> Date: Fri, 11 Feb 2022 15:34:46 +0300
>> Subject: [PATCH 4/5] home: Migrate fountutils and xdg modules to
>>  xdg-configuration-files.
>>
>> * gnu/home/services/fontutils.scm (home-fontconfig-service-type): Migrate to
>> xdg-configuration-files.
>> * gnu/home/services/xdg.scm (home-xdg-user-directories-service-type,
>> home-xdg-mime-applications-service-type): Migrate to xdg-configuration-files.
>
> Neat!
>
>> From 089683bbd301f6e085f00fbd53713f335abac40e Mon Sep 17 00:00:00 2001
>> From: Andrew Tropin 
>> Date: Fri, 11 Feb 2022 16:14:23 +0300
>> Subject: [PATCH 5/5] home: symlink-manager: Respect XDG_CONFIG_HOME during
>>  activation.
>>
>> * gnu/home/services/symlink-manager.scm (update-symlinks-script): Respect
>> XDG_CONFIG_HOME during activation.
>
> I propose to postpone this one after
> , and I even offer to rebase it
> myself if you want.  :-)
>
> Could you send updated patches?

Sure, I even replied to bug#54180 ticket :)  Waiting for the merge, after
that will update patches to address your comments and will rebase them
on top of bug#54180.  Also, I need to update the manual as well.

>
> Thanks in advance, and apologies again for the delay!
>
> Ludo’.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

bug#54305: disk utility fail format fat

[Roman Riabenko]

Hello

When initiating formatting of a USB flash drive in GNOME Files
(Nautilus), GNOME Disks (gnome-disk provided by gnome-disk-utility
package) opens followed by the volume formatting dialog. Currently, by
default, it is only possible to format the disk in Ext4. Other options
are grayed out, except for FAT, but choosing this option results in the
following error:

Error creating file system: Error spawning command-line `mkfs.vfat -l -
n "'/dev/sdb": Failed to execute child process "mkfs.vfat" (No such
file or directory) (g-exec-error-quark, 8) (udisks-error-quark, 0) 

(Here /dev/sdb is my flash drive.) I fixed this error by adding
dosfstools to the system profiles packages in config.scm:

(specification->package "dosfstools")

I see two issues here.

1. The FAT option was not grayed out in the formatting dialog. For
comparison, the NTFS option was grayed out until I added ntfs-3g to the
system profile too. May be GNOME Disks expects mkfs.vfat to be present,
so it does not check whether it is present like it does for other file
systems. 

So, it would be great for GNOME Disks to check whether mkfs.vfat is
available before proceeding like it does for other filesystems. It
could be easier to make dosfstools a dependency of gnome-disk-utility.
But, for comparison, the approach for UDisks seems to be to patch the
library instead of propagating system utilities:
https://issues.guix.gnu.org/41247#10

Possibly relevant patches:
https://issues.guix.gnu.org/40480
https://issues.guix.gnu.org/49128

2. GNOME Disks utility ignored the dosfstools package which I installed
in my user profile. For comparison, this applies to ntfs-3g too. In
relation to ntfs-3g with UDisks this seems to be expected behavior, but
it seemed to me as a bug at first:
https://guix.gnu.org/en/manual/devel/en/html_node/Desktop-Services.html#index-udisks_002dservice

I do not know what is necessary to make GNOME Disk utility recognize
the tools in the user profile and I am not sure it is necessary. It
just seemed against the spirit of guix that the user is forced to
reconfigure the system.

Roman

bug#54292: Commit e8518c43 breaks guix pull on i686

[Liliana Marie Prikler]

Am Dienstag, dem 08.03.2022 um 13:33 -0500 schrieb Philip McGrath:
> I can see (at least) two paths forward:
> 
>   1. `%nix-{arch,os}-to-chez-alist` could become many-to-one rather
>  than one-to-one. Presumably we'd use the first applicable entry
> when going from Chez to Nix.
> 
>   2. We could give up on alists and use existing predicates from
>  (guix utils) like `target-x86-32?`, as Liliana had already
>  suggested during review for `chez-upstream-features-for-system`.
> 
> I liked the alists because they made the bidirectional relationship
> obvious, but I wonder if there are other potential pitfalls analogous
> to this one.  Maybe someone more familiar with non-x86_64 systems in
> Guix/Nix than I am should decide.
There is no 1:1 mapping to be found here as far as I can see. 
Likewise, the reverse mapping is currently unused and should in my
opinion be dropped so that people don't expect a round-trip to be well-
defined.

> OTOH, while it's definitely a bug that `(nix-system->chez-machine
> "i686-linux")` currently returns `#f`, it seems like the more
> immediate problem is from the `maybe-compile` phase of
> the stex-bootstrap package, where this code:
> 
>     (define machine
>   #$(chez-machine->threaded
>  (nix-system->chez-machine)))
> 
> assumes, apparently incorrectly, that it's only going to be run when
> the result of `nix-system->chez-machine` is non-false. In other
> words, even if we fix the bug in `nix-system->chez-machine` for i686,
> I think we'd still hit this problem for systems that Chez really
> doesn't support, e.g. ppc64le or MIPS.  I don't know what the most
> correct way would be to write this code, but I think we could defer
> the error until someone attempts to build the package for the
> unsupported system by just writing something like:
> 
>     (define machine
>   #$(and=> (nix-system->chez-machine)
>    chez-machine->threaded))
I pushed that definition upstream, but a rewrite is still needed.  I
also think this logic should be a little decoupled from the question of
whether or not a given nix-system is supported.  While surely this
function returning #f means it's not, there are still other questions
to consider.

An implementation could look like the following

(define* (nix-system->chez-machine system #:key threaded?)
  (false-if-exception
   (string-append
(if threads? "t" "")
(cond
 ((target-x86_64? system) "a6")
 ...)
(cond 
 ((target-linux? system) "le")
 ...

Cheers 

bug#53915: No way of replacing an input in modify-input syntax structure but keep all the outputs

[Liliana Marie Prikler]

Am Dienstag, dem 08.03.2022 um 17:11 +0100 schrieb Ludovic Courtès:
> [...]
> With the patch below, we get more sensible behavior:
> 
> --8<---cut here---start->8---
> scheme@(guile-user)> (modify-inputs (append $5 $4)
>    (replace "glib" xpdf))
> $8 = (("glib" # 7f9b1457c9a0>) ("pkg-config" # pkg-config@0.29.2 gnu/packages/pkg-config.scm:36 7f9b13a30580>)
> ("glib" #
> "bin") ("gobject-introspection" # gobject-introspection@1.66.1 gnu/packages/glib.scm:428
> 7f9b12994e70>))
> --8<---cut here---end--->8---
> 
> If that makes sense to you, I’ll go ahead with this change and adjust
> documentation accordingly.
Sounds better than my own suggestion, since it'll keep working the way
it did even when labels are eventually dropped.  If more control is
needed, we can always later extend it to support (replace ("label"
"output") (package output)).  WDYT?

Cheers

bug#53904: Using an http proxy, derivation failed

[dal-blazej--- via Bug reports for GNU Guix]

Hi,

Ludovic Courtès  writes:

>> guix pull: error: failed to connect to `/var/guix/daemon-socket/socket': 
>> Connection refused
>
> This suggests that guix-daemon is not running.  Could it be that it
> failed to start?  Does ‘journalctl -u guix-daemon.service’ contain any
> clue?
>
> BTW, according to the output you pasted earlier (in particular the noisy
> locale warnings), it seems that your daemon needs an update.  Check out
> .

Yes It needs an update but it can't. That's the issue ;)

Sorry, I think my CC error has lead to some confusion.

My last mail stated I started from scratch (new virtual machine, new
guix installation) :
- with the https_proxy defined inside the systems service file.
- with the daemon running
So please, ignore the first errors.

In this case the error seems clearly that :
$ guix pull
use git, and _guix does not pass to git the https_proxy_.

Fortunately I can update by passing the https_proxy on the command:
$ https_proxy=https://127.0.0.1:8082 guix pull

To make it clear, both the variable in the systemd service file and on
the command line are necessary to successfully run guix pull.

But as you stated it shouldn't, it still looks like a bug.

bug#51466: bug#53355: guix shell --check: confusing error message

[Ludovic Courtès]

Hi Chris,

Did you have a chance to look into it?

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

TIA.  :-)

Ludo’.

Ludovic Courtès  skribis:

> Hi Chris,
>
> Thanks for debugging this!
>
> Chris Marusich  skribis:
>
>> From c3eea81846ae71a246e6b592be74062f4bf26474 Mon Sep 17 00:00:00 2001
>> From: Chris Marusich 
>> Date: Sun, 13 Feb 2022 14:15:14 -0800
>> Subject: [PATCH] environment: Prevent PS1 from clobbering output in 'check'.
>>
>> Fixes: .
>>
>> * guix/scripts/environment.scm (child-shell-environment): In the script
>> executed the child shell, set PS1 to an empty value and then echo three
>> sentinel lines to try to "flush" the original PS1 value before printing the
>> environment variables.  In the parent process, read and discard all lines up
>> to and including the last sentinel line.  After that, read the remaining 
>> lines
>> as usual.
>
> [...]
>
>> +;; Why print "GUIX_FLUSH" a few times?  We are trying to "flush" the
>> +;; original PS1 value to the port so we can read it (and discard it)
>> +;; before we start reading the environment variables from the port.  If 
>> we
>> +;; don't do this, the original PS1 value can sometimes get interleaved
>> +;; into the output, which interferes with our parsing logic.  It's a 
>> hack,
>> +;; but in practice it seems to do the job.  If you know of a more 
>> graceful
>> +;; solution, please implement it!  See: 
>> https://issues.guix.gnu.org/51466
>> +"PS1=; for i in 1 2 3; do echo GUIX_FLUSH_$i; done; \
>> +env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
>
> So you confirm that a single “echo” is not enough, right?
>
> Perhaps we should unroll the ‘for’ loop for portability, to be on the
> safe side.  Initially I tested with Bash, Zsh, and Fish:
>
>   https://issues.guix.gnu.org/51285#0-lineno49
>
> I think Fish has a very non-POSIX syntax, hence the suggestion to avoid
> ‘for’.
>
> I realized that setting PS1 could interfere with the logic below that
> checks for PS1.  And since it doesn’t seem to help, perhaps we can
> remove “PS1=;”?
>
> Thoughts?
>
> Sorry to answer with yet more questions!
>
> Thanks,
> Ludo’.

bug#54292: Commit e8518c43 breaks guix pull on i686

[Philip McGrath]

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 thinking about the fact that Guix 
distinguishes among "i[3456]86" when I ported `%nix-arch-to-chez-alist` from 
the `raco cross` codebase.

I can see (at least) two paths forward:

  1. `%nix-{arch,os}-to-chez-alist` could become many-to-one rather than
 one-to-one. Presumably we'd use the first applicable entry when going
 from Chez to Nix.

  2. We could give up on alists and use existing predicates from (guix utils)   
  
 like `target-x86-32?`, as Liliana had already suggested during review for
 `chez-upstream-features-for-system`.

I liked the alists because they made the bidirectional relationship obvious, 
but I wonder if there are other potential pitfalls analogous to this one. 
Maybe someone more familiar with non-x86_64 systems in Guix/Nix than I am 
should decide.

OTOH, while it's definitely a bug that
`(nix-system->chez-machine "i686-linux")` currently returns `#f`, it seems 
like the more immediate problem is from the `maybe-compile` phase of the stex-
bootstrap package, where this code:

(define machine
  #$(chez-machine->threaded
 (nix-system->chez-machine)))

assumes, apparently incorrectly, that it's only going to be run when the 
result of `nix-system->chez-machine` is non-false. In other words, even if we 
fix the bug in `nix-system->chez-machine` for i686, I think we'd still hit 
this problem for systems that Chez really doesn't support, e.g. ppc64le or 
MIPS. I don't know what the most correct way would be to write this code, but 
I think we could defer the error until someone attempts to build the package 
for the unsupported system by just writing something like:

(define machine
  #$(and=> (nix-system->chez-machine)
   chez-machine->threaded))

-Philip

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

bug#54280: stumpwm won't load libraries

[Einar Largenius]

Hello!

I have an issue where I can't get slynk to load inside stumpwm with Guix
as the package manager. I have no issue loading slynk with either nyxt
or when running a sbcl-repl even without modifying
asdf:*central-registry*. These are the packages I have in my profile:

glibc-locales   2.33out 
/gnu/store/nrr24nvf6548if5wdpvxhlvjif3x9jjp-glibc-locales-2.33
nyxt2.2.4   out 
/gnu/store/rf5aamdsdd039mhn4c3vsx5zgzzmnzdx-nyxt-2.2.4
sbcl2.2.2   out 
/gnu/store/129g8pcc2ybs1p81ak28lj44i0wkyiqj-sbcl-2.2.2
cl-slynk1.0.43-5.0470c02out 
/gnu/store/zc8h7xy78k6ybfq74k4wvx0yhg4pz6ln-cl-slynk-1.0.43-5.0470c02
stumpwm 20.11   out 
/gnu/store/y88ghx13yv9b6a2sa7b8hnxgcnw8x3ka-stumpwm-20.11

If I just try to load slynk directly asdf doesn't seem to find it at
all. If I try to add the *.asd files that Guix provides:

(push (uiop:subpathname* (user-homedir-pathname) 
".guix-profile/share/common-lisp/systems/") asdf:*central-registry*)

And then try to load, I still get an error:

Don't know how to REQUIRE SB-CLTL2

stumpwm itself works without issue.

-- 
With kind regards Einar

bug#54278: Bug report

[Oliver König]

/etc$ sudo -i guix pull
Kanal „guix“ wird vom Git-Repository auf 
„https://git.savannah.gnu.org/git/guix.git“ aktualisiert …
Kanal „guix“, Commits 9edb3f6 bis e7886fd werden authentifiziert (16.614 neue 
Commits) …
Von diesem Kanal wird erstellt:
  guix  https://git.savannah.gnu.org/git/guix.git   e7886fd
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
 libtiff-4.2.0-doc  358KiB 
2.0MiB/s 00:00 [##] 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
 curl-7.76.0-doc  624KiB   
2.1MiB/s 00:00 [##] 100.0%
 openldap-2.4.50  1.3MiB   
5.6MiB/s 00:00 [##] 100.0%
 curl-7.76.0  414KiB   
4.9MiB/s 00:00 [##] 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
 curl-7.74.0  379KiB   
2.8MiB/s 00:00 [##] 100.0%
 git-minimal-2.31.1  4.1MiB
3.5MiB/s 00:01 [##] 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
 gnutls-3.6.15-doc  1.0MiB 
1.6MiB/s 00:01 [##] 100.0%
 zlib-1.2.11  94KiB
2.5MiB/s 00:00 [##] 100.0%
 gcc-7.5.0  38.4MiB
7.0MiB/s 00:06 [##] 100.0%
 gnutls-3.6.15-debug  2.6MiB   
6.7MiB/s 00:00 [##] 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird 
aktualisiert … 100.0%
 gmp-6.2.0  583KiB 
2.9MiB/s 00:00 [##] 100.0%
 libffi-3.3  73KiB 
2.8MiB/s 00:00 [##] 100.0%
 libgc-8.0.4  276KiB   
2.4MiB/s 00:00 [##] 100.0%
 libltdl-2.4.6  52KiB  
4.3MiB/s 00:00 [##] 100.0%
 libunistring-0.9.10  794KiB   
6.9MiB/s 00:00 [##] 100.0%
 pkg-config-0.29.2  498KiB 
7.3MiB/s 00:00 [##] 100.0%
 guile-3.0.2  10.8MiB  
6.9MiB/s 00:02 [##] 100.0%
/gnu/store/sflmgcfcdwizj7iyd3pfksdvrkc3pskb-config.scm.drv wird erstellt …
/gnu/store/7k17dvmcrdicjsdxmpvhss4p3i3d70j5-git.scm.drv wird erstellt …
/gnu/store/j9s3n7iqvh8pqkxkwy91nq3qynr1nby7-hash.scm.drv wird erstellt …
/gnu/store/3n2l31b7fvbc2wwrhnakf5s1lwsq1w3g-module-import.drv wird erstellt …
/gnu/store/6p1l3jpa88pq0ns0p04173bcv31l175j-module-import.drv wird erstellt …
/gnu/store/jvakc7dncsqviz7xzdz9zplyw6lf9g7w-module-import-compiled.drv wird 
erstellt …
/gnu/store/j2xm5zh3rlv6s5sjx5q8s5p5i6j5yqkx-module-import-compiled.drv wird 
erstellt …
/gnu/store/39vi02cqm8556rkxgjjfk37wsbvwniwy-compute-guix-derivation.drv wird 
erstellt …
substitute: Liste der Substitute von ?https://ci.guix.gnu.org? wird 
aktualisiert ? 100.0%
substitute: Liste der Substitute von ?https://ci.guix.gnu.org? wird 
aktualisiert ? 100.0%
substitute: Liste 

bug#54277: guix derivation compute bug

[Никита Зинкевич]

Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to e7886fd (315 new 
commits)...

Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   e7886fd
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 
0.0%guix substitute: warning: ci.guix.gnu.org: connection failed: 
Connection timed out

substitute:
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
building /gnu/store/2ih3xpn6cbaajnbajsskfd75l7in7fkm-module-import.drv...
building 
/gnu/store/q32v1p84mx92yvr2il23ag9damiq7jxg-module-import-compiled.drv...
building 
/gnu/store/6fs70csi6jmgjp0f4vwixzdprpz2z295-compute-guix-derivation.drv...

substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
Backtrace:
  17 (primitive-load 
"/gnu/store/47jgrwakv5mwmxp1whz1i1wmhb50xd7j-compute-guix-derivation")

In ice-9/eval.scm:
155:9 16 (_ _)
159:9 15 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))

In ice-9/boot-9.scm:
152:2 14 (with-fluid* _ _ _)
152:2 13 (with-fluid* _ _ _)
In ./guix/store.scm:
  2129:24 12 (run-with-store # 
# ?)

   1966:8 11 (_ #)
In ./guix/gexp.scm:
   296:22 10 (_ #)
   1177:2  9 (_ #)
   1043:2  8 (_ #)
889:4  7 (_ #)
In ./guix/store.scm:
  2014:12  6 (_ #)
   1406:5  5 (map/accumulate-builds #7f04564517d0> # ?)
  1421:15  4 (_ # 
("/gnu/store/awbqcblsksjrvgi80skcv5s5bfvw92h6-guile-ssh-?" ?) ?)

  1421:15  3 (loop #f)
   733:11  2 (process-stderr # _)
In ./guix/serialization.scm:
   102:11  1 (read-int #)
 80:6  0 (get-bytevector-n* # 8)

./guix/serialization.scm:80:6: In procedure get-bytevector-n*:
ERROR:
  1. :
  file: #f
  port: #
guix pull: error: You found a bug: the program 
'/gnu/store/47jgrwakv5mwmxp1whz1i1wmhb50xd7j-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"e7886fd6746267e26cf11628f96d8082680b496f"; system: "x86_64-linux";

host version: "f8aa8899e265a46fd3dff6c717ec484057ba2b68"; pull-version: 1).
Please report the COMPLETE output above by email to .

bug#53915: No way of replacing an input in modify-input syntax structure but keep all the outputs

[Ludovic Courtès]

Hi,

Gordon Quad  skribis:

> poppler package include glib as a native-input with "bin" output.
>
> If I am doing the following:
>
> (package/inherit poppler
> (native-inputs
> (modify-inputs (package-native-inputs poppler)
> (replace "glib" my-glib
>
> poppler's build will fail becuase replace syntax will replace "glib"
> package erasing its outputs.

Indeed:

--8<---cut here---start->8---
scheme@(guile-user)> ,use(gnu packages pdf)
scheme@(guile-user)> ,use(guix)
scheme@(guile-user)> (package-native-inputs poppler)
$4 = (("pkg-config" #) ("glib" # "bin") ("gobject-introspection" #))
scheme@(guile-user)> (package-propagated-inputs poppler)
$5 = (("glib" #))
scheme@(guile-user)> (modify-inputs (append $5 $4)
   (replace "glib" xpdf))
$6 = (("glib" #) 
("pkg-config" #) ("glib" #) ("gobject-introspection" #))
--8<---cut here---end--->8---

We see that both ‘glib’ packages have been replaced, but the “bin” part
has been removed from the second one.

With the patch below, we get more sensible behavior:

--8<---cut here---start->8---
scheme@(guile-user)> (modify-inputs (append $5 $4)
   (replace "glib" xpdf))
$8 = (("glib" #) 
("pkg-config" #) ("glib" # "bin") ("gobject-introspection" #))
--8<---cut here---end--->8---

If that makes sense to you, I’ll go ahead with this change and adjust
documentation accordingly.

Thanks for bringing it up!

Ludo’.

diff --git a/guix/packages.scm b/guix/packages.scm
index 3f0262602d..288ae37523 100644
--- a/guix/packages.scm
+++ b/guix/packages.scm
@@ -1091,11 +1091,11 @@ (define (replace-input name replacement inputs)
   "Replace input NAME by REPLACEMENT within INPUTS."
   (map (lambda (input)
  (match input
-   (((? string? label) . _)
+   (((? string? label) _ . outputs)
 (if (string=? label name)
 (match replacement;does REPLACEMENT specify an output?
   ((_ _) (cons label replacement))
-  (_ (list label replacement)))
+  (_ (cons* label replacement outputs)))
 input
inputs))
 

bug#54292: Commit e8518c43 breaks guix pull on i686

[Liliana Marie Prikler]

Am Dienstag, dem 08.03.2022 um 09:00 +0100 schrieb Liliana Marie
Prikler:
> > I do think this is an issue with commit e8518c43 because
> > 
> > --8<---cut here---start->8---
> > guix pull --commit=e8518c43 --system=i686-linux -p /tmp/guix
> > --8<---cut here---end--->8---
> > 
> > fails to build the package cache whereas 
> > 
> > --8<---cut here---start->8---
> > guix pull --commit=75f9f944 --system=i686-linux -p /tmp/guix
> > --8<---cut here---end--->8---
> > 
> > succeeds (75f9f944 being the parent commit of e8518c43).  I even ran
> > these with --substitute-urls=https://bordeaux.guix.gnu.org in a
> > freshly downloaded instance of the 1.3.0 QEMU image [5] to rule out
> > corrupted substitutes from berlin with the same result.
> For the sake of completeness, I'll be running this with --no-
> substitutes and see what happens.  If you want to try the same without
> rebuilding the world, I suggest first pulling
> b5f654b238dd3dec43b0ee9e08b78981cf8de981 with substitutes -- that is
> the last commit before the series. 
Okay, I now have the confirmation that this fails even "without any
substitutes" (I only had the guix package itself substituted to cut out
a little of the bootstrap chain).  I also have a full backtrace:

In gnu/packages.scm:
   437:11 19 (generate-package-cache _)
In srfi/srfi-1.scm:
   460:18 18 (fold # _ _)
In guix/packages.scm:
   518:21 17 (expand-cache . _)
  1260:17 16 (supported-package? #
…)
In guix/memoization.scm:
101:0 15 (_ # #
…)
In guix/packages.scm:
  1230:12 14 (_)
In srfi/srfi-1.scm:
   460:18 13 (fold #
…)
In guix/packages.scm:
  1234:42 12 (_ _ ("x86_64-linux" "i686-linux" "armhf-linux" "aar…" …))
In guix/memoization.scm:
101:0 11 (_ # #
…)
In guix/packages.scm:
  1230:12 10 (_)
In srfi/srfi-1.scm:
   460:18  9 (fold #
…)
In guix/packages.scm:
  1234:42  8 (_ _ ("x86_64-linux"))
In guix/memoization.scm:
101:0  7 (_ # #
…)
In guix/packages.scm:
  1238:37  6 (_)
  1498:16  5 (package->bag _ _ _ #:graft? _)
  1603:43  4 (thunk)
In gnu/packages/chez.scm:
   457:28  3 (arguments #)
65:16  2 (chez-machine->threaded #f)
In unknown file:
   1 (string-ref #f 0)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

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.

Cheers

bug#54033: Calibre's ebook-viewer only shows white-on-white or dark-on-dark.

[Guillaume Le Vaillant]

"bdju"  skribis:

> On Fri Mar 4, 2022 at 8:07 AM CST, Guillaume Le Vaillant wrote:
>> Hi,
>>
>> FreeCAD also has some issues with the rendering of its "start page"
>> where the text is missing.
>> And as Calibre and FreeCAD are apparently both Python applications using
>> QtWebEngine, it may indicate that there is something not working
>> correctly in QtWebEngine or in the Python bindings to QtWebEngine.
>
> qutebrowser and anki are also affected. There's an issue somewhere about
> it already.

Zhu Zihao found a workaround (see issue 54297): passing "--no-sandbox"
to Chromium.

So the text is rendered correctly when using:
--8<---cut here---start->8---
QTWEBENGINE_CHROMIUM_FLAGS="--no-sandbox" ebook-viewer
QTWEBENGINE_CHROMIUM_FLAGS="--no-sandbox" calibre
QTWEBENGINE_CHROMIUM_FLAGS="--no-sandbox" FreeCAD
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#54297: Acknowledgement (Qutebrowser failed to render local fonts.)

[Zhu Zihao]

Tweaks the qt.args in Qutebrowser by adding "no-sandbox" it now renders
text properly, I guess the sandbox of qtwebengine is broken.
-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao


signature.asc
Description: PGP signature

bug#52152: Haskell Hackage importer can create dependency cycles

[zimoun]

Hi,

On dim., 28 nov. 2021 at 02:50, John Kehayias  
wrote:

> While working on importing a bunch of Haskell packages, I came across
> a cycle created by the importer (twice actually, but forgot the other
> one). Perhaps this is from the metadata from Hackage, as it doesn't
> create the cycle when importing from Stackage. Here are the outputs:

The difference comes from upstream:

 - hackage fetches from
   https://hackage.haskell.org/package/OneTuple/OneTuple-0.3.1.tar.gz
 - stackage fetches from
   https://hackage.haskell.org/package/OneTuple/OneTuple-0.2.2.1.tar.gz

Therefore, it is not the same version.  Let compare:

--8<---cut here---start->8---
$ guix import hackage OneTuple

Starting download of /tmp/guix-file.7VmwVe
>From https://hackage.haskell.org/package/OneTuple/OneTuple-0.3.1.tar.gz...
 ….3.1.tar.gz  5KiB   3.8MiB/s 00:00 [##] 100.0%
(package
  (name "ghc-onetuple")
  (version "0.3.1")
[...]
(base32 "1vry21z449ph9k61l5zm7mfmdwkwszxqdlawlhvwrd1gsn13d1cq"
[...]

  (inputs (list ghc-hashable ghc-base-orphans))
  (native-inputs (list ghc-onetuple ghc-onetuple))
  (arguments
`(#:cabal-revision
  ("2" "0gk0656igxl0km9kgh8v7b5vq74kla59ka9hvpzq57njr6bc0j58")))
[...]

  (description
"This package is a compatibility package for a singleton data type . > data 
Solo
a = Solo a .  Note: it's not a @newtype@ . @Solo@ is available in @base-4.16@
(GHC-9.2).")

$ guix import stackage OneTuple

Starting download of /tmp/guix-file.WpQBJV
>From https://hackage.haskell.org/package/OneTuple/OneTuple-0.2.2.1.tar.gz...
 …2.2.1.tar.gz10.9MiB/s 00:00 | 3KiB transferred
(package
  (name "ghc-onetuple")
  (version "0.2.2.1")
[...]
(base32 "15ls6kkf953288q7rsc49bvw467ll4nq28hvsgbaazdn7hf75ixc"
[...]

  (arguments
`(#:cabal-revision
  ("1" "03mygfz7lv6h0i30bq2grvmahbg9j7a36mc0wls2nr81dv9p19s7")))
[...]

  (description
"This package provides a singleton tuple data type . > data OneTuple a = 
OneTuple
a .  Note: it's not a @newtype@")
--8<---cut here---end--->8---


And the "cycle" seems expected from OneTuple.cabal:

--8<---cut here---start->8---
$ cat OneTuple-0.3.1/OneTuple.cabal
cabal-version:  >=1.10

[...]

test-suite th
  type: exitcode-stdio-1.0
  default-language: Haskell98
  hs-source-dirs:   test
  main-is:  th.hs
  build-depends:
  base
, OneTuple
, template-haskell
--8<---cut here---end--->8---


Well, for what they are worth, based on this remark, two points:

 1. I do not know what could be done on Guix side.  An idea?
 2. Usually, it is recommended to follow LTS and so Stackage.


Cheers,
simon

bug#52836: "guix import pypi" fails with "Failed to extract file from wheel" and "no requires.txt file found"

[zimoun]

Hi,

On ven., 31 déc. 2021 at 12:00, zimoun  wrote:
> On Fri, 31 Dec 2021 at 11:15, bbb ee  wrote:
>
>> > Is it a bug on Guix side or upstream?  Because it seems that upstream
>> > does not provide metadata information, at least, as usually expected.
>>
>> `pip install PyPortfolioOpt`, `poetry add PyPortfolioOpt` runs for me. If 
>> other python package installer can run, I suppose the upstream is correct.
>
> Hum, not necessary.  Well, I do not think that 'pip' uses all the
> metadata from PyPI to install.  'pip' does dirty things and yes it
> just works :-)  But this does not imply that PyPortfolioOpt is
> correctly packaged as it is defined by PyPI standards.  I do not know
> 'poetry'.
>
> Anyway. :-)  I am not finding the PEP defining the Python packaging
> and the structure for a PyPI package.  Because it is not clear for me
> if it is a bug on Guix side or upstream.

This package PyPortfolioOpt is badly packaged upstream.  We cannot do
better than warn about the issue:

--8<---cut here---start->8---
$ guix import pypi  PyPortfolioOpt
following redirection to `https://pypi.org/pypi/pyportfolioopt/json'...

Starting download of /tmp/guix-file.6rSGsS
>From 
>https://files.pythonhosted.org/packages/97/c2/c7569f2773f3e942367e90dcca15a235af3d3330ac8abfcbfbe67a8ba8dd/PyPortfolioOpt-1.5.1.tar.gz...
 …t-1.5.1.tar.gz  56KiB   8.2MiB/s 00:00 [##] 100.0%

Starting download of /tmp/guix-file.MFmUSK
>From 
>https://files.pythonhosted.org/packages/90/98/3906835b783ba39cfc613c7b0c0fde9c758c729ff3406d45f1c2a1116961/PyPortfolioOpt-1.5.1-py3-none-any.whl...
 ….1-py3-none-any.whl  60KiB 45.2MiB/s 00:00 [##] 100.0%
guix import: warning: Failed to extract file: 
PyPortfolioOpt-1.5.1.dist-info/METADATA from wheel.
guix import: warning: Cannot guess requirements from source archive: no 
requires.txt file found.
guix import: warning: project name pyportfolioopt does not appear verbatim in 
the PyPI URI
hint: The PyPI URI is:
`https://files.pythonhosted.org/packages/97/c2/c7569f2773f3e942367e90dcca15
a235af3d3330ac8abfcbfbe67a8ba8dd/PyPortfolioOpt-1.5.1.tar.gz'.  You should
review the pypi-uri declaration in the generated package.  You may need to
replace "pyportfolioopt" with a substring of the PyPI URI that identifies
the package.

(package
  (name "python-pyportfolioopt")
  (version "1.5.1")
  (source
(origin
  (method url-fetch)
  (uri (pypi-uri "pyportfolioopt" version))
  (sha256
(base32 "162d6jyvba0xk2blssbp52rrjqpjv011h988k150p1fg7x7nzbs9"
  (build-system python-build-system)
  (home-page "https://github.com/robertmartin8/PyPortfolioOpt;)
  (synopsis "Financial portfolio optimization in python")
  (description "Financial portfolio optimization in python")
  (license license:expat))
--8<---cut here---end--->8---


Therefore, I am closing.  Feel free to reopen if I missed a point.


Cheers,
simon

bug#52350: pypi import: ungraceful exit when recursively importing unknown package

[zimoun]

Hi Ricardo,

On mar., 07 déc. 2021 at 11:26, Ricardo Wurmus  wrote:

> ./pre-inst-env guix import pypi -r pytestrerunfailures

--8<---cut here---start->8---
$ guix import pypi pytestrerunfailures
following redirection to `https://pypi.org/pypi/pytestrerunfailures/json/'...
guix import: error: failed to download meta-data for package 
'pytestrerunfailures'

$ guix import pypi pytestrerunfailures -r
following redirection to `https://pypi.org/pypi/pytestrerunfailures/json/'...
--8<---cut here---end--->8---

Fixed by f7bb161445903c51d299307610403cb3de0fcc56, at least the ugly
backtrace.  However, it is still unsatisfactory since the error is not
correctly handled.

I propose to close because the exit is now graceful -- at least less
ungraceful. :-)


Cheers,
simon

bug#42289: recursive import does not dort alphabetically

[zimoun]

Hi Hartmut,

On jeu., 09 juil. 2020 at 09:53, Hartmut Goebel  
wrote:
> In most gnu/packages/*.scm files are (expected to be) sorted alphabetically.

While I agree with this recommendation to sort alphabetically
gnu/packages/*.scm...

> Now when importing some packages recursivly, packages are output in
> order of the dependency graph, thus authors need to sort them manually.

...I think it is not a good idea to sort alphabetically the output of
the importers, because:

 1. the packages have to be added dependency-sorted,
 2. since each imported package is not alphabetically adjacent in the
 larger collection of already available packages, the user still needs
 to find the correct location.

Therefore, I am in favor to close this issue as wontfix notabug.  WDYT?


Cheers,
simon

bug#49168: ‘guix import pypi’ misses package dependencies

[zimoun]

Hi,

On lun., 28 juin 2021 at 11:39, Ludovic Courtès  wrote:
> Maxim Cournoyer  skribis:

>> In the mean time, the statu quo seems the best option to me (manually
>> specify the setuptools extensions as native-inputs for the python
>> packages that need it).  We should look forward adjusting our importer
>> to the latest PEP 517 trends (along the PEP 517 build system patches
>> awaiting review for core-updates!), which are quickly becoming
>> ubiquitous in the Python world.

> In the meantime I guess we can close this bug?

Do we wait the merge of the branch 'wip-python-pep517' to close this
report?  Or can we close it now?


Cheers,
simon

bug#35673: pypi importer returns the wheel hash when it fails to find a proper source.

[zimoun]

Hi,

On ven., 10 mai 2019 at 14:41, Jack Hill  wrote:
> As discussed on guix-devel[0] the pypi importer should probably not fill in
> the hash with that of the wheel if a proper source archive is not found on
> pypi.
>
> [0] https://lists.gnu.org/archive/html/guix-devel/2019-05/msg00209.html

Now the importer displays some warnings and hint, for instance:

--8<---cut here---start->8---
$ guix import pypi  PyPortfolioOpt
following redirection to `https://pypi.org/pypi/pyportfolioopt/json'...

Starting download of /tmp/guix-file.6rSGsS
>From 
>https://files.pythonhosted.org/packages/97/c2/c7569f2773f3e942367e90dcca15a235af3d3330ac8abfcbfbe67a8ba8dd/PyPortfolioOpt-1.5.1.tar.gz...
 …t-1.5.1.tar.gz  56KiB   8.2MiB/s 00:00 [##] 100.0%

Starting download of /tmp/guix-file.MFmUSK
>From 
>https://files.pythonhosted.org/packages/90/98/3906835b783ba39cfc613c7b0c0fde9c758c729ff3406d45f1c2a1116961/PyPortfolioOpt-1.5.1-py3-none-any.whl...
 ….1-py3-none-any.whl  60KiB 45.2MiB/s 00:00 [##] 100.0%
guix import: warning: Failed to extract file: 
PyPortfolioOpt-1.5.1.dist-info/METADATA from wheel.
guix import: warning: Cannot guess requirements from source archive: no 
requires.txt file found.
guix import: warning: project name pyportfolioopt does not appear verbatim in 
the PyPI URI
hint: The PyPI URI is:
`https://files.pythonhosted.org/packages/97/c2/c7569f2773f3e942367e90dcca15
a235af3d3330ac8abfcbfbe67a8ba8dd/PyPortfolioOpt-1.5.1.tar.gz'.  You should
review the pypi-uri declaration in the generated package.  You may need to
replace "pyportfolioopt" with a substring of the PyPI URI that identifies
the package.

(package
  (name "python-pyportfolioopt")
  (version "1.5.1")
  (source
(origin
  (method url-fetch)
  (uri (pypi-uri "pyportfolioopt" version))
  (sha256
(base32 "162d6jyvba0xk2blssbp52rrjqpjv011h988k150p1fg7x7nzbs9"
  (build-system python-build-system)
  (home-page "https://github.com/robertmartin8/PyPortfolioOpt;)
  (synopsis "Financial portfolio optimization in python")
  (description "Financial portfolio optimization in python")
  (license license:expat))
--8<---cut here---end--->8---

If it is not enough, could you provide an example?


Cheers,
simon

bug#54259: pypi importer prints backtrace when no source package exists

[zimoun]

Hi Ludo,

On Tue, 8 Mar 2022 at 09:36, Ludovic Courtès  wrote:

> Fixed in ebb03447f8cc93b9e070b3e7706d7a64d5d1772c.
>
> The problem was with projects that lack a home page on PyPI.  For
> others, the result looks like this:

Well, we are fixing importer per importer when the same issue appears
across many if not all the importers.  For instance, a similar issue
for opam:




And I remember one about hackage but I cannot find the report -- maybe
fixed since then.

My point is : the importers would deserve a revamp and refactoring.
Maybe an Outreachy project. :-)


Cheers,
simon

bug#53296: Intermittent segfaults when parsing (?) custom package from repo.

[Ludovic Courtès]

Hi,

Any update on this one?

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

If there’s no reliable way to reproduce it, I’ll close the bug soon.

Thanks,
Ludo’.

Ludovic Courtès  skribis:

> Hi,
>
> elaexuo...@wilsonb.com skribis:
>
>> Ludovic Courtès  wrote:
>>> Here’s how I tried (and failed) to reproduce the segfault:
>>> 
>>> --8<---cut here---start->8---
>>> $ find /tmp/test
>>> /tmp/test
>>> /tmp/test/gnu
>>> /tmp/test/gnu/packages
>>> /tmp/test/gnu/packages/jsoftware.scm
>>> 
>>> $ guix build -L /tmp/test jsoftware
>>> /tmp/test/gnu/packages/jsoftware.scm:76:0: warning: source expression 
>>> failed to match any pattern
>>> guix build: error: jsoftware: nekonata pako
>>
>> Is that an Esperanto locale?!
>
> Jes!
>
>> The segfault is pretty inconsistent on my end. Unfortunately, the only
>> "reliable" way to produce I know at the moment is to badger the build command
>> repeatedly and get (un)lucky.
>
> OK, please let us know when you have a reliable reproducer, or GDB
> backtraces, things like that.
>
> Thanks,
> Ludo’.

bug#53904: Using an http proxy, derivation failed

[Ludovic Courtès]

Hi,

dal-bla...@onenetbeyond.org skribis:

> The systemd unit file from debian looks like that
> (I only added the https_proxy, with localhost or 127.0.0.1, with or
> without the leading http://):

[...]

> [Service]
> ExecStart=/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon 
> --build-users-group=guixbuild
> Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale'
>  LC_ALL=en_US.utf8 'https_proxy=http://localhost:8082/'

Looks good to me.

> After reloading the daemons and restarting the daemon :
>
> guix pull: error: failed to connect to `/var/guix/daemon-socket/socket': 
> Connection refused

This suggests that guix-daemon is not running.  Could it be that it
failed to start?  Does ‘journalctl -u guix-daemon.service’ contain any
clue?

BTW, according to the output you pasted earlier (in particular the noisy
locale warnings), it seems that your daemon needs an update.  Check out
.

Thanks,
Ludo’.

bug#54075: Bug when performing guix pull

[Ludovic Courtès]

Hi Silas,

Silas Vedder  skribis:

> In ./guix/serialization.scm:
>102:11  1 (read-int #)
>  80:6  0 (get-bytevector-n* # 8)
>
> ./guix/serialization.scm:80:6: In procedure get-bytevector-n*:
> ERROR:
>   1. :
>   file: #f
>   port: #
> guix pull: error: You found a bug: the program 
> '/gnu/store/n1mqpdkdf1iczjdsz3i9cyrwchj9hhcd-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "45995eab3ae62ceef89ee223a1bc805738356c1f"; system: "x86_64-linux";
> host version: "755c7c80825c150b5a8b38072bcfb78699f2fbf2"; pull-version: 1).
> Please report the COMPLETE output above by email to .

It looks like a transient error networking error, poorly handled.  Could
you check whether that still happens?

Thanks,
Ludo’.

bug#54259: pypi importer prints backtrace when no source package exists

[Ludovic Courtès]

Hi,

Ricardo Wurmus  skribis:

> The only download for the kaleido package on Pypi is a binary.  There is
> no source code on Pypi.  The importer recognizes this but then prints a
> confusing backtrace when attempting to print a hint:
>
> ./pre-inst-env guix import pypi kaleido
> guix import: error: no source release for pypi package kaleido 0.2.1.post1
>
> hint: Backtrace:

[...]

> texinfo.scm:92:2: In procedure loop:
> Throw to key `parser-error' with args `(#f "@-command expected more 
> arguments:" () (url #:opt title replacement) (url #:opt title replacement))'.

Fixed in ebb03447f8cc93b9e070b3e7706d7a64d5d1772c.

The problem was with projects that lack a home page on PyPI.  For
others, the result looks like this:

--8<---cut here---start->8---
$ ./pre-inst-env guix import pypi torch
guix import: error: no source release for pypi package torch 1.10.2

hint: This indicates that the package is available on PyPI, but only as a 
"wheel" containing
binaries, not source.  To build it from source, refer to the upstream 
repository at
`https://pytorch.org/'.
--8<---cut here---end--->8---

Ludo’.

bug#54209: ‘guix shell -D … --with-branch …’ leads to an invalid derivation

[Ludovic Courtès]

Ludovic Courtès  skribis:

> The following command ends up creating an invalid derivation in the
> glib-schemas hook:
>
> $ guix shell -D guile-next  --with-branch=guile-next=stable-2.2 
> python-matplotlib  
> guix shell: error: derivation 
> `/gnu/store/6hy95hpjbbzvppwxndzapi3f5s1xcgkm-glib-schemas.drv' has incorrect 
> output `/gnu/store/vahx614bazd4zk5akkqp1y7aflbi1rla-glib-schemas', should be 
> `/gnu/store/m0138ijax94m5lcdksw8jz5zdvlhdghh-glib-schemas'

Fixed:

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

Ludo’.

bug#54292: Commit e8518c43 breaks guix pull on i686

[Liliana Marie Prikler]

Hi Diego,

Am Montag, dem 07.03.2022 um 18:12 + schrieb Diego Nicola Barbato:
> Hi Liliana,
> 
> Liliana Marie Prikler  writes:
> 
> > Hi,
> > 
> > Am Montag, dem 07.03.2022 um 12:47 + schrieb Diego Nicola
> > Barbato:
> > > Hi Guix,
> > > 
> > > Commit e8518c43 (gnu: Add stex) breaks guix pull, specifically
> > > the package cache hook, on i686-linux.
> > This series also fails on CI in a rather peculiar manner [1,2,3]. 
> > However, it succeeded on bordeaux, even for i686 [4].
> 
> While these CI issues are certainly interesting and possibly
> deserving of their own bug reports, they have little to do with this
> bug report: I didn't try to build chez-nanopass [1],
> chez-scheme-for-racket-bootstrap-bootfiles [2], or racket [4] itself
> and I didn't experience any offloading errors [3].  This bug report
> is about guix pull failing to build the package cache on i686-linux
> (the package cache is one of the last things guix pull builds, it
> didn't have any trouble building guix-packages-base, guix-packages,
> guix-system, guix-home, guix-cli, etc.).
These are very much related in that they all belong to the same series.
We would not only have to revert that single commit, but all following
commits authored by Philip as well.

> > I don't think this is an issue with the patch, we should start
> > challenging berlin.
> 
> I do think this is an issue with commit e8518c43 because
> 
> --8<---cut here---start->8---
> guix pull --commit=e8518c43 --system=i686-linux -p /tmp/guix
> --8<---cut here---end--->8---
> 
> fails to build the package cache whereas 
> 
> --8<---cut here---start->8---
> guix pull --commit=75f9f944 --system=i686-linux -p /tmp/guix
> --8<---cut here---end--->8---
> 
> succeeds (75f9f944 being the parent commit of e8518c43).  I even ran
> these with --substitute-urls=https://bordeaux.guix.gnu.org in a
> freshly downloaded instance of the 1.3.0 QEMU image [5] to rule out
> corrupted substitutes from berlin with the same result.
For the sake of completeness, I'll be running this with --no-
substitutes and see what happens.  If you want to try the same without
rebuilding the world, I suggest first pulling
b5f654b238dd3dec43b0ee9e08b78981cf8de981 with substitutes -- that is
the last commit before the series. 

> 
Cheers