<PotentialUser-15>maav: i'm interested in building signal-desktop, but it requires npm/yarn, which i don't see in guix (yet?)
<anarkat>just finished installing guix , i run guix pull everthing goes smoothly then at the end spits 2 hints one says "after setting `PATH' , run `hash guix' to make sure your shell refers to `/home/user/.config/guix/current/bin/guix"
<PotentialUser-15>tbh, i found the easiest way to keep my packages up to date is make a manifest file, and i just "guix pull && guix package --manifest=[filename]" every time i want to update, but i have no clue if that's what other people do
<jlicht>PotentialUser-15: `guix install node' for npm, although node is stuck at version 10 (for now)
<jlicht>and packaging npm packages is kind-of terrible at the moment, although the recently packaged esbuild might help in getting some important things unstuck
<PotentialUser-15>jslicht: thanks, i'll try that, it doesn't appear when searching npm ^_^
<sss2>hi all, is it possible to have key file for luks device on external filesystem ?
<vagrantc>well, the pinebook-pro for example has a slow quad-core CPU and a fast dual-core CPU ... schedutil seems to load up the fast CPUs when it's doing a lot of work, and the slow ones when it's mostly idle
<vits-test>on rockpro i'd prefer conservative, as it seem to use lower frequency (idk, "it seem")
<sss2>if it is possible to distribute work across whole network, it will be very nice
<sss2>is it planned any work to implement lvm support for initramfs ?
<Brendan[m]2>sss2 use of distcc would result in changing the package definitions completely, so you'd be off the beaten track. probably its better just building multiple packages simultaneously on different systems instead
<sss2>Brendan[m]2, yes, but here is some like chromium, libreoffice, krita, inkscape
<Brendan[m]2>i was wondering if chromium could actually be split up into multiple different packages that are all assembled at the end
<wleslie>I'd been hoping that keeping g++ but separating libstdc++ for a later build stage would yield me a working cross compiler, but I think I'm going to have to specify languages=c and then build newlib
<wleslie>otherwise I get a bunch of failures in the libcpp build, around things like "undefined reference to `xmalloc`"`
<sss2>is it possible to use custom init inside initramfs on guix system ?
<sss2>and i can add necessary binaries into initramfs ?
<lispmacs>sss2: there is a flag you can pass called #:helper-packages
<sss2>thx, thats enough for now, anyway i am far from this just yet
<lispmacs>these packages are copied into the initrd
<sss2>for now i guess i have another try with my netbook
<sss2>from what i learned, i think it will not be too hard to implement all i need inside init
<sss2>in worst case i think i always can replace it completely by my own (i know this is against whole concept)
<sss2>why xfs utils not included in guix installation media ?
<wleslie>here's the current state of (gnu packages capos). up until now I've been running `./pre-inst-env guix build capos-capros-toolchain`; but now I want to build capos-capros-gcc, however I get `guix build: error: capos-capros-gcc: unknown package`. what have I misunderstood?
<wleslie>oh I added (properties '()) and it found it
<maav>hi, everybody, one quick (and maybe dumb) question... how could i test extlinux bootloader?
<divoplade>Hello, I don't have enough knowledge about guix to turn this into a reproducible example, but running a guile script in a shepherd forkexec service does not work (as opposed to a shell script calling guile, like what cuirass does). Any I/O will silently fail and somehow terminate the program.
<divoplade>(that applies even if I/O is redirected to a file)
<maav>divoplade: this could be related to something i've been hitting these days, do you have any locale-related environment variables defined?
<maav>guile calls setlocale by default, and it raises an exception when the locale is not available
<divoplade>maav, the thing is, it's difficult to know for sure what's in the environment, since I can't do any I/O ^^ The guile compile/load paths are modified, for sure, and LTDL_LIBRARY_PATH too.
<leoprikler>you could use the #:environment argument if that's really necessary
<divoplade>But that would just add things to the environment, wouldn't it?
<leoprikler>not sure if it's adding or setting, it might be the latter
<maav>anyway, the cheap old trick (exec env > logfile) may be used in desesperate times ;)
<maav>(cheaper is to give it a while sleep and check /proc/pid/environ, i feel dirty for what i've done sometimes...)
<Zambonifofex>Hello, Guix! Is there any reason the “base32” hash information has to be stored for Git URLs? Doesn’t Git itself perform integrity checks based on the commit hash itself?
<leoprikler>Guix won't allow you to use git unless it has a hash to check things against and that hash is the `guix hash` of the working directory.
<maav>leoprikler: git stores the file hashes into their blobs and trees, so the hash for the top tree of a version should identify only the content, it's the commits which contain the history (which usually are the ones used, not the tree hashes)
<mfg>well, compiling qt related stuff is slower than i thought - it's compiling for ~3.5 hours i think...
<divoplade>Zambonifofex, in case the history is huge, guix can make a shallow clone, which saves a lot of disk space and bandwidth
<maav>the commits are the ones that don't contain only file hashes*
<Zambonifofex>Well, I was invited (on #hurd) to send a patch updating the commit info for a package, so it just got me wondering, I suppose. I also don’t know how to `guix download` a specific commit by hash.
<leoprikler>guix download sadly doesn't have git support yet
<Zambonifofex>I’m getting a `error: Guile-JSON is missing` running `./configure`, both inside `guix environment guix` and outside it, with my own distro’s packages. (I have the `guile-json` package installed, though.)
<cbaines>Zambonifofex, the important question is whether it's on your GUILE_LOAD_PATH when you try to run ./configure
<ryanprior>Zambonifofex: I saw your question about verifying changes without having to build Guix. There's no tool to do that I'm aware of, any and such tool would be a guess at best, because the packages are part of the Guix code base and could depend on any other part of Guix.
<ryanprior>There's a proposal for a package format that wouldn't be entangled with Guix itself, and thus could be checked for correctness without needing the whole of Guix installed. But it's been stalled for years.
<Zambonifofex>I see. Well, to be honest, I just wanted to be able to verify whether the hashes I put in are actually valid. I suppose it’s a too specific request, though, so it makes sense that it’s not an available option.
<ryanprior>A tool to create Guix hashes of a file or directory does seem like a thing that should be able to work without needing all of Guix. I'm interested in building that actually, but it's not a high priority yet.
<roptat>ryanprior, well there's "guix hash", I'm sure you can extract its content without needing a lot of what guix comes with
<ryanprior>Yes that's my idea is to read how `guix hash` works and turn that into a standalone tool.
<vagrantc>ryanprior: i'd like such a tool as well :)
<Zambonifofex>Ah, I did generate the hash with `guix hash -rx`, but I wanted to make sure I haven’t done anything dumb, I suppose.
<rekado>Zambonifofex: you may also need to update the revision
<rekado>it’s there to make sure that the version string increases monotonically
<rekado>commit hashes cannot be sorted alphanumerically to get the most recent first
<rekado>so we prefix it with a revision number that we update manually, even if the version string itself (here the Linux version) has not changed
<rekado>Zambonifofex: if you want you can send me the diff and I’ll test the build and push it.
<Zambonifofex>rekado: See if this looks good enough! You can credit me as either “Zamfofex” or “Zambonifofex” (I prefer just “Zamfofex”, though). If you need my email, it’s zambonifofex at gmail, but I’d rather it not be included if possible.