<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
<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.
<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 email@example.com, 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
<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
<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.
<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