<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? <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. <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
***Guest31236 is now known as Guest312361
***Guest312361 is now known as sturm2
***emyles``` is now known as emyles
<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! <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>do you think you could have the overdrives back on-line? :-) <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>Chiliparrot: (operating-system … (kernel linux-libre-foo) …) ; will pin a kernel version <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: dmitri.tobias.gr:5552 / sergei.tobias.gr:5551 — 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 <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>Oh 🙂 Two of my favourite composers, and they fit in my 6-letter naming scheme. <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... <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) <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>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 <nckx>No Internet at home? That's some special kind of hell. <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). <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. <nckx>jonsger: The machines themselves work perfectly. <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 🙂 <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' <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 <roptat>using sudo -E instead of plain sudo <nckx>desmes: No. sudo -E guix system reconfig. <civodul>nckx, roptat: "ssh dmitri.tobias.gr -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. <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?) <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>apteryx: How did you test? <nckx>(dmitri is port 5552 only, BTW, no need to waste time elsewhere.) <nckx>Connection closed by 62.210.81.154 port 56168 [preauth] <nckx>Connection closed by 137.205.52.16 port 46970 [preauth] <nckx>I'm guessing that's someone here 🙂 <nckx>warwick.ac.uk & firmbright.net. <nckx>Thank you, lurker person. <nckx>curl v4.ip.tobias.gr → 109.131.198.218 (I'm currently at home). <roptat>mh... are you connecting on an IPv6? <civodul>oh wait, "ssh -4 dmitri.tobias.gr -p 5552" actually works <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) <nckx>roptat: I know, it's depressing. <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'`. <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? <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 91.160.117.201 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/ <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>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?) <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 <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. <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>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? <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 ci.guix.gnu.org, 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 <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. <g_bor>I believe that there are some race conditions on start, which indicates that there might be missing service dependencies... <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 ;-) <Chiliparrot>(I hope that qemu is slowing everything down, though ;-) <nckx>Oh, ‘haveged’ then, sorry. <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 <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. <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. <civodul>nckx: oh ok, i thought it was a verb or something :-) <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. <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* <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>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 <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 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. <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 <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 ***chrislck_ is now known as chrislck
<Minall>Where can I find system messages? <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>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 <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 <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>when i run guix pull, i get spurios SIGPOLL <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? <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>i don;t think this is worth the headache, thanks all for your help <nckx>I shall never understand such people. <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>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: https://paste.debian.net/1103759/. 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? <bavier>Minall: I think the only package we have right now for Matrix is "quaternion" <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 <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>(Ollreee: sorry, I don't know.) <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 <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: 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. <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. <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