IRC channel logs


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.
<arescorpio> # see if it helps you to have the new keys on your destop
<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>oh, interesting
<dieggsy>bavier: how do i refer to the newly downloaded file? can i (assoc-ref %build-inputs "source") it or something?
<bavier>dieggsy: right
<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
<bavier>great, np
<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]>I want to package Patchwork, should I improvise with this?
<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
<catonano>as far as I understand
<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
<catonano>it'd need an update
<dieggsy>well damn
<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
<catonano>it's just that he's busy. I am too
<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.
<catonano>adfeno: oh, ok
<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.
<wigust>And don't build C/C++ stuff.
<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.
<adfeno>wigust: I know we can't ;)
<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>but bash is already there
<dieggsy>wigust: ?
<wigust>dieggsy: as efraim mentioned, you need want to remove every hardcorded paths like '/bin/pwd', because we have only /bin/sh
<dieggsy>huh. i'll look into that then
<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
<dieggsy>ah welp
<wigust>dieggsy: if 'recreated' package declaration was builded againg, something is different in the package declaration
<dieggsy>wigust: OH
<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.
<adfeno>wigust: +1
<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?
<bavier>mbakke: there's find-files
<bavier>in (guix build utils)
<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>no, find-files can't do that
<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>hey hey!
<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/
<rekado>found a guix-less server
<rekado>the script worked!
<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 addresses (including it might appear on the mailing list archives in a couple of hours.
<rekado>pmal: but if you’re curious I could paste it.
<rekado>pmal: here’s a copy of the patch:
<civodul>rekado: awesome!
<wigust> to get it in raw
<civodul>grmbl 'guix offload' eventually hangs when offloading to 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>it was
<wigust>except a few issues with my current situation, but perl importer does a great job
<civodul>well congrats on getting it done
<wigust>civodul: thank you, it works well, but i want it be installable ^_^
<civodul>heheh :-)
<civodul>i'll take a look tomorrow if everything goes well
<civodul>for now, i'll go to bed :-)
<wigust>wigust's dns provider gives him html named as tarball and says tarball was infected