IRC channel logs

<davexunit>okay, 2/4 release tasks down.

<Steap>paroneayea: well, OpenStack allows you to run VMs

<Steap>so it's basically like installing a VM, I think

<davexunit>need to create a disk image in the right format and tell openstack to provision the VM with the desired resources and disk volumes

<lfam>How does Guix replace /usr/include? Are packages supposed to put their headers in ~/.guix-profile/include? And then, any input with a header must be propagated?

<davexunit>'make install' and friends install headers in /gnu/store/...-foo/include

<davexunit>profiles are symlink forests, do not confuse them with where things are actually installed to.

<lfam>Yeah, I know. I meant, all the libraries and headers are supposed to end up symlinked into ~/.guix-profile/[include|share|lib], right?

<davexunit>yes.

<davexunit>but no, that doesn't mean propagation.

<davexunit>usually.

<davexunit>propagating is only necessary (for C things, anyway) when an application dlopens a shared library or something.

<lfam>Yeah, in this case I am packaging libraries

<davexunit>you most likely do not need to propagate

<lfam>The Lua shared library system uses dlopen.

<davexunit>oh this is for lua

<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

<codemac>*dislike...

<nully>why not just set your PATH to include /sbin?

<nully>otherwise, symlink the entire directory

<nully>if you reallllly wanna do that.

<nully>dont bother managing symlinks, that gets out of control.

<Gxsdnewb>Why is it that every time i run guix pull that there is a new guix-latest.tar.gz with a new hash... is the source repo changing so often within the span of one hour?

<codemac>yeah nully, I know I'm boing ridiculous. I just hate these kinds of distinctions when nix-style store paths give up some completely on unix paths anyways

<Gxsdnewb>There is also no guix binary in the compiled ...-guix-latest/ dir after guix pull

<Gxsdnewb>only many scm and go files, and which guix points to a ...-guix-0.8.3.5d09263/bin/guix

<Gxsdnewb>the compiled ...-guix-latest/ has no bin subdir

<fps>rekado: http://www.hashcollision.org/ragg/index.html

<fps>that looks even more promising

<fps>but it's in racket and not in guile

<rekado>fps: there's also a parser generator in guile.

<rekado>(I haven't used it so far, though)

<fps>rekado: my google fu must suck then. i didn't find it :(

<fps>but i don't mind the particular dialect too much as long as it's readily available on most platforms..

<Gxsdnewb>reading section 6.7 of the manual about Bootstrapping now, this only applies to installations with the source tarball?

<Gxsdnewb>I downloaded the binary GuixSD live image and booted from usb, and this obviously has many more precompiled packages

<fps>Gxsdnewb: i think so. once you install the image to a hd ou have guix available..

<fps>*you

<fps>Gxsdnewb: one note though: right after installation do guix pull as root

<fps>cause 0.8.3 binaries have been GC'ed from the build server

<fps>and you don't want to build everything from source ;)

<fps>oh and after guix pull, do guix system reconfigure and maybe reboot once more

<fps>(reconfigure /path/to/your/config.scm)

<Gxsdnewb>fps: but if i did want to build everything from source, then i could start with only the bootstrap binaries plus guile tarball?

<Gxsdnewb>i was running guix pull while still in a live environment, but this is against your recommendation?

<fps>Gxsdnewb: i'm somewhat of a noob, too :)

<fps>i just followed the installation instructions once and then was surprised that everthing was built from source when i tried to install stuff

<fps>Gxsdnewb: so what is your plan?

<fps>do you want to completely boostrap the distribution"?

<fps>or do you want to use it? :)

<Gxsdnewb>both?

<fps>oh ok, then ignore me. i thought it was only about getting up to speed using it

<fps>i suppose nothing is stopping you to pull the tarball into the live system

<fps>and then try to bootstrap it :)

<Gxsdnewb>fps: i guess once i get up installing the binaries, nothing is stopping me from trying to reproduce the builds to see if they match, either

<fps>you need to have _some_ binaries anyways

<fps>Gxsdnewb: i would think so, especially if you take care to use the exact same versions

<Gxsdnewb>well the source distributions ships with precompiled bash, mkdir, xz, and tar says the manual

<fps>which is outside of my expertise by a long shot

<fps>and scheme, gcc, and some other stuff

<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

<fps>etc..

<fps>so please do ignore me cause i'm obviously clueless

<fps>unless you need someone to bounce ideas/chatter off :)

<Gxsdnewb>mark_weaver: Anytime you have a moment libre to give advice about Bootstrapping GuixSD from the live 0.8.3 env, i am curious to know the corrects order of steps

