Bug#907123: ceph 14.2.4 in unstable
On 12/30/19 4:09 AM, Milan Kupcevic wrote: > I've seen BeagleBone Black and Raspberry Pi mini cluster setups used in > classroom environment for educational purposes. We should provide them, > if possible. > > As for failing builds on arm architectures it probably does not make > sense to push for ARM NEON on armel as it targets hardware with no float > acceleration. Debian's target on armel is --with-arch=armv5te > --with-float=soft. Even if we'd patch the build process to detect armel properly, I'd assume it would fail with the same issue as armhf - see below. > On the other hand the armhf arch on Debian is specifically targeting > hardware with float acceleration. Default target is --with-arch=armv7-a > --with-fpu=vfpv3-d16 --with-float=hard. NEON is more likely to be > available on this one. > > NEON is safely available on arm64, aarch64-linux-gnu > > See https://en.wikipedia.org/wiki/ARM_architecture#Advanced_SIMD_(NEON) > for more info. yes, armhf builds much further with clang than with gcc and does not complain about NEON, but it fails with [ 60%] Building CXX object src/rgw/CMakeFiles/rgw_common.dir/services/svc_zone.cc.o cd /<>/obj-arm-linux-gnueabihf/src/rgw && /usr/bin/clang++ -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D__linux__ -I/<>/obj-arm-linux-gnueabihf/src/include -I/<>/src -I/usr/include/nss -I/usr/include/nspr -I/<>/src/dmclock/support/src -isystem /<>/obj-arm-linux-gnueabihf/include -isystem /<>/src/xxHash -isystem /<>/src/rapidjson/include -isystem /<>/src/rgw/services -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wtype-limits -Wignored-qualifiers -Winit-self -Wpointer-arith -Werror=format-security -fno-strict-aliasing -fsigned-char -Wno-unknown-pragmas -Wno-unused-function -Wno-unused-local-typedef -Wno-varargs -Wno-gnu-designator -Wno-missing-braces -Wno-parentheses -Wno-deprecated-register -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -ftemplate-depth-1024 -Wnon-virtual-dtor -Wno-unknown-pragmas -Wno-ignored-qualifiers -Wno-inconsistent-missing-override -Wno-mismatched-tags -Wno-unused-private-field -Wno-address-of-packed-member -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -fPIC -DHAVE_CONFIG_H -D__CEPH__ -D_REENTRANT -D_THREAD_SAFE -D__STDC_FORMAT_MACROS -std=c++17 -o CMakeFiles/rgw_common.dir/services/svc_zone.cc.o -c /<>/src/rgw/services/svc_zone.cc In file included from /<>/src/rgw/services/svc_zone.cc:7: /<>/src/rgw/rgw_rest_conn.h:441:28: error: template parameter redefines default argument template ^ /<>/src/rgw/rgw_rest_conn.h:437:32: note: previous default template argument defined here template ^ Which is clearly not valid in c++, but gcc accepts it. Also I'm not motivated to create patches to make ceph build with clang and maintain them... So I think for now mipsel, armel and armhf have to go. I've opened a bug against gcc: #947751 So if nobody is going to stop me, I'll remove mipsel, armel and armhf for now. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#907123: ceph 14.2.4 in unstable
On 2019-12-27 16:14, Thomas Goirand wrote: > On 12/26/19 1:49 AM, Bernd Zeimetz wrote: >> Hi Milan, >> >> I gave you access to the salsa team as requested. Sounds good. >> >> Please coordinate what you want to work on with Thomas (zigo@d.o) and me. >> >> Right now things like arch-all and various architectures do not build at >> all.. I think we might even need to drop some as they just don't have >> enough memory for whatever gcc/g++ is doing there. >> >> Bernd > > Hi Bernd, > > Thanks a lot for your work. > > I'd be IMO fine if we drop armel, armhf and mipsel, for the server side > of things. I don't see how one could reliable setup a cluster with this > type of CPUs in production anyway. > I've seen BeagleBone Black and Raspberry Pi mini cluster setups used in classroom environment for educational purposes. We should provide them, if possible. As for failing builds on arm architectures it probably does not make sense to push for ARM NEON on armel as it targets hardware with no float acceleration. Debian's target on armel is --with-arch=armv5te --with-float=soft. On the other hand the armhf arch on Debian is specifically targeting hardware with float acceleration. Default target is --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard. NEON is more likely to be available on this one. NEON is safely available on arm64, aarch64-linux-gnu See https://en.wikipedia.org/wiki/ARM_architecture#Advanced_SIMD_(NEON) for more info. Milan signature.asc Description: OpenPGP digital signature
Bug#907123: ceph 14.2.4 in unstable
On 12/29/19 11:27 PM, Thomas Goirand wrote: > On 12/28/19 2:23 PM, Bernd Zeimetz wrote: >> Hi, >> >>> I'd be IMO fine if we drop armel, armhf and mipsel, for the server side >>> of things. I don't see how one could reliable setup a cluster with this >>> type of CPUs in production anyway. >> >> ack. >> >> >>> But IMO, it'd be nice if we could at least keep the client side working. >>> I'm not sure how to achieve this though, probably this will make the >>> build a lot more complicated. >> >> If you are keen on trying this, go on. I don't have enough spare time to >> care of it. Might make sense to open an upstream bug report about it, >> though. Supporting a client-only build should come from them imho, you >> never know how the build system will change and if it is possible to >> keep up support for it. >> Which parts of the client side are you interested in? >> I could imagine that building cephfs alone is possible. > > I think it'd be nice if we could have at least: > - cephfs > - librbd (so that Qemu could be built with it) > > So, more or less, this means all the Package: lib*, no? I'm building it with clang on those architectures now, seems it does not need as much memory as gcc. Mightmake sense to file a bug against gcc... >>> BTW, any idea what dependency is missing in mips64el? >> >> https://buildd.debian.org/status/package.php?p=ceph >> Dependency installability problem for ceph on mips64el: >> ceph build-depends on missing: >> - libboost-context-dev:mips64el (>= 1.67.0) >> >> (like on various other architectures) > > The buildd status page says it's currently in "building" status for the > release -6 you've uploaded. So probably this has been solved. Let's see > then! :) -5 already built well on mips64el (and showed some more issues on the -ports arches, I've fixed as many as I could without having to debug this properly on a porter box. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#907123: ceph 14.2.4 in unstable
On 12/28/19 2:23 PM, Bernd Zeimetz wrote: > Hi, > >> I'd be IMO fine if we drop armel, armhf and mipsel, for the server side >> of things. I don't see how one could reliable setup a cluster with this >> type of CPUs in production anyway. > > ack. > > >> But IMO, it'd be nice if we could at least keep the client side working. >> I'm not sure how to achieve this though, probably this will make the >> build a lot more complicated. > > If you are keen on trying this, go on. I don't have enough spare time to > care of it. Might make sense to open an upstream bug report about it, > though. Supporting a client-only build should come from them imho, you > never know how the build system will change and if it is possible to > keep up support for it. > Which parts of the client side are you interested in? > I could imagine that building cephfs alone is possible. I think it'd be nice if we could have at least: - cephfs - librbd (so that Qemu could be built with it) So, more or less, this means all the Package: lib*, no? >> BTW, any idea what dependency is missing in mips64el? > > https://buildd.debian.org/status/package.php?p=ceph > Dependency installability problem for ceph on mips64el: > ceph build-depends on missing: > - libboost-context-dev:mips64el (>= 1.67.0) > > (like on various other architectures) The buildd status page says it's currently in "building" status for the release -6 you've uploaded. So probably this has been solved. Let's see then! :) Cheers, Thomas Goirand (zigo)
Bug#907123: ceph 14.2.4 in unstable
On 12/28/19 2:23 PM, Bernd Zeimetz wrote: >> BTW, any idea what dependency is missing in mips64el? > > https://buildd.debian.org/status/package.php?p=ceph > Dependency installability problem for ceph on mips64el: > ceph build-depends on missing: > - libboost-context-dev:mips64el (>= 1.67.0) > > (like on various other architectures) commit e88fc2171efcf034cffc56c00cd7deb79d490f25 Author: Bernd Zeimetz Date: Sat Dec 28 15:53:19 2019 +0100 Set -DWITH_BOOST_CONTEXT=OFF where necessary. [!s390x !mips64el !ia64 !m68k !ppc64 !riscv64 !sh4 !sparc64 !x32] -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#907123: ceph 14.2.4 in unstable
Hi, > I'd be IMO fine if we drop armel, armhf and mipsel, for the server side > of things. I don't see how one could reliable setup a cluster with this > type of CPUs in production anyway. ack. > But IMO, it'd be nice if we could at least keep the client side working. > I'm not sure how to achieve this though, probably this will make the > build a lot more complicated. If you are keen on trying this, go on. I don't have enough spare time to care of it. Might make sense to open an upstream bug report about it, though. Supporting a client-only build should come from them imho, you never know how the build system will change and if it is possible to keep up support for it. Which parts of the client side are you interested in? I could imagine that building cephfs alone is possible. > BTW, any idea what dependency is missing in mips64el? https://buildd.debian.org/status/package.php?p=ceph Dependency installability problem for ceph on mips64el: ceph build-depends on missing: - libboost-context-dev:mips64el (>= 1.67.0) (like on various other architectures) Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#907123: ceph 14.2.4 in unstable
On 12/26/19 1:49 AM, Bernd Zeimetz wrote: > Hi Milan, > > I gave you access to the salsa team as requested. > > Please coordinate what you want to work on with Thomas (zigo@d.o) and me. > > Right now things like arch-all and various architectures do not build at > all.. I think we might even need to drop some as they just don't have > enough memory for whatever gcc/g++ is doing there. > > Bernd Hi Bernd, Thanks a lot for your work. I'd be IMO fine if we drop armel, armhf and mipsel, for the server side of things. I don't see how one could reliable setup a cluster with this type of CPUs in production anyway. But IMO, it'd be nice if we could at least keep the client side working. I'm not sure how to achieve this though, probably this will make the build a lot more complicated. BTW, any idea what dependency is missing in mips64el? Thomas Goirand (zigo)
Bug#907123: ceph 14.2.4 in unstable
Hi Milan, I gave you access to the salsa team as requested. Please coordinate what you want to work on with Thomas (zigo@d.o) and me. Right now things like arch-all and various architectures do not build at all.. I think we might even need to drop some as they just don't have enough memory for whatever gcc/g++ is doing there. Bernd On 12/25/19 6:34 PM, Milan Kupcevic wrote: > On 2019-12-24 08:40, Bernd Zeimetz wrote: >> Version: 14.2.4-1 >> >> Hi, >> >> ceph 14.2.4 is in unstable. > > > This is a great news. > > >> Maintaining two different versions of ceph is absolutely a no-go. There >> are not even enough ressources to maintain one version as well as it >> should be. > > > I agree. > > >> >> What will happen - after ceph migrated to testing - is a backport to buster. >> > > > Excellent. > > >> If you want to help, please test hte packages and look into build issues. >> > > > I will look into it. > > > Could you please push the uploaded version commits to the package salsa > repository? > > > Milan > -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#907123: ceph 14.2.4 in unstable
On 2019-12-24 08:40, Bernd Zeimetz wrote: > Version: 14.2.4-1 > > Hi, > > ceph 14.2.4 is in unstable. This is a great news. > Maintaining two different versions of ceph is absolutely a no-go. There > are not even enough ressources to maintain one version as well as it > should be. I agree. > > What will happen - after ceph migrated to testing - is a backport to buster. > Excellent. > If you want to help, please test hte packages and look into build issues. > I will look into it. Could you please push the uploaded version commits to the package salsa repository? Milan
