IRC channel logs

<davexunit>woot, wrote a quick guile script to spawn a process within another process's namespaces.

<davexunit>now I have a shell inside my container

<davexunit>and a guile prompt inside my container

<davexunit>ugh, I just can't get user namespaces to work right.

<davexunit>apparently I can't create device nodes within one

<davexunit>but I mapped uid 0 of the new namespace to uid 0 of the parent.

<davexunit>so I should be able to do root stuff...

<davexunit>and it seems that I can't join an existing process's mount namespace without having a valid user namespace to join.

<ewemoa>is it correct that 'make install' from source checked out via git will place things under /usr/local?

<ewemoa>er, that is, for guix checked out from git

<ewemoa>s/from/via/

<ewemoa>i'd like for the built result to end up in the store

<ewemoa>this is on a system running guix sd 0.8.2

<davexunit>ewemoa: it would never end up in the store because it's not built via the guix daemon.

<davexunit>you can change where 'make install' installs to by passing the --prefix flag to ./configure

<davexunit>but I don't recommend running 'make install' on a guixsd system.

<ewemoa>davexunit: thanks -- on this guixsd system i'd rather not either

<mark_weaver>ewemoa: did you pass --localstatedir=/var to configure?

<ewemoa>mark_weaver: yes i did

<mark_weaver>ewemoa: okay, good.

<mark_weaver>one nice hack is to make ~/.config/guix/latest a symlink to the top-level directory of your guix git checkout.

<mark_weaver>that symlink is normally set by "guix pull"

<mark_weaver>and the code that it points to is used by all 'guix' commands.

<ewemoa>mark_weaver: ah, that sounds promising indeed!

<ewemoa>mark_weaver: so far the symlink hack seems to be working well -- tyvm!

<mark_weaver>ewemoa: welcome!

<mark_weaver>alezost came up with that hack.

<davexunit>user namespaces are very confusing things.

<davexunit>I got around the device node issue by bind mounting them from the host rather than calling mknod

<davexunit>and now it fails in the system activation script

<davexunit>when it fails to chown the a user's profile

<davexunit>s/a //

<ewemoa>mark_weaver: i summarized the process in some detail here: https://pastee.org/ndfrf -- thanks again

<ewemoa>iyzsong: i'd like to get anthy working w/ fcitx but haven't managed yet -- what i have so far is an attempt at anthy: https://pastee.org/zzs4a and fcitx-anthy: https://pastee.org/yqkva -- any hints on what i'm doing wrong / missing?

<mark_weaver>ewemoa: what is the error?

<mbuf>are there any hosting providers where guix can be used?

<mbuf>or how do people run services on current guix systems?

<efraim>I've been thinking about the scripts that exist to turn digital ocean debian systems to arch, and I think that one is done with chroots, so it should be possible there

<grothoff>Finally got GNUnet to properly build (and pass tests) on GuixSD last night, based on Andreas's package definition.

<grothoff>Now what is left to do is get the setup right -- in particular creation of groups, users and SUID/SGID binaries might be a bit funky, especially if 'guix package -i gnunet' is done by a normal user... Is this even possible?

<ewemoa>mark_weaver: i don't see any relevant errors -- i don't see anthy among the input methods sub menu of the tray icon, nor does it appear among items selectable via the config tool

<iyzsong>ewemoa: look good to me, FCITXDIR should set to ~/.guix-profile to let fcitx find its plugins, for ref: https://github.com/NixOS/nixpkgs/issues/4550

<iyzsong>Should we make 'FCITXDIR' a native-search-paths? Bring it into etc/profile.. Yeah, another search-path with empty files field.

<ewemoa>iyzsong: the FCITXDIR tip works well -- thank you very much!

<iyzsong>great :-)

<ewemoa>i'll try to work on fcitx-hangul next :)

<effa>bavier: Regarding GHC: To use it, I currently define

<effa>export GHC_PACKAGE_PATH="$HOME/.guix-profile/lib/ghc-7.8.4/package.conf.d"

<effa>Maybe we need some search-path specification.

<effa>Nix does have a quite advanced setup for Haskell. nix-shell creates an on-the-fly compiler wrapper with a bunch of custom environment variables (NIX_GHC, ...). Some library, I thihk ghc-paths, has been patched to recognize those variables. See , e.g., http://cryp.to/nixos-meetup-3-slides.pdf

<iyzsong>I just use nix on GuixSD for haskell stuff, it work pretty well..

<effa>iyzsong: I never used nix, so my understanding of their approach is limited.

<effa>If you understand it, maybe you could outline how we could improve our approach.

<iyzsong>effa: I don't know the detail too. But a search-path should be enough for now IMO.

<effa>I didn't add it, because it is harmfull to the haskell-build-system which uses cabal.

<effa>But, probably it is better to just unset GHC_PACKGE_PATH at the beginning of the build system.

<iyzsong>Yes, they are different. I wonder how we can use profile hooks in build-systems.

