Package Details: nomad 0.8.6-1

Git Clone URL: (read-only)
Package Base: nomad
Description: A Distributed, Highly Available, Datacenter-Aware Scheduler
Upstream URL:
Licenses: MPL
Submitter: mtorromeo
Maintainer: mtorromeo
Last Packager: mtorromeo
Votes: 14
Popularity: 0.931393
First Submitted: 2016-02-25 21:45
Last Updated: 2018-10-01 06:45

Latest Comments

1 2 Next › Last »

leothrix commented on 2018-07-29 17:11

The bump to 0.8.4 seems to have changed something with the build process, because now the binary doesn't show the UI anymore when trying to view :4646/ui:

Nomad UI is not available in this binary.

You can check the complete output by running the binary and browsing :4646, but it suggests either using make release, an official binary release, or make dev-ui. Not sure what the best approach to fixing it may be (either tweaking the go compilation command or using make release and grabbing the compilation artifact instead).

mtorromeo commented on 2018-07-11 11:25

Applied patch to fix the build

Svenstaro commented on 2018-07-09 18:30

Seems to be broken right now:

In file included from vendor/ ./lxc-binding.h:76:8: error: redefinition of 'struct migrate_opts' struct migrate_opts { ^~~~~~~~~~~~

jshuping commented on 2017-09-11 15:40

They've changed the build logic in 0.6.2, there is no longer a

==> Extracting sources...
-> Extracting nomad-0.6.2.tar.gz with bsdtar
==> Starting prepare()...
sed: can't read scripts/ No such file or directory
==> ERROR: A failure occurred in prepare().

thaewrapt commented on 2017-07-03 14:59

Works like charm w/o 'tree' now, thanks!

grossws commented on 2017-06-22 14:20

It seems that `tree` should be added to build deps.

mtorromeo commented on 2017-01-07 09:54

What I was explaining in previous comments is that the version was never updated from rc1 to stable in the git repo.

Here you can see that it was only bumped less than 24h ago from 0.5.2-rc1 to 0.5.3-dev, with no stable version in between the two:

Anyway, this is only cosmetic.

gehzumteufel commented on 2017-01-07 02:24

Then one should cherry pick the commit changing the version from rc1 to release or create a compile time patch.

mtorromeo commented on 2017-01-06 23:25

@gehzumteufel: those are binary releases and I already know that I am getting the correct tarball as these are the source releases:

If they built their binary releases from a different commit I can't know for sure but the PKGBUILD points to the correct upstream version.

gehzumteufel commented on 2017-01-06 23:11

You really should source the release from here. This way you know you're getting the correct tarball.