IRC channel logs


back to list of logs

<sneek>dannym was in #guix 3 months ago, saying: civodul: Hi :).
<nckx>sneek: botsnack, but don't ping people.
*GNUtoo wonders if I can leave a message somehow?
<nckx>sneek: later tell <nick>: <stuff>
<sneek>Got it.
*nckx facepalms.
<nckx>Who knows when dannym will next log in, though. They don't IRC often. E-mail is a much better bet.
<GNUtoo>sneek: later tell dannym: Hi, you worked on packaging rpi-open-firmware, and days ago a GPLv2 license was added to the new design ( which has a much better status (composite video works on most devices for instance).
<sneek>Got it.
<cbaines>civodul, regarding novena-eeprom, that'll be a Guix Data Service issue, since it's computing derivations for x86_64-linux plus other systems, it's probably not paying attention to the supported-systems field properly
***user3456_ is now known as user3456
<sneek>Yey! rekado is back!
<vagrantc>i love this computer. "guix upgrade: warning: Your Guix installation is 19040 days old."
<kitty1>:l woah lmao
<Noisytoot>How can your Guix installation be 52 years old?
<vagrantc>bad clock battery, boots to epoch 0 :)
<vagrantc>should really look into fixing that ...
<vagrantc>and/or fixing ntpd to actually really bump the year even when it's that old
<vagrantc>and/or writing a dumb service to make sure time for the most part only moves forward :)
<nckx>My initial reflex was ‘we should fix that to use d/m/y units’ but I actually quite like the effect.
<podiki[m]>hi again nckx! hope all has been well
<nckx>Glad to be back, tho.
<nckx>How's you?
<apteryx>rekado: thanks to you for making mere ideas a reality :-) ok let's try a bit earlier tomorrow
<apteryx>rekado: oh, /etc/ssh sounds like something critical to preserve
<apteryx>(just saw you already had mentioned it)
<apteryx>on the /etc preserve list: rsync -aPHAX /etc/{guix,childhurd,ssl-ca,letsencrypt,cuirass.scm,wireguard,ssh,rsyncd.conf} /mnt/btrfs-pool/@etc/
***Xenguy_ is now known as Xenguy
***sturm_ is now known as sturm
<dirtcastle>guys. I'm new to guix and archlinux. can I use pacman and yay to download binaries and guix just for rollback?
<Kolev`>dirtcastle: no. packages hav to be downloaded from guix. guix does not touch pacman.
<dirtcastle>aur has emacs-native-comp-git-enhanced. will that be available in guix?
<jgart>dirtcastle, you can use both package managers side by side
<jgart>just install Guix on Arch
<jgart>or whatever arch derivative you like
<dirtcastle>yup! got it. I'll just download packages that are more prone to breaking coz of updates through guix.
<sleepydog>what is emacs-native-comp-git-enhanced ?
<dirtcastle>thanks for your time! Kolev` jgart
<podiki[m]>nckx: missed that question earlier. all good here, excited for my first guix days, have a talk too!
<jgart>dirtcastle, np
<dirtcastle>sleepydog : it's a package in aur - emacs with native compilation
<dirtcastle>it's faster than normal emacs because normal emacs is interpreted and not compiled.
<sleepydog>as in, it natively compiles elisp instead of using bytecode?
<jgart>dirtcastle, have you checked out flatwhatson's channel?
<dirtcastle>nope. haven't heard of it until now
<jgart>maybe someone should just add that package to upstream
<jgart>unless it's not ready?
<jgart>dirtcastle, Do you know how to add a guix channel?
<jgart>you could get emacs native comp that way
<dirtcastle>nope. I'm completely new. but I have the rough idea what it will do. I'll check the manual and videos.
<sleepydog>the github README has instructions
<sleepydog>in jgart's first link
<jgart>dirtcastle, Guix channels are like AUR
<jgart>Here's another channel with more packages that are not in upstream yet: https://whereis.xn--q9jyb4c/
<jts>it might be worth mentioning that emacs-next in the official guix channel is 28 so it has the native compilation features already
<dirtcastle>in emacs we include repos like melpa, elpa. this is like that right?
<jgart>dirtcastle, guix can take from all of those repos
<jgart>some emacs packages come from github, for example
<jgart>we download the sources and build it
<jgart>then install it in the store
<dirtcastle>ohh. noting down everything.
<jgart>If you'd like to get involved with packaging there's a packaging meetup once a month
<jgart>more info about that this Saturday at Guix Days: WhereisEveryone, Guix 'R Us, Online Meetups
<jts>does anyone here happen to use Spacemacs with Guix emacs and know how to get the symbols to load properly? eg in spaceline (emacs-spaceline in the Guix channel)
<jgart>you mean guix.el package?
<podiki[m]>would be great to have flat's emacs packages in guix, seems it still needs a newer/tweaked libgccjit
<podiki[m]>or at least that channel provides one and has reasons for it
<jts>jgart: I mean I'm using Spacemacs on emacs-next from Guix and the symbols and the statusline (and other places) aren't loading properly
<jts>in the statusline*
<jgart>hmmm, not sure. maybe someone else has tried hacking that
<podiki[m]>maybe a missing font? I forget for spaceline, but other nice mode lines like having some fonts with the symbols
<jts>I do have the recommended font installed (adobe soure code pro)
<jts>I just have it installed to my profile, though; should I include that in the system definition or something?
<podiki[m]>I don't remember the emacs commands off hand, but you should be able to see what fonts/symbols it is trying to load
<podiki[m]>or maybe check the spacemacs/spaceline (I think they have a separate package for the modeline for non-spacemacs users that can be handy to look at) docs/issues to see any troubleshooting
<xelxebar>sneek: Later tell civudol, The invalid SSL cert issue with guix pull turned out to be because my system clock was way off (more than a year in the past). :facepalm:
<sneek>Got it.
***aya is now known as gyara
<thornAvery>hello, Im doing a fresh guix install. At the moment I have two problems: when doing 'manual partitioning' through the install menu, I get a stack trace about not matchitg the symbol ext4, and secondly after an automated install, after guix pull and a reconfigure, I get stuck on what I assume is hhe dmesg screen on boot
<thornAvery>ny pointers on where to go from here? i can boot into the generation from the initial install, but any of the successor bulids wont boot
<tho1efx[m]>Someone on the maintainers crew should cross some things off the ROADMAP file. <nonfree></nonfree>
<tho1efx[m]>* file. <nonfree>, * </nonfree>
<apteryx>for your info, mumi ( is offline for maintenance (database backup); should be back soon
<apteryx>mumi is back online
<jts>thornAvery: regarding ext4, is the reference in a device uuid or in a filesystem type? a type has to be a string eg "ext4" while a uuid has to be a symbol eg 'ext4. see "type" and "device" options of the file-system type, and the "uuid" procedure (at the bottom)
<thornAvery>jts: im not sure what the scheme had it as, this was happening as part of hhe graphical install before I got a chance to edit ncheme
<vivien>Is there a way to make a guix pack with only native inputs of a package, like -D for guix shell?
<vivien>I can create a guix profile (from (guix profiles)) but I can’t pass it directly to self-contained-tarball (from (guix scripts pack))
<vivien>OK, I was confused, self-contained-tarball requires a profile and not a manifest
<vivien>Where does guix store the channel authentication results?
<civodul>Hello Guix!
<sneek>civodul, you have 1 message!
<sneek>civodul, xelxebar says: The invalid SSL cert issue with guix pull turned out to be because my system clock was way off (more than a year in the past). :facepalm:
<vivien>Looks like it’s in ~/.cache
<vivien>Hello civodul :)
<jacereda>how can I establish environment variables from a guix.scm, so that those are properly set when entering 'guix shell'?
<flatwhatson>jgart: it's ready enough to go upstream, I just haven't been paying down my guix backlog for a bit
<civodul>jacereda: hi! in general you cannot, except for search paths:
<jpoiret>you can integrate `guix shell` as part of your own environment setup though
<jacereda>civodul: I'm trying to write a guix.scm for a project that needs LLVM_SYS_130_PREFIX set, in nix it would just be 'LLVM_SYS_130_PREFIX = "${}";' in its pkgs.mkShell. I'm wondering what the equivalent could be for Guix. Maybe a 'shell stage, so you can '(add-before 'shell...'?
<jacereda>jpoiret: what do you mean?
<jpoiret>Ah, I thought you wanted to set some env variable to a static thing
<jacereda>civodul: oh, maybe that use case is already covered by `(native-search-path`?
<rekado>apteryx: I’m around now; let me know if you want to go through the fs once more before we reboot.
<rekado>sneek: hey, want a botsnack?
<jpoiret>I don't think it would cover your use case though
<vier-littleme>can i manually delete some file at /gnu/store? is that support? or some cmd can handle that?
<jpoiret>vier-littleme: `guix gc -D /gnu/store/xxxxxxx`
<vier-littleme>jpoiret: thank you
<jacereda>If there isn't already a hook in place I can intercept to do things like '(setenv ...' before entering a shell I'd like to add one, any hint on where to look? Does a 'shell stage sound reasonable?
<jpoiret>i don't really understand the 'shell stage thing though, i don't think we have that
<the_tubular>thornAvery, late answer, I remember having this problem. I retryed it like 5-6 times and it just worked
<jpoiret>i think the best solution currently would be to write a proper guile file that uses the Guix APIs
<the_tubular>Also, my SSD was dying and it was giving me weird errors
<the_tubular>Is there a way to use guix to configure emacs ?
<jpoiret>if you need llvm in the environment itself (ie installed in the profile) i think it should be pretty easy by parsing the profile's manifest, otherwise you'll need to interact with the store directly
<sneek>Welcome back dongcarl!!
<jacereda>jpoiret: I mean that packages already have a mechanism to add hooks via `(add-before` and friends, maybe an artificial 'shell stage that will be invoked by 'guix shell' could do the trick?
<jpoiret>they're not hooks though, they're purely build phases
<jpoiret>they can't really influence the run-time apart from adding files or modifying them
***modula2 is now known as defaultxr
<jacereda>My use case doesn't influence the run-time, I just need to set environment variables during development, those variables aren't needed at run-time once the product is built
<civodul>jacereda: i don't think the llvm package declares LLVM_SYS_130_PREFIX as a search path right now, so as jpoiret wrote, you probably need to define it by yourself
<jpoiret>jacereda: well, if you're writing a guix package, then setting LLVM_SYS_130_PREFIX in a build phase is 100% okay, but it seems you're using `guix shell` to manually build something
<vier-littleme>union-build: collision between file and directories ((files ("/gnu/store/${hash}openjdk-17.0.1/lib/modules")) (dirs ("/gnu/store/${hash}linux-libre-5.16.9/lib/modules")))
<jpoiret>in that case, `guix shell` can't really set arbitrary env variables
<vier-littleme>how to handle this? is that a way to put the openjdk at {hash}/lib/jvm?
<jpoiret>vier-littleme: are you trying to put openjdk in the system profile?
<jpoiret>I think the better workaround would be to only install it in a user profile if possible
<vier-littleme>i just trying install openjdk, not root users. i got some confused
<jpoiret>jacereda: the way `guix shell` works as of now is that it simply builds a profile and enters it (with some bells and whistles), I don't really see a simple way to add the feature you're describing right now
<vier-littleme>jpoiret would you help me by display how to install jdk at user profile? i use guix install openjdk
<jpoiret>but it's definitely something people are interested in
<jpoiret>vier-littleme: did you also install linux-libre inside that profile?
<jpoiret>you can use `guix package -I` to see installed packages
<jpoiret>(that's a capital i)
<vier-littleme>i got it, i can't put both at some profile, isn't it?
<vier-littleme>jpoiret thank you, you are so lovely
<jpoiret>yes, since they conflict
<jpoiret>you can either install them in different profiles, or remove linux-libre
<jpoiret>jacereda: i think a possible workaround would be `LLVM_SYS_130_PREFIX=$(guix build llvm) guix shell`
<jpoiret>if you're using --pure you'll also need to --preserve=^LLVM_SYS_130_PREFIX
<jacereda>jpoiret: that could do the trick, but maybe it would be cleaner to have some method to do that in the guix.scm... If someone suggest a way I'm willing to attempt it
<jpoiret>i think you'd have to rewrite something on top of `guix shell`
<jpoiret>for now guix shell is 100% limited to what profiles can do, and those don't really support setting arbitrary env vars
<jacereda>jpoiret: btw, where's the `guix shell` code?
<jpoiret>guix/scripts/shell.scm and guix/scripts/environment.scm
<jacereda>jpoiret: great, thanks
<jpoiret>you'll find that shell is just a layer over environment
<wonko>hi all!
<wonko>when I `guix system reconfigure` I see packages that should not be concerned being built (inkscape for example, that is installed in a user profile). So how does updating the system impact stuff installed by a user?
<jpoiret>wonko: inkscape is used by a package in your profile is the most likely answer
<jpoiret>system declaration *
<jpoiret>it's often used to convert SVGs, although that should be limited to build-time I think
<wonko>ok, so reconfigure doesn't touch user profiles
<wonko>currently when I update, I `guix pull` as root, then `system reconfigure`, then I pull as user, and I rebuild profiles from manifests. Is there a simpler way of doing this?
<jpoiret>yes! you don't need to guix pull as root at all
<jpoiret>if you do `guix pull` then `sudo guix system reconfigure`, the second command will use the freshly-pulled guix
<wonko>ah, perfect!
<jpoiret>that's because `sudo` doesn't try to load the user-to-sudo-as's environment variables, including PATH, and it will lookup the binary to execute from the user-that-is-running-sudo's PATH
<jpoiret>(unless you use `sudo --login/-i`)
<allana>Hi guix! Any Python people here who might know when a python-next may arrive (e.g 3.10.*)? I perused wip branches of the guix repository and didn't see anything promising
<balbi>hi, I have `sbcl', `sbcl-slynk', and `stumpwm'. How can I tell `sbcl' and `stumpwm' where to find `sbcl-slynk' so I can start a slynk server in the context of stump?
<son0p>hi, how can I change use Fish as shell?, I've tried $ chsh -s /bin/fish and $ chsh -s ~/.guix_profile/bin/fish but get chsh: PAM: autentication failure in both cases
<balbi>son0p: looking at the manual, I suppose you need to reconfigure your user account section.
<balbi>son0p: perhaps add something `(shell (file-append fish "/bin/fish"))' to your user? I'm not 100% sure though
<son0p>balbi: thanks!
<son0p>I will try that
<balbi>son0p: hope it works, I'm also pretty new to guix :)
***ff is now known as Guest8037
<vier-littleme>acually u can treat it as normal system too, i use arch and guix.(arch provide kernel some driver).
<vier-littleme>so don't be afraid to change the config, there is generation of guix to protect u.
<tschilptschilp23>Hi! I'm a little confused by the 'guix git authenticate' process. The situation is the following -- I've cloned git from savannah, run the process as described in the manual, including the testsuite. Now I've added a definition/commited signed with my gpg-key, './pre-install-env guix build PACKAGE', re-run 'make && make check'. So far it looks good. But now, if I run 'make authenticate' it returns '/bin/sh line 2: guix: command not
<tschilptschilp23>found'. To get around this, I run './pre-install-env make authenticate', but then I'm told that my commit's key is missing. I do understand that, as I wouldn't know how guix should know about my key. What am I missing?
<rekado>your key would have to be added to the keyring branch
<rekado>I’m getting this error trying to use qemu-guest-agent-service-type: guix system: error: #<<location> file: "gnu/services/virtualization.scm" line: 893 column: 18>: invalid G-expression input
<rekado>this error seems to be referring to qemu-guest-agent-configuration
<tschilptschilp23>rekado: thanks. I will try to figure this out
<tschilptschilp23>rekado: this this means I will fork guix in order to manipulate the keyring, to get rid of this problem? I'm not experienced with git/gpg processes...
<rekado>tschilptschilp23: you don’t need to do any of this if you are not a contributor with push permissions
<tschilptschilp23>For local stuff and possibly-future-patch submission I can skip all that? Happy to hear!
<rekado>tschilptschilp23: yes, someone else will apply and sign the commit, so your key doesn’t need to be there
<stfnbms>Today I am struggling with setting up encrypted swap. My understanding is that the only way to do so in Guix is to use a swap file on a LUKS-encrypted filesystem. So I tried this:
<stfnbms>But system reconfigure gives me the error message: Wrong type to apply: "/mnt/swap/swapfile"
<stfnbms>I am also confused about whether to use “swap-space” or “swap-devices,” or both.
<rekado>stfnbms: “wrong type to apply” means that something other than a procedure (or macro) is in the first position of an expression
<jetomit>stfnbms: I have (swap-devices (list (swap-space (target "/swap"))))
<stfnbms>rekado and jetomit: Thanks, I will try that. Would explain the “wrong type.”
<stfnbms>No luck. Now I have and get the error
<porcupirate>pulse_out says it can't find the JACK socket even though I'm starting it with qjackctl. Stopping pulse doesn't help. Has anyone been able to get JACK to work when installed to a user profile, or is it best to install it as a system package?
<porcupirate>not pulse_out. alsa_out
<wonko>stfnbms: I have (dependencies mapped-devices)
<wonko>oh but that's new in my config and haven't finished building
<apteryx>rekado: good afternoon!
<apteryx>I've got this local commit for the maintenance repo:
<apteryx>it should contain all that is needed (a listing of the "state" migrated appears at the bottom)
<apteryx>if you look under /mnt/btrfs-pool/ you should see various subvolumes holding that data
<rekado>the bootloader thing works on the variable /dev/sdX names. Is this a problem?
<rekado>thanks for taking care of /secrets. I’ve been wanting to move secrets there since a long time :)
<rekado>apteryx: I see that /home is already on btrfs, but /root is not
<apteryx>rekado: it's suboptimal that it wants devices names instead of UUID (as noted in a comment), but unless the devices change place again it shouldn't be a problem
<apteryx>rekado: yes, /root will just be part of @root I think
<apteryx>(not its own subvolume)
<rekado>should /root be copied?
<apteryx>I haven't seen anything of value there
<rekado>well, the dirty maintenance clone is there
<apteryx>is it still useful? Personally I never know if the uncommitted bits there are useful, so I've been working from a personal pristine maintenance checkout under ~/src/maintenance
<rekado>it’s not a bad idea…
<apteryx>I'd argue if they are useful whoever tried them should commit them :-)
<rekado>but we have been using dirty stuff there
<rekado>I keep stashing away, rebasing, unstashing
<simendsjo>I tried to post to the bug mailing list several hours ago, and I got the accknowledegment, but the post doesn't show in the archives. Has the post been "moderated" or something? The reference is 54037.
<rekado>apteryx: secrets isn’t mounted anywhere atm
<rekado>if the secrets in /root have been copied, could you please delete them from /root?
<apteryx>I haven't reconfigured with that yet; and I'll run 'guix system init', which won't mount things until the next reboot
<rekado>(trying to clean up a bit)
<apteryx>hm, actually no because the current services are still using them
<rekado>I’ll take a look at maintenance now
<apteryx>also, 'du -ms /var/log/* | sort -rn' says there are 643M mumi.worker.log and 337M mumi.log log files; we should extend rottlog for rotating these
<apteryx>also cuirass-web-server.log at 8.3 G, cuirass-web.log at at 6 G
<apteryx>simendsjo: if it is your first post yes, it is probably awaiting moderation
<rekado>apteryx: you can trash the mumi logs
<rekado>apteryx: hydra/cuirass-client-certs/ in /root/maintenance doesn’t exist anywhere else
<apteryx>oh! where does this get picked up?
<rekado>it’s for us sysadmins to generate new certs for cuirass admins
<apteryx>should we commit it?
<apteryx>the way to create the certs shouldn't be secret sauce (the crypto is enough), right?
<rekado>looks like it contains a very guessable password :)
<rekado>(to unlock the private key I think)
<apteryx>should we move this to under /root/scripts or something? And adjust the doc.
<rekado>apteryx: yes.
<rekado>I think it’s not mentioned anywhere in the docs.
<rekado>I committed everything else that was worth keeping
<rekado>there’s one difference now: when we deploy to the build farm it will likely want to enable the childhurds for a bunch of servers.
<rekado>they had been disabled previously
<apteryx>rekado: what do you think of extending rottlog for mumi via:
<rekado>apteryx: looks good
<apteryx>I guess we're about ready to try it
<apteryx>there'll be a 80 G nginx log (!) to take care of later
<rekado>okay, I’m on the serial console in case things go wrong
<rekado>the new system is going to reset all our passwords, isn’t it?
<apteryx>hmm, good point; can /etc/passwd be preserved?
<singpolyma>Need /etc/shadow too
<rekado>or we could just start from scratch
<unmatched-paren>what does `nouveau: sec2 ctor failed` mean? (obviously it's something with the nouveau driver, which i don't really need, i'm just curious)
<rekado>I get on with root on the console, set a password, and then send y’all your initial passwords.
<apteryx>works for me
<unmatched-paren>i don't use my nvidia card, the integrated intel card works fine for most things, but it would be nice to be able to use it for eg supertuxkart which has noticeable stuttering on the intel card
<unmatched-paren>obviously this boot error makes me slightly worried to try
<apteryx>rekado: init has run
<apteryx>ah, still running
<apteryx>when it completes, I'll stop postgresql, sync it one last time, do the same for mumi, then the logs, then reboot
<apteryx>so the way GRUB is supposed to boot on these new drives is via the bios_grub partitions on each of them
<apteryx>all of the 6 drives both have a 1 M bios_grub partition as well as an 200 M esp one (for EFI compatibility, not used here).
<apteryx>guix system: bootloader successfully installed on /dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf :-)
<apteryx>just noticed a typo for the postgresql mount
<apteryx>should be under /var/lib/postgresql
*rekado goes to mix some pizza dough
<lfam>sneek: later tell xelxebar: Maybe we can fix your "clock is waaay off" problem by having Guix set the clock to the date of the Guix revision itself if NTP won't make such a big change, and then try NTP again. It might fix some instances of the bug, since the date of the revision-in-use is probably not more than a year old
<sneek>Will do.
<lfam>sneek: later tell xelxebar: It would be great to get some more details about the case where NTP wouldn't fix the time. Like, how wrong does the clock have to be?
<sneek>Got it.
<lfam>simendsjo: Your mail should be getting delivered now
*apteryx is syncing logs before the reboot...
<apteryx>lfam: any idea how to get nginx to better rotate its logs on berlin?
<apteryx>you also had noted a 80 G nginx log
<apteryx>it's ridiculous
<rekado>why do we log so much anyway?
*jonsger thinks that logrotating is an area where Guix can still improve :P
<apteryx>I don't know
<apteryx>the biggest one is: 80340 /var/log/nginx/https.access.log
<apteryx>and there are a couple more of around 8 G
<rekado>that one hasn’t been rotated since 2020
<vivien>Isn’t it illegal?
<vivien>Probably not but I don’t know much about this
<rekado>not rotating should be illegal.
<apteryx>hmm, nginx doesn't say much about log rotation:
<vivien>We have a service for log rotation, it just needs to be extended by more services
<rekado>apteryx: I think we should worry about this later.
<rekado>I’d compress the log and move on for now.
<rekado>then discuss among the sysadmins what we really want from those logs (detect abuse? get rough usage stats?) and then adjust
<rekado>and maybe we decide that we don’t need to log the very mundane stuff at all
<apteryx>I'd be in the camp of 'no logs until we see a reason for them'
<apteryx>but they've been useful in the past, to gather stats about which substitutes type is most used
<apteryx>so yeah, let's discuss!
<gnucode>Hello guix!
<rekado>apteryx: just sent an email
<apteryx>thank you!
<apteryx>I'll let the huge logs finish syncing to the new storage, then move the nginx log directory to nginx.bak
<apteryx>then reboot
<apteryx>it's almost done I think
<rekado>what happens to builds that arrive at /gnu/store but for which we haven’t built any substitutes yet?
<rekado>we’re only building substitutes on demand, aren’t we?
<apteryx>cuirass takes care of populating the cache for each build retrieve I think
<rekado>I’m asking because I’ve been building quite a few aarch64 packages — outside of cuirass because of the coreutils test failures.
<rekado>would be a shame to have them lost
<rekado>well, they wouldn’t be actually lost; they’re still in the old store.
<apteryx>if they have been cached, should be OK, otherwise lost
<rekado>but we have no way of fetching them from the old store
<apteryx>yes, I mean unusable
<rekado>after the reboot maybe we could start a VM or a container that uses the old store and allows us to “guix copy” things back and forth
<rekado>not to recreate the huge store a second time, but to get requested builds for substitute baking
<apteryx>that sounds fun
<rekado>more like “fun”
<apteryx>OK I'm out of patience for these logs
<apteryx>will abort rsync and reboot
<rekado>go go go!
<apteryx>issuing reboot...
<apteryx>hope it comes back!
*rekado watches the console
<rekado>156156.169251] shepherd[1]: failed to unmount '/gnu': Device or resource busy
<apteryx>OK; I hope that's just a warning
<rekado>[156195.386703] reboot: Restarting system
<rekado>blinking cursor
<rekado>okay, it’s initializing hardware
<apteryx>the thrill
<rekado>linux is booting
<podiki[m]>(enjoying the play-by-play!)
<rekado>waiting for partition 'a6455b66-59d2-40bd-bddb-0c572bb62a2f' to appear...
<rekado>bunch of disks appear
<rekado>I see failures to start fs
<rekado>btrfs services don’t come up
<apteryx>uh uh
<rekado>and that leads to a lot more failures
<rekado>three devices are missing according to btrfs
<rekado>it’s in a loop now
<apteryx>are you able to copy the relevant messages?
<gnucode>that sounds problematic...
<rekado>weirdly enough it keeps trying to start all the other services
<rekado>that’s not sane
<rekado>zabbix_agentd [2574]: cannot open log: unable to open log file [/var/log/zabbix/agent.log]: [13] Permission denied
<rekado>no shit
<apteryx>did it boot read only?
<rekado>I don’t know
<rekado>it’s still going
<rekado>I mean: still failing to start services
<rekado>I don’t get a login prompt
<rekado>so… why are we missing three disks?
<apteryx>perhaps they were too slow to initialize at boot?
<nckx>Good morning Gu—oh, hushed silence, I see.
<apteryx>can you do a power reset from where you are?
<rekado>yes, I’ll try
<rekado>can we make the other services depend on successful btrfs initialization?
<rekado>there’s no point in any other service trying to start
*rekado waits for grub
<rekado>FWIW the server sees 6 non-RAID disks
<apteryx>perhaps! I think Btrfs may be booting in read-only because the degraded flag is present; but it warns too many device are missing to boot with write access
<apteryx>if degraded wasn't there it'd just panic at this point
<rekado>almost reached grub
<rekado>okay, here we are
<rekado>should I do something in the grub cli?
<rekado>or do we just try again?
<apteryx>just try again to see if it's reproducible
<rekado>I should say that the first thing it does is print “error: no such device: a6455b66-59d2-40bd-bddb-0c572bb62a2f.”
<rekado>it asks me to hit any key
<rekado>I don’t
<rekado>and then it starts booting
<rekado>I see “recovering journal” on “my-root”
<rekado>it moutns ext4 things
<apteryx>rekado: a6455b66-59d2-40bd-bddb-0c572bb62a2f is the old disk
<apteryx>network array, right?
<apteryx>it must be missing since I've removed the kernel modules making it visible
<rekado>so, now I’ve got *four* missing disks
<rekado>1, 4, 5, and 6
<rekado>more seem to be coming up
<rekado>now it’s only two
<rekado>disk 1 and 4
<rekado>zabbix wants to log again
<apteryx>seems time sensitive; I wonder if there's a way to halt the system before 'btrfs scan'
<rekado>it keeps printing different devids
<apteryx>to give the drives some time to come up
<rekado>1 and 4
<rekado>and sometimes it’s 1 4 5 6
<apteryx>can you enter the bios, waste some time there, then resume boot?
<rekado>I don’t understand
<rekado>may I waste time in Grub instead?
<apteryx>that should do too! But it may be interesting to validate all the drives are present in the BIOS
<apteryx>(seen by the BIOS)
<rekado>they are all there
<lfam>apteryx: I think we just need to make sure to actually rotate the logs? There's supposed to be a cron job to handle it, but either certain logs are not specified for rotation, or cron isn't working?
<rekado>the first two are the old HDDs; then follow six SSDs
<lfam>It's something to investigate on the new system
<gnucode>sorry for being behind on the times...what's the new system that you guys are migrating to?
<rekado>apteryx: I’ll powercycle again and waste time in grub
<apteryx>OK, thanks
<apteryx>gnucode: we're attempting to migrate the build farm to a new storage array
<rekado>apteryx: but I’m not hopeful that this helps
<lfam>From spinning HDDs to SSDs
<rekado>maybe I could do something to the disks in grub?
<lfam>gnucode: It should increase performance of the build farm and unlock a lot of possibilities currently constrained by slow I/O
<gnucode>apteryx ok. That's probably a good idea. I imagine in a few years you'll move to NVMe. That's just speculation of course.
<gnucode>lfam: what sort of things would now be possible?
<gnucode>once the migration is complete?
<lfam>The build farm will be able to work almost 24 hours per day instead of spending >1/4 of its time on slow garbage collection
<nckx>‘Building things’ (not a joke — the daily GC was taking >24h last time I checked, and blocked builds, no nothing was built).
<lfam>Things like that
<apteryx>rekado: same issue?
<lfam>gnucode: We have just been extremely constrained by this slow I/O, and it makes us unwilling to try new things
<nckx>gnucode: The only reason it still built as much as it did is that people frequently ssh'd into it to kill ‘guix gc’.
<lfam>Now... the future is possible
<nckx>Leading to other problems.
<nckx>lfam: Yay \o/
<mbakke>rekado: it does not help with your current situation, but I fixed the zabbix services on 'master'
*mbakke has to go, good luck!
<rekado>apteryx: only just got to grub
<rekado>initializing the hardware takes a very long time
<joshulux>I gather from the log that the issue with being down is known and related to the build farm migration?
<lfam>We should mention it in the channel topic
<lfam>Can someone do the needful?
<nckx>Oh, sure.
<nckx>Thanks for the prod.
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix 🚨 is being migrated, all services down 🚨 | | videos: | bugs & patches: | paste: | Guix in high-performance computing: | This channel's logged:'
<gnucode>lfam and nckx thanks for the explanation.
<apteryx>nckx: thanks!
<rekado>apteryx: not much I can do in grub
<rekado>so I’ll just try booting again
<apteryx>I could ssh in
<apteryx>so it is time sensitive
<rekado>this is wrong
<rekado>this is ext4: /dev/sdg1 on / type ext4 (rw,relatime)
<apteryx>hm. is this a previous generation?
<rekado>also: I’m both logged in and not
<rekado>got this horrible serial console problem again
<rekado>some serial console service must have started late and now it’s messing with my session
<apteryx>SSH works
*apteryx checks /run/current-system/configuration.scm
<rekado>could it be that we accidentally got an old grub to respond?
<rekado>we’ve got grub on all of these disks
<apteryx>hm yeah that's old
<rekado>including the old hard disks
<rekado>but hey: it booted
<rekado>so … we get a chance to fix this
<apteryx>it could be yes!
<rekado>the only way we could have booted an old generation is through the old grub
<apteryx>GRUB is still on the older disks, on their MBR
<rekado>so … this /dev/sd* business is just messed up
<rekado>this was not fun
<rekado>I see that isn’t back up yet
<rekado>apteryx: could you check that we aren’t destroying anything by having booted the old generation?
<rekado>like, are any services writing to the wrong locations…?
<rekado>do the mounts look sane?
<rekado>to fix the grub problem we can do this: add a menu entry to the old grub config that chainloads the new grub
<podiki[m]>probably you all did this, but double check boot order in bios? if it seeing a different grub or the a disk is not coming quick enough that is earlier in the boot order?
<rekado>(until we get a chance to remove the old disks)
<rekado>podiki[m]: yup, will mess with the boot order later
<apteryx>rekado: looking at /run/current-system/configuration.scm, it should be fine
<apteryx>we're back to the previous state
<rekado>so we’ve got ourselves some breathing room
<apteryx>yeah. not great though. I don't have a good explanation of what went wrong.
<rekado>add a busy wait after ’btrfs scan’?
<apteryx>someone hinted at rootdelay or rootwait arguments that'd need to be understood by our initrd
<apteryx>seem like rootdelay would be helpful
<apteryx>that'd be a configurable amount of time in seconds to busy wait before attempting mounting the root fs
<apteryx>that should have the same effect as waiting at the GRUB prompt before continuing the boot, right?
<gnucode>Fun fact, I started updating my guix server during the migration boot issues...The downtime was so short, that it did not seem to affect the upgrade. Good job guix team!
<rekado>apteryx: I don’t think so
<rekado>it tells *Linux* not to give up
<rekado>but the root file system *does* seem to come up — partially.
<rekado>enough that Linux thinks “this is good enough to continue”
<rekado>and then it pivots to the new system, starts shepherd, and runs with it
<rekado>all the while the file system is actually not at all in a usable state
<rekado>rootdelay probably wouldn’t help here
<rekado>apteryx: I don’t know anything, but this looks relevant:
<rekado>in particular the reference to this udev rule:
*rekado goes afk for a while
<nckx>I thought I ‘implemented’ rootdelay for the initrd.
***nckx changes topic to 'GNU Guix | | videos: | bugs & patches: | paste: | Guix in high-performance computing: | This channel's logged:'
***ChanServ sets mode: -o nckx
<apteryx>rekado: from my current understanding, what would be key is to get 'btrfs device scan' to assemble the Btrfs RAID cleanly (as opposed to degraded with 4 or 2 or N missing drives currently)
<apteryx>'btrfs device scan' occurs during our initrd; so having a delay before the scan (via an option understood by our initrd) would help, it seems
<apteryx>nckx: oh, do we have such a thing already?
*apteryx reads the reddit post
<apteryx>nckx: ah, #48880 "gnu: Respect ‘rootdelay’ kernel command-line argument."
<nckx>apteryx: Should do <>. I haven't tested it recently, though, most notably after moving ‘btrfs dev scan’ to something like a pre-mount phase (IIRC). LMK if I broke it and I'll fix it immediately.
<nckx>I stand by the comment 😉
<nckx>systemdistros use udev to ‘properly’ sync with device probe events IIUC.
<apteryx>I've seen btrfs udev stuff pass by the boot log it seems... properly by the time our udev service has started and the root partition long mounted
<apteryx>to the "optimal" way to handle this would be to support udev at the initrd level?
<nckx>I'd say that's the majority opinion.
<nckx>Our whole ‘script a bunch of ordered actions at boot time’ goes against the current practice to launch such things on hotplug events, whenever they happen. Most during boot, but not all.
<nckx>‘Stuff has probably settled by now, enumerate all drives!’ is not considered good practice now.
<apteryx>I wonder what supporting this at our initrd level would entail...
***dgcampea-2 is now known as dgcampea
<nckx>Without thinking it through, I'd suggest the systemd approach of starting the shepherd as early as possible, and handling these scripted steps as ‘proper’ async services instead, both of which survive into the booted system.
<nckx>But I didn't consider alternatives.
<nckx>This implies making the Shepherd more dynamic than it is now, or at least than it is currently used.
*nckx shrugs.
<apteryx>so if I use rootdelay=20 as a kernel-arguments, that may allow us to move past that 'btrfs device scan' not finding the drives problem
<nckx>The above is one of the main reasons that systemd considered it necessary to maintain udev in sync, because it's so central to their (hardware-)event-driven approach. But I don't want to have The Conversation again please 😛
<nckx>apteryx: It should, if the problem is just async kernel scans taking longer than we expect.
<nckx>Can't say I'm familiar with HBA/servery systems.
<apteryx>we're talking local SSDs
<nckx>Ah, but they're no longer hooked up to the same interface the previous array was?
<nckx>My ‘good morning’ above was really where I came in, I didn't read the whole story.
<nckx>Nor did I read everything after it to be honest :)
<apteryx>I think they are hooked in a front bay directly attached (part of) the server unit
<apteryx>it's fine; we tried rebooting the system and it failed to find some drives, booting in a read-only degraded state, presumably because of lack of synchronization at our initrd
<apteryx>and after a couple of reset we managed to have GRUB pick an old drive and boot from that, which allowed us to get back to the current state
<nckx>Well, all I can say is that I've configured minimal kernels so ‘efficient’ they booted ages (er, seconds) faster than the kernel noticed the only SATA disc in the machine. It's not that weird.
<nckx>Oh, sometimes-boot, nice.
<apteryx>how does GRUB pick a drive to boot from from its scan?
<rekado>apteryx: that’s nothing to worry about
<rekado>we’ll just remove the old disks from the top of the boot order
<rekado>and/or: add an option to pass control to the other disks from the old grub
<nckx>I'm not sure GRUB even deals with multi-device at all? It certainly didn't used to.
<apteryx>it does, because at home I have LUKS on top a Btrfs array and it manages to prompt for the passphrase
<nckx>What kind of array?
<rekado>it doesn’t have to deal with multi devices
<rekado>we installed grub on all the disks
<apteryx>nckx: ah, I may be forgetting, LUKS must be under the RAID, not on top
<apteryx>rekado: true; just picking any of them should be fine
<nckx>rekado's reply is how I remember things being, too.
<nckx>It ‘deals’ with multiple devices by installing it to each, so whichever one is booted at random works :)
<apteryx>GRUB prompts me for LUKS 3 times though... so it knows about my 3 drives in RAID
<apteryx>then Linux prompts me 3 times again (it's a pain, yes)
<apteryx>rekado: we'll have to mark the old partitions as needed-for-boot? #f and re-init with that
<apteryx>otherwise the boot would get stuck not finding these
<apteryx>(if the disks are physically pulled out or disconnected from BIOS)
<apteryx>perhaps 'mount? #f' too for good measures
<rekado>sounds reasonable
<rekado>but … what shall we do in the short term about the big problem?
<apteryx>rootdelay=20 ?
<rekado>is that really all?
<apteryx>I'm hoping so
<apteryx>otherwise I don't get it
<rekado>we *don’t* have the problem that linux thinks the root fs isn’t there
<rekado>the problem is IIUC that it *continues* even though not all disks are there.
<apteryx>that's expected, as we are using the 'degraded' mount option
<apteryx>which allows to mount the RAID with a missing (or more as we've found, albeit in read-only mode) drive
<apteryx>if we remove that option I'm confident the boot will halt on the error
<rekado>here’s the full output of the second failed boot:
<rekado>for reference
<rekado>I have to leave now, but I’ll be back in a few hours.
<apteryx> 62.489685] BTRFS info (device sdb3): allowing degraded mounts
<apteryx>I'll review it, thanks
<nckx>So… 16 drives are probed (sda..sdp). Is that too few? The UUID refs do my head in.
<nckx>(But then:, I don't really understand what this layout is supposed to look like.)
<apteryx>that's a lot; there should be 6 SSDs, and 2 more drives
<apteryx>but there's this HBA thing which gets loaded at some point, perhaps it's not helping
<apteryx>nckx: uh: 62.448504] BTRFS: device fsid 16ff18e1-eb41-4224-8df6-80d3b53c411a devid 3 transid 58045 /dev/sdd3 scanned by udevd
<apteryx>so udev is running at this point, and still the drives are not found?
<nckx>My btrfs command-line-fu has bitrotted to a ridiculous extent 🎉
<mroh>Same for my git cli-fu, "thanks" to magit ;)
<nckx>So for lines like ‘devid 1 uuid 05e90cad-0368-4b90-a796-d522c89f867d is missing’ I'm not finding anything in /dev/disk/by-anything. That's not expected is it?
*nckx shrugging intensifies.
<nckx>mroh: I've given up on magit a few times for the opposite reason; ‘I know exactly how to type this at the prompt, but… now was it C-space M-power-button or C-router-WPA-button in magit?’.
<nckx>*WPS. Fail.
<rekado>nckx: lsblk shows these uuids
<rekado>oh, wait, you are right. Mixed up the uuid with one reported earlier by apteryx
<apteryx>nckx: I see 16ff18e1-eb41-4224-8df6-80d3b53c411a under /dev/disk/by-uuid/ on the booted berlin
<apteryx>ah, fell in the same trap
<nckx>That's the whole file system.
<acrow>I would like to examine outputs of a check phase but guix build -K <pkg> doesn't preserve it??
<nckx>It should?
<acrow>when the build succeeds.
<acrow>Of course I can just break it. That's never too hard.
<nckx>In such cases I just (add-after 'check 'punt (lambda _ punt)) — not pretty but it works.
<nckx>‘Breakpoint support’ 👍
<acrow>Good enough.
<acrow>I'm also interested in reproducibility. I just read a great blog post on it.
<acrow>But, how do you verify your build is reproducible? Just build it twice and see that the hashcodes match?
<unmatched-paren>acrow: `guix challenge` :)
<unmatched-paren>oh wait no
<unmatched-paren>sorry, misread your question :P
<unmatched-paren>i believe you can pass `--rounds=<N>` to `guix build` to build stuff multiple times, and it'll detect determinism automatically
<acrow>Ah, that seems right. If I just build twice I think the second build just returns what has been put in the store, no?
<unmatched-paren>not if you do --rounds i think
<unmatched-paren>let me try
<unmatched-paren>hm, yes, you're right
<mroh>try adding --check
<unmatched-paren>thanks, mroh
<acrow>The output is understated. Just the same result as if the rounds command had been omitted. Seems like a 'tada' might have been justified... maybe that only happens if --rounds>=10 :)
<nckx>(display "🎉🎊\n")
<unmatched-paren>acrow: try `guix build --rounds=3 --check nnn`
<unmatched-paren>(nnn for no reason in particular, it's just a small package that builds fast and that i didn't previously have -.o.-`
<acrow>I think --check is the same as --rounds=2 but with better output, no?
<unmatched-paren>oh, really? cool
<acrow>unmatched-paren: thank you -- that put me back on track.
<unmatched-paren>the cargo-build-system seems to handle local deps poorly
<unmatched-paren>if i have a `foo = { version = "*", path = "../foo" }` in a Cargo.toml, the `package` phase fails
<unmatched-paren>error: failed to prepare local package for uploading
<unmatched-paren> no matching package named `foo` found
<unmatched-paren> location searched: registry `crates-io`
<unmatched-paren>why is it looking in `crates-io` when `path = ...` is directly specified?
<unmatched-paren>this is a project with a monorepo and multiple modular crates
<unmatched-paren>some of them refer to the others via `path = ...`.
<singpolyma>I expect it's patching the dependencies to match the inputs
<singpolyma>And needs to just not patch those ones maybe
<acrow>I think I was wrong with --check == --rounds=2. Now I think they are two separate steps in the process.
<acrow>--check verifies that derivations are reproducible but then you still need to run --rounds=N to check that the subsequent builds are also reproducible.
<unmatched-paren>according to `guix build --help`:
<unmatched-paren>- -check rebuild items to check for non-determinism issues
<unmatched-paren>--rounds=N build N times in a row to detect non-determinism
<singpolyma>Should add a flags like --every-day-of-week --each-month --leap-day ;)
<acrow>unmatched-paren: I have never used cargo but faced with packaging something with that I'd give the guix importer a go before digging into the cargo manuals. Have you given that a try?
<unmatched-paren>problem: the crate in question is not on
<unmatched-paren>ah, i see
<unmatched-paren>Note: does not allow packages to be published with path dependencies (path dev-dependencies are ignored). See the Multiple locations section for a fallback alternative.
<phf-1>Hello Guix! How does Guix play with CI/CD? Is there a "good" post of doc that shows how to use Guix in a CI/CD pipeline?
<unmatched-paren>but it looks like this *should* work
<unmatched-paren>it looks like it's completely ignoring the `path = ...`??
<unmatched-paren>i'll try building with --keep-failed and poke around a bit (i am patching this Cargo.toml, so that's probably why, but it still /should/ be working since the substitute* seems to be correct to me)
<acrow>unmatched-paren: I empathize, code attachment is blinding and seems only resolvable with patience.
<acrow>determination too but suffering is not required
<singpolyma>phf-1: how exactly do you want to use it? I run most of our company's CI on guix
<phf-1>singpolyma, wow! Great :)
<apteryx>rekado: is the 36.4T disk (/dev/sdh), the one currently holding /gnu/store a single HDD or somethnig else?
<florhizome[m]>Hey guix, zeitgeist ist failing to build because of dee
<phf-1>singpolyma, well, we are just starting. The idea is to go from a package to a tested `.deb'
<florhizome[m]>probably relevant for a couple packages
<singpolyma>phf-1: by package you mean a guix def?
<phf-1>singpolyma, yes.
<singpolyma>And you'll make the deb with pack? Or you want a "normal" Deb?
<singpolyma>I deploy with guix so I use guix archive --no-grafts for our deploy
<rekado>apteryx: that’s the external disk enclosure
<rekado>it’s the one connected via the HBA card
<phf-1>singpolyma, in between, it would be good to have: 1) a package repository 2) a substitue repository. With that in place, the workflow would be: 1) git commit, 2) git push 3) package is built on a build machine 4) the depot is updated and the substitue depot is updated 5) test pipeline begins 6) guix install $pkg_to_be_tested 7) tests are ran 8) .deb is built.
<rekado>it presents itself as a single disk, but it’s … somewhere between 10 and 16 disks
<rekado>I keep forgetting
<phf-1>singpolyma, .deb made with guix pack
<phf-1>singpolyma, is your workflow documented somewhere? do you use Gitlab or similar? if not, what do you use?
<apteryx>rekado: would you mind joining #btrfs? someone (Forza) is keen to help, but they are asking many physical details I lack
<singpolyma>phf-1: AFAIK no one really knows how substitutes work, so you need a machine running guix and use guix publish or whatever for that. If you use guix archive you can get similar effect but it works different not as a channel but you can still install without building again
<rekado>but that disk enclosure is nothing to do with btrfs
<singpolyma>phf-1: we use, I'll grab an example build recipe for you
<phf-1>singpolyma, Great, thank you.
<singpolyma>If you have any questions about what we do I'm basically always here :)
<unmatched-paren>my substitute seems correct
<phf-1>singpolyma, I will document that and publish it on :)
<phf-1>singpolyma, thank you. I'll probably ask for help again and make sure to share that for others too.
<nckx>florhizome[m]: So fixing dee was easy, but not sure how to fix zeitgeist…
<nckx>where-clause.vala:219.35-219.63: error: The name `pdata' does not exist in the context of `GLib.PtrArray*'
<nckx>Do u kno the vala.
<Guest99>Hi, is there any way to define an my-os that is an inferior? Like say you run guix system reconfigure config.scm where config.scm returns something like (lookup-inferior-os inferior my-os) ?
<Guest99>Im looking for a way that you don't have to use time-machine or guix pull --commit directly, so that just a regular guix system reconfigure would be sufficient.
<nckx>florhizome[m]: Try again, I don't use Zeitgeist.
<vivien>Does someone have an example in gcrypt to verify an ECC (DSA) signature with literal sexps? Same question for RSA PSS?
<civodul>Guest99: hi! i suppose you'd instead want to do something like: guix time-machine --commit=XYZ -- system reconfigure config.scm
<civodul>vivien: did you check the gcrypt manual? i think it contains examples like that
<florhizome[m]>nckx: me neither, was trying to build sth that uses it^^
<vivien>civodul, the manual that’s on guix only has an example for how to generate a key pair
<Guest99>civodul: basically I want to keep a dynamic config.scm that looks at what commit it will be deployed as, and depending on some condition return an inferior or not - the time-machine option would not be dynamic.
<florhizome[m]>nckx I need your dee anyways or you merge it ^.–
<nckx>Zeitgeist builds now.
<anticomputer>what's the canonical way for guix based users to bootstrap development environments, just through manifests and profile activations or do folks stack gcc etc. into their base system configs as well? trying to decide whether I want to keep a minimal base system with many profiles, or a full base system with special-case profiles
<civodul>vivien: you're looking at rather than, no?
<vivien>Oh the info manual for gcrypt has a lot more options that what I have on the internet
<vivien>I can’t see more examples though
<unmatched-paren>i think i've nearly resolved it... by wiping the dependency entries from Cargo.toml... it works, but it will probably cause other issues
<unmatched-paren>note that this is *after* the build, so the dependencies are still compiled in
<vivien>civodul, for instance, this doesn’t work:
<vivien>I don’t understand why.
***lukedashjr is now known as luke-jr
<civodul>vivien: could it be that you need special flags for (data ...)?
<civodul>info "(gcrypt) Cryptographic Functions"
<civodul>it's kinda annoying to debug
<civodul>(a good example of why not to use sexps in lieu of dijoint data types!)
<vivien>This is so frustrating
<vivien>My search-engine skills can’t find an example of use
<florhizome[m]><anticomputer> "what's the canonical way for..." <- I would say; more profiles for sure
<unmatched-paren>does (display "foo" port) append to port or overwrite it?
<jeko>Yoooo Guixters
<kitty1>yo uwu
<apteryx>nckx: I've found the code initially written for rootflags (then called --root-options):
<castilma>when creating a guix pack with --relocatable, the content need to get rebuild to use relative paths to the dependencies. Why isn't everything by default built that way? this would prevent a rebuild for sharing, and I don't see any downsides. this was also proposed by
<castilma> (very interesting talk)
<civodul>castilma: nothing gets rebuilt: the original executables are just wrapped, and the wrapper takes care of simulating /gnu/store one way or another
<unmatched-paren>ok, apparently cargo-build-system just doesn't like cargo workspaces at all, i have to replace the install phase
<civodul>and the followup at
<civodul>castilma: ↑
<castilma>civodul ah, okay. But now we need wrappers. As far as I understand, you wouldn't need any wrappers, if the binaries are built with rpath=../../...-libc-../lib/ instead of /gnu/store/...-libc-../lib/
<jonsger>what is `~A` for a kind of type in guile/guix? and how can I convert a string (~S) to it?
<castilma>(or actually rpath=$ORIGIN/../../...-libc-.../lib/
<civodul>castilma: yes, but $ORIGIN solves just part of the problem; it doesn't solve other references embedded in files, such as references to data, locale data, etc.
<the_tubular>I want to add a guix channel but for every user.
<the_tubular>So I should put the channel.scm file in /root/.config/channel.scm right ?
<castilma>I see. So one would need to manually adapt every software that hardcodes an absolute path and make that somehow turn into a relative path from the binary...
<the_tubular>Or can I directly pass the chanel in my config.scm ?
<apteryx>nckx: I was looking at a75a3d71329 because I'm resuming from that era to add rootflags, and I noticed that it changed the behavior of --root; it used to be optional, but is now required to mount the root file system.
<apteryx>it's documented as "When unspecified, the device name from the root file system of the operating system declaration is used." in (guix) Initial RAM Disk
<Haider>Exited for the online conference! I Liked the pre-recorded talks.
<Haider>only a few days until the conference
<unmatched-paren>paren@guix-aspire ~/code/helix$ hx --version
<unmatched-paren>helix 0.6.0
<unmatched-paren>woohoo! \o/
<unmatched-paren>jgart: you said you were interested in
<unmatched-paren>if i remember right
<Haider>Helix looks great. Cant be as good as Emacs though :)
<apteryx>nckx: if that's not deemed useful (it probably isn't since nobody complained about it in a year) we could simply adjust the doc
<unmatched-paren>i decided i didn't like emacs that much
<unmatched-paren>after a while of using it with a pretty largish config
<unmatched-paren>helix doesn't have plugins yet, but that's fine since pretty much everything i need is there out of the box
<Haider>Language servers inbuilt seems quite cool
<unmatched-paren>they're planning to use wasm for plugins, which is an interesting idea since you'll be able to write the plugins in any language that support compilation to wasi
<Haider>That is a quite interesting idea. Certainly has potential
<unmatched-paren>tbh that's a far better use of it than what it was actually intended for :)
<nckx>apteryx: The change in behaviour was obviously unintentional (I even clarified the comment — to be, er, wrong).
<nckx>It is notable that nobody noticed though.
<unmatched-paren>i'm planning to publish it on my guix channel, since it requires tree-sitter. the patch to add that to mainstream guix has... uh... stalled somewhat...
<nckx>apteryx: That patch set went through *a lot* of churn, I'm not entirely suprised at this.
<unmatched-paren> has not had activity for ages
<unmatched-paren>note that it's actually outdated now; tree-sitter 0.20 is now a thing
<unmatched-paren>also: my helix package currently has a C blob emitted by the tree-sitter compiler
<unmatched-paren>so not ideal...
<unmatched-paren>s/a C blob/many C blobs/
<unmatched-paren>it's easily fixed, but it requires a change to node-build-system (like in that patch)
<apteryx>nckx: haha. So perhaps I can try to re-add that behavior because it'll go in the direction I'm going (making the init ram disk more... flexible/intuitive)
<nckx>Ah, OK
<unmatched-paren>one more thing: the helix package builds from master, so i'd need to make it use stable 0.6 before upstreaming
<nckx>If you're just going to clobber the whole thing (which is good!) I won't waste time on it?
<apteryx>yes, probably ^^
<apteryx>well, I'm not sure what I'll do yet, I'm only after adding rootflags but we'll see.
<nckx>I'll test the change I just made (based solely on ‘guix show a75a3d71329’ with 0 context, so may well be wrong) but stop if it was bogus.
<apteryx>OK! I'll be thankful to start from a consistent base whatever it is :-)
<the_tubular>I'll reask my question, what's the best way to include a custom channel if I want to use it with guix deploy ?
<the_tubular>Can I pass the channels directly into to conig.scm ?
<the_tubular>into the config.scm *
*nckx doesn't know.