<ngz>zacts: you need to have glibc-locales installed in your profile, and environment variable LOCPATH set to $HOME/.guix-profile/lib/locale (from .profile or .bash_profile). <zacts>also should I run guix pull before using guix package? <zacts>'guix pull' before 'guix package' <zacts>and does guix pull use binary packages, or does it build them from source? <ngz>zacts: you will also need to do the same from root or you'll get the error substitute: failed to install locale... <zacts>because 'guix pull' is taking a long time for me <ngz>zacts: guix pull only refreshes guix internals and package recipies (which are compiled). It doesn't update packages. <ngz>You need "guix package -u" for that. <zacts>wait, so should I run 'guix pull' first? <zacts>I want to only use 'guix package -u' <ngz>But guix package -u may not do anything if you don't refresh recipe first <zacts>oh how do I refresh the recpies again? <zacts>that's what I was trying to accomplish with pull <zacts>so I do want to run guix pull <ngz>And then guix package -u <zacts>how can I prevent 'guix pull' from building packages from source? <zacts>or does it just normally take a long time to pull? <ngz>It seems I'm not clear. "guix pull" will not build packages. However "guix package -u" will. You can use substitutes and fetch pre-built binaries instead of compiling locally. <zacts>how do I make 'guix package -u' fetch pre-built binaries instead of compiling locally? <zacts>I just want to: 1) update the package list. 2) install some gnu hydra guix binary packages (without actually building them myself from source) <ngz>You have to authorize the build farm (hydra) to furnish substitutes. This is done with "guix archive --authorize < hydra.gnu.org.pub". You should have a look to the manual, section substitutes. <ngz>Then you should already get pre-built binaries. <zacts>so how do I actually command guix package to use packages instead of building from source <zacts>why does 'guix pull' take so long? <zacts>it's only at: compiling... 30% of 433 files <ngz>It compiles all recipes. <ngz>that is scheme files <zacts>what does compile mean in this case, it creates guile object files? <zacts>sorry for all of my newbie questions, I do have a ~/doc/guix.txt to keep track of all the answers though... :-D <ngz>IIUC, this process doesn't scale well and will have to be made more efficient at some point. <ngz>I'm also a guix beginner. <zacts>what is the name of the guile-emacs binary? <zacts>I only see these in my ~/.guix-profile/bin <zacts>^ I'm assuming emacs-24.4.50 ? <mark_weaver>zacts: in general, to answer questions like this, use "guix build <package-name>" to get the directory name in /gnu/store and then look in there. <mark_weaver>or if you've already installed it in your profile and want that one instead of the one that would be build right now, "guix package -I <package-name>" <zacts>I'm searching the Mailing Lists and stuff, but my guix installed git, seems to be throwing some CA certfile error when I do something like 'git clone https://' <zacts>^ this is my git clone error <mark_weaver>if your host system's certificate store doesn't have the same layout as on Debian (and derivatives), then you'll need to set some environment variables. <zacts>I do have one ENV variable set <zacts>namely, 'export SSL_CERT_DIR="/home/zacts/.guix-profile/etc/ssl/certs" <mark_weaver>to avoid having to research where things are on your system, I would install 'nss-certs' in your user profile, and then: <mark_weaver>export SSL_CERT_DIR=$HOME/.guix-profile/etc/ssl/certs <mark_weaver>export SSL_CERT_FILE=$SSL_CERT_DIR/ca-certificates.crt <mark_weaver>that last one is the one relevant for git, but the others are useful for other programs. <zacts>but my gnu.org link mentions those same ENV variables <mark_weaver>if you want to use Debian's CA trust store instead of the one from Guix, you can do this: <zacts>I would rather use the Guix CA trust store <zacts>hum... I'm still getting the same error <zacts>both with your above ENV variables <zacts>and with the /etc/ssl/certs ENV variable <zacts>and yes I did refresh my shell <zacts>alright now it works, and even with the guix nss-certs <zacts>and yes I'm keeping my ~/doc/guix.txt lol <zacts>and I have online backups of it too heh <zacts>(not a guix package, but perhaps I could help with this) <cehteh>mhmpf .. just compiled guile-emacs on debian .. nice try, but its unbearable slow <zacts>cehteh: indeed I did this too, also on debian <zacts>the bootup time for guile-emacs is like 5 min for me <mark_weaver>compilation seems to be disabled in guile-emacs for some reason, and it's making it vastly slower to load and run. <zacts>I'm looking into updating, or adding a new version for tmux-2.0 the latest release <mark_weaver>that's true. I'm just saying that guile can do a *lot* better, and will do when guile-emacs is further along. <zacts>I wonder if I can use a guix linux-libre kernel on debian? <cehteh>i dont think debian has high demands on what kernel is installed <cehteh>some special things and firmware loaders will fail but the base system should come up <mark_weaver>a symlink for the kernel modules would have to be put into place <zacts>I just wanted to see how involved it might be <zacts>I'm just waiting for GuixSD full disk encryption <zacts>(note: I'm hoping to contribute towards this goal too) <cehteh>i like systemd quite much .. its somewhat "fix all problems" thing <cehteh>as soon i purged it, the problems where gone <cehteh>well some parts remain and bug me <zacts>oh does GuixSD use mcron by default? <davexunit>that's kosa, who volunteers at the fsf. not sure why he pinged us and then left so quickly, though. <ejr>I tried to boot GuixSD on an AMD opteron server, it won't boot <davexunit>hmmm, multi-threaded processes cannot enter user or mount namespaces <davexunit>those are the exact 2 namespaces that I cannot enter at the moment. must be the reason. <davexunit>I don't explicitly create any threads in my guile program, though. <davexunit>hmm, forking beforehand seems to do the trick. <davexunit>cool, now I can insert a shell process into a guixsd container to debug some tty problems ***hacker is now known as y
<zacts>guix package -i chicken, is panicing on me during the chicken test phase <zacts>I'm assuming it's a chicken related issue though <zacts>but, where may I find the guix package install log for this session? <zacts>I won't install anything in between this session, and me reading the logs <davexunit>that will throw something in /tmp for you to look at <zacts>but I'm not building chicken I don't think <zacts>so why would chicken be testing itself? <davexunit>how it could it be failing at the test suite phase if you aren't building it? <davexunit>guix automatically builds from source if a substitute isn't available. <zacts>maybe my network connection lagged or something? or hydra was down for a sec? <zacts>let me redo the guix command <zacts>and odd I'm still getting the 'substitute: warning: failed to install locale: Invalid argument <zacts>guix error on every guix command invocation <zacts>even after installing glibc-locales for both the root user, and my local guix user <zacts>(and after adding the PATH to my root and local user's shell's rc file) <zacts>note I'm running Guix on top of debian 8 amd64 gnu/linux, and not GuixSD <rekado>building something locally happens in these cases: <rekado>- you don't have substitutes enabled <rekado>- you have not authorised any source (such as hydra) <rekado>- the package recipes you have are outdated and thus there are no more binaries for them on hydra <rekado>- hydra cannot be reached temporarily <zacts>I did that gpg substitutes thing at the beginning <zacts>or the authorized source for hydra <rekado>what do you see guix say when running the command "guix package -i chicken"? <rekado>it should tell you if it could not get something from hydra. <rekado>it will not tell you about outdated (or too fresh) recipes, though. <zacts>ok let me guix gc, and things. and then guix pull, and I'll try again <zacts>rekado: can waiting to guix pull for too long, cause even a package that doesn't yet need an update to be unavailable on hydra? <zacts>ugh... also guix pull seems to be really slow for me <zacts>but I did do a full guix gc beforehand <zacts>the slowness happens at the compiling... phase of guix pull <Oxuodo>Hi, I'm here to try and solve a problem I'm having when trying to install GuixSD. <Oxuodo>I first tried to install it on a vbox machine but I was not being able to do a dhclient on my network card so I decided to install it on my machine but I'm getting the exact same error. <davexunit>ifconfig <interface> up && dhclient <interface> <rekado>zacts: what do you mean by "doesn't yet need an update"? <rekado>zacts: even if there are no version changes the package recipe may have been updated. <Oxuodo>Oh that makes a lot of sense lol <zacts>rekado: chicken hasn't changed versions since like last year I think <zacts>that answers my question actually <rekado>zacts: when an input changes the resulting package will change. <zacts>so even though chicken hasn't changed versions, perhaps I may still need a 'guix pull' to fetch the guix chicken binary package <davexunit>old builds are removed from hydra periodically <zacts>davexunit: so why is guix pull likely so slow on the compiling phase for me? <zacts>I have an x86_64 / 2G ram / intel multi-core cpu <zacts>will it be this slow for each run of guix pull? <zacts>it just seems if I must guix pull this often, I wonder if it might be an idea to eventually optimize it <zacts>davexunit: "builds from scratch" <-- does this mean it's compiling binaries? <zacts>or do you mean compiling deltas or something? <davexunit>it's not like running 'git pull' and 'make' from an existing git checkout <zacts>I just want to refresh my package data base <zacts>so does it compile those to guile object files? <zacts>I wonder how this could be optimized? <zacts>because it seems I may have to do this even multiple times per day sometimes? <davexunit>we're all aware of the issue, but it's not solved yet. <zacts>is it more of an implementation issue, or a theoretical issue? <rekado>in a git checkout it doesn't take long because most things have previously been compiled already <davexunit>zacts: if you're doing it that often, you should just use a git checkout of your own <rekado>with guix pull it's done from scratch. <zacts>I shall try a manual git checkout then <rekado>"multiple times per day" seems excessive. <davexunit>perhaps 'guix pull' in the future can download a pre-built binary and copy it into the store <zacts>I'll just have to research how to convert my existing guix installation to one I can manually git checkout <zacts>I'm not like guix pulling a ton, I'm just getting my initial setup right now <davexunit>and symlink ~/.config/guix/latest to that directory <zacts>I do want to save your hydra bandwidth too <davexunit>you don't actually talk to hydra for 'guix pull' <zacts>once I get my initial packages installed, I'll probably only guix pull and package install at most once per week, unless I'm doing devel work on guix <rekado>zacts: I meant "excessive" in the sense of "unnecessary" and probably "painful" :) <davexunit>if you're doing any sort of development, having your own local repo is best. <zacts>rekado: oh ok! well perhaps I was a bit over-exaggerated too, due to me being tired, and to the fact that my air conditioner is broken and it's in the 100 deg. Fahr right now <rekado>if you're updating often I really recommend a git clone. <rekado>the first "make" will take a while, but subsequent "git pull && make" will be much faster than "guix pull". <zacts>ok so how can I convert my existing system guix install on debian to use a manual git clone? <davexunit>guixsd containers are so cool. very pleased with how this is turning out. <zacts>oh davexunit you've made progress on this? <zacts>I think the last I was into guix you were just beginning this, like Q3 or Q4 of 2014 or so... iirc <zacts>davexunit: are you bloggin on this at all? <zacts>if you do you should also post to HN <davexunit>I'm just trying to get this code in shape so I can get it merged. <davexunit>there's many missing features, but the very basics are working and you can do things like 'guix system container' to build guixsd containers or 'guix environment --container' to launch arbitrary programs in a container <zacts>the guix man page for gcc-5.1 shows "timestamp" as the contents <zacts>davexunit: what is your git server again? <davexunit>the container stuff isn't there, though, if that's what you're looking for. <davexunit>there's a wip-container branch in the official guix repo. <davexunit>I'm committing everything I've done today and will update it soon. <davexunit>I'm going to post a follow-up on the mailing list with instructions for people that want to test. <rekado>zacts: "ok so how can I convert my existing system guix install on debian to use a manual git clone?" <-- well, clone from git, ./bootstrap, make, and then use "./pre-inst-env guix" instead of just "guix". <rekado>see the instructions in the manual and HACKING. <davexunit>guix environment -e '(@@ (gnu packages package-management) guix-devel)' <davexunit>that can quickly setup an enviroment suitable for building guix <rekado>I always just use "guix environment guix" on GuixSD. <rekado>guix-devel is publicly available as "guix". <davexunit>I wrote the above snippet when I was unsure if that would always be the case <davexunit>soon enough you will be able to do 'guix environment guix --container' :) <rekado>zacts: note that even with "guix environment guix" you still need to pass some configure flags. <zacts>I'm still here for a sec though, but I'll probably pass out soon myself <bavier>has anyone else had trouble with `git send-email` on GuixSD? <zacts>bavier: what is your specific problem? <zacts>(I've found that git send-email often requires perl modules) <bavier>missing perl modules for smtp authentication <zacts>(that I think are undocumented in the git manpages) <zacts>bavier: let me see if GuixSD provides packages for the required Perl modules, and I'll list them to you <bavier>zacts: don't bother, I have a patch set ready with the missing modules already <zacts>bavier: you may also eventually be interested in perlbrew, if you ever decide to test perl modules before packaging them for guix <zacts>also maybe I should make a distro CPAN module for guixsd <zacts>^ see this, you can have perl create GuixSD package definitions / packages automatically of any Perl module on CPAN <zacts>but I would have to code the Perl for it <zacts>so if GuixSD doesn't yet have a Perl CPAN module, we can have them autogenerated for us <bavier>zacts: thanks for the link, I'll have to read through it some more <zacts>bavier: yeah, I may try to do this myself, as I have some experience with Perl <bavier>I write the cpan importer for guix, and have been using that <bavier>but I know it's not nearly so powerful <zacts>so there is a scheme version? <zacts>that autogenerates guix packages of Perl modules? <zacts>it would still be nice to have a CPAN distribution to do this for us also <bavier>zacts: if it could handle upgrades, and some more sophisticated dependency tracking, that'd be great. <bavier>but then again, adding those features to our native guix importer would also be nice, since it would likely help our other importers <efraim>in defining a package, native-inputs are needed for compiling and inputs are needed for running? <ewemoa>efraim: fwiw, there is some info about that in the guix.info file <rekado>efraim: the web manual is generated from the same sources as the info pages. <efraim>is it kept up to date or is it as of 0.8.2 <rekado>efraim: I think the web manual is fixed at the latest stable release. <efraim>ewemoa: i see it now in mine too, thanks <efraim>if i go to package the python bindings for enlightenment, do i put them in python.scm or enlightenment.scm? <davexunit>efraim: enlightenment.scm is probably the best place <efraim>don't want to create cyclical calls ranks higher than python packages in python.scm <mark_weaver>zacts: the problem with 'chicken' is that it started failing on intel platforms recently, when we made some other change. it still compiles cleanly on mips, amusingly. <mark_weaver>so someone needs to investigate what's going on to fix it. <mark_weaver>I think the problem started happening when we updated our default compiler from gcc-4.8.x to gcc-4.9.x <anthk_>how can I delete old snapshots from "guix system reconfigure?" <alezost>anthk_: the system links are placed in /var/guix/profiles/. You need to remove them manually (AFAIK there is no other way, but I may be wrong) <phant0mas>sneek later tell civodul check darnassus /tmp/ ;-) ***y is now known as exio4
<taylanub>my mplayer2 is crashing after a guix update and package -u :\\ <zacts>mark_weaver: maybe I'll volunteer to investigate <zacts>mark_weaver: is gcc-4.9.x <-- is the 'x' supposed to function as an asterisk? <zacts>(#chicken wants to know, as I'm assuming that they may have had problems with a specific 4.9.0 gcc release <rekado>zacts: where do you see gcc-4.9.x? <zacts>rekado: 08:17 < mark_weaver> I think the problem started happening when we updated our default compiler from gcc-4.8.x to gcc-4.9.x <rekado>our 4.9 is 4.9.2 according to gcc.scm <amz3>I'd like to use dns proxy(?) on my machine to speedup the overall slow internet connection. Do you recommend dnsmasq or adns? <amz3>(my connection is static) <mark_weaver>taylanub: it might be related to the recent ffmpeg update <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, phant0mas says: check darnassus /tmp/ ;-) <civodul>mark_weaver: what are your thoughts on building curl-updates vs. wip-diet? <mark_weaver>civodul: well, curl-update is already well along, and it's a security fix. <mark_weaver>so I guess I would prefer to start wip-diet after curl-update is merged, which would be after it is fully built on intel platforms.. what do you think? <civodul>mark_weaver: yes that's what i thought, but i wasn't sure what the status was for curl-update <civodul>so i could wait for curl-update to be merged, then rebase wip-diet, then build it <davexunit>guix container exec 30316 /run/current-system/profile/bin/bash <davexunit>^ launching bash within a running guixsd container :) <davexunit>but it could really be any process inside the container <davexunit>next up in 'guix container eval' to eval arbitrary g-expressions. <davexunit>does anyone know how to figure out the identifier for a syscall on a given platform? <davexunit>my 'clone' wrapper uses the low-level 'syscall' procedure rather than the libc wrapper, and from what I can tell the syscall identifier varies. <mark_weaver>well, it's worse than that. the syscalls work differently on different systems. there's no portability down there. <mark_weaver>most of the things that are syscalls on most platforms actually translate to sending messages to other daemons on the Hurd. <mark_weaver>is there are reason to use the raw syscall instead of the libc wrapper? <davexunit>mark_weaver: yes. the libc wrapper requires allocating a new stack and passing a function pointer. <davexunit>my Scheme clone works exactly like primitive-fork, except that it takes a flag bitmask. <mark_weaver>hmm, if the child shares the address space with the parent, then you'll need to use a new stack location. <mark_weaver>I'm not sure how that's supposed to be handled via the raw syscall. <davexunit>I've looked at other container implementations such as pflask that also do this <mark_weaver>maybe the idea is that after the syscall returns, you don't use the existing stack at all if you're the child. <mark_weaver>I suspect that pflask code doesn't work if the address space is shared between parent and child, which may be fine for their use case. <mark_weaver>well, anyway, I don't know how to know the syscall number for an arbitrary platform on Linux, besides reading the header file. <mark_weaver>it's not obvious to me why it's a problem to allocate a stack and pass a function pointer. <mark_weaver>but if you can make it work portably in some other way, that's fine :) <civodul>IMO the portability we're interested in here is mostly across architectures <civodul>for the Hurd, things will have to be very different <mark_weaver>the linux syscall numbers are not the same across platforms, afaik. <mark_weaver>I suppose we could maintain our own table, but at that point, allocating a stack and using 'procedure->pointer' looks preferable, dunno. <davexunit>i haven't noticed problems by using the raw syscall <davexunit>and I couldn't get the libc wrapper to work right <civodul>mark_weaver has a point, it might be worth revisiting it at some point <civodul>for now it's good that you're focusing on the fun stuff ;-) <mark_weaver>we could just maintain a table for now, and revisit later <mark_weaver>I don't want to distract from the more important work <davexunit>if anyone ever feels like taking a look, feel free ;) 