IRC channel logs


back to list of logs

<lle-bout>apteryx: updating fixes it? or are you still doing it?
<leoprikler>which guix package has tput?
<pkill9>leoprikler: ncurses
<apteryx>lle-bout[m]: I think the issue has been fixed in docker 20.10 but not 19.03:
<apteryx>and last time I tried updating to docker 20.10 I got lost in go modules hell
*apteryx retries docker 19.03.15 with updated containerd and runc to see if the problem remains
<BlackMug>hi there
<BlackMug>im trying to install guix on qubes-VM using manual installation
<BlackMug>reading here , this is not suitable for static-ip method
<BlackMug>as ip or ifconfig doesnt show anything because this need to be defined manually
<BlackMug>in debian i do that with modifying /etc/network/interfaces
<BlackMug>in guix there is no /etc/network path
<genr8_>it should still show the interfaces
<BlackMug>but they IP,Gateway,dns.. need to be set manually
<genr8_>I believe this part is just to get the installation working, so you do it manually first.
<genr8_>the permanent configuration will take place after the system has a filesystem to write to
<BlackMug>ok so what should i do firs t
<genr8_>i dont remember the syntax for ifconfig and ip commands, youll have to get another guide for setting a static IP with those commands . should be too hard.
<BlackMug>i tried to partition using cfdesk it say cant open /dev/sda: No such file or directory
<genr8_>well thats not good
<BlackMug>so im lost with network and partitioning
<genr8_>what about "lsblk" or "blkid" to prove you even have a disk at all attached
<BlackMug>yes working
<BlackMug>desk is attached for sure because im using it over vm
<BlackMug>so how to configure network manually in the installation process and so as partitioning
<BlackMug>im trying to get guix over qubes for testing but i failed doing that because guix doesnt provide offline installation like other normal distros
<genr8_>maybe you should have picked the graphical installer if you dont know what you're doing
<BlackMug>not possible
<BlackMug>im doing in within qubes
<genr8_>its totally possible
<BlackMug>and guix require internet while in the installation process , qubes doesnt provide this option
<genr8_>maybe thats why you have no interfaces
<BlackMug>you need to define your network manually because VMs are on static ip only
<BlackMug>route package not in guix
<genr8_>ok it can be done by "ip r" look at another guide for the route :p
<genr8_>i think just replace "route" with "ip r" might work
<genr8_>ip route add via dev eth0
<genr8_>I agree it probably woulda been helpful to add that stuff to the guix manual but this is universal standard linux stuff
<BlackMug>im running into two issues
<BlackMug>either Error: either "to" is duplicate, or "gw" is a garbage.
<BlackMug>or Error: Nexthop has invalid gateway
<genr8_>yes. see what i said next
<BlackMug>i dont know why not just taking old stable distros way of installation like debian,fedora..etc
<genr8_>there is, you've chosen yourself the wrong thing.
<BlackMug>not sure how is that?
<genr8_>USB/DVD ISO installer of the standalone Guix System on Linux.
<BlackMug>yeah that doesnt work on VM or network need static ip configurations
<BlackMug>guix doesnt work without internet in the installation process
<genr8_>the installer establishes the network.
<genr8_>your suffering is self-induced
<BlackMug>yes if it can read that, what if it cant?
<genr8_>then it asks you to specify
<BlackMug>thats not guix
<BlackMug>this is debian or fedora or ..etc
<genr8_>k well i am regarding this as a troll attempt, goodbye
<BlackMug>already reported
<BlackMug>anyway will come later when someone debug this better
<BlackMug>thanks for your time
<BlackMug>take care, god bless
<apteryx>lle-bout[m]: ah, just bumping the runc seems to have worked. Perhaps combined with your recent update of docker. Nice! I'll spare the go modules fight for another day.
<Bumblehorse>Has anyone else gotten a warning about emacs not finding simple.el because .guix-profile/share/emacs/27.1/lisp doesn't exist?
<jackhill>Bumblehorse: yes, it is an unfortunate consequense of how we communicate to emacs where to find its packages. See
<apteryx>Bumblehorse: long story short: logout then relogin; its caused by versioned entries in EMACSLOADPATH
<jackhill>Bumblehorse: essentially emacs was recently upgraded to 27.2 so the path changed, and the EMACSLOADPATH environment variable needs to be upgraded. Workarounds are log out and back in or source e.g. .guix-profile/etc/profile and launch emacs from that shell
<Bumblehorse>Oh I see I guess this is the first time I have upgraded my packages then closed and relaunched emacs
<apteryx>it only happens when emacs itself is upgraded
<apteryx>to a different version number
<apteryx>so it's not that often
<Bumblehorse>yeah, I caught that. I dont know why I didn't specify but oh well
***koleesch_ is now known as koleesch
<Frosku>What's the idiomatic place to run a command when an X session starts? (i.e. a compositor)
***ChanServ sets mode: +b *!*
***jehelset was kicked by ChanServ (Banned: 'connectivity issues')
<brendyyn>Frosku: which compositor?
<Frosku>brendyyn: picom
<Frosku>(it's a form of compton)
<Frosku>It's in guix, I'm just a noob and don't know how to start it when X starts
<Frosku>I've tried putting it in .xprofile but it doesn't look like that gets sourced when logging in
<Frosku>Using the standard desktop-services (I think it's GDM?) and i3wm
<marusich>Frosku, perhaps ~/.xsession?
<Frosku>Hm, worth a try
<Frosku>Thanks, .xsession worked after a bit of tweaking
<Frosku>Another question: I've installed fish, if I set my user's shell to fish in config.scm and system reconfigure, it starts loading fish shells *but* after reboot that stops working. Any ideas how I can get that to stick?
<Frosku>By 'stops working' to be more precise, I mean I can't log in as the user because the shell isn't found
***apteryx is now known as Guest57995
***apteryx_ is now known as apteryx
<brendyyn>Frosku: mayke add fish as a systemwide package
<Frosku>brendyyn: Did
***sneek_ is now known as sneek
<meo>kernel crash on virtualbox at first boot from either the ISO or the VM image, is this normal?
<meo>it boots fine on windows 10 hyperv
<brendyyn>Frosku: what did you write to specify the shell?
<Frosku>brendyyn: I tried 'fish' and '/usr/bin/env fish'
<Frosku>I hardcoded the one in .guix-profile now and that seems to be working
<brendyyn>hmm ok
<brendyyn>you can also use (file-append fish "/bin/fish")
<link2xt>meo: booting the ISO and installing the system on virtualbox works for me
<link2xt>but it's a virtualbox running on debian, not windows
<pkill9>i believe this could be the source of all my wifi woes:
<pkill9>Apr 3 12:24:35 localhost wpa_supplicant[477]: wlp3s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-67 noise=9999 txrate=144400
<pkill9>Apr 3 12:24:36 localhost wpa_supplicant[477]: wlp3s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-60 noise=9999 txrate=65000
<pkill9>Apr 3 12:24:40 localhost wpa_supplicant[477]: wlp3s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-55 noise=9999 txrate=65000
<pkill9>Apr 3 12:24:49 localhost wpa_supplicant[477]: wlp3s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-72 noise=9999 txrate=65000
<pkill9>Apr 3 12:24:50 localhost wpa_supplicant[477]: wlp3s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-61 noise=9999 txrate=65000
<pkill9>9999 does not look like a healthy noise level, lol
<pkill9>looks like my wifi card is mehj
<pkill9>glad it's not guix
<pkill9>or it's kernel related
<pkill9>gonna try setting power management off
<pkill9>here's an idea of a desktop - it does stuff for you, but tells you how it does it
<pkill9>e.g. it gives you GUI to handle wireless connections, but it tells you the tools it uses, e.g. iwconfig
<pkill9>in the GUI itself
<pkill9>why do i not have udisks even though i added the service hmm
<pkill9>though it did run the daemon
<nckx>Good morning, Guix.
<pkill9>ok i get it, udiskie is a daemon that uses udisks
<pkill9>would it be a bad idea to merge mcron functionality into shepherd?
<pkill9>maybe it would
<pkill9>now i remember, shepherd doesn't remove th ezombie processes :/
<pkill9>the zombie*
<mroh>Good morning nckx and #guix.
<pkill9>is there a way to reload user shepherd config? is eem to remember there is
<pkill9>damnit, the concept of an index has been around sinve forever, I onlyu just realised it's purpose, it's basically like 'apropos'
***keonix[m] is now known as keo[m]
<pkill9>i'm going ot lsowly but surely create a cobbled together desktop 'distribution' (really glorified config and maybe channel for anything not upstreamed) of guix
<Frosku>That sounds like a cool endeavor
<brendyyn>im working on setting up pipewire in guix
<Frosku>I want to try pipewire
<brendyyn>i had it working as a pulseaudio replacement in a vm
<brendyyn>trying to get the alsa layer working
<Frosku>I refuse to use pulse, it caused me too much pain in early days
<Frosku>Just more bloatware
<valerii_leontiev>Hey. I'm using guix with Debian. How to bind guix packages to be visible in gnome app menu?
<valerii_leontiev>Wayland session
<pkill9>notify-send shows notifications with mako, yet, makoctl list fails to connect ot e bus, strange
<valerii_leontiev>It works from terminal so $PATH works
<pkill9>valerii_leontiev: add your profile's /share directory to XDG_DATA_DIRs
<pkill9>and restart gnome
<pkill9>add it in ~/.profile
<valerii_leontiev>Looks like I've added
<valerii_leontiev>Let me check
<valerii_leontiev>Is it correct?
<valerii_leontiev>export XDG_DATA_DIRS=$XDG_DATA_DIRS:$HOME/.guix-profile/share
<valerii_leontiev>It works in xorg but looks like in Wayland it doesn't
<valerii_leontiev>It is in .zshrc
<valerii_leontiev>And in .profile as well
<valerii_leontiev><valerii_leontiev "It works in xorg but looks like "> Yep, it's correct. I have double checked
<pkill9>it should work
<pkill9>i may have encountered that bug actually
<pkill9>but i can't remember
<pkill9>have you restarted gnome?
<pkill9>actually i htink the bug was that it didn't update the list, because it resolves the symlink
<pkill9>so when the profile changes it doesn't look in new store location
<valerii_leontiev>Yep, I've restarted gnome
<valerii_leontiev>Still doesn't work with Wayland
***koleesch_ is now known as koleesch
<valerii_leontiev>And looks like foot terminal package doesn't work
<link2xt>valerii_leontiev: does ~/.guix-profile/etc/profile contain XDG_DATA_DIRS settings?
<link2xt>I use guix on top of debian and didn't have to set it manually
<link2xt>only source the profile
<Noisytoot>How does Guix calculate the hash of a git repository?
<pkill9>i guess hoever `guix hash -xr <repository>` does it
<pkill9>just takes all the files and calculated a hash
<valerii_leontiev>> valerii_leontiev: does ~/.guix-profile/etc/profile contain XDG_DATA_DIRS settings?
<valerii_leontiev>How can I check it?
<valerii_leontiev>Could someone please fix `foot` package?
<valerii_leontiev>It's almost unusable
<brendyyn>open it in a text file and look
<brendyyn>text editer
<valerii_leontiev>Let me check
<nckx>valerii_leontiev: It works fine. If you're having specific problems, please give specific information.
<valerii_leontiev>On top of Debian it's have strange behaviour. Some keys doesn't work, some keys print double
<nckx>Backspace doesn't backspace but that might be intentional <>. Always hard to tell.
<Noisytoot>What's the difference between base32 and nix-base32?
<nckx>Noisytoot: Different character set to reduce the chance of naughty wordings.
<valerii_leontiev>I have XDG_DATA_DIRS in guix profile
<nckx>valerii_leontiev: I can't reproduce what you describe but I don't use Debian. Please file a bug, bug do include enough information to reproduce it. ‘x doesn't work’ just invites ‘yes it does, closing’.
<nckx>s/bug do/but do/
<Noisytoot>Which one is used for (sha256 (base32 "..."))?
<nckx>Have some hysterical raisins.
<Noisytoot>Why isn't there a base64 option?
<brendyyn>because then you'd use it
<Noisytoot>But what's the problem with using it?
<valerii_leontiev>Meh... I'm tired with guix. Too much bugs and no pros.
<valerii_leontiev>Today I've tried to upgrade one of the package and it fails because I should upgrade another
<valerii_leontiev>Package manager is really slow
<Noisytoot>Guix is excellent!
<valerii_leontiev>Even slower than nix
<valerii_leontiev>Which is very slow
<Noisytoot>valerii_leontiev, With other package managers you couldn't upgrade just 1 package
<pkill9>i think it's best to just dip your toes in it
<pkill9>while relying on foreign distro
<valerii_leontiev>I've tried in Debian
<valerii_leontiev>Maybe it's for enthusiasts
<pkill9>but if you aren't willing to fix it up for now, then yea maybe don't use it
<valerii_leontiev>Maybe it's for people who love lisp and emacs
<valerii_leontiev>I dunno
<pkill9>it's for people who like lisp for sure
<brendyyn>its for everybody, its just young still
<Noisytoot>I like lisp and emacs!
<pkill9>i like lisp, i don't love emacs
<nckx>valerii_leontiev: It's for everyone.
<valerii_leontiev>I don't want to fix system. I prefer to use it
<valerii_leontiev><nckx "valerii_leontiev: It's for every"> Absolutely no
<pkill9>the system is still young
<nckx>I'd never used Lisp or emacs before switching from Nix to Guix.
<pkill9>and fairly niche, it requires fixing yourself a bit, but it's not only for people who are willing to do that
<pkill9>it just doesn't have the resources that distros like ubuntu and debian do
<valerii_leontiev>It's for everyone who have enough time to fix it and improve
<pkill9>efforts are made to make it more user-friendly
<valerii_leontiev>Unfortunately I haven't
<pkill9>like the installer
<valerii_leontiev><pkill9 "it just doesn't have the resourc"> Totally understand
<nckx>valerii_leontiev: Also not true. Guix is for you if you think it's for you. Otherwise, it's not 😉 There's no accounting for taste.
<valerii_leontiev><nckx "valerii_leontiev: Also not true."> No x100
<Noisytoot>What's x100?
<valerii_leontiev>It's not only taste choice
<valerii_leontiev>It's stability choice
<valerii_leontiev>I can't even got vim from repo during month
<valerii_leontiev>It's crazy
<valerii_leontiev>Vim was broken
<valerii_leontiev>Vim Carl
<nckx>‘It's for everyone who have enough time to fix it and improve’ is true of all systems. Guix has saved me a lot of time in comparison.
<valerii_leontiev><nckx "‘It's for everyone who have enou"> Debian didn't get any minute if my time except installation and upgrade
<valerii_leontiev>Even testing
<nckx>I'm still stuck maintaining a few Ubuntu systems and the time spent just getting them to work is... suprising, considering the resources poured into it compared to Guix.
<nckx>valerii_leontiev: Hence why it's subjective.
<valerii_leontiev>Yep. But I already send many examples of scenarios when guix got failed
<valerii_leontiev>Is it subjective? No
<valerii_leontiev>Broken vim in repo... It's diagnosis
<rekahsoft>valerii_leontiev: vim was broken?
<valerii_leontiev>Over one month
<rekahsoft>valerii_leontiev: on guix?
<valerii_leontiev>I've tracked it one month
<valerii_leontiev>I also send bug report
<valerii_leontiev><rekahsoft "valerii_leontiev: on guix?"> Yep
<pkill9>is it still broken?
<rekahsoft>valerii_leontiev: What was the commit of the guix channel where you found vim to be broken? I ask because I just ran `guix environment --ad-hoc vim -- vim` which ran vim without a hitch, so its definitely working as expected now.
<rekahsoft>pkill9: It doesn't seem to be
<valerii_leontiev><rekahsoft "valerii_leontiev: What was the c"> It's minimal vim
<valerii_leontiev>Look into vim-full
<rekahsoft>valerii_leontiev: Gotcha, trying that now
<valerii_leontiev>Package which called "vim" is vim without clipboard, python support
<valerii_leontiev>Now it should work
<valerii_leontiev>I got message on my mail
<valerii_leontiev>That it was fixed
<rekahsoft>valerii_leontiev: seems like vim-full works for me as well
<valerii_leontiev><pkill9 "is it still broken?"> Should work
<rekahsoft>valerii_leontiev: what revision of guix (commit) did you notice vim-full being broken?
<rekahsoft>PS: I'm not a vim user, just trying to help out
<rekahsoft>I certainly do not find guix unstable. Using it more and more as my daily driver (sometimes in the context of a foreign distro)
<valerii_leontiev>Looks like it's issue on tracker
<valerii_leontiev>I got this to my mailbox
<valerii_leontiev>I totally understand that guix is young, and it hasn't enough resources. I agreed. But I don't understand how it can be used for daily driver
<raghavgururajan>Hello Guix!
<Noisytoot>Hello raghavgururajan
<Noisytoot>What's git-file-name?
<Noisytoot>Does it specify the name and version of the directory in the store?
<rekahsoft>valerii_leontiev: a personal decision at the end of the day. I make it work. You're mileage may vary :)
<nckx>Hi raghavgururajan.
<nckx>Noisytoot: Kind of. (file-name ...) is what does, and (git-file-name ...) is a helper to easily generate a name that fits our conventions. It just string-appends behind the scenes.
<Noisytoot>I've found the source code, it just does: (string-append name "-" version "-checkout")
<nckx>Guix has been my only OS for 6 years. Its main drawback is how lazy and impatient with other distributions it's made me. Now I dread installing Debian from scratch.
<nckx>Noisytoot: It's not even git-specific.
<Noisytoot>What is the " " thing (printed as "^L" in emacs) after git-file-name in guix/git-download.scm?
<nckx>‘Oh well’.
<nckx>Noisytoot: A page feed (= ‘new page’).
<nckx>Used to separate logically, er, separate sections of the same file. It's an old-school (lispy? emacsy? I don't know) thing to do for sure.
<Noisytoot>How can it be inserted in Emacs?
<nckx>Noisytoot: C-q means ‘insert the next character literally’, so C-q C-l.
<Noisytoot>There's C-x [ and C-x ] to go the the next/previous page
<Noisytoot>What's guix git authenticate?
<Noisytoot>There doesn't seem to be anything in the manual about guix git
<nckx>7.4 Invoking 'guix git authenticate'
<Noisytoot>I didn't find it in the Emacs Info index for Guix
<Noisytoot>All of the other Invoking 'guix <something>' entries were there
<leoprikler>I see it in C-h I m Guix RET
<Noisytoot>I only have 7.1 and 7.2 in the Development section
<Noisytoot>Invoking guix environment and Invoking guix pack
<Noisytoot>leoprikler: Did you mean C-h i m Guix RET
<Noisytoot>Because C-h I is Describe input method
<leoprikler>right, yeah
<Noisytoot>I only have:
<Noisytoot>* Invoking guix environment:: Setting up development environments.
<Noisytoot>* Invoking guix pack:: Creating software bundles.
<Noisytoot>in the Development section
<Noisytoot>Maybe it's in a separate package
<leoprikler>It's part of the guix package.
<leoprikler>Are you running a foreign distro perhaps?
<leoprikler>that's probably it then
<leoprikler>in Guix, those info files come from /run/current-system/
<Noisytoot>How can I install the full manual?
<leoprikler>so in Debian, you'd have to point your INFOPATH to root's share/info as well
<leoprikler>[because root has Guix installed, I assume]
<Noisytoot>Where's that?
<Noisytoot>Is it in /root?
<raghavgururajan>lle-bout: Does rust-1.49 build for you?
<Noisytoot>Most users can't access /root
<leoprikler>IIUC you should be able to expose root's info, but don't ask me how.
<leoprikler>Also first try to verify my claim as root before doing anything stupid (i.e. try searching for guix' info files as root)
<rmra>what is the best way to find modules?
<PotentialUser-28>Hi all. Could anyone kindly shed some light on the following. I have an old guix installation on one machine that includes a bunch of other channels in its /etc/guix/channels.scm. I've no upgraded it to the latest and greatest guix and now attempting to install guix on a different machine in a way that it uses the same channels etc. I built a boota
<PotentialUser-28>ble image and managed to boot off of it. I'm going to call it "host environment" now. So that USB host env appears itself to run guix that had those channels and their modules in scope, however when I go through installation sequence and try to reference modules defined in those channels in the final config.scm I get an error saying that code can't
<PotentialUser-28> be found. So it appears that even though host guix was built with those channels and code in scope, any command that I invoke with that guix has no knowledge of that code. I tried switching to another TTY and running `guix pull` having put appropriate /etc/guix/channels.scm in place. It does appear to pull correct code as expected but ends with er
<PotentialUser-28>ror: can't symlink finale result. Typically i would suspect that I've forgotten to run it as `sudo` but booted off USB I am root ... so I've no idea. Derivations were written, so I shouldn't suspect that the final dir is read only, right? I'd love to understand better what's going on here. I'd also love to learn a way to "teach that host env (USB i
<PotentialUser-28>mage)" about code from other channels - it seems to me that since I'm the one creating this image in the first place I should be able to also ensure it has access to modules in all those channels. This is mostly to fascilitate my understanding of what exactly guix is doing when. In the end my task here is to deploy guix on another machine ... I hal
<PotentialUser-28>f expect there is a better way then booting off USB and going through manual installation sequence. Something that involves maybe writing some scheme code. Could someone help me a bit, please
<PotentialUser-28>problem is that other machine is an old rusty server that takes 15-20min to reboot, so I'd rather come up with an intelligent approach
<dissoc>what build system should i use for writing a package that is nothing more than a single bash script?
<pkill9>yea i think so
<dissoc>when the source is a single file and not an archive should i just delete the unpack phase?
<pkill9>dunno where it places them
<pkill9>you'll probably want to use trivial-build-system
<pkill9>to place it in /bin
<dissoc>okay. do you know of an example package that does something similar?
<dissoc>i can probably just search through packages for trivial examples
<dissoc>also, did build logs change in the last few months? when it failed i used to get a log i could view. now I get a message that says "Could not find build log for '/gnu/store/foo.drv'
<pkill9>what are you using to view build log?
<nefix>Hello! I'm building a derivation for libvirt 7.2.0. I'm trying to make it use through `inputs` lvm2 (they call it 'libdevmapper' but when I compile it meson doesn't find the dependency. Does somebody know what am I doing wrong?
<nefix>Thanks! :D
***lle-bout` is now known as lle-bout
<raghavgururajan>lle-bout: o/
<raghavgururajan>error: couldn't generate documentation: No space left on device (os error 28)
<raghavgururajan>error: "/tmp/guix-build-rust-1.49.0.drv-0/rustc-1.49.0-src/build/x86_64-unknown-linux-gnu/stage2-std/x86_64-unknown-linux-gnu/doc/src/core/": No space left on device (os error 28)
<mroh>raghavgururajan: try to configure your guix-service-type with (tmpdir "/whereYourStorageIs") so that packages won't build in /tmp which is most likely a ramdisk basically.
<raghavgururajan>mroh: I am offloading the builds.
<cybersyn>hey guix, sorry if this is cheesing it up a bit, but I just want to thank all of you who have put so much work into this project and who make it happen every day. I discovered guix at a time when I was starting to transition to design after burning out from programming for a living for a decade, but the guix intervention has made me rediscover my love for computing. given recent events when some in commercial software seized the
<cybersyn>opportunity to banish or phase out GPL software from their ecosystem, I just feel like saying the work you all are doing is important, and that GNU is the only software liscensing movement that is genuinely *good*, even if with its issues
<raghavgururajan>lle-bout: Running gc on VM
<raghavgururajan>cybersyn: Welcome to Guix! :)
<raghavgururajan>> guix intervention has made me rediscover my love for computing
<raghavgururajan>cybersyn: Well put. I'll +1 to that.
<bonz060>If I want to have xdg-open inside a guix container, what package has it? In the sense of what do I need to provide to =--ad-hoc= to have that command?
<cybersyn>raghavgurajan: thanks! i've been here since november, but I haven't had many questions because its really well documented and the rolling log of this IRC has the answer to all questions i've had so far. but every now and then i post some spontaneous enthusiastic excitement, like now
<mroh>bonz060: xdg-utils
<Noisytoot>Does running guix install from a guix environment add the package to your profile, or to the environment?
<moorg>like cybersyn, just wanted to say hello too!
<moorg>have only recently been devouring the docs, source repos and video talks, but am happy something like guix exists
<civodul>hey moorg, thanks for saying hi and for the kind words :-)
<moorg>civodul: saw a couple of your talks, very interesting!
<moorg>even dusted off my geiser config
<Noisytoot>There seems to be a in infinite symlinked directory loop in /var/guix/profiles/per-user/root/current-guix/current-guix/current-guix/current-guix/current-guix …
<nckx>cybersyn: That warms the innards to hear. Thanks! And thanks, too, moorg.
<Noisytoot>but only for root
<davidl>so Im trying to substitute some version = 1.2.3 and regex = 1.2.3 in Cargo.toml and Cargo.toml.orig but I fail horribly.
<nckx>Noisytoot: Your profile.
<nckx>davidl: Could you paste teh codez?
<Noisytoot>leoprikler: /root/.guix-profile doesn't exist
*nckx reluctantly opens their mailbox for the day.
<Noisytoot>What's the point of having to store in /gnu/store rather than just /gnu?
<Noisytoot>As there are no other subdirectories of /gnu
<louis771>how do I find out why guix won't compile a specific package (guix noob here)
<Noisytoot>Nix also has /nix/var, but Guix doesn't
<louis771>I just get `| 'configure' phasebuilder for `/gnu/store/plgzgmklaslp8dg5mamnda9wr6zch4gz-binutils-mesboot0-2.14.drv' failed with exit code 1`
<Noisytoot>Guix has /var/guix
<davidl>nckx: ok, so basically, please ignore my post and what I wrote.
<civodul>Noisytoot: /gnu is "reserved for future extensions" :-)
<Noisytoot>louis771, How did you compile it?
<nckx>davidl: I was just about to say things.
<nckx>I will not.
<davidl>nckx: you got pm's from me btw.
<nckx>Right, those things I never check.
<nckx>OK, I might.
<louis771>Noisytoot: I just installed Guix and did the initial `guix install glibc-utf8-locales`
<louis771>It compiled for about an hour and then stopped with this message
*davidl afk
<Noisytoot>Why did you disable substitutes?
<civodul>louis771: did you install Guix via the script listed at ?
<civodul>that scripts allows you to enable "substitutes" (pre-built binaries)
<louis771>but I answered the allowe binary downloads with no
<civodul>ah, then it tries to compile everything
<civodul>and apparently it failed
<civodul>(note that disabling substitutes is very costly)
<louis771>costly in terms of long compile times?
<civodul>the command should have given you the file name of a log file for the failed build
<civodul>louis771: yes
<louis771>the only maybe relevant message I get is substitute: guix substitute: warning: ACL for archive imports seems to be uninitialized, substitutes may be unavailable
<civodul>yes, that's because you disabled them
<louis771>can I turn that substitution on afterwards or better reinstall?
<Noisytoot>glibc-utf8-locales is useless, as it doesn't contain en-GB
<civodul>louis771: see
<louis771>great thanks, will try that now
<Noisytoot>Why doesn't glibc-utf8-locales have en_GB?
<nckx>Noisytoot: Does not compute.
<civodul>Noisytoot: glibc-utf8-locales is documented as being "useless" as you write for many cases
<civodul>not just en_GB
<nckx>Noisytoot: Because it's a small & somewhat arbitrary selection of locales.
<civodul>s/somewhat// :-)
<nckx>s/it's a small & somewhat arbitrary selection of locales//
<Noisytoot>Why were those locales selected?
<nckx>Noisytoot: Why are you installing glibc-utf8-locales instead of glibc-locales?
<Noisytoot>I'm not, louis771 is
<Noisytoot>But previously I had glibc-utf8-locales, and got annoying warnings, now I have glibc-locales
<nckx>Noisytoot: To make arbitrary things work, mainly test suites IIRC.
<nckx>It could be renamed glibc-locales-for-tests.
<louis771>nckx: got the same error with glibc-locales
<nckx>I don't know if there are other uses. Apart from ‘it just happens to have the locales I want so yay for me’.
<louis771>it always `binutils-mesboot0-2.14`that is not compiling
<nckx>You didn't paste the error log yet.
<Noisytoot>louis771, You can use or
<Noisytoot>Is that for bootstrapping (binutils-mesboot0)?
*nckx 's mood is going as expected, good thing ‘delete’ is a single keystroke in mu4e.
<Noisytoot>in evolution, delete is the delete key
<nckx>louis771: Could you (b)paste(deb) the (decompressed ;-) contents of /var/log/guix/drvs/pl/gzgmklaslp8dg5mamnda9wr6zch4gz-binutils-mesboot0-2.14.drv.bz2 too?
<nckx>But lo, the pinky is weak, and easily tires from machinegunning idiots. D is bound to the index finger. Win.
<Noisytoot>I just move my hand to delete emails
<Noisytoot>(to make reaching delete more convenient)
<nckx>Like a Jedi gesture system?
*nckx AFK for entertainment purposes.
<Noisytoot>louis771, nckx is away
<Noisytoot>* nckx AFK for entertainment purposes.
<Noisytoot>What's showManPage in nix/nix-daemon/shared.hh for?
<Noisytoot>It just consists of:
<Noisytoot> /* This idea is evil. Abort. */
<Noisytoot> abort ();
<Noisytoot>What's the point of having a function that just aborts?
<Noisytoot>Why is showManPage evil?
<nckx>louis771: Thanks. It's strange. That exact derivation built fine on berlin (the main build farm). Race condition? I don't know. You could try rebuilding it with ‘guix build -{M,c}1 /gnu/store/plgzgmklaslp8dg5mamnda9wr6zch4gz-binutils-mesboot0-2.14.drv’ to see.
<vagrantc>i vaguely recall some progress regarding lvm in guix over the last year ... is it possible to use for rootfs w/ /gnu/store yet?
<nckx>Noisytoot: It's purpose is to pop up a man pager when you type ‘foo --help’ instead of printing ‘proper’ help output. Whoever wrote that comment thought it an evil practice.
<Noisytoot>What's the point of having that function at all if it just aborts?
<nckx>The comment isn't in current Nix by the way, so perhaps it was civodul.
<Noisytoot>It's only used in
<nckx>Noisytoot: Because the daemon is haunted^WC++ and nobody ever goes there unless they absolutely must?
<Noisytoot>What's the difference between and
<Noisytoot>Rewrite it in Guile!
<civodul>ah yes, it's me
<civodul>i'll remove it :-)
<civodul>back then the idea was to leave the Nix code untouched as much as possible
<nckx><Rewrite it in Guile> That's a ‘why don't you just...’ for the ages. :-/
<civodul>so we could merge changes back in
<vagrantc>WAT 135998 guix-master 1 Apr 13:23 +0200 qemu.aarch64-linux qemu-2.10.2aarch64-linux raw
<vagrantc>qemu 2.10.x ?
<civodul>vagrantc: where does that come from?
<vagrantc>i was looking into why qemu-minimal fails for aarch64 ...
<vagrantc>notably, april 1st, but ... i don't imagine anyone's pranking the ci system :)
<vagrantc>apparently qemu-minimal fails due to some tests timing out ...
<vagrantc> 85/259 glib:glib+slow / 642026 TIMEOUT 180.60 s
<vagrantc> 86/259 glib:glib+slow / 642026-ec TIMEOUT 180.64 s
<vagrantc>and looking into qemu-minimal because for some reason it's some type of input for grub-efi ... ?
<civodul>vagrantc: you never know, Cuirass 1.0 was announced +/- on April 1st ;-)
<lfam>That is from ((gnu packages debug) qemu-for-american-fuzzy-lop)
<Noisytoot>An american fuzzy lop is a rabbit
*vagrantc assumed too much, perhaps
<nckx>Noisytoot: That is the best kind of correct.
<lfam>I don't think that package should be used by anything except for AFL
<lfam>If it is, that's a bug
<vagrantc>lfam: it's the only qemu that succeeds on aarch64, apparently :/
<lfam>But where is it included in the package graph?
<lfam>That's what I don't understand
<lfam>GRUB depends on qemu-minimal
<vagrantc>does grub run some tests that use qemu?
<lfam>Did you just find this job on CI? Or did it fail due to some command that you ran?
<vagrantc>lfam: it failed while i was trying to build a shiny new Guix System
<vagrantc>lfam: so then i looked at ci to see what the history looked like
<lfam>And, does your system include AFL?
<vagrantc>AFL >
<lfam>American fuzzy lop, a package
<vagrantc>lfam: oh, the qemu-2.10 ... that i just found in CI ...
<Noisytoot>or a rabbit
<lfam>Never mind then. I thought you were saying that qemu-2.10 failed to build on your system
<lfam>QEMU is ostensibly support on ARM. It is disabled on mips64el and i586 (hurd)
<lfam>I guess it's rare that GRUB is used on ARM so we didn't notice before
<vagrantc>with aarch64, i would guess grub-efi is the norm
<nckx>All the overdrives use grub-efi.
<vagrantc>at least for server-grade stuff
<Noisytoot>What's i586?
<lfam>Like I said, it's GNU Hurd
<nckx>Noisytoot: De facto GNU Hurd.
<lfam>Good to know about the bootloaders
<nckx>Although my first CPU was a 586.
<nckx>Which was nice.
<Noisytoot>GNU Hurd isn't a CPU architecture
<lfam>You asked, we answere
<nckx>The best kind of correct continues.
<vagrantc>i guess i should try to build grub-efi and just disable tests for now, just to get the system booted
<lfam>On CI, grub-efi fails to build on aarch64 because glib-static-2.62.6 fails
<vagrantc>alternate strategy i guess would be to just build grub.cfg and not build grub-efi itself...
<lfam>It's going to be rough with glib
<lfam>I mean, without
<lfam>Maybe it's a miscompilation due to emulation. We keep finding those
<vagrantc>and then use grub from debian or something crazy like that
<lfam>I'll retry the build on guaranteed ARM hardware
<vagrantc>lfam: this is definitely on arm hardware too
<lfam>But, you should that QEMU failed to build, right? Not glib?
<vagrantc>lfam: this is one of those boards i mentioned earlier
<lfam>I mean, you said
*vagrantc will try again
<lfam>I asked it to build the grub-efi derivation from that CI page I linked to
<lfam>I'll be able to check the results in several hours
<lfam>It does need to build glib and QEMU 5.2.0 (I assume qemu-minimal, not full QEMU)
<civodul>lfam: i'm taking care of
<civodul>(which went out a bit too early)
<lfam>I have to take a long drive in a minute
<lfam>Hm, it appears that CI lacks a huge number of foundational substitutes for aarch64
<nckx>Guix's alacritty freezes when I do something, but I haven't figured out what something yet.
<lfam>Such as meson
<nckx>And no xkill on Wayland :(
<lfam>Well, I guess this is why we are trying to get new hardware
<cbaines>I don't think we've ever had a hardware problem lfam
<vagrantc>wow, the regular linux-libre eats a lot of disk during build
<vagrantc>cbaines: for aarch64?
<nckx>cbaines: For aarch64?
<cbaines>assuming this page is right everything is idle currently
<Noisytoot>eating disks can be harmful
<cbaines>vagrantc, nckx yeah, there's aarch64 hardware available and idle
<nckx>OK, one.
<cbaines>more hardware could probably build things faster, but I'm pretty sure there's enough available to keep up with master
<nckx>I wonder why, and whose that is.
<vagrantc>it must be idle-o'clock
<vagrantc>i'll also queue up glib, just in case it decides it needs that
<cbaines>(and by "ever", I guess I mean while there've been overdrive machines kicking around, which actually isn't "ever", I guess the last few years?)
<vagrantc>cbaines: if key dependencies aren't built due to emulated-build failures, and don't get rescheduled on native hardware ... that might cause some of the idle
<vagrantc>but definitely, idle workers has been an ongoing issue :/
<nckx>Weren't emulated ARM builds disabled? If not, why not yet.
<cbaines>vagrantc, indeed, I still like having the option of mixing native+QEMU for builds, but that circumstance needs to be handled
<lfam>cbaines: We only have 4 Cortex-A57 cores in the build farm. The rest of it is emulated, and there is a lot of miscompilation
<vagrantc>i think i might be willing to host a few build machines if they only build some subset of packages ... i don't think my bandwidth can handle world-rebuilds
<cbaines>I didn't think the aarch64-linux substitute situation on was bad though, I think substitute availability was roughly comparible to when I checked recently
<lfam>It is interesting that the farm is apparently idle at the moment. Since that "workers" paged appeared, the emulated builders have never been idle, because the emulation is so slow that CI can't keep up
<lfam>Maybe it finally caught up, that would be great
<lfam>vagrantc: Yeah, building the linux-libre sources churns through a few gigabytes of disk space, and it takes at least an hour
<cbaines>Looks like the last revision Cuirass on has processed was pushed at 2021-04-02 21:26:47
<lfam>It's egregiously inefficient
<lfam>I always "pre-build" these tarballs on CI before pushing the update, so that nobody has to build them
<cbaines>which maybe explains why it's idle, as it's about 24 hours behind
<vagrantc>gah, i should remember to use --keep-failed when debugging these things
<lfam>Hm, it does appear to have stalled
<vagrantc>maybe it's waiting for curiass 1.1 ?
<lfam>Well, I have to go
<lfam>Happy hacking!
<cbaines>Maybe it's simply not running, the cuirass service is stopped on berlin
<cbaines>(curiass-web is the bit that does the web interface)
<cbaines>I'll try starting it...
<nckx>Oh. Is there a sad trombone emojo.
<vagrantc>i felt like when i did guix aarch64 just a couple weeks ago, the substitutes were doing a lot better
<cbaines>... and it's back
*nckx updates knot-resolver, then notices the hash ends in nckx.
*vagrantc claps
<nckx>Oh, nkcx.
<nckx>Close enough.
<vagrantc>we totally need to make some vanity hashes
*nckx can't easily tell the difference.
<nckx>There was one that started with ‘1lisp’ that I was sad to update a while back.
<vagrantc>glib built fine for me on aarch64, fwiw
<Noisytoot>I'm packaging a Node.JS module that's only 33 lines long (including comments)
<Noisytoot>Why are Node.JS modules so small?
<nckx>vagrantc: Yes, let's break sha256 just to release 1.2.0 with a hash of ‘guixftw...’. (/me checks %nix-base32-chars... sad.)
<vagrantc>nckx: no, we just have to tweak the tarball until satisfied
<vagrantc>"what's this random file with arbitrary text in it that's not used by anything?"
<nckx>That's disturbingly feasible.
*nckx ‘borrows’ berlin for a day.
<vagrantc>probably someone with mathgician skillz could do it better
<vagrantc>i definitely know people who've used truerng to generate vanity hashes for gpg keys
<Noisytoot>Should npm packages (from npm, not npm itself) go in node-xyz.scm?
<nckx>Noisytoot: Yes, I think so.
<pricly_yellow>Hello, i just wondering why i not can start shepherd as user process before i logged in graphical environment? When i login to my pc with ssh shepherd not run with error No such file or directory: "/run/user/1000/shepherd", but if i login in wm it's work as expected. How i run shepherd as user without wm start?
<Noisytoot>pricly_yellow, Shepherd is an init system
<Noisytoot>I think it should be ran as PID 1
<nckx>You can run a separate user instance.
<nckx>pricly_yellow: /run/user/nnn is created by elogind, so you need to <something somehow> log in non-graphically using that.
<Noisytoot>Do I have to run "guix refresh" if I'm creating a new package, rather than updating an existing one?
<pricly_yellow>nckx: if i run elogind manually it not interrupts my graphical session?
<nckx>Maybe it's as simple as adding an explicit elogind-service.
<nckx>pricly_yellow: I really can't say.
<nckx>For as stodgy as I am, starting my desktop manually has never appealed to me.
<nckx>You can always try and roll back at the GRUB menu :)
<pricly_yellow>Thank you, try to dig in this way
<nckx>I checked my system.scm. It has an explicit (service elogind-service-type (elogind-configuration ...)) service element. So it should not conflict with your desktop (I use sddm+Sway).
***ChanServ sets mode: -o nckx
<Noisytoot>Running "guix lint" on the package that I defined failed
<Noisytoot>(./pre-inst-env guix lint)
<Noisytoot>When I compiled the file, it worked
<vagrantc>sneek: later tell lfam well, this time grub-efi (and presumably qemu-minimal) successfully built for me on aarch64
<vagrantc>sneek: botsnack
<raghavgururajan>In core-updates, librsvg fails to build with "Unbound variable: %outputs". But it used to build fine.
<raghavgururajan>civodul: By any change this is related to your changes in c-u?
<Noisytoot>I've just sent a new patch, could someone apply it?
<smoothdev>Hello, I've heard about guix from people comparing it to nixos (in terms of characteristics of deterministic package handling).
<smoothdev>I'm unclear if it works as something of another running distrib, or if it stands on it's own?
<smoothdev>I intend to run it on arm64 architecture, and unclear of which steps I need to take
<vagrantc>how is node.js packaging in guix?
<vagrantc>there are a couple of applications i'd like to try that use node.js ... but packaging in debian is nightmarish
<Noisytoot>vagrantc, I've just added a new node.js package:
<Noisytoot>It's node-wrappy
<Noisytoot>But it hasn't been applied yet
<vagrantc>Noisytoot: yes, that prompted my question :)
<raghavgururajan>smoothdev: Guix can installed on top any GNU/Linux System or can be installed as stand-alone Guix System.
<Noisytoot>vagrantc, The problem is that node.js packages are quite short, so there are lots of dependencies
<vagrantc>Noisytoot: it should explain why node-tap isn't plausible to package
<Noisytoot>wrappy is 33 lines long
<vagrantc>Noisytoot: rather than leaving it as a FIXME
<Noisytoot>vagrantc, I actually copied that part from the package above
<Noisytoot>As it was failing to build without it
<vagrantc>ah, guix import doesn't support node.js yet
<jackhill>vagrantc, Noisytoot: has some comments about the road ahead for JS stuff
<raghavgururajan>lle-bout: Fixed librsvg build.
<vagrantc>and ... aarch64 ... /gnu/store/z10yjczzwbhyj4mcb929q0sz7lammrc6-guile-static-3.0.2.drv ... spinning