IRC channel logs
2018-11-02.log
back to list of logs
<OrangeShark>is there a way to tell a build system to use the build system files that aren't in the root directory? They are in a build directory. <lfam>OrangeShark: The solution will be specific to the build system and how it looks for the files in question <lfam>Can you give more details? <OrangeShark>so it uses the gnu-build-system and the files like configure.ac and Makefile.am are in a directory build/autotools <OrangeShark>found how, just need to modify a phase, like before or after one, and call chdir. There is a bunch of packages that do that <lfam>Glad you figured it out, OrangeShark :) <ng0>OrangeShark: with-directory-excursion* is also something you might consider <ng0>but I think simply chdir before a phase will work better <efraim>I know their code is hosted on github, I think elogind/elogind <stefanX2ovic>I ask because I do not have git account and I have simple bug to report. <stefanX2ovic>I am using GuixSD with the latest 239.1 version. I plan to send update patch to guix-patches when the next version is released, because I need recent version for wlroots (Alpha), sway (Beta), and mako. <ng0>stefanX2ovic: wingo used to do that, but upstream development has moved to github. <ng0>i don't know if "#guix on irc.freenode.org" is still appropriate <stefanX2ovic>ng0: I am aware of wingo's involvment. But I am wondering whether to make github account for this simle bug. <ng0>pick a high frequency contributor of the elogind repo and send them a patch or message? <ng0>or maybe whoever looks like the maintainer these days <ng0>since it is picked from systemd the "contributors" list in github might be misleading <ng0>(and the git log equivalent) <ng0>Yamakuzure looks like the maintainer or someone you could ask <stefanX2ovic>ng0: I am thinking of sending a patch to Yamakuzure (Sven), using his commit e-mail. Do you think that is apropriate> <ng0>that's what I do most of the time when I can't find anything else <stefanX2ovic>ng0: Thank you, I will do that. I am not good at IRC, I will log out soon. <Sleep_Walker>is anyone working on docker support? I can see docker as a package but not containerd <jlicht>it seems the bayfront.guixsd.org LE cert is out of date <ng0>Sleep_Walker: more or less. need to get some things wrapped up, then I can send all of Docker <ng0>work on this has been idle for a couple of months, but someone needs it for their work. <ng0>no place I can link to here according to policies I'm afraid <ng0>it is not fully unctional yet, this is what I meant with polishing. so no use in linking <ng0>it is bundled alongside with a number of linux /kernel.org/ package definitions <ng0>i just realized I did not publicly expose this, it is "ssh-pubkey only" <ng0>well I have a couple hundred repos over the time I experimented with extending Guix ^^ <Sleep_Walker>oh, I always ended with 2 - one for config, one for external packages <ng0>my work goes beyond packages. right now I'm doing another evaluation of my ideas to see wether I should still use guix as the underlying origin. <ng0>I'll writie about it nmore in detail one day <lsl88>hi! does the problem with hydra also affects guix import? <roptat>lsl88: it shouldn't, but it will affect your attempt at building what you import (guix might have to build more things locally) <lsl88>roptat: thank you, it works for R packages, but when I try to import a template from bioconductor I get errors, it happened to me in the past, but I don't know why this is happening now <nly>Hi has anyone made a shepherd service to start a script? Can i have a look? :-) <roptat>lsl88: can you share the error on paste.debian.net? maybe we can help <apteryx>is there a way currently to duplicate my current guix version to another machine? <apteryx>I tried guix copy, but you still have to guix pull thereafter and I'm not convinced of the gain. <roptat>apteryx: you need to find you current guix version and send it to your other computer with guix copy <roptat>then you run guix pull, but it doesn't have to build anything since you already sent everything <roptat>(run guix pull --commit=... to get the exact same commit as your first computer) <apteryx>roptat: I did guix copy --to=my-other-machine realpath ~/.config/guix/current, and it did copy a bunch of things, then I ran guix pull --commit with that commit but wasn't sure if it made a big difference. I should time it! <apteryx>roptat: err, guix copy --to=my-other-machine $(realpath ~/.config/guix/current) <pkill9_>does guix copy copy the store paths depencies as well? <pkill9_>if it doesn't you could try using `guix archive --export --recursive` and import it to the other machine <pkill9_>actually that takes a ppackage not a store path i think <apteryx>pkill9_: guix copy also takes a package rather than store paths, but there seems to be an exception for profiles <apteryx>I found the profile trick documented in our manual <pkill9_>there is a way to get a list of dependencies of a store path though, can't remember exactly, it's either using `guix graph` or `guix gc` <apteryx>it would be helpful it guix archive / copy would also work for any /gnu/store item. <lsl88>roptcat: sure, when I first had the issue, it was because of not adding the -a bioconductor. But now I add everything and the output is similar <lsl88>roptat: sure, when I first had the issue, it was because of not adding the -a bioconductor. But now I add everything and the output is similar. Sorry for the typo <roptat>lsl88: I think you found a bug :) <lsl88> I just wanted to make another contribution :( I was going to practice another R package but more difficult this time, and then read about texinfo to learn it, and also contribute with that. <lsl88>roptat: do I need to report it somewhere? <lsl88>roptat: and I do not understand very well which the bug is, could you explain it? :) <roptat>lsl88: the first issue is that guix doesn't find the correct tarball <roptat>then I think it tries to use that file, and that's the stacktrace you see <roptat>is the issue only with that package? <roptat>I wonder why it tries to build version 1.58.0 when the latest is 1.60.0 <roptat>it seems they don't retain old tarballs <roptat>I'm not familiar with R or bioconductor, but I'm pretty sure the importer should try to download the latest release, which it doesn't do <apteryx>how would someone launch a script triggered by a udev rule? I know the basics, but the udev manpage explicitly discourages running long lasting processes. <apteryx>(as it says they might be killed and also block any other event from triggering) <lsl88>roptat sorry, BivarP doesn't belong to bioconductor, and the error I was getting was because I didn't know that it was case sensitive <apteryx>pkill9_: do you mean like in /my/script.sh &> /dev/null & disown (or nohup /my/script.sh) ? <apteryx>because I've already tried this but apparently it's no warranty that the child process won't be killed (it happened). <pkill9_>maybe there's a better way to do that <maddo>is there a status for guixsd port to openpower? <apteryx>pkill9_: 'at' doesn't seem to exist in guix :( <apteryx>or I don't know which package provides it <lsl88>roptat: I had a similar problem before, but it is weird, I tried with the commands that demotri mentioned by that time and I don't know why it is still not getting the latest version. Maybe I should ask about that. When I wrote in guix-devel, it worked for me then <Laalf>is there an easy way of exporting THE STORE? meaning guix archive --export *? <amz3>Ah! did anybody write a parser for gnu commit messages? <amz3>forget it, sorry! just another useless idea. <amz3>maybe I should go back to my gnunet work