<lfam>Can someone give me a refresher on the difference between inputs and propagated-inputs? I thought that propagated-inputs were installed into my profile along with their referrer. But I have a WIP python package with tons of propagated-inputs, and it works, but they are not in my profile. So clearly I don't understand fully.
<Steap_>lfam: weird, I use "propagated-inputs" for inputs that I need at runtime
<lfam>I've seen propagated-inputs in my profile before, but that wasn't for python. Maybe the python-build-system does some magic to keep the profiles clean?
<Steap_>I'm pretty sure that if you install "python-foo" and "python-bar" is one of its propagated inputs, then pytho-nbar cannot be removed by "guix gc" as long as python-foo is installed
<lfam>My understanding is that native-inputs are build-time only dependencies, inputs are run-time dependencies whose paths can be patched into the source files, and propagated-inputs are run-time dependencies that must be on some variant of $PATH. Is that correct?
<lfam>I think I used to know this better... the last few weeks have damaged my brain :p
<Steap_>native-inputs is used for cross-compilation
<Steap_>if you need autoconf/automake/... you want to run a version that works on the build machine
<lfam>Well, I have a ton of packages that make up the lets-encrypt client and its closure. TBH I'm not sure what type of input every dependency should be. I will send the patches as WIP to the ML for advice.
<lfam>It would be nice to have the package ready for the open beta on 2015-12-03
<mark_weaver>lfam: if package A has package B as a propagated-input, and package A is in your profile, then package B will also be added to it, but B still won't show up in the output of "guix package -I"
***hacker is now known as y
***y is now known as exio
<lfam>I see that the build system has automatically wrapped the output binaries to provide PYTHONPATH. Nice!
<civodul>bavier: one wouldn't expect that from such companies ;-)
<Steap_>From what I've heard, it is mostly people paying to be able to hear propaganda from Intel & co.
<mark_weaver>civodul: so, I was thinking, as a way to make 'guix pull' builds go faster and also evaluations, maybe we could split the building of guix into a bunch of finer-grained derivations, where each one compiles a single file, and has as inputs the files it references.
<mark_weaver>of course, the circular dependencies between modules are perhaps a blocker for this, but IMO we should try to eliminate those anyway.
<mark_weaver>we could start by only making the package modules compiled in a fine-grained fashion.
<mark_weaver>the rest of guix could be compiled in a single derivation that build everything except for the package modules, and that would be an input to all the other derivations.
<civodul>mark_weaver: hackish idea: it might be that in gnu-system.scm, replacing (set! %fresh-auto-compile #t) with (set! %load-compiled-path '()) would work better? (evaluate everything instead of building everything)
<davexunit>I know that in C there is LUFA which can do tons of stuff out-of-the-box
<mark_weaver>civodul: as a half-way measure, we could compile some selected modules with the hottest code, and evaluate the rest.
<davexunit>isn't it all hot code once the user does 'guix package -s foo' ?
<mark_weaver>well, I'm assuming that the package derivations are memoized, so hopefully most of the code in gnu/packages/*.scm is only run once per evaluation.
<mark_weaver>I guess I should point out that although my initial idea above was for optimizing all builds of 'guix' (include evaluations on hydra, 'guix pull', and 'guix build guix'), our immediate concern is optimizing evaluations on hydra, and civodul's recent suggestions are specific to that.
<mark_weaver>and they have the benefit of being easier to implement
<mark_weaver>civodul: setting %load-compiled-path to '() seems too extreme. we want to be able to load Guile's own compiled modules.
<mark_weaver>the main problem with our hydra is that it's an underprovisioned VM, with not enough memory allocated to it, and with a very braindead RAID set up that basically turns every disk operation into multiple accesses with seeks across the disk.
<davexunit>rekado: I try to compile a firmware and it complains that it can't find <avr/io.h>
<davexunit>mark_weaver: I will gladly stand corrected, but I seriously remember this being brought up just before the 0.9.0 release when someone found a problem
<mark_weaver>as I recall, a couple of months ago karhunguixi wanted an encrypted root, and I looked into it and suggested a patch to our initrd code to enable it, and he got it working, posted the patch, and it went into master a while ago.
<nalck>I don't mean to step on toes, but is this a Libre kernel issue?
<nalck>I don't see how GuixSD should be different than any other system that implements GRUB and LUKS.
<mark_weaver>the issue was that we have a very unusual initrd system based on guile, and it needed to be adjusted to support an encrypted root partition, but as I recall we resolved it a while ago, and karhunguixi has been successfully using GuixSD with an encrypted root.
<mark_weaver>nalck: not a BIOS, but a boot program. it's basically coreboot with the non-free blobs removed (so it only works on a few machines, but yay for no more back doors like Intel AMT), and packaged in a way that makes installation vastly easier than coreboot.
<mark_weaver>it does part of the job than a BIOS does, but doesn't provide all the functionality of a BIOS. it can be used together with SeaBIOS if you really need a BIOS.
<mark_weaver>but GRUB can be compiled to work on coreboot/libreboot directly, so there's usually no need to SeaBIOS.
<mark_weaver>the folks at #libreboot can tell you more about all of these details.
<mark_weaver>but if you don't like the idea of your machine having a separate processor running a complete proprietary OS with direct access to the entire system memory, BIOS configuration, and out-of-band network access, accessible remotely even when the machine is powered off, then I would recommend checking out Libreboot.
<hhynek>Well, when I do guix build --dry-run, it still says "The following derivations would be built"
<hhynek>I expected something different from the manual
<keverets>is there an easy way to tie M-x doctor to ERC to form a quick-and-dirty bot?
<civodul>mark_weaver: "time XDG_CACHE_HOME=/tmp/cache guile -L . -l build-aux/hydra/gnu-system.scm -c '(hydra-jobs (open-connection) (list))'" with an actual connection to the store takes 2m5s on my laptop
<rekado>alezost: "M-x guix e pkg-name RET" is extremely useful!
<rgrau>btw, I was trying to use guix.el, and I'm finding some issues: guix-init.el does a (require 'guix-autoloads), but this file doesn't exist. also, I see some .el.in, which probably have to be 'compiled', but there's no make in there.
<rgrau>this is from the git source. but I installed the binary guix, and can't do a full compilation of guix from source
<mark_weaver>civodul: after the build-aux script finished, the latter part of the evaluator code (the perl script that creates the builds, etc) seems to be stuck. the last thing it printed was "warning: SQLite database is busy"
<bavier>davexunit: the schematics appears to be on their wiki
<davexunit>I have to continue to investigate my avr-gcc issues
<mark_weaver>civodul: okay, I guess it's doing work, but very slowly
***JamesJRH is now known as JRHaigh
***JRHaigh is now known as JamesJRH
<civodul>mark_weaver: "time XDG_CACHE_HOME=/tmp/cache ~/src/hydra/src/script/hydra-eval-guile-jobs --entry hydra-jobs -l build-aux/hydra/gnu-system.scm > out.xml" takes 8mn here; that's without the Perl thing
<civodul>just sharing measurements as i make progress :-)
<Shibe>guys i have a question about package managers
<Shibe>functional package managers give programs their own dependency tree right?
<Shibe>so newer versions of libraries can't break other programs?
<Shibe>but they take up more space right? since every program has their own libraries and whatnot
<Shibe>wouldn't it be possible to have both? as in if in a package's metadata it is confirmed that package a works with library c version 2, and package b also works with that, couldn't they share the library?
<mark_weaver>libraries are shared in guix, if precisely the same version is used from multiple programs.