IRC channel logs


back to list of 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>so cool
<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>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: -- 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: and fcitx-anthy: -- 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:
<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.,
<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 need to go afk
<iyzsong>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: ?
<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: 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.
<rekado_>looks like a bug in the IcedTea build system (which may have been created by my massive patching): ln -s; ln -s;
<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
<civodul>the real question is what functionality do we gain in Evince by adding libkpathsea?
<civodul>i guess probably DVI display or something?
<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.
<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
<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
<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> 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 :-/
<civodul>so /, /root, and /var may have wrong ownership
<rekado_>will check.
<civodul>it's interesting that peopl
<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>tell them the type systems are similar.
<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).
<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>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 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.
<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.
<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
<davexunit>I hate rvm so much. guix needs more gems so I never have to use rvm again
<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 isn't nice enough, I hear.
<davexunit>if you try it out, I can try to help get it working.
<rekado_>I'll play with it some time this week.
<davexunit>does it need to be able to successfully install packages?
<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>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.
<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.
<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
<davexunit>g-expressions are the best.
<civodul>i noticed (gexp->script "" ...) somewhere
<civodul>you can get rid of the .sh ;-)
<davexunit>civodul: oh
<davexunit>I just copied the style of "", 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
<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.
<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>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.
<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>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/
<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/ (thanks to rekado for finding it)
<davexunit>so that's a built-in python thing
<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>it's a good example of bad practices
<civodul>with all the stuff
<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 investigates
<civodul>the beauty of CAs...
*mark_weaver looks forward to 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:
<mark_weaver>anthk: this is a very recent mini-tutorial that ewemoa made, much less comprehensive but might also be helpful as a supplement:
<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>(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>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.
<mark_weaver>ngz: how and where are you setting LANG to fr_FR.UTF-8?
<ngz>I also set LOCPATH
<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.
<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
<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>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.
<civodul>mark_weaver: thanks
<ngz>That did the trick. Thank you again.
<mark_weaver>you're welcome (both :)