Accepted redis 3:3.2.9-1~bpo9+1 (source amd64) into stretch-backports, stretch-backports
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Format: 1.8
Date: Wed, 26 Jul 2017 19:53:36 +0100
Source: redis
Binary: redis-server redis-tools redis-sentinel
Built-For-Profiles: nocheck
Architecture: source amd64
Version: 3:3.2.9-1~bpo9+1
Distribution: stretch-backports
Urgency: medium
Maintainer: Chris Lamb <lamby@debian.org>
Changed-By: Chris Lamb <lamby@debian.org>
Description:
redis-sentinel - Persistent key-value database with network interface (monitoring)
redis-server - Persistent key-value database with network interface
redis-tools - Persistent key-value database with network interface (client)
Closes: 850534 852347 856116 858519
Changes:
redis (3:3.2.9-1~bpo9+1) stretch-backports; urgency=medium
.
* Rebuild for stretch-backports.
.
redis (3:3.2.9-1) unstable; urgency=medium
.
* New upstream minor bugfix release.
* Specify <!nocheck> for test-related Build-Depends.
* Bump debhelper compatibility level to 10.
.
redis (3:3.2.8-3) unstable; urgency=medium
.
* Revert the creation of the redis-tools:/usr/bin/redis-check-rdb ->
redis-server:/usr/bin/redis-server symlink to avoid a dangling symlink if
only the redis-tools binary package is installed.
.
This was a regression since 3:3.2.6-3 where we attempted to avoid shipping
duplicate file; the redis-server binary changes behaviour based on the
contents of argv.
.
One alternative would be to ship a symlink in redis-server but that would
mean users wishing to check RDB databases would have to install the server
package, so reverting to shipping a duplicate file seems justified.
(Closes: #858519)
.
redis (3:3.2.8-2) unstable; urgency=medium
.
* Avoid conflict between RuntimeDirectory and tmpfiles.d(5) both attempting
to create /run/redis with differing permissions.
.
This prevents an installation error on Jessie where /run/redis was first
being created by the tmpfiles.d(5) mechanism and then subsequently via the
RuntimeDirectory directive. Due to a bug in Jessie's systemd, this caused a
package installation error as systemd was too strict about permissions if
the target already exists: <https://github.com/systemd/systemd/pull/896>
.
The redis-{server,sentinel} daemon would actually start successfully a few
milliseconds later due to the Restart=always directive.
.
We work around this this by dropping the tmpfiles.d(5) handling and moving
entirely to RuntimeDirectory{,Mode}; we are not using any special handling
requiring tmpfiles.d(5) and we appear to need RuntimeDirectory anyway for
#846350. (Closes: #856116)
.
redis (3:3.2.8-1) unstable; urgency=medium
.
* New upstream release.
.
redis (3:3.2.7-1) unstable; urgency=medium
.
* New upstream release.
.
redis (3:3.2.6-6) unstable; urgency=medium
.
* Use --cpu-list 0 (not --cpu-list 1) to ensure compilation on single-CPU
machines. (Closes: #852347)
.
redis (3:3.2.6-5) unstable; urgency=medium
.
* Re-add taskset calls to try and avoid FTBFS due to parallelism in upstream
test suite.
.
redis (3:3.2.6-4) unstable; urgency=medium
.
* Expand the documentation in redis-server.service and redis-sentinel
regarding the default hardening options.
.
redis (3:3.2.6-3) unstable; urgency=medium
.
* Don't ship a "duplicate" redis-server binary in redis-tools as
/usr/bin/redis-check-rdb (it checks argv to change its behaviour) by
replacing it with a symlink. Found by <https://dedup.debian.net/>.
.
redis (3:3.2.6-2) unstable; urgency=medium
.
* Rename RunTimeDirectory -> RuntimeDirectory in .service files.
(Closes: #850534)
* Refresh all patches with pq import -> pq export.
* Tidy all patches, updating descriptions and use Pq-Topic to organise.
Checksums-Sha1:
4780f34de5f3116e4ad5b0cfe4d03760287135cf 2059 redis_3.2.9-1~bpo9+1.dsc
0e513c26da2e3fc5596d808fc1b6c506c654470a 36248 redis_3.2.9-1~bpo9+1.debian.tar.xz
268ba8dc2835f8fad37015d5da49d95176a73b10 19366 redis-sentinel_3.2.9-1~bpo9+1_amd64.deb
1cb8771cd3333dadd7bc4ed8e362d56ec5b22d04 1038640 redis-server-dbgsym_3.2.9-1~bpo9+1_amd64.deb
d3edf3ff57a5faedbd57ec3c5d6c7db8fb68a02a 414276 redis-server_3.2.9-1~bpo9+1_amd64.deb
5bc3f24d9b97c830c216e33332b5a691150081fa 1256676 redis-tools-dbgsym_3.2.9-1~bpo9+1_amd64.deb
3534e6723ff53cfdc72956c1587bbdf13ab333af 463990 redis-tools_3.2.9-1~bpo9+1_amd64.deb
6af855dcc110d05a47fcc4ce280fbb8b6b54e47a 6742 redis_3.2.9-1~bpo9+1_amd64.buildinfo
Checksums-Sha256:
2634655098173b31503c856c75a9c90ec2ee43be41d78f92fd47851af2ee3a22 2059 redis_3.2.9-1~bpo9+1.dsc
e2bec804ef6338965bcab0c891024f07bed4271833cc1596b5cb88d47286079c 36248 redis_3.2.9-1~bpo9+1.debian.tar.xz
62154a139e9c7ba434ad0eee7575b301836a7cd1e1f118fa00ef92419849dbeb 19366 redis-sentinel_3.2.9-1~bpo9+1_amd64.deb
07f20960ea273bafda04b11c65c2b6aa7b46eaabc0d364f36e4789642d44d1dc 1038640 redis-server-dbgsym_3.2.9-1~bpo9+1_amd64.deb
55283ca298a9ad3c953d6ceb6fa3bb53a11b1cb8d63aa95f8fa0b6447b82c8e2 414276 redis-server_3.2.9-1~bpo9+1_amd64.deb
69dbfe2db9f6be7f44e3418bb5f03e7e8a410e2086a9c828e2bec36dbcb23480 1256676 redis-tools-dbgsym_3.2.9-1~bpo9+1_amd64.deb
7f3c735fef4ada25954c730614d32a400dbc1da256596b17789663b253c15fca 463990 redis-tools_3.2.9-1~bpo9+1_amd64.deb
c644499a690065a3a019d65ce7d82c35c0c5dd385dcf066dc7b59869be083718 6742 redis_3.2.9-1~bpo9+1_amd64.buildinfo
Files:
dfd6d4dcb3a20b7f8718e09fe91802fd 2059 database optional redis_3.2.9-1~bpo9+1.dsc
8294efb3868830f4d803079c7cd00872 36248 database optional redis_3.2.9-1~bpo9+1.debian.tar.xz
21cd195097aede344fac47af4bc2641a 19366 database optional redis-sentinel_3.2.9-1~bpo9+1_amd64.deb
fd7c14524682acc5ba7d911a0f801560 1038640 debug extra redis-server-dbgsym_3.2.9-1~bpo9+1_amd64.deb
bdfcb0df83f46fbdc4a7f9c61cef5de2 414276 database optional redis-server_3.2.9-1~bpo9+1_amd64.deb
21611f3c671f71d4f11bffe87767a317 1256676 debug extra redis-tools-dbgsym_3.2.9-1~bpo9+1_amd64.deb
516e0c6c613613b6b3d8573194e2ab04 463990 database optional redis-tools_3.2.9-1~bpo9+1_amd64.deb
ff0022109be7c84a1cfbf89971e75459 6742 database optional redis_3.2.9-1~bpo9+1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEwv5L0nHBObhsUz5GHpU+J9QxHlgFAll45YAACgkQHpU+J9Qx
HlijiA/+KlN0++5qCXUX2bCSquvOKNgpm+V59InFTjCckZDqfCo8DHzNWJRG2x0d
Ax6orR7VBEF4IQCD4hKpMKUVfz1BnYfJTjNSY3o+RPoDrcln0gFlzYV+M5PrqfLY
fAr92CFCEaCBi7sPlamLIJlnBZ9cUlG7UxIrTsanRA4i+NUnDqt7UlczD2pd4JOo
F9SKShPu9053qyiQPdIHRJ9HF/wzojACXv6urXI9i5T9y7SNkCJJ+wlNyNSbTQyj
Tl31I0xxmcT2du5CAWMe7TFMxAQjhCnKJ8vqIShXcR/ROfdgnh98zxx0AjTmXrrd
InlBBsE4pRkclVn7addRT1mrjGpRr5l5OuaoJmICNzUIKOOTLw79FMVFqJZE2uzm
S/wIc6CkhcMEcLPvHovz6XxAPm8zugC3cz0R41SiwZcPJASubkmbFvC7s9Et5pRX
qEZeLbL31cWPihqaMTKzPhg7b/l6dGOKEXVtCOsEKoUSKYEuEggczaOngZOPrcdD
paC2BfrnelPCyY4Iwy87OHA9j3smIS1qfxuTTlwhdivFI7p2i9TkW4oZGRDejDtw
pab3co9AjvJCMa5P5DLjLeqne6aaRe+eDJ8VXCa9hNSB0ADsmPO4hIyT4NMsAq/a
a07UuZ9sTtVS8CvkrS/BZhjRTH5kAQhV/Zd3zPpzc+ol1JX1j6A=
=vb8X
-----END PGP SIGNATURE-----
Reply to: