Topic: Nightly Builds (Read 5488 times)
Yes; was asking to see if they could be hosted at the same place or would have to be elsewhere.
Would you be interested in nightly builds for DragonFly BSD and OpenBSD?
Yes, would you be interested in building?Would you be interested in nightly builds for DragonFly BSD and OpenBSD?
Currently I do all the building on one Ubuntu VM, so adding two more VMs is quite a bit more effort. If you want to do them though, setting up a cronjob to build is quite easy.if it is possible, could you do a 64 bit windows build? just to see how much faster it is.
The Linux 32/64 difference is unnoticeable, the only reason a Linux 64-bit binary is provided is the 32-bit one will fail to load due to 32-bit BDB on 64-bit Ubuntu attempting to load 64-bit plugins. Because they are both compiled with gcc, the difference for Windows should be virtually identical to that on Linux. That and setting up a 64-bit build for windows would be substantially more effort.Sorry to those who have noticed the builds have not been happening over the past couple days, Im hoping to get them back running today or tomorrow (Im in the process of switching build servers).
if it is possible, could you do a 64 bit windows build? just to see how much faster it is.
Would you be interested in nightly builds for DragonFly BSD and OpenBSD?
Thanks for your builds. 
On linux, bitcoind, 64bits :
./bitcoind
=> bitcoind doesn't display "bitcoin server starting" and doesn't return to the next line of the terminal.
But, from another terminal, i can send rpc commands and all seams to work.
I can launch "./bitcoind stop" and bitcoind stops in the first terminal.
The problem doesn't appear with the -daemon option.
This problem didn't exist in the 0.3.20.2 release.
That isn't a problem with the nightlies. That was a conscious change made and will be in the 0.3.21 release (I believe its in the 0.3.21 RC now). ./bitcoind
=> bitcoind doesn't display "bitcoin server starting" and doesn't return to the next line of the terminal.
But, from another terminal, i can send rpc commands and all seams to work.
I can launch "./bitcoind stop" and bitcoind stops in the first terminal.
The problem doesn't appear with the -daemon option.
This problem didn't exist in the 0.3.20.2 release.
On linux, bitcoind, 64bits :
./bitcoind
=> bitcoind doesn't display "bitcoin server starting" and doesn't return to the next line of the terminal.
But, from another terminal, i can send rpc commands and all seams to work.
I can launch "./bitcoind stop" and bitcoind stops in the first terminal.
The problem doesn't appear with the -daemon option.
This problem didn't exist in the 0.3.20.2 release.
./bitcoind
=> bitcoind doesn't display "bitcoin server starting" and doesn't return to the next line of the terminal.
But, from another terminal, i can send rpc commands and all seams to work.
I can launch "./bitcoind stop" and bitcoind stops in the first terminal.
The problem doesn't appear with the -daemon option.
This problem didn't exist in the 0.3.20.2 release.
Windows 7, vanilla fresh install.
1. Run start /B bitcoind -rpcpassword=1
(wait for it to finish startup)
2. Run bitcoind -rpcpassword=1 stop
3. Windows says it crashed (and db error visible)
Ok, so I wasn't able to fix that on Windows Server 2003. I'd assume it would work on XP but I gave up on windows. Now the win32 nightlies are compiled on Ubuntu via https://github.com/TheBlueMatt/bitcoin/tree/crosscompile. They appear to work 100% now. If you find any additional issues, please notify me. 1. Run start /B bitcoind -rpcpassword=1
(wait for it to finish startup)
2. Run bitcoind -rpcpassword=1 stop
3. Windows says it crashed (and db error visible)
More importantly, both the oldest and newest Win32 nightlies on the site crash when stopped.
I can't reproduce, could you provide more information (ie Windows version, etc)1. Run start /B bitcoind -rpcpassword=1
(wait for it to finish startup)
2. Run bitcoind -rpcpassword=1 stop
3. Windows says it crashed (and db error visible)
More importantly, both the oldest and newest Win32 nightlies on the site crash when stopped.
I can't reproduce, could you provide more information (ie Windows version, etc) things to avoid
----------------------------------------------------
Breaking changes, like Luke JR's RPC versioning changes.
More trolling, I see.----------------------------------------------------
Breaking changes, like Luke JR's RPC versioning changes.
For anyone interested, my RPCv1 changes do NOT break anything, and are completely backward compatible.
Weren't those the ones that didn't actually do anything?
More importantly, both the oldest and newest Win32 nightlies on the site crash when stopped.
things to avoid
----------------------------------------------------
Breaking changes, like Luke JR's RPC versioning changes.
More trolling, I see.----------------------------------------------------
Breaking changes, like Luke JR's RPC versioning changes.
For anyone interested, my RPCv1 changes do NOT break anything, and are completely backward compatible.
Weren't those the ones that didn't actually do anything?
things to avoid
----------------------------------------------------
Breaking changes, like Luke JR's RPC versioning changes.
More trolling, I see.----------------------------------------------------
Breaking changes, like Luke JR's RPC versioning changes.
For anyone interested, my RPCv1 changes do NOT break anything, and are completely backward compatible.
It would be nice if directories such as http://bitcoin.bluematt.me/bitcoin-nightly/ included a README that described the contents of the directory / purpose of the project / etc.
New version pushed just now.
The default is now to use 127.0.0.1 while bootstrapping (on the host) and 10.0.2.2 in the VM. This will always hit the host.
Let me know if it works for you.
The default is now to use 127.0.0.1 while bootstrapping (on the host) and 10.0.2.2 in the VM. This will always hit the host.
Let me know if it works for you.
After building the VMs, attempting to run the build script results in apt errors fetching from my host name. ie "Failed to fetch from http://HostHostName:...". My host name will not resolve via DNS which is apparently the problem here.
Try doing:
Code:
export MIRROR_HOST=10.0.2.2
bin/make-base-vm
bin/make-base-vm
I think I'll make that the default.
Strange. Could you try:
* While make-base-vm is running, run
Code:
ps auxww | grep vmbuilder
and make sure that the mirror arguments refer to 10.0.2.2* Make sure that you didn't specify -i or --skip-image
* I just realized that the --quiet flag to gbuild actually does --skip-image due to a bug . If you had this flag on, it didn't pick up the new base vm image.
I've just pushed a new version that fixed the latter and makes 10.0.2.2 the default.
I'm on irc if you want to chat instead of messaging here.
After building the VMs, attempting to run the build script results in apt errors fetching from my host name. ie "Failed to fetch from http://HostHostName:...". My host name will not resolve via DNS which is apparently the problem here.
Try doing:
Code:
export MIRROR_HOST=10.0.2.2
bin/make-base-vm
bin/make-base-vm
I think I'll make that the default.
After building the VMs, attempting to run the build script results in apt errors fetching from my host name. ie "Failed to fetch from http://HostHostName:...". My host name will not resolve via DNS which is apparently the problem here.
Try doing:
Code:
export MIRROR_HOST=10.0.2.2
bin/make-base-vm
bin/make-base-vm
I think I'll make that the default.
After building the VMs, attempting to run the build script results in apt errors fetching from my host name. ie "Failed to fetch from http://HostHostName:...". My host name will not resolve via DNS which is apparently the problem here.
Looking into this.
Jump to: