<leoprikler>erikg: If CMake provides some flags to use system libraries, use that. Otherwise try putting the source code into the expected destination path and hope that CMake acts reasonable
<leoprikler>although guix usually aims to debundle such packages, so you may want to add a patch in your cmake setup, even if that is for guix only
<erikg>leoprikler: yeah, I get the debundling motif, but in this case the project is under very active development. The whole reason for using the ExternalProject_Add incantations was to reduce the cost of updating dependencies to an absolute minimum, because I'm doing it very frequently
<erikg>I'd like to use guix for packaging and deployment in various places, so it's worth patching the repo to allow everything to get pulled down with a recursive git clone (which is totally cool with guix)
<leoprikler>Recursive clone is usually a sign that the packager gave up on your ugly submodule structure.
<leoprikler>"Reducing the cost of updating" should not be that much of a concern if you're using guix for packaging/development anyway.
<leoprikler>Package the dependency in guix, then use a `guix environment` for hacking or just add another package for deployment.
<erikg>I need to be able to build without guix. It's not possible for the majority of my users to install it. However, it is useful to me and some users who need to deploy via containers.
<erikg>If your focus is making a binary executable that is precisely specified by its input source code, submodules and ExternalProject specifications are just fine. They meet the basic requirements. We can blame C++ for never developing a proper module system. Obviously, guix would be ideal, but it's not a standard facility that everyone can have access to (e.g. in HPC systems), even if it should be...
<erikg>And yes, this pattern has resulted in some nasty source trees with plenty of awkwark duplication
<nckx>raghav-gururajan: Outreachy internships focus on one coherent, ideally ‘finishable’ task. See <https://www.outreachy.org/past-projects/> and search on each page in that list for ‘Guix’ (except the last one, we haven't submitted anything for that yet) to get an idea.
<nckx>You're welcome to propose something yourself (anyone is) and if it's accepted you can apply for it :
<Parra>I did a find /tmp -name '*.log' but nothing was found
<leoprikler>C-q runs the command quoted-insert (found in global-map), which is an interactive compiled Lisp function in ‘/gnu/store/hg2qd5ggvnxq5gfdhxqpidhm3rr8vysr-emacs-26.3/share/emacs/26.3/lisp/simple.el’.
<aitzkora>civodul: someone in the guix-hpc project could accept my merge request for opencoarrays ?
<civodul>aitzkora: sure, i or someone else will take a look
<jonsger>civodul: can guix already be used with guile-3.0?
<thesfrash>Hi Guixers! I was wondering how bad an idea it was to share a Guix Store between the Guix System and Arch Linux dual booting on my laptop. My understanding is that if I never use "guix gc" everything should be fine because if something already is in the Store then it's ok, if it's not it just gets substituted/built. But everything could break if,
<thesfrash>after I run "guix gc", Guix decides that a Store item is not linked to any profiles in the running distro it'll just GC them and they could be possibly linked in some other profiles in the other distribution. Is that a real problem or Guix is smart enough to figure this out for itself? Thanks!
<leoprikler>It should probably be fine if one of them only makes references to the other
<leoprikler>e.g. if you `guix pull` on arch, using guix commits that you already have on Guix system
<leoprikler>building the same packages on both systems etc. etc.
<zimoun>Debbugs question: why does the tag "patch" only appear when the subject contains PATCH? Does it come from the old time where the patches were sent to guix-devel? Is it possible to add the tag "patch" to all the emails sent to guix-patches?
<erikg>efraim: that should be happening with (recursive? #t) set in (git-reference ...)
<nckx>I don't know if that reasoning is still valid (do you?) but any commit reverting it should a) not be mixed in with many unrelated changes and b) include some rationale for why Chris's addition is no longer needed.
<mehlon>I already have fixed instructions ready that should be more portable anyway
<nckx>KE0VVT: We aren't ‘against /usr/bin/env’, we explicitly support it if you want to write/use scripts that have it. What we don't do is ship *Guix packages* that contain such shebangs because there's no way to know what they will invoke at run time.
<mehlon>lfam: useradd and groupadd are not present on alpine linux, you have to user adduser, addgroup
<mehlon>wait no, even *that* doesn't work unless you have busybox...
<nckx>janneke: Looks good, assuming the code & GRUB xref work! Only nitpick I can think of would be to check whether the list elements contain a ‘,’ or ‘;’, which should probably not be silently allowed, but I'm sure most other services don't go that far either so it's certainly not a blocker.
<lfam>mehlon: Can Guix work on alpine at all? Guix is heavily dependent on glibc
<oriansj>painful but works is better than nothing at all
<lfam>Better to use another distro IMO, where you don't have to compile anything
<apteryx>inkscape fails to build on core-updates, some C++ compiling error: no known conversion for argument 1 from 'GlobalParams*' to 'std::nullptr_t' (line 18 of pdfinput.cpp). Might be due to an update to Poppler, which defines GlobalParams
<mehlon>well I mean the solution is *obvious*........ program in scheme exclusively
<nckx>oscar123123: The decision was made because hackers and others kept coming into this channel, more than weekly, to ask the same identical question. I don't like the solution very much but it was made in good faith. Other suggested solutions (like guix install --force) do not seem to me to be an improvement.
<leoprikler>Even if you program in C, `guix environment` FTW!
<oscar123123>what about changing the package name to something beside gcc
<nckx>‘gcc-toolchain’ was and is documented in the manual but that didn't help.
<kmicu>Darcs… nice. I see that our bot is the top quality code.
<nckx>oscar123123: It's a technical (non-)solution to a social problem. No qvesh.
*nckx remembers something about ‘working’, whatever that means. See y'all later o/
<mehlon>sneek: if you're so 'extensible' why can't we program you from the chat, huh?
<leoprikler>I think we should have "sneek install <package>", where <package> is a hidden package
<oscar123123>nckx well, i can see why people made this decision but it can make peoples life a bit hard. I'm trying to run firefox for like an hour now and at the end i used another package to find a libstdc++