<fps>i would _guess_ that if you want to test the reproducability it's a bad idea to do guix pull, cause the binaries on the live image are 0.8.3

<Gxsdnewb>I would like to do it with substitutes disabled.

<Gxsdnewb>strange that there are two separate guile-2.0.11 directories of different sizes right at the start.

<Gxsdnewb>strange, when i try to kill guix-daemon and launch again manually with --no-substitues, it restarts in the background without it so there are two processes running

<Gxsdnewb>fps: It is sad, but maybe i should just try installing the binaries as they arde precompiled :-/

<fps>Gxsdnewb: i suppose the init system does that for you

<fps>but just a guess

<fps>ah right

<fps>sudo deco status dmd

<fps>shows among others guix-daemon

<fps>Gxsdnewb: i suppose you can just tell the tools to not use substitutes though

<fps>e.g. https://www.gnu.org/software/guix/manual/html_node/Substitutes.html

<fps>oh, that refers to the guix-build option, right..

<fps>wow, who thought it was a good idea to output all the services in one line?

<fps>my eyes hurt :)

<fps>piping it through sed -e 's; ;\\n;g' helps

<fps>Gxsdnewb: try as root decu stop guix-daemon

<fps>yep, that stops guix-build

<fps>*deco

<Gxsdnewb>Thank you, this works. With no manpage for deco, i didnt know it was the interface to dmd

<Gxsdnewb>My guix edit command does not work. execlp: No such file or directory

<efraim>guix edit is "for developers" but I've never actually used it

<fps>Gxsdnewb: it's mentioned in the manual, which i consulted :)

<fps> https://www.gnu.org/software/guix/manual/html_node/Services.html#Services

<Gxsdnewb>Yes but it is unfortunately nonfunctional on the live 0.8.3 x86_64 image

<Gxsdnewb>Strange that 3 different ...-guile-2.0.9.tar.xz files were downloaded from hydra during sguix system init (with substitutes enabled)

<rekado>Gxsdnewb: have you set up the EDITOR variable?

<Gxsdnewb>no... could that be why GUILEC continuously fails to compile?

<rekado>what error message do you get?

<Gxsdnewb>ERROR: failed to create path for auto-compiled file "...-guile-2.0.11/bin/guild" many many times for dozens of .go files

<Gxsdnewb>I think maybe guix on 0.8.3 is too old to handle the substitutes on hydra

<rekado>I suggest updating to guix from git.

<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>I'm confused.

<rekado>if you use --no-substitutes you will not use substitutes from Hydra, so I don't understand "I think maybe guix on 0.8.3 is too old to handle the substitutes on hydra".

<Gxsdnewb>It was not working before, but now guix system init gives me a new error: open-file: No such file or directory: "...-guile-bootstrap-2.0.drv"

<Gxsdnewb>There is nothing in /gnu/store/ mentioning bootstrap on the live image

<Gxsdnewb>yiiso

<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?

<Gxsdnewb>s/package/dir

<Gxsdnewb>I have run into a frustrating error during compilation of first-stage gcc, as it compiled into /tmp i ran out of space of the ramdisk and the entire guixsd installprocess aborted

<Gxsdnewb>how can i specify guix to compile all outputs (incl temporary) to me target storage temp dir?

<iyzsong>Gxsdnewb: you can run the guix-daemon with TMPDIR set to where you want it be.

<Gxsdnewb>iyzsong is that an env variable? i do not see this option mentioned in the manpage

<iyzsong>yes, the "Invoking 'guix-daemon" section of the info did mention it.

<rekado>building R on mips failed because the tests timed out. Could we raise the timeout threshold on the mips slave?

<Gxsdnewb>i see... and with --cache-failures, will it resume where the build process left off if it fails for some other reason?

<Gxsdnewb>maybe this with --gc-keep-outputs which if i enable can i delete the non-root derivations later with gc?

<mazde>Hello ! Thank you for the good work

<mazde>Will you integrate Hurd ?

<Gxsdnewb>the manual is not very specific on what it means to cache failures

<iyzsong>Gxsdnewb: I think it's: when the build failures of a derivation is cached, a sequence build actions of that derivation won't repeat the actually build phases. it's mainly useful for hydra CI.

<civodul>Hello Guix!

<sneek>civodul, you have 1 message.

<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?

<iyzsong>Gxsdnewb: ok, good luck :-)

<davexunit>civodul: context?

<civodul>davexunit: commit 46c3658

<Gxsdnewb>thnx! :)

<alezost>civodul: really? But in other parts of "guix.texi" there are “``foo'',” but not “``foo,''”

