<mbkamble>Hi. I am using fish shell as my login shell. could someone guide me how to write the code for (home-environment ... (services ... (service home-fish-service-type ...))) so that the generated fish.config will source the $GUIX_EXTRA_PROFILES/<profile>/<profile>/etc/profile for all profiles under $GUIX_EXTRA_PROFILES?
<mbkamble>I believe I will ned to use home-fish-extension, but I don't know how
<tinybronca[m]>"So, no, systemd is not going to become a package manager, because ordinary distros won't have a package manager at all, except maybe Flatpak, or Snap or something similar. The new functionality, including managing installed kernels, is to facilitate A/B type dual-live-system partitions."
<KiranShila[m]>Am I missing some PAM configuration here? I have `pam-limits-entry` setup such that it creates `* - memlock unlimited` in `/etc/security/limits.conf`, but those setting are not being applied. `ulimit -a` shows that the memlock size is unchanged.
<KiranShila[m]>Ah I see - pam_limits.so is only enabled in `login` in pam.d
<zacchae[m]>If someone made a pull request for something like this, would guix even accept it? I searched the manual for "windows" and came up dry, so I'm wondering if there is some policy against doing something like this
<lilyp>If only there was a package manager that could support more than two system generations...
<ardon>Hi guys. I'm trying to spin up a server with Guix on a VPS, but after booting up the ISO and building the new system with `guix system reconfigure', it complains about `Out of memory: Killed process'. Is my best bet to include an `ssh-service' in the ISO and then invoke `guix deploy'? Or does anyone know what are the memory requirements of Guix? I'm currently trying it on a 1GB RAM cloud instance from Vultr
<jpoiret>sneek, later tell civodul: do you think it'd be ok if we used (@@ (ice-9 popen) piped-process) like maximed suggested? i don't think it'd be worth it to reinvent the wheel, maybe propose exporting it upstream?
<zamfofex>Hello, Guix! I’m trying to use a Hurd VM service to offload builds, but I keep getting an SSH error. ‘guix offload test’ tells me “Access denied for 'publickey'. Authentication that can continue: publickey,password”. I have some more info to share, just give me a moment.
<jpoiret>what kind of key are you using? wasn't there some deprecation recently?
<ardon>efraim, jpoiret: Thanks, I'd mostly use it with `guix deploy' though, so it was more about the initial installation of the system. I'll try and see if I can rebuild the VPS with an ISO that has an openssh service running
<jpoiret>great! maybe it'd be worth to have a 'minimal VPS bootstrap ISO`
<lilyp>zamfofex: Guix doesn't use your own SSH keys
<zamfofex>lilyp: It uses root’s, right? But I was able to connect with ‘sudo ssh’ too. I also went as far as to add root’s public key to ‘/etc/childhurd/root/.ssh/authorized_keys’ to no avail.
<zamfofex>At any rate, I need to be absent for a while now, but I’ll be back later!
<rekado>for as long as I can remember, bash completion of Guix commands hasn’t worked for me.
<rekado>I’ll type “guix package --manifest=<TAB>” in a shell in Emacs (M-x shell) and I get a REPL error.
<rekado>it does seem to work in a Gnome terminal, so it must be something to do with my Emacs settings.
<rekado>do you have any ideas on how to debug this?
<blake2b>in guix we don't configure, we schematize :sunglasses-emoji:
<unmatched-paren>So, someone in #hare recently noted that the leap-seconds.list file that Hare uses for timekeeping is not included in their distribution's tzdata. I checked, and we don't have it either. Would we be able to graft a new version of tzdata that includes leap-seconds.list? Or are grafts reserved for security updates only?
<nckx>unmatched-paren: In tzdata's case you'd just update the main tzdata package whilst making sure tzdata-for-tests doesn't change.
*jonsger[m] wasn't aware that combining 16:9 and 4:3 on Wayland (on Xorg I guess as well) behaves so badly...
<nckx>rekado: That ‘Unknown object’ error is what I get when I do *anything* with guix in Emacs, including M-x guix-all-packages. As for completion, M-x shell doesn't use bash/readline's and must roll its own. For example it fails at completing ‘ls --’.
<pashencija[m]>I want to have conditional arguments inside invoke. How do I do that?
<unmatched-paren>`,@` is like `,`, but it splices the list that it's given into the quoted list. So `(foo ,(list 32 12)) returns (list 'foo (list 32 12)), whereas `(foo ,@(list 32 12)) returns (list 'foo 32 12).
<nckx>‘Users’ are a myth, and Guix doesn't drink that Kool-Aid.
<nckx>There's a lot of work left to make Guix more user-friendly, but in a way that benefits equally all users, not ‘users’. Projects chasing the latter make poor ‘I'd never use this myself but my users are idiots’ decisions.
<nckx>GNOME had this bad. I don't know if they still do. I hope not.
<nckx>Use -v2 (or -v$whatever) if you use git send-email.
<nckx>If you don't already know how to merge patches: git commit --amend, probably.
<unmatched-paren>A "typical PC user" doesn't _really_ exist any more... obviously there are still windows users, but most people are on "smart" phones now. So to an extent, any PC user is somewhere above average.
<nckx>unmatched-paren: Smart phones kind of make the myth a reality, although I'm undecided on how much of it is prejudice. Nobody develops telephone software on the telephone. The ‘thank you, based dev’ rift is strictly enforced.
<unmatched-paren>pashencija[m]: It also seems to me as if Macs are dwindling in popularity among average PC users. I have not seen a Mac in a long time, barring some workplaces that are clearly using them to look professional.
<unmatched-paren>So even if you're using a Mac normally, you are not an average PC user! :P
<nckx>pashencija[m]: It gets better if you put the (normal) effort into learning it. I installed Guix System without understanding a single Scheme character. I copy-pasted my way into functional bliss.
<jpoiret>non-local control flow really messes with functional programming
<jpoiret>basically, (dynamic-wind pre thunk post) runs pre before the dynamic extent of thunk is entered and post after it is left, which means that for example if you abort to a prompt in thunk that goes outside of it, post will be run
<unmatched-paren>i think scheme's biggest weakness is how it tries to be both simultaneously functional and imperative
<jpoiret>this lets you clean up things when there's a non-local exit
<maximed>FWIW I think that should be implemented with the exception system.
<unmatched-paren>nckx: I find that dynamically typed languages have a place, so I'm happy to use them, but once they start being used for big projects like Guix they become rather annoying to work with
<nckx>unmatched-paren: Sure. Much like being functional, the Scheme thing to do would be to leave it up to the programmer. Some won't like that (but then they like Haskell so who's truly sane here) but it's the Scheme way.
<zamfofex>I feel like it would be nice to have a better way to verify types at runtime at least. If you claim “the argument must be a list of numbers”, I don’t care that it might not be checked at build time, but it would be nice to have it fail early tight then and there instead of failing later.
<zamfofex>I’m still a bit stuck trying to offload builds to the Hurd VM I set up. Does anyone have that kind of thing set up?
<wdkrnls>Sadly, I think I'm pretty much going to have to give up on using R directly from Guix for now until the community grows. Everything is available and works perfectly from debian, but there is just so much.
<civodul>wdkrnls: re missing Info files in R, it's worth reporting a bug
<sneek>civodul, jpoiret says: do you think it'd be ok if we used (@@ (ice-9 popen) piped-process) like maximed suggested? i don't think it'd be worth it to reinvent the wheel, maybe propose exporting it upstream?
<civodul>jpoiret: using @@ on external software should be a last resort IMO
<maximed_>civodul: The idea is to export it in Guile (the external software)
<civodul>i'd rather work on a fix in Guile proper and use it once it's available
<zamfofex>It feels like there is an issue with how Guix connects through SSH.
<zamfofex>Running ‘ssh -vv ...’ says it connects using ‘none’ as the authentication, which I think is meant to differ from ‘publickey’ which Guix tries to use.
<zamfofex>I wish I could debug this more carefully, but I don’t know what I’d need to do.
<nckx>Maybe you already know this, but have you tried connecting with sudo -i youroffloaduser@ssh first, and accepting the host key?
<anadon>nckx: Can I get an ETA for 54630 ? I'd like to avoid straying from origin/master, even if it ends up being just a little. Sorry to be a bother. I want it in so I can get the C++ runtime for the Antlr4 package in.
<lilyp>anadon: Did you not receive my response to your patch?
<lechner>unmatched-paren: About pkg-config in Linux PAM, Guix would need a newer PAM release. I built and use it locally without issues after just updating version and hashes. Is a diff to -patches the way to go? Thanks! http://ix.io/3YTI
<anadon>lilyp: Nope! Like last time, some emails seem to have been just dropped. I'm reading it on the debbugs page now.
<emacsomancer[m]><KarlJoad> "Is there an IRC bouncer already..." <- KarlJoad: Weechat?
<anadon>Strange. Well, on to version 3 of the patch. Crud.
<KarlJoad>maximed_, wdkrnls: There is not a shepherd service already defined for Emacs. You will have to write your own if you want that.
***Xenguy_ is now known as Xenguy
<anadon>lilyp: Response sent. Can you confirm receipt? IDK why emails are being dropped like they are, but so long as they are I'll try double checking in here.
<pashencija[m]>There's a function, that runs make-u-boot-package with special params and returns a directory in a store with uboot files(let's say `/gnu/store/ry78hc0jkpsp834ngcpl2mz52wjhj3jx-u-boot-rpi-4-2022.04/`)
<pashencija[m]>There's a file `/gnu/store/ry78hc0jkpsp834ngcpl2mz52wjhj3jx-u-boot-rpi-4-2022.04/libexec/u-boot.bin`
<pashencija[m]>I want to take that file in a gexp to store it in some directory (I run that gexp as partition initializer)
<ardon>I'm trying to invoke `guix deploy' on a VPS with a barebones Guix ISO and openssh-service enabled, but I get this error back when sending store items to the server "error: preallocating file of 170413 bytes: No space left on device". Is this a memory error or a storage one? It's a 1GB RAM 25GB SSD cloud instance.
<ardon>^ Also, is this referring to my local system or the remote?
<ardon>Ah ok, it's the storage space. Now I'm in sort of a dilemma though, the ISO's storage is too small to invoke `guix deploy' on the instance and reboot to a full Guix system, and the VPS' RAM is too limited to run `guix system reconfigure' on it.
<maximed>(I don't know when tmpfs is used on Guix)
<yewscion>Hi Guix, quick question: What is the canonical way of setting $CLASSPATH for java under Guix? I'm tempted to just export the variable in my .bashrc to point to my current profile, but that seems a bit clunky to me. Is there another way more canonical to Guix?
<singpolyma>yewscion: some package hopefully has that as a search path. I would hope the Java/jre package?
<nckx>sneek: later tell maximed (if they care) ix.io works fine here too (TN), but I'm a business customer with a reputation, soo... I'd send them an e-mail just to hear their excuse if it were blocked for me.
<yewscion>singpolyma: I am looking through the source for such a package now. I have `icedtea:jdk`, icedtea:doc`, `ant`, and `maven` installed in my profile, though, and it is does not appear to be set (unless I've done something incorrectly).
<yewscion>(FWIW, it is not listed in `~/.guix-home/profile/etc/profile` either.)