unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / Atom feed
* GNU Guix 1.2.0rc1 available for testing!
@ 2020-11-13 17:07 Ludovic Courtès
  2020-11-15 16:19 ` zimoun
                   ` (2 more replies)
  0 siblings, 3 replies; 23+ messages in thread
From: Ludovic Courtès @ 2020-11-13 17:07 UTC (permalink / raw)
  To: guix-devel

[-- Attachment #1: Type: text/plain, Size: 2853 bytes --]

Hello Guix!

I’m happy to announce a release candidate for 1.2.0:

  source:
    https://alpha.gnu.org/gnu/guix/guix-1.2.0rc1.tar.gz

  binary tarball (to install on a “foreign distro”):
    https://alpha.gnu.org/gnu/guix/guix-binary-1.2.0rc1.aarch64-linux.tar.xz
    https://alpha.gnu.org/gnu/guix/guix-binary-1.2.0rc1.armhf-linux.tar.xz
    https://alpha.gnu.org/gnu/guix/guix-binary-1.2.0rc1.i686-linux.tar.xz
    https://alpha.gnu.org/gnu/guix/guix-binary-1.2.0rc1.x86_64-linux.tar.xz

  system installation:
    https://alpha.gnu.org/gnu/guix/guix-system-install-1.2.0rc1.i686-linux.iso.xz
    https://alpha.gnu.org/gnu/guix/guix-system-install-1.2.0rc1.x86_64-linux.iso.xz

  virtual machine image:
    https://alpha.gnu.org/gnu/guix/guix-system-vm-image-1.2.0rc1.x86_64-linux.xz

SHA256 hashes:

  ac85dbfa17bfb582c91b867928bd1eebc4dc36b61fca2d8014ba0e8c83879932  guix-1.2.0rc1.tar.gz
  83996dad6ec4d1a0ee59ee2eab37cc2398e0d894fb942c67347009a37250be02  guix-binary-1.2.0rc1.aarch64-linux.tar.xz
  ee2071da2640843977c56cfc9fdf7c346c9c88f250b1f20baff27731e4a3ff5a  guix-binary-1.2.0rc1.armhf-linux.tar.xz
  b7174db2faaf2d7fad74ab5c06b635f39d38f3f80b023f3de8e4c0d30bd84cf9  guix-binary-1.2.0rc1.i686-linux.tar.xz
  625f57a7a16118a98330a3f03d0d63509a0b4a61e56a179f1a2c0ca1e00de3b6  guix-binary-1.2.0rc1.x86_64-linux.tar.xz
  f4dc25282cfcb5f9426c17cf0d18984846595cf6815ffd87315596e3514a5d71  guix-system-install-1.2.0rc1.i686-linux.iso.xz
  8478f762146bcbc0ce7683395a846b6cbcf6002107e71df4248bf9d8699d52e2  guix-system-install-1.2.0rc1.x86_64-linux.iso.xz
  8bd4e9cbb4e218ca5afa02d5f7e8bc70d4b3ed1c19b6576488051ed61a5cfc89  guix-system-vm-image-1.2.0rc1.x86_64-linux.xz

All these files have an associated ‘.sig’, an OpenPGP signature that you
can verify as explained at
<https://guix.gnu.org/manual/en/html_node/Binary-Installation.html>.

You can help by:

  1. Testing the binary tarball on the distro of your choice.  You can
     download <https://guix.gnu.org/install.sh> and tweak it so it
     fetches 1.2.0rc1 (patch not included :-)).

  2. Testing the graphical installer of Guix System.

  3. Testing the VM image.

  4. Testing the bug fix for <https://issues.guix.gnu.org/35594>: in
     GNOME, Xfce, and other GLib-based desktop environment, the
     application menu should now be automatically updated as soon as
     ‘guix install’, ‘guix remove’, etc. complete.

     You can also test this without going through a full system
     installation by running:

       guix time-machine --branch=version-1.2.0 \
         system reconfigure /etc/config.scm

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

It would be nice to release 1.2.0 before the Guix Day and the Guix
anniversary (Nov. 23).

Thanks in advance!

Ludo’.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-13 17:07 GNU Guix 1.2.0rc1 available for testing! Ludovic Courtès
@ 2020-11-15 16:19 ` zimoun
  2020-11-15 19:16 ` pelzflorian (Florian Pelz)
  2020-11-16  0:10 ` Oleg Pykhalov
  2 siblings, 0 replies; 23+ messages in thread
From: zimoun @ 2020-11-15 16:19 UTC (permalink / raw)
  To: Ludovic Courtès, guix-devel

Hi Ludo.

On Fri, 13 Nov 2020 at 18:07, Ludovic Courtès <ludo@gnu.org> 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


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-13 17:07 GNU Guix 1.2.0rc1 available for testing! Ludovic Courtès
  2020-11-15 16:19 ` zimoun
