Hi Thomas, I don't really have the time to help maintaining it, sorry. But regarding ceph for 32bit: please drop it. It might compile, but it's not supported by upstream and as long as you can't run the full test suite it doesn't make sense to risk it. Last time I've checked it there were lots assumptions on 64bit in the code that were not even detected by the compiler on 32bit. It will also save you a lot of work... Bernd 28.09.2023 09:11:32 Thomas Goirand <zigo@xxxxxxxxxx>: > On 9/27/23 17:05, Gregory Farnum wrote: >> Also, I’d like to connect you and Thomas, who has been working on >> Debian builds in irc again and maintains Ceph packages in Debian >> proper. >> -Greg > > Hi there! > > Thanks Gregory for getting in touch. > > I also CC-ed Bzed, who's co-maintaining Ceph with me (even though I was alone for the last 2 years or so, I still have hope that Bzed helps). > > My mission is probably a bit different from what Matthew is doing. Trying to maintain Ceph in Debian has to be done in Unstable/Testing, which is a way more challenging than building for one's own unofficial backport repository for amd64 alone. For example, I'm currently fighting to get Ceph Pacific fixed for SID and RiscV (we believe we have a solution for it, ie: using -latomic). See here, it still doesn't build: > https://buildd.debian.org/status/package.php?p=ceph&suite=sid > > At the same time, I'm trying to get Reef to build in Experimental: > https://buildd.debian.org/status/package.php?p=ceph&suite=experimental > > As you may see, it currently fails under all 32 bits arch. The issue is, we need Ceph for these arch too, so that Qemu can be built against librbd, otherwise all 32 bits arch wont get RBD support. Lucky, Mipsel was removed, so at least, we have 3GB of RAM to build, not 2. > > I'm not so much interested in packaging in non-official Debian, or even upstream. In fact, I'd be for removing the Debian folder from the Ceph upstream master branch, as this is causing issues on the downstream distributions (ie: I have to remove the debian folder from the orig tarball). Best would be if we could all (wikimedia, Ubuntu, Debian) share the same packaging branch on top of master or stable branches of Ceph, and somehow build a CI to automatically build packages. I have enough experience to write such a CI (which I do already for OpenStack). Though it'd probably be nicer to have this done in the upstream infrastructure, so that we could build Debian and Ubuntu packages for stable AND unstable (Ubuntu/Debian, but also Ceph), aso we see things break. > > My Debian packaging is also a way more Debian policy compliant than what I saw from upstream. For example, I noticed that during the build, Ceph build Arrow, which in its turn, download xsimd (and of course, downloading at build time is strictly forbidden in Debian), so I had to add "extraopts += -DWITH_RADOSGW_SELECT_PARQUET=OFF" until we get arrow properly packaged in Debian. I also fixed many of the things you fixed in the merge request from this week-end. > > I very much would love to get more help on the packaging, and do it with you Matthew. Note that I already work with Arturo Borrero Gonzalez from Wikimedia as well, as I am also the package maintainer for all things OpenStack (which is why I am interested in Ceph). > > My current plan is to finish the packaging of Ceph Reef in Experimental, which means, make it build for all arch in the Debian buildd, before opening a transition bug to the release team and upload to Unstable (at which point, the advise is to attempt rebuilding all reverse depends and file bugs as necessary). Once the package reaches Unstable, and then Testing/Trixie, I want to also upload Reef to official bookworm-backports. > > Our current production plan is to run Ceph on bookworm+arm64 for a new region of our public cloud. Hopefully, this can be done on Reef, using the official bookworm backports I described above. I can forecast a lot of fun testing all that in a real production environment... :) > FYI, we want to use HPE's RL300 servers (though if anyone has other suggestions for ARM hardware and Ceph, please let me know). > > The Ceph packaging is maintained in Salsa, like almost all of Debian: > > https://salsa.debian.org/ceph-team/ceph/ > > There's also a lot of work that should be done in order to de-embed many of the Ceph included libraries: > - jerasure + isal (I already packaged this in Debian) > - arrow (there's a start of a package from the Debian science team [1]) > - uring (Ceph Reef currently fails with the Debian version) > - boost (same thing... we need to transition to 1.8.2 in Unstable) > > This is a lot of work, and really, too much for only myself, who's also in charge of OpenStack, OpenVSwitch/OVN, RabbitMQ, and many more in Debian. > > So, Matthew, would you like to do packaging with me directly in Debian? If so, I warmly welcome you in the #debian-openstack IRC channel in OFTC if you would like to kickstart this (or we continue by email if you prefer). > > Cheers, > > Thomas Goirand (zigo) > > [1] See https://bugs.debian.org/970021 and https://salsa.debian.org/science-team/arrow > This start of packaging would need to be upgraded to version 9.0.0 *at least* (we got to figure out if Ceph can cope with an even newer version), and must make sure it doesn't download xsimd at build time. Probably, some of the arrow (build-)depends should also be packaged separately. > > P.S: I'm not registered to this list (I'm registered to a way too many lists...), so please do CC me. _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