<paroneayea>hello, *

<civodul>alezost: i think it's a Chicago vs. Oxford manual of style kind of issue

<civodul>davexunit is closer to Chicago ;-)

<civodul>hey, paroneayea

<alezost>mazde: there is some work on Hurd+Guix, but I don't know the state of it; perhaps others know: [16:21]<mazde> Will you integrate Hurd ?

<civodul>i'd say that two thirds of the Hurd work is in master

<civodul>the rest is in wip-hurd

<paroneayea>hi civodul !

<alezost>civodul: davexunit: oh, I was sure it's a typo, sorry if it's not

<mazde>alezost: Nice to hear that

<alezost>mazde: also look at what civodul said

<alezost>civodul: but I think we should be consistent, as there are many “``foo'',” but no “``foo,''” at all

<civodul>alezost: yeah, we should

<davexunit>sure, we should be consistent.

<davexunit>the way I learned was to include the punctuation inside the quotation.

<civodul>i would tend to follow Chicago since the thing uses US spelling anyway

<davexunit>I'm not well-versed in the debates amongst different schools of grammar

<civodul>typography, rather

<davexunit>see how ignorant I am of it all?

<civodul>:-)

<toothbrush0>Hell Guix!

<toothbrush0>*Hello

<toothbrush0>(Freudian slip)

<davexunit>:P

<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

<toothbrush0>-L/tmp/nix-build-qt-5.4.2.drv-0/qt-everywhere-opensource-src-5.4.2/qtbase/lib -lQt5Widgets -lQt5Gui -lQt5Core -lGL -lpthread

<toothbrush0>ld: BFD (GNU Binutils) 2.25 internal error, aborting at elflink.c line 8822 in elf_link_output_extsym

<toothbrush0>ld: Please report this bug.

<toothbrush0>collect2: error: ld returned 1 exit status

<toothbrush0>Makefile:221: recipe for target 'dropsite' failed

<toothbrush0>make[5]: *** [dropsite] Error 1

<davexunit>toothbrush0: which version of qt? could it be that qt is broken, and thus a substitute isn't available on hydra? :/

<toothbrush0>hm, um.

<efraim>5.4.2?

<toothbrush0>efraim: indeed, that's the one it's trying to install.

<civodul>Hell toothbrush0! ;-)

<toothbrush0>Pergatory, civodul !

<civodul>heheh

<efraim>we're on 5.5.1 now, but I don't know why 5.4.2 wouldn't have built

<toothbrush0>hm.

<civodul>toothbrush0: i'd say OOM

<civodul>but yeah, use the substitute for the newer one

<toothbrush0>OOM?

<toothbrush0>ah

<toothbrush0>out of memory

<civodul>yes

<toothbrush0>(not Dutch for uncle)

<civodul>oh

<toothbrush0>i'll try using the git version

<civodul>ACTION fearlessly upgrades TeX Live at 904KiB/s

<toothbrush0>i guess i should've done `guix pull` after using the 0.8.3 release...

<toothbrush0>(i've just done a sort-of clean install of my computer)

<civodul>i was planning to provide a test image of 0.9.0 soonish, if you'd like to redo your clean install

<toothbrush0>civodul: that's a good idea, then i can be a guinea pig at the same time.

<toothbrush0>although it wasn't a totally clean install

<toothbrush0>i just blew away /gnu/store

<toothbrush0>and /var/guix

<civodul>okay

<mazde>Is a graphical installer under development ?

<davexunit>mazde: no

<toothbrush0>mazde: menus belong in restaurants!

<toothbrush0>:p

<mazde>davexunit: Why ?

<toothbrush0>(i jest)

<davexunit>mazde: 1) it's a bit early for that 2) no one has done it

<civodul>... but you can help! ;-)

<davexunit>a graphical installer for guix presents interesting challenges though

<mazde>davexunit: It is never early to be user friendly :)

<davexunit>mazde: but things change quickly here

<davexunit>it would be very difficult to have a complex UI keep up

<efraim>i've been thinking about an ncurses interface for managing packages, but the installer's another beast

<davexunit>the distro itself isn't particularly "user friendly" yet, in that we don't have things like GNOME

<toothbrush0>mazde: maybe guix-mode in Emacs is a reasonable compromise for the time being?

<davexunit>that doesn't help with installation, though.

<toothbrush0>true, forget i said anything ;)

<davexunit>it's best that installation is CLI only right now.

<rekado>the installation is semi-automatic, though.

<davexunit>yes, it's not like installing, say, Parabola.

<rekado>we could create a frontend for editing the config.scm file and then reboot and do the rest automatically.

