<trevdev>Hey Guix. Is there some way to perform a "shell source" from a Guile script file? I tried a (system* "." "/path/to/file"), I got "permission denied"
<nckx>No. There is no ‘.’ command, and even if there were it wouldn't do what you think it would. You'll have to either parse the file yourself (doable if it's simple KEY=VALUE subset syntax) or have a shell source it and *then* run your Guile script from it.
<trevdev>I guess Guile scripts do have their limits, then. I was hoping to avoid faffing about with shell script. I guess I'll set an alias for every single guix profile I could need.
*apteryx is booting Rocky Linux XFCE GuixFarm thing
<trevdev>If some ruby-gems broke because the ruby version changed and they did not get "re-built" what's the simplest wat to rebuild them?
<nckx>trevdev: Another (ugly) hack could be to system* bash to run ‘. myfile; env >/tmp/myvars’ and then still parse & setenv each line yourself, but at least you would be able to continue in the same Guile process almost as if you had sourced myfile. You'd basically be serialising your child's (bash's) environment, to then load it into yours (the parent's). Big words for such a silly thing, which I can't actually recommend, I just had to mention it.
<nckx>trevdev: Guix doesn't have a concept of ‘re-building’ things to fix them. Do you mean update?
<apteryx>apparently in EPEL 9 (which Rocky Linux 9 would use), there's now Btrfs support, thanks to Fedora
<trevdev[m]><nckx> "trevdev: Guix doesn't have a..." <- Ruby gems with "native bindings" need to ve re-built when a ruby version changes. My gem packes are all needing this. I can't just use the gem command because of the nature of Guix
<nckx>And I don't know the first thing about the gem command. But I get that they aren't managed by Guix. Which also means I can't help.
<nckx><Ruby gems with "native bindings" need to ve re-built when a ruby version changes.> That sounds distressingly common, but also implies that there should be Ruby tooling to manage such a common thing? Just guessin'.
<apteryx>the Guix System images gets stuck on: Loading initial ramdisk ( /images/Guix_System_1.3.0/initrd.cpio.gz ) ... in PXE
<apteryx>I know the PXE server is 'cobbler'. Not sure why it's so picky.
<PotentialUser-59>Guest8 I attempted that but the computer wouldnt boot from the usb drive
<nckx>raghavgururajan: The CI *didn't* break? It was running fine until the end, both -ends.
<Guest8>PotentialUser-59 maybe because you didn't F10 or Fwhatever so to tell the computer to boot from the usb drive?
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | 🚨 We are biting some bullets, https://guix.gnu.org is down 🚨 | use https://bugs.gnu.org/NUMBER for bugs/patches | videos: https://guix.gnu.org/blog/tags/talks/ | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
<nckx>Has anybody successfully booted the Guix System installation image over PXE?
<Guest99>Maybe someone here understands my question as I try to goole an answer for it but could not find any blog or mailing list posting answering my question: As far as I understand it Guix builds every package in a chroot. My question is: Does every package build start with Mes (or MesCC)? These bootstrapping from scratch minimal tools/compilers?
<roptat>yes and no: mes and mescc are at the bottom of the (build) dependency graph
<nckx>Yes, but once (for example) GCC exists, whether built by you or downloaded from a substitute server, it isn't rebuilt. Every package's dependency graph starts with Mes & friends.
<roptat>and the functional package management style means that whenever something changes, all its dependents are changed, so if something changes in mescc, guix will know that it needs to rebuild gcc and all packages above that
<Guest99>But then my followup question is: Is there a command to say "please, build starting by Mes" (or whatever comes first in this "bootstrapping from scratch" chain)?
<roptat>if you want to build everything yourself, you can disable substitutes
<roptat>(substitutes are built by the build farm in the same way your guix would if there were no substitutes available)
<nckx>If you'd install Guix from the 1.3.0 installer and disabled substitutes, you'd rebuild everything from scratch.
<roptat>right, and that's because the bootstrap chain was completely modified between 1.3.0 and now
<nckx>*During installation*, so lots of fun. You could also install a 1.3.0 system with substitutes, boot into it, and then start the upgrade process without substitutes, and at least you can watch cat videos on the machine whilst it bootstraps ‘master’.
<nckx>As you can tell, berlin ain't going so well.
<gowpjmu93[m]>I'll help 20 individuals how to earn $30,000 in just 72 hours from the crypto market. But you will pay me 10% commission when you receive your profit. for more details on how to get started
<nckx>I mean, I can kick the bot, but it's futile.
***ChanServ sets mode: +o nckx
***gowpjmu93[m] was kicked by nckx (gowpjmu93[m])
<nckx>If you want to lose your life savings to a scammer, more power to you, but I hope Guixers are cleverer than that.
<Guest99>Cool. The thing is (I mean my real problem): I want to understand how Mes and MesCC are built and how they work (and so on) but many (important pages) of the manual are missing so I thought that maybe by using Guix I can see how the bootstrapping works.
<blake2b>[unrelated] a few days ago delimited continuations finally crystalized for
<nckx>See (1) topic (2) entry message when you join, but you didn't join.
<nckx>In fact, which some people might find even worse, it currently running Ubuntu 🦇
<blake2b>with all of the more advanced / highly general scheme topics I typically find myself butting up against each time I approach them, I'll have a sudden epiphany while doing errands and the steep upwards climb quickly plateaus and I'll discover super powers.
<blake2b>has there been an email about the issues its facing & the move to Ubuntu? I feel like always miss these things until the shit hits the fan, and perhaps its due to the emails being on a list i'm not subscribed to.
<nckx>Guest8: Does ‘grep 7D602902D3A2DBB83F8A0FB98602A754C5493B0B778C8D1DD4E0F41DE14DE34F /etc/guix/acl’ return anything?
<nckx>And this needs to be run in an absolutely pristine checkout, no untracked files etc. ☝
<Guest8>nckx: how long is that command supposed to take?
<blake2b>i find the idea that we shouldn't openly discuss project issues due to the possibility of flamers taking it out of context to be discouraging. aren't these matters important for users to be kept in the loop?
<blake2b>sorry, I was just trying to get a grip on whats happening and how I can be better informed
<nckx>blake2b: We are currently running Ubuntu because I tried every option in the PXE menu for the past half hour, and Ubuntu actually worked, the end. That is the entire extent of the reasoning and discussion that led to it :) There is no sinister plan.
<nckx>I tried a good few things to get Guix to boot (from ISO) but I simply don't think it's feasible.
<nckx>And (you can't know this) I find the Dell rescue environment extremely hostile, so nothing is fast, productive, or fun, and I doubt I'd make any progress on the Guix System boot even if I put hours into it.
<nckx>blake2b: You are kept in the loop. I'm vomiting random info in the scrollback (to the point where I thought I was annoying), & there's the topic & entrymsg.
<nckx>I could also write a nice e-mail but I choose not to and poke at the system instead.
<nckx>Heh, ‘guix pull’ is trying to pull substitutes from ci.guix 🤦
<blake2b>nckx: I feel you, what I was asking wasn't accusatory. I just thought there could be a mailing list I'm not subscribing to (for example, I think theres a guix-announcements mailing list I'm not subscribed to; I was wondering if it could be happening there).
<blake2b>part of why i'm curious is I'd like to see how I could lend a hand. I have a decent grasp on the system now, run my own cuirass instance, and am decent at debugging
<nckx>blake2b: I gave you the wrong impression. ‘There isn't a sinister plan’ is just nckx for ‘there isn't as much of a plan (with announcements, timelines, etc.) as you obviously think, friend, I decided to boot Ubuntu 5 minutes ago’, not meant to imply I thought you actually thought there was.
<blake2b>if there is any pitching in I can do, lmk! i have some free time atm so could debug faulty parts of the system on my end if that would be helpful
<nckx>blake2b: Thanks for the offer, but we're currently at the level of Dell HBAs, SANs, GRUB, and the Guix initrd (we think?) not playing nice together. This has been going on for months and, since it's possible to eventually boot the system, always postponed. When the system boots it mostly runs fine, or at least we know what the issues are there.
<roptat[m]><Guest8> "but saying something is 100..." <- it's not a bug, substitute-urls can also be used for mirrors or for downloading substitutes from untrusted sources that have the same hash as trusted sources
<apteryx>the box is now running in UEFI mode, so hopefully it works this time. I'll also upload a wip-migration branch on maintenance with the 3 commits I 'guix system init' with that haven't yet been merged.
<apteryx>OK, I see we're at keyboard configuration screen
<nckx>apteryx: We weren't, we were at a different and more useful screen, but cool that Ubuntu decided to change that while I wasn't even connected.
***ChanServ sets mode: -o nckx
***califax_ is now known as califax
<trevdev>I made the decision to re-factor my system config. Now when I try to reconfigure, I get errors like "wrong type in position 1: define". I am not sure why this is happing. When I call reconfigure with a target system.scm, must I ensure that the whole file contain nothing but the module requirements and operating system declaration? Other examples on the net don't seem to follow that pattern
<hako>Just ensuring an operating-system record is returned.
<nckx>Right, there are no artificial limits on system configuration files, you have the full power of Scheme at your disposal as long as you hold up your end of the bargain (returning an o-s). What you describe sounds like a run-of-the-mill syntax error/typo, trevdev. The ‘define’ symbol just isn't in a place where it's seen as defining something.
<nckx>raghavgururajan: That might have been due to running out of inodes on /gnu.
<nckx>I can't prove it, of course, but AFAIK Cuirass itself was up and ‘running’ (just unsuccessfully).
<Kabouik_>I'm coming back to my Guix SBC after 7 months not using it, and I don't know anything about Lisp and Guilde... The learning curve seems even harder today than 7 months ago. My brain is getting too old.
<kabouik>Also maybe I should edit configuration.scm instead of system.scm, I'm not quite sure anymore. As far as I remember, system.scm is used to deploy to other machines, while configuration is for user-specific configurations? At the moment, both are quite similar on my machine; not sure if that's even necessary to have them mirrored or if configuration.scm should just contain the additional specific things.
<roptat[m]>file name doesn't matter, you pass it to the guix command anyway
<kabouik>But configuration.scm belongs to the user while system.scm belongs to root, and system.scm also contains more lines about nvme drive and partitions, etc.
<kabouik>To be honest it's quite hard for me to get back into my config and understand what I did, I put that SBC in a cardboard by lack of time before I fully started to comprehend what I started; Guix is a whole new paradigm for me, and I don't know much about Scheme/Lisp so it's also hard to write/read.
<kabouik>I mean, it's a nice challenge, but I am afraid I might end up asking silly questions here
<roptat[m]>it's fine, we have lots of silly answers for you :)
<kabouik>I hope so. :> I'm trying to read and understand as much as I can from the online resources, but some of them seem to be offline at the moment, and I remember that there was a lot that was too hard for me to grasp without help anyway
<roptat[m]>the difference between these files is not the name but, probably, the kind of structure they contain
<nckx>kabouik: That looks correct! The -E is strictly unnecessary (it's the default on Guix Systems — *not* guaranteed elsewhere), but won't hurt either.
<nckx>What you don't want is its ‘opposite’, ‘sudo -i’ (which is the default on some other distros).
<nckx>But then I doubt you'll be reconfiguring those.
<yarl>I am trying to `guix build -m manifest.scm` with manifest.scm : https://paste.debian.net/1248871/ . This is the same revision the package artanis is using. But the compilation fails here : https://paste.debian.net/1248872/ . If someone have any idea? Did I mess something with the package variant? This is mainly for debugging something in artanis (testing a patch against master, I first try to build against v0.5.1).
<roptat>kabouik, your issue is likely to be related to one of the other channels
<roptat>you'd have to have a look at "zless /var/log/guix/drvs/2q/bc72gzy15dhs97lib1n38a1j6c6ri0-guix-package-cache.drv.bz2" to know a bit more
<rekado_>but it’s what someone decided to move to for the whole data centre, and that’s the last word on it
<rekado_>I think they wanted to have *one* system for every involved party, instead of this incompatible and conflicting mix of ad-hoc PXE servers
<nckx>What I don't understand is: aren't the unbootable entries (Debian fatally can't find a mirror; Ubuntu is missing a trivial kernel argument, then works) unbootable for everyone? Does nobody test them at all then?
<nckx>If you could add "console=ttyS0,115200" to the Ubuntu menuentry, at least (Guix needs it to but as discussed fails later), please do.
<nckx>The Rocky option did not sound half as usable from apteryx' telling of it.
<kabouik>I tried removing the bits that were related to pkill9's channel, but somehow messed with brackets, so I added one back, and then realized that my system.scm uses fhs service which comes from pkill9 too, so I wanted to restore it to its initial stage but I have no tracks of it. I should just have kept the editor open, or just commented things out. Dump mistakes.
<kabouik>That's configuration.scm, not system.scm, which is the one which had pkill9's channel related lines
<kabouik>I've just readded pkill9 channel, but reconfigure still complains about pkill9 services fhs
<nckx>kabouik: There's no way around, either: removing the module import (and all code that depends on it), or adding the channel back so it can be found.
<nckx>I strongly recommend using channels.scm for the latter, but -L could be made to work if you insist.
<nckx>kabouik: Missed your last line. That's ‘impossible’. Did you pull?
<kabouik>"no code for module (pkill9 services fhs)"; I probably just donn't remember exactly what the use-modules line for pkill9 services fhs looked like, and what I added back afterwards might be wrong
<nckx>There is nothing wrong with https://p.teknik.io/Simple/WAljl AFAICT, and use-modules lines aren't magic — pkill9/services/fhs.scm exists and is a valid module, so (pkill9 services fhs) must work.
<nckx>kabouik: So ‘guix describe’ shows the channel, and you're definitely using that same guix binary to reconfigure?
<kabouik>Maybe I just need to guix pull again now that I added pkill9 channel back, before reconfigure
<kabouik>I'm kind of skeptical about my need for pkill9's channel though. As far as I remember from months ago, I initially added it because pkill9 were working towards making appimages work on Guix. Which was not an easy task, and I don't know if they succeeded. I don't quite know what fhs services do, but I think this is the reason they were in my system.scm in the first place. Probably I could just remove all that plain and simple,
<kabouik>but the above experience proves I shouldn't try to be too bold editing my system.scm.
<nckx>Definitely start from a working copy (and back it up!), then iterate from there. You'll get there!
<nckx>guix system reconfigure takes an arbitrary file name, so you don't even have to touch the real one.
<kabouik>So I could copy system.scm to some other test file and reconfigure from it. Any risk of bricking the machine?
<nckx>I suggest checking your entire system configuration into git to keep (1) track of things (2) your sanity.
<nckx>kabouik: Should be slim, especially if you're not touching the bootloader field. As long as you don't GC previous system generations they will be waiting for you in the GRUB menu.
<nckx>There's also ‘guix system vm’, but if your system configuration relies on certain things (hardware, partitions, files) already existing it might not be a realistic test.
<nckx>E.g., it ignores your file-system field and substitutes its own, for reasons which are mostly sensible.
<kabouik>I can't quite escape the dead-end loop yet though, since after restoring pkill9's channel, I end up again in the state where guix pull fails because of python-setuptools; and if I remember the channel, then I can guix pull, but have to remove all related bits in my system.scm, including fhs which I don't quite know what they do, and seem to be deeper in my config (L91 here: https://p.teknik.io/Simple/WAljl).
<kabouik>Now I don't want to bother you with noob issues; I'll try things by myself
<lilyp>for the FHS service, if you're fine with not running appimages (or using patchelf to do so), removing the service should not be too harmful
<kabouik>I'd be fine not running appimages to get back to a clean state at least, and then could iterate from there as I get more familiar with the system and all the things I forgot about how Guix works
<kabouik>Especially if keeping fhs implies keeping a whole extra channel which has roots down to my system.scm, even though I am not able to run appimages with it yet anyway
<kabouik>I'm afraid there may be some I am using without knowing, but I'll just move those I know I want to the packages block (like curl, network-manager, sqlite, xkeyboard-config, ffmpeg, ncurses, freeglut, openssl)
<rekado_>I think it worked for Maxim when we first set this up.
<davidl>Hi! I have emacs-deferred in my EMACSLOADPATH directory but I haven't installed the emacs package directly from guix - is there any way I can use guix gc to find which package(s) in my profile that pulls in that package?
<davidl>I tried --references etc but didnt get any results that I could make sense of
<guixisdown>hello all. does anyone know when guix.gnu.org may be back up ?
<nckx>rekado_: Do I care why the nodes are called 25/29 here rather than 1*?
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | 🚨 We are biting some bullets, most of *.guix.gnu.org is down 🚨 | use https://bugs.gnu.org/NUMBER for bugs/patches | videos: https://guix.gnu.org/blog/tags/talks/ | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<guixisdown>im a very probable future user, was planning a few installs today.. i will be back when things are up and my installs are successful :D thanks irc for being alive :D
<nckx>rekado_: Wow. And here I was flailing around in a fake racadm> shell for hours.
<nckx>apteryx: After recreating /dev/sda2 it mounted fine as vfat, so the signature was not completely wiped.
<rekado_>nckx: the node names without the leading 1 were given out by Madalin when he set up the iDRACs. I had been using the 1* names since the lower numbers were assigned to the old recycled Sun servers.
<rekado_>he renamed the ids in iDRAC but stopped short of adjusting the host names. No idea why.
<nckx>Thanks for satisfying my curiosity (Sun? neat).
<rekado_>yes, actual Sun hardware from the decommissioned first HPC cluster at the MDC.
<kabouik>So I have three different packageX.scm files in my ~/.config/guix-private-channel, a channel that's present in my channels.scm, and yet when I guix search those packages, only one is found (a package I created long ago). I can't find what I did with that .scm files so that it shows in guix search that I wouldn't have done with the others
<kabouik>And with the website being down, I can't find help
<nckx><And with the website being down, I can't find help> logs.guix.gnu.org is up, and bugs.gnu.org has the guix bugs. I can't think of anything else missing?
<nckx>There's nothing to ‘do’ with files, they should just show up.
<nckx>Is it possible to share the channel here or not?
<kabouik>I am not sure of the URL but I remember a very comprehensive subdomain of guix.org where examples are given for new users on how to configure their system and use Guix, that's what I had in mind nckx
<nckx>kabouik: I cannot reproduce this with a (too?) simple git clone URL && guix search -L guix-private-channel nnn-ctx8
<nckx>So it happens only when pull'ed as a channel? That would be strange.
<kabouik>Ok, thanks. I'll try investigating then. Guix is currently working so I'll wait until it finishes
<nckx>I do get ‘error: nspr: unbound variable’ for the third package.
<kabouik>Yeah discord.scm is not from me, I just found the .scm file and wanted to try it. I added it to my own channel after updating the hash, but since I couldn't find it afterwards with my attempts, I didn't try it yet
<nckx>Try removing it and committing (this is git, you can always revert).
<nckx>Having a file that downright won't evaluate won't help matters even if it wouldn't be the cause (I don't know).
<kabouik>Actually, my private channel in channels.scm reads "(url (string-append "file://" (getenv "HOME") "/.config/guix-private-channel"))))" so I thought it would find local files in ~/.config/guix-private-channel, but I just pushed them to a remote to show them to you, and apparently it worked for you. So maybe they need to be pushed to remote before the guix pull sees them even though the channels.scm points to a local folder?
<nckx>kabouik: I should clarify: they worked for me using -L, which is a quick hack. I did not add them to my channels.scm and pull them as a proper channel.
<nckx>But I don't think that was a migration artefact.
<rekado_>it didn’t need to trust itself, because of that huge store.
<rekado_>migrating to just using the cache requires that self-trust configuration.
<tex_milan>hello guix! I am trying to package imhex and it tries to git clone imhex-patterns during its build. the error I get is that git clone is unable to access repository of imhex-patterns. any ideas?
<tex_milan>looks like https is blocked during build of package?
<nckx>Add imhex-patterns as an input, and copy it to the expected location in the build directory in a phase before the build starts.
<podiki[m]>there is no internet access in build environment
<nckx>If the build system still insists on cloning the repo even when it exists, you'll have to patch it not to.
<nckx>Cloning random git repos during builds is, to put it mildly, not allowed.
<tex_milan>thanks for confirmation. i was worried this is the case.
<tex_milan>when defining package, source is specified. can we specify multiple sources? that way i could clone what is needed (to specific folder)?
<podiki[m]>I think you need to look for the add_subdirectory in the cmakelists.txt file and then make sure headers/libraries are found/linked (sometimes you don't need to do more than have them as inputs)
<nckx>rekado_: OK, it's not as weird as I feared. The sucesses were merely cached by nginx. In reality, everything 502s, which is frankly reassuring.
<podiki[m]>better to do as nckx said and use a separate package input and copy the source; you can use multiple origins in the inputs as well
<podiki[m]>libigl is one that came up for multiple origins via inputs
<podiki[m]>good luck! there should be examples of just about anything you want already existing, this type of bundling being very common unfortunately
<tex_milan>thanks podiki[m]! the thing with imhex-patterns is that is it just a folder(s). not project, no cmake, make, anything. it just wanted to be placed to correct folder inside imhex source code.
<podiki[m]>right, so you'll want to copy the source of that input package where it wants it
<podiki[m]>add a phase that does something like (copy-recursively #$(this-package-inputs "inputpkg") "folder")
<tex_milan>perfect, the libigl looks as exactly what I need!
<podiki[m]>taking a quick look, imhex-patterns is sort of "data" for imhex? in which case the additional input origin could be good for that
<podiki[m]>or if it is useful otherwise, a separate package (even if it is just a copy-build-system)
<tex_milan>to me it looks like it is just a "data" from imhex
<podiki[m]>tex_milan: looks like imhex bundles a lot (see the .gitmodules), so you'll need to navigate that eventually (hopefully just deleting all of lib/external and supplying the right inputs will get you somewhere, but may have to tweak the build more)
<KarlJoad>If I want to install a script through Guix, does it make sense to make it a Guile script and build it through a package? Or should packaging the "bash" script work?
<podiki[m]>not sure what you mean, but we do have e.g. python scripts that are packages, no "translation" to guile beyond that
<lilyp>nckx: idk about you, but philosophies are meant to be shared
<nckx>With imported (and possibly totes bogus) percentages as if nothing happened.
<lilyp>nckx: philosophies are like sandwiches, you have to eat through thick bread until you get to the meat
<nckx>That 36 gigabase has me kind of worried though.
<KarlJoad>podiki[m]: I have a shell script that uses guix shell as its shebang. I want to package it into my channel to be installed globally. It is currently located inside the channel. I am wondering if writing a package that uses the script makes more sense than a package that generates a scheme file.
<nckx>lilyp: And nobody wants to eat the crust, even though everyone claims it's good for you.