IRC channel logs


back to list of logs

<Exagone313>This channel is more dead than I thought it could be
<civodul>Exagone313: look, it's alive!
<davexunit>Exagone313: the channel is very active, but it can be low traffic due to the time zones that the regular crowd lives in
<Exagone313>DO I repost my question from 3 hours ago?
<Exagone313>no message since
<davexunit>Exagone313: multiple users installing the same software does not mean that the software is on disk many times
<Exagone313>I meant for multiple versions
<davexunit>there's no way to prevent users from installing what they wish
<davexunit>so yes, multiple versions of the software may exist on the same system
<davexunit>we see this as a feature.
<Exagone313>if foo1 and foo2 install x.y.z, bar1 and bar2 install x.y+1.w, so another version of the same program. Both versions get new releases. Only foo1 and bar1 update. So, is there 4 versions of the program installed?
<davexunit>there would be 2.
<Exagone313>it might add pain to keep the system up-to-date.
<Exagone313>if it's 2, it's ok
<davexunit>I think there's some things to clear up here
<Exagone313>what describes package update?
<davexunit>you would update guix to get new packages
<davexunit>a user would run 'guix pull' to get a new guix
<davexunit>each user may run different versions of guix
<Exagone313>`For instance, when user root runs guix pull, this has no effect on the version of Guix that user alice sees, and vice versa5. `
<Exagone313>so, why not 4 versions in what I said before?
<davexunit>there are 4 users, but only 2 versions of a package were installed.
<davexunit>and there's no duplication since everything is in the same global store
<davexunit>the stuff the user installs ends up just being a bunch of symlinks to the global store
<davexunit>yes to both questions
<davexunit>in that case you'd have 4 versions in the store
<Exagone313>so, there are 4 versions
<Exagone313>that's what was my question
<davexunit>this is a different scenario than presented before
<Exagone313>I didn't explain nicely
<davexunit>or I misunderstood. either way
<davexunit>yes, 4 versions. one user doesn't have power over another to change what they have installed.
<Exagone313>is there a way for admins to force users to update their versions?
<davexunit>someone with root could forcibly run 'guix pull' and 'guix package -u'
<Exagone313>(other than looping each users to update)
<Exagone313>now let's say I have a server. I want to run 2 instances of nginx. So I install on both the mainline version. nginx get a new release. I have to log in on both users to update nginx (the second one will be faster as it's already present on the system)?
<Exagone313>s/on both/on two users/
<Exagone313>you see, there is a need for an alias, I like that user structure but it's the problem I see (that can be resolved)
<davexunit>well, user-based package management doesn't really make sense on servers.
<davexunit>that's more of a desktop use-case.
<davexunit>so let me explain a bit more
<davexunit>there are things called "profiles"
<Exagone313>well, I'm used to computers with only one user
<davexunit>which are sets of packages
<davexunit>when a user runs 'guix package -i emacs', they install emacs into their *default* profile.
<davexunit>it's a convenient thing.
<davexunit>but a user may have any number of profiles.
<Exagone313>what's the goal?
<davexunit>contrived example: let's say you want to use both emacs 25 and emacs 24 for some reason. you can't install them to the same profile because they provide many of the same files and therefore conflict.
<davexunit>so, you could make a second profile and switch to whichever when you need it.
<Exagone313>a reason why it could be used on servers is when you want to use different versions of the same program, it might happen. if you compile on your side you won't have proper update notifications and you have to recompile each time for your path
<davexunit>maybe python 2 vs. 3 is a better example (though they might be parallel installable, making it a bad example)
<davexunit>so profiles are *one* way to manage the software
<Exagone313>env python2 vs env ptyhon3 :P
<davexunit>the point is: software collisions happen, which is why distros that only install to /usr are problematic.
<davexunit>guix avoids this issue in a couple of ways, and profiles are one way.
<Exagone313>my distro even links /bin to /usr/bin, /lib to /usr/lib
<davexunit>you can also just run software directly out of the store without putting it in a profile
<davexunit>$(guix build guile)/bin/guile
<davexunit>you can also use 'guix environment' to launch programs in the context of some arbitrary packages that won't be installed to any user profile
<davexunit>guix environment --ad-hoc ruby -- irb
<Exagone313>what `guix build guile` returns in stdin? path of install?
<davexunit>that would launch a Ruby REPL without ever "installing" ruby to a profile
<davexunit>Exagone313: yeah, it returns the "store path"
<davexunit>something like /gnu/store/longhash-guile-2.0.13
<davexunit>'guix environment' is similar to virtualenv in python, if you've ever used that.
<Exagone313>what about things that are not user-side
<davexunit>the difference being that it can make virtual environments for *any* software, not just python things.
<Exagone313>like diplay manager
<davexunit>now we're getting into GuixSD, which is the distro component.
<davexunit>if you use our distro, there is a configuration management system for this.
<davexunit>and you can specify system services that will run
<davexunit>for example, we have something called slim-service that will start the Slim display manager.
<davexunit>there's openssh-service, mysql-service, nginx-service, etc. we have a small but slowly growing number of interfaces for managing commonly used daemons.
<Exagone313>could it be compatible with multiple init-likes? what about services that would have a different syntax
<davexunit>GuixSD uses Shepherd as the init system
<davexunit>it is also written in Guile, which we use to our advantage.
<Exagone313>ok it's created with guixsd
<davexunit>so the GuixSD service API generates service configurations for Shepherd.
<Exagone313>I don't know much about init, I just know a bit systemd and it does not always look good
<davexunit>Shepherd is still quite young, not as robust as systemd, but it's much more configurable because you write configuration in Scheme rather than the limited systemd DSL.
<Exagone313>what about user-side services?
<davexunit>I think this is something that Guix itself could support better, but at the moment I run my own Shepherd instance as my user to manage things like emacs daemon, offlineimap, mpd, etc.
<Exagone313>also, is there something added, maybe to sudo, to easily add the possibility for an user to run programs by another user? Like having other users for all stuff that could be compromised, like web browser, games, non free stuff.
<Exagone313>this is something I am too lazy to do, but could be useful for security/paranoia
<Exagone313>I code things, type passwords, and on the same user I run non-free games...
<Exagone313>I don't see much multiple human users on the same computer around me. Maybe in a family you can have multiple one. So I imagine use cases with only one human and multiple user accounts
<lfam>There are some tools for running things in containers, which isn't quite what you asked for
<sneek>lfam, you have 1 message.
<sneek>lfam, ng0 says: i'm not sure about the keyservers, sending ed25519 works, receiving.. idk. take a look at for keys. I'll eventually copy that again to
<Exagone313>I think I would have to use multiple Xorg session, so it's offtopic.
<marusich>Hm. I recently upgraded from emacs 24.5 to 25.1 (looks like mark_weaver bumped the version in 846b2534df0138a72fe8ee6a541f97de59697cb0). Previously, in Gnus, when I reply to an an email, if I sign the request (using mml-secure-message-sign-pgpmime) and then send it (using message-send-and-exit), Gnus prompts me TWICE for my secret key. Before this upgrade, it only prompted me ONCE. Any ideas why this might happen? I'd like to not have to
<marusich>select my signing key twice for every reply.
<marusich>I tried rolling back my profile just now and confirmed that the behavior was different. I'm not sure how to troubleshoot an emacs issue like that
<marusich>When I said "Previously, in Gnus, ..." I meant to say "After the upgrade, in Gnus, ..."
<rekado>Exagone313: re multiple versions and admin control: as an admin you can always opt not to allow users to install their own software. You can manage one shared profile that everybody uses.
<rekado>Exagone313: but you also need to realize that the only thing stopping people from building their own software on any shared system is convenience.
<rekado>Exagone313: users can always “just” build from source. It’s just really hard in many cases.
<rekado>installing different versions is not much of a problem in terms of space.
<rekado>at work we have countless variants and multiple versions of the same software and we serve dozens of users, but the shared store is relatively small (about 30GB last time I checked).
<ng0>how broken is idn2 for curl? or does it work? I've seen threads about it on the curl list, but i have not read them yet.. I've just seen the guix side of it
<ng0>all tests succeeded for gnurl with libidn2 in guix
<ng0>if it's broken, it's not obvious
<ng0>read the thread on curl list, and there's some work left to do for them
<ng0>so, what do you propose for our curl and gnurl packages? keep using idn? switch to idn2 experimental? turn off idn builds?
<rekado>ng0: I don’t follow. What’s the context here?
<ng0>curl mailinglist on idn
<ng0>and the libidn2 package which was added in the last 12 hours at guix
<rekado>sorry, that’s not enough for me to understand the questions
<rekado>ACTION goes back to working on Faust2
<ng0>should we switch from idn to idn in curl, that's all I asked
<ng0>support is there, but the errors if there are others than some umlaute are not catched by tests in the curl testsuite
<deathsbreed>Hey, I've been trying to install Guix on my system but I end up getting stuck on step 4 where they ask me to run `guix-daemon --build-users-group-guixbuild', 'cause this command doesn't exist yet.
<deathsbreed>Did I miss something?
<iyzsong>deathsbreed: did you link the ~/.guix-profile, it should at ~/.guix-profile/bin/guix-daemon of user root.
<deathsbreed>iyzsong: the instructions said to link as follows (which is what I did): ln -sf /var/guix/profiles/per-user/root/guix-profile ~root/.guix-profile
<iyzsong>deathsbreed: yeah, then you can run it as `~/.guix-profile/bin/guix-daemon --build-users-group=..', not work?
<deathsbreed>It's running now, I'll come back when it's done. But yeah, I didn't know that's where the executable was located, the instructions never mentioned its location or adding that dir to my PATH.
<deathsbreed>Oh... right... this is a daemon. Perhaps I should've run it on a separate thread....
<deathsbreed>I think I can handle it from here. iyzsong, thanks!
<iyzsong>deathsbreed: yeah, installed packages are available as profiles (symlinks tree) under /var/guix/profiles, and user usually link it as ~/.guix-profile. you can add 'source ~/.guix-profile/etc/profile' to your bash_profile. (See "Invoking guix package" of the manual).
<iyzsong>good luck and welcome :-)
<deathsbreed>I just added .guix-profile/bin/ to my PATH. That should be fine, right?
<iyzsong>there're other environment variables, eg: XDG_DATA_DIRS for desktop applications, INFOPATH for info etc. the etc/profile has all of them.
<deathsbreed>I see.
<deathsbreed>Would trying to authorize a substitute (the one) I got a warning: `warning: failed to install locale: Invalid argument'. It's a warning, so I'm guessing it worked in the end, but that's just my assumption. Is there something I should fix?
<iyzsong>deathsbreed: See '2.6.1 Locales', run the guix-daemon with 'GUIX_LOCPATH' should fix that. you want to do that for normal users too.
<deathsbreed>How exactly would I run the daemon with GUIX_LOCPATH? I've set it in my bashrc and restarted the service, but that didn't seemt o change much.
<iyzsong>if using systemd, something should be added to the guix-daemon.service, like 'Environment=GUIX_LOCPATH=...'.
<deathsbreed>Hmm... seems like it's been added.
<iyzsong>yeah, I see. maybe check the directories under 'locale/2.XX' and your LANG? they should be matched.
<iyzsong>sometimes, I find 'LANG=en_US.UTF-8' doesn't work while 'LANG=en_US.utf8' does, and sometimes the opposite..
<deathsbreed>Yeah, got disconnected.
<deathsbreed>Btw, is usually low on upstream bandwidth? Or is this my side that's being slow?
<deathsbreed>(on the other hand, I am downloading from Europe)
<civodul>iyzsong: i missed the beginning of the discussion, but did you check ?
<civodul>deathsbreed: unless you're using a very old Guix, it should be downloading from, which is usually relatively fast
<deathsbreed>Okay, that tells me my internet is as shitty as always.
<civodul>so is it downloading from mirror.*?
<deathsbreed>My internet is just slow, in general.
<deathsbreed>I should really complain to the ISP.
<iyzsong>yeah, miss that.
<deathsbreed>I think I'm going to leave this for today and study for a bit.
<deathsbreed>Hopefully pick this up tomorrow.
<deathsbreed>Thanks, cya!
<iyzsong>my internet is very slow too :-
<iyzsong>civodul: the 'glibc-locales' package only has 'UTF-8' locales (doesn't work with 'LANG=en_US.utf8'), while 'glibc-utf8-locales' has both.
<iyzsong>ACTION go sleep.
<Apteryx>marusich: You could ask the fine folks on #emacs
<lfam>Trying to upgrade weex to the latest release, I get 'checking build system type... /gnu/store/...-bash-4.3.42/bin/bash: ./config.guess: No such file or directory
<lfam>configure: error: cannot guess build type; you must specify one
<lfam>Any advice?
<lfam>It works when I redo all the autotools stuff
<Apteryx>When I work in a "guix environment", does it allow me to install stuff there using "guix package -i "?
<Apteryx>Or will it still install the package to my regular (non-temporary) profile?
<lfam>Apteryx: No, but you can use `guix environment --ad-hoc` to add things to your current environment
<lfam>No way to remove things, as far as I can tell. I think of `guix environment` as a stack
<lfam>Just push and pop
<lfam>I replied to your first question, meaning "guix package -i will install things to your regular profile"
<ZombieChicken>Is there a wiki for guix(SD) and if not, are there any plans to make one?
<alezost>ZombieChicken: there is no wiki, and I think there are no plans for it
<ZombieChicken>That is too bad
<alezost>I mean official wiki
<lfam>There are unofficial wiki-like things scattered across the net. We'd rather improve the manual relentlessly.
<lfam>Or at least, I'd rather do that :)
<alezost>ZombieChicken: right, I think the policy is to make the manual so good that a wiki will be not needed
<alezost>as for the unofficial wikis, I know about:
<lfam>There is also lots of 3rd party documentation from the bioinformatics community, especially on GitHub
<lfam>There are some interesting things there, lots of examples I found helpful at the beginning
<ZombieChicken>so basically info guix is going to be the 'wiki', so to speak?
<lfam>The problem that I see with wikis, which makes me unmotivated to contribute to them, is that they tend to go stale very quickly, leading to confusion and misinformation. By keeping the docs in the source tree, it's easy to ask for features to be documented
<ZombieChicken>heh. Gentoo's df doesn't seem to like something. It's showing a 100G partition as 93M...
<Apteryx>lfam. OK. My use case is modifying the udisks package defined in freedesktop.scm. I've copied that file under ~/devel/guix-packages/gnu/packages/ and did "export GUIX_PACKAGE_PATH=$HOME/devel/guix-packages". Now how would I go to install it and trying it, knowing that udisks is already installed and up-to-date in my profile?
<rekado>yeah, let’s not let the wikis grow. We’d rather see the manual become better.
<rekado>Apteryx: your modified udisks package could have a new name
<rekado>Apteryx: alternatively you can use the “-e” option (I think) to select a package by variable name.
<Apteryx>rekado: Thanks!
<lfam>Apteryx: If you intend to contribute your changes, it's probably best to clone our Git repo and work in there. That will make it easy to send a patch later
<ZombieChicken>Anyone know of a good alternative to info other than pinfo and emacs?
<civodul>ACTION doesn't
<civodul>you could build the HTML and browse it locally
<civodul>not as good as an Info reader though
<lfam>janneke: mono is failing on core-updates on x86_64:
<lfam>Node is failing on core-updates as well:
<ng0>wasn#t node fixed in master?
<lfam>core-updates has the latest node commit from master
<lfam>I think it's a new problem
<lfam>And inkscape just started failing on core-updates:
<lfam>Somewhere between "a8dd96 to 40330e"
<lfam>inkscape is only failing on armhf, however
<ZombieChicken>Do I need to run guix pull on every user, or does that work system-wide when anyone runs it?
<lfam>ZombieChicken: It's per-user
<lfam>You can make it global by symlinking ~/.config/guix/latest to something like /root/.config/guix/latest. The symlink will be undone next time the unprivileged user runs `guix pull`
<ZombieChicken>k ty
<ng0>ifyou do it the other way around, the symlink sticks
<ng0>ie have agit checkout somewhere, and link $USER path whatever it was to that and symlink the one in root to that
<lfam>Until root runs `guix pull`...
<ng0>ok,i never did that
<wgreenhouse>is there something like a guixsd hardware compatibility list? or would it make more sense to just refer to h-node and docs of other linux-libre-using distros like trisquel?
<lfam>There's no list. Those resources you mentioned are a good bet
<dvc>we can revert the icecat gtk3 patch if anyone thinks it helps, I'm not using it currently anyway ;)
<lfam>dvc: I think the problem existed before that change
<lfam>At least, people reported frequent crashes before it
<dvc>does anyone know how much work it would be to port the icecat bash script to guile? Then we could make it part of the guix package definition and follow firefox releases more closely
<efraim>i've never looked at it
<dvc>and since the firefox branding is released under a free license, all that icecat really does is set some default options, or does it have any dark magic in it?
<dvc>also has anyone seen this error before? python EOFError: EOF read where object expected
<dvc>I keep getting these when trying to build inox. but when I rerun the command that ninja logged it succeeds. Rerunning ninja gives the same error on the next python file.
<lfam>Searching the web suggests a race condition
<dvc>aren't race conditions sporadic?
<dvc>but yeah, that was what I was thinking too
<lfam>I think a race condition could happen deterministically if the build system is designed poorly. I guess it's technically a logic bug in that case
<lfam>Is ninja trying to build in parallel?
<ng0>dvc: it definitely existed before gtk3 patch
<ng0>icecat also does some rebranding
<ng0>like wordings of open source -> free software etc
<ng0>and run some more scripts:
<ng0>include new addons, etc
<ng0>so, yeah it is doable in guile
<dvc>lfam: probably, will try again as soon as I've freed up some computing resources...
<dvc>ng0: one day we will have a modern browser in guix and not just last years browser!
<lfam>We'll suffer today's bugs instead ;)
<ng0>my attempt with palemoon is stuck at the build system of it
<dvc>better to suffer today's bugs than last years bugs or not? :)
<ng0>creates a file at uild time which must be patched, but i have not found the source where it could be changed
<ng0>if at all
<lfam>dvc: Yes, definitely :)
<ng0>the older the bug, the finer the taste
<lfam>ng0: Those are always tricky
<lfam>ng0: Well, I ate an 11 year old bug earlier today. It tasted bitter ;)
<efraim>do we build with double precision?
<ng0>lfam: yeah, the mach build system is okay, but this is the only part I am stuck with so far
<ng0>well the build system is strange, but it works
<thomasd>Hi #guix,
<thomasd>building guix from git, I get "No Guile development packages were found", though I'm in a `guix environment guix`
<civodul>lfam: aren't bugs getting better over time, like wine? :-)
<civodul>thomasd: could you check in config.log why it says that?
<lfam>civodul: I prefer the beaujolais nouveau ;)
<civodul>heheh :-)
<thomasd>civodul: it complains it cannot find guile-2.0.pc in PKG_CONFIG_PATH
<thomasd>even though it is there :/
<lfam>thomasd: Does your interactive shell initialization (for example, .bashrc) set things like $PATH? Or is that variable setting limited to the login shell initialization (for example .bash_profile)
<lfam>`guix environment guix` starts a new shell, so it's possible your .bashrc is clobbering the effect of `guix environment`
<civodul>good point
<civodul>thomasd: see
<thomasd>lfam: as far as I can see, this isn't the case though
<thomasd>and when I `which guile`, i get /gnu/store/mxg3...profile/bin/guile
<thomasd>and in /gnu/store/mxg3.../lib/pkgconfig, there is guile-2.0.pc
<civodul>"guix environment guix --pure -- pkg-config guile-2.0 --libs" does the right thing here
<civodul>does it work for you too?
<civodul>lfam: suggests core-updates is ready, no?
<ng0>w3m fails
<ng0>error: pathspec '0.5.3+git20161031' did not match any file(s) known to git.
<civodul>lfam: only 13 new failing jobs, seems incredibly low
<civodul>ng0: on core-updates?
<ng0>no, master
<ng0>it needs a "v"
<ng0>a leading "v" i mean
<ng0>i'll test this
<ng0>do you want a patch for this 12 characters change?
<ng0>or will someone do:
<ng0>(commit (string-append "v" version)) ?
<ng0>i can send it quickly
<civodul>hmm, w3m is built from a tarball, not from a checkout?
<civodul>or am i missing something?
<ng0>no, a checkout
<lfam>civodul: I hadn't been watching the core-updates jobset, but rather the core-updates-3 jobset. But they appear to have similar results. Are we still having that "stale builds" problem on Hydra?
<lfam>Re: w3m: The release tag is 'v0.5.3+git20161031', with the v
<ng0>i#ve just sent the patch to fix the build
<thomasd>civodul: what should I obtain? I get -L/gnu/store/...guile-2.0.11/lib -L/gnu/store/.../libgc-7.4.2/lib -lguile-2.0 -lgc
<lfam>civodul: If that stale builds problem is gone, I think that core-updates looks ready.
<civodul>wait, i wasn't comparing to master
<civodul>so we have:
<lfam>ng0: Pushed, thanks!
<lfam>civodul: Yes, that's what I'm used to looking at. A longer list...
<civodul>yeah, so ~300 new failures
<civodul>still, not that bad
<civodul>i'll try to fix a few of them
<lfam>civodul: A handful of the failures listed there have been fixed. Check `git log` before you spend too much time :)
<thomasd>civodul: nevermind, I've found the obvious mistake I was making 0_0
<ng0>does someone know why openssl is not deterministic in its build?
<civodul>lfam: oh sure :-)
<civodul>thanks for your work here!
<rekado>I’ll try fixing the fftw-related failures again
<ng0>is there any movement on the ring package set?
<ng0>I've just read that since october ring is a gnu project
<civodul>ng0: see
<civodul>i think we're waiting for feedback from Lukas
<ng0>I've read the thread in my inbox, parts of it
<ng0>maybe someone should ping on that patchset if there's no news in a few weeks?
<ng0>there's a new version out too I think
<rekado>I’m composing a reply to one of Lukas’ emails
<marusich>ng0, I sent an email to him earlier yesterday asking about that very topic
<marusich>It should have gone to the guix-devel mailing list, too
<reepca>quick question - how can I find out the size of a package (not including dependencies)? Is that information not known until it's been installed? I want to compare the size of git to the 200MB I had to install on my brother's Windoze laptop
<reepca>never mind, I bothered looking at the manual - guix size did the trick
<marusich>So, in Icecat, when I run across a page that doesn't seem to be working right due to blocked javascript, it seems that whitelisting the scripts doesn't actually fix the 'broken' page...
<marusich>Is there something else I have to do?