Re: Status update on 1.0

[Timothy Sample]

Hi Ludo,

Ludovic Courtès  writes:

> Hello Guix!
>
> When we said we’d try to release 1.0 for FOSDEM, we were talking about
> FOSDEM *2019*, which is well over now, so I think we need to get our act
> together and complete the remaining tasks for 1.0.  :-)
>
> Looking at the
> 
> plus my own memories, here are work items that still need to be
> addressed:
>
> [...]
>
>   • GDM works well for GNOME and WMs that provide a .session file.
> However it still doesn’t honor ~/.xsession.  We discussed it before
> and dropped the ball.  Timothy, what’s missing?  I’d really like to
> make it the default.

Nothing is missing!  As promised [1], in the last patch series I made
GDM run our custom “xinitrc” script instead of the built-in one.  This
happened in commit 41fa9f1815685ede0d3fdc1c561d2a9cf0ffb158.  :)

(I tested this now to be absolutely sure, and it works like a charm.)

>   • GDM’s closure is 1.3 GiB, we should do something about it.

Yes.  We should be working on “guix size gnome-shell”.  It more
accurately reflects the size of GDM, and (I hope you’re sitting down) it
weighs in at 2GiB!

Fortunately, it looks like we could claw back ~400MiB by (somehow)
dropping “hplip-minimal”.  It gets pulled in through the path

gdm → gnome-settings-daemon → colord → sane-backends →
hplip-minimal.

We almost certainly don’t need it for GDM.  I guess removing it means
making a version of “colord” without “sane-backends”.  It was introduced
in commit 4c9287432824f396d5c614c3b2287f553cd9fb90.  I’ll look into
this.

GNOME Shell has a handful of silly references like “inkscape” and
“webkitgtk” that are huge and (I assume) unnecessary.

There seems to be a handful of easy wins.  I would be surprised if we
could get the closure of “gnome-shell” below 1GiB, but we will see.
Also, keep in mind that a lot of these bytes will be recycled.  For
instance, GTK+ 3 is ~700MiB, and chances are there will be at least one
GTK+ 3 application besides GDM.


[1] https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00198.html


-- Tim

Re: Status update on 1.0

[Maxim Cournoyer]

Danny Milosavljevic  writes:

> On Wed, 13 Mar 2019 17:00:55 +0100
> Pierre Neidhardt  wrote:
>
>> > The last time I tried the installer it didn't work on AMD(GPU) cards.  
>> > I'll give
>> > it another go.  
>> 
>> I've experienced the same issue and I'm quite sure this is because the 
>> installer
>> uses KMSCON which only works with the proprietary amdgpu kernel module.  
>> During
>> FOSDEM, Mathieu mentioned that KMSCON was chosen because it works better with
>> text/input encoding, if I recall correctly. 
>
> Or find out why on earth KMSCON needs the prorietary amdgpu kernel module.
>
> It's not exactly 3D graphics, so what is going on?  Furthermore, vesafb should
> always work regardless (if slowly, but who cares).

As Pierre hinted, your question should rather be as "Why on Earth does
the AMDGPU drivers needs a binary blob to provide basic features such as KMS
at all". I'm still appalled that this mammoth, 125 K lines of codes
driver got merged in the Linux kernel and is barely useful [0] when
the proprietary binary blobs are not installed.

Maxim

[0]  Booting an AMD R9 285 GPU without the binary blobs installed would
leave me to a black screen last time I tried, using Debian 9.

Re: Request for commit access

[Laura Lazzati]

> I will use the attached OpenPGP subkey  for signing commits.
Great!

Please, write to me to see how to improve the audios - appart from
haivng your native accent :)
Regards :)
Laura

Re: Request for commit access

[Paul Garlick]

Hi Ludo,

> welcome aboard!  :-)

Great, many thanks.

I will use the attached OpenPGP subkey  for signing commits.

Best regards,

Paul.


signature.asc
Description: This is a digitally signed message part

Re: Status update on 1.0

[mikadoZero]

Ricardo Wurmus writes:

