Re: [boinc_dev] [boinc_projects] BOINC - October 2017 VirtualBox and VBoxWrapper updates

[Rom Walton]

Oh, and configure.ac.  Just in case somebody uses autoconf/automake on Windows.

- Rom

-Original Message-
From: boinc_projects [mailto:boinc_projects-boun...@ssl.berkeley.edu] On Behalf 
Of Rom Walton
Sent: Sunday, November 5, 2017 6:30 PM
To: David Anderson <da...@ssl.berkeley.edu>; Jacob Klein 
<jacob_w_kl...@msn.com>; Juha Sointusalo <juha.sointus...@gmail.com>
Cc: BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu>; Boinc Projects 
<boinc_proje...@ssl.berkeley.edu>; BOINC Alpha <boinc_al...@ssl.berkeley.edu>
Subject: Re: [boinc_projects] [boinc_dev] BOINC - October 2017 VirtualBox and 
VBoxWrapper updates

version.h and version.h.in

- Rom

From: David Anderson [mailto:da...@ssl.berkeley.edu]
Sent: Sunday, November 5, 2017 6:08 PM
To: Jacob Klein <jacob_w_kl...@msn.com>; Juha Sointusalo 
<juha.sointus...@gmail.com>
Cc: Rom Walton <r...@romwnet.org>; BOINC Developers Mailing List 
<boinc_dev@ssl.berkeley.edu>; Boinc Projects <boinc_proje...@ssl.berkeley.edu>; 
BOINC Alpha <boinc_al...@ssl.berkeley.edu>
Subject: Re: [boinc_dev] BOINC - October 2017 VirtualBox and VBoxWrapper updates

Rom,
Where does that version # (7.9.26197.0) come from?
-- D
On 11/5/2017 5:08 PM, Jacob Klein wrote:
David:
I tested this "Release 2" version of the 26200 wrapper. We're very close.

The good:
- The crashes starting LHC tasks on 5.2, and crashes resuming RNA World tasks 
on 5.2, appear to be resolved. No more crashes. I suspect Release 1 had the 
stale tlb file.
The bad - *2* issues:
- The "File Version" of the exe is still incorrect, and is being written to 
stderr.txt. We need to fix this, so we can keep track of what version of the 
wrapper is being used at points in the log.
- The x86 version will need rebuilt too, with the fixes.

Once you get that "File Version" resolved, maybe consider doing another version 
bump to 26201, for reasons of sanity :) Then let me know when to retest it - 
I'm getting good at it.

Thanks,
Jacob


From: Jacob Klein <jacob_w_kl...@msn.com><mailto:jacob_w_kl...@msn.com>
Sent: Sunday, November 5, 2017 5:37 PM
To: David Anderson; Juha Sointusalo
Cc: Rom Walton; BOINC Developers Mailing List; Boinc Projects; BOINC Alpha
Subject: RE: [boinc_dev] BOINC - October 2017 VirtualBox and VBoxWrapper updates


Thanks David, I don't suppose there's any chance you could test, too, to see if 
you can get any repro? Wishful thinking? :)




From: David Anderson <da...@ssl.berkeley.edu><mailto:da...@ssl.berkeley.edu>
Sent: Sunday, November 5, 2017 4:53:53 PM
To: Juha Sointusalo; Jacob Klein
Cc: Rom Walton; BOINC Developers Mailing List; Boinc Projects; BOINC Alpha
Subject: Re: [boinc_dev] BOINC - October 2017 VirtualBox and VBoxWrapper updates

I rebuilt everything and uploaded it (same .zip filename).
The .exe size didn't change, but diff says it's different.
-- David
On 11/5/2017 12:09 PM, Juha Sointusalo wrote:
On 5 November 2017 at 11:14, Jacob Klein 
<jacob_w_kl...@msn.com<mailto:jacob_w_kl...@msn.com>> wrote:
David / Juha / Rom:

I have concluded my testing (took about 6 hours), and 26200 has some serious 
problems!

There seems to be something wrong in the vboxwrapper David built. I can 
reproduce the problems with it.

I re-built vboxwrapper myself, with VS2010 and VS2013 to see if it's something 
with VS version. Neither had problems with my test app. Now I have ATLAS and 
Theory task running with vboxwrapper built with VS2013 and the tasks seem to be 
working fine, or at least started fine.

Jacob, here's something for you to test: 
https://drive.google.com/open?id=13naXH8_mPg3b4kVrvRLPUfw2yY6cGnaW . Version 
numbers are off, don't worry about them.

-Juha


___
boinc_projects mailing list
boinc_proje...@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] BOINC - October 2017 VirtualBox and VBoxWrapper updates

[Rom Walton]

version.h and version.h.in

- Rom

From: David Anderson [mailto:da...@ssl.berkeley.edu]
Sent: Sunday, November 5, 2017 6:08 PM
To: Jacob Klein <jacob_w_kl...@msn.com>; Juha Sointusalo 
<juha.sointus...@gmail.com>
Cc: Rom Walton <r...@romwnet.org>; BOINC Developers Mailing List 
<boinc_dev@ssl.berkeley.edu>; Boinc Projects <boinc_proje...@ssl.berkeley.edu>; 
BOINC Alpha <boinc_al...@ssl.berkeley.edu>
Subject: Re: [boinc_dev] BOINC - October 2017 VirtualBox and VBoxWrapper updates

Rom,
Where does that version # (7.9.26197.0) come from?
-- D
On 11/5/2017 5:08 PM, Jacob Klein wrote:
David:
I tested this "Release 2" version of the 26200 wrapper. We're very close.

The good:
- The crashes starting LHC tasks on 5.2, and crashes resuming RNA World tasks 
on 5.2, appear to be resolved. No more crashes. I suspect Release 1 had the 
stale tlb file.
The bad - *2* issues:
- The "File Version" of the exe is still incorrect, and is being written to 
stderr.txt. We need to fix this, so we can keep track of what version of the 
wrapper is being used at points in the log.
- The x86 version will need rebuilt too, with the fixes.

Once you get that "File Version" resolved, maybe consider doing another version 
bump to 26201, for reasons of sanity :) Then let me know when to retest it - 
I'm getting good at it.

Thanks,
Jacob


From: Jacob Klein <jacob_w_kl...@msn.com><mailto:jacob_w_kl...@msn.com>
Sent: Sunday, November 5, 2017 5:37 PM
To: David Anderson; Juha Sointusalo
Cc: Rom Walton; BOINC Developers Mailing List; Boinc Projects; BOINC Alpha
Subject: RE: [boinc_dev] BOINC - October 2017 VirtualBox and VBoxWrapper updates


Thanks David, I don't suppose there's any chance you could test, too, to see if 
you can get any repro? Wishful thinking? :)




From: David Anderson <da...@ssl.berkeley.edu><mailto:da...@ssl.berkeley.edu>
Sent: Sunday, November 5, 2017 4:53:53 PM
To: Juha Sointusalo; Jacob Klein
Cc: Rom Walton; BOINC Developers Mailing List; Boinc Projects; BOINC Alpha
Subject: Re: [boinc_dev] BOINC - October 2017 VirtualBox and VBoxWrapper updates

I rebuilt everything and uploaded it (same .zip filename).
The .exe size didn't change, but diff says it's different.
-- David
On 11/5/2017 12:09 PM, Juha Sointusalo wrote:
On 5 November 2017 at 11:14, Jacob Klein 
<jacob_w_kl...@msn.com<mailto:jacob_w_kl...@msn.com>> wrote:
David / Juha / Rom:

I have concluded my testing (took about 6 hours), and 26200 has some serious 
problems!

There seems to be something wrong in the vboxwrapper David built. I can 
reproduce the problems with it.

I re-built vboxwrapper myself, with VS2010 and VS2013 to see if it's something 
with VS version. Neither had problems with my test app. Now I have ATLAS and 
Theory task running with vboxwrapper built with VS2013 and the tasks seem to be 
working fine, or at least started fine.

Jacob, here's something for you to test: 
https://drive.google.com/open?id=13naXH8_mPg3b4kVrvRLPUfw2yY6cGnaW . Version 
numbers are off, don't worry about them.

-Juha


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Increase in errors on Windows clients related to shared memory

[Rom Walton]

Charlie,

More than one graphics application can be running at a time, hence why the 
graphics application log file ended up in the slot directory.  Just creating a 
single user specific subdirectory isn't going to lead to a happy place.

It is supposed to be cleaned up when the slot directory is cleaned up.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Charlie Fenton
Sent: Wednesday, September 27, 2017 6:49 PM
To: Charlie Fenton.SSL 
Cc: boinc_dev email List 
Subject: Re: [boinc_dev] Increase in errors on Windows clients related to 
shared memory

On the Mac, the project graphics apps can not write to the per-user BOINC 
directory (which on the Mac is "/Users/{username}/Library/Application 
Support/BOINC/") because they run as user and group boinc_project under our 
UNIX account-based sandboxing. So I plan to set up a PR to create new per-user 
directories "/Library/Application Support/BOINC Data/users/" and 
"/Library/Application Support/BOINC Data/users/{username}/" with the same owner 
and group as the "/Library/Application Support/BOINC Data/projects/" directory, 
and write  the stderrscrgfx.txt, stdoutscrgfx.txt, stderrgfx.txt and 
stdoutgfx.txt files there.

I believe that a similar approach is probably needed for Windows, which has a 
simpler account-based sandboxing. But first I need to get my more urgent PR 
finished to fix the fact that the BOINC screensaver was broken by the recently 
released Mac OS 10.13 High Sierra.

Cheers,
--Charlie

On Sep 27, 2017, at 2:51 PM, Charlie Fenton  wrote:
> On Sep 27, 2017, at 12:49 PM, Juha Sointusalo  
> wrote:
>> I did see that the graphics app opens stderrgfx.txt file in slot 
>> directory and keeps it open as long as the graphics are open.
> 
> That is not terribly useful, since it will be gone after the slot directory 
> is cleaned. It should go in the per-user directory, which on Windows is 
> C:/Users/{username}/AppData/Roaming/BOINC/ or at least in the project 
> directory.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] BOINC, Visual Studio 2017, and Vcpkg

[Rom Walton]

As far as I know, this all works with Visual Studio 2017 Community Edition, 
which is positioned for students and open source projects.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Filip 
Rydlo
Sent: Monday, June 5, 2017 1:40 PM
To: BOINC-dev email list <boinc_dev@ssl.berkeley.edu>
Subject: Re: [boinc_dev] BOINC, Visual Studio 2017, and Vcpkg

Hi, Rom!
 That's  COOL!

 "Only *one* concernI have." - as Master Yoda would say   -
...

   Do I need to buy  a full version of *Visual Studio 2017*to
be able to compile  BOINC   and to use  Vcpkg ?( or will the "Express"
version be enough ? )

Namaste
Filip


P.S. I also hope it *WILL* compile on *AMD Ryzen 1800X CPU,  o*therwise  I am 
in trouble..


2017-06-05 8:02 GMT+02:00 Rom Walton <r...@romwnet.org>:

> Howdy Folks,
>
> It has been awhile.  Things have been settling into a nice rhythm at 
> my new gig and wanted to start mixing BOINC back into my life.
>
> What would you all think of migrating our project files over to Visual 
> Studio 2017 and using Vcpkg as a means dealing with the various 
> dependent open source libraries?
>
> Vcpkg can be found here:
> https://github.com/Microsoft/vcpkg
>
> I stumbled across it investigating something else on Channel 9 and 
> thought it would be a very useful tool in phasing out the dependency 
> git repos on boinc.berkeley.edu.
>
> Thoughts? Concerns?
>
> - Rom
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and (near bottom of page) enter 
> your email address.
>
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

[boinc_dev] BOINC, Visual Studio 2017, and Vcpkg

[Rom Walton]

Howdy Folks,

It has been awhile.  Things have been settling into a nice rhythm at my new gig 
and wanted to start mixing BOINC back into my life.

What would you all think of migrating our project files over to Visual Studio 
2017 and using Vcpkg as a means dealing with the various dependent open source 
libraries?

Vcpkg can be found here:
https://github.com/Microsoft/vcpkg

I stumbled across it investigating something else on Channel 9 and thought it 
would be a very useful tool in phasing out the dependency git repos on 
boinc.berkeley.edu.

Thoughts? Concerns?

- Rom
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Vboxwrapper 26186

[Rom Walton]

Fixed.

- Rom



From: Marius Millea<mailto:mmil...@ucdavis.edu>
Sent: Sunday, June 5, 2016 6:25 AM
To: Rom Walton<mailto:r...@romwnet.org>
Cc: BOINC Developers Mailing List<mailto:boinc_dev@ssl.berkeley.edu>
Subject: Re: [boinc_dev] Vboxwrapper 26186

Awesome, thanks Rom. I'm happy to see LPT Mac fix too, I'll let you know if 
that fixes our issues.

Fyi, the filename inside the zip file is wrong for the 64 bit Linux version, it 
still says 26184. Any chance you could update it (I presume I could just rename 
it myself, but as is it breaks the scripts I have for automatically downloading 
and creating new VM app versions)

Marius


On Sat, Jun 4, 2016 at 8:44 AM, Rom Walton 
<r...@romwnet.org<mailto:r...@romwnet.org>> wrote:
Howdy Folks,

We have a new vboxwrapper release which will support VirtualBox 5.1 on Windows.

You can download the binaries from the usual locations:
http://boinc.berkeley.edu/dl
or
https://github.com/BOINC/boinc/releases/tag/vboxwrapper%2F26186

- Rom



___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

[boinc_dev] Vboxwrapper 26186

[Rom Walton]

Howdy Folks,

We have a new vboxwrapper release which will support VirtualBox 5.1 on Windows.

You can download the binaries from the usual locations:
http://boinc.berkeley.edu/dl
or
https://github.com/BOINC/boinc/releases/tag/vboxwrapper%2F26186

- Rom



___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Moving

[Rom Walton]

Howdy Folks,

I'm back on the air, after a detour to Bellevue, Washington.

- Rom

-Original Message-
From: boinc_alpha [mailto:boinc_alpha-boun...@ssl.berkeley.edu] On Behalf Of 
Rom Walton
Sent: Sunday, April 24, 2016 3:10 PM
To: BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu>
Cc: boinc_projects <boinc_proje...@ssl.berkeley.edu>; 
boinc_...@ssl.berkeley.edu; BOINC Alpha <boinc_al...@ssl.berkeley.edu>
Subject: [boinc_alpha] Moving

Howdy Folks,

Starting on Monday, I'm going to be moving to North Carolina.  During the move, 
my web and email server will be down.

My alternate email address during the move is 
walton_...@msn.com<mailto:walton_...@msn.com>.

I believe the only issue that this will cause for the project as a whole is the 
automatic synchronization of the localization files between Transifex and 
Github.

- Rom
___
boinc_alpha mailing list
boinc_al...@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

[boinc_dev] Moving

[Rom Walton]

Howdy Folks,

Starting on Monday, I'm going to be moving to North Carolina.  During the move, 
my web and email server will be down.

My alternate email address during the move is 
walton_...@msn.com.

I believe the only issue that this will cause for the project as a whole is the 
automatic synchronization of the localization files between Transifex and 
Github.

- Rom
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] automatic filename extension in windows wrapper

[Rom Walton]

I suppose it would be more robust to have the wrapper launch "cmd.exe" with the 
command line argument of "/k" and then the desired application name.  That 
would then allow cmd.exe to launch the desired application correctly.

.COM/.EXE apps can be launched directly with CreateProcess/CreateProcessEx
.VBS/.JS/.WSH would be launched with wscript.exe
.BAT/.CMD would be handled by the currently running command interpreter

In theory this could also take care of python/perl files as well.  As long as 
the interpreters are installed on the system.

- Rom

-Original Message-
From: Christian Beer [mailto:christian.b...@aei.mpg.de] 
Sent: Thursday, February 25, 2016 3:09 PM
To: BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu>
Cc: Rom Walton <r...@romwnet.org>
Subject: automatic filename extension in windows wrapper

Hi,

we have a use case where we want to use the wrapper to deploy a legacy 
application. The application is bundled in a zip archive that is extracted by 
the wrapper into the slot directory. This application is called "LegacyApp" and 
"LegacyApp.exe" on Linux and Windows respectively. Now comes the problem. We 
want t include the job.xml file as part of the workunit not the appversion. 
This way we can only set one name "LegacyApp" which causes problems because for 
an unknown reason Windows 7 will not start a file without the .exe extension.

I looked through the code and found a place
(https://github.com/BOINC/boinc/blob/master/samples/wrapper/wrapper.cpp#L633)
where we could add some more logic to detect such a case and add the ".exe" 
extension. Something like: if on windows and app_path does not exist try 
app_path+".exe"

Another possibility would be to also add the .exe extension to the linux 
executable but who want's to do that? And remember it later when we wonder why 
we fixed a Windows Problem on Linux.

Any thoughts on that?

Regards
Christian
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] client in master is broken

[Rom Walton]

I believe I've just fixed that issue.

- Rom

-Original Message-
From: Richard Haselgrove [mailto:r.haselgr...@btopenworld.com] 
Sent: Tuesday, February 16, 2016 9:45 AM
To: Rom Walton <r...@romwnet.org>; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] client in master is broken

Ouch. Big, big problems.

Client built OK, no errors or warnings. And it runs OK - I can see the client, 
and project science apps, running in Process Explorer.

BUT:

Nothing can connect to it - not local Manager, not remote Manager, not my 
faithful old BoincView. Even this fails:

D:\BOINC>D:\BOINC\boinccmd.exe --quit 
Authorization failure: -102 

D:\BOINC>

And I see

16-Feb-2016 14:25:01 [---] Creating new client state file

The new state file has, in many places but not everywhere, a [nul] character 
after a closing tag where I would expect to see a newline

Significant files attached.


On Tuesday, 16 February 2016, 13:55, Rom Walton <r...@romwnet.org> wrote:
I've fixed the issue created by switching over to strlcat.

The warnings have, more or less, always been there.  We just suppressed them in 
Visual Studio 2005.

Unfortunately, what they suggest we use is not cross-platform.  So we are 
having to hunt down the cross platform equivs.

- Rom


-Original Message-
From: McLeod, John [mailto:john.mcl...@sap.com] 
Sent: Tuesday, February 16, 2016 8:25 AM
To: Richard Haselgrove <r.haselgr...@btopenworld.com>; Rom Walton 
<r...@romwnet.org>; boinc_dev@ssl.berkeley.edu
Subject: RE: [boinc_dev] client in master is broken

The _s functions do a better job of avoiding buffer overruns.  IIRC, they force 
the programmer to tell the function the size of the target buffer.  

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Richard Haselgrove
Sent: Tuesday, February 16, 2016 8:18 AM
To: Richard Haselgrove <r.haselgr...@btopenworld.com>; Rom Walton 
<r...@romwnet.org>; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] client in master is broken

And the resulting client failed with "A buffer overrun has occurred in 
boinc.exe which has corrupted the program's internal state. Press Break to 
debug the program or Continue to terminate the program."

Pressing Break dropped me into the source at 


>boinc.exe!__raise_securityfailure(_EXCEPTION_POINTERS * ExceptionPointers) 
> Line 85C 
boinc.exe!__report_gsfailure(unsigned __int64 StackCookie) Line 241C 
boinc.exe!__GSHandlerCheck(_EXCEPTION_RECORD * ExceptionRecord, void * 
EstablisherFrame, _CONTEXT * ContextRecord, _DISPATCHER_CONTEXT * 
DispatcherContext) Line 91C 
ntdll.dll!775b8bbd()Unknown 
ntdll.dll!775a875f()Unknown 
ntdll.dll!775dd348()Unknown 
msvcr120.dll!07fef313c3f9()Unknown 
()Unknown 
0080()Unknown 
boinc.exe!strlcat(char * dst, const char * src, unsigned __int64 size) Line 78  
  C++ 
boinc.exe!get_processor_features(char * vendor, char * features, int 
features_size) Line 1198C++ 
boinc.exe!get_processor_info(char * p_vendor, int p_vendor_size, char * 
p_model, int p_model_size, char * p_features, int p_features_size, double & 
p_cache, int & p_ncpus) Line 1305C++ 


On Tuesday, 16 February 2016, 12:59, Richard Haselgrove 
<r.haselgr...@btopenworld.com> wrote:



Rom,

The fix you made last night solved the build problem in VS2013 - thanks.

But your overnight work on the 'low hanging fruit' has triggered a huge number 
of VS2013 warnings - 469 when building boinccmd, which includes the client 
build as part of the solution.

All seem to be C4996 - sample below. In each case, the 'consider using' 
suggestion seems to be to replace the function (several different functions are 
named) with function_s

e.g.

Warning 469 warning C4996: 'ctime': This function or variable may be unsafe. 
Consider using ctime_s instead. To disable deprecation, use 
_CRT_SECURE_NO_WARNINGS. See online help for details.

D:\Sources_build\boinc_head\lib\gui_rpc_client_print.cpp 238 1 boinccmd


On Monday, 15 February 2016, 20:29, Rom Walton <r...@romwnet.org> wrote:



Should be fixed now.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Richard Haselgrove
Sent: Monday, February 15, 2016 3:09 PM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] client in master is broken

I also found that the Windows VS2013 solution failed to build the client from 
tags 7.6.24, 7.6.25, and head.
Managed to fix it by adding references to '..\lib\project_init.cpp' and 
'..\lib\project_init.h' to the  lists in both 
boinc_cli_vs2013.vcxproj and libboinc_staticcrt_vs2013.vcxproj

With that adjustment, head (debug) seems to be running. 

  

On Tuesday, 9 February 2016, 13:31, Oliver Bock <oliver.b...@aei.mpg.de> wrote:


On 09/02/16 14:10 , Rom Walton wrote:
> Should be f

Re: [boinc_dev] client in master is broken

[Rom Walton]

I've fixed the issue created by switching over to strlcat.

The warnings have, more or less, always been there.  We just suppressed them in 
Visual Studio 2005.

Unfortunately, what they suggest we use is not cross-platform.  So we are 
having to hunt down the cross platform equivs.

- Rom

-Original Message-
From: McLeod, John [mailto:john.mcl...@sap.com] 
Sent: Tuesday, February 16, 2016 8:25 AM
To: Richard Haselgrove <r.haselgr...@btopenworld.com>; Rom Walton 
<r...@romwnet.org>; boinc_dev@ssl.berkeley.edu
Subject: RE: [boinc_dev] client in master is broken

The _s functions do a better job of avoiding buffer overruns.  IIRC, they force 
the programmer to tell the function the size of the target buffer.  

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Richard Haselgrove
Sent: Tuesday, February 16, 2016 8:18 AM
To: Richard Haselgrove <r.haselgr...@btopenworld.com>; Rom Walton 
<r...@romwnet.org>; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] client in master is broken

And the resulting client failed with "A buffer overrun has occurred in 
boinc.exe which has corrupted the program's internal state. Press Break to 
debug the program or Continue to terminate the program."

Pressing Break dropped me into the source at 


>   boinc.exe!__raise_securityfailure(_EXCEPTION_POINTERS * 
> ExceptionPointers) Line 85  C 
boinc.exe!__report_gsfailure(unsigned __int64 StackCookie) Line 241 C 
boinc.exe!__GSHandlerCheck(_EXCEPTION_RECORD * ExceptionRecord, void * 
EstablisherFrame, _CONTEXT * ContextRecord, _DISPATCHER_CONTEXT * 
DispatcherContext) Line 91 C 
ntdll.dll!775b8bbd()Unknown 
ntdll.dll!775a875f()Unknown 
ntdll.dll!775dd348()Unknown 
msvcr120.dll!07fef313c3f9() Unknown 
()  Unknown 
0080()  Unknown 
boinc.exe!strlcat(char * dst, const char * src, unsigned __int64 size) Line 78  
C++ 
boinc.exe!get_processor_features(char * vendor, char * features, int 
features_size) Line 1198   C++ 
boinc.exe!get_processor_info(char * p_vendor, int p_vendor_size, char * 
p_model, int p_model_size, char * p_features, int p_features_size, double & 
p_cache, int & p_ncpus) Line 1305   C++ 


On Tuesday, 16 February 2016, 12:59, Richard Haselgrove 
<r.haselgr...@btopenworld.com> wrote:



Rom,

The fix you made last night solved the build problem in VS2013 - thanks.

But your overnight work on the 'low hanging fruit' has triggered a huge number 
of VS2013 warnings - 469 when building boinccmd, which includes the client 
build as part of the solution.

All seem to be C4996 - sample below. In each case, the 'consider using' 
suggestion seems to be to replace the function (several different functions are 
named) with function_s

e.g.

Warning 469 warning C4996: 'ctime': This function or variable may be unsafe. 
Consider using ctime_s instead. To disable deprecation, use 
_CRT_SECURE_NO_WARNINGS. See online help for details.

D:\Sources_build\boinc_head\lib\gui_rpc_client_print.cpp 238 1 boinccmd


On Monday, 15 February 2016, 20:29, Rom Walton <r...@romwnet.org> wrote:



Should be fixed now.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Richard Haselgrove
Sent: Monday, February 15, 2016 3:09 PM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] client in master is broken

I also found that the Windows VS2013 solution failed to build the client from 
tags 7.6.24, 7.6.25, and head.
Managed to fix it by adding references to '..\lib\project_init.cpp' and 
'..\lib\project_init.h' to the  lists in both 
boinc_cli_vs2013.vcxproj and libboinc_staticcrt_vs2013.vcxproj

With that adjustment, head (debug) seems to be running. 

  

On Tuesday, 9 February 2016, 13:31, Oliver Bock <oliver.b...@aei.mpg.de> wrote:


On 09/02/16 14:10 , Rom Walton wrote:
> Should be fixed now.

Please, please, please. It's been about three years since we migrated to git. 
BOINC moved to GitHub just recently and tries to adopt a community governance 
model. It should really be possible by now that devs start using feature 
branches for development and save everyone else from periodic headaches. It's 
not hard by any means and it comes with huge incentives for everyone involved.

So please, use feature branches for development; merge to master when you're 
done with testing; don't break master; be happy; make everyone else happy...

THANKS!


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


  
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, v

Re: [boinc_dev] client in master is broken

[Rom Walton]

Should be fixed now.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Christian Beer
Sent: Tuesday, February 9, 2016 5:06 AM
To: BOINC Developers Mailing List 
Subject: [boinc_dev] client in master is broken

The client currently fails to build from master with:
>
> boinc_client-client_state.o: In function `CLIENT_STATE::init()':
>
> /home/travis/build/BOINC/boinc/client/client_state.cpp:715: undefined 
> reference to `PROJECT_INIT::init()'
>
> boinc_client-client_state.o: In function `CLIENT_STATE':
>
> /home/travis/build/BOINC/boinc/client/client_state.cpp:88: undefined 
> reference to `PROJECT_INIT::PROJECT_INIT()'
>
> boinc_client-gui_rpc_server_ops.o: In function
> `handle_get_project_init_status':
>
> /home/travis/build/BOINC/boinc/client/gui_rpc_server_ops.cpp:725:
> undefined reference to `PROJECT_INIT::remove()'
>
> boinc_client-gui_rpc_server_ops.o: In function `handle_project_attach':
>
> /home/travis/build/BOINC/boinc/client/gui_rpc_server_ops.cpp:885:
> undefined reference to `PROJECT_INIT::remove()'
>
> collect2: ld returned 1 exit status
>

I disabled the notification to the boinc_cvs mailing list so the default 
notification rules are used. Now the committer should directly receive an email 
about the build status. Sadly this does not work for pull requests.

Regards
Christian
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

[boinc_dev] BOINC 7.6.22 released for Windows and Mac

[Rom Walton]

A new version of BOINC is ready for public use.

The big ticket items for the 7.6.22 release are:
* Updated localizations 
* Updated libcurl, openssl, and http://boinc.berkeley.edu/trac/wiki/VirtualBox 
(for packages that include http://boinc.berkeley.edu/trac/wiki/VirtualBox) 
* Fixed http://boinc.berkeley.edu/trac/wiki/VirtualBox detection for Mac and 
Linux 
* Fixed numerous issues detected via coverity source code scans. 
* Fixed how elapsed time is displayed in the manager 
* Fixed localized number formatting issues 
* Fixed crash analysis code in the manager (Windows Only) 
* Fixed GPU detection issues 
* Fixed minimum password text in attach wizard 
* Fixed clipping of the project icons in the simple GUI (Windows Only) 

Download: http://boinc.berkeley.edu/download.php
Release Notes: http://boinc.berkeley.edu/wiki/Release_Notes
Version History: http://boinc.berkeley.edu/trac/wiki/VersionHistory

- Rom
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Manager fails to build

[Rom Walton]

It was a mistake on my part.

The stuff in the header file should be put back in.

I'll fix this.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Vitalii Koshura
Sent: Monday, December 14, 2015 7:04 AM
To: Christian Beer 
Cc: BOINC Developers Mailing List 
Subject: Re: [boinc_dev] Manager fails to build

As I understand BOINC Manager failed to build not only on Linux, but on Windows 
(and possibly MacOS) too.I don't know why this was done.

Best regards,
Vitalii Koshura

2015-12-14 13:58 GMT+02:00 Christian Beer :

> That is correct. I meant to post this link:
> https://github.com/BOINC/boinc/compare/bcc6e701020c...a97b15c20963 
> that shows the commits tested by the failing travis build which 
> includes 8ec4cd4.
>
> Regards
> Christian
>
> On 14.12.2015 12:22, Vitalii Koshura wrote:
> > Hello Christian,
> >
> > It seems that this was broken in this
> > commit:
> https://github.com/BOINC/boinc/commit/8ec4cd41cbc753705c9f25fa29a0fda1
> 8f49d4c4
> >
> > Best regards,
> > Vitalii Koshura
> >
> > 2015-12-14 12:52 GMT+02:00 Christian Beer  > >:
> >
> > The Manager for linux is broken in current master.
> >
> > It seems it was introduced here:
> >
> https://github.com/BOINC/boinc/commit/a97b15c20963ab1235b4768ea3b3e3e0
> 77a10574
> >
> > The error log from Travis:
> > >
> > > BOINCGUIApp.cpp: In member function ‘virtual bool
> > CBOINCGUIApp::OnInit()’:
> > >
> > > BOINCGUIApp.cpp:157:5: error: ‘m_bRunDaemon’ was not declared in
> > this
> > > scope
> > >
> > > BOINCGUIApp.cpp:158:5: error: ‘m_bNeedRunDaemon’ was not 
> > declared
> in
> > > this scope
> > >
> > > BOINCGUIApp.cpp: In member function ‘void
> > CBOINCGUIApp::SaveState()’:
> > >
> > > BOINCGUIApp.cpp:626:40: error: ‘m_bRunDaemon’ was not declared
> > in this
> > > scope
> > >
> > > [snip]
> > >
> > > BOINCGUIApp.cpp: In member function ‘virtual bool
> > > CBOINCGUIApp::OnCmdLineParsed(wxCmdLineParser&)’:
> > >
> > > BOINCGUIApp.cpp:733:9: error: ‘m_bNeedRunDaemon’ was not 
> > declared
> in
> > > this scope
> > >
> > > make[2]: *** [boincmgr-BOINCGUIApp.o] Error 1
> > >
> > > make[2]: Leaving directory
> > `/home/travis/build/BOINC/boinc/clientgui'
> > >
> > > make[1]: *** [all-recursive] Error 1
> > >
> > > make[1]: Leaving directory `/home/travis/build/BOINC/boinc'
> > >
> > > make: *** [all] Error 2
> > >
> >
> > ___
> > boinc_dev mailing list
> > boinc_dev@ssl.berkeley.edu 
> > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> > To unsubscribe, visit the above URL and
> > (near bottom of page) enter your email address.
> >
> >
>
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and (near bottom of page) enter 
> your email address.
>
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Errors when building release branch locally

[Rom Walton]

To be honest, I never really tested the scripts on Windows.  I built everything 
in a Linux VM.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of John 
David Heeter
Sent: Tuesday, November 17, 2015 12:22 PM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] Errors when building release branch locally

We’ve followed the instructions from:

http://boinc.berkeley.edu/trac/wiki/AndroidBuildClient#


Using:
Android SDK 20
Android NDK r9d


we’ve tried to build the toolchain, this is what’ve got:

