Update LTR to 3.28.12

[SrNetoChan]

Checklist

• [x] Used a personal fork of the feedstock to propose changes
• [ ] Bumped the build number (if the version is unchanged)
• [x] Reset the build number to 0 (if the version changed)
• [ ] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [ ] Ensured the license file is being packaged.

[conda-forge-webservices[bot]]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[SrNetoChan]

@conda-forge-admin, please rerender

[conda-forge-webservices[bot]]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [118]

[conda-forge-webservices[bot]]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[SrNetoChan]

@conda-forge-admin, please rerender

[gillins]

@h-vetinari sorry to ask again, but do you have any idea about the error messages below? Is it a C++ mismatch?

qgsvectortilemvtencoder.cpp.obj : error LNK2019: unresolved external symbol "private: void __cdecl absl::lts_20230802::log_internal::LogMessage::CopyToEncodedBuffer<0>(class std::basic_string_view<char,struct std::char_traits<char> >)" (??$CopyToEncodedBuffer@$0A@@LogMessage@log_internal@lts_20230802@absl@@AEAAXV?$basic_string_view@DU?$char_traits@D@std@@@std@@@Z) referenced in function "public: class absl::lts_20230802::log_internal::LogMessage & __cdecl absl::lts_20230802::log_internal::LogMessage::operator<<<48>(char const (&)[48])" (??$?6$0DA@@LogMessage@log_internal@lts_20230802@absl@@QEAAAEAV0123@AEAY0DA@$$CBD@Z)
vector_tile.pb.cc.obj : error LNK2001: unresolved external symbol "private: void __cdecl absl::lts_20230802::log_internal::LogMessage::CopyToEncodedBuffer<0>(class std::basic_string_view<char,struct std::char_traits<char> >)" (??$CopyToEncodedBuffer@$0A@@LogMessage@log_internal@lts_20230802@absl@@AEAAXV?$basic_string_view@DU?$char_traits@D@std@@@std@@@Z)
qgsvectortilemvtencoder.cpp.obj : error LNK2019: unresolved external symbol "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > * __cdecl absl::lts_20230802::log_internal::MakeCheckOpString<unsigned __int64,unsigned __int64>(unsigned __int64,unsigned __int64,char const *)" (??$MakeCheckOpString@_K_K@log_internal@lts_20230802@absl@@YAPEAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@_K0PEBD@Z) referenced in function "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > * __cdecl absl::lts_20230802::log_internal::Check_LEImpl<unsigned __int64,unsigned __int64>(unsigned __int64 const &,unsigned __int64 const &,char const *)" (??$Check_LEImpl@_K_K@log_internal@lts_20230802@absl@@YAPEAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AEB_K0PEBD@Z)
vector_tile.pb.cc.obj : error LNK2001: unresolved external symbol "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > * __cdecl absl::lts_20230802::log_internal::MakeCheckOpString<unsigned __int64,unsigned __int64>(unsigned __int64,unsigned __int64,char const *)" (??$MakeCheckOpString@_K_K@log_internal@lts_20230802@absl@@YAPEAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@_K0PEBD@Z)

[h-vetinari]

do you have any idea about the error messages below? Is it a C++ mismatch?

Type mismatch is unlikely unless you're compiling with something before C++17.

It's possible though that qgis isn't ready yet for the brave new protobuf world where you now need to link to abseil even as a protobuf consumer. Looking at the failing link invocation in the log, I don't see abseil anywhere, so this is probably missing a target_link_libraries for the respective target.

[SrNetoChan]

Sorry @gillins , my bad... When 3.34 becomes the LTR, let's add it to migrations again.

[gillins]

Hi @SrNetoChan this is my bad... I assumed this was due to some migration problem, but turns out I had to backport some fixes from 3.34 for dealing with a more recent protobuf. So we could have done this much sooner... Sorry. Happy to leave it off migrations (or on - whatever you think is best). Thanks @h-vetinari you got me on the right track!