> mikadoZero  writes:
>
>>>   • “GuixSD” has been removed from the web site and from almost all of
>>> the source code.  Still need to fix the file names that appear in
>>> Makefile.am.
>>
>> Is it to be changed to "Guix SD"?
>
> Just “Guix system”.

I will wait for patch #34848 to be committed before looking at this.

Re: Status update on 1.0

[L p R n d n]

"pelzflorian (Florian Pelz)"  writes:

> On Wed, Mar 13, 2019 at 06:08:38PM +0100, Ricardo Wurmus wrote:
>> mikadoZero  writes:
>> 
>> >>   • “GuixSD” has been removed from the web site and from almost all of
>> >> the source code.  Still need to fix the file names that appear in
>> >> Makefile.am.
>> >
>> > Is it to be changed to "Guix SD"?
>> 
>> Just “Guix system”.
>> 
>
> In the manual I sometimes see “Guix System” with a capital S.  Which
> is correct?
>
> When doing translations, should the English name be kept as a proper
> name as with GuixSD?  I would prefer to translate it to a German
> “Guix-System” (with hyphen) to avoid misunderstandings (many Germans
> would read an English “Guix System” with German pronunciation anyway).
> For other languages “Guix Système” or maybe “Guix 系统” or so of
> course does not resemble the guix system command as much anymore.
>
> Regards,
> Florian

Re: Status update on 1.0

[Danny Milosavljevic]

On Wed, 13 Mar 2019 17:00:55 +0100
Pierre Neidhardt  wrote:

> > The last time I tried the installer it didn't work on AMD(GPU) cards.  I'll 
> > give
> > it another go.  
> 
> I've experienced the same issue and I'm quite sure this is because the 
> installer
> uses KMSCON which only works with the proprietary amdgpu kernel module.  
> During
> FOSDEM, Mathieu mentioned that KMSCON was chosen because it works better with
> text/input encoding, if I recall correctly. 

Or find out why on earth KMSCON needs the prorietary amdgpu kernel module.

It's not exactly 3D graphics, so what is going on?  Furthermore, vesafb should
always work regardless (if slowly, but who cares).


pgpEnA9wExOv7.pgp
Description: OpenPGP digital signature

Re: Status update on 1.0

[pelzflorian (Florian Pelz)]

On Wed, Mar 13, 2019 at 06:08:38PM +0100, Ricardo Wurmus wrote:
> mikadoZero  writes:
> 
> >>   • “GuixSD” has been removed from the web site and from almost all of
> >> the source code.  Still need to fix the file names that appear in
> >> Makefile.am.
> >
> > Is it to be changed to "Guix SD"?
> 
> Just “Guix system”.
> 

In the manual I sometimes see “Guix System” with a capital S.  Which
is correct?

When doing translations, should the English name be kept as a proper
name as with GuixSD?  I would prefer to translate it to a German
“Guix-System” (with hyphen) to avoid misunderstandings (many Germans
would read an English “Guix System” with German pronunciation anyway).
For other languages “Guix Système” or maybe “Guix 系统” or so of
course does not resemble the guix system command as much anymore.

Regards,
Florian

Re: ; XXX: remove when Inetutils suffices

[mikadoZero]

Leo Famulari writes:

>> What does XXX in a comment mean?  I have seen it a couple times.
>
> It indicates something undesirable. Like a really nasty hack to
> work-around something or a problem upstream that we have no good
> solution for. Sort of like TODO but with extra complications.

Thanks for the explanation.

Re: Status update on 1.0

[Ricardo Wurmus]

mikadoZero  writes:

>>   • “GuixSD” has been removed from the web site and from almost all of
>> the source code.  Still need to fix the file names that appear in
>> Makefile.am.
>
> Is it to be changed to "Guix SD"?

Just “Guix system”.

-- 
Ricardo

Re: Status update on 1.0

[mikadoZero]

Ludovic Courtès writes:

>   • The graphical installer has been merged (yay!) but we still need to
> discuss it in the manual and to test it some more.

I was just going to install Guix SD on another system.  So I could try
the installer.  I could also try my hand at texinfo and do some
documentation of the graphical installer.

