Re: 1.1.0rc1 available for test!

[Ludovic Courtès]

Hi,

Vincent Legoll  skribis:

> On 13/04/2020 12:50, Ludovic Courtès wrote:
>> What changes are you referring to? (Sorry, I’m getting lost!)
>
> This: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=40601

Oh nice.  I don’t think that’ll make it into 1.1.0 but it’s a welcome
addition!

Ludo’.

Re: 1.1.0rc1 available for test!

[pelzflorian (Florian Pelz)]

On Fri, Apr 10, 2020 at 04:47:44PM +0200, pelzflorian (Florian Pelz) wrote:
> On Fri, Apr 10, 2020 at 04:35:18PM +0200, pelzflorian (Florian Pelz) wrote:
> > On Fri, Apr 10, 2020 at 03:56:21AM +0200, pelzflorian (Florian Pelz) wrote:
> > > For me the Guix System installer crashes reproducibly after manual
> > > partitioning, even when not formatting the partition.  The ESP and
> > > root partition have not been deleted (no matter if I tell the
> > > installer to format them or not).
> > 
> > Hmm I tried again today but formatting worked now sadly.  I do not
> > think I did anything differently.
> 
> Maybe the error only happens when choosing encryption; apparently I
> forgot to set up encryption on the working first try.
> 

The error when encrypting on my Macbook is gone on 1.1.0-rc2 via USB.
I do not know why and hope it is fixed (or the previous USB was bad).

I reinstalled successfully now after Manual partitioning.  Thanks to
all who made this possible!

Regards,
Florian

Re: 1.1.0rc1 available for test!

[Vincent Legoll]

Hello,

On 13/04/2020 12:50, Ludovic Courtès wrote:

What changes are you referring to? (Sorry, I’m getting lost!)


This: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=40601

--
Vincent Legoll

Re: 1.1.0rc1 available for test!

[Vincent Legoll]

Thanks again,

On 13/04/2020 12:50, Ludovic Courtès wrote:

The ‘guix-binary.x86_64-linux.tar.xz’ makefile target runs:
   guix pack guix …

So you would first need to update the ‘guix’ package, using:

   make update-guix-package

and committing the result.


What about the patch here:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=40597

then ?

--
Vincent Legoll

Re: 1.1.0rc1 available for test!

[Vincent Legoll]

Hello,

On 13/04/2020 12:50, Ludovic Courtès wrote:

Hi Vincent,

Vincent Legoll  skribis:


BTW, how would I test that (modified guix-install + nix/local.mk) ?

I've modified guix-install to handle runit-based distros (for void
linux) and nix/local.mk, like in the sysv-init enablement Danny
submitted lately.

I've seen the rebuild instructions at the end of binary installation
page in the manual, but I couldn't make that take my local
modifications in account. I think there's some required steps
that are only made by the release make target.

The ‘guix-binary.x86_64-linux.tar.xz’ makefile target runs:

   guix pack guix …

So you would first need to update the ‘guix’ package, using:

   make update-guix-package

and committing the result.



Thanks, I'll try that today.



I want to test, at least once before submitting my patch series
for review. Even if I think it would be nice-to-have for the 1.1.0...

What changes are you referring to?  (Sorry, I’m getting lost!)



The support for runit-based distros in guix-install.sh & its

accompanying added file in the binary tarball. But I will

not ask to delay the release for that though, just if it can

be merged before the final build ok.


--

Vincent Legoll

Re: 1.1.0rc1 available for test!

[Ludovic Courtès]

Hi Vincent,

Vincent Legoll  skribis:

> BTW, how would I test that (modified guix-install + nix/local.mk) ?
>
> I've modified guix-install to handle runit-based distros (for void
> linux) and nix/local.mk, like in the sysv-init enablement Danny
> submitted lately.
>
> I've seen the rebuild instructions at the end of binary installation
> page in the manual, but I couldn't make that take my local
> modifications in account. I think there's some required steps
> that are only made by the release make target.

The ‘guix-binary.x86_64-linux.tar.xz’ makefile target runs:

  guix pack guix …

So you would first need to update the ‘guix’ package, using:

  make update-guix-package

and committing the result.

> I want to test, at least once before submitting my patch series
> for review. Even if I think it would be nice-to-have for the 1.1.0...

What changes are you referring to?  (Sorry, I’m getting lost!)

Thanks,
Ludo’.

Re: 1.1.0rc1 available for test!

[Vincent Legoll]

Hello,

On Sun, Apr 12, 2020 at 12:26 AM Ludovic Courtès  wrote:
> Did you use ‘guix-install.sh’ (modified) or did you install it manually?