<alezost>davexunit: <http://lists.gnu.org/archive/html/guix-devel/2015-11/msg00041.html> — I wanted to send it to bugs and cc you, but failed at both :-)

<davexunit>rekado: that might be a good idea.

<davexunit>a UI for GuixSD has to be different than a UI for other distros.

<davexunit>we want our users to hack the system.

<davexunit>so any UI we design should be designed with the intent of guiding the user towards that.

<davexunit>give them something comfortable and familiar, but don't hide what's behind the curtain.

<davexunit>ACTION works on sending emails to local meetup groups about guix/guile

<civodul>which reminds me i should send an announcement for my talk next week in Rennes

<efraim>aww i gc'ed my copy of qt and mysql

<davexunit>civodul: :)

<civodul>i hope it's OK to send that on Savannah

<civodul>thoughts?

<davexunit>it is about guix right?

<civodul>yes, in the local GLUG

<davexunit>I think all talk announcements should go on the savannah feed

<civodul>yeah

<davexunit>shows that we're active

<civodul>makes sense

<civodul>we can still revisit that once we have 3 talks per week worldwide ;-)

<davexunit>in addition to making people following us aware of what is going on in their area

<civodul>right

<davexunit>civodul: hehe if we are ever at that scale, we can have a separate event calendar.

<civodul>:-)

<davexunit>we'd probably have GuixCon at that point ;)

<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?

<davexunit>just add a native search path, I guess.

<taylan>?

<civodul> https://savannah.gnu.org/forum/forum.php?forum_id=8394

<taylan>civodul: exciting!

<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.

<mazde>davexunit: Ok

<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).

<mazde>kmicu: :D

<davexunit>nice summary :)

<davexunit>and yes, the political and philosophical difference is that Guix is fully free.

<davexunit>GuixSD, rather.

<davexunit>no proprietary packages included in the distro.

<avoine>alezost: about fix you just did, your missing the system submodule: -e '(@@ (gnu *system*) %base-packages)'

<sneek>Welcome back avoine, you have 1 message.

<sneek>avoine, davexunit says: 'guix environment -e' works with lists now!

<avoine>yeah it's pretty cool :)

<davexunit>:)

<alezost>avoine: ah indeed, all my attention was on a single "@"

<alezost>too many typos

<alezost>davexunit: just in case: did you mean to use "(@@ (gnu system) %base-packages)" in <http://git.savannah.gnu.org/cgit/guix.git/commit/?id=c9c282cea04ec5a3ee7bd17e6ad8846600220feb>?

<alezost>instead of (@ (gnu) %base-packages)

<davexunit>alezost: no

<alezost>ah, (gnu) module will also work!

<alezost>avoine: ^^^

<davexunit>alezost: that would be a bit nicer.

<efraim>if I'm escaping a quote in a substitute string, it's \\" or \\\\\\" ?

<efraim>\\\\\\" I think, \\\\ to "pass the following on" and \\" to "pass the quote"

<davexunit>yeah something like that

<efraim>i passed \\" in the end ;p got cmake parse errors

<efraim>i'll try the replace half of substitute with just "\\""

<efraim>so far looks good, made it past configure and into build

<efraim>my real issue with cmake-build-system: owncloud-client has 27 CMakeLists.txt spread throught the source

<rekado>efraim: cmake is annoying. In the powertabeditor package I had to override variables to make sure that the runpath is not lost.

<efraim>i got owncloud client built, now I'm going back and trying to get it to recognize inotify

<davexunit>paroneayea: did you ever end up trying to package Ring?

<davexunit>looks like we should already have all or almost all of the dependencies.

<paroneayea>davexunit: I never got around to it...

<davexunit>just wondering

<davexunit>I'd like to get Ring and Mumble packaged.

<davexunit>Mumble is higher priority for me because I run a Murmur server now.

<karhunguixi>hm, would it make more sense for guix to stop and complain when user runs something like "guix gc help", instead of just ignoring the second argument and running like normal..

<karhunguixi>(yes, i accidentally did that just now)

<davexunit>it would be good if it threw an error about the extraneous argument.

<karhunguixi>i would've preferred if it did

<davexunit>karhunguixi: could you file a bug for this?

<karhunguixi>sure

<davexunit>thanks!

<civodul>davexunit: did you have a chance to look at the /bin/sh-related 'guix environment' test failure?

<davexunit>civodul: did you get sneek's message earlier

<davexunit>?

<davexunit>if not, let me find what I wanted to tell you

<civodul>oh maybe i got it earlier today but didn't make the connection

<davexunit>IIRC, I said that we should set $SHELL in the check phase