<effa>what do you meand by "in build-systems"? We use a hook to generate the packages.cache file.

<iyzsong>Hm, I don't know what I said, please ignore me :-)

<effa>:-)

*effa need to go afk

<iyzsong>effa: bye!

<effa>bye

<rekado_>woo, someone just created a package definition for their own bioinfo tool on the bio-packaging mailing list.

<anthk>where is the guix web interface?

<rekado_>anthk: do you mean this: https://gitorious.org/guix-web/guix-web ?

<rekado_>I noticed that I have an unused Macbook sitting in a shelf here; I wonder what would need to be done to port Guix to OSX?

<DusXMT>rekado_: Does the glibc work on OSX? If no, that'd have to be ported

<DusXMT>Hmm, looks like it _is_ ported.

<rekado_>I wouldn't even know how to begin porting Guix to OSX.

<rekado_>I'm especially unsure about how to deal with the kernel dependencies. Aren't the Linux kernel headers a low-level dependency?

<DusXMT>rekado_: They are, but if you really want, you could look at the wip-hurd branch

<DusXMT>However, keep in mind that as far as I know, Ludo is only interested in supporting GNU systems

<rekado_>I'm also not interested in non-GNU systems (personally), but it just so happens that we have a lot of Mac users in science (I don't know for what reasons).

<civodul>Hello Guix!

<rekado_>Hello civodul!

<rekado_>wat? --> "make[7]: stat: libjvm.so: Too many levels of symbolic links"

<davexunit>looks like our (ab)use of symlinks has bitten us?

<rekado_>I'm trying to bootstrap IcedTea7 rather than building it with IcedTea6. It's probably my mistake.

<civodul>oh

<rekado_>looks like a bug in the IcedTea build system (which may have been created by my massive patching): ln -s libjvm.so libjvm.so; ln -s libjvm.so.1 libjvm.so.1;

<iyzsong>I just update evince to 3.16.1. And it seem that we should build libkpathsea as a shared library (from texlive-bin, only have static libraries currently).

<civodul>sure, why not

<civodul>but i don't think we want to have Evince depend on TeX Live...

<iyzsong>so, we need texlive-bin "lib" :-)

<civodul>yeah dunno

<civodul>we need to discuss this on the list

<iyzsong>sure

<civodul>the real question is what functionality do we gain in Evince by adding libkpathsea?

<civodul>i guess probably DVI display or something?

<iyzsong>yes

<iyzsong>I don't used any DVI files though, not very sure.

<civodul>yeah, i guess few people do nowadays :-)

<rekado_>BTW: the cluster admins that I met today are currently working with easybuild. They read the paper on Guix in HPC, but said that they have "no lisp expertise". I assured them that no such thing is required, but it seems that they are quite invested in easybuild and environment modules.

<rekado_>they are also quite excited by docker and "hope" to use docker eventually.

<civodul>interesting feedback

<Steap>rekado_: so, are they not gonna use Guix at all ?

<civodul>i guess it's not completely a rational choice, but hey, it gets the job done

<rekado_>they are still working on getting the server set up (seems they have no proper sysadmins yet so they are just drafting things on slides), so things are still open.

<rekado_>I doubt they will move to Guix though, even though they admitted that easybuild caused them problems.

<davexunit>rekado_: I admire your ability to market Guix to people, though.

<rekado_>what seems to be easier in easybuild (for them) is installation of multiple package versions by name (without the need to write any "scary" lisp code).

<Steap>to be fair, knowledge of Guile helps with Guix :)

<rekado_>what bit them when using easybuild was the failure to capture all inputs; in particular there was a version mismatch with boost or something and they could not easily install the right version.

<rekado_>this problem simply doesn't exist with Guix.

<rekado_>they also seem to be willing to use various tools for package management: easybuild for "core" stuff, virtualenv for Python, <forgot-the-name> for R, etc.

<rekado_>I suggested that Guix could be a simpler layer of abstraction --- once learned.

<rekado_>they and we suffer a bit from having a considerable number of non-expert users, so things need to be "easy".

<davexunit>death by a thousand package managers.

<davexunit>^ someone should name a presentation that

<davexunit>and convince everyone to use Guix ;)

<rekado_>where "easy" does not mean the most powerful tool.

<rekado_>hehe

<civodul>rekado_: i think the multiple-variants-from-the-command-line use case should be addressed

<civodul>--with-source was an attempt in that direction

<rekado_>civodul: I think so, too.

<civodul>but we could easily support things like Spack

<civodul>i do think it's irrational though ;-)

<davexunit>so the use-case is building multiple versions at the command line without writing any Scheme?

<civodul>i mean, for non-trivial variants, you'll want to express something that cannot fit in a single command-line

<civodul>yes

<rekado_>I was a little uncomfortable to tell them our recipe for different versions requires a bit of work: namely, keeping recipes for various versions around.

<civodul>davexunit: like replacing one input with another

