Re: [PATCH 0/9] Add 32-bit powerpc support
On Sat, Apr 17, 2021 at 06:04:02PM +0200, Ludovic Courtès wrote: > Hi! > > I haven’t looked into details so I’ll just share thoughts from a > maintenance viewpoint: > > 1. Those fdisk patch file names will make ‘guix lint’ unhappy. :-) I'll make sure to touch them up. I was also not happy about the supported-architectures field of the package, I took that from Debain (or was it Gentoo?) but I'm not sure of a technical reason why it can't be built from other architectures. > 2. Apart from mac-fdisk-p18.patch, which looks relatively big, the > changes seem to be rather non-intrusive, so it’s tempting to merge > them (on ‘core-updates’ I guess?). Before I found some of the patches I played around with fixing the package. Without looking at the patches too closely some of them fix warnings and some of them actually make it compile correctly. > 3. OTOH, what will be the status of this architecture? I don’t think > new 32-bit PPC hardware is being made (right?), so I guess we > probably won’t have substitutes for that architecture. That means > it won’t be supported at the same level as other architectures and > may quickly suffer from bitrot. I don't know about new 32-bit powerpc hardware, I think it's only being newly created for the embedded and networking space. As far as operating systems with support¹ Adélie Linux is the only one I know that's actually targeting the machines. I found that emulation on my desktop (Ryzen 3900XT, 24 threads) is faster than building on native hardware (1 core, 1.5GB of RAM, original 4200 RPM disk), edging it out on single threaded compiling and doing great when it comes to using multiple cores and parallel builds. Ignoring how to create an OS image if we just targeted, say, mesa and maybe one or two other packages, we could have a core set which doesn't change regularly and won't take up too much emulated build time but will save days of compile time. > I’m torn between #2 and #3. > > What do people think? The fear of bit-rot is real and I think we should mention in the manual (when I actually write the section) that support is best-effort with minimal substitutes. > Thanks, > Ludo’. ¹ https://en.wikipedia.org/wiki/PowerPC#Operating_systems_with_native_support -- 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: bug#47615: [PATCH 0/9] Add 32-bit powerpc support
On Sat, Apr 17, 2021 at 12:51:01PM -0700, Chris Marusich wrote:
> Efraim Flashner writes:
>
> > * 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.
>
> Nits: adjust the test suite to do what? The message would be clearer if
> it explained the purpose of the adjustment. You could also name the
> phases you added/moved, for extra clarity, if you want to.
>
> > 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
> > + '(
>
> What's the problem? Presumably the test fails; a comment here could
> clarify that.
>
> If it's a test failure, has the issue been reported upstream?
I'll check to see if I can find something upstream. If not I'll report
it. FWIW Debian disables the test suite for powerpc.
https://sources.debian.org/src/binutils/2.36.1-6/debian/rules/#L537
> > (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
>
> I think you can p
[PATCH v2 01/12] gnu: bootstrap: Add support for powerpc-linux.
2inz000fqa0gn5x9d1fxxa5y8m"))
("mips64el-linux"
(base32
"072y4wyfsj1bs80r6vbybbafy8ya4vfy7qj25dklwk97m6g71753"))
@@ -574,6 +594,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")
+("powerpc-linux"
+
"/20200923/binutils-2.35.1.tar.xz")
(_
"/20131110/binutils-2.23.2.tar.xz")))
%bootstrap-base-urls))
@@ -597,6 +619,9 @@ $out/bin/guile --version~%"
("i586-gnu"
(base32
"11kykv1kmqc5wln57rs4klaqa13hm952smkc57qcsyss21kfjprs"))
+ ("powerpc-linux"
+ (base32
+
"0asbg1c4avkrvh057mx0942xwddd136jni382zqsxzn79ls42yq8"))
("mips64el-linux"
(base32
"1x8kkhcxmfyzg1ddpz2pxs6fbdl6412r7x0nzbmi5n7mj8zw2gy7"))
@@ -654,6 +679,8 @@ $out/bin/guile --version~%"
"/20210106/glibc-stripped-2.31-powerpc64le-linux-gnu.tar.xz")
("i586-gnu"
"/20200326/glibc-stripped-2.31-i586-pc-gnu.tar.xz")
+ ("powerpc-linux"
+ "/20200923/glibc-2.32.tar.xz")
(_
"/20131110/glibc-2.18.tar.xz")))
%bootstrap-base-urls))
@@ -677,6 +704,9 @@ $out/bin/guile --version~%"
("i586-gnu"
(base32
"14ddm10lpbas8bankmn5bcrlqvz1v5dnn1qjzxb19r57vd2w5952"))
+("powerpc-linux"
+ (base32
+
"0smmssyjrlk5cvx49586smmk81gkwff0i6r91n4rir4jm6ba25sb"))
("mips64el-linux"
(base32
"0k97a3whzx3apsi9n2cbsrr79ad6lh00klxph9hw4fqyp1abkdsg")
@@ -750,6 +780,8 @@ exec ~a/bin/.gcc-wrapped -B~a/lib \
"/20210106/gcc-stripped-5.5.0-powerpc64le-linux-gnu.tar.xz")
("i586-gnu"
"/20200326/gcc-stripped-5.5.0-i586-pc-gnu.tar.xz")
+ ("powerpc-linux"
+"/20200923/gcc-5.5.0.tar.xz")
(_
"/20131110/gcc-4.8.2.tar.xz")))
%bootstrap-base-urls))
@@ -773,6 +805,9 @@ exec ~a/bin/.gcc-wrapped -B~a/lib \
("i586-gnu"
(base32
"1j2zc58wzil71a34h7c70sd68dmqvcscrw3rmn2whq79vd70zvv5"))
+ ("powerpc-linux"
+ (base32
+
"1p7df3yixhm87dw5sccc6yn1i9db1r9hnmsg87wq5xi4rfmirq7w"))
("mips64el-linux"
(base32
"1m5miqkyng45l745n0sfafdpjkqv9225xf44jqkygwsipj2cv9ks")
diff --git a/guix/packages.scm b/guix/packages.scm
index 61238a8118..e1ddabac53 100644
--- a/guix/packages.scm
+++ b/guix/packages.scm
@@ -353,7 +353,7 @@ name of its URI."
;; This is the list of system types that are supported. By default, we
;; expect all packages to build successfully here.
'("x86_64-linux" "i686-linux" "armhf-linux" "aarch64-linux" "mips64el-linux"
"i586-gnu"
-"powerpc64le-linux"))
+"powerpc64le-linux" "powerpc-linux"))
(define %hurd-systems
;; The GNU/Hurd systems for which support is being developed.
@@ -364,7 +364,7 @@ name of its URI."
;;
;; XXX: MIPS is unavailable in CI:
;; <https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00790.html>.
- (fold delete %supported-systems '("mips64el-linux")))
+ (fold delete %supported-systems '("mips64el-linux" "powerpc-linux")))
;; A package.
diff --git a/m4/guix.m4 b/m4/guix.m4
index 05d409a674..e778a56004 100644
--- a/m4/guix.m4
+++ b/m4/guix.m4
@@ -1,7 +1,7 @@
dnl GNU Guix --- Functional package management for GNU
dnl Copyright © 2012, 2013, 2014, 2015, 2016, 2018, 2019, 2020, 2021 Ludovic
Courtès
dnl Copyright © 2014 Mark H Weaver
-dnl Copyright © 2017 Efraim Flashner
+dnl Copyright © 2017, 2020 Efraim Flashner
dnl Copyright © 2021 Chris Marusich
dnl
dnl This file is part of GNU Guix.
@@ -89,7 +89,7 @@ courageous and port the GNU System distribution to it (see
# Currently only Linux-based systems are supported, and only on some
# platforms.
case "$guix_system" in
-x86_64-linux|i686-linux|armhf-linux|aarch64-linux|powerpc64le-linux)
+
x86_64-linux|i686-linux|armhf-linux|aarch64-linux|powerpc64le-linux|powerpc-linux)
;;
*)
if test "x$guix_courageous" = "xyes"; then
--
2.31.1
[PATCH v2 00/12] Add 32-bit powerpc support
This looks to be about 2 weeks worth of time since the last email, with about 10 days of continuous building and is based on commit 76fc36d0a7215979bb74c05840f5a4de4ab5ea93 which changes the default gcc to 8. I'll inline my comments in the top of each of the patches. Some of the patches are going straight to core-updates but I've included them anyway since the patchset is available in the official repo in the wip-ppc branch and that's where I developed them. Efraim Flashner (12): gnu: bootstrap: Add support for powerpc-linux. gnu: guile-3.0: Fix building on powerpc-linux. gnu: gcc-boot0: Use 128-bit long-double on powerpc-linux. gnu: binutils: Fix bug in test suite in libiberty. 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: zstd: Adjust test suite for 32-bit architectures. gnu: glib: Disable failing test. gnu/build/vm.scm |1 + gnu/local.mk |4 + gnu/packages/base.scm |3 +- gnu/packages/bootstrap.scm| 37 +- gnu/packages/commencement.scm | 12 +- gnu/packages/compression.scm |4 +- gnu/packages/debug.scm|2 + gnu/packages/disk.scm | 43 + gnu/packages/gl.scm | 33 +- gnu/packages/glib.scm | 16 +- gnu/packages/guile.scm| 17 +- gnu/packages/nss.scm |7 +- .../binutils-libiberty-endianness-bug.patch | 36 + .../patches/glib-skip-failing-test.patch | 27 + .../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 +- 19 files changed, 3157 insertions(+), 35 deletions(-) create mode 100644 gnu/packages/patches/binutils-libiberty-endianness-bug.patch create mode 100644 gnu/packages/patches/glib-skip-failing-test.patch create mode 100644 gnu/packages/patches/mac-fdisk-gentoo-patchset.patch create mode 100644 gnu/packages/patches/mac-fdisk-p18.patch base-commit: f08b070019a3c1697bb0b4a783dcd4f31243715a prerequisite-patch-id: b98fc3a62ea8cceddca93361a4621026cebdb8e9 prerequisite-patch-id: 349889c70ebae8711909e6dfc0329235fee1a319 prerequisite-patch-id: dd3b6fe2e61b8588333468e597efec90314e482e prerequisite-patch-id: 95964df281b3feb46795c5875c1091136fb9 prerequisite-patch-id: c150ac2fb2988685f28d788f4924b74a6264dce7 prerequisite-patch-id: a08c6f0dd727f598ef1258bb4233cfcec78913ee prerequisite-patch-id: e36e1a27ce5055e53d5638f7139b4cf8c1ee68bf prerequisite-patch-id: e59cdf3bd91cdba9e39d79d32c650eefea1749fd prerequisite-patch-id: 2a1b37ff2e9b6f6787f4f3262d71cc26a005ccab prerequisite-patch-id: 5cf027408739a4b2661cdf2709abdb8f1f06ce81 prerequisite-patch-id: 6deb5fd40689a243b1cce2c2fa5cca298bce253b prerequisite-patch-id: 4c113e2088ef2674d35d985024c2a41daa8c679c prerequisite-patch-id: edd89720757f9d3cedab3f3832abb4a8ec8bd83f prerequisite-patch-id: 01258be2f32995622720bbc2eac1874282033604 prerequisite-patch-id: ed2fbb545f52e3ae813dc1b27e91e7ce2c84bce7 prerequisite-patch-id: 3523cc33853e2ff01d7b2916f5c481b052a674b5 prerequisite-patch-id: 92482c9dff576aa675e96a15bd02bd7471be517b prerequisite-patch-id: f51d60f4622d9badefacdbb419d26c92a9387286 prerequisite-patch-id: dd2f7be90323949247ee684840ceea90ab2aed30 prerequisite-patch-id: f5f2f3cad462eb3c42df531f4b7fb0b2dc11959d prerequisite-patch-id: ca605868541fdc9d2521c9bad0135a7a6e0b25b0 prerequisite-patch-id: 5ea5961816f5e60b38dbbacc6986860585d5b5c4 prerequisite-patch-id: 6d1cf903247a8ba700eb7b160b58d9b30b012a85 prerequisite-patch-id: 9d2c5115e7e6d19a06019cce74b58d036bc8f0d8 prerequisite-patch-id: b3699959ce306c85c4ed4756746e5273044f175a prerequisite-patch-id: c587c3ca1d6bc31b1ff7f242066a8dd1603d3268 prerequisite-patch-id: 8fb15f1844dfe713c745b8095750912e03449d64 prerequisite-patch-id: fa64eb7a3a6312c0351e3452ad0300014a1cb2a0 prerequisite-patch-id: 84d9c39b89b986e096677904a5328b34e0072d30 prerequisite-patch-id: 0a0b1370f74ade7fcb989bd7e35520e9adac625e prerequisite-patch-id: db9f94813d400e6734a1c80e40ad90aa7c1dd195 prerequisite-patch-id: db6b99cbc6e931613643690b3f72b41d73acf1b7 prerequisite-patch-id: 8441973a4f8c0f1713939fcd489274b7d30f44e4 prerequisite-patch-id: 9dd81d9a919ec6ca7f4bf07affdb7606f216cf44 prerequisite-patch-id: 88e793b3c2f41f4736b0867aaa5359a1a2f5df8f prerequisite-patch-id: 7182f001b5ebaa7aafccf5d4c7e02e086ac6d25a prerequisite-patch-id: fc8ca96ac1c7eb95a9326b2c2489f767c3f3184d prerequisite-patch-id: 317a9f00e31e3a5a85542139bb70bfdadb9d7839 prereq
[PATCH v2 02/12] 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 | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
This patch has the comments updated. I reported my findings to the guile
debbugs email and Other People™ are testing the changes on the other
architectures. Otherwise patch unchanged.
diff --git a/gnu/packages/guile.scm b/gnu/packages/guile.scm
index f63322794d..08ad50f7b0 100644
--- a/gnu/packages/guile.scm
+++ b/gnu/packages/guile.scm
@@ -305,7 +305,22 @@ 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 knows about suggested solution.
+ ;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45214
+ (substitute* "bootstrap/Makefile.in"
+ (("^GUILE_OPTIMIZATIONS.*")
+"GUILE_OPTIMIZATIONS = -O1 -Oresolve-primitives
-Ocps\n"
+ (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"))
+ (package-arguments guile-2.2
(native-search-paths
(list (search-path-specification
(variable "GUILE_LOAD_PATH")
--
2.31.1
[PATCH v2 03/12] gnu: gcc-boot0: Use 128-bit long-double on powerpc-linux.
* gnu/packages/commencement.scm (gcc-boot0)[arguments]: Adjust
configure-flag to also use '--with-long-double-128' on powerpc-linux.
---
gnu/packages/commencement.scm | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
I ran into build troubles without this patch. It only affects gcc-boot0
on powerpc, everything else I built out to mesa was unaffected by a
64-bit/128-bit mismatch.
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index 36ebcee163..93caaac709 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -2733,12 +2733,12 @@ exec " gcc "/bin/" program
"--disable-shared"
"--enable-languages=c,c++"
- ;; boot-triplet inserts "guix" in the triplet.
- ,@(if (equal? "powerpc64le-guix-linux-gnu"
(boot-triplet))
- ;; On POWER9 (little endian) glibc needs the
- ;; 128-bit long double type.
- '("--with-long-double-128")
- '())
+ ;; On POWER9 (little endian) glibc needs the 128-bit
+ ;; long double type. 32-bit PPC is affected by the
+ ;; changes applied for powerpc64le.
+ ,@(if (string-prefix? "powerpc" (boot-triplet))
+ '("--with-long-double-128")
+ '())
;; libstdc++ cannot be built at this stage
;; ("Link tests are not allowed after
--
2.31.1
[PATCH v2 04/12] gnu: binutils: Fix bug in test suite in libiberty.
* gnu/packages/base.scm (binutils)[source]: Add patch.
* gnu/packages/patches/binutils-libiberty-endianness-bug.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register it.
---
gnu/local.mk | 1 +
gnu/packages/base.scm | 3 +-
.../binutils-libiberty-endianness-bug.patch | 36 +++
3 files changed, 39 insertions(+), 1 deletion(-)
create mode 100644 gnu/packages/patches/binutils-libiberty-endianness-bug.patch
Completely rewritten. I reported the bug upstream to binutils and after
some testing it was determined to be an actual bug in libiberty's test
suite affecting big-endian systems. I've tested this on x86_64 and saw
no issues with it.
diff --git a/gnu/local.mk b/gnu/local.mk
index f9996e6fa1..23b768871c 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -865,6 +865,7 @@ dist_patch_DATA =
\
%D%/packages/patches/biber-sortinithash.patch\
%D%/packages/patches/bidiv-update-fribidi.patch \
%D%/packages/patches/binutils-boot-2.20.1a.patch \
+ %D%/packages/patches/binutils-libiberty-endianness-bug.patch \
%D%/packages/patches/binutils-loongson-workaround.patch \
%D%/packages/patches/binutils-mingw-w64-timestamp.patch \
%D%/packages/patches/binutils-mingw-w64-deterministic.patch \
diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index ee1ab1bcad..3dd4f2d0be 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -507,7 +507,8 @@ change. GNU make offers many powerful extensions over the
standard utility.")
(sha256
(base32
"18ypqr5y48vxqg9mkz1c47798jp1xb1d4vfpmfq8vkihkvkx4jsv"))
-(patches (search-patches "binutils-loongson-workaround.patch"
+(patches (search-patches "binutils-libiberty-endianness-bug.patch"
+ "binutils-loongson-workaround.patch"
(build-system gnu-build-system)
;; TODO: Add dependency on zlib + those for Gold.
diff --git a/gnu/packages/patches/binutils-libiberty-endianness-bug.patch
b/gnu/packages/patches/binutils-libiberty-endianness-bug.patch
new file mode 100644
index 00..e6c82f704e
--- /dev/null
+++ b/gnu/packages/patches/binutils-libiberty-endianness-bug.patch
@@ -0,0 +1,36 @@
+This patch fixes a bug exposed when running the libiberty test suite on
+big-endian machines.
+
+Original bug report:
+https://sourceware.org/bugzilla/show_bug.cgi?id=27751
+Follow-ups:
+https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100177
+https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568314.html
+
+---
+ libiberty/rust-demangle.c | 9 ++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/libiberty/rust-demangle.c b/libiberty/rust-demangle.c
+index 6fd8f6a4db0..848563fa3c3 100644
+--- a/libiberty/rust-demangle.c
b/libiberty/rust-demangle.c
+@@ -1253,9 +1253,12 @@ demangle_const_char (struct rust_demangler *rdm)
+ else if (value == '\n')
+ PRINT ("\\n");
+ else if (value > ' ' && value < '~')
+-/* Rust also considers many non-ASCII codepoints to be printable, but
+- that logic is not easily ported to C. */
+-print_str (rdm, (char *) &value, 1);
++{
++ /* Rust also considers many non-ASCII codepoints to be printable, but
++ that logic is not easily ported to C. */
++ char c = value;
++ print_str (rdm, &c, 1);
++}
+ else
+ {
+ PRINT ("\\u{");
+--
+2.31.1
+
--
2.31.1
[PATCH v2 05/12] 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. Add powerpc
specific phase to skip failing tests.
---
gnu/packages/gl.scm | 33 +
1 file changed, 29 insertions(+), 4 deletions(-)
Blanket skipping of the test suite removed, instead we have a phase to
skip certain tests. When rebased on core-updates there will be 3 such
phases and adjustments to the packaging already for powerpc64le and
aarch64. I'll make adjustments to that when I rebase next.
diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
index c194d269f8..ec76029cf9 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"
@@ -350,6 +357,24 @@ also known as DXTn or DXTC) for Mesa.")
(guix build meson-build-system))
#:phases
(modify-phases %standard-phases
+ ,@(if (string-prefix? "powerpc-" (or (%current-target-system)
+ (%current-system)))
+ ;; There are some tests which fail specifically on powerpc.
+ `((add-after 'unpack 'disable-failing-test
+ (lambda _
+ (substitute* '(;; LLVM ERROR: Relocation type not
implemented yet!
+"src/gallium/drivers/llvmpipe/meson.build"
+;; This is probably a big-endian test
failure.
+"src/gallium/targets/osmesa/meson.build")
+ (("if with_tests") "if not with_tests"))
+ (substitute* "src/util/tests/format/meson.build"
+ ;; This is definately an endian-ness test failure.
+ (("'u_format_test', ") ""))
+ ;; It is only this portion of the test which fails.
+ (substitute* "src/mesa/main/tests/meson.build"
+ ((".*mesa_formats.*") ""))
+ #t)))
+ '())
,@(if (string-prefix? "i686" (or (%current-target-system)
(%current-system)))
;; Disable new test from Mesa 19 that fails on i686. Upstream
@@ -390,7 +415,7 @@ also known as DXTn or DXTC) for Mesa.")
(let ((out (assoc-ref outputs "out"))
(bin (assoc-ref outputs "bin")))
,@(match (%current-system)
- ((or "i686-linux" "x86_64-linux")
+ ((or "i686-linux" "x86_64-linux" "powerpc-l
[PATCH v2 06/12] 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 | 43 +
.../patches/mac-fdisk-gentoo-patchset.patch | 866 +++
gnu/packages/patches/mac-fdisk-p18.patch | 2070 +
4 files changed, 2981 insertions(+)
create mode 100644 gnu/packages/patches/mac-fdisk-gentoo-patchset.patch
create mode 100644 gnu/packages/patches/mac-fdisk-p18.patch
I'm fairly certain there's just the cc-for-target change to make-flags.
This package is still untested on actual hardware.
diff --git a/gnu/local.mk b/gnu/local.mk
index 23b768871c..7aba045e4b 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1351,6 +1351,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..5f24d555f0 100644
--- a/gnu/packages/disk.scm
+++ b/gnu/packages/disk.scm
@@ -302,6 +302,49 @@ 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"))
+ #:make-flags (list (string-append "CC=" ,(cc-for-target)))
+ #: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 100
[PATCH v2 07/12] 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(+)
This patch is already in master and already merged into core-updates.
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 v2 08/12] 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(+) Adjusted at the suggestion of Vincent Legoll to strongly match just powerpc-linux and not powerpc64le. diff --git a/gnu/build/vm.scm b/gnu/build/vm.scm index 253d9bcd31..88b27adb4f 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 v2 09/12] 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(-)
Unchanged since last patchset, IMO not ready for upstreaming.
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 v2 10/12] 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(-) Unchanged since last patchset, IMO not ready for upstreaming. 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 v2 11/12] gnu: zstd: Adjust test suite for 32-bit architectures.
* gnu/packages/compression.scm (zstd)[arguments]: Adjust
'fix-tests-32bit phase to work better on low RAM machines.
---
gnu/packages/compression.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Discussed on IRC, ready to go straight to core-updates.
diff --git a/gnu/packages/compression.scm b/gnu/packages/compression.scm
index e28b78a3fa..1941ddd43f 100644
--- a/gnu/packages/compression.scm
+++ b/gnu/packages/compression.scm
@@ -7,7 +7,7 @@
;;; Copyright © 2015, 2016, 2017, 2018, 2020 Ricardo Wurmus
;;; Copyright © 2015, 2017, 2018 Leo Famulari
;;; Copyright © 2015 Jeff Mickey
-;;; Copyright © 2015, 2016, 2017, 2018, 2019, 2020 Efraim Flashner
+;;; Copyright © 2015, 2016, 2017, 2018, 2019, 2020, 2021 Efraim Flashner
;;; Copyright © 2016 Ben Woodcroft
;;; Copyright © 2016 Danny Milosavljevic
;;; Copyright © 2016–2021 Tobias Geerinckx-Rice
@@ -1422,7 +1422,7 @@ or junctions, and always follows hard links.")
(lambda _
(substitute* "tests/playTests.sh"
(("roundTripTest -g8M \"19 -T0 --long\"")
-"roundTripTest -g8M \"22 -T0 --long\""
+"roundTripTest -g8M \"16 -T0 --long\""
(add-after 'unpack 'remove-bogus-check
(lambda _
;; lib/Makefile falsely claims that no .pc file can be created.
--
2.31.1
[PATCH v2 12/12] gnu: glib: Disable failing test.
* gnu/packages/glib.scm (glib)[source]: Add patch.
[arguments]: Remove custom 'increase-test-timeout phase.
* gnu/packages/patches/glib-skip-failing-test.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register it.
---
gnu/local.mk | 1 +
gnu/packages/glib.scm | 16 +++
.../patches/glib-skip-failing-test.patch | 27 +++
3 files changed, 31 insertions(+), 13 deletions(-)
create mode 100644 gnu/packages/patches/glib-skip-failing-test.patch
I don't have a way to test this on native armhf or i686 but I tried
changing the test timeout to 30 minutes (from the new default of 180
seconds) and it still timed out / hung forever. This is the minimal
patch to skip that test.
diff --git a/gnu/local.mk b/gnu/local.mk
index 7aba045e4b..18fa325503 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1080,6 +1080,7 @@ dist_patch_DATA =
\
%D%/packages/patches/ghostscript-no-header-uuid.patch\
%D%/packages/patches/ghostscript-no-header-creationdate.patch \
%D%/packages/patches/glib-appinfo-watch.patch\
+ %D%/packages/patches/glib-skip-failing-test.patch\
%D%/packages/patches/glibc-CVE-2018-11236.patch \
%D%/packages/patches/glibc-CVE-2018-11237.patch \
%D%/packages/patches/glibc-CVE-2019-7309.patch \
diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
index 34d2ba4cf4..ede4a06a08 100644
--- a/gnu/packages/glib.scm
+++ b/gnu/packages/glib.scm
@@ -3,7 +3,7 @@
;;; Copyright © 2013, 2015 Andreas Enge
;;; Copyright © 2013 Nikita Karetnikov
;;; Copyright © 2014, 2015, 2016, 2017, 2018, 2021 Mark H Weaver
-;;; Copyright © 2016, 2020 Efraim Flashner
+;;; Copyright © 2016, 2020, 2021 Efraim Flashner
;;; Copyright © 2016 Lukas Gradl
;;; Copyright © 2017, 2018, 2019 Ricardo Wurmus
;;; Copyright © 2017 Petter
@@ -187,7 +187,8 @@ shared NFS home directories.")
(sha256
(base32 "1sh3h6b734cxhdd1qlzvhxq6rc7k73dsisap5y3s419s9xc4ywv7"))
(patches
-(search-patches "glib-appinfo-watch.patch"))
+(search-patches "glib-appinfo-watch.patch"
+"glib-skip-failing-test.patch"))
(modules '((guix build utils)))
(snippet
'(begin
@@ -203,17 +204,6 @@ shared NFS home directories.")
#:configure-flags '("-Dman=true")
#:phases
(modify-phases %standard-phases
- ;; TODO: Remove the conditional in the next core-updates cycle.
- ;; Needed to build glib on slower ARM nodes.
- ,@(if (string-prefix? "arm" (%current-system))
- `((add-after 'unpack 'increase-test-timeout
- (lambda _
- (substitute* "meson.build"
- (("test_timeout = 60")
-"test_timeout = 90")
- (("test_timeout_slow = 120")
-"test_timeout_slow = 180")
- '())
(add-after 'unpack 'disable-failing-tests
(lambda _
(with-directory-excursion "glib/tests"
diff --git a/gnu/packages/patches/glib-skip-failing-test.patch
b/gnu/packages/patches/glib-skip-failing-test.patch
new file mode 100644
index 00..c7706aaa74
--- /dev/null
+++ b/gnu/packages/patches/glib-skip-failing-test.patch
@@ -0,0 +1,27 @@
+This test timed out on powerpc-linux even after extending the
+test_timeout_slow to 1800 seconds. Previously we tried to work around
+this test by extending test_timeout_slow by 1.5 its previous value.
+
+---
+ gio/tests/meson.build | 4
+ 1 file changed, 4 deletions(-)
+
+diff --git a/gio/tests/meson.build b/gio/tests/meson.build
+index a926ae0..4fdbe7a 100644
+--- a/gio/tests/meson.build
b/gio/tests/meson.build
+@@ -317,10 +317,6 @@ if host_machine.system() != 'windows'
+ 'extra_sources' : [extra_sources, gdbus_test_codegen_generated,
gdbus_test_codegen_generated_interface_info],
+ 'c_args' : ['-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_32'],
+ },
+- 'gdbus-threading' : {
+-'extra_sources' : extra_sources,
+-'suite' : ['slow'],
+- },
+ 'gmenumodel' : {
+ 'extra_sources' : extra_sources,
+ 'suite' : ['slow'],
+
+--
+2.31.1
+
--
2.31.1
Re: neovim and luajit?
On Thu, Apr 22, 2021 at 01:33:58AM -0400, Jack Hill wrote: > On Fri, 31 Jul 2020, Jack Hill wrote: > > > Hi Guix, > > > > I'm wondering why we use Lua 5.1 instead of LuaJIT for neovim? It seems > > that upstream prefers LuaJIT given the non-default configure flag we > > use[0] and their FAQ[1]. > > > > I don't have an opinion either way. I'm learning about neovim today, and > > am curious how we arrived at our configuration. > > > > [0] > > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/vim.scm?id=96a655a77bb087397a9436391e472c36ff0a2ec2#n647 > > [1] https://github.com/neovim/neovim/wiki/FAQ#why-embed-lua-instead-of-x > > > > Best, > > Jack > > I've returned to the above question. With the attached patch, neovim builds > on x86_64 and performs basic editing functions. I did not test it with any > extra packages or plugins. > > In addition to what I said before, I'm also interested in LuaJIT because it > supports the 5.1 language and still seems to be developed upstream. Lua is > no longer developing the 5.1 series and the newer series have an > incompatible language. > > A downside to using LuaJIT is that it doesn't support all the architectures > that Guix supports [2]. In particular, it looks like aarch64 and ppc64el are > missing. > > [2] https://luajit.org/install.html > > Best, > Jack > > P.S. Maybe its time to work on the Lua language of Guile 😀 Our copy of luajit supports aarch64 so I don't think that's a problem. (Last I checked) Debian has a patch to replace powerpc support with 64-bit ppc support. I'd go ahead with the change if that's the direction that neovim is going and let the powerpc64le people decide between using lua5.1 or just removing lua support on a per-architecture basis for ppc64le. -- 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: [bug#47615] [PATCH 3/9] gnu: binutils: Adjust test suite on powerpc-linux.
On Wed, Apr 21, 2021 at 10:11:48PM -0700, Chris Marusich wrote: > Efraim Flashner writes: > > >> If it's a test failure, has the issue been reported upstream? > > > > I'll check to see if I can find something upstream. If not I'll report > > it. FWIW Debian disables the test suite for powerpc. > > https://sources.debian.org/src/binutils/2.36.1-6/debian/rules/#L537 > > How significant is the failure, anyway? Are we likely to encounter > trouble down the line on powerpc if we don't resolve this? I have no > idea, honestly, so I'm asking because I just don't know. I submitted the bug upstream. It turns out it was a bug in the test suite which only showed up on big-endian systems. They've fixed it in libiberty (in GCC) and I added the patch to binutils on core-updates. Tests pass on powerpc-linux and x86_64-linux. It also made this commit much much smaller :) -- 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: Neovim plugin/addon packaging
On Fri, Apr 30, 2021 at 01:03:23AM -0400, Jack Hill wrote: > Greetings Guix, > > I'd like to improve the experience of installing Neovim plugins/add-ons with > Guix. I've submitted #48112 [0] which adds an XDG_DATA_DIRS search path so > nvim (the Neovim executable name) will be able to find plugins installed by > guix at …/share/nvim/site. I guess my first question is does it work? I think I first tried something similar for vim with 'share/vim/vimfiles' but it didn't actually work for vim. > Currently, we only have one such package, neovim-syntastic. I'd like to add > more. Many plugins are compatible with both vim and nvim. However, they > search for plugins at different paths. Therefore, the vim-syntastic and > neovim-syntastic packages, which use the copy-build-system, differ only in > the destination directories of the install-plan (and changing "Vim" to > "Neovim" in the description). > > My initial inclination is to remove the duplication of maintaining two > install-plans (and other arguments) by creating a procedure that would take > as input a Vim package that uses copy-build-system and output a Neovim > package with the install-plan re-written. > > Perhaps that solution would be overwrought. How would you recommend handling > this situation? My first idea would be to have the one package install the files into both directories and combine them, but I feel like it falls apart when it comes to searching for vim/neovim plugins and naming. One package with two names? Call it vim-neovim-syntastic? If vim/neovim move more apart and actually need separate plugins in the future then I guess it would make more sense to have two actual packages that can be installed by name (vim-foo and neovim-foo). > [0] https://issues.guix.gnu.org/48112 > > Best, > Jack -- 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: Neovim plugin/addon packaging
On Sat, May 01, 2021 at 04:25:18PM -0400, Jack Hill wrote: > Thanks for your reply. > > On Fri, 30 Apr 2021, Efraim Flashner wrote: > > > On Fri, Apr 30, 2021 at 01:03:23AM -0400, Jack Hill wrote: > > > Greetings Guix, > > > > > > I'd like to improve the experience of installing Neovim plugins/add-ons > > > with > > > Guix. I've submitted #48112 [0] which adds an XDG_DATA_DIRS search path so > > > nvim (the Neovim executable name) will be able to find plugins installed > > > by > > > guix at …/share/nvim/site. > > > > I guess my first question is does it work? I think I first tried > > something similar for vim with 'share/vim/vimfiles' but it didn't > > actually work for vim. > > Yes, it does work! I tested it with neovim-syntastic and a local > neovim-fugitive package both with a guix environment and manually > manipulated environment variables. > > A difference between Neovim and Vim is that Neovim supports XDG_DATA_DIRS > (and XDG_CONFIG_DIRS) as real search paths while the environment variables > for Vim are single directories (compare `:help runtimepath` in the two > editors). > > > > Currently, we only have one such package, neovim-syntastic. I'd like to > > > add > > > more. Many plugins are compatible with both vim and nvim. However, they > > > search for plugins at different paths. Therefore, the vim-syntastic and > > > neovim-syntastic packages, which use the copy-build-system, differ only in > > > the destination directories of the install-plan (and changing "Vim" to > > > "Neovim" in the description). > > > > > > My initial inclination is to remove the duplication of maintaining two > > > install-plans (and other arguments) by creating a procedure that would > > > take > > > as input a Vim package that uses copy-build-system and output a Neovim > > > package with the install-plan re-written. > > > > > > Perhaps that solution would be overwrought. How would you recommend > > > handling > > > this situation? > > > > My first idea would be to have the one package install the files into > > both directories and combine them, but I feel like it falls apart when > > it comes to searching for vim/neovim plugins and naming. One package > > with two names? Call it vim-neovim-syntastic? > > > > If vim/neovim move more apart and actually need separate plugins in the > > future then I guess it would make more sense to have two actual packages > > that can be installed by name (vim-foo and neovim-foo). > > A combined package is an interesting suggestion. However, I share the > concern about searching for packages. Having packages that are compatible > with both editors use one naming scheme and ones that are compatible with > only one use a different naming scheme seems like a implementation detail > that would be better not to expose to me. > > I drew inspiration for creating the Neovim package variants with a procedure > from the package-for-python2 and sbcl-package->ecl-package. Of course those > procedures have build system support and aren't depending on a common usage > pattern of copy-build-system. > > Is it time a a vim-build-system? Perhaps not, but I'm still not sure what > the right way forward is. ng0/nikita thought about it a few years ago but I think the copy-build-system works well enough. I know for vim we need a vim profile hook to create the documentation, does neovim need something like that too? -- 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: Neovim plugin/addon packaging
On Mon, May 03, 2021 at 12:46:30AM -0400, Jack Hill wrote: > On Sun, 2 May 2021, Efraim Flashner wrote: > > > ng0/nikita thought about it a few years ago but I think the > > copy-build-system works well enough. I know for vim we need a vim > > profile hook to create the documentation, does neovim need something > > like that too? > > I'm not sure and will need to investigate. With the XDG_DATA_DIRS search > path, if I install neovim and neovim-syntastic into the same environment, I > am able to see references to the syntastic documentation in the main help > index, but trying to navigate to them results in a 'E149: Sorry, no help for > syntastic-checkers.txt' error, so clearly something is not quite right. > That's always something we can fix later. It's also not more broken than it is now. -- 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 v2 00/12] Add 32-bit powerpc support
I'm going to bump this email again. I feel like it's ready for merging but I wanted to give everyone another chance to chime in. -- 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: bug#47615: [PATCH 1/9] gnu: bootstrap: Add support for powerpc-linux.
On Tue, May 04, 2021 at 06:52:31PM -0700, Chris Marusich wrote: > Chris Marusich writes: > > > Efraim Flashner writes: > > > >> On 923bb70a1bff657125c3008f119a477e5cb57c2b > >>gnu:glibc-for-bootstrap: Fix patch. > >> > >> Run > >> ./pre-inst-env guix build --target=powerpc-linux-gnu bootstrap-tarballs > g>> > >> Producing > >> > >> /gnu/store/dyj1wvayyp1ihaknkxniz1xamcf4yrhl-bootstrap-tarballs-0 > >> > >> With guix hash -rx > >> /gnu/store/dyj1wvayyp1ihaknkxniz1xamcf4yrhl-bootstrap-tarballs-0 > >> > >> 02xx2ydj28pwv3vflqffinpq1icj09gzi9icm8j4bwc4lca9irxn > > > > Generally speaking, this patch looks fine to me. Just curious, what > > sort of machines does one use for 32-bit powerpc? > > > > I want to build the bootstrap binaries, see if they're reproducible (in > > particular GCC, which I suspect won't be), and verify the hashes. > > > > It might take a few days to do that, but I'll update this thread once > > I've done it. > > I repeated Efraim's steps on two different x86_64-linux Guix System > machines. In both cases, it produced exactly the same hash. Therefore, > it would seem these bootstrap binaries are actually reproducible. I was > surprised by this because of my experience with bug 41669. I expected > GCC to not be reproducible, but in this case it seems reproducible. > > I wonder what's different? The powerpc64 architecture is 64-bit, and > powerpc is 32-bit, but I wonder what else might be different that could > cause the non-reproducibility to occur only in the powerpc64-linux > case. > > Anyway, this is good news for the powerpc-linux port. It is also an > interesting clue for the investigation of bug 41669, but further > discussion about that should go there, not here. > In terms of what is more relevant here, IIRC there is some CI code to build cross toolchain stuff to powerpc-linux-gnu. Is it possible that you reused some of that? I don't remember exactly from the other bug report which bits suddenly made the difference. Otherwise I built mine about 4 months earlier. -- 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: bug#47615: [PATCH 0/9] Add 32-bit powerpc support
On Thu, May 06, 2021 at 04:48:09PM +0200, Ludovic Courtès wrote: > Efraim Flashner skribis: > > > * 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. > > [...] > > > +++ 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 > > > [...] > > > +++ b/gnu/packages/patches/mac-fdisk-p18.patch > > @@ -0,0 +1,2070 @@ > > +This is the result of unzipping the 0.1-18 diff.gz > > +https://cdn-aws.deb.debian.org/debian/pool/main/m/mac-fdisk/mac-fdisk_0.1-18.diff.gz > > Given the size of these patches, please add a couple of sentences > explaining what they do. > > It would be best if we could refer to a fork instead of carrying those > patches, though. > > Ludo’. I think I'm going to sit on the mac-fdisk package for a while. It would be good to cut down the patches a bit. And I have to actually test it at some point. -- 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: branch core-updates updated: gnu: coreutils-boot0: Fix building on arm architectures.
On December 12, 2022 1:47:29 PM UTC, "Ludovic Courtès" wrote: >Hello, > >guix-comm...@gnu.org skribis: > >> commit 9782c4529249c8300501202112c095a6589845d3 >> Author: Efraim Flashner >> AuthorDate: Sun Dec 11 22:35:06 2022 +0200 >> >> gnu: coreutils-boot0: Fix building on arm architectures. >> >> * gnu/packages/commencement.scm (coreutils-boot0)[arguments]: When >> building for arm architectures skip building some programs. > >[…] > >> + ,@(if (target-arm?) >> + ;; Some binaries fail to build. >> + `(#:configure-flags '(,(string-append >> +"--enable-no-install-program=" >> +;; the defaults >> +"arch,coreutils,hostname" >> +;; fails on aarch64 >> +",timeout,sort"))) > >Isn’t there a risk that things will break down the road if ‘sort’, >‘hostname’, etc. are missing? How hard would it be to address the build >failure instead? > >Thanks, >Ludo’. I built all the way out to hello without any problems. Also %final-inputs has coreutils-final, so it really shouldn't be noticable. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Python Packaging Policy
On Thu, Dec 08, 2022 at 11:48:42AM +0100, zimoun wrote: > Hi, > > On Wed, 07 Dec 2022 at 17:22, jgart wrote: > > > What is our policy then for updating Python packages in our Python > > library collection? > > The policy is to not break the other packages; guix refresh -l python-. > > > > How are we assuring that all Python libraries are working well together? > > How? With a lot of love. :-) Yeah, basically. The 'sanity-check phase helps a lot though ... -- 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: WIP: zig-build-system
a copy of the GNU General Public License
> +;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
> +
> +(define-module (guix build zig-build-system)
> + #:use-module ((guix build gnu-build-system) #:prefix gnu:)
> + #:use-module (guix build utils)
> + #:use-module (ice-9 popen)
> + #:use-module (ice-9 rdelim)
> + #:use-module (ice-9 ftw)
> + #:use-module (ice-9 format)
> + #:use-module (ice-9 match)
> + #:use-module (rnrs io ports)
> + #:use-module (srfi srfi-1)
> + #:use-module (srfi srfi-26)
> + #:export (%standard-phases
> +zig-build))
> +
> +;; Commentary:
> +;;
> +;; Builder side code of the Zig build system
> +;;
> +;; Code:
> +
> +;; Interesting guide here:
> +;; https://github.com/riverwm/river/blob/master/PACKAGING.md
I would define a global-cache-dir and use ZIG_GLOBAL_CACHE_DIR to refer
to it and not pass it around to all the phases.
> +(define* (build #:key (zig-build-flags '())
> +#:allow-other-keys)
> + "Build a given Zig package."
> + (setenv "DESTDIR" "out")
> + (apply invoke
> +`("zig" "build"
> + "--global-cache-dir" "zig-cache"
> + "-p" "" ;; Don't add /usr
If '-p' is the short form of '--prefix' or something then use the long
form.
> + "--prefix-lib-dir" "lib"
> + "--prefix-exe-dir" "bin"
> + "--prefix-include-dir" "include"
> + ,@zig-build-flags)))
> + ;; Let the build flags decide if it needs `-Drelease-safe` or
> + ;; `-Drelease-fast` or any other.
cmake-build-system has an option to determine Release or Debug (or to
leave it as RelWithDebInfo) named 'build-type'. I think that should be
added here.
> +
> +(define* (check #:key tests? #:allow-other-keys)
> + "Run all the tests"
> + (when tests?
> +(setenv "DESTDIR" "test-out")
I assume this is to prevent overwriting the actual binary with the tests
enabled binary? I would consider unsetting it at the end of the phase.
Or storing its previous value and setting it back to that, we have seen
packages which use DESTDIR and I wouldn't want any surprises.
> +(apply invoke
> + `("zig" "build" "test"
> + "--global-cache-dir" "zig-cache"
What's the difference between 'zig test build.zig' and 'zig build test'?
> +(define* (install #:key inputs outputs #:allow-other-keys)
> + "Install a given Zig package."
> + (let* ((out(assoc-ref outputs "out")))
> +(copy-recursively "out" out)))
Beware of copy-pasting :). You don't use inputs, don't need let* vs let,
and could probably directly (copy-recursively #$output out). Or rely on
'make install'. 'make install' was available for ncdu2, not sure about
other zig projects.
> +(define %standard-phases
> + (modify-phases gnu:%standard-phases
> +(delete 'bootstrap)
> +(delete 'configure)
> +(replace 'build build)
> +(replace 'check check)
> +(replace 'install install)))
> +
> +
> +(define* (zig-build #:key inputs (phases %standard-phases)
> + #:allow-other-keys #:rest args)
> + "Build the given Zig package, applying all of PHASES in order."
> + (apply gnu:gnu-build #:inputs inputs #:phases phases args))
> --
> 2.38.0
>
--
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: skia for libreoffice
On Sun, Jan 08, 2023 at 12:21:55PM +0100, Nicolas Graves via Development of GNU Guix and the GNU System distribution. wrote: > > Hi! > (please tell me if I should use another channel for such questions) > > I recently have been working on enabling tests for skia and including > skia in libreoffice (see bug 60571 for the first part). > > Now that I delve into libreoffice's build of skia, I see that there's a > series of patches that libreoffice use for the build of the > library. Which makes me wonder if it's worth it packaging a > "skia-for-libreoffice" package variant, or if we should just add the > tarball in the external directory as it has been done with dtoa, and > rely on libreoffice's build of skia. In the end, both versions will end > up in the store in any case, because of the patches libreoffice needs. > > What is Guix policy in this case? It's a toss-up. skia-for-libreoffice wouldn't see any use outside of libreoffice since it's specific patches and not a different version of the library. In those cases (especially if the library is maintained upstream by the same people, which I don't think is the case here) we're far more lenient on leaving it bundled. On the other hand, separating it out would decrease the build time for libreoffice, which would be a Good Thing™. IF (and I mean it) you can separate it out easily and it doesn't make building libreoffice with it then go ahead and do so, especially if the version and/or patches don't change regularly. Otherwise I'd consider adding a note in libreoffice's snippet (assuming it has one) or configure-flags about why we're not using an unbundled version. -- 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: Packages grow, no longer fit on a 💾
t;))
((#:phases phases)
`(modify-phases ,phases
(add-after 'install 'delete-static-libraries
(lambda* (#:key outputs #:allow-other-keys)
(for-each delete-file
(find-files (string-append
(assoc-ref outputs "out") "/lib")
"\\.a$"
(replace 'install-opt-viewer
(lambda* (#:key outputs #:allow-other-keys)
(let ((out (assoc-ref outputs "out")))
(delete-file-recursively
(string-append out "/share/opt-viewer")
(add-after 'install 'build-and-install-llvm-config
(lambda* (#:key outputs #:allow-other-keys)
(let ((out (assoc-ref outputs "out")))
(substitute*
"tools/llvm-config/CMakeFiles/llvm-config.dir/link.txt"
(("/tmp/guix-build-llvm-11.0.0.drv-0/build/lib")
(string-append out "/lib")))
(invoke "make" "llvm-config")
(install-file "bin/llvm-config"
(string-append out "/bin")))
In addition to what I have below I found that nix has a patch to make
llvm-11 (and the others) use the GNUInstallDirs, so we'd be able to move
the include directory to another output, saving another 21MB, bringing
llvm-for-mesa down to 71MB. Another possibility would be to have
llvm-for-mesa use llvm as an input, and then to use some configure-flags
to tell llvm-for-mesa to use the includes from llvm (the input).
--
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: Merging core-updates?
On Sun, Feb 12, 2023 at 10:05:40AM +0100, Julien Lepiller wrote: > Hi Guix! > > As discussed at Guix Days before Fosdem, we haven't merged core-updates > in a very long time. I'd volunteer to lead this effort, but I don't > know what steps I should follow. Do we have some documentation about > that? I think we normally have a 2 week last-chance window to get all sorts of last minute packages bumped and then we freeze it and try to build "everything". -- 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: branch core-updates updated: gnu: coreutils-boot0: Fix building on arm architectures.
On Thu, Dec 15, 2022 at 03:56:24PM +0100, Ludovic Courtès wrote: > Hi, Sorry for taking a while to get back to answer this. > Efraim Flashner skribis: > > > On December 12, 2022 1:47:29 PM UTC, "Ludovic Courtès" wrote: > > [...] > > >>> + ,@(if (target-arm?) > >>> + ;; Some binaries fail to build. > >>> + `(#:configure-flags '(,(string-append > >>> +"--enable-no-install-program=" > >>> +;; the defaults > >>> +"arch,coreutils,hostname" > >>> +;; fails on aarch64 > >>> +",timeout,sort"))) > >> > >>Isn’t there a risk that things will break down the road if ‘sort’, > >>‘hostname’, etc. are missing? How hard would it be to address the build > >>failure instead? > >> > >>Thanks, > >>Ludo’. > > > > I built all the way out to hello without any problems. Also %final-inputs > > has coreutils-final, so it really shouldn't be noticable. > > That’s odd though. Isn’t there some upstream patch we could take? > Surely ‘sort’ has no reason to contain arch-specific code? > > If there’s no such patch, we can go with the patch above, but then there > should be a comment linking to bug reports and reassuring the reader > that yes, some packages do build even without these commands. :-) In file included from src/timeout.c:53:0: /gnu/store/4fy2658sxphy1kgclxrrmcka6lwiwap0-glibc-bootstrap-0/include/sys/prctl.h:22:66: fatal error: linux/prctl.h: No such file or directory #include /* The magic values come from here */ I'm not sure if it's because armhf and aarch64 are using %bootstrap-glibc vs glibc-2.16, but I didn't see this problem with glibc-mesboot or with the %bootstrap-glibc from architectures using 2.31. Other workarounds I thought of were adding in a glibc-boot0 here to replace libc for everybody or using an older version (the last one in the 8 series), but this seemed like the least invasive option for now. I've also added a comment so it'll be clearer what's happening there. > (There’s no “coreutils” command BTW, unless enabling the > everything-in-one-binary trick, no?) It turns out coreutils does allow for that. > Thanks, > Ludo’. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Architecture support [was: Re: Merging core-updates?]
On Mon, Feb 13, 2023 at 10:43:17AM +0100, zimoun wrote: > Hi, > > Well, it could be helpful is Berlin or Bordeaux could build some > manifest of core-updates (not necessary the whole core-updates). And > then, once the manifest builds, we could add some packages and repeat. > > It would avoid that we all build the same things; worse, that each of us > burn many CPU just for knowing it fails. > > Chris, Mathieu? What do you think? > At least locally I try to build out to hello, and then to mesa. Currently I believe only x86_64 is building to hello. I'm not against downgrading file to an earlier version if it'll get i686 to get to hello. i686 is getting stuck at an unknown file. Aarch64 and armhf are getting stuck at gcc-cross-boot0. Riscv64 is getting stuck at gcc-final. I haven't tested powerpc64le (or powerpc or mips64el). -- 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: Proposed changes to the commit policy
On Mon, Jan 30, 2023 at 10:40:42PM +0100, Ludovic Courtès wrote: > Hi! > > My 2¢ on this… As a committer & reviewer, I love that I can just go to > <https://qa.guix.gnu.org/patches>, pick one of the patch series with a > green tick, and have the assurance that the resource-intensive work is > already done. That makes a big difference! > > As someone who submits patches, I realize the delay can be off-putting. > For the hwloc upgrade I recently submitted, I got valuable feedback > pointing at actual issues, but that was about a week later. Then I had > to switch contexts again to adjust the patch accordingly. > > I guess that, to a large extent, that’s scheduling and resource issue. > > Happy to discuss that in the coming days in Brussels! Some of that might be mitigated by separating submitting patches and pushing patches. On the rare occasion I've pushed patches belonging to another committer if I felt it had been long enough and I needed it for another patchset. If we're ok with touching up and pushing each other's patches then reviewing all patches might go faster. Even more so if we made it a rule that you couldn't push your own patches (which I believe was suggested in 2017 and with using aegis). -- 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: Merging core-updates?
On Sun, Feb 12, 2023 at 06:29:04PM +, Kaelyn wrote: > Hi, > > --- Original Message --- > On Sunday, February 12th, 2023 at 5:08 PM, Andreas Enge > wrote: > > > > > > > Am Sun, Feb 12, 2023 at 12:58:06PM +0100 schrieb Julien Lepiller: > > > > > And I was able to rebuild (with --check) patch-mesboot. The error looks > > > a lot like https://issues.guix.gnu.org/49985. We should fix that indeed > > > :) > > > > > > Ah indeed, that looks like deal breaking; maybe someone from MES can have > > a look? > > > > What is the magic incantation with double "@@" to build this package? > > Ah, here we go, for reference to self: > > guix build -e '(@@ (gnu packages commencement) patch-mesboot)' > > > > Andreas > > While not directly related to the patch-mesboot error, I want to mention that > there is also https://issues.guix.gnu.org/58719 blocking i686 builds on > core-updates (and x86_64 builds of certain packages like wine64, which has > i686 dependencies) since the update to glibc 2.35. > > It may also need assistance from the MES folks to fix, since the error > message is about an undefined symbol in glibc-mesboot's libpthread.so.0: > > make[2]: Entering directory '/tmp/guix-build-file-5.44.drv-0/file-5.44/magic' > ../src/file -C -m magic > /tmp/guix-build-file-5.44.drv-0/file-5.44/src/.libs/file: symbol lookup > error: > /gnu/store/s4yd6ibxsh5q1j9ipygb9vpjj4g00wc9-glibc-mesboot-2.16.0/lib/libpthread.so.0: > undefined symbol: h_errno, version GLIBC_PRIVATE > make[2]: *** [Makefile:863: magic.mgc] Error 127 > > Cheers, > Kaelyn I think I found where this is coming from. %boot3-inputs added ld-wrapper-boot3 but didn't remove ld-wrapper-0, which pulled in glibc-mesboot. I'm testing out removing ld-wrapper-0 from %boot3-inputs to see if that's enough to make that final file build. Hopefully it'll also fix the final tar for i686, which I found was also failing for me. -- 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: Merging core-updates?
On Mon, Feb 13, 2023 at 09:35:32PM +0100, Andreas Enge wrote:
> Hello all,
>
> here are my first important failures when trying to go beyond hello and mpc
> (aka the easy C programs):
>
> ocaml-4.0.9 fails with
> gcc -c -O2 -fno-strict-aliasing -fwrapv -Wall -fno-tree-vrp -g
> -D_FILE_OFFSET_BITS=64 -D_REENTRANT -DCAML_NAME_SPACE
> -DOCAML_STDLIB_DIR='"/gnu/store/mzzak7bp6dpngq04hphlx58wzp62755m-ocaml-4.09.0/lib/ocaml"'
> -DNATIVE_CODE -DTARGET_amd64 -DMODEL_default -DSYS_linux -o
> signals_nat_n.o signals_nat.c
> signals_nat.c:185:13: error: variably modified ‘sig_alt_stack’ at file scope
> 185 | static char sig_alt_stack[SIGSTKSZ];
> | ^
> make[3]: *** [Makefile:343: signals_nat_n.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> make[3]: Leaving directory
> '/tmp/guix-build-ocaml-4.09.0.drv-0/ocaml-4.09.0/runtime'
> make[2]: *** [Makefile:1004: makeruntimeopt] Error 2
> make[2]: Leaving directory '/tmp/guix-build-ocaml-4.09.0.drv-0/ocaml-4.09.0'
> make[1]: *** [Makefile:417: opt.opt] Error 2
> make[1]: Leaving directory '/tmp/guix-build-ocaml-4.09.0.drv-0/ocaml-4.09.0'
> make: *** [Makefile:468: world.opt] Error 2
> error: in phase 'build': uncaught exception:
> %exception #<&invoke-error program: "make" arguments: ("-j" "4" "world.opt")
> exit-status: 2 term-signal: #f stop-signal: #f>
> phase `build' failed after 45.7 seconds
> command "make" "-j" "4" "world.opt" failed with status 2
>
> openjdk-19.0.1-checkout fails:
> `File make/modules/java.desktop/lib/Awt2dLibraries.gmk is read-only; trying
> to patch anyway
> patching file make/modules/java.desktop/lib/Awt2dLibraries.gmk
> Hunk #1 succeeded at 214 (offset -3 lines).
> File src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c is
> read-only; trying to patch anyway
> patching file src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c
> Hunk #1 succeeded at 44 (offset 4 lines).
> Hunk #2 succeeded at 978 (offset 4 lines).
> File test/jdk/java/awt/JAWT/Makefile.unix is read-only; trying to patch anyway
> patching file test/jdk/java/awt/JAWT/Makefile.unix
> File test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c is read-only;
> trying to patch anyway
> patching file test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c
> Hunk #1 FAILED at 67.
> 1 out of 1 hunk FAILED -- saving rejects to file
> test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c.rej
> source is at 'openjdk-19.0.1-checkout'
> applying
> '/gnu/store/g6sgv9nipmvsxbmimlgsmhdcdvcssmhf-openjdk-15-xcursor-no-dynamic.patch'...
> applying
> '/gnu/store/ms15ddy4ac2kmiyy82l0spnjj5b6h6lb-openjdk-10-hotspot-stack-size.patch'...
> Backtrace:
>5 (primitive-load "/gnu/store/kpgzrwyczkxymc54lnkld0nmrd0…")
> In ice-9/eval.scm:
> 619:8 4 (_ #(#(# "ope…") #))
> In ice-9/boot-9.scm:
> 142:2 3 (dynamic-wind # …)
> In ice-9/eval.scm:
> 619:8 2 (_ #(#(#)))
> In srfi/srfi-1.scm:
> 634:9 1 (for-each # _)
> In guix/build/utils.scm:
> 812:6 0 (invoke "/gnu/store/qy964im7g1w77yzd97rahl0r7v8rkv0g-p…" …)
>
> guix/build/utils.scm:812:6: In procedure invoke:
> ERROR:
> 1. &invoke-error:
> program:
> "/gnu/store/qy964im7g1w77yzd97rahl0r7v8rkv0g-patch-2.7.6/bin/patch"
> arguments: ("--force" "--no-backup-if-mismatch" "-p1" "--input"
> "/gnu/store/ms15ddy4ac2kmiyy82l0spnjj5b6h6lb-openjdk-10-hotspot-stack-size.patch")
> exit-status: 1
> term-signal: #f
> stop-signal: #f
> Just a permission error on files to be patched, or a problem with the patch
> itself?
>
> Andreas
Looks like you might be able to drop openjdk-10-hotspot-stack-size.patch
from openjdk-19.0.1.
--
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
Rust team branch (was Re: Discussion notes on releases and branches)
On Thu, Feb 09, 2023 at 01:19:28PM +0100, Andreas Enge wrote: > Attached are the notes of our discussion at the Guix Days concerning > releases, branches, teams and related matters. > > Andreas > > BRANCHES > > Suggestion: > - Spin off a stable branch from master with security fixes, maybe important > backports; after 6 months, branch a new stable branch from master; this > is almost like a release, but continued into some future. > > Counter-suggestion: > - Create branches with a few patches or patchsets; in any case with > a "semantic" description of the changes. The branches could be > shortlived. Feature branches are one incarnation of the concept. > - The numerical criteria for staging and core-updates is outdated: > Even non-core packages may create an enormous number of rebuilds. > - Negative point: There is a risk of churn, by not regrouping world- > rebuilding changes - but two non related world rebuilding changes > might be difficult to review. > > Before creating new branches, we need to clarify how the old branches > are handled! > > - Smaller branches could be taken care of by dedicated persons > responsible for pushing them forward. For instance by teams. > - Some people already do this for a feature branch on their local > machine for medium-sized updates (ocaml), or even on ci (haskell, > kernel updates). > - Branch creators should fix a goal and tentative timeline. > - We need a mapping between branches and maintainers responsible > for the merge. This could be a team leader, if such a role is created. > A wiki could be used to keep track of the branches. > - There is discussion whether we need a core-updates branch. > Core updates concern the toolchain, build phase changes, everything > that has big ramifications all over the system. It would be important > to not have several "parallel" branches with related (for instance, > but not exclusively, core-update) changes, which in fact should come > one after the other. Either they could be collected in one branch, > or would require coordination of branch creation (inside a team, say). > - "Merge trains" of gitlab are mentioned, as a way of merging several > branches at the same time. > - Grafts can also be handled in feature branches: The graft is applied > to master; the graft is applied to a different branch, directly followed > by an ungrafting commit and an update of the corresponding package; > once the branch is built it is merged back to master. > - Minor drawback: If qa has treated a world-rebuilding patch, the > substitutes will be available on bordeaux, but not on berlin; people > who have installed a long time ago and not authorised bordeaux might > be affected. If there are complaints, they can be handled on the > mailing list. > - Moving fast poses problems for non-x86 architectures, but the build farm > situation has improved for aarch64 and armhf sufficiently to keep up > with master. Handling feature branches remains an unsolved problem. > - Currently there is a cap on qa, only patches with at most 300 dependents > are treated. This cap could be increased. Or it could be weighed with > the build times of the packages. > > > TEAMS > > - Issues could be tagged more often with responsible teams, or with > severity information (blocking bug or not). > - Each module should be covered by a team; otherwise it would be > difficult to get important updates through a feature branches. On behalf of the Rust Team™¹ we'd like to check our rust source tarballs for any hidden binaries² and to do a mass upgrade of many of the crates. Currently there are many crates queued up in the staging branch but we'd like to pull them out and run a rust-team branch. As a project we haven't setup anything for starting the team-based branches and upgrades, and the Rust Team volunteers to go first. Although the rust team would consider adding librsvg (and python-cryptography) to our list of packages, we'd like to not touch it this round, to keep it "small" (as far as rust goes) as a test. ¹ Help wanted ² https://issues.guix.gnu.org/61352 -- 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: Merging core-updates?
On Mon, Feb 13, 2023 at 09:36:17PM +, Kaelyn wrote: > --- Original Message --- > On Monday, February 13th, 2023 at 8:04 PM, Efraim Flashner > wrote: > > > > > > On Sun, Feb 12, 2023 at 06:29:04PM +, Kaelyn wrote: > > > > > Hi, > > > > > > --- Original Message --- > > > On Sunday, February 12th, 2023 at 5:08 PM, Andreas Enge andr...@enge.fr > > > wrote: > > > > > > > Am Sun, Feb 12, 2023 at 12:58:06PM +0100 schrieb Julien Lepiller: > > > > > > > > > And I was able to rebuild (with --check) patch-mesboot. The error > > > > > looks > > > > > a lot like https://issues.guix.gnu.org/49985. We should fix that > > > > > indeed > > > > > :) > > > > > > > > Ah indeed, that looks like deal breaking; maybe someone from MES can > > > > have > > > > a look? > > > > > > > > What is the magic incantation with double "@@" to build this package? > > > > Ah, here we go, for reference to self: > > > > guix build -e '(@@ (gnu packages commencement) patch-mesboot)' > > > > > > > > Andreas > > > > > > While not directly related to the patch-mesboot error, I want to mention > > > that there is also https://issues.guix.gnu.org/58719 blocking i686 builds > > > on core-updates (and x86_64 builds of certain packages like wine64, which > > > has i686 dependencies) since the update to glibc 2.35. > > > > > > It may also need assistance from the MES folks to fix, since the error > > > message is about an undefined symbol in glibc-mesboot's libpthread.so.0: > > > > > > make[2]: Entering directory > > > '/tmp/guix-build-file-5.44.drv-0/file-5.44/magic' > > > ../src/file -C -m magic > > > /tmp/guix-build-file-5.44.drv-0/file-5.44/src/.libs/file: symbol lookup > > > error: > > > /gnu/store/s4yd6ibxsh5q1j9ipygb9vpjj4g00wc9-glibc-mesboot-2.16.0/lib/libpthread.so.0: > > > undefined symbol: h_errno, version GLIBC_PRIVATE > > > make[2]: *** [Makefile:863: magic.mgc] Error 127 > > > > > > Cheers, > > > Kaelyn > > > > > > I think I found where this is coming from. %boot3-inputs added > > ld-wrapper-boot3 but didn't remove ld-wrapper-0, which pulled in > > glibc-mesboot. I'm testing out removing ld-wrapper-0 from %boot3-inputs > > to see if that's enough to make that final file build. Hopefully it'll > > also fix the final tar for i686, which I found was also failing for me. > > Interesting! Since my last email, I was able to fix the issue with file by > adding "--disable-xzlib" to the file package in gnu/packages/commencement.scm > (after discovering it when noticing "--disable-bzlib" was being passed to the > configure script), but hadn't sent in a patch yet because I hit a subsequent > test failure while building tar. I thought to disable xz support because I > traced the source of the glibc-mesboot libpthread.so in the error message to > xz-mesboot being detected by the configure script and linked in even though > file itself was being linked against a newer glibc and had no explicit > dependencies. (I think the error after upgrading to glibc 2.35 from 2.33 was > an abi compatibility between the newer glibc and the old pthread being pulled > in via xz-mesboot.) > > Cheers, > Kaelyn I ended up going a different route and moving xz from the finalize packages to an actual xz-final and replacing xz-bootstrap/xz-mesboot in %boot6-inputs. I also tracked down the issue in tar and adjusted the testsuite so it shouldn't be a problem on 32-bit systems. -- 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: Rust team branch
On Tue, Feb 14, 2023 at 05:36:13PM +0100, Andreas Enge wrote: > Am Tue, Feb 14, 2023 at 12:14:04PM +0200 schrieb Efraim Flashner: > > On behalf of the Rust Team™¹ we'd like to check our rust source tarballs > > for any hidden binaries² and to do a mass upgrade of many of the crates. > > Currently there are many crates queued up in the staging branch but we'd > > like to pull them out and run a rust-team branch. > > By "pull out" you mean revert them in staging and apply them on a separate > branch? That would also delay #61475 and maybe ease merging of the staging > branch. I was thinking more of cherry-picking them into a branch, not necessarily reverting them on staging. > Would it make sense to wait with the creation of the feature branch > until after the core-updates merge? Normally I'd say yes, but it might be a while until we can get core-updates merged in. > > As a project we haven't setup anything for starting the team-based > > branches and upgrades, and the Rust Team volunteers to go first. > > ¹ Help wanted > > Splendid! I suppose that increasing the team size beyond 1 would be > a first important goal, call out to volunteers! > > Andreas > > -- 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: Rust team branch (was Re: Discussion notes on releases and branches)
On Tue, Feb 14, 2023 at 09:36:46AM -0700, Katherine Cox-Buday wrote: > Efraim Flashner writes: > > > As a project we haven't setup anything for starting the team-based > > branches and upgrades, and the Rust Team volunteers to go first. > > Leo has attempted[1] to setup a branch for Go, but we're waiting to hear from > sysadmins on why there's a build error. > > [1] https://lists.gnu.org/archive/html/guix-devel/2023-01/msg00131.html Second is also good :) Also I don't think there's a lot of overlap between go and rust so we can probably have both going at the same time. -- 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: Architecture support [was: Re: Merging core-updates?]
On Tue, Feb 14, 2023 at 05:30:32PM +0100, Andreas Enge wrote: > Hello, > > Am Mon, Feb 13, 2023 at 12:56:45PM +0200 schrieb Efraim Flashner: > > Aarch64 and armhf are getting stuck at gcc-cross-boot0. > > I got to hello on my aarch64, which is very encouraging! I will have to > try again with your latest changes to core-updates, but am rather optimistic. It might just be my machines then. My pinebook pro doesn't have a lot of space available for building and my pine64 only has 2GB of ram. Also I made a typo in the tar fix, so I'll push a fix for that after I confirm that it actually skips the broken test. -- 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: Openjdk (was: Merging core-updates?)
On Wed, Feb 15, 2023 at 08:19:08PM +0100, Andreas Enge wrote: > Am Wed, Feb 15, 2023 at 07:51:56PM +0100 schrieb Andreas Enge: > > Actually the patch has already been applied to openjdk13, if I am not > > mistaken. So I do not understand how the source could be built in master > > then, while the exact same code (?!) fails on core-updates... > > Well, there is a somewhat hidden difference. > core-updates introduces > "openjdk-10-hotspot-pointer-comparison.patch" > "openjdk-10-hotspot-stack-size.patch" > to openjdk10. > > openjdk11 is a package of its own without the patch. > > openjdk12 uses the newly defined make-openjdk to start from openjdk11, > overwriting the source together with openjdk-10-hotspot-stack-size.patch > in core-updates, and without the patch in master. (And it uses an obscure > tarball instead of a git checkout - why?) > > openjdk13 has the same code in core-updates and master: > (define-public openjdk13 > (make-openjdk openjdk12 "13.0.13" > "0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji")) > So in core-updates it inherits the patch from openjdk12, in master > it does not (I think). And then I suppose it passes the patch on to all > its descendants. It's definitely possible that the master->core-updates merge messed with the package definitions and the inheritance and I didn't notice it. > The following seems to work and create source for openjdk13 and later: > (define-public openjdk13 > (make-openjdk openjdk12 "13.0.13" > "0pxf4dlig61k0pg7amg4mi919hzam7nzwckry01avgq1wj8ambji" > (source (origin > (inherit (package-source base)) > (patches '()) > > Okay to push if I manage to build current openjdk with it? Yeah, that's probably fine. > Is it necessary to keep all these version of openjdk and to bootstrap > version n with version n-1? Probably? I assume if you can cut some out that'd be ok. I'm pretty sure openjdk-11 and openjdk-17 are considered LTS by upstream so it would make sense to keep those specifically. -- 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: Building arm64 guix system image
On Fri, Feb 17, 2023 at 10:29:35AM +0200, Max Brieiev wrote:
> I want to run Guix on Apple M1 as a Qemu virtual machine.
>
> On the Mac machine I run arm64 dedian image. I installed there guix as a
> package manager. Now I am trying to create a guix system image to use
> with Qemu, but it fails.
>
> Here is what I do:
>
> max@debian:~$ guix system image --system=aarch64-linux -t qcow2
> ~/code/guix/gnu/system/examples/bare-bones.tmpl
> guix system: warning: Consider running 'guix pull' followed by
> 'guix system reconfigure' to get up-to-date packages and security updates.
>
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'...
> 100.0%
> The following derivations will be built:
> /gnu/store/dhknasynfsx9ffsv2m188mmhfvz4l1cl-grub-2.06.drv
> /gnu/store/875pz541zymv6vhl0hkfll151jv8sd2p-qemu-minimal-7.2.0.drv
> /gnu/store/2vbjnb0f6dzcnvvyaaqjzww0146fpwmj-openbios-qemu-ppc-1.1.drv
> /gnu/store/dclmdk80rbqqpix98vh6srhdbgscyiwb-qemu-7.2.0.tar.xz.drv
> /gnu/store/g9crxhl9j2pw35kwgx9bdcjg3jrvi77v-linux-libre-6.1.9.drv
> /gnu/store/blyj3j5v3p2lh6pj7mw81xjg58d1k4zb-shepherd-0.9.3.drv
> /gnu/store/r517qlsjsl877kpjfl9ixay9mzh0n923-grub-efi32-2.06.drv
> /gnu/store/pyv1w00f9c0q291qhi6y0911sqlvfcrv-grub-efi-2.06.drv
> /gnu/store/875pz541zymv6vhl0hkfll151jv8sd2p-qemu-minimal-7.2.0.drv
> /gnu/store/brzpisxg4dkvad07pd95riwn7c8559j6-genimage-15-1.ec44ae0.drv
>
> 1.0 MB will be downloaded
> alsa-utils-1.2.4 987KiB 4.5MiB/s 00:00 [##]
> 100.0%
> building
> /gnu/store/g9crxhl9j2pw35kwgx9bdcjg3jrvi77v-linux-libre-6.1.9.drv...
> building
> /gnu/store/2vbjnb0f6dzcnvvyaaqjzww0146fpwmj-openbios-qemu-ppc-1.1.drv...
> | 'build' phasebuilder for
> `/gnu/store/2vbjnb0f6dzcnvvyaaqjzww0146fpwmj-openbios-qemu-ppc-1.1.drv'
> failed with exit code 1
> build of
> /gnu/store/2vbjnb0f6dzcnvvyaaqjzww0146fpwmj-openbios-qemu-ppc-1.1.drv failed
> View build log at
> '/var/log/guix/drvs/2v/bjnb0f6dzcnvvyaaqjzww0146fpwmj-openbios-qemu-ppc-1.1.drv.gz'.
> cannot build derivation
> `/gnu/store/875pz541zymv6vhl0hkfll151jv8sd2p-qemu-minimal-7.2.0.drv': 1
> dependencies couldn't be built
> guix system: error: build of
> `/gnu/store/875pz541zymv6vhl0hkfll151jv8sd2p-qemu-minimal-7.2.0.drv' failed
>
>
> The relevant part of the build log shows the following errors:
>
> Building OpenBIOS for ppc
> Building...
> error:
>
> /gnu/store/gm5mbaxkqhzafwy0wnimrg53j884glxn-linux-libre-headers-5.10.35/include/asm/sigcontext.h:128:2:
> error: unknown type name ‘__u32’
> 128 | __u32 size; /* size in bytes of the extra space */
> | ^
>
> /gnu/store/gm5mbaxkqhzafwy0wnimrg53j884glxn-linux-libre-headers-5.10.35/include/asm/sigcontext.h:129:2:
> error: unknown type name ‘__u32’
> 129 | __u32 __reserved[3];
> | ^
>
> /gnu/store/gm5mbaxkqhzafwy0wnimrg53j884glxn-linux-libre-headers-5.10.35/include/asm/sigcontext.h:136:2:
> error: unknown type name ‘__u16’
> 136 | __u16 vl;
> | ^
>
> /gnu/store/gm5mbaxkqhzafwy0wnimrg53j884glxn-linux-libre-headers-5.10.35/include/asm/sigcontext.h:137:2:
> error: unknown type name ‘__u16’
> 137 | __u16 __reserved[3];
> | ^
> make[1]: *** [rules.mak:83: host/kernel/bootstrap.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> make[1]: Leaving directory
> '/tmp/guix-build-openbios-qemu-ppc-1.1.drv-0/source/obj-ppc'
> make: *** [Makefile:19: build] Error 1
> error: in phase 'build': uncaught exception:
> %exception #<&invoke-error program: "make" arguments: ("-j" "4")
> exit-status: 2 term-signal: #f stop-signal: #f>
> phase `build' failed after 0.2 seconds
> command "make" "-j" "4" failed with status 2
>
> I don't know where to look to fix this error. Please, help me.
>
> Also, I thought I could find somewhere arm64 guix build, but apparently
> there is none?
>
> I found only a raw image for Pinebook Pro:
> https://ci.guix.gnu.org/eval/196495
>
> But for some reason it says it is x86_64 system, and this confuses me.
>
> Thank you in advance.
I have two patches on the core-updates branch that should allow building
openbios-qemu-ppc from aarch64. I'll try cherry-picking them to master
and see if that allows building qemu-minimal.
--
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: Building arm64 guix system image
On Mon, Feb 20, 2023 at 11:31:04AM +0100, Roman Scherer wrote: > > Efraim Flashner writes: > > > > I have two patches on the core-updates branch that should allow building > > openbios-qemu-ppc from aarch64. I'll try cherry-picking them to master > > and see if that allows building qemu-minimal. > > Hi Efraim, > > that would be great. I'm looking forward to try them out. I ran out of space while building qemu so I'm waiting on the build farm¹ to see if qemu worked. Since qemu-minimal worked I pushed it upstream and current master should have that building now. I haven't tested building an image yet though. ¹ https://ci.guix.gnu.org/eval/211772 > Since we are already talking about arm64 here, do you have experience > with transparent huge pages on aarch64? > > I would love to get some feedback on this one: > > https://lists.gnu.org/archive/html/guix-patches/2023-02/msg00698.html > > Do you know if any of the aarch64 build machines configured with a page > size > 4K? If so, I think that patch could help building more packages > on that architecture. > > Thanks, Roman. I'm pretty sure they all use a 4K page size. From gnu/packages/aux-files/linux-libre/6.1-arm64.conf: CONFIG_ARM64_4K_PAGES=y # CONFIG_ARM64_16K_PAGES is not set # CONFIG_ARM64_64K_PAGES is not set It looks like they're set for 4K pages. I'm not sure if it can be set for more than one size at once. As for the transparent huge pages, I'm pretty sure back in 2017 when I disabled it in jemalloc it was fairly broken on aarch64 but I don't see a reason to not enable it now. -- 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: Building arm64 guix system image
On Tue, Feb 21, 2023 at 12:02:53AM -0500, Andrew Patterson wrote: > > On Mon, 2023-02-20 at 16:17+02, Efraim Flashner > wrote: > > > I ran out of space while building qemu so I'm waiting on the build farm¹ > > to see if qemu worked. Since qemu-minimal worked I pushed it upstream > > and current master should have that building now. I haven't tested > > building an image yet though. > > > > ¹ https://ci.guix.gnu.org/eval/211772 > > Thank you for fixing this! I'll close my bug report. Happy to help :) > It looks like the fix was just updating to a more recent commit; should I > close the issue I posted on github, then? We don't use github for issue tracking so I'm not sure which repo you're talking about... so it'd probably be a good idea to close it :D -- 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: Merging branch wip-haskell
On Wed, Feb 22, 2023 at 10:37:41AM +0100, Andreas Enge wrote: > Hello Lars, > > Am Wed, Feb 15, 2023 at 11:38:23AM +0100 schrieb zimoun: > > Feel free to merge. :-) > > +1, please go ahead! > > By the way, when building pandoc for my core-updates profile, I noticed > that ghc bootstrapping takes a terribly long time. Might there be a fleeting > chance to jump over some older releases? I believe in core-updates I've changed it so we go from 8.6 to 8.10. I think if we packaged 8.2 we could go from 7.10 -> 8.2 -> 8.6 -> 8.10, using 8.2 to replace 8.0 and 8.4. -- 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: Error booting aarch64 installation image
On Tue, Feb 21, 2023 at 10:06:41AM +0200, Max Brieiev wrote: > Hi Roman, > > Roman Scherer writes: > > > I think you need to use --image-type=efi-raw for this to work. > > Unfortunately, this doesn't build and produces yet another errors. > > > I actually installed my Guix system from another distro. I roughly > > followed this guide here: > > > > https://guix.gnu.org/blog/2019/guix-on-an-arm-board/ > > Thank you! I spent all day yesterday playing with this idea. > > And it actually works. For me the steps were like this: > > 1. Launch Debian ARM image. > 2. Install Guix on it as package manager > 3. Attach an empty qcow image as a storage device (/dev/vdb for me) > 4. Partition and format /dev/vdb > 5. Mount root and boot efi partitions. > 6. Edit file-system entries in lightweight-desktop.scm and save it as > /mnt/etc/config.scm > 7. Run: > guix system init /mnt/etc/config.scm /mnt > 8. Reboot > > And this works! > > Now I've just discovered in guix-cookbook that there is a special > linux-libre-arm64-generic kernel for ARM boards and that u-boot is > usually used to boot them. > > But in my case it works with grub and a default kernel. > > Are there any advantages of switching to linux-libre-arm64-generic > kernel? > I believe it mostly comes down to kernel configs. The regular linux-libre arm64 kernel uses the Guix kernel config. The linux-libre-arm64-generic build uses the upstream defaults instead of a configuration file. -- 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: Python
On Fri, Feb 24, 2023 at 07:08:44PM +0100, Lars-Dominik Braun wrote: > Hi Andreas, > > sorry, I can’t quite keep up with the Python issues on core-updates > right now :( > > > Yet another python failure: python-pathlib > this is a backport of Python’s built-in pathlib library. It should be > dropped as a dependency for all of these packages, since our Python is >= > 3.4 – the version pathlib was introduced into the standard library. And > then drop the package entirely. Do we have a list of packages in the python importer that can be removed from inputs? Like already exists for hackage (and maybe others)? -- 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: Qt in core-updates (was: KDE in core-updates)
On Sun, Feb 26, 2023 at 09:38:43PM -0500, kiasoc5 wrote: > On 2/26/23 18:43, Philip McGrath wrote: > > Hi, > > > > On Sunday, February 26, 2023 7:44:20 AM EST Andreas Enge wrote: > > > > > > In any case, I realised that we are still compiling most packages > > > (including > > > KDE) with Qt 5, which is seriously outdated (not maintained any more in > > > the > > > free version since May 2021). Qt 6.3 support will end in April 2023, that > > > of the current version Qt 6.4 in September 2023. So we have the work > > > carved > > > out for a (yet to be created) Qt/KDE team. > > > > > > > Note that KDE maintains a patch collection for Qt 5.15: > > https://community.kde.org/Qt5PatchCollection > > > > There was an announcement here: > > https://dot.kde.org/2021/04/06/announcing-kdes-qt-5-patch-collection > > > > Patches are exclusively backports of bugfixes that have already been > > committed > > to upstream Qt 6, except that patches for Qt 5.15 components removed in Qt 6 > > are also accepted. The patches are curated by a small group of KDE > > developers > > who also have commit privileges in the upstream Qt Project (as distinct from > > the Qt Company). > > > > I think out Qt 5 packages should be based on the KDE patch collection. > > > > The patches are maintained in Git repositories with the same structure as > > upstream Qt. They could be extracted with `git format-patch v5.15.3-lts- > > lgpl..origin/kde/5.15` and added to "gnu/packages/patches/", or we could > > just > > change the origins for Qt 5 to point to KDE's repositories, e.g. this one > > for > > qt-base: https://invent.kde.org/qt/qt/qtbase/-/tree/kde/5.15 > > The KDE patchset moves quickly and does not have tagged releases. If that > proves difficult we could also just bump the QT5 version to 5.15.8, which is > freely available. This is something we should probably do anyway. We should also try to keep qtwebengine patched as much as possible, since it is a web engine :) -- 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: Oniro or Guix on Zephyr kernel?
On Fri, Feb 24, 2023 at 01:36:06PM -0500, Mitchell Schmeisser via Development of GNU Guix and the GNU System distribution. wrote: > jbra...@dismail.de writes: > > >> Guix System, 1 Gig of ram, etc, due to the package builder and Guix/Nix > >> daemon? If it was possible > >> to declare an instance of Guix System that did not include those and only > >> used cross-compiled > >> packages, could some portion of Guix System function in a similar way as > >> Oniro, or is that a > >> nonsense question? > > What I understand your question to be is "Can we use Guix to describe an > embedded operating system which does not run Guix?" and I think the > answer is probably. I don't think the guix daemon is technically required > for the shepherd to boot (being the daemon is a shepherd process > itself). I can answer this. I built a one-off Guix image of gparted and it doesn't have the guix-daemon service included. > I don't think it's a good idea because you need the daemon in order to > use `guix deploy`. Otherwise you have to make an installation image and > it can become "involved." If you were willing to forgo `guix deploy` (and guix install, and really any package management) and just reflash it every time then the memory constraints go down to whatever the running programs require. -- 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: Feedback on indentation rules (was: [PATCH 0/5] Add support for the RPM format to "guix pack")
On Thu, Feb 23, 2023 at 05:20:55PM -0500, Maxim Cournoyer wrote:
> -CC bug#61255
> +CC guix-devel
>
> Hi Ludovic and guix-devel readers,
>
> Ludovic Courtès writes:
>
> > Hi,
> >
> > Maxim Cournoyer skribis:
> >
> >> Ludovic Courtès writes:
> >>
>
> [...]
>
> >>> I’m not convinced by the indentation rule for ‘gexp->derivation’ added
> >>> in 82daab42811a2e3c7684ebdf12af75ff0fa67b99: there’s no reason to treat
> >>> ‘gexp->derivation’ differently from other procedures.
> >>
> >> The benefit I saw was that writing
> >>
> >> (gexp->derivation the-name
> >> #~(begin
> >> (the
> >>(multi-line
> >> (gexp)
> >
> > I understand, but you know, it’s best to avoid unilaterally changing
> > established conventions. :-)
> >
> > If and when there’s consensus about this change, (guix read-print)
> > should be updated.
>
> OK. I'm not against soliciting more opinions; I'm CC'ing guix-devel,
> hoping some opinionated individuals tip in on this 2021
> 82daab42811a2e3c7684ebdf12af75ff0fa67b99 commit, more specifically, the
> part that change the indentation rules for .dir-locals.el like this:
>
> --8<---cut here---start->8---
> + (eval . (put 'gexp->derivation 'scheme-indent-function 1))
> --8<---cut here---end--->8---
>
> In the same spirit there was also
> b1c25e2ce364741d1c257d3bb3ab773032807a80 (".dir-locals.el: Add
> indentation rule for computed-file.") made more recently (last month).
>
> The idea was to be able to format gexp->derivation like this:
>
> --8<---cut here---start->8---
> (gexp->derivation "check-deb-pack"
> (with-imported-modules '((guix build utils))
> #~(begin
> (use-modules (guix build utils)
>(ice-9 match)
>(ice-9 popen)
>(ice-9 rdelim)
>(ice-9 textual-ports)
>(rnrs base))
> [...]
> --8<---cut here---end--->8---
>
> Rather than like this:
>
> --8<---cut here---start->8---
> (gexp->derivation "check-deb-pack"
> (with-imported-modules '((guix build utils))
> #~(begin
> (use-modules (guix build utils)
>(ice-9 match)
>(ice-9 popen)
>(ice-9 rdelim)
>(ice-9 textual-ports)
>(rnrs base))
> --8<---cut here---end--->8---
>
> (or having to use another 'builder' variable, for example).
>
> What do you all think?
The second one is wy to indented. For myself I sometimes end up
wrapping the lines (although I don't love it) so it looks like this:
(gexp->derivation
"check-deb-pack"
(with-imported-modules '((guix build utils))
#~(begin
(use-modules (guix build utils)
(ice-9 match)
(ice-9 popen)
(ice-9 rdelim)
(ice-9 textual-ports)
(rnrs base))
--
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
universal aarch64/riscv64 images
I've been thinking some about how we create our disk images for aarch64
devices and how we'll eventually create images for riscv64 devices.
Currently we use u-boot to load extlinux to boot linux. I propose we use
u-boot with its EFI interface to load grub-efi to boot linux.
Major benefit of this is that we can create one generic aarch64 image
using raw-with-offset to create the image and then ship a separate
script to flash either the SD card or an SPI chip or whatever someone
wants. We also don't need to reflash u-boot at every reconfigure (I
couldn't follow the code well enough to see if that's currently the
case), just regenerate extlinux or grub-efi like we do on x86_64.
Currently here's the script to install u-boot on the disk image for a pine64:
(define install-allwinner64-u-boot
#~(lambda (bootloader root-index image)
(let ((spl (string-append bootloader
"/libexec/u-boot-sunxi-with-spl.bin"))
(u-boot (string-append bootloader
"/libexec/u-boot-sunxi-with-spl.fit.itb")))
(write-file-on-device spl (stat:size (stat spl))
image (* 8 1024))
(write-file-on-device u-boot (stat:size (stat u-boot))
image (* 40 1024)
And in the OS config:
(bootloader (bootloader-configuration
(bootloader u-boot-pine64-lts-bootloader)
(targets '("/dev/vda"
This would transition to (work in progress):
(define install-allwinner64-u-boot
#~(lambda (bootloader root-index image)
(let ((spl (string-append bootloader
"/libexec/u-boot-sunxi-with-spl.bin"))
(u-boot (string-append bootloader
"/libexec/u-boot-sunxi-with-spl.fit.itb")))
(write-file-on-device spl (stat:size (stat spl))
image (* 8 1024))
(write-file-on-device u-boot (stat:size (stat u-boot))
image (* 40 1024)
;; This needs to be fixed up to actually work!!
;; To be run (as root): 'u-boot-installer-pine64-lts /dev/sda'
(define-public u-boot-installer-pine64-lts
(program-file "u-boot-installer-pine64-lts"
#~((let ((bootloader u-boot-pine64-lts)
(image $1)))
#$(install-allwinner-u-boot
(bootloader (bootloader-configuration
(bootloader grub-efi)
(targets '("/dev/vda"
(extra-special-file `(("/sbin/flash-u-boot" ,u-boot-installer-pine64-lts)))
--
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
rust-team cuirass build
The Rust Team has been hard at work updating the rust compiler and a number of rust packages. We've tested a number of packages¹ to ensure that everything looks okay. Real world testing has occurred on x86_64 and has started on riscv64 but we'd like to request that a job be added to cuirass so we can make sure that everything builds nicely on the build farm and on the other architectures. Quick stats for the branch: 404 commits by 4 people. 181 packages updated 50 packages removed 155 new packages rust updated to 1.67. '#:skip-build? #t' no longer breaks the 'package phase. librsvg updated to 2.54.5. gdk-pixbuf updated to 2.42.10. rav1e updated to 0.6.3. tealdeer updated to 1.6.1. ¹ librsvg -e '(@@ (gnu packages gnome) librsvg-bootstrap)' rav1e rust-cbindgen@0.23 ripgrep tealdeer fd newsboat -- 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: bug#61894: [PATCH RFC] Team approval for patches
On Tue, Mar 07, 2023 at 01:29:51PM -0500, Maxim Cournoyer wrote: > Hi Simon, > > Simon Tournier writes: > > > Hi, > > > > On Tue, 07 Mar 2023 at 11:36, Andreas Enge wrote: > > > >> 1) Every current and potential new package is covered by a team. > >> 2) Every team has at least 3 members, better yet 4 or 5. > >>3 members would make it possible that even if one of them is on vacation > >>or otherwise busy a patch could be pushed without this additional one > >>week if the other 2 agree. > > > > It would help if being committer implies appearing at least in one team, > > no? > > > > Currently in etc/teams.scm.in, I count 26 members and 20 are committers > > over the 48 ones. No blame. :-) > > If most committers end up being team members, aren't we back to where we > currently stand? It seems the original motivation here is to add some > extra control/guards against undesirable commits landing in the core of > Guix. If a committer that previously landed such commits joined the > core team (e.g., myself), it seems to me the situation would be little > changed: My understanding was that it would help people feel more ownership over a portion of the code, allowing others to tag them explicitly for code review touching their area of expertise and allowing them to perhaps "pay less attention" to areas where they are less sure. The second part works better when all areas are covered by a team, but in practice I feel it was already happening, judging by our large backlog of patches. > 1. Our pool of reviewers would likely continue to be spread too thin. > > 2. The 2 weeks time window would quickly slip, even with a team looking > at a more focused backlog, or the reviews would only be of the kind "I > think that's not what we want" without more time or energy to offer the > kind of concrete insights that can be turned into action for the > submitter. > > 3. The team member might be tempted to take their chance and merge their > change with little to no feedback, or feedback they perceived > insufficient or not actionable enough to justify keeping their > submission in limbo for longer. > > I think the main problem we have is social, not organizational. There's > little incentive to jump into the laborious review process compared to > hack on something we like in our free time. We need to promote and > value review work more, without making it feel like a compulsory chore. > That's a great challenge to solve for a project that's driven by > volunteers. > > I'll venture a suggestion to explore: adding enticements to review (some > playful guidelines such as "while waiting for your 2 weeks review > period, please try to review twice as many other submissions that have > been patiently waiting on the patches tracker :-)", or some stats > crunched and advertised periodically to guix-devel or even our to our > blog about our top reviewers, etc.). > > -- > Maxim -- 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: The 🐑 Shepherd gets a service collection
On Mon, Mar 13, 2023 at 05:11:34PM +0100, Ludovic Courtès wrote: > Hello Guix! > > I pushed some changes yesterday that confirm that the Shepherd paves the > way for init system innovation, synergistic cross-domain fertilization, > and delimited continuations: > > > https://git.savannah.gnu.org/cgit/shepherd.git/log/?id=31d21fa083872d500c016b6b3b2587d25510702d > > 31d21fa * Add REPL service. > cd6f3fb * comm: Add 'open-server-socket'. > c64804f * Add resource monitoring service. > > These new services are built into shepherd, allowing users to control it > and to fiddle with it. The REPL is functional but of course a bit > bumpy: you’d better know what you’re doing. > > I imagine we could develop more convenient services like this, such as a > basic command scheduler similar to the ‘at’ command, and a syslogd > implementation. The latter could be nice for a couple of reasons: > logging would happen from the start and till the end (an improvement > over the external syslogd process), and it could let us provide a nicer > user interface to view logs (taking inspiration from that of > ‘journalctl’). > > Thoughts? Ideas? I always imagined an 'at' command being part of mcron. Does this mean we should look forward to shepherdd-mcron? > PS: It just occurred to me that we might as well rename the new > (shepherd service …) hierarchy to (shepherd sheep …) or even > (shepherd 🐑 …). How does shepherd handle emojis for system symbols? -- 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: State of core-updates
On Wed, Mar 15, 2023 at 08:54:55AM +0100, Andreas Enge wrote:
> Am Tue, Mar 14, 2023 at 08:56:38PM -0400 schrieb Maxim Cournoyer:
> > OK! We could probably merge staging into master and be done already.
>
> We should build it first. The last time I tried, there was a showstopper bug.
>
> Here it is:
> I tried to build staging for my profile on x86_64, but it failed with
> a dependency of ffmpeg, rust-rav1e-0.5.1. There is a newer version 0.6.3,
> but I did not simply update it, since the package looks particularly
> complicated, containing a phase:
> (add-after 'configure 'force-rust-edition-2018
>(lambda* (#:key vendor-dir #:allow-other-keys)
> ;; Force all the dependencies to not be higher than edition 2018.
> (with-fluids ((%default-port-encoding #f))
>(substitute* (find-files vendor-dir "Cargo.toml")
> (("edition = \\\"2021\\\"") "edition = \"2018\"")
> and many other changes.
>
> Leo suggested to remove the dependency as non-essential. On the other
> hand, I think the problem does not occur in core-updates, so one should
> have a look.
>
> And there may be other problems, too.
>
> And of course this implies merging the merged into master staging back to
> core-updates, which may create problems we will have to deal with later.
> But yes, I would be happy to merge staging first; this was my initial
> suggestion, before we somehow collectively flocked to core-updates :)
>
This and other bugs are fixed on the rust-team branch. Once I figure out
how to compare it against master and force rust to build for aarch64
we'll be nearly there.
--
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: Branch and release process (was: gnu: inetutils: Update to 2.4.)
On Tue, Mar 14, 2023 at 11:30:52PM -0400, Maxim Cournoyer wrote: > Hi, > > Leo Famulari writes: > > > On Tue, Mar 14, 2023 at 09:10:33PM -0400, Maxim Cournoyer wrote: > >> Felix Lechner writes: > >> > With the core-updates process now abandoned, I retitled the issue to > >> > >> Could you share the reference of that? I'm not against it, but our > >> currently documented process still mention the good old staging and > >> core-updates branches. > > > > At the Guix Days in February, we discussed the branching workflow and > > reached a rough consensus that for non-core packages (defined in > > %core-packages), we should try to adopt a more targeted "feature branch" > > workflow. That's actually what we used to do, before we outgrew our old > > build farm, after which we were barely able to build one branch at a > > time (IIRC, we would stop building master in order to build core-updates > > or staging). > > > > The discussion was summarized by Andreas here: > > > > https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00066.html > > Thanks! I had missed it. It sounds promising! > > > Currently we are demo-ing this workflow in the wip-go-updates branch and > > go-team Cuirass jobset. > > So the review happens first on the ML, then the changes land to the team > branch, and then finally the feature branch gets merged to master? If > the review has already happened and the package been tested (and built > by QA), why is a feature branch needed? So we can group a couple of larger related changes together. > > My hope is that we can rewrite the relevant documentation in the coming > > months, as we learn from these early efforts. > > OK! Thanks for allowing me to catch up! > > -- > Thanks, > Maxim > -- 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: Gnome dans core-updates
On Mon, Mar 20, 2023 at 06:11:56PM +0100, Andreas Enge wrote: > Am Mon, Mar 20, 2023 at 06:00:37PM +0100 schrieb Andreas Enge: > > If it is indeed a solution... Here is how far I got, patch attached. > > Actually it was updated by Efraim in master on March 9. Indeed, it was needed for qemu-minimal to build on riscv64. > Time to merge master into core-updates, I would say. Often a good idea :) -- 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: Zig on core-updates
On Tue, Apr 11, 2023 at 07:11:47AM +0200, Pjotr Prins wrote: > > On Mon, Apr 10, 2023 at 05:56:52PM +0200, Andreas Enge wrote: > > Am Fri, Mar 17, 2023 at 09:33:31AM + schrieb pukkamustard: > > > A hunch: This might have something to do with Zig not properly > > > supporting glibc 2.35: https://github.com/ziglang/zig/issues/12808 > > > > Thanks, this looks like a good explanation of the problem, but I do not > > quite see what could be a solution... I see a string of issues of the form > > "add support for targeting glibc ..." > >https://github.com/ziglang/zig/issues/12808 > >https://github.com/ziglang/zig/issues/12809 > >https://github.com/ziglang/zig/issues/14798 > > but all of them are open. > > > > We may have to do without zig in the foreseeable future... > > > > They just added a tag for the next release. We can wait. We may have to backport whatever fix they do, it looks like 0.11 is going to use their new bootstrap chain, with a pre-compiled zig wasm binary. -- 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
[PATCH 0/8] Remove mysql
I saw that a fix was applied to mysql on core-updates to have it build with openssl-1.1, and I figured that rather than have a version that was several years out of date (and surely had many many security vulnerabilities) it would be better to try to just remove it. `mariadb:dev` provides the `mysql_config` binary that some packages search for so I used it as a drop-in replacement. Nothing seemed broken to me after building some packages, so to the best of my knowledge of these disparate packages and languages all is fine. Efraim Flashner (8): gnu: sysbench: Build with mariadb. gnu: ghc-mysql: Build with mariadb. gnu: neko: Build with mariadb. gnu: inspircd: Build with mariadb. gnu: ulogd: Build with mariadb. gnu: opensmtpd-extras: Build with mariadb. gnu: sbcl-clsql: Build with mariadb. gnu: cl-clsql: Build with mariadb. gnu/packages/benchmark.scm | 9 + gnu/packages/haskell-xyz.scm | 4 ++-- gnu/packages/haxe.scm| 3 ++- gnu/packages/irc.scm | 4 ++-- gnu/packages/linux.scm | 6 +++--- gnu/packages/lisp-xyz.scm| 18 ++ gnu/packages/mail.scm| 4 ++-- 7 files changed, 22 insertions(+), 26 deletions(-) base-commit: 2d06dfc050114dba44e791d8decc8eaa705fee01 -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted
Re: Erlang: dirname: command not found
On Sun, Apr 02, 2023 at 12:56:05AM +, jgart wrote: > jgart@guixer ~/erl_sandbox$ guix shell erlang --container > jgart@guixer ~/erl_sandbox [env]$ erlc > /gnu/store/i98q2wgmsvvfck51f830c4aqxrygjlb2-profile/bin/erl: line 22: > dirname: command not found > /gnu/store/i98q2wgmsvvfck51f830c4aqxrygjlb2-profile/bin/erl: line 52: > basename: command not found > jgart@guixer ~/c_sandbox [env]$ erl > /gnu/store/i98q2wgmsvvfck51f830c4aqxrygjlb2-profile/bin/erl: line 22: > dirname: command not found > /gnu/store/i98q2wgmsvvfck51f830c4aqxrygjlb2-profile/bin/erl: line 52: > basename: command not found > > Hi, > > Is the above expected? Sounds like it should be wrapped with coreutils and maybe some more packages. -- 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
[Rust Team] Status post core-updates merge
Now that core-updates has been merged into master it's time for a status update from the rust team. Currently rust supports (in the order of gaining support) x86_64, aarch64 and riscv64. GDB-11 doesn't currently build on aarch64 or riscv64, so we're removing gdb-11 entirely and using a new gdb-12 as gdb/pinned for the test suite. This is expected to fix rust building on aarch64. rust-bootstrap currently fails to build on riscv64. I've been testing solutions by building on an x86_64 machine to see what builds pass and what fails, and I think I've found a solution with minimal changes. Once I'm able to successfully build rust-bootstrap on x86_64 and riscv64 I'll push the update to the rust-team branch and let the CI build it out. As a quick overview, this push moves our rust package to rust-1.67 and updates many of our rust packages. We've had some more unbundling of bundled library sources and precompiled libraries and updated a number of rust programs, mostly so they build with the newer version of rust. -- 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: [Rust Team] Status post core-updates merge
On Thu, Apr 27, 2023 at 07:06:29PM +0200, Josselin Poiret wrote: > Hi Efraim (and the rest of the Rust team), > > Efraim Flashner writes: > > > Now that core-updates has been merged into master it's time for a status > > update from the rust team. > > > > Currently rust supports (in the order of gaining support) x86_64, > > aarch64 and riscv64. GDB-11 doesn't currently build on aarch64 or > > riscv64, so we're removing gdb-11 entirely and using a new gdb-12 as > > gdb/pinned for the test suite. This is expected to fix rust building on > > aarch64. > > Is there any hope for the other architectures? I'm thinking i686 > mostly, but s390x, powerpc and mips are all on the radar. There hasn't been much development in the mrustc repo for the past few months and I believe the issues blocking i686 (needs too much memory at once) is still present. As far as powerpc64le, it does pretty well with mrustc but doesn't get through the whole bootstrap yet. Another option would be to work on the cross-compiling ability of the cargo-build-system, then you could at least cross compile to them. I will point out that s390x and mips aren't actually supported in Guix currently. > > rust-bootstrap currently fails to build on riscv64. I've been testing > > solutions by building on an x86_64 machine to see what builds pass and > > what fails, and I think I've found a solution with minimal changes. > > > > Once I'm able to successfully build rust-bootstrap on x86_64 and riscv64 > > I'll push the update to the rust-team branch and let the CI build it > > out. > > > > As a quick overview, this push moves our rust package to rust-1.67 and > > updates many of our rust packages. We've had some more unbundling of > > bundled library sources and precompiled libraries and updated a number > > of rust programs, mostly so they build with the newer version of rust. > > Very impressive! I only watch from afar and complain about the rust > situation whenever I can, but this is giving me hope. With Rust getting > further and further down into the dependency chain, this is vital work, > and you all seem to be handling it very well. > > I'm also curious, since you're "early adopters": how are you managing > with the team workflow? Any tips, remarks or impressions that you could > share with other teams? Speak in the plural and no one will realize it's a team of one ;) I'm thinking of tagging the rust stuff with [rust team] so it stands out and is easily searchable. if/when I send patches for other teams I'll probably tag those too and hope it catches on. -- 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
ocaml bootstrap (was Re: Core-updates merge)
On Fri, Apr 28, 2023 at 04:17:40PM +0200, Simon Tournier wrote: > Hi Andreas, > > On mar., 25 avril 2023 at 16:09, Andreas Enge wrote: > > > - OCaml could be simplified by dropping version 4.07 (Julien Lepiller). > > Well, 4.07 is the version that is de-bootstrapped, i.e. bootstrapped > using ’camlboot’ via Guile – for details see [2]. > > However, higher versions (4.09, 4.14, 5) does not use this seed and thus > they are not de-bootstrapped. Well, I do not know the status upstream; > from my point of view, we have two options: > > a) Agree with other distros and OCaml folks to rely on a common OCaml > 4.07 bootstrapped using camlboot and then use this OCaml 4.07 as the > seed for the subsequent versions. Somehow having a way to verify the > current OCaml compiler without running again and again via camlboot. > > b) Build ourselves a chain from 4.07 bootstrapped with camlboot to > modern OCaml compilers. However, each time we modify one dependency of > camlboot, it means rebuild the complete chain. Well, bootstrapping via > camlboot can be very slow and I do not know if we have the resources > for non-x86_64 architecture. Here, the list of the emerged > dependencies: I think similarly to the very slow *-mes part of the bootstrap chain, we have to realize that some parts are just very slow. (A vote for b) I built camlboot once on aarch64, probably a year ago. IIRC it took more than 24 hours. I will say that it is doable without needing 8GB of ram, which is also a limiting factor for the slow architectures. > $ guix graph camlboot -t bag-emerged | grep label | cut -d'=' -f2 > "camlboot@0.0.0-1.45045d0", shape > "guile@3.0.9", shape > "pkg-config@0.29.2", shape > "tar@1.34", shape > "gzip@1.12", shape > "bzip2@1.0.8", shape > "file@5.44", shape > "diffutils@3.8", shape > "patch@2.7.6", shape > "findutils@4.9.0", shape > "gawk@5.2.1", shape > "sed@4.8", shape > "grep@3.8", shape > "xz@5.2.8", shape > "coreutils@9.1", shape > "make@4.3", shape > "bash-minimal@5.1.16", shape > "ld-wrapper@0", shape > "binutils@2.38", shape > "gcc@11.3.0", shape > "glibc@2.35", shape > "glibc-utf8-locales@2.35", shape > "libffi@3.4.4", shape > "bash-minimal@5.1.16", shape > "libunistring@1.0", shape > "libgc@8.2.2", shape > > c) Fix the dependencies of camlboot. Looking at camlboot, there's a native input of guile-3.0. Unless we want to bootstrap using some of the boot0 packages or actually find the minimum set of packages needed and remove the rest that are brought in by implicit-inputs (recursively) I think it's already as small as possible. > > Well, it seems a separated discussion but it echoes the recent blog post [3] > about “The Full-Source Bootstrap”. :-) > > 2: > https://10years.guix.gnu.org/video/camlboot-debootstrapping-the-ocaml-compiler > 3: > https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/ > > > Cheers, > simon > > > -- 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: #:tests? #f
On Mon, May 01, 2023 at 05:48:47AM +, jgart wrote: > hi, > > wdyt > > `guix build qutebrowser --disable-tests` > > or bloat? Need more context. We already have `guix build qutebrowser \ --without-tests=qutebrowser` -- 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
rust-team branch merged
I've merged the rust-team branch into master. I've dropped rust for aarch64-linux again for now until I can get it built on cuirass so it's not holding up the branch any longer. Unfortunately I forgot about the mesa update earlier so there's more rebuilds than I 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: rust-team branch merged
On Tue, May 09, 2023 at 09:33:46AM +0100, Christopher Baines wrote: > > Efraim Flashner writes: > > > I've merged the rust-team branch into master. I've dropped rust for > > aarch64-linux again for now until I can get it built on cuirass so it's > > not holding up the branch any longer. > > Do you know if it actually doesn't build, or whether it's just a > berlin/Cuirass issue? I've managed to build it myself on my own pinebook pro and used that to build librsvg and python-cryptography. riscv64-linux actually needs more work to fix so it's building again. > While I appreciate the waiting for the build farm to catch up, I think > that in the case of aarch64-linux substitutes from ci.guix.gnu.org, > whatever problems are causing the substitute availability to be so low > aren't really going to be helped by waiting, something more is probably > needed. The way its currently setup all we need to do is re-add aarch64-linux to the supported-systems of rust-bootstrap and it'll be enabled again, and build successfully eventually. -- 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: rust-team branch merged
On Tue, May 09, 2023 at 02:22:36PM +0100, Christopher Baines wrote: > > Andreas Enge writes: > > > Hello, > > > > Am Tue, May 09, 2023 at 11:54:00AM +0300 schrieb Efraim Flashner: > >> The way its currently setup all we need to do is re-add aarch64-linux to > >> the supported-systems of rust-bootstrap and it'll be enabled again, and > >> build successfully eventually. > > > > I am confused by what happened; did you disable rust on aarch64 for > > everyone, > > or just building on the farm? If the first, that sounds like a pity, since > > at worst people can still compile packages by themselves. > > Yeah, while I appreciate paying attention to what substitutes are > available, I think we should add aarch64-linux back to the supported > systems, regardless of what ci.guix.gnu.org is doing. Thank you all for the encouragement and feedback. I've re-enabled aarch64 for rust. -- 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: RISC-V (riscv64-linux) substitutes are coming
On Tue, May 09, 2023 at 02:40:21PM +0100, Christopher Baines wrote: > Hey! > > Almost a year ago now [1] I mentioned that I had received a HiFive > Unmatched board, but I hadn't got it doing anything yet. > > 1: https://lists.gnu.org/archive/html/guix-devel/2021-06/msg00104.html Some would say that's almost two years ago! > In the last few days I've made some time to take a look at it again and > try to get it connected up to the bordeaux build farm. > > This has been somewhat successful, you should be able to see the machine > (named rochor) on the prototype activity viewer [2]. > > 2: https://bordeaux.guix.gnu.org/activity > > Unfortunately it seems a bit stuck trying to upload the build results > back to the coordinator due to the suspendable ports issues in > guile-gnutls, but that should be fixed in the latest release so > hopefully I'll be able to deploy that fix soon. > > It's also just currently a bare board hooked up to a spare power supply > I have. I'll try and cost up a dedicated power supply plus case for it, > and if anyone has suggestions for minimal mini-itx compatible cases, > please let me know! > > This is a start, but more hardware will be needed to keep up with the > master branch, plus testing patches and other branches, so if you have > hardware to hand, or know of hardware available for purchase that might > be suitable, that would be really useful to know about. That's really exciting! I've been having good luck with the visionfive1 as a build machine. My visionfive2 gets a little hot and I'm looking at getting a desk fan to blow at it and some of the other boards that get a bit hot while building. -- 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: RISC-V (riscv64-linux) substitutes are coming
On Tue, May 09, 2023 at 06:24:11PM +0300, Aleksandr Vityazev wrote: > Hi, > > On 2023-05-09, 15:22 +0100, Christopher Baines wrote: > > > Efraim Flashner writes: > > > >> [[PGP Signed Part:Undecided]] > >> On Tue, May 09, 2023 at 02:40:21PM +0100, Christopher Baines wrote: > >>> Hey! > >>> > >>> Almost a year ago now [1] I mentioned that I had received a HiFive > >>> Unmatched board, but I hadn't got it doing anything yet. > >>> > >>> 1: https://lists.gnu.org/archive/html/guix-devel/2021-06/msg00104.html > >> > >> Some would say that's almost two years ago! > > > > Indeed, I got my maths wrong! Time is really getting on :/ > > > >>> In the last few days I've made some time to take a look at it again and > >>> try to get it connected up to the bordeaux build farm. > >>> > >>> This has been somewhat successful, you should be able to see the machine > >>> (named rochor) on the prototype activity viewer [2]. > >>> > >>> 2: https://bordeaux.guix.gnu.org/activity > >>> > >>> Unfortunately it seems a bit stuck trying to upload the build results > >>> back to the coordinator due to the suspendable ports issues in > >>> guile-gnutls, but that should be fixed in the latest release so > >>> hopefully I'll be able to deploy that fix soon. > >>> > >>> It's also just currently a bare board hooked up to a spare power supply > >>> I have. I'll try and cost up a dedicated power supply plus case for it, > >>> and if anyone has suggestions for minimal mini-itx compatible cases, > >>> please let me know! > >>> > >>> This is a start, but more hardware will be needed to keep up with the > >>> master branch, plus testing patches and other branches, so if you have > >>> hardware to hand, or know of hardware available for purchase that might > >>> be suitable, that would be really useful to know about. > >> > >> That's really exciting! > >> > >> I've been having good luck with the visionfive1 as a build machine. My > >> visionfive2 gets a little hot and I'm looking at getting a desk fan to > >> blow at it and some of the other boards that get a bit hot while > >> building. > > I also use visionfive2 as my build machine. Quite happy with it. I have > a fairly large heatsink installed without a fan, the temperature does > not exceed 60 degrees at full load. Where did you get the heatsink from? Something generic or from the makers of the visionfive2? > > Cool, well let me know if any of those can be hooked up to the build > > farm. It's quite easy and obviously you can still use them (and just > > stop the build coordinator agent) if you need to. > > > > I'd give it a try. Although now there is only a 256GB ssd plugged in and > no dedicated ip address. I don't know how the coordinator works, maybe > it doesn't matter, I need to see how it all works. > > -- > Best regards, > Aleksandr Vityazev -- 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: Tooling for branch workflows
On Wed, May 10, 2023 at 01:39:05PM +0200, Andreas Enge wrote: > Hello all, > > the title says it all, I wish to share some conclusions from working on > the core-updates merge. Clearly our tooling could be improved for the task; > there was some flying by night without instruments, and in the end I > merged the branch without being really able to tell how it compared > to master... (You may also blame it partially on my lack of patience.) > Having feature branches may or may not make things a bit easier, but it > will definitely not solve the problems. I have to agree with this sentiment. I merged the rust-team branch with the gut-feeling that nothing new was broken, but I wasn't really sure how to compare the two. > This mail is also of course a bit politically sensitive: It may look like > I am complaining about other people's work, who are volunteers and do what > they can, without offering to work on the code myself. So as a preamble, > let me express my gratitude to the few people who have been working > tirelessly on our tooling and contributing to our infrastructure, without > whom big code changes like we did on core-updates (and now on feature > branches) would simply be impossible; their work is vital to the project > and often not very visible. If I am critical, it is not to diminish their > work, but to discuss about a positive path forward; and I hope more people > will find the motivation to do infrastructure work, which I think will be > decisive for the success of Guix (together with policy and organisational > questions). I too wish to thank everyone for all the work they have done. I would especially like to thank those who work on cuirass and the Guix build coordinator, neither of which I've worked on but which are fundamental underpinnings of Guix. -- 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: What's needed to get things building for i586-gnu (the hurd) post core-updates?
On Sun, May 14, 2023 at 05:55:20PM +0200, Josselin Poiret wrote: > Hi Ludo and Chris, > > Ludovic Courtès writes: > > > Hello! > > > > Probably the main issue is that childhurds now fail to boot: > > > > https://issues.guix.gnu.org/62307#23 > > > > We can still build “new” i586-gnu binaries on an “old” childhurd, of > > course, but to me that’s doing that is less of a priority. > > [1] should fix this. We have at least three important failures > regarding native compilation now: > > - coreutils doesn't build. This is because our bootstrap glibc doesn't > contain all the kernel headers, and coreutils tries to use some of > them directly. This should be fixable by adding an additional > bootstrap input for the Hurd with the missing kernel sources, I'm > trying to get one right now. > > While discussing with janneke, we also figured out that > coreutils-boot0 was probably unneeded as it's only used to rm a file > in an origin later on that could be removed with pure Guile. That > would be a world rebuild though so let's leave that for later. If all you need is to remove coreutils-boot0 from the origin then you could create a similar boot0 package specifically for the hurd and make the fix there, and then use the current package or your new one as an input in later packages based on the architecture. > - m4 and findutils both have some failing tests, and they seem to be > crashing. I haven't investigated this yet. > > [1] https://issues.guix.gnu.org/63501 > > -- > Josselin Poiret -- 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: Defaulting to MAC-based names for network interfaces
On Sun, May 14, 2023 at 02:52:26PM -0700, Felix Lechner via Development of GNU
Guix and the GNU System distribution. wrote:
> Hi everyone,
>
> Upon personal reflection, a declarative operating system like Guix probably
> ought to use only predictable interface names.
>
> More details about this proposal, including the text below, are
> available in Bug#63508.
>
> While shorter names like 'eno1' offer an indisputable convenience and beauty
> when typing on the command line, administrators in Guix are unlikely to do so
> due to the declarative configuration system.
>
> Some system services may explicitly refer to interface names in their
> configuration. They would also benefit from the predictable and constant
> nature of MAC-based names.
>
> The latter is particularly relevant on multi-homed machines, i.e. those with
> more than one network connection.
>
> A MAC-based interface name as issued by 'eudev' looks like this:
>
> enx0123456789af (fictitious)
>
> The commit in Bug#63508 was deployed on two production machines. The
> migration to MAC-based interface names took place without issues. A
> second reconfiguration was used to add the new interface name in
> services tha needed it. The second step can be skipped, since the name
> is known with certainty in advance.
>
> The current naming scheme is less desirable because some services may silently
> refuse to start after equipment was added or removed. A removal may take
> place, for example, when something broke or when equipment was sold.
>
> The device enumeration may also change when a CMOS battery fails and system
> options are lost. In the author's option, Guix should not depend on BIOS
> enumeration for device names.
>
> In the author's case, the name of the sole network interface changed from
> enp3s0 to enp4s0 when a PCIe disk controller (a SAS host-based adapter) was
> installed. As a result, OpenSMTPd silently failed to start.
>
> This commit switches 'eudev' from the standard naming order
>
> ID_NET_NAME_ONBOARD
> ID_NET_NAME_SLOT
> ID_NET_NAME_PATH
>
> to ID_NET_NAME_MAC, which is always available. [1]
>
> The author initially attempted to achieve the same result via
>
> (udev-rules-service 'net-name-mac
> (udev-rule
> "01-net-name-mac.rules"
> "SUBSYSTEM==\"net\", ACTION==\"add\", NAME=\"$env{ID_NET_NAME_MAC}\"
> ")))
> but that did not work. While the situation was not examined exhaustively, it
> was not clear that udevadm can currently work because the standard command to
> test udev setups: [2]
>
> $ udevadm --debug test /sys/class/net/*
>
> did not find the script installed via the 'udev-service-type'.
I was curious about this, since I've been using a udev rule for quite a
while to setup zram swap. I definitely have my zram swap enabled and
working, but 'udevadm --debug test /dev/zram0' didn't find any rule for
zram.
> A review of the 'eudev' sources indicated that the path to find rules [3] is
> hard-coded to the store location during installation. An attempt to set the
> path to /etc/udev/rules.d yielded a build error because that target folder
> outside the store was understandably not writable.
>
> The manual page for udevadm did not offer a way to select the runtime location
> of the udev/rules.d folder via environment variables or a command-line option.
>
> Anyone for whom such a setup is working properly should please contact the
> author. Thank you!
/etc/udev points to /etc/static/udev, which itself is a symlink to a
combined udev item in the store, made up of all the udev rules installed
in the current system.
> This commit may result in some loss of privacy, although it is presently not
> clear how meaningful that is. With this commit, anyone using privacy-enhanced
> IPv6 addresses risks having their MAC exposed when they publish their
> configuration files in Git or post a well-meant sample in a chat rooms,
> because that configuration may mention the MAC address.
>
> Moreover, the compatibility with schemes to generate fake one-time MAC
> addresses upon boot should be evaluated. One concern is that the explicit
> reference to a network interface in a configuration file would likely force
> the use of a single and constant MAC address for that interface.
>
> This commit was tested in production and is currently being used.
>
> The change here resulted in the recompilation of several seemingly unrelated
> packages such as Emacs and GTK. Perhaps those dependency relationships should
> be examined.
>
> [1]
> https://wiki.debian.org/NetworkInterfaceNames#How_to_migrate_to_th
Re: What's needed to get things building for i586-gnu (the hurd) post core-updates?
On Mon, May 15, 2023 at 06:46:17PM +0200, Josselin Poiret wrote:
> Hi Efraim,
>
> Efraim Flashner writes:
> > If all you need is to remove coreutils-boot0 from the origin then you
> > could create a similar boot0 package specifically for the hurd and make
> > the fix there, and then use the current package or your new one as an
> > input in later packages based on the architecture.
>
> Unfortunately, it is used in an origin snippet, and there you can't
> really case over the target system.
>
Let me clarify a bit:
Add gcc-boot0-hurd, but with the snippet using guile instead of
coreutils-boot0. Then in (%boot1-inputs) the code gets changed from
("gcc" ,gcc-boot0) to (untested)
("gcc" ,(if (target-hurd?)
gcc-boot0-hurd
gcc-boot0))
And then similarly through the rest of gnu/packages/commencement.
--
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 0/8] Remove mysql
On Mon, Apr 17, 2023 at 04:29:13PM +0300, Efraim Flashner wrote: > I saw that a fix was applied to mysql on core-updates to have it build > with openssl-1.1, and I figured that rather than have a version that was > several years out of date (and surely had many many security > vulnerabilities) it would be better to try to just remove it. > `mariadb:dev` provides the `mysql_config` binary that some packages > search for so I used it as a drop-in replacement. Nothing seemed broken > to me after building some packages, so to the best of my knowledge of > these disparate packages and languages all is fine. > > Efraim Flashner (8): > gnu: sysbench: Build with mariadb. > gnu: ghc-mysql: Build with mariadb. > gnu: neko: Build with mariadb. > gnu: inspircd: Build with mariadb. > gnu: ulogd: Build with mariadb. > gnu: opensmtpd-extras: Build with mariadb. > gnu: sbcl-clsql: Build with mariadb. > gnu: cl-clsql: Build with mariadb. > > gnu/packages/benchmark.scm | 9 + > gnu/packages/haskell-xyz.scm | 4 ++-- > gnu/packages/haxe.scm| 3 ++- > gnu/packages/irc.scm | 4 ++-- > gnu/packages/linux.scm | 6 +++--- > gnu/packages/lisp-xyz.scm| 18 ++ > gnu/packages/mail.scm| 4 ++-- > 7 files changed, 22 insertions(+), 26 deletions(-) > > > base-commit: 2d06dfc050114dba44e791d8decc8eaa705fee01 This patch was pushed almost a month ago, closing the bug now -- 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: Transformations Shell Syntax
On Tue, May 23, 2023 at 06:43:30AM +, jgart wrote: > Hi Guixers WDYT, > > Uses specified commit hash: > > guix build emacs-ement@8b56efa9387262514daf63151d41c9e111e79567 for a comparison, the current (long) version: guix build emacs-ement --with-commit=emacs-ement=8b56efa9387262514daf63151d41c9e111e79567 Obviously the difference is that --with-commit can apply to dependencies, and this looks to only work on the actual package, but I often find myself only adjusting the actual package I'm trying to build anyway. > Uses specified commit hash (short): > > guix build emacs-ement@8b56efa > > Uses latest upstream release: > > guix build emacs-ement@latest > > Uses upstream version 0.8.2 if not packaged: > > guix build emacs-ement@0.8.2 > > Uses the latest commit in the wip/find-room branch: > > guix build emacs-ement@wip/find-room I'm not sure how @latest would work with @wip/find-room, unless @latest was reserved to point to (maybe) the newest release. I think we've all seen that the updater sometimes gets confused by some of the upstream methods of tagging releases and trying to figure out what the lastest release actually is. -- 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: Do substitutes download slowly for you? / Speeding up substitute delivery/mirrors
On Thu, May 25, 2023 at 02:52:24PM +0100, Christopher Baines wrote: > Hey! > > I was reminded again about substitute download speeds outside of Europe > again today. It looks like I'm a bit later than most of the other responses. > Once again it would be good to gather some data on this, so here are > some test commands. I'm interested to see how France compares with > either the US or Singapore depending on your location. If you think that > none of these locations serve you well, then please say that plus give > some indication of what download speeds you see for things that download > quickly. > > France:wget > https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 (ins)efraim@3900XT /tmp$ wget https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 -O stellarium-france --2023-05-29 14:54:04-- https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 Resolving bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)... 185.233.100.56, 2a0c:e300::58 Connecting to bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)|185.233.100.56|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 208615205 (199M) [text/plain] Saving to: ‘stellarium-france’ stellarium-france 100%[>] 198.95M 12.2MB/sin 17s 2023-05-29 14:54:21 (11.8 MB/s) - ‘stellarium-france’ saved [208615205/208615205] > US:wget > https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 (ins)efraim@3900XT /tmp$ wget https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 -O stellarium-US --2023-05-29 14:55:02-- https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 Resolving bordeaux-us-east-mirror.cbaines.net (bordeaux-us-east-mirror.cbaines.net)... 5.161.49.48 Connecting to bordeaux-us-east-mirror.cbaines.net (bordeaux-us-east-mirror.cbaines.net)|5.161.49.48|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 208615205 (199M) [text/plain] Saving to: ‘stellarium-US’ stellarium-US 100%[>] 198.95M 12.2MB/sin 17s 2023-05-29 14:55:20 (11.5 MB/s) - ‘stellarium-US’ saved [208615205/208615205] > Singapore: wget > https://bordeaux-singapore-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 (ins)efraim@3900XT /tmp$ wget https://bordeaux-singapore-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 -O stellarium-singapore --2023-05-29 14:56:29-- https://bordeaux-singapore-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 Resolving bordeaux-singapore-mirror.cbaines.net (bordeaux-singapore-mirror.cbaines.net)... 64.176.80.78, 2401:c080:1400:71df:5400:4ff:fe73:757d Connecting to bordeaux-singapore-mirror.cbaines.net (bordeaux-singapore-mirror.cbaines.net)|64.176.80.78|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 208615205 (199M) [text/plain] Saving to: ‘stellarium-singapore’ stellarium-singapore 100%[>] 198.95M 10.8MB/sin 19s 2023-05-29 14:56:50 (10.2 MB/s) - ‘stellarium-singapore’ saved [208615205/208615205] > So please share the output from wget and if you're comfortable doing so, > the rough real world location of where the computer doing the > downloading is. I'm in Israel, paying for a 100/2 connection. I'm surprised the download from Singapore went so quickly, I would've expected that to be slower. Unless things have changed our internet travels to us by way of Greece and Cyprus. As an aside, a few years ago we tried out using Amazon as a CDN, and IIRC I figured I was likely the only user in Israel with ~15GB/month draw. -- 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: 02/03: gnu: openblas: Update architectures we provide substitutes for.
On Fri, Jun 02, 2023 at 11:03:42PM +0100, Christopher Baines wrote: > > guix-comm...@gnu.org writes: > > > efraim pushed a commit to branch master > > in repository guix. > > > > commit 076688fa1e41a09f034a80e1a593bac43f1f1482 > > Author: Efraim Flashner > > AuthorDate: Thu Jun 1 11:06:00 2023 +0300 > > > > gnu: openblas: Update architectures we provide substitutes for. > > > > * gnu/packages/maths.scm (openblas)[arguments]: Adjust the > > substitutable? > > flag to only not provide substitutes when building for powerpc-linux. > > Adjust the comment accordingly. > > --- > > gnu/packages/maths.scm | 11 ++- > > 1 file changed, 2 insertions(+), 9 deletions(-) > > I've been looking at why armhf-linux substitute availability has been > dropping recently, and I think this change triggered a lot of > rebuilds. Could this have gone to core-updates? > > → guix refresh -l openblas > Building the following 2282 packages would ensure 5596 dependent packages are > rebuilt: ... It's not that it's triggered rebuilds, but that it's triggered builds. It's also triggered builds on powerpc64le and riscv64. Before any package which had openblas as a transitive dependency wasn't built by the CI because it wasn't substitutable¹. People still have the option of using package transformations to use openblas tuned for the cortex a7 or a15 on armhf, but in reality this just unlocks substitutes for those ~5600 packages which wasn't available before. ¹ We saw this in the past briefly in the past when openzfs made its way as a dependency to qemu and through that to Gnome. -- 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: 02/03: gnu: openblas: Update architectures we provide substitutes for.
On Sat, Jun 03, 2023 at 08:12:48PM +0100, Christopher Baines wrote: > > Efraim Flashner writes: > > > On Fri, Jun 02, 2023 at 11:03:42PM +0100, Christopher Baines wrote: > >> > >> guix-comm...@gnu.org writes: > >> > >> > efraim pushed a commit to branch master > >> > in repository guix. > >> > > >> > commit 076688fa1e41a09f034a80e1a593bac43f1f1482 > >> > Author: Efraim Flashner > >> > AuthorDate: Thu Jun 1 11:06:00 2023 +0300 > >> > > >> > gnu: openblas: Update architectures we provide substitutes for. > >> > > >> > * gnu/packages/maths.scm (openblas)[arguments]: Adjust the > >> > substitutable? > >> > flag to only not provide substitutes when building for powerpc-linux. > >> > Adjust the comment accordingly. > >> > --- > >> > gnu/packages/maths.scm | 11 ++- > >> > 1 file changed, 2 insertions(+), 9 deletions(-) > >> > >> I've been looking at why armhf-linux substitute availability has been > >> dropping recently, and I think this change triggered a lot of > >> rebuilds. Could this have gone to core-updates? > >> > >> → guix refresh -l openblas > >> Building the following 2282 packages would ensure 5596 dependent packages > >> are rebuilt: ... > > > > It's not that it's triggered rebuilds, but that it's triggered builds. > > It's also triggered builds on powerpc64le and riscv64. Before any > > package which had openblas as a transitive dependency wasn't built by > > the CI because it wasn't substitutable¹. People still have the option of > > using package transformations to use openblas tuned for the cortex a7 or > > a15 on armhf, but in reality this just unlocks substitutes for those > > ~5600 packages which wasn't available before. > > > > ¹ We saw this in the past briefly in the past when openzfs made its way > > as a dependency to qemu and through that to Gnome. > > Ok, so the documentation does mention "rebuilding", and I do see that > indeed ci.guix.gnu.org doesn't build not substitutable things. > > Although I think it doesn't apply recursively. Take qjson, guix refresh > -l tells me it's dependent on openblas, and looking back at say this > output [1] for powerpc64le-linux, that's available from both > ci.guix.gnu.org. Which makes sense, as that derivation is substitutable, > even though one of it's inputs isn't. > > 1: > https://data.guix.gnu.org/gnu/store/fibiwzyz8s899ccpix5zs6r2pcdpxk5b-qjson-0.9.0 > > Maybe on the client side this works differently, and guix won't > substitute things which have a non substitutable input? > > Assuming ci.guix.gnu.org was building things for armhf-linux, I think > this would have still caused ~5596 rebuilds, and as I say, I think for > systems like powerpc64le-linux, I think it did cause ~5596 > rebuilds. I looked into it more. First I ran on master: './pre-inst-env guix build --no-grafts --system=armhf-linux openblas -d' /gnu/store/whi4yhiw2b0c0i3n6l8s0qfcphkvbzg4-openblas-0.3.20.drv Then I locally reverted the patch expanding the architectures where we provided substitutes: /gnu/store/1m57z8jkbf6gz7qlbw3ws4ayl0ln9602-openblas-0.3.20.drv Then I locally reverted the patch adjusting the make-flags: /gnu/store/1m57z8jkbf6gz7qlbw3ws4ayl0ln9602-openblas-0.3.20.drv It seems I was wrong, changing the #:substitutable? flag _does_ change the derivation of the package. I also checked the substitutes and saw that bordeaux did (and does) have substitutes for the non-substitutable version, showing that it was built before. I also checked for powerpc64le, to see if perhaps cuirass worked a different way and honored the #:substitutable flag by not building it there, and it too has substitutes for both versions of openblas. I didn't check for riscv64 but I assume the case is the same with a changing derivation. So obviously if I had realized this would cause ~5596 rebuilds per affected arch I wouldn't have pushed the patch. I should've checked the derivation before and after to make sure it didn't change. -- 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: FSDG issues of SCUMMVM-based games
On Tue, Jun 20, 2023 at 06:30:26AM +0200, Liliana Marie Prikler wrote: > Am Sonntag, dem 18.06.2023 um 21:07 +0200 schrieb Denis 'GNUtoo' > Carikli: > > [...] > > > Didn't you say that a hello world for scummvm exists? > > I don't know. There is a template for AGI games but the license is > > strange too, and it also requires some software to build it, and I've > > no idea if it's compatible with QT AGI, and I've also no idea if QT > > AGI works, doesn't have nonfree dependencies, etc. > > > > So that makes things way more complicated because here it probably > > requires a lot of work to confirm that it's possible or not possible > > to develop programs that run inside ScummVM with free software. > I see we're hitting a recurring pattern of not knowing things. This is > not aided by my personal disinterest for ScummVM, but I have to weigh > that disinterest against the potential interest of thousands of users > who are likely to only discover this argument to have taken place after > we've reached a conclusion. > > Note, that this discussion started IIRC a year ago and we have > practically known about actually existing FSDG violations since then. > My approach here is quite simple and pragmatic: Remove the games which > obviously violate the FSDG (that is all the games currently depending > on ScummVM as far as I know), but keep ScummVM for now to allow folks > to experiment. If in some one to five years we still find no practical > way of using ScummVM with only free software, that might be a reason to > remove it then. > > WDYT? This sounds like a sensible resolution to me. -- 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: Guix / Nix Benchmarks
On Mon, Jun 19, 2023 at 02:55:21PM -0400, kiasoc5 wrote: > On 6/19/23 08:54, Nicolas Graves via Development of GNU Guix and the GNU > System distribution. wrote: > > > > One of the criticism that can be read online about Guix (compared to > > Nix) is its speed. I have never tried Nix and probably won't in a near > > future, but I was wondering if some work has been made to compare them > > on basic tasks (package installation, removal...) (the reason why I ask > > is to be able to give an honest answer to someone hesitating between > > both). > > > > At least package installation is faster with Nix. One reason is that Hydra > (their "substitute server") has faster download speeds compared to > CI/Bordeaux, likely due to multiple geographical locations/mirrors. I believe on the Nix side that includes a ~$9000/month bill for AWS. -- 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: shepherd respawn frequency
On Sun, Jul 02, 2023 at 10:01:26PM +0200, Ludovic Courtès wrote: > Hi! > > Attila Lendvai skribis: > > > would the shepherd maintaners (looking at you Ludo :) accept a change that > > introduces a new field into called RESPAWN-DELAY, and issue a > > fiber sleep in RESPAWN-SERVICE when it is not #false, and the daemon > > process quits unexpectedly? > > We could do that. It never occurred to me that this is something one > would want to have though. My reasoning is that if you mark a service > as respawnable, then you really want it to be respawned as soon as it > fails, not 5 seconds later. > > Do you have a motivating example in mind (a daemon) to share? > > Thanks, > Ludo’. > If you want to make sure that something is really gone and cleaned up before trying again. Or an artificial delay, say while waiting for the correct network interface to come up. Or even just `mbsync -a && exit 1 || exit 1` -- 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: Can ALPS be included in the Guix repo? The question is about the licenses.
On Sat, Aug 12, 2023 at 04:03:31PM +0500, nigko wrote: > Hello Guix! > > The ALPS project* (Algorithms and Libraries for Physics Simulations) > https://web.archive.org/web/20210508050408/https://alps.comp-phys.org/mediawiki/index.php/Main_Page > is an open source effort aiming at providing simulation codes for strongly > correlated quantum mechanical systems as well as C++ libraries for > simplifying the development of such code. > > According to https://alps.comp-phys.org/mediawiki/index.php/Licensing the > ALPS _Libraries_ are available for _academic and non-commercial_ use under > the terms of the ALPS _Library_ License version 1.0, > > https://web.archive.org/web/20210506121129/https://alps.comp-phys.org/static/software/ALPS/LICENSE.txt/, > > the ALPS _Applications_ under the ALPS _Application_ License version 1.0, > > https://web.archive.org/web/20210512081507/https://alps.comp-phys.org/static/software/applications/LICENSE.txt/. > > I wonder can ALPS be included in the Guix repo? My concern is in the > licenses. In particular, the ALPS licenses state that the ALPS is for > "non-commercial academic use", but according to > https://www.gnu.org/philosophy/free-sw.html "a free program must be > available for commercial use, commercial development, and commercial > distribution", which are in the contradiction. > > Regards, > N Y > > *Since 2022-10-21 the project is being dormant, > https://green.physics.lsa.umich.edu/alps_legacy/index.php?title=Main_Page > Placing the limitation of 'academic and non-commercial' the license is non-free and cannot be included in Guix proper. If something depends on it that you're looking to upstream it'll need to be buildable without that library. I apologize for being the bearer of sad news. -- 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: btrfs recommended layout for snapshots?
On Mon, Aug 14, 2023 at 04:41:52PM +0200, Nicolas Graves via Development of GNU Guix and the GNU System distribution. wrote: > > > - either not snapshotting the rootfs / at all, with the hypothesis that > > we get it back entirely from config files. Is that possible ? Is there > > information in / (I think of /etc in particular) that is saved, not > > temporary and not managed by guix system that would justify that we > > want to snapshot / at all? > > This would allow to simply care about only a few "user data" > > directories, and be sure to not miss anything when there's a need to > > restore the state. > > > > I can't find easily a case of successful use of the second > > configuration, but would be glad to find one, as well as some discussion > > about what would be a recommended way to secure the state beyond > > dotfiles. > > I've found some equivalent information on the NixOS side here : > https://nixos.wiki/wiki/Impermanence > > Some (rare) directories indeed seem that would better be saved because > their information is useful for the system, in the case of NixOS, it > seems to be "/etc/nixos", "/etc/NetworkManager" (for system > connections), "/var/log", "/var/lib". > > However, I have much more files that aren't linked in the store, > especially in the /etc directory (at least 20 files). > > Has anybody tried to do something like this on Guix? I'm still not using most of the features of btrfs, just compression. Inside /etc/guix /etc/guix/acl is managed with the guix-service-type. IMO the signing keys should be rotated if you reload a machine (or at least properly securing them is more effort than is worthwhile), and /etc/guix/machines.scm isn't secret. I can't think of anything else in /etc I'd want besides /etc/guix/machines.scm. With that in mind, the only thing I could see snapshotting is /home, and living with the knowledge that I might have to adjust or remove some symlinks when rolling back. As far as what inside /home/ is worth backing up and what isn't, I suppose that depends on their use of guix-home or if they want to save space by not backing up ~/.cache or ~/.var or the like. -- 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: btrfs recommended layout for snapshots?
On Wed, Aug 16, 2023 at 10:10:25AM +0200, Nicolas Graves wrote: > On 2023-08-14 16:41, Nicolas Graves wrote: > > >> - either not snapshotting the rootfs / at all, with the hypothesis that > >> we get it back entirely from config files. Is that possible ? Is there > >> information in / (I think of /etc in particular) that is saved, not > >> temporary and not managed by guix system that would justify that we > >> want to snapshot / at all? > >> This would allow to simply care about only a few "user data" > >> directories, and be sure to not miss anything when there's a need to > >> restore the state. > >> > >> I can't find easily a case of successful use of the second > >> configuration, but would be glad to find one, as well as some discussion > >> about what would be a recommended way to secure the state beyond > >> dotfiles. > > > > I've found some equivalent information on the NixOS side here : > > https://nixos.wiki/wiki/Impermanence > > > > Some (rare) directories indeed seem that would better be saved because > > their information is useful for the system, in the case of NixOS, it > > seems to be "/etc/nixos", "/etc/NetworkManager" (for system > > connections), "/var/log", "/var/lib". > > Thank you all for your answers! > > I actually managed to replicate the impermanence functionality by > creating btrfs subvolumes for "/etc/guix" "/etc/NetworkManager" > "/var/log" "/var/lib" "/var/guix" and 4 light patches (I'm currently > trying to remove one I think might be not necessary, will send them > here. They basically amount to create directories when they might not be > present or allowing the root "none" to pass to the mount call). With impermanence I'd save /etc/ssh so you don't have to regenerate keys each time. Or perhaps look into SSH Certificate Authority if you want to go crazy with it. > This allows me to start with a tmpfs rootfs, and the only annoying thing > I experience not is that the root password is not set (the account > password is set though, since we can include that in the definition of > an os). Boot time is a bit higher since /etc/machine-id and some other > files have to be recreated, but that's not really noticeable. > > I don't know if I'll stick to this "impermanent" mode, but at least this > gives me the right information about what directories are worth > considering for snapshots (doesn't mean they are worth snapshotting), > and what a "precise" btrfs layout on Guix would have to consider. > > I guess it's possible to do the same with my home as well (thus only > saving actual data and not consecutive linking metadata), but that might > require some more time and fine-grained applications considerations. > > @Efraim : I don't have a /etc/guix/machines.scm to save (I don't have an > offloading deamon set for now), IIUC this means I could be doing as good > without "/etc/guix". What are the signing keys used for? The signing keys are used when offloading derivations to other machines. There's an example usage, with saving them for later, in the hurd-vm-service-type and the secret-root (by default in /etc/childhurd). > One weakness from this impermanence feature is that it's actually > application-dependent. For guix-system it's not very damaging (except if > we want very low-level optimizations, like setting nodatacow on > subvolumes with databases etc), but for guix-home, it makes things much > more difficult. @Andrew Tropin : maybe that's something we could in RDE in > a state-btrfs in (gnu home-services state) if we find a way to migrate > directories to subvolumes safely and reproducibly. > > -- > Best regards, > Nicolas Graves -- 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: How can we decrease the cognitive overhead for contributors?
On Mon, Sep 04, 2023 at 10:56:39AM +0200, Ricardo Wurmus wrote: > > Vagrant Cascadian writes: > > > The only thing clunky about this particular aspect of the workflow > > described is the fact that the guix community (maintainers?) have > > decided on a one patch per mail policy with a cover letter, rather than > > submitting the patches as attachments in the initial mail. > > You are right. When I started contributing I actually did attach all > patches in one email. I wonder why we stopped doing that. I believe some found it easier to pipe multiple emails to git am than to pipe attachments. From mutt there's no difference for me. > I’ll say that many of my gripes with (the GNU instance of) Debbugs are > due to the fact that we can’t customize it to better suit our needs — it > is a shared resource with a complicated maintenance story. So all > changes went into Mumi as crude workarounds. I think this is a dead end > and we’d be better off leaving the shared GNU instance of Debbugs > behind. -- 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: CI job for lisp-team branch
On Mon, Sep 04, 2023 at 09:27:44AM +, Guillaume Le Vaillant wrote: > Hi. > I created a lisp-team branch to work one some updates for clisp and > sbcl. Could someone with admin access to the CI things add a job for it? > Thanks. I commented on IRC but figured I should post to the mailing list. I tested sbcl@2.3.8 on riscv64-linux and the build failed in the contrib section. I see the patch was removed, presumably because it was included in the upstream release. When I finish my current build target(s) I'll see what needs to be done there. -- 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: CI job for lisp-team branch
On Wed, Sep 06, 2023 at 03:47:01PM +0300, Efraim Flashner wrote: > On Mon, Sep 04, 2023 at 09:27:44AM +, Guillaume Le Vaillant wrote: > > Hi. > > I created a lisp-team branch to work one some updates for clisp and > > sbcl. Could someone with admin access to the CI things add a job for it? > > Thanks. > > I commented on IRC but figured I should post to the mailing list. > > I tested sbcl@2.3.8 on riscv64-linux and the build failed in the contrib > section. I see the patch was removed, presumably because it was included > in the upstream release. When I finish my current build target(s) I'll > see what needs to be done there. Re-adding the patch failed hard when applying the patch. I tested downgrading sbcl to 2.3.7 and that built everything without any trouble on riscv64-linux. -- 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: Guix related things in Germany at the end of October/start of November
On Tue, Sep 05, 2023 at 06:28:09PM +0100, Christopher Baines wrote: > Hey, > > PackagingCon [1] is happening in Berlin on the 26th to the 28th of > October, and the Reproducible Builds summit is happening in Hamburg on > the 31st of October to the 2nd of November. > > 1: https://packaging-con.org/ > 2: https://reproducible-builds.org/events/hamburg2023/ > > I've had a talk proposal on QA and Guix accepted for PackagingCon, and > I'm planning to attend the Reproducible Builds summit as well. Plus I'll > try to make some time to do some tourist stuff while I'm in Germany as > well. > > Is anyone else planning to attend these events, or otherwise interested > in meeting up in Germany around these dates? I'll be there! Feedback on my talk proposal was that it was perhaps a bit too niche, so I get to enjoy the conference without giving a talk. Haven't finalized my dates yet but I'm planning on coming in to Berlin on the Wednesday (25th?) so I can be there for PackagingCon and then my wife and kids are flying in on Sunday and we're going to take the train to Hamburg. No plans yet about which touristy things to do. -- 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: CI job for lisp-team branch
On Thu, Sep 07, 2023 at 12:31:39PM +, Guillaume Le Vaillant wrote:
> Efraim Flashner skribis:
>
> > On Wed, Sep 06, 2023 at 03:47:01PM +0300, Efraim Flashner wrote:
> >>
> >> I commented on IRC but figured I should post to the mailing list.
> >>
> >> I tested sbcl@2.3.8 on riscv64-linux and the build failed in the contrib
> >> section. I see the patch was removed, presumably because it was included
> >> in the upstream release. When I finish my current build target(s) I'll
> >> see what needs to be done there.
> >
> > Re-adding the patch failed hard when applying the patch. I tested
> > downgrading sbcl to 2.3.7 and that built everything without any trouble
> > on riscv64-linux.
>
> The patch was a backport from upstream (commit
> 8704f528f227f587d0e06dfd2f807aeca7a69a71), so it is already in the
> sources for sbcl 2.3.8.
>
> What error do you get when building on riscv64? Maybe we could report it
> upstream as I have not seen anything about riscv64 fixes in the commit
> history of sbcl since version 2.3.8.
//entering make-target-contrib.sh
make: Entering directory '/tmp/guix-build-sbcl-2.3.8.drv-0/sbcl-2.3.8/contrib'
make: *** No rule to make target 'sb-posix.fasl', needed by 'all'.
make: *** No rule to make target 'sb-bsd-sockets.fasl', needed by 'all'.
make: *** No rule to make target 'sb-introspect.fasl', needed by 'all'.
make: *** No rule to make target 'sb-cltl2.fasl', needed by 'all'.
make: *** No rule to make target 'sb-aclrepl.fasl', needed by 'all'.
make: *** No rule to make target 'sb-sprof.fasl', needed by 'all'.
make: *** No rule to make target 'sb-capstone.fasl', needed by 'all'.
make: *** No rule to make target 'sb-rotate-byte.fasl', needed by 'sb-md5.fasl'.
make: *** No rule to make target 'sb-executable.fasl', needed by 'all'.
make: *** No rule to make target 'sb-gmp.fasl', needed by 'all'.
make: *** No rule to make target 'sb-concurrency.fasl', needed by
'sb-queue.fasl'.
make: *** No rule to make target 'sb-rt.fasl', needed by 'all'.
make: *** No rule to make target 'asdf.fasl', needed by 'sb-grovel.fasl'.
make: Target 'all' not remade because of errors.
make: Leaving directory '/tmp/guix-build-sbcl-2.3.8.drv-0/sbcl-2.3.8/contrib'
real0m0.046s
user0m0.033s
sys 0m0.014s
error: in phase 'build': uncaught exception:
%exception #<&invoke-error program: "sh" arguments: ("make.sh" "clisp"
"--prefix=/gnu/store/yz18dz67jmy2vmvilxm1pbfdw8g1yky2-sbcl-2.3.8"
"--dynamic-space-size=3072" "--with-sb-core-compression"
"--with-sb-xref-for-internals" "--without-sb-simd") exit-status: 2 term-signal:
#f stop-signal: #f>
phase `build' failed after 11808.1 seconds
command "sh" "make.sh" "clisp"
"--prefix=/gnu/store/yz18dz67jmy2vmvilxm1pbfdw8g1yky2-sbcl-2.3.8"
"--dynamic-space-size=3072" "--with-sb-core-compression"
"--with-sb-xref-for-internals" "--without-sb-simd" failed with status 2
That's why I tried to reapply the patch, when I saw that I figured the
patch was still needed. I've attached a compressed log incase for
posterity.
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
sbcl-2.3.8-riscv64.log.gz
Description: application/gunzip
signature.asc
Description: PGP signature
Re: How can we decrease the cognitive overhead for contributors?
On Fri, Sep 08, 2023 at 11:53:43AM +0200, Giovanni Biscuolo wrote: > Hello Katherine, > > Katherine Cox-Buday writes: > > [...] > > > By "standard" I mean the GNU Changelog format > > (https://www.gnu.org/prep/standards/standards.html#Change-Logs). As > > in: it's expected that commit messages use this format. > > [...] > > > In my response I was trying to point out a flaw in your comparison: that > > with style guidelines, which are also complicated, there is usually a > > formatter that will do it for me, or a linter that will tell me that > > something is not meeting the standard. This is because languages have > > grammars, and linters have higher-order system grammars. > > AFAIU you are talking about the "Formatting Code" /subset/ of a "Coding > style", because there is no linter that will tell you if you are > following the subset called "Data Types and Pattern Matching" [1]: am I > wrong? > > Back to the git commit message formatting: please can you provide us > with one or two examples of how a commit message should be formatted and > what linter is available for that syntax? > > [...] > > > Here is my channel with things I intend to upstream, but haven't, > > largely because of this friction. > > By "this friction" you mean you miss a linter for commit messages? > > Or do you mean you do not agree with the style requested by Guix (and > GNU) for the commit messages? > > You are obviously free not to contribute your patches upstream but the > fact that you decided not to because it's "too hard" (my executive > summary about your complaints about Change Log content rules) to write > commit messages suitable for contribution it _not_ a Guix maintainers > fault, not at all. > > Obviously everyone is free to comment, ask for clarifications or > proposing **patches**, but it's not fair to say "I'm not contributing > largerly because I've a specific friction with the rules about commit > messages" (again, my executive summary). > > [...] > > Ciao, Gio' That wasn't my read of it at all. I too have many packages which I haven't upstreamed. One of the major pushes that I did was cleaning up mailman and pushing them to Guix. I had just finished working on it earlier in the week and it turned out I didn't actually need it anymore, but I figured better in Guix than out. It was either one or two 8 hour days of reviewing my own patches, making sure they all built correctly, and then finally committing them. I also have almost 500 go packages which I don't intend to upstream. I'm package them and update them occasionally when trying to package some big application like gitea or keybase or tailscale or gotosocial, but the effort to go through and see which packages are ACTUALLY needed and to clean up everything, it's just too much for me. I suppose this could be construed as "I'm not contributing these packages because I don't like go" but that's not the whole of it. And by rephrasing it like that takes out the nuance of other bits of why I haven't worked on those packages and neuters the discussion about why these are my packages instead of our packages. As far as commit messages, I've found that the script in etc/committer.scm to be very nice, even if there are plenty of cases where it doesn't do the job. I do think there's room for improvement and that may be one of the things we can do to make contributing easier. -- 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: Cross compilation status
On Sun, Sep 10, 2023 at 11:14:29AM +0200, Mathieu Othacehe wrote: > > I have CC'ed members of the python, java, ruby, rust, r, haskell and > emacs teams. Any plans adding cross-compilation support to your > build-system, barriers to overcome? Speaking as the one who added the rakudo build system and the perl6 packages, IMO all the perl6 packages should be removed and also the rakudo-build-system. I don't believe most of the packages have built for more than a year and I don't believe they have ever had any adoption. If it turns out that Raku (no longer perl6 for several years now) would make use of the current rakudo-build-system then we can always revert removing it. -- 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: Cross compilation status
On Sun, Sep 10, 2023 at 11:14:29AM +0200, Mathieu Othacehe wrote: > > Hello, > > In order for Guix to become an alternative to tools such as Yocto and > Buildroot, having most or all our packages cross-compiling is a > prerequisite. > > Here is a status of cross-compilation in Guix. For cross-compilation to > work, the build-system needs to support cross-compilation. > > The following build-systems explicitly refuse cross-compiling packages: > > > ocaml: 61 > haskell: 812 > maven: 2 > chicken: 12 > node: 57 > emacs: 1370 > dune: 289 > android-ndk: 12 > waf: 21 > julia: 300 > pyproject: 433 > r: 2441 > cargo: 3535 > ruby: 597 > rebar: 22 > scons: 15 > rakudo: 22 > agda: 6 > ant: 559 > python: 2488 > Cross-compilation KO: 13054 > --8<---cut here---end--->8--- > > Over the 28076 packages in Guix, 15065 are part of build-systems with > cross-compilation support and 13054 are part of build-systems without > cross-compilation support. > > Overall 46.5% of our packages will refuse to cross-compile with errors > such as: > > --8<---cut here---start->8--- > mathieu@meije ~$ guix build --target=aarch64-linux-gnu librsvg > guix build: error: gnu/packages/gnome.scm:3500:2: librsvg@2.54.5: build > system `cargo' does not support cross builds > --8<---cut here---end--->8--- > > I'd like to help converge towards the situation where all build-systems > support cross-compilation. > > I have CC'ed members of the python, java, ruby, rust, r, haskell and > emacs teams. Any plans adding cross-compilation support to your > build-system, barriers to overcome? I suspect librsvg is especially a problem since it is almost always pulled in with any sort of image building. I haven't looked at it closely yet, but I believe that in order to support cross-compilation support in rust we'll need to enable more targets, which will increase the build time for the final rust and the final output size. Considering that nothing built with rust links to it, I'm not convinced this is a problem. We will likely see people confused that we have a rust with cross-compiling abilities but with windows- and mac-specific (pre-compiled) libraries removed, so it wouldn't be able to cross-compile to those (or some other) platforms without changes. -- 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: How can we decrease the cognitive overhead for contributors?
On Fri, Sep 08, 2023 at 04:20:30PM +0200, Ricardo Wurmus wrote: > > Josselin Poiret writes: > > > Regarding the “mom argument”, I would disagree and say that this is > > completely related: interruptions are more costly, you're more likely to > > have less attention span, and overall you probably don't want to commit > > to 20 steps just to send a contribution. > > That’s exactly it. > > I’m a parent working a full-time job and I’m easily overwhelmed by what > I would have considered to be simple processes 20 years ago. All these > simple and totally “easy” processes add up and – oops it’s 11:30pm > already and I had been feeling exhausted since 10am… > > There’s an hour before I pass out — what will I do with it? This thread > is about how we can reduce overhead; for me that would mean to have > certain checks automated, or to have commit messages be generated so I > only need to read them to sign off on them, etc. > > We all may gain from streamlining our processes. Personally, I see the > biggest problem in a lack of effective tools for reviewers, which > results in stretching out contribution interactions over weeks, months, > or years. This, to me, would be a way to increase the weight of the > rewards on the unbalanced scales that are overwhelmed by chores on the > other side. On the other hand, if we do manage to automate writing of commit messages, it makes one less thing for committers to manually fix before pushing the commit. The last couple of contributions I pushed had green checks on qa.guix.gnu.org and I felt at a bit of a loss what to do while checking it over. After checking that it was in fact green I double-checked the commit message and then also some of the layout of the commit and the package itself, and made sure it passed `guix lint`. More resources for qa.guix.gnu.org would let us build more patches more quickly. -- 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: Cross compilation status
On Sun, Sep 10, 2023 at 04:59:35PM +0200, Liliana Marie Prikler wrote: > Hi Mathieu, > > Am Sonntag, dem 10.09.2023 um 11:14 +0200 schrieb Mathieu Othacehe: > > I have CC'ed members of the python, java, ruby, rust, r, haskell and > > emacs teams. Any plans adding cross-compilation support to your > > build-system, barriers to overcome? > For Emacs, there are layers of problems. First things first, we are > only doing byte compilation atm, which may or may not be arch-dependant > based on stuff like endianness. For native compilation, there is the > thing that even a slightly differently configured emacs won't load the > packages you've just compiled without compiling it natively on its own. > Granted, if we want to do cross-compilation, having just the bytecode > might already be "good enough", but I wanted to throw this out there. > > I think we'd need some support from Emacs proper before we can start > implementing cross builds. I will note that the only big-endian architecture which we "support" is 32-bit powerpc, so we don't have to worry that much about wrong endianness. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Emacs and Guix (was Re: The e(macs)lephant in the room and the Guix Bang)
On Mon, Sep 25, 2023 at 10:34:11PM +0200, Simon Tournier wrote: > Hi, > > On Mon, 25 Sep 2023 at 14:09, MSavoritias wrote: > > > when its the same people that push Emacs as the "blessed" way to > > contribute (as in the guix manual) > > Just to point 1. Guix is part of GNU – for the good, the bad and the > ugly – so 2. editors developed under the GNU umbrella are autopromoted – > GNU Emacs is one, GNU nano would be another one. Well, for what it is > worth, I feel such autopromotion as some consistency. > > BTW, Efraim is GNU Guix co-maintainer and demoed the use of Vim for Guix > development: > > https://10years.guix.gnu.org/video/using-vim-for-guix-development/ > > Somehow, when one co-maintainer publicly demoed using not-Emacs makes a > point that there is no “blessed“ editors – and the part dedicated for > Emacs in the manual seems just an autopromotion of GNU products that > contributors enjoy for cooking – dogfooding. ;-). Oh no! My very embarrassing talk where I was missing that magic 1 or 2 packages from my manifest and then everything fell apart. I think I need to watch it again myself and then try redoing it at home. > Contributions in the Guix manual or in the cookbook about how to setup > other editors than Emacs are very welcome. This is the big part. I have a setup that works reasonably well for me and I haven't done a good job sharing it with others so they can see some of the other options. IIRC one of the big things I wanted to show was using ctags with Guix to jump quickly between packages or to other definitions. Right now the tags make target is a stub, I (or someone else even) should see about adjusting that so 'make tags' works for the project. -- 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: Guix related things in Germany at the end of October/start of November
On Thu, Sep 28, 2023 at 11:58:10PM +0200, Ricardo Wurmus wrote: > > Christopher Baines writes: > > > PackagingCon [1] is happening in Berlin on the 26th to the 28th of > > October […] > > Is anyone else planning to attend these events, or otherwise interested > > in meeting up in Germany around these dates? > > I don’t seem to have anything planned around the time of PackagingCon, > so should a little Guix meeting happen in Berlin I’d try to make time to > stop by for a while. I think I got everyone in the list. It looks like I won't be traveling with wife & kids this trip. PackageCon is Thursday & Friday in Berlin with a hackday on Saturday. Then Reproducible Builds is Tuesday, Wednesday, Thursday in Hamburg. Saturday hackathon entrance fee is 5€ I think but it comes with the location and I assume outlets and internet and seems like a good idea to repurpose it for a meetup. Or we can meetup for food at some point. I don't have any ideas yet for Hamburg, except that I don't know if Chris has any plans on when he's heading over from Berlin and I haven't booked anything yet. -- 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: ActtivityPub and Haunt
On Thu, Sep 28, 2023 at 10:03:13PM +0200, Reza Housseini wrote: > > But I will hands-down say that Haunt was an EXCELLENT environment for > > writing ap.rocks. The implementation guide page especially is a great > > demonstration of Haunt's power: > > > >https://activitypub.rocks/implementation-report/ > > pretty cool stuff indeed! I also checked out the software mentioned on the > page, are there any attempts at packaging some of the software e.g. > microblog.pub? Looks like I was starting to work on it at some point. Not sure why I stopped. https://git.sr.ht/~efraim/my-guix/tree/master/item/wip/microblog-pub.scm -- 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: [bug#66343] Add more setups to Guix docs
> +
> +@example
> +guix install vim-paredit
> +@end example
> +
> +We also recommend that you run @code{:set autoindent} so that your code is
> +automatically indented as you type.
> +
> +For the interaction with Git,
> +@uref{https://www.vim.org/scripts/script.php?script_id=2975
> +@code{fugitive.vim}} is the most commonly used plugin:
> +
> +@example
> +guix install vim-fugitive
> +@end example
> +
And of course if you want to interact with Guix directly from inside of
vim, using the built-in terminal emulator, we have our very own
@code{guix.vim} package!
@example
guix install vim-guix-vim
@end example
> +In NeoVim you can even make a similar setup to Geiser using
> +@url{https://conjure.fun/, Conjure} that lets you connect to a running Guile
> +process and inject your code there live (sadly it's not packaged in Guix
> yet).
> +
> +
> @node Packaging Guidelines
> @section Packaging Guidelines
>
> @@ -1257,13 +1327,6 @@ Formatting Code
> @noindent
> @xref{Invoking guix style}, for more information.
>
> -@cindex Vim, Scheme code editing
> -If you are editing code with Vim, we recommend that you run @code{:set
> -autoindent} so that your code is automatically indented as you type.
> -Additionally,
> -@uref{https://www.vim.org/scripts/script.php?script_id=3998,
> -@code{paredit.vim}} may help you deal with all these parentheses.
> -
> We require all top-level procedures to carry a docstring. This
> requirement can be relaxed for simple private procedures in the
> @code{(guix build @dots{})} name space, though.
>
> base-commit: 284f8508bebcae510261c7c223dc28f9badf87ce
> --
> 2.41.0
>
--
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: [bug#66343] Add more setups to Guix docs
On Wed, Oct 04, 2023 at 06:15:53PM +, Ekaitz Zarraga wrote: > > > --- Original Message --- > On Wednesday, October 4th, 2023 at 16:18, Efraim Flashner > wrote: > > > > I think we can mention guix.vim also > > > Certainly, do you want to add it yourself? > > Nobody is going to explain it better than you. I tossed in a line or two in the middle of the patch -- 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: [bug#66343] Add more setups to Guix docs
On Wed, Oct 04, 2023 at 06:47:51PM +, Ekaitz Zarraga wrote:
>
> --- Original Message ---
> On Wednesday, October 4th, 2023 at 18:35, Efraim Flashner
> wrote:
>
>
> > On Wed, Oct 04, 2023 at 06:15:53PM +, Ekaitz Zarraga wrote:
> >
> > > --- Original Message ---
> > > On Wednesday, October 4th, 2023 at 16:18, Efraim Flashner
> > > efr...@flashner.co.il wrote:
> > >
> > > > I think we can mention guix.vim also
> > >
> > > Certainly, do you want to add it yourself?
> > >
> > > Nobody is going to explain it better than you.
> >
> >
> > I tossed in a line or two in the middle of the patch
>
> But you didn't attach, did you?
>
> Or you directly commited?
I commented directly in the middle of the patch.
> +@example
> +guix install vim-fugitive
> +@end example
> +
And of course if you want to interact with Guix directly from inside of
vim, using the built-in terminal emulator, we have our very own
@code{guix.vim} package!
@example
guix install vim-guix-vim
@end example
> +In NeoVim you can even make a similar setup to Geiser using
> +@url{https://conjure.fun/, Conjure} that lets you connect to a running Guile
--
Efraim Flashner רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
From 410eff90c552977a209db2c56538166ec5455be1 Mon Sep 17 00:00:00 2001
Message-ID:
<410eff90c552977a209db2c56538166ec5455be1.1696452671.git.efr...@flashner.co.il>
From: Ekaitz Zarraga
Date: Mon, 25 Sep 2023 16:16:28 +0200
Subject: [PATCH v2] doc: contributing: Add alternative setups section
Start with Guile Studio and Vim/NeoVim.
* doc/contributing.texi (Alternative Setups): Add section explaining
other setups that are similar to the one in The Perfect Setup
---
doc/contributing.texi | 85 +++
1 file changed, 78 insertions(+), 7 deletions(-)
diff --git a/doc/contributing.texi b/doc/contributing.texi
index 0de47a403b..f7c72634e7 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -23,6 +23,7 @@ Contributing
* Building from Git:: The latest and greatest.
* Running Guix Before It Is Installed:: Hacker tricks.
* The Perfect Setup:: The right tools.
+* Alternative Setups:: Other posible tools that do the job.
* Packaging Guidelines::Growing the distribution.
* Coding Style::Hygiene of the contributor.
* Submitting Patches:: Share your work.
@@ -453,6 +454,83 @@ The Perfect Setup
Emacs Manual} and @ref{Minor Mode,,, debbugs-ug, The Debbugs User
Guide}.
+@node Alternative Setups
+@section Alternative Setups
+
+Alternative setups than Emacs may let you work on Guix with a
+similar development experience and they might work better with the
+tools you currently use or help you make the transition to Emacs.
+
+The options listed below only provide the alternatives to the Emacs
+based setup, which is the most widely used in the Guix community. If
+you want to really understand how is the perfect setup for Guix
+development supposed to work, we encourage you to read the section
+before this regardless the editor you choose to use.
+
+@menu
+* Guile Studio::First step in your transition to Emacs.
+* Vim and NeoVim:: When you are evil to the root.
+@end menu
+
+@node Guile Studio
+@subsection Guile Studio
+
+Guile Studio is a pre-configured Emacs with mostly everything you need
+to start hacking in Guile. If you are not familiar with Emacs it makes
+the transition easier for you.
+
+@example
+guix install guile-studio
+@end example
+
+Guile Studio comes with Geiser preinstalled and prepared for action.
+
+@node Vim and NeoVim
+@subsection Vim and NeoVim
+
+
+Vim (and NeoVim) are also packaged in Guix, just in case you decided
+to go for the evil path.
+
+@example
+guix install vim
+@end example
+
+If you want to enjoy a similar development experience to that in the perfect
+setup, you should install several plugins to configure the editor. Vim (and
+NeoVim) have the equivalent to Paredit,
+@uref{https://www.vim.org/scripts/script.php?script_id=3998,
+@code{paredit.vim}}, that will help you with the structural editing of Scheme
+files (the support for very large files is not great, though).
+
+@example
+guix install vim-paredit
+@end example
+
+We also recommend that you run @code{:set autoindent} so that your code is
+automatically indented as you type.
+
+For the interaction with Git,
+@uref{https://www.vim.org/scripts/script.php?script_id=2975
+@code{fugitive.vim}} is the most commonly used plugin:
+
+@example
+guix install vim-fugitive
+@end example
+
+And of course if you want to interact with Guix directly from inside of
+vim, using the built-in terminal emulator, w
Re: [bug#66343] Add more setups to Guix docs
On Wed, Oct 04, 2023 at 08:55:32PM +, Ekaitz Zarraga wrote: > > It looks good to me. > > Commit? Looks good to me too. Patch pushed! -- 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
