patch: partition vs filesystem

[Marco van Hulten]

Patch for documentation attached.

terminology: replaced partition with filesystem where needed

—Marco
diff --git a/doc/guix.texi b/doc/guix.texi
index 098ff5e..d4a2a69 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -8072,7 +8072,7 @@ types.}.  For the ESP, if you have one and assuming it is
 mkfs.fat -F32 /dev/sda2
 @end example
 
-Preferably, assign partitions a label so that you can easily and
+Preferably, assign file systems a label so that you can easily and
 reliably refer to them in @code{file-system} declarations (@pxref{File
 Systems}).  This is typically done using the @code{-L} option of
 @command{mkfs.ext4} and related commands.  So, assuming the target root
@@ -8097,9 +8097,9 @@ cryptsetup open --type luks /dev/sda1 my-partition
 mkfs.ext4 -L my-root /dev/mapper/my-partition
 @end example
 
-Once that is done, mount the target root partition under @file{/mnt}
+Once that is done, mount the target file system under @file{/mnt}
 with a command like (again, assuming @code{my-root} is the label of the
-root partition):
+root file system):
 
 @example
 mount LABEL=my-root /mnt

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

[Alex Vong]

Kei Kebreau  writes:

> Alex Vong  writes:
>
>> 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.
>
> When did you first notice this issue?
>
I am afraid I cannot remember exactly when...

I installed wxmaxima long ago and things worked fine for a long
time. One day, after updating wxmaxima, it showed the above warning and
started to crash nondeterministically when I typed things into the
message box. The crash was fixed quickly by another update, but the
warning persisted. 

>>
>> Does anyone knows what's going on?
>>
>> Cheers,
>> Alex
>
> Hello Alex,
>
> This is my first time running into this issue. While I do get this
> warning message using the Maxima substitute from hydra.gnu.org, when I
> build Maxima 5.41.0 from source locally, this warning message does not
> appear. Is this the case for you as well?
>
Same for me. I set --prefix during configure and install it
somewhere. It starts without the warning.

> The message comes from the source code of GNU Common Lisp, but the GCL
> binary from hydra.gnu.org doesn't give this error when I run it. It
> seems like this comes down a bug in GCL set off by Maxima, a bug in
> Maxima, a reproducibility issue, or some combination of all of
> these. I'll be investigating this further.
>
> Thank you,
> Kei

Thanks for looking at it!


signature.asc
Description: PGP signature

Re: Is anyone opposed to GnuTLS with DANE by default?

[ng0]

Ludovic Courtès transcribed 0.5K bytes:
> ng0  skribis:
> 
> > Am I in the 'old system design' mindwset when I think that
> > every application that has applications such as libmicrohttpd
> > in its direct dependency chain should depend on the GnuTLS
> > version LMH uses and not the 'normal' GnuTLS
> > (It also depends on the features of GnuTLS which are being used,
> > but to be on the safe side)?
> 
> You’re right, it’s a bad sign when there are two different variants of
> the same package in a reference graph.
> 
> Ludo’.

I haven't read much (or at all?) into guix lint so far,
but can we lint for occurence of this pair somehow?
-- 
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://dl.n0.is/dist/keys/
  WWW: https://we.make.ritual.n0.is


signature.asc
Description: PGP signature

Re: ATI radeon + modesetting

[Ludovic Courtès]

Hi Andy,

Andy Wingo  skribis:

> Recalling all of this history, I thought that perhaps a switch to
> modesetting could fix my radeon problems as well, and indeed, voilà,
> this patch fixes it:
>
> --- a/gnu/services/xorg.scm
> +++ b/gnu/services/xorg.scm
> @@ -117,7 +117,7 @@ Section \"Files\"
>FontPath \"" font-adobe75dpi "/share/fonts/X11/75dpi\"
>ModulePath \"" xf86-video-vesa "/lib/xorg/modules/drivers\"
>ModulePath \"" xf86-video-fbdev "/lib/xorg/modules/drivers\"
> -  ModulePath \"" xf86-video-ati "/lib/xorg/modules/drivers\"
> +  # ModulePath \"" xf86-video-ati "/lib/xorg/modules/drivers\"
>ModulePath \"" xf86-video-cirrus "/lib/xorg/modules/drivers\"
>ModulePath \"" xf86-video-intel "/lib/xorg/modules/drivers\"
>ModulePath \"" xf86-video-mach64 "/lib/xorg/modules/drivers\"