*rekado_ has to go now; a colleague wants to use Guix in "ze cloud" and needs help setting it up

<civodul>rekado_: is it a bad thing, that one has to keep the recipes around?

<civodul>oh nice :-)

*davexunit is going to push some updates to wip-container today

<civodul>container = "ze app", right? ;-)

<davexunit>things aren't exactly usable yet, but it *is* possible to run 'guix system container' and see dmd launch and spawn (most) services correctly.

<davexunit>user namespaces continue to be an elusive problem

<Steap>"in ze cloud"

<davexunit>and I've learned that Docker doesn't even properly support them yet.

<civodul>davexunit: sounds exciting!

<civodul>doesn't support name spaces?

<davexunit>the user namespace

<davexunit>the most scary, complicated one.

<civodul>ah, uids

<civodul>ok

<davexunit>I don't know how to do it right.

<davexunit>quite a bit of hair pulling

<davexunit>but I'm learning

<davexunit>for example: you can't call mknod() in a user namespace

<davexunit>makes sense once I thought about it

<davexunit>so now I bind mount /dev/null and co.

<davexunit>but it just pushes the problem elsewhere, like not being able to chown a profile to 'alice', a user within the container.

<civodul>hmm, or you need uidof(alice) in the container to map to uidof(alice) outside, right?

*civodul starts to imagine the difficulties

<davexunit>yeah, not sure what to do there.

<davexunit>dynamically creating users on the host system isn't a feasible solution

<davexunit>I'm not sure what is needed.

<civodul>build.cc doesn't use CLONE_NEWUSER either

<rekado_>civodul: apparently, having to keep track of recipes is seen as an obstacle.

<rekado_>I guess it's because people simply don't want to think about it.

<rekado_>this also explains the enthusiasm for docker.

<rekado_>it's a post-hoc solution.

<rekado_>"i don't know what the hell I have installed here, but to make it easier for others to reproduce what I have here I'll just snapshot the whole environment"

<rekado_><3 the self-contained guix tarball!

<civodul>uh, ok :-)

<rekado_>my colleague just got it set up all by himself and I just had to show how to use it all.

<civodul>yeah that was fast!

<civodul>did you tell the text in fine prints about the wrong UID/GID? ;-)

<rekado_>no. It seems to just work.

<rekado_>Is there still a problem with ownership of / ?

<civodul>with the 0.8.2 tarball, yes :-/

<rekado_>oh.

<civodul>so /, /root, and /var may have wrong ownership

<rekado_>will check.

<civodul>it's interesting that peopl

<civodul>err

<civodul>it's interesting that people jump into easybuild

<civodul>it has relatively few contributors apparently

<civodul>but it has the advantage of looking familiar, i guess

<rekado_>yup, ownership was wrong. Fixed it. Phew!

<rekado_>they did ask me about the number of contributors to Guix.

<rekado_>it seems to be more of a concern to them because: "lisp".

<rekado_>they are okay with python.

<Steap>"well, if you give me money to contribute, one more !"

<Steap>well

<Steap>tell them the type systems are similar.

<rekado_>heh

<rekado_>I told them that it's not at all difficult because we're dealing with a DSL that reads almost like plain English (if you are able to let the parentheses fade into the background).

<civodul>indeed

<rekado_>I feel that their decision is really primarily an emotional one.

<civodul>i have hope that we can overcome anti-lisp feelings because the Clojure people apparently did :-)

<civodul>yeah

<civodul>well, we're humans

<rekado_>I never understood anti-lisp feelings. What's not to like?

<rekado_>my department is still committed to using Guix.

<civodul>+1 for MDC :-)

<Steap>rekado_: crazy syntax

<rekado_>I was a little surprised to hear that they haven't yet packaged for Easybuild as many common tools as I did for Guix.

<Steap>rekado_: you know how you put braces on their own lines in C ? It feels so unnatural to have ")))))))" in Guile after that :p

<civodul>rekado_: and they're in bioinfo as well, right?

<rekado_>so it's possible that if I'm just a little more productive they'll see that it may be more reasonable to just help in packaging stuff.

<rekado_>for Guix.

<Steap>do they have autopackagers for easybuild ?

<rekado_>civodul: yes.

<davexunit>civodul: yeah, I knew about build.cc not using that. that's why running the daemon as a non-root user is harmful.

<Steap>guix import pypi might help them a lot :)

<davexunit>it would actually be really cool to get the daemon to use a user namespace

<davexunit>then the daemon could run unprivileged without concern.

<civodul>davexunit: would be nice; well, now you're the expert :-)

<davexunit>at least, I think it could.

<davexunit>oh god.

<civodul>:-)

<davexunit>blind leading the blind, here. ;)

<civodul>rekado_: are the two labs part of the OpenBio Foundation?

<DusXMT>Steap: Well, in C, you have several different kind of braces, so bunching them up would make blocks a bit more awkward to distinguish. Also, each language has its own set of ideas accos'd with it

