[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#761817: Fwd: Fwd: [info] Upcoming Debian repository signing key expiration



Hi Christop,
Thanks for giving us a heads up regarding the key life time.
I've read through:

(which is probably related to this mail?)
and have some remarks:

 - V8 does not provide a stable API across versions, so you need exactly the version that we use (or that release series).
 - we apply some patches to V8, mostly build system related, however some of them patch away some "Resources empty? Geronimo!!!!" code which is not nice to have in a database - that will auto-terminate without any feedback then.
 - Rocksdb - same here. While we send patches of our changes upstream, they may only become available in later versions which may not be api compatible - so if I strongly sugest to use the version shipped with arangodb.
 - Boost - you most probably need the version we use, it should be ok to use a system provided version
 - snappy - whatever is newer probably is better. needs to work with rocksdb.
 - s2 (not yet in your list) - probably needs to be exactly the shipped version with ArangoDB 3.4
 - curl - you can probably use newer versions.
 - velocypack - our binary json representation https://github.com/arangodb/velocypack/ - to be honest we didn't yet work with tags here so you could identify whats released with which arangodb - we need to fix this.
 - fuerte - our binary transport c++ library - issues see velocypack.
 - iresearch - needs to be a matching version, however upstream is also maintained by us.
 - ICU - we use the one bundled with V8 - don't know whether there is a good way to include a system one

Up to arangodb we used cpack to generate debian packages, accompanying scripts can be found in Installation/debian; This is probably why you don't find a debian/ directory.
With ArangoDB 3.4 we migrated to statically linked binaries with libmusl - compile once, bundle into tar/rpm/deb; The currently used debian scripts can be found here: https://github.com/arangodb/oskar/tree/master/debian/3.4

Since we need to be able to ship bugfix versions, we do this with the third version digit incrementing. So Arangodb 3.3.20 can be treated as a bugfix version of 3.3.19.

The current arangodb cmake build is intended to bundle and bring all required 3rd party libraries, I don't know how well it can be configured to prefer system installed ones.

If you have more questions regarding compiling arangodb don't hesitate to ping me via slack or github issues.

Cheers,
Willi

ps: there are only rspec / ruby tests remaining which probably shouldn't be represented in the final package, the ruby tag of the initial wnpp can probably be removed.

---------- Forwarded message ---------
From: Christoph Biedl <debian.axhn@manchmal.in-ulm.de>
Date: Mi., 12. Dez. 2018 um 01:11 Uhr
Subject: [info] Upcoming Debian repository signing key expiration
To: Frank Celler <info@arangodb.com>


Hello,

thanks for providing arangodb packages for Debian, and especially for
providing a GPG signature for these. However, there is a problem coming:
The key as provided at

    https://download.arangodb.com/arangodb34/DEBIAN/Release.key

has an expiration date less than six months into the future:

| $ gpg --list-key EA93F5E56E751E9B
+ pub   rsa4096 2015-06-02 [SC] [expires: 2019-06-01]
|       CD8CB0F1E0AD5B52E93F41E7EA93F5E56E751E9B
| uid           [ unknown] Frank Celler (ArangoDB Debian Repository) <info@arangodb.com>
+ sub   rsa4096 2015-06-02 [E] [expires: 2019-06-01]

From my experience, deploying a new signing key is a lengthy process,
so I'm asking you to start it as soon as possible. Unfortunatley, the
risk users out there will not install it in time is already quite high.

Regards,

    Christoph




Reply to: