in https://tracker.ceph.com/issues/55114, Laura pointed out a regression for cmake builds on centos/rhel involving the new 'utf8proc' dependency. for these distros, the Arrow submodule PR https://github.com/ceph/ceph/pull/44696 added an extra submodule for utf8proc, along with the cmake variable WITH_SYSTEM_UTF8PROC to control its use the required utf8proc v2.2.0 is available on other distros, so i chose WITH_SYSTEM_UTF8PROC=ON as the default. for centos/rhel, ceph.spec.in conditionally disables that flag when building the RPMs - so all of our CI should handle this correctly for local cmake builds, how would developers like this to work? we might consider a cmake script that auto-detects the presence of a compatible utf8proc, and only builds the submodule when necessary. however, package maintainers seem to prefer cmake options like WITH_SYSTEM_UTF8PROC for explicit control over bundled dependencies in the meantime, anyone that's blocked on cmake failures about utf8proc can work around this issue, either by disabling the arrow dependency entirely via -DWITH_RADOSGW_SELECT_PARQUET=OFF, or by selecting the utf8proc submodule via -DWITH_SYSTEM_UTF8PROC=OFF On Wed, Mar 23, 2022 at 3:48 PM Casey Bodley <cbodley@xxxxxxxxxx> wrote: > > fyi, the Arrow submodule just merged to master with > https://github.com/ceph/ceph/pull/44696. please let me know if this > causes any build issues on master asap! i'm planning to cherry-pick > this for the quincy release > > On Thu, Feb 10, 2022 at 5:16 PM Kaleb Keithley <kkeithle@xxxxxxxxxx> wrote: > > > > > > For those not in the RGW standups. > > > > liborc (Apache ORC) passed package review for Fedora and packages are built for f37/rawhide. It is also updated to the latest version, 1.7.3. (The ugly patch I used to get it to build shlibs in 1.6.6 is much prettier — if that's possible — in 1.7.3.) If anyone has any contacts at Apache that can get them to stop bundling dependencies that's be a big win in my book. > > > > I'm now preparing libarrow (Apache Arrow) for Fedora package review. As Casey noted in another email version 4.0.1 does not build with newer compilers, e.g. gcc-12 at least, maybe gcc-11 too, so I am working on packaging 7.0.0. > > > > Once I get libarrow submitted to package review I will circle back and update the versions of liborc and libarrow in CentOS Stream 8 (and Stream 9 too) to the latest. > > > > And longer term will get them and the other dependencies built in EPEL8 and EPEL9. > > > > > > On Fri, Jan 28, 2022 at 1:22 PM Casey Bodley <cbodley@xxxxxxxxxx> wrote: > >> > >> after discussion with our Debian/Ubuntu maintainers, we've decided > >> that Ceph will need to build arrow from a submodule for the quincy > >> release. both distros do provide the dependencies necessary for a > >> minimal build of arrow/parquet. i'm working through the cmake > >> integration of the arrow submodule in > >> https://github.com/ceph/ceph/pull/44696 > >> > >> for Centos, Kaleb has packaged arrow and its missing dependencies and > >> made them available in the Centos Storage SIG > >> (https://wiki.centos.org/SpecialInterestGroup/Storage). i'm a bit wary > >> about requiring that our Centos users install this additional repo via > >> 'yum install centos-release-ceph', though. the Storage SIG is also > >> going to host Centos' ceph release packages, so it may not a good idea > >> to mix those repos with our upstream download.ceph.com repo > >> > >> getting this stuff into EPEL would be ideal - even if it was just > >> enough to enable us to build the arrow submodule - but it sounds like > >> some obstacles remain here. what do people think about requiring this > >> extra centos-release-ceph repo for quincy? could that be acceptable as > >> a last resort? > >> > > > > > > -- > > > > Kaleb _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
