Re: Changing HTTP proxy settings in GuixSD

[Mark H Weaver]

Hi,

l...@gnu.org (Ludovic Courtès) writes:
> It turned out to come from a typo in Guile 2.2’s web client, now fixed
> here:
>
>   
> https://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.2&id=7d0d9e2c25c1e872cfc7d14ab5139915f1813d56

[...]

> diff --git a/module/web/http.scm b/module/web/http.scm
> index 993b50e..62f0624 100644
> --- a/module/web/http.scm
> +++ b/module/web/http.scm
> [...]
> @@ -1158,7 +1158,7 @@ three values: the method, the URI, and the version."
>  (put-symbol port scheme)
>  (put-string port "://")
>  (cond
> - ((host string-index #\:)
> + ((string-index host #\:)
>(put-char #\[ port)
>(put-string port host
>(put-char port #\])))

There are 4 typos in the cond clause above, all introduced in this
commit:

  
https://git.savannah.gnu.org/cgit/guile.git/commit/?id=96b994b6f815747ce2548123cc996d8132bd4781

which includes:

- ((string-index host #\:)
-  (display #\[ port)
-  (display host port)
-  (display #\] port))
+ ((host string-index #\:)
+  (put-char #\[ port)
+  (put-string port host
+  (put-char port #\])))

In addition to the typo you fixed:

* The first call to 'put-char' above has its arguments reversed.
* The following line is missing its ')'.
* The last line has an extra ')'.

   Mark

maxima: The SGC segfault recovery test failed with memprotect_bad_fault_address, SGC disabled

[Alex Vong]

Hello all,

When I start maxima, I get the following warning message:

The SGC segfault recovery test failed with memprotect_bad_fault_address, SGC 
disabled
The SGC segfault recovery test failed with memprotect_bad_fault_address, SGC 
disabled
Maxima 5.41.0 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.12
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.

Actually I encountered this problem quite a while ago after an update,
but I didn't report it since it was not fetal.

Does anyone knows what's going on?

Cheers,
Alex


signature.asc
Description: PGP signature

Re: parallelizing more actions

[Ludovic Courtès]

Hi Efraim,

Efraim Flashner  skribis:

> While rebuilding glibc-final on aarch64 I realized that the 'strip phase
> took 235 seconds. The relevant code for 'strip from gnu-build-system is
> in guix/build/gnu-build-system.scm, starting at line 340, with the
> actual stripping starting at 398. When I changed 'for-each' to
> 'par-for-each' the time dropped from 235 seconds to 215, about an 8.5%
> savings. I'm pretty sure most of that time was spent failing to strip
> certain files, but it is still a savings.

Is it on a spinning hard disk or an SSD?  My guess is that most of the
time is I/O, and that parallelizing doesn’t buy us much (indeed, 8.5% is
not that much, far from a linear speedup.) 

So I’m mildly reluctant to parallelizing this particular piece of code.

Thanks,
Ludo’.

Re: Best-practice to "develop" a system-config / service?

[Ludovic Courtès]

Hi Hartmut,

Hartmut Goebel  skribis:

> I made KDE Plasma start up in a VM by adding tons of packages to the
> system declaration (to be on the save side). Now for finishing and
> providing a nice service declaration I need to strip this list of
> packages down to the bare minimum.
>
> Since a vm (sharing the host store) is unacceptable sloow,

Could you be more specific?  I understand from Chris Baines’ measurement
some time ago that it’s definitely slower than a bare-metal system, but
I don’t find it “unacceptably slow” when it comes to testing stuff like
this (it’s definitely faster than building a standalone image with ‘guix
system vm-image’ anyway!).

> I've build a vm-image using my development environment
> ("./pre-inst-env guix system vm-image …"). Now within the VM-image
> there is a different version of guix installed than the in-development
> one I used for building the VM. Of course the former one does not know
> any of the packages I've just added. So I can't not just run "guix
> system reconfigure …".
>
> After some luckless tries I assume the easiest solution would be to get
> my in-development version of guix into the VM. How to achieve this?

You probably don’t want to do that.

I think all you want, to test your KDE service, is to:

  1. Write an OS config that uses the service.

  2. Run “./pre-inst-env guix system vm that-config.scm”, run the VM,
 and check if it works.

That’s really all it takes to develop and test a system service.

You seemed to be willing to start a GuixSD VM that does *not* use the
service you want to test, and then to reconfigure that VM from the
inside so that it would run your service.  That’s super tedious, as you
wrote, and it’s strictly equivalent to the steps above anyway.

HTH!

Ludo’.

Re: GuixSD on armhf.

[Ludovic Courtès]

Heya,

Mathieu Othacehe  skribis:

>> IOW, a service that starts a GuixSD VM for another architecture.
>>
>> Thoughts?
>
> Thanks for this patch ! For now I'm still trying to build a GuixSD image
> directly on an armhf system.
>
> About that, i made some progress, but i'm now stuck on
> "load-in-linux-vm" part of system generation. This part is starting a
> qemu machine, inside the qemu machine i'm using for this dev. It takes
> about half an hour, just to boot !

Perhaps you’ll need real hardware, though I don’t know whether the cheap
SoCs are much faster than QEMU on x86_64.  :-)

I just got an Olimex A20 OLinuXino and I’d like to have it run GuixSD at
some point!

Ludo’.

Speed of qemu VM sharing the store (was: Best-practice to "develop" a system-config / service?)

[Hartmut Goebel]

Am 11.11.2017 um 12:31 schrieb Ludovic Courtès:
>> Since a vm (sharing the host store) is unacceptable sloow,
> Could you be more specific?  I understand from Chris Baines’ measurement
> some time ago that it’s definitely slower than a bare-metal system, but
> I don’t find it “unacceptably slow” when it comes to testing stuff like
> this (it’s definitely faster than building a standalone image with ‘guix
> system vm-image’ anyway!).
>
See my posting at
:

When sharing the host's store ("guix system vm …"), Plasma takes 80
seconds (minimum) to start up after log-in to X11, when clicking the
menu-button, it takes 36 sec. for the menu to appear. This plain renders
such a VM unusable even for testing.

YMMV, but I call this in-acceptable and this is why I'm using a vm-image
("guix system vm-image …", which is much faster: Plase start-up 25 sec.,
Menu appears immediately.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Best-practice to "develop" a system-config / service?

[Hartmut Goebel]

Am 11.11.2017 um 12:31 schrieb Ludovic Courtès:
> I think all you want, to test your KDE service, is to:
>
>   1. Write an OS config that uses the service.
>
>   2. Run “./pre-inst-env guix system vm that-config.scm”, run the VM,
>  and check if it works.
>
> That’s really all it takes to develop and test a system service.

Not in my case. Plasma heavily relies on plugins and such. I have added
about 50 package to the system configuration to make Plasma start. Now I
need [1] to iterately remove (and re-add) packages (not services!) to
learn what are actual the minimum requirements.

Creating a new VM for each iteration is *much* too time-consuming – no
matter if using "vm-image" or "vm" –, let alone since this required to
reboot the machine each time. Even if I would try to write a test-case
for this [2], each cycle would take too much time.

On a Fedora-like system I would simply 'rpm -e PACKAGENAME`.
Unfortunately guix is not able to uninstall a package it does not know
(see ).

[1] It "need" since I want to deliver a high-qualify service definition.
Otherwise I could live with these 50 packages.
[2] Which is hard, since I would need to figure out how to test "the
Plasma beast is running".

> You seemed to be willing to start a GuixSD VM that does *not* use the
> service you want to test, 

Nope. I want to start a GuixSD VM that *does* use the service, but I
need to remove and add *package* in the machine.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Speed of qemu VM sharing the store

[Ludovic Courtès]

Hartmut Goebel  skribis:

> Am 11.11.2017 um 12:31 schrieb Ludovic Courtès:
>>> Since a vm (sharing the host store) is unacceptable sloow,
>> Could you be more specific?  I understand from Chris Baines’ measurement
>> some time ago that it’s definitely slower than a bare-metal system, but
>> I don’t find it “unacceptably slow” when it comes to testing stuff like
>> this (it’s definitely faster than building a standalone image with ‘guix
>> system vm-image’ anyway!).
>>
> See my posting at
> :
>
> When sharing the host's store ("guix system vm …"), Plasma takes 80
> seconds (minimum) to start up after log-in to X11, when clicking the
> menu-button, it takes 36 sec. for the menu to appear. This plain renders
> such a VM unusable even for testing.

OK, that’s terrible indeed.  So that’s with ‘-enable-kvm’ on the qemu
command line, right?

> YMMV, but I call this in-acceptable and this is why I'm using a vm-image
> ("guix system vm-image …", which is much faster: Plase start-up 25 sec.,
> Menu appears immediately.

25 seconds to start up is still a lot (in ‘guix system vm’ GNOME is
usable and much faster to start).  It would be nice to see if that comes
from I/O or something else.  Is there something we’re doing wrong
(independently of the VM) or is it expected for Plasma startup to be
this slow?

Ludo’.

Re: Best-practice to "develop" a system-config / service?

[Ludovic Courtès]

Hartmut Goebel  skribis:

> Am 11.11.2017 um 12:31 schrieb Ludovic Courtès:
>> I think all you want, to test your KDE service, is to:
>>
>>   1. Write an OS config that uses the service.
>>
>>   2. Run “./pre-inst-env guix system vm that-config.scm”, run the VM,
>>  and check if it works.
>>
>> That’s really all it takes to develop and test a system service.
>
> Not in my case. Plasma heavily relies on plugins and such. I have added
> about 50 package to the system configuration to make Plasma start. Now I
> need [1] to iterately remove (and re-add) packages (not services!) to
> learn what are actual the minimum requirements.
>
> Creating a new VM for each iteration is *much* too time-consuming – no
> matter if using "vm-image" or "vm" –, let alone since this required to
> reboot the machine each time. Even if I would try to write a test-case
> for this [2], each cycle would take too much time.

Well, I’ve always used the above approach to test system services as I
worked on them, and the 10–30 seconds it took for ‘guix system vm’ to
complete as I tweak the service were never that much of a hindrance to
me.

But yeah, I understand you’re using ‘vm-image’, so it’s a different
story since ‘vm-image’ takes ages.

Now, it seems to me that the workflow you describe has become this
complicated just because of the slowness of Plasma in the VM.  To me
that’s something worth investigating.  Granted a VM with a 9p-mounted
store is slower than a bare metal system, but it shouldn’t be this slow.
Something’s wrong.

> On a Fedora-like system I would simply 'rpm -e PACKAGENAME`.
> Unfortunately guix is not able to uninstall a package it does not know
> (see ).

It cannot uninstall a propagated package, if that’s what you mean.

Ludo’.

Re: Emacs minor-mode highlight code stages (gexp & sexp)

[Ludovic Courtès]

Chris Marusich  skribis:

> I've only used it for about 5 minutes now, but I have one question: is
> it possible to highlight gexps using a different color than other
> "staged" code?

Then we’re going to ask too much, like how should it highlight something
like:

  `(foo ,#~(bar '#$baz))

?

:-)

The next thing will be to make Geiser aware of staged code…

Ludo’.

Re: [PATCH 6/6] gnu: Improve error reporting of the use-.*modules macros.

[Ludovic Courtès]

Heya,

Chris Marusich  skribis:

> Ludovic Courtès  writes:
>
>> +(define-syntax-rule (try-use-modules hint modules ...)
>> +  (eval-when (expand load eval)
>> +(%try-use-modules '(modules ...)
>> +  (source-properties->location
>> +   (current-source-location))
>> +  hint)))
>> +
>
> Why is it necessary to use eval-when here?  The Guile manual makes it
> sound like eval-when is intended to be used with syntax-case macros, not
> syntax-rules macros.

It’s necessary because ‘use-modules’ (and ‘try-use-modules’ here)
doesn’t allow you to specify the “phase” (run-time or expansion-time) at
which you’re “using” the module.  Thus, it assumes you’re using it both
at expansion-time and at run-time.

The (gnu packages …) modules happen to export a few macros, so it
doesn’t work if you import them at run-time only.

Ludo’.

Re: Changing HTTP proxy settings in GuixSD

[Ludovic Courtès]

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>> It turned out to come from a typo in Guile 2.2’s web client, now fixed
>> here:
>>
>>   
>> https://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.2&id=7d0d9e2c25c1e872cfc7d14ab5139915f1813d56
>
> [...]
>
>> diff --git a/module/web/http.scm b/module/web/http.scm
>> index 993b50e..62f0624 100644
>> --- a/module/web/http.scm
>> +++ b/module/web/http.scm
>> [...]
>> @@ -1158,7 +1158,7 @@ three values: the method, the URI, and the version."
>>  (put-symbol port scheme)
>>  (put-string port "://")
>>  (cond
>> - ((host string-index #\:)
>> + ((string-index host #\:)
>>(put-char #\[ port)
>>(put-string port host
>>(put-char port #\])))
>
> There are 4 typos in the cond clause above, all introduced in this
> commit:
>
>   
> https://git.savannah.gnu.org/cgit/guile.git/commit/?id=96b994b6f815747ce2548123cc996d8132bd4781
>
> which includes:
>
> - ((string-index host #\:)
> -  (display #\[ port)
> -  (display host port)
> -  (display #\] port))
> + ((host string-index #\:)
> +  (put-char #\[ port)
> +  (put-string port host
> +  (put-char port #\])))
>
> In addition to the typo you fixed:
>
> * The first call to 'put-char' above has its arguments reversed.
> * The following line is missing its ')'.
> * The last line has an extra ')'.

Ouch, good catch.  I pushed appropriate fixes.

If you spot more, feel free to fix them directly!  :-)

Thanks,
Ludo’.

Re: parallelizing more actions

[Efraim Flashner]

On Sat, Nov 11, 2017 at 12:25:01PM +0100, Ludovic Courtès wrote:
> Hi Efraim,
> 
> Efraim Flashner  skribis:
> 
> > While rebuilding glibc-final on aarch64 I realized that the 'strip phase
> > took 235 seconds. The relevant code for 'strip from gnu-build-system is
> > in guix/build/gnu-build-system.scm, starting at line 340, with the
> > actual stripping starting at 398. When I changed 'for-each' to
> > 'par-for-each' the time dropped from 235 seconds to 215, about an 8.5%
> > savings. I'm pretty sure most of that time was spent failing to strip
> > certain files, but it is still a savings.
> 
> Is it on a spinning hard disk or an SSD?  My guess is that most of the
> time is I/O, and that parallelizing doesn’t buy us much (indeed, 8.5% is
> not that much, far from a linear speedup.) 
> 

It was on eMMC, so basically an SSD.

> So I’m mildly reluctant to parallelizing this particular piece of code.
> 
> Thanks,
> Ludo’.

-- 
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: Emacs minor-mode highlight code stages (gexp & sexp)

[Chris Marusich]

l...@gnu.org (Ludovic Courtès) writes:

> Chris Marusich  skribis:
>
>> I've only used it for about 5 minutes now, but I have one question: is
>> it possible to highlight gexps using a different color than other
>> "staged" code?
>
> Then we’re going to ask too much, like how should it highlight something
> like:
>
>   `(foo ,#~(bar '#$baz))
>
> ?
>
> :-)

OK, that's fair.

> The next thing will be to make Geiser aware of staged code…

That would be really nice.

-- 
Chris


signature.asc
Description: PGP signature

Re: [PATCH 6/6] gnu: Improve error reporting of the use-.*modules macros.

[Chris Marusich]

l...@gnu.org (Ludovic Courtès) writes:

> Heya,
>
> Chris Marusich  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> +(define-syntax-rule (try-use-modules hint modules ...)
>>> +  (eval-when (expand load eval)
>>> +(%try-use-modules '(modules ...)
>>> +  (source-properties->location
>>> +   (current-source-location))
>>> +  hint)))
>>> +
>>
>> Why is it necessary to use eval-when here?  The Guile manual makes it
>> sound like eval-when is intended to be used with syntax-case macros, not
>> syntax-rules macros.
>
> It’s necessary because ‘use-modules’ (and ‘try-use-modules’ here)
> doesn’t allow you to specify the “phase” (run-time or expansion-time) at
> which you’re “using” the module.  Thus, it assumes you’re using it both
> at expansion-time and at run-time.
>
> The (gnu packages …) modules happen to export a few macros, so it
> doesn’t work if you import them at run-time only.

I see.  Thank you for the explanation.  I think I need to read up more
on how Guile loads, evaluates, compiles, etc. its code.

-- 
Chris


signature.asc
Description: PGP signature

Re: boot the Hurd with Guix

[rennes]

Hola,

Finally I was able to start the Hurd with the binaries generated with the guix 
package manager.

At the moment the image of Hurd I have built it manually and does not yet have 
any functionality like GuixSD / Linux.

Next goal:
  * Generate the image file in the style of guix.
  ** For this I have noticed that it is required to compile qemu for the 
architecture i586-pc-gnu, at the moment I could not compile qemu in Hurd. I 
have tried to disable some quemu features that come by default; however, I have 
not yet achieved it.

Other pending things:
  * Some packages fail during the compilation and testing phases.
  * Other packages used by guix, such as lsof are not ported in Hurd yet.

At the moment it is everything, any doubt or help is welcome.


Rene

Re: boot the Hurd with Guix

[Samuel Thibault]

ren...@openmailbox.org, on sam. 11 nov. 2017 18:02:11 -, wrote:
> Finally I was able to start the Hurd with the binaries generated with the 
> guix package manager.

Groovy :D

Samuel

Re: boot the Hurd with Guix

[Manolis Ragkousis]

This is awesome Rene!! Have you uploaded your changes anywhere?

On November 11, 2017 8:02:11 PM GMT+02:00, ren...@openmailbox.org wrote:
>Hola,
>
>Finally I was able to start the Hurd with the binaries generated with
>the guix package manager.
>
>At the moment the image of Hurd I have built it manually and does not
>yet have any functionality like GuixSD / Linux.
>
>Next goal:
>  * Generate the image file in the style of guix.
>** For this I have noticed that it is required to compile qemu for the
>architecture i586-pc-gnu, at the moment I could not compile qemu in
>Hurd. I have tried to disable some quemu features that come by default;
>however, I have not yet achieved it.
>
>Other pending things:
>  * Some packages fail during the compilation and testing phases.
>* Other packages used by guix, such as lsof are not ported in Hurd yet.
>
>At the moment it is everything, any doubt or help is welcome.
>
>
>Rene

Re: boot the Hurd with Guix

[Ludovic Courtès]

Hi rennes!

ren...@openmailbox.org skribis:

> Finally I was able to start the Hurd with the binaries generated with the 
> guix package manager.

Woohoo!  Does that mean you were able to run packages cross-compiled
with Guix, or packages built natively with Guix?

> At the moment the image of Hurd I have built it manually and does not yet 
> have any functionality like GuixSD / Linux.

… or did you build a VM image of GNU/Hurd?

> Next goal:
>   * Generate the image file in the style of guix.
>   ** For this I have noticed that it is required to compile qemu for the 
> architecture i586-pc-gnu, at the moment I could not compile qemu in Hurd. I 
> have tried to disable some quemu features that come by default; however, I 
> have not yet achieved it.

Things like ‘guix system vm’ use QEMU because we need to start a VM
because on GNU/Linux one needs to be root to create a file system, mount
it, and populate it.

However, on GNU/Hurd, file systems can be mounted without being root.
So you could in fact skip QEMU altogether, though that’d require
tweaking in the VM-generation code (in (gnu build vm), etc.).

> Other pending things:
>   * Some packages fail during the compilation and testing phases.
>   * Other packages used by guix, such as lsof are not ported in Hurd yet.

We could probably get rid the lsof dependency.  What matters here is a
Linuxish /proc.

Anyway, congrats on this milestone!  :-)

Ludo’.

Re: diverse double compilation: using $ORIGIN?

[Ludovic Courtès]

Chris Marusich  skribis:

> Ricardo Wurmus  writes:
>
>> Since the GCC build procedure is performed at least two
>> times (once with the bootstrap compiler, and then again with the GCC
>> variant this produces), the resulting GCC binaries should be identical.
>>
>> Except that they are not.  One of the reasons is that the binaries
>> that Guix produces embed the target output directories.  This means
>> that the two compiler binaries that result from diverse double
>> compilation will *always* differ in at least the embedded paths, such
>> as paths to itself (e.g. to binaries in the libexec directory) and
>> paths to.
>
> What ever happened to the intensional model (i.e., a content-addressed
> store)?  If derivation outputs were content-addressed, this would not be
> a problem, right?

Indeed.

> Dolstra's thesis presented some ideas for how to rewrite self-references
> in derivation outputs under the intensional model.  I've casually looked
> into what happened with the intensional model since his thesis was
> written, but I don't really know why it hasn't been implemented.  All I
> know is that Dolstra and the Nix devs seem to have moved away from that
> idea; I never really learned the reason(s) why.

One problem is that it requires 100% reproducible builds; if something
doesn’t build reproducibly, you cannot get substitutes.

Another problem is… migration.  :-)

Now, fixed-output derivations are one way to retrofit bits of the
intensional model in the extensional model.  Perhaps we could do more in
that direction?

Ludo’.

Re: [PATCH 0/6] Error reporting and hints for missing modules

[Ludovic Courtès]

Julien Lepiller  skribis:

> I saw that last hint today buveuse I misspelled a type name 
> (dovecot-configurtation). I understand the hint is great when you forget to 
> import a service module, but it's not so great when the error is misspelling. 
> Maybe the solution would be: if the unbound variable is the name of a 
> service, propose using that module, otherwise don't show any hint. 

A hint is nothing more than that, a hint (as opposed to a “solution”),
but maybe you’re right about removing the “Did you forget ‘use-modules’”
hint.

Thoughts?

(Misspelling is where we’d need something using the Levensthein
distance.  I’m sure one could do a PhD on this topic.  :-))

Ludo’.

Re: [PATCH 0/6] Error reporting and hints for missing modules

[Ludovic Courtès]

myglc2  skribis:

> On 11/10/2017 at 00:04 Ludovic Courtès writes:
>>
>> Thrilled by this idea, I pushed an unbound-variable handler that can
>> provide hints, such as:
>>
>>   configuration.scm:88:19: zip: unbound variable
>>   hint: Try adding `(use-modules (gnu packages compression))'.
>>
>> Feedback welcome!
>
> I built and played with this.  If I follow some of the hints literally
> they lead me astray. Here are some suggested hint rewording.

Again, it’s a hint, it could be wrong.

So perhaps that’s a good reason for “Did you mean xyz?”, ending with a
question mark (like GCC does), rather than a sentence that looks
assertive.

In the example above, it may be less confusing if we write:

  Did you forget (use-modules …)?

With the question mark, the user understands that this may or may not be
the cause of the error.

Thoughts?

Ludo’.

Re: boot the Hurd with Guix

[rennes]

> This is awesome Rene!! Have you uploaded your changes anywhere?
> 

Hello Manolis,

I will prepare the documentation and a small image of qemu and upload it.