<lfam>Particularly the install-headers-phase. It has the line (mkdir-p include). I can't tell based on bash.scm where in the directory tree that is executed, but the bash tarball unpacks with an include/ directory at the top-level.
<lfam>However, the contents of the directory aren't getting copied into the store directory for bash:include
<davexunit>lfam: try inserting a debugging print statement just before that
<lfam>The contents of the tarball's include/ directory, that is
<lfam>So far I have not created any profiles from "scratch". I have just package -i and -r'ed them into shape. But is there a way to make a new profile with just bash? And I guess locales?
<lfam>Even with a bash only profile, there is still a lot to do
<lfam>Well, at least the transitions between profiles are atomic and fast :)
<lfam>It's a shame though. The bash:include package shouldn't need to compile anything. It's literally just copying files from the tarball into the store, unless I am mistaken. But the whole dependency tree is changed when I change bash.scm.
<bavier>lfam: yes, bash is used during bootstrapping
<bavier>so changing the bash package recipe leads to re-bootstrapping
<mark_weaver>xd1le: it's possible in theory but difficult, and I don't know off hand how best to do it, but part of the job would be to create an xorg.conf that tells X where to find things like its modules and fonts, and then to pass the needed command-line arguments to use that configuration file.
<toothbrush0>Hello all! I have added a crapton of Haskell/Cabal packages; i guess i should send individual patches. What i'm worried about though, is that it will be a non-trivial task to sort out the order in which packages should be added.
<toothbrush0>iyzsong: it looks like you're right, although i haven't checked exhaustively
<alezost>davexunit: yes, all other emacs packages worked for you, because all of them were installed in ~/.guix-profile/share/emacs/site-lisp, but for the packages installed in guix.d, each new subdir should be added to load-path separately
<iyzsong>um, propagated all inputs for library-type packages make our life easier, since we don't install them typical, the mess can be ignore? toothbrush0, yes, we should talk it to the mailing list.
<davexunit>"Programmers don't care to the point that they welcomed Docker (which is "bundling on steroids") with open arms, red carpet and whatnot."
<davexunit>"If distros want developers to unbundle their dependancies then the distros need to start making some promises about compatibility, for 5-7 years, of the libraries they want developers to be able to depend on otherwise this doesn't fix the pressure toward bundling and containerizing."
<davexunit>"Who cares about bundling? I say, bundle the whole world and to hell with distributions. Bundle everything above syscalls: ditch glibc for musl, jettison distro-provided libraries, get rid of complicated packaging.
<toothbrush0>this is becoming rather tiresome, i just want Idris :p
<toothbrush0>okay, so i'm rather frustrated at Hackage right now. I just discovered that they think it's reasonable to update the .cabal file (which should be inside the checksummed .tar.gz) on hackage.haskell.org (as a so-called `Revision') without updating the .tar.gz!
<toothbrush0>hm, maybe someone can help. I'm getting an error "ERROR: In procedure copy-file: No such file or directory", but the displayed path does exist on my filesystem. it points into /gnu/store/..
<taylan>toothbrush0: propagated inputs are generally not nice. when a user installs X, all its propagated inputs are installed too, in a user-visible way. this should be avoided when not absolutely necessary. I think we might eventually want a better solution for pkg-config's broken logic too.
<davexunit>propagating is unideal, but thankfully Guix has profiles to deal with any conflicts that may happen.
<taylan>in fact in the case of Elisp (and maybe Guile?) it's not just a mistake of the checking mechanism; all dependencies of a library really need to be installed because there's no such thing as referring to them with absolute file names. (actually there seems to be, according to the docs of 'require' in Elisp, but it hasn't been looked into much yet AFAIK)
<lfam>If I alter bash.scm, and then build it from within `guix environment guix` and /.pre-inst-env, which takes forever, is there a way to make that new bash package visible to operations that are not performed within `guix environment`?
<lfam>For example, I did that, and then I rebuilt a package that depends on bash, but guix selected the old bash.
<lfam>I could just build the dependent package from within `guix environment`, but I'm wondering if there are other ways.
<lfam>I mean, I think I "could just" do that. It's building now and I didn't see which bash it chose. I will find out after the build.
<bavier>lfam: were you also using ./pre-inst-env outside 'guix environment'?
<lfam>I just let it do this overnight. What is going on here?
<lfam>I didn't make any changes between now and then
<mark_weaver>lfam: if you modified the 'bash' package, then since 'bash' is needed for almost every build, everything will need to be rebuilt.
<bavier>lfam: does it do the same from within 'guix environment'?
<lfam>bavier: I already rebuilt bash overnight, with everything that entails, from within `guix environment`. Now, I wanted to rebuild the package recutils from within `guix environment`. Recutils depends on bash. Shouldn't the bash and deps I rebuilt overnight be used here?
<lfam>bavier: Maybe I am wrong about what's happening, and different things are being rebuilt. I'm not sure how to read the "to-do" list while `guix build` is happening. But it's rebuilding libgcrypt, gmp, etc. Things I thought were rebuilt overnight.
<davexunit>lfam: any reason why you didn't build a separate bash package to test this includes thing so that you didn't have to rebuild the world?
<mark_weaver>lfam: I guess that's not needed in this case. it will have to be applied to the 'core-updates' branch anyway, where it is expected that breakage might result, and also if the only change is to install more headers to the 'include' output (seldom used), we can probably guess that it's most likely safe.