<vagrantc>nothing quite like booting an old guix machine and seeing how troublesome it is to bring it back up to date :)
<joshuaBPMan>davexunit Thanks. I do know how to make a site look somewhat respectable...I've just got to learn haunt first. :) I'm actually copying your blog builder for now....obviously. Also, let me know if you wanna do a haunt coding session...Idk how much help I'll be, but I'll be sure to bring rocking music. And virtual cookies.
<joshuaBPMan>vagrantc hahaha. I remember those days, Now I upgrade like everyday just in case.
<vagrantc>this has been sitting in the closet for maybe 5 months ... and the time before that maybe another 6 months
<bdju>I'm having an issue where launching emacs from wofi results in it not using my normal config, but launching from a terminal is normal. what would the difference be? I tried launching by the exact path from `which emacs` in wofi and it has the same problem. `emacs` or that path in terminal works.
<bdju>my emacs may have updated recently so maybe it's a difference in environment between my shell where I updated guix and my login session
<joshuaBPMan>bdju I haven't actually updated emacs yet...does the problem persist when you downgrade emacs?
<bdju>I haven't tried a downgrade but it seems to be very specific to what sort of thing launches it. I tried in another shell I had open since a long time ago and it has the same problem as wofi, but if I source my shell config then it launches fine after that
<lfam>Anyways, this change I'm testing is just a short-term thing. If it's better to fetch from Git that's fine as well. I wonder how using Git in more parts of this would affect linux-libre-headers-5.4.20. The comment says it used in the bootstrap process
<vagrantc>apteryx: when i made a simple attempt at switching to linux-libre git ... it re-downloaded the whole git history each version and produced a huge store checkout
<vagrantc>apteryx: are you doing something more clever to reduce that impact?
<apteryx>nope. Are you sure it's failing at doing a shallow checkout?
<lfam>It's really only practical with shallow cloning
<vagrantc>well it was trying a shallow checkout ... was still quite expensive as compared to downloading a compressed tarball
<apteryx>eh, did the hash change for linux-4.19.142? hash mismatch for store item '/gnu/store/3spw1k850mrcskrldqcfa7cnhgwmp4kp-linux-4.19.142.tar.xz'
<apteryx>vagrantc: how many MiB? That lz tarball needs to be decompressed anyway.
<jgart[m]>Does anybody happen to know of any example configs demonstrating guile shepherd wrappers around systemd? i.e. I'd like to declaratively manage/wrap systemd on a foreign distro from shepherd. Would this be the right way to do it?
<vits-test>Hello jgart[m]. blackbeard[m] have worked on make the systemd units useable by shepherd. It's all i heard close to this topic.
<peanutbutterandc>It seems that while `alsa-lib` and `alsa-plugins` are different packages, ALSA lib conf.c expects to find `alsa-plugins`-shared-objects inside 'lib' under an 'alsa-lib' subdirectory within alsa-lib's 'out'...
<peanutbutterandc>It is looking for libasound_module_conf_pulse.so in the wrong place. It should have been looking for it in a separate /gnu/store/hash-alsa-plugins-version directory... or something
<peanutbutterandc>If anybody wants to look into it, the package is `tuxguitar`. If you build it as-is, you will get an error about libasound_module_conf_pulse.so not being found where it is supposed to be. A quick look at the package definition will show that the `alsa-plugins` is, indeed, not listed as an input.
<peanutbutterandc>However, if one adds it as an input, the issue and builds, the issue still persists.
<vits-test>peanutbutterandc: there are similar things for some sdl-dependent packages. For those there is 'sdl-union'. Maybe alsa has something like this too?
<peanutbutterandc>vits-test, I can seem to `guix show sdl-union` nor can I see anything like alsa-union...
<vits-test>peanutbutterandc: sdl-union used in package descriptions, but i didn't found the alsa-union.
<zzappie>any guix-ocamlists here? I'm trying to package frama-c and got stuck at why3 library that requires ocaml-num. Configure script complains that there is no Num library even though PATH, CAML_LD_LIBRARY_PATH, LIBRARY_PATH etc all point to ocaml-num I'm just curious whether ocaml requires extra handling in relation to libraries
<vits-test>zzappie: Hello. Try add ocaml-num to propagated-inputs.
<vits-test>btw, nckx: in recent conversation, nly said we can use some already present tools to use p2p with `guix`. Like, share a store via torrent. People can download needed files. Then `guix archive --something`.
<vits-test>"and that digital signature is appended" oops.
<nckx>Well, the plan was always to use existing tools... Like GNUnet or IPFS (or torrents, I guess, although I don't know if it's a good fit). You can't share the store using bittorrent but you could share static parts of it.
<nckx>Using nars (‘guix archive’) and signatures is probably a given, although last time I heard about IPFS there was talk about using a more ‘native’ format. That was quite a while ago and I forgot most of the salient points.
<apteryx>lfam: I think reproducibility is is a bit more than a nice to have, otherwise we wouldn't open issues about it on the tracker. It's a goal to be 100% reproducible, and when contributing new packages, it's expected that we do the homework to verify whether the package is reproducible, and try to fix it if it isn't (putting upstream in the loop if something need changing on their side).
<apteryx>But you are right that it doesn't block inclusion. Just wanted to stress that it's important :-)
<Aurora_v_kosmose>Right. I would imagine in this case that once the compilers get fixed the rest would just naturally follow.
<lfam>Yes, it is important. But currently not feasible to require :)
<lfam>There are often issues in the build scripts, as well, Aurora_v_kosmose
<lfam>And for certain programs, reproducibility may not even be desirable. For example, software that is supposed to be high-performance should be compiled for the CPU it will run on, not a generic platform. That's a use case that is not really addressed by our efforts so far
<Aurora_v_kosmose>lfam: In some build systems the case is worse than others. ASDF tends not to carry as much.
<Aurora_v_kosmose>lfam: As for CPU-specific flags, I'd think someone should customize their package definitions if they want that.
<Formbi>that way you can have the configs and not download other variants
<simendsjo>lfam: Ref my "edit command not found" when running `guix edit` - yes, it seems like it was because EDITOR couldn't be launched. I used `--pure` for `environment`, and thus didn't have anything other than guix (and deps) available. Quite cryptic error message though.
<lfam>simendsjo: I'm not sure if it's Guix's fault or the system's fault in this case. I do know that "permission denied" and "command not found" can be really misleading on GNU/Linux
<lfam>They are overloaded and should really be overhauled
<bluekeys>I'm on a foreign distro, the penny has just dropped, I' running its version of emacs, I'm not sure it is loading modules from guix
<lfam>simendsjo: If you haven't already, it would be helpful if you filed a bug report about the confusing error message. Maybe we can fix it