>   • “GuixSD” has been removed from the web site and from almost all of
> the source code.  Still need to fix the file names that appear in
> Makefile.am.

Is it to be changed to "Guix SD"?

Greping the Guix repo it looks like “GuixSD” is in documentation (in
different languages) and source code comments.

What should be done when it is part of something more important like
file paths, variable name or command line argument?

I can start with the doc directory.

Re: ; XXX: remove when Inetutils suffices

[Leo Famulari]

On Wed, Mar 13, 2019 at 11:44:20AM -0400, mikadoZero wrote:
> system.scm line 537:
> 
> net-tools ; XXX: remove when Inetutils suffices
> 
> git log -L 537,537:system.scm outputs:
> 
> commit 6f436c54d6d9698e62639de31a845cd9b9167423
> Date:   Wed Jun 4 2014
> 
> This comment was committed in 2014.  Is inetutils at the point where
> net-tools can be removed?

Someone would have to audit the uses of the programs in net-tools and
decide if they are no longer needed in the base system, and if users do
not expect them anymore. They are old and venerable so they are sort of
sticky at this point, even if they no longer represent the state of the
art.

> What does XXX in a comment mean?  I have seen it a couple times.

It indicates something undesirable. Like a really nasty hack to
work-around something or a problem upstream that we have no good
solution for. Sort of like TODO but with extra complications.


signature.asc
Description: PGP signature

Re: Status update on 1.0

[Pierre Neidhardt]

> The last time I tried the installer it didn't work on AMD(GPU) cards.  I'll 
> give
> it another go.

I've experienced the same issue and I'm quite sure this is because the installer
uses KMSCON which only works with the proprietary amdgpu kernel module.  During
FOSDEM, Mathieu mentioned that KMSCON was chosen because it works better with
text/input encoding, if I recall correctly.  The solution would be to fallback
on something else with lesser encoding support, which is still better than a
black screen :p

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

; XXX: remove when Inetutils suffices

[mikadoZero]

system.scm line 537:

net-tools ; XXX: remove when Inetutils suffices

git log -L 537,537:system.scm outputs:

commit 6f436c54d6d9698e62639de31a845cd9b9167423
Date:   Wed Jun 4 2014

This comment was committed in 2014.  Is inetutils at the point where
net-tools can be removed?

If it is then I can submit a patch to remove the line.

What does XXX in a comment mean?  I have seen it a couple times.

Re: Publishing with Lzip

[Pierre Neidhardt]

Thanks for clarifying this!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Status update on 1.0

[Tobias Geerinckx-Rice]

Ludo',

Ludovic Courtès wrote:
  • The graphical installer has been merged (yay!) but we still 
  need to

discuss it in the manual and to test it some more.


The last time I tried the installer it didn't work on AMD(GPU) 
cards.  I'll give it another go.


 • “GuixSD” has been removed from the web site and from almost 
 all of
   the source code.  Still need to fix the file names that 
   appear in

   Makefile.am.


Sounds trivial enough (hah) for me to do this evening, but then 
that's true for anybody.


  • I think we should add ‘guix install’, ‘guix remove’, and 
  ‘guix

upgrade’.


Hmmm… m.  What would these do?

Thanks for keeping this ball rolling in the air with your eye on 
it,


T G-R

Re: DNS delegation

[Julien Lepiller]

Le 2019-03-13 16:00, Ludovic Courtès a écrit :

Hi Julien,

Julien Lepiller  skribis:


we've already discussed that multiple times, we'd like to have a DNS
delegation for guix.gnu.org, so that we can manage the zone ourselves
without having to rely too much on fsf sysadmins.

Here is a patch (untested) that aims at doing that. I've configured
bayfront and berlin to be DNS authoritative servers. bayfront is the
master (it is the one that needs to be updated when a change happens 
in

the zone), and berlin is set as slave (it will automatically follow
changes in bayfront). I've enabled dnssec on bayfront, since it's the
one that's going to sign the zone, and transfer signatures to its 
slave.


Cool, thanks for working on it!


Currently the zone (in modules/sysadmin/dns.scm) is incomplete. What
needs to be there?