<rekado_>Steap: I no longer see closing parentheses at all. I do use paren-face in Emacs to make them a little less prominent, to be fair.

<Steap>yeah, but some people like to use a good text editor.

<Steap>hahem.

<davexunit>paredit solves all problems.

<DusXMT>Steap: If good editor == vi(m), then it has the infinitely handy % function, which jumps between parens

<rekado_>davexunit: exactly!

<rekado_>Steap: well, Emacs has evil-mode for those who cannot kick old habits ;-p

<Steap>DusXMT: yes, just trolling :) It is just a bit awkward to read

<rekado_>(I used evil-mode for quite a while but abandoned it at the same time I switched to Dvorak)

<DusXMT>I think I'll start using evil-mode, I've been using emacs for a couple weeks now, and I just feel so clumsy with it

<rekado_>DusXMT: god-mode is also neat (although it gets in the way when enabled globally).

*DusXMT really misses %, but I guess I can very easily make a function that does that and assoc it with C-%

<rekado_>DusXMT: when working on lisp you may find C-M-{f,b,u,d,SPC} useful. I no longer miss % since I got used to motion by sexp.

*davexunit pushes new wip-cointainer branch

<civodul>iyzsong: could you reply to the David Hashe regarding Evince?

<civodul>you both had the same idea ;-)

<civodul>oh sorry, you already did

<civodul>perfect

<davexunit>I hate rvm so much. guix needs more gems so I never have to use rvm again

<rekado_>+1

<rekado_>hey davexunit, is there a reason why there's no package for guix-web in Guix?

<davexunit>rekado_: because it's meant to be a part of guix proper and isn't built to be installed on its own right now.

<davexunit>I still have like 5 patches from ludo to incorporate into it.

<rekado_>I'm asking because since about two weeks I'm supposed to install a public version of it here to give people a pretty interface to search for bioinfo software packaged for Guix.

<rekado_>I guess I can just take the latest version from git and run with that.

<davexunit>rekado_: it hasn't been updated it some time.

<rekado_>"pretty" is the key word here. The list on gnu.org isn't nice enough, I hear.

<davexunit>if you try it out, I can try to help get it working.

<rekado_>great.

<rekado_>I'll play with it some time this week.

<davexunit>does it need to be able to successfully install packages?

<rekado_>no

<davexunit>okay, cool.

*rekado_ goes afk

<paroneayea>in about 1.5 weeks I can put some time into guix-web too if you all want to work together on it rekado, davexunit

<paroneayea>by then I'll be moved into my new place

<davexunit>paroneayea: oh cool :)

<davexunit>that would be lovely

*davexunit braindumps to guix-devel about containers

<civodul>+1 for guix-web in guix!

<davexunit>guix-web of course is naturally plagued by the problems with package management for web assets.

<davexunit>currently I keep unminified versions of bootstrap, mithril.js, and kefir.js

<davexunit>and underscore.js

<paroneayea>davexunit: in the glorious future we'll make alternatives to all of those with ijp's guile->ecmascript branch right? :) What's another 30 or so yaks at this point?

<davexunit>;)

<davexunit>I just want javascript interop for guile.js

<davexunit>so I can write frontend code in scheme that uses existing js libs

<davexunit>sounds hard, though.

<davexunit>but then again I'm ignorant about a lot of this stuff.

<davexunit>feels good but sort of overwhelming to have so many guix sub-projects in the works.

<davexunit>with a few extra hands, I think the "minimal viable product" version of guix-web can get into guix core in the next few months.

<amz3>having js<->another language interop is not that difficult, I've done it in python

<davexunit>cool :)

<davexunit>I'll stay optimistic, then.

<amz3>like you said, it's a must have

<davexunit>paroneayea, rekado_: with guix-web, we need to make a decision on what our UI framework is. right now, it's mithril (virtual dom) + kefir (reactive programming).

<davexunit>but I'm 100% in love with kefir.

<davexunit>but I want FRP

*paroneayea looks at kefir

<paroneayea>neat, I hadn't seen this

<davexunit>I found kefir to be better than bacon

<davexunit>which is a more popular frp library

<rekado_>I'm not familiar with the latest and greatest in JS. I didn't even know there are usable FRP libraries for JS.

<rekado_>I only used Elm before.

<davexunit>but seems that frp in javascript can never be as nice as it is in Sly.

<davexunit>kefir distinguishes between "behaviors" and "signals"

<davexunit>whereas sly and elm just have "signals"

<davexunit>and signals are just boxes with a current value

<mark_weaver>davexunit: oh, if we implement user namespaces, then unprivileged users can create a proper build container? if so, that's great news!

<davexunit>mark_weaver: yeah, the user namespace would prevent build processes from escaping and getting access to impure things.

<mark_weaver>I should mention one other important feature: after the build ends, we need a way to reliably kill all the processes that could possibly have been launched by the builder.

