IRC channel logs


back to list of logs

<apteryx>civodul: phew, it worked. Going to send a couple patches soon!
*apteryx dinner time
<civodul>apteryx: yay!
*civodul -> zZz
<civodul>no good outcome for that GLib patch
<civodul>we'll see
<nitro_> #tinycore
<wleslie>I've just set up a new system. I've used debian for the base system (kernel, xorg, window manager, terminal) and then installed guix on top for user applications. I installed guix using the automatic script.
<wleslie>I performed a guix pull on Tuesday and installed a few packages. it failed at one point because it couldn't take the lock in /var/guix/profiles/per-user/wleslie/. I compared this directory with the one on my laptop; on the laptop these are owned by the user, on the new system these were owned by root, and after chowning them I could install things.
<wleslie>today, /var/guix/profiles/per-user/wleslie/current-guix is owned by root again, and so `guix pull` fails with `guix pull: error: symlink: File exists: "/var/guix/profiles/per-user/wleslie/current-guix"`
<wleslie>chowning again did not fix it.
<wleslie>and indeed didn't change anything?
<wleslie>running `guix pull` as root tells me that per-user/wleslie is "not owned by you" and tells me to "change the owner to wleslie"
<wleslie>but I'm root, not wleslie 0_o
<wleslie>rm'd current-guix as root, switched to user, and now pull seems to be doing something
<wleslie>possibly destroying my nice emacs setup but hey at least I have a decent `history`
<lfam>Hm, it sounds like "which user was using which copy of guix" got messed up
<lfam>It's expected that each user has their own copy at ~/.config/guix/current
<wleslie>oh yeah. ~root/.guix-profile -> /var/guix/profiles/per-user/wleslie/guix-profile
<wleslie>huh. I used `su root` to get the root shell. in here, $USER=wleslie
<wleslie>did nyxt go away? `guix package -i nyxt` gives me `error: nyxt: unknown package`, and it's not mentioned on the page
<wleslie>chromium and qutebrowser both immediately crash (chromium reports signal 6, which is SIGABRT?)
<lfam>wleslie: About `su root`, I recommend using `su --login root`. Otherwise you can get a sort-of hybrid environment and it can break parts of Guix
<lfam>I notice that Guix System uses `su` from the shadow package, whereas Debian uses util-linux's `su`
<lfam>The util-linux man page warns about it
<wleslie>good idea, thanks
<lfam>About the crashes... I don't know. That's definitely not expected
<wleslie>looks like `clone(child_stack=... flags=CLONE_NEWUSER|SIGCHLD) = -1 EPERM (Operation not permitted)` is the source of the crash on chromium
<wleslie>hmm, I might need to start the process with specific crapabilities
***catonano_ is now known as catonano
<wleslie>alas; no.
<peanutbutterandc>Hey guix
<wleslie>(greet peanutbutterandc)
<peanutbutterandc>It's my birthday today (:
<peanutbutterandc>wleslie, (:
<lfam>Happy birthday!
<apteryx>Happy Birthday peanutbutterandc!
<peanutbutterandc>apteryx, Thank you (:
<peanutbutterandc>lfam, Thank you (:
<peanutbutterandc>Oh, and if anybody out there has a mediocre job position open for someone like me (, I'm most happily available.
<apteryx>Okay :-)
<apteryx>sneek: later tell civodul heya; by the way it's quite wasteful to offload the image derivations; not only the .qcow2 needs to be downloaded, but also its raw constituent partitions! That's 4 G for the lighweight-desktop image root partition, and 1 G for the final qcow2 :-/. We'll have to introduce some finer grain mechanism to control this.
<sneek>Got it.
*apteryx unlocks persistence for disk images
<apteryx>sneek: later tell civodul sorry for the spam, but one last thing: if you apply the v2 patches from, you can generate an image like: ./pre-inst-env guix system disk-image --image-type=qcow2 --image-size=10G gnu/system/examples/desktop.tmpl; copy it outside the store, chmod +rw, and run it with: "qemu-system-x86_64 -m 2000 -bios $(guix build
<sneek>Got it.
<apteryx>ovmf)/share/firmware/ovmf_x64.bin -hda /tmp/the-image.qcow2 -enable-kvm"
<apteryx>hope that helps your debugging!
<apteryx>sneek: later tell civodul don't forget the '--non-volatile' option tobe able to make use of the extra disk space.
<sneek>Will do.
*apteryx zzzz
<wleslie>on chromium not starting: it looks like a font problem. it crashes with `] Check failed: InitDefaultFont(). Could not find the default font`. I've installed gs-fonts, font-dejavu, font-gnu-freefont-ttf, and fontconfig, and run `fc-cache -rv` and xset
<wleslie>yet the error persists
<wleslie>is there something I should install in my profile to grant clients DRI access to an AMD GPU?
<wleslie>despite my success with khtml-based browsers being so far a complete failure, does anyone know why nyxt is uninstallable?
<mbakke>wleslie: what does 'guix describe' say?
<efraim>and what does 'which guix' say
<wleslie>oh dear. it's 1.1.0, yet /usr/local/bin/guix
<wleslie>could be a conseqence of my profiles being mixed up, will try guix pull as root
<mbakke>wleslie: make sure ~/.config/guix/current/bin appears first in PATH
<wleslie>apparently the install script sets it up as root's current guix
<mbakke>I think the install scripts drops a /etc/profile.d/ script that DTRT, but you need to re-login for it to take effect.
<abcdw>hi guix!
***apteryx is now known as Guest28272
***apteryx_ is now known as apteryx
<vits-test>sneek: botsnack
<wleslie>installing :) thanks!
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 3 messages!
<sneek>civodul, apteryx says: heya; by the way it's quite wasteful to offload the image derivations; not only the .qcow2 needs to be downloaded, but also its raw constituent partitions! That's 4 G for the lighweight-desktop image root partition, and 1 G for the final qcow2 :-/. We'll have to introduce some finer grain mechanism to control this.
<sneek>civodul, apteryx says: sorry for the spam, but one last thing: if you apply the v2 patches from, you can generate an image like: ./pre-inst-env guix system disk-image --image-type=qcow2 --image-size=10G gnu/system/examples/desktop.tmpl; copy it outside the store, chmod +rw, and run it with: "qemu-system-x86_64 -m 2000 -bios $(guix build
<sneek>civodul, apteryx says: don't forget the '--non-volatile' option tobe able to make use of the extra disk space.
<mbakke>related to the disk image offloading, we need a much more aggressive GC schedule on the build nodes; maybe -F 200 every 8 hours?
<civodul>mbakke: hi! did you notice ENOSPC recently?
<mbakke>civodul: indeed, even with manual GC in between the sceduled ones!
<wleslie>settrans -fa /hurd/greet civodul
<wleslie>I have a working browser! thank you so much mbakke & efraim
<mbakke>wleslie: cool :-) can you file a bug report about ungoogled-chromium failing on Debian? I'll try to reproduce in a few days.
<wleslie>I'll re-install it now that I have updated guix and double check it's still a problem
<civodul>mbakke: i'd go for a higher daily threshold and half of that at midday; does that make sense?
<civodul>running more often than that could be too much
<efraim>would using the timeout command from coreutils help with limiting the amount of time spent running GC or would that just make it run out of space
<efraim>and would a job to just remove disk and qemu images help with that?
<mbakke>efraim: GC is pretty quick on the builders, but Berlin wastes a lot of bandwidth sending the closures.
<mbakke>civodul: makes sense ... tbf I've mostly noticed ENOSPC in the context of ungoogled-chromium, which needs a whooping ~40 GiB.
<mbakke>I'll update guix-maintenance and try a deploy this afternoon.
<mbakke>efraim: a job to remove the disk images would make a lot of sense though ... is there already such a script somewhere?
<efraim>mbakke: rekado posted one forever ago: guix gc --list-dead | grep -E '((disk|qemu)-image|installation)' | xargs guix gc -D
<efraim>I have a working phase for the python-build-system which does a simple search for Cythonized searches but doesn't check them or error if it finds them
<vits-test>small off-topic fun: query "gnu elections" -> "".
<vits-test>21 century: leaders are immortals, and never get older.
*vits-test .-.-.-
***brown121407 is now known as b7
<civodul>mbakke: the job to remove specifically disk images is costly though
<civodul>i think it's better to make sure we don't keep GC roots to those
<civodul>and then just let the GC do its work
<civodul>there's a cleanup-cuirass-roots mcron job on berlin
***b7 is now known as brown
***brown is now known as Guest62565
***Guest62565 is now known as b121407
***b121407 is now known as zazavatar
***zazavatar is now known as brown121407
<mroh>aha, just 2 inputs in gst-plugins-bad for a webrtc module, it seems.
<civodul>apteryx: hey! did you push the update-guix-package patch? i can't find it
<ane>with guix using recutils to display search results, is this done via a guile wrapper for librec or are the results generated by hand?
<bluekeys>Hi guix. str1ngs, I've been told that you have a pinephone, is that right? Any thoughts on getting guix on it?
<bdju_>hm I can't do a second update with --dry-run to see if the package I'm building has a substitute by now
<bdju_>anyone know if qtwebengine has a substitute? I started updates last night and it's still going because of qtwebengine
<vits-test>bdju: what about `guix weather qtwebengine` ?
<bdju_>thanks, didn't know weather worked for individual packages. looks like there is no substitute yet, so I'll let it finish
<lurdan>hi, please help me to rescue my guix system, which can't boot. I try to live linux distro and mount filesystems, but noticed that I can't chroot in that guix system (chroot doesn't know where to exec bash...)
<efraim>/run/current-system/profile/bin/bash I think. I'm on my phone
<g_bor[m]> [lurdan]( what does it say whrn you try to boot it?
<g_bor[m]>Can you boot an earlier generation?
<lurdan>[g_bor] No, my earlier generations also don't boot (because I've changed filesystems, so I try to boot system with live linux ditro(finnix) and mount guix system's filesystems.
<g_bor[m]>You could try to find a bash in the store and run that in the chroot
<lurdan>[efraim] Thanks,so, I guess, specifing that path to chroot, and after logging in, I will be required to set PATH to current profile, herd start guix-daemon, ...and might be able to run guix reconfigure...?
<g_bor[m]>Most probably yes.
<lurdan>Thanks, I'll try!
<g_bor[m]>You can source the current profile envvars as per the suggestion on the command line.
<civodul>ane: recutils formatting is done in Scheme, for instance:
<civodul>there's also a minimal recutils parser:
<ane>civodul: ok. recutils has librec, perhaps it would be useful to make a guile wrapper for it.
<civodul>ane: yes; i don't think it's useful for these use cases but for more general recutils processing, surely
<apteryx>civodul: I thought I did! On version-1.2.0 only I think
<apteryx>perhaps it failed and I didn't noticed
<civodul>apteryx: ah ha! could be, i don't see it there
<apteryx>indeed, it's not there :-/
*apteryx reflogs...
<civodul>at worst it's in the ML archive :-)
<apteryx>yeah, the version I thougth I pushed had two small fixes on top of that IIRC
<apteryx>ok, found it
*abcdw wondering, when 1.2 will be released and is there a release schedule?
<apteryx>civodul: pushed! 3de898b43c
<lurdan>hmm, it seems difficult to run guix in chroot, it fails to setup build environment ... almost same course:
<civodul>apteryx: thanks!
<civodul>abcdw: roughly, "in the coming days"
<civodul>we're ironing out final details
<civodul>i'd really like to get the gappinfo thing fixed because i think it makes a real difference to desktop users
<apteryx>civodul: sadly I won't have time to dedicate to gappinfo until the weekend, I'm afraid. I hope the patches shared for the disk-image action will provide at least better debug tools for the endeavour!
<civodul>apteryx: i haven't tried them yet; i have a hacky workflow where i share a host dir over 9p and then link to that from /var/guix/profiles to emulate "guix install" :-D
<civodul>it does sound like a real improvement though, so thanks for doing that!
<civodul>i *think* i'm approaching a real patch for gappinfo
<civodul>if everything goes well, i'll post it, and then maybe we can to an RC/testing round
*civodul crosses fingers
<apteryx>civodul: please include support to /run/current-system while you're at it, if it's not too much too ask! It'd be a shame to have to revisit this later.
<apteryx>(given how much time consuming it is to test)
<apteryx>this is another version I had cooking, but it's based on the same scheme you had tried so doesn't work. Putting it here in case it's of use:
<apteryx>one thing to note is that if the .guix-profile doesn't exist from the start, the alternative-desktop-file or something called similarly will search up for an existing directory and put the watch on that
<civodul>apteryx: yes, i've included /run/current-system support this time :-)
<apteryx>great! thank you!
<civodul>here's the hopefully final version of the patch:
<civodul>roptat: salut ! in, should we systematically use a no-break space before semicolons and colons, and after opening guillemets and before closing guillemets?
<divoplade>Don't forget the question mark and exclamation marks
<apteryx>civodul: cool! so my original idea to find the mutable directory holding the links did make some sense :-) I hope it works!
<abcdw>How many people use gpg keys for ssh?
<vagrantc>ssh keys from openpgp are great!
<vagrantc>being able to set expiry and leverage the web of trust is pretty handy for an authentication scheme
<civodul>apteryx: definitely, that put me on the right track!
<civodul>vagrantc: oh there's an extension to use OpenPGP keys for SSH authentication?
<vits-test>abcdw: U mean instead of passwords? I think everyone.
<vagrantc>yeah, you can use gnupg-agent instead of ssh-agent
<vagrantc>and you use an authentication subkey ... which you can extract the public key in ssh-friendly format with gpg --export-ssh-key USERID
<civodul>you can use gpg-agent, but for regular SSH keys
<abcdw>vits-test, nope I mean gpg --export-ssh-key and gpg-agent instead of ssh
<civodul>oh, --export-ssh-key
<vagrantc>it is the way to go, as far as i'm concerned :)
<vagrantc>and then you can use an openpgp token for both pgp and ssh
<vagrantc>there are also some curious packages in guix to support this sort of thing using cryptocurrency tokens ...
<vits-test>abcdw: ah, interesting.
<vagrantc>python-trezor-agent and company in gnu/packages/finance.scm
<vagrantc>so, now there are guix packages in debian that actually build on amd64 and i386 :)
<vagrantc>armhf has test suite failures, and arm64 doesn't have a working guile-gnutls for guile 3.0
<vagrantc>but it's a start
<vits-test>boo! gnu/packages/fiancé.scm
<vagrantc>considering one of my motivations for packaging it for debian was to do easier guix installs by installing debian, installing guix and then instantiating a Guix System from there...
<vagrantc>(on armhf/aarch64)
<divoplade>That's my favorite way to install guix :)
<vits-test>hm, last time i tried debian->aarch64 i failed to prepare image. used armbian instead.
<vits-test>to install guix
<vagrantc>civodul: to get the packages to build, i mostly ended up just adding a 100-200 (unless (network-reachable?) (test-skip 1)) around tests using bootstrap binaries ... so not ideal
<vagrantc>guess to get guix to build on anything other than x86_64/i686/armhf/aarch64 you need to pass --with-courage
<vits-test>sometimes --with-thrashing, acc. to someone.
<civodul>vagrantc: around uses of %bootstrap-guile specifically, right?
<vagrantc>interestingly, guix tried to build on armel (armv5t) and got just as far as armhf ...
<civodul>--with-courage is for platforms Guix does not support yet
<vagrantc>civodul: and boatloads of other %bootstrap*
<civodul>so in Debian you don't want to use it
<vagrantc>civodul: but how will it build on hurd? :)
<vagrantc>civodul: there were also numerous tests that didn't directly mention the bootstrap binaries, but used them indirectly
<civodul>--with-courage is no longer needed for the Hurd, is it?
<vagrantc>civodul: and also possibly a few i added in error ...
<civodul>if you could list your findings by email, that'd be great
<vagrantc>civodul: i found a lot that ended up using %guile-for-build ... which tried downloading %bootstrap-guile, for instance
<vagrantc>ah, sure
<vagrantc>a little easier to reference than irc :)
<civodul>yup :-)
<vagrantc>i acutally haven't tested that the packages work in quite a while ... hopefully ... :)
<lane>hi all, I'm completely new to guix, but I'm hoping to use it for a project and want to start by packaging by project's dependencies. I tried following the "Building From Git" instructions and I got the following error when running `configure`: "checking whether Guile-JSON is available and recent enough... no
<lane>configure: error: Guile-JSON is missing; please install it." I tried doing `guix environment guix --pure --ad-hoc guile-json` to fix the issue, but it didn't seem to work. Any ideas?
<lane>(`bootstrap` seems to have succeeded with a couple of warnings)
<civodul>lane: hi! it could be that your Guix is providing too old a version of Guile-JSON
<civodul>you can fix that by running "guix pull" first
<lane>civodul: thanks, I'll try that!
<lane>hmm, didn't seem to fix the issue
<db48x>lane: if you're building guix from scratch before installing it, then you need to install Guile-JSON either with your normal package manager (apt, rpm, etc) or from source (it's on GitHub)
<lane>I also notice during configure that it checks for guile 3.0 and 2.2 but then continues with 2.2... does guix itself still use guile 2?
<civodul>lane: it can be built with 3.0 or 2.2; 3.0 recommended
<lane>db48x: I've installed guix already using the shell script, so it seems like I should be able to get the dependencies from my installed guix
<lane>civodul: do you need to configure specially to build with 3?
<lane>hmm, when I do `guix show guile` the latest version seems to be 2.27
<lane>`guix refresh guile` shows: gnu/packages/guile.scm:258:13: guile would be upgraded from 2.2.7 to 3.0.4
<vagrantc>have you logged out and logged back in since you ran guix pull? it might be still using your old guix
<lane>vagrantc: I have not. I'll try that, thanks
<vagrantc>and once you've gotten to a guix that defaults to guile >= 3.0, you might need to re-run ./bootstrap
<vagrantc>hope they make it back :)
<lane>thanks everyone, I got configure to work by logging out and back in
<lane>./pre-inst-env guix build openFrameworks
<lane>hahahah wrong buffer sorry
<vagrantc>i guess you could have done "hash -d guix" instead of logging out ... i'm less familiar with that
<vagrantc>or opened another shell
<nckx>Morning Guix.
<nckx>vagrantc: Party hard.
<nckx>& thanks.
<wleslie>nice work
<wleslie>I've just had the fun of getting guix working on top of a fresh buster install, so even before all the politics I get that it's a mean feat
<wleslie>not meant to be a slight on guix, just that there's definitely work to do.
<zzappie>vagrantc: wow this is amazing!
<zzappie>I think there is going to be a lot more guix adoption when it's one apt install away
***bdju_ is now known as bdju
<vagrantc>nckx, wleslie, zzappie: testing appreciated if you can :)
*vagrantc will return
*vagrantc waves
<g_bor[m]>Hello guix!
<g_bor[m]>I've just picked up a conversation the backlog about the netlink binding.
<g_bor[m]>What is the status of that?
<fnstudio>hi, out of curiosity, looking at the upgrading instructions here, shouldn't that make mention of `guix package --upgrade`?
<nckx>‘Upgrading Guix’ is about updating Guix the package manager itself as well as the available packages.
<vits-test>nckx: though 2.7 has no link to Getting started
<fnstudio>nckx: right, got that, i was just wondering if that's necessarily clear to someone jumping on that page for the first time
<vits-test>while 3.7 After System Installation has a link
<nckx>vagrantc: Can I test it on ‘Debian Sid’ in a reversible fashion? Very little Debian knowledge beyond running apt this && apt that every month.
<fnstudio>nckx: although i realise that a significantly common pattern (eg in Debian it's update + upgrade)
<vits-test>fnstudio: guix is rolling distro. pattern is update, read news (if grub wasn't broken?), upgrade.
<nckx>vits-test, fnstudio: I agree that a pointer to a page explaining how to upgrade packages (is that Getting Started?) would be nice at the end.
<nckx>I think mentioning ‘guix upgrade’ itself under ‘upgrading Guix’ would confuse matters.
<fnstudio>nckx: true, but that highlights there's an underlying issue
<fnstudio>nckx: which doesn't go away if it's not mentioned in that particular section
<vits-test>sneek: seen issues?
<sneek>Sorry, no.
<nckx>fnstudio: Which is?
<vits-test>fnstudio: no issues.
<vits-test>sneek: botsnack
<nckx>fnstudio: The concept of ‘updating available packages’ vs ‘updating packages’ itself?
<vagrantc>nckx: generally hard to downgrade in debian
<fnstudio>nckx: the fact that upgrading is used with two different meanings in (pretty much) the same context might be confusing
<nckx>vagrantc: So Sid != Experimental? Never mind then.
<fnstudio>nckx vits-test: don't get me wrong, it's not the end of the world
<vagrantc>nckx: experimental is just a few arbitrary packages that aren't appropriate for sid, more or less
<fnstudio>i was just pointing out a possible (minor) UX point
<vagrantc>aren't yet ...
<nckx>fnstudio: Well, you are ‘just’ upgrading the Guix package (which bundles its own package definitions unlike most PMs), so it's the same meaning, but point definitely taken.
<nckx>Do you know whether there's an attempt to explain this elsewhere in the manual?
<fnstudio>nckx: let me see
<fnstudio>nckx: well, definitely here:
<fnstudio>in the `--upgrade` section
<fnstudio>it mentions the distinction
<fnstudio>"To update your distribution, you should regularly run guix pull"
<fnstudio>so the information is definitely there
<fnstudio>and i assume that most people are familiar with some sort of 2-step pattern
<nckx>It seems like the kind of thing you need to read several times or in the right order before all parts make sense. Maybe. It's very hard to read this stuff with new eyes.
<fnstudio>nckx: true...
<nckx>fnstudio: If you have any specific suggestions to improve this (or want to try your hand at rewriting parts), please do. Fresh perspective & all that.
<g_bor[m]> [vagrantc]( you need testing on debian?
<nckx>(I don't mean to imply you're new here, I know you're not.)
<fnstudio>nckx: if you're new to the system (like more or less i am), you search for "guix upgrade" and you land on that page and you *might* (maybe not) have the expectation that that does the whole trick
<g_bor[m]>I can spin up a vm tomorror.
<g_bor[m]>What should be checked?
<fnstudio>nckx: sure, that's a great idea, i'll see if i can think of a tiny change that might make it more intuitive for a new person
<fnstudio>nckx: thanks so much for your time
<nckx>fnstudio: Thank you!
<roptat>g_bor[m], I'm working on it
<roptat>I plan to implement the missing part (the routing protocol) this weekend
<roptat>I'll also need some sort of high-level interface that we can use in the guix service to provide interface configuration
<roptat>right now I have the interface and address protocols, so I can create, view, and modify links, and add, delete and view addresses (v4 and v6) on interfaces
<roptat>g_bor[m], also
<civodul>roptat: woohoo!
<roptat>all I'm missing is the ability to view, add and delete routes, and I'll have the same functionalities as the static-networking-service-type, except it'll work for v6 too :)
<vagrantc>g_bor[m]: well, i can probably test it myself, but it never hurts to have other people point out issues too :)
<vagrantc>g_bor[m]: basically, test how the guix package works on a foreign distro ... ... apt install -t experimental guix ...
<vagrantc>i *think* guix-daemon should come up out-of-the-box and then that the guix command does the usual things :)
<cbaines>congrats vagrantc on getting the Debian package for Guix in experimental!
<vagrantc>it's been a bt of a hairpulling adventure, but luckily i have plenty of hair :)
<cbaines>What's the path between experimental and unstable? As far as I remember, packages don't trickle down automatically...
<vagrantc>cbaines: effectively have to do an upload to unstable and bump the version
<vagrantc>cbaines: currently blocked by guile-gnutls version supporting guile-3.0
<vagrantc>or ... fixing or disabling tests with guix on guile-2.2
<cbaines>Right, OK :)
<vagrantc>i wonder if some of the failures are due to unavailable locales ... maybe i should build-depend on locales-all
*vagrantc really wishes guix supported C.UTF-8
<apteryx>hmm, pigx is failing on version-1.2.0: pileup.c:287:25: error: dereferencing pointer to incomplete type ‘struct bam_mplp_s’
<vagrantc>but that means getting upstream glibc to support C.UTF-8 ...
<apteryx>rekado: ^
<apteryx>(about pigx failing to build on master)
<vagrantc>oh yes, need to ... "guix archive --authenticate"
<vagrantc>well, looks like the debian packages don't know about any substitutes, and guix pull doesn't know where to get the origin/keyring branch from
<vagrantc>so, it belongs in experimental thus far :)
<mbakke>vagrantc: really awesome work :-) is it safe to 'apt -t experimental install guix' on current stable?
<happy_gnu>hello guix :)
<vagrantc>mbakke: it'll pull in a lot of non-stable core libraries, probably
<vagrantc>guix weather reported 87% substitute coverage, but it won't even "guix build hello" without bootstrapping everything
<vagrantc>i know i've seen this before: guix pull: error: Git error: cannot locate local branch 'origin/keyring'
<fnstudio>hi, i'm reading this regarding the use of substitute servers (disclaimer: i'm on a foreign distro)
<fnstudio>is there a standard location or place from where i can retrieve ?
<fnstudio>i can actually find a file with that name in `.cache/guix/checkouts/...`
<fnstudio>which i suppose will do it
<db48x>fnstudio: it should have been installed along with guix itself, however you installed guix
<civodul>yes, typically in /var/guix/profiles/per-user/root/share/guix
<civodul>vagrantc: you're missing the "keyring" branch in the repo you pulled from maybe?
<fnstudio>db48x: yeah, but mind i'm on a foreign distro, does that make any diff?
<civodul>vagrantc: see
<db48x>fnstudio: no, though it might change where guix is installed
<fnstudio>db48x civodul: oh i see, thanks, let me have another look
<vagrantc>civodul: did someone delete the keyring branch from savannah? :P
<fnstudio>ok, i've run `guix archive --authorize ...` as per and now i'm testing with something like `guix build emacs --dry-run`
<fnstudio>however, i get `The following grafts would be made: ...`, while the url above says i should expecting `112.3 MB would be downloaded:`
<fnstudio>is that ok?
<vagrantc>.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq contains remotes/origin/keyring
<fnstudio>maybe it's simply because emacs is already installed, let me try with another package
<fnstudio>yay, it seems the output matches what shown in the manual if the package is not yet installed
<fnstudio>so i suppose it's all fine
<vagrantc>ok, apparently "git checkout origin/keyring origin/keyring" made it work ... but ... that doesn't seem right.
<fnstudio>hm... sorry, me again, i'm not sure... if i then type `guix upgrade`, i see that some derivations are actually going to be built
<vagrantc>and none of the substitues match, despite what guix weather thinks
<vagrantc>... /o\
<vagrantc>it actually needed a branch "origin/keyring" ... not to be confused with the "keyring" branch from remote "origin" ?
<mbakke>vagrantc: weird, what's the version of libgit2 (/me is grasping at a straw)?
<vagrantc>mbakke: ii libgit2-28:amd64 0.28.5+dfsg.1-1 amd64 low-level Git library
<mbakke>huh, that's ancient, perhaps that is actually the issue?
<mbakke>I think the keyring code was added after libgit 1.0
<mbakke>vagrantc: re substitutes, you get the same result for 'guix build -d hello' with the debian package as you get with the guix binary?
<fnstudio>is there an option for `guix upgrade` that prevents anything to be built? a `--substitutes-only` or `--no-build` kind of thing?
<fnstudio>*from being built
<vagrantc>mbakke: it's still building the bootstrap binaries
<vagrantc>mbakke: so i don't know
<vagrantc>fnstudio: no, unfortunately
<mbakke>vagrantc: try with --no-grafts
<mbakke>that should not build anything
<fnstudio>vagrantc: hm i see, interesting, i wonder if there's a specific reason for that or just because it happens to be so
<nckx>fnstudio: It's just not easy to implement, and nobody has done so yet.
<fnstudio>nckx: right, understood
*nckx frustratingly close to getting the GNU Eiffel compiler to build. Builds in a pure environment, not as a package, grrr.
<nckx>But none of this matters anyway because all of these compilers ‘bootstrap’ from generated C, so... yay?