Guix installer on foreign distro breaks /usr/local/share/info/dir

[Garjola Dindi]

Hi,

I recently installed the Guix package manager on Debian and found
symlinks on /usr/local/share/info/. One of them looks like this

ls -l /usr/local/share/info/dir
lrwxrwxrwx 1 root staff 60 Jan 10 12:04 /usr/local/share/info/dir ->
/var/guix/profiles/per-user/root/current-guix/share/info/dir

This breaks the info directory. Is this a bug? I didn't do anything
special during installation.

Thanks.

-- 

Re: Single-board-computer approach: don't make an installer, make the install?

[Christopher Lemmer Webber]

Joshua Branson writes:

> Mathieu Othacehe  writes:
>
>> Mathieu
>>
>> [1]: https://othacehe.org/the-guix-system-image-api.html
>
> This is really well written.  May I edit this article and reproduce it
> for the guix blog and perhaps the guix manual?  If ludo's ok with me
> putting it on the blog, then I intend to end the blog post with "This
> article first appeared in this personal blog (link here) and is
> reproduced with permission."

It is good.

Maybe in the cookbook?

>> [2]: https://archive.fosdem.org/2020/schedule/event/ggaaattyp/
>>

Re: guix time-machine, broken hash in an old package definition, a workaround?

[Leo Famulari]

On Wed, Jan 13, 2021 at 08:37:30PM +0100, Wiktor Żelazny wrote:
> Yeah, there may be a connection. Is --no-substitutes a way to avoid this
> error?

Yes, the problem is in the substituter so --no-substitutes will avoid
it. You might spend a loong time building things but it depends on
the specific package(s).


signature.asc
Description: PGP signature

Error when installing libnode

[Pierre-Antoine Bouttier]

Dear Guix community,

I try to install libnode through guix and I have this error :

---

 $ guix install libnode
The following package will be installed:
   libnode (dependencies or package changed)

substitute: 
/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash: 
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivation will be built:
   /gnu/store/a22nqd33fk2dp0zrm7jsqp50ncibw2ip-libnode-10.20.0.drv

/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash: 
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
building /gnu/store/a22nqd33fk2dp0zrm7jsqp50ncibw2ip-libnode-10.20.0.drv...
\ 'patch-node-shebang' phasebuilder for 
`/gnu/store/a22nqd33fk2dp0zrm7jsqp50ncibw2ip-libnode-10.20.0.drv' failed with 
exit code 1
build of /gnu/store/a22nqd33fk2dp0zrm7jsqp50ncibw2ip-libnode-10.20.0.drv failed
View build log at 
'/var/log/guix/drvs/a2/2nqd33fk2dp0zrm7jsqp50ncibw2ip-libnode-10.20.0.drv.bz2'.
guix install: error: build of 
`/gnu/store/a22nqd33fk2dp0zrm7jsqp50ncibw2ip-libnode-10.20.0.drv' failed

$ tail /var/log/guix/drvs/a2/2nqd33fk2dp0zrm7jsqp50ncibw2ip-libnode-10.20.0.drv
phase `install' succeeded after 1.0 seconds
starting phase `patch-node-shebang'
Backtrace:
   8 (primitive-load "/gnu/store/b5kwljjs1x9dqb7j2wi6gwyqpj7…")
In ice-9/eval.scm:
   191:35  7 (_ _)
In guix/build/gnu-build-system.scm:
838:2  6 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1736:10  5 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
   857:16  4 (every1 # …)
In guix/build/gnu-build-system.scm:
   847:30  3 (_ _)
In ice-9/eval.scm:
   293:34  2 (_ #(#(#(#) (#)) #))
In unknown file:
   1 (readlink "/gnu/store/7430qqkrdfy5gy6bhq0vn41ddl0l9jpx-…")
In ice-9/boot-9.scm:
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
In procedure readlink: No such file or directory
—

When I look the guix expression, it seems to me there is a problem with the 
line 179 of gnu/packages/node.scm : 
(npx(readlink (string-append bindir "/npx"

Do you have an idea on how can I fix this issue?

Thank you
---
Pierre-Antoine Bouttier
GriCAD Research Engineer

GriCAD - https://gricad.univ-grenoble-alpes.fr/
Batiment IMAG
CS 40700
38058 Grenoble CEDEX 9

+33 4 57 42 18  66

Re: Channel details of profile generation

[zimoun]

Hi,
On Tue, 12 Jan 2021 at 19:16, Phil  wrote:

> Then if I install another package for the 2nd generation I get the
> backtrace occurring (see below).

I cannot reproduce this.  However, I note that it is what I consider as
slow: ~15s to display.


> Perhaps the problem is specific to running Guix on Ubuntu 18.04 as all
> my servers run this?

Hum?  I do not know.  Do you have the same configuration (PATH etc.) on
your servers (which have the issue) and on your other machine (which has
not).

What does

  $ which guix

say?

>> Do you mean issues when replicating my example with only the channels
>> guix and guix-science?
>
> I've actually reduced this down to no channel.scm file (so only default
> guix channel), and picking 2 packages in guix - eg python and
> python-numpy.

--8<---cut here---start->8---
$ guix package -i python -p /tmp/test-profile -v 0
Le paquet suivant sera installé :
   python 3.8.2

conseil : Pensez à paramétrer les variables d'environnement nécessaires en 
lançant :

 GUIX_PROFILE="/tmp/test-profile"
 . "$GUIX_PROFILE/etc/profile"

Autrement, regardez `guix package --search-paths -p "/tmp/test-profile"'.

$ guix package -i python-numpy -p /tmp/test-profile -v 0
Le paquet suivant sera installé :
   python-numpy 1.17.3

conseil : Pensez à paramétrer les variables d'environnement nécessaires en 
lançant :

 GUIX_PROFILE="/tmp/test-profile"
 . "$GUIX_PROFILE/etc/profile"

Autrement, regardez `guix package --search-paths -p "/tmp/test-profile"'.

$ time guix pull -p /tmp/test-profile -l
Génération 113 janv. 2021 21:04:10
  python 3.8.2
Génération 213 janv. 2021 21:04:29  (actuelle)
  python 3.8.2
  python-numpy 1.17.3

real0m5,989s
user0m14,709s
sys 0m0,572s
--8<---cut here---end--->8---



All the best,
simon

Re: Single-board-computer approach: don't make an installer, make the install?

[Joshua Branson via]

Mathieu Othacehe  writes:

> Mathieu
>
> [1]: https://othacehe.org/the-guix-system-image-api.html

This is really well written.  May I edit this article and reproduce it
for the guix blog and perhaps the guix manual?  If ludo's ok with me
putting it on the blog, then I intend to end the blog post with "This
article first appeared in this personal blog (link here) and is
reproduced with permission."

> [2]: https://archive.fosdem.org/2020/schedule/event/ggaaattyp/
>

--
Joshua Branson
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help

enough other people get what they want." - Zig Ziglar

Re: noweb/LaTeX integration - .sty files not found

[Martin Michel]

Hi Paul,

thank you, using TEXINPUTS solved it for me!

−Martin

Re: guix time-machine, broken hash in an old package definition, a workaround?

[Wiktor Żelazny]

On Wed, Jan 13, 2021 at 01:57:06PM -0500, Leo Famulari wrote:
> On Wed, Jan 13, 2021 at 02:22:23PM +0100, Wiktor Żelazny wrote:
> > These attempts were either ignored by guix or resulted in
> >
> > guix time-machine: error: got unexpected path `Backtrace:' from substituter
>
> I don't think this error is related to time-machine and unstable source
> code. It appears to be .

Hi Leo,

Yeah, there may be a connection. Is --no-substitutes a way to avoid this
error?

WŻ


signature.asc
Description: PGP signature

Re: guix time-machine, broken hash in an old package definition, a workaround?

[Wiktor Żelazny]

On Wed, Jan 13, 2021 at 05:24:39PM +0100, zimoun wrote:

> One way to locally fix is: checkout the Guix repo at commit
> d81fb2ae9443994ae5dd1cb5837276fad63f842c, then tweak the checksum, build
> from this source, and use:
>
>   ./pre-inst-env guix environment -C -m manifest.scm

Hi simon,

Thanks for the tip. I may give it a try if there is no other solution
available at the moment.

WŻ


signature.asc
Description: PGP signature

Re: guix time-machine, broken hash in an old package definition, a workaround?

[Leo Famulari]

On Wed, Jan 13, 2021 at 02:22:23PM +0100, Wiktor Żelazny wrote:
> These attempts were either ignored by guix or resulted in
> 
> guix time-machine: error: got unexpected path `Backtrace:' from substituter

I don't think this error is related to time-machine and unstable source
code. It appears to be .

Re: guix time-machine, broken hash in an old package definition, a workaround?

[zimoun]

Hi,

Sadly, nothing can be done.  Well, I hope that someone will show me I am
wrong. :-)

--8<---cut here---start->8---
$ guix time-machine --commit=d81fb2ae9443994ae5dd1cb5837276fad63f842c \
   -- weather r-foreign \
   --substitute-urls="https://ci.guix.gnu.org https://bayfront.guix.gnu.org 
https://guix.cbaines.net https://guix.tobias.gr 
https://builds.guix-patches.cbaines.net";
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
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.

computing 1 package derivations for x86_64-linux...
looking for 1 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org
  .0% substitutes available (0 out of 1)
  unknown substitute sizes
  0.0 MiB on disk (uncompressed)
  0.000 seconds per request (0.0 seconds in total)
  2770.1 requests per second

  0.0% (0 out of 1) of the missing items are queued
  660 queued builds
  i586-gnu: 5 (.8%)
  aarch64-linux: 634 (96.1%)
  armhf-linux: 1 (.2%)
  x86_64-linux: 18 (2.7%)
  i686-linux: 2 (.3%)
  build rate: 111.65 builds per hour
  x86_64-linux: 37.52 builds per hour
  aarch64-linux: 70.38 builds per hour
  i686-linux: 4.14 builds per hour
looking for 1 store items on https://bayfront.guix.gnu.org...
updating substitutes from 'https://bayfront.guix.gnu.org'... 100.0%
https://bayfront.guix.gnu.org
  .0% substitutes available (0 out of 1)
  unknown substitute sizes
  0.0 MiB on disk (uncompressed)
  0.176 seconds per request (0.2 seconds in total)
  5.7 requests per second

  0.0% (0 out of 1) of the missing items are queued
  93 queued builds
  x86_64-linux: 93 (100.0%)
  'https://bayfront.guix.gnu.org/api/latestbuilds?nr=1000' returned 504 
("Gateway Time-out")
looking for 1 store items on https://guix.cbaines.net...
updating substitutes from 'https://guix.cbaines.net'... 100.0%
https://guix.cbaines.net
  .0% substitutes available (0 out of 1)
  unknown substitute sizes
  0.0 MiB on disk (uncompressed)
  1.751 seconds per request (1.8 seconds in total)
  0.6 requests per second
  (continuous integration information unavailable)
looking for 1 store items on https://guix.tobias.gr...
updating substitutes from 'https://guix.tobias.gr'... 100.0%
https://guix.tobias.gr
  .0% substitutes available (0 out of 1)
  unknown substitute sizes
  0.0 MiB on disk (uncompressed)
  0.210 seconds per request (0.2 seconds in total)
  4.8 requests per second
  (continuous integration information unavailable)
looking for 1 store items on https://builds.guix-patches.cbaines.net...
updating substitutes from 'https://builds.guix-patches.cbaines.net'... 100.0%
https://builds.guix-patches.cbaines.net
  .0% substitutes available (0 out of 1)
  unknown substitute sizes
  0.0 MiB on disk (uncompressed)
  0.182 seconds per request (0.2 seconds in total)
  5.5 requests per second
  (continuous integration information unavailable)
--8<---cut here---end--->8---

Well, maybe someone has the tarball in their personal store and could
share it.  Otherwise, it is game over.

The story about “guix time-machine” and tarball is far to be complete
and robust.  It is impossible to fix the upstream in-place replacement.
The only thing the Guix project can do is store these tarballs on their
machine; it is what it is commonly done but time to time edge cases
happen, sadly.

Instead of archiving the upstream source code on machines from Guix
projects, the idea is to use Software Heritage infrastructure as
archivist.  It works pretty well for Git source because the mapping
(content-address) between Git ID, SWH-ID, and NAR hash is almost
straightforward.  But, this mapping is not as straightforward for
tarballs because of metadata.  That’s the aim of the project Disarchive;
still experimental.

https://git.ngyro.com/disarchive-db/


One way to locally fix is: checkout the Guix repo at commit
d81fb2ae9443994ae5dd1cb5837276fad63f842c, then tweak the checksum, build
from this source, and use:

  ./pre-inst-env guix environment -C -m manifest.scm


All the best,
simon

Re: Single-board-computer approach: don't make an installer, make the install?

[Christopher Lemmer Webber]

Mathieu Othacehe writes:

> Hello Christopher,
>
>> I haven't tried it yet but can't think of a good reason it wouldn't
>> work.  Has anyone tried that?
>
> Sure, I would advise you to read this[1], which is a sort of follow-up
> of this article. You can also listen that talk[2].

O-ho!  Very good!

Looking forward to watching the talk tonight. :)

> I have been successfully producing ready to use disk-images for Pine64,
> Danny has done the same for Novena and there are a few people trying to
> do so for their Pinebook-pro.

Extra, super good!

> Thanks,
>
> Mathieu
>
> [1]: https://othacehe.org/the-guix-system-image-api.html
> [2]: https://archive.fosdem.org/2020/schedule/event/ggaaattyp/

Re: Single-board-computer approach: don't make an installer, make the install?

[Mathieu Othacehe]

Hello Christopher,

> I haven't tried it yet but can't think of a good reason it wouldn't
> work.  Has anyone tried that?

Sure, I would advise you to read this[1], which is a sort of follow-up
of this article. You can also listen that talk[2].

I have been successfully producing ready to use disk-images for Pine64,
Danny has done the same for Novena and there are a few people trying to
do so for their Pinebook-pro.

Thanks,

Mathieu

[1]: https://othacehe.org/the-guix-system-image-api.html
[2]: https://archive.fosdem.org/2020/schedule/event/ggaaattyp/

Single-board-computer approach: don't make an installer, make the install?

[Christopher Lemmer Webber]

I looked recently at this tutorial:

  https://guix.gnu.org/blog/2017/porting-guixsd-to-armv7/

However, it strikes me: maybe there's another nice approach?  Would it
be nicer to just make an image that the user boots into directly on the
beagleboard, if it's going onto a microsd card anyway, rather than
building an installer image?

I haven't tried it yet but can't think of a good reason it wouldn't
work.  Has anyone tried that?

Side note, a RISC-V Beagleboard SoC is coming.  I suspect that might be
very good helping us start ramping up getting Guix very usable on
RISC-V:

  
https://arstechnica.com/gadgets/2021/01/seeed-and-beagleboard-team-up-to-provide-a-new-risc-v-based-linux-pc/

Re: Channel details of profile generation

[Phil]

Just to add - I repeated the 'guix pull' experiments in the original
e-mail on Guix System using a VirtualBox and I could not reproduce
either the hanging or backtrace issues described.

So whatever the issue is it's limited to foreign OS use of Guix - but
does seem to be repeatable on Ubuntu 18.04 (at least the backtrace is).

This may explain why Simon could not reproduce?

Phil writes:

> Hi,
>
> Thanks - I think the original question is answered now - however I am
> curious over why only I can reproduce issues with the incorrect use of
> 'guix pull'.  It's tempting to say it's just undefined behaviour and
> move on with my life, but I've done a bit more digging

guix time-machine, broken hash in an old package definition, a workaround?

[Wiktor Żelazny]

Hi list,

It appears that the package bundles at CRAN are not stable. The bundle
contents can change, and so its hash. I’ve encountered such a problem
three times, I think, already, so it’s presumably systemic. The latest
(minimal working) example:

$ cat manifest.scm

(specifications->manifest
  '("r-foreign"))

$ cat channel-specs.scm

(list (channel
(name 'guix)
(url "https://git.savannah.gnu.org/git/guix.git";)
(commit
  "d81fb2ae9443994ae5dd1cb5837276fad63f842c")))

$ guix time-machine --commit=d81fb2ae9443994ae5dd1cb5837276fad63f842c 
--channels=channel-specs.scm -- environment -C --pure --manifest=manifest.scm

Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
building 
/gnu/store/ixqarfdy375cqwkwgvm9z8cadw87f6gg-foreign_0.8-75.tar.gz.drv...
downloading from 
http://cran.r-project.org/src/contrib/Archive/foreign/foreign_0.8-75.tar.gz...
/sha256 hash mismatch for 
/gnu/store/z6hkz6r1i5cgzjxc5m883lgh1xvjff8s-foreign_0.8-75.tar.gz:
  expected hash: 0g4mi101srjbl17ydb2hl3854m3xj0llj6861lfr30sp08nkqavl
  actual hash:   1c888wrn9xf94lp7w9kjw5l8fnarrkv5pi1px5rfnybm1qlysdx5
hash mismatch for store item 
'/gnu/store/z6hkz6r1i5cgzjxc5m883lgh1xvjff8s-foreign_0.8-75.tar.gz'
build of /gnu/store/ixqarfdy375cqwkwgvm9z8cadw87f6gg-foreign_0.8-75.tar.gz.drv 
failed
View build log at 
'/var/log/guix/drvs/ix/qarfdy375cqwkwgvm9z8cadw87f6gg-foreign_0.8-75.tar.gz.drv.bz2'.
cannot build derivation 
`/gnu/store/vx9187mcdj041sr76bivzbnggr6ajm4q-r-foreign-0.8-75.drv': 1 
dependencies couldn't be built
guix environment: error: build of 
`/gnu/store/vx9187mcdj041sr76bivzbnggr6ajm4q-r-foreign-0.8-75.drv' failed

I tried

. adding another channel with r-foreign redefined in hope that the one in guix
would get masked

. adding --with-input=r-foreign=r-foreign-redefined (the latter defined
in another channel)

. adding -L to the environment (also to time-machine) pointing to a
directory with r-foreign redefined

. an inferior

These attempts were either ignored by guix or resulted in

guix time-machine: error: got unexpected path `Backtrace:' from substituter

Is there a recommended way to deal with such a situation? Thank you for
taking a look.

WŻ


signature.asc
Description: PGP signature