<next_step>Hello, are there any plans for pre-built binaries for ARM? I think this is interesting because a large share of close-to-free hardware is running and will run on ARM (Asus C201, Pyra just to name 2). However, these tend to be low power devices, so I imagine they will struggle to self-compile all stuff. Perhaps cross-compiling?
<cestdiego>I'm torn between guix and nix for package managing :( my main objective is scientific software. Anyone that can give me their insights on scientific packaging? AFAIK guix and nix are not that different. But I'd rather stay with scheme than to learn another lang. Also Emacs by my side would be a strong tool for guix
<davexunit>cestdiego: we have a growing number of scientific packages, thanks to several contributors that work in the bioinformatics industry.
<cestdiego>davexunit: interesting. I'm more into physics though D: how are guix packages regarding non free software? Would I always be sure my system is gonna be Free Open SOftware if I decide to go with GuixSD?
<mark_weaver>GuixSD is committed to including only free software, yes.
<cestdiego>how easy would you guys say that is to package stuff in GuixSD? :) btw so GuixSD is more server oriented? or is gonna have desktop audience too? if so, how are the nvidia drivers gonna work? D: Are the noveau gonna be the default without option to have the propietary ones?
<davexunit>cestdiego: Guix is oriented towards all classes of computers. it works well on servers and desktops.
<davexunit>the nouveau drivers "just work" on my old desktop with an nvidia gtx275 gpu
<mark_weaver>and we also, of course, support intel graphics out of the box as well.
<cestdiego>I have optimus card :( asus n56v and I've had TONS of trouble in other distros :(
<mark_weaver>I find that it is very easy to package most things in guix. it really depends on the build system, and how well it copes with things in non-standard places.
<mark_weaver>it is not uncommon for me to write and debug simple packages in less than 20 minutes.
<cestdiego>also I kinda started on nixos some weeks ago because I haven't heard of GuixSD but now that I see it is copliant with GNU FSDG then I'd like to give it a try. Where are the best guides on getting started? :O
<mark_weaver>but there are occasional packages that are quite a bit more difficult. it varies a lot.
<cestdiego>There were some `Nix` pills in nixos... are there any recommended blog posts that can complement the manual?
<mark_weaver>for the foreseeable future, Guix needs to be monolithic with both the full set of package recipes and support code all together in one git repo.
<mark_weaver>we support GUIX_PACKAGE_PATH for users to easily make their own recipes, but occasionally you will need to fix things up to adapt when we make changes.
<mark_weaver>and even more flexible: you can run guix directly out of your own private git branch, containing arbitrary changes to guix, and periodically rebase your branch on our upstream. that's what I do.
<mark_weaver>(or, if you prefer, merge our upstream into your private branch)
<mark_weaver>but we cannot reasonably support third-party package repos, and it would be bad for many reasons.
<mark_weaver>cestdiego: to give a concrete example of how the situation is not hopeless, recall that even Apple dropped DRM from its iTunes music catalog in 2009.
<mark_weaver>if we don't want a future where our computers are under the control of corporations, with all the disastrous consequences that would have, then we need to build a movement to strongly reject DRM.
<mark_weaver>we cannot merely go along with it, for convenience sake.
<mark_weaver>Steap: I guess the reason you didn't see the message your bot posted is because, by default, the mailing list does not send your own posts back to you, and your bot's emails come from your email address. iirc, subscribers can change that setting in mailman.
<mark_weaver>the arguments include #:inputs, #outputs, #make-flags, and other keyword arguments will be accepted but ignored without complaint.
<mark_weaver>phase procedures receive all of the arguments in the 'arguments' list plus some more that are added by the build system.
<mark_weaver>I've used that kind of procedure signature when replacing a phase that runs 'make', so that it can see the value of the #:make-flags argument, if any, and pass them along to 'make', just like the default 'build', 'check', and 'install' phases do in gnu-build-system.
<mark_weaver>the (make-flags '()) means that '() will be the default value in case 'make-flags' was not included in the argument list at all.
<mark_weaver>if no default is explicitly given, then #f is the default.
<mark_weaver>does that make sense? it may be that I need to explain more about scheme procedures and 'lambda'.
<yenda>builder for `/gnu/store/8vl43j0jrzajgzfhqn565di020y8sbhr-go-1.4.2.drv' failed to produce output path `/gnu/store/p97kd9z21j5mjgl7i5ml6a9r6c3nyaxn-go-1.4.2'
<yenda>@ build-failed /gnu/store/8vl43j0jrzajgzfhqn565di020y8sbhr-go-1.4.2.drv - 1 builder for `/gnu/store/8vl43j0jrzajgzfhqn565di020y8sbhr-go-1.4.2.drv' failed to produce output path `/gnu/store/p97kd9z21j5mjgl7i5ml6a9r6c3nyaxn-go-1.4.2'
<yenda>guix build: error: build failed: build of `/gnu/store/8vl43j0jrzajgzfhqn565di020y8sbhr-go-1.4.2.drv' failed
<mark_weaver>okay, so the problem is that nothing was installed in the output directory
<mark_weaver>for projects that have a 'configure' script, that's taken care of because gnu-build-system passes --prefix=<output> to configure
<cjbarnes18`>using guix-all-available-packages in emacs, is it possible to determine which of the packages are included in os?
<next_step>mark_weaver: thanks. Yeah, powerful ARM hardware is quite expensive and not so common. ARM would be an awesome addition to Guix. For example Pyra will be an ARM device, and IMHO the ultimate free phone/minitablet. Would be fantastic to run Guix there.