I used a modified guix-install.sh for the void testing (I'll submit
the modifications) but not for the others. I'll do future testing
with it, as it is the recommended way to setup guix on a foreign
distro.

BTW, how would I test that (modified guix-install + nix/local.mk) ?

I've modified guix-install to handle runit-based distros (for void
linux) and nix/local.mk, like in the sysv-init enablement Danny
submitted lately.

I've seen the rebuild instructions at the end of binary installation
page in the manual, but I couldn't make that take my local
modifications in account. I think there's some required steps
that are only made by the release make target.

I want to test, at least once before submitting my patch series
for review. Even if I think it would be nice-to-have for the 1.1.0...

> > (*) those tried to rebuild a lot of things locally at step 5,
> > so I stopped them. Maybe an operator error...
>
> Could be that substitutes were missing.

Yes, that's also possible, how would I check / ensure that ?

> > I'm still working on automating those tests though...
>
> Heh, we’ll have them for 1.2.  ;-)

Hopefully.

Thanks

-- 
Vincent Legoll

Re: 1.1.0rc1 available for test!

[Ludovic Courtès]

Hi Vincent,

Vincent Legoll  skribis:

> I tested the 1.1.0rc1 binary with the following commands:
>
> 1) guix search hello
> 2) guix show hello
> 3) guix build hello
> 4) guix gc -D /gnu/store/*hello*
> 5) guix build --no-substitutes hello
> 6) guix gc
>
> On the following foreign distros:
>
> i686 void 20191109 (glibc) (qemu / kvm) (*)
> x86-64 debian 9 stretch 20200210-166 (qemu / kvm)
> x86-64 debian 10 buster 20200410-227 (qemu / kvm)
> armhf  armbian 20.02.1 bionic (kernel 5.4.20) (orangepi+2e)
> aarch64 armbian 5.95 stretch (kernel 4.9.190) (odroid n2) (*)

Woow, thanks a lot!

Did you use ‘guix-install.sh’ (modified) or did you install it manually?

> (*) those tried to rebuild a lot of things locally at step 5,
> so I stopped them. Maybe an operator error...

Could be that substitutes were missing.

> I'm still working on automating those tests though...

Heh, we’ll have them for 1.2.  ;-)

Thank you!

Ludo’.

Re: 1.1.0rc1 available for test!

[Amin Bandali]

alex sassmannshausen  writes:

> Heya
>
> On Sat, 11 Apr 2020, 00:38 Ludovic Courtès,  wrote:
>
>> Hi Alex,
>>
>> Alex Sassmannshausen  skribis:
>>
>> > After successfully completing system setup from the ISO using that
>> > selection, rebooting the system launches GDM OK.  Signing in to GDM
>> > however causes the system to loop back to GDM, instead of starting a
>> > ratpoison session.  It is not clear to me what causes the issue, but I'm
>> > happy to help debug if someone can provide me with pointers on doing so.
>> >
>> > Intuitively, I would hazard a guess that the initialisation of ratpoison
>> > fails and the session is aborted, at which point GDM is restarted.
>>
>> Isn’t it just that GDM defaults to GNOME (not ratpoison), but since
>> GNOME isn’t available, it loops back?
>>
>> What if you click on the small gear and select ratpoison?
>>
>
> You are 100% correct! Thanks for that pointer - I hadn't considered it
> would still default to gnome! :)
>

Not sure if this was ever reported, but IMHO, that GDM defaults to a
(nonexistent) GNOME shell option by default even when e.g. Xfce is
installed rather than GNOME, is a bug.  I recall that for a default
installation, GDM would be correctly set to start Xfce by default, but
after the first upgrade and reboot, it would automatically be changed to
GNOME, which would obviously not work when trying to log in, and one
would have to set it back to Xfce once again.  I remember being puzzled
by this when it first occurred to me.

>
> Cheers,
>
> Alex
>
>
>
>> Thanks for your feedback!
>>
>> Ludo’.
>>


signature.asc
Description: PGP signature

Re: 1.1.0rc1 available for test!

[Vincent Legoll]

Hello,

I tested the 1.1.0rc1 binary with the following commands:

1) guix search hello
2) guix show hello
3) guix build hello
4) guix gc -D /gnu/store/*hello*
5) guix build --no-substitutes hello
6) guix gc

On the following foreign distros:

i686 void 20191109 (glibc) (qemu / kvm) (*)
x86-64 debian 9 stretch 20200210-166 (qemu / kvm)
x86-64 debian 10 buster 20200410-227 (qemu / kvm)
armhf  armbian 20.02.1 bionic (kernel 5.4.20) (orangepi+2e)
aarch64 armbian 5.95 stretch (kernel 4.9.190) (odroid n2) (*)

(*) those tried to rebuild a lot of things locally at step 5,
so I stopped them. Maybe an operator error...

Looks like everything's working properly...

Congrats !

I'm still working on automating those tests though...

-- 
Vincent Legoll

Re: 1.1.0rc1 available for test!

[alex sassmannshausen]

Heya

On Sat, 11 Apr 2020, 00:38 Ludovic Courtès,  wrote:

> Hi Alex,
>
> Alex Sassmannshausen  skribis:
>
> > After successfully completing system setup from the ISO using that
> > selection, rebooting the system launches GDM OK.  Signing in to GDM
> > however causes the system to loop back to GDM, instead of starting a
> > ratpoison session.  It is not clear to me what causes the issue, but I'm
> > happy to help debug if someone can provide me with pointers on doing so.
> >
> > Intuitively, I would hazard a guess that the initialisation of ratpoison
> > fails and the session is aborted, at which point GDM is restarted.
>
> Isn’t it just that GDM defaults to GNOME (not ratpoison), but since
> GNOME isn’t available, it loops back?
>
> What if you click on the small gear and select ratpoison?
>

You are 100% correct! Thanks for that pointer - I hadn't considered it
would still default to gnome! :)

Cheers,

Alex



> Thanks for your feedback!
>
> Ludo’.
>

Re: 1.1.0rc1 available for test!

[Ludovic Courtès]

Hi Alex,

Alex Sassmannshausen  skribis:

> After successfully completing system setup from the ISO using that
> selection, rebooting the system launches GDM OK.  Signing in to GDM
> however causes the system to loop back to GDM, instead of starting a
> ratpoison session.  It is not clear to me what causes the issue, but I'm
> happy to help debug if someone can provide me with pointers on doing so.
>
> Intuitively, I would hazard a guess that the initialisation of ratpoison
> fails and the session is aborted, at which point GDM is restarted.

Isn’t it just that GDM defaults to GNOME (not ratpoison), but since
GNOME isn’t available, it loops back?

What if you click on the small gear and select ratpoison?

Thanks for your feedback!

Ludo’.

Re: 1.1.0rc1 available for test!

[Alex Sassmannshausen]

Heya

Ludovic Courtès  writes:

> Hi!
>
> Mathieu Othacehe  skribis:
>
>>> * Esperanto language/layout crashes the installer.
>>
>> Fixed by 1a24df44347629cd67821d672edad7636404f293 on master.
>>
>> Ludo, you may want to cherry-pick it to 1.1.0 branch :)
>
> Done!
>
> Thanks for testing & fixing, comrades!
>
> Ludo’.

This is amazing — really cool to see how quickly this was resolved!  Now
to learning Esperanto by using it on my spare computer… ;-)

Alex

Re: 1.1.0rc1 available for test!

[Alex Sassmannshausen]

Hello,

A minor useability issue:

At the end of installation, a prompt suggests installation is complete
and that the system is ready for reboot.

However, it suggests one can remove the installation medium before
hitting return to restart.

For me at least, removing the pendrive prior to reboot caused the system
to hang.  Only a hard power off got me out of that hang.  The system
seems to work fine aftarwards.

Perhaps the message could be improved by reversing the order of
restarting and removing boot media?

Best wishes,

Alex

Ludovic Courtès  writes:

> Hello Guix!
>
> I’ve run “make release” from the new ‘version-1.1.0’ branch and uploaded
> the result:
>
>   https://web.fdn.fr/~lcourtes/software/guix/1.1.0rc1
>
> Alternately (and preferably), you can get it over IPFS:
>
>   guix install ipfs
>   ipfs daemon &
>   ipfs ls QmXpSUnppJgf23LpaKJzRWJbQxwEfybJy9VxF79iTLSXqa
>   ipfs get …
>
> All the files are signed with my key, also used to sign this message.
>
> Please test things as much as you can, be it the binary installation
> tarball on a “foreign” distro or the ISO image.  Once you’ve downloaded,
> just follow the same instructions as before (if you want to use
> ‘guix-install.sh’, you’ll have to adjust it to use the right tarball):
>
>   https://guix.gnu.org/download/
>
> If you encounter an issue, please report it to bug-g...@gnu.org,
> explaining what you did and what you observed.
>
> Notice that there’s no i686-linux installation image and no VM image,
> because of  but i can provide
> those later.
>
> If everything goes well, we can publish the release on Monday, 13th,
> with few or no changes beyond translation updates on the ‘version-1.1.0’
> branch.
>
> Thanks in advance!  :-)
>
> Ludo’.

Re: 1.1.0rc1 available for test!

[Alex Sassmannshausen]

Hello!

I have spotted a further issue — though I'm not sure whether this thread
is the right place to report it:

One is able to select ratpoison as the only option in the desktop
environment options in the installer.

After successfully completing system setup from the ISO using that
selection, rebooting the system launches GDM OK.  Signing in to GDM
however causes the system to loop back to GDM, instead of starting a
ratpoison session.  It is not clear to me what causes the issue, but I'm
happy to help debug if someone can provide me with pointers on doing so.

Intuitively, I would hazard a guess that the initialisation of ratpoison
fails and the session is aborted, at which point GDM is restarted.

Best wishes,

Alex

Ludovic Courtès  writes:

> Hello Guix!
>
> I’ve run “make release” from the new ‘version-1.1.0’ branch and uploaded
> the result:
>
>   https://web.fdn.fr/~lcourtes/software/guix/1.1.0rc1
>
> Alternately (and preferably), you can get it over IPFS:
>
>   guix install ipfs
>   ipfs daemon &
>   ipfs ls QmXpSUnppJgf23LpaKJzRWJbQxwEfybJy9VxF79iTLSXqa
>   ipfs get …
>
> All the files are signed with my key, also used to sign this message.
>
> Please test things as much as you can, be it the binary installation
> tarball on a “foreign” distro or the ISO image.  Once you’ve downloaded,
> just follow the same instructions as before (if you want to use
> ‘guix-install.sh’, you’ll have to adjust it to use the right tarball):
>
>   https://guix.gnu.org/download/
>
> If you encounter an issue, please report it to bug-g...@gnu.org,
> explaining what you did and what you observed.
>
> Notice that there’s no i686-linux installation image and no VM image,
> because of  but i can provide
> those later.
>
> If everything goes well, we can publish the release on Monday, 13th,
> with few or no changes beyond translation updates on the ‘version-1.1.0’
> branch.
>
> Thanks in advance!  :-)
>
> Ludo’.

Re: 1.1.0rc1 available for test!

[pelzflorian (Florian Pelz)]

On Fri, Apr 10, 2020 at 04:35:18PM +0200, pelzflorian (Florian Pelz) wrote:
> On Fri, Apr 10, 2020 at 03:56:21AM +0200, pelzflorian (Florian Pelz) wrote:
> > For me the Guix System installer crashes reproducibly after manual
> > partitioning, even when not formatting the partition.  The ESP and
> > root partition have not been deleted (no matter if I tell the
> > installer to format them or not).
> 
> Hmm I tried again today but formatting worked now sadly.  I do not
> think I did anything differently.

Maybe the error only happens when choosing encryption; apparently I
forgot to set up encryption on the working first try.

Re: 1.1.0rc1 available for test!

[Ludovic Courtès]

Hi!

Mathieu Othacehe  skribis:

>> * Esperanto language/layout crashes the installer.
>
> Fixed by 1a24df44347629cd67821d672edad7636404f293 on master.
>
> Ludo, you may want to cherry-pick it to 1.1.0 branch :)

Done!

Thanks for testing & fixing, comrades!

Ludo’.

Re: 1.1.0rc1 available for test!

[Mathieu Othacehe]

> * Esperanto language/layout crashes the installer.

Fixed by 1a24df44347629cd67821d672edad7636404f293 on master.

Ludo, you may want to cherry-pick it to 1.1.0 branch :)

Mathieu

Re: 1.1.0rc1 available for test!

[Alex Sassmannshausen]

Great, thank you for that summary, I think that is right.

I've noticed a further (small?) error:

On installation completion an error flashes up.  When I checked
/var/log/debug, the message is:
…localhost shepherd[1]: system-error("rmdir" "~A" ("Directory not empty") (39))

Best wishes,

Alex


Mathieu Othacehe  writes:

>> As the system language & locale rather than 
>> - Esperanto
>
> I can reproduce it in QEMU. So there are two issues here:
>
> * Esperanto language/layout crashes the installer.
>
> * When the installer crashes, `umount-cow-store' is not called and the next
> installation is bound to fail because some mounted partitions are still 
> around.
>
> Maybe we need to call this procedure at installer start, in case the
> previous installation has crashed.
>
> Thanks for reporting!
>
> Mathieu

Re: 1.1.0rc1 available for test!

[Alex Sassmannshausen]

Hi Mathieu,

Thanks for getting back to me!

Mathieu Othacehe  writes:

> Hello Alex,
>
> Thanks for your feedback!
>
>> Then the screen flashes back to the beginning of the installer.  Running
>> through the process again results in the disk drive not being available
>> for partitioning.
>
> Are you running the installer on a VM or on real hardware?

Real hardware.

> Could you try the following steps:
>
> * Run the installation until it fails and restart.
> * Press Ctrl-Alt-2.
> * Type "sendkey ctrl-alt-f3".
> * Then press Ctrl-Alt-1 and Enter.
> * Check if there is a /tmp/last-installer-error file and, if yes, report
> its content.

This I could not do: Ctrl-Alt-2 doesn't do anything, but I imagine you
meant Ctrl-Alt-f2?  That takes me to the manual.

However, once the installer reloads, I can hit Ctrl-Alt-f3 and Enter to
get to a prompt.

There is no /tmp/last-installer-error file :-(

I did check /var/log/debug.  There I can trace the configuration
process.

After "running form # ("Configuration file") with 0
clients" I get:
…Service cow-store has been started.
…Service cow-store has been stopped.
…Service guix-daemon has been stopped.
…Service guix-daemon has been started.
…Umounted /remove successfully.
…unmounting "/mnt"
…closing LUKS entry "cryptroot"
…running step 'locale'

The last presumably is the installer restarting.

Hth,

Alex

>
> Thanks,
>
> Mathieu

Re: 1.1.0rc1 available for test!

[Mathieu Othacehe]

> As the system language & locale rather than 
> - Esperanto

I can reproduce it in QEMU. So there are two issues here:

* Esperanto language/layout crashes the installer.

* When the installer crashes, `umount-cow-store' is not called and the next
installation is bound to fail because some mounted partitions are still around.

Maybe we need to call this procedure at installer start, in case the
previous installation has crashed.

Thanks for reporting!

Mathieu

Re: 1.1.0rc1 available for test!

[Alex Sassmannshausen]

I have been able to avoid this error by selecting:
- English
- United Kingdom

As the system language & locale rather than 
- Esperanto

which I had previously selected.

I tried a great number of combinations of configurations, and this seems
to have been the one thing that reliably crashed (when choosing
Esperanto) or fixed (when Choosing English/UK).

After this the installation seems to be going swimmingly.

Hth,

Alex


Alex Sassmannshausen  writes:

> Hello,
>
> Running the graphical installer from the installation image hosted
> through IPFS, I can report the following experience:
>
> The guidance, keyboard configuration & partitioning works well.  In fact
> all goes charmingly until the stage where the sysconf is shown.  That
> looks correct too.
>
> Hitting continue at that point switches to a terminal wher I briefly see
> cow-store being started.
>
> Then the screen flashes back to the beginning of the installer.  Running
> through the process again results in the disk drive not being available
> for partitioning.
>
> I cannot see any error messages in the brief time I see the terminal and
> am not sure how to get an error log.
>
> Happy to run some more commands to get additional information.
>
> Best wishes,
>
> Alex
>
> Ludovic Courtès  writes:
>
>> Hello Guix!
>>
>> I’ve run “make release” from the new ‘version-1.1.0’ branch and uploaded
>> the result:
>>
>>   https://web.fdn.fr/~lcourtes/software/guix/1.1.0rc1
>>
>> Alternately (and preferably), you can get it over IPFS:
>>
>>   guix install ipfs
>>   ipfs daemon &
>>   ipfs ls QmXpSUnppJgf23LpaKJzRWJbQxwEfybJy9VxF79iTLSXqa
>>   ipfs get …
>>
>> All the files are signed with my key, also used to sign this message.
>>
>> Please test things as much as you can, be it the binary installation
>> tarball on a “foreign” distro or the ISO image.  Once you’ve downloaded,
>> just follow the same instructions as before (if you want to use
>> ‘guix-install.sh’, you’ll have to adjust it to use the right tarball):
>>
>>   https://guix.gnu.org/download/
>>
>> If you encounter an issue, please report it to bug-g...@gnu.org,
>> explaining what you did and what you observed.
>>
>> Notice that there’s no i686-linux installation image and no VM image,
>> because of  but i can provide
>> those later.
>>
>> If everything goes well, we can publish the release on Monday, 13th,
>> with few or no changes beyond translation updates on the ‘version-1.1.0’
>> branch.
>>
>> Thanks in advance!  :-)
>>
>> Ludo’.

Re: 1.1.0rc1 available for test!

[Mathieu Othacehe]

Hello Florian,

> For me the Guix System installer crashes reproducibly after manual
> partitioning, even when not formatting the partition.  The ESP and
> root partition have not been deleted (no matter if I tell the
> installer to format them or not).  This applies to EFI installation on
> my 2010 Macbook but not in QEMU.  Perhaps the reason is the partition
> I’m trying to format previously was LUKS-encrypted.

Could you share your hard drive layout (size and partitions) and the
content of `dmesg' and `/var/log/messages' ?

Thanks for your help,

Mathieu

Re: 1.1.0rc1 available for test!

[Mathieu Othacehe]

Hello Alex,

Thanks for your feedback!

> Then the screen flashes back to the beginning of the installer.  Running
> through the process again results in the disk drive not being available
> for partitioning.

Are you running the installer on a VM or on real hardware? Could you try
the following steps:

* Run the installation until it fails and restart.
* Press Ctrl-Alt-2.
* Type "sendkey ctrl-alt-f3".
* Then press Ctrl-Alt-1 and Enter.
* Check if there is a /tmp/last-installer-error file and, if yes, report
its content.

Thanks,

Mathieu

Re: 1.1.0rc1 available for test!

[Alex Sassmannshausen]

Hello,

Running the graphical installer from the installation image hosted
through IPFS, I can report the following experience:

The guidance, keyboard configuration & partitioning works well.  In fact
all goes charmingly until the stage where the sysconf is shown.  That
looks correct too.

Hitting continue at that point switches to a terminal wher I briefly see
cow-store being started.

Then the screen flashes back to the beginning of the installer.  Running
through the process again results in the disk drive not being available
for partitioning.

I cannot see any error messages in the brief time I see the terminal and
am not sure how to get an error log.

Happy to run some more commands to get additional information.

Best wishes,

Alex

Ludovic Courtès  writes:

> Hello Guix!
>
> I’ve run “make release” from the new ‘version-1.1.0’ branch and uploaded
> the result:
>
>   https://web.fdn.fr/~lcourtes/software/guix/1.1.0rc1
>
> Alternately (and preferably), you can get it over IPFS:
>
>   guix install ipfs
>   ipfs daemon &
>   ipfs ls QmXpSUnppJgf23LpaKJzRWJbQxwEfybJy9VxF79iTLSXqa
>   ipfs get …
>
> All the files are signed with my key, also used to sign this message.
>
> Please test things as much as you can, be it the binary installation
> tarball on a “foreign” distro or the ISO image.  Once you’ve downloaded,
> just follow the same instructions as before (if you want to use
> ‘guix-install.sh’, you’ll have to adjust it to use the right tarball):
>
>   https://guix.gnu.org/download/
>
> If you encounter an issue, please report it to bug-g...@gnu.org,
> explaining what you did and what you observed.
>
> Notice that there’s no i686-linux installation image and no VM image,
> because of  but i can provide
> those later.
>
> If everything goes well, we can publish the release on Monday, 13th,
> with few or no changes beyond translation updates on the ‘version-1.1.0’
> branch.
>
> Thanks in advance!  :-)
>
> Ludo’.

Re: 1.1.0rc1 available for test!

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)"  skribis:

> For me the Guix System installer crashes reproducibly after manual
> partitioning, even when not formatting the partition.  The ESP and
> root partition have not been deleted (no matter if I tell the
> installer to format them or not).  This applies to EFI installation on
> my 2010 Macbook but not in QEMU.  Perhaps the reason is the partition
> I’m trying to format previously was LUKS-encrypted.

Did you capture the backtrace from /tmp/last-installer-error?  That
would be great.

> I switch to a console and type
>
> /gnu/store/*kmscon*/bin/kmscon --debug --login /gnu/store/*installer 2>out
>
> The suspicious part of the output is at time 60:
>
> [0015.940745] DEBUG: uterm_uxkb: new keyboard description (pc105, us, 
> altgr-intl, ) (uxkb_desc_init() in src/uterm_input_uxkb.c:160)
> [0060.006214] DEBUG: pty: cannot read from pty of child 364 (5): Input/output 
> error (read_buf() in src/pty.c:478)
> [0060.006281] DEBUG: pty: HUP on pty of child 364 (pty_input() in 
> src/pty.c:520)
> [0060.006612] DEBUG: eloop: child 364 exited successfully (sig_child() in 
> src/eloop.c:353)
> [0060.006627] INFO: pty: child exited: pid: 364 status: 0 (sig_child() in 
> src/pty.c:536)
> [0060.007224] DEBUG: pty: forking child 414 (pty_spawn() in src/pty.c:422)
> [0091.233270] DEBUG: vt: deactivating VT 7 to 4 due to user input 
> (real_input() in src/uterm_vt.c:578)
> [0091.233319] DEBUG: vt: leaving VT 7 0x10c68c0 due to VT signal 
> (real_sig_leave() in src/uterm_vt.c:231)
> [0091.27] DEBUG: seat: deactivate session 0x1153ae0 
> (session_call_deactivate() in src/kmscon_seat.c:125)
> [0091.233351] DEBUG: video: go asleep (uterm_video_sleep() in 
> src/uterm_video.c:663)
> [0091.233376] DEBUG: uterm_input: going to sleep (uterm_input_sleep() in 
> src/uterm_input.c:441)

I don’t understand; what is this telling us?

> I tested an installer manually created from the version-1.1.0 branch
> with Tobias’ compression patch applied
> .
> I believe it makes no difference.  I would really like that compression.

I’ll run the installer tests on ISO9660, with the patch applied, and if
everything goes well, we can use it (and roll an RC2, I guess.)

> On an Acer Aspire 5738PG with ATI Mobility Radeon HD 4570 the
> installer remains black.  I pressed ctrl-alt-f3 and typed
>
> modprobe uvesafb v86d=$(guix build v86d | head -n1)/sbin/v86d 
> mode_option=1024x768

Could we come up with a udev rule or a modprobe.d snippet so that this
happens automatically?

I found things like:

  https://bbs.archlinux.org/viewtopic.php?id=165480

Or should we give up on v86d like Gentoo:

  https://wiki.gentoo.org/wiki/Uvesafb

?

(Perhaps this is best discussed in a specific issue on bug-guix.)

Thanks for the detailed report, as always!

Ludo’.

Re: 1.1.0rc1 available for test!

[Ludovic Courtès]

Hi Vagrant,

Vagrant Cascadian  skribis:

> On 2020-04-09, Ludovic Courtès wrote:
>> Hello Guix!
>>
>> I’ve run “make release” from the new ‘version-1.1.0’ branch and uploaded
>> the result:
>>
>>   https://web.fdn.fr/~lcourtes/software/guix/1.1.0rc1
>
> The only tarball I see there is:
>
>   
> https://web.fdn.fr/~lcourtes/software/guix/1.1.0rc1/guix-1.0.1.13450-01d5f2.tar.gz
>
> Which does not correspond to the commit from 01d5f2 (which happens to be
> a few hundred commits behind master)... 

The machinery picked up a stale commit ID.  Fixed in
08b14ab20ebe181690df6210a0b3f95bad494af5.

> Which commit was it actually built with? I know it's not a release, per
> se, but git tags would be *really* helpful even for release candidates...

The source tarball corresponds to
98148830c0afb9adc8acf150afc48f09aae42ac1 on ‘version-1.1.0’.  I’ve added
a tag now.

However, “make release” creates two additional commits as it updates the
‘guix’ package, and I chose to not push them.

> When building my own local guix tarballs, I found it disturbingly easy
> to get the wrong version information into the tarball .version and
> .tarball-version and consequently the resulting tarball...

Agreed, sorry for the confusion.

> I notice gnu/services/linux.scm is also missing in some of my locally
> built git snapshot tarballs, so there appears to be something broken in
> the tarball generation process.

I see you fixed it in the meantime.

Thanks for reporting these issues!

Ludo’.

Re: 1.1.0rc1 available for test!

[Vagrant Cascadian]

On 2020-04-09, Ludovic Courtès wrote:
> Hello Guix!
>
> I’ve run “make release” from the new ‘version-1.1.0’ branch and uploaded
> the result:
>
>   https://web.fdn.fr/~lcourtes/software/guix/1.1.0rc1

The only tarball I see there is:

  
https://web.fdn.fr/~lcourtes/software/guix/1.1.0rc1/guix-1.0.1.13450-01d5f2.tar.gz

Which does not correspond to the commit from 01d5f2 (which happens to be
a few hundred commits behind master)... 

Which commit was it actually built with? I know it's not a release, per
se, but git tags would be *really* helpful even for release candidates...

When building my own local guix tarballs, I found it disturbingly easy
to get the wrong version information into the tarball .version and
.tarball-version and consequently the resulting tarball...


It also appears to be missing gnu/services/linux.scm, which causes it to
fail to build when I attempt to build the debian package:

  [ 49%] LOAD gnu/tests/linux-modules.scm
  WARNING: (guix build download-nar): `dump-port*' imported from both (guix 
serialization) and (guix progress)
  ;;; Failed to autoload make-page-map in (charting):
  ;;; missing interface for module (charting)
  ;;; Failed to autoload make-page-map in (charting):
  ;;; missing interface for module (charting)
  random seed for tests: 1586480372
  error: failed to load 'gnu/tests/linux-modules.scm':
  ice-9/eval.scm:293:34: no code for module (gnu services linux)
  
  Some deprecated features have been used.  Set the environment
  variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
  program to get more information.  Set it to "no" to suppress
  this message.
  make[3]: *** [Makefile:5859: make-go] Error 1
  make[3]: Leaving directory '/<>'

But gnu/services/linux.scm is present in git...

I notice gnu/services/linux.scm is also missing in some of my locally
built git snapshot tarballs, so there appears to be something broken in
the tarball generation process.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: 1.1.0rc1 available for test!

[pelzflorian (Florian Pelz)]

On Thu, Apr 09, 2020 at 10:51:49PM +0200, Ludovic Courtès wrote:
> If everything goes well, we can publish the release on Monday, 13th,
> with few or no changes beyond translation updates on the ‘version-1.1.0’
> branch.


For me the Guix System installer crashes reproducibly after manual
partitioning, even when not formatting the partition.  The ESP and
root partition have not been deleted (no matter if I tell the
installer to format them or not).  This applies to EFI installation on
my 2010 Macbook but not in QEMU.  Perhaps the reason is the partition
I’m trying to format previously was LUKS-encrypted.

I switch to a console and type

/gnu/store/*kmscon*/bin/kmscon --debug --login /gnu/store/*installer 2>out

The suspicious part of the output is at time 60:

[0015.940745] DEBUG: uterm_uxkb: new keyboard description (pc105, us, 
altgr-intl, ) (uxkb_desc_init() in src/uterm_input_uxkb.c:160)
[0060.006214] DEBUG: pty: cannot read from pty of child 364 (5): Input/output 
error (read_buf() in src/pty.c:478)
[0060.006281] DEBUG: pty: HUP on pty of child 364 (pty_input() in src/pty.c:520)
[0060.006612] DEBUG: eloop: child 364 exited successfully (sig_child() in 
src/eloop.c:353)
[0060.006627] INFO: pty: child exited: pid: 364 status: 0 (sig_child() in 
src/pty.c:536)
[0060.007224] DEBUG: pty: forking child 414 (pty_spawn() in src/pty.c:422)
[0091.233270] DEBUG: vt: deactivating VT 7 to 4 due to user input (real_input() 
in src/uterm_vt.c:578)
[0091.233319] DEBUG: vt: leaving VT 7 0x10c68c0 due to VT signal 
(real_sig_leave() in src/uterm_vt.c:231)
[0091.27] DEBUG: seat: deactivate session 0x1153ae0 
(session_call_deactivate() in src/kmscon_seat.c:125)
[0091.233351] DEBUG: video: go asleep (uterm_video_sleep() in 
src/uterm_video.c:663)
[0091.233376] DEBUG: uterm_input: going to sleep (uterm_input_sleep() in 
src/uterm_input.c:441)


I tested an installer manually created from the version-1.1.0 branch
with Tobias’ compression patch applied
.
I believe it makes no difference.  I would really like that compression.

In QEMU I can even install with a toggle layout even though the guix
package appears not to have been updated to include your fix.
Strange.


On an Acer Aspire 5738PG with ATI Mobility Radeon HD 4570 the
installer remains black.  I pressed ctrl-alt-f3 and typed

modprobe uvesafb v86d=$(guix build v86d | head -n1)/sbin/v86d 
mode_option=1024x768

but it says “guix build: error: v86d: unknown package”, probably
because the guix package has not been updated recently.

Regards,
Florian

Re: 1.1.0rc1 available for test!

[Danny Milosavljevic]

Hi Ludo,

nice!

On Thu, 09 Apr 2020 22:51:49 +0200
Ludovic Courtès  wrote:

> guix install ipfs

guix install go-ipfs ? :)

> ipfs daemon &

Error: no IPFS repo found in /home/dannym/.ipfs.
please run: 'ipfs init'

After invoking that, ipfs daemon works.


pgpSuwfUh8TcV.pgp
Description: OpenPGP digital signature

1.1.0rc1 available for test!

[Ludovic Courtès]

Hello Guix!

I’ve run “make release” from the new ‘version-1.1.0’ branch and uploaded
the result:

  https://web.fdn.fr/~lcourtes/software/guix/1.1.0rc1

Alternately (and preferably), you can get it over IPFS:

  guix install ipfs
  ipfs daemon &
  ipfs ls QmXpSUnppJgf23LpaKJzRWJbQxwEfybJy9VxF79iTLSXqa
  ipfs get …

All the files are signed with my key, also used to sign this message.

Please test things as much as you can, be it the binary installation
tarball on a “foreign” distro or the ISO image.  Once you’ve downloaded,
just follow the same instructions as before (if you want to use
‘guix-install.sh’, you’ll have to adjust it to use the right tarball):

  https://guix.gnu.org/download/

If you encounter an issue, please report it to bug-g...@gnu.org,
explaining what you did and what you observed.

Notice that there’s no i686-linux installation image and no VM image,
because of  but i can provide
those later.

If everything goes well, we can publish the release on Monday, 13th,
with few or no changes beyond translation updates on the ‘version-1.1.0’
branch.

Thanks in advance!  :-)

Ludo’.


signature.asc
Description: PGP signature