Thanks for that, ubuntu has it building for all
arches, they have
patches for 32bit and arm in the patches directory here:
<http://archive.ubuntu.com/ubuntu/pool/main/c/ceph/ceph_15.2.5-0ubuntu1.1.debian.tar.xz>
On 23 Nov 2020, at 08:48, Vladimir Bashkirtsev
<vladimir(a)bashkirtsev.com <mailto:vladimir@bashkirtsev.com>> wrote:
I doubt that Cypress will build necessary stuff. Much faster:
diff
-uNr ceph-15.2.4/src/pybind/mgr/dashboard/frontend/package.json ceph-15.2.4-arm32_fix/src/pybind/mgr/dashboard/frontend/package.json
--- ceph-15.2.4/src/pybind/mgr/dashboard/frontend/package.json
2020-07-01 01:10:51.000000000 +0930
+++ ceph-15.2.4-arm32_fix/src/pybind/mgr/dashboard/frontend/package.json
2020-11-21 22:11:16.065796889 +1030
@@ -122,7 +122,6 @@
"@types/node": "12.12.34",
"@types/simplebar": "5.1.1",
"codelyzer": "5.2.2",
- "cypress": "4.4.0",
"html-linter": "1.1.1",
"htmllint-cli": "0.0.7",
"jest": "25.2.4",
On 23/11/20 7:37 pm, Duncan Bellamy wrote:
> Thanks for the info, I have opened an issue about it on cypress github:
>
https://github.com/cypress-io/cypress/issues/9272
> <https://github.com/cypress-io/cypress/issues/9272>
>
> I don’t think the alpine build is running the test suite, cypress is
> installed and for the test step it does a cd into the build
> directory and runs “ctest” but looking at the build logs and
> searching for “ctest” returns 0 results.
>
> Duncan
>
>> On 22 Nov 2020, at 23:18, Vladimir
>> Bashkirtsev <vladimir(a)bashkirtsev.com> wrote:
>>
>> There no cypress for ARM 32 bit at all. As it is used just for
>> testing I have removed it from package.json and then dropped
>> relevant test to avoid test failure. Not the best solution
>> but because I do build 64 bits as well I can sleep relatively
>> easy knowing that it should work. Node is used to create
>> mgr frontend and it should generate pretty much the same
>> JS regardless of architecture.
>>
>> Explicit use of cypress also tells me that 32 bit support was
>> dropped by Ceph silently. But I can say that after some patching
>> ceph does pass full test suite on armv7l. I will provide them as
>> PRs soon - hopefully they will be accepted and Ceph will run on
>> 32 bits again.
>>
>> On 23 November 2020 4:01:18 am AEDT, Duncan Bellamy
>> <a.16bit.sysop(a)icloud.com> wrote:
>> I have been updating the Alpine Linux version to 15.2.6 and it
>> fails on armv7 and x86 because cypress install fails with not
>> found, how did you get cypress to work on arm 32bit?
>>
>> Duncan
>>
>>> On 22 Nov 2020, at 08:49, Vladimir Bashkirtsev
>>> <vladimir(a)bashkirtsev.com> wrote:
>>>
>>>
>>> Yeah, that's exactly because of this document I am kinda
>>> wondering. This document is latest dev and thus one may expect
>>> that 32 bits builds are still a thing. But after I have
>>> went through considerable effort building it on 32 bit ARM I am
>>> sure that current Ceph release is not buildable out of the box.
>>> Say in options.h Options::size_t (notion of SIZE option)
>>> uses std::size_t (largest counter available - 32 bits on 32 bit
>>> arches) as store of value. It automatically implies that smoke.sh
>>> test which tries to create 100G OSD fails as 100G value just does
>>> not fit into 32 bits and trimmed to become just 0 (zero). And the
>>> same story with other SIZE options which may exceed 2^32.
>>> So clearly Ceph in its current form cannot pass testing on 32 bit
>>> systems making me think that 32 bit target was silently dropped at
>>> some point.
>>>
>>> On 22/11/20 7:39 pm, Yuval Lifshitz wrote:
>>>> I don't know if it is built and tested regularly on 32bit
>>>> arch, but according to this:
>>>>
https://docs.ceph.com/en/latest/dev/release-process/
>>>> 32bit arch is a valid target for ceph.
>>>>
>>>> On Sun, Nov 22, 2020 at 10:30 AM Vladimir
>>>> Bashkirtsev <vladimir(a)bashkirtsev.com> wrote:
>>>> Hi Yuval,
>>>>
>>>>
>>>>
>>>> Thank you for pointing me into right direction. I am planning
>>>> to provide PRs as I already have relevant patches.
>>>>
>>>>
>>>>
>>>> BTW: am I right in my thinking that Ceph no longer does building
>>>> and testing on 32 bit architectures?
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Vladimir
>>>>
>>>> On 22/11/20 7:18 pm, Yuval Lifshitz wrote:
>>>>> Hi Vladimir,
>>>>> We use PRs to github for code contributions to Ceph. For
>>>>> more details see here: [1].
>>>>> If you find issues that need fixing, but you don't plan
>>>>> on fixing right away you can open tracker issues here [2].
>>>>>
>>>>> Yuval
>>>>>
>>>>> [1]
https://github.com/ceph/ceph/blob/master/SubmittingPatches.rst
>>>>> [2]
https://tracker.ceph.com/projects
>>>>>
>>>>> On Sun, Nov 22, 2020 at 5:45 AM Vladimir Bashkirtsev
>>>>> <vladimir(a)bashkirtsev.com> wrote:
>>>>> Hi all,
>>>>>
>>>>>
>>>>> Over last few weeks I was working on making Ceph 15.2.4 to build
>>>>> and run
>>>>> on ARM 32 bit system. It appears that Ceph no longer supports 32
>>>>> bit
>>>>> systems. But I wanted to run it on Odroid HC-2 which makes a
>>>>> very good
>>>>> cheap OSD basically turning SATA disk into ethernet enabled
>>>>> disk. So I
>>>>> stuck my teeth into getting current Ceph up and running on 32 bit
>>>>> architecture. While doing so I have encountered number of bugs
>>>>> in Ceph
>>>>> codebase which I now want to put back for everyone to use.
>>>>>
>>>>> For example I found a bug in EC code which attempts to malloc
>>>>> around 4GB
>>>>> - this bug is not noticeable on 64 bit systems as malloc happily
>>>>> allocates 4GB but it of course failed on 32 bit system and
>>>>> digging into
>>>>> the issue shown that this malloc was just a bug - it should not be
>>>>> happening at all in the first place.
>>>>>
>>>>> Or wrong include (.cc instead of .h) which caused compilation hard
>>>>> error. Or python threading timeout was specified as int while it
>>>>> should
>>>>> be a float and basically timeout was not happening. And so on.
>>>>> Small
>>>>> inaccuracies peppered around code base. It is certainly should
>>>>> not be
>>>>> done as one huge patch and I am happy to put these patches one
>>>>> by one.
>>>>> But which way it should be done? As number of PR requests on
>>>>> github? Or
>>>>> patch files emailed to someone?
>>>>>
>>>>> May someone from the list enlighten me on acceptable procedure I
>>>>> need to
>>>>> follow?
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Vladimir
>>>>> _______________________________________________
>>>>> Dev mailing list -- dev(a)ceph.io
>>>>> To unsubscribe send an email to dev-leave(a)ceph.io
>>>>>
>>> _______________________________________________
>>> Dev mailing list -- dev(a)ceph.io
>>> To unsubscribe send an email to dev-leave(a)ceph.io
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>