Re: [PATCH] gnu: libffi: Add unreleased patch to fix float128 on powerpc64le.

[Mark H Weaver]

Earlier, I wrote:
> When invoking 'patch' in Guix, you should *always* use "--force" instead
> of "--batch".

(See  for my earlier message).

Since writing the message above, I've found another problem in the same
commit (7eaa2f24ea77cddbb4bbc2d6a6905673a36f8f99): it searches for the
'patch' program in 'inputs'.  This is a mistake, because when
cross-compiling, 'inputs' will contain software compiled to run on the
target system instead of the build system.

If 'native-inputs' is not #f, we should search for the 'patch' program
in 'native-inputs' instead of 'inputs'.  Unless there's now a better way
that I don't know, I suggest adding 'native-inputs' to the list of
keyword arguments accepted by the 'lambda*', and changing 'inputs' to
"(or native-inputs inputs)" in the call to 'assoc-ref'.  Something like
this (untested):

_ ,@(if (string-prefix? "powerpc64le-" (or (%current-target-system)
__ (%current-system)))
___ '(#:phases (modify-phases %standard-phases
 (add-after 'unpack 'apply-patch2
__ (lambda* (#:key inputs native-inputs
 #:allow-other-keys)
 (let ((patch (assoc-ref (or native-inputs inputs)
 "powerpc64le-patch")))
__ (invoke "patch" "--force" "-p1"
__ "-i" patch))
___ '())

I see now that both of these mistakes were already present in the
"powerpc-*" case immediately above the recently-added "powerpc64le-*"
case.  The "powerpc-*" case was added earlier this year in the following
commit:

  
https://git.sv.gnu.org/cgit/guix.git/commit/?id=02f5ee01c96589fc13f1e21b85b0b48100aec4e8

I'm CC'ing 'guix-devel' to raise awareness about these common mistakes,
in the hopes that reviewers will be more likely to notice them in the
future.

  Thanks,
Mark

Re: Provide an option to specify the tmpfs size of the container

[Robert Smith]

Hi Ludo,

On Mon Dec 14, 2020 at 10:56 AM Ludovic Courtès wrote:
> Hi,
> 
> luhux  skribis:
> 
> > I am using guix environment --container to containerize my programming 
> > environment and runtime environment, but I found that the container / 
> > created by this command uses tmpfs and cannot be resized.
> >
> > When a file in the container outputs a lot of logs to the tmpfs of the 
> > container, the memory usage of the host will be very high (this is usually 
> > something I did not expect)
> >
> > So can provide an option to specify the size of tmpfs?
> 
> Sure, why not.  Would you like to give it a try?

This feature caught my interest and I wanted to investigate a bit :)
tmpfs defaults to half of the available RAM, with the 'size=' option to
the mount command we can increase this limit but I believe that the
upper bound is the sum of the available RAM + swap space. Would it be
worthwhile to allow for the container filesystem to be stored in a
non-temporary filesystem, for example allowing the user to specify the
parent directory of the container root? This would let the container fs
grow as large as the computer storage allows.

-Robert

Re: [PATCH] gnu: libffi: Add unreleased patch to fix float128 on powerpc64le.

[Mark H Weaver]

Hi,

There's a problem with the following commit:

> commit 7eaa2f24ea77cddbb4bbc2d6a6905673a36f8f99
> Author: John Doe 
> Date:   Tue Dec 15 10:23:44 2020 +0100
> 
>   gnu: libffi: Add unreleased patch to fix float128 on powerpc64le.
>   
>   Fixes .
>   
>   * gnu/packages/patches/libffi-float128-powerpc64le.patch: Import patch file
>   from .
>   * gnu/packages/libffi.scm (libffi)[arguments]: Apply patch conditionally for
>   powerpc64le-* systems in a phase.
>   [inputs]: Add patch as input conditionally for powerpc64le-* systems.
>   * gnu/local.mk (dist_patch_DATA): Add patch file to build system.
>   
>   Signed-off-by: Chris Marusich 

The problem is in how the 'patch' program is invoked, here:

> diff --git a/gnu/packages/libffi.scm b/gnu/packages/libffi.scm
> index d324892330..66239e0363 100644
> --- a/gnu/packages/libffi.scm
> +++ b/gnu/packages/libffi.scm
[...]
> @@ -67,13 +68,28 @@
>"powerpc-patch")))
>  (invoke "patch" "--batch" "-p1"
>  "-i" patch))
> + '())
> +   ,@(if (string-prefix? "powerpc64le-" (or (%current-target-system)
> +(%current-system)))
> + '(#:phases (modify-phases %standard-phases
> +  (add-after 'unpack 'apply-patch2
> +(lambda* (#:key inputs #:allow-other-keys)
> +  (let ((patch (assoc-ref inputs
> +  "powerpc64le-patch")))
> +(invoke "patch" "--batch" "-p1"
> +"-i" patch))
>   '(

When invoking 'patch' in Guix, you should *always* use "--force" instead
of "--batch".  There's a crucial difference between these two options:
If 'patch' finds that the given patch has already been applied, then
"--batch" will automatically *revert* the patch, whereas "--force" will
raise an error.  Here's the relevant section of the 'diffutils' manual:

> 10.11.2 Inhibiting Keyboard Input
> -
> 
> There are two ways you can prevent 'patch' from asking you any
> questions.  The '--force' ('-f') option assumes that you know what you
> are doing.  It causes 'patch' to do the following:
> 
>* Skip patches that do not contain file names in their headers.
> 
>* Patch files even though they have the wrong version for the
>  'Prereq:' line in the patch;
> 
>* Assume that patches are not reversed even if they look like they
>  are.
> 
> The '--batch' ('-t') option is similar to '-f', in that it suppresses
> questions, but it makes somewhat different assumptions:
> 
>* Skip patches that do not contain file names in their headers (the
>  same as '-f').
> 
>* Skip patches for which the file has the wrong version for the
>  'Prereq:' line in the patch;
> 
>* Assume that patches are reversed if they look like they are.

Now consider what will happen when we upgrade 'libffi' to a newer
version that already includes this fix.  If the Guix developer who
performs the upgrade forgets to remove this patch, the 'patch'
invocation above will start silently re-inserting the old bug.

We ran into this exact problem in the early years of Guix, and
henceforth changed all of the invocations of 'patch' to use '--force'.

Can we fix this right away, before many powerpc64le-* binaries are built
on top of it?

In any case, thanks very much for working on the powerpc64le port!

  Regards,
Mark

SJTUG's Guix mirror is online now

[Peng Mei Yu]

Hello,

After extensive cooperation with SJTUG's maintainers, we are happy to
announce that SJTUG's Guix mirror is online now.

The substitute URL is: https://mirrors.sjtug.sjtu.edu.cn/guix

Asia residents, especially China residents, will greatly benefit from
this mirror.  Average download speed is about 3MB/s within China, which
is a 100 times increase compared to ci.guix.gnu.org.

SJTUG's Guix mirror is maintained by students of Shanghai Jiao Tong
University Linux User Group (SJTUG).  We will continue to cooperate with
them in the near future to ensure this mirror server is fast and stable.

Find the announcement and usage instructions here:
https://guix.org.cn/blog/sjtug-guix-mirror-is-online-now/
https://sjtug.org/post/mirror-news/2020-12-21-release-guix/
https://mirrors.sjtug.sjtu.edu.cn/docs/guix


--
Peng Mei Yu

Re: wip-arm-bootstrap: Reduced binary seed bootstrap

[Jan Nieuwenhuizen]

Jan Nieuwenhuizen writes:

Hello,

> I pushed an initial wip-arm-bootstrap that builds up to tcc-boot:

Just a headsup: I have reset wip-arm-bootstrap.  This version actually
builds tcc-boot using mes-boot (the previous one only worked when
cheating by using %bootstrap-guile).

Also, the aarch64-linux problem has been fixed, so that this

--8<---cut here---start->8---
./pre-inst-env guix build --system=armhf-linux \
 -e '(@@ (gnu packages commencement) tcc-boot)'
--8<---cut here---end--->8---

now works on overdrive1.

Greetings,
Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com