<yenda>so it looks like building go is as simple as running a bash script, which bootstraps go from c then build <yenda>should I use trivial-build-system ? the problem is that I'm not sure how because the few packages using it don't do much <Steap>Sorry guys, the messages from Guix-Bot might have been delivered twice :) <Steap>yep, for some reason I don't get these messages <davexunit>sneek: later tell yenda you should still use the gnu-build-system for go because it has several phases that do important tasks your trivial build system would overlook. <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? <davexunit>next_step: we don't currently offer pre-built binaries because we have no ARM machines for our build farm. :( <mark_weaver>next_step: we just need powerful ARM boards for our build farm. boards with at least 4 GB of RAM, a SATA disk, a reasonably fast processor, and capable of running with a 100% free OS. <mark_weaver>but I'm not willing to donate my Novena to the build farm. <mark_weaver>(I intend to make it my primary machine at some point) <mark_weaver>if we could raise about $1300 for this purpose, that would be enough to buy 2 Novena boards with SATA hard drives, and we'd be able to provide armhf binaries. ***chipb_ is now known as chipb
<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? <davexunit>though this particular article is for installing guix on top of a non-guixsd host system <cestdiego>So what about GuixSD, are you guys using guixsd_ <davexunit>a guix planet feed might be good to have in the future, to aggregate our independent blog posts. <mark_weaver>I've been using GuixSD on my primary laptop for the last year or so. <davexunit>but using the package manager for well over a year. <davexunit>ACTION opens emacs in a guixsd container and everything seems to work <mark_weaver>yes, I'm a happy camper. the system works very well for me. <davexunit>same. it's just a matter of packaging more things to keep me happy. <mark_weaver>I miss GNOME 3, and look forward to packaging more of GNOME for GuixSD, but XFCE is working well enough for me at the moment. <cestdiego>nowadays I kinda can't work without i3 ;_; I spent too much time configuring it to just drop it. <mark_weaver>cestdiego: fwiw, my approach was to run Guix within another system (in my case, Debian), until I packaged what I needed most, and then I switched to GuixSD. <davexunit>you needn't jump right right into GuixSD. you can use Guix the package manager on your current host distro. <OrangeShark>That is what I am currently doing until I learn more about Guix :) <cestdiego>oh...I was just reading the prev blog post for HPC <OrangeShark>I need to find some time to learn how to make packages as well as learn more scheme <cestdiego>so davexunit you are an emacs user right? what packages do you use for guix dev? <davexunit>cestdiego: geiser and paredit, the tools of choice for guile hacking. <cestdiego>also do you use your GuixSD computer as your main work computer? <davexunit>my company gave me an ubuntu workstation which I run guix on top of. <davexunit>too much ruby code to be able to use just guix right now. <davexunit>guix only has about ~2000 packages, so you're sure to find things you like that are missing. <cestdiego>doesn't matter if they are propietary though? like dropbox. <mark_weaver>cestdiego: as we said before, we are committed to only including free software in Guix. <davexunit>you're free to package whatever you'd like for your own usage, but we only accept free software upstream. <mark_weaver>however, we provide easy means to add your own private packages. <cehteh>do you really need dropbox? ... otherwise take a look at git-annex <cestdiego>ppl share stuff in dropbox and I have to process them and then modify them..they get the thing instantly.. <davexunit>free alternatives include owncloud and seafile <cehteh>what company shares its data over dropbox .. makes me lol <davexunit>our manual has the information about including your own private packages <cehteh>me think sooner or later someone will provide a non-free guix repo <cestdiego>ppl that really want it can gather in their own repo <mark_weaver>if you want non-free software, better just use NixOS <davexunit>I anticipate this happening, but we will not advertise it here or otherwise recommend its usage. <cestdiego>the finger licking greatness of scheme + emacs. to develop packages for your os is the dream <mark_weaver>we can't support third-party repos, for multiple reasons, but the main technical reason is that we can't provide a stable API. <mark_weaver>it's the same reason that Linux keeps its drivers internal to its monolithic kernel. <cestdiego>that makes kinda sense. I'm not saying it will be supported but that it may happen spontaneously.. <mark_weaver>Linux (the kernel) is constantly evolving their internal APIs, and often those require updates to the drivers themselves. <mark_weaver>if they tried to provide a stable API for maintaining out-of-tree drivers, it would be a disaster of backward compatibility hacks, etc. <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. <cestdiego>I'm gonna see how things go and hopefully even contribute to guix :D <cestdiego>so I guess you don't have chrome, but chromium right? <mark_weaver>we don't have chromium yet, but it could be added, provided that it was modified to conform to the GNU FSDG. <mark_weaver>I haven't looked in detail at chromium, but some free web browsers recommend or direct people to install non-free software, e.g. video codecs or flash. <mark_weaver>media companies generally only provide their video to computers that are not under control of their users, because that would allow users to make copies of the video. <mark_weaver>whereas we are dedicated to making sure that users have control over their computers <mark_weaver>you might be able to get Chrome working on Guix, but it's not something we can condone or support. <mark_weaver>netflix demands DRM, whereas the GNU FSDG requires that "The distro must contain no DRM, no back doors, and no spyware." <cestdiego>I feel it's right but sigh :( so frustrating there is no way media can be *free* <mark_weaver>the situation is not hopeless. if sufficient numbers of users demand no DRM, then we could have DRM-free media. <cestdiego>I'm downloading guixsd now to try it on a vm :) <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. <cestdiego>I support it, I wish I could do it in a more relevant way though :( <mark_weaver>rejecting DRM and encouraging your friends to do the same would be very relevant and helpful. <mark_weaver>rejecting it means refusing to use it, not merely speaking against it while paying for it. if we pay for it, we're lost. <mark_weaver>but if watching videos is more important to us than our freedom, we will lose our freedom. <adhoc>theres nothing on television worth watching anyway, so its no great loss <mark_weaver>another way to use netflix is to have them mail you physical DVDs, and those can be ripped. <rekado->the problem with lilypond (error when asking ghostscript to convert ps->pdf) is likely fixed with an update to fontconfig 2.11.94 (from 2.11.92). <rekado->haven't tested this yet, but I tried everything else: different fonts, different version/distribution of ghostscript, etc. <mark_weaver>rekado-: unfortunately, updating fontconfig will entail on the order of 1400 rebuilds, at least. <mark_weaver>we'll have to wait on that until after 'expat-update' is merged. <rekado_>yes, I noticed that it's hard to test because of massive amounts of rebuilds. <mark_weaver>but first you should determine if it actually fixes the problem <rekado_>there's a bug report for the same problem at the redhat/fedora bug tracker. <mark_weaver>did they report that updating fontconfig fixed the problem on fedora? <rekado_>for them the situation was the same: same error, not fixed by different (previous or later) versions of ghostscript or pango, fixed with fontconfig 2.11.94 <rekado_>as I explored different versions of ghostscript I found that there's GNU Ghostscript (9.14) and the official AGPL Ghostscript (9.16). Do you happen to know why there is a GNU version? <rekado_>looking at the different directories I could only tell that AGPL Ghostscript bundles more third-party libs. <rekado_>but this doesn't seem enough to warrant a fork. <mark_weaver>jgay: do you know off-hand why GNU Ghostscript exists alongside the AGPL-licensed version? <davexunit>ACTION struggles with setting up a psuedo-terminal for container processes <cirno[9]>I made a slight mistake in my patch & the bot pointed it out <cirno[9]>"sentences in description should be followed by two spaces" <cirno[9]>what should I do? Make the patches again with that fixed and post again? <davexunit>cirno[9]: yes, after fixing the issues, reply to the email with a new patch. <cirno[9]>it' spretty nice, I did try guix lint but my version might not have had that rule implemented <cirno[9]>it did seem to post both its messages twice though <davexunit>Steap is playing around with automated baseline patch review, and you were the first test subject. :) <Steap>cirno[9]: yeah, for some reason, I did not receive these messages myself, so I thought the bot had failed <Steap>davexunit: yeah I'd like to have some sort of a "CI" that would be mail based <Steap>funnily enough, I cannot find anything that does that <davexunit>Steap: I think having a bot that points out common, machine identifiable problems is a great idea. <Steap>davexunit: yeah, I'd like to do "make" and "guix lint" at least <Steap>davexunit: when I send patches to OpenStack, a bot tells me "well, these are the issues in your patch that could be identified by a machine" <Steap>that saves a lot of time for reviewers, so they can work on stuff that matters <Steap>but that uses gerrit for instance <Steap>I found a project called "patchwork" that generates a nice list of currently reviewed patches on a Web page <Steap>that seems nice, but it does not have CI-capabilities built-in <Steap>I'd rather extend something that already exists <Steap>also the bot is currently written in... hahem... Python. <cirno[9]>i find it crashes a lot when you drag files into folders <rekado_>cirno[9]: I use XFCE but not Thunar. I use dired in Emacs. <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. <Steap>but I see the emails I send through Thunderbird <Steap>maybe I asked Thunderbird to keep a copy <Steap>maybe I could just use a fake adress for the bot <mark_weaver>Steap: guix-devel won't accept mails from unsubscribed email addresses automatically. those go through moderator queue. <Steap>yeah but then I'm gonna get all the messages I post twice <mark_weaver>I configure my mail clients to BCC myself on all outgoing mails. <Steap>this bot is really beta-quality. <Steap>would be best to have something less Guix-specific <mark_weaver>although I presume that the bit about putting human reviewers out of a job is a joke :) <Steap>still, making sure nobody has to do what can be automated is a good idea <Steap>just have to make sure people still get money anyway <davexunit>yeah, I like the idea of an automated linter bot <Steap>it's gonna be quite a pain though <Steap>having to manage complete threads <davexunit>paroneayea: the patch that I'm no longer confident we should apply? ;) <alezost>ACTION thinks the same as a year ago <amz3>yes the same as a year ago <amz3>it requires configuration <amz3>s/configuration/programming <amz3>the above image is mockup i did on inkscape <amz3>the thing i couldn't get answer about is how to program guile-wm <amz3>guile-wm creator told me he *only* connect emacs geiser repl like with sly <amz3>and do what hacker do best <amz3>I am big fan of tiling window manager, so eventually I will use it <amz3>right now i need, to focus and for some reason I switched to debian, even if I did not find good reason to do so <paroneayea>yes I am on debian + gnome with guix as an additional package manager for now <paroneayea>though I do look forward to the day I can go full guix :) <amz3>tbh I miss playing games sometimes <amz3>I know if I don't use guixsd I won't make recipes or unlikely <amz3>It goes back and forth in my mind, and I can't focus on my stuff <amz3>s/on my stuff/on hacking <amz3>a lot of tools I look at are still unstable or not released so that doesn't help <sneek>yenda, davexunit says: you should still use the gnu-build-system for go because it has several phases that do important tasks your trivial build system would overlook. <davexunit>ACTION wonders if Iridium would be useful to package <davexunit>just got added to the free software directory <mark_weaver>yenda: yes, gnu-build-system is best to use in almost all cases, even if you end up removing or replacing many of its phases. <mark_weaver>trivial-build-system is primarily for cases where there's no compilation at all, e.g. for font packages where the fonts are already built and need only be copied. <mark_weaver>davexunit: Iridiumbrowser definitely looks interesting!! <davexunit>mark_weaver: I wonder if the undo any of the bundling that chromium does. <mark_weaver>we might need to make a few more modifications to it to comply with the FSDG, but it sounds like the changes they make are ones we'd want. <davexunit>seems like it would be too hard to maintain, but I have no idea. <mark_weaver>we can deal with bundled libraries incrementally, removing them over time <davexunit>in this case, you probably want to replace the 'build' phase with one that chdirs to the right place and runs 'make.bash' <mark_weaver>and because the shebang probably refers to something like /bin/bash that doesn't exist, you might need to do something like (zero? (system* "bash" "make.bash")) <mark_weaver>oh, nevermind, the patch-shebangs phase will have already taken care of that <yenda>mark_weaver: the line you suggest is actually what I have <yenda>I guess I should delete the check phase too : make: *** No rule to make target 'check'. Stop. <davexunit>there's just no makefile, so 'make check' does nothing <mark_weaver>sometimes it has a different target name than "check" <mark_weaver>some projects want "make test" or to run make within another directory or something. <yenda>there is a run.bash that mentions some testing <davexunit>yenda: if you figure out how to run it, you'll want to replace the 'check' phase with a new phase that does the right thing. <yenda>I just used (zero? (system* 'bash' 'run.bash')) to run it <yenda>but it can't find the go command though <yenda>so I'm grepping for exemple of rewrites for 'check <davexunit>yenda: did the build phase complete successfully? <davexunit>you can disable tests for now and see if go actually works <yenda>Installed Go for linux/amd64 in /tmp/nix-build-go-1.4.2.drv-0/source <yenda>Installed commands in /tmp/nix-build-go-1.4.2.drv-0/source/bin <yenda>phase `build' succeeded after 26 seconds <codemac>yenda: I've been working on go as well <yenda>codemac: how did it go ? I need it to package docker <codemac>go can't seem to get rpathing correct for libgcc_s <yenda>codemac: can you share you package declaration ? <codemac>I have to run to a meeting here at work, but yenda, my email is j@codemac.net <mark_weaver>yenda: you need double-quotes, not single quotes there. "bash" "run.bash", not 'bash' 'run.bash' <yenda>I know it's just when writing <davexunit>it's a small thing, but I am so glad that guile doesn't allow string literals to use single quote *or* double quotes interchangeably <yenda>could you explain me what this does : (lambda* (#:key inputs outputs (make-flags '()) #:allow-other-keys) ? <mark_weaver>yenda: that creates a procedure that takes keyword arguments <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>the problem with go seems to be that the make.bash script does both the build and install phase ***cjbarnes` is now known as CJBarnes
<yenda>so build succeeds then install fails because there is nothing to install <mark_weaver>yenda: that's okay, you can just (delete 'install) to remove the install phase. <yenda>I found lots of alist-delete and chained alist-replace in other packages <mark_weaver>oh yes, that was the old way of doing things, and I guess most packages still do it that way <mark_weaver>we've been incrementally switching packages to use 'modify-phases', but it's not important. <davexunit>modify-phases is special syntax that expands into the nested alist transformations <yenda>anyway I deleted install to before but then it fails <davexunit>well, you'll need to replace the install phase with something that actually does the installation, right? <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 <amz3>(that nothing was installed in the output directory) <mark_weaver>otherwise, you need to do it in some other way. for projects with makefiles, sometimes it can be done by including PREFIX=<output> in the make-flags. <davexunit>amz3: because the output directory wasn't created <mark_weaver>amz3: because of the error message "failed to produce output path" <mark_weaver>the name output directory can be obtained with (assoc-ref outputs "out") within a phase procedure if it accepts the 'outputs' keyword argument. ***cjbarnes` is now known as cjbarnes18`
<mark_weaver>(in general, there can be more than one output, hence the lookup) <mark_weaver>somehow, that directory needs to be created, and probably have things like /bin and /lib subdirectories. <mark_weaver>the thing is, usually if you fail to tell it where to install, it will try to install somewhere in /usr and fail. <cjbarnes18`>good evening folks, having troubles installing guixos in a vm, am attempting to install using USB media. fails downloading ../bootstrap/../guile-2.0.9.tar.xz <amz3>the fact that phase procedure are are not lambda is strange. out is an argument but it doesn't appear. <davexunit>but we use the special lambda* syntax which has additional affordances for keyword arguments. <yenda>mark_weaver: ok i took notes I'll have another look later on <mark_weaver>cjbarnes18`: you're running the USB installer within a VM? does it have network access? <amz3>davexunit: lambda* does not appear in the package definition <mark_weaver>and what is 'out' an argument to? I'm very confused. <mark_weaver>cjbarnes18`: it's trying to download from alpha.gnu.org and failing? <amz3>my bad, lambda* appears in the package definition for instance in xorg.scm:imake. <mark_weaver>cjbarnes18`: you need to somehow set up the networking before running the commands to install <mark_weaver>have you verified that the network is set up properly within the USB installer? has it successfully talked to any outside host? <cjbarnes18`>ahh, this time I missed a step... network address. have been trying all day with various errors however. <cjbarnes18`>I managed to get enlightenment working eventually, thanks for your help yesterday. <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. <codemac>I'm testing a fix for my go package - it depends on a patched patchelf, I'll ping you when it's built <yenda>have you encountered the missing libgcc_s.so.1 library ? <codemac>yenda: that's exactly what I'm fixing <codemac>yenda: my package is also done very differently, but uploading now <yenda>I was hoping it would come with gccgo but it's not <codemac>I fix a few bugs with the tests and I don't use the %standard-phases <codemac>You'll notice it depends on "patchelf-0.8.git" due to the fact that the go binary is a bit non-standard <codemac>I'm building this new patchelf plus that package to see that things work <yenda>well I'm not that knowledgable yet <codemac>don't worry, me neither yenda . I've been hacking at this for a week-ish with a huge machete of parens. I use go all day at work, so I know about go, I just don't know much about guix yet <amz3>how do you build go, since it's self hosted? <yenda>amz3: there is a C bootstrap <codemac>amz3: this is go 1.4.2, it is not self hosted yet, that's go1.5 <amz3>which means it compiles a subset of the gocompiler written in c? <amz3>I'm curious, what got you interested in guix? <codemac>oh - I adored everything about nix, but I hated the nix recipe language stuff. Coming from PKGBUILDs in arch, they were just over the top. <codemac>I miss systemd, but I'm packaging that for myself <amz3>myself, I got interested because of 0) functional package manager (via nixos) 1) GNU 2) Guile <yenda>amz3: me because it's the emacs of distros and I wanted to make emacs my OS <yenda>and because a functional package manager seemed like a neat idea but I dislike nixOS DSL <amz3>yes, the emacs of distribution is a good argument when you know emacs but I prefer to say that it use guile; a true language <codemac>I'd also love to know guix well enough to help with a `guix ops` kind of thing. I saw on the mailing list there's interest, but I assume there's lots of work to do <yenda>I also hope it will help speed up guile-emacs development <amz3>I'd like to have something similar to gentoo useflags. <codemac>nix does that with "channels".. i'm not sure what the guix thoughts are on that <amz3>well, this is long term wish, right now I'm mostly trying to help with guile itself, even if I have a patch for guix in the pipe <amz3>my patch draws graphviz graph of dependencies of a package <codemac>In procedure lower: Error while printing exception <codemac>Hmmmmmmmm somehow upgrade-string isn't working well 
