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 Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
