IRC channel logs
2018-01-28.log
back to list of logs
<platoxia>Does gnupg have to be installed with the system configuration or is it supposed to work when a user installs it? <platoxia>It doesn't seem to be spawning gpg-agent when trying to generate keys after being installed by the user. <platoxia>That's great...but gpg isn't working properly and won't generate keys at all. <arescorpio>try then installing: <kgpg>, is a graphic program that generates all kinds of keys at will <dieggsy>if i use the method url-fetch/tarbomb with trivial-build-system, will the #:builder be called from within the untarred directory? <dieggsy>(i assumed so, but i'm having problems with it not seeing files that _should_ be in there) <bavier>dieggsy: with trivial-build-system, you need to do the source untarring yourself <dieggsy>bavier: i was under the impression the url-fetch/tarbomb method would untarr <bavier>dieggsy: url-fetch/tarbomb repacks the source after fetching, it doesn't affect the building part at all <dieggsy>bavier: how do i refer to the newly downloaded file? can i (assoc-ref %build-inputs "source") it or something? <bavier>dieggsy: that should resolve to a path in the store that points to the tarball <dieggsy>bavier: what's the right way to go about this? say i have the tar variable bound to the correct path for the tar executable - I'm trying something along the lines of (system* tar "xvf" (assoc-ref %build-inputs "source")) - how do i then enter into the resulting directory? <dieggsy>ah, darn, i need gzip for that too. slow and steady wins the race <bavier>dieggsy: the name of the directory should be known <dieggsy>bavier: you're right of course :) can i make tar "see" the gzip executable, or should i just unzip, untar manually <bavier>dieggsy: there are a few good examples of trivial-build-system in other packages <bavier>dieggsy: setting PATH works well <bavier>e.g. (setenv "PATH" (string-append (assoc-ref %build-inputs "gzip") "/bin")) <dieggsy>bavier: thanks for the help, i'm definitely getting there <dieggsy>turns out, modifying gnu-build-system is _probably_ the way to go for me heh <ofosos[m]>Is there any kind of best practice way to package a node application? <rekado_>ofosos[m]: no. That’s mostly because it is very hard to package a node application and all its dependencies purely from source. <ofosos[m]>For starters I included all of the runtime dependencies in a profile and have it running with LD_LIBARY_PATH=profile/lib <dieggsy>I'm trying to add a step after 'patch-source-shebangs that does an "npm install", but i get an NPM error: getaddrinfo ENOTFOUND . I've found this probably has something to do with npm not being able to connect over https - is there some build input or env var i could add to mitigate this? <catonano>dieggsy: the build happens in an environment that has no network connectivity <dieggsy>catonano: damn - does that make building packages that require npm install or network connectivity otherwise for building impossible? <catonano>dieggsy: I'm not the most prominent expert. But I'm afraid the answer is yes, it's impossible <catonano>dieggsy: jlicht has done some work on npm <catonano>in theory, you should use npm to build a project in a local folder of yours <catonano>your project could download the binary of the package you're trying to build as a dependency <catonano>dieggsy: that could work because in your profile it wouldn't be isolated from the network <catonano>dieggsy: this practice is not supported by Guix so we shholdn't discuss this here <catonano>dieggsy: furthher, last time I tried this didn't work, becase npm has changed since the prototype of the npm build system was made <dieggsy>on an unrelated note, anyone know why i'd get "/bin/pwd: no such file or directory" on a package that _inherits_ from the emacs package? <wigust>dieggsy: `command -V pwd` -> pwd is a shell builtin <adfeno>dieggsy catonano: Do we really want official GNU Guix packages to rely on language-specific package managers ? <adfeno>Also, if I recall correctly, `npm install' by default relies on third-party repos not commited to FSDG. <wigust>dieggsy: also 'ls $(guix build emacs)/bin' will show no pwd in emacs package. <catonano>adfeno: I was outlining the situation for the benefit of dieggsy I don't mean to subvert the FSDG. In fact I explicitly stated that that is not supported so it shhouldn't have discussed here <catonano>if anything I believe that a FSDG compliant npm build system is needed. I offered jlicht hhelp tp test and debug his work <adfeno>catonano dieggsy: Don't worry, I don't mean any disrespect and I don't mean to be harsh, I was only trying to start some friendly discussion about the issues of npm and other language-specific package managers. <wigust>adfeno: What is an issue with other language-specific package manager? <adfeno>wigust: mainly related to the fact that these package managers point to a repository from a third-party. <wigust>Others don't pull everything on the internet unlike npm. <adfeno>wigust: Interesting... not even pip and the other Python-based ones? <wigust>adfeno: We cannot have a repository of all source from the internet I guess. <wigust>adfeno: you could check Nix talk why npm is a pain <adfeno>Well, Guix can't, but perhaps if the FSF and free/libre distros make some sort of repository to list known free/libre ones, then we could just patch the package managers to use that repository instead. <wigust>adfeno: Why do you need a repository at all if you can see the source, hash it, diff with update? <wigust>you will pull the source from the upstream either way <adfeno>Indeed, you might be right wigust, arepository seems a lot of work, perhaps a list pointing to the packages already evaluated (called when doing `npm install') seems to be better and less expensive for storage. <adfeno>This issue with npm and also some "docker image repositories" was brought to directory-discuss (or was it libreplanet-discuss?) a year ago if I'm not mistaken. <dieggsy>wigust: how would i go about fixing this pwd issue <wigust>adfeno: will be interesting to see if i find :-) thanks <dieggsy>wigust: i tried adding coreutils to the build inputs to no avail <wigust>dieggsy: pwd is Bash builtin, so you want a Bash ;-) <dieggsy>wigust: pkgfile -s pwd shows coreutils on my computer, as well as which pwd <efraim>or a substitute* to change '/bin/pwd' to 'pwd' or to '(which) pwd' <wigust>dieggsy: as efraim mentioned, you need want to remove every hardcorded paths like '/bin/pwd', because we have only /bin/sh <dieggsy>weird thing is i build once succesfully, accidentally deleted the file, tried to recreate the package declaration and this issue showed up <dieggsy>i didn't do anything special with substitute* or bash the first time <wigust>dieggsy: if 'recreated' package declaration was builded againg, something is different in the package declaration <adfeno>wigust: What do you mean by?: 2018-01-28T13:07:10-0200 <wigust> adfeno: will be interesting to see if i find :-) thanks <dieggsy>wigust: heh, the built-in emacs package takes care of this for me, for phases i am now modifying %standard-phases in what i thought to be a "simpler" method, last time i was modifying the original package's phases <wigust>adfeno: if i find this discussion on the internet <wigust>ACTION doesn't care about docker-images repositories at all because they docker image is dead after build though <wigust>but npm repository will be interesting <dieggsy>wigust: so wait, i'm not sure i follow - what was the idea regarding npm ? <adfeno>^ the discussion starts from that message <adfeno>The list uses Namazu for search, if I'm not mistaken, so its also a good idea to use "+subject:{[Subject without these braces.]}" to search for the replies because mailing lists tend to have their threading lost. <wigust>adfeno: Thank you. Fdroid like repository for Docker images would be great. Especially images produced by Guix, which will be free. <wigust>dieggsy: not much an idea, just a discussion of the current situation <mbakke>Is there a grep-like utility in Guile/Guix that can build up a list of files based on some search criteria? <mbakke>But can it search for strings inside files? <mbakke>Some context: apparently in recent versions of python-gevent, the way to avoid network tests is to just run those matching "grep -l subprocess test*.py". <bavier>mbakke: I'd suggest hardcoding the list into the package definition, if there aren't too many <mbakke>There are 19 matching files. I'll give it a go. <civodul>it'd be time to post a one-week-to-FOSDEM article <rekado>I have edited and extended the guix installer script <rekado>haven’t been able to test it fully, though, because I don’t have a machine that doesn’t have Guix yet… <rekado>I’ll add it as etc/guix-install.sh <rekado>patch sent. I tested this successfully on a machine with Guix (it aborts as expected) and on a machine without (it installed everything). It also verifies the tarball signature as it should. <pmal>Where I could find this script and take a look? <rekado>pmal: since I have problems sending emails to gnu.org addresses (including guix-devel@gnu.org) it might appear on the mailing list archives in a couple of hours. <rekado>pmal: but if you’re curious I could paste it. <civodul>grmbl 'guix offload' eventually hangs when offloading to overdrive.guixsd.org and only there <wigust>ACTION packaged licensecheck and thought it was good, until tried 'package -i licensecheck' <wigust>What to do if perl script requires a specific version of a perl library, and this library is in propagated-inputs with different versions? <pmal>rekonto: thanks. Great work. <pmal>rekado: thanks. Great work. <civodul>wigust: woow, looks like licensecheck was not an easy one! :-) <wigust>except a few issues with my current situation, but perl importer does a great job <wigust>civodul: thank you, it works well, but i want it be installable ^_^ <civodul>i'll take a look tomorrow if everything goes well <wigust>wigust's dns provider gives him html named as tarball and says tarball was infected