<nckx>I don't think outputs are appropriate for that (you're not ‘doing the work anyway’; the font-foo:nerd output would be unaffiliated with and possibly not even endorsed by the font-foo authors; etc.) <nckx>But separate nerdified packages could. <apteryx>lilyp: re "reload subdirs"; how do I actually do that? <apteryx>the breakage in the past was not due to being able to reload things, but because the EMACSLOADPATH path was versioned; when bumping Emacs version say from 27 to 28 it would persist at 27 until a user relogged in <apteryx>but I'm still not satisfied: I want the login manager screen to be shown when I connect to the VNC server, so that I could choose one or another type of session, a different user, etc. <lilyp>apteryx: I think in eshell it might just be "load subdirs", but in general if you (load "$GUIX_PROFILE/share/emacs/site-lisp/subdirs.el") you get the new directories pushed to the front of your load-path. <itd_>Hi. I'd like to use GUIX_PACKAGE_PATH with 'guix import json' but end up with 'no code for module' (while 'guix search' works). E.g., I'd like the imported package to depend on 'my-foo-bar': https://paste.debian.net/hidden/e989e482/ Where's my mistake? Thanks! <yuu[m]>i'm trying to set EFISTUB with efibootmgr so no need for GRUB, ... what to put for `--loader` (the vmlinux/vmlinuz? and `initrd=`? <yuu[m]>is grub really a requirement for Guix? <unmatched-paren>it's probably required, since guix remakes the grub.cfg every reconfigure <nckx>It's also 'cross-platform', and doesn't require copying the kernel. <unmatched-paren>Oh, yeah, I forgot it was possible to switch the bootloader in the operating-system. <unmatched-paren>Okay, then, I suppose it might be possible to add support for efibootmgr? <nckx>If somebody contributes patches for UEFI rootki^Wboot support, sure, but it's hardly a killer feature otherwise. <nckx>Don't forget to add EFI_STUB to our kernels if so. *unmatched-paren looked at Linux's EFISTUB docs, and is now unable to unsee those path backslashes :S <yuu[m]>unmatched-paren: yeah that what i hoped, that generations would be listed there just fine. i think grub is more complex than it should be... but if there's no support, guess i'll move on for now. <yuu[m]>> * <@unmatched-paren:libera.chat> looked at Linux's EFISTUB docs, and is now unable to unsee those path backslashes :S <yuu[m]>the backslash is a requirement by the efi standard <yuu[m]>it's not like i think unix systems are good anyway. what did lisp machines used? <unmatched-paren>yuu[m]: Oh, yeah, it's certainly overengineered. Like gcc and coreutils and glibc and possible linux and ... <nckx>From a distro & support perspective, getting out of the buggy UEFI mess as soon as we can into something consistent is a feature. <nckx>The more I think about it the less I see the point of supporting alternative x86 bootloaders when GRUB works perfectly fine across all of them. <muradm>nckx: fox x86 agree, however having something less complex and minimal like systemd-boot for uefi only (since it is majority) would be nice <yuu[m]>unmatched-paren nckx i like grub only for bios. muradm on nixos i use uefi systemd-boot and it's pretty nice and simple <muradm>few weeks back had to switch back to lenovo carbon x1, and yesterday again faced that issue with nvram <muradm>guix system reconfigure always touches nvram <muradm>and --no-bootloader is not very helpfull, since after reboot old profile is getting loaded <muradm>eventually after some reboot, one gets surprized with old kernel :D <nckx>I didn't mean --no-bootloader, I meant using a no-op (const #t) ‘bootloader’ value. <muradm>nckx: (operating-system (bootloader #f))? <nckx>I.e. (installer #~(const #t)) <ncbfg36>I'm trying to build a software package that requires ogg vorbis. I installed libogg and libvorbis. The other dependency mentioned in the configure script is "libvorbisfile" however i cannot find anything like this in package repositories. Is there an alternately named guix package that will satisfy the dependency? <nckx>ncbfg36: ‘libvorbisfile’ is the name of the library, ‘libvorbis’ the name of the package. <unmatched-paren>ncbfg36: `ls (guix build libvorbis)` shows that libvorbis provides libvorbisfile.so <nckx>The configure script isn't talking about packages or is subtly wrong. <ncbfg36>ahh that makes sense. Yes it mentions all three so I was confused <nckx>unmatched-paren: You broke my Schemebrain parsing that until I realised the missing $. <ncbfg36>now i just need to figure out why it can't find it <nckx>What's fish for () then? <nckx>Just group commands together, for lack of a better explanation. <nckx>( echo hi; echo ho ) | less <nckx>But! It's not quite {} which is also supported, but doesn't spawn a subshell. <nckx>I guess the subshell is the difference but I'm not 100% sure. <nckx>ncbfg36: Sorry to ask the obvious, but: you do have pkg-config in native-inputs, right? <muradm>nckx: what is the difference between (installer #~(const #f)) and --no-bootloader? <ncbfg36>nckx: Not at all considering I don't know what that means :-/ <nckx>muradm: You said --no-bootloader didn't update the list of generations. <nckx>I know only that (installer …) definitely does update grub.cfg. <nckx>ncbfg36: Ah, problem (probably solved). <nckx>pkg-config is a build tool to help packages find each other. <unmatched-paren>it reads those .pc files and outputs compiler flags for gcc/clang to use <unmatched-paren>e.g. for libvorbis, pkg-config --libs --cflags vorbis might output `-lvorbis -L/gnu/store/.../lib -I/gnu/store/.../include` <nckx>They are quite readable text files, taking a look at vorbisfile.pc will probably make it clear what they do. <unmatched-paren>--libs outputs the linker flags (-l, -L) and --cflags outputs the compiler flags (-I) <unmatched-paren>and it will also output the necessary flags for any dependencies of the libraries <nckx>In the dark old days before pkg-config, each user of library foo either just carried a copy of the flags it thought foo needed (fun! tens of subtly differing packages going slowly out of sync!) or used an ad-hoc FOO-config binary installed by the foo library (sic) which was also pretty yuck. The latter have almost vanished but they still exist in the wild. <nckx>There were other approaches but you get the gist. <ncbfg36>so pkg-config is a package i need to have installed <nckx>No, just add it to native-inputs. <nckx>Like gcc-toolchain etc: don't install it unless you build from source a lot. <muradm>nckx: https://paste.rs/L5S this seems to work as you say, thanks.. but that means i have to edit configuration whenever i really should do install <ncbfg36>Forgive me but what is native inputs? You mentioned some lisp code but i'm not sure where I would input that <nckx>ncbfg36: But after your third package it will become a habit: ‘error: can't find libfoo’ — but libfoo is in inputs? Oh, I'll try adding pkg-config. <nckx>ncbfg36: A (package …) field. <nckx>You're not writing a package are you. <nckx>Then install it, I guess, but building from source by hand is often more trouble than writing a package. <ncbfg36>So I should be doing it differently on Guix? <nckx>unmatched-paren: Agreed, but then you either keep adding subshells for each new package you realise you need (not the end of the world) or you might accidentally exit your shell where you just spent time setting some precious variables. <ncbfg36>hmmm that shell env it still claims vorbis isn't installed <nckx>muradm: Yes. But that's once in the lifetime of the machine, so not a big deal. <nckx>ncbfg36: Which package is this? (Sorry if you said — I can't find it.) <rekado>apteryx: node 129 is now connected to the management network. I manually assigned an IP on that network to eno4 (consider doing that in maintenance.git). <rekado>you can SSH to .167.225 (iDRAC for ci.guix.gnu.org) from there <rekado>I’ll be out for the rest of the day; hope it’ll work all right for you <unmatched-paren>muradm: umm, (bootloader (bootloader-configuration (bootloader (bootloader? :D <ncbfg36>nckx: oh the package the build depends on is libvorbis <nckx>ncbfg36: Exult was the answer I was looking for. Thanks! <unmatched-paren>"For security, the Guix boot process now goes through four bootloaders before launching Linux." <nckx>Say what you will of Sourceforge's past sins, but I know few sites with a cookie dialogue that has ′I refuse’ right next to ‘accept’ and just respects that in a single click. <ncbfg36>haha yes. And the site is usable in text mode browser <nckx>I guess they learnt a lesson (I'm aware that current management is probably not the same one that did the baddies, but still). <ncbfg36>unmatched-paren: that didn't work either <muradm>unmatched-paren: yeah, verbose, the first thing in manual mentioned about bootloader configuration ) <nckx>guix shell pkg-config libvorbis automake autoconf libtool gettext gcc-toolchain sdl2 ; I get an error, but it's not libvorbis-related <fiesh>nckx: you should give i-dont-care-about-cookies (firefox / icecat plugin) a shot if these dialogs bother you <nckx>It rejects all cookies by default? <unmatched-paren>muradm: (call-with-output-file (lambda (file) (display (string-append "I'm afraid Scheme " "is often quite verbose") file))) <fiesh>it gets rid of the dialog and tries to accept "necessary" ones -- but rejecting cookies is a browser setting that doesn't require any plugin I think <fiesh>(yeah you can just disable all cookies in firefox / icecat) <ncbfg36>unmatched-paren: yes I typed it exactly as you did. I also tried what you did nckx amd it still throws an error about must have ogg/vorbis installed <nckx>I think I'll keep manually deciding but thanks for the tip. <unmatched-paren>ncbfg36: I wonder what it's trying to find to confirm that vorbis is installed <fiesh>but then I'd still use the browser to selectively whitelist... these dialogs are a horrible solution from both a technical and a usability point of view <nckx>Vorbis......................: 1.3.7 <nckx>Now type 'make' to build Exult <nckx>This is just my ‘guix shell’ with freetype and (I'm an idiot) make added. <muradm>unmatched-paren: every language has 5 beautiful and 95 ugly verbose of 100 features ) <nckx>In my defense I think it's been actual years since I built a package by hand. <nckx>If the ‘missing vorbis’ error happens during ‘make’, the build system's just bugsy. <muradm>yesterday i tried to add bash-completion, do i have to do extra thing in my .bashrc to enable them? <nckx>Adding it to your system packages should suffice. Installing it, maybe, haven't tested that myself. <nckx>I'm also assuming you're using Guix System and it's merry band of default ~/.bashrc et al. <muradm>nckx: yes definetely guix system :D not system but in profile manifest, should be system? .bashrc is not default, but it sources /etc/bashrc <nckx>I don't think it ‘should’ be a system package, but that's the only configuration I use and can vouch for. <nckx>Soni… Please never place that image into my brain again. <nckx>"syntax error near unexpected token `OGG," is the real error. <nckx>This works for me (it's still building): <nckx>guix shell --pure pkg-config libvorbis automake autoconf libtool gettext gcc-toolchain sdl2 coreutils make freetype bash grep findutils sed gawk diffutils flex bison -- bash -c "./autogen.sh && ./configure && make -j $(nproc)" <nckx>There might even be an unnecessary package or two in there — I threw in things likely to be needed. <ncbfg36>unmatched-paren: haha yes i'm getting that impression <nckx>I'm not sure what caused your error, but it wasn't libvorbis/pkg-config. <ncbfg36>so "guix shell things" sets up a self contained subshell with a specific toolset? <unmatched-paren>ncbfg36: it's actually quite easy: you pick an appropriate gnu/packages/whatever.scm, add a public variable for the package (define-public pkg ...) which is bound to a package record <nckx>Without --pure, your current environment (installed packages) still bleeds through, with --pure it is really self-contained. There's also a container option, but that's overkill here. <nckx>That said, proper Guix packages are built in a container, so you might have to solve a few more puzzles there (no $HOME, etc.) But shouldn't be major. <ncbfg36>ahh okay. And i'd add the toolchain as dependencies in the packages .scm config <nckx>ncbfg36: It built successfully. <unmatched-paren>you'll need a name (string), version (string), build-system (something like gnu-build-system {which is what you want here, because autotools} or python-build-system), a source (usually an origin record that points to a file or git repo on the internet) <unmatched-paren>ncbfg36: The toolchain is automatically included by the gnu-build-system <nckx>ncbfg36: There are a few things you don't need to add, and gcc-toolchain is one of them. <nckx>So is make, and a few others. <nckx>auto* and gettext-minimal aren't, actually, I don't think. <nckx>ncbfg36: I'd start with an empty list of inputs and native-inputs (there are those words again —you'll learn what they are when you start packaging), and only add things as needed. <nckx>It will be a subset of what I gave above. <unmatched-paren>you also need a (description), (synopsis), (home-page), and (license) <nckx>unmatched-paren: Because we used to bootstrap far, far fewer packages from git than we do now. <nckx>Waiter these raisins are hysterical. <ncbfg36>hmmm cool I suppose that will be my next learning experience *unmatched-paren goes to find a reasonable, sane gnu-build-system package <unmatched-paren>Hmm, clamav is a gnu-build-system package, but it's got phases and patches <nckx>And you don't want those? Hello is minimal. <nckx>Doesn't have inputs, but that's easy to explain. <nckx>I'll say because it's often ‘too simple’ if you want to illustrate a particular technique :) <nckx>It's a good minimal template though. <nckx>Yeah, hello being in ‘base’ is counterintuitive (probable raisin detected). <unmatched-paren>Hello is a core component of any self-respecting Linux user's workflow, so it makes sense to me :) <nckx>(package (name "hex0") … (inputs (list hello))) <nckx>Truly a ‘hello world’ worthy of the name. <ncbfg36>The man pages for "true" and "false" still make me laugh... "does nothing, successfully" and "does nothing, unsucessfully" respectively <nckx>Is there a way to search inside the current bash/readline line? Like C-r, but horizontally? <nckx>I know about C-x C-e but it's a bit heavyweight when in a flow. <ncbfg36>sorry so where would I find the hello .scm? All I found is the .tar.gz from guix packages directory <nckx>Read-only: guix edit hello (yes, sic, ‘edit’) <antipode>ncfbfg36: use "guix show hello" to find the location <nckx>guix edit basically does that but spawns your $EDITOR for you. <ncbfg36>OH it's literally in base.scm. I get it <nckx>The source of all Guix packages is on your machine, right now. <antipode>It's usually read-only though, with some exceptions like "./pre-inst-env guix edit hello" <antipode>nckx: Is a copy of the antiox channel specification publicly available? <antipode>I'd like to setup a local cuirass instance. <ncbfg36>hmmm I am still learning to grasp fundamental concepts here. I am used to just installing packages to do things amd occasionally editing config files. That's why I switched to guix, to learn to actually control my computer. I get bogged dowm in details and don't fully understand documentation often. I'll have to come back to this. Right now I meed to do a month's worth of reading before tomorrows res school <ncbfg36>haha. I appreciate this channel you are all unusually friendly and helpful :-) <antipode>I was looking for something to put in config.scm actually. <nckx>I know, but that's all I can give you without ssh or writing it myself. <nckx>ncbfg36: Take it slowly, we'll be here whenever :) Packaging is relatively rare, not a daily part of managing your computer. At least after the initial burst of packaging things you miss in Guix. <jonsger[m]>antipode: I can send you an example of stuff like this done in the config.scm as this is possible with cuirass as well... *antipode runs "guix system reconfigure" ***wielaard is now known as mjw
<nckx>apteryx, rekado: Does node 129 have its own set of authorised SSH keys? I can't get in. <apteryx>it uses the admins as defined in the berlin-new-build-machine-os <ns12>Okay. Wanted to ask: can I send an email to a closed bug report? <ns12>For example, I may have some relevant information to add to a bug report that was closed. <antipode>ns12: You can, but you might receive an e-mail about 'unarchiving' it first if it has been closed a long time. <ns12>antipode: Does the bug report remain closed after I send an email to it? <ns12>No, I do not wish to reopen. I just want to provide highly relevant information for future reference. <apteryx>nckx: I could easily add you to it via 'guix deploy', if berlin was up and running (only berlin key is authorized) I can still add you in a manual hacky fashion if you need. <nckx>‘Need’'s a big word, if you're on it. I don't really have a plan. I've never used this before. <nckx>Thanks for the ping, I missed your previous repyl. <nckx>Since the current state isn't *that* degraded, I'd rather someone with more experience take care of things. OTOH, I'd love to learn how this stuff works. <nckx>E.g., is it possible to get a serial console login on berlin? <antipode>(worked around it for now with a manual "guix build /gnu/store/[something libsoup]) <nckx>Assuming aggety's not broken too. <apteryx>nckx: the serial console can be obtained from iDRAC, which lives on a network that only Berlin currently can reach into <apteryx>so with Berlin being inaccessible it's not possible currently <apteryx>the plan is to have node 129 also able to reach the iDRAC network (which needs some manual cable shuffling at the data center) to have a usable fallback when berlin is unreachable like now <nckx>apteryx: Hm. Did I misread Ricardo's message then: ‘node 129 is now connected to the management network. I manually assigned an IP on that network to eno4 (consider doing that in maintenance.git).‘ <nckx>I thought this was that. <apteryx>ah, then I haven't caught up with my emails yet <nckx>It's in the scrollback here. <nckx>No rush, if you have limited time please get berlin up first. <nckx>Also no sure if ‘consider doing that’ is understatement for ‘if you reboot sooner, you're screwed’. <antipode>Are "error: substituter started" actual errors? <muradm>giving up.. bash completions from packages defined in manifest seems to never get loaded <muradm>but why? what it will do differently? <antipode>For search paths. Except there is no relevant search path defined for bash. <antipode>Or maybe bash looks for bash completions in a directory based on where 'bash' was run for <antipode>so if it's in /run/current-system/profile/bin/bash, maybe it looks in /run/current-system/profile/share/..., and not in $GUIX_ENVIRONMENT (speculation)? <nckx>It just makes general sense to add bash to the profile you're testing bash-completions from. <muradm>when i build profile, it suggests to source $GUIX_PROFILE/etc/profile, right? <muradm>suppose it is under ~/.cache/guix-extra-profiles/desktop <muradm>i digged everything i could, but i didn't find where would $GUIX_PROFILE/etc/bash_completion.d/* be read/sourced <muradm>i.e. what is under ~/.cache/guix-extra-profiles/desktop/etc/bash-completion.d/(git|pass|etc.) never get sourced <muradm>and most weird thing is, if i do source ~/.cache/guix-extra-profiles/desktop/etc/bash-completion.d/git in terminal, it gets initialed, and completions for git starts working <apteryx>muradm: it's because of the way search path specification (the mechanism setting environment variables) works in Guix <muradm>but if i do same in my .bashrc it does not (face palm) <apteryx>it's profile based, and the consumer application has the search path defined on them <apteryx>so if you 'guix edit bash' you'll set it has a search path specification defined for BASH_LOADABLES_PATH <apteryx>actually I'm not sure that has anything to do with completions <apteryx>nckx: I'm reconfiguring node 129 locally (guix system reconfigure) with you added as sysadmin to it <apteryx>(locally meaning on the machine itself) <muradm>apteryx: no i don't get what is the relation between BASH_LOADABLES_PATH and completions <muradm>apterix: /run/current-system/profile/etc/profile.d/bash_completion.sh this <muradm>apteryx: ~/.cache/guix-extra-profiles/desktop/etc/profile.d/bash_completion.sh and this <muradm>no script does look for ~/.cache/guix-extra-profiles/desktop/etc/bash_completion.d/ <antipode>Nevermind, seems like I just needed to be more patient <muradm>i would expect that ~/.cache/guix-extra-profiles/desktop/etc/profile.d/bash_completion.sh would be different <muradm>also this if [ -n "${BASH_VERSION-}" -a -n "${PS1-}" -a -z "${BASH_COMPLETION_VERSINFO-}" ]; then <apteryx>muradm: ah, it seems hard-coded (via a custom patch) to look into your user profile <apteryx>git show 16629c8adf90db559a32b7a2c5ec8a94be7ef7ba <muradm>does not give a chance to it second time at all, so once /etc/bashrc does bash_completion.sh with things seen from system, it is done <apteryx>probably Bash has no native means to locate completions via environment variables <apteryx>if we could contribute an upstream patch adding that, then we could unlock completions for arbitrary guix profiles <apteryx>muradm: perhaps you could report an issue for that if here isn't one already, so we don't forget it <apteryx>nckx: re reconfiguring, it's taking some time, thanks to 'guix pull' <singpolyma>Could use crazy hacks to overlay the profile paths onto / <nckx>apteryx: OK. I have to go AFK a while now. Good luck in the meantime. <muradm>apteryx: i don't think that bash ever looks for completions anywhere <muradm>they should be source <completion_script> <muradm>basically bash-completion package is a collection of some common completions, and it is getting initalized by sourcing bash-compltion.sh <muradm>which inturns sources completions from package <muradm>and may be it the only possibly correct way <apteryx>muradm: ah, that bash-completion-directories.patch is not applied to bash but to 'bash-completion' <muradm>git-prompt.sh from contrib is not in git package *apteryx clearly apteryx has never carefully studied how bash completion works <apteryx>nckx: fun, guix reconfigure fails building /gnu/store/dq0fxxifcmrj21l753pb28z4997m8xzs-guix-1.3.0-23.a27e47f.drv on node 129 <nckx>muradm: contrib/ is special and not intended to be installed as part of ‘git’ — they aren't maintained as such and the whole point is that these things need more work before they graduate. I would not expect any distro to treat them otherwise. You could submit a :contrib output though, and it might be accepted if there's sufficient interest. <apteryx>I thought that'd only happen in non isolated builds of guix <apteryx>I'll pull to the commit the system is currently configured with, hoping to get substitutes <muradm>nckx: will take another year to pop from my todo to patch, and another year to repo :D <nckx>Sold. I'll put your promise in my calendar. <apteryx>nckx: hydra-guix-129 reconfigured! could you test ssh access? <apteryx>rekado: I confirm I can now access iDRAC of berlin via node 129, thanks! <nckx>Of course *now* I don't have time, but thanks again! <clever>apteryx: the last time i had to deal with iDRAC, it used activex!!, and needed both a win-xp and a win-7 machine, lol <clever>the remote desktop feature only worked under win-7 <clever>the remove cdrom feature (to boot from a .iso on the local machine) only worked on win xp <clever>but xp cant download jack, because its ssl support is too old <clever>so it was a major pain to even get the iso into the xp vm! <apteryx>rekado, nckx sent a mail to sysadmins about recent reconfiguration of node 129 <muradm>stackoverflow et all seems to experience global problems... <fiesh>despite running on Windows :/ *apteryx supposes microsoft must be looking to by buy stackoverflow anytime soon <apteryx>rekado: how long does 'resetting iDRAC' usually takes? <apteryx>nevermind, it's back on. takes a few minutes apparently <clever>at that same datacenter, i ran into problems with their shared virtual hosting, the network was configured in a radically different way, and i locked myself out of the vm <nckx>I wonder if we can boot ISOs without spinning up NT for Workgroups. <clever>when i asked for a screenshot of the boot error, i got a PHOTO of a vm on a windows machine <clever>i already knew what the problem was, and rather then trying to reinstall remotely, i just threw a vm disk image at them <clever>the datacenter then asked for the root pw, so they could setup the static ip for me, followed by a "nvm" because i had pre-configured it :P <clever>it was also a nixos install, so i doubt they could have changed the IP <nckx>‘Send me a photo of vi /etc/nixos/configuration.nix and I'll walk you through it.’ <clever>nckx: it didnt exist, the image was built with nix-build, and was intended for use with nixops <clever>nckx: previously, i was trying to use an ubuntu livecd to install nixos, on a different box, and every time i would reboot, the stupid ubuntu scripts would eject the cd <clever>and id have to constantly ask them to push the disk back in, over the support ticket, lol <nckx>Finally, you thought, my woes are over, you thought. <clever>i also dont have any emoji fonts loaded, so i just see ?'s <clever>this is part of why i wrote my kexec tooling <clever>just unpack a tarball to / and run /kexec_nixos, and boom, the machine is now running nixos from ram <clever>if you messed up the networking, wait an hour, it will reboot itself automatically, and then the old OS resumes control <nckx>I wanna do something cool with Guix + kexec but I don't have a use case to justify my time. <clever>nckx: this is the most important part, it takes a pre-made initrd (which has a rootfs, from other tooling), and appends a 2nd initrd with the authorized_keys file, then tells kexec to load the kernel+initrd and exec it <clever>make-system-tarball.nix is then used to bundle the closure of that up into a .tar file <clever>so you can just unpack it to / and the complete closure is available on a non-nix (or non-guix) system <clever>the actual nix tooling and nix state is missing, so its kinda improper, but your going to format that disk in a few minutes <clever>nckx: and because i set $PATH, it doenst rely on any tools being installed on the host, only that the host kernel has kexec enabled <clever>nckx: this netboot profile is the other critical part, it packages the rootfs into the initrd, so you can boot with only kernel+initrd <nckx>Why not use a separate initrd? (Admitted nitpick.) <clever>makeInitrdNG takes the standard nixos initrd, and prepends it to a 2nd initrd that contains just the .squashfs file <clever>at boot, linux will unpack each concat'd initrd to a tmpfs <nckx>There's a lot of abstraction. <clever>and then run whatever /init happens to be <nckx>Which is good! It just makes reading the code a bit very ‘pkgs.doTheThing { doIt = true; }’ OK. <clever>that style also lets you recycle functions easily <clever>antipode: ah, i hadnt seen that script before, i'm guessing it assumes you have kexec installed on the host <clever>antipode: it also looks like its designed to have zero closure, just copy those 3 files to the target <nckx>That was my understanding. <antipode>Exactly, any idea why is it assuming that instead of just adding it to the references? <antipode>Maybe it's for systems that don't have nix yet? <clever>this would be an example of reusing makeInitrd for something else <clever>antipode: yeah, if you dont have a /nix/store, its much harder to get the closure in <nckx>antipode: Presumably the same reason it uses ${SCRIPT_DIR}/bzImage, yes. <clever>in haskell-init, i compile a haskell program to a single static ELF, then i wrap it into an initrd as /init <nckx>Why is it always Haskell with you people. /s <nckx>‘This version may change by agreement of the Toolchain Gang, but for now is governed by the Lancaster Consensus of 2013.’ <clever>nckx: do you know how cross-compiling works in guix? ive been trying to help somebody in adding a cross-compiler <antipode>clever: Try "guix build hello --target=aarch64-linux-gnu" <antipode>You don't need to manually make a cross-compiler, Guix will create one automatically. <clever>antipode: but if you want to add an entirely new arch, that is baremetal only? <antipode>There are some 'bare-metal' arches defined I think <antipode>at least for some glib-something procedure it returns something like "none" for them <clever>antipode: i need vc4-elf-gcc working <antipode>clever: Clarification: are you trying to define a Guix package with some vc4-elf things? <apteryx>nckx: could do you have access to berlin's idrac? just in case. i'll have lunch then reboot it <antipode>hopefully it's only a single arch, not some mix, otherwise things become complicated <clever>antipode: LK supports arm, risc-v, x86, vc4, m68k, and many others! <clever>but for a single project, it only needs one ISA <clever>you always run something like `make PROJECT=vc4-stage1` <antipode>It doesn't try to create some kind of binary to run on Linux to install non-Linux firmware or such? <clever>antipode: the build system then loads a project file like this, which defines a target <clever>antipode: the whole point of this, is to replace the non-free firmware with free firmware <nckx>clever: I guess I don't since I don't even know what ‘bare-metal only’ is supposed to mean. <clever>antipode: the target file then defines an arch <antipode>clever: Add #:target "vc4-elf" to the 'arguments' of your package <clever>antipode: and the arch file defines the cross-compiler prefix <antipode>, then Guix goes into cross-compilation mode for vc4-elf. <antipode>You'll get errors (something about the dynamic linker), but it's a start <clever>here is where i did similar in nix, some projects come from the 32bit arm, some from 64bit arm, and a large chunk from vc4 <lilyp>don't yall just love compiling huge rustlibs? <antipode>What I meant is, why do we have one, why aren't we just using cross-gcc <clever>vc4 isnt supported in upstream gcc <clever>only in a fork of gcc, does it work <antipode>First: #:target #false ; We won't be using the standard Guix cross-compilation, ignore --target= <antipode>Secondly: Add 'gcc-vc4' (from gnu packages embedded) to native-inputs <clever>ah, thats kinda like how i'm dealing with the multi-arch dev shell <clever>where i have a standard x86 env, and a ton of cross-compilers <antipode>To be clear, this is not a generally recommended method of cross-compilation. <clever>yeah, same reason my single-project derivations use the proper nixpkgs cross-compile framework <antipode>Usually, it's just --target=... and sometimes (in case of firmware that needs to be cross-compiled to a _different_ system than the computer in which the device is inserted -- actually we don't do that yet, but AFAIK not for any good reason) <antipode>I think it would be better to add #:target "vc4-elf" to the package instead, that would work better if your 'bare-metal' thing uses some (presumably static?) libraries. <clever>LK's build system doesnt use any libraries <clever>but i do have other vc4 projects that do <antipode>(On #:target: That requires some work though, as the standard gcc doesn't support vc4 so we would have to change some Guix code to, in case of vc4, redirect to the gcc-vc4 variant) <clever>this is a case where i went nuts, and put nixpkgs cross-compile to full use <clever>libcommon.a, can be compiled to baremetal vc4, baremetal arm32, baremetal arm64, linux arm32, and linux arm64 <clever>the address it uses for MMIO changes based on if its for vc4 or arm <clever>and linux arm, will expect you to mmap /dev/mem first, and uses a var instead of an addr <clever>and then i just buildInputs = [ common ];, and it works on any target <clever>but its got some bugs too, x86->vc4 works, but arm->vc4 doesnt <nckx>Whatever that means exactly. <apteryx>I'm checking the output in serial console *nckx people without emojo support: 🤬 <apteryx>booting, although there was an error in GRUB about a device not being found: error: no such device: a6455b66-59d2-40bd-bddb-0c572bb62a2f <apteryx>got the comforting error in finalization thread: Success, seems to be heading back online <apteryx>Service mumi-mailer has been disabled. <nckx>BTRFS error (device sda3): open_ctree failed <apteryx>never resolved on berlin. but moving to UEFI should fix that, if the problem is as seen on twine node 129; if we manage to boot <apteryx>a6455b66-59d2-40bd-bddb-0c572bb62a2f is the partition hosting /gnu <apteryx>rekado: the anonip stuff didn't come back online <apteryx>you're welcome. I'm not done yet though. since we have access now, I'll try switching the machine to UEFI mode <apteryx>and see if it resolves our non deterministic boot issues ***daviid` is now known as daviid
<apteryx>hm, now is a good time to migrate file system too: No space left on device <apteryx>that's because of inodes exhaustion on /gnu <apteryx>nckx: any idea of how to quickly regain some inodes of /gnu? <lilyp>apteryx: run guix gc with a low number of bytes to free? <nckx>Maybe, if you're very lucky, there's .trash from a previous incomplete run. <nckx>Otherwise: ‘quick’: no. Anything involving ‘guix gc’ won't be quick. <apteryx>"it is not possible to expand the number of inodes on a filesystem after it is created" <apteryx>oh! deleting garbage... I should disable cuirass though, otherwise it'll fill it back up in a minute <apteryx>/dev/sdh1 610021376 610021376 0 100% /gnu ^^' <nckx>apteryx: You can set a better trade-off at mkfs time, but better to use btrfs (limitless inodes) next time. <apteryx>yep, I've already partitioned the SAN as Btrfs <apteryx>I planned to reboot to test BIOS -> UEFI first, but this inode thing is making it a pain to reconfigure <apteryx>perhaps time to try the 'guix system init' trick again <apteryx>nckx: 'guix gc -C10GiB' hasn't cleared a single inode in 20 minutes. <nckx>I'd expect it to clear few during (most at a burst near the end, because the real meat is in .links) but not none, since Ludo' disabled deduplication for small files IIRC. <nckx>For deduplicated files, inodes won't be freed until the refcount hits 1 (the copy in .links) and that last copy deleted. <nckx>If your plan was to run ‘guix gc’ for ‘a while’ and then ^C it I would have advised against it. <nckx>It's safe but inefficient. ***Dynom_ is now known as Guest6196
***LispyLights is now known as Aurora_v_kosmose
<rekado>perhaps we could set up node 129 to host some more services, then change the DNS record from .40 to .41, then take some time to build a new system with small store on .40 (berlin). <apteryx>this time I wont sync any of /etc. It's easier to fix broken services than a broken boot. <apteryx>rekado: that'd be the safest approach (and slowest) <apteryx>are we confident that SAN thing is bootable as-is? (as this been attempted before?) <apteryx>guix init says: error: you may need these modules in the initrd for /dev/sdk2: qla2xxx <apteryx>bah, even 'guix system init' complains with "No space left on device" <apteryx>perhaps I can use GUIX_DAEMON_SOCKET <apteryx>that works: GUIX_DAEMON_SOCKET=ssh://hydra-guix-129 guix build hello <apteryx>this seems to do it: GUIX_DAEMON_SOCKET=ssh://141.80.167.159 sudo -E guix system init -L modules berlin.scm /mnt/new-rootfs/@root <apteryx>hmm, the SAN partition now appears filled after writing about 1.5 GiB to it, although it's supposed to be 100 T <apteryx>OK, that was fixed wih 'sudo btrfs fi resize max /mnt/new-rootfs'. SAN oddity, I suppose. <Ox151>hi, i am trying to use the gtk library and its linked to my .guix-profile/include/gtk-4.0, but I need it to be .guix-profile/include/gtk, i tried to create a new link which should fix it, but .guix-profile/incude is r-x only. ***mark_ is now known as mjw
<rekado>apteryx: we’ve never tried booting from the SAN <rekado>if it isn’t visible in GRUB we can do the same as before: put the kernel and initrd on a local disk, then swap the root fs when Linux boots <antipode>I deactivated a specification on my local instance, and now it's gone, does someone know how to reactivate it? <antipode>reconfiguration and restarting cuirass had no effect. <antipode>Will try to work-around by renaming for now. <apteryx>the 'guix system init' nearly worked, but grub install failed, I think because it detected GRUB on the host and it conflicted or something. 