<davexunit>mark_weaver: killing the init process of the pid namespace should do that.

<davexunit>is it more complicated than that?

<davexunit>when testing my guixsd containers, I just kill dmd and everything dies, AFAIK.

<mark_weaver>davexunit: I don't know, as civodul said, you're the expert now :)

<davexunit>what have I gotten myself into. :)

<mark_weaver>but I can say that it's important for security reasons that build processes must not be able to create a process that survives past the build.

<davexunit>yes.

<mark_weaver>and it's also important that build processes cannot interfere with each other at all.

<davexunit>I'd like to see a case in which that happens

<davexunit>I'm curious how a build process could have access to impurities right now, given that a chroot is used.

<davexunit>is there a way to escape it?

<mark_weaver>in the current daemon, this is implemented by using a separate uid for each build -- never for two separate build processes -- and killing all processes by that uid after.

<mark_weaver>you might need to use cgroups for this.

<davexunit>I'm not sure what cgroups would solve here.

<davexunit>but I don't have all of the possible cgroups committed to my brain yet.

<mark_weaver>apparently systemd uses cgroups to reliably keep track of all processes launched by a given service, to allow killing them all reliably when desired.

<mark_weaver>but maybe there's another solution that problem as well, dunno.

<davexunit>hmm

<mark_weaver>but if we could avoid running guix-daemon as root, that would surely make many people more comfortable.

<davexunit>I'm curious how we even have such a problem. the docs regarding pid namespaces specify that all processes within the namespace are killed when PID 1 (relative to that namespace) dies.

<davexunit>but perhaps I have misread something.

<davexunit>mark_weaver: yes, it would. the cool thing about user namespaces is that an unprivileged user can create one, and then have root within that namespace, but not outside.

<mark_weaver>davexunit: ah, okay. that sounds promising.

<davexunit>the really difficult part for me is the mapping between users/groups inside the namespace to users/groups outside the namespace.

<davexunit>I haven't been able to get it right.

<mark_weaver>well, thanks for looking into this. exciting stuff!

<davexunit>users would still have the issue that the store directory wouldn't be /gnu/store and thus they'd have to build everything for themselves.

<civodul>davexunit: wip-container seems to be in a pretty good shape now!

<davexunit>civodul: yeah, it's getting there. slowly but surely.

<davexunit>I'm happy that I have linux-container-script now.

<civodul>very very cool

<civodul>yeah

<davexunit>g-expressions are the best.

<civodul>i noticed (gexp->script "foo.sh" ...) somewhere

<civodul>you can get rid of the .sh ;-)

<davexunit>civodul: oh

<davexunit>I just copied the style of "run-vm.sh", but that doesn't use gexp->script

<mark_weaver>civodul: your patch to make the 'as' symlink got MIPS further, but now gettext-boot0 fails to build, in configure:

<davexunit>yeah, I'll get rid of that.

<mark_weaver>configure: error: in `/tmp/nix-build-gettext-boot0-0.19.4.drv-0/gettext-0.19.4/gettext-tools':

<mark_weaver>configure: error: C compiler cannot create executables

*mark_weaver looks in config.log

<civodul>mark_weaver: bummer

<civodul>going afk, ttyl!

<mark_weaver>okay, bye!

<mark_weaver>collect2: fatal error: cannot find 'ld'

<mark_weaver>I guess we need an 'ld' symlink as well...

*davexunit re-pushes wip-container with a cleaned up commit history

<efraim>I'm currently playing with updating the packages in enlightenment.scm as a learning experience

<davexunit>:)

<efraim>if they build correctly then comes connman, python-efl and econnman

<efraim>building is one of those times I wish I had something more powerful than my netbook.

<efraim>i forgot to put time in the front of my build command, I think I'm at 30 minutes on efl-1.14.1 so far

<efraim>phase `build' succeeded after 1149 seconds

<efraim>is there a reason most packages are .tar.gz and not .tar.xz or something else more tightly packed?

<efraim>awsome, that finished successfully

<davexunit>efraim: well, a lot of people publish gzipped tarballs rather than xz tarballs.

<davexunit>but if you find that we are fetching a .tar.gz when we could be fetching .tar.xz, feel free to change it.

<davexunit>less bandwidth usage is good.

<efraim>i figured it might be the low-cost bandwidth and the faster untarring

<davexunit>I prefer xz when I can get it.

<efraim>if i've built 1.14.1 and i've downloaded 1.13.0, how do I tell guix to use 1.14.1

<mark_weaver>efraim: can you explain more clearly? I don't understand.

<mark_weaver>what do you mean by "downloaded" and "built" ?

<mark_weaver>built using guix, built by hand? what package?

<efraim>i built efl-1.14.1 and efl-1.13.0 is already in guix

<mark_weaver>and what you mean by "use" ?

<mark_weaver>is it that you currently have efl-1.13.0 in your user profile, and you want to upgrade it to 1.14.1?

