I have the same problem. I installed sqlite-devel but didn't fix. I'll keep researching!

EDIT: In db-sqlite.c, SQLITE_OPEN_READWRITE is not defined, nor is it defined in any of the includes, which is why Make is throwing a hissy fit. I wonder why this isn't causing a problem on other Distro's?

EDIT 2: It seems this is a common problem with sqlite dependant apps on CentOS. I'm running up OpenSUSE 11.4 now to try my luck with that!

I'm sorry to ask something just only vaguely related but I'm unable to find any documentation about it and I need to understand better.

The miner programs connects to the pool server using an HTTP request but I'm unable to understand which kind of request it is. Is it a standard http web request?If yes, how are the json parameters passed?

In other words, how to decode the request using for example PHP, JSP or a similar scripting language?

I'm also thinking about building a pool with pushpool. Here are some questions from my side (maybe not all so much pushpool related):

About the shares table:* our_result - If pushpool accepts the hash from the miner, this is Y... else N* reason - If pushpool doesn't accept the hash, this is the reason (so.. mostly 'stale' I guess)* upstream_result - If pushpool accepted the hash, it gets forwarded to bitcoind, if it's not accepted it's N, if it's a success it's Y (and a new block is born?)...

I've got a couple of "our_result=Y; upstream_result=N" what does that mean? (Is it related to rpc.target.rewrite?)

About pool speed:

Quote

Look at your share log, for the rate of incoming solutions.

How can I calculate the speed from that? Sometimes I'm sending a hash every 2 seconds, sometimes it takes minutes?

About the shares table:* our_result - If pushpool accepts the hash from the miner, this is Y... else N* reason - If pushpool doesn't accept the hash, this is the reason (so.. mostly 'stale' I guess)* upstream_result - If pushpool accepted the hash, it gets forwarded to bitcoind, if it's not accepted it's N, if it's a success it's Y (and a new block is born?)...

I've got a couple of "our_result=Y; upstream_result=N" what does that mean? (Is it related to rpc.target.rewrite?)

For easy-target pools, pushpool does not submit all H==0 solutions to upstream bitcoind. That would be a lot of solutions with zero chance of being a valid mainnet block hash.

pushpool requires 8 additional zero bits, before it submits to upstream. Therefore, you will see (Y, NULL) for most shares, (Y, N) for uncommon shares that are just a bit closer to the target, and (Y, Y) for valid, full-target mainnet block hash accepted by upstream. Only the latter (Y, Y) pays you 50 BTC, and generates a block w/ transactions.

Quote

About pool speed:

Quote

Look at your share log, for the rate of incoming solutions.

How can I calculate the speed from that? Sometimes I'm sending a hash every 2 seconds, sometimes it takes minutes?

If you are difficulty 1 pool, then each share represents 2**32 hashes. Divide over time to get hashes/second.