<plasma41>All the spare drives and the original drive on the computer exhibiting the issue are IDE. On the computer that works fine, the DVD drive is SATA. Hmmm... <espectalll[m]>On a system which didn't finish guix system init because of a bad bootloader config? <apteryx>espectalll[m]: I think as long as you remount the previous /gnu/store location, rerunning guix system init a 2nd time should bring you pretty much to where you where in not much time (given that everything has been cached so far). <plasma41>Attached a spare SATA DVD drive and tried again. No change. Same issue. Dang. <plasma41>Maybe it's in the ATAPI protocol implementation; that would affect both. <plasma41>What must I do from grub on the install DVD to load the sata_nv kernel module? <THFKA4>does anything in GuixSD react to udev's "uaccess" tag? <apteryx>IIRC this is still to be implemented in eudev <rk4>what's the xfs desire motivated by? <tune>why does adding exfat-utils and fuse-exfat to my manifest and doing 'guix package -m manifest.scm' do anything besides install those packages? it's doing something with cataclysm-dda.... <tune>I didn't do a guix pull or anything <tune>just wanted to quickly put files on a flash drive <joshuaBPMan>rk4: thanks. I guess I heard that xfs is a little more stable than ext4. <joshuaBPMan>I remember reading something along the lines of "people are quietly migrating to xfs instead of btrfs." <rk4>ext4 is stable enough most mortals <tune>still updating two hours later when I just wanted to add two packages! <efraim>Still doing the manifest? You could just do 'guix package -I foo bar' ***rekado_ is now known as rekado
<rekado>tune: if you’re confused about what Guix does try adding “--no-grafts --dry-run” first to get an overview on what it will do. <rekado>yay, three Softiron Overdrive 1000 boxes arrived at my office. ***Server sets mode: +cnt
<tune>hm getting locale errors and failure to recognize package i3blocks <tune>both seemingly config.scm failing to work properly <tune>as I had the locale thing fixed already <tune>are the packages necessary for formatting a drive as UDF available on GuixSD? <tune>rekado: not entirely sure. saw a few different answers. I ended up using a machine running Void to format the drive. the package I used there was "udftools" I think, but I heard a couple other possible names <tune>also: is there any way to mount drives as an unprivileged user? I heard of "pmount" but it doesn't seem to be packaged <rekado>tune: you can use “udiskctl mount” <espectalll[m]>Hey, small question, why is cargo installed with Rust but not added to the path? <roptat>ah, that's because it's a separate output <roptat>that's the syntax to specify an output <roptat>a package can have multiple outputs, the default one is "out", so rust is actually rust:out <janneke>samplet: i've been doing more Gash merge and bootstrap work on my wip-bootstrap branch <janneke>hoping to build mes-boot in scheme-only bootstrap *janneke has been hoping for it to build for some hours now ;-) <samplet>janneke: That’s great! I’ve been hoping you’d give it a try. <janneke>i was missing some commands that historical Gash had (type, command) <janneke>found and fixed some silly bugs/regressions (rmdir, test) <janneke>found new brokenness and added failing test <janneke>samplet: tests/42-export-new.sh is most annoying now <samplet>janneke: Is the work on Gitlab? I only see stuff from a week ago. <janneke>it would be nice if you renamed your geesh.git to gash.git @ github and had a look at the READMEs, i added some stuff <janneke>eh yeah, on my wip-bootstrap -- wait <samplet>janneke: I found it. GitLab is calling it “gash-historical” in some places, which is really confusing. :/ <janneke>i renamed gash.git to gash-historical.git <samplet>janneke: It also looks like you are not using my “wip-bootstrap” work. Maybe there’s something weird with the GitLab UI. <janneke>samplet: i'm on top of b9fcc34b26822c0f51a143812c96a2ffa6b28c51 tests: bootstrap: Patch out 'test -o' <janneke>i think gitlab confused the rename, and now repos have gotten merged <samplet>janneke: If I clone it, it looks fine. That’s bizarre. <samplet>I was hoping to avoid “test -o”/“test -a”, but I guess that was just wishful thinking. :( <samplet>(The POSIX spec. says it wants to retire those flags eventually.) <janneke>samplet: gitlab still seems to name it janneke/geesh.git -- i attempt an new rename <janneke>samplet: i think it worked now (gitlab.com/janneke/gash); you should see wip-boostrap at: <janneke>eb57119 Oops: remove accidentally committed files. <janneke>samplet: ah, (-a -o) i only now read your latest patch <ngz>Hmm recently, when using guix environment guix, then ./pre-inst-env guix build something, I get a lot of "Unbound variable: something", something being, e.g., "coreutils", "perl", "python", etc. and I eventually cannot build anything. Is there a known fix for that? <samplet>janneke: I just pushed a commit that should fix the failing export test. <rekado>ngz: has your checkout been modified? <rekado>ngz: this indicates a problem with your checkout. <ngz>I did guix pull recently <ngz>According to "guix pull -l", I'm on ea593fe2984ca665c864160d2bd5e40362a4eb09 <ngz>I'm calling pre-inst-env from HEAD. <rekado>is your git checkout “dirty”? <janneke>samplet: thanks! i added a hack that i was able to remove -- just rebased onto you again <janneke>i also made set -x noisy now, that helps a lot with debugging failing scripts :-) <ngz>guix pull is related, when I do "guix environment guix", isn't it? My git checkout is dirty, I'm trying to build a package with pre-inst-env. Hmmmm <rekado>ngz: does it enter the environment as expected? <rekado>then “guix pull” is unrelated. <rekado>your git checkout must be broken then. <ngz>Then my changes are probably too dirty. <ngz>OK, I'll double check. Thank you :) <ngz>rekado: Found. I was missing a home-page entry… Sorry for the noise. <janneke>finally into phase check for Mes' scheme-only bootstrap using the new Gash <janneke>note that the pre-merger Gash could not run 'check at all (much too complex shell stuff), but it had all provisions for the build stage <janneke>after the merger, much more possibilities but also quite some "regressions" <plasma41>Has anyone successfully installed GuixSD 0.16.0 from the ISO images onto a computer with an nvidia chipset? <THFKA4>i'm having a hell of a time trying to get eudev to load additional rules <THFKA4>i'm following the manual to the t where it gives an example with the "android-udev-rules" package <THFKA4>guix repl shows them as part of the OS definition. where else can i look? <pkill9>THFKA4: have you added the rules to the eudev service definition? <pkill9>or just adding them as a package <pkill9>oh nevermind you said you followed the manual <THFKA4>yep, i have them in the definition <rekado>THFKA4: can you show us the config? <THFKA4>is modify-services under services in the OS definition? <rekado>(services …) is a field that accepts a list of services. <rekado>%destop-services is such a list. <rekado>(modify-services %desktop-services …) returns a new list of services based on %desktop-services. <THFKA4>i also tried it with the android-udev-rules package and a slightly different syntax <THFKA4>nope, system reconfigure finishes fine <rekado>does the generated system’s udev directory contain the rule? <THFKA4>i then use udevadm trigger and udevadm test to check the list of rules that applies to the device node <THFKA4>it looks like it only loads the rules from the eudev package which does not contain the rules <rekado>THFKA4: but does the generated system *provide* the rule? <THFKA4>hmm, i'm not sure that i know where to look for that. i checked the store and the current generation doesn't have anythin udev-related in /etc <rekado>guix gc -R $(readlink -f /run/current-system) <rekado>you should see an item named “/gnu/store/…-udev-rules” <rekado>it has a directory “lib/udev/rules.d/”, which should contain your rules. <rekado>this means that your system config is fine. <rekado>the problem is likely with the defaults of udevadm <rekado>it doesn’t know that your rules are in this other non-standard directory <rekado>so it might need to be told about this. <THFKA4>are you saying that udevadm doesn't list the applied rules, even though they're in effect? that wouldn't bother me as much <rekado>I don’t know much about udev, though, so I don’t feel comfortable giving you an authoritative explanation :) <THFKA4>no worries, thanks a lot for your help