<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.. <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. <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>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` <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 <lfam>Okay, I too only have a little time today <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 <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> /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>anyway, I'm really not interested in debating this with you, to be honest. it wasn't even my idea <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>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 <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 <jmd>Well one idea would be an optional variable GUIX_PROFILE <jmd>or, like you previously suggested, just use directly /var/guix/profiles and forget ~/.guix-profile <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>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. <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 <jmd>We ought to have a "do not edit" warning in grub.cfg <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. <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>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. <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 <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>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" <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
<mark_weaver>jmd: that's a hack to work around an issue on hydra generating very large nar files. <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 <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>$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>grep -i Environment /etc/systemd/system/guix-daemon.service <dtluna>Environment=GUIX_LOCPATH=/root/.guix-profile/lib/locale <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>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. <brendyn>I'm installing Guix on debian on a virtual machine atm <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? <jmd>How do I add a filesystem to my configuration? <jmd>Has anyone had any luck configuring nfs mounts on GuixSD or is that something which can't be done yet? <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. <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? <mark_weaver>looks like xterm has a -u8 option, but I'd still recommend gnome-terminal. <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>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>jmd: Ctrl-C it before it finishes, or add a phase that returns #f <retroj>GUIX_LOCPATH=/run/current-system/locale <mark_weaver>retroj: what is the output of: ls /run/current-system/locale <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. <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 <mark_weaver>it's important to keep up-to-date, because security holes are being publicized and fixed very often. <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 <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_>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.