Was looking for the "client release" here
https://github.com/BOINC/boinc/releases

found 7.14.2 under tags but not 7.15 anywhere.

was also wondering if building might require older version of tools such as mingw, openssh, libcurl, etc, as I once tried to build an older Linux app and found that it would not build with the latest versions of 3rd party apps, libraries, and databases and it was difficult to find old versions.

The numbering policy is:

Even numbers are used for releases
Odd numbers are used for development work, not yet ready for release.

If you see v7.15.0 out in the wild, it's a private build, made for testing and possibly with modifications not intended for general use.

The next release branch is 7.16.1, and that can be selected under 'branches' in GitHub: I've made a private Windows build for testing, but I don't know of anybody else admitting to doing that.

The numbering policy is:

Even numbers are used for releases
Odd numbers are used for development work, not yet ready for release.

If you see v7.15.0 out in the wild, it's a private build, made for testing and possibly with modifications not intended for general use.

The next release branch is 7.16.1, and that can be selected under 'branches' in GitHub: I've made a private Windows build for testing, but I don't know of anybody else admitting to doing that.

Yes, I have been alerted via PM about this version. it seems the project, SETI, has some deficiency or feature (not sure which) that required fixing with a different version of BOINC. I myself had a problem where I was getting way too many work units from Einstein when SETI went off-line but that was fixed when Wille found a bug in !BAM that prevented resource% from being set to 0. I will find out next Tuesday. Hopefully with resource=0 I will get exactly the number of Einstein work units I need to remain busy until SETI comes back on-line. I think we discussed this a few months ago but I was unware that !BAM was affecting the value.

At Milkyway, I had a problem where my S9100 GPU was not being recognized or used efficiently. With the source code available (but very difficult for me to build), I used a binary editor to change one of the recognized board's ID to "S9100" (Hawaii actually) and I changed the number of ALU's and the FP64 ratio to match that of the Hawaii GPU. This allowed the board to be recognized and efficiently utilized by the Milkyway app. This app, like Berkeley's BOINC was created under the GNU Lesser General Pubic License. I am not sure if this "binary hack" is considered a "modification" under the terms of the LGPL but I did post how to make the change here and it was used by several other enthusiasts who had S9150 boards.

From what I see, the version 7.15.0 is being used by a select group of SETI users and not available to the general users. I do not have a problem with that myself. However, I think it is quite hypocritical for staff at Berkeley (not going to mention any names but you can google) to complain about Fred not releasing his BoincTask source code to the public and then not do anything about their own code when it suits them just fine.

Well, up to a point. Until a couple of days ago, my computer list showed several v7.15.0, and one v7.13.0 - most of the 7.15.0 have now been replaced by v7.16.1 so I can get a feel of how the new release code works and report any bugs.

All of those odd builds were compiled by me, to develop or test fixes for the central code base. They will all have been different from any other build made from the master branch with different tweaks - you can't just point to a development version number and assume you know everything about it.

I've supplied updates to the source code to tweak GPU detection too - but only for NVidia, most recently in #2707 for the RTX range. If there needs to be a similar fix for the "S9100" (Hawaii), let me know and I can submit it.

As make runs again, I am just getting more and more impressed at anyone who can manage to build BOINC from source at least on the penguin platform!

Edit: Scratch that I have successfully built 7.15.0 but on a slow machine, it takes a long time when you have to work out what each fatal error is, fix it and then start again!

Now, the thing of course is that one can name any BOINC version 7.15.0 by adjusting the corresponding values in version.h, just as you can name them 1.0.0, or 100.91.23, or 7.16.2

It may matter to schedulers, if they check for old version numbers, but in general a 7.15.0 version can have been built from any source code, not necessarily from the 7.16 branch.

Which reminds me, let me go get that one.

/* Platform independent version definitions... */

#ifndef BOINC_VERSION_H
#define BOINC_VERSION_H

/* Major part of BOINC version number */
#define BOINC_MAJOR_VERSION 7

/* Minor part of BOINC version number */
#define BOINC_MINOR_VERSION 15

/* Release part of BOINC version number */
#define BOINC_RELEASE 0

/* Release part of wrapper version number */
#define WRAPPER_RELEASE 26016

/* Release part of vboxwrapper version number */
#define VBOXWRAPPER_RELEASE 26202

/* String representation of BOINC version number */
#define BOINC_VERSION_STRING "7.15.0"

/* Package is a pre-release (Alpha/Beta) package */
#define BOINC_PRERELEASE 1

#if (defined(_WIN32) || defined(__APPLE__))
/* Name of package */
#define PACKAGE "boinc"

/* Define to the address where bug reports for this package should be sent. */
#define PACKAGE_BUGREPORT ""

/* Define to the full name of this package. */
#define PACKAGE_NAME "BOINC"

/* Define to the full name and version of this package. */
#define PACKAGE_STRING "BOINC 7.15.0"

/* Define to the one symbol short name of this package. */
#define PACKAGE_TARNAME "boinc"