$ sh build_androidtc_arm.sh
expr: syntax error
expr: syntax error
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: name: No such file or directory
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: OPTIONS_abstract_Specify: command not found
expr: syntax error
expr: syntax error
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: ver: No such file or directory
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: OPTIONS_abstract_Specify: command not found
expr: syntax error
expr: syntax error
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: name: No such file or directory
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: OPTIONS_abstract_Specify: command not found
expr: syntax error
expr: syntax error
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: name: No such file or directory
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: OPTIONS_abstract_Specify: command not found
expr: syntax error
expr: syntax error
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: path: No such file or directory
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: path: No such file or directory
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186:
OPTIONS_default_C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9=:
No such
file or directory
expr: syntax error
expr: syntax error
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: name: No such file or directory
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: OPTIONS_abstract_Specify: command not found
expr: syntax error
expr: syntax error
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: path: No such file or directory
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: path: No such file or directory
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: OPTIONS_default_/tmp/ndk-=: No such file or directory
expr: syntax error
expr: syntax error
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: path: No such file or directory
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
ev
al: line 186: unexpected EOF while looking for matching `''
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
ev
al: line 187: syntax error: unexpected end of file
expr: syntax error
expr: syntax error
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: name: No such file or directory
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: OPTIONS_abstract_Specify: command not found
C:/Users/Ivan/Downloads/android-ndk-r9-windows-x86/android-ndk-r9/build/tools/prebuilt-common.sh:
li
ne 186: OPTIONS_default_android-3=: command not found 
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] 153f66: Server (assimilator): add random string to result ...

[Rom Walton]

It would probably be a noticeable difference though.  Similar to the 
differences between HTTP vs HTTPS.

Of the additional load generated, half would be in the transitioner while it is 
generating replicas.

When the transitioner slows down, it slows down all the other daemons.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of David 
Anderson
Sent: Tuesday, November 17, 2015 12:57 PM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] 153f66: Server (assimilator): add random string to 
result ...

You're right - enabling upload certificates (which work, AFAIK) would fix the 
problem too, as long as the project's upload directory isn't accessible.

If I recall, we made upload certificates not the default at a point where S@h's 
servers were overloaded and we were looking for every performance boost 
(actually the impact is probably negligible).

-- D

On 11/17/2015 4:04 AM, Christian Beer wrote:
> On 17.11.2015 12:24, Nicolás Alvarez wrote:
>> 4. The commit message says the attacker could "upload fake files as B's 
>> output files". This is not possible due to upload signatures. If he could 
>> upload fake files as B's output files, he could also do the same as C's, 
>> D's, E's, etc. with file sizes as large as max_nbytes allows and fill up the 
>> upload server, which is exactly what upload signatures are supposed to 
>> prevent.
>>
>> If the attacker can't upload files as B's output files, the entire 
>> postulated attack falls down and this change is not necessary.
> This is for a scenario where the project turned off upload certificates.
> This is not mentioned in the message.
>
> So I have another question: What's the argument for turning off upload 
> certificates and needing this kind of randomized filename? Wouldn't it 
> be easier to fix and enable upload certificates?
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and (near bottom of page) enter 
> your email address.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

[boinc_dev] Dynamic HTTP Compression

[Rom Walton]

Howdy Folks,

Are there any projects using dynamic HTTP compression?

See:
http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/

I'm updating the version of libcurl we include with our Windows release and 
would like to drop our requirement for OpenSSL and use the SSL implementation 
built into Windows.

Pros:

* Microsoft maintains the certificate authority store

* Microsoft maintains SSL implementation

Cons:

* Lose Dynamic HTTP compression

- Rom
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Problems with cached memory under 64-bit Windows

[Rom Walton]

I believe you are running into SuperFetch.

See:
http://www.osnews.com/story/21471/SuperFetch_How_it_Works_Myths

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Robert 
Miles
Sent: Monday, October 26, 2015 10:51 AM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] Problems with cached memory under 64-bit Windows

BOINC appears to have a problem with filling the cached memory in a way that 
prevents Windows from using that cached memory for any 32-bit programs until 
the next restart or reboot.  Problem seen under 64-bit Windows Vista and 64-bit 
Windows 7; 64-bit Windows 10 appears to have a similar problem even if it does 
not call anything cached memory; I do not have any running other versions of 
Windows to check.

64-bit workunits appear to be able to get cached memory freed if they need it.  
I do not run 64-bit programs from the console often enough to tell if such 
64-bit console programs can also free cached memory or not.

One of my computers with 8 GB of memory and 64-bit Windows Vista is now often 
unable to start its email program unless I have shut down BOINC.
Another computer, with 16 GB memory and Windows 10, does not have as obvious a 
problem yet, but the email program is often slow to start or run there.
Suspending BOINC to free CPU use does not help.

My Windows Vista computer currently has 5319 of its 8190 blocks of physical 
memory labelled as cached, and is slow to respond when I start a 32-bit program 
with significant use of memory.

Still, the help files do not appear to explain what cached memory is, whether 
it is useful to reduce the amount of cached memory, and if so, how to do this.

So many files on the hard drives that defragmentation, full virus scans, and 
other operations on all the files take 3 to 5 days, even with nothing else 
running.  These are mostly message files from using Windows Mail and Windows 
Live Mail to read newsgroups, and save most of the messages read or even 
downloaded but not yet read.  This is so long that I seldom run any operations 
that require reading all the files.  Quick virus scans find nothing of 
interest, though.

The motherboard appears to be at the maximum amount of physical memory it can 
handle.

Could several of you join me in asking Microsoft to add an explanation of 
whether it is useful to reduce the amount of memory cached, and if so, how to 
reduce the cached memory?  I'd like for them to provide a program to show more 
about what is being cached, including any file names, so that users can look 
harder at the files cached most often.  For example, I'd like to check if files 
that a program used months ago but but not more recently are getting stored in 
the cache every time that program runs.

I've found information on what memory caches are supposed to be used for 
(faster access to items likely to be used again), but it looks like BOINC does 
not allow enough of the cached memory to be freed when 32-bit programs need 
more memory.

One idea of how to change BOINC to reduce the number of BOINC-related files in 
cached memory:  BOINC  already has a feature for allowing frequently used files 
to be stored in project directories so they can be saved for any future 
workunits that need them.  A new feature could be added to allow BOINC servers 
to tell BOINC clients that some of the files in the project directories are not 
expected to be used again, and therefore should be deleted from the project 
directories so that they cannot be loaded into cached memory in the future.
This may need some thought about what to do if a project mistakenly lists a 
file as no longer needed, but some later workunit tries to use it anyway.
Note that both the server and the client will need to have sufficiently recent 
software for this new feature will work, so it should be designed in a way that 
will allow older BOINC software to ignore it if only one end of the connection 
supports the feature.

I have not found a definite way to duplicate this problem, but the following 
method seems likely:  Start with a computer with 8 GB of memory or less, and 
running 64-bit Windows.  Install a recent version of BOINC, if it isn't already 
installed. Connect it to each of the following BOINC projects, and run each of 
their applications at least once:

World Community Grid
rosetta@home
ralph@home
PrimeGrid
Milkyway@Home
GPUGRID
FiND@Home
Einstein@Home
Albert@Home

These projects were the ones that use the most disk space on my computers, and 
therefore probably have the most space used in their project directories.
My computers are connected to enough other projects to have about 20 projects 
in all connected.

Now, with all but one of the CPU cores running 32-bit CPU workunits, and a GPU 
workunit also running, start trying to start some 32-bit program that uses a 
lot of memory.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu

Re: [boinc_dev] vbox64 and virtualization

[Rom Walton]

> Yea, can confirm "VBoxManage startvm" returns successfully on my system even 
> though the VM immediately
> dies with the VERR_VMX_MSR_VMXON_DISABLED error. That's why vboxwrapper never 
> catches it. Not sure if
> this is a VBox bug and/or if its limited to my system.

Well, it is a bug in vboxwrapper.  It may or may not be a change in behavior 
for VirtualBox.

Ideally, BOINC relies on vboxwrapper to tell it whether the host machine is 
properly configured to support running VirtualBox Virtual Machines.  
Vboxwrapper relies on VirtualBox.

This was working at one time.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Marius 
Millea
Sent: Friday, October 16, 2015 9:12 AM
To: Christian Beer 
Cc: BOINC-dev email list 
Subject: Re: [boinc_dev] vbox64 and virtualization

On Fri, Oct 16, 2015 at 2:23 PM, Marius Millea  wrote:

> Here's the relevant lines from the scheduler log, vmx is there, and 
> its present in /proc/cpuinfo as well.
>
> 2015-10-16 12:12:34.6279 [PID=66   ][send] CPU 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 rdtscp lm 
> constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
> aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl *vmx* smx est 
> tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt 
> tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb 
> xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep 
> erms
> 2015-10-16 12:12:34.6596 [PID=66   ][send] Sending app_version
> camb_boinc2docker 4 5 vbox64_mt; projected 14.64 GFLOPS
>
> Reading eg here
>  ocessor-supports-vt/>
> or here
>  nsions-enabled-in-bios> it seems vmx appearing there just means your 
> CPU supports it, not that it is actually enabled. Clearly in my case its 
> disabled yet still shows up.
>
> So I suppose the questions are now,
>
> 1) is there a way BOINC can check if vmx is actually enabled?
> 2) whats going on with vboxwrapper
>
>
Yea, can confirm "VBoxManage startvm" returns successfully on my system even 
though the VM immediately dies with the VERR_VMX_MSR_VMXON_DISABLED error. 
That's why vboxwrapper never catches it. Not sure if this is a VBox bug and/or 
if its limited to my system.






> Marius
>
>
>
> On Fri, Oct 16, 2015 at 2:01 PM, Christian Beer 
>  > wrote:
>
>> Did you restart the server processes just to make sure? The scheduler 
>> should use the new plan_class.xml config instantly and not send you 
>> any work. This seems to be a separate problem.
>>
>> So in theory the server shouldn't send you any task but it is. And 
>> the vboxwrapper should recognize the error code but it isn't. Very strange.
>>
>> Next thing to check would be the scheduler_request and reply from the 
>> client and the scheduler log on the server the interesting part there 
>> is the cpu capabilities. This is where the BIOS setting is reported. 
>> There should be no vmx or svm capability reported by your computer 
>> (as you have HW accell turned off).
>>
>> Regards
>> Christian
>>
>> On 10/16/2015 01:47 PM, Marius Millea wrote:
>> > Thanks Christian, I added that option but same result.
>> >
>> > Its clear to me now that vboxwrapper is missing the fact that the 
>> > VM doesn't start correctly. If you look at the attached stderr.txt, 
>> > if says "Successfully started VM." Hence it never makes it to the 
>> > part in the code that checks vbox.log for 
>> > "VERR_VMX_MSR_VMXON_DISABLED" and hence never prints 
>> > "ERR_CPU_VM_EXTENSIONS_DISABLED".
>> >
>> > I'm looking into why, any ideas? Otherwise yea it looks like the 
>> > code to do exactly what you guys describe is there.
>> >
>> > Marius
>> >
>> >
>> > On Fri, Oct 16, 2015 at 11:42 AM, Christian Beer 
>> > > wrote:
>> >
>> > On 10/16/2015 11:16 AM, Marius Millea wrote:
>> > > However I'm using VBox
>> > > 4.3.30 and vboxwrapper 26175 so I don't think that's it. I'm
>> > attaching my
>> > > vbox.log, there's some errors in there about VT-x but searching
>> > > for ERR_CPU_VM_EXTENSIONS_DISABLED yields nothing.
>> > The vbox.log contains VERR_VMX_MSR_VMXON_DISABLED at the end. 
>> > Which
>> is
>> > the VirtualBox errorcode to say you have a 64bit Guest but Hardware
>> > Virtualization is not enabled (it says so in the begining of the log
>> > too). This gets picked up by vboxwrapper and
>> > ERR_CPU_VM_EXTENSIONS_DISABLED gets output to stderr.txt in the slot
>> > directory which gets reported back to the server as part of the
>> > sched_request file. The stderr.txt shoud be 

Re: [boinc_dev] vbox64 and virtualization

[Rom Walton]

What is supposed to happen is:

When the VM shuts down, vboxwrapper parses the end of vbox.log looking for the 
possible error codes related to the VM extensions being disabled.  If found, it 
then writes the following to stderr 'ERR_CPU_VM_EXTENSIONS_DISABLED'.

BOINC parses the stderr text when the app exits, if it detects the above text 
it sets a flag that says the VM extensions have been disabled on the machine.  
In the sched_request file it is named .

I recently updated vboxwrapper to support the newer error codes returned in 
VirtualBox 5.0:
https://github.com/BOINC/boinc/commit/0ee90d7995118ff5fd00c68af734050172f7733a

That commit should be in 26173 or above.

- Rom

List of VirtualBox error codes is in vbox_common.cpp:320-338

What is written to stderr is in vboxwrapper.cpp:774-784

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Marius 
Millea
Sent: Thursday, October 15, 2015 7:31 PM
To: BOINC-dev email list 
Subject: [boinc_dev] vbox64 and virtualization

Hi all,

Virtualbox can't run a 64bit guest OS unless you have virtualization (VT-x or 
AMD-v or whatever it might be called...) enabled in your BIOS. Hence no app 
which is plan class vbox64 should be sent to a host which does not have this 
enabled. Unfortunately I'm not seeing either happen. First, I turned off VT-x 
on my machine, rebooted and readded the project, and I'm still receiving vbox64 
jobs. Should this be happening or is this a feature which does not exist yet?

Secondly, it seems like vboxwrapper ought to catch this and shut down with some 
informative error message. From the source it looks like it does have some code 
which attempts to catch this, but at least on my system it doesn't seem to 
work. It gets stuck saying "Status Report:
virtualbox/vboxheadless is no longer running." for a while, then gives me 
"Waiting to run (VM Hypervisor failed to enter an online state in a timely 
fashion)". Any ideas what's going on?

Thanks,

Marius
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

[boinc_dev] Vboxwrapper 26176

[Rom Walton]

Howdy Folks,

We have published a new version of Vboxwrapper which addresses these issues:
* VBOX: Add code to handle search path modification for Linux and Mac.
* VBOX: On a hypervisor detection failure dump all the logs to stderr, it would 
have quickly exposed a search path change on Mac OS X.
* VBOX: Reduce the amount of disk I/O when parsing the VM log file
* VBOX: Fix a regression introduced in 26172 with starting up a VM

- Rom
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

[boinc_dev] Vboxwrapper 26173

[Rom Walton]

Howdy Folks,

We have published a new version of Vboxwrapper which addresses these issues:
* Update the error codes being looked for with regards to VMX and SVM related 
errors.
* Fix a crashing bug in the wrapper when the VM process itself fails to start.

VirtualBox 5.x changed the name of a few of their VMX error codes.  This leads 
to BOINC/Vboxwrapper not properly detecting when the host cannot properly 
detect VMX/SVM instruction set issues.  Namely that they might be disabled in 
the BIOS, or something of that nature.

- Rom
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Default process priority

[Rom Walton]

I committed a fix for this.

Sorry about the build break.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Stephen Maclagan
Sent: Monday, October 05, 2015 7:03 PM
To: Richard Haselgrove ; David Anderson 
; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Default process priority

Tried building Boinc 7.6 from the Boinc 7.6 head, it fails with:

stephen@stephen-MM061:~/boinc76$ make
cd . && sh generate_svn_version.sh
make  all-recursive
make[1]: Entering directory `/home/stephen/boinc76'
Making all in m4
make[2]: Entering directory `/home/stephen/boinc76/m4'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/stephen/boinc76/m4'
Making all in api
make[2]: Entering directory `/home/stephen/boinc76/api'
  CXX  boinc_api.lo
  CXX  graphics2_util.lo
  CXX  reduce_main.lo
  CXXLDlibboinc_api.la
  CXX  libboinc_graphics2_la-gutil.lo
  CXX  libboinc_graphics2_la-gutil_text.lo
  CXX  libboinc_graphics2_la-reduce_lib.lo
  CXX  libboinc_graphics2_la-graphics2.lo
  CXX  libboinc_graphics2_la-graphics2_unix.lo
  CXXLDlibboinc_graphics2.la
  CXX  boinc_opencl.lo
  CXXLDlibboinc_opencl.la
rm -f libboinc_api.a
/bin/ln .libs/libboinc_api.a .
rm -f libboinc_graphics2.a
/bin/ln .libs/libboinc_graphics2.a .
rm -f libboinc_opencl.a
/bin/ln .libs/libboinc_opencl.a .
make[2]: Leaving directory `/home/stephen/boinc76/api'
Making all in lib
make[2]: Entering directory `/home/stephen/boinc76/lib'
  CXX  libboinc_la-app_ipc.lo
  CXX  libboinc_la-base64.lo
  CXX  libboinc_la-cc_config.lo
  CXX  libboinc_la-cert_sig.lo
  CXX  libboinc_la-coproc.lo
  CXX  libboinc_la-diagnostics.lo
diagnostics.cpp:707:6: warning: unused parameter 'siginfo' [-Wunused-parameter] 
 void boinc_catch_signal(int signal, struct siginfo *siginfo, void *sigcontext) 
{
  ^
diagnostics.cpp:707:6: warning: unused parameter 'sigcontext' 
[-Wunused-parameter]
diagnostics.cpp: In function 'void boinc_catch_signal(int, siginfo*, void*)':
diagnostics.cpp:734:73: warning: ignoring return value of 'ssize_t write(int, 
const void*, size_t)', declared with attribute warn_unused_result 
[-Wunused-result]
 (void) write(fileno(stderr),"Stack trace (",strlen("Stack trace ("));
 ^
diagnostics.cpp:743:49: warning: ignoring return value of 'ssize_t write(int, 
const void*, size_t)', declared with attribute warn_unused_result 
[-Wunused-result]
 (void) write(fileno(stderr),p+1,strlen(p+1));
 ^
diagnostics.cpp:744:65: warning: ignoring return value of 'ssize_t write(int, 
const void*, size_t)', declared with attribute warn_unused_result 
[-Wunused-result]
 (void) write(fileno(stderr)," frames):",strlen(" frames):"));
 ^
diagnostics.cpp:746:40: warning: ignoring return value of 'ssize_t write(int, 
const void*, size_t)', declared with attribute warn_unused_result 
[-Wunused-result]
 (void) write(fileno(stderr),mbuf,1);
^
  CXX  libboinc_la-filesys.lo
filesys.cpp: In function 'int boinc_copy(const char*, const char*)':
filesys.cpp:602:42: warning: ignoring return value of 'int chown(const char*, 
__uid_t, __gid_t)', declared with attribute warn_unused_result [-Wunused-result]
 chown(newf, sbuf.st_uid, sbuf.st_gid);
  ^
  CXX  libboinc_la-gui_rpc_client.lo
  CXX  libboinc_la-gui_rpc_client_ops.lo
  CXX  libboinc_la-gui_rpc_client_print.lo
  CXX  libboinc_la-hostinfo.lo
  CXX  libboinc_la-md5.lo
  CXX  libboinc_la-md5_file.lo
  CXX  libboinc_la-mem_usage.lo
  CXX  libboinc_la-mfile.lo
  CXX  libboinc_la-miofile.lo
  CXX  libboinc_la-msg_log.lo
  CXX  libboinc_la-network.lo
  CXX  libboinc_la-notice.lo
  CXX  libboinc_la-opencl_boinc.lo
  CXX  libboinc_la-parse.lo
  CXX  libboinc_la-prefs.lo
  CXX  libboinc_la-procinfo.lo
  CXX  libboinc_la-proc_control.lo
  CXX  libboinc_la-proxy_info.lo
  CXX  libboinc_la-shmem.lo
shmem.cpp: In function 'int create_shmem_mmap(const char*, size_t, void**)':
shmem.cpp:340:27: warning: ignoring return value of 'ssize_t write(int, const 
void*, size_t)', declared with attribute warn_unused_result [-Wunused-result]
 write(fd, "\0", 1);
   ^
  CXX  libboinc_la-str_util.lo
  CXX  libboinc_la-url.lo
  CXX  libboinc_la-util.lo
  CXX  libboinc_la-procinfo_unix.lo
  CXX  libboinc_la-synch.lo
  CXX  libboinc_la-unix_util.lo
  CXXLDlibboinc.la
  CXX  libboinc_crypt_la-crypt.lo
crypt.cpp: In function 'int scan_key_hex(FILE*, KEY*, int)':
crypt.cpp:220:29: warning: ignoring return value of 'int fscanf(FILE*, const 
char*, ...)', 

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

I would consider that a design failure.

Ideally, for a fully customized installer, there only needs to be two times the 
volunteer needs to provide input.  Once to kick off the installer and the other 
to confirm they really do want to contribute their CPU/GPU cycles to a given 
project/account manager.

Any additional interactions should be around failure cases, such as needing to 
know the proxy servers name and port number if there is a communication failure 
and the client cannot ping www.google.com.

- Rom

-Original Message-
From: Tristan Olive [mailto:tristan.ol...@studiodelta.us] On Behalf Of Tristan 
Olive
Sent: Monday, September 28, 2015 1:31 PM
To: Rom Walton <r...@romwnet.org>
Cc: Matthew Blumberg <m...@gridrepublic.org>; BOINC Developers Mailing List 
<boinc_dev@ssl.berkeley.edu>; Rytis Slatkevičius <ry...@gridrepublic.org>; Hugh 
Wormington <h...@gridrepublic.org>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

On Mon 28 Sep 2015 01:16:35 PM EDT, Rom Walton wrote:
>
> Originally I envisioned this as something interjected between steps 1 
> and 2, when the browser window is closed, it passes the GUID to the 
> lookup account phase and proceeds based on success or failure. What 
> your proposing is to push more of the attach process into the client 
> so the attach process can move between its states without the wizard 
> being stuck displaying the bouncing ball between two computers.
>
> It would require a major overhaul of the client/manager-side attach 
> process to support.
>


What about just pausing the wizard while the browser window is opened, then 
when the user gets the "all clear" message in the browser, they can click to 
continue the wizard. No reason for the wizard itself to have to get any info 
from the browser window at all (as I'd think that would be complicated and 
prone to maintenance issues).

--
Tristan Olive

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

2)  So the volunteer is supposed to leave the manager alone for a few hours 
while it is stuck in the attach wizard bouncing a ball between two computers?

I suspect that is not what you had in mind.

The whole reason for the wizards existence is to provide the client software 
with an authenticator to attach to a project/account manager with when 
completed.  If we leave the wizard and begin some background operation in the 
client, then the volunteer gets an empty UI not doing anything as far as they 
can tell.  They would have to go to the event log (Advanced UI thing) just to 
see what the client is up too.

Behind the wizard this is what is going on:

1.   Get Project Config RPC (Run in Manager): detect various things about a 
project/account manager.  Minimum password lengths, platforms supported, 
canonical project URL, etc.

2.   Lookup Account/Create Account (Run in Manager): get the volunteer to 
give us enough information to acquire an authenticator.

3.   Attach to project (Run in Client): when the wizard closes it instructs 
the client to attach to a project with the given authenticator.

Once the client begins the attach process, the UI sees a project.  It can 
display some information about it.

Originally I envisioned this as something interjected between steps 1 and 2, 
when the browser window is closed, it passes the GUID to the lookup account 
phase and proceeds based on success or failure.  What your proposing is to push 
more of the attach process into the client so the attach process can move 
between its states without the wizard being stuck displaying the bouncing ball 
between two computers.

It would require a major overhaul of the client/manager-side attach process to 
support.

- Rom


From: hugh.w...@gmail.com [mailto:hugh.w...@gmail.com] On Behalf Of Hugh 
Wormington
Sent: Monday, September 28, 2015 12:35 PM
To: Rom Walton <r...@romwnet.org>
Cc: Hugh Wormington <h...@gridrepublic.org>; Matthew Blumberg 
<m...@gridrepublic.org>; Rytis Slatkevičius <ry...@gridrepublic.org>; BOINC 
Developers Mailing List <boinc_dev@ssl.berkeley.edu>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

1) In the case of Progres Thru Processors the login is Facebook's, which they 
know. PTP links that through to the GR/BOINC user in the background. Apologies 
for not making that clear.
2) The client could poll for a few hours max, after which it could wait until 
the next time it's started up and then poll once and if necessary try the whole 
thing again.

  *   I notice that other software sometimes fires up a browser window e.g. for 
feedback after uninstalling. Granted that example is not critical, but with the 
right UI I think it should be robust. For example if the first attempt failed, 
the client could show a window containing a link with a text like "Add this 
computer to your Progress Thru Processors (or whatever) account to get going 
(opens a browser window)".
  *   No user interaction is required unless the browser is no longer logged in.
  *   I'm not aware of any plugins/AVs etc that would interfere with this 
process unless an AV identified the URL as suspect, in which case we're 
probably stuffed anyway.
  *   Rather than being browser-dependent it should be future-proof.
5) Interesting. There's a discussion about UUID uniquness in stackoverflow 
here<http://stackoverflow.com/questions/1155008/how-unique-is-uuid>.
Hugh

On 28 September 2015 at 16:48, Rom Walton 
<r...@romwnet.org<mailto:r...@romwnet.org>> wrote:


1.   In the case of Progress Thru Processors, it is a catastrophic failure 
case.  Volunteers do not know what username/password they have been assigned.

2-4.  How long should the client poll before assuming an error has occurred?  
All the various browser issues exist with plugins getting in the way plus now 
you might have window z-orders to worry about.  What happens if the manager is 
over the browser window when it is looking for a username/password?  What 
happens if the browser window is stuck behind a word processing application?

5.  They do happen though.  After deploying a test framework for a web property 
on a project I previously worked on, we would experience a 50% failure rate on 
test cases overnight every third day of testing.  While the math says one thing 
it is still something that has to be accounted for.  Granted the likelihood 
drops dramatically when they expire after a given amount of time.  But you 
still might run into denial of service attacks accepting what amounts to random 
input from random locations on the internet.  Although, I suppose you could 
just ignore the GUID if the session cookie is not available.

Frankly, the more and more I think about this, the less and less I like it.  
With browser cookie lookup we only had to deal with changes to three browsers 
who more or less kept things somewhat predictable day to day.  Now we ar

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

Violation of basic computational rights?

I'm not sure the filename approach is really all that far out there.

Microsoft uses it for Office 2016 deployments.  Their new installer process 
does something similar to what we are trying to do when installing office.

An example of the filename they use is:
Setup.X64.en-US_O365HomePremRetail_0174f7b5-908c-4338-be4c-_TX_PR_.exe

Their web page that kicks off the download process simply states we are going 
to download a file to your computer.  When your browser gives you an option to 
save it or run it, choose run.

- Rom

-Original Message-
From: Tristan Olive [mailto:tristan.ol...@studiodelta.us] On Behalf Of Tristan 
Olive
Sent: Monday, September 28, 2015 1:00 PM
To: Rom Walton <r...@romwnet.org>
Cc: Hugh Wormington <h...@gridrepublic.org>; Rytis Slatkevičius 
<ry...@gridrepublic.org>; BOINC Developers Mailing List 
<boinc_dev@ssl.berkeley.edu>; Matthew Blumberg <m...@gridrepublic.org>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

I agree that an IP cannot be expected to be a reliable, unique identifier, even 
short term. However, I also think the long filename is unreliable, as it 
requires that a user not do basic file management on his own system. It feels 
like a "violation of basic computational rights" to expect this. Also, is the 
maximum path length on Windows still an issue? We can't be sure where the 
download directory is located, as that is also browser dependent and user 
configurable, so the total path length is unpredictable.

To go along with what Hugh is suggesting, see the attached (rudimentary) chart 
showing the flow of how this could work. Note that the nonce really is only 
used to establish a handshake of sorts between the client and server; once that 
has been done, the server gives the client a separate, verifiably-unique auth 
key to be used in  for client authentication going forward.

If the browser launch fails, can we add a link or button or menu item somewhere 
in the client as a manual retry? Then we could send the user a notice after 
some time saying, "we see you have not completed installation, please follow 
these directions to continue."

--
Tristan Olive

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

One IP address can represent many machines if they are behind a NAT device.  
Now that North America has run out of IP addresses to be assigned, I expect 
carrier grade NATs will be used by more ISPs than in the past.

IP addresses as a means of identification is a bad idea.

- Rom

From: Filip Rydlo [mailto:filip.ry...@gmail.com]
Sent: Monday, September 28, 2015 3:49 AM
To: Rom Walton <r...@romwnet.org>
Cc: BOINC-dev email list <boinc_dev@ssl.berkeley.edu>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

Yes, Rom.
   It really seems like a monster on the client side. This is neither 
easy nor  error-proof.

So, ... :
  Why not to save the unique "GUID" (generated by the server) + all 
this info  (with perfectly encrypted password)  in a dedicated (MySQL) DATABASE 
 on the main BOINC web-server? (it could be easily "cron"-ned to be cleaned 
from old entries and Vacuum-analyzed  every 4 hours or so)

It would be browser-independent.  IT would be easily implemented as 
temporary  and as valid only for the given I.P. address  - which is the same 
(during a short interval like 1 hour)  across all browsers on the PC / VM  , as 
far as I know.
Namaste
Filip



2015-09-28 2:44 GMT+02:00 Rom Walton 
<r...@romwnet.org<mailto:r...@romwnet.org>>:
GUID would be more appropriate.

I foresee a few problems with this approach though:

1.   The ‘default’ browser wxWidgets detects may not be the browser the 
volunteer downloaded BOINC with.

2.   The manager would have to wait on the association to complete which 
means it has to know how to deal with whatever browser to launched.
(Basically the manager would have to know how each browser works. (window 
names, window class names, window titles, what events each window responds too))
(This is actually a more complicated problem than dealing with cookies.)

3.   We may never be able to find out if the association was successful 
from the manager perspective.

4.   Some browser plugins redirect errors and monkey with the error pages. 
(Norton 360, Google Toolbar, Yahoo Toolbar, etc.)

5.   There is a remote possibility that two machines can generate the same 
GUID, without being able to check against the master list ahead of time it 
could happen.

This solution might look okay from a server perspective, but it is a monster 
from a client implementation perspective.

- Rom


From: hugh.w...@gmail.com<mailto:hugh.w...@gmail.com> 
[mailto:hugh.w...@gmail.com<mailto:hugh.w...@gmail.com>] On Behalf Of Hugh 
Wormington
Sent: Sunday, September 27, 2015 5:22 PM
To: Rom Walton <r...@romwnet.org<mailto:r...@romwnet.org>>
Cc: Matthew Blumberg <m...@gridrepublic.org<mailto:m...@gridrepublic.org>>; 
Hugh Wormington <h...@gridrepublic.org<mailto:h...@gridrepublic.org>>; Rytis 
Slatkevičius <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>>; BOINC 
Developers Mailing List 
<boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

> Where is the nonce generated?
By the installer.

> If it is generated by the installer and passed to the account manager, how to 
> we know who it came from?
The installer loads a browser on the url passing the "nonce" as a url 
parameter. The receiving page is then able to associate it with a logged-in 
user, after which the association is known.

A little side issue for avoidance of lexical confusion I'm a little unsure 
if this is really a "nonce" :

  *   Nonce: is an arbitrary number that may only be used once in secure 
communication exchange (See diagram on this wikipedia 
page<https://en.wikipedia.org/wiki/Cryptographic_nonce>) It doesn't carry any 
information itself.
  *   GUID: A globally unique identifier (GUID, /ˈɡuːɪd/) is a unique reference 
number used as an identifier in computer software. The term "GUID" typically 
refers to various implementations of the universally unique 
identifier<https://en.wikipedia.org/wiki/Universally_unique_identifier> (UUID) 
standard (Wikipedia<https://en.wikipedia.org/wiki/Globally_unique_identifier>)

I think we're talking about a GUID which the installer generates at install 
time and uses to identify itself to two different processes 1) the front end 
web application 2) the account manager server.
(A CPID is a kind of GUID, but this one isn't a CPID, since CPIDs are (AFAIK) 
generated by the BOINC project servers.)

So is it a nonce or a GUID?
Hugh

PS Many apologies if I'm teaching grandmothers to suck eggs (does that work 
internationally??).

On 26 September 2015 at 02:56, Rom Walton 
<r...@romwnet.org<mailto:r...@romwnet.org><mailto:r...@romwnet.org<mailto:r...@romwnet.org>>>
 wrote:
In theory we could open up a browser with a URL like that.

Wh

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

1.   In the case of Progress Thru Processors, it is a catastrophic failure 
case.  Volunteers do not know what username/password they have been assigned.

2-4.  How long should the client poll before assuming an error has occurred?  
All the various browser issues exist with plugins getting in the way plus now 
you might have window z-orders to worry about.  What happens if the manager is 
over the browser window when it is looking for a username/password?  What 
happens if the browser window is stuck behind a word processing application?

5.  They do happen though.  After deploying a test framework for a web property 
on a project I previously worked on, we would experience a 50% failure rate on 
test cases overnight every third day of testing.  While the math says one thing 
it is still something that has to be accounted for.  Granted the likelihood 
drops dramatically when they expire after a given amount of time.  But you 
still might run into denial of service attacks accepting what amounts to random 
input from random locations on the internet.  Although, I suppose you could 
just ignore the GUID if the session cookie is not available.

Frankly, the more and more I think about this, the less and less I like it.  
With browser cookie lookup we only had to deal with changes to three browsers 
who more or less kept things somewhat predictable day to day.  Now we are 
trying to work into the equation any number of browsers and the random factor 
of what the volunteer has configured (browser preferences, virus scanners, 
anti-malware detectors, browser plugins) and how they are using their system at 
the time of install.

- Rom

From: hugh.w...@gmail.com [mailto:hugh.w...@gmail.com] On Behalf Of Hugh 
Wormington
Sent: Monday, September 28, 2015 5:22 AM
To: Rom Walton <r...@romwnet.org>
Cc: Hugh Wormington <h...@gridrepublic.org>; Matthew Blumberg 
<m...@gridrepublic.org>; Rytis Slatkevičius <ry...@gridrepublic.org>; BOINC 
Developers Mailing List <boinc_dev@ssl.berkeley.edu>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)


1. This shouldn't matter. If the session cookie is missing (ie user not already 
logged into the website in that browser) then they will just be asked to login. 
NB the current installer cookies should no longer be used since the user 
identification comes from the website login. The user is then greeted with some 
message like "this computer has been added to your account".

2. to 4. I agree that approach seems unfeasible. I imagined the client simply 
poll the AMS until its GUID is "claimed" by a user. Is that feasible?
It might also be good to have the ability to "retry attach" to a user account 
in case the original process didn't complete, maybe at boot time if it finds 
itself unclaimed. A "retry" would simply involve  reloading the original 
browser URL.

5. GUIDs are widely used; the generator eg UUID ensures duplicates are so rare 
that statistically they never happen.
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]Hugh

On 28 September 2015 at 01:44, Rom Walton 
<r...@romwnet.org<mailto:r...@romwnet.org>> wrote:
GUID would be more appropriate.

I foresee a few problems with this approach though:

1.   The ‘default’ browser wxWidgets detects may not be the browser the 
volunteer downloaded BOINC with.

2.   The manager would have to wait on the association to complete which 
means it has to know how to deal with whatever browser to launched.
(Basically the manager would have to know how each browser works. (window 
names, window class names, window titles, what events each window responds too))
(This is actually a more complicated problem than dealing with cookies.)

3.   We may never be able to find out if the association was successful 
from the manager perspective.

4.   Some browser plugins redirect errors and monkey with the error pages. 
(Norton 360, Google Toolbar, Yahoo Toolbar, etc.)

5.   There is a remote possibility that two machines can generate the same 
GUID, without being able to check against the master list ahead of time it 
could happen.
This solution might look okay from a server perspective, but it is a monster 
from a client implementation perspective.

- Rom


From: hugh.w...@gmail.com<mailto:hugh.w...@gmail.com> 
[mailto:hugh.w...@gmail.com<mailto:hugh.w...@gmail.com>] On Behalf Of Hugh 
Wormington
Sent: Sunday, September 27, 2015 5:22 PM
To: Rom Walton <r...@romwnet.org<mailto:r...@romwnet.org>>
Cc: Matthew Blumberg <m...@gridrepublic.org<mailto:m...@gridrepublic.org>>; 
Hugh Wormington <h...@gridrepublic.org<mailto:h...@gridrepublic.org>>; Rytis 
Slatkevičius <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>>; BOINC 
Developers Mailing List 
<boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>>

