bug#40893: import crate: Recursive importer loops

[Hartmut Goebel]

When running "import crate -r", the same packages get downloaded again
and again. Depending on the package to be imported, this looping can
take quite some time and the user gets the impression, that the import
will recurse endlessly.

I would expect the importer to recognize it did already download the
package.

$ guix pull --commit=ee8de7381  # to be sure the packages are not
imported already.
$ ./pre-inst-env guix import crate -r h2
...
following redirection to
`https://static.crates.io/crates/rustls/rustls-0.17.0.crate'...
...
following redirection to
`https://static.crates.io/crates/webpki/webpki-0.21.2.crate'...
following redirection to
`https://static.crates.io/crates/webpki-roots/webpki-roots-0.19.0.crate'...
...
following redirection to
`https://static.crates.io/crates/webpki/webpki-0.21.2.crate'...
following redirection to
`https://static.crates.io/crates/webpki-roots/webpki-roots-0.19.0.crate'...
...
following redirection to
`https://static.crates.io/crates/ring/ring-0.17.0-alpha.1.crate'...
following redirection to
`https://static.crates.io/crates/ring/ring-0.17.0-alpha.1.crate'...
...
following redirection to
`https://static.crates.io/crates/webpki/webpki-0.21.2.crate'...
...
following redirection to
`https://static.crates.io/crates/rustls/rustls-0.17.0.crate'...
following redirection to
`https://static.crates.io/crates/webpki/webpki-0.21.2.crate'...
following redirection to
`https://static.crates.io/crates/webpki-roots/webpki-roots-0.19.0.crate'...

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

bug#40894: import crate: Use proper variable names

[Hartmut Goebel]

"import crate -r" shall create and use "proper" variable names for the
package definitions it prints out and for the packages it reference.

If guix commits to use variable names follow the Cargo book (see
),
the importer shall create respective variables and use these names. This
would easy importing packages a lot.

Dummy example:

$guix import crate -r h2@0.2.4
…
(define-public rust-h2
…
    (arguments
  `(#:cargo-inputs
    (("rust-bytes" ,rust-bytes)
 ("rust-fnv" ,rust-fnv)

Shall become

$guix import crate -r h2@0.2.4
…
(define-public rust-h2-0.2
…
    (("rust-bytes" ,rust-bytes-0.4)
 ("rust-fnv" ,rust-fnv-1)


-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

bug#40895: import crate: Relaxed version selection

[Hartmut Goebel]

If (manually) importing dependencies for some package requiring "other
^0.2", I would like the importer to fetch the newest version of
other-0.2.x automatically.

As it is now, I need to specify the exact version number, e.g. "guix
import crate other@0.2.4" - and the get the version number I need to go
to crates.io, search the package and search the list of available
versions. The importer can do this much more efficient.

This could be implemented like this:

- If the version giben ("@0.2.4") matches an version available, use this
version.

- Otherwise, if the version giben ("@0.2") is a prefix of some available
version, use the highest/newest of these versions

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

bug#40899: Locales not set up correctly

[Matthew Kraai]

Hi,

After I launch an EC2 instance using the official Debian 10 Buster AMI
and run the attached script, which should match the installation
instructions in the manual, the locales don't seem to be set up
properly.  For example,

```
$ guix package -i nss-certs
guile: warning: failed to install locale
hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package 
and
defining `GUIX_LOCPATH', along these lines:

 guix package -i glibc-utf8-locales
 export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"

See the "Application Setup" section in the manual, for more info.

guix package: warning: Consider running 'guix pull' followed by
'guix package -u' to get up-to-date packages and security updates.

The following package will be installed:
   nss-certs 3.50

substitute: 
/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash: 
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
0.1 MB will be downloaded:
   /gnu/store/0y63pfqi2626nwsjbksrci1jyd62cxx8-nss-certs-3.50
/gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/bash: 
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
downloading from 
https://ci.guix.gnu.org/nar/lzip/0y63pfqi2626nwsjbksrci1jyd62cxx8-nss-certs-3.50...
 nss-certs-3.50  133KiB   189KiB/s 00:00 [  ]  
48.3%Backtrace:
In ice-9/boot-9.scm:
  1736:10  4 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
   3 (apply-smob/0 #)
In ice-9/boot-9.scm:
718:2  2 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  1 (_ #(#(#)))
In guix/ui.scm:
  1936:12  0 (run-guix-command _ . _)

guix/ui.scm:1936:12: In procedure run-guix-command:
Throw to key `encoding-error' with args `("scm_to_stringn" "cannot convert wide 
string to output locale" 84 #f #f)'.
substitution of /gnu/store/0y63pfqi2626nwsjbksrci1jyd62cxx8-nss-certs-3.50 
failed
guix package: error: some substitutes for the outputs of derivation 
`/gnu/store/mxp55201zl6wm2d82xdjnc8qa7qwgr85-nss-certs-3.50.drv' failed 
(usually happens due to networking issues); try `--fallback' to build 
derivation from source 
```

-- 
Matthew Kraai


install_guix.sh
Description: Bourne shell script

bug#40839: Shepherd activation .GO files are not cross-compiled ... and the Hurd

[Mathieu Othacehe]

Hello Janneke!

I had a look to (gnu system hurd), this is really nice! I think we could
try an explosive mixture of our two branches :)

More seriously, we could do something like:

--8<---cut here---start->8---
(define hurd-disk-image
  (image
   (format 'disk-image)
   (partitions
(list
 (partition
  (size 'guess)
  (label "Guix_image")
  (file-system "ext2")
  (flags '(boot))
  (initializer (gexp initialize-hurd-root-partition)))
--8<---cut here---end--->8---

then we could have some mapping in guix/scripts/system.scm to
associate:

* x86_64-linux -> efi-disk-image
* i586-pc-gnu -> hurd-disk-image

and one could get a hurd disk-image by typing: 

--8<---cut here---start->8---
guix system disk-image --target=i586-pc-gnu my-hurd-os.scm
--8<---cut here---end--->8---

One problem that can arise is the installation of grub. Currently
wip-disk-image does not support legacy Grub (MBR based)
installation.

This is because running grub-install needs root permissions, to mess with
/dev/something in order to write the MBR I guess.

We could also create a Hurd ISO if grub-mkrescue (that is used to make
the ISO bootable), supports the Hurd.

Adding Ludo that might have some insight here.

Thanks,

Mathieu

bug#40899: Locales not set up correctly

[zimoun]

Dear,

On Mon, 27 Apr 2020 at 14:30, Matthew Kraai  wrote:

> $ guix package -i nss-certs
> guile: warning: failed to install locale

There 3 points:

 a) "guix install glibc-utf8-locales" as root because of the daemon
and restart it. (depending on your system init, an extra config should
be required)
 b) "guix install glibc-utf8-locales" as regular user

This should fix the locales issues.

Note that depending on your locale, glibc-utf8-locles should not
provide it. (The term utf8 could be misleading). But en_US is provided
by it.



> guix package: error: some substitutes for the outputs of derivation 
> `/gnu/store/mxp55201zl6wm2d82xdjnc8qa7qwgr85-nss-certs-3.50.drv' failed 
> (usually happens due to networking issues); try `--fallback' to build 
> derivation from source

 c) Try:
  guix install nss-certs --fallback


Hope that helps,
simon

bug#40906: Downloading the incorrect sourceforge URL doesn't fail

[pkill9]

running `guix download
mirror://sourceforge/Jamulus/3.4.4/jamulus-3.4.4.tar.gz` eventually
downloads a HTML page.

bug#40906: Acknowledgement (Downloading the incorrect sourceforge URL doesn't fail)

[pkill9]

Weird, it is opening URLs fine again...

bug#40906: Downloading the incorrect sourceforge URL doesn't fail

[Leo Famulari]

On Mon, Apr 27, 2020 at 05:40:28PM +0100, pkill9 wrote:
> running `guix download
> mirror://sourceforge/Jamulus/3.4.4/jamulus-3.4.4.tar.gz` eventually
> downloads a HTML page.

`guix download` is just a tool for downloading things and putting them
in /gnu/store. Can you say what you expected to happen here, and how it
went wrong?

bug#40891: import crate: Traceback when package not found

[Ludovic Courtès]

Hi,

Hartmut Goebel  skribis:

> If "import crate" does not find the package, a traceback is shown (see
> below)

Fixed in 5fbc753ab524809cd81e3e5c54b3d0acbe33792d.

Thanks,
Ludo’.

bug#40837: core-updates: webkitgtk web process sandbox incomplete

[Jack Hill]

I didn't have any better luck with the Nix patch. I was also unable to any 
problems with /etc/pulse/client.conf when calling bwrap manually on the 
command line.


I'm afraid that I'm stuck for now. I have asked the WebKit developers for 
help: https://lists.webkit.org/pipermail/webkit-dev/2020-April/031184.html


Best,
Jack

bug#40803: One page HTML cookbooks are 404

[Björn Höfling]

Hi operator.name,

On Thu, 23 Apr 2020 22:17:13 +
"operator.name" via Bug reports for GNU Guix  wrote:

> As of now these following pages 404:
> 
> https://guix.gnu.org/cookbook/de/guix-cookbook.de.html
> https://guix.gnu.org/cookbook/en/guix-cookbook.html
> https://guix.gnu.org/cookbook/es/guix-cookbook.es.html
> https://guix.gnu.org/cookbook/fr/guix-cookbook.fr.html
> https://guix.gnu.org/cookbook/ru/guix-cookbook.ru.html
> https://guix.gnu.org/cookbook/zh-cn/guix-cookbook.zh_CN.html
> 
> According to the way back machine this seems to be a recent change -
> the last known good link is from 2020-04-02:
> 
> https://web.archive.org/web/20200402034805/https://guix.gnu.org/cookbook/en/guix-cookbook.html

I wanted to have a look into this but currently my computer is
downloading (and then compiling) the 2Gig tetex-live... I will
investigate it tomorrow.

Hint: The manual and guix-cookbook sources are in the main Guix git
repository under the "doc/" directory.

The website is in the maintenance.git repository under "hydra/". In
hydra/berlin.scm, you will find reference on how the Cookbook is built:

GUIX_MANUAL=guix-cookbook guix build -f doc/build.scm

I think a partial answer to the problem is that the Cookbook's texi
source is only available in English and German language: There is no
es/fr/ru/ch translation in the Guix source repository.

I think the 

(define %languages

should either be controlled by environment variables like with the
GUIX_MANUAL or should be dependent on the value of %manual.

BTW, the link to the translation project 404s too:

https://translationproject.org/domain/guix-cookbook.html
 
> Is there also a reason that Russian and Chinese don't have pdfs for
> the cookbook or the manual?

Yes, I stumbled upon this comment in doc/build.scm :-):

;; FIXME: Unfortunately building PDFs for non-Latin
;; alphabets doesn't work:
;; .
(guard (c ((invoke-error? c)

Thanks for your report,

Björn


pgph_P9FiH9z6.pgp
Description: OpenPGP digital signature

bug#40803: One page HTML cookbooks are 404

[pelzflorian (Florian Pelz)]

On Tue, Apr 28, 2020 at 01:01:03AM +0200, Björn Höfling wrote:
> BTW, the link to the translation project 404s too:
> 
> https://translationproject.org/domain/guix-cookbook.html

The cookbook is not available at the TP because no POT file is shipped
in Guix’ tarball.  Julien suggested moving the translation from the TP
infrastructure to a Weblate setup (which I agree Guix should try and
experiment with), so instead of waiting for inclusion of the cookbook
at the TP I just commited the German translation directly to Guix
master without going through the Translation Project.  (It is
important that the version at the TP is the most current version, but
since there is no cookbook at the TP, it does not matter currently.)

Regards,
Florian

bug#40837: core-updates: webkitgtk web process sandbox incomplete

[Jack Hill]

I'm a little bit unstuck now. I found a bubblwrap issue [0], which I 
believe is the one that we're running into.


[0] https://github.com/containers/bubblewrap/issues/195 "Errors when 
--bind used with a symlinked path"


With insight gained there, I've determined that the following simplified 
bwrap invocation succeeds:


"""
$ bwrap  --ro-bind-try /etc/pulse/client.conf /etc/pulse/client.conf 
--ro-bind /gnu /gnu --ro-bind /run/current-system /run/current-system -- 
/run/current-system/profile/bin/bash

"""

while the following invocation fails:

"""
$ bwrap --ro-bind /etc /etc --ro-bind-try /etc/pulse/client.conf 
/etc/pulse/client.conf --ro-bind /gnu /gnu --ro-bind /run/current-system 
/run/current-system -- /run/current-system/profile/bin/bash


bwrap: Can't create file at /etc/pulse/client.conf: No such file or 
directory

"""

The difference between the working and non-working invocations in that in 
the non-working invocation, /etc is already mounted withing the new 
namespace, which includes symlinks at /etc/pulse and 
/etc/pulse/client.conf, and the later mount of the /etc/pulse/client.conf 
symlink causese the problem.


Now to figure out what the solution is, and if it is best fixed in 
webkitgtk or bubblewrap :)


Ideas welcome!

Best,
Jack