IRC channel logs


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.
<Apteryx>Great, thanks!
<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>For example, you will see the line:
<marusich> (name package-name) ; string
<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>access field F is called ‘T-G’." (From:
<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.
<Apteryx>You meant 'T-F'I guess? :)
<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>Anyways, hope that info helps.
<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.
<marusich>You're welcome! :)
<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.
<sneek>Will do.
<Apteryx>So, to access the name of package symbol docbook-xsl, would I do: (package-name docbook-xsl) ?
<civodul>Hello Guix!
<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: neat!
<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.
<rekado>ACTION goes afk for a while
<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>i'm sure you'd find a topic
<civodul>it can be a short talk if you think that's more appropriate
<ng0>i mean, traveling expenses are a risk for me.
<civodul>oh sorry, i misunderstood
<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?
<ng0>sneek: later tell lfam: I wasjust told that sks 1.1.6 added ed25519 support, but some servers are still on older versions, so EC keys are not found. see and for more :)
<sneek>Got it.
<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 :-)
<sneek>Will do.
<Apteryx>Could someone tell me what I'm doing wrong with accessing the name, version of package "docbook-xsl"?
<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>bavier: Thanks!
<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:
<davexunit>Apteryx: ,docbook-xsl
<davexunit>that's your problem
<davexunit>if you learn to use the Guile REPL and try out code like this and then use the debugger if something goes wrong
<Apteryx>davexunit: OK, I will try, thanks
<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>I'm probably wrong about that :)
<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.
<davexunit>which aren't being used here.
<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/ error: depends on '', which cannot be found in RUNPATH
<roptat> was installed as part of this package, and indeed is not in the RUNPATH
<lfam>roptat: Check this recent discussion of that very topic:
<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
<lfam>That's good
<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>The "Go" way
<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")
<lfam>ng0: What do you mean?
<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 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.
<davexunit>sounds like a nightmare...
<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> here's what I have so far for it
<lfam>Cool. I assume you've seen my Syncthing package?
<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
<ng0>lfam: ah, ok
<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
<lfam>I figured out why GOBIN doesn't work for Syncthing. The Syncthing install target sets GOBIN to the current directory:
<lfam>40 checkouts? Why?! :)
<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
<ng0>good night o/
<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>where is defined openssh-service?
<Sleep_Walker>I can see only openssh-service-type
<Sleep_Walker>\\o/ finally walked through guix-devel ML
<Sleep_Walker>hm, I wanted to try connman-service
<Sleep_Walker>when I have missing (gnu service networking), connman-service is unbound variable
<Sleep_Walker>when I add it, I got
<Sleep_Walker>guix system: error: service 'networking' provided more than once
<Sleep_Walker>any trick to get rid of this?
<Sleep_Walker>I have found but that doesn't look helpful
<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>I see
<Sleep_Walker>is there reason why I can't have installed both at the same time?