IRC channel logs
2016-11-07.log
back to list of logs
<Apteryx>Hmm. I'm trying to make udisks build with its manpages, but this requires the docbook to be registed in the xml catalog. Do we have such a catalogue on GuixSD? <Apteryx>I have two options from my understanding of xsltproc: 1) Iappend an entry to "/etc/xml/catalog" which points to the path (docbook-xsl), or 2) I set some env variable "SGML_CATALOG_FILES" to the path (docbook-xsl) to be used by the gnu build system, and have to hack autoconf files into calling xsltproc with the --catalogs option... The former seems simpler, right? <marusich>Apteryx, I don't have an answer for that; the best I can do is suggest looking to see if any existing packages do something similar. <marusich>A few recursive greps "grep -ri mykeyword ." and maybe git log searches (e.g., "git log -SSGML_CATALOG_FILES") might help <marusich>If you mean that we cannot build the manpages for the "udisks" package unless certain state is present in the /etc/xml/catalog system file, then in the interest of making the build self-contained and reproducible, your option (2) seems preferable. I don't know much about what you're trying to do, though, so I could be mistaken. <marusich>In addition, if to accomplish (2) you need to change the autoconf files, I wonder if perhaps that's a change you could push to get put in upstream, so that we can just specify the environment variable in the build and be done with it? <Apteryx>marusich: I'm going to try every options by hand at first, to see what works. Thanks :) <Apteryx>Scheme question: can I insert a (let* ) anywhere? Say, between a #:keyword-arg and its value (list ...)? <marusich>Apteryx, since a let* form will evaluate to the value of the last expression in its body, you can use a let* form anywhere you would normally need some value. <marusich>So, for example, (string-append "foo" "bar") could be replaced with (string-append "foo" (let* ...)) as long as the (let* ...) evaluates to "bar". <Apteryx>How can I get the name, version, or any field out of a package object? <Apteryx>It assoc-ref? "->" notation? Sorry... quite new to scheme. <marusich>Apteryx, it's a little different. Check in guix/packages.scm for (define-record-type* <package> ...) <marusich>This defines a field called "name" which can be accessed via a procedure called "package-name" - you'll notice that package-name is in the #:export list at the top of the file. <marusich>To quote Ludo, "A widespread Scheme convention is that, for a type T, the procedure to <marusich>Finally, for more info about the syntax "define-record-type*", check out its definition in guix/records.scm. It's not documented in the manual. <marusich>The Info node "(guile) Record Overview" is also useful because the define-record-type* syntax creates objects that are similar, but more featureful, to those kinds of records. <marusich>Apteryx, you'd have to ask Ludo :) But sure, I think commonly the G would be the same as F. <marusich>Perhaps there are occasions where you might use a G that is different than F <marusich>But you'd always prefix it with T, that's the point I think. <marusich>A lot of the internal structures used in Guix are created using define-record-type*, so their accessors follow the same pattern. <Apteryx>marusich: Thanks a lot :) This should get me going for a while. <jmd>sneek: Tell civodul later that (gnu services nfs) has everything (I think) to mount nfs directories, but not (yet) to export them. <sneek>civodul, jmd says: later that (gnu services nfs) has everything (I think) to mount nfs directories, but not (yet) to export them. <jmd>didn't I say "later" ? <jmd>sneek: later tell civodul later that (gnu services nfs) has everything (I think) to mount nfs directories, but not (yet) to export them. <Apteryx>So, to access the name of package symbol docbook-xsl, would I do: (package-name docbook-xsl) ? <sneek>civodul, you have 1 message. <sneek>civodul, jmd says: later that (gnu services nfs) has everything (I think) to mount nfs directories, but not (yet) to export them. <rekado>I just received a call to apply for a grant to fund efforts to sustainably provision research software. <rekado>Guix looks like a very good match <civodul>rekado: is it an EU FP kind of thing? <civodul>janneke: are you planning to talk about Mes at FOSDEM? hint hint ;-) <janneke>hi civodul! i'll think about it; i'm not too thrilled by the idea. <janneke>all i have is halfway experiments atm <rekado>civodul: it’s a grant issued by the Deutsche Forschungsgemeinschaft for their e-Research programme. <rekado>civodul: I’ll see if our research group can apply for it and get funding for more work on Guix. <rekado>the objective is building and testing infrastructure to make research software available and provide it in a sustainable manner to a large audience. <ng0>I think I could talk at fosdem about what I work towards with guix, but I just came to the regular realization that I'm just too broke. <civodul>ng0: you're too broke? i think you could/should just submit a talk on whatever you think might be relevant to others <civodul>it can be a short talk if you think that's more appropriate <ng0>i mean, traveling expenses are a risk for me. <jmd>Do a talk by video link. <civodul>we're not really in a situation where we have Guix funds that could go to travel expense support :-/ <civodul>janneke: i think the whole experiment is interesting anyway :-) <ng0>I talked to someone living around there and a place to stay at is no problem, but I still have to cover ~60 - 80 euro there nd back again <ng0>civodul: yeah, which is why I'll just wait until what I do is.. well, visible. right now it's the state where you have a roadmap, and many construction sites, but nothing I can present <ng0>the best product to present is the one which exists, not the idea :) <jmd>I don't necessarily agree. <ng0>it's easier, usually <jmd>If something already exists, why would anyone want to go to a conference to hear about it? <jmd>Conferences are for new and upcoming things. - ideas!! <jmd>Obviously one should demonstrate that you have thought carefully about the idea. A proof of concept is a good thing to have. <ng0>ok, i agree there. that's what I meant, there's no prototype or demo right now <jmd>civodul: What did you want to know about nfs configuration? <civodul>sneek: later tell jmd re nfs, i was trying to see how the set of services is supposed to be used and whether it could export or simply mount NFS trees; IOW, i was looking for an example :-) <Apteryx>I get this output when I try building the package: ERROR: In procedure memoize-variable-access!: ERROR: Unbound variable: package-name. <bavier>Apteryx: you need to unquote the doxbook-xsl reference, or the entire string-append <bavier>since the quoted code is executed by the builder, which has no notion of the docbook-xsl package variable <Apteryx>Is there a way to "step" the code as I do a "guix build"? I'm still having a error: ERROR: In procedure scm_lreadr: /gnu/store/n70dbq007rqamxmrzjrfssla5ypb4bdv-my-udisks-2.1.7-guile-builder:1:4627: Unknown # object: #\\<. The modified udisks package now looks like this with the backquoting: http://paste.lisp.org/display/330614. <davexunit>if you learn to use the Guile REPL and try out code like this and then use the debugger if something goes wrong <davexunit>Apteryx: to elaborate on the problematic code, you are unquoting a package object. <davexunit>but the structure you are building is a quoted section of code <davexunit>and package objects aren't a serializable object here <davexunit>thus the 'read' procedure fails when guile tries to evaluate the code that has unrecognized syntax like #<package ...> <Apteryx>davexunit: By using ,docbook-xsl I thought I'd be getting the string corresponding to its store item. <Apteryx>Maybe... (package-location ,docbook-xsl) ? I'll try the Guile REPL as you advised! <Apteryx>The whole expression unquote I meant. <Apteryx>Looks like I have to look at the store interface rather than the package interface to get a store item path. <davexunit>Apteryx: no, that is what happens in a g-expression, though. <Apteryx>davexunit: OK, that's where I must have gotten that idea from. <alezost>Apteryx: I think instead of “,docbook-xsl” you want “,(assoc-ref %build-inputs "docbook-xsl")” <roptat>I'm trying to add a package, but it fails with /gnu/store/...libr2.so: error: depends on 'libr_core.so', which cannot be found in RUNPATH <roptat>libr_core.so was installed as part of this package, and indeed is not in the RUNPATH <lfam>Basically, you'll need to add some linker flags to the package definition to manually add the appropriate directroy the runpath <efraim>rekado will be happy to know that keepassx should switch to qt5 with 2.0.4 <efraim>and for you i've got qsyncthingtray almost working, it just needs a custom install phase since it doesn't ship with one <lfam>I should send in my Syncthing package definition. It's better to have it than to wait for a go-build-system that I don't understand how to create <efraim>now I want to learn how to change my syncthing systemd unit thingy to a shephard process <lfam>Oh, I forgot about all of Syncthing's bundled stuff. That's the real reason I didn't submit it sooner <lfam>Dozens of bundled libraries <lfam>I still don't have any idea how to make a Go build system that would let us avoid the bundled stuff. <lfam>There doesn't even seem to be a standard "manifest" file that can be automatically parsed for dependency information <efraim>the best i've thought of so far is for each package to have a "bin" and a "src" output <efraim>and to replace the bundled libraries with the "src" output <ng0>isn't there? gogs has one <ng0>i mena a file for dependencies <lfam>Go developers don't even specify which version of the dependencies they are using. Just random Git commits <efraim>or at the very worst with (package-source "bundled-lib-53") <ng0>my understanding, from the limited exposure with gogs and gitlab related packages is, that versions in Go dependencies are mostly git commits, and a file like this https://github.com/gogits/gogs/blob/master/.gopmfile defines the dependencies, but i don#t know how often this ocurs <lfam>From what I've seen, those files are different from project to project. Some projects don't even have them. <lfam>They also made a serious error only keeping 7 characters of the Git commits. <lfam>I think I must be missing something about how Go software is built. I wish a Go expert would fly in and explain it all for us :) <lfam>There has been some explication on guix-devel, but not enough for me to see what the right direction is <lfam>efraim: Does qsyncthingtray implement syncthing's protocol itself, or does it require syncthing to be installed separately? <efraim>it requires it to be installed separately <efraim>yup, I have a copy of it in my GUIX_PACKAGE_PATH <lfam>It's very frustrating for it to be "out of tree" for so long <efraim>thats what made me start using the GUIX_PACKAGE_PATH for more of my wip projects <efraim>If i needed something new I added it to the bottom, when it was time to submit to the list I'd add pacakges from the bottom to the top of the file <efraim>then again now I have a couple of packages that I need to send in <efraim>translate-shell, vifm, rkflashtool, viewnior, newsbeuter, emacs-aria2 <ng0>that#s why I have like 60 brnaches and 40 more checkouts.. package path would've been better :D <ng0>because i lost control. <efraim>what was that newer git feature, working-path or something, that let you have another branch in a different dir <ng0>yeah, but i'm not so much into reading up on new features so i missed that <ng0>some branches / checkouts just sit there without saved state <lfam>I guess I just rebuild my checkout as necessary <ng0>until I get "that" idea to fix the failure i had <lfam>Looks like Nixpkgs just uses the bundled libraries. Their package definition is basically the same as mine <lfam>Debian, on the other hand, made packages for each of the those bundled libraries. So, it is possible to do <bavier>has anyone attempted an nfs-service yet? <Sleep_Walker>when I have missing (gnu service networking), connman-service is unbound variable <Sleep_Walker>guix system: error: service 'networking' provided more than once <bavier>Sleep_Walker: wicd-service is in %desktop-services, and provides the 'networking' service. you may need to remove it before adding connman-service <Sleep_Walker>is there reason why I can't have installed both at the same time?