Re: Please review blog post draft: powerpc64le-linux support
Hi Joshua, Joshua Branson writes: > Awesome! Great work! I read the below draft blog post like a Harry > Potter novel! It is superbly written. And it makes a lot of sense! Thank you for the kind words, and your feedback! >> +### Why Is This Important? >> + >> +This is important because it means that GNU Guix now works on the [RYF >> +Talos II and Talos II Lite >> +mainboards](https://www.fsf.org/news/talos-ii-mainboard-and-talos-ii-lite-mainboard-now-fsf-certified-to-respect-your-freedom) >> +and it's IBM POWER9 processor. This is a modern, performant hardware > > I believe you should use "its". it's is short for "it is". Good catch! >> +platform that respects your freedom. It can run without any non-free >> +code, all the way down to its bootloader and firmware. It's a >> +freedom-friendly platform that aligns well with GNU Guix's commitment >> +to software freedom. >> + >> +How is this any different from existing RYF hardware, you might ask? >> +The existing RYF >> +[laptops](https://ryf.fsf.org/products?category=1=All_by=created_order=DESC), >> +[mainboards](https://ryf.fsf.org/products?category=5=All_by=created_order=DESC), >> +and >> +[workstations](https://ryf.fsf.org/products?category=30=All_by=created_order=DESC) >> +can only really be used with Intel Core Duo or AMD Opteron processors. >> +Those processors were released over 15 years ago. Since then, >> +processor performance has increased drastically. People should not >> +have to choose between performance and freedom, but the fact is that >> +for many years, that is exactly what we were forced to do. However, >> +the Talos II and Talos II Lite have changed this: the free software >> +community now has an RYF-certified option that can compete with the >> +performance of modern Intel and AMD systems. >> + >> +Although the performance of POWER9 processors is competitive with >> +modern Intel and AMD processors, its real advantage is that it< > > Why is there "it<" ? Is that some markup I'm not familiar with? Nope, it's a typo. Good eyes! >> +respects your freedom. Modern processors from [both Intel and AMD >> +include back >> +doors](https://www.fsf.org/blogs/sysadmin/the-management-engine-an-attack-on-computer-users-freedom) >> +over which you are given no control. Additionally, hardware design >> +defects in the processors of both vendors have been discovered, giving >> +rise to critical security vulnerabilities like >> +[Spectre](https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)) >> +and >> +[Meltdown](https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)). >> +In many cases, these vulnerabilities can only be fixed by installing >> +[non-free CPU microcode](https://wiki.debian.org/Microcode) - unless, >> +of course, [the vendor decides not to provide any fix at >> +all](https://arstechnica.com/gadgets/2018/04/intel-drops-plans-to-develop-spectre-microcode-for-ancient-chips/)! >> + >> +Compared to that, the RYF Talos II and Talos II Lite are a breath of >> +fresh air that the free software community really deserves. Raptor >> +Computing Systems' commitment to software freedom and owner control is >> +an inspiring reminder that it **is** possible to ship a great product >> +that respects the freedom of your customers. And going forward, the >> +future looks bright for the open, royalty-free Power ISA, [which is >> +now a Linux Foundation >> +project](https://www.linuxfoundation.org/press-release/2019/08/the-linux-foundation-announces-new-open-hardware-technologies-and-collaboration/) >> +(see also: [the same announcement from The OpenPOWER >> +Foundation](https://openpowerfoundation.org/the-next-step-in-the-openpower-foundation-journey/). >> + >> + >> +In Guix, all software for a given system (e.g., powerpc64le-linux) is >> +built starting from its bootstrap binaries. It is intended that the >> +bootstrap binaries are the only pieces of software in the entire >> +package collection that Guix cannot build from source. In practice, >> +[additional bootstrap roots are >> +possible](https://lists.gnu.org/archive/html/guix-devel/2015-02/msg00814.html), >> +but introducing them in Guix is highly discouraged, and our community >> +[actively](https://guix.gnu.org/en/blog/2019/guix-reduces-bootstrap-seed-by-50/) >> +[works](https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/) >> +to [reduce](https://guix.gnu.org/en/blog/2018/bootstrapping-rust/) our >> +overall bootstrap footprint. >> + >> +So first you need to build the the bootstrap binaries for your > > "the the" --> "the" Fixed! >> +platform. In theory, you can do this in many ways. For example, you >> +might try to manually compile them on an existing system. However, >> +Guix has [package >> +definitions](https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/make-bootstrap.scm?id=5d8c2c00d60196c46a32b68c618ccbe2b3aa48f4) >> +that you can use to build them - using Guix, of course! >> >> +In both the big-endian
Re: A new wip-emacs branch
Hi Leo! Thanks so much for working to improve Emacs packaging in Guix! I have a question and a comment about your approach on the wip-emacs branch. On Tue, Apr 06 2021, Leo Prikler wrote: Emacs now gets its core lisp path from the wrapper rather than the search path and there's a new profile hook adding all top-level subdirectories to a subdirs.el, that gets loaded at startup. This sounds great in terms of Emacs starting in an already established profile, but one key use case for me is to be able to install new packages without restarting Emacs. Usually I can do this in eshell by running $ guix install emacs-magit # shell command ... $ guix-emacs-autoload-packages # emacs command ... I just tried this in a fresh profile with a Guix built from wip-emacs, but it didn't seem to work. It's possible that I've done something wrong (I'm doing it with time-machine, which adds its own complexities), but are you expecting this to work? It looks like guix-emacs wasn't loaded, and it wasn't on the load path, but I haven't had a chance to investigate further than that. Extending PATH in the same wrapper as EMACSLOADPATH seems to be a fairly cheap option, however. I'm not supportive of this, because extending PATH would also change the binaries that are available through Emacs' shells, which I use a lot. This would mean that either (a) the Emacs packages can shadow what I've explicitly installed in my profile, potentially leading to me running unexpected versions of programs, or (b) installing something else in my profile might break something in Emacs because the version has changed. This isn't likely to be a major problem for coreutils and gzip, assuming they're stable enough, but it is a problem in general. In my view either patching the Emacs libraries (to avoid the conflict) or propagating inputs (to expose the potential conflict while building the profile) are better options. Thanks again! Carlo
Re: [PATCH 0/9] Add 32-bit powerpc support
Hello, On Tue, Apr 6, 2021 at 2:26 PM Efraim Flashner wrote: > The wip-ppc branch on Savannah is currently in a good state. With the > recent rapid churn on core-updates I haven't been very quick about > rebasing on core-updates but I can confirm that building out to mesa > works. Building is slow, it took 6 days to build from guile-final to > mesa without stopping. I still haven't dragged my G4 mini from its osx misery, so I tried cross-building (from x86_64) instead. cross-builds ok: * bootstrap-tarballs * guile * binutils * mac-fdisk failed: * guix (perl refused to cross-build) * nss, because nspr failed with: [...] ../../../config/./nsinstall -R -m 444 ./_aix32.cfg ./_aix64.cfg ./_bsdi.cfg ./_darwin.cfg ./_freebsd.cfg ./_hpux32.cfg ./_hpux64.cfg ./_linux.cfg ./_netbsd.cfg ./_nto.cfg ./_openbsd.cfg ./_os2.cfg ./_qnx.cfg ./_riscos.cfg ./_scoos.cfg ./_solaris.cfg ./_unixware7.cfg ./_unixware.cfg ./_win95.cfg ./_winnt.cfg ../../../dist/include/nspr/md ../../../config/./nsinstall: ../../../config/./nsinstall: cannot execute binary file mesa and afl refused because of meson-build-system. -- Vincent Legoll
Pruning inactive committers
Hello, We recently formalized our policy regarding what to do about inactive committers [0]. Basically, after 1 year without activity using commit access, one's commit access will be disabled. In coordination with the Guix maintainer collective, I put this policy into practice and removed such committers, yesterday and today. Specifically, this means: 1) removing the inactive committers from the Guix group on Savannah [1] 2) deauthorizing their code-signing keys [2] Sincerely, Leo Famulari [0] https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html [1] On Savannah, commit access is synonymous with group membership https://savannah.gnu.org/projects/guix [2] https://git.savannah.gnu.org/cgit/guix.git/log/.guix-authorizations signature.asc Description: PGP signature
Re: GNOME 40
Hello Guix! Sorry for the delayed response. I also didn't receive emails as I am not subscribed to the list. @Mark Thanks for bringing up your concern, which is very valid. My hyper-focus on working on GNOME40 slightly made me to overlook certain things like mail-lists and reviews, even though I deeply value them. @Chistopher @zimoun @civodul Thank you all for your thoughts. @Leo It is very natural that one might miss certain things while intensively working on something. Its great we had/have these folks and other community members to have our backs by keeping us in check. :) Let us do this, [1] Create wip-gnome branch on savannah [2] Create guix-patches thread for wip-gnome. [3] Leo, me or anyone else can contribute by sending patches to that thread. [4] Leo and I (hopefully after getting commit access) can review and push the patches to wip-gnome. [5] From wip-gnome, any existing committers can double-check and merge commits to core-updates. Sounds good for everyone? Let us all work together and make Guix's GNOME awesome, comrades! :-) Regards, RG. OpenPGP_signature Description: OpenPGP digital signature
Re: website: Building fails because of missing locales
On Wednesday, April 7, 2021 5:22 PM, Julien Lepiller wrote: > Here's v2. > > I checked that it sets GUIX_LOCPATH properly on my system (I had to add > the path specification for it to work). Thanks, Julien, with this new patch, the website builds. But I noticed other problems now: 1. It does not run (haunt serve fails). 2. Running it with "python3 -m http.server" instead, I see many characters replaced by "?" marks. I'm using the commands from the website's README, but omitting "-E GUIX_LOCPATH" and changing "lib/locale" to "lib/locales" because the former does not exist. So this is the command I ran to build: $ LANG=C GUIX_WEB_SITE_LOCAL=yes guix environment -C -m manifest.scm -E LANG --share=$HOME/.guix-profile/lib/locales -E GUIX_WEB_SITE_LOCAL --share=/tmp -- haunt build And this one for serving: $ guix environment -CN -m manifest.scm -E LANG --share=$HOME/.guix-profile/lib/locales --share=/tmp -- haunt serve guile: warning: failed to install locale Backtrace: 2 (primitive-load "/gnu/store/k3650bnqc741650cg36nv2wan82?") In haunt/ui.scm: 130:2 1 (haunt-main _ "serve") In unknown file: 0 (setlocale 6 "") ERROR: In procedure setlocale: In procedure setlocale: Invalid argument Am I doing something wrong?
Re: A new wip-emacs branch
Am Dienstag, den 06.04.2021, 11:06 +0200 schrieb Leo Prikler: > Hello Guix, > > this is a small progress report on wip-emacs. Emacs now gets its > core > lisp path from the wrapper rather than the search path and there's a > new profile hook adding all top-level subdirectories to a subdirs.el, > that gets loaded at startup. Emacs' build system has been rewritten > to > use ELPA-style subdirectories. Packages, that cause build failures > in > themselves or others by not adhering to this practice, have been > adjusted. Small progress report part II, here's the packages, that still contain plain files: /gnu/store/0nrhnq7csbbgh79scc68yy3y1l621hy0-emacs-dvc-0.0.0-1.591/ /gnu/store/cyga8wwz77280xcwk6nma6gsh49k954h-emacs-subdirs/ /gnu/store/gwkma1hhyp7cmfdlp6g00zzg18sk2ql2-emacs-guix-0.5.2-4.8ce6d21/ /gnu/store/gyjz18k9gh0bsv3j122abbcbi2qzgz4z-emacs-shroud-1.105/ /gnu/store/kz1lhfyzb38n0q1jqw3fvnjyylk67z57-emacs-w3m-2018-11-11/ /gnu/store/m6ws0xhs0svb7zcbk733n1ddlcpqd5ip-emacs-rime-1.0.4/ /gnu/store/mw7lghj1vsgcd6gp0vqx8sczgbmynym6-emacs-ddskk-17.1/ /gnu/store/n2zi43s18y4i0z002yj88n2ipr1ms7dv-emacs-julia-snail-1.0.0rc4/ /gnu/store/p71rm7qvscxs8kf68n4vacaf23xwz14q-emacs-haskell-mode-17.2/ /gnu/store/qi7kmb9hh9m11m5vrjasf26ydpjcbb5c-emacs-geiser-gauche-0.0.2/ /gnu/store/xdlhj4r2bw76sdkqbnsg5p0kvczfmjia-emacs-27.2/ /gnu/store/z88282qbjx5nnj9syddid5v3dw3qsvva-emacs-wget-0.5.0/ /gnu/store/zqapdihhi09cdls7zwv1bcannh7xqrjs-mu-1.4.15/ Obviously emacs-27.2 and emacs-subdirs deserve special treatment here, so they don't count. In total, that's 11 packages, which don't (yet) follow the ELPA subdirectory style. Regards, Leo
Re: website: Building fails because of missing locales
Here's v2.
I checked that it sets GUIX_LOCPATH properly on my system (I had to add
the path specification for it to work).
>From 70aa3b969e1830bce9e44b8dda0a97fcb27cce89 Mon Sep 17 00:00:00 2001
From: Julien Lepiller
Date: Tue, 6 Apr 2021 22:16:43 +0200
Subject: [PATCH] website: Add locales in manifest.
* website/manifest.scm: Add locale definition for all our translations.
---
website/manifest.scm | 62 ++--
1 file changed, 49 insertions(+), 13 deletions(-)
diff --git a/website/manifest.scm b/website/manifest.scm
index eda382a..6beb78e 100644
--- a/website/manifest.scm
+++ b/website/manifest.scm
@@ -1,6 +1,8 @@
(use-modules (guix packages)
((gnu packages package-management) #:select (guix))
((gnu packages guile-xyz) #:select (haunt))
+ (gnu system locale)
+ (ice-9 rdelim)
(srfi srfi-1))
(define the-good-guile
@@ -14,17 +16,51 @@
`(("guile" ,the-good-guile)
,@(alist-delete "guile" (package-inputs haunt))
-(packages->manifest
- (append
- ;; Guile needs to be compatible
- (list
- guix
- the-good-guile
- haunt-the-ghost)
+(define locales
+ (locale-directory
+(call-with-input-file "po/LINGUAS"
+ (lambda (port)
+(let loop ((line (read-line port))
+ (locales '()))
+ (if (eof-object? line)
+ locales
+ (if (equal? (string-ref line 0) #\#)
+ (loop (read-line port) locales)
+ (loop (read-line port)
+(cons
+ (locale-definition
+(name (string-append line ".utf8"))
+(source line))
+ locales)))
+#:libcs
+(list glibc)))
- ;; Other packages
- (map specification->package
- (list
-"glibc-locales"
-"git"
-"guile-syntax-highlight"
+(manifest
+ (cons
+(manifest-entry
+ (name "locales")
+ (version "0")
+ (item (computed-file "locales"
+ (with-imported-modules '((guix build utils))
+#~(let ((out (string-append #$output "/lib/locale")))
+(use-modules (guix build utils))
+(mkdir-p out)
+(copy-recursively #$locales out)
+ (search-paths
+(list (search-path-specification
+(variable "GUIX_LOCPATH")
+(files '("lib/locale"))
+(manifest-entries
+ (packages->manifest
+ (append
+;; Guile needs to be compatible
+(list
+ guix
+ the-good-guile
+ haunt-the-ghost)
+
+;; Other packages
+(map specification->package
+ (list
+ "git"
+ "guile-syntax-highlight")))
--
2.31.0
Re: website: Building fails because of missing locales
On Wednesday, April 7, 2021 3:10 PM, Julien Lepiller wrote: > Weird, is GUIX_LOCPATH not set at all maybe? I have this: $ echo $GUIX_LOCPATH /run/current-system/locale $ tree /run/current-system/locale /run/current-system/locale ├── 2.29 -> /gnu/store/dlf4a3zrx0rrb38v3w42317fbd2p4dnb-locale-2.29/2.29 └── 2.31 -> /gnu/store/xlzv58dyh7nw8gv1w33byhx8f19aqivk-locale-2.31/2.31 2 directories, 0 files For what it's worth, using the packages from my user profile, I can setlocale from a Guile REPL to "de_DE.utf8" and it works. I also tried it on my website, which is internationalized and localized, made it build pages in that same locale, and it works too (although it doesn't use Haunt nor Guix i18n mechanism, but it is Guile Scheme).
Re: Initiating Guix System on Foriegn Distro
Katarina Rostova writes: > Hi, > > I was wondering if I can do `guix system init` with guix installed on top off > a foreign distro? > > Katarina. Hey Katarina! You've got a great first name! Actually I think you can do 'guix system reconfigure config.scm' on top of a foreign distro. That's how some people initially guix system-ized digital ocean droplets. :) You might want to double check on #guix in irc if that's correct though...I sometimes make mistakes. :) Also, any help questions are best sent to help-g...@gnu.org. Welcome to the guix family! Joshua -- Joshua Branson (joshuaBPMan in #guix) Sent from Emacs and Gnus https://gnucode.me https://video.hardlimit.com/accounts/joshua_branson/video-channels https://propernaming.org "You can have whatever you want, as long as you help enough other people get what they want." - Zig Ziglar
Re: Meta guix: making money with GNU Guix: slightly off topic
Leo Famulari writes: > On Tue, Apr 06, 2021 at 12:05:00PM -0400, Joshua Branson wrote: >> Aloha you lovely people! I personally believe that people should make >> business out of free software. Here are some of my business ideas >> involving GNU Guix. I invite you all to beat me to market! > > VPS service that accepts a config.scm and returns a running virtual > machine, accessible with a web-based console (SSH, HTTPS and other > services would be enabled by the user as desired, in config.scm). I'm all game to do something like this! We could be a serious contender for linode or digital ocean! Guix already has a VPS like service...one would just need to write the web interface...and potentially buy some hardware. -- Joshua Branson (joshuaBPMan in #guix) Sent from Emacs and Gnus https://gnucode.me https://video.hardlimit.com/accounts/joshua_branson/video-channels https://propernaming.org "You can have whatever you want, as long as you help enough other people get what they want." - Zig Ziglar
Re: Document our WIP
Hello, On Tue, Apr 6, 2021 at 1:35 AM Léo Le Bouter wrote: > I am thinking we could establish policy so that the WIP wiki page is an > index to mailing list threads, git branches or other "updatable" > locations so that it is less likely to need updating and therefore > stays updated w.r.t. it's main purpose: finding out about WIP work. > > The policy would say that one must create a mailing list thread, git > branch or else and link it there and **NOT** include original > information on the wiki page but rather just link to ML/git/else. > > We could write such policy at the top of the page so contributors to it > can easily see it. > > What do you think? It can be an index, but I personally prefer if it can be a bit more than that, so I don't see strict policy being useful. Just collectively try to keep it sane, organized and as up to date as possible. It already is only an index to ML, blog, git branches for some items, and I think that's OK. I also think that the entries with a bit more context (arch support, mainly) are also useful in explaining what one can expect from that item. Thanks -- Vincent Legoll
Re: branch master updated: hydra: berlin: Accept new languages.
Ah! Why did I add this set_from_accept_language line? Let me try again… Le 7 avril 2021 11:26:37 GMT-04:00, Mathieu Othacehe a écrit : > >Hello Julien, > >> * hydra/nginx/berlin.scm (%extra-content): Autoredirect 'eo', >'ko' and 'ru' >> to the translated website. > >I had to revert this one that causes the following nginx error: > >2021/04/07 17:05:08 [emerg] 94058#0: variable already defined: "lang" >in >/gnu/store/ajvqgc205hvrfab7plbwds2a9wiqj52f-nginx.conf:4666 > >Mathieu
Re: Semi-automated patch review
Hello, On Wed, Apr 7, 2021 at 5:03 PM Andreas Enge wrote: > posting messages to the issues looks like a feasible and good thing to me, > then all relevant information would be present in the same place. Yes, +1 to that -- Vincent Legoll
Re: branch master updated: hydra: berlin: Accept new languages.
Hello Julien, > * hydra/nginx/berlin.scm (%extra-content): Autoredirect 'eo', 'ko' and > 'ru' > to the translated website. I had to revert this one that causes the following nginx error: 2021/04/07 17:05:08 [emerg] 94058#0: variable already defined: "lang" in /gnu/store/ajvqgc205hvrfab7plbwds2a9wiqj52f-nginx.conf:4666 Mathieu
Re: website: Building fails because of missing locales
Weird, is GUIX_LOCPATH not set at all maybe?
Le 7 avril 2021 09:48:02 GMT-04:00, Luis Felipe
a écrit :
>On Wednesday, April 7, 2021 11:09 AM, Julien Lepiller
> wrote:
>
>> Ah, don't pass -E GUIX_LOCPATH, I think it prevents guix from setting
>it properly in the environment.
>
>It fails a bit differently now; it errors trying to set locale
>"de_DE.utf8":
>
>
>$ LANG=C GUIX_WEB_SITE_LOCAL=yes guix environment -C -m manifest.scm -E
>LANG --share=$HOME/.guix-profile/lib/locales -E GUIX_WEB_SITE_LOCAL
>--share=/tmp -- haunt build
>Backtrace:
>In ice-9/boot-9.scm:
> 222:17 19 (map1 (((apps base data)) ((apps base templates #)) # ?))
> 3297:17 18 (resolve-interface (apps base data) #:select _ #:hide _ ?)
>In ice-9/threads.scm:
>390:8 17 (_ _)
>In ice-9/boot-9.scm:
> 3223:13 16 (_)
>In ice-9/threads.scm:
>390:8 15 (_ _)
>In ice-9/boot-9.scm:
> 3507:20 14 (_)
> 2806:4 13 (save-module-excursion _)
> 3527:26 12 (_)
>In unknown file:
> 11 (primitive-load-path "apps/base/data" #)
>In ice-9/eval.scm:
> 626:19 10 (_ #)
> 173:55 9 (_ #)
> 174:20 8 (_ #)
> 177:32 7 (lp (# ?))
>159:9 6 (_ #(# (G_ ?) ?))
>159:9 5 (_ #(# (G_ ?) ?))
>159:9 4 (_ #(# (G_ ?) ?))
>163:9 3 (_ #(# (G_ ?) ?))
>In srfi/srfi-1.scm:
> 586:17 2 (map1 ("de_DE" "en_US" "eo" "es_ES" "fr_FR" "ko_KR" # #))
>In ice-9/eval.scm:
>619:8 1 (_ #(#(# # ?) ?))
>In unknown file:
> 0 (setlocale 6 "de_DE.utf8")
>
>ERROR: In procedure setlocale:
>In procedure setlocale: Invalid argument
>
Re: Semi-automated patch review
Hello, Am Mon, Apr 05, 2021 at 11:52:53PM +0200 schrieb Léo Le Bouter: > Cbaines already runs automated patch testing infra at > https://data.guix-patches.cbaines.net/ and > https://patches.guix-patches.cbaines.net/project/guix-patches/list/ > > Considering that posting robot messages with test/lint/+ result > information on the issues directly and on the ML might get spammy posting messages to the issues looks like a feasible and good thing to me, then all relevant information would be present in the same place. Andreas
Re: configure: error: A recent Guile-zlib could not be found; please install it.
On Wed, 2021-04-07 at 15:37 +0100, Paul Garlick wrote: > Hi Roel, > > > How can I get a working development environment to work on Guix? > > A 'guix pull' within your profile will update the guile-zlib version > that is used by 'guix environment ...'. Then the configure script > requirement will be met. > Thanks! Cheers, Roel
Re: configure: error: A recent Guile-zlib could not be found; please install it.
Hi Roel, > How can I get a working development environment to work on Guix? A 'guix pull' within your profile will update the guile-zlib version that is used by 'guix environment ...'. Then the configure script requirement will be met. Best regards, Paul.
Re: website: Building fails because of missing locales
On Wednesday, April 7, 2021 11:09 AM, Julien Lepiller
wrote:
> Ah, don't pass -E GUIX_LOCPATH, I think it prevents guix from setting it
> properly in the environment.
It fails a bit differently now; it errors trying to set locale "de_DE.utf8":
$ LANG=C GUIX_WEB_SITE_LOCAL=yes guix environment -C -m manifest.scm -E LANG
--share=$HOME/.guix-profile/lib/locales -E GUIX_WEB_SITE_LOCAL --share=/tmp --
haunt build
Backtrace:
In ice-9/boot-9.scm:
222:17 19 (map1 (((apps base data)) ((apps base templates #)) # ?))
3297:17 18 (resolve-interface (apps base data) #:select _ #:hide _ ?)
In ice-9/threads.scm:
390:8 17 (_ _)
In ice-9/boot-9.scm:
3223:13 16 (_)
In ice-9/threads.scm:
390:8 15 (_ _)
In ice-9/boot-9.scm:
3507:20 14 (_)
2806:4 13 (save-module-excursion _)
3527:26 12 (_)
In unknown file:
11 (primitive-load-path "apps/base/data" #)
In ice-9/eval.scm:
626:19 10 (_ #)
173:55 9 (_ #)
174:20 8 (_ #)
177:32 7 (lp (# ?))
159:9 6 (_ #(# (G_ ?) ?))
159:9 5 (_ #(# (G_ ?) ?))
159:9 4 (_ #(# (G_ ?) ?))
163:9 3 (_ #(# (G_ ?) ?))
In srfi/srfi-1.scm:
586:17 2 (map1 ("de_DE" "en_US" "eo" "es_ES" "fr_FR" "ko_KR" # #))
In ice-9/eval.scm:
619:8 1 (_ #(#(# # ?) ?))
In unknown file:
0 (setlocale 6 "de_DE.utf8")
ERROR: In procedure setlocale:
In procedure setlocale: Invalid argument
Feature request: hostname namespaces in guix environment
Some programs (e.g. xpra) create files based on the hostname and it'd be useful to have control of this parameter. There's another reason to have custom hostnames within the container as well. From the guix manual[1]: While this will limit the leaking of user identity through home paths and > each of the user fields, this is only one useful component of a broader > privacy/anonymity solution—not one in and of itself. > Right now my hostname is leaking to the container and that is certainly a hint to my main persona. [1] https://guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html [2] https://man.archlinux.org/man/core/man-pages/uts_namespaces.7.en -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/
Feature request: Installatuon image for aarch64
I wish either a rootfs, or an installation.iso. Last year i failed to make one for myself, and used Armbian to install Guix System. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Initiating Guix System on Foriegn Distro
Hi, I was wondering if I can do `guix system init` with guix installed on top off a foreign distro? Katarina.
Re: Racket 8 and store references (was [security] Chunked store references in .zo files in Racket 8 #47614)
Indeed, I expect this is a more precise diagnosis of the same problem. My patch in https://issues.guix.gnu.org/47180 solves it by putting the store references (search paths for foreign libraries) in a configuration data file that isn't compiled, so they don't end up in .zo files in the first place. The .zo format is intentionally undocumented and subject to breaking change, including from different compilation options. At a minimum, a change to the Racket version number signals a breaking change to compiled code (e.g. Git is now at 8.0.0.13, so 13 breaking changes since the release). Internally, I don't know all the details, but the normal 8.0 .zo format has a Racket layer around the Chez Scheme object format, which seems to be very complex: it looks like it supports user-configurable compression at the granularity of the individual object within an object file. So it seems much better to avoid rewriting .zo files altogether. -Philip On 4/6/21 9:20 PM, Jack Hill wrote: On Tue, 6 Apr 2021, Mark H Weaver wrote: Anyway, I doubt that imposing such a limitation would adequately solve the problem here of chunked references in Racket 8, because I suspect that Racket 8 could split store references at arbitrary points in the string. I doubt that we can safely assume that the hash component of store references will be stored contiguously in *.zo files. Mark and everyone, I wanted to spin off a subthread on guix-devel, to make you aware of another problem that we've run into with reference in .zo getting mangled: https://issues.guix.gnu.org/47180 Best, Jack
Re: website: Building fails because of missing locales
Ah, don't pass -E GUIX_LOCPATH, I think it prevents guix from setting it
properly in the environment.
Le 6 avril 2021 22:20:32 GMT-04:00, Luis Felipe
a écrit :
>On Tuesday, April 6, 2021 8:20 PM, Julien Lepiller
>wrote:
>
>> Le Tue, 6 Apr 2021 14:11:03 -0400,
>> Leo Famulari l...@famulari.name a écrit :
>>
>> > On Tue, Apr 06, 2021 at 03:59:20PM +, Luis Felipe wrote:
>> >
>> > > Hello,
>> > > I updated my local copy of guix-artwork repository today and now
>> > > running "haunt build" fails with this message:
>
>[...]
>
>> > This happens for me too.
>>
>> Attached is a patch to the manifest.scm that should fix the issue: it
>> ensures that you enter an environment where the locales corresponding
>> to po/LINGUAS are available. Can you check if it fixes your issues?
>
>Leo, Julien, thanks for checking.
>
>Julien, unfortunately I get the same error after applying the patch:
>
>
>LANG=C GUIX_WEB_SITE_LOCAL=yes guix environment -C -m manifest.scm -E
>GUIX_LOCPATH -E LANG --share=$HOME/.guix-profile/lib/locales -E
>GUIX_WEB_SITE_LOCAL --share=/tmp -- haunt build
>Backtrace:
>In ice-9/threads.scm:
>390:8 19 (_ _)
>In ice-9/boot-9.scm:
> 3223:13 18 (_)
>In ice-9/threads.scm:
>390:8 17 (_ _)
>In ice-9/boot-9.scm:
> 3507:20 16 (_)
> 2806:4 15 (save-module-excursion _)
> 3527:26 14 (_)
>In unknown file:
> 13 (primitive-load-path "apps/base/data" #)
>In ice-9/eval.scm:
> 626:19 12 (_ #)
> 173:55 11 (_ #)
> 174:20 10 (_ #)
> 177:32 9 (lp (# ?))
>159:9 8 (_ #(# (G_ ?) ?))
>159:9 7 (_ #(# (G_ ?) ?))
>159:9 6 (_ #(# (G_ ?) ?))
>163:9 5 (_ #(# (G_ ?) ?))
>In srfi/srfi-1.scm:
> 586:29 4 (map1 ("de_DE" "en_US" "eo" "es_ES" "fr_FR" "ko_KR" # #))
> 586:29 3 (map1 ("en_US" "eo" "es_ES" "fr_FR" "ko_KR" "ru_RU" "?"))
> 586:17 2 (map1 ("eo" "es_ES" "fr_FR" "ko_KR" "ru_RU" "zh_CN"))
>In ice-9/eval.scm:
>619:8 1 (_ #(#(# # ?) ?))
>In unknown file:
> 0 (setlocale 6 "eo.utf8")
>
>ERROR: In procedure setlocale:
>In procedure setlocale: Invalid argument
>
Re: GCC: Canadian Cross + Dynamic linker issues
Let me please bump this thread a little bit, since I didn't get any answer > Hi, > > I've been struggling with GCC package definition for a while and I hope > someone > can help me solve or improve what I think are issues in its definition. > > I'm working on a R7RS-Small Scheme implementation that compiles to RISC-V > assembly and I'm finding many issues to create a RISC-V cross compiler. > > Consider the following manifest file for my project, where I need a GCC for > a 32 bit RISC-V machine: > > (use-modules (gnu packages cross-base) > (gnu packages gcc) > (gnu packages embedded)) > > (packages->manifest > > (let* ((triplet "riscv32-unknown-elf") > (binutils (cross-binutils triplet))) > (list > binutils > (cross-gcc triplet > #:xbinutils binutils > #:libc #f > > > The call to cross-gcc fails to find a dynamic linker and the installation > fails. > > This happens because GCC package definition calls to the function > `glibc-dynamic-linker` in `gnu/packages/bootstrap.scm`, that contains a list > of > possible triplets with their associated dynamic linker file name. > > I don't really understand why does a generic GCC package need to call a > function from the bootstrap module by default. I can see why GCC takes a huge > part on the bootstrapping process of Guix but I think that kind of coupling is > compromising the flexibility of the generic GCC package. Please, correct me if > I'm wrong. > > That said, in the past, I sent a patch[^patch] as a workaround because I saw > some references to AVR on the `glibc-dynamic-linker` that also used a fake > dynamic linker to avoid the function to fail but I got no response so I'm not > sure if the change makes any sense. > > Digging further on the GCC package definition I found a note that says: > > > ;; None of the flags below are needed when doing a Canadian cross. > > ;; TODO: Simplify this. > > So I wonder if that's the source of the problems I'm finding here. > > The `glibc-dynamic-linker` function is being used twice in the block preceded > by that comment and only once more below, in some patches we are applying on > top of the source code. > > At this level I'm not sure if there's any way to "fix" GCC package definition > to be able to create cross-compilers or if I should create a separate package > for my specific use-case and forget about all this. > > I would love to take part and try to simplify the GCC package description, but > as it is a fundamental package looks like a huge responsibility so I'd like to > have some guidance first. > > Thanks, > > Ekaitz > > [^patch]: https://issues.guix.gnu.org/46059
Re: A new wip-emacs branch
On Tue, Apr 06 2021, Leo Prikler wrote: >> FYI Geiser has recently been slit up into multiple packages with one >> core Geiser package[1]. Should the Geiser package be updated in >> wip-emacs or directly on master? >> >> [1]: https://github.com/melpa/melpa/pull/7514 > That depends. If geiser now uses an unaltered emacs-build-system it > can go either way, but if it still has some special needs to take care > of, updating it on wip-emacs will mean less work overall. Looks like someone already sent a patch to update it[1]. :) [1]: https://yhetil.org/guix-patches/byapr05mb4023349403c379ca3db8ab7dc5...@byapr05mb4023.namprd05.prod.outlook.com
Re: guix home: Call for Early Adopters
> Could you sign your rde channel? I am not at ease adding unsigned > channels since that's basically RCE into my system :-) It is not intended for use as a channel, at least yet, because `guix home` will not work without: export GUILE_LOAD_PATH=~/.config/guix/current/share/guile/site/3.0:$GUILE_LOAD_PATH export GUILE_LOAD_COMPILED_PATH=~/.config/guix/current/lib/guile/3.0/site-ccache:$GUILE_LOAD_COMPILED_PATH By "local checkout of the rde Git repository", I meant literal `git clone` to the local file system) Anyway, I signed the channel, the introduction is in the README. Maybe later I'll write a guide explaining how to use it as a channel. > Thanks!! You are very welcome (: and thank you for motivating me to clean up and improve things)
configure: error: A recent Guile-zlib could not be found; please install it.
Hi Guix, I'm at version 2e5ac371e799cb91354ffafaf8af2da37d11fa3f, and when doing this: $ guix environment -C guix --ad-hoc guile-zlib [env]$ ./configure --localstatedir=/var .. then configure ends with: checking whether Guile-zlib is available and recent enough... no configure: error: A recent Guile-zlib could not be found; please install it. How can I get a working development environment to work on Guix? Kind regards, Roel Janssen