Subject: Re: [boi

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

GUID would be more appropriate.

I foresee a few problems with this approach though:

1.   The ‘default’ browser wxWidgets detects may not be the browser the 
volunteer downloaded BOINC with.

2.   The manager would have to wait on the association to complete which 
means it has to know how to deal with whatever browser to launched.
(Basically the manager would have to know how each browser works. (window 
names, window class names, window titles, what events each window responds too))
(This is actually a more complicated problem than dealing with cookies.)

3.   We may never be able to find out if the association was successful 
from the manager perspective.

4.   Some browser plugins redirect errors and monkey with the error pages. 
(Norton 360, Google Toolbar, Yahoo Toolbar, etc.)

5.   There is a remote possibility that two machines can generate the same 
GUID, without being able to check against the master list ahead of time it 
could happen.

This solution might look okay from a server perspective, but it is a monster 
from a client implementation perspective.

- Rom


From: hugh.w...@gmail.com [mailto:hugh.w...@gmail.com] On Behalf Of Hugh 
Wormington
Sent: Sunday, September 27, 2015 5:22 PM
To: Rom Walton <r...@romwnet.org>
Cc: Matthew Blumberg <m...@gridrepublic.org>; Hugh Wormington 
<h...@gridrepublic.org>; Rytis Slatkevičius <ry...@gridrepublic.org>; BOINC 
Developers Mailing List <boinc_dev@ssl.berkeley.edu>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

> Where is the nonce generated?
By the installer.

> If it is generated by the installer and passed to the account manager, how to 
> we know who it came from?
The installer loads a browser on the url passing the "nonce" as a url 
parameter. The receiving page is then able to associate it with a logged-in 
user, after which the association is known.

A little side issue for avoidance of lexical confusion I'm a little unsure 
if this is really a "nonce" :

  *   Nonce: is an arbitrary number that may only be used once in secure 
communication exchange (See diagram on this wikipedia 
page<https://en.wikipedia.org/wiki/Cryptographic_nonce>) It doesn't carry any 
information itself.
  *   GUID: A globally unique identifier (GUID, /ˈɡuːɪd/) is a unique reference 
number used as an identifier in computer software. The term "GUID" typically 
refers to various implementations of the universally unique 
identifier<https://en.wikipedia.org/wiki/Universally_unique_identifier> (UUID) 
standard (Wikipedia<https://en.wikipedia.org/wiki/Globally_unique_identifier>)

I think we're talking about a GUID which the installer generates at install 
time and uses to identify itself to two different processes 1) the front end 
web application 2) the account manager server.
(A CPID is a kind of GUID, but this one isn't a CPID, since CPIDs are (AFAIK) 
generated by the BOINC project servers.)

So is it a nonce or a GUID?
Hugh

PS Many apologies if I'm teaching grandmothers to suck eggs (does that work 
internationally??).

On 26 September 2015 at 02:56, Rom Walton 
<r...@romwnet.org<mailto:r...@romwnet.org>> wrote:
In theory we could open up a browser with a URL like that.

Where is the nonce generated?

If it is generated from the account manager, how does the installer find it?

If it is generated by the installer and passed to the account manager, how to 
we know who it came from?

- Rom

From: mblumb...@picador.net<mailto:mblumb...@picador.net> 
[mailto:mblumb...@picador.net<mailto:mblumb...@picador.net>] On Behalf Of 
Matthew Blumberg
Sent: Friday, September 25, 2015 6:27 PM
To: Rom Walton <r...@romwnet.org<mailto:r...@romwnet.org>>
Cc: Hugh Wormington <h...@gridrepublic.org<mailto:h...@gridrepublic.org>>; 
Rytis Slatkevičius <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>>; 
BOINC Developers Mailing List 
<boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>>

Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

So for GR/CE/PTP you end up with filenames like:
gr_setup_asc_ODU0NjVfZWEwYWJkNjc4NDc2MjllMWFlOWVkM2I4YWRmZmZmZmY=.exe


i'm really not comfortable with filenames like that

for AMS, is it possible to  :

  1.  open a browser window upon completion of install (*as is done already); 
but instead of using return_url from the cookie, use instead the URL from 
acct_mgr_url.xml, and append a random number as a parameter, e.g. 
http://acctmgr.com/?return_id=[nonce]<http://acctmgr.com/?return_id=%5bnonce%5d>
  2.  and then also use that same return_id as the user email address (e.g. as 
of the user had entered this into the email field when registering manually)

(*tristan/rytis/hught, pls add any clarification if i'm missing something or 
got something wrong)





On Fri, Sep 25, 2015 at 10:21 AM

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

In theory we could open up a browser with a URL like that.

Where is the nonce generated?

If it is generated from the account manager, how does the installer find it?

If it is generated by the installer and passed to the account manager, how to 
we know who it came from?

- Rom

From: mblumb...@picador.net [mailto:mblumb...@picador.net] On Behalf Of Matthew 
Blumberg
Sent: Friday, September 25, 2015 6:27 PM
To: Rom Walton <r...@romwnet.org>
Cc: Hugh Wormington <h...@gridrepublic.org>; Rytis Slatkevičius 
<ry...@gridrepublic.org>; BOINC Developers Mailing List 
<boinc_dev@ssl.berkeley.edu>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

So for GR/CE/PTP you end up with filenames like:
gr_setup_asc_ODU0NjVfZWEwYWJkNjc4NDc2MjllMWFlOWVkM2I4YWRmZmZmZmY=.exe


i'm really not comfortable with filenames like that

for AMS, is it possible to  :

  1.  open a browser window upon completion of install (*as is done already); 
but instead of using return_url from the cookie, use instead the URL from 
acct_mgr_url.xml, and append a random number as a parameter, e.g. 
http://acctmgr.com/?return_id=[nonce]<http://acctmgr.com/?return_id=%5bnonce%5d>
  2.  and then also use that same return_id as the user email address (e.g. as 
of the user had entered this into the email field when registering manually)

(*tristan/rytis/hught, pls add any clarification if i'm missing something or 
got something wrong)





On Fri, Sep 25, 2015 at 10:21 AM, Rom Walton 
<r...@romwnet.org<mailto:r...@romwnet.org>> wrote:
A point of clarification.

Everything the client needs to communicate with a project/account manager will 
be in project_init.xml or acct_mgr_url.xml.

All that will be missing to do an attach is an authenticator.

- Rom

-Original Message-
From: boinc_dev 
[mailto:boinc_dev-boun...@ssl.berkeley.edu<mailto:boinc_dev-boun...@ssl.berkeley.edu>]
 On Behalf Of Rom Walton
Sent: Friday, September 25, 2015 10:02 AM
To: Hugh Wormington <h...@gridrepublic.org<mailto:h...@gridrepublic.org>>; 
Rytis Slatkevičius <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>>
Cc: Matthew Blumberg <m...@gridrepublic.org<mailto:m...@gridrepublic.org>>; 
BOINC Developers Mailing List 
<boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

In essence this is what the setup cookie is for.

In cases where there is a customized installer, everything the client needs 
will be in the project_init.xml or acct_mgr_url.xml (in the case of account 
managers) files.  BOINC will treat the setup cookie as opaque data and just 
send it back to 
https:///lookup_account.php<https://%3cproject_url%3e/lookup_account.php<https://%3cproject_url%3e/lookup_account.php%3chttps:/%3cproject_url%3e/lookup_account.php>>.

So for GR/CE/PTP you end up with filenames like:
gr_setup_asc_ODU0NjVfZWEwYWJkNjc4NDc2MjllMWFlOWVkM2I4YWRmZmZmZmY=.exe

The filename can be made shorter as it depends on how large you want your 
random piece of data to be.

- Rom

From: hugh.w...@gmail.com<mailto:hugh.w...@gmail.com> 
[mailto:hugh.w...@gmail.com<mailto:hugh.w...@gmail.com>] On Behalf Of Hugh 
Wormington
Sent: Friday, September 25, 2015 6:56 AM
To: Rytis Slatkevičius <ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>>
Cc: Matthew Blumberg <m...@gridrepublic.org<mailto:m...@gridrepublic.org>>; Rom 
Walton <r...@romwnet.org<mailto:r...@romwnet.org>>; BOINC Developers Mailing 
List <boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu>>; Tristan 
Olive <tol...@gridrepublic.org<mailto:tol...@gridrepublic.org>>; Hugh 
Wormington <h...@gridrepublic.org<mailto:h...@gridrepublic.org>>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

Further to Rytis's email (is this the place to continue this discussion or in 
Jira?):
I agree, but I think the stored meta data need not include user info, only the 
project url. The installer would load a page on 
boinc.berkeley.edu<http://boinc.berkeley.edu><http://boinc.berkeley.edu> in a 
browser, passing the nonce or cipid or guid as a URL parameter (whichever 
variant is adopted). That in turn would forward it to the project site. At this 
point the project site could receive the cookies it set earlier (private and 
secure), and the nonce/cipid/guid and continue the process. If it finds no 
cookies it can ask the user to log in to the project site and then continue.
Hugh

On 25 September 2015 at 07:48, Rytis Slatkevičius 
<ry...@gridrepublic.org<mailto:ry...@gridrepublic.org><mailto:ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>>>
 wrote:
Is there really a need for such schemes?

A script will be running to generate the download filenames (I assume at 
boinc.berkeley.ed

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

Using IP addresses is kind of iffy, think a bunch of computers within a 
corporate environment.  With a small company we probably wouldn't run into a 
problem.  IBM or Microsoft, we probably would.

Cookies themselves are a weak point as the browsers are constantly changing and 
require us to update the cookie detection code.  Over time things fall apart 
for the same BOINC version.  

Once the installer is code-signed, the contents of the installation package 
cannot be changed.  If we had a static URL on the Internet that we point the 
installer to and it disappears, then that scheme falls apart.

Encoding things within the file name avoids a single point of failure relative 
to the code-signed installer.  The server-side code that handles the file 
rename process can run from whichever server the volunteer is downloading the 
installer from.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Christian Beer
Sent: Friday, September 25, 2015 8:40 AM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

What Rytis suggests sounds good but relies on the availability of 
boinc.berkeley.edu which I consider a week point at the moment. Sending 
Web-RPCs is better than the cookie thing because we already support Web-RPC's 
and just need to define where to send the RPC to. We would need a permanent URL 
where the Client can get the metadata from that doesn't change because it is 
hardcoded in the Client/Installer. The IP lookup should work if the metadata 
expires within a few hours because the IP maybe reassigned to another user in 
the meantime. Sure the scenario to exploit this is unlikely but possible.

MfG / Regards
Christian Beer

Am 25.09.2015 um 10:08 schrieb David Anderson:
> That scheme sounds plausible,
> but it seems more complex than what Rom proposed.
> -- D
>
> On 9/24/2015 11:48 PM, Rytis Slatkevičius wrote:
>> Is there really a need for such schemes?
>>
>> A script will be running to generate the download filenames (I assume 
>> at boinc.berkeley.edu); why not store user's temporary metadata on 
>> the server instead of passing it through the installer filename, and 
>> look it up based on the IP address? There are not going to be any 
>> clashes if metadata is stored for only a short while.
>>
>> The process would be as follows:
>> 1. The user registers at a website;
>> 2. The website sends an RPC to boinc.berkeley.edu (or other URLs, 
>> e.g. in case of a custom build), storing metadata as well as user's 
>> IP address; 3. The user downloads a regular installation file and 
>> installs; 4. Once installed, the first thing the client does is 
>> contact boinc.berkeley.edu to retrieve metadata and attach wherever 
>> needed (maybe even possible through the installer?). The server would 
>> load data based on the requester's IP address.
>>
>>
>> -- 
>> Pagarbiai / Sincerely
>> Rytis Slatkevičius
>> +370 670 7
>>
>> On Fri, Sep 25, 2015 at 12:28 AM, Matthew Blumberg
>> <m...@gridrepublic.org>
>> wrote:
>>
>>> I'm a little worried about the proposed approach; I fear it will
>>> notably
>>> reduce conversion-completion rates -- if i got an installer with a 120
>>> character filename, i'd [a] edit to clean it up, and/or [b] assume
>>> it was
>>> corrupted or infected and be afraid to run it.
>>>
>>> In any event, by way of making this work in the AMS context, can we
>>> request one minor revision to the current scheme --
>>>
>>> In the current scheme, at completion of install, the wizard opens a
>>> browser window using the return_url specified in the browser cookie.
>>> Could
>>> you instead open a browser window upon completion, using the URL
>>> from acct_mgr_url.xml, and appending a random number as a parameter,
>>> e.g.
>>> http://acctmgr.com/?return_id=[nonce]
>>>
>>> Best Wishes,
>>>
>>> ..Matt
>>>
>>>
>>>
>>>
>>> On Mon, Sep 21, 2015 at 10:59 AM, Rom Walton <r...@romwnet.org> wrote:
>>>
>>>> Howdy Folks,
>>>>
>>>> Current Strategy:
>>>> https://boinc.berkeley.edu/trac/wiki/SimpleAttach
>>>>
>>>> As part of the simplification process we (WCG and I) would like to
>>>> propose the idea of cookieless installs.
>>>>
>>>> See:
>>>> https://boinc.berkeley.edu/trac/wiki/SimpleAttach#CookielessInstalls
>>>>
>>>> Pros:
>>>>
>>>> We would be able to get around the various issues with cookies s

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

In essence this is what the setup cookie is for.

In cases where there is a customized installer, everything the client needs 
will be in the project_init.xml or acct_mgr_url.xml (in the case of account 
managers) files.  BOINC will treat the setup cookie as opaque data and just 
send it back to 
https:///lookup_account.php<https://%3cproject_url%3e/lookup_account.php>.

So for GR/CE/PTP you end up with filenames like:
gr_setup_asc_ODU0NjVfZWEwYWJkNjc4NDc2MjllMWFlOWVkM2I4YWRmZmZmZmY=.exe

The filename can be made shorter as it depends on how large you want your 
random piece of data to be.

- Rom

From: hugh.w...@gmail.com [mailto:hugh.w...@gmail.com] On Behalf Of Hugh 
Wormington
Sent: Friday, September 25, 2015 6:56 AM
To: Rytis Slatkevičius <ry...@gridrepublic.org>
Cc: Matthew Blumberg <m...@gridrepublic.org>; Rom Walton <r...@romwnet.org>; 
BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu>; Tristan Olive 
<tol...@gridrepublic.org>; Hugh Wormington <h...@gridrepublic.org>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

Further to Rytis's email (is this the place to continue this discussion or in 
Jira?):
I agree, but I think the stored meta data need not include user info, only the 
project url. The installer would load a page on 
boinc.berkeley.edu<http://boinc.berkeley.edu> in a browser, passing the nonce 
or cipid or guid as a URL parameter (whichever variant is adopted). That in 
turn would forward it to the project site. At this point the project site could 
receive the cookies it set earlier (private and secure), and the 
nonce/cipid/guid and continue the process. If it finds no cookies it can ask 
the user to log in to the project site and then continue.
Hugh

On 25 September 2015 at 07:48, Rytis Slatkevičius 
<ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>> wrote:
Is there really a need for such schemes?

A script will be running to generate the download filenames (I assume at 
boinc.berkeley.edu<http://boinc.berkeley.edu>); why not store user's temporary 
metadata on the server instead of passing it through the installer filename, 
and look it up based on the IP address? There are not going to be any clashes 
if metadata is stored for only a short while.

The process would be as follows:
1. The user registers at a website;
2. The website sends an RPC to boinc.berkeley.edu<http://boinc.berkeley.edu> 
(or other URLs, e.g. in case of a custom build), storing metadata as well as 
user's IP address;
3. The user downloads a regular installation file and installs;
4. Once installed, the first thing the client does is contact 
boinc.berkeley.edu<http://boinc.berkeley.edu> to retrieve metadata and attach 
wherever needed (maybe even possible through the installer?). The server would 
load data based on the requester's IP address.


--
Pagarbiai / Sincerely
Rytis Slatkevičius
+370 670 7<tel:%2B370%20670%207>

On Fri, Sep 25, 2015 at 12:28 AM, Matthew Blumberg 
<m...@gridrepublic.org<mailto:m...@gridrepublic.org>> wrote:
I'm a little worried about the proposed approach; I fear it will notably reduce 
conversion-completion rates -- if i got an installer with a 120 character 
filename, i'd [a] edit to clean it up, and/or [b] assume it was corrupted or 
infected and be afraid to run it.

In any event, by way of making this work in the AMS context, can we request one 
minor revision to the current scheme --

In the current scheme, at completion of install, the wizard opens a browser 
window using the return_url specified in the browser cookie. Could you instead 
open a browser window upon completion, using the URL from acct_mgr_url.xml, and 
appending a random number as a parameter, e.g. 
http://acctmgr.com/?return_id=[nonce]<http://acctmgr.com/?return_id=%5bnonce%5d>

Best Wishes,

..Matt




On Mon, Sep 21, 2015 at 10:59 AM, Rom Walton 
<r...@romwnet.org<mailto:r...@romwnet.org>> wrote:
Howdy Folks,

Current Strategy:
https://boinc.berkeley.edu/trac/wiki/SimpleAttach

As part of the simplification process we (WCG and I) would like to propose the 
idea of cookieless installs.

See:
https://boinc.berkeley.edu/trac/wiki/SimpleAttach#CookielessInstalls

Pros:

We would be able to get around the various issues with cookies such as:
* Browser implementations changing over time.
* Sqlite changing over time
* Unknown browsers

Cons:

Realistically we are limited to filenames that are 256 characters in size.

Note: By default various shells on Windows limit the file namespace to 256 
characters, the limits can by bypassed by prefixing the filename with 
\\.\ but most users do not know that.  I also suspect that most 
browsers will complain about malware or something of that nature is we attempt 
to go past 256 characters.

- Rom
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl

Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

[Rom Walton]

A point of clarification.

Everything the client needs to communicate with a project/account manager will 
be in project_init.xml or acct_mgr_url.xml.

All that will be missing to do an attach is an authenticator.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Rom 
Walton
Sent: Friday, September 25, 2015 10:02 AM
To: Hugh Wormington <h...@gridrepublic.org>; Rytis Slatkevičius 
<ry...@gridrepublic.org>
Cc: Matthew Blumberg <m...@gridrepublic.org>; BOINC Developers Mailing List 
<boinc_dev@ssl.berkeley.edu>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

In essence this is what the setup cookie is for.

In cases where there is a customized installer, everything the client needs 
will be in the project_init.xml or acct_mgr_url.xml (in the case of account 
managers) files.  BOINC will treat the setup cookie as opaque data and just 
send it back to 
https:///lookup_account.php<https://%3cproject_url%3e/lookup_account.php>.

So for GR/CE/PTP you end up with filenames like:
gr_setup_asc_ODU0NjVfZWEwYWJkNjc4NDc2MjllMWFlOWVkM2I4YWRmZmZmZmY=.exe

The filename can be made shorter as it depends on how large you want your 
random piece of data to be.

- Rom

From: hugh.w...@gmail.com [mailto:hugh.w...@gmail.com] On Behalf Of Hugh 
Wormington
Sent: Friday, September 25, 2015 6:56 AM
To: Rytis Slatkevičius <ry...@gridrepublic.org>
Cc: Matthew Blumberg <m...@gridrepublic.org>; Rom Walton <r...@romwnet.org>; 
BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu>; Tristan Olive 
<tol...@gridrepublic.org>; Hugh Wormington <h...@gridrepublic.org>
Subject: Re: [boinc_dev] Proposal: Simple Attach (Cookieless Installs)

Further to Rytis's email (is this the place to continue this discussion or in 
Jira?):
I agree, but I think the stored meta data need not include user info, only the 
project url. The installer would load a page on 
boinc.berkeley.edu<http://boinc.berkeley.edu> in a browser, passing the nonce 
or cipid or guid as a URL parameter (whichever variant is adopted). That in 
turn would forward it to the project site. At this point the project site could 
receive the cookies it set earlier (private and secure), and the 
nonce/cipid/guid and continue the process. If it finds no cookies it can ask 
the user to log in to the project site and then continue.
Hugh

On 25 September 2015 at 07:48, Rytis Slatkevičius 
<ry...@gridrepublic.org<mailto:ry...@gridrepublic.org>> wrote:
Is there really a need for such schemes?

A script will be running to generate the download filenames (I assume at 
boinc.berkeley.edu<http://boinc.berkeley.edu>); why not store user's temporary 
metadata on the server instead of passing it through the installer filename, 
and look it up based on the IP address? There are not going to be any clashes 
if metadata is stored for only a short while.

The process would be as follows:
1. The user registers at a website;
2. The website sends an RPC to boinc.berkeley.edu<http://boinc.berkeley.edu> 
(or other URLs, e.g. in case of a custom build), storing metadata as well as 
user's IP address; 3. The user downloads a regular installation file and 
installs; 4. Once installed, the first thing the client does is contact 
boinc.berkeley.edu<http://boinc.berkeley.edu> to retrieve metadata and attach 
wherever needed (maybe even possible through the installer?). The server would 
load data based on the requester's IP address.


--
Pagarbiai / Sincerely
Rytis Slatkevičius
+370 670 7<tel:%2B370%20670%207>

On Fri, Sep 25, 2015 at 12:28 AM, Matthew Blumberg 
<m...@gridrepublic.org<mailto:m...@gridrepublic.org>> wrote:
I'm a little worried about the proposed approach; I fear it will notably reduce 
conversion-completion rates -- if i got an installer with a 120 character 
filename, i'd [a] edit to clean it up, and/or [b] assume it was corrupted or 
infected and be afraid to run it.

In any event, by way of making this work in the AMS context, can we request one 
minor revision to the current scheme --

In the current scheme, at completion of install, the wizard opens a browser 
window using the return_url specified in the browser cookie. Could you instead 
open a browser window upon completion, using the URL from acct_mgr_url.xml, and 
appending a random number as a parameter, e.g. 
http://acctmgr.com/?return_id=[nonce]<http://acctmgr.com/?return_id=%5bnonce%5d>

Best Wishes,

..Matt




On Mon, Sep 21, 2015 at 10:59 AM, Rom Walton 
<r...@romwnet.org<mailto:r...@romwnet.org>> wrote:
Howdy Folks,

Current Strategy:
https://boinc.berkeley.edu/trac/wiki/SimpleAttach

As part of the simplification process we (WCG and I) would like to propose the 
idea of cookieless installs.

See:
https://boinc.berkeley.edu/trac/wiki/SimpleAttach#CookielessInstalls

Pros:

We would be able to get ar

Re: [boinc_dev] winbuild

[Rom Walton]

Thanks for the pointer.  I'll see what I can do.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Juha
Sent: Tuesday, September 15, 2015 4:01 PM
To: BOINC Developers Mailing List 
Subject: [boinc_dev] winbuild

Hi

The dependency stores are rather large, 2 GB for vs2010 and 650 MB for vs2013. 
The size combined with the poor download rate of 100 kB/s makes cloning them 
take forever, five hours for vs2010.

Considering that there's unlikely much need for the old library versions one 
might try cloning only the HEAD of the repo. Unfortunately that doesn't
work:

git clone --depth 1
http://boinc.berkeley.edu/git/boinc_depends_win_vs2010.git
Cloning into 'boinc_depends_win_vs2010'...
fatal: dumb http transport does not support --depth

It wouldn't be much use for me any more but I'm sure the next person to think 
about hacking BOINC would appreciate if you supported Git's smart http 
transport.

-Juha
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_admin] When using HTTPS in image container tag, image doesn't show.

[Rom Walton]

I do believe that is a browser setting.

For instance, Internet Explorer has two different advanced settings dealing 
with warning/blocking mixed protocol content.

- Rom

From: boinc_ad...@googlegroups.com [mailto:boinc_ad...@googlegroups.com] On 
Behalf Of Jord van der Elst
Sent: Wednesday, September 02, 2015 5:42 AM
To: BOINC Dev Mailing List 
Cc: boinc_ad...@googlegroups.com
Subject: [boinc_admin] When using HTTPS in image container tag, image doesn't 
show.

Any images that use HTTPS in their URL do not show in the BOINC forums. The 
image URL needs HTTP at the moment to work correctly.

-- Jord van der Elst.
--
You received this message because you are subscribed to the Google Groups 
"boinc_admin" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
boinc_admin+unsubscr...@googlegroups.com.
To post to this group, send email to 
boinc_ad...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/boinc_admin/CAEXjb0eETQfkTJyoBG4tOr9ctDyCw%2BFGy2W8gm5_Z8ys2A14-A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_admin] When using HTTPS in image container tag, image doesn't show.

[Rom Walton]

What is the URL to that post?

- Rom

-Original Message-
From: boinc_ad...@googlegroups.com [mailto:boinc_ad...@googlegroups.com] On 
Behalf Of Richard Haselgrove
Sent: Wednesday, September 02, 2015 10:54 AM
To: Rom Walton <r...@romwnet.org>; Jord van der Elst <els...@gmail.com>; BOINC 
Dev Mailing List <boinc_dev@ssl.berkeley.edu>
Cc: boinc_ad...@googlegroups.com
Subject: Re: [boinc_dev] [boinc_admin] When using HTTPS in image container tag, 
image doesn't show.

I'm not sure it's as simple as that. Trying a few random image urls directly in 
my browser (Chrome) address bar, some rendered differently when accessed via 
HTTPS - e.g. protobucket switched to an html frame. But even when I found an 
image which rendered normally in https, and pasted the url into a message board 
post at a project I was accessing via https, it still just displayed the 
'broken image link' icon.



On Wednesday, 2 September 2015, 15:06, Rom Walton <r...@romwnet.org> wrote:


>
>
>I do believe that is a browser setting.
>
>For instance, Internet Explorer has two different advanced settings dealing 
>with warning/blocking mixed protocol content.
>
>- Rom
>
>From: boinc_ad...@googlegroups.com 
>[mailto:boinc_ad...@googlegroups.com] On Behalf Of Jord van der Elst
>Sent: Wednesday, September 02, 2015 5:42 AM
>To: BOINC Dev Mailing List <boinc_dev@ssl.berkeley.edu>
>Cc: boinc_ad...@googlegroups.com
>Subject: [boinc_admin] When using HTTPS in image container tag, image doesn't 
>show.
>
>Any images that use HTTPS in their URL do not show in the BOINC forums. The 
>image URL needs HTTP at the moment to work correctly.
>
>-- Jord van der Elst.
>--
>You received this message because you are subscribed to the Google Groups 
>"boinc_admin" group.
>To unsubscribe from this group and stop receiving emails from it, send an 
>email to 
>boinc_admin+unsubscr...@googlegroups.com<mailto:boinc_admin+unsubscr...@googlegroups.com>.
>To post to this group, send email to 
>boinc_ad...@googlegroups.com<mailto:boinc_ad...@googlegroups.com>.
>To view this discussion on the web visit 
>https://groups.google.com/d/msgid/boinc_admin/CAEXjb0eETQfkTJyoBG4tOr9ctDyCw%2BFGy2W8gm5_Z8ys2A14-A%40mail.gmail.com<https://groups.google.com/d/msgid/boinc_admin/CAEXjb0eETQfkTJyoBG4tOr9ctDyCw%2BFGy2W8gm5_Z8ys2A14-A%40mail.gmail.com?utm_medium=email_source=footer>.
>For more options, visit https://groups.google.com/d/optout.
>
>___
>boinc_dev mailing list
>boinc_dev@ssl.berkeley.edu
>http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
>To unsubscribe, visit the above URL and (near bottom of page) enter 
>your email address.
>
>
>

--
You received this message because you are subscribed to the Google Groups 
"boinc_admin" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to boinc_admin+unsubscr...@googlegroups.com.
To post to this group, send email to boinc_ad...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/boinc_admin/1999697702.553952.1441205636070.JavaMail.yahoo%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_admin] make Github repo the master?

[Rom Walton]

If your using the command line:
https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes

In TotoriseGit, it is under the settings when you right-click the repo.

- Rom

From: David Anderson [mailto:da...@ssl.berkeley.edu]
Sent: Monday, July 27, 2015 1:18 PM
To: Rom Walton r...@romwnet.org; Eric J Korpela korp...@ssl.berkeley.edu
Cc: boinc_ad...@googlegroups.com; BOINC Dev Mailing List 
boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_admin] make Github repo the master?

How do we do that?
-- David
On 27-Jul-2015 10:15 AM, Rom Walton wrote:
As of now, the authoritative BOINC repo is on github.

Please change your origin repo to point to github.

Thanks.

- Rom

From: Rom Walton
Sent: Thursday, July 23, 2015 11:30 AM
To: 'Eric J Korpela' 
korp...@ssl.berkeley.edumailto:korp...@ssl.berkeley.edu; David Anderson 
da...@ssl.berkeley.edumailto:da...@ssl.berkeley.edu
Cc: boinc_ad...@googlegroups.commailto:boinc_ad...@googlegroups.com; BOINC 
Dev Mailing List boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
Subject: RE: [boinc_admin] make Github repo the master?

I plan on doing the changeover on the 27th.

After the change, everybody should only need to change the git origin repo 
configuration to https://github.com/BOINC/boinc.git within their local repo.

- Rom

From: boinc_ad...@googlegroups.commailto:boinc_ad...@googlegroups.com 
[mailto:boinc_ad...@googlegroups.com] On Behalf Of Eric J Korpela
Sent: Wednesday, July 22, 2015 8:51 PM
To: David Anderson da...@ssl.berkeley.edumailto:da...@ssl.berkeley.edu
Cc: boinc_ad...@googlegroups.commailto:boinc_ad...@googlegroups.com
Subject: Re: [boinc_admin] make Github repo the master?

Be sure to give a shout out when this happens.

On Mon, Jul 20, 2015 at 10:00 PM, David Anderson 
da...@ssl.berkeley.edumailto:da...@ssl.berkeley.edu wrote:
I propose making the BOINC repo on Github the master repo
(rather than the one on the UCB server).

This will make it easier to control who has commit access,
and will make this info publicly visible.

Any objections or comments?
If not we'll do this in a couple of days.

-- David

--
You received this message because you are subscribed to the Google Groups 
boinc_admin group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
boinc_admin+unsubscr...@googlegroups.commailto:boinc_admin%2bunsubscr...@googlegroups.com.
To post to this group, send email to 
boinc_ad...@googlegroups.commailto:boinc_ad...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/boinc_admin/55ADD1DD.7020809%40ssl.berkeley.edu.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups 
boinc_admin group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
boinc_admin+unsubscr...@googlegroups.commailto:boinc_admin+unsubscr...@googlegroups.com.
To post to this group, send email to 
boinc_ad...@googlegroups.commailto:boinc_ad...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/boinc_admin/CAKFuvzbSNhTMGc5y7Ft-G-5T2MXrw_A4g-ZS3%3DUAPoGZkA9HLA%40mail.gmail.comhttps://groups.google.com/d/msgid/boinc_admin/CAKFuvzbSNhTMGc5y7Ft-G-5T2MXrw_A4g-ZS3%3DUAPoGZkA9HLA%40mail.gmail.com?utm_medium=emailutm_source=footer.
For more options, visit https://groups.google.com/d/optout.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_admin] make Github repo the master?

[Rom Walton]

Here is the URL you would use on github:
https://github.com/BOINC/boinc/commits/master
https://github.com/BOINC/boinc/commits/client_release/7/7.6

- Rom

-Original Message-
From: Jord van der Elst [mailto:els...@gmail.com] 
Sent: Monday, July 27, 2015 1:28 PM
To: David Anderson da...@ssl.berkeley.edu
Cc: Rom Walton r...@romwnet.org; BOINC Dev Mailing List 
boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] [boinc_admin] make Github repo the master?

The only other question is, where have these gone to?

https://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=log
https://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=log;h=refs/heads/client_release/7/7.6

At least not to, e.g.
https://github.com/BOINC/gitweb/?p=boinc.git;a=log;h=refs/heads/client_release/7/7.6

-- Jord van der Elst.


On Mon, Jul 27, 2015 at 7:23 PM, Jord van der Elst els...@gmail.com wrote:
 I did it like this for the GUI:
 Right click on my local repository, Git-Pull In the window that opens, 
 click Manage remotes.
 Either add BOINC as a remote, or change the URL from what it was to 
 https://github.com/BOINC/boinc.git
 Click Apply.
 Next in the Git Pull window, choose BOINC, check that the branch is 
 still correct, then click OK.


 -- Jord van der Elst.


 On Mon, Jul 27, 2015 at 7:17 PM, David Anderson da...@ssl.berkeley.edu 
 wrote:
 How do we do that?
 -- David

 On 27-Jul-2015 10:15 AM, Rom Walton wrote:


 As of now, the authoritative BOINC repo is on github.

 Please change your origin repo to point to github.

 Thanks.

 - Rom

 *From:*Rom Walton
 *Sent:* Thursday, July 23, 2015 11:30 AM
 *To:* 'Eric J Korpela' korp...@ssl.berkeley.edu; David Anderson 
 da...@ssl.berkeley.edu
 *Cc:* boinc_ad...@googlegroups.com; BOINC Dev Mailing List 
 boinc_dev@ssl.berkeley.edu
 *Subject:* RE: [boinc_admin] make Github repo the master?

 I plan on doing the changeover on the 27^th .

 After the change, everybody should only need to change the git 
 origin repo configuration to https://github.com/BOINC/boinc.git within 
 their local repo.

 - Rom

 *From:*boinc_ad...@googlegroups.com 
 mailto:boinc_ad...@googlegroups.com
 [mailto:boinc_ad...@googlegroups.com] *On Behalf Of *Eric J Korpela
 *Sent:* Wednesday, July 22, 2015 8:51 PM
 *To:* David Anderson da...@ssl.berkeley.edu 
 mailto:da...@ssl.berkeley.edu
 *Cc:* boinc_ad...@googlegroups.com 
 mailto:boinc_ad...@googlegroups.com
 *Subject:* Re: [boinc_admin] make Github repo the master?

 Be sure to give a shout out when this happens.

 On Mon, Jul 20, 2015 at 10:00 PM, David Anderson 
 da...@ssl.berkeley.edu mailto:da...@ssl.berkeley.edu wrote:

 I propose making the BOINC repo on Github the master repo
 (rather than the one on the UCB server).

 This will make it easier to control who has commit access,
 and will make this info publicly visible.

 Any objections or comments?
 If not we'll do this in a couple of days.

 -- David

 -- You received this message because you are subscribed to the
 Google Groups
 boinc_admin group.
 To unsubscribe from this group and stop receiving emails from 
 it, send an
 email to boinc_admin+unsubscr...@googlegroups.com
 mailto:boinc_admin%2bunsubscr...@googlegroups.com.
 To post to this group, send email to boinc_ad...@googlegroups.com
 mailto:boinc_ad...@googlegroups.com.
 To view this discussion on the web visit

 https://groups.google.com/d/msgid/boinc_admin/55ADD1DD.7020809%40ssl.berkeley.edu.
 For more options, visit https://groups.google.com/d/optout
 https://groups.google.com/d/optout.

 --
 You received this message because you are subscribed to the Google 
 Groups boinc_admin group.
 To unsubscribe from this group and stop receiving emails from it, 
 send an email to boinc_admin+unsubscr...@googlegroups.com
 mailto:boinc_admin+unsubscr...@googlegroups.com.
 To post to this group, send email to boinc_ad...@googlegroups.com 
 mailto:boinc_ad...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/boinc_admin/CAKFuvzbSNhTMGc5y7Ft-G
 -5T2MXrw_A4g-ZS3%3DUAPoGZkA9HLA%40mail.gmail.com
 https://groups.google.com/d/msgid/boinc_admin/CAKFuvzbSNhTMGc5y7Ft-G-5T2MXrw_A4g-ZS3%3DUAPoGZkA9HLA%40mail.gmail.com?utm_medium=emailutm_source=footer.
 For more options, visit https://groups.google.com/d/optout.


 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev

 To unsubscribe, visit the above URL and (near bottom of page) enter 
 your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_admin] make Github repo the master?

