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 :)
<roptat>hi guix!
<demotri>Hi
<user_oreloznog>Hello guix :) o/
<ng0>OrangeShark: with-directory-excursion* is also something you might consider
<ng0>but I think simply chdir before a phase will work better
<stefanX2ovic>Are any elogind developers here?
<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>s/git/github/
<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: Thank you for the sugesstion.
<ng0>shortcut to contact: https://prydeworx.com/about-me/
<stefanX2ovic>ng0: I am thinking of sending a patch to Yamakuzure (Sven), using his commit e-mail. Do you think that is apropriate>
<stefanX2ovic>?
<ng0>that's what I do most of the time when I can't find anything else
<stefanX2ovic>s/apropriate/appropriate/
<ng0>so, yes
<stefanX2ovic>ng0: Thank you, I will do that. I am not good at IRC, I will log out soon.
<ng0>no problemo :)
<ng0>if stefanX2ovic returns: https://github.com/elogind/elogind/issues/91
<Sleep_Walker>is anyone working on docker support? I can see docker as a package but not containerd
<jlicht>hey guix
<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
<Sleep_Walker>cool! this hurts me most when using GuixSD for work...
<ng0>work on this has been idle for a couple of months, but someone needs it for their work.
<Sleep_Walker>ng0: do you have some WIP patches available somewhere?
<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
<Sleep_Walker>I'm not sure which policy you have in mind...
<ng0>it is bundled alongside with a number of linux /kernel.org/ package definitions
<Sleep_Walker>ah, that :b
<Sleep_Walker>ng0: you should have your repo :)
<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.
<Sleep_Walker>interesting...
<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>nly: I use that for running some network scripts: https://lepiller.eu/ma-configuration.html (see iproute2-service-type)
<roptat>lsl88: can you share the error on paste.debian.net? maybe we can help
<nly>thanks
<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_>dependencies*
<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>(judging from my limited testing)
<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>guix gc -R /gnu/store... I think
<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
<lsl88>I added all the informatition I considered relevant: https://paste.debian.net/1050134/
<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
<lsl88>roptat: no, I added comments on top. It happened with a4, affy, and even with the one I was planning to package: BivarP. Here is the output of a4: https://paste.debian.net/1050143/
<lsl88>and with bivarp:
<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
<pkill9_>RUN IT AS A DAEMON?
<pkill9_>oops caps
<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_>yeah something like that
<pkill9_>maybe there's a better way to do that
<apteryx>"Nowaydays udev uses cgroups to seek-n-destroy spawned tasks" https://unix.stackexchange.com/a/243648/82353
<apteryx>I'll try using the 'at' command.
<maddo>hello
<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
<apteryx>apparently hosted here: http://blog.calhariz.com/tag/at
<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
<g_bor>hello guix!
<amz3>o/
<Laalf>is there an easy way of exporting THE STORE? meaning guix archive --export *?
<g_bor>lsl88: are you here?
<g_bor>sneek: botsnack!
<g_bor>sneek?
<g_bor>good night
<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