<jsierles>when using 'guix import cran', what should I name the file in which the package definition gets placed? <jsierles>i set GUIX_PACKAGE_PATH to a directory. but not sure how to get 'guix package' to recognize this new package definition <jsierles>ah, i see i have to wrap it with 'define-public' and add to a module namespace <jsierles>guess that work has to be done manually? <lfam>jsierles: Yes, that part is done manually, but I'm sure it could be automated somehow <jsierles>ok. just confirming. in which module are the license variables defined? <jsierles>i'm including 'guix licenses' but getting " Unbound variable: gpl2" <jsierles>maybe i'm missing something. does the filename have to be something specific? <lfam>jsierles: When you imported (guix licenses) you gave it a prefix of "license:". So you'll have to prefix each license as you use it: (license license:gpl2) <lfam>But, it's not necessary to use the prefix in this file <lfam>We use them to work around the fact there are both packages and licenses called 'zlib', 'openssl', and 'expat' <jsierles>right. i removed that, but now see: ERROR: no code for module (nextjournal) <lfam>Presumable this file is not in a directory structure like 'gnu/packages/nextjournal.scm' <lfam>That module path needs to match the file path relative to GUIX_PACKAGE_PATH <jsierles>ah, didn't know that was required. not mentioned in the docs :) <jsierles>if this is just scheme, i can use anything i want, i presume <lfam>I never tried to reuse that namespace, so I'm not sure what would happen if you tried <jsierles>ok, now i see it getting further. but the package it defines as a propagated input is not available <jsierles>"(propagated-inputs `(("r-stringr" ,r-stringr)))" <lfam>You need to import the package module it belongs to (gnu packages statistics) <jsierles>so i guess this will be some trial and error. <lfam>Hm, weird. Can you share your latest package definition? <lfam>If you use more than once license, you need to pass a list: (license (list gpl2+ gpl3+)) <jsierles>ok. thats the output directly from 'guix import' <lfam>Hm, that's a bug in the importer <lfam>Can you report it to <bug-guix@gnu.org>? <jsierles>fixing that, i managed to get r-ggmap installed. so success! <jsierles>is there a command line search tool to find which module has a package? <lfam>I usually use the 'location' field from `guix package --show`, but there's surely an easy way to do it in Scheme or the Emacs Guix tools <lfam>It's okay, I'm still using my stone age tools too ;) <rekado>the output from “guix package --show” is in recutils format, so you can filter with recsel ***Piece_Maker is now known as Acou_Bass
<rekado_>reordering packages / commits is really painful because git tries to be smart and considers new package expressions as changes to existing expressions. <rekado_>is there any way to tell git to either try harder or much less hard? <lfam>rekado_: Add a couple extra newlines between package definitions ;) <rekado_>has anyone tried to use git with ydiff? <rekado_>ACTION still needs to clean up the patches for texlive-tiny <eacces>ACTION returns for another guixing session <jsierles>any chance guix stuff can move to gitlab? <eacces>i'm an outsider so irrelevant; but i am curious. why move at all? <jsierles>well, because the current suite of tools suck in comparison <rekado_>jsierles: are there problems with savannah? <jsierles>it's not just the code hosting. also bug tracking and CI. think using modern tooling would benefit this project, just as it has for countless other free software projects <rekado_>for bug tracking we use debbugs, which works very well for us <jsierles>i can go into detail, but don't want to seem unappreciative. i think this project is important, which is why i think it deserves a better home. i think you'd get more people participating <rekado_>most importantly it doesn’t require yet another account <rekado_>at this point I think contributions aren’t the problem; the problem is rather with the number of reviewers <janneke>ACTION is pretty happy with debbugs + git <rekado_>jsierles: do you think we have enough reviewers? :) <jsierles>rekado_: i think better tooling makes it easier to review, submit issues, track and comment on merge requests, etc. <rekado_>debbugs allows for all of this, and it only requires email <rekado_>it just doesn’t have an editable web interface, so what some people are used to doesn’t exist <rekado_>jsierles: what tools are you using to talk to debbugs? <jsierles>rekado_: i just sent an email. i don't use emacs <jsierles>i dont know if my report was accepted, where to find it, etc. <rekado_>whenever you send an email to bug-guix (or guix-patches) you’ll receive a confirmation from debbugs with that info. <rekado_>it tells you where to send updates and gives you a URL <rekado_>was this your first email to bug-guix? <rekado_>they do greylisting, which incurs a significant delay on the first email <jsierles>so how do you review merge requests? does such a thing exist in savannah? <rekado_>we don’t use a workflow involving merge requests. We use a rebase-only workflow <rekado_>this means that people will usually send patches via email <rekado_>we encourage patches to be sent to guix-patches <jsierles>ok. so if you use emacs, i suppose you have some tooling for diffing with patches? <Petter>As an occasional contributor I'm happy with this process. <rekado_>patches as such are diffs already. But if I wanted to see them in context I’d apply them to a new branch and give that a spin. <rekado_>I have my email in Emacs, so I can apply patches right there with no friction <eacces>speaking of patches, i'm going to submit my first [trivial] package change to guix-patches, be kind if i screwed up something basic :D <jsierles>alright. guix is officially separate from nix right? only sharing the store format? <rekado_>eacces: please allow for some time to review. There are quite a few patches, but not enough reviews. <rekado_>(and I’m kinda busy these days, so I don’t get to review as much as I used to.) <rekado_>jsierles: yes, the projects are completely separate. We use a version of the Nix daemon for now, but reepca is about to replace parts of it. <rekado_>jsierles: some people think Guix is a fork of Nix, but that’s not correct. <ecraven>isn't the "package" format the same too? <rekado_>Guix is another implementation of functional package management, and other than the daemon there’s no shared code. <ecraven>no, the prebuild binaries thing, I think? <ecraven>derivations are guile vs. nixlang, so they should be different, right? <ecraven>not sure, but I thought they were the same format <rekado_>ecraven: the on-disk format of derivations is actually identical <rekado_>ecraven: we’re “compiling” them to that format to be able to use the daemon without changes. <ecraven>ah, so that'll go away at some point and be replaced with guile? <rekado_>the binary archive format probably is identical, too, because that’s what hydra provides us with and the daemon uses it. <rekado_>ecraven: the on-disk format for derivations might change at some point in the future, but there isn’t really any motivation to do it. It would be work without direct positive impact. <rekado_>it would be cute if it was just S-expressions, though <jsierles>is there a way to find out which profile matches a specific manifest? <rekado_>in Nix it is really obvious why this whole idea is called functional package management. Package definitions are functions, and you’ve got a big table of instantiation parameters <rekado_>in Guix the design is built around the package graph instead <jsierles>using --dry-run, i can see the derivation that 'would be built'. <rekado_>the derivation tells you what output directories would be the result of instantiating the derivation. <jsierles>but if i just run 'guix package -m my.manifest', that profile is not created in /gnu/store. only the derivation. <jsierles>ok. how do you instantiate a derivation? <rekado_>(or rather: by having the daemon build it) <jsierles>running the above should build it, right? <jsierles>if i run it, it just says 'nothing to be done' <Petter>Probably because it's already built with the same inputs. <jsierles>yeah, but i don't know which profile that is <rekado_>the derivation gives you the directory, doesn’t it? <jsierles>in there i see a few different profile directories <jsierles>the first entry is: ("out","/gnu/store/06gaic9whmj1j4jmaacihyk6r5czd82r-profile","",""). but this directory doesn't exist. <jsierles>the current profile i'm linked to is not in the derivation file mentioned by --dry-run. <jsierles>my goal here is to know for a given manifest, what the associated profile will be. because in the cluster, i'm just setting the appropriate environment variables, not linking or using the guix command line. <rekado_>I can’t check this now, but I’ll try to find some time today to see if we can do this easily <jsierles>so what i want to do is build from a manifest, then grab that profile hash so the clients (docker containers) start up with the right paths <jsierles>i guess one way is just to check what my current link is after the 'guix package'? <jsierles>nope. now just mounting the store directly and using paths <jsierles>given dry-run exists, it seems like that hash should be calculable without having to run the build <rekado_>hmm, I see that the derivations to be built for “--dry-run” and without are different <rekado_>doing this with “--no-grafts” gives me the same derivation for both <rekado_>no, running the actual build with “no-grafts” gets the same derivation as “dry-run” <rekado_>I guess you’d have to use Guile then to get the directory name. <jsierles>ah ok. well, i can find it by looking at my current profile link <eacces>i notice the guix fundraising campaign was announced end of 2015. is it still relevent? is cash for hosting and hardware still important? <ecraven>I'd guess cash is always important ;) <brendyn>eacces: yeah i think it's important, you just have to figure out who wants to take up the responsibility of running that hardware <civodul>we almost have that, but not as nicely integrated <rekado_>eacces: we don’t currently run a fundraising campaign, but the project accepts donations through the FSF. <civodul>m-o``: thanks for (guix git), i'm glad it's finally in! <m-o``>civodul: happy too, thanks for your help :) <m-o``>civodul: next job: connect cuirass to this new API ! <civodul>BTW, it seems that Cuirass no longer "hangs" <civodul>the story was that by default guix-daemon had timeout = 0 and max-silent-time = 0 <civodul>most of our clients would override this, but Cuirass did not <civodul>so i added --timeout and --max-silent-time to guix-daemon <civodul>and i used these options on bayfront <m-o``>ok !! thanks for the info, i'll do the same on my build server :) <civodul>speaking of which, bayfront has crashed it seems :-/ <wingo>hehe :) hardware: sometimes as bad as software <rekado_>ACTION just sent out the first few Texlive patches <rekado_>I got some comments/criticism on the usability of Guix <rekado_>two important things are: generate manifests from existing profiles and allow specifying the Guix version in a manifest. <rekado_>(other comments were about speed, but that’s highly NFS-related) <davidl>I can't run guix refresh: "guix/build/download.scm:424:6: X.509 certificate of 'api.github.com' could not be verified: \\n signer-not-found \\n invalid' <rekado_>davidl: have you set up the SSL environment variables as suggested in the manual? <davidl>I don't remember, but I'll double check that. I've been using it for very long and most other things work. <davidl>rekado_ a nice feature to have when using GuixSD would be to be able to apply a system configuration that automatically resorts to a version which has a successful build available on hydra so you can avoid the time it takes building from source. <davidl>rekado_ exporting the cert paths seem to work. <rekado_>what do you think about adding different manifest formats? <rekado_>it’s trivial to read different file formats with Guile, so if all a user wants is to describe an environment, why not give them ways that don’t involve writing Scheme? <rekado_>I think we might be able to reduce complexity for some users by removing most syntax from manifests <civodul>rekado: re manifest formats, why not, sounds like a good idea <rekado>civodul: I was thinking of plain text as a less controversial step, but JSON sounds good to me too. <rekado>so… I’m trying to move the shared /gnu/store from NFS to GPFS <rekado>there’s only so much one can do to improve NFS performance <rekado>GPFS is what the cluster uses now for most things <rekado>it’s a pity that IT went with the proprietary GPFS (I wonder why people still make these kinds of decisions), but in reality our NFS server was a proprietary appliance too. <civodul>i vaguely recall a "GPFS" by Red Hat or IBM <htgoebel>I have a package installing a lib into …/lib/plasma/libDiscoverCommon.so and …/lib/other/lib.so <htgoebel>Phase `validate-runpath' fails with: "…/other/lib.so depends on 'libDiscoverCommon.so', which cannot be found in RUNPATH" <htgoebel>And the RUNPATH shown does not include …/lib/plasma (but only …/lib) <htgoebel>I tried setting linker flags, but this did not help. <efraim_>I would think that if ../lib is in the RUNPATH then it would take plasma too <quigonjinn>any ideas about duplicate phases across packages, that only differ at some file paths? would it be ok to be defined as top-level procedures? <efraim_>Have you tried building it with -K and run ldd to see if that's the only one that's not linking? <efraim_>GCC has a patch that adds to vtv's runpath I believe, that might be something <efraim_>quigonjinn: I think it would depend on the specifics, for the qt packages they use inheritance <quigonjinn>efraim_: i didn't know what to grep for. i'll take a look at the qt packages then ***andreh1 is now known as andreh
<civodul>yeah i think someone sent the URL before <bavier`>many of the "problems" repology reports for guix are homepage permanent redirects <htgoebel>efraim: the libs are all linking, it's validate-runpath which fails. <janneke>civodul: nice...but what's with the `0 issues' entries? <civodul>janneke: initially the idea was that packages.html would have a link to issues.html#PACKAGE, which is why it contains even 0-issue entries <civodul>but i think sirgazil has ideas on how to make this better anyway :-) <sneek>Welcome back rain1, you have 1 message. <dTal>okay... why does adding a swapfile line in my /etc/config.scm result in a recompile of samba... <dTal>not to mention a bunch of downloads <bavier`>dTal: did you 'sudo guix pull' since your last reconfigure? <dTal>I have still never run guix pull actually <dTal>I really feel like my mental model is lacking here <janneke>rain1: i have paused my tcc.c compile efforts for a bit, mescc now compiles to `hex3' files and something even more close to OrianJ's stage0's hex2 <janneke>not a scheme interpreter in assembly yet, but getting just a bit closer ;-) <rain1>oh that is interesting, what is hex3? did you see the hex86 format I was playing with? <janneke>rain1: i guess i didn't. hex3 is essentially hex2+ and then as s-expressions (or hex2-, depending how you look at it). <janneke>hex3 (and my current hex2) needs annotations with labels <janneke>function-local labels, relative vs absolute labels, and 1/2/4-bit labels <janneke>other than that, it's x86 text and data with labels <rain1>I've been thinking about the lower level section a bit <janneke>yeah, with hex86 you take the other possibility wrt my annotated labels: `assemble' JMP* and CALL <rain1>it would be easy to write some simple programs like 'cat' and so on in hex86 <rain1>but implementing a language is harder.. the runtime for scheme is quite large <cbaines>Does anyone know of a way to take a file like /tmp/guix/gnu/packages/../.. and turn it in to /tmp/guix ? <rain1>so I am wondering maybe a lower level language but still something above assembly would be a good help to do <rain1>forth for example has a very small runtime compared to scheme, but i've not coded in that much <janneke>rain1: i was hoping to find a middle way between hex2 and hex3 with OriansJ, now your hex86 also plays :-) <janneke>rain1: i fear things get too slow with an extra indirection between assembly and scheme <janneke>but, who knows -- OriansJ's stage2 LISP is also nice <rain1>yes we must be careful not to stack interpreters <rain1>but as long as long as things are being compiled down they should stay fast <rain1>that is why i have been rewriting my scheme compiler, to avoid nested interpretation <janneke>otoh, as soon as stage0 can assemble+link mes'c hex2, we somewhat (with only a bit of cheating) closed the bootstrap loop on the lower end, if we can get mescc to compile a compiler that can compile gcc...done <janneke>yeah, we should move to compilation some time soon <janneke>rain1: it will get real fun as soon as we can somehow combine or build on all of our efforts <rain1>I think there are still a few things unclear, but maybe a plan can be listed and then we can fill the stages in one by one <rain1>janneke: how does the scheme implementation, mes, get started? <rain1>oh i guess OriansJ wrote a scheme interpreter <rain1>so it would be run with that <janneke>mes.c-the-scheme-interpreter needs to be available as a binary <janneke>there are several ways to do that, currently: using gcc, using the mescc C compiler run on Guile, or even using mescc the C compiler run on a mes-binary :-) <janneke>so, that's cheating...and i was hoping to move mes.c into mes.hex86 or something and produce a binary from that using OriansJ's stage2 linker <janneke>so, this bit is still somewhat fuzzy but i think we're getting closer <rain1>ahh mes has its own interpreter in c, which the scheme version can run on top of! <rain1>but mes is the first c compiler we expect to get up and running, i see the trouble now <janneke>i chose to just look away a bit from that until now ;-) <rain1>so just rewriting that interpreter in assembly, or maybe forth or some very low level language could resolve it <bavier`>oh, I hadn't considered that option before <janneke>and now that mescc compiles to something close to hex2, we're "almost" there <bavier`>maybe a scheme interpreter in Forth can be my next project <janneke>of course, c-compled hex2 is not really how you would code assembly/hex <janneke>bavier`: you do know that OriansJ has a form of forth and lisp in their stage0 project? <rain1>the reason I mention forth is because it requires much less 'runtime' when making an interpreter for it <bavier`>janneke: yeah, I've had a look at both before <rain1>another actually very reasonable option could be lambda calculus <rain1>it could be done with ref counting instead of gc <rain1>or something more like C (but drastically simplified) could be a good option too <janneke>rain1: seemingly so many possibilities <janneke>it would be nice to find a real sweet solution :-) <janneke>rain1: when we have decided on a workable hex format for mescc, the compiler can be greatly simplified <janneke>currently it calculates most jump offsets, with labels that all goes away <rain1>yes that is very nice building each compiler on top of the next <rain1>you get a accumulation of power <janneke>so i'll be working on simplifying mescc before extending it to handle tcc.c <rain1>having a more advanced assembler reduces the work of a scheme compiler, its ' a great technique <janneke>but i probably want to look at 8cc first -- tcc uses seemingly unnecessary complex C constructs <janneke>rain1: yes...it's as beautiful as logical...when you see it <rain1>I wonder what I should do to help most just now? if there's more info/testing needing done regarding C compilers I can look into it <janneke>quigonjin, rain1: yeah, beautiful metaphor for the bootstrap problem <janneke>rain1: i'm personally looking for two things: 1. some insights/decisive arguments on how to close the gap between hex2 and hex3 (hex86 might be it) ... but in a way that OriansJ is happy to produce an ELF from that <rain1>so I think OriansJ plan was building on top of this portable virtual machine, all the hex codes are programmed to this particular engine (maybe we can call it the Knight VM) <janneke>and 2.: the simplest C compiler to compile with mescc, hopefully simpler than tcc <rain1>on top of Knight VM he has a lisp interpreter, forth interpreter, some toolls like cat and such - it's a great way <janneke>or, otherwise: help to simplify tcc and help to compile it using mescc :-) <rain1>but how to implement the VM interpreter? that's why I was trying to follow his idea but directly to x86 instead of to a virtual ISC <rain1>so it could be used to build up towards implementing the knight VM, then on top of that we may have a basic set of assemblers, linkers etc. enough to get the mes scheme implementation going <rain1>just throwing one possible path/idea out though <rain1>simpler than tcc <- this is a difficult one, I don't think there is a older commit in the tcc repo of a "one-file tcc" that can be used <rain1>pcc can build tcc, but it quite a considerable codebase <rain1>maybe I should check out these ultra minimal c compilers like 8cc and see if any of them have a chance at building an early tcc <rain1>(I very much doubt it though) <rain1>basically (2) is very hard... <janneke>rain1: ah, when i say hex2 for mescc, i mean the x86 variant -- i don't mean to target the VM (yet) <rain1>oh btw a very nice test program might be the neatld linker <rekado>sneek: later tell civodul Yes, GPFS is an IBM thing, and it’s non-free. You have to purchase a license to be allowed to download a binary for RHEL. <reepca>cbaines: (canonicalize-path "/home/reepca/.././././reepca") => "/home/reepca". It appears to be a guile builtin that isn't documented in the reference. <ng0>jsierles, I'd rather use pagure instead of gitlab. well at least that's where I am moving personally and project related. Developed around fedora this one looks the most promising. <ng0>it's tough to get it working but of all the version control web systems I want this myself.. the package builds, just need to get the service definition right. gnunet-service and pagure, that'll be the work focus now. <ng0>rekado: nice work with tex :) <ng0>I think you all are quicker in response than the fsfe licensing team (I don't expect them to be fast and responsive): there was a deriviate license of the GPL2 way before GPL3 was made public, had a different name. I'm not sure if I am allowed to do the same with AGPL3. There's just one clause I want to add, the result of past discussions and chats. I'm not sure what the implication of a derivate license is. <ng0>All I want is AGPL3 plus this new paragraph in it. I think I would have to rename the license.. I don't know any software lawyers, but some other people who could help with proof reading the section <ng0>ah right.. I want to contact them later this year anyway for our project. I think that's a good advice, thanks <bavier`>ng0: the people at fsf are usually pretty good at answering license questions <ng0>I don't find irc a good way to communicate <ng0>fsfe had a 5 weeks delay, I guess the same will happen with fsf. But I'm in no rush with this license <ng0>of course the license is copyright fsf so I should fsf.. I thought about this today