IRC channel logs


back to list of logs

<noobly>guix system error: some substittues... ...; try --fallback to build derivation from source
<noobly>like this "guix --fallback system init /mnt/etc/config.scm /mnt ?
<noobly>i only ask this dumb question because last time I had guix running I made some mistake involving fallback
<noobly>and what does it imply that there is now an `efi.img` in '/'?
***jonsger1 is now known as jonsger
<guix-vits>noobly: did you use btrfs with zstd compression on any of your file systems?
<noobly>so upon running 'guix system --fallback init /mnt/etc/config.scm /mnt' I get a weird error: no space left, while 'df -h' returns /dev/sda3 (root) with merely 2% used, and some weird 'none' filesystems of ~992M size, one of which that is 100% used. Does this sound familiar to anyone?
<noobly>guix-vits: no, not that I know of
<nckx>noobly: Which mount point is full? Are you sure you ran ‘herd start cow-store /mnt’ this session?
<nckx>That efi.img sounds odd to me but I don't have an installer handy.
<noobly>nckx: i did not run such a thing :o
<noobly>ouch, looks like i glossed right over that
<nckx>noobly: Ooch.
<noobly>am i ded?
<noobly>or do i just run it now?
<noobly>i probably should've just started from a clean slate this morning rather than trying to save my botched install
<guix-vits>noobly: hint: you can access the "Installation Instructions" at tty2.
<noobly>guix-vits: yeah, that's what I've been using
<nckx>You're not in a great situation: Guix has (not unreasonably) started to download and build your system in /gnu, however in the installer, /gnu is entirely in your RAM. The only way to free it would be to run ‘guix gc’ now, but it's probably better to start from scratch. You'd be re-downloading everything in both cases. Just save your connfiguration and restart the installer IMO.
<nckx>Fiddling and copying things is just more error-prone risk at this point.
<noobly>ok, i've 'cp /mnt/etc/config.scm /', that should be saved onto the bootable media persistently right? and when I start my new fresh install, I shouldn't have to repartition, right?
<noobly>thanks for the help
<guix-vits>noobly: Try to customize as less as you can (before installation is ended).
<nckx>noobly: No! Nothing is saved on the installer medium, there is no persistency service whatsoever.
<nckx>You can copy it to /mnt or to another USB drive.
<guix-vits>noobly: also i'd "unclean unmount" after using Ctrl + Alt + Del. First unmount all in /mnt (umount -R /mnt), then reboot (BTW, `reboot` on installed system seems to work good).
<noobly>guix-vits: I have been sticking strictly to defaults as much as I can, previously my error (I believe) was that the installer recommend UEFI/GPT setup when I am in fact BIOS/GPT
<noobly>then my cat or something screwed up attempt #2 resulting in todays mess
<nckx>As a cat owner I 100% believe that excuse by the way.
<noobly>guix-vits: thanks, I'll do that now
<nckx>noobly: You saw my no above, right?
<noobly>yes, I copied to /mnt
<noobly>just gotta remember no repartition
<guix-vits>noobly: XD
<nckx>noobly: Removing everything but /mnt/etc/config.scm from /mnt before the final ‘guix system init’ will result in a new clean system, no need to reformat/-partition.
<noobly>guix-vits: what exactly are your instructions? first 'umount -R /mnt', then reboot? is that all or do I need to do the cntrl+alt+del thing?
<nckx>noobly: As long as /mnt is unmounted it doesn't really matter. Hard reset, C-A-D, ‘reboot’, … it's up to you. C-A-D is fastest.
<noobly>nckx: hopefully last dumb question for awhile, so I need to then ensure I remove everything but /mnt/etc/config.scm from /mnt before running the final guix command, manually??
<noobly>nckx: never realized that was the hotkey for that
<nckx>You don't need to but let's, just to avoid any left-overs.
<guix-vits>noobly: it should be easy: `cd /mnt; ls`, `rm -rf ...` -- type all you see above, but etc.
<noobly>guix-vits: thanks, so internet connection is backup, partitions remain the same, swap is on.. I have mounted my root partition (/dev/sda3) to /mnt, should I run that command now?
<noobly>ok, and just to clarify if I have other files under /etc I should delete those too? I have group passwd and shadow as well
<noobly>tmp is a fat one
<noobly>no match for rm -rf though
<nckx>You can delete everything except etc/config.scm.
<nckx>noobly: ‘No match’?
<noobly>ok, awesome. then proceed as normal with herd start?
<guix-vits>noobly: i'm dare to recommend to you to use Arch Linux for a month, or so. They have all maded in easy way, with greatest Wiki ever. And their configs are not require you to know Lisp (and it is allowed to directly edit them). Also they have a "Post installation advices" (Firewall, Power-save, Service (systemd) management, etc...). You will return there then, if want. Just in Guix you even have a 'performance' set as a default
<guix-vits>cpu-scaling-governor, and possibly such.
<noobly>nckx: i was just joking around, probably picked bad terminology, lol. I meant that despite tmps fat size rm would still kill it
<nckx>noobly: No, I was just too stupidly literal-minded to read it as colloquialism >_< I blame looking at regexps for the past 10 minutes.
<noobly>guix-vits: I've used Arch before, I'm coming from several years of Gentoo and Emacs, use believe it or not.
*nckx often feels like the only person who's never used Arch.
<noobly>guix-vits: I have actually used guix before, believe it or not ;)
<noobly>ok, cow store started and guix system init command ran, hopefully in 24 hours I have a successful install :)
<noobly>thanks for the help, guixs
<nckx>noobly: You might want to run something like ‘until guix system init …; :; done’ if there's any chance your network might be flakey.
<nckx>Would be a shame if your machine sat idle for most of the night after a transient error.
<noobly>there's no harm in killing the current guix system init process right now and rerunning it like how you suggest, right?
<nckx>noobly: None at all.
<guix-vits>nckx: Arch is about the just a few things to do yourself, from a list of things that maintainers did already (this or that good) elsewhere. But it helps (a lot) one to notice the existence of those things.
<nckx>Guix (and Nix) is probably the most transactional package manager on earth.
<nckx>There are edge cases like ‘power failure halfway writing your literal boot loader’ but y'know what I mean.
<guix-vits>nckx: laptop, sir...
<nckx>guix-vits: If all your laptops have working batteries & can't die from overheating you are a lucky vits.
<nckx>To be honest the reason I've never considered using Arch is that I don't think I'd learn anything new. And then all that remains is the tedium of doing stuff by hand.
<drakonis>nckx: writing the bootloader data is such a short amount of time that if would be unlikely that it would break
<drakonis>unless its a freak accident
<nckx>drakonis: YOU WOULD THINK
*nckx must be a very lucky mcdude.
<drakonis>wait, it happened to you?
<noobly>nckx: have you done LFS?
<guix-vits>nckx: true, most of those can be managed with GUI these days. And books is probably better.
<noobly>i can't figure out how to do that bash loop proper
<nckx>drakonis: Uh huh. Not quite as dramatic as I made it sound (I didn't end up with half a stage1), but 3 or so GRUB modules were missing. That was a fun debug.
<nckx>noobly: Yup.
<noobly>nckx: had a feeling given the educational remark, it's on my list. unfortunately the only time I really interface with my OS are few and far between, like migrating machines or drives
<nckx>So let me rephrase my marketing: Guix, it's probably more transactional than your underlying filesystem.™
<noobly>in the guix image/bootable media, is there a way to jump to guile function definitions?
*nckx dunno. Does it even have emacs? You can always switch to another VT and ‘guix install $your_favourite_packages’. It's a real Guix System.
*guix-vits test
<noobly>I just mean like when I'm trying to install, I read things like (bootloader .., it would be nice to see a docstring or jump to function definition
*guix-vits /ME it is
<guix-vits>noobly: better do it after the installation ;) This file should be still there.
*guix-vits start to fear noobly
***guix-vits is now known as scarred-guix-vit
<nckx>noobly: Sorry, missed your message about the loop: until <command>; do :; done
***scarred-guix-vit is now known as scarred-guixvits
<nckx>‘:’ is just shorthand for ‘true’, do nothing successfully.
<noobly>guix-vits: lol, it just would've been potentially helpful during the install is all, im sorta surprised that functionality isn't built-in
<noobly>nckx: ah ok, that's what i missing
<noobly>nckx: how long did LFS take you to complete?
<noobly>it's been on the bucket list for awhile now
<scarred-guixvits>noobly: "The until command is identical to the while command, except that the test is negated: ... executed as long ... returns a NON-zero exit status"
<scarred-guixvits>until echo foo > /restricted_file.txt; do echo bar; done
<nckx>noobly: Honestly I can't even guess, it was years ago and I was at university.
<scarred-guixvits>noobly: until SMTH_STOP_TO_RETUR_ERROR; do WORK; done
<noobly>thanks, scaredy cat :-)
<noobly>nckx: oh, it was like a classroom setting that you did it? that's cool!
<nckx>Oh, no, not at all. Just me. At home. At night. Nothing has really changed.
<noobly>yeah i need to do that
<noobly>i've used linux for so long but i'm still so inept
<noobly>well thanks again for the help fellas, nighty night
***scarred-guixvits is now known as guix-vits
<sturm>When using Trisquel's Emacs I can open a PDF and it renders inline automatically, but I've never been able to do this in Guix System's Emacs. Can other people open PDFs in Emacs?
<bandali>i think emacs ships with doc-view-mode no?
<bandali>actually, pdf-view-mode seems to be what is used
<bandali>works fine for me
<bandali>there's also emacs-pdf-tools
<sturm>yes, doc-view should be default as far as I'm aware - emacs-pdf-tools is an alternative
<nckx>sturm: PDFs open in DocView in my Guix emacs 26.
<bandali>if i do M-x doc-view-mode it attempts to display the PDF raw, but the default pdf-view-mode when opening PDFs works fine for me
<sturm>thanks nckx, interesting... no different if I `emacs --no-init-file`
<nckx>grep -i doc .emacs returns nothing, nor does guix package -I emacs.*pdf, if I changed something I have no idea what.
<nckx>And if you M-x doc-view-mode C-c C-c (I think)?
<guix-vits>nckx: C-c C-c doesn't works for me. i'm using emacs-no-x.
<jackhill> suggests that a helper program is needed to create a raster from the pdf.
<nckx>guix-vits: Displaying PDFs is an X-only cool kidz klub activity.
<nckx>jackhill, sturm: Aha. I do have mupdf installed.
<jackhill>The other day when I tested by adding ghostscript to my profile, it worked (although, I found the default ghostscript output left a little bit to be desired as I could see artifacts)
<jackhill>nckx: oh, cool, I'll have to try mupdf over ghostscript
<nckx>*Reading* Guess who's going to package unoconv today…
<guix-vits>nckx: i'm was able to see one (distorted) page from a pdf document with a `kitty +kitten icat ...`
<guix-vits>nckx: ;)
<nckx>guix-vits: From within emacs?
<guix-vits>no, but close to it XD
<nckx>Oh, I love the framebuffer. Used to use fbpdf and fb links as my main document readers…
<nckx>Weird happy X-less year.
<sturm>thanks nckx: i'll do some testing
<sturm>nckx: I've installed mupdf and tried `emacs -q` again but no luck. On the right track by the looks of things - the messages buffer shows "No PNG support is available, or some conversion utility for pdf files is missing."
<guix-vits>sturm: imagemagick package?
<nckx>I has it.
<sturm>guix-vits: yes, imagemagick is installed
<sturm>Ghostscript `gs` doesn't seem to be though - maybe I need that
*guix-vits singing De-pen-den-cies De-penden-cies
*guix-vits was caught by gang of dependencies
<sturm>yay, it was ghostscript!
<sturm>thanks nckx, bandali, guix-vits for your help
<nckx>With our powers of installing random packages combined, we are unstoppable.
<sturm>made me laugh
*nckx goes to bed while libreoffice builds. Good night!
<bandali>cheers sturm
*bandali unlike nckx waits for ci.guix to build libreoffice for them
*guix-vits looks in wikipedia what is libreoffice, and can he play as paladin in it, and if it has a multiplayer
<ArneBab>hey, I just discovered that the pam-limits-entry for nofile finally works! Thank you for fixing it!
<ArneBab>(⇒ one less hack required)
<guix-vits>ArneBab: Hi. The hack: what was it is?
<ArneBab>guix-vits: the hack was `for i in $(pgrep .); do sudo prlimit --pid $i --nofile=1000000:1000000; done`
<ArneBab>Because our sourcetree at work is large enough that the normal open files limit does not allow building with maven.
<Gooberpatrol66>when I try to mount an NFS share, it says "bad option; for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program." But I already have nfs-utils installed. What gives?
<DamienCassou>hi everyone
<ArneBab>guix-vits: I guess I should blog the hacks I use …
<guix-vits>Gooberpatrol66: try to logoff then login in graphical session (or even reboot). I'd similar issues with GCC recently. str1ngs said that there is some variables that need to be re-set, or such. Which program do you use to mount the share?
<Gooberpatrol66>mount command
<guix-vits>try it in another tty?
<Gooberpatrol66>same issue
<Gooberpatrol66>i already re-logged
<Gooberpatrol66>it was actually throwing a different error before i relogged
<Gooberpatrol66>i needed to be root, even though the "user" flag was set in fstab
<guix-vits>See the `guix search nfs | less`: how about to install the "libnfs" package?
<guix-vits>Gooberpatrol66: chech your /etc/fstab, is user steel there?
<Gooberpatrol66>reboot didnt help
<guix-vits>Gooberpatrol66: maybe the dir to where NFS mounts is need to be user-writable?
***apteryx is now known as Guest77775
***apteryx_ is now known as apteryx
<guix-vits>Gooberpatrol66: Did you tried this: ("...we recommended to configure an NFS server with the nfs-service-type.")?
<guix-vits>emm.. Server. Maybe it's irrelevant.
<civodul>Hello Guix!
<guix-vits>Hello, civodul. Are you by chance didn't know how to configure a NFS non-root mount in Guix? Gooberpatrol66 currently struggle to know ;)
<DamienCassou>hi civodul
<civodul>guix-vits: dunno! there was a bug apteryx fixed recently in that area
<efraim>I realized we don't have a rust-packages section in the contributing section of manual, I'm typing something up now
<efraim>We also don't have one for go packages, I'll let someone else tackle that :)
<civodul>efraim: heh, good idea!
<kahiru>nckx: still about zfs. I have no modules directory in /run/booted-system/profile/lib
<efraim>civodul: can I get your help (later) on reviewing the cargo recursive import patches? The limited testing I've done shows it works as expected on crates. I assume we want guile-semver to be an optional dependency for a bit.
<guix-vits>kahiru: cd /gnu/store/*linux-libre-`uname -r|cut -f1 -d'-'` modules should be there, i THINK (not know).
<kahiru>guix-vits: no luck. the module is provided by the zfs package, so I guess it will live somewhere else
<guix-vits>kahiru: find /gnu/store -maxdepth 1 -type d| grep '.*zfs-.*' ?
<efraim>the module is in the "module" output of the zfs package
<jetomit_>hi all
<jetomit_>there seems to be a typo in the bootstrap script
<jetomit_>in line 18 "guix-manual" should be "guix-cookbook" I think
***jetomit_ is now known as jetomit
<nckx>kahiru: You can read previous messages at
<nckx>jetomit: Here, it is.
<allana>Hi, I reconfigure my guixsd system every few days. That has worked well for me until today. An hour or so ago I reconfigured my system and upon the next boot, the boot process did not get past dns-resolving and I was not presented with my normal GDM-login prompt. Reverting back to a previous generation worked as expected. I'm here now to report this issue and maybe provide details if there is anyone who can direct
<allana>"as expected" means that my previous generation booted normally.
<allana>And there have been no changes to my system configuration.
<jetomit>err line 19 that is
<guix-vits>allana: did your disks configuration changed physically changed LABEL, or such?
<nckx>jetomit: Do you mean line 19? That looks fishy.
<nckx>…never mind 🙂
<allana>guix-vits: no
<jetomit>nckx: yeah, I think commit f98e83a uncovered this
<allana>Funny thing -- I am sending http requests to and getting varied responses. Perhaps a physical machine is being updated
<allana>Now I am getting an Apache 2 Debian default landing page
<nckx>jetomit: Yes, it's definitely a typo. I've fixed it now.
<allana>Maybe there is something to this, I will try to boot my latest (supposedly broken) generation and see what happens and rejoin #guix in a few moments.
<jetomit>nckx: thus beating the lowest report-to-fix time I have observed so far :) thanks!
<nckx>sneek: later tell allana: I get this, but returns ‘OK’ so it might not be relevant.
<nckx>sneek: later tell allana: …now the page has been replaced by ‘test page’ without enabling cookies so it probably was.
<sneek>Will do.
<nckx>jetomit: I wish all bugs were this easy to fix; they'd all be fixed that quickly 😉
<allana>so, to continue, I have reconfigured my system today. No changes to my system configuration, and shortly after a successful guix system reconfigure my new system never finishes booting up and presenting GDM. The boot process seems to try to resolve and fail repeatedly. Booting a previous generation will "boot normally", meaning that it is able to reach a GDM login prompt.
<sneek>Welcome back allana, you have 2 messages.
<sneek>allana, nckx says: I get this, but returns ‘OK’ so it might not be relevant.
<sneek>allana, nckx says: …now the page has been replaced by ‘test page’ without enabling cookies so it probably was.
<nckx>allana: Did it work? now redirects to Something was definitely happening just now.
<allana>sneek: I saw what you shared wiht your paste originally, and then I saw the debian-apache landing page.
<allana>nckx: It did not work, but I am happy to try again :-)
<nckx>Are you sure that NTP failures are to blame? Is there anything else fishy in the logs/terminal?
<guix-vits>sneek: botsnack
<nckx>I don't actually think this would be fatal.
<allana>nckx: I am absolutely not sure -- where would you look?
<nckx>Eh, that's where I can't help you, I don't use GDM. Most general messages are in /var/log[/messages].
<nckx>This is the only bug I know about that could be relevant:
<allana>I'm using the reference to GDM as a reference point, it doesn't get that far when booting my newest generation, I just see ntp complaints every minute or so
<nckx>allana: But any errors before those NTP ones?
<allana>nckx: not that I know of. I do see this in my current generation: Feb 17 12:02:56 localhost ntpd[307]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
<nckx>That's ‘normal’.
<guix-vits>nckx: to check if this is a GDM issue, maybe allana need to ;; gdm, and install another DM? if it isn't helps, change the same way the DE/WM? And if this isn't helps, then ...?
<allana>nckx: I'm not sure what is normal and what isn't. For example, I see this: WARNING: No NSS support for mDNS detected, consider installing nss-mdns!
<nckx>allana: That's completely understandable, there are quite a few things printed during boot that are harmless but sound scary. And that's unfortunate.
<nckx>If your failed boot is actually logged, you can paste the whole thing (but only that boot) at or so.
<allana>nckx: I am going to do a new reconfigure and reboot, and then share a paste. Thanks
<nckx>Good luck.
<civodul>efraim: ah yes, not sure about adding guile-semver as a dependency
<civodul>i'll take a look
<guix-vits>nckx: i'm remember an cartoon: character are constructs an airplane, and says upon completion (gesturing a to big pile of gears): "I'm wonder, why do they sold to me so many unneccesary parts?". It was wonderful :)
<nckx>guix-vits: That's an option, if they think GDM is to blame. They don't seem to think so, and NTP is probably also a red herring. Still too many unknowns to help IMO.
*nckx away.
<kahiru>efraim: I know that, but there is several of those, only with different hashes. some of them give "unknown symbol" errors when I try to load them. I'm looking for a reliable way of getting the one I can load
<kahiru>or ideally having it loaded at boot time and not having to worry about it
<guix-vits>kahiru: modinfo FILENAME_OF_ZFS_MODULE | grep filename
<guix-vits>it should show which file it is for a current kernel, probably. like /run/booted-system/kernel/lib/modules/5.4.18-gnu/kernel/drivers/gpu/drm/nouveau/nouveau.ko
<guix-vits>for `modinfo nouveau`
<guix-vits>allana: Hi! how do you do? ;P (Emacs rules)
<allana>guix-vits: thanks, yes, and ERC is quite a nice IRC client :-)
<allana>nckx: here is the paste: -- BRB, I have to step away for a few minutes
<guix-vits>allana: line 593, "Service dockerd could not be started". What if you try to disable docker for a test?
<guix-vits>allana: line 295, "Service term-auto could not be started". Is agetty needed to make GDM work?
<guix-vits>allana: line 580, "ovsdb: Could not connect: No such file or directory". i've no idea what it is.
<guix-vits>allana: Cancel the 295, i've the same.
<guix-vits>allana: Cancel the 580, i've the same.
<guix-vits>allana: You can try to remove "quiet" at the next boot, in GRUB, to see more messages.
<guix-vits>during boot
<nckx>guix-vits: modinfo won't work here. kahiru: Please read the logs, I went through some trouble to paste the exact paths yesterday.
<nckx>insmod /run/booted-system/…/`uname -r`/something will work every time and always match the booted kernel.
<guix-vits>nckx: but "Most users will want to use modprobe(8) instead, which is more clever and can handle module dependencies.", why use the insmod?
<kahiru>you mentioned /run/booted-system/profile/lib/modules/`uname -r`/extra/zfs/zfs.ko, but i have no modules directory in /run/booted-system/profile/lib
<nckx>Did you add the module output of the zfs package to your system configuration?
<nckx>guix-vits: Because modprobe won't find these ‘external’ modules until is closed.
<guix-vits>kahiru: /run/booted-system/kernel/...
<kahiru>nckx: just added zfs to packages, not sure how to add module output. what does that even mean?
<kahiru>guix-vits: that does not include out-of-tree moduels
<guix-vits>kahiru: got it :)
<guix-vits>nckx: Thanks!
<nckx>kahiru: Well, I know you didn't, it was a rhetorical question 😛 (specification->package+output "zfs:module") will definitely work. Dunno if there's a gexp notation that actually works.
<nckx>So (packages (cons* foo bar (specification->package+output "zfs:module") %base-blah)).
<kahiru>ahh. is this documented somewhere?
<nckx>Heh. I don't know. :-/
<jlicht>hey guix
<nckx>I'm pretty horrible when it comes to ‘welp, that works, now to never touch it again’.
<jonsger>morning guix
*nckx tips fedora.
<nckx>allana: I have no idea if ‘Feb 17 12:20:43 localhost gdm: Child process -318 was already dead.’ is suspicious.
<allana>guix-vits: Thanks, will disable the docker-service and retry. Then, if that's the case, I may need to file a bug report bout Docker because I need that :-)
<nckx>You might want to check the GDM logs anyway.
<guix-vits>allana: it is VirtualBox?
<allana>nckx: ok
<nckx>allana: term-auto failing is fine.
<allana>guix-vits: yes
<allana>guix-vits: it is running under virtualbox
<kahiru>nckx: this is how I define packages in config.scm. I rebuilt the system and rebooted, still the same issue
<nckx>Hm. I'm going to add it.
<nckx>(Presumably efraim has a working ZFS set-up?)
*jonsger starts working on powerpc64le port again
<jonsger>dftxbs3e: whats the status on 64bit big endian?
<allana>nckx: I see one problem from "/var/log/gdm/greeter.log.1". Fatal server error: no screens found
<nckx>Oh. The big one.
<nckx>Lines before that should tell you why.
<guix-vits>nckx: (kahiru) `sudo guix install zfs:module` (not system wide, though)?
<nckx>guix-vits: Thanks, but I strongly advise against that, it can easily desync from your operating-system kernel.
<nckx>For no real benefit(?).
*nckx stuck in the ‘guix pull’ tarpit.
*guix-vits just had forget that they should be in sync.
<allana>nckx: A little above the previous message, "Screen 0 deleted because of no matching config section." And then further up, "No Layout section. Using the first Screen section." followed by "No screen section available. Using defaults." and "No monitor specified for screen 'Default Screen Section'"
<nckx>Building ZFS: 'really configure' phase. Lol.
<nckx>allana: You're reading it in the right order but X logs are pretty dramatic about errors and like to stretch them out over half the file. Could you paste it?
<allana>nckx: sorry, that got a little out of hand. paste is here:
<nckx>allana: So X tries (in order) vbox, DRI, framebuffer, and vesa (woot) but each fails. I'd compare this log against a successful one to see which one should have worked.
<allana>I have the successful one on the older generation as well.
<nckx>Hum. So the ‘modesetting’ driver should work, but it's being unloaded on the new system because of: (EE) open /dev/dri/card0: No such file or directory
<nckx>Your xorg package hash hasn't changed between the two, so I'm left wondering: kernel or driver regression?
<nckx> 🤷 Not really my area of interest I'm afraid.
<nckx>I buy the Intel and the pixels go.
<nckx>allana: You might want to start by looking for any relevant bug reports or commits (if that's your thing) between Linux 5.4.18 and 5.4.20.
<nckx>Run lsmod on both systems and diff the results.
<nckx>You know, wild guessing.
<nckx>What the hell. Why does ZFS behave differently from every module on my system.
<allana>nckx: Thanks for all of your help.
<allana>guix-vits: And your help, thanks to you as well.
<guix-vits>allana, nckx: There is should be a way to "freeze" the Kernel version?
<nckx>guix-vits: There's already the (kernel …) field that can take any kernel you like, including an older version from, say, an inferior.
<allana>nckx: so maybe I could set mine to 5.4.18 nd see what happens?
<nckx>I think so. My knowledge of inferiors is 100% theoretical.
<nckx>Commit 57bd483f6730ce0daa9479d9b7be3b8b4a152097 would be the one to use.
<civodul>new post!
<guix-vits>nckx: if some version will be listed for some pull in `guix search linux-libre`, it isn't an inferior? like 5.4.12 or such...
<nckx>guix-vits: I'm not sure what you mean. ‘Inferior’ is a declared older version of Guix from which you pull one or more packages into your (newer) Guix. It's not a value judgment, or something that packages are or aren't 🙂 See (guix)Inferiors, which needs love but should be readable.
<allana>nckx and guix-vits: Any idea what (kernel …) should look like? The manual doesn't offer any examples other than (kernel linux-libre) and I am not much of a schemer (yet).
<allana>something like (kernel linux-libre@57bd483f6730ce0daa9479d9b7be3b8b4a152097) ?
<guix-vits>allana: try like in (packages it is done: linux-libre-5.4.18
<janneke>hello Guix!
<nckx>allana, guix-vits: No, it wouldn't be that magical (and opaque).
<nckx>Complete guess based on the example in (guix)Inferiors:
<allana>guix-vits: didn't work
<nckx>Fixed guile-json typo:
<allana>guix-vits: "linux-libre-5.4.18: unbound variable" FYI
<nckx>allana: Guix doesn't create packages on the fly like that, it ships the exact version(s) and nothing more.
<allana>nckx: Trying your paste, thank you :-)
<nckx>Be prepared to see it crash and burn, this is pure guesswork.
*allana thinks that it's about time that I start learning scheme.
*nckx wonders what lookup-inferior-packages' NAME represents: it's not a spec, so why not take a symbol?
<guix-vits>nckx: it works.
<nckx>Holy crap.
<nckx>I am a wizard.
<guix-vits>i'm mean linux-libre-5. ...
<guix-vits>wait, sudoedit should first close file...
<allana>I'm still computing the guix derivation but it seems to be chugging along nicely.
<nckx>guix-vits: Linux-libre-5.4.18 won't work in an up-to-date Guix.
<allana>nckx: why wont this slightly older 5.4.18 not work with an up to date guix? Just curious
<nckx>allana: ‘Works’ was ambiguous, indeed. I meant that literally referring to the ‘linux-libre-5.4.18’ variable with a Guix that no longer has that kernel will fail, as you found out.
<allana>ok, new sytem to try. be back soon.
<allana>nckx: ah, thanks
<guix-vits>nckx: i was looked at
<guix-vits>nckx: (kernel linux-libre-4.19) works. but it is older a lot, of course.
<guix-vits>now it is install 4.19.102
<nckx>guix-vits: Indeed. 4.19 (and 4.14) are long-term supported kernels that are still shipped in Guix today. However, you can't specify e.g. linux-libre-4.15. With inferiors, as long as there was ever a Guix commit with linux-libre 4.15, you can.
<nckx>We're missing an interface to ask ‘which commit was that, Guix?’ but thanks to our disciplined commit messages using ‘git log | less’ and ‘/’ is quite nice.
<nckx>guix-vits: allana needed 5.4.18, which is ‘gone’ from guix, so they need to ‘ressurect’ it from commit 57bd483f6730ce0daa9479d9b7be3b8b4a152097. That's what that code snippet does.
<nckx>‘Pretend it's 2 weeks ago, now give me linux-libre.’
<efraim>nckx: not a terrible assumption, but I just packaged zfs for the challenge
<nckx>efraim: Damn.
<nckx>Do you have *any* idea why all my modules show up in the expected /run/…-system/profile/lib/modules/$uname directory except zfs?
<efraim>is it installed in your OS config?
<nckx>I'm using a custom kernel [version] and didn't override zfs's #:linux but I'd expect that to result in /run/…-system/profile/lib/modules/$different_uname, not a completely missing tree.
<nckx>efraim: Yes… let me quintuple-check.
<nckx>efraim: (packages (map specification->package+output (list … "zfs:module"))) which is how all my other modules are specified.
<nckx>I could add it as a gexp instead if you can remind me of a syntax that works 🙂
<efraim>anything interesting about the directory structure of zfs:module in the store?
<nckx>"zfs" is added in the same way and /profile/sbin/zfs does exist.
<nckx>efraim: /gnu/store/xp4kw3l260xhhkx6khkm2iynv9yldk1h-zfs-0.8.2-module/lib/modules/5.4.20-gnu/extra/zfs/zfs.ko
<nckx>Really nothing jumps out at me.
<efraim>so it should be there, maybe its a bug in how current-system is assembled?
<nckx>That was my next question, if system-union-whatever-thing filters by kernel version.
<nckx>Which would be inadvisable IMO, or indeed just a bug.
<nckx>OK, so nobody knows 🙂 Thanks for responding though! I was starting to doubt my sanity.
<kahiru>am I getting it right there's no way to get zfs to work right now?
<drakonis1>it requires extra steps
<nckx>kahiru: Not ‘no way’, just ‘hacky’. Unless you're using a custom (kernel …), insmodding the result of ‘guix build zfs’'s -module output in some right order (because, indeed, insmod doesn't do dependencies) will work just fine.
<drakonis1>out of tree modules are janky
<nckx>The plates spin fine if you start them all by hand.
<kahiru>I'll give it another try in the evening
<nckx>Welcome to young experimental OSes that gladly accept contributions from all 🙂 You're apparently the first to actually try using ZFS, which is cool.
<drakonis1>now this is what happens when you have a smaller userbase that hasnt covered a kitchen sink of use cases
<kahiru>I still need to wrap my head around how everything works
<nckx>Especially enterprisey ones like ZFS. Yes, people use it on their file server, but that's not what drives initial distribution patches.
<efraim>it might be as easy as merging all the zfs outputs into one
<nckx>efraim: Doing just that now.
<kahiru>guess I should just wipe my machine, slap guix on it and try to live with it. having it in a vm doesn't force me to use it on a daily basis
<drakonis1>backups are great.
<kahiru>backwhats? :)
<nckx>kahiru: I did that in 2014 without knowing what Scheme was and I survived.
<allana>nckx: No luck -- maybe it has to do with Docker. I am curious to know if anyone is running the docker service from a recent guix?
<sneek>Welcome back allana, you have 1 message.
<sneek>allana, nckx says: Just curious: you run Guix in a VM, but don't use an IRC client outside of that VM…?
<allana>nckx: Yes, I know it seems funny to live inside a VM running on VirtualBox. I use GuixSD at work and my host machine is running the most vanilla possible install of Windows.
<nckx>allana: I don't see how docker could *ever* cause your DRI card0 to disappear.
<nckx>I live to be surprised but that would be a biggie.
<drakonis1>so, the lack of hardware support is a bit of a problem
<kahiru>nckx: at least I kinda know scheme
<allana>nckx: And I may be running GuixSD on actual hardware soon, it will just take me some time
<guix-vits>allana, nckx: what about LTS kernel, as a second attempt?
<nckx>allana: No, not funny; it's the sincerest compliment, I guess 🙂
<kahiru>lenovo x220 should be fully supported, right?
<nckx>kahiru: Perfectly.
<nckx>guix-vits: I'll leave it up to allana to choose their bisectin' ways but since we know 5.4.18 worked I see little point myself.
<nckx>kahiru: You'll have to insmod an out-of-tree module if you want to set battery charge levels but even that is streamlined compared to ZFS.
<kahiru>I don't think I ever did that
*nckx 's just paranoid when it comes to battery wear.
<kahiru>that battery was almost dead when I bought it, so I didn't really bother
<jlicht>hey guix!
<guix-vits>nckx: `guix pull --commit=`, to see when it will stop working as a whole, then?
<guix-vits>maybe it is possible to specify "not working commit" and use --news?
<nckx>guix-vits, kahiru: That's what I'd do. Start with guix pull --commit=<commit of the generation that boots>, just to make sure the configuration really didn't change, then bisect from there.
<nckx>If only this were QEMU on GNU, you could script the entire thing using git bisect run 🙂
*guix-vits crying and silently swears in a Nippon language, then realizes that he doesn't even know this language
<guix-vits>allana: see the above, nckx recommended way. At least it should greatly reduce the eye starring work.
<nckx>guix-vits: Sssh, let's hope they just give up and remove Windows first!
<apteryx>hello! Upon reconfiguring my system using a very recent master branch:
<apteryx>perhaps I need to run 'guix pull' for root, but I thought it was working last Friday (TM).
<nckx>Try manually running sudo /gnu/store/3433z5hdwsxks216d4xmv1nm44ycy1jc-grub-efi-2.04/sbin/grub-install --boot-directory //boot --bootloader-id=Guix --efi-directory //boot/efi --verbose
<nckx>Maybe it will say more.
<apteryx>nckx: yeah, this fails because I need to reference the correct GRUB config somehow: /gnu/store/3433z5hdwsxks216d4xmv1nm44ycy1jc-grub-efi-2.04/sbin/grub-install: error: attempt to install to encrypted disk without cryptodisk enabled. Set `GRUB_ENABLE_CRYPTODISK=y' in file `/gnu/store/3433z5hdwsxks216d4xmv1nm44ycy1jc-grub-efi-2.04/etc/default/grub'.
<civodul>"Could not delete variable: Invalid argument"
<civodul>"efibootmgr failed to register the boot entry: Block device required"
<nckx>apteryx: You haven't changed your configuration at all?
<nckx>Are your boot-directory and efi-directory mounted?
<apteryx>nckx: only thing I've changed is going back from GDM to slim, but that shouldn't be relevant
<nckx>EFI grub-install doesn't take an explicit block device at all.
<nckx>apteryx: I agree.
<apteryx>nckx: according to mount, /efi/boot is mounted
<nckx>This sounds nvram/firmware-related. Restarting & trying again is worth a try.
<apteryx>ah, this would explain it. When I came to work this morning this new PC was asleep. Had to press the power button to awake it. Perhaps I should disable sleep to prevent further problems.
<apteryx>I guess this is GDM's doing (sending the machine to sleep after some interval of time?)
<nckx>apteryx: My X230T refuses to boot when the NVRAM is full (of kernel crash dumps). Firmware is bad.
<apteryx>I'll try a reboot. brb.
<civodul>apteryx: BTW, the output you pasted above is from 'guix system reconfigure', right? i wonder why the &message exception is not properly handled
<zimoun>Hi Guix
<apteryx>civodul: yes, this was from 'guix system reconfigure'
<apteryx>nckx: a reboot, and reconfigure now worked! A 2nd reboot, later, I'm back at home with Slim.
<apteryx>I wonder what other distros do to work around this pesky firmware bug, if they do anything. I wouldn't expect Ubuntu to suffer from this kind of problem.
<nckx>efraim, civodul: Kernel modules from outputs other than :out are not unioned into -system/profile/lib/modules. They're just missing. Merging zfs:module into zfs:out made the module magically appear.
<apteryx>thanks for pointing to the firmware, I would have pulled me some hair before thinking about that.
<efraim>good to know
<nckx>apteryx: The first search result was
<nckx>Impossible d'installer Ubuntu.
<guix-vits>i'd seen in the Fedora Linux: "BLS", entries in /boot/loader/entries. GRUB used to not be reconfigured at all, just updates placed and deleted the files in /boot/loader/entries/. And GRUB used some module to lookup these configs at boot time.
<nckx>I'm not going to spend time fixing this right now but it's worth noting we currently ship a near-useless ZFS kernel module.
<nckx>Oh god, the ol' systemd BootLoaderSpec. Is that still a thang.
<nckx>Probably is since they've subsumed booting too.
<apteryx>nckx: probably only affects EFI.
<apteryx>Perhaps a good old MBR install would not have suffered from this ;-)
<nckx>apteryx: Certainly, but that's the vast majority of machines nowadays.
<nckx>s/good //
<apteryx>nckx: they seem to be able to to legacy as well (at least the one I have here).
<apteryx>you get to choose in the BIOS setup.
<nckx>Don't let's rose-tint our BIOS glasses 😛
<apteryx>zimoun: o/
<apteryx>hmm, our git-repo package is still broken.
*apteryx adds an item to its stack
<joshuaBPMan>morning guix
<wingo>q: why does the gnome metapackage no longer include pinentry-gnome3 ?
<wingo>apparently stems from a8cda7f57992e9ce9ae4a694eba54e3eab42c39b
<wingo>symptom is that my gpg stopped working
<wingo>probably explains a lack of other fonts as well...
<wingo>efraim: do you recall? you reviewed that patch
<nckx>wingo: That commit removed some ‘I'll add this it's nice to have’ things that aren't in fact part of GNOME.
*wingo nod
<nckx>I think that's reasonable for pintentry, not so sure about things like Cantarell.
<wingo>i guess i am not a very good user, following along with things, but the symptom is that my gnome install is less functional than it used to be
<nckx>The problem is that it's called ‘gnome’ but tends to bloat into ‘guix-desktop-experience’ over time.
<nckx>I'm not advocating for it but having a ‘guix-gnome-desktop’ package is how most other distributions I know would fill that void.
<nckx>%guix-gnome-desktop-packages .
<wingo>relatedly, an old problem that Alt-F2 -> ~/Documents started reappearing recently
<wingo>it opens directories in baobab instead of nautilus
<wingo>i fixed this a couple years ago but am not sure why it's back :P
<wingo>that is because gnome-default-applications was removed :/
*wingo grumbl
<efraim>I believe it was the start of an effort to make the gnome meta package more closely align to gnome's preferred desktop collection and less of a bundle of software for a gnome based desktop
<sirgazil>wingo: what is Alt-F2 -> ~/Documents (I use GNOME)
<wingo>yeah i guess what is missing would be %guix-gnome-desktop-packages that would depend on gnome and probably a number of the packages that were removed; wdyt?
<wingo>sirgazil: like press alt-fd
<nckx>Yes. It's basically the start of what might become the ‘improve GNOME packaging’ Outreachy internship.
<wingo>if you type in a path, it will open that path with whatever mime type is appropriate
<wingo>nckx: in the meantime i think we have a regression fwiw
<nckx>So feedback definitely welcome. Making gnome more upstream/objective is fine, but we'll still need somewhere to put the ‘yah you really kind of need this’ distro opinion.
<wingo>for gnome desktops at least
<nckx>Ideally not as a metapackage because that's just porting other distro's idioms poorly to propagated-input monsters.
<sirgazil>Oh, yes. Alt+F2 and then ~/Documentos opens Baobad and not nautilus...
<nckx>wingo: I'm just explaining what happened, I don't use GNOME.
<wingo>heh tx for walking through it tho :) packaging is hard &c
<wingo>and there are the two goals of defining what is and what isn't gnome according to upstream, and providing a comfortable gnome desktop experience, and the two aren't always in line
<wingo>(which is weird when you think about it but understandable too)
*sirgazil abandoned Alt+F2 because it is so slow (in the Guix System?) that it is faster to go and click on the app icon.
<sirgazil>The copy-build-system seems like something I'd like to use in the future for my own data packages.
<wingo>i wonder if removing xdg-user-dirs is also a problem...
<joshuaBPMan>Hey guix! I seriously love ya'll. You've made it sooo easy to set up a locally running nginx server. I am thinking about building a small guile web app, and your nginx syntax is sooo slick!
<wingo>regarding xdg-user-dirs, original motivation in c20cd0d24d9b5e8a47b864db9799e0992ffd44b9
<nckx>wingo: Proof that it should have been a comment ( :o) )
<nckx>I thought there was a meta-bug open about the GNOME situation but can't find any.
<wingo>i am filing a bug with some notes
<wingo>will get all sorted eventually i guess :)
<nckx>Thank you!
<nckx>Be sure to CC Raghav.
<wingo>done :)
<civodul>just stumbled upon this:
<civodul>AIUI, it's like a CLI to manifest-like dependency files
<NieDzejkob>Sometimes I need to restart dhclient to regain internet connectivity. When I do that, ping and curl work, but IceCat needs a restart to see the Internet connection again. Any idea what on earth might be happening here?
<NieDzejkob>Toggling IceCat's offline mode doesn't help.
<civodul>NieDzejkob: weird, i don't think i've experienced it
<civodul>i use NetworkManager though, but that in turn runs dhclient as needed
<NieDzejkob>yeah, I switched from NetworkManager to wpa-supplicant when I was initially setting up my system. Not sure why anymore
<NieDzejkob>I think I couldn't figure out how to tell NetworkManager the wifi details
<civodul>i'm an old fart and i used to do everything manually... until i switched to NM a few years ago, and i don't regret it :-)
<raghav-gururajan>wingo I just saw your conversations. Are you Andy who just email to mail-list? I have replied. :-)
<NieDzejkob>argh, is down
<raghav-gururajan>NieDzejkob I think it is
<bluekeys>Hi guix. Is there a way to extract my current running config.scm?
<nckx>raghav-gururajan: Yes they are.
<raghav-gururajan>nckx Thanks.
<raghav-gururajan>NieDzejkob Ah it is also down. Mean while, you could use
<janneke>oww, that's sad...removing --quiet from ./pre-inst-env guix build -e '(@@ (gnu packages commencement) guile-final)' after half an hour reveils:
<janneke>waiting for locks or build slots...
***Server sets mode: +cnt
<NieDzejkob>raghav-gururajan: doesn't help when what I want to do is look at the pastes from today's chat history
<roptat>bluekeys: maybe look for "provenance information" in the manual? I kind of remember there is some information available. If you just installed guix, there's /etc/config.scm
<NieDzejkob>bluekeys: If it's only one file, check /run/current-system/configuration.scm
<raghav-gururajan>NieDzejkob Fair enough.
<raghav-gururajan>sneek: later tell wingo: I have requested It should reverse the hickups you are facing. :-)
<sneek>Got it.
<nckx>raghav-gururajan: Whoa there, that's drastic, let's put that on hold. The first two only add packages (did they break anything? what?), the third has no effect on packages if your commit message is accurate. The fourth is the only one that removes packages, and even that might be better tweaked (this time: with comments noting what each non-core package brings to the GNOME table) than flat-out reverted. What do you think?
<nckx>I have to leave now but shall return, wet and mildly confused as ever.
<raghav-gururajan>nckx That reverse shouldn't break anything. In fact, it take GNOME back to the time where my screw ups has not started. :P
<nckx>I've sent the same message to bug-guix for Danny, but no reason to reply again of course It's not (just) about not breaking things, it's unnecessary. Talk more later 🙂
<raghav-gururajan>nckx Since we got lot of feedbacks regarding GNOME, I am gonna re-contemplate what can be done to gnome meta-package.
<raghav-gururajan>nckx See ya later.
*raghav-gururajan will be away for a while
<wingo>evening :)
<sneek>Welcome back wingo, you have 1 message.
<sneek>wingo, raghav-gururajan says: I have requested It should reverse the hickups you are facing. :-)
<wingo>raghav-gururajan: hey thanks! fwiw i wasn't meaning to argue necessarily that changes had to be reverted, fixing in other ways is also fine!
<nojr>hi, could someone explain to me that happens exactly when running guix environment after cd into the guix directory in
<nojr> , my bad, also I'm referring to Part One, I'm confused because we need to start the shell with ./bootstrap, but is this a one time thing? also, the video says that `make` makes the ./pre-inst-env commands available
<nojr>I'm a noob :/ and I'm trying to understand
<NieDzejkob>./bootstrap generates the ./configure script
<NieDzejkob>(google keyword: autoconf)
<joostvb>it's scripts generating scripts generating scripts
<NieDzejkob>nojr: Part One of which video?
<NieDzejkob>joostvb: accurate description
<joostvb>NieDzejkob: tnx :)
<NieDzejkob>hmm, I think you're referring to packaging
*NieDzejkob -> AFK
<nojr>so we need to build Guix from master branch, to include the new package?
<nojr>NieDzejkob: of the packaging video tutorials
<nojr>also why are coreutils and findutils included in the environment, in the video tutorial/
<roptat>We need to update these videos I think, as the manual evolved a bit…
<roptat>Now I think we recommend using a --pure environment for tge bootstrap and configure steps, but it doesn't really matter
<roptat>nojr: for packaging, you'll need to build guix from master, yes, because that's where you're going to put your new packages (if you want to contribute them back to us, that is)
<roptat>If you don't intend to contribute, you can skip this and create yourself a channel, which is roughly che same thing, but not covered by tge videos
<roptat>Not sure why coreutils and findutil are included, I don't think they are necessary
<roptat>Unless you run with --pure maybe
<civodul>is it just me or the connection to ci. is really slow?
<KE0VVT>civodul: What is ci?
<cbaines>civodul, when downloading flightgear (which is large), I get 1.42MB/s
<cbaines>both from London, and from a virtual machine in Germany
<cbaines>(I'm testing with )
<civodul>cbaines: hmm i'm at 26KB/s
<civodul>there must be something wrong on the way
<cbaines>I know that strikes in France are a recent thing, but I didn't know the internet was involved :D
<civodul>yeah, weird! :-)
<civodul>oh, and now Matrix strikes back
<civodul>hi there!
<HappyEnt>Hello, I recently updated my system and now gdm only starts when i add the intel gpu kernel modules to my initrd. Anybody else experiencing this problem?
<dftxbs3e>hey jonsger, still trying to remove that reference of bash inside gawk, somewhat skipped onto other things such as actually putting everything I had into the code, which is done now
<dftxbs3e>I just have to upload new bootstrap binaries and re-test now to see where we're at
<dftxbs3e>The static bash path embedded inside gawk is really weird
<dftxbs3e>everything patched in glibc, same story for gawk..
<janneke>civodul: i added a patch that makes wip-bootstrap build again for me; pushed to savannah. it removes bzip2 from `file' in commencement altogether; this was introduced in file-5.38 and fails because of built with earlier bootstrap gcc's
<janneke>civodul: i'll do a rebase on latest core-updates and also test that
<bandali>KE0VVT, ci is, the official substitute server
<KE0VVT>bandali: I need more disk space ASAP.
<KE0VVT>Filesystem Size Used Avail Use% Mounted on
<KE0VVT>/dev/mapper/trisquel--vg-home 125G 125G 371M 100% /home
<bandali>KE0VVT, uh, how am i to help with that? if you use guix, and are implying that guix has taken a lot of space on your partition, look into `guix gc'
<KE0VVT>bandali: I am just telling you I am still stuck on Trisquel at the moment.
<bandali>KE0VVT, oh, okay
<civodul>cbaines: i just noticed that cuirass on bayfront wasn't doing much because of incorrect ownership on /var/cache/cuirass
<civodul>janneke: awesome, thanks!
<cbaines>civodul, ah, right. I was struggling to reconfigure the machine, so I ended up removing and re-adding the service, but that just caused problems with the uids
<cbaines>obviously I didn't fix all the issues
<civodul>cbaines: np, should be fine now!
<dftxbs3e>civodul, about the gawk bash-static store reference problem. Here's what I could figure out: gawk has a 'set-shell-filename phase that replaces /bin/sh with bash pkg then inputs replacement in make-bootstrap changes bash pkg to bash-static pkg -- so initially I tried to replace using (substitute* ..) inside make-bootstrap but because of the set-shell-filename step, it actually didnt happen because it was already replaced with bash pkg. So I ended
<dftxbs3e>up removing the set-shell-filename and then using substitute. I found a few places where /bin/sh (or any pkg it gets replaced by) could be spawned directly so I patched that as well with "sh" for PATH lookup. But I'm still getting bash-static in the final gawk static binary, so that makes me puzzled.
<dftxbs3e>(in glibc, for the last part, I mean)
<civodul>dftxbs3e: uh, that's more than i can handle right now :-)
<dftxbs3e>civodul, see: and earlier commits.. if that's of any interest.
<dftxbs3e>civodul, ah ok, well have good rest I guess
<civodul>i'm not even having a rest :-) struggling with the installer tests
<dftxbs3e>civodul, oh great! testing UI?
<civodul>dftxbs3e: perhaps you should send a status update to the list, so people can asynchronously comment?
<dftxbs3e>cool, curious about how you do that..
<necrophcodr[m]>I've been trying to make a package for some software that uses go, but I keep hitting an error: failed to initialize build cache at /homeless-shelter/.cache/go-build: mkdir /homeless-shelter: permission denied
<dftxbs3e>TUI testing definitely is interesting
<necrophcodr[m]>Any way "around" this? I'm not sure exactly what it means, or what the exact issue is here.
<nckx>necrophcodr[m]: Set HOME to /tmp.
<nckx>(setenv "HOME" "/tmp")
<dftxbs3e>civodul, I just hope to finish this. I' tired right now, will run this test and send a concise email tomorrow.. I'll try
<dftxbs3e>I just tend to think it's not very useful since I'm kind of alone deep in this mess
<necrophcodr[m]>nckx: so the correct way to build packages that depend on go is to run `HOME=/tmp guix build ...` ?
<civodul>dftxbs3e: i know that feeling, but you're not alone!
<nckx>necrophcodr[m]: No, call setenv in a phase when writing the package.
<jackhill>HappyEnt: I'm not experiencing that, but I'm not quite sure what to suggest. Maybe you can post some more information about your system (guix describe output and more information about your intel gpu)
<nckx>Builds are self-contained, external environment variables have no effect anyway.
<civodul>dftxbs3e: often just sharing the current status and letting it rest for a day or two can help IME
<necrophcodr[m]>Alright, I'll look into making my own phases for the gnu build system. I'm not entirely certain how all of the pieces fit together, but there's always diving through the source code for hours lol
<dftxbs3e>civodul, noted, I've been having some difficulty contributing to GNU Guix as much as I love it, because it doesnt work on my machine, and my lack of knowledge of Scheme is damaging. I need to read a book about it. - I'll post useful news tomorrow on the list I promise.
<nckx>necrophcodr[m]: You need to add the phase to your package, not the build system: (arguments `(#:phases (modify-phases %standard-phases (add-before 'build 'set-HOME (lambda _ (setenv "HOME" "/tmp") #t)))))
<civodul>dftxbs3e: noted; take your time, no worries
<civodul>you've already gone very far
<dftxbs3e>civodul, I feel like I've tried *lots* of things without progressing very much. Probably compiled things 100 times by now heh
<necrophcodr[m]><nckx "necrophcodr: You need to add the"> Ahh thanks. I'm not entirely sure how what you wrote works, so I'll look at it closer and how phases work, so I won't have to come back here asking these questions again.
<nckx>necrophcodr[m]: That's what we're for 🙂
<nckx>‘build’ is a guess by the way, it depends which phase is failing (this will be printed in the ‘guix build’ log output).
<HappyEnt>jackhill: i am currently building an older kernel, there seem to be quite a few people over on arch experiencing similar problems with the newer kernels. I will report back wether that works, otherwise I will try the mailing list and add more information about my system.
<dftxbs3e>At least I'll have deep understanding of the bootstrap process then :P
<civodul>dftxbs3e: yup, i understand & sympathize; tell janneke about building things 100 times :-)
<civodul>yeah, which is good
<jackhill>HappyEnt: cool, best of luck!
<civodul>dftxbs3e: few people actually dread in that area, so it's really nice you did that
<dftxbs3e>My love for GNU Guix can only drive me in that direction
<dftxbs3e>I don't even have an x86 machine with a display at home to actually run GNU Guix otherwise. So there's no way out of the frustration but porting :-)
<janneke>dftxbs3e, civodul ... hehe ;)
<necrophcodr[m]><nckx "‘build’ is a guess by the way, i"> It is indeed the build phase, and this brings me a LOT closer now. Thanks for the help, I think I can figure out the rest of the problems that are cropping up now :D
<dftxbs3e>civodul, Thanks for cheering me up on that contribution, I hope to get it finished **very** soon! Grr!
<jackhill>necrophcodr[m]: you may also want to use the go-build-system, or if that's not appropriate, at least borrow some ideas from it.
<janneke>dftxbs3e: do feel free to talk about it here, that helps me a lot when i get frustrated :)
<jackhill>necrophcodr[m]: what software are you packaging by the way?
<necrophcodr[m]><jackhill "necrophcodr: you may also want t"> Absolutely considering it too.
<necrophcodr[m]><jackhill "necrophcodr: what software are y"> A couple of things. Consul by Hashicorp, and Gobetween, a TCP/HTTP proxy. Both are written in Go. And even if they end up being packaged before I'm done that's okay too, this is mostly a learning experience :D
<nckx>Wait, you're not using the Go build system for a Go package? That's definitely… recommended.
<jackhill>necrophcodr[m]: cool, I was mostly just curious. I've stubled into looking at go packages recently becuase I wanted to try out
<jackhill>That lead me to feeling ambitious about a Go importer:
<necrophcodr[m]>The different importers in Guix are crazy. I'm used to writing packages like ebuilds, but Guix and especially the importers take it a couple of levels up for sure!
<necrophcodr[m]><nckx "Wait, you're not using the Go bu"> I've considered trying to get it working with that as well, but the gnu build system has gotten me the furthest with the least trouble so far. Some "Go packages" aren't strictly... Go packages either. Some require the use of the gnu make (and other) tools to even build, and cannot be built using `go get`.
<necrophcodr[m]>If all software was packaged neatly and organized in a single predictable manner, we might not even need `make` at all. Although that's quite a reach. Make is fantastic in it's own right.
<civodul>hmm the installer no longer works at all on master: blank screen
<apteryx>civodul: hmm? I've used it quite recently.
<apteryx>Well, at least it was working circa 10th of February.
<civodul>apteryx: yeah same here, so i'm at loss
<civodul>could you check with "guix system vm gnu/system/install.scm"?
<apteryx>civodul: yes, gimme a sec
*apteryx building latest master; luckily on a powerful machine
<guixy>Hi guix
<guixy>I'm working on a wrapper for clojure.
<guixy>It's based on the wrapper installed with brew.
<guixy>I think it would be best to use the clojure and clj scripts in that repo.
<guixy>But there are some roadblocks. I would need to change "${project.version}" to the actual version.
<guixy>I would also need to have it look for the clojure jar in "$install_dir/share/java/clojure.jar" instead of "$install_dir/libexec/clojure-tools-${project.version}.jar".
<guixy>I think it would be easier to make these changes with a patch rather than with multiple calls to "replace"
<guixy>I've looked in the manual and haven't found anything about the standards for sending patches to be applied.
<guixy>Where can I find guidelines?
<apteryx>sneek later tell civodul seems to hang for me as well; nothing shows up after seaBIOS
<calher>Would the GNOME Software backend developers accept a patch to add support for Guix?
<calher>Then maybe make a separate app for Guix specific stuff.
<leoprikler>What kind of patch are you specifically hoping for?
<calher>leoprikler: So you can go into GNOME Software on Guix System, search for an app, and click install.
<calher>leoprikler: AFAIK, its backend only supports APT, Flatpak, RPM, and pacman.
<nckx>calher: Isn't that PackageKit? Or no longer?
<calher>Yeah, that's the name.
<calher>PackageKit has no Guix capabilities, nckx.
<nckx>Not yet. If you're willing to write a PK back end for Guix I'm sure they'd accept it upstream. Even if they didn't, we could provide it in Guix System.
<calher>Cool. I'm a GNOME fanatic...
<nckx>I wonder if PackageKit has a concept of per-user package management.