<theo_>Hi -- I've installed the Guix package manager on OpenSUSE, I've installed GNU Icecat with it, and it runs, but the font is just github icons, like every character is a github icon. Also, guix pull results in an error: Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
<theo_>guix pull: error: Git error: the SSL certificate is invalid
<lfam>theo_: The Icecat font issue means you need to install some fonts, if I remember correctly
<lfam>theo_: The certificate validation issue shouldn't happen... That should just work. But, you could make sure to follow the instructions regarding X.509 certificates in the manual:
<kondor>What do you do if you need to modify `/etc/services` ? Do you make a custom version of `net-base` package?
<lfam>kondor: I suppose! I don't think I've seen this asked before
<kondor>lfam yeah, my solution would be, create a package variant of net-base, then crawl through all the required packages, substituting net-base as an input with my own package. All this to add a single line of text to that bloody file. I am sure there must be a more elegant solution.
<kondor>On the other hand, i could eval a new package definition of net-base inside the admin module. I guess that would take care of the dependant packages, too
<kondor>This is a weak point of Guix. Simple changes are not simple (unless I'm blind to obvious solutions -- entirely possible) :)
<lfam>I think we would need to create some configuration interface for it
<lfam>Maybe there is another way to affect it, not sure
<shcv>hello; how do I configure elogind so that it doesn't suspend on a timeout?
<shcv>I've set up a computer with desktop-services that I mostly want to use as a headless machine
<shcv>I'm slightly confused because the docs say the default idle action is 'ignore'
<OriansJ>shcv: if your goal was headless why did you install desktop-services? elogind never has to be on your machine at all.
<xelxebar>Not OP, but I've been forced to install elogind because dockerd apparently requires it :/
<OriansJ>was docker because of a preference or a technical requirement?
<OriansJ>as lxc and kvm/libvirt are options in guix
<awb99>How can I find out why a specific package ends up in /gnu/store that I get with a GUIX docker build? I see lots of duplicated packages and and also lots of different version numbers.
<dftxbs3e>awb99, you can try to use the guix graph command, but I don't think it can generate graphs for manifests or operating system configurations.
<dftxbs3e>Duplicated versions are normal, some times packages depend on different versions of some other packages so we have to package both.
<procra>hi, I got an error when try to export a org file to PDF through latex. if I compile on termina the pdf is produced with pdflatex and lualatex. And I use exwm on emacs.
<mothacehe>fnstudio: "guix system vm" spawns a VM that shares the host store using a RO mount. To be able to use the store in a VM, you should use "guix system image -t qcow2" that will in turn return a VM image.
<dftxbs3e>cbaines, that page is monitoring for one of the powerpc64le-linux agents (the one at my home)
<nckxv2>dftxbs3e: Does it sound more like me to completely blow up my laptop's rootfs by playing kernel dev, then have to borrow $partner's to SSH into my Guix mail server to build a rescue ISO that can read bcachefs?
<dftxbs3e>nckxv2, oopsie.. it sounded a bit emergency the kiwiirc
<fnstudio>mothacehe: right, what if i still used "guix system vm" but i added a --shared option to let the VM home be rw, then i could start jupyter as a user and the guix write operation would happen in the rw shared home?
<dftxbs3e>nckxv2, is bcachefs any good? Also, is it available on GNU Guix?
<nckxv2>dftxbs3e: It's still in development but far more stable than btrfs at the same age. I don't blame it for breaking after I corrupt its page cache. No, no Guix support at all (apart from adding bcachefs-tools). You need a patched kernel, I haven't tried merging it + Linux-libre.
<nckxv2>You also need a separate /boot which, at least recently, Guix System did not support OOTB.
<efraim>dftxbs3e: we could try the mtime thing first. One option is after the 'patch-cargo-checksums phase to add a phase to read the mtime from one of the Cargo.toml files, add some amount of time, and set the mtime of the compiled artifacts we've carried from the previous build(s)
<efraim>I don't know enough about using rustc inplace of cargo, but I do like that idea better overall
<kondor>Services that depend on packages ... where do those packages end up in -- the system profile? Does that mean that if I explicitly install a package in the system profile, they'll use that?
<kondor>Like, I see how to substitute inputs for packages which I control (by installing them in various profiles), but I don't know how modify dependencies of the services (such as, eg inetd)
<nckxv2>kondor: The packages end up in the store, that's the only guarantee. They are then called with an explicit store path. Some services -- and I am not a fan of this trend -- also propagate [some] of these dependencies into the system profile ($PATH etc.) so you can e.g. invoke cups tools without adding cups to your system packages, only the
<nckxv2>service. But what you describe (services calling binaries from /run/current-system instead of /gnu/store) is not done.
<nckxv2>kondor: Some services offer package fields: (cups-service-type (cups-configuration (cups-package my-custom-cups) ...)) but it's an ad-hoc thing.
<kondor>nckxv2 mu problem is that i need to add additional entries to `/etc/services`. Now, i think this gets cared of when i extend the `netbase` package in `admin` module. However, i guess that populating systems `/etc` is done by some (low-level) service which depends on the unmodified netbase. How am I supposed to avoid conflicts?
<nckx>lf94: Ansible is an automated button pusher that turns a (say) Debian system into your Debian system by turning knobs. Guix deploy installs Guix System. If the VPS supports only some hard-coded (say) Debian kernel, it won't work.
<lf94>nckx: yeah that's the gist of what I understood
<jlicht>with a relocatable `guix pack`, how does one 'activate' the profile variables (such as PYTHONPATH)?
<nckx>lf94: I'm no expert on either, but it doesn't sound like it if you're not (yet) willing or able to switch to Guix System wholesale. Nor can I blame you, as you sad deploy could use some maturing.
<kondor>lf94 take a look at linode server provisioning in the guix cookbook. Forget about the debian part, just take the system config script, you can even replace the bootloader with something superstandard. Build the image with vm-image and it'll run in qemu
<kondor>The next step would be to upload such image to a vps system
<nckx>iis: To do what that article describes you'd add a file-system entry to your operating-system's file-systems field, which is Guix System's equivalent of /etc/fstab. I think (device "<UUID here>") just works <https://guix.gnu.org/manual/en/html_node/File-Systems.html#File-Systems>. It won't mount ‘any’ USB device, though, only that exact one, and only if it's present at boot. If it's not, I'm not sure that Guix handles it well! Be ready to roll back.
<nckx>charmonium[m]: Might depend on whom you ask. We have a slight preference for git repositories at the moment because they are archived by Software Heritage, but only if the trade-off (extra inputs for bootstrapping, etc.) is reasonable.
<nckx>We used to have more of a bias towards bootstrapped release tarballs.
<nckx>Making sure that Guix can build the ‘raw’ development sources from git has some advantages for users. It's arguably the preferred form of modification.
<charmonium[m]>Interestingly the MediaWiki tarball contains all of its pure PHP dependencies but the git repo just has a version lock file.
<nckx>Using such bundled dependencies in Guix packages is strongly discouraged.
<nckx>charmonium[m]: Yes: ‘git clone <URL>’ and ‘guix hash -rx <directory>’.
<kondor>nckx well, i don't know, i ran .. `guix system vm-image --image-type=.. -c8 config-script.scm` this usually downloads substitutes. I think I remeber a previois build failed with a TLS error. When restarted, it started compiling everything from source.
<kondor>sundbry thanks! We should collect different configs into a central repository.
<mdevos>Maybe the automake and libtool package itself actually need autoconf-wrapper? I don't think any other package actually needs it
<mdevos>nckx: writing a patch should be easy. Something like sed s/"autoconf" autoconf/"autoconf" autoconf/wrapper/, but with proper quoting (or the other way around)
<mdevos>I can do this right now, but I just need to know which colour to paint the bikeshed
<nckx>It's not about the effort (indeed trivial) but the churn and what we'd gain from it.
<nckx>I'm all for not confusing new users (which often learn by imitation), but that might not be enough.
<mdevos>nckx: benefit: consistency accross package definitions (except the special cases where one or the other is really needed). con: package rebuilds, accidentally breaking something!!!
<mdevos>as a naive confused user, I prefer consistency. But maybe guix maintainers know a good reason not to make this change.
<nckx>My ‘preparation’ question above was because I thought you might be pushing for /bin/sh-less builds, which would be interesting, and because without such a goal you might not get past the ‘churn’ objection. (One could suggest a scripted reindation of the entire code base for consistency, too...)
<nckx>*Apart* from that, I do think -wrapper is the right thing.
<mdevos>I thought /bin/sh (and /usr/bin/env) doesn't exist in the build environment? Or am I wrong here?
<mdevos>also, I don't think the comparison with reindenting all the source code is appropriate here. Indentation is purely cosmetic (except for the rebuilds that would result because of change in hash in guix/build/*.scm), ...
<nckx>If you want another (if also minor) problem: there are several packages that have to jump through a little hoop to keep upsteam's ./autogen.sh from calling ./configure, e.g. by setting NO_CONFIGURE. That would go away.
<roptat>what you can do is create a separate module, say (guix build phpize) that exports this procedure, and import in on the build side with #:modules (or is it #:imported-modules, I'm always confused)
<roptat>or simply inline the function in the package definition
<charmonium[m]>@roptat: Ok. Is this the conventional way of reusing a phase?
<roptat>you mean you have this phpize in multiple packages? if so, creating a separate module is the way to go
<roptat>if it's used only very locally in one or two packages, then don't bother and inline it
<charmonium[m]>@mdevos: I've quoted `(invoke "phpize") and I've quoted `phpize-phase, and it's still giving: Unknown # object #/<
<roptat>yeah, because you can pass the procedure to the build size that way, you need a module, or to inline it
<roptat>java-junit would be an example of a package that uses a procedure declared in a separate module
<roptat>(note that the module in question is already imported by the build system, so we don't need to change #:modules or #:imported-modules)
<lf94>This makes me think: we already do this with apt.
<lf94>We have a apt repository for our custom software
<Sharlatan>I would say from DevOps point of side - our dev team use bandle liek brew -> insall asdf -> asdf install python -> asdf install poetry -> poetry install packages -> poetry make requirements -> pip install requirements
<lf94>Then I think: well we use a VPS to deploy to, which uses a custom debian image
<guix-noob>all right, looks like it is the keyboard causing the trouble
<lf94>So how does guix help here...Well, guix deploy would deploy a "custom image" each time