You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Marcus Crafter <cr...@managesoft.com> on 2005/01/03 17:20:54 UTC
Updating Forrest for debian, packaging questions
Hi All,
Hope all is going well. Happy New Year to all. :)
After a nice weekend I thought I'd get started updating the Forrest
Debian package from 0.5.1 to 0.6.
Yesdarday I downloaded the updated sources and saw that a few things had
changed wrt. the build process and how Forrest is to be distributed.
From my first inspections, it seems that Forrest is now with the source
and binary archive acting as one? ie. with run scripts referencing files
that in src/ directories and so forth. Is this the case? Doing a
./build.sh dist seems to make a copy of the apache-forrest-0.6 directory
under build/dist completely.
Normally, Debian packages are split in 2, potentially more packages -> a
source and binary package (perhaps multiple with software,
documentation, etc), with the binary containing only whats needed to run
the software, and the source package containing everything whats needed
to reproduce the binary package/s.
Obviously in Forrest's case, much of the source can be considered binary
content verbatim (eg. stylesheets, etc), but things like java source,
etc, normally wouldn't be bundled in a Debian binary package - so I was
wondering if there was a list (or if someone might be able to list) the
directories in the forrest.tgz that are required for running Forrest, as
opposed to purely source code used for building it? Any thoughts there
at all?
I've already done some playing with the package itself. The 0.5 version
of the package installed Forrest to /usr/share/forrest (pretty much was
the contents of the build directory from a ./build.sh dist from memory).
From anywhere on the system, /usr/bin/forrest would use the single
installation for all users.
This behaviour seems to have changed somewhat from what I can tell - as
this approach currently fails with a:
ERROR 2005-01-03 17:02:03.791 [ ] (): Directory '.' is not
readable/writable
Exception in thread "main" java.io.IOException: Directory '.' is not
readable/writable
at
org.apache.cocoon.bean.CocoonWrapper.getDir(CocoonWrapper.java:253)
at
org.apache.cocoon.bean.CocoonWrapper.initialize(CocoonWrapper.java:106)
at org.apache.cocoon.bean.CocoonBean.initialize(CocoonBean.java:98)
at org.apache.cocoon.Main.main(Main.java:320)
after attempting to generate a site.
The directory is:
<java classname="org.apache.cocoon.Main"
fork="true"
** dir="${forrest.home}/context"
maxmemory="${forrest.maxmemory}"
ie. ${forrest.home}/context, from what I can tell,
This at the moment resovles to /usr/share/forrest/src/core/context which
is normally not writable by users (eg. root.root ownership, 755 dir perms).
Is a 'single forrest installation' still intended to work ok, or should
each user actually be working with their own copy of forrest locally?
Hope this isn't too much off the bat - just trying to learn as much as I
can about how Forrest is intended to run and be installed so I can make
the package the best as possible.
Hope everyone has a nice evening.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft Corporation
$ o_)$$$: Frankfurt am Main, Germany
;$, _/\ &&:'
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
Re: Updating Forrest for debian, packaging questions
Posted by Marcus Crafter <cr...@managesoft.com>.
Hi Cheche,
Juan Jose Pablos wrote:
>>>From my first inspections, it seems that Forrest is now with the
>>source and binary archive acting as one? ie. with run scripts
>>referencing files that in src/ directories and so forth. Is this the
>>case? Doing a ./build.sh dist seems to make a copy of the
>>apache-forrest-0.6 directory under build/dist completely.
>>
>
> There is another restructure in the svn, so I think that maybe would be
> worth to try to use the development version.
Ok, thanks for the heads up about that. Is there perhaps an estimate
timeline for the next Forrest release at all? Just wondering as
generally Debian includes released software - but there has been
exceptions to this.
> Maybe we can add the debian stuff under whiteboard/debian
Sure, I'd be happy to have the debian control files etc in SVN assuming
it's ok with everyone else. I'm totally happy with what the
community/group, would like to do.
>>Obviously in Forrest's case, much of the source can be considered
>>binary content verbatim (eg. stylesheets, etc), but things like java
>>source, etc, normally wouldn't be bundled in a Debian binary package -
>>so I was wondering if there was a list (or if someone might be able to
>>list) the directories in the forrest.tgz that are required for running
>>Forrest, as opposed to purely source code used for building it? Any
>>thoughts there at all?
>
>
> There were suggestions from some people that wanted just the software
> to run. With the plugin effort forrest could be split in more packages.
Ok. The plugin effort sounds great :)
> I am pretty sure that this was a cocoon problem and it has been fixed. I
> have not been able to find the mails, but I am sure that it has been
> fixed on the development version.
Cool - Upayavira just confirmed it for us so that's good news.
>>Is a 'single forrest installation' still intended to work ok, or
>>should each user actually be working with their own copy of forrest
>>locally?
>
>
> I think that it should be a single forrest instalation, we have the
> forrest.home and the project.home for this.
Cool, I agree - having a single installation across multiple users would
be ideal as well.
>>Hope this isn't too much off the bat - just trying to learn as much as
>>I can about how Forrest is intended to run and be installed so I can
>>make the package the best as possible.
>>
>
> no problem, personaly I like debian a lot, I use for everything, and I
> think that this would help forrest to be more standard from the O.S. POV.
Glad to come across another happy Debian user :)
Thanks for your help - much appreciated :)
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft Corporation
$ o_)$$$: Frankfurt am Main, Germany
;$, _/\ &&:'
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
Re: Updating Forrest for debian, packaging questions
Posted by Marcus Crafter <cr...@managesoft.com>.
Hi Upayavira,
Thanks for that - if the check was removed then it might get a bit
further then.
I just had a further play -> it looks like Cocoon/Forrest is writing
it's log files into the ${context-root}/WEB-INF/logs directory according
to the context/WEB-INF/logkit.xconf configuration.
This will be the next issue then, as /usr/share/forrest/** would
normally be root.root ownership with no write permissions.
Should we perhaps reconfigure the logkit.xconf to log to a per user
location or similar? Any thoughts there?
Since this (and updating the Cocoon version to include the patch) would
be a change to the base dependencies for Forrest - is there a plan for a
point release of Forrest soon?
Thanks for everyone's help. :)
Cheers,
Marcus
PS. Yes, a Debian package for Cocoon would be great too.
There was a Cocoon1 package many eons ago, and from memory some attempts
at packaging Cocoon2 - but nothing really eventuated. I think mainly due
to the embedded nature of Cocoon itself (eg. if 2.1.6 was packaged, we
still couldn't depend on it for Forrest 0.6 as it uses a 2.2.0-dev cut).
I'll check with the original ITP (intent to package) holders to see what
the status is though, we might be able to take advantage of it in the
future. :)
Upayavira wrote:
> Juan Jose Pablos wrote:
>
>
>>Marcus Crafter wrote:
>>
>>
>>>>From anywhere on the system, /usr/bin/forrest would use the single
>>>installation for all users.
>>>
>>>This behaviour seems to have changed somewhat from what I can tell -
>>>as this approach currently fails with a:
>>>ERROR 2005-01-03 17:02:03.791 [ ] (): Directory '.' is not
>>>readable/writable
>>>Exception in thread "main" java.io.IOException: Directory '.' is not
>>>readable/writable
>>> at
>>>org.apache.cocoon.bean.CocoonWrapper.getDir(CocoonWrapper.java:253)
>>> at
>>>org.apache.cocoon.bean.CocoonWrapper.initialize(CocoonWrapper.java:106)
>>> at
>>>org.apache.cocoon.bean.CocoonBean.initialize(CocoonBean.java:98)
>>> at org.apache.cocoon.Main.main(Main.java:320)
>>>
>>
>>I am pretty sure that this was a cocoon problem and it has been fixed.
>>I have not been able to find the mails, but I am sure that it has been
>>fixed on the development version.
>
>
> There was a check to see if the context directory was writable. It was
> removed in SVN I believe.
>
> Upayavira, who wants to see Cocoon packaged for Debian too!
>
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft Corporation
$ o_)$$$: Frankfurt am Main, Germany
;$, _/\ &&:'
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
Re: Updating Forrest for debian, packaging questions
Posted by Upayavira <uv...@upaya.co.uk>.
Juan Jose Pablos wrote:
> Marcus Crafter wrote:
>
>> From anywhere on the system, /usr/bin/forrest would use the single
>> installation for all users.
>>
>> This behaviour seems to have changed somewhat from what I can tell -
>> as this approach currently fails with a:
>> ERROR 2005-01-03 17:02:03.791 [ ] (): Directory '.' is not
>> readable/writable
>> Exception in thread "main" java.io.IOException: Directory '.' is not
>> readable/writable
>> at
>> org.apache.cocoon.bean.CocoonWrapper.getDir(CocoonWrapper.java:253)
>> at
>> org.apache.cocoon.bean.CocoonWrapper.initialize(CocoonWrapper.java:106)
>> at
>> org.apache.cocoon.bean.CocoonBean.initialize(CocoonBean.java:98)
>> at org.apache.cocoon.Main.main(Main.java:320)
>>
> I am pretty sure that this was a cocoon problem and it has been fixed.
> I have not been able to find the mails, but I am sure that it has been
> fixed on the development version.
There was a check to see if the context directory was writable. It was
removed in SVN I believe.
Upayavira, who wants to see Cocoon packaged for Debian too!
Re: Updating Forrest for debian, packaging questions
Posted by Rick Tessner <ri...@apache.org>.
On Tue, 2005-01-04 at 08:29 +0100, Juan Jose Pablos wrote:
> Marcus Crafter wrote:
>
> > From anywhere on the system, /usr/bin/forrest would use the single
> > installation for all users.
> >
> > This behaviour seems to have changed somewhat from what I can tell -
> > as this approach currently fails with a:
> > ERROR 2005-01-03 17:02:03.791 [ ] (): Directory '.' is not
> > readable/writable
> > Exception in thread "main" java.io.IOException: Directory '.' is not
> > readable/writable
> > at
> > org.apache.cocoon.bean.CocoonWrapper.getDir(CocoonWrapper.java:253)
> > at
> > org.apache.cocoon.bean.CocoonWrapper.initialize(CocoonWrapper.java:106)
> > at
> > org.apache.cocoon.bean.CocoonBean.initialize(CocoonBean.java:98)
> > at org.apache.cocoon.Main.main(Main.java:320)
> >
> I am pretty sure that this was a cocoon problem and it has been fixed. I
> have not been able to find the mails, but I am sure that it has been
> fixed on the development version.
Yes, this was a cocoon problem. The cocoon that Forrest uses has been
upgraded on the forrest trunk (0.7-dev).
Cocoon for Forrest 0.6.1-dev has not yet been upgraded. It's something
I am currently working on but there are some interesting issues. I'll
compile a list (hopefully later on today or tomorrow) under a new
thread.
Rick
Re: Updating Forrest for debian, packaging questions
Posted by Juan Jose Pablos <ch...@apache.org>.
Marcus Crafter wrote:
>
> From my first inspections, it seems that Forrest is now with the
> source and binary archive acting as one? ie. with run scripts
> referencing files that in src/ directories and so forth. Is this the
> case? Doing a ./build.sh dist seems to make a copy of the
> apache-forrest-0.6 directory under build/dist completely.
>
There is another restructure in the svn, so I think that maybe would be
worth to try to use the development version.
Maybe we can add the debian stuff under whiteboard/debian
> Obviously in Forrest's case, much of the source can be considered
> binary content verbatim (eg. stylesheets, etc), but things like java
> source, etc, normally wouldn't be bundled in a Debian binary package -
> so I was wondering if there was a list (or if someone might be able to
> list) the directories in the forrest.tgz that are required for running
> Forrest, as opposed to purely source code used for building it? Any
> thoughts there at all?
There were suggestions from some people that wanted just the software
to run. With the plugin effort forrest could be split in more packages.
> From anywhere on the system, /usr/bin/forrest would use the single
> installation for all users.
>
> This behaviour seems to have changed somewhat from what I can tell -
> as this approach currently fails with a:
> ERROR 2005-01-03 17:02:03.791 [ ] (): Directory '.' is not
> readable/writable
> Exception in thread "main" java.io.IOException: Directory '.' is not
> readable/writable
> at
> org.apache.cocoon.bean.CocoonWrapper.getDir(CocoonWrapper.java:253)
> at
> org.apache.cocoon.bean.CocoonWrapper.initialize(CocoonWrapper.java:106)
> at
> org.apache.cocoon.bean.CocoonBean.initialize(CocoonBean.java:98)
> at org.apache.cocoon.Main.main(Main.java:320)
>
I am pretty sure that this was a cocoon problem and it has been fixed. I
have not been able to find the mails, but I am sure that it has been
fixed on the development version.
> Is a 'single forrest installation' still intended to work ok, or
> should each user actually be working with their own copy of forrest
> locally?
I think that it should be a single forrest instalation, we have the
forrest.home and the project.home for this.
>
> Hope this isn't too much off the bat - just trying to learn as much as
> I can about how Forrest is intended to run and be installed so I can
> make the package the best as possible.
>
no problem, personaly I like debian a lot, I use for everything, and I
think that this would help forrest to be more standard from the O.S. POV.
Cheers,
Cheche
Re: Updating Forrest for debian, packaging questions
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Marcus Crafter wrote:
> Hi David,
>
> David Crossley wrote:
...
> I think the local project space logging is the right approach too though:
>
> Turns out the that in logkit.xconf:
>
> ${context-root}/WEB-INF/logs
>
> configuration is actually resolved via a o.a.a.f.c.Context object. If we
> could have the user.dir/user.home/etc system property added to the
> DefaultContext inside Cocoon then this could be:
>
> ${user.dir}/build/logs
>
> which would create the logs in the build area of the site. Alternatively
> project.home could be used as well.
>
> What do you reckon mate?
Wait a sec, projects *already* log to the project build dir. I have made
our logger for this purpose. Is it not happening?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Updating Forrest for debian, packaging questions
Posted by Upayavira <uv...@upaya.co.uk>.
Marcus Crafter wrote:
> Hi David,
>
> David Crossley wrote:
>
>> Forrest-0.6+ has a default logkit.xconf and each project can supply
>> their own logkit.xconf to override that. (I have not tested that,
>> but supplying a cli.xconf works.) Would it be possible to not have
>> a global logkit.xconf and make each project supply it, by default
>> logging to a directory in their project space?
>
>
> Ok. Is there a local logkit.xconf created when seeding a new site
> though? If not I fear Debian users of Forrest will encounter the
> problem until they find out about this local logkit.xconf feature.
>
> I think the local project space logging is the right approach too though:
>
> Turns out the that in logkit.xconf:
>
> ${context-root}/WEB-INF/logs
>
> configuration is actually resolved via a o.a.a.f.c.Context object. If
> we could have the user.dir/user.home/etc system property added to the
> DefaultContext inside Cocoon then this could be:
>
> ${user.dir}/build/logs
>
> which would create the logs in the build area of the site.
> Alternatively project.home could be used as well.
>
> What do you reckon mate?
It at least sounds plausible!
Regards, Upayavira
Re: Updating Forrest for debian, packaging questions
Posted by Marcus Crafter <cr...@managesoft.com>.
Hi David,
David Crossley wrote:
> Forrest-0.6+ has a default logkit.xconf and each project can supply
> their own logkit.xconf to override that. (I have not tested that,
> but supplying a cli.xconf works.) Would it be possible to not have
> a global logkit.xconf and make each project supply it, by default
> logging to a directory in their project space?
Ok. Is there a local logkit.xconf created when seeding a new site
though? If not I fear Debian users of Forrest will encounter the problem
until they find out about this local logkit.xconf feature.
I think the local project space logging is the right approach too though:
Turns out the that in logkit.xconf:
${context-root}/WEB-INF/logs
configuration is actually resolved via a o.a.a.f.c.Context object. If we
could have the user.dir/user.home/etc system property added to the
DefaultContext inside Cocoon then this could be:
${user.dir}/build/logs
which would create the logs in the build area of the site. Alternatively
project.home could be used as well.
What do you reckon mate?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft Corporation
$ o_)$$$: Frankfurt am Main, Germany
;$, _/\ &&:'
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
Re: Updating Forrest for debian, packaging questions
Posted by David Crossley <cr...@apache.org>.
Marcus Crafter wrote:
>
> Any thoughts at all?
Forrest-0.6+ has a default logkit.xconf and each project can supply
their own logkit.xconf to override that. (I have not tested that,
but supplying a cli.xconf works.) Would it be possible to not have
a global logkit.xconf and make each project supply it, by default
logging to a directory in their project space?
--David
Re: Updating Forrest for debian, packaging questions
Posted by Thorsten Scherler <th...@apache.org>.
Hi Marcus,
I am using Guadalinex, which is based on Debian SID. ...and I am
*really* happy with Debian. Lots of thanks over to that community.
Cheers that you are trying o package forrest. I may find some time to
use your paths and try to make it running.
...again million thanks to debian and you.
thorsten
El mar, 04-01-2005 a las 16:57, Marcus Crafter escribió:
> Upayavira wrote:
> >>/var/log/forrest might be a better position for the logs but it's
> >>still global, perhaps even better would be a local directory to each
> >>generated site (perhaps we could use project.home for this?)
> >
> > Question is, can you get a value from an Ant property (e.g.
> > project.home) into Cocoon and then logkit.xconf? How would you do that?
> > That is really the problem you would have to solve, as I see it.
> >
> > Now, Carsten implemented a new ConfigurationBulder that allows property
> > replacement in cocoon.xconf. If you could get it to work on
> > logkit.xconf, you would have your way.
>
> Well, ant has the "basedir" property passed to it, so it would be
> possible to pass this to Cocoon via the <java ...> invocation as a -D
> parameter, however logkit.xconf reads its ${variable} details from a
> o.a.a.f.c.Context instance...
>
> hmm.. still digging for more info.
>
> Cheers,
>
> Marcus
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Updating Forrest for debian, packaging questions
Posted by Marcus Crafter <cr...@managesoft.com>.
Upayavira wrote:
>>/var/log/forrest might be a better position for the logs but it's
>>still global, perhaps even better would be a local directory to each
>>generated site (perhaps we could use project.home for this?)
>
> Question is, can you get a value from an Ant property (e.g.
> project.home) into Cocoon and then logkit.xconf? How would you do that?
> That is really the problem you would have to solve, as I see it.
>
> Now, Carsten implemented a new ConfigurationBulder that allows property
> replacement in cocoon.xconf. If you could get it to work on
> logkit.xconf, you would have your way.
Well, ant has the "basedir" property passed to it, so it would be
possible to pass this to Cocoon via the <java ...> invocation as a -D
parameter, however logkit.xconf reads its ${variable} details from a
o.a.a.f.c.Context instance...
hmm.. still digging for more info.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft Corporation
$ o_)$$$: Frankfurt am Main, Germany
;$, _/\ &&:'
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
Re: Updating Forrest for debian, packaging questions
Posted by Upayavira <uv...@upaya.co.uk>.
Marcus Crafter wrote:
>>
>> Is http://issues.cocoondev.org/browse/FOR-356 relevant? (I confess to
>> not having absorbed your problem, or that in the issue, but instinct
>> seems to link them)
>
>
> This is the one. From Upayavira's email it looks like it's been fixed
> in Cocoon SVN (ie. the writable check isn't done), however the log
> files still attempt to write to this location according to the
> logkit.xconf configuration.
>
> Since I've currently got Forrest installing to /usr/share/forrest/**,
> we can't have anything write to
> /usr/share/forrest/src/core/context/WEB-INF/logs, as from memory,
> Linux FHS or Debian policy (not sure which one) says that /usr may be
> shared amongst systems and be read-only.
>
> /var/log/forrest might be a better position for the logs but it's
> still global, perhaps even better would be a local directory to each
> generated site (perhaps we could use project.home for this?)
Question is, can you get a value from an Ant property (e.g.
project.home) into Cocoon and then logkit.xconf? How would you do that?
That is really the problem you would have to solve, as I see it.
Now, Carsten implemented a new ConfigurationBulder that allows property
replacement in cocoon.xconf. If you could get it to work on
logkit.xconf, you would have your way.
Regards, Upayavira
Regards, Upayavira
Re: Updating Forrest for debian, packaging questions
Posted by Marcus Crafter <cr...@managesoft.com>.
Hi Ross,
Thanks for your response, much appreciated mate.
Ross Gardler wrote:
> Marcus Crafter wrote:
> > so I was
>
>>wondering if there was a list (or if someone might be able to list) the
>>directories in the forrest.tgz that are required for running Forrest, as
>>opposed to purely source code used for building it? Any thoughts there
>>at all?
>
>
> (do not consider this response necessarily complete, it is just my
> "off-the-top-of-my-head response")
>
> Pretty much all of them are required when running Forrest with the
> exception of src/java and src/forestlogos. It could be argued that
> src/forrestbar and src/forrestbot are not needed, these are external
> tools and not required by Forrest core, the same goes for scratchpad/**.
Ok - cool, thanks for that, good to know what's needed and not.
> A great deal of the other files are only used in quite specific
> circumstances, plugins in 0.7 are allowing us to move these files into
> optional packages, but that is a different story.
Ok.
>>This at the moment resovles to /usr/share/forrest/src/core/context which
>>is normally not writable by users (eg. root.root ownership, 755 dir perms).
>>
>>Is a 'single forrest installation' still intended to work ok, or should
>>each user actually be working with their own copy of forrest locally?
>
>
> Is http://issues.cocoondev.org/browse/FOR-356 relevant? (I confess to
> not having absorbed your problem, or that in the issue, but instinct
> seems to link them)
This is the one. From Upayavira's email it looks like it's been fixed in
Cocoon SVN (ie. the writable check isn't done), however the log files
still attempt to write to this location according to the logkit.xconf
configuration.
Since I've currently got Forrest installing to /usr/share/forrest/**, we
can't have anything write to
/usr/share/forrest/src/core/context/WEB-INF/logs, as from memory, Linux
FHS or Debian policy (not sure which one) says that /usr may be shared
amongst systems and be read-only.
/var/log/forrest might be a better position for the logs but it's still
global, perhaps even better would be a local directory to each generated
site (perhaps we could use project.home for this?)
Any thoughts at all?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft Corporation
$ o_)$$$: Frankfurt am Main, Germany
;$, _/\ &&:'
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
Re: Updating Forrest for debian, packaging questions
Posted by Ross Gardler <rg...@apache.org>.
Marcus Crafter wrote:
> so I was
> wondering if there was a list (or if someone might be able to list) the
> directories in the forrest.tgz that are required for running Forrest, as
> opposed to purely source code used for building it? Any thoughts there
> at all?
(do not consider this response necessarily complete, it is just my
"off-the-top-of-my-head response")
Pretty much all of them are required when running Forrest with the
exception of src/java and src/forestlogos. It could be argued that
src/forrestbar and src/forrestbot are not needed, these are external
tools and not required by Forrest core, the same goes for scratchpad/**.
A great deal of the other files are only used in quite specific
circumstances, plugins in 0.7 are allowing us to move these files into
optional packages, but that is a different story.
> This at the moment resovles to /usr/share/forrest/src/core/context which
> is normally not writable by users (eg. root.root ownership, 755 dir perms).
>
> Is a 'single forrest installation' still intended to work ok, or should
> each user actually be working with their own copy of forrest locally?
Is http://issues.cocoondev.org/browse/FOR-356 relevant? (I confess to
not having absorbed your problem, or that in the issue, but instinct
seems to link them)
> Hope this isn't too much off the bat - just trying to learn as much as I
> can about how Forrest is intended to run and be installed so I can make
> the package the best as possible.
Brilliant, thanks.
Ross
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.8 - Release Date: 03/01/2005