Re: GNU Mes 0.24.1 released
Efraim Flashner writes: Hi Efraim, > On Wed, Oct 19, 2022 at 09:41:20PM +0200, Janneke Nieuwenhuizen wrote: > > Which hardware are you building on? On my pine64 I'm getting stuck at > tcc-0.9.26-1134-g80114c4d > On commit 519f4c8c9a0b191e9a447116685393c2fed4cd3b > > starting phase `build' > CCLD mes-tcc > mkdir -p > /gnu/store/d3kcgm0z3yyc7bplaacr7g0j8gk36h5j-tcc-boot0-0.9.26-1134-g80114c4d/lib/tcc > rm -f crt1.o; > cp -f /gnu/store/nli76zd955d9xksy01qrfzlizq4c28kd-mes-boot-0.24.1//lib/crt1.c > . > crt1.c:149: warning: implicit declaration of function 'main' > rm -f crti.o; > cp -f /gnu/store/nli76zd955d9xksy01qrfzlizq4c28kd-mes-boot-0.24.1//lib/crti.c > . > rm -f crtn.o; > cp -f /gnu/store/nli76zd955d9xksy01qrfzlizq4c28kd-mes-boot-0.24.1//lib/crtn.c > . > rm -f libc.a > cp -f > /gnu/store/nli76zd955d9xksy01qrfzlizq4c28kd-mes-boot-0.24.1//lib/libc+gnu.c > libc.c > error: in phase 'build': uncaught exception: > srfi-34 # exit-status: 1 term-signal: #f stop-signal: #f] 10f6100> > phase `build' failed after 21994.9 seconds Oops. Not sure what happened on my side, but yeah this error reproduces for me. I've pushed an updated tcc-boot0 to wip-aarch64-bootstrap. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond https://lilypond.org Freelance IT https://JoyOfSource.com | Avatar® https://AvatarAcademy.com
Re: Mes Bootstrapping demonstration
Aret San writes: Hello Aret/John, > I heard that from GNU Mes 0.24 it's capable of being bootstrapped with > M2-Planet. Yes, see the core-updates branch. > But when I was trying to do that it ended up in some errors > in scm files `something related to (export)`. Sounds like a Nyacc problem. You're missing GUILE_LOAD_PATH set to nyacc/modules, or you don't have nyacc-1.00.2. > I also tried this in a busybox docker image where there's no gcc (not > even guile), The M2-Planet and mescc-tools compiles fine but GNU Mes > crashed the container in `sh configure.sh`. That could be, I haven't tried such tings. > I was wondering if a step-by-step bootstrap instruction can be written > for a barebone system like a busybox container. If you don't want to use Guix, you may have a look at the live bootstrap project https://github.com/fosslinux/live-bootstrap Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond https://lilypond.org Freelance IT https://JoyOfSource.com | Avatar® https://AvatarAcademy.com
[ANN] Dezyne 2.15.0 released as Free Software
antics) no longer confuses the simulator. - A bug has been fixed that would cause the well-welformness check for system bindings to ignore certain missing bindings. - A bug has been fixed when assigning a value to a formal parameter of a function. - A bug has been fixed in the vm that would cause graph or simulate to hang when using a foreign component that has both provides and requires ports (note: don't do that!). - The test framework can be built using gcc-11. - A bug has been fixed in the code generator when assiging to a local variable that shadows a formal parameter or member variable. - A bug has been fixed in the verifier when creating a new local variable or assigning a variable that remains otherwise unused. - The simulation function now supports injection of foreign components. - The trace produced by running dezyne code is now correct when using injected foreign components. - A bug has been fixed that would cause the verifier to overlook non-determinism in a component. - Using external data in binary expressions is now reported as an error (#64[7]). - The parser no longer reports "" expected when an external type definition is missing. - The well-formedness check of the parser no longer hangs when a component has the same name as one of its interfaces. - An interface can now have the same name as its namespace. * Links [0] https://dezyne.org [1] https://mcrl2.org [2] https://tue.nl [3] https://gitlab.com/groups/dezyne/-/issues [4] https://dezyne.org/bugreport [5] https://gitlab.com/dezyne/dezyne-issues/-/issues/67 [6] https://gitlab.com/dezyne/dezyne-issues/-/issues/66 [7] https://gitlab.com/dezyne/dezyne-issues/-/issues/61 -- Jan Nieuwenhuizen | GNU LilyPond https://lilypond.org Freelance IT https://JoyOfSource.com | Avatar® https://AvatarAcademy.com
Re: [bug#54394] [PATCH core-updates 00/12] Remove old GNU utilities from early bootstrap
Timothy Sample writes:
Hello!
> This is culmination of a lot of work, so I’m excited to be submitting
> it! The main thrust of this series is to update Gash and Gash-Utils,
> and then remove most of the old GNU utilities we use during early
> bootstrap. To elaborate, the current situation is that we climb a
> ladder through time: first we build Bash 2, then we build Bash 4, and
> finally we build Bash 5. This is true for most GNU utilities: Sed,
> Gawk, Coreutils, etc. The reason? Until now, our Scheme
> implementations of those utilities (Gash and Gash-Utils) were very
> limited. Bash 2 used to be a lot more useful then Gash, for example.
> Now, with recent releases of Gash and Gash-Utils, the Scheme utilities
> are, in general, capable of powering the builds of modern GNU software.
What an amazing piece of work. Not only adding support for this in Gash
and Gash-Utils, also adding the "follow-up" for the Guix bootstrap.
Wow!
Not meaning to create more unwanted work for you, but I believe this
could do with a blog post. I very much like your "climb a ladder
through time" description.
> To be clear, we still climb the time-ladder in a few cases. The main
> ones are GCC, Glibc, and Binutils. For example, we have to use GCC 2 to
> transition from TCC To GCC 4 (which is the last non-C++ GCC [1]).
> Fixing this would require quite a bit of TCC hacking
Yes, that needs work on MesCC, especially the Mes C Library, and TCC.
Possibly some work on mpz/gmp. We definately want to jump from TCC to
GCC 4.6 (the last modular distribution) in the (near) future.
> We still use old versions of Gzip, Make, patch, and
> Gawk. The fact that Gawk is still there disappoints me quite a bit, but
> ‘glibc-mesboot’ fails in a way that I just can’t figure out when
> building with Gash-Utils.
Yeah, I can imagine, especially after your (2nd?) rewrite of AWK.
> Gzip is not strictly necessary, but also pretty easy to replace.
and replacing possibly has quite a speed penalty.
> I’m not sure, but I think patch is only there
> to avoid using patches in ‘origin’ records during bootstrap. We now
> have a way to do that, so it may no longer be necessary.
Yes, I believe patch is needed for the manual "apply-boot-patch" stages
to avoid adding a dependency on xz, created by adding patches to
"origin" records.
> Make will likely need to be rewritten in Scheme, but we have a head
> start: Potato Make [2].
>
> [2] https://github.com/spk121/potato-make
Interesting!
POSIX Makefile Parser
Recipes can contain the following parser function
(parse ...) reads a standard Makefile and creates
rules based on its contents.
Building glibc without GNU Make may be pretty difficult, though.
> Here’s some detailed info for reviewers.
> Ludovic Courtès writes:
> > The patches all LGTM! I think you can push them to ‘core-updates’ if
> > there are no objections.
> Pushed! (Maybe I didn’t leave enough time for objections – apologies if
> it ends up requiring a revert! I’ll be around to work through any
> issues this might cause.)
Patches LGTM, and thanks for pushing.
> The rest hopefully speak for themselves. Sadly, the last one is
> something of a jumble. Originally I wanted to remove the utilities one
> at a time, but it turns out there are interference effects. I can’t
> remember the exact details now, but to get an idea, removing both old
> Bash and old Grep might work, but removing one and then the other (in
> either order) might not. Hence, many utilities get updated in one
> commit.
That's quite understandable, and certainly acceptable. Much of this
time-ladder was created by me, it was an enormous effort to find old
(and some ancient) versions of the tools that worked well together.
There are undocumented build dependencies all around. Some newer
packages cannot be used to build older versions of other packages, etc.
So, while this kludge was a necessary evil, I'm extremely happy we can
now do without it. We should work towards a bootstrap that depends
mainly on current packages, and strive to keep current packages
bootstrappable.
To summarize what you removed:
bzip2 (not an old version)
sed-1.18
sed-4.0.6
binutils-2.14 (really great!)
bash-2.05b
bash-4.4
gawk-3.0.0
tar-1.22
grep-2.0
coreutils-5.0
xz-5.0.0 (wow, that was difficult to build)
that's 11 old and ancient packages, if have counted correctly.
Greetings,
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Clarifying blog post licensing
Ludovic Courtès writes: > With a few exceptions, our blog posts do not have a license, which is > not great Good catch, I agree! Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: EXWM
André A. Gomes writes: > Jan Nieuwenhuizen writes: > >> I just tried adding my ~/.exwm into my init.el and running a nested >> emacs and now I get a GUI dialog: >> >> Replace existing window manager? Y/N >> >> Not great! Not very suprisingly, the extra unnecessary initialization >> /does/ hurt here. > > Isn't exwm doing precisely what it's supposed to do? Isn't it fair that > the newly spawned (nested) Emacs has the right to take control over the > "older" Emacs? Of course; that's my point exactly! Emacs cannot know, and thus cannot help but doing the annoying thing: throwing a dialogue. That is what this code --8<---cut here---start->8--- (cond ((file-exists-p "~/.exwm") (load-file "~/.exwm")) ((not (featurep (quote exwm))) (require (quote exwm)) (require (quote exwm-config)) (exwm-config-default) (message (concat "exwm configuration not found. " "Falling back to default configuration..." --8<---cut here-------end--->8--- helps to prevent in a very nice way. Let's please keep it! Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: EXWM
Arun Isaac writes: Hello, >> My suggestion is simple: remove the added layer of complexity introduced >> by the .exwm file; don't force a default Exwm config on the user. > > I think I agree with you now. I checked, and exwm indeed does not run > when emacs is opened in the console even though my exwm config is > defined in my ~/.emacs. Interesting. So the extra, unneccesary initialization code does not hurt there. I just tried adding my ~/.exwm into my init.el and running a nested emacs and now I get a GUI dialog: Replace existing window manager? Y/N Not great! Not very suprisingly, the extra unnecessary initialization /does/ hurt here. > So, I see no reason to continue having ~/.exwm. If no one else has any > objections, please do send a patch fixing this. I would very much like for this nested emacs issue to be addressed first. I just don't really see the point in mixing two bits of code that are meant to run in different scenarios, and then disabling one of them. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: EXWM
Arun Isaac writes: Hello, > I was involved in the packaging of exwm when it was first done, and I > hear your frustration. :-) Please do send patches (with me on Cc) > addressing the issue, and we can continue our discussion there. As someone who didn't have a prior EXWM setup in their .emacs, I have been enjoying the separate .exwm config file. I'm wondering, how have you managed to switch off exwm when running a nested emacs or a console emacs? Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Freezing ‘core-updates’ soon?
Ludovic Courtès writes:
Hello!
> What about finally merging that ‘core-updates’ branch? :-)
>
> The main things to decide on are:
>
> • Upgrading to GCC 10? I know Marius has spent time looking at it and
> fixing build failures caused by the upgrade. Can we do it?
>
> • Reduced binary seeds—anything new? My understanding is that the
> reduced binary seed bootstrap now works on ARM, but that we were
> waiting on a Mes release to merge those bits. Janneke, Danny?
Sadly, we are not there yet. The gcc/glibc build is still not done.
The full source bootstrap is "almost ready" and is waiting for a GNU Mes
release. It was wating for an M2-Planet release but that happened last
week! I'm not sure about a time frame here though. A week, hmm?
> • Simplified package inputs—I’ll keep working on that, and most of the
> work can be done without a world rebuild, so it’s not a blocker IMO.
I haven't really caught-up here and am still wondering here about things
like
("foo-for-build" ,foo)
("patch-bar" ,(search-patch ...))
but that's prolly addressed. I'll look into this.
Greetings,
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [bootstrappable] GNU Mes 0.23 released
Ludovic Courtès writes: Hello! > Jan Nieuwenhuizen skribis: > >> and now also for armhf-linux and aarch-linux. Work to integrate this >> into Guix is ongoing: tinycc and gcc-core-2.95.3 have been built. > > Woohoo, impressive work! Thanks! > I suppose that will unlock the full-source bootstrap branch, right? Yes! For Guix we'll probably want to finish the ARM bootstrap first, but for mes the coming release is to support the full-source bootstrap. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
GNU Mes 0.23 released
We are happy to announce the release of GNU Mes 0.23, representing 125 commits over one year by four people. Mes was ported to ARM and can now be used in the GNU Guix Reduced Binary Seed bootstrap as described here https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25/ and now also for armhf-linux and aarch-linux. Work to integrate this into Guix is ongoing: tinycc and gcc-core-2.95.3 have been built. We are excited that the Nlnet Foundation is now sponsoring this work! Enjoy, Janneke and Danny. * About GNU Mes[0] is a Scheme interpreter and C compiler for bootstrapping the GNU System. Since version 0.22 it has again helped to halve the size of opaque, uninspectable binary seeds that are currently being used in the Reduced Binary Seed bootstrap[1] of GNU Guix[2]. The final goal is to help create a full source bootstrap as part of the bootstrappable builds[3] effort for UNIX-like operating systems. The Scheme interpreter is written in ~5,000 LOC of simple C, and the C compiler written in Scheme and these are mutual self-hosting. This mes.c is now being simplified to be transpiled by M2-Planet[4]. Mes has a Garbage Collector, a library of loadable Scheme modules-- notably Dominique Boucher's LALR[5], Pre-R6RS portable syntax-case[6] with R7RS ellipsis, Matt Wette's Nyacc[7] --and test suite, just enough to support a REPL and a C99 compiler: mescc. Mes + MesCC + Mes C Library can build a bootstrappable TinyCC[8] that is self-hosting. Using this tcc and the Mes C library we now have a Reduced Binary Seed bootstrap for the gnutools triplet: glibc-2.2.5, binutils-2.20.1, gcc-2.95.3. This is enough to bootstrap Guix for i686-linux, x86_64-linux, armhf-linux and aarch64-linux. Mes is inspired by The Maxwell Equations of Software: LISP-1.5[9] -- John McCarthy page 13, GNU Guix's source/binary packaging transparency and Jeremiah Orians's stage0[10] ~500 byte self-hosting hex assembler. We are very grateful to NLNet for sponsoring the Reduced Binary Seed bootstrap[11] and the ARM port[12]. * Download git clone git://git.savannah.gnu.org/mes.git Here are the compressed sources and a GPG detached signature[*]: https://ftp.gnu.org/gnu/mes/mes-0.23.tar.gz https://ftp.gnu.org/gnu/mes/mes-0.23.tar.gz.sig Use a mirror for higher download bandwidth: https://ftpmirror.gnu.org/mes/mes-0.23.tar.gz https://ftpmirror.gnu.org/mes/mes-0.23.tar.gz.sig Here are the MD5 and SHA1 checksums: e9a0ae6e2c3842cf57fccb54909463ba mes-0.23.tar.gz 0560879358e5a980f7374844c495c92014b47878 mes-0.23.tar.gz [*] Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify mes-0.23.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver keys.gnupg.net --recv-keys 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273 and rerun the 'gpg --verify' command. * Get informed, get involved See https://bootstrappable.org Join #bootstrappable on irc.freenode.net. * NEWS * Changes in 0.23 since 0.22 ** Core *** Mes and Mes C Library can now be built with GCC 10.x. ** MesCC *** The Mes C Library now supports an armhf-linux bootstrap. *** MesCC now supports ARM. *** mini.c library was split into _exit.c, and _write.c. *** When building with GCC, -lgcc is now used. *** MesCC now has it's own support library libmescc.a (-lmescc). *** MesCC now requires mescc-tools-0.7.0 or later for ARM. *** MesCC can be now built with nyacc-1.00.2: note that nyacc-1.03.0 is not (backwards) compatible. *** MesCC can be built with Guile 3.0.x: See https://bugs.gnu.org/43831; use guild compile -O1 with Guile 3.0.x. *** MesCC now raises SIGABRT on abort, if supported. ** Noteworthy bug fixes *** unreadchar on EOF is now a no-op. *** malloc now aligns the blocks it gives out to max_align_t. [0] https://www.gnu.org/software/mes [1] https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25 [2] https://www.gnu.org/software/guix [3] https://bootstrappable.org [4] https://github.com/oriansj/m2-planet [5] https://github.com/schemeway/lalr-scm [6] https://www.cs.indiana.edu/chezscheme/syntax-case/old-psyntax.html [7] https://www.nongnu.org/nyacc [8] https://gitlab.com/janneke/tinycc [9] http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf [10] https://savannah.nongnu.org/projects/stage0 [11] https://nlnet.nl/project/GNUMes [12] https://nlnet.nl/project/GNUMes-arm -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com signature.asc Description: PGP signature
Re: [bootstrappable] Re: Can Guile be bootstrapped from source without psyntax-pp.scm?
Michael Schierl writes: Hello, > Jan Nieuwenhuizen wrote to guile-u...@gnu.org[1] on 07 Jul 2017: >> Mark H Weaver writes: >> >>>> Does this mean Guile is not bootstrappable from source only? >>> >>> That's correct. psyntax-pp.scm is not source code, and it is needed to >>> bootstrap Guile. >> >> I'm facing the same problem with Mes. I have an implemenation of >> syntax-rules that is just about 200 lines of define-macro source code, >> but not syntax case. > >>> Having said this, I agree that it would be better if psyntax.scm were >>> written in such a way that it could be bootstrapped without the use of >>> itself. Maybe some day we'll rewrite it to make it so. >> >> That could be essential to our full source bootstrapping efforts so I'm >> very much interested! > > For the record, I have written a psyntax implementation that can be used > by Guile (3.0.2) and does not require an expanded version of itself. Oh, that's amazing! I see that you are using make-syntax-transformer (and others) which GNU Mes does not support yet; it only has define-macro. This may be a good reason/opportunity to work towards better Guile support in Mes. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Update on wip-arm-bootstrap
Danny Milosavljevic writes:
Hello Danny,
> Nice!
>
> Patch review:
>
>>+#if __ARM_EABI__
>>+#define CLEAR_CACHE(BEG,END) \
>>+{\
>>+ register unsigned long _beg __asm ("a1") = (unsigned long)(BEG); \
>>+ register unsigned long _end __asm ("a2") = (unsigned long)(END); \
>>+ register unsigned long _flg __asm ("a3") = 0;
>>\
>>+ __asm __volatile ("mov r7, 0x9f0002\n\t" \
>
> should be mov r7, 0xf0002 in EABI.
> (SWI #(0x90 + syscallnr) is for OABI syscalls only)
Ok, great; that could help!
>>* sysdeps/unix/sysv/linux/arm/brk.c (__brk): Likewise.Likewise.
>
> Duplicate "Likewise".
>
> Otherwise LGTM!
Thanks. Testing a fixup now (currently only on my branch @gitlab).
>>But something like puts or printf segfaults "Illegal
>>instruction" in strlen:
>
>>--8<---cut here---start->8---
>>(gdb) disas /r
>>Dump of assembler code for function strlen:
>> 0xd160 <+0>: 03 10 c0 e3 bic r1, r0, #3
>>=> 0xd164 <+4>: 04 20 91 e4 ldr r2, [r1], #4
>>--8<---cut here---end--->8---
>
> Hmm... looks good to me? Weird.
Yes...
> I'm building it right now and will have a look.
Great, thanks!
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Update on wip-arm-bootstrap
Danny Milosavljevic writes: > Hi Janneke, > > I get > > gcc-mesboot.sh: line 20: 9438 Illegal instruction (core dumped) ./a.out > > │ 0x276b8 <__writev+32> svc 0x0014 > │ > │ >0x276bc <__writev+36> mov r4, r0 > │ > > The actual problem is at the first line above--the svc with argument != 0. > > #0 0x000276bc in __writev (fd=2, vector=0xbebc54c0, count=10) > at ../sysdeps/unix/sysv/linux/writev.c:51 > > glibc 2.2.5:sysdeps/unix/sysv/linux/writev.c:51 > >> bytes_written = INLINE_SYSCALL (writev, 3, fd, CHECK_N (vector, count), >> count); > > Err hmm?! Hmm, I'm not seeing this (I did see something like this before). You *are* on e44b6b7eed squash! commencement: binutils-mesboot0: Support ARM. right? > You *are* patching INLINE_SYSCALL body-- Yes > so I'd guess that __ARM_EABI__ for some reason is not being defined. > > I'd suggest to #error (or at least #warning) if !__ARM_EABI__. That's a good suggestion; I'm setting it in the glibc-mesboot0 recipe ,(if (equal? triplet "arm-unknown-linux-gnu") " -D __ARM_EABI__=1" ""))) and it "looks like" that's being used in every compilation... Weird, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Update on wip-arm-bootstrap
Jan Nieuwenhuizen writes:
Hi Danny!
>> On Thu, 18 Feb 2021 22:52:57 +0100
>> Jan Nieuwenhuizen wrote:
>> Since this only affects the syscall interface and since also our
>> ELF headers specify EABI, I would just change the syscalls to EABI:
>> Just put the syscall number into r7 and use svc 0.
>
> Oh, if that's all we should be able to find and fix it?
I took a stab at it and created the attached patch, also on
wip-arm-bootstrap now. This allows creating simple binaries using
gcc-core-mesboot0 and glibc-mesboot0 that run, like "return 42" and even
"exit (42)". But something like puts or printf segfaults "Illegal
instruction" in strlen:
--8<---cut here---start->8---
(gdb) disas /r
Dump of assembler code for function strlen:
0xd160 <+0>: 03 10 c0 e3 bic r1, r0, #3
=> 0xd164 <+4>: 04 20 91 e4 ldr r2, [r1], #4
--8<---cut here---end--->8---
makes no sens to me? So, trying to build the first glibc-based gcc
--8<---cut here---start->8---
./pre-inst-env guix build -e '(@@ (gnu packages commencement) gcc-mesboot0)'
--8<---cut here---end--->8---
still fails during configure. Seems like I'm stuck here again,
hopefully you can spot some silly mistake in my patch or have another
helpful insight :-)
Greetings,
Janneke
>From dda9f6d081d68848a1d602c375e0d7a8871e4ae4 Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen"
Date: Sat, 20 Feb 2021 15:32:53 +0100
Subject: [PATCH 8/8] bootstrappable: arm: Support EABI system calls.
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
* sysdeps/unix/sysv/linux/arm/sysdep.h (DO_CALL,INLINE_SYSCALL)
[__ARM_EABI__]: Use eabi calling convention for syscalls.
* sysdeps/arm/dl-machine.h (CLEAR_CACHE): Likewise.
* sysdeps/unix/sysv/linux/arm/brk.c (__brk): Likewise.Likewise.
* sysdeps/unix/sysv/linux/arm/clone.S: Likewise.
* sysdeps/unix/sysv/linux/arm/mmap.S: Likewise.
* sysdeps/unix/sysv/linux/arm/mmap64.S: Likewise.
* sysdeps/unix/sysv/linux/arm/sigrestorer.S: Likewise.
* sysdeps/unix/sysv/linux/arm/socket.S: Likewise.
* sysdeps/unix/sysv/linux/arm/vfork.S: Likewise.
---
sysdeps/arm/dl-machine.h | 14 ++
sysdeps/unix/sysv/linux/arm/brk.c | 10 +
sysdeps/unix/sysv/linux/arm/clone.S | 7 +++
sysdeps/unix/sysv/linux/arm/mmap.S| 7 +++
sysdeps/unix/sysv/linux/arm/mmap64.S | 7 +++
sysdeps/unix/sysv/linux/arm/sigrestorer.S | 14 ++
sysdeps/unix/sysv/linux/arm/socket.S | 7 +++
sysdeps/unix/sysv/linux/arm/sysdep.h | 54 +++
sysdeps/unix/sysv/linux/arm/vfork.S | 14 ++
9 files changed, 134 insertions(+)
diff --git a/sysdeps/arm/dl-machine.h b/sysdeps/arm/dl-machine.h
index 2d802b7..02c48bd 100644
--- a/sysdeps/arm/dl-machine.h
+++ b/sysdeps/arm/dl-machine.h
@@ -32,6 +32,19 @@
&& VALID_ELF_OSABI (hdr[EI_OSABI]) \
&& VALID_ELF_ABIVERSION (hdr[EI_ABIVERSION])
+#if __ARM_EABI__
+#define CLEAR_CACHE(BEG,END) \
+{ \
+ register unsigned long _beg __asm ("a1") = (unsigned long)(BEG); \
+ register unsigned long _end __asm ("a2") = (unsigned long)(END); \
+ register unsigned long _flg __asm ("a3") = 0;\
+ __asm __volatile ("mov r7, 0x9f0002\n\t"\
+ "swi 0x0 @ sys_cacheflush" \
+ : /* no outputs */ \
+ : /* no inputs */ \
+ : "a1","r7"); \
+}
+#else // !__ARM_EABI__
#define CLEAR_CACHE(BEG,END) \
{ \
register unsigned long _beg __asm ("a1") = (unsigned long)(BEG); \
@@ -42,6 +55,7 @@
: /* no inputs */ \
: "a1"); \
}
+#endif // !__ARM_EABI__
/* Return nonzero iff ELF header is compatible with the running host. */
static inline int __attribute__ ((unused))
diff --git a/sysdeps/unix/sysv/linux/arm/brk.c b/sysdeps/unix/sysv/linux/arm/brk.c
index 153d893..d5d0904 100644
--- a/sysdeps/unix/sysv/linux/arm/brk.c
+++ b/sysdeps/unix/sysv/linux/arm/brk.c
@@ -29,12 +29,22 @@ __brk (void *addr)
{
void *newbrk;
+#if __ARM_EABI__
+ asm ("mov a1, %1\n" /* save the argment in r0 */
+ "mov r7, %2\n" /* system call nr in r7 */
+ "swi 0x0\n" /* do the system call */
+ "mov %0, a1;" /* keep the return value */
+ : "=r"(newbrk)
+ : "r"(addr), "i" (SYS_ify (brk))
+ : "a1","r7");
+#else // !__ARM_EABI__
asm ("mov a1, %1\n" /* save the argment in r0 */
"swi %2\n" /* do the system call */
"mov %0, a1;" /* keep the return value */
: "=r"(newbrk)
: "r"(add
Re: Update on wip-arm-bootstrap
Ludovic Courtès writes: Hello, > I read the story, which I found rather fun and full of suspense, but I > admit I was disappointed by the ending. :-) > > Jan Nieuwenhuizen skribis: > >> ...pretty familiar. So, what's going on here? Do the "woody" >> binaries not run on novena? > > Does that mean there are no old reference binaries known to work on > Novena? Not if they are binaries from before Lenny (2009), unless we compile the kernel with OABI support, which as I understand from Danny, is a bad idea. Weird. Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Update on wip-arm-bootstrap
Danny Milosavljevic writes: Hey Danny, > On Thu, 18 Feb 2021 22:52:57 +0100 > Jan Nieuwenhuizen wrote: > >> # CONFIG_OABI_COMPAT is not set >> >> ...certainly a lot easier to find when you know what you're looking >> for. >> >> @Danny: I'm wondering if we could (should?) try a kernel with OABI >> compatibility? I suppose it would be better to somehow target >> EABI...but I'm not sure that's possible with glibc-2.2.5 / gcc-2.95.3. >> Interesting choices here! > > OABI is older than year 2000, and the kernel docs say not to enable it. > It also breaks seccomp. > I doubt that people have it enabled, and thus would have trouble reproducing > our stuff. Okay, I agree; better to not go this route if we can avoid it. > Since this only affects the syscall interface and since also our > ELF headers specify EABI, I would just change the syscalls to EABI: > Just put the syscall number into r7 and use svc 0. Oh, if that's all we should be able to find and fix it? > I'd do it myself but I don't see what libc the gcc 2.95 we built has been > using. > Is it ours? > If so, how come it then uses svc 9... in the first place? > We don't do that. > > Or is it using glibc ? Not it's not ours, it's gcc-core-mesboot0-2.95.3 binaries built against glibc-mesboot0-2.2.5. So then it's probably glibc-2.2.5 that is using/built for OABI. I didn't know of OABI before, but did look for EABI options and didn't find any in those early gcc/glibc's... We'll have to see if that glibc can be built for OABI, possibly by patching it. If we need to upgrade glibc then that may be an "interesting" undertaking... >From Vagrant's link, I found that Lenny (5.0) is the first armel (EABI) release, it uses glibc-2.7, gcc-4.1, binutils-2.18. > How do I build that gcc on novena? Where would the syscall headers that > I could change be? On latest wip-arm-bootstrap 3c78496c32 DRAFT gnu: mes: Update to 0.22-124-33cf5ea5e8. then building ./pre-inst-env guix build -e '(@@ (gnu packages commencement) gcc-mesboot0)' will be using the gcc,glibc,binutils that's broken and configure will fail on running a conftest. You can get the PATH and other environment settings from that build. I have those settings also in a script: novena:~janneke/src/guix/gcc-mesboot.sh is a reproducer. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Update on wip-arm-bootstrap
Vagrant Cascadian writes: Hi! > On 2021-02-13, Jan Nieuwenhuizen wrote: [..] >> ...pretty familiar. So, what's going on here? Do the "woody" >> binaries not run on novena? > > My guess would be OABI (debian "arm" architecture) vs. EABI (debian > "armel" or "armhf" architectures). The hardware may likly support OABI, > but the kernel may need a compatibility layer enabled. > > https://wiki.debian.org/ArmPorts Ah, interesting. The kernel config has # CONFIG_OABI_COMPAT is not set ...certainly a lot easier to find when you know what you're looking for. @Danny: I'm wondering if we could (should?) try a kernel with OABI compatibility? I suppose it would be better to somehow target EABI...but I'm not sure that's possible with glibc-2.2.5 / gcc-2.95.3. Interesting choices here! Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Guix Day: Notes frome the Bootstrap session
Ludovic Courtès writes: Hello, > > Jan Nieuwenhuizen skribis: > >> Attached the notes from the "Bootstrap what's next" session yesterday. > > Thanks for sharing! > >> - Making the guix build system code less dependent on Guile and more >> dependent on MES > > Not necessarily more dependent on Mes :-), but rather portable between > the two. Ah, sure -- my bad for simply forwarding the notes without really reading them, only adding the status update :-/ > On this topic, one action item we identified was to try and see what it > would take to run (guix build gnu-build-system) and the modules it > depends on on Mes. If we can run that on Mes during early bootstrap > (before Guile is built), then that’s a step towards removing the big > ‘%bootstrap-guile’ binary seed. > > These modules require some Guilish module support as well as a bunch of > (ice-9 *) and (srfi *) modules. Perhaps with some tricks such as > autoloads, we can reduce the number of modules actually needed. > > Another option is to write a simplified but compatible subset of (guix > build gnu-build-system) specifically for use during early bootstrap. > > At any rate, the first step is to try to feed that code to Mes and see > what happens. :-) > > If you’ve always wanted to join the bootstrapping movement, now’s your > opportunity! Yes, very nice! Note that we already have some experience with this: the Nyacc project is a Guile library that runs on Mes; only minor modifications were necesary. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Update on wip-arm-bootstrap
c binutils patchelf wget wget http://archive.debian.org/debian/pool/main/g/glibc/libc6_2.2.5-11.8_arm.deb ar x libc6_2.2.5-11.8_arm.deb tar xf data.tar.gz wget http://archive.debian.org/debian/pool/main/g/glibc/libc6-dev_2.2.5-11.8_arm.deb ar x libc6-dev_2.2.5-11.8_arm.deb tar xf data.tar.gz wget http://archive.debian.org/debian/pool/main/b/binutils/binutils_2.12.90.0.1-4_arm.deb ar x binutils_2.12.90.0.1-4_arm.deb tar xf data.tar.gz wget http://archive.debian.org/debian/pool/main/g/gcc-2.95/gcc-2.95_2.95.4-27_arm.deb ar x gcc-2.95_2.95.4-27_arm.deb tar xf data.tar.gz patchelf --print-interpreter usr/bin/as /lib/ld-linux.so.2 patchelf --set-interpreter $PWD/lib/ld-linux.so.2 usr/bin/as usr/bin/as Illegal instruction --8<---cut here---end--->8--- Hmm...does it? Using gdb, the problem looks... --8<---cut here---start->8--- Program received signal SIGILL, Illegal instruction. 0xb6ff3b6c in writev () from /home/janneke/src/debian/lib/ld-linux.so.2 (gdb) disas /r Dump of assembler code for function writev: [..] 0xb6ff3b58 <+28>:05 20 a0 e1 mov r2, r5 0xb6ff3b5c <+32>:07 10 a0 e1 mov r1, r7 0xb6ff3b60 <+36>:00 80 90 e5 ldr r8, [r0] 0xb6ff3b64 <+40>:06 00 a0 e1 mov r0, r6 0xb6ff3b68 <+44>:92 00 90 ef svc 0x00900092 => 0xb6ff3b6c <+48>:00 40 a0 e1 mov r4, r0 --8<---cut here---end--->8--- ...pretty familiar. So, what's going on here? Do the "woody" binaries not run on novena? --8<---cut here---start->8--- $ uname -a Linux novena 5.9.11-gnu #1 SMP 1 armv7l GNU/Linux 10:11:54 janneke@novena:~/src/debian [env] $ readelf -h usr/bin/as ELF Header: Magic: 7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI:ARM ABI Version: 0 Type: EXEC (Executable file) Machine: ARM Version: 0x1 Entry point address: 0x9c34 Start of program headers: 52 (bytes into file) Start of section headers: 267716 (bytes into file) Flags: 0x2, GNU EABI, Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 7 Size of section headers: 40 (bytes) Number of section headers: 25 Section header string table index: 24 --8<---cut here---end--->8--- Overdrive1 seems to think so, and respects "fail early" --8<---cut here---start->8--- $ uname -a Linux overdrive1 5.8.13-gnu #1 SMP 1 aarch64 GNU/Linux 10:18:39 janneke@overdrive1:~/src/debian [env] $ usr/bin/as bash: usr/bin/as: cannot execute binary file: Exec format error --8<---cut here---end--->8--- Hmm? Greetings, Janneke & Danny -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Guix Day: Notes frome the Bootstrap session
Hello Guix! Attached the notes from the "Bootstrap what's next" session yesterday. Greetings, Janneke - Branch wip-arm-bootstrap is getting ready but stuck at glibc-mesboot0, when finished: release mes-0.23. - Branch wip-full-source-bootstrap is ready for review; wait with merge until wip-arm-bootstrap? When finished, relase mes-0.24. - Support for PowerPC and RISC-V - Submitting a GSOC proposal to have a student help out with some of the problems ^^ - Building for PowerPC isn't straightforward. You'd need actual h/w to test things out. - Making the guix build system code less dependent on Guile and more dependent on MES - PowerPC + Glibc+GCC version combination during bootstrap is problematic on PowerPC. + Glibc changes introduces uncertainty. + Branch with bootstrap binaries is ready for merging: https://git.sr.ht/~lle-bout/guix/log/wip-ppc64le -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
Efraim Flashner writes: Hi! > On Wed, Jan 20, 2021 at 03:19:49PM -0500, Timothy Sample wrote: >> Hi janneke, >> >> Jan Nieuwenhuizen writes: >> >> It looks like you’ve made a lot of progress on this already (judging by >> the rest of this thread). However, if it helps, the current Gash-Utils >> awk could _probably_ be used to skip most (all?) of the old versions of >> Gawk. >> >> Sorry I can’t be more helpful ATM. I appreciate the work you do to keep >> this project rolling! >> > > Using this post as inspiration I replaced diffutils-mesboot with > gash-utils-boot. diffutils-mesboot provided cmp and diff, both of which > are available in gash-utils. Oh, that's nice. It would be good to get rid of as much unspported software releases as we can. > Unfortunately sed from gash-utils-boot > didn't seem to work so I wasn't able to remove that. Yeah, distilling a nice bug report for that can take quite some time. Greetigns, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Building Guile with ‘-j1’?
Ludovic Courtès writes: Hello, > As the saying goes, “the cobbler’s children go barefoot”. Guile/Guix > are no exception since Guile builds are non-reproducible, despite work > done a few years ago: > > https://issues.guix.gnu.org/20272 Ugh. Thanks for bringing this up again. Would you consider disabling parallel builds in Guile by default, adding something like a "--enable-somewhat-faster-non-reproducible-build" configure option until this is fixed? > Until it’s fixed in Guile proper, what do you think of building Guile > 2.0/2.2/3.0 with #:parallel-build? #f ? We could do that in > ‘core-updates’ now. > > That would work around the problem for Guile itself. It would increase > build times, but probably not that much since the most expensive part > (compiling the first few files) is sequential anyway. IIRC this is what > Vagrant did for the Debian packages. Yes, I would support at least doing this. > We could also disable parallel builds in ‘guile-build-system’. It’s > only used for small packages so the extra build time is probably OK. Are packages using guile-build-system expected to build non-reproducible too? In that case, I would certainly support doing it there. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 04/06: services: hurd-vm: Avoid circular dependency with (gnu system images hurd).
Hi! On current master, the disk-size setting on a childhurd has no effect, leaving very little disk space to do development. I am suspecting this commit > commit 859b362f81598830d7ff276b96a8724aee3c4db7 > Author: Ludovic Courtès > AuthorDate: Mon Dec 7 12:38:25 2020 +0100 > > services: hurd-vm: Avoid circular dependency with (gnu system images > hurd). > > * gnu/services/virtualization.scm (hurd-vm-disk-image): Use > 'lookup-image-type-by-name' instead of referring to 'hurd-disk-image' > from (gnu system images hurd). > --- > gnu/services/virtualization.scm | 15 ++- > 1 file changed, 6 insertions(+), 9 deletions(-) > > diff --git a/gnu/services/virtualization.scm b/gnu/services/virtualization.scm > index eaf0bbd..f435630 100644 > --- a/gnu/services/virtualization.scm > +++ b/gnu/services/virtualization.scm [..] > @@ -913,14 +912,12 @@ that will be listening to receive secret keys on port > 1004, TCP." > (define (hurd-vm-disk-image config) >"Return a disk-image for the Hurd according to CONFIG. The secret-service > is added to the OS specified in CONFIG." > - (let ((os (secret-service-operating-system (hurd-vm-configuration-os > config))) > -(disk-size (hurd-vm-configuration-disk-size config))) > -(system-image > - (image > - (inherit hurd-disk-image) > - (format 'compressed-qcow2) > - (size disk-size) > - (operating-system os) This system-image included (size disk-size), and here > + (let* ((os(secret-service-operating-system > + (hurd-vm-configuration-os config))) > + (disk-size (hurd-vm-configuration-disk-size config)) > + (type (lookup-image-type-by-name 'hurd-qcow2)) > + (os->image (image-type-constructor type))) > +(system-image (os->image os disk-size goes unused. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
Danny Milosavljevic writes:
Hi Danny,
> On Fri, 8 Jan 2021 19:56:19 +0100
> Danny Milosavljevic wrote:
>
>> The CI on nanana is currently building and running the tests.
>>
>> I'm curious what it will say.
>
> Tests succeeded.
>
> Pushed to mes on savannah as commit 10c38e112f177bc0b01ecf107d193e4c6b13
> ("wip" branch).
Lovely, thanks!
I'll inject it into wip-arm-bootstrap and see what happens. Especially
I hope we'll be able to remove these hacks
--8<---cut here---start->8---
ebd1a594 HACK bootstrappable: ARM: "tccgen_ok".
8d475711 HACK bootstrappable: ARM: "tccpp_ok".
--8<---cut here---end--->8---
from bootstrappable tinycc.
Greetings,
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
Danny Milosavljevic writes:
Hi Danny,
> I propose to, instead, change mes libc to align stuff malloc returns like
> this:
>
> That should fix it.
That's great; I'd like to go test this. Would you like to push to "wip"
when you're ready?
> diff --git a/include/stddef.h b/include/stddef.h
> index a597c9bb..a682d726 100644
> --- a/include/stddef.h
> +++ b/include/stddef.h
> @@ -37,6 +37,10 @@
> #endif // !__MESC__
> #endif // offsetof
>
> +/* TODO: On armhf gcc, max_align_t is 16 Byte big instead. Use that? */
> +
> +typedef double max_align_t;
> +
> #endif // ! SYSTEM_LIBC
Is this something you can get more info on, or do we just try it like
this?
> #endif // __MES_STDDEF_H
> diff --git a/lib/stdlib/malloc.c b/lib/stdlib/malloc.c
> index f4be4de1..aaf99886 100644
> --- a/lib/stdlib/malloc.c
> +++ b/lib/stdlib/malloc.c
> @@ -20,6 +20,8 @@
>
> #include
> #include
> +#include
> +#include
>
> /* FIXME: We want bin/mes-mescc's x86-linux sha256sum to stay the same.
> Therfore we cannot remove stdlib/malloc from libc_SOURCES, which is
> @@ -37,6 +39,8 @@ malloc (size_t size)
> {
>if (!__brk)
> __brk = (char *) brk (0);
> + /* align what we give back. */
> + __brk = (char*) (((uintptr_t) __brk + sizeof(max_align_t) - 1) &
> -sizeof(max_align_t));
>if (brk (__brk + size) == -1)
> return 0;
>char *p = __brk;
Very nice, thanks!!
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [Tinycc-devel] [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
Danny Milosavljevic writes: Hi Danny, Grishka! > On Fri, 08 Jan 2021 08:16:29 +0100 > grischka wrote: > >> But no such thing happens in this case. The 'ptr' in init_putv() >> comes from >> >> ptr = sec->data + c; >> >> and it seems that if tcc is doing the right thing then 'c' cannot >> be misaligned, and if malloc/realloc on that system is doing the >> right thing, then sec->data cannot be misaligned either. So...? > > How does tcc allocate dynamic memory? I've tried to find out, but > tcc_malloc is defined to be "use_tcc_malloc", which I don't find > anywhere. Does it use libc malloc for that ? > > (With MEM_DEBUG defined, tcc_malloc_debug seems to use malloc. But > what about without MEM_DEBUG defined ?) > > If so, is libc malloc supposed to ensure alignment of allocated memory? > > According to https://man7.org/linux/man-pages/man3/malloc.3.html yes. > > @Janneke: So our mes libc malloc should be aligning the stuff--but it's not > doing it. So it's a bug in our libc. Beautiful! Maybe this explains other differences we saw between aarch64-linux and arm-linux? Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [Tinycc-devel] [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
> Jan Nieuwenhuizen wrote: Hello Arnold! >> to the gawk-mesbot0 recipe also fixes "inc.awk". The pre >> increment/decrement code looks like this: >> >> --8<---cut here---start->8--- >> *lhs = make_number(lval + >> (tree->type == Node_preincrement ? 1.0 : -1.0)); >> >> --8<---cut here---end--->8--- > > What in the world? That looks like gawk 3.x code, which is > terribly ancient. What project is still using a version that old? We are removing binary seeds from the GNU Guix package graph. The binary packages in Guix form an acyclic graph and at the bottom of the graph we originally had binutils, glibc, gcc, bash, coreutils (gawk, gzip, sed, tar, ...). Since 2016 we have been working to eliminate those binary seeds. For a complete overview and more background see https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/ https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/ but what we did is remove all those, replacing them by Stage0, GNU Mes, tinycc...and multiple versions of ancient GNU tools. Using ancient tools is less than great, we are using those because "it works" or rather, we didn't succeed as yet using newer versions. Often, newer versions of a software are more demanding in their requirements and are less bootstrappale. In other cases, ancient software does not build with newer tools, because they are more strict. > Arnold > (The gawk maintainer) Thanks for reaching out! Sadly I do not have more concrete information (let alone a bug report or feature request) for you yet, other than that we are using gawk-3.0.0, lateron v3.1.8, and only finally v5.0.1. Simalarly for other tools. The biggest hudle was bootstrapping glibc and gcc, as you can imagine. Currently, we start with gcc-2.95.3 and I would very much like to target gcc-4.6.4 directly instead. For a tool as gawk, it would be great to be able to the latest greatest! Greetings, Janneke (GNU Mes author) -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
to get tcc's ARM binaries to run on Aarch64-Linux. Is this
related; iow, could it be that this "fix" for Aarch64 break ARM?
> tinycc does have:
>
> /* reserve at least 'size' bytes aligned per 'align' in section
>'sec' from current offset, and return the aligned offset */
> ST_FUNC size_t section_add(Section *sec, addr_t size, int align)
> {
> size_t offset, offset1;
>
> offset = (sec->data_offset + align - 1) & -align;
> offset1 = offset + size;
> if (sec->sh_type != SHT_NOBITS && offset1 > sec->data_allocated)
> section_realloc(sec, offset1);
> sec->data_offset = offset1;
> if (align > sec->sh_addralign)
> sec->sh_addralign = align;
> return offset;
> }
>
> But that's not used for init_putv.
OK.
> And section_reserve, which is used, doesn't care about alignment at all.
>
> (it seems there's a reserved part and a data part in each section, and
> it holds that the data part elements are aligned--but the reserved part
> elements are NOT aligned. I don't see how sec->data would be aligned
> by the dynamic memory allocator either)
>
> Other notes:
>
> tccgen.c even has this:
>
>>/* XXX: when cross-compiling we assume that each type has the
>> same representation on host and target, which is likely to
>> be wrong in the case of long double */
>
> Yeah, and even when NOT cross-compiling, the alignment is wrong--which means
> it sometimes won't work at all on ARM, depending on luck.
>
> As a workaround, we can patch tcc to instead do the assignments on elements
> on the stack and then copy those over, instead of doing
>
> *(double *)ptr = vtop->c.d
>
> (the latter of which emits VFP instructions that expect double-aligned
> pointers).
So alignment should be fixed, but that's more work and you propose a
workaround, right? I'm struggling to understand the implications of
this last bit...guessing you will be preparing a patch for the mes-0.23
branch of our "bootstrappable tinycc"? Oh, and we need that same patch
for plain tcc-0.9.27, for "tcc-boot" of course!
Greetings,
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [bootstrappable] wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
Paul Sherwood writes: Hello Paul, > On 2021-01-04 17:01, Jan Nieuwenhuizen wrote: >> I have reset Guix' wip-full-source-bootstrap branch with a first >> working >> implementation of the, well, "Full Source Bootstrap" for x86-linux (and >> x86_64-linux). This bootstrap is rooted in the 357-byte hex0-seed from >> the Stage0 project (https://savannah.gnu.org/projects/stage0): > > This is really exciting, great job Jan! Do you need any help, e.g. on > the ARM side, or with optimising the integration? Thanks! We really could use help with this (Danny?). To paint the picture for people listening in: Next to ARM it may need some Guix skills, or even more work to reproduce our experimental ARM bootstrap outside of Guix. I'm a bit hesitant about the timing, because I cannot make much time the coming week. A very short summary of where we are, on wip-arm-bootstrap, building gawk-mesboot0 --8<---cut here---start->8--- ./pre-inst-env guix build -e '(@@ (gnu packages commencement) gawk-mesboot0)' --8<---cut here---end--->8--- produces a gawk binary that fails to increment a variable --8<---cut here---start->8--- 11:35:59 janneke@novena:~/src/wip-arm-bootstrap [env] $ /gnu/store/f756xxxqj3mabaax5r4ldrxh01a9q54r-gawk-mesboot0-3.0.0/bin/gawk -f add.awk add.awk i=1 i=2 11:36:14 janneke@novena:~/src/wip-arm-bootstrap [env] $ /gnu/store/f756xxxqj3mabaax5r4ldrxh01a9q54r-gawk-mesboot0-3.0.0/bin/gawk -f inc.awk inc.awk i= 0 i= 0 11:36:27 janneke@novena:~/src/wip-arm-bootstrap [env] --8<---cut here---end--->8--- So could be anything, could bin in tcc-boot or in gawk-mesboot0... Thanks for reaching out! Greetings, Janneke add.awk Description: Binary data inc.awk Description: Binary data -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Guile 2.0 in make-bootstrap.scm
Ludovic Courtès writes: Hello Ludo! > > While uploading the powerpc64le-linux tarballs, I noticed they use Guile > 2.0, which reminded me of eef44fea17a735d2f4048a747d16af478d4b9dbc: > > Revert "gnu: guile-static-stripped: Update to 2.2." > > As discussed on IRC, keeping bootstrap Guile on 2.0 simplifies adding new > architectures and removes the need for parameterizing > gnu/packages/bootstrap.scm. > > This reverts commit 2acfe022a740f79b593348cc6362cc4ee8f33bb4. > > * gnu/packages/make-bootstrap.scm (%guile-static): Revert to guile-2.0. > Retain > build recipe. > * gnu/packages/patches/guile-relocatable.patch: Update for Guile 2.0.14. > > Do you remember the reason for this change? I remember we hesitated gratuitously updating the %bootstrap-guile seed (to 2.2) and decided to try to "make it work without updating the guile seed". I am not 100% sure, we'd have to look up the IRC discussions. > What’s surprising is that > <https://ftp.gnu.org/gnu/guix/bootstrap/i686-linux/20190815> does use > 2.2. Oh, that's weird. Well, we used gule-2.2 until almost the very last moment, I remember. I am cc'ing Timothy, as he helped make the guile-2.0 bootstrap possible (gash compatibility and such). Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
Hi! I have reset Guix' wip-full-source-bootstrap branch with a first working implementation of the, well, "Full Source Bootstrap" for x86-linux (and x86_64-linux). This bootstrap is rooted in the 357-byte hex0-seed from the Stage0 project (https://savannah.gnu.org/projects/stage0): --8<---cut here---start->8--- $ ./pre-inst-env guix build hello --verbosity=1 [..] /gnu/store/w61gf93yn2bxwyc6d1xp4y9lavvw1l3d-hello-2.10 17:58:54 janneke@dundal:~/src/guix/wip-fsb [env] --8<---cut here---end--->8--- (it runs too!). When you look at the bottom of the graph (see attached), you will notice "%bootstrap-guile": the driver that we use for the Guix build and also for "bootar", "gash", and "gash-utils". This "%bootstrap-guile" is not used as a seed in anything that is built, "%bootstrap-guile", "bootar", "gash", and "gash-utils" could be replaced with any other driver. Two new packages are added: "bootstrap-seeds", which contains the hex0-seed binary (https://github.com/oriansj/bootstrap-seeds/blob/master/POSIX/x86/hex0-seed) with ASCII-equivalent (https://github.com/oriansj/bootstrap-seeds/blob/master/POSIX/x86/hex0_x86.hex0), and "m2-planet-boot" which, starting from hex0, via hex1, M0, hex2 and M1, bootstraps the M2-Planet transpiler. M2 is a language that closely resembles a subset of C. The breakthrough is that this M2-Planet can now compile a version of GNU Mes, as yet unreleased: the wip-m2 branch. This removes the remaining binary seeds: %bootstrap-mescc-tools and %bootstrap-mes, together with the "%bootstrap-mes-rewired" hack. Apart from a review there is still some work before it can be integrated, in short (from the top commit message): XXX TODO: * wip-full-source-bootstrap - release mes-0.24, update - possibly release m2-planet-1.8.0, update - rebase wip-full-source-bootstrap onto core-updates - integrate * wip-arm-bootstrap - finish; currently stuck on gawk-mesboot0 - release mes-0.23 - devise strategy for integrating wip-full-source-bootstrap and wip-arm-bootstrap Greetings, Janneke *) https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-full-source-bootstrap gcc-core-mesboot0-graph.dot Description: Binary data -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: wip-arm-bootstrap: Reduced binary seed bootstrap
Ludovic Courtès writes: Hi! > Jan Nieuwenhuizen skribis: > >> I pushed an initial wip-arm-bootstrap that builds up to tcc-boot: >> >> ./pre-inst-env guix build -e '(@@ (gnu packages commencement) tcc-boot)' >> >> >> Danny did a terrific job on armhf-linux support for GNU Mes and we are >> getting close to release v0.23. What's known to be missing is "setjmp" >> support for tcc/gcc. And, of course, for the Reduced binary seed >> bootstrap to work on ARM! > > Woohoo, thumbs up for this great milestone, hackers! Thanks!! >> Anyway, the problem I'm looking at now is that while tcc-boot builds on >> an ARM box, it does not build on aarch64-linux, i.e. this >> >> ./pre-inst-env guix build --system=armhf-linux \ >> -e '(@@ (gnu packages commencement) tcc-boot0)' >> >> fails on overdrive1. > > That’s “interesting”. Did you eventually find a lead? Yes, I added '|| BOOTSTRAP' in tccelf.c: --8<---cut here---start->8--- #if defined (TCC_ARM_EABI) || BOOTSTRAP ehdr.e_ident[EI_OSABI] = 0; ehdr.e_flags = EF_ARM_EABI_VER4; if (file_type == TCC_OUTPUT_EXE || file_type == TCC_OUTPUT_DLL) ehdr.e_flags |= EF_ARM_HASENTRY; if (s1->float_abi == ARM_HARD_FLOAT) ehdr.e_flags |= EF_ARM_VFP_FLOAT; else ehdr.e_flags |= EF_ARM_SOFT_FLOAT; #else ehdr.e_ident[EI_OSABI] = ELFOSABI_ARM; #endif --8<---cut here---end--->8--- this should be investigated a bit further. Compiling with TCC_ARM_EABI fails (which should work, really), but for this linking stage we need it set to produce an aarch64-linux-compatible ELF header. Dunno! > Thanks for the update, it’s exciting! You're welcome! Meanwhile, I built gcc-core-mesboot0 (2.95.3). However, that's using bash from %bootstrap-coreutils The last thing I did was to investigate into bash-2.05b and found that bash depends on a working setjmp/longjmp for tinycc. I tried several versions of macro substitution on x86 instead of setjmp/longjmp, but that doesn't seem possible: subshells and such. So Danny, would you like to look at that? Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: wip-arm-bootstrap: Reduced binary seed bootstrap
Jan Nieuwenhuizen writes: Hello, > I pushed an initial wip-arm-bootstrap that builds up to tcc-boot: Just a headsup: I have reset wip-arm-bootstrap. This version actually builds tcc-boot using mes-boot (the previous one only worked when cheating by using %bootstrap-guile). Also, the aarch64-linux problem has been fixed, so that this --8<---cut here---start->8--- ./pre-inst-env guix build --system=armhf-linux \ -e '(@@ (gnu packages commencement) tcc-boot)' --8<---cut here---end--->8--- now works on overdrive1. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
wip-arm-bootstrap: Reduced binary seed bootstrap
Hi! I pushed an initial wip-arm-bootstrap that builds up to tcc-boot: --8<---cut here---start->8--- ./pre-inst-env guix build -e '(@@ (gnu packages commencement) tcc-boot)' --8<---cut here---end--->8--- Danny did a terrific job on armhf-linux support for GNU Mes and we are getting close to release v0.23. What's known to be missing is "setjmp" support for tcc/gcc. And, of course, for the Reduced binary seed bootstrap to work on ARM! In the previous status report https://lists.gnu.org/archive/html/bug-mes/2020-12/msg2.html I was stuck trying to get floats to work in tinycc but last weekend I finally managed to bootstrap tcc, with long longs and floats enabled. (this all took quite some effort). Moving this into Guix should have been almost trivial...but some silly "things" happened such as me working off a dirty mes build tree; took me several days to find. Anyway, the problem I'm looking at now is that while tcc-boot builds on an ARM box, it does not build on aarch64-linux, i.e. this --8<---cut here---start->8--- ./pre-inst-env guix build --system=armhf-linux \ -e '(@@ (gnu packages commencement) tcc-boot0)' --8<---cut here---end--->8--- fails on overdrive1. What's next? * Fix the aarch64-linux problem, * the current wip-arm-bootstrap is based on master: it needs to be rebased on core-updates, * the rest of the bootstrap needs attention, * which probably means supporting "setjmp" in the Mes C Library on ARM * remove binary seeds for binutils, gcc, glibc, coreutils, * verify the x86 bootstrap still works, * and the current version of tcc-boot0 applies two inexplicable hacks 477134b1 HACK bootstrappable: ARM: "tccgen_ok". 33b60f03 HACK bootstrappable: ARM: "tccpp_ok". that would be great to understand and get rid of, * and IWBN to fix Gash's stacktraces on failing exec configure: error: 'mescc' failed to compile conftest.c. Backtrace: In unknown file: ?: 19 [apply-smob/1 #] [..] In gash/shell.scm: 165: 1 [sh:exec-let () "./conftest" "triplet"] In unknown file: ?: 0 [execle "./conftest" # "./conftest" ...] ERROR: In procedure execle: ERROR: In procedure execle: No such file or directory Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Some emacs stuff to activate/deactivate guix profiles
pinoaffe writes: Hello, > I've attached the reusable stuff in guix-profiles.el, and my personal > config in init-profiles.el. > Any thoughts? My emacs-guix already has a file called guix-profiles.el; how do you handle that or how do I best look at / try your profiles? This looks interesting; I'm using M-x guix-set-emacs-environment a lot but my biggest problem/gripe with that is that it's global. Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Xen hypervisor
Danny Milosavljevic writes:
> Hi Janneke,
>
> with our (gnu bootloader grub) already supporting multiboot, it would be easy
> for us to add official support for the Xen hypervisor & Linux.
>
> I've already packaged xen and it's ready to be used.
>
> In order to boot Xen, the grub config should read something like this:
Nice; this could help a lot with hurd work, notably 64bit/x86_64 and SMP
work, IIUC.
> Note especially that "multiboot" is "/xen-4.1-amd64.gz", and that "module"
> statements are used for the linux kernel and for the initrd.
OK.
> The work you have been doing for the Hurd already fetches both the "multiboot"
> and the "module" parameters from the boot-parameters via
> boot-parameters->menu-entry.
>
> But I can't find how I can set the multiboot-modules in my operating-system
> definition.
Yes,..currently, you only can if you're "hurd":
gnu/system.scm has:
--8<---cut here---start->8---
(define (boot-parameters->menu-entry conf)
(let* ((kernel (boot-parameters-kernel conf))
(multiboot-modules (boot-parameters-multiboot-modules conf))
(multiboot? (pair? multiboot-modules)))
--8<---cut here---end--->8---
and
--8<---cut here---start->8---
(define (operating-system-multiboot-modules os)
(if (operating-system-hurd os) (hurd-multiboot-modules os) '()))
--8<---cut here---end--->8---
> Like,
>
> (operating-system
> (kernel (file-append xen "/boot/xen.gz"))
> (multiboot-modules (list linux-libre initrd)))
Yes, we need some an indirection. There already is
--8<---cut here---start->8---
(define (hurd-multiboot-modules os)
(let* ((hurd (operating-system-hurd os))
(root-file-system-command
(list (file-append hurd "/hurd/ext2fs.static")
"ext2fs"
"--multiboot-command-line='${kernel-command-line}'"
"--host-priv-port='${host-port}'"
"--device-master-port='${device-port}'"
"--exec-server-task='${exec-task}'"
"--store-type=typed"
"--x-xattr-translator-records"
"'${root}'" "'$(task-create)'" "'$(task-resume)'"))
...
--8<---cut here---end--->8---
> Also, how do I get guix's usual initrd into that multiboot-modules list ?
Yes, that's another thing that would need to change, if you look at
gnu/bootloader/grub.scm has:
--8<---cut here---start->8---
(define* (grub-configuration-file config entries
...
(if linux
(let ((arguments (menu-entry-linux-arguments entry))
...
(let ((kernel (menu-entry-multiboot-kernel entry))
...
--8<---cut here---end--->8---
we don't do multiboot when we're doing linux.
> Do you think it would make sense to adapt boot-parameters->menu-entry
> slightly so one could specify both a multiboot kernel and a linux kernel
> at the same time? Or would that be too magical?
Hmm, I'd have to see the patch ;-) We need a parameterisation, not sure
if splitting case LINUX in two is preferrable over a third flavor.
HTH!
Greetings,
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Guix now in Debian experimental!
Vagrant Cascadian writes: Hello! > It's been a long haul getting all the build dependencies of guix into > Debian, but it has finally paid off: > >https://tracker.debian.org/pkg/guix > > So now you can install guix from Debian's experimental distribution! That's an amazing achievement, congratulations! Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Porting Guix to RISCV
Vagrant Cascadian writes: Hey! > On 2020-10-31, Pjotr Prins wrote: >> Anyone interested in porting GNU Mes and GNU Guix to RISCV? ...trying not to get noticed, /me looks at their full plate (cough Mes + ARM) and then slowly looks over shoulder... >> We can try >> and purchase the hardware. We have a Polarfire running >> >> https://www.crowdsupply.com/microchip/polarfire-soc-icicle-kit >> >> and there are more options coming. I am happy to support such an >> initiative and buy the hardware. > > I added a few RISC-V related packages to guix already: > > u-boot-qemu-riscv64 > u-boot-qemu-riscv64-smode > u-boot-sifive-fu540 > opensbi-sifive-fu540 > opensbi-qemu-sifive-u > linux-libre-riscv64-generic > > Got as far as booting a kernel in qemu, at least. So the basic boot > infrastructure is at least partly there... > > So, I guess you could count me as interested. :) Great! Anyway, runing RISC-V on Guix (can I dream "the Hurd"?) is an amazing perspective, so count me in! Did anyone try building bootstrap binaries for RISC-V? Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Guix Front End (GUI) and making it more mainstream, popular in scientific community.
Pierre Neidhardt writes: > Ludovic Courtès writes: > >> This reminds me of Janneke’s Guimax: >> >> https://gitlab.com/janneke/guimax >> >> It’s rather about providing a Guile UI, but perhaps it could also serve >> as the basis of a Guix GUI? > > I haven't heard about this, thanks for the hint, I'll look into it! It's possibly more worthwile to look at Nomad; the interesting theme of both is: fully guile-based gui with emacsy integration. So, a self-documenting gui program in Guile. Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Advantages over Nix?
Taylan Kammer writes: Hi Taylan, > Personally I'm a GNU-lover and a Scheme-lover so it's obvious why I > would choose Guix over Nix. :-) > TL;DR: sell Guix (over Nix) to someone who doesn't care about GNU or > Scheme? Have you seen Daniel Schaefer's Peering into the Land of Parentheses? https://www.youtube.com/watch?v=bDGzCXr6VYU Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [BLOG] Childhurds and GNU/Hurd substitutes
zimoun writes: Dear Simon, > Thank you for the help! I have fun. :-) Good! > On Wed, 14 Oct 2020 at 16:15, Jan Nieuwenhuizen wrote: > I do not know if it was bad luck or if "herd start ssh" does the trick > but here we go! \o/ > > $ ssh -p 10022 root@localhost > The authenticity of host '[localhost]:10022 ([127.0.0.1]:10022)' can't > be established. > ECDSA key fingerprint is SHA256:iETZ8thOyFqk+35g02tRW9FRzLqilgYYlxWr/9xn/kI. > Are you sure you want to continue connecting (yes/no)? yes > Warning: Permanently added '[localhost]:10022' (ECDSA) to the list of > known hosts. > > > This is the GNU Hurd. Welcome. > > Thank you. \o/ >> > Last, I am confused: >> > >> >debian$ guix build hello --target=i586-pc-gnu hello >> >/gnu/store/09sz4qsqp3zgnbaxhzppspaxihwmfzll-hello-2.10 > > [..] > >> It's tricky; --target is != --system: --target is a cross-build. IOW, >> --system => (%current-system), --target => (%current-target-system). >> >> So, >> >> guix build hello --system=i586-gnu hello >> >> should give the identical hash. > > What is the target? i586-pc-gnu or i586-gnu? The blog post mentions > 'i586-pc-gnu' at the beginning and then 'i586-gnu'. I suppose it is > 'i586-gnu' since using this target produces the expected hash. > What do I miss? Yeah, this can be confusing. The target is a triplet (https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html), e.g. i586-pc-gnu, x86_64-unknown-linux-gnu; system is specified by the platform, or interpreter name; see e.g. gnu/packages/bootstrap.scm: glibc-dynamic-linker for a list of platforms. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [BLOG] Childhurds and GNU/Hurd substitutes
zimoun writes: Dear Simon, > On Thu, 08 Oct 2020 at 15:34, Jan Nieuwenhuizen wrote: > >> We have just published a blog post on building your own Guix System with >> GNU/Hurd and running it in a virtual machine; the road we traveled since >> beginning of April and what is possible right now. Read it here: >> >> https://guix.gnu.org/en/blog/2020/childhurds-and-substitutes/ > > Amazing! Thanks! > On foreign distro, I have missed how to setup the “childhurd“. The > “guix system” is still a bit mysterious to me… Yeah, guix system in essence "just" builds a disk-image (aka vm-image). Then, qemu can start that image. > Using this command line (from gnu/system/examples/bare-hurd.tmpl): > > guix environment --ad-hoc qemu \ > -- qemu-system-i386 -enable-kvm -m 512 \ > -device rtl8139,netdev=net0 -netdev > user,id=net0,hostfwd=tcp:127.0.0.1:10022-: \ > -snapshot -hda \ > $(guix system disk-image -t hurd-raw bare-hurd.tmpl) > > it is telling me that the ’ssh’ service is not started. Therefore, > > ssh -p 10022 root@localhost > ssh: connect to host localhost port 10022: Connection refused > > What do I miss? I have no idea. This exact command works for me. Maybe you had bad luck/try again? Does `herd start ssh' work after you login as root? It could be that your "bad luck" comes from qemu networking -- maybe you could try running your foreign distro's qemu instead of guix's? > Then, > > login> login root RET RET > root@guixygnu ~# $(guix build hello)/bin/hello > > downloads, builds, and displays as expected “Hello, world!”. \o/ \o/ > Last, I am confused: > >debian$ guix build hello --target=586-pc-gnu hello >/gnu/store/09sz4qsqp3zgnbaxhzppspaxihwmfzll-hello-2.10 > >root@guixygnu ~# guix build hello >/gnu/store/-hello-2.10 > > What do I miss? It's tricky; --target is != --system: --target is a cross-build. IOW, --system => (%current-system), --target => (%current-target-system). So, guix build hello --system=i586-gnu hello should give the identical hash. > (Sorry for these naive questions.) You're welcome. Thanks for looking at this! > Thank you! All is really neat! Hehe, that's what we are doing it for; Have fun! Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [PATCH] installer: Add Emacs EXWM desktop environment. [WAS Re: Call for 1.2 installer testing.]
Mathieu Othacehe writes: Hi Mathieu, >> It works for me; I found Emacs EXWM missing however. After zenny also >> asked about that this morning, I decided to create a patch. > > Thanks for testing Using it is real easy, pleasant, and fast. One thing that I got wrong a couple of times is to actually select a suggested option while partitioning, I pressed TAB and RET (like in previous screens), then selecting the button that is clearly marked EXIT. Then it tries to continue with a non-partitioned or badly partitioned drive, which then may give an unexpected error. Clearly a user error, not a problem and I also do not have a better suggestion. Also, my mistake was very obvious to me later. > and for the patch! I think it might be necessary to > add "emacs-exwm" to "installation-target-os-for-gui-tests" in (gnu tests > install) module. Good call. I verified that the test fails without it.. > To make sure that it's working fine you can run: > > make check-system TESTS="gui-installed-os gui-installed-os-encrypted > gui-installed-desktop-os-encrypted" --8<---cut here---start->8--- cannot build derivation `/gnu/store/7xnhrap7xsv2x717yn9wrgisxpppxrmy-emacs-27.1.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/kkfdhpc81h0f0sz0mj1ayin0sxy7vkmq-emacs-desktop-environment-0.3.0.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/3amvkhwa4jv8fghljgkcvlkpg4mpwc8v-emacs-exwm-0.24.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/q4pxd90hb9mah7cs9r1cjyb2pif1ixmz-emacs-xelb-0.18.drv': 1 dependencies couldn't be built --8<---cut here---end--->8--- and veried that it passes when I adding them. > Otherwise, it looks fine. Thanks, pushed to master as 1197b8b20f4fca4ce03bbc5fa75e18d54e3717c0. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Declarative /etc/guix/acl?
Ludovic Courtès writes: Hello, > Jan Nieuwenhuizen skribis: > >> Ludovic Courtès writes: > >> However, if you have your own substitute server, you now can run guix >> archive --authorize < ..., e.g. at bootstrap/install time. For such >> cases, IWBN to have a --authorized-key argument to guix build / guix >> system. > > There’s already an ‘authorized-keys’ field in ‘guix-configuration’: > > > https://guix.gnu.org/manual/devel/en/html_node/Base-Services.html#index-guix_002dconfiguration > > So you would just list keys there. Is that what you have in mind? > > The option is already there, it’s just non-authoritative. I was thinking about the initial installer scenario; when guix-daemon is already running and you didn't build the guix system yourself. But yeah, I guess this is an exceptional or corner case and you can always build your own installer and add the key there. Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: branch master updated: gnu: gettext-minimal: Mark "test-raise" test XFAIL on the Hurd.
Ludovic Courtès writes:
Hi!
> Jan Nieuwenhuizen skribis:
>
>>> commit 2fc298d19c5256eb5609aae7bd35bada59d91685
>>> Author: Jan (janneke) Nieuwenhuizen
>>> AuthorDate: Mon Oct 5 11:58:16 2020 +0200
>>>
>>> gnu: gettext-minimal: Mark "test-raise" test XFAIL on the Hurd.
>>>
>>> * gnu/packages/gettext.scm (gettext-minimal)[arguments]: When compiling
>>> for
>>> the Hurd, add "test-raise" to XFAIL_TESTS in make-flags.
>>
>> Some more info on this bug, it is this snippet that causes
>> the test failure
>>
>> #include
>>
>> int
>> main (void)
>> {
>> if (!raise (-1))
>> return 1;
>>
>> return 0;
>> }
>
> I don’t know if it’s relevant here, but you should always use ‘-pthread’
> both at compile time and link time:
>
> gcc raise.c -pthread
>
> That typically defines a few macros that may or may not have an effect
> on the code at hand.
Ah...right. Makes no difference, though:
root@childhurd ~# guix environment --bootstrap --ad-hoc gcc-toolchain@7
root@childhurd ~ [env]# gcc raise.c
root@childhurd ~ [env]# ./a.out
root@childhurd ~ [env]# echo $?
0
root@childhurd ~ [env]# gcc raise.c -pthread
root@childhurd ~ [env]# ./a.out
User defined signal 2
root@childhurd ~ [env]# echo $?
159
Greetings,
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
[PATCH] installer: Add Emacs EXWM desktop environment. [WAS Re: Call for 1.2 installer testing.]
Mathieu Othacehe writes:
Hi,
> The 1.2 release is on its way. So here's the traditional call for
> installer testing. This time, the CI is building latest installer
> images, which should ease testing.
It works for me; I found Emacs EXWM missing however. After zenny also
asked about that this morning, I decided to create a patch.
Greetings,
Janneke
>From 130480c4e76d7133f32a83cb1fa30aa171944383 Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen"
Date: Sun, 11 Oct 2020 12:45:00 +0200
Subject: [PATCH] installer: Add Emacs EXWM desktop environment.
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
Suggested by zenny via IRC.
* gnu/installer/services.scm (%system-services): Add emacs, emacs-exwm,
emacs-desktop-environment.
* etc/release-manifest.scm (%system-packages): Likewise.
* gnu/system/examples/lightweight-desktop.tmpl: Likewise.
* gnu/installer/newt/services.scm (run-desktop-environments-cbt-page): Make
one entry taller.
---
etc/release-manifest.scm | 2 ++
gnu/installer/newt/services.scm | 3 ++-
gnu/installer/services.scm | 6 ++
gnu/system/examples/lightweight-desktop.tmpl | 3 ++-
4 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/etc/release-manifest.scm b/etc/release-manifest.scm
index caa200c673..7f54fe8768 100644
--- a/etc/release-manifest.scm
+++ b/etc/release-manifest.scm
@@ -1,5 +1,6 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2020 Ludovic Courtès
+;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen
;;;
;;; This file is part of GNU Guix.
;;;
@@ -53,6 +54,7 @@ TARGET."
(append (map specification->package
'("xorg-server" "xfce" "gnome" "mate" "enlightenment"
"openbox" "awesome" "i3-wm" "ratpoison"
+ "emacs" "emacs-exwm" "emacs-desktop-environment"
"xlockmore" "slock" "libreoffice"
"connman" "network-manager" "network-manager-applet"
"openssh" "ntp" "tor"
diff --git a/gnu/installer/newt/services.scm b/gnu/installer/newt/services.scm
index 4f32d9077b..6d431cb4bb 100644
--- a/gnu/installer/newt/services.scm
+++ b/gnu/installer/newt/services.scm
@@ -1,6 +1,7 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2018 Mathieu Othacehe
;;; Copyright © 2019 Ludovic Courtès
+;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen
;;;
;;; This file is part of GNU Guix.
;;;
@@ -40,7 +41,7 @@ choose the one to use on the log-in screen.")
#:items items
#:selection (map system-service-recommended? items)
#:item->text system-service-name ;no i18n for DE names
- #:checkbox-tree-height 8
+ #:checkbox-tree-height 9
#:exit-button-callback-procedure
(lambda ()
(raise
diff --git a/gnu/installer/services.scm b/gnu/installer/services.scm
index dbac79196d..ec5ea30594 100644
--- a/gnu/installer/services.scm
+++ b/gnu/installer/services.scm
@@ -1,6 +1,7 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2018 Mathieu Othacehe
;;; Copyright © 2019 Ludovic Courtès
+;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen
;;;
;;; This file is part of GNU Guix.
;;;
@@ -82,6 +83,11 @@
(name "ratpoison")
(packages '((specification->package "ratpoison")
(specification->package "xterm"
+ (desktop-environment
+ (name "Emacs EXWM")
+ (packages '((specification->package "emacs")
+ (specification->package "emacs-exwm")
+ (specification->package "emacs-desktop-environment"
;; Networking.
(system-service
diff --git a/gnu/system/examples/lightweight-desktop.tmpl b/gnu/system/examples/lightweight-desktop.tmpl
index b4037d4f79..8e38095a03 100644
--- a/gnu/system/examples/lightweight-desktop.tmpl
+++ b/gnu/system/examples/lightweight-desktop.tmpl
@@ -4,7 +4,7 @@
(use-modules (gnu) (gnu system nss))
(use-service-modules desktop)
-(use-package-modules bootloaders certs ratpoison suckless wm xorg)
+(use-package-modules bootloaders certs emacs-xyz ratpoison suckless wm xorg)
(operating-system
(host-name "antelope")
@@ -43,6 +43,7 @@
(packages (append (list
;; window managers
ratpoison i3-wm i3status dmenu
+ emacs-exwm emacs-desktop-environment
;; terminal emulator
xterm
;; for HTTPS access
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Declarative /etc/guix/acl?
Ludovic Courtès writes: Hello! > For some reason, /etc/guix/acl is not declarative on Guix System: we let > users modify it and assume it’s stateful, which can surprise users as in > <https://issues.guix.gnu.org/39819>. > > Should we make it declarative, just like most of /etc? I think so. Yes, I think so too. However, if you have your own substitute server, you now can run guix archive --authorize < ..., e.g. at bootstrap/install time. For such cases, IWBN to have a --authorized-key argument to guix build / guix system. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
[BLOG] Childhurds and GNU/Hurd substitutes
Hi! We have just published a blog post on building your own Guix System with GNU/Hurd and running it in a virtual machine; the road we traveled since beginning of April and what is possible right now. Read it here: https://guix.gnu.org/en/blog/2020/childhurds-and-substitutes/ Enjoy! Janneke, Ludovic & Mathieu -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: branch master updated: gnu: gettext-minimal: Mark "test-raise" test XFAIL on the Hurd.
Hi!
> commit 2fc298d19c5256eb5609aae7bd35bada59d91685
> Author: Jan (janneke) Nieuwenhuizen
> AuthorDate: Mon Oct 5 11:58:16 2020 +0200
>
> gnu: gettext-minimal: Mark "test-raise" test XFAIL on the Hurd.
>
> * gnu/packages/gettext.scm (gettext-minimal)[arguments]: When compiling
> for
> the Hurd, add "test-raise" to XFAIL_TESTS in make-flags.
Some more info on this bug, it is this snippet that causes
the test failure
--8<---cut here---start->8---
#include
int
main (void)
{
if (!raise (-1))
return 1;
return 0;
}
--8<---cut here---end--->8---
but only when linked against libpthread:
--8<---cut here---start->8---
$ gcc raise.c
$ ./a.out
$ echo $?
0
$ gcc raise.c
/gnu/store/9vs3gkp6svam82zw7vjlml7iiarcs11c-glibc-2.31/lib/libpthread.so.0.3
$ ./a.out
User defined signal 2
$ echo $?
159
--8<-------cut here---end--->8---
Janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Messed up with (guix ssh)
Ludovic Courtès writes: Hello! > So I wanted to give a heads-up and apologize. It got me thinking; this > patch hadn’t gone through guix-patches, which could have prevented this, > maybe. Thanks for the heads-up and quick fix. I'm often amazed how well guix-patches work, notably also for catching/preventing silly mistakes. I think it's a trade-off and not all black and white, to get a feel for where the boundary is we have to cross it now and then. Dunno, very happy with what you're doing :-) Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: bug#27149: perl for arm-linux-gnueabihf
Ludovic Courtès writes: >>> *guix build --target=arm-linux-gnueabihf* *perl* fails with the following >>> output: https://pastebin.com/QF0xKAmR This has been fixed by #40698. Thanks, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: wip-postfix
Gábor Boskovits writes: Hello! >> Jan Nieuwenhuizen ezt írta (időpont: 2020. márc. 17., Ke >> 9:02): > > Gábor Boskovits writes: I took the liberty of rebasing wip-postfix on latest master and found it does not compile --8<---cut here---start->8--- gcc -fPIC -I. -I../../include -DNO_EAI -DDEF_SMTPUTF8_ENABLE=\"no\" -DHAS_DEV_URANDOM -DDEF_SHLIB_DIR=\"/gnu/store/hbdrbb84krvjvw58vmr1pvzb6l3gbmyv-postfix-minimal-3.4.8\" -DUSE_DYNAMIC_LIBS -DUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat -Wno-comment -fPIC -g -O -I. -I../../include -DLINUX5 -c dns_str_resflags.c dns_str_resflags.c:55:13: warning: RES_AAONLY is deprecated "RES_AAONLY", RES_AAONLY, ^ dns_str_resflags.c:57:13: warning: RES_PRIMARY is deprecated "RES_PRIMARY", RES_PRIMARY, ^~~ dns_str_resflags.c:63:22: error: ‘RES_INSECURE1’ undeclared here (not in a function); did you mean ‘RES_RECURSE’? "RES_INSECURE1", RES_INSECURE1, ^ RES_RECURSE --8<---cut here---end--->8--- Luckily, that was easily fixed by updating postfix to 3.5.0. >> When I hack around and create /etc/ailases.db, it works. > I would like to add a service config for this. I found we already have mail-aliases-service-type, so I used that, together with running postalias. Now, queuing mail works ootb...but delivery seems not to work: it remains queued. I rebased wip-postfix and added a couple of patches for this. Please feel free to revert them if you don't like it :-) When starting postfix like so --8<---cut here---start->8--- ./pre-inst-env guix system vm gnu/system/examples/postfix.tmpl`\ --nographic -m 1G\ --nic user,model=virtio-net-pci,hostfwd=tcp::12025-:25,hostfwd=tcp:127.0.0.1:12022-: --8<---cut here---end--->8--- I'm seeing --8<---cut here---start->8--- 07:39:18 janneke@dundal:~/src/guix/wip-postfix [env] $ telnet localhost 12025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 komputilo.localdomain ESMTP Postfix mail from: root mail from: root 250 2.1.0 Ok rcpt to: alice rcpt to: alice 250 2.1.5 Ok data data 354 End data with . hello Alice! hello Alice! . . 250 2.0.0 Ok: queued as E26BA3116 quit quit 221 2.0.0 Bye Connection closed by foreign host. 08:03:53 janneke@dundal:~/src/guix/wip-postfix [env] $ ssh -p 12022 root@localhost /gnu/store/mydn0wr0bs7mz3rx9fwihpma26r0dpqq-postfix-minimal-3.5.0/mailq -C /gnu/store/nj5pa9l9zy6vx5484pbdsqnilva8bivc-postfix-config-dir -Queue ID- --Size-- Arrival Time -Sender/Recipient--- E26BA3116* 175 Mon Aug 10 08:00:50 root@komputilo.localdomain alice@komputilo.localdomain -- 0 Kbytes in 1 Request. --8<---cut here---end--->8--- Ideas? >> It looks like most everything is installed in a single, flat directory >> >> /gnu/store/pyv0rpd6zs0m2i482cb8qxd6mhf5b47z-postfix-minimal-3.4.8 >> >> executables, copies of readmes, (unused?) config files (main.cf, >> aliases)? > > Yes, but can be easily separated. The config files are installer > generated, and not used. Ok => TODO :-) >> Anyhow, this is a great start; next Mailman? > > One thing that blocks me from finishing this is that the setuid > programs in the os declatation should be extended, so that we can use > the privilege separation of postfix. I would like to propose a patch > later this week. Any insight here, something blocking maybe? Greetings, Janneke Jan (janneke) Nieuwenhuizen (5): gnu: postfix-minimal: Updato to 3.5.0. system: examples: Add postfix.tmpl. gnu: postfix-minimal: Fix startup warnings. service: postfix: Use mail-aliases-service-type. system: postfix.tmpl: Add mail-aliases-service. gnu/packages/mail.scm| 32 --- gnu/services/mail.scm| 12 ++- gnu/system/examples/postfix.tmpl | 54 3 files changed, 86 insertions(+), 12 deletions(-) create mode 100644 gnu/system/examples/postfix.tmpl -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Blog post on Further reduced bootstrap seed to 25%
Danny Milosavljevic writes: Hi Danny, > On Mon, 15 Jun 2020 14:54:39 +0200 > Jan Nieuwenhuizen wrote: > >> I’ve published a post about the second big reduction of the Guix >> bootstrap binaries >> >> https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25/ > > "again decided to sponsor this work" link is broken > > Otherwise good :) Thanks, fix pushed! Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Blog post on Further reduced bootstrap seed to 25%
Hello Guix! I’ve published a post about the second big reduction of the Guix bootstrap binaries https://guix.gnu.org/blog/2020/guix-further-reduces-bootstrap-seed-to-25/ Thanks to the recent merge of ‘core-updates’ some weeks days ago, the set of bootstrap binaries now weighs in at approximately 60 MiB; about 25% of what it used to be. Thanks to Timothy Samplet, Danny Milosavljevic and Ludovic Courtès for their feedback and help on an earlier version of this post! Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Canonical-packages restoration.
Mathieu Othacehe writes: > With f30d84d32db0f4f6cb84e139868e1727a7dc0a51 and > dfc8ccbf5da96a67eb1cade499f0def21e7fdb02, I did remove most of the > "canonical-package" calls because they were breaking system > cross-compilation. > > Now, I'd like to somehow restore them Just a quick question: why?; would that reduce a system's closure size? Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 02/04: doc: Update README to refer to the manual.
Ludovic Courtès writes: Hi Ludo! > Jan Nieuwenhuizen skribis: > >>> commit c75a80189fc19f6ff8b4c82d1d1801be6763b6d2 >>> Author: Ludovic Courtès >>> AuthorDate: Tue Jun 2 14:50:54 2020 +0200 >>> >>> doc: Update README to refer to the manual. >>> >>> * README (Requirements): Refer to the manual. >>> (Installation): Update URL of the manual. >> >> Hmm, I don't like it! Also, no rationale. > > Someone reported that the list of dependencies (the Guile version in > particular) in ‘README’ was outdated. I set out to update it and then > realized that that info was already available and up-to-date in the > manual. Hence this patch. Okay... >> ...but as a new potential user of a software I have often cursed the >> makers for providing "empty" READMEs that refer to documentation that is >> neither built (yet) or shipped, or needs a viewer/web browser; making it >> most convenient for them, the writers, and not for me, the reader; >> leaving me puzzled ... "So, you'd rather not have me use your software?" >> >> I'm wondering if you haven't had that experience, and how you look at >> this... > > Sure. Two things: > > 1. People installing a release from a tarball have doc/guix.info > already built. Ah, that's right. > 2. The ‘README’ also gives the URL of the on-line copy of the manual. > > So I think the information is readily available. > > My goal here was just to avoid having an outdated copy of parts of the > manual. > > I hope that makes sense! Yes...it looks like this struck a nerve; I'll think about it. Thanks; Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 02/04: doc: Update README to refer to the manual.
Hi! > commit c75a80189fc19f6ff8b4c82d1d1801be6763b6d2 > Author: Ludovic Courtès > AuthorDate: Tue Jun 2 14:50:54 2020 +0200 > > doc: Update README to refer to the manual. > > * README (Requirements): Refer to the manual. > (Installation): Update URL of the manual. Hmm, I don't like it! Also, no rationale. > +If you are building Guix from source, please see the manual for build > +instructions and requirements, either by running: > > - - [[https://gnu.org/software/guile/][GNU Guile 2.2.x]] > - - [[https://notabug.org/cwebber/guile-gcrypt][Guile-Gcrypt]] 0.1.0 or later > - - [[https://www.gnu.org/software/make/][GNU Make]] > - - [[https://www.gnutls.org][GnuTLS]] compiled with guile support enabled > - - [[https://notabug.org/guile-sqlite3/guile-sqlite3][Guile-SQLite3]], > version 0.1.0 or later > - - [[https://gitlab.com/guile-git/guile-git][Guile-Git]] > - - [[http://www.zlib.net/][zlib]] > - - [[https://savannah.nongnu.org/projects/guile-json/][Guile-JSON]] > + info -f doc/guix.info "Requirements" I can guess how the information in README is a duplication of what we have in the maunual, and possibly even (somewhat) out of date, so for us as developers/maintainers this means extra work... > +or by checking the > [[https://guix.gnu.org/manual/en/html_node/Installation.html][web copy of the > manual]]. > > For information on installation from a Git checkout, please see the section > "Building from Git" in the manual. ...but as a new potential user of a software I have often cursed the makers for providing "empty" READMEs that refer to documentation that is neither built (yet) or shipped, or needs a viewer/web browser; making it most convenient for them, the writers, and not for me, the reader; leaving me puzzled ... "So, you'd rather not have me use your software?" I'm wondering if you haven't had that experience, and how you look at this... As an aside: what has always puzzled me is that GNU has failed/not bothered yet to come up with some sort of standard file to list a package's dependencies. If you're lucky, it's available in human readable form README, or INSTALL, or ... Sorry to be so grumpy ;) Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Providing a Guix System images catalog.
Mathieu Othacehe writes: Hello Mathieu, > To build a Guix System image, one needs to pick an operating system file > and call "guix system disk-image my-os.scm" to get an image. > > While this works fine on desktop, this is more tricky for the embedded > devices. Which operating system to select in "examples" folder? What's > the difference between --system and --target, which one should I use? > > This attached, wip patch, allows to run (on wip-hurd-vm branch): > > guix system image hurd-disk-image > > instead of: > > guix system disk-image --target=i586-pc-gnu > gnu/system/examples/bare-hurd.tmpl That's pretty nice! I wonder about how this composes; if I'd want to add say a guix-daemon service to the bare-hurd, how would I do that? What I also like about "gnu/system/examples/bare-hurd.tmpl" is that it's easy to imagine where to make such a change. Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [PATCH] ext2fs: Update to upstream Hurd-reserved xattr index for "gnu.*".
Samuel Thibault writes: Hello Samuel, > Jan Nieuwenhuizen, le mar. 12 mai 2020 16:12:34 +0200, a ecrit: >> setfattr --name=gnu.translator --value='/hurd/pflocal\0' >> /mnt/servers/socket/1 > > man setfattr says > > If the given string is enclosed in double quotes, the inner string is > treated as text. In that case, backslashes and double quotes have > special meanings and need to be escaped by a preceding backslash. > > so I guess it needs > > setfattr --name=gnu.translator --value='"/hurd/pflocal\0"' > /mnt/servers/socket/1 > > to actually interpret \0 Yes, that's it; thank you! So I've now managed to create a vm-image using Guix that boots the Hurd straight into our Guile RC script, without the need to use Bash for that. See https://gitlab.com/janneke/guix/-/commit/3b4c0dcda783e8c866be154ab46ec95fb581f08f ./pre-inst-env guix system vm-image --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl and wget https://lilypond.org/janneke/hurd/hurd-xattr.img.gz gunzip hurd-xattr.img.gz guix environment --ad-hoc qemu -- qemu-system-i386 -enable-kvm \ -snapshot -hda hurd-xattr.img -m 2G \ -device rtl8139,netdev=net0 -netdev user,id=net0,hostfwd=tcp:127.0.0.1:10022-: So WDYT, is my patch for the Hurd (the first message in this thread) https://lists.gnu.org/archive/html/bug-hurd/2020-05/msg00016.html OK to apply now? Any ideas or suggestions on my Linux patch? >> --8<---cut here---start->8--- >> fsck --yes --force / >> fsysopts / --writable >> mv /servers/socket/1 /servers/socket/1-linux >> touch /servers/socket/1 >> setfattr --name=gnu.translator --value='/hurd/pflocal\0' /servers/socket/1 > > Note that glibc's setxattr, i.e. _hurd_xattr_set, translates that > into a __file_set_translator() RPC call. Did you pass the proper option > to make ext2fs record the translator as xattr instead of passive record? Yes... >> And I guess there must be an incompatibility between Linux and the Hurd >> in how setfattr embeds the xattr attributes into the file system. >> >> How to best "diff" this aspect in the file system; how to proceed? > > debugfs can be used for that. Right, thanks. I was looking for something like that. >> Inspired by Shengyu's GSoC code that simply seemed to use fprintf for >> debbugging, I tried adding some debug printing in inode.c >> >> fprintf (stderr, "gnu.translator[%d,%d]=%s\n", datalen, strlen (*namep), >> *namep); > > Printf is the simplest way to make sure things are happening the way one > wants, yes. Note however that in the case of translators even the output on > stderr is buffered, so you need to flush it with fflush(stderr). Even > safer is to use snprintf + mach_print(). > >> but that does not seem to work, > > More precisely? > I'll assume "does not show up". (that was more precisely exactly what I meant to ask) > If your print doesn't show up, try to put a print in other places which > are definitely to be called such as in diskfs_user_read_node(). If those > come up, then it means the code you put your prints is not even called, > so put prints in code you thought was calling it etc. up to the RPC that > you thought would be called, then jump to libc which was supposed to be > making the RPC call, etc. Thank you! It took me a while to find the right setfattr curse so I dabbled in here some more and can confirm that combining your instructions, e.g., like so --8<---cut here---start->8--- diff --git a/ext2fs/inode.c b/ext2fs/inode.c index a2e804b9..f4e29eb5 100644 --- a/ext2fs/inode.c +++ b/ext2fs/inode.c @@ -700,6 +700,9 @@ diskfs_get_translator (struct node *np, char **namep, unsigned *namelen) void *transloc; struct ext2_inode *di; + fprintf (stderr, "diskfs_get_translator\n"); + fflush (stderr); + if (sblock->s_creator_os != EXT2_OS_HURD) return EOPNOTSUPP; --8<---cut here---end--->8--- "just work". That's helpful knowledge to have anyway. Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Verification Builds for Guix
Paul Spooren writes: [cc: guix-devel] Hello Paul, > I've used the last week a bit to work on some kind of verification build > collector. Essentially a scraper of rebuild results. Meaning, an official > binary > provided by a project is tried to rebuild. Okay... > This works already for Archlinux and OpenWrt[0], now I wanted to know if the > same would make sense for Guix. Possibly...I'm not sure, cc'ing guix-devel :-) > Checking out the packages part of the website I found that there is at > least an CI creating binaries. Are those also offered to users? Yes, Guix (like Nix) uses a mechanism that enables (encourages?) users to always build everything from source. The result of a package build, a "binary package" is uniquely identified by a hash of its inputs, including its build recipe, e.g., "18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2". This hash includes the transitive dependencies and can be calculated without compiling anything. The "binary package", once built, will be installed using this hash, e.g.: "/gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2". A user can opt-in to using "binary substitutes". In that case when a installing a package, before the package build actually starts, Guix checks if a binary is already available from a substitute server using this hash. If a binary is available it simply (well...keys/trust etc.) downloads the build result. In my case it checks for these in order http://banaan.local:8080/nar/gzip/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2 http://janneke.lilypond.org:8080/nar/gzip/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2 http://kluit.dezyne.org:8181/nar/gzip/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2 https://ci.guix.gnu.org/nar/lzip/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2 > If so a rebuilder of exactly these images would be interesting to > integrate in the rebuild-collector. Okay...so be clear on this; Guix (nor Nix) have the concept of REbuilders; all builders are equal: the central CI builder is not "more equal" than any other ;-) Guix does have the "guix challenge" command --8<---cut here---start->8--- guix challenge --help Usage: guix challenge [PACKAGE...] Challenge the substitutes for PACKAGE... provided by one or more servers. --substitute-urls=URLS compare build results with those at URLS --8<---cut here---end--->8--- now the trick is, to get "someone" to run that on an interesting portion of the archive...and to report the results in some common format. Looking at > [0]: https://rebuild.aparcar.org/ I think it could work, although for Guix I think it would be more natural to consider the local build to be the the "original" to compare binary substitute servers against? Maybe the format could be more symmetrical? Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
[PATCH] ext2fs: Update to upstream Hurd-reserved xattr index for "gnu.*".
_hurd_handler = {
+ .prefix = XATTR_HURD_PREFIX,
+ .list = ext4_xattr_hurd_list,
+ .get = ext4_xattr_hurd_get,
+ .set = ext4_xattr_hurd_set,
+};
diff --git a/include/uapi/linux/xattr.h b/include/uapi/linux/xattr.h
index c1395b5bd432..9463db2dfa9d 100644
--- a/include/uapi/linux/xattr.h
+++ b/include/uapi/linux/xattr.h
@@ -7,6 +7,7 @@
Copyright (C) 2001 by Andreas Gruenbacher
Copyright (c) 2001-2002 Silicon Graphics, Inc. All Rights Reserved.
Copyright (c) 2004 Red Hat, Inc., James Morris
+ Copyright (c) 2020 Jan (janneke) Nieuwenhuizen
*/
#include
@@ -31,6 +32,9 @@
#define XATTR_BTRFS_PREFIX "btrfs."
#define XATTR_BTRFS_PREFIX_LEN (sizeof(XATTR_BTRFS_PREFIX) - 1)
+#define XATTR_HURD_PREFIX "gnu."
+#define XATTR_HURD_PREFIX_LEN (sizeof(XATTR_HURD_PREFIX) - 1)
+
#define XATTR_SECURITY_PREFIX "security."
#define XATTR_SECURITY_PREFIX_LEN (sizeof(XATTR_SECURITY_PREFIX) - 1)
--
2.26.0
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Feeble attempt at using xattr gnu.translator
Samuel Thibault writes: > Samuel Thibault, le lun. 11 mai 2020 10:42:08 +0200, a ecrit: >> > diskfs_S_file_set_translator (struct protid *cred, >> > [...] >> > if (passivelen && passive[passivelen - 1]) >> > return EINVAL; >> > >> > hmm; so even when there are no arguments, VALUE must end with 0?! >> >> That > > That's a bit sad, but I'm not so surprised either. I don't remember if > that was discussed at the time. At first glance it felt like a bug/non-finished thing; setttrans does not require the user to resort to \0-hackery. Of course, setfattr is a generic tool; so nothing can be done there to make this frienlier; I'm not sure if something could be done on the hurd side. Could be nice, not sure. janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Feeble attempt at using xattr gnu.translator
Samuel Thibault writes: Hello Samuel, > Did you have a look at Shengyu Zhang's work on xattr? That's about > summer 2016. Ah, that's a helpful pointer. What I notice is that Shengyu's last message says "not merged yet", to which Richard Braun responds https://lists.gnu.org/archive/html/bug-hurd/2016-08/msg00095.html "we'll have more time in September to really dive into the code, finish the review and merge it." It got merged, but I'm not sure about the "finish" bit; Justus Winter disabled it by default (not a great sign), and GSoC 2017 mentions: "finishing the xattr work" https://lists.gnu.org/archive/html/bug-hurd/2017-01/msg00016.html I cannot find any more meta data, documentation or tests... > Also see glibc/sysdeps/mach/hurd/setxattr.c which > translates gnu attributes into RPC calls, and then again in the > translators's diskfs_set_translator. See for instance in > hurd/ext2fs/inode.c's diskfs_set_translator, it looks at > > if (EXT2_HAS_COMPAT_FEATURE (sblock, EXT2_FEATURE_COMPAT_EXT_ATTR) > && use_xattr_translator_records) I noticed the --x-xattr-translator-records before but after reading some more code, I got a little bit further glibc/hurd/xattr.c has gnu.translator empty if no passive translator translator and arguments: "/hurd/foo\0arg1\0arg2\0" ah...so there's a nice hack (way??) to also pass arguments...and then hurd/libdiskfs/file-set-trans.c has diskfs_S_file_set_translator (struct protid *cred, [...] if (passivelen && passive[passivelen - 1]) return EINVAL; hmm; so even when there are no arguments, VALUE must end with 0?! Okay... --8<---cut here---start->8--- root@debian:~# touch 1 root@debian:~# setfattr --name=gnu.translator --value=/hurd/pflocal 1 setfattr: 1: Invalid argument root@debian:~# setfattr --name=gnu.translator --value='/hurd/pflocal\0' 1 root@debian:~# showtrans 1 /hurd/pflocal --8<---cut here---end--->8--- ...so "something" works. Sadly, this trick does not work on GNU/Linux. I'm afraid this hasn't been upstreamed and we would have to debug linux and/or create a patch for setxattr to accept "gnu." on "Hurd" type file systems. Thoughts? Also, some other things also don't work --8<---cut here---start->8--- root@debian:~# getfattr --name=gnu.translator 1 1: gnu.translator: Operation not supported root@debian:~# setfattr --name=gnu.translator --value='/geert/pflocal\0' 1 setfattr: 1: Operation not supported root@debian:~# setfattr --remove=gnu.translator 1 setfattr: 1: Operation not supported --8<---cut here---end--->8--- Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Feeble attempt at using xattr gnu.translator
Hello, As part of the effort of creating vm-images for the Hurd using Guix, it would be nice to use extended file attributes to set passive translators. In particular, it would be helpful if we could use setfattr --name=gnu.translator --value=/hurd/pfinet 1 That would allow us to boot right into Guile and skip a Bash script to only to run settrans -c /servers/socket/1 /hurd/pflocal Whether on GNU/Linux or on the Hurd (booted with --x-xattr-translator-records and x-xattr-translator-records option in fstab); almost nothing works. The Hurd root@debian:~# cat /etc/fstab # /etc/fstab: static file system information. # # /dev/hd0s2 / ext2defaults,x-xattr-translator-records 0 1 /dev/hd0s1 noneswapsw 0 0 /dev/hd2/media/cdrom0 iso9660 noauto 0 0 root@debian:~# fsysopts / ext2fs --writable --no-inherit-dir-group --x-xattr-translator-records --store-type=typed device:hd0s2 root@debian:~# ps -ef --width=1000 | grep ext2 - 5 2 - 0:02.98 ext2fs --readonly --multiboot-command-line=root=device:hd0s2 --host-priv-port=1 --device-master-port=2 --exec-server-task=3 -T typed device:hd0s2 --x-xattr-translator-records so that seems OK? Still, nothing seems to work root@debian:~# touch 1 root@debian:~# mknod 2 c 0 0 root@debian:~# setfattr --name=gnu.translator --value=/hurd/pfinet 1 setfattr: 1: Invalid argument root@debian:~# setfattr --name=gnu.translator --value=/hurd/pfinet 2 setfattr: 2: Invalid argument root@debian:~# setfattr --name=gnu.author --value=/hurd/pfinet 1 setfattr: 1: Invalid argument root@debian:~# setfattr --name=gnu.author --value=/hurd/pfinet 2 setfattr: 2: Invalid argument root@debian:~# setfattr --name=user.translator --value=/hurd/pfinet 1 setfattr: 1: Operation not supported root@debian:~# setfattr --name=user.translator --value=/hurd/pfinet 2 setfattr: 2: Operation not supported On GNU/Linux, I only managed to set user.X, not gnu.translator root@dundal ~# touch 1 root@dundal ~# mknod 2 c 0 0 root@dundal ~# setfattr --name=gnu.translator --value=/hurd/pfinet 1 setfattr: 1: Operation not supported root@dundal ~# setfattr --name=gnu.translator --value=/hurd/pfinet 2 setfattr: 2: Operation not supported root@dundal ~# setfattr --name=gnu.author --value=/hurd/pfinet 1 setfattr: 1: Operation not supported root@dundal ~# setfattr --name=gnu.author --value=/hurd/pfinet 2 setfattr: 2: Operation not supported root@dundal ~# setfattr --name=user.translator --value=/hurd/pfinet 1 root@dundal ~# setfattr --name=user.translator --value=/hurd/pfinet 2 setfattr: 2: Operation not permitted only one command succeeds, but that's next to useless (well, it suggests touch could work and we don't need mknod). This https://lists.gnu.org/archive/html/bug-hurd/2004-02/msg00108.html is the only interesting piece of information I found; down the thread there is a suggestion to try upstreaming. I looked at the Linux sources They seem to suggest that only a couple of namespaces are allowed (and "gnu" is not one of them) but find them hard to read. Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [OUTREACHY]: Integration of desktop environments into GNU Guix
Raghav Gururajan writes: > I would like to thank Guix Maintainers, Gábor Boskovits and Danny > Milosavljevic; for selecting me as an intern for this project. I am gald to be > part of Guix and excited to get started. :-) Well, done; congratulations! Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: hide more output
Ricardo Wurmus writes: > when installing a few packages we see output like this: > > $ guix install zile-on-guile vim-full > The following packages will be installed: >zile-on-guile 2.4.14-0.fd09781 >vim-full 8.2.0411 > > 9.4 MB will be downloaded: >/gnu/store/vf7w4yiax38ra7x8aqqvbnc38c0ldgpm-zile-on-guile-2.4.14-0.fd09781 >/gnu/store/dnj9wljcck9vdwgp7dwxk00qnnk1g3c5-vim-full-8.2.0411 > downloading from > https://ci.guix.gnu.org/nar/lzip/dnj9wljcck9vdwgp7dwxk00qnnk1g3c5-vim-full-8.2.0411... [..] > While I’m sure many of us have gotten used to this I think we don’t need > to show quite as much information. My proposal is to hide the > “downloading from ” by default, because the URLs don’t > really matter to users. We can unhide that bit of info when slightly > higher verbosity is requested. > > What do you think? +1 I've been using --verbosity=1 a lot, lately; I'm all for having another, more quiet but not silent level and bumping the defaults. Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 18/36: services: hurd: Add dummy loopback.
ime.
+ (syntax-case s ()
+ (_
+ (if (= (target-word-size)
+ (with-target %host-type target-word-size))
+ (sizeof type)
+ #'(sizeof type)))
v
(define-syntax alignof*
@@ -208,9 +214,14 @@
(alignof* type))
((_ type)
(let-syntax ((v (lambda (s)
- (let ((val (alignof type)))
- (syntax-case s ()
- (_ val))
+ ;; When compiling natively, call 'sizeof' at expansion
+ ;; time; otherwise, emit code to call it at run time.
+ (syntax-case s ()
+ (_
+ (if (= (target-word-size)
+ (with-target %host-type target-word-size))
+ (alignof type)
+ #'(alignof type)))
v
(define-syntax align ;as found in (system foreign)
--
2.26.0
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: guix system vm-image --target=i586-pc-gnu Hurd'le
Mathieu Othacehe writes:
Hello Mathieu
>> (define* (hurd-grub-configuration-file config entries
>>#:key
>>(system (%current-target-system))
>>(old-entries '()))
>> (let ((hurd (if (equal? system (%current-system))
>> hurd
>> (with-parameters ((%current-target-system system))
>> hurd)))
>
> I'm not sure this is useful. When --target is set, you can use #$ to
> refer to the cross-built package and #+ to refer to the native package
> (built for host architecture).
Oh...it seems to be pretty convoluted way to type dead code. Thanks!
>> menuentry \"GNU\" {
>> multiboot ~a/boot/gnumach root=device:hd0s1
>> module ~a/hurd/ext2fs.static ext2fs \\
>> --multiboot-command-line='${kernel-command-line}' \\
>> --host-priv-port='${host-port}' \\
>> --device-master-port='${device-port}' \\
>> --exec-server-task='${exec-task}' -T typed '${root}' \\
>> '$(task-create)' '$(task-resume)'
>> module ~a/lib/ld.so.1 exec ~a/hurd/exec '$(exec-task=task-create)'
>> }\n"
>> #+mach #+mach #+hurd
>> #+libc #+hurd))
>
> So here, I think you want to use #$hurd, which would refer to the
> cross-compiled hurd package when cross-compiling and to the native hurd
> when building from a hurd system (real, or emulated with --system).
Ah yes, this is a bug; thanks!
I have changed it to
(define* (hurd-grub-configuration-file config entries
#:key
(system (%current-system))
(old-entries '()))
;; XXX Get from a hurd'ified config+entries
(let ((mach gnumach)
(hurd hurd)
(libc glibc))
(computed-file "grub.cfg"
#~(call-with-output-file #$output
(lambda (port)
(format port "
...
}\n"
#$mach #$mach #$hurd
#$libc #$hurd))
> In the future it would also be nice to have this stuff in (gnu
> bootloader grub), but we'll discuss that later on :)
Yes! I found it still a bit too kludgy for that?
In particular, I haven't really dared to think what to do about the
linux-specific config ...make a hurd variant, or add
hurd'ish fields.
Greetings,
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
guix system vm-image --target=i586-pc-gnu Hurd'le
Hi!
We have made some great progress on "guix system vm-image" for the Hurd.
The "wip-hurd-vm" branch has been reset, and there now is only this one
cross-build puzzle that we need to solve (until we hit the next problem ;-).
Running
./pre-inst-env guix system vm-image --target=i586-pc-gnu
gnu/system/examples/bare-hurd.tmpl --verbosity=1
to cross build a VM-image for the Hurd on current "wip-hurd-vm"
9b25e0e4aa DRAFT services: hurd: Use activation-service, hurd-etc-service.
will attepmt to also build a native, non-cross-built Hurd (in my case
for x86_64), which fails. It could be that I am something silly, or we
may not have noticed before because usually a native linux will already
be available, and else it will succeeed.
The diff below adds some debug printing, I get
--8<---cut here---start->8---
14:48:08 janneke@dundal:~/src/guix/wip-hurd-vm [env]
$ ./pre-inst-env guix system vm-image --target=i586-pc-gnu
gnu/system/examples/bare-hurd.tmpl --verbosity=1
;;; ("perform-action: getting packages")
;;; (" => " #)
;;; ("implicit mlet-lowering target=" "i586-pc-gnu")
;;; (" => " (# # sys-object" #)
;;; ("implicit mlet-lower" "i586-pc-gnu")
;;; ("hurd-etc-services: target=" #f)
;;; ("hurd-etc-services: target=" #f)
The following derivation will be built:
/gnu/store/9s621nadr6xcj74n1dl4c7gkvn8x0179-hurd-0.9-1.91a5167.drv
process 2740 acquired build slot '/var/guix/offload/kluit.dezyne.org:22/0'
load on machine 'kluit.dezyne.org' is 0.0 (normalized: 0.0)
building /gnu/store/9s621nadr6xcj74n1dl4c7gkvn8x0179-hurd-0.9-1.91a5167.drv...
|offloading build of
/gnu/store/9s621nadr6xcj74n1dl4c7gkvn8x0179-hurd-0.9-1.91a5167.drv to
'kluit.dezyne.org'
build of /gnu/store/9s621nadr6xcj74n1dl4c7gkvn8x0179-hurd-0.9-1.91a5167.drv
failed
View build log at
'/var/log/guix/drvs/9s/621nadr6xcj74n1dl4c7gkvn8x0179-hurd-0.9-1.91a5167.drv.bz2'.
guix system: error: build of
`/gnu/store/9s621nadr6xcj74n1dl4c7gkvn8x0179-hurd-0.9-1.91a5167.drv' failed
[1]14:48:17 janneke@dundal:~/src/guix/wip-hurd-vm [env]
--8<---cut here---end--->8---
Any help/ideas greatly appreciated.
I can add something like
(target (pk "target" (%current-target-system)))
(hurd (operating-system-hurd os))
(hurd (if target (with-parameters ((%current-target-system target))
hurd) hurd)))
but that does not help; as (%current-target-system) migh be #f.
Hardcoding TARGET to "i586-pc-gnu"..."works", but is not a solution:
we certainly cannot do that for generic services.
Greetings,
janneke
diff --git a/gnu/services/hurd.scm b/gnu/services/hurd.scm
index b3c71e69bd..9d2b94280b 100644
--- a/gnu/services/hurd.scm
+++ b/gnu/services/hurd.scm
@@ -22,6 +22,7 @@
#:use-module (gnu system)
#:use-module (guix gexp)
#:use-module (guix records)
+ #:use-module (guix utils)
#:export (hurd-etc-service))
;;; Commentary:
@@ -50,6 +51,7 @@ if [ -f \"$GUIX_PROFILE/etc/profile\" ]; then
. \"$GUIX_PROFILE/etc/profile\"
fi\n"))
(hurd (operating-system-hurd os)))
+(pk "hurd-etc-services: target=" (%current-target-system))
(etc-service
`(("services" ,(file-append net-base "/etc/services"))
("protocols" ,(file-append net-base "/etc/protocols"))
diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm
index 2664c66a30..26c5208d9d 100644
--- a/guix/scripts/system.scm
+++ b/guix/scripts/system.scm
@@ -799,13 +799,24 @@ static checks."
(check-initrd-modules os)))
(mlet* %store-monad
- ((sys (system-derivation-for-action os action
+ ((foo -> (pk "perform-action: getting packages"))
+ (packages -> (mlet %store-monad () (return (operating-system-packages
os
+ (foo -> (pk " => " packages))
+ (foo -> (pk "implicit mlet-lowering target=" (%current-target-system)))
+ (packages packages)
+ (foo -> (pk " => " packages))
+ (foo -> (pk "calling system-derivation-for-action"))
+ (sys-object -> (system-derivation-for-action os action
#:file-system-type
file-system-type
#:image-size image-size
#:full-boot? full-boot?
#:container-shared-network?
container-shared-network?
#:mappings mappings))
+ (foo -> (pk " => sys-object" sys-object))
+ (foo -> (pk "implicit mlet-lower" (%current-target-system)))
+ (sys sys-object)
+ (foo -> (pk " => sys" sys))
;; For 'init' and 'reconfigure', always build BOOTCFG, even if
;; --no-bootloader is passed, because we then use it as a GC root.
;; See <http://bugs.gnu.org/21068>.
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 18/36: services: hurd: Add dummy loopback.
Ludovic Courtès writes: >> herd: exeception caught while executing 'start' on service 'loopback': >> Value out of range 0 to 4294967295: -1 > > Ah see, it’s out of range. > > Could you run Guile, load (guix build syscalls), and try to run the code > of the ‘start’ method that appears in > ‘static-networking-shepherd-service’ to see which syscall is giving us > that error? Yes, that reproduces! > Could it be ‘ifreq-struct-size’ that’s off on GNU/Hurd, or one of its > friends? Something like that: sizeof-ifconf is set to 16 (like on x86_64), but it's size should be 8. Not sure how that works!? Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 13/36: services: Add hurd-console-service-type.
Ludovic Courtès writes: >> (define* (expression->derivation-in-linux-vm name exp >> #:key >> (system (%current-system)) >> target >> (linux linux-libre) >> ... >> >> that is called by qemu-image. So I have been playing with this hack > > Ah, so there was a #$ vs. #+ issue we discussed on IRC. Did that > help? Yes; that fixed this aspect. In fact, fixing this allows me to introduce guix system build --target=i586-pc-gnu / guix system vm-image --target=i586-pc-gnu much earlier, and have those working. So I have reversed some bits, and now don't need to introduce the hurd-service->shepherd-service intermediate anymore! I'll reset wip-hurd-vm with those improvements. > The VM is used just to create the image (it will no longer be necessary > once Mathieu’s work on image creation has landed). The fact that it > runs Linux doesn’t matter. Yes... >>>> + (default-value (hurd-console-configuration >>> >>> Please add a ‘description’ too! >> >> For the default value? > > No, I meant a ‘description’ field. Ah, I believe, I think it's there. Someone may have overlooked something. Thanks! -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: M2-Planet v1.6.0 and mescc-tools v1.0.0 released
Orians, Jeremiah (DTMB) writes: > https://github.com/oriansj/M2-Planet > > https://savannah.nongnu.org/projects/mescc-tools > > A K+R C equivalent C compiler, assembler, linker, dwarf stub generator > and shell able to produce fully standards compliant ELF binaries for > Knight, x86, AMD64, armv7l and aarch64 and be bootstrapped from a sub > 250byte hex0 hex assembler and a 737byte shell Congratulations on this beautiful release; an amazing piece of work! I can't wait to have a fully bootstrapped M2-Planet, in turn fully bootstrapping GNU Mes at the bottom of our package graph (and preferrably others' package graphs too :-)! Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 13/36: services: Add hurd-console-service-type.
Jan Nieuwenhuizen writes: > Now this > > guix system build --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl Oops the above works, I should have said: Now this guix system vm-image --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl ... etc We can now, actually cross build using guix system build; but the problem is in creating a VM with a cross-built system in it, as described in that message. -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 18/36: services: hurd: Add dummy loopback.
Ludovic Courtès writes: > guix-comm...@gnu.org skribis: > >> +(define (hurd-loopback-shepherd-service _) >> + "Return the 'loopback' Shepherd service." >> + >> + (list (shepherd-service >> + (documentation "Dummy for bootstrapping (gnu services) on the >> Hurd.") >> + (provision '(loopback)) >> + (requirement '()) >> + (start #~(const #t)) >> + (stop #~(const #t)) >> + (respawn? #f >> + >> +(define hurd-loopback-service-type >> + (service-type >> + (name 'loopback) >> + (extensions (list (service-extension shepherd-root-service-type >> +hurd-loopback-shepherd-service))) >> + (compose concatenate) >> + (extend first-of-two) >> + (default-value '(loopback)) ;canary for hurd-service->shepherd-service >> + (description "Dummy service to bootstrap (gnu services) on the >> +Hurd."))) > > I believe the code currently used in ‘static-networking-service’ to > setup the loopback device on GNU/Linux should also work on GNU/Hurd: it > uses the “traditional” ioctls provided by (guix build syscalls). > > So hopefully we don’t need a Hurd-specific variant. Ah, great! I rewrote this to use ...and it almost works already. I have added (service static-networking-service-type (list (static-networking (interface "lo") (ip "127.0.0.1") (requirement '()) (provision '(loopback) and the VM builds, only it doesn't start herd: exeception caught while executing 'start' on service 'loopback': Value out of range 0 to 4294967295: -1 I have added new code for this as a squash! commit, that I then also revert for now, until it works. :-( Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 13/36: services: Add hurd-console-service-type.
ervices to plug that into
gnu/system/hurd.scm.
Meanwhile there is the vm-image question: can we somehow use
expression->derivation-in-linux-vm when running "guix system
... --target=i586-pc-gnu"? Or do we want to create a
expression->derivation-in-hurd-vm? Or do we leap onto the "explosive
mixture of wip-disk-image and wip-hurd-vm? Once any of these solutions
work we can drop the gnu/system/hurd.scm cross-hurd-image workaround.
>> + (list (shepherd-service
>> + (documentation "Hurd console.")
>
> “Run the Hurd’s VGA console client.”
Ah, ok...that's what it is.
>> + (provision '(console))
>> + (requirement '())
>
> Should be '(user-processes) I think.
Ah yes, good catch.
>> + (start #~(lambda _ (fork+exec-command #$console-command) #t))
>
> Rather #~(make-forkexec-constructor #$console-command).
Great, thanks!
>> +(define hurd-console-service-type
>> + (service-type
>> + (name 'console)
>> + (description
>> +"Run a hurd console, @command{console}.")
>
> Maybe “Run the Hurd console client.”
Thanks.
>> + (compose concatenate)
>> + (extend first-of-two)
>
> I don’t think we need these two fields since this service is not meant
> to be extensible.
>
>> + (default-value (hurd-console-configuration
>
> Please add a ‘description’ too!
For the default value? Isn't that added above...maybe i'm using a weird
layout for the fields?
I will be testing these changes and updating the other services
similarly.
> Also, normally we document every new service type in the manual, but
> maybe we can delay it here so that you can unleash your hack powers in
> the meantime. :-)
I'm marking this as DRAFT and add a TODO in the message so that we don't
forget. Let's not waste my hacking powers on documenting stuff too long
before it's merged...but also not forget the documentation.
Phew...
Greetings,
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 20/36: system: hurd: Add the Shepherd.
Ludovic Courtès writes: Hi Ludo'! >> commit bb17242a511014e1691d494b17152865db0580e0 >> Author: Jan (janneke) Nieuwenhuizen >> AuthorDate: Tue Apr 7 08:03:03 2020 +0200 >> >> system: hurd: Add the Shepherd. >> + (define shepherd.conf >> +(with-parameters ((%current-target-system "i586-pc-gnu")) >> + (shepherd-configuration-file (hurd-shepherd-services %hurd-os > > This looks like an intermediate before fully using the service/OS > framework TL;DR: Thanks a lot for your review and questions! I will be using this to rewrite the Shepherd/services introduction in a proper way, until it can be merged. > , but I wonder how much it helps. Yes, that's exactly it! This intermediate, is curerently the only way I found that can produce a fully functional VM-image; i.e., one that starts guix-daemon and openssh. So it helps by being an intermediate. > The way I see it, now that you’ve defined services for Hurd-specific > things like the console client, you could very much write: > > (operating-system > ;; … > (kernel gnumach) > (hurd hurd) ;<- we probably need this new field (oh...prolly better than the (if hurd-target?) I've been sprinkling and implicit adding of gnumach. I'll have a go at this. > (essential-services (hurd-essential-services this-operating-system)) > (services %base-hurd-services)) > > (Eventually we can even arrange for ‘essential-services’ and ‘services’ > to pick the right default as a function of the chosen kernel.) > > and then do: > > guix system build --target=i586-pc-gnu the-config-above.scm > Assuming system cross-compilation works as advertised :-), it should > cross-compile the whole system. Yeah...is seems that the marketing department may have sold us something that has yet to be delivered. Either that, or I failed to read some bits of the instruction manual ;-) To get something to run, we need (near the top of wip-hurd-vm) 6302837257 HACK Don't fail on running host's localedef. 443e1b2176 gnu: hurd: Cross-build hack: Set target i586-pc-gnu if unset. 87b50146ee gnu: glibc/hurd-headers: Cross-build fix for the Hurd. So, on a well-chosen version of wip-hurd-vm (for example: wip-hurd-vm24 on my gitlab), I can now finally run this ./pre-inst-env guix system build --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl ...but (most of) the OS is not cross-compiled; /bin/bash is the build host's bash. Some things, like Grub, Gnumach, the Hurd are cross compiled, so ... > At that stage, you don’t need ‘cross-hurd-image’ any longer and you can > instead run: > > guix system vm-image --target=i586-pc-gnu the-config-above.scm > > to achieve the same result. ... indeed, running: ./pre-inst-env guix system vm-image --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl creates a bootable VM-image that drops into a bash-minimal shell, because /bin/bash cannot be executed. > But! There’s one missing bit: a Hurdish grub.cfg. I think that can be > hacked in (gnu bootloader grub), by inheriting from ‘grub-bootloader’ > and providing a custom ‘configuration-file-generator’ field and maybe > ‘installer’ as well. I think I have that covered here d6ec2c2543 * system: hurd: Add hurd-grub-configuration-file. a9a6b716d9 * system: hurd: Add hurd-grub-minimal-bootloader. possibly depending on these 4fd4296325 * system: Add hurd-operating-system-directory-base-entries. f4f872a440 * services: hurd: Move hurd-default-essential-services. 5f7c73d83a * services: Add hurd-file-systems-service-type. d7cd2f122d * services: hurd: Move hurd-etc-sevcices. > Thus, (gnu system hurd) would be left with nothing but the definitions > of ‘%base-services/hurd’, ‘%base-packages/hurd’, and so on. > ‘hurd-essential-services’ could maybe go to (gnu services hurd). Yes! > But I wonder if I’m missing something, WDYT? You're right...and this is what I am trying to work towards. The reason for me to introduce these intermediate steps is that they enable to run intermediate tests. Currently, "guix build -f gnu/system/hurd.scm" is the only way I have that produces a functional VM. We are pretty close t creating such a thing with "guix system ...", but to do so we need a cross build that works and a shepherd config generated...and that all needs to come together. So instead of attempting a giant leap, I'm trying to throw some intermediate stepping stones in the pond :-) We don't need to merge, or keep this history; but I don't see how to walk this path without going round these extra curves; let alone getting feedback or asking questions. So I can imagine that these commits keep being rewritten/removed on wip-hurd-vm until everything works. > Thanks for the exciting developments again! :-) Thanks for your insig
Re: 02/36: gnu: guix: Use gnutls-3.6.13 when cross-compiling.
Ludovic Courtès writes:
Hello Ludo'!
> Time for random review comments on ‘wip-hurd-vm’. :-)
\o/
> guix-comm...@gnu.org skribis:
>
>> commit af9b4d0ba3d55ef89e956f408853548451243e95
>> Author: Jan (janneke) Nieuwenhuizen
>> AuthorDate: Fri Apr 10 09:54:02 2020 +0200
>>
>> gnu: guix: Use gnutls-3.6.13 when cross-compiling.
>>
>> * gnu/packages/package-management.scm (guix)[propagated-inputs]: When
>> cross-compiling, use patched gnutls-3.6.13.
>
> [...]
>
>>(propagated-inputs
>> - `(("gnutls" ,guile3.0-gnutls)
>> + `(("gnutls" ,(if (%current-target-system)
>> +(@@ (gnu packages tls) gnutls-3.6.13)
>
> Please avoid @@ by making ‘gnutls-3.6.13’ public
Oh..."gnutls-3.6.13" is already public; I simply removed (@@ ..)
Hmm, I don't know how this happened...I either didn't look well before,
maybe I was using then non-exported "gnutls", changed to gnutls-3.6.13
and kept the @@), or possibly it got exported later. I'll try to
remember to avoid @@ in such cases.
> (and making the package > itself hidden if necessary).
> Otherwise LGTM!
Great, pushed.
> Forgive brevity, sent from my Emacs under lockdown.
> :-)
*lol*
Reading in my GNU Emacs under lockdown, thanks for your brevity.
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: branch wip-hurd-vm created (now fdb35e3)
Ludovic Courtès writes: >> new 330f3ab gnu: guix: Cross-build fixup for wrap-program. >> new af9b4d0 gnu: guix: Use gnutls-3.6.13 when cross-compiling. removed (@@ ...) >> new de41617 gnu: guix: Apply courage for the Hurd. >> new 309963e gnu: guix: Update to de41617661. re-created >> new ddb44df vm: Make the device node procedure a parameter. dropped >> new f3b1d64 gnu: hurd: Fix references to /bin/w. >> new 695e2b4 gnu: hurd: Use default Qemu guest ip: 10.0.2.15. added comments >> new 2f5d2dc gnu: hurd: Add NFS support. >> new 29ea4dc gnu: Add libtirpc/hurd. >> new d01f38a system: hurd: Add less, which to %base-packages/hurd. >> new df00a4a system: hurd: Add /etc/group. added > With the feedback I gave, these 11 patches can go to ‘core-updates’ > IMO! Great! All pushed to core-updates. Lovely progress by 4 committers: Rene, Ricardo, Efraim, Janneke! ...No commits by Ludovic this round! (the silence before the storm?)... and of course I'm joking here, thanks a lot for this review party Ludovic! Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 09/36: gnu: Add libtirpc/hurd.
Ludovic Courtès writes: > guix-comm...@gnu.org skribis: > >> commit 29ea4dc2c1df0d4562f1add01501726a3f963b91 >> Author: Ricardo Wurmus >> AuthorDate: Sun Apr 12 23:04:49 2020 +0200 >> >> gnu: Add libtirpc/hurd. >> >> * gnu/packages/onc-rpc.scm (libtirpc/hurd): New variable. >> * gnu/packages/patches/libtirpc-hurd-client.patch, >> gnu/packages/patches/libtirpc-hurd.patch: New files. >> * gnu/local.mk (dist_patch_DATA): Add them. > > LGTM! Pushed to core-updates; thanks Ricardo! > On the next ‘staging’ cycle, we should merge the two libtirpc’s. I'll try to help remember; can we add helpful comment somewhere? Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 08/36: gnu: hurd: Add NFS support.
Ludovic Courtès writes: > guix-comm...@gnu.org skribis: > >> commit 2f5d2dc8240c22ea109c52c8ca957be9b155ff36 >> Author: Ricardo Wurmus >> AuthorDate: Sun Apr 12 23:06:30 2020 +0200 >> >> gnu: hurd: Add NFS support. >> >> * gnu/packages/hurd.scm (hurd)[inputs]: Add libtirpc/hurd. >> [arguments]: Add configure flags to use libtirpc; add phase "find-tirpc" >> to >> find the RPC headers; add phase "fix-rpc-headers" to include missing >> headers. > > LGTM! Pushed to core-updates; thanks Ricardo! -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 07/36: gnu: hurd: Use default Qemu guest ip: 10.0.2.15.
Ludovic Courtès writes: >> but using this default allows us to use the widely advertised >> >> -device rtl8139,netdev=net0 -netdev >> user,id=net0,hostfwd=tcp:127.0.0.1:2228-:22 > > Oh! > >> * gnu/packages/hurd.scm (hurd-rc-script): Use 10.0.2.15. > ^ > You can also mention [hurd-directives] here. Eh, this is in the RC script; I have changed it to * gnu/packages/hurd.scm (hurd-rc-script): Used by (hurd)[inputs]: Use 10.0.2.15; the default QEMU guest IP. >> -"--address" "10.0.2.77" >> +"--address" "10.0.2.15" > > Perhaps add a margin comment saying this is the default QEMU guest IP. Good idea; done. > LGTM! Thanks, pushed to core-updates with these changes. -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 05/36: vm: Make the device node procedure a parameter.
Ludovic Courtès writes:
>> vm: Make the device node procedure a parameter.
>>#:bootcfg-drv grub.cfg
>>#:bootloader grub-bootloader
>>#:register-closures? #f
>> + #:device-nodes 'hurd
>>#:extra-directives hurd-directives))
>
> On ‘core-updates’, there’s already #:device-nodes 'hurd, though not on
> the same line.
>
> I think we can drop this patch, no?
Oops, sure; dropped.
We may even want to move this (and "friends") into the qemu-image
declaration itself; in a much later patch on wip-hurd-vm I have
(define* qemu-image #:key
[...]
- (file-system-type "ext4")
- (file-system-options '())
- (device-nodes 'linux)
+ (file-system-type (if (hurd-target?) "ext2" "ext4"))
+ (file-system-options
+ (if (hurd-target?) '("-o" "hurd") '()))
+ (device-nodes (if (hurd-target?) 'hurd 'linux))
Having linux-specific defaults in a generic function is kind of awkward;
we would need to change all callers, or ...
Well, that's for later to be sure!
Greetings,
janeke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 06/36: gnu: hurd: Fix references to /bin/w.
Ludovic Courtès writes: >> commit f3b1d64cecdd964699a4e22a2b4b5b7fc53c >> Author: Rene Saavedra >> AuthorDate: Sun Apr 12 22:33:08 2020 -0500 >> >> gnu: hurd: Fix references to /bin/w. >> >> * gnu/packages/hurd.scm (hurd): Use '/bin/w' from hurd package. > > OK! Thanks; Pushed to core-updates. janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Guix System video review on YouTube
Jonathan Brielmaier writes: > Guix System got a video review on YouTube: > https://www.youtube.com/watch?v=IKsXecNJ_nE > Although the reviewer was not really happy with the Guix System > distribution, he was quite pleased with the package manager. So he would > recommend his viewers to try Guix on a foreign distro, but not our distro. > > For the issues I could reproduce, I already filed bugs: That's great. Are you planning on leaving a reaction, maybe something like: Thanks for the extensive testing, I filed bugs for the issues you found here => ... janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 14/42: gnu: Add netdde.
Ludovic Courtès writes: > guix-comm...@gnu.org skribis: > >> commit 5aedec90651e7db389732554247d25419cfce755 >> Author: Ricardo Wurmus >> AuthorDate: Tue Apr 14 12:46:00 2020 +0200 >> >> gnu: Add netdde. >> >> * gnu/packages/hurd.scm (netdde): New variable. > > LGTM! Pushed to core-updates; rebased and reset wip-hurd-vm! Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 08/42: gnu: guix: Update to eeb87326d8.
Ludovic Courtès writes: >> gnu: guix: Update to eeb87326d8. >> >> * gnu/packages/package-management.scm (guix): Update to >> 1.1.0-1.eeb87326d8. > > Note: when merging, make sure it refers to a commit from ‘core-updates’, > not one from the WIP branch. Yes!...pushed to core-updates! janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 07/42: gnu: guix: Cross-build fix: override compressors.
Ludovic Courtès writes:
> guix-comm...@gnu.org skribis:
>
>> commit eeb87326d891e0f88f5eebf767d97b45c3e6
>> Author: Jan (janneke) Nieuwenhuizen
>> AuthorDate: Fri Apr 10 21:24:19 2020 +0200
>>
>> gnu: guix: Cross-build fix: override compressors.
>>
>> * gnu/packages/package-management.scm (guix)[arguments]: When
>> cross-compiling,
>> add `fixup-compressors' stage.
>> [inputs]: When cross-compiling, add `xz'.
>
> Nice!
>
>> + (lambda* (#:key inputs #:allow-other-keys)
>> +;; Use host compressors.
>> +(let ((bzip2 (assoc-ref inputs "bzip2"))
>> + (gzip (assoc-ref inputs "gzip"))
>> + (xz (assoc-ref inputs "xz")))
>> + (substitute* "guix/config.scm"
>> +(("/gnu/store/.*/bzip2")
>> + (string-append bzip2 "/bin/bzip2"))
>> +(("/gnu/store/.*/gzip") gzip
>> + (string-append gzip "/bin/gzip"))
>> +(("/gnu/store/.*/xz")
>> + (string-append xz "/bin/xz")))
>
> Here’s a way to avoid hard-coding the store name:
>
> (substitute* "guix/config.scm"
> (("\".*/bin/gzip\"")
> (string-append "\"" gzip "/bin/gzip\""))
> …)
Ah, nice. Change them to
(("\"[^\"]*/bin/bzip2")
(string-append "\"" bzip2 "/bin/bzip2"))
> Otherwise LGTM!
Thanks!
> Perhaps eventually we should add ‘--with-host-gzip’ and similar
> configure options.
Okay, I'll give that a go later.
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 07/42: gnu: guix: Cross-build fix: override compressors.
Ludovic Courtès writes:
> guix-comm...@gnu.org skribis:
>
>> commit eeb87326d891e0f88f5eebf767d97b45c3e6
>> Author: Jan (janneke) Nieuwenhuizen
>> AuthorDate: Fri Apr 10 21:24:19 2020 +0200
>>
>> gnu: guix: Cross-build fix: override compressors.
>>
>> * gnu/packages/package-management.scm (guix)[arguments]: When
>> cross-compiling,
>> add `fixup-compressors' stage.
>> [inputs]: When cross-compiling, add `xz'.
>
> Nice!
>
>> + (lambda* (#:key inputs #:allow-other-keys)
>> +;; Use host compressors.
>> +(let ((bzip2 (assoc-ref inputs "bzip2"))
>> + (gzip (assoc-ref inputs "gzip"))
>> + (xz (assoc-ref inputs "xz")))
>> + (substitute* "guix/config.scm"
>> +(("/gnu/store/.*/bzip2")
>> + (string-append bzip2 "/bin/bzip2"))
>> +(("/gnu/store/.*/gzip") gzip
>> + (string-append gzip "/bin/gzip"))
>> +(("/gnu/store/.*/xz")
>> + (string-append xz "/bin/xz")))
>
> Here’s a way to avoid hard-coding the store name:
>
> (substitute* "guix/config.scm"
> (("\".*/bin/gzip\"")
> (string-append "\"" gzip "/bin/gzip\""))
> …)
Ah, nice. Change them to
(("\"[^\"]*/bin/bzip2")
(string-append "\"" bzip2 "/bin/bzip2"))
> Otherwise LGTM!
Thanks!
> Perhaps eventually we should add ‘--with-host-gzip’ and similar
> configure options.
Okay, I'll give that a go later.
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 04/42: gnu: guix: Cross-build workaround: Run native guile for version.
Ludovic Courtès writes: >> gnu: guix: Cross-build workaround: Run native guile for version. > > Good catch, LGTM! Thanks; pushed to core-updates. janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 04/36: gnu: guix: Do not copy bootstrap-guile when cross-compiling.
Ludovic Courtès writes: >> gnu: guix: Do not copy bootstrap-guile when cross-compiling. >> >> * gnu/packages/package-management.scm (guix)[arguments]: When >> cross-compiling, >> skip copy-bootstrap-guile phase; needed for tests only. ... >> -(add-before 'check 'copy-bootstrap-guile >> +,@(if (%current-target-system) >> + '() >> + `((add-before 'check 'copy-bootstrap-guile >>(lambda* (#:key system inputs #:allow-other-keys) > > Perhaps it would be clearer by avoiding the unquote-splicing dance: > > (lambda* (#:key system target inputs #:allow-other-keys) > (unless target > …) > #t) Ah, yes. No need to be careful not to trigger a rebuild. > Otherwise LGTM! Thanks, pushed to core-updates. janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 04/05: gnu: autoconf: Support cross-build.
Ludovic Courtès writes:
Hi!
>> Tests are disabled currently (even on master!), so I guess that
>> inserting this line break is fine :-)
>
> Damn it, this is terrible! But not your fault, for sure. :-)
Yes, it would be good to re-enable them during the next cycle.
>> -(arguments `(#:tests? #f))
>> +(arguments
>> + `(#:tests? #f
>
> I’m really nitpicking, but could you move the XXX comment right after
> #:tests? #f?
As checkn on IRC: yes, right after "(arguments `(" right before #:tests
>> + (out (assoc-ref outputs "out"))
>> + (store-directory (%store-directory)))
>> + (substitute* (find-files (string-append out "/bin"))
>> +(((string-append store-directory
>> "/[^/]*-m4-[^/]*")) m4)
>> +(((string-append store-directory
>> "/[^/]*-perl-[^/]*"))
>> + perl))
>
> I’m very much in favor of keeping regexps literal. What about writing
> them as:
>
> (substitute* …
> (("/[[:graph:]]/bin/m4")
> (string-append m4 "/bin/m4"))
> …)
After discussing various options on IRC: keeping the parenthetical
(((string-append stor-directory...; we are using than for git and
perl, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40698#16
> Also please move the comment right below ‘lambda*’. :-)
Done!
> And then I think you can push it to ‘core-updates’.
Pushed to core-updates, together with a simalar patch for automake,
and a trivial one for texinfo.
Thanks!
janneke
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Progress on the Hurd; new state of wip-hurd-vm
Jan Nieuwenhuizen writes: > Like before, you should be able to run > > ./pre-inst-env guix build -f gnu/system/hurd.scm As reported by apteryx on IRC yesterday, this command may fail for you unless you have already built the bootstrap binaries for the Hurd. If you are new to the Hurd you must first build the bootstrap-binaries from the core-updates branch. The easiest to do that is by using the command above to build the VM. This should be fixed once we get the `guix' package to cross-builds without some of the hacks that are now used near the tip of the wip-hurd-vm branch. Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 04/05: gnu: autoconf: Support cross-build.
Jan Nieuwenhuizen writes:
(fix typo/update renamed phase in commit message)
>From 2b7ae7542fd77b35d7a143c90556cf32a7f9ae48 Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen"
Date: Sat, 18 Apr 2020 19:49:54 +0200
Subject: [PATCH] gnu: autoconf: Support cross-build.
Autoconf cannot be cross-built properly: it lacks the concept of
-for-build. It runs the host `autom4te' (a perl script) during build.
* gnu/packages/autotools.scm (autoconf)[inputs]: When cross-building, add perl
and m4.
[native-inputs]: when cross-building, use -for-build names.
[arguments]: When cross-building, add `patch-non-shebang-references' phase to
substitute m4 and perl.
---
gnu/packages/autotools.scm | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/autotools.scm b/gnu/packages/autotools.scm
index 99ca52730e..fa3ced182f 100644
--- a/gnu/packages/autotools.scm
+++ b/gnu/packages/autotools.scm
@@ -55,12 +55,38 @@
(base32
"113nlmidxy9kjr45kg9x3ngar4951mvag1js2a3j8nxcz34wxsv4"
(build-system gnu-build-system)
+(inputs
+ ;; TODO: remove `if' in the next rebuild cycle.
+ (if (%current-target-system)
+ `(("perl" ,perl)
+ ("m4" ,m4))
+ '()))
(native-inputs
`(("perl" ,perl)
("m4" ,m4)))
;; XXX: testsuite: 209 and 279 failed. The latter is an impurity. It
;; should use our own "cpp" instead of "/lib/cpp".
-(arguments `(#:tests? #f))
+(arguments
+ `(#:tests? #f
+ ,@(if (%current-target-system)
+ `(#:phases
+ (modify-phases %standard-phases
+ ;; `patch-shebangs' patches shebangs only, and the Perl
+ ;; scripts use a re-exec feature that references the build
+ ;; hosts' perl. Also, M4 store references hide in the
+ ;; scripts.
+ (add-after 'install 'patch-non-shebang-references
+ (lambda* (#:key build inputs outputs #:allow-other-keys)
+ (let ((m4 (assoc-ref inputs "m4"))
+ (perl (assoc-ref inputs "perl"))
+ (out (assoc-ref outputs "out"))
+ (store-directory (%store-directory)))
+ (substitute* (find-files (string-append out "/bin"))
+(((string-append store-directory "/[^/]*-m4-[^/]*")) m4)
+(((string-append store-directory "/[^/]*-perl-[^/]*"))
+ perl))
+ #t)
+ '(
(home-page "https://www.gnu.org/software/autoconf/;)
(synopsis "Create source code configuration scripts")
(description
--
2.26.0
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 04/05: gnu: autoconf: Support cross-build.
(((string-append store-directory "/[^/]*-perl-[^/]*"))
perl))
#t)
> (You previously found that something’s wrong there, but I forgot what…)
(yes, and I did not have the whole story)
Attaching the updated patch in full.
(automake is pretty similar, i'll send an updated patch for that right
after this review is finished).
Greetings,
janneke
>From 3d776e0077d62000f20d23a1b42b32fef718a503 Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen"
Date: Sat, 18 Apr 2020 19:49:54 +0200
Subject: [PATCH] gnu: autoconf: Support cross-build.
Autoconf cannot be cross-built properly: it lacks the concept of
-for-build. It runs the host `autom4te' (a perl script) during build.
* gnu/packages/autotools.scm (autoconf)[inputs]: When cross-building, add perl
and m4.
[native-inputs]: when cross-building, use -for-build names.
[arguments]: When cross-building, add `fake-cross-build' phase to substitute
m4 and perl.
---
gnu/packages/autotools.scm | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/autotools.scm b/gnu/packages/autotools.scm
index 99ca52730e..fa3ced182f 100644
--- a/gnu/packages/autotools.scm
+++ b/gnu/packages/autotools.scm
@@ -55,12 +55,38 @@
(base32
"113nlmidxy9kjr45kg9x3ngar4951mvag1js2a3j8nxcz34wxsv4"
(build-system gnu-build-system)
+(inputs
+ ;; TODO: remove `if' in the next rebuild cycle.
+ (if (%current-target-system)
+ `(("perl" ,perl)
+ ("m4" ,m4))
+ '()))
(native-inputs
`(("perl" ,perl)
("m4" ,m4)))
;; XXX: testsuite: 209 and 279 failed. The latter is an impurity. It
;; should use our own "cpp" instead of "/lib/cpp".
-(arguments `(#:tests? #f))
+(arguments
+ `(#:tests? #f
+ ,@(if (%current-target-system)
+ `(#:phases
+ (modify-phases %standard-phases
+ ;; `patch-shebangs' patches shebangs only, and the Perl
+ ;; scripts use a re-exec feature that references the build
+ ;; hosts' perl. Also, M4 store references hide in the
+ ;; scripts.
+ (add-after 'install 'patch-non-shebang-references
+ (lambda* (#:key build inputs outputs #:allow-other-keys)
+ (let ((m4 (assoc-ref inputs "m4"))
+ (perl (assoc-ref inputs "perl"))
+ (out (assoc-ref outputs "out"))
+ (store-directory (%store-directory)))
+ (substitute* (find-files (string-append out "/bin"))
+(((string-append store-directory "/[^/]*-m4-[^/]*")) m4)
+(((string-append store-directory "/[^/]*-perl-[^/]*"))
+ perl))
+ #t)
+ '(
(home-page "https://www.gnu.org/software/autoconf/;)
(synopsis "Create source code configuration scripts")
(description
--
2.26.0
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: modular shepherd config
Efraim Flashner writes: > A while ago I split my personal shepherd init.scm into a bunch of files > and I wanted to document it somewhere for others to see also. Any > suggestion where I should put it? Shepherd manual? guix-cookbook? This looks interesting, so how to get started trying? My most pressing question is: how and when do you start your user's shepherd? Do I have to log into the machine, do I have to stay logged-in? Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Progress on the Hurd; new state of wip-hurd-vm
Vincent Legoll writes: Hello Vincent, > I just had a tour of that branch, it looks like there are interesting > patches wrt cross-building, aren't those ready for upstream (core- > updates maybe) ? Yes, some of them (gnutls, git, python) have just been cleaned-up and applied to core-updates. > I'm looking at the first one (for perl) for example... Ah, that one took some review and effort, see https://bugs.gnu.org/40698 and has now been applied too. > I've been trying to cross-compile the binary-tarball to new arches, > without any success, all failing the same way, on perl... > > And when it hit me that there is a recurring theme in those failures > I found a few issues and ML posts about the same problem. > > So, what's the status of those patches ? Hard to tell! Some of those are ready, others need review, others need work. The autotools patches need review, but they work. The patches to cross-build guix need some discussion and worse, cross-compiling guix currently uses a terrible kludge; so while also that "works", its still under development. Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Progress on the Hurd; new state of wip-hurd-vm
Hello, I just reset wip-hurd-vm to ba6bdb0d0b gnu: guix: Run `make update-guix-package'. Like before, you should be able to run ./pre-inst-env guix build -f gnu/system/hurd.scm on it to get a VM and start it doing something like guix environment --ad-hoc qemu -- qemu-system-i386 -enable-kvm \ -snapshot -hda $(./pre-inst-env guix build -f gnu/system/hurd.scm) -m 2G \ -device rtl8139,netdev=net0 -netdev user,id=net0,hostfwd=tcp:127.0.0.1:10022-: The VM now starts the Shepherd which starts the guix-daemon as well as an openssh daemon. root shares the system profile, which has been setup for minimalistic Guix development. You can build our first package ssh root@localhost -p 10022 guix build --no-offload -e '(@@ (gnu packages commencement) gnu-make-boot0)' and now also do that from git git clone gnu:guix cd guix ./bootstrap ./configure --localstatedir=/var --sysconfdir=/etc --with-courage make -j2 ./pre-inst-env guix build --no-offload -e '(@@ (gnu packages commencement) gnu-make-boot0)' Being able to build packages from git greatly reduces the round-trip time :-) The Shepherd integration needs more work. Also, the tip of that branch shows some troublesome commits that hack around cross-compiling guix to the Hurd. Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
[BLOG] A "Hello World" VM running the Hurd!
Hi! We have just published a new blog post---a follow-up, in a way to last week's April 1 post---about some real achievement: Using Guix we have cross-built a VM image for the Hurd. Read more... https://guix.gnu.org/blog/2020/a-hello-world-virtual-machine-running-the-hurd/ Enjoy! Janneke & Ludovic -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: [BLOG] On migration to the Hurd
":" sed "/bin"
+ ":/run/current-system/profile/bin"
+ ":/run/current-system/profile/sbin"))
+ )
+ (substitute* (string-append out "/bin/sush")
+ (("-/bin/fmt") (string-append "-/" coreutils "/bin/fmt"))
+ (("-/bin/login") (string-append "-/" coreutils "/bin/legin")))
#t
#:configure-flags (list (string-append "LDFLAGS=-Wl,-rpath="
%output "/lib")
@@ -370,8 +401,11 @@ boot, since this cannot be done from GNU/Linux."
"--without-parted")))
(build-system gnu-build-system)
(inputs
- `(("glibc-hurd-headers" ,glibc/hurd-headers)
- ("hurd-rc" ,(hurd-rc-script
+ `(("bash" ,bash-minimal)
+ ("coreutils" ,coreutils)
+ ("glibc-hurd-headers" ,glibc/hurd-headers)
+ ("hurd-rc" ,(hurd-rc-script))
+ ("sed" ,sed)))
(native-inputs
`(("autoconf" ,autoconf)
("automake" ,automake)
--
2.26.0
>From 293e2c316005f2674b3cad32a2127c27a70b8ff6 Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen"
Date: Sat, 4 Apr 2020 11:53:13 +0200
Subject: [PATCH 3/3] system: hurd: Add /bin/sh symlink.
* gnu/system/hurd.scm (cross-hurd-image): Create /bin/sh symlink.
---
gnu/system/hurd.scm | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/gnu/system/hurd.scm b/gnu/system/hurd.scm
index 97c54a2992..82a9d94d5c 100644
--- a/gnu/system/hurd.scm
+++ b/gnu/system/hurd.scm
@@ -1,6 +1,7 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2020 Ludovic Courtès
;;; Copyright © 2020 Rene Saavedra
+;;; Copyright © 2020 Jan (janneke) Nieuwenhuizen
;;;
;;; This file is part of GNU Guix.
;;;
@@ -22,6 +23,7 @@
#:use-module (guix utils)
#:use-module (gnu bootloader grub)
#:use-module (gnu packages base)
+ #:use-module (gnu packages bash)
#:use-module (gnu packages cross-base)
#:use-module (gnu packages hurd)
#:use-module (gnu system vm)
@@ -45,7 +47,7 @@
(directory-union "gnu+hurd"
(cons (with-parameters ((%current-system "i686-linux"))
gnumach)
- (for-hurd hurd coreutils grep sed)
+ (for-hurd hurd bash-minimal coreutils grep sed)
(define grub.cfg
(let ((hurd (with-parameters ((%current-target-system "i586-pc-gnu"))
@@ -99,7 +101,11 @@ menuentry \"GNU\" {
("/libexec" -> ,(file-append (with-parameters ((%current-target-system
"i586-pc-gnu"))
hurd)
- "/libexec"
+ "/libexec"))
+ ("/bin/sh" -> ,(file-append (with-parameters ((%current-target-system
+ "i586-pc-gnu"))
+bash-minimal)
+ "/bin/sh"
(qemu-image #:file-system-type "ext2"
#:file-system-options '("-o" "hurd")
--
2.26.0
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
