IRC channel logs


back to list of logs

<NieDzejkob>Evaluations are consistently failing on CI with "In procedure scm_lreadr: #<unknown port>:16:144: Unknown # object: #\<"
<raingloom>does globally installed nss-certs not get used in user sessions?? i couldn't figure out why netsurf and git were spewing HTTPS errors at me, but i took a look at the output of env(1) and it looks like there are no related paths being set. :|
<NieDzejkob>the first failing push is eda3fcfb46586710fff876ce6254b300795ef543, consisting of two patches by mothacehe: "ci: Build Guix System images.", "image: Move hurd image definition to a dedicated file."
<NieDzejkob>raingloom: I install nss-certs globally and it seems to populate /etc/ssl/certs as a result
<raingloom>NieDzejkob: weird. it does seem populated. maybe it's oudated? but i'm pretty sure my profile is not _that_ old... yup, only 3 days old.
<raingloom>(more like 2 days and change)
<raingloom>NieDzejkob: none of those are set for me, not even when i open --ad-hoc nss-certs environment.
*raghav_gururajan will brb
<raingloom>maybe this is related to not using GDM, like how GVFS is completely broken
<civodul>cbaines: the "performing database optimizations" step in Cuirass leads to crashes
<civodul>ice-9/boot-9.scm:890:4: In procedure iota:
<civodul>Throw to key `wrong-type-arg' with args `(-1)'.
<raingloom>...maybe if i add git to the environment
<civodul>does that ring a bell?
<raingloom>(ok, adding git fixed it.)
<civodul>ah so cuirass won't start at all
<nckx>I'm not alone.
<civodul>yeah same thing on berlin
*nckx was staring at another window.
<cbaines>hmm, that stack trace is useful
<nckx>civodul: This is berlin, I was adding a wip-desktop job for Raghav.
<civodul>ah i see
<rekado_>BTW: adding a job can be done from the web interface
<nckx>civodul: (Should that be: "wip-desktop" "wip-desktop", or "guix" "wip-desktop"? This naming is opaque to me.)
*rekado_ –> zzzZ
<nckx>I still haven't set up a client cert for that.
<cbaines>I think the error suggests that something's up with the database schema
<nckx>civodul: Is there a guide for that?
<cbaines>It's not specifically to do with the database optimisations, but happening there because that's where the database is first opened
<cbaines>I think the -1 suggests the current schema version (recorded in the database) is one behind the latest schema version that the cuirass code knows about
<civodul>so the schema upgrade didn't take place?
<civodul>nckx: you can just do an SSH tunnel to use the /admin interface
<civodul>it takes care of naming for you
<cbaines>I think the latest schema version is 8 (matching up with the upgrade-8.sql file)
<cbaines>This SQLite command will get you the schema version recorded in the database: PRAGMA user_version;
<cbaines>Maybe this has happened because some newer code was used for Curiass, and now some older code is in use?
<cbaines>It would be good to check what upgrade SQL files are in the cuirass output that's in use
<nckx>civodul: That's… clever. I get a nice 502 now.
<nckx>I still get 403 for /admin though.
<civodul>cbaines: it's /gnu/store/5pdnafy6p51sxiyh137ixjxr2x4pk71c-cuirass-0.0.1-31.2280ae1
<cbaines>nckx, are you going directly to the cuirass port, not through nginx?
<cbaines>You'll need to do the former, as NGinx is what's giving you the 403
<cbaines>civodul, I don't have that output unfortunately. What's in the share/cuirass/sql/ directory?
<cbaines>Ah, looking at the 2280ae1 commit, that's 3 weeks old, and doesn't use the latest schema
<cbaines>What controls what version of cuirass is in use on berlin? It seems like it's somehow using an older one that it was using before?
<civodul>cbaines: up to upgrade-7.sql
<civodul>the version of cuirass is controlled by the config
<civodul>"guix system describe" says we're at 9bc516bada71e1437d73971584bff5e72e053dbe
<civodul>reconfigured 20mn ago actually
<cbaines>my internet connection is a bit dodgy, so my messages might be a bit odd...
<civodul>hmm generation 346 lacks provenance info
<cbaines>Anyway, I think the solution here is to reconfigure berlin with a newer cuirass (however that's done)
<civodul>you have access to berlin, right?
<cbaines>I don't have access
<civodul>oh you can add yourself if you want
<civodul>(but maybe you don't, that's reasonable :-))
<civodul>yeah i think the issue is that the reconfigurations today were made with an older commit
<civodul>that of root's guix
*civodul pulls & reconfigures
<cbaines>Cuirass should probably give a more to the point description of this issue, something like "You're database uses schema version X, but the latest known schema version is Y, are you running an older version of Cuirass?"
<cbaines>Rather than: In procedure iota: Throw to key `wrong-type-arg' with args `(-1)'.
<cbaines>Maybe it did, that's at least something that I could have broken
<cbaines>Regarding Cuirass on berlin, the web interface has been unavailable quite often recently
<cbaines>does anyone have a theory as to why?
<civodul>i don't know
<civodul>mothacehe has been pushing changes recently, perhaps that's related
<cbaines>It's possibly something like a file descriptor leak, but it's easiest to check that when it's in a broken state
<cbaines>I was chasing a file discriptor leak before, and I'm not sure I actually solved it
<PotentialUser-64>I’m having issues during graphical installation on a laptop. It gets to the partitioning phase and then just loops back to the locales. Any advice would be great
<hendursaga>Well, good news, I've successfully installed Guix on a RPi 3, running DietPi image, now to find out if it works or not..
<civodul>cbaines: oh, we'll keep an eye on it
<nckx>civodul: Are you reconfiguring?
***deesix_ is now known as deesix
***dddddd_ is now known as dddddd
<mbakke>so my system failed to start properly, I rolled back, wrote a patch in less than five minutes, and rebooted into a working system
<mbakke>I feel like a super hacker
<madage>movie like hacker, except you are invading your own system... :)
<mbakke>it's been so long, I can't imagine life without roll-backs anymore
<madage>I still pity myself for having hesitated for so long to just dive into guix
<madage>made my hacking carefree
<mbakke>you're still well ahead of the curve ;-)
<civodul>cbaines, nckx: reconfigure complete, cuirass running!
<cbaines>great :)
<civodul>mbakke: heh, well done :-)
<NieDzejkob>civodul, cbaines, nckx: evaluations are still failing on CI
<NieDzejkob>see my messages from 80 minutes ago
<civodul>@ build-succeeded /gnu/store/991738x97ff1f8181a7p1pflqwkgagm8-profile.drv -
<civodul>ERROR: In procedure read:
<civodul>In procedure scm_lreadr: #<unknown port>:16:144: Unknown # object: #\<
<civodul>ah yes
<civodul>NieDzejkob: we should revert eda3fcfb46586710fff876ce6254b300795ef543 or the other commit you mentioned
<NieDzejkob>I'm not sure which one though, guix pull doesn't reproduce the failure
<tracerte>Hi, does the graphical installer have some sort of log or output onto a virtual terminal? My attempt at installation looped with no failure notice. Thanks.
<cbaines>I'm guessing the evaluation failures could be related to the database issue
<civodul>NieDzejkob: i've reverted the (gnu ci) one, it's likely the culprit
<civodul>i'm not sure it was pushed on purpose actually because it's still under review here:
<civodul>cbaines: no, i don't think it's related
*civodul -> zZz
<civodul>see ya tomorrow!
<ryanprior>madage: can I quote you in a talk slide? If so, what attribution should I use, is "madage" good or would you prefer a social media handle or full name?
<madage>ryanprior: which quote, may I ask?
<ryanprior>> I still pity myself for having hesitated for so long to just dive into guix. Made my hacking carefree.
<ryanprior>The carefree vision that Guix presents I find compelling, and that quote is a nice testimony that it's delivering.
<madage>for sure! I'll let you decide the handle, my name is André Batista
<madage>but you may as well quote madage if you prefer
<kernel-help>Hi all. I need help with using an inferior for specifying a kernel version
<madage>ryanprior: I pretty like this nick, it's a portmanteu of morgan, ada and babage.. and it also could be read as 'mon adage' though I don't know if this would be proper french
<ryanprior>Cool, I'll have plenty of slide space for your name and your nick :)
<NieDzejkob>kernel-help: sure, what's the problem?
<kernel-help>NieDzejkob, here is what im trying. I'm running guix system build config.scm and it just hangs indefinitely.
<NieDzejkob>kernel-help: try "linux-libre@4.19.129" instead
<kernel-help>NieDzejkob, ice-9/eval.scm:626:19: In procedure car: Wrong type (expecting pair): ()
<NieDzejkob>looks like there's no such version on that commit?
***catonano_ is now known as catonano
<NieDzejkob>which is weird
<kernel-help>NieDzejkob, im thinking it is something about the format. the version definitely exists in that commit, can check with guix time-machine, it is there.
<kernel-help>guix time-machine --commit=4f33bf5709a77a98f3d0330e45753d54675239ff -- build linux-libre@4.19
<kernel-help>this returns 4.19.129
<NieDzejkob>kernel-help: hmm, could you paste the modified snippet, to be sure?
<NieDzejkob>sneek: later tell jonsger: I've figured out what your problem is. The clue was that even though you only specified the gui output, the binaries from the out output were still there. specification->package+output returns the output as a separate value, so you have to bind it with let-values or handle it otherwise. Stealing a snippet from specifications->manifest, try (map (compose list specification->package+output) ...)
<kernel-help>NieDzejkob, funny thing is that my original snippet used to work. But the kernel parameter must have changed in the type it accepts.
<kernel-help>I dont know for sure though, and I cant seem to chase it in the git history
<kernel-help>so I really dont know what to do to get the parameter to conform
<NieDzejkob>with the version as a separate parameter!?
<kernel-help>yeah, let me link you to my old mailing list post
<NieDzejkob>oh, okay, I just checked the source and I misremembered how it goes. lookup-inferior-packages doesn't use a specification, your first snippet was more correct
<NieDzejkob>what is the end of the output from before the infinite hang you mentioned
<kernel-help>NieDzejkob, It just hangs on the updating channel output
<kernel-help>NieDzejkob, reading back in that mailing list it looks like I was able to get the time-machine to output some error. But im not sure what command I ran to get that.
<kernel-help>I should have been more specific lol
<NieDzejkob>I think starting up the inferior for the first time might take a while. For how long did you try letting it run?
<kernel-help>NieDzejkob, its been running for over an hour :)
<NieDzejkob>anyway, it's getting late, I can't continue troubleshooting right now. Hopefully someone else here will be able to help you...
<kernel-help>Thanks. no worries.
<kernel-help>Anybody else want to take a stab at this issue?
<kernel-help>Anybody available to help me with an issue regarding inferiors?
<kernel-help>nckx, are you available?
<PotentialUser-13>Hi all. I am having an issue with inferiors, anybody available?
<madage>ryanprior: it just came to me a grand finale for your talk: "At first I was afraid, I was petrified..."
<madage>now I'm gonna crash, see you and thanks for caring!
<ryanprior>Good night, see you around!
<ryanprior>PotentialUser-13: I still haven't got inferiors into my workflows yet, sorry X.X
<wdkrnls>Would this be useful to include in the standard guix .bashrc?
<wdkrnls># Use cat as the pager from within Emacs
<wdkrnls>if [[ $INSIDE_EMACS ]]; then
<wdkrnls> export PAGER=cat
<apteryx>hmm: "make[2]: *** [Makefile:5966: make-go] Error 143" which one is that?
<apteryx>oh, probably an OOM.
***terpri__ is now known as terpri
<ryanprior>wdkrnls: I wouldn't want that in my bashrc, because my Emacs shell supports pagers like `less` (or even `nvim`)
<ryanprior>So I would vote no for baking that assumption into Guix.
<PotentialUser-59>Hello. Is anybody available to help me with an issue I am having with inferiors?
<rekado>nckx: for the cuirass admin interface we have scripts in /root/maintenance to generate your client cert
***modula is now known as defaultxr
<rekado>the directory /root/maintenance/hydra/cuirass-client-certs has a shell script “” that should take care of things (it’s annoyingly interactive)
<civodul>Hello Guix!
***apteryx_ is now known as apteryx
<janneke>grmbl, no emacs-magit on i686
<mothacehe>hey guix!
<mothacehe>sorry for the ci breakage yesterday, thanks for the revert civodul
<janneke>hi mothacehe!
<civodul>hi mothacehe!
<civodul>no worries for the CI issue
<civodul>NieDzejkob found out about it yesterday evening
<cbaines>hello all :)
<MSavoritias[m]1>Hi cbaines
<cbaines>MSavoritias[m]1, by the way, if you're interested in build reproducibility issues, guix challenge is a command to try
<cbaines>There's also some stats on package reproducibility here
<cbaines>and if you click through to the "Not matching" list, you'll see what specific outputs didn't build reproducibily
<cbaines>Then you can use guix challenge to see why: guix challenge --substitute-urls="" gnome-characters --diff
<cbaines>Ah, slightly wrong command, this should work: guix challenge --substitute-urls="" gnome-characters --diff=diffoscope
<cbaines>I didn't realise that guix challenge did such a good job at comparing the results from different substitute servers!
<cbaines>It even works with store paths as well, that's amazing! guix challenge --substitute-urls="" /gnu/store/0f42kqdrdxixjdi8m5j3x52z1bgmrrlf-gnome-characters-3.30.0 --diff=diffoscope
<simendsjo>I would love for some automagic way for the packages I build to be uploaded to some substitute server.
<NieDzejkob>Why does expand-crate-sources in guix/build-system/cargo.scm use filter-map? the lambda looks like it won't ever return #f
<apfel>hi there, i try to use guix pull behind a http proxy. guix install works and downloads and installs fine. But guix pull failes with "Network is unreachable". When i use git clone it works fine.
<apfel>it seems that guix pull does not honor my proxy settings of my environment. This was also discussed years ago on some mailing list, but it seems the fixes from the past do not work anymore :/
<xelxebar>apfel: I believe you need to start the daemon in an environment that has http_proxy etc set
<apfel>xelxebar: i did that, the environment of the daemon has the variables set correctly. herd set-http-proxy guix-daemon http://... This fixes the download of substitues. But not guix pull.
<xelxebar>Just checking the obvious stuff, but the environment from which you run guix pull also *_proxy set?
<apfel>xelxebar: yes
<civodul>apfel: currently "guix pull" doesn't honor $http_proxy when it clones Git repos
<civodul>this functionality is available in Guile-Git upstream, but not yet in the release we're using
<apfel>civodul: ok, thanks, maybe i can do it manually with git pull instead of guix pull
<civodul>apfel: you have to do it with 'guix pull', but you can point it to a local clone that you created with git
<civodul>guix pull --url=file://...
<apfel>civodul: nice, thanks, thats good enough for now :)
<xelxebar>Typical civodul, sweeping in and disseminating helpful nuggets.
<valsa>Hi all, i have a guix virtual machine with a disk encryption that i can not boot anymore from this morning. It accept the decryption passphrase before grub but when it's asked again after grub it's say "no key avaiable with this passphrase". Anyone facing the same problem? Thanks all
<NieDzejkob>valsa: did you try booting previous generations?
<valsa>yes, without success
<NieDzejkob>did you reconfigure since the previous boot?
<valsa>i did not reconfigure, i tryed a package upgrade that i have to interrupt on icecat stuck
<xelxebar>valsa: The second passphrase failing means it's happening from your initramfs. There's a kernel cmdline parameter that drops you into a guile shell at this stage, which would let you poke around.
<xelxebar>Your boot is encrypted, right? If grub is successfully decrypting the drive, then your luks headers are fine, so that, at least, is reassuring.
<valsa>yes, that's exactly what's happening and where's i am tryng to figure out how to fix it
<xelxebar>What's the kernel cmdline argument that drops you into an early boot guile shell?
<xelxebar>Not finding it in the manual
<valsa>i think it can be related to a ice-9/boot-9.scm in procedure raise-exception: pre-mount action failed, but i am not competent enough
<xelxebar>I don't know much guile either, but that just sounds like a "failed to mount" kind of error.
<xelxebar>valsa: I think I found it. If you edit your kernel line from grub and add --repl as an argument, I think this will drop you into a guile shell.
<xelxebar>But now that I say that, I realize that you may already be there since it's erroring out...
<valsa>thanks a lot, yes, i am already in the guile shell, where i can't find anything usefull
<PurpleSym>Is it not possible to use local URLs (i.e. file://) for git-reference’s url? It says “X does not appear to be a git repository”, although I can clone it just with with `git`.
<NieDzejkob>PurpleSym: I think the build is sandboxed. You can try using local-file as the source instead
<PurpleSym>Oh, of course, thanks.
<valsa>xelxebar NieDzejkob thanks a lot for the support, i think i am going to reinstall, i will loose only half day of work not committed.
<mbakke>PurpleSym: if it's just for testing, a little-known hack is (source "/the/repository") :-)
<PurpleSym>mbakke: Didn’t know that one. I went for `python3 -m http.server` xD
<tracerte>Anyone available to assist with installation via the graphical installer?
<mothacehe>tracerte: sure
<tracerte>Thanks mothacehe. I'm installing on a thinkpad. All goes according to plan until the actual installation is supposed occur. It formats the drive and then takes me right back to the locale selection menu. No errors.
<mothacehe>tracerte: uh, that would be (sadly) a known issue of the 1.0.1 installer.
<mothacehe>is your thinkpad using an NVMe drive?
<mothacehe>in any case, you might prefer to use the "latest" installation image which is available here:
<tracerte>mothacehe: I tried installing on a virtual machine earlier in the week, no problem. No it's actually just a standard ssd.
<tracerte>Thanks mothacehe, I'll check out the "latest" image and report back.
<mothacehe>ok thanks, the error reporting is fixed on the "latest" image, so if it fails again, we should at least have some information.
<MSavoritias[m]1>cbaines: thank you for the information 🙂 I will definetily try with the guix challenge command. I really need to start learning some guile :P
<MSavoritias[m]1>I found another determinism issue by the way. Icecat this time.
<tracerte>mothacehe: that's good to know about the error reporting. Is there an output onto a virtual terminal or log file that I should share if I encounter a problem?
<mothacehe>yes, you will see an error page with a red background. In that case you can either send a picture of that page, or use the /tmp/last-installer-error file that contains the same information.
<tracerte>mothacehe: Perfect, thanks so much for the assistance.
<MSavoritias[m]1>Is it better to add the guix challenge logs or just add the build log everytime I find a determinism problem?
<MSavoritias[m]1>or are they for different things?
<cbaines>MSavoritias[m]1, the diff from guix challenge is probably more immediately relevant when you spot a determinism problem
<MSavoritias[m]1>ok. I will do it like that from now on
<civodul>Helm is more and more getting on my nerves
<apteryx>civodul: it's find-files autocompletion gets in the way when browsing the /gnu/store
<apteryx>it takes ages to processes the large amount of files there
*apteryx also has a love/hate relationship with helm
<apteryx>I guess I should give Ivy/Counsel a try
<zimoun>civodul: mothacehe convinces me to switch from Helm to Ivy ;-) And I have not switched back... ;-)
<zimoun>apteryx: the only package where I find Helm better is helm-bibtex: the Ivy backend is poorer than the Helm one. Otherwise for the rest, I am less grumpy against Ivy than I was against Helm. :-)
<jsoo>apteryx: I use ivy for the same reason. Helm is just too slow with many inputs.
<civodul>apteryx: yeah i also have a love/hate relationship with helm, leaning towards hate these days ;-)
<civodul>zimoun: oh really?
<civodul>thing is i don't want to switch every month
<civodul>i used ido for years and i was happy
<civodul>then helm brought me happiness, but that also came with occasional frustration
<apteryx>The only thing I really need from Helm is the ability to git-grep and git-ls-files, which sets the bar rather low for a switch in my case.
<apteryx>I've found all the other Helm things "interesting" but never actually touches it (such as helm-top).
<zimoun>civodul: I have read that fido-mode in emacs-next (or emacs-next-next) should be a nice replacement of Ido. I have not tried yet.
<civodul>nice, so many possibilities :-)
<civodul>apteryx: yeah git grep in helm-find-file is the killer feature for me
<zimoun>civodul: Speaking about SWHID, zack pointed me a python CLI tool to apparently compute this SWHID. Well, it is not packaged yet and I do not know how it is local, but such equivalent tool for Guix could be nice to have. We could compute and store their hashes somewhere without relying on them, I mean trust them.
<civodul>zimoun: "guix hash -r" does that, computing a hash over the nar rather than over the Git tree
<civodul>i don't believe in storing manually-provided hashes that are not used
<civodul>i don't think we can avoid storing raw tarballs without also losing the ability to meaningfully authenticate/integrity-check code
<zimoun>I agree that storing raw tarballs solve the issue. But reading their messages, I do not think they will do, sadly. And if they provide a correspondance table between raw tarball hashes (the ones we store) and git tree SWHID hashes, then there is a big trust issue; which would not be acceptable. And then we cannot fallback to SWH, if I understand correctly. So one way is to store ourself this correspondance. I do not know. I feel like an
<zimoun>impasse for falling back to SWH.
<civodul>right, it's a policy decision for them to make
<civodul>we discussed it back in 2016 already and i think the answer was neither "yes" nor "no"
<civodul>i think we need to reach a common understanding of the implications, first
<zimoun>I agree even if I am already anticipating what will be their decision. Well, the good point is that now, Guix has more reachable packages in SWH than Nix because of git-fetch. ;-)
<wdkrnls>Dear Guix, I added CUPS to my config.scm and reconfigured. That worked. Yay! I figured out that I could install the system-config-printer to setup my printer. Unfortunately, now it's complaining that a certain sub-file of the cups directory in /gnu/store is not installed (pertaining to "rastertoqpdl").
<wdkrnls>I have cups-filters in my extensions, so why would this be?
*kmicu moved away from Emacs’ Helm after spotting dependency on EIEIO.
<nckx>wdkrnls: QPDL is a Samsung thing, not CUPS. Did you add splix to your cups-service-type extensions field?
<nckx>And which printer is this?
<Kozo>Putting this here to help anyone in the future who trys to use SDL2 with emacs through quicklisp.
<Kozo>(pushnew "/home/<your-user>/.guix-profile/lib/"
<Kozo> cffi:*foreign-library-directories*
<Kozo> :test #'equal)
<MSavoritias[m]1>what is the option to pass to diffoscope so I get a small readable file and not a bunch of random numbers?
<MSavoritias[m]1>or is that expected?
<nckx>MSavoritias[m]1: Those ‘random numbers’ are the diff, as I suspect you know. Diffoscope can use different external tools to create more structured diffs, for example readelf (guix install binutils) for ELF binaries.
<nckx>Without knowing (and probably with, TBH :-p) what kind of file you're looking at I can't say what you need.
<MSavoritias[m]1>its binary files mainly. the one's stored in /gnu/store
<nckx>Without a format-specific unpacker it falls backs to xxd hex dumps. The problem is it supports so many external tools that adding them all as inputs would be impractical.
<MSavoritias[m]1>i have stumbled onto some determinism issues and i was trying to see if there is a log or something
<nckx>MSavoritias[m]1: But what *kind* of binary files? If executables, try installing binutils.
<apteryx>MSavoritias[m]1: I like to remove some noise with --exclude-command stat
<nckx>--exclude-directory-metadata might also help, and --text-color always makes it a bit more scannable.
<nckx>Ah! ‘diffoscope --list-tools’ is what I was looking for.
<MSavoritias[m]1>that's a lot of tools
<nckx>It's in a weirdly redundant format though.
<nckx>You need only look at one ‘Available-in-distro’ line.
<nckx>MSavoritias[m]1: If you're seeing large differences in *.ja (omni.ja) files, try installing unzip and/or zip.
<nckx>IceCat packs most of the Webby stuff into these opaque archives.
<MSavoritias[m]1>what is the command to use a specific tool like unzip?
<nckx>Not sure what you mean. That diffoscope doesn't recognise a zipped file as zip?
*nckx fixes diffoscope to install a man page 😒
<nckx>Here it is by the way:
<civodul>interesting: Nix now caches "evaluation results" in a local sqlite db:
<civodul>i think it's cheating, but hey, it's always an option!
<civodul>the two first examples at the top are slower than the Guix equivalent
<civodul>but the "nix shell firefox" example is faster than "guix environment --ad-hoc icecat -- icecat --version"
<NieDzejkob>caches make profiling harder :P
<NieDzejkob>yay reproducibility
<civodul>reproducibility of poor performance? :-)
<civodul>not a goal IMO ;-)
<zimoun>civodul: and still some improvements of "guix environment" seems possible as pointed here
<civodul>yes, it's on my to-do list!
<civodul>well there's room for improvement everywhere, performance-wise
<civodul>it's high priority for me
<civodul>and hopefully others out there :-)
<zimoun>speaking about cache and reproducibility, package.cache is not, I guess.
<NieDzejkob>I also plan to focus on performance once I'm done with some bigger yakshaves
<nckx>zimoun: Not even the file size is!
<zimoun>nckx: what do you mean?
<nckx>zimoun: When I compared to package.caches y'day one was 8 bytes larger than the other.
<zimoun>nckx: if you have the time to deal with email (aside the boring reasons), could you send this comment to bug#42009?
<zimoun>I do not know, but basically package.cache is "just" 'compile' to .go
<nckx>zimoun: The boring reasons were server related and should be mostly over now (minus ‘propagation’ time).
<nckx>zimoun: Yes, it's an ELF executable.
<nckx>I don't remember which sections varied. I'll try to reproduce it again.
<MSavoritias[m]1>nckx: to reproduce it I mainly to guix pull --rounds=2 --keep-failed
<MSavoritias[m]1>and it happens everytime
<zimoun>MSavoritias[m]1 what happens everytime? the general non-reproducibility? or the 8 bytes?
***abbe_ is now known as abbe
<MSavoritias[m]1>the non-reproducibility
<MSavoritias[m]1>the caches had a small difference but i didn't do repeat testing to see if it was the same size everytime
<zimoun>MSavoritias[m]1: it is easier for reproducing to simply run "guix build path/derivation/package.cache" than the bazooka --round which recomputes a lot.
<MSavoritias[m]1>and diffoscope was basically giving 20 MB of file differences everytime i was comparing them
<MSavoritias[m]1>hmm. didn't know about that command. Thank you :)
<nckx>MSavoritias[m]1: Lucky you. It gives me 50 😉
<nckx>(Probably because I have binutils installed.)
<nckx>(And pretty colours.)
<zimoun>MSavoritias[m]1: diffoscope is large because some addresses are different I guess. If some Guile compiler expert can look at it? :-)
<MSavoritias[m]1>nckx: maybe you get something more readable than me though. mine was all numbers
<nckx>Yes. Let me whip up a diff.
<nckx>guix lint spewage:
<nckx>Did SWH do a thing?
<zimoun>nckx: nothing I am aware. "guix lint -c archival diffoscope" works guix 82b9ed4
<nckx>Of course now (or: on this box) I can't reproduce the size issue.
<lfam>Interesting aarch64 server product:
<nckx>The addresses still differ though.
<lfam>Could it be a good choice for our build farm?
<nckx>Support Us
<nckx>If you’ve landed on this page because as a European user you’d decided to decline data collection on this site as part of the new GDPR regulations. That’s fine, but that also means programmatic ads, even ones considered safe and non-intrusive such as Google Adsense will be blocked, and income for this website will drop. If you’d like to reconsider your choice, you can click this link to opt-in to data collection:’
<lfam>"Bamboo B1008N is more like an 8 Linux servers-in-a-box rather than a single 128-core server, and all 8 servers interface using Bamboo PANDA (Parallel Arm Node Designed Architecture) system architecture “utilizing embedded systems methodologies, to maximize compute throughput for modern microservices-based workloads while using as little power as possible and generating as little heat as possible”."
<nckx>Now that's localised content.
<lfam>$10000 USD
<lfam>Seems quite nice
<lfam>Well, the price starts at $10k. I don't know how many of the 16-core servers you get for that price
<zimoun>nckx: yes and I do not know if it fixable... Waiting for wise Guile compiler advise. ;-)
<nckx>It's nice. It would be nice to have some benchmarks.
<lfam>That platform is already used in some products by Solid Run, so I bet there are benchmarks for the raw compute
<nckx>lfam: And (I keep hammering on this without being able to contribute; I'm aware) our issue isn't hardware, it's that we don't use it. dmitri and sergei's CPUs have been sitting idle for >87% and >83% of their uptime, respectively.
<lfam>Those are aarch64 builders? (I'm not up to date on the build farm status these days)
<nckx>That's 2 ‘16-core’ Overdrives not used right there. 😉
<jonsger>lfam: but pretty expensive. I did a research on aarch64 servers a while ago, they were starting at 1,5k/2k. But compared with x86 there only very few suppliers
<sneek>jonsger, you have 1 message!
<sneek>jonsger, NieDzejkob says: I've figured out what your problem is. The clue was that even though you only specified the gui output, the binaries from the out output were still there. specification->package+output returns the output as a separate value, so you have to bind it with let-values or handle it otherwise. Stealing a snippet from specifications->manifest, try (map (compose list specification->package+output) ...)
<nckx>lfam: Yes.
<nckx>2 of 4, IIRC.
<lfam>jonsger: Yeah, but it doesn't help to compare prices between architectures when we aim to offer aarch64 anyways. Unless we want to virtualize the build machines
<nckx>Those %s are great compared to the x86_64 builders by the way, which are low single-digits CPU utilisation.
<lfam>It's really surprising to me, because I never get substitutes for bigger packages
<lfam>Blender, Krita, Libreoffice: I almost always have to build, even for days-old commits
<jonsger>lfam: that's a different problem
<nckx>lfam: How is that surprising?
<lfam>I figured they weren't being built due to some resource limit, maybe slowing things down and causing timeouts
<lfam>Unfortunately it's quite hard to find out what's going on :/
<mbakke>cuirass has thousands of packages in the queue, yet the build farm is mostly idle:
<nckx>Yes, the schedulers <adjective of choice>d leaving the build nodes idle.
<lfam>Well, it's good to hear the Overdrives are sufficient for now
<jonsger>NieDzejkob: I don't get your change
<nckx>lfam: Well, in that there's still 85% unused dormant power, yes.
<lfam>But the user experience of substitutes is still suboptimal, and in some ways worse than the best days of Hydra
<lfam>Mark had to do a lot of work manually controlling Hydra, but it worked from the perspective of users
*nckx AFK.
<jonsger>lfam: yes, especially it doesn't provide substitues for the big (desktop) packages. So it can take one or two days to succeed with "system reconfigure" :(
<lfam>We are like 95% of the way there, when you consider how much actually does get built. It would take weeks or months to build the entire system
<lfam>On slower aarch64 consumer-quality platforms, that is. But building libreoffice must still be quite annoying
<jonsger>chromium is the most annoying. 8 or 10h on my laptop
<lfam>I'm impressed that it's that fast!
<lfam>That's not so bad
<cbaines>I've tried to start building aarch64-linux for my build farm, it's just my Pinebook Pro so far though + a couple of machines with QEMU
<jonsger>I didn't measured it maybe even more
<lfam>How is the QEMU performance cbaines? What are the host machines?
<lfam>I am reading your web site cbaines, no need to reply :)
<cbaines>lfam, at least when starting from scratch, performance isn't the problem, quite a few things just fail to build with QEMU emulation
<lfam>So I guess they are decent Xeons with a couple cores each?
<cbaines>Yeah, I think the two Hetzner machines I'm using are 8 core Xeons
<lfam>cbaines already chimed in, but I filed a bug report about UI / UX issues regarding substitute availability:
<cbaines>Frustratingly, even with the automatic retrying I'm using, there's a load of things I just haven't built for some reason:
<cbaines>Anyway, I should probably spend less time starting at graphs, they can be very distracting
<jonsger>NieDzejkob: got it now, missed another (list ...)
<rlp10>I'm trying to decide if I'm ready to try Guix on my laptop. I figured I'd come check out the community. o/
<pkill9>guix is pretty great on a laptop
<rlp10>I've got a Thinkpad T450s, so I'm guessing it should be pretty straightforwards.
<rlp10>Where's the best place to learn Guix, the website? Are there any good tutorials I should be looking at?
<guix-vits> (has search feature)
<rlp10>Thanks, I'll start by having a look there.
<rlp10>Would it be easier for me to learn nixos, before trying guix? Or is guix just as accessible?
<pkill9>i'd say guix is more accessible due to the better package definitions, universal programming language (guile), and easier to understand commandline interface
<guix-vits>rlp10: the point in making Guix was (afaik): to use an general-purpose language (Guile) instead of thing the NixOs uses. Probably You will have more fun with the GNU-maniacs there.
<pkill9>but i haven't used nixos, and it's more popular so i'm probably wrong
<pkill9>plus it's been around longer and has more documentation and stuff
<rlp10>OK, I see. I like scheme more than I like haskell (although haskell is good too), so maybe that is a good reason to try guix.
<pkill9>but guile made more sense to me when i looked at it first
<MSavoritias[m]1>Also Guix has pretty difficult and interesting goals like the bootstrap project
<rlp10>What's the bootstrap project?
<pkill9>i like to think guix has more longevity due to it's focus on bootstrappability
<MSavoritias[m]1>this article is a good start
<pkill9>nix relies on a mixture of it's own language, plus shell scripts, for it's package definitions
<pkill9>whereas guix uses only guile
<rlp10>I see, it doesn't need any other binary blobs.
<rlp10>That website, do you think they would want me to points out typos?
<MSavoritias[m]1>guile also has a whole ecosystem that you can use if you get the hang of it
<pkill9>also check that linux-libre is compatible with your hardware
<rlp10>linux-libre is linux without non-free drivers?
<rlp10>Is linux-libre a distro; I thought guix was the distro?
<pkill9>nah, it's the kernel
<rlp10>Oh I see, got it
<rlp10>And guix uses the linux-libre kernel
<pkill9>the linux kernel minus binary blobs, and minus support for nonfree firmware
<MSavoritias[m]1>usually you look at the wifi card you have and if you have any dedicated graphics card
<nckx>rlp10: The problem with ThinkPads is that most have WLAN chips without free drivers/firmware, and a BIOS whitelist to keep you from replacing them. You'll have to use a USB adapter to use Guix on those machines.
<nckx>The T450 has an Intel iGPU which shouldn't be a problem.
<MSavoritias[m]1>ah ok
<rlp10>OK, thanks, so if I go with guix, I'd be stuck without wifi (until I bought an adapter)
<rlp10>But the graphics wouldn't be a problem
<rlp10>Got it
<nckx>rlp10: That depends on your exact card (see lspci).
<rlp10>Network controller: Intel Corporation Wireless 7265 (rev 99)
<rlp10>If you will forgive me for the blasphemy, can't I use guix with the normal Linux kernel? If I adopt guix and like it, then I am going to want all my colleagues at work to use it too eventually. But they all have different thinkpads. It's going to be a bit annoying if I have to buy lots of wifi cards.
<guix-vits>rlp10: Officially no (but the L. Kernel is just a package, and if You specify an custom one in Your sys. config..). Though with non-free drivers the system can be less fun (i'd troubles with my graphics card during the ever).
<rlp10>OK, I see. I suppose I could install another distro, and then use guix as the package manager. That would also work right?
<pkill9>yea that would work too
<rlp10>In fact, that sounds like a good idea. I'm running Debian now, and I'd like to use the most up-to-date version of Emacs (which isn't in the repository). So I could download the guix package manager and install it from there. I'll give that a go...
*guix-vits "error in finalization thread: success"
<kmicu>rlp10: unpopular opinion here, but learning curve should be the same for both projects ‘cuz they are technically mostely the same in my experience.
<rlp10>alright, thanks. well i've run the installer script and i'm updating the channel now lots of things seem to be happening! i guess all the packages run of their own versions, so it's downloading lots of packages i already have
<kmicu>Guix/Nix stuff is seperated and isolated from your fave distro so nothing is reused from Debian. Generally Guix/Nix requires more disk space, network and compilation than traditional package managers. That’s the trade‑off.
<rlp10>I see, but I'm still downloading binaries, right? I mean I'm not going to have to build firefox, for example, am I?
<kmicu>(* also some things are not packaged nominally hence they pull in not always necessary dependencies)
<kmicu>If everything is setup correctly then no compilation is required; binary substitutes should be available and reachable.
<rlp10>great, thanks
<guix-vits>rlp10: `guix weather [packagename]`
<guix-vits>shows if all substitutes are ready.
<rlp10>a 'substitute' is a binary, like it substitutes having to compile it yourself?
<rlp10>i don't follow why it is "weather" though, the command that is
<pkill9>substitutes are binaries yea
<roptat>rlp10, the website is mostly maintained by guix users/devs, so I'd say yes, we'd be happy if you could point some typos :)
<pkill9>i think it's called weather because it tells you if you're going to have a bad day due to needing to compile, lol
<guix-vits>roptat: You've set-up a Cuirass and steel sane (+ ~9 days)!? :D respect.
<roptat>guix-vits, yes, took me a while to figure things out
<rlp10>roptat: it's "best practices" not "best practises", unless there is a joke/play on words that's going over my head
<roptat>probably not a joke :)
<rlp10>pkill9: :)
<roptat>guix-vits, it took me some time to figure out how to configure it to build all the packages, but leaving out the images and tests
<roptat>there are still some cross packages I'd prefer not to build
<roptat>and then sometimes it fails for no reason at all
<guix-vits>"i've a great idea, but the damned thing resist" -- "someone"
<roptat>also I disabled offloading
<pkill9>what fails?
<pkill9>the build farm?
<roptat>my build farm
<roptat>sometimes, an evaluation just doesn't start but there's nothing in the logs
<roptat>I mean, I get a cross instead of a count of success/failures/being evaluated
<rlp10>how do i search for a package, like the packages that contain "emacs" or "firefox". sorry, i know it's a newb question
<roptat>rlp10, we don't have firefox, we have icecat instead, and looking for firefox will not give you any result
<guix-vits>rlp10: --provides flag is steel missing (or was 9 days ago)
<rlp10>roptat: yes, ok, free software reasons, got it
<guix-vits>rlp10: though it may be possible to search the needed file on, and then search the similarly named package there.
<rlp10>sorry, I ask the wrong question. I mean how do I search for a package with that string in the title
<rlp10>like how do I find the emacs package?
<roptat>rekado, do you know where is hosted? i think it needs to be re-generated (rlp10's typo seems to be fixed in the repo)
<roptat>with guix, you can use "guix show <exact-package-name>" or "guix search <search-terms>"
<rlp10>roptat: perfect, thank you
<roptat>the website is not very interactive, but there's this other website with more javascript:
<guix-vits>rlp10: also: `guix package --help|grep search`
<rlp10>guix-vits: thanks
<kmicu>rlp10: to clarify the lack of Firefox is due to trademark (Mozilla needs to agree for using ‘Firefox’ trademark in Guix) and FSDG which is stricter than libre software (for example Firefox addons (or ad campaigns) steer users into proprietary software and that’s no allowed by FSDG).
<rlp10>kmicu: yes, thank you. i kind of knew that, but had forgotten. like i think debian used to have icecat instead of firefox
<guix-vits>rlp10: They'd used iceweasel :D
<rlp10>oh yes, i remember now
<kmicu>(I only mention that because I see more and more folks saying Fixefox (Rust too) is not libre software even though the sole existence of IceCat proves othewise.)
<kmicu>rlp10: installing graphical apps from Guix in Debian can have some issues (like missing fonts or icons) so feel free to report anything not quite right.
<rlp10>kmicu: thank you, i'll let you know
<raghav-gururajan>Hello Guix!
<sneek>Welcome back raghav-gururajan, you have 2 messages!
<sneek>raghav-gururajan, nckx says: Cuirass is down while I'm typing this; I'll add the job tomorrow.
<sneek>raghav-gururajan, nckx says:
<terramorpha>anybody managed to get build offloading working ?
<raghav-gururajan>nckx: Thanks so much!
<roptat>terramorpha, yes, somewhat, what is your problem?
<terramorpha>I set up the keys with guix archive
<terramorpha>then I added the ssh keys in authorized_hosts
<terramorpha>but when I run guix offload test, I get a cryptic message
<roptat>what does it say?
<terramorpha>"failed to connect to `#<input-output: channel (open) 7ff5c19efe60>': Protocol error"
<roptat>ok, I don't know what that means...
<roptat>you have create a keypair on both machines, and authorized them on *both* machines?
<roptat>can you check you can actually use ssh with that key?
<terramorpha>the guix ones, I have, but not the ssh ones, I think only one is necessary
<terramorpha>They work
<roptat>for the ssh, you only need the server being offloaded to, to authorize connection from the offloading server
<roptat>can you run "guile --version" on the server being offloaded to?
<roptat>I mean, is guile in the PATH of that server?
<terramorpha>The version is 3.0.4
<roptat>have you checked this (from the manual): ssh build-machine guix repl --version
<terramorpha>guix repl (GNU Guix) 1.1.0rc2-1.9d0d27f
<terramorpha>it is also up to date.
<terramorpha>Would there be a way to accesssome kind of stack trace ?
<terramorpha>and find the source of the problem ?
<roptat>I have no idea
<roptat>if nobody can answer here, I'd send a message to
<nckx>terramorpha: ‘authorized_hosts’ → typo? Whose authorized_keys (it should be root's)? Are you running ‘guix offload test’ as root?
<nckx>raghav-gururajan: Happy to. Looks like the current branch isn't evaluating.
<terramorpha>I was running the test as a regular user
<terramorpha>Is that not what I was supposed to do ?
<raghav-gururajan>nckx: Does that mean, something wrong with the commits or something else?
<nckx>terramorpha: No. You need to do everything as root, including ‘sudo ssh offloaduser@host’ so you can type ‘yes’ (my way of adding the host to root's authorized_keys 🙂).
<nckx>Then ‘sudo guix offload test’.
<nckx>raghav-gururajan: It should mean something's wrong with the commits, but ci's been less than reliable lately.
<kernel-help>Hello. Is anybody currently available to help me with inferiors?
<nckx>raghav-gururajan: I'm pretty sure CI's to blame. The evaluation logs are truncated.
<nckx>At the gzip level even.
<kernel-help> I am trying to specify a version of linux-libre for the kernel field as so. But when I run `guix system build config.scm` the process just hangs indefinitely at "Updating channel..."
<kernel-help>I've used this method several months ago, but now it doesnt work
<raghav-gururajan>nckx: Hmm. Let me ask Danny.
<kernel-help>Could somebody help me troubleshoot this issue?
<nckx>kernel-help: I'm no inferior expert, I'm trying your code. But if this is a regression you should report a bug at, it will get more (if not immediate) response.
<roptat>oh I've had some troubles with inferiors recently too
<nckx>kernel-help: The code looks OK…
<roptat>it would hang after using lookup-inferior-packages on the same inferior, on the third different package
<kernel-help>Agree. It matches the lookup-inferior-packages structure
<kernel-help>roptat, im pretty sure thats what is happening here to
<divansantana>is there a quick and easy way to get an "Android Phone VM" up and running on guix system?
<divansantana>A way to run some android apps on guix.
<kernel-help>I wonder if there is a way I can get it to produce a backtrace rather than just hang
<roptat>I used the repl to try and understand why it hung for me
<kernel-help>roptat, did you conjure up a fix?
<kernel-help>or a workaround
<roptat>my workaround was to make a single request instead of multiple requests to the inferior
<kernel-help>roptat, you mean avoid lookup-inferior-packages?
<nckx>If I comment out #;(define linux-libre-4.19-inferior… it works fine.
<roptat>with inferior-eval-with-store
<nckx>roptat: Is there a bug report about this?
<kernel-help>roptat, I dont see that method documented. let me look in the source
<NieDzejkob>terramorpha: You need to make sure that guix and guile are installed in the same profile
<kernel-help>or if you have an example
<NieDzejkob>this is usually something you shouldn't do, so I'd recommend creating a separate user for offloading
<roptat>kernel-help, this is what i use it for:
<terramorpha>NieDzejkob: Why shouldn't I do that ?
<roptat>nckx, there is one... in my mail's drafts ^^'
<NieDzejkob>terramorpha: because guix pull will not work well on that user
<NieDzejkob>to be specific, the `guix' command will not resolve to the profile managed by guix pull
<roptat>kernel-help, from the repl I can run your snippet
<roptat>it doesn't hang
<kernel-help>roptat, mind sharing what you evaluated?
<roptat>basically your code, with some ,use for (guix channels) (guix inferior) and (srfi srfi-1):
<nckx>NieDzejkob: ‘You need to make sure that guix and guile are installed in the same profile’ — what? Which profile?
<roptat>and that returned #<inferior-package linux-libre@4.19.129 7f2843e74750>
<NieDzejkob>nckx: on my offloading user, I have the guix and guile packages in ~/.guix-profile
<NieDzejkob>guile -c needs to be able to import guix modules
<NieDzejkob>otherwise you get the protocol error
<kernel-help>roptat, that is what it returned for me too in the repl. but when I apply it to the kernel field in the system configuration it hangs never the less
<kernel-help>which makes me curious about where that issue resides
<roptat>so it hangs after evaluating the inferior package
<kernel-help>#<inferior-package linux-libre@4.19.129 7fe698304d80>
<kernel-help>we get a different return hash, but i doubt thats relevant
<nckx>NieDzejkob: Works fine here.
<roptat>that's a memory address I think
<kernel-help>oh, I see.
<NieDzejkob>nckx: so, what's the output of `guix package -I` on your offloading user?
<roptat>and actually, it doesn't hang on lookup for me, it hangs when doing some requests on these packages
<nckx>NieDzejkob: I don't think they have a profile.
<nckx>Let me check.
<roptat>(I wanted to use inferior-package-derivation, which I can't use on more than two different inferior packages)
<NieDzejkob>That's why, I'm using Guix-on-Debian on my build machine
<roptat>I think I didn't save the bug report as a draft after all, but I'll re-write it
<nckx>NieDzejkob: Oh! indeed!
<rndd>hi everyone! i'm trying to install guix on my laptop with some packages from custom channels. i wrote /root/.config/guix/channels.scm and run guix pull. but "guix system init" still doesn't see code for custom modules. any ideas?
<nckx>terramorpha: I guess we forgot to ask if this is on Guix System or not.
<NieDzejkob>what does 'type guix' say?
<NieDzejkob>(rndd: ^)
<kernel-help>roptat, nckx: here is my full config if you want to take a peek.
<nckx>terramorpha: But I guess NieDzejkob's advice is solid & worth a try, it's just news to me (offloading works great here without it).
<rndd>NieDzejkob: guix is hashed (/run/current-syste/profile/bin/guix)
<NieDzejkob>rndd: I think 'guix pull' should've told you to either run 'hash guix' or relaunch the shell
<NieDzejkob>rndd: it should say /root/.config/guix/current/bin/guix
<terramorpha>nckx: It is from a GUIX system laptop to an Arch desktop
<rndd>NieDzejkob: oh, thank you
<NieDzejkob>so this applies. Create a dedicated user for offloading and have it 'guix install guile guix'
<nckx>terramorpha: I'm blissfully unaware of the many pitfalls of not using Guix System everywhere 😊
<nckx>kernel-help: When did it start failing? It should be easy to run ‘git bisect run’ on that config.scm. I'll wait for roptat's bug report though.
<kernel-help>nckx: I couldnt pinpoint exactly. sadly.
<nckx>kernel-help: Doesn't need to be. A month? Longer? A week?
<kernel-help>nckx: I originally reported finding a solution here So sometime between Wed, 20 Nov 2019 and now :/
<kernel-help>sorry, thats not probably helpful much
<nckx>No, thanks, it might save a few iterations on a ThinkPad that doesn't like the heat 🙂
<roptat>mh... I can't seem to be able to reproduce the issue anymore...
<nckx>I get the same ‘permission denied’ error with kernel-help's config.scm :-/
<kernel-help>nckx: How are you getting any output at all? mine literally just hangs on Updating channel 'guix'
<nckx>See the paste above.
<kernel-help>nckx: exactly what im running, except im running -M 4
<kernel-help>but yeah
<nckx>Maybe because I don't usually pull from Savannah? Although I quite recently did. Haven't used inferiors in ages though, perhaps they're cached [elsewhere].
<nckx>Ages being a few months.
<nckx>In the before times.
<roptat>nckx, no bug on my side anymore, so no bug report for you :p
<nckx>Well fudge.
<nckx>I guess I'll try strace.
<terramorpha>something changed
<terramorpha>after fiddling with my installation, I now have a different error !
<nckx>OK, /home/nckx/.cache/guix/authentication/channels/guix is root-owned, that's probably not supposed to happen… 😒
<terramorpha>guix offload test no succeeds for the first half, but prints, when trying to send a file over ssh, error while sending files over SSH
<NieDzejkob>could you paste the error?
<zimoun>nckx: no, it is only supposed to be 600.
<terramorpha>"unknown error while sending files over SSH"
<nckx>zimoun: It was, but for root, not for me, hence -EACCESS.
<nckx>Now it just hangs.
<kernel-help>"The task failed successfully."
<nckx>Oh, I spake to soon.
<nckx>(Poor laptop's building IceCat in summer, poor laptop shouldn't be judged.)
<nckx>Now it's offloading stuff.
<nckx>I hope that's not a confounder.
<zimoun>nckx: -EACCESS, what does it mean?
<nckx>(‘guix system build’ is offloading stuff, I mean, not IceCat.)
<roptat>zimoun, E for error, ACCESS for access denied
<kernel-help>eaccess - check effective user's permissions for a file
<zimoun>roptat: thanks
<nckx>zimoun: ‘Permission denied’ in Unix error messages.
<nckx>zimoun: Which is fun, because there's also an EPERM, which is not this! Unix \o/
<zimoun>nckx, kernel-help: thanks
<zimoun>/home/nckx/.cache/guix/authentication/channels/guix should not be root owned but should be nckx owned, I mean if everything is regular. :-)
<roptat>kernel-help, it takes some time but I got passed the updating guix channel message as well
<kernel-help>roptat, im running it with strace right now and strace isnt hanging... so it must be that my computer just isnt powerful enough... i guess
<kernel-help>so, i'll just let it run
<nckx>zimoun: Yes.
<roptat>could also be that it's busy doing nothing :p
<nckx>The hang that was not.
<kernel-help>roptat, how long did it take for you?
<roptat>I mean it's still downloading/building stuff
<roptat>so maybe I just haven't experienced the hang yet
<nckx>kernel-help: Your system's already finished here.
<nckx>Took me a walk to the kitchen and the serving of chocolate milk.
<nckx>And this machine isn't that beefy.
<nckx> → /gnu/store/air4vmfka9jbb6nfygk94xgchlawwp41-system
<zimoun>nckx: it depends on the size of your house. ;-)
<nckx>And the mood of the cow.
<roptat>actually I think it's hanging there now
<roptat>it was building stuff like /gnu/store/pfgm055rdviq95p8lsimp4mq5dfm94k3-sudo-1.9.1-python but now it's just doing nothing
<nckx>Wait, so now I'm the odd one out because it didn't hang?
<nckx>My guix is from today, ffecb23.
<roptat>wait, guix is busy building something, but it dosen't show anything
<NieDzejkob>how many kilowalks to the kitchen does it take to compile icecat? :P
<roptat>oh it's deblobbing the kernel without showing any message
<NieDzejkob>terramorpha: could you paste the entire output of 'guix offload test' (on or similar)
<roptat>so it's not hanging, it's just busy building the kernel
<NieDzejkob>I'm relying on my visual memory of errors here :P
<roptat>which is weird because I'm running it with -n
<terramorpha>guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
<terramorpha>guix offload: Guix is usable on 'espoir' (test returned "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
<terramorpha>guix offload: 'espoir' is running GNU Guile 3.0.2
<terramorpha>sending 1 store item (0 MiB) to 'espoir'...
<terramorpha>exporting path `/gnu/store/b24gddylmp29wn330pbmssr78brkwnrp-export-test'
<terramorpha>guix offload: error: unknown error while sending files over SSH
<NieDzejkob>have you authorized the keys both ways?
<NieDzejkob>both machines need to trust each other
<terramorpha>yes they do
<nckx>terramorpha: Does ‘sudo -i ssh builduser@buildhost’ work?
<nckx>I guess it does if you get that far.
<nckx>Hm, that error message is classic.
<nckx>Blame SSH, run.
<nckx>NieDzejkob: IceCat takes exactly 1 sleep, a remarkable constant over the years!
<terramorpha>it also works
<roptat>nckx, that's also the time I measured for gcc + tests when I used to build LFS systems ^^
<roptat>one day for building everything until gcc, one sleep for gcc and one day to finish the rest of the base system :)
<nckx>roptat: Did you build many? I did it twice, that was enough.
<roptat>oh yeah, dozens
<roptat>I'm one of the translators, so I at least build a system for each version, to get a feel of what's changed
<NieDzejkob>terramorpha: does 'ssh builduser@buildhost guile' and then ',use(guix)' work?
<roptat>and keep being useful on the French channel :)
<nckx>Right, I thought I saw you behind the LFS booth at FOSDEM! (…awkward if not.)
<terramorpha>NieDzejkob: it doesn't work
<NieDzejkob>I got very excited when I first learned of LFS and then got really disappointed when I learned it requires a set of tools from the base distro
<NieDzejkob>terramorpha: what error.
<terramorpha>no code for module (guix)
<NieDzejkob>what does `ssh builduser@buildhost guix package -I` say?
<roptat>nckx, yes I was :)
<terramorpha>guix 1.1.0rc2-1.9d0d27f out /gnu/store/qkl8qjvkfs5hz96l92197cdr2c21i3wf-guix-1.1.0rc2-1.9d0d27f
<terramorpha>guile 2.2.7 debug /gnu/store/mi453hslgnxrjrbmny815qpmvy5hm1pf-guile-2.2.7-debug
<terramorpha>qemacs 0.3.3 out /gnu/store/ky1shnzazldjl7mns4k3wqx9wfxhzgrn-qemacs-0.3.3
<terramorpha>guile-commonmark 0.1.2 out /gnu/store/dy6l4cfpv183b35jnqiyx8f807iyb2vc-guile-commonmark-0.1.2
<terramorpha>emacs-tide 3.2.3 out /gnu/store/wy2f40di19hddw009lx64cq7zxp6awv8-emacs-tide-3.2.3
<terramorpha>xdot 1.1 out /gnu/store/by6m1kwfdx40rwnwhrvrswy1f5il4wxv-xdot-1.1
<terramorpha>zile 2.4.14 out /gnu/store/9n7rz7pxc5wl66d4bmkrlww28nw7pw1v-zile-2.4.14
<terramorpha>guile 2.2.7 out /gnu/store/jgl9d4axpavsv83z2f1z1himnkbsxxqj-guile-2.2.7
<NieDzejkob>do you really need xdot, zile and emacs on your offloading user?
<NieDzejkob>anyway, I think it's an issue with the guix environment not being loaded in non-login shells
<terramorpha>I don't
<terramorpha>that makes sense
<NieDzejkob>on debian, I had to add `source /etc/profile.d/` to the very top of /etc/bash.bashrc
<nckx>roptat: I thoroughly enjoyed LFS way back when (version 6, IIRC). Thanks for contributing to it.
<buenouanq>Say I want to run a script when a particular harddrive is mounted - What is the guix way for going about doing this?