Re: Welcome to Simon as a new committer

[zimoun]

Hi all,

Thanks for the grant. :-)

Well, I know the “frustration” to have patches waiting… Somehow, I will
try to do my best.  As member of the teams Julia, Core and Mentors, I
would like to apply:

One last thing: the project keeps moving forward because committers
not only push their own awesome changes, but also offer some of
their time reviewing and pushing other people’s changes. As a
committer, you’re welcome to use your expertise and commit rights to
help other contributors, too!

<https://guix.gnu.org/manual/devel/en/guix.html#Commit-Access>

And I hope to be able in helping Ricardo and Lars with the teams R and
Haskell.

The fingerprint of my key is:

705A 29B7 01EE 410E B6F9 236E 92F1 D22C 608E E7E5

and available on some keyservers [1].

1: 
<https://keys.openpgp.org/vks/v1/by-fingerprint/705A29B701EE410EB6F9236E92F1D22C608EE7E5>



For sure, I am committed to:

Commit access should not be thought of as a “badge of honor” but
rather as a responsibility a contributor is willing to take to help
the project.

<https://guix.gnu.org/manual/devel/en/guix.html#Commit-Access>

As a reminder, note that many tasks do not require commit access and
they also help the project: ;-)

+ Bug triage
+ Reviewing patches
+ Translation
+ Writing blog post
+ Co-organization of events (online or IRL)
+ etc.

Thanks,
simon
--
https://simon.tournier.info/



zimoun-key.pub
Description: zimoun-key.pub


signature.asc
Description: PGP signature

Re: Merging branch wip-haskell

[zimoun]

Hi Lars,

On Wed, 15 Feb 2023 at 10:01, Lars-Dominik Braun  wrote:

> Is there anything preventing a merge into currently? Can we coordinate
> the merge with some other big world-rebuilding changes waiting to happen
> (apart from core-updates)?

As discussed in #61420 [1], from my small experiments most of the
substitutes are there and after checking about CI status, all seems
green except ganeti and python-pypandoc.

Not all susbtitutes are available after rebasing wip-haskell on the top
of current master (4501a50bbd), but somehow this situation appears to me
unavoidable, sadly.

Well, maybe we could try to build ganeti and python-pypandoc with an
older GHC than 9.2 since Guix provides several GHC version.  Somehow
apply an transformation similar to ’package-with-explicit-python’ for
GHC.  Or I propose to hide them waiting a proper fix.

Feel free to merge. :-)

Cheers,
simon

1: 

Time for RFC? (was Re: Moving forward with teams and feature branches (was: Discussion notes on releases and branches))

[zimoun]

Hi,

On Sun, 12 Feb 2023 at 22:13, Josselin Poiret  wrote:

> 1. Document this workflow in the manual, in a dedicated node, with a
>rationale as well.  One thing worth mentioning would be how to handle
>grafting/ungrafting now.  Also remove the staging/core-updates
>criterion.

Maybe it is also time for “RFC” as discussed earlier.  It would fit this
item #1.

Time for a request-for-comments process?
id:87cznqb1sl@inria.fr
Wed, 27 Oct 2021 23:22:50 +0200
https://yhetil.org/guix/87cznqb1sl@inria.fr

Some examples of other projects.

https://github.com/NixOS/rfcs
https://peps.python.org/pep-/
https://github.com/rust-lang/rfcs

Cheers,
simon

Re: avoid Computing Guix derivation when not necessary

[zimoun]

Hi,

On Sun, 12 Feb 2023 at 01:10, Ludovic Courtès  wrote:

>> The principle is simple: get commit and directory info from the profile
>> manifest, compare commits, if commits for all channels are the same, do
>> not try to update the profile.

Indeed, some improvements could be done in that direction.  For
instance,

--8<---cut here---start->8---
$ guix describe
Generation 89   Jan 17 2023 15:20:08(current)
  guix 29efa27
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 29efa2791dafb042ca8ace77bcf8538fb404d492

$ guix pull --commit=29efa27
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   29efa27
Computing Guix derivation for 'x86_64-linux'... |
[...]
--8<---cut here---end--->8---

Going from one commit to the exact same commit should not trigger some
intensive «Computing Guix derivation».

Note that if I run “guix pull --commit=29efa27” two times in row, the
second one it displays: «nothing to be done» after «Computing Guix
derivation».

Last, note that:

/var/guix/profiles/per-user/simon/current-guix -> current-guix-90-link

and

--8<---cut here---start->8---
$ /var/guix/profiles/per-user/simon/current-guix-90-link/bin/guix describe
  guix 29efa27
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 29efa2791dafb042ca8ace77bcf8538fb404d492

$ /var/guix/profiles/per-user/simon/current-guix-89-link/bin/guix describe
  guix 29efa27
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 29efa2791dafb042ca8ace77bcf8538fb404d492

$ readlink -f /var/guix/profiles/per-user/simon/current-guix-90-link
/gnu/store/g32zjrbr40fzp1rj5i6gx7hal20myfyv-profile

$ readlink -f /var/guix/profiles/per-user/simon/current-guix-89-link
/gnu/store/pk1i1dsagdby5pqydmvfbffg0i80wwvy-profile

$ diff -r --no-dereference \
  /gnu/store/g32zjrbr40fzp1rj5i6gx7hal20myfyv-profile/manifest \
  /gnu/store/pk1i1dsagdby5pqydmvfbffg0i80wwvy-profile/manifest
12c12
<   "/gnu/store/96bibk75vy5yvmilnycd8pl0l2bydcww-guix-29efa2791"
---
>   "/gnu/store/ldp0snjsac6hp1fikk5b8413pihm77di-guix-29efa2791"
20c20
< (branch #f)
---
> (branch "master")
--8<---cut here---end--->8---

Hum, maybe I have something twisted somewhere in my configuration.  From
my understanding, it comes from (guix scripts pull):

--8<---cut here---start->8---
(match (find guix-channel? channels)
  ((? channel? guix)
   ;; Apply '--url', '--commit', and '--branch' to the 'guix' channel.
   (let ((url (or url (channel-url guix
 (cons (match ref
 (('commit . commit)
  (channel (inherit guix)
   (url url) (commit commit) (branch #f)))
--8<---cut here---end--->8---

where ’branch’ should not be #f but instead inherit from ’guix’.  I
remember discussing this but I do not find where. :-)


> One marginal improvement would be sharing the cache that ‘time-machine’
> uses with ‘guix pull’.  Last I looked it wasn’t as easy as one might
> hope, but I forgot the details.

It could be nice! :-)  Last time I gave a look, I had an headache. ;-)

Cheers,
simon

Re: Merging core-updates?

[zimoun]

Hi,

On Sun, 12 Feb 2023 at 10:05, Julien Lepiller  wrote:

> As discussed at Guix Days before Fosdem, we haven't merged core-updates
> in a very long time. I'd volunteer to lead this effort, but I don't
> know what steps I should follow. Do we have some documentation about
> that?

Maybe a start could be to fix: 

Well, it could be helpful is Berlin or Bordeaux could build some
manifest of core-updates (not necessary the whole core-updates).  And
then, once the manifest builds, we could add some packages and repeat.

It would avoid that we all build the same things; worse, that each of us
burn many CPU just for knowing it fails.

Chris, Mathieu?  What do you think?


Cheers,
simon

Re: guix build -S  --with-branch

[zimoun]

Hi,

On Thu, 09 Feb 2023 at 18:07, "jgart"  wrote:

> Just opening this thread for us to brainstorm how we can improve the
> symbiosis between guix build -S and --with-branch.

Well, indeed this bug could be fixed,

--8<---cut here---start->8---
$ guix build eless --with-branch=eless=tests -S
updating checkout of 'https://github.com/kaushalmodi/eless'...
retrieved commit fb9584e319152c38dfb64ab16d596eed7b00133f
Backtrace:
  13 (primitive-load "/home/simon/.config/guix/current/bin/guix")
In guix/ui.scm:
   2276:7 12 (run-guix . _)
  2239:10 11 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 10 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/status.scm:
815:4  9 (call-with-status-report _ _)
In ice-9/boot-9.scm:
  1752:10  8 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/store.scm:
   661:37  7 (thunk)
   1300:8  6 (call-with-build-handler _ _)
   1300:8  5 (call-with-build-handler # …)
In guix/scripts/build.scm:
   807:26  4 (_)
In srfi/srfi-1.scm:
634:9  3 (for-each # 
("/gnu/store/0yd0l61i817qd31rklimqsz5gs…"))
In guix/ui.scm:
907:2  2 (show-derivation-outputs _)
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:
Throw to key `match-error' with args `("match" "no matching pattern" 
"/gnu/store/0yd0l61i817qd31rklimqsz5gsc7afcb-eless-fb9584e")'.
--8<---cut here---end--->8---

and instead return the expected Git checkout.

However, note that the store item returned by “guix build -S” is not a
Git repository, IIUC.


Cheers,
simon

Re: Getting tree-sitter grammars in Guix

[zimoun]

Hi Pierre,

On Mon, 06 Feb 2023 at 21:01, Pierre Langlois  wrote:

> https://issues.guix.gnu.org/49946#215

Oh cool, this tree-sitter-build-system looks great!  Thanks.

Sorry, I have overlooked this patch (and the Tree-sitter story :-)).

Cheers,
simon

Re: Translation files .gmo and packaging

[zimoun]

Hi Ludo,

On Mon, 30 Jan 2023 at 22:59, Ludovic Courtès  wrote:

> In the case of ice-wm, it would seem that there’s the extra difficulty
> that source is scattered in different places (where are the .po files?),
> so perhaps that’s a case where you may want to use the tarball, possibly
> discussing with upstream to see if we can do better.

Well, v3 [1] is an attempt.

1: 


Cheers,
simon

Re: valgrind

[zimoun]

Hi,

On Wed, 25 Jan 2023 at 12:01, Andreas Enge  wrote:

> (define-public valgrind
>   (package
> (name "valgrind")
> (version "3.17.0")
> (properties '((hidden? . #t)
>
> (define-public valgrind/interactive
>   (package/inherit
>valgrind
>(version "3.17.0")
>
> (define-public valgrind-3.20
>   (package
> (inherit valgrind/interactive)
> (version "3.20.0")

> Is version 3.17 really needed? Is the distinction between the hidden package
> and the "interactive" package still important?

--8<---cut here---start->8---
$ guix refresh -l -e '(@ (gnu packages valgrind) valgrind)'
Building the following 544 packages would ensure 1085 dependent packages are 
rebuilt:
--8<---cut here---end--->8---

I guess, the symbol ’valgrind’ refers to a minimal version of Valgrind
used by many packages.  Well, I guess again that ’valgrind-minimal’
could be a better name. :-)

Both ’valgrind/interactive’ and ’valgrind-3.20’ provides what user
expects with Valgrind but at 2 different versions.

Is the package ’valgrind/interactive’ accessible with valgrind@3.17
needed?  Indeed, maybe it could be dropped, especially if it is broken
for some use-case.


Cheers,
simon

Re: Struggling to write Dissecting Guix, Part 2

[zimoun]

Hi,

On Wed, 25 Jan 2023 at 07:12, "("  wrote:

> I've been struggling to write Part 2 of Dissecting Guix; I'm just not sure 
> where to start to
> explain monads.

Here my attempt to explain monads using Guile:

1:https://simon.tournier.info/posts/2021-02-03-monad.html

My aim was to provide the “intuition” of the concept.  Therefore, I have
tried to explain the monad concept using as simple as possible other
concepts and in the same time I tried to avoid the “monad fallacy” [2].
(summarized by «Monads are Like Burritos» ;-)))


> It's hard for a variety of reasons, those being that:
>
>   - Guile has no type system, so you can't express monads in terms of types

I do not think the concept of monad is related to the type system but
instead it appears to me related to the composition.


>   - Guix doesn't implement very many monads (only state, identity, and 
> store), so it's
> difficult to explain with a simpler monad, as there are no simpler monads

In [1], I am using the simple monads: list and maybe.

Their implementation is poor but they bring the concept to the table.
Well, I planned to use this introduction of the concepts to then write
another post about the state monad – which is the only we are really
interested in. ;-)


>   - Guix doesn't have functors or monoids either, so it's hard to 
> "progressively" explain
> first functors, then monoids, then monads

I think monad can be introduced using the well-known ’map’ which uses
functor without digging in too much details.


>  - Monads are just difficult in general :P

Well, from my point of view, it is hard because the concept appears
difficult at first then after the oohh moment it becomes hard to explain
without using the concept itself.  IMHO, it is well summarized in this
post:

2: 
https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/

Cheers,
simon

Re: My first package

[zimoun]

Hi Tobias,

Sorry for this late reply.

On Thu, 15 Sep 2022 at 09:35, Tobias Platen  wrote:

> I've created my first package for guix, the sekai speech synthesis
> toolkit which I use mainly for producing singing voice with lilypond.
> I'll also plan a talk at the gnu hackers meeting how I make Desktop
> Music using the Guix System. Two more packages will follow next.

Cool!  Thank you for your contribution.

For easing the merge, could you send to guix-patc...@gnu.org this patch
using git-format-patch with a commit message.  Well, please give a look
at the section « Submitting Patches » [1] from the manual. :-)


1: 


Two minor comment starting the review. :-)

>#:use-module (gnu packages textutils))
>  
> +

Here, you introduced an extra line.

> +(define-public sekai
> +  (package
> +(name "sekai")
> +(version "0.6.0")
> +(source (origin
> +  (method git-fetch)
> +  (uri (git-reference
> +(url "https://notabug.org/isengaara/sekai;)
> +(commit "0.6rc0")))
> +  (sha256
> +   (base32
> +"0j55pipx3hcp0xl4v0d72fdwysnz9a9a40x65a9lxpl4k6wyp4nm"   
>
> +(build-system cmake-build-system)
> +(arguments '(#:tests? #f))

The tests are disallowed.  Any specific reason?  If yes, the usual
practise is to add a one line comment.  For example,

   (arguments '(#:tests? #f)); no tests


> +(inputs `(("fftw" ,fftw)
> +  ("libsndfile",libsndfile)
> +   ("pkg-config",pkg-config)
> +   ("gsl",gsl)
> +   ("jsoncpp",jsoncpp)
> +   ("boost",boost)
> +   ("jack" ,jack-1)
> + ))

Now, you can use directly,

(inputs (list fftw
  libsndfile
  pkg-config
  gsl
  jsoncpp
  boost
  jack-1))

Cheers,
simon

Re: Org 9.6: void org-element--cache-active-p on fresh

[zimoun]

Hi,

On Mon, 16 Jan 2023 at 20:43, zimoun  wrote:

>> --8<---cut here---start->8---
>> org-get-buffer-tags: Symbol's function definition is void: 
>> org-element--cache-active-p
>> --8<---cut here---end--->8---

>> Well, is it a bug on Guix side or is it a bug on Org-mode side?  Or from
>> my config?

Fixed upstream by 5d9c9c27c68f1af1159dfeb62352b2fa610b1d9f [1].

1: https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5d9c9c27c


Cheers,
simon

Re: FOSDEM’s coming!

[zimoun]

Hi,

I am late to the party.

On Thu, 19 Jan 2023 at 16:58, Ludovic Courtès  wrote:
> Hello Guix!
>
> I’ve prepared a blog post about FOSDEM and the Guix Days that we could
> publish tomorrow (Friday) or Monday:

Thanks for maintaining the communication up. :-)

>   
> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/meet-guix-at-fosdem-2023.md

LGTM.  Except the Guix Days dates:

*Thursday Feb. 2nd and Friday Feb. 3rd**

> Please take a look and send patches if needed!  If someone can come up
> with some kind of a logo for the Guix Days, that’d be great; otherwise
> we’ll just reuse the one from last year.

A quick comment about:

Believe it or not, it’s the [9th year Guix is represented at
FOSDEM](https://guix.gnu.org/en/blog/tags/fosdem/)!  There are
several talks that will let you learn more about different areas
of the joyful Hydra Guix has become.

When submitting a proposal for a stand (that had been refused :-(), I
collected all the presentations – if I have not missed some; let me
know.

In this FOSDEM 2023 session, we have 10 talks about Guix, compared to
the 31 ones counted over the past years.  Is Guix becoming trendy?  ;-)

2014 [1]
2015 [2]
2016 [3-6]
2017 [7-14]
2018 [15]
2019 [16-19]
2020 [20-25]
2021 [26-29]
2022 [30-31]

1: https://archive.fosdem.org/2014/schedule/event/gnuguix/
2: https://archive.fosdem.org/2015/schedule/event/the_emacs_of_distros/
3: https://archive.fosdem.org/2016/schedule/event/guixhurd/
4: https://archive.fosdem.org/2016/schedule/event/guix/
5: https://archive.fosdem.org/2016/schedule/event/guixdistro/
6: https://archive.fosdem.org/2016/schedule/event/guixmodules/
7: https://archive.fosdem.org/2017/schedule/event/hpc_deployment_guix/
8: 
https://archive.fosdem.org/2017/schedule/event/composingsystemservicesinguixsd/
9: https://archive.fosdem.org/2017/schedule/event/futureofguix/
10: https://archive.fosdem.org/2017/schedule/event/guixintroduction/
11: https://archive.fosdem.org/2017/schedule/event/guixpackages/
12: https://archive.fosdem.org/2017/schedule/event/guixhurd/
13: https://archive.fosdem.org/2017/schedule/event/guixworkflowmanagement/
14: https://archive.fosdem.org/2017/schedule/event/guixsdbootstrap/
15: https://archive.fosdem.org/2018/schedule/event/guix_workflows/
16: 
https://archive.fosdem.org/2019/schedule/event/gnu_guix_new_approach_to_software_distribution/
17: https://archive.fosdem.org/2019/schedule/event/guixinfra/
18: https://archive.fosdem.org/2019/schedule/event/gnuguixminimalism/
19: https://archive.fosdem.org/2019/schedule/event/gnumes/
20: https://archive.fosdem.org/2020/schedule/event/guix/
21: https://archive.fosdem.org/2020/schedule/event/reprod_jupyter_guix/
22: https://archive.fosdem.org/2020/schedule/event/ggaaattyp/
23: https://archive.fosdem.org/2020/schedule/event/gnumes/
24: https://archive.fosdem.org/2020/schedule/event/gexpressionsguile/
25: https://archive.fosdem.org/2020/schedule/event/gnuguixpackagemanager/
26: https://archive.fosdem.org/2021/schedule/event/gnumes/
27: https://archive.fosdem.org/2021/schedule/event/declarativeminimalistic/
28: https://archive.fosdem.org/2021/schedule/event/gnuguix/
29: https://archive.fosdem.org/2021/schedule/event/minimalismguix/
30: https://archive.fosdem.org/2022/schedule/event/guixdeclare/
31: https://archive.fosdem.org/2022/schedule/event/gnuguixci/


Cheers,
simon

Re: Packages grow, no longer fit on a 

[zimoun]

Hi,

On Tue, 17 Jan 2023 at 17:25, Ludovic Courtès  wrote:

> Examples include libgccjit in Emacs and mozjs in polkit.

Do I miss a point?  How is it possible to have native compilation for
Emacs without libgccjit?

For emacs-minimal, if considered to only bytecompile (.elc) and not
native compile, this libgccgit seems unexpected, indeed.  Well, is
native compilation disabled for emacs-minimal?  I guess not. :-)


> Still, even compared to contemporary distros, we’re doing pretty bad.
> Debian most likely does better, and people often cite Alpine as the
> distro providing the smallest packages.  Do we have figures?  What can
> we learn from them?  What tradeoffs to they make?

I agree we need to improve.  However, I would like to mitigate. :-)

Functional and closure makes apparent what is hard to evaluate on
“contemporary distros”.  I would be curious to know the transitive
closure of the testing Debian meta-package named ’emacs’ (28.2) [1],
which is roughly the equivalent of the Guix package ’emacs’.

Because if you dig a bit [2], for instance it depends on ’libgccjit0’.

If you consider Alpine Linux and give a look at the dependency of the
equivalent [3] of the Guix package ’emacs’, it depends on ’libgccjit’.

These “contemporary distros” rely on version resolver which somehow
hides the costs; when these costs are clearly popping with Guix.

For sure, we need to improve because Docker pack produced by Guix are
really more fat compared to the ones available around and usually
produced with distros as Alpine.

1: 
2: 
3: 


Cheers,
simon

Re: Packages grow, no longer fit on a 

[zimoun]

On Wed, 18 Jan 2023 at 00:05, zimoun  wrote:

> For emacs-minimal, if considered to only bytecompile (.elc) and not
> native compile, this libgccgit seems unexpected, indeed.  Well, is
> native compilation disabled for emacs-minimal?  I guess not. :-)

The package emacs-minimal is only for bytecompiling and configured
without native compilation, IIUC.  Thus the reference to libgccgit
appears unexpected, then tackled by Josselin and fixed by Liliana in
#60831 [1].

Cool! :-)

1: 
<http://issues.guix.gnu.org/msgid/f8e96b5d959815f77501beadeaca9139b3fb2d11.ca...@gmail.com>


Cheers,
simon

Re: Command consistency: suggestion

[zimoun]

Hi Paul,

On Mon, 16 Jan 2023 at 18:59, Paul Jewell via "Development of GNU Guix and the 
GNU System distribution."  wrote:

> guix system --switch-generation ... --delete-generation ...
>
> but I am reading into your comment that guix system does _not_ use 
> SRFI-37, and therefore cannot combine actions. In other words, it would 
> take more effort to implement this change?

Yes, it would be possible to replace “guix system ” by “guix
system --”.  However, it will not be happen.

The CLI “guix system” and “guix package” will not change.  Although they
can be considered as inconsistent.

The cost of such change is too high.  Because it means update all the
documentation around and let the time for people to upgrade their
scripts, etc.

For example, consider discussion in #38529 [1] and give a look to the
lengthy thread [2].  The discussion was about a change for the CLI of
“guix environment”.  It ended with a new command line “guix shell” and a
deprecation and removal plan over several years for “guix environment”.

As I am trying to explain, the only viable solution is to implement a
Guix extension with another CLI.  The current one will not change, IMHO.

1: 

2: 



> I suppose for those of you who have been in guix for several years, this 
> is no issue, since you are familiar with all the different options. to 
> me, as a relative newcomer, it didn't feel so smooth. If nothing changes 
> I shall not be resorting to aliases, but simply making sure I know the 
> correct syntax to achieve what I want!

Thanks for the feedback.  I agree that the split of “guix package/pull”
on one hand and “guix system/home/import” on the other hand can be
confusing at first.  Well, Guix is more than 10 years now and it is some
historical choices. :-)


Cheers,
simon

Exception: srfi-35 vs (ice-9 exceptions (was Re: [bug#60802] [PATCH v2 1/2] platforms: Raise an exception when no suitable platform is found.)

[zimoun]

Hi Maxim,

On Mon, 16 Jan 2023 at 12:46, Maxim Cournoyer  wrote:

>> So far the we use (srfi srfi-35) exclusively to define condition types;
>> I think we should do the same here, for consistency.
>
> Could we instead start migrating away from srfi-35 to (ice-9
> exceptions), which is the new native way to use exceptions in Guile?  

Well, I think this should be discussed separately.  Therefore,
-60...@debbugs.gnu.org and +guix-devel. :-)


>   I
> think it'd be nicer to use it in the future, to avoid newcomers being
> confusing about the 3 or 4 ways to manage exceptions in Guile
> (recommended read on the topic:
> https://vijaymarupudi.com/blog/2022-02-13-error-handling-in-guile.html).

In Guile maybe several but only one in Guix: (srfi srfi-35). :-)


> Migrating the whole code at once doesn't seem a good idea, so gradually
> transitioning (such as using (ice-9 exceptions) for new code) appears a
> good idea to me, if we agree on the direction!

Just to note that all Guix is using (srfi srfi-35); except,

--8<---cut here---start->8---
1 candidates:
./guix/build/minetest-build-system.scm:26:  #:use-module (ice-9 exceptions)
--8<---cut here---end--->8---

Therefore, this plan needs to be a bit cooked, otherwise it will become
quickly a big mess with 2 ways for managing exceptions – and people, at
least me, will be confused to pick the correct one depending on the
module.

Well, if such migration makes sense (I do not know?), from my point of
view, the migration of the whole code in a short period of time appears
to me the best; probably with a dedicated WIP branch.

Cheers,
simon

Org 9.6: void org-element--cache-active-p on fresh

[zimoun]

Hi,

I do not know if the issue is on Guix side or Org-mode side; or maybe on
my side, hence this email. :-)

Here a reproducer:

--8<---cut here---start->8---
$ cat config.el

(setq
 org-directory "/tmp/"
 org-agenda-files '("example.org")
 org-element-cache-persistent nil)

$ cat example.org

* DONE Yesterday
CLOSED: [2023-01-15 Sun 15:45]

* DONE Today
CLOSED: [2023-01-16 Mon 15:45]
--8<---cut here---end--->8---

(Well, modify the date of “Today“ to be your today’s date.)

Then,

$ guix shell -C emacs-minimal emacs-org -E TERM \
   -- emacs -q -l config.el -f org-agenda

Select: m Match a TAGS/PROP/TODO query

--8<---cut here---start->8---
org-get-buffer-tags: Symbol's function definition is void: 
org-element--cache-active-p
--8<---cut here---end--->8---

Note that it does not happen with Org 9.5.5 included in Emacs; i.e.,

$ guix shell -C emacs-minimal -E TERM \
   -- emacs -q -l config.el -f org-agenda


Now consider:

$ guix shell -C emacs-minimal emacs-org -E TERM \
   -- emacs -q -l config.el \
   --eval "(require 'org-element)"  \
   -f org-agenda

Then press ’m’ and type: CLOSED>="".  The result is:

--8<---cut here---start->8---
Headlines with TAGS match: CLOSED>=""
Press `C-u r' to search again
  example:DONE Yesterday
  example:DONE Today
--8<---cut here---end--->8---

The expected result (at least using Org v9.5) is to only match with the
item “Today” – the item “Yesterday” should be filtered out; e.g.,

Headlines with TAGS match: CLOSED>=""
Press `C-u r' to search again
  example:DONE Today

Well, is it a bug on Guix side or is it a bug on Org-mode side?  Or from
my config?


Cheers,
simon

Re: [PATCH guix-artwork v4] website: posts: Add Dissecting Guix, Part 1: Derivations.

[zimoun]

Hi,

On Tue, 10 Jan 2023 at 06:59, "("  wrote:

> Probably, yeah.  It might take me longer to write the monads post, since i 
> didn't
> understand Guix's monads when I started :) (I do understand them a bit now, 
> though.)

Feel free to post to guix-b...@gnu.org even an early draft if you want
some early feedback.  Well, if this private alias is still working. :-)

(Hum, I do not remember who is behind in addition to me. ;-)))

Cheers,
simon

Be careful with PyPI

[zimoun]

Hi,

If the origin does not exist upstream, then Guix try other servers as
fallback.  For instance,

--8<---cut here---start->8---
Starting download of 
/gnu/store/lb0kb4c212f9f789ixd1c18bcm8qbsqi-Keras-2.11.0.tar.gz
>From 
>https://files.pythonhosted.org/packages/source/K/Keras/Keras-2.11.0.tar.gz...
download failed 
"https://files.pythonhosted.org/packages/source/K/Keras/Keras-2.11.0.tar.gz; 
404 "Not Found"

Starting download of 
/gnu/store/lb0kb4c212f9f789ixd1c18bcm8qbsqi-Keras-2.11.0.tar.gz
>From 
>https://ci.guix.gnu.org/file/Keras-2.11.0.tar.gz/sha256/1j8bsqzh49vjdxy6l1k4iwax5vpjzniynyd041xjavdzvfii1dlh...
download failed 
"https://ci.guix.gnu.org/file/Keras-2.11.0.tar.gz/sha256/1j8bsqzh49vjdxy6l1k4iwax5vpjzniynyd041xjavdzvfii1dlh;
 404 "Not Found"

Starting download of 
/gnu/store/lb0kb4c212f9f789ixd1c18bcm8qbsqi-Keras-2.11.0.tar.gz
>From 
>https://tarballs.nixos.org/sha256/1j8bsqzh49vjdxy6l1k4iwax5vpjzniynyd041xjavdzvfii1dlh...
following redirection to 
`https://tarballs.nixos.org/sha512/0d57cb8e0af234a619ba3dec245c2ab73cbd0566194ed6b59377231183b2ef916514ba87abe04ec7e518770c9e0cb157747db87cedf0ebeced4ae0f56be401c3'...
downloading from 
https://tarballs.nixos.org/sha256/1j8bsqzh49vjdxy6l1k4iwax5vpjzniynyd041xjavdzvfii1dlh
 ...
 1j8bsqzh49vjdxy6l1k4iwax5vpjzniynyd041xjavdzvfii1dlh  748KiB   
  67.1MiB/s 00:00 [##] 100.0%
successfully built 
/gnu/store/75g4aq5b25g4j1qwd3ggl1sys24q63la-Keras-2.11.0.tar.gz.drv
--8<---cut here---end--->8---

One potential issue is that the tarballs.nixos.org is using the checksum
as lookup key.  Therefore, when modifying only the version and not the
checksum, the something is returned with an inconsistent name/content.

First, let get the source of the current Keras (v2.2.4).

--8<---cut here---start->8---
$ ./pre-inst-env guix build python-keras -S
0.5 MB will be downloaded:
  /gnu/store/k2wxrqzmr29rjy1w5b0nhd4k36sv8szb-Keras-2.2.4.tar.xz
substituting /gnu/store/k2wxrqzmr29rjy1w5b0nhd4k36sv8szb-Keras-2.2.4.tar.xz...
downloading from 
https://ci.guix.gnu.org/nar/k2wxrqzmr29rjy1w5b0nhd4k36sv8szb-Keras-2.2.4.tar.xz 
...
 Keras-2.2.4.tar.xz  521KiB 
   3.6MiB/s 00:00 [##] 100.0%

/gnu/store/k2wxrqzmr29rjy1w5b0nhd4k36sv8szb-Keras-2.2.4.tar.xz
--8<---cut here---end--->8---

Then, tweak only the version (update to 2.11.0) and get the source.

--8<---cut here---start->8---
$ git diff
diff --git a/gnu/packages/machine-learning.scm 
b/gnu/packages/machine-learning.scm
index 75cc100851..2cbe0eddd6 100644
--- a/gnu/packages/machine-learning.scm
+++ b/gnu/packages/machine-learning.scm
@@ -2831,7 +2831,7 @@ (define-public python-keras-preprocessing
 (define-public python-keras
   (package
 (name "python-keras")
-(version "2.2.4")
+(version "2.11.0")
 (source
  (origin
(method url-fetch)
$ ./pre-inst-env guix build python-keras -S
;;; note: source file 
/home/simon/src/guix/guix/gnu/packages/machine-learning.scm
;;;   newer than compiled 
/home/simon/src/guix/guix/gnu/packages/machine-learning.go
;;; note: source file 
/home/simon/src/guix/guix/gnu/packages/machine-learning.scm
;;;   newer than compiled 
/home/simon/src/guix/guix/gnu/packages/machine-learning.go
;;; note: source file 
/home/simon/src/guix/guix/gnu/packages/machine-learning.scm
;;;   newer than compiled 
/home/simon/.config/guix/profiles/emacs/emacs/lib/guile/3.0/site-ccache/gnu/packages/machine-learning.go
;;; note: source file 
/home/simon/src/guix/guix/gnu/packages/machine-learning.scm
;;;   newer than compiled 
/home/simon/.config/guix/profiles/emacs/emacs/lib/guile/3.0/site-ccache/gnu/packages/machine-learning.go
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
The following derivations will be built:
  /gnu/store/by6pgdambmv4wrg2h40l287d7zhbwc17-Keras-2.11.0.tar.xz.drv
  /gnu/store/75g4aq5b25g4j1qwd3ggl1sys24q63la-Keras-2.11.0.tar.gz.drv
building /gnu/store/75g4aq5b25g4j1qwd3ggl1sys24q63la-Keras-2.11.0.tar.gz.drv...

Starting download of 
/gnu/store/lb0kb4c212f9f789ixd1c18bcm8qbsqi-Keras-2.11.0.tar.gz
>From 
>https://files.pythonhosted.org/packages/source/K/Keras/Keras-2.11.0.tar.gz...
download failed 
"https://files.pythonhosted.org/packages/source/K/Keras/Keras-2.11.0.tar.gz; 
404 "Not Found"

Starting download of 
/gnu/store/lb0kb4c212f9f789ixd1c18bcm8qbsqi-Keras-2.11.0.tar.gz
>From 
>https://ci.guix.gnu.org/file/Keras-2.11.0.tar.gz/sha256/1j8bsqzh49vjdxy6l1k4iwax5vpjzniynyd041xjavdzvfii1dlh...
download failed 
"https://ci.guix.gnu.org/file/Keras-2.11.0.tar.gz/sha256/1j8bsqzh49vjdxy6l1k4iwax5vpjzniynyd041xjavdzvfii1dlh;
 404 

Re: Search in One Channel

[zimoun]

Hi,

On Wed, 28 Dec 2022 at 23:45, "jgart"  wrote:

> I'd like to search just in the guix-emacs channel with `guix search`. 

Currently, the only option I am aware is to parse the output (with
recutils or other).

Well, it is not convenient but something like:

guix time-machine -C one-specific-channel.scm -- search foo-bar

should work.  Not convenient because «Compute derivation» and because
you need to extract the correct information for the file
one-specific-channel.scm.

My question is: what is your use case?  Why is “guix search” on all
the channels not fitting your needs?

Well, “guix search” should use ’location’ which is a good indication for
package channel provenance, although it is not a strong guarantee.

Well, it is not straightforward to use ’module-name’ as search term.
Because how to map the string search terms with this module name.  And
because it could lead to some performance penalty.

Cheers,
simon

Re: Builds of https://guix.gnu.org/{packages,sources}.json

[zimoun]

Hi,

On Wed, 04 Jan 2023 at 23:30, Ludovic Courtès  wrote:

> Thus I moved the former (apps packages builder) module of the web site
> to a script in maintenance.git, and had it run as a periodic mcron job
> populating /srv/package-metadata, with nginx serving these two files
> from that directory:
>
>   5664984 * hydra: web: Add mcron job to build /packages.json and 
> /sources.json.
>   318db3e * hydra: Add 'build-package-metadata.scm' script.

Cool!  Thank you.

I still have a WIP about turning this into manifest and then build
sources.json via CI (Cuirass).  Well, I do not know if it would be
useful or better compared to this new Guix REPL script.


Cheers,
simon

Re: Stratification of GNU Guix into Independent Channels

[zimoun]

Hi,

On Sat, 24 Dec 2022 at 03:49, "jgart"  wrote:

> Users could then decide what channels they'd like to subscribe to/opt
> in to by adding any of the following channels as they please: 
>
> python-channel
> rust-channel
[...]
> etc...
>
> The above channels would still be maintained under the auspices of
> GNU. 
>
> What do you think would be the pros and cons of the stratified
> approach versus the monorepo approach that we currently have?

The Big cons is about maintenance.

It is possible to have a look at the complete current state [1] but it
would be hard, if not impossible, when using many many many channels.
When using other channels [2], time to time it breaks.  Somehow, you
have a combinatorial problem.

Consider that some Git tools are part of one channel and for instance
Julia packages are part of another channel.  The update of Git from its
channel could have an impact on the packages defined in some other
channels; for concrete case: Git update from 2.38.0 to 2.38.1 breaks
julia-documenter [3].  Using few channels, it makes doable to tackle
such issues (guix refresh, guix graph, etc.).  Using many many channels,
it makes it hard to detect; although CI and QA are improving a lot and
for sure they can help, the situation is not good enough yet, IMHO.

Moreover, many channels would be dependant from one to the other.  Give
a look at (gnu packages python-xyz).  If the packages defined here would
become the channel ’python-channel’ then this ’python-channel’ would
depend on many others – this (gnu packages python-xyz) module requires
103 other (gnu packages …) modules.

Concretely, the split would be a painful, boring and tedious work where
I am doubtful about the practical outcome.

>From my point of view, solutions for improving the situation of “guix
pull” are:

 + more modular; maybe split *package-modules* in (guix self)
 
 + transform subcommands as extensions; here we would have a better
   control for the Guix feature dependencies via the Scheme API


1: 
2: 
3: 

Cheers,
simon

Re: guix package path

[zimoun]

Hi Ludo,

On Wed, 21 Dec 2022 at 23:42, Ludovic Courtès  wrote:

> We don’t have enough info to be sure, but could it be that there are two
> ‘gtklp’ packages in your package collection, for instance because
> ‘gtklp-bad-tool’ is also public?  ‘specification->package’ prints a
> warning if it’s ambiguous.

I do not think the issue is about your assumption.  I guess it is about
Guile modules and compilation.

The package gtklp-bad-tool is defined by:

--8<---cut here---start->8---
(define-public gtklp-bad-tool
  (package
(name "gtklp")
(version "1.3.4")
[...]
--8<---cut here---end--->8---

Then gtklp is defined by:

--8<---cut here---start->8---
(define-public gtklp
  (let ((toolchain (specification->package "clang-toolchain@10")))
(package-with-c-toolchain gtklp-bad-tool `(("toolchain" ,toolchain)
--8<---cut here---end--->8---

Here, the issue is ’(specification->package "clang-toolchain@10")’.  For
instance, you get:

$ guix show -L /tmp/my-guix sbcl-lispiec
guix show: error: sbcl-lispiec: package not found

where nothing is ambiguous; the package ’sbcl-lispiec’ is unrelated to
both gtklp-bad-tool or gtklp.

If you replace [1] ’specification->package’ by the symbol
clang-toolchain-10, then it just works.

Last, if you use the broken channel with ’specification->package’ but
instead of --load-path, you run “time-machine” or “pull”, then the issue
is gone.


https://gitlab.com/acpadoanjr/my-guix/-/blob/0e540b6fce0409330cb1ca3453d81f18c8e60163/my-packages/extra.scm#L71-115
https://gitlab.com/acpadoanjr/my-guix/-/blob/0e540b6fce0409330cb1ca3453d81f18c8e60163/my-packages/extra.scm#L313-315
1: 


Cheers,
simon

Re: File search

[zimoun]

Hi Ludo,

On Mon, 19 Dec 2022 at 22:25, Ludovic Courtès  wrote:

> I think at this point we could consider integration in Guix proper,
> under ‘guix/scripts’.  For that we could dismiss commit history.
>
> That’ll entail extra work (d’oh!) such as fine-tuning, writing tests,
> and writing a section for the manual.
>
> The other option, if you prefer, would be to keep it in a separate repo
> as an extension that people can install.  To me that would be more of a
> temporary solution because I think it’s a useful feature that ought to
> be provided by Guix proper eventually.

For what it is worth, I think it would better to reduce the number of
scripts and instead have something more modular with extensions.

The tradeoff about the maintenance cost is to not clear, I agree.

On the other hand, reducing the number of modules that “guix pull”
processes would help for improving the performance.  For instance, let
say that I am not interested by “guix system” and the computation of the
derivation at “guix pull” time is not nothing.  Another instance is all
the plumbing commands.

The manual would cover the extensions but it would be an opt-in choice by
the user to install them.  And it would reduce the load at “guix pull”
time.

My 2 cents. :-)

Cheers,
simon

Re: guix package path

[zimoun]

Hi,

On Mon, 19 Dec 2022 at 13:06, Antonio Carlos Padoan Junior 
 wrote:

> ~$ guix show -L /home/antonio/git/my-guix sbcl-lispiec
> guix show: error: sbcl-lispiec: package not found
>
> ~$ guix build -L /home/antonio/git/my-guix sbcl-lispiec
> guix build: error: sbcl-lispiec: unknown package

The issue is this snippet:

--8<---cut here---start->8---
(define-public gtklp
  (let ((toolchain (specification->package "clang-toolchain@10")))
(package-with-c-toolchain gtklp-bad-tool `(("toolchain" ,toolchain)
--8<---cut here---end--->8---

and to be precise, it seems ’specification->package’.  If it is removed,
and for example, adding #:use-module (gnu packages llvm) and

--8<---cut here---start->8---
(define-public gtklp
  (let ((toolchain clang-toolchain-10))
(package
  (inherit
   (package-with-c-toolchain gtklp-bad-tool `(("toolchain" ,toolchain
  (name "gtklp-with-clang"
--8<---cut here---end--->8---

Then all seems to work.  Therefore, the same should fix
GUIX_PACKAGE_PATH.

Well, I do not know why it does not work as expected.  Maybe an issue
with Guile modules and compilation.


Back to your original issue.  Using
26f397ee26c2da6961a2ef893270ea03986ee55e from master and the channels
file:

--8<---cut here---start->8---
$ cat channels.scm
(list (channel
(name 'guix)
(url "https://git.savannah.gnu.org/git/guix.git;)
(branch "master")
(commit
  "c8316c1e47ce2ace5474cbcda03555cf915b4fce"))
  (channel
   (name 'mine)
   (url "file:///tmp/my-guix")
   (branch "master")))

$ guix time-machine -C /tmp/channels.scm -- build sbcl-lispiec
/gnu/store/giwpdx5kcwfry3bx2yc90084nkmx7283-sbcl-lispiec-1.0.2
--8<---cut here---end--->8---

And note that,

--8<---cut here---start->8---
$ guix repl -q -L /tmp/my-guix
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> ,use(guix)
scheme@(guix-user)> ,use(my-packages extra)
scheme@(guix-user)> ,build sbcl-lispiec
$1 = "/gnu/store/giwpdx5kcwfry3bx2yc90084nkmx7283-sbcl-lispiec-1.0.2"
scheme@(guix-user)>
--8<---cut here---end--->8---


Cheers,
simon

Re: guix package path

[zimoun]

Hi,

On Mon, 19 Dec 2022 at 08:12, Antonio Carlos Padoan Junior 
 wrote:

> This channel is also available here
> https://gitlab.com/acpadoanjr/my-guix.git/
> But I want to use it from my local machine while I'm developing.
>
> Using the GUIX_PACKAGE_PATH, I have a local package (sbcl-lispiec) that seems
> correctly loaded:
>
> 
> ~$ guix search sbcl-lispiec

[...]

> location: /home/antonio/git/my-guix/my-packages/extra.scm:217:4

[...]

> 
>
> But I cannot build it or install it:
>
> 
> ~$ guix build sbcl-lispiec
> guix build: error: sbcl-lispiec: unknown package
> 

This package sbcl-lispiec is indeed not in:

https://gitlab.com/acpadoanjr/my-guix.git/

and there no line 217 inside the file:

https://gitlab.com/acpadoanjr/my-guix/-/blob/main/my-packages/extra.scm

Therefore, I guess something is twisted somewhere.

Could you try:

guix show -L /home/antonio/git/my-guix sbcl-lispiec
guix build -L /home/antonio/git/my-guix sbcl-lispiec


Cheers,
simon

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[zimoun]

Hi,

On Sun, 18 Dec 2022 at 01:54, Mekeor Melire  wrote:

> What do you think? Should this go into a separate, private 
> channel? Into the Guix Cookbook? Into Guix, if so, then probably 
> with lots of changes? Should it just stay here, in this mailing 
> list thread? Or do you think this is just a bad idea in general?

>From my point of view, you could convert to an extension, say “guix
emacs” and share this extension as a regular Guix packages.  This would
help to iterate and discuss various implementation details using
concrete and easy tests.

Cheers,
simon

Re: Release progress, week 10

[zimoun]

Hi,

On Sun, 18 Dec 2022 at 16:13, Ludovic Courtès  wrote:

> I wrote a couple of paragraphs about this and other things yesterday
> (tried to keep it relatively short).  Let me know if you think
> anything’s missing.

All appears to me good.  You do not mention that the coverage for
git-fetch is about ~98% and that Disarchive is very important because
the main source of origins is url-fetch, hence the total of 75%.

I would add at the end of the first paragraph something like:

--8<---cut here---start->8---
[...]
Software Heritage as a fallback, with version 1.4.0 **the source code of
Guix channels is automatically fetched from Software Heritage** if its
original URL has become unreachable.  As of the “[Preservation of Guix
Report](https://ngyro.com/pog-reports/latest/)” published in January
2022, more than 98% of the packages directly referring to Git
repositories are now fully archived in Software Heritage.
--8<---cut here---end--->8---


>> I still think that it would be worth to mention the removal of many
>> Python 2 packages and that the project stops to maintain Python 2
>> packages.  I know it appears in NEWS but it costs nothing to restate
>> because many people are not reading all the details of all. :-)
>
> Oh right, I’ll add a few lines.

LGTM.


Cheers,
simon

PS: A side note and it is too late. :-)  This:

  - [“Using TeX and
LaTeX”](https://guix.gnu.org/manual/en/html_node/Using-TeX-and-LaTeX.html)

appears to me a Cookbook section and not a Manual section.  Well, let
discuss that on January. :-)

Re: Release progress, week 10

[zimoun]

Hi Ludo,

On Thu, 15 Dec 2022 at 17:38, Ludovic Courtès  wrote:

> If everything goes well, I plan to publish the release on Monday, 19th.
> Time to get to your instrument for a release song or whatever other
> performance you feel like making!  :-)

It reminds me the announce on hpc.guix.info.  Well, I am not have the
time before Monday to collect the changes.  I can draft on Monday.

The draft of the announce for the Guix website LGTM.  I will try to
write a paragraph about «Supporting long-term reproducibility» (SWH
fallback for channels and Disarchive) on Monday morning.  If you want to
proceed before, go ahead. :-)

I still think that it would be worth to mention the removal of many
Python 2 packages and that the project stops to maintain Python 2
packages.  I know it appears in NEWS but it costs nothing to restate
because many people are not reading all the details of all. :-)


Cheers,
simon

Re: Packaging big generated data files?

[zimoun]

Hi,

On Wed, 07 Dec 2022 at 11:33, Denis 'GNUtoo' Carikli 
 wrote:

> The issue here is probably the size of the generated files: they are
> huge, so if they are packaged, they will most likely take significant
> resources in the Guix infrastructure.
>
> So what would be the way to go here? Would Guix accept patches to add
> packages for these files in Guix proper?  

>From my point of view, the data and the code should be packaged
separately; the package data using copy-build-system would be an input
for the package code.

> If so, does it needs to be done like with the ZFS (kernel module)
> package where "#:substitutable? #f" is used to avoid redistributing
> package builds? Or are other ways better for such use cases?

Yes, ’#:substitutable? #f’ seems the first way to go.


Cheers,
simon

Re: Some stats about the graph of dependencies

[zimoun]

Hi,

On Sat, 10 Dec 2022 at 00:19, jbra...@dismail.de wrote:

>> Although Python is great, I would like to run Guile. Any Guile library
>> for manipulating graph is around?
>
> https://packages.guix.gnu.org/packages/guile2.2-charting/0.2.0-1.75f755b/

By graph, I was meaning this kind of graph:

https://en.wikipedia.org/wiki/Graph_(discrete_mathematics)

and not this kind of graph:

https://en.wikipedia.org/wiki/Chart

Sorry for the confusing terminology. :-)


Cheers,
simon

Re: Drafting a Guix blog post on the FHS container

[zimoun]

Hi,

On Mon, 05 Dec 2022 at 02:32, John Kehayias  
wrote:

> Here is a current (rough!) draft. For the ease of plain text email
> I've exported from the org source to text with some light edits:

Nice!  If you can turn the draft into Markdown and format a patch for
guix-artwork [1] under website/drafts, it could be awesome! :-)

Then you could send the patch to guix-devel, guix-blog or guix-patches.

1: 


Cheers,
simon

Re: guile profiling / speeding up derivations on slow storage

[zimoun]

Hi,

On Thu, 01 Dec 2022 at 02:02, Csepp  wrote:

> First of all, I'm curious, how do other Guile developers profile code?

Well, recently Ludo posted a heap profiler for Guile

https://lists.gnu.org/archive/html/guile-user/2022-11/msg00012.html

> Could we add a profiling flag for the CLI similar to the existing
> debugging flags?

I agree that some utilities would be welcome.  And for instance, I am
unable to use ,profile or ’statprof’.

Well, maybe it could be interesting to collect various scenarios as
proposed in this thread [1].

1: https://yhetil.org/guix/87lenve3t2@gnu.org

Cheers,
simon

Re: File search

[zimoun]

Hi Antoine,

Cool!  I have not really look yet.  Just a minor answer to one of your
question. :-)

On Fri, 09 Dec 2022 at 11:05, "Antoine R. Dumont (@ardumont)" 
 wrote:
>> It should instead show “git@2.38.1:send-email”.  We probably need an
>> ‘output’ field in the ‘Packages’ table.
>
> Why must that be "git@2.38.1:send-email", what does it mean?

It is about outputs [1].  Some packages have more than one output.  For
instance,

--8<---cut here---start->8---
$ guix show git | recsel -p outputs
outputs: 
+ send-email: [description missing]
+ svn: [description missing]
+ credential-netrc: [description missing]
+ credential-libsecret: [description missing]
+ subtree: [description missing]
+ gui: [description missing]
+ out: everything else
--8<---cut here---end--->8---

It means that “git:send-email” provides “git send-email” for not
necessary Git itself.

1: https://guix.gnu.org/manual/devel/en/guix.html#Packages-with-Multiple-Outputs

Cheers,
simon

Re: Booth at FOSDEM (Brussels), 4-5 Feb 2023?

[zimoun]

Hi,

We do NOT have a stand at FOSDEM 2023.  We are not listed in:

https://fosdem.org/2023/news/2022-12-08-accepted-stands-fosdem-2023/

if I read correctly, although I did not received any email.

Thanks to everyone who offered to spend their time at the stand.  Maybe
next year!

See you at the Guix Days right before FOSDEM:

https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00100.html
https://libreplanet.org/wiki/FOSDEM2023-guix-days

Cheers,
simon


PS: The Guix project had also been refused back in 2019 [1].

1: 

Some stats about the graph of dependencies

[zimoun]

Hi,

Preparing some Python stuff, I was toying with the package
python-networkx.  And Guix is awesome because it is easy to extract the
graph of dependencies.

Here dependencies are just inputs, native-inputs and propagated-inputs.
It could be interesting to also include build-system dependencies, I
have been lazy. :-)

My initial question is to know what are the “essentials”?  By essential,
I mean the “important“ ones, the “hot” ones, etc.  The ones which are
“influencers” – yeah the world is a social network. :-)

First, let extract the graph with a tiny Scheme script:

$ guix repl -- packages-to-dict.scm > dod.py

Then, let import that into an IPython session:

$ guix shell python python-ipython \
   python-scipy python-matplotlib python-networkx  -- ipython

and run another tiny Python script for plotting.  See Figure attached.

We can compare a link analysis metrics [1] and a centrality measure
[2]; say PageRank [3] and Eigenvector [4].  More the value is large and
higher the package is “important“ (for this metrics).

And the Directed and Undirected graphs can be compared, using Networkx
[5,6].  Well, Eigenvector centrality (or Katz centrality [7]) is failing
because the power iteration does not converge but other metrics could be
also considered.  Here is just a first rough toy. :-)

According to PageRank applied to the Directed Graph, the 10 most
“important” packages are:

--8<---cut here---start->8---
[('pkg-config-0.29.2', 0.02418335991713879),
 ('perl-5.34.0', 0.015404032767249512),
 ('coreutils-minimal-8.32', 0.013240458675517012),
 ('zlib-1.2.11', 0.009107245584307803),
 ('python-pytest-6.2.5', 0.008413060648307678),
 ('ncurses-6.2.20210619', 0.007598925467605917),
 ('r-knitr-1.41', 0.00554772892485958),
 ('sbcl-rt-1990.12.19-1.a6a7503', 0.004884721933452539),
 ('bzip2-1.0.8', 0.004800877844001881),
 ('python-3.9.9', 0.00415536078558266)]
--8<---cut here---end--->8---

And if we compare the 3 results (Undirected with PageRank and
Eigenvector, and Directed with PageRank only, then 10 most “important”
packages are:

--8<---cut here---start->8---
['pkg-config-0.29.2',
 'glib-2.70.2',
 'zlib-1.2.11',
 'gtk+-3.24.30',
 'perl-5.34.0',
 'gettext-minimal-0.21',
 'qtbase-5.15.5',
 'libxml2-2.9.12',
 'python-3.9.9',
 'autoconf-2.69']
--8<---cut here---end--->8---

Somehow, it means that these packages have an high influence on all the
others.  Now, we can roughly compare with the release-manifest.scm [8],

--8<---cut here---start->8---
   '("bootstrap-tarballs" "gcc-toolchain" "nss-certs"
 "openssh" "emacs" "vim" "python" "guile" "guix")))
   '("coreutils" "grep" "findutils" "gawk" "make"
 #;"gcc-toolchain" "tar" "xz")))
   '("xorg-server" "xfce" "gnome" "mate" "enlightenment"
 "openbox" "awesome" "i3-wm" "ratpoison"
 "emacs" "emacs-exwm" "emacs-desktop-environment"
 "xlockmore" "slock" "libreoffice"
 "connman" "network-manager" "network-manager-applet"
 "openssh" "ntp" "tor"
 "linux-libre" "grub-hybrid"
   '("coreutils" "grep" "sed" "findutils" "diffutils" "patch"
 "gawk" "gettext" "gzip" "xz"
 "hello" "zlib"
--8<---cut here---end--->8---

Well, we could investigate more and play more with some graphs tools.
For instance, include all the build-system dependencies and so on.

Some list about “statistically important” packages could help for
improving the list of “essential” packages.

Although Python is great, I would like to run Guile.  Any Guile library
for manipulating graph is around?

All that to say, Guix is great! :-) And perhaps some of you have already
some Guile code for analysing graphs.  Maybe.

Well, comment or idea is welcome. :-)

1: 
2: 
3: 
4: 
5: 

6: 

7: 
8: 


Cheers,
simon



packages-to-dict.scm
Description: packages-to-dict.scm
import networkx as nx
import matplotlib
matplotlib.use('TkAgg')
import matplotlib.pyplot as plt
import numpy as np

exec(open("dod.py").read())
UG = nx.Graph(dod)
DG = nx.DiGraph(dod)

nnodes = DG.number_of_nodes()

# nx.draw(G, with_labels=True);plt.show()

metrics = [
(UG, nx.eigenvector_centrality),
(UG, nx.pagerank),
(DG, nx.pagerank),
]

Re: Winding down of Fosshost

[zimoun]

Hi,

On Sun, 04 Dec 2022 at 11:35, indieterminacy  
wrote:

> Given Fosshost's place in the ecosystem: is this something which 
> requires mitigating at the Guix end?

On Sun, 04 Dec 2022 at 13:16, Tobias Geerinckx-Rice  wrote:

> - They hosted a Big Blue Button instance[0] only for the duration 
>   of our COVID Days[1].

[...]

> [0]: (dead link) https://guixbbb.fosshost.org

Last time we used this BBB instance was for Outreachy back on November
2020 / April 2021.  After, we used other BBB instances.

They cancelled the BBB instance [0] some time ago; probably mid-2021 or
late 2021.  IIRC, they changed their policy and somehow asked us some
counterparts, so we moved.


Cheers,
simon

Re: Emacs proof-general

[zimoun]

Hi,

On Tue, 06 Dec 2022 at 10:38, pinoaffe  wrote:

> I don't know why this file is renamed,

The explanations are here: :-)

https://issues.guix.gnu.org/51755#5

or here: :-)

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/coq.scm#n217


> Does anyone know what's going on, and how this can be resolved?  (or is
> this just a case of user-error?)

Well, it works for me. ;-)  This,

   guix shell -C emacs proof-general coq -- emacs -q foo.v

correctly starts Proof-General.  Then, depending on what is inside the
file foo.v, say:

Definition x := 42.
Print x.

so I start Coq pressing ’C-c C-n’.

Otherwise, I have my Emacs packages under the profile
~/.config/guix/profiles/emacs (containing the packages emacs and
proof-general) and another profile ~/.confi/guix/profiles/compiler
(containing the package coq).  And I do not have any specific Coq or
Proof-General configuration in ~/.config/emacs.


Could you be more specific about what is not working for you?


Cheers,
simon

Re: Python Packaging Policy

[zimoun]

Hi,

On Wed, 07 Dec 2022 at 17:22, jgart  wrote:

> What is our policy then for updating Python packages in our Python
> library collection?

The policy is to not break the other packages; guix refresh -l python-.


> How are we assuring that all Python libraries are working well together?

How?  With a lot of love. :-)


Cheers,
simon

Re: File search

[zimoun]

Hi,

On Tue, 06 Dec 2022 at 11:01, Ludovic Courtès  wrote:
> "Antoine R. Dumont (@ardumont)" 
> skribis:
>
>> Please, find enclosed the latest implementation as a patch (somewhat vcs
>> code ;). I've edited commits to mark Ludo as author with his
>> started/amended implementations first [0] (that should be in the patch).

That’s cool!


> Also going forward we’ll need a schema version, as in:
>
> --8<---cut here---start->8---
> create table SchemaVersion (
> version integer not null;
> );
> --8<---cut here---end--->8---

Well, using plain SQLite as backend will make more complicated the way
to query.  For instance, “guix index output:doc gtk”.  Maybe it could be
worth to use guile-xapian as backend.

Cheers,
simon

Re: Help with G-expression

[zimoun]

Hi Ludo,

Thanks for the help.


On Sat, 03 Dec 2022 at 18:43, Ludovic Courtès  wrote:

> Fixed in 9672db290a35f59113682a7f0c17c050a4ae2578.

Well, the main issue was that I hit this bug. :-)

I tried to see if this trivial example is covered by the test suite but
I have not found it.  Something like,

--8<---cut here---start->8---
(define (something)
  (with-extensions (list guile-gcrypt)
(with-imported-modules (source-module-closure
'((guix build utils)
  (guix profiles))) ;import it
  (computed-file "empty-tree"
 #~(begin
 ;; Put it in scope.
 (use-modules (guix build utils))

 ;; Happily use its 'mkdir-p' procedure.
 (mkdir-p (string-append #$output "/a/b/c")))
,build (something)
--8<---cut here---end--->8---

where ’something’ would be a better name and ’,build’ the real function
call.  Well, maybe it could help to detect some regression. :-)  As
people tell: one bug closed, one test added. ;-)

Although it requires to talk with the daemon and I do not remember if it
is a good idea to add such test.


> It’s annoying, but I don’t see how this could be avoided.

Well, the error message is not super clear…

--8<---cut here---start->8---
building 
/gnu/store/rh1ii1cjlc0jhkz2aspxcw1mdkr7b2nf-module-import-compiled.drv...
 20% [# 
]builder for 
`/gnu/store/rh1ii1cjlc0jhkz2aspxcw1mdkr7b2nf-module-import-compiled.drv' failed 
with exit code 1
build of /gnu/store/rh1ii1cjlc0jhkz2aspxcw1mdkr7b2nf-module-import-compiled.drv 
failed
View build log at 
'/var/log/guix/drvs/rh/1ii1cjlc0jhkz2aspxcw1mdkr7b2nf-module-import-compiled.drv.gz'.
cannot build derivation 
`/gnu/store/cznhm1wzdv60jwi7fz96cilq925j54i1-empty-tree.drv': 1 dependencies 
couldn't be built
While executing meta-command:
ERROR:
  1. :
  message: "build of 
`/gnu/store/cznhm1wzdv60jwi7fz96cilq925j54i1-empty-tree.drv' failed"
  status: 100
--8<---cut here---end--->8---

…but the log somehow is:

--8<---cut here---start->8---
[ 1/56] Loading './guix/base16.scm'...

[...]

[11/56] Loading './guix/derivations.scm'...
;;; Failed to autoload make-zlib-input-port in (zlib):
;;; no code for module (zlib)
;;; Failed to autoload make-zlib-input-port in (zlib):
;;; no code for module (zlib)
;;; Failed to autoload make-zlib-output-port in (zlib):
;;; no code for module (zlib)
;;; Failed to autoload make-zlib-output-port in (zlib):
;;; no code for module (zlib)
Backtrace:

[...]

   222:17  1 (map1 (((gcrypt hash)) ((guix profiling)) ((rnrs #)) # ?))
   3329:6  0 (resolve-interface (gcrypt hash) #:select _ #:hide _ # _ ?)

ice-9/boot-9.scm:3329:6: In procedure resolve-interface:
no code for module (gcrypt hash)
--8<---cut here---end--->8---

Well, it seems reasonable, IMHO, to assume that an user diving into such
internal would be able to parse this information.


Cheers,
simon

Re: Release progress, week 8

[zimoun]

Hi,

On Sun, 04 Dec 2022 at 00:32, Maxim Cournoyer  wrote:

>> It reminds me that,
>>
>> https://othacehe.org/wsl-images-for-guix-system.htm
>>
>> could fit a Guix blog post.  Mathieu, WDYT?
>
> Mathieu wrote one already, it's published on their personal blog.  I've
> read it recently, it was interesting [0]
>
> [0]  https://othacehe.org/wsl-images-for-guix-system.html

Sorry to not have been clear, I am proposing to convert the already
published Mathieu’s post on their personal blog as a post on the Guix
blog.

I agree it is an interesting read and it appears to me worth for
communicating. :-)

It could be published “as is“ or could be a bit polished by proofreaders
(people behind the alias guix-b...@gnu.org; which includes myself :-)).

Mathieu, WDYT?


Cheers,
simon

Re: Release progress, week 8

[zimoun]

Hi Ludo,

On Fri, 02 Dec 2022 at 23:45, Ludovic Courtès  wrote:

> I started writing super long release notes (a book!), comments welcome:
>
>   
> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/gnu-guix-1.4.0-released.md
>
> Comments?  Suggestions?  Happiness?  Excitement?  You tell!

I will try to propose a couple of paragraphs for this:

--8<---cut here---start->8---
# Supporting long-term reproducibility

TODO:
  - SWH fallback for channels
  - Disarchive
--8<---cut here---end--->8---

About “guix pack -f deb”, I thought it was experimental and it is not
mentioned.  Maybe,

--8<---cut here---start->8---
 —has
been extended with an experimental format: `guix pack -f deb` creates a
standalone `.deb` package 
--8<---cut here---end--->8---

It reminds me that,

https://othacehe.org/wsl-images-for-guix-system.htm

could fit a Guix blog post.  Mathieu, WDYT?

About the part « **Python packaging** has seen important changes. » I
would mention the removal of many Python 2 packages.  Maxim, WDYT?


Cheers,
simon

Re: GNU Guix 1.4.0rc1 available for testing!

[zimoun]

Hi,

On Fri, 02 Dec 2022 at 17:17, Ahmed Khanzada  wrote:
> How can I switch my current GNU Guix installation over to 1.4?
> Afterwards, how could I switch it back? Is that all safe to do so?

I guess some usual,

guix pull  --branch=version-1.4.0
guix system reconfigure

then

guix pull  --roll-back
guix system reconfigure

Well, I think it should be possible using “guix time-machine”, something
like,

guix time-machine  --branch=version-1.4.0 -- system reconfigure

but then I do not know how it goes for switching back.

Cheers,
simon

Re: Help with G-expression

[zimoun]

Hi Ludo,

Thanks for your patience. :-)

On Fri, 02 Dec 2022 at 22:30, Ludovic Courtès  wrote:

> Oops, that one is a new bug due to
> 54003af85cc5b689bd328b30617c93ed2f5fd647.  I’ll look into it.

Ah, a good news. :-)

>> Below the log file – missing (gcrypt hash).
>
> So (with-extensions (list guile-gcrypt) …), as in ‘video-ges-project’ in
> ‘render-videos.scm’¹.
>
> In essence, the gexp you want to run must specify all the Guile modules
> and extensions it depends on; this is what ‘with-imported-modules’ and
> ‘with-extensions’ let you express.

Not here.  What I running is this:

--8<---cut here---start->8---
(with-imported-modules '((guix build utils))  ;import it
  (computed-file "empty-tree"
 #~(begin
 ;; Put it in scope.
 (use-modules (guix build utils))

 ;; Happily use its 'mkdir-p' procedure.
 (mkdir-p (string-append #$output "/a/b/c")
--8<---cut here---end--->8---

And it perfectly works. :-)  As explained in the very first email in
this thread.

The issue is when I am adding (guix profiles) and nothing more to the
previous perfectly working ’computed-file’.  How can I guess that this
module (guix profiles) requires (gcrypt hash) as extension?  Just to be
loaded since it is not used.

Sorry I am missing the obvious.

Cheers,
simon

Re: Help with G-expression

[zimoun]

Hi Ludo,

On Fri, 02 Dec 2022 at 10:09, Ludovic Courtès  wrote:
> zimoun  skribis:
>
>> no code for module (guix config)
>
> (guix config) is added by using ‘make-config.scm’; there’s an example in
> (gnu services base).
>
> For the rest, make sure to use ‘source-module-closure’ or you’ll miss
> modules (info "(guix) G-Expressions").

I have read this section. :-) Something is not clear for me.

Note that ’make-config.scm’ does not appear in the manual.

The only difference between the previous ’work’ example and all the
’fail’ as ’fail-again-not-fixed’ is only the part ’with-imported-modules’.

Well, I am somehow surprised how difficult is to find the correct.

--8<---cut here---start->8---
scheme@(guix-user)> (define (fail-again-not-fixed)
  (with-imported-modules (source-module-closure
  '((guix build utils)
(guix config)
(guix profiles)))  ;import it
(computed-file "empty-tree"
   #~(begin
   ;; Put it in scope.
   (use-modules (guix build utils))

   ;; Happily use its 'mkdir-p' procedure.
   (mkdir-p (string-append #$output "/a/b/c"))
scheme@(guix-user)> ,build (fail-again-not-fixed)
While executing meta-command:
Throw to key `match-error' with args `("match" "no matching pattern" 
(#:declarative? #f #:export (%guix-package-name %guix-version 
%guix-bug-report-address %guix-home-page-url %channel-metadata %system 
%store-directory %state-directory %store-database-directory %config-directory 
%gzip %bzip2 %xz)))'.
--8<---cut here---end--->8---

Here it is the same error as ’fail-again’.  And I do not understand the
magic invocation.  Well, what I tried next:

--8<---cut here---start->8---
scheme@(guix-user)> (define (fail-again-bis)
  (with-imported-modules `(((guix config) => ,(make-config.scm))
   ,@(source-module-closure '((guix build utils)
  (guix profiles))
#:select? not-config?))
(computed-file "empty-tree"
   #~(begin
   ;; Put it in scope.
   (use-modules (guix build utils))

   ;; Happily use its 'mkdir-p' procedure.
   (mkdir-p (string-append #$output "/a/b/c"))
;;; : warning: possibly unbound variable `make-config.scm'
;;; : warning: possibly unbound variable `not-config?'
scheme@(guix-user)> ,build (fail-again-bis)
While executing meta-command:
error: make-config.scm: unbound variable
scheme@(guix-user)> ,use(guix self)
scheme@(guix-user)> ,build (fail-again-bis)
While executing meta-command:
error: not-config?: unbound variable
scheme@(guix-user)> (define not-config?
  ;; Select (guix …) and (gnu …) modules, except (guix config).
  (match-lambda
(('guix 'config) #f)
(('guix rest ...) #t)
(('gnu rest ...) #t)
(rest #f)))
scheme@(guix-user)> ,build (fail-again-bis)
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
building /gnu/store/xjvjrkl3559jrlm0bnvdj29c838y81x3-config.scm.drv...
building /gnu/store/slwgyy4vnxprz0cj73vyq6psr7bqmbwz-module-import.drv...
building 
/gnu/store/cfjpfzph97dsishvr7g1bqxqw5kynns8-module-import-compiled.drv...
 20% [# 

]builder for 
`/gnu/store/cfjpfzph97dsishvr7g1bqxqw5kynns8-module-import-compiled.drv' failed 
with exit code 1
build of /gnu/store/cfjpfzph97dsishvr7g1bqxqw5kynns8-module-import-compiled.drv 
failed
View build log at 
'/var/log/guix/drvs/cf/jpfzph97dsishvr7g1bqxqw5kynns8-module-import-compiled.drv.gz'.
cannot build derivation 
`/gnu/store/pr3qqw26jilyhyn650i3w7z13i7k6p40-empty-tree.drv': 1 dependencies 
couldn't be built
While executing meta-command:
ERROR:
  1. :
  message: "build of 
`/gnu/store/pr3qqw26jilyhyn650i3w7z13i7k6p40-empty-tree.drv' failed"
  status: 100
--8<---cut here---end--->8---
  
Below the log file – missing (gcrypt hash).

Well, I give up because the try-error does not explain me how it
works. :-)

Any pointers?

Cheers,
simon

--8<---cut here---start->8---
[ 1/56] Loading './guix/base16.scm'...
[ 2/56] Loading './guix/base32.scm'...
[ 3/56] Loadin

Re: Licence of the Guix blog posts

[zimoun]

Hi Ludo,

Thanks for this clarification.  It reminds me hpc.guix.info posts. :-)

On Mon, 28 Nov 2022 at 18:22, Ludovic Courtès  wrote:

> Simon, what do you think about emailing the authors of the “10 years of
> stories” post asking if they agree with the licensing?  :-)  No rush,
> though the sooner the more likely we are to get an answer.

I will do my best this week-end.


Cheers,
simon

Re: Help with G-expression

[zimoun]

Hi,

On Thu, 01 Dec 2022 at 18:21, "("  wrote:
> On Thu Dec 1, 2022 at 5:34 PM GMT, zimoun wrote:
>> View build log at 
>> '/var/log/guix/drvs/g1/jbxhhz4b7zcyixhy4vw13brn2fncia-module-import-compiled.drv.gz'.
>
> What's in this file? :)

--8<---cut here---start->8---
Backtrace:
  16 (primitive-load "/gnu/store/hld85lyaq7k2h4qzbmlgiflypcx?")
In ice-9/eval.scm:
619:8 15 (_ #f)
In srfi/srfi-1.scm:
   460:18 14 (fold # ?)
   460:18 13 (fold # ?)
In ice-9/eval.scm:
619:8 12 (_ #(#(#) # ?))
In ice-9/boot-9.scm:
   2835:4 11 (save-module-excursion #)
In unknown file:
  10 (primitive-load "./guix/profiles.scm")
In ice-9/eval.scm:
   721:20  9 (primitive-eval (define-module (guix profiles) # (# ?) ?))
In ice-9/psyntax.scm:
  1230:36  8 (expand-top-sequence ((define-module (guix #) # (?) ?)) ?)
  1222:19  7 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
   259:10  6 (parse _ (("placeholder" placeholder)) (()) _ c (eval) ?)
In ice-9/eval.scm:
   293:34  5 (_ #)
In ice-9/boot-9.scm:
   3409:4  4 (define-module* _ #:filename _ #:pure _ #:version _ # _ ?)
  2594:24  3 (call-with-deferred-observers #)
  3422:24  2 (_)
   222:17  1 (map1 (((guix config) #:select (%state-directory)) (?) ?))
   3329:6  0 (resolve-interface (guix config) #:select _ #:hide _ # _ ?)

ice-9/boot-9.scm:3329:6: In procedure resolve-interface:
no code for module (guix config)
--8<---cut here---end--->8---

Then,

(guix utils)
(guix memoization)
(guix profiling)
(guix build syscalls)

and I stopped try-error the game before completing. :-)


Cheers,
simon

Help with G-expression

[zimoun]

Hi,

Trying to make a Guix script for extracting BigBlueButton videos – the
ones from Café Guix for instance – I am very puzzled by G-expression.

Well, I am trying to adapt this one [1].  But I am failing…

The manual has this example [1],

--8<---cut here---start->8---
(with-imported-modules '((guix build utils))  ;import it
  (computed-file "empty-tree"
 #~(begin
 ;; Put it in scope.
 (use-modules (guix build utils))

 ;; Happily use its 'mkdir-p' procedure.
 (mkdir-p (string-append #$output "/a/b/c")
--8<---cut here---end--->8---

Which I turn into a function, and from “guix repl”

--8<---cut here---start->8---
scheme@(guix-user)> (define (work)
  (with-imported-modules '((guix build utils))  ;import it
(computed-file "empty-tree"
   #~(begin
   ;; Put it in scope.
   (use-modules (guix build utils))

   ;; Happily use its 'mkdir-p' procedure.
   (mkdir-p (string-append #$output "/a/b/c"))

scheme@(guix-user)> ,build (work)
$1 = "/gnu/store/d8psk7dsczqj65sc8bqigpi6ffhd0wvn-empty-tree"
--8<---cut here---end--->8---

where “tree /gnu/store/d8psk7dsczqj65sc8bqigpi6ffhd0wvn-empty-tree” shows the 
tree a/b/c.  So far, so
good.

If instead, I just add the module (guix profiles), then it fails.

--8<---cut here---start->8---
scheme@(guix-user)> (define (fail)
  (with-imported-modules '((guix build utils)
   (guix profiles))  ;import it
(computed-file "empty-tree"
   #~(begin
   ;; Put it in scope.
   (use-modules (guix build utils))

   ;; Happily use its 'mkdir-p' procedure.
   (mkdir-p (string-append #$output "/a/b/c"))
scheme@(guix-user)> ,build (fail)
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
building 
/gnu/store/g1jbxhhz4b7zcyixhy4vw13brn2fncia-module-import-compiled.drv...
 50% [ 
]builder for 
`/gnu/store/g1jbxhhz4b7zcyixhy4vw13brn2fncia-module-import-compiled.drv' failed 
with exit code 1
build of /gnu/store/g1jbxhhz4b7zcyixhy4vw13brn2fncia-module-import-compiled.drv 
failed
View build log at 
'/var/log/guix/drvs/g1/jbxhhz4b7zcyixhy4vw13brn2fncia-module-import-compiled.drv.gz'.
cannot build derivation 
`/gnu/store/ln5yb7lvdknr3azc5zh2m3239adgmsjj-empty-tree.drv': 1 dependencies 
couldn't be built
While executing meta-command:
ERROR:
  1. :
  message: "build of 
`/gnu/store/ln5yb7lvdknr3azc5zh2m3239adgmsjj-empty-tree.drv' failed"
  status: 100
--8<---cut here---end--->8---

Well, the message is not really helping. :-)

Then, because I am not sure to fully understand the difference, let add
’source-module-closure’.

--8<---cut here---start->8---
scheme@(guix-user)> ,use(guix modules)
scheme@(guix-user)> (define (fail-again)
  (with-imported-modules (source-module-closure
  '((guix build utils)
(guix profiles)))  ;import it
(computed-file "empty-tree"
   #~(begin
   ;; Put it in scope.
   (use-modules (guix build utils))

   ;; Happily use its 'mkdir-p' procedure.
   (mkdir-p (string-append #$output "/a/b/c"))
scheme@(guix-user)> ,build (fail-again)
While executing meta-command:
Throw to key `match-error' with args `("match" "no matching pattern" 
(#:declarative? #f #:export (%guix-package-name %guix-version 
%guix-bug-report-address %guix-home-page-url %channel-metadata %system 
%store-directory %state-directory %store-database-directory %config-directory 
%gzip %bzip2 %xz)))'.
--8<---cut here---end--->8---

Ah, another message.  Not helping either. :-)


What do I miss or am doing wrong?


1: 

2: https://guix.gnu.org/manual/devel/en/guix.html#Build-Utilities

Cheers,
simon

Re: how to customize mirror list used in custom channels?

[zimoun]

Hi,

On Tue, 29 Nov 2022 at 09:41, Ludovic Courtès  wrote:

> The more I write, the closer I get to an actual implementation.  :-)
> If ‘url-fetch’ takes a #:mirrors, that should allow us to extend the set
> of mirrors quite conveniently, along the lines of:
>
>   (define (my-url-fetch . args)
> (apply url-fetch (append args '(#:mirrors …

Well, the ’url-fetch’ defined in (guix build download) already takes
#:mirrors, no?

--8<---cut here---start->8---
(define* (url-fetch url file
#:key
(timeout 10) (verify-certificate? #t)
(mirrors '()) (content-addressed-mirrors '())
(disarchive-mirrors '())
(hashes '())
print-build-trace?)
--8<---cut here---end--->8---

So, I guess you are talking about ’url-fetch*’ from (guix download) and
exported as ’url-fetch’.  Right?  The one which put the bits in the
store. :-)

Does something like that would make sense?

--8<---cut here---start->8---
diff --git a/guix/download.scm b/guix/download.scm
index 2e9ecb43fc..2497ea0f75 100644
--- a/guix/download.scm
+++ b/guix/download.scm
@@ -499,6 +499,7 @@ (define %download-fallback-test
 (define* (url-fetch* url hash-algo hash
  #:optional name
  #:key (system (%current-system))
+ (mirrors %mirrors)
  (guile (default-guile))
  executable?)
   "Return a fixed-output derivation that fetches data from URL (a string, or a
@@ -519,7 +520,8 @@ (define file-name
   (_
(basename url
 
-  (let ((uri (and (string? url) (string->uri url
+  (let ((uri (and (string? url) (string->uri url)))
+(mirror-file (plain-file "mirrors" (object->string mirrors
 (if (or (and (string? url) (not uri))
 (and uri (memq (uri-scheme uri) '(#f file
 (interned-file (if uri (uri-path uri) url)
@@ -540,7 +542,7 @@ (define file-name
  #:hash-algo hash-algo
  #:hash hash
  #:executable? executable?
- #:mirrors %mirror-file
+ #:mirrors mirror-file
  #:content-addressed-mirrors
  (match (%download-fallback-test)
((or #f 'content-addressed-mirrors)
--8<---cut here---end--->8---

This change would a world rebuild, right?

Last, note that ’download-to-store’ uses %mirrors so it seems
straightforward here to add ’#:key (mirrors %mirrors)’, I guess.


Cheers,
simon

Re: advanced?

[zimoun]

Hi,

On Mon, 28 Nov 2022 at 15:44, Simon Josefsson via "Development of GNU Guix and 
the GNU System distribution."  wrote:

> Yes, that makes sense.  I'm not the best person to summarize it, but
> starting pointers if someone wants to take it further:

Well, it is somehow part of,

* Transactional upgrades and roll-backs
* Reproducible build environments

I would also add Inferiors and Time-machine, especially working in
tandem with Software Heritage.  AFAIU, it is unique to be able to jump
to (almost) any point back in time and just rebuild (or almost), with
one command-line, whatever the state of the world (or almost).  It
pushes far beyond features such as https://snapshot.debian.org/ IMHO.

Cheers,
simon

Re: Guile debugger workgroup?

[zimoun]

Hi,

On Mon, 28 Nov 2022 at 12:06, Ludovic Courtès  wrote:

> Why doesn’t it work in ‘guix repl’?  Because auto-compilation is
> disabled:

Ah, thanks.  Well, maybe we could have an option to start “guix repl”
with debug mode available… even if it is really slow.


> I think we should identify scenarios where things don’t work as
> expected, and then turn them into bug reports, documentation issues, or
> any other concrete action we should take.

The example I provided is, IMHO, a good scenario for starting. :-)  For
instance, ,step by ,step works,

--8<---cut here---start->8---
$ guix shell guile -- guile -q
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (load "/tmp/my-target.scm")
scheme@(guile-user)> ,break example
Trap 0: Breakpoint at #.
scheme@(guile-user)> (example #t)
Trap 0: Breakpoint at #
Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> ,bt
In /tmp/my-target.scm:
 17:0  0 (example #t)
scheme@(guile-user) [1]> ,s
Step into #
scheme@(guile-user) [1]> ,bt
In /tmp/my-target.scm:
19:21  0 (example _)
scheme@(guile-user) [1]> ,s
Step into #
scheme@(guile-user) [1]> ,s
Step into #
scheme@(guile-user) [1]> ,s
Step into #
scheme@(guile-user) [1]> ,bt
In /tmp/my-target.scm:
19:20  1 (example _)
  3:0  0 (mutate-once "something")
scheme@(guile-user) [1]> 
--8<---cut here---end--->8---

but then I do not know how many steps are required to reach the other
’mutate-twice’.

--8<---cut here---start->8---
Step into #
Step into #
4x Step into #
5x Step into #
4x Step into #
Step into #
10x Step into #
4x Step into #
Step into #
6x Step into #
3x Step into #
5x Step into #
Step into #
…
--8<---cut here---end--->8---

And I do not know if ,break-at-source works correctly.

--8<---cut here---start->8---
$ cat -n /tmp/my-target.scm | grep 20
20   (my-target (mutate-twice my-target)))

$ guix shell guile -- guile -q
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (load "/tmp/my-target.scm")
scheme@(guile-user)> ,break example
Trap 0: Breakpoint at #.
scheme@(guile-user)> (example #t)
Trap 0: Breakpoint at #
Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> ,bt
In /tmp/my-target.scm:
 17:0  0 (example #t)
scheme@(guile-user) [1]> ,break-at-source "/tmp/my-target.scm" 20
Trap 1: Breakpoint at /tmp/my-target.scm:20.
scheme@(guile-user) [1]> ,bt
In /tmp/my-target.scm:
 17:0  0 (example #t)
scheme@(guile-user) [1]> ,next
Step into #
scheme@(guile-user) [1]> ,bt
In /tmp/my-target.scm:
19:21  0 (example _)
scheme@(guile-user) [1]> ,locals
  No local variables.
scheme@(guile-user) [1]>
--8<---cut here---end--->8---


Cheers,
simon

Re: how to customize mirror list used in custom channels?

[zimoun]

Hi,

On Mon, 28 Nov 2022 at 11:49, Ludovic Courtès  wrote:
> Hi,
>
> zimoun  skribis:
>
>> On Sat, 26 Nov 2022 at 12:11, Ludovic Courtès  wrote:
>
> [...]
>
>>> Now, if you really want to extend the set of things recognized, you
>>> could write variant of ‘url-fetch’ that passes a different #:mirrors
>>> argument to ‘built-in-download’.  Maybe ‘url-fetch’ could have a
>>> #:mirrors parameter to simplify it.
>>
>> Why is it not possible to extend ’%mirrors?
>
> What I described above is one way to extend it, just not via ‘set!’.

Just to be sure, one way is this extension mechanism,

--8<---cut here---start->8---
(define (qt-urls component version)
  "Return a list of URLs for VERSION of the Qt5 COMPONENT."
  ;; We can't use a mirror:// scheme because these URLs are not exact copies:
  ;; the layout differs between them.
  (list (string-append "https://download.qt.io/official_releases/qt/;
   (version-major+minor version) "/" version
   "/submodules/" component "-everywhere-opensource-src-"
   version ".tar.xz")
(string-append "https://download.qt.io/official_releases/qt/;
   (version-major+minor version) "/" version
   "/submodules/" component "-everywhere-src-"
   version ".tar.xz")
(string-append "https://download.qt.io/archive/qt/;
   (version-major+minor version) "/" version
   "/submodules/" component "-everywhere-opensource-src-"
   version ".tar.xz")
(let ((directory (string-append "qt5" (string-drop component 2
  (string-append "http://sources.buildroot.net/; directory "/"
 component "-everywhere-opensource-src-" version 
".tar.xz"))
(string-append "https://distfiles.macports.org/qt5/;
   component "-everywhere-opensource-src-" version 
".tar.xz")))
--8<---cut here---end--->8---

then,

(uri (qt-urls name version))

Right?  Well, for what it is worth, it does not appear to me consistent
with the rest.  We could do the same for everything, and remove
"mirror://" after all. :-)

The other one way is to implement a variant of url-fetch method.  What
would be the interface?  Where the extended list of mirrors would be
provided?


Cheers,
simon

Re: advanced?

[zimoun]

Hi Simon,

On Sat, 26 Nov 2022 at 22:47, Simon Josefsson via "Development of GNU Guix and 
the GNU System distribution."  wrote:

> The patch is meant as food for thought as I'm sure I'm missing
> something, and it may be a language/cultural thing.

I am not native-english.  The dictionary says:

 1. An advanced system, method, or design is modern and has been developed
from an earlier version of the same thing.

 2. Something that is at an advanced stage or level is at a late stage of
development.

 3. An advanced student has already learned the basic facts of a subject
and is doing more difficult work. An advanced course of study is
designed for such students.  

IIUC, you are understanding “advanced” as #3 when it can also be
understood as #1 or #2.

Well, I do not have an opinion about the term “advanced” for Guix.  For
sure, it seems worth to underline that the concepts are not as usual
distro. :-)


Cheers,
simon

Re: Guile debugger workgroup?

[zimoun]

Hi Ludo,

On Sat, 26 Nov 2022 at 12:22, Ludovic Courtès  wrote:

> Well, Guile has a debugger that lets you do that (modulo inlining etc.,
> as with any other compiler), and Geiser is not Visual Studio™ but it
> does a good job.

And you wrote elsewhere in the thread:

It may be more of a limitation of Geiser than of Guile.  I find
it more useful in “typical” imperative ELisp code than in
functional Scheme code, but it’d be nice to have either way!



Maybe I am wrong or miss some Guile features.  From my experience, the
issue is not the way that the information is presented or how we
interact with it (Geiser or else) but, instead, the issue is the
availability of such information.  And that is one limitation of Guile,
IMHO.

> Also, I think I mentioned before that I almost never use breakpoints on
> Guile code—not because of some deficiency of the debugger, not (just)
> because I’m silly or inexperienced, but because it’s rarely the right
> tool for the job.

That’s interesting. :-) Well, so you are using the good ol’ way putting
’pk’ here or there, right?  One thing when debugging is to inspect the
current state of the program; what are the values of this or that, then
after running this other, etc.  And, ’pk’ is the poor man
breakpoint. :-)


> I believe this is largely due to (1) writing functional code, and (2)
> doing live programming at the REPL.  Why would you use breakpoints when
> you can just call the relevant procedures on some input to see how they
> behave?

Well, I do not think you are not using breakpoint with Guile because the
code is functional style.  My guess is more that you have built your way
around the limitations of the Guile debugger.

For what this example is worth, I know people with 30+ years of
experience programming highly optimized C code and they never used GDB
or Valgrind or strace or else for debugging.  Doing all debugging with
plain ’printf’.  Well, because when they started, GDB and friends were
less efficient, other folk around were not used to these tools, etc.
And so they took habits without.


> So I think you won’t convince people to pick Guile for their project by
> selling it as a C/C++/Python drop-in replacement.  Guile is about
> functional programming and live coding so the set of tools differs.

Racket is an example of functional programming and live coding.  Haskell
is another; it is functional programming and if I might, I would
recommend to give a look at the interactive GHCi debugger [1].

Back to the initial example [2].  Racket is able to set breakpoints at
various places, as shown in the short demo [3].  Well, I am not able to
do that with Guile.

--8<---cut here---start->8---
$ cat -n my-target.scm
 1  ;#lang racket
 2  
 3  (define (mutate-once x)
 4(let ((once "once")
 5  (dash "-"))
 6  (string-append x dash once)))
 7  
 8  (define (mutate-twice x)
 9(let* ((dash "-")
10   (twice "twice")
11   (stuff (string-append twice dash)))
12(string-append "twice-" x)))
13  
14  (define (do-something-with x)
15(string-length x))
16  
17  (define (example x)
18(let* ((my-target "something")
19   (my-target (mutate-once my-target))
20   (my-target (mutate-twice my-target)))
21  (do-something-with my-target)))
--8<---cut here---end--->8---

then,

--8<---cut here---start->8---
$ guix repl
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> (load "my-target.scm")
scheme@(guix-user)> ,break-at-source "my-target.scm" 17
While executing meta-command:
No procedures found at ~a:~a. "my-target.scm" 17
scheme@(guix-user)> ,break-at-source "/home/simon/tmp/my-target.scm" 17
While executing meta-command:
No procedures found at ~a:~a. "/home/simon/tmp/my-target.scm" 17
scheme@(guix-user)> (example #t)
$1 = 20
scheme@(guix-user)> ,break example
Trap 2: Breakpoint at #.
scheme@(guix-user)> (example #t)
$2 = 20
scheme@(guix-user)>
--8<---cut here---end--->8---

How can I enter in the debugger?  Do I only enter on error?  Well, I end
to put ’pk’ here and there to inspect the code.  Poor experience. :-)

Just to compare with Haskell (functional style, where it is hard nor
impossible to put equivalent of ’pk’ here or there :-)) – the code is
the equivalent as above.

--8<---cut here---start->8---
 1  mutate_once x = x ++ dash ++ once
 2where
 3  once = "once"
 4  dash = "-"
 5  
 6  

Re: how to customize mirror list used in custom channels?

[zimoun]

Hi,

On Sat, 26 Nov 2022 at 12:11, Ludovic Courtès  wrote:

>   (origin
> (method url-fetch)
> (uri (list URL1 URL2 URL3))
> (base32 …))

Neat!  This is nice for one or two packages.


> See for example how ‘qtbase’ does it.

Well, it looks like it is a manual implementation of the Guix mirror
mechanism.


> Now, if you really want to extend the set of things recognized, you
> could write variant of ‘url-fetch’ that passes a different #:mirrors
> argument to ‘built-in-download’.  Maybe ‘url-fetch’ could have a
> #:mirrors parameter to simplify it.

Why is it not possible to extend ’%mirrors?  For instance, it is
possible to extend ’%load-path’.  Why not %mirrors?


Cheers,
simon

Re: issue tracking in git

[zimoun]

Hi Arun,

On Fri, 25 Nov 2022 at 22:03, Arun Isaac  wrote:

[...]

> https://guix-forge.systemreboot.net/manual/dev/en/

[...]

> https://github.com/genenetwork/genenetwork-machines/

Cool!  Thanks for sharing.


Cheers,
simon

Re: issue tracking in git

[zimoun]

Hi Pjotr,

On Wed, 23 Nov 2022 at 14:18, Pjotr Prins  wrote:

> We also have ci and cd based on our own system containers in Guix.
>
> => https://ci.genenetwork.org/

This is based on which CI code?  Your own or do you use an existing CI
framework/tools?


Cheers,
simon

Re: [RFC] package-with-features

[zimoun]

Hi,

On Thu, 24 Nov 2022 at 20:26, "("  wrote:

> This comment by oriansj on IRC:
>
>I am thinking in terms of gentoo builds and making
>   it easy to avoid some packages from being downloaded or built
>   like pulseaudio (I like alsa better) and trim down the dependencies
>   to only those that are absolutely directly required.
>
> made me wonder how we could incorporate such a feature into
> Guix.

Maybe, you could be interested by past discussions:

Parameterized packages (May 2019)
id:87woitz1xx@gnu.org
https://yhetil.org/guix/87woitz1xx@gnu.org/

A plan for parameterized packages (Nov 2020)
id:87eeku8trb@gnu.org
https://yhetil.org/guix/87eeku8trb@gnu.org


> # Unanswered Questions
>
> - Should CI try to build at least some non-default feature permutations?
>   (Probably not.)

>From my understanding, one of the issue of the unmanageable number of
combinations.  Well, I am doubtful we (the project) would be able to
guarantee that this feature combination builds or even works.

Maybe Mathieu or Chris can comment about the CI, but to my knowledge,
the build farms are already quite busy.  Without speaking it would
require to store such resulting substitutes; which means less space for
others and so a poorer experience with “guix time-machine“ for older
Guix revisions.


> - Might there be a better syntax for features in package specs?

Maybe, the ’outputs’ mechanism could be used.  The TODO list file in the
Guix repository contains:

--8<---cut here---start->8---
** extend ‘propagated-build-inputs’ with support for multiple outputs

#+BEGIN_SRC scheme
  (outputs '("out" "include"))
  (propagated-build-inputs
`"i1" ,p1 "o1")
("i2" ,p2))
   => "include")
  ("i3" ,p3)))
#+END_SRC
--8<---cut here---end--->8---

where the idea seems to have conditional inputs depending on the
outputs.  Somehow, this mechanism would ease to build feature variants.


Cheers,
simon

how to customize mirror list used in custom channels?

[zimoun]

Hi,

I have a custom channel defining a package.  The source of this package
is mirrored.

In ’(guix download)’ module, the list of mirrors are provided by the
list ’%mirrors’.  So I would like to add mine, e.g.,

(cons
 '(mine
   "https://fast-server.org/sources/;
   "hhtps://kikoo.io/path/to/something/")
 %mirrors)

and then in my package definition,

(uri "mirror://mine/stuff.tar.gz")

Somehow, I would like to replace the list %mirrors by an extended one.

Well, I am stuck because I am puzzled by the Guile module system. :-)


How to customize the mirror list?

Cheers,
simon

Re: nss-certs@3.81: server certificate verification failed. CAfile: /gnu/store/…/ca-certificates.crt CRLfile: none

[zimoun]

Hi,

On Wed, 23 Nov 2022 at 18:18, Tobias Geerinckx-Rice  wrote:

> It's incorrectly sending an ISRG Root X1 certificate, which chains 
> to the expired DST Root CA X3.
>
> It should not send ISRG Root X1 at all.

Thanks for the explanations.  Reported upstream.

Cheers,
simon

Fail ’guix time-machine’ on Nov 2021 because libgit2

[zimoun]

Hi,

Well, I am looking for different past versions of Numpy, so I am trying
commit b9595a7659 from Nov 11, 2021,

gnu: python-numpy: Update to 1.21.3 and cleanup.

and I just run,

   guix time-machine --commit=b9595a7659 -- help

which returns an error:

--8<---cut here---start->8---
[...]

cannot build derivation 
`/gnu/store/ss0hz522h5w8bp82d4xz165318qw1yv5-profile.drv': 1 dependencies 
couldn't be built
guix time-machine: error: build of 
`/gnu/store/ss0hz522h5w8bp82d4xz165318qw1yv5-profile.drv' failed
--8<---cut here---end--->8---

and the failure is about libgit2. The log reads,

--8<---cut here---start->8---
[...]

refs::rename...
refs::revparse.F

  1) Failure:
refs::revparse::date 
[/tmp/guix-build-libgit2-1.1.0.drv-0/libgit2-1.1.0/tests/refs/revparse.c:31]
  Function call succeeded: error
  no error, expected non-zero return

error: in phase 'check': uncaught exception:
%exception #< program: "./libgit2_clar" arguments: ("-v" "-Q") 
exit-status: 1 term-signal: #f stop-signal: #f> 
phase `check' failed after 11.5 seconds
command "./libgit2_clar" "-v" "-Q" failed with status 1
--8<---cut here---end--->8---

Well, is it specific to my machine?  Or is it reproducible?


Cheers,
simon

nss-certs@3.81: server certificate verification failed. CAfile: /gnu/store/…/ca-certificates.crt CRLfile: none

[zimoun]

Hi,

Well, using nss-certs@3.81, I get this failure,

--8<---cut here---start->8---
$ guix time-machine --commit=785fd09af0e161906e984944ddae363c384b66dd \
   -- show nss-certs | recsel -p version
version: 3.81

$ guix time-machine --commit=785fd09af0e161906e984944ddae363c384b66dd \
   -- shell -CN git nss-certs \
   -- git clone https://gitlab.in2p3.fr/reprovip/reprovip-guix nss-3.81
Cloning into 'nss-3.81'...
fatal: unable to access 'https://gitlab.in2p3.fr/reprovip/reprovip-guix/': 
server certificate verification failed. CAfile: 
/gnu/store/h51ffnnqqkydhvgmyd77fhswwcddlan9-profile/etc/ssl/certs/ca-certificates.crt
 CRLfile: none
--8<---cut here---end--->8---

but it does not happen when running nss-certs@3.71 instead,

--8<---cut here---start->8---
$ guix time-machine --commit=65cabb010e3388d10f9b25ec560bfcfab5f810d4 \
   -- show nss-certs | recsel -p version
version: 3.71

$ guix time-machine --commit=65cabb010e3388d10f9b25ec560bfcfab5f810d4 \
   -- shell -CN git nss-certs \
   -- git clone https://gitlab.in2p3.fr/reprovip/reprovip-guix nss-3.71
Cloning into 'nss-3.71'...
warning: redirecting to https://gitlab.in2p3.fr/reprovip/reprovip-guix.git/
remote: Enumerating objects: 303, done.
remote: Counting objects: 100% (303/303), done.
remote: Compressing objects: 100% (140/140), done.
remote: Total 352 (delta 110), reused 267 (delta 89), pack-reused 49
Receiving objects: 100% (352/352), 12.23 MiB | 22.01 MiB/s, done.
Resolving deltas: 100% (117/117), done.
--8<---cut here---end--->8---

Is it a bug in Guix nss-certs side?  Or on Gitlab server side?


Cheers,
simon

Re: RFC: libgit2 is slow/inefficient; switch to git command?

[zimoun]

Hi,

On Tue, 22 Nov 2022 at 21:15, Phil  wrote:

> Just to add mine too - libgit2 behaves differently to command-line git
> in ways which can make guix do unexpected things when caching clones in
> certain cases.  This has resulted in some hard to diagnose issues with
> using guix to build PRs for example.

[...]

> An explanation of why, was raised with libgit2:
> https://github.com/libgit2/libgit2/issues/6183

To avoid people to follow various links, this issue #6183 is another
manifestation of issue #3361 (still open since Aug 6, 2015).  Quoting:

Git has recently changed the refspec matching rules to allow
refspecs such as

refs/heads/o*:refs/remotes/heads/i*

We still perform checks using the old rules by which the glob
must always match a full path element.

https://github.com/libgit2/libgit2/issues/3361

However, pleas note that only 3 issues with the tag ’git compatibility’
are currently open [1]–well three when 2 are related.

1: 

Cheers,
simon

Re: Layout of ‘define-configuration’ records

[zimoun]

Hi Maxim,

On Mon, 21 Nov 2022 at 16:00, Maxim Cournoyer  wrote:

> That sounds very appropriate indeed.  I guess we could send
> announcements on API breaking changes to both places.  I suppose not
> many people are registered to 'info-guix' (I wasn't myself until
> recently ^^').

Well, more is better here, no? :-)


> I guess that's a question of how disruptive the API change is, but it'd
> be convenient if it was 2 weeks to match the time the change might
> appear on guix-patches un-reviewed.

Well, the process for API change could be:

 1. + submit to guix-patches,
+ in the same time, announce to guix-devel; so people not subscribed to
  guix-patches can chime.
 2. + after 2 weeks, or consensus, merge the change,
+ in the same time, announce to guix-devel, info-guix and --news.

There is no extra burden and it smooths the change for many users, IMHO.

WDYT?

Cheers,
simon

Re: RFC: libgit2 is slow/inefficient; switch to git command?

[zimoun]

Hi,

On Mon, 21 Nov 2022 at 21:21, Maxim Cournoyer  wrote:

> Given that:
>
> * the git CLI doesn't suffer from such poor performance;
> * This kind of performance problem has been known for years in libgit2
>   [0] with no fix in sight;
> * other projects such as Cargo support using the git CLI and that
>   projects are using it for that reason [1];

And I would add the lack of «Support for shallow repositories» [1].

1: 


> Would it make sense to switch to use the git command directly instead of
> calling into this libgit2 C library that ends up being slower?  It would
> provide a hefty speed-up when using 'guix refresh' or building new
> packages fetched from git without substitutes, or using 'git-checkout',
> etc.

Well, the question is about the closure and the bootstrap.

For instance,

--8<---cut here---start->8---
$ guix size guix | grep 'total:'
total: 629.5 MiB

$ guix size guix git-minimal | grep 'total:'
total: 671.0 MiB
--8<---cut here---end--->8---

which is not nothing but not so worse neither.  However, it would
require a fine scrutinizing about what would be added as dependencies.

The proposal is to fully drop ’guile-git’ and instead run ’(invoke "git"
)’ as in the module ’(guix build git)’, right?

Cheers,
simon

PS: For the record, Software Heritage, which ingests *a lot* of Git
repositories, relies on Dulwhich [2] (pure Python implementation), IIUC.

2: 

Re: [Guix Website] A Search Page for Packages

[zimoun]

Hi Chris,

On Mon, 21 Nov 2022 at 08:57, Christopher Baines  wrote:
> zimoun  writes:
>
>> On Sat, 19 Nov 2022 at 10:51, Christopher Baines  wrote:
>>
>>> It's really nice to have multiple things now (packages.guix.gnu.org,
>>> qa.guix.gnu.org, bordeaux.guix.gnu.org, ...) that are made possible by
>>> the Guix Data Service!
>>
>> Chris, what do you mean by «that are made possible by the Guix Data
>> Service»?
>
> Only that the things I mention are making use of the Guix Data Service
> to provide and query data.

Just to be sure, by Guix Data Service, do you mean the code
https://git.savannah.gnu.org/git/guix/data-service.git?  Or do you mean
a generic name for all the services as qa.guix, bordeaux.guix,
packages.guix or even issues.guix, logs.guix?


Cheers,
simon

Re: ci.guix.gnu.org and associated services downtime

[zimoun]

Hi Maxim,

I am replying a bit late…

On Thu, 10 Nov 2022 at 16:42, Maxim Cournoyer  wrote:

> There is currently an outage with Berlin, which hosts the build farm,
> the web site, the issue tracker and a host of other Guix services.

…but thanks for the notification.  I read it on time and it avoid me
some annoyance. :-)


> Simply rebooting the machine doesn't fix it and it seems it may has to
> do with the disk controller or the disk itself, so sadly it seem it'll
> take some before it can be brought back up and running.

I hope all is now fixed.


Cheers,
simon

Re: (M)ELPA package metadata accuracy

[zimoun]

Hi Ludo,

On Mon, 21 Nov 2022 at 11:00, Ludovic Courtès  wrote:

> So that’d be 72% accurate package metadata for (M)ELPA, not too bad!

IMHO, one could extrapolate that if someone applies a similar approach
as Lars for CRAN, then 70-75% of (M)ELPA should build out-of-the box.

BTW, unrelated to the topic but note that I engaged a discussion [1]
with Org folk about using Guix as a brick for quality assurance of Emacs
packages – starting with Org. ;-)  Well, the GNU project should reuse
its own components instead of relying on other distros. :-)

1: 


> I tried to estimate repository package data accuracy for my PackagingCon
> talk last year in a sophisticated way (perhaps too sophisticated):
>
>   
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/plain/talks/packaging-con-2021/grail/talk.2020.pdf
>   (slide 53)
>
>   https://lists.gnu.org/archive/html/guix-devel/2021-10/msg00297.html

IIRC, you mainly investigated the accuracy of the importers…

> I think we should identify common sources of inaccuracy in package
> metadata

…and indeed maybe a systematic analysis of the modifications of the
default emacs-build-system could help in 2 directions:

 1. maybe draw some heuristics to improve the importer accuracy,

>  talk with repo maintainers to improve on that.

and 2. report upstream if some patterns appear.


Well, for packages using ’emacs-build-system’, only comparing ’keyword’
arguments, it reads:

emacs: 1234 = 1234 = 878  + 356
("phases" . 213)
("tests?" . 144)
("test-command" . 127)
("include" . 87)
("emacs" . 25)
("exclude" . 20)
("modules" . 7)
("imported-modules" . 4)
("parallel-tests?" . 1) 

Considering this 356 packages, 144 modifies the keyword #:tests?.  Note
that ’#:tests? #t’ is counted in these 144 and it reads,

$ ag 'tests\? #t' gnu/packages/emacs-xyz.scm | wc -l
117

Ah!  It requires some investigations. :-)

Indeed, it could be worth to identify common sources of the extra
modifications we are doing compared to the default emacs-build-system.


Cheers,
simon

(use-modules (guix)
 (gnu)
 (srfi srfi-1)
 (ice-9 match))


(define %table (make-hash-table))

(define (keyword-as-string arg)
  (map (compose symbol->string keyword->symbol)
   (filter keyword? arg)))

(define (count-items lst)
  (if (null? lst)
  '()
  (let ((sorted (sort lst string<=?)))
(sort
 (fold (lambda (keyword result)
 (match result
   ((head tail ...)
(match head
  ((k . v)
   (if (string= k keyword)
   (cons `(,k . ,(+ 1 v)) tail)
   (cons `(,keyword . 1) result)))
  (_ (format #t "Error:"
   (_ (format #t "Error:"
   (list `(,(car sorted) . 1))
   (cdr sorted))
 (lambda (x1 x2)
   (match x1
 ((k1 . v1)
  (match x2
((k2 . v2)
 (> v1 v2))


(fold-packages (lambda (package result)
 (let ((bs  (build-system-name
 (package-build-system package)))
   (arg (package-arguments package)))
   (match (hash-ref result bs)
 ((tot wo wi args)
  (if (null? arg)
  (hash-set! result bs (list
(1+ tot)
(1+ wo)
wi args))
  (hash-set! result bs (list
(1+ tot)
wo
(1+ wi)
(append (keyword-as-string arg)
args)
 (#f (if (null? arg)
 (hash-set! result bs (list 1 1 0 '()))
 (hash-set! result bs (list 1 0 1 
(keyword-as-string arg)
 (_ (format #t "Error: ~s~%" (package-name package
   result))
  %table)


(define fmt "~13s: ~4s = ~4s = ~4s + ~4s  ~{ ~s ~}~%")
(format #t fmt
'key 'tot 'tot 'no-arguments 'arguments (list 'pattern?))
(hash-for-each-handle (lambda (kv)
(match kv
  ((key . value)
   (match value
 ((tot wo wi args)
  (format #t fmt
  key
  (+ wo wi)
 

Re: Guix Shows Us The Executable Binaries

[zimoun]

Hi,

On Mon, 21 Nov 2022 at 08:56, Christopher Baines  wrote:
> jgart  writes:
>
>> wdyt if we show the bin folder in `guix show` output like in fedora?
>
> How would you implement that? Would the guix show command build the
> package if it isn't in the store?

In addition to Chris’s comment, please give a look at the “guix
filesearch” old proposal [1].  Be able to list the executable binary
files by “guix show” requires to get the list from the substitute
servers, so they need to somehow expose new features.

1: 

Cheers,
simon

Re: [Guix Website] A Search Page for Packages

[zimoun]

Hi Chris,

Really cool!  Thank you Felipe and Chris for this new
packages.guix.gnu.org. :-)


On Sat, 19 Nov 2022 at 10:51, Christopher Baines  wrote:

> It's really nice to have multiple things now (packages.guix.gnu.org,
> qa.guix.gnu.org, bordeaux.guix.gnu.org, ...) that are made possible by
> the Guix Data Service!

Chris, what do you mean by «that are made possible by the Guix Data
Service»?

Cheers,
simon

Re: guix open

[zimoun]

Hi,

On Fri, 18 Nov 2022 at 13:49, jgart  wrote:

> what do you think of having a `guix open` command that opens the projects
> home-page in your $BROWSER? 

It is already possible, thanks Unix composability. :-)

   $BROWSER $(guix show hello | recsel -P homepage)

Well, ’recsel’ from the package recutils is unusual and appears a bit
weird at first but it is very powerful once RTFM. :-)


Cheers,
simon

Re: guix open

[zimoun]

Hi,

On Fri, 18 Nov 2022 at 20:25, "("  wrote:
> On Fri Nov 18, 2022 at 8:22 PM GMT, Tobias Geerinckx-Rice wrote:
>> Yes — as ‘guix open’ — but it would make a nice addition to ‘guix 
>> show’.
>
> How would that interact with ``guix package --show''? Perhaps it might
> be better to add a ``guix package --open'' option?

Currently “guix show” is an alias of “guix package --show=” and we could
start to do the contrary, “guix package --show=” would be using “guix
show”.  Mainly for maintaining backward compatibility.  But “guix show”
could evolve this own way supporting options that would not be supported
by legacy “guix package --show=”.  WDYT?

It would avoid some headache. ;-)


Cheers,
simon

Re: guix melpa mirror!

[zimoun]

Hi,

On Thu, 17 Nov 2022 at 19:06, jgart  wrote:

> I would love for guix to have very powerful automated package creation
> for all language ecosystems! 

Well, it strongly depends on the quality of the targeted language
ecosystem.  For some, they provide enough metadata to rely on for good
automatizing; for instance, R with CRAN or Bioconductor.

Sadly, for many others ecosystem, they (upstream) do not provide enough
metadata to automatically fill all the package fields.  And some manual
tweaks are required.

For example, let count the number of packages that are tweaking their
’arguments’ fields (from ’#:tests? #f’ to complex phases modifications).
This is far from being a perfect metrics but it is a rough indication
about upstream quality: if they provide clean package respecting their
build system or if the package requires Guix adjustments.

Well, I get:

  r: 2093 = 2093 = 1991 + 102 

which is good (only ~5% require ’arguments’ tweaks), but

  python   : 2630 = 2630 = 803  + 1827

is bad (only ~31% do not require an ’arguments’ tweak).

About Emacs, it reads,

  emacs: 1222 = 1222 = 874  + 348 

>From my point of view, it seems that it would be hard to have full
automated Emacs packaging for Guix.  Well, it requires some work to find
some heuristics at importing (converting) time and that’s not
straightforward, IMHO.

Cheers,
simon

--8<---cut here---start->8---
$ guix repl -- arguments-vs-import.scm
key  : tot  = tot  = no-arguments + arguments
ocaml: 57   = 57   = 0+ 57  
haskell  : 723  = 723  = 505  + 218 
clojure  : 11   = 11   = 0+ 11  
qt   : 226  = 226  = 98   + 128 
copy : 105  = 105  = 1+ 104 
maven: 1= 1= 0+ 1   
node : 48   = 48   = 2+ 46  
minetest-mod : 18   = 18   = 18   + 0   
chicken  : 9= 9= 0+ 9   
emacs: 1222 = 1222 = 874  + 348 
linux-module : 14   = 14   = 0+ 14  
raw  : 1= 1= 1+ 0   
glib-or-gtk  : 128  = 128  = 31   + 97  
asdf/source  : 659  = 659  = 553  + 106 
dune : 226  = 226  = 39   + 187 
go   : 483  = 483  = 0+ 483 
cmake: 1115 = 1115 = 92   + 1023
minify   : 11   = 11   = 1+ 10  
perl : 823  = 823  = 710  + 113 
android-ndk  : 11   = 11   = 0+ 11  
waf  : 25   = 25   = 0+ 25  
trivial  : 223  = 223  = 0+ 223 
julia: 273  = 273  = 129  + 144 
r: 2093 = 2093 = 1991 + 102 
guile: 41   = 41   = 14   + 27  
elm  : 29   = 29   = 24   + 5   
cargo: 3342 = 3342 = 195  + 3147
ruby : 475  = 475  = 80   + 395 
rebar: 19   = 19   = 11   + 8   
scons: 14   = 14   = 0+ 14  
font : 85   = 85   = 61   + 24  
rakudo   : 21   = 21   = 10   + 11  
gnu  : 4241 = 4241 = 812  + 3429
asdf/ecl : 637  = 637  = 434  + 203 
asdf/sbcl: 678  = 678  = 453  + 225 
ant  : 462  = 462  = 1+ 461 
meson: 448  = 448  = 88   + 360 
texlive  : 143  = 143  = 0+ 143 
python   : 2630 = 2630 = 803  + 1827
--8<---cut here---end--->8---

(use-modules (guix)
 (gnu)
 (ice-9 match))


(define table (make-hash-table))

(fold-packages (lambda (package result)
 (let ((bs  (build-system-name
 (package-build-system package)))
   (arg (package-argumentspackage)))
   (match (hash-ref result bs)
 ((tot wo wi)
  (if (null? arg)
  (hash-set! result bs (list
(1+ tot)
(1+ wo)
wi))
  (hash-set! result bs (list
(1+ tot)
wo
(1+ wi)
 (#f (if (null? arg)
 (hash-set! result bs (list 1 1 0))
 (hash-set! result bs (list 1 0 1
 (_ (format #t "Error: ~s~%" (package-name package
   result))
  table)


(define fmt "~13s: ~4s = ~4s = ~4s + ~4s~%")
(format #t fmt
'key 'tot 'tot 'no-arguments 'arguments)
(hash-for-each-handle (lambda (kv)
(match kv
  ((key . value)
   (match value
 ((tot wo wi)
  (format #t fmt
  key
  (+ wo wi)
  tot wo wi))
  table)

Re: debbugs-guix.el helper function

[zimoun]

Hi,

On Fri, 07 Oct 2022 at 11:47, Ludovic Courtès  wrote:

> I have something similar that I find extremely useful: hitting C-w on a
> bug adds the mumi and debbugs URLs to the kill ring.

In addition, another helper that I plan to use more… But it is not that
handy with Debbugs because of Gnus.  Well, via Notmuch (or Mu4e), it is
handy,

--8<---cut here---start->8---
(defun my/notmuch-issues (msgid)
  "Add URL of MSGID pointing to bug number to `kill-ring'.

Yankable result:
`http://issues.guix.gnu.org/issue/msgid/'

then resolved by the server.

Work only `notmuch-tree-mode', `notmuch-search-mode' or
`notmuch-show-mode'."
  (interactive
   (list
(let ((yanked
   (if (or (eq major-mode 'notmuch-tree-mode)
   (eq major-mode 'notmuch-search-mode)
   (eq major-mode 'notmuch-show-mode))
   (progn
 (notmuch-show-stash-message-id-stripped)
 (car kill-ring))
 "?")))
  (read-string
   (format "Message-ID (%s): " yanked)
   nil nil yanked
  (let* ((url
  (format "%s%s"
  "http://issues.guix.gnu.org/msgid/;
  msgid)))
(kill-new url)
(when current-prefix-arg
  (browse-url url))
(message (format "%s killed." url
--8<---cut here---end--->8---

When reading from Emacs-Notmuch, I just run ’M-x my/notmuch-issues’ and
then I can yank elsewhere the URL.  Last, Mumi resolves from the
Message-ID to the Debbugs number (even the specific message instead of
#2 or else).


Cheers,
simon

Re: Booth at FOSDEM (Brussels), 4-5 Feb 2023?

[zimoun]

Hi,

On Tue, 18 Oct 2022 at 18:59, zimoun  wrote:

> As the winter, FOSDEM 2023 is coming…
>
> https://fosdem.org/2023

As you may know, the devroom [1] on Declarative and Minimalistic
Computing at FOSDEM 2023 is on the road.  Keep in touch about Guix Days…


About a Guix stand at FOSDEM:

>  1. do we run for a booth?

I sent the application.  Wait and see…

>  2. who is in?

For now, volunteers are:

 + Jonathan
 + Julien
 + Josselin
 + Simon

As you see, even if your name does not start with a ’J’, you can be
volunteer. ;-)


In all cases, see you at FOSDEM 2023!

Cheers,
simon

1: <https://yhetil.org/guix/f9a0548c-0f5e-ff05-43cc-f0d8c036a...@gmail.com>

Re: Compile skribilo doc containing guix channel references

[zimoun]

Hi Ludo,

On jeu., 10 nov. 2022 at 12:58, Ludovic Courtès  wrote:

>> Is it possible to have a Skribilo reader which would use less
>> parenthesis?  Similar to Racket Scribble?
>
> Definitely, there’s already a couple of them and we could add one with a
> syntax similar to Texinfo or Scribble.

Do you mean Skribe syntax and Outline syntax [1] by “a couple of them”?
Or others?

Well, if it is possible to implement something similar to Texinfo, why
not similar to LaTeX which is more popular for scientific authoring
system than all the others.  For what it is worth, I would never invest
in something different from LaTeX syntax for publishing. :-)

1: https://www.nongnu.org/skribilo/doc/user-3.html


Cheers,
simon

Re: Update on automating testing of patches and qa.guix.gnu.org

[zimoun]

Hi Chris,

On Mon, 07 Nov 2022 at 10:36, Christopher Baines  wrote:

> For the Git branches, there's Gitolite+cgit+some other stuff setup here
> https://git.guix-patches.cbaines.net/git/guix-patches
>
> So yes, this command should work (obviously, disabling authentication
> isn't good):
>
>   guix time-machine \
> --url=https://git.guix-patches.cbaines.net/git/guix-patches \
> --branch=issue-58812 --disable-authentication -- shell --symlink

That’s awesome!  It just works.  It could be a booster for reviewing
patches because:

 1. substitutes are sometimes available; which is really helpful for
 people using low-power machines,

 2. it simplifies the workflow for testing.

However, something about “guix time-machine” is not cached as expected.
Running twice in a row the same command and then

Computing Guix derivation for 'x86_64-linux'...

is computed each time; when it should not, IIUC.   Another story. :-)


> Eventually I'd like to move this off of a machine I'm paying for, plus
> move it on to a .guix domain. Also, even though the channel instance for
> some branches might have been built by the data.qa.guix.gnu.org Guix
> Data Service, this isn't done in a way that substitutes are available,
> so that's not ideal.

What do you mean by «this isn't done in a way that substitutes are
available»?


> I'm using this list here https://qa.guix.gnu.org/patches and just
> looking at the ones at the top with the green circle by them.
>
> An API endpoint could easily be added though if that's useful.

Personally, I find easier to query and get back a list that I can
process instead of having open my webbrowser. :-)


>>> If there's any which
>>> aren't (e.g. needs some changes or more discussion), you can mark it as
>>> moreinfo to push it down the list (there's a link on the right to do
>>> this).
>>
>> Mark it as ’moreinfo’ via Debbugs?  Or something else?
>
> Yep. I'm currently trying to keep the qa-frontpage relatively stateless,
> so it's just reading the tags in debbugs.

Ok, cool!

If I remember correctly, the Data Service provides some lint
information.  We could also imagine a commit-message linter.  However,
the number of tags is rather limited.  Some time ago, we discussed
’usertag’ or else.  Well, what could be done in this area of “automatic”
tagging?


Cheers,
simon

Re: Monthly maintainers' meeting notes

[zimoun]

Hi,

On Tue, 08 Nov 2022 at 12:25, Maxim Cournoyer  wrote:

> [0] https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc
> /maintainers/meetings/2022-11-02.org

Cool!  Thanks.  Just the time to read and…

*** TODO Review #52891 for guix-install.sh [Tobias?]

…already DONE by Mathieu. :-)

Cheers,
simon

Re: Compile skribilo doc containing guix channel references

[zimoun]

Hi Ludo,

On lun., 07 nov. 2022 at 10:21, Ludovic Courtès  wrote:

> In a published paper, it’d be useful to include channel information, and
> Skribilo/Guix integration is one way to do that.  For the convenience of
> people who do not use Guix, some might also find it to include
> approximate package metadata such as name/version pairs, as in that 2015
> paper.

About the channel information to include in a published paper, yeah
Skribilo/Guix is one (non-straightforwardly?) way to get “guix describe
-f channels”. ;-)

Is it possible to have a Skribilo reader which would use less
parenthesis?  Similar to Racket Scribble?

Well, if I understand correctly, «the context of reproducible research
workflows» somehow means using Skribilo as authoring system for
producing “active papers“, right?


Cheers,
simon

PS: About the name/version pairs, are we not trying to explain at length
that it is the wrong way to obtain reproducibility?  Aside it is not
clear what is the depth of name/version pairs to provide when speaking
about reproducibility, no?

Re: Compile skribilo doc containing guix channel references

[zimoun]

Hi Phil,

On dim., 06 nov. 2022 at 22:12, Phil  wrote:

> At the moment compilation is only manual and from inside the repo clone:
> guix environment skribilo guile -- guix repl -- compile-docs.scm

I see.  Interesting as a way to document the channel.  Because I find
hard to write and read Skribilo mark-up format, I would use Org and
org-babel; but that’s another story. :-)

Well, this leads me to 2 questions: :-)

 1. Is it possible to have a reader in the style of Racket Scribble [1]?

 2. Does it make to sense to hook “guix pull” to generate some outputs
 (HTML and Info, say) if the channel contains a specific folder?


1: 

Cheers,
simon

Re: Update on automating testing of patches and qa.guix.gnu.org

[zimoun]

Hi Chris,

Thanks!  Really cool.

On sam., 05 nov. 2022 at 12:24, Christopher Baines  wrote:

>  - The creation of the patch branches is now handled here (rather than
>through scripts run by Laminar)

Is it possible to have access to the branch?  As discussed with Josselin
at 10 Years Days, we could have in mind the workflow:

guix time-machine --url=https://qa.guix.gnu.org \
  --branch=58812\
 -- shell --symlink

for quickly testing a specific patch without going to manually clone,
apply the patch, then run ./bootstrap, ./configure and last use
./pre-inst-env.


> I'm finding this really useful to highlight simple patches which have
> had some testing done automatically. I'd encourage others who are
> interested in merging patches to try looking at the patches showing up
> as green, as hopefully they're in a good state.

Do you expose the list of these green patches?  It could be cool to have
a command line – an option of “guix weather” or a specific CLI – to
collect information of the status.  WDYT?

> If there's any which
> aren't (e.g. needs some changes or more discussion), you can mark it as
> moreinfo to push it down the list (there's a link on the right to do
> this).

Mark it as ’moreinfo’ via Debbugs?  Or something else?


Cheers,
simon

Re: guix pypi-ls

[zimoun]

Hi,

On Sat, 05 Nov 2022 at 12:47, jgart  wrote:

> I have this one off script I call `pypi-ls` for listing tar files on
> standard output from pypi to see if they contain tests:
>
> #!/bin/env sh
>
> exec wget -qO- $1 | tar xvz

Well, I think you can avoid the extraction.  Something like:

   exec wget -qO- $1 | tar tz

I have some tiny Guix script that extract the source URL from a package,
but I am not happy with it.  Other said, from my point of view, the most
annoying part is to form the PyPI URL, i.e., get $1. :-) For instance, I
have something like,

guix download $(guix repl -- pypi.scm pygls@.13) | tar tz

and we could imagine a better UI.  It could be nice to have an
extension, say “guix upstream”, that does some of the left part of the
pipe.


Cheers,
simon

Re: Compile skribilo doc containing guix channel references

[zimoun]

Hi,

On Sat, 05 Nov 2022 at 19:03, Ludovic Courtès  wrote:

>> This generates the docs with guix imports - see compile-command in the 
>> header:
>> https://github.com/quantiletechnologies/qt-guix/blob/feature/EA-133/compile-docs.scm
>>
>> This is the document - it's less ambitious than my internal version in
>> terms of generating content from guix - but has a few examples of
>> generating content from channels:
>> https://github.com/quantiletechnologies/qt-guix/blob/feature/EA-133/qtdocs/qt-guix.skb

I am missing how the Skribilo file is it compiled?  At “guix pull” time?
Or manually when running the script compile-docs.scm?

> Nice!  Including channel info in the document like you do here is
> probably a major use case; it also makes a lot of sense in the context
> of reproducible research workflows.

Ludo, what do you have in mind about reproducible research workflow?


Cheers,
simon

Re: Reproducible Builds Summit 2022

[zimoun]

Hi,

Really cool!  Thank you for the heads-up.

On Thu, 03 Nov 2022 at 15:44, Efraim Flashner  wrote:

>  We should also continue working on implementing a
> change in the ACL to allow requiring a K of N agreement between
> different substitute servers that a build is correct^2.

I am not a specialist about consensus algorithm so maybe I am totally
out of topic.  This K-of-N agreement looks like a Proof of Stake [1].

Well, the problem looks like «Byzantine generals problem» [2] and I do
not know what is the state of the art.  Somehow Paxos [3] algorithm and
variants are often implemented to keep consistent a distributed database
(which is another way to see “different substitute servers”).

Maybe, it could be worth to compare the various approaches… well, if it
has not already been done. :-)

1: 
2: 
3: 


Cheers,
simon

Re: Permanent URL for GUIX packages

[zimoun]

Hi,

On Thu, 03 Nov 2022 at 11:50, Sunshine via "Development of GNU Guix and the GNU 
System distribution."  wrote:

>  guix.gnu.org/packages/monolith-2.6.1/ 

Indeed.  Note this alternative:

https://hpc.guix.info/package/monolith


Cheers,
simon

Re: guix bisect

[zimoun]

Hi,

On Thu, 03 Nov 2022 at 19:18, jgart  wrote:

> do we have something similar to nix-bisect but for guix?
>
> * https://github.com/timokau/nix-bisect

Nothing I am aware.  I mean nothing using ~/.cache/guix/checkouts.

However, it is easy to run the same thing from the development checkout.
I had (still have?) some Bash script for bisecting.

Well, I do not remember and I have not checked if the returned code of
“guix weather” is specified.  If not, it could make the Bash script more
annoying.

Last, this bisection of build failures is already provided by the Data
Service. For instance, see [1].  It currently only uses the Bordeaux
build farm and probably some work to add Berlin but doable, I guess.

1: 
https://data.guix.gnu.org/repository/1/branch/master/package/freecad/output-history


There is many tools from the Nix ecosystem that could be implemented as
Guix extensions.  That’s where Guix shines: it is continuous from core
Guix to package definition or to scripts.

Cheers,
simon

Re: splitting up and sorting commits?

[zimoun]

Hi Liliana,

On Thu, 03 Nov 2022 at 21:59, Liliana Marie Prikler  
wrote:

>  The pauper's solution
> would be to keep a separate "scratch pad" file containing a bunch of
> assorted guix packages, ordered in a way that all packages are defined
> before they're used as inputs – you can easily maintain this order by
> insertion sort.

I did something similar that for some Julia packages, but it can be
tedious depending on the number of packages.  Well, it could be cool to
have something like

guix graph -m some-packages.scm --sort

returning the list of packages sorted (topological order).


Cheers,
simon

Re: Synchronizing the Disarchive databases

[zimoun]

Hi Timothy,

On Tue, 04 Oct 2022 at 12:22, Ludovic Courtès  wrote:

> How could we copy the contents of disarchive.ngyro.com to Guix infra?

A friendly ping. :-)


Cheers,
simon

Re: git guix checkout automation for contributors

[zimoun]

Hi,

I am late to the party. :-)

On Sat, 01 Oct 2022 at 19:18, Ludovic Courtès  wrote:
> Danny Milosavljevic  skribis:
>
>> (1) Install the guix system
>> (2) Log in as regular user
>> (3) guix edit nano
>> (4) It opens a file from /gnu/store that you cannot edit.
>
> At one point, I thought we could have, say:
>
>   guix edit --clone PKG
>
> It would close the channel containing PKG, open the file that defines
> it, and then tell you to run “guix build -L … PKG” to test your changes.
>
> All this would be relatively easy to implement, but it has one downside:
> it doesn’t work for the ‘guix’ channel.
>
> Perhaps we could make it work for the ‘guix’ channel if we arrange so
> that “guix build -L … PKG” doesn’t end up loading all the local
> uncompiled guix/*.scm modules.

Well, does it need to be a Git clone?  Or can it just be a simple copy?

Because using a simple copy, we could imagine,

guix edit --from=PKG --to=DIRECTORY

that extracts the PKG package definition, filling the required
’#:use-module’s and so ready for “guix build -L DIRECTORY PKG”.

On the other hand, a Git clone would allow to prepare a patch almost
ready for submission.


Cheers,
simon

Re: splitting up and sorting commits?

[zimoun]

Hi,

On mer., 02 nov. 2022 at 00:05, Csepp  wrote:

> I'm working on a fairly sizeable MirageOS branch, just getting the
> hello-world kernel running involved adding about 40 packages.  Very
> often I run into a scenario where an imported package needs some other
> package to compile, and then that needs another, and then that another,
> and so on and so on, so by the time I can commit the first I have a
> plethora of new packages that should in theory all get their own
> commits.
> There are two problems with this:
> * Splitting up the commit is a pain, even with git add --patch, because
> hand editing the diff sucks and splitting does not work, possibly due to
> there not being enough space between defines for git's taste.
> * It is very easy for package to get added before their dependencies, so
> even though by the end of the commit chain everything builds perfectly
> fine, there are intermediate commits that can't be tested on their own.
>
> How should one solve this?  I already spent way too much time on a
> script that I foolishly thought would be able to automatically sort
> commits based on their dependencies, but now I'm throwing in the towel,
> it's not getting anywhere.

Well, I do not know if I am answering the questions. :-)

Maybe what you are looking for is ./etc/committer.scm which tries to
split the complete change to small chunks and commit them.

Recently, I was updating Julia packages and I hit something similar.
Well, I have started with “./pre-inst-env guix refresh -u -m
julia-packages.scm” and then “./pre-inst-env ./etc/commiter.scm” which
leads to ~140 commits.  Next, I add the missing packages (committing
them individually) such that the final state just builds and I fix some
tests etc.

Last, I rebase all and edit the history.  Using Magit and Emacs, it is
really straightforward.  The main issue with large change is on one hand
to have that each atomic commit builds fine and on the other hand keep
each commit as atomic as possible.  Well, from my point of view, it is
tradeoff – personally, I am ready to have some commits that do not build
and keep them atomic.

Well, I have also spent too much time trying to find the correct order.
I also tried to an ugly script using the DAG to sort the packages but
then some updates require other specific version… and it is nearly
impossible to satisfy all the constraints.


Cheers,
simon

Re: guix install nyxt failure

[zimoun]

Hi,

On sam., 29 oct. 2022 at 00:59, pierce glenn  wrote:
> For the past few weeks, I have had install failures with nyxt.
>
> I am running guix package manager on the Librem 5 and get the
> following. Always fails when it gets to inkscape. Anyone got pointers?
> I've heard to try --subsitute-urls, but I am already using the
> standard bordeaux and ci.guix. This is only a recent problem. Nyxt
> installed fine a month and a half ago, and I have loaded other
> software through guix without issue.

Currently, substitutes are only available for x86_64-linux and
i686-linux.  For other systems – as Librem 5, I guess – Nyxt is failing,
probably because some dependencies.

However, you report an issue with inkscape when there is no path between
nyxt and inkscape; at least, it is what “guix graph --path nyxt
inkscape” says.

Then, you report,

--8<---cut here---start->8---
  269 | Rect boundsFast() const override {
  |  ^~
 47% [### ]guix install: error: corrupt input while 
restoring archive from socket
 
;;If I try to run again
 
~ $ guix install nyxt
guix install: error: failed to connect to `/var/guix/daemon-socket/socket': 
Connection refused
--8<---cut here---end--->8---

when guix-daemon had been stopped.  And that’s unexpected.


Cheers,
simon

Re: IWBC guix derivation pretty printer

[zimoun]

Hi,

On ven., 28 oct. 2022 at 13:58, jgart  wrote:
> IWBC if we have a guix derivation pretty printer built into the Guix CLI 
> itself.

There is an Emacs mode from the package emacs-guix.  Indeed, it could be
nice to have a pretty printer for derivation.


Cheers,
simon

Re: bug#58859: profile contents depends on package order

[zimoun]

Hi,

On sam., 29 oct. 2022 at 20:47, Attila Lendvai  wrote:

> https://issues.guix.gnu.org/50878

It appears also related to:

http://issues.guix.gnu.org/issue/43585

Cheers,
simon

Re: * TODO Guix json dump all python packages in channel (CLI)

[zimoun]

Hi,

On Mon, 24 Oct 2022 at 22:03, jgart  wrote:

> Wouldn't it be cool if you could do
>
> ```
> guix dump -L my-guix-channel/ --json --filter=py
> ```
>
> I know it's possible by writing Guix API code.

>From my opinion, this perfectly fits a Guix extension.  Well, if you are
interested by the JSON file, you can start by,



where the job is done by the website, see here [1].

1: 



Hope that helps,
simon

Re: Pinning package inputs using inferiors?

[zimoun]

Hi,

On sam., 22 oct. 2022 at 22:58, Felix Lechner via "Development of GNU Guix and 
the GNU System distribution."  wrote:

> While I am relatively new to functional package management, I find it
> inconsistent that inputs in Guix are provided by variables.

What do you mean by « variables »?


> I believe the inputs should be provided by functions that deliver the
> most suitable version of a package. For most packages, that is the
> most recent version unless pinned.

What do you mean by « inputs »?

Currently, the “new” style refers to symbol as inputs which points to
other package definitions.  A package definition somehow defines a
function to build a package.  At this level, it is hard to have a
precise meaning of « suitable version of a package», IMHO.

At the CLI level, packages are referred by their name field and the most
recent version is used by default; unless a specific version as
’@1.2.3’ is appended to the name.


> A package definition would be the list of available versions rather
> than just one version.

What do you build?  Do you build the matrix of all the combinations?

The hard task of a package manager is to provide a set of packages at
their appropriated versions that works well all together.  Aside some
specific cases where the compatibility across version is guarantee, I
miss how a mutli-version definition could work in practise.

Package transformation is somehow a way to implement package definition
for several versions.  It allows to rewrite the function definition
(package) but in the same time to keep under control the combinations.


Cheers,
simon

Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event

[zimoun]

Hi Tanguy,

On dim., 23 oct. 2022 at 17:40, Tanguy LE CARROUR  wrote:

>> guix package --export-manifest > /tmp/my-pkgs.scm
>> guix refresh -m /tmp/my-pkgs.scm 2>&1 | ...
>
> I'm not using manifest (anymore). I used to, but for the time being, I'm using
> `divenv` + `guix shell` and I'm quite happy with that setup.

Note that the first command above creates the manifest for you.
Usually, it works well enough. :-)

Well, ’direnv’ + ’guix shell’ but you have a manifest, no?  I mean how
does ’guix shell’ know what to provide inside this new shell?

For what it is worth, I have used similar workflow but I have been bored
to run “guix pull”, do some stuff unrelated to ’project’, then later be
back on ’project’ and then have failures.  Instead, my workflow is
splited into 2 ways depending on my phase of the Moon.  Either, I create
a profile inside the project directory.  Either, I use channels.scm +
manifest.scm and often run via ’guixify’ script (see below); e.g.,

guixify foo # run foo using the Guix environment
guixify # enter in the environment

Maybe, ’direnv’ would do a better job.  The good point is that
channels.scm and manifest.scm are included in the Git tree of the
project.  And they can be re-used with ’guix pack -f docker -m
manifest.scm’ to generate Docker pack that I can share with colleagues.

--8<---cut here---start->8---
#!/bin/sh

guix time-machine -C channels.scm  \
 -- shell --pure   \
 -m manifest.scm   \
 -- $@
--8<---cut here---end--->8---



Cheers,
simon

Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event

[zimoun]

Hi Tanguy,

On dim., 23 oct. 2022 at 17:48, Tanguy LE CARROUR  wrote:

> ```console
> $ guix package -I | awk '{print $1}' | tr '\n' ' ' | xargs guix refresh 2>&1 \
>   | ag -v '(already|failed|no updater|warning|redirection)'
> ```

This pipe is equivalent to,

guix package --export-manifest > /tmp/my-installed-packages.scm
guix refresh -m /tmp/my-installed-packages.scm 2>&1 \
 | ag -v '(already|failed|no updater|warning|redirection)'

which is, IMHO, more Guixy. ;-)


Cheers,
simon

Re: Pinning package inputs using inferiors?

[zimoun]

Hi Phil,

On Thu, 20 Oct 2022 at 22:37, Phil  wrote:

> A change in a package ("dependency" in the below example) in a channel I
> own has caused a conflict in another package in the same channel that depends
> on it ("test-package" in the below).  Whilst fixing the "test-package"
> package is the right solution, this is too complicated in do in the
> short-term.  I need to pin "dependency" to v1.0 in test-pacakge's
> propagated-inputs. Simultaneously, other packages need the new update to
> the "dependency" package to use this functionality to deliver new
> functionality that can't wait.
>
> This isn't a one-off situation; this happens frequently and I'm
> interested in how other Guixers resolve this with as little friction to
> users as possible?

Well, I answer to this question and I do not answer to your question
about inferior…

> One brainwave I had was to use inferiors - but this doesn't seem to
> work.  Continuing from the above example we could define access to a
> historical v1.0 of the dependency package for the test-package like so:
>
> (define dependency-inferior
>   ;; An inferior containing dependency v1.0.
>   (inferior-for-channels dependency-channels))

…instead of defining a complete inferior, why not just define 2
packages.  Something as,

(define-public foo
  (package
(name "foo")
(version "2.0")
[...]


(define-public foo-1.6
  (package
(inherit foo)
(name "foo")
(version "1.6")
[...]

For an example, see python-numpy and python-numpy-next in (gnu packages
python-xyz).

Note that most CLI as “guix install foo” will install the last version.
Hence the ’-next’ trick in the package name. :-)  Depending what you
would like to be the “default“.


Cheers,
simon