IRC channel logs


back to list of logs

<lfam>It happened: A dependency cycle for GnuTLS:
<lfam>Plus a security vulnerability
<ng0>yikes. do we need to start hosting copies now?
<lfam>I don't know what the solution is. The short-term solution is to ship a patch.
<lfam>Checking if Nix has addressed this yet
<ng0>unrelated, i messaged with crowd supply and wired money transfers add +5, so I'll add some money to my visa card accound and use the visa option..
<ng0>+ 25 dollar
<lfam>Nix hasn't gotten to it yet
<ng0>ii being weird with $ signs.
<lfam>One possible short-term solution is to use the Nix and Guix content-addressed mirrors. They do get queried even with '--no-substitutes', although I wonder if that's what users expect.
<mark_weaver>lfam: at this point, I doubt that's our own dependency cycle related to https source downloads.
<mark_weaver>*our only dependency cycle
<lfam>mark_weaver: Are we working around the others somehow? Or are we avoiding them by not having updated to the latest version of certain packages?
<lfam>And, can we actually address this bug with a graft, since the bug is in flex's generated code?
<mark_weaver>we're getting around them by having the sources in hydra's store
<lfam>I see
<mark_weaver>no, a graft won't help here at all
<lfam>Okay, do you want me to send a "regular" update patch?
<mark_weaver>lfam: I don't see 'flex' listed in the inputs for gnutls
<mark_weaver>often, tarball releases come with the flex-generated code included. I guess that's the case here.
<lfam>No, I think it's a transitive dependency. It does appear in `guix graph gnutls | grep flex`
<mark_weaver>ah, okay.
<lfam>And, I got a stack overflow when I tried to fetch the source from the HTTPS GitHub link using Guix
<mark_weaver>flex has too many dependencies to push an update to master
<lfam>Back to the old days of "security-updates" branches?
<mark_weaver>what we could do is this: find the set of packages that use our 'flex', and graft each of those to variants that use the new flex.
<mark_weaver>but we'll also need to deal with all of the pre-generated flex code that's in upstream sources
<lfam>Yeah, and how can we deal with all of that? It's a bit overwhelming
<mark_weaver>I have to go afk soon. I'll have to look at this later
<mark_weaver>thanks for bringing it to my attention
<lfam>Okay, I too only have a little time today
<mark_weaver>this is a tricky one. I'll look at it later.
<lfam>I'll be around tomorrow, though
<ng0>do we have something about running Nix on GuixSD or Nix and Guix on a host system in parallel (for build offloading, assuming Nix does support this as well)? I know the Guix documentation had one section
<jmd>I want to have my .guix-profile somewhere other than $HOME Is that possible?
<jmd>What does the function and=> do ?
<mark_weaver>jmd: it's in the index for the guile manual. in emacs, type i and=> RET in the guile info manual
<mark_weaver>~/.guix-profile is just a symlink to /var/guix/profiles/per-user/<username>/guix-profile
<mark_weaver>you can make other symlinks to the same place
<mark_weaver>also see the --profile option for 'guix package'
<jmd>I know. But I don't want to have to pass --profile to *every* call to guix package
<mark_weaver>if you want your default user profile somewhere else, I recommend just making another symlink by hand
<mark_weaver>the secondary profiles created by --profile are inferior in some ways, although I've forgotten the details.
<jmd>But I would have to do that after *every* time I installed/removed a package.
<mark_weaver>no, you wouldn't
<mark_weaver> /var/guix/profiles/per-user/<username>/guix-profile is itself a symlink, and that's the symlink that gets changed when you make changes to your profile
<jmd>ok. so why do we have ~/.guix-profile ?
<mark_weaver>I don't know what was in the mind of the person who came up with the idea, but I certainly prefer it. it's shorter, more memorable, doesn't depend on the value of $localstatedir or $prefix, etc
<jmd>But instead, it depends on $HOME
<mark_weaver>almost everything a user does doesn't on their home, and it's easily accessible in shells by ~, etc.
<mark_weaver>s/doesn't //
<mark_weaver>sorry, s/does doesn't /depends /
<mark_weaver>anyway, I'm really not interested in debating this with you, to be honest. it wasn't even my idea
<mark_weaver>better to send proposals to the mailing list
<mark_weaver>and if you want to use /var/guix/profiles/per-user/jmd/guix-profile instead, feel free :)
<jmd>You sound like the one trying to start a debate...
<jmd>I just wanted advice.
<jmd>The question is, how can I cause guix to use /var/guix/profiles/per-user/jmd/guix-profile instead of ~/.guix-profile ?
<mark_weaver>what do you mean by "use" ?
<mark_weaver>more concretely, what change in behavior are you asking for?
<jmd>I want my PATH etc. to point to /var/guix/profiles/... and not $HOME/.guix-profile/...
<mark_weaver>out of curiosity, why do you want this? I feel free to ask since you're asking me to spend my time to find out how.
<jmd>My HOME is nfs mounted and shared between lots of machines.
<jmd>(not an uncommon situation I think)
<mark_weaver>most of the environment variables are set in ${profile}/etc/profile, based on the value of $GUIX_PROFILE
<mark_weaver>on a GuixSD system, that's handled automatically by /etc/profile, which is created from code in gnu/system.scm
<mark_weaver>search for: (mixed-text-file "profile" ...
<jmd>Yes I have been looking at that this morning.
<mark_weaver>but this sounds like a situation where you're not running GuixSD, so just set $GUIX_PROFILE appropriately before loading ${GUIX_PROFILE}/etc/profile
<jmd>In fact, I am running GuixSD (on some machines).
<mark_weaver>and the .guix-profile symlink points to the wrong place on some of those machines?
<jmd>Well that is my concern. If on different machines a different localstatedir has been used, then the link will be wrong on those machines.
<mark_weaver>well, in that case, using /var/guix/profiles/... won't work either
<mark_weaver>because that "/var" in there is $localstatedir
<mark_weaver>what would you suggest?
<jmd>Well one idea would be an optional variable GUIX_PROFILE
<mark_weaver>we already have that, though.
<jmd>or, like you previously suggested, just use directly /var/guix/profiles and forget ~/.guix-profile
<mark_weaver>what problem would that solve?
<mark_weaver>if the symlink is bad because $localstatedir might be different on different machines, then using /var/guix/profiles has the same problem, no?
<jmd>No. The problem is that guix package (re)creates ~/.guix-profile to point to the *local* /var
<jmd>That is correct on the machine on which guix package is running, but could be wrong on other machines.
<jmd>Hence next time I login on another machine, all my paths will have vanished.
<mark_weaver>symlinks don't point to a local anything. they just contain a string, which is interpreted as a filename on whatever machine the symlink is being read from.
<mark_weaver>so, ~/.guix-profile points to /var/guix/profiles/per-user/jmd/guix-profile
<jmd>I know what symlinks are.
<jmd>That is precisely my point.
<mark_weaver>as long as guix is installed with the same localstatedir on all the machines that you mount your NFS home directory on, then it'll point to the localstatedir on that machine
<jmd>Right. But that condition may not hold true.
<mark_weaver>I acknowledge that, but if it's not true, then your suggestion to "just use directly /var/guix/profiles and forget ~/.guix-profile" would not work either.
<mark_weaver>anyway, I think it would be better to discuss this on the mailing list. if you come up with a concrete proposal, please post it there
<mark_weaver>but that's only a suggestion. if people want to discuss it here, that's of course fine.
<mark_weaver>jmd: I apologize for losing my patience. I acknowledge that the problem you're raising is worth discussing.
<mark_weaver>how do you think we can improve this? the GUIX_PROFILE variable is a good idea, and already implemented. see ${profile}/etc/profile
<jmd>mark_weaver: No problem. I have various ideas on a solution. But I haven't thought through any of them very carefully.
<jmd>I was just throwing those ideas around here to see what people thought and if there were any better suggestions.
<mark_weaver>that's a fine thing to do, of course
<mark_weaver>if localstatedir varies from machine to machine, somewhere during early login the correct profile directory needs to be determined, to allow setting of the environment variables.
<jmd>Is there a way to discover localstatedir from the guix binary?
<mark_weaver>yes, but how do I find the guix binary before I've found the profile, which depends on knowing localstatedir.
<jmd>Yes, you're right.
<mark_weaver>you could add some jmd-specific logic to your ~/.bash_profile, maybe by probing some fixed set of possible localstatedir's for a guix installation.
<jmd>Although it is going to be invariant that /run/current-system/profile/bin/guix is the path to A guix binary I think.
<mark_weaver>on a GuixSD system, it's also invariant that /var is Guix's localstatedir
<mark_weaver> /run/current-system likely doesn't exist on non-GuixSD systems
<jmd>On a different subject completely: Is /boot/grub/grub.cfg intented to be user edited on GuixSD ?
<mark_weaver>no, it's generated every time you 'guix system reconfigure'
<mark_weaver>it's created as a file in the store, and later copied to /boot/grub/grub.cfg
<jmd>So how is one supposed to tweek options in it?
<mark_weaver>on a GuixSD system, the idea is to specify the grub configuration in your OS config
<jmd>For example, how do I set the timeout ?
<mark_weaver>see section 7.2.12 (GRUB Configuration) in the manual
<mark_weaver>timeout is a field of the grub-configuration type
<jmd>We ought to have a "do not edit" warning in grub.cfg
<mark_weaver>good idea
<mark_weaver>would you like to propose a patch?
<mark_weaver>see 'grub-configuration-file' in gnu/system/grub.scm
<jmd>ok. I'll have a look.
<mark_weaver>to insert a header in the grub.cfg, add code before #$sugar that writes to 'port' the desired header.
<mark_weaver>line 273
<jmd>At the risk of asking too many stupid questions today. I suppose it would be a bad idea to have /gnu/store NFS mounted?
<mark_weaver>there can only be one guix-daemon with write access to a given store
<mark_weaver>so if you did this, only one machine would run guix-daemon
<jmd>That's to avoid races I suppose.
<mark_weaver>but rekado is a good person to ask. iirc, he does something like what you suggest
<mark_weaver>well, the canonical information about the store is in a sqlite database
<mark_weaver>the files in /gnu/store are non-authoritative (e.g. there can be directories there that are not valid store paths, and not technically part of the store)
<mark_weaver>(and iirc, that can happen when a build fails)
<mark_weaver>so, if a store were to be shared by guix-daemon instances across machines, they would all have to be using the same sqlite database.
<mark_weaver>but in any case, nothing like this is implemented
<jmd>I don't understand why. If the store contains the union of all the files referenced by all databases, then multiple databases would be fine.
<jmd>But I can forsee other problems too. Like how would you boot?
<sapientech>hi all, noticed guix has a pretty swell monad module, was wondering if that came from somewhere?
<mark_weaver>anyway, rekado would know much more about these issues than I do.
<sapientech>ive been trying to find scheme monads online, but have only found small examples
<mark_weaver>sapientech: I believe that came from the mind of civodul
<sapientech>cool cool!
<jmd>I wish texlive wasn't such a monster.
<mark_weaver>we have texlive-minimal now. it would be good to change uses of 'texlive' to 'texlive-minimal' in package inputs.
<sapientech>was thinking it would be nice to reference tags with git-reference, rather than the specific commit
<jmd>I didn't know about that. Thanks.
<sapientech>do we not do this because someone could change the tags to a different commit
<mark_weaver>sapientech: tags can be used
<mark_weaver>we still have the sha256 hash, so it can't be changed without us noticing.
<sapientech>mark_weaver: oh yeah good call, well in git-download.scm, there isn't anything about tags, is it done another way?
<mark_weaver>sapientech: e.g. see the 'gflags' package in gnu/packages/popt.scm, where the commit field is set to (string-append "v" version)
<mark_weaver>sapientech: guix doesn't need to understand how the commit is specified, because it merely passes it as an argument to "git checkout"
<mark_weaver>see line 45 of guix/build/git.scm
<mark_weaver>(system* git-command "checkout" commit)
<jmd>What is the /gnu/store/.links directory for ?
<mark_weaver>jmd: deduplication. it's a content-addressed store of all files in the store
<mark_weaver>when a file is added to the store, the hash of its contents is computed and looked up in /gnu/store/.links. if it exists there, another hard link to that file is made.
<sapientech>mark_weaver: okay that makes sense, although maybe not overly intuitive
<jmd>mark_weaver: I see. So in fact its files don't occupy any space on disk?
<mark_weaver>jmd: the directory itself, which is essentially a list of (name inode-number) pairs, occupies space, but the inodes in there are also referenced from other places in /gnu/store/
<mark_weaver>(the last step of "guix gc" is to scan /gnu/store/.links looking for inodes that have a reference count of 1, which are deleted)
***erdic_ is now known as erdic
***fkz is now known as Guest16724
<jmd>guix substitute: error: download from '' failed: 410, "Gone"
<mark_weaver>jmd: that's a hack to work around an issue on hydra generating very large nar files.
<mark_weaver>for now, pass --fallback
<jmd>How long will that take !!?
<mark_weaver>actually, texlive-texmf is a very quick build, even though it's huge.
<mark_weaver>it has always been faster to build locally than to download from hydra
<mark_weaver>that isn't the package that contains the programs
<jmd>It would be great to have some heuristic which could guestimate which would be faster.
<jmd>I keep getting this error:
<jmd>guix package: warning: failed to load '(build-aux build-self)':
<jmd>ERROR: no code for module (build-aux build-self)
<jmd>What have I done wrong?
***frafra_ is now known as frafra
<dtluna>Hello, every time I run guix package, I get "warning: failed to install locale: Invalid argument"
***frafra_ is now known as frafra
<cbaines>dtluna, you may need to install glibc-locales
<dtluna>chaines: I have installed it
<dtluna>$LOCPATH and $GUIX_LOCPATH are both set to /root/.guix-profile/lib/locale
<cbaines>Are you running guix on GuixSD or otherwise?
<cbaines>I think on Debian I had to set Environment=GUIX_LOCPATH=/root/.guix-profile/lib/locale in the systemd service file
<dtluna>I am running Parabola
<dtluna>It has that line there
<dtluna>grep -i Environment /etc/systemd/system/guix-daemon.service
<steveeJ>in case of grafting, how can a packager verify that the ABI hasn't changed?
<jmd>steveeJ: I don't think it can.
<jmd>grafts, as I see it, are a compromise between purity and quick deployment.
<steveeJ>it can work if there is a testsuite that uses the binaries. this can either be the testsuite of a dependent package, or one that is shipped with the grafted package
<brendyn>This guide doesn't seem to work
<brendyn>I tried it with 0.11 and it didn't create anything in root
<jmd>Well the first line of that page reads "This post has been updated for the 0.9.0 release of GNU Guix."
<jmd>So it is two releases behind.
<jmd>The canonical guide to installing GuixSD is here:
<brendyn>I'm installing Guix on debian on a virtual machine atm
<brendyn>Since GuixSD can't run on OpenStack
<jmd>In that case, is what you need to read.
<steveeJ>brendyn: why can it not run on openstack?
<brendyn>Well I tried booting it and it doesn't work. Apparently it needs customising before it can work, but I have no idea how to do that.
<jmd>brendyn: I've no idea what openstack is. Neither do I know what you mean by "dostn't work".
<alezost>dtluna: does /root/.guix-profile/lib/locale exist?
<dtluna>alezost yes
<jmd>How do I add a filesystem to my configuration?
<Tsutsukakushi>so, has there been any progress with the support for luks?
<jmd>Has anyone had any luck configuring nfs mounts on GuixSD or is that something which can't be done yet?
<cehteh>oh ... ssl trouble ahead :D
<brendyn>Where is guix.el 0.o?
<brendyn>Ah, just as I noticed the right part of the manual
<kingcons>Hey all! Installing Guix SD on a Thinkpad of mine today but it has an Intel wifi chip. Is there a simple way to go about using Wingo's nonfree package during installation?
<jmd>kingcons: Install over a lan
<jmd>Or pull it out and put an Atherton chip in there.
<kingcons>Thanks jmd.
<retroj>i'm using the terminal emulator urxvt. when i split a view in tmux, the dividing line appears as a series of "â" characters rather than a horizontal line. also when I cat a source file from guix, the copyright symbols appear as "©". this suggests that my system is not configured to use UTF-8 everywhere. how can I fix this?
<retroj>happens in xterm too, so it's not specific to urxvt
<mark_weaver>I use gnome-terminal, which works. I guess that xterm and urxvt are not configured to expect UTF-8 in the terminal output.
<jmd>xterm works fine for me.
<jmd>(at least in that respect).
<mark_weaver>if copyright symbols appear as "©", that indicates that UTF-8 is actually being output by the programs, but that the terminal program is interpreting it as Latin-1
<retroj>i'm going to try gnome-terminal.. i can just do: guix environment gnome-terminal, right?
<retroj>that's awesome
<mark_weaver>looks like xterm has a -u8 option, but I'd still recommend gnome-terminal.
<mark_weaver>(I use gnome-terminal even when I'm in xfce)
<retroj>urxvt has served me so well for years.. and i don't get this problem on other distros, so there is just something i need to configure
<mark_weaver>oh, sorry
<mark_weaver>"guix package -i gnome-terminal"
<retroj>oh ok
<mark_weaver>guix environment gnome-terminal" does something rather different. it spawns a subshell with everyting you need to build gnome-terminal manually from source
<mark_weaver>it may be that other distros have patched urxvt, or perhaps that we're building it incorrectly, somehow.
<mark_weaver>if you'd like to investigate, and submit a patch to fix it, that would be welcome
<retroj>gnome-terminal actually produces an error related to dbus
<mark_weaver>oh, I guess it needs dbus or some other desktop related services that you're missing
<mark_weaver>why don't you read the urxvt man page looking for an option to set utf-8 mode
<retroj>maybe this is related. when i run 'man', i get a warning: man: can't set the locale; make sure $LC_* and $LANG are correct
<retroj>i have no LC_* environment variables
<ng0>there are patches for urxvt as well as for st which can be applied which we do not apply.
<ng0>but utf8 should just work
<ng0>if the © symbol does not appear, it's usually the font
<mark_weaver>retroj: are you running GuixSD, or Guix on top of another distro?
<mark_weaver>is LANG set?
<retroj>yes, LANG is en_US.UTF-8
<mark_weaver>jmd: Ctrl-C it before it finishes, or add a phase that returns #f
<retroj>output of locale:
<mark_weaver>retroj: what is the output of: ls /run/current-system/locale
<jmd>mark_weaver: Thanks
<retroj>mark_weaver: a directory called 2.23/
<ng0>you use urxvt, retroj? maybe your .Xresources (or where you set the config value for urxvt*) has left overs from another distro which used to apply patches which guix doesn't
<mark_weaver>retroj: okay, most likely you still have some programs linked to glibc-2.22, which uses an incompatible locale data format. you could add locale support for glibc-2.22, but it would be much better for update your software, since the old stuff you're running probably has unpatched security holes.
<paroneayea>oh nice, kingcons was in here :)
<paroneayea>I love that guy
<retroj>how do i update everything?
<mark_weaver>retroj: to update the software in your user profile, "guix pull" and then "guix package -u"
<ng0>guix pull; guix package -u .. or system reconfigure for some system parts
<retroj>ah, thank you
<mark_weaver>it's important to keep up-to-date, because security holes are being publicized and fixed very often.
<paroneayea>retroj: also
<paroneayea>"sudo guix system reconfigure /path/to/your-guixsd-config.scm"
<paroneayea>retroj: you'll also want to do that sometimes, since your kernel, base system glibc, and friends should be updated too
<retroj>i have done that more recently than the rest. i somehow missed 'guix package -u' in my reading of the manuals
<ng0>could be because it is provided information, but not in one place like a 'maintaining your system / keeping up to date' section
<retroj>a maintenance section would be helpful
<ng0>can someone with commit access take a look at ? It's a first package contributor, and only needs some fixes which the commiter can apply :)
<retroj>'guix package -u' resolved my problem. thanks!
<jmd>How can I install a locally defined package in the system profile?
<ng0>hey, is libmicrohttpd part of GNU womb descriptions file list? I can not find it, and I want to push a description fix, bit maybe it's unnecessary
<ng0>anyway, version bump is out
<jmd>ng0: Have a look in blurbs
<ng0>well... does this mean I can not update the description to remove this linebreak which looks annoying to me?
<rekado_>jmd: the system profile is modified by changing the OS configuration. When doing “guix system reconfigure /path/to/config.scm” make sure that GUIX_PACKAGE_PATH is specified and the config.scm has a use-modules expression to load your custom module.
<rekado_>if you use “sudo” you can do “sudo -E …” to keep the current environment (including GUIX_PACKAGE_PATH)
<rekado_>ng0: if there’s something wrong with the description in GNU womb it should be fixed there.
<ng0>womb is awful to navigate in its source.. where is the description file
<jmd>How do files like /etc/protocols get created?
<ng0>hrrrrkkkkk....this room is too dark, i just did 'tag all' instead of 'tag single message' ... now I need to filter my filtering..
<rekado_>jmd: see operating-system-etc-service in gnu/system.scm.
<rekado_>it’s provided by an etc-service.
<rekado_>the file is the same as ./etc/protocols from the net-base package.
<rekado_>you can create arbitary files in /etc by means of a custom service.
<jmd>/etc/netconfig is missing
<ng0>what is needed for a 'guix system vm' with qemu forwarded ports?
<ng0>i need to test git-service
<ng0>i mean i can test with localhost, but some kind of in/out network would be better?
<ng0>is the expected default of a git server to be able to locally su git to make changes to repositories, or is it a maintenance users which will be added to the git group to make such changes? I don't want to enforce my way of doing things on everyones system
<ng0>so i was able to git clone.. some setups I use involve ssh+git, i can't test that atm.. is this enough to guess that it works?
<ng0>to test ssh+git, I would need advise on how the qemu forward ports is achieved with guix system vm.