<suitsmeveryfine>Hi! I've packaged a game that I'm trying to build but get this error: "Unknown option --enable-fast-install". Any ideas about what I can do about it? I've simply used (build-system gnu-build-system) in the package definition.
<spudowiar>I was just wondering, does #!/usr/bin/env work in GuixSD?
<efraim>suitsmeveryfine: if it builds anyway then don't worry about it, if the error causes it to fail to build then you need to replace the configure phase
<efraim>spudowiar: we don't have /usr/bin/env in GuixSD
<spudowiar>efraim: that's what I thought, how would you use shebangs on GuixSD then?
<efraim>iirc /bin/sh works, but for the others they have to be patched I think
<efraim>i don't think we've come to a consensus what to do about it yet
<roelj>I have about 45 R packages I would like to add, which is about the entire dependency graph for a single R package I actually wanted. Should I send one mail to the list with 45 patches? Or should I split them in groups of related functionality? Or should I send 45 mails to the list? Or should I just keep them outside the guix master?
<efraim>there's a command line argument to patch it at run time but I don't have it written down
<wingo>iyzsong: one more thing i forgot -- the argument to get-string-n isn't bytes
<iyzsong>there is no /etc/config.scm on my system. I put and manage my config.scm in /etc/guix.
<wingo>so probably to be correct you should use get-bytevector-n and then convert to a string
<suitsmeveryfine>iyzsong: these are the configure flags that were called automatically: "configure flags: ("CONFIG_SHELL=/gnu/store/b1yqjimbdh5bf9jnizd4h7yf110744j2-bash-4.3.42/bin/bash" "SHELL=/gnu/store/b1yqjimbdh5bf9jnizd4h7yf110744j2-bash-4.3.42/bin/bash" "--prefix=/gnu/store/yglqy6ahpljdfjskznjrbmw1sj1d2252-openttd-1.6.0" "--enable-fast-install" "--build=x86_64-unknown-linux-gnu")"
<suitsmeveryfine>So you're saying that I would need to add all of these except "--enable-fast-install".
<spudowiar>iyzsong: yeah, the installation says to create one but AFAICT, it's stored there just for reference
<spudowiar>Anyway, I'm new to Lisp, so I might be on here quite often
<iyzsong>suitsmeveryfine: you can figure them out by run the 'configure' script manually in 'guix environment', etc.
<suitsmeveryfine>iyzsong: OK -- when I do this I get an output like this: "checking build system type... x86_64-unknown-linux-gnu [...] checking build cc... gcc [...] detecting SSE... found [...] configure: error: no video driver development files found"
<spudowiar>wingo: how do I list all herd services? I'm trying to restart sshd (lsh)
<ngz>I have a question about package creation. I wrote a new package definition in GUIX_PACKAGE_PATH and successfully installed it in the store. Now I'm trying to send a patch for inclusion. I pasted the definition in the appropriate module in /gnu/. How can I check if it is still correct (e.g., there is no missing use-module at the beginning of the module)?
<ngz>roelj: Thank you. Do I have to do this each time I pull from the git repository?
<davexunit>we cannot host dynamic web applications on gnu.org anyway
<roelj>ngz: Well, what I do is this: 1. 'git pull' to get the latest changes; 2. Add my package; 3. Test my changes; 4. Commit the changes; 5. Run 'git format-patch -1 --no-attach' to create a patch file; 6. E-mail the patch file to the mailing list.
<ngz>roelj: Actually, as I tried to explain, the third point is giving me headaches. I'm fine with the others, tho :)
<roelj>ngz: If you make a symbolic link in $HOME/.config/guix/latest that points to your Git repository directory, then you'll be able to test your changes.
<roelj>ngz: What is it, that you're exactly running into? If you are able to build and install the package once it's in the Guix repository checkout, it be fine for others too.
<ngz>roelj: Basically, I create a branch in my local repository and made the changes to a module. I cannot guix build my-new-package because it is not found. I had no pre-inst-env script before your help: ./configure created it.
<roelj>ngz: Aha, ok. And now with ./pre-inst-env you're able to test your changes?
<ngz>Now, I try ./pre-inst-env guix build my-package from the root of the repository, and I get a cannot connect to socket error.
<ngz>OK, I have one last point (hopefully) to solve. How can I remove a previous derivation from the store. guix package -r package doesn't remove the derivation. If I delete the previous generations and call "guix gc", it will probably remove too much.
<roelj>Oh.. I see.. there's no 'configure' phase in r-build-system. The './configure' is run in the install phase..
<anthk_>Jookia, show me a link to that code on github
<anthk_>if exists, tell marrub it has code incompatible with the GPL
<Jookia>anthk_: is marrub on IRC? or is there a gloom channel?
<anthk_>Jookia, "All of the code from Doom has been relicensed from the Doom Software License to the GPL license, and all legally troubled code (such as the code taken from Ken Silverman's BUILD engine) have been either removed or rewritten and licensed to be GPL compatible."
<suitsmeveryfine>Is it possible, in the package definition, to use "modify-phases" to replace a particular configure option with an empty string? The thing is that I'd like to remove a particular option, "--enable-fast-install"
<bavier>suitsmeveryfine: have you tried putting "--disable-fast-install" in #:configure-flags?
<bavier>or is it a case of the configure script failing on unrecognized option?
<suitsmeveryfine>bavier: Now I get this: `sh-4.3.42/bin/bash" "--prefix=/gnu/store/iqzmdgbda69wd3wixv6gblw1sfhq7fpd-openttd-1.6.0" "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" "--disable-fast-install") Unknown option --enable-fast-install`
<suitsmeveryfine>bavier: yes, other people suggested this to me earlier. The trouble is that I don't know which options to add. That's why I asked earlier if there's a way to remove a particular option rather than defining all the options manually.
<alezost>suitsmeveryfine: why do you need to remove --enable-fast-install? Does it gives an error or just warning?
<mark_weaver>civodul: sure! I mainly got stuck because I was trying to verify that the resulting grafts were good, and they weren't. but those problems seem to exist without my changes as well.
<mark_weaver>civodul: also, although I haven't yet filed a bug report for it, my attempt to eliminate duplicate grafts failed, because sometimes (but not always) a graft derivation includes extraneous inputs.