bug#56410: [BUG] SBCL, GNU CLISP, and ASDF

[Christopher Rodriguez]

Per this[1] conversation on IRC, there is an issue with ASDF being
installed for SBCL while using GNU CLISP. It seems that when sbcl
libraries are installed, there are also some files created in
/etc/common-lisp/ that, by default, cause /any/ implementation of Common
Lisp using ASDF to prefer the SBCL libraries.

This can currently be worked around using an init file[2], but this is
not a user-friendly situation. I am looking into a possible solution,
but wanted to report the bug now in case someone else has more
experience than me.


[1]: https://logs.guix.gnu.org/guix/2022-07-04.log#214848
[2]: http://paste.debian.net/1246303/

--

Christopher Rodriguez


signature.asc
Description: PGP signature

bug#47474: fossil: hash mismatch

[zimoun]

Hi,

Thanks Jack for the follow up. :-)

On Tue, 05 Jul 2022 at 17:49, Ludovic Courtès  wrote:

> We would need to check whether older releases are available.  Disarchive
> is relatively recent so they’re likely to be missing there, but Timothy
> Sample has a Disarchive database that goes several years back, unlike
> disarchive.guix.gnu.org.  Worth checking!

I guess the Timothy’s database starts on 2019-05-05 which is v1.0.  The
last coverage is from Jan 2022.




> Anyhow, I think this issue can be closed.

Done.


Cheers,
simon

bug#47474: fossil: hash mismatch

[Jack Hill]

On Tue, 5 Jul 2022, Ludovic Courtès wrote:


Hi!

Jack Hill  skribis:


I'm also curious to know to fill in the archive for old versions. I
guess the first step would be to preserve the tarballs with the
original hashes. Does anyone have them? I notice that this happened
again with 2.17:

downloading from 
https://www.fossil-scm.org/home/tarball/f48180f2ff3169651a725396d4f7d667c99a92873b9c3df7eee2f144be7a0721/fossil-src-2.17.tar.gz
 ...
 fossil-src-2.17.tar.gz  6.0MiB 
  4.0MiB/s 00:02 [##] 100.0%
sha256 hash mismatch for 
/gnu/store/i695w5hp8vkgvkx40rs8p647mas0ldah-fossil-src-2.17.tar.gz:
  expected hash: 1gvx6xzrw1a8snlq9qmr6099r44ifghg0h0fw4jazqmmyxriqzsw
  actual hash:   18q5rc1d9d2zvrvsas5h419dv525ig9lyqswrx7bcl38zbjxics4


I got a substitute for the tarball:

--8<---cut here---start->8---
$ guix build 
"/gnu/store/svcwny2aw005mgyz7fsnm8m7v612q9d4-fossil-src-2.17.tar.gz.drv"
6.3 MB will be downloaded:
 /gnu/store/i695w5hp8vkgvkx40rs8p647mas0ldah-fossil-src-2.17.tar.gz
substituting 
/gnu/store/i695w5hp8vkgvkx40rs8p647mas0ldah-fossil-src-2.17.tar.gz...
downloading from 
https://ci.guix.gnu.org/nar/i695w5hp8vkgvkx40rs8p647mas0ldah-fossil-src-2.17.tar.gz
 ...
fossil-src-2.17.tar.gz  6.0MiB  
   16.3MiB/s 00:00 [##] 100.0%

/gnu/store/i695w5hp8vkgvkx40rs8p647mas0ldah-fossil-src-2.17.tar.gz
$ guix hash $(guix build 
"/gnu/store/svcwny2aw005mgyz7fsnm8m7v612q9d4-fossil-src-2.17.tar.gz.drv")
1gvx6xzrw1a8snlq9qmr6099r44ifghg0h0fw4jazqmmyxriqzsw
--8<---cut here---end--->8---

Alternatively, we can get it via the content-addressed endpoint:

--8<---cut here---start->8---
$ wget -qO- 
https://ci.guix.gnu.org/file/fossil-src-2.17.tar.gz/sha256/1gvx6xzrw1a8snlq9qmr6099r44ifghg0h0fw4jazqmmyxriqzsw
 |guix hash -
1gvx6xzrw1a8snlq9qmr6099r44ifghg0h0fw4jazqmmyxriqzsw
--8<---cut here---end--->8---

Last, Disarchive tarball metadata is available:

--8<---cut here---start->8---
$ wget -qO- https://disarchive.guix.gnu.org/sha256/$(guix hash -f hex $(guix build 
"/gnu/store/svcwny2aw005mgyz7fsnm8m7v612q9d4-fossil-src-2.17.tar.gz.drv")) |head
(disarchive
 (version 0)
 (gzip-member
   (name "fossil-src-2.17.tar.gz")
   (digest
 (sha256
   "5c7f1c73f7b5e2af24e10e40f0e07391909c1230b9e284a9d548059e7f377dbf"))
   (header
 (mtime 1633790590)
 (extra-flags 2)
$ wget -qO- https://disarchive.guix.gnu.org/sha256/$(guix hash -f hex $(guix build 
"/gnu/store/svcwny2aw005mgyz7fsnm8m7v612q9d4-fossil-src-2.17.tar.gz.drv")) 
|grep swhid
   (swhid 
"swh:1:dir:1d10cd5c9e0afaf7c95fa87cd50d4b6b13e6c6c9"))
--8<---cut here---end--->8---

