<lfam>I spent some time banging my head on the shell last night
<nckx>There really isn't a difference *if* your shell is POSIX/sane. I'm with lfam that, if there's a reason apart from cargocultation (used in 97% of shell scipts™), it's to work on a shell that's not.
<mroh>ne1 knows how to get the webrtc gstreamer plugin working? `gst-inspect-1.0 webrtc` -> No such element. It seems to be in gst-plugins-bad somehow, but not as a gstreamer module (which are in lib/gstreamer-1.0), but as a sharedlib with pkgconfig etc (in /lib).
***catonano_ is now known as catonano
<apteryx>lfam: you are aware there's such an example in the Guix manual?
<apteryx>A mcron job named %battery-alert-job, in info '(guix) Scheduled Job Execution'
<lfam>I forgot about that! I should use it on my Guix System laptop
<vagrantc>well, couldn't figure out how to trick the debian package to use the system guile instead of bootstrap-guile and various other bootstrap-* bits, but ... i've essentially disabled ~150 tests ... we'll see if i missed anything soon
<vagrantc>it's particularly annoying when tests/*.sh fail; it seems to not bother to run all the other tests in some cases, then.
<vagrantc>hrm ... or a test backtraces and leaves no meaningful log :/
<apteryx>vagrantc: are you running the tests in parallel? that's known to cause problems
<vagrantc>apteryx: i'm running the tests without access to bootstrap binaries :)
<vagrantc>apteryx: parallel doesn't seem to change the results, from what i've seen ...
<vagrantc>and i was assured that running tests in parallel was also supported
<Loker32>what System requirements? cpu? ram? Storage?
<SebPastor>Hello guys ! I am very new to GUIX. I ve installed in over Alpine Linux my daily driver.
<SebPastor>So far so good ! I had one question though. Trying to install an upgrade of Chromium, I have the feeling that the package is being build while I have authorized substitute
<SebPastor>I am expecting binaries only. Or maybe it is not always the case ?
<brown121407>SebPastor, the substitutes may not have been yet built on the build servers. You can check their availability with the "guix weather" command
<SebPastor>Thanx brown121407 ! Does it mean that if I installed using a local build my next upgrade of the same package will need to be built as well?
<brown121407>Nope, as far as I know. Whenever you tell Guix to upgrade or install stuff it first checks for substitutes. If the next time you want to upgrade the package it is available from the substitutes server, it will be pulled from there, regardless if you previously had to build it
<SebPastor>thx ! it clears things a bit. I have another quiestion (sorry I am just discovering the Guix world). I am confused about which GUIX_PROFILE I should use
<SebPastor>as sometimes the guix command hint refers to ~/.guix-profile
<SebPastor>and other times it points to ~/.config/guix/current/
<brown121407>SebPastor, my GUIX_PROFILE points to ~/.guix-profile, but I use Guix System. I don't know how it should be on foreign distros.
<SebPastor>thx again .. maybe the hint is hard-coded and not suitable for when used on foreign distros then .
<brown121407>I have a Fedora install with Guix on it somewhere, I'll try to install some stuff on it to trigger those messages a bit later. If I discover something and no one has cleared this issue untill then, I'll ping you.
<db48x>SebPastor: it's my understanding that the guix command should come from ~/.config/guix/current and everything else you've installed should be in ~/.guix-profile
<SebPastor>db48x: yes that seems correct ..when looking at the content of the folder. still not sure where to point my GUIX_PROFILE. In the doc (Binary installation) it points to ~/.config/guix/current
<SebPastor>but guix pull commands hints to point to ~/.guix-profile
<SebPastor>Well ... now I just re-run a guix pull to try to make a point :) but it gives me 'hint: After setting `PATH', run `hash guix' to make sure your shell refers to `/home/spastor/.config/guix/current/bin/guix'.
<SebPastor>'and funny enough if I run guix pull, the hint I have is
<SebPastor>the other pb I am facing as newbie, is : just installed qutebrowser ok tried to upgrade it. Now qutebrowser is broken. (I guess the package is faulty somehow). I tried to install previous version but it seems the only version available is 1.14 the latest
<SebPastor>Tried to rollback .. but qutebrowser remains at the latest version.
<SebPastor>Probably a lack of understanding from my part.
<jonsger>efraim: I would rather skip it. If someone needs it, it can be added as output again...
<efraim>not always as easily said as done. I was going to test newsboat with a libcurl static library. I know I can inherit it and change it but I wish it was already ready :) Although I do like not needing to download it anyway for grafting all outputs.
<user_oreloznog>roptat: congrats for the translation of the guix-manual and others! I will help again when I have more time
<roptat>user_oreloznog, we always need help proof-reading :)
<efraim>I think I fixed sbcl-cffi-libffi on aarch64 and armhf
<nckx>PotentialUser-43: However! Don't get your hopes up. By far the most effective way to get something packaged in Guix is to start yourself. If you get stuck, post your work to firstname.lastname@example.org. People are far more willing to help you than to work for you.
<apteryx>which would have streamlined the disk image code a bit
<apteryx>but it turns out it's not technically feasible. Having a rather large bios-grub partition doesn't change the fact that the machine BIOS will only support loading a file which is at most 491520.
<apteryx>so, let's wait a couple years for BIOS machine to become extinct and revisit the issue ;-)
<maav>apteryx: IIUC, the modules there only have to be the needed ones, and the operating-system object should already have some info like that (partition type, crypto, and so on)
<joshuaBPMan>apteryx I was going to say, please continue to support BIOS machines, but then I remembered that my BIOS only laptop is librebooted, so grub is already loaded in the laptop.
<joshuaBPMan>I think they support grub as a payload in the flash memory.
<joshuaBPMan>maybe the wiki calls it the "ME" flash memory, if my memory serves me right. Man that was a tough weekend project to libreboot my T400.
<joshuaBPMan>I wouldn't have been able to pull it off if one of the main developers hadn't spent 2+ hours coaching me through the process.
<apteryx>joshuaBPMan: coreboot/libreboot support something better than i386-pc
<apteryx>see info '(grub) Core image size limitation'
<maav>apteryx: btw, doing some tests 'grub-mkstandalone --compress=xz --install-modules="luks part_gpt" --fonts="" -v -O i386-pc -o dest.img' could be a starting point, but this depends on the machine where is installed as you can see on the output
<nckx>PotentialUser-39: That file is provided by linux-libre-headers. Is it a native-input?
<apteryx>civodul: hello! I've been working on making it easy to run 'guix system disk-image' on the examples we have that rely on the bootloader-efi-grub, but I'm still having a problem. In the meantime you can hack the os definitions manually to 1) switch them to use bootloader-grub 2) remove the EFI file system
<apteryx>then disk-image -t qcow2 should give you something to play with in a reasonable amount of time
<nckx>PotentialUser-39: Well, we'll see. The reason I'm packaging it is ‘hm, I've never actually seen Eiffel, I wonder if it's fun’ so if things get hairy I might not get far.
<apteryx>but the --image-size doesn't work at least with qcow2 it seems, so you'll have to to with what it gives you ('guix install emacs-no-x' worked for me).
<nckx>PotentialUser-39: What do you have working so far?
<roptat>so I just had a chat with opam folks, and the author of opam2nix :)
<roptat>that was great, and i think I understand how opam2nix works now
<roptat>it's both an equivalent to our importer, and a build-side ocaml library that uses opam to build packages
<roptat>Tim doesn't use it to import packages inside nix-packages, it's only used as a way to "snapshot" the opam repository and build the dependencies of a package with nix instead of creating an opam switch
<roptat>so I'm thinking we could package opam2nix (at least the build-side part) and use it in the ocaml-build-system. That way, I think it will make the importer work a lot better (less need to manually fix packages, since we would use the "source of truth" which is the opam file, instead of trying to guess the correct sequence of commands)
<roptat>once we have this, we could also have use the importer to generate a manifest, or import a build environment from an opam file dynamically, without using the packages from guix
<roptat>though that's a bit risky, as we would not be able to check the licenses, and everything
<civodul>roptat: yeah that brings us to the more general topic of invoking importers "on the fly"
<civodul>which i think could be interesting but has caveats
<civodul>i think it's something we should look at from the POV of importers in general