The summary says it all. The URI is above. So, let's get an ebuild ready! This one you can ACTUALLY COMPILE YOURSELF, which is kinda cool. I'll have a look at this today, but if someone beats me to it, then an ebuild will be ready rather quicker than I could manage. But let's try not to lose any functionality already in the current 3.08-rX ebuild - like using FHS-compliant data locations, which I think the binary SETI@home/BOINC breaks AFAICS... Reproducible: Always Steps to Reproduce:
An ebuild would be nice - this time dropping root priviledges! Actually, what you can compile yourself is the BOINC program itself. The SETI program which is doing all the work is still downloaded in binary by BOINC (which I can understand). Putting the BOINC binary in /opt or compiling it and putting it in /usr/bin is no problem, but along with the work unit data, the SETI binary is now dynamically updated by BOINC, together with the rest of the state information in /var/lib. An ebuild could be very simple, since BOINC automagically takes care of running multiple instances on multiprocessor machines, and it also does work unit queueing.
Created attachment 34098 [details] Sample init.d and conf.d scripts These scripts assume an existing boinc user, and a boinc binary in /opt/boinc. The /var/lib/boinc directory should probably be created in the ebuild (not in the init.d script), so that the boincwrapper can be copied to /var/lib/boinc. The init.d script also attempts to start boinc for the first time, allowing the user to enter project url and account key. Together, these run as an unprivileged user, writing stdout and stderr to a custom log file.
Created attachment 34243 [details] Ebuild for boinc-3.19 (CVS snapshot) This is an ebuild for BOINC 3.19. It's a CVS snapshot, as the servers appear to be dead at the moment. A hefty patch is required to tear the MySQL dependency out (only required for the server install, which we don't want); this follows. Also, there are sample conf.d, init.d and wrapper scripts, as provided above - these will be reattached in order to give them their correct names. Each should go in ${FILESDIR}.
Created attachment 34244 [details] conf.d script for BOINC
Created attachment 34245 [details] init.d script for BOINC
Created attachment 34246 [details] Wrapper script for BOINC
Created attachment 34247 [details, diff] Patch for client-only build of BOINC, MySQL not required
Created attachment 34248 [details] A tarball of the above, for the lazy amongst you ;-) Extract this (if you plan to use it) to ${PORTDIR_OVERLAY}/app-sci/boinc/ .
Created attachment 34249 [details] Whoops! Nearly... fixed a really stupid typo /var/lib/boinc, not /var/lib...
Created attachment 34250 [details] ...and a new tarball.
Oh, and by the way, this should start with priority 19, not 0 - I don't know how to do this yet. Anyone?
Use start-stop-daemon -N <nicelevel> in the init script? See start-stop-daemon --help
Problems with ebuild: it installs the boincwrapper in /var/lib/boinc, creating /var/lib/boinc with root ownership. If a user then goes to run su boinc -c boinc_client this breaks, because it can't write to /var/lib/boinc. Ebuild should install this directory with boinc:boinc permissions?
Ahhh, bugger, yes, you're right. I'm working on getting the actual SETI programme compiled at the moment, and I think I broke something, so I'll have to sort this later - the fix is trivial, though.
Created attachment 34281 [details, diff] adds nicelevel and fixes permissions problem This patch fixes the 2 issues I noted in previous msgs. btw I hope you are making the seti stuff a separate ebuild from boinc?
Thanks for fixing that. The SETI stuff will indeed be a seperate ebuild. But right now it doesn't even want to think about compiling - I suspect it's a GCC 3.4 specific issue, at a guess, as the source is absolutely horrible.
Created attachment 34291 [details] Ebuild and files for building the seti program for use with boinc See the code, but it has to build the lib directory of boinc, then build the client. There are a few additional patches to boinc, and a couple of small tweaks to the client, to get it to work. Give it a try? There's no GCC 3.4 issue that I can see. My main question is what to do with the app after you've built it! -- Given you don't know what slot the user's going to want it in. So at the moment I'm just installing it to /var/lib/boinc/apps with an info message saying that's where it is and roughly what to do with it.
Scratch my last about GCC 3.4, I'm using gcc 3.3, I forgot I'd reverted.
I think the ebuild and files in the tarball in comment #10 together with the patch to it in comment #15 constitute a solution that could be added to the portage tree. The ebuild I submitted for compiling the seti program itself, in the tarball #17, probably isn't worth considering, since the Boinc program enables projects to send new compiled application code at run-time which would replace anything compiled with this code.
Created attachment 35486 [details] v3.20 ebuild and files This is a modified version of the previous ebuild that John recommended for inclusion to portage. I updated it to Boinc 3.20, and also they have started making a a new nightly tarball called boinc_public-cvs-2004-07-13.tar.gz, etc. I am not sure what the difference is between this and the non-'public' one, but I am pretty sure we should use it. Anyway, I have tested this on two x86 machines and it works great for me. It would be a good thing to have in portage. Thanks.
Created attachment 38771 [details] Boinc 4.08 nightly 2004-09-02 Ebuild for the nightly cvs 2004-09-02 based upon previus ebuild in this bug.
Created attachment 39545 [details] Nightly Build 2004-09-13 Client Only (No MySQL)
Created attachment 41894 [details] boinc 4.11 official release ebuild Here is an updated ebuild that uses the official 4.11 source tarball in the /source/archive/ directory on the boinc website.
Does this also work on AMD64 platform in 64-bits?
Created attachment 43259 [details] boinc 20041103 (4.13) nightly ebuild Here is the latest version of boinc. I talked to some of the guys over at boinc about releasing official version tarballs when they release a new version, but for some reason they were reluctant to do so. (Couldn't tell you why) So apparently, we will either have to check out the version from cvs and create our own tarballs or use the nightlies. Also, I would like some one to tell me the reason boinc isn't in portage yet...
Sorry, Tony, but when you have a look at http://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_severity=enhancement&emailassigned_to1=1&emailtype1=substring&email1=sci%40gentoo.org&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= you can see a few reasons. And this is only enhancements - we still have enough more serious bugs. Please also check http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=3 for other (minor) reasons.
I just emerged the latest ebuild on my AMD64 machine in 64-bits. All seams to be working fine. The only problem is that even if I run "/etc/init.d boinc stop" and then try to run "boinc_client" by hand (I would like to add/attach another project) it always tels me that it is already runing even if I don't see it in the list of processes.
Created attachment 43326 [details] The boinc-1.0 License This will need to be added when boinc is added...
Created attachment 43327 [details] boinc 4.13 and setiathome 4.07 ebuilds Ok, I've done quite a bit of work on this to add support for a compiled setiathome client and some clean ups too. I'm sorry to see that app-sci has so much work to do. I'd offer to help, but the only program I've ever touched in app-sci is setiathome. After some investigation, it looks like boinc_public is only updated when there is a release, so it will be fine just to grab some nightly and call it version 4.07 or whatever it says in configure.ac. I have attached the boinc-1.0 license to this bug, it is required for boinc, but setiathome is GPL-2. If your are using the setiathome ebuild in the tarball, you may want to watch your units, if all or most of them are being rejected, there may be a problem...
Created attachment 43434 [details] boinc 4.13 ebuild I moved the setiathome ebuild into it's own bug #70303. I also cleaned up the ebuild more, and moved some files into better locations.
I'm keen on working on this again. Hopefully with a bit more success this time, too :-P If I ever meet anyone who works for BT Broadband, I swear I'll forcibly remove their testicles and send them through a golf ball washer. How can it take SEVEN WEEKS to transfer a connection when you move house?!?! Anyway, as such, as long as I'm happy enough with what I see, this package may yet have a maintainer (me)...
License changed to LGPL
Created attachment 49443 [details] Boinc 4.17 ebuild: new license and version
Created attachment 49577 [details] Version Bump to 4.19
Hmm... Will BOINC ever be released to Portage? 8 months since this bug was filed... Thanks for your work!
Yea, I was wondering the same thing. Shouldn't this have been approved and moved into the tree already? It obsoletes the old seti client and allows for many other projects.
Created attachment 51637 [details] boinc 4.62 ebuild I've attached an ebuild of the development version of boinc 4.62, which includes a wxGTK client boinc_gui! If you haven't done so, you should unmerge old boinc versions and move your boinc dir in your portage overlay to sci-astronomy instead of the old app-sci. This ebuild is much cleaner than the ones for non-development versions, kudos to the boinc dev team for cleaning up the makefiles :) I would definately suggest this for inclusion in portage, unless it being for the dev version is a problem. There are a few items (depends, server use flag, ??) that might need changing before putting this in portage, if so please bring them up here. This ebuild uses some USE flags, and also adds a local use flag "server", which enables building the boinc server for those interested (almost no one). I haven't tested building the server yet as I don't want to install mysql on my test system. Also, the gui/client take up 100% cpu on my system (amd64) when running (not doing computations), so you've been warned ;)
> sci-astronomy instead of the old app-sci. This seems inappropriate to me, BOINC is used for many non-astronomy projects.
I would agree with that, but what would be a more appropriate category? sci-misc, that's where zetagrid is...
About comments #35 and comment #36 - my comment #26 is still valid, we have about 50 normal bugs and about 170 open enhancement requests, some of which are much older than this one. So we need some pills which eliminate the need for sleep, a few more developers or you need even more patience than you already had. Sorry!
i recently tried out the 4.62 ebuild the problems i found was that the gui client doenst compile when wxGTK unicode support and without unicode i get some weird missing symbol error also when -X is set and wxGTK is installed it still trys to compile with wx i notice its just a snapshot so i might try latest and see if it makes any difference
Created attachment 51892 [details] boinc 4.19 and 4.62 ebuilds and supporting files Ok, I've fixed that issue. Now when you specify -X, it really doesn't even check for it. Sorry about that, I assumed if the libraries were there then people wouldn't care if the gui got built... I guess there are reasons to truly disable it... Tell me how this new one works for ya.
Created attachment 51893 [details] boinc 4.19 and 4.62 ebuilds and supporting files (fixed)
* Adding group 'boinc' to your system ... * - Groupid: next available groupadd: group boinc exists !!! ERROR: sci-misc/boinc-4.62 failed. !!! Function enewgroup, Line 878, Exitcode 9 !!! enewgroup failed getting this error now for the moment im just going to comment it out to test the use flags
doesnt work only way i got it to not use wx was to add --with-wx-config=nonono aka give it a configure program that doesnt exist and the patch in the following bug solved that missing symbol issue i had http://bugs.gentoo.org/show_bug.cgi?id=82207
the groupadd bug looks like a problem with eutils.eclass (part of portage). Ok, looks like --without-x doesn't disable wxWidgets for some reason, but we do want that behavior... I'll keep looking into it.
might want to look at the games eclass to see what it does as i think it will add missing group/user if it isnt there not sure tho also some projects have a screensaver/graphic to look at to get this to work for now im adding export DISPLAY=:0 just before boinc is loaded in the wrapper perhaps somethin could be added to the conf.d item so the user can set this when they want to see the graphic easily also an option to add -allow_remote_gui_rpc option to boinc so the gui can be ran on a remote comp (handy to admin headless comps) would be a handy option to have also
Created attachment 52024 [details] boinc 4.19 and 4.66 ebuilds and files Ok, I've updated it to the latest tagged version in cvs 4.66. I've updated the scripts to support allow remote rpc's by default, and put a config option in the conf.d file. Now you can view multiple clients on one gui client, like the included Boinc Manager(boinc_gui). I started to looking into properly setting DISPLAY there too, but couldn't get setiathome to build against 4.66 to enable graphics. What project has graphics suppport in linux? Also, still no progress on disabling wxgtk properly...
http://einstein.phys.uwm.edu/ that project has graphics that work in linux ill test out the updated items later today
Hi! Since the ebuild dies when trying to build with X and glut, if the system /usr/bin/wx-config points to /usr/bin/wxGTK2u-?.?-config (that is, the unicode version), perhaps it would be A Good Thing to add something like --with-wx-config /usr/bin/wxGTK2-?.?-config to the ECONF-line. Of course it would have to depend on the X use-flag and what version of wxGTK ve have and stuff like that.. :)
the rpc bit works for me i added export DISPLAY in the init script to get graphics to display dunno if thats allowed or not but it works Mikael: i tried the unicode config as per your suggestion and no diff for me but perhaps someone that doesnt have gtk 2.6 installed can try as that might be part of my problem right now all i know is im starting to really dislike wx ;)
Created attachment 52131 [details] boinc 4.19 and 4.66 ebuilds and files (new) Well, I've made the ebuild force wxconfig to use the non-unicode config. Please tell me if it helps. Also, I have gtk+ 2.6 on my machines, so that isn't what is causing the problem. None have unicode support so, I can't reproduce the compile failure. I think I have DISPLAY being set adequately enough, but I couldn't get graphics to display for me. Please report whether graphics works or not. I also add a bit that truncates the log file everytime you start boinc to keep the log from growing too large.
Setting the wx-config worked here, no more missing symbols from wx. I did rebuild wx recently with the patch from http://bugs.gentoo.org/show_bug.cgi?id=82207 that Bret mentioned.. However, the last build while still using unicode GTK failed on the missing symbols.. With the DISPLAY set and wx and glut, I can get both the GUI and the project specific graphics for einstein@home. These graphics are somewhat sporadic though, but I believe that's the GUI's fault.. (e.g. the graphics for a project can only be shown when that project is running even if the GUI shows the "show graphics" label.. ) For the reference, I'm running wxGTK2.4.2-r2.
var/lib/boinc/boinc.log might have permission issue ?! I started it as root with with "/etc/init.d/boinc start" Gave URL and key (einstein project). It then failed with "permission denied" message for the log file. I checked the file created /var/lib/boinc/boinc.log was effectively root owned when the rest of the files are boinc owned. Log file is of course empty. Service did not start. And re-run of script refused to start it as still marked "already started". I emerged 4.66 on amd64. PS:After that, I also tried boinc_gui which use 100% CPU but no process seems to be running except boinc_gui. my project is listed in account_einstein.phys.uwm.edu.xml file but not in GUI and cannot add project in GUI. I assume all this is consequence of problem above so probably irrelevant.
Created attachment 53033 [details] boinc 4.19 and 4.66 ebuilds and files (-r3) Some ebuild cleanups that I thought I should get out there. I was waiting for a new boinc release to be tagged, but it's taking to long ;) Allows users to set the EXTRA_ECONF variable on the commandline, like the should be able to... I also fixed the permision denied on the logfile, the problem is root creates the file(attempting to truncate it) before the boinc process can. If you have this problem run this "chown boinc:boinc /var/lib/boinc/boinc.log" as root to fix it (with or without upgrading to this ebuild). There are no other changes in this if your previous install works fine, there is no reason to upgrade.
So, now that there's a new Forum called "Unsupported Software" in the Gentoo Forums, should this be moved out of the Portage bugzilla into that as a thread, since this will probably never make it into Portage proper in the next 6 months or so, based on its current pace? Might be easier, actually, since the first post in the thread can be the HOWTO and new changes can be edited into that same message.
You might want to keep the development on Bugzilla so Gentoo developers can keep track of it. Linking this bug from a forum thread is probably the best thing to do.
*** Bug 84799 has been marked as a duplicate of this bug. ***
Created attachment 56597 [details] boinc 4.32 ebuild and files I've posted a new ebuild for boinc since they have finally released a new version. 4.32 is newer than 4.66. Before you unpack this tarball, you should remove the boinc directory in your portage overlay. I've done more clean ups and changed the default location of the boinc log file to /var/log/boinc.log. If anyone is using this ebuild to run a boinc server, I would like to know because I have no (easy) way of testing the server portion of this ebuild, only that it compiles...
I have compiled the current stable version, and was looking at the unstable which didn't compile. I will take a look at the new unstable version. Can't download the setiathome sources right now though. I am hoping to resolve all the remaining issues and get this into portage.
the setiathome sources have moved, I am currently working on a new ebuild for that, but the build system still depends on the boinc sources being present... The setiathome ebuild is not needed to run setiathome, unless you are on a non-x86 platform. So, setiathome should NOT block the inclusion of boinc into portage, especially since there are other projects that use boinc. Also, there is a small unimportant error in the boinc 4.32 ebuild, that shoudl be fixed if this is included in portage. Remove /var/log/boinc.log from the fowners line...
I am using amd64 machines to test mainly, and so it will hinder my testing. I have one slow x86 machine to test on. I want to ensure that boinc/setiathome are set up correctly as if I add this to portage I will be responsible for maintaining it. I am currently testing boinc, but will need at least a few days to test it and get to grips with the ebuilds and init files etc. It would be helpful if the files were provided as plain text files too, but I can work with them as they are for now. This will be a high priority for me to add, but I won't add it until I am happy with it.
Currently 4.32 seems to be fairly broken - it never prompts for project URL/key and so no work units are ever processed. Also can't seem to get it to work manually with boic_client -attach_project
Created attachment 56676 [details] boinc 4.32 ebuild and files More and more clean up. I removed the use of boincwrapper all-together. I created two patches to fix mess ups on berkeley's end. One fixes command line project attach, the other fixes gui connection issues. Then I changed the init script. It always starts boinc, no matter if you have attached to a project or not. If you haven't it gives you a friendly notice on how to attach to a project. I added a commandline option: /etc/init.d/boinc attach it stops boinc, registers a new project, then starts boinc... Enjoy
OK - I think this is all coming along very well. Outstanding issues are that completed units do not seem to be uploaded, the graphics bit seems to be broken here at least and the stats produced may be way off. I am still waiting on whether the returned units are accepted too... Some examples of my time, my claimed credits, someone else's time and claimed credits are 35,813.07 126.83 13,078.02 24.56 22,550.65 70.90 9,448.91 16.62 Quite a difference I am sure you will agree. This is on two different Athlon64 systems (a 1GB, 1MB cache 3200+ and a 0.5GB, 0.5MB cache 3200+). These could all be bugs of the current development code - but I don't want to put a broken client into portage :) I would like to see if the units are valid too.
Right - I have added 4.19 and 4.32 to portage as sci-misc/boinc. They are all package.masked right now, and I would appreciate testing on them. I would like to thank Tony Murray for all the work he has put into these ebuilds, and we have exchanged more than a few emails trying to perfect these ebuilds. Add sci-misc/boinc to /etc/portage/package.unmask to be able to emerge it. 4.19 is their current stable, and 4.32 is their current development version. There are still some issues with the compiled setiathome client so this may take a little longer to add.