@ 2020-11-15 19:16 ` pelzflorian (Florian Pelz)
  2020-11-15 21:53   ` Marius Bakke
  2020-11-16  0:10 ` Oleg Pykhalov
  2 siblings, 1 reply; 23+ messages in thread
From: pelzflorian (Florian Pelz) @ 2020-11-15 19:16 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]

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

[-- Attachment #2: last-installer-error --]
[-- Type: text/plain, Size: 1949 bytes --]

In ./gnu/installer/newt/partition.scm:
    785:4 19 (run-partitioning-page)
In srfi/srfi-1.scm:
    634:9 18 (for-each #<procedure 7f09c7a2b3d8 at ./gnu/installer/parted.scm:1392:14 (file-name)> ("/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 (_ #(#(#<directory (guile-user) 7f09d2bc2f00> #<<installer> name: newt init: #<procedure init ()> exit: #<procedure exit ()> exit-error: #<procedure exit-error (file key args)> f…>) …))
    619:8  4 (_ #(#(#(#<directory (guile-user) 7f09d2bc2f00> #<<installer> name: newt init: #<procedure init ()> exit: #<procedure exit ()> exit-error: #<procedure exit-error (file key arg…>) …) #))
In ice-9/ports.scm:
   463:17  3 (call-with-output-file _ _ #:binary _ #:encoding _)
In ice-9/eval.scm:
    619:8  2 (_ #(#(#<directory (guile-user) 7f09d2bc2f00> misc-error (#f "~A" ("Device /dev/sda is still in use.") #f)) #<output: /tmp/last-installer-error 19>))
    159:9  1 (_ #(#(#<directory (guile-user) 7f09d2bc2f00> misc-error (#f "~A" ("Device /dev/sda is still in use.") #f)) #<output: /tmp/last-installer-error 19>))
In unknown file:
           0 (make-stack #t)
ice-9/eval.scm:159:9: Device /dev/sda is still in use.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-15 19:16 ` pelzflorian (Florian Pelz)
@ 2020-11-15 21:53   ` Marius Bakke
  2020-11-15 23:16     ` pelzflorian (Florian Pelz)
  0 siblings, 1 reply; 23+ messages in thread
From: Marius Bakke @ 2020-11-15 21:53 UTC (permalink / raw)
  To: pelzflorian (Florian Pelz), Ludovic Courtès; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> 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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-15 21:53   ` Marius Bakke
@ 2020-11-15 23:16     ` pelzflorian (Florian Pelz)
  2020-11-16  9:12       ` Mathieu Othacehe
  2020-11-16 15:39       ` Miguel Ángel Arruga Vivas
  0 siblings, 2 replies; 23+ messages in thread