… and tarball content is in Software Heritage:

 
https://archive.softwareheritage.org/browse/directory/1d10cd5c9e0afaf7c95fa87cd50d4b6b13e6c6c9/

So we’re doing OK: it’s definitely archived and won’t ever vanish!  :-)

Ludo’.


That's great!

I guess I ran into this because I was using `guix build` with 
`--no-substitutes`. Is it expected that we don't fallback to disarchive 
and Software Heritage in that case? If so, I guess my problem was an 
operator error. Can we close this ticket then, or are we still missing the 
tarballs for the older releases?


Best,
Jack

bug#47474: fossil: hash mismatch

[Ludovic Courtès]

Hi!

Jack Hill  skribis:

> I guess I ran into this because I was using `guix build` with
> `--no-substitutes`. Is it expected that we don't fallback to
> disarchive and Software Heritage in that case?

Yes, and that’s actually suboptimal:

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

> If so, I guess my problem was an operator error. Can we close this
> ticket then, or are we still missing the tarballs for the older
> releases?

We would need to check whether older releases are available.  Disarchive
is relatively recent so they’re likely to be missing there, but Timothy
Sample has a Disarchive database that goes several years back, unlike
disarchive.guix.gnu.org.  Worth checking!

Anyhow, I think this issue can be closed.

Ludo’.

bug#47474: fossil: hash mismatch

[Ludovic Courtès]

Hi!

Jack Hill  skribis:

> I'm also curious to know to fill in the archive for old versions. I
> guess the first step would be to preserve the tarballs with the
> original hashes. Does anyone have them? I notice that this happened
> again with 2.17:
>
> downloading from 
> https://www.fossil-scm.org/home/tarball/f48180f2ff3169651a725396d4f7d667c99a92873b9c3df7eee2f144be7a0721/fossil-src-2.17.tar.gz
>  ...
>  fossil-src-2.17.tar.gz  6.0MiB   
> 4.0MiB/s 00:02 [##] 100.0%
> sha256 hash mismatch for 
> /gnu/store/i695w5hp8vkgvkx40rs8p647mas0ldah-fossil-src-2.17.tar.gz:
>   expected hash: 1gvx6xzrw1a8snlq9qmr6099r44ifghg0h0fw4jazqmmyxriqzsw
>   actual hash:   18q5rc1d9d2zvrvsas5h419dv525ig9lyqswrx7bcl38zbjxics4

I got a substitute for the tarball:

--8<---cut here---start->8---
$ guix build 
"/gnu/store/svcwny2aw005mgyz7fsnm8m7v612q9d4-fossil-src-2.17.tar.gz.drv"
6.3 MB will be downloaded:
  /gnu/store/i695w5hp8vkgvkx40rs8p647mas0ldah-fossil-src-2.17.tar.gz
substituting 
/gnu/store/i695w5hp8vkgvkx40rs8p647mas0ldah-fossil-src-2.17.tar.gz...
downloading from 
https://ci.guix.gnu.org/nar/i695w5hp8vkgvkx40rs8p647mas0ldah-fossil-src-2.17.tar.gz
 ...
 fossil-src-2.17.tar.gz  6.0MiB 
16.3MiB/s 00:00 [##] 100.0%

/gnu/store/i695w5hp8vkgvkx40rs8p647mas0ldah-fossil-src-2.17.tar.gz
$ guix hash $(guix build 
"/gnu/store/svcwny2aw005mgyz7fsnm8m7v612q9d4-fossil-src-2.17.tar.gz.drv")
1gvx6xzrw1a8snlq9qmr6099r44ifghg0h0fw4jazqmmyxriqzsw
--8<---cut here---end--->8---

Alternatively, we can get it via the content-addressed endpoint:

--8<---cut here---start->8---
$ wget -qO- 
https://ci.guix.gnu.org/file/fossil-src-2.17.tar.gz/sha256/1gvx6xzrw1a8snlq9qmr6099r44ifghg0h0fw4jazqmmyxriqzsw
 |guix hash -
1gvx6xzrw1a8snlq9qmr6099r44ifghg0h0fw4jazqmmyxriqzsw
--8<---cut here---end--->8---

Last, Disarchive tarball metadata is available:

--8<---cut here---start->8---
$ wget -qO- https://disarchive.guix.gnu.org/sha256/$(guix hash -f hex $(guix 
build 
"/gnu/store/svcwny2aw005mgyz7fsnm8m7v612q9d4-fossil-src-2.17.tar.gz.drv")) |head
(disarchive
  (version 0)
  (gzip-member
(name "fossil-src-2.17.tar.gz")
(digest
  (sha256
"5c7f1c73f7b5e2af24e10e40f0e07391909c1230b9e284a9d548059e7f377dbf"))
(header
  (mtime 1633790590)
  (extra-flags 2)
$ wget -qO- https://disarchive.guix.gnu.org/sha256/$(guix hash -f hex $(guix 
build 
"/gnu/store/svcwny2aw005mgyz7fsnm8m7v612q9d4-fossil-src-2.17.tar.gz.drv")) 
|grep swhid
(swhid 
"swh:1:dir:1d10cd5c9e0afaf7c95fa87cd50d4b6b13e6c6c9"))
--8<---cut here---end--->8---

… and tarball content is in Software Heritage:

  
https://archive.softwareheritage.org/browse/directory/1d10cd5c9e0afaf7c95fa87cd50d4b6b13e6c6c9/

So we’re doing OK: it’s definitely archived and won’t ever vanish!  :-)

Ludo’.

bug#56398: (guix git) fails to check out repos with nested submodules

[Ludovic Courtès]

Hello,

It seems that ‘update-cached-checkout’ fails to handle nested Git
submodules, when a submodule itself has submodules:

