<asterope>How can I wrap scripts from a lua package so they'd aware of a lua library in the store? <asterope>I know that I need to change one variable in the environment, every time the script is run <OriansJ>asterope: assuming you exported the library in your ENV, just have your lua package read from the ENV and use the library <OriansJ>assuming it is in the LUA_INCLUDE_PATH or LIBRARY_PATH or which ever standard ENV your language uses to express where to look for libraries <asterope>both the library and the program are in the store <OriansJ>asterope: yes but how does the program know where to look for the library? <asterope>win LUA_PATH, but I don't want to set it for the user, just for the executable <OriansJ>So unset the variable after you are done with the installation <asterope>I'm writing a package definition for moonscript (a lua program) which is dependent on a few lua libraries (each is its own package) <asterope>moonscript's executables can't see the libs because they're not in the LUA_PATH <asterope>I don't want to propagate those libs and prompt user to change this env variable <OriansJ>but you wish to find the libs in the user's ~/.guix-profile <asterope>The user don't need those libs, I just want to do something like python-build-system <OriansJ>asterope: So just have them as dependencies for the build definition. <asterope>They are in 'input' field, but as it is a scripting language - I need to point the program to them anyway <asterope>lua runtime runs the program and searches LUA_PATH for any libraries, the store is not one of the places it searches <asterope>so I need to add the store paths of those libs to the LUA_PATH before every invocation of that program <asterope>I found wrap-program in guix/build/utils.scm it's perfect for the job <bavier>what to do when your evince doesn't render some fonts in pdfs? <bavier>for some reason my evince can't find a "courier" like font to display <bavier>even though it says its using the system's liberation fonts as a substitute for the nonembedded fonts <apteryx>Hello! it seems that gcc-toolchain doesn't not include libstdc++? Do I need to to install the libstdc++ package along gcc-toolchain? <Sleep_Walker>how can I configure tramp mode to not be confused when connecting to GuixSD? <Sleep_Walker>OK, ls behaves weird but all seems to be respected via tramp-remote-path <efraim>I had to move inputs -> propagated-inputs, but I have perl6's rakudo compiler building <efraim>debian's plan for the test suite doesn't inspire much confidence though <efraim>make test || make test || make test || make test || MVM_SPESH_DISABLE=1 make test <roptat>so, origins create a fixed-output derivation for downloading the source, that's why there's a sha256 in it... <roptat>but if there's a snippet, the sha256 doesn't change, so I guess it creates a new derivation that takes the result of the fixed-output derivation as an input <roptat>then if I disable substitutes, I don't get the result of that derivation (the actual source code of packages in guix), right? <roptat>(I mean, not from guix's build farm, I have to build it myself) <roptat>and, what does it mean to have (sha256 #f) in an origin? ***ng0_ is now known as ng0
<bgardner>Good morning Guix, has anyone worked out a method to declare NFS mounts yet? My last effort a month or so ago had no luck (NFS works, but you can't get entries into fstab without hand-editing). <apteryx>I may have missed the answer and I'm sorry if I did, but I still have the following question: it seems that gcc-toolchain doesn't not include libstdc++? Do I need to to install the libstdc++ package along gcc-toolchain? <mikadozero>I have just completed a: guix system reconfigure --no-substitutes <mikadozero>Is it correct that that means all the programs on the system have been built from source? <rekado>mikadozero: not necessarily. It just means that for *this* reconfiguration no binaries were downloaded from the build farms. <rekado>if there are parts of the system that already existed in /gnu/store they would not have been rebuilt from source. <mikadozero>How would I have everything built from source even if the system has previous substitutes? <rekado>there is no way to do that recursively, AFAIK. /gnu/store is a cache and it will be used unless you tell Guix to rebuild something with “--check”. <rekado>whether an item in /gnu/store was built from source or fetched as a substitute is recorded in the database, but isn’t exposed through a user interface. <mikadozero>It would be nice to be able to build the entire system locally and ignore any substitutes that were already on the system. <mikadozero>So if I wanted everything to be built locally could <roptat>mh... there's every dependency of guix already in the store, so you'd have to start with a guix built from source, outside of the store <mikadozero>I accomplish that with a new install and always using --no-substitues? <roptat>so I guess, you'd boot on a live-CD for another system, install dependencies for guix using that system, checkout the git repo, bootstrap, configure, make and then run the daemon with --no-substitutes, and ./pre-inst-env guix system init ... <roptat>with the no-substitutes as an option to the daemon in your new system's configuration <roptat>I don't know if anything simpler would work <roptat>For instance, I think the guix live-cd already has a store, so there are some things that will be used from it <mikadozero>roptat: Okay so it could be done by bootstrap the system and have the daemon configured to use --no-substitutes. <roptat>yes, as long as there is no store to start with <roptat>then you'd build everything from the bootstrap binaries up to your system <mikadozero>guix challeng gives me: 2,490 store items were analyzed: <mikadozero>Is it normal to have so many inconclusive results? <mikadozero>The different ones could be from non-determinism in those packages? <roptat>that's when you have derivations that were not built yet or have been removed from the build farms (IIUC) <roptat>you'll probably want to investigate further and send a bug report for each of them, if there is none yet <roptat>or better, a patch if you can fix the non determinism :) <rekado>mikadozero: inconclusive could be because you never built the thing locally, so you can’t make a meaningful comparison. <mikadozero>rekado: That makes sense given what we were just discussing. <mikadozero>rekado: As far as patching a package to make it deterministic, I think it might be better for me to first try creating a package. <mikadozero>rekado: Is there documentation I can look at for bug reporting? <apteryx>mikadozero: I can't seem to find bug reporting guidelines in the Guix info manual, but basically 1. search for existing bugs before entering a new one 2. state your guix version (guix describe) and steps to reproduce the issue. 3. Mail it to bug-guix@gnu.org. <rvgn>I have no idea why, but whenever I fire up my IRC and join #guix, I am getting all charged up. XD <rvgn>May be the novelty of guix excites me. ;) <mikadozero>Is there a different process than bug reporting for feature requests? For example: - Add bug reporting to info manual - Be able to rebuild entire existing system from source <polezaivsani>rvgn, and since you sound like you did more than once, please tell how good of a fit guix might be to configure computers? i.e. what's Ansible, Cheff and the rest are being used for now. <rvgn>In my experience, I think guix can be a fit for literally anything. You know how there are particular distros focused for particular purposes? Guix can be molded to literally anything with just one configuration. More to that, it can be reproducible. <roptat>polezaivsani, ansible and the like have the ability to deploy and configure systems remotely, which guix cannot yet, but they don't provide reproducibility, only some sort of fix-point guarantee (the environment created will influence a future run of the same config in such a way that it creates the same environment) I don't remember how they call that <polezaivsani>guess i'll take a stab at it once i up my guile game a bit <roptat>and we are working on a guix deploy thing :) <roptat>in the mean time, people are using some scripts to deploy stuff remotely and it seems they are pretty happy with the result <roptat>I guess you could use ansible to reconfigure remote machines though ^^ <polezaivsani>like setup guix on a remote host first and then run the same config as you'd do locally? <roptat>I was thinking of ansible as a tool to automate ssh'ing to the machine and running some commands, which would be "install the new config file, run guix pull to that specified commit and reconfigure the system" <roptat>but people use scripts that actually build the remote system locally and send guix store items to the system once that's done, and then it's very quick to reconfigure on the remote system <rekado>roptat: once installed you can also do that without ansible :) <roptat>building locally has some advantages : you build common stuff only once and you might have a more powerfull machine you want to use <polezaivsani>roptat: what is this guix deploy you're working on? something internal? <mikadozero>When trying to redirect the output of guix challenge I found out that it does not output anything to stdout and only stderr even when there is no error. I was not expecting it to do that. Is there a reason for it? <kmicu>polezaivsani: nix (disnix, nixops) already replace those use cases. Guix can do the same ― we only need to throw engineering hours at it, nothing more. <kmicu>(You could also use disnix/nixops to deploy Guix if you like layers of indirection 😹) <mikadozero>For the guix challenge I just ran 39 of 41 packages that were marked as differ where guix related packages. Would guix related packages have an issues with being non-deterministic? <polezaivsani>yeah, that sounds like lots of fun, kmicu :) and frankly i won't mind lots more indirection once it's all orchestrated via guix and not my fallible self <mikadozero>Guix related meaning it says guix in the package title. <kmicu>polezaivsani: Changing remote boxes by sending a declarative configuration (which is reproducible) is sweet. But it also has some downsides like being angry each time you need to touch your debian box xD <polezaivsani>kmicu: you mean it would turn into the only way to configure them? as in you don't mish and mash guix config and e.g. manual installations? <polezaivsani>i got used to it mostly with my current setup; dont know how painful it is for a large scale ops though <kmicu>I’ve had in mind that after using 100% declarative approach I cringe every time I need to manage a statefull (and update-in-place) system like Debian. <polezaivsani>yup, i imagine it would hurt some... like kicking a bad habbit ;) *kmicu imagines a future with GuixWRT and Guix System as popular as CentOS/Debian in VPS offerings. <eubarbosa>lol, eager to install chromium, takes too long...decide to install it as I go to sleep... <kmicu>(Cuz I also want to have a declarative&reproducible config for my router.) <apteryx>kmicu: wouldn't Guix in itself be sufficient for a router, albeit targetting the specific target/board? <kmicu>apteryx: guix, the package manager? <kmicu>(There are plenty of services on a router and sole package manager is not enough to say ‘guix ops deploy /path/to/routerWithUnboundAndAdBlockerAndProsodyAndGitolite.scm router.IP’) <apteryx>you'd manage the OS of your router using the same interface you manage the OS of your Guix System. <apteryx>FWIU Guix would just need to be ported for it. One problem without further effort might be disk space requirements <kmicu>Ah, not really, Guix System is too big. <kmicu>(Where ‘Too Big’ means it’s not a distro for embedded devices. Removing stuff would take more time than starting from scratch.) <apteryx>some embedded boards are powerful and can be equipped with enough storage for Guix (some people are running Guix on ARM boards for instance). It might be possible to turn those into routers, using USB network adapters? <kmicu>(Folks have issues with adding support for Fish and for embedded devices we need to remove bash xD). <kmicu>(OpenWRT is not about powerful single board computers but those drawing 4W and having ~32MB of RAM.) *kmicu should talk about libreCMC (not OpenWRT) cuz it’s FSDG like Guix System. <apteryx>kmicu: OT, but talking about libreCMC, I ordered a second hand Netgear WNDR8000 to install it on it! <kmicu>Nice, not only libre but also environmentally friendly cuz second-hand 👏 <apteryx>yeah, I'm looking forward to see how it performs <g_bor>I was thinking about that it would be nice, if we could upload the tarball generated by guix build --source ungoogled-chromium somewhere, or provide the link from the build farm, so that interested parties can have a look at that, run their license checker, or whatever. Wdyt? <rvgn>IDEA+DOUBT: Is it possible to make qubes-like OS with guix? <vagrantc>of course it's possible, question is really of how much work it would take :) <vagrantc>out of the box, it does have support for running an individual application containerized and isolated, but i don't think it's been designed for security <vagrantc>and you can also trivially spin up virtual machines with specific software profiles <vagrantc>specifically using xen like qubes does, i'm not sure <vagrantc>rvgn: all/most of the pieces are there, it just would take some effort and security auditing to make it workable and integrated <rekado>mikadozero: this can happen. Could you send these reports to the mailing list please? <rekado>(this is about non-deterministic packages as reported by “guix challenge”) <apteryx>any idea why our libstdc++ package version is reported as 4.9.4? AFAICT it should be based on the same version as our GCC package (which is, 5.5.0) (in gcc.scm: (define-public (make-libstdc++ gcc) ... ) and just above: (define-public gcc gcc-5) <apteryx>it seems to be a bug with regards to the package inherit mechanism <rekado>apteryx: there’s nothing wrong here. <rekado>we only have a definition of libstdc++-4.9, which is defined as (make-libstdc++ gcc-4.9) <rekado>having it report version 4.9.4 is expected and correct. <rekado>there is no separate libstdc++ for the current gcc. <mikadozero>rekado: Okay, but which mailing list is more appropriate the bug reporting or development mailing list? <rekado>non-reproducible packages are bugs. You can send an email with all the details (including your version of Guix) to bug-guix@gnu.org. Thanks! <eubarbosa>after learning some lisp you notice that even basic syntax of other languages are damn weird.. ratio = denom == 0 ? 0 : num / denom; <eubarbosa>Java book: "parentheses can sometimes be used to help clarify the meaning of an expression" ... I agree!