<lfam>No worries :) Don't hesitate to ask for help
<nunzarius>actually, those additional instructions aren't helping. I'm back to being stuck.
<nunzarius>guix install: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory
<nunzarius>that's the error giving me trouble when I try a "guix install" command
<mange>That probably means that the guix daemon isn't running. I'm not familar with the install script, but step 5 in the manual section "(guix) Binary Installation" is where you install and start the daemon.
<nunzarius>that does look to be the issue. I ran the systemd commands (I'm on fedora) but systemd shows that the daemon failed.
<samplet>peanutbutterandc: One is called “ffmpeg-3.4”, so “(("ffmpeg" ,ffmpeg-3.4))” should do it.
<samplet>(The “@” for versions only works when dealing with a package specification. You need a Guile variable name after the comma there.)
<peanutbutterandc>samplet, I see. Thank you. That makes sense. However, another question: Say for instance I want to have my package definition depend on ffmpeg-4.2.1 right now (because my package might not work with newer versions of ffmpeg). How would I 'freeze' it?
<peanutbutterandc>...to 4.2.1, I mean. It seems that ffmpeg-4.2.1 is defined only as ffmpeg
<peanutbutterandc>Also, if there are any devs around, I have a (probably stupid) idea. Instead of having ffmpeg-3.x and ffmpeg-2.x and ffmpeg-4.x in the same version of video.scm, what if guix could look into the historical git revisions of the file in question and see if the package was defined in an earlier version and use that definition. That way, we would only have ffmpeg latest in the file itself but we would also have the old versions.
<peanutbutterandc>samplet, I see. I was hoping that I could define something like ffmpeg-4.2.1 and even when guix pull is done, my particular package will still refer to the historical 4.2.1 of ffmpeg somehow so as to not break it. Perhaps that is what guix will feature eventually? It was a really interesting read. Thank you very much. Guix continues to impress me more and more!
<samplet>peanutbutterandc: You might also like section 4.8 (“Inferiors”) of the manual. It explains how to grab a single package from an older Guix (e.g., a version of Guix with the version of ffmpeg that you want).
<peanutbutterandc>Also, another thing: (format #t "Copying ~a -> ~a~%" in out) makes me think that lisp format-strings are super different than the normal C-and-family format strings. I should probably read-up on that too.
<samplet>Take a look at the package “wine-staging-patchset-data” in “gnu/packages/wine.scm”.
<peanutbutterandc>I learn more from minutes spent on IRC than hours spent reading the manual, it seems. Thank you very much!
<samplet>Sometime later you should checkout gexps, as they are the more elegant version of all this. Unfortunately, they don’t work with the package abstraction (yet).
<samplet>You are welcome. It’s fun to explain all this, as it proves I’ve managed to learn some of it!
<peanutbutterandc>I see. I will. I am still going through introductory books on scheme/guile but couldn't wait to tinker around with guix packages. Any books etc that you'd recommend? You sure have learned quite a lot! And you managed to explain it in simple terms. I am not very bright student. You are just a good teacher!
<peanutbutterandc>samplet, Sorry to bug you again but I have a quick question. I assume the (substitute* syntax is (substitute* ((regex) (replace)) ((regex) (replace)) ) in pairs inside parens. Is that correct?
<samplet>Not quite. The regex goes inside a list, since you can bind capture groups variables. The replacement is just a string. Hence, I would say “((regex) replace) ...”.
<samplet>I meant to say “capture groups *as* variables”.
<samplet>How about “(substitute* (("find1") "replace1") (("find2") "replace2"))”.
<peanutbutterandc>Yes, that is what I meant (more-or-less). Thank you :) Another question: Do I have to replace every single command I use in the script? Or will just merely substituting coreutils take care of `cat` etc?
<samplet>You should substitute every single command. You might be able to use a trick, like wrapping the script in another script that sets $PATH, but I’m not sure.
<peanutbutterandc>That trick sounds quite interesting. I would like it done once. I'm not sure if I understand things that well to do it yet.
<mange>Hey! I was just running into that problem! The error message is super confusing, but in my case it was because I had written the filename wrong and there was no file with the name I gave.
<mange>It looks like in your case you're trying to get it to substitute on a file at /imglapse.sh (ie. in the root filesystem), whereas I assume you just want to substitute imglapse.sh (ie. in the root of the source directory).
<peanutbutterandc>mange, I see. So how would I point it to the one at my source directory?
<mange>It's because the coreutils bin directory isn't on the PATH. When I was doing my test I was using gnu-build-system which put the coreutils bin directory on the PATH, so then ls could be found.
<mange>You could do (invoke (string-append coreutils "/bin/ls")) and I would expect that to work.
<mange>But then you never actually copy the source file into the working directory, so you won't see in in the ls output. You just copy it straight into the output directory (which you call out), so the easiest thing to do is to substitute it there.
<mange>If so, the issue is that it's putting a file into the output location, rather than a directory. I think it's likely that you actually want to create a /bin/ directory in the output location, and put your script in it.
<mange>You can do that, or you can just copy the one file - that's what I'm doing in the paste I just sent.
<peanutbutterandc>mange, Hmm... I see. Thank you very much. I will work on copying the entire thing (as it contains license info, too)... I don't quite understand why create a /bin dir and all, TBH
<mange>When the package gets installed into a profile it effectively just gets merged into the profile at the root, which means the /bin directory goes to ~/.guix-profile/bin (in the default user profile). When you source ~/.guix-profile/etc/profile it adds ~/.guix-profile/bin to your PATH, which then lets you run the imglapse script as just "imglapse".
<peanutbutterandc>mange, I see. I think that makes some sense. But I might have to re-read that again to grasp it fully. Thank you
<PotentialUser-94>I'm part of Security Team of the University of Milan. We just discovered that the DNS record of data.guix.gnu.org points to a machine of our network. Can please someone tell me what's the purpose of that?
<roptat>PotentialUser-94, that's the guix data service, it analyses commits from the guix git repository
<PotentialUser-94>Sounds good to me, but it's normal that the data service is hosted on a machine on our network?
<roptat>I suppose the service is running on that machine because it was started by someone at the University of Milan
<roptat>I think only they have access to that machine
<fps>hmm, let's say i have some packages in my default user profile and another profile with some other packages. how can i get a shell with just the packages in the additional profile?
<fps>civodul: btw: did you consider adding some branches to the guix repo and have some support in guix pull for them. something like semiregular release tags that only get added when all ci jobs for that particular commit have finished?
<fps>then a user calling guix pull could be sure that binary substitutes are up to date. if he wants more bleeding edge things there could be an option to track HEAD directly instead of the ci-finished-tags
<dongcarl>Question for maintainers: which branch would https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37999#14 go? I see that clang only has around 30 dependent packages, but mbakke says it should go in staging? Is the rationale that since clang is somewhat "fundamental" it probably will cause rebuilds for those maintaining their own channels/manifests?
<nckx>fps: texlive should install it (it's actually in the private texlive-texmf package which is part of that union).
<nckx>Franciman: The problem is that binaries link directly to the exacty glibc that they were built against (so that's very Guix and very good), but they all consume the same unversioned variable GUIX_LOCPATH that can point to only one version. That's my understanding, anyway.
<numerobis>Hi #guix! Don't know where the proper place to say this is, but here is a suggestion: in the documentation for the openssh service configuration, it might be worth saying that a each file passed as argument, when listing the keys for a given user, must end with a newline. This is not a problem when passing a local-file pointing to 'key.pub', as in the example provided, but it is necessary when using
<numerobis>'plain-file' to hardcode the ssh public key in config.scm, and without the final '\n' all the keys are put on the same line.
<nckx>numerobis: Would it make sense to insert a missing newline ourselves? Regardless: bug-guix at gnu.org is the place 2 be.
<numerobis>nckx: the fix I use it to pass (authorized-keys `(("user" ,(plain-file "UNIMPORTANT_FILENAME" "ssh-rsa PUBLIC_KEY\n"))). Thanks for the info!
<numerobis>nckx: whether it makes sense or not for guix (is 'us' guix?) to insert the missing new line, I don't know, but I would say that it is.
<nckx>numerobis: That's a good fix, but if we(Guix)'re the one doing \n-concatenation, I don't think it's the user's job at all to provide the separator.
<dongcarl>nckx: Checked that `llvm` hash remained the same and only `clang` hash changed
<nckx>raghavgururajan: How is root using audio? A full root X session, sudo xprogramme, sudo consolethingy, …
<nckx>Root shouldn't need to be a member of a group to have access to the audio device, but maybe someone somewhere is doing ‘if member_of("audio")’ or something.
<raghavgururajan>nckx Pardon? What I meant was; when I login as root in gdm and try to play any media file, the audio does not work. When I checked sound settings in gnome, there was no speaker detected.
<dongcarl>davexunit: I'll definitely tag you with updates on this channel, and if you have the time, take a look at my recent mailing list posts about clang, as they are all in service of getting osx cross builds to work
<davexunit>dongcarl: sure, I'll take a look. I probably won't have any good input as I have never even begun investigating what osx cross builds require.