IRC channel logs


back to list of logs

<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>(I forgot the quotes)
<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
<zacts>ngz: ok
<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>oh I see
<ewemoa>fwiw, regarding the tests/packages.scm failure, there is this bit in packages.log:
<zacts>wait, so should I run 'guix pull' first?
<zacts>oh no
<zacts>I don't want to do this
<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?
<ngz>guix pull
<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>ah ok I see
<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 <". You should have a look to the manual, section substitutes.
<zacts>ok I did that already
<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>oh I see
<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?
<ngz>I think so.
<zacts>ah ok cool
<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>oh cool
<zacts>what is the name of the guile-emacs binary?
<zacts>once it is installed?
<zacts>I only see these in my ~/.guix-profile/bin
<zacts>^ I'm assuming emacs-24.4.50 ?
<zacts>as that is the version named in the .png linked from
<zacts>I just want to double check
<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>export GIT_SSL_CAINFO=$SSL_CERT_FILE
<zacts>ok I just found
<zacts>thanks though! :-)
<mark_weaver>that last one is the one relevant for git, but the others are useful for other programs.
<mark_weaver>oh, are you running GuixSD?
<zacts>no I'm on debian still
<zacts>but my link mentions those same ENV variables
<mark_weaver>oh, okay. in that case:
<mark_weaver>if you want to use Debian's CA trust store instead of the one from Guix, you can do this:
<mark_weaver>export SSL_CERT_DIR=/etc/ssl/certs
<mark_weaver>and then the other two settings as above
<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>oops typo
<zacts>SLL instead of SSL
<zacts>alright now it works, and even with the guix nss-certs
<zacts>thanks dude
<zacts>and yes I'm keeping my ~/doc/guix.txt lol
<zacts>and I have online backups of it too heh
<zacts>ah yeah, still no stumpwm
<zacts>I'll just use mine for now
<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.
<cehteh>which makes it rather unuseable
<cehteh>also hogs a lot of memory
<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?
<mark_weaver>I don't think anyone has done that before
<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
<mark_weaver>I guess it's doable without too much effort though.
<cehteh>systemd may barf :D
<zacts>I just wanted to see how involved it might be
<zacts>I'm just waiting for GuixSD full disk encryption
<zacts>but I can wait
<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>catchall :)
<cehteh>well some parts remain and bug me
<zacts>oh does GuixSD use mcron by default?
<k054>mark_weaver: ping! :)
<k054>davexunit: ping :)
<davexunit>that's kosa, who volunteers at the fsf. not sure why he pinged us and then left so quickly, though.
<mark_weaver>ah yes!
<mark_weaver>I met him at the mailling
<mark_weaver>yeah, too bad he left so quickly
<davexunit>perhaps a client issue
<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>not sure how to work around this.
<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>zacts: guix build -K chicken
<davexunit>that will throw something in /tmp for you to look at
<zacts>ok cool
<zacts>but I'm not building chicken I don't think
<zacts>I did
<zacts>'guix package -i chicken'
<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?
<zacts>that's my question exactly
<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"?
<zacts>just a sec
<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>taking 10 min at least
<zacts>but I did do a full guix gc beforehand
<zacts>the slowness happens at the compiling... phase of guix pull
<Oxuodo>Hey guys
<davexunit>hello Oxuodo
<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>Oxuodo: you must bring the interface up
<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
<Oxuodo>Sry for the noobnes
<zacts>rekado: ah ok I see
<rekado>zacts: but chicken has inputs.
<zacts>that answers my question actually
<davexunit>Oxuodo: no problem. our UX isn't the best.
<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
<zacts>ah ok
<davexunit>old builds are removed from hydra periodically
<davexunit>but I'm not sure the frequency
<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
<davexunit>because there's lot of packages to compile
<zacts>will it be this slow for each run of guix pull?
<davexunit>guix pull builds from scratch each time
<davexunit>so yes.
<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 compiling all of the guix source
<zacts>oh I don't want this do I?
<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
<davexunit>they are one and the same
<zacts>oh ok
<davexunit>there's no database
<davexunit>all of the packages are scheme variables.
<zacts>oh I see I think
<zacts>so does it compile those to guile object files?
<zacts>ah ok
<davexunit>that's what takes too long
<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>ah I see
<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
<zacts>davexunit: ah I see
<rekado>with guix pull it's done from scratch.
<zacts>oh cool
<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>rekado: heh, yeah
<davexunit>but that's still wasteful on bandwidth.
<zacts>sorry man
<davexunit>there's not much to convert
<davexunit>make the checkout wherever
<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'
<davexunit>it gets the latest snapshot from savannah
<davexunit>lots to improve with '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" :)
<zacts>oh I see davexunit
<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
<davexunit>zacts: yeah really good progress
<zacts>oh nice
<zacts>davexunit: are you bloggin on this at all?
<davexunit>no. I should.
<zacts>ah ok
<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>yes, I will.
<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>ok odd
<zacts>the guix man page for gcc-5.1 shows "timestamp" as the contents
<zacts>for me
<zacts>davexunit: oh nice
<zacts>davexunit: what is your git server again?
<davexunit>the container stuff isn't there, though, if that's what you're looking for.
<zacts>ok cool
<davexunit>there's a wip-container branch in the official guix repo.
<zacts>oh neat
<davexunit>I'm committing everything I've done today and will update it soon.
<davexunit>not super usable yet.
<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>oh, ./configure before make.
<rekado>see the instructions in the manual and HACKING.
<zacts>rekado: oh
<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>oh cool
<davexunit>I wrote the above snippet when I was unsure if that would always be the case
<davexunit>'guix environment guix' is much nicer
<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.
*davexunit goes to sleep
<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>what error messages?
<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>just a sec
<bavier>ok, not just me then
<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>hm... ok
<bavier>zacts: thanks though
<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>let me show you what I mean
<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>like here's the one for debian
<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
<zacts>hm... cool
<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?
<bavier>`guix import cpan`
<zacts>oh cool
<zacts>let me check it out
<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
<bavier>and also because scheme ;)
<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 file
<efraim>ewemoa: thanks
<efraim>looks pretty similar to what I've been looking at online
<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.
<ewemoa>efraim: my local has a 4.1.1 that contains:
<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/ ;-)
<phant0mas>sneek botsnack
***y is now known as exio4
<taylanub>my mplayer2 is crashing after a guix update and package -u :\\
<paron_remote>hello #guix!
<zacts>mark_weaver: maybe I'll volunteer to investigate
<zacts>let me wake up
<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
<zacts>^ there
<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
<mark_weaver>(the mplayer2 crash)
<civodul>hey, mark_weaver
<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?
<civodul>how should we proceed?
<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>sounds good, then
<civodul>so i could wait for curl-update to be merged, then rebase wip-diet, then build it
<mark_weaver>sounds good, thanks!
<davexunit>guix container exec 30316 /run/current-system/profile/bin/bash
<davexunit>^ launching bash within a running guixsd container :)
<mark_weaver>what is the 30316 ?
<davexunit>the pid of the container's init process
<davexunit>but it could really be any process inside the container
<mark_weaver>ah, okay
<davexunit>next up in 'guix container eval' to eval arbitrary g-expressions.
<davexunit>then cleanup, docs, and tests.
<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>davexunit: do you mean the syscall number?
<mark_weaver>well, it's worse than that. the syscalls work differently on different systems. there's no portability down there.
<davexunit>yeah, the syscall number.
<mark_weaver>consider the Hurd for example.
<davexunit>this particular syscall is Linux-only.
<davexunit>so I just need to cover my bases 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>whereas the raw syscall works like fork
<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>right, that's what I meant.
<civodul>ah ok, sorry
<mark_weaver>the linux syscall numbers are not the same across platforms, afaik.
<davexunit>i was trying to find a lookup table
<davexunit>but came up empty
<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>we'll see
<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 ;)