Re: [WIP Patch] Adding an FHS container to guix shell
John Kehayias writes: > First, I wanted to ask how people feel about such a feature. Obviously, one > use > is to run pre-built binaries (isolated!), but this is also handy for setting > up > development environments when not able (or wanting) to with Guix packages > only. > For example, using the rustup [0] scripts, pretty much anything JS, or just > following typical Readme instructions to try out something new before > packaging. > I won't debate the details here other than to say this topic comes up with > Guix > and I think it is yet another useful tool for guix shell and containers. Absolutely! I usually have to resort to Docker containers when building something that doesn't support GuixSD, so being able to work with them through Guix would be amazing. > What about other uses for this container, like providing an isolated > environment > to build and run software we can't do fully with bootstrap and sources (like > JS)? Could this become some stop-gap to allow people to work with these > ecosystems in a more controlled way within Guix? Or an alternative build > environment? Not entirely sure what this could mean, just thinking out loud. I think an interesting idea would be to allow packages to transparently run in the FHS container (i.e. a shim that turns 'x' into 'guix shell --fhs-container x -- x'). That way software incompatible with GuixSD in a way too difficult to patch could be still be packaged and used transparently, albeit with a significant performance cost. Even if packages in Guix proper don't use it, it could be useful for third-party channels or end-users to whip up packages. Thanks so much for this; I've been thinking about getting around to this feature for quite a while. signature.asc Description: PGP signature
Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic
Josselin Poiret writes: > Hello, > > Joshua Branson writes: > >> I would love for Guix to be a Multi Kernel package manager (I mean it >> works on the Hurd also, but I have never encountered a Hurd user in real >> life). My dream would be to port Guix to Plan 9 ;-) > > I don't think Guix runs on the Hurd in the same way that Guix runs on > Linux: the (gnu system hurd) tells me that the daemon is started with > --disable-chroot, which actually disables all isolation mechanisms. > There would need to be a significant effort to port the isolation > mechanisms to the Hurd. > > Seeing how the daemon is in general left alone since C++ is hard > compared to Scheme (and there's always the "but we could rewrite it in > Guile" excuse), combined with the difficulty of interfacing with > kernels, I'm not sure BSD support (or even Hurd support) will appear > anytime soon. > > Best, Someone was working on NetBSD support but ran into libc differences or something and didn't get much support.
Updating Packages
Hi there! I am new to software development, but I would like to contribute. I want to start by updating some rust packages to newer versions. So far I have just been making scheme files in a seperate directory and running "guix build -f $SCHEME_FILE". I am trying to follow the [guidlines in the manual](https://guix.gnu.org/manual/en/html_node/Contributing.html), but git is still new to me and I am a little confused how to make this all work. What should I do to get package builds to recognize the updates I make to dependencies?
Re: emacs-lilypond-mode should we?
On Mon, 2022-07-11 at 16:29 +0300, Efraim Flashner wrote: > On Mon, Jul 11, 2022 at 02:10:36AM -0500, jgart wrote: > > Hi, > > > > Should we package this mode separately from lilypond as emacs- > > lilypond-mode? > > > > https://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=tree;f=elisp;h=dc4d450a9f98433d04ac87057571ab58f98497c5;hb=HEAD > > > > all best, > > > > jgart > > I think it would be best to package it separately, and I'm pretty > sure > that's already what is suggested. The two packages I have installed > that > happen to have .el files installed also don't have them compiled to > .elc > files. Best to keep it separate so it's done with all the automation > of > the emacs-build-system. > I agree, soon I will use that one when I compose vocasynth songs using lilypond, since I use emacs and a lilypond addon for festival, which I have replaced with a more modern sinsy. Soon I will package that one too.
Re: Reminder: please add yourself to a team
On Wed, 2022-07-06 at 10:45 +0200, Ricardo Wurmus wrote: > lease take the time to add an entry for yourself to etc/teams.scm.in > in > the Guix repository. Here’s an example commit: > > > https://git.savannah.gnu.org/cgit/guix.git/commit/etc/teams.scm.in?id=47ed000d4df98e440a8a9a0788412b2f791b88b4 > > Thank you! I'll do that soon, since I plan to contribute more in the future.
Re: Test US mirror for bordeaux.guix.gnu.org and slow downloading of sub
Hi Chris, Thanks for setting up some more mirrors, here is what I just got (in a previous run the main Bordeaux server was a bit slower, more like 18 MB/s) on a wired connection that maxes out at about 320 Mbps. ❯ wget https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 --2022-07-12 13:27:43-- https://bordeaux.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 Resolving bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)... 185.233.100.56, 2a0c:e300::58 Connecting to bordeaux.guix.gnu.org (bordeaux.guix.gnu.org)|185.233.100.56|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 208615205 (199M) [text/plain] Saving to: ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.2’ 078vr3r8mn3yrwzwxw64hmcyshic 100%[===>] 198.95M 24.2MB/sin 8.3s 2022-07-12 13:27:52 (23.9 MB/s) - ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.2’ saved [208615205/208615205] ❯ wget https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 --2022-07-12 13:27:56-- https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 Resolving bordeaux-us-east-mirror.cbaines.net (bordeaux-us-east-mirror.cbaines.net)... 5.161.49.48 Connecting to bordeaux-us-east-mirror.cbaines.net (bordeaux-us-east-mirror.cbaines.net)|5.161.49.48|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 208615205 (199M) [text/plain] Saving to: ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.3’ 078vr3r8mn3yrwzwxw64hmcyshic 100%[===>] 198.95M 36.5MB/sin 5.4s 2022-07-12 13:28:01 (37.0 MB/s) - ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.3’ saved [208615205/208615205] A nice speedup! And for good measure, I tried the main substitute server: ❯ wget https://ci.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 --2022-07-12 13:28:50-- https://ci.guix.gnu.org/nar/lzip/078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0 Resolving ci.guix.gnu.org (ci.guix.gnu.org)... 141.80.181.40 Connecting to ci.guix.gnu.org (ci.guix.gnu.org)|141.80.181.40|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 208615205 (199M) [application/octet-stream] Saving to: ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.4’ 078vr3r8mn3yrwzwxw64hmcyshic 100%[===>] 198.95M 14.5MB/sin 24s 2022-07-12 13:29:15 (8.42 MB/s) - ‘078vr3r8mn3yrwzwxw64hmcyshic9p3q-stellarium-0.21.0.4’ saved [208615205/208615205] I guess I really should put Bordeaux (of any flavor) as what should be tried first, since either way it is much faster for me. And happy to help support these additional mirrors, just point me to where I can donate. John
Re: [WIP Patch] Adding an FHS container to guix shell
On 2022-07-12, John Kehayias wrote: > Apologies for the long email, so let me start with the punchline: > attached is a diff which adds an '--fhs-container' (or -F) option to > guix shell/environment to set up an FHS-like container. This includes > the usual /lib directory and a glibc which loads (a generated in the > container) /etc/ld.so.cache. This should allow running most things > that expect a more "typical" Linux environment. Give it a try! Nice! > 1. Set up directories like /lib. This is easy enough and can be done > currently, like in roptat's response here [1] by building the profile > first to know where to link to. Note that it is easier to do it within > the environment code since we have access to the profile even if it is > being built for the first time. There are some wrinkles with linking > something like /bin since we currently add a link for sh; see the > comments in my diff. > > Right now I did not handle a multi-arch setup, though that shouldn't > be too difficult. This would probably require an option to build > either all or specified packages for an additional arch, like 32bit in > a 64bit system, and make the libraries available (/lib32 or > something). Though may run into a union-build bug [2]? This might be splitting hairs, but that sounds like a bi-arch setup e.g. "/lib and /lib32" vs. a multi-arch setup "/lib, /lib/aarch64-linux-gnu/ and /lib/i386-linux-gnu" https://wiki.debian.org/Multiarch Not sure how many extra hoops you'd need to jump through to make either work well. live well, vagrant signature.asc Description: PGP signature
[WIP Patch] Adding an FHS container to guix shell
Hi Guixers, Apologies for the long email, so let me start with the punchline: attached is a diff which adds an '--fhs-container' (or -F) option to guix shell/environment to set up an FHS-like container. This includes the usual /lib directory and a glibc which loads (a generated in the container) /etc/ld.so.cache. This should allow running most things that expect a more "typical" Linux environment. Give it a try! First, I wanted to ask how people feel about such a feature. Obviously, one use is to run pre-built binaries (isolated!), but this is also handy for setting up development environments when not able (or wanting) to with Guix packages only. For example, using the rustup [0] scripts, pretty much anything JS, or just following typical Readme instructions to try out something new before packaging. I won't debate the details here other than to say this topic comes up with Guix and I think it is yet another useful tool for guix shell and containers. Nix, which I know almost nothing about, does have some FHS container/environment options as well. Next, some technical points about implementation, which I hope will be informed by the first question and what we want from this tool. There are two main things needed for the FHS-container: 1. Set up directories like /lib. This is easy enough and can be done currently, like in roptat's response here [1] by building the profile first to know where to link to. Note that it is easier to do it within the environment code since we have access to the profile even if it is being built for the first time. There are some wrinkles with linking something like /bin since we currently add a link for sh; see the comments in my diff. Right now I did not handle a multi-arch setup, though that shouldn't be too difficult. This would probably require an option to build either all or specified packages for an additional arch, like 32bit in a 64bit system, and make the libraries available (/lib32 or something). Though may run into a union-build bug [2]? 2. Typically binaries will expect the ld loader to use /etc/ld.so.cache for finding libraries. So, I made a glibc package that removes our dl cache patch to restore this behavior. It seems enough to add this as a default package to the container, though I commented out an option to automatically graft everything with this glibc. Both worked for me, but grafting didn't seem necessary. The second step is to generate the ld cache, which is done with a simple startup script in the container, after creating a temporary ld.so.conf (our ldconfig doesn't use the usual default directories?). I'm sure I found the hackiest way to do this, but it works :) Again, this could be possible without modifying guix containers, but this is easier. (For example, you can see work done by myself and others at a certain non-free channel to do exactly this.) Some questions going forward, besides overall cleanup and tweaking of the code (which I provided comments in for some details, please see there). It might be nice to be able to extend containers more easily with setup scripts, though again this can be done by making some Guile scripts to wrap a container and making a package around that (e.g. from the non-free channel). What kind of extensions would be useful to expose? I think I saw some talk on IRC recently about how to manage env variables when using guix shell. Perhaps an extended manifest format for shell? Relatedly and more generally, perhaps it would be good to have somewhere (cookbook?) some recipes of useful guix shell container incantations. Sharing what you need from the host for graphical programs can be a little tricky to figure out. We have the --network option, maybe others would be useful? Or some base package lists for development: just like we have our various -build-system's, a package list with typical library sets might be a nice convenience. What about other uses for this container, like providing an isolated environment to build and run software we can't do fully with bootstrap and sources (like JS)? Could this become some stop-gap to allow people to work with these ecosystems in a more controlled way within Guix? Or an alternative build environment? Not entirely sure what this could mean, just thinking out loud. Okay, let me end by bringing it back to what we can currently do with this code I whipped up (and many thanks to [1] and efforts in a non-free channel for doing the work that I drew upon). I don't know any Rust, so I figured trying out what I read on the internet about "just use rustup" and follow a readme is a good test case. So I did that and compiled something that looked hefty, a graphical widget system [3]. Here's the command I used and everything just worked: the rustup script ran and downloaded the rust tools, the cargo build command worked to build everything. I couldn't run the actual widgets as I am within a pure shell for my guix checkout
Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic
Akib Azmain Turja writes: > Joshua Branson writes: > I did not write the below sentence. I was quoting the previous discussion found on guix devel. >> (I mean it >> works on the Hurd also, but I have never encountered a Hurd user in real >> life) > > Really? I found tons of bugs in the Hurd port, causing it to not even > boot properly. > I would not know how well GNU/Hurd Guix System runs. I have never used it. I have played with hurd-service. That's pretty cool. But I could never really get it to work...I am currently playing with the pre-packaged qemu debian image.
Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic
Josselin Poiret writes: > Hello, > > Joshua Branson writes: > To be clear, I did not write the next paragraph. I was quoting the previous discussion. :) >> I would love for Guix to be a Multi Kernel package manager (I mean it >> works on the Hurd also, but I have never encountered a Hurd user in real >> life). My dream would be to port Guix to Plan 9 ;-) > > I don't think Guix runs on the Hurd in the same way that Guix runs on > Linux: the (gnu system hurd) tells me that the daemon is started with > --disable-chroot, which actually disables all isolation mechanisms. > There would need to be a significant effort to port the isolation > mechanisms to the Hurd. > > Seeing how the daemon is in general left alone since C++ is hard > compared to Scheme (and there's always the "but we could rewrite it in > Guile" excuse), combined with the difficulty of interfacing with > kernels, I'm not sure BSD support (or even Hurd support) will appear > anytime soon. > To be fair, Guix does support the Hurd. You can run the guix package manager on the Hurd. Guix System does not yet support the Hurd. Though I believe I talked with a user in the guix community that was running GNU Guix System/Hurd, but the issue he ran into was that he has no wifi support. Then something broke in GNU Guix System/Hurd and he no longer run GNU Guix System/Hurd on real hardware. > > Best,
Ten Years of Guix: preliminary program available!
Hello! We’re excited to announce a preliminary program for the Ten Years of Guix event that will take place in Paris, France, Sept. 16th–18th! https://10years.guix.gnu.org/program/ On Friday, scientists and practitioners will talk about how they address computational reproducibility in their domain, using Guix and using other tools, including Nix and Maneage. We’ll also see how Software Heritage helps bridge the gap, both at a technical level and for software citation and referencing, and we’ll learn about OCaml bootstrapping and a vision for RISC-V and Guix. The community-oriented program for Saturday and Sunday is work in progress and there’s already a good set of topics brought to the table, whether you want to learn about Guix, to get started contributing, to discuss ways to improve it, or to dive into technical matters. Please email guix-birthday-ev...@gnu.org if you’d like to facilitate a brainstorming session or a hacking session, or if you’d like to share about your favorite use case, Guix subsystem, and whatnot! Make sure to register so you get your share of the birthday cake! :-) Ludovic, Simon, and Tanguy. signature.asc Description: PGP signature
[PATCH] gnu: tcc: Update to a83b28568596afd8792fd58d1a5bd157fc6b6634
Hi,
With this patch the tcc build issue is fixed, the downside is that it's
set to an specific commit and not a release.
It also separates tcc-boot from the tcc source, so it does not interfere
in the bootstrapping process (the patch moves the source of tcc to git
and that produces a circular dependency).
I hope this is useful.
Best,
EkaitzFrom ed05cfb9356fb5b07be48c54b9ec33eab672de61 Mon Sep 17 00:00:00 2001
From: Ekaitz Zarraga
Date: Tue, 12 Jul 2022 11:05:15 +0200
Subject: [PATCH] gnu: tcc: Update to a83b28568596afd8792fd58d1a5bd157fc6b6634
* gnu/packages/c.scm (tcc): Update to a83b28568596afd8792fd58d1a5bd157fc6b6634
* gnu/packages/commencement.scm (tcc-boot)[source]: Remove dependency on
tcc.
---
gnu/packages/c.scm| 110 ++
gnu/packages/commencement.scm | 9 ++-
2 files changed, 66 insertions(+), 53 deletions(-)
diff --git a/gnu/packages/c.scm b/gnu/packages/c.scm
index b1f68c706b..c5afc2fc1c 100644
--- a/gnu/packages/c.scm
+++ b/gnu/packages/c.scm
@@ -15,6 +15,7 @@
;;; Copyright © 2021 Foo Chuan Wei
;;; Copyright © 2022 (unmatched parenthesis
;;; Copyright © 2022 Artyom V. Poptsov
+;;; Copyright © 2022 Ekaitz Zarraga
;;;
;;; This file is part of GNU Guix.
;;;
@@ -112,58 +113,63 @@ (define-public cproc
(license license:expat
(define-public tcc
- (package
-(name "tcc") ;aka. "tinycc"
-(version "0.9.27")
-(source (origin
- (method url-fetch)
- (uri (string-append "mirror://savannah/tinycc/tcc-"
- version ".tar.bz2"))
- (sha256
- (base32
-"177bdhwzrnqgyrdv1dwvpd04fcxj68s5pm1dzwny6359ziway8yy"
-(build-system gnu-build-system)
-(native-inputs (list perl texinfo))
-(arguments
- `(#:configure-flags (list (string-append "--elfinterp="
- (assoc-ref %build-inputs "libc")
- ,(glibc-dynamic-linker))
- (string-append "--crtprefix="
- (assoc-ref %build-inputs "libc")
- "/lib")
- (string-append "--sysincludepaths="
- (assoc-ref %build-inputs "libc")
- "/include:"
- (assoc-ref %build-inputs
- "kernel-headers")
- "/include:{B}/include")
- (string-append "--libpaths="
- (assoc-ref %build-inputs "libc")
- "/lib")
- ,@(if (string-prefix? "armhf-linux"
- (or (%current-target-system)
- (%current-system)))
- `("--triplet=arm-linux-gnueabihf")
- '()))
- #:test-target "test"))
-(native-search-paths
- (list (search-path-specification
-(variable "CPATH")
-(files '("include")))
- (search-path-specification
-(variable "LIBRARY_PATH")
-(files '("lib" "lib64")
-;; Fails to build on MIPS: "Unsupported CPU"
-(supported-systems (delete "mips64el-linux" %supported-systems))
-(synopsis "Tiny and fast C compiler")
-(description
- "TCC, also referred to as \"TinyCC\", is a small and fast C compiler
-written in C. It supports ANSI C with GNU and extensions and most of the C99
-standard.")
-(home-page "http://www.tinycc.org/;)
-;; An attempt to re-licence tcc under the Expat licence is underway but not
-;; (if ever) complete. See the RELICENSING file for more information.
-(license license:lgpl2.1+)))
+ (let ((revision "1")
+(commit "a83b28568596afd8792fd58d1a5bd157fc6b6634"))
+(package
+ (name "tcc") ;aka. "tinycc"
+ (version (git-version "0.9.27" revision commit))
+ (source
+(origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "git://repo.or.cz/tinycc.git")
+ (commit commit)))
+ (file-name (git-file-name name version))
+ (sha256
+(base32
+ "01znw86fg73x3k0clafica4b6glbhz69p588kvp766i0zgvs68dh"
+ (build-system gnu-build-system)
+ (native-inputs (list perl texinfo))
+ (arguments
+`(#:configure-flags (list (string-append "--elfinterp="
+ (assoc-ref %build-inputs "libc")
+ ,(glibc-dynamic-linker))
+
Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic
Hello, Joshua Branson writes: > I would love for Guix to be a Multi Kernel package manager (I mean it > works on the Hurd also, but I have never encountered a Hurd user in real > life). My dream would be to port Guix to Plan 9 ;-) I don't think Guix runs on the Hurd in the same way that Guix runs on Linux: the (gnu system hurd) tells me that the daemon is started with --disable-chroot, which actually disables all isolation mechanisms. There would need to be a significant effort to port the isolation mechanisms to the Hurd. Seeing how the daemon is in general left alone since C++ is hard compared to Scheme (and there's always the "but we could rewrite it in Guile" excuse), combined with the difficulty of interfacing with kernels, I'm not sure BSD support (or even Hurd support) will appear anytime soon. Best, -- Josselin Poiret
