IRC channel logs

2024-09-14.log

back to list of logs

<[>How do I get GnuPG to work with KMail? Attempting to access the GnuPG settings in KMail results in this error: kf.coreaddons: KPluginFactory could not create a KCModule instance from "/gnu/store/aivv392dyfrqc4cqf7p50cng256rp8z5-profile/lib/qt6/plugins/pim6/kcms/kleopatra/kleopatra_config_gnupgsystem.so"
<RavenJoad>Why is Cuirass (my own instance, not Guix CI) so slow at pulling substitutes? Is this just a Cuirass thing? The download speeds are fine, but it took 40+ minutes to build a texlive-scheme-medium-based package, which just builds a LaTeX PDF.
<RavenJoad>I am facing an error with kpathsea to generate fonts(?). "kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 tcrm1000" fails because ././homeless-shelter has a permissions error.
<nckx>RavenJoad: It's the default value of $HOME and inaccessible more or less by design. Set $HOME to (getcwd) or so.
<RavenJoad>I thought that was the problem. When I do a "guix shell <package> --container" in the package's repo, and "unset HOME", I do not get the error. Is this just a thing because this is CI then?
<nckx>Guix builds are Guix builds. There is nothing special about ‘CI’.
<RavenJoad>That's what I thought. Curious how I am not getting the problem in a container on my local system, but I am on Cuirass. I added the phase just now and am building again.
<nckx>(Manually running things inside guix shell is not a Guix build, of course, but I don't know what differs in your case to make it work. A lot of things, for sure.)
<RavenJoad>The "export" of env vars inside the container is small, so I am not sure how much is different, but I'll never know.
<RavenJoad>I also "wget"-ed my Cuirass instance, so I'll let you know how it handles the change in 30ish minutes.
<nckx>You could run ‘env’ in both the ‘guix shell’ container and the Guix build container and compare the output, if you care enough.
<nckx>Actually, the mere fact that HOME *is* set in the build container rather than unset is a likely cause.
<nckx>You could unsetenv it. Again, assuming you care enough :)
<RavenJoad>I mean, $HOME is set by Guix to /homeless-shelter on purpose. The real solution to this problem is to find out why kpathsea is running to resize fonts.
<RavenJoad>nckx: Yep, adding a phase before build to set $HOME to a non-default worked in CI. (I imaging if I actually created the directory manually things would work too, but this is a fine workaround to the error for now.)
<apteryx>ugh, OVH KVM interface (on their website) keyboard input appears to work fine with Chromium, doesn't in Librewolf. Feels like 1998 again.
<bdju>a bunch of programs are warning me about my locale and not being able to set it since my last reboot. where would that be configured? .profile? config.scm? shell config? not something I usually mess with
<bdju>hm in my config.scm I have a locale set
<bdju>though I wasn't able to do a system reconfigure since my last pull and user package upgrade due to the swaylock problem
<bdju>wonder if something is out of sync
<bdju>can't really afford to have a broken swaylock or maybe I'd try commenting it out to let the system reconfigure go through and then adding it back
<bdju>maybe because the locale setting in config.scm isn't working I should just set it somewhere else
<bdju> https://0x0.st/Xx0I.txt here's my output for the locale command, a few "no such file or directory" bits at the top but then most of the env vars actually do look to be set properly
<bdju> https://0x0.st/Xx0l.txt okay locale -a output looking way less good. maybe my locale is set properly but the locale itself is missing(?!)
<bdju>that seems harder to fix
<bdju>yeah think I'm screwed until the swaylock thing is sorted. will just deal with it for the time being
<dxk>Hi, I recently ntfs formatted a previously fat formatted usb stick I use to transfer files to/from windows. I installed ntfs-3g, and can mount/umount the stick with sudo, so I know the basic mounting process works fine.
<dxk>It is only a minor inconvenience, but I'm used to mounting usb sticks as an unprivileged (but member of "wheel") user, and the same configuration did so mounting the same stick when it was fat formatted.
<dxk>In the file system configuration I have /mnt/8g defined with options "noauto,defaults,user". In the system config I append (setuid-program (program (file-append ntfs-3g "/sbin/mount.ntfs-3g"))) to %setuid-programs. Where should I look next for getting this working again?
<Rutherther>as a different solution you could consider using udisks, it's in the default %desktop-services. Then you can use udisksctl to mount stuff without privileges
<Rutherther>with the current config with setuid programs it still doesn't work? what does "which mount.ntfs-3g" say?
<dxk>~ $ which mount.ntfs-3g says /run/privileged/bin/mount.ntfs-3g
<sepeth>Hey Guix, I know guix build has --keep-failed, but is there an option for a successful one as well? I just want to check if the install phase is not copying something.
<nckx>sepeth: No, you'll have to (add-after 'install 'die die) or so.
<sepeth>Thanks! Nice trick ^-^
<PotentialUser-25>Hi!
<nckx>Hullo.
<PotentialUser-25>Anyone else have recent problem with icons in gnome??
<PotentialUser-25>mine disapeard one of the last times I updated
<PotentialUser-25>I've made sure the adwaita-icon-theme is installed, and I tryed to change the icon setting in the configuration-manager, to no avail.
<nckx>ACTION doesn't use GNOME, sorz.
<PotentialUser-25>guix has also startded pestering aboit installing glibc-locales(wich is installed) and Define GUIX_LOCPATH, again. I am running guix SD, so acording to manual, this should only be an issue if i've installed guix as a user
<PotentialUser-25>But I belive that to be a separate issue
<nckx>dxk: You could try using the in-kernel ntfs3 driver? AFAIK ntfs-3g in Guix doesn't support being setuid at all, claiming that it's insecure.
<nckx>(Which may well be true!)
<jakef>PotentialUser-25: that locales warning goes away after a system reconfigure and reboot
<nckx>PotentialUser-25: I think it's related to user and system profiles being ‘out of sync’, yes.
<PotentialUser-25>nckx That tracks XD
<PotentialUser-25>jakef no, it does not. My system is old.
<jakef>old as in you haven't pulled in a while?
<PotentialUser-25>no pulled yesterday
<nckx>dxk: This one: <https://paste.debian.net/plainh/c0b1598a> It's strange that you didn't see it…
<PotentialUser-25>installed it years ago
<nckx>Installation time shouldn't matter, Guix System is entirely rolling release.
<PotentialUser-25>system is from aug23
<nckx>(And called Guix System now, although you did technically install GuixSD :o)
<PotentialUser-25>jami fails for system XD
<PotentialUser-25>nckx XD Did not get the memo, will take note
<nckx>PotentialUser-25: Pretty sure 23 August is out of date and the cause of this message.
<PotentialUser-25>So.. my Guix system system jami failed XD
<nckx>core-updates was merged bringing a new glibc and locales. It's the version mismatch between your system and user profiles that causes these LOCPATH messages.
<PotentialUser-25>OK so dissonans between system and lokal install??
<PotentialUser-25>I thought my system was supposed to be stable?
<PotentialUser-25>(it generally has been)
<nckx>Whoever told you that owes you a refund.
<PotentialUser-25>XD
<PotentialUser-25>clearly do XD
<jakef>so just to confirm, you have reconfigured your system since core updates merge?
<jakef>or have you never reconfigured your system since install?
<PotentialUser-25>Is the lack of icons also propebly coused by the difference betveen system and user?
<nckx>Less likely IMO, but let's tackle one problem at a time.
<nckx>I think 23 August predates the core-updates merge, so while you might consider it recent (it is) it's not recent enough in this particular case, if you've since ‘guix pull’ed and modified your user profile.
<PotentialUser-25>My system was last updated on aug23, this year. has stumbeld in build issue with jami, since
<nckx>This is something of a special case (or treat!) whenever core-updates is merged. In other cases, a lag between user and system profile is fine.
<nckx>OK, so reconfigure and reboot and the LOCPATH noise should go away.
<PotentialUser-25>OK so need to figure out how to lock the current jami version in place in the system config
<PotentialUser-25>so it will stop feiling at jami XD
<nckx>./media/audio/audio-processing/webrtc.cpp:22:10: fatal error: webrtc/modules/audio_processing/include/audio_processing.h: No such file or directory
<PotentialUser-25>one of the problems is I don't do this shit often enough, so I forget from time to time XD
<PotentialUser-25>Luxary issues XDXD
<Rutherther>PotentialUser-25: see documentation of inferiors for using jami from different guix channel commit than rest
<PotentialUser-25>nckx Egsagtley!
<PotentialUser-25>Rutherther On it :)
<PotentialUser-25>nckx You know how to fix jami?
<nckx>If you ‘guix install’ed jami, you can use ‘guix upgrade’ with ‘--do-not-upgrade=jami’ to keep the old version.
<nckx>If you have it as part of your system configuration, you'll have to use an inferior as Rutherther said. The UX is… not great, but you can copy most of the boilerplate from the manual section on Inferiors.
<PotentialUser-25>it's part of my system XD
<nckx>PotentialUser-25: No, and this kind of hyper-complex WebMedia2000 nonsense error message doesn't exactly tempt me to try.
<PotentialUser-25>system packages, i just usually wait to be usable
<PotentialUser-25>but when I also do not have icons. It becomes a usabillity issue
<PotentialUser-25>also, I will have to remember to remove it later, wich I'm not great at XD
<PotentialUser-25>Holy shit, that seemed overly complicated
<nckx>core-updates tends to bring more bugs at once than your average Guix day.
<PotentialUser-25>(the inferior thing, that is)
<PotentialUser-25>nckx OK, so not just a missing dep XD
<nckx>guix time-machine --commit=d5312370b46ace47e138d84e1bb28e5651cee94b -- install jami # might also work
<PotentialUser-25>seemed simpler XD
<PotentialUser-25>Well, then. I guess Jami is officially to unstable to be in system :/
<nckx>ACTION tries updating Jami, but at the first sign of WebCoreCyberMedia.wasm nonsense I'm back out.
<nckx>Lies told by people on a Saturday.
<Rutherther>nckx: update won't work
<nckx>Well bugger that. Why not?
<Rutherther>I've looked into it, the problem is that webrtc-audio-processing has moved include files so that now the include is just top level instead of under "webrtc" package. The newest libjami (jami-daemon) source still contains "<webrtc/" reference
<nckx>OK.
<Rutherther>it seems a bit like a regression in the webrtc-audio-processing guix package, but I am not sure completely
<Rutherther>because having the stuff without webrtc/ prefix seems very strange, it's not clear it is webrtc
<nckx>Everything is under include/webrtc-audio-processing-1, which tracks with <https://packages.artixlinux.org/packages/world/x86_64/webrtc-audio-processing-1/> (random distro)
<Rutherther>yes, that is true, but that's not really what I meant
<Rutherther>look into the pkgconfig file
<Rutherther>before last update it was include/webrtc_audio_processing/webrtc, where the include/webrtc_audio_processing was what pkgconfig referred to, so you still had webrtc under the root include folder, whereas now it's all in root include
<Rutherther>maybe this is just an upstream decision in webrtc_audio_processing between 0.x and 1.x, looking into arch that has both it can be seen webrtc prefix is there for the 0.x one
<Rutherther>so it would probably mean for libjami to compile to provide it with webrtc_audio_processing sub 1.x, since it has not been updated to use the 1.x
<Rutherther>(by not updated I mean that libjami upstream has not updated it https://git.jami.net/savoirfairelinux/jami-daemon/-/blob/master/src/media/audio/audio-processing/webrtc.cpp?ref_type=heads#L22)
<nckx>I'm currently trying to build it against 1.x anyway 😈
<Rutherther>I wonder if artix decided to keep the sub 1 just because of libjami... in ther jami-daemon is the only referrer, so it would seem that way
<Rutherther>arch has two, jami-daemon and dino
<PotentialUser-25>Hmm... nowI have icons(in gnome). But adwaita does not work properbly, it only shows thise blue generic icons, not different/correct ones
<PotentialUser-25>nor does hicontrast, work
<PotentialUser-25>but yaru icons work
<PotentialUser-25>Well, at least I have icons, again, and the glibc-locales warning seems too have disapered
<PotentialUser-25>(moved jami to local install, through time-machine. and updated)
<PotentialUser-25>Thanks, for that :D
<PotentialUser-25>So, now only it is only adwaita(icons), that does not work correctley
<PotentialUser-25>XD
<PotentialUser-25>YeY adwaita XD
<Rutherther>how have you installed the adwaita icons?
<PotentialUser-25>Are they not part of the gnome install??
<Rutherther>I wouldn't know
<PotentialUser-25>I did try to install them as user, just to see if it fixed the issue, it did not
<Rutherther>did you relog after installing them as user?
<PotentialUser-25>no..
<PotentialUser-25>They were already installed XD
<dxk>nckx: How can I use the in kernel ntfs3 driver - I could load it with sudo modprobe ntfs3, but still no user mount.
<apteryx>I tried -build-options $7 #:print-build-trace #t #:print-extended-build-trace? #t) but it's still mostly silent.
<apteryx>where $7 is my store connection, as opened by (open-connection)
<apteryx>set-build-options*
<Rutherther>PotentialUser-25: okay, unfortunately I don't really have any more pointers, as icons are always quite tricky. You can try searching for some gnome cached files and removing those
<apteryx>PotentialUser-25: what is the icon issue?
<PotentialUser-25>Adwaita(icontheme)only shows these blue "icon-missing" icons
<nckx>PotentialUser-25: Re: jami, pull and try again. Or wait a while and get a substitute.
<PotentialUser-25>Do they need to be installed sepperatley, as system package?
<nckx>I'd link to the CI page but it be 504in'.
<PotentialUser-25>nckx Thanks :D
<Rutherther>PotentialUser-25: having them in any XDG_DATA_DIRS suffices, so can be system, can be user, doesn't matter
<PotentialUser-25>Already had them in usr
<nckx>dxk: You don't even need to modprobe it AFAIR, simply using -t ntfs3 should autoprobe it. This is sounding less like a driver issue and more like a mount issue. Can you ‘user mount’ ext4 file systems for example? Are you invoking /run/privileged/bin/mount and is it setuid?
<PotentialUser-25>tryed to remove them from user, to if iot did any dif, and it did not
<apteryx>nckx: libjami is currently broken; I started working on a jami update but it's on the back burner
<PotentialUser-25>Out of curiosity, what broke the jami package to begin with?
<PotentialUser-25>Does anybody know?
<apteryx>I guess some updated package from core-updates
<Rutherther>update of webrtc-audio-processing 1.x, but jami-daemon still hasn't moved to it, and the include files have been moved
<Rutherther>jami-daemon supports only webrtc-audio-processing 0.x
<PotentialUser-25>Ahh, Thanks
<nckx>apteryx: Is there an upstream libjami commit that builds with webrtc-audio-processing@1?
<PotentialUser-25>Then why was webrtc-audio-processing removed, when it is still a dependency?
<Rutherther>it wasn't removed. It was just updated
<PotentialUser-25>I thought one of the pro's of guix is that different versions of the same package can coexist?
<PotentialUser-25>(I am so clearly a noob XD)
<Rutherther>yes, the can, that's also what the fix consits of. But that they can doesn't mean that Guix always keeps the older version, only if there is a necessity like here. Not every package is checked to be compatible afterwards, so it can happen that it won't build afterall
<PotentialUser-25>Ahh
<PotentialUser-25>I tought that happend autmagick
<nckx>Alas not.
<Rutherther>that's something else, the older versions don't get removed from your store and you can still use them. But the problem here was that the code updated it, and that means that libjami automatically starts pointing to newer version, since it just points to the symbol webrtc-audio-processing, and that one can just be updated to point to newer
<PotentialUser-25>I thought you had to define dependency versions, and then guix just "magickally" got the right one from its history
<nckx>apteryx: I'll grant avp commit access later (want to make sure we don't step on each others' toes since there's a hypothetical chance of breaking master if they push too soon).
<nckx>PotentialUser-25: Nope, Guix doesn't deal with versions at all, it is (by design) very stupid. What exists right now is all that exists.
<PotentialUser-25>Ahh
<PotentialUser-25>Then I clearly missunderstod samething XD
<PotentialUser-25>And this all of a sudden makes a lot of sense XD
<nckx>ACTION ‘sorry.’
<apteryx>nckx: cool, I'm happy to let you do it
<apteryx>to avoid breaking master, the trick is to add them to the savannah guix project *after* pgp is set right
<apteryx>they can't push to the repo until they're part of the guix savannah group
<apteryx>by 'pgp', I meant .guix-authorizations and the keyring branch
<nckx>Oh, I know, but if two people are dancing in the same spot they'll step on toes and it might foul up the order of things.
<apteryx>nckx: oh, you fixed libjami, thank you
<apteryx>I had missed that
<nckx>Meh, ‘fixed’, but you're welcome!
<nckx>Are you involved with Jami development {still,at all}?
<apteryx>I never really was involved in serious Jami development (mostly was doing devops things for it), and won't be doing this anymore since I no longer work for Savoir-faire Linux
<nckx>Oh, I didn't know.
<apteryx>i"ll try to keep the guix package updated though, since I think on paper it's about the best thing we have for conferencing
<apteryx>(in practice, some annoying bugs remain though)
<dxk>nckx: I tried ~ $ mount -t ntfs3 /mnt/8g mount and got /mnt/8g: must be superuser to use mount.
<Franciman>hi, i rolled back to a previous generation of my guix home
<Franciman>now what if i want to retain this version of packages but add a new package?
<dxk>ncxk: which mount gives /run/privileged/bin/mount and ~ $ ls -l /run/privileged/bin/mount gives -r-sr-xr-x 1 root root 56552 2024-09-14 07:31 /run/privileged/bin/mount which has the 's' flag
<nckx>Does ‘command -v mount’ agree? Avoid ‘which’, it doesn't do exactly what people think it does.
<nckx>dxk: ☝
<nckx>ACTION reconfigures with an NTFS partition.
<dxk>nckx: I get command: command not found. Which package is it in?
<nckx>It's not.
<nckx>So you're not using bash, OK.
<nckx>Let's avoid all that and just ask: does explicitly invoking ‘/run/privileged/bin/mount /mnt/8g’ not work?
<nckx>I'm also not convinced that your ‘mount’ invocation is correct. Too many options.
<apteryx>what should the license of a meta-package (purely propagating stuff) be?
<nckx>I'd expect ‘mount /mnt/8g’ to work, as well as ‘mount /dev/foo’, but not your command with explicit -t and whatnot.
<nckx>apteryx: The intersection of all component licences. Some form of GPL if you're lucky. If you can't reduce it to one licence, you can list all of them & let the user sort it out, although I'm sceptical that it's equally correct.
<dxk>nckx: in bash, I get /run/privileged/bin/mount, the same as with which
<nckx>OK, thanks. Although I think it's an invocation error, try dropping ‘-t ntfs3’ and use only the device or mount point.
<dxk>nckx: mount /mnt/8g give Unprivileged user can not mount NTFS block devices using the external FUSE library. Either mount the volume as root, or rebuild NTFS-3G with integrated FUSE support and make it setuid root. Please see more information at https://github.com/tuxera/ntfs-3g/wiki/NTFS-3G-FAQ
<nckx>There we go.
<nckx>That's success.
<nckx>Switch the type from ntfs-3g and ntfs3 and you should be good to go.
<nckx>The FUSE error is a Guix packaging bu^Wdecision, but the ‘must be superuser’ error is just mount not being clever enough to figure out that you are using allowed options from /etc/fstab. I believe you'd get that on any distribution.
<nckx>According to the Arch wiki, ‘[t]here is no good technical reason for not allowing setuid for external FUSE besides a mistrust of the library. This patch removes the said restriction.’
<nckx>Do we want to trust that…
<nckx>Typo: Switch the type from ntfs-3g and ntfs3 → Switch the type from ntfs-3g to ntfs3
<apteryx>nckx: thanks
<apteryx>hm, OK I've clearly pushed something that causes a world rebuild...
<apteryx>git-minimal ?
<dxk>nckx: Awesome, I think that's done it. Many thanks! I'll just do a full restart to confirm and summarise the findings.
<nckx>apteryx: Hey, that's my thing.
<apteryx>yep, I touched a phase of git-minimal, which trips git-minimal/pinned, which trips gtk+
<apteryx>and I thought I was being clever
<nckx>dxk: \o/ I tried removing mount.ntfs-3g from privileged-programs (it still needs to be in the list of system packages due to https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/linux.scm#n2243) and replacing ‘user’ with the (special FUSE snowflake?) ‘users’ option, but no dice. I think you're limited to ntfs3 if you want this, for now.
<nckx>People on the Internet are adamant that ntfs3 is less stable than ntfs-3g.
<nckx>People on the Internet are adamant that ntfs3 is more stable than ntfs-3g.
<nckx>So it evens out.
<apteryx>so... according to our processes, what should happen with this git-minimal change I reverted? before, that would have been core-updates
<apteryx>a feature branch + custom CI job + merge request for this seems silly (in terms of efforts expanded for the return)
<Rutherther>oh you reverted it? then I should pull once more instead of the rebuild I suppose :D
<apteryx>yes, it's already reverted, apologies
<Rutherther>no worries, it's fine
<apteryx>wait, my push failed, or something
<nckx>Finally, something that I can be blamed for.
<apteryx>Rutherther: second time is the charm: 258aab2c9b
<apteryx>nckx: haha
<nckx>sneek: later tell dxk https://logs.guix.gnu.org/guix/2024-09-14.log#161117
<sneek>Will do.
<nckx>sneek: botsnack?
<sneek>:)
<dxk2>nckx: In summary, To just read/write to an ntfs formatted usb stick as an unprivileged user, include that user in wheel and define the stick as: (file-system (mount-point "/mnt/8g") (device (file-system-label "DT")) (type "ntfs3") (mount? #f) (create-mount-point? #t) (options "noauto,defaults,user"))
<dxk2>nckx: This uses the built-in kernel module ntfs3. Now a non-root user can mount/umount /mnt/8g without sudo.
<nckx>Yes. Also, well done on fooling sneek, the highly intelligent bot, with your new inscrutable pseudonym.
<dxk2>nckx: more that I'm struggling with using irc, especially in a web browser.
<nckx>I've seen sneek reply to less obviously related nicks, so I have no idea why it didn't this time.
<dxk>nckx: oh well, all's well that ends well. thanks again...
<sneek>dxk, you have 1 message!
<sneek>dxk, nckx says: https://logs.guix.gnu.org/guix/2024-09-14.log#161117
<RavenJoad>Is it normal for Cuirass to take 1000+ seconds to build a simple LaTeX document? It takes ~10-15 seconds on my desktop in a guix shell container.
<nckx>I assume it's not building per se.
<RavenJoad>The log for the run that took 1100 seconds only has the build, no substitutes needed. Runs that take 4-10x as much time pull substitutes too. "phase `build' succeeded after 1085.5 seconds" (From the successful build's log)
<dariqq>isi t normal to have to relax 10+ cargo dependencies? Rust developers like to depend on ^random-patch versions which makes the whole semver thing pointless
<nckx>RavenJoad: Huh. Not what I expected, I'll admit.
<nckx>Cuirass ‘just’ builds via Guix.
<nckx>This isn't binfmt-emulated or anything, right?
<RavenJoad>nckx: I may have some confounding factors here, since my Cuirass instance is a VM whose disk is on a network share. But other builds (Go, Common Lisp, and Guile) all build in <15 seconds.
<RavenJoad>Nope, no emulation.
<RavenJoad>Oddly enough, my desktop is normally quite slow at building LaTeX too, but I have texlive-scheme-everything (whatever the actual symbol is).
<aswjrisp>I am trying to install guix on a computer using a uefi partition setup. The bios has options for uefi. I am getting this grub install error message https://termbin.com/f1ef
<aswjrisp>I have recorded all the install steps I am using in this shell script. https://termbin.com/8m03
<rynn>Anyone know if the quassel package in guix is the monolithic all-in-one?
<aswjrisp>My system config is https://termbin.com/z7qt
<aswjrisp>rynn: Have you checked it's outputs?
<rynn>You mean the package definition?
<aswjrisp>The output of lsblk is https://termbin.com/kedb
<rynn>Just looks like it's using quassel-version-tar.gz, which is ambiguous
<aswjrisp>The output of blkid is https://termbin.com/qfs1 with /dev/sdb being the usb that the installer is on.
<rynn>Ahh, looking at the git repo, looks like the mono builds list that in the name, so I think the Guix one is just the normal client.
<aswjrisp>What I am trying to do is have a disk partitioned for eufi and have a root partition that is luks encryted with a btrfs filesystem in it. The btrfs has subvolumes for root, home and swap.
<aswjrisp>With a swapfile in the btrfs subvolume swap.
<aswjrisp>I am not sure how to deal with that error message.
<aswjrisp>I am running the last couple of commented out lines in the script linked above manually to allow me to iterate through attempts faster.
<aswjrisp>Some of the things I have tried to get the install to work have been switch from a bios to uefi partitioning, run guix pull from the intsall image and use the UUID from blkid instead of fdisk (they give different UUIDs).
<aswjrisp>I also switched from using fdisk interactively to using parted in the script.
<aswjrisp>Rutherther: I took your suggestion to switch from a bios to a uefi partition scheme.
<Rutherther>is your system i386 architecture?
<aswjrisp>Rutherther: lscpu tells me it is x86_64
<Rutherther>also I think you are going to have easier time if you make /boot esp folder rather than /boot/efi. It should work somehow even with encrypted /boot, but I can imagine more problems
<makx>I just recently installed with encrypted /boot (which is part of /); worked fine enough. only annoyance is that I have to enter the passphrase twice
<Rutherther>you would have to enter it twice even with unencrypted /boot, since the linux and initrd are still in the store
<makx>\_")_/ well then ;)
<aswjrisp>Right now I have a partition with a fat32 filesystem on it and that is mounted in /mnt/boot
<aswjrisp>Then I created a efi directory in /mnt/boot
<aswjrisp>That partition has the esp ond the boot flags on.
<aswjrisp>The partition is /dev/sda1.
<Rutherther>oh, so then your targets should be /boot, not /boot/efi. It should be directly the esp, not the efi folder under it
<aswjrisp>So I should change the target under bootloader in my config to be /boot instead of /boot/efi. Should I also remove the efi directory I made.
<aswjrisp>Rutherther: Or would it be better for me to do your suggestion of "make /boot esp folder"? If so could you elaborate a little on what you meant.
<Rutherther>I think if you removed it it would just get created automatically. Though I've always seen the folder with all caps. I am not sure if it matters
<Rutherther>aswjrisp: I assumed your current esp was /boot/efi, since you have that in config. But you already have /boot as esp, so you are already using that suggestions
<Rutherther>I should've looked at the lsblk output you sent first, and I would see immediatelly your esp is already /boot
<aswjrisp>Okay I will try change the config to use /boot instead of /boot/efi and remove the efi directory I created.
<aswjrisp>Made the changes and reinitializing.
<aswjrisp>Rutherther: I get a very similar error message. https://termbin.com/4roa
<aswjrisp>Made the change in the config from /boot/efi to /boot. Also removed the efi directory in /mnt/boot/.
<aswjrisp>I am rerunning the init with my config copied over to /mnt/etc/config.scm and making sure I use that in the init command.
<Rutherther>I am quite confused by the error message since you are on x86_64 so it should look for that one, and additionally, since it's efi variant, it should look for -efi folder, not -pc...
<Rutherther>what is the output of "uname -a"?
<Rutherther>also do you now have /sys/firmware/efi folder now?
<aswjrisp>Rutherther: There is no /sys/firmware/efi directory. I am using the 1.4.0 install image and have done a pull in the image.
<Rutherther>then it seems you are still not booted in uefi, so it makes sense grub doesn't really detect it should do an efi installation
<aswjrisp>The output of uname -a is https://termbin.com/z3qe
<Rutherther>uefi installation has to be done from being booted into uefi
<aswjrisp>Rutherther: In the bios boot menu I had two options for the usb there was one that was uefi and another one. I will redo the system setup using the script I linked after booting the uefi installer selected in the boot menu.
<Rutherther>after being booted into that first check presence of that /sys/firmware/efi folder
<Rutherther>if it won't be there, no need to bother with installing another time since it will fail again
<aswjrisp>I will check for the /sys/firmware/efi folder first.
<aswjrisp>/sys/firmware/efi is there when I boot the uefi usb in the bios boot menu.
<aswjrisp>I am going to try the install again.
<attila_lendvai>is it normal that guix pull --list-generations runs for minutes?
<freakingpenguin>attila_lendvai: I've noticed that behavior. Not sure what makes it take so long.
<aswjrisp>Rutherther: thanks for your help.
<aswjrisp>The install worked and I was able to bott
<aswjrisp>boot and sign in.
<aswjrisp>These were the key things I learned that were causing problems.
<aswjrisp>Boot the uefi installer from the bios boot menu.
<aswjrisp>Do a guix pull in the installer.
<aswjrisp>Use the UUIDs from blkid and not fdisk.
<aswjrisp>For the bootloader use /boot instead of /boot/efi.
<aswjrisp>Use uefi instead of bios partitioning.
<attila_lendvai>any idea why do i get "configure: error: pkg-config is missing, please install it", when pkg-config is present and runs fine? this is with building a shepherd checkout.
<Rutherther>attila_lendvai: so it happens when building a package, or?
<attila_lendvai>Rutherther, i run $ ./configure in a shepherd checkout. i used to work, and now it doesn't, and i have no idea what changed
<attila_lendvai>./configure: line 7268: PKG_PROG_PKG_CONFIG: command not found
<attila_lendvai>if i run autoconf: configure.ac:52: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd
<attila_lendvai>ACTION never understood autoconf and company
<attila_lendvai>that line is configure.ac seems unrelated: GUILE_PKG([3.0])
<Rutherther>I also don't know much about this. But one thing - do you have automake and pkg-config in the same profile to get the ACLOCAL_PATH search path? it should point to a folder with pkg.m4
<attila_lendvai>i've seen this before. then it goes away, and i have no idea what i did that fixed it... i've seen this a couple of times already. how annoying!
<attila_lendvai>i added them, but didn't help: guix --development shepherd automake autoconf
<mrh57>how do guile foreign libs work on guix?
<mrh57>accessing foreign libs in guile I mean
<mrh57>as far as I can tell, (load-foreign-library <lib>) is not gonna look for <lib> in either /run/current-system/profile/lib or /home/<name>/.guix-home/profile/lib
<mrh57>you can add arbitrary paths with the env var GUILE_EXTENSIONS_PATH, but surely any installation of guile in guix should have at least the former lib in its foreign search paths
<mrh57>unless I'm missing something?
<mrh57>*former lib path
<galois`>How to share local files with a container?
<Rutherther>gaois: the guix options for container also have --expose for read only or --share for rw mounts of your filesystem
<galois`>Rutherther: Thanks
<galois`>Ok so I added something like --share=/home/.../Desktop/ as an argument. Where can I find the files contained in that folder?