I guess we’d need to have roughly the same entries as we currently have
on guix.info, so what you wrote is a good start and we can always 
adjust

later.


From 331a85e469579c02a3fc338a6fb0bade3916c666 Mon Sep 17 00:00:00 2001
From: Julien Lepiller 
Date: Mon, 4 Mar 2019 22:00:22 +0100
Subject: [PATCH] hydra: Add dns services for guix.gnu.org.

* hydra/bayfront.scm (services): Add knot-service.
* hydra/berlin.scm (services): Add knot-service.
* hydra/modules/sysadmin/dns.scm: New file.


So it looks like this does the work on the Guix side.

We now need to get the gnu.org admins to delegate to both bayfront and
berlin, is that correct?  Anything else we need to do?


I didn't think too much about it, but we need to host the website
(guix.gnu.org) somewhere and configure a vhost/server block accordingly,
unless gnu.org/software/guix stays the official website?



Thank you!

Ludo’.

Status update on 1.0

[Ludovic Courtès]

Hello Guix!

When we said we’d try to release 1.0 for FOSDEM, we were talking about
FOSDEM *2019*, which is well over now, so I think we need to get our act
together and complete the remaining tasks for 1.0.  :-)

Looking at the

plus my own memories, here are work items that still need to be
addressed:

  • The graphical installer has been merged (yay!) but we still need to
discuss it in the manual and to test it some more.

  • The installer should be changed to produce the right
‘initrd-modules’ field, using the same mechanism used by
‘check-device-initrd-modules’.

  • The story about grafts and displaying upfront what’s going to be
built is not fixed yet.  I’ve been toying with the build
continuations but nothing conclusive yet.  I’ve also thought about
quick hacks instead but nothing concrete either.

  • IPv6 support in ‘static-networking-service’: as discussed at the
Guix Days, we’ll probably need to Linux Netlink sockets to do that
rather than the old ioctls currently used in (guix build syscalls).

The netlink interface for network config is vaguely documented at
.
Writing bindings for ‘sendmsg’ and the associated data structures
looks reasonable… it just needs to be done.

  • GDM works well for GNOME and WMs that provide a .session file.
However it still doesn’t honor ~/.xsession.  We discussed it before
and dropped the ball.  Timothy, what’s missing?  I’d really like to
make it the default.

  • GDM’s closure is 1.3 GiB, we should do something about it.

  • I think we should add ‘guix install’, ‘guix remove’, and ‘guix
upgrade’.

  • “GuixSD” has been removed from the web site and from almost all of
the source code.  Still need to fix the file names that appear in
Makefile.am.

  • Work for guix.gnu.org is on its way thanks to Julien, hopefully done
soon.

If you’re interesting in tackling a specific issue, please share.  Let’s
all tackle these so we can finally reach that milestone and celebrate!

Ludo’.

Re: Guix pronunciation

[Laura Lazzati]

Bonjour Ludo! :)

> Should we write this more prominently somewhere?  Probably!  :-)
Thank you for the explanation, I guess I read the first link before
from somewhere, but what I was asking was if since people are
discussing if the name is appropriate, maybe the Guile + Nix could be
added, like "it is pronounced like geeks, but it comes from..."
Maybe, in those cultures where a geek is seen badly or may be seen not
professional, or could make people not become a contributor - here I
come promoting ;) - or whatever, know how to pronounce it but where it
comes from too. IMHO I also agree it is a good Idea adding the
similarities and differences.

Regards :)
Laura

Re: DNS delegation

[Ludovic Courtès]

Hi Julien,

Julien Lepiller  skribis:

> we've already discussed that multiple times, we'd like to have a DNS
> delegation for guix.gnu.org, so that we can manage the zone ourselves
> without having to rely too much on fsf sysadmins.
>
> Here is a patch (untested) that aims at doing that. I've configured
> bayfront and berlin to be DNS authoritative servers. bayfront is the
> master (it is the one that needs to be updated when a change happens in
> the zone), and berlin is set as slave (it will automatically follow
> changes in bayfront). I've enabled dnssec on bayfront, since it's the
> one that's going to sign the zone, and transfer signatures to its slave.

Cool, thanks for working on it!

