sci-astronomy/setiathome-3.* is obsolete. Please test sci-misc/boinc-4.72 and sci-astronomy/setiathome-4.18.20050813 and mark as testing for your architecture. Unfortunately the 3.* versions can no longer be downloaded and/or used with the project, and so will be masked and removed shortly.
Both sci-misc/boinc-4.72.20050813 and sci-astronomy/setiathome-4.18 now marked ~sparc; they build and install, and boinc seems to run (at least, it can benchmark the system). Note that for me, at least, to get boinc to install successfully consistently, I needed MAKEOPTS='-j1', because in one case, the make attempted to 'cp ../lib/boinc_cmd BOINC/boinc_cmd' before the 'mkdir -p BOINC' had completed.
I upgraded from setiathome 3.0x to boinc-4.72 and setiathome-4.18 last night. All did not go smoothly. The old download was around 450 KBytes. The new download is around 23 Megabytes. The new download included wxGTK-2.6.0 and a sound package. I do not know what they are used for and wonder why I had to download them. Everything compiled OK so far as I know. Old setiathome 3.0x files were not removed, e.g., /etc/init.d/setiathome is still present. I had to run "boinc attach" in /etc/init.d to be able to connect to the Berkeley site. When things started working, the boinc_client -- I think it was this program but it might be some other boinc program -- deleted all the files in /var/lib/boinc/projects/setiathome.berkeley.edu including the setiathome-4.18 file. It then downloaded some data files to this directory and what I think was a binary copy of setiathome-4.02. When it finished that, it deleted all the files in that directory again -- yes -- and loaded new data files and another copy of setiathome-4.02. This time files were not deleted and the program appeared to run normally. I had to add boinc to /etc/runlevels/default so that boinc would start when I booted. The original problem of bug 40120 has re-emerged. I again cannot kill or pause setiathome as an ordinary user. Currently, it runs as boinc. Ivar
Marcus, I have been thinking about this a bit and have decided on a reasonable solution to seti@home. It should be masked always for platforms that berkeley provides a binary with a way that users will know why it is masked (a client is downloaded automatically for their platform) They can always unmask the seti ebuild though it is likely to be slower... Another nice thing to have would be a seti@home-bin ebuild to pull in some precompiled and OPTIMIZED clients from around the net. Also OT, I have noticed many people running boinc_client by hand which is highly undesireable. Perhaps we should remove it from the PATH?
(In reply to comment #2) > The new download included wxGTK-2.6.0 and a sound package. I do not know what > they are used for and wonder why I had to download them. They are dependencies of the new Boinc GUI, and so are needed if you want to use the GUI. Otherwise build with USE="-X" > > Everything compiled OK so far as I know. > > Old setiathome 3.0x files were not removed, e.g., /etc/init.d/setiathome is > still present. That is known behaviour of portage to protect config files, and is beyond the scope of this ebuild to remedy. See previous discussions on -dev about this issue. > > I had to run "boinc attach" in /etc/init.d to be able to connect to the Berkeley > site. When things started working, the boinc_client -- I think it was this > program but it might be some other boinc program -- deleted all the files in > /var/lib/boinc/projects/setiathome.berkeley.edu including the setiathome-4.18 > file. It then downloaded some data files to this directory and what I think was > a binary copy of setiathome-4.02. When it finished that, it deleted all the > files in that directory again -- yes -- and loaded new data files and another > copy of setiathome-4.02. This time files were not deleted and the program > appeared to run normally. This is a bug that I have noted, and am working on currently. It presents the biggest issue for archs other than x86 where currently the only workaround is to attach, then stop boinc and emerge setiathome again, and then start boinc which should then use the provided binary. Patches would be welcome. > > I had to add boinc to /etc/runlevels/default so that boinc would start when I > booted. As expected. > > The original problem of bug 40120 has re-emerged. I again cannot kill or pause > setiathome as an ordinary user. Currently, it runs as boinc. This is expected behaviour and not a bug. If you want to stop boinc as a normal user you will have to use sudo to allow them to perform this action. Bug 40120 concerned security issues with running setiathome as root, running it as a dedicated user with limited privs is the correct solution to that issue. If you want to modify the user then modify /etc/conf.d/boinc, and you must also chown -R user:user /var/lib/boinc in that case.
(In reply to comment #3) > Marcus, I have been thinking about this a bit and have decided on a reasonable > solution to seti@home. It should be masked always for platforms that berkeley > provides a binary with a way that users will know why it is masked (a client is > downloaded automatically for their platform) They can always unmask the seti > ebuild though it is likely to be slower... I disagree - Gentoo is about choice and people can choose to emerge setiathome or not. May be the creation of some Gentoo specific documentation would help people decide what was best, but I will not be keeping the ebuild masked. > > Another nice thing to have would be a seti@home-bin ebuild to pull in some > precompiled and OPTIMIZED clients from around the net. > > Also OT, I have noticed many people running boinc_client by hand which is highly > undesireable. Perhaps we should remove it from the PATH? Again if people choose to do things their own way that is fine. The facility is provided to them, but they should not be forced to use it. I will be leaving all the commands in their path, we try to keep all packages as close to upstream as possible in most cases.
added ~ia64 to boinc-4.72.20050813.ebuild and setiathome-4.18.ebuild
sci-misc/boinc-4.72.20050813 fails for me on ppc. If wanted, I can provide full log. make[2]: Leaving directory `/var/tmp/portage/boinc-4.72.20050813/work/boinc_public/clientgui' Making all in sea make[2]: Entering directory `/var/tmp/portage/boinc-4.72.20050813/work/boinc_public/sea' mkdir -p BOINC cp ../lib/boinc_cmd BOINC/boinc_cmd cp boincmgr.8x8.png BOINC/boincmgr.8x8.png cp: cannot create regular file `BOINC/boinc_cmd': No such file or directory make[2]: *** [BOINC/boinc_cmd] Error 1 make[2]: *** Waiting for unfinished jobs.... cp: cannot create regular file `BOINC/boincmgr.8x8.png': No such file or directory make[2]: *** [BOINC/boincmgr.8x8.png] Error 1 make[2]: Leaving directory `/var/tmp/portage/boinc-4.72.20050813/work/boinc_public/sea' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/boinc-4.72.20050813/work/boinc_public' make: *** [all] Error 2
I think humpback encountered a similar compile error on x86, and I was unable to reproduce it there either. I would appreciate any more info you can give me - it seems as though the boinc_cmd executable is never compiled or linked for some reason. Hopefully I will get time to roll some new ebuilds on the weekend with a more recent code snapshot too, may be that will help.
I have committed sci-misc/boinc-4.72.20050813-r2 and sci-astronomy/setiathome-4.18-r1 to the tree. They take care of various issues and compile here without any problems on both amd64 and x86. I would appreciate further testing, but have been unable to reproduce the build failures reported by some people. I would like to iron out any remaining issues as setiathome-3.* will have to be p.masked and removed from the tree soon - it is obsolete and no longer supported upstream. Please test :)
Tested boinc-4.72.20050813-r2 and setiathome-4.18-r1 in two different x86 systems. They emerged and worked correctly in both systems. Lucas Chiesa
> Unfortunately the 3.* versions can no longer be downloaded and/or used with the project, only the first part is true - the old 3.08 client works perfectly with "seti classic" and there is no single word about stopping the service in near future at the setiathome webpages (by the time of writing this) because I prefer the non-BOINC version (and I think that many other people too - just look at the statistics at the old setiathome pages), I would like to ask: > I would like to iron out any remaining issues as setiathome-3.* will > have to be p.masked and removed from the tree soon were you asked for this by the "seti classic" maintainer? or is it just the need "to be more popish than the pope"? (I do not know this proverb in English but I hope you understand ;-) ) what is the reason for removing the old setiathome, why don't you just wait and remove the "classic" version when the "classic" project is stopped?
(In reply to comment #11) > > Unfortunately the 3.* versions can no longer be downloaded and/or used with > the project, > > only the first part is true - the old 3.08 client works perfectly with "seti > classic" and there is no single word about stopping the service in near future > at the setiathome webpages (by the time of writing this) And what is the point in keeping an ebuild in the tree that does not work? If you cannot download setiathome classic then the ebuild is useless - you can keep using it whether the ebuild is there or not. For others there is no point.
Used with the seti@home client at http://www.guntec.de/Crunch3r/setialpha.html, boinc (including the GUI) works well on my ev56 Alpha.
(In reply to comment #12) > And what is the point in keeping an ebuild in the tree that does not work? > If you cannot download setiathome classic then the ebuild is useless well ... what is the point in keeping e.g. sun-jdk when the sources may not be downloaded automatically? sorry to say that, but your point that it does not work is formally true, but a big lie in practice - it works (nearly - see bug 103214) perfectly if you get the file yourself (and it is not the only ebuild for which it has to be done manually, as I say above ... and what if I already have it downloaded in distfiles and just want to rebuild for some reason?) does it cost you a lot od money and time to keep the ebuild in portage tree? > - you can keep using it whether the ebuild is there or not. yes, and I can go for LFS and throw away any package-system benefits and the nice (?) init.d script ... very fine :-(
(In reply to comment #14) > well ... what is the point in keeping e.g. sun-jdk when the sources may not > be downloaded automatically? These are two completely different situations. SUN actively supports and distributes their JKD; they merely require you to download it manually. SETI@home 3.x, however, is longer distributed or developed upstream, and its license prevents us from mirroring an old archive on our servers. > sorry to say that, but your point that it does not work is formally true, but > a big lie in practice - it works (nearly - see bug 103214) perfectly if you > get the file yourself (and it is not the only ebuild for which it has to be > done manually, as I say above ... and what if I already have it downloaded in > distfiles and just want to rebuild for some reason?) No, it does not work at all. If I type "emerge =setiathome-3*" on my system, it just fails because the archive is not available, and if I go to the Website, I am told the software is longer distributed so I cannot download it. The ebuild will in fact only work for the minority of users who have an old archive lying around on their computer (or those who would download an illegaly redistributed archive). Portage strives to be a quality repository, and broken ebuilds just have no place in it. > does it cost you a lot od money and time to keep the ebuild in portage tree? Money, no. Time (and efforts), yes. We need to solve bugs, keep an eye on security vulnerabilities, update the other packages (GUIs and such) that rely on this one (that are mostly unmaintained now that the BOINC-based client is available). And since it is a binary package, we cannot look at the code and will not be able to solve any security issue. > yes, and I can go for LFS and throw away any package-system benefits and the > nice (?) init.d script ... very fine :-( Let us face the fact no developer is interested in investing his time in maintaining a broken, upstream-abandoned package for which there is a working replacement. If you absolutely must continue to use the classic client, just copy the ebuild and related files to a local Portage overlay. (And if you ever loose it, you can fetch it from the attic in our CVS.)
Marked ~ppc.
(In reply to comment #15) I would argue but it is pointless because of two reasons, the first being personal and the second: November 15, 2005 On December 15, 2005, after 6 years of operation, this project will shut down. (http://setiathome2.ssl.berkeley.edu/)
Newest recommended software version by http://boinc.berkeley.edu/download.php is version 5.2.8 of the client.
I am well aware of the latest recommended version, but it has build issues. If you would like to help getting it working then please do. I will hopefully take another look this weekend but I think they are depending upon a masked version of openssl. The old SETI client was always going to be removed from portage and that is because the ebuild is no more than a placeholder now, and it was obvious they were going to stop the project sooner or later.
The "classic" SETI@home 3.x service has now been discontinued (and the software is no longer distributed). This is why I will start masking the relevant packages. These will be removed from the tree in about a month. They are: =sci-astronomy/setiathome-3* sci-astronomy/ksetispy sci-astronomy/ksetiwatch sci-astronomy/lin-seti sci-astronomy/msetimon sci-astronomy/setimgr sci-astronomy/tkseti x11-plugins/gkrellm-seti x11-plugins/wmseti x11-plugins/wmsetimon x11-plugins/wmufo The "seti" local USE flag used in "app-admin/torsmo" and "app-admin/conky" will be masked in the base profile.
There are still quite a few issues with administrating both boinc and setiathome 's new version. One I haven't seen any mention of here is that the start() function in the boinc init.d script empties ${LOGFILE}, which I find highly undesirable. Patch to follow. Otherwise, it all seems to run on hppa quite well... More after some additional testing.
Created attachment 73756 [details, diff] sci-astronomy-boinc.init.d-log.patch
It seems reasonable to append the log output rather than overwriting so I have added your patch. I also did a rev bump to propagate the new init file. Administration is still not totally flawless but it seems to be working pretty well here. I would welcome feedback on this.
(In reply to comment #23) > Administration is still not totally flawless but it seems to be working pretty > well here. I would welcome feedback on this. One other administrative issue is that while there is an attach extension to the normal init.d commands, there is no detach function, as in boinc_cmd --project http://setiathome.berkely.edu detach Of course the problem with this is that boinc then deletes the /var/lib/projects /<Project_URL> directory. Maybe the solution to this problematic behaviour is to install the project XML file and the executable somewhere in /usr/lib/${PN} and then make symlinks there from /var/lib/projects/<Project_URL>. Then, the init.d script can restore those symlinks after boinc_cmd (or boinc) has removed them in attach(). However, since an admin could also use boinc_cmd to attach and detach projects, we'd probably need a fix_boinc.sh script too that the admin can call after 'boinc_cmd ... attach' has removed the symlinks. In all of this I assume boinc doesn't actually dereference those symlinks...
On a system without X, emerge setiathome results in: make all-recursive make[1]: Entering directory `/var/tmp/portage/setiathome-4.18-r1/work/seti_boinc' Making all in jpeglib make[2]: Entering directory `/var/tmp/portage/setiathome-4.18-r1/work/seti_boinc/jpeglib' make[2]: *** No rule to make target `all'. Stop. make[2]: Leaving directory `/var/tmp/portage/setiathome-4.18-r1/work/seti_boinc/jpeglib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/setiathome-4.18-r1/work/seti_boinc' make: *** [all] Error 2
On an x86_64 system emerging setiathome works flawlessly, but it will not run properly. Here's the log message: Tue Dec 13 21:26:33 2005|SETI@home|Message from server: platform 'x86_64-pc-linux-gnu' not found It seems that the separator between the version (4.18) and the platform (x86_64-pc-linux-gnu) should be an underscore ('_') and not a dot ('.'). Renaming the setiathome client binary and modifying the app_info.xml file accordingly results in platform "anonymous", which is accepted by the server.
I am on Processor Inventory: 1 AuthenticAMD AMD Athlon(tm) 64 Processor 3200+ Processor(s) 2005-12-16 09:20:18 [---] Benchmark results: 2005-12-16 09:20:18 [---] Number of CPUs: 1 2005-12-16 09:20:18 [---] 1642 double precision MIPS (Whetstone) per CPU 2005-12-16 09:20:18 [---] 4241 integer MIPS (Dhrystone) per CPU Due to failing start own compiled setiathome i was runing this one: http://www.pperry.f2s.com/files/setiathome_4.07.3a_amd64-fftw3-static-pc-linux-gnu.tar.bz2 with average 6000s CPU time for WU. Now fixing file name for 4.18 version launched it and got little above 30000s CPU time for WU, and side effect - clock running faster, 40 min ahead in 24 h. Now I'mback to static setiathome and later will report if there still time drift or it is gone.
adding to my previous post, time drift isin general, not related only to setiathome
(In reply to comment #27) my values: P
(In reply to comment #27) my values: Pá 16. prosinec 2005, 23:35:04 CET||Processor Inventory: 1 AuthenticAMD AMD Athlon(tm) 64 Processor 3000+ Processor(s) Ne 18. prosinec 2005, 13:40:14 CET||Benchmark results: Ne 18. prosinec 2005, 13:40:14 CET|| Number of CPUs: 1 Ne 18. prosinec 2005, 13:40:14 CET|| 1368 double precision MIPS (Whetstone) per CPU Ne 18. prosinec 2005, 13:40:14 CET|| 3562 integer MIPS (Dhrystone) per CPU > Now fixing file name for 4.18 version > launched it and got little above 30000s CPU time for WU, up to date, I have finished 3 WUs and all the times were more than 9 hours - with claimed credit about 102 and granted credit about 25 ... very strange ... > and side effect - clock running faster, I cannot confirm this, my clock is OK
there is a problem with attaching to projects - if I emerge setiathome, it installs /var/lib/boinc/projects/setiathome.berkeley.edu/setiathome-4.18.x86_64-pc-linux-gnu but if I run '/etc/init.d/boinc attach' and set up my account, the contents of the directory /var/lib/boinc/projects/setiathome.berkeley.edu/ gets deleted and I have to reemerge setiathome to be able to compute (since boinc is unable to download seti client for amd64 itself and the "anonymous" binary is gone) I suppose it is boinc bug (feature?), but ... if the gentooish way is to emerge setiathome which pulls boinc as dependency and not to install separately boinc and then setiathome (or I suppose it to be meant this way??? :-)) then could somebody write a patch to boinc not to delete the binary? (speaking about boinc 4.72.20050813-r3)
I will take another look at this when I get chance over the Xmas break. I have already attempted to address this but I now see the flaw in my previous attempt. If anyone has any patches I would be glad to look at them as this has always been a problem with the new boinc. May be tracking down the function in the source and addressing it there would be the best approach.
Yesterday sci-misc/boinc-5.2.14 was brought out of package.mask. I could not attach to any project, this was the output I got: # /etc/init.d/boinc attach Enter the Project URL: http://setiathome.berkeley.edu Enter your Account Key: [removed] * Attaching to project ... [ !! ] 2006-01-21 11:25:59 [---] Memory: 504.20 MB physical, 251.01 MB virtual 2006-01-21 11:25:59 [---] Disk: 4.63 GB total, 838.14 MB free 2006-01-21 11:25:59 [---] No general preferences found - using BOINC defaults 2006-01-21 11:25:59 [---] Remote control not allowed; using loopback address 2006-01-21 11:25:59 [---] This computer is not attached to any projects. 2006-01-21 11:25:59 [---] There are several ways to attach to a project: 2006-01-21 11:25:59 [---] 1) Run the BOINC Manager and click Projects. 2006-01-21 11:25:59 [---] 2) (Unix/Mac) Use boinc_cmd --project_attach 2006-01-21 11:25:59 [---] 3) (Unix/Mac) Run this program with the -attach_projec t command-line option. 2006-01-21 11:25:59 [---] Visit http://boinc.berkeley.edu for more information Then I tried to attach "by hand": # boinc_cmd --project_attach http://setiathome.berkeley.edu [removed] RPC_CLIENT::init connect 2 on 3 returned -1 Authorization failure: -155 And tried another command: # boinc_cmd --get_state RPC_CLIENT::init connect 2 on 3 returned -1 Authorization failure: -155 This fixed the behaviour: # cd /var/lib/boinc/ # ls client_state.xml client_state_prev.xml gui_rpc_auth.cfg lockfile # cp gui_rpc_auth.cfg gui_rpc_auth.xml With the result: # boinc_cmd --get_state RPC_CLIENT::init connect 2 on 3 returned -1 ======== Projects ======== ======== Applications ======== ======== Application versions ======== ======== Workunits ======== ======== Results ======== # /etc/init.d/boinc attach Enter the Project URL: http://setiathome.berkeley.edu Enter your Account Key: [removed] * Attaching to project ... [ ok ] 2006-01-21 11:39:02 [http://setiathome.berkeley.edu/] Reason: Requested by user 2006-01-21 11:39:02 [http://setiathome.berkeley.edu/] Requesting 8640 seconds of new work 2006-01-21 11:39:06 [http://setiathome.berkeley.edu/] Scheduler request to http: //setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded 2006-01-21 11:39:06 [SETI@home] General preferences have been updated 2006-01-21 11:39:06 [SETI@home] New host venue: home 2006-01-21 11:39:06 [---] General prefs: from SETI@home (last modified 2005-11-3 0 10:09:23) 2006-01-21 11:39:06 [---] General prefs: using your defaults 2006-01-21 11:39:06 [SETI@home] Successfully attached to SETI@home 2006-01-21 11:39:07 [SETI@home] Started download of setiathome_4.02_i686-pc-linu x-gnu 2006-01-21 11:39:07 [SETI@home] Started download of [work unit] Hope that helps Christian
*** Bug 120392 has been marked as a duplicate of this bug. ***
I just built a new amd64 system and installed setiathome: emerge seitathome. Everything built as expected but I got the error, similar to message 26: 2006-02-28 01:31:20 [SETI@home] Message from server: platform 'x86_64-pc-linux-gnu' not found when I tried to attach. This is similar to the error described in message 30. My solution was to emerge setiathome again and after restarting: /etc/init.d/boinc restart everything started up. I think that message 30 is on the right track. I would be glad to test the install and attach sequence again if that would help.
Added ~alpha keyword to boinc and setiathome.
setiathome-3* no longer in portage, closing.
