<davexunit>it's not all that nebulous: the daemon and hydra need to replaced. then we'd be running 100% on Scheme.
<jgrant>davexunit: Nebulous in that seems like approximately like "a lot of work" but not really quantified on my end as how much doing such things would be. But yeah, gotcha, ultimately it's "only these two things" but it seems like somewhere from a pain to a monster to actually re-implement.
<jgrant>Well, as always excited to see how such things are trudging along in this camp. I'm hoping by the end of the year, I'll be a bit less useless and be able to start working on thing that are not just packages.
<davexunit>hmmm, looks like we have no existing usage of bzip2 for compression...
<davexunit>that's what Hydra uses, so I guess I'll have to figure that part out...
<jgrant>Not to say packaging is useless, but within the frame of my day to day computing -- the only stuff missing is CL based applications, which I'd need to be able to figure some factor of a build system for it... which is a bit past my skill-level currently.
<jgrant>Stumpwm is certainly up there of big packages Guix is missing for me to fully make the switch, but too being dependent on this non-existent build-system for dependencies, I see being a bit problematic atm to persue more seriously.
<davexunit>a-ha, looks like I don't have to do that. (guix utils) has compressed-port and decompressed-port, awesome!
<davexunit>jgrant: does stumpwm have it's own special build system?
<davexunit>or do you need sbcl + a common-lisp-build-system?
<jgrant>davexunit: No, but it depends on clx and cl-ppcre which I think needs somefactor of asdf iirc.
<davexunit>it just reaffirms my biases against ruby programmers.
<davexunit>while I programmed in ruby professionally for a couple of years and generally like the language, the community does some boneheaded things whilst thinking that they are more advanced than everyone else.
<jgrant>davexunit: I was going to say, I assume you had some history there remembering you did someactor of webdev (at least historically).
<davexunit>but when I can't build a gem from your source releases... there's a problem.
<jgrant>There seems to be a slightly larger contingency of "douchebaggery" in the webdev community than other facets of compsci ... that being said, it's relatively bad wherever. The ego is always present, nearly, it seems.
<civodul>the upstream work done here will be beneficial to everyone
<bavier>how does #:substitutable #f work with dependent packages? E.g. If I want to install python-numpy, does it need to be built locally because atlas (which it depends on) isn't substitutable?
<bavier>I'll ask my question again, now that civodul is here ;): how does #:substitutable #f work with dependent packages? E.g. If I want to install python-numpy, does it need to be built locally because atlas (which it depends on) isn't substitutable?
<mark_weaver>texlive fails to build on ARM. configure fails because it can't successfully link to -lgd. the reason is that libgd depends on libjpeg and fontconfig, and those libraries are not getting linked in to the test program that configure creates. not sure why we're not seeing this on the other platforms.
<civodul>maybe a configure script somewhere determined that it cannot build share libs, and another configure script down the path determined that it cannot use the lib because it's not shared, etc.
<mark_weaver>gd lacks a .pc file. libgd.la file includes -ljpeg and -lfontconfig in 'dependency_libs', but that's not getting included in the test program link.
<civodul>because the test program doesn't use libtool
<civodul>if libgd.so exists and has the right NEEDED, there's no problem
<civodul>if it doesn't (there's only libgd.a), then boom