<apteryx>OK, so it's the chicken and egg problem when the system is BIOS until rebooted, so I can't install GRUB efi <clever>grub also has an install as removable option <clever>there is a special filename, that acts as a default, for when you cant set efi vars <clever>and thats how the firmware is able to efi boot from a usb stick <clever>but nothing stops you from using the same path on an internal disk *acrow vagrantc Waves -- there has been some progress. Can demonstrate later. <nckx>apteryx: There should be a grub-efi-removable-bootloader now. <ben`>Hello! I am trying to run iptables from mcron, but it says "command not found". What's the correct way to find/specify the path within the job? <nckx>vagrantc: Oh no… where now? <nckx>ben`: Something like (string-append … #$iptables "/sbin/iptables" …) if your job is one long string, or (file-append #$iptables "/sbin/iptables") if it's more structured. <nckx>Both within a gexp (#~(something …)). <vagrantc>worked around the bad gateway by preferring bordeaux over ci <nckx>apteryx: Is guix-publish deliberately stopped? <nckx>vagrantc: I don't dare restart it without an answer, sorry. <vagrantc>nckx: no worries ... just introducing someone to guix :) ***jesopo is now known as jess
<apteryx>nckx: I had stopped cuirass, not guix-publish <apteryx>restarted it now, not sure why it was stopped <nckx>Quoth the Shepherd: ‘It is stopped.’ <nckx>OK. Well, it appears to be running now, so thanks. <apteryx>and I will reboot soon, and will have to do the chroot dance <nckx>How went the inode hunting? <apteryx>to reinstall GRUB on the UEFI'd machine <apteryx>I did move disarchive somewhere else which gave me some headroom to play with <apteryx>otherwise I couldn't even run 'guix system init' <apteryx>so at this point the new system has been init'd, but GRUB needs fixing <apteryx>nckx: OK, going to cause some downtime now, I need to reboot the thing, PXE boot into Rocky Linux, chroot onto the new file system, and reconfigure from there <nckx>sneek: Thanks. Botsnack. <apteryx>or would grub-efi-removable-bootloader saves that hassle? <apteryx>can it be installed atop a BIOS system? <nckx>Ah, that explains the centos pastebin. <nckx>I don't know. I just saw folks suggesting --removable earlier. <apteryx>no, that one is when Debian considers I'm a spammer <apteryx>can only be used if /sys/firmware/efi is available, which aint' <apteryx>so seems the chroot is my only friend <nckx>That limitation makes no sense, but it is what it is. <apteryx>I've copied the maintenance onto the new root, here we go <nckx>(Sorry, not really available.) <apteryx>it's fine :-) I have at least 5 hours in front of me *nckx looks at CEST clock <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>oh nice, that Rocky Linux thing is based on RHEL which shunted Btrfs long ago, so no support. <nckx>Can you kexec into something sane? Upload an ISO (should I torrent Windows XP)? What's ‘GuixFarm’-specific about this thing? <nckx>I can understand ‘no $upport’, but really no kernel module? <apteryx>don't know, but last time I tried all the isos in the PXE menu and none could but that thing <nckx>Do we see early boot messages? <nckx>This is insane, but since resources aren't a problem, you could virtualise an entire sane system and expose the drives to that… <nckx>I'm aware of how batty that sounds, but it's not actually a joke… <nckx>Unless early boots logs to serial, how are you even going to debug any other ISO on metal. <apteryx>I'll try my luck again booting a few other isos <nckx>Make sure there's no plan A hiding between them :) <apteryx>hmm... I have an idea. I can chroot into the *old* system, and 'guix system init' anew there. <nckx>But you'll still be using the Rocky kernel. <apteryx>The difference being the system is now in UEFI mode, so hopefully grub install succeeds <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. <apteryx>Probably made by Red Hat for Red Hat <nckx>images/Guix_System_1.3.0/initrd.cpio.gz isn't a file name we ship — is Cobbler what extracts it? <nckx>It is a very strange place to fail. <nckx>I would not be surprised if it failed in our initrd because $assumptions, but (apparently) failing to even load it is very strange. <nckx>(error: no proprietary microcode appended to initrd, refusing to boot for your protection :o) <apteryx>I have no idea about what it works. I thought PXE boot was as simple as putting ISOs in TFTP served directory, and voila <nckx>But then I have no idea what this Cobbler thing is, clearly it's advertised as such a thing. <apteryx>a "deployment server" whatever that means <nckx>I'm guessing the PXE environment doesn't have actual Internet access? <nckx>Otherwise you could try something like netboot.xyz. <nckx>Just to rule out Cobbler as a variable. <apteryx>that's kind of crazy, I thought I had done this before on node 129 (chroot into a Btrfs system) <apteryx>perhaps I can install virt-manager on Rocky Linux and try your idea *apteryx hops back into Rocky Linux 8.5 <trevdev[m]><nckx> "And I don't know the first thing..." <- I packaged them myself, so they are guix packages. I could labor to set up a non-guix gem setup but Ruby's a pain either way <apteryx>nckx: eh, I've been trying to run guix on Rocky Linux, to run qemu, to run guix. Makes sense? <apteryx>the install script ran fine, but the daemon doesn't seem to be happy <apteryx>guix build: error: setting synchronous mode: disk I/O error <apteryx>perhaps because: /dev/mapper/live-rw 5.9G 5.9G 0 100% / <apteryx>can someone produce a relocatable QEMU guix pack and make it available over https? :-) <nckx>apteryx: What's /dev/mapper/live? tmpfs? <apteryx>I'm trying to bind mount /run/gnu onto /gnu and install on it <apteryx>not sure if that's supposed to be possible <apteryx>I don't think so; it's a live image. The internet says no. <apteryx>but I have 100 GiB of tmpfs on /run and /tmp <nckx>I meant the tmpfs, where writes go. <nckx>Weird that it says 5.9G then. *nckx had to reboot because they ran out… of /tmp space. <apteryx>/dev/mapper/live-rw on / type ext4 (rw,noatime,seclabel) <nckx>Oh, should I rename it or can you paste? <apteryx>can we download a latest guix system image from bordeaux? <apteryx>it's currently down for "maintenance" <trevdev>I suppose this includes substitute servers :/ <trevdev>Ah, I keep failing at ci.guix.gnu.org <apteryx>make sure you add the key, and that it's part of your --substitute-urls for guix-daemon <nckx>apteryx: And with qemu-system-x86_64? <apteryx>I think I can't exec anything in tmpfs, although I don't see noexec on mounts <nckx>Can ya mount any real storage that isn't out of inodes? <apteryx>with a dummy bash script I made to test <apteryx>so I'm not sure what's going on, probably the Guix wrapper fails <nckx>I'll build an -R pack since we're here anyway. <nckx>Actually, I'll build a non-relocatable one too. <apteryx>I'll try with GUIX_EXECUTION_ENGINE=proot <apteryx>the default is to use user namespace, perhaps it fails to fall back <apteryx>actually, it's weirder that than: 'find -L gnu/ -name *qemu*' returns nothnig <apteryx>GUIX_EXECUTION_ENGINE=proot didn't help, but gnu/store/gaa1frcj57kkl2bszc24jfh5syxkz45b-qemu-6.2.0R/bin/qemu-x86_64 -> qemu: no user program specified <apteryx>and using the 'R' suffixed store output. I guess if we made a symlink this wrapped variant would have shadowed the non-wrapped one? <apteryx>OK, so I got a working QEMU, the 1.3.0 iso (couldn't find anything newer online)... let's see if the idea can work <apteryx>how to boot from cdrom while exposing /dev/sdi ? So far, I have 'qemu-system-x86_64 -nographic -m 1000 -hda /dev/sdi -cdrom 1.3.0.iso -boot c', but it still attempts to boot hard drive <nckx>-boot c is asking it to. *nckx is building a ‘latest’ image just in case. <apteryx>I think it's just real slow because of the lack of KVM <apteryx>live images often lack it for some reason <nckx>You say ‘reason’ like it means something at this hour. <nckx>I hope you're at least running with SMP. <apteryx>I hope I'm not contributing to your sleep deprivation <apteryx>so, all the action so far is a white cursor on the top left corner <apteryx>I haven't started it in screen so I can't check top in another term, to see if it's working hard toward something <apteryx>outside of when it actively manages your packages, the overhead is mostly disk usage <clarity_>yeah, I might be able to deduplicate most of that... I have a bunch of raspi's and a NAS <apteryx>but updating your package collection will be very slow <nckx>Indeed: overhead in what sense? <apteryx>'guix pull' is already quite demanding on beefy machines <clarity_>nckx, ram usage, cpu usage, disk usage, etc... <clarity_>It's a vague question for sure... I finally got the pi's ready for use, so now, I can focus on using them ;-) <clarity_>I'm doing the kubernetes/k3s container management stuff <nckx>Actually, I take that question back, in that I'm not going to attempt to answer it :) <clarity_>apteryx, I'll play with it a bit and see what I can do <clarity_>the guile scheme aspect of it makes it incredibly attractive *nckx is (very) slowly getting ready to zzz, is all. <trevdev>Is it typical for the REPL (via geiser) to not be able to find most of the modules in the Guix System when eval'ing a buffer? <trevdev>I don't remember having so much trouble REPL'ing my way through scripts/configs in the past. Maybe I've screwed something up <apteryx>nckx: thanks a lot for the help! and good night <nckx>apteryx: Latest ISO in /nuts. As well as alternative QEMU packs you'll never need. <nckx>ISO is from d1c6b8db5a30f9e428d018156dadb12927c485f8. <apteryx>why can't we interrupt bash's autocompletion... it's infuriating (e.g., trying to scan all under /gnu/store/*) <lilyp>I think in zsh you can interrupt it but it still takes some while <paul_j>Good morning all! Is the website down this morning? <lilyp>issues have bee down for a while and ci has been hit too <paul_j>I was aware of this, but the front page website has been up and running. That seems to have changed this morning. <paul_j>(unless of course the issue is somehow local to me - hence the question!) <paul_j>Is there a link to download the liveCD without going through the website? <roptat>(add .sig for the signature file) ***Dynom_ is now known as Guest4927
<raghavgururajan>When the CI broke on 24th, was it only the web front-end or the actual CI process at the back-end or both? <roptat>I don't know about the 24th, but right now, the server itself is down <lilyp>manual rust builds for everyone <roptat>you can still use bordeaux.guix.gnu.org I think? <apis_and_ipas>is the website down? nothing seems to be loading for me as I try to get help with the install issue im having and im realizing that in turn might be the issue im having.. <Guest8>Hi, nothing works (ci.guix.gnu.org) <apis_and_ipas>im having the same issue. didnt get a reply yet, but youve confirmed it for Me <sharlatan>hi, does anyone know what's wrong with issues and main pages? <Guest8>so what seems to work (slow but...) is: git pull + manual building + guix package whatever --no-substitutes <examors>--substitute-urls="bordeaux.guix.gnu.org" is still working for me <Guest8>substitute: guix substitute: error: bordeaux.guix.gnu.org: invalid URI <Guest8>guix package: error: `/gnu/store/b04hv0m31c2wwxbwfld65g0ysvxhsv9y-guix-command substitute' died unexpectedly *Guest8 building the world <PotentialUser-59>are there any packages for easily creating bootable USBs? like unetbootin or balenaetcher, I cant find anything like that <Guest8>(for anyone trying to use guix anyway) <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'
***ChanServ sets mode: -o nckx
<Guest8>what dd command did you use? PotentialUser-59 <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. <nckx>And there's the roptat effect :) <roptat>usually packages are built with GCC, and that GCC was built with mes (actually there's more layers) *nckx is happy; more time to futz with berlin. <roptat>once that GCC is built though, there's no need to rebuild it, it can be used directly to build other packages <Guest99>Okay, understood. The system does the work one time and it saves the work (not doing unneccessary things). <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>well no, because it's already the case <roptat>it's not possible to build a package if you didn't build its dependents, and the bootstrap chain is part of the dependents <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 <blake2b>me and since then I've written the nicest code I ever have in my life. guile never ceases to amaze <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. <yarl>Hello guix! Ah, topic have the answer to my question. <Guest8>If I were to continue building, it would take like 24h to update a guix manifest that more or less containes Emacs and a few other small things <nckx>This is all in the manual. <Guest28>any eta on guix.gnu.org? substitutes only get me so far in the projects i'm working with <Guest8>well, if no substitute is built on bordeaux it's exactly the same <nckx>Don't forget to authorise bordeaux, I don't think it is by default on older installations. <nckx>If you have Guix installed, the docs are always included. <nckx>Guest8: Why do you think no substitutes are built? Debug that. <Guest8>because there is no error message, it says downloading substitutes from bordeaux and then build the world <Guest8>an authorization issue would imply an error message <blake2b>why is it running Ubunutu all of the sudden? <nckx>Please, don't ‘help’ people with ‘of course’ if you're not certain. <nckx>It makes it harder for others. <nckx>It's that or knock-off CentOS. <nckx>I'm not convinced the Guix System ISO supports PXE at all. I certainly don't plan on debugging it for hours. *nckx apt installs guix like a weirdo. <nckx>blake2b: Note that Ubuntu is not installed, and won't be. <Guest8>so it would say 100% with an authorization issue? <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>blake2b: Even if joke, maybe please don't :) Next is somebody taking your ‘move to ubuntu’ out of context & posting it to HN. <nckx>It will be added to ‘the next release’, which will be ‘real soon now’, and has politely been so for months. <blake2b>nckx: you posted above that ci.guix.gnu.org is running Ubuntu, which is what prompted my question <yarl>Hmm, I am unable to compute the right hash using guix hash on a git repo. <nckx>blake2b: It is, but we're not moving to it. It's a rescue system. One of several, but few of them actually boot, because computers hate us and want us to leave. <yarl>when I run guix build -m manifest.scm I got expected hash: 0qah0vyyn9dbx2jcgfq68q3pnffsyg318djchqrnlmrjlx89zmpa <yarl> actual hash: 1w4rdc3w5ann3lkbd6a4idd970ajq6fvsg3x0qgbwklms5zizh67 <nckx>apteryx: So we can boot Ubuntu 22.04 (server), you just need to add "console=ttyS0,115200" which was missing from almost everything but Rocky. I've done that, installed guix, and am now pulling. <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? <nckx>Did you read the ‘pipe’ part? <yarl>hako: Yes. That's what I did. <nckx>You can always paste it by hand & hit C-d. <nckx>blake2b: I am openly discussing it with you. You tend to take things I say in jest & run much farther with them than intended. My bad; I'll stop jesting. <Guest8>but saying something is 100% done when is not is a bug in my humble opinion <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. <blake2b>nckx: I said nothing to imply or suggest that there was. I merely asked a few questions. <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. <nckx>I have Opinions about this having been the right time to do so without having a back-up of the Web site in place, but we're here now, so… <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 reads scrollback <nckx>apteryx: I just finished ‘guix pull’ on a Ubuntu rescue system. <nckx>Reachable from node 129 over SSH. <blake2b>gotcha. I have some experience with the initrd so will browse the debbug and see if there is anything I can dig into there <nckx>apteryx: I feel a great lack of shared notes & docs about the build farm. Painfully. <apteryx>OK! so we're in a live Ubuntu environment where there's latest guix available? <nckx>Your e-mails are great but no substitute. <apteryx>yes, we should have some sysadmin cookbook or something <nckx>Hell, I don't even know which block devices map to what. <nckx>(And ‘I can work it out by looking’ is true but not a substitute. :) <apteryx>nckx: thanks for that. With ubuntu running, I may be able to simply fix the GRUB installation of the system I 'guix system init'd on /dev/sdi2 yesterday <apteryx>which is a 100 TB Btrfs partition on the SAN <nckx>OK. Let me encrypt to you the deets. <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>see commit ea45260 / branch wip-san-migration <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). <nckx>There are a few long-standing issues like that with berlin that just happened to interlock in a way that was very hard to fix, especially whilst trying to keep providing service. <nckx>So this downtime wasn't planned, but it might get rid of one and untangle the rest? We'll see. <nckx>Next time, though, we should (1) plan it and (2) set up the world's puniest VPS to serve guix.gnu.org with a banner telling user's what's going on. <nckx>‘nckx sets the #guix topic’ was supposed to be a silly cope, once, not the standard procedure. <nckx>I'm running out of loud emojis. <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_>If I change something in my ~/.config/guix/system.scm (namely to add bluetooth-service), the command to take it into account is `sudo -E guix reconfigure ~/.config/guix/system.scm`, correct? ***Kabouik_ is now known as kabouik
<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. <hako>it's just to "describle" your system <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. <kabouik>I admit I'm down to not even remembering why reconfigure requires sudo and not other guix commands; I assume it's because reconfiguring is a system action <nckx>Really only to install the boot loader & restart services at the very end. <nckx>‘$ guix system reconfigure’ will do 99.9% of the meat just fine, then error out. <kabouik>I see; so I added bluetooth-service in my system.scm, I'll reconfigure with that, but before I do, I may have to fix an issue I'm getting with guix pull <kabouik>Oh, good to know. Was it down yesterday as well? I've gotten that issue last night. <nckx>kabouik: Also make sure this key is in your /etc/guix/acl, otherwise pipe (important) it into ‘sudo guix archive --authorize’. <nckx>kabouik: Yeah, something like that, unfort. <kabouik>I didn't quite get what I need to do with the key you mentioned, sorry <nckx>Easiest is to run ‘sudo guix archive --authorize’ <kabouik>I had curl installed, did that, thanks <nckx>I just realised somebody will find this in the logs and try to paste that URL into their terminal. I meant, of course, to write ‘the contents of’. <nckx>You should see some downloads, at least. <nckx>(Guix pull is substitutable.) *nckx AFK, sorry, good luck. <kabouik>Seems it hasn't even tried to fetch from bordeaux.guix.gnu.org, I'll try again with the quotes. <yarl>14:53 <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 <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 <yarl>This is also to become more familiar with guix package definitions. <roptat>kabouik, one of your channels is using python-setuptools-scm, which doesn't exist anymore, but I can't tell more than that, because guix is not very verbose about the issue :/ <yarl>If someone could just double check that the manifest can't compile for them too? I would really appreciate. <kabouik>I can look locally into my channels, I only have 4, but I don't know which subdirs to check to see what packages they're listing <roptat>kabouik, "grep -r python-setuptools-scm" <roptat>yarl, same error, which is to be expected :) <roptat>so you'd have to ping pkill9, so they know they have something to fix :) <roptat>yarl, the guix package has a long snippet that your package does not execute <roptat>you could inherit the source field: (source (origin (inherit (package-source artanis)) ...)) <yarl>roptat: I didn't understand that it worked like this. Thank you a lot! <kabouik>Hum? guix: reconfigure: command not found <rekado_>nckx apteryx thanks for working on the migration! *rekado_ is back for a few minutes <nckx>rekado_: I'm about to start debugging GRUB again, in an equally few minutes. <rekado_>re PXE: I’ve struggled for a long time with PXE boot when first installing the build farm and when reinstalling it on new nodes. It doesn’t work without some work on the initrd. <rekado_>and yes, this cobbler thing is infuriating <nckx>I do not believe the Guix images as they are can even work. <rekado_>the weird location of the initrd and kernel is a mix of where the ISO contents are unpacked on that cobbler server and some prefix <nckx>I was about to write the Guix ISO's partition to a physical one but booted Ubuntu instead. It worked. <nckx>rekado_: Is that all automated? <rekado_>and it’s *not* documented well at all <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. <nckx>That's the only answer I would have believed :) <rekado_>after the migration from PXE nobody had a need to install any servers; except for the Rocky servers, which is why that image appears to work fine — for a Rocky installation. <kabouik>Hey I think I've broken my system.scm and I have no backup. :') <nckx>Not even in your editor's undo tree? <rekado_>kabouik: there might be a configuration.scm in /gnu/store <rekado_>or /run/current-system/configuration.scm <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 <Cairn>How about you throw it in a pastebin here? <Cairn>I'm also getting the same bug as #56836 when I `guix pull`. Could that be related? <nckx>kabouik: Does ‘guix describe’ list the pkill9 channel? <kabouik>It doesn't, I actually removed it from my channels because of this python-setuptools issue <kabouik>So I wanted to sanitize my system.scm accordingly, then realized there's fhs in the system.scm, and got scared by the rabbit hole <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 <nckx>Hence 30 Jul 18:08:42<nckx> kabouik: Missed your last line. That's ‘impossible’. Did you pull? <nckx>When in doubt, pull something. <kabouik>Oh, I missed that message nckx, I'm sorry. <nckx>That's why ‘guix describe’ is a good sanity check. <nckx>It shows what is, not what could have been. <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 <nckx>No more sessions are available for this type of connection! <nckx>Connection to 141.80.167.225 closed. <lilyp>building webkit atm, no memory left to open tabs ^^" <kabouik>Well no anyway, that's not quite that simple, I forgot a lot of fhs-related stuff on L28 :\ <kabouik>Should all these packages move to the block starting L67 with new "specification->package" lines? <lilyp>kabouik: probably no, you only want to provide essential packages on an OS level <lilyp>none of the packages in fhs-packages seem to be stuff you'd normally need (and those which you do need are already propagated by other packages for... reasons) <kabouik>Trying to understand how they ended up in my file in the first place. I'm looking at pkill9's configs, I probably copied that block from their config. <kabouik>So removing the whole block L27 would be essentially fine according to you lilyp? There may be some other packages I would like to keep, but I can just move them to the block L67 I guess. <lilyp>imho there's no point in declaring variables you don't use <lilyp>and you do have a git backup, so... <rekado_>nckx: user ‘guix’ has four active SSH sessions on the iDRAC. <nckx>apteryx won't be back for 12h, I don't think they expect any to remain. Sounds good. <rekado_>nckx: login times: 01:44:21, 04:58:43, 05:02:16, and 14:44:44 <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) <nckx>The 0* ones sound bogus, rekado_. Idle(?) SSH connections are dropped after a time (MDC firewall rule?); it seems like they are not cleaned up by iDRAC? That's bad. <rekado_>okay, I’ll kill the 0* sessions, too <nckx>rekado_: There's no way we can do that without you, right? <rekado_>visit the iDRAC IP in a browser; you will need to tunnel your connection through node 129. <rekado_>if you can log in there it’s ‘iDRAC settings…’ -> Users -> Sessions <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 ? <Ox151>just a sanity check, is ci.guix.gnu.org down? <nckx>Ox151: You should get an entry message when you enter the channel, as well as the channel topic. <Ox151>nvm the topic says guix.gnu.org is <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>Did you use define-public, for example? <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>I am genuinely unsure of what you mean. <nckx>It wasn't the cookbook, was it? <nckx>That's installed locally as ‘info guix-cookbook’, or whatever info viewer you prefer. <nckx>You may not like the formatting, but it's a far cry from being helpless in a storm :* <kabouik>Oh, that's actually nice. I didn't know about it. <nckx>OK, berlin is up, but that's about as far as it goes. <nckx>It smells odd and wants brains. 🤔 <nckx>Also, no fancy services like ‘a Web site’ for you, sorry. <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>Local file:// URLs are fine. I use them. <kabouik>My guix system reconfigure is still ongoing, so I don't think I can do much before it ends <nckx>You can still change your channel configuration & pull & test. <nckx>No need to wait for guix system reconfigure. <badc0dec>I wish "guix shell -D emacs" would actually check out the source and version and prepare the dir <lilyp>the reason it doesn't is because that way you can also use your modified emacs branch <nckx>There is such a thing as too much magic. <badc0dec>well guix seems to know where the source is, for when you use no-substitutes, it just tries really hard to hide it from us <badc0dec>so before using guix shell one has to go on a quest for finding the right source, anyway <nckx>that never before in the history of mouse or man has anyone been so beyond themselves with joy to see a 404. <nckx>badc0dec: WDYM? Does ‘guix build -S’ not work here? <badc0dec>nckx: it's possible that my workflow is wrong, but I end up using "guix shell -D emacs" to see what needs to be modified and written in the (package) build script <atka>nckx: I take it as good news then? sometime over the night there wasn't even a route to host? <nckx>Yes, it's come such a very long way. I am very proud of it. <nckx>badc0dec: There are few wrong workflows, although I don't immediately follow yours. <nckx>Hmm, DNS is broken on berlin. <nckx>static-networking-service didn't create /etc/resolv.conf for whatever reason (I will not debug this now). <nckx>Now we're building binutils & glibc to build the Web site 👍 <nckx>Oh, and 2 versions of GCC. Gotta have 2 versions of GCC. <nckx>When Guix works — and it often does! — it's pretty hot-darn awesome. <atka>nckx: guix.gnu.org is a haunt site yes? <badc0dec>was just thinking about that, to bump default gcc or not, as I needed libgccjit to add --with-native-compilation to emacs <badc0dec>it still needs patches for emacs to use libgccjit for whatever reason <badc0dec>that's why I had to whine a bit about guix shell, looking up the sources for everything is meh <nckx>I'd heard something about that. <badc0dec>I'm sure it will be fine, it's just an itch since I use Emacs EXWM as my desktop, no need *nckx uses native-comp from the flatwhatson channel, as several others do. <nckx>Works for me! Although I don't use EXWM. <nckx>ci.guix.gnu.org should work for substitution. ***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | https://guix.gnu.org | 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
***jesopo is now known as jess
<KarlJoad>Say I have a bash script in my repository that is also my channel. How should I write the source/origin field to refer to a file local to the channel? Or is this just back practice? <rekado_>nckx: is ci.guix.gnu.org not using itself for substitutes? <rekado_>we did copy the substitute cache, didn’t we? <nckx>rekado_: What we did not do, is copy the signing key. <rekado_>we did do that in previous attempts. Pity. <nckx>rekado_: Berlin is also not set up to trust itself. <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. <podiki[m]>sometimes packages will have cmake submodules that will try to do something similar <tex_milan>recently cmake allows you to specify its inputs and do such stuff (like clonig things and gathering build dependencies)... yes. <podiki[m]>yes, they have their own recipe thing, forget what it is called <podiki[m]>i've had to patch around it, could find some examples if that is helpful tex_milan <tex_milan>me as old C++ guy I actually liked that cmake allows it. on platforms without default package managements (yes, Windows) it is handy <nckx>And it breaks (punishes) platforms that don't suck. <nckx>podiki[m]: So it doesn't even behave if the directory already exists? <podiki[m]>I believe there is some lines to tweak in the cmakelists, so it doesn't try to use a submodule <tex_milan>it probably will, it has IMHEX_OFFLINE_BUILD switch in function that does the clone <nckx>rekado_: What needs to be copied/created to make the cache work? It's all 502s. <podiki[m]>good packages will have some USE_SYSTEM_LIBNAME option.... <podiki[m]>yeah, look for any cmake options first before trying to hack around it <nckx>rekado_: Actually, not all, only some, which is somehow worse. <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]>so I would go with that for now (easy enough), see that it works, and then can see from there <podiki[m]>my philosophy is always to get something working first, and then iterate from there <nckx>No stealing others' philosophy; find your own. *nckx 's kingdom for ‘something working’ ATM. <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>You're thinking of sandwiches. <nckx>You may notices that the specs are missing, which is bad. <Cairn>Were they up for a second? ci.guix.gnu.org is still down for me <nckx>…momentarily down because I need to copy 36G(!) of Postgres database. <Cairn>Cool! Looking forward to seeing the issue tracker again <nckx>Copy is averaging about 40MiB/s, for whatever reason. <nckx>Cairn: TBH that's last on the list for me, bugs.gnu.org being a homely but functional fallback. <nckx>I think the Web site's almost back. <Cairn>No, that makes sense. It was just the first thing I noticed was down. <podiki[m]>issues was back up yesterday(?) at some point <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. <nckx>It wasn't even deliberate, although I didn't backspace it either. <nckx>But yeh, not very scalable :-/ <podiki[m]>KarlJoad: I see. hmm, not sure what is more "guixy" <nckx>(I think somebody unironically complained about Cuirass not using Sqlite?) <Cairn>What might be the solution to the db, do you think? (just curious, since I don't know much about dbs)