From: pelzflorian (Florian Pelz) @ 2020-11-15 23:16 UTC (permalink / raw)
  To: Marius Bakke; +Cc: guix-devel

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 #<newt-form 771a60> ("Locale language") with 0 clients 
Nov 15 23:49:40 localhost vmunix: [   56.102132] tg3 0000: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 <UP>
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 <DOWN>
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 <LINK>
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {del} route fd00:: gw :: scope 0 <UNIVERSE>
Nov 15 23:49:40 localhost connmand[210]: enp3s0 {del} route fe80:: gw :: scope 0 <UNIVERSE>
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 #<newt-form 771ab0> ("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 #<newt-form 788ea0> ("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 #<newt-form 789640> ("Timezone") with 0 clients 
Nov 15 23:50:32 localhost installer[259]: running form #<newt-form 7859b0> ("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 #<newt-form 783e40> ("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 #<newt-form 7842a0> ("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 #<newt-form 785dd0> ("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 #<newt-form 7e5590> ("No service") with 0 clients 
Nov 15 23:51:00 localhost vmunix: [  135.760473] tg3 0000:03:00.0 enp3s0: Link is up at 100 Mbps, full duplex
Nov 15 23:51:00 localhost vmunix: [  135.760478] tg3 0000: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 <UNIVERSE>
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 <UP,RUNNING,LOWER_UP>
Nov 15 23:51:00 localhost connmand[210]: enp3s0 {newlink} index 2 address 10:9A:DD:46:4F:9F mtu 1500
Nov 15 23:51:00 localhost connmand[210]: enp3s0 {newlink} index 2 operstate 6 <UP>
Nov 15 23:51:00 localhost connmand[210]: Setting domainname to fritz.box
Nov 15 23:51:00 localhost nscd: 211 monitored file `/etc/resolv.conf` was written to
Nov 15 23:51:00 localhost connmand[210]: enp3s0 {add} address 192.168.178.74/24 label enp3s0 family 2
Nov 15 23:51:00 localhost connmand[210]: ntp: adjust (slew): +0.137667 sec
Nov 15 23:51:00 localhost connmand[210]: enp3s0 {add} route 192.168.178.0 gw 0.0.0.0 scope 253 <LINK>
Nov 15 23:51:00 localhost connmand[210]: enp3s0 {add} route 192.168.178.1 gw 0.0.0.0 scope 253 <LINK>
Nov 15 23:51:00 localhost connmand[210]: enp3s0 {add} route 0.0.0.0 gw 192.168.178.1 scope 0 <UNIVERSE>
Nov 15 23:51:00 localhost nscd: 211 monitored file `/etc/resolv.conf` was written to
Nov 15 23:51:00 localhost last message repeated 5 times
Nov 15 23:51:00 localhost connmand[210]: enp3s0 {add} route 212.227.81.55 gw 192.168.178.1 scope 0 <UNIVERSE>
Nov 15 23:51:01 localhost connmand[210]: enp3s0 {del} route 212.227.81.55 gw 192.168.178.1 scope 0 <UNIVERSE>
Nov 15 23:51:01 localhost installer[259]: running step 'select-technology' 
Nov 15 23:51:01 localhost installer[259]: running step 'power-technology' 
Nov 15 23:51:02 localhost connmand[210]: enp3s0 {add} route fd00:: gw :: scope 0 <UNIVERSE>
Nov 15 23:51:02 localhost nscd: 211 monitored file `/etc/resolv.conf` was written to
Nov 15 23:51:02 localhost installer[259]: running step 'connect-service' 
Nov 15 23:51:03 localhost installer[259]: running step 'wait-online' 
Nov 15 23:51:04 localhost installer[259]: running step 'user' 
Nov 15 23:51:04 localhost installer[259]: running form #<newt-form 857f70> ("System administrator password") with 0 clients 
Nov 15 23:51:04 localhost connmand[210]: enp3s0 {add} address fd00::129a:ddff:fe46:4f9f/64 label (null) family 10
Nov 15 23:51:04 localhost nscd: 211 monitored file `/etc/resolv.conf` was written to
Nov 15 23:51:04 localhost last message repeated 5 times
Nov 15 23:51:15 localhost installer[259]: running form #<newt-form 85c870> ("Password confirmation required") with 0 clients 
Nov 15 23:51:23 localhost installer[259]: running form #<newt-form 85c820> (add-users) with 0 clients 
Nov 15 23:51:45 localhost installer[259]: running form #<newt-form 859770> ("Password confirmation required") with 0 clients 
Nov 15 23:51:54 localhost installer[259]: running form #<newt-form 858770> (add-users) with 0 clients 
Nov 15 23:51:55 localhost installer[259]: running step 'services' 
Nov 15 23:51:55 localhost installer[259]: running form #<newt-form 859480> ("Desktop environment") with 0 clients 
Nov 15 23:52:01 localhost installer[259]: running form #<newt-form 8594d0> ("Network service") with 0 clients 
Nov 15 23:52:02 localhost installer[259]: running step 'partition' 
Nov 15 23:52:04 localhost vmunix: [  199.938163]  sda: sda1 sda2 sda3 sda4 sda5 sda7
Nov 15 23:52:04 localhost vmunix: [  200.195324]  sdc: sdc2
Nov 15 23:52:04 localhost installer[259]: running form #<newt-form 8592a0> ("Partitioning method") with 0 clients 
Nov 15 23:52:08 localhost installer[259]: running form #<newt-form 8594d0> ("Manual partitioning") with 0 clients 
Nov 15 23:52:08 localhost vmunix: [  203.706965]  sda: sda1 sda2 sda3 sda4 sda5 sda7
Nov 15 23:52:08 localhost vmunix: [  203.715838]  sdc: sdc2
Nov 15 23:52:12 localhost installer[259]: running form #<newt-form 859910> ("Partition edit") with 0 clients 
Nov 15 23:52:15 localhost installer[259]: running form #<newt-form 86f5f0> ("Encryption label") with 0 clients 
Nov 15 23:52:24 localhost installer[259]: running form #<newt-form 86ee10> ("Partition edit") with 0 clients 
Nov 15 23:52:26 localhost installer[259]: running form #<newt-form 864610> ("Mounting point") with 0 clients 
Nov 15 23:52:28 localhost installer[259]: running form #<newt-form 8643a0> ("Partition edit") with 0 clients 
Nov 15 23:52:30 localhost installer[259]: running form #<newt-form 864450> ("Manual partitioning") with 0 clients 
Nov 15 23:52:33 localhost installer[259]: running form #<newt-form 86f730> ("Password required") with 0 clients 
Nov 15 23:52:45 localhost installer[259]: running form #<newt-form 870810> ("Password confirmation required") with 0 clients 
Nov 15 23:52:55 localhost installer[259]: running form #<newt-form 8643a0> ("Format disk?") with 0 clients 
Nov 15 23:53:01 localhost vmunix: [  257.244569]  sdc: sdc2
Nov 15 23:53:03 localhost installer[259]: crashing due to uncaught exception: misc-error (#f "~A" ("Device /dev/sda is still in use.") #f) 
Nov 15 23:53:03 localhost installer[259]: running form #<newt-form 865370> ("Unexpected problem") with 0 clients 

I assume some formatting step had not completed in time.

Regards,
Florian


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-13 17:07 GNU Guix 1.2.0rc1 available for testing! Ludovic Courtès
  2020-11-15 16:19 ` zimoun
  2020-11-15 19:16 ` pelzflorian (Florian Pelz)
@ 2020-11-16  0:10 ` Oleg Pykhalov
  2020-11-16  9:06   ` Ludovic Courtès
  2 siblings, 1 reply; 23+ messages in thread
From: Oleg Pykhalov @ 2020-11-16  0:10 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-16  0:10 ` Oleg Pykhalov
@ 2020-11-16  9:06   ` Ludovic Courtès
  2020-11-16 16:24     ` John Soo
  0 siblings, 1 reply; 23+ messages in thread
From: Ludovic Courtès @ 2020-11-16  9:06 UTC (permalink / raw)
  To: Oleg Pykhalov; +Cc: guix-devel

Hi Oleg,

Oleg Pykhalov <go.wigust@gmail.com> skribis:

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

Yay!

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

Right, it very much assumes DHCP.

> 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”.

OK.

> 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.
>
> (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)

It would be nice to include a fix, either a patch or explicitly
depending on the previous Geiser version.  (Cc: John Soo who might have
suggestions.)

Thanks!

Ludo’.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-15 23:16     ` pelzflorian (Florian Pelz)
@ 2020-11-16  9:12       ` Mathieu Othacehe
  2020-11-16 11:47         ` pelzflorian (Florian Pelz)
                           ` (2 more replies)
  2020-11-16 15:39       ` Miguel Ángel Arruga Vivas
  1 sibling, 3 replies; 23+ messages in thread
From: Mathieu Othacehe @ 2020-11-16  9:12 UTC (permalink / raw)
  To: pelzflorian (Florian Pelz); +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 825 bytes --]


