Re: Using bootstrap seeds write package definitions
Hi c4droid, Le Sun, 16 May 2021 10:50:36 +0800, "c4droid" a écrit : > Hello guix! > I was using the Linux From Scratch for a while as my mainly linux > distro, use soft link as package management. when I heard guix, I > think I found solution for my LFS package management. I tried guix > and guix system few month, Is time for switch my LFS package manager > to guix. I've been using LFS (and my own LFS-based "distro") for some years, so I completely understand why you'd want to use guix. Actually I based my "distro" on what I understood from Guix and the package manager from Haiku. When I understood I implemented that badly, I switched to Guix and Guix System entirely, no more LFS :D. > When I watched the manual talk about bootstrapping guix, I don't know > how to writing some package definitions with bootstrap-seeds, I was > searching on the google and ask questions on irc, because building > the LFS, want build the cross toolchain (stage 1) then build final > system (stage 2), last is kernel and initramfs (stage 3). after that > is build Beyond LFS (stage 4). I stuck with using bootstrap seeds > writing stage 1 package definitions. So I ask for help on community, > because the power of community is great. :) So Guix comes with a set of packages, which are just recipes to build them from source. There are two things you might want to do: you can either use the existing packages or create your own recipes for the whole system. If you choose to use our packages, then there are again two options. You can use the existing binary bootstrap (the only thing you wouldn't build yourself), or build it yourself and replace the binaries used in Guix by your own. Note that the bootstrap binaries are different from the binaries built for the first chroot of LFS (the cross-compiler). We do not use a binary GCC, but we instead start from mescc, a small C compiler, and use it to build tcc, then gcc, with the goal of reducing that down to stage0, which is only a few hundred bytes of binary, plus sources of other packages. # Using our recipes and bootstrap binaries If you want to use our bootstrap binaries, there is nothing to do, because Guix itself will be able to get the binary bootstrap and build everything from it. Do not enable substitutes if you want to build everything yourself. # Providing your own bootstrap binaries If you prefer to provide your own bootstrap, you'll have to build and provide binaries for the bootstrap seeds we currently have in Guix, that you see in the manual. # Building your own packages If you decide not to use our recipes, you must write your own. The set of packages is rooted in the bootstrap seeds, as you noticed. However, if you want to provide your own recipes, you are basically free to provide any bootstrap and further packages you want. What you could do is to build stage1 (cross toolchain), use that as your binary seed, and build the other stages as guix packages. Note that for that, you'll need to have guix already installed on the host system. If you have never used Guix, or never written a package definition, you might want to have a look at our short packaging tutorial at https://guix.gnu.org/en/cookbook/en/html_node/Packaging-Tutorial.html#Packaging-Tutorial (French and German are also available if you prefer one of these languages). There is some code in gnu/packages/bootstrap.scm that you might be interested in. It has some interesting bits: first there are a few binary seeds with hashes: they are statically linked binaries that are needed to decompress other seeds. Then, we define a few special procedures that replace the normal packaging procedures (bootstrap-origin, package-from-tarball). You probably want to use them or get inspiration from them to create your own bootstrap recipes (packages that simply decompress a tarball containing a prebuilt binary). The rest of the file lists these packages. Then gnu/packages/commencement.scm is the very beginning of the package graph. These packages use the binary seeds to build up to gcc, that we later use in the gnu-build-system, etc. You will be interested in the comments in this file too :) # My own experience with my package manager (not guix) If I recall correctly, what I did when I had my own "distro" (and package manager), is that I first built the cross-toolchain and base system from LFS (it was pre-10.0, and we built the cross-compiler and use it firts outside the chroot to build the base build toolchain we could then chroot to). I would first manually create a package from the chroot, and install a first system with only that package, then chroot to it. Then, from this system and the chroot package, I was able to build the base system with my package manager. Once I had the base LFS system (stage 2), that system had a dependency on the chroot package, which was not acceptable for me, so I replaced all the recipes to depend on the previously built version, turning stage2 into a set of bootstrap binaries. I
FUSE works as non-root user but not in Shepherd service under same user
So, I've been struggling with this for a few days now. I have a Chez script that waits until a SQL dump is written, cleanly shuts down the FUSE file system that uses the corresponding database, deletes the database, undumps it from the newly written SQL script, and waits for the next write, all in an infinite loop. To make the system a bit more secure, I run it as the gmnisrv user. It works fine when I run it with su as: su -s $(guix build memex-runner)/bin/memex-runner.sps gmnisrv /path/to/gemini/document/root Translation, because su's syntax is a bit weird: `su -s [args...]` runs [args...] as username. So, should have the same effect as specifying user and group in the service description, right? But when I run the service I get this error: ``` Mounting to "wiki/tags" Forked into background PID 1478 fusermount: mount failed: Operation not permitted ``` I have no clue what's going wrong. The mount point is owned by gmnisrv, the database file too, /dev/fuse has read and write access for user, group, and other, looking at the strace output doesn't reveal anything obviously wrong or different between running it with su or with Shepherd. I also thought that I might be wrapping memex-runner.sps wrong and it finding the binaries in /gnu/store before the ones in /run/setuid-programs, so now wrap-program suffixes the PATH of inputs instead of prefixing it, but that still didn't fix anything. I'm out of ideas. Any idea how to proceed, short of going through the source code for everything that's involved here, including FUSE, Shepherd, Linux, and Supertag? Here is my channel, look for raingloom/services/gemini.scm and raingloom/packages/scheme.scm. https://git.sr.ht/~raingloom/guix-packages/ My machine configs are private but if needed I can share the relevant bits, but I don't think there is anything relevant. It's a pretty basic web server setup with Nginx and Molly Brown.
Using bootstrap seeds write package definitions
Hello guix! I was using the Linux From Scratch for a while as my mainly linux distro, use soft link as package management. when I heard guix, I think I found solution for my LFS package management. I tried guix and guix system few month, Is time for switch my LFS package manager to guix. When I watched the manual talk about bootstrapping guix, I don't know how to writing some package definitions with bootstrap-seeds, I was searching on the google and ask questions on irc, because building the LFS, want build the cross toolchain (stage 1) then build final system (stage 2), last is kernel and initramfs (stage 3). after that is build Beyond LFS (stage 4). I stuck with using bootstrap seeds writing stage 1 package definitions. So I ask for help on community, because the power of community is great. :) p.s.: Sorry for my poor english -- Best reguards c4droid
Re: python to support SQLite extensions
Hi Jelle,
On 5/10/21 11:31 PM, Jelle Licht wrote:
> Does anybody perhaps know why my python is correctly receiving (and
> subsequently ignoring) this configure flag? It seems that *something*
> happens between the 'configure' script receiving the flag, and the file
> in `Modules/_sqlite/connection.c' being built, it seems
> SQLITE_OMIT_LOAD_EXTENSION is set to "1".
>
> This (seemingly) happens in setup.py, lines 1432 and on:
> --8<---cut here---start->8---
> if '--enable-loadable-sqlite-extensions' not in
> sysconfig.get_config_var("CONFIG_ARGS"):
> sqlite_defines.append(("SQLITE_OMIT_LOAD_EXTENSION", "1"))
> --8<---cut here---end--->8---
>
> Indeed, in *any* python3 I can find on my Guix System, I see:
>
> --8<---cut here---start->8---
> #> import sysconfig
> #> sysconfig.get_config_var("CONFIG_ARGS")
> '--with-system-ffi'
> --8<---cut here---end--->8---
>
> Something weird is going on!
>
> I have no clue how to continue finding why this happens, but for my
> personal problem I can just patch python's setup.py file.
You're onto something with `sysconfig.get_config_var("CONFIG_ARGS")`:
In the definition of the python-2.7 package from which the python
package eventually derives from, a phase
`'do-not-record-configure-flags` is added before `'configure`. This
phase removes everything but '--with-system-ffi' from `CONFIG_ARGS`.
I've successfully enabled loadable sqlite extensions with the following
package definition.
---8<8<8<8<---
(define python-with-loadable-sqlite-modules
(package (inherit python)
(arguments
(substitute-keyword-arguments (package-arguments python)
((#:configure-flags cf)
`(cons* "--enable-loadable-sqlite-extensions" ,cf))
((#:phases phases)
`(modify-phases ,phases
(delete 'do-not-record-configure-flags)))
--->8>8>8>8---
While this works, it might be better to modify the
`'do-not-record-configure-flags` phase to keep the
`--enable-loadable-sqlite-extensions` option instead of completely
removing this phase.
I think it might be a good idea to enable loadable sqlite extensions by
default in the python package. As you've already pointed out, other
distros have this option enabled which leads to surprises when trying to
load sqlite extensions in guix's python.
Hope that helps,
Felix
How to repair/reinstall guix on foreign distro
Hi! It seems every few weeks i’m thrown into a initramfs prompt, as root got mounted read-only. The way out is always running fsck, which reports errors and offers fixes that I either can’t map to anything, or that refer to paths that belong to guix. Usually only below /gnu/store, but this time also var/guix. Now `guix pull` fails with: ``` ;;; WARNING: loading compiled file /gnu/store/8bsnz1fk330qbn1p8k18i0j11vld4jxd-guix-module-union/lib/guile/3.0/site-ccache/guix/build-system/gnu.go failed: ;;; In procedure load-thunk-from-memory: not an ELF file Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... guix pull: error: Git error: invalid data in index - incorrect header signature ``` At first, I focused on the warning (sorry, leoprikler) ... the same git error happens when using an older guix. Now a fix for that would be great, but independent of that, I have to wonder how one should go about reinstalling guix on a foreign distro. I cannot umount or remount and remove /gnu/store! Even after `sudo systemctl stop gnu-store.mount`, /gnu/store is busy. `fuser -kim /gnu/store/` will throw me out of the session, even though I would think everything that belongs to it is part of the host (Ubuntu Unity 20.10). No sudo umount or remount or rm -rf allowed, /gnu/store remains ro and busy. Short of booting another system (say an USB stick), is there a way to clear /gnu/store? Or to safely replace its content? -- Thorsten Wilms
