<benjamin1>I tried running 'package-derivation' in a guix repl, but the debugger it dropped me into was for the client, not the build daemon
<mbkamble>Can anyone suggest how services launched from my home-environment (eg emacs daemon) see the env variables (specifically PATH) setup from ~/.bash_profile rather than just that of /etc/profile? I have packages in ~/.guix-extra-packages that I need to be accesible in emacs
<lilyp>mbkamble: wrap them in a shell script that sources the relevant extra packages?
<mbkamble>how I ensure that it gets source by shepherd? This is the pstree hierarchy of emacs: hepherd(1)───shepherd(2245)───.emacs-28.1-rea(2246)
<lilyp>have shepherd launch a shell script or alternatively, since it's guile code, have shepherd setup the environment variables
<mbkamble>understood. I think I have the skills to write the shell script and launch all my daemons through it (emacs, gpg-agent). I don't kow guile enough to achieve the env var setup for shepherd
<mitchell>No I was simply taking a stab at the dark and ran `file` on a binary that worked and on my program. The only difference was the glibc version (which i guess is what that number is)
<mitchell>but i made another pack with some other stuff, including guile, and it all worked fine
<nckx>It's the minimum Linux kernel version that the glibc the binary links against will run on. But even that is a bit of a lie in Guix, since the only '2.6' we support is actually heavily patched IIRC. Long story short it really isn't something you should worry about.
<mitchell>https://paste.debian.net/1245224 Here is my approximate package definition. This is a work thing and I cant share the sources with the outside world but i am not doing anything except calling scm_boot_guile which should drop me into a repl. I am cross compiling to a xilinx zynq-7000 which is a cortex-A9 armv7. I call the following `guix pack --target=arm-linux-gnueabihf my-guile guile htop tree`. I copy the resulting tarball to the
<mitchell>device, unpack it, and source the profile. All the programs work as expected except my-guile which seg faults when not run with --help or --version.
<mitchell>strace shows it trying to load a bunch of guile site files (and succeeding?) until it crashes
<mitchell>the guile package itself has a lot of propogated inputs. Perhaps i should inherit those to my package as well
<retropikzel>I'm trying to make package out of stklos. If I download the source and do ./configure && make it works. Put when building as package ./configure fails to recognise the OS and the build fails on compilation. Can I somehow make ./configure find the info even when compiling as package?
<lilyp>"configure fails to recognize the OS" sounds rather cursed
<lilyp>in any case, utils/shlib-options has the magic
<maximed>benjamin1: FWIW, guix could detect that the UTF-8 hasn't been set up and bail out?
<maximed>And there are some plans for making Guile support files with arbitrary file name encoding (independent of locale) which would make things more error-prone
<maximed>Though as it is currently, it also seems a reproducibility problem to me.
<retropikzel>lilyp, I can find multiple utils files but not shlib-options
<jmes>Maybe a dumb question but where are .so files installed on guix? I need libffi.so to do stuff with CFFI in common lisp, but it's not found after installing with guix install.
<mitchell>why are cross compiled packs so much larger than native ones? When i run `guix pack htop tree coreutils` the resulting tarball is 28M. When I run `guix pack --target=arm-linux-gnueabihf htop tree coreutils` it is 63M.
<lilyp>probably some cross-compilation artifacts are kept in there, plus cross-compilation may not result in optimal codegen?
<maximed>mitchell: Is this only for the pack itself, or for the cross-compiled software itself?
<maximed>You could do "guix build htop tree coreutils --target=..." and then run the store items through "guix size"
<lilyp>ahh, yes, the toolchain is also included in `guix pack', so you'd have to go with the size reported by guix build instead
<maximed>I assume that including the toolchain is an accident, not the intended functionality?
<mitchell>interestingly the arm htop is smaller by 100k
<nckx>Not to hammer a dead horse, but now Microsoft 'GUIX' is #1 on DDG for 'guix git', and the real Guix is last, with the Microsoft GitHub mirror somewhere in between.
<maximed>mitchell: I don't know the direction. Just give both a try, I guess: "guix graph --type=references --path /gnu/store/this /gnu/store/that"
<mitchell>I put it through dot and ARM ncurses-> x86 ncurses and gcc-cross-arm-linux...-lib which both point to x86-gcc-lib
<nckx>dhruvin: Patches to make the build scripts run on less common distributions are welcome! I don't find either example in the code, though, although there is an --output-delimiter example in a manual translation.
<nckx>maximed: I have a script that tries both directions & prints the working one because I always forget it.
<nckx>Just don't expect future contributors to those files to test on every obscure distro under the sun. You might have to keep maintaining the Alpine compatibility. Though, these files don't change that much.
<nckx>james[m]: Reinstalling with the exact same set-up won't magically fix this. Reinstalling without FDE might. Can you afford to do so for now? We can also wait a bit for others to chime in; I'm currently out of ideas.
<nckx>I don't own any ‘modern’ hardware and I don't really mind. But I'm sorry I can't be of more help.
<sneek>unmatched-paren, jgart says: I don't really use any of thosse programs. That was mostly for dcunit3d_ who needs them. I'd probably use Octave but I imagine dcunit3d_ needs some feature of Matlab that Octave doesn't provide maybe or it's a requirement for some class or whatnot
<unmatched-paren>I guess it makes sense; it's a temporary solution while they get the self-hosting compiler working.
<unmatched-paren>(Well, not exactly temporary; they plan to keep maintaining harec as a bootstrap path.)
<nckx>unmatched-paren: <Do you really think an Alpine Linux package maintainer would> My complete Alpine experience is yesterday days old; I wouldn't know. I tried to apk add cowsay and it said no such package, so I wasn't impressed by their priorities so far.
<nckx>the_tubular: Thank you! However, what you view (source) is exactly what I wrote to index.html (in emacs). There's nothing more there. I didn't make the background; it's borrowed from a 64K demo (by… I want to say Mercury?) without permission.
<unmatched-paren>guix pull fetches the latest guix, guix package -u / guix upgrade updates the software in your profile, sudo guix system reconfigure /etc/config.scm will create a new system from the configuration file at /etc/config.scm, which will update system software
<unmatched-paren>james[m]: sure it does. `guix show icecat` shows "name: icecat" then "version: 9.10.0-guix0-preview1"
<unmatched-paren>What I'm saying is: the Hurd was probably a lost cause from the moment GNU decided to use Linux. And even before then, it was getting nowhere (iirc) and being derided as vapourware by some.
<james[m]>That's really unfortunate because its a good design in my opinion. I guess they just need more people working on it.
<unmatched-paren>The efforts to get it working are valiant, but IMHO probably ultimately pointless.
<james[m]>I think its the fact that people left that project to work on the Linux kernel. I mean if you look at the git logs there are not many people working on it.
<unmatched-paren>james[m]: Well, the reason GNU eventually fell back to Linux was that Hurd was taking a loooong time. And, I think, the reason that Linux was created in the first place; apparently Linus wanted a UNIX that ran on x86 computers, but Hurd was nowhere near done.
<james[m]>Yes its being worked on. But not by many people.
<KarlJoad>What is the proper way to specify a networked filesystem to be mounted? I understand it would go in the file-systems field of the OS definition, but am unsure if there is something special that must be done.
<lilyp>you would need to set the nfs type and probably also make it not mount at boot
<KarlJoad>Are other filesystem types supported? Samba/CIFS, namely. I have control over the server, so I can set up NFS, but am lazy.
<lilyp>we do have samba packages, but I don't actually know the mount options to do things by hand
<lilyp>(I usually rely on gvfs, which works as expected in Guix)
<james[m]>Does anyone here have experience with virtualization in guix?
<james[m]>I want to use Xen. And just wanted to know if anyone had issues setting it up or if its just as simple as on Debian.
<james[m]><maximed> "james: I've done some work on..." <- Nice. Yea. At the moment I only know enough to do minor bug fixes and stuff. Its quite intimidating as I am new to that. I also attended the virtual hacker week that happened when everything when online.
<james[m]>Also I keep getting errors when I do a guix refresh. Is that normal?