[...]

> I think I would like to apply this patch to Guix.  My only concern would
> be that perhaps there are people using older radeon cards that don't
> support Glamor; dunno.  I do see bugs around this area that suggest that
> the radeon driver is also slipping into disrepair, e.g.:
>
>   https://bugs.freedesktop.org/show_bug.cgi?id=102054
>
> But considering that the ATI driver was only added to the default
> modules a year ago in 3126fd8820e8c30e27ef978d66dced8763d04905, before
> our Xorg server configuration included the paths to the modesetting
> driver, perhaps the risk is low.  Any thoughts?

FWIW, given your analysis and the silence that ensued ;-), I think you
can go ahead and push this patch.

Eventually we should make this part of the code more modular so that
users can specify a list of driver packages and easily add/remove one.

Thanks,
Ludo’.

Re: Is anyone opposed to GnuTLS with DANE by default?

[Ludovic Courtès]

ng0  skribis:

> Am I in the 'old system design' mindwset when I think that
> every application that has applications such as libmicrohttpd
> in its direct dependency chain should depend on the GnuTLS
> version LMH uses and not the 'normal' GnuTLS
> (It also depends on the features of GnuTLS which are being used,
> but to be on the safe side)?

You’re right, it’s a bad sign when there are two different variants of
the same package in a reference graph.

Ludo’.

Re: isc-bind service draft

[Ludovic Courtès]

Oleg Pykhalov  skribis:

