Author

Topic: Gentoo Linux Ebuild (Read 21535 times)

hero member
Activity: 574
Merit: 504
April 28, 2011, 07:30:12 AM
#65
come to #bitcoin-gentoo on Freenode
sr. member
Activity: 340
Merit: 250
April 28, 2011, 07:28:25 AM
#64
there is a problem with emerging:

Code:
>>> Verifying ebuild manifests

>>> Emerging (1 of 1) net-p2p/bitcoin-9999 from booboo
 * Package:    net-p2p/bitcoin-9999
 * Repository: booboo
 * USE:        amd64 elibc_glibc kernel_linux multilib userland_GNU
 * FEATURES:   sandbox
>>> Unpacking source...
 * subversion update start -->
 *      repository: https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk
At revision 251.
 *    working copy: /usr/portage/distfiles/svn-src/bitcoin/trunk

>>> Source unpacked in /var/tmp/portage/net-p2p/bitcoin-9999/work
>>> Preparing source in /var/tmp/portage/net-p2p/bitcoin-9999/work/bitcoin-9999 ...
 * Applying bitcoin-9999-Makefile.patch ...

 * Failed Patch: bitcoin-9999-Makefile.patch !
 *  ( /usr/local/portage/layman/booboo/net-p2p/bitcoin/files/bitcoin-9999-Makefile.patch )
 *
 * Include in your bugreport the contents of:
 *
 *   /var/tmp/portage/net-p2p/bitcoin-9999/temp/bitcoin-9999-Makefile.patch.out

 * ERROR: net-p2p/bitcoin-9999 failed (prepare phase):
 *   Failed Patch: bitcoin-9999-Makefile.patch!
 *
 * Call stack:
 *     ebuild.sh, line   56:  Called src_prepare
 *   environment, line 3067:  Called bitcoin_src_prepare
 *   environment, line  618:  Called epatch '/usr/local/portage/layman/booboo/net-p2p/bitcoin/files/bitcoin-9999-Makefile.patch'
 *   environment, line 1849:  Called die
 * The specific snippet of code:
 *               die "Failed Patch: ${patchname}!";
 *
 * If you need support, post the output of 'emerge --info =net-p2p/bitcoin-9999',
 * the complete build log and the output of 'emerge -pqv =net-p2p/bitcoin-9999'.
 * This ebuild used the following eclasses from overlays:
 *   /usr/local/portage/layman/booboo/eclass/bitcoin.eclass
 * This ebuild is from an overlay named 'booboo': '/usr/local/portage/layman/booboo/'
 * The complete build log is located at '/var/tmp/portage/net-p2p/bitcoin-9999/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/net-p2p/bitcoin-9999/temp/environment'.
 * S: '/var/tmp/portage/net-p2p/bitcoin-9999/work/bitcoin-9999'
hero member
Activity: 574
Merit: 504
March 02, 2011, 07:08:28 PM
#63
bitcoin-git-9999 ebuild updated
hero member
Activity: 574
Merit: 504
December 24, 2010, 03:26:43 PM
#62
I would love to be able to get this running on my headless gentoo box. Any suggestions on this error:

Yes, I haven't updated the ebuild for svn in a while and the latest patch I produced for monitoraddress no longer works.  Yesterday I decided to use gavin's release at http://github.com/bitcoin/bitcoin and produced a bitcoin-git-9999.ebuild and pushed it to the git repository. I've been rather busy lately and haven't been able to maintain the live bitcoin ebuilds lately, so if anyone would like to take over they are welcome to.

bitcoin-9999 is a live ebuild (against cvs/git?). They can break. Make sure your patch is ok.

Ah, perfect. I shoved


in package.keywords and it works fine although apparently I'm only getting v3.15 Sad

*EDIT: Ahh, but then it segfaults when I set generate to true. Oh well, I just dumped the binary in /usr/bin that seems fine for now

You may also try adding net-p2p/bitcoin-git-9999 into /etc/portage/package.keywords and see if it works for you.  It worked for me on two different architectures.
newbie
Activity: 45
Merit: 0
December 17, 2010, 04:04:16 AM
#61
bitcoin-9999 is a live ebuild (against cvs/git?). They can break. Make sure your patch is ok.

Ah, perfect. I shoved


in package.keywords and it works fine although apparently I'm only getting v3.15 Sad

*EDIT: Ahh, but then it segfaults when I set generate to true. Oh well, I just dumped the binary in /usr/bin that seems fine for now
sr. member
Activity: 340
Merit: 250
December 16, 2010, 09:45:48 PM
#60
shall we post bugs of it here?
if not - it would be the last (from me)

emake failed
 * ERROR: net-p2p/bitcoin-9999 failed:
 *   died running emake, base_src_make
 *
 * Call stack:
 *     ebuild.sh, line   56:  Called src_compile
 *   environment, line 3226:  Called bitcoin_src_compile
 *   environment, line  596:  Called base_src_compile
 *   environment, line  506:  Called base_src_make
 *   environment, line  544:  Called die
 * The specific snippet of code:
 *           emake "[email protected]" || die "died running emake, $FUNCNAME";
 *
 * If you need support, post the output of 'emerge --info =net-p2p/bitcoin-9999',
 * the complete build log and the output of 'emerge -pqv =net-p2p/bitcoin-9999'.
 * This ebuild used the following eclasses from overlays:
 *   /usr/local/portage/layman/booboo/eclass/bitcoin.eclass
 * This ebuild is from an overlay named 'booboo': '/usr/local/portage/layman/booboo/'
 * The complete build log is located at '/var/tmp/portage/net-p2p/bitcoin-9999/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/net-p2p/bitcoin-9999/temp/environment'.
 * S: '/var/tmp/portage/net-p2p/bitcoin-9999/work/bitcoin-9999'


what shall I do?
legendary
Activity: 1658
Merit: 1001
December 16, 2010, 07:48:03 AM
#59
bitcoin-9999 is a live ebuild (against cvs/git?). They can break. Make sure your patch is ok.
newbie
Activity: 45
Merit: 0
December 16, 2010, 07:08:45 AM
#58
I would love to be able to get this running on my headless gentoo box. Any suggestions on this error:

 * Applying bitcoin-monitor.patch ...

 * Failed Patch: bitcoin-monitor.patch !
 *  ( /usr/local/portage/net-p2p/bitcoin/files/bitcoin-monitor.patch )
 *
 * Include in your bugreport the contents of:
 *
 *   /var/tmp/portage/net-p2p/bitcoin-9999/temp/bitcoin-monitor.patch.out

 * ERROR: net-p2p/bitcoin-9999 failed:
 *   Failed Patch: bitcoin-monitor.patch!
 *
 * Call stack:
 *     ebuild.sh, line   56:  Called src_prepare
 *   environment, line 5246:  Called epatch '/usr/local/portage/net-p2p/bitcoin/files/bitcoin-monitor.patch'
 *   environment, line 2216:  Called die
 * The specific snippet of code:
 *               die "Failed Patch: ${patchname}!";
 *
 * If you need support, post the output of 'emerge --info =net-p2p/bitcoin-9999',
 * the complete build log and the output of 'emerge -pqv =net-p2p/bitcoin-9999'.
 * This ebuild is from an overlay: '/usr/local/portage/'
 * The complete build log is located at '/var/tmp/portage/net-p2p/bitcoin-9999/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/net-p2p/bitcoin-9999/temp/environment'.
 * S: '/var/tmp/portage/net-p2p/bitcoin-9999/work/bitcoin-9999/trunk'

>>> Failed to emerge net-p2p/bitcoin-9999, Log file:
legendary
Activity: 1658
Merit: 1001
December 03, 2010, 04:53:36 PM
#57
Ok, I've changed one of my systems to a hardened system and was able to reproduce the bug
on version 0.3.17. Here is the backtrace. No idea what is going wrong.

Code:
gdb bitcoind
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) run
Starting program: /usr/bin/bitcoind
[Thread debugging using libthread_db enabled]
bitcoin server starting
[New Thread 0xb6aa46d0 (LWP 6475)]
[New Thread 0xb6477b70 (LWP 6478)]
[New Thread 0xb5c76b70 (LWP 6479)]
[New Thread 0xb5475b70 (LWP 6480)]
[New Thread 0xb4c74b70 (LWP 6481)]
[New Thread 0xb4473b70 (LWP 6482)]
[New Thread 0xb3c57b70 (LWP 6483)]
[New Thread 0xb3456b70 (LWP 6484)]
[New Thread 0xb2c39b70 (LWP 6485)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb2c39b70 (LWP 6485)]
Detect128BitSSE2 () at main.cpp:2956
2956 main.cpp: No such file or directory.
in main.cpp
(gdb) bt full
#0  Detect128BitSSE2 () at main.cpp:2956
fUseSSE2 =
fPrinted = false
nFamily = 15
nModel = 2
#1  0xb768fdfc in BitcoinMiner () at main.cpp:3313
reservekey = {nIndex = 0, vchPubKey = { >> = {
      _M_impl = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_start = 0x0,
        _M_finish = 0x0, _M_end_of_storage = 0x0}}, }}
nExtraNonce =
nPrevTime =
__PRETTY_FUNCTION__ = "void BitcoinMiner()"
#2  0xb7690e32 in ThreadBitcoinMiner (parg=0x0) at main.cpp:2884
No locals.
#3  0xb6acd96e in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4  0xb6baeb5e in clone () from /lib/libc.so.6
No symbol table info available.

The misbehaving line is:
Code:
if (!fPrinted)

in the following code:

Code:
    // AMD reports a lower model number in 64-bit mode
    if (fAMD && sizeof(void*) > 4 && nFamily * 10000 + nModel >= 160000)
        fUseSSE2 = true;

    static bool fPrinted;
    if (!fPrinted)
    {
        fPrinted = true;
        printf("CPUID %08x family %d, model %d, stepping %d, fUseSSE2=%d\n", nBrand, nFamily, nModel, cpu.nStepping, fUseSSE2);
    }
    return fUseSSE2;

fPrinted is false according to the backtrace, I don't know why this is causing the segfault?
legendary
Activity: 1658
Merit: 1001
November 16, 2010, 11:49:18 AM
#56
Thank you for the information.

I've been searching through the code, but haven't able to find anything yet that might cause the problem.
The part where genproclimit comes into play (until where it is the same as not setting it) is relatively small
and doesn't seem to do strange things. Also, as this code is also the same as the prebuild binaries it seems that
the problem is somewhere else.

Did you already try to get a gdb trace? (there seems also to be a -debug option, might be useful)
full member
Activity: 146
Merit: 100
November 16, 2010, 02:01:52 AM
#55
 another thing, I now have a running bitcoind with mining enabled ( -gen ) but with no genproclimit

 no crash until I set the genproclimit

 wether I have the genproclimit in the config file ( -genproclimit=1 in /etc/conf.d/bitcoin ) or when I set it via bitcoind command line the server crashes
full member
Activity: 146
Merit: 100
November 15, 2010, 10:31:29 PM
#54
profile :
 [7]   hardened/linux/x86/10.0 *
make.profile -> ../usr/portage/profiles/hardened/linux/x86/10.0

 gcc-config :
[10] i686-pc-linux-gnu-4.4.4 *

in make.conf :

CFLAGS="-O2 -march=i686 -pipe"
CHOST="i686-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j3"

CPU :

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
stepping        : 10
cpu MHz         : 2997.000
cache size      : 6144 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
bogomips        : 5999.86
clflush size    : 64
power management:

 any command line you recommend to get more specific details about g++/ld flags ?

legendary
Activity: 1658
Merit: 1001
November 15, 2010, 08:23:04 AM
#53
yes I m using PIE / SSP
I tried the official  binaries , they are working, no segfault


Ok, could you give me some info on the system and your C++/LD-flags?
full member
Activity: 146
Merit: 100
November 15, 2010, 07:25:12 AM
#52
yes I m using PIE / SSP
I tried the official  binaries , they are working, no segfault
legendary
Activity: 1658
Merit: 1001
November 15, 2010, 04:29:41 AM
#51
Pushed bitcoin-0.3.15 ebuild to github.
legendary
Activity: 1658
Merit: 1001
November 15, 2010, 03:09:48 AM
#50
Do you have SSP enabled?

Quote
Issues arising from default SSP

The SSP implementation in gcc-3.x is not perfect, and can cause problems. In particular C++ code can be built incorrectly when SSP is enabled, although the exact details are not clear at the moment.

The SSP implementation in gcc-4.x is completely different, even so far as changing the semantics of the compiler switches. At the time of writing, we have little experience in the SSP implementation in gcc-4.x.


Try the binaries first, if they also give problems, hand the problem to the devs. They might be quicker in pinpointing the problem.
If the problem is not present in the binaries, we might have to add a build flag somewhere (although there is not much difference,
compared with the distributed build scripts).
full member
Activity: 146
Merit: 100
November 15, 2010, 03:03:29 AM
#49
Ok, I'll see if I can find out what is going wrong (please note that I'm not a C++ coder myself).
I was a C coder 10 years ago and had a quick look at the source code but couldnt find anything until now, i m thinking on adding debug to see more precisely where the segv happen

The distributed binary works, right?

 I never run binaries on my servers ;( so i havent tried the binary yet , I ll see if I can give it a try on a testing server.

legendary
Activity: 1658
Merit: 1001
November 15, 2010, 02:53:22 AM
#48
Ok, I'll see if I can find out what is going wrong (please note that I'm not a C++ coder myself).

The distributed binary works, right?
full member
Activity: 146
Merit: 100
November 15, 2010, 02:45:47 AM
#47
 ok after more investigation the problem is not related to ATOM CPU or to my system

 I can build and run any gentoo packages but still have a problem with bitcoin on all the servers using the gentoo hardened pie/ssp toolchain ( http://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml )

 bitcoin is running ok on the servers not using hardened  toolchain

 bitcoin will SIGSEGV on all the server using hardened :

 here is the full strace of the segfault :

Code:
      [pid  8467] write(19, "BitcoinMiner started\n", 21) = 21
      [pid  8467] close(19)                   = 0
      [pid  8467] munmap(0xb7ef7000, 4096)    = 0
      [pid  8467] setpriority(PRIO_PROCESS, 0, 20) = 0
      [pid  8467] open("/var/lib/bitcoin/.bitcoin/debug.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 19
      [pid  8467] fstat64(19, {st_mode=S_IFREG|0600, st_size=8581205, ...}) = 0
      [pid  8467] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef7000
      [pid  8467] fstat64(19, {st_mode=S_IFREG|0600, st_size=8581205, ...}) = 0
      [pid  8467] _llseek(19, 8581205, [8581205], SEEK_SET) = 0
      [pid  8467] write(19, "CPUID 6c65746e family 6, model 2"..., 59) = 59
      [pid  8467] close(19)                   = 0
      [pid  8467] munmap(0xb7ef7000, 4096)    = 0
      [pid  8467] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
      Process 8467 detached


 its always reproducible.

 I also tried disabling the sse2 use flag, nothing changes, same sigsegv problem with or without sse2 flag

 there is no crash if I disable the miner ( -gen=0 option ) so its clear the problem is in the miner code

 I also tried updating myself the ebuild to 0.3.15 , same crash but th strace is different :

Code:
[pid 12260] open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 17
[pid 12260] fstat64(17, {st_mode=S_IFREG|0644, st_size=744, ...}) = 0
[pid 12260] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7db7000
[pid 12260] read(17, "# /etc/hosts:  This file describ"..., 4096) = 744
[pid 12260] read(17, "", 4096)          = 0
[pid 12260] close(17)                   = 0
[pid 12260] munmap(0xb7db7000, 4096)    = 0
[pid 12260] time(NULL)                  = 1289803862
[pid 12260] socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 17
[pid 12260] connect(17, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("213.186.33.99")}, 28) = 0
[pid 12260] gettimeofday({1289803862, 19994}, NULL) = 0
[pid 12260] poll([{fd=17, events=POLLOUT}], 1, 0) = 1 ([{fd=17, revents=POLLOUT}])
[pid 12260] send(17, "\334\16\1\0\0\1\0\0\0\0\0\0\3irc\5lfnet\3org\0\0\1\0\1", 31, MSG_NOSIGNAL) = 31
[pid 12260] poll([{fd=17, events=POLLIN}], 1, 5000
[pid 12263] write(19, "ThreadMessageHandler started\n", 29) = 29
[pid 12263] close(19)                   = 0
[pid 12263] munmap(0xb7db5000, 4096)    = 0
[pid 12263] setpriority(PRIO_PROCESS, 0, 2) = 0
[pid 12263] gettimeofday({1289803862, 20156}, NULL) = 0
[pid 12263] gettimeofday({1289803862, 20177}, NULL) = 0
[pid 12263] nanosleep({0, 99979000}, 
[pid 12261] set_robust_list(0xb4afebe0, 0xc) = 0
[pid 12261] open("/var/lib/bitcoin/.bitcoin/debug.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 18
[pid 12261] fstat64(18, {st_mode=S_IFREG|0600, st_size=8587255, ...}) = 0
[pid 12261] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7db7000
[pid 12261] fstat64(18, {st_mode=S_IFREG|0600, st_size=8587255, ...}) = 0
[pid 12261] _llseek(18, 8587255, [8587255], SEEK_SET) = 0
[pid 12261] write(18, "ThreadSocketHandler started\n", 28) = 28
[pid 12261] close(18)                   = 0
[pid 12261] munmap(0xb7db7000, 4096)    = 0
[pid 12261] select(6, [5], [], [], {0, 50000}
[pid 12235] +++ killed by SIGSEGV +++
[pid 12260] +++ killed by SIGSEGV +++
[pid 12233] +++ killed by SIGSEGV +++
[pid 12262] +++ killed by SIGSEGV +++
[pid 12263] +++ killed by SIGSEGV +++
[pid 12261] +++ killed by SIGSEGV +++
[pid 12234] +++ killed by SIGSEGV +++
+++ killed by SIGSEGV +++


with 0.3.15 the crash happens later, after :

Code:
CPUID 6c65746e family 6, model 23, stepping 10, fUseSSE2=0
ThreadIRCSeed started
ThreadMessageHandler started
ThreadSocketHandler started

legendary
Activity: 1658
Merit: 1001
October 23, 2010, 07:04:41 AM
#46
Just see if your system is sane, if it is I'll contact you for the whole strace.
full member
Activity: 146
Merit: 100
October 22, 2010, 06:39:18 PM
#45

EDIT : for now forget about this bugreport, theres something weird on this server and the problem could be unrelated with the ebuild, I m investigating and  will update this within 24-48 hours.


Yes, a complete strace would be more useful. I don't see anything strange in this part.
Did you also try ebuilds before 0.3.13, did they give issues?

Also give a bit more information about your system (is is x86 or ~x86 for example).

 nop tried only 0.3.13 and 0.3.14 until now, dont know how to get older ebuilds with git ;(

 the system is x86 but I added
Code:
=net-p2p/bitcoin-0.3.14 ~x86

in /etc/portage/package.keywords

 also all my servers are gentoo hardened / grsec, but i m 99% its not related ( no grsec log message concerning bitcoind, its just a segfault, nothing more, and bitcoind is running on other dedicate servers )

 since the strace can contain sensitive information I d prefer not to put it publicly here, could you send me a PM with you email or come on the #bitcoin-dev IRC channel ?

legendary
Activity: 1658
Merit: 1001
October 22, 2010, 04:16:13 PM
#44

(  I can provide the complete strace if needed )

 this is true with the 2 last ebuilds, 0.3.13 and 0.3.14

 NOTE : the BINARY 32/bitcoind is running well on the same ATOM CPU server



Yes, a complete strace would be more useful. I don't see anything strange in this part.
Did you also try ebuilds before 0.3.13, did they give issues?

Also give a bit more information about your system (is is x86 or ~x86 for example).
full member
Activity: 146
Merit: 100
October 22, 2010, 10:15:35 AM
#43
 for information the ebuild is working perfectly on my intel servers, but not working on a ATOM CPU :

Code:
+++ killed by SIGSEGV +++
Segmentation fault

 Logs :

Code:
Oct 22 15:41:46 mx kernel: bitcoind[32466]: segfault at 3042924 ip 161ab4c0 sp 452fed50 error 4 in bitcoind[1614b000+13b000]
Oct 22 15:42:04 mx kernel: bitcoind[32648]: segfault at 1042924 ip 1272d4c0 sp 4f0fad50 error 4 in bitcoind[126cd000+13b000]
Oct 22 15:43:03 mx kernel: bitcoind[32730]: segfault at 2042924 ip 16eea4c0 sp 4a9fad50 error 4 in bitcoind[16e8a000+13b000]
Oct 22 15:46:26 mx kernel: bitcoind[753]: segfault at 1042924 ip 143244c0 sp 46ffed50 error 4 in bitcoind[142c4000+13b000]

CPU :

Code:
mx bitcoin_gentoo_ebuild # cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 28
model name      : Intel(R) Atom(TM) CPU  330   @ 1.60GHz
stepping        : 2
cpu MHz         : 1596.057
cache size      : 512 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm
bogomips        : 3192.11
clflush size    : 64
cache_alignment : 64
address sizes   : 32 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 28
model name      : Intel(R) Atom(TM) CPU  330   @ 1.60GHz
stepping        : 2
cpu MHz         : 1596.057
cache size      : 512 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 2
apicid          : 2
initial apicid  : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm
bogomips        : 3192.29
clflush size    : 64
cache_alignment : 64
address sizes   : 32 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 28
model name      : Intel(R) Atom(TM) CPU  330   @ 1.60GHz
stepping        : 2
cpu MHz         : 1596.057
cache size      : 512 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm
bogomips        : 3192.27
clflush size    : 64
cache_alignment : 64
address sizes   : 32 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 28
model name      : Intel(R) Atom(TM) CPU  330   @ 1.60GHz
stepping        : 2
cpu MHz         : 1596.057
cache size      : 512 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 2
apicid          : 3
initial apicid  : 3
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm
bogomips        : 3192.30
clflush size    : 64
cache_alignment : 64
address sizes   : 32 bits physical, 48 bits virtual
power management:

Code:
CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer"
CXXFLAGS="-O2 -march=native -pipe -fomit-frame-pointer"

CHOST="i686-pc-linux-gnu"

end of the strace :

Code:
stat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
close(11)                               = 0
munmap(0x515e5000, 4096)                = 0
gettimeofday({1287755265, 385568}, NULL) = 0
time(NULL)                              = 1287755265
time(NULL)                              = 1287755265
mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x50de5000
mprotect(0x50de5000, 4096, PROT_NONE)   = 0
clone(child_stack=0x515e5484, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x515e5bd8, {entry_number:6, base_addr:0x515e5b70, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0x515e5bd8) = 832
mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x505e4000
mprotect(0x505e4000, 4096, PROT_NONE)   = 0
clone(child_stack=0x50de4484, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x50de4bd8, {entry_number:6, base_addr:0x50de4b70, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0x50de4bd8) = 833
gettimeofday({1287755265, 386429}, NULL) = 0
gettimeofday({1287755265, 386521}, NULL) = 0
nanosleep({999, 999908000}, 

(  I can provide the complete strace if needed )

 this is true with the 2 last ebuilds, 0.3.13 and 0.3.14

 NOTE : the BINARY 32/bitcoind is running well on the same ATOM CPU server

legendary
Activity: 1658
Merit: 1001
October 21, 2010, 05:47:47 PM
#42
bitcoin-0.3.14.ebuild is on github.
full member
Activity: 146
Merit: 100
October 18, 2010, 04:57:20 PM
#41
 I updated the ebuild with git, but you ll have to rebuild the manifest in the ebuild :

Code:
!!! Digest verification failed:
!!! /usr/local/portage/net-p2p/bitcoin/files/Makefile.gentoo
!!! Reason: Filesize does not match recorded size

 I did it :
Code:
cd net-p2p/bitcoin/
ebuild bitcoin-0.3.13.ebuild manifest
Appending /root/bitcoin_gentoo_ebuild to PORTDIR_OVERLAY...
>>> Creating Manifest for /root/bitcoin_gentoo_ebuild/net-p2p/bitcoin
cp -af net-p2p/ /usr/local/portage/
emerge bitcoin

 and it WORKS !

Code:
 * Enabling SSE2 code
>>> Source prepared.

many thanks biomike !

now building, I ll give more feedback later
legendary
Activity: 1658
Merit: 1001
October 18, 2010, 02:12:08 PM
#40
I see my Makefile.gentoo got reverted to an older version, caused by an update by mizerydearea. That is causing the problem.

I'll see if I can get my version in again.

Corrected Makefile.gentoo is in github again
legendary
Activity: 1470
Merit: 1003
Bringing Legendary Har® to you since 1952
October 18, 2010, 09:37:01 AM
#39
Never mind my previous post.

I've studied the code of the ebuild and i know what the @@[email protected]@ is.

This "@@[email protected]@" gets replaced by "-DFOURWAYSSE2" by emerge, which is defined in the ebuild. If it is not replaced, something wrong is going on with the ebuild.

My advice: try the older version (as it worked for me).
legendary
Activity: 1470
Merit: 1003
Bringing Legendary Har® to you since 1952
October 18, 2010, 09:17:31 AM
#38
I think You should ask this question at Gentoo Forums as it seems that Your Gentoo is misconfigured somehow.

They will know why is Your SSE2 variable not set.

BTW,
Did You do $ env-update && source /etc/profile as root after changing your CFLAGS ?
Alternatively, You may restart Your computer - that should work too.
full member
Activity: 146
Merit: 100
October 18, 2010, 06:32:55 AM
#37
my CPU is :

model name     : Intel(R) Core(TM)2 Duo CPU     E6550  @ 2.33GHz
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr lahf_lm

should have this sse2 support according to the flags

EDIT :

 same problem after changing my CFLAGS  ;(

 I tried :

CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"

and

CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer"

I think that Your cflags are wrong (too general). You need to set them for specifically Your processor type, so SSE2 will be detected and set.
But i might be wrong.

Code:
CFLAGS="-O2 -mtune=i686 -pipe"
declare -x CXXFLAGS="-O2 -mtune=i686 -pipe"

Look at mine in comparison:

Code:
CFLAGS="-march=k8 -O2 -pipe"
CXXFLAGS="-march=k8 -O2 -pipe"

Those are set specifically for AMD64 processor with SSE2 support.
Another thing is that perhaps Your processor does not support SSE2 ?

You could post Your hardware specs.

----
EDIT:
Also, here are lists for safe Gentoo CFLAGS for every Intel/AMD processor:
http://en.gentoo-wiki.com/wiki/Safe_Cflags/AMD
http://en.gentoo-wiki.com/wiki/Safe_Cflags/Intel
legendary
Activity: 1470
Merit: 1003
Bringing Legendary Har® to you since 1952
October 18, 2010, 06:05:43 AM
#36
I think that Your cflags are wrong (too general). You need to set them for specifically Your processor type, so SSE2 will be detected and set.
But i might be wrong.

Code:
CFLAGS="-O2 -mtune=i686 -pipe"
declare -x CXXFLAGS="-O2 -mtune=i686 -pipe"

Look at mine in comparison:

Code:
CFLAGS="-march=k8 -O2 -pipe"
CXXFLAGS="-march=k8 -O2 -pipe"

Those are set specifically for AMD64 processor with SSE2 support.
Another thing is that perhaps Your processor does not support SSE2 ?

You could post Your hardware specs.

----
EDIT:
Also, here are lists for safe Gentoo CFLAGS for every Intel/AMD processor:
http://en.gentoo-wiki.com/wiki/Safe_Cflags/AMD
http://en.gentoo-wiki.com/wiki/Safe_Cflags/Intel
legendary
Activity: 1470
Merit: 1003
Bringing Legendary Har® to you since 1952
October 18, 2010, 05:36:28 AM
#35
Clearly i can see that Your makefile is not reading the @@[email protected]@ variable.
Another question is, WHY.

I am using exactly the same ebuild as You are and everything works.

Perhaps something is wrong with Your cflags. Check make.conf. perhaps You should add processor type/architecture to the $CFLAGS variable.

----
You can post Your make.conf here, i will take a look at it.


----
EDIT: Correction, I'm not using the same ebuild as You, I'm using its older version.
Perhaps something broke later ?
full member
Activity: 146
Merit: 100
October 18, 2010, 05:09:05 AM
#34
bitcoin-0.3.13 ebuild is now available. Made some small changes in the process (bitcoin is C++, so renamed the CFLAGS to CXXFLAGS).

Have fun.

 hi,

 I m new to bitcoin and have just built bitcoin on my gentoo using your ebuild :
http://github.com/mizerydearia/bitcoin_gentoo_ebuild/tree/master

 I use gentoo for years but never had to use a custom ebuild until now, so I had to search how to use it .

 My small contribution for the next one wanted to test bitcoin on gentoo, I just did :

 First I added in make.conf :
Code:
PORTDIR_OVERLAY=/usr/local/portage
to be able to use a custon ebuild

 Then :

Code:
emerge git # install git
git clone http://github.com/mizerydearia/bitcoin_gentoo_ebuild.git #to get the ebuild
cp -af net-p2p /usr/local/portage # put the ebuild in the overlay
emerge -pv bitcoin # check everything is ok and see the default use flags


then  in /etc/portage/package.use :

Code:
=net-p2p/bitcoin-0.3.13  nls sse2 daemon -gui

and in /etc/portage/package.keywords
Code:
=net-p2p/bitcoin-0.3.13         ~x86

 and finally build it :

Code:
emerge -pv bitcoin # check again the useflags
emerge bitcoin # build and install it

but I got :

Code:
>>> Unpacking source...
>>> Unpacking bitcoin-0.3.13-linux.tar.gz to /var/tmp/portage/net-p2p/bitcoin-0.3.13/work
>>> Source unpacked in /var/tmp/portage/net-p2p/bitcoin-0.3.13/work
>>> Preparing source in /var/tmp/portage/net-p2p/bitcoin-0.3.13/work/bitcoin-0.3.13 ...
 * Berkeley DB:
include version 4.8
 * Enabling SSE2 code
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/net-p2p/bitcoin-0.3.13/work/bitcoin-0.3.13 ...
>>> Source configured.
>>> Compiling source in /var/tmp/portage/net-p2p/bitcoin-0.3.13/work/bitcoin-0.3.13 ...
make bitcoind
g++ -c -O2 -mtune=i686 -pipe -Wno-invalid-offsetof -Wformat @@[email protected]@ -I"/usr/include" -I"/usr/include/crypto++" -I"/usr/include/db4.8"  -o obj/nogui/util.o util.cpp
g++: @@[email protected]@: No such file or directory
util.cpp: In function 'void ShrinkDebugFile()':
util.cpp:739: warning: ignoring return value of 'size_t fwrite(const void*, size_t, size_t, FILE*)', declared with attribute warn_unused_result
make: *** [obj/nogui/util.o] Error 1
 * ERROR: net-p2p/bitcoin-0.3.13 failed:
 *   emake bitcoind failed
 *
 * Call stack:
 *     ebuild.sh, line  54:  Called src_compile
 *   environment, line 5203:  Called die
 * The specific snippet of code:
 *           emake bitcoind || die "emake bitcoind failed";
 *
 * If you need support, post the output of 'emerge --info =net-p2p/bitcoin-0.3.13',
 * the complete build log and the output of 'emerge -pqv =net-p2p/bitcoin-0.3.13'.
 * This ebuild is from an overlay: '/usr/local/portage/'
 * The complete build log is located at '/var/tmp/portage/net-p2p/bitcoin-0.3.13/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/net-p2p/bitcoin-0.3.13/temp/environment'.
 * S: '/var/tmp/portage/net-p2p/bitcoin-0.3.13/work/bitcoin-0.3.13'

>>> Failed to emerge net-p2p/bitcoin-0.3.13


any ideas ? did I miss something ? should I disable this sse2 ?

full build log : http://paste.pocoo.org/show/276889/
build environment : http://paste.pocoo.org/show/276890/
hero member
Activity: 574
Merit: 504
October 08, 2010, 01:23:05 PM
#33
What github username do you use?  I'll add commit access.
legendary
Activity: 1470
Merit: 1003
Bringing Legendary Har® to you since 1952
October 08, 2010, 04:23:23 AM
#32
I do not have an nVidia gpu and cannot afford to buy anything for the foreseeable future.  If another gentoo user is willing to provide an ebuild for the CUDA client, that would be appreciated.  I can provide access to the github repository if somene is willing to contribute a CUDA ebuild.  Otherwise instead of an entirely separate ebuild, if there are patches (just like the others) that can be applied when "cuda" USEFLAG is enabled, then you're welcome to modify my ebuild as well.

I will contribute a CUDA ebuild, once i get the damn makefile to work.
I guess perhaps this weekend.
newbie
Activity: 7
Merit: 0
October 08, 2010, 04:03:05 AM
#31
As CUDA isn't in the main releases yet, I'm not going to include it (my goal is to get it as stable as possible to get it included into the main gentoo tree). Mizerydearia is taking care of the live ebuild and might want to include it.

Thanks for the replies, getting it into the main tree is indeed a lot more important. Good luck! Smiley
legendary
Activity: 1658
Merit: 1001
October 05, 2010, 02:52:43 AM
#30
 Otherwise instead of an entirely separate ebuild, if there are patches (just like the others) that can be applied when "cuda" USEFLAG is enabled, then you're welcome to modify my ebuild as well.

I think that would be the way to go. If the patches are right you could build it with USE="cuda", but the program would just not use it. People with Cuda hardware could then test it for you.
hero member
Activity: 574
Merit: 504
October 04, 2010, 08:07:55 PM
#29
I do not have an nVidia gpu and cannot afford to buy anything for the foreseeable future.  If another gentoo user is willing to provide an ebuild for the CUDA client, that would be appreciated.  I can provide access to the github repository if somene is willing to contribute a CUDA ebuild.  Otherwise instead of an entirely separate ebuild, if there are patches (just like the others) that can be applied when "cuda" USEFLAG is enabled, then you're welcome to modify my ebuild as well.
legendary
Activity: 1658
Merit: 1001
October 04, 2010, 05:13:53 PM
#28
As CUDA isn't in the main releases yet, I'm not going to include it (my goal is to get it as stable as possible to get it included into the main gentoo tree). Mizerydearia is taking care of the live ebuild and might want to include it.
newbie
Activity: 7
Merit: 0
October 04, 2010, 02:13:54 PM
#27
Any chance of a CUDA use flag, maybe restricted to a certain revision? Grin
legendary
Activity: 1658
Merit: 1001
October 01, 2010, 02:32:15 AM
#26
bitcoin-0.3.13 ebuild is now available. Made some small changes in the process (bitcoin is C++, so renamed the CFLAGS to CXXFLAGS).

Have fun.
hero member
Activity: 574
Merit: 504
September 29, 2010, 01:44:08 PM
#25
svn ebuild: bitcoin-9999.ebuild updated (currently revision 157)

https://bitcointalksearch.org/topic/m.14576
https://bitcointalksearch.org/topic/m.14575
hero member
Activity: 574
Merit: 504
September 19, 2010, 07:04:45 PM
#24
bitcoin-9999.ebuild tested to work with latest svn snapshot 156: https://bitcointalksearch.org/topic/m.13219
Also, fixed this, however, init script is still buggy/unfinished.
hero member
Activity: 574
Merit: 504
September 18, 2010, 07:15:18 PM
#23
Updated bitcoin-9999.ebuild to work with revision 155
legendary
Activity: 1658
Merit: 1001
September 07, 2010, 03:59:08 PM
#22
Updated the ebuild on github for version 0.3.12.
legendary
Activity: 1658
Merit: 1001
September 05, 2010, 03:24:00 PM
#21
You should specify which ebuild is yours so that others know.  Currently there are two ebuild versions in the repository.

Message says:
"bitcoin-0.3.11 ebuild from BioMike"
hero member
Activity: 574
Merit: 504
September 05, 2010, 02:30:57 PM
#20
You should specify which ebuild is yours so that others know.  Currently there are two ebuild versions in the repository.

You should specify which ebuild is yours so that others know.  Currently there are two ebuild versions in the repository.

Message says:
"bitcoin-0.3.11 ebuild from BioMike"

Ah, I didn't check git repository
legendary
Activity: 1658
Merit: 1001
September 05, 2010, 06:33:29 AM
#19
My current ebuild is now also available from github. Smiley

Please test.
legendary
Activity: 1658
Merit: 1001
September 04, 2010, 03:51:04 AM
#18
domo is not usable in this case (bitcoin doesn't use the standard gettext localisation (po) dir). Bitcoin doesn't handle gettext directly, as far as I can see, so no dependency on gettext.
legendary
Activity: 1658
Merit: 1001
September 03, 2010, 01:11:59 AM
#17
Some interesting tips in there (last part), especially the domo command. The gui/daemon flags aren't a big issue currently. Development of an ebuild isn't working to an end point, but always ongoing. Splitting isn't useful here, can be done, but the package is IMHO to small for a split.
hero member
Activity: 574
Merit: 504
September 02, 2010, 04:22:58 PM
#16
http://devmanual.gentoo.org/ebuild-writing/variables/index.html

freenode / #gentoo-dev-help:
Quote
In regards to compiling a package (bitcoin) from source and using useflags to determine whether to compile bitcoin binary (gui requiring wxwidgets-2.9) and/or bitcoind binary (daemon), which useflag method does anyone suggest: use "gui" and "daemon", use "wxwidgets" or something else?
Does it matter or is it important what useflags are used?
Perhaps it would be acceptable to use useflags "bitcoin" and "bitcoind?"
mizerydearia: maybe client and server use-flags are better?
nao, I don't think so because bitcoin is a gui-based p2p client that connects to the p2p network and bitcoind is a daemon-based p2p client that connects tot he p2p network.
Both have server and client characteristics
mizerydearia: they share some code or they are completly different?
nao: They share code
mizerydearia: they share some libs or other resources? e.g. Can you compile +gui -daemon, install it, then compile -gui +daemon and install again without collision with previous?
hmm, I used "wxidgets" and "daemon" useflags.  "wxwidgets" provides gui binary and "daemon" provides daemon and init.d/conf.d scripts
It is possible to install only the gui or only the daemon
mizerydearia: IMHO wxidgets is not the best variant, maybe use "gui"?
hmm, really?  I thought it was better than gui
mizerydearia: gui is more generic
And in the case in future that a second gui is available to be compiled that isn't reliant on wxwidgets, then how to separate them?
gui2?
mizerydearia: hm... seems you are right
mizerydearia: can this package be splitted into two?
two separate ebuild
ebuilds
I suppose, but they would download content from same repository and use same files
and there only be very minor difference in indicating to build bitcoind or bitcoin binary.
It would seem pointless to split into two.
dry (don't repeat yourself)?
mizerydearia: IMHO, if files are not overlap... splitting may be useful
nao, Can you provide examples of ebuilds in portage that have been split?
mizerydearia: dev-games/renpy -> dev-games/renpy, dev-games/renpy-modules is splitted by me in sunrise Wink
Any examples in portage?
in main?  not sure of name
mizerydearia: but no, there was a special reason for that
mizerydearia: try this:
mizerydearia: cat /var/db/pkg/*/*/SRC_URI | tr ' ' '\n' | grep '^http\|^ftp\|^mirror' | sed '[email protected]^.*/\([^/]*\)[email protected]\[email protected]' | sort | uniq -dc | sort -n
mizerydearia: hmm... there are some bug in my script;) wait...
mizerydearia: *-ant packages, vim-core and gvim
mizerydearia: i.e. splitting is not used widely
I agree
mizerydearia: then not forget to test if at last one of the flags enabled
mizerydearia: you can use confutils.eclass for that

Quote
nao, Here is the ebuild.  How does it look? http://github.com/mizerydearia/bitcoin_gentoo_ebuild/blob/master/net-p2p/bitcoin/bitcoin-9999.ebuild
mizerydearia: The name of ebuild (package) can be removed from description
mizerydearia: Add / to the end of HOMEPAGE
mizerydearia: bitcoin in SRC_URI can be replaced by ${PN}
mizerydearia: sort DEPEND
mizerydearia: min version of app-admin/eselect-wxwidgets in portage is 1.1, so you can drop version
mizerydearia: using ${PN} in enewuser... don`t know, better to ask someone on the channel
mizerydearia: don`t use 'cd trunk', you can set S variable for that
mizerydearia: try to use emake instead of make
S variable?
$ grep "enewuser.*PN" */*/*.ebuild
Shows a couple packages using ${PN}
Not too many though
nao, Thanks for tips.  Anything else?
mizerydearia: lines 45,46 can be expanded to more lines
mizerydearia: inlines with if fi is not readable
mizerydearia: nls? needs gettext, or maybe virtual/libintl
Which is better to rely on: sys-devel/gettext or virtual/libintl?
I'll use sys-devel/gettext
mizerydearia: don`t know. but many of ebuilds in portage rely on sys-devel/gettext
mizerydearia: I just found 'domo' helper Smiley you can use it for .mo files
mm, domo?
mizerydearia: And, I think, if LINGUAS is not set, you need to install all mo files
ah
Only a few ebuilds use domo
Very few even
mizerydearia: yes, but you can use it:)
mizerydearia: don`t know much about stuff on lines 56-70. hope you know it better
mizerydearia: I don`t have more comments on your ebuild
legendary
Activity: 1658
Merit: 1001
September 02, 2010, 04:13:19 PM
#15
On my side, documentation (readme and license) are installed, and a .desktop menu entry is made when the gui is installed (to start bitcoin from the menu). Did some permission fixing for /var/lib/bitcoin (daemon), but not validated yet if it is correct.
hero member
Activity: 574
Merit: 504
September 02, 2010, 12:04:25 AM
#14
http://github.com/mizerydearia/bitcoin_gentoo_ebuild
I updated bitcoin-9999.ebuild
Any feedback is appreciated.
legendary
Activity: 1658
Merit: 1001
August 31, 2010, 03:23:31 PM
#13
Ebuild for net-p2p/bitcoin is in overlay "booboo".
http://bin.mypage.sk/FILES/bitcoin-9999-Makefile.patch is patch for makefile.unix to compile bitcoin with system boost and wxGTK.
Use overlay "dirtyepic" for wxGTK:2.9.

wxGTK 2.9 is already in tree. I've already send mizerydearia an ebuild with makefile to build bitcoind and bitcoin based on use flags with autodetected berkdb, cflags and ldflags. Also localisation files are installed based on LINGUAS. For bitcoind init.d script is installed that seem to work fine under the bitcoin user. The ebuild isn't finished yet, but it is getting along.
full member
Activity: 212
Merit: 100
August 31, 2010, 02:42:14 PM
#12
Ebuild for net-p2p/bitcoin is in overlay "booboo".
http://bin.mypage.sk/FILES/bitcoin-9999-Makefile.patch is patch for makefile.unix to compile bitcoin with system boost and wxGTK.
Use overlay "dirtyepic" for wxGTK:2.9.
hero member
Activity: 574
Merit: 504
August 29, 2010, 02:42:02 AM
#11
Thanks to BioMike/Myckel for pointing out http://devmanual.gentoo.org/ebuild-writing/file-format/index.html I used the official header provided at /usr/portage/header.txt
administrator
Activity: 4228
Merit: 8647
August 29, 2010, 02:05:01 AM
#10
Any ideas on proper or best method to "fix" this?  I am not so knowledgeable of copyright.

Including "Copyright 1999-2010 Gentoo Foundation" didn't assign your copyright to the Gentoo Foundation.

Looking at this, you can just remove the header (and the other comments if they're copied). It's pretty generic stuff.

If the work is not derivative, there's no legal risk in placing it under another license or even keeping full copyright. Old code will still be usable under the GPL, but new code will be under the new license only (you aren't required to put it under the GPL if you're the sole copyright holder).

For a derivative work, you would change the header to something like this:
Code:
# Copyright 2010 mizerydearia
# Distributed under the terms of the GNU General Public License v2
# Based on the ebuild for LightBlue:
# /var/cvsroot/gentoo-x86/app-mobilephone/lightblue/lightblue-0.4.ebuild,v 1.3 2010/03/27 17:57:36 arfrever Exp
# Copyright 1999-2010 Gentoo Foundation
I don't think it is derivative, though, if you remove the header.

(IANAL)
hero member
Activity: 574
Merit: 504
August 29, 2010, 12:31:06 AM
#9
Sent as a private message, reposting here since I am unfamiliar with how to prepare an ebuild to support foreign languages.
I had  a problem with emerging boinc-9999 - can u help me to fix it?
Quote
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.4/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lboost_system
collect2: выполнение ld завершилось с кодом возврата 1
make: *** [bitcoin] Error 1
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/net-p2p/bitcoin-9999/work/bitcoin-9999 ...
>>> Source configured.
>>> Compiling source in /var/tmp/portage/net-p2p/bitcoin-9999/work/bitcoin-9999 ...
make -j3
make: *** Не заданы цели и не найден make-файл.  Останов.
emake failed
>>> Source compiled.
>>> Test phase [not enabled]: net-p2p/bitcoin-9999

>>> Install bitcoin-9999 into /var/tmp/portage/net-p2p/bitcoin-9999/image/ category net-p2p
!!! dobin: bitcoin does not exist
dobin failed
!!! dobin: bitcoind does not exist
dobin failed
>>> Completed installing bitcoin-9999 into /var/tmp/portage/net-p2p/bitcoin-9999/image/

 * QA Notice: file does not exist:
 *
 *    dobin: bitcoin does not exist
 *    dobin: bitcoind does not exist

>>> Installing (1 of 1) net-p2p/bitcoin-9999
>>> Auto-cleaning packages...
hero member
Activity: 574
Merit: 504
August 29, 2010, 12:28:56 AM
#8
Code:
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/app-mobilephone/lightblue/lightblue-0.4.ebuild,v 1.3 2010/03/27 17:57:36 arfrever Exp $

That header Wink

Oooh.

Quote from: #gentoo
necrodearia:  if you wrote the ebuild, I think you could remove the lines.
How much has to be left of the originals for it to be considered derivitave?

Quote from: #gentoo-dev-help
I wrote an ebuild and released it on github.  I mistakenly left in the three lines starting with # Copyright 1999-2010 Gentoo Foundation from copying from another ebuild file.  Since I had released the file with that in the header, do I no longer own the copyright?
https://bitcointalksearch.org/topic/m.11414
If anyone has downloaded it, you would have a difficult time suing them.
That isn't my intention.  I would like to maintain gpl if I am able to.
Also, since you copied an existing ebuild, yours would probably be considered a derrivative work under the GPL.
I agree.  How can I proceed safely so that my derivation is still acceptable?  Is it okay to remove the $Header line?
I'm not an expert on the GPL, but I believe you need to maintain a record of the original author(s).
mm, I imagine so.  However, someone pointed out that I should fix the header.  I am uncertain how to "fix" it.

Any ideas on proper or best method to "fix" this?  I am not so knowledgeable of copyright.
legendary
Activity: 1658
Merit: 1001
August 27, 2010, 06:39:24 PM
#7
I used the live ebuild as a base to make a new ebuild against 0.3.10. The daemon seems to build fine, but for the graphical client I still need to adjust the Makefile (whole wxGTK part is missing there), but the ebuild already takes most of wxGTK into account. The daemon/graphical client are build on basis of use flags.
sr. member
Activity: 340
Merit: 250
August 27, 2010, 05:31:30 PM
#6
ebuild for bitcoin-9999 was updated. I had installed it just with "emerge bitcoin" .
Just synced overlay (booboo) before.
p.s. it would be excelent to make bitcoind .
legendary
Activity: 1658
Merit: 1001
August 27, 2010, 02:52:53 PM
#5
1) Remind that you will need to fix the header.
I don't understand this.  Which header?

Code:
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/app-mobilephone/lightblue/lightblue-0.4.ebuild,v 1.3 2010/03/27 17:57:36 arfrever Exp $

That header Wink

4) /home/bticoin?
I don't see where I misspelled bitcoin.  Which file?

My mistake. I meant to write /home/bitcoin. My point is that this should be /var/lib/bitcoin.

5) Strip optimizations from the Makefile and let the user provide them (or strip them properly)
I am uncertain what "optimizations" are.

Things like "-msse2 -O3 -march=amdfam10". Gentoo users normally specify them themselves in /etc/make.conf.

6) Don't build static code. I have a Makefile that builds dynamic code. If you want I can send it to you. You will need to make changes to it.
I am not familiar with which parts of code are static and could be converted to dynamic.  I only prepared an ebuild because it seems nobody else has.  I am not skilled enough to perfect the ebuild, however, if anyone else would like to contribute towards making it better, I set up a git repository: http://github.com/mizerydearia/bitcoin_gentoo_ebuild

I can help you with that. One other thing that might be nice is an init.d script to start and stop the daemon at boot. oh... it's already there.
hero member
Activity: 574
Merit: 504
August 27, 2010, 04:03:27 AM
#4
Last time I tried $(shell /usr/bin/wx-config), there was immediate hollering about build problems with it.  There wasn't time to investigate at the time.

One problem with $(shell /usr/bin/wx-config) is it will pick up any version (wx 2.8 ) and any configuration (non-UTF-8 ) of wxWidgets that happens to be there.  -lwx_gtk2ud-2.9 only matches the right configuration.  It fails if wxWidgets was built with the wrong configuration.

For reference purpose, Gentoo has the following work-around for specific wxWidgets versions:

Code:
$ eselect wxwidgets list
Available wxWidgets profiles:
  [1]   gtk2-ansi-release-2.6
  [2]   gtk2-unicode-2.9 *
  [3]   gtk2-unicode-release-2.6
  [4]   gtk2-unicode-release-2.8

$ /usr/bin/wx-config --version
2.9.1

# eselect wxwidgets set 1

Setting wxWidgets profile to gtk2-ansi-release-2.6

$ /usr/bin/wx-config --version
2.6.4

I'm not sure about other distros though.


Quote
This is because on my system the path is /usr/include/wx-2.9/wx/wx.h
Why is it there?  Was it included by the OS, or did you have to build it?  If you built it, I wonder why it would put itself in a different place.

1) Remind that you will need to fix the header.
I don't understand this.  Which header?

4) /home/bticoin?
I don't see where I misspelled bitcoin.  Which file?

5) Strip optimizations from the Makefile and let the user provide them (or strip them properly)
I am uncertain what "optimizations" are.

6) Don't build static code. I have a Makefile that builds dynamic code. If you want I can send it to you. You will need to make changes to it.
I am not familiar with which parts of code are static and could be converted to dynamic.  I only prepared an ebuild because it seems nobody else has.  I am not skilled enough to perfect the ebuild, however, if anyone else would like to contribute towards making it better, I set up a git repository: http://github.com/mizerydearia/bitcoin_gentoo_ebuild
legendary
Activity: 1658
Merit: 1001
August 27, 2010, 01:22:35 AM
#3
Some things:

1) Remind that you will need to fix the header.
2) wxgtk is only needed when building the gui, not the daemon (make that use flag dependable)
3) gtk+ is then dependency of wxgtk, don't ask for it yourself.
4) Check other programs if and how they use wxwidgets through eselect (you can have 2.6 and 2.8 slotted on the same system, you will need 2.9)
4) /home/bticoin?
5) Strip optimizations from the Makefile and let the user provide them (or strip them properly)
6) Don't build static code. I have a Makefile that builds dynamic code. If you want I can send it to you. You will need to make changes to it.

Valuable reading material:
http://devmanual.gentoo.org/
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml


founder
Activity: 364
Merit: 3077
August 26, 2010, 08:49:43 PM
#2
Try -datadir=

Last time I tried $(shell /usr/bin/wx-config), there was immediate hollering about build problems with it.  There wasn't time to investigate at the time.

One problem with $(shell /usr/bin/wx-config) is it will pick up any version (wx 2.8 ) and any configuration (non-UTF-8 ) of wxWidgets that happens to be there.  -lwx_gtk2ud-2.9 only matches the right configuration.  It fails if wxWidgets was built with the wrong configuration.

Quote
Iirc, chatting in #wxwidgets on freenode, the devs there were baffled why that was used.
Did they say why they were baffled?

Quote
This is because on my system the path is /usr/include/wx-2.9/wx/wx.h
Why is it there?  Was it included by the OS, or did you have to build it?  If you built it, I wonder why it would put itself in a different place.

Has wxWidgets 2.9 finally started to become available as a debian package?

Maybe we should do this:

INCLUDEPATHS= \
 -I"/usr/local/include/wx-2.9" \
 -I"/usr/local/lib/wx/include/gtk2-unicode-debug-static-2.9" \
 -I"/usr/include/wx-2.9" \
 -I"/usr/lib/wx/include/gtk2-unicode-debug-static-2.9"

Again, those paths help make sure it's only 2.9 and will fail with 2.8.

wxWidgets 2.8 comes in ANSI and UTF-16, both wrong for us.  It's tempting because it's so easily available as a package; a lot of people were frustrated by it until we started hardcoding 2.9 into the makefile.
hero member
Activity: 574
Merit: 504
August 26, 2010, 02:10:29 AM
#1
bitcoin ebuilds for gentoo linux

2011.03.02: bitcoin-git-9999 ebuild updated
outdated

Come to #bitcoin-gentoo on Freenode for latest
Jump to: