Re: Guix infrastructure
On July 7, 2017 6:00:42 AM GMT+03:00, Leo Famulari wrote: >On Thu, Jul 06, 2017 at 08:09:17PM -0400, myglc2 wrote: >> On 07/01/2017 at 14:01 Leo Famulari writes: >> > ... Bayfront is still not fully operational, so hydra.gnu.org is >still >> > serving as the front-end of the build farm. We are still relying on >the >> > Hydra software. That is, the situation is basically the same as >before. >> > Adding build machines will not help very much until the front-end >> > hardware gets faster. >> >> This leaves me wondering ... >> >> Is the hydra/front-end hardware going to be upgraded? > >Yes... > >> Is bayfront/cuirass intended to replace hydra? > >... and yes. > >> The bayfront hardware described here ... >> >> https://www.gnu.org/software/guix/news/growing-our-build-farm.html >> >> ... seems weak to me. Is there a plan to scale it up and make it >redundant? > >It will be a lot more powerful than the current Hydra system. As for >specific plans, I'll let those administering the system chime in. > >> A reliable, resourced, managed, "nightly Guix build" should pay big >> dividends for the project. But, from reading the lists, I get the >> impression that such a thing does not exist. Is that correct? > >Currently, we tend to build all the packages as often as we can with >our >resources, which is less than once a day. > >> Do we know what would be needed to achieve a complete nightly build? > >It depends on what you mean by "complete". > >I doubt we can find armhf hardware that could build all the packages >daily. That platform doesn't get very powerful in general and, in my >experience, the machines that do exist can't handle sustained high >loads, nor do they have fast network and I/O interfaces. > >It is possible for x86_64, i686, and eventually for aarch64. Maybe we >will be able to cross-build from aarch64 to arhmf; I'm not sure. >Efraim? In theory it should be possible to build and run armhf packages on aarch64, in practice its not always the case. http://sjoerd.luon.net/posts/2017/07/debian-armhf-vm-on-arm64/ says: On the 64 bit ARM side, we're running on Gigabyte MP30-AR1 based servers which can run 32 bit arm code (As opposed to e.g. ThunderX based servers which can only run 64 bit code). As such running armhf VMs on them to act as build slaves seems a good choice, but setting that up is a bit more involved than it might appear. > >Ricardo has been working on getting some new x86_64 / i686 builders >online: > >https://gnunet.org/bot/log/guix/2017-06-30#T1433202 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
New build-system quest (premake4 t-engine)
Hi,
I try to package premake4 build-system and t-engine game. I have an
issue with "No such file or directory" "../bla/bla/bla/*.h".
(info "(guix) Debugging Build Failures")
./pre-inst-env guix environment -C t-engine
source ./environment-variables
cd t-engine*
make
succeeded.
But building with guix build failed. Checkout patch and logs. Any
ideas appreciating :-)
>From 2529572312b40cd3920fcc845619fa77d9a6d874 Mon Sep 17 00:00:00 2001
From: Oleg Pykhalov
Date: Sat, 8 Jul 2017 18:29:36 +0300
Subject: [PATCH] gnu: New build-system quest.
* guix/build/premake4-build-system.scm: New file.
* guix/build-system/premake4.scm: New file.
* Makefile.am (MODULES): Add them.
* gnu/packages/build-tools.scm (premake4): New variable.
*
* gnu/packages/games.scm (t-engine): New variable.
---
Makefile.am| 2 +
gnu/packages/build-tools.scm | 35 ++
gnu/packages/games.scm | 42 +++
gnu/packages/patches/t-engine-fix-sdl-h-path.patch | 39 ++
guix/build-system/premake4.scm | 135 +
guix/build/premake4-build-system.scm | 59 +
6 files changed, 312 insertions(+)
create mode 100644 gnu/packages/patches/t-engine-fix-sdl-h-path.patch
create mode 100644 guix/build-system/premake4.scm
create mode 100644 guix/build/premake4-build-system.scm
diff --git a/Makefile.am b/Makefile.am
index 4d1512f8c..1aac383fd 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -83,6 +83,7 @@ MODULES = \
guix/build-system/gnu.scm \
guix/build-system/haskell.scm \
guix/build-system/perl.scm \
+ guix/build-system/premake4.scm \
guix/build-system/python.scm \
guix/build-system/ocaml.scm \
guix/build-system/waf.scm \
@@ -112,6 +113,7 @@ MODULES = \
guix/build/gnu-build-system.scm \
guix/build/gnu-dist.scm \
guix/build/perl-build-system.scm \
+ guix/build/premake4-build-system.scm \
guix/build/python-build-system.scm \
guix/build/ocaml-build-system.scm \
guix/build/r-build-system.scm \
diff --git a/gnu/packages/build-tools.scm b/gnu/packages/build-tools.scm
index 66f46433f..78da66818 100644
--- a/gnu/packages/build-tools.scm
+++ b/gnu/packages/build-tools.scm
@@ -23,6 +23,7 @@
#:use-module (guix packages)
#:use-module (guix download)
#:use-module (gnu packages)
+ #:use-module (gnu packages compression)
#:use-module (gnu packages python)
#:use-module (gnu packages ninja)
#:use-module (guix build-system gnu)
@@ -90,3 +91,37 @@ Autoconf/Automake/make combo. Build specifications, also known as @dfn{Meson
files}, are written in a custom domain-specific language (DSL) that resembles
Python.")
(license license:asl2.0)))
+
+(define-public premake4
+ (package
+(name "premake4")
+(version "4.3")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "http://downloads.sourceforge.net/project/premake/Premake/";
+ version "/premake-" version "-src.zip"))
+ (sha256
+ (base32
+ "1017rd0wsjfyq2jvpjjhpszaa7kmig6q1nimw76qx3cjz2868lrn"
+(build-system gnu-build-system)
+(native-inputs
+ `(("unzip" ,unzip))) ; for unpacking the source
+(arguments
+ `(#:make-flags '("CC=gcc")
+ #:tests? #f ; No test suite
+ #:phases
+ (modify-phases %standard-phases
+ (delete 'configure)
+ (add-after 'unpack 'enter-source
+ (lambda _ (chdir "build/gmake.unix") #t))
+ (replace 'install
+ (lambda* (#:key outputs #:allow-other-keys)
+ (install-file "../../bin/release/premake4"
+ (string-append (assoc-ref outputs "out")
+ "/bin"))
+ #t)
+(synopsis "A makefile generation tool")
+(description "@code{premake4} is a command line utility which reads a
+scripted definition of a software project.")
+(home-page "https://premake.github.io";)
+(license license:bsd-3)))
diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
index a7f697ece..b24766bc9 100644
--- a/gnu/packages/games.scm
+++ b/gnu/packages/games.scm
@@ -133,6 +133,7 @@
#:use-module (gnu packages networking)
#:use-module (guix build-system gnu)
#:use-module (guix build-system haskell)
+ #:use-module (guix build-system premake4)
#:use-module (guix build-system python)
#:use-module (guix build-system cmake)
#:use-module (guix build-system trivial))
@@ -4577,3 +4578,44 @@ computer-hosted roleplaying games. This is the last version released by
Crowther & Woods, its original authors, in 1995. It has been known as
\"adventure 2.5\" and \"430-point adventure\".")
(license license:bsd-2
+
+(define-public t-engine
+ (package
+(name "t-engine")
+(version "1.5.5")
+(source
+ (origin
+ (method url-fetch)
+ (uri (string-append "https://te4.org/dl/t-engine/t-engine4-src-";
+
Re: Inkscape libpoppler error
Kei Kebreau writes: > Kei Kebreau writes: > >> Daniel Pimentel writes: >> >>> Hi guixs, >>> >>> today I updated my GuixSD but my Inkscape not start :( >>> >>> I installed poppler and I reinstaled inkscape too. In my >>> ~/.guix-profile there isn't libpoppler.so.66 but in my system there: >>> /gnu/store/mpq4v7hgg02gl0bkjjq8612rm3sira5s-poppler-0.52.0/lib/libpoppler.so.66 >>> /gnu/store/c31lmp5smk9snfyb8rf7mmzrdv15aps8-poppler-0.52.0/lib/libpoppler.so.66 >>> /gnu/store/8c0bj7imclym7rmf1pa3cgf2xg1qbv25-poppler-0.52.0/lib/libpoppler.so.66 >>> >>> Error output: >>> inkscape: error while loading shared libraries: libpoppler.so.66: >>> cannot open shared object file: No such file or directory >> >> Hi Daniel, >> >> I just checked the inkscape package on my computer and I got the same >> error. I'm looking into the problem now. Sorry for the inconvenience. > > I've found the source of the issue and I'm seeing about fixing it. In > the meantime, you can reinstall inkscape using the following command: > > guix package -i inkscape --no-grafts For the details about what's going on here, see: https://bugs.gnu.org/27621 Please email further comments about this issue to: 27...@debbugs.gnu.org Thanks! Mark
Re: Guix infrastructure
On 07/07/2017 at 14:19 Ludovic Courtès writes: > Hello Guix! > > Leo Famulari skribis: > >> On Thu, Jul 06, 2017 at 08:09:17PM -0400, myglc2 wrote: >>> On 07/01/2017 at 14:01 Leo Famulari writes: >>> > ... Bayfront is still not fully operational, so hydra.gnu.org is still >>> > serving as the front-end of the build farm. We are still relying on the >>> > Hydra software. That is, the situation is basically the same as before. >>> > Adding build machines will not help very much until the front-end >>> > hardware gets faster. >>> >>> This leaves me wondering ... >>> >>> Is the hydra/front-end hardware going to be upgraded? >> >> Yes... >> >>> Is bayfront/cuirass intended to replace hydra? >> >> ... and yes. >> >>> The bayfront hardware described here ... >>> >>> https://www.gnu.org/software/guix/news/growing-our-build-farm.html >>> >>> ... seems weak to me. Is there a plan to scale it up and make it redundant? >> >> It will be a lot more powerful than the current Hydra system. As for >> specific plans, I'll let those administering the system chime in. > > That machine is super powerful… Well, I disagree. A 2010 motherboard with 2 x 2011 CPUs (16 core at 1.6GHz) is weak compared to modern servers. > but alas, it has also been terribly > unstable. Vikings has been kind enough to assist us; they’ve notably > provided us with CPU replacements once already. Despite these efforts, > the machine is still crashing. We’re investigating with them what to > do next. > > On top of that, all the testing and all the back and forth takes an > awful lot of time, which is in part due to hardware problems being hard > to pinpoint and debug in general, and in part due to us here in Bordeaux > (where the machine is hosted) being unable to scale up. As you have experienced here, the learning/deployment costs and hassle associated with each new type of server often dwarfs other costs. The best way to minimize this is to minimize the number of types of servers you own. In practice this means you need to place your bets carefully and quickly cut you loses if things don't work out. It also means that when (not if) a server breaks you should buy one exactly like the broken one. At this point it makes sense to abandon the Vikings motherboard and choose a popular, mainstream, current x86_64 motherboard. Since AMD has not been a competitive server vendor for the last ~8 years this means, practically speaking, picking a popular intel-based motherboard. > Infrastructure has been the project’s Achilles’ heel since we run the > crowdfunding campaign in Dec. 2015 (!). Now it’s becoming detrimental > to the project. Our initial plan was to buy more Libreboot-based > machines like the one above once the first one has proved to work > well. However, given the situation, we’ve been discussing on > guix-sysadmin a change in strategy, at least in the short term; > Ricardo has been working on re-purposing used hardware for our needs, > and that may well be our short- to medium-term solution. Hmm, didn't know about guix-sysadmin until now but couldn't easily read it. So, FWIW, here are some additional comments/suggestions ... It should be pretty easy to estimate the requirements to run the front end and do a nightly x86_64 build of guixSD, projected out 3 years. Do we have a handle on what this is? You should buy hardware that supports this and plan to discard it in 3 years. Since things always break, visualize a system in which every server has a redundant warm backup or is a pair of servers at 50% load. You can choose between amazingly cheap used servers that guzzle power or new servers that use less power. If you buy used computers ~ 3 years old the total cost of ownership will be nearly a wash over ~ 3 years of deployment. So, if you are cash rich, buy new computers. If you are cash-poor, buy used computers, but don't buy anything more than 3 years old, unless you want a computer museum ;-) The benefit of a used server is that it comes assembled and tested and probably has good driver support. Shiny new motherboards expose you to the risk of unstable drivers and BIOS. So, if you want new, you should probably buy last year's model ;-) In either case, it is tempting to assemble the computer. But this is not a good idea because there is always some glitch. The best strategy would be to buy assembled, tested servers with GuixSD installed and running. If you can't find a vendor that will do that for you, buy a test unit on the condition that the machine will be returned if GuixSD doesn't install smoothly. Specify RAIDed SSDs or, ideally, NVMe drives. Acquire a test unit quickly. If it works great, buy another one (or two)! If not, ditch it right away and try something else. Based on my experience it is easy to install GuixSD on 3 year old intel-based hardware. And I expect it should be equally easy to install on 1 year old intel-based hardware. Finally, WRT the bayfront hardware, when you said, "That machine is super po
Re: Guix infrastructure
Ludovic Courtès transcribed 2.5K bytes: > I not only sympathize with your frustration, ng0, I feel it even ten > times more. ;-) Several of us are determined to come up with a > solution quickly, so I hope that will materialize soon! > > Thanks, > Ludo’. > > Okay. About that.. It was not just no builds available. What for me the real grave issues are at the moment as someone who's primarily considering to base a project on GuixSD and who secondarily and within that scope contributes to GuixSD: - master is not stable and it is not being treated as a high priority problem, at least that is my impression from remarks in chat/emails and what I've been able to read. All arguing aside, that's something which can be fixed. CC'd dvn: in our last mumble session you mentioned that ii could get in touch with Guix. I don't think you'll forget it but here's an email for the start. I think you (Ludovic) suggested something similar to what ii is offering, but maybe I just imagined that ou commented on that. - a bug in the compiler which is used in the core of Guix is bad. In my understanding that we could at least try to evade this by reducing the module sizes is met with arguments like "this will be fixed in the future, for now we can only split 1 module the rest has to stay together for semantic and linguistic reasons". If my understanding of the whole situation is wrong this is due to the intransparent dealing with this serious problem and the way my idea to temporarily fix it was met. For me GuixSD as it is at the moment, is unusable. Not with my hardware, not with my knowledge and devices I have. But with the intention of the project I am running it aims at hardware which can not evade this bug. On my side even when we set up our own build infrastructure it will not change the fact that the current pull/make is using way too much resources for the end result I target. - Writing system services in Shepherd is hard. The debugging of these services is a major pain compared to writing services for OpenRC or systemd. I'm no expert in Guile, I understand more than 2.7(?) years ago (coming to Guix was my first exposure to Guile). With OpenRC I'm not really sure why it is easier. I just know what would work and what doesn't work. It has its limits, it operates in another system structure. - Debugging in general. It would be *very* good if debugging symbols and capabilities wouldn't be an 'write your local inherits and overrides so that you get debug outputs' thing. This is not just my opinion, people brought this up in off the record chats (and possibly even in irc) before. These are the major issues Guix could fix. There's more where I know it will not be fixed and/or it can not be fixed[0], those are reasons why we are currently re-evaluating the choice of the system. Maybe it turns out playing the high-chase speed run with Guix is the only sane choice. Maybe it doesn't. There are no hard feelings if the issues above will not be fixed, it's just something which makes it frustrating to work with Guix. The frustration did set in when the 0.13 / guile 2.2.2 related bug(s) came to the list of existing issues for me. When I came to GuixSD in Winter 2015 I saw a huge potential. I still see it. I hope we can fix this, no matter how the re-evaluation on our side turns out. 0: Most of these issues are differences in goals and how it applies to what is technically implemented, etc. Public docs are incomplete and intransparent, so the links below (for the curious) will not represent the actual state of what is being worked towards. -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org signature.asc Description: PGP signature
Re: Inkscape libpoppler error
I fixed it: guix package -i inkscape --no-grafts Inkscape works now ;) Thanks Kei and Guixs, --- Daniel Pimentel (d4n1) On 2017-07-08 19:47, Kei Kebreau wrote: Kei Kebreau writes: Daniel Pimentel writes: Hi guixs, today I updated my GuixSD but my Inkscape not start :( I installed poppler and I reinstaled inkscape too. In my ~/.guix-profile there isn't libpoppler.so.66 but in my system there: /gnu/store/mpq4v7hgg02gl0bkjjq8612rm3sira5s-poppler-0.52.0/lib/libpoppler.so.66 /gnu/store/c31lmp5smk9snfyb8rf7mmzrdv15aps8-poppler-0.52.0/lib/libpoppler.so.66 /gnu/store/8c0bj7imclym7rmf1pa3cgf2xg1qbv25-poppler-0.52.0/lib/libpoppler.so.66 Error output: inkscape: error while loading shared libraries: libpoppler.so.66: cannot open shared object file: No such file or directory Hi Daniel, I just checked the inkscape package on my computer and I got the same error. I'm looking into the problem now. Sorry for the inconvenience. I've found the source of the issue and I'm seeing about fixing it. In the meantime, you can reinstall inkscape using the following command: guix package -i inkscape --no-grafts
Re: Inkscape libpoppler error
Kei Kebreau writes: > Daniel Pimentel writes: > >> Hi guixs, >> >> today I updated my GuixSD but my Inkscape not start :( >> >> I installed poppler and I reinstaled inkscape too. In my >> ~/.guix-profile there isn't libpoppler.so.66 but in my system there: >> /gnu/store/mpq4v7hgg02gl0bkjjq8612rm3sira5s-poppler-0.52.0/lib/libpoppler.so.66 >> /gnu/store/c31lmp5smk9snfyb8rf7mmzrdv15aps8-poppler-0.52.0/lib/libpoppler.so.66 >> /gnu/store/8c0bj7imclym7rmf1pa3cgf2xg1qbv25-poppler-0.52.0/lib/libpoppler.so.66 >> >> Error output: >> inkscape: error while loading shared libraries: libpoppler.so.66: >> cannot open shared object file: No such file or directory > > Hi Daniel, > > I just checked the inkscape package on my computer and I got the same > error. I'm looking into the problem now. Sorry for the inconvenience. I've found the source of the issue and I'm seeing about fixing it. In the meantime, you can reinstall inkscape using the following command: guix package -i inkscape --no-grafts signature.asc Description: PGP signature
Re: Inkscape libpoppler error
Daniel Pimentel writes: > Hi guixs, > > today I updated my GuixSD but my Inkscape not start :( > > I installed poppler and I reinstaled inkscape too. In my > ~/.guix-profile there isn't libpoppler.so.66 but in my system there: > /gnu/store/mpq4v7hgg02gl0bkjjq8612rm3sira5s-poppler-0.52.0/lib/libpoppler.so.66 > /gnu/store/c31lmp5smk9snfyb8rf7mmzrdv15aps8-poppler-0.52.0/lib/libpoppler.so.66 > /gnu/store/8c0bj7imclym7rmf1pa3cgf2xg1qbv25-poppler-0.52.0/lib/libpoppler.so.66 > > Error output: > inkscape: error while loading shared libraries: libpoppler.so.66: > cannot open shared object file: No such file or directory Hi Daniel, I just checked the inkscape package on my computer and I got the same error. I'm looking into the problem now. Sorry for the inconvenience. signature.asc Description: PGP signature
Wicd-curses urwid error
Hi guixs, there is a error with wicd-curses package. Follow my error output: Traceback (most recent call last): File "/gnu/store/345x7rgqqj8crpp53zskl72a9lm75g97-wicd-1.7.4/share/wicd/curses/wicd-curses.py", line 44, in import urwid ImportError: No module named urwid I installed urwid package (python2-urwid and python-urwid) but not work more. I'll debug and I'll try send patch to fix it. -- Daniel Pimentel (d4n1)
Re: 01/01: gnu: wxmaxima: Update to 17.05.0.
Mark H Weaver writes:
> k...@openmailbox.org (Kei Kebreau) writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit 5143517c9969d17b48cbb60e1103633bc0cfb430
>> Author: Kei Kebreau
>> Date: Fri Jul 7 22:58:27 2017 -0400
>>
>> gnu: wxmaxima: Update to 17.05.0.
>>
>> * gnu/packages/maths.scm (wxmaxima): Update to 17.05.0.
>> [source]: Update URL and add file-name.
>> [native-inputs]: Add autoconf, automake and gettext-minimal.
>> [arguments]: Add 'autoconf' phase.
>
> [...]
>
>> @@ -2172,6 +2176,10 @@ point numbers.")
>> ("shared-mime-info" ,shared-mime-info)))
>> (arguments
>> `(#:phases (modify-phases %standard-phases
>> + (add-before
>> + 'configure 'autoconf
>> + (lambda _
>> + (zero? (system* "./bootstrap"
>
> In general, autoconf-style phases like this should be put after the
> 'unpack' phase, not before the 'configure' phase. The reason is that on
> some platforms (e.g. mips64el-linux), the 'patch-usr-bin-file' phase
> needs to be able to operate on the generated configure script.
>
> When you move the phase earlier, you may then find that you need to
> launch the 'bootstrap' script differently, because its shebang will not
> be correct. That's because it will now be run before the
> 'patch-source-shebangs' phase.
>
> So, the way we normally do this is to run something like:
>
> (zero? (system* "sh" "bootstrap"))
>
> Grepping for "add-before 'configure" reveals that there are now a rather
> large number of instances of this problem. Oh well.
>
>Mark
I see. Thank you for the correction.
Do you consider it worth going through the package code and patching
this problem specifically or should it be corrected gradually while
making other changes?
signature.asc
Description: PGP signature
Inkscape libpoppler error
Hi guixs, today I updated my GuixSD but my Inkscape not start :( I installed poppler and I reinstaled inkscape too. In my ~/.guix-profile there isn't libpoppler.so.66 but in my system there: /gnu/store/mpq4v7hgg02gl0bkjjq8612rm3sira5s-poppler-0.52.0/lib/libpoppler.so.66 /gnu/store/c31lmp5smk9snfyb8rf7mmzrdv15aps8-poppler-0.52.0/lib/libpoppler.so.66 /gnu/store/8c0bj7imclym7rmf1pa3cgf2xg1qbv25-poppler-0.52.0/lib/libpoppler.so.66 Error output: inkscape: error while loading shared libraries: libpoppler.so.66: cannot open shared object file: No such file or directory -- Daniel Pimentel (d4n1)
Re: 01/01: gnu: wxmaxima: Update to 17.05.0.
k...@openmailbox.org (Kei Kebreau) writes:
> kkebreau pushed a commit to branch master
> in repository guix.
>
> commit 5143517c9969d17b48cbb60e1103633bc0cfb430
> Author: Kei Kebreau
> Date: Fri Jul 7 22:58:27 2017 -0400
>
> gnu: wxmaxima: Update to 17.05.0.
>
> * gnu/packages/maths.scm (wxmaxima): Update to 17.05.0.
> [source]: Update URL and add file-name.
> [native-inputs]: Add autoconf, automake and gettext-minimal.
> [arguments]: Add 'autoconf' phase.
[...]
> @@ -2172,6 +2176,10 @@ point numbers.")
> ("shared-mime-info" ,shared-mime-info)))
> (arguments
> `(#:phases (modify-phases %standard-phases
> + (add-before
> + 'configure 'autoconf
> + (lambda _
> + (zero? (system* "./bootstrap"
In general, autoconf-style phases like this should be put after the
'unpack' phase, not before the 'configure' phase. The reason is that on
some platforms (e.g. mips64el-linux), the 'patch-usr-bin-file' phase
needs to be able to operate on the generated configure script.
When you move the phase earlier, you may then find that you need to
launch the 'bootstrap' script differently, because its shebang will not
be correct. That's because it will now be run before the
'patch-source-shebangs' phase.
So, the way we normally do this is to run something like:
(zero? (system* "sh" "bootstrap"))
Grepping for "add-before 'configure" reveals that there are now a rather
large number of instances of this problem. Oh well.
Mark
Re: `guix pack --target=arm-linux-gnueabihf guile` fails at phase unpack
On Sat, Jul 08, 2017 at 01:19:16AM -0500, Louis Pearson wrote: > starting phase `unpack' > In execvp of tar: No such file or directory > phase `unpack' failed after 0.0 seconds > What is going on? The important part appears to be `In execvp of tar: > No such file or directory`, but I'm not sure why tar is unable to find > the file/directory. I'm not sure what the root cause of the failure is, but I think it's more likely this message is coming from execvp() and means that `tar` cannot be found. signature.asc Description: PGP signature
Re: [PATCH] service: Fix arguments passing in the 'restart' action.
On Sat, 8 Jul 2017 18:00:34 +0800 宋文武 wrote: > - (start obj args))) > + (apply start obj args))) LGTM!
[PATCH] service: Fix arguments passing in the 'restart' action.
* modules/shepherd/service.scm (action): Use 'apply' to invoke the 'start' procedure in the 'restart' action. --- modules/shepherd/service.scm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/shepherd/service.scm b/modules/shepherd/service.scm index 26f29aa..72fbc3d 100644 --- a/modules/shepherd/service.scm +++ b/modules/shepherd/service.scm @@ -398,7 +398,7 @@ wire." (if running (stop obj) (local-output "~a was not running." (canonical-name obj))) - (start obj args))) + (apply start obj args))) ((status) ;; Return the service itself. It is automatically converted to an sexp ;; via 'result->sexp' and sent to the client. -- 2.12.2
cuirass evaluate
Hi, Now that Cuirass uses (guix git), I'm trying to robustify specification evaluation. Currently Cuirass calls a binary called "evaluate" to get a job list from a specification. I don't like the idea of this extra "evaluate" script because : * We have to give evaluate almost all arguments given to Cuirass (load-path, package-path, cachedir, spec, database). * The script is made available for the user but it's very unclear how to call it. The help says : "Usage evaluate FILE" which is wrong (5 arguments are expected). So my question is, is this a strong requirement to have a separate script to parse specification, or can I put this stuff back in main Cuirass program ? Thanks, Mathieu
