Needs #108347 to build successfully on aarch64 Rebased

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/470

@Thra11 can you please take a look at the failing ofborg builds?

Thanks for working on getting OSM Scout Server and Pure Maps into NixOS. I can see that you incorporated libosmscout backend as well. As I am using very old version of it (as newer versions break API once in a while) and has stated that this backend is deprecated, I suggest to skip it when you package for NixOS. This would allow you later to use newer libosmscout library, if the apps using it will get traction. Otherwise, we will have a conflict over libosmscout version.

Alteranative is to package it as you did and be ready to disable the backend in OSM Scout Server as soon as libosmscout will be updated to newer versions.

Yeah, I tend to go with a policy along the lines of, "If an optional backend is on by default, supported on this platform, and not too much extra effort to include, then include it, as some users may want it".

Alteranative is to package it as you did and be ready to disable the backend in OSM Scout Server as soon as libosmscout will be updated to newer versions.

I think this is probably a reasonable approach. At the moment, there are no other packages which depend libosmscout, so it is unlikely to be updated to an incompatible version in the near future. NixOS does support having multiple versions of a package, so long as the added complexity justifies it. osmscout-server's disable_osmscout flag will be handy if we do want to disable it.

Good! Then at least you know the background and are aware of possible complications in future.

@SuperSandro2000 w.r.t ofborg's failing aarch64-linux build, it appears that #111198 landed in staging a little while back and has now made its way into master, breaking the valhalla build. I will investigate what needs to be done for valhalla to build against geos 3.9.0.

As far as the x86_64-linux build is concerned, I have no idea what's going on there:

In file included from /build/source/valhalla/midgard/linesegment2.h:7,
                 from /build/source/src/midgard/linesegment2.cc:1:
/build/source/valhalla/midgard/point2.h: In member function 'std::size_t std::hash<valhalla::midgard::Point2>::operator()(const valhalla::midgard::Point2&) const':
/build/source/valhalla/midgard/point2.h:198:5: error: 'uint64_t' was not declared in this scope; did you mean 'u_int64_t'?
  198 |     uint64_t h;
      |     ^~~~~~~~
      |     u_int64_t
/build/source/valhalla/midgard/point2.h:199:54: error: 'h' was not declared in this scope
  199 |     char* b = static_cast<char*>(static_cast<void*>(&h));
      |                                                      ^
In file included from /build/source/valhalla/midgard/obb2.h:7,
                 from /build/source/src/midgard/obb2.cc:1:
/build/source/valhalla/midgard/point2.h: In member function 'std::size_t std::hash<valhalla::midgard::Point2>::operator()(const valhalla::midgard::Point2&) const':
/build/source/valhalla/midgard/point2.h:198:5: error: 'uint64_t' was not declared in this scope; did you mean 'u_int64_t'?
  198 |     uint64_t h;
      |     ^~~~~~~~
      |     u_int64_t
/build/source/valhalla/midgard/point2.h:199:54: error: 'h' was not declared in this scope
  199 |     char* b = static_cast<char*>(static_cast<void*>(&h));
      |                                                      ^
make[2]: *** [src/midgard/CMakeFiles/valhalla-midgard.dir/build.make:82: src/midgard/CMakeFiles/valhalla-midgard.dir/linesegment2.cc.o] Error 1

I'll take a closer look once I've sorted the geos 3.9.0 issue.

@Thra11 : try to bump Valhalla to 3.1.0. I tested a bit with that version and OSM Scout Server looks to be working fine with it. From release notes, looks like Valhalla 3.1.0 supports geos 3.9. And I suspect that this undeclared uint64_t issue is fixed as well. If I remember correctly, I had to patch to get around that uint64_t issue. Hopefully, in newer Valhalla it is OK already.

Yes, I saw there was a commit fixing geos-3.9 in valhalla 3.1.0. Just making the necessary changes for it to build, as there are some new/no longer optional vendored dependencies.

When you fixed the build failures please undraft the PR.

@rinigus Any plans for a new osmscout-server release any time soon? Looks like I need a few of the unreleased commits for it to build against valhalla 3.1.0. (At a minimum, it needs the commit changing to C++14, otherwise std::max isn't constexpr. I assume it should have the "add Valhalla 3.1 config" commit too).

If not, no worries (don't want to rush you into releasing before you're ready). I can always either package from an unreleased commit or package the 1.17.1 release plus the required commits as patches.

@Thra11: I guess I should take it into my plans. There is also a wish to get ability to activate it via DBus to help those without systemd (pmOS). And switch to Valhalla 3.1.0 would also be helpful. So, there are some targets to work on the new release.

I am busy with working on my port of SFOS, but I will look into OSM Scout Server then this weekend.

Right. Now we once again have something that builds and runs.

Not entirely happy with the workaround for the HowardHinnant/date dependency, but valhalla puts us in a slightly awkward position there: Valhalla bundles date as a vendored build-time dependency, doesn't install the date headers which it uses, but then expects users to have the exact same version installed when building against valhalla (I assume they expect you to use valhalla as vendored dependency or something?). The alternative solution is to de-vendor date as a separate package, but since it probably still needs to be pinned to the version valhalla wants, that could actually end up being worse.

I've removed the unused fetchpatch input from libosmscout.

/status needs_merger

Reminder: Please review!

Reminder: This Pull Request is awaiting merger. If you are the assigned reviewer with commit permission, please have a look. If you can't, please say so. If the status is not accurate, please change it. If nothing happens, this PR will be should be put back in the needs_reviewer queue in one day.

Note: This feature is currently broken. The bot will not actually change the status. If you see this message multiple times, please request a status change manually.

/status awaiting_changes

Rebased and fixed conflicts in pkgs/top-level/all-packages.nix

This is a semi-automatic executed nixpkgs-review with nixpkgs-review-checks extension. It is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.

Result of nixpkgs-review pr 108354 run on x86_64-linux 1