> Currently the zone (in modules/sysadmin/dns.scm) is incomplete. What
> needs to be there?

I guess we’d need to have roughly the same entries as we currently have
on guix.info, so what you wrote is a good start and we can always adjust
later.

> From 331a85e469579c02a3fc338a6fb0bade3916c666 Mon Sep 17 00:00:00 2001
> From: Julien Lepiller 
> Date: Mon, 4 Mar 2019 22:00:22 +0100
> Subject: [PATCH] hydra: Add dns services for guix.gnu.org.
>
> * hydra/bayfront.scm (services): Add knot-service.
> * hydra/berlin.scm (services): Add knot-service.
> * hydra/modules/sysadmin/dns.scm: New file.

So it looks like this does the work on the Guix side.

We now need to get the gnu.org admins to delegate to both bayfront and
berlin, is that correct?  Anything else we need to do?

Thank you!

Ludo’.

Re: Splitting mkvtoolnix outputs: cycle detected in the references

[Ludovic Courtès]

Hi,

Pierre Neidhardt  skribis:

> I'm trying to split mkvtoolnix-gui (depends on Qt) to a separate "gui" output.
> "out" would only contain the command line tools.
>
> Disabling Qt shrinks the closure size from 1.5+ GB to 277 MB.  Pretty
> neat, huh? :)

Yup!

> I naively tried to move mkvtoolnix-gui to the "gui" output:
>
> (add-after 'install 'post-install
>(lambda* (#:key outputs #:allow-other-keys)
>  ;; Move the Qt interface to "gui".
>  (let ((out (assoc-ref outputs "out"))
>(gui (assoc-ref outputs "gui")))
>(mkdir-p (string-append gui "/bin"))
>(rename-file (string-append out "/bin/mkvtoolnix-gui")
> (string-append gui "/bin/mkvtoolnix-gui")))
>  #t))
>
>
> But I get the following error after the
> `compress-documentation' phase:
>
> cycle detected in the references of 
> `/gnu/store/7asc0q7kik1ak463nj8g675hnab7h982-mkvtoolnix-31.0.0-gui'
>
> It's unclear to me why there would be a cycle.  Any clue how to
> investigate from there?

This error means that the two outputs, “out” and “gui”, refer to each
other; the daemon does not support that.

To find out where the references come from, you can build with -K, and
then grep -r for one output in the other.

If it turns out to be impossible to remove the cycle, I’d suggest making
a separate package for the GUI.

HTH!

Ludo’.

Re: create a symlink

[Ludovic Courtès]

Hello,

Rene  skribis:

> How I can change "/hurd/" by "/gnu/store/abc..-hurd-0.9/hurd/" in
>  through Guix?

I think /hurd is hard to avoid; it’s akin to /bin/sh, which is also
hard-coded in libc (for the ‘system’ function).  As you found out, you’d
need to change macros in libc headers, which means that libc could only
talk to a specific instance of the Hurd servers.  Furthermore, /hurd
needs to be writable.

So I would recommend keeping /hurd, at least as a first approach.

Happy hacking!

Ludo’.

Re: Publishing with Lzip

[Ludovic Courtès]

Hi!

Pierre Neidhardt  skribis:

>> I’d also recommend to re-read the API doc in the headers or whatever.
>> IME these APIs are very tricky to use and one has to pay attention to
>> every small detail.
>
> I read the manual too many times.  The headers are not documented.  The 
> examples
> don't tell us more about the API.
>
> I might be too inexperienced in the area, so maybe you or someone else could
> have a look at the manual.
>
> Else we could contact the maintainer and ask directly :D

Well, we’ll see!

>> According to the C standard an enum is an ‘int’.  So mapping them is
>> just a matter of producing/consuming ints.  The values of the enum start
>> from 0 and are incremented by 1 from then on, unless specific values are
>> provided.
>
> My question was whether it's possible to have the mapping done "symbolically."
> In C, you would match error values again the symbols of the enum, not against
> the number.  So if we map the error numbers manually in Guile, it would break
> whenever the API updates the enum.
>
> Maybe I'm just being overly picky here :p

Indeed.  :-)

The funny thing with the FFI is that it gives “a whole bunch of new
flexibility” to shoot yourself in the foot.  So for enums, while you
could do something fancy to extract the values from the headers (using
nyacc’s ffi-helper, or by running the C compiler at macro-expansion
time), what I would recommend is to just grab them once and for all.
:-)

In practice that works well: C library writers have an incentive to keep
ABI compatibility, so they’ll rarely change enum values.  This is
especially true for a library like this one whose API is probably set in
stone given that the scope of its functionality is well-defined.  We did
that for example in Guile-Gcrypt and Guile-Git and everything works
fine.

That also means that it’s a good idea to have unit tests that exercise
all the bindings.

HTH!

Ludo’.

Re: Guix pronunciation

[Ludovic Courtès]

Hi Laura,

Laura Lazzati  skribis:

>> As for those wondering why: “Guix” is initially just the contraction of
>> Guile + Nix.
> Thank you for the explanation. The person I met interested in at least
> playing whith Guix told me that was thinking of both Guix and Nix, and
> I was asked before about the differences. Is it in the manual? Because
> I don't remember reading it.  Maybe it could be added, before the
> pronunciation, WDYT?

Nix and Guix have technical similarities, in the same sense that Debian
and Fedora have technical similarities, but the projects have different
goals, priorities, commitments, and processes.  Guix is committed to
user freedom and to building software from source, for instance.

Nix and Guix have also significant technical differences arising from
the use, in Guix, of a single general-purpose language for everything,
with embedded domain-specific languages (EDSLs) as needed.  That, in
turn, makes the system very hackable and extensible, and that’s what
makes it easy to write several UIs (CLI, Emacs, web), simple UIs, new
tools around Guix like ‘guix pack’ or the Guix Workflow Language, etc.

I wrote about the initial vision regarding the programming language
approach in .  Ricardo wrote a more
up-to-date and more comprehensive answer on HN:
.

Should we write this more prominently somewhere?  Probably!  :-)

