<sophrosyne>yep looking through the logs it seems like this isn't the first time someone has brought up that you can't extend the home-fontconfig-service-type
<Kabouik>Any idea what could be wrong? https://0x0.st/oiw8.png This is `guix pull -c 2 -v 3`. I did that after trying `guix pull` and seeing stuck at the "check" stage ob "ruby-byebug" for several days. It's on a phone so I thought it could maybe be hours, but several days (and replicated 3 times to make sure) was weird, and -v 3 shows this issue.
<Kabouik>It's Guix package manager, not system. The system is Debian Sid (LXC container).
<dumbdemic[m]>nckx: lfam Thanks for the help! I got virt-manager installed in 5 min with the "https://guix.tobias.gr" substitute server. Building virt-manager from source was definitely not the move lol 😄
<cbaines>lfam, on bordeaux.guix.gnu.org, at least for x86_64-linux and i686-linux, it's still catching up from the core-updates-frozen merge
<cbaines>it's doing pretty well for other architectures though
<vagrantc>could even run it on debian to give it a little more of a foreign environment :)
<vagrantc>e.g. to check reproducibility even when running on a foreign distro vs. guix system
<cbaines>yeah, I am interested in doing that kind of testing, since there may be some issues when building against non-Guix kernels
<vagrantc>cbaines: i could definitely throw some time into it ... i was orginally just panning on doing a whole archive build periodically (e.g. released versions) and just basically doing "guix build --no-substistes" on everything available
<vagrantc>and then making results available via guix publish ...
<abrenon>xelxebar: I don't know but guix/scripts/hash or guix/hash don't seem to use (guix store)'s query-path-hash so why would you expect the results to be the same ? (the behaviour of guix hash is still confusing to me)
<vldn>i try to include some guix guile scripts like the http-client on a foreign distro via a guix binary installation but guile keeps telling "no code for module (guix http-client)"
***aya is now known as gyara
<allana>Hi Guix! I have a question about defining packages. Say that I am developing a piece of software, and I have a guix.scm with a package definition for my software. For the "source" field of the package, is it possible to refer to the local git repository? Any examples out there? Right now I am using local-file and pointing to a source tar.gz that I need to remember to build before I invoke "guix shell".
<xelxebar>"... the alphanumerics excepting the letters e, o, u, and t. This is to reduce the possibility that hash representations contain character sequences that are potentially offensive to some users."
<xelxebar>Interesting. That's a solid motivation and answers a lingering question I had :D
<abrenon>I guess : ) but it's frustrating to see a tool not being able to use it properly while knowing that it's probably there for a good reason since it was devised by people who understand all this better
<ennoausberlin>Hi. I wonder what is best practice to start a web application (django) automatically after reboot?
<notmaximed>ennoausberlin: Maybe you could write a service to start the app? See (guix)Shepherd Services
<rekado>abrenon: I added the simple-texlive-package procedure only to simplify some common patterns I noticed when packaging things. It doesn’t exist for any better reason :)
<rekado>and it’ll likely change significantly or disappear completely with an overhaul of the texlive-build-system
<abrenon>oh will it ? but doesn't it manage setting $GUIX_TEXMF correctly to make sure pdflatex finds what it needs ?
<ennoausberlin>notmaximed: That would be possible. Are there any other methods? The system wide mcron might be an option, too. But I did not found a job-specifier for once-at-boot time.
<rekado>texlive-bin has a search path setting for GUIX_TEXMF. That’s all that’s needed.
<rekado>the default texlive config is defined in terms of GUIX_TEXMF; installing texlive-bin into your profile (or rather texlive-base, which propagates it along with the minimum set of packages you’ll need) causes the variable to be set and thus all texlive packages to be found.
<rekado>using the modular TeX Live is simple: install texlive-base and whatever package your document needs
<notmaximed>There's a non-backup reason to make /gnu/store (or /gnu? not sure) a BTRFS subvolume: compression
<efraim>civodul: I'm seeing hash mismatches connected to the kicad upgrade
<abrenon>ok, and then I need to manually add texlive-latex-geometry… it looks as though adding my package "broke" pandoc's magic to find everything it needs on its own, and from there I need to add everything back piece by piece
<notmaximed>I don't how effective BTRFS compression is in practice.
<nckx>Guest85: I'd say it's unlikely to be useful. If do want to back up /gnu and restore it later as a working store, you must make sure to snapshot /var/guix (or at least /var/guix/db) along with it. For that reason I'd advise *against* making them separate subvolumes since AFAIK that makes this impossible? You could play symlink tricks, of course, but otherwise snapshotting / and backing up selected parts of that seems like the better choice.
<abrenon>rekado: thank you very much for your help ! it's not exactly clear, but a picture is forming and it's way less muddy
<nckx>efraim: A ‘fix hashes’ commit was recently pushed, are you up to date?
<nckx>Guest85: The only reason to back up /gnu is to save downloads and/or rebuilds later. None of the contents are precious in that they can all be rebuilt from the ‘sources’ that are Guix, your package manifest, and your system configuration.
<johnjaye>like i can install it from an iso in virtualbox right
<nckx>johnjaye: Guix is a package manager that builds free software packages, from source code, in a way that allows you to more tightly control their dependencies, and allows other interesting features like profiles, generations, and transactional rollbacks. It should run on any Linux [distribution]. Guix System is a GNU/Linux distribution built on the Guix package manager.
<nckx>I assume you got my rambling reply. LMK if not.
<rekado>oh, the texlive test is trivially broken; will push a fix.
<notmaximed>johnjaye: Guix is neither pro-SystemD nor anti-SystemD. As I understand, the reason that Shepherd is used and not SystemD or SysV init or the like, is that with Shepherd, we can write all kind of things in Scheme (like most of the rest of Guix)
***roptat is now known as Guest4659
<the_tubular>There's still some cool feature in systemd that I don't know if you can use in guix yet
<the_tubular>Also, can anything be used with the hurd as of now florhizome[m] ?
<florhizome[m]>I‘m pretty sure there are services you could run headless in Hurd vms. But idk if guix has a graphical Hurd session. I haven’t looked at the hurd yet, I just know that Systeme is pretty linux specific.