<patched[m]>Is it possible to define a package to be the same as another one, but simply with the git repo being switched out? I'd like to do this for custom configurations of suckless software. <lechner>Hi, how can I find the sshd_config file that's being used, please? <mekeor[m]>patched: (define-public foo-custom (package (inherit foo) (source ...))) <vagrantc>lechner: it's probably in the running process tree ... e.g. pgrep -l -a -f ssh <mekeor[m]>patched: by the way, did you know that the members of the suckless community are suspected to be far-right, nazi-alike extremists who name their servers after hitlers last bunker and do nazi-alike rituals etc? <vagrantc>lechner: not sure how to find one that *would* be generated, though <patched[m]>mekeor[m]: they can be drinking the blood of babies for all I care, software still good tho <lechner>vagrantc: thanks for the idea, but neither fgrep nor herd status worked <mekeor[m]>lechner: ps aux | egrep -o '[^ ]+sshd_config' <lechner>yes, but it refuses connections on ipv6 and does not negotiate via GSSAPI <mekeor[m]>patched: well, maybe you want to make sure you only use suckless-software of which you read the source code :D <mekeor[m]>lechner: so you still didn't find the sshd_config? <vagrantc>curious. i swear i used to be able to find the config with pgrep ... ***rekado_ is now known as rekado
<EMax`0Mancer[m]>I don't think it's actually an emacs issue, but an `mu` issue - because the same buffers can display unicode characters, but however it's processing `mu`'s output is not outputting as utf-8 <vagrantc>lechner: yeah, that's pretty similar to what i see <vagrantc>would the change to the newish shepherd changed that somehow? <EMax`0Mancer[m]>yes, seems to be a `mu` issue. I get the same issue when I run `mu` on the commandline (and checking a different machine, `mu` on the commandline correctly outputs in utf-8) <djeis>So here’s something fun: I’ve got a box I just switched over to guix system, I’m running the standard desktop services, and I can run gdm+gnome just fine. However, if I put anything in .xsession my gdm login always fails immediately. It doesn’t even run the xsession file, which I verified with a dummy one which just touches a file in my homedir. <djeis>Actually earlier it seemed to get stuck launching the x server, but now it consistently drops right back to the gdm login screen. <djeis>Any suggestions for how I could debug this further? I’m reaching my wits end. <piethesailor>using guix as operating system, have emacs open and a sbcl sly repl. when (ql:quickload :lisp-stat) <piethesailor>I am getting an error about not having a series of libcrypto packages <piethesailor>Ive tried both guix install openssl and "openssl@1.1.1l" <piethesailor>had to pop off for a moment. hopefully I didnt miss a response ***f1reflyylmao is now known as f1refly
<nanounanue>Is someone using guix home? Mind to share configs? <jts>should I configure a WireGuard connection on Guix system using the service type or through NetworkManager? <Aurora_v_kosmose>It appears that emacs-mastodon has moved from Github to Codeberg & archived the Github repo. <lechner>Hi, where's a good place to install static ELF executables for software not yet packaged for Guix, please? <mekeor[m]><lechner> "Hi, where's a good place to..." <- maybe just create ~/bin and add it to your PATH? <lechner>mekeor[m]: thanks for the idea, but the software is needed to mount my encryted home directory <mekeor[m]>lechner: you can also just put it /some/where and then export PATH=/some/where:$PATH <jpoiret>lechner: you could write your own package for it and use it as any other <jpoiret>copy-build-system will be enough if it's just a static ELF <lechner>jpoiret: i used to package it in debian. should i create my own channel, and then submit it here if it works, right? <jpoiret>lechner: depends on whether you want to actually properly package it or not <jpoiret>to be included upstream, it should be built from sources <lechner>jpoiret: it would be, but i am too new here. right now, i am just migrating to Guix system <jpoiret>djeis: you can enable (debug? #t) in the gdm configuration <jpoiret>then, you'll get more info in /var/log/{debug,messages} <jpoiret>lechner: right, so in the meantime you could define a package that just downloads the prebuilt binary and copies it to the output <lechner>jpoiret: can i define it in my /etc/config.scm for now? <lechner>jpoiret: great! what would be a good place to start reading, please? <jpoiret>let me find you an example in the sources that might be more ... down-to-earth and digestible <lechner>jpoiret: thanks! is that acceptable for distribution? <jpoiret>it's just a bash script so no need to build it <lechner>jpoiret: i can't wait to try it. thanks for this great new OS! *attila_lendvai is very happy he found guix <meo>if this is interesting or useful to anyone, i worked out a way to zero-touch account provisioning in thunderbird <a13x5>So I decided to create some packages for Guix. Mostly devops tools which I need (mostly go code). So I bumped into an issue with go modules - I can't add phase with go mod download - its failing because network is not available. Does it means that the only option to manage go modules is to add them all to gnu packages golang? <a13x5>nix for example has a function buildGoModule which will download all go modules and then build artifacts <bjc>guix requires all dependencies to be explicit; you can't rely on a tool to download the entire dependency graph <bjc>so, yes, every dependency needs a package to be defined <attila_lendvai>a13x5, the current opinion of the maintainers is that vendoring is not to be supported, and all packages need to be imported into guix. the good news is that i'm just filing my patches to the go importer that will make it much more robust to automate this process. <bjc>i'd describe it less of an opinion of the maintainers and more that it's inherent in the way guix works. if the build phase were to allow a tool like ‘go get’ or ‘go mod download’ to work, it'd break reproducibility <bjc>although i suppose there could be a way to have a ‘go-mod’ origin to fix that <attila_lendvai>bjc, nixos does vendoring: uses the golang tools to import a snapshot of the transitive closure of dependencies into the store/substitutes, and then use it to build the actual app that is being packaged. <attila_lendvai>i'm not a go/guix expert, but i think this decision is much more derived from ideals than technical reasons. <bjc>maybe i don't understand how go module vendoring works these days -- it's been years since i've looked at it -- but how do they ensure that one of the imported module's dependencies hasn't changed? <attila_lendvai>bjc, whatever gets imported is captured into the store. a vendor hash is calculated, and it becomes part of the package. <bjc>say you're importing module a@1.0.0, but that includes b, without a version. if you download the graph to the store, you can ensure that today the hash is x, but tomorrow, if b updates, that'll change the hash, right? <attila_lendvai>i think golang's go.mod stuff is also reproducible build nowadays. the dependency spec is checked into the repos, and it fully specifies what versions to use. and it takes an explicit CLI invocation to update it. (i may be wrong here) <bjc>b needs to be pinned somehow to make sure you can repro the build. that's what i'm missing from ‘go mod download’ <bjc>oh, so it has an equivalent of .lock files from other systems? <f1refly>can i use the guix installation media on an efi only system? <f1refly>I tried booting a fresh flashdrive, but all it does is take me back to the bios' boot device selection <bjc>f1refly: i think it's supposed to, but i wasn't able to make it work in a virtual machine <bjc>a manual install should work, failing all else <f1refly>well, for that i first need a running system on that machine <a13x5>bjc got it I'll need to create go- packages for all dependencies. It's make sense for reproducibility, but I don't understand how guix will resolve situation when for example two packages will have dependencies on the same library, but different versions of it. <a13x5>attila_lendvai and what is the go importer you've mentioned? Because I had to run some sed/awk oneliner on go.mod file to get a list of dependencies which could be passed to inputs)) <f1refly>looks like debian boots fine. Hopefully the installed guix will boot from the harddrive <attila_lendvai>a13x5, but even without my fixes you may give it a try along these lines: guix import go -r --pin-versions github.com/ethereum/go-ethereum@v1.10.17 *attila_lendvai will force push that branch soon <f1refly>the laptop had force secure boot turned on, so that explains the issue <jpoiret>bjc: on a vm, you mean using qemu? if so you need to pass it an efi bios implementation like ovmf <bjc>jpoiret: yes, using qemu, but i set it up via virt-manager, which pre-fills things correctly if you tick the box to use efi. it's possible i screwed something up -- i only tried once, that i recall -- but i've definitely used this method to set up efi vms many times in the past <bjc>when i get some more bandwidth i'll try it again. there's a reason i didn't submit a bug report for it: i'm not sure i didn't mess up <jpoiret>i've only ever used qemu CLI, and it works <bjc>my guix instance is a vm until i can get zfs working with it <bjc>initrd-modules has been decidedly unfriendly, and my initial approaches all have shortcomings, so i'm taking a step back to try and find a better way to work things in <bjc>i think the best way is to add a keyword arg to ‘initrd-modules’ that'll take something that'll produce a path when lowered, which will be searched for modules in addition to the linux tree <jpoiret>isn't initrd-modules a field specifier of operating-system? <bjc>i can add another field, then <bjc>extra-initrd-modules-path or something <jpoiret>yes, you could also consider changing the semantics of (initrd-modules ...) <jpoiret>by the way, things that produce paths when lowered are exactly what guix calls file-likes <patched[m]>nvm, adding parentheses to the import seems to have solved it <bjc>jpoiret: my first take was to change the semantics of initrd-modules, but i ran into issues with variable lookup inside the build expression that i couldn't wrap my head around <bjc>and then, thinking about it more, i realized that for the recursive-module-dependency stuff to work with out-of-tree modules, i'd need to add another path anyway <bjc>like, if out-of-tree module x requires a linux module y, that needs to be captured, and the only way i can think to do that is to search all trees as if they're one hierachy <civodul>hey ho! i merged master in staging! let's revive that branch! <mekeor[m]>does anyone have a working config for hpcguix-web? e.g. the one used at https://guix.mdc-berlin.de - i wanna find out why my setup doesn't work. specifically, a 404 occurs for the /packages.json route. <mekeor[m]>civodul: maybe you know? because you seem to operate a hpcguix-web instance. <civodul>well, it's expected that /packages.json returns 404 the first time <civodul>hpcguix-web first has to build it, which it does lazily, on the first hit <civodul>if you run "guix processes", maybe you'll find that it's building stuff? <lechner>Hi, can the host-key field in (gnu services networking) be used multiple times (to exclude ECDSA)? <mekeor[m]><civodul> "yes" <- so is there a hard coded path where hpcguix-web operates? <f1refly>when i encrypt my root partition, but have my /boot on a separate partition, will guix ask me for my luks2 password on boot? <f1refly>Previously, I had my /boot in the same container as my root, so I was constricted to luks1 by grub <lechner>Hi, my local encryption is very restrictive. Does the guix daemon ever access the user's home folder (or if so, with a uid other than that user)? <jpoiret>lechner: the guix daemon itself doesn't access things outside off /gnu and /var/guix iirc <jpoiret>as long as the store is encrypted, guix will ask for your passphrase <f1refly>It asked me for the passphrase without loading the grub entries first, indicating that it thinks /boot is encrypted <jpoiret>oh, yes, GRUB also needs to unlock the store, because most of the files are there <f1refly>so there's no way to have a separated /boot, huh? <jpoiret>just that guix's GRUB needs more than /boot, it needs access to /gnu/store <f1refly>I'm mainly trying to avoid having to enter my password twice, the first time with a qwerty layout <f1refly>but that isn't possible then, because grub needs /store for that <jpoiret>i've personally gotten used to it :p <f1refly>I think I'll just encrypt /home and leave root unencrypted <lechner>jpoiret: yeah, thanks! it seems to work fine. i'm so thrilled <vagrantc>f1refly: i didn't think Guix System supported split /boot partitions yet <vagrantc>the problem is the way guix's bootloader configurations are set up they point directly to things such as the kernel and initrd from /gnu/store ... <vagrantc>so yeah, encrypted /home should work fine <vagrantc>i have vague memories that recent grub2 should support luks2 as well, though <vagrantc>(but maybe not all possible combinations of luks2?) <f1refly>there was an issue where it didn't work in guix i think <f1refly>i had some trouble with luks2 in the past because I didn't know it wasn't supported (yet) <lechner>Hi, it seem that plain dm-crypt mapping is not yet supported. Can a noobie help in that area, or are there systemic hurdles to that work? <f1refly>but that doesn't solve my problem regarding double password entry :) <vagrantc>right, still need to enter password twice <f1refly>plain dm-crypt wasn't supported when i tried setting it up a few months ago *vagrantc would usually prefer the tradeoff of entering two passwords over running an unencrypted OS <lechner>i encrypt users individually via overlay and then swap <f1refly>it's the conflicting layouts that kill it for me. double password entry for 32 characters would be annoying, but forcing that in muscle memory for qwerty kills it <lechner>but, the decryption uses the login password <bjc>if you set the bootloader's keymap it still defaults to qwerty for password entry? <f1refly>well, it depends if grub could load resources <f1refly>when /boot is unencrypted it uses your defined keymap <bjc>the keymap definition is in the grub.cfg, though, right? *that* should be loadable without unencrypting anything on an efi machine <bjc>is it in the esp, though? <bjc>and if not, a reasonable compromise might be to put it there? <f1refly>can i have an lvm in a luks volume on an lvm? <lechner>bjc: in my old setup on Debian the keymap was actually in /boot/grub (not EFI) but i also have grub.cfg in both places, so my setup probably worked by accident <lechner>f1refly: my recommended setup, the parts of which I'm hoping to contribute here shortly, is: Gocryptfs for each user (unlocked with pam_mount) and plain dm-crypt (non LUKS) with a random password for swap <f1refly>I have no idea what gocryptfs is and how to use it with pam_mount <f1refly>I think I'll just settle on having unencrypted root and putting home and swap into a luks2 with lvm inside <lechner>f1refly: is neo2 available in the official XKB symbol set? <f1refly>i don't know, maybe they just annoyed the xkb maintainers long enough <lechner>why do you ever type a password in QWERT? mode? <f1refly>because the windows login screen at work is QWERT only :) <f1refly>and when booting guix on the machine i'm currently trying to replace, because grub doesn't have a keymap config <f1refly>I'm currently running encrypted / and it doesn't <f1refly>is anyone here using fprintd by the way? I tried adding it to my system configuration earlier today and it failed building because it couldn't run some test I think <f1refly>I'll wait for the error to show up again so I can tell what it says exactly <gym_lover>hi can someone tell me about good practices after install guix. <mekeor[m]>lechner: puh, that's a lot of load on the pinkies for space <mekeor[m]>actually, my pinky began to hurt just recently :/ i need to find a solution #EmacsPinky <bjc>a keyboard with a thumb cluster <bjc>i have the older version of the top keyboard here: https://shop.keyboard.io/ (the model 100 hasn't shipped yet, but the form factor is identical) <singpolyma>I was sad they stopped the 01 but after their adventures I don't blame them <morganw>How does the Fn key work in practise? Do you just smush it with hand? <bjc>honestly, the palm key was a work of genius. it's my favorite thing about this keyboard <bjc>it's the kind of thing that, after you use it, you smack your forehead and go "how come no one else thought of this?"