<codemac>nvm figured it out, bad ctrl-left in paredit <amz3>I find editing with paredit more difficult, right now, I need to get more confortable with guile I think <mark_weaver>codemac: I wish you had consulted with us about how best to go about writing the 'go' package. it's a bad idea to use the trivial-build-system for this. I'm afraid this is the wrong approach. <mark_weaver>gnu-build-system takes care of the rpath issues automatically in various ways, and you're reinventing the wheel here I'm afraid. <mark_weaver>for example, we have something called 'ld-wrapper' that automatically adds the rpaths to the linker commands. <mark_weaver>you are having to use patchelf, which is very non-portable and currently only works on intel systems, to work around your lack of ld-wrapper usage. <mark_weaver>and of course, you're having to reinvent things that are done in the early phases of gnu-build-system, e.g. setting environment variables <codemac`>mark_weaver: no worries, I'm just learning things here. I wasn't anywhere near ready to post that to guix-devel or anything. <codemac`>mark_weaver: the problem is that the go binary doesn't have the same elf sections that things notice, and go does not use ./configue, make, or any of the stuff in gnu-build-system so this was my experiment to figure out what it *did* need. <codemac`>mark_weaver: any pointers about ld-wrapper? <codemac`>mark_weaver: not to mention building go doesn't use gcc ld, it uses their own ld that uses different commands. I'm not sure I see how gnu-build-system helps a ton here, but I don't know much about the packaging system yet. ***codemac` is now known as codemac
<davexunit>does anyone have a good resource for understanding how psuedo-terminals work? <davexunit>I'm reading the gnu libc manual, but I feel like I need more background to really grok it. <codemac>davexunit: another thing that probably cares a lot about this is things like logind? maybe they have more resources too? <davexunit>codemac: are you saying that the logind source code might have good information? <codemac>yea, beacuse they have to open ttys / ptys to open consoles, and they may have docs that explain it since systemd is rewriting the globe for whatever reason. xterm / ssh may be interesting as well. <davexunit>let's try to implement this and get 'make' to not crash! ***ruukasu is now known as ploopkazoo
<rekado->amz3: you can have something like useflags in guix as well. <rekado->you just need to inherit from the package you want to customise and overwrite a couple of things. <rekado->e.g. add one more input, add one more configure flag. <rekado->you just won't get binary substitutes from hydra for those packages that are affected by the change, but on Gentoo you don't have substitutes anyway. <rekado_>for the r-build-system I need to know all transitive inputs, not just the direct inputs. Is there an easy way to get them? <amz3>transitive inputs are inputs of inputs? <rekado_>we have a couple of procedures on packages, but it seems like they are not available on the build side <rekado_>maybe I really should propagate the inputs. <rekado_>yup, propagating the inputs fixes things. <rekado_>whee, the r-build-system actually works! <rekado_>I just finished packaging the first non-trivial R package and all its dependencies (ggplot2). <rekado_>only had to make a couple of tweaks. <rekado_>There are some tarballs that are only offered via FTP and FTP access requires a public username+password. <rekado_>guix uses a fixed username for anonymous access. <rekado_>it would be nice if ftp URLs like "ftp://name:pass@some.site" would work. <cehteh>anyone still running ftp servers? :) <mark_weaver>rekado-: interesting. out of curiosity, what package is this for? <mark_weaver>I suppose it wouldn't be too hard to extend our ftp code in that way, although I've never looked at it in detail <bavier>for applications using gstreamer plugins, is it enough to add the plugin package to 'inputs', or does something need to be set in the runtime environment too? <rekado_>mark_weaver: no package in particular. I just noticed it when looking at some proprietary bioinfo tarball download site. <rekado_>could be that it's not a problem in general. <davexunit>ACTION continues to screw up using psuedo-terminals <amz3>bavier if you think about updating the environment search path, then it's automatically reported by guix I think <amz3>bavier: have a look at totem <bavier>amz3: thanks, just the pointer I needed <mark_weaver>bavier: for now, my recommendation is to do something similar to what I did for totem. <bavier>I'm not so familiar with the audio world <bavier>I ran the application I was packaging, and audio seemed to work, then later didn't. But I might have been in a 'guix environment' the first time. <mark_weaver>bavier: gstreamer searches for its plugins in directories of GST_PLUGIN_SYSTEM_PATH <mark_weaver>so unless a wrapper sets that variable, gstreamer won't find any at all. <mark_weaver>in the general case, users should install the plugins they want in their profile and set that variable to ~/.guix-profile/lib/gstreamer-1. 0 <mark_weaver>however, I think it makes sense to include a minimal set of plugins via a wrapper for common applications. <mark_weaver>however, I think the wrapper should *not* include gst-plugins-ugly, which includes things like patent-encumbered formats like mp3 and h264 <bavier>mark_weaver: in this case, there is a specific plugin in gst-plugins-base that the application needs, so adding a wrapper seems fine to me. <bavier>the plugin is needed for playing some bundled audio snippets <jynxy>people used to talk in chat rooms <jynxy>anyone answer a simple guix related question for me? <jynxy>ill send you a electronic blowjob <jynxy>is there a way to invoke useradd or adduser in guix? <mark_weaver>you add users and groups on GuixSD by editing your OS config and re-running "guix system reconfigure <config>" <rekado->jynxy: you can also run useradd directly, but you'd need to have sbin in your PATH and shadow installed into your profile. The better way is to do it via OS config. <jynxy_>anyone able to answer a simple guix question for me? <jynxy_>thank you for being a person dave <jynxy_>is there a way you know of to invoke useradd or adduser on a pure guix system? <jynxy_>I am trying to install nix and well... <jynxy_>I feel like I have a very secure os with nothing to secure <davexunit><mark_weaver> you add users and groups on GuixSD by editing your OS config and re-running "guix system reconfigure <config>" <davexunit><rekado-> jynxy: you can also run useradd directly, but you'd need to have sbin in your PATH and shadow installed into your profile. The better way is to do it via OS config. <jynxy_>I will commit all the guide to memory soon thank you for entertaining me <jynxy_>im sure it was up there and I just missed it <mark_weaver>rekado-: can it be done by hand? I have some recollection of a discussion where users would be removed if they weren't in the config, but I'm not sure whether that's implemented or not. <jynxy_>odd. I found useradd but it is not under a profile it is just in the store <jynxy_>I have had to link a few items I thought would be undermy profile by hand <jynxy_>like any python library qt... but whatevs <jynxy_>if it wasn't hard it wouldn't be good I suppose <mark_weaver>jynxy_, rekado-: you should not add user accounts by hand. if you do, the account will be removed the next time you run "guix system reconfigure" unless it's in your OS config. <bavier>jynxy_: I'd recommend you read the manual sooner rather than later <jynxy_>I did... just gotta work on that retention part <mark_weaver>see (for-each delete-user ...) in gnu/build/activation.scm <mark_weaver>jynxy_: this channel is not about nix. it is about Guix. <mark_weaver>jynxy_: if you're running nix, you're in the wrong place <jynxy_>I suppose you invented the egg too <davexunit>guix uses some low-level tools and file formats from nix ***mattl_ is now known as mattl
<yenda>I saw in the log that the crazy guy from yesterday came back davexunit :D <rekado->well, *did* someone here invent the egg? <yenda>Was reading the logs and I knew it was him from the first sentence <amz3>I know for close, very near, experience, that guile and guix can make someone smile or become hilarious or creative but this... is a bit much ;) <yenda>I'm pretty sure this is the same guy I told you about who made a rant on #docker <yenda>anyway back to business on go package <yenda>I get this error : "error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory". It's wierd because libgcc_s.so.1 seems to be included in gcc (according to debian packages) <codemac>yenda: did you get the runtime/cgo.a errors? <yenda>no only this one since it breaks the build <codemac>ok. the gnu-build-system doesn't handle the go c compilers, so a lot of stuff breaks given your last package definition I saw <codemac>though I think I need to figure out how to use ld-wrapper <yenda>oh I see because it bootstraps with C but then it uses go itself <codemac>I used the external linker to get things building & running correctly. <codemac>they all run now successfully during build, but everything segfaults when I run them after install. I think mark_weaver had suggestions for me, but a lot of the gnu-build-system stuff is invalid for go's completely non-gnu build <davexunit>codemac: maybe you should take a look if Nix has a go package <codemac>Yea, there's is 1.4.1, and I don't see how they fix these issues <codemac>They manually patch the cmd/6l/asm.c to point to their ld-linux, but guix doesn't do ld-linux the same way <codemac>(substitute* "cmd/6l/asm.c" (("/lib64/ld-linux-x86-64.so.2") (string-append glibclib "/ld-linux-x86-64.so.2"))) <codemac>^^ I tried that, but it hasn't been working for me. <codemac>bavier: because it's not just another compiler, it's also another runtime (as of 1.4, this may change for 1.5 as the compiler & runtime will be written in go). So basically anyone using go doesn't use it. <rekado->codemac: and you cannot use it for bootstrapping either? <rekado->for the JDK I used GCJ for bootstrapping. <rekado->GCJ + classpath is also not used by anyone in production, but it's sufficient to compile the JDK. <codemac>rekado-: I'm not sure, go combines their build and run steps, and include their own go_bootstrap. It's a very convoluted build system so I haven't exhausted all options yet. <bavier>codemac: ok. I'm not knowledgeable in go, but saw the bullet in gcc 5's release notes <yenda>Well I'm nowhere close to your understanding of how go bootstraps and compiles, I just figured I'm missing a library or something and hoped gccgo had it but it wasn't the case <mark_weaver>codemac: in practice, gnu-build-system is the one to use even for non-gnu builds. <mark_weaver>(unless we already have another build system for it, e.g. python-build-system) <mark_weaver>trivial-build-system is almost never the right thing for anything that's compiled at all. <davexunit>gnu-build-system is worth using even if the only thing you end up using are its shebang patching phases <codemac>even when I directly pass rpath's to gcc & 6l for whatever reason libgcc_s.so is left dangling when I run ldd <davexunit>I'm having my own libgcc issues trying to get an AVR cross-compilation toolchain working <codemac>and patchelf was my last ditch effort, but you guys are right, it's pretty poop <bavier>agreed. I fell to its temptation a while back for a project, and now it's caused me a bit of trouble. <yenda>codemac: it's not the problem and might be wrong but can you use (setenv ...) rather than (zero? (system* "env" ...)) ? <yenda>codemac: I tried your install it builds but I don't have the go command after install <dmarinoj>What would be involved in packaging stumpwm for guix? <davexunit>dmarinoj: figuring out a common lisp build system. I just looked and we have ccl, clisp, and sbcl packages. <davexunit>stumpwm may have prerequisite CL libraries that need to be packaged <davexunit>it would lay the foundation for packaging other common lisp libraries <davexunit>I don't use common lisp, so I don't have more details to share than that. <davexunit>I know there's something called quicklisp that we could perhaps write an importer for once a working build system exists. <davexunit>I just ran 'guix environment --ad-hoc sbcl -E sbcl' and got an SBCL REPL prompt. wee. <dmarinoj>davexunit: Sounds good. I would like to maybe help but I am new to guix. How difficult would this be? <davexunit>dmarinoj: you'd need to get familiar with the packaging concepts. how is your Scheme know-how/ <dmarinoj>davexunit: I am somewhat experienced with emacs lisp and common lisp and have played around with scheme a little <dmarinoj>davexunit: also experience packaging for dragora <davexunit>give it a shot, read the manual, ask questions here. <codemac>it doesn't pass all it's tests with the same libgcc_s.so error though :/