/* Define to the version of this package. */
#define PACKAGE_VERSION "7.15.0"

#endif /* #if (defined(_WIN32) || defined(__APPLE__)) */

#endif /* #ifndef BOINC_VERSION_H */

---

As make runs again, I am just getting more and more impressed at anyone who can manage to build BOINC from source at least on the penguin platform!

Edit: Scratch that I have successfully built 7.15.0 but on a slow machine, it takes a long time when you have to work out what each fatal error is, fix it and then start again!

That is a delight I am reluctantly gathering myself to address.

The Windows build instructions, by way of contrast, are a model of clarity, and from memory I only had to work round one single outdatedness.

OK, got Boinc Penguin to work!!

Proof: I modded version.h and changed number to "the beast" 7.16.666

Saved my history and copied what should be the necessary commands to build boinc under 18.04

downloaded the boinc_client zip from github for 7.16.1  (but version.h had 7.15.0)

   13  sudo apt-get update
   14  sudo apt-get upgrade

   11  sudo apt-get install build-essential
   12  sudo apt-get install  checkinstall

   21  sudo apt-get install m4
   22  sudo apt-get install gm4

   24  sudo apt-get install pkg-config

   30  sudo apt-get install autoconf

(use 42 instead of libtoolize)
   42  sudo apt-get install libtool m4 automake

   48  sudo apt-get install openssl

not all of 59 worked but 62 & 66 seemed to do it
   59  sudo apt-get install clibcurl4-openssl-dev pkg-config libssl-dev libsslcommon2-dev

   62  sudo apt install libssl-dev
   66  sudo apt-get install libcurl4-gnutls-dev
   75  sudo apt-get install libz-dev
   80  sudo apt-get install libnotify-dev

i scattered the following between the above lines and then searched for the missing packages but should work here no error
   37  ./_autosetup 

ask for that unwanted wxwidgets so I needed disable manager
   69  ./configure --disable-server --disable-manager

   83  make

note:  i edited version.h and put in the "beast" 666

   94  ./client/boinc --version

Look at bottom left of picture for printout of version #


got it up and running also!!

[CODE]z400-linux

1 8/5/2019 10:32:25 PM Starting BOINC client version 7.16.666 for x86_64-pc-linux-gnu
2 8/5/2019 10:32:25 PM This a development version of BOINC and may not function properly
3 8/5/2019 10:32:25 PM log flags: file_xfer, sched_ops, task
4 8/5/2019 10:32:25 PM Libraries: libcurl/7.58.0 GnuTLS/3.5.18 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
5 8/5/2019 10:32:25 PM Data directory: /var/lib/boinc-client
6 8/5/2019 10:32:25 PM No usable GPUs found
7 8/5/2019 10:32:25 PM Version change (7.15.0 -> 7.16.666)
8 8/5/2019 10:32:25 PM [libc detection] gathered: 2.27, Ubuntu GLIBC 2.27-3ubuntu1
9 8/5/2019 10:32:25 PM Host name: jyslinux1
10 8/5/2019 10:32:25 PM Processor: 12 GenuineIntel Intel(R) Xeon(R) CPU X5650 @ 2.67GHz [Family 6 Model 44 Stepping 2]
11 8/5/2019 10:32:25 PM Processor features: 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 syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmper
12 8/5/2019 10:32:25 PM OS: Linux Ubuntu: Ubuntu 18.04.3 LTS [5.0.0-23-generic|libc 2.27 (Ubuntu GLIBC 2.27-3ubuntu1)]
[/CODE]

downloaded the boinc_client zip from github for 7.16.1 (but version.h had 7.15.0)

If version.h had 7.15.0, then you didn't download v7.16.1

The version numbers in the copy I downloaded yesterday were all correct: they were updated six days ago by https://github.com/BOINC/boinc/commit/42a488b331e8f8e203691d5cbb036e81b8c8fd13

But thanks for the build instructions: I'll give those a try later today.

The Windows build instructions, by way of contrast, are a model of clarity, and from memory I only had to work round one single outdatedness.

Next time I feel bored, I shall see if the Windows instructions work under WINE. Having done one build it was a lot quicker on my laptop. Also helped by the fact that the machine itself is quicker!

If version.h had 7.15.0, then you didn't download v7.16.1

I did a complete new download of branch 7.16 last night and also got 7.15.0 in version.h

It did update version.h to yesterday's date and time of update. So this seems to be hit & miss. Or 7.16.1 isn't in the 7.16 branch

---

I've checked three different ways now:

1) Fresh clone into a new folder in my Windows build tree
2) Straight ZIP download in Linux
3) Inspect file contents directly on GitHub

I've built new clients under Windows: the machines I've deployed those builds on are showing v7.16.1 in the status line and online. I haven't got the Linux client to build yet - going to give that another go today.

But I've only ever seen v7.15.0 when downloading/building from master - deliberately or otherwise.

