<brettg>Hey all, some of you may remember me but i'm Brett. I'm a committer for the Guix project, and am coming off of a contributing hiatus I took after my son was born. I have a new set of gpg signing keys, after I put them on savannah what is my next step before I can make commits again? <roptat>there has been some changes lately, so I'm not sure what the concrete steps are exactly <roptat>civodul will know for sure, I think you should send a message to guix-devel <guixy>But when I plug it in, the kernel says non-free firmware was disabled. <guixy>Do I need to setup anything to get it to recognize it? <guixy>I've scoured the linux-libre source, but I can't find where it disables that particular device. <guixy>If linux-libre should be able to run it, this is a linux-libre bug. <guixy>h-node says it should work without nonfree drivers. <guixy>But when I plug it in, the kernel says non-free firmware was disabled. <guixy>Do I need to setup anything to get it to recognize it? <guixy> I've scoured the linux-libre source, including the deblob script, but I can't find where it disables that particular device. <guixy>I confirmed that lsusb -v is identical to what's on h-node. <guixy>The only difference is the serial number <guixy>Or would I be better off asking help-guix? <raghav-gururajan>guixy: To my knowledge, Broadcomm BT devices never work with free software. I know this as I was looking for BTv4 device that works with free software. So there is only one. CSR8510 <guixy>So should I check that it works on PureOS as reported in H-Node and investigate if PureOS has non-free firmware? <raghav-gururajan>guixy: May be, you could try the device you already bought, with Trisquel and Parabola. <guixy>I'll do that. I'll also ask help-guix. Maybe someone has had a similar issue. <guixy>I don't see where the linux-libre deblob script touches BCM20702A0 though... <raghav-gururajan>guixy: It says that the device used "btusb" driver. Which is a free software and part of linux kernel. So they are not going to be deblobbed. <raghav-gururajan>guixy: I suspect that your non-functionality has something to with version of kernel. <guixy>I'll contact linux-libre if it doesn't work on Trisquel or Parabola or Hyperbola <raghav-gururajan>guixy: You do not have to try on both Trisquel and Hyperbola, as they both are LTS distros and uses same LTS kernel version by default. So you can do Trisquel+Parabola or Hyperbola+Parabola. <raghav-gururajan>guixy: Btw, if it doesn't work right away. Try running the command `modprobe btusb` and the re-try. <nilsirl[m]>Hi, I'm new to guix with a light experience with nixos. I'm testing things out using the provided QEMU image and reading part of the documentation. Is there an equivalent to `/etc/nixos/configuration.nix`? Or can you put your system configuration wherever you want? <bdju>I think /etc/config.scm is common, but you can put it elsewhere and name it something else as well <atw>yup, and then when e.g. reconfiguring the system, you specify the location <nilsirl[m]>How can I know what's already running on the QEMU image? This isn't really a problem when you're starting from scratch, but here in this image, if I start with a quite empty <name>.scm (with just a bit of boilerplate), it's gonna screw up everything (from what I understand) <roptat>if you are lucky, you'll find your current configuration in /run/current-system/configuration.scm <roptat>(I don't remember when that was introduced) ***sturm1 is now known as sturm
<raingloom>anyone knows where gvfs is started? i still can't get `gio mount` working and it looks like it's because on an sddm login it's simply not started for some reason. <pkill9>what does this error mean? guix copy: error: implementation cannot deal with > 32-bit integers <raingloom>pkill9: looks like an integer overflow. someone should be using bignums. <atw>guix pulling and I see rustc downloading :| gonna wait for an icecat substitute to be available <malaclyps>raingloom, you probably already know this but sddm doesn't really start anything up if you're using wayland (or at least that's my experience with sway) -- I think it relies heavily on xsession-style scripts to get things going <malaclyps>I ended up sticking some stuff in ~/.pam_environment which has the advantage of working whether you login via sddm or kick things off from the command line <raingloom>malaclyps: damn. i did not. that sucks big time. <raingloom>malaclyps: sure, but i don't want to use GDM. <raingloom>functionality should not be specific to display managers. <malaclyps>raingloom, yeah. I may be wrong, but I think people ended up moving a lot of initialisation into Xsession-land and wayland doesn't really have a obvious equivalent <malaclyps>my biggest struggle with Guix is that it requires quite a bit of environment-variable setting to get going, and I'm never clear on where or what that should be. I'm beginning to understand it better though. <raingloom>malaclyps: could you write up what you learned and the workaround you used? <guixy> I found where the deblobber patched out my bluetooth dongle's firmware. It's a rampatch. <raingloom>tbh i really wish Guix had something as good as the Arch wiki <malaclyps>i do think it might be better in the GNOME setup, because sway+sddm+zsh is waay off the beaten track even for Guix <malaclyps>raingloom, well i follow you on Mastodon so I think we are in the same tiny ideological cluster. Last night I was going huh! I have not heard of wio before that is tempting <malaclyps>raingloom, yeah but not sure $UID is available -- pam_env is weird <ajgrf[m]>GHC has been compiling on aarch64 for a few hours now without errors. With any luck it may actually work this time. <raingloom>malaclyps: sadly wio seems to be very broken. i used it successfully on Arch, but that was a long time ago, so it might be a regression in wio and not a Guix issue. <malaclyps>raingloom, i enjoyed exploring your guix channel tho -- I think we need to work out good ways to share such things (and as you say, Arch-like tips) <raingloom>anyways, this init stuff really should be cleaned up. i'll open a proper bug report. <raingloom>malaclyps: thanks ^u^ it's nice to know it's useful to at least a few people. i should really clean it up tho and separate the dubiously open stuff. <malaclyps>i would like to explore some form of documentation that's not just wiki-and-everything-goes-and-is-never-updated-correctly: everything-is-in-one-texinfo-manual has its definite advantages but as the community grows things need to be a bit more .. discoverable? editable? don't know <malaclyps>you remind me that very early on i had a theory about how to fix some of the challenges with zsh, and I think the solution was correct, but I wasn't confident enough to go forward with it (basically have /etc/zprofile source /etc/profile ) but now i think it's the right way <raingloom>malaclyps: that could be useful too. i should also package the GRML config. <nixfreak>how to do I install nim:nimble package manager <LarryTheCow>Hi everyone. I'm still reading the Guix manual (chapter 6.2) but I jumped ahead and packaged a program. Everything is working fine, but I read that it's better to use git-download over download when dealing with auto-generated tarballs. My quesion is, how do I get the hash of a git repo? <dissoc>guix download works too but probably inferior method <dissoc>guix hash is definitely the way to go. im still pretty new so dont listen to me <terpri>"guix hash -rx ." to be precise, inside the repo (or with the repo path instead of '.', i guess) <LarryTheCow>dissoc: lol it's okay. I think guix download would be good if you want to package the latest commit. Since I'm doing a specific checkout, hash seems more suitable. <LarryTheCow>terpri: Yeah I wasn't familiar with -r. I come from nix, so I'm used to the binary computing the hash of the entire directory <terpri>i don't think guix download will work with just the github repo's url. but you could use it on a release tarball url, for example <dissoc>it worked for me. i just randomly decided to try it one day and just rolled with it lol <dissoc>but to be clear i dont know what im doing <terpri>dissoc, really? 'guix download' clones the git repo and hashes the contents? <dissoc>honestly i just push buttons on the keyboard and things finally end up working <dissoc>then you're right. im just an idiot <terpri>which is only useful if you're packaging a webpage ;) <dissoc>i could've sworn it work. however im also fueled by caffeine and alcohol <terpri>i mix up 'guix download' vs 'guix hash' too, would be cool if 'download' could automagically detect VCS repos <dissoc>so in summary dont listen to anything i say <dissoc>on the bright side i was able to make a cassandra package and service <terpri>the nice thing about guix/nix is that you *can* just mash buttons while packaging until things work, without breaking the system <dissoc>i just wish i would've read through utils first. i implemented a really bad wrap-program of my own ***apteryx is now known as Guest55957
***apteryx_ is now known as apteryx
<LarryTheCow>I second that. I used to be a man-reader until I discovered how Emacs docs are structured <Leon>I need some help if anyone's here? <Leon>Do you know how I can fix this? <terpri>Leon, guix pull --debug=M --verbosity=N (M is 0-5, N is 0-2, higher means more info for both) will produce more verbose output <terpri>maybe --debug=4 --verbosity=2, and dial back the --debug number if it's too verbose <Leon>I get the exact same result even with --debug=5 <terpri>the commit is definitely in the guix repo (35691bf5dc69e4d482b31fab63e3bd73ffece755, janneke added a gdb-minimal pkg) <Leon>Well, by the way, my computer often freezes and restarts when I try "guix pull", and that can break things. <LarryTheCow>Just out of curiosity, what's the output of `df -h` and `free -h`? It might be due to lack of resources <Leon>That's what happened last night. So I left my computer off and now I'm awake again I wanted to address me issues <terpri>also, are these guix system/guixsd, or on top of a foreign distro? <Leon>My distribution is Debian Buster, and I might have originally installed it in French, but that's for friends who might use my computer, I use it in English <terpri>Leon, on a foreign distro, you can try "sudo systemctl restart guix-daemon.service" to restart guix-daemon <Leon>OK, I'll restart the daemon <terpri>(or "sudo herd restart guix-daemon" on guix system, iirc) <Leon>Wait, do you mean to say that the GUIX system uses The Hurd kernel? <terpri>Leon, no, herd is from "shepherd", an init system like systemd <Leon>So, about my first issue: restarting the daemon didn't change anything. <terpri>(which descends from the hurd's dmd ("Daemon-Managing Daemon?"), and some people are working on hurd support for guix, but that's another story :)) <terpri>hm, and maxing the debug/verbosity settings didn't add extra output? <Leon>The systemctl status tells me everything is fine with the daemon. <terpri>Leon, well, you could bypass the git cloning by using channels to check that it's not a network/git problem, by using channels (package collections; guix has a "guix" channel defined by default, which you can override) <terpri>then, put in ~/.config/guix/channels.scm: (list (channel (name 'guix) (url (string-append "file://" (getenv "HOME") "/src/guix")) (branch "master"))) <terpri>so that the guix channel uses your git checkout instead of cloning the git repo when you pull <terpri>(adjust the path after "file://" if you didn't clone to ~/src/guix, e.g. "/guix" instead of "/src/guix" if you just cloned it in $HOME) <terpri>guix repo is ~300MB, btw, so not too big <Leon>Well, mine is 196M, so I don't know. OK, I'm on the things you asked me to do <mbakke>janneke: FYI, commit 76129cd3edb1eb62778344de0b1b44365f82ee06 caused 1761 rebuilds, I adjusted the fix to not cause any rebuilds in 361541d4a51b343694f9f14f150d3c6612490687 <terpri>mine has extra branches, etc., so that makes sense <terpri>Leon, then try guix pull; it will show you an authentication warning (bc not pulling from official repo), warn that you're using a "mirror" of the repo, etc., that's to be expected <terpri>also you can try "guix show 35691bf5dc69e4d482b31fab63e3bd73ffece755" inside of the checkout, just to make sure that commit is present <terpri>(though i can't imagine why it wouldn't be) <Leon>OK, now the guix pull says that he can't find a repo at 'file:///home/leon/src/guix'. I'm going to paste the result of the git clone command <Leon>guix show: error: 35691bf5dc69e4d482b31fab63e3bd73ffece755: package not found <Leon>What do you know, we're getting there ^^ <Leon>Thje commit seems to be there <terpri>Leon, "/src/guix/guix" in the channels.scm then (i was suggesting to put the checkout directly in ~/src, location doesn't matter though) <Leon>Yes yes yes! You are right, I'll do the modification <terpri>as ~/src/guix/guix should be the checkout dir <terpri>then you can run guix pull, and hopefully it will work or else you may get a more interesting error :) <Leon>OK? so far the guix pull doesn't give me any errors like before, let's wait some more <Leon>When you said this: > put in ~/.config/guix/channels.scm: (list (channel (name 'guix) (url (string-append "file://" (getenv "HOME") "/src/guix")) (branch "master"))) <Leon>I noticed the guix channel name didn't have a closing ' <Leon>Was I right or wrong in doing that? <Leon>OK? I put it back like you said <terpri>the single quote means it's a Scheme symbol, rather than a variable name etc. (not string syntax) <terpri>or to elaborate slightly, the single-quote prefix in scheme means the next expression will be treated as data rather than code <Leon>Well, now I have other errors I think are related to the fact that my computer froze and crashedd during the guix pull last night. I sent an email about this, and we found the solution. I'm going to tend to it. <terpri>Leon, you might want to check /gnu/store with "guix gc --verify=contents", if you suspect there might be data corruption from the crash <Leon>OK? I'll run the command you just said and see <terpri>and "--verify=repair" will redownload files if corruption is detected <Leon>I'm having lots of output with the verify command. Like this: <terpri>(there are other places where data could be corrupted too, like databases and other files stored under /var/guix, but checking the store is the easiest place to start) <Leon>path `/gnu/store/cv3siakkyhlzjwnlh6ki943xajpfclz4-texlive-hyphen-friulan-51265-checkout.drv' was modified! expected hash `5d655832c1cb2f2bdec661f1f369b8e21ca2db183d4004e517aadc8ce4dc8bca', got `77ac62e2629d8e45f624589c0c8bf99e24b3a722349bf1e79bc18600853https://paste.debian.net/1154063/ <Leon>So hould I do the repair now? <Leon>Can I do this then? > sudo guix gc --verify=repair <terpri>which will just rebuild/redownload the corrupted files <terpri>not exactly reassuring ;) sudo guix gc --verify=check,repair maybe? <Leon>guix gc: error: check: invalid '--verify' option <terpri>sudo guix gc --verify=contents,repair <Leon>OK, lots of output again. Let's wait for it to finish <Leon>Wow, this little command is awesome, seems like it's repairing everything broken. <terpri>note that repair is not an atomic operation, so try not to let your computer crash while it's working ;) <terpri>though i doubt it would make things worse if the files are already corrupt <Leon>OK. Well, I never did it on purpose. ^^' But it has happened several times that I only had a guix pull running in a terminal and my system froze for 1 minute, mouse, keyboard, clock, everything, and then rebooted by it self. That's what happened last night.. <Leon>I tried guix pull again and got this: build of /gnu/store/kxdbkik0dxlw4q2jwvmffxw4w200dj56-module-import-compiled.drv failed <Leon>Yes, I think it is. But my computer is 5 years old… <terpri>"hm" @ the build failure, i'm not sure what it means <Leon>On the email conversations I had about the first time that freezing and violent rebooting happened, this kind of thing solved the issue: <Leon>guix gc -D /gnu/store/m5djg8zwgl7nh0rm1av4nnlbwgwi0fwg-guix-daemon-1.1.0-4.bdc801e.drv <janneke>mbakke: thanks for fixing my gdb ooops :-( <terpri>yeah, should be fine more or less, there are options you can change to limit resource usage ("Common Build Options" in the manual) <terpri>(e.g. sometimes i have to limit the number of cores/jobs with a 32-core cpu) <Leon>Wow! 32? That's awesome! <Leon>O, my command didn't change anything. Do you want a paste of the whole output of my guix pull? <terpri>Leon, you could look at /var/log/guix/drvs/kx/dbkik0dxlw4q2jwvmffxw4w200dj56-module-import-compiled.drv.bz2 and see if it looks "interesting" <terpri>i wonder if it was a failed download since the paste mentioned substitutes, but also mentioned building the derivation (.drv) <terpri>haha, that would be an unusual variable name indeed <terpri>maybe some file got filled (or half-filled) with null bytes <Leon>I don't know what to do now. <mbakke>janneke: np, as a bonus I made gdb 9.2 the default on 'staging', so you can use that branch if you need to build anything that depends on GDB :-) <mbakke>I wonder we should change packages to use 'gdb-minimal' instead of the "full" gdb <terpri>Leon, "guix gc --references /gnu/store/kxdbkik0dxlw4q2jwvmffxw4w200dj56-module-import-compiled.drv" and "guix gc --referers /gnu/store/kxdbkik0dxlw4q2jwvmffxw4w200dj56-module-import-compiled.drv" <janneke>mbakke: i prolly already "decided" that nothing could really depend on gdb and ran guix refresh --list-dependent gdb; yeah only itself <janneke>gdb@9.1 shows something else, i now see... <janneke>and there's also a comment in the gdb package <terpri>...might be interesting, as it will show what packages/derivations are related to that .drv file <janneke>mbakke: similarly, i was wondering whether to include "guile" in gdb-minimal <mbakke>janneke: easy mistake to do, there are a few other 'guix refresh' pitfalls <janneke>i needed a version that would coss build and strictly without python anyways, for the hurd, of course <mbakke>janneke: adding 'guile' seems sensible <Leon>referers is an unrecognized option <mbakke>janneke: does python not work on the Hurd? <janneke>it's not "minimal", but for us...we always have guile anyway <terpri>Leon, also "sudo guix build --repair=/gnu/store/kxdbkik0dxlw4q2jwvmffxw4w200dj56-module-import-compiled.drv" will try to fix just that file, but i'd expect it to fail again <terpri>Leon, sorry, "--referrers" (HTTP/1.x headers ruined my ability to spell that word ;)) <janneke>python-boot0 and python-minimal do; i postponed looking into stuff like python until we have our hurd build node VMs up <Leon>Ah, oui, voilà. I wasn't sure how to write it corrrectly <Leon>The 3rd command "--repair" is an invalid argument <janneke>iow, debian/hurd has python3, so one way or another we'll get it to work <Leon>the referrers command gave this: /gnu/store/xx46rn64fl4s2b0rd52d9vr7qwc2pv7l-compute-guix-derivation.drv <janneke>"<mbakke> I wonder we should change packages to use 'gdb-minimal' instead of the "full" gdb" <= that sounds like it makes sense <janneke>but i cannot oversee the implications :-) <terpri>Leon, oops, should be "sudo guix build --repair /gnu/store/kxdbkik0dxlw4q2jwvmffxw4w200dj56-module-import-compiled.drv" i think (no '=') <janneke>but please go for it if it seems right; i'm a big fan of reducing dependencies <janneke>especially when they are not used/needed <Leon>building failed again, with the weird variable with the \x0;\x0;… <mbakke>janneke: I'll try that on staging once you have added guile to 'gdb-minimal' :-) <Leon>Maybe I should just reinstall the whole thing? There must be a command that downloads all the sources of all my installed packages and builds everything from scratch? <terpri>Leon, you could peek at the referrers/references files and see if they look like source code (.scm is scheme of course, .drv files are, i think, a Nix-based language, with funky syntax but obviously source code) <terpri>Leon, you could just reinstall guix, yes, especially if running on debian and not using too many packages <terpri>guix package -I will give you a complete list of packages you've installed <Leon>Oh, thanks! I was looking for a command that would give me all the packages I installed. <Leon>So, what about the references? What should I do before I reinstall everything as a last resort. *janneke tests gdb-minimal without guile removal for the Hurd <terpri>Leon, i'd try "sudo guix build --repair X", where X is each file in the references/referrers lists (so <10 commands to run overall) <janneke>LarryTheCow: yeah, quite possibly :-) <terpri>Leon, but the problem may lie deeper in the package graph, and if you're just using a few packages, deleting your guix installation and reinstalling may be the quickest solution <Leon>Yes, but that's the easy way. I would like to try all the options before that one. <Leon>OK, the package given by the referrers command has failed to build. <Leon>build of /gnu/store/kxdbkik0dxlw4q2jwvmffxw4w200dj56-module-import-compiled.drv failed <Leon>guix build: error: build of `/gnu/store/xx46rn64fl4s2b0rd52d9vr7qwc2pv7l-compute-guix-derivation.drv' failed <Leon>OK, I'm nearing being out of options. ^^' Would you know of an easy way to reinstall guix completely? Or the command I should use to uninstall it, then I'll run the guix-install.sh script and then install all my packages. <terpri>Leon, i'm not aware of a simple command to uninstall, but roughly: <terpri>Leon, guix package -I | awk '{print $1}' | tr '\n' ' ' <terpri>will make a list of packages in your personal profile, that you can later copy-paste into a "guix install" command <Leon>But actually, I don't know how to uninstall the whole guix package manager. I'm used to doing "apt purge package" <mbakke>janneke: On second thought, Valgrind (where most of gdb's dependencies come from) includes GDB for interactive use, which probably should have the Python extensions for the full experience <terpri>Leon, um...systemctl stop guix-daemon.service and possible guix-publish.service as well, then delete the corresponding guix*.service files from /etc/systemd <Leon>And I tried before on another machine to rerun the install script, and it failed saying it was already installed. <terpri>as well as ~/.config/guix since i had you add the channels.scm file <LarryTheCow>A more fun way of removing it is `chmod 777 /gnu && rm -rf /gnu` <Leon>Well, I think I'll have to do what terpri says, and also what LarryTheCow says. <terpri>LarryTheCow is joking, suggesting you make /gnu world-writable <Leon>At some point, if I want to do a whole reinstalling of the paxckage manager, /gnu will have to disappear at some point, no? <Leon>Oh yes, OK, I'm sorry. I'm on it. <janneke>...but probably a good catch not to break that <janneke>mbakke: would it make sense to have another gdb flavour? <terpri>so once you've (1) stopped the daemon (2) deleted the 'guix*.service' from /etc/systemd (3) deleted the dirs listed in the email (3) deleted ~/.config/guix... <mbakke>janneke: what flavor are you thinking of? 'gdb-intermediate'? :P <terpri>Leon, you should be able to then run guix-install.sh again to get a fresh installation <janneke>mbakke: we want something really minimal (for the hurd and possibly non-interactive use, rust etc), and something "stable", for valgrind (etc?). <janneke>attempting to move stable => minimal does not work, if i understand correctly <Leon>OK, everything removed. I ran the guix-install.sh <Leon>Now I'll add my personnal packages <terpri>also, guix might actually be in debian at some point, but i think the request-for-packaging got stuck because using /gnu isn't FHS-compliant or something <mbakke>janneke: it makes a lot of sense to use 'gdb-minimal' for test suites and the like. I'm not sure if Valgrind needs to include GDB at all, I suppose people who use Valgrind already have it installed? <Leon>Oh, that will be very nice! <mbakke>or introduce a 'valgrind-minimal' for noninteractive use, hmm <Leon>I'm having anothererror now though. -bash: /home/leon/.config/guix/current/bin/guix: No such file or directory <mbakke>terpri: Nix is already included in Debian, Guix is stuck because it comes with a comprehensive test suite that does not fully work on the Debian builders :P <Leon>current -> /var/guix/profiles/per-user/leon/current-guix This link is dead <mbakke>Leon: you can use '/var/guix/profiles/per-user/root/current-guix/bin/guix pull' to create your users current-guix <Leon>guix pull: error: Git error: object not found - no match for id (35691bf5dc69e4d482b31fab63e3bd73ffece755) <Leon>Do I have some kind of network problem? I don't think so. After all, I'm talking to you guys. <mbakke>Leon: probably your git cache is corrupted, try 'rm -rf ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/' <terpri>oh right, i forgot about .cache/guix <Leon>OK, I'll do it again from the start then. ^^ <Leon>OK, I think I'm completely clean now. I'll reinstall the script. <nckx>mbakke: Perfect, thanks. <Leon>OK? guix pull worked. guix install all-my-perosnnal-packages worked. My guix installation is now back on track! Thanks a lot people! <Leon>That was my desktop computer. I also installed guix on may banana pi m3. But it's very low on resources, so that's going to be trickier. Anyway, I guix pull gives me this: guix pull: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused <Leon>The socket file is empty. <Leon>I think the system crashed during a guix pull also, so I might just have to reinstall everything from scratch to make it easier? <mbakke>Leon: probably you just need to start guix-daemon.service <Leon>Oh! You're right, it's not running, I wonder why. I'll do that, thanks! <Leon>OK, now I'm trying the guix pull on the banana pi m3. Last time it failed because I didn't have enough RAM or something. We'll see this time <terpri>Leon, for low-end machines you might want to look into offloading ("Daemon Offload Setup" in manual); tl;dr your banana pi can transparently have other guix machines build packages for it <terpri>not sure if it supports cross-compiling (e.g. amd64 -> arm) though <Leon>That sounds pretty awesome! <Leon>Because the other machine building the binaries would have to build not in 64bits, but in ARM. <terpri>Leon, it's easy to cross-compile individual builds for other architectures, with "guix build --target=aarch64-linux-gnu hello" for example <terpri>dunno if it's integrated with offloading at all though <terpri>for example that command on my system took a few seconds and produced: <terpri>linked, interpreter /gnu/store/51xk2szprml75fjl25d1sdan0h60a25i-glibc-cross-aarch64-linux-gnu-2.31/lib/ld-linux-aarch64.so.1, for GNU/Li <terpri>/gnu/store/h3vhmc1k18rid5m0la03zx5hchm4s34l-hello-2.10/bin/hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/51xk2szprml75fjl25d1sdan0h60a25i-glibc-cross-aarch64-linux-gnu-2.31/lib/ld-linux-aarch64.so.1, for GNU/Linux 2.6.32, not stripped <Leon>Well, to me it would seem pretty important to implement the cross building function into offloading. It's kinda the whole point behind offloading I guess <terpri>guix build --system=foo can, apparently, use qemu+binfmt_misc to transparently emulate other architectures for building (emulation rather than cross-compiling)...offloading with that set up on the remote box might simply work (i haven't tried it) <terpri>still handy for running guix on e.g. low-end laptops with a high-end workstation on the same network <terpri>(though tbh i don't use that functionality much either, normally i rely on substitutes or debian packages when substitutes aren't available) <nckx>Leon: Not really, the main point for most users is laptop → big box or big box → farm of big boxes, of the same architecture. In practice (and not just on Guix) cross-building support is too spotty to reliably cross-build large parts of the package graph. --system is slower but almost magic (there are a few cases where the emulation isn't 100% transparent but those are few). <nckx>Guess I was primed for a ‘no, but’ 🙂 <Leon>Well, guix pull is still running on my banana pi m3, I'll see if it goes all the way til the end. For now it's working fine. So thanks a lot everyone for all your help with my issues! I kept notes on how to uninstall the guix package manager for a clean reinstall so I'll be able to do it by myself if there's a next time when I'll need it. Thank you <Leon> very much for your help and time! I think I've earned the right to eat lunch now. ^^ <mbakke>nckx: I think you'd have noticed if core-updates went into a feature freeze :P <mbakke>janneke: I pushed the valgrind change in b611597af8641b388dc9f8935b85895a71e9fb52 <mbakke>and also changed Rust to use gdb-minimal on the same branch <mbakke>obviously did not build all the rusts yet, let's see how it goes <nilsirl[m]>roptat: Unfortunately, it's not in /run/current-system/configuration.scm, so I think I'm just going to do an install from scratch, instead of using the provided VM <roptat>ok, as I said, I don't remember whether that was included before or after the latest release <janneke>yeah, so EIO happens on the hurd when trying to read /proc/1/environ, for example <janneke>now, most probably, all that /proc/1 needs is already a gc root and many other processes just have a readable /proc/XX/environ <civodul>janneke: you mentioned it was not just PID 1 though, right? <Kozo>How do you force a library into .guix-profile? At one point I had libSDL2 in there but now it's gone. It's in /gnu/store/ as well. <civodul>ah, it's not running in a UTF-8 locale <PurpleSym>So, I want to upgrade xpra to 4.0.2 and in the process replace python2-pyopengl with its python3 variant python-pyopengl. How do I commit these changes properly? Should I add python-pyopengl, then upgrade xpra and then remove python2-pyopengl (which is only used by xpra)? <terpri>PurpleSym, sounds like a plan to me, unless there are programs still on the python2 version we might want to package (seems unlikely, but i don't follow python news closely) <janneke>hey logs, didn't we chat about gdb-minimal? <janneke>civodul: that's right, i didn't find a pattern yet; though *janneke starts a fresh image that just built while they were away <civodul>janneke: i noticed that the Xapian index wasn't being updated due to bad permissions <civodul>janneke: oh thanks for the /proc thingie <civodul>did you manage to add gdb to the image? <janneke>just checked and debian/hurd shows something similar <civodul>i hvaen't been able to try that yesterday <wdkrnls>nckx: I am able to print a test page through the CUPS web interface :). ssh -L did not work for me, but with a few modifications to my openssh service I was able to ssh -Y into it using the surf web browser. <sneek>wdkrnls, you have 1 message! <sneek>wdkrnls, nckx says: I re-read our convo from yesterday (but now awake!) and am convinced that s-c-p is buggy. *civodul runs disk-image --target=i586-pc-gnu <civodul>janneke: did you have to remove some of the gdb dependencies? <civodul>janneke: thanks for the image, gdb works! <civodul>but! there are no debugging symbols for 'hurd', right? <janneke>civodul: yeah, we now have "gdb-minimal" <PurpleSym>Can I somehow use package-name inside (guix build python-build-system)? Importing (guix packages) seems to be not enough. <janneke>ah right -- no debugging symbols at all oops <civodul>i miss "guix environment --target" as well <civodul>but the approximation is not good enough <janneke>yeah, the ^C / (add-after 'install 'crash ...) "works" *janneke adds #:make-flags "V=1" to guix recipe <pkill9>imagine a meta-guix, consisting of packages that are associated with revisions of guix <pkill9>i.e. each package has it's own guix <pkill9>like with time-machine, but the package is the time-machine-applied package <civodul>janneke: it's just that there's no "debug" output <pkill9>does anyone know of a tool for finding changes to a packages inputs since a guix revision? <pkill9>e.g. a package fails to build now, but successfully built on a previous revision, and a package's inputs have changed between now and then, but you don't know which package has <pkill9>i want a tool that tells you which packages have changed between revisions <pkill9>i mean, which inputs have changed <pkill9>hmm actually, i don't think i need it recursively <janneke>civodul: so someone needs to just add (outputs "out" "debug") to our guix package? <pkill9>just realised, it's not likely going to be recursive <civodul>it's not easily discoverable, but it's there <cbaines>it sounds like the derivation comparison feature might be close to what you want pkill9, there are Compare links on the "Include derivations" variant of the page civodul linked to <cbaines>practically though, the derivation comparison feature needs improving to help distinguish cases where the derivation has changed, but the output is the same (the most common occurance), from where the derivation and associated outputs have changed (which could impact the derivation you're comparing) <civodul>janneke: alternatively, are we able to cross-compile gcc for i586-pc-gnu? <janneke>civodul: someone already did; have a look in: /run/current-system/bootstrap-profile/bin <civodul>"bootstrap-profile" hmm, i'm curious! <pkill9>nice thanks, that does what i need, haven't tested if it's correct though <janneke>this is another WIP that gets richer <janneke>"devel-hurd" gets us past guix's "configure", that's helpful <janneke>so many things are "almost" usable already!! <pkill9>oh this is cool, you can compare derivations, and then compare the derivations of differing derivations of those differences <civodul>janneke: Rome wasn't made in one day! <pkill9>with this, a tool could be made that let's you browse through all the differences <janneke>civodul: yeah, i'm really happy with how we're doing <janneke>eh, i mean: "but i haven't got all day!" <katco>hey all, i finally got a guixsd system going after years of using it as a package manager. how am i meant to change conf files? e.g. i'd like to edit `/etc/gdm3/custom.conf`, but it's not there, it's in the store. <bdju>generally you don't edit anything in /etc by hand, instead there'll be something to put in your config.scm for that <civodul>for most services, there's an "escape hatch" <civodul>where you can pass a raw config file <civodul>(and also add the missing settings to the config record) <katco>as someone who wants guix to succeed, this is slightly concerning to me. i've been part of other projects which try to encapsulate vanilla conf files, and they've all failed. <bdju>I think this is an area where nixos is ahead, they seem to have a neat config option for just about everything <katco>in this particular instance, i'm trying to set `WaylandEnabled=false` <katco>which, when i checked the manual, doesn't seem to be an option <bdju> http://ix.io/2ql4 I have this in my config to set an option in /etc/fuse.conf, maybe you could use it as inspiration <bdju>this is a bit out of my depth, I had help to do the above, but someone around could probably assist <katco>also, sorry for my manners. hello civodul, bdju :) <katco>imo, this is a significant barrier to entry for guixsd :( <katco>right out of the gate i'm stuck, and i'm somewhat familiar with guix concepts <bdju>I think you're right, but being able to have this sort of setting in a config is really cool because then you're all set when applying it to a new machine <katco>yeah, i do like that, but my opinion is that there should always be a way to fall back to a config file <katco>right now, i have no path forward to troubleshoot why i can't log into my wm <wdkrnls>nckx had suggested to me to create something like (simple-service 'descriptive-name etc-service-type (list `("path/to/config" ,prog-config))) <katco>i am left with a non-functional system, which supersedes any coolness <civodul>as i see it, encapsulated conf files is both a barrier to entry for seasoned users, and help to newcomers <bdju>are you not able to create the file in /etc as usual? my thought was that it would be wiped on an update, but should be able to be set once to get you logged in <civodul>but yeah, in the meantime, it's always annoying at best to be left with a non-functional system <katco>bdju: i certainly have access to that part of the fs, but i didn't think adding anything there would do anything. does it? <civodul>katco: could you report the issue to bug-guix@gnu.org? <katco>civodul: yeah, it's cool when it works, but as i said earlier, when i've been part of these kinds of "eat the world" projects, they have failed partly due to their inflexibility <civodul>katco: re inflexibility, like i wrote there's usually the option to pass raw conf files <civodul>but yeah, i agree that it's a tradeoff <civodul>and there's the risk that you describe, no argument here <katco>i would propose that be a default property of all things, and not something the author has to specify so that users are guaranteed an escape hatch <katco>i'll try and make my case in the bug report <katco>in the meantime, it looks like i can somehow specify a wrapper service? <bdju>katco: I think creating the file manually should work, as the simple service approach is just doing the same in a functional way so it can be applied on every reconfigure <bdju>I just checked and I have an /etc/fuse.conf with one line in it <katco>bdju: hm, ok. i guess i'll start with that since i'm trying to troubleshoot. if i find a configuration that allows me to log into my wm, i'd certainly want to make it survive reconfigures <bdju>yes, of course. I was just picturing you stuck at a TTY or similar and thinking it's more comfortable to troubleshoot from a working environment <katco>i am indeed stuck at a tty ;p <katco>one tty has been compiling the rust series for 18h <katco>unexpectedly triggered after doing a guix system reconfigure <civodul>katco: are you sure WaylandEnabled=false would help though? <civodul>i didn't specify it and yet it works on Xorg <civodul>did you check your config in "guix system vm", to see if it fails similarly? <katco>no, not at all. that's just what research is suggesting might help <katco>no i haven't tried `guix system vm`... sorry, it's not clear to me what that would be trying to show? <katco>my logs contain `gdm: GdmDisplay: Session never registered, failing` and my research suggests that maybe this is a race that was fixed in gdm and that `gnome-session` isn't completing in time. i'm using stumpwm. <katco>but this is the primary issue, and i got stuck on the secondary issue of not knowing how to modify config files to troubleshoot hehe <mbakke>katco: you can cancel that rust build, it's not going to complete any time soon (and it was a hiccup on master, fixed now) <bdju>katco: are you using an nvidia gup? <katco>oh thank god. i'm up to rust v1.33 <bdju>okay, makes sense. seems like that's what that option is for <bdju>did you want GDM or is it just the default still? you could probably replace %desktop-services with just %base-packages and then use a different display manager or skip having one and use startx or similar <katco>mbakke: huh? i just did a `guix pull` and a `guix system reconfigure` still says it's going to build all of rust :( <bdju>I usually recommend people avoid nvidia hardware due to issue like this, by the way, not that it's much help to say when you've already got the hardware <katco>bdju: indeed, this is a brand new system, but with an old spare gpu since new gpus are imminent <katco>how do i restart gdm? it's not listed in `herd status`. the closest thing i see is `xorg-server` <katco>i'm used to being able to do `systemctrl restart gdm` <bdju>if it were me I would do `sudo pkill gdm` <bdju>and I think it restarts itself from what I remember <katco>that has left me with inoperable ttys. i can only power-cycle <bdju>you could ssh in from another device still probably <katco>i.e. i just have a blinking `_` on all ttys i try <mbakke>katco: check with --no-grafts, it could be that the derivations you see are grafts <bdju>well, apologies if I've made you have to reboot. I assume you've checked tty1 and tty7 for something graphical? it may even be on 8/9, I think wayland can put stuff there. <katco>bdju: no worries at all. i expected issues getting a new system going <mbakke>katco: yes :-) but it can be handy to use -n --no-grafts to check if the derivations are actual builds or "just" grafts <katco>bdju: i appreciate your help <katco>mbakke: without grafts, the build list explodes, and rust is still in there :( <mbakke>katco: what is your 'guix --version'? and what is the version of your previous reconfigure? <katco>`guix --version` is `35691b...` <katco>`guix system list-generations` shows commit as `e66851...` <mbakke>katco: then your pull did not complete, or you ran it as a different user, or something <mbakke>35691b is the rebuild-all-the-rusts revision <katco>hm... running both as root. just did another `guix pull` which completed. same `guix --version` <mbakke>katco: huh... what does 'which guix' say? <katco>oh.... it's pointing to my user's guix.... i've been doing `sudo -s` which i think is causing issues <mbakke>katco: ah, you should be using 'sudo -i' to do a full login as the root user <katco>mbakke: i apologize. i now have a build plan that does not include all of rust <mbakke>katco: no need to apologize, glad you figured it out :-) <katco>so the manual suggests doing `guix pull` and then `sudo guix system reconfigure`. that would be using the user's guix and not root. is that the canonical way of performing system upgrades, or should i be trying to do this under root? <bdju>that's the way I do it, guix pull as user <bdju>this also means for non-system packages you can pull and update without root at all <katco>that appeals more to me since i usually work with guix for userland packages <katco>i am over the moon at managing some services on a bespoke version of linux for a nas all in userland using guix. i get to sidestep their wacky package ecosystem completely :) <atw>ugh jealous, I'm struggling to make a service for synapse, the matrix server <katco>atw: that is another area i think guix could work on: userland services are really useful even for those of us running guixsd in most places. i have wondered if there's a way to unify the sd services and userland services <katco>atw: gl on the synapse service though! i'll be using that (albeit perhaps dendrite) at some point :D <atw>if by user services you mean stuff like redshift or mpd running for just one user, I think some people have some approaches to that <katco>atw: services running on a non-guixsd system <atw>ah ok different thing <katco>i.e. i had to define my own services, some of which are already written as guixsd services <roptat>just pushed maven-install-plugin in my wip-maven-build-system branch, 4 more plugins and it'll be complete! <atw>so exciting! congratulations roptat! <roptat>I already have them in a separate channel, so what's left is easy, but I still need to complete them: descriptions, and try to enable tests <roptat>I should be done by tomorrow evening <roptat>to be honest I already had everything a month or two ago, but I dedicated my free time to another project instead of integrating my work into guix immediately <roptat>maven-resources-plugin done, 3 more plugins left <thorwil>hi! so i wanted to take care of the long overdue update of caps-plugins-lv2. building from git took many hours, making me wonder if something is going wrong. i mean to recall this used to take less time, but then again, i didn’t measure back then or now. <thorwil>then hours more after `./pre-inst-env guix package -i caps-plugins-lv2`, only to run into an error with mesa <mbakke>thorwil: there was a commit yesterday night that caused a big rebuild, but it was fixed this morning, perhaps you got unlucky? :/ <mbakke>just add it to your system configuration :P <mbakke>or update the description of bind :-) <thorwil>i see. the whole build from git, make and ./pre-inst-env dance is still the expected way of testing a change before submitting a patch, right? if only it wouldn’t be so ridiculously resource intensive. <mbakke>thorwil: normally you'd get substitutes for everything you did not change <apteryx>mbakke: right, I should edit the description <mbakke>apteryx: sounds good, where to find dig is probably a top 10 question around here :-) <apteryx>just editing this kind of metadata doesn't trigger rebuilds, right? <apteryx>(descriptions are ignored from the hash computing machinery IIRC) <bdju>In IceCat when using duckduckgo, if I refresh the results page I'm sent to some generic search page. The same happens if I click a result and then try to go back to the results page. It seems my search terms aren't in the URL. Any idea why this happens now? <katco>what is the canonical way to run services for a single user? e.g. i used to run `gpg-agent` under userspace systemd <apteryx>bdju: because you disabled the GNU LibreJS plugin <bdju>You're correct that I disabled it, but I don't quite follow you here. Why does that result in this problem? <bdju>On my phone, for example, I don't seem to have the problem... so it's not just the "normal" ddg behavior as far as I can tell. <bdju>Interesting! So enabling librejs sort of fixes it by redirecting me to the html-only version of the site. I don't have that same "html" bit in the url on my phone, though. <bdju>If it is a new default behavior, then I guess that would mean it was left out of the mobile version of the site maybe. <katco>i guess that's not in the manual yet haha <mbakke>it would make for a good cookbook entry ***MightyJoe is now known as cyraxjoe
<civodul>which reminds me we should do something with the patch you submitted a while back! <cbaines>and yeah, hopefully I'll make some time at some point to circle back around to that work <cbaines>I'm busy procrastinating working on getting data from the Guix Build Coordinator in to the Guix Data Service at the moment though... <janneke>hmm, building the daemon now works, on the hurd, running is still something else <roptat>arg, I've been trying for two hours to add one of the packages i need for maven... <roptat>it looks like I can't include (gnu packages maven) in (gnu packages java), because one of the packages in maven.scm inherits from a package in java.scm <roptat>I just moved it to java.scm instead, and now I can include maven.scm, but I have a dependency loop between packages, and I don't see where <cbaines>if it applies, it should indicate where there's a loop <roptat>cbaines, it applies, that's great! <roptat>now I see where the loop is coming from <cbaines>cool, looking again at that patch is another thing I should make time for at some point... <roptat>so, one of these packages will need to have its tests disabled... <atw>mbakke: thanks for the link, I'd missed that blog post! I'll probably convert my jank setup to that. +1 to putting that in the cookbook! <roptat>mh... actually I think I added a dependency that's not needed <rekado>cbaines: could you please add this commit to the master branch or propose it for discussion on guix-patches? <rekado>I’d very much like to have something like that. <cbaines>yeah, I'll try and send an email out about it soon <nixfreak>how can I install nimble (nim package manager)? <nixfreak>So nim is a packages on guix , but it doesn't come with nimble or nimsuggest or any of the other tools for nim <nixfreak>so I decided to build it instead and it worked just fine , but I get errors like this though now ... /tmp/nimble_7950/githubcom_PMunchnimlsp_#head/src/nimlsppkg/suggestlib.nim(7, 14) Error: cannot open file: /gnu/store/gy2hv90in37dprl86rphly55n1vxl8b6-nim-1.0.6/nimsuggest/nimsuggest.nim <nixfreak>so I have nim setup in ~/nim and I also created a dir for nimble in ~/.nimble/bin <nixfreak>I have all the src files in ~/nim/ I created a path PATH=$PATH:/home/nixfreak/nim/bin and PATH=$PATH:/home/nixfreak/.nimble/bin <bdju>the guix way would probably be to package nim stuff instead of using nimble. there are tons of r-foo, rust-foo, python-foo packages and so on. <bdju>hm I don't see any like that for nim, though. <roptat>maven-compiler-plugin done, 2 more plugins to do! <roptat>I suppose we only have the compiler, but no package yet <roptat>nixfreak, you $PATH has guix's nim first I think <roptat>I don't know how nim looks for files, but maybe it can be configured with an environment variable? <nixfreak>its looking for this path /gnu/store/gy2hv90in37dprl86rphly55n1vxl8b6-nim-1.0.6/nimsuggest/nimsuggest.nim <nixfreak>so If I build something I need to move it to ~/ right? <roptat>/gnu/store/...-nime-1.0.6 is the store directory where nim is installed, its --prefix at configure time <roptat>does that mean nim is looking for files only in its prefix? <nixfreak>it supposed to install in /usr/local /usr/local/bin <roptat>nixfreak, but it doesn't really make sense, if you install in /usr/local, it will look for /usr/local/nimsuggest? <roptat>it's just polluting your /usr/local that way... <roptat>but in any case, I don't know how nim works so... <roptat>you'll have to find a way to specify a non-prefix directory <roptat>it looks like there are NIMR_BIN and NIMR_SRC