<davexunit>yeah, probably lots of propagation going on.
<davexunit>that's what basically every language but C needs.
<lfam>All these libraries have their own quirky ways of setting up the library and include paths... sigh
***mark_otaris is now known as Mark_otaris
***Mark_otaris is now known as mark_Otaris
***mark_Otaris is now known as ^`__`^
***^`__`^ is now known as mark_otaris
<codemac>I truly disk like /sbin + /bin splits, they seem very artificial for me. But I understand i may be alone on this. Curious if anyone had a suggestion for how I could write a 'profile package' that would create symlinks from anything in /sbin to /bin, so my PATh can be simpler
<fps>"Guix relies on pre-built binaries of Guile, GCC, Binutils, libc, and the other packages mentioned above—the bootstrap binaries. "
<fps>but you seem to be right: "But how do we write a derivation that unpacks this tarball and adds it to the store? To solve this problem, the guile-bootstrap-2.0.drv derivation—the first one that gets built—uses bash as its builder, which runs build-bootstrap-guile.sh, which in turn calls tar to unpack the tarball. Thus, bash, tar, xz, and mkdir are statically-linked binaries, also part of the Guix source distribution, whose sole purpose is to allow the Guile tarball to
<rekado>there probably are no more substitutes on hydra for guix 0.8.3
<rekado>but this error you are seeing appears to be unrelated.
<Gxsdnewb>I thought to simply install the system as it is on the live 0.8.3 image so i could practise reproducing the builds
<Gxsdnewb>but guix wont connect to my manually started guix-daemon with --no-substitutes flag after disabling the autostarted guix-daemon with deco stop (that IS what i should do to install & verify the shipped builds, right?)
<Gxsdnewb>There would ideally be a separate live image with a special dir of just the bootstrap binaries and a guile source tarball for those who wanted to bootstrap their own toolchain, kernel, and GNU packages
<rekado>are you following the instructions in the manual? Or are you deviating from the instructions? If so: where? At what point do things fail?
<Gxsdnewb>now i am deviating by killing guix-daemon with deco stop and running it myself with --no-substitutes... but it seems it still wants to download many tarballs instead of compiling what is on the live disk, including an older (3.14.37) linux-libre than what the live disk ships with.
<Gxsdnewb>Maybe this is because the live image has very little source code on it by default?
<Gxsdnewb>Hmm. the guix system init with no-substitutes failed at adding downloading the tarball of an extra package that i specified in my .scm
<Gxsdnewb>so i really must start the entire build process over after deleting mention of the package in the .scm? what about the compiled outputs that already exist in the /target/tmp/guix-inst/ package?
<sneek>civodul, davexunit says: how about setting the SHELL env var in the guix-devel build script so that 'guix environment -E' will use it? Simply using 'sh' won't do in pure environments that don't have a shell on PATH.
<Gxsdnewb>iyzsong: but would it help resume a guix system init faster if it fails bootstrapping my toolchain so i do not need to start from step 0 everfytime?
<davexunit>Gxsdnewb: why don't you actually finish a GuixSD installation before you start experimenting? you're not using a very ideal environment at all.
<iyzsong>Gxsdnewb: the successed build store items is there unless you run gc. well, I guess the failures ones did need extra efforts.
<Gxsdnewb>davexunit: i am just trying to minimize compiling the sme derivations over and over...
<iyzsong>unless you modify the build exps (the scheme code for that package), the failed build WILL fail again. in that case, it's really bugs.
<Gxsdnewb>iyzsong: i am now running guix-daemon with gc-guild-outputs=yes so i assume non-root derivations (is that the correct terminology?) will remain and not be autodeleted
<Gxsdnewb>not in the case of small ramdisk filling up... the same scheme code should work with a large tmpdir
<iyzsong>Gxsdnewb: I haven't do that, but it seems you can pass both '--gc-keep-outputs=yes --gc-keep-derivations=yes' to be more safe.
<civodul>alezost: i think what you fixed is not a typo, but common style; davexunit?
<toothbrush0>I have a weird thing happening here. I'm trying to install vlc, which pulls in qt as a requirement, but instead of downloading a substitute, it's trying to build. Alright. But it ends on an error: "g++ -Wl,-O1 -Wl,-rpath,/gnu/store/lg4g29ig96xc6fj4v7wfdlx7xp5xadq2-qt-5.4.2/lib -o dropsite .obj/droparea.o .obj/dropsitewindow.o .obj/main.o .obj/moc_droparea.o .obj/moc_dropsitewindow.o
<taylan>hm, so I managed to package Mupen64Plus and all its plugins, but it needs some user configuration to find plugins and their data files. the plugin system assumes a single plugin directory and a single data directory, so a user will need to install the plugin packages into a profile, then set the plugin directory to $profile/lib/mupen64plus and the data directory to $profile/share/mupen64plus
<taylan>improving on that seems hard. ideally I would just document this and move on, but where could I document it?
<Gxsdnewb>so in bootstrapping a new 0.8.3 install, i look at my process tree and it seems guix is still using pre-bootstrap binaries for xz, tar, make, and guile
<Gxsdnewb>why are the newly compiled binaries in /target/tmp/guix-inst being called?
<Gxsdnewb>ah maybe this is because of execution in the chroot, sorry
<Gxsdnewb>still not sure about how to tell which xz is being called
***erdic_ is now known as erdic
<efraim>owncloud client failed at validate-runpath
<mazde>What does guix bring to the table compared to nix ?
<davexunit>mazde: on the technical side, we use a single programming language for packages, build scripts, system configurations, CLI tools, etc. that language is Guile Scheme.
<davexunit>Nix uses its own domain specific language, also called Nix, for packages and system configurations. but build scripts are written in Bash, and the Nix tools are written in a variety of languages like Python and Perl.
<kmicu>mazde: Lisp all the way (no hacky Perl and shell scripts), REPL–driven development (even for the init system), first class Emacs integration, GNU philosophy (with good and bad things related to that).