Ludo’.

Re: create a symlink

[Danny Milosavljevic]

Hi Rene,

On Tue, 12 Mar 2019 14:57:59 -0600
Rene  wrote:

> How I can change "/hurd/" by "/gnu/store/abc..-hurd-0.9/hurd/" in
>  through Guix?
> 
> --8<---cut here---start->8---
> /* Hurd servers are specified by symbols _HURD_FOO,
>the canonical pathname being /hurd/foo.  */
> 
> #define   _HURD   "/hurd/"
> #define _HURD_STARTUP   _HURD "startup"
> #define _HURD_PROC   _HURD "proc"
> #define _HURD_AUTH  _HURD "auth"
> --8<---cut here---end--->8---

Hmm, try to patch it out of the source code.

Modify /gnu/packages/hurd.scm to be something like:

(define-public hurd
  (package
[...]
(arguments
 `(#:phases
   (modify-phases %standard-phases
 (add-after 'unpack 'patch-paths
   (lambda* (#:key outputs #:allow-other-keys)
 (substitute* "hurd/paths.h"
  (("\"/hurd/\"")
(string-append "\"" (assoc-ref outputs "out") "\"")))
 #t))
 [...]



pgpiWpZCT9i8X.pgp
Description: OpenPGP digital signature

Re: Patch adding POWER9 cross compile support

[Tobias Platen]

I had to work on the core-updates branch, or in the past on the wip-gcc7 
branch. I mentioned this some month ago. The current branch has an 
outdated gcc version.


On 03/12/2019 03:10 PM, Ludovic Courtès wrote:

Hi!

Efraim Flashner  skribis:


On Sun, Mar 10, 2019 at 09:20:04PM +0100, Tobias Platen wrote:

I ran configure on my Talos II, and got the following error message.

checking for the Guix system type... powerpc64le-linux


Sure but that’s the next step.  My question was about the triplet you
passed to ‘--target’ when cross-compiling from your Intel(?) machine,
but I think I can derive the answer now:

   guix build --target=powerpc64le-linux-gnu …


Guix already knows about this architecture, but building glibc will fail if
gcc does not have the float128 datatype. Once I saw this link[1] on the guix
mailing list, I knew how to solve the build error.

For the second question I could not find an answer.

[1] http://lists.busybox.net/pipermail/buildroot/2017-September/201379.html


Alright.

Thanks for the info.


In the off chance we ever wish to support powerpc64 big endian, I
suggest instead using (string-prefix? "powerpc64*-" target)


Yes.

Unfortunately, with just this extra --with-long-double-128, this:

   guix build sed --target=powerpc64le-linux-gnu

eventually leads to a glibc build failure:

--8<---cut here---start->8---
running configure fragment for sysdeps/unix/sysv/linux/powerpc
checking whether powerpc64le-linux-gnu-gcc -g -O2 -mlong-double-128 uses IBM 
extended format... yes
running configure fragment for sysdeps/unix/sysv/linux
checking installed Linux kernel header files... 3.2.0 or later
configure: WARNING: minimum kernel version reset to 3.10.0
checking for kernel header at least 3.10.0... ok
running configure fragment for sysdeps/gnu
running configure fragment for sysdeps/powerpc/powerpc64/le
checking if powerpc64le-linux-gnu-gcc supports binary128 floating point type... 
no
checking if the target machine is at least POWER8... yes
configure: error: ***  binary128 floating point type (GCC >= 6.2) is required 
on powerpc64le.
--8<---cut here---end--->8---

See ‘config.log’ excerpt below.  Do you happen to have an additional
change needed?

Thanks,
Ludo’.

--8<---cut here---start->8---
configure:6698: result: running configure fragment for 
sysdeps/powerpc/powerpc64/le
configure:5: checking if powerpc64le-linux-gnu-gcc supports binary128 floating 
point type
configure:31: powerpc64le-linux-gnu-gcc -c -g -O2 -Werror -mfloat128  conftest.c 
>&5
powerpc64le-linux-gnu-gcc: error: unrecognized command line option '-mfloat128'
configure:31: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Library"
| #define PACKAGE_TARNAME "glibc"
| #define PACKAGE_VERSION "(see version.h)"
| #define PACKAGE_STRING "GNU C Library (see version.h)"
| #define PACKAGE_BUGREPORT "https://sourceware.org/bugzilla/";
| #define PACKAGE_URL "http://www.gnu.org/software/glibc/";
| #define PKGVERSION "(GNU libc) "
| #define REPORT_BUGS_TO ""
| #define HAVE_TUNABLES 1
| #define HAVE_CC_NO_STACK_PROTECTOR 1
| #define STACK_PROTECTOR_LEVEL 0
| #define USE_MULTIARCH 1
| #define HAVE_ASM_SET_DIRECTIVE 1
| #define HAVE_SDATA_SECTION 1
| #define NO_CTORS_DTORS_SECTIONS 1
| #define HAVE_Z_COMBRELOC 1
| #define HAVE_CC_INHIBIT_LOOP_TO_LIBCALL 1

| #define HAVE_EHDR_START 1
| #define HAVE_BUILTIN_TRAP 1
| #define HAVE_ELFV2_ABI 1
| #define __LINUX_KERNEL_VERSION (3 * 65536 + 10 * 256 + 0)
| #define __ABI_TAG_VERSION 2,6,32
| #define HAVE_INLINED_SYSCALLS 1
| /* end confdefs.h.  */
|
| __float128 a, b, c, d, e;
| int i;
|
| __float128
| foobar (__float128 x)
| {
|   a = __builtin_nansq ("0");
|   b = __builtin_huge_valq ();
|   c = __builtin_infq ();
|   d = __builtin_fabsq (x);
|   e = __builtin_nanq ("0");
|   i = __builtin_signbit (x);
|   return __builtin_copysignq (x, x);
| }
|
configure:39: result: no
configure:47: checking if the target machine is at least POWER8
configure:61: powerpc64le-linux-gnu-gcc -c -g -O2   conftest.c >&5
configure:61: $? = 0
configure:68: result: yes
configure:75: error: ***  binary128 floating point type (GCC >= 6.2) is 
required on powerpc64le.
--8<---cut here---end--->8---