arangodb: 3.4.8 -> 3.10.0#194670
arangodb: 3.4.8 -> 3.10.0#194670vcunat merged 24 commits intoNixOS:masterfrom jsoo1:jsoo1/arangodb-bump
Conversation
|
Turns out |
|
Is 3.10.0 still effected? If so, I suppose we could mark it insecure. |
|
Very unlikely, I think @yorickvP 's point is this will fix those issues. |
|
Yep, this upgrade will fix those issues. |
I see, thanks for the clarification! |
|
That reasoning doesn't make sense to me. You'd get gcc11 (which is supported by upstream). Instead you force gcc10, with an argument speaking against such a change. |
|
It (now) doesn't build for me on x86_64 NixOS. Maybe there was some (other) reason to downgrade compiler version. The errors look like changes around standard strictness, etc. (complex C++ traces; probably no sense to post them here) |
Same. I will investigate. |
|
I found a new problem - maybe or maybe not related to compile failures - edit: see arangodb/arangodb@cc860c3 |
3.{3,4,5} all reached EOL
It is unused.
It fails to apply
Which were EOL long ago.
Co-authored-by: Robert Scott <code@humanleg.org.uk>
USE_OPTIMIZE_FOR_ARCHITECTURE was removed without commit in a prior commit. This is because it was removed upstream: arangodb/arangodb@cc860c3 This is unfortunate - now /proc/cpuinfo is read unconditionally for feature detection. Some other means of feature detection will have to be found.
It seems that gcc11 - though reportedly supported - introduced some constraint that arangodb fails to compile with.
Avoid non-deterministic builds of ArangoDB proper. Note that this provides 0 guarantees about the vendored libraries doing anything similar.
If -DTARGET_ARCHITECTURE is supplied arango's cmake configuration will not use /proc/cpuinfo for feature detection. However, `generic` and `none` options both fail when building the vendored v8. This workaround provides some defaults, but warns if no override is provided.
As far as I can tell, this can cause compile failures when building the vendored abseil_cpp if choosing a target arch that does not support sse. This might be possible to determine programmatically, but it is more flexible to let the user decide.
For which no reliable default target architecture is provided upstream.
|
I decided to keep only Also, I used |
|
This is probably about as much effort as I can give to this package at the moment. Hopefully what I have is sufficient but I would be happy to see some other eyes on this. |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/prs-ready-for-review/3032/1378 |
| description = "A native multi-model database with flexible data models for documents, graphs, and key-values"; | ||
| license = licenses.asl20; | ||
| platforms = [ "x86_64-linux" ]; | ||
| maintainers = [ maintainers.flosse maintainers.jsoo1 ]; |
There was a problem hiding this comment.
| maintainers = [ maintainers.flosse maintainers.jsoo1 ]; | |
| maintainers = with maintainers; [ flosse jsoo1 ]; |
| # prevent failing with "cmake-3.13.4/nix-support/setup-hook: line 10: ./3rdParty/rocksdb/RocksDBConfig.cmake.in: No such file or directory" | ||
| dontFixCmake = true; | ||
| NIX_CFLAGS_COMPILE = "-Wno-error"; | ||
| preConfigure = "patchShebangs utils"; |
There was a problem hiding this comment.
This should really be a multiline string.
Description of changes
arangodbwas out of date (last commited 2018). This brings it to a more current version.Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)nixos/doc/manual/md-to-db.shto update generated release notes