Re: NEW: net/bitcoin
On Wed, Jul 11, 2018 at 10:05:54PM +0200, Fabian Raetz wrote: > Hi, > > can we also create a package of the no_x11 flavor? Not only we can, but we must. Otherwise unbuilt FLAVORs tend to rot and die... Thanks, commited. > diff --git a/net/Makefile b/net/Makefile > index 57cfb4eec35..b8781538c32 100644 > --- a/net/Makefile > +++ b/net/Makefile > @@ -27,6 +27,7 @@ > SUBDIR += bird > SUBDIR += bird,v6 > SUBDIR += bitcoin > + SUBDIR += bitcoin,no_x11 > SUBDIR += bitlbee > SUBDIR += bitlbee,libpurple > SUBDIR += bitlbee,otr > > > Cheers, > Fabian > > Am So., 8. Juli 2018 um 20:05 Uhr schrieb Kirill Bychkov < > ki...@linklevel.net>: > > > On Sun, July 8, 2018 20:13, Rafael Sadowski wrote: > > > On Sun Jul 08, 2018 at 05:39:33PM +0300, Kirill Bychkov wrote: > > >> On Wed, July 4, 2018 23:28, Rafael Sadowski wrote: > > >> > HI ports@, Hi Fabian Raetz! > > >> > > > >> > Thanks for testing over two weeks and tweaks/feedback. Your rc changes > > >> > works fine for me. > > >> > > > >> > @ports: Attached new tarball with rc tweaks from Fabian Raetz. > > >> > > > >> > Could I get an okay (ports-wise) to import? > > >> > > >> Hi! Not an OK yet, sorry. > > >> I guess better comment is needed to explain why this could be > > >> built with clang only. > > > > > > Added "Undefined reference to boost and db4 with GCC" over COMPILER. > > > Better ideas? > > > > OK kirby@ > > BTW you can use --disable-tests instead of @comments in PLIST > > > > > > > > Complete output: > > > > > > /usr/bin/ar cr leveldb/libmemenv.a > > > leveldb/helpers/memenv/leveldb_libmemenv_a-memenv.o > > > /usr/bin/ranlib leveldb/libmemenv.a > > > /usr/bin/libtool --tag=CXX --mode=link eg++ -Wstack-protector > > > -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -pthread > > -Wl,-z,relro > > > -Wl,-z,now -L/usr/X11R6/lib -L/usr/local/lib -o bitcoind > > bitcoind-bitcoind.o > > > libbitcoin_server.a libbitcoin_common.a univalue/libunivalue.la > > > libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a > > libbitcoin_consensus.a > > > crypto/libbitcoin_crypto.a leveldb/libleveldb.a > > leveldb/libleveldb_sse42.a > > > leveldb/libmemenv.a secp256k1/libsecp256k1.la -pthread -L/usr/local/lib > > > -lboost_system -lboost_filesystem -lboost_program_options-mt > > -lboost_thread-mt > > > -lboost_chrono-mt -ldb_cxx -lssl -lcrypto -lcrypto -lminiupnpc > > > -L/usr/local/lib -levent_pthreads -levent_extra -levent_core > > -L/usr/local/lib > > > -levent_extra -levent_core -L/usr/local/lib -lzmq > > > libtool: link: eg++ -o .libs/bitcoind -pthread -Wstack-protector > > > -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -Wl,-z -Wl,relro -Wl,-z > > > -Wl,now bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a > > > libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a > > libbitcoin_consensus.a > > > crypto/libbitcoin_crypto.a leveldb/libleveldb.a > > leveldb/libleveldb_sse42.a > > > leveldb/libmemenv.a -L.libs -lunivalue -lsecp256k1 -lboost_system -lc++ > > > -lc++abi -lpthread -lm -lboost_filesystem -lboost_program_options-mt > > > -lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -ldb_cxx -lssl > > -lcrypto > > > -lminiupnpc -levent_pthreads -levent_extra -levent_core -lzmq -lsodium > > > -Wl,-rpath-link,/usr/local/lib > > > .libs/libzmq.so.4.2: warning: strcat() is almost always misused, please > > use > > > strlcat() > > > .libs/libdb_cxx.so.6.0: warning: rand() may return deterministic values, > > is > > > that what you want? > > > .libs/libboost_filesystem.so.8.0: warning: strcpy() is almost always > > misused, > > > please use strlcpy() > > > .libs/libzmq.so.4.2: warning: sprintf() is often misused, please use > > > snprintf() > > > .libs/libevent_core.so.1.1: warning: random() may return deterministic > > values, > > > is that what you want? > > > libbitcoin_util.a(libbitcoin_util_a-util.o): In function > > `SetupEnvironment()': > > > util.cpp:(.text+0x12ca): undefined reference to > > > `boost::filesystem::path::imbue(std::locale const&)' > > > util.cpp:(.text+0x12d5): undefined reference to > > > `boost::filesystem::path::imbue(std::locale const&)' > > > libbitcoin_util.a(libbitcoin_util_a-util.o): In function > > > > > `boost::program_options::detail::basic_config_file_iterator::getline(std::string&)': > > > > > util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs[_ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs]+0x98): > > > undefined reference to `boost::program_options::to_internal(std::string > > > const&)' > > > libbitcoin_util.a(libbitcoin_util_a-util.o): In function > > > > > `boost::program_options::detail::basic_config_file_iterator::basic_config_file_iterator(std::istream&, > > > std::set, > > std::allocator > > > > const&, bool)': > > > > > util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcEC2ERSiRKSt3setISsSt4lessISsESaISsEEb[_ZN5boost15program_options6detail26basic_config_file_iter
Re: NEW: net/bitcoin
Hi, can we also create a package of the no_x11 flavor? diff --git a/net/Makefile b/net/Makefile index 57cfb4eec35..b8781538c32 100644 --- a/net/Makefile +++ b/net/Makefile @@ -27,6 +27,7 @@ SUBDIR += bird SUBDIR += bird,v6 SUBDIR += bitcoin + SUBDIR += bitcoin,no_x11 SUBDIR += bitlbee SUBDIR += bitlbee,libpurple SUBDIR += bitlbee,otr Cheers, Fabian Am So., 8. Juli 2018 um 20:05 Uhr schrieb Kirill Bychkov < ki...@linklevel.net>: > On Sun, July 8, 2018 20:13, Rafael Sadowski wrote: > > On Sun Jul 08, 2018 at 05:39:33PM +0300, Kirill Bychkov wrote: > >> On Wed, July 4, 2018 23:28, Rafael Sadowski wrote: > >> > HI ports@, Hi Fabian Raetz! > >> > > >> > Thanks for testing over two weeks and tweaks/feedback. Your rc changes > >> > works fine for me. > >> > > >> > @ports: Attached new tarball with rc tweaks from Fabian Raetz. > >> > > >> > Could I get an okay (ports-wise) to import? > >> > >> Hi! Not an OK yet, sorry. > >> I guess better comment is needed to explain why this could be > >> built with clang only. > > > > Added "Undefined reference to boost and db4 with GCC" over COMPILER. > > Better ideas? > > OK kirby@ > BTW you can use --disable-tests instead of @comments in PLIST > > > > > Complete output: > > > > /usr/bin/ar cr leveldb/libmemenv.a > > leveldb/helpers/memenv/leveldb_libmemenv_a-memenv.o > > /usr/bin/ranlib leveldb/libmemenv.a > > /usr/bin/libtool --tag=CXX --mode=link eg++ -Wstack-protector > > -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -pthread > -Wl,-z,relro > > -Wl,-z,now -L/usr/X11R6/lib -L/usr/local/lib -o bitcoind > bitcoind-bitcoind.o > > libbitcoin_server.a libbitcoin_common.a univalue/libunivalue.la > > libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a > libbitcoin_consensus.a > > crypto/libbitcoin_crypto.a leveldb/libleveldb.a > leveldb/libleveldb_sse42.a > > leveldb/libmemenv.a secp256k1/libsecp256k1.la -pthread -L/usr/local/lib > > -lboost_system -lboost_filesystem -lboost_program_options-mt > -lboost_thread-mt > > -lboost_chrono-mt -ldb_cxx -lssl -lcrypto -lcrypto -lminiupnpc > > -L/usr/local/lib -levent_pthreads -levent_extra -levent_core > -L/usr/local/lib > > -levent_extra -levent_core -L/usr/local/lib -lzmq > > libtool: link: eg++ -o .libs/bitcoind -pthread -Wstack-protector > > -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -Wl,-z -Wl,relro -Wl,-z > > -Wl,now bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a > > libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a > libbitcoin_consensus.a > > crypto/libbitcoin_crypto.a leveldb/libleveldb.a > leveldb/libleveldb_sse42.a > > leveldb/libmemenv.a -L.libs -lunivalue -lsecp256k1 -lboost_system -lc++ > > -lc++abi -lpthread -lm -lboost_filesystem -lboost_program_options-mt > > -lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -ldb_cxx -lssl > -lcrypto > > -lminiupnpc -levent_pthreads -levent_extra -levent_core -lzmq -lsodium > > -Wl,-rpath-link,/usr/local/lib > > .libs/libzmq.so.4.2: warning: strcat() is almost always misused, please > use > > strlcat() > > .libs/libdb_cxx.so.6.0: warning: rand() may return deterministic values, > is > > that what you want? > > .libs/libboost_filesystem.so.8.0: warning: strcpy() is almost always > misused, > > please use strlcpy() > > .libs/libzmq.so.4.2: warning: sprintf() is often misused, please use > > snprintf() > > .libs/libevent_core.so.1.1: warning: random() may return deterministic > values, > > is that what you want? > > libbitcoin_util.a(libbitcoin_util_a-util.o): In function > `SetupEnvironment()': > > util.cpp:(.text+0x12ca): undefined reference to > > `boost::filesystem::path::imbue(std::locale const&)' > > util.cpp:(.text+0x12d5): undefined reference to > > `boost::filesystem::path::imbue(std::locale const&)' > > libbitcoin_util.a(libbitcoin_util_a-util.o): In function > > > `boost::program_options::detail::basic_config_file_iterator::getline(std::string&)': > > > util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs[_ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs]+0x98): > > undefined reference to `boost::program_options::to_internal(std::string > > const&)' > > libbitcoin_util.a(libbitcoin_util_a-util.o): In function > > > `boost::program_options::detail::basic_config_file_iterator::basic_config_file_iterator(std::istream&, > > std::set, > std::allocator > > > const&, bool)': > > > util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcEC2ERSiRKSt3setISsSt4lessISsESaISsEEb[_ZN5boost15program_options6detail26basic_config_file_iteratorIcEC5ERSiRKSt3setISsSt4lessISsESaISsEEb]+0x21): > > undefined reference to > > > `boost::program_options::detail::common_config_file_iterator::common_config_file_iterator(std::set > std::less, std::allocator > const&, bool)' > > libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In function > > `CDBEnv::Verify(std::string const&, bool (*)(std::string const&, > > std::string&), std::string&)
Re: NEW: net/bitcoin
On Sun, July 8, 2018 20:13, Rafael Sadowski wrote: > On Sun Jul 08, 2018 at 05:39:33PM +0300, Kirill Bychkov wrote: >> On Wed, July 4, 2018 23:28, Rafael Sadowski wrote: >> > HI ports@, Hi Fabian Raetz! >> > >> > Thanks for testing over two weeks and tweaks/feedback. Your rc changes >> > works fine for me. >> > >> > @ports: Attached new tarball with rc tweaks from Fabian Raetz. >> > >> > Could I get an okay (ports-wise) to import? >> >> Hi! Not an OK yet, sorry. >> I guess better comment is needed to explain why this could be >> built with clang only. > > Added "Undefined reference to boost and db4 with GCC" over COMPILER. > Better ideas? OK kirby@ BTW you can use --disable-tests instead of @comments in PLIST > > Complete output: > > /usr/bin/ar cr leveldb/libmemenv.a > leveldb/helpers/memenv/leveldb_libmemenv_a-memenv.o > /usr/bin/ranlib leveldb/libmemenv.a > /usr/bin/libtool --tag=CXX --mode=link eg++ -Wstack-protector > -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -pthread -Wl,-z,relro > -Wl,-z,now -L/usr/X11R6/lib -L/usr/local/lib -o bitcoind bitcoind-bitcoind.o > libbitcoin_server.a libbitcoin_common.a univalue/libunivalue.la > libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a libbitcoin_consensus.a > crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a > leveldb/libmemenv.a secp256k1/libsecp256k1.la -pthread -L/usr/local/lib > -lboost_system -lboost_filesystem -lboost_program_options-mt -lboost_thread-mt > -lboost_chrono-mt -ldb_cxx -lssl -lcrypto -lcrypto -lminiupnpc > -L/usr/local/lib -levent_pthreads -levent_extra -levent_core -L/usr/local/lib > -levent_extra -levent_core -L/usr/local/lib -lzmq > libtool: link: eg++ -o .libs/bitcoind -pthread -Wstack-protector > -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -Wl,-z -Wl,relro -Wl,-z > -Wl,now bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a > libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a libbitcoin_consensus.a > crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a > leveldb/libmemenv.a -L.libs -lunivalue -lsecp256k1 -lboost_system -lc++ > -lc++abi -lpthread -lm -lboost_filesystem -lboost_program_options-mt > -lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -ldb_cxx -lssl -lcrypto > -lminiupnpc -levent_pthreads -levent_extra -levent_core -lzmq -lsodium > -Wl,-rpath-link,/usr/local/lib > .libs/libzmq.so.4.2: warning: strcat() is almost always misused, please use > strlcat() > .libs/libdb_cxx.so.6.0: warning: rand() may return deterministic values, is > that what you want? > .libs/libboost_filesystem.so.8.0: warning: strcpy() is almost always misused, > please use strlcpy() > .libs/libzmq.so.4.2: warning: sprintf() is often misused, please use > snprintf() > .libs/libevent_core.so.1.1: warning: random() may return deterministic values, > is that what you want? > libbitcoin_util.a(libbitcoin_util_a-util.o): In function `SetupEnvironment()': > util.cpp:(.text+0x12ca): undefined reference to > `boost::filesystem::path::imbue(std::locale const&)' > util.cpp:(.text+0x12d5): undefined reference to > `boost::filesystem::path::imbue(std::locale const&)' > libbitcoin_util.a(libbitcoin_util_a-util.o): In function > `boost::program_options::detail::basic_config_file_iterator::getline(std::string&)': > util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs[_ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs]+0x98): > undefined reference to `boost::program_options::to_internal(std::string > const&)' > libbitcoin_util.a(libbitcoin_util_a-util.o): In function > `boost::program_options::detail::basic_config_file_iterator::basic_config_file_iterator(std::istream&, > std::set, std::allocator > > const&, bool)': > util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcEC2ERSiRKSt3setISsSt4lessISsESaISsEEb[_ZN5boost15program_options6detail26basic_config_file_iteratorIcEC5ERSiRKSt3setISsSt4lessISsESaISsEEb]+0x21): > undefined reference to > `boost::program_options::detail::common_config_file_iterator::common_config_file_iterator(std::set std::less, std::allocator > const&, bool)' > libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In function > `CDBEnv::Verify(std::string const&, bool (*)(std::string const&, > std::string&), std::string&)': > db.cpp:(.text+0x6812): undefined reference to `Db::verify(char const*, char > const*, std::ostream*, unsigned int)' > libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In function > `CDBEnv::Salvage(std::string const&, bool, > std::vector > >, std::vector > >, > std::allocator char> >, std::vector char> > > > >&)': > db.cpp:(.text+0x6e81): undefined reference to `Db::verify(char const*, char > const*, std::ostream*, unsigned int)' > collect2: error: ld returned 1 exit status > Error while executing eg++ -o .libs/bitcoind -pthread -Wstack-protector > -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -Wl,-z -Wl,relro -Wl,-z > -Wl,now bitcoind-bitcoind.o libbitcoin_ser
Re: NEW: net/bitcoin
On Sun Jul 08, 2018 at 05:39:33PM +0300, Kirill Bychkov wrote: > On Wed, July 4, 2018 23:28, Rafael Sadowski wrote: > > HI ports@, Hi Fabian Raetz! > > > > Thanks for testing over two weeks and tweaks/feedback. Your rc changes > > works fine for me. > > > > @ports: Attached new tarball with rc tweaks from Fabian Raetz. > > > > Could I get an okay (ports-wise) to import? > > Hi! Not an OK yet, sorry. > I guess better comment is needed to explain why this could be > built with clang only. Added "Undefined reference to boost and db4 with GCC" over COMPILER. Better ideas? Complete output: /usr/bin/ar cr leveldb/libmemenv.a leveldb/helpers/memenv/leveldb_libmemenv_a-memenv.o /usr/bin/ranlib leveldb/libmemenv.a /usr/bin/libtool --tag=CXX --mode=link eg++ -Wstack-protector -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -pthread -Wl,-z,relro -Wl,-z,now -L/usr/X11R6/lib -L/usr/local/lib -o bitcoind bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a univalue/libunivalue.la libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a libbitcoin_consensus.a crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a leveldb/libmemenv.a secp256k1/libsecp256k1.la -pthread -L/usr/local/lib -lboost_system -lboost_filesystem -lboost_program_options-mt -lboost_thread-mt -lboost_chrono-mt -ldb_cxx -lssl -lcrypto -lcrypto -lminiupnpc -L/usr/local/lib -levent_pthreads -levent_extra -levent_core -L/usr/local/lib -levent_extra -levent_core -L/usr/local/lib -lzmq libtool: link: eg++ -o .libs/bitcoind -pthread -Wstack-protector -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -Wl,-z -Wl,relro -Wl,-z -Wl,now bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a libbitcoin_consensus.a crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a leveldb/libmemenv.a -L.libs -lunivalue -lsecp256k1 -lboost_system -lc++ -lc++abi -lpthread -lm -lboost_filesystem -lboost_program_options-mt -lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -ldb_cxx -lssl -lcrypto -lminiupnpc -levent_pthreads -levent_extra -levent_core -lzmq -lsodium -Wl,-rpath-link,/usr/local/lib .libs/libzmq.so.4.2: warning: strcat() is almost always misused, please use strlcat() .libs/libdb_cxx.so.6.0: warning: rand() may return deterministic values, is that what you want? .libs/libboost_filesystem.so.8.0: warning: strcpy() is almost always misused, please use strlcpy() .libs/libzmq.so.4.2: warning: sprintf() is often misused, please use snprintf() .libs/libevent_core.so.1.1: warning: random() may return deterministic values, is that what you want? libbitcoin_util.a(libbitcoin_util_a-util.o): In function `SetupEnvironment()': util.cpp:(.text+0x12ca): undefined reference to `boost::filesystem::path::imbue(std::locale const&)' util.cpp:(.text+0x12d5): undefined reference to `boost::filesystem::path::imbue(std::locale const&)' libbitcoin_util.a(libbitcoin_util_a-util.o): In function `boost::program_options::detail::basic_config_file_iterator::getline(std::string&)': util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs[_ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs]+0x98): undefined reference to `boost::program_options::to_internal(std::string const&)' libbitcoin_util.a(libbitcoin_util_a-util.o): In function `boost::program_options::detail::basic_config_file_iterator::basic_config_file_iterator(std::istream&, std::set, std::allocator > const&, bool)': util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcEC2ERSiRKSt3setISsSt4lessISsESaISsEEb[_ZN5boost15program_options6detail26basic_config_file_iteratorIcEC5ERSiRKSt3setISsSt4lessISsESaISsEEb]+0x21): undefined reference to `boost::program_options::detail::common_config_file_iterator::common_config_file_iterator(std::set, std::allocator > const&, bool)' libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In function `CDBEnv::Verify(std::string const&, bool (*)(std::string const&, std::string&), std::string&)': db.cpp:(.text+0x6812): undefined reference to `Db::verify(char const*, char const*, std::ostream*, unsigned int)' libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In function `CDBEnv::Salvage(std::
Re: NEW: net/bitcoin
On Wed, July 4, 2018 23:28, Rafael Sadowski wrote: > HI ports@, Hi Fabian Raetz! > > Thanks for testing over two weeks and tweaks/feedback. Your rc changes > works fine for me. > > @ports: Attached new tarball with rc tweaks from Fabian Raetz. > > Could I get an okay (ports-wise) to import? Hi! Not an OK yet, sorry. I guess better comment is needed to explain why this could be built with clang only. And since almost all @tag bits are in, it would be nice to use it in new ports instead of @exec. > > Thanks, Rafael > > On Mon Jul 02, 2018 at 11:07:10PM +0200, Fabian Raetz wrote: >> add here's the missing diff xD >> >> Am Mo., 2. Juli 2018 um 23:06 Uhr schrieb Fabian Raetz < >> fabian.ra...@gmail.com>: >> >> > Hi >> > >> > i've been running a bitcoin node for the last two weeks and everything >> > seems to be fine! I tested the QT client as well as the no_x11 FLAVOR and >> > used it in combination with lnd [0] (in testnet) >> > >> > Please find the attached diff with two small improvements to the rc file: >> > - add daemon_timeout=300. The daemon need time to shutdown successfully >> > (syncing to disk). 300 sec. was choosen randomly but this value worked for >> > me in several restarts. >> > - remove pid_file. It works even without specifying it. >> > >> > With this, the port looks ok to me :) >> > >> > Cheer, >> > Fabian >> > >> > [0] https://github.com/lightningnetwork/lnd >> > >> > Am Di., 26. Juni 2018 um 23:20 Uhr schrieb Rafael Sadowski < >> > raf...@sizeofvoid.org>: >> > >> >> On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote: >> >> > On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote: >> >> > > On 2018-06-23 09:07:38, Thomas Frohwein >> >> wrote: >> >> > > > On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com >> >> wrote: >> >> > > > > I think the blockchain size is a deterrent. I can test it when >> >> I'm back from traveling in ~ 10 days and have access to additional GB on >> my >> >> external drive, in case that helps. >> >> > > > > >> >> > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski < >> >> raf...@sizeofvoid.org> wrote: >> >> > > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please. >> >> > > > > > >> >> > > > > >It's not evil! It's NOT mining. ;) >> >> > > > >> >> > > > I installed it and tried to sync the 200GB blockchain to my >> >> external HDD >> >> > > > (because that's the only one that got this much space available). >> It >> >> > > > synced fine for 1-2 days with the bitcoin-qt client, but then at >> >> about >> >> > > > 30-40% of the blockchain synced, it now starts throwing an error: >> >> > > > >> >> > > > ERROR: ReadBlockFromDisk: Deserialize or I/O error - >> >> CAutoFile::read:fread failed: unspecified iostream_category error at >> >> CBlockDiskPos(nFile=613, nPos=6513581) >> >> > > > >> >> > > > When this happens, the following lines appear in dmesg: >> >> > > > >> >> > > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28 >> >> > > > SENSE KEY: Media Error >> >> > > > ASC/ASCQ: Unrecovered Read Error >> >> > > > >> >> > > > Fortunately, the drive still seems to be functional otherwise, can >> >> be >> >> > > > mounted and fsck -f doesn't see any issues. The dmesg lines >> reappear >> >> > > > whenever mounting or unmounting said drive until I disconnect and >> >> > > > reconnect the drive from the USB port. >> >> > > > >> >> > > >> >> > > This is almost certainly a problem with the drive. I've had >> >> > > several hard drives fail over the ~13 years or so I've been using >> >> > > OpenBSD, and this is exactly the kind of error I see when the >> >> > > drive is wearing out. >> >> > > >> >> > > The message means that the kernel could not read a sector on the >> >> > > drive despite trying to do so. I've had drives continue to >> >> > > otherwise work for years after throwing errors like that (though I >> >> > > made sure to back them up and only used them as "scratch" drives). >> >> > > Another time I had a drive fail within weeks of throwing an error >> >> > > like that. >> >> > > >> >> > > If it's still under warranty, I'd recommend sending it in for >> >> > > replacement. If it's not, I'd *highly* recommend backing up >> >> > > anything on there to another drive. >> >> > > >> >> > > Sometimes, sectors can be "weak" and if you give the drive enough >> >> > > time it will be able to read it, so if it can't be backed up >> >> > > entirely, back up as much as you can, then let the drive sit for a >> >> > > few days and try again. >> >> > > >> >> > > Some ports that may help: >> >> > > sysutils/ddrescue >> >> > > sysutils/testdisk >> >> > > sysutils/e2fsprogs (for the "badblocks" program) >> >> > > net/rsync (probably obvious, but still worth mentioning) >> >> > > >> >> > > Modern drives keep "spare sectors" in which to remap failing ones >> >> > > like this, but they usually only do so when *writing* to the >> >> > > sector, not when *reading* it. >> >> > > >> >> > > You could try backing
Re: NEW: net/bitcoin
HI ports@, Hi Fabian Raetz! Thanks for testing over two weeks and tweaks/feedback. Your rc changes works fine for me. @ports: Attached new tarball with rc tweaks from Fabian Raetz. Could I get an okay (ports-wise) to import? Thanks, Rafael On Mon Jul 02, 2018 at 11:07:10PM +0200, Fabian Raetz wrote: > add here's the missing diff xD > > Am Mo., 2. Juli 2018 um 23:06 Uhr schrieb Fabian Raetz < > fabian.ra...@gmail.com>: > > > Hi > > > > i've been running a bitcoin node for the last two weeks and everything > > seems to be fine! I tested the QT client as well as the no_x11 FLAVOR and > > used it in combination with lnd [0] (in testnet) > > > > Please find the attached diff with two small improvements to the rc file: > > - add daemon_timeout=300. The daemon need time to shutdown successfully > > (syncing to disk). 300 sec. was choosen randomly but this value worked for > > me in several restarts. > > - remove pid_file. It works even without specifying it. > > > > With this, the port looks ok to me :) > > > > Cheer, > > Fabian > > > > [0] https://github.com/lightningnetwork/lnd > > > > Am Di., 26. Juni 2018 um 23:20 Uhr schrieb Rafael Sadowski < > > raf...@sizeofvoid.org>: > > > >> On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote: > >> > On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote: > >> > > On 2018-06-23 09:07:38, Thomas Frohwein > >> wrote: > >> > > > On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com > >> wrote: > >> > > > > I think the blockchain size is a deterrent. I can test it when > >> I'm back from traveling in ~ 10 days and have access to additional GB on my > >> external drive, in case that helps. > >> > > > > > >> > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski < > >> raf...@sizeofvoid.org> wrote: > >> > > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please. > >> > > > > > > >> > > > > >It's not evil! It's NOT mining. ;) > >> > > > > >> > > > I installed it and tried to sync the 200GB blockchain to my > >> external HDD > >> > > > (because that's the only one that got this much space available). It > >> > > > synced fine for 1-2 days with the bitcoin-qt client, but then at > >> about > >> > > > 30-40% of the blockchain synced, it now starts throwing an error: > >> > > > > >> > > > ERROR: ReadBlockFromDisk: Deserialize or I/O error - > >> CAutoFile::read:fread failed: unspecified iostream_category error at > >> CBlockDiskPos(nFile=613, nPos=6513581) > >> > > > > >> > > > When this happens, the following lines appear in dmesg: > >> > > > > >> > > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28 > >> > > > SENSE KEY: Media Error > >> > > > ASC/ASCQ: Unrecovered Read Error > >> > > > > >> > > > Fortunately, the drive still seems to be functional otherwise, can > >> be > >> > > > mounted and fsck -f doesn't see any issues. The dmesg lines reappear > >> > > > whenever mounting or unmounting said drive until I disconnect and > >> > > > reconnect the drive from the USB port. > >> > > > > >> > > > >> > > This is almost certainly a problem with the drive. I've had > >> > > several hard drives fail over the ~13 years or so I've been using > >> > > OpenBSD, and this is exactly the kind of error I see when the > >> > > drive is wearing out. > >> > > > >> > > The message means that the kernel could not read a sector on the > >> > > drive despite trying to do so. I've had drives continue to > >> > > otherwise work for years after throwing errors like that (though I > >> > > made sure to back them up and only used them as "scratch" drives). > >> > > Another time I had a drive fail within weeks of throwing an error > >> > > like that. > >> > > > >> > > If it's still under warranty, I'd recommend sending it in for > >> > > replacement. If it's not, I'd *highly* recommend backing up > >> > > anything on there to another drive. > >> > > > >> > > Sometimes, sectors can be "weak" and if you give the drive enough > >> > > time it will be able to read it, so if it can't be backed up > >> > > entirely, back up as much as you can, then let the drive sit for a > >> > > few days and try again. > >> > > > >> > > Some ports that may help: > >> > > sysutils/ddrescue > >> > > sysutils/testdisk > >> > > sysutils/e2fsprogs (for the "badblocks" program) > >> > > net/rsync (probably obvious, but still worth mentioning) > >> > > > >> > > Modern drives keep "spare sectors" in which to remap failing ones > >> > > like this, but they usually only do so when *writing* to the > >> > > sector, not when *reading* it. > >> > > > >> > > You could try backing up the drive, then writing zeros to the > >> > > entire drive with dd(1) to try to see if it helps. You could also > >> > > try running "badblocks -n" on the drive (from sysutils/e2fsprogs). > >> > > > >> > > -nUse non-destructive read-write mode. By default only a non- > >> > > destructive read-only test is done. This option must > >> not be > >> > >
Re: NEW: net/bitcoin
add here's the missing diff xD Am Mo., 2. Juli 2018 um 23:06 Uhr schrieb Fabian Raetz < fabian.ra...@gmail.com>: > Hi > > i've been running a bitcoin node for the last two weeks and everything > seems to be fine! I tested the QT client as well as the no_x11 FLAVOR and > used it in combination with lnd [0] (in testnet) > > Please find the attached diff with two small improvements to the rc file: > - add daemon_timeout=300. The daemon need time to shutdown successfully > (syncing to disk). 300 sec. was choosen randomly but this value worked for > me in several restarts. > - remove pid_file. It works even without specifying it. > > With this, the port looks ok to me :) > > Cheer, > Fabian > > [0] https://github.com/lightningnetwork/lnd > > Am Di., 26. Juni 2018 um 23:20 Uhr schrieb Rafael Sadowski < > raf...@sizeofvoid.org>: > >> On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote: >> > On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote: >> > > On 2018-06-23 09:07:38, Thomas Frohwein >> wrote: >> > > > On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com >> wrote: >> > > > > I think the blockchain size is a deterrent. I can test it when >> I'm back from traveling in ~ 10 days and have access to additional GB on my >> external drive, in case that helps. >> > > > > >> > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski < >> raf...@sizeofvoid.org> wrote: >> > > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please. >> > > > > > >> > > > > >It's not evil! It's NOT mining. ;) >> > > > >> > > > I installed it and tried to sync the 200GB blockchain to my >> external HDD >> > > > (because that's the only one that got this much space available). It >> > > > synced fine for 1-2 days with the bitcoin-qt client, but then at >> about >> > > > 30-40% of the blockchain synced, it now starts throwing an error: >> > > > >> > > > ERROR: ReadBlockFromDisk: Deserialize or I/O error - >> CAutoFile::read:fread failed: unspecified iostream_category error at >> CBlockDiskPos(nFile=613, nPos=6513581) >> > > > >> > > > When this happens, the following lines appear in dmesg: >> > > > >> > > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28 >> > > > SENSE KEY: Media Error >> > > > ASC/ASCQ: Unrecovered Read Error >> > > > >> > > > Fortunately, the drive still seems to be functional otherwise, can >> be >> > > > mounted and fsck -f doesn't see any issues. The dmesg lines reappear >> > > > whenever mounting or unmounting said drive until I disconnect and >> > > > reconnect the drive from the USB port. >> > > > >> > > >> > > This is almost certainly a problem with the drive. I've had >> > > several hard drives fail over the ~13 years or so I've been using >> > > OpenBSD, and this is exactly the kind of error I see when the >> > > drive is wearing out. >> > > >> > > The message means that the kernel could not read a sector on the >> > > drive despite trying to do so. I've had drives continue to >> > > otherwise work for years after throwing errors like that (though I >> > > made sure to back them up and only used them as "scratch" drives). >> > > Another time I had a drive fail within weeks of throwing an error >> > > like that. >> > > >> > > If it's still under warranty, I'd recommend sending it in for >> > > replacement. If it's not, I'd *highly* recommend backing up >> > > anything on there to another drive. >> > > >> > > Sometimes, sectors can be "weak" and if you give the drive enough >> > > time it will be able to read it, so if it can't be backed up >> > > entirely, back up as much as you can, then let the drive sit for a >> > > few days and try again. >> > > >> > > Some ports that may help: >> > > sysutils/ddrescue >> > > sysutils/testdisk >> > > sysutils/e2fsprogs (for the "badblocks" program) >> > > net/rsync (probably obvious, but still worth mentioning) >> > > >> > > Modern drives keep "spare sectors" in which to remap failing ones >> > > like this, but they usually only do so when *writing* to the >> > > sector, not when *reading* it. >> > > >> > > You could try backing up the drive, then writing zeros to the >> > > entire drive with dd(1) to try to see if it helps. You could also >> > > try running "badblocks -n" on the drive (from sysutils/e2fsprogs). >> > > >> > > -nUse non-destructive read-write mode. By default only a non- >> > > destructive read-only test is done. This option must >> not be >> > > combined with the -w option, as they are mutually >> exclusive. >> > > >> > > "badblocks -n" will read all sectors on the drive and write back >> > > the same data to the sector. If it's "weak", and the program can >> > > manage to read the sector, the drive may then remap that sector to >> > > a spare. >> > > >> > > But! How much do you really trust a drive that has started to >> > > fail? Drives are cheap. Cheaper than they've ever been. If this >> > > drive contains the only copy of family photos o
Re: NEW: net/bitcoin
Hi i've been running a bitcoin node for the last two weeks and everything seems to be fine! I tested the QT client as well as the no_x11 FLAVOR and used it in combination with lnd [0] (in testnet) Please find the attached diff with two small improvements to the rc file: - add daemon_timeout=300. The daemon need time to shutdown successfully (syncing to disk). 300 sec. was choosen randomly but this value worked for me in several restarts. - remove pid_file. It works even without specifying it. With this, the port looks ok to me :) Cheer, Fabian [0] https://github.com/lightningnetwork/lnd Am Di., 26. Juni 2018 um 23:20 Uhr schrieb Rafael Sadowski < raf...@sizeofvoid.org>: > On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote: > > On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote: > > > On 2018-06-23 09:07:38, Thomas Frohwein > wrote: > > > > On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com > wrote: > > > > > I think the blockchain size is a deterrent. I can test it when I'm > back from traveling in ~ 10 days and have access to additional GB on my > external drive, in case that helps. > > > > > > > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski < > raf...@sizeofvoid.org> wrote: > > > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please. > > > > > > > > > > > >It's not evil! It's NOT mining. ;) > > > > > > > > I installed it and tried to sync the 200GB blockchain to my external > HDD > > > > (because that's the only one that got this much space available). It > > > > synced fine for 1-2 days with the bitcoin-qt client, but then at > about > > > > 30-40% of the blockchain synced, it now starts throwing an error: > > > > > > > > ERROR: ReadBlockFromDisk: Deserialize or I/O error - > CAutoFile::read:fread failed: unspecified iostream_category error at > CBlockDiskPos(nFile=613, nPos=6513581) > > > > > > > > When this happens, the following lines appear in dmesg: > > > > > > > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28 > > > > SENSE KEY: Media Error > > > > ASC/ASCQ: Unrecovered Read Error > > > > > > > > Fortunately, the drive still seems to be functional otherwise, can be > > > > mounted and fsck -f doesn't see any issues. The dmesg lines reappear > > > > whenever mounting or unmounting said drive until I disconnect and > > > > reconnect the drive from the USB port. > > > > > > > > > > This is almost certainly a problem with the drive. I've had > > > several hard drives fail over the ~13 years or so I've been using > > > OpenBSD, and this is exactly the kind of error I see when the > > > drive is wearing out. > > > > > > The message means that the kernel could not read a sector on the > > > drive despite trying to do so. I've had drives continue to > > > otherwise work for years after throwing errors like that (though I > > > made sure to back them up and only used them as "scratch" drives). > > > Another time I had a drive fail within weeks of throwing an error > > > like that. > > > > > > If it's still under warranty, I'd recommend sending it in for > > > replacement. If it's not, I'd *highly* recommend backing up > > > anything on there to another drive. > > > > > > Sometimes, sectors can be "weak" and if you give the drive enough > > > time it will be able to read it, so if it can't be backed up > > > entirely, back up as much as you can, then let the drive sit for a > > > few days and try again. > > > > > > Some ports that may help: > > > sysutils/ddrescue > > > sysutils/testdisk > > > sysutils/e2fsprogs (for the "badblocks" program) > > > net/rsync (probably obvious, but still worth mentioning) > > > > > > Modern drives keep "spare sectors" in which to remap failing ones > > > like this, but they usually only do so when *writing* to the > > > sector, not when *reading* it. > > > > > > You could try backing up the drive, then writing zeros to the > > > entire drive with dd(1) to try to see if it helps. You could also > > > try running "badblocks -n" on the drive (from sysutils/e2fsprogs). > > > > > > -nUse non-destructive read-write mode. By default only a non- > > > destructive read-only test is done. This option must > not be > > > combined with the -w option, as they are mutually > exclusive. > > > > > > "badblocks -n" will read all sectors on the drive and write back > > > the same data to the sector. If it's "weak", and the program can > > > manage to read the sector, the drive may then remap that sector to > > > a spare. > > > > > > But! How much do you really trust a drive that has started to > > > fail? Drives are cheap. Cheaper than they've ever been. If this > > > drive contains the only copy of family photos of your dearly > > > departed grandmother, are you willing to risk it? > > > > > > sd4 at scsibus4 targ 1 lun 0: SCSI4 > 0/direct fixed > > > sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors > > > > > > I see a 3TB Western Digital
Re: NEW: net/bitcoin
On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote: > On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote: > > On 2018-06-23 09:07:38, Thomas Frohwein wrote: > > > On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com wrote: > > > > I think the blockchain size is a deterrent. I can test it when I'm back > > > > from traveling in ~ 10 days and have access to additional GB on my > > > > external drive, in case that helps. > > > > > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski > > > > wrote: > > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please. > > > > > > > > > >It's not evil! It's NOT mining. ;) > > > > > > I installed it and tried to sync the 200GB blockchain to my external HDD > > > (because that's the only one that got this much space available). It > > > synced fine for 1-2 days with the bitcoin-qt client, but then at about > > > 30-40% of the blockchain synced, it now starts throwing an error: > > > > > > ERROR: ReadBlockFromDisk: Deserialize or I/O error - > > > CAutoFile::read:fread failed: unspecified iostream_category error at > > > CBlockDiskPos(nFile=613, nPos=6513581) > > > > > > When this happens, the following lines appear in dmesg: > > > > > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28 > > > SENSE KEY: Media Error > > > ASC/ASCQ: Unrecovered Read Error > > > > > > Fortunately, the drive still seems to be functional otherwise, can be > > > mounted and fsck -f doesn't see any issues. The dmesg lines reappear > > > whenever mounting or unmounting said drive until I disconnect and > > > reconnect the drive from the USB port. > > > > > > > This is almost certainly a problem with the drive. I've had > > several hard drives fail over the ~13 years or so I've been using > > OpenBSD, and this is exactly the kind of error I see when the > > drive is wearing out. > > > > The message means that the kernel could not read a sector on the > > drive despite trying to do so. I've had drives continue to > > otherwise work for years after throwing errors like that (though I > > made sure to back them up and only used them as "scratch" drives). > > Another time I had a drive fail within weeks of throwing an error > > like that. > > > > If it's still under warranty, I'd recommend sending it in for > > replacement. If it's not, I'd *highly* recommend backing up > > anything on there to another drive. > > > > Sometimes, sectors can be "weak" and if you give the drive enough > > time it will be able to read it, so if it can't be backed up > > entirely, back up as much as you can, then let the drive sit for a > > few days and try again. > > > > Some ports that may help: > > sysutils/ddrescue > > sysutils/testdisk > > sysutils/e2fsprogs (for the "badblocks" program) > > net/rsync (probably obvious, but still worth mentioning) > > > > Modern drives keep "spare sectors" in which to remap failing ones > > like this, but they usually only do so when *writing* to the > > sector, not when *reading* it. > > > > You could try backing up the drive, then writing zeros to the > > entire drive with dd(1) to try to see if it helps. You could also > > try running "badblocks -n" on the drive (from sysutils/e2fsprogs). > > > > -nUse non-destructive read-write mode. By default only a non- > > destructive read-only test is done. This option must not be > > combined with the -w option, as they are mutually exclusive. > > > > "badblocks -n" will read all sectors on the drive and write back > > the same data to the sector. If it's "weak", and the program can > > manage to read the sector, the drive may then remap that sector to > > a spare. > > > > But! How much do you really trust a drive that has started to > > fail? Drives are cheap. Cheaper than they've ever been. If this > > drive contains the only copy of family photos of your dearly > > departed grandmother, are you willing to risk it? > > > > sd4 at scsibus4 targ 1 lun 0: SCSI4 0/direct > > fixed > > sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors > > > > I see a 3TB Western Digital My Book on a very popular online > > retailer for only $89.99 USD with free shipping as I type this. > > > > Is the data on that drive worth more than that? Is the amount of > > time you'd spend trying to squeeze a little more life out of the > > drive worth it? How much do you value your free time? If you > > enjoy tinkering with things like this and don't have valuable data > > on it, it may be worth trying. If you'd rather spend that time > > outside hiking or seeing friends and family, then it may be more > > economical to just buy a new one. > > > > Ultimately, only you can decide. > > > > > I can't resume syncing the blockchain though because the error appears > > > again. > > > > > > > While I'm here, I poked around bitcoin's manpage and found this: > > > > -prune= > > > > Reduce storage r
Re: NEW: net/bitcoin
On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote: > On 2018-06-23 09:07:38, Thomas Frohwein wrote: > > On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com wrote: > > > I think the blockchain size is a deterrent. I can test it when I'm back > > > from traveling in ~ 10 days and have access to additional GB on my > > > external drive, in case that helps. > > > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski > > > wrote: > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please. > > > > > > > >It's not evil! It's NOT mining. ;) > > > > I installed it and tried to sync the 200GB blockchain to my external HDD > > (because that's the only one that got this much space available). It > > synced fine for 1-2 days with the bitcoin-qt client, but then at about > > 30-40% of the blockchain synced, it now starts throwing an error: > > > > ERROR: ReadBlockFromDisk: Deserialize or I/O error - CAutoFile::read:fread > > failed: unspecified iostream_category error at CBlockDiskPos(nFile=613, > > nPos=6513581) > > > > When this happens, the following lines appear in dmesg: > > > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28 > > SENSE KEY: Media Error > > ASC/ASCQ: Unrecovered Read Error > > > > Fortunately, the drive still seems to be functional otherwise, can be > > mounted and fsck -f doesn't see any issues. The dmesg lines reappear > > whenever mounting or unmounting said drive until I disconnect and > > reconnect the drive from the USB port. > > > > This is almost certainly a problem with the drive. I've had > several hard drives fail over the ~13 years or so I've been using > OpenBSD, and this is exactly the kind of error I see when the > drive is wearing out. > > The message means that the kernel could not read a sector on the > drive despite trying to do so. I've had drives continue to > otherwise work for years after throwing errors like that (though I > made sure to back them up and only used them as "scratch" drives). > Another time I had a drive fail within weeks of throwing an error > like that. > > If it's still under warranty, I'd recommend sending it in for > replacement. If it's not, I'd *highly* recommend backing up > anything on there to another drive. > > Sometimes, sectors can be "weak" and if you give the drive enough > time it will be able to read it, so if it can't be backed up > entirely, back up as much as you can, then let the drive sit for a > few days and try again. > > Some ports that may help: > sysutils/ddrescue > sysutils/testdisk > sysutils/e2fsprogs (for the "badblocks" program) > net/rsync (probably obvious, but still worth mentioning) > > Modern drives keep "spare sectors" in which to remap failing ones > like this, but they usually only do so when *writing* to the > sector, not when *reading* it. > > You could try backing up the drive, then writing zeros to the > entire drive with dd(1) to try to see if it helps. You could also > try running "badblocks -n" on the drive (from sysutils/e2fsprogs). > > -nUse non-destructive read-write mode. By default only a non- > destructive read-only test is done. This option must not be > combined with the -w option, as they are mutually exclusive. > > "badblocks -n" will read all sectors on the drive and write back > the same data to the sector. If it's "weak", and the program can > manage to read the sector, the drive may then remap that sector to > a spare. > > But! How much do you really trust a drive that has started to > fail? Drives are cheap. Cheaper than they've ever been. If this > drive contains the only copy of family photos of your dearly > departed grandmother, are you willing to risk it? > > sd4 at scsibus4 targ 1 lun 0: SCSI4 0/direct > fixed > sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors > > I see a 3TB Western Digital My Book on a very popular online > retailer for only $89.99 USD with free shipping as I type this. > > Is the data on that drive worth more than that? Is the amount of > time you'd spend trying to squeeze a little more life out of the > drive worth it? How much do you value your free time? If you > enjoy tinkering with things like this and don't have valuable data > on it, it may be worth trying. If you'd rather spend that time > outside hiking or seeing friends and family, then it may be more > economical to just buy a new one. > > Ultimately, only you can decide. > > > I can't resume syncing the blockchain though because the error appears > > again. > > > > While I'm here, I poked around bitcoin's manpage and found this: > > -prune= > > Reduce storage requirements by enabling pruning (deleting) of > old blocks. This allows the pruneblockchain RPC to be called to > delete specific blocks, and enables automatic pruning of old > blocks if a target size in MiB is provided. T
Re: NEW: net/bitcoin
On 2018-06-23 09:07:38, Thomas Frohwein wrote: > On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com wrote: > > I think the blockchain size is a deterrent. I can test it when I'm back > > from traveling in ~ 10 days and have access to additional GB on my external > > drive, in case that helps. > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski > > wrote: > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please. > > > > > >It's not evil! It's NOT mining. ;) > > I installed it and tried to sync the 200GB blockchain to my external HDD > (because that's the only one that got this much space available). It > synced fine for 1-2 days with the bitcoin-qt client, but then at about > 30-40% of the blockchain synced, it now starts throwing an error: > > ERROR: ReadBlockFromDisk: Deserialize or I/O error - CAutoFile::read:fread > failed: unspecified iostream_category error at CBlockDiskPos(nFile=613, > nPos=6513581) > > When this happens, the following lines appear in dmesg: > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28 > SENSE KEY: Media Error > ASC/ASCQ: Unrecovered Read Error > > Fortunately, the drive still seems to be functional otherwise, can be > mounted and fsck -f doesn't see any issues. The dmesg lines reappear > whenever mounting or unmounting said drive until I disconnect and > reconnect the drive from the USB port. > This is almost certainly a problem with the drive. I've had several hard drives fail over the ~13 years or so I've been using OpenBSD, and this is exactly the kind of error I see when the drive is wearing out. The message means that the kernel could not read a sector on the drive despite trying to do so. I've had drives continue to otherwise work for years after throwing errors like that (though I made sure to back them up and only used them as "scratch" drives). Another time I had a drive fail within weeks of throwing an error like that. If it's still under warranty, I'd recommend sending it in for replacement. If it's not, I'd *highly* recommend backing up anything on there to another drive. Sometimes, sectors can be "weak" and if you give the drive enough time it will be able to read it, so if it can't be backed up entirely, back up as much as you can, then let the drive sit for a few days and try again. Some ports that may help: sysutils/ddrescue sysutils/testdisk sysutils/e2fsprogs (for the "badblocks" program) net/rsync (probably obvious, but still worth mentioning) Modern drives keep "spare sectors" in which to remap failing ones like this, but they usually only do so when *writing* to the sector, not when *reading* it. You could try backing up the drive, then writing zeros to the entire drive with dd(1) to try to see if it helps. You could also try running "badblocks -n" on the drive (from sysutils/e2fsprogs). -nUse non-destructive read-write mode. By default only a non- destructive read-only test is done. This option must not be combined with the -w option, as they are mutually exclusive. "badblocks -n" will read all sectors on the drive and write back the same data to the sector. If it's "weak", and the program can manage to read the sector, the drive may then remap that sector to a spare. But! How much do you really trust a drive that has started to fail? Drives are cheap. Cheaper than they've ever been. If this drive contains the only copy of family photos of your dearly departed grandmother, are you willing to risk it? sd4 at scsibus4 targ 1 lun 0: SCSI4 0/direct fixed sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors I see a 3TB Western Digital My Book on a very popular online retailer for only $89.99 USD with free shipping as I type this. Is the data on that drive worth more than that? Is the amount of time you'd spend trying to squeeze a little more life out of the drive worth it? How much do you value your free time? If you enjoy tinkering with things like this and don't have valuable data on it, it may be worth trying. If you'd rather spend that time outside hiking or seeing friends and family, then it may be more economical to just buy a new one. Ultimately, only you can decide. > I can't resume syncing the blockchain though because the error appears > again. > While I'm here, I poked around bitcoin's manpage and found this: -prune= Reduce storage requirements by enabling pruning (deleting) of old blocks. This allows the pruneblockchain RPC to be called to delete specific blocks, and enables automatic pruning of old blocks if a target size in MiB is provided. This mode is incompatible with -txindex and -rescan. Warning: Reverting this setting requires re-downloading the entire blockchain. (default: 0 = disable pruning blocks, 1 = allow manual pruning via RPC, >550 =
Re: NEW: net/bitcoin
On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com wrote: > I think the blockchain size is a deterrent. I can test it when I'm back from > traveling in ~ 10 days and have access to additional GB on my external drive, > in case that helps. > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski wrote: > >3rd ping, or 4rd? Could anyone sacrifice themselves, please. > > > >It's not evil! It's NOT mining. ;) I installed it and tried to sync the 200GB blockchain to my external HDD (because that's the only one that got this much space available). It synced fine for 1-2 days with the bitcoin-qt client, but then at about 30-40% of the blockchain synced, it now starts throwing an error: ERROR: ReadBlockFromDisk: Deserialize or I/O error - CAutoFile::read:fread failed: unspecified iostream_category error at CBlockDiskPos(nFile=613, nPos=6513581) When this happens, the following lines appear in dmesg: sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28 SENSE KEY: Media Error ASC/ASCQ: Unrecovered Read Error Fortunately, the drive still seems to be functional otherwise, can be mounted and fsck -f doesn't see any issues. The dmesg lines reappear whenever mounting or unmounting said drive until I disconnect and reconnect the drive from the USB port. I can't resume syncing the blockchain though because the error appears again. Not sure if this is a deficiency of the port or maybe the hard drive itself... bitcoin's debug.log (9.5M): https://thfr.info/tmpstor/debug.log OpenBSD 6.3-current (GENERIC.MP) #36: Wed Jun 20 00:03:07 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 7454228480 (7108MB) avail mem = 7157866496 (6826MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x3f262000 (86 entries) bios0: vendor American Megatrends Inc. version "1.A0" date 02/27/2018 bios0: MSI MS-7A74 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT HPET SSDT SSDT UEFI SSDT LPIT SSDT SSDT SSDT SSDT DBGP DBG2 WSMT acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-7100 CPU @ 3.90GHz, 3892.39 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 23MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i3-7100 CPU @ 3.90GHz, 3890.94 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 2399 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus -1 (RP09) acpiprt5 at acpi0: bus -1 (RP10) acpiprt6 at acpi0: bus -1 (RP11) acpiprt7 at acpi0: bus -1 (RP12) acpiprt8 at acpi0: bus -1 (RP13) acpiprt9 at acpi0: bus -1 (RP01) acpiprt10 at acpi0: bus -1 (RP02) acpiprt11 at acpi0: bus -1 (RP03) acpiprt12 at acpi0: bus -1 (RP04) acpiprt13 at acpi0: bus -1 (RP05) acpiprt14 at acpi0: bus -1 (RP06) acpiprt15 at acpi0: bus 2 (RP07) acpiprt16 at acpi0: bus -1 (RP08) acpiprt17 at acpi0: bus -1 (RP17) acpiprt18 at acpi0: bus -1 (RP18) acpiprt19 at acpi0: bus -1 (RP19) acpiprt20 at acpi0: bus -1 (RP20) acpiprt21 at acpi0: bus -1 (RP21) acpiprt22 at acpi0: bus -1 (RP22) acpiprt23 at acpi0: bus -1 (RP23) acpiprt24 at acpi0: bus -1 (RP24) acpiprt25 at acpi0: bus -1 (RP14) acpiprt26 at acpi0: bus -1 (RP15) acpiprt27 at acpi0: bus -1 (RP16) acpiec0 at acpi0: not present acpicpu0 at acpi0: C2(200@151 mwait.1@0x33), C1(1000@1 mwa
Re: NEW: net/bitcoin
I think the blockchain size is a deterrent. I can test it when I'm back from traveling in ~ 10 days and have access to additional GB on my external drive, in case that helps. On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski wrote: >3rd ping, or 4rd? Could anyone sacrifice themselves, please. > >It's not evil! It's NOT mining. ;) > >On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote: >> Hi ports@ >> >> Attached is a new port for bitcoin. Long time ago pascal@ started >> working on bitcoin in openbsd-wip. I've finished this work and run a >full >> bitcoin node over weeks without problems so far: >> >> https://twitter.com/sizeofvoid/status/976586173538885632 >> >> $ cat net/bitcoin/pkg/DESCR >> >> Bitcoin is an experimental new digital currency that enables instant >> payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer >> technology to operate with no central authority: managing >transactions >> and issuing money are carried out collectively by the network. >> Bitcoin is also the name of the open source software which enables >> the use of this currency. >> >> Ok? Comments? >> >> Greetings to the hackerroom. >> >> Rafael Sadowski
Re: NEW: net/bitcoin
3rd ping, or 4rd? Could anyone sacrifice themselves, please. It's not evil! It's NOT mining. ;) On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote: > Hi ports@ > > Attached is a new port for bitcoin. Long time ago pascal@ started > working on bitcoin in openbsd-wip. I've finished this work and run a full > bitcoin node over weeks without problems so far: > > https://twitter.com/sizeofvoid/status/976586173538885632 > > $ cat net/bitcoin/pkg/DESCR > > Bitcoin is an experimental new digital currency that enables instant > payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer > technology to operate with no central authority: managing transactions > and issuing money are carried out collectively by the network. > Bitcoin is also the name of the open source software which enables > the use of this currency. > > Ok? Comments? > > Greetings to the hackerroom. > > Rafael Sadowski
Re: NEW: net/bitcoin
On Fri May 18, 2018 at 11:47:48AM -0400, Joseph Mayer wrote: > 2018-05-07 3:21 GMT+08:00 Rafael Sadowski : > > It doesn't build with ports-gcc > > I got it built using ports not too long ago. > > What issues did you get trying to build it using gcc-ports (GCC 4.9.4)? Please find attached my GCC output. The same linker call works with clang but not with ports-gcc. > > The only issue was the difficulty of install Berkeley DB, which can be > resolved by either building and installing (how?) or something like > --disable-wallet, as only the wallet subfunctionality uses it anyhow, > not the central router. > > Do you build the QT and wallet parts? Please check the ports Makefile. > > > and you already said it: "... you wouldn't want to run this on a > > machine that doesn't have clang available to it since it's probably > > far too slow." > > Clang may be working well for many projects, this one included, but > there are also projects today where Clang consistently performs > disastrously, so GCC will remain having a valid niche, maybe for very > long. > It's about architectures not projects. /usr/bin/libtool --tag=CXX --mode=link c++ -Wstack-protector -fstack-protector-all -fPIE -O2 -pipe -std=c++14 -pthread -Wl,-z,relro -Wl,-z,now -L/usr/X11R6/lib -L/usr/local/lib -L/usr/local/lib/db4 -o bitcoind bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a univalue/libunivalue.la libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a libbitcoin_consensus.a crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a leveldb/libmemenv.a secp256k1/libsecp256k1.la -pthread -L/usr/local/lib -lboost_system -lboost_filesystem -lboost_program_options-mt -lboost_thread-mt -lboost_chrono-mt -ldb_cxx -lssl -lcrypto -lcrypto -lminiupnpc -L/usr/local/lib -levent_pthreads -levent_extra -levent_core -L/usr/local/lib -levent_extra -levent_core -L/usr/local/lib -lzmq libtool: link: c++ -o .libs/bitcoind -pthread -Wstack-protector -fstack-protector-all -fPIE -O2 -pipe -std=c++14 -Wl,-z -Wl,relro -Wl,-z -Wl,now bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a libbitcoin_consensus.a crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a leveldb/libmemenv.a -L.libs -lunivalue -lsecp256k1 -lboost_system -lc++ -lc++abi -lpthread -lm -lboost_filesystem -lboost_program_options-mt -lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -ldb_cxx -lssl -lcrypto -lminiupnpc -levent_pthreads -levent_extra -levent_core -lzmq -lsodium -Wl,-rpath-link,/usr/local/lib .libs/libzmq.so.4.2: warning: sprintf() is often misused, please use snprintf() .libs/libzmq.so.4.2: warning: strcat() is almost always misused, please use strlcat() .libs/libevent_core.so.1.1: warning: random() may return deterministic values, is that what you want? .libs/libboost_filesystem.so.8.0: warning: strcpy() is almost always misused, please use strlcpy() .libs/libdb_cxx.so.6.0: warning: rand() may return deterministic values, is that what you want? libbitcoin_util.a(libbitcoin_util_a-util.o): In function `SetupEnvironment()': util.cpp:(.text+0x12ca): undefined reference to `boost::filesystem::path::imbue(std::locale const&)' util.cpp:(.text+0x12d5): undefined reference to `boost::filesystem::path::imbue(std::locale const&)' libbitcoin_util.a(libbitcoin_util_a-util.o): In function `boost::program_options::detail::basic_config_file_iterator::getline(std::string&)': util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs[_ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs]+0x98): undefined reference to `boost::program_options::to_internal(std::string const&)' libbitcoin_util.a(libbitcoin_util_a-util.o): In function `boost::program_options::detail::basic_config_file_iterator::basic_config_file_iterator(std::istream&, std::set, std::allocator > const&, bool)': util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcEC2ERSiRKSt3setISsSt4lessISsESaISsEEb[_ZN5boost15program_options6detail26basic_config_file_iteratorIcEC5ERSiRKSt3setISsSt4lessISsESaISsEEb]+0x21): undefined reference to `boost::program_options::detail::common_config_file_iterator::common_config_file_iterator(std::set, std::allocator > const&, bool)' libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In
Re: NEW: net/bitcoin
2018-05-07 3:21 GMT+08:00 Rafael Sadowski : > It doesn't build with ports-gcc I got it built using ports not too long ago. What issues did you get trying to build it using gcc-ports (GCC 4.9.4)? The only issue was the difficulty of install Berkeley DB, which can be resolved by either building and installing (how?) or something like --disable-wallet, as only the wallet subfunctionality uses it anyhow, not the central router. Do you build the QT and wallet parts? > and you already said it: "... you wouldn't want to run this on a > machine that doesn't have clang available to it since it's probably > far too slow." Clang may be working well for many projects, this one included, but there are also projects today where Clang consistently performs disastrously, so GCC will remain having a valid niche, maybe for very long.
Re: NEW: net/bitcoin
anyone? On Sun May 06, 2018 at 09:21:50PM +0200, Rafael Sadowski wrote: > On Sun May 06, 2018 at 01:23:43PM -0400, Brian Callahan wrote: > > > > On 05/05/18 07:29, Rafael Sadowski wrote: > > > *ping* > > > > > > On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote: > > > > Hi ports@ > > > > > > > > Attached is a new port for bitcoin. Long time ago pascal@ started > > > > working on bitcoin in openbsd-wip. I've finished this work and run a > > > > full > > > > bitcoin node over weeks without problems so far: > > > > > > > > https://twitter.com/sizeofvoid/status/976586173538885632 > > > > > > > > $ cat net/bitcoin/pkg/DESCR > > > > > > > > Bitcoin is an experimental new digital currency that enables instant > > > > payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer > > > > technology to operate with no central authority: managing transactions > > > > and issuing money are carried out collectively by the network. > > > > Bitcoin is also the name of the open source software which enables > > > > the use of this currency. > > > > > > > > Ok? Comments? > > > > > > > > Greetings to the hackerroom. > > > > > > > > Rafael Sadowski > > > > > > > It reads and builds ok, and bitcoin-qt even launches. > > I am not going to download the 200GB (!!!) that it wants me to, so that's as > > far as I can test. > > portcheck -N complains about hardcoded paths in pkg/bitcoind.rc > > > > One thought from me: is there no hope for this to build on !CLANG_ARCHS? > > (You only have COMPILER=base-clang ports-clang). Maybe that is the right way > > to go, since I'm guessing you wouldn't want to run this on a machine that > > doesn't have clang available to it since it's probably far too slow. > > > > In that case, you don't need that CXXFLAGS line. > > > > It doesn't build with ports-gcc and you already said it: "... you > wouldn't want to run this on a machine that doesn't have clang available > to it since it's probably far too slow." > > Yes builds fine without CXXFLAGS. Ok with /var -> ${VARBASE}? > > Thanks for test and review! >
Re: NEW: net/bitcoin
On Sun May 06, 2018 at 01:23:43PM -0400, Brian Callahan wrote: > > On 05/05/18 07:29, Rafael Sadowski wrote: > > *ping* > > > > On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote: > > > Hi ports@ > > > > > > Attached is a new port for bitcoin. Long time ago pascal@ started > > > working on bitcoin in openbsd-wip. I've finished this work and run a full > > > bitcoin node over weeks without problems so far: > > > > > > https://twitter.com/sizeofvoid/status/976586173538885632 > > > > > > $ cat net/bitcoin/pkg/DESCR > > > > > > Bitcoin is an experimental new digital currency that enables instant > > > payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer > > > technology to operate with no central authority: managing transactions > > > and issuing money are carried out collectively by the network. > > > Bitcoin is also the name of the open source software which enables > > > the use of this currency. > > > > > > Ok? Comments? > > > > > > Greetings to the hackerroom. > > > > > > Rafael Sadowski > > > > It reads and builds ok, and bitcoin-qt even launches. > I am not going to download the 200GB (!!!) that it wants me to, so that's as > far as I can test. > portcheck -N complains about hardcoded paths in pkg/bitcoind.rc > > One thought from me: is there no hope for this to build on !CLANG_ARCHS? > (You only have COMPILER=base-clang ports-clang). Maybe that is the right way > to go, since I'm guessing you wouldn't want to run this on a machine that > doesn't have clang available to it since it's probably far too slow. > > In that case, you don't need that CXXFLAGS line. > It doesn't build with ports-gcc and you already said it: "... you wouldn't want to run this on a machine that doesn't have clang available to it since it's probably far too slow." Yes builds fine without CXXFLAGS. Ok with /var -> ${VARBASE}? Thanks for test and review!
Re: NEW: net/bitcoin
On 05/05/18 07:29, Rafael Sadowski wrote: *ping* On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote: Hi ports@ Attached is a new port for bitcoin. Long time ago pascal@ started working on bitcoin in openbsd-wip. I've finished this work and run a full bitcoin node over weeks without problems so far: https://twitter.com/sizeofvoid/status/976586173538885632 $ cat net/bitcoin/pkg/DESCR Bitcoin is an experimental new digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Bitcoin is also the name of the open source software which enables the use of this currency. Ok? Comments? Greetings to the hackerroom. Rafael Sadowski It reads and builds ok, and bitcoin-qt even launches. I am not going to download the 200GB (!!!) that it wants me to, so that's as far as I can test. portcheck -N complains about hardcoded paths in pkg/bitcoind.rc One thought from me: is there no hope for this to build on !CLANG_ARCHS? (You only have COMPILER=base-clang ports-clang). Maybe that is the right way to go, since I'm guessing you wouldn't want to run this on a machine that doesn't have clang available to it since it's probably far too slow. In that case, you don't need that CXXFLAGS line. ~Brian
Re: NEW: net/bitcoin
*ping* On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote: > Hi ports@ > > Attached is a new port for bitcoin. Long time ago pascal@ started > working on bitcoin in openbsd-wip. I've finished this work and run a full > bitcoin node over weeks without problems so far: > > https://twitter.com/sizeofvoid/status/976586173538885632 > > $ cat net/bitcoin/pkg/DESCR > > Bitcoin is an experimental new digital currency that enables instant > payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer > technology to operate with no central authority: managing transactions > and issuing money are carried out collectively by the network. > Bitcoin is also the name of the open source software which enables > the use of this currency. > > Ok? Comments? > > Greetings to the hackerroom. > > Rafael Sadowski
Re: new: net/bitcoin
Welcome, audit it. That would be cool. I guess divide code into separate processes for gui, core and maybe database would be great. I actually looked through patches. They obviously fix staff like include dirs. So you can trust this port as you trust official source. I don't really care about it since I haven't a LOT of bitcoins. BTW I don't really understand how to perform reliable security audit. Remember famous Linux backdoor example? if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) retval = -EINVAL; I looked at this code 3 times before I understand where it is... 17.11.2013, 19:15, "Christian Weisgerber" : > I think everybody who proposes a bitcoin port should consider whether > something that seriously deals with people's money doesn't warrant > special auditing and whether they are prepared to invest that work. > > I'm very uncomfortable with shipping our usual "it seems to build > and run for me" packages and having naive users actually put their > trust in them. But it is 0P3NB5D! 1T MU57 B3 S3KYOOR! > > -- > Christian "naddy" Weisgerber na...@mips.inka.de
Re: new: net/bitcoin
I think everybody who proposes a bitcoin port should consider whether something that seriously deals with people's money doesn't warrant special auditing and whether they are prepared to invest that work. I'm very uncomfortable with shipping our usual "it seems to build and run for me" packages and having naive users actually put their trust in them. But it is 0P3NB5D! 1T MU57 B3 S3KYOOR! -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: new: net/bitcoin
On Thu, 14 Nov 2013 20:30:37 +, Stuart Henderson wrote: > On 2013/11/14 12:18, Aaron wrote: > > On Wed, Nov 13, 2013 at 3:07 PM, Alexander Pakhomov > > wrote: > > > bitcoin-qt also compiles: > > > > > > cd /usr/ports/pobj/bitcoin-.../bitcoin-... > > > bitcoin-qt.pro: remove "-lrt" line > > > qmake4 BOOST_LIBS_SUFFIX=-mt INCLUDE_PATH+=/usr/local/include/db4 > > > gmake > > > > > > Don't know should I make a separate port or it is better to include in > > > this. > > > > Not sure either - but here is a version of just bitcoin-qt :D > > The manpages here conflict with the other port in bitcoin.tar.gz.. > Also I noticed when reading the Makefile that there's an internal copy > of leveldb, can it use leveldb from ports instead? My version in openbsd-wip does that, so maybe you can use that as a starting point. > > Maybe a flavor vs a different port? > > I don't think a flavour makes sense, if you want to build them in the same > port then just subpackage the qt interface, separate ports would be fine with > me too though (but I think I'd have ports/net/bitcoin/qt and > ports/net/bitcoin/daemon or something, so you can use a Makefile.inc so > there's less chance of them getting out-of-sync later). I think the MULTI_PACKAGES approach is the sanest solution; I just didn't bother with it because I didn't need bitcoin-qt anyway.
Re: new: net/bitcoin
On 2013/11/14 12:18, Aaron wrote: > On Wed, Nov 13, 2013 at 3:07 PM, Alexander Pakhomov wrote: > > bitcoin-qt also compiles: > > > > cd /usr/ports/pobj/bitcoin-.../bitcoin-... > > bitcoin-qt.pro: remove "-lrt" line > > qmake4 BOOST_LIBS_SUFFIX=-mt INCLUDE_PATH+=/usr/local/include/db4 > > gmake > > > > Don't know should I make a separate port or it is better to include in this. > > Not sure either - but here is a version of just bitcoin-qt :D The manpages here conflict with the other port in bitcoin.tar.gz.. Also I noticed when reading the Makefile that there's an internal copy of leveldb, can it use leveldb from ports instead? > Maybe a flavor vs a different port? I don't think a flavour makes sense, if you want to build them in the same port then just subpackage the qt interface, separate ports would be fine with me too though (but I think I'd have ports/net/bitcoin/qt and ports/net/bitcoin/daemon or something, so you can use a Makefile.inc so there's less chance of them getting out-of-sync later).
Re: new: net/bitcoin
On Wed, Nov 13, 2013 at 3:07 PM, Alexander Pakhomov wrote: > bitcoin-qt also compiles: > > cd /usr/ports/pobj/bitcoin-.../bitcoin-... > bitcoin-qt.pro: remove "-lrt" line > qmake4 BOOST_LIBS_SUFFIX=-mt INCLUDE_PATH+=/usr/local/include/db4 > gmake > > Don't know should I make a separate port or it is better to include in this. Not sure either - but here is a version of just bitcoin-qt :D Maybe a flavor vs a different port? > > 12.11.2013, 22:31, "Aaron" : > >> On Sat, Jan 12, 2013 at 9:47 AM, David Hill wrote: >>> On Sun, Dec 09, 2012 at 05:09:56PM +0100, Pascal Stumpf wrote: >>> :On Sat, 26 May 2012 15:44:31 +0200, Pascal Stumpf wrote: >>> :> Bitcoin is an experimental new digital currency that enables instant >>> :> payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer >>> :> technology to operate with no central authority: managing transactions >>> :> and issuing money are carried out collectively by the network. >>> :> Bitcoin is also the name of the open source software which enables >>> :> the use of this currency. >>> :> >>> :> >>> :> Of course, mining is not very efficient on OpenBSD, but it is still >>> :> useful to manage your wallet, make transactions etc. >>> :> >>> : >>> :Updated port attached (0.7.1), latest update done by Alex Bula. >>> : >>> :ok? >>> >>> Updated your port to 0.7.2 and successfully using it on i386. >>> Attached is the tarball. >> Updated to 0.8.5 - working great on amd64. FWIW I can't reproduce >> the deleting /dev/null issue. bitcoin.tar.gz Description: GNU Zip compressed data
Re: new: net/bitcoin
bitcoin-qt also compiles: cd /usr/ports/pobj/bitcoin-.../bitcoin-... bitcoin-qt.pro: remove "-lrt" line qmake4 BOOST_LIBS_SUFFIX=-mt INCLUDE_PATH+=/usr/local/include/db4 gmake Don't know should I make a separate port or it is better to include in this. 12.11.2013, 22:31, "Aaron" : > On Sat, Jan 12, 2013 at 9:47 AM, David Hill wrote: >> On Sun, Dec 09, 2012 at 05:09:56PM +0100, Pascal Stumpf wrote: >> :On Sat, 26 May 2012 15:44:31 +0200, Pascal Stumpf wrote: >> :> Bitcoin is an experimental new digital currency that enables instant >> :> payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer >> :> technology to operate with no central authority: managing transactions >> :> and issuing money are carried out collectively by the network. >> :> Bitcoin is also the name of the open source software which enables >> :> the use of this currency. >> :> >> :> >> :> Of course, mining is not very efficient on OpenBSD, but it is still >> :> useful to manage your wallet, make transactions etc. >> :> >> : >> :Updated port attached (0.7.1), latest update done by Alex Bula. >> : >> :ok? >> >> Updated your port to 0.7.2 and successfully using it on i386. >> Attached is the tarball. > Updated to 0.8.5 - working great on amd64. FWIW I can't reproduce > the deleting /dev/null issue.
Re: new: net/bitcoin
On 11/12/13 18:31, Aaron wrote: On Sat, Jan 12, 2013 at 9:47 AM, David Hill wrote: On Sun, Dec 09, 2012 at 05:09:56PM +0100, Pascal Stumpf wrote: :On Sat, 26 May 2012 15:44:31 +0200, Pascal Stumpf wrote: :> Bitcoin is an experimental new digital currency that enables instant :> payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer :> technology to operate with no central authority: managing transactions :> and issuing money are carried out collectively by the network. :> Bitcoin is also the name of the open source software which enables :> the use of this currency. :> :> :> Of course, mining is not very efficient on OpenBSD, but it is still :> useful to manage your wallet, make transactions etc. :> : :Updated port attached (0.7.1), latest update done by Alex Bula. : :ok? Updated your port to 0.7.2 and successfully using it on i386. Attached is the tarball. Updated to 0.8.5 - working great on amd64. FWIW I can't reproduce the deleting /dev/null issue. Hi Aaron, Thanks for the port - I can confirm that it is working well on amd64: port:fred ~> bitcoind -?|head -1 Bitcoin version v0.8.5.0-gef14a26-beta port:fred ~> dmesg|head -4 OpenBSD 5.4-current (GENERIC.MP) #117: Sun Nov 3 11:37:42 MST 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8447131648 (8055MB) avail mem = 8214102016 (7833MB) Cheers Fred
Re: new: net/bitcoin
On Sat, Jan 12, 2013 at 9:47 AM, David Hill wrote: > On Sun, Dec 09, 2012 at 05:09:56PM +0100, Pascal Stumpf wrote: > :On Sat, 26 May 2012 15:44:31 +0200, Pascal Stumpf wrote: > :> Bitcoin is an experimental new digital currency that enables instant > :> payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer > :> technology to operate with no central authority: managing transactions > :> and issuing money are carried out collectively by the network. > :> Bitcoin is also the name of the open source software which enables > :> the use of this currency. > :> > :> > :> Of course, mining is not very efficient on OpenBSD, but it is still > :> useful to manage your wallet, make transactions etc. > :> > : > :Updated port attached (0.7.1), latest update done by Alex Bula. > : > :ok? > > Updated your port to 0.7.2 and successfully using it on i386. > Attached is the tarball. > > Updated to 0.8.5 - working great on amd64. FWIW I can't reproduce the deleting /dev/null issue. bitcoin.tar.gz Description: GNU Zip compressed data
Re: new: net/bitcoin
On 03/19/13 06:53, Pascal Stumpf wrote: Version 0.8.1 of the bitcoin port. Needs the leveldb fix I sent earlier. Bitcoin is an experimental new digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Bitcoin is also the name of the open source software which enables the use of this currency. ok? I would like to see this in ports. I'm using another system for Bitcoin because I didn't get around porting it to my OBSD laptop. Thanks
Re: new: net/bitcoin
On Wed, Mar 20, 2013 at 4:33 PM, Pascal Stumpf wrote: > On Tue, 19 Mar 2013 14:53:59 +0100, Pascal Stumpf wrote: >> Version 0.8.1 of the bitcoin port. Needs the leveldb fix I sent >> earlier. >> >> Bitcoin is an experimental new digital currency that enables instant >> payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer >> technology to operate with no central authority: managing transactions >> and issuing money are carried out collectively by the network. >> Bitcoin is also the name of the open source software which enables >> the use of this currency. >> >> ok? >> > > Grr, now a version that actually builds (forgotten patch). Tested on amd64 - OK from me.
Re: new: net/bitcoin
On Tue, 19 Mar 2013 14:53:59 +0100, Pascal Stumpf wrote: > Version 0.8.1 of the bitcoin port. Needs the leveldb fix I sent > earlier. > > Bitcoin is an experimental new digital currency that enables instant > payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer > technology to operate with no central authority: managing transactions > and issuing money are carried out collectively by the network. > Bitcoin is also the name of the open source software which enables > the use of this currency. > > ok? > Grr, now a version that actually builds (forgotten patch). bitcoin.tgz Description: bitcoin.tgz
Re: new: net/bitcoin
On Sun, Dec 09, 2012 at 05:09:56PM +0100, Pascal Stumpf wrote: :On Sat, 26 May 2012 15:44:31 +0200, Pascal Stumpf wrote: :> Bitcoin is an experimental new digital currency that enables instant :> payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer :> technology to operate with no central authority: managing transactions :> and issuing money are carried out collectively by the network. :> Bitcoin is also the name of the open source software which enables :> the use of this currency. :> :> :> Of course, mining is not very efficient on OpenBSD, but it is still :> useful to manage your wallet, make transactions etc. :> : :Updated port attached (0.7.1), latest update done by Alex Bula. : :ok? Updated your port to 0.7.2 and successfully using it on i386. Attached is the tarball. bitcoin.tgz Description: application/tar-gz
Re: new: net/bitcoin
On Sun, Dec 09, 2012 at 05:09:56PM +0100, Pascal Stumpf wrote: > [...] > ok? There seems to be one superflouus file, patches/patch-srd_db.cpp.org. Can't say anything else yet, it's still building. -- Gregor Best
Re: new: net/bitcoin
On Sat, 26 May 2012 15:44:31 +0200, Pascal Stumpf wrote: > Bitcoin is an experimental new digital currency that enables instant > payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer > technology to operate with no central authority: managing transactions > and issuing money are carried out collectively by the network. > Bitcoin is also the name of the open source software which enables > the use of this currency. > > > Of course, mining is not very efficient on OpenBSD, but it is still > useful to manage your wallet, make transactions etc. > Updated port attached (0.7.1), latest update done by Alex Bula. ok? bitcoin.tgz Description: bitcoin.tgz
Re: new: net/bitcoin
Hi This works for me on i386 after applying the uvm patch here: http://old.nabble.com/Re%3A-uvm_fault-page-fault-on-i386-25-May-2012-snapshot-p33936119.html I'll continue testing once this is fixed in tree Thanks Tom On Sat, May 26, 2012 at 2:44 PM, Pascal Stumpf wrote: > Bitcoin is an experimental new digital currency that enables instant > payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer > technology to operate with no central authority: managing transactions > and issuing money are carried out collectively by the network. > Bitcoin is also the name of the open source software which enables > the use of this currency. > > > Of course, mining is not very efficient on OpenBSD, but it is still > useful to manage your wallet, make transactions etc. >