Clozure size

[zimoun]

Dear,

On Mon, 16 Nov 2020 at 01:54, Ryan Prior  wrote:

> For example, `docker size python` shows a 171.4mb bundle size just for

How is the Docker image built?

> Python alone, while `docker images python:alpine` shows a 44.3mb
> system

Idem?

I agree with your argument, I am just wondering if apples are compared
to apples. :-)


> image, which includes a bunch of system stuff in addition to Python. It
> would be great to have tools to understand what's in our big Guix
> packages and how we could ship light bundles that get the job done.

Well, the closure is sometimes an issue, indeed.  The tools to tackle
this are “guix size” and “guix graph”, AFAIK.  What do you think is
missing?


All the best,
simon

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Maxim Cournoyer]

Hello Christopher,

CC'ing Ludovic since they had that problem as well, so might be
interested in testing your solution.

Christopher Lemmer Webber  writes:

[...]

> I figured out what was happening!  The bug is *technically* in vc-mode.
> However, nontheless it manifested here...
>
> Here's what happened.  vc-mode has some various hacks, as you can see
> above with "hack-local-variables-apply"... which traverses the dirlocals
> stuff.  (Not sure what the purpose is, didn't look too long.)
>
> However for whatever reason, vc-mode also seems to be reusing buffers
> such as `*vc-diff*'... and somehow still is left in the directory
> context it *first* was used in.
>
> Thus if I C-x v = in a guix-oriented buffer first, and then switch to
> another completely different project and do the same, it's loading the
> dirlocals from Guix(...)
>
> This is clearly a bug in vc-mode, I'll try to report it as such.

Thank you for the investigation.  I'd be really happy if you could
report the problem upstream (M-x report-emacs-bug) and link to it here!
Be sure to include a very detailed description of how to reproduce; I
for one still am unable to reproduce with the above instructions.  I've
tried many ways, using a pure environment, not loading my Emacs init
file, etc. based on what Miguel had written in IRC at the time of the
initial report, but to no avail.

> In the meanwhile, I used this hacky "fix".  Maybe worth applying for the
> moment... what do you think of it?

I'd like to have the upstream bug linked in that fix rather than the
Guix one; that way it'll be possible to track upstream resolution and
know when the workaround can be removed.

> #+BEGIN_SRC diff
> diff --git a/.dir-locals.el b/.dir-locals.el
> index 8e5d3902e3..2aa446a4f6 100644
> --- a/.dir-locals.el
> +++ b/.dir-locals.el
> @@ -17,17 +17,19 @@
>   ;; Geiser
>   ;; This allows automatically setting the `geiser-guile-load-path'
>   ;; variable when using various Guix checkouts (e.g., via git worktrees).
> - (eval . (let* ((root-dir (expand-file-name
> -   (locate-dominating-file
> -default-directory ".dir-locals.el")))
> -;; Workaround for bug https://issues.guix.gnu.org/43818.
> -(root-dir* (directory-file-name root-dir)))
> -   (unless (boundp 'geiser-guile-load-path)
> - (defvar geiser-guile-load-path '()))
> -   (make-local-variable 'geiser-guile-load-path)
> -   (require 'cl-lib)
> -   (cl-pushnew root-dir* geiser-guile-load-path
> -   :test #'string-equal)
> + (eval . (let ((root-dir-unexpanded (locate-dominating-file
> + default-directory 
> ".dir-locals.el")))
> +   (when root-dir-unexpanded
> + (let* ((root-dir (expand-file-name root-dir-unexpanded))
> +;; Workaround for bug 
> https://issues.guix.gnu.org/43818.
> +(root-dir* (directory-file-name root-dir)))
> +
> +   (unless (boundp 'geiser-guile-load-path)
> + (defvar geiser-guile-load-path '()))
> +   (make-local-variable 'geiser-guile-load-path)
> +   (require 'cl-lib)
> +   (cl-pushnew root-dir* geiser-guile-load-path
> +   :test #'string-equal)))
>
>   (c-mode  . ((c-file-style . "gnu")))
>   (scheme-mode
> #+END_SRC
>
> Btw, I'm not very familiar with dirlocals.  I see that setq is used in
> the previous definition.  Woudl setq-local be better... or does it do
> that by default?

Good observation.  The `guix-directory' is set globally.  It could be
neater if we made it also a buffer-local variable like the
`geiser-guile-load-path' below.

Thank you for having persevered in understanding the root cause of the
issue you had, and sharing the details here.

Maxim

Re: Guix now compiles on my Talos II, but download fails

[Maxim Cournoyer]

Hi!

Tobias Platen  writes:

> On Mon, 9 Nov 2020 22:13:52 +0100
> Tobias Platen  wrote:
>
>> I checked out the wip-ppc branch which I compiled on my Talos II.
>
> Guix now runs and is able to download files and put them in the store.
>
> ./pre-inst-env guix download https://ftp.gnu.org/gnu/guix/guix-1.1.0.tar.gz
> works, but other commands that download files do not work, with the following 
> error message:
>
> building /gnu/store/gcsaa54nd7mfggxdrn9bgmb4gw4ai4hl-hello-2.10.tar.gz.drv...
> error: failed to run download program 
> '/home/user/guix-ppc/guix/scripts/guix': Permission denied
> builder for 
> `/gnu/store/gcsaa54nd7mfggxdrn9bgmb4gw4ai4hl-hello-2.10.tar.gz.drv' failed 
> with exit code 1
> build of /gnu/store/gcsaa54nd7mfggxdrn9bgmb4gw4ai4hl-hello-2.10.tar.gz.drv 
> failed
> View build log at 
> '/usr/local/var/log/guix/drvs/gc/saa54nd7mfggxdrn9bgmb4gw4ai4hl-hello-2.10.tar.gz.drv.gz'.
> cannot build derivation 
> `/gnu/store/n4r9d1rxw6091s878wz7p6658mdzpjzj-hello-2.10.drv': 1 dependencies 
> couldn't be built
> guix build: error: build of 
> `/gnu/store/n4r9d1rxw6091s878wz7p6658mdzpjzj-hello-2.10.drv' failed

Well done, Tobias!

I'm excited to see how things will go from there :-).

Maxim

Re: A plan for parameterized packages

[Ryan Prior]

On November 15, 2020, raingloom  wrote:
> Alpine already achieves an incredibly tiny install size by splitting
> packages into many outputs. We could and should do the same.
> As far as I know, they do not have parameterized packages.

I definitely support more package-splitting and dependency tree-shaking
where possible. Getting a core Guix System down to Alpine size would be
fantastic.

For example, `docker size python` shows a 171.4mb bundle size just for
Python alone, while `docker images python:alpine` shows a 44.3mb system
image, which includes a bunch of system stuff in addition to Python. It
would be great to have tools to understand what's in our big Guix
packages and how we could ship light bundles that get the job done.

Re: GNU Guix 1.2.0rc1 available for testing!

[Oleg Pykhalov]

Hello,

Yeeeho!  I've installed Guix 1.2.0rc1 system on a KVM virtual machine.


1. Because of DHCP server is not exist on a network I cannot use TUI
installer.

When I installed via shell, I need manually stop “networking” service
with herd.  Otherwise “ip address” shows “169.254.182.22/16” assigned to
“eht0” and “ip route” shows “default dev eth0 scope link” which breaks a
network on automatically before “guix system init”.


2. “emacs-guix” is broken out of the box, because of incompatible
“geiser”.  On my machine I have a dirty hack with “module-set!”, but I
assume we could specify “emacs-geiser-0.10” in “propagated-inputs” until
somebody have a fix :-) , but it will trigger errors if you will want to
install “emacs-geiser” in the same profile AFAIK.

--8<---cut here---start->8---
(define-public emacs-geiser-0.10
  (package
(inherit emacs-geiser)
(version "0.10")
(source (origin
 (method url-fetch)
 (uri (string-append "mirror://savannah/geiser/" version
 "/geiser-" version ".tar.gz"))
 (sha256
  (base32
   "0pj3l7p8d60c9b4vfprnv6g5l61d74pls4b5dvd84cn4ky9mzwjv"))

(module-set! (resolve-module '(gnu packages emacs-xyz)) 'emacs-geiser 
emacs-geiser-0.10)
--8<---cut here---end--->8---


Regardless,
Oleg.


signature.asc
Description: PGP signature

Re: GNU Guix 1.2.0rc1 available for testing!

[pelzflorian (Florian Pelz)]

On Sun, Nov 15, 2020 at 10:53:29PM +0100, Marius Bakke wrote:
> I have just installed a system using manual partitioning through the
> installer, with encryption.  Everything worked like a charm.
> 
> Can you provide more details about the steps you did to arrive at the
> error?  And information about the (new and old) partition layout?

Thank you for trying.  Hmm strange.  I tried once again (I think I did
the same steps as before) and it worked.  Maybe I forgot something?
Maybe it depends on how fast the machine completes a formatting task?
So I tried again two more times and it failed again, I got the error
again both times during partition formatting.

So all the partitioning is already done except for the encryption.
/dev/sdc is the install USB drive.  /dev/sda is the hard disk.
/dev/sda1 is the EFI system partition; I do not format it.  /dev/sda5
is the partition I try to put the encrypted root fs on.  I check
encryption and set its mount point to “/”.

/var/log/messages has the following log for the installer:

Nov 15 23:49:30 localhost installer[259]: Display is 128x42. 
Nov 15 23:49:30 localhost installer[259]: running step 'locale' 
Nov 15 23:49:30 localhost installer[259]: running step 'language' 
Nov 15 23:49:31 localhost installer[259]: running form # 
("Locale language") with 0 clients 
Nov 15 23:49:40 localhost vmunix: [   56.102132] tg3 :03:00.0 enp3s0: Link 
is down
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {RX} 24 packets 3438 bytes
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {TX} 31 packets 3795 bytes
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {update} flags 36867 
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {newlink} index 2 address 
10:9A:DD:46:4F:9F mtu 1500
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {newlink} index 2 operstate 2 

Nov 15 23:49:40 localhost nscd: 211 monitored file `/etc/resolv.conf` was 
written to
Nov 15 23:49:40 localhost nscd: 211 monitored file `/etc/resolv.conf` was 
written to
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {del} address 192.168.178.74/24 
label enp3s0
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {del} route 192.168.178.0 gw 
0.0.0.0 scope 253 
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {del} route fd00:: gw :: scope 
0 
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {del} route fe80:: gw :: scope 
0 
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {del} address 
fd00::129a:ddff:fe46:4f9f/64 label (null)
Nov 15 23:50:23 localhost installer[259]: running step 'territory' 
Nov 15 23:50:23 localhost installer[259]: running form # 
("Locale location") with 0 clients 
Nov 15 23:50:26 localhost installer[259]: running step 'codeset' 
Nov 15 23:50:26 localhost installer[259]: running step 'modifier' 
Nov 15 23:50:26 localhost shepherd[1]: Service console-font-tty2 has been 
stopped. 
Nov 15 23:50:26 localhost shepherd[1]: Service term-tty2 has been stopped. 
Nov 15 23:50:26 localhost shepherd[1]: Service host-name has been started. 
Nov 15 23:50:26 localhost shepherd[1]: Service term-tty2 has been started. 
Nov 15 23:50:26 localhost installer[259]: running step 'welcome' 
Nov 15 23:50:26 localhost installer[259]: running form # 
("GNU Guix install") with 0 clients 
Nov 15 23:50:27 localhost installer[259]: running step 'timezone' 
Nov 15 23:50:27 localhost installer[259]: running form # 
("Timezone") with 0 clients 
Nov 15 23:50:32 localhost installer[259]: running form # 
("Timezone") with 0 clients 
Nov 15 23:50:34 localhost installer[259]: running step 'keymap' 
Nov 15 23:50:34 localhost installer[259]: running step 'layout' 
Nov 15 23:50:34 localhost installer[259]: running form # 
("Layout") with 0 clients 
Nov 15 23:50:36 localhost installer[259]: running step 'variant' 
Nov 15 23:50:36 localhost installer[259]: running form # 
("Variant") with 0 clients 
Nov 15 23:50:41 localhost installer[259]: running step 'hostname' 
Nov 15 23:50:41 localhost installer[259]: running form # 
("Hostname") with 0 clients 
Nov 15 23:50:53 localhost installer[259]: running step 'network' 
Nov 15 23:50:53 localhost installer[259]: running step 'select-technology' 
Nov 15 23:50:53 localhost installer[259]: running step 'power-technology' 
Nov 15 23:50:54 localhost installer[259]: running step 'connect-service' 
Nov 15 23:50:54 localhost installer[259]: running form # ("No 
service") with 0 clients 
Nov 15 23:51:00 localhost vmunix: [  135.760473] tg3 :03:00.0 enp3s0: Link 
is up at 100 Mbps, full duplex
Nov 15 23:51:00 localhost vmunix: [  135.760478] tg3 :03:00.0 enp3s0: Flow 
control is on for TX and on for RX
Nov 15 23:51:00 localhost vmunix: [  135.760598] IPv6: ADDRCONF(NETDEV_CHANGE): 
enp3s0: link becomes ready
Nov 15 23:51:00 localhost connmand[210]: enp3s0 {add} route fe80:: gw :: scope 
0 
Nov 15 23:51:00 localhost connmand[210]: enp3s0 {RX} 24 packets 3438 bytes
Nov 15 23:51:00 localhost connmand[210]: enp3s0 {TX} 31 packets 3795 bytes
Nov 15 23:51:00 localhost connmand[210]: enp3s0 {update} flags 102467 

Nov

Re: GNU Guix 1.2.0rc1 available for testing!

[Marius Bakke]

"pelzflorian (Florian Pelz)"  writes:

> On Fri, Nov 13, 2020 at 06:07:32PM +0100, Ludovic Courtès wrote:
>>   system installation:
>> […]
>> 
>> https://alpha.gnu.org/gnu/guix/guix-system-install-1.2.0rc1.x86_64-linux.iso.xz
>
> Sorry for testing so late.  For me the graphical installer crashes
> when doing a Manual Partitioning with an encrypted partition.
> I attach the last-installer-error after Manual Partitioning.
>
> Can others successfully use encryption with the installer?

I have just installed a system using manual partitioning through the
installer, with encryption.  Everything worked like a charm.

Can you provide more details about the steps you did to arrive at the
error?  And information about the (new and old) partition layout?


signature.asc
Description: PGP signature

Re: Release: Docker Image? DockerHub? skopeo?

[zimoun]

Hi Danny,

Sorry to be late.

On Wed, 04 Nov 2020 at 15:50, Danny Milosavljevic  
wrote:

>> Some days ago, we discussed on #guix about releasing Docker images
>> ready-to-use.  And you pointed your project:
>> 
>>   https://gitlab.com/daym/guix-on-docker/

[...]

> For the use case I'm using it for, guix-on-docker is final now.
> I doubt that I'll change anything in it, and certainly nothing major.

I have simply tried:

   docker run -d --name guix registry.gitlab.com/daym/guix-on-docker
   docker exec guix guix pack hello

Wow!  The image is huge:

5.23GB registry.gitlab.com/daym/guix-on-docker latest 884b4a4ddf61 

Is it expected?   BTW, I am noting that there are couple of layers:

 "RootFS": {
 "Type": "layers",
 "Layers": [
 
"sha256:c3deb477b7310360aaa445de77aa7c16f4cee76db5163c2c70573f49b2b26943",
 
"sha256:8128b7241acd71f13fc7bdcc5cda139e0ab75a2a987db6268d8d0f74b0974fe9",
 
"sha256:ba90a34fcea86f444a3ceb192ad2b6ad2d1ba86c1df4e9b4746114d86472f1a8",
 
"sha256:c2f9dceb24a4df38f7e708db969792ac3061270f6322411b503c347ff98399b0",
 
"sha256:39e027c52cb13e22b7b2a729b07e23f3574662ee482fb5c09b42c6cf51020cf6",
 
"sha256:5a938600c9db6ce11a1e561b2c57448a70ebeb82539276afead86bc44319",
 
"sha256:541970bba9516720676f088c629ff12048ce478a2bd5e2b7da21c50feaa619f1",
 
"sha256:3cc6fdb7c0cc6b5bca938df9a5fa03fe3438333f3c9f686f8a90b1fc785ff07f",
 
"sha256:298ab852047104192cc6c5347154843f3669810c215377bcc280dbfb89277708",
 
"sha256:a5a94f3837bafc49d54ef88f98eb3e162e78248c8b055ab17fd057b2d57d6d2e",
 
"sha256:697ddc7e64d6cd06293d0840abc4876c3f27fccc70e35efd4f07d84d0e3e6d63" 
 ]
 },

I am not sure to understand why.  It reminds me this previous thread:



Well, I do not know.


Then, the ’docker exec’ downloads \o/ and then fails with:

  guix pack: error: getting status of `/tmp': No such file or directory

Hum, as in the other message, I am sure I am missing the obvious with
Docker options.


> Right now, my gitlab project automatically tracks guix from git master on
> savannah and rebuilds that and pushes the result to gitlab's docker
> registry (every time someone commits to guix master).
>
> If we wanted the gitlab project to track a release tag, we'd have to
> configure it to do building from a tag, too.  If so, please tell me.

Currently, it builds master, right?  I have not looked but do you think
it could possible to track the both branches master and version-1.x.y?


Thanks,
simon

Re: A plan for parameterized packages

[raingloom]

On Sun, 15 Nov 2020 21:46:58 +0100
Danny Milosavljevic  wrote:

> Hi Ludo,
> 
> nice feature!
> 
> On Sun, 15 Nov 2020 17:33:28 +0100
> Ludovic Courtès  wrote:
> 
> > An important question: do we have examples of packages for which
> > we’d like to have parameters?
> 
> For the embedded/flash rom side:
> 
> * Enable/disable building the documentation.  I really don't need a
> 40 MiB manual stored onto a 16 MiB firmware flash chip.  If that's
> better done as an extra output, fair enough.
> ..

Alpine already achieves an incredibly tiny install size by splitting
packages into many outputs. We could and should do the same.
As far as I know, they do not have parameterized packages.

Re: A plan for parameterized packages

[zimoun]

Dear,

On Sun, 15 Nov 2020 at 21:46, Danny Milosavljevic  
wrote:

> * Enable/disable building the documentation.  I really don't need a 40 MiB
> manual stored onto a 16 MiB firmware flash chip.  If that's better done as an
> extra output, fair enough.

Related (I hope) is: build packages with several outputs.  For instance,
’git’ has several 'outputs' ("send-email", "svn", etc.), so the list of
"inputs" provides e.g., "subversion" even if I am only interested by
e.g., "git:send-email".  This matters about closure.

And it is maybe an occasion to revisit the museum, i.e., the TODO file:

** 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

For one reference:

  


All the best,
simon

Re: A plan for parameterized packages

[Danny Milosavljevic]

Hi Ludo,

nice feature!

On Sun, 15 Nov 2020 17:33:28 +0100
Ludovic Courtès  wrote:

> An important question: do we have examples of packages for which we’d
> like to have parameters?

For the embedded/flash rom side:

* Enable/disable building the documentation.  I really don't need a 40 MiB
manual stored onto a 16 MiB firmware flash chip.  If that's better done as an
extra output, fair enough.

* Enable/disable obscure dependencies: Library packages that pull in 400 MiB Qt
into the closure for a thing no one (TM) uses should probably provide a switch 
to
disable that GUI.  Sometimes a package provides multiple GUIs for different
toolkits, in which case one should be able to choose one toolkit and not
build for the others.

* No, even in 2020, I won't start using AmigaFS, NFSv3 and whatever old
protocol/format is still around and superseded by other protocols.

The gexp-functionality of being able to select individual files of a package
is already very useful for use cases an embedded developer would have
(and that's there for a long time already).  So that's nice!

For the kind of feature flags I have in mind, it usually means I don't want
to have the feature *anywhere*--for example, if I don't want to have Qt or
Kerberos or whatever, that's because I want to save the space and thus
it should be able to be *globally* specified--at least per profile.

It doesn't help one bit for space savings if package A doesn't pull in
Kerberos or latex or or Haskell bindings for a Raspberry Pi serial port
library (guess why that's oddly specific ;) ), but package B does.

However, sometimes using static libraries is better and there's no reason to
build the shared libraries.  But that's very much local to whatever I'm
trying to do (at least local to a profile if not package).

I would advise against doing a grep -r -- --enable and introducing all those
as parameters.  Rather I would check the closure of stuff and if the closure
goes from 1200 MiB to 50 MiB, chances are a parameter would be nice there :)

I guess the kind of flags I envision would be set at profile level.

From experience with Gentoo before I can tell you that the combinatory
explosion is a real problem and most of the "more advanced" (toggled more
switches :) ) combinations did not work the majority of the time.


pgpick5BhadGn.pgp
Description: OpenPGP digital signature

Re: GNU Guix 1.2.0rc1 available for testing!

[pelzflorian (Florian Pelz)]

On Fri, Nov 13, 2020 at 06:07:32PM +0100, Ludovic Courtès wrote:
>   system installation:
> […]
> 
> https://alpha.gnu.org/gnu/guix/guix-system-install-1.2.0rc1.x86_64-linux.iso.xz

Sorry for testing so late.  For me the graphical installer crashes
when doing a Manual Partitioning with an encrypted partition.
I attach the last-installer-error after Manual Partitioning.

Can others successfully use encryption with the installer?

Regards,
Florian
In ./gnu/installer/newt/partition.scm:
785:4 19 (run-partitioning-page)
In srfi/srfi-1.scm:
634:9 18 (for-each # ("/dev/sda" "/dev/sdb"))
In ./gnu/installer/parted.scm:
  1395:23 17 (_ _)
In ice-9/boot-9.scm:
  1669:16 16 (raise-exception _ #:continuable? _)
  1667:16 15 (raise-exception _ #:continuable? _)
  1667:16 14 (raise-exception _ #:continuable? _)
  1667:16 13 (raise-exception _ #:continuable? _)
  1667:16 12 (raise-exception _ #:continuable? _)
  1667:16 11 (raise-exception _ #:continuable? _)
  1667:16 10 (raise-exception _ #:continuable? _)
  1667:16  9 (raise-exception _ #:continuable? _)
  1667:16  8 (raise-exception _ #:continuable? _)
  1667:16  7 (raise-exception _ #:continuable? _)
  1764:13  6 (_ #<&compound-exception components: (#<&error> #<&origin origin: 
#f> #<&message message: "~A"> #<&irritants irritants: ("Device /dev/sda is 
still in use.")> #<&exception-with-kind-an…>)
In ice-9/eval.scm:
619:8  5 (_ #(#(# #< name: 
newt init: # exit: # exit-error: 
# f…>) …))
619:8  4 (_ #(#(#(# #< 
name: newt init: # exit: # exit-error: 
#) …) #))
In ice-9/ports.scm:
   463:17  3 (call-with-output-file _ _ #:binary _ #:encoding _)
In ice-9/eval.scm:
619:8  2 (_ #(#(# misc-error (#f "~A" 
("Device /dev/sda is still in use.") #f)) #))
159:9  1 (_ #(#(# misc-error (#f "~A" 
("Device /dev/sda is still in use.") #f)) #))
In unknown file:
   0 (make-stack #t)
ice-9/eval.scm:159:9: Device /dev/sda is still in use.

Re: A plan for parameterized packages

[Taylan Kammer]

An important question: do we have examples of packages for which we’d
like to have parameters?  I’d grepped for “inherit” and that yields a
few potential candidates, but also maybe a few potential non-candidates.
Would this be a good fit for them?


I suppose Emacs would be an obvious candidate, with its "no-x" as well 
as "no-x-toolkit" variants.



Taylan

Re: Releasing guix binary in Docker format too?

[zimoun]

Hi,

>> >  guix pack guix -f docker -S /bin=bin \
>> >--entry-point="bin/guix-daemon --disable-chroot"

[...]

>> > Someone needs to try because the devil is in the details.  
>> 
>> I will try to give a try.  If someone does not beat me.
>
> Please do.

I did and probably am lost in Docker details (the mentioned devil? ;-))

--8<---cut here---start->8---
$ docker load < \
> $(guix time-machine --branch=version-1.2.0 \
> -- pack guix -f docker -S /bin=bin  --entry-point="bin/guix-daemon")
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Loaded image: guix:latest

$ docker images --format "{{.Repository}} {{.Tag}} {{.ID}} {{.Size}}"
guix latest 7a99e79f803c 502MB

$ docker run -d --name guix guix:latest
7ecfb3311619d1265f1e91a45f587b28e3017c39735c9527b91bac5b0d5d49e1

$ docker ps
7ecfb3311619 guix:latest "/gnu/store/62iy7phi…" 5 seconds ago Up 4 seconds guix

$ docker exec guix guix pack hello
user with UID 0 not found
substitute: guix substitute: warning: ACL for archive imports seems to be 
uninitialized, substitutes may be unavailable
substitute: guix substitute: warning: ci.guix.gnu.org: host not found: Servname 
not supported for ai_socktype
The following derivations will be built:
   /gnu/store/p8w0ickl7n4psa5rkybx0q856phzxmpp-glibc-utf8-locales-2.31.drv

[...]

   /gnu/store/ll89ynpa8xrk2q4fvyg2aj8ig98w4zls-mkfontdir-1.0.7.tar.bz2.drv

building 
/gnu/store/wj0dnfmik81160y3zf85qf5hvkp2x1hi-libX11-1.6.10.tar.bz2.drv...
builder for 
`/gnu/store/wj0dnfmik81160y3zf85qf5hvkp2x1hi-libX11-1.6.10.tar.bz2.drv' failed 
with exit code 1
build of /gnu/store/wj0dnfmik81160y3zf85qf5hvkp2x1hi-libX11-1.6.10.tar.bz2.drv 
failed
View build log at 
'/var/log/guix/drvs/wj/0dnfmik81160y3zf85qf5hvkp2x1hi-libX11-1.6.10.tar.bz2.drv.bz2'.
building /gnu/store/4d3cjvjrgs0q38fs3bgfajcw7apc0vml-Python-3.5.9.tar.xz.drv...
cannot build derivation 
`/gnu/store/mvf88n2v90jjxg9n8b315p22r6jrkbyb-libx11-1.6.A.drv': 1 dependencies 
couldn't be built
killing process 29
guix pack: error: build of 
`/gnu/store/mvf88n2v90jjxg9n8b315p22r6jrkbyb-libx11-1.6.A.drv' failed
--8<---cut here---end--->8---

I have tried various Docker option and I have failed to figure out the
correct one.  I should miss the obvious.  My eyes are a bit tired these
days.  Any hint?


BTW, the tool skopeo failed in the branch version-1.2.0 as ’weather’
confirms.  Therefore the Cookbook recipe will be for the next release.

Cheers,
simon

Re: A plan for parameterized packages

[zimoun]

Hi Pierre,

On Sun, 15 Nov 2020 at 18:44, Pierre Neidhardt  wrote:

> For instance, what if we want to build "all packages without X support"?
> This means that the parameter must traverse all inputs recursively if we
> don't want to drag X indirectly.

It means: add this new ’optionally’ to all the packages supporting X to
be able to turn it off with the ’boolean’ type.  IIUC.


> If I understand your change correctly, the patch is only applying
> parameters to the given package and it's not propagated to the inputs,
> is that correct?

Because of ’package-input-rewriting/spec’, it is applied to all the
graph,  IIUC.

Cheers,
simon

Re: A plan for parameterized packages

[zimoun]

Hi Lduo,

On Sun, 15 Nov 2020 at 17:33, Ludovic Courtès  wrote:

> That said, this message is about a possible implementation of package
> parameters, so here we go.  :-)

Cool!


> To me the requirements for package parameters are:
>
>   1. it must be possible to discover them and choose them from the UI;
>
>   2. they must contain on-line internationalized documentation such that
>  the UI can list a package’s parameters and their type;

Except ’boolean’, which kind of type do you have in mind?  Aside that
you did not find examples of packages requiring parameters. ;-)

The answer leads to your point #4.


>   3. the chosen parameters when installing a package in a profile must
>  be preserved;

You mean track the parameters with ’properties’ in /manifest,
right?


>   4. it must be possible to enumerate all the possible values of a
>  parameter, and thus to build the Cartesian product of all the
>  possible parameter combinations of a package (or of a package
>  graph!), so we can test those combinations as much as possible.

The values of the option are therefore known at package time, right?
However, this implies restricted possibility for the type, right?


> Subject: [PATCH 1/4] DRAFT Add (guix parameters).
>
> DRAFT: Missing tests & doc.
>
> * guix/parameters.scm: New file.
> * Makefile.am (MODULES): Add it.
> ---

[...]

> diff --git a/guix/parameters.scm b/guix/parameters.scm
> +
> +;; Type of a package parameter.
> +(define-record-type*  parameter-type
> +  make-parameter-type
> +  parameter-type?
> +  (name  parameter-type-name)  ;debugging purposes only!
> +  (string->value parameter-type-string->value)
> +  (value->string parameter-type-value->string)
> +  (universe  parameter-type-universe))
> +
> +(define boolean
> +  ;; The Boolean parameter type.
> +  (parameter-type (name 'boolean)
> +  (universe '(#true #false))
> +  (value->string
> +   (match-lambda
> + (#f "false")
> + (#t "true")))
> +  (string->value
> +   (lambda (str)
> + (cond ((string-ci=? str "true")
> +#t)
> +   ((string-ci=? str "false")
> +#f)
> +   (else
> +(raise (condition
> +(&message (message "wrong 
> value"))

The types will be “hard-coded“ here, right?  Boolean being the simplest
example and imagination just needs to be released, right? :-)



> Subject: [PATCH 2/4] DRAFT transformations: Add '--with-parameter'.
>
> DRAFT: Missing tests & doc.
>
> * guix/transformations.scm (evaluate-parameter-specs)
> (transform-package-parameters): New procedures.
> (%transformations, %transformation-options): Add 'with-parameter'.
> ---
>  guix/transformations.scm | 39 +++
>  1 file changed, 39 insertions(+)
>
> diff --git a/guix/transformations.scm b/guix/transformations.scm

[...]

> +(define (evaluate-parameter-specs specs proc)
> +  "Parse SPECS, a list of strings like \"bitlbee=purple=true\", and return a
> +list of spec/procedure pairs, where (PROC PACKAGE PARAMETER VALUE) is called
> +to return the replacement package.  Raise an error if an element of SPECS 
> uses
> +invalid syntax, or if a package it refers to could not be found."
> +  (map (lambda (spec)
> + (match (string-tokenize spec %not-equal)
> +   ((spec name value)
> +(define (replace old)
> +  (proc old name value))
> +
> +(cons spec replace))
> +   (_
> +(raise
> + (formatted-message
> +  (G_ "invalid package parameter specification: ~s")
> +  spec)
> +   specs))

Here ’proc’ could be anything, right?  But then…

> +(define (transform-package-parameters replacement-specs)
> +  "Return a procedure that, when passed a package, replaces its direct
> +dependencies according to REPLACEMENT-SPECS.  REPLACEMENT-SPECS is a list of
> +strings like \"guile-next=stable-3.0\" meaning that packages are built using
> +'guile-next' from the latest commit on its 'stable-3.0' branch."
> +  (define (replace old name value)
> +(set-package-parameter-value old name value))
> +
> +  (let* ((replacements (evaluate-parameter-specs replacement-specs
> + replace))
> + (rewrite  (package-input-rewriting/spec replacements)))
> +(lambda (obj)
> +  (if (package? obj)
> +  (rewrite obj)
> +  obj

… it is ’set-package-parameter-value’.  It is not clear in my mind.
Does this constrain the hypothetical types?


Cheers,
simon

Re: A plan for parameterized packages

[Pierre Neidhardt]

Fantastic!

One of the biggest struggle we had when discussing it was figuring out
what to do about parameter propagation across dependencies.

For instance, what if we want to build "all packages without X support"?
This means that the parameter must traverse all inputs recursively if we
don't want to drag X indirectly.

If I understand your change correctly, the patch is only applying
parameters to the given package and it's not propagated to the inputs,
is that correct?

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: A plan for parameterized packages

[Nicolò Balzarotti]

More in general, grepping for `--enable` or `--with` flags shows
a lot of potential packages (but also many false positives).


Nicolò Balzarotti  writes:

> Neat! Thanks for working on it :)
>
>> An important question: do we have examples of packages for which we’d
>> like to have parameters?  I’d grepped for “inherit” and that yields a
>> few potential candidates, but also maybe a few potential non-candidates.
>> Would this be a good fit for them?
>
> What about evince?  eps/ps/dvi rendering is disabled, according to this
> thread [1] for security reasons, so it makes sense to have it disabled
> by default.  But I'd like to be able to enable it easily.
>
> WDYT?
>
> Nicolò
>
> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39674
>
> Ludovic Courtès  writes:
>
>> Hello Guix!
>>
>> For some time we’ve discussed ways to achieve “parameterized
>> packages”—packages where one can from the command line or from Scheme
>> configure optional build-time features, similar to Gentoo “USE flags”.
>>
>> I still have mixed feeling about this feature: on one hand it can bring
>> much welcome flexibility, but on the other hand it can also lead us to
>> the wild west of untested package configurations and combinatorial
>> explosion.  It could also be argued that we achieve something similar
>> today by simply defining package variants when we have to:
>>
>>   
>> https://guix.gnu.org/manual/devel/en/html_node/Defining-Package-Variants.html
>>
>> That said, this message is about a possible implementation of package
>> parameters, so here we go.  :-)
>>
>> To me the requirements for package parameters are:
>>
>>   1. it must be possible to discover them and choose them from the UI;
>>
>>   2. they must contain on-line internationalized documentation such that
>>  the UI can list a package’s parameters and their type;
>>
>>   3. the chosen parameters when installing a package in a profile must
>>  be preserved;
>>
>>   4. it must be possible to enumerate all the possible values of a
>>  parameter, and thus to build the Cartesian product of all the
>>  possible parameter combinations of a package (or of a package
>>  graph!), so we can test those combinations as much as possible.
>>
>> This leads to the patches below.  The last one gives an example use for
>> Bitlbee: it adds a “libpurple” parameter that allows users to choose
>> whether or not to enable the optional libpurple dependency:
>>
>> --8<---cut here---start->8---
>> $ ./pre-inst-env guix build bitlbee --with-parameter=bitlbee=libpurple=true 
>> -n
>> The following derivation would be built:
>>/gnu/store/mkknqgjsa93ajcl5d2krngizb11j1b0q-bitlbee-3.6.drv
>> $ ./pre-inst-env guix build bitlbee --with-parameter=bitlbee=libpurple=false 
>> -n
>> /gnu/store/c2ckg51ffwgs6jni3l549k06w3jd3b7a-bitlbee-3.6
>> $ ./pre-inst-env guix build bitlbee --with-parameter=bitlbee=libpurple=wat? 
>> -n
>> guix build: error: wrong value
>> $ ./pre-inst-env guix build bitlbee --with-parameter=bitlbee=libviolet=true 
>> -n
>> gnu/packages/messaging.scm:283:5: error: libviolet: no such package parameter
>> $ ./pre-inst-env guix show bitlbee
>> name: bitlbee
>> version: 3.6
>> outputs: out
>> parameters: libpurple
>> systems: x86_64-linux i686-linux
>> dependencies: check@0.12.0 glib@2.62.6 gnutls@3.6.12 libotr@4.1.1 
>> perl@5.30.2 pkg-config@0.29.2 python@3.8.2
>> location: gnu/packages/messaging.scm:243:2
>> homepage: https://www.bitlbee.org/
>> license: GPL 2+, FreeBSD
>> synopsis: IRC to instant messaging gateway  
>> description: BitlBee brings IM (instant messaging) to IRC clients, for 
>> people who have an IRC client running all
>> + the time and don't want to run an additional IM client.  BitlBee currently 
>> supports XMPP/Jabber (including Google
>> + Talk), MSN Messenger, Yahoo! Messenger, AIM and ICQ, and the Twitter 
>> microblogging network (plus all other Twitter
>> + API compatible services like identi.ca and status.net).
>>
>> $ ./pre-inst-env guix install bitlbee 
>> --with-parameter=bitlbee=libpurple=true -p /tmp/test-bitlbee
>> The following package will be installed:
>>bitlbee 3.6
>>
>> The following derivation will be built:
>>/gnu/store/clvs5521v5ybdw1z1yh97z2ky1dxm4d9-bitlbee-3.6.drv
>>
>> [...]
>>
>> $ cat /tmp/test-bitlbee/manifest
>> ;; This file was automatically generated and is for internal use only.
>> ;; It cannot be passed to the '--manifest' option.
>>
>> (manifest
>>   (version 3)
>>   (packages
>> (("bitlbee"
>>   "3.6"
>>   "out"
>>   "/gnu/store/d67r9k5hwfm5hkd1d3pbhg49fcc2jj4q-bitlbee-3.6"
>>   (propagated-inputs ())
>>   (search-paths ())
>>   (properties
>> (transformations
>>   (with-parameter . "bitlbee=libpurple=true")))
>> --8<---cut here---end--->8---
>>
>> That’s it!
>>
>> We would need more things, like a ‘guix parameters’ command to show the
>> available parameters of a package and an ‘--all

Re: A plan for parameterized packages

[Nicolò Balzarotti]

Neat! Thanks for working on it :)

> An important question: do we have examples of packages for which we’d
> like to have parameters?  I’d grepped for “inherit” and that yields a
> few potential candidates, but also maybe a few potential non-candidates.
> Would this be a good fit for them?

What about evince?  eps/ps/dvi rendering is disabled, according to this
thread [1] for security reasons, so it makes sense to have it disabled
by default.  But I'd like to be able to enable it easily.

WDYT?

Nicolò

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39674

Ludovic Courtès  writes:

> Hello Guix!
>
> For some time we’ve discussed ways to achieve “parameterized
> packages”—packages where one can from the command line or from Scheme
> configure optional build-time features, similar to Gentoo “USE flags”.
>
> I still have mixed feeling about this feature: on one hand it can bring
> much welcome flexibility, but on the other hand it can also lead us to
> the wild west of untested package configurations and combinatorial
> explosion.  It could also be argued that we achieve something similar
> today by simply defining package variants when we have to:
>
>   
> https://guix.gnu.org/manual/devel/en/html_node/Defining-Package-Variants.html
>
> That said, this message is about a possible implementation of package
> parameters, so here we go.  :-)
>
> To me the requirements for package parameters are:
>
>   1. it must be possible to discover them and choose them from the UI;
>
>   2. they must contain on-line internationalized documentation such that
>  the UI can list a package’s parameters and their type;
>
>   3. the chosen parameters when installing a package in a profile must
>  be preserved;
>
>   4. it must be possible to enumerate all the possible values of a
>  parameter, and thus to build the Cartesian product of all the
>  possible parameter combinations of a package (or of a package
>  graph!), so we can test those combinations as much as possible.
>
> This leads to the patches below.  The last one gives an example use for
> Bitlbee: it adds a “libpurple” parameter that allows users to choose
> whether or not to enable the optional libpurple dependency:
>
> --8<---cut here---start->8---
> $ ./pre-inst-env guix build bitlbee --with-parameter=bitlbee=libpurple=true -n
> The following derivation would be built:
>/gnu/store/mkknqgjsa93ajcl5d2krngizb11j1b0q-bitlbee-3.6.drv
> $ ./pre-inst-env guix build bitlbee --with-parameter=bitlbee=libpurple=false 
> -n
> /gnu/store/c2ckg51ffwgs6jni3l549k06w3jd3b7a-bitlbee-3.6
> $ ./pre-inst-env guix build bitlbee --with-parameter=bitlbee=libpurple=wat? -n
> guix build: error: wrong value
> $ ./pre-inst-env guix build bitlbee --with-parameter=bitlbee=libviolet=true -n
> gnu/packages/messaging.scm:283:5: error: libviolet: no such package parameter
> $ ./pre-inst-env guix show bitlbee
> name: bitlbee
> version: 3.6
> outputs: out
> parameters: libpurple
> systems: x86_64-linux i686-linux
> dependencies: check@0.12.0 glib@2.62.6 gnutls@3.6.12 libotr@4.1.1 perl@5.30.2 
> pkg-config@0.29.2 python@3.8.2
> location: gnu/packages/messaging.scm:243:2
> homepage: https://www.bitlbee.org/
> license: GPL 2+, FreeBSD
> synopsis: IRC to instant messaging gateway  
> description: BitlBee brings IM (instant messaging) to IRC clients, for people 
> who have an IRC client running all
> + the time and don't want to run an additional IM client.  BitlBee currently 
> supports XMPP/Jabber (including Google
> + Talk), MSN Messenger, Yahoo! Messenger, AIM and ICQ, and the Twitter 
> microblogging network (plus all other Twitter
> + API compatible services like identi.ca and status.net).
>
> $ ./pre-inst-env guix install bitlbee --with-parameter=bitlbee=libpurple=true 
> -p /tmp/test-bitlbee
> The following package will be installed:
>bitlbee 3.6
>
> The following derivation will be built:
>/gnu/store/clvs5521v5ybdw1z1yh97z2ky1dxm4d9-bitlbee-3.6.drv
>
> [...]
>
> $ cat /tmp/test-bitlbee/manifest
> ;; This file was automatically generated and is for internal use only.
> ;; It cannot be passed to the '--manifest' option.
>
> (manifest
>   (version 3)
>   (packages
> (("bitlbee"
>   "3.6"
>   "out"
>   "/gnu/store/d67r9k5hwfm5hkd1d3pbhg49fcc2jj4q-bitlbee-3.6"
>   (propagated-inputs ())
>   (search-paths ())
>   (properties
> (transformations
>   (with-parameter . "bitlbee=libpurple=true")))
> --8<---cut here---end--->8---
>
> That’s it!
>
> We would need more things, like a ‘guix parameters’ command to show the
> available parameters of a package and an ‘--all-parameter-values’ option
> to ‘guix build’ to build all the variants of a given package.
>
> An important question: do we have examples of packages for which we’d
> like to have parameters?  I’d grepped for “inherit” and that yields a
> few potential candidates, but also maybe a few potential 

A plan for parameterized packages

[Ludovic Courtès]

Hello Guix!

For some time we’ve discussed ways to achieve “parameterized
packages”—packages where one can from the command line or from Scheme
configure optional build-time features, similar to Gentoo “USE flags”.

I still have mixed feeling about this feature: on one hand it can bring
much welcome flexibility, but on the other hand it can also lead us to
the wild west of untested package configurations and combinatorial
explosion.  It could also be argued that we achieve something similar
today by simply defining package variants when we have to:

  https://guix.gnu.org/manual/devel/en/html_node/Defining-Package-Variants.html

That said, this message is about a possible implementation of package
parameters, so here we go.  :-)

To me the requirements for package parameters are:

  1. it must be possible to discover them and choose them from the UI;

  2. they must contain on-line internationalized documentation such that
 the UI can list a package’s parameters and their type;

  3. the chosen parameters when installing a package in a profile must
 be preserved;

  4. it must be possible to enumerate all the possible values of a
 parameter, and thus to build the Cartesian product of all the
 possible parameter combinations of a package (or of a package
 graph!), so we can test those combinations as much as possible.

This leads to the patches below.  The last one gives an example use for
Bitlbee: it adds a “libpurple” parameter that allows users to choose
whether or not to enable the optional libpurple dependency:

--8<---cut here---start->8---
$ ./pre-inst-env guix build bitlbee --with-parameter=bitlbee=libpurple=true -n
The following derivation would be built:
   /gnu/store/mkknqgjsa93ajcl5d2krngizb11j1b0q-bitlbee-3.6.drv
$ ./pre-inst-env guix build bitlbee --with-parameter=bitlbee=libpurple=false -n
/gnu/store/c2ckg51ffwgs6jni3l549k06w3jd3b7a-bitlbee-3.6
$ ./pre-inst-env guix build bitlbee --with-parameter=bitlbee=libpurple=wat? -n
guix build: error: wrong value
$ ./pre-inst-env guix build bitlbee --with-parameter=bitlbee=libviolet=true -n
gnu/packages/messaging.scm:283:5: error: libviolet: no such package parameter
$ ./pre-inst-env guix show bitlbee
name: bitlbee
version: 3.6
outputs: out
parameters: libpurple
systems: x86_64-linux i686-linux
dependencies: check@0.12.0 glib@2.62.6 gnutls@3.6.12 libotr@4.1.1 perl@5.30.2 
pkg-config@0.29.2 python@3.8.2
location: gnu/packages/messaging.scm:243:2
homepage: https://www.bitlbee.org/
license: GPL 2+, FreeBSD
synopsis: IRC to instant messaging gateway  
description: BitlBee brings IM (instant messaging) to IRC clients, for people 
who have an IRC client running all
+ the time and don't want to run an additional IM client.  BitlBee currently 
supports XMPP/Jabber (including Google
+ Talk), MSN Messenger, Yahoo! Messenger, AIM and ICQ, and the Twitter 
microblogging network (plus all other Twitter
+ API compatible services like identi.ca and status.net).

$ ./pre-inst-env guix install bitlbee --with-parameter=bitlbee=libpurple=true 
-p /tmp/test-bitlbee
The following package will be installed:
   bitlbee 3.6

The following derivation will be built:
   /gnu/store/clvs5521v5ybdw1z1yh97z2ky1dxm4d9-bitlbee-3.6.drv

[...]

$ cat /tmp/test-bitlbee/manifest
;; This file was automatically generated and is for internal use only.
;; It cannot be passed to the '--manifest' option.

(manifest
  (version 3)
  (packages
(("bitlbee"
  "3.6"
  "out"
  "/gnu/store/d67r9k5hwfm5hkd1d3pbhg49fcc2jj4q-bitlbee-3.6"
  (propagated-inputs ())
  (search-paths ())
  (properties
(transformations
  (with-parameter . "bitlbee=libpurple=true")))
--8<---cut here---end--->8---

That’s it!

We would need more things, like a ‘guix parameters’ command to show the
available parameters of a package and an ‘--all-parameter-values’ option
to ‘guix build’ to build all the variants of a given package.

An important question: do we have examples of packages for which we’d
like to have parameters?  I’d grepped for “inherit” and that yields a
few potential candidates, but also maybe a few potential non-candidates.
Would this be a good fit for them?

Thoughts?

Ludo’.

From 9155411f2e8e78922e1e46d92068ac8f652ff0a5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
Date: Sun, 15 Nov 2020 17:01:14 +0100
Subject: [PATCH 3/4] ui: 'package->recutils' emits "parameters" field.

* guix/ui.scm (package->recutils): Add "parameters" recutils field.
---
 guix/ui.scm | 5 +
 1 file changed, 5 insertions(+)

diff --git a/guix/ui.scm b/guix/ui.scm
index 4e686297e8..2485400cc9 100644
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -60,6 +60,7 @@
 #:hide (package-name->name+version
 ;; Avoid "overrides core binding" warning.
 delete))
+  #:autoload   (guix parameters) (package-parameters package-parameter-name)
 

Re: GNU Guix 1.2.0rc1 available for testing!

[zimoun]

Hi Ludo.

On Fri, 13 Nov 2020 at 18:07, Ludovic Courtès  wrote:

> In any case, please report success, failure, and annoyances in this thread.

Everything looks fine for me.  Even the ’r-*’ packages are there.

It is not finished yet but I would like to have a script that check the
availability build-system per build-system.  Something really better
than:

--8<---cut here---start->8---
$ pkgs=$(guix time-machine --branch=version-1.2.0 -- package -A ^sbcl- |cut -f1)
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...

$ guix time-machine --branch=version-1.2.0 -- weather $pkgs
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
computing 455 package derivations for x86_64-linux...
looking for 456 store items on https://ci.guix.gnu.org...
updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
https://ci.guix.gnu.org
  71.3% substitutes available (325 out of 456)
  at least 214.3 MiB of nars (compressed)
  431.6 MiB on disk (uncompressed)
  0.023 seconds per request (10.4 seconds in total)
  43.0 requests per second

  0.0% (0 out of 131) of the missing items are queued
  at least 1,000 queued builds
  x86_64-linux: 495 (49.5%)
  i686-linux: 355 (35.5%)
  aarch64-linux: 126 (12.6%)
  armhf-linux: 24 (2.4%)
  build rate: 32.11 builds per hour
  i686-linux: 10.53 builds per hour
  x86_64-linux: 13.04 builds per hour
  aarch64-linux: 4.63 builds per hour
  armhf-linux: 4.16 builds per hour
--8<---cut here---end--->8---


Thank you for the release candidate and all the under-the-hood work.

Cheers,
simon

Re: Reviving Emacs-Guix

[zimoun]

On Sun, 15 Nov 2020 at 16:45, Pierre Neidhardt  wrote:
> Good stuff!

I do not know but you aroused me about Geiser. ;-)

> Can you report your findings on the GitLab repo of emacs-guix?

I could.  Even send a patch.  :-)

Once the future of Emacs-Guix is a bit more clear.

All the best,
simon

Re: Reviving Emacs-Guix

[zimoun]

On Sun, 15 Nov 2020 at 15:11, Pierre Neidhardt  wrote:

> My bad, makes sense now.

If it makes sense…

>> Especially if
>>
>>  (guix-eval-in-repl
>>"(guix-build \"nyxt\" \"--no-grafts\" \"--check\")")
>>
>> works fine.
>
> What do you mean with this part?

… I mean replace the current offending part:

(guix-eval-in-repl
 (format (concat "(build-package* (package-by-id %d)"
 " #:use-substitutes? %s"
 " #:dry-run? %s)")
 package-id
 (guix-guile-boolean guix-use-substitutes)
 (guix-guile-boolean guix-dry-run)

by something like:

(guix-eval-in-repl
 (format (concat "(guix-build \"%s\" \"%s")
 package-name
 some-options)

in the Emacs function ’guix-build-package’ which is the one that chokes
the build part of Emacs-Guix.  Then this ’guix-build-package’ function
has to be exposed to ’M-x’, currently not and I do not why.

Somehow replace/rewrite ’build-packages*’ which seems the offender.  Not
Geiser.  If you confirm that it works for you in *ielm*.

The function ’guix-devel-build-package-source’ is another story because
it means interactive-ness.  Well, I have not looked into.  But similar
trick could be used.

Cheers,
simon

Re: Discoverability at the REPL level

[Danny Milosavljevic]

Hi zimoun,

On Sun, 15 Nov 2020 14:02:04 +0100
zimoun  wrote:

> In an ideal world, the first ’,a’ could provide hint for the module to
> ’,use’

There is no "the" module.  Any number of modules could have your searched-for
symbol--and the procedures so found could do completely unrelated things.  One
of the points of using modules in the first place is in order to group together
related things (and in order not to have unrelated things together).

What would be nice is for the module names to be easy to understand so you know
which module to import.  That's currently not great.  For example I have no
idea when something goes into (guix packages) vs (gnu packages).

Also, it would be nice and easy to implement to actually have the Guile REPL
search for all possible loadable modules that contain some symbol if it
encounters an unknown symbol, and print those, too (Guix often already does
that anyway!).

It should be easy to add such a thing to the guile repl.  In addition to
",describe" and ",apropos" there would be ",search" which would loop through
all modules, find the specified symbol and then print the docstrings of each
of those, including the module to use for each.

But since these modules can contain code that runs at module import time,
that's maybe also not what you want to actually happen (it would execute
code of random modules that are in the search path).
Then again, guile has declarative modules, too.  If those don't do that,
maybe just search in those.

Also, maybe you don't want Guile to actually IMPORT things into your namespace
when you do ",search".  You just want guile to list them.  That would be the
only complication.

... in before someone points out that this already exists in guile ;)

> and the ’,d’ should provide both signature and docstring.

I agree.  It's useless to separate those.  I mean it's nice that ",a"
exists--but then having ",d" not list the signature is just causing more work
for the developer.


pgpeN4qWpJyJV.pgp
Description: OpenPGP digital signature

Re: Reviving Emacs-Guix

[Pierre Neidhardt]

zimoun  writes:

>> Maybe a misunderstanding, but comint-mode is not the problem here, it
>> works very well indeed with big outputs.
>> Only Geiser chokes on it.
>
> I do not understand your point.  ’guix-eval-in-repl’ is a wrapper around
> ’geiser-repl--send’ so it uses Geiser, isn’t it?

Oops, sorry, I was focused on the IELM part, I though you were
outputting in the IELM buffer!

My bad, makes sense now.

> Especially if
>
>  (guix-eval-in-repl
>"(guix-build \"nyxt\" \"--no-grafts\" \"--check\")")
>
> works fine.

What do you mean with this part?

> PS:
> What do you name Geiser?

Sorry, I don't understand your question :p

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Reviving Emacs-Guix

[zimoun]

Hi Pierre,

On Sun, 15 Nov 2020 at 08:37, Pierre Neidhardt  wrote:
> zimoun  writes:
>
>> Could you try this and tell if Emacs hangs?  On my laptop, the first
>> attempts are not so worse.  M-x ielm
>>
>> --8<---cut here---start->8---
>> *** Welcome to IELM ***  Type (describe-mode) for help.
>> ELISP> (require 'guix-repl)
>> guix-repl
>> ELISP> (guix-eval-in-repl ",use(guix scripts build)")
>> nil
>> ELISP> (guix-eval-in-repl "(guix-build \"nyxt\" \"--no-grafts\" 
>> \"--check\")")
>> nil
>> --8<---cut here---end--->8---
>
> Maybe a misunderstanding, but comint-mode is not the problem here, it
> works very well indeed with big outputs.
> Only Geiser chokes on it.

I do not understand your point.  ’guix-eval-in-repl’ is a wrapper around
’geiser-repl--send’ so it uses Geiser, isn’t it?

>From my understanding, the culprit of Emacs hanging when building seems
more something wrong with the current implementation in Emacs-Guix than
really Geiser.

It reads:

(guix-eval-in-repl
 (format (concat "(build-package* (package-by-id %d)"
 " #:use-substitutes? %s"
 " #:dry-run? %s)")

where ’build-packages*’ reads:

--8<---cut here---start->8---
(define (build-package* package . build-options)
  "Build PACKAGE using BUILD-OPTIONS acceptable by 'set-build-options'.
Show what and how will/would be built."
  (with-store store
(run-with-store store
  (apply build-package package build-options
--8<---cut here---end--->8---

Especially if

 (guix-eval-in-repl
   "(guix-build \"nyxt\" \"--no-grafts\" \"--check\")")

works fine.


All the best,
simon


PS:
What do you name Geiser?

Discoverability at the REPL level

[zimoun]

Dear,

Preparing the online Guix Days, maybe this discussion is worth.  It
echoes first with the talks “Guix compared to Nix” then with the recent
discussion about Emacs-Guix [1].


The topic is discoverability at the REPL level.


Well, I have a proposal draft «“guix repl” and beyond» that I never
sent, where the ideas was to discuss ’~/.guile’ and how to extend Guix
ending with these questions:

 1. Does Guix want a system of aliases?  For example, let the script
 “~/.config/guix/scripts/foo.scm“ and then ‘guix foo’.

 2. How could the API be more discoverable?

 3. Is the experimental ‘guix repl --gui’ reasonable?


The #1 popup’ed up in #38529 [2,3] and it is not related to
discoverablity but not orthogonal either.

The #3 means open Guile-Studio or any other front-end and echoes the
recent discussion about GUI front-end [4].


Therefore, here materials about the point #2. :-)


(The attentive reader is waiting for parametrized package PoC :-) and a
first discussion and arguments are this long thread [5].)


Feed back and ideas welcome.  Especially about:

There are probably several ways to address it, including the
unbound-variable hints and documentation.


All the best,
simon


1: https://yhetil.org/guix-devel/87tuttci4z.fsf...@gnu.org
2: https://yhetil.org/guix-bugs/87y2jie1aj@gmail.com/
3: http://issues.guix.gnu.org/issue/38529#60
4: 
https://yhetil.org/guix-devel/caf-xjgsynm3kszum__f9dspuc0epj2qkdfwdftilhttumfa...@mail.gmail.com
5: https://yhetil.org/guix-devel/87woitz1xx@gnu.org/

 Start of forwarded message 
From: zimoun 
Cc: guix-d...@gnu.org
Date: Fri, 13 Nov 2020 19:20:21 +0100

Hi Ludo,

On Mon, 09 Nov 2020 at 22:55, Ludovic Courtès  wrote:

> Yeah I was also unsure; my idea was to give possible directions I had in
> mind (hence the plural: “the ways forward”), with the understanding that
> it’s nothing but a personal choice.

At «apero» break today, I have just watched [1] (speed 1.5) about Nix
modules (I do not know if it makes sense in the Guix context, anyway).
>From my opinion, one interesting point is discoverability.

Guile is still a bit mysterious to me but a lot of tooling could be done
in this area.  For example, I am directly grepping in the Guix sources
to find the function names or which module provides which function, etc.
When you come from Python or Haskell (to name the few I know), the
experience is poor.  Even if Emacs+Geiser+Completion helps.

For a concrete example of annoyance,

--8<---cut here---start->8---
$ guix repl
scheme@(guix-user)> ,a fold-packages
scheme@(guix-user)> ,use(gnu packages)
scheme@(guix-user)> ,a fold-packages
(gnu packages): fold-packages   #
scheme@(guix-user)> ,d fold-packages
Call (PROC PACKAGE RESULT) for each available package defined in one of
MODULES that matches SELECT?, using INIT as the initial value of RESULT.  It
is guaranteed to never traverse the same package twice.
--8<---cut here---end--->8---

So I have to know beforehand the module to import (and I personally do
not know how to list all the functions that the module exports) then use
,apropos and ,describe to know the signature and if it is what I want.

In an ideal world, the first ’,a’ could provide hint for the module to
’,use’ and the ’,d’ should provide both signature and docstring. Since
the naming is more or less regular ’,a package bag’ should list all the
functions containing (name or docstring) the both terms so it becomes
easy to find which module provide ’package->bag’.  Instead on relying to
ag+Ivy. ;-)


Well, just sharing random ideas that popped up watching [1]. :-)

1: 


Cheers,
simon
 End of forwarded message 

 Start of forwarded message 
From: Ludovic Courtès 
Cc: guix-d...@gnu.org
Date: Sun, 15 Nov 2020 12:25:29 +0100

Hi,

zimoun  skribis:

> At «apero» break today, I have just watched [1] (speed 1.5) about Nix
> modules (I do not know if it makes sense in the Guix context, anyway).
> From my opinion, one interesting point is discoverability.

I think some of the criticism that applies to Nix does not apply to
Guix: we have ‘guix search’ and ‘guix system search’, we have package
transformation options (which achieve some of what people want to do
with Nixpkgs overlays), source code location shows up in search results,
etc.

Representing packages as functions is Nixpkgs is the root of
non-discoverability.  Conversely, packages, service types, etc. are
top-level declarations.

And… we have Guile modules when it comes to structuring code.  :-)

What we’re seeing here is an example of a DSL that grows and grows until
it includes all the features that general-purpose languages have.

What we don’t have yet is parameterized packages, but that motivates me
to come up with a PoC.

> Guile is still a bit mysterious to

Re: Working Guix on 64 bit PowerPC.

[Efraim Flashner]

On Tue, Nov 10, 2020 at 08:56:21PM +0100, Tobias Platen wrote:
> Hello,
> 
> I've got the wip-ppc branch of Guix compiling unmodified on my Talos II.
> Since the POWER9 is backwards compatible with the PowerPC G4, it can run
> the existing bootstrap binaries for powerpc-linux. The binaries from
> http://flashner.co.il/guix/bootstrap/powerpc-linux/ have been verified
> working on my Talos II. I also plan to setup a mirror of those binaries.
> 
> [user@staticvoid guix]$ arch
> ppc64
> [user@staticvoid guix]$ ps -A | grep guix
>  1104 pts/100:00:00 guix-daemon
> [user@staticvoid guix]$ ./pre-inst-env guix build hello
> guix build: error: could not find bootstrap binary 'tar' for system 
> 'powerpc64-linux'
> [user@staticvoid guix]$ cat /proc/cpuinfo 
> processor : 0
> cpu   : POWER9, altivec supported
> clock : 2154.00MHz
> revision  : 2.2 (pvr 004e 1202)
> 

In the mean time you could use './pre-inst-env guix build
--system=powerpc-linux hello'. I'm especially interested if you can
build guile-final since I get some Segfault while compiling
ice-9/boot-9.go.

./pre-inst-env guix build --system=powerpc-linux -e '(@@ (gnu packages
commencement) guile-final)'

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature