Help in testing Basho Riak port

Bryan Drewery bryan at shatow.net
Sun Sep 22 10:35:26 UTC 2013


Yes, to commit it, it needs to build.

Sent from my iPhone

> On Sep 22, 2013, at 4:43, Big Lebowski <spankthespam at gmail.com> wrote:
> 
>> On Sat, Sep 21, 2013 at 11:26 PM, Bryan Drewery <bryan at shatow.net> wrote:
>> 
>>> On 9/21/2013 5:08 PM, Big Lebowski wrote:
>>> Hi,
>>> 
>>> Thanks for your comments, see mine below.
>>> 
>>> 
>>>> On Fri, Sep 20, 2013 at 9:37 PM, Bryan Drewery <bryan at shatow.net> wrote:
>>>> 
>>>>> On Fri, Sep 20, 2013 at 06:57:52PM +0100, Big Lebowski wrote:
>>>>> Hi list!
>>>>> 
>>>>> I've been working for couple last days on porting Basho Riak database
>>>>> (latest version 1.4.2) and finally I think it is ready to be presented:
>>>>> https://www.dropbox.com/s/2ztu2bdiip1u2un/riak.tgz
>>>> 
>>>>  MASTER_SITES=
>>>> http://s3.amazonaws.com/downloads.basho.com/riak/1.4/1.4.2/ \
>>>> 
>>>> http://downloads.basho.com.s3.amazonaws.com/riak/1.4/1.4.2/
>>>> 
>>>> Use ${PORTVERSION} instead of 1.4.2
>>> 
>>> Fixed.
>>> 
>>> 
>>>> 
>>>>  USES=           ${GMAKE}
>>>> 
>>>> Use 'gmake', not ${GMAKE} here.
>>> 
>>> Fixed.
>>> 
>>> 
>>>> 
>>>> Fails to build on 8.3 i386:
>>>> 
>>>>  db/version_set.cc:59: warning: this decimal constant is unsigned only
>> in
>>>> ISO C90
>>>>  db/version_set.cc:59: warning: this decimal constant is unsigned only
>> in
>>>> ISO C90
>>>>  db/version_set.cc:60: error: integer constant is too large for 'long'
>>>> type
>>>>  db/version_set.cc:60: error: integer constant is too large for 'long'
>>>> type
>>>>  db/version_set.cc:61: error: integer constant is too large for 'long'
>>>> type
>>>>  db/version_set.cc:61: error: integer constant is too large for 'long'
>>>> type
>>>>  db/version_set.cc:62: error: integer constant is too large for 'long'
>>>> type
>>>>  db/version_set.cc:62: error: integer constant is too large for 'long'
>>>> type
>>>>  table/filter_block.cc: In member function 'bool
>>>> leveldb::FilterBlockReader::KeyMayMatch(uint64_t, const
>> leveldb::Slice&)':
>>>>  table/filter_block.cc:112: warning: comparison between signed and
>>>> unsigned integer expressions
>>>>  util/env_posix.cc: In constructor
>>>> 'leveldb::<unnamed>::PosixEnv::PosixEnv()':
>>>>  util/env_posix.cc:788: warning: unused variable 'ts'
>>>> 
>>>> 
>>>>  gmake[1]: *** [libleveldb.so.1.9] Error 1
>>>>  gmake[1]: Leaving directory
>> `/wrkdirs/usr/ports/databases/riak/work/riak-1.4.2/deps/eleveldb/c_src/leveldb'
>>> 
>>> Can you provide any more details on your testing environment, like 32/64
>>> bit, GCC version, any compile optimizations in make.conf and so on?
>>> Unfortunately, I dont have any 8.x machine to test it, so I wasnt able to
>>> see that before. Could you also try to build it on 8.3 using CLANG?
>> 
>> 8.3 i386 (32 bit). GCC 4.2. This error is of too much data for 32bit
>> variable. Clang won't help.
>> 
>> Here is the issue upstream as well with a recommended fix and a SO
>> explaining more:
>> 
>> https://github.com/basho/leveldb/issues/87
>> 
>> http://stackoverflow.com/questions/5541560/integer-constant-is-too-large-for-long-type
> 
> 
> It seems like its a bug in Riak itself, and I wonder if it should be me,
> who's fixing it? Given the fact, the fix have not been accepted for two
> months now, that it is (as its author writes) still giving warnings, and
> given that I've zero knowledge of C, does it make sense to make this
> unaccepted, uncomplete and unknown code a patch for the port? If there
> would be Nginx error prohibiting building it on certain enviroments, would
> Nginx port owner be fixing it, or should it rather be a Nginx authors
> problem?
> 
> B.
> 
> 
>> 
>> 
>>> 
>>> 
>>>> 
>>>> 
>>>> Instead of bsd.port.pre.mk ... bsd.port.post.mk, use
>> bsd.port.options.mk...
>>>> bsd.port.mk. Although, it doesn't look like you even need that. Just
>> use
>>>> bsd.port.mk at the end, no 2nd include.
>>> 
>>> I dont think I can get away with only using bsd.port.mk - I've tried
>> that,
>>> and the port fails miserably, somwhere on the level of interpretation of
>>> the Makefile, where it is missing many macros, so I've stayed with two
>>> includes.
>>> 
>>> 
>>>> 
>>>> 
>>>> Otherwise, good work. I will pkg-build test any updates you send out.
>>> 
>>> Thanks, great to hear that. Latest version will be posted in response to
>> my
>>> original message.
>>> 
>>> B.
>>> 
>>> 
>>>> 
>>>>> 
>>>>> Please, grab the port and test it on anything you can, break it in any
>>>> way
>>>>> possible, and comment on anything you see that's been done wrong - I am
>>>>> open to any suggestion on how to make it worthy candidate for send-pr
>>>> with
>>>>> port submission.
>>>>> 
>>>>> Any help will be highly appreciated and will motivate me to port more
>>>> cool
>>>>> software to FreeBSD! ;)
>>>>> 
>>>>> Kind regards,
>>>>> S.
>>>>> _______________________________________________
>>>>> freebsd-ports at freebsd.org mailing list
>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>>>>> To unsubscribe, send any mail to "
>> freebsd-ports-unsubscribe at freebsd.org"
>>> _______________________________________________
>>> freebsd-ports at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>>> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"


More information about the freebsd-ports mailing list