Log message:
Update rabbitmq to 2.8.0.

Changes in 2.8.0:

* Dead lettering
* Internal flow control

Log message:
Bump PKGREVISION from default python change to 2.7.

Log message:
Convert to USE_TOOLS=zip.

Log message:
Update rabbitmq to 2.7.1

Changes:

* Important fixes to High Availability
* Compatibility with Erlang R15B
* Bug fixes and performance improvements

Log message:
Fix stale/missing config file

Log message:
Use Bash as interpretter in scripts properly

Log message:
Updated net/rabbitmq to 2.7.0.

Major changes:
  * Order preservation of re-queued messages
  * Plugins included with server
  * "amqp" URI client connection
  * Performance improvements

See full changelog:

  \ 
http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111109/116e9fd4/attachment.txt

Log message:
Updated net/rabbitmq to 2.6.1.

Various pkgsrc fixes:

- Fix mangled PLIST from the previous commit.
- Depend on coreutils for readlink, which is used in rabbitmq-env.
- Depend on bash, which is assumed throughout the scripts.
- Make sure the shell is passed properly to make/install targets.
- Fix Python usage (add Python 2.7) and clean up other bits.

RabbitMQ changelog:

2.6.1 bug fixes
- The broker failed to (re)start on reboot on systems that keep
  /var/run on a temporary file systems, e.g. Ubuntu.
- The Windows service failed to increase the Erlang process limit,
  limiting the broker to a few thousand queues, connections and
  channels.

2.6.0 bug fixes
- Upgrading from RabbitMQ 2.1.1 to any later release could break if
  there were durable queues with persistent messages present.
- On very slow machines, starting rabbit via the supplied init scripts
  could fail with a timeout.
- Rabbit could fail to stop (when asked to do so) in the presence of
  some plug-ins (e.g. shovel).
- 'ram' nodes in a cluster could consume ever increasing amounts of
  disk space.
- The presence of fast consumers on a queue could significantly delay
  the addition of new consumers.
- When a client was issuing a tx.commit in one channel, and
  simultaneously, in another channel, deleted a durable queue with
  persistent messages involved in that tx, rabbit could terminate with
  an error.
- When a client was using both basic.qos and channel.flow, the latter
  would fail to re-enable message flow.
- When using 'confirm' mode, the deletion of queues could cause nacks
  to be issued (incorrectly).
- In extremely rare circumstances (never observed in the wild), a
  queue with a per-queue message ttl could break during sudden changes
  in rabbit memory usage.

2.6.0 enhancements
- Introduce active-active HA, with queues getting mirrored on nodes in
  a cluster. See http://www.rabbitmq.com/ha.html.
- Revamp the handling of AMQP's tx (transaction) class and clarify its
  behaviour See http://www.rabbitmq.com/specification.html#tx.
- Replace the 'administrator' flag, as used by the management plugin,
  with a more general 'user tags' mechanism. See
  http://www.rabbitmq.com/man/rabbitmqctl.1.man.html#set_user_tags.
- Do not require 'configure' permissions for passive queue/exchange
  declaration.
- Optimise of message delivery on channels with a basic.qos
  prefetch limit that are consuming from many queues.
- In 'rabbitmqctl list_channels', do not show the tx mode by default.
- When a cluster 'degrades' to only containing ram nodes - through
  'rabbitmqctl' actions or node failure - display/log a warning.
- Eliminate some spurious errors from the sasl log.

Log message:
Upgrade from 2.1.0 -> latest (2.5.1).  Also fixes build.

---
Release messages:
The RabbitMQ team is pleased to announce the release of RabbitMQ 2.1.1.
This release fixes a number of bugs and introduces some enhancements,
including exchange to exchange bindings and some performance improvements,
in the server and clients.

The RabbitMQ team is pleased to announce the release of RabbitMQ 2.2.0.
This release fixes a number of bugs and introduces some enhancements,
including automatic upgrades of non-clustered brokers, per-queue message
TTLs and significantly reduced memory usage for pending acknowledgements.

Perfectly timed one day before the start of the year of the Rabbit,
the RabbitMQ team is pleased to announce the release of RabbitMQ 2.3.0.
This release fixes a number of bugs and introduces some enhancements,
including streaming publish confirmations, new plugin mechanisms for
authentication and authorisation, and a great deal more.

The RabbitMQ team is pleased to announce the release of RabbitMQ 2.3.1.
This release fixes a small number of bugs, in particular one serious bug
in 2.3.0 which could lead to queue processes crashing.

The RabbitMQ team is delighted to announce the release of RabbitMQ 2.4.0.
This release fixes a number of bugs and introduces some enhancements,
including fast routing for topic exchanges, sender-selected distribution
and server-side consumer cancellation notifications.

The RabbitMQ team is delighted to announce the release of RabbitMQ 2.4.1.
This release fixes a number of bugs, in particular one bug in 2.4.0 that
would break upgrades if durable queues were present. A notable enhancement
included in this release are cluster upgrades.

The RabbitMQ team is delighted to announce the release of RabbitMQ 2.5.0.
This release fixes a number of bugs. In particular:
recovery has been simplified, improving startup times when many exchanges
or bindings exist
bindings are recovered between durable queues and non-durable exchanges
on restart of individual cluster nodes
better performance under high load and memory pressure
source compatibility with the new Erlang R14B03 release
New features include:
tracing facility for debugging incoming and outgoing messages, (see firehose)
improved inbound network performance
improved routing performance
new rabbitmqctl commands ('report', 'environment', and 'cluster_status')

The RabbitMQ team is pleased to announce the release of RabbitMQ 2.5.1.
This release correctly upgrades from RabbitMQ 2.1.1 and 2.2.0.
There are no other changes compared with 2.5.0.

Log message:
Import rabbitmq-2.1.0 as net/rabbitmq.

RabbitMQ is a complete and highly reliable Enterprise Messaging
system. The RabbitMQ client libraries and broker daemon can be used
together to create an AMQP network, or used individually to bring
the benefits of RabbitMQ to established networks.

(Based on wip/rabbitmq.)