The file is not installed, but this should eliminate any possible
  confusion in its use.

If GRES are associated with specific CPUs and a job allocation includes
GRES, which are not associated with the specific CPUs allocated to the
job, then when the job is deallocated, an underflow error results. To
reproduce:

gres.conf:
Name=gpu File=/dev/tty0 CPUs=0-5
Name=gpu File=/dev/tty1 CPUs=6-11
Name=gpu File=/dev/tty2 CPUs=12-17
Name=gpu File=/dev/tty3 CPUs=18-23

Then
$ srun --gres=gpu:2 -N1 --ntasks-per-node=2 hostname

In slurmctld log file:
error: gres/gpu: job 695 dealloc node smd1 topo gres count underflow

Logic modified to increment the count based upon the specific GRES
actually allocated, ignoring the associated CPUs (too late to consider
that after the GRES as picked).

Conflicts:
	NEWS
	src/slurmctld/acct_policy.c

Also a very minor sanity check in job_mgr.c to make sure we at least have
a task count.  This shouldn't matter, but just to be as robust as possible.

only 1 job was accounted (against MaxSubmitJob) for when an array was
submitted.

Correct counting for job array limits, job count limit underflow possible
    when master cancellation of master job record.
bug 1952

Bug 1905

Sort output of "scontrol show license" in alphabetic order and
 add test of that capability

Implement an option NONE for not sending mails
at all.
Closes http://bugs.schedmd.com/show_bug.cgi?id=1962

Also a very minor sanity check in job_mgr.c to make sure we at least have
a task count.  This shouldn't matter, but just to be as robust as possible.

only 1 job was accounted (against MaxSubmitJob) for when an array was
submitted.

Previous conf expansion was limited to "n-to-1" or "n-to-n" matching like :

Entity=node[1-10] key=value
Entity=node[1-10] key=value[1-10]

Now it is possible to have cycled or splitted "n-to-m" matching having
m<n or m>n (with m mod(n) being zero) like :

Entity=node[1-10] Enclosed=node[1-10]_core[0-31]
Entity=node[1-10]_core[0-31] core_id=[0-31] ...

Where :
	- node1 will enclose node1_core[0-31]
	- node2 will enclose node2_core[0-31]
	- ...

	- node1_core0 will have a core_id of 0
	- node1_core1 will have	a core_id of 1
	- ...
	- node2_core0 will have	a core_id of 0
	- ...

this new flags param will be used to bring more option in the show/update
and state dump layouts logic.

I've noticed that parameter JobCheckpointDir has a (from my point of view) inconsistent behavior.

* in sbatch executions, it is exported as CWD
* in srun it is also exported as CWD,
* except when it is manually set with "--checkpoint-dir=dir". If so, that value is exported.
* value defined in slurm.conf is, as far as I know, never read.

I have created this small patch to correct that behaviour. Now it is exported with the value configured on slurm.conf. If nothing is set, returned value is the defined on common/read_config.h,

The "scontrol hold/release" commands accept either "name=" or "jobname=". I've modified the documentation to only show "jobname" for consistentcy with the "scontrol update" command.

I have also modified the "scancel" command to accept "--jobname=" in addition to the existing "--name=" and "-n".

If a sleep was interrupted or ran a bit long, the backfill scheduler
run times could be significantly wrong as the sleep time was based
upon the calculation of sleep_count x desired_sleep_time. This new
logic captures and uses the actual sleep time for good accuracy.
bug 1939