--8<---cut here---start->8---
$ ./pre-inst-env guix refresh python-pytorch
gnu/packages/machine-learning.scm:2872:13: python-pytorch would be upgraded 
from 1.11.0 to 1.12.0
$ ./pre-inst-env  guix refresh -u python-pytorch
Backtrace:
In ice-9/eval.scm:
619:8 19 (_ #(#(#)))
In guix/ui.scm:
   2238:7 18 (run-guix . _)
  2201:10 17 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 16 (with-exception-handler _ _ #:unwind? _ # _)
  1752:10 15 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   659:37 14 (thunk)
  2168:25 13 (run-with-store # …)
In guix/scripts/refresh.scm:
   560:16 12 (_ _)
In srfi/srfi-1.scm:
634:9 11 (for-each # …)
In guix/scripts/refresh.scm:
   309:22 10 (update-package _ # …)
In guix/upstream.scm:
   475:10  9 (package-update/git-fetch _ _ #< pack…> …)
In guix/git.scm:
550:8  8 (latest-repository-commit # …)
472:7  7 (update-cached-checkout _ #:ref _ #:recursive? _ # _ # _ …)
In srfi/srfi-1.scm:
634:9  6 (for-each # …)
In guix/git.scm:
   333:20  5 (_ _)
In srfi/srfi-1.scm:
634:9  4 (for-each # …)
In guix/git.scm:
   325:16  3 (_ _)
In git/bindings.scm:
 77:2  2 (raise-git-error _)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Git error: failed to resolve path 
'/home/ludo/.cache/guix/checkouts/orwu3gj6brdg2ui6r2tl5me7plucokpvqvgbhe2yuo6jc2tovvha/third_party/gloo/third-party/googletest/.git':
 No such file or directory
$
$ ls 
/home/ludo/.cache/guix/checkouts/orwu3gj6brdg2ui6r2tl5me7plucokpvqvgbhe2yuo6jc2tovvha/third_party/gloo/third-party/
ls: cannot access 
'/home/ludo/.cache/guix/checkouts/orwu3gj6brdg2ui6r2tl5me7plucokpvqvgbhe2yuo6jc2tovvha/third_party/gloo/third-party/':
 No such file or directory
$ ls 
/home/ludo/.cache/guix/checkouts/orwu3gj6brdg2ui6r2tl5me7plucokpvqvgbhe2yuo6jc2tovvha/third_party/gloo/
cmake/  CODE_OF_CONDUCT.md  docs/  LICENSEtools/
CMakeLists.txt  CONTRIBUTING.md gloo/  README.md
$ ls 
/home/ludo/.cache/guix/checkouts/orwu3gj6brdg2ui6r2tl5me7plucokpvqvgbhe2yuo6jc2tovvha/third_party/gloo/.gitmodules
 
/home/ludo/.cache/guix/checkouts/orwu3gj6brdg2ui6r2tl5me7plucokpvqvgbhe2yuo6jc2tovvha/third_party/gloo/.gitmodules
--8<---cut here---end--->8---

Ludo’.

bug#47474: fossil: hash mismatch

[Jack Hill]

On Mon, 8 Nov 2021, zimoun wrote:


Indeed, when looking forward. :-)

However, in the context of Disarchive and long-term, it is seems
relevant to keep it still open; as example to test “guix time-machine”
and various fallbacks, IMHO.


I'm also curious to know to fill in the archive for old versions. I guess 
the first step would be to preserve the tarballs with the original hashes. 
Does anyone have them? I notice that this happened again with 2.17:


downloading from 
https://www.fossil-scm.org/home/tarball/f48180f2ff3169651a725396d4f7d667c99a92873b9c3df7eee2f144be7a0721/fossil-src-2.17.tar.gz
 ...
 fossil-src-2.17.tar.gz  6.0MiB 
  4.0MiB/s 00:02 [##] 100.0%
sha256 hash mismatch for 
/gnu/store/i695w5hp8vkgvkx40rs8p647mas0ldah-fossil-src-2.17.tar.gz:
  expected hash: 1gvx6xzrw1a8snlq9qmr6099r44ifghg0h0fw4jazqmmyxriqzsw
  actual hash:   18q5rc1d9d2zvrvsas5h419dv525ig9lyqswrx7bcl38zbjxics4

Looking forward:

I have asked upstream how we might avoid this problem: 
https://fossil-scm.org/forum/forumpost/4903c3fcc1


We'll see what they say.

Some other ideas in the meantime:

1) Develop a fossil-fetch that can be used like git-fetch to download from 
the source code repository directly.


2) Use git-fetch with the git-mirror. This would allow us to make use of 
our current git integration with Software Heritage.


Best,
Jack

bug#56371: Can't remove a package present in profil

[bbb ee]

close #56371

Le mar. 5 juil. 2022 à 12:46, bbb ee  a écrit :

> Thanks for the tip!
>
> Le lun. 4 juil. 2022 à 07:04, Julien Lepiller  a
> écrit :
>
>> It's not a bug, because you don't have icedtea in your profile, but
>> icedtea:jdk. Guix is picky with outputs. Try "guix remove icedtea:jdk" :)
>>
>> On July 3, 2022 7:25:46 PM GMT+02:00, bbb ee  wrote:
>>>
>>> Hi,
>>>
>>> I have icedtea installed in my current profil, but `guix package remove`
>>> doesn't find it.
>>> ```
>>> $ guix package -p ~/.guix-profile -I | grep icedtea
>>> icedtea 3.19.0   jdk
>>> /gnu/store/5k7lsz61p8fq37c9x5p9xalryjxk31bs-icedtea-3.19.0-jdk
>>> $ guix package -p ~/.guix-profile -r icedtea
>>> guix package: error: package 'icedtea' not found in profile
>>> ```
>>>
>>> It is a bug?
>>>
>>

bug#56371: Can't remove a package present in profil

[bbb ee]

Control: close #56371

Le mar. 5 juil. 2022 à 12:46, bbb ee  a écrit :

> close #56371
>
> Le mar. 5 juil. 2022 à 12:46, bbb ee  a écrit :
>
>> Thanks for the tip!
>>
>> Le lun. 4 juil. 2022 à 07:04, Julien Lepiller  a
>> écrit :
>>
>>> It's not a bug, because you don't have icedtea in your profile, but
>>> icedtea:jdk. Guix is picky with outputs. Try "guix remove icedtea:jdk" :)
>>>
>>> On July 3, 2022 7:25:46 PM GMT+02:00, bbb ee  wrote:

 Hi,

 I have icedtea installed in my current profil, but `guix package
 remove` doesn't find it.
 ```
 $ guix package -p ~/.guix-profile -I | grep icedtea
 icedtea 3.19.0   jdk
 /gnu/store/5k7lsz61p8fq37c9x5p9xalryjxk31bs-icedtea-3.19.0-jdk
 $ guix package -p ~/.guix-profile -r icedtea
 guix package: error: package 'icedtea' not found in profile
 ```

 It is a bug?

>>>

bug#56371: Can't remove a package present in profil

[bbb ee]

Thanks for the tip!

Le lun. 4 juil. 2022 à 07:04, Julien Lepiller  a écrit :

> It's not a bug, because you don't have icedtea in your profile, but
> icedtea:jdk. Guix is picky with outputs. Try "guix remove icedtea:jdk" :)
>
> On July 3, 2022 7:25:46 PM GMT+02:00, bbb ee  wrote:
>>
>> Hi,
>>
>> I have icedtea installed in my current profil, but `guix package remove`
>> doesn't find it.
>> ```
>> $ guix package -p ~/.guix-profile -I | grep icedtea
>> icedtea 3.19.0   jdk
>> /gnu/store/5k7lsz61p8fq37c9x5p9xalryjxk31bs-icedtea-3.19.0-jdk
>> $ guix package -p ~/.guix-profile -r icedtea
>> guix package: error: package 'icedtea' not found in profile
>> ```
>>
>> It is a bug?
>>
>

bug#56114: Guix does not have a documented general and practical procedure for lowering a single lowerable object to the /gnu/store/... string.

[zimoun]

Hi,

On Tue, 5 Jul 2022 at 09:57, Ludovic Courtès  wrote:

> I don’t take comments about unrelated things.  ;-)

So one more. ;-)


> As someone who writes gexps and manipulates “file-like objects”, it
> doesn’t matter whether a thing lowers to a derivation or to a plain
> store item.  What matters is that you can insert it in a gexp and it’ll
> do the right thing.  That’s why the docstrings don’t insist on that
> difference.
>
> Hope it makes sense!

The difference is explained nowhere and to understand why the returned
call is different, then one has to read the code; it is what I did.
:-)

Well, "do the right thing" is an expectation based on an understanding
about what the "right thing" means. :-)  When I am manipulating
"file-like objects", I am always confused by what it means and thus it
appears to me that it does not "do the right thing" and it is hard to
understand why.

Yes it makes sense to not insistt on that difference once you have
clear understanding of this very difference.  However, when learning
G-Exp -- which is already unusual -- "file-like objects" and how to
manipulate them is hard to grasp because the difference is never
written down.  I still think the docstring or the manual should
mention such difference.

Explicit is better than implicit.
In the face of ambiguity, refuse the temptation to guess.

– The Zen of Python, by Tim Peters –

Anyway!  That's unrelated. ;-)


Cheers,
simon

bug#56343: ‘tests/services/telephony.scm’ fails to run

[Lars-Dominik Braun]

Hi Maxim,

> It isn't obsolete, but I had forgotten there were both unit and functional 
> (system) tests for our Jami seevice. It's probably easy to adjust, I can look 
> into it when I'm back from travels in a few days.
I had to remove tests/services/telephony.scm from Makefile.am, so
we could update the guix package to fix other issues. Please revert
c23e0aa65d511a29f31da876f905594c0f8bce00 once you’ve fixed the tests.

Thanks,
Lars

bug#56389: ruby-nokogiri may be non-deterministic

[Wiktor Zelazny]

On Tue, Jul 05, 2022 at 07:09:37AM +0200, wzela...@vurv.cz wrote:

> Discovered by accident and did not explore further.

ruby-nokogiri@1.10.9 to be exact. Did not check @1.12.5. Guix version
4d126e776239cc2e9b2e39718d0a1051f4a9bbc3.

WŻ

bug#56389: ruby-nokogiri may be non-deterministic

[Wiktor Zelazny]

Discovered by accident and did not explore further.

WŻ

bug#56334: Should asdf-build-system/sbcl use load-system instead of compile-system?

[Pierre Neidhardt]

While we are rebuilding the Lisp world, I suggest we remove Coreutils
from the SBCL closure since it's only needed on LispWorks and on
non-Linux:

--8<---cut here---start->8---
(add-after 'install 'remove-coreutils-references
   ;; They are only useful on non-Linux, non-SBCL.
   (lambda* (#:key outputs #:allow-other-keys)
 (let* ((out (assoc-ref outputs "out"))
(share-dir (string-append out "/share/sbcl/")))
   (substitute* (string-append share-dir 
"src/code/run-program.lisp")
 (("\\(run-program \".*uname\"")
  "(run-program \"uname\""))
   (substitute* (string-append share-dir "contrib/asdf/asdf.lisp")
 (("\\(\".*/usr/bin/env\"")
  "(\"/usr/bin/env\""))
   (substitute* (string-append share-dir "contrib/asdf/uiop.lisp")
 (("\\(\".*/usr/bin/env\"")
  "(\"/usr/bin/env\""))

   #t)))
--8<---cut here---end--->8---



signature.asc
Description: PGP signature

bug#56346: [BUG] emacs-parsebib and emacs-ebib out of sync

[Nicolas Goaziou]

Hello,

Christopher Rodriguez  writes:

> The emacs-ebib package has been updated recently to depend upon new
> functionality in the emacs-parsebib package, however there has not been
> a release to allow emacs-parsebib to be updated, causing things to break
> on a purely-guix install of these packages.
>
> There has not been an upstream release tag created for emacs-parsebib
> since 2021-12-08 (which was version 3.1.0). However, 11 days ago, the
> actual library's version info was bumped to 4.1.0. This indicates that
> there was a breaking change (which there apparently was).
>
> I have commented on the commit bumping the internal version number[1]
> and I opened an issue to the same effect[2]. I am also in the process of
> recompiling the packages in my declaration that rely on emac-parsebib to
> rely on the commit mentioned above.
>
> So long as that works, I'll send a patch updating the Guix version of
> this package to this more-recent 'release' of emacs-ebib.

Thank you for the report.

I updated emacs-parsebib to 4.1. Closing.

Regards,
-- 
Nicolas Goaziou

bug#56114: Guix does not have a documented general and practical procedure for lowering a single lowerable object to the /gnu/store/... string.

[Ludovic Courtès]

Hi,

zimoun  skribis:

> My comment was about an unrelated thing.

I don’t take comments about unrelated things.  ;-)

> Well, I do not use every day G-exp nor ’plain-file’ and the like.  The
> interface appears to me unexpected each time I use it but hey I can
> live with it. :-) However, the documentation (or docstring) does not
> appear clear, each time I have my «aaah right!» moment.

[...]

> it is hard to guess beforehand that ’plain-file’ and ’mixed-text-file’
> do not return the same type of file-like object.

As someone who writes gexps and manipulates “file-like objects”, it
doesn’t matter whether a thing lowers to a derivation or to a plain
store item.  What matters is that you can insert it in a gexp and it’ll
do the right thing.  That’s why the docstrings don’t insist on that
difference.

Hope it makes sense!

Ludo’.