Re: website: Building fails because of missing locales
On Tuesday, April 6, 2021 8:20 PM, Julien Lepiller wrote:
> Le Tue, 6 Apr 2021 14:11:03 -0400,
> Leo Famulari l...@famulari.name a écrit :
>
> > On Tue, Apr 06, 2021 at 03:59:20PM +, Luis Felipe wrote:
> >
> > > Hello,
> > > I updated my local copy of guix-artwork repository today and now
> > > running "haunt build" fails with this message:
[...]
> > This happens for me too.
>
> Attached is a patch to the manifest.scm that should fix the issue: it
> ensures that you enter an environment where the locales corresponding
> to po/LINGUAS are available. Can you check if it fixes your issues?
Leo, Julien, thanks for checking.
Julien, unfortunately I get the same error after applying the patch:
LANG=C GUIX_WEB_SITE_LOCAL=yes guix environment -C -m manifest.scm -E
GUIX_LOCPATH -E LANG --share=$HOME/.guix-profile/lib/locales -E
GUIX_WEB_SITE_LOCAL --share=/tmp -- haunt build
Backtrace:
In ice-9/threads.scm:
390:8 19 (_ _)
In ice-9/boot-9.scm:
3223:13 18 (_)
In ice-9/threads.scm:
390:8 17 (_ _)
In ice-9/boot-9.scm:
3507:20 16 (_)
2806:4 15 (save-module-excursion _)
3527:26 14 (_)
In unknown file:
13 (primitive-load-path "apps/base/data" #)
In ice-9/eval.scm:
626:19 12 (_ #)
173:55 11 (_ #)
174:20 10 (_ #)
177:32 9 (lp (# ?))
159:9 8 (_ #(# (G_ ?) ?))
159:9 7 (_ #(# (G_ ?) ?))
159:9 6 (_ #(# (G_ ?) ?))
163:9 5 (_ #(# (G_ ?) ?))
In srfi/srfi-1.scm:
586:29 4 (map1 ("de_DE" "en_US" "eo" "es_ES" "fr_FR" "ko_KR" # #))
586:29 3 (map1 ("en_US" "eo" "es_ES" "fr_FR" "ko_KR" "ru_RU" "?"))
586:17 2 (map1 ("eo" "es_ES" "fr_FR" "ko_KR" "ru_RU" "zh_CN"))
In ice-9/eval.scm:
619:8 1 (_ #(#(# # ?) ?))
In unknown file:
0 (setlocale 6 "eo.utf8")
ERROR: In procedure setlocale:
In procedure setlocale: Invalid argument
Racket 8 and store references (was [security] Chunked store references in .zo files in Racket 8 #47614)
On Tue, 6 Apr 2021, Mark H Weaver wrote: Anyway, I doubt that imposing such a limitation would adequately solve the problem here of chunked references in Racket 8, because I suspect that Racket 8 could split store references at arbitrary points in the string. I doubt that we can safely assume that the hash component of store references will be stored contiguously in *.zo files. Mark and everyone, I wanted to spin off a subthread on guix-devel, to make you aware of another problem that we've run into with reference in .zo getting mangled: https://issues.guix.gnu.org/47180 Best, Jack
Re: Please review blog post draft: powerpc64le-linux support
On Tue, 2021-04-06 at 00:15 -0700, Chris Marusich wrote: > Hi, > > Léo and I have drafted the following blog post. Could you take a few > minutes to read it and give us your thoughts? > > It's a work in progress. The primary goal is to announce the new > powerpc64le-linux support and explain why it matters (POWER9 is an > exciting, freedom-friendly platform!). The secondary goal is to > explain > some of the details about what we did, and invite people to get > involved. > > Your feedback would be highly appreciated! > It's been mostly you here Chris, thank you so much for writing it, as others said, it is really beautifully written! Unfortunately I havent felt enough peace of mind to write like you did :-( I would've liked to write about the early days where I met some problems with the core-updates branch having to rebase several times and learning GNU Guix at the same time since my first ever project related to GNU Guix was porting before even trying to use it elsewhere. Having to learn the GNU commit message guidelines, then learning git- send-email and GNU Emacs (since that's where all dev tools are), all that to contribute to GNU Guix and get this port in. Aaaahh very long story! Léo signature.asc Description: This is a digitally signed message part
Re: guix home: Call for Early Adopters
On Tue, 2021-04-06 at 20:21 +0300, Andrew Tropin wrote: > Guix Home has most essential features ready and now requires some > real-world usage from a few more people to be sure that there are no > fundamental issues with it. > > We are looking for 3-5 advanced GNU/Linux users (not necessary Guix), > who want to try `guix home` and are willing to spend some time and > effort configuring it, and in case of issues reporting them to > https://lists.sr.ht/~abcdw/rde-discuss > > We will be supporting early adopters in the rde-discuss mailing list > on > weekdays. Also, you can reach us on #guix IRC channel for a casual > talk > or quick question, @abcdw and @yoctocell. > > On `date --date="2021-04-14 15:00:00 UTC"` we plan a jitsi call, to > make sure that everyone is up and running, provide some help and/or > answer questions. Will schedule consequent calls if needed. > > To participate you need to have a working installation of Guix the > package manager, and have a local checkout of the rde Git > repository[1]. Reply to the thread in rde-discuss [2] with a few > lines about you and/or your technical background and please attach > the > output of running `make env-info` at the root of the rde repository > to > be sure that Guix and rde are installed and everything works > correctly. > > See you soon, > Andrew Tropin. > > Useful links: > [1] https://git.sr.ht/~abcdw/rde > [2] https://lists.sr.ht/~abcdw/rde-discuss > Really Awesome :-) Could you sign your rde channel? I am not at ease adding unsigned channels since that's basically RCE into my system :-) Thanks!! signature.asc Description: This is a digitally signed message part
Re: [PATCH 9/9] gnu: nss: Skip tests on powerpc-linux.
On Tue, Apr 6, 2021 at 9:18 PM Efraim Flashner wrote: > On Tue, Apr 06, 2021 at 07:00:50PM +0200, Vincent Legoll wrote: > > s/sporatically/sporadically/ > > Not going to lie, spelling is hard. I normally have spell check turned > off for scheme files. But you *are* lying, you have the guile spell-(and-syntax-)checker enabled for all your scheme files, and it is a picky one... ;-) -- Vincent Legoll
Re: [PATCH 7/9] build: qemu-command: Add support for powerpc.
On Tue, Apr 6, 2021 at 9:18 PM Efraim Flashner wrote:
>
> On Tue, Apr 06, 2021 at 07:02:47PM +0200, Vincent Legoll wrote:
> > Hello,
> >
> > On Tue, Apr 6, 2021 at 2:44 PM Efraim Flashner
> > wrote:
> > > +((string-match "powerpc" cpu) "ppc")
> >
> > Won't there be some "powerpc64le" conflict here ?
> >
>
> I thought not, but it appears it would match all of powerpc*
>
> (ins)scheme@(guile-user)> (use-modules (ice-9 regex))
> (ins)scheme@(guile-user)> (string-match "powerpc" "powerpc")
> $1 = #("powerpc" (0 . 7))
> (ins)scheme@(guile-user)> (string-match "powerpc" "powerpc64le")
> $2 = #("powerpc64le" (0 . 7))
> (ins)scheme@(guile-user)> (string-match "powerpc" "armhf")
> $3 = #f
>
> If it were string=? then it would be fine, but that would break the
> ^i[3456]86$ regex. It looks like I would need to add a powerpc64 case
> above the powerpc case. Looking at the output of qemu adding
> ((string-match "powerpc64" cpu) "ppc64") would be the right answer.
or you can use anchored regex, like in the x86 case:
((string-match "^powerpc$" cpu) "ppc")
--
Vincent Legoll
Re: A new wip-emacs branch
Am Dienstag, den 06.04.2021, 20:21 +0200 schrieb Xinglu Chen: > On Tue, Apr 06 2021, Leo Prikler wrote: > > > There are still some packages, that use the old convention, e.g. > > emacs- > > geiser. > > FYI Geiser has recently been slit up into multiple packages with one > core Geiser package[1]. Should the Geiser package be updated in > wip-emacs or directly on master? > > [1]: https://github.com/melpa/melpa/pull/7514 That depends. If geiser now uses an unaltered emacs-build-system it can go either way, but if it still has some special needs to take care of, updating it on wip-emacs will mean less work overall. Regards, Leo
Re: website: Building fails because of missing locales
Le Tue, 6 Apr 2021 14:11:03 -0400,
Leo Famulari a écrit :
> On Tue, Apr 06, 2021 at 03:59:20PM +, Luis Felipe wrote:
> > Hello,
> >
> > I updated my local copy of guix-artwork repository today and now
> > running "haunt build" fails with this message:
> >
> >
> > Backtrace:
> > In ice-9/threads.scm:
> > 390:8 19 (_ _)
> > In ice-9/boot-9.scm:
> > 3223:13 18 (_)
> > In ice-9/threads.scm:
> > 390:8 17 (_ _)
> > In ice-9/boot-9.scm:
> > 3507:20 16 (_)
> >2806:4 15 (save-module-excursion _)
> > 3527:26 14 (_)
> > In unknown file:
> > 13 (primitive-load-path "apps/base/data" # > 7fd2e…>) In ice-9/eval.scm:
> >626:19 12 (_ #)
> >173:55 11 (_ #)
> >174:20 10 (_ #)
> >177:32 9 (lp (#
> > …)) 159:9 8 (_ #(# (G_ …)
> > …)) 159:9 7 (_ #(# (G_ …)
> > …)) 159:9 6 (_ #(# (G_ …)
> > …)) 163:9 5 (_ #(# (G_ …)
> > …)) In srfi/srfi-1.scm:
> >586:29 4 (map1 ("de_DE" "en_US" "eo" "es_ES" "fr_FR" "ko_KR" #
> > #)) 586:29 3 (map1 ("en_US" "eo" "es_ES" "fr_FR" "ko_KR" "ru_RU"
> > "…")) 586:17 2 (map1 ("eo" "es_ES" "fr_FR" "ko_KR" "ru_RU"
> > "zh_CN")) In ice-9/eval.scm:
> > 619:8 1 (_ #(#(# # …)
> > …)) In unknown file:
> >0 (setlocale 6 "eo.utf8")
> >
> > ERROR: In procedure setlocale:
> > In procedure setlocale: Argumento inválido
> >
>
> This happens for me too.
>
Attached is a patch to the manifest.scm that should fix the issue: it
ensures that you enter an environment where the locales corresponding
to po/LINGUAS are available. Can you check if it fixes your issues?
Thanks!
>From 432145b027b36cc0eedf28d89664a6646db9ebc6 Mon Sep 17 00:00:00 2001
From: Julien Lepiller
Date: Tue, 6 Apr 2021 22:16:43 +0200
Subject: [PATCH] website: Add locales in manifest.
* website/manifest.scm: Add locale definition for all our translations.
---
website/manifest.scm | 53 +---
1 file changed, 40 insertions(+), 13 deletions(-)
diff --git a/website/manifest.scm b/website/manifest.scm
index eda382a..6248c87 100644
--- a/website/manifest.scm
+++ b/website/manifest.scm
@@ -1,6 +1,8 @@
(use-modules (guix packages)
((gnu packages package-management) #:select (guix))
((gnu packages guile-xyz) #:select (haunt))
+ (gnu system locale)
+ (ice-9 rdelim)
(srfi srfi-1))
(define the-good-guile
@@ -14,17 +16,42 @@
`(("guile" ,the-good-guile)
,@(alist-delete "guile" (package-inputs haunt))
-(packages->manifest
- (append
- ;; Guile needs to be compatible
- (list
- guix
- the-good-guile
- haunt-the-ghost)
+(define locales
+ (locale-directory
+(call-with-input-file "po/LINGUAS"
+ (lambda (port)
+(let loop ((line (read-line port))
+ (locales '()))
+ (if (eof-object? line)
+ locales
+ (if (equal? (string-ref line 0) #\#)
+ (loop (read-line port) locales)
+ (loop (read-line port)
+(cons
+ (locale-definition
+(name (string-append line ".utf8"))
+(source line))
+ locales)))
+#:libcs
+(list glibc)))
- ;; Other packages
- (map specification->package
- (list
-"glibc-locales"
-"git"
-"guile-syntax-highlight"
+(manifest
+ (cons
+(manifest-entry
+ (name "locales")
+ (version "0")
+ (item locales))
+(manifest-entries
+ (packages->manifest
+ (append
+;; Guile needs to be compatible
+(list
+ guix
+ the-good-guile
+ haunt-the-ghost)
+
+;; Other packages
+(map specification->package
+ (list
+ "git"
+ "guile-syntax-highlight")))
--
2.31.0
Re: [PATCH 4/9] gnu: mesa: Add support for powerpc-linux.
On Tue, Apr 06, 2021 at 03:32:48PM +0300, Efraim Flashner wrote:
>
> + ;; The llvm-based tests are flakey on non-Intel hardware.
> + #:tests? ,(if (string=? "powerpc-linux" (or (%current-system)
> + (%current-target-system)))
> + '#f '#t)
> +
>
Looks like Charlène of OpenBSD (I think?) is right, there are some
endianness bugs in mesa with llvm. I've tried, building mesa for powerpc
without llvm isn't actually possible, so disabled tests for now.
Snippet from the test suite log:
Testing util_format_a1b5g5r5_unorm_unpack_rgba_8unorm ...
FAILED: {0x39, 0xc5, 0x00, 0x00} obtained
{0x00, 0x00, 0xff, 0x00} expected
FAILED: {0xc5, 0x00, 0x18, 0xff} obtained
{0x00, 0xff, 0x00, 0x00} expected
FAILED: {0x00, 0x18, 0xe6, 0x00} obtained
{0xff, 0x00, 0x00, 0x00} expected
FAILED: {0x00, 0x20, 0x00, 0x00} obtained
{0x00, 0x00, 0x00, 0xff} expected
Testing util_format_a1b5g5r5_unorm_norm_flags ...
Testing util_format_x1b5g5r5_unorm_fetch_rgba_float ...
FAILED: {0.225806, 0.774194, 0.00, 1.00} obtained
{0.00, 0.00, 1.00, 1.00} expected
FAILED: {0.774194, 0.00, 0.096774, 1.00} obtained
{0.00, 1.00, 0.00, 1.00} expected
FAILED: {0.00, 0.096774, 0.903226, 1.00} obtained
{1.00, 0.00, 0.00, 1.00} expected
FAILED: {1.00, 0.870968, 1.00, 1.00} obtained
{1.00, 1.00, 1.00, 1.00} expected
Testing util_format_x1b5g5r5_unorm_pack_rgba_float ...
FAILED: 00 3e obtained
3e 00 expected
FAILED: 07 c0 obtained
c0 07 expected
FAILED: f8 00 obtained
00 f8 expected
FAILED: ff fe obtained
fe ff expected
--
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: [PATCH 9/9] gnu: nss: Skip tests on powerpc-linux.
On Tue, Apr 06, 2021 at 07:00:50PM +0200, Vincent Legoll wrote: > Hello, > > On Tue, Apr 6, 2021 at 2:44 PM Efraim Flashner wrote: > > + ;; Tests on powerpc-linux take forever and fail sporatically. > > s/sporatically/sporadically/ > Not going to lie, spelling is hard. I normally have spell check turned off for scheme files. -- 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: [PATCH 7/9] build: qemu-command: Add support for powerpc.
On Tue, Apr 06, 2021 at 07:02:47PM +0200, Vincent Legoll wrote:
> Hello,
>
> On Tue, Apr 6, 2021 at 2:44 PM Efraim Flashner wrote:
> > +((string-match "powerpc" cpu) "ppc")
>
> Won't there be some "powerpc64le" conflict here ?
>
I thought not, but it appears it would match all of powerpc*
(ins)scheme@(guile-user)> (use-modules (ice-9 regex))
(ins)scheme@(guile-user)> (string-match "powerpc" "powerpc")
$1 = #("powerpc" (0 . 7))
(ins)scheme@(guile-user)> (string-match "powerpc" "powerpc64le")
$2 = #("powerpc64le" (0 . 7))
(ins)scheme@(guile-user)> (string-match "powerpc" "armhf")
$3 = #f
If it were string=? then it would be fine, but that would break the
^i[3456]86$ regex. It looks like I would need to add a powerpc64 case
above the powerpc case. Looking at the output of qemu adding
((string-match "powerpc64" cpu) "ppc64") would be the right answer.
--
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: A new wip-emacs branch
On Tue, Apr 06 2021, Leo Prikler wrote: > There are still some packages, that use the old convention, e.g. emacs- > geiser. FYI Geiser has recently been slit up into multiple packages with one core Geiser package[1]. Should the Geiser package be updated in wip-emacs or directly on master? [1]: https://github.com/melpa/melpa/pull/7514
Re: website: Building fails because of missing locales
Oops, I happen to have an esperanto locale on my system, and berlin probably
has one too. That would explain why I was able to build the website, and why
the website is updated.
This is how I defined that locale:
https://git.lepiller.eu/system-configuration/tree/-/modules/config/os.scm#L117
Weirdly, glibc-locales provides "eo" but not "eo.utf8"
Le 6 avril 2021 11:59:20 GMT-04:00, Luis Felipe
a écrit :
>Hello,
>
>I updated my local copy of guix-artwork repository today and now
>running "haunt build" fails with this message:
>
>
>Backtrace:
>In ice-9/threads.scm:
>390:8 19 (_ _)
>In ice-9/boot-9.scm:
> 3223:13 18 (_)
>In ice-9/threads.scm:
>390:8 17 (_ _)
>In ice-9/boot-9.scm:
> 3507:20 16 (_)
> 2806:4 15 (save-module-excursion _)
> 3527:26 14 (_)
>In unknown file:
> 13 (primitive-load-path "apps/base/data" #)
>In ice-9/eval.scm:
> 626:19 12 (_ #)
> 173:55 11 (_ #)
> 174:20 10 (_ #)
> 177:32 9 (lp (# …))
>159:9 8 (_ #(# (G_ …) …))
>159:9 7 (_ #(# (G_ …) …))
>159:9 6 (_ #(# (G_ …) …))
>163:9 5 (_ #(# (G_ …) …))
>In srfi/srfi-1.scm:
> 586:29 4 (map1 ("de_DE" "en_US" "eo" "es_ES" "fr_FR" "ko_KR" # #))
> 586:29 3 (map1 ("en_US" "eo" "es_ES" "fr_FR" "ko_KR" "ru_RU" "…"))
> 586:17 2 (map1 ("eo" "es_ES" "fr_FR" "ko_KR" "ru_RU" "zh_CN"))
>In ice-9/eval.scm:
>619:8 1 (_ #(#(# # …) …))
>In unknown file:
> 0 (setlocale 6 "eo.utf8")
>
>ERROR: In procedure setlocale:
>In procedure setlocale: Argumento inválido
>
>
>I see in the commit log that there's a new commit adding Esperanto to
>the website translations, but I was surprised to see this error because
>the website manifest.scm includes "glibc-locales" and I thought it
>would provide "eo.utf8" locale, but, apparently, it doesn't (see
>"locale -a" output below).
>
>Also, if I understand correctly, the package description for
>"glibc-locales" says it provides more than 400 locales, but once
>installed, I see less than 40:
>
>
>$ locale -a
>C
>ca_ES.utf8
>cs_CZ.utf8
>da_DK.utf8
>de_DE.utf8
>el_GR.utf8
>en_AU.utf8
>en_CA.utf8
>en_GB.utf8
>en_US.utf8
>en_US.UTF-8
>es_AR.utf8
>es_CL.utf8
>es_CO.utf8
>es_ES.utf8
>es_MX.utf8
>fi_FI.utf8
>fr_BE.utf8
>fr_CA.utf8
>fr_CH.utf8
>fr_FR.utf8
>ga_IE.utf8
>it_IT.utf8
>ja_JP.utf8
>ko_KR.utf8
>nb_NO.utf8
>nl_NL.utf8
>pl_PL.utf8
>POSIX
>pt_PT.utf8
>ro_RO.utf8
>ru_RU.utf8
>sv_SE.utf8
>tr_TR.utf8
>uk_UA.utf8
>vi_VN.utf8
>zh_CN.utf8
>
>
>I'm not sure what to do here. Maybe the use of "setlocale" should be
>guarded against missing locales, but I'm also confused about the 400
>locales part, where's the rest?
>
>(I'm using Guix System 1148890)
>
>
>---
>Luis Felipe López Acevedo
>https://luis-felipe.gitlab.io/
Re: website: Building fails because of missing locales
On Tue, Apr 06, 2021 at 03:59:20PM +, Luis Felipe wrote:
> Hello,
>
> I updated my local copy of guix-artwork repository today and now running
> "haunt build" fails with this message:
>
>
> Backtrace:
> In ice-9/threads.scm:
> 390:8 19 (_ _)
> In ice-9/boot-9.scm:
> 3223:13 18 (_)
> In ice-9/threads.scm:
> 390:8 17 (_ _)
> In ice-9/boot-9.scm:
> 3507:20 16 (_)
>2806:4 15 (save-module-excursion _)
> 3527:26 14 (_)
> In unknown file:
> 13 (primitive-load-path "apps/base/data" #)
> In ice-9/eval.scm:
>626:19 12 (_ #)
>173:55 11 (_ #)
>174:20 10 (_ #)
>177:32 9 (lp (# …))
> 159:9 8 (_ #(# (G_ …) …))
> 159:9 7 (_ #(# (G_ …) …))
> 159:9 6 (_ #(# (G_ …) …))
> 163:9 5 (_ #(# (G_ …) …))
> In srfi/srfi-1.scm:
>586:29 4 (map1 ("de_DE" "en_US" "eo" "es_ES" "fr_FR" "ko_KR" # #))
>586:29 3 (map1 ("en_US" "eo" "es_ES" "fr_FR" "ko_KR" "ru_RU" "…"))
>586:17 2 (map1 ("eo" "es_ES" "fr_FR" "ko_KR" "ru_RU" "zh_CN"))
> In ice-9/eval.scm:
> 619:8 1 (_ #(#(# # …) …))
> In unknown file:
>0 (setlocale 6 "eo.utf8")
>
> ERROR: In procedure setlocale:
> In procedure setlocale: Argumento inválido
>
This happens for me too.
Re: Meta guix: making money with GNU Guix: slightly off topic
On Tue, Apr 06, 2021 at 12:05:00PM -0400, Joshua Branson wrote: > Aloha you lovely people! I personally believe that people should make > business out of free software. Here are some of my business ideas > involving GNU Guix. I invite you all to beat me to market! VPS service that accepts a config.scm and returns a running virtual machine, accessible with a web-based console (SSH, HTTPS and other services would be enabled by the user as desired, in config.scm).
guix home: Call for Early Adopters
Guix Home has most essential features ready and now requires some real-world usage from a few more people to be sure that there are no fundamental issues with it. We are looking for 3-5 advanced GNU/Linux users (not necessary Guix), who want to try `guix home` and are willing to spend some time and effort configuring it, and in case of issues reporting them to https://lists.sr.ht/~abcdw/rde-discuss We will be supporting early adopters in the rde-discuss mailing list on weekdays. Also, you can reach us on #guix IRC channel for a casual talk or quick question, @abcdw and @yoctocell. On `date --date="2021-04-14 15:00:00 UTC"` we plan a jitsi call, to make sure that everyone is up and running, provide some help and/or answer questions. Will schedule consequent calls if needed. To participate you need to have a working installation of Guix the package manager, and have a local checkout of the rde Git repository[1]. Reply to the thread in rde-discuss [2] with a few lines about you and/or your technical background and please attach the output of running `make env-info` at the root of the rde repository to be sure that Guix and rde are installed and everything works correctly. See you soon, Andrew Tropin. Useful links: [1] https://git.sr.ht/~abcdw/rde [2] https://lists.sr.ht/~abcdw/rde-discuss
Re: [PATCH 7/9] build: qemu-command: Add support for powerpc.
Hello, On Tue, Apr 6, 2021 at 2:44 PM Efraim Flashner wrote: > +((string-match "powerpc" cpu) "ppc") Won't there be some "powerpc64le" conflict here ? -- Vincent Legoll
Re: [PATCH 9/9] gnu: nss: Skip tests on powerpc-linux.
Hello, On Tue, Apr 6, 2021 at 2:44 PM Efraim Flashner wrote: > + ;; Tests on powerpc-linux take forever and fail sporatically. s/sporatically/sporadically/ -- Vincent Legoll
Meta guix: making money with GNU Guix: slightly off topic
Aloha you lovely people! I personally believe that people should make business out of free software. Here are some of my business ideas involving GNU Guix. I invite you all to beat me to market! - Become a competitor to jmp.chat. jmp.chat is a free software cell phone service. I use it. They charge $3 per month. Unlimited calling and texting. Not to shabby. Somewhere on their website, they link to a wiki that has all of their source code and the nitty gritty details on how to use their service. Someone could make this a service in GNU Guix and then ANYONE could compete with jmp.chat. - Sell your emacs config. Guix should make it possible for people to download and install a custom emacs. I believe one of the guix developers is currently making a custom emacs for guix usage...can someone link to that for me? You could make a custom channel, that somehow people can only access if they pay for you it. This is free software, BUT people need to pay to use it. "Conversations" (that's how I use jmp.chat) on my Android phone, has this business model. You have to pay to download the software, but it is free software. - Sell free software games. I'm sure guix could help you do this is some way... - If we package sourcehut, people could try to compete with Drew Devault. Though that guy works 80 hours a week. So best of luck competing against him! Thanks! Joshua Apologies if this is off topic. Please let me know if this sort of email does not belong on guix devel!
website: Building fails because of missing locales
Hello,
I updated my local copy of guix-artwork repository today and now running "haunt
build" fails with this message:
Backtrace:
In ice-9/threads.scm:
390:8 19 (_ _)
In ice-9/boot-9.scm:
3223:13 18 (_)
In ice-9/threads.scm:
390:8 17 (_ _)
In ice-9/boot-9.scm:
3507:20 16 (_)
2806:4 15 (save-module-excursion _)
3527:26 14 (_)
In unknown file:
13 (primitive-load-path "apps/base/data" #)
In ice-9/eval.scm:
626:19 12 (_ #)
173:55 11 (_ #)
174:20 10 (_ #)
177:32 9 (lp (# …))
159:9 8 (_ #(# (G_ …) …))
159:9 7 (_ #(# (G_ …) …))
159:9 6 (_ #(# (G_ …) …))
163:9 5 (_ #(# (G_ …) …))
In srfi/srfi-1.scm:
586:29 4 (map1 ("de_DE" "en_US" "eo" "es_ES" "fr_FR" "ko_KR" # #))
586:29 3 (map1 ("en_US" "eo" "es_ES" "fr_FR" "ko_KR" "ru_RU" "…"))
586:17 2 (map1 ("eo" "es_ES" "fr_FR" "ko_KR" "ru_RU" "zh_CN"))
In ice-9/eval.scm:
619:8 1 (_ #(#(# # …) …))
In unknown file:
0 (setlocale 6 "eo.utf8")
ERROR: In procedure setlocale:
In procedure setlocale: Argumento inválido
I see in the commit log that there's a new commit adding Esperanto to the
website translations, but I was surprised to see this error because the website
manifest.scm includes "glibc-locales" and I thought it would provide "eo.utf8"
locale, but, apparently, it doesn't (see "locale -a" output below).
Also, if I understand correctly, the package description for "glibc-locales"
says it provides more than 400 locales, but once installed, I see less than 40:
$ locale -a
C
ca_ES.utf8
cs_CZ.utf8
da_DK.utf8
de_DE.utf8
el_GR.utf8
en_AU.utf8
en_CA.utf8
en_GB.utf8
en_US.utf8
en_US.UTF-8
es_AR.utf8
es_CL.utf8
es_CO.utf8
es_ES.utf8
es_MX.utf8
fi_FI.utf8
fr_BE.utf8
fr_CA.utf8
fr_CH.utf8
fr_FR.utf8
ga_IE.utf8
it_IT.utf8
ja_JP.utf8
ko_KR.utf8
nb_NO.utf8
nl_NL.utf8
pl_PL.utf8
POSIX
pt_PT.utf8
ro_RO.utf8
ru_RU.utf8
sv_SE.utf8
tr_TR.utf8
uk_UA.utf8
vi_VN.utf8
zh_CN.utf8
I'm not sure what to do here. Maybe the use of "setlocale" should be guarded
against missing locales, but I'm also confused about the 400 locales part,
where's the rest?
(I'm using Guix System 1148890)
---
Luis Felipe López Acevedo
https://luis-felipe.gitlab.io/
Re: Please review blog post draft: powerpc64le-linux support
Awesome! Great work! I read the below draft blog post like a Harry Potter novel! It is superbly written. And it makes a lot of sense! Chris Marusich writes: > Hi, > > Léo and I have drafted the following blog post. Could you take a few > minutes to read it and give us your thoughts? > > It's a work in progress. The primary goal is to announce the new > powerpc64le-linux support and explain why it matters (POWER9 is an > exciting, freedom-friendly platform!). The secondary goal is to explain > some of the details about what we did, and invite people to get > involved. > > Your feedback would be highly appreciated! > > -- > Chris Seriously good job on this blog post, and all involved in the powerPC porting work! Fabulous job chaps! Cheerio! Also below are my tiny edits: > + > +### Why Is This Important? > + > +This is important because it means that GNU Guix now works on the [RYF > +Talos II and Talos II Lite > +mainboards](https://www.fsf.org/news/talos-ii-mainboard-and-talos-ii-lite-mainboard-now-fsf-certified-to-respect-your-freedom) > +and it's IBM POWER9 processor. This is a modern, performant hardware I believe you should use "its". it's is short for "it is". > +platform that respects your freedom. It can run without any non-free > +code, all the way down to its bootloader and firmware. It's a > +freedom-friendly platform that aligns well with GNU Guix's commitment > +to software freedom. > + > +How is this any different from existing RYF hardware, you might ask? > +The existing RYF > +[laptops](https://ryf.fsf.org/products?category=1=All_by=created_order=DESC), > +[mainboards](https://ryf.fsf.org/products?category=5=All_by=created_order=DESC), > +and > +[workstations](https://ryf.fsf.org/products?category=30=All_by=created_order=DESC) > +can only really be used with Intel Core Duo or AMD Opteron processors. > +Those processors were released over 15 years ago. Since then, > +processor performance has increased drastically. People should not > +have to choose between performance and freedom, but the fact is that > +for many years, that is exactly what we were forced to do. However, > +the Talos II and Talos II Lite have changed this: the free software > +community now has an RYF-certified option that can compete with the > +performance of modern Intel and AMD systems. > + > +Although the performance of POWER9 processors is competitive with > +modern Intel and AMD processors, its real advantage is that it< Why is there "it<" ? Is that some markup I'm not familiar with? > +respects your freedom. Modern processors from [both Intel and AMD > +include back > +doors](https://www.fsf.org/blogs/sysadmin/the-management-engine-an-attack-on-computer-users-freedom) > +over which you are given no control. Additionally, hardware design > +defects in the processors of both vendors have been discovered, giving > +rise to critical security vulnerabilities like > +[Spectre](https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)) > +and > +[Meltdown](https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)). > +In many cases, these vulnerabilities can only be fixed by installing > +[non-free CPU microcode](https://wiki.debian.org/Microcode) - unless, > +of course, [the vendor decides not to provide any fix at > +all](https://arstechnica.com/gadgets/2018/04/intel-drops-plans-to-develop-spectre-microcode-for-ancient-chips/)! > + > +Compared to that, the RYF Talos II and Talos II Lite are a breath of > +fresh air that the free software community really deserves. Raptor > +Computing Systems' commitment to software freedom and owner control is > +an inspiring reminder that it **is** possible to ship a great product > +that respects the freedom of your customers. And going forward, the > +future looks bright for the open, royalty-free Power ISA, [which is > +now a Linux Foundation > +project](https://www.linuxfoundation.org/press-release/2019/08/the-linux-foundation-announces-new-open-hardware-technologies-and-collaboration/) > +(see also: [the same announcement from The OpenPOWER > +Foundation](https://openpowerfoundation.org/the-next-step-in-the-openpower-foundation-journey/). > + > + > +In Guix, all software for a given system (e.g., powerpc64le-linux) is > +built starting from its bootstrap binaries. It is intended that the > +bootstrap binaries are the only pieces of software in the entire > +package collection that Guix cannot build from source. In practice, > +[additional bootstrap roots are > +possible](https://lists.gnu.org/archive/html/guix-devel/2015-02/msg00814.html), > +but introducing them in Guix is highly discouraged, and our community > +[actively](https://guix.gnu.org/en/blog/2019/guix-reduces-bootstrap-seed-by-50/) > +[works](https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/) > +to [reduce](https://guix.gnu.org/en/blog/2018/bootstrapping-rust/) our > +overall bootstrap footprint. > + > +So first you need to build the the bootstrap
[PATCH 9/9] gnu: nss: Skip tests on powerpc-linux.
* gnu/packages/nss.scm (nss)[arguments]: Skip tests on powerpc-linux. --- gnu/packages/nss.scm | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/gnu/packages/nss.scm b/gnu/packages/nss.scm index e054363e9f..954a1d3b80 100644 --- a/gnu/packages/nss.scm +++ b/gnu/packages/nss.scm @@ -1,7 +1,7 @@ ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2013, 2014, 2015, 2016, 2017, 2018, 2019 Ludovic Courtès ;;; Copyright © 2014, 2015, 2016, 2017, 2018, 2019 Mark H Weaver -;;; Copyright © 2016, 2017, 2018, 2019 Efraim Flashner +;;; Copyright © 2016, 2017, 2018, 2019, 2020 Efraim Flashner ;;; Copyright © 2017, 2018 Tobias Geerinckx-Rice ;;; Copyright © 2020 Marius Bakke ;;; Copyright © 2020 Jonathan Brielmaier @@ -109,7 +109,10 @@ in the Mozilla clients.") ;; Parallel builds are not supported (see: ;; https://bugzilla.mozilla.org/show_bug.cgi?id=1640328). `(#:parallel-build? #f - #:tests? #t ;requires at least one hour to run + ;; Tests on powerpc-linux take forever and fail sporatically. + #:tests? ,(if (string=? "powerpc-linux" (or (%current-system) + (%current-target-system))) + '#f '#t) #:make-flags (let* ((out (assoc-ref %outputs "out")) (nspr (string-append (assoc-ref %build-inputs "nspr"))) -- 2.31.1
[PATCH 7/9] build: qemu-command: Add support for powerpc.
* gnu/build/vm.scm (qemu-command): Add missing case for powerpc. --- gnu/build/vm.scm | 1 + 1 file changed, 1 insertion(+) diff --git a/gnu/build/vm.scm b/gnu/build/vm.scm index 253d9bcd31..a2c2d79bb9 100644 --- a/gnu/build/vm.scm +++ b/gnu/build/vm.scm @@ -75,6 +75,7 @@ (cond ((string-match "^i[3456]86$" cpu) "i386") ((string-match "armhf" cpu) "arm") +((string-match "powerpc" cpu) "ppc") (else cpu) (define* (load-in-linux-vm builder -- 2.31.1
[PATCH 6/9] gnu: american-fuzzy-lop: Add support for powerpc-linux.
* gnu/packages/debug.scm (american-fuzzy-lop): Add case for
powerpc-linux.
(qemu-for-american-fuzzy-lop): Same.
---
gnu/packages/debug.scm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gnu/packages/debug.scm b/gnu/packages/debug.scm
index 2913c348f3..1326ce6e16 100644
--- a/gnu/packages/debug.scm
+++ b/gnu/packages/debug.scm
@@ -179,6 +179,7 @@ tools that process C/C++ code.")
("aarch64-linux" "aarch64")
("armhf-linux""arm")
("mips64el-linux" "mips64el")
+ ("powerpc-linux" "ppc")
;; Prevent errors when querying this package on unsupported
;; platforms, e.g. when running "guix package --search="
(_"UNSUPPORTED"
@@ -254,6 +255,7 @@ down the road.")
("aarch64-linux" "aarch64")
("armhf-linux""arm")
("mips64el-linux" "mips64el")
+ ("powerpc-linux" "ppc")
;; Prevent errors when querying this package on unsupported
;; platforms, e.g. when running "guix package --search="
(_"UNSUPPORTED"
--
2.31.1
[PATCH 5/9] gnu: Add mac-fdisk.
* gnu/packages/disk.scm (mac-fdisk): New variable.
* gnu/packages/patches/mac-fdisk-gentoo-patchset.patch,
gnu/packages/patches/mac-fdisk-p18.patch: New files.
* gnu/local.mk (dist_patch_DATA): Register them.
---
gnu/local.mk |2 +
gnu/packages/disk.scm | 44 +
.../patches/mac-fdisk-gentoo-patchset.patch | 866 +++
gnu/packages/patches/mac-fdisk-p18.patch | 2070 +
4 files changed, 2982 insertions(+)
create mode 100644 gnu/packages/patches/mac-fdisk-gentoo-patchset.patch
create mode 100644 gnu/packages/patches/mac-fdisk-p18.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index ce0a79fb4d..4545cd0a7f 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1374,6 +1374,8 @@ dist_patch_DATA =
\
%D%/packages/patches/luit-posix.patch\
%D%/packages/patches/lvm2-static-link.patch \
%D%/packages/patches/mailutils-fix-uninitialized-variable.patch \
+ %D%/packages/patches/mac-fdisk-gentoo-patchset.patch \
+ %D%/packages/patches/mac-fdisk-p18.patch \
%D%/packages/patches/make-impure-dirs.patch \
%D%/packages/patches/mars-install.patch \
%D%/packages/patches/mars-sfml-2.3.patch \
diff --git a/gnu/packages/disk.scm b/gnu/packages/disk.scm
index ed112f2ec2..ce49f493ea 100644
--- a/gnu/packages/disk.scm
+++ b/gnu/packages/disk.scm
@@ -302,6 +302,50 @@ fdisk. fdisk is used for the creation and manipulation of
disk partition
tables, and it understands a variety of different formats.")
(license license:gpl3+)))
+(define-public mac-fdisk
+ (package
+(name "mac-fdisk")
+(version "0.1")
+(source
+ (origin
+(method url-fetch)
+(uri (string-append "mirror://debian/pool/main/m/mac-fdisk/"
+"mac-fdisk_" version ".orig.tar.gz"))
+(sha256
+ (base32 "0rkaqp82l47pg0ymqys07mljf3widv2yk4hhgs2yz8hwli5zqnbh"))
+(patches (search-patches "mac-fdisk-p18.patch"
+ "mac-fdisk-gentoo-patchset.patch"
+(build-system gnu-build-system)
+(arguments
+ `(#:phases
+ (modify-phases %standard-phases
+ (delete 'configure); no configure script.
+ (replace 'install
+ (lambda* (#:key outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+(sbin (string-append out "/sbin"))
+(man8 (string-append out "/share/man/man8")))
+ (mkdir-p sbin)
+ (mkdir-p man8)
+ (copy-file "fdisk" (string-append sbin "/mac-fdisk"))
+ (copy-file "pdisk" (string-append sbin "/pmac-fdisk"))
+ (copy-file "mac-fdisk.8.in" (string-append man8 "/mac-fdisk.8"))
+ (copy-file "pmac-fdisk.8.in" (string-append man8
"/pmac-fdisk.8"))
+ #t
+ #:make-flags (list "CC=gcc")
+ #:tests? #f)); no tests
+(home-page "https://tracker.debian.org/pkg/mac-fdisk;)
+(synopsis "Apple disk partition manipulation tool")
+(description "The @code{fdisk} utilities from the MkLinux project, adopted
+for Linux/m68k. @code{mac-fdisk} allows you to create and edit the partition
+table of a disk. It supports only the Apple partition format used on Macintosh
+and PowerMac, use @code{pmac-fdisk} for PC partition format disks as used on
+PowerPC machines. @code{mac-fdisk} is an interactive tool with a menu similar
+to PC @code{fdisk}, supported options are somewhat different from PC
+@code{fdisk} due to the differences in partition format.")
+(supported-systems '("powerpc-linux" "i686-linux" "x86_64-linux"))
+(license license:gpl2)))
+
(define-public gptfdisk
(package
(name "gptfdisk")
diff --git a/gnu/packages/patches/mac-fdisk-gentoo-patchset.patch
b/gnu/packages/patches/mac-fdisk-gentoo-patchset.patch
new file mode 100644
index 00..b1bd38f671
--- /dev/null
+++ b/gnu/packages/patches/mac-fdisk-gentoo-patchset.patch
@@ -0,0 +1,866 @@
+https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/mac-fdisk/files
+
+---
+ bitfield.c | 16 +-
+ bitfield.h | 4 +--
+ dump.c | 42 --
+ errors.c| 11 ---
+ fdisk.c | 68 ++
+ fdisk.h | 5
+ fdisklabel.c| 79 +++--
+ fdisklabel.h| 2 +-
+ io.c| 8 +++--
+ kernel-defs.h | 6
+ partition_map.c | 43 ---
+ pdisk.c | 7 ++---
+ 12 files changed, 186 insertions(+), 105 deletions(-)
+
+diff --git a/bitfield.c b/bitfield.c
+index 687e8bd..02e7f68 100644
+--- a/bitfield.c
b/bitfield.c
+@@ -67,13 +67,12 @@ const unsigned long masks[] = {
+ //
+ // Routines
+ //
+-unsigned long
[PATCH 1/9] gnu: bootstrap: Add support for powerpc-linux.
On 923bb70a1bff657125c3008f119a477e5cb57c2b
gnu:glibc-for-bootstrap: Fix patch.
Run
./pre-inst-env guix build --target=powerpc-linux-gnu bootstrap-tarballs
Producing
/gnu/store/dyj1wvayyp1ihaknkxniz1xamcf4yrhl-bootstrap-tarballs-0
With guix hash -rx
/gnu/store/dyj1wvayyp1ihaknkxniz1xamcf4yrhl-bootstrap-tarballs-0
02xx2ydj28pwv3vflqffinpq1icj09gzi9icm8j4bwc4lca9irxn
* gnu/packages/bootstrap.scm (%bootstrap-executables): Add entries for
powerpc-linux.
(%bootstrap-guile-hash, %bootstrap-coreutils, %bootstrap-binutils,
%bootstrap-glibc, %bootstrap-gcc): Add entry for powerpc-linux.
* gnu/packages.scm (%supported-systems): Add powerpc-linux.
(%hydra-supported-systems): Remove powerpc-linux.
* m4/guix.m4: Add powerpc-linux as a supported system.
---
gnu/packages/bootstrap.scm | 37 -
guix/packages.scm | 4 ++--
m4/guix.m4 | 4 ++--
3 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/gnu/packages/bootstrap.scm b/gnu/packages/bootstrap.scm
index c50e94e891..049735013a 100644
--- a/gnu/packages/bootstrap.scm
+++ b/gnu/packages/bootstrap.scm
@@ -89,6 +89,15 @@
,(base32 "1j51gv08sfg277yxj73xd564wjq3f8xwd6s9rbcg8v9gms47m4cx"))
("xz"
,(base32 "1d779rwsrasphg5g3r37qppcqy3p7ay1jb1y83w7x4i3qsc7zjy2")))
+("powerpc-linux"
+ ("bash"
+ ,(base32 "0hwlw5lcyjzadprf5fm0cv4zb6jw667g9amnmhq0lbixasy7j72j"))
+ ("mkdir"
+ ,(base32 "12lfwh5p8pp06250wgi9mdvjv1jdfpd5xpmvfc0616aj0xqh09hp"))
+ ("tar"
+ ,(base32 "00sbmwl8qh6alxv9mw4hvj1j4yipwmw5mrw6qad8bi2pr7ya5386"))
+ ("xz"
+ ,(base32 "0hi47y6zh5zz137i59l5ibw92x6g54zn7ris1b1ym9rvavsasg7b")))
("armhf-linux"
("bash"
,(base32 "0s6f1s26g4dsrrkl39zblvwpxmbzi6n9mgqf6vxsqz42gik6bgyn"))
@@ -139,6 +148,7 @@
;; This is where the bootstrap executables come from.
'("https://git.savannah.gnu.org/cgit/guix.git/plain/gnu/packages/bootstrap/;
"https://alpha.gnu.org/gnu/guix/bootstrap/;
+"http://flashner.co.il/guix/bootstrap/;
"http://lilypond.org/janneke/guix/;))
(define (bootstrap-executable-file-name system program)
@@ -146,6 +156,7 @@
(match system
("powerpc64le-linux" (string-append system "/20210106/" program))
("i586-gnu" (string-append system "/20200326/" program))
+("powerpc-linux" (string-append system "/20200923/bin/" program))
(_ (string-append system "/" program
"?id=44f07d1dc6806e97c4e9ee3e6be883cc59dc666e"
@@ -341,6 +352,8 @@ or false to signal an error."
(match system
("aarch64-linux"
"/20170217/guile-2.0.14.tar.xz")
+ ("powerpc-linux"
+"/20200923/guile-2.0.14.tar.xz")
("armhf-linux"
"/20150101/guile-2.0.11.tar.xz")
("i586-gnu"
@@ -366,7 +379,9 @@ or false to signal an error."
("aarch64-linux"
(base32 "1giy2aprjmn5fp9c4s9r125fljw4wv6ixy5739i5bffw4jgr0f9r"))
("i586-gnu"
- (base32 "0wgqpsmvg25rnqn49ap7kwd2qxccd8dr4lllzp7i3rjvgav27vac"
+ (base32 "0wgqpsmvg25rnqn49ap7kwd2qxccd8dr4lllzp7i3rjvgav27vac"))
+("powerpc-linux"
+ (base32 "1by2p7s27fbyjzfkcw8h65h4kkqh7d23kv4sgg5jppjn2qx7swq4"
(define (bootstrap-guile-origin system)
"Return an object for the Guile tarball of SYSTEM."
@@ -500,6 +515,8 @@ $out/bin/guile --version~%"
"/20210106/static-binaries-0-powerpc64le-linux-gnu.tar.xz")
("i586-gnu"
"/20200326/static-binaries-0-i586-pc-gnu.tar.xz")
+("powerpc-linux"
+
"/20200923/static-binaries.tar.xz")
(_
"/20131110/static-binaries.tar.xz")))
%bootstrap-base-urls))
@@ -523,6 +540,9 @@ $out/bin/guile --version~%"
("i586-gnu"
(base32
"17kllqnf3fg79gzy9ansgi801c46yh9c23h4d923plvb0nfm1cfn"))
+ ("powerpc-linux"
+ (base32
+
"0kspxy0yczan2vlih6aa9hailr2inz000fqa0gn5x9d1fxxa5y8m"))
("mips64el-linux"
(base32
"072y4wyfsj1bs80r6vbybbafy8ya4vfy7qj25dklwk97m6g71753"))
@@ -573,6 +593,8 @@ $out/bin/guile --version~%"
"/20210106/binutils-static-stripped-2.34-powerpc64le-linux-gnu.tar.xz")
("i586-gnu"
"/20200326/binutils-static-stripped-2.34-i586-pc-gnu.tar.xz")
+
[PATCH 3/9] gnu: binutils: Adjust test suite on powerpc-linux.
* gnu/packages/base.scm (binutils)[arguments]: Add phase on
powerpc-linux to adjust the test suite.
* gnu/packages/commencement.scm (binutils-boot0)[arguments]: Move custom
phases after inherited arguments. Add phase on powerpc-linux to adjust
the test suite.
---
gnu/packages/base.scm | 11 ++-
gnu/packages/commencement.scm | 21 -
2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index dbb7c619fe..b9fc0a6e29 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -531,7 +531,16 @@ change. GNU make offers many powerful extensions over the
standard utility.")
;; Make sure 'ar' and 'ranlib' produce archives in a
;; deterministic fashion.
- "--enable-deterministic-archives")))
+ "--enable-deterministic-archives")
+ ,@(if (string=? (%current-system) "powerpc-linux")
+ `(#:phases
+(modify-phases %standard-phases
+ (add-after 'unpack 'disable-rust-libiberty-test
+(lambda _
+ (substitute* "libiberty/testsuite/Makefile.in"
+((" check-rust-demangle ") ""))
+ #t
+ '(
(synopsis "Binary utilities: bfd gas gprof ld")
(description
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index 7c39a84008..f707a01d30 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -2653,7 +2653,22 @@ exec " gcc "/bin/" program
#:modules ((guix build gnu-build-system)
(guix build utils)
(ice-9 ftw)); for 'scandir'
+
+ ;; #:phases gets modified for powerpc-linux in binutils,
+ ;; so #:phases here needs to be after the inherited one.
+ ,@(substitute-keyword-arguments (package-arguments binutils)
+ ((#:configure-flags cf)
+`(cons ,(string-append "--target=" (boot-triplet))
+ ,cf)))
+
#:phases (modify-phases %standard-phases
+ ,@(if (string=? (%current-system) "powerpc-linux")
+ '((add-after 'unpack 'disable-rust-libiberty-test
+ (lambda _
+(substitute* "libiberty/testsuite/Makefile.in"
+ ((" check-rust-demangle ") ""))
+#t)))
+ '())
(add-after 'install 'add-symlinks
(lambda* (#:key outputs #:allow-other-keys)
;; The cross-gcc invokes 'as', 'ld', etc, without the
@@ -2667,12 +2682,8 @@ exec " gcc "/bin/" program
(with-directory-excursion (string-append out "/bin")
(for-each (lambda (name)
(symlink name (remove-triplet-prefix
name)))
-(scandir "." has-triplet-prefix?)))
+(scandir "." has-triplet-prefix?)
- ,@(substitute-keyword-arguments (package-arguments binutils)
- ((#:configure-flags cf)
-`(cons ,(string-append "--target=" (boot-triplet))
- ,cf)
(inputs (%boot0-inputs
(define libstdc++-boot0
--
2.31.1
[PATCH 2/9] gnu: guile-3.0: Fix building on powerpc-linux.
* gnu/packages/guile.scm (guile-3.0)[arguments]: On powerpc add two
phases to adjust for 32-bit big-endian systems.
---
gnu/packages/guile.scm | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index f63322794d..dca1b1c16f 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -305,7 +305,26 @@ without requiring the source code to be rewritten.")
(substitute-keyword-arguments (package-arguments guile-2.2)
((#:configure-flags flags ''())
`(cons "--disable-jit" ,flags)))
- (package-arguments guile-2.2)))
+ (if (string-prefix? "powerpc-" (%current-system))
+ (substitute-keyword-arguments (package-arguments guile-2.2)
+ ((#:phases phases)
+ `(modify-phases ,phases
+ (add-after 'unpack 'adjust-bootstrap-flags
+ (lambda _
+ ;; Upstream not yet notified about suggested solution.
+ ;; See existing bug reports:
+ ;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45214
+ ;;
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977223
+ (substitute* "bootstrap/Makefile.in"
+ (("^GUILE_OPTIMIZATIONS.*")
+"GUILE_OPTIMIZATIONS = -O1 -Oresolve-primitives
-Ocps\n"))
+ #t))
+ (add-after 'unpack 'remove-failing-tests
+ (lambda _
+ ;; TODO: Discover why this test fails on powerpc-linux
+ (delete-file "test-suite/standalone/test-out-of-memory")
+ #t)
+ (package-arguments guile-2.2
(native-search-paths
(list (search-path-specification
(variable "GUILE_LOAD_PATH")
--
2.31.1
[PATCH 8/9] gnu: mercurial: Skip tests on powerpc-linux.
* gnu/packages/version-control.scm (mercurial)[arguments]: Skip tests on
powerpc-linux.
---
gnu/packages/version-control.scm | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index 4d4b276a10..13e2ccd400 100644
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -1688,7 +1688,11 @@ execution of any hook written in any language before
every commit.")
"--slowtimeout" "86400"
;; The test suite takes a long time and produces
little
;; output by default. Prevent timeouts due to
silence.
- "-v"
+ "-v"))
+ ;; Tests on powerpc-linux take more than 10 hours.
+ #:tests? ,(if (string=? "powerpc-linux" (or (%current-system)
+ (%current-target-system)))
+ '#f '#t)))
;; The following inputs are only needed to run the tests.
(native-inputs
`(("python-nose" ,python-nose)
--
2.31.1
[PATCH 4/9] gnu: mesa: Add support for powerpc-linux.
* gnu/packages/gl.scm (mesa)[inputs]: Add llvm, glslang for powerpc.
[arguments]: Customize the configure flags for powerpc. Skip tests on
powerpc.
---
gnu/packages/gl.scm | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
index ee29a79366..3b6a829031 100644
--- a/gnu/packages/gl.scm
+++ b/gnu/packages/gl.scm
@@ -271,7 +271,7 @@ also known as DXTn or DXTC) for Mesa.")
("libxrandr" ,libxrandr)
("libxvmc" ,libxvmc)
,@(match (%current-system)
-((or "x86_64-linux" "i686-linux")
+((or "x86_64-linux" "i686-linux" "powerpc-linux")
;; Note: update the 'clang' input of mesa-opencl when bumping
this.
`(("llvm" ,llvm-11)))
(_
@@ -283,7 +283,7 @@ also known as DXTn or DXTC) for Mesa.")
("flex" ,flex)
("gettext" ,gettext-minimal)
,@(match (%current-system)
-((or "x86_64-linux" "i686-linux")
+((or "x86_64-linux" "i686-linux" "powerpc-linux")
`(("glslang" ,glslang)))
(_
`()))
@@ -298,6 +298,8 @@ also known as DXTn or DXTC) for Mesa.")
((or "armhf-linux" "aarch64-linux")
;; TODO: Fix svga driver for aarch64 and armhf.
'("-Dgallium-drivers=etnaviv,freedreno,kmsro,lima,nouveau,panfrost,r300,r600,swrast,tegra,v3d,vc4,virgl"))
+ ("powerpc-linux"
+ '("-Dgallium-drivers=nouveau,r300,r600,radeonsi,swrast,virgl"))
(_
'("-Dgallium-drivers=iris,nouveau,r300,r600,radeonsi,svga,swrast,virgl")))
;; Enable various optional features. TODO: opencl requires libclc,
@@ -318,12 +320,14 @@ also known as DXTn or DXTC) for Mesa.")
,@(match (%current-system)
((or "i686-linux" "x86_64-linux")
'("-Dvulkan-drivers=intel,amd"))
+ ("powerpc-linux" ; No default on this platform.
+ '("-Dvulkan-drivers=amd"))
(_
'("-Dvulkan-drivers=auto")))
;; Enable the Vulkan overlay layer on i686-linux and x86-64-linux.
,@(match (%current-system)
- ((or "x86_64-linux" "i686-linux")
+ ((or "x86_64-linux" "i686-linux" "powerpc-linux")
'("-Dvulkan-overlay-layer=true"))
(_
'()))
@@ -337,6 +341,9 @@ also known as DXTn or DXTC) for Mesa.")
((or "x86_64-linux" "i686-linux")
'("-Ddri-drivers=i915,i965,nouveau,r200,r100"
"-Dllvm=enabled")) ; default is x86/x86_64 only
+ ("powerpc-linux"
+ '("-Ddri-drivers=nouveau,r200,r100"
+"-Dllvm=enabled"))
(_
'("-Ddri-drivers=nouveau,r200,r100"
@@ -344,6 +351,11 @@ also known as DXTn or DXTC) for Mesa.")
;; documentation recommends using 'release' for performance anyway.
#:build-type "release"
+ ;; The llvm-based tests are flakey on non-Intel hardware.
+ #:tests? ,(if (string=? "powerpc-linux" (or (%current-system)
+ (%current-target-system)))
+ '#f '#t)
+
#:modules ((ice-9 match)
(srfi srfi-1)
(guix build utils)
--
2.31.1
[PATCH 0/9] Add 32-bit powerpc support
https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-ppc The wip-ppc branch on Savannah is currently in a good state. With the recent rapid churn on core-updates I haven't been very quick about rebasing on core-updates but I can confirm that building out to mesa works. Building is slow, it took 6 days to build from guile-final to mesa without stopping. The patches start with adding the bootstrap binaries for powerpc. The next patch fixes guile-3.0.2+ on powerpc (and probably other 32-bit big-endian systems) and is the result of almost 3 weeks of bisecting. Next is a patch for binutils to disable one of the tests. The test is new to core-updates, and fails on powerpc-linux but not the other architectures we support. The mesa patch works, but I have to see about enabling the tests. I have also tested updating mesa and enabling the llvm backend on aarch64 and the tests no longer fail there, so I'll do another couple (3 hour) mesa builds to see if the comment needs adjusting or if the tests can be enabled on powerpc-linux. mac-fdisk I didn't have a solid reason to put in the wip-ppc branch but there it is. I need to change CC=gcc to use cc-for-target. The patch for american-fuzzy-lop I snuck into master the qemu-command in gnu/build/vm shouldn't overlap with ppc64le. the last two patches, disabling the tests for mercurial and nss, can probably be dropped. The comments are accurate though, and we have done similar in the past on mips64le and armhf. Efraim Flashner (9): gnu: bootstrap: Add support for powerpc-linux. gnu: guile-3.0: Fix building on powerpc-linux. gnu: binutils: Adjust test suite on powerpc-linux. gnu: mesa: Add support for powerpc-linux. gnu: Add mac-fdisk. gnu: american-fuzzy-lop: Add support for powerpc-linux. build: qemu-command: Add support for powerpc. gnu: mercurial: Skip tests on powerpc-linux. gnu: nss: Skip tests on powerpc-linux. gnu/build/vm.scm |1 + gnu/local.mk |2 + gnu/packages/base.scm | 11 +- gnu/packages/bootstrap.scm| 37 +- gnu/packages/commencement.scm | 21 +- gnu/packages/debug.scm|2 + gnu/packages/disk.scm | 44 + gnu/packages/gl.scm | 18 +- gnu/packages/guile.scm| 21 +- gnu/packages/nss.scm |7 +- .../patches/mac-fdisk-gentoo-patchset.patch | 866 +++ gnu/packages/patches/mac-fdisk-p18.patch | 2070 + gnu/packages/version-control.scm |6 +- guix/packages.scm |4 +- m4/guix.m4|4 +- 15 files changed, 3096 insertions(+), 18 deletions(-) create mode 100644 gnu/packages/patches/mac-fdisk-gentoo-patchset.patch create mode 100644 gnu/packages/patches/mac-fdisk-p18.patch base-commit: f08b070019a3c1697bb0b4a783dcd4f31243715a -- 2.31.1
Re: A new wip-emacs branch
Hello Guix, this is a small progress report on wip-emacs. Emacs now gets its core lisp path from the wrapper rather than the search path and there's a new profile hook adding all top-level subdirectories to a subdirs.el, that gets loaded at startup. Emacs' build system has been rewritten to use ELPA-style subdirectories. Packages, that cause build failures in themselves or others by not adhering to this practice, have been adjusted. I have attached a manifest, that builds all packages from emacs-xyz known not to fail on master. If some Emacs-related package is not covered by this manifest, but still breaks, please do report it while those patches still live on wip-emacs, so that they can be fixed in time. There are still some packages, that use the old convention, e.g. emacs- geiser. While those can be fixed as well, it is a low priority. In terms of UX it would also be nice to tackle the issue of coreutils and gzip being required to have core functionality. I'm not sure, whether patching Elisp files is the correct solution here, since Emacs could (via tramp) connect to other machines, where those store paths don't exist and it's not clear (to me) on which machine those commands are executed. Extending PATH in the same wrapper as EMACSLOADPATH seems to be a fairly cheap option, however. Regards, Leo (use-modules (gnu)) (use-package-modules emacs) (packages->manifest (cons emacs (filter identity (hash-map->list (lambda (k v) (and (not (member k ;; blacklist packages, that don't build on master '(emacs-el-patch emacs-org-generate emacs-md4rd emacs-picpocket))) (variable-ref v))) (module-obarray (resolve-interface '(gnu packages emacs-xyz)))
Re: Semi-automated patch review
Léo Le Bouter writes: > Cbaines already runs automated patch testing infra at > https://data.guix-patches.cbaines.net/ and > https://patches.guix-patches.cbaines.net/project/guix-patches/list/ > > Considering that posting robot messages with test/lint/+ result > information on the issues directly and on the ML might get spammy, I > suggest that Cbaines could setup something that sends off-list to all > the participants or just the poster of the patch being tested, as well > as another list like guix-ci-...@cbaines.net that reviewers could > voluntarily subscribe to to receive all those off-list messages. > > Another suggestion is that the infrastructure by Cbaines could include > an easy way to lookup CI information from a bug id and that a link to > see such CI information could be linked to from Mumi's > (issues.gnu.guix.org) UI. But I also really think that mailing the > contributors privately is very important so they can get automated > feedback and save us time without any additional setup or knowledge > required. > > What do you think? So a technical component that I have in mind for this is supporting subscriptions to data in the Guix Data Service, and that's something that I'm hoping to at least start implementing in the coming weeks. Once that's a possibility for the data relevant to patch series, I think it will be feasible to look at having more useful "checks" in Patchwork (e.g. broken builds, new lint warnings, ...) and perhaps sending emails to the bug to set out that information. There's also other related work still going on, I'm hoping to merge the Laminar package and service soon [1] which I'm currently using for this patch testing setup, and the upcoming Outreachy project on improving the Guix Data Service performance will greatly benefit using the Guix Data Service for patch review. 1: https://issues.guix.gnu.org/47392 Thanks, Chris signature.asc Description: PGP signature
Re: rust-tempfile-3 update to 3.2.0 breaks sequoia build
Am 04.04.21 um 11:08 schrieb Nicolas Goaziou: > Not really. Is it possible to upgrade it to a more recent commit? I see > that Cargo.lock references tempfile 3.2.0 in HEAD. The issue is not in tempfile, it's just caused by this update. Thus I'm not confident updating sequoia to a more recent version will fix the issue. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Please review blog post draft: powerpc64le-linux support
Hi, Léo and I have drafted the following blog post. Could you take a few minutes to read it and give us your thoughts? It's a work in progress. The primary goal is to announce the new powerpc64le-linux support and explain why it matters (POWER9 is an exciting, freedom-friendly platform!). The secondary goal is to explain some of the details about what we did, and invite people to get involved. Your feedback would be highly appreciated! -- Chris From 8900d918106f6a70b20df461c5f086b5275773cc Mon Sep 17 00:00:00 2001 From: Chris Marusich Date: Tue, 6 Apr 2021 00:10:35 -0700 Subject: [PATCH] website: drafts: Add powerpc64le-linux announcement. * website/drafts/new-system-powerpc64le-linux.md: New file. --- .../drafts/new-system-powerpc64le-linux.md| 326 ++ 1 file changed, 326 insertions(+) create mode 100644 website/drafts/new-system-powerpc64le-linux.md diff --git a/website/drafts/new-system-powerpc64le-linux.md b/website/drafts/new-system-powerpc64le-linux.md new file mode 100644 index 000..e3de5ba --- /dev/null +++ b/website/drafts/new-system-powerpc64le-linux.md @@ -0,0 +1,326 @@ +title: powerpc64le-linux support in GNU Guix +date: 2021-03-26 00:00 +author: Chris Marusich and Léo Le Bouter +tags: porting, powerpc64le +--- + +It is a pleasure to announce that support for powerpc64le-linux +(PowerISA v.2.07 and later) has now been +[merged](https://issues.guix.gnu.org/47182) to the master branch of +GNU Guix! + +This means that GNU Guix can be used immediately on this platform from +a [from a Git +checkout](https://guix.gnu.org/manual/en/html_node/Building-from-Git.html). +Starting with the next release (Guix v1.2.1), you will also be able to +[download a copy of Guix pre-built for +powerpc64le-linux](https://guix.gnu.org/manual/en/guix.html#Binary-Installation). +Regardless of how you get it, you can run the new powerpc64le-linux +port of GNU Guix on top of any existing powerpc64le GNU/Linux +distribution. + +This new platform is available as a "technology preview". This means +that although it is supported, substitutes are not yet available from +the build farm, and some packages may fail to build. Although +powerpc64le-linux support is nascent, the Guix community is actively +working on improving it, and this is a great time to [get +involved](https://guix.gnu.org/manual/en/html_node/Contributing.html)! + +### Why Is This Important? + +This is important because it means that GNU Guix now works on the [RYF +Talos II and Talos II Lite +mainboards](https://www.fsf.org/news/talos-ii-mainboard-and-talos-ii-lite-mainboard-now-fsf-certified-to-respect-your-freedom) +and it's IBM POWER9 processor. This is a modern, performant hardware +platform that respects your freedom. It can run without any non-free +code, all the way down to its bootloader and firmware. It's a +freedom-friendly platform that aligns well with GNU Guix's commitment +to software freedom. + +How is this any different from existing RYF hardware, you might ask? +The existing RYF +[laptops](https://ryf.fsf.org/products?category=1=All_by=created_order=DESC), +[mainboards](https://ryf.fsf.org/products?category=5=All_by=created_order=DESC), +and +[workstations](https://ryf.fsf.org/products?category=30=All_by=created_order=DESC) +can only really be used with Intel Core Duo or AMD Opteron processors. +Those processors were released over 15 years ago. Since then, +processor performance has increased drastically. People should not +have to choose between performance and freedom, but the fact is that +for many years, that is exactly what we were forced to do. However, +the Talos II and Talos II Lite have changed this: the free software +community now has an RYF-certified option that can compete with the +performance of modern Intel and AMD systems. + +Although the performance of POWER9 processors is competitive with +modern Intel and AMD processors, its real advantage is that it< +respects your freedom. Modern processors from [both Intel and AMD +include back +doors](https://www.fsf.org/blogs/sysadmin/the-management-engine-an-attack-on-computer-users-freedom) +over which you are given no control. Additionally, hardware design +defects in the processors of both vendors have been discovered, giving +rise to critical security vulnerabilities like +[Spectre](https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)) +and +[Meltdown](https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)). +In many cases, these vulnerabilities can only be fixed by installing +[non-free CPU microcode](https://wiki.debian.org/Microcode) - unless, +of course, [the vendor decides not to provide any fix at +all](https://arstechnica.com/gadgets/2018/04/intel-drops-plans-to-develop-spectre-microcode-for-ancient-chips/)! + +Compared to that, the RYF Talos II and Talos II Lite are a breath of +fresh air that the free software community really deserves. Raptor +Computing Systems' commitment to software freedom and owner
