<mange>The other potential issue would be running "sudo wget ... | gpg" would do the wget as root, but the gpg as your user. The least error-prone way is to run it as root like lfam suggested. <nunzarius>when trying to run guix install I'm seeing an error: <nunzarius>guix install: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory <nunzarius>oh wait. I see there's more to do after the script <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. <nunzarius>I'm not very familiar with systemd so maybe there's somewhere it's outputing useful info. When I run systemctl start guix-daemon it doesn't say anything is wrong <lfam>nunzarius: What happens if you run the guix-daemon manually, as root? Using the path from that error message (the '/var/guix/...' path)? <nunzarius>it gives me a warning about running as root but looks to be working <nckx>nunzarius: Add --build-users-group from the previous lines too. <nckx>(Including the part after =.) <nckx>The daemon will refuse do download things as root. <lfam>I bet it has to do with fish <lfam>Try changing the systemd unit file line ExecStart to begin with '/bin/sh' or '/bin/bash' <nunzarius>I successfully installed the hello package. Where is the systemd unit saved? <nckx>nunzarius: Should be /etc/systemd/system/guix-daemon.service or similar. <lfam>Your paste shows the path to the unit file <lfam>"Loaded: loaded (/etc/systemd/system/guix-daemon.service; enabled; vendor preset: disabled)" <nunzarius>The systemd unit still fails. When I run the command with "/bin/sh" I get a "cannot execute binary file" error <lfam>nunzarius: How did you install Guix? <lfam>After you fixed the PGP error, did the installer script ever finish? <lfam>When you said there was more to do after the script, what did you mean? <nunzarius>The instructions had an "Additional steps" section. I don't think that was actually what I needed. <lfam>The installer script should be sufficient <lfam>Honestly I recommend you remove the directories /gnu and /var/guix and run the installer script again <lfam>Make sure you run it as root <lfam>It will be easier than trying to debug this <nunzarius>It looks like everything is working. thanks so much <peanutbutterandc>Question: Since ffmpeg4.2.1 and ffmpeg 3.4.6 are both in (gnu packages video), how can I specify in the (inputs) that I need ffmpeg 3.4.6 and not ffmpeg 4.x? <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. <samplet>With respect to freezing, we don’t really do that. You can easily freeze all of Guix, but not a specific package. (Not that I know about, anyway.) <samplet>You can mix a package from an older Guix with packages from a newer Guix, though (see again the blog post). <samplet>In one thing I do, I need a specific version of Guile, and I can get it by inheriting and modifying the upstream Guix package definition (for Guile) to use an older source tarball. <samplet>It is not automatic, but it works well enough with a little effort. <vagrantc>haven't managed to figure out how to build cross-compilers for architectures not already supported in guix <vagrantc>but that firmware would enable many allwinner/sunxi systems to liberate yet another bit of firmware... <Gooberpatrol66>If I have guix installed on top of gentoo, can I run "guix system disk-image" to install guix on a flash drive? Or do I need a full installation in order to do that? <marusich>You can do that on any system with Guix, not just on the full distro "Guix System". <marusich>The only thing you can't do on a "foreign distro" is run "guix system reconfigure". <mange>I think the main things you can't do on a foreign distribution is "guix system reconfigure" (and "guix system init", if you want to keep your foreign distro). <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! <marusich>The trivial-build-system requires it. Check some examples in gnu/packages, and I think you'll see how to do it. <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>marusich - I see. But I don't have any idea what I am supposed to supply... I will try to dig around in gnu/packages. Thank you <samplet>You’re welcome. I actually thought the blog post explained inferiors, but I guess I misremembered. Sorry! <peanutbutterandc>It's all right. I'm looking forward to what further cool stuffs the guix developers are going to implement. You have been of major help to me. Thank you all the same <peanutbutterandc>So, the guide says that #:builder argument must be "Scheme expression that builds the package output(s)—as with build-expression->derivation (see build-expression->derivation)." <peanutbutterandc>However, all I have to do with this package is just have it copied to $PATH or something. The script is an executable. It's a really simple thing, really. <samplet>It will mostly just be a matter of using the Scheme function “copy-file”. I’ll take a look and paste something – I’m sitting here waiting for builds anyway. :) <samplet>Put that after the “build-system” form. <peanutbutterandc>samplet, Thank you very much. Now, is there some way/something I can read to understand the code? I would very much like to know how things work <samplet>You can pass extra arguments to build systems via the “arguments” field in a package definition. <samplet>The trivial build system takes a bit of Scheme code that builds the package. <samplet>(Other build systems provide most of the code, which is why they are not “trivial”.) <samplet>The Scheme code is passed to the trivial build system with the “#:builder” argument. <samplet>For the actual Scheme code, the “let*” form defines variables, so I define “source”, “in”, and “out” here. <peanutbutterandc>%build-inputs seems like something predefined. I have encountered something similar with channels.scm: %default-channel or something <samplet>The “source” variable refers to the input with the name “source” (the “assoc-ref” function pulls an element out of a list with named elements, which is what “%build-inputs” is). <samplet>The “%” is not special to Guile, but it is special to us humans. ;) <samplet>It just means that the variable is a “system” variable or maybe a constant. <samplet>TBH, it gets used in a few ways, but it is generally a reminder that the variable is special somehow. <peanutbutterandc>Ah I see. But I still don't understand where the variable comes from. (I'm a python person and we have to import everything (except for a few __builtins__)) <samplet>Guix itself sets up the “%build-inputs” and “%outputs” variables. The are just magically available to us when we write builder code. <peanutbutterandc>I see. That makes some sense. And how does one know if %build-inputs is just a list or a list with named elements? Is it documented somewhere? If so, may I please be guided there? <samplet>Technically, they come from the derivation, which is the low-level representation of something that Guix can build. <samplet>They are both what a Python person would call “dictionaries”. In Scheme land, they are alists. <peanutbutterandc>So you are also defining 'in' to be the 'source' (which I presume is the cloned checkout of the github repo)/imglapse.sh to point to the script <peanutbutterandc>If the script were to be under /bin/ in the repo it would have been (in (string-append source "/bin/imglapse.sh"))? <peanutbutterandc>And %output appears to be where-ever in the /gnu/store that guix decides the packages should go inside? <peanutbutterandc>I feel like a kid learning his multiplication tables and the teacher encouraging my baby steps. :) <samplet>You will need to patch in the locations of Bash, Core Utils, and ffmpeg into your script. <samplet>You are learning very fast! These are hardly baby steps. <peanutbutterandc>uh uh... that sounds like another tough thing. I'm afraid you will have to walk me through it again. (I'm a n00b) <samplet>To do the patching, I highly recommend finding an example. Do you have local copy of the Guix source code? I could point you in the right direction if so. <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”. <samplet>It does almost exactly what you are trying to do, with the exception that it copies a whole directory instead of a single script. <samplet>First thing to notice, is that there is another keyword to the “arguments” form: “#:modules”. <samplet>This tells the trivial build system to give us access to the “(guix build utils)” module, which provides the “substitute*” macro. <samplet>Next thing to look at is the “substitute*” macro. :) <samplet>It is essentially like running “sed -i”, but in a Scheme-like interface. <samplet>Basically, it says open up some file, and replace anything that matches a given regex with a given replacement. <peanutbutterandc>patches/patchinstall.sh and patches/gitapply.sh must be shipped with guix itself, I presume? <samplet>Nope. They are part of the package source code. They play the role of your “imglapse.sh”. <samplet>The “bash” variable points to “/gnu/store/...-bash-x.y”, but you want the actually “bash” binary. Hence, you add “/bin/bash” to the end of it. <samplet>You want to provide the absolute location (in the Guix store) of the programs the script calls. <peanutbutterandc>Ah that makes sense!!! In my case it would probably be something like (substitute* "imglapse.sh" (("/bin/bash") (string-append bash "bin/bash")))? <peanutbutterandc>And also (ffmpeg) (string-append ffmpeg "bin/ffmpeg") or something similar, I would guess <samplet>Yup! And “bash” would come from “(assoc-ref %build-inputs "bash")”. <peanutbutterandc>I see. Ah. I have to use (assoc-ref %build-inputs "bash") because just bash refers to the package as provided by (gnu packages bash) and not the /gnu/store location for bash <peanutbutterandc>But how about coreutils? I use cat etc in my script and coreutils is a meta-package. <samplet>Actually, just “bash” would be an undefined variable. The builder script does not know about packages. <samplet>The “coreutils” package just has a bunch of binaries, so “(string-append coreutils "/bin/cat")” is fine. <samplet>In the inputs, it is a package, but it gets “lowered” to just the path en route to the daemon. <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>I did a sneaky hack to work it out. :P I did (invoke "ls" "-R") to find out exactly where all the files ended up, then changed my substitute* path based on that. <mange>The working directory of the builder is the same each time, so running ls -R gave me enough information to write a relative path to the right file. <mange>Let me try it out. Part of the difficulty here is that trivial-build-system is missing a bunch of the niceness that gnu-build-system gives you. <mange>Ah, okay, if I replace "imglapse.sh" with out, then I can get it to build. <peanutbutterandc>mange, I see. I will try that now. Also, how come I am unable to (invoke "ls" "-R")? Do I have to use any module? <peanutbutterandc>Oh... perhaps because we copied just the file and not the entire git-cloned 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>Where are you getting that error? <mange>Is it when you try to install it to your profile? <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. <peanutbutterandc>Perhaps in the (copy in out) section, rather than just copy the file, I should copy the entire git-cloned directory... that is what seems to have been done in a gnu/packages sample <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 <nly>i want to do a guix system reconfigure to update my system but any later version than kernel 4.19.69 seems to not work, as in the system won't boot. <leoprikler>nly: have you tried inserting 4.19.69 into your config via inferiors? <leoprikler>(or perhaps by just defining a new kernel package as they do in gnu/packages/linux.scm) <leoprikler>you're missing the less package in your let-bindings <nly>efraim sadly 4.19.81 doesn't <nly>leoprikler, thanks i should try inferiors <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 <roptat>I think you should have cbaines for more info :) ***porto is now known as Pinkukumo
<Pinkukumo>maybe it should be specified that it's similar software to init and systemd on that page, for noobs like me <leoprikler>there's also currently no way to replace it with systemd if you wanted that ***amfl_ is now known as amfl
<leoprikler>"It provides a replacement for the service-managing capabilities of SysV-init (or any other init)" ***Pinkukumo is now known as porto
<efraim>civodul: do you remember, when I build bootstrap-tarballs, am I supposed to use --no-grafts or not or should it not matter <efraim>looks like it's not supposed to matter <Franciman>I install guix system. After that, from my user, I run guix pull <Franciman>it says I should set GUIX_LOCPATH to something in my profile <Franciman>Am I doing something wrong? or is this needed on guix system too_ <bdju>I think that's needed on Guix System too <bdju>I have in my ~/.profile export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" <efraim>looks like the files in GUILE_SYSTEM_COMPILED_PATH for guile-static-powerpc are segfaulting, but if I set the wrong directory it seems to work <efraim>happens with the one from core-updates too <efraim>I wonder if its a big-endian/little-endian problem or something wrong with the creation process <roptat>Franciman, actually, it's not needed on the guix system when the system and the user both have the same libc version, and the locale is one of the glibc-utf8-locales package <roptat>when you did a guix pull, it updated the glibc used by guix to 2.29, but your system was not updated and still uses 2.28 <roptat>so either set the variable to fix the warning, or also update your system with "guix system reconfigure" using a recent guix, which will install the more recent glibc for the system <roptat>I wonder how we could detect this difference in version when we print that hint... we could be more precise then :) <Franciman>when I run `guix system reconfigure` do I need to use sudo? <Franciman>but I get some errors saying that I didn't run guix pull for root <Franciman>even if the manual explicitly says that sudo guix still runs the guix for my user profile <jetomit>Franciman: try sudo -E guix ... to run the guix from your user profile <fps>hmm, i tried installing python-virtualenv and then using it to create and populate an environment [python virtualenv environment] <fps>creation and activation worked fine, but using the pip installed with the virtualenv fails <fps>anyone seen this before and knows what the fix is? <fps>python -m pip works instead of just using pip <iyzsong>fps: don't know, you can use 'python3 -m venv' instead of 'virtualenv', venv works for me. <Franciman>but, what is the right way to update the system? <nckx>Franciman: guix pull && sudo -E guix system reco… should always work. <Franciman>it says one should run: sudo guix system reco... <nckx>I think the -E can be dropped on Guix System but I'm only 98% sure. *elixx is gone.. autoaway after 15 min ..[cyp(l/on.p/on)] <nckx>If the manual says so, I'd trust the manual. Could you file a bug? <nckx>(I use my own sudoers so not up to date on the defaults.) <nckx>Franciman: So -E works for you where plain ‘sudo’ does not? <Franciman>plain `sudo` complains that I never ran guix pull for root user, i.e. there is no /home/root/.guix-profile directory <nckx>Franciman: OK. That's surprising to me, I really thought env_keep was supposed to be the default on Guix System now 🤷 <nckx>Franciman: Was your system old? Maybe it predated the change, and sudo will work next time (possibly after a reboot). <Franciman>ah I also need guix system reconfigure I guess <nckx>If you pulled before installing, you should have booted into the newest Guix available at the moment of installation. <nckx>If you pulled after installation, the ran guix package -u (but not guix system reconfigure), your ‘base system’ (including Guix itself) will be 1.0.1 — pretty old. <nckx>OK. Then your installed system should have been up to date. <htgoebel>I'm struggling with getting debug symbols for a cmake-build package <htgoebel>I set #:buildtype "debugfull", but when running the executable gdb says "No debug symbols found" <roptat>htgoebel, I think there is a strip phase that removes symbols <roptat>in the gnu build system the cmake build system inherits from <htgoebel>roptat: I did not mention that I try to debug test failures, thus the strip phase has not run at this point <htgoebel>OTOH the segfault occurs in another package, thus I need to remove the strip-phase from that other package. <htgoebel>Nevertheless I'm missing the symbols for the "current" package. <htgoebel>Seems as using gdb is more complicated than I thought <civodul>if you're using gdb in the first place, adding one line to .gdbinit is probably not that complicated ;-) <htgoebel>But there are many manual steps: redefining and rebuilding the packages, unpacking the source, setting up gdb, going into the container/environment <htgoebel>Bying a Python developer, I'm not used to such :-) <janas>I'm unsure about how to remove old versions of the current-guix profile from my system <roptat>guix pull --delete-generations[=PATTERN] should do it :) <roptat>if your guix is a bit old, then guix package -p /var/guix/profiles/per-user/<user>/current-guix --delete-generations <janas>roptat: Thanks for the help! I just got it to work with guix package -p ~/.config/guix/current --delete-generations=[...] <htgoebel>civodul: More important: I can't get the cmake-build-system to generate debug symbols. Hat is the trick? <civodul>htgoebel: you'll probably need to add a "debug" output to your package <civodul>otherwise binaries are stripped in the 'strip' phase <htgoebel>civodul: ACk, but the package fails to build in the test-phase, thus the strip-phase is not run <civodul>davexunit: thanks for editing & pushing the post! ↑ <fps>raghavgururajan: in the source ;) <roptat>you could also use the guix repl <roptat>,use (gnu services base) \n ,use (gnu services) \n (map service-type-name (map service-kind %base-services)) <roptat>(replace \n with actual line break) <raghavgururajan>fps roptat Also, I am trying to use enlightenment DE. Does it have it's own DM? <roptat>I don't think so, but I don't use enlightenment <civodul>raghavgururajan: you can also try "guix system extension-graph config.scm > /tmp/t.dot" <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 <roptat>fps you can do "source <other-profile>/etc/profile" I think <nckx>roptat: That'll append most variables, though. I'm unsure how to do this myself. <nckx>Something like ‘env -i `which bash` --rcfile ~/.guix-profile/etc/profile’ clears too much, like $DISPLAY. <nckx>It's a deceptively simple question 😛 or there's a simple answer of which I'm unaware. <fps>it's also of great utility <fps>or rather: it would be of great utility. <fps>and is there a way to search all outputs produced by all packages? <fps>i can't for the live of it figure out what package has todonotes.sty <ng0>fps: have you tried searching on cpan? <ng0>going by the guix naming, tex-todonotes or tex-contrib <ng0>i haven't verified if those exist <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). <fps>nckx: texlive is 2.4G though <fps>i wanted to avoid that (i used it previously but that really is madness) and install packages more granually <nckx>fps: I just answer the questions, I don't defend their answers 😛 <fps>so basically i cannot install it unless i install the whole thing? <fps>how did you find it btw? i grepped the guix tree for "todonotes" <nckx>dongcarl: Didn't verify, but does that also affect llvm? llvm+clang is 1826 rebuilds (and refresh -l misses some dependency paths like inheritance). <nckx>You can check the llvm hash to make sure (and build an argument for master). <Franciman>I was thinking about the issue I am having with the locale <nckx>fps: I ran ‘find /gnu/store -name todonotes.sty’ on my build farm, so cheated. <Franciman>Is it normal that if I update glibc for my user, everything goes out of sync? <nckx>Only works if you already have the package installed, or in this case, all of them. <Franciman>if I update some software in my profile to use glibc-2.29 <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. <nckx>Patching everything to use versioned variables (GUIX_LOCPATH_2_28 etc.) might fix that but involves, well, patching everything. <Franciman>I had better run guix system reconfigure too <nckx>Franciman: Yes, although most people just get annoying warnings before they update both. <nckx>So it's not the end of the world. <nckx>For them. Do you get real errors? <Franciman>and thanks to the whole channel. You helped a lot in these days :P <Franciman>looks like I am finally happy with my system <nckx>Franciman: I am very glad to hear that 🙂 <Franciman>in order to run the guix system reconfigure, I had to install glibc-locales <Franciman>other than that, everything was pretty smooth ***galex-713 is now known as minikind
***minikind is now known as gal
<str1ngs>Franciman: you are using guix system not guix foreign distro? <str1ngs>on another note, if the guix foreign distro had another version of glibc. using thing like LD_LIBRARY_PATH can seriously cause issue. I think LD_LIBRARY_PATH should be avoided all together. <str1ngs>not related to your locales issue. but something I've noticed on foreign distros <fps>hmm, did i break something? "guix package -p foo -l" lists a package, but "guix package -p foo -r pkg" says it's not installed <fps>oh, i'm dumb. the "-" indicates they got removed in that generation. never mind <str1ngs>fps: sometimes I just run guix package -d to clean things up. <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. <nckx>I don't think I volunteered to—did I? <nckx><nckx> raghavgururajan: […] I'll read your further debugging adventures later. <nckx>I'm afraid I haven't given it any (time, mainly). I use the applet once in a while, as I do openvpn, but never together. <nckx>Feel free to ping me with questions you may have while investigating but that's about it. <raghavgururajan>nckx I noticied an another thing. The audio does not work for root user. There is no speakers detected. <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. <nckx>raghavgururajan: 🤷 I have never in my life graphically logged in as root. <nckx>Kali and systemrescuecd excepted. <dongcarl>raghavgururajan: Perhaps gnome uses pulseaudio for audio? <dongcarl>I know that on my machines pulseaudio only starts for my normal users <nckx>raghavgururajan: What does something like ‘pavucontrol’ say? <raghavgururajan>dongcarl You could be right. I am curiours why pulseaudio is not started for root user. <nckx>dongcarl's command is probably better, I'm no PA guru. <nckx>I don't think this is a Guix problem per se, but of course you'll have to ‘port’ the solution to Guix. <dongcarl>nckx: Since only `clang` changed, okay to do master? or still staging only? ***jonsger1 is now known as jonsger
*janneke runs guix pull --news *nice* <brettgilio>Any documentation on how to get Jami to run on Guix? <vagrantc>sounds like people have been working on updating the jami packaging to a recent version; some talk on guix-devel list <Franciman>guix import crate --recursive wants to download hunderds and hundreds of packages because the version doesn't exactly match with the packages already in the guix distro <Franciman>it seems really impossible to write this package <Franciman>sorry I am a bit exahusted, but I can't really find a way out <Franciman>So the way out is writing all the dependencies? <brettgilio>Nix has the privilege of having a more mature rust system than us. <dongcarl>brettgilio: Hey! I'd recommend posting to the mailing list <dongcarl>I'm sure there are people who've worked with rust in Guix that will help you there <dongcarl>IRC is mostly for synchronous communication <Franciman>dongcarl, which mailing list should I look for? <nckx>dongcarl (I keep trying to tab-complete ‘dang’): I don't feel super comfy contradicting mbakke so it would be nice if they respond. <nckx>Maybe they know something I don't (which, about clang, is not unlikely). <dongcarl>Haha gotcha, I'll probs respond on mailing list thread then! <nckx>Franciman: It's possible that the recursive Rust importer is far too eager to output packages that aren't strictly needed. There was a recent post to guix-devel to that effect. <nckx>dongcarl: No, it was regarding Rust dependencies of IceCat. <nckx>Just an aside, but an interesting one. <civodul>i didn't know there was a need for luks number 2 actually :-) <civodul>and i thought this was a wonderful idea <civodul>yet, i wondered if there were *additional* improvements :-) <nckx>civodul: Apart from larger block sizes, I don't know. Maybe ‘extensible now, features later’. <nckx>Fine as long as they don't merge (and carry forever) ever crazy feature that comes along. *dongcarl sees larger block sizes, checks that he's not in #bitcoin-core-dev <nckx>Earn Guixcoin by building substitutes. <nckx>civodul: Authenticated disk (sector) encryption (EXPERIMENTAL) [in 2016] is gud. <leoprikler>but what if two substitutes conflict? who gets the guixcoin? <nckx>Libreofficebucks, the universal currency. dongcarl: is Guix now building official BitCoin releases? <dongcarl>nckx: Not yet, I’ve done the work for linux and windows builds, now all that’s left is OSX, which is why I’ve been posting on the mailing list about clang <dongcarl>I am very thankful for everyone who’s helped in my linux/windows pursuits <davexunit>dongcarl: ooh I want to do osx cross builds as well. <dongcarl>davexunit: Haha sounds like we have a lot of the same needs <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. <dongcarl>davexunit: It does, unfortunately. We can discuss more on #guix-nonfree if unsuitable for this channel <nckx>It's certainly borderline. <davexunit>I'm not on that channel but this is enough for now