Well, after some confusion between openssl and libssl-dev, a lot of purple (warnings) and cyan (also warnings), I think I have a v7.16.1 client - no red!

I'm not going to test it until after the SETI outage (when I can flush my - excessive - cache), but watch this space.

I'm not going to test it until after the SETI outage (when I can flush my - excessive - cache), but watch this space.

Have gone from 7.15 to 7.16.1 on desktop but haven't tested yet as I still have windows tasks running under WINE. On laptop 7.15 has completed one SETI task, and nearly finished another. and two testing branch tasks from CPDN have been running for 40 minutes.

Haven't managed to get visual studio installed under WINE yet to see if it is possible to do Windows builds on a Linux box. How recent a version do you need. All the more recent ones are ranked as garbage on the WINE site.

Haven't managed to get visual studio installed under WINE yet to see if it is possible to do Windows builds on a Linux box. How recent a version do you need. All the more recent ones are ranked as garbage on the WINE site.

I'm building with VS2013 - if you can get hold of it. Microsoft doesn't tend to keep superseded versions hanging around for ever.

https://boinc.berkeley.edu/trac/wiki/CompileClient#Windows is pretty good. I've added a couple of gotchas from my own experience.

I'm building with VS2013 - if you can get hold of it. Microsoft doesn't tend to keep superseded versions hanging around for ever.

That version rated "garbage" on WINE site.

https://appdb.winehq.org/objectManager.php?sClass=application&iId=892 To get something rated gold I need to go back to 2005!

You're in luck - there are still dependencies for VS2005 listed at https://boinc.berkeley.edu/trac/wiki/SourceCodeGit#Windowsbuilddependencies.

David A is still building releases with VS2010 to maintain compatibility with Windows XP.

Edit - with those old versions, you may need to update some files, especially ca-bundle.crt to maintain secure link compatibility with modern servers like, in particular, SETI.

I am going to try and duplicate the "7.15.0 spoofed client" that was done by the GPU users group over at SETI. When (if) I get it working I will post here (unless there is an objection) on how to make the changes.
From what I see so far the following is an easy change

in file client_state.h use a bigger number say 10000

#define WF_MAX_RUNNABLE_JOBS    1000
    // don't fetch work from a project if it has this many runnable jobs.

more complicated is to ensure that when the XML sched_request is written out to force a big number to spoof SETI

<host_info>
    <n_usable_coprocs>2</n_usable_coprocs>
<coproc_cuda>
   <count>2</count>

TBar over at SETI suggested limiting upload when debugging to prevent tons of erroring out work units

If anyone with "inside" knowledge of the code changes, please PM me as I hate debugging with Linux (I retired when my company switched to Linux and CORBA). Far easier to set a breakpoint and see WTF is going on than to throw in console printouts

BTW, I downloaded two zips from GitHub at different times. The one I put in my windows VS2017 Dev system had version.h of 7.16.1 but I must have gotten the Linux download from a different spot at GitHub as it had 7.15.0 although the filename included the phrase 7.16

Starting with VS2015 code is binary compatible with future code (so I have read) unlike all earlier version of VS. Additionally after VS2013 there were huge changes. I spent a long time trying to get boinc to compile with VS2017 community before giving up. The problem was the (older) 3rd party libraries in addition to where they had to be found and downloaded from. I also found I had to make code changes in the headers as I was unable to use command line "defines" to fix problems. That would be a no-no for any backwards compatibility. I saw the same problem with the GRC "wallet". Someone tried doing a windows build but there was so much work required to maintain Linux compatibility it was a hopeless task. Far easier to stay in Linux and do a cross build for windows binary. IMHO of course.


my Linux "breadboard" just for this test.

You're in luck - there are still dependencies for VS2005 listed at https://boinc.berkeley.edu/trac/wiki/SourceCodeGit#Windowsbuilddependencies.

Thanks Richard, Sadly when I download the .exe file for 2005, the installer starts but when the little squares reach 100% for extracting, it stops. Running the file from a terminal with wine VS80sp1-KB926749-X86-INTL.exe just returns to the terminal after about 2 seconds with no error indicating what the problem is.

Having succeeded in getting 7.16.1 running on both laptop and desktop machines, I might give up on trying to build the windows version under wine. (Or possibly steal partner's windows laptop and try copying files over.)

Edit: Is there anything in particular you would like those of us using the new builds to look at while running them?

Spoof worked. SETI thinks I have 99 RX560s

Would there be a problem if I used 6.66.666 for the boinc version?
Going to think about this for a while before I actually do any processing. I don't want the GRC people to take away my grid coins thinking I am cheating.
Actually, this whole thing has become a joke. it should NOT be possible to do what I just did in the first place. I suspect that GPU users group over at SETI has opened a can of worms trying to get an edge on other users.

[EDIT] Have thought about this. Not going to pursue the spoofing. It was just a challenge to do the spoofing. A real challenge would be to get the client working under Visual Studio community but I don't think that would be useful to anyone either.