<lle-bout>apteryx: updating fixes it? or are you still doing it? <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>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 <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 <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 <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>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>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 <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 172.10.1.0/24 via 10.0.0.100 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>either Error: either "to" is duplicate, or "gw" is a garbage. <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. <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. <BlackMug>yes if it can read that, what if it cant? <genr8_>k well i am regarding this as a troll attempt, goodbye <BlackMug>anyway will come later when someone debug this better <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? <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 <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 *!*@cm-84.209.80.117.getinternet.no
***jehelset was kicked by ChanServ (Banned: 'connectivity issues')
<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 <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 ***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>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>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>why do i not have udisks even though i added the service hmm <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>now i remember, shepherd doesn't remove th ezombie processes :/ <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 <brendyyn>i had it working as a pulseaudio replacement in a vm <Frosku>I refuse to use pulse, it caused me too much pain in early days <valerii_leontiev>Hey. I'm using guix with Debian. How to bind guix packages to be visible in gnome app menu? <pkill9>notify-send shows notifications with mako, yet, makoctl list fails to connect ot e bus, strange <pkill9>valerii_leontiev: add your profile's /share directory to XDG_DATA_DIRs <valerii_leontiev><valerii_leontiev "It works in xorg but looks like "> Yep, it's correct. I have double checked <pkill9>i may have encountered that bug actually <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 ***koleesch_ is now known as koleesch
<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 <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? <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 <Noisytoot>What's the difference between base32 and nix-base32? <nckx>Noisytoot: Different character set to reduce the chance of naughty wordings. <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’. <Noisytoot>Which one is used for (sha256 (base32 "..."))? <nckx>Have some hysterical raisins. <valerii_leontiev>Today I've tried to upgrade one of the package and it fails because I should upgrade another <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>but if you aren't willing to fix it up for now, then yea maybe don't use it <pkill9>it's for people who like lisp for sure <nckx>valerii_leontiev: It's for everyone. <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 <pkill9>efforts are made to make it more user-friendly <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. <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 <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. <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>valerii_leontiev: seems like vim-full works for me as well <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>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 <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>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>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. <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>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 <Noisytoot>I only have 7.1 and 7.2 in the Development section <Noisytoot>Invoking guix environment and Invoking guix pack <Noisytoot>* Invoking guix environment:: Setting up development environments. <Noisytoot>* Invoking guix pack:: Creating software bundles. <leoprikler>in Guix, those info files come from /run/current-system/ <leoprikler>so in Debian, you'd have to point your INFOPATH to root's share/info as well <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? <dissoc>when the source is a single file and not an archive should i just delete the unpack phase? <pkill9>you'll probably want to use trivial-build-system <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? ***lle-bout` is now known as lle-bout
<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/intrinsics.rs.html": 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. <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 <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 <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. <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) <louis771>I just get `| 'configure' phasebuilder for `/gnu/store/plgzgmklaslp8dg5mamnda9wr6zch4gz-binutils-mesboot0-2.14.drv' failed with exit code 1` <davidl>nckx: ok, so basically, please ignore my post and what I wrote. <civodul>Noisytoot: /gnu is "reserved for future extensions" :-) <nckx>davidl: I was just about to say things. <nckx>Right, those things I never check. <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 <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>(note that disabling substitutes is very costly) <civodul>the command should have given you the file name of a log file for the failed build <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 <nckx>Noisytoot: Does not compute. <civodul>Noisytoot: glibc-utf8-locales is documented as being "useless" as you write for many cases <nckx>Noisytoot: Because it's a small & somewhat arbitrary selection of locales. <nckx>s/it's a small & somewhat arbitrary selection of locales// <nckx>Noisytoot: Why are you installing glibc-utf8-locales instead of glibc-locales? <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 paste.debian.net or bpa.st <Noisytoot>Is that for bootstrapping (binutils-mesboot0)? *nckx 's mood is going as expected, good thing ‘delete’ is a single keystroke in mu4e. <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. <nckx>Like a Jedi gesture system? *nckx AFK for entertainment purposes. <Noisytoot>What's showManPage in nix/nix-daemon/shared.hh for? <Noisytoot>What's the point of having a function that just aborts? <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. <nckx>Noisytoot: Because the daemon is haunted^WC++ and nobody ever goes there unless they absolutely must? <Noisytoot>What's the difference between nix-daemon.cc and guix-daemon.cc? <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. :-/ <vagrantc>WAT 135998 guix-master 1 Apr 13:23 +0200 qemu.aarch64-linux qemu-2.10.2aarch64-linux raw <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) *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 <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 <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? <lfam>American fuzzy lop, a package <vagrantc>lfam: oh, the qemu-2.10 ... that i just found in CI ... <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. <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>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>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 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) <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. <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 <cbaines>vagrantc, nckx yeah, there's aarch64 hardware available and idle <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>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 ci.guix.gnu.org was bad though, I think substitute availability was roughly comparible to guix.cbaines.net 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 ci.guix.gnu.org 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 <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) <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 *nckx updates knot-resolver, then notices the hash ends in nckx. <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. <Noisytoot>I'm packaging a Node.JS module that's only 33 lines long (including comments) <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? <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 :) <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 <vagrantc>sneek: later tell lfam well, this time grub-efi (and presumably qemu-minimal) successfully built for me on aarch64 <raghavgururajan>In core-updates, librsvg fails to build with "Unbound variable: %outputs". But it used to build fine. <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>there are a couple of applications i'd like to try that use node.js ... but packaging in debian is nightmarish <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 <vagrantc>Noisytoot: rather than leaving it as a FIXME <Noisytoot>vagrantc, I actually copied that part from the package above <vagrantc>ah, guix import doesn't support node.js yet <vagrantc>and ... aarch64 ... /gnu/store/z10yjczzwbhyj4mcb929q0sz7lammrc6-guile-static-3.0.2.drv ... spinning