IRC channel logs


back to list of logs

<plasma41>No luck with any of the spare drives.
<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]>Just wondering
<espectalll[m]>How do you chroot with a working guix?
<espectalll[m]>On a system which didn't finish guix system init because of a bad bootloader config?
<espectalll[m]>Oh, just running guix-daemon
<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).
<espectalll[m]>...but it's now on my path
*apteryx is rebooting
<espectalll[m]>apteryx: hope so, will give a try
<plasma41>Attached a spare SATA DVD drive and tried again. No change. Same issue. Dang.
<plasma41>espectalll[m]: I wonder if is related to my issue. My problem computer does use an nvidia chipset.
<espectalll[m]>The first one seems to be after installation
<espectalll[m]>That second one tho 🤔
<espectalll[m]>...but then IDE drives should work?
<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
<joshuaBPMan>does guix support xfs filesystems?
<joshuaBPMan>or is it only ext4?
<rk4> says "Currently GuixSD only supports ext4 and btrfs file systems. In particular, code that reads file system UUIDs and labels only works for these file system types.
<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
<rk4>s/most/for most/
<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.
<jlicht>hey guix!
<efraim>rekado: yay!
***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?
<rekado>what packages are those?
<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>I actually used a script from github but it depends on other things
<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>what do you mean?
<espectalll[m]>It's not symlinked at my Giux profile
<roptat>give me a second to check
<espectalll[m]>But searching it up shows the binary is there
<roptat>ah, that's because it's a separate output
<roptat>you should install rust:cargo
<espectalll[m]>Oh, why the :?
<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
<espectalll[m]>Alright I see
<roptat>yw :)
<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.
<samplet>What kind of problems remain?
<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/ 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
<janneke>samplet: i renamed my branch! it's at (previously known as geesh.git)
<samplet>janneke: I found it. GitLab is calling it “gash-historical” in some places, which is really confusing. :/
<janneke>samplet: uhuh...that's bad
<janneke>i renamed gash.git to gash-historical.git
<janneke>i'll have a look
<janneke>yes, i see -- ugh that's bad
<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: oh oh, that's not good
<janneke>samplet: i'm on top of b9fcc34b26822c0f51a143812c96a2ffa6b28c51 tests: bootstrap: Patch out 'test -o'
<janneke>your commit from a week ago
<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 (; you should see wip-boostrap at:
<janneke>eb57119 Oops: remove accidentally committed files.
<samplet>janneke: Yes. It’s good now.
<janneke>phew, thanks for the headsup :-)
<janneke>samplet: ah, (-a -o) i only now read your latest patch
<janneke>yeah, i guess we need that
<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>Pulled yesterday
<ngz>I'm calling pre-inst-env from HEAD.
<rekado>guix pull is unrelated.
<rekado>is your git checkout “dirty”?
<rekado>or is it equal to HEAD?
<rekado>erm, equal to master?
<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?
<ngz>Yes, it does.
<rekado>then “guix pull” is unrelated.
<rekado>your git checkout must be broken then.
<ngz>Then my changes are probably too dirty.
<rekado>heh :)
<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>rain1: thanks!
<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?
<rekado>I can show you mine
<rekado>THFKA4: here’s what I do:
<THFKA4>thanks, looking
<THFKA4>is modify-services under services in the OS definition?
<rekado>THFKA4: yes.
<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>here's what i have, it's quite similar
<THFKA4>i also tried it with the android-udev-rules package and a slightly different syntax
<rekado>do you get an error?
<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.
<THFKA4>it's there
<rekado>okay, that’s good
<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
<THFKA4>hmmm, okay
<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>yes, that’s a possibility
<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