[Rom Walton]

I’ve updated the wiki page and added the boinc-lite/boinc-scenarios repos to 
github.

I’ve held off on adding the various boinc_depends_* repos, they are too big for 
github.

- Rom

From: Richard Haselgrove [mailto:r.haselgr...@btopenworld.com]
Sent: Monday, July 27, 2015 3:27 PM
To: Rom Walton r...@romwnet.org; Jord van der Elst els...@gmail.com; David 
Anderson da...@ssl.berkeley.edu
Cc: BOINC Dev Mailing List boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] [boinc_admin] make Github repo the master?

I think we need some consequential changes on 
http://boinc.berkeley.edu/trac/wiki/SourceCodeGit - which is linked directly 
from the from the front page. In particular, the link in the very first bullet 
point no longer contains the actual source code - I presume all these various 
sundry sub-gits will be migrated in due course.


On Monday, 27 July 2015, 18:32, Rom Walton 
r...@romwnet.orgmailto:r...@romwnet.org wrote:

Here is the URL you would use on github:
https://github.com/BOINC/boinc/commits/master
https://github.com/BOINC/boinc/commits/client_release/7/7.6

- Rom

-Original Message-
From: Jord van der Elst [mailto:els...@gmail.commailto:els...@gmail.com]
Sent: Monday, July 27, 2015 1:28 PM
To: David Anderson da...@ssl.berkeley.edumailto:da...@ssl.berkeley.edu
Cc: Rom Walton r...@romwnet.orgmailto:r...@romwnet.org; BOINC Dev Mailing 
List boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] [boinc_admin] make Github repo the master?

The only other question is, where have these gone to?

https://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=log
https://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=log;h=refs/heads/client_release/7/7.6

At least not to, e.g.
https://github.com/BOINC/gitweb/?p=boinc.git;a=log;h=refs/heads/client_release/7/7.6

-- Jord van der Elst.


On Mon, Jul 27, 2015 at 7:23 PM, Jord van der Elst 
els...@gmail.commailto:els...@gmail.com wrote:
 I did it like this for the GUI:
 Right click on my local repository, Git-Pull In the window that opens,
 click Manage remotes.
 Either add BOINC as a remote, or change the URL from what it was to
 https://github.com/BOINC/boinc.git
 Click Apply.
 Next in the Git Pull window, choose BOINC, check that the branch is
 still correct, then click OK.


 -- Jord van der Elst.


 On Mon, Jul 27, 2015 at 7:17 PM, David Anderson 
 da...@ssl.berkeley.edumailto:da...@ssl.berkeley.edu wrote:
 How do we do that?
 -- David

 On 27-Jul-2015 10:15 AM, Rom Walton wrote:


 As of now, the authoritative BOINC repo is on github.

 Please change your origin repo to point to github.

 Thanks.

 - Rom

 *From:*Rom Walton
 *Sent:* Thursday, July 23, 2015 11:30 AM
 *To:* 'Eric J Korpela' 
 korp...@ssl.berkeley.edumailto:korp...@ssl.berkeley.edu; David Anderson
 da...@ssl.berkeley.edumailto:da...@ssl.berkeley.edu
 *Cc:* boinc_ad...@googlegroups.commailto:boinc_ad...@googlegroups.com; 
 BOINC Dev Mailing List
 boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
 *Subject:* RE: [boinc_admin] make Github repo the master?

 I plan on doing the changeover on the 27^th .

 After the change, everybody should only need to change the git
 origin repo configuration to https://github.com/BOINC/boinc.git within 
 their local repo.

 - Rom

 *From:*boinc_ad...@googlegroups.commailto:boinc_ad...@googlegroups.com
 mailto:boinc_ad...@googlegroups.commailto:boinc_ad...@googlegroups.com
 [mailto:boinc_ad...@googlegroups.commailto:boinc_ad...@googlegroups.com] 
 *On Behalf Of *Eric J Korpela
 *Sent:* Wednesday, July 22, 2015 8:51 PM
 *To:* David Anderson da...@ssl.berkeley.edumailto:da...@ssl.berkeley.edu
 mailto:da...@ssl.berkeley.edumailto:da...@ssl.berkeley.edu
 *Cc:* boinc_ad...@googlegroups.commailto:boinc_ad...@googlegroups.com
 mailto:boinc_ad...@googlegroups.commailto:boinc_ad...@googlegroups.com
 *Subject:* Re: [boinc_admin] make Github repo the master?

 Be sure to give a shout out when this happens.

 On Mon, Jul 20, 2015 at 10:00 PM, David Anderson
 da...@ssl.berkeley.edumailto:da...@ssl.berkeley.edu 
 mailto:da...@ssl.berkeley.edumailto:da...@ssl.berkeley.edu wrote:

I propose making the BOINC repo on Github the master repo
(rather than the one on the UCB server).

This will make it easier to control who has commit access,
and will make this info publicly visible.

Any objections or comments?
If not we'll do this in a couple of days.

-- David

--You received this message because you are subscribed to the
 Google Groups
boinc_admin group.
To unsubscribe from this group and stop receiving emails from
 it, send an
email to 
 boinc_admin+unsubscr...@googlegroups.commailto:unsubscr...@googlegroups.com

 mailto:boinc_admin%2bunsubscr...@googlegroups.commailto:2bunsubscr...@googlegroups.com.
To post to this group, send email to 
 boinc_ad...@googlegroups.commailto:boinc_ad...@googlegroups.com

 mailto:boinc_ad...@googlegroups.commailto:boinc_ad

Re: [boinc_dev] [boinc_admin] make Github repo the master?

[Rom Walton]

Is this what you are looking for?

https://github.com/BOINC/boinc/commits/master

- Rom

From: boinc_ad...@googlegroups.com [mailto:boinc_ad...@googlegroups.com] On 
Behalf Of Richard Haselgrove
Sent: Monday, July 27, 2015 7:02 PM
To: Rom Walton r...@romwnet.org; Nicolás Alvarez nicolas.alva...@gmail.com
Cc: boinc_ad...@googlegroups.com; BOINC Dev Mailing List 
boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] [boinc_admin] make Github repo the master?

Does anyone know whether it's possible to display the Github web interface in 
most recent change first order? (so far, I've failed). For active developers, 
you know which area of code you'll be working in. But for users and amateur 
bughunters, the question is what areas of code have changed recently - have 
they fixed the problem I've reported, or where might the next glitch show up 
and need testing?


On Monday, 27 July 2015, 22:58, Rom Walton 
r...@romwnet.orgmailto:r...@romwnet.org wrote:

Even better.

- Rom

-Original Message-
From: Nicolás Alvarez 
[mailto:nicolas.alva...@gmail.commailto:nicolas.alva...@gmail.com]
Sent: Monday, July 27, 2015 5:21 PM
To: Rom Walton r...@romwnet.orgmailto:r...@romwnet.org
Cc: boinc_ad...@googlegroups.commailto:boinc_ad...@googlegroups.com; BOINC 
Dev Mailing List boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] [boinc_admin] make Github repo the master?

2015-07-27 18:17 GMT-03:00 Rom Walton 
r...@romwnet.orgmailto:r...@romwnet.org:
 The git (cli) commands to redirect origin to the github site are:
 git remote rm origin
 git remote add origin https://github.com/BOINC/boinc

 - Rom

git remote set-url origin https://github.com/BOINC/boinc

--
Nicolás
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

--
You received this message because you are subscribed to the Google Groups 
boinc_admin group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
boinc_admin+unsubscr...@googlegroups.commailto:boinc_admin+unsubscr...@googlegroups.com.
To post to this group, send email to 
boinc_ad...@googlegroups.commailto:boinc_ad...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/boinc_admin/283284114.3739869.1438038127572.JavaMail.yahoo%40mail.yahoo.comhttps://groups.google.com/d/msgid/boinc_admin/283284114.3739869.1438038127572.JavaMail.yahoo%40mail.yahoo.com?utm_medium=emailutm_source=footer.
For more options, visit https://groups.google.com/d/optout.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Boinc for Arm on Linux doesn't report the CPU model, only the vendor.

[Rom Walton]

I've backported the fix to the 7.2, 7.4, and 7.6 branches.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Christian Beer
Sent: Tuesday, July 21, 2015 5:43 AM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Boinc for Arm on Linux doesn't report the CPU model, 
only the vendor.

Debian stable (Jessy) is on 7.4 old-stable (wheezy) is on 7.0 but 7.4 is 
available through wheezy-backports.

Ubuntu Trusty (14.04LTS) is on 7.2 but the latest 7.2 is only available through 
trusty-backports. Ubuntu Utopic (14.10) is on 7.4.8 with no newer version in 
backports. Ubuntu Vivid (15.04) is on 7.4.23.

So it seems backporting to at least 7.2 is necessary to get the fix into Ubuntu 
14.04LTS backports.

OpenSuse, Fedora and CentOS6 seem to be on 7.2.42 for newer versions and 7.0.x 
for older versions.

Gianfranco is maintaining the Debian based packages, I don't know who is doing 
RPM packaging for CentOS and OpenSuse.

MfG / Regards
Christian Beer

Am 20.07.2015 um 23:09 schrieb David Anderson:
 What version are the package maintainers using?
 Hopefully patching 7.4 would suffice.
 -- David

 On 20-Jul-2015 1:20 PM, Stephen Maclagan wrote:
 I've patched my local 7.2 head and recompiled Boinc 7.2.47, and it
 works:

 http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=7413
 8

 Mon 20 Jul 2015 20:13:07 UTC |  | Starting BOINC client version
 7.2.47 for armv7l-unknown-linux-gnueabihf Mon 20 Jul 2015 20:13:07 
 UTC |  | log flags: file_xfer, sched_ops, task, sched_op_debug Mon 20 
 Jul 2015 20:13:07 UTC |  | Libraries: libcurl/7.26.0 OpenSSL/1.0.1e 
 zlib/1.2.7 libidn/1.25 libssh2/1.4.2 librtmp/2.3 Mon 20 Jul 2015 
 20:13:07 UTC |  | Data directory: /home/pi/BOINC Mon 20 Jul 2015 
 20:13:07 UTC |  | No usable GPUs found Mon 20 Jul 2015 20:13:07 UTC | 
 SETI@home | Found app_info.xml; using anonymous platform Mon 20 Jul 
 2015 20:13:07 UTC |  | Host name: raspberrypi Mon 20 Jul 2015 
 20:13:07 UTC |  | Processor: 4 ARM ARMv7 Processor rev 5 (v7l) Mon 20 
 Jul 2015 20:13:07 UTC |  | Processor features: half thumb fastmult 
 vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm Mon 20 
 Jul 2015 20:13:07 UTC |  | OS: Linux: 4.0.8-v7+ Mon 20 Jul 2015 
 20:13:07 UTC |  | Memory: 926.03 MB physical, 100.00 MB virtual Mon 
 20 Jul 2015 20:13:07 UTC |  | Disk: 14.48 GB total, 8.42 GB free Mon 
 20 Jul 2015 20:13:07 UTC |  | Local time is UTC +0 hours Mon 20 Jul 
 2015 20:13:07 UTC | Albert@Home | URL http://albert.phys.uwm.edu/; 
 Computer ID 12650; resource share 100 Mon 20 Jul 2015 20:13:07 UTC | 
 SETI@home Beta Test | URL http://setiweb.ssl.berkeley.edu/beta/; 
 Computer ID 74138; resource share 100 Mon 20 Jul 2015 20:13:07 UTC | 
 Einstein@Home | URL http://einstein.phys.uwm.edu/; Computer ID 
 11741356; resource share 100 Mon 20 Jul 2015 20:13:07 UTC | SETI@home 
 | URL http://setiathome.berkeley.edu/; Computer ID 7495179; resource 
 share 100 Mon 20 Jul 2015 20:13:07 UTC | SETI@home | General prefs: 
 from SETI@home (last modified 02-Feb-2015 14:45:48)


 Any chance of it being packported to the 7.0, 7.2, 7.4 and 7.6 heads 
 please, then at least the repository builds have a small chance of 
 getting updated.

 Claggy

 -
 ---

 Date: Sun, 19 Jul 2015 12:50:58 -0700
 From: da...@ssl.berkeley.edu
 To: stephen.macla...@hotmail.com; boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] Boinc for Arm on Linux doesn't report the 
 CPU model, only the vendor.

 Stephen:
 Thanks.  It looks like the /proc/cpuinfo format changed at some 
 point, and we weren't parsing the model name correctly for ARM.

 I checked in changes that will parse the /proc/cpuinfo examples you 
 sent.
 Hopefully this will also work on recent Android.

 Rom, can you please test this on whatever Android devices you have?

 -- David

 On 19-Jul-2015 10:36 AM, Stephen Maclagan wrote:

 On my Quad Core Raspberry Pi running Raspbian Wheezy:

 pi@raspberrypi ~ $ cat /proc/cpuinfo
 processor: 0
 model name: ARMv7 Processor rev 5 (v7l)
 BogoMIPS: 57.60
 Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva 
 idivt vfpd32
 lpae evtstrm
 CPU implementer: 0x41
 CPU architecture: 7
 CPU variant: 0x0
 CPU part: 0xc07
 CPU revision: 5

 processor: 1
 model name: ARMv7 Processor rev 5 (v7l)
 BogoMIPS: 57.60
 Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva 
 idivt vfpd32
 lpae evtstrm
 CPU implementer: 0x41
 CPU architecture: 7
 CPU variant: 0x0
 CPU part: 0xc07
 CPU revision: 5

 processor: 2
 model name: ARMv7 Processor rev 5 (v7l)
 BogoMIPS: 57.60
 Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva 
 idivt vfpd32
 lpae evtstrm
 CPU implementer: 0x41
 CPU architecture: 7
 CPU variant: 0x0
 CPU part: 0xc07
 CPU revision: 5

 

Re: [boinc_dev] is there a way to persist files on the host

[Rom Walton]

Vboxwrapper.cpp:673 would be the place you would want to start with any local 
changes.

I think we wanted to go one step further when removing the copy_file/ flag 
and also mark the VDI as immutable.  That would cause VirtualBox to create a 
differencing disk in the local slot directory and avoid the disk image copy 
operation to the slot directory.

Doing so will probably lead to some bigger changes though.

- Rom

From: Marius Millea [mailto:mmil...@ucdavis.edu]
Sent: Monday, June 29, 2015 1:30 AM
To: Rom Walton r...@romwnet.org; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] is there a way to persist files on the host

Hi Rom,

I saw your commits regarding the scratch directory. Thanks for the amazingly 
quick response!

Unfortunately, I now realize its not going to work out as I initially imaged it 
(see this 
discussionhttps://forums.docker.com/t/how-does-boot2docker-persistence-work/2077
 with one of the boot2docker guys). Basically, the docker directory can't be on 
a VBox shared folder due to insufficiencies of vboxfs.

I should have realized that the correct way to do this is via boot2docker's 
normal way of persistence, which just uses a VDI disk. Essentially a persistent 
VDI would live in the BOINC project/ directory, and vboxwrapper would attach 
that same one each time to the VM (meaning you can only have 1 of these kinds 
of tasks running at a time, granted that was always the case without properly 
installing the docker client on each host). This is in fact almost exactly what 
the wrapper currently does. The only change needed would be to allow 
vm_cache.vdi to not have copy_file/ and to have vboxwrapper correctly follow 
this link (I don't think it currently does). I'm wondering what you think about 
possibly adding an option to do that? I feel bad having you take the time for 
this other scratch directory feature which was not really needed by me (I think 
it might still be useful to some anyway), plus I acknowledge I don't know what 
other road blocks I might hit. If you wanted to just poi
 nt me to where I might make this change myself, I'm happy to do it.

In any case, I had been hoping I could avoid changes to vboxwrapper so that I 
could have the convenience of using the precompiled versions you guys put up. 
Since that doesn't look like its going to be possible, is there any help you 
could give me on cross compiling? What does your setup look like? (I've never 
done this before)

Thanks,

Marius


On Thu, Jun 25, 2015 at 4:40 PM, Marius Millea 
mmil...@ucdavis.edumailto:mmil...@ucdavis.edu wrote:
Thanks for the interest. Thus far just Linux, although a Windows machine is 
waiting once any of this kind of works. The way I currently envisage it (which 
could well change), there would be no forking vboxwrapper required. Basically I 
modified the boot2docker ISO to act as multi purpose app (in the language of 
http://boinc.berkeley.edu/trac/wiki/VboxApps) so on boot it mounts shared/ and 
from there runs some boinc_app script. That script then calls docker run... 
etc.. so its all happening inside the VM, the host system never needs to 
interact directly with the docker daemon. It could certainly be done other ways 
too though.

And agreed, the boot image size is very enticing. There is also the size of the 
docker image that gets run, but there are decent to good base images in the 
5-100Mb range, and with this persistence thing working it would be a one time 
download (and thank's to Docker, if you're running different images all based 
on the same base image, you only download the changes).

Marius

On Thu, Jun 25, 2015 at 4:18 PM, Rom Walton 
r...@romwnet.orgmailto:r...@romwnet.org wrote:
Marius,

What host platform are you testing against?

- Rom

-Original Message-
From: boinc_dev 
[mailto:boinc_dev-boun...@ssl.berkeley.edumailto:boinc_dev-boun...@ssl.berkeley.edu]
 On Behalf Of Rom Walton
Sent: Thursday, June 25, 2015 5:43 PM
To: Marius Millea mmil...@ucdavis.edumailto:mmil...@ucdavis.edu
Cc: boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] is there a way to persist files on the host

Well, that is an interesting idea.

Ultimately I think there will need to be a fork of vboxwrapper that knows how 
to handle the docker daemon as well as VirtualBox.

A 27MB boot image is pretty enticing.

- Rom

From: Marius Millea [mailto:mmil...@ucdavis.edumailto:mmil...@ucdavis.edu]
Sent: Thursday, June 25, 2015 4:43 PM
To: Rom Walton r...@romwnet.orgmailto:r...@romwnet.org
Cc: boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] is there a way to persist files on the host

Yea sorry ambiguous what I meant by host there. The idea is that BOINC clients 
are running VBoxwrapper which loads up boot2docker inside of which I run my 
Docker apps.

Marius

On Thu, Jun 25, 2015 at 1:38 PM, Rom Walton 
r...@romwnet.orgmailto:r...@romwnet.orgmailto:r...@romwnet.orgmailto:r...@romwnet.org
 wrote:
Hosts

Re: [boinc_dev] is there a way to persist files on the host

[Rom Walton]

Hosts or guests?

Using VirtualBox implies that your docker application would be running within a 
Linux guest.

- Rom

From: Marius Millea [mailto:mmil...@ucdavis.edu]
Sent: Thursday, June 25, 2015 4:10 PM
To: Rom Walton r...@romwnet.org
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] is there a way to persist files on the host

Hi Rom,

Yea, I think that's exactly what I'd need. I had started looking at the source 
for vboxwrapper, but if that's something you could add officially to BOINC then 
that'd be amazing, thanks!

My end goal btw is to have hosts running Docker, and this would allow 
persisting images between tasks. We'll see if there's any other road blocks...

Marius





On Thu, Jun 25, 2015 at 12:25 PM, Rom Walton 
r...@romwnet.orgmailto:r...@romwnet.org wrote:
I can add another shared directory that points to a scratch area in the 
project's directory.

Would that work for you?

- Rom

-Original Message-
From: boinc_dev 
[mailto:boinc_dev-boun...@ssl.berkeley.edumailto:boinc_dev-boun...@ssl.berkeley.edu]
 On Behalf Of Marius Millea
Sent: Thursday, June 25, 2015 2:27 PM
To: boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] is there a way to persist files on the host

(sorry if this screws up the threading, I can't figure out how to reply to a 
specific message given I receive only the digest?)


I see, that makes a lot of sense, thanks. I suppose a followup problem is that 
this is a VBox app, which AFAIK only gets access to the mounted shared/ folder. 
Is there any way around this?

Marius


The easiest way is to not tell BOINC about the file -
 just create it in the project directory, and look for it there in
 subsequent jobs.

 The app can get the project dir from the APP_INIT_DATA:
 http://boinc.berkeley.edu/trac/wiki/StatusApi

 -- David


 On 25-Jun-2015 2:10 AM, Marius Millea wrote:
  Suppose the result of a computation yields a large file which I
  would
 like
 
  1) to remain on host
  2) to be used in subsequent computations
  3) to not be uploaded
 
  I think I know how to do 1), if I have the file in the output
  template I can add the copy_file flag. Is there actually any way
  to do 2 or 3 though?
 
  Thanks,
 
  Marius
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] is there a way to persist files on the host

[Rom Walton]

I can add another shared directory that points to a scratch area in the 
project's directory.

Would that work for you?

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Marius 
Millea
Sent: Thursday, June 25, 2015 2:27 PM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] is there a way to persist files on the host

(sorry if this screws up the threading, I can't figure out how to reply to a 
specific message given I receive only the digest?)


I see, that makes a lot of sense, thanks. I suppose a followup problem is that 
this is a VBox app, which AFAIK only gets access to the mounted shared/ folder. 
Is there any way around this?

Marius


The easiest way is to not tell BOINC about the file -
 just create it in the project directory, and look for it there in 
 subsequent jobs.

 The app can get the project dir from the APP_INIT_DATA:
 http://boinc.berkeley.edu/trac/wiki/StatusApi

 -- David


 On 25-Jun-2015 2:10 AM, Marius Millea wrote:
  Suppose the result of a computation yields a large file which I 
  would
 like
 
  1) to remain on host
  2) to be used in subsequent computations
  3) to not be uploaded
 
  I think I know how to do 1), if I have the file in the output 
  template I can add the copy_file flag. Is there actually any way 
  to do 2 or 3 though?
 
  Thanks,
 
  Marius
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] is there a way to persist files on the host

[Rom Walton]

Well, that is an interesting.

Ultimately I think there will need to be a fork of vboxwrapper that knows how 
to handle the docker daemon as well as VirtualBox.

A 27MB boot image is pretty enticing.

- Rom

From: Marius Millea [mailto:mmil...@ucdavis.edu]
Sent: Thursday, June 25, 2015 4:43 PM
To: Rom Walton r...@romwnet.org
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] is there a way to persist files on the host

Yea sorry ambiguous what I meant by host there. The idea is that BOINC clients 
are running VBoxwrapper which loads up boot2docker inside of which I run my 
Docker apps.

Marius

On Thu, Jun 25, 2015 at 1:38 PM, Rom Walton 
r...@romwnet.orgmailto:r...@romwnet.org wrote:
Hosts or guests?

Using VirtualBox implies that your docker application would be running within a 
Linux guest.

- Rom

From: Marius Millea [mailto:mmil...@ucdavis.edumailto:mmil...@ucdavis.edu]
Sent: Thursday, June 25, 2015 4:10 PM
To: Rom Walton r...@romwnet.orgmailto:r...@romwnet.org
Cc: boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu

Subject: Re: [boinc_dev] is there a way to persist files on the host

Hi Rom,

Yea, I think that's exactly what I'd need. I had started looking at the source 
for vboxwrapper, but if that's something you could add officially to BOINC then 
that'd be amazing, thanks!

My end goal btw is to have hosts running Docker, and this would allow 
persisting images between tasks. We'll see if there's any other road blocks...

Marius





On Thu, Jun 25, 2015 at 12:25 PM, Rom Walton 
r...@romwnet.orgmailto:r...@romwnet.org wrote:
I can add another shared directory that points to a scratch area in the 
project's directory.

Would that work for you?

- Rom

-Original Message-
From: boinc_dev 
[mailto:boinc_dev-boun...@ssl.berkeley.edumailto:boinc_dev-boun...@ssl.berkeley.edu]
 On Behalf Of Marius Millea
Sent: Thursday, June 25, 2015 2:27 PM
To: boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] is there a way to persist files on the host

(sorry if this screws up the threading, I can't figure out how to reply to a 
specific message given I receive only the digest?)


I see, that makes a lot of sense, thanks. I suppose a followup problem is that 
this is a VBox app, which AFAIK only gets access to the mounted shared/ folder. 
Is there any way around this?

Marius


The easiest way is to not tell BOINC about the file -
 just create it in the project directory, and look for it there in
 subsequent jobs.

 The app can get the project dir from the APP_INIT_DATA:
 http://boinc.berkeley.edu/trac/wiki/StatusApi

 -- David


 On 25-Jun-2015 2:10 AM, Marius Millea wrote:
  Suppose the result of a computation yields a large file which I
  would
 like
 
  1) to remain on host
  2) to be used in subsequent computations
  3) to not be uploaded
 
  I think I know how to do 1), if I have the file in the output
  template I can add the copy_file flag. Is there actually any way
  to do 2 or 3 though?
 
  Thanks,
 
  Marius
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edumailto:boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_alpha] BOINC re-using slot directories without ensuring they're empty

[Rom Walton]

Here is a private drop:
http://boinc.berkeley.edu/dl/boinc.100615.x64.zip

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Richard Haselgrove
Sent: Wednesday, June 10, 2015 3:34 AM
To: David Anderson; Jacob Klein; Seke Rob
Cc: BOINC Development
Subject: Re: [boinc_dev] [boinc_alpha] BOINC re-using slot directories without 
ensuring they're empty

Rom, if you could build a private drop, I'll report what the log says. 


 On Wednesday, 10 June 2015, 4:28, David Anderson da...@ssl.berkeley.edu 
wrote:
   
 

  I added a log message that may help a bit.
 I'd like to track this down, even though it's minor.
 -- David
 
 On 19-May-2015 12:15 PM, Richard Haselgrove wrote:
  
  OK, the delay happened again, and I captured a procmon log. 
  Copy of the BOINC log attached (period of interest is 19:35:30 to 19:35:41): 
also a simple extract of ProcMon for the same period. It has to be said, 
boinc.exe was doing surprisingly little. 
  I have kept the full ~200 MB native ProcMon log, which can be re-filtered to 
look for anything else of interest, if you can suggest some likely targets. 
 
 
   On Monday, 18 May 2015, 20:57, David Anderson da...@ssl.berkeley.edu 
wrote:
   
 
 
 That looks like what's needed.
 Richard, if you can repro the inter-job delay,  you could try using Process 
Monitor to capture as much  as possible from the client during that period.
 -- David
 
 On 18-May-2015 11:12 AM, Jacob Klein wrote:
  Process Monitor can be used to watch the things a process does (you have 
  to set   up correct filters, etc.)... but I'm not sure if that includes 
  sleeps. But if the   process is waiting on a file or something, though, it 
  should be able to tell you. 
  Worth looking into.
 
  https://technet.microsoft.com/en-us/library/bb896645.aspx
 
  Regards,
  Jacob
 
 
 
  Date: Mon, 18 May 2015 10:41:16 -0700   From: da...@ssl.berkeley.edu   To: 
  r.haselgr...@btopenworld.com; onec...@hotmail.com; jacob_w_kl...@msn.com   
  CC: boinc_dev@ssl.berkeley.edu   Subject: Re: [boinc_dev] [boinc_alpha] 
  BOINC re-using slot directories without   ensuring they're empty I 
  looked at this and couldn't figure out the source of the 12-sec delay.
  In general, delays could happen because   1) the client does something that 
  takes a long time (like copying a 5 GB file)   2) the client sleeps (i.e. 
  calls boinc_sleep()).
     It does this in a few situations,
     like backing off and retrying a file system operation.
  But there's no indication that either of these is happening here.
 
  Does Windows have a way of logging the system calls that a process makes   
  (like strace on Unix)?
  If so that might reveal what the client is doing during those 12 seconds.
 
  -- David
 
  On 16-May-2015 8:01 AM, Richard Haselgrove wrote:
 
     Here is the message log file for a GPUGrid task finish. The 12-second 
 delay      appears again between 14:26:35 and 14:26:47 - that's after the 
 slot directory      has been cleared, and the exiting task has changed state 
 from 'running' to      'uploading'. Two new tasks have been assigned to the 
 GPU, but their (small)      startup files have not yet been linked to their 
 respective slot directories.
 
     I also attach directory listings for the slot and GPUGrid project folders 
 at      various stages of the cleanup: the slot held 34 files totalling 
 44,186,727      bytes, which doesn't sound excessive: the largest file 
 deletion (94,783,960      bytes) occurred several minutes later, when that 
 file finished uploading.
 
     I'll enable similar logging and watch what happens when the next GPUGrid 
 task      starts up, but from memory, the disruption to BOINC is less severe 
 at startup.
 
 
 
     On Tuesday, 12 May 2015, 23:29, David Anderson da...@ssl.berkeley.edu  
     mailto:da...@ssl.berkeley.edu wrote:
 
 
 
         BTW: the client isn't completely single-threaded;          it uses a 
 separate thread to do CPU throttling.
         It would be feasible to also use separate threads          for 
 serving GUI RPC connections,          which would allow client to remain 
 responsive even while          e.g. copying thousands of files to a slot dir.
         -- David
 
         On 12-May-2015 2:40 AM, Seke Rob wrote:
          Reminds me of the Clean Energy Project, Phase 2 and why we have    
       app_config and           max_concurrent and a default control of 
 allowing 1 'In Progress' on a          host. This           project sets 
 up in slot copying near 6700 files [symlinking proposed          long ago as 
           is done on several other WCG projects for the static files]. If 
 more          than one CEP2           is started the machine feels at 
 times like a snail, responsiveness of          the BOINC           manager 
 is poor, many a time the less powerful systems incurring error         

Re: [boinc_dev] [boinc_alpha] BOINC re-using slot directories without ensuring they're empty

[Rom Walton]

The 12-second delay might be related to DNS name resolution.

On Windows, we disabled async name resolution in libcurl because of random 
crashes in the async code.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Jacob 
Klein
Sent: Monday, May 18, 2015 2:12 PM
To: David Anderson; Richard Haselgrove; Seke Rob
Cc: BOINC Development
Subject: Re: [boinc_dev] [boinc_alpha] BOINC re-using slot directories without 
ensuring they're empty

Process Monitor can be used to watch the things a process does (you have to 
set up correct filters, etc.)... but I'm not sure if that includes sleeps. But 
if the process is waiting on a file or something, though, it should be able to 
tell you. Worth looking into.

https://technet.microsoft.com/en-us/library/bb896645.aspx

Regards,
Jacob
Date: Mon, 18 May 2015 10:41:16 -0700
From: da...@ssl.berkeley.edu
To: r.haselgr...@btopenworld.com; onec...@hotmail.com; jacob_w_kl...@msn.com
CC: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] [boinc_alpha] BOINC re-using slot directories without 
ensuring they're empty


  

  
  
I looked at this and couldn't figure out the source of the 12-sec
  delay.

  In general, delays could happen because

  1) the client does something that takes a long time (like copying
  a 5 GB file)

  2) the client sleeps (i.e. calls boinc_sleep()).

 It does this in a few situations,

 like backing off and retrying a file system operation.

  But there's no indication that either of these is happening here.

  

  Does Windows have a way of logging the system calls that a process
  makes

  (like strace on Unix)?

  If so that might reveal what the client is doing during those 12
  seconds.

  

  -- David



On 16-May-2015 8:01 AM, Richard
  Haselgrove wrote:



  
Here is the message
log file for a GPUGrid task finish. The 12-second delay
appears again between 14:26:35 and 14:26:47 - that's after
the slot directory has been cleared, and the exiting task
has changed state from 'running' to 'uploading'. Two new
tasks have been assigned to the GPU, but their (small)
startup files have not yet been linked to their respective
slot directories.


  
I also attach
directory listings for the slot and GPUGrid project folders
at various stages of the cleanup: the slot held 34 files
totalling 44,186,727 bytes, which doesn't sound excessive:
the largest file deletion (94,783,960 bytes) occurred
several minutes later, when that file finished uploading.


  
I'll enable similar
logging and watch what happens when the next GPUGrid task
starts up, but from memory, the disruption to BOINC is less
severe at startup. 




  



  

On Tuesday,
  12 May 2015, 23:29, David Anderson
  da...@ssl.berkeley.edu wrote:

 
   



BTW: the client isn't
  completely single-threaded;
  it uses a separate thread to do CPU throttling.
  It would be feasible to also use separate threads
  for serving GUI RPC connections,
  which would allow client to remain responsive even
  while
  e.g. copying thousands of files to a slot dir.
  -- David
  
  On 12-May-2015 2:40 AM, Seke Rob wrote:
   Reminds me of the Clean Energy Project, Phase 2
  and why we have app_config and 
   max_concurrent and a default control of
  allowing 1 'In Progress' on a host. This 
   project sets up in slot copying near 6700 files
  [symlinking proposed long ago as 
   is done on several other WCG projects for the
  static files]. If more than one CEP2 
   is started the machine feels at times like a
  snail, responsiveness of the BOINC 
   manager is poor, many a time the less powerful
  systems incurring error zero status 
   exits or total fail. On an 8 core observed it
  could take over an hour before 
   actual computing commenced [CPU time logged].
  Boot cycle requires manually 
   starting of tasks one by one. Kevin Reed few
  years ago raised a ticket for 
   staggered starting, where the models can reach
  several GB and bigger in the 
   coming. At any 

Re: [boinc_dev] OpenCL under MESA (Clover)

[Rom Walton]

In theory this should already work with BOINC 7.4 or better.

Give it a try, BOINC should report detecting the OpenCL GPU device.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Benji 
Wiebe
Sent: Monday, April 27, 2015 4:24 PM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] OpenCL under MESA (Clover)

Is there any plans to support Clover? I'm looking forward to being able to run 
Collatz on my GPU with only FOSS drivers. I might be interested in helping get 
it to work, too.

Thanks,

Benji
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

[boinc_dev] BOINC 7.4.42 released to public

[Rom Walton]

Howdy Folks,

A new version of BOINC is ready for public use.

Download: http://boinc.berkeley.edu/download.php
Release Notes: http://boinc.berkeley.edu/wiki/Release_Notes
Version History: http://boinc.berkeley.edu/trac/wiki/VersionHistory

Enjoy!

- Rom

Change Log:
* Update localizations 
* Screensaver fix for when the client is suspended 
* When using a proxy, fallback to HTTP 1.0 if the proxy returns a 417
status code. 
* Fixed Windows 10 detection (kernel version change)
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Boinc 7.4.42+ on Linux x64

[Rom Walton]

I just back-ported it.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
Stephen Maclagan
Sent: Wednesday, March 11, 2015 8:16 PM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] Boinc 7.4.42+ on Linux x64

I've built Boinc 7.4.42+ from the 7.4 head on my Ubuntu 14.04 host, the
following Bug is still present since this changeset hasn't been applied
to the 7.4 head:

http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=commit;h=4094edd1805b
4dd8fcba1dec5d1818698d54d168

Claggy
  
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] No information from BOINC or its data directory for aweek.

[Rom Walton]

U, BOINC's installer doesn't fiddle around with the firewalls rules.

BOINC does not create a network share to the data directory.  That must
be a left over from something else.

What is supposed to happen is when BOINC is first launched it starts all
the components that need access to 31416 in a test mode designed to
trigger the firewall's consent dialog.  It appears the firewall software
is being pretty liberal with its default rule set.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
Charles Elliott
Sent: Friday, February 13, 2015 3:15 PM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] No information from BOINC or its data directory for
aweek.

After a new version of BOINC is installed:

 

1.The BOINC data directory is inaccessible from any other
computer.
Deleting the share and re-sharing the directory has no impact.  A soln
that works is to give Everyone sufficient security privileges manually
using the directory properties dialog box.

2.   Boinccmds such as boinccmd -host remoteComputer
-get_host_info no
longer work as long as the firewall on the remote computer is active.
If two of the four incoming firewall rules that are marked in red,
specifically disallowing connections to BOINC, are changed to allow
connections, then boinccmd functions again.

3.   The firewall rules added by the BOINC installer allow access to
all
ports.  Why does any external program need access to BOINC thru any port
other than 31416?

 

Charles Elliott

 

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

[boinc_dev] BOINC/GitHub

[Rom Walton]

Howdy Folks,

Over the last few days we have migrated several BOINC services over to
GitHub.  We will be using GitHub to keep track of the BOINC Bug
database, project documentation, and have it be the primary mirror for
our source code repository.

Trac has been made read-only at this point.  Once we have fixed up the
wiki pages we should be able to shut it down.

In the not too distant future, I hope to use one of the GitHub
integrated services to replace Pootle.

Our presence on GitHub can be found here:
https://github.com/BOINC/boinc

- Rom
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] [boinc_alpha] BOINC/GitHub

[Rom Walton]

First mirror.

 

The primary repository, that we all push our commits to, is still on the BOINC 
server.

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Thursday, February 05, 2015 12:54 PM
To: Rom Walton
Cc: BOINC Developers Mailing List; Boinc_projects List; boinc_translations 
email List; BOINC Alpha
Subject: Re: [boinc_alpha] BOINC/GitHub

 

 

Please define primary mirror.  Does that mean primary repository or first 
mirror?

 

On Thu, Feb 5, 2015 at 9:27 AM, Rom Walton r...@romwnet.org wrote:

Howdy Folks,

Over the last few days we have migrated several BOINC services over to
GitHub.  We will be using GitHub to keep track of the BOINC Bug
database, project documentation, and have it be the primary mirror for
our source code repository.

Trac has been made read-only at this point.  Once we have fixed up the
wiki pages we should be able to shut it down.

In the not too distant future, I hope to use one of the GitHub
integrated services to replace Pootle.

Our presence on GitHub can be found here:
https://github.com/BOINC/boinc

- Rom
___
boinc_alpha mailing list
boinc_al...@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_alpha
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

 

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Official GitHub mirror?

[Rom Walton]

Okay, cool.

Let us make it official.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Christian Beer
Sent: Friday, January 09, 2015 5:56 AM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] Official GitHub mirror?

I fiddled a bit with travis-ci and got it up and running for my github fork.

See: https://github.com/ChristianBeer/boinc-v2/tree/travis-ci-test there is 
also a nice picture at the bottom of the page build information: 
https://travis-ci.org/ChristianBeer/boinc-v2

The current config just builds the components (libraries, server,
client+manager) and fails if the compiler reports an error. It just
monitors the travis-ci-test branch.

I would be willing to maintain the travis configuration. A possible roadmap for 
this could be:
- split up client and manager
- add a simple syntax test for php code
- add some more elaborate tests (it should even be possible to create a project 
inside the VM)
- add a windows build test (this seems not to be trivial and a build node 
should be provided for this)

travis-ci is free for open source projects and uses ubuntu based VMs as build 
nodes by default (community supported).

MfG / Regards
Christian Beer

Am 08.01.2015 um 19:58 schrieb Rom Walton:
 You can find the mirror here:
 https://github.com/BOINC/boinc-v2

 - Rom

 -Original Message-
 From: Rom Walton
 Sent: Thursday, January 08, 2015 1:58 PM
 To: Rom Walton; Filip Rydlo; BOINC-dev email list
 Subject: RE: [boinc_dev] Official GitHub mirror?

 The github mirror should be up and running.

 I'm not sure what to do about the pull requests yet, it looks like the web 
 services just send json requests to a remote server.  I was hoping for a 
 simple if pull request accepted, push to origin type of thing.

 I guess we will cross that bridge when we get there.

 - Rom

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf 
 Of Rom Walton
 Sent: Thursday, January 08, 2015 12:19 PM
 To: Filip Rydlo; BOINC-dev email list
 Subject: Re: [boinc_dev] Official GitHub mirror?

 We'll investigate getting this setup.

 - Rom

 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf 
 Of Filip Rydlo
 Sent: Wednesday, January 07, 2015 12:30 PM
 To: BOINC-dev email list
 Subject: Re: [boinc_dev] Official GitHub mirror?

 me too!

 I would welcome this  very very much!
 This would let me  experiment and make the Grand *redesign* of the advanced 
 view's  Tasks tab.

  Not only the  columns will be  checkable   which are to be
 displayed  and their  *order* can be  selected by the user in the GUI,  but
 the user  will be able to  *CREATE* and save/load   *several*  profiles
 !!  So that he / she  does NOT need to change it manually whenever he / she 
 needs to  switch to different point of view  to solve / check  different 
 issues  / idling cores / GPUs  etc... resource-share / backup projects
 also the ordering will be much more  optional  and will remember up to 5
 columns   by which it will  sort  - sorting order of the columns will also
 be saved/loaded in the *profile*. :)


 * This should make the LIFE of many scientists and power-users much
 much easier!*

  It will take me some time, however  I will  *design*  the
 internal  (optimal / ideal)   API for this  with   Apiary  and API
 Blueprint tools ... then I will create a good WRAPPER which will kinda
 isolate me from the *awful  wxWidget low-level code*and then ...  it
 is EASY -  The path ahead is clear. ... ! :-)

  So, thats the plan. What do You say?


 (attending  in person  the meetup  in Prague  ... which is a workshop for the 
  Apiary + API Blueprint ! So I will know to use  them *directly from
 their author*!!   Hopefully, it will be enough-GREAT a lecture.   Wish me
 luck - I need to learn this really  *WELL* if I am to use it inside of 
 BOINC Manager ;) )


 *Namaste*
 Filip


 2015-01-07 16:04 GMT+01:00 Christian Beer christian.b...@posteo.de:

 I would second that and also volunteer to look at the issues and pull 
 requests as I'm more active on github lately. An Open Source security 
 project I use and also contribute to (ossec-hids) switched to github 
 completeley and they got a huge influx of new contributors and also 
 pull requests that are easily merged and testet. They have an 
 automated compilation running with every pull request using travis-ci 
 so you see if compilation fails before merging changes with the master 
 branch.

 There is already an organization for BOINC setup by Rom. How 
 mirroring works is described here:
 https://help.github.com/articles/about-github-mirrors/

 I would think that the github support would help setting this up too.

 MfG / Regards
 Christian Beer

 Am 06.01.2015 um 19:13 schrieb Nicolás Alvarez:
 The SourceCodeGit wiki page says You don't need direct write access 
 to contribute code

Re: [boinc_dev] Official GitHub mirror?

[Rom Walton]

We'll investigate getting this setup.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Filip 
Rydlo
Sent: Wednesday, January 07, 2015 12:30 PM
To: BOINC-dev email list
Subject: Re: [boinc_dev] Official GitHub mirror?

me too!

I would welcome this  very very much!
This would let me  experiment and make the Grand *redesign* of the advanced 
view's  Tasks tab.

 Not only the  columns will be  checkable   which are to be
displayed  and their  *order* can be  selected by the user in the GUI,  but
the user  will be able to  *CREATE* and save/load   *several*  profiles
!!  So that he / she  does NOT need to change it manually whenever he / she 
needs to  switch to different point of view  to solve / check  different 
issues  / idling cores / GPUs  etc... resource-share / backup projects
also the ordering will be much more  optional  and will remember up to 5
columns   by which it will  sort  - sorting order of the columns will also
be saved/loaded in the *profile*. :)


* This should make the LIFE of many scientists and power-users much
much easier!*

 It will take me some time, however  I will  *design*  the
internal  (optimal / ideal)   API for this  with   Apiary  and API
Blueprint tools ... then I will create a good WRAPPER which will kinda
isolate me from the *awful  wxWidget low-level code*and then ...  it
is EASY -  The path ahead is clear. ... ! :-)

 So, thats the plan. What do You say?


(attending  in person  the meetup  in Prague  ... which is a workshop for the  
Apiary + API Blueprint ! So I will know to use  them *directly from
their author*!!   Hopefully, it will be enough-GREAT a lecture.   Wish me
luck - I need to learn this really  *WELL* if I am to use it inside of BOINC 
Manager ;) )


*Namaste*
Filip


2015-01-07 16:04 GMT+01:00 Christian Beer christian.b...@posteo.de:

 I would second that and also volunteer to look at the issues and pull 
 requests as I'm more active on github lately. An Open Source security 
 project I use and also contribute to (ossec-hids) switched to github 
 completeley and they got a huge influx of new contributors and also 
 pull requests that are easily merged and testet. They have an 
 automated compilation running with every pull request using travis-ci 
 so you see if compilation fails before merging changes with the master branch.

 There is already an organization for BOINC setup by Rom. How mirroring 
 works is described here:
 https://help.github.com/articles/about-github-mirrors/

 I would think that the github support would help setting this up too.

 MfG / Regards
 Christian Beer

 Am 06.01.2015 um 19:13 schrieb Nicolás Alvarez:
  The SourceCodeGit wiki page says You don't need direct write access 
  to contribute code to BOINC. Given the distributed nature of Git you 
  can publish your contributions elsewhere (e.g. on GitHub) [...].
 
  But how exactly do people contribute via Github? Push the entire 
  BOINC repo and post a link to it on the mailing list?
 
  I think it would be better if there was an official GitHub mirror of 
  the BOINC repository, which people can 'Fork' and send pull requests 
  to. I'm not proposing that development is moved to GitHub; the 
  really-official repository will remain the one hosted on 
  boinc.berkeley.edu, and the GitHub mirror would only be used for 
  external contributors to fork.
 

 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
 To unsubscribe, visit the above URL and (near bottom of page) enter 
 your email address.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Official GitHub mirror?

[Rom Walton]

The github mirror should be up and running.

I'm not sure what to do about the pull requests yet, it looks like the web 
services just send json requests to a remote server.  I was hoping for a simple 
if pull request accepted, push to origin type of thing.

I guess we will cross that bridge when we get there.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Rom 
Walton
Sent: Thursday, January 08, 2015 12:19 PM
To: Filip Rydlo; BOINC-dev email list
Subject: Re: [boinc_dev] Official GitHub mirror?

We'll investigate getting this setup.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Filip 
Rydlo
Sent: Wednesday, January 07, 2015 12:30 PM
To: BOINC-dev email list
Subject: Re: [boinc_dev] Official GitHub mirror?

me too!

I would welcome this  very very much!
This would let me  experiment and make the Grand *redesign* of the advanced 
view's  Tasks tab.

 Not only the  columns will be  checkable   which are to be
displayed  and their  *order* can be  selected by the user in the GUI,  but
the user  will be able to  *CREATE* and save/load   *several*  profiles
!!  So that he / she  does NOT need to change it manually whenever he / she 
needs to  switch to different point of view  to solve / check  different 
issues  / idling cores / GPUs  etc... resource-share / backup projects
also the ordering will be much more  optional  and will remember up to 5
columns   by which it will  sort  - sorting order of the columns will also
be saved/loaded in the *profile*. :)


* This should make the LIFE of many scientists and power-users much
much easier!*

 It will take me some time, however  I will  *design*  the
internal  (optimal / ideal)   API for this  with   Apiary  and API
Blueprint tools ... then I will create a good WRAPPER which will kinda
isolate me from the *awful  wxWidget low-level code*and then ...  it
is EASY -  The path ahead is clear. ... ! :-)

 So, thats the plan. What do You say?


(attending  in person  the meetup  in Prague  ... which is a workshop for the  
Apiary + API Blueprint ! So I will know to use  them *directly from
their author*!!   Hopefully, it will be enough-GREAT a lecture.   Wish me
luck - I need to learn this really  *WELL* if I am to use it inside of BOINC 
Manager ;) )


*Namaste*
Filip


2015-01-07 16:04 GMT+01:00 Christian Beer christian.b...@posteo.de:

 I would second that and also volunteer to look at the issues and pull 
 requests as I'm more active on github lately. An Open Source security 
 project I use and also contribute to (ossec-hids) switched to github 
 completeley and they got a huge influx of new contributors and also 
 pull requests that are easily merged and testet. They have an 
 automated compilation running with every pull request using travis-ci 
 so you see if compilation fails before merging changes with the master branch.

 There is already an organization for BOINC setup by Rom. How mirroring 
 works is described here:
 https://help.github.com/articles/about-github-mirrors/

 I would think that the github support would help setting this up too.

 MfG / Regards
 Christian Beer

 Am 06.01.2015 um 19:13 schrieb Nicolás Alvarez:
  The SourceCodeGit wiki page says You don't need direct write access 
  to contribute code to BOINC. Given the distributed nature of Git you 
  can publish your contributions elsewhere (e.g. on GitHub) [...].
 
  But how exactly do people contribute via Github? Push the entire 
  BOINC repo and post a link to it on the mailing list?
 
  I think it would be better if there was an official GitHub mirror of 
  the BOINC repository, which people can 'Fork' and send pull requests 
  to. I'm not proposing that development is moved to GitHub; the 
  really-official repository will remain the one hosted on 
  boinc.berkeley.edu, and the GitHub mirror would only be used for 
  external contributors to fork.
 

 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
 To unsubscribe, visit the above URL and (near bottom of page) enter 
 your email address.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Official GitHub mirror?

[Rom Walton]

You can find the mirror here:
https://github.com/BOINC/boinc-v2

- Rom

-Original Message-
From: Rom Walton 
Sent: Thursday, January 08, 2015 1:58 PM
To: Rom Walton; Filip Rydlo; BOINC-dev email list
Subject: RE: [boinc_dev] Official GitHub mirror?

The github mirror should be up and running.

I'm not sure what to do about the pull requests yet, it looks like the web 
services just send json requests to a remote server.  I was hoping for a simple 
if pull request accepted, push to origin type of thing.

I guess we will cross that bridge when we get there.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Rom 
Walton
Sent: Thursday, January 08, 2015 12:19 PM
To: Filip Rydlo; BOINC-dev email list
Subject: Re: [boinc_dev] Official GitHub mirror?

We'll investigate getting this setup.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Filip 
Rydlo
Sent: Wednesday, January 07, 2015 12:30 PM
To: BOINC-dev email list
Subject: Re: [boinc_dev] Official GitHub mirror?

me too!

I would welcome this  very very much!
This would let me  experiment and make the Grand *redesign* of the advanced 
view's  Tasks tab.

 Not only the  columns will be  checkable   which are to be
displayed  and their  *order* can be  selected by the user in the GUI,  but
the user  will be able to  *CREATE* and save/load   *several*  profiles
!!  So that he / she  does NOT need to change it manually whenever he / she 
needs to  switch to different point of view  to solve / check  different 
issues  / idling cores / GPUs  etc... resource-share / backup projects
also the ordering will be much more  optional  and will remember up to 5
columns   by which it will  sort  - sorting order of the columns will also
be saved/loaded in the *profile*. :)


* This should make the LIFE of many scientists and power-users much
much easier!*

 It will take me some time, however  I will  *design*  the
internal  (optimal / ideal)   API for this  with   Apiary  and API
Blueprint tools ... then I will create a good WRAPPER which will kinda
isolate me from the *awful  wxWidget low-level code*and then ...  it
is EASY -  The path ahead is clear. ... ! :-)

 So, thats the plan. What do You say?


(attending  in person  the meetup  in Prague  ... which is a workshop for the  
Apiary + API Blueprint ! So I will know to use  them *directly from
their author*!!   Hopefully, it will be enough-GREAT a lecture.   Wish me
luck - I need to learn this really  *WELL* if I am to use it inside of BOINC 
Manager ;) )


*Namaste*
Filip


2015-01-07 16:04 GMT+01:00 Christian Beer christian.b...@posteo.de:

 I would second that and also volunteer to look at the issues and pull 
 requests as I'm more active on github lately. An Open Source security 
 project I use and also contribute to (ossec-hids) switched to github 
 completeley and they got a huge influx of new contributors and also 
 pull requests that are easily merged and testet. They have an 
 automated compilation running with every pull request using travis-ci 
 so you see if compilation fails before merging changes with the master branch.

 There is already an organization for BOINC setup by Rom. How mirroring 
 works is described here:
 https://help.github.com/articles/about-github-mirrors/

 I would think that the github support would help setting this up too.

 MfG / Regards
 Christian Beer

 Am 06.01.2015 um 19:13 schrieb Nicolás Alvarez:
  The SourceCodeGit wiki page says You don't need direct write access 
  to contribute code to BOINC. Given the distributed nature of Git you 
  can publish your contributions elsewhere (e.g. on GitHub) [...].
 
  But how exactly do people contribute via Github? Push the entire 
  BOINC repo and post a link to it on the mailing list?
 
  I think it would be better if there was an official GitHub mirror of 
  the BOINC repository, which people can 'Fork' and send pull requests 
  to. I'm not proposing that development is moved to GitHub; the 
  really-official repository will remain the one hosted on 
  boinc.berkeley.edu, and the GitHub mirror would only be used for 
  external contributors to fork.
 

 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
 To unsubscribe, visit the above URL and (near bottom of page) enter 
 your email address.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter

Re: [boinc_dev] BOINC 7.4.36 released to public

[Rom Walton]

I believe I committed a fix for that in the 7.4 branch.

- Rom

-Original Message-
From: Grozdan [mailto:neutri...@gmail.com] 
Sent: Thursday, January 01, 2015 2:36 PM
To: Rom Walton
Cc: boinc_annou...@ssl.berkeley.edu; boinc_dev@ssl.berkeley.edu; 
boinc_proje...@ssl.berkeley.edu; BOINC Alpha
Subject: Re: [boinc_dev] BOINC 7.4.36 released to public

On Thu, Jan 1, 2015 at 8:18 PM, Rom Walton r...@romwnet.org wrote:
 A new version of BOINC is ready for public use.

 Changes Include:
 *Attaching to World Community Grid
 *Back-up projects (0 Resource Share)
 *Better detection of notice updates (reduces the number of system
 notifications)
 *Suspending GPUs should not suspend Bitcoin Miners *Increasing the 
 maximum number of coprocessor devices to 64 *Updates to 
 OpenSSL(1.0.1j) and LibCurl?(7.39.0)

 Download:
 http://boinc.berkeley.edu/download.php

 Release Notes:
 http://boinc.berkeley.edu/wiki/Release_Notes

 Thanks to all the testers whom helped out this release cycle:
 Ralfy, Peter Jasion, MarkJ, Ageless, Cliff Harding, [TiDC] Chulma, 
 Armagedets, [SG-SPEG] Autofuzzy, Christian Schroder, Billy, Jacob 
 Klein, pi17388, GPV67, BobCat13

Hi,

Fails to compile here on openSUSE 13.2 with wxWidgets 3.0.2

http://pastebin.com/RWAc34gP




 - Rom
 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
 To unsubscribe, visit the above URL and (near bottom of page) enter 
 your email address.



--
Yours truly
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

[boinc_dev] BOINC 7.4.36 released to public

[Rom Walton]

A new version of BOINC is ready for public use.

Changes Include:
*Attaching to World Community Grid 
*Back-up projects (0 Resource Share) 
*Better detection of notice updates (reduces the number of system
notifications) 
*Suspending GPUs should not suspend Bitcoin Miners 
*Increasing the maximum number of coprocessor devices to 64 
*Updates to OpenSSL(1.0.1j) and LibCurl?(7.39.0)

Download:
http://boinc.berkeley.edu/download.php

Release Notes:
http://boinc.berkeley.edu/wiki/Release_Notes

Thanks to all the testers whom helped out this release cycle:
Ralfy, Peter Jasion, MarkJ, Ageless, Cliff Harding, [TiDC] Chulma,
Armagedets, [SG-SPEG] Autofuzzy, Christian Schroder, Billy, Jacob Klein,
pi17388, GPV67, BobCat13

- Rom
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

[boinc_dev] BOINC HTML-Based Graphics Applications

[Rom Walton]

Over the last week I've been working on extending the BOINC graphics app
infrastructure to include HTML based applications.

I'm now far enough along that I'm ready to solicit feedback from the
community on the current design and any feature requests.

I've created a wiki page and well as precompiled binaries and they are
located here:
http://boinc.berkeley.edu/trac/wiki/HTMLGfx

If anybody wants to take a crack at replacing the embedded HTML page
that is included in the executable, I would be happy to replace it.  It
started out as a proof of concept and I left it in to test various
things.

If you are interested, take it for a test drive and let me know what you
think.

Thanks in advance.

- Rom
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Boinc 7.4.23 doesn't find OpenCL device

[Rom Walton]

Fixed in .26/.27.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
Gianfranco Costamagna
Sent: Friday, November 14, 2014 4:20 AM
To: BOINC Developers Mailing List
Subject: [boinc_dev] Boinc 7.4.23 doesn't find OpenCL device

Hi boinc developers,
I got this morning a debian bug that I'm forwarding here
Package: boinc-client
Version: 7.4.23+dfsg-1exp3
Severity: normal

Dear Maintainer,

current version fails to detect Intel GPU as an OpenCL device.

I have several OpenCL icd files installed:
dpkg -S OpenCL/vendors
pocl-opencl-icd: /etc/OpenCL/vendors/pocl.icd pocl-opencl-icd, beignet:
/etc/OpenCL/vendors
beignet: /etc/OpenCL/vendors/intel.cd
beignet: /etc/OpenCL/vendors/intel-beignet.icd

and clinfo detects 3 platforms:
clinfo -h
pocl warning: encountered incomplete implementation in
clGetDeviceInfo.c:225 pocl warning: encountered incomplete
implementation in clGetDeviceInfo.c:271
Number of platforms:3
with one being:
Platform Name:Intel Gen OCL Driver
Number of devices:  1
Device Type:  CL_DEVICE_TYPE_GPU


But boinc reports:
13-Nov-2014 22:44:07 [---] No usable GPUs found




have many thanks,

Gianfranco
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Boinc 7.4.23 doesn't find OpenCL device

[Rom Walton]

Well, maybe...

The block we had in place was supposed to be for Nvidia GPUs, which has
been removed.

Intel should not have been a problem.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
Rom Walton
Sent: Friday, November 14, 2014 10:29 AM
To: Gianfranco Costamagna; BOINC Developers Mailing List
Subject: Re: [boinc_dev] Boinc 7.4.23 doesn't find OpenCL device

Fixed in .26/.27.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
Gianfranco Costamagna
Sent: Friday, November 14, 2014 4:20 AM
To: BOINC Developers Mailing List
Subject: [boinc_dev] Boinc 7.4.23 doesn't find OpenCL device

Hi boinc developers,
I got this morning a debian bug that I'm forwarding here
Package: boinc-client
Version: 7.4.23+dfsg-1exp3
Severity: normal

Dear Maintainer,

current version fails to detect Intel GPU as an OpenCL device.

I have several OpenCL icd files installed:
dpkg -S OpenCL/vendors
pocl-opencl-icd: /etc/OpenCL/vendors/pocl.icd pocl-opencl-icd, beignet:
/etc/OpenCL/vendors
beignet: /etc/OpenCL/vendors/intel.cd
beignet: /etc/OpenCL/vendors/intel-beignet.icd

and clinfo detects 3 platforms:
clinfo -h
pocl warning: encountered incomplete implementation in
clGetDeviceInfo.c:225 pocl warning: encountered incomplete
implementation in clGetDeviceInfo.c:271
Number of platforms:3
with one being:
Platform Name:Intel Gen OCL Driver
Number of devices:  1
Device Type:  CL_DEVICE_TYPE_GPU


But boinc reports:
13-Nov-2014 22:44:07 [---] No usable GPUs found




have many thanks,

Gianfranco
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] stderrdae.txt - why are there no time stamps in theerror file ?

[Rom Walton]

To which messages are you referring?

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Toralf 
Förster
Sent: Wednesday, November 12, 2014 1:48 PM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] stderrdae.txt - why are there no time stamps in theerror 
file ?

I tried to correlate entries from stderrdae.txt to stdoutdae.txt - but that 
won't work without time stamps :-(

-- 
Toralf
pgp key: 0076 E94E

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Windows 7 Boinc client service fails to run wrappersuccessfully

[Rom Walton]

I've updated the wrapper wiki page to point to 26011 of the wrapper which 
should resolve this issue.


See:

http://boinc.berkeley.edu/trac/wiki/WrapperApp


-- Rom






Sent from Surface





From: Bill Flynn
Sent: ‎Friday‎, ‎October‎ ‎3‎, ‎2014 ‎9‎:‎23‎ ‎PM
To: BOINC Dev Mailing List





Sorry, I was away and disabled email delivery.  This is my response in
context.

On Fri, Oct 3, 2014 at 3:18 PM, Bill Flynn wfly...@gmail.com wrote:

 Hi Dave,

 We think the problem actually stems from the sandboxed permissions of 
 boinc_project and boinc_master when Boinc is installed as a service on 
 Windows.  Doing

 net localgroup administrators

 neither boinc_master nor boinc_project were listed.  So we added

 net localgroup administrators boinc_master /add
 net localgroup administrators boinc_project /add

 to our install script and things worked fine after a restart.  I think it's 
 because each time the wrapper tried to communicate with the client, it didn't 
 have permissions to do so, and would exit; but then the client would see it 
 has a free CPU and would restart the job until we hit the 100 retry maximum.  
 As an administrator, the boinc_* user running the wrapper can properly 
 communicate with the client.  We are only running our own project, so I we're 
 not too concerned with the security implications of elevating the privileges 
 of the two boinc_* users.

 I had tried redownloading the wrappers from the WrapperApp site, but they 
 didn't solve the problem.  We also tried using the wrappers that come with 
 the debian7 virtualbox server; those didn't work either.

 Thanks,

 Bill


Bill:
It looks like you're using an old version of the wrapper,
which had a bug causing the problem you're seeing.
This is fixed in the current
version:http://boinc.berkeley.edu/trac/wiki/WrapperApp

-- David

