<kensington>civodul: i did add pam_elogind to my pam config where pam_systemd would normally appear, but no dice
***Digitteknohippie is now known as Digit
<janneke>it says in the manual that starting guix-publish-service is a one-liner
<ng0>upstream commit 60a8e2167d92afb0376d248cdea95ce3d5b228cf fixed the license in perlpsyc after a feedback, however i don't know how to label this change: I will exclude contrib as it was recommended by the author to me, and psycion is now gpl2+/artistic, while the rest is gpl2/artistic.
<janneke>is running `guix archive --generate-key' manually a prerequisite, or should that have happened after a guix system init?
<civodul>rekado_: me? :-) or other interested Guix
<ng0>am I promoting the use of non-free software when I state that one binary needs another binary which is shareware from 1996 and until it is not ported to another API it is up to the user to decide?
<ng0>specifically, it works, but you need to decide if you want functionallity, which you will discover once you try to run it.
<ng0>I won't link to the website either or the new source
<ng0>the website disappeared from the web though, so it's hard to get it unless you search it
<ecraven>well, it's non-free and you are promoting it... :p
<ng0>not really... ";; psycmp3 so far relies on rxaudio, a binary shareware from ~1996" is the only quote. one out of 12 binaries, the perl software which needs this itself is free software.
<ng0>i don't tell anyone who reads the source to go ahead and get the binary
<ecraven>hm.. I'd suggest maybe installing the binary, but adding a note somewhere that you need rxaudio to actually use psycmp3?
<ng0>yeah which leads me exactly to the question, can I do that? whoever (a very very small percentage of people I guess, as psycmp3 isn't the focus of the package) will use it will see it in the sourcecode
<ecraven>ng0: I'd tend toward adding a note, but I'd wait for someone more knowledgeable than me to answer you :)
<ng0>software is free (gpl2/perl package license), only quotes itself that it needs MP3::List, but to actually function you need to either port to a free API or get rxaudio
<ng0>lynX said at some point in the chats that i should just ignore psycmp3. but i'd like to know if it can be integrated somehow so that if at some point the "API rewritten" commit message pops up I just have to fix a note.
<ng0>my motivation for this is to just have a native psyc client instead of telnet.
<rekado_>civodul: yes, you commented on the patch I submitted to use different source tarballs for swt dependent on architecture. But at that time I had already pushed it after it had been reviewed by someone else.
<jlicht>ng0: I'd say this would promote non-free sw as it is, but that's just my 2¢
<ng0>so 1 unsure, 1 yes it does and myself I am unsure as well, author said ignore psycmp3.
<ng0>that equals to me ignoring it and leaving it out for now
<rekado_>when the software cannot be used without non-free software I would consider this "promoting the use of non-free software"
<adfeno>ACTION is reminded of a book about GIMP, and other one called "The Book of Linux" in Brazilian Portuguese, which document functional data (and so are also functional), but don't give the 4 essential freedom's to society.
<adfeno>rekado_: Yes... I'm also worried by that...
<rekado_>davexunit: I have a question about "guix environment --container". I want to load an environment from a file with "-l guix.scm", but I also need to add coreutils to the environment. Should "guix environment --container --ad-hoc coreutils -l guix.scm" work?
<optikalmouse>davexunit: I mean can I load build systems after guix has been built, hot-reload is the terminology for other lesser programming languages ;)
<davexunit>rekado_: that would be put the package in guix.scm in the environment, if you want the deps then you need to change it a bit
<optikalmouse>jlicht: for building a package, I would just need to set native-inputs or inputs to 'node yeah? and then propagated-inputs would be the other npm packages needed?
<davexunit>optikalmouse: roughly yes, assuming there was a build system for Node, which is what jlicht is building.
<optikalmouse>is there a way to have optional deps or minimum deps in the inputs? like i have node 4.x in one project and 6.0 in another, do I need to write separate packages that build against each target or can I say (inputs `(("node" ,(or node-6.0.0 node-4.x)))))))
<davexunit>I recall being able to tell npm not to talk to the network
<jlicht>davexunit: Without diving into bundled dependencies and/or offline npm registries?
<davexunit>I don't remember exactly, but I had packaged a few things using npm to install locally and it worked out okay.
<optikalmouse>^ I would prefer zero reliance on npm other than grabbing existing packages to convert them to guix. there's no need for it, it's not like pip and python or perl and cpan where you absolutely need them to get anything done. npm is a binary I wish I could remove from all my machines -_-
<ng0>yep. nvm the question, grep first, ask later.
<ng0>I think I want to disable tests. it's not a super huge program, but getting the tests done in the way I want them does not work as you can't execute in the store in the phase.
<ng0>bascially what I do in addition to wrapping the tests/Makefile is chmod the Makefile to #o777, do a system* (string-append test "/Makefile"), delete-file-recursively test , where only the chmod and the delete succeeds.
<ng0>i don't know yet how else to execute the tests
<myglc2>davexunit: Thanks. My use case: Home servers with Guix/Debian 8.3. Linux work servers w/o sudo. Wondering when/if it might become feasible to build my SW tools at home and then run on the work servers.
<davexunit>myglc2: can't give you a timeline, it's basically whenever motivated people put in the work to make it happen.
<jlicht>sneek: later tell optikalmouse: You are correct in assuming that an npm package that is simply copied over could also just be installed from tar.gz. The general problem is that these sources often include and make use of generated and/or minified files, and as such are not the preferred source
<myglc2>davexunit: Thanks. Guix offers a strange mix of freedom and control: I lets an unprivileged user do what ever they want, but only if they have sudo, or know a sysadmin that is adventuresome enough to install Guix/GuixSD for them.
<davexunit>myglc2: yeah, but I think we'll eventually remove even that requirement.
<bavier>myglc2: a short while ago I explored setting up `guix publish` on a computer I have root on that would serve substitutes to my unprivileged computer
<bavier>the daemon was set up with a store location in "/ptmp" that I have write access to on the unprivileged computer
<ifur>his, is there a convinient way to download a directory with curl containing tar.gz or other files and checmsum all of them and extract into a single folder?
<davexunit>having an unprivileged guix daemon with substitutes from hydra would require using containers to mount /gnu/store
<davexunit>time to go AFK for the long weekend. happy hacking all!
<ifur>civodul: file by file its a bit much, a brute force approach would be really nice
<bavier>civodul: yeah, I'd like to explore the hack a bit more
<ifur>civodul: so these datasets are by and large associated with a specific version of the software library
<civodul>ifur: what about (list (origin ...) ...), would it be ok?
<ifur>the way to deal with these data sets aren't consistent, .e.g. there used to be a large tarball for all of them, but they have moved towards a file by file approach using a script... which is obviously not a good solution
<ifur>civodul: notice how many there are, and that its by version?
<ifur>think one needs to follow the versions in order to be sure to get the correct ones
<ifur>and its critically important because these datasets are used for generating events in high energy physics, as in... the pdfsets are based on theoretical and experimental data
<ifur>because ideally an end user should be able to easily update the version withot going through every single data set
<ifur>since the total size isnt massive, doing all of them in one go is likely the best approach
<civodul>you could have a script, Scheme or otherwise, that generates the list of origins
<civodul>it wouldn't help that much to do it in one go
<civodul>you still need to know the hashes of each individual file
<ifur>i was thinking more along the lines of a user updating the main library versions, and then when trying to install get an error with a single incorrect hash that could be updated
<myglc2>bavier: Thanks. This is along the lines I was imagining.
<ifur>the primary users of this piece of software is theoretical physicsts, so albeit clever may not be inclined to spend a lot of time learning scripting in order to update this absurd amount of files