On 10-12-2015 16:03, Willem Jan Withagen wrote:
I have a failure in:
./unittest_erasure_code_shec_arguments
All tests befor this PASS. (other than rbd which is disabled to
the time being)
Which I traceback to code in ErasureCodeShec.cc
Line 218:
unsigned blocksize = (*chunks.begin()).seco
I have a failure in:
./unittest_erasure_code_shec_arguments
All tests befor this PASS. (other than rbd which is disabled to
the time being)
Which I traceback to code in ErasureCodeShec.cc
Line 218:
unsigned blocksize = (*chunks.begin()).second.length();
After a few iterations I get a "ne
On 8-12-2015 13:36, Mykola Golub wrote:
On Tue, Dec 08, 2015 at 11:04:13AM +0100, Willem Jan Withagen wrote:
On 4-12-2015 21:11, Willem Jan Withagen wrote:
One larger problem with libraries I have is the stuff with dlopen.
In ./configure it seems that most of the code is short-circuited, and -
On Tue, Dec 08, 2015 at 11:04:13AM +0100, Willem Jan Withagen wrote:
> On 4-12-2015 21:11, Willem Jan Withagen wrote:
>
> One larger problem with libraries I have is the stuff with dlopen.
>
> In ./configure it seems that most of the code is short-circuited, and -ldl
> gets appended in the Makefi
On 4-12-2015 21:11, Willem Jan Withagen wrote:
On 4-12-2015 19:44, Gregory Farnum wrote:
On Fri, Dec 4, 2015 at 10:30 AM, Willem Jan Withagen wrote:
On 3-12-2015 01:27, Yan, Zheng wrote:
On Thu, Dec 3, 2015 at 4:52 AM, Willem Jan Withagen wrote:
On 2-12-2015 15:13, Yan, Zheng wrote:
I se
On 4-12-2015 21:11, Willem Jan Withagen wrote:
One larger problem with libraries I have is the stuff with dlopen.
In ./configure it seems that most of the code is short-circuited, and -ldl
gets appended in the Makefile.am's by default. The code there is rather
hard
to parse.
FreeBSD has this
On 8-12-2015 01:29, Willem Jan Withagen wrote:
On 7-12-2015 23:19, Michal Jarzabek wrote:
Hi Willem,
If you look at line 411 and 412 you will have variables k and m
defined. They are not changed anywhere(I think), so the sizes must
be big enough. As Xinze mentioned just add const in front of it
On 7-12-2015 23:19, Michal Jarzabek wrote:
Hi Willem,
If you look at line 411 and 412 you will have variables k and m
defined. They are not changed anywhere(I think), so the sizes must be
big enough.
As Xinze mentioned just add const in front of it:
const int k = 12
const int m = 4
and it should
Hi Willem,
If you look at line 411 and 412 you will have variables k and m
defined. They are not changed anywhere(I think), so the sizes must be
big enough.
As Xinze mentioned just add const in front of it:
const int k = 12
const int m = 4
and it should fix the compile error.
buffer::ptr enc[k +
On 5-12-2015 14:02, Xinze Chi (信泽) wrote:
I think "const int k = 12; const int m = 4" would pass the compile?
Are these sizes big enough??
--WjW
2015-12-05 20:56 GMT+08:00 Willem Jan Withagen :
src/test/erasure-code/TestErasureCodeIsa.cc
contains snippets, function definition like:
buffe
I think "const int k = 12; const int m = 4" would pass the compile?
2015-12-05 20:56 GMT+08:00 Willem Jan Withagen :
> src/test/erasure-code/TestErasureCodeIsa.cc
>
> contains snippets, function definition like:
>
> buffer::ptr enc[k + m];
> // create buffers with a copy of the original data to
src/test/erasure-code/TestErasureCodeIsa.cc
contains snippets, function definition like:
buffer::ptr enc[k + m];
// create buffers with a copy of the original data to be able to
compare it after decoding
{
for (int i = 0; i < (k + m); i++) {
Clang refuses because the [k+m] size in not
On 4-12-2015 19:44, Gregory Farnum wrote:
> On Fri, Dec 4, 2015 at 10:30 AM, Willem Jan Withagen wrote:
>> On 3-12-2015 01:27, Yan, Zheng wrote:
>>> On Thu, Dec 3, 2015 at 4:52 AM, Willem Jan Withagen
>>> wrote:
On 2-12-2015 15:13, Yan, Zheng wrote:
>>
I see that you have disabled uuid
On Fri, Dec 4, 2015 at 10:30 AM, Willem Jan Withagen wrote:
> On 3-12-2015 01:27, Yan, Zheng wrote:
>> On Thu, Dec 3, 2015 at 4:52 AM, Willem Jan Withagen wrote:
>>> On 2-12-2015 15:13, Yan, Zheng wrote:
>
>>> I see that you have disabled uuid?
>>> Might I ask why?
>>
>> not disable. Currently ce
On 3-12-2015 01:27, Yan, Zheng wrote:
> On Thu, Dec 3, 2015 at 4:52 AM, Willem Jan Withagen wrote:
>> On 2-12-2015 15:13, Yan, Zheng wrote:
>> I see that you have disabled uuid?
>> Might I ask why?
>
> not disable. Currently ceph uses boost uuid implementation. so no need
> to link to libuuid.
On Thu, Dec 3, 2015 at 1:50 AM, Willem Jan Withagen wrote:
> On 2-12-2015 22:10, Willem Jan Withagen wrote:
>
>> Running gmake check
>
>
> Now I start wondering how long certain tests are able to run:
>
> I've killed:
> unittest_chain_xattr
> because it was running already voor 12 hours.
On 3-12-2015 10:50, Willem Jan Withagen wrote:
On 2-12-2015 22:10, Willem Jan Withagen wrote:
Running gmake check
Now I start wondering how long certain tests are able to run:
I've killed:
unittest_chain_xattr
because it was running already voor 12 hours.
And unittest_lfnindex is also
On 3-12-2015 13:34, Mykola Golub wrote:
> On Wed, Dec 02, 2015 at 11:47:04PM +0100, Willem Jan Withagen wrote:
>>
>> Running gmake check is starting to work.
>> reporting still thinks there are no successful tests
>> but tests themselves report OKE
>>
>> But where I really can not get it
On Wed, Dec 02, 2015 at 11:47:04PM +0100, Willem Jan Withagen wrote:
>
> Running gmake check is starting to work.
> reporting still thinks there are no successful tests
> but tests themselves report OKE
>
> But where I really can not get it to work is with testing rbd.
>
> Is starts
On 2-12-2015 22:10, Willem Jan Withagen wrote:
Running gmake check
Now I start wondering how long certain tests are able to run:
I've killed:
unittest_chain_xattr
because it was running already voor 12 hours.
And unittest_lfnindex is also running for > 20 minutes
Is there a way
On Thu, Dec 3, 2015 at 4:52 AM, Willem Jan Withagen wrote:
> On 2-12-2015 15:13, Yan, Zheng wrote:
>> see https://github.com/ceph/ceph/pull/6770. The code can be compiled
>> on FreeBSD/OSX, most client programs can connect to ceph servers on
>> Linux.
>
> Hi,
>
> I do like some of the inline compi
Running gmake check is starting to work.
reporting still thinks there are no successful tests
but tests themselves report OKE
But where I really can not get it to work is with testing rbd.
Is starts with the simple:
/bin/sh: rbd: not found
And whatever I'm trying in co
On 1-12-2015 19:51, Willem Jan Withagen wrote:
> On 1-12-2015 17:24, Willem Jan Withagen wrote:
>> I think in the short run it will not be the code that is going to be a
>> major porting pain. But getting the run-time environment ironed out is
>> just plain (hard) work. Things where /bin/sh expects
On 2-12-2015 15:13, Yan, Zheng wrote:
> see https://github.com/ceph/ceph/pull/6770. The code can be compiled
> on FreeBSD/OSX, most client programs can connect to ceph servers on
> Linux.
Hi,
I do like some of the inline compiler tests.
I guess that the way the errno's are done like the other OS
see https://github.com/ceph/ceph/pull/6770. The code can be compiled
on FreeBSD/OSX, most client programs can connect to ceph servers on
Linux.
Regards
Yan. Zheng
On Wed, Dec 2, 2015 at 2:43 AM, Willem Jan Withagen wrote:
> On 1-12-2015 19:36, Sage Weil wrote:
>>
>> On Tue, 1 Dec 2015, Alan Some
On 1-12-2015 17:24, Willem Jan Withagen wrote:
I think in the short run it will not be the code that is going to be a
major porting pain. But getting the run-time environment ironed out is
just plain (hard) work. Things where /bin/sh expects certain bash-isms.
Where paths have not been setup to t
On 1-12-2015 19:36, Sage Weil wrote:
On Tue, 1 Dec 2015, Alan Somers wrote:
On Tue, Dec 1, 2015 at 11:08 AM, Willem Jan Withagen wrote:
On 1-12-2015 18:22, Alan Somers wrote:
I did some work porting Ceph to FreeBSD, but got distracted and
stopped about two years ago. You may find this port
On 1-12-2015 19:21, Alan Somers wrote:
On Tue, Dec 1, 2015 at 11:08 AM, Willem Jan Withagen wrote:
On 1-12-2015 18:22, Alan Somers wrote:
I did some work porting Ceph to FreeBSD, but got distracted and
stopped about two years ago. You may find this port useful, though it
will probably need t
On Tue, 1 Dec 2015, Alan Somers wrote:
> On Tue, Dec 1, 2015 at 11:08 AM, Willem Jan Withagen wrote:
> > On 1-12-2015 18:22, Alan Somers wrote:
> >>
> >> I did some work porting Ceph to FreeBSD, but got distracted and
> >> stopped about two years ago. You may find this port useful, though it
> >>
On Tue, Dec 1, 2015 at 11:08 AM, Willem Jan Withagen wrote:
> On 1-12-2015 18:22, Alan Somers wrote:
>>
>> I did some work porting Ceph to FreeBSD, but got distracted and
>> stopped about two years ago. You may find this port useful, though it
>> will probably need to be updated:
>>
>> https://pe
On 1-12-2015 18:22, Alan Somers wrote:
I did some work porting Ceph to FreeBSD, but got distracted and
stopped about two years ago. You may find this port useful, though it
will probably need to be updated:
https://people.freebsd.org/~asomers/ports/net/ceph/
I'll chcek that one as well...
A
On Tue, Dec 1, 2015 at 9:24 AM, Willem Jan Withagen wrote:
> On 1-12-2015 15:35, Sage Weil wrote:
>>
>> On Tue, 1 Dec 2015, Willem Jan Withagen wrote:
>>>
>>> On 1-12-2015 14:30, Sage Weil wrote:
On Tue, 1 Dec 2015, Willem Jan Withagen wrote:
>
> On 30-11-2015 14:21, Sage Weil wr
On 1-12-2015 15:35, Sage Weil wrote:
On Tue, 1 Dec 2015, Willem Jan Withagen wrote:
On 1-12-2015 14:30, Sage Weil wrote:
On Tue, 1 Dec 2015, Willem Jan Withagen wrote:
On 30-11-2015 14:21, Sage Weil wrote:
The problem with all of the porting code in general is that it is doomed
to break later
On Tue, 1 Dec 2015, Willem Jan Withagen wrote:
> On 1-12-2015 14:30, Sage Weil wrote:
> > On Tue, 1 Dec 2015, Willem Jan Withagen wrote:
> > > On 30-11-2015 14:21, Sage Weil wrote:
> > > > The problem with all of the porting code in general is that it is doomed
> > > > to break later on if we don't
On 1-12-2015 14:30, Sage Weil wrote:
On Tue, 1 Dec 2015, Willem Jan Withagen wrote:
On 30-11-2015 14:21, Sage Weil wrote:
The problem with all of the porting code in general is that it is doomed
to break later on if we don't have (at least) ongoing build tests. In
order for a FreeBSD or OSX po
On Tue, 1 Dec 2015, Willem Jan Withagen wrote:
> On 30-11-2015 14:21, Sage Weil wrote:
> > The problem with all of the porting code in general is that it is doomed
> > to break later on if we don't have (at least) ongoing build tests. In
> > order for a FreeBSD or OSX port to continue working we n
On 1-12-2015 13:22, Mykola Golub wrote:
On Tue, Dec 01, 2015 at 10:42:57AM +0100, Willem Jan Withagen wrote:
On 30-11-2015 17:20, Gregory Farnum wrote:
Installed the results:
gmake install
And looked at what it delivered:
zfs diff
And I have to be honest that I'm not really enjoying
On Tue, Dec 01, 2015 at 10:42:57AM +0100, Willem Jan Withagen wrote:
> On 30-11-2015 17:20, Gregory Farnum wrote:
> >>Installed the results:
> >>gmake install
> >>
> >>And looked at what it delivered:
> >> zfs diff
> >>
> >>And I have to be honest that I'm not really enjoying all the ceph-
On 30-11-2015 14:21, Sage Weil wrote:
The problem with all of the porting code in general is that it is doomed
to break later on if we don't have (at least) ongoing build tests. In
order for a FreeBSD or OSX port to continue working we need VMs that run
either gitbuilder or a jenkins job or simi
On 30-11-2015 17:20, Gregory Farnum wrote:
Installed the results:
gmake install
And looked at what it delivered:
zfs diff
And I have to be honest that I'm not really enjoying all the ceph-test
stuff in my /usr/local/bin
Would prefer it to go into something like:
/usr/loca
On Mon, Nov 30, 2015 at 11:04 AM, Willem Jan Withagen wrote:
> On 30-11-2015 15:40, Willem Jan Withagen wrote:
>> On 30-11-2015 15:13, Mykola Golub wrote:
>>> On Mon, Nov 30, 2015 at 12:53:54PM +0100, Willem Jan Withagen wrote:
>>>
> git clone --recursive -b wip-freebsd https://github.com/troc
On 30-11-2015 15:40, Willem Jan Withagen wrote:
> On 30-11-2015 15:13, Mykola Golub wrote:
>> On Mon, Nov 30, 2015 at 12:53:54PM +0100, Willem Jan Withagen wrote:
>>
git clone --recursive -b wip-freebsd https://github.com/trociny/ceph.git
cd ceph
./install-deps.sh
./do_autogen.s
On 30-11-2015 15:13, Mykola Golub wrote:
> On Mon, Nov 30, 2015 at 12:53:54PM +0100, Willem Jan Withagen wrote:
>
>>> git clone --recursive -b wip-freebsd https://github.com/trociny/ceph.git
>>> cd ceph
>>> ./install-deps.sh
>>> ./do_autogen.sh
>>> gmake
>>> cd src
>>> ./vstart.sh # start dev clus
On 30-11-2015 15:13, Mykola Golub wrote:
> On Mon, Nov 30, 2015 at 12:53:54PM +0100, Willem Jan Withagen wrote:
>
>>> git clone --recursive -b wip-freebsd https://github.com/trociny/ceph.git
>>> cd ceph
>>> ./install-deps.sh
>>> ./do_autogen.sh
>>> gmake
>>> cd src
>>> ./vstart.sh # start dev clus
On Mon, Nov 30, 2015 at 12:53:54PM +0100, Willem Jan Withagen wrote:
> > git clone --recursive -b wip-freebsd https://github.com/trociny/ceph.git
> > cd ceph
> > ./install-deps.sh
> > ./do_autogen.sh
> > gmake
> > cd src
> > ./vstart.sh # start dev cluster
> > ./ceph -s # check it works
> >
>
>
On 30-11-2015 14:21, Sage Weil wrote:
> The problem with all of the porting code in general is that it is doomed
> to break later on if we don't have (at least) ongoing build tests. In
> order for a FreeBSD or OSX port to continue working we need VMs that run
> either gitbuilder or a jenkins jo
The problem with all of the porting code in general is that it is doomed
to break later on if we don't have (at least) ongoing build tests. In
order for a FreeBSD or OSX port to continue working we need VMs that run
either gitbuilder or a jenkins job or similar so that we can tell when it
brea
On 30-11-2015 07:58, Mykola Golub wrote:
> On Mon, Nov 30, 2015 at 11:46:27AM +0800, Yan, Zheng wrote:
>> On Mon, Nov 30, 2015 at 2:57 AM, Willem Jan Withagen
>> wrote:
...
Hi Mykola,
> I have a branch in my repo that contains patches to make compilation
> on FreeBSD easier:
>
> https://github
On Mon, Nov 30, 2015 at 11:46:27AM +0800, Yan, Zheng wrote:
> On Mon, Nov 30, 2015 at 2:57 AM, Willem Jan Withagen wrote:
> >
> > On 29-11-2015 19:08, Haomai Wang wrote:
> >
> > > I guess we still expect FreeBSD support, which version do you test to
> > > compile? I'd like to help to make bsd work
On Mon, Nov 30, 2015 at 2:57 AM, Willem Jan Withagen wrote:
>
> On 29-11-2015 19:08, Haomai Wang wrote:
>
> > I guess we still expect FreeBSD support, which version do you test to
> > compile? I'd like to help to make bsd work :-)
>
> I considered it is best to develop against HEAD aka:
> 11.0-CUR
On 29-11-2015 19:08, Haomai Wang wrote:
> I guess we still expect FreeBSD support, which version do you test to
> compile? I'd like to help to make bsd work :-)
I considered it is best to develop against HEAD aka:
11.0-CURRENT FreeBSD 11.0-CURRENT #0 r291381: Sat Nov 28 14:22:54 CET 2015
I'm also
On Mon, Nov 30, 2015 at 1:44 AM, Willem Jan Withagen wrote:
> Hi,
>
> Not unlike many others running FreeBSD I'd like to see if I/we can get
> Ceph to build and run on FreeBSD. If not all components than at least
> certain components.
>
> With compilation I do get quite some way, even with the CLA
52 matches
Mail list logo
