Re: Dissecting Guix -- blog post series
On Fri Dec 9, 2022 at 7:31 AM GMT, 宋文武 wrote: > I think it's missing what "build-derivations" do, or "Part 0: Store". Hmm, do you mean adding an example of building a derivation in Scheme with ``build-derivations''? I'll definitiely add that :) -- ( signature.asc Description: PGP signature
Re: Dissecting Guix -- blog post series
"(" writes:
> Heya!
>
> Some of you may have seen on IRC that I've been writing a post for the Guix
> blog that I hope will form the first part of a series. This series aims to
> dissect the internals of Guix, from bottom to top. Perhaps they could go in
> the cookbook once the series is done? My aim is to write the following posts
> (complete with cheesy titles :P), hopefully one per week:
>
> * Dissecting Guix, Part 1: Derivations
>
> Discusses derivations, the bottom layer of the Guix compilation tower, and
> dissects some example derivations.
>
> A draft of this post may be found below. Please feel free to critique! :)
Great, thank you!
I think it's missing what "build-derivations" do, or "Part 0: Store".
Re: Winding down of Fosshost
Hi, On Sun, 04 Dec 2022 at 11:35, indieterminacy wrote: > Given Fosshost's place in the ecosystem: is this something which > requires mitigating at the Guix end? On Sun, 04 Dec 2022 at 13:16, Tobias Geerinckx-Rice wrote: > - They hosted a Big Blue Button instance[0] only for the duration > of our COVID Days[1]. [...] > [0]: (dead link) https://guixbbb.fosshost.org Last time we used this BBB instance was for Outreachy back on November 2020 / April 2021. After, we used other BBB instances. They cancelled the BBB instance [0] some time ago; probably mid-2021 or late 2021. IIRC, they changed their policy and somehow asked us some counterparts, so we moved. Cheers, simon
Re: Emacs proof-general
Hi, On Tue, 06 Dec 2022 at 10:38, pinoaffe wrote: > I don't know why this file is renamed, The explanations are here: :-) https://issues.guix.gnu.org/51755#5 or here: :-) https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/coq.scm#n217 > Does anyone know what's going on, and how this can be resolved? (or is > this just a case of user-error?) Well, it works for me. ;-) This, guix shell -C emacs proof-general coq -- emacs -q foo.v correctly starts Proof-General. Then, depending on what is inside the file foo.v, say: Definition x := 42. Print x. so I start Coq pressing ’C-c C-n’. Otherwise, I have my Emacs packages under the profile ~/.config/guix/profiles/emacs (containing the packages emacs and proof-general) and another profile ~/.confi/guix/profiles/compiler (containing the package coq). And I do not have any specific Coq or Proof-General configuration in ~/.config/emacs. Could you be more specific about what is not working for you? Cheers, simon
Experimenting with reduced gcc-lib
Hi Guix!
I had a look at gcc to try and reduce its footprint. I figured gcc-lib
contained shared and static libraries as well as support libraries for
gdb, many headers and compiler runtime, that are taking a lot of space
when they are not needed at runtime. Reducing its 33.4 MiB would help
create smaller guix packs, have smaller system and profile closures,
etc.
I figured gcc has a --with-slibdir option that is advertised as being
useful to specify a directory for the shared libraries. I decided to
use it and create a new output for the gcc package, shared-lib. In
fact, this option only installs libgcc_s.so in that output, and that's
the only thing required by most packages.
Attached is a patch that divides gcc-lib into gcc-static-lib and
gcc-shared-lib (not very good names, gcc-static-lib contains shared
libs too).
Before the patch we get:
guix size perl
total: 147.7 MiB
After the patch:
./pre-inst-env guix size perl
total: 114.5 MiB
This is because before the patch, gcc-lib is 33.4 MiB, and after the
patch gcc-shared-lib is only 0.2 MiB.
I don't want to push that patch as is, because libstdc++.so is still in
the gcc-static-lib output and will bring all the useless stuff with it.
C++ programs will bring back the remaining 33.2 MiB.
Another possible target is glibc, since the only useful bits in there
are libc.so and ld-linux.so (I think?). This could reduce the closure
of our packs by another ~40 MiB (I think our systems would still need
most of the content of this package).
>From bff8567b0770455397d44f1ed304a67681b472c9 Mon Sep 17 00:00:00 2001
From: Julien Lepiller
Date: Thu, 8 Dec 2022 22:29:01 +0100
Subject: [PATCH] gnu: gcc: Separate lib output.
* gnu/packages/gcc.scm (gcc-4.7): Replace `lib' output with `static-lib'
and `shared-lib'.
* gnu/packages/commencement.scm (gcc-boot0): Update accordingly.
---
gnu/packages/commencement.scm | 6 +++---
gnu/packages/gcc.scm | 39 +--
gnu/tests/mail.trs| 0
3 files changed, 31 insertions(+), 14 deletions(-)
create mode 100644 gnu/tests/mail.trs
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index b4566b41cc..f3fce1750f 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -2853,7 +2853,7 @@ (define gcc-boot0
(lambda _ #t
(add-after 'install 'symlink-libgcc_eh
(lambda* (#:key outputs #:allow-other-keys)
- (let ((out (assoc-ref outputs "lib")))
+ (let ((out (assoc-ref outputs "static-lib")))
;; Glibc wants to link against libgcc_eh, so provide
;; it.
(with-directory-excursion
@@ -3417,7 +3417,7 @@ (define glibc-final
;; if 'allowed-references' were per-output.
(arguments
`(#:allowed-references
- (,(gexp-input gcc-boot0 "lib")
+ (,(gexp-input gcc-boot0 "shared-lib")
,(kernel-headers-boot0)
,static-bash-for-glibc
,@(if (hurd-system?)
@@ -3523,7 +3523,7 @@ (define gcc-final
`(#:guile ,%bootstrap-guile
#:implicit-inputs? #f
- #:allowed-references ("out" "lib" ,zlib-final
+ #:allowed-references ("out" "shared-lib" "static-lib" ,zlib-final
,glibc-final ,static-bash-for-glibc)
;; Things like libasan.so and libstdc++.so NEED ld.so for some
diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index bb154cac62..010c6102a0 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -106,8 +106,16 @@ (define-public gcc-4.7
'("CC" "CXX" "LD" "AR" "NM" "OBJDUMP" "RANLIB" "STRIP")
'("gcc" "g++" "ld" "ar" "nm" "objdump" "ranlib" "strip"))
'()
+ (static-libdir
+ (let ((base '(or (assoc-ref outputs "static-lib")
+ (assoc-ref outputs "out"
+(lambda ()
+ ;; Return the directory that contains lib/libgcc_s.so et al.
+ (if (%current-target-system)
+ `(string-append ,base "/" ,(%current-target-system))
+ base
(libdir
- (let ((base '(or (assoc-ref outputs "lib")
+ (let ((base '(or (assoc-ref outputs "shared-lib")
(assoc-ref outputs "out"
(lambda ()
;; Return the directory that contains lib/libgcc_s.so et al.
@@ -138,6 +146,12 @@ (define-public gcc-4.7
,(string-append "--with-gxx-include-dir="
(assoc-ref %outputs "out")
"/include/c++")
+ ,(string-append "--libdir="
+ (assoc-ref %outputs "static-lib")
+ "/lib")
+ ,(string-append "--with-slibdir="
+ (assoc-ref
Dissecting Guix -- blog post series
Heya! Some of you may have seen on IRC that I've been writing a post for the Guix blog that I hope will form the first part of a series. This series aims to dissect the internals of Guix, from bottom to top. Perhaps they could go in the cookbook once the series is done? My aim is to write the following posts (complete with cheesy titles :P), hopefully one per week: * Dissecting Guix, Part 1: Derivations Discusses derivations, the bottom layer of the Guix compilation tower, and dissects some example derivations. A draft of this post may be found below. Please feel free to critique! :) * Dissecting Guix, Part 2: The Humble G-Expression Talks about g-expressions and why they're necessary, explains file-like objects, and provides demonstrations of each kind of file-like. * Dissecting Guix, Part 3: Packages A walkthrough for package creation. * Dissecting Guix, Part 4: Monads ``mlet'', ``>>='', ``define-monad'', ``return'', and all that. * Dissecting Guix, Part 5: Profiles and Search Paths Explores profiles and search paths. * Dissecting Guix, Part 6: Goings-On in the Build Container Explains build systems, examines a build script, and talks about what exactly happens when a package is built. Also demonstrates some of the ``(guix build utils)'' APIs. * Dissecting Guix, Part 7: Record Types Demonstrates the ``(guix records)'' API in all its glory. * Dissecting Guix, Part 8: Substitutes and Grafts Discusses substitutes, and that persistent thorn in our sides, grafting. * Dissecting Guix, Part 9: Cross-Compilation Building packages on architecture X for architecture Y, and how that all works. * Dissecting Guix, Part 10: Services Walks you through the process of creating a service, and thouroughly explains system configuration. * Dissecting Guix, Part 11: Home Services Similar to Part 9, except it's about ``guix home'', of course. * Dissecting Guix, Part 12: Writing a Subcommand Guides you through the process of adding a new command to Guix with the extensions feature, demonstrating several utility APIs in the process. * Dissecting Guix, Part 13: Lending a Hand How to edit the Guix source code and submit patches to be reviewed by the lovely Guix community! -- ( title: Dissecting Guix, Part 1: Derivations and Derivation date: TBC author: ( tags: Dissecting Guix, Functional package management, Programming interfaces, Scheme API --- To a new user, Guix's functional architecture can seem quite alien, and possibly offputting. With a combination of extensive `#guix`-querying, determined manual-reading, and plenty of source-perusing, they may eventually figure out how everything fits together by themselves, but this can be frustrating and often takes a fairly long time. However, once you peel back the layers, the "Nix way" is actually rather elegant, if perhaps not as simple as the mutable, imperative style implemented by the likes of [`dpkg`](https://wiki.debian.org/dpkg) and, [`pacman`](https://wiki.archlinux.org/title/pacman). This series of blog posts will cover basic Guix concepts, taking a "ground-up" approach by dealing with lower-level concepts first, and hopefully make those months of information-gathering unnecessary. Before we dig in to Guix-specific concepts, we'll need to learn about one inherited from [Nix](https://nixos.org), the original functional package manager and the inspiration for Guix; the idea of a _derivation_ and its corresponding _store items_. These concepts were originally described by Eelco Dolstra, the author of Nix, in their [PhD thesis](https://edolstra.github.io/pubs/phd-thesis.pdf); see _§ 2.1 The Nix store_ and _§ 2.4 Store Derivations_. # Store Items As you almost certainly know, everything that Guix builds is stored in the _store_, which is almost always the `/gnu/store` directory. It's the job of the [`guix-daemon`](https://guix.gnu.org/manual/en/html_node/Invoking-guix_002ddaemon.html) to manage the store and build things. If you run [`guix build PKG`](https://guix.gnu.org/manual/en/html_node/Invoking-guix-build.html), `PKG` will be built or downloaded from a substitute server if available, and a path to an item in the store will be displayed. ``` $ guix build irssi /gnu/store/v5pd69j3hjs1fck4b5p9hd91wc8yf5qx-irssi-1.4.3 ``` This item contains the final result of building [`irssi`](https://irssi.org). Let's peek inside: ``` $ ls $(guix build irssi) bin/ etc/ include/ lib/ share/ $ ls $(guix build irssi)/bin irssi* ``` `irssi` is quite a simple package. What about a more complex one, like [`glib`](https://docs.gtk.org/glib)? ``` $ guix build glib /gnu/store/bx8qq76idlmjrlqf1faslsq6zjc6f426-glib-2.73.3-bin /gnu/store/j65bhqwr7qq7l77nj0ahmk1f1ilnjr3a-glib-2.73.3-debug /gnu/store/3pn4ll6qakgfvfpc4mw89qrrbsgj3jf3-glib-2.73.3-doc /gnu/store/dvsk6x7d26nmwsqhnzws4iirb6dhhr1d-glib-2.73.3 /gnu/store/4c8ycz501n2d0xdi4blahvnbjhd5hpa8-glib-2.73.3-static ``` `glib` produces five `/gnu/store` items, because it's possible for a package
Release progress, week 9
Hello Guix! Release progress: week 9. Here are the main improvements that landed on ‘version-1.4.0’ since RC1: • System test failures and ARM image build failures fixed: https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00063.html • Missing file added to Makefile.am: https://lists.gnu.org/archive/html/guix-devel/2022-12/msg00037.html • e2fsprogs now in the system profile of the installer • Julia build failures fixed: https://issues.guix.gnu.org/59836 • backported the ‘match-record’ improvements to avoid ABI incompatibility compared to ‘master’: https://issues.guix.gnu.org/59864 That’s a total of 24 commits. Bugs that need attention or even fixing: :-) • “Retrying a failed install fails” https://issues.guix.gnu.org/59784 • “Installer fails to identify installation device on Ventoy-made images” https://issues.guix.gnu.org/59823 • “‘gui-installed-desktop-os-encrypted’ test intermittent failures” https://issues.guix.gnu.org/59884 • “install.sh script should authorize bordeaux” (almost done) https://issues.guix.gnu.org/59781 As explained before, I can push an RC2 by Sunday, which is real soon. The above bugs are not critical but it’d be nice to make progress on them before RC2. Consider giving a hand! Ludo’.
Re: Go path issue
Heya, On Wed Dec 7, 2022 at 11:09 PM GMT, Christopher Howard wrote: > This almost works, but the build fails because of a path issue: > > ``` > starting phase `build' > src/golang.org/x/net/idna/idna10.0.0.go:25:2: cannot find package > "golang.org/x/text/secure/bidirule" in any of: > > /gnu/store/d06665qgp3zqp05fr0q1sdbfnpvxywsc-go-1.17.11/lib/go/src/golang.org/x/text/secure/bidirule > (from $GOROOT) > > /tmp/guix-build-go-git-sr-ht-adnano-go-gemini-0.2.3.drv-0/src/golang.org/x/text/secure/bidirule > (from $GOPATH) > src/golang.org/x/net/idna/idna10.0.0.go:26:2: cannot find package > "golang.org/x/text/unicode/bidi" in any of: > > /gnu/store/d06665qgp3zqp05fr0q1sdbfnpvxywsc-go-1.17.11/lib/go/src/golang.org/x/text/unicode/bidi > (from $GOROOT) > > /tmp/guix-build-go-git-sr-ht-adnano-go-gemini-0.2.3.drv-0/src/golang.org/x/text/unicode/bidi > (from $GOPATH) > src/golang.org/x/net/idna/idna10.0.0.go:27:2: cannot find package > "golang.org/x/text/unicode/norm" in any of: > > /gnu/store/d06665qgp3zqp05fr0q1sdbfnpvxywsc-go-1.17.11/lib/go/src/golang.org/x/text/unicode/norm > (from $GOROOT) > > /tmp/guix-build-go-git-sr-ht-adnano-go-gemini-0.2.3.drv-0/src/golang.org/x/text/unicode/norm > (from $GOPATH) > Building 'git.sr.ht/~adnano/go-gemini' failed. > ``` Try adding ``go-golang-org-x-text'' to propagated-inputs. -- ( signature.asc Description: PGP signature
Emacs proof-general
Hi folks, the proof-general package seems to be broken - I cannot load it from emacs, even when it is properly installed and in the path. I've tried requiring proof-general, proof-general-autoloads, and loading it using use-package. I think the issue is that proof-general.el is renamed to proof-general-autoloads.el in the guix package definition, while the file still ends in `(provide 'proof-general)`. I don't know why this file is renamed, but I see two possible resolutions: - either don't rename proof-general.el, or - rename it, edit `(provide 'proof-general)`, and optionally add a new file proof-general.el so that it can be loaded in the conventional manner. I've shied away from posting a patch making either of these changes since I don't understand the reason for the renaming. Does anyone know what's going on, and how this can be resolved? (or is this just a case of user-error?) Kind regards, pinoaffe
Go path issue
Hello, I was trying to package some go software, using a definition based on
what I got from the importer. This is my working definition:
```
(define-public go-git-sr-ht-adnano-go-gemini
(package
(name "go-git-sr-ht-adnano-go-gemini")
(version "0.2.3")
(source (origin
(method git-fetch)
(uri (git-reference
(url "https://git.sr.ht/~adnano/go-gemini;)
(commit (string-append "v" version
(file-name (git-file-name name version))
(sha256
(base32
"0mv4x4cfwyhh77wfb3r221bhr84x4nmjpgysnvvjgmbnnafsgfns"
(build-system go-build-system)
(arguments
'(#:import-path "git.sr.ht/~adnano/go-gemini"))
(propagated-inputs `(("go-golang-org-x-net" ,go-golang-org-x-net)))
(home-page "https://git.sr.ht/~adnano/go-gemini;)
(synopsis "go-gemini")
(description
"Package gemini provides Gemini client and server implementations.")
(license license:expat)))
```
This almost works, but the build fails because of a path issue:
```
starting phase `build'
src/golang.org/x/net/idna/idna10.0.0.go:25:2: cannot find package
"golang.org/x/text/secure/bidirule" in any of:
/gnu/store/d06665qgp3zqp05fr0q1sdbfnpvxywsc-go-1.17.11/lib/go/src/golang.org/x/text/secure/bidirule
(from $GOROOT)
/tmp/guix-build-go-git-sr-ht-adnano-go-gemini-0.2.3.drv-0/src/golang.org/x/text/secure/bidirule
(from $GOPATH)
src/golang.org/x/net/idna/idna10.0.0.go:26:2: cannot find package
"golang.org/x/text/unicode/bidi" in any of:
/gnu/store/d06665qgp3zqp05fr0q1sdbfnpvxywsc-go-1.17.11/lib/go/src/golang.org/x/text/unicode/bidi
(from $GOROOT)
/tmp/guix-build-go-git-sr-ht-adnano-go-gemini-0.2.3.drv-0/src/golang.org/x/text/unicode/bidi
(from $GOPATH)
src/golang.org/x/net/idna/idna10.0.0.go:27:2: cannot find package
"golang.org/x/text/unicode/norm" in any of:
/gnu/store/d06665qgp3zqp05fr0q1sdbfnpvxywsc-go-1.17.11/lib/go/src/golang.org/x/text/unicode/norm
(from $GOROOT)
/tmp/guix-build-go-git-sr-ht-adnano-go-gemini-0.2.3.drv-0/src/golang.org/x/text/unicode/norm
(from $GOPATH)
Building 'git.sr.ht/~adnano/go-gemini' failed.
```
I looked and saw that the the files are available, but from the directory
/gnu/store/...-go-1.17.11/lib/go/src/vendor/golang.org/x/text/...
So, build system is looking for them at lib/go/src/golang.org but they are
installed at lib/gosrc/***VENDOR***/golang.org.
I don't know much about Go or about how the paths are handled by our Go build
system, so I was hoping somebody here could help me resolve this issue. I'm not
a Go programmer but I was hoping to package another piece of software that
depends on this one.
--
Christopher Howard
gemini://gem.librehacker.com
http://gem.librehacker.com
בראשית ברא אלהים את השמים ואת הארץ
Re: Guile-Gcrypt 0.4.0 released
Jonathan Brielmaier skribis: > On 03.12.22 23:45, Vagrant Cascadian wrote: >> On 2022-12-01, Ludovic Courtès wrote: >>> I’m pleased to announce Guile-Gcrypt version 0.4.0: >>> >>>git clone https://notabug.org/cwebber/guile-gcrypt.git >>>cd guile-gcrypt >>>git checkout v0.4.0 # or 425554d4327eeeb60c39e3d4a1b7bc5e36b63953 >>>git tag -v v0.4.0 >> >> FWIW, I updated guile-gcrypt to 0.4.0 in Debian experimental and updated >> to guix 1.4.0rc1 in Debian experimental using guile-gcrypt 0.4.0, and it >> seemed to go fine so far... > > Those being on openSUSE Tumbleweed can enjoy 0.4.0 as well: > https://build.opensuse.org/request/show/1039343 > > Guix is also built against the updated version, no problems so far :) Awesome, thank you! Ludo’.
Re: GMP GCC C++ Hurd cross-build failure on core-updates
Hi, zamfofex skribis: > configure:10478: checking C++ compiler i586-pc-gnu-g++ -m32 -O2 -pedantic > -fomit-frame-pointer > Test compile: > configure:10492: i586-pc-gnu-g++ -m32 -O2 -pedantic -fomit-frame-pointer > conftest.cc >&5 > i586-pc-gnu-ld: > /gnu/store/g3p2j9pb7skjdwrgk4zxlbxhxq6zl5rh-gcc-cross-i586-pc-gnu-11.3.0-lib/lib/gcc/i586-pc-gnu/11.3.0/../../../../i586-pc-gnu/lib/libstdc++.so: > undefined reference to `pthread_rwlock_unlock' > i586-pc-gnu-ld: > /gnu/store/g3p2j9pb7skjdwrgk4zxlbxhxq6zl5rh-gcc-cross-i586-pc-gnu-11.3.0-lib/lib/gcc/i586-pc-gnu/11.3.0/../../../../i586-pc-gnu/lib/libstdc++.so: > undefined reference to `pthread_create' It looks as if libstdc++.so lacked libpthread.so from its dependencies (DT_NEEDED). What does this say: objdump -x \ /gnu/store/g3p2j9pb7skjdwrgk4zxlbxhxq6zl5rh-gcc-cross-i586-pc-gnu-11.3.0-lib/lib/gcc/i586-pc-gnu/11.3.0/../../../../i586-pc-gnu/lib/libstdc++.so \ | grep NEEDED ? Thanks, Ludo’.
Re: File search
Hi,
"(" skribis:
> Someone on IRC suggested that we use GraphQL to allow us to request
> that a substitute server search for files in a database constructed
> using all the packages that have been built.
>
> I suggest something like this:
>
> # on the client
> when [built a package derivation]
> [add files to local database]
>
> when [user ran guix find]
> if [send find request to substitute server] didn't work
> [search through local database]
> [display result]
Upthread I started the discussion of criteria for file search:
https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00354.html
Among them, there’s privacy and support for off-line operation. To meet
these criteria, I think we should refrain from sending individual file
search requests to the server, and instead have the option of fetching a
full database.
Ludo’.
Re: Packaging big generated data files?
Denis 'GNUtoo' Carikli writes: > [[PGP Signed Part:Undecided]] > Hi, > > Is there any policies or past decisions of the Guix project on > packaging big generated data files? > > I've added packages for software like kiwix-tools and navit that both > work offline but that also need data files to be useful. > > Navit is a (car) navigation software that need maps. The maps can be > generated from OpenStreetMap dumps with a tool available in Navit > source code (maptool)[1] which is not packaged yet. Binary map files can > also be downloaded directly from various sources. > > Right now the biggest file possible for such maps is about 47 GiB > (for the whole planet). > > As for kiwix-tools, it can serve offline versions of websites like > Wikipedia, and there too it needs files to work. The biggest file seems > to be the complete version of English Wikipedia with scaled down > pictures[2] and it takes about 89 GiB. I didn't look yet how these files > were generated but I guess that they somehow can be generated from > Wikipedia dumps. > > Packaging the binary files (without generating them) can be useful as > it simplifies a lot the maintenance as one can just update the package > version and checksum to update these. It also enables to keep the > information (download URL, checksum, license) in one place and it > enables easy reuse by Guix services and/or configuration files. > > If these files were generated in packages, it would also enable to > tweak the data, for instance by adding height data in navit maps. As > for kiwix compatible files, it would probably enable to decide when to > make the snapshots or enable to package additional wikis > (like the Libreplanet Wiki) or websites. > > The issue here is probably the size of the generated files: they are > huge, so if they are packaged, they will most likely take significant > resources in the Guix infrastructure. > > So what would be the way to go here? Would Guix accept patches to add > packages for these files in Guix proper? > > If so, does it needs to be done like with the ZFS (kernel module) > package where "#:substitutable? #f" is used to avoid redistributing > package builds? Or are other ways better for such use cases? > > Note that so far I've only packaged locally only kiwix compatible files > for various wikis by just downloading already prepared files, so I > didn't look yet into navit maps or into generating all these files, so > I might miss some details about generating them. > > References: > --- > [1]https://navit.readthedocs.io/en/latest/maps.html#processing-osm-maps-yourself > [2]https://mirror.download.kiwix.org/zim/wikipedia/wikipedia_en_all_maxi_2022-05.zim > > Denis. > > [[End of PGP Signed Part]] Could ZIM files be downloaded over bittorrent as fixed output derivations? They can be pretty huge. Also if the system started seeding them as well, that would be pretty cool.
Re: Python Packaging Policy
Hi, On Wed, 07 Dec 2022 at 17:22, jgart wrote: > What is our policy then for updating Python packages in our Python > library collection? The policy is to not break the other packages; guix refresh -l python-. > How are we assuring that all Python libraries are working well together? How? With a lot of love. :-) Cheers, simon
Re: Winding down of Fosshost
Tobias Geerinckx-Rice writes: > indieterminacy 写道： >> Given Fosshost's place in the ecosystem: is this something which >> requires mitigating at the Guix end? > > I'm aware of two dealings with Fosshost in the past, neither of them > crucial: > - They hosted a Big Blue Button instance[0] only for the duration of > our COVID Days[1]. > - They donated and hosted[2] two x86_64 machines. > > fosshost1. responds to pings; fosshost2. does not. I never had SSH > access to either. The machines may have been shut down and the > fosshost1 IP repurposed. They might never have made it to production > at all. > > Chris Baines[3], CC'd, will know. As far as I remember, the fosshost machines weren't used recently, and I think they disappeared (and I didn't get around to following this up). So I don't think we need to do anything in relation to them. Thanks, Chris signature.asc Description: PGP signature
