IRC channel logs


back to list of logs

<bavier>c0c0: what's 'guix --version'?
<c0c0>bavier: just did a guix pull, and now it is available
<reepca>linux-libre-headers@5.3.1 seems to fail to build, the log complains about failing to find rsync in the 'install' phase?
<reepca>nckx: ^
<quiliro>Hello...I wanted to make a presentation for Emacsconf by showing my Emacs keypresses. I was suggested to install key-mon. I found it exists asa a Guix package. So i installed it successfully. But I cannot open it. Would anyone care to test please?
<apteryx>more trouble with probing btrfs subvolumes: the partition needs to be mounted for it to succeed... We could attempt to mount it ourselves, but then, what if it's sitting on an encrypted LUKS block? That would ask for a password... and it's complex.
<apteryx>So I think to refrain from any *live* probing is a more sane choice for Guix and Btrfs submodules. It can do something basic that'll support 90% of use cases, and allow for declaring more complex scenarios in tho operating-system config for those users.
<apteryx>*who need it.
<quiliro>I guess no one uses key-mon here...
<quiliro>gotta is another now!
<janneke>...building qt-everywhere-src-5 again -- how do i get rid of this disaster :( / :)
***Forza_ is now known as Forza
***freedom_ is now known as freedom
<efraim>use qtbase and other qt modules
<roptat>hi guix!
***Guest31236 is now known as Guest312361
***Guest312361 is now known as sturm2
***emyles``` is now known as emyles
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 1 message.
<sneek>civodul, dongcarl says: I'm sorry I didn't respond to your email fixing the store-error-protocol, but everything seems to be working alright now :-) Thank you!
<nckx>reepca: rsync? Nice. Thanks!
<nckx>First coffee, then fix.
<civodul>hey dongcarl!
<civodul>dongcarl: i thought the fix would allow you to see what exactly fails to build, i didn't expect it to actually fix the build failure
<civodul>oh well, it's better this way! :-)
<civodul>heya nckx!
<civodul>do you think you could have the overdrives back on-line? :-)
<g_bor>hello guix!
<nckx>civodul: Huh?
<nckx>You say this like they've been gone a while. They AFAICT haven't. OK.
<efraim>efl update needs a bunch of massaging, they switched from autotools to meson
<nckx>civodul: (Still) -ECANNOTREPRODUCE as I noted here on the 27th. I can ssh into both of them. Slowly, but that could just be the café wi-fi. Could you explain what exactly I should be looking for?
<Chiliparrot>Hi there! I'm playing with guix in a VM and have been waiting for a "system reconfigure" form more than a day to finish :-(
<Chiliparrot>Is there a simple way to pin the version of the kernel? Apparently, building is responsible for the delay, and I don't care about the kernel version
<nckx>They *are* both idle, but I can't berlin to find out why.
<nckx>civodul: ☝
<nckx>Chiliparrot: (operating-system … (kernel linux-libre-foo) …) ; will pin a kernel version
<Chiliparrot>thanks nckx - I'll try that
<nckx>Chiliparrot: That won't keep your kernel from being rebuilt when a dependency changes. And linux-libre was updated to 5.2 quite some time ago (a week? seems like a month :), substitutes would have been built by now.
<Chiliparrot>Mh, maybe just bad luck with the timing... just restarted the process, wish me luck ;-)
<efraim>efl-1.23.0 wants a bunch more propagated-inputs :/
<nckx>Chiliparrot: Good luck, I'm curious.
<Chiliparrot>nckx now guix fetched llvm and is building xf86-video-vesa... but I'm coming from Gentoo, so I'm used to wait ;-)
<roptat>nckx, maybe it changed IP and berlin cannot access them anymore because of the firewall? It happened to mine once
<nckx>roptat: That's happened (my main ‘home server’ is off-line longer that expected due to RAID drive warranty issues, and it handled the DDNS which I now do by hand like an ape-man). But that's not the case now.
<nckx>roptat: / ­— they should both resolve and listen to the Internet.
<roptat>I mean the firewall at the MDC only allows connections on a set of IPs, so if the IP linked to your domain changed, berlin cannot reach it
<roptat>unless it uses a tunnel somewhere
<roptat>where do these names come from?
<nckx>roptat: That should be the case. And rekado was trying to get them to support DNS-based whitelisting, I don't know if that succeeded.
<nckx>(I don't have SSH access to berlin so this is all just guesswork.)
<nckx>roptat: How so?
<roptat>I mean, why dmitri and sergei?
<nckx>Oh 🙂 Two of my favourite composers, and they fit in my 6-letter naming scheme.
<roptat>I see
<nckx>(And ‘wagner’ might've been a bit too controversial.)
<roptat>civodul, I can confirm I can access nckx's servers from here, can you from berlin?
<nckx>roptat: Thanks so much for testing.
<roptat>mine is broken, along with my internet... so berlin doesn't have a lot of arm build machines right now...
<g_bor>hello guix!
<nckx>o/ g_bor.
<nckx>roptat: Your… Overdrive is broken? ☹
<roptat>for some reason the kernel disappeared from the store
<roptat>I can boot the old system because I kept the old /etc around
<nckx>Hey! I had that exact problem many times over when I first installed them (that's why it took so long).
<roptat>but I don't remember the root password, so it's a bit useless, and until I have internet at home, I can't really work on that issue (can't download packages or sources)
<roptat>what caused this?
<nckx>I wish I knew. I really do. I was debugging it and suddenly (I'm sure I did something subtly different during the 17th installation) vanished. So yay build machines, boo no clues.
<roptat>could it be some incompatibility with btrfs or something?
<roptat>it should have been live, so guix gc shouldn't have collected it, but I don't see any other explanation...
<aitzkora>Hi, Somebody knows how to pull the specific version for a channel like guix pull --commit=
<roptat>aitzkora, in your channels.scm, you can specify a commit
<g_bor>Now the Outreachy contribution period is officially open.
<roptat>actually, I might be wrong
<aitzkora>roptat: with an special field ?
<roptat>I think (commit "commit n°"), but I don't find it in the manual anymore...
<roptat>yes, looking at the code, commit should work
<nckx>roptat: Possible, but ‘weirdness’ still happened on ext4 (which both my Overdrives now use). I run multiple Guix Systems on different btrfs configurations, all work fine. But of course none of those have been borged from Suse.
<roptat>ok, well I hope I can fix this and my internet quickly
<roptat>my ISP said "before the 7th"
<nckx>No Internet at home? That's some special kind of hell.
<aitzkora>roptat: thanx, it seems to work
<roptat>nckx, they gave me a 4G device as a temporary measure, but doesn't work well behind the thick walls
<nckx>roptat: Friendly neighbours…?
<jonsger>nckx: you have a problem with SUSEs btrfs on those machines?
<nckx>jonsger: No, and other people have apparently installed Guix System ‘over’ openSUSE with success, I'm certainly not blaming it.
<nckx>‘Something’ was corrupting the database (/var/guix/db/…), although not in a way that caused hard errors, just missing rows (and hence GC'ing of things that really oughtn't been GC'd).
<jonsger>hm, doesn't seem so easy to debug
<nckx>I mean, it's possible that SUSE was to blame, it just doesn't seem likely and I don't want to be quoted as such 🙂
<nckx>jonsger: It wasn't, and unfortunately (in hindsight) I was too focused on getting these machines up and not on fixing the issue. I changed far too many variables at once, then suddenly it worked.
<jonsger>nckx: so they do work now?
<nckx>jonsger: The machines themselves work perfectly.
<desmes>hey guix!!
<coldpress>hi desmes
<civodul>hey, hey!
<desmes>Should I run "sudo guix pull" besides "guix pull", from time to time? When I run "sudo guix system reconfigure /etc/config.scm" it says that the root user has never ran "guix pull".
<nckx>desmes: Do you use Guix System?
<nckx>If not, you should look into how to make ‘sudo’ call your *user's* guix, not root's. ‘sudo -E’ usually does the trick although IIRC there's some gotcha on Ubuntu.
<nckx>root's Guix is only used for the daemon launched on non-Guix systems. You can edit /etc/systemd/system/guix-daemon.service to change that. I always change it to /var/guix/profiles/per-user/nckx/current-guix/bin/guix-daemon and never pull as root. Otherwise, you should pull as root once in a while to keep your daemon relatively up to date, but it's not as important.
<nckx>AFAIK all CVEs in the daemon are currently undiscovered 🙂
<desmes>nckx: Yes I use guix system
<nckx>Anyway, you never need to pull as root on Guix System.
<nckx>I'm not sure why you get that error.
<desmes>nckx: But I find it strange that that message appears when running 'reconfigure'
<desmes>Ah ok I see
<desmes>Thanks for the info!
<nckx>desmes: What does ‘sudo which guix’ say?
<g_bor[m]>desmes : the trick with sudo -E still apply on guix system, i believe.
<desmes>I'm currently reinstalling since I got the file system corrupted
<nckx>g_bor[m]: What trick?
<roptat>using sudo -E instead of plain sudo
<desmes>sudo -E guix pull then??
<nckx>desmes: No. sudo -E guix system reconfig.
<civodul>nckx, roptat: "ssh -p 5551" or "5552" fail for me (from home)
<nckx>roptat, g_bor[m]: Are y'all sure? nckx@dmitri ~$ sudo which guix → /home/nckx/.config/guix/current/bin/guix
<desmes>Ok. But if doing it with -E applies on the guix system, what does doing it without the -E do?
<nckx>desmes: Well, according to me, the exact same thing nowadays, but there seems to be some disagreement 🙂
<roptat>civodul, works from the Inria network :)
<roptat>nckx, absolutely not, I don't use sudo
<nckx>desmes: In any case: it used to call root's Guix.
<apteryx>civodul: unreachable for me too
<nckx>There's no need to ever do that on the average system. You can use your user's Guix for everything and it avoids confusion (did I pull? as whom? which commit will this command use?)
<apteryx>port is not listening it seems
<nckx>‘works from the Inria network’ ‘port is not listening it seems’ — well, I'm sufficiently confused.
<desmes>nckx: I'm sorry. There is no need to do what?
<nckx>desmes: Run root's Guix.
<nckx>Pull root's Guix.
<nckx>apteryx: How did you test?
<nckx>(dmitri is port 5552 only, BTW, no need to waste time elsewhere.)
<nckx>Connection closed by port 56168 [preauth]
<nckx>Connection closed by port 46970 [preauth]
<nckx>I'm guessing that's someone here 🙂
<roptat>not me :)
<nckx> &
<nckx>Guess not.
<nckx>Thank you, lurker person.
<civodul>roptat: what IP do you see?
<civodul>lemme try
<nckx>curl → (I'm currently at home).
<civodul>this IP works for me
<roptat>mh... are you connecting on an IPv6?
<civodul>oh wait, "ssh -4 -p 5552" actually works
<civodul>so it's a v6 issue?
<roptat>dig says 2a02:a03f:4a49:f300:62cd:d8a0:8cf4:7ca2
<desmes>nckx: I see. But If 'guix pull' updates the distribution only for the user who ran it, if I never run 'sudo guix pull', the root user will never have an updated distribution, will he? His guix tools and packages source code (for guix package) will be outdated.
*nckx facepalms. G*d d*mn ISP.
<nckx>I'll remove the AAAA records.
<roptat>desmes, according to nckx, sudo guix should use the user's guix, not root's guix, so it's fine
<nckx>(Which are correct but hey IPv6 is brand new and hard to get right /s)
<roptat>"brand new"
<bricewge>Hello Guix!
<nckx>roptat: I know, it's depressing.
<roptat>it's almost as old as I am ^^'
<roptat>actually, older than me
<nckx>OK, now I feel old.
<desmes>Okok, I think I understand it now. So it doesn't really matter if the root's distribution is updated or not.
<bricewge>I can't manage to build the guix repo, `make` keep screaming `format specifications in 'msgstr[0]' are not a subset of those in 'msgid_plural'`.
<bricewge>It's the same issue as, anyone have an idea on how to fix it?
<nckx>desmes: Root is ‘just another user’ on Guix.
<nckx>So it only matter if ‘root’ does things on their own. Which, on most single-user systems, isn't the case: you admin using sudo, not by logging in as root. I'm being vague because everybody does things slightly differently (roptat not using sudo‽ burn the wizard!).
<grumbel>bricewge: 'make -k' and ignore the error
<desmes>nckx: That's what I mean. Since "guix pull" only affects the user who runs it, if we never run it with the root user, the root user will never have an updated distribution.
<nckx>civodul: 5-minute TTL should be over soon; could you try again without -4?
<nckx>desmes: Right!
<roptat>desmes, sudo guix system reconfigure should use the user's distribution, not root's, and then root's distribution is the one installed with the operating system (so it's also updated, but a different pace)
<nckx>Root will not even have their own profile, they'll only ‘see’ the packages installed system-wide from your system.scm. Which are kept up-to-date when you reconfigure. As a regular user 😛 OK, I can understand how this can be confusing.
<bricewge>grumbel: Thanks, it continue building now. Any idea on the source of the issue?
<roptat>now I'm not sure it's actually the case, I'm very confused by sudo
<nckx>Disconnected from user ludo port 57524
<desmes>roptat: How come it also will be updated (at a different pace)? If he never runs guix pull?
<roptat>bricewge, one of the files has a plural form that gettext think is incorrect (its singular has something like ~*1 where the plural has ~a)
<roptat>desmes, root will then use the system's guix which is updated from time to time in the distribution
<desmes>roptat: What do you mean 'guix' and 'distribution' I thought these tho words meant the same?
<roptat>but you shouldn't really care about that if you don't run as the root user
<civodul>nckx: they should be back to use now, i hardcoded the IP in the ssh tunnel
<desmes>roptat: I see, but I'm just trying to understand how this works
<nckx>civodul: That will break. These are dynamic IPs.
<roptat>so the "guix" binary can come from different sources: your ~/.config/guix/current/bin/guix or your system's guix
<desmes>'guix' as a program, as the set of tools for administration, am I right?
<nckx>civodul: Load average: 9.96 3.22 1.14 \o/
<desmes>roptat: i see
<roptat>your guix from .config is a bit special, it comes from "guix pull" which updates it independently from your current guix version
<roptat>the default guix in the system however comes from the guix package that is declared in a recipe in your current guix installation
<desmes>roptat: declared in /etc/config.scm?
<roptat>that /etc/config.scm declares an operating system that is built by your current guix, so it uses packages in that guix version
<roptat>if you're not careful and use the system's guix, you'll be using the guix recipe from the system's guix, which is necessarily older than the current system guix (we can't guess git commit hash in advance ;)), so you'll downgrade your system
<roptat>that's why guix pull is so special and separate from your current guix: it's to prevent a downgrade
<roptat>now if you use "sudo guix system reconfigure", you should be using the user's guix installation in .config, so you shouldn't have any issues
<roptat>but again, sudo is confusing
<roptat>so I'm not completely sure
<roptat>I think "sudo guix pull" will update your user's guix installation in .config, but it'll be owned by root
<desmes>roptat: To be honest I'm still a bit confused. How come the system's config file declares (?) a 'guix' binary?
<roptat>it's implicit (or maybe in %base-packages?)
<desmes>roptat: Aaah, I can see that.
<roptat>you system config is a declaration (a description of your future system)
<roptat>in which the guix package is declared to be installed
<desmes>roptat: Damn it all makes more sense now
<roptat>nice :)
<desmes>roptat: Thanks a lot for the clarification!
<civodul>nckx: re dynamic IPs, could you thus tell me once you've remove the IPv6 address your DNS entries (is that correct?), at which point i'll restart the tunnel?
<civodul>speaking of which, has any tried used autossh?
<htgoebel>I just did "guix pull" (commit 4ee948e) and this started building guile-2.2.4 - which is on core-updates.
<htgoebel>What is going wrong here?
<civodul>i have a lame bash loop for restart the tunnels, but i'm sure we could do better
<nckx>civodul: I already have & the TTL was only 5 minutes.
<nckx>If you're still seeing AAAA entries your resolver is misbehaving.
<civodul>maybe i didn't wait long enough
<civodul>htgoebel: depends on your pull target, but see
<civodul>it should build 2.2.4 only if you target master from before ~2 days ago
<civodul>gentlefolks! anyone here objects to merging core-updates today?
<civodul>like *this* today
<nckx>civodul: None at all from me.
<htgoebel>civodul: I did not specify any target, plain "guix pull" without any options. This pulled commit 4ee948e.
<htgoebel>Anyway: guile-2.2.4 should be available at, shouldn't it?
<htgoebel>But it this is a temporary issue, I'll just ignore it and wait for finishing.
<nckx>I've been running it for a few days and it's been almost disappointingly uneventful ;-)
<civodul>htgoebel: it's being built (i pushed the commit in question an hour ago so...)
<civodul>but yeah, guile 2.2.4 will have substitutes available soonish
<civodul>nckx: i've been running it for a week or two, so i definitely sympathize!
<civodul>the figures in "guix weather" still aren't as good as i'd like
<civodul>but "-c" shows there's a long tail, meaning mostly leaves are unbuilt
<civodul>so not great, but nothing worrying
<jonsger>civodul: mbakke raised something about ssh on the ML
<bricewge>roptat: Thanks but I can't find wich file to tweak unfortunatly.
<g_bor>actually the problem with ssh seems that it is very difficult to find out what's going wrong.
<mbakke>civodul: also, mariadb consistently fails on armhf, which is strange, because it used to work before the last full-rebuild
<g_bor>I had the same issue with it several times already, and it does not actually depend only on the config.
<nckx>bricewge: This was supposed to be fixed by (which has a patch removing ~* entirely).
<g_bor>I believe that there are some race conditions on start, which indicates that there might be missing service dependencies...
<htgoebel>civodul: thanks for the info
<g_bor>Once it turned out to be the random seeding slow, and once it was because some filesystems coming up slow...
<nckx>g_bor: If mashing the keyboard makes it succeed it's pretty clear. Which isn't to say there aren't multiple unrelated ssh-daemon bugs.
<roptat>bricewge, it might have been fixed already
<roptat>bricewge, maybe the po file was not updated
<nckx>bricewge: Have you (git) pulled very recently (~1 day)?
<mbakke>g_bor: have you had entropy starvation on 'master' too?
<g_bor>mbakke's comment is about headless systems, so mashing the keyboard is not really an option there either
<g_bor>mbakke: I had earlier, but that was a few month ago.
*nckx actually has a headless system with a keyboard, just no screen.
<roptat>bricewge, maybe try "make update-po"?
<g_bor>I did not recurred since then, but I change my machine.
<bricewge>nckx: Yes I'm in sync with origin/master (on 4ee948e39be1c783022242735bdb6f7f7da3aebd).
<civodul>mbakke, nckx: just replied to the ssh/getentropy issue :)
<civodul>i'm retrying the mariadb build on armhf again, just in case
<bricewge>roptat: I don't have an update-po target. Maybe my setup is missing something then...
<roptat>bricewge, you're right, "make -C po/guix update-po" should work better
<nckx>I use urandom-seed-service-type too, but also haveged. I'll remove the latter from my services for a while and see if I happen to hit starvation.
<Chiliparrot>nckx the reconfigure finished while I was away; I had to repeat it with sudo, but then it also finished with success ;-)
<nckx>Chiliparrot: Grrreat!
<Chiliparrot>(I hope that qemu is slowing everything down, though ;-)
<civodul>nckx: "havaged"?
<nckx>Oh, ‘haveged’ then, sorry.
<civodul>hmm i still don't get it
<bricewge>roptat: Thanks a lot, it seems to build fine now. I'll report that to #37491.
<civodul>bandali: bah, sounds like we'll have a hard time upgrading
<roptat>bricewge, actually, there's no issue anymore
<roptat>en@quot.po is generated, you probably had one from another commit which had the issue
<roptat>update-po updated the file
<bricewge>#37491 should probably be closed then.
<nckx>Or if that was a ‘tf is that’ question: it's a little (Guix-packaged) daemon that claims to generate some randomness from CPU jitter. I don't trust it enough to run it on, say, SSH/GPG-key generating machines, but it's nice for systems that have no external entropy source otherwise. It's an alternative to trusting RDRAND.
<nckx>civodul: ☝
<bandali>civodul, yeah :(
<bandali>on the bright side, it may be a good time to ditch it ;)
<bricewge>roptat: What is strange is that the issue appeared on a fresh git clone.
<jonsger>almost 4k commits since 1.0.1 :)
<nckx>bandali: Ditch… Gnome?
<bandali>nckx, yeah
<civodul>nckx: oh ok, i thought it was a verb or something :-)
<roptat>bricewge, ok, then it's a bug
<Chiliparrot>Interesting point, bandali... I've seen systemd-dependency issues before (Funtoo has never used the old init system, and they want to stick with their solution); how big is this problem with shepherd?
<nckx>bandali: Not that I care about Gnome, but I'm going to hide under a strong rock for the week that that's announced ;-)
<nckx>We have a lot of Gnome users.
<bandali>nckx, you and me both ;)
<civodul>nckx: right, we can't really ditch it
<mbakke>civodul: I have been on 'core-updates' for about half a year now, and only occasionally see the problem (and strangely never on systems with FDE) :-)
<bandali>Chiliparrot, ha, i’m not quite sure, as i’m not familiar with the internals of shepherd or gnome
<civodul>mbakke: oh well, so what are we waiting for? :-)
<bandali>programs that make systemd a dependency are *awful*
<bandali>what’s the status of kde and guix?
<civodul>bandali: well, there are engineering arguments for that, even strategic arguments, even, one could say, arguments about the relevance of free software on the desktop
<civodul>i'm playing the devil's advocate
<civodul>but just because i think the big picture is more complex
<bandali>yeah… but i feel like at some point people should take a stand
<civodul>i think we should find a way to reap the relevant parts of systemd
<bricewge>bandali: I'm looking into it at the moment. IT hasn't advanced for 3 month
<civodul>like we already do for elogind, and a bit for localed
<mbakke>civodul: one of my systems get the entropy problem on about 1/3 boots, I have time dig into the problem this weekend
<bricewge>bandali: I'm trying to rebase the work of htgoebel.
<Chiliparrot>btw bandali: Did anyone ever try to run guix with systemd? I'm fine with Xfce, but I don't have the impression that the majority is moving away from systemd
<civodul>mbakke: so do you think we should hold on before merging?
<civodul>(i'd rather not)
*civodul goes afk for a bit
<bandali>bricewge, cool, thanks for the link/update, and for your work!
<joshuaBPMan>Hey guix, guix package -i guile-dbi is failing. It is saying that my profile contains conflicting entries for guile....I guess I'll try a guix gc.
<bricewge>bandali: Not my work, it 's htgoebel's.
<bandali>Chiliparrot, hmm, not that i know of? i, too, would be fine with Xfce and even better, a tiling wm like i3 or exwm, but i understand that it’s not everyone’s preference
<bandali>bricewge, yes, but you’re also doing work built on htgoebel’s :)
<roptat>jonsger, guix gc won't help, try to update guile instead
<roptat>(or the whole profile)
<bricewge>roptat: I have rebuilt guix a second time from scratch without `update-po`. The "issue" has vanished, maybe it was from a cached file.
<roptat>ah I meant joshuaBPMan, but they disconnected...
<efraim>I get an odd issue on core-updates that pre-inst-env thinks its on master
<efraim>Using git worktrees
***chrislck_ is now known as chrislck
<Minall>Hello guix!
<Minall>Where can I find system messages?
<bavier>Minall: /var/log/*
<Minall>Thanks bavier, there they are1
<Minall>Using guix pull will update the packages but permanently?
<nckx>Minall: It will update the packages *available* to ‘guix install’ and ‘guix system …’. It's persistent, yes, but not permanent in the sense that you can always ‘update’ to an older commit with ‘guix pull --commit=…’.
<bavier>or even 'guix pull --roll-back'
<nckx>Well TIL.
<bavier>and 'guix pull --switch-generation' :)
<nckx>Sigh. I'm going to have to create a ‘vanilla Guix VM’ soon for helping folks on IRC vs. ‘guix as she is used by nckx’ (git all the things, fork all the stuff)…
<Minall>I mean, If i do a guix pull, and then shutdown, do I have to make another guix pull?, or does it saves even if I don't reconfigure in that session?
<nckx>Minall: Yes, that's what persistent means. Guix wouldn't be very useful if it forgot about all its packages when you reboot.
<apteryx>do we currently validate at reconfigure time that a file system label exists, or other similar checks?
<guixmike>hello all, I have installed the binary installation of guix twice now and have run into a problem. Everytime I try to "guix install glibc-locales", the build process stops at libelf-0.8.13 with hash mismatch
<guixmike>is there a way to force the build?
<bavier>guixmike: I think the recommended solution in the past has been to 'guix pull'
<guixmike>i have tried guix pull, but it just tries to continue the build process and then stops again
<guixmike>with the same mismatch error
<bavier>guixmike: what's your guix version? i.e. 'guix describe'
*bavier is able to 'guix build -S libelf'
<guixmike>guix descibe gives: erro: failed to determine origin. It's version string is 1.0.1
<bavier>seems like maybe the 'guix pull' didn't succeed?
<guixmike>is there a way to make it verbose?
<guixmike>when i run guix pull, i get spurios SIGPOLL
<guixmike>but seems to update
<roptat>if guix pull seems to succed, check you have ~/.config/guix/current/bin first in your $PATH and run "hash guix" (no output)
<guixmike>~/.config/guix/current/bin is in path and "hash guix" gave no output
<nckx>apteryx: No, I don't think so (and I'd oppose anything but a friendly warning — it's not Guix's job to guess what might or might not exist in future).
<nckx>guixmike: Did that fix it?
<guixmike>no, still getting hash mismatch
<nckx>guixmike: What does ‘command -v guix’ say now that you've run ‘hash guix’, and does ‘guix describe’ still return an error?
<guixmike>'command -v guix' gives /root/.config/guix/current/bin/guix
<guixmike>guix describe still gives error
<guixmike>i don;t think this is worth the headache, thanks all for your help
<nckx>I shall never understand such people.
<bavier>a new scheme for us to package :)
<nckx>bavier: Cool!  ‘Once it has been bootstrapped it can self-compile.’ Do you know how the former happens?
*bavier checking it out right now
<bavier>ah, it bootstraps with chez scheme
<nckx>That's good.
<janneke>eh, can chez be bootstrapped, then?
<nckx>Oh, I just meant it's in Guix.
<bavier>chez's bootstrapping is currently via bunch of binaries
<bavier>huh, even provides a "fibers" library based on wingo's
<desmes>How come I can't use Emacs as my WM? I have a very simple configuration, like the one in the documentation: I aalso have EXWM inside Emacs' elpa folder (and this same Emacs config works flawlessly as my WM in Arch Linux).
<desmes>When I log in in the display manager nothing happens, I just have to login again, and again, etc.
<desmes>I guess it's not using my ~/.emacs.d config?
<Minall>What application can I install in order to use Matrix?
<Minall>'Matrix client'
<bavier>Minall: I think the only package we have right now for Matrix is "quaternion"
<Minall>Thanks bavier, I'll install it
<truby>weechat also has matrix support
<truby>not sure if that's pacakged though, I think it's an extra plugin you have to install
<civodul>bavier: looks cool!
<Ollreee>I tried to follow the manual as well as I could, but there's still a known problem with fonts when running Guix on a foreign distro?
<Ollreee>did fc-cache -f which (which fc-cache points to guix as it should)
<Ollreee>did fc-cache -f (which fc-cache points to guix as it should)*
<desmes>How do you install fonts in this distro. Do you just put them in ".local/share/fonts" and then run "fc-cache"?
<nckx>desmes: Yup!
<nckx>(Ollreee: sorry, I don't know.)
<desmes>nckx: Nice :)
<nckx>I use it for some ‘customised’ fonts that don't make sense to package as such in Guix.
<Ollreee>nckx ah thanks anyway. i'll probably email support later
<nckx>‘Email support’ ♥
<g_bor>sirmacik: I've checked my config on the sway machine. The only thing I have in the config.scm is elogind-service and %base-services that relates to sway. Sway is installed in my user profile, and I start it from the command line.
<g_bor[m]>sneek: botsnack!
<g_bor[m]>sneek: later tell sirmacik I've checked my config on the sway machine. The only thing I have in the config.scm is elogind-service and %base-services that relates to sway. Sway is installed in my user profile, and I start it from the command line.
<sneek>Will do.
<vagrantc>g_bor[m]: oooh... care to share your config?
<vagrantc>nckx: did you intentionally not update all the linux-libre variables so that linux-libre-arm* still use 5.2 ?
***jonsger1 is now known as jonsger
<desmes>guix-emacs is the best thing I've seen in a long time.
<kongobongo>Hi guix, can I use guix armhf on a 32bit iMX6?
<vagrantc>kongobongo: it's definitely possible ... i've run it on the novena and the wandboard ... but going to be a bit on the slow side.
<vagrantc>just for package installation, upgrade, etc.
<kongobongo>Thank you vagrantc is armhf equivalent of armv7?
<vagrantc>armhf using armv7 probably plus a few extensions, yeah
<kongobongo>Lovely! Time to put Guix on a SBC. Yey!
<civodul>sooo, have we merged yet?