[PATCH] website: Update sjd.se servers.
* website/apps/base/templates/donate.scm (donate-t): --- website/apps/base/templates/donate.scm | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/website/apps/base/templates/donate.scm b/website/apps/base/templates/donate.scm index 3135be8..5a6b7a0 100644 --- a/website/apps/base/templates/donate.scm +++ b/website/apps/base/templates/donate.scm @@ -161,18 +161,11 @@ i686-linux, and dedicated storage") (li (a (@ (href "https://www.fsf.org/;)) "Free Software Foundation") (tr - (td "guix.sjd.se") - (td "x86_64-linux, i686-linux") - (td - (ul - (li (a (@ (href "http://josefsson.org;)) - "Simon Josefsson") -(tr - (td "x15.sjd.se") + (td "guix-x15.sjd.se, guix-x15b.sjd.se") (td "armhf-linux") (td (ul - (li (a (@ (href "http://josefsson.org;)) + (li (a (@ (href "https://blog.josefsson.org/;)) "Simon Josefsson") (tr (td "hydra-slave1") -- 2.20.1 signature.asc Description: PGP signature
[PATCH] website: Update sjd.se servers.
* website/apps/base/templates/donate.scm (donate-t): --- website/apps/base/templates/donate.scm | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/website/apps/base/templates/donate.scm b/website/apps/base/templates/donate.scm index 3135be8..5a6b7a0 100644 --- a/website/apps/base/templates/donate.scm +++ b/website/apps/base/templates/donate.scm @@ -161,18 +161,11 @@ i686-linux, and dedicated storage") (li (a (@ (href "https://www.fsf.org/;)) "Free Software Foundation") (tr - (td "guix.sjd.se") - (td "x86_64-linux, i686-linux") - (td - (ul - (li (a (@ (href "http://josefsson.org;)) - "Simon Josefsson") -(tr - (td "x15.sjd.se") + (td "guix-x15.sjd.se, guix-x15b.sjd.se") (td "armhf-linux") (td (ul - (li (a (@ (href "http://josefsson.org;)) + (li (a (@ (href "https://blog.josefsson.org/;)) "Simon Josefsson") (tr (td "hydra-slave1") -- 2.20.1 signature.asc Description: PGP signature
Re: Image generation
Mathieu Othacehe skribis: >> Wow! Why did it take 2h30? Do you have KVM? > > Yes, I'm not sure why it's so long. It seems that > "estimated-partition-size" takes a large proportion of this time, > because if I run the same command with a fixed disk-image size it goes > faster. Ooooh, I had never realized, but you may be right: ‘closure-size’ stats every single file of the closure, and those files are accessed over 9P. That said, I tried this: --8<---cut here---start->8--- $ guix system build gnu/system/examples/bare-bones.tmpl --no-offload [...] $ time guix system disk-image gnu/system/examples/bare-bones.tmpl --no-offload guix system: warning: Your Guix installation is 15 days old. guix system: warning: Consider running 'guix pull' followed by 'guix system reconfigure' to get up-to-date packages and security updates. La jenaj derivoj estos konstruataj: /gnu/store/ydvfhx9v65l4cjrbdgr6xxdh44091fwf-disk-image.drv /gnu/store/8kz750zdbxl86n4w2gfcm0xm6gcqzbnb-linux-vm-loader.drv /gnu/store/0jmcc2f6r3q72mlbi9ahmx2bjghn2rha-builder-in-linux-vm.drv /gnu/store/9df7312w32sbs9nv55x8arh2c65apjmx-grub.cfg.drv /gnu/store/72mmpjd65ysyxdb8c7x9bflb7g9jq93i-raw-initrd.drv /gnu/store/m4xri89s0m0xkdkbma1z0a9ikaz3117v-system.drv /gnu/store/53gm95vhr2p5r6g3bb7c7zynchwn2k3x-boot.drv /gnu/store/ylmkdd43vinyz6li8kx62cphz74kcark-parameters.drv building /gnu/store/53gm95vhr2p5r6g3bb7c7zynchwn2k3x-boot.drv... building /gnu/store/72mmpjd65ysyxdb8c7x9bflb7g9jq93i-raw-initrd.drv... building /gnu/store/ylmkdd43vinyz6li8kx62cphz74kcark-parameters.drv... building /gnu/store/m4xri89s0m0xkdkbma1z0a9ikaz3117v-system.drv... building /gnu/store/9df7312w32sbs9nv55x8arh2c65apjmx-grub.cfg.drv... building /gnu/store/0jmcc2f6r3q72mlbi9ahmx2bjghn2rha-builder-in-linux-vm.drv... building /gnu/store/8kz750zdbxl86n4w2gfcm0xm6gcqzbnb-linux-vm-loader.drv... building /gnu/store/ydvfhx9v65l4cjrbdgr6xxdh44091fwf-disk-image.drv... /gnu/store/7v599g2zwkzb6lv8s6gjm66lqw0gcb53-disk-image real4m11.079s user0m5.145s sys 0m0.418s $ guix describe Generacio 139 Apr 13 2020 21:50:08(nuna) guix bad368b repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: bad368b0d794689f3a8a11b58f1ea4987938682e --8<---cut here---end--->8--- So it’s much less than 2h30. Could it be that you timing building of additional derivations? Even with a cold cache, it shouldn’t make that big a difference no? Thanks, Ludo’.
Re: Image generation
Howdy! Mathieu Othacehe skribis: > I made some progress on the image generation topic. As discussed > previously, the goal is to use the same principles as genimage[1], to > achieve faster image generation, without resorting to VM. Awesome. > A very related topic, is to bring the possibility to create Guix System > images with custom layouts. That includes position, size and type of the > bootloader partition, offset of the root partition and so on. While this > is not really important for desktop usage, it is almost mandatory for > embedded usage. > > The wip-disk-image branch allows to define a Guix System image along the > lines of: > > (define my-image > (image >(format 'disk-image) >(operating-system my-os) >(partitions > (list (partition >(size (* 40 (expt 2 20))) >(label "GNU-ESP") >(file-system "vfat") >(flags '(esp)) >(initializer (gexp initialize-efi-partition))) > (partition >(size 'guess) >(label "Guix_image") >(file-system "ext4") >(flags '(boot)) >(initializer (gexp initialize-root-partition))) That’s really cool! I’ve been willing to have something like that forever, but the current record is buried on the build side, which makes it inconvenient to use like you do above. > On this branch, it is already possible to generate an EFI disk-image, > with the traditional command: > > ./pre-inst-env guix system disk-image gnu/system/examples/desktop.tmpl > > On my computer, this takes 6m50 versus 2h30 for the master version. I > tested the image in QEMU, everything seems fine. Oh, this much on ‘master’? Anyway, the speedup is undoubtedly there and it’s really great. > Now there's still plenty of work. This branch needs some more > cleaning. Then we need to: > > * Add support for ISO images. I see you did that in the meantime. > * Extend support to grub (non-efi), extlinux and u-boot bootloaders. > * Check everything works with --system and --target arguments. Yeah. I saw your message to janneke, and indeed, I think there’s room for cooperation: janneke has come up with something that’s very close to “normal” Guix System for GNU/Hurd, and one of the main stumbling blocks in my mind is building the image and in particular getting proper GRUB suppotr for multiboot OSes. > I've re-implemented some parts of genimage in (gnu build disk-image) > module. Now, we could also go further and remove the use of this tool > completely. I think it’s great. :-) Please do ping us when you want a closer review! Ludo’.
Re: Image generation
Hi! Mathieu Othacehe skribis: > This command: > > guix system disk-image --file-system-type=iso9660 > gnu/system/examples/bare-bones.tmpl > > takes, > > * Without zisofs compression, on host: 4min > * With zisofs compression, on host: 8min > * With zisofs, on VM: 19min (master) Nice! > This makes me think that we may want to make iso compression optional, > so that tests can use uncompressed iso that takes more space but are > faster to produce. > > It seems that there are also some alternatives to xorriso such as > genisoimage (used by genimage). To me it’s really Xorriso that’s terribly slow, much slower than what ‘guix system disk-image’ does for ext4 on master. Ludo’.
Re: Cookbook translations
Le 28 avril 2020 13:46:33 GMT-04:00, "Björn Höfling" a écrit : >Hi Florian, > >On Tue, 28 Apr 2020 01:42:31 +0200 >"pelzflorian (Florian Pelz)" wrote: > >> On Tue, Apr 28, 2020 at 01:24:30AM +0200, Björn Höfling wrote: >> > I wondered: do you know how the cookbook translations are >> > organized? > >[..] > >> The cookbook is not available at the TP because no POT file is >shipped >> in Guix’ tarball. Julien suggested moving the translation from the >TP >> infrastructure to a Weblate setup (which I agree Guix should try and >> experiment with), so instead of waiting for inclusion of the cookbook >> at the TP I just commited the German translation directly to Guix >> master without going through the Translation Project. (It is >> important that the version at the TP is the most current version, but >> since there is no cookbook at the TP, it does not matter currently.) >> >> Regards, >> Florian > >I see. > >Do you want to use the hosted version of Weblate or are there plans to >host it within Guix? > >I just wondered because Weblate uses Node/yarn packages: > >https://github.com/WeblateOrg/weblate/blob/master/scripts/yarn/package.json > >Would that be OK for just hosting it as a service or do we need the >npm/yrn-importer first? :-) > >Björn The translation project is already hosted outside the guix project, so I don't see any issue if we're not able to package it just yet. hosted.weblate.org has some tracking in place (a matomo instance hosted by the weblate author). I wouldn't like to expose our users to it. Fedora has a weblate instance open to any free software project with no tracking, so I was suggesting using it instead.
Re: Cookbook translations
Hi Florian, On Tue, 28 Apr 2020 01:42:31 +0200 "pelzflorian (Florian Pelz)" wrote: > On Tue, Apr 28, 2020 at 01:24:30AM +0200, Björn Höfling wrote: > > I wondered: do you know how the cookbook translations are > > organized? [..] > The cookbook is not available at the TP because no POT file is shipped > in Guix’ tarball. Julien suggested moving the translation from the TP > infrastructure to a Weblate setup (which I agree Guix should try and > experiment with), so instead of waiting for inclusion of the cookbook > at the TP I just commited the German translation directly to Guix > master without going through the Translation Project. (It is > important that the version at the TP is the most current version, but > since there is no cookbook at the TP, it does not matter currently.) > > Regards, > Florian I see. Do you want to use the hosted version of Weblate or are there plans to host it within Guix? I just wondered because Weblate uses Node/yarn packages: https://github.com/WeblateOrg/weblate/blob/master/scripts/yarn/package.json Would that be OK for just hosting it as a service or do we need the npm/yrn-importer first? :-) Björn pgpUovaxvAhw6.pgp Description: OpenPGP digital signature
Re: Adding a subcommand "load-profile"
On Tue, 28 Apr 2020 22:42:53 + Roel Janssen wrote > Dear Guix, > > Years ago we implemented GNU Guix on the high-performance computing cluster > in > Utrecht. One of the things we added was a wrapper around the "guix" command > (called "guixr") to enable communication between the guix-daemon (on one > node), > and the client-side "guix" command. (We actually copied the great "guixr" > script from Ricardo at the time.) > > Lots of improvements have been made for the HPC use-case that the need for > the > "guixr" wrapper script is no longer needed. Except for one thing. > > We added a subcommand in the "guixr" script called "load-profile". It > allows a > user to do the following: > > $ guixr package -i ... -p /my/profile > $ guixr load-profile /my/profile > [env]$ > # ... A new shell is spawned here. > # Inside this shell only the environment variables in > # /my/profile/etc/profile are set ... > [env]$ exit > # Return to the normal shell state > > > The code of "guixr" is available at [1]. > > I sometimes wish I had this command available in "guix" itself. So I'd like > to > implement the "load-profile" subcommand in Scheme, so that it can be part of > Guix. > > Would there be any interest from others to have this as well? And also, the > shell implementation heavy relies on Bash. What other shells should I > attempt > to implement? Personally, I think managing Guix profiles is currently difficult, and I would like to have commands like this one to make it easier. Actually, I've been exploring using profiles to create development environments for my own projects (using information in the Cookbook), but it turned out to be too much manual work, so I've been prototyping a Guile-based CLI for my personal needs (https://gitlab.com/sirgazil/guix-entorno). I would like these kinds of things to be possible with Guix commands instead, though.
Re: core-updates call for testing
On Tue, Apr 28, 2020 at 03:17:06PM +0200, Marius Bakke wrote: > Leo Famulari writes: > > > I reconfigured my Guix System based on core-updates, and afterwards I > > was unable to login, either remotely over SSH, or on the Linux console. > > Do you still have the logs from this attempt? Curious what caused login > to fail. Yes, they are excerpted below. First you'll see the remote login attempts, and then the attempts at the Linux console: -- Apr 25 13:57:16 localhost sshd[2731]: Accepted publickey for leo from 192.168.1.101 port 55512 ssh2: ED25519 SHA256:my-key Apr 25 13:57:16 localhost sshd[2731]: error: PAM: pam_open_session(): Module is unknown Apr 25 13:57:16 localhost sshd[2733]: Received disconnect from 192.168.1.101 port 55512:11: disconnected by user Apr 25 13:57:16 localhost sshd[2733]: Disconnected from user leo 192.168.1.101 port 55512 Apr 25 13:57:23 localhost sshd[2735]: Accepted publickey for leo from 192.168.1.101 port 55514 ssh2: ED25519 SHA256:my-key Apr 25 13:57:23 localhost sshd[2735]: error: PAM: pam_open_session(): Module is unknown Apr 25 13:57:24 localhost sshd[2737]: Received disconnect from 192.168.1.101 port 55514:11: disconnected by user Apr 25 13:57:24 localhost sshd[2737]: Disconnected from user leo 192.168.1.101 port 55514 Apr 25 13:57:33 localhost sshd[2739]: Accepted publickey for leo from 192.168.1.101 port 55516 ssh2: ED25519 SHA256:my-key Apr 25 13:57:33 localhost sshd[2739]: error: PAM: pam_open_session(): Module is unknown Apr 25 13:57:34 localhost sshd[2741]: Received disconnect from 192.168.1.101 port 55516:11: disconnected by user Apr 25 13:57:34 localhost sshd[2741]: Disconnected from user leo 192.168.1.101 port 55516 Apr 25 13:57:58 localhost dhclient: DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 5 Apr 25 13:58:03 localhost dhclient: DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 7 Apr 25 13:58:10 localhost dhclient: DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 10 Apr 25 13:58:13 localhost /gnu/store/c972x2d6vld0wgw1vdsf72wiyf4ibqwm-mingetty-1.08/sbin/mingetty[334]: tty1: invalid character 0x0 in login name Apr 25 13:58:17 localhost shepherd[1]: Respawning term-tty1. Apr 25 13:58:17 localhost shepherd[1]: Service host-name has been started. Apr 25 13:58:17 localhost shepherd[1]: Service term-tty1 has been started. Apr 25 13:58:20 localhost vmunix: [433720.062263] login[2745]: segfault at 0 ip 7f8fc66d0934 sp 7fffcf163610 error 4 in libpthread-2.31.so[7f8fc66d+f000] Apr 25 13:58:20 localhost vmunix: [433720.062271] Code: 82 e8 02 00 00 e0 ff ff ff be 18 00 00 00 b8 11 01 00 00 48 89 ba d8 02 00 00 48 89 ba e0 02 00 00 0f 05 48 8b 05 84 56 01 00 <48> 8b 00 64 48 89 04 25 98 06 00 00 48 8d 05 09 9a 01 00 48 8d 8a Apr 25 13:58:20 localhost shepherd[1]: Respawning term-tty1. Apr 25 13:58:20 localhost shepherd[1]: Service host-name has been started. Apr 25 13:58:20 localhost shepherd[1]: Service term-tty1 has been started. --
Re: Adding a subcommand "load-profile"
Dear Roel, On Tue, 28 Apr 2020 at 17:43, Roel Janssen wrote: > > $ guixr package -i ... -p /my/profile > $ guixr load-profile /my/profile > [env]$ > # ... A new shell is spawned here. > # Inside this shell only the environment variables in > # /my/profile/etc/profile are set ... > [env]$ exit > # Return to the normal shell state > [...] > Would there be any interest from others to have this as well? And also, the > shell implementation heavy relies on Bash. What other shells should I attempt > to implement? It would be cool! However, if I remember correctly the previous discussion on such topic, the issue was to respect the user's shell ($SHELL). This argument is mitigated by the fact that "guix environment" already uses Bash to spawn the new shell, if I understand correctly. Well, I find annoying to not able to "go in" and "go out" in one profile and I prefer having a Bash specific implementation than nothing. So, thank you for the initiative. :-) > If there is interest in having this as a "load-profile" subcommand, I will > post > an initial implementation to the mailing list ASAP. Instead of another subcommand, I would suggest to add an option to "guix environment". Then an another further step should maybe combine "--load-profile" and "--ad-hoc" in order to create a temporary "augmented" profile. All the best, simon
Adding a subcommand "load-profile"
Dear Guix, Years ago we implemented GNU Guix on the high-performance computing cluster in Utrecht. One of the things we added was a wrapper around the "guix" command (called "guixr") to enable communication between the guix-daemon (on one node), and the client-side "guix" command. (We actually copied the great "guixr" script from Ricardo at the time.) Lots of improvements have been made for the HPC use-case that the need for the "guixr" wrapper script is no longer needed. Except for one thing. We added a subcommand in the "guixr" script called "load-profile". It allows a user to do the following: $ guixr package -i ... -p /my/profile $ guixr load-profile /my/profile [env]$ # ... A new shell is spawned here. # Inside this shell only the environment variables in # /my/profile/etc/profile are set ... [env]$ exit # Return to the normal shell state The code of "guixr" is available at [1]. I sometimes wish I had this command available in "guix" itself. So I'd like to implement the "load-profile" subcommand in Scheme, so that it can be part of Guix. Would there be any interest from others to have this as well? And also, the shell implementation heavy relies on Bash. What other shells should I attempt to implement? If there is interest in having this as a "load-profile" subcommand, I will post an initial implementation to the mailing list ASAP. Thanks all! Kind regards, Roel Janssen [1] https://github.com/UMCUGenetics/guix-additions/blob/master/umcu/packages/guix.scm#L191-L339
Re: When installing pycurl through pip, linux/limits.h is missing from glibc
Josh Marshall writes: > `python3 -m pip install pycurl` fails due to glibc not being able to find > the header "linux/limits.h". I am aware that there is a "python-pycurl" > package in guix, but the above should still work. I think glibc is missing > a dependency on linux headers, but I'm not sure that all this is > actionable. Should I be opening up a bug report for this? Does it work if you run it in a 'guix environment --ad-hoc gcc-toolchain'? That would set up CPATH and related variables and should allow the build system to locate the Linux headers. signature.asc Description: PGP signature
Re: core-updates call for testing
Leo Famulari writes: > I reconfigured my Guix System based on core-updates, and afterwards I > was unable to login, either remotely over SSH, or on the Linux console. Do you still have the logs from this attempt? Curious what caused login to fail. signature.asc Description: PGP signature
Re: core-updates call for testing
Efraim Flashner writes: > I have a package which currently depends on gfortran-5, although > gfortran-5 doesn't build on core-updates. > > efraimf@penguin2:~/workspace/guix-core-updates$ ./pre-inst-env guix build > --no-grafts -e '(@@ (gnu packages gcc) gfortran-5)' > substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% > The following derivation will be built: >/gnu/store/frqb5p2vdk8qcjwbny1s6mlak344a0gx-gfortran-5.5.0.drv > building /gnu/store/frqb5p2vdk8qcjwbny1s6mlak344a0gx-gfortran-5.5.0.drv... > Backtrace: > In ice-9/eval.scm: >217:50 19 (lp (# ?)) >217:50 18 (lp (# ?)) >217:50 17 (lp (# ?)) >217:50 16 (lp (# ?)) >217:50 15 (lp (# ?)) >217:50 14 (lp (# ?)) >217:50 13 (lp (# ?)) >217:50 12 (lp (# ?)) >217:50 11 (lp (# ?)) >217:50 10 (lp (# ?)) >217:50 9 (lp (# ?)) >217:50 8 (lp (# ?)) >217:50 7 (lp (# ?)) >217:50 6 (lp (# ?)) >217:33 5 (lp (# ?)) >196:43 4 (_ #f) >196:35 3 (_ #f) >202:27 2 (_ #f) >223:20 1 (proc #) >In unknown file: >0 (%resolve-variable (7 . cut) #) > > ERROR: In procedure %resolve-variable: > Unbound variable: cut Fixed in 587398d2a82e0b5966a6827d36a1f1d115181b11, thanks! signature.asc Description: PGP signature
Re: core-updates call for testing
I have a package which currently depends on gfortran-5, although gfortran-5 doesn't build on core-updates. efraimf@penguin2:~/workspace/guix-core-updates$ ./pre-inst-env guix build --no-grafts -e '(@@ (gnu packages gcc) gfortran-5)' substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% The following derivation will be built: /gnu/store/frqb5p2vdk8qcjwbny1s6mlak344a0gx-gfortran-5.5.0.drv building /gnu/store/frqb5p2vdk8qcjwbny1s6mlak344a0gx-gfortran-5.5.0.drv... Backtrace: In ice-9/eval.scm: 217:50 19 (lp (# ?)) 217:50 18 (lp (# ?)) 217:50 17 (lp (# ?)) 217:50 16 (lp (# ?)) 217:50 15 (lp (# ?)) 217:50 14 (lp (# ?)) 217:50 13 (lp (# ?)) 217:50 12 (lp (# ?)) 217:50 11 (lp (# ?)) 217:50 10 (lp (# ?)) 217:50 9 (lp (# ?)) 217:50 8 (lp (# ?)) 217:50 7 (lp (# ?)) 217:50 6 (lp (# ?)) 217:33 5 (lp (# ?)) 196:43 4 (_ #f) 196:35 3 (_ #f) 202:27 2 (_ #f) 223:20 1 (proc #) In unknown file: 0 (%resolve-variable (7 . cut) #) ERROR: In procedure %resolve-variable: Unbound variable: cut builder for `/gnu/store/frqb5p2vdk8qcjwbny1s6mlak344a0gx-gfortran-5.5.0.drv' failed with exit code 1 build of /gnu/store/frqb5p2vdk8qcjwbny1s6mlak344a0gx-gfortran-5.5.0.drv failed View build log at '/var/log/guix/drvs/fr/qb5p2vdk8qcjwbny1s6mlak344a0gx-gfortran-5.5.0.drv.bz2'. guix build: error: build of `/gnu/store/frqb5p2vdk8qcjwbny1s6mlak344a0gx-gfortran-5.5.0.drv' failed I checked the guix tree and 'git grep \,gfortran' showed they're all using gfortran-7. I was able to build gfortran-6. gfortran-4.9 also failed, same error. -- 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
Re: Guix System video review on YouTube
On 28.04.20 13:04, Bengt Richter wrote: >>> So I would propose an interface like: >>> $ guix search vim >>> | Name | Synopsis | Version | Outputs >>> | >>> +---++--+-+ >>> | vim | Text editor based on vi| 8.2.0411 | out >>> | | vim-airline | ... [...] >> >> Please don't, ASCII formatting always messes things up. Use the >> terminal for text. If you want a more visual package manager, don't use > > To me it looks like he *is* using a terminal to get the above :) > (or faking it from some re-purposed console cli sql output snippet?) I did wrote it directly to my mail client as a visualization of my idea.
Re: Guix System video review on YouTube
On +2020-04-28 02:32:39 +0200, raingloom wrote: > On Mon, 27 Apr 2020 12:11:05 +0200 > Jonathan Brielmaier wrote: > > > $ echo "hello" > > hello > > $ guix install emacs > > > > Then while installing emacs, try to reach the hello. It will be tricky > > as every new output line from `guix install emacs` will reset you to > > the bottom of your terminal. That's annoying. > > > > This is not related to the distribution, it's a terminal emulator > default. The behavior is the same in every other distribution I've used. > If they think this is a bad default, they should write on the > terminal emulator's bug tracker. > > But then again, you usually want new (possibly quite important) > messages to catch the user's attention, so I'd say it's a good default. > > Anyways, the option is trivial to change in the settings. You don't > even have to look too hard. > > > So I would propose an interface like: > > $ guix search vim > > | Name | Synopsis | Version | Outputs > > | > > +---++--+-+ > > | vim | Text editor based on vi| 8.2.0411 | out > > | | vim-airline | ... [...] > > Please don't, ASCII formatting always messes things up. Use the > terminal for text. If you want a more visual package manager, don't use To me it looks like he *is* using a terminal to get the above :) (or faking it from some re-purposed console cli sql output snippet?) > a CLI tool. A proper GUI will be more accessible. > By "proper" you mean browser-presented html/javascript ? ;-) > As one example, ASCII formatting makes screen readers a lot harder to > use. I don't think that has to be so :) > -- Regards, Bengt Richter
Re: 02/02: image: Disable compression for ISO images.
On +2020-04-27 18:00:05 +0200, Mathieu Othacehe wrote: > > Hey Tobias, > > > guix-comm...@gnu.org 写道： > >> + ;; XXX: Temporarily disable compression to speed-up the tests. > >> + (compression? #f))) > > > > Interesting! What kind of improvement do you see, roughly? > > I posted some figures here: > https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00374.html. > > Here's a more complete summary: > > --8<---cut here---start->8--- > || Host (wip-disk-image) | VM (master) | > |+---+-| > | No compression | 4min | 12min | > | Compression| 8min | 19min | > --8<---cut here---end--->8--- > > > When I added zlib compression I was surprised to learn that here it made no > > significant difference in wall clock time (less than a minute; 5% or so) or > > CPU time. The disks they spin and CPU she is fast, but still I would have > > noticed a spike. > > Strange we have different results, those benches are not very accurate > though. Might it throw some light to see your different results for --8<---cut here---start->8--- $ lscpu|grep -i bogo $ top -n1|grep ^MiB --8<---cut here---end--->8--- At least I'm curious :) > > Thanks, > > Mathieu > -- Regards, Bengt Richter
