IRC channel logs


back to list of logs

<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>here's the scm file i'm using:
<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 :)
<lfam>Scheme stuff :)
<jsierles>should i even be using this namespace?
<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>ah, thanks.
<jsierles>so i guess this will be some trial and error.
<jsierles>yay, well it installed anyway.
<jsierles>got pretty far now. but ran into: ERROR: Wrong type to apply: #<<license> name: "GPL 2+" uri: "" comment: "">
<lfam>Hm, weird. Can you share your latest package definition?
<jsierles>the gpl2+ seems to cause it
<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 <>?
<jsierles>sure thing
<jsierles>fixing that, i managed to get r-ggmap installed. so success!
<lfam>Woohoo :)
<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
<jsierles>right. i dont use emacs *duck*
<jsierles>easy enough to search in the source
<jsierles>just curious
<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>afternoon all :)
<eacces>ACTION returns for another guixing session
<janneke>Morning Guix!
<efraim_>Good morning!
<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
<jsierles>according to, gitlab now at least gets a 'acceptable' stamp.
<rekado_>jsierles: very unlikely
<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
<rekado_>other tools wouldn’t help here.
<jsierles>hmm, i disagree, but OK :)
<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
<jsierles>alright then
<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
<jsierles>ok - i didn't get that email.
<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
<rekado_>it’s also backed by debbugs
<rekado_>reviews are via email
<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
<rekado_>eacces: awesome!
<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.
<rekado_>ecraven: do you mean derivations?
<ecraven>no, the prebuild binaries thing, I think?
<ecraven>derivations are guile vs. nixlang, so they should be different, right?
<jsierles>cool, good to know
<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>maybe it was that then ;)
<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
<ecraven>that's what I meant ;)
<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_>by building it
<rekado_>(or rather: by having the daemon build it)
<jsierles>running the above should build it, right?
<rekado_>ACTION –> afk
<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>you mean inside the derivation file?
<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'?
<rekado_>are you still using “guix pack”?
<jsierles>nope. now just mounting the store directly and using paths
<jsierles>this seems simpler and more flexible.
<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_>looks like that’s because of grafts
<rekado_>doing this with “--no-grafts” gives me the same derivation for both
<jsierles>running dry-run with no-grafts?
<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
<rekado_>ACTION goes offline for a while
<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>Hello Guix!
<Apteryx>civodul: hey
<mekeor>hellou :)
<civodul>would be nice to have a dashboard for packages akin to
<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 '' 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
<civodul>you were thinking about YAML? ;-)
<civodul>JSON would be super easy to add
<civodul>rekado: i just learned about this: (“Spack and software reproducibility in HPC”, argh!)
<rekado>civodul: ah, Spack again!
<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>GPFS is proprietary?
<civodul>i vaguely recall a "GPFS" by Red Hat or IBM
<catonano>civodul: what's spak ?
<civodul>catonano: a package manager for HPC:
<htgoebel>Hi guix!
<htgoebel>I have a package installing a lib into …/lib/plasma/ and …/lib/other/
<htgoebel>Phase `validate-runpath' fails with: "…/other/ depends on '', 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.
<htgoebel>How to solve this?
<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
<catonano>civodul: thanks
<civodul>"Modular Texlive" oh my!
***andreh1 is now known as andreh
<mekeor>did you know repology? it's a tool/website to compare package versions in many repositories. and guix is present there, too:
<mekeor>there are even some problems repology detected in our packages:
<civodul>yeah i think someone sent the URL before
<civodul>it's interesting
<civodul>note that we have too
<bavier`>many of the "problems" repology reports for guix are homepage permanent redirects
<bavier`>for http -> https
<bavier`>which is not really a problem imho
<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 :-)
<janneke>good :-)
<janneke>there's been yet another lxd effort, this time by epronk: anyone got clues here?
<sneek>Welcome back rain1, you have 1 message.
<sneek>rain1, OriansJ says: you might like this one
<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
<janneke>hi rain1!
<dTal>I really feel like my mental model is lacking here
<rain1>hey :)
<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
<rain1>what I did was take hex2 and start adding some nmemonics for x86 opcodes (as well as 1 byte long label references) --
<janneke>other than that, it's x86 text and data with labels
<janneke>rain1: *nice*
<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
<janneke>yes, indeed
<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>rain1: no...
<rain1>ah, what is the plan then?
<janneke>i cheated until now
<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>..but its just one option
<rain1>another actually very reasonable option could be lambda calculus
<rain1>it could be done with ref counting instead of gc
<janneke>ah okay, sorry ;-)
<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:'s as beautiful as logical...when you see it
<rain1>janneke: have you seen the logo I put for the wiki
<janneke>rain1: nice! quite an apt logo!
<quigonjinn>rain1: that quote from anon is hilarious
<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.
<sneek>Will do.
<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
<jonsger>ng0: maybe
<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
<bavier`>ng0: have you asked in #fsf?
<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