<dp0>Hi, I'm trying to install guixsd on a VM using the GUI installer. I'm seeing the progress bar for some packages moving super slow. Specifically "libqmi" and "guix" so far. Is that common?
<dp0>It's weird. libgphoto (1.2MiB) is about the same size as libqmi (1.7MiB) but finished downloading in a couple seconds.
<vagrantc>been using guix plenty long now, and still surprised ... installing a package installs the gnutls-*-doc package?
<bjc>i know there have been complaints about the unicode progress bars, but i like 'em
<kraai>Hi. Why does `guix build firstname.lastname@example.org` appear to work whereas `./pre-inst-env guix build email@example.com` prints `guix build: error: failed to evaluate expression 'firstname.lastname@example.org':\nUnbound variable: email@example.com`?
<kraai>Sorry, the error message with `pre-inst-env` is `guix build: error: rust: package not found for version 1.65.0`.
<mirai>so the bot suffers from some kind of allergic reaction?
<mirai>the theory seems to check out given the '#<&irritants irritants' message
<Rampoina><civodul> "Rampoina: "guix shell" is..." <- I know about guix shell, I was asking specifically about phases commands because of this.
<Rampoina>As far as I can tell (I haven't had time to try yet) it doesn't let you run phases at all? It's unclear to me what you do once you're inside of an environment with `guix shell --development X` . With the Nix command, one inside you're able to easily download the source, compile it and install it with those commands (although imo this is still lacking a command to make a package with the current change and install it). How do you do the equivalent
<apteryx>AwesomeAdam54321: the postgresql trick work to start it in the build container, but the application (ruby-pg or ruby-activerecord) still seems hard-wired to want to task to a socket under /var/run/postgresql :-/
<apteryx>hm, a substitute server seems to be hanging connections
<jpoiret>Rampoina: no, there's no way currently to run phases once inside the shell
<jpoiret>I wonder how we could do that, for nix it's easier since they have a tighter control on what build systems do, whereas we basically have any scheme code that can be modified on the fly per-package
<jpoiret>sneek, later tell kraai: rust-1.65 is not a public (exported) variable so the guix command line tools won't find it
<Guest74>I need to edit /etc/libvirt/qemu.conf to add the path of $(guix build ovmf) so libvirt can use UEFI. I did not see anything related to that in the manual. Does someone know how? Basically I just want UEFI to work in virt-manager
<jpoiret>Guest74: it doesn't exist on your system yet, right?
<AgentKilo[m]>Hmmm, I tried that, and it produced the same hash as `guix hash -x -S nar ./some/dir/`, but not the "actual hash" printed by Guix either
<AgentKilo[m]>./some/dir/ should be the to-level dir that's cloned by git, right?
<bost>Hi. `guix lint <my-new-package>` reports 'can be upgraded to 1.5'. What does it mean? What should I do? The package version is defined as '(git-version "0.1" revision commit)' where the revision is "0".
<bost>next4th: One more thing: The https://github.com/mikenichols/railscasts-theme specifies no version, revision or anything like it. I use (git-version "0" revision commit) with revision "0" then `guix lint` complains 'firstname.lastname@example.org: updater 'generic-git' failed to find upstream releases'. What should I do about it?
<mirai>jpoiret: was this question ever raised before?
<unmatched-paren>we should have a rust-latest package, but adding that would be harder than it sounds
<unmatched-paren>the rust package is not defined as just (define-public rust CURRENT-RUST-VERSION)
<unmatched-paren>it has a lot of changes that basically revert a bunch of modifications we make to the rust-VERSION packages to make them slightly less of a pain to build ad nauseum, iirc :)
<next4th>bost: that's fine i guess, that just means the updater can't handle repo without a proper tag/release..
<unmatched-paren>(about the substitute: cuirass only seems to build packages that either (1) are public, which means they will be picked up by FOLD-PACKAGES, or (2) are used by a package which is, which would of course lead to it being built as a dependency
<davidl>Hi, without knowing when, or fully if, what would the requirements be reg. copyright etc. if I wanted to build a GuixSD derivative distribution? I considered maintaining some patches and mainly follow Guix master but with a lot more default everything, and probably some simple custom package GUI for package management, maybe some changes to the installer etc. What about keep using Guix
<davidl>rekado: I know your servers won't provide non-free stuff, but the burden of maintaining substitutes for everything, except some additional packages, is prohibitively expensive for a small derivative distro. I do have a channel already, mainly for packages. What are all the things I can possibly have in a channel? I might want to override the grub-service, and the default creation of files in the user's Home-dirs, and default init files for some
<davidl> software, and default packages for new users. If I can get all that in a channel, that might be sufficient.
<lfam>Hey rekado, do you have any idea how to create a TLS client certificate for using the Cuirass web interface on ci.guix.gnu.org? Apparently we lost the script mentioned in 'release.org'.
<Guest74>I configured via Guix home an alias for ls but it is not working. Do I need to restart my machine to take effect or what is the problem?
<rekado>but it’s the kind of boring thing that I cannot ever commit to memory
<jpoiret>davidl: you can't "override services" but you can create your own derivative services
<rekado>(it’s also the unintuitive kind of boring)
<jpoiret>but roughly you could do all of that in a channel yeah
<lfam>On guix-sysadmin, people are advocating for giving more people SSH access to berlin so that they can use the hardware, but I think that's the wrong choice. It would be great to get this safer method working again, rekado
<rekado>lfam: I agree. I find SSH access to the substitute servers icky.
<davidl>jpoiret: ok, do you mean like creating a service based on an existing service type, like (define-public special-cgit-service (service cgit-service-type (cgit-configuration ... ? That's of course a nice way to be able to do lots of stuff without messing with much normal Guix, which I like. However, I suspect it's not sufficient for what I want to achieve.
<rekado>sadmax: you need to extend the dbus-root-service-type
<rekado>the dbus-root-service-type is defined in such as way as to allow extensions
<rekado>comments in the definition say this: Extensions consist of lists of packages (representing D-Bus services) that we just concatenate.
<rekado>sadmax: I believe you can use simple-service for this
<rekado>if this works for you we could 1) add an example for dbus service extension, 2) update the cookbook entry to remove the deprecated use of the “dbus-service” procedure, and 3) mention the case when a dbus service already exists (e.g. when %desktop-services is used).
<rekado>sadmax: please also note that %desktop-services likely implies the use of pulseaudio; using bluez-alsa will likely not work as expected
<rekado>sadmax: the cookbook entry says “In the example below we [set] up a headless music server. There will be no graphical user interface, no Pulseaudio daemon, and no local audio output. Instead we will configure MPD with two outputs: a bluetooth speaker and a web server to serve audio streams to any streaming media player.”
<rekado>if you want to use a desktop environment I don’t think bluez-alsa is the correct choice