> (($  user _ run-directory pid-file
>  listen-v4 listen-v6 listen-port
>  allow-recursion? allow-transfer?
>  allow-update?
>  version hostname server-id)

Given that there are many fields, it’s safer to use the new
‘match-record’ macro from (guix records) in this case.

Ludo’.

Re: isc-bind service draft

[Ludovic Courtès]

Chris Marusich  skribis:

> Chris Marusich  writes:
>
>>>
>>> (define (emit-bind-options-config options)
>>>   (match options
>>> (($  user _ run-directory pid-file
>>>  listen-v4 listen-v6 listen-port
>>>  allow-recursion? allow-transfer?
>>>  allow-update?
>>>  version hostname server-id)
>>
>> Some of these slots (e.g., listen-v4) appear to be un-used.  Instead of
>> listing positional slots by name, maybe it would be better to bind the
>> entire  to a variable, and then use the
>> accessor procedures (e.g., bind-options-configuration-listen-v4) to get
>> just the attributes you need.  This has the benefit of being more
>> resilient to refactorings which change the order of fields in the
>> record, also.  I realize that a lot of the code in Guix relies on
>> positional matching of slots like this, so I don't mind if you keep it
>> as-is, but consider my suggestion as food for thought.
>
> FYI, I just learned that there is a way to do this with pattern matching
> in Guile.  You can write something like the following:
>
> (match options
>   ((? bind-options-configuration? (= bind-options-configuration-listen-v4 
> listen-v4))
>;; Do something with listen-v4
>(foo listen-v4)))
>
> As far as I know, this is the same as writing something like:
>
> (match options
>   ((? bind-options-configuration? opts)
>(let ((listen-v4 (bind-options-configuration-listen-v4 opts)))
>  ;; Do something with listen-v4
>  (foo listen-v4

In this particular case I would argue that the second version is more
readable.

Ludo’.

Re: Is anyone opposed to GnuTLS with DANE by default?

[ng0]

Ludovic Courtès transcribed 0.5K bytes:
> Tobias Geerinckx-Rice  skribis:
> 
> > I certainly don't object, but am forced to note that ’gnutls-dane’ more
> > than doubles the closure size of ‘gnutls’ proper (294.2 MiB vs. 138.5).
> >
> > The only new input is ‘unbound’, but that manages to pull in both
> > Pythons 2 and 3. It would be nice™ if it could first be -minimalised...
> 
> Yes, to me that’s a showstopper.  (One of the Pythons comes from
> libevent.)
> 
> Thanks,
> Ludo’.

Okay, sounds reasonable to me and I agree, especially with Python not being
reproducible at the moment (if I remember the threads right).

Am I in the 'old system design' mindwset when I think that
every application that has applications such as libmicrohttpd
in its direct dependency chain should depend on the GnuTLS
version LMH uses and not the 'normal' GnuTLS
(It also depends on the features of GnuTLS which are being used,
but to be on the safe side)?
-- 
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://dl.n0.is/dist/keys/
  WWW: https://we.make.ritual.n0.is


signature.asc
Description: PGP signature

Re: boot the Hurd with Guix

[Manolis Ragkousis]

Hello everyone,

On 11/16/2017 12:13 PM, Ludovic Courtès wrote:
> Hi Samuel,  :-)
> 
> Samuel Thibault  skribis:
> 
>> Ludovic Courtès, on lun. 13 nov. 2017 11:42:01 +0100, wrote:
>>> PS: guix-daemon no longer depends on ‘lsof’, but it still depends on /proc.
>>
>> Does our procfs have everything it needs already?
> 
> It needs /proc/PID/{exe,cwd,fd,maps,environ}:
> 
>   
> https://git.savannah.gnu.org/cgit/guix.git/tree/nix/scripts/list-runtime-roots.in
> 
> That said, it’s quite optional: the worst that can happen if one of
> these things is missing is that something can be reclaimed “prematurely”
> from /gnu/store.  I say “prematurely” with quotes because users are
> supposed to register “real” GC roots anyway, as with ‘guix package -i’
> or ‘guix build --root’.

That reminds me, Rene have you tried running 'guix gc -C' ? What is the
output? Because I have a problem with this on Guix on Hurd and I haven't
managed to fix it yet.

Re: boot the Hurd with Guix

[Ludovic Courtès]

Hi Samuel,  :-)

Samuel Thibault  skribis:

> Ludovic Courtès, on lun. 13 nov. 2017 11:42:01 +0100, wrote:
>> PS: guix-daemon no longer depends on ‘lsof’, but it still depends on /proc.
>
> Does our procfs have everything it needs already?

It needs /proc/PID/{exe,cwd,fd,maps,environ}:

  
https://git.savannah.gnu.org/cgit/guix.git/tree/nix/scripts/list-runtime-roots.in

That said, it’s quite optional: the worst that can happen if one of
these things is missing is that something can be reclaimed “prematurely”
from /gnu/store.  I say “prematurely” with quotes because users are
supposed to register “real” GC roots anyway, as with ‘guix package -i’
or ‘guix build --root’.

Thanks,
Ludo’.

Re: Is anyone opposed to GnuTLS with DANE by default?

[Ludovic Courtès]

Tobias Geerinckx-Rice  skribis:

> I certainly don't object, but am forced to note that ’gnutls-dane’ more
> than doubles the closure size of ‘gnutls’ proper (294.2 MiB vs. 138.5).
>
> The only new input is ‘unbound’, but that manages to pull in both
> Pythons 2 and 3. It would be nice™ if it could first be -minimalised...

Yes, to me that’s a showstopper.  (One of the Pythons comes from
libevent.)

Thanks,
Ludo’.

Re: parallelizing more actions

[Ludovic Courtès]

Efraim Flashner  skribis:

> On Sun, Nov 12, 2017 at 03:31:49PM +0200, Efraim Flashner wrote:
>> On Thu, Nov 09, 2017 at 11:05:59AM +0200, Efraim Flashner wrote:
>> > 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.
>> > 
>> 
>> These numbers were for glibc@2.26. I ran it against glibc@2.25 on my
>> x86_64 machine with a spinning harddrive and 2 cores, without the patch
>> it took 165.7 seconds (164.6 the second time), with the patch it dropped
>> to 24.3 seconds.
>> 
>> I'll test it with glibc@2.25 on aarch64 later when its not building
>> other things.
>> 
>
> Looks like aarch64 could use some help somewhere. With the patch it took
> 221.9 seconds, without the patch it was 219.8.
>
> so in summary, aarch64 is terrible at stripping, parallel or not, and on
> x86_64 my patch saved 85% of the patching time, despite only using 2 cores.

This is weird.  I don’t see any reason why ‘strip’ would be slower on
aarch64 than elsewhere.  Are you sure it’s not mostly I/O?  It would be
nice to time it and see the real/user/system times.

Thanks,
Ludo’.

Re: Changing HTTP proxy settings in GuixSD

[Konrad Hinsen]

Hi Ludo,

> I’ll update the ‘guix’ package soon so that this change is available to
> daemon-side code such as ‘guix substitute’.  In the meantime you can run
> the daemon from a checkout:
>
>   sudo -E ./pre-inst-env guix-daemon …

That works fine - thanks!

Konrad.