Hello Florian,

> Nov 15 23:53:03 localhost installer[259]: crashing due to uncaught exception: misc-error (#f "~A" ("Device /dev/sda is still in use.") #f) 
> Nov 15 23:53:03 localhost installer[259]: running form #<newt-form 865370> ("Unexpected problem") with 0 clients 

Many thanks (again) for your help here! According to the backtrace you
sent earlier in this thread, it looks like the crash occurs in the
"free-parted" procedure.

This procedure tries to unallocate Parted resources and waits for the
partition table changes to be synchronized to disk. The
"with-delay-device-in-use?" tries 4 times every 250ms to detect if the
device is still in use.

Maybe it takes longer on your HW to synchronize the partition tables. If
you could test the attached patch on top of 1.2.0 it would be terrific.

Thanks,

Mathieu

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Increase-device-use-delay.patch --]
[-- Type: text/x-diff, Size: 908 bytes --]

From 6fec27303d0f8767ed48c507af67908a0fcf17a0 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe <othacehe@gnu.org>
Date: Mon, 16 Nov 2020 10:10:56 +0100
Subject: [PATCH] Increase device use delay.

---
 gnu/installer/parted.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/installer/parted.scm b/gnu/installer/parted.scm
index f2352c5779..ed3af6af85 100644
--- a/gnu/installer/parted.scm
+++ b/gnu/installer/parted.scm
@@ -318,7 +318,7 @@ PARTED-OBJECT field equals PARTITION, return #f if not found."
 fail. See rereadpt function in wipefs.c of util-linux for an explanation."
   ;; Kernel always return EINVAL for BLKRRPART on loopdevices.
   (and (not (string-match "/dev/loop*" file-name))
-       (let loop ((try 4))
+       (let loop ((try 16))
          (usleep 250000)
          (let ((in-use? (device-in-use? file-name)))
            (if (and in-use? (> try 0))
-- 
2.29.2


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-16  9:12       ` Mathieu Othacehe
@ 2020-11-16 11:47         ` pelzflorian (Florian Pelz)
  2020-11-17  9:02           ` Mathieu Othacehe
  2020-11-16 15:49         ` Miguel Ángel Arruga Vivas
  2020-11-17  9:30         ` Ludovic Courtès
  2 siblings, 1 reply; 23+ messages in thread
From: pelzflorian (Florian Pelz) @ 2020-11-16 11:47 UTC (permalink / raw)
  To: Mathieu Othacehe; +Cc: guix-devel

On Mon, Nov 16, 2020 at 10:12:09AM +0100, Mathieu Othacehe wrote:
> Many thanks (again) for your help here! According to the backtrace you
> sent earlier in this thread, it looks like the crash occurs in the
> "free-parted" procedure.
> 
> This procedure tries to unallocate Parted resources and waits for the
> partition table changes to be synchronized to disk. The
> "with-delay-device-in-use?" tries 4 times every 250ms to detect if the
> device is still in use.
> 
> Maybe it takes longer on your HW to synchronize the partition tables. If
> you could test the attached patch on top of 1.2.0 it would be terrific.
> 
> Thanks,
> 
> Mathieu


Thank you for the quick patch!  Clearly you have been spot-on.
“Partition formatting is in progress, please wait” is displayed
considerably longer but eventually succeeds.  I tried 3 times
successfully with your patch.  I tried again without your patch and it
failed.  I tried once more with your patch and formatting succeeded
again.

(Install failed due to a loss of network connectivity and restarting
is impossible, but that is less important, normally all works.)

Regards,
Florian


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-15 23:16     ` pelzflorian (Florian Pelz)
  2020-11-16  9:12       ` Mathieu Othacehe
@ 2020-11-16 15:39       ` Miguel Ángel Arruga Vivas
  1 sibling, 0 replies; 23+ messages in thread
From: Miguel Ángel Arruga Vivas @ 2020-11-16 15:39 UTC (permalink / raw)
  To: pelzflorian (Florian Pelz); +Cc: guix-devel, Mathieu Othacehe

Hallo, Leute!

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:
> 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.
[...]
> 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.
[...]
> I assume some formatting step had not completed in time.

From your log, the format didn't even took place, as it is the following
step from run-partitioning-page (at gnu/installer/newt/partition.scm),
but it was writing the partitions to the disk.  I think this comment
from free-parted (at gnu/installer/parted.scm) tells the same problem
you're hitting:

----------------------------------8<--------------------------------------
;; XXX: Formatting and further operations on disk partition table may fail
;; because the partition table changes are not synced, or because the device
;; is still in use, even if parted should have finished editing
;; partitions. This is not well understood, but syncing devices and waiting
;; them to stop returning EBUSY to BLKRRPART ioctl seems to be enough. The
;; same kind of issue is described here:
;; https://mail.gnome.org/archives/commits-list/2013-March/msg18423.html.
---------------------------------->8--------------------------------------

Nonetheless, we're only waiting 1 second + processing time to timeout
the lookup for EBUSY at 'with-delay-device-in-use?'.  Should we extend
that timeout?  I don't think waiting even minutes at this stage would be
a big issue, as formatting an encrypted partition may take hours and
will be performed just after that.

WDYT?

Happy hacking!
Miguel


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-16  9:12       ` Mathieu Othacehe
  2020-11-16 11:47         ` pelzflorian (Florian Pelz)
@ 2020-11-16 15:49         ` Miguel Ángel Arruga Vivas
  2020-11-17  9:06           ` Mathieu Othacehe
  2020-11-17  9:30         ` Ludovic Courtès
  2 siblings, 1 reply; 23+ messages in thread
From: Miguel Ángel Arruga Vivas @ 2020-11-16 15:49 UTC (permalink / raw)
  To: Mathieu Othacehe; +Cc: guix-devel

Hi,

I didn't update my mail so often and you've already solved it...  Sorry
for the noise and thank you for the patch.  :-)

Happy hacking!
Miguel


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-16  9:06   ` Ludovic Courtès
@ 2020-11-16 16:24     ` John Soo
  0 siblings, 0 replies; 23+ messages in thread
From: John Soo @ 2020-11-16 16:24 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix-Devel

[-- Attachment #1: Type: text/plain, Size: 193 bytes --]

     
 

 Hello,
 

 
I have a fix for emacs-guix. Once I make the repository on savannah, that patch should be easy to make.    I may be able to get to that around Wednesday.
 

 
- John
     

[-- Attachment #2: Type: text/html, Size: 353 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-16 11:47         ` pelzflorian (Florian Pelz)
@ 2020-11-17  9:02           ` Mathieu Othacehe
  2020-11-17 12:13             ` pelzflorian (Florian Pelz)
  0 siblings, 1 reply; 23+ messages in thread
From: Mathieu Othacehe @ 2020-11-17  9:02 UTC (permalink / raw)
  To: pelzflorian (Florian Pelz); +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]


Hello Florian,

> Thank you for the quick patch!  Clearly you have been spot-on.
> “Partition formatting is in progress, please wait” is displayed
> considerably longer but eventually succeeds.  I tried 3 times
> successfully with your patch.  I tried again without your patch and it
> failed.  I tried once more with your patch and formatting succeeded
> again.

That's good news! Here's a more complete patch that I intend to push on
the 1.2.0 branch. It logs the time spent waiting for disk
synchronization.

It would be great if you could test it one more time, so that we know if
4 seconds is enough or if we should use an even higher delay.

Thanks again,

Mathieu

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-installer-Fix-device-synchronization.patch --]
[-- Type: text/x-diff, Size: 4887 bytes --]

From f3d41cff6704ad748d51e4dd548c045034656b66 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe <othacehe@gnu.org>
Date: Tue, 17 Nov 2020 09:50:01 +0100
Subject: [PATCH] installer: Fix device synchronization.

Reported by Florian Pelz:
https://lists.gnu.org/archive/html/guix-devel/2020-11/msg00326.html.

* gnu/installer/utils.scm (call-with-time): New procedure,
(let/time): new macro.
* gnu/installer/parted.scm (with-delay-device-in-use?): Increase the retry
count to 16.
(non-install-devices): Remove the call to with-delay-device-in-use? as it
doesn't return the expected result, and would block much longer now.
(free-parted): Log the time required to sync each device.
---
 gnu/installer/parted.scm | 27 ++++++++++++++-------------
 gnu/installer/utils.scm  | 14 ++++++++++++++
 2 files changed, 28 insertions(+), 13 deletions(-)

diff --git a/gnu/installer/parted.scm b/gnu/installer/parted.scm
index f2352c5779..3ad1721795 100644
--- a/gnu/installer/parted.scm
+++ b/gnu/installer/parted.scm
@@ -41,6 +41,7 @@
   #:use-module (ice-9 regex)
   #:use-module (rnrs io ports)
   #:use-module (srfi srfi-1)
+  #:use-module (srfi srfi-19)
   #:use-module (srfi srfi-26)
   #:use-module (srfi srfi-34)
   #:use-module (srfi srfi-35)
@@ -318,7 +319,7 @@ PARTED-OBJECT field equals PARTITION, return #f if not found."
 fail. See rereadpt function in wipefs.c of util-linux for an explanation."
   ;; Kernel always return EINVAL for BLKRRPART on loopdevices.
   (and (not (string-match "/dev/loop*" file-name))
-       (let loop ((try 4))
+       (let loop ((try 16))
          (usleep 250000)
          (let ((in-use? (device-in-use? file-name)))
            (if (and in-use? (> try 0))
@@ -339,15 +340,12 @@ fail. See rereadpt function in wipefs.c of util-linux for an explanation."
 (define (non-install-devices)
   "Return all the available devices, except the busy one, allegedly the
 install device. DEVICE-IS-BUSY? is a parted call, checking if the device is
-mounted. The install image uses an overlayfs so the install device does not
-appear as mounted and won't be considered as busy. So use also DEVICE-IN-USE?
-from (guix build syscalls) module, who will try to re-read the device's
-partition table to determine whether or not it is already used (like sfdisk
-from util-linux)."
+mounted."
+  ;; FIXME: The install image uses an overlayfs so the install device does not
+  ;; appear as mounted and won't be considered as busy.
   (remove (lambda (device)
             (let ((file-name (device-path device)))
-              (or (device-is-busy? device)
-                  (with-delay-device-in-use? file-name))))
+              (device-is-busy? device)))
           (devices)))
 
 \f
@@ -1368,9 +1366,12 @@ the devices not to be used before returning."
   (let ((device-file-names (map device-path devices)))
     (for-each force-device-sync devices)
     (for-each (lambda (file-name)
-                (let ((in-use? (with-delay-device-in-use? file-name)))
-                  (and in-use?
-                       (error
-                        (format #f (G_ "Device ~a is still in use.")
-                                file-name)))))
+                (let/time ((time in-use?
+                                 (with-delay-device-in-use? file-name)))
+                  (if in-use?
+                      (error
+                       (format #f (G_ "Device ~a is still in use.")
+                               file-name))
+                      (syslog "Syncing ~a took ~a seconds.~%"
+                              file-name (time-second time)))))
               device-file-names)))
diff --git a/gnu/installer/utils.scm b/gnu/installer/utils.scm
index 5f8fe8ca01..a7fa66a199 100644
--- a/gnu/installer/utils.scm
+++ b/gnu/installer/utils.scm
@@ -22,6 +22,7 @@
   #:use-module (guix build utils)
   #:use-module (guix i18n)
   #:use-module (srfi srfi-1)
+  #:use-module (srfi srfi-19)
   #:use-module (srfi srfi-34)
   #:use-module (ice-9 match)
   #:use-module (ice-9 rdelim)
@@ -36,6 +37,8 @@
 
             syslog-port
             syslog
+            call-with-time
+            let/time
 
             with-server-socket
             current-server-socket
@@ -117,6 +120,17 @@ COMMAND exited successfully, #f otherwise."
 ;;; Logging.
 ;;;
 
+(define (call-with-time thunk kont)
+  "Call THUNK and pass KONT the elapsed time followed by THUNK's return
+values."
+  (let* ((start  (current-time time-monotonic))
+         (result (call-with-values thunk list))
+         (end    (current-time time-monotonic)))
+    (apply kont (time-difference end start) result)))
+
+(define-syntax-rule (let/time ((time result exp)) body ...)
+  (call-with-time (lambda () exp) (lambda (time result) body ...)))
+
 (define (open-syslog-port)
   "Return an open port (a socket) to /dev/log or #f if that wasn't possible."
   (let ((sock (socket AF_UNIX SOCK_DGRAM 0)))
-- 
2.29.2


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-16 15:49         ` Miguel Ángel Arruga Vivas
@ 2020-11-17  9:06           ` Mathieu Othacehe
  0 siblings, 0 replies; 23+ messages in thread
From: Mathieu Othacehe @ 2020-11-17  9:06 UTC (permalink / raw)
  To: Miguel Ángel Arruga Vivas; +Cc: guix-devel


Hello Miguel,

> I didn't update my mail so often and you've already solved it...  Sorry
> for the noise and thank you for the patch.  :-)

Thanks for having a look to this :). I sent an updated patch because the
first one could cause a regression in "non-install-devices" procedure I
think.

This procedure tries to find the install device by checking which
devices are busy using "with-delay-device-in-use?". Turns out it doesn't
work for me, plus it would now took a longer time if the delay is
higher.

In the updated patch, I removed the "with-delay-device-in-use?" call
from "non-install-devices", adding a note saying that it would be nice
to fix this procedure anyway.

What do you think about that?

Thanks,

Mathieu


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-16  9:12       ` Mathieu Othacehe
  2020-11-16 11:47         ` pelzflorian (Florian Pelz)
  2020-11-16 15:49         ` Miguel Ángel Arruga Vivas
@ 2020-11-17  9:30         ` Ludovic Courtès
  2020-11-17  9:38           ` Mathieu Othacehe
  2 siblings, 1 reply; 23+ messages in thread
From: Ludovic Courtès @ 2020-11-17  9:30 UTC (permalink / raw)
  To: Mathieu Othacehe; +Cc: guix-devel

Hi Mathieu,

Mathieu Othacehe <othacehe@gnu.org> skribis:

> From 6fec27303d0f8767ed48c507af67908a0fcf17a0 Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe <othacehe@gnu.org>
> Date: Mon, 16 Nov 2020 10:10:56 +0100
> Subject: [PATCH] Increase device use delay.
>
> ---
>  gnu/installer/parted.scm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gnu/installer/parted.scm b/gnu/installer/parted.scm
> index f2352c5779..ed3af6af85 100644
> --- a/gnu/installer/parted.scm
> +++ b/gnu/installer/parted.scm
> @@ -318,7 +318,7 @@ PARTED-OBJECT field equals PARTITION, return #f if not found."
>  fail. See rereadpt function in wipefs.c of util-linux for an explanation."
>    ;; Kernel always return EINVAL for BLKRRPART on loopdevices.
>    (and (not (string-match "/dev/loop*" file-name))
> -       (let loop ((try 4))
> +       (let loop ((try 16))
>           (usleep 250000)
>           (let ((in-use? (device-in-use? file-name)))
>             (if (and in-use? (> try 0))

Should we go ahead and apply this one?  Not polling would be nicer, but
maybe there’s no real way to do that?

BTW:

  (string-match "/dev/loop*" file-name)

should almost certainly be:

  (string-prefix? "/dev/loop" file-name)

The regexp above would match “/dev/loo”, “qux/dev/looppppppppabc”, etc.

WDYT?

Thanks,
Ludo’.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-17  9:30         ` Ludovic Courtès
@ 2020-11-17  9:38           ` Mathieu Othacehe
  2020-11-17 14:41             ` Ludovic Courtès
  0 siblings, 1 reply; 23+ messages in thread
From: Mathieu Othacehe @ 2020-11-17  9:38 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel


Hey Ludo,

> Should we go ahead and apply this one?  Not polling would be nicer, but
> maybe there’s no real way to do that?

I proposed a variant of this patch a few minutes ago. I added some time
logging and I would like to see what's the result on Florian machine to
see if the new delay is large enough.

> BTW:
>
>   (string-match "/dev/loop*" file-name)
>
> should almost certainly be:
>
>   (string-prefix? "/dev/loop" file-name)
>
> The regexp above would match “/dev/loo”, “qux/dev/looppppppppabc”, etc.

Oh you're right, I'll fix it.

Thanks,

Mathieu


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-17  9:02           ` Mathieu Othacehe
@ 2020-11-17 12:13             ` pelzflorian (Florian Pelz)
  0 siblings, 0 replies; 23+ messages in thread
From: pelzflorian (Florian Pelz) @ 2020-11-17 12:13 UTC (permalink / raw)
  To: Mathieu Othacehe; +Cc: guix-devel

On Tue, Nov 17, 2020 at 10:02:33AM +0100, Mathieu Othacehe wrote:
> That's good news! Here's a more complete patch that I intend to push on
> the 1.2.0 branch. It logs the time spent waiting for disk
> synchronization.
> 
> It would be great if you could test it one more time, so that we know if
> 4 seconds is enough or if we should use an even higher delay.
> 
> Thanks again,
> 
> Mathieu


It succeeded three times in a row.

Regards,
Florian


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-17  9:38           ` Mathieu Othacehe
@ 2020-11-17 14:41             ` Ludovic Courtès
  2020-11-17 15:26               ` zimoun
                                 ` (3 more replies)
  0 siblings, 4 replies; 23+ messages in thread
From: Ludovic Courtès @ 2020-11-17 14:41 UTC (permalink / raw)
  To: Mathieu Othacehe; +Cc: guix-devel

Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

>> Should we go ahead and apply this one?  Not polling would be nicer, but
>> maybe there’s no real way to do that?
>
> I proposed a variant of this patch a few minutes ago. I added some time
> logging and I would like to see what's the result on Florian machine to
> see if the new delay is large enough.

Awesome.

One this patch is in, I think we’re ready for either an RC2 or the real
thing.

WDYT?

Ludo’.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-17 14:41             ` Ludovic Courtès
@ 2020-11-17 15:26               ` zimoun
  2020-11-17 21:19                 ` Ludovic Courtès
  2020-11-17 15:41               ` pelzflorian (Florian Pelz)
                                 ` (2 subsequent siblings)
  3 siblings, 1 reply; 23+ messages in thread
From: zimoun @ 2020-11-17 15:26 UTC (permalink / raw)
  To: Ludovic Courtès, Mathieu Othacehe; +Cc: guix-devel

Hi,

On Tue, 17 Nov 2020 at 15:41, Ludovic Courtès <ludo@gnu.org> wrote:
> Mathieu Othacehe <othacehe@gnu.org> skribis:
>
>>> Should we go ahead and apply this one?  Not polling would be nicer, but
>>> maybe there’s no real way to do that?
>>
>> I proposed a variant of this patch a few minutes ago. I added some time
>> logging and I would like to see what's the result on Florian machine to
>> see if the new delay is large enough.
>
> Awesome.
>
> One this patch is in, I think we’re ready for either an RC2 or the real
> thing.

Real thing potential means “1.0.1” troubles.  On the other hand, I will
not have time to test more.  So… :-)

BTW, I am failing with Docker [1,2].  And aside, skopeo (the tool that
avoid the duplication of the image) seems broken.  Therefore, provide an
experimental Docker image should be postponed to the next release.

1: <https://yhetil.org/guix-devel/86pn4esca3.fsf@gmail.com>
2: <https://yhetil.org/guix-devel/86k0ums3xw.fsf@gmail.com>


All the best,
simon


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-17 14:41             ` Ludovic Courtès
  2020-11-17 15:26               ` zimoun
@ 2020-11-17 15:41               ` pelzflorian (Florian Pelz)
  2020-11-17 18:13               ` Mathieu Othacehe
  2020-11-17 23:12               ` Mark H Weaver
  3 siblings, 0 replies; 23+ messages in thread
From: pelzflorian (Florian Pelz) @ 2020-11-17 15:41 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel, Mathieu Othacehe

On Tue, Nov 17, 2020 at 03:41:34PM +0100, Ludovic Courtès wrote:
> One this patch is in, I think we’re ready for either an RC2 or the real
> thing.
> 
> WDYT?
> 
> Ludo’.

With the patch I see no problems on x86_64 Guix system, install script
or VM, but I have no idea of current Guix bugs.

Regards,
Florian


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-17 14:41             ` Ludovic Courtès
  2020-11-17 15:26               ` zimoun
  2020-11-17 15:41               ` pelzflorian (Florian Pelz)
@ 2020-11-17 18:13               ` Mathieu Othacehe
  2020-11-17 23:12               ` Mark H Weaver
  3 siblings, 0 replies; 23+ messages in thread
From: Mathieu Othacehe @ 2020-11-17 18:13 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel


Hey,

> One this patch is in, I think we’re ready for either an RC2 or the real
> thing.

Pushed to 1.2.0 and master. Thanks Florian for all the testing!

No objections to make the rc2 the final one.

Thanks,

Mathieu


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-17 15:26               ` zimoun
@ 2020-11-17 21:19                 ` Ludovic Courtès
  0 siblings, 0 replies; 23+ messages in thread
From: Ludovic Courtès @ 2020-11-17 21:19 UTC (permalink / raw)
  To: zimoun; +Cc: guix-devel, Mathieu Othacehe

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> BTW, I am failing with Docker [1,2].  And aside, skopeo (the tool that
> avoid the duplication of the image) seems broken.  Therefore, provide an
> experimental Docker image should be postponed to the next release.

Yes, that was my understanding.

Ludo’.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: GNU Guix 1.2.0rc1 available for testing!
  2020-11-17 14:41             ` Ludovic Courtès
                                 ` (2 preceding siblings ...)
  2020-11-17 18:13               ` Mathieu Othacehe
@ 2020-11-17 23:12               ` Mark H Weaver
  3 siblings, 0 replies; 23+ messages in thread
From: Mark H Weaver @ 2020-11-17 23:12 UTC (permalink / raw)
  To: Ludovic Courtès, Mathieu Othacehe; +Cc: guix-devel

Ludovic Courtès <ludo@gnu.org> writes:
> One this patch is in, I think we’re ready for either an RC2 or the real
> thing.
>
> WDYT?

FYI, within 8 hours I expect to push the IceCat 78.5 security update, in
case you'd like that to be in 1.2.0, but perhaps it doesn't matter much.

    Regards,
      Mark


^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2020-11-17 23:14 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-13 17:07 GNU Guix 1.2.0rc1 available for testing! Ludovic Courtès
2020-11-15 16:19 ` zimoun
2020-11-15 19:16 ` pelzflorian (Florian Pelz)
2020-11-15 21:53   ` Marius Bakke
2020-11-15 23:16     ` pelzflorian (Florian Pelz)
2020-11-16  9:12       ` Mathieu Othacehe
2020-11-16 11:47         ` pelzflorian (Florian Pelz)
2020-11-17  9:02           ` Mathieu Othacehe
2020-11-17 12:13             ` pelzflorian (Florian Pelz)
2020-11-16 15:49         ` Miguel Ángel Arruga Vivas
2020-11-17  9:06           ` Mathieu Othacehe
2020-11-17  9:30         ` Ludovic Courtès
2020-11-17  9:38           ` Mathieu Othacehe
2020-11-17 14:41             ` Ludovic Courtès
2020-11-17 15:26               ` zimoun
2020-11-17 21:19                 ` Ludovic Courtès
2020-11-17 15:41               ` pelzflorian (Florian Pelz)
2020-11-17 18:13               ` Mathieu Othacehe
2020-11-17 23:12               ` Mark H Weaver
2020-11-16 15:39       ` Miguel Ángel Arruga Vivas
2020-11-16  0:10 ` Oleg Pykhalov
2020-11-16  9:06   ` Ludovic Courtès
2020-11-16 16:24     ` John Soo

unofficial mirror of guix-devel@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guix-devel/0 guix-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-devel guix-devel/ https://yhetil.org/guix-devel \
		guix-devel@gnu.org
	public-inbox-index guix-devel

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.devel
	nntp://news.gmane.io/gmane.comp.gnu.guix.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git