<rekado>OriansJ: would you mind if I added stage0 to the list of projects on bootstrappable.org?
<Apteryx>Hi Guix! I'm making progress on a profile hook that will generate the manpage index.db file which allows apropos or man -k to work as expected, but still need some help.
<Apteryx>I'm testing for example by doing: guix environment --ad-hoc git. I then see that the generated profile contains the desired file: /gnu/store/j8hdiljyjx5fw8wzm4jh6g8g2afzdfl6-profile/share/man/index.db. Unfortunately apropos seems to be looking under $HOME/.guix-profile/share/man/index.db.
<efraim>Maybe it might need tweaks to the guix environment script
<Apteryx>OK. I'll try to get the base use case going at first (the main user profile).
<ofosos>I want to add a package to a guix checkout, some old documentation talks about gnu-system.am, which i can't find, to let the system know that package is there, do I still need that? guix build comes back with package not found. any ideas?
<rekado>ofosos: also make sure to use “./pre-inst-env guix”
<Apteryx>Strange, I cannot find the docs for find-files.
<ofosos>hmpf, ok, i see. the problem: i defined the new package in audio.scm, the ./pre-inst-env guix build simply states that the .scm is newer than the one in the default environment, but doesn't seem to do anything about it
<rekado>Apteryx: it’s a Guix thing. It’s defined in (guix build utils)
<rekado>ofosos: that’s just a warning. You can run “make” to compile the .scm to .go.
<civodul>amz3: i think i just emailed it to OrangeShark, thinking it would be unproductive to email the two of you :-)
<rekado>civodul: guile-reader fails to build on core-updates
<ofosos>hmm, i'm having a problem using the elpa imiporter on melpa-stable to get bbdb: guix import: error: failed to download package 'bbdb'
<ofosos>this worked nicely with adjust-parens, but no luck with bbdb
<ofosos>hmm, i've packaged up qjackctl, however, when i try to check if it is deterministic (--check) it simply grafts the software, when i pass build --check --no-grafts it tells me that both differ. how can i analyse this?
<jest_a_prank>Hi, #guix. can `handle-lid-switch` in `elogind-service` be set as suspend *and* lock?
<arunisaac>Hi, I'm trying to fix bug #25235 ( https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25235 ), and have modified guix/build/python-build-system.scm for the same. In particular, I have added #:use-module (guix packages) because I need the functions `package-name' and `package-transitive-target-inputs'. But, when I try building any python-build-system package with something like "./pre-inst-env guix build scons", I get a ("no code for module"
<lfam>ofosos: In your message, can you also list all the patches that darktable depends on? If I remember correctly, they were sent in separate threads so it was hard to keep track of
<ofosos>lfam: as of now, only fop is unavailable, everything else worked. i removed the fop dependency and it built fine
<ofosos>oh yes, and i change the llvm-x.x.x to llvm, same for clang, in the native inputs, but i didn't verify the result
<Apteryx>civodul: Success for the manpage db generation :)
<Apteryx>It's a bit compute heavy though; on my main profile with 67 packages installed it doubled the time required to do a package install (since it must rebuild the database from scratch everytime the profile changes).
<ofosos>nope, opencl doesn't work, basically it need a libOpenCL, which is not available
<ofosos>but the software itself is unaffected, i only see a complaint when i start with -d opencl
<Apteryx>I'll send the patch tomorrow, after I write the changelog with a clear head.
<lfam>Hey efraim, did you ever send a patch for the parallel XZ thing?
<davexunit>'guix pack' is sure useful for letting you know that your dependency tree is huge
<janneke>yes ~@31:50, the thing about distros starts ~@27:00
<paroneayea>the tl;dr for people here curious (though you should watch the talk) is that most free distros end up complicating the "supply chain" by introducing an intermediate distro which needs to remove all the nonfree things, and that both duplicates effort in resrource constrained environments and also results in slow delivery of security updates, etc... but guix doesn't have the middleman situation, since it starts out libre by default
<lfam>It's the idea that those distros can only ever be *less* secure than the upstream distro
<lfam>I think there's a social issue, too. It's hard to get large numbers of people excited about a distro re-spin whose only distinguishing characteristics is that it's 100% free. Whereas Guix is interesting in its own right.
<lfam>But it's valuable to have those distro variants anyways. Some people want or need to use a familiar distro type rather than something new
<paroneayea>I'm not necessarily claiming Brett is right, but in a selfish interest-validating way it was nice to hear
<paroneayea>and also it was an interesting argument, since Brett is not a Guix user (yet... I think they like the design)
<lfam>I've only just started the video, but I think I'll agree with him based on my reading of his slides a couple days ago
<lfam>So, I can take all the keys from Savannah. We should also include the key that thomasd used by accident recently, and keys of people who have left the project (I still have those keys). I'll also make a README explaining where the keys came from, things like that
<lfam>Right now I'm measuring the effect of efraim's parallel XZ patch
<lfam>The linux-libre tarballs are a good test case, I think'
<efraim>If it is compressed with xz in parallel then it can be decompressed in parallel, but if it is compressed single threaded then it'll only decompress on one thread
<efraim>According to the documentation it doesn't matter how many threads the compression happened on, as long as it was more than 1
<lfam>I'm going to benchmark creating our patched tarballs, and also unpacking them in advance of building linux-libre
<lfam>efraim: Is it possible to check if a tarball was compressed in parallel?