Guix Without Scheme
Hi Guixers, I just wanted to share this presentation that Singpolyma gave titled "Guix Without Scheme": https://archive.org/details/singpolyma-guix-without-scheme Through the course of the presentation, singpolyma demos how to build a Guix package with javascript as well as lua. What do people think of leveraging Guile's compiler tower to write Guix packages in lua, javascript, python, and other languages? nix perhaps? Might be meta fun to write a Guix package in a guile implemented nix frontend. Maybe we should think of Scheme as just one frontend among many to Guile's compiler tower? Is it a future goal for Guix to fully support this unique feature? all best, jgart
lagrange install japanese fonts and other fonts?
Just wanted to add a packaging TODO for lagrange for when we get around to it: https://github.com/skyjake/lagrange/issues/526 Should I send issues like this to guix-patc...@gnu.org instead? all best, jgart
Re: Tom Lord passing
Thanks for sharing, even if accidental. What a shame. Kind regards, T G-R Sent on the go. Excuse or enjoy my brevity.
Re: Tom Lord passing
sorry... the mail was meant to go to another mailing list... Tom Lord had no direct relation to guix On Tue, Jul 19, 2022 at 4:30 PM Andy Tai wrote: > > Thomas Lord was an early (or the first?) maintainer of guile > > from https://berkeleydailyplanet.com/issue/2022-06-26/article/49837 > > Obituaries > > Thomas Lord > 1966-2022
Tom Lord passing
Thomas Lord was an early (or the first?) maintainer of guile from https://berkeleydailyplanet.com/issue/2022-06-26/article/49837 Obituaries Thomas Lord 1966-2022 Trina Pundurs Monday June 27, 2022 - 05:21:00 PM Thomas Lord was born April 26, 1966 in Pittsburgh, Pennsylvania, where he lived until the age of 10 when his family relocated to western Massachusetts. He graduated from Phillips Academy Andover in 1984. He attended Johns Hopkins University and Carnegie Mellon University, and in 1987 began his career as a software engineer at Carnegie Mellon, working on the Andrew Project. During this time he became interested in the free software movement (http://www.gnu.org/philosophy/philosophy.html) and thereafter dedicated himself to developing and supporting free software (aka libre software or open source). He worked as an employee of the Free Software Foundation, developing for the GNU Project, for several years in the early 1990s. In 1995 he first moved to Berkeley and began spending time in People’s Park, a place and a society that held great meaning for him. He returned to Pittsburgh PA in 1998, then came back to the Bay Area in 2001 and relocated permanently to Berkeley in 2004. In 2007 he married Trina Pundurs, his life partner since 1992. Upon settling in Berkeley, he began engaging with city politics and policymaking. His interest led him to contribute to the Berkeley Daily Planet, and his work with Planet editor Becky O’Malley drew him further into city and regional issues, especially housing, displacement, and homelessness. In 2016 he was appointed by then-Councilmember Cheryl Davila to serve on the City Housing Advisory Commission. In 2018 he was profoundly moved by a news report about scientists weeping in the aisles at COP 24, where the IPCC presented its Special Report on the impact of global warming of 1.5° C (“IPCC SR15”). Upon studying SR15, and following the work of Greta Thunberg, he became a tireless advocate of speaking the truth about the climate emergency and treating it as an actual emergency. In addition to his climate and housing activism, he spent several years volunteering with students at Longfellow Middle School as part of the Writer Coach Connection program. He died unexpectedly this week of a massive brain hemorrhage. Thomas is survived by his wife Trina Pundurs, mother Luanna Pierannunzi, uncle Christopher Lord, aunt Sharlene Jones, and many cousins and extended family.
Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic
July 15, 2022 7:23 AM, "Csepp" wrote: > Vagrant Cascadian writes: > > > If the goal is to produce highly secure servers than I'd like to suggest > unikernels once again. No Guix running on the deployed server, but the > server image is built by and possibly deployed by Guix. > Of course the downside is that they do a whole lot less than OpenBSD or > Linux. But if your use case is already covered, that's actually a > positive, since no extra features means smaller attack surface. > MirageOS could be a good starting point, since we already have a good > chunk of Ocaml tooling integrated into Guix. > http://unikernel.org/projects > There was a Nix project with similar aims that sadly fizzled out, so > it's probably not exactly an easy task to tackle, but it's much easier > than porting Guix to a new kernel and packaging a userland for that > kernel. Thanks for the suggestion! That would be a really secure server!
Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic
July 14, 2022 11:38 AM, "Vagrant Cascadian" wrote: > On 2022-07-14, zimoun wrote: > >> Well, dreaming about science fiction, it appears me more approachable to >> have Guix running on something as Debian/kfreeBSD – it could be an >> interesting project with the help of Debian folks. Other said, “just” >> replace the Linux kernel by a variant of the FreeBSD one running with >> GNU GLibc. > > Well, guile-3.0 does not build on Debian GNU/kFreeBSD, so that would be > a bit of a blocker for a GNU Guix port: > > https://buildd.debian.org/guile-3.0 > > But guile-2.2 built fine: > > https://buildd.debian.org/guile-2.2 > > It is a rough port, I have toyed with it now and again ... requires lots > of patches to code that assume userland based on running kernel; patches > that upstreams are hesitant to take, etc. It is great as a grueling test > of coding assumptions, though! Does guile 3.0+ compile on the GNU/Hurd? > > My guess is you would have the same sort of problems with porting GNU > Guix to any of the *BSD. > > Definitely the sort of project that would take someone highly motivated > over many years... > > live well, > vagrant
Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic
July 14, 2022 9:06 AM, "zimoun" wrote: > Hi Tobias, All, > > (French Bastille Day is a day off, so a day for trolling. ;-)) > > On Thu, 14 Jul 2022 at 10:40, Tobias Geerinckx-Rice wrote: > >> https://www.hyperbola.info/news/announcing-hyperbolabsd-roadmap > > Thanks for the link. It is helpful for understanding. :-) > >> Far from 'recent' in my book. > > Indeed, the announcement is from 2019-12-21. :-) > > Quoting: > > This will not be a "distro", but a hard fork of the OpenBSD > kernel and userspace > > Not being a new distro means using the venerable pkg_* package manager, > right? Well, I am confused by the aim… They want to use pacman apparently. :) > >>> If you run OpenBSD kernel and OpenBSD userland, why not just run an >>> OpenBSD system? :-) >> >> Because it contains blobs. HyperbolaBSD doesn't, by definition (see above). > > …because HyperboladBSD seems a new distro as gnewSense is a new distro > free from problematic parts but based on an existing other one. Well, > since it had been announced on late 2019 and we are in 2022, it could be > interesting to know the status on this project. > >> Whatever my opinion on WSL, Darwin, and the Hurd, I must concede that they >> at least exist. >> >> Porting Guix to something that doesn't is a poor investment in comparison. > > Just to be sure to understand, the initial question is to port Guix to > HyperbolaBSD which is a variant of OpenBSD (kernel and userland). > > Therefore, correct me if I misunderstand something, it means: > > 1. port Guix to a new kernel not using the GLibc > 2. package all the (free) userland OpenBSD managed by Guix > > Bah I wish all the best for people who would tackle this. :-) > > Well, dreaming about science fiction, Thanks for speaking plainly. I did not realize how difficult this project would be. :) > it appears me more approachable to > have Guix running on something as Debian/kfreeBSD – it could be an > interesting project with the help of Debian folks. Other said, “just” > replace the Linux kernel by a variant of the FreeBSD one running with > GNU GLibc. > > However, doing so, the point #2 (BSD userland) is lost. > > My understanding is: #1 and #2 require more work than the union of the > Guix community *and* the other kernel community could provide, IMHO. > Assuming both communities would be interested in. :-) > > Cheers, > simon
Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic
July 14, 2022 6:24 AM, "zimoun" wrote: > Hi, > > On Mon, 11 Jul 2022 at 18:44, Joshua Branson wrote: > > Well, I am missing where it is announced. Could you be more specific? Someone else already provided the link, but someone on irc did ask me where the source code for HyperbolaBSD is? I can't find it, and that is a bit troubling... > > If you run OpenBSD kernel and OpenBSD userland, why not just run an > OpenBSD system? :-) I love that Guix is the Emacs of distros! It's cool to customize it! And easy! But OpenBSD "seems to be more secure" than GNU/Linux. And Linux is huge! And OpenBSD has some awesome software: pf, spamd, httpd, and some other stuff that their marketing tells me is good. Maybe a good first step would be for guix to provide a hardened linux package. > Well, Debian is working (maybe the project is stalling?) on running GNU > userland using GLibc on the top of a FreeBSD kernel. The conclusion is: > it is a piece of work. :-) > > https://www.debian.org/ports/kfreebsd-gnu > > What I miss with your proposal is: are you interested by OpenBSD > userland software and you would like them running on a Linux kernel? Or > are you interested by specific OpenBSD kernel feature and you would like > be able to run GNU software on it? I would love to use a secure, extensible, microkernel/exokernel that has a universal guixy configuration language. Guix GNU/Hurd System vm is probably the best candidate for this, but my understanding is that the "childhurd" (a GNU/Hurd running on top of GNU/Linux) is not very stable. Possibly because the vm image does not have a swap space. There was an open bug report for it but I cannot find it. Has anyone here had a good experience with a childhurd? Not a criticism, I just have not heard many people say that the childhurd is stable/awesome. > > I think, similar as Josselin, that it requires a lot of work because > many low-level features are kernel dependant. Therefore, it appears to > me more being worth to focus on smoothing the WSL2 experience, focus on > the Hurd, or to attempt something on the Darwin kernel. > > Cheers, > simon
Re: Dealing with non-ASCII file names in BOOTSTRAP-ORIGIN
Greg Hogan skriver:
> On the off chance that the following is helpful, in order to switch
> the build to GCC 11 or 12 I had to apply the patch (with the missing
> endif) from
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017#c12
>
> You may have avoided or worked around this issue, but even though a
> different fix from the ticket was patched into our GCC 11.3 and 12.1,
> these would not bootstrap for me without that patch.
Neat. Do you have a patch submitted to the tracker already? Did you
also find a solution to the file name problem?
I took a slightly different route to work around the libstdc++ bootstrap
issue (see bottom hunk):
--8<---cut here---start->8---
(add-after 'unpack 'apply-patches-and-snippet
(lambda* (#:key inputs #:allow-other-keys)
(let ((patch1 (assoc-ref inputs "patch1"))
(patch2 (assoc-ref inputs "patch2"))
(libstdc++ (assoc-ref inputs "libstdc++")))
;; Apply the patch inputs added below.
(for-each (lambda (patch)
(invoke "patch" "-p1" "--input" patch
"--no-backup-if-mismatch"))
(list patch1 patch2))
;; Apply the gcc-canadian-cross-objdump snippet.
(substitute* "libcc1/configure"
(("\\$gcc_cv_objdump -T")
"$OBJDUMP_FOR_TARGET -T"))
;; Fix a regression in GCC 11 where the libstc++ input
;; shadows glibc headers when building libstdc++. An
;; upstream fix was added in GCC 11.3.0, but it only
;; hides system include directories, not those on
;; CPLUS_INCLUDE_PATH. See discussion at
;; .
(substitute* "libstdc++-v3/src/c++17/Makefile.in"
(("^AM_CXXFLAGS = ")
(string-append "CPLUS_INCLUDE_PATH = "
(string-join
(remove (cut string-prefix? libstdc++
<>)
(string-split
(getenv "CPLUS_INCLUDE_PATH")
#\:))
":")
"\nAM_CXXFLAGS = "
--8<---cut here---end--->8---
It's not pretty, but does the job! I won't push it right away though,
waiting for feedback and checking that things generally work first.
--
Thanks,
Marius
signature.asc
Description: PGP signature
Re: Dealing with non-ASCII file names in BOOTSTRAP-ORIGIN
Marius,
Thank you for your work upgrading the core packages!
On the off chance that the following is helpful, in order to switch
the build to GCC 11 or 12 I had to apply the patch (with the missing
endif) from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017#c12
You may have avoided or worked around this issue, but even though a
different fix from the ticket was patched into our GCC 11.3 and 12.1,
these would not bootstrap for me without that patch.
Greg
On Mon, Jul 18, 2022 at 3:49 PM Marius Bakke wrote:
>
> Hi Guix,
>
> I tried switching to GCC 11 on the core-updates branch, but it fails
> early when attempting to repack the GCC source code for GCC-BOOT0,
> because some files in its test suite contains non-ASCII characters:
>
> --8<---cut here---start->8---
> [... unpacking ...]
> patching file gcc/builtins.c
> Hunk #1 succeeded at 4623 with fuzz 1 (offset 1341 lines).
> Hunk #2 succeeded at 6097 with fuzz 2 (offset 2206 lines).
> patching file gcc/gimple-fold.c
> Hunk #1 succeeded at 665 (offset 9 lines).
> Hunk #2 succeeded at 766 with fuzz 2 (offset 16 lines).
> patching file libvtv/Makefile.in
> Hunk #1 succeeded at 14 with fuzz 1 (offset -1 lines).
> source is at 'gcc-11.3.0'
> applying
> '/gnu/store/g0ba4l825z9i4l1jd5cqvl6m09xicdwa-gcc-9-strmov-store-file-names.patch'...
> applying
> '/gnu/store/5705r4ajxl8lav1hz9xm19w75zdcz1n2-gcc-5.0-libvtv-runpath.patch'...
> find-files:
> gcc-11.3.0/gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/Äfoo.go: No
> such file or directory
> Backtrace:
> In srfi/srfi-1.scm:
> 465: 19 [fold # result+visited)> ...]
> In ice-9/ftw.scm:
> 452: 18 [# result+visited)> # #]
> 450: 17 [loop "gcc" "gcc-11.3.0" ...]
> In srfi/srfi-1.scm:
> 465: 16 [fold # result+visited)> ...]
> In ice-9/ftw.scm:
> 452: 15 [# result+visited)> # #]
> 450: 14 [loop "testsuite" "gcc-11.3.0/gcc" ...]
> In srfi/srfi-1.scm:
> 465: 13 [fold # result+visited)> ...]
> In ice-9/ftw.scm:
> 452: 12 [#
> # #]
> 450: 11 [loop "go.test" "gcc-11.3.0/gcc/testsuite" ...]
> In srfi/srfi-1.scm:
> 465: 10 [fold # result+visited)> ...]
> In ice-9/ftw.scm:
> 452: 9 [#
> # #]
> 450: 8 [loop "test" "gcc-11.3.0/gcc/testsuite/go.test" ...]
> In srfi/srfi-1.scm:
> 465: 7 [fold # result+visited)> ...]
> In ice-9/ftw.scm:
> 452: 6 [#
> # #]
> 450: 5 [loop "fixedbugs" "gcc-11.3.0/gcc/testsuite/go.test/test" ...]
> In srfi/srfi-1.scm:
> 465: 4 [fold # result+visited)> ...]
> In ice-9/ftw.scm:
> 452: 3 [#
> # #]
> 474: 2 [loop "issue27836.dir" ...]
> In guix/build/utils.scm:
> 540: 1 [# result)>
> "gcc-11.3.0/gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/Äfoo.go" ...]
> In unknown file:
>?: 0 [scm-error misc-error #f "~A" ("find-files failed") #f]
>
> ERROR: In procedure scm-error:
> ERROR: find-files failed
> --8<---cut here---end--->8---
>
> Deleting these files also don't work for the same reason, even when
> using the hex representation, i.e. (delete-file "\u00c4foo.go"), or with
> DELETE-FILE-RECURSIVELY.
>
> One workaround is to avoid the use of BOOTSTRAP-ORIGIN by applying the
> patches and snippet in phases, but that's suboptimal because it has to
> be done for all of GCC-BOOT0, LIBSTDC++, and GCC-FINAL.
>
> I'll try this workaround to get things going, but hoping for better
> suggestions!
>
Re: “Building a Secure Software Supply Chain with GNU Guix”
Ludovic Courtès schreef op ma 18-07-2022 om 10:45 [+0200]: > The model here is that users trust authorized committers. When you > think about it, there’s no way around it, because at the end of the > day, you’re installing software that an authorized committer added to > the channel. FWIW, something I haven't seen mentioned yet is that the trust problem could be reduced by some kind of multisig system, where multiple independent persons would need to sign the commit for it to be accepted, though that might be technically hard to implement and probably be too people-time-expensive currently. Greetings, Maxime.
Re: “Building a Secure Software Supply Chain with GNU Guix”
Arun Isaac schreef op di 19-07-2022 om 12:51 [+0530]: > > Hi Ludo, > > > https://doi.org/10.22152/programming-journal.org/2023/7/1 > > This is an excellent read! Are there plans to release this git > authentication system as a separate tool so that other non-Guix > projects may use it easily? FWIW I have been using "guix git authenticate" + .guix-authorizations in the Git repo of Scheme-GNUnet for letting users verify whether they got an 'authentic' copy. Greetings, Maxime.
Re: maradns reproducibility fixes and the merits of picking a random number
Ludovic Courtès 写道： Honestly, I don’t think it’s worth bothering about the non-substitutable trick. Agreed. In practice, maradns should be able to rely on /dev/urandom at run time, right? That is my understanding. Kind regards, T G-R signature.asc Description: PGP signature
Re: Non-free data in Poppler test suite
Ludovic Courtès schreef op vr 01-07-2022 om 14:57 [+0200]: > Nitpick: it’s not that “the FSDG applies to Guix” but rather the Guix > project chooses to follow the FSDG (info "(guix) Software Freedom"). OOps, I searched for 'FSDG' but not for 'free software distribution guidelines' ... Greetings, Maxime.
Re: “Building a Secure Software Supply Chain with GNU Guix”
Hi! Arun Isaac skribis: > This is an excellent read! Are there plans to release this git > authentication system as a separate tool so that other non-Guix projects > may use it easily? Not really. ‘guix git authenticate’ is already usable outside and the modules behind it are well isolated from the rest of Guix though. https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-git-authenticate.html I don’t plan personally to make it a separately-maintained tool, but it could be interesting. More generally, getting in touch with the Git developers and also with other projects with similar concerns would be great. Ludo’.
Re: “Building a Secure Software Supply Chain with GNU Guix”
Hi Ludo, > https://doi.org/10.22152/programming-journal.org/2023/7/1 This is an excellent read! Are there plans to release this git authentication system as a separate tool so that other non-Guix projects may use it easily? Thanks, Arun
