Bugzilla Bug 54962

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 an attachment (id=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 an attachment (id=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 an attachment (id=34244) [details]
conf.d script for BOINC

Created an attachment (id=34245) [details]
init.d script for BOINC

Created an attachment (id=34246) [details]
Wrapper script for BOINC

Created an attachment (id=34247) [details]
Patch for client-only build of BOINC, MySQL not required

Created an attachment (id=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 an attachment (id=34249) [details]
Whoops! Nearly... fixed a really stupid typo

/var/lib/boinc, not /var/lib...

Created an attachment (id=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 an attachment (id=34281) [details]
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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=39545) [details]
Nightly Build 2004-09-13 Client Only (No MySQL)

Created an attachment (id=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 an attachment (id=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 an attachment (id=43326) [details]
The boinc-1.0 License

This will need to be added when boinc is added...

Created an attachment (id=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 an attachment (id=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 an attachment (id=49443) [details]
Boinc 4.17 ebuild:  new license and version

Created an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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.