<fnstudio>singpolyma: well, i'm interested in understanding how the process work on the guix side more than in any specific vendor... so the answer is no, it doesn't... that said, DO would be a bit more convenient for me as i have an account there already
<lechner>and here is the package definition (the source distribution is still incomplete) http:/ix.io/3ZkA
<daviid>lechner: nota guix user, but that is a bash command not founderror
<lechner>daviid: thanks! (although i would be surprised if autoreconf was not part of gnu-build-system)
<daviid>for some reason, the env that is trying to build your guile-pam instance can't find autoreconf, i think, not sure but ... worth investigate that symptom
<sammm>hey - extreme guix newbie here, I wanted to use the service module that has been proposed here https://issues.guix.gnu.org/54561#29. I tried making my own channel and moving the patched modules to it but alas, getting guix pull errors. What's the easiest way to use these patches on my system?
<apteryx>sammm: I'd apply the patch to a git checkout of guix, build that following instructions in the manual, then try './pre-inst-env guix system vm your-config.scm' or 'sudo -E guix system reconfigure your-config.scm' if you're brave
<apteryx>perhaps you could try to build it on machine in a './pre-inst-env guix shell -D guile-pam' environment with export COLUMNS=400
<AwesomeAdam54321>It appears that my segfault problem the other day was caused by enabling the Captive Portal setting in IceCat
<char[m]>Very interesting: If you remember I was having trouble with compiling guix. I was being told that glibc is unbound and that I should include module (gnu packages base) even though it was alreay included. I moved my code to a different file outside of guix source tree) and everything is working now.
<fnstudio>i've been reading a bit re cloud-init, following some initial attempts at building a guix image that could work with a particular hosting provider
<fnstudio>i've gone through the stages: oh this sounds easy, there must be a package for this already; oh wait, no, it's more complicated that i thought; to finally realising that it's something we may not actually want... as also highlighted here https://logs.guix.gnu.org/guix/2016-11-30.log at some point in a convo re EC2 images
<roptat>so, maybe it's because SAX_FEATURE_EXTERNAL_ENT is now set by default
<roptat>184.108.40.206 is more like a completely new version, the change to set it by default is from almost a year ago
<ardon>Hi Guix! I constantly get this error "Channel opening failure: channel 66 error (2) open failed" when invoking `guix remote', although at times re-running the command will make it work. I have a clean SSH config, is there an option that would alleviate this?
<Haider>Hello!, I got a very (nooby) question. I have mounted my seperate drive in Guix using the file-system field in my Guix operating-system decleration. My user account cannot create files in the mountpoint directory, I probably could use chmod but is there like some sort of property allowing you can do this in Guix system-configuration?
<roptat>more unsupported features... I'm afraid there's nothing I can do
<roptat>other than using jdom 2.0.6 instead of 220.127.116.11 for maven
<jpoiret>(display glibc) works fine if i just add it at top-level
<jpoiret>if you do ./pre-inst-env guix repl and then (@ (gnu packages base) glibc), does it work?
<char[m]>jpoiret: That is what is extra strange, it would sometimes work for me too. Usually after some combination of `make` `make -B` `make clean` and maybe a `make make-packages-go`, it would become broken.
<pashencija[m]>So the question is: how to debug it? How to understand what exactly fails guix pull?
<pashencija[m]>What happens to guix pull when I add a channel with packages that I have not installed yet?
<fnstudio>i seem to have been able to create a guix image which i then uploaded to a hosting provider and used to spin a VPS... pretty amazed and very happy!! i can see many guix servers in my future ahah!!
<nckx>fnstudio: I've not used writable Guix 'images' but yes, that's what it does.
<fnstudio>related to this (but probably less related to guix), out of curiosity, now that i've started this machine that has a micro 1.5GB root partition, is there a way to increase the partition size from within the machine?
<fnstudio>nckx: amazing, thanks, i'm currently creating the new image, i'll try to upload it to my hosting provider in a min, thanks!
<fnstudio>pashencija[m]: ah amazing, great stuff, will try that in a sec
<fnstudio>pashencija[m]: hm wait, on the live system?
<nckx>Probably not. You could resize the partition, possibly reboot, and then resive the root fs, but the 'from within' isn't possible on most file systems. You'll need something like the Gparted live CD to do it off line.
<char[m]>What is even stranger is this: 1. branch to master, make, no problems. 2. branch to ghc-toolchain, make, no problems!? 3. ~/guix/pre-inst-env guix shell ghc toolchain: tcc unbound, and many other totally unrelated unbount variable errors like googletest and ffmpeg.
<jpoiret>hmmmm, usually you want separate worktrees for branches that differ substantially
<tribals>I'm experimenting with my own channel. I created GPG key, updated `.guix-authorizations` with that key, then committed just changed `.guix-authorizations` into new "keyring" branch, signed off this commit with that key, ran `guix git authenticate` to verify that everything glued together, and then finally, updated channel's `(keyring-reference ...)` to point to just created "keyring" branch and committed `.guix-channel` (signing it with same key) to my
<tribals>channel's main branch (581025b27e). All this worked as expected. Then, I added some new commits (all signed) in new branch, then merged (--no-ff) this branch into my channel's main (0e9b4bce09). Then, I tried to use just created channel in a manifest as an inferior channel, using proper channel introduction which authenticates commits starting from 0e9b4bce09. For some reason, that didn't work with error: commit not signed by an authorized key. Why?
<KarlJoad>It's also weird, because I update the master branch of the repo, but not the hash of the build file, and I build the old version of master that the sha256 hash _does_ match.
<roptat>tribals, when you merge a branch, you lose signature on commits
<tribals>I tried to sign it off explicitly, using `git merge --no-ff --signoff`
<tribals>Correction: I used channel with introduction starting from (581025b27e), not (0e9b4bce09)
<tribals>*But*, `(channel .. (commit ...))` points to (0e9b4bce09).
<jpoiret>KarlJoad: if you don't use file-name in origin that depends on the commit, guix won't try to download the file because it already has a file with that name + hash
<jpoiret>you could just falsify the hash temporarily
<tribals>I've seen some branches in main guix repo. How commit signing is preserved in, well, guix repo? (then)
<jpoiret>about TOFU, you can just do `guix build -S the-package` to check out the downloaded source
<roptat>not sure how it works in guix, it's probably resigned?
<char[m]>upon a fresh git clone of my ghc-toolchain branch, I still get tcc unbound variable.
<roptat>tribals, --signof doesn't sign with gpg, it's just adding "Signed-off-by ...", right?
<jpoiret>char[m]: maybe there's a bug with that branch then
<KarlJoad>jpoiret: Ahh. I just found an example of file-name. That would do it. Thanks.
<tribals>roptat: I may be wrong, my merge-commit is signed, which is confirmed by `git show 0e9b4bce09 --show-signature`.
<KarlJoad>How should I go about finding a latex package that I know exists (texlive has it), but I cannot find the package name in guix? the tlmgr info trick does not work because the package name is correct and not part of some larger package.
<KarlJoad>One way I can think of is to use a full store path to get back a package name.
<civodul>i wonder how other syslogd implementations and journald deal with syncing
<KarlJoad>civodul: That is what I have been doing. chngcntr is present in the full texlive, but I cannot find a Guix package that provides it. Using tlmgr info chngcntr returns the package name chngcntr.
<KarlJoad>There are other LaTeX packages that have similar issues, like nth.
<nckx>(And the daemon isn't ‘the meat’, it's really quite tiny in the — oh dear, I didn't go here on purpose, promise — grand scheme of Guix.)
<johnjaye>i'm quite jaded and cynical as you might guess. today I realized the raspberry pi getting started has 0 information about configuring lxde. worse, the lxde doesn't even have a manual. more of a wiki
<unmatched-paren>johnjaye: Guix is configured via scheme code too. All the package definitions are in scheme. The system config I linked to is in scheme. You can configure your dotfiles and user's packages with scheme if you want.
<unmatched-paren>the command-line interface is scheme. you can write external scheme programs that call into guix's modules.
<unmatched-paren>and then add `(gnu packages emacs)` to the use-modules in ~/.config/guix/home-configuration.scm, add the `emacs` package to the `packages` list, and `guix home reconfigure ~/.config/guix/home-configuration.scm`
<unmatched-paren>then run `sudo guix system reconfigure /etc/config.scm` to upgrade the system, and reboot
<unmatched-paren>if something breaks you can roll back in grub, which is really nice to have
<unmatched-paren>because of the way guix works, we can do that. traditional distros generally haphazardly replace libc, linux, etc with no way to revert it. in guix a new profile is created, then the current profile's symlink is atomically replaced with the updated profile
<hunger>i was using hello as a base but now im getting that 'foo' unkown package unmatched-paren, and when i was doing that invoke command it gave me a huge error, but tbf i was doing it inside (arguments)
<unmatched-paren>it basically evaluates the file you give it, then creates a new system following the operating-system declaration it evaluated to
<unmatched-paren>johnjaye: if my computer suddenly dies, all i need to do to replicate my system on the replacement machine is install guix system on it, install git and clone <https://git.sr.ht/~unmatched-paren/conf>, then run `./reconfigure && ./reconfigure system` in the conf directory
<unmatched-paren>obviously my code etc will need to be recovered from git.sr.ht, but my setup will be there instantly
<johnjaye>it sounded to me like you were saying use a certain command if you want to be able to back up your guix config to another distro where guix is just the package manager. as opposed to guix being the OS
<foobarxyz>roptat: thanks! Is there a guix convention what should go into a package's lib/ and share/ directories (which will end up in the profile as such), or is it up to the package to define how to structure its output files?
<wdkrnls>Don't I have to boot from a live usb to do that?
<roptat>foobarxyz, it's up to the package, all the files end up in the profile. But remember that only *explicitely* installed packages end up in the profile, not their dependencies
<unmatched-paren>i think i've heard it being used to install to VPSes by installing a debian, installing guix on it, and running `guix reconfigure` to turn it into a guix system
<unmatched-paren>a guix system is just an OS that is configured using the `guix system` command
<roptat>wdkrnls, it might work if you remount your root fs ro
<foobarxyz>roptat: I see thanks, this is an important point (wrt *explicitly* installed packages)
<roptat>on most distros you would get access to dependencies, not on guix. You only get what you ask for
<unmatched-paren>hunger: you don't actually need the (lambda* (#:key ...) ...) stuff.
<wdkrnls>the ubuntu shutdown command has a way to force a fsck on next reboot, does guix have anything like that? I didn't see it in the options for shutdown, but I thought I would ask because maybe its somewhere else.
<johnjaye>i ran the command 'guix system reconfigure /etc/config.scm'. it's spitting out warnings about how targets is deprecated use targets instead. cannot determine provenance for the current system.
<lilyp>alternatively, you can try finding all the store items with size 0 and guix build --repair those (though that's an underapproximation)
<wdkrnls>well, I suppose it doesn't hurt try it for the one thing emacs depends on.
<unmatched-paren>djeis: (substitute-keyword-arguments OLD-ARGUMENTS ((#:KEY OLD-VAL) NEW-VAL) ...) for each KEY/OLD-VAL/NEW-VAL finds the value of KEY in ARGUMENTS and binds it to OLD-VAL inside the NEW-VAL expression