On 25-Sep-2014 10:02 AM, Bill Flynn wrote:
* Hello,
** We have developed molecular dynamics code which we would like to distribute
** to unused Windows 7 machines at our university.  The code was originally
** developed in Linux but we have recently compiled on Windows using Mingw.
** We are distributing the app using the Boinc Wrapper.
** For both Windows clients where Boinc was not installed as a service and
** Linux clients where software was installed via apt-get (or similar), the
** app works well and returns successful results.  However, for Windows
** clients where Boinc was installed as a service, the workunits fail 95+% of
** the time with the following error message:
** 10:29:37 (2352): wrapper: starting
** 10:29:38 (2352): wrapper: running ../../projects/
** XXX.XXX.XXX.XXX/impact_1.5_windows_x86_64.exe
** http://155.247.99.246/impact_1.5_windows_x86_64.exe
http://155.247.99.246/impact_1.5_windows_x86_64.exe (md.inp)
** 10:29:49 (2352): BOINC client no longer exists - exiting
** This repeats 100 times until the job returns unsuccessfully with an
** EXIT_CHILD_FAILED or ERR_TOO_MANY_EXITS error.
** I have tested this on several machines with fresh Windows installations
** where Boinc (7.2.42 Windows 64 bit) is installed as a service.  Given the
** list of possible issues here (
** http://boincfaq.mundayweb.com/index.php?view=116
http://boincfaq.mundayweb.com/index.php?view=116), I tried all
possible
** configurations of disabled anti-virus, disabled Windows time
** synchronization, and disabled drive indexing with the service
** installation.  None of them fix the problem.  We also run with 50% CPUs
** used with no throttling.  We have tested these clients with other projects
** which have native Boinc applications, and they run fine.  Therefore, we
** think it is a interaction problem between the Boinc wrapper and Boinc
** client service installation on Windows.
** Speaking of which, are the wrappers found here (
** http://boinc.berkeley.edu/trac/wiki/WrapperApp
http://boinc.berkeley.edu/trac/wiki/WrapperApp) up to date?
** We are forced to run Boinc as a service in order to use these machines
** (university computer lab/library) and are several weeks/months away from
** getting around to restructuring our code to accommodate the Boinc API.
** Do you have any suggestions on how to fix this issue?  I have attached the
** following files: job.xml, input_template, output_template, version.xml, and
** stderr.txt (from an example job).
** Thanks,
** Bill
** ___
** boinc_dev mailing list
** boinc_dev at ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
** http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
** To unsubscribe, visit the above URL and
** (near bottom of page) enter your email address.
*
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Boinc client certificate verification failure

[Rom Walton]

That pretty much just solves the problem for your machine.  It won't solve the 
problem for the volunteers.


See:

http://boinc.berkeley.edu/trac/wiki/SecureHttp


Apache needs to know about the intermediate chain file that links your ssl cert 
with the CA’s root certificate.


- Rom






Sent from Surface





From: Bill Flynn
Sent: ‎Saturday‎, ‎October‎ ‎4‎, ‎2014 ‎3‎:‎48‎ ‎AM
To: BOINC Dev Mailing List





Actually I solved this.  I downloaded the GoDaddy ca-bundle and appended
its contents to C:\Program Files\BOINC\ca-bundle.crt.  That cleared up the
issue.



On Fri, Oct 3, 2014 at 3:02 PM, Bill Flynn wfly...@gmail.com wrote:

 Hi,

 My web server's CA (GoDaddy) isn't trusted by the boinc client.  When
 requesting

 https://example.domain.com/project/get_project_config.php

 the request fails with:

 [http] [ID #1] Info:  Trying xxx.xxx.xxx.xxx...
 [http] [ID #1] Info: Connected to example.domain.com (xxx.xxx.xxx.xxx)
 port 443 (#0)
 [http] [ID #1] Info: Connected to example.domain.com (xxx.xxx.xxx.xxx)
 port 443 (#0)
 [http] [ID #1] Info: successfully set certificate verify locations:
 [http] [ID #1] Info:  CAfile C:\Program Files\BOINC\ca-bundle.crt
 [http] [ID #1] Info:  CApath: none
 [http] [ID #1] Info: SSLv3, TLS handshake, Client hello (1):
 [http] [ID #1] Info: SSLv3, TLS handshake, Server hello (2):
 [http] [ID #1] Info: SSLv3, TLS handshake, CERT (11):
 [http] [ID #1] Info: SSLv3, TLS alert, Server hello (2):
 [http] [ID #1] Info: SSL certificate problem, verify that the CA cert is
 OK. Details:
 [http] [ID #1] Info: error: 14090086:SSL
 routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
 [http] [ID #1] Info: Closing connection #0
 [http] HTTP error: Peer certificate cannot be authenticated with given CA
 certificates

 This is causing my any clients to fail when attaching to the project.  How
 can I get the BOINC client to trust the CA that signed my web server's
 certificate so the client can access the get_project_config.php page?

 Thanks,

 Bill

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on the CR/LF changes made upstream

[Rom Walton]

Our server runs an older version of git.

1.7.1

We are in the process of migrating to a new server which runs a more up-to-date 
distro.

- Rom

-Original Message-
From: Torsten Bögershausen [mailto:tbo...@web.de] 
Sent: Sunday, September 14, 2014 7:23 AM
To: Toralf Förster; Torsten Bögershausen; Rom Walton; g...@vger.kernel.org
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on 
the CR/LF changes made upstream

On 09/14/2014 10:51 AM, Torsten Bögershausen wrote:
 It may be that there is a bug in the tools you are using.
 I use git 2.1.0

The question was how the commit had been produced:
Rom,  what are you using ?



___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on the CR/LF changes made upstream

[Rom Walton]

Try:
git checkout -f master
git pull origin

I committed fixes for that stuff this morning.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Toralf 
Förster
Sent: Friday, September 12, 2014 2:09 PM
To: g...@vger.kernel.org
Cc: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on the 
CR/LF changes made upstream

Today I run again into the CR/LF pain when I pulled from BOINC upstream and me 
wonders how I can repair the repository using git-2.1.0 at a 32bit Linux 
without cloning the full repository again (as I did it in the past). FWIW I did 
not changed anything locally, I just do pull regularly from upstreem to create 
a tar-ball of the current version for my own purpose:


tfoerste@n22 ~/devel/trinity $ cd ~/devel/boinc-v2; git pull
remote: Counting objects: 104, done.
remote: Compressing objects: 100% (52/52), done.
remote: Total 52 (delta 42), reused 0 (delta 0) Unpacking objects: 100% 
(52/52), done.
From git://boinc.berkeley.edu/boinc-v2
   ce97e85..d2e5582  master - origin/master
   194f1dc..4a696b4  client_release/7/7.4 - origin/client_release/7/7.4 
Updating ce97e85..d2e5582
error: Your local changes to the following files would be overwritten by merge:
html/languages/translations/hu.po
html/languages/translations/nl.po
locale/bg/BOINC-Web.po
locale/da/BOINC-Web.po
locale/el/BOINC-Web.po
locale/fr/BOINC-Web.po
locale/hr/BOINC-Web.po
locale/hu/BOINC-Project-Generic.po
locale/hu/BOINC-Web.po
locale/it_IT/BOINC-Project-Generic.po
locale/lv/BOINC-Web.po
locale/nl/BOINC-Project-Generic.po
locale/nl/BOINC-Web.po
locale/pl/BOINC-Web.po
locale/pt_BR/BOINC-Web.po
locale/ro/BOINC-Web.po
locale/sk/BOINC-Web.po
locale/zh_TW/BOINC-Web.po
Please, commit your changes or stash them before you can merge.
Aborting

tfoerste@n22 ~/devel/boinc-v2 $ git diff

tfoerste@n22 ~/devel/boinc-v2 $ git status On branch master Your branch is 
behind 'origin/master' by 7 commits, and can be fast-forwarded.
  (use git pull to update your local branch) Changes not staged for commit:
  (use git add file... to update what will be committed)
  (use git checkout -- file... to discard changes in working directory)

modified:   html/languages/translations/hu.po
modified:   html/languages/translations/nl.po
modified:   locale/bg/BOINC-Web.po
modified:   locale/da/BOINC-Web.po
modified:   locale/el/BOINC-Web.po
modified:   locale/fr/BOINC-Web.po
modified:   locale/hr/BOINC-Web.po
modified:   locale/hu/BOINC-Project-Generic.po
modified:   locale/hu/BOINC-Web.po
modified:   locale/it_IT/BOINC-Project-Generic.po
modified:   locale/lv/BOINC-Web.po
modified:   locale/nl/BOINC-Project-Generic.po
modified:   locale/nl/BOINC-Web.po
modified:   locale/pl/BOINC-Web.po
modified:   locale/pt_BR/BOINC-Web.po
modified:   locale/ro/BOINC-Web.po
modified:   locale/sk/BOINC-Web.po
modified:   locale/zh_TW/BOINC-Web.po

no changes added to commit (use git add and/or git commit -a)


tfoerste@n22 ~/devel/boinc-v2 $ git branch
* master

tfoerste@n22 ~/devel/boinc-v2 $ git stash
warning: CRLF will be replaced by LF in html/languages/translations/hu.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in html/languages/translations/nl.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/bg/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/da/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/el/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/fr/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/hr/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/hu/BOINC-Project-Generic.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/hu/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/it_IT/BOINC-Project-Generic.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in locale/lv/BOINC-Web.po.
The file will have its original line endings in your working directory.
warning: CRLF will be replaced by LF in 

Re: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on the CR/LF changes made upstream

[Rom Walton]

Crud...

Well, personally, I would delete the locale directory and the two translation 
files in html.

Do the 'git pull', and then switch between master and some other branch.

like:
git checkout -f client_release/7/7.4
git checkout -f master

It is round about, but it should get the job done.

- Rom

-Original Message-
From: Toralf Förster [mailto:toralf.foers...@gmx.de] 
Sent: Friday, September 12, 2014 2:32 PM
To: Rom Walton; g...@vger.kernel.org
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on 
the CR/LF changes made upstream

On 09/12/2014 08:19 PM, Rom Walton wrote:
 Try:
 git checkout -f master
 git pull origin
 
 I committed fixes for that stuff this morning.

doesn't helped :

tfoerste@n22 ~/devel/boinc-v2 $ git checkout -f master Already on 'master'
Your branch is behind 'origin/master' by 7 commits, and can be fast-forwarded.
  (use git pull to update your local branch)

tfoerste@n22 ~/devel/boinc-v2 $ git pull origin Updating ce97e85..d2e5582
error: Your local changes to the following files would be overwritten by merge:
html/languages/translations/hu.po
html/languages/translations/nl.po
locale/bg/BOINC-Web.po
locale/da/BOINC-Web.po
locale/el/BOINC-Web.po
locale/fr/BOINC-Web.po
locale/hr/BOINC-Web.po
locale/hu/BOINC-Project-Generic.po
locale/hu/BOINC-Web.po
locale/it_IT/BOINC-Project-Generic.po
locale/lv/BOINC-Web.po
locale/nl/BOINC-Project-Generic.po
locale/nl/BOINC-Web.po
locale/pl/BOINC-Web.po
locale/pt_BR/BOINC-Web.po
locale/ro/BOINC-Web.po
locale/sk/BOINC-Web.po
locale/zh_TW/BOINC-Web.po
Please, commit your changes or stash them before you can merge.
Aborting

--
Toralf
pgp key: 0076 E94E

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on the CR/LF changes made upstream

[Rom Walton]

I found this:
http://stackoverflow.com/questions/17223527/how-do-i-force-git-to-checkout-the-master-branch-and-remove-carriage-returns-aft

That might help in the future.

- Rom

-Original Message-
From: Toralf Förster [mailto:toralf.foers...@gmx.de] 
Sent: Friday, September 12, 2014 3:04 PM
To: Rom Walton; g...@vger.kernel.org
Cc: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] (local ?) BOINC repo broken again -or- how to act on 
the CR/LF changes made upstream

On 09/12/2014 08:55 PM, Rom Walton wrote:
 Crud...
 
 Well, personally, I would delete the locale directory and the two translation 
 files in html.
 
 Do the 'git pull', and then switch between master and some other branch.
 
 like:
 git checkout -f client_release/7/7.4
 git checkout -f master
 
 It is round about, but it should get the job done.

Re-cloning seems to be the only way, b/c :

tfoerste@n22 ~/devel/boinc-v2 $ git checkout -f client_release/7/7.4 Branch 
client_release/7/7.4 set up to track remote branch client_release/7/7.4 from 
origin.
Switched to a new branch 'client_release/7/7.4'

tfoerste@n22 ~/devel/boinc-v2 $ git checkout -f master Checking out files: 100% 
(234/234), done.
Switched to branch 'master'
Your branch is behind 'origin/master' by 7 commits, and can be fast-forwarded.
  (use git pull to update your local branch)

tfoerste@n22 ~/devel/boinc-v2 $ git pull Updating ce97e85..d2e5582
error: Your local changes to the following files would be overwritten by merge:
...
same picture as before

--
Toralf
pgp key: 0076 E94E

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Wrapper resource file version corrupted

[Rom Walton]

I've applied your patch to the wrapper and vboxwrapper.

Leaving git enabled in Trac was causing our server performance problems.
We disabled it until we can complete the migration to a new server.

- Rom

-Original Message-
From: Teemu Mannermaa [mailto:t...@sci.fi] 
Sent: Sunday, September 07, 2014 9:15 AM
To: BOINC Developers Mailing List
Cc: Rom Walton
Subject: Wrapper resource file version corrupted

Hi,

Commit
http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=commit;h=9f5e9a0b7e7f
c39915cc6abcd0fb5fccfa738822
is awesome but unfortunately the way FileVersion and ProductVersion are
set they end up containing junk (binary data, instead of text strings).
:(

Attached is a patch that fixes it but you could also make an already
stringified version for wrapper and use that instead.

PS. Your trac git browser is broken and just throws error Unsupported
version control system git: Can't find an appropriate component, maybe
the corresponding plugin was not enabled?. :(
--
Teemu Mannermaa
System Specialist

Anything is possible but probabilities vary.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] BOINC can't detect OpenCL under CUDA 6.5 on linux

[Rom Walton]

Is there an libopencl.so in /usr/lib?

 

If so, was the ICD installed?

 

http://www.khronos.org/news/permalink/opencl-installable-client-driver-icd-loader

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Wednesday, September 03, 2014 4:00 PM
To: boinc_dev@ssl.berkeley.edu; David Anderson; Rom Walton
Subject: BOINC can't detect OpenCL under CUDA 6.5 on linux

 

Following installation of CUDA 6.5 on a RHEL6.5 derivative (Scientific Linux), 
BOINC can no longer detect OpenCL Libraries.

03-Sep-2014 12:45:09 [---] Starting BOINC client version 7.2.33 for 
x86_64-pc-linux-gnu
03-Sep-2014 12:45:09 [---] log flags: file_xfer, sched_ops, task, coproc_debug
03-Sep-2014 12:45:09 [---] Libraries: libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 
libidn/1.18 libssh2/1.4.2
03-Sep-2014 12:45:09 [---] Data directory: /var/lib/boinc
03-Sep-2014 12:45:09 [---] [coproc] launching child process at 
/usr/bin/boinc_client
03-Sep-2014 12:45:09 [---] [coproc] relative to directory /var/lib/boinc
03-Sep-2014 12:45:09 [---] [coproc] with data directory /var/lib/boinc
03-Sep-2014 12:45:09 [---] CUDA: NVIDIA GPU 0: GeForce GT 620 (driver version 
unknown, CUDA version 6.5, compute capability 2.1, 2048MB, 2032MB available, 
269 GFLOPS peak)
03-Sep-2014 12:45:09 [---] CUDA: NVIDIA GPU 1: GeForce GT 520 (driver version 
unknown, CUDA version 6.5, compute capability 2.1, 1023MB, 1012MB available, 
156 GFLOPS peak)
03-Sep-2014 12:45:09 [---] NVIDIA library reports 2 GPUs
03-Sep-2014 12:45:09 [---] No ATI library found
03-Sep-2014 12:45:09 [---] No OpenCL library found
03-Sep-2014 12:45:09 [---] App version needs OpenCL but GPU doesn't support it
03-Sep-2014 12:45:09 [SETI@home] Application uses missing NVIDIA GPU
03-Sep-2014 12:45:09 [---] App version needs OpenCL but GPU doesn't support it
03-Sep-2014 12:45:09 [Milkyway@Home] Application uses missing NVIDIA GPU
03-Sep-2014 12:45:09 [---] App version needs OpenCL but GPU doesn't support it
03-Sep-2014 12:45:09 [Milkyway@Home] Application uses missing NVIDIA GPU
03-Sep-2014 12:45:09 [Milkyway@Home] Missing coprocessor for task 
ps_modfit_15_3s_130_wrap_const_1_1405680903_8114046_0

[many deleted]

03-Sep-2014 12:45:09 [SETI@home Beta Test] Missing coprocessor for task 
ap_30my13ac_B3_P0_00026_20140825_22705.wu_1
03-Sep-2014 12:45:09 [---] Host name: backer
03-Sep-2014 12:45:09 [---] Processor: 8 GenuineIntel Intel(R) Xeon(R) CPU 
E5-2603 v2 @ 1.80GHz [Family 6 Model 62 Stepping 4]
03-Sep-2014 12:45:09 [---] 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 xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl 
vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm arat epb xsaveopt pln pts 
dts tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
03-Sep-2014 12:45:09 [---] OS: Linux: 2.6.32-431.23.3.el6.x86_64
03-Sep-2014 12:45:09 [---] Memory: 126.00 GB physical, 128.00 GB virtual
03-Sep-2014 12:45:09 [---] Disk: 78.74 GB total, 56.99 GB free
03-Sep-2014 12:45:09 [---] Local time is UTC -7 hours
03-Sep-2014 12:45:09 [---] VirtualBox version: 4.1.34r95024
03-Sep-2014 12:45:09 [---] Config: use all coprocessors

[more deleted]

03-Sep-2014 12:45:09 [---] General prefs: from http://bam.boincstats.com/ (last 
modified 02-Jul-2014 09:28:55)
03-Sep-2014 12:45:09 [---] Host location: none
03-Sep-2014 12:45:09 [---] General prefs: using your defaults
03-Sep-2014 12:45:09 [---] Reading preferences override file
03-Sep-2014 12:45:09 [---] Preferences:
03-Sep-2014 12:45:09 [---]max memory usage when active: 42579.43MB
03-Sep-2014 12:45:09 [---]max memory usage when idle: 129028.59MB
03-Sep-2014 12:45:09 [---]max disk usage: 64.78GB
03-Sep-2014 12:45:09 [---]max CPUs used: 4
03-Sep-2014 12:45:09 [---]don't compute while active
03-Sep-2014 12:45:09 [---]don't use GPU while active
03-Sep-2014 12:45:09 [---](to change preferences, visit a project web site 
or select Preferences in the Manager)
03-Sep-2014 12:45:09 [---] Not using a proxy
03-Sep-2014 12:45:11 Initialization completed
03-Sep-2014 12:45:11 [Einstein@Home] [coproc] Assigning NVIDIA instance 0 to 
PB0037_0_32_1
03-Sep-2014 12:45:11 [Einstein@Home] [coproc] Assigning NVIDIA instance 1 to 
PB0037_009D1_126_1



clinfo doesn't have any problem finding them.

Number of platforms: 1
  Platform Profile:  FULL_PROFILE
  Platform Version:  OpenCL 1.1 CUDA 6.5.14
  Platform Name: NVIDIA CUDA
  Platform Vendor:   NVIDIA Corporation
  Platform Extensions:   cl_khr_byte_addressable_store 
cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options

Re: [boinc_dev] BOINC can't detect OpenCL under CUDA 6.5 on linux

[Rom Walton]

I found this post:

http://scientificlinuxforum.org/index.php?showtopic=2666

 

I suspect the packages have been reshuffled.

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Wednesday, September 03, 2014 4:11 PM
To: Rom Walton
Cc: boinc_dev@ssl.berkeley.edu; David Anderson
Subject: Re: BOINC can't detect OpenCL under CUDA 6.5 on linux

 

No, there is no libopencl in /usr/lib or /usr/lib64.  This machine has never 
has and devkit other than nvidia's installed on it.



 

On Wed, Sep 3, 2014 at 1:06 PM, Rom Walton r...@romwnet.org wrote:

Is there an libopencl.so in /usr/lib?

 

If so, was the ICD installed?

 

http://www.khronos.org/news/permalink/opencl-installable-client-driver-icd-loader

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Wednesday, September 03, 2014 4:00 PM
To: boinc_dev@ssl.berkeley.edu; David Anderson; Rom Walton
Subject: BOINC can't detect OpenCL under CUDA 6.5 on linux

 

Following installation of CUDA 6.5 on a RHEL6.5 derivative (Scientific Linux), 
BOINC can no longer detect OpenCL Libraries.

03-Sep-2014 12:45:09 [---] Starting BOINC client version 7.2.33 for 
x86_64-pc-linux-gnu
03-Sep-2014 12:45:09 [---] log flags: file_xfer, sched_ops, task, coproc_debug
03-Sep-2014 12:45:09 [---] Libraries: libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 
libidn/1.18 libssh2/1.4.2
03-Sep-2014 12:45:09 [---] Data directory: /var/lib/boinc
03-Sep-2014 12:45:09 [---] [coproc] launching child process at 
/usr/bin/boinc_client
03-Sep-2014 12:45:09 [---] [coproc] relative to directory /var/lib/boinc
03-Sep-2014 12:45:09 [---] [coproc] with data directory /var/lib/boinc
03-Sep-2014 12:45:09 [---] CUDA: NVIDIA GPU 0: GeForce GT 620 (driver version 
unknown, CUDA version 6.5, compute capability 2.1, 2048MB, 2032MB available, 
269 GFLOPS peak)
03-Sep-2014 12:45:09 [---] CUDA: NVIDIA GPU 1: GeForce GT 520 (driver version 
unknown, CUDA version 6.5, compute capability 2.1, 1023MB, 1012MB available, 
156 GFLOPS peak)
03-Sep-2014 12:45:09 [---] NVIDIA library reports 2 GPUs
03-Sep-2014 12:45:09 [---] No ATI library found
03-Sep-2014 12:45:09 [---] No OpenCL library found
03-Sep-2014 12:45:09 [---] App version needs OpenCL but GPU doesn't support it
03-Sep-2014 12:45:09 [SETI@home] Application uses missing NVIDIA GPU
03-Sep-2014 12:45:09 [---] App version needs OpenCL but GPU doesn't support it
03-Sep-2014 12:45:09 [Milkyway@Home] Application uses missing NVIDIA GPU
03-Sep-2014 12:45:09 [---] App version needs OpenCL but GPU doesn't support it
03-Sep-2014 12:45:09 [Milkyway@Home] Application uses missing NVIDIA GPU
03-Sep-2014 12:45:09 [Milkyway@Home] Missing coprocessor for task 
ps_modfit_15_3s_130_wrap_const_1_1405680903_8114046_0

[many deleted]

03-Sep-2014 12:45:09 [SETI@home Beta Test] Missing coprocessor for task 
ap_30my13ac_B3_P0_00026_20140825_22705.wu_1
03-Sep-2014 12:45:09 [---] Host name: backer
03-Sep-2014 12:45:09 [---] Processor: 8 GenuineIntel Intel(R) Xeon(R) CPU 
E5-2603 v2 @ 1.80GHz [Family 6 Model 62 Stepping 4]
03-Sep-2014 12:45:09 [---] 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 xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl 
vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm arat epb xsaveopt pln pts 
dts tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
03-Sep-2014 12:45:09 [---] OS: Linux: 2.6.32-431.23.3.el6.x86_64
03-Sep-2014 12:45:09 [---] Memory: 126.00 GB physical, 128.00 GB virtual
03-Sep-2014 12:45:09 [---] Disk: 78.74 GB total, 56.99 GB free
03-Sep-2014 12:45:09 [---] Local time is UTC -7 hours
03-Sep-2014 12:45:09 [---] VirtualBox version: 4.1.34r95024
03-Sep-2014 12:45:09 [---] Config: use all coprocessors

[more deleted]

03-Sep-2014 12:45:09 [---] General prefs: from http://bam.boincstats.com/ (last 
modified 02-Jul-2014 09:28:55)
03-Sep-2014 12:45:09 [---] Host location: none
03-Sep-2014 12:45:09 [---] General prefs: using your defaults
03-Sep-2014 12:45:09 [---] Reading preferences override file
03-Sep-2014 12:45:09 [---] Preferences:
03-Sep-2014 12:45:09 [---]max memory usage when active: 42579.43MB
03-Sep-2014 12:45:09 [---]max memory usage when idle: 129028.59MB
03-Sep-2014 12:45:09 [---]max disk usage: 64.78GB
03-Sep-2014 12:45:09 [---]max CPUs used: 4
03-Sep-2014 12:45:09 [---]don't compute while active
03-Sep-2014 12:45:09 [---]don't use GPU while active
03-Sep-2014 12:45:09 [---](to change preferences, visit a project web site 
or select Preferences in the Manager)
03-Sep-2014 12:45:09 [---] Not using a proxy
03-Sep-2014 12:45:11 Initialization completed
03-Sep-2014 12:45:11 [Einstein@Home] [coproc] Assigning NVIDIA instance 0 to 
PB0037_0_32_1
03-Sep

Re: [boinc_dev] BOINC can't detect OpenCL under CUDA 6.5 on linux

[Rom Walton]

No, maybe a case problem?

 

We are looking for libOpenCL.so.

 

Line 181 of client/gpu_opencl.cpp.

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Wednesday, September 03, 2014 4:21 PM
To: Rom Walton
Cc: boinc_dev@ssl.berkeley.edu; David Anderson
Subject: Re: BOINC can't detect OpenCL under CUDA 6.5 on linux

 

I don't think that's it.  The driver is definitely installed.  I can run OpenCL 
code and CUDA code from the command line.  BOINC runs CUDA apps fine.  BOINC 
just thinks it can't find libOpenCL.so.  Is BOINC using static paths for 
libOpenCL, rather than letting ld.so find it?

 

On Wed, Sep 3, 2014 at 1:16 PM, Rom Walton r...@romwnet.org wrote:

I found this post:

http://scientificlinuxforum.org/index.php?showtopic=2666

 

I suspect the packages have been reshuffled.

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Wednesday, September 03, 2014 4:11 PM
To: Rom Walton
Cc: boinc_dev@ssl.berkeley.edu; David Anderson
Subject: Re: BOINC can't detect OpenCL under CUDA 6.5 on linux

 

No, there is no libopencl in /usr/lib or /usr/lib64.  This machine has never 
has and devkit other than nvidia's installed on it.

 

On Wed, Sep 3, 2014 at 1:06 PM, Rom Walton r...@romwnet.org wrote:

Is there an libopencl.so in /usr/lib?

 

If so, was the ICD installed?

 

http://www.khronos.org/news/permalink/opencl-installable-client-driver-icd-loader

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Wednesday, September 03, 2014 4:00 PM
To: boinc_dev@ssl.berkeley.edu; David Anderson; Rom Walton
Subject: BOINC can't detect OpenCL under CUDA 6.5 on linux

 

Following installation of CUDA 6.5 on a RHEL6.5 derivative (Scientific Linux), 
BOINC can no longer detect OpenCL Libraries.

03-Sep-2014 12:45:09 [---] Starting BOINC client version 7.2.33 for 
x86_64-pc-linux-gnu
03-Sep-2014 12:45:09 [---] log flags: file_xfer, sched_ops, task, coproc_debug
03-Sep-2014 12:45:09 [---] Libraries: libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 
libidn/1.18 libssh2/1.4.2
03-Sep-2014 12:45:09 [---] Data directory: /var/lib/boinc
03-Sep-2014 12:45:09 [---] [coproc] launching child process at 
/usr/bin/boinc_client
03-Sep-2014 12:45:09 [---] [coproc] relative to directory /var/lib/boinc
03-Sep-2014 12:45:09 [---] [coproc] with data directory /var/lib/boinc
03-Sep-2014 12:45:09 [---] CUDA: NVIDIA GPU 0: GeForce GT 620 (driver version 
unknown, CUDA version 6.5, compute capability 2.1, 2048MB, 2032MB available, 
269 GFLOPS peak)
03-Sep-2014 12:45:09 [---] CUDA: NVIDIA GPU 1: GeForce GT 520 (driver version 
unknown, CUDA version 6.5, compute capability 2.1, 1023MB, 1012MB available, 
156 GFLOPS peak)
03-Sep-2014 12:45:09 [---] NVIDIA library reports 2 GPUs
03-Sep-2014 12:45:09 [---] No ATI library found
03-Sep-2014 12:45:09 [---] No OpenCL library found
03-Sep-2014 12:45:09 [---] App version needs OpenCL but GPU doesn't support it
03-Sep-2014 12:45:09 [SETI@home] Application uses missing NVIDIA GPU
03-Sep-2014 12:45:09 [---] App version needs OpenCL but GPU doesn't support it
03-Sep-2014 12:45:09 [Milkyway@Home] Application uses missing NVIDIA GPU
03-Sep-2014 12:45:09 [---] App version needs OpenCL but GPU doesn't support it
03-Sep-2014 12:45:09 [Milkyway@Home] Application uses missing NVIDIA GPU
03-Sep-2014 12:45:09 [Milkyway@Home] Missing coprocessor for task 
ps_modfit_15_3s_130_wrap_const_1_1405680903_8114046_0

[many deleted]

03-Sep-2014 12:45:09 [SETI@home Beta Test] Missing coprocessor for task 
ap_30my13ac_B3_P0_00026_20140825_22705.wu_1
03-Sep-2014 12:45:09 [---] Host name: backer
03-Sep-2014 12:45:09 [---] Processor: 8 GenuineIntel Intel(R) Xeon(R) CPU 
E5-2603 v2 @ 1.80GHz [Family 6 Model 62 Stepping 4]
03-Sep-2014 12:45:09 [---] 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 xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl 
vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm arat epb xsaveopt pln pts 
dts tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
03-Sep-2014 12:45:09 [---] OS: Linux: 2.6.32-431.23.3.el6.x86_64
03-Sep-2014 12:45:09 [---] Memory: 126.00 GB physical, 128.00 GB virtual
03-Sep-2014 12:45:09 [---] Disk: 78.74 GB total, 56.99 GB free
03-Sep-2014 12:45:09 [---] Local time is UTC -7 hours
03-Sep-2014 12:45:09 [---] VirtualBox version: 4.1.34r95024
03-Sep-2014 12:45:09 [---] Config: use all coprocessors

[more deleted]

03-Sep-2014 12:45:09 [---] General prefs: from http://bam.boincstats.com/ (last 
modified 02-Jul-2014 09:28:55)
03-Sep-2014 12:45:09 [---] Host location: none
03-Sep-2014 12:45:09 [---] General prefs: using your defaults
03-Sep-2014 12:45:09 [---] Reading preferences

Re: [boinc_dev] BOINC can't detect OpenCL under CUDA 6.5 on linux

[Rom Walton]

'nvidia' subdirectory?

 

Is the nvidia subdirectory in the search path?

 

There should also be stuff in the /etc/OpenCL/vendors directory.

 

http://wiki.tiker.net/OpenCLHowTo

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Wednesday, September 03, 2014 4:30 PM
To: Rom Walton
Cc: boinc_dev@ssl.berkeley.edu; David Anderson
Subject: Re: BOINC can't detect OpenCL under CUDA 6.5 on linux

 

That shouldn't be it...  

% ls -l /usr/lib64/nvidia/libOpenCL.so*
lrwxrwxrwx 1 root root18 Sep  3 09:34 /usr/lib64/nvidia/libOpenCL.so - 
libOpenCL.so.1.0.0
lrwxrwxrwx 1 root root18 Sep  3 09:34 /usr/lib64/nvidia/libOpenCL.so.1 - 
libOpenCL.so.1.0.0
-rwxr-xr-x 1 root root 21712 Jul 31 20:10 /usr/lib64/nvidia/libOpenCL.so.1.0.0



 

On Wed, Sep 3, 2014 at 1:24 PM, Rom Walton r...@romwnet.org wrote:

No, maybe a case problem?

 

We are looking for libOpenCL.so.

 

Line 181 of client/gpu_opencl.cpp.

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Wednesday, September 03, 2014 4:21 PM


To: Rom Walton
Cc: boinc_dev@ssl.berkeley.edu; David Anderson
Subject: Re: BOINC can't detect OpenCL under CUDA 6.5 on linux

 

I don't think that's it.  The driver is definitely installed.  I can run OpenCL 
code and CUDA code from the command line.  BOINC runs CUDA apps fine.  BOINC 
just thinks it can't find libOpenCL.so.  Is BOINC using static paths for 
libOpenCL, rather than letting ld.so find it?

 

On Wed, Sep 3, 2014 at 1:16 PM, Rom Walton r...@romwnet.org wrote:

I found this post:

http://scientificlinuxforum.org/index.php?showtopic=2666

 

I suspect the packages have been reshuffled.

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Wednesday, September 03, 2014 4:11 PM
To: Rom Walton
Cc: boinc_dev@ssl.berkeley.edu; David Anderson
Subject: Re: BOINC can't detect OpenCL under CUDA 6.5 on linux

 

No, there is no libopencl in /usr/lib or /usr/lib64.  This machine has never 
has and devkit other than nvidia's installed on it.

 

On Wed, Sep 3, 2014 at 1:06 PM, Rom Walton r...@romwnet.org wrote:

Is there an libopencl.so in /usr/lib?

 

If so, was the ICD installed?

 

http://www.khronos.org/news/permalink/opencl-installable-client-driver-icd-loader

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Wednesday, September 03, 2014 4:00 PM
To: boinc_dev@ssl.berkeley.edu; David Anderson; Rom Walton
Subject: BOINC can't detect OpenCL under CUDA 6.5 on linux

 

Following installation of CUDA 6.5 on a RHEL6.5 derivative (Scientific Linux), 
BOINC can no longer detect OpenCL Libraries.

03-Sep-2014 12:45:09 [---] Starting BOINC client version 7.2.33 for 
x86_64-pc-linux-gnu
03-Sep-2014 12:45:09 [---] log flags: file_xfer, sched_ops, task, coproc_debug
03-Sep-2014 12:45:09 [---] Libraries: libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 
libidn/1.18 libssh2/1.4.2
03-Sep-2014 12:45:09 [---] Data directory: /var/lib/boinc
03-Sep-2014 12:45:09 [---] [coproc] launching child process at 
/usr/bin/boinc_client
03-Sep-2014 12:45:09 [---] [coproc] relative to directory /var/lib/boinc
03-Sep-2014 12:45:09 [---] [coproc] with data directory /var/lib/boinc
03-Sep-2014 12:45:09 [---] CUDA: NVIDIA GPU 0: GeForce GT 620 (driver version 
unknown, CUDA version 6.5, compute capability 2.1, 2048MB, 2032MB available, 
269 GFLOPS peak)
03-Sep-2014 12:45:09 [---] CUDA: NVIDIA GPU 1: GeForce GT 520 (driver version 
unknown, CUDA version 6.5, compute capability 2.1, 1023MB, 1012MB available, 
156 GFLOPS peak)
03-Sep-2014 12:45:09 [---] NVIDIA library reports 2 GPUs
03-Sep-2014 12:45:09 [---] No ATI library found
03-Sep-2014 12:45:09 [---] No OpenCL library found
03-Sep-2014 12:45:09 [---] App version needs OpenCL but GPU doesn't support it
03-Sep-2014 12:45:09 [SETI@home] Application uses missing NVIDIA GPU
03-Sep-2014 12:45:09 [---] App version needs OpenCL but GPU doesn't support it
03-Sep-2014 12:45:09 [Milkyway@Home] Application uses missing NVIDIA GPU
03-Sep-2014 12:45:09 [---] App version needs OpenCL but GPU doesn't support it
03-Sep-2014 12:45:09 [Milkyway@Home] Application uses missing NVIDIA GPU
03-Sep-2014 12:45:09 [Milkyway@Home] Missing coprocessor for task 
ps_modfit_15_3s_130_wrap_const_1_1405680903_8114046_0

[many deleted]

03-Sep-2014 12:45:09 [SETI@home Beta Test] Missing coprocessor for task 
ap_30my13ac_B3_P0_00026_20140825_22705.wu_1
03-Sep-2014 12:45:09 [---] Host name: backer
03-Sep-2014 12:45:09 [---] Processor: 8 GenuineIntel Intel(R) Xeon(R) CPU 
E5-2603 v2 @ 1.80GHz [Family 6 Model 62 Stepping 4]
03-Sep-2014 12:45:09 [---] 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 xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl 
vmx smx est

Re: [boinc_dev] BOINC can't detect OpenCL under CUDA 6.5 on linux

[Rom Walton]

is BOINC referencing a different dynamic linker than clinfo?

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Wednesday, September 03, 2014 5:52 PM
To: Rom Walton
Cc: boinc_dev@ssl.berkeley.edu; David Anderson
Subject: Re: BOINC can't detect OpenCL under CUDA 6.5 on linux

 

I don't even see any indication that boinc is attempting to open an opencl 
library before pronouncing that there isn't one.  stderrgpudetect.txt and 
stdoutgpudetect.txt are empty.

From an strace of boinc --detect_gpus here are the directories searched...

open(/lib64/tls/libOpenCL.so, O_RDONLY) = -1 ENOENT (No such file or 
directory)
open(/lib64/libOpenCL.so, O_RDONLY)   = -1 ENOENT (No such file or directory)
open(/usr/lib64/tls/libOpenCL.so, O_RDONLY) = -1 ENOENT (No such file or 
directory)
open(/usr/lib64/libOpenCL.so, O_RDONLY) = -1 ENOENT (No such file or 
directory)

From cat /etc/ld.so.conf.d/*.conf, here's what should have been searched...  
/usr/lib64/atlas
/usr/lib64/ctapi
/usr/lib/llvm
/usr/lib64/llvm
/usr/lib64/mysql
/usr/lib64/nvidia
/usr/lib/nvidia
/usr/lib64/qt-3.3/lib
/usr/lib/wine/
/usr/lib64/xulrunner
and the defaults (/usr/lib64,/lib64)

Adding /usr/lib64 to LD_LIBRARY_PATH solved the problem, but shouldn't have 
been necessary.

 

 

On Wed, Sep 3, 2014 at 1:59 PM, Eric J Korpela korp...@ssl.berkeley.edu wrote:

/usr/lib64/nvidia is in the search path through 
/etc/ld.so.conf.d/nvidia-lib64.conf (which contains /usr/lib64/nvidia )

And the /etc/OpenCL/vendors directory is there...
% cat /etc/OpenCL/vendors/nvidia.icd 
libnvidia-opencl.so.1

libnvidia-opencl.so.1 is also located in /usr/lib64/nvidia.

 

 

On Wed, Sep 3, 2014 at 1:34 PM, Rom Walton r...@romwnet.org wrote:

'nvidia' subdirectory?

 

Is the nvidia subdirectory in the search path?

 

There should also be stuff in the /etc/OpenCL/vendors directory.

 

http://wiki.tiker.net/OpenCLHowTo

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Wednesday, September 03, 2014 4:30 PM


To: Rom Walton
Cc: boinc_dev@ssl.berkeley.edu; David Anderson
Subject: Re: BOINC can't detect OpenCL under CUDA 6.5 on linux

 

That shouldn't be it...  

% ls -l /usr/lib64/nvidia/libOpenCL.so*
lrwxrwxrwx 1 root root18 Sep  3 09:34 /usr/lib64/nvidia/libOpenCL.so - 
libOpenCL.so.1.0.0
lrwxrwxrwx 1 root root18 Sep  3 09:34 /usr/lib64/nvidia/libOpenCL.so.1 - 
libOpenCL.so.1.0.0
-rwxr-xr-x 1 root root 21712 Jul 31 20:10 /usr/lib64/nvidia/libOpenCL.so.1.0.0

 

On Wed, Sep 3, 2014 at 1:24 PM, Rom Walton r...@romwnet.org wrote:

No, maybe a case problem?

 

We are looking for libOpenCL.so.

 

Line 181 of client/gpu_opencl.cpp.

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Wednesday, September 03, 2014 4:21 PM


To: Rom Walton
Cc: boinc_dev@ssl.berkeley.edu; David Anderson
Subject: Re: BOINC can't detect OpenCL under CUDA 6.5 on linux

 

I don't think that's it.  The driver is definitely installed.  I can run OpenCL 
code and CUDA code from the command line.  BOINC runs CUDA apps fine.  BOINC 
just thinks it can't find libOpenCL.so.  Is BOINC using static paths for 
libOpenCL, rather than letting ld.so find it?

 

On Wed, Sep 3, 2014 at 1:16 PM, Rom Walton r...@romwnet.org wrote:

I found this post:

http://scientificlinuxforum.org/index.php?showtopic=2666

 

I suspect the packages have been reshuffled.

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Wednesday, September 03, 2014 4:11 PM
To: Rom Walton
Cc: boinc_dev@ssl.berkeley.edu; David Anderson
Subject: Re: BOINC can't detect OpenCL under CUDA 6.5 on linux

 

No, there is no libopencl in /usr/lib or /usr/lib64.  This machine has never 
has and devkit other than nvidia's installed on it.

 

On Wed, Sep 3, 2014 at 1:06 PM, Rom Walton r...@romwnet.org wrote:

Is there an libopencl.so in /usr/lib?

 

If so, was the ICD installed?

 

http://www.khronos.org/news/permalink/opencl-installable-client-driver-icd-loader

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Wednesday, September 03, 2014 4:00 PM
To: boinc_dev@ssl.berkeley.edu; David Anderson; Rom Walton
Subject: BOINC can't detect OpenCL under CUDA 6.5 on linux

 

Following installation of CUDA 6.5 on a RHEL6.5 derivative (Scientific Linux), 
BOINC can no longer detect OpenCL Libraries.

03-Sep-2014 12:45:09 [---] Starting BOINC client version 7.2.33 for 
x86_64-pc-linux-gnu
03-Sep-2014 12:45:09 [---] log flags: file_xfer, sched_ops, task, coproc_debug
03-Sep-2014 12:45:09 [---] Libraries: libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 
libidn/1.18 libssh2/1.4.2
03-Sep-2014 12:45:09 [---] Data directory: /var/lib/boinc
03-Sep-2014 12:45:09 [---] [coproc] launching child process at 
/usr/bin/boinc_client
03-Sep-2014 12:45:09 [---] [coproc] relative to directory /var/lib/boinc
03-Sep-2014 12:45:09

Re: [boinc_dev] dir_dev redefined error.

[Rom Walton]

Should be fixed now.

 

- Rom

 

From: Gianfranco Costamagna [mailto:costamagnagianfra...@yahoo.it] 
Sent: Tuesday, August 26, 2014 2:44 AM
To: boinc_dev@ssl berkeley. edu; Rom Walton
Subject: dir_dev redefined error.

 

Hi boinc developers,
the latest boinc doesn't build anymore on linux because of a dir_dev redefined 
struct

http://boinc.berkeley.edu/gitweb/?p=boinc-v2.git;a=commitdiff;h=bfae1032e5c1ac73f2d8d92f93d8383a6cee

can anybody please fix that? seems that a typedef should fix the issue,

many thanks

Gianfranco

Sent from Yahoo Mail on Android 
https://uk.overview.mail.yahoo.com/mobile/?.src=Android 

 

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Feature request: discovery installed version of BOINC

[Rom Walton]

I will go ahead and modify the installer to put the version into the registry.

You can also execute:
boinc --version

That will return the version number and platform of the installed client.

All the client software should be using the same version number.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Richard Haselgrove
Sent: Thursday, August 07, 2014 12:42 PM
To: BOINC Dev MailingList
Subject: [boinc_dev] Feature request: discovery installed version of BOINC

My request is for the Windows operating system, but it may be applicable to 
other OSs as well.

Context: I am writing an updated installation program to deliver anonymous 
platform applications to volunteers' BOINC installations. Each time we release 
an updated version, we observe something of the order of 30,000 user downloads 
- we suspect the number of hosts involved is significantly higher, and we don't 
track all mirror site download numbers.

I am being pressured to provide selective installation on the basis of the 
BOINC version and mode (service/user) encountered. I can access program and 
data locations by querying the registry for INSTALLDIR and DATADIR 
respectively, and I can also check for the presence of a BOINC service (whether 
it is running or stopped).

If BOINC is running, I could query the client with an RPC, or - less elegantly, 
but simpler - pipe the response to a boinccmd -V into a file and parse that. 
But where is the version number of a stopped instance?

For the future, could it be added to HKEY_LOCAL_MACHINE\SOFTWARE\Space Sciences 
Laboratory, U.C. Berkeley\BOINC Setup by your installer, please?

And if anybody could answer the 'stopped instance' question in the near future, 
I'd be grateful.

[later: boinccmd reports:

C:\BOINCboinccmd -V
boinccmd,  built from BOINC 7.2.42

Is that really the running client version, as the documentations says, or its 
own build number, as printed?] ___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Feature request: Preference for graphics apps or fastapps.

[Rom Walton]

What overhead is left for the regular app with regards to graphics?

I thought all the major overhead is in the graphics app itself.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
Eric J Korpela
Sent: Tuesday, August 05, 2014 11:49 AM
To: boinc_dev@ssl.berkeley.edu; David Anderson
Subject: [boinc_dev] Feature request: Preference for graphics apps or
fastapps.

Hi David,

Starting with Astropulse 7 we're going to have both a standard app with
graphics code for the screen saver and a faster version without the
graphics overhead.  If I just release them as is, the non-graphical
version will quickly become dominant.

There are still people out there who like to see the screensaver
graphics.
I haven't come up with a way (apart from custom code) to allow people to
choose to get a slower version with graphics over a faster version
without.

Any ideas on whether such a thing could be done?

--
Eric
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Building Boinc wrapper for android + Advises for GPGPU computing on Android with Boinc

[Rom Walton]

Our servers are going to be going down before too long.

When they come back up I'll post an android version of wrapper to the
BOINC web site.

OpenCL isn't supported on all Android devices.  We are modifying BOINC
so that it can give us a better understanding of OpenCL support within
the Android community, but it is still a little ways out.

I don't know anything about RenderScript.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
fabien monnier
Sent: Wednesday, July 16, 2014 4:39 PM
To: Boinc_Dev mailing list
Subject: [boinc_dev] Building Boinc wrapper for android + Advises for
GPGPU computing on Android with Boinc

Dear Boinc Dev community,
First thank you to have created this useful platform.

I am setting up my own Boinc server to resolve some scientific problems.
I want to target Android only devices for some reasons.

It is a little complicated to rewrite my application with Boic_API so I
would use my current binary that read a file.in file as a data input and
write the result in a file.out file as a data output.

I have some difficulties to get the android wrapper built.
Can someone help me ?

Actually I use pthread to boost my application, as my algorithms can be
spread to an unlimited number of parallel compute unit, I would extend
the computation to the GPU of Android devices.
Does someone have an idea of the best way to do it ? Should I write a
binary with RenderScript or OpenCL ? What are your recommendations ? Is
there any other way ?

Thank you for your time.

--
Best regards,
Fabien Monnier
Washington , District of Columbia, USA
fabien.monnier (Skype)
monnier.fab...@gmail.com
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Please fix this bug in simple view, patch attached

[Rom Walton]

Gainfranco,

I've committed the patch.  I'm sorry I hit enter a little too quickly and 
didn't attached your name to the check-in note though.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of 
Gianfranco Costamagna
Sent: Friday, June 27, 2014 5:14 AM
To: boinc_dev@ssl.berkeley.edu; David Anderson
Subject: [boinc_dev] Please fix this bug in simple view, patch attached

Simple view is not coherent with the advanced one, and on linux we _cannot_ 
close the window in any way (kill works of course)

this is the patch
diff --git a/clientgui/sg_BoincSimpleFrame.cpp 
b/clientgui/sg_BoincSimpleFrame.cpp
index 22aa497..9fceeae 100755
--- a/clientgui/sg_BoincSimpleFrame.cpp
+++ b/clientgui/sg_BoincSimpleFrame.cpp
@@ -127,6 +127,22 @@ CSimpleFrame::CSimpleFrame(wxString title, wxIconBundle* 
icons, wxPoint position
 strMenuDescription
 );
 
+    strMenuDescription.Printf(
+    _(Exit %s),
+    pSkinAdvanced-GetApplicationName().c_str()
+    );
+
+    strMenuName.Printf(
+    _(Exit %s),
+    pSkinAdvanced-GetApplicationName().c_str()
+    );
+
+    menuFile-Append(
+    wxID_EXIT,
+    strMenuName,
+    strMenuDescription
+    );
+
 #ifdef __WXMAC__
 menuFile-Append(
 wxID_PREFERENCES



https://bugs.launchpad.net/ubuntu/+source/boinc/+bug/1332955


thanks,

Gianfranco
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] failed to compile 7.3.19 on fedora 20

[Rom Walton]

That was probably me.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
Eric J Korpela
Sent: Tuesday, June 17, 2014 1:09 PM
To: Juha
Cc: BOINC Developers Mailing List
Subject: Re: [boinc_dev] failed to compile 7.3.19 on fedora 20

Who put pkg-config calls in the Makefiles?  That's awful, and is now on
my list of things to fix.


On Tue, Jun 17, 2014 at 9:49 AM, Juha juha.sointus...@gmail.com wrote:

 On 17 June 2014 19:45, Juha juha.sointus...@gmail.com wrote:

  On 17 June 2014 04:05, Han Pingtian ha...@linux.vnet.ibm.com
wrote:
 
  On Mon, Jun 16, 2014 at 11:46:14PM +0300, Juha wrote:
   On 16 June 2014 07:45, Han Pingtian ha...@linux.vnet.ibm.com
wrote:
  
On Thu, Jun 12, 2014 at 06:39:29PM +0300, Juha wrote:
 On 10 June 2014 16:20, Han Pingtian 
 ha...@linux.vnet.ibm.com
  wrote:

  I have installed wxGTK3 on this system, the 
  /usr/include/wx-3.0/wx/defs.h comes from wxGTK3-devel. And 
  the /usr/include/gtk-2.0/gdk/gdktypes.h comes from 
  gtk2-devel.  I'm
  using
  './configure --disable-server ' to configure it. Not sure 
  what's
  wrong,
  please advise. Thanks!
 

 In Fedora 20 wxWidgets 3 is configured to use GTK+ 3 backend 
 and
  you are
 trying to compile Manager with GTK+ 2. That's not going to 
 work,
 you
can't
 mix GTK+ versions like that.

   
I think this is what boinc wants to do on the Fedora 20 system,

not me ... Boinc is going to use wx 3 and gtk+ 2 together here,

not sure
  if
I was doing something wrong.
   
  
   Do you have gtk3-devel installed? If not, install it.
 
  I had gtk3-devel-3.10.9-1.fc20.x86_64 installed, looks like this 
  isn't the reason of this problem ...
 
 
  I was going to tell you to uninstall gtk2-devel but that's not going

  to work.
 
  Open clientgui/Makefile.am and replace every gtk+-2.0 with
gtk+-3.0.
  There should be three of them near the end of the file.
 
  This isn't a proper fix but should get you at least a bit further.
 

 After editing Makefile.am run configure. You may need to run 
 _autosetup before configure, I never remember which files were input 
 files for which programs.

 -Juha
 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
 To unsubscribe, visit the above URL and (near bottom of page) enter 
 your email address.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] failed to compile 7.3.19 on fedora 20

[Rom Walton]

It looks like the libnotify/gtk dev packages is missing.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Han 
Pingtian
Sent: Tuesday, June 10, 2014 9:21 AM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] failed to compile 7.3.19 on fedora 20

Hey there,

I'm trying to compile boinc from source git on a fedora 20 system, but it 
failed with some error messages:

... ...
  CXX  boincmgr-taskbarex.o
In file included from /usr/include/wx-3.0/wx/wx.h:14:0,
 from ./stdwx.h:49,
 from gtk/taskbarex.cpp:20:
/usr/include/wx-3.0/wx/defs.h:3394:31: error: conflicting declaration ‘typedef 
struct _GdkWindow GdkWindow’
 typedef struct _GdkWindow GdkWindow;
   ^
In file included from /usr/include/gtk-2.0/gdk/gdkscreen.h:32:0,
 from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31,
 from /usr/include/gtk-2.0/gdk/gdk.h:32,
 from /usr/include/gtk-2.0/gtk/gtk.h:32,
 from gtk/taskbarex.cpp:17:
/usr/include/gtk-2.0/gdk/gdktypes.h:114:39: error: ‘GdkWindow’ has a previous 
declaration as ‘typedef struct _GdkDrawable GdkWindow’
 typedef struct _GdkDrawable   GdkWindow;
   ^ In file included from 
/usr/include/wx-3.0/wx/cursor.h:69:0,
 from /usr/include/wx-3.0/wx/event.h:21,
 from /usr/include/wx-3.0/wx/wx.h:24,
 from ./stdwx.h:49,
 from gtk/taskbarex.cpp:20:
/usr/include/wx-3.0/wx/utils.h:603:52: warning: redundant redeclaration of 
‘void wxQsort(void*, size_t, size_t, wxSortCallback, const void*)’ in same 
scope [-Wredundant-decls]
   const void* user_data);
^ In file included from 
/usr/include/wx-3.0/wx/list.h:34:0,
 from /usr/include/wx-3.0/wx/wx.h:17,
 from ./stdwx.h:49,
 from gtk/taskbarex.cpp:20:
/usr/include/wx-3.0/wx/vector.h:44:23: warning: previous declaration of ‘void 
wxQsort(void*, size_t, size_t, wxSortCallback, const void*)’ 
[-Wredundant-decls]  WXDLLIMPEXP_BASE void wxQsort(void* pbase, size_t 
total_elems,
   ^
gtk/taskbarex.cpp:77:5: warning: unused parameter ‘notification’ 
[-Wunused-parameter]
 status_icon_notification_actions(NotifyNotification* notification, gchar 
*action, wxTaskBarIconEx* taskBarIcon)
 ^
gtk/taskbarex.cpp:85:5: warning: unused parameter ‘notification’ 
[-Wunused-parameter]
 status_icon_notification_closed(NotifyNotification* notification, 
wxTaskBarIconEx* taskBarIcon)
 ^
make[2]: *** [boincmgr-taskbarex.o] Error 1
make[2]: Leaving directory `/home/hpt/temp/boinc/clientgui'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/hpt/temp/boinc'
make: *** [all] Error 2

I have installed wxGTK3 on this system, the /usr/include/wx-3.0/wx/defs.h comes 
from wxGTK3-devel. And the /usr/include/gtk-2.0/gdk/gdktypes.h comes from 
gtk2-devel.  I'm using './configure --disable-server ' to configure it. Not 
sure what's wrong, please advise. Thanks!

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] failed to compile 7.3.19 on fedora 20

[Rom Walton]

There are a few optional packages:
xcb-atom
xcb-util

I'm not really sure what the package name is these days.  The X screensaver and 
X keyboard/mouse stuff has been re-factored over the years and the package 
names change.

- Rom

-Original Message-
From: Han Pingtian [mailto:ha...@linux.vnet.ibm.com] 
Sent: Tuesday, June 10, 2014 9:11 PM
To: Rom Walton; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] failed to compile 7.3.19 on fedora 20

On Tue, Jun 10, 2014 at 12:14:43PM -0400, Rom Walton wrote:
 It looks like the libnotify/gtk dev packages is missing.
 
It looks like I had installed gtk2-devel-2.24.22-2.fc20.x86_64 and 
libnotify-devel-0.7.6-1.fc20.x86_64. Any other packages I should also install?

Thanks.
 - Rom
 
 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf 
 Of Han Pingtian
 Sent: Tuesday, June 10, 2014 9:21 AM
 To: boinc_dev@ssl.berkeley.edu
 Subject: [boinc_dev] failed to compile 7.3.19 on fedora 20
 
 Hey there,
 
 I'm trying to compile boinc from source git on a fedora 20 system, but it 
 failed with some error messages:
 
 ... ...
   CXX  boincmgr-taskbarex.o
 In file included from /usr/include/wx-3.0/wx/wx.h:14:0,
  from ./stdwx.h:49,
  from gtk/taskbarex.cpp:20:
 /usr/include/wx-3.0/wx/defs.h:3394:31: error: conflicting declaration 
 ‘typedef struct _GdkWindow GdkWindow’
  typedef struct _GdkWindow GdkWindow;
^
 In file included from /usr/include/gtk-2.0/gdk/gdkscreen.h:32:0,
  from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31,
  from /usr/include/gtk-2.0/gdk/gdk.h:32,
  from /usr/include/gtk-2.0/gtk/gtk.h:32,
  from gtk/taskbarex.cpp:17:
 /usr/include/gtk-2.0/gdk/gdktypes.h:114:39: error: ‘GdkWindow’ has a previous 
 declaration as ‘typedef struct _GdkDrawable GdkWindow’
  typedef struct _GdkDrawable   GdkWindow;
^ In file included from 
 /usr/include/wx-3.0/wx/cursor.h:69:0,
  from /usr/include/wx-3.0/wx/event.h:21,
  from /usr/include/wx-3.0/wx/wx.h:24,
  from ./stdwx.h:49,
  from gtk/taskbarex.cpp:20:
 /usr/include/wx-3.0/wx/utils.h:603:52: warning: redundant redeclaration of 
 ‘void wxQsort(void*, size_t, size_t, wxSortCallback, const void*)’ in same 
 scope [-Wredundant-decls]
const void* user_data);
 ^ In file included from 
 /usr/include/wx-3.0/wx/list.h:34:0,
  from /usr/include/wx-3.0/wx/wx.h:17,
  from ./stdwx.h:49,
  from gtk/taskbarex.cpp:20:
 /usr/include/wx-3.0/wx/vector.h:44:23: warning: previous declaration of ‘void 
 wxQsort(void*, size_t, size_t, wxSortCallback, const void*)’ 
 [-Wredundant-decls]  WXDLLIMPEXP_BASE void wxQsort(void* pbase, size_t 
 total_elems,
^
 gtk/taskbarex.cpp:77:5: warning: unused parameter ‘notification’ 
 [-Wunused-parameter]
  status_icon_notification_actions(NotifyNotification* notification, gchar 
 *action, wxTaskBarIconEx* taskBarIcon)
  ^
 gtk/taskbarex.cpp:85:5: warning: unused parameter ‘notification’ 
 [-Wunused-parameter]
  status_icon_notification_closed(NotifyNotification* notification, 
 wxTaskBarIconEx* taskBarIcon)
  ^
 make[2]: *** [boincmgr-taskbarex.o] Error 1
 make[2]: Leaving directory `/home/hpt/temp/boinc/clientgui'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory `/home/hpt/temp/boinc'
 make: *** [all] Error 2
 
 I have installed wxGTK3 on this system, the /usr/include/wx-3.0/wx/defs.h 
 comes from wxGTK3-devel. And the /usr/include/gtk-2.0/gdk/gdktypes.h comes 
 from gtk2-devel.  I'm using './configure --disable-server ' to configure it. 
 Not sure what's wrong, please advise. Thanks!
 
 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
 To unsubscribe, visit the above URL and (near bottom of page) enter 
 your email address.

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

[Rom Walton]

I think we are on the same page for the most part.

 

The stuff that is important to projects (lib and api) can be built and used by 
whatever the toolset (compiler/linker) is used by the project.

 

- Rom

 

From: Raistmer the Sorcerer [mailto:raist...@mail.ru] 
Sent: Friday, May 23, 2014 2:11 AM
To: Rom Walton
Cc: BOINC Dev Mailing List; Eric J Korpela
Subject: Re[2]: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

 

Express edition maybe enough for compiling BOINC libs (but again, better if 
they would be pre-compiled) but not enough for developing GPU science 
application, for example.
I would say it's just general principle - not to restrict area of applicability 
w/o real need. 
I know, big companies like AMD or NV do such with easy dropping support with M$ 
fashion but this is not the way to mimic actually. 
It's against initial BOINC spirit - to use everything spare. Think about it, 
maybe no more pragmatic reasons needed?



Thu, 22 May 2014 20:19:54 -0400 от Rom Walton r...@romwnet.org:

Well, the AVX detection code is only used in the client software and only 
needed on Windows.  Is there a reason to be backwards compatible with VS 2008, 
if the recent versions of express edition are free?

 

/lib and /api do not need the additional stuff and should compile fine with all 
the compilers in use.  

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Thursday, May 22, 2014 7:56 PM
To: Rom Walton
Cc: Raistmer the Sorcerer; BOINC Dev Mailing List
Subject: Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

 

Coming from a world where no two compilers are alike, I have some experience 
with such problems.

#ifndef HAVE__XGETBV  /* set by autoconf or in boinc_win.h */

static unsigned long long _xgetbv(unsigned int index){

  unsigned int A, D;

#ifdef __GNUC__

  #ifdef ASM_SUPPORTS_XGETBV  /* gcc version = 4.4, but better tested by 
autoconf */

  __asm__ __volatile__(xgetbv : =a(A), =d(D) : c(index));

  #else

  __asm__ __volatile__(.byte 0x0f, 0x01, 0xd0: =a(A), =d(D) : 
c(index));

  #endif

#elif defined(_MSC_VER) 
  #ifdef _M_IX86 

  __asm {
   mov ecx,index

   __emit 00fh
   __emit 001h
   __emit 0d0h

   mov D,edx

   mov A,eax

   }

  #elif defined(_M_AMD64)

  // damn Microsoft for not having inline assembler in 64-bit code

  // so this is in an NASM compiled library

  return asm_xgetbv(index);

  #endif
  return ((unsigned long long)D  32) | A;

#else 

  return 0;

#endif

}

#endif

 

On Thu, May 22, 2014 at 3:52 PM, Rom Walton r...@romwnet.org 
https://e.mail.ru/compose/?mailto=mailto%3ar...@romwnet.org  wrote:

I meant to say not supported.

- Rom


-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu 
https://e.mail.ru/compose/?mailto=mailto%3aboinc_dev%2dboun...@ssl.berkeley.edu
 ] On Behalf Of Rom Walton
Sent: Thursday, May 22, 2014 6:49 PM
To: Raistmer the Sorcerer
Cc: BOINC Dev Mailing List

Subject: Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

It is my understanding that the '_xgetbv' intrinsic is supported in VS2008.



- Rom



From: Raistmer the Sorcerer [mailto:raist...@mail.ru 
https://e.mail.ru/compose/?mailto=mailto%3araist...@mail.ru ]
Sent: Thursday, May 22, 2014 6:46 PM
To: Rom Walton
Cc: BOINC Dev Mailing List; Jord van der Elst
Subject: Re[2]: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010



That is, this code will do wrong being compiled with VS2008?

int cpuInfo[4];

__cpuid(cpuInfo, 1);



bool osUsesXSAVE_XRSTORE = cpuInfo[2]  (1  27) || false;

bool cpuAVXSuport = cpuInfo[2]  (1  28) || false;



if (osUsesXSAVE_XRSTORE  cpuAVXSuport)

{

// Check if the OS will save the YMM registers

unsigned long long xcrFeatureMask = _xgetbv(_XCR_XFEATURE_ENABLED_MASK);

avxSupported = (xcrFeatureMask  0x6) || false;

}

__cpuid() will not report correctly?




Thu, 22 May 2014 17:47:28 -0400 от Rom Walton r...@romwnet.org 
https://e.mail.ru/compose/?mailto=mailto%3ar...@romwnet.org :

Demand for AVX detection and support:

http://insufficientlycomplicated.wordpress.com/2011/11/07/detecting-intel-advanced-vector-extensions-avx-in-visual-studio/



- Rom



From: Raistmer the Sorcerer [mailto:raist...@mail.ru 
https://e.mail.ru/compose/?mailto=mailto%3araist...@mail.ru ]
Sent: Thursday, May 22, 2014 5:19 PM
To: Jord van der Elst
Cc: BOINC Dev Mailing List; Rom Walton
Subject: Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010



What reasons behind of this version shift?
What unresolvable problems with VS2008 ?



Thu, 22 May 2014 16:54:15 +0200 от Jord van der Elst els...@gmail.com 
https://e.mail.ru/compose/?mailto=mailto%3aels...@gmail.com  
https://e.mail.ru/compose/?mailto=mailto%3aels

Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

[Rom Walton]

Over the last few months I've been pruning the source tree of legacy Windows 
code.  1200+ lines so far.

 

I suspect that BOINC will not even compile on VS 2005 anymore.  I removed a 
bunch of #defines from hostinfo_win.cpp which are present in the VS 2010 
Windows SDK but not in the VS 2005 Windows SDK.  There were also a bunch of 
places where we were doing a LoadLibrary/GetProcAddress instead of calling the 
API directly so that we could run on older versions of Windows.  I've been 
cleaning that up as well.

 

The commit in question just modified a shell script used by one of VS's 
post-build events to update DLLs in the build directory.  I also use the same 
script to validate/upload symbol files and code sign the stuff we release.

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Thursday, May 22, 2014 11:19 AM
To: Jord van der Elst
Cc: Rom Walton; BOINC Dev Mailing List
Subject: Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

 

Nothing quite like spending a few hundred dollars to compile free software, is 
there?  It's not clear from Rom's message whether the incompatibility is in the 
project files (or that it's too much work to maintain the old project files), 
or whether its a newer visual C++ version that is necessary.  If it's just the 
maintenence of old project files and required libraries, a volunteer could do 
it.

As a means of relaxing, I've been slowly working on cross compiling with 
mingw32/64 on Linux and Cygwin, but, of course, there's no clear indications of 
what features are necessary in wxWidgets to compile boincmgr.  At least I have 
the libraries and client compiling.  Of course, MSVC++ happily and silently 
compiles things that aren't legal on gcc (like implicit conversions from string 
to char *, what's that about?), so there are a hunderd things to fix to get it 
working.

 

On Thu, May 22, 2014 at 7:54 AM, Jord van der Elst els...@gmail.com wrote:

WINBUILD: Minimum supported VS is now VS 2010

So then that means that someone has to retest and rewrite all and everything of
http://boinc.berkeley.edu/trac/wiki/CompileClient#Windows as the
compilers the page is written for are VS 2005 (Express) and 2008.

And what VS, full VS or is Express also an option?
Or is Express still not capable of compiling 64bit applications?

Thanks,

-- Jord van der Elst.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

 

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

[Rom Walton]

The pre-built stuff we use and maintain internally is published here:
http://boinc.berkeley.edu/gitweb/?p=boinc_depends_win_vs2010.git;a=summary

VS 2010 with Windows SDK and a directory layout like:
src/boinc
src/boinc_depends_win_vs2010

Should be all you need to build BOINC on your machine.

- Rom

-Original Message-
From: Jord van der Elst [mailto:els...@gmail.com] 
Sent: Thursday, May 22, 2014 12:14 PM
To: Rom Walton
Cc: Eric J Korpela; BOINC Dev Mailing List
Subject: Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

Okay,

So the old CompileClient page is really out of date by now. Do we want a new 
one, or is it better that Windows users use as much as possible the official 
recommended version, and that those that like to live dangerously can use an 
exotic like a development version?
If we want a new CompileClient page for Windows, I don't mind writing it. I'll 
just need pointers, such as what are the requirements these days, which version 
of VS2010 at minimum, which service pack, which SDK?
Do we need pre-built OpenSSL, Zlib, LibCurl, SQLite3, and other libraries, or 
are they only in self-built versions available?
WxWidgets is 3.0, but what else?

Rom and I wrote the original CC page for Windows, and I know it was broken 
within months of us putting in the final dot, so I assume that's going to be 
the case now as well.
Perhaps it is better that Windows users use the Berkeley built versions... :-)

-- Jord van der Elst.


On Thu, May 22, 2014 at 6:00 PM, Rom Walton r...@romwnet.org wrote:
 Over the last few months I've been pruning the source tree of legacy 
 Windows code.  1200+ lines so far.



 I suspect that BOINC will not even compile on VS 2005 anymore.  I 
 removed a bunch of #defines from hostinfo_win.cpp which are present in 
 the VS 2010 Windows SDK but not in the VS 2005 Windows SDK.  There 
 were also a bunch of places where we were doing a 
 LoadLibrary/GetProcAddress instead of calling the API directly so that 
 we could run on older versions of Windows.  I've been cleaning that up as 
 well.



 The commit in question just modified a shell script used by one of 
 VS's post-build events to update DLLs in the build directory.  I also 
 use the same script to validate/upload symbol files and code sign the 
 stuff we release.



 - Rom



 From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J 
 Korpela


 Sent: Thursday, May 22, 2014 11:19 AM
 To: Jord van der Elst
 Cc: Rom Walton; BOINC Dev Mailing List
 Subject: Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010



 Nothing quite like spending a few hundred dollars to compile free 
 software, is there?  It's not clear from Rom's message whether the 
 incompatibility is in the project files (or that it's too much work to 
 maintain the old project files), or whether its a newer visual C++ 
 version that is necessary.  If it's just the maintenence of old 
 project files and required libraries, a volunteer could do it.

 As a means of relaxing, I've been slowly working on cross compiling 
 with
 mingw32/64 on Linux and Cygwin, but, of course, there's no clear 
 indications of what features are necessary in wxWidgets to compile 
 boincmgr.  At least I have the libraries and client compiling.  Of 
 course, MSVC++ happily and silently compiles things that aren't legal 
 on gcc (like implicit conversions from string to char *, what's that 
 about?), so there are a hunderd things to fix to get it working.



 On Thu, May 22, 2014 at 7:54 AM, Jord van der Elst els...@gmail.com wrote:

 WINBUILD: Minimum supported VS is now VS 2010

 So then that means that someone has to retest and rewrite all and 
 everything of 
 http://boinc.berkeley.edu/trac/wiki/CompileClient#Windows as the 
 compilers the page is written for are VS 2005 (Express) and 2008.

 And what VS, full VS or is Express also an option?
 Or is Express still not capable of compiling 64bit applications?

 Thanks,

 -- Jord van der Elst.
 ___
 boinc_dev mailing list
 boinc_dev@ssl.berkeley.edu
 http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
 To unsubscribe, visit the above URL and (near bottom of page) enter 
 your email address.


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

[Rom Walton]

It is my understanding that the '_xgetbv' intrinsic is supported in VS2008.

 

- Rom

 

From: Raistmer the Sorcerer [mailto:raist...@mail.ru] 
Sent: Thursday, May 22, 2014 6:46 PM
To: Rom Walton
Cc: BOINC Dev Mailing List; Jord van der Elst
Subject: Re[2]: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

 

That is, this code will do wrong being compiled with VS2008?

int cpuInfo[4];

__cpuid(cpuInfo, 1);

 

bool osUsesXSAVE_XRSTORE = cpuInfo[2]  (1  27) || false;

bool cpuAVXSuport = cpuInfo[2]  (1  28) || false;

 

if (osUsesXSAVE_XRSTORE  cpuAVXSuport)

{

// Check if the OS will save the YMM registers

unsigned long long xcrFeatureMask = _xgetbv(_XCR_XFEATURE_ENABLED_MASK);

avxSupported = (xcrFeatureMask  0x6) || false;

}

__cpuid() will not report correctly?




Thu, 22 May 2014 17:47:28 -0400 от Rom Walton r...@romwnet.org:

Demand for AVX detection and support:

http://insufficientlycomplicated.wordpress.com/2011/11/07/detecting-intel-advanced-vector-extensions-avx-in-visual-studio/

 

- Rom

 

From: Raistmer the Sorcerer [mailto:raist...@mail.ru] 
Sent: Thursday, May 22, 2014 5:19 PM
To: Jord van der Elst
Cc: BOINC Dev Mailing List; Rom Walton
Subject: Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

 

What reasons behind of this version shift?
What unresolvable problems with VS2008 ?



Thu, 22 May 2014 16:54:15 +0200 от Jord van der Elst els...@gmail.com 
https://e.mail.ru/compose/?mailto=mailto%3aels...@gmail.com :

WINBUILD: Minimum supported VS is now VS 2010

So then that means that someone has to retest and rewrite all and everything of
http://boinc.berkeley.edu/trac/wiki/CompileClient#Windows as the
compilers the page is written for are VS 2005 (Express) and 2008.

And what VS, full VS or is Express also an option?
Or is Express still not capable of compiling 64bit applications?

Thanks,

-- Jord van der Elst.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu 
https://e.mail.ru/compose?To=boinc_dev@ssl.berkeley.edu 
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

 

 

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

[Rom Walton]

I meant to say not supported.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Rom 
Walton
Sent: Thursday, May 22, 2014 6:49 PM
To: Raistmer the Sorcerer
Cc: BOINC Dev Mailing List
Subject: Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

It is my understanding that the '_xgetbv' intrinsic is supported in VS2008.

 

- Rom

 

From: Raistmer the Sorcerer [mailto:raist...@mail.ru]
Sent: Thursday, May 22, 2014 6:46 PM
To: Rom Walton
Cc: BOINC Dev Mailing List; Jord van der Elst
Subject: Re[2]: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

 

That is, this code will do wrong being compiled with VS2008?

int cpuInfo[4];

__cpuid(cpuInfo, 1);

 

bool osUsesXSAVE_XRSTORE = cpuInfo[2]  (1  27) || false;

bool cpuAVXSuport = cpuInfo[2]  (1  28) || false;

 

if (osUsesXSAVE_XRSTORE  cpuAVXSuport)

{

// Check if the OS will save the YMM registers

unsigned long long xcrFeatureMask = _xgetbv(_XCR_XFEATURE_ENABLED_MASK);

avxSupported = (xcrFeatureMask  0x6) || false;

}

__cpuid() will not report correctly?




Thu, 22 May 2014 17:47:28 -0400 от Rom Walton r...@romwnet.org:

Demand for AVX detection and support:

http://insufficientlycomplicated.wordpress.com/2011/11/07/detecting-intel-advanced-vector-extensions-avx-in-visual-studio/

 

- Rom

 

From: Raistmer the Sorcerer [mailto:raist...@mail.ru]
Sent: Thursday, May 22, 2014 5:19 PM
To: Jord van der Elst
Cc: BOINC Dev Mailing List; Rom Walton
Subject: Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

 

What reasons behind of this version shift?
What unresolvable problems with VS2008 ?



Thu, 22 May 2014 16:54:15 +0200 от Jord van der Elst els...@gmail.com 
https://e.mail.ru/compose/?mailto=mailto%3aels...@gmail.com :

WINBUILD: Minimum supported VS is now VS 2010

So then that means that someone has to retest and rewrite all and everything of 
http://boinc.berkeley.edu/trac/wiki/CompileClient#Windows as the compilers the 
page is written for are VS 2005 (Express) and 2008.

And what VS, full VS or is Express also an option?
Or is Express still not capable of compiling 64bit applications?

Thanks,

-- Jord van der Elst.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu 
https://e.mail.ru/compose?To=boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

 

 

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

[Rom Walton]

Well, the AVX detection code is only used in the client software and only 
needed on Windows.  Is there a reason to be backwards compatible with VS 2008, 
if the recent versions of express edition are free?

 

/lib and /api do not need the additional stuff and should compile fine with all 
the compilers in use.  

 

- Rom

 

From: korp...@gmail.com [mailto:korp...@gmail.com] On Behalf Of Eric J Korpela
Sent: Thursday, May 22, 2014 7:56 PM
To: Rom Walton
Cc: Raistmer the Sorcerer; BOINC Dev Mailing List
Subject: Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

 

Coming from a world where no two compilers are alike, I have some experience 
with such problems.

#ifndef HAVE__XGETBV  /* set by autoconf or in boinc_win.h */

static unsigned long long _xgetbv(unsigned int index){

  unsigned int A, D;

#ifdef __GNUC__

  #ifdef ASM_SUPPORTS_XGETBV  /* gcc version = 4.4, but better tested by 
autoconf */

  __asm__ __volatile__(xgetbv : =a(A), =d(D) : c(index));

  #else

  __asm__ __volatile__(.byte 0x0f, 0x01, 0xd0: =a(A), =d(D) : 
c(index));

  #endif

#elif defined(_MSC_VER) 
  #ifdef _M_IX86 

  __asm {
   mov ecx,index

   __emit 00fh
   __emit 001h
   __emit 0d0h

   mov D,edx

   mov A,eax

   }

  #elif defined(_M_AMD64)

  // damn Microsoft for not having inline assembler in 64-bit code

  // so this is in an NASM compiled library

  return asm_xgetbv(index);

  #endif
  return ((unsigned long long)D  32) | A;

#else 

  return 0;

#endif

}

#endif

 

On Thu, May 22, 2014 at 3:52 PM, Rom Walton r...@romwnet.org wrote:

I meant to say not supported.

- Rom


-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Rom 
Walton
Sent: Thursday, May 22, 2014 6:49 PM
To: Raistmer the Sorcerer
Cc: BOINC Dev Mailing List

Subject: Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010

It is my understanding that the '_xgetbv' intrinsic is supported in VS2008.



- Rom



From: Raistmer the Sorcerer [mailto:raist...@mail.ru]
Sent: Thursday, May 22, 2014 6:46 PM
To: Rom Walton
Cc: BOINC Dev Mailing List; Jord van der Elst
Subject: Re[2]: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010



That is, this code will do wrong being compiled with VS2008?

int cpuInfo[4];

__cpuid(cpuInfo, 1);



bool osUsesXSAVE_XRSTORE = cpuInfo[2]  (1  27) || false;

bool cpuAVXSuport = cpuInfo[2]  (1  28) || false;



if (osUsesXSAVE_XRSTORE  cpuAVXSuport)

{

// Check if the OS will save the YMM registers

unsigned long long xcrFeatureMask = _xgetbv(_XCR_XFEATURE_ENABLED_MASK);

avxSupported = (xcrFeatureMask  0x6) || false;

}

__cpuid() will not report correctly?




Thu, 22 May 2014 17:47:28 -0400 от Rom Walton r...@romwnet.org:

Demand for AVX detection and support:

http://insufficientlycomplicated.wordpress.com/2011/11/07/detecting-intel-advanced-vector-extensions-avx-in-visual-studio/



- Rom



From: Raistmer the Sorcerer [mailto:raist...@mail.ru]
Sent: Thursday, May 22, 2014 5:19 PM
To: Jord van der Elst
Cc: BOINC Dev Mailing List; Rom Walton
Subject: Re: [boinc_dev] WINBUILD: Minimum supported VS is now VS 2010



What reasons behind of this version shift?
What unresolvable problems with VS2008 ?



Thu, 22 May 2014 16:54:15 +0200 от Jord van der Elst els...@gmail.com 
https://e.mail.ru/compose/?mailto=mailto%3aels...@gmail.com :

WINBUILD: Minimum supported VS is now VS 2010

So then that means that someone has to retest and rewrite all and everything of 
http://boinc.berkeley.edu/trac/wiki/CompileClient#Windows as the compilers the 
page is written for are VS 2005 (Express) and 2008.

And what VS, full VS or is Express also an option?
Or is Express still not capable of compiling 64bit applications?

Thanks,

-- Jord van der Elst.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu 
https://e.mail.ru/compose?To=boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.





___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

 

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom

Re: [boinc_dev] [PATCH] MinGW lib build currently broken

[Rom Walton]

I've applied patches 1, 3, and 4.

I need to investigate 2 a little bit more.  One of the first things
winsock.h does is pull in windows.h.  

Can you point me to the recommendation?

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
Timo Strunk
Sent: Monday, April 28, 2014 12:34 PM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] [PATCH] MinGW lib build currently broken

Hi everybody,

The commit afb6dcc6f3166f004327ec6fe32f39c577b40b38
MGR  Client: Massive code clean-up.  Remove as much of the
LoadLibrary[...]
breaks MinGW compilation because of the line #include winternl.h

The stock MinGW distribution does not carry this include, but the newer
MinGW-W64(http://sourceforge.net/apps/trac/mingw-w64/browser/trunk/mingw
-w64-headers/include/winternl.h?rev=5224),
does. However also here the compilation fails with the commit.

We (Thomas Koch and me) therefore tried fixing this situation for
MinGW-W64:
The problem is simply that MinGW-W64's winternl.h defines another
THREAD_STATE enum (also in diagnostics_win.h), which is similar to the
one of the BOINC lib, but has members, which carry different names.
The reason this is possible, is that there is no official THREAD_STATE
enum; Microsoft's implementation is a simple DWORD and some #defines for
the STATEs. (I'm definitely no expert on this, so I might be completely
wrong. I did not find any _official_ THREAD_STATE definition).

1.) As I think it will be really hard to change the naming of the MinGW
compiler, the attached patch changes the naming in the BOINC library and
does not define the enums in case of __MINGW32__ defines, as it relies
on the ones found in winternl.h.
In this way we don't change functionality in case of MSVC compiles
(please test, I only checked MinGW), but still allow compilation with
MinGW-W64. Another occurence happens in the installer directory, but I
did
  not touch this, because I think it's not intended to be MinGW
compatible anyways.
These are:
0001-Renamed-Thread_State-enum-names-to-mingw-standard-in.patch
0003-Renamed-StateWaiting-again-to-StateWait-as-per-mingw.patch

2.) The attached patches also include delayimp.h for MinGW, as it
seems to be required nowadays.
0004-MinGW-also-requires-delayimp-now.patch

This patch here is not required for making everything compile:
3.) winsock.h is now included prior to windows.h as recommended. Also
WIN32_LEAN_AND_MEAN is defined, because I saw no reason not to. If it is
defined somewhere else or even required to be absent and I didn't
notice, please remove it. It might not be good style to define it just
like that in a header.
0002-Include-winsock-before-windows.h.patch

With these 4 patches, mingw still doesn't compile using the supplied
makefile, but requires -fpermissive to be set. The reasons are multiple
deprecated string conversions.

After the commit mentioned at the beginning of the mail Windows 2000
support was dropped for the lib. Maybe the switch to Winsock2.h (Win98
and NT4 and upwards) and ws2tcpip.h (ipv6) should also be made now as
the code still seems to use winsock.h and it should be a simple change
of one include. However: Again, I'm no expert on the subject and there
might be good legacy reasons to keep everything as is.

Best,
Timo

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] 7.3.9 can't be compiled at 32 bit stable gentoo Linux

[Rom Walton]

I just committed a change I think will fix that.  Sync up with the master 
branch.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Toralf 
Förster
Sent: Thursday, March 06, 2014 12:05 PM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] 7.3.9 can't be compiled at 32 bit stable gentoo Linux

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

BOINCGUIApp.cpp: In member function ‘virtual bool CBOINCGUIApp::OnInit()’:
BOINCGUIApp.cpp:173:14: warning: variable ‘iErrorCode’ set but not used 
[-Wunused-but-set-variable]
BOINCGUIApp.cpp: In member function ‘virtual void 
CBOINCGUIApp::OnFatalException()’:
BOINCGUIApp.cpp:582:13: error: cannot pass objects of non-trivially-copyable 
type ‘const wxScopedCharBuffer {aka const class wxScopedCharTypeBufferchar}’ 
through ‘...’
BOINCGUIApp.cpp:582:13: warning: format ‘%s’ expects argument of type ‘char*’, 
but argument 3 has type ‘const wxScopedCharBuffer {aka const 
wxScopedCharTypeBufferchar}’ [-Wformat]


7.3.8 was fine

- --
MfG/Sincerely
Toralf Förster
pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E -BEGIN 
PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlMYqswACgkQxOrN3gB26U6KoAEAhrvmIgpBlVWm2Fb+lnXLOHNh
37Cicokx2Qvz6gcSUNYBAInu3o1m9tVnfcTUpv4vofdUrvLqql+Y4TWQawngDENq
=f22Q
-END PGP SIGNATURE-
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] BOINC 7.2.11 doesn't detect AVX

[Rom Walton]

It'll be fixed in the next release.

commit 073d3a70f7f041afa0c0dd9687b7b26ea55a6e6f
Author: Rom Walton r...@romwnet.org
Date:   Thu Mar 6 21:02:34 2014 -0500

client: Fix the CPUID calls for structured extension feature flags, it was 
clobbering standard support flags on Windows.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Erik 
Veit
Sent: Thursday, March 06, 2014 8:17 PM
To: BOINC Dev Mailing List
Subject: Re: [boinc_dev] BOINC 7.2.11 doesn't detect AVX

I upgraded to 7.3.9, and I still don't see avx.  In fact, a bunch of the 
processor features disappeared.  Over on asteroids, I was getting the SSE3 app 
with 7.2.42.  With 7.3.9, I can't get those any more, just the generic app that 
doesn't use any of the features.  It looks like the server thinks I don't have 
SSE3 any more.

1   Starting BOINC client version 7.2.42 for windows_x86_64 
21  Processor: 8 GenuineIntelIntel(R) Core(TM) i7-3770K CPU @ 
3.50GHz [Family 6 Model 58 Stepping 9]
22  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 htt tm pni ssse3 
cx16 sse4_1 sse4_2 popcnt aes syscall nx lm vmx tm2 pbe  
23  OS: Microsoft Windows 7: Professional x64 Edition, Service Pack 1, 
(06.01.7601.00)  


1   Starting BOINC client version 7.3.9 for windows_x86_64  
21  Processor: 8 GenuineIntelIntel(R) Core(TM) i7-3770K CPU @ 
3.50GHz [Family 6 Model 58 Stepping 9]
22  Processor features: fpu pse msr pae apic sep pge mca pat psn dts acpi 
fxsr ss fma cx16 movebe f16c rdrandsyscall nx lm fsgsbase smep vmx smx dca  
  
23  OS: Microsoft Windows 7: Professional x64 Edition, Service Pack 1, 
(06.01.7601.00)  



On Mar 1, 2014, at 9:36 AM, Rom Walton r...@romwnet.org wrote:

 Check the 7.3 build.  7.2 is still build with VS2005.
 
 - Rom
 
 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf 
 Of Erik Veit
 Sent: Saturday, March 01, 2014 12:15 PM
 To: BOINC Dev Mailing List
 Subject: Re: [boinc_dev] BOINC 7.2.11 doesn't detect AVX
 
 Did this ever get fixed/added to boinc?  If not, when?
 
 I have an IB i7, with the win7 64 and all the latest patches, and BOINC 
 7.2.42.  But it still does not show AVX.
 
 3/1/2014 6:37:23 AM   Starting BOINC client version 7.2.42 for windows_x86_64 
 3/1/2014 6:37:23 AM   Processor: 8 GenuineIntelIntel(R) Core(TM) 
 i7-3770K CPU @ 3.50GHz [Family 6 Model 58 Stepping 9]
 3/1/2014 6:37:23 AM   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 
 htt tm pni ssse3 cx16 sse4_1 sse4_2 popcnt aes syscall nx lm vmx tm2 pbe  
 3/1/2014 6:37:23 AM   OS: Microsoft Windows 7: Professional x64 Edition, 
 Service Pack 1, (06.01.7601.00)  
 
 Thanks,
 Erik
 
 
 
 On Aug 25, 2013, at 5:20 AM, Jord van der Elst els...@gmail.com wrote:
 
 Rom Walton, from the other thread:
 I've held off putting this into 7.2 for now.  It turns out that 
 detecting the CPU instruction set is only half of the problem.
 
 We are in the process of getting an updated toolchain for building on 
 Windows which will allow us to detect if the OS is properly 
 saving/restoring the new registers on a thread context switch.
 (http://lists.ssl.berkeley.edu/pipermail/boinc_dev/2013-August/020264.
 html)
 
 Rom Walton, from the other thread:
 We are in the process of updating our Windows toolchain to a more 
 recent version of Visual Studio.
 
 It isn't enough to just check if the instruction set is present, we 
 also need to check whether the OS is saving and restoring the 
 registers as well.  That required a more recent assembler than what 
 we are currently using.
 
 Once we have the updated toolchain we will finish up with the rest of 
 the detection and get it ported over to the 7.2 branch.
 (http://lists.ssl.berkeley.edu/pipermail/boinc_dev/2013-August/020316.
 html)
 
 On Sun, Aug 25, 2013 at 1:45 PM, Radim Vančo rad...@centrum.cz wrote:
 I know but because it was another problem it the mailing than I 
 suppose that they solved this but forgot on these new CPUs. As I 
 said, another problem so that is why I wrote about it.
 
 
 Dne 25.8.2013 13:41, Jord van der Elst napsal(a):
 
 BOINC can not report parts of the CPU that it isn't programmed to report.
 So when for instance in 2014 there will be CPUs available with FMA3 
 and FMA4, you'll first need a new BOINC capable of detecting those 
 options before that same BOINC will report them.
 Even having code added to the source code does not automatically 
 mean that any of the presently available BOINC versions is capable 
 of reporting that CPU option. The BOINC with the code in it will 
 first have to be built  be available for download. Which in this 
 case, it hasn't.
 
 
 On Sun, Aug 25, 2013 at 1:35 PM, Radim Vančo rad

Re: [boinc_dev] BOINC 7.2.11 doesn't detect AVX

[Rom Walton]

I've created a private drop with the fix:

x64: http://boinc.berkeley.edu/dl/boinc.060214.x64.zip
x86: http://boinc.berkeley.edu/dl/boinc.060214.x86.zip

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Rom 
Walton
Sent: Thursday, March 06, 2014 9:04 PM
To: BOINC Dev Mailing List
Subject: Re: [boinc_dev] BOINC 7.2.11 doesn't detect AVX

It'll be fixed in the next release.

commit 073d3a70f7f041afa0c0dd9687b7b26ea55a6e6f
Author: Rom Walton r...@romwnet.org
Date:   Thu Mar 6 21:02:34 2014 -0500

client: Fix the CPUID calls for structured extension feature flags, it was 
clobbering standard support flags on Windows.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Erik 
Veit
Sent: Thursday, March 06, 2014 8:17 PM
To: BOINC Dev Mailing List
Subject: Re: [boinc_dev] BOINC 7.2.11 doesn't detect AVX

I upgraded to 7.3.9, and I still don't see avx.  In fact, a bunch of the 
processor features disappeared.  Over on asteroids, I was getting the SSE3 app 
with 7.2.42.  With 7.3.9, I can't get those any more, just the generic app that 
doesn't use any of the features.  It looks like the server thinks I don't have 
SSE3 any more.

1   Starting BOINC client version 7.2.42 for windows_x86_64 
21  Processor: 8 GenuineIntelIntel(R) Core(TM) i7-3770K CPU @ 
3.50GHz [Family 6 Model 58 Stepping 9]
22  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 htt tm pni ssse3 
cx16 sse4_1 sse4_2 popcnt aes syscall nx lm vmx tm2 pbe  
23  OS: Microsoft Windows 7: Professional x64 Edition, Service Pack 1, 
(06.01.7601.00)  


1   Starting BOINC client version 7.3.9 for windows_x86_64  
21  Processor: 8 GenuineIntelIntel(R) Core(TM) i7-3770K CPU @ 
3.50GHz [Family 6 Model 58 Stepping 9]
22  Processor features: fpu pse msr pae apic sep pge mca pat psn dts acpi 
fxsr ss fma cx16 movebe f16c rdrandsyscall nx lm fsgsbase smep vmx smx dca  
  
23  OS: Microsoft Windows 7: Professional x64 Edition, Service Pack 1, 
(06.01.7601.00)  



On Mar 1, 2014, at 9:36 AM, Rom Walton r...@romwnet.org wrote:

 Check the 7.3 build.  7.2 is still build with VS2005.
 
 - Rom
 
 -Original Message-
 From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf 
 Of Erik Veit
 Sent: Saturday, March 01, 2014 12:15 PM
 To: BOINC Dev Mailing List
 Subject: Re: [boinc_dev] BOINC 7.2.11 doesn't detect AVX
 
 Did this ever get fixed/added to boinc?  If not, when?
 
 I have an IB i7, with the win7 64 and all the latest patches, and BOINC 
 7.2.42.  But it still does not show AVX.
 
 3/1/2014 6:37:23 AM   Starting BOINC client version 7.2.42 for windows_x86_64 
 3/1/2014 6:37:23 AM   Processor: 8 GenuineIntelIntel(R) Core(TM) 
 i7-3770K CPU @ 3.50GHz [Family 6 Model 58 Stepping 9]
 3/1/2014 6:37:23 AM   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 
 htt tm pni ssse3 cx16 sse4_1 sse4_2 popcnt aes syscall nx lm vmx tm2 pbe  
 3/1/2014 6:37:23 AM   OS: Microsoft Windows 7: Professional x64 Edition, 
 Service Pack 1, (06.01.7601.00)  
 
 Thanks,
 Erik
 
 
 
 On Aug 25, 2013, at 5:20 AM, Jord van der Elst els...@gmail.com wrote:
 
 Rom Walton, from the other thread:
 I've held off putting this into 7.2 for now.  It turns out that 
 detecting the CPU instruction set is only half of the problem.
 
 We are in the process of getting an updated toolchain for building on 
 Windows which will allow us to detect if the OS is properly 
 saving/restoring the new registers on a thread context switch.
 (http://lists.ssl.berkeley.edu/pipermail/boinc_dev/2013-August/020264.
 html)
 
 Rom Walton, from the other thread:
 We are in the process of updating our Windows toolchain to a more 
 recent version of Visual Studio.
 
 It isn't enough to just check if the instruction set is present, we 
 also need to check whether the OS is saving and restoring the 
 registers as well.  That required a more recent assembler than what 
 we are currently using.
 
 Once we have the updated toolchain we will finish up with the rest of 
 the detection and get it ported over to the 7.2 branch.
 (http://lists.ssl.berkeley.edu/pipermail/boinc_dev/2013-August/020316.
 html)
 
 On Sun, Aug 25, 2013 at 1:45 PM, Radim Vančo rad...@centrum.cz wrote:
 I know but because it was another problem it the mailing than I 
 suppose that they solved this but forgot on these new CPUs. As I 
 said, another problem so that is why I wrote about it.
 
 
 Dne 25.8.2013 13:41, Jord van der Elst napsal(a):
 
 BOINC can not report parts of the CPU that it isn't programmed to report.
 So when for instance in 2014 there will be CPUs available with FMA3 
 and FMA4, you'll first need a new BOINC capable of detecting those

Re: [boinc_dev] BOINC 7.2.11 doesn't detect AVX

[Rom Walton]

Check the 7.3 build.  7.2 is still build with VS2005.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Erik 
Veit
Sent: Saturday, March 01, 2014 12:15 PM
To: BOINC Dev Mailing List
Subject: Re: [boinc_dev] BOINC 7.2.11 doesn't detect AVX

Did this ever get fixed/added to boinc?  If not, when?

I have an IB i7, with the win7 64 and all the latest patches, and BOINC 7.2.42. 
 But it still does not show AVX.

3/1/2014 6:37:23 AM Starting BOINC client version 7.2.42 for windows_x86_64 
3/1/2014 6:37:23 AM Processor: 8 GenuineIntelIntel(R) Core(TM) 
i7-3770K CPU @ 3.50GHz [Family 6 Model 58 Stepping 9]
3/1/2014 6:37:23 AM 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 htt 
tm pni ssse3 cx16 sse4_1 sse4_2 popcnt aes syscall nx lm vmx tm2 pbe  
3/1/2014 6:37:23 AM OS: Microsoft Windows 7: Professional x64 Edition, 
Service Pack 1, (06.01.7601.00)  

Thanks,
Erik



On Aug 25, 2013, at 5:20 AM, Jord van der Elst els...@gmail.com wrote:

 Rom Walton, from the other thread:
 I've held off putting this into 7.2 for now.  It turns out that 
 detecting the CPU instruction set is only half of the problem.
 
 We are in the process of getting an updated toolchain for building on 
 Windows which will allow us to detect if the OS is properly 
 saving/restoring the new registers on a thread context switch.
 (http://lists.ssl.berkeley.edu/pipermail/boinc_dev/2013-August/020264.
 html)
 
 Rom Walton, from the other thread:
 We are in the process of updating our Windows toolchain to a more 
 recent version of Visual Studio.
 
 It isn't enough to just check if the instruction set is present, we 
 also need to check whether the OS is saving and restoring the 
 registers as well.  That required a more recent assembler than what we 
 are currently using.
 
 Once we have the updated toolchain we will finish up with the rest of 
 the detection and get it ported over to the 7.2 branch.
 (http://lists.ssl.berkeley.edu/pipermail/boinc_dev/2013-August/020316.
 html)
 
 On Sun, Aug 25, 2013 at 1:45 PM, Radim Vančo rad...@centrum.cz wrote:
 I know but because it was another problem it the mailing than I 
 suppose that they solved this but forgot on these new CPUs. As I 
 said, another problem so that is why I wrote about it.
 
 
 Dne 25.8.2013 13:41, Jord van der Elst napsal(a):
 
 BOINC can not report parts of the CPU that it isn't programmed to report.
 So when for instance in 2014 there will be CPUs available with FMA3 
 and FMA4, you'll first need a new BOINC capable of detecting those 
 options before that same BOINC will report them.
 Even having code added to the source code does not automatically 
 mean that any of the presently available BOINC versions is capable 
 of reporting that CPU option. The BOINC with the code in it will 
 first have to be built  be available for download. Which in this 
 case, it hasn't.
 
 
 On Sun, Aug 25, 2013 at 1:35 PM, Radim Vančo rad...@centrum.cz wrote:
 
 I hope so, because in that mailing part there was problem with not 
 reporting AVX on os that doesn't support it, but it doesn't report 
 it even on os that does support it.
 
 
 Dne 25.8.2013 13:14, Jord van der Elst napsal(a):
 
 That's because 'the latest version' doesn't support it yet.
 It'll be in a 7.2 version, AFTER 7.2.11, as soon as the developers 
 port it to the 7.2 branch.
 
 If you can't wait, you can build a newer BOINC from Master.
 
 
 http://boinc.berkeley.edu/trac/changeset/9b2d0f992f6669d31d1996c4f
 c105ce22324445b/boinc-v2 shows that Rom added the change on the 
 22nd of July 2013 to the Master branch.
 It just hasn't been ported to the 7.0 or 7.2 branches yet.
 
 On Sun, Aug 25, 2013 at 12:56 PM, Radim Vančo rad...@centrum.cz wrote:
 
 I have read it, but this is another problem.  The processor has 
 AVX support and OS also. It is Win 7 with SP1 64bit but it 
 doesn't report AVX. Even with the latest version, but it doesn't 
 report it on these type of processors.
 i7
 reports it ok, but i5-3230M and other 3xxx doesn't report it.
 
 
 
 Dne 25.8.2013 12:01, Jord van der Elst napsal(a):
 
 You probably haven't had an answer because there's just been a 
 whole email thread about this.
 Can be found in the archives of the boinc_dev email list, 
 starting from
 
 http://lists.ssl.berkeley.edu/pipermail/boinc_dev/2013-July/0202
 15.html
 
 On Sun, Aug 25, 2013 at 11:49 AM, Radim Vančo 
 rad...@centrum.cz
 wrote:
 
 No one to reply this? This is quite important, I already wrote 
 with some people and they also have undetected AVX on this type 
 of processor which has AVX. So there is some problem in BOINC 
 client, that it doesn't report AVX.
 
 Radim
 
 
 Dne 23.8.2013 11:51, Radim Vančo napsal(a):
 
 I am now testing 7.0.64 and it also doesn't detect AVX. So it 
 propably something in source code, that it doesn't detect on 
 that processor

[boinc_dev] BOINC 7.2.42 released to the public

[Rom Walton]

A new version of BOINC client is ready for public use.

Bug fix over previous public release:
* Fix problem that was causing scheduler RPCs to fail on Yoyo@home (HTTP
status code 400)

Download: http://boinc.berkeley.edu/download.php
Release Notes: http://boinc.berkeley.edu/wiki/Release_Notes
Version History: http://boinc.berkeley.edu/trac/wiki/VersionHistory

Thanks to all the alpha testers and community at large for helping us
figure this issue out and get a hot fix released.

- Rom
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] compile error with boinc-7.3.3 (7.3.2 compiles and runsfine)

[Rom Walton]

I fixed that issue last night.  Checkout the latest from master.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Toralf 
Förster
Sent: Wednesday, February 19, 2014 1:32 PM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] compile error with boinc-7.3.3 (7.3.2 compiles and 
runsfine)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

At a stable 32 bit Gentoo Linxu I do get now :

...
res/boincsnooze.xpm:127:1: warning: deprecated conversion from string constant 
to ‘char*’ [-Wwrite-strings]
res/boincsnooze.xpm:127:1: warning: deprecated conversion from string constant 
to ‘char*’ [-Wwrite-strings]
res/boincsnooze.xpm:127:1: warning: deprecated conversion from string constant 
to ‘char*’ [-Wwrite-strings]
SkinManager.cpp:258:6: warning: unused parameter ‘strIcon’ [-Wunused-parameter]
sg_TaskPanel.cpp: In member function ‘void CScrolledTextBox::SetValue(const 
wxString)’:
sg_TaskPanel.cpp:73:21: warning: variable ‘totalLines’ set but not used 
[-Wunused-but-set-variable]
SkinManager.cpp: In member function ‘bool 
CSkinAdvanced::InitializeDelayedValidation()’:
SkinManager.cpp:589:89: error: no matching function for call to 
‘CSkinIcon::SetDefaults(const wchar_t [12], wxIcon, wxIcon)’
SkinManager.cpp:589:89: note: candidates are:
SkinManager.cpp:258:6: note: bool CSkinIcon::SetDefaults(wxString, wxString)
SkinManager.cpp:258:6: note:   candidate expects 2 arguments, 3 provided
SkinManager.cpp:272:6: note: bool CSkinIcon::SetDefaults(wxString, const 
char**, const char**)
SkinManager.cpp:272:6: note:   no known conversion for argument 2 from ‘wxIcon’ 
to ‘const char**’
SkinManager.cpp:590:134: error: no matching function for call to 
‘CSkinIcon::SetDefaults(const wchar_t [25], wxIcon, wxIcon)’
SkinManager.cpp:590:134: note: candidates are:
SkinManager.cpp:258:6: note: bool CSkinIcon::SetDefaults(wxString, wxString)
SkinManager.cpp:258:6: note:   candidate expects 2 arguments, 3 provided
SkinManager.cpp:272:6: note: bool CSkinIcon::SetDefaults(wxString, const 
char**, const char**)
SkinManager.cpp:272:6: note:   no known conversion for argument 2 from ‘wxIcon’ 
to ‘const char**’
SkinManager.cpp:591:114: error: no matching function for call to 
‘CSkinIcon::SetDefaults(const wchar_t [19], wxIcon, wxIcon)’
SkinManager.cpp:591:114: note: candidates are:
SkinManager.cpp:258:6: note: bool CSkinIcon::SetDefaults(wxString, wxString)
SkinManager.cpp:258:6: note:   candidate expects 2 arguments, 3 provided
SkinManager.cpp:272:6: note: bool CSkinIcon::SetDefaults(wxString, const 
char**, const char**)
SkinManager.cpp:272:6: note:   no known conversion for argument 2 from ‘wxIcon’ 
to ‘const char**’
make[2]: *** [boincmgr-SkinManager.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory `/mnt/ramdisk/boinc-7.3.3/clientgui'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/mnt/ramdisk/boinc-7.3.3'
make: *** [all] Error 2

- --
MfG/Sincerely
Toralf Förster
pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E -BEGIN 
PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlME+KUACgkQxOrN3gB26U6/SAD/UiClmrpg2mROIsWW96ug6vRR
nSCjNB3p70kbm+xWmPQA/15rkx6l0gsQzl6n3ux8KOYJyN+/iPFIZ7m+KyrxSIbj
=vckS
-END PGP SIGNATURE-
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] compile error with boinc-7.3.3 (7.3.2 compiles and runsfine)

[Rom Walton]

Okay, try with this id:
062839a43124c561ce4b4b1fd227d0c50dc2503f

I checked this in this morning, I had some feedback from Charlie about Mac 
builds.

- Rom

-Original Message-
From: Toralf Förster [mailto:toralf.foers...@gmx.de] 
Sent: Wednesday, February 19, 2014 2:25 PM
To: Rom Walton; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] compile error with boinc-7.3.3 (7.3.2 compiles and 
runsfine)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/19/2014 08:10 PM, Rom Walton wrote:
 It should be:
 a14f17bf9fdda80a274d0ea2f98052a45b575da5
 
 We will probably do another desktop release next week.  We are in the middle 
 of another Android release cycle at the moment.
 
 - Rom
 

Well, 7.3.3 + that id gives :


res/boincsnooze.xpm:127:1: warning: deprecated conversion from string constant 
to ‘char*’ [-Wwrite-strings]
res/boincsnooze.xpm:127:1: warning: deprecated conversion from string constant 
to ‘char*’ [-Wwrite-strings]
res/boincsnooze.xpm:127:1: warning: deprecated conversion from string constant 
to ‘char*’ [-Wwrite-strings]
SkinManager.cpp: In member function ‘bool 
CSkinAdvanced::InitializeDelayedValidation()’:
SkinManager.cpp:589:106: error: invalid conversion from ‘char**’ to ‘const 
char**’ [-fpermissive]
SkinManager.cpp:270:6: error:   initializing argument 2 of ‘bool 
CSkinIcon::SetDefaults(wxString, const char**, const char**)’ [-fpermissive]
make[2]: *** [boincmgr-SkinManager.o] Error 1
make[2]: Leaving directory 
`/var/tmp/portage/sci-misc/boinc-7.3.3/work/boinc-7.3.3/clientgui'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/var/tmp/portage/sci-misc/boinc-7.3.3/work/boinc-7.3.3'
make: *** [all] Error 2
 * ERROR: sci-misc/boinc-7.3.3::toralf failed (compile phase):
 

 -Original Message-
 From: Toralf Förster [mailto:toralf.foers...@gmx.de]
 Sent: Wednesday, February 19, 2014 2:06 PM
 To: Rom Walton; boinc_dev@ssl.berkeley.edu
 Subject: Re: [boinc_dev] compile error with boinc-7.3.3 (7.3.2 
 compiles and runsfine)
 
 On 02/19/2014 07:35 PM, Rom Walton wrote:
 I fixed that issue last night.  Checkout the latest from master.
 
 - Rom
 
 yes - I do know, the git tree compiles fine.
 
 Do you have a single commit id for this issue - or is 7.3.4 already in the 
 queue ?
 
 (under Gentoo it is easy to cherry-pick and compile a patched version).
 
 
 

- --
MfG/Sincerely
Toralf Förster
pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E -BEGIN 
PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlMFBQwACgkQxOrN3gB26U7jWgD8CPsYc7laFaXIjTmd4Y5RvyU1
k53odtOhZm2a4Hp1NYgA/Rm0G8leMsUtXN8gFlRcGI5R2Tq4nI1gy0XlmaUmuP74
=t8QT
-END PGP SIGNATURE-
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] compile error while trying to build boincmgr of boinc 7.4/7.3.1 at a Gentoo Linux

[Rom Walton]

Right now, the notices tab uses the new webkit technology.  At some point it 
should be possible to embed images and video in notices.

We plan on adding OAuth authentication, we needed an updated HTML experience to 
do that.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Toralf 
Förster
Sent: Wednesday, February 12, 2014 11:12 AM
To: Wolfgang Schwieger; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] compile error while trying to build boincmgr of boinc 
7.4/7.3.1 at a Gentoo Linux

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/11/2014 11:31 PM, Wolfgang Schwieger wrote:
 Hi,
 
 it seems that your version of wxWidgets-3.0.0 is not configured for
 webkit/webview:
 
 use these options to configure wxWidgets: ./configure --disable-shared 
 --enable-static --enable-unicode --enable-webkit --enable-webview 
 --prefix=/usr

yes - boincmgr compiles now fine.


1 Issue and 1 Question :

The mouse wheel cannot longer be used to cycle through the menus Notices, 
Projects, Tasks and son on - worked before flawlessly.
The wheel itself works and is recognized by boincmgr: I can scroll up and down 
and left + right. But when I hover the mouse cursor over the scroll bars - then 
nothing happens, the menu cycling is lost.


And now the question - what are (or will be) the enhancements in the manager 
now which requires the webkit ? I'm asking because b/c currently I do not see 
any new feature and the additional 13 packages needed here in gentoo land take 
a loong compile time.


- --
MfG/Sincerely
Toralf Förster
pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E -BEGIN 
PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlL7nTgACgkQxOrN3gB26U5zOQD7BvfuRQjIcpNPdHK/VnfWtNgN
PlPHY3heUfdl2KfX2RIA/0A2lTFQqH9uvAfQb/1SDYQxxc9e5YCuNjJXrtqOZZ5+
=MJiI
-END PGP SIGNATURE-
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] compile error while trying to build boincmgr of boinc 7.4/7.3.1 at a Gentoo Linux

[Rom Walton]

It looks like wxWidgets was built without webview support, or at least the 
'make install' step didn't copy over all the web view header files.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Toralf 
Förster
Sent: Tuesday, February 11, 2014 1:17 PM
To: boinc_dev@ssl.berkeley.edu
Subject: [boinc_dev] compile error while trying to build boincmgr of boinc 
7.4/7.3.1 at a Gentoo Linux

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, the client was build fine and seems to work well, but the manager cannot be 
built due to this error at a 32 bit Gentoo Linux:

$ make
  CXX  boincmgr-NoticeListCtrl.o
In file included from /usr/include/wx-3.0/wx/cursor.h:69:0,
 from /usr/include/wx-3.0/wx/event.h:21,
 from /usr/include/wx-3.0/wx/wx.h:24,
 from stdwx.h:48,
 from NoticeListCtrl.cpp:22:
/usr/include/wx-3.0/wx/utils.h:603:52: warning: redundant redeclaration of 
‘void wxQsort(void*, size_t, size_t, wxSortCallback, const void*)’ in same 
scope [-Wredundant-decls] In file included from 
/usr/include/wx-3.0/wx/list.h:34:0,
 from /usr/include/wx-3.0/wx/wx.h:17,
 from stdwx.h:48,
 from NoticeListCtrl.cpp:22:
/usr/include/wx-3.0/wx/vector.h:44:23: warning: previous declaration of ‘void 
wxQsort(void*, size_t, size_t, wxSortCallback, const void*)’ 
[-Wredundant-decls] In file included from NoticeListCtrl.cpp:36:0:
NoticeListCtrl.h:48:25: error: ‘wxWebViewEvent’ has not been declared
NoticeListCtrl.h:49:26: error: ‘wxWebViewEvent’ has not been declared
NoticeListCtrl.h:59:5: error: ‘wxWebView’ does not name a type
NoticeListCtrl.cpp:53:72: error: invalid use of non-static member function 
‘void CNoticeListCtrl::OnLinkClicked(int)’
NoticeListCtrl.cpp:53:85: error: ‘EVT_WEBVIEW_NAVIGATING’ was not declared in 
this scope
NoticeListCtrl.cpp:54:5: error: expected ‘}’ before ‘EVT_WEBVIEW_ERROR’
NoticeListCtrl.cpp:54:5: error: expected ‘,’ or ‘;’ before ‘EVT_WEBVIEW_ERROR’
NoticeListCtrl.cpp:57:1: error: expected declaration before ‘}’ token
make: *** [boincmgr-NoticeListCtrl.o] Error 1

- --
MfG/Sincerely
Toralf Förster
pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E -BEGIN 
PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlL6aS0ACgkQxOrN3gB26U5VygD+MfiqHz3Osq+3MbY1tqtQXmQK
I66CX7dJ6gJdO1q5n0UBAI8vgOIbDzSbWaXJRujF6ATVwqsoSNRxqAIjMRvF9gNI
=WCY2
-END PGP SIGNATURE-
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.