<GNUtoo>hi, are SBCs supposed to work on Guix? <GNUtoo>I tried with the beaglebone black and I can see MLO but then it reboots on MLO again and I've no other prints <GNUtoo>I've also tried with a lime2 and the bootloader works fine this time but doesn't load Guix <GNUtoo>in both case I installed it on the microSD <GNUtoo>I've also strange things, like it does have some x86 code in it <GNUtoo>/run/media/[...]/GNU-ESP/EFI/BOOT/BOOTIA32.EFI: PE32 executable (EFI application) Intel 80386 (stripped to external PDB), for MS Windows <GNUtoo>in the rootfs I found both x86 and arm executables <GNUtoo>is "guix system disk-image --target=arm-linux-gnueabihf lime2.scm" the right command for building the image? <GNUtoo>(with lime2.scm based on the beaglebone black template in guix source code) <GNUtoo>for the lime2 it probably just need to find the syslinux.conf <GNUtoo>sysboot mmc 0:2 any $scriptaddr /boot/extlinux/extlinux.conf <- this boots the board <GNUtoo>though I end up with a scheme shell instead of a bash one <GNUtoo>(because it doesn't find the rootfs somehow) <GNUtoo>in u-boot scan_dev_for_boot_part fails with some error messages <GNUtoo>ohhh the second partition isn't set bootable <GNUtoo>I fixed it with f-disk and it now boots automatically <GNUtoo>though there is still the "waiting for partition '33b9200a-53cc-aa34-07c4-c92033b9200a' to appear..." now <GNUtoo>blkid shows 33b9200a-53cc-aa34-07c4-c92033b9200a for the second partition... <GNUtoo>so some modules might be lacking I guess <GNUtoo>MODULE_ALIAS("platform:sunxi-mmc"); <GNUtoo>I guess I need the sunxi-mmc module too <profmakx>twas a bit of a fiddle finding which modules were required in the initrd <GNUtoo>ok, nice I'm using u-boot too from the microSD though, but I've no idea how u-boot is supposed to boot in Guix <GNUtoo>does it use the usual distro_boot_cmd ? <GNUtoo>since boot is broken, I want to check that adding the boot flag to the second partition is the right thing to do <profmakx>I am currently fiddling about with the boot.txt/boot.scr by hand; it's on my todo list to figure out how to generate it <profmakx>yes adding boot flag is a good idea anyways ;) <GNUtoo>in /boot/extlinux/extlinux.conf there is a config file <GNUtoo>if I set the second partition bootable it will load that file and boot automatically <GNUtoo>and guix generates extlinux.conf <profmakx>I should check whether it does here, too <profmakx>would be grand to just be able to reconfigure *GNUtoo will add the missing module and try again <GNUtoo>Though I've no idea how to add the bootable flag to the generated image <GNUtoo>I did it with fdisk manually so far <profmakx>the way i figured it out in the end wsa by booting another distributen and looking at the drivers required for the root eMMC in /sys/... <GNUtoo>As for the modules Guix probably expects users to add that by hand for now as the beaglebone black template has it <profmakx>yes, I added modules into the initrd-modules list <GNUtoo>the devicetree has the description of all the hardware that isn't probable automatically <GNUtoo>like everything that is not in a bus <GNUtoo>so with that I get the driver with grep <GNUtoo>and I end up in drivers/mmc/host/sunxi-mmc.c <profmakx>heh, that's a good way t ofigure that out as well I guess <profmakx>I'll keep that trick in mind for next time I need to figure such a thing out <GNUtoo>and there I'm guessing that MODULE_ALIAS sets the module name as it's consistent with what OMAP has for the beaglebone black <GNUtoo>(especially with the module in ./gnu/system/examples/beaglebone-black.tmpl in guix source code) <GNUtoo>While I'm familiar with ARM stuff, I'm way less familiar with Guix (I barely know scheme for instance) <GNUtoo>well the basis is easy, but I strugle with the more complicated parts <GNUtoo>and understanding what the code does with match-lambda and so on is complicated for me <profmakx>sure, I struggled with lisp/scheme at the beginning, too <GNUtoo>There seems to be a partition-bootable? flag in Guix <GNUtoo>Though I'm unsure how to use that <GNUtoo>now it boot fully when I add the module and set it bootable by hand <profmakx>I should probably try to make it possible to buid an image for the rockpro too <profmakx>i only installed it with guix init from another system <profmakx>do you cross-compile those images, GNUtoo? <GNUtoo>I used that: guix system disk-image --target=arm-linux-gnueabihf lime2.scm <GNUtoo>so if I understood well --target cross compiles <GNUtoo>Before I tried to use more complete image templates but it failed to cross compile <GNUtoo>(some build system didn't support cross compiling) <GNUtoo>but with that minimal image it works fine <profmakx>I should try this, might be faster to build an image that way; compiling a kernel on the rockpro itself takes quite a while <GNUtoo>It probably needs some more fix for the console <GNUtoo> ;; the MLO and is expected at 0x60000. Write both first stage ("MLO") and <GNUtoo>I guess that here the partition table is created after <GNUtoo>*The second stage bootloader will be loaded by the MLO and is expected at 0x60000. <GNUtoo>So here I guess that u-boot.img is overwritten by the partition table <GNUtoo>in Parabola I had to relocate the second stage to be before that <GNUtoo>The issue also with the lime2 is that there are 3 different Ethernet PHY on the lime2 <GNUtoo>on the am335x devices I did "CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200" on Parabola to fix them, and I also moved u-boot.img to that address *GNUtoo probably need to fix the beaglebone black in Guix too <asterope>somehow dbus-system is still added to my system even after removing any service that relies on it and disabling it in wpa-supplicant <asterope>is there anything other than a service's requirment list that can implicitly add a service to the system? *GNUtoo has no idea where partition is defined <GNUtoo>(define (partition->gexp partition) <GNUtoo>(define-record-type* <user-partition> <GNUtoo> (bootable? user-partition-bootable? <GNUtoo>hmmm I'll probably revisit that later on as it's too complicated for me <bdju>anyone planning to update the alacritty package one of these days? <dftxbs3e>bdju, it's probably a nightmare with all the rust deps <dftxbs3e>I think there is some work on GNU Guix tooling for managing that many dependencies first <bdju>yeah, that's the idea I got based on what some people here have said. I just wanted to believe that since someone packaged it, there should be at least one person who can update it <bdju>kind of a bummer to be stuck on an old buggy version but there's not really another terminal emulator that seems acceptable <bdju>wayland support + bitmap font support are my main criteria. pango killing bitmap support ruined a lot of programs for me and I had to stop using termite <lfam>People have been emulating terminals for several decades. Surely all of them are acceptable :) <sneek>Welcome back lfam, you have 1 message! <lfam>Thanks dftxbs3e. I'll get to it as soon as I can *GNUtoo bugreported with many details for the u-boot issue above <GNUtoo>I'll also bugreport for the AM335x issue <GNUtoo>It'll probably be fixed way way faster than if I try to fix it myself *apteryx just found a funny bug in compressed docs (symbolic link alias need to have the compressor extension, too) <apteryx>rekado_: ever since I've heard your song I've been procrastinating, help <ride>I'm using guix system and Icecat does not seem to have any fonts. <ride>Icons exist but not fonts. <GNUtoo>hmmm I can probably add a patch for u-boot to fix that <zamfofex>ride: I have recently (finally) installed Guix SD on an actual computer, and I decided to do GUI things by myself, as opposed to relying on existing packages. I installed IceCat, and it did not have any fonts, instead displaying blocks with the code point values inside them, even for ASCII characters. I fixed that by installing the DejaVu font <apteryx>ride: did you run 'fc-cache -rf' (or something similar, it's in the manual) ? <apteryx>and do you have any font installed in your user profile? There's dejavu-font used as a fall-back, but perhaps that's not enough? <ride>apteryx: I forgot to rebuild the cache. Thanks! <apteryx>ride: does it display correctly now? <apteryx>I'm dabbled with fontconfig recently but still don't know much about it (other than it's written in a weird C style) <apteryx>perhaps on Guix it could make sense to disable any fontconfig caching, if that's even possible. It's a common gotcha. <GNUtoo>btw, are there tricks on how to handle pythonpath with Guix (not GuixSD) ? <GNUtoo>like how can we choose one python or another? <GNUtoo>and separate the modules being used <GNUtoo>source /home/gnutoo/.guix-profile/etc/profile ; echo $PYTHONPATH gives only things starting with /gnu in PYTHONPATH <GNUtoo>yet which python points to /usr/bin/python <GNUtoo>ah maybe python programs are all expected to be patched, though I'm unsure how to launch python itself <apteryx>GNUtoo: the best with python from Guix would be to keep it in a separate Guix profile <apteryx>(guix environment --pure --ad-hoc python python-some-library ... -r ~/.config/guix/profiles/your-python-profile <apteryx>if you want to use different versions of Python, keep them in distinct profiles <apteryx>otherwise they'll conflict since PYTHONPATH is not versioned <GNUtoo>apteryx: that works fine, my main issue is between my host (Parabola) and Guix itself <GNUtoo>but here I can at least run a working python with your command, thanks a lot <apteryx>ah, like... sharing things from both environment? I'd refrain from doing so. It'll give you more headaches than satisfaction. <cheers>does guix have anything like nix flakes? <apteryx>I'm not familiar with 'nix flakes'. What does it help with? <GNUtoo>apteryx: I'd like to avoid that but it's complicated: I've packages in Parabola that depends on python, and I need Guix packages that depends on python too... <GNUtoo>so I probably need to wrap Guix packages with an environment command somehow <GNUtoo>like guix environment --pure --adhoc <the package name> <some way to execute it automatically> <bqv>cheers: I've asked this before <bqv>I'm pretty sure the answer is no <GNUtoo>there was also a Nix and Guix comparison in the last Guix conference <cheers>GNUtoo: a replacement for channels, ie, an easy way to distribute nix-packaged software <cheers>(i'm not talking about `guix pack`, ftr; flakes are more source-based-- they're a way to specify the dependencies for a nix-managed project) <bqv>It's basically a dependency manager for nix code itself, so you don't have to manually TOFU everything repeatedly, and can bring in new code trivially <cheers>where nix generates a lockfile and takes care of updating them for you <cheers>somewhat similarly to how cargo and npm work <GNUtoo>we have stuff like manifest files, but I'm unsure if it's similar or not <cheers>(in their use of a lockfile for pinning dependency hashes) <bqv>Something like niv would be the first step to doing it in guix <cheers>i may write something like this, then <tgamblin47>cheers: how do they look up the pinned hashes? is there a flake registry? <cheers>it just downloads the newest version of whatever dependency you specified, via url/git repo/whatever else <apteryx>cheers: I still don't have a very clear picture of the 'nix flakes' tool, but a manifest + channels file does allow you to pin exact dependencies of the packages and of guix itself. <cheers>hm, that involves updating hashes yourself, doesn't it (unless i'm missing something) <apteryx>in the simplest case suppose your project is happy with the version of its dependencies in a given Guix revision. Then you just need to fix a single hash of Guix to cristalize them (guix describe -f channels > channels.scm). <apteryx>where it gets tricky is if you need packages from different Guix revisions. This is currently achievable via Guix inferiors, but yes, you'll have to grep the history to discover which Guix hash contains what you want. <apteryx>and by Guix hash, I really mean Guix commit. <cheers>flakes are for specifying external dependencies, really <cheers>like if you have something you wanna check in from some random git repo <cheers>(it's supposed to be a packaging format for nix projects, if that makes sense) <apteryx>Wouldn't you write a package definition for those? And then either upstream their definition (yes please) or keep them in a channel if it's private/ugly :-) <cheers>yeah, ideally, though it's easier to just add a git repo to the flake inputs (and write some trivial nix config for it), if it's just for some specific project <cheers>(the channel thing works, but they're less nice, imo...) <bqv>I think channels are the closest analogue to flakes in purpose and nature <bqv>Just less tidy, yeah <cheers>i may try to whip up a flakes-esque tool for guix, when i find the time :) <zamfofex>I wonder how feasible it would be to get package suggestions when typing the name for a program that isn’t installed, kinda like in Ubuntu. <bqv>zamfofex: so a command-not-found helper. Yes, nixos has one, so guix easily could <marusich>Anyone have trouble building "guix build --no-grafts -d gnutls@3.6.12" recently? I get an error like "You need openssl to run this test." I don't want to substitute it, but there are substitutes available for it, which makes me wonder why I can't build it but the build farm can... <marusich>To try a build, remove the -d from the command. <efraim>gnutls@3.6.12 is known to fail, something about missing the time window when it will build and pass the tests <bonz060>efraim: Btw I wasn't able to work around the `guix pull` failing from the call to the store within the package. I'll look at that once I format my disk and re-install my OS :) <efraim>bonz060: no problem. no one's complained about it so I assume everyone is working from a checkout. we'll get it fixed eventually. <rekado_>apteryx: you can ‘weaponize’ procrastination. In my case, I procrastinate on things that I should do by doing other things. It’s just a matter of putting meaningful tasks in the those slots on the TODO list that would be picked when procrastinating on the top priority task. <leoprikler>The hoops through which I had to jump to set up SSH access. <dftxbs3e>sneek later tell bdju, quite frankly just use cargo install alacritty for now, it will do fine <apteryx>rekado_: Clever :-). Thanks for the tip! <gnutec>rekado, Just doesn't record. But is perfect now. <gnutec>rekado, I did know about "peek". But is 7,3 MB against 1,2 MB from Simple Screen Record. I'll take a look. *profmakx discovers the risc64 qemu bootloader, tries making a disk image <nij>Hello! I'm new to this place :) I tried Nix before and quite liked the idea. But I left as there was much work to do and I didn't like the language. I recently got into Lisp, and found Guix. I'm interested again. Before I dive into the playground.. I'd like to clear some of my concerns. <nij>1. Rumor has been that Guix has a much smaller community, and there are more restrictions (e.g. hard to get non-free software). Do you find yourself switching to different package manager quite often? <nij>2. I'm on arch. Can I use Guix just as a package manager, and expect it to completely replace pacman/aur-helper? If so, what would be a practical way to start? If not.. would I be using both systems at the same time..? <nij>3. How to handle python (or ruby, go, haskell.. etc.) packages (i.e. those that you get from pip install)? <PotentialUser-80>Is it possible to cross-compile a BeagleBone Black installation image on a x86_64 computer? <nij>4. What will I lose if I use Guix as a package manager but not the whole OS? <atw>1. I think you have to answer that one for yourself by asking how well will free drivers work on your hardware. Heads up that in this and other official forums, it's desired that discussion stay on free software <bqv>5: also try repology, perhaps <bqv>1: I'm finding guix is better stocked than I expected, but still slightly lacking yes <atw>3. many python, ruby, go, and haskell packages are available in guix. You're free to use Guix to do development in those languages, but if an eg python library is not packaged in Guix, you may end up packaging it yourself (but this is usually very easy thanks to importers). Alternatively you can keep using eg Stack for Haskell. Whatever works for you! <atw>nij: re 3, any specific plans? <lispmacs>nij: hi, I use Guix as my full system on my home and work desktop PCs. I just wanted to mention some downsides to Guix on, say, Debian: (1) when I tried that in the past, development of code became rather complicated due to interaction between libraries installed in the traditional paths, and libraries I had installed through guix. (2) if you use Guix as your full system, it makes a lot of cool system configuration <lispmacs>easy to do through minor edits to your system configuration file, and running the "system reconfigure" command <nij>atw: Thanks.. and not yet. I'm just worrying to be hopping from different packaging systems.. <atw>"--root=FILE [...] Make FILE a symlink to the result, and register it as a garbage collector root." if I were to do this, how would I undo it? How would I unregister FILE as a GC root? <atw>+1 to lispmacs' point: you'd be missing out on all the cool features of the Guix System! :P I especially like Shepherd <nij>lispmacs: as for your first point.. do you mean guix is easier than debian, or vice versa? <mroh>atw: `rm FILE` would undo the "registration". <ruffni>i am trying to set up a guix StandaloneVM in QubesOS. Qubes warns about having to manually configure a StandaloneVM for networking to work correctly. i managed to bring up the link (ping 1.1.1.1 works just fine) but i'm having trouble resolving hostnames. any pointers? i'm running the `guix-system-install-1.1.0.x86_64-linux.iso` <mbakke>ruffni: if you configured networking manually, you probably also have to manually update /etc/resolv.conf with a working name server <mroh>udisks-service is running? <raghavgururajan>mroh: It is not. I thought the error was python related. But this might be it. <raghavgururajan>Gooberpatrol66: IIRC, some GNOME stuff use pipewire. But there is no pipewire service in guix, yet. <sakalli>hi *. a couple of hours into guix on top of arch. when you install packages 'imperitavely', does it generate a file or can one export one, that declares the current state of the installed packages. ie. what would be the way to restore a profile? <lispmacs[work]>sakalli: I'm checking in the documentation to see if there is a way to generate a manifest file from a profile <lispmacs[work]>I do things the other way around. If I need a new package I just add it to my manifest file. If I need a package short term or on an evaluation basis, I use `guix environment --adhoc <package>' <lispmacs[work]>sakalli: I'm not seeing a way to generate a manifest file from a profile; I seem to recall asking about this once but can't recall what I was told. One can do `guix package -l' to get a description of all the changes you have made to your profile, which would be helpful in building your Manifest file <lispmacs[work]>(specifications->manifest '("<package1>" "<package2>" ... "<packageN>")) <lispmacs[work]>you don't have to list all the dependencies in the manifest file, just the packages you want to see in it <sakalli>ok cool, makes sense. the declarative way was what i was looking for. thank you <lispmacs[work]>another fun trick is you can have more than one manifest file, and use the `guix environment' command to load up a particular set of packages in the current terminal <leoprikler>You can read the manifest of any profile using (profile-manifest "/path/to/profile") <lispmacs[work]>leoprikler: you might need to explain where to find the default /path/to/profile <leoprikler>sneek: profile-manifest is a procedure to read the manifest of a Guix profile, e.g. (profile-manifest "/home/user/.guix-profile"). It is defined in (guix profiles). <leoprikler>Can you even do that tho? Last I checked, -e was for packages only. <lispmacs[work]>isn't there some guix command-line command for loading up a guix scheme environment, or did I just imagine that? <lispmacs[work]>so, run `guix repl'. then `,use (guix profiles)'. then `(profile-manifest "/home/<user>/.guix-profile") <lispmacs[work]>I don't think you could actual use that output in a manifest file, though <lispmacs[work]>I got a list with a full printout of every manifest entry object with all the attributes printed out including version numbers and dependencies <leoprikler>nah, that's for bit-by-bit recreation of a profile on another machine <lispmacs[work]>basically what you want for reproducibility is a simple manifest file, plus the information from `guix describe' <leoprikler>sure, but many folks don't actively maintain a manifest file and then inevitably ask *that* question <GNUtoo>Hi, is there some way to make local Guix mirrors and how much space does it take? <lispmacs[work]>leoprikler: could you come up with a function that converts profile-manifest output to something useful for "many folks"? <lfam>GNUtoo: What kind of mirror? <lispmacs[work]>leoprikler: sounds like a great guix blog post, or cookbook article <leoprikler>(map manifest-entry-name (manifest-entries manifest)) <GNUtoo>lfam: a mirror similar to Parabola, so that contains substitutes as well as all what is needed to build them and release medias too <GNUtoo>Where the substitutes are just rsynced and not built locally <lispmacs[work]>so, (map manifest-entry-name (manifest-entries (profile-manifest "/home/christopher/.guix-profile"))) <lispmacs[work]>sounds like we are a few paragraphs away from a cookbook paragraph <GNUtoo>The idea is to have a local complete cache of the latest substitutes and source code <lfam>GNUtoo: Yes, a mirror was set up for people in China recently. If you search the mailing list archives you'll find the discussion and could see what they did <lfam>It's easy to set up a caching server but it won't be complete — it would just cache whatever is fetched through it <ekaitz[m]>Ofc, they are not perfect or anything, but I'd like to know if it makes any sense to send them as patches if the package version is an unstable commit <ekaitz[m]>what's the guix criteria on non-tagged commits? <ekaitz[m]>or, rephrasing for this actual package: what is better: have a broken workspace or unstable code in the whole package? <lfam>It's definitely better to build it from an untagged commit than for the package to be broken <lfam>You're more likely to get a timely answer if the suggested changes are in the form of patches. <lfam>The farther it is from appearing "ready to push", the lower priority it will be to review, speaking for myself <ekaitz[m]>there's something else that made me send the message before going for a patch, it's the fact that the whole freecad package is a mess (not because of us, it's an upstream problem) <ekaitz[m]>this proposed change adds some deprecated codebase that freecad still needs and all that, so I'm not sure how long will this stand... <lfam>For things like this, where the situation is complicated, it's better to try to get help on IRC. Email is too asynchronous to handle the Q and A <profmakx>mhm, is ./pre-inst-env guix build -f gnu/system/hurd.scm supposed to work? <ekaitz[m]><lfam "For things like this, where the "> if the proposed changes make some sense for you i'll just spend some time and prepare them as patches <lfam>ekaitz[m]: Even if you're not sure about the code, it's always better to send patches, and say that they build. If they don't build, say so, and include the error messages. <leoprikler>profmakx: no, you need variables at the end of the file for that to work, which does not line up with how guix is supposed to be written <lfam>ekaitz[m]: The important thing is if the changes make sense to you :) You will be the freecad expert in the review session, most likely <ekaitz[m]>lfam: hah, i think i am but that's why I'm in doubt, because the whole thing is a mess :) I suppose i'll send the patches and live with it <lfam>ekaitz[m]: If the package is broken, it's likely that there will not be a reviewer who uses it, so you have to be the one who decides what to do <lfam>ekaitz[m]: We definitely aim for the packages to be "correct", but sometimes it's not clear what is correct. And if something is wrong, it can always be changed <GNUtoo>ah too bad: "No. To deal with software repositories that are not easy to have a full <GNUtoo>sync, maintainers of SJTUG wrote a cache program" <GNUtoo>They got it working through caching and not mirroring <ekaitz[m]>lfam: I'll try to go for it then, thank you! <lfam>That's what I figured, GNUtoo <profmakx>i seem to be incapable of finding consistent and useful documentation <GNUtoo>So I guess you cannot really use Guix without Internet <GNUtoo>And you probably need decent speed connections <lfam>That's not really a factor ***iyzsong- is now known as iyzsong
<lfam>Or, it has the same impact as any other distro <GNUtoo>A Parabola mirror is about 212G and it has full source code + binaries + installation medias <GNUtoo>Sadly I'm not currently good enough in Scheme or Guix to implement that myself (the mirror) <lfam>Parabola is an Arch variant? <GNUtoo>An FSDG version of Arch + Arch32 + Arch ARM <GNUtoo>Can you at least mirror the source code? <GNUtoo>so we don't have a command to download everything I guess <lfam>We "build" both sources and binaries. They are handled in the same way <GNUtoo>Right, so I guess it would be possible to "download" the full source code of everything if I act like a substitute provider? <lfam>GNUtoo: There's no command to "download everything". You only download the things you ask for <lfam>But, it only caches the things that are requested, and it's not intended as an archive <GNUtoo>can you at least "build everything" somehow? <lfam>You could set up a build farm, using Cuirass or the Guix Build Coordinator <GNUtoo>ok, so I guess that I would probably need to patch Guix to "download everything" without building everything <lfam>But, it's not a small undertaking. In many cases it would be a lot easier to get online <mbakke>GNUtoo: you can do something along the lines of 'guix package -A | xargs guix build --source' to get all the sources <lfam>You'll want to add --keep-going, since some things will fail *GNUtoo also guess that it would also be possible to do that with substitutes <mbakke>GNUtoo: it will miss some of the "bootstrap" sources though <GNUtoo>The idea would then be to clean the store when sources are too old <apteryx>mbakke: what do you think of using python-minimal instead of python for the build system on core-updates? <apteryx>to prevent dragging in tk in the closure of some packages, which depend on fontconfig <apteryx>I was working on updating fontconfig and a cycle appeared when I tried adding the needed inputs to build its doc <mbakke>apteryx: Right. I don't have a strong opinion, maybe raise it on guix-devel? The main issue I see is that packages will eventually get two different 'python' derivations in their closure. <mbakke>python-minimal exists mainly to have an escape hatch for that exact dependency cycle <ruffni>i've stumbled over a bug and am requested to report it to bug-guix@gnu.org. should i just email the error message or is more data needed? <mbakke>ruffni: the error message and what you did to produce it is great <apteryx>mbakke: if all the python packages are built using python-minimal, wouldn't there be only python-minimal in the closure (unless the user explicitly adds the 'real' python package?) <lfam>ruffni: You should also include the output of the commands `guix describe` and `guix --version` <mbakke>apteryx: but 'python' is widely used outside of python-build-system, so we'd have to change those too <mbakke>apteryx: some packages might also expect that 'gdbm' is available, but I suppose we can add that to python-minimal if making it the default <ruffni>strange.. the error occured while running the first "guix pull" after an installation. no error when i run it again. i guess i won't report it <lfam>Then it's likely a transient networking failure, ruffni <lfam>Wow, we should really do something about the linux-libre sources. I think that currently they are built 4 times <atw>thanks mroh, the guix gc page in the manual has some helpful info I hadn't read before. I may make a contribution to state explicitly that roots created with --root can be unregistered by deleting them <efraim>I like the idea of python-minimal for the build system <apteryx>mbakke: I think the wiser thing to do will be to keep fontconfig docless as it pulls too many things for such a core dependency <apteryx>and define a fontconfig-with-documentation <apteryx>perhaps making the new fontconfig-with-documentation the user facing package <lfam>Or the inverse. Keep fontconfig as it is, and add a fontconfig-minimal variant. This is more consistent with other similar use cases <apteryx>but then I need to edit the whole collection to refer to fontconfig-minimal <apteryx>and it's one new special package variable name to keep track of for packagers ;-) <apteryx>(although the other situation can play tricks too (guix refresh -l fontconfig -> nothing depends on it) <apteryx>actually that's true when using fontconfig-minimal rather than the fontconfig-with-documentation