<fnstudio>hi! if i reconfigure to a system definition that inherits from another one, how will that be reflected into /run/current-system/config.scm? will i end up losing any "provenance" information, e.g. anything related to the base definition?
<PurpleSym>podiki: As expected rocm 5.1.3 does not support my gfx803-based GPU any more ☹️ Keeping only rocclr-4 is not sufficient, I think. We’d need a full stack of rocm 4.5 (which is the last version to support that GPU). I’ll see if I can simply `inherit` everything without too much hassle.
<tex_milan>hello folks, any idea why mount is unable to mount sshfs?
<tex_milan>root@t14s /home/milan# mount -t fuse -o defaults,user,exec,uid=1000,rw,noatime,allow_other,max_read=65536,port=2222,IdentityFile=/home/milan/.ssh/id_rsa_moto_e7 email@example.com:/mnt/sdcard/ /sshfs/moto-e7
<tex_milan>mount: /sshfs/moto-e7: wrong fs type, bad option, bad superblock on firstname.lastname@example.org:/mnt/sdcard/, missing codepage or helper program, or other error.
<jpoiret>i'd suggest using the sshfs command directly if that's possible for you
<jpoiret>my guess is that you'd need to install sshfs/fuse userspace helpers in the system profile
<tex_milan>sshfs directly works. but i want automount, this is what automount executes and fails.
<daviwil>Hey folks! Simple patch to bump the version on herbtsluftwm, any maintainers free to take a look? If I hadn't let my commit access lapse I could have pushed it myself ;) https://issues.guix.gnu.org/55924
<fps>i screwed up by calling sudo -E guix pull. now running that as regular user complains about the symlink already existing (sorry, can't copy and paste from that vm)
<ekaitz>another random question: why if my package generates a /include output that is not added to the $GUIX_ENVIRONMENT when I use the package from a manifest? what did I miss?
<fnstudio>ok, the certbot+nginx thing ended up requiring a bit more tinkering than expected: i understand one has to first deploy a certbot-only system config; at that point i had to run the renew-certificate script manually, which was unexpected; then i reconfigured to a certbot+nginx system, but also in that case i had to manually herd restart nginx for it to come to life
<fnstudio>(i may very well be missing something of course)
<nckx>ekaitz: I'm not sure, but something. So $(guix build P)/include definitely exists? Which command do you run to enter the shell/environment?
<ekaitz>nckx: the /include dir exists in the build and the command to enter the shell is just `guix shell -m manifest` and the manifest includes the package
<jonsger[m]>nckx I do usually `sudo -E guix pull`, but I can't do anymore. It says "guix pull: Fehler: directory ‘/home/jonathan/.cache/guix’ is not owned by user jonathan" but that directory is owned by jonathan:users
<nckx>jonsger[m]: With ‘sudo -E’ (the default for ‘sudo’ on Guix System), you are root but keep almost all of your regular user's environment. This was a problem, because ‘sudo guix pull’ would happily create root-owned files in ~user/.cache/guix, and the next ‘guix pull’ without sudo would be unable to update them → fatal. ‘sudo -i’ is the moral equivalent of logging is as root; ‘sudo -i guix pull’ with update root's guix using root's ~/.cache,
<maximed>All that has to be done is setting RUSTC_BOOTSTRAP=1.
<lechner>cache, but the system folder in unsuitable as an install location. Would it be better if GUILE_SITE_DIR worked off of $prefix to produce $(libdir)/guile/$(GUILE_EFFECTIVE_VERSION)/site-ccache ?
<maximed>lechner: For classical non-Nix-like distribution, installing to Guile's site-ccache makes more sense (if in another location, it wouldn't be found
<maximed>Though maybe nowadays $(libdir) makes more snese?
<lechner>maximed: isn't the location the same for classical distros?
<maximed>lechner: No. On classical distros, it's /usr/lib/guile/3.0/site-ccache.
<maximed>Which _is_ writable by dependencies during installation.
<PurpleSym>podiki: Yeah, just wasted some time trying 4.5 and it also does not work, which means 4.3 was the last version to support my GPU. I guess the easiest path would be to just bump to 5.1 and I’ll just use a Guix inferior with 4.3.
<podiki[m]>any idea where the support dropped that we could patch back in or just keep a limited package set around?
<podiki[m]>very annoying for them to drop support, though I guess they never really list anywhere what is supported too
<lechner>Hi, in view of the 'staging' rebuilds, is there a local strategy for the sharing, mirroring or other reuse of official substitutes?
<maximed>lechner: You can set up a publish server and set up guix-daemon with --discover to share things on the local network
<maximed>but I'm not seeing the relation to staging.
<maximed>Also, the substitute server is ‘just’ a HTTP server, so you a generic caching proxy should work if you want something mirror-like.
<podiki[m]>PurpleSym: as perhaps the main (only?) user of rocm v4, probably up to you how to handle the older version. Though if this is a habit of rocm, might be worthwhile to keep older versions going forward?
<lechner>Hi, is an inferior a way to amend the symbol definitions in xkeyboard-config with a custom layout (likely a patch)?
<PurpleSym>podiki: I’m always conflicted about that tbh. I mean: We have a the time-machine to go back, but guix-past also exists. Not sure where to put rocm in this spectrum and when time-machine would fail us here. Does it work after a libc upgrade, for example?
<podiki[m]>PurpleSym: yeah, not sure the best course of action. we do have several options in guix and at least rocm is pretty standalone, other than the llvm part (but we keep a few versions of llvm anyway)
<ggoes>hmm, i seem to have lost spell check in chromium
<tricon>the site claims they have yet to determine specifically which crypto libs are affected.
<maximed_>tricon: SHouldn't this have been done during the embargo period?
<tricon>maximed_: Yeah, I'm wondering why at least major libs weren't audited during that time.
<maximed_>Even if it's only telling crypto lib people: ‘here's a vulnerability, we don't have the resources yet to look into it ourselves yet if it applies to you, but quite likely it does, so prepare!!!’
<elb[m]>(To follow up on my Emacs troubles earlier; I removed the distro Emacs packages, which were there to be able to build Emacs debian packages, updated Guix and cleaned some things up, and now guix-about works, so I have no idea. The distro Emacs stuff wasn't in the load-path, but I wonder if it wasn't interfering.)
<podiki[m]>basically removing the -Ddri-drivers flag we currently have
<podiki[m]>there is a separate branch to have these older drivers.... thoughts?
<kaelyn>Hi guix, how would I select the gcc:lib output (with libstdc++.so in it) when calling "guix shell"? I would have expected "guix shell gcc@10:lib" to work, except it gives an error because "gcc@10" is being shunted to "gcc-toolchain@10".
<kaelyn>forgot to add: and "gcc-toolchain" doesn't have a "lib" output, nor does it include libstdc++.so
<jpoiret>gcc itself is hidden iirc, only gcc-toolchain is usable from the CLI
<nckx>justkdng: Fix it to use /run, but what else would you do?
<nckx>kaelyn, jpoiret: Should it be added to gcc-toolchain? It's not the first time someone needs it, and I'm not sure how I'd write it using -e (which doesn't accept gexps, although I'm not surprised).
<justkdng>nckx: don't package have a hash prefix or something?
<nckx>Hold up. Are you saying this package installs a PID file or socket?
<justkdng>I'm trying to use Arch's pkgbuild as an example
<justkdng>it has some systemd files, services, tmpfiles
<justkdng>don't know how to translate that to guix
<nckx>The ‘hash prefix’ applies only to the store directory, which is where the package is installed after it's built. It's similar to the contents of ‘a package’ (.deb, .whateverarchuses) on other distros. At run time, packages may go nuts, and write whatever they want to /var.
<nckx>Although as previously stated we use /run, not /var/run.
<nckx>podiki[m]: Our current mesa package builds some dusty DRI drivers to the detriment of their shiny Gallium versions (there can only be one provider), which is weird.
<justkdng>though, they are related to the service files
<podiki[m]>nckx: I saw Arch had the same drivers we do (i915, etc) for that flag, so we weren't alone; if I remember correctly now mesa will refuse to build if you specify that as that code is removed
<podiki[m]>nckx: I'm not up on all the different drivers and names to know if we are losing actual hardware support or just the older drivers that have been superseded (seems like at least some old hardware is unsupported now?)
<podiki[m]>we could also have a mesa variant that uses the alternative branch with those drivers still, but that's only useful for someone to specify a transformation to build all the mesa dependents with it
<podiki[m]>justkdng: from what I know that is all towards setting up systemd services, or mostly I think (or e.g. a user meant to run something)...for services look into shepherd if you need to make a service
<podiki[m]>nckx: I see core-updates has the libdrm and wayland-protocols version needed for latest mesa, other than that I had to remove the old driver flag and it built successfully last time I tried
<nckx>justkdng: Yes, those would also be handled by Guix system services, if they are handled at all.
<mitchell>Hello guix, I need to get my hands on an arm-linux-gnueabihf cross compiler. How can I tell guix to build such a thing for me?
<maximed_>mitchell: Do you want the cross-compiler, or the cross-compiled software?
<nckx>Just for reference, I'm building Mesa-not-22 with "-Ddri-drivers= -Dgallium-drivers=[long list of crap],i915". I don't expect it to break my 2013 ThinkPad at all, since it should be 10+ years newer than the kind of hardware targeted by the deprecation, but I'd prefer to be certain.
<maximed_>For the latter, I think you can do "guix build hello --target=arm-linux-gnueabihf" to cross-compile hello.
<nckx>Since i915 is what old ThinkPads use, a disproportionate number of Guix laptops will be unaffected if it works 😉
<nckx>podiki[m]: I'm far from an expert, but what exactly is confusing, apart from the length? Maybe I can help.
<nckx>justkdng: Just to confuse you further, G-exps are a proprietary Guix® innovation, not found in other Schemes (or even Guile).
<mitchell>maximed_: How do I refer to the package created by `cross-gcc` from the `specifications->manifest` form
<podiki[m]>nckx: I mean confusing what is included by default or not. Looking at the Arch wiki, i915 page just says plain old mesa, so I want to say that in current mesa i915 is in the default gallium driver set
<podiki[m]>searching back this discussion goes back like 10 years, as the gallium drivers were being developed but the previous i915 was the main one
<nckx>They just aren't consistently used? Or is ‘i915[g]’ not quite a synonym for ‘Iris’? Or…?
<nckx>I'm beginning to fear justkdng didn't take the kick as purely technical.
<podiki[m]>mesa 22 no longer has any i915, so that wouldn't work for mesa 22; prior to that is more confusing
<nckx>sneek: later tell justkdng: Welcome back, sorry for the kick, nothing personal. *Please* use the paste service in the topic for posting more than ~3 lines. IRC isn't Matrix; posting walls of text is considered bad form to say the least.
<sneek>justkdng, nckx says: Welcome back, sorry for the kick, nothing personal. *Please* use the paste service in the topic for posting more than ~3 lines. IRC isn't Matrix; posting walls of text is considered bad form to say the least.