<ng0>i don't understand this.. i added the dropbear service to the testvm, added a line in gnu/system/vm.scm to enable port forwarding, and i still can't ssh into the vm
<lostcoffee>hey guys! I'm trying to dual-boot and so I installed with guix system init --no-grub, hoping that debian's automatic grub configuration would detect guix and add a grub menu entry. However, that's not happening. Should I just make an entry manually?
<lostcoffee>(also I noticed that the installation didn't make a /boot directory. Is that a problem?)
<jmd>jamesrichardson: I think sharing /gnu/store is not possible
<jmd>Sharing /home might also be problematic if the two guixes have different localstatedir
<jamesrichardson>hmm, might just have to keep things completely seperate until I lean more about guix.
<jamesrichardson>OpenAFS seems not to be packaged yet (I couldn't find anything). Don't see nfs either.
<jmd>Strangely enough, I'm working on NFS right now.
<jamesrichardson>I would offer to help (still can I guess). Just learning about guix. I need to learn scheme.
<brendyn>I would like to package my first program, praat, but there is an issue. praat's source is simply in a github and there doesn't seem to be a tarball, only binaries, so it seems I need to build from the repo
<lime_>I study ethical hacking at university so most of my friends run Linux
<lime_>I am going to write a driver for this WiFi card when I get GUIXSd up
<brendyn>I think Stallman is right, if we do not have the stuborness to look at the license agreement and say "no, this is unacceptable", then we will simply fail. As a matter of consistency, if you need one proprietary program, you'll accept more under similar circumstances
<rekado_>mark_weaver: I’ve just pushed two commits to “gtk-im-modules”, which requires a rebuild of both GTK+ packages. Can we build this separately? It’s for making input methods actually work with all GTK applications.
<ng0>these are requests and features I should document in my packaging process for secushare.. so they get some use in upstream (guix) documentation at some point. I will try to build with a core dump phase now.
<ng0>i really need to debug this.. i know this hasn't been tried before and I can't reproduce the fail on other systems I have, so I welcome suggestions on how to maiplulate whatever is needed to achieve what I want
<jmd>But I think that is something to discuss on #emacs or #guile and not on #guix.
<brendyn>Ok. I'm still drowning in the deep end here using emacs
<davexunit>if you use the guix emacs stuff it will fix those indentation issues
<brendyn>I'm still figuring out how to install that
<davexunit>%standard-phases should be on the same line as modify-phases
<davexunit>the indentation rule for it specifies that indentation should happen after the first argument
<davexunit>see .dir-locals.el for that and other indentation rules
<catonano>ng0: you might want to write on the mailing list about this
<ng0>doesn't the guixbuild user in the environment have some kind of .bashrc where I can set this value?
<ng0>it does not require root... at least I was able as a normal user to execute it
<ng0>I will look at the sauce for examples on how to activate this in the build
<davexunit>ng0: sounds like you are trying to overcomplicate things again.
<davexunit>is the problem that you need a parent process to run ulimit and then spawn a child process?
<davexunit>because otherwise the ulimit wouldn't take effect?
<ng0>the only information I have so far was the comment provided in the link on mantis
<davexunit>"The ulimit utility shall set or report the file-size writing limit imposed on files written by the shell and its child processes"
<ng0>This happens if GNUNET_snprintf() is called with a buffer that is too small. If you enable core dumps, you should get one, and then please obtain the stack trace (gdb test-binary core-file => bt full). That'll help me find what went wrong.
<davexunit>I wouldn't recommend doing this debugging in a package build
<ng0>the question then will be, can I reproduce the guixbuilder limitation when I do a user build..
<brendyn>/home/b/software/guix/src/gnu/packages/linguistics.scm:52:6: error: invalid field specifier
<davexunit>but something like that would be useful sometimes
<davexunit>although ultimately I think that upstream software needs to be fixed
<davexunit>so that their build systems don't assume things
<davexunit>guile, guix, software that I write, etc. works everywhere because it doesn't make assumptions about where binaries are and stuff like that
<ng0>hm.. well for another software I ran into the blocker that I need rust. which is why I started using NixOS, to start packaging this software there, and to be able to build it, what I currently have stopped in guix.
<davexunit>well that's just because we don't have a rust package.
<ng0>so the way to make sure stuff builds is to fix assumptions about locations
<dvc_>I think the problem was that bootstrapping from binaries is frowned upon
<ng0>well i took the first rust package... worked on it.. gave up, posted it, and then someone else started to work on it some more
<ng0>we need to do this for rust though, and the todo should be to fix this.
<dvc_>I'd like that too, but I've got other priorities at the moment...
<ng0>i try my user build now.. see if i can reproduce guixbuilder problems. but how do you deal with shebangs, davexunit? write them in a way that they are changed to local paths when configure is run?
<ng0>i think that's what automake, autoconf, libtool are there for when your system uses them.
<jmd>but packages in general cannot/shouldnot write to /var
<jmd>whereas using something like (string-append %outputs "out") "/var") would mean this directory would get written at run time.
<davexunit>divansantana: someone recently sent some patches regarding mdadm support. I don't remember if they made it into guix itself and if it works for your case. so, I guess just give it a whirl and see how it goes. :)
<jlicht>quigonjinn: I just have a git repo with dotfiles, and a (propagated-inputs) entry for stow :-)
<dvc>ah don't need an -s flag, read some confusing documentation...
<quigonjinn>jlicht: is there any example of propagated-inputs usage with stow, to achieve that functionality?
<jlicht>quigonjinn: Well, I just messed around a bit, and my current setup is not really usable for other people. I would recommend to just start using something simple (like stow + your very own dotfiles git repo).
<jmd>In the store, the mode of the the .so files for mit-krb5 is 444