<efraim>the next package I was going to try to upgrade is elementary, which requires efl to be at least at the same version number

<efraim>yeah, basically

<mark_weaver>efraim: "guix package -i efl"

<efraim>thats what I thought, but it said it was going to download 1.13.0

<efraim>i don't actually have it installed right now

<mark_weaver>efraim: if it said it was going to download 1.13.0, then it means that your 'guix' has efl-1.13.0 but not efl-1.14.1.

<mark_weaver>more precisely, the set of recipes that is available to your 'guix' has 1.13.0 but not 1.14.1.

<efraim>ok

<mark_weaver>you might have 1.14.1 in /gnu/store, but apparently that recipe is not in your current set of guix package descriptions.

<efraim>i built it with guix build --with-source=efl-1.14.1.tar.gz

<efraim>and since I edited my git clone of guix, I guess I should do `guix build --with-source=enlightenment-1.14.1.tar.gz -L guix-git

*efraim has to afk

<mark_weaver>efraim: maybe try passing the same --with-source to 'guix package -i'

<mark_weaver>(untested)

<mark_weaver>efraim: but the better solution is to just update the package description properly :)

<mark_weaver>another hack is to do 'guix package -i /gnu/store/...-efl-1.14.1' but that has various disadvantages and I don't recommend it.

<efraim>mark_weaver: from the manual guix package does accept build commands, so -i --with-source might work for installing an update or beta release

<efraim>also I haven't forgotten about recompiling the armhf kernel, just been having trouble getting the board to show up on my network so I can do it remotely

<davexunit>efraim: --with-source wouldn't be valid because it's a build option that is sent to the daemon.

<efraim>davexunit: yeah, just tried --with-source and it said unrecognized option

<mark_weaver>efraim: why not just update your package description for efl to 1.14.1?

<efraim>mark_weaver: ... I don't actually know where to do that

<mark_weaver>efraim: "guix package -s efl" tells you where the package description is located.

<mark_weaver>in this case, it is in gnu/packages/enlightenment.scm

<mark_weaver>and then you could submit a patch to update it :)

<efraim>i know its in gnu/packages/enlightenment.scm in the git repo

<mark_weaver>efraim: the official way to run guix from the git checkout is to prefix all commands with /path/to/guix-git-checkout/pre-inst-env, e.g. if you are in that directory already: ./pre-inst-env guix package -i ...

<mark_weaver>if you want to use the git repo for all guix operations by default, make ~/.config/guix/latest a symlink to your git checkout directory.

<efraim>hmmm

<mark_weaver>(that symlink is normally created and updated by 'guix pull', but if you use git instead there's no need to use 'guix pull'.

<mark_weaver>that's what I do, fwiw.

<efraim>that would be convinient, guix pull takes about an hour to process

<mark_weaver>right, it's *much* faster to run 'make' and git.

<mark_weaver>the only caveat is that every once in a while we make a change that requires 'make clean-go' before the 'make', but it's fairly rare.

<davexunit>I need to make that symlink

<davexunit>what a cool hack :)

*davexunit wonders about configuration file templating

<davexunit>I fear it, but I think we might need something like it.

<davexunit>but perhaps not.

<mark_weaver>hmm, this is surprising to me. I ran 'strace -f' on 'youtube-dl' to investigate an SSL certificate problem, and found that it ran 'gcc' to compile a C program.

<mark_weaver>I really hope this is legit...

<davexunit>...

<davexunit>that certainly spooks me.

<efraim>for the symlink hack do I need to go through with ./bootstrap && ./configure && make?

<mark_weaver>efraim: yes, definitely

<mark_weaver>efraim: but make sure to pass --localstatedir=/var to configure

<mark_weaver>that's crucial.

<mark_weaver>and if you're building in a guix environment, you'll also need --with-libgcrypt-prefix=$HOME/.guix-profile

<mark_weaver>well, this is very troubling.

<mark_weaver>I don't see any occurrences of 'gcc' or 'ldconfig' in the youtube-dl source code, but it's being run.

<mark_weaver>I wonder if it's a curl thing, but that would also be surprising.

<rekado>I also see that youtube-dl tries to run gcc.

<rekado>but it doesn't find it, so nothing else seems to happen.

<rekado>[pid 17494] execve("/gnu/store/dlr4klmngff66l845n8kwj61f11a6mh2-bash-4.3.33/bin/sh", ["/gnu/store/dlr4klmngff66l845n8kw"..., "-c", "if type gcc >/dev/null 2>&1; the"...], [/* 54 vars */] <unfinished ...>

<mark_weaver>rekado: yes, same here

<mark_weaver>but so far I've not found the source code that does that.

<mark_weaver>I've looked in youtube-dl and curl so far.

<mark_weaver>for me, it tries to run "/sbin/ldconfig -p" also.

<rekado>could it be cython?

<rekado>this file contains the "if type gcc" stuff: /gnu/store/a2nnfdbr51rji0z85raadic276krbx9s-python-3.4.3/lib/python3.4/ctypes/util.py

<rekado>cmd = 'if type gcc >/dev/null 2>&1; then CC=gcc; elif type cc >/dev/null 2>&1; then CC=cc;else exit 10; fi;' \\

<mark_weaver>I wonder if this is some python-setuptools thing. I vaguely recall that python-setuptools dynamically downloads and installs software on the fly.

<mark_weaver>and that the debian folks specifically rip that crap out.

<mark_weaver>rekado: ah, thanks!

<mark_weaver>civodul: surprising discovery of the day: 'youtube-dl' runs "/sbin/ldconfig -p" and "gcc" to compile a program when it is run.

<mark_weaver>the code is here: /gnu/store/a2nnfdbr51rji0z85raadic276krbx9s-python-3.4.3/lib/python3.4/ctypes/util.py (thanks to rekado for finding it)

<davexunit>so that's a built-in python thing

<davexunit>weird

<davexunit>why?

<civodul>mark_weaver: ouch!

<mark_weaver>we should probably replace that code

<civodul>that's Python's FFI, right?

<mark_weaver>yes, I guess so.

<mark_weaver>it's trying to auto-detect stuff I guess.

<mark_weaver>it runs objdump as well

<civodul>or they do the things that we'd do at macro-expansion time at run time, no?

<civodul>like using the C compiler to determine the value of macros, etc.

<mark_weaver>looking for sonames

<civodul>that file is entertaining

<mark_weaver>well, I'm glad it's legit. for a few minutes I thought I was being hacked.

<civodul>heh

<civodul>it's a good example of bad practices

<civodul>with all the os.name stuff

<civodul>bah

<mark_weaver>yeah, it's pretty gross

<civodul>i'm not sure what the right fix is

<civodul>i think there's not much we can do, no?

<mark_weaver>whatever it's trying to auto-detect, we could just give it the right answers statically. but it would require some investigation.

<mark_weaver>the code also just plain doesn't work if a toolchain is not in PATH

<mark_weaver>well, the reason I started all this is because 'youtube-dl' fails to download from vimeo, because we seem to lack the needed CA: /etc/ssl/certs/c692a373.0, which apparently is for GTE_CyberTrust_Global_Root.pem based on a web search.

<mark_weaver>but sure what that's about...

<mark_weaver>s/but/not/

*mark_weaver investigates

<civodul>the beauty of CAs...

*mark_weaver looks forward to https://letsencrypt.org/ putting them all out of business :)

<anthk>I need an introduction over GUIX

<anthk>about how I can generate my first package

<mark_weaver>anthk: these slides from a tutorial are slightly out of date, but probably still useful: https://gnu.org/software/guix/guix-ghm-andreas-20130823.pdf

<mark_weaver>anthk: this is a very recent mini-tutorial that ewemoa made, much less comprehensive but might also be helpful as a supplement: https://pastee.org/fnkus

<mark_weaver>this CA issue is strange. when I visit vimeo using icecat, I see no problems, and it seems that vimeo is using a different CA than 'youtube-dl' is trying to use.

<civodul>i like the twmn tutorial

<civodul>i like that it uses GUIX_PACKAGE_PATH

<mark_weaver>yeah

<mark_weaver>(even though I encourage people to graduate to using git before too long)

<mark_weaver>but it's good to have a low barrier to entry for starting out

<civodul>heh :-)

<ngz>I think I'm making progress on the locale problem I have.

<ngz>If I do "echo $LANG" in a terminal, I get fr_FR.utf8 even though I set it to fr_FR.UTF-8.

<mark_weaver>civodul: btw, a while ago we had a disagreement about whether it was good to import a source tree into the store as individual files. after more thought, I've come around to your view.

<ngz>Unfortunately, fr_FR.utf8 doesn't match any directory in glib-locales

<ngz>glibc

<ngz>So I get LANG=C everywhere.

<mark_weaver>we should support large numbers of fine-grained derivations

<mark_weaver>and fix any resulting scalability problems

*davexunit still would like to be able to import a filtered local directory as a single store item

<ngz>Do you think there's a workaround in Guix so I can get programs in my locale (and also get rid of warning:failed to install locale at each guix run)?

<davexunit>ngz: guix package -i glibc-locales

<ngz>I did that.

<davexunit>then

<mark_weaver>ngz: how and where are you setting LANG to fr_FR.UTF-8?

<ngz>I also set LOCPATH

<davexunit>oh

<ngz>mark_weaver: /etc/locale.conf (Archlinux)

<mark_weaver>ngz: I guess that something, somewhere, is setting LANG to fr_FR.utf8.

<ngz>If I use env LANG=fr_FR.UTF-8 guix whatever, I don't get a locale error.

<mark_weaver>so, one solution would be to add that locale. instead of using glibc-locales, you could set LOCPATH to some other directory of your own creation, and using 'localedef' to generate the fr_FR.utf8 there.

<mark_weaver>or you can try to find where LANG is being set to fr_FR.utf8

<ngz>I asked on #archlinux-fr. No answer so far.

<ngz>At some point in time, I though they were equivalent "utf8 and UTF-8", but it isn't the case apparently.

<ngz>thought

<mark_weaver>what is the deal with this .utf8 vs .UTF-8 thing anyway? I'd like to know the story behind it.

<civodul>mark_weaver: i don't quite remember what my view was though :-)

<civodul>ngz: are you on GuixSD?

<mark_weaver>civodul: well, you didn't see a problem with importing each file as its own store item, and I thought that was a bad idea. I've gotten over it :)

<mark_weaver>civodul: ngz is on Arch.

<ngz>civodul: no I unpacked a guix binary on top of Archlinux

<civodul>ah, ok :-)

<civodul>so, UTF-8 vs. utf8

<civodul>i thought i had a good reason for choosing utf8

<mark_weaver>even if Guix, we are not consistent about using one or the other. if you grep for '\\.utf8' and '\\.UTF-8' you will find many occurrences of each.

<mark_weaver>I wonder if one of them is deprecated and the other is preferred.

<ngz>Hmm even localectl returns fr_FR.UTF-8

<mark_weaver>*even in Guix

<ngz>I am pointed to https://raw.githubusercontent.com/grawity/code/master/system/locale-check

<civodul>mark_weaver: the "glibc-locales" package, which is The Reference, uses .UTF-8

<civodul>(it's the reference because it's generated using libc's makefile rules)

<mark_weaver>civodul: okay

<civodul>ngz: so you installed glibc-utf8-locales?

<ngz>No, just glibc-locales.

<ngz>Are they different?

<civodul>glibc-utf8-locales is smaller, but that's fine

<mark_weaver>civodul: he installed glibc-locales, but even when he sets LANG=fr_FR.UTF-8, something in arch seems to be setting it to fr_FR.utf8 and then breaking locales for guix programs.

<mark_weaver>ngz: I see that locale-check seems to prefer .utf8

<ngz>Not really. I ran the check and it told me to change fr_FR.utf8 into fr_FR.UTF-8, which I'd like to do.

<mark_weaver>civodul: what kind of summary line would you prefer for that 'add-gas-symlink' patch for the MIPS bootstrap problem?

<mark_weaver>it finally seems to work now that I added symlinks for all the binutils programs.

<mark_weaver>ngz: oh, okay, I skimmed it but apparently too superficially.

<civodul>mark_weaver: something like "gnu: commencement: Use our Binutils as soon as possible"

<civodul>it's good news

<davexunit>has anyone had a problem with using geiser from guix on a non-guixsd machine

<davexunit>I've got some weird behavior here

<davexunit> http://paste.lisp.org/display/149435

<davexunit>any expression I type in throws me deep into error prompts

<davexunit>hmmm, guile load path issue perhaps

<civodul>yes, probably Geiser didn't load all the Scheme-side code

<davexunit>that makes sense, thanks.

<davexunit>not sure what the path needs to be. this has always just worked for me.

<davexunit>I see the modules here: /gnu/store/rjqzf2bwib47a7rl2pxl8236yka674di-geiser-0.7/share/geiser/guile/geiser/

<davexunit>civodul: I did (require 'geiser) instead of (require 'geiser-install)

<ngz>Even .config/locale.conf is turned into .utf8

<civodul>davexunit: ok

<mark_weaver>civodul: pushed

<mark_weaver>and I asked hydra to re-evaluate core-updates.

<mark_weaver>I also started building 'hello' on armhf from this core-updates

<ngz>OK. The locale problem was on the Gnome side. I had to re-install language in my gnome session. Onto the next problem :)

<ngz>When I run "guix something", I have "warning: failed to load '(emacs test indent scheme)': ERROR: In procedure skip_block_comment: emacs/test/indent/scheme.scm:10:1: unterminated `#! ... !#' comment"

<ngz>It doesn't look terribly dangerous, but is it a known issue?

<mark_weaver>ngz: that's strange. I don't know where that's coming from.

<mark_weaver>ngz: maybe you have a file emacs/test/indent/scheme.scm in GUIX_PACKAGE_PATH ?

<mark_weaver>or rather, in a subdirectory of a GUIX_PACKAGE_PATH

<mark_weaver>those directories are scanned for *.scm files and loaded, to look for package descriptions

<mark_weaver>and I guess that the file in question is for some other scheme implementation

<ngz>I see.

<ngz>Actually GUIX_PACKAGE_PATH points to a directory I use for various Lisp-related tasks.

<ngz>I need to make it point to a guix-specific directory then.

<mark_weaver>yes

<civodul>mark_weaver: thanks

<ngz>That did the trick. Thank you again.

<mark_weaver>you're welcome (both :)

IRC channel logs

2015-06-08.log