allura-users@incubator.apache.org Archives

Re: SCM Auth & Allura Auth

2013-05-17T19:06:21Z

Each protocol uses a different authentication methods, but for the ones
that use local accounts (e.g., ssh, git under some configurations), you
could indeed have your LocalAuthenticationProvider subclass set the local
account password to the same as the Allura password.


On Thu, May 16, 2013 at 4:55 AM, 王再國  wrote:

> hi:
> yes, I asking about "how to integrate authentication in Allura with
> authentication for SCM access.".
> I am sorry for my english is not so good.
>
> We want use allura build a production forge site. Not a private forge.
> I have implemented subverion server. Include http; svn; ssh protocol.
> Use schroot; FUSE; LDAP.  But LDAP no sync with Allura.
> And I want use LocalAuthenticationProvider not LDAP.
>
> FUSE fuse/accessfs.py, only check permission from /auth/repo_permissions
> API.
> But, ssh; https; svn; git; protocol need login authentication.
> If use API or subprocess calls to register a new user on SCM. How to set
> the password?
> Allura user password encode same with the linux password encode?
>
> wangaguo
>
>
> 2013/5/15 Cory Johns 
>
>> I believe you are asking about how to integrate authentication in Allura
>> with authentication for SCM access; if I have misunderstood your question,
>> I apologize.
>>
>> In order to create, refresh, or remove repositories, the Allura taskd
>> worker needs to have file system write permissions to the SCM folders, but
>> for most normal operation it really only needs read access.  Beyond that,
>> it doesn't put any restrictions on authentication for SCM access itself.
>>
>> LDAP would certainly work to manage authentication, but it comes with its
>> own complications and I don't really have any experience setting up LDAP
>> for the SCM auth management.
>>
>> There are a couple of approaches you could take for integrating local
>> authentication with the SCM.  You could create a
>> LocalAuthenticationProvider subclass that registered new users with the SCM
>> authentication system via its API or subprocess calls.  For example, if you
>> are using local system account authentication (e.g., git over ssh), the
>> provider would need to call useradd via subprocess.
>>
>> Alternatively, you could use a single system user, possibly combined with
>> something like HTTP Basic Auth, to access the SCM, and then use a FUSE
>> filesystem to enforce access.  There is an implementation in the Allura
>> project under fuse/accessfs.py and documentation for using it under
>> Allura/docs/scm_host.rst.  This approach is more or less what we use at
>> SourceForge.
>>
>>
>> On Mon, May 13, 2013 at 10:56 PM, 王再國  wrote:
>>
>>> hi:
>>> Allura auth.method = ldap or Local
>>>
>>> if use the ldap. SCM can setting auth use ldap.
>>> if use Local. SCM how to auth use Allura account?
>>>
>>> sourceforge how to auth? old sourceforge & allura & scm & other app.
>>>
>>> wangaguo
>>>
>>
>>
>

Re: SCM Auth & Allura Auth

2013-05-16T08:55:04Z

hi:
yes, I asking about "how to integrate authentication in Allura with
authentication for SCM access.".
I am sorry for my english is not so good.

We want use allura build a production forge site. Not a private forge.
I have implemented subverion server. Include http; svn; ssh protocol.
Use schroot; FUSE; LDAP.  But LDAP no sync with Allura.
And I want use LocalAuthenticationProvider not LDAP.

FUSE fuse/accessfs.py, only check permission from /auth/repo_permissions
API.
But, ssh; https; svn; git; protocol need login authentication.
If use API or subprocess calls to register a new user on SCM. How to set
the password?
Allura user password encode same with the linux password encode?

wangaguo


2013/5/15 Cory Johns 

> I believe you are asking about how to integrate authentication in Allura
> with authentication for SCM access; if I have misunderstood your question,
> I apologize.
>
> In order to create, refresh, or remove repositories, the Allura taskd
> worker needs to have file system write permissions to the SCM folders, but
> for most normal operation it really only needs read access.  Beyond that,
> it doesn't put any restrictions on authentication for SCM access itself.
>
> LDAP would certainly work to manage authentication, but it comes with its
> own complications and I don't really have any experience setting up LDAP
> for the SCM auth management.
>
> There are a couple of approaches you could take for integrating local
> authentication with the SCM.  You could create a
> LocalAuthenticationProvider subclass that registered new users with the SCM
> authentication system via its API or subprocess calls.  For example, if you
> are using local system account authentication (e.g., git over ssh), the
> provider would need to call useradd via subprocess.
>
> Alternatively, you could use a single system user, possibly combined with
> something like HTTP Basic Auth, to access the SCM, and then use a FUSE
> filesystem to enforce access.  There is an implementation in the Allura
> project under fuse/accessfs.py and documentation for using it under
> Allura/docs/scm_host.rst.  This approach is more or less what we use at
> SourceForge.
>
>
> On Mon, May 13, 2013 at 10:56 PM, 王再國  wrote:
>
>> hi:
>> Allura auth.method = ldap or Local
>>
>> if use the ldap. SCM can setting auth use ldap.
>> if use Local. SCM how to auth use Allura account?
>>
>> sourceforge how to auth? old sourceforge & allura & scm & other app.
>>
>> wangaguo
>>
>
>

Re: allura email

2013-05-15T17:17:09Z

The full exception should have been logged to allura.log, and it will also
be in the task result which can be accessed at
/admin/task_manager/5193893b100d2b0628ad4fe0
or by querying the task out of mongo directly with:
db.monq_task.findOne({_id: ObjectId('5193893b100d2b0628ad4fe0')}).result;

You can see in Allura/allura/lib/mail_util.py that it just uses smtplib and
the TurboGears smtp_server / smtp_ssl settings, so you'll need to ensure
those are correct.  I would expect the vagrant image to have exim or such
running, but I'm not entirely certain.  Regardless, the full exception
should give more info.

As for the DNS error for receiving mail, the smtp_server command launches a
simple local SMTP server just for receiving email to Allura.  You can use
the steps at https://sourceforge.net/p/allura/wiki/Notes/ to confirm that
it's working.  Beyond that, you'll need to set up a wildcard DNS entry to
handle the subdomains, as well as either firewall port forwarding or SMTP
forwarding in your exim to direct the emails to the smtp_server command
running on the non-standard port.

Furthermore, the target email addresses are of the form
@...host.tld (where 
depends on the specific tool).  The example on the Notes wiki page is
general@discussion.test8.p.myhost.net which would start a new topic in the
forum at /p/test8/discussion/general.

On Wed, May 15, 2013 at 10:05 AM, Chris Riegel  wrote:

> From a high level, what would be needed to get email working in allura?
>
> For example (sending email), when a user tries to claim an email address
> on their preferences page, I see the confirmation email and link to the
> confirmation url in allura.log but an there's an error message in taskd.log:
>
> Error on job  allura.tasks.mail_tasks.sendmail vagrant-ubuntu-precise-64 pid 1572
> project:None app:None user:root>, re-raising it
>
> I'm curious how this fit in with forgemail and lamson and what direction
> you think might be best to build this in to allura based on your lessons
> learned.  I'm expecting you have some external mechanism to facilitate this
> on sf.net.
>
>
> Going the other way (receiving email), I've edited development.ini and
> updated smtp_server and smtp_port for my setup, confirmed that my port is
> open, executed "paster smtp_server ../../development.ini" in the
> allura/command directory, and tried sending email to blog@adobe.smtp_serverand wiki@adobe.smtp_server(where
smtp_server is what I placed in development.ini and the adobe
> neighborhood has wiki and blog apps).  However, the emails fail and get
> returned with DNS errors for domain not found, so I've been playing with my
> MX records, but those seem to be ok.  I'm just looking for confirmation
> that what I've done sounds like the correct process or if I've missed
> something on the server setup.
>
> Thanks!
>

allura email

2013-05-15T14:05:38Z

>From a high level, what would be needed to get email working in allura?

For example (sending email), when a user tries to claim an email address on
their preferences page, I see the confirmation email and link to the
confirmation url in allura.log but an there's an error message in taskd.log:

Error on job , re-raising it

I'm curious how this fit in with forgemail and lamson and what direction
you think might be best to build this in to allura based on your lessons
learned.  I'm expecting you have some external mechanism to facilitate this
on sf.net.


Going the other way (receiving email), I've edited development.ini and
updated smtp_server and smtp_port for my setup, confirmed that my port is
open, executed "paster smtp_server ../../development.ini" in the
allura/command directory, and tried sending email to
blog@adobe.smtp_serverand wiki@adobe.smtp_server(where smtp_server is
what I placed in development.ini and the adobe
neighborhood has wiki and blog apps).  However, the emails fail and get
returned with DNS errors for domain not found, so I've been playing with my
MX records, but those seem to be ok.  I'm just looking for confirmation
that what I've done sounds like the correct process or if I've missed
something on the server setup.

Thanks!

Re: SCM Auth & Allura Auth

2013-05-14T17:30:52Z

I believe you are asking about how to integrate authentication in Allura
with authentication for SCM access; if I have misunderstood your question,
I apologize.

In order to create, refresh, or remove repositories, the Allura taskd
worker needs to have file system write permissions to the SCM folders, but
for most normal operation it really only needs read access.  Beyond that,
it doesn't put any restrictions on authentication for SCM access itself.

LDAP would certainly work to manage authentication, but it comes with its
own complications and I don't really have any experience setting up LDAP
for the SCM auth management.

There are a couple of approaches you could take for integrating local
authentication with the SCM.  You could create a
LocalAuthenticationProvider subclass that registered new users with the SCM
authentication system via its API or subprocess calls.  For example, if you
are using local system account authentication (e.g., git over ssh), the
provider would need to call useradd via subprocess.

Alternatively, you could use a single system user, possibly combined with
something like HTTP Basic Auth, to access the SCM, and then use a FUSE
filesystem to enforce access.  There is an implementation in the Allura
project under fuse/accessfs.py and documentation for using it under
Allura/docs/scm_host.rst.  This approach is more or less what we use at
SourceForge.

On Mon, May 13, 2013 at 10:56 PM, 王再國  wrote:

> hi:
> Allura auth.method = ldap or Local
>
> if use the ldap. SCM can setting auth use ldap.
> if use Local. SCM how to auth use Allura account?
>
> sourceforge how to auth? old sourceforge & allura & scm & other app.
>
> wangaguo
>

SCM Auth & Allura Auth

2013-05-14T02:56:50Z

hi:
Allura auth.method = ldap or Local

if use the ldap. SCM can setting auth use ldap.
if use Local. SCM how to auth use Allura account?

sourceforge how to auth? old sourceforge & allura & scm & other app.

wangaguo

Re: basic allura administration

2013-05-10T23:51:33Z

Just today we were talking about the need to document this area. Some brief pointers off the
top of my head; I'm on the road right now:

paster --help or --help-commands

paster create-neighborhood 

paster script development.ini scripts/foo.py -- --args

Urls:
/nf/admin
/p/admin
/p/add_project
/p/someproject/admin

I can elaborate later.  Or others can fill in the gaps 



-- 
Dave Brondsema

On May 10, 2013, at 3:42 PM, Chris Riegel  wrote:

> I'd like to know more about basic allura administration.  
> 
> For example: 
>     creating a new neighborhood 
>     associating a user with a project 
>     granting a user a role (member, developer, admin) for a project or neighborhood
> 
> I found create_neighborhood.py in the commands folder, but I haven't been able to get
it to work.
> 
> I've been able to hack things by going directly in to mongo, which works, but I'm sure
you have a better way.
> 
> Thanks for your time!
> 
> - Chris

basic allura administration

2013-05-10T19:42:06Z

I'd like to know more about basic allura administration.

For example:
    creating a new neighborhood
    associating a user with a project
    granting a user a role (member, developer, admin) for a project or
neighborhood

I found create_neighborhood.py in the commands folder, but I haven't been
able to get it to work.

I've been able to hack things by going directly in to mongo, which works,
but I'm sure you have a better way.

Thanks for your time!

- Chris

RE:taskd doesn't start

2013-05-09T09:47:48Z



That's it. Thanks a lot guys.




De : Tim Van Steenburgh [tvansteenburgh@gmail.com]
Envoyé : mercredi 8 mai 2013 14:29
À : allura-users@incubator.apache.org
Objet : Re: taskd doesn't start


According to the traceback, taskd is unable to connect to Mongodb. Try `service mongodb restart`.



On Wednesday, May 8, 2013 at 3:09 AM, Eugène Adell wrote:
Hello


after rebooting my server, it is not possible to start the task processing.


$ nohup paster taskd development.ini > ~/logs/taskd.log &


generates this log :


20:06:52,730 INFO [allura.command] Initialize command with config 'development.ini'
Traceback (most recent call last):
File "/root/envs/allura/bin/paster", line 8, in 
load_entry_point('PasteScript==1.7.4.2', 'console_scripts', 'paster')()
File "/root/envs/allura/local/lib/python2.7/site-packages/paste/script/command.py", line 104,
in run
invoke(command, command_name, options, args[1:])
File "/root/envs/allura/local/lib/python2.7/site-packages/paste/script/command.py", line 143,
in invoke
exit_code = runner.run(args)
File "/root/envs/allura/local/lib/python2.7/site-packages/paste/script/command.py", line 238,
in run
result = self.command()
File "/root/envs/allura/src/allura/Allura/allura/command/taskd.py", line 46, in command
self.basic_setup()
File "/root/envs/allura/src/allura/Allura/allura/command/base.py", line 72, in basic_setup
activitystream.configure(**conf)
File "/root/envs/allura/local/lib/python2.7/site-packages/activitystream/__init__.py", line
69, in configure
_director = ActivityDirector(**defaults)
File "/root/envs/allura/local/lib/python2.7/site-packages/activitystream/__init__.py", line
22, in __init__
self.connection = pymongo.Connection(conf['activitystream.master'])
File "/root/envs/allura/local/lib/python2.7/site-packages/pymongo/connection.py", line 180,
in __init__
max_pool_size, document_class, tz_aware, _connect, **kwargs)
File "/root/envs/allura/local/lib/python2.7/site-packages/pymongo/mongo_client.py", line 269,
in __init__
raise ConnectionFailure(str(e))
pymongo.errors.ConnectionFailure: could not connect to 127.0.0.1:27017: [Errno 111] Connection
refused

Re: taskd doesn't start

2013-05-08T12:29:15Z

According to the traceback, taskd is unable to connect to Mongodb. Try `service mongodb restart`.
 


On Wednesday, May 8, 2013 at 3:09 AM, Eugène Adell wrote:

> Hello
>  
> after rebooting my server, it is not possible to start the task processing.
>  
> $ nohup paster taskd development.ini > ~/logs/taskd.log &
>  
> generates this log :
>  
> 20:06:52,730 INFO [allura.command] Initialize command with config 'development.ini'
> Traceback (most recent call last):
> File "/root/envs/allura/bin/paster", line 8, in 
> load_entry_point('PasteScript==1.7.4.2', 'console_scripts', 'paster')()
> File "/root/envs/allura/local/lib/python2.7/site-packages/paste/script/command.py", line
104, in run
> invoke(command, command_name, options, args[1:])
> File "/root/envs/allura/local/lib/python2.7/site-packages/paste/script/command.py", line
143, in invoke
> exit_code = runner.run(args)
> File "/root/envs/allura/local/lib/python2.7/site-packages/paste/script/command.py", line
238, in run
> result = self.command()
> File "/root/envs/allura/src/allura/Allura/allura/command/taskd.py", line 46, in command
> self.basic_setup()
> File "/root/envs/allura/src/allura/Allura/allura/command/base.py", line 72, in basic_setup
> activitystream.configure(**conf)
> File "/root/envs/allura/local/lib/python2.7/site-packages/activitystream/__init__.py",
line 69, in configure
> _director = ActivityDirector(**defaults)
> File "/root/envs/allura/local/lib/python2.7/site-packages/activitystream/__init__.py",
line 22, in __init__
> self.connection = pymongo.Connection(conf['activitystream.master'])
> File "/root/envs/allura/local/lib/python2.7/site-packages/pymongo/connection.py", line
180, in __init__
> max_pool_size, document_class, tz_aware, _connect, **kwargs)
> File "/root/envs/allura/local/lib/python2.7/site-packages/pymongo/mongo_client.py", line
269, in __init__
> raise ConnectionFailure(str(e))
> pymongo.errors.ConnectionFailure: could not connect to 127.0.0.1:27017: [Errno 111] Connection
refused
>  
>

taskd doesn't start

2013-05-08T07:09:19Z

Hello

after rebooting my server, it is not possible to start the task processing.

$ nohup paster taskd development.ini > ~/logs/taskd.log &

generates this log :

20:06:52,730 INFO  [allura.command] Initialize command with config 'development.ini'
Traceback (most recent call last):
  File "/root/envs/allura/bin/paster", line 8, in 
    load_entry_point('PasteScript==1.7.4.2', 'console_scripts', 'paster')()
  File "/root/envs/allura/local/lib/python2.7/site-packages/paste/script/command.py", line
104, in run
    invoke(command, command_name, options, args[1:])
  File "/root/envs/allura/local/lib/python2.7/site-packages/paste/script/command.py", line
143, in invoke
    exit_code = runner.run(args)
  File "/root/envs/allura/local/lib/python2.7/site-packages/paste/script/command.py", line
238, in run
    result = self.command()
  File "/root/envs/allura/src/allura/Allura/allura/command/taskd.py", line 46, in command
    self.basic_setup()
  File "/root/envs/allura/src/allura/Allura/allura/command/base.py", line 72, in basic_setup
    activitystream.configure(**conf)
  File "/root/envs/allura/local/lib/python2.7/site-packages/activitystream/__init__.py", line
69, in configure
    _director = ActivityDirector(**defaults)
  File "/root/envs/allura/local/lib/python2.7/site-packages/activitystream/__init__.py", line
22, in __init__
    self.connection = pymongo.Connection(conf['activitystream.master'])
  File "/root/envs/allura/local/lib/python2.7/site-packages/pymongo/connection.py", line 180,
in __init__
    max_pool_size, document_class, tz_aware, _connect, **kwargs)
  File "/root/envs/allura/local/lib/python2.7/site-packages/pymongo/mongo_client.py", line
269, in __init__
    raise ConnectionFailure(str(e))
pymongo.errors.ConnectionFailure: could not connect to 127.0.0.1:27017: [Errno 111] Connection
refused

RE:WebOb conflict

2013-05-07T07:31:25Z

Hi all

Finally I upgraded ubuntu from 12.04 to 12.10 and I could install Allura after this (with
pre-installing numpy as suggested before).

Now I have another problem with Allura not starting anymore after a reboot, I'll tell more
about this in another mail thread.

thanks

________________________________________
De : Dave Brondsema [dave@brondsema.net]
Envoyé : mardi 23 avril 2013 19:51
À : allura-users@incubator.apache.org
Objet : Re: WebOb conflict

Yeah, the numpy & matplotlib packages are difficult to install, and are causing
us problems in other places too (creating the vagrant box, readthedocs setup,
Apache Jenkins which I'm exploring).  So I'd like to work on removing those
dependencies soon.

On 4/23/13 1:46 PM, Tim Van Steenburgh wrote:
> It looks like you don't have a C++ compiler installed. If you're on Ubuntu,
> try `sudo apt-get install g++` before running the pip installs.
>
> --
> Tim Van Steenburgh
> Sent with Sparrow 
>
> On Tuesday, April 23, 2013 at 1:25 PM, Eugène Adell wrote:
>
>>
>>
>> Hi all
>>
>> it's still not good, maybe are there other packages which behave like numpy ?
>> The new logs are here : http://95.154.250.47/alluralogs/
>>
>> I notice that the pip install fails with a gcc compil.
>>
>> It's not possible to use the Vagrant image on my server and it would be nice
>> to have the "normal" install process working well
>>
>> Again, thanks for helping.
>>
>>
>> De : Cory Johns [cjohns@slashdotmedia.com ]
>> Envoyé : lundi 22 avril 2013 17:05
>> À : allura-users@incubator.apache.org 
>> Objet : Re: WebOb conflict
>>



--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Re: Subversion server setting on apache & mod_dav_svn

2013-05-03T05:51:18Z

Yes, I had use the patch file to patch subversion 1.7.7 and follow INSTALL
document to conf; compile; make.
But some step is difficult for me.
like below.
1. No BDB support. only FSFS. because berkeley-db can not found. set
--with-berkeley-db same is not found.
2. How to depoly to another server?

My question is "This patch file will patch to subversion release version?
or not?".

wangaguo


2013/4/27 Dave Brondsema 

> I'm pretty sure this patch is for subversion 1.7.7
>
> On 4/25/13 1:46 AM, 王再國 wrote:
> > hi dave:
> > Thank you very mush.
> > I can't find the source code. Can you help me.
> > The pastebin only show the branch master? Pastebin data look is not same
> with
> > branch master.
> >
> > wangaguo.
> >
> >
> >
> > 2013/4/22 Dave Brondsema  >>
> >
> >     Here's the latest version of the patch
> >     https://sourceforge.net/p/allura/pastebin/517557273e5e837ec65122c1/
> >
> >
> >     diff -rup subversion-1.7.7.orig/subversion/libsvn_repos/repos.c
> >     subversion-1.7.7/subversion/libsvn_repos/repos.c
> >     --- subversion-1.7.7.orig/subversion/libsvn_repos/repos.c
> 2012-11-15
> >     16:04:07.000000000 +0000
> >     +++ subversion-1.7.7/subversion/libsvn_repos/repos.c    2012-12-07
> >     23:06:10.352959642 +0000
> >     @@ -1286,7 +1286,7 @@ svn_repos_create(svn_repos_t **repos_p,
> >       * on errors (which would be permission errors, probably) so that
> >       * we the user will see them after we try to open the repository
> >       * for real.  */
> >     -static svn_boolean_t
> >     +svn_boolean_t
> >      check_repos_path(const char *path,
> >                       apr_pool_t *pool)
> >      {
> >     diff -rup subversion-1.7.7.orig/subversion/mod_dav_svn/repos.c
> >     subversion-1.7.7/subversion/mod_dav_svn/repos.c
> >     --- subversion-1.7.7.orig/subversion/mod_dav_svn/repos.c
>  2012-11-15
> >     16:04:07.000000000 +0000
> >     +++ subversion-1.7.7/subversion/mod_dav_svn/repos.c     2012-12-07
> >     23:06:18.291130038 +0000
> >     @@ -1288,10 +1288,13 @@ dav_svn_split_uri(request_rec *r,
> >
> >        else
> >          {
> >     -      /* SVNParentPath was used instead: assume the first component
> of
> >     +      /* SVNParentPath was used instead: figure out which component
> of
> >               'relative' is the name of a repository. */
> >     -      const char *magic_component, *magic_end;
> >     +      extern svn_boolean_t check_repos_path(const char *path,
> apr_pool_t
> >     *pool);
> >     +      const char *magic_component = NULL, *magic_end;
> >     +      char *repos_path;
> >
> >     +     do {
> >            /* A repository name is required here.
> >               Remember that 'relative' always starts with a "/". */
> >            if (relative[1] == '\0')
> >     @@ -1309,16 +1312,34 @@ dav_svn_split_uri(request_rec *r,
> >                /* ### Request was for parent directory with no trailing
> >                   slash; we probably ought to just redirect to same with
> >                   trailing slash appended. */
> >     +         if (!magic_component)
> >                magic_component = relative + 1;
> >     +         else {
> >     +          magic_component = apr_pstrcat(r->pool, magic_component,
> >     +                                        relative, NULL);
> >     +         }
> >                relative = "/";
> >              }
> >            else
> >              {
> >     +         if (!magic_component)
> >                magic_component = apr_pstrndup(r->pool, relative + 1,
> >                                               magic_end - relative - 1);
> >     +         else {
> >     +          char *tmp_magic_component;
> >     +
> >     +          tmp_magic_component = apr_pstrndup(r->pool, relative,
> >     +                                             magic_end - relative);
> >     +          magic_component = apr_pstrcat(r->pool, magic_component,
> >     +                                        tmp_magic_component, NULL);
> >     +         }
> >                relative = magic_end;
> >              }
> >
> >     +      repos_path = svn_path_join(fs_parent_path, magic_component,
> >     +                                 r->pool);
> >     +     } while (check_repos_path(repos_path, r->pool) != TRUE);
> >     +
> >            /* return answer */
> >            *repos_basename = magic_component;
> >          }
> >     @@ -1472,6 +1493,7 @@ cleanup_fs_access(void *data)
> >      }
> >
> >
> >     +#if 0
> >      /* Helper func to construct a special 'parentpath' private
> resource. */
> >      static dav_error *
> >      get_parentpath_resource(request_rec *r,
> >     @@ -1527,6 +1549,7 @@ get_parentpath_resource(request_rec *r,
> >        *resource = &comb->res;
> >        return NULL;
> >      }
> >     +#endif
> >
> >      /* --------------- Borrowed from httpd's mod_negotiation.c
> -------------- */
> >
> >     @@ -1955,6 +1978,7 @@ get_resource(request_rec *r,
> >        xslt_uri = dav_svn__get_xslt_uri(r);
> >        fs_parent_path = dav_svn__get_fs_parent_path(r);
> >
> >     +#if 0
> >        /* Special case: detect and build the SVNParentPath as a unique
> type
> >           of private resource, iff the SVNListParentPath directive is
> 'on'. */
> >        if (fs_parent_path && dav_svn__get_list_parentpath_flag(r))
> >     @@ -1978,6 +2002,7 @@ get_resource(request_rec *r,
> >                return NULL;
> >              }
> >          }
> >     +#endif
> >
> >        /* This does all the work of interpreting/splitting the request
> uri. */
> >        err = dav_svn_split_uri(r, r->uri, root_path,
> >     @@ -3264,8 +3289,13 @@ deliver(const dav_resource *resource, ap
> >              {
> >                apr_hash_index_t *hi;
> >                apr_hash_t *dirents;
> >     +          int root_path_len =
> strlen(resource->info->repos->root_path);
> >                const char *fs_parent_path =
> >     -            dav_svn__get_fs_parent_path(resource->info->r);
> >     +            apr_pstrcat(resource->info->r->pool,
> >     +
>  dav_svn__get_fs_parent_path(resource->info->r),
> >     +                        resource->info->r->uri
> >     +                        + ((root_path_len > 1) ? root_path_len : 0),
> >     +                        NULL);
> >
> >                serr = svn_io_get_dirents3(&dirents, fs_parent_path, TRUE,
> >                                           resource->pool,
> resource->pool);
> >
> >
> >
> >
> >
> >
> >
> >     On 4/17/13 4:41 PM, Dave Brondsema wrote:
> >     > On SourceForge our SVN servers run with a patch to SVNParentPath
> to support
> >     > recursion.
> http://subversion.tigris.org/issues/show_bug.cgi?id=3588 has some
> >     > patches for it, but they are old.  I'm seeing if I can get the
> latest
> >     version of
> >     > our patch public that works with a recent release of Subversion.
> >     >
> >     > On 4/17/13 5:02 AM, 王再國 wrote:
> >     >> I think so. "inotifywait, or a simple cron job would probably be
> easier."
> >     >>
> >     >> project has subproject. recursively sub project.
> >     >> allura neighborhood can invite project to other neighborhood.
> >     >> This will change all relation path.
> >     >> I don't know sourceforge how to setting svn server.
> >     >> but I know have many event handler or script.
> >     >>
> >     >> now, I use apache macro module.
> >     >>
> >     >> 
> >     >>  
> >     >>    DAV svn
> >     >>    SVNParentPath /scm/svn$nh_project
> >     >>      ...
> >     >>  
> >     >> 
> >     >>
> >     >> NameVirtualHost 192.168.22.121
> >     >>  <
> http://svn.allura.org>>
> >     >>  Use SVNSetup /p/allura
> >     >>  Use SVNSetup /p/test
> >     >>  Use SVNSetup /p/test/sub1
> >     >> 
> >     >>
> >     >> and I need to sync the conf with allura neighborhood; project;
> subproject.
> >     >> sourceforge how to setting svn server???
> >     >>
> >     >> wangaguo
> >     >>
> >     >>
> >     >> 2013/4/17 王再國 
> >     >>
> >     >>
> >     >>     if project & repos below.
> >     >>     /p/allura/svn
> >     >>     /p/testproject01/svn
> >     >>     /p/testproject02/svn
> >     >>
> >     >>     and /tmp/svn/ is SVNParentPath
> >     >>
> >     >>     maybe symlink below.
> >     >>     /tmp/svn/allura-svn
> >     >>     /tmp/svn/testproject01-svn
> >     >>     /tmp/svn/testproject02-svn
> >     >>
> >     >>     but the web url is not below.
> >     >>     http://svn.allura.org/p/allura/svn
> >     >>     http://svn.allura.org/p/testproject01/svn
> >     >>
> >     >>     web url is below.
> >     >>     http://svn.allura.org/allura-svn
> >     >>     http://svn.allura.org/testproject01-svn
> >     >>
> >     >>     wangaguo
> >     >>
> >     >>
> >     >>
> >     >>     2013/4/16 Tim Van Steenburgh  >     
> >     >>      tvansteenburgh@gmail.com>>>
> >     >>
> >     >>         One idea would be to use bash + inotifywait to watch
> /tmp/svn, and
> >     >>         rename + symlink new repo directories to another
> location, and
> >     use that
> >     >>         location as the SVNParentPath. I'm not totally sure it
> would
> >     work, but
> >     >>         maybe worth a try?
> >     >>
> >     >>         Tim
> >     >>
> >     >>         On Tuesday, April 16, 2013 at 2:58 AM, 王再國 wrote:
> >     >>
> >     >>>         If all repos in the /tmp/svn then set SVNParentPath on
> /tmp/svn
> >     is ok.
> >     >>>         But allura has three level neighborhood; project; repos.
> >     >>>         SVNParentPath only support one level parent path. no
> recursive.
> >     >>>         e.g. /p/allura/svn1, In apache conf, I only can seting
> to the allura
> >     >>>         project.
> >     >>>
> >     >>>         wangaguo
> >     >>>
> >     >>>
> >     >>>         2013/4/16 王再國  wangaguo@gmail.com>
> >     >>
> >     >>>
> >     >>>             Hi.
> >     >>>             svn can set SVNParentPath for multiple repository.
> >     >>>             But allura scm direcotry stucture is
> neighborhood/project/repos.
> >     >>>             How to setting up svn apache & mod_dav_svn for
> allura svn
> >     folder.
> >     >>>
> >     >>>             wangaguo
> >     >>>
> >     >>>
> >     >>>
> >     >>
> >     >>
> >     >>
> >     >
> >     >
> >     >
> >
> >
> >
> >     --
> >     Dave Brondsema : dave@brondsema.net 
> >     http://www.brondsema.net : personal
> >     http://www.splike.com : programming
> >                   <><
> >
> >
>
>
>
> --
> Dave Brondsema : dave@brondsema.net
> http://www.brondsema.net : personal
> http://www.splike.com : programming
>               <><
>

Re: Allura private projects for non-admins

2013-05-02T20:32:50Z

On 5/2/13 4:53 AM, Rui Ferreira wrote:
> Hi,
> 
> I'd be willing to send some patches your way.
> 
> Perhaps changing the value of neighborhood.features['private_projects'] to
> hold the user group that can create private projects (Admin, Developer,
> Member, Authenticated) would cover all those cases?

That sounds good to me

> 
> This would break compatibility with the current
> set_neighborhood_property command, would this be a problem? I could add a new property
instead.

I think the current property is ok.  The code could check and see if the value
is True and then treat it like Admin, that'd be backwards compatible.  Or folks
could update their data when upgrading.  In scripts/migrations/ there are some
examples of how we've done that in the past.

> 
> On Tue, Apr 30, 2013 at 05:58:38PM -0400, Dave Brondsema wrote:
>> Since Allura was developed at SourceForge which hosts open source projects, the
>> functionality was designed to support that open (not private) projects initially.
>>
>> Note that these are just initial settings and a project admin can remove
>> anonymous 'read' rights later.
>>
>> Your changes seem fine for a local modification.  If you were interested in
>> contributing them back to Allura, that'd be great, but I think it'd be best to
>> have additional configuration so that each neighborhood could have different
>> settings for whether they allowed private projects for nobody, neighborhood
>> admins, or everyone.  This could be done with an expansion of the
>> neighborhood.features['private_projects'] values.
>>
>> -Dave
>>
>>
>> On 4/29/13 5:25 AM, Rui Ferreira wrote:
>>> Hi,
>>>
>>> I'm looking into allowing users to create private projects in allura,
>>> but it seems that Allura requires a user to be admin on a neighborhood
>>> in order to create private projects.
>>> I was wondering if there is any strong reason for this restriction?
>>>
>>> This seems to be enforced at the controller and template, and removing
>>> both checks allowed my users to create private projects i.e. 
>>>
>>> diff --git a/Allura/allura/controllers/project.py b/Allura/allura/controllers/project.py
>>> index 5aa9e02..55d8ff6 100644
>>> --- a/Allura/allura/controllers/project.py
>>> +++ b/Allura/allura/controllers/project.py
>>> @@ -177,8 +177,8 @@ def check_names(self, project_name='', unix_name=''):
>>>      def register(self, project_unixname=None, project_description=None, project_name=None,
neighborhood=None,
>>>                   private_project=None, tools=None, **kw):
>>>          require_access(self.neighborhood, 'register')
>>> -        if private_project:
>>> -            require_access(self.neighborhood, 'admin')
>>> +#        if private_project:
>>> +#            require_access(self.neighborhood, 'admin')
>>>          neighborhood = M.Neighborhood.query.get(name=neighborhood)
>>>  
>>>          project_description = h.really_unicode(project_description or '').encode('utf-8')
>>> diff --git a/Allura/allura/templates/widgets/neighborhood_add_project.html b/Allura/allura/templates/widgets/neighborhood_add_project.html
>>> index 78ab608..0b36cb8 100644
>>> --- a/Allura/allura/templates/widgets/neighborhood_add_project.html
>>> +++ b/Allura/allura/templates/widgets/neighborhood_add_project.html
>>> @@ -41,7 +41,7 @@
>>>

>>> {% endfor %} >>> {% endif %} >>> - {% if h.has_access(neighborhood, 'admin') and not neighborhood.project_template and neighborhood.features['private_projects'] %} >>> +{# {% if h.has_access(neighborhood, 'admin') and not neighborhood.project_template and neighborhood.features['private_projects'] %} #} >>>

>>>

>>> {{widget.display_field(widget.fields.private_project)}} >>> @@ -52,7 +52,7 @@ >>>

>>>

>>> - {% endif %} >>> +{# {% endif %} #} >>>

>>> >>>

>>> >>> Support for private projects is already enabled/disabled on a per >>> beighborhood basis, is there really a need for this check? >>> >>> >> >> >> >> -- >> Dave Brondsema : dave@brondsema.net >> http://www.brondsema.net : personal >> http://www.splike.com : programming >> <>< > -- Dave Brondsema : dave@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><

Re: Allura private projects for non-admins

2013-05-02T08:53:41Z

Hi,

I'd be willing to send some patches your way.

Perhaps changing the value of neighborhood.features['private_projects'] to
hold the user group that can create private projects (Admin, Developer,
Member, Authenticated) would cover all those cases?

This would break compatibility with the current
set_neighborhood_property command, would this be a problem? I could add a new property instead.

On Tue, Apr 30, 2013 at 05:58:38PM -0400, Dave Brondsema wrote:
> Since Allura was developed at SourceForge which hosts open source projects, the
> functionality was designed to support that open (not private) projects initially.
> 
> Note that these are just initial settings and a project admin can remove
> anonymous 'read' rights later.
> 
> Your changes seem fine for a local modification.  If you were interested in
> contributing them back to Allura, that'd be great, but I think it'd be best to
> have additional configuration so that each neighborhood could have different
> settings for whether they allowed private projects for nobody, neighborhood
> admins, or everyone.  This could be done with an expansion of the
> neighborhood.features['private_projects'] values.
> 
> -Dave
> 
> 
> On 4/29/13 5:25 AM, Rui Ferreira wrote:
> > Hi,
> > 
> > I'm looking into allowing users to create private projects in allura,
> > but it seems that Allura requires a user to be admin on a neighborhood
> > in order to create private projects.
> > I was wondering if there is any strong reason for this restriction?
> > 
> > This seems to be enforced at the controller and template, and removing
> > both checks allowed my users to create private projects i.e. 
> > 
> > diff --git a/Allura/allura/controllers/project.py b/Allura/allura/controllers/project.py
> > index 5aa9e02..55d8ff6 100644
> > --- a/Allura/allura/controllers/project.py
> > +++ b/Allura/allura/controllers/project.py
> > @@ -177,8 +177,8 @@ def check_names(self, project_name='', unix_name=''):
> >      def register(self, project_unixname=None, project_description=None, project_name=None,
neighborhood=None,
> >                   private_project=None, tools=None, **kw):
> >          require_access(self.neighborhood, 'register')
> > -        if private_project:
> > -            require_access(self.neighborhood, 'admin')
> > +#        if private_project:
> > +#            require_access(self.neighborhood, 'admin')
> >          neighborhood = M.Neighborhood.query.get(name=neighborhood)
> >  
> >          project_description = h.really_unicode(project_description or '').encode('utf-8')
> > diff --git a/Allura/allura/templates/widgets/neighborhood_add_project.html b/Allura/allura/templates/widgets/neighborhood_add_project.html
> > index 78ab608..0b36cb8 100644
> > --- a/Allura/allura/templates/widgets/neighborhood_add_project.html
> > +++ b/Allura/allura/templates/widgets/neighborhood_add_project.html
> > @@ -41,7 +41,7 @@
> >

> > {% endfor %} > > {% endif %} > > - {% if h.has_access(neighborhood, 'admin') and not neighborhood.project_template and neighborhood.features['private_projects'] %} > > +{# {% if h.has_access(neighborhood, 'admin') and not neighborhood.project_template and neighborhood.features['private_projects'] %} #} > >

> >

> > {{widget.display_field(widget.fields.private_project)}} > > @@ -52,7 +52,7 @@ > >

> >

> > - {% endif %} > > +{# {% endif %} #} > >

> > > >

> > > > Support for private projects is already enabled/disabled on a per > > beighborhood basis, is there really a need for this check? > > > > > > > > -- > Dave Brondsema : dave@brondsema.net > http://www.brondsema.net : personal > http://www.splike.com : programming > <><

Re: New Allura app

2013-05-01T20:01:54Z

Hey Chris, 

You'll need to run `python setup.py develop` in the root of you new App in order for Allura
to see the new entry point.

Tim

On Wednesday, May 1, 2013 at 3:48 PM, Chris Riegel wrote: 
> Hi,
> 
> I want to develop a new Allura app, but I'm in need of just a little direction to get
off and running.
> 
> I've started from the ForgeLink app and cloned that into a template for my new app. 
However, after essentially modifying occurrences of "link" and "Link" with another string
the new app does not appear under the "Tools" menu on the "Admin" screen.  What needs to be
done to have the new app added to the tools menu?
> 
> I thought I might have made a mistake somewhere in my cloning of the ForgeLink app, so
I also downloaded the ForgePastebin app from SF.net (http://SF.net) and tried installing that
by removing the "status='beta'" line in the app.py file, but I'm not able to see the Pastebin
app on the Admin screen either.  Perhaps Pastebin doesn't have a configuration window on the
Admin>Tools screen?
> 
> Thanks for your help!

New Allura app

2013-05-01T19:48:48Z

Hi,

I want to develop a new Allura app, but I'm in need of just a little
direction to get off and running.

I've started from the ForgeLink app and cloned that into a template for my
new app.  However, after essentially modifying occurrences of "link" and
"Link" with another string the new app does not appear under the "Tools"
menu on the "Admin" screen.  What needs to be done to have the new app
added to the tools menu?

I thought I might have made a mistake somewhere in my cloning of the
ForgeLink app, so I also downloaded the ForgePastebin app from SF.net and
tried installing that by removing the "status='beta'" line in the app.py
file, but I'm not able to see the Pastebin app on the Admin screen either.
Perhaps Pastebin doesn't have a configuration window on the Admin>Tools
screen?

Thanks for your help!

Re: Allura private projects for non-admins

2013-04-30T21:58:38Z

Since Allura was developed at SourceForge which hosts open source projects, the
functionality was designed to support that open (not private) projects initially.

Note that these are just initial settings and a project admin can remove
anonymous 'read' rights later.

Your changes seem fine for a local modification.  If you were interested in
contributing them back to Allura, that'd be great, but I think it'd be best to
have additional configuration so that each neighborhood could have different
settings for whether they allowed private projects for nobody, neighborhood
admins, or everyone.  This could be done with an expansion of the
neighborhood.features['private_projects'] values.

-Dave


On 4/29/13 5:25 AM, Rui Ferreira wrote:
> Hi,
> 
> I'm looking into allowing users to create private projects in allura,
> but it seems that Allura requires a user to be admin on a neighborhood
> in order to create private projects.
> I was wondering if there is any strong reason for this restriction?
> 
> This seems to be enforced at the controller and template, and removing
> both checks allowed my users to create private projects i.e. 
> 
> diff --git a/Allura/allura/controllers/project.py b/Allura/allura/controllers/project.py
> index 5aa9e02..55d8ff6 100644
> --- a/Allura/allura/controllers/project.py
> +++ b/Allura/allura/controllers/project.py
> @@ -177,8 +177,8 @@ def check_names(self, project_name='', unix_name=''):
>      def register(self, project_unixname=None, project_description=None, project_name=None,
neighborhood=None,
>                   private_project=None, tools=None, **kw):
>          require_access(self.neighborhood, 'register')
> -        if private_project:
> -            require_access(self.neighborhood, 'admin')
> +#        if private_project:
> +#            require_access(self.neighborhood, 'admin')
>          neighborhood = M.Neighborhood.query.get(name=neighborhood)
>  
>          project_description = h.really_unicode(project_description or '').encode('utf-8')
> diff --git a/Allura/allura/templates/widgets/neighborhood_add_project.html b/Allura/allura/templates/widgets/neighborhood_add_project.html
> index 78ab608..0b36cb8 100644
> --- a/Allura/allura/templates/widgets/neighborhood_add_project.html
> +++ b/Allura/allura/templates/widgets/neighborhood_add_project.html
> @@ -41,7 +41,7 @@
>

> {% endfor %} > {% endif %} > - {% if h.has_access(neighborhood, 'admin') and not neighborhood.project_template and neighborhood.features['private_projects'] %} > +{# {% if h.has_access(neighborhood, 'admin') and not neighborhood.project_template and neighborhood.features['private_projects'] %} #} >

> {{widget.display_field(widget.fields.private_project)}} > @@ -52,7 +52,7 @@ >

> - {% endif %} > +{# {% endif %} #} >

> >

> > Support for private projects is already enabled/disabled on a per > beighborhood basis, is there really a need for this check? > > -- Dave Brondsema : dave@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><

Allura private projects for non-admins

2013-04-29T09:25:59Z

Hi,

I'm looking into allowing users to create private projects in allura,
but it seems that Allura requires a user to be admin on a neighborhood
in order to create private projects.
I was wondering if there is any strong reason for this restriction?

This seems to be enforced at the controller and template, and removing
both checks allowed my users to create private projects i.e. 

diff --git a/Allura/allura/controllers/project.py b/Allura/allura/controllers/project.py
index 5aa9e02..55d8ff6 100644
--- a/Allura/allura/controllers/project.py
+++ b/Allura/allura/controllers/project.py
@@ -177,8 +177,8 @@ def check_names(self, project_name='', unix_name=''):
     def register(self, project_unixname=None, project_description=None, project_name=None,
neighborhood=None,
                  private_project=None, tools=None, **kw):
         require_access(self.neighborhood, 'register')
-        if private_project:
-            require_access(self.neighborhood, 'admin')
+#        if private_project:
+#            require_access(self.neighborhood, 'admin')
         neighborhood = M.Neighborhood.query.get(name=neighborhood)
 
         project_description = h.really_unicode(project_description or '').encode('utf-8')
diff --git a/Allura/allura/templates/widgets/neighborhood_add_project.html b/Allura/allura/templates/widgets/neighborhood_add_project.html
index 78ab608..0b36cb8 100644
--- a/Allura/allura/templates/widgets/neighborhood_add_project.html
+++ b/Allura/allura/templates/widgets/neighborhood_add_project.html
@@ -41,7 +41,7 @@

{% endfor %} {% endif %} - {% if h.has_access(neighborhood, 'admin') and not neighborhood.project_template and neighborhood.features['private_projects'] %} +{# {% if h.has_access(neighborhood, 'admin') and not neighborhood.project_template and neighborhood.features['private_projects'] %} #}

{{widget.display_field(widget.fields.private_project)}} @@ -52,7 +52,7 @@

- {% endif %} +{# {% endif %} #}

Support for private projects is already enabled/disabled on a per beighborhood basis, is there really a need for this check?

Re: Subversion server setting on apache & mod_dav_svn

2013-04-26T16:02:02Z

I'm pretty sure this patch is for subversion 1.7.7

On 4/25/13 1:46 AM, 王再國 wrote:
> hi dave:
> Thank you very mush.
> I can't find the source code. Can you help me.
> The pastebin only show the branch master? Pastebin data look is not same with
> branch master.
> 
> wangaguo.
> 
> 
> 
> 2013/4/22 Dave Brondsema >
> 
>     Here's the latest version of the patch
>     https://sourceforge.net/p/allura/pastebin/517557273e5e837ec65122c1/
> 
> 
>     diff -rup subversion-1.7.7.orig/subversion/libsvn_repos/repos.c
>     subversion-1.7.7/subversion/libsvn_repos/repos.c
>     --- subversion-1.7.7.orig/subversion/libsvn_repos/repos.c       2012-11-15
>     16:04:07.000000000 +0000
>     +++ subversion-1.7.7/subversion/libsvn_repos/repos.c    2012-12-07
>     23:06:10.352959642 +0000
>     @@ -1286,7 +1286,7 @@ svn_repos_create(svn_repos_t **repos_p,
>       * on errors (which would be permission errors, probably) so that
>       * we the user will see them after we try to open the repository
>       * for real.  */
>     -static svn_boolean_t
>     +svn_boolean_t
>      check_repos_path(const char *path,
>                       apr_pool_t *pool)
>      {
>     diff -rup subversion-1.7.7.orig/subversion/mod_dav_svn/repos.c
>     subversion-1.7.7/subversion/mod_dav_svn/repos.c
>     --- subversion-1.7.7.orig/subversion/mod_dav_svn/repos.c        2012-11-15
>     16:04:07.000000000 +0000
>     +++ subversion-1.7.7/subversion/mod_dav_svn/repos.c     2012-12-07
>     23:06:18.291130038 +0000
>     @@ -1288,10 +1288,13 @@ dav_svn_split_uri(request_rec *r,
> 
>        else
>          {
>     -      /* SVNParentPath was used instead: assume the first component of
>     +      /* SVNParentPath was used instead: figure out which component of
>               'relative' is the name of a repository. */
>     -      const char *magic_component, *magic_end;
>     +      extern svn_boolean_t check_repos_path(const char *path, apr_pool_t
>     *pool);
>     +      const char *magic_component = NULL, *magic_end;
>     +      char *repos_path;
> 
>     +     do {
>            /* A repository name is required here.
>               Remember that 'relative' always starts with a "/". */
>            if (relative[1] == '\0')
>     @@ -1309,16 +1312,34 @@ dav_svn_split_uri(request_rec *r,
>                /* ### Request was for parent directory with no trailing
>                   slash; we probably ought to just redirect to same with
>                   trailing slash appended. */
>     +         if (!magic_component)
>                magic_component = relative + 1;
>     +         else {
>     +          magic_component = apr_pstrcat(r->pool, magic_component,
>     +                                        relative, NULL);
>     +         }
>                relative = "/";
>              }
>            else
>              {
>     +         if (!magic_component)
>                magic_component = apr_pstrndup(r->pool, relative + 1,
>                                               magic_end - relative - 1);
>     +         else {
>     +          char *tmp_magic_component;
>     +
>     +          tmp_magic_component = apr_pstrndup(r->pool, relative,
>     +                                             magic_end - relative);
>     +          magic_component = apr_pstrcat(r->pool, magic_component,
>     +                                        tmp_magic_component, NULL);
>     +         }
>                relative = magic_end;
>              }
> 
>     +      repos_path = svn_path_join(fs_parent_path, magic_component,
>     +                                 r->pool);
>     +     } while (check_repos_path(repos_path, r->pool) != TRUE);
>     +
>            /* return answer */
>            *repos_basename = magic_component;
>          }
>     @@ -1472,6 +1493,7 @@ cleanup_fs_access(void *data)
>      }
> 
> 
>     +#if 0
>      /* Helper func to construct a special 'parentpath' private resource. */
>      static dav_error *
>      get_parentpath_resource(request_rec *r,
>     @@ -1527,6 +1549,7 @@ get_parentpath_resource(request_rec *r,
>        *resource = &comb->res;
>        return NULL;
>      }
>     +#endif
> 
>      /* --------------- Borrowed from httpd's mod_negotiation.c -------------- */
> 
>     @@ -1955,6 +1978,7 @@ get_resource(request_rec *r,
>        xslt_uri = dav_svn__get_xslt_uri(r);
>        fs_parent_path = dav_svn__get_fs_parent_path(r);
> 
>     +#if 0
>        /* Special case: detect and build the SVNParentPath as a unique type
>           of private resource, iff the SVNListParentPath directive is 'on'. */
>        if (fs_parent_path && dav_svn__get_list_parentpath_flag(r))
>     @@ -1978,6 +2002,7 @@ get_resource(request_rec *r,
>                return NULL;
>              }
>          }
>     +#endif
> 
>        /* This does all the work of interpreting/splitting the request uri. */
>        err = dav_svn_split_uri(r, r->uri, root_path,
>     @@ -3264,8 +3289,13 @@ deliver(const dav_resource *resource, ap
>              {
>                apr_hash_index_t *hi;
>                apr_hash_t *dirents;
>     +          int root_path_len = strlen(resource->info->repos->root_path);
>                const char *fs_parent_path =
>     -            dav_svn__get_fs_parent_path(resource->info->r);
>     +            apr_pstrcat(resource->info->r->pool,
>     +                        dav_svn__get_fs_parent_path(resource->info->r),
>     +                        resource->info->r->uri
>     +                        + ((root_path_len > 1) ? root_path_len : 0),
>     +                        NULL);
> 
>                serr = svn_io_get_dirents3(&dirents, fs_parent_path, TRUE,
>                                           resource->pool, resource->pool);
> 
> 
> 
> 
> 
> 
> 
>     On 4/17/13 4:41 PM, Dave Brondsema wrote:
>     > On SourceForge our SVN servers run with a patch to SVNParentPath to support
>     > recursion.  http://subversion.tigris.org/issues/show_bug.cgi?id=3588 has some
>     > patches for it, but they are old.  I'm seeing if I can get the latest
>     version of
>     > our patch public that works with a recent release of Subversion.
>     >
>     > On 4/17/13 5:02 AM, 王再國 wrote:
>     >> I think so. "inotifywait, or a simple cron job would probably be easier."
>     >>
>     >> project has subproject. recursively sub project.
>     >> allura neighborhood can invite project to other neighborhood.
>     >> This will change all relation path.
>     >> I don't know sourceforge how to setting svn server.
>     >> but I know have many event handler or script.
>     >>
>     >> now, I use apache macro module.
>     >>
>     >> 
>     >>  
>     >>    DAV svn
>     >>    SVNParentPath /scm/svn$nh_project
>     >>      ...
>     >>  
>     >> 
>     >>
>     >> NameVirtualHost 192.168.22.121
>     >>  >
>     >>  Use SVNSetup /p/allura
>     >>  Use SVNSetup /p/test
>     >>  Use SVNSetup /p/test/sub1
>     >> 
>     >>
>     >> and I need to sync the conf with allura neighborhood; project; subproject.
>     >> sourceforge how to setting svn server???
>     >>
>     >> wangaguo
>     >>
>     >>
>     >> 2013/4/17 王再國 
>     >>
>     >>
>     >>     if project & repos below.
>     >>     /p/allura/svn
>     >>     /p/testproject01/svn
>     >>     /p/testproject02/svn
>     >>
>     >>     and /tmp/svn/ is SVNParentPath
>     >>
>     >>     maybe symlink below.
>     >>     /tmp/svn/allura-svn
>     >>     /tmp/svn/testproject01-svn
>     >>     /tmp/svn/testproject02-svn
>     >>
>     >>     but the web url is not below.
>     >>     http://svn.allura.org/p/allura/svn
>     >>     http://svn.allura.org/p/testproject01/svn
>     >>
>     >>     web url is below.
>     >>     http://svn.allura.org/allura-svn
>     >>     http://svn.allura.org/testproject01-svn
>     >>
>     >>     wangaguo
>     >>
>     >>
>     >>
>     >>     2013/4/16 Tim Van Steenburgh      
>     >>     >>
>     >>
>     >>         One idea would be to use bash + inotifywait to watch /tmp/svn, and
>     >>         rename + symlink new repo directories to another location, and
>     use that
>     >>         location as the SVNParentPath. I'm not totally sure it would
>     work, but
>     >>         maybe worth a try?
>     >>
>     >>         Tim
>     >>
>     >>         On Tuesday, April 16, 2013 at 2:58 AM, 王再國 wrote:
>     >>
>     >>>         If all repos in the /tmp/svn then set SVNParentPath on /tmp/svn
>     is ok.
>     >>>         But allura has three level neighborhood; project; repos.
>     >>>         SVNParentPath only support one level parent path. no recursive.
>     >>>         e.g. /p/allura/svn1, In apache conf, I only can seting to the
allura
>     >>>         project.
>     >>>
>     >>>         wangaguo
>     >>>
>     >>>
>     >>>         2013/4/16 王再國 
>     >>
>     >>>
>     >>>             Hi.
>     >>>             svn can set SVNParentPath for multiple repository.
>     >>>             But allura scm direcotry stucture is neighborhood/project/repos.
>     >>>             How to setting up svn apache & mod_dav_svn for allura
svn
>     folder.
>     >>>
>     >>>             wangaguo
>     >>>
>     >>>
>     >>>
>     >>
>     >>
>     >>
>     >
>     >
>     >
> 
> 
> 
>     --
>     Dave Brondsema : dave@brondsema.net 
>     http://www.brondsema.net : personal
>     http://www.splike.com : programming
>                   <><
> 
> 



-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Re: Subversion server setting on apache & mod_dav_svn

2013-04-25T05:46:52Z

hi dave:
Thank you very mush.
I can't find the source code. Can you help me.
The pastebin only show the branch master? Pastebin data look is not same
with branch master.

wangaguo.



2013/4/22 Dave Brondsema 

> Here's the latest version of the patch
> https://sourceforge.net/p/allura/pastebin/517557273e5e837ec65122c1/
>
>
> diff -rup subversion-1.7.7.orig/subversion/libsvn_repos/repos.c
> subversion-1.7.7/subversion/libsvn_repos/repos.c
> --- subversion-1.7.7.orig/subversion/libsvn_repos/repos.c       2012-11-15
> 16:04:07.000000000 +0000
> +++ subversion-1.7.7/subversion/libsvn_repos/repos.c    2012-12-07
> 23:06:10.352959642 +0000
> @@ -1286,7 +1286,7 @@ svn_repos_create(svn_repos_t **repos_p,
>   * on errors (which would be permission errors, probably) so that
>   * we the user will see them after we try to open the repository
>   * for real.  */
> -static svn_boolean_t
> +svn_boolean_t
>  check_repos_path(const char *path,
>                   apr_pool_t *pool)
>  {
> diff -rup subversion-1.7.7.orig/subversion/mod_dav_svn/repos.c
> subversion-1.7.7/subversion/mod_dav_svn/repos.c
> --- subversion-1.7.7.orig/subversion/mod_dav_svn/repos.c        2012-11-15
> 16:04:07.000000000 +0000
> +++ subversion-1.7.7/subversion/mod_dav_svn/repos.c     2012-12-07
> 23:06:18.291130038 +0000
> @@ -1288,10 +1288,13 @@ dav_svn_split_uri(request_rec *r,
>
>    else
>      {
> -      /* SVNParentPath was used instead: assume the first component of
> +      /* SVNParentPath was used instead: figure out which component of
>           'relative' is the name of a repository. */
> -      const char *magic_component, *magic_end;
> +      extern svn_boolean_t check_repos_path(const char *path, apr_pool_t
> *pool);
> +      const char *magic_component = NULL, *magic_end;
> +      char *repos_path;
>
> +     do {
>        /* A repository name is required here.
>           Remember that 'relative' always starts with a "/". */
>        if (relative[1] == '\0')
> @@ -1309,16 +1312,34 @@ dav_svn_split_uri(request_rec *r,
>            /* ### Request was for parent directory with no trailing
>               slash; we probably ought to just redirect to same with
>               trailing slash appended. */
> +         if (!magic_component)
>            magic_component = relative + 1;
> +         else {
> +          magic_component = apr_pstrcat(r->pool, magic_component,
> +                                        relative, NULL);
> +         }
>            relative = "/";
>          }
>        else
>          {
> +         if (!magic_component)
>            magic_component = apr_pstrndup(r->pool, relative + 1,
>                                           magic_end - relative - 1);
> +         else {
> +          char *tmp_magic_component;
> +
> +          tmp_magic_component = apr_pstrndup(r->pool, relative,
> +                                             magic_end - relative);
> +          magic_component = apr_pstrcat(r->pool, magic_component,
> +                                        tmp_magic_component, NULL);
> +         }
>            relative = magic_end;
>          }
>
> +      repos_path = svn_path_join(fs_parent_path, magic_component,
> +                                 r->pool);
> +     } while (check_repos_path(repos_path, r->pool) != TRUE);
> +
>        /* return answer */
>        *repos_basename = magic_component;
>      }
> @@ -1472,6 +1493,7 @@ cleanup_fs_access(void *data)
>  }
>
>
> +#if 0
>  /* Helper func to construct a special 'parentpath' private resource. */
>  static dav_error *
>  get_parentpath_resource(request_rec *r,
> @@ -1527,6 +1549,7 @@ get_parentpath_resource(request_rec *r,
>    *resource = &comb->res;
>    return NULL;
>  }
> +#endif
>
>  /* --------------- Borrowed from httpd's mod_negotiation.c --------------
> */
>
> @@ -1955,6 +1978,7 @@ get_resource(request_rec *r,
>    xslt_uri = dav_svn__get_xslt_uri(r);
>    fs_parent_path = dav_svn__get_fs_parent_path(r);
>
> +#if 0
>    /* Special case: detect and build the SVNParentPath as a unique type
>       of private resource, iff the SVNListParentPath directive is 'on'. */
>    if (fs_parent_path && dav_svn__get_list_parentpath_flag(r))
> @@ -1978,6 +2002,7 @@ get_resource(request_rec *r,
>            return NULL;
>          }
>      }
> +#endif
>
>    /* This does all the work of interpreting/splitting the request uri. */
>    err = dav_svn_split_uri(r, r->uri, root_path,
> @@ -3264,8 +3289,13 @@ deliver(const dav_resource *resource, ap
>          {
>            apr_hash_index_t *hi;
>            apr_hash_t *dirents;
> +          int root_path_len = strlen(resource->info->repos->root_path);
>            const char *fs_parent_path =
> -            dav_svn__get_fs_parent_path(resource->info->r);
> +            apr_pstrcat(resource->info->r->pool,
> +                        dav_svn__get_fs_parent_path(resource->info->r),
> +                        resource->info->r->uri
> +                        + ((root_path_len > 1) ? root_path_len : 0),
> +                        NULL);
>
>            serr = svn_io_get_dirents3(&dirents, fs_parent_path, TRUE,
>                                       resource->pool, resource->pool);
>
>
>
>
>
>
>
> On 4/17/13 4:41 PM, Dave Brondsema wrote:
> > On SourceForge our SVN servers run with a patch to SVNParentPath to
> support
> > recursion.  http://subversion.tigris.org/issues/show_bug.cgi?id=3588has some
> > patches for it, but they are old.  I'm seeing if I can get the latest
> version of
> > our patch public that works with a recent release of Subversion.
> >
> > On 4/17/13 5:02 AM, 王再國 wrote:
> >> I think so. "inotifywait, or a simple cron job would probably be
> easier."
> >>
> >> project has subproject. recursively sub project.
> >> allura neighborhood can invite project to other neighborhood.
> >> This will change all relation path.
> >> I don't know sourceforge how to setting svn server.
> >> but I know have many event handler or script.
> >>
> >> now, I use apache macro module.
> >>
> >> 
> >>  
> >>    DAV svn
> >>    SVNParentPath /scm/svn$nh_project
> >>      ...
> >>  
> >> 
> >>
> >> NameVirtualHost 192.168.22.121
> >> >
> >>  Use SVNSetup /p/allura
> >>  Use SVNSetup /p/test
> >>  Use SVNSetup /p/test/sub1
> >> 
> >>
> >> and I need to sync the conf with allura neighborhood; project;
> subproject.
> >> sourceforge how to setting svn server???
> >>
> >> wangaguo
> >>
> >>
> >> 2013/4/17 王再國 >
> >>
> >>     if project & repos below.
> >>     /p/allura/svn
> >>     /p/testproject01/svn
> >>     /p/testproject02/svn
> >>
> >>     and /tmp/svn/ is SVNParentPath
> >>
> >>     maybe symlink below.
> >>     /tmp/svn/allura-svn
> >>     /tmp/svn/testproject01-svn
> >>     /tmp/svn/testproject02-svn
> >>
> >>     but the web url is not below.
> >>     http://svn.allura.org/p/allura/svn
> >>     http://svn.allura.org/p/testproject01/svn
> >>
> >>     web url is below.
> >>     http://svn.allura.org/allura-svn
> >>     http://svn.allura.org/testproject01-svn
> >>
> >>     wangaguo
> >>
> >>
> >>
> >>     2013/4/16 Tim Van Steenburgh  >>     >
> >>
> >>         One idea would be to use bash + inotifywait to watch /tmp/svn,
> and
> >>         rename + symlink new repo directories to another location, and
> use that
> >>         location as the SVNParentPath. I'm not totally sure it would
> work, but
> >>         maybe worth a try?
> >>
> >>         Tim
> >>
> >>         On Tuesday, April 16, 2013 at 2:58 AM, 王再國 wrote:
> >>
> >>>         If all repos in the /tmp/svn then set SVNParentPath on
> /tmp/svn is ok.
> >>>         But allura has three level neighborhood; project; repos.
> >>>         SVNParentPath only support one level parent path. no recursive.
> >>>         e.g. /p/allura/svn1, In apache conf, I only can seting to the
> allura
> >>>         project.
> >>>
> >>>         wangaguo
> >>>
> >>>
> >>>         2013/4/16 王再國 >
> >>>
> >>>             Hi.
> >>>             svn can set SVNParentPath for multiple repository.
> >>>             But allura scm direcotry stucture is
> neighborhood/project/repos.
> >>>             How to setting up svn apache & mod_dav_svn for allura svn
> folder.
> >>>
> >>>             wangaguo
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
>
>
>
> --
> Dave Brondsema : dave@brondsema.net
> http://www.brondsema.net : personal
> http://www.splike.com : programming
>               <><
>

Re: WebOb conflict

2013-04-23T17:51:19Z

Yeah, the numpy & matplotlib packages are difficult to install, and are causing
us problems in other places too (creating the vagrant box, readthedocs setup,
Apache Jenkins which I'm exploring).  So I'd like to work on removing those
dependencies soon.

On 4/23/13 1:46 PM, Tim Van Steenburgh wrote:
> It looks like you don't have a C++ compiler installed. If you're on Ubuntu,
> try `sudo apt-get install g++` before running the pip installs.
> 
> -- 
> Tim Van Steenburgh
> Sent with Sparrow 
> 
> On Tuesday, April 23, 2013 at 1:25 PM, Eugène Adell wrote:
> 
>>
>>
>> Hi all
>>
>> it's still not good, maybe are there other packages which behave like numpy ?
>> The new logs are here : http://95.154.250.47/alluralogs/
>>
>> I notice that the pip install fails with a gcc compil.
>>
>> It's not possible to use the Vagrant image on my server and it would be nice
>> to have the "normal" install process working well
>>
>> Again, thanks for helping.
>>
>>
>> De : Cory Johns [cjohns@slashdotmedia.com ]
>> Envoyé : lundi 22 avril 2013 17:05
>> À : allura-users@incubator.apache.org 
>> Objet : Re: WebOb conflict
>>



-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Re: WebOb conflict

2013-04-23T17:46:48Z

It looks like you don't have a C++ compiler installed. If you're on Ubuntu, try `sudo apt-get
install g++` before running the pip installs.


--  
Tim Van Steenburgh
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Tuesday, April 23, 2013 at 1:25 PM, Eugène Adell wrote:

>  
>  
> Hi all
>  
> it's still not good, maybe are there other packages which behave like numpy ? The new
logs are here : http://95.154.250.47/alluralogs/
>  
> I notice that the pip install fails with a gcc compil.
>  
> It's not possible to use the Vagrant image on my server and it would be nice to have
the "normal" install process working well
>  
> Again, thanks for helping.
>  
>  
> De : Cory Johns [cjohns@slashdotmedia.com (mailto:cjohns@slashdotmedia.com)]
> Envoyé : lundi 22 avril 2013 17:05
> À : allura-users@incubator.apache.org (mailto:allura-users@incubator.apache.org)
> Objet : Re: WebOb conflict
>  
>  
> Eugène,  
>  
>  
> Your pip log shows it failing when installing matplotlib which is causing Pylons to get
skipped. Tim tells me that this is an issue with pip trying to install matplotlib before numpy,
even though numpy is in the file first. The work-around is to manually running `pip install
numpy==1.6.1` in the virtualenv before running `pip install -r requirements.txt`.
>  
>  
> Sorry for the difficulty on this one. You could also try using the Vagrant image that
Tim posted in another thread.
>  
>  
>  
> On Fri, Apr 19, 2013 at 4:55 PM, Eugène Adell 
wrote:
>  
> Hello,
> still bad when trying your method.
>  
> After mkvirtualenv it seems ok :
>  
> # pip freeze
> argparse==1.2.1
> wsgiref==0.1.2
>  
> After " pip install -r requirements.txt " the freeze command returns the same result
as before. But during "python setup.py develop", the problem occurs. The freeze then returns
this :
>  
> # pip freeze
>  
> Warning: cannot find svn location for Ming==0.3.3dev-20130322
>  
> Warning: cannot find svn location for EasyWidgets==0.2dev-20130116
>  
> Allura==0.1dev
> Babel==0.9.6
> BeautifulSoup==3.2.1
> Creoleparser==0.7.4
> ## FIXME: could not find svn URL in dependency_links for this package:
> EasyWidgets==0.2dev-20130116
> FormEncode==1.2.6
> Jinja2==2.6
> Markdown==2.3.1
> ## FIXME: could not find svn URL in dependency_links for this package:
> Ming==0.3.3dev-20130322
> PIL==1.1.7
> Pygments==1.6
> Pylons==1.0.1
> Pypeline==0.1dev
> TurboGears2==2.2.2
> WebError==0.10.3
> WebFlash==0.1a9
> WebHelpers==1.3
> WebOb==1.2.3
> WebTest==2.0.5
> argparse==1.2.1
> chardet==2.1.1
> crank==0.6.4
> datadiff==1.1.5
> docutils==0.10
> feedparser==5.1.3
> httplib2==0.8
> iso8601==0.1.4
> mock==1.0.1
> nose==1.3.0
> oauth2==1.5.211
> pymongo==2.5
> pysolr==3.0.6
> python-dateutil==2.1
> python-openid==2.2.5
> requests==1.2.0
> textile==2.1.5
> wsgiref==0.1.2
>  
> I put the two logs coming from "pip install" and "python setup.py" here : http://95.154.250.47/alluralogs/
>  
> Thanks a lot
>  
>  
>  
>  
>  
>  
> De : Cory Johns [cjohns@slashdotmedia.com (mailto:cjohns@slashdotmedia.com)]
> Envoyé : vendredi 19 avril 2013 15:33
>  
> À : allura-users@incubator.apache.org (mailto:allura-users@incubator.apache.org)
> Objet : Re: WebOb conflict
>  
>  
> I'm really at a loss here, as I tested the build myself on a fresh virtualenv created
with:
>  
>  
> [cjohns allura]$ mkvirtualenv test-allura --no-site-packages
> New python executable in test-allura/bin/python27
> Also creating executable in test-allura/bin/python
> Installing setuptools............done.
> [cjohns allura]$ workon test-allura
> (test-allura)[cjohns allura]$ pip freeze
> wsgiref==0.1.2
>  
> (test-allura)[cjohns allura]$ pip install -r requirements.txt
> ...
> (test-allura)[cjohns allura]$ pip freeze | egrep 'Pylons|WebOb'
> Pylons==1.0
> WebOb==1.0.8
>  
>  
> Other than a build error on matplotlib, everything went as expected and I ended up with
the expected versions.
>  
>  
> My advice would be to ensure that you start with a fresh virtualenv with --no-site-packages
explicitly stated, ensure it has no unexpected initial packages via pip freeze, and perform
the pip install -r requirements.txt before installing any additional libraries.
>  
>  
>  
> On Thu, Apr 18, 2013 at 5:49 AM, Eugène Adell 
wrote:
>  
>  
> I get the same problem on a fresh VM with a fresh virtualenv. I am following this doc
:
>  
> https://sourceforge.net/p/allura/git/ci/master/tree/README.markdown
>  
> Now, the error looks like this :
>  
> ...
> Searching for Pylons
> Reading http://pypi.python.org/simple/Pylons/
> Reading http://www.pylonshq.com/
> Best match: Pylons 1.0.1
> Downloading http://pypi.python.org/packages/source/P/Pylons/Pylons-1.0.1.tar.gz#md5=6cb880d75fa81213192142b07a6e4915
> Processing Pylons-1.0.1.tar.gz
> Running Pylons-1.0.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-7xHulp/Pylons-1.0.1/egg-dist-tmp-nBfo7J
> warning: no previously-included files matching '*' found under directory 'tests/test_units/session'
> warning: no previously-included files matching '.DS_Store' found anywhere in distribution
> warning: no previously-included files matching '*.hgignore' found anywhere in distribution
> warning: no previously-included files matching '*.hgtags' found anywhere in distribution
> Adding Pylons 1.0.1 to easy-install.pth file
>  
> Installed /root/anvil/lib/python2.7/site-packages/Pylons-1.0.1-py2.7.egg
> Reading http://www.pylonshq.com/download/1.0
>  
> error: Installed distribution WebOb 1.2.3 conflicts with requirement WebOb==1.1.1
>  
>  
>  
>  
> ________________________________________
> De : Cory Johns [cjohns@slashdotmedia.com (mailto:cjohns@slashdotmedia.com)]
> Envoyé : mardi 16 avril 2013 16:20
>  
> À : allura-users@incubator.apache.org (mailto:allura-users@incubator.apache.org)
> Objet : Re: WebOb conflict
>  
>  
> Dave makes a good point. Instead of trying to triage specific version conflicts, a better
approach would be to create a fresh virtualenv (making sure not to include site packages,
although that's been the default behavior for a while; but you might want to check your virtualenv
/ mkvirtualenv version just to be sure) and then install just the required libraries with:
>  
> pip install -r requirements.txt
>  
> As Dave mentioned, the README file has more detailed instructions.
>  
>  
>  
> On Mon, Apr 15, 2013 at 5:55 PM, Dave Brondsema >
wrote:
> Hey Eugène, just wondering did you install with a fresh python virtual
> environment and the requirements.txt file? If you follow the instructions in
> the README to do that I don't think you'd have any version errors.
>  
> On 4/15/13 2:06 PM, Eugène Adell wrote:
> >  
> > Still not good, is there any way to find the root cause ? Again, thanks for helping
> >  
> > # pip list
> > Allura (0.1dev)
> > argparse (1.2.1)
> > Babel (0.9.6)
> > Beaker (1.6.4)
> > BeautifulSoup (3.2.1)
> > beautifulsoup4 (4.1.3)
> > chardet (2.1.1)
> > crank (0.6.4)
> > Creoleparser (0.7.4)
> > datadiff (1.1.5)
> > decorator (3.4.0)
> > docutils (0.10)
> > Warning: cannot find svn location for EasyWidgets==0.2dev-20130116
> > EasyWidgets (0.2dev-20130116)
> > feedparser (5.1.3)
> > ForgeWiki (0.0dev)
> > FormEncode (1.2.6)
> > httplib2 (0.8)
> > iso8601 (0.1.4)
> > Jinja2 (2.6)
> > Mako (0.8.0)
> > Markdown (2.3.1)
> > MarkupSafe (0.15)
> > Warning: cannot find svn location for Ming==0.3.3dev-20130322
> > Ming (0.3.3dev-20130322)
> > mock (1.0.1)
> > nose (1.3.0)
> > oauth2 (1.5.211)
> > PIL (1.1.7)
> > Pygments (1.6)
> > Pylons (1.0)
> > pymongo (2.5)
> > Pypeline (0.1dev)
> > pysolr (3.0.6)
> > python-dateutil (2.1)
> > python-openid (2.2.5)
> > repoze.lru (0.6)
> > requests (1.2.0)
> > Routes (1.13)
> > simplejson (3.1.3)
> > Tempita (0.5.1)
> > textile (2.1.5)
> > TurboGears2 (2.2.2)
> > waitress (0.8.2)
> > WebError (0.10.3)
> > WebFlash (0.1a9)
> > WebHelpers (1.3)
> > WebOb (1.0.8)
> > WebTest (1.4.0)
> > wsgiref (0.1.2)
> >  
> >  
> > # python setup.py develop
> > running develop
> > running egg_info
> > writing paster_plugins to Allura.egg-info/paster_plugins.txt
> > writing requirements to Allura.egg-info/requires.txt
> > writing Allura.egg-info/PKG-INFO
> > writing top-level names to Allura.egg-info/top_level.txt
> > writing dependency_links to Allura.egg-info/dependency_links.txt
> > writing entry points to Allura.egg-info/entry_points.txt
> > reading manifest file 'Allura.egg-info/SOURCES.txt'
> > reading manifest template 'MANIFEST.in (http://MANIFEST.in)'
> > warning: no files found matching 'allura/public/favicon.ico'
> > writing manifest file 'Allura.egg-info/SOURCES.txt'
> > running build_ext
> > Creating /root/anvil/lib/python2.7/site-packages/Allura.egg-link (link to .)
> > Allura 0.1dev is already the active version in easy-install.pth
> > Installed /root/src/allura/Allura
> > Processing dependencies for Allura==0.1dev
> > error: Installed distribution WebOb 1.0.8 conflicts with requirement WebOb==1.1.1
> >  
>  
>  
> > De : Cory Johns [cjohns@slashdotmedia.com]
>  
> > Envoyé : lundi 15 avril 2013 19:06
>  
> > À : allura-users@incubator.apache.org
>  
> > Objet : Re: WebOb conflict
> >  
> >  
> > It looks like the conflict is coming from your version of Pylons. We're using 1.0,
while you appear to have 1.0.1 installed. That .0.1 release apparently updated quite a few
requirements.
>  
> > On Mon, Apr 15, 2013 at 12:40 PM, Eugène Adell >
wrote:
> >  
> >  
> > Hello
> >  
> > thanks ; after downgrading I still got a conflict error :
> >  
> > # pip list
> > Allura (0.1dev)
> > argparse (1.2.1)
> > Babel (0.9.6)
> > BeautifulSoup (3.2.1)
> > beautifulsoup4 (4.1.3)
> > chardet (2.1.1)
> > crank (0.6.4)
> > Creoleparser (0.7.4)
> > datadiff (1.1.5)
> > docutils (0.10)
> > Warning: cannot find svn location for EasyWidgets==0.2dev-20130116
> > EasyWidgets (0.2dev-20130116)
> > feedparser (5.1.3)
> > ForgeWiki (0.0dev)
> > FormEncode (1.2.6)
> > httplib2 (0.8)
> > iso8601 (0.1.4)
> > Jinja2 (2.6)
> > Markdown (2.3.1)
> > Warning: cannot find svn location for Ming==0.3.3dev-20130322
> > Ming (0.3.3dev-20130322)
> > mock (1.0.1)
> > nose (1.3.0)
> > oauth2 (1.5.211)
> > PIL (1.1.7)
> > Pygments (1.6)
> > Pylons (1.0.1)
> > pymongo (2.5)
> > Pypeline (0.1dev)
> > pysolr (3.0.6)
> > python-dateutil (2.1)
> > python-openid (2.2.5)
> > requests (1.2.0)
> > textile (2.1.5)
> > TurboGears2 (2.2.2)
> > waitress (0.8.2)
> > WebError (0.10.3)
> > WebFlash (0.1a9)
> > WebHelpers (1.3)
> > WebOb (1.0.8)
> > WebTest (1.4.0)
> > wsgiref (0.1.2)
> >  
> >  
> > # python setup.py develop
> > running develop
> > running egg_info
> > writing paster_plugins to Allura.egg-info/paster_plugins.txt
> > writing requirements to Allura.egg-info/requires.txt
> > writing Allura.egg-info/PKG-INFO
> > writing top-level names to Allura.egg-info/top_level.txt
> > writing dependency_links to Allura.egg-info/dependency_links.txt
> > writing entry points to Allura.egg-info/entry_points.txt
> > reading manifest file 'Allura.egg-info/SOURCES.txt'
> > reading manifest template 'MANIFEST.in (http://MANIFEST.in)'
> > warning: no files found matching 'allura/public/favicon.ico'
> > writing manifest file 'Allura.egg-info/SOURCES.txt'
> > running build_ext
> > Creating /root/anvil/lib/python2.7/site-packages/Allura.egg-link (link to .)
> > Allura 0.1dev is already the active version in easy-install.pth
> > Installed /root/src/allura/Allura
> > Processing dependencies for Allura==0.1dev
> > error: Installed distribution WebOb 1.0.8 conflicts with requirement WebOb==1.1.1
> >  
>  
>  
> > De : Cory Johns [cjohns@slashdotmedia.com]
>  
> > Envoyé : lundi 15 avril 2013 18:01
>  
> > À : allura-users@incubator.apache.org
>  
> > Objet : Re: WebOb conflict
> >  
> >  
> >  
> > Eugène,
> >  
> >  
> >  
> > Our requirements actually list WebOb 1.0.8 (in requirements-common.txt), which is
what we use at SourceForge and what we've tested with and can confirm works. The 1.1.1 requirement
appears to be coming from WebTest, indicating you have a higher version than the 1.4.0 specified
in requirements-common.txt, yet not the newest version which specifies >= 1.2 for WebOb.
> >  
> >  
> > If you wish to try running with WebOb 1.2.3, you could try upgrading your WebTest
version, but since we haven't tested with those versions, I can't say that it will work without
further error. My recommendation would be to downgrade WebTest to 1.4.0 and WebOb to 1.0.8
but I don't know of any specific issues with the newer versions that would cause issues, so
it may be worth a try.
> >  
> >  
> >  
> >  
> > - Cory
>  
> > On Sun, Apr 14, 2013 at 4:04 PM, Eugène Adell >
wrote:
> >  
> > Hello
> >  
> > when installing Allura, I get an error at this step :
> >  
> >  
> > $ python setup.py develop
> >  
> > error: Installed distribution WebOb 1.2.3 conflicts with requirement WebOb==1.1.1
> >  
> >  
> > Do I need to force an install with WebOb 1.1.1 ?
>  
>  
>  
> --
>  
> Dave Brondsema : dave@brondsema.net
>  
> http://www.brondsema.net : personal
> http://www.splike.com : programming
> <><
>  
>

RE:WebOb conflict

2013-04-23T17:25:03Z



Hi all

it's still not good, maybe are there other packages which behave like numpy ? The new logs
are here : http://95.154.250.47/alluralogs/

I notice that the pip install fails with a gcc compil.

It's not possible to use the Vagrant image on my server and it would be nice to have the "normal"
install process working well

Again, thanks for helping.


De : Cory Johns [cjohns@slashdotmedia.com]
Envoyé : lundi 22 avril 2013 17:05
À : allura-users@incubator.apache.org
Objet : Re: WebOb conflict


Eugène, 


Your pip log shows it failing when installing matplotlib which is causing Pylons to get skipped.
 Tim tells me that this is an issue with pip trying to install matplotlib before numpy, even
though numpy is in the file first.  The work-around is to manually running `pip install numpy==1.6.1`
in the virtualenv before running `pip install -r requirements.txt`.


Sorry for the difficulty on this one.  You could also try using the Vagrant image that Tim
posted in another thread.



On Fri, Apr 19, 2013 at 4:55 PM, Eugène Adell  wrote:

Hello,
still bad when trying your method.

After mkvirtualenv it seems ok :

# pip freeze
argparse==1.2.1
wsgiref==0.1.2

After " pip install -r requirements.txt " the freeze command returns the same result as before.
But during "python setup.py develop", the problem occurs. The freeze then returns this :

# pip freeze

Warning: cannot find svn location for Ming==0.3.3dev-20130322

Warning: cannot find svn location for EasyWidgets==0.2dev-20130116

Allura==0.1dev
Babel==0.9.6
BeautifulSoup==3.2.1
Creoleparser==0.7.4
## FIXME: could not find svn URL in dependency_links for this package:
EasyWidgets==0.2dev-20130116
FormEncode==1.2.6
Jinja2==2.6
Markdown==2.3.1
## FIXME: could not find svn URL in dependency_links for this package:
Ming==0.3.3dev-20130322
PIL==1.1.7
Pygments==1.6
Pylons==1.0.1
Pypeline==0.1dev
TurboGears2==2.2.2
WebError==0.10.3
WebFlash==0.1a9
WebHelpers==1.3
WebOb==1.2.3
WebTest==2.0.5
argparse==1.2.1
chardet==2.1.1
crank==0.6.4
datadiff==1.1.5
docutils==0.10
feedparser==5.1.3
httplib2==0.8
iso8601==0.1.4
mock==1.0.1
nose==1.3.0
oauth2==1.5.211
pymongo==2.5
pysolr==3.0.6
python-dateutil==2.1
python-openid==2.2.5
requests==1.2.0
textile==2.1.5
wsgiref==0.1.2

I put the two logs coming from "pip install" and "python setup.py" here : http://95.154.250.47/alluralogs/

Thanks a lot






De : Cory Johns [cjohns@slashdotmedia.com]
Envoyé : vendredi 19 avril 2013 15:33

À : allura-users@incubator.apache.org
Objet : Re: WebOb conflict


I'm really at a loss here, as I tested the build myself on a fresh virtualenv created with:


    [cjohns allura]$ mkvirtualenv test-allura --no-site-packages
    New python executable in test-allura/bin/python27
    Also creating executable in test-allura/bin/python
    Installing setuptools............done.
    [cjohns allura]$ workon test-allura
    (test-allura)[cjohns allura]$ pip freeze
    wsgiref==0.1.2

    (test-allura)[cjohns allura]$ pip install -r requirements.txt
...
    (test-allura)[cjohns allura]$ pip freeze | egrep 'Pylons|WebOb'
    Pylons==1.0
    WebOb==1.0.8


Other than a build error on matplotlib, everything went as expected and I ended up with the
expected versions.


My advice would be to ensure that you start with a fresh virtualenv with --no-site-packages
explicitly stated, ensure it has no unexpected initial packages via pip freeze, and perform
the pip install -r requirements.txt before installing any additional libraries.



On Thu, Apr 18, 2013 at 5:49 AM, Eugène Adell  wrote:


I get the same problem on a fresh VM with a fresh virtualenv. I am following this doc :

https://sourceforge.net/p/allura/git/ci/master/tree/README.markdown

Now, the error looks like this :

...
Searching for Pylons
Reading http://pypi.python.org/simple/Pylons/
Reading http://www.pylonshq.com/
Best match: Pylons 1.0.1
Downloading http://pypi.python.org/packages/source/P/Pylons/Pylons-1.0.1.tar.gz#md5=6cb880d75fa81213192142b07a6e4915
Processing Pylons-1.0.1.tar.gz
Running Pylons-1.0.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-7xHulp/Pylons-1.0.1/egg-dist-tmp-nBfo7J
warning: no previously-included files matching '*' found under directory 'tests/test_units/session'
warning: no previously-included files matching '.DS_Store' found anywhere in distribution
warning: no previously-included files matching '*.hgignore' found anywhere in distribution
warning: no previously-included files matching '*.hgtags' found anywhere in distribution
Adding Pylons 1.0.1 to easy-install.pth file

Installed /root/anvil/lib/python2.7/site-packages/Pylons-1.0.1-py2.7.egg
Reading http://www.pylonshq.com/download/1.0

error: Installed distribution WebOb 1.2.3 conflicts with requirement WebOb==1.1.1




________________________________________
De : Cory Johns [cjohns@slashdotmedia.com]
Envoyé : mardi 16 avril 2013 16:20

À : allura-users@incubator.apache.org
Objet : Re: WebOb conflict


Dave makes a good point.  Instead of trying to triage specific version conflicts, a better
approach would be to create a fresh virtualenv (making sure not to include site packages,
although that's been the default behavior for a while; but you might want to check your virtualenv
/ mkvirtualenv version just to be sure) and then install just the required libraries with:

  pip install -r requirements.txt

As Dave mentioned, the README file has more detailed instructions.



On Mon, Apr 15, 2013 at 5:55 PM, Dave Brondsema >
wrote:
Hey Eugène, just wondering did you install with a fresh python virtual
environment and the requirements.txt file?  If you follow the instructions in
the README to do that I don't think you'd have any version errors.

On 4/15/13 2:06 PM, Eugène Adell wrote:
>
> Still not good, is there any way to find the root cause ? Again, thanks for helping
>
> # pip list
> Allura (0.1dev)
> argparse (1.2.1)
> Babel (0.9.6)
> Beaker (1.6.4)
> BeautifulSoup (3.2.1)
> beautifulsoup4 (4.1.3)
> chardet (2.1.1)
> crank (0.6.4)
> Creoleparser (0.7.4)
> datadiff (1.1.5)
> decorator (3.4.0)
> docutils (0.10)
> Warning: cannot find svn location for EasyWidgets==0.2dev-20130116
> EasyWidgets (0.2dev-20130116)
> feedparser (5.1.3)
> ForgeWiki (0.0dev)
> FormEncode (1.2.6)
> httplib2 (0.8)
> iso8601 (0.1.4)
> Jinja2 (2.6)
> Mako (0.8.0)
> Markdown (2.3.1)
> MarkupSafe (0.15)
> Warning: cannot find svn location for Ming==0.3.3dev-20130322
> Ming (0.3.3dev-20130322)
> mock (1.0.1)
> nose (1.3.0)
> oauth2 (1.5.211)
> PIL (1.1.7)
> Pygments (1.6)
> Pylons (1.0)
> pymongo (2.5)
> Pypeline (0.1dev)
> pysolr (3.0.6)
> python-dateutil (2.1)
> python-openid (2.2.5)
> repoze.lru (0.6)
> requests (1.2.0)
> Routes (1.13)
> simplejson (3.1.3)
> Tempita (0.5.1)
> textile (2.1.5)
> TurboGears2 (2.2.2)
> waitress (0.8.2)
> WebError (0.10.3)
> WebFlash (0.1a9)
> WebHelpers (1.3)
> WebOb (1.0.8)
> WebTest (1.4.0)
> wsgiref (0.1.2)
>
>
> # python setup.py develop
> running develop
> running egg_info
> writing paster_plugins to Allura.egg-info/paster_plugins.txt
> writing requirements to Allura.egg-info/requires.txt
> writing Allura.egg-info/PKG-INFO
> writing top-level names to Allura.egg-info/top_level.txt
> writing dependency_links to Allura.egg-info/dependency_links.txt
> writing entry points to Allura.egg-info/entry_points.txt
> reading manifest file 'Allura.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> warning: no files found matching 'allura/public/favicon.ico'
> writing manifest file 'Allura.egg-info/SOURCES.txt'
> running build_ext
> Creating /root/anvil/lib/python2.7/site-packages/Allura.egg-link (link to .)
> Allura 0.1dev is already the active version in easy-install.pth
> Installed /root/src/allura/Allura
> Processing dependencies for Allura==0.1dev
> error: Installed distribution WebOb 1.0.8 conflicts with requirement WebOb==1.1.1
>
>
>

> De : Cory Johns [cjohns@slashdotmedia.com]

> Envoyé : lundi 15 avril 2013 19:06

> À : allura-users@incubator.apache.org

> Objet : Re: WebOb conflict
>
>
> It looks like the conflict is coming from your version of Pylons.  We're using 1.0, while
you appear to have 1.0.1 installed.  That .0.1 release apparently updated quite a few requirements.
>
>
>

> On Mon, Apr 15, 2013 at 12:40 PM, Eugène Adell >
wrote:
>
>
> Hello
>
> thanks ; after downgrading I still got a conflict error :
>
> # pip list
> Allura (0.1dev)
> argparse (1.2.1)
> Babel (0.9.6)
> BeautifulSoup (3.2.1)
> beautifulsoup4 (4.1.3)
> chardet (2.1.1)
> crank (0.6.4)
> Creoleparser (0.7.4)
> datadiff (1.1.5)
> docutils (0.10)
> Warning: cannot find svn location for EasyWidgets==0.2dev-20130116
> EasyWidgets (0.2dev-20130116)
> feedparser (5.1.3)
> ForgeWiki (0.0dev)
> FormEncode (1.2.6)
> httplib2 (0.8)
> iso8601 (0.1.4)
> Jinja2 (2.6)
> Markdown (2.3.1)
> Warning: cannot find svn location for Ming==0.3.3dev-20130322
> Ming (0.3.3dev-20130322)
> mock (1.0.1)
> nose (1.3.0)
> oauth2 (1.5.211)
> PIL (1.1.7)
> Pygments (1.6)
> Pylons (1.0.1)
> pymongo (2.5)
> Pypeline (0.1dev)
> pysolr (3.0.6)
> python-dateutil (2.1)
> python-openid (2.2.5)
> requests (1.2.0)
> textile (2.1.5)
> TurboGears2 (2.2.2)
> waitress (0.8.2)
> WebError (0.10.3)
> WebFlash (0.1a9)
> WebHelpers (1.3)
> WebOb (1.0.8)
> WebTest (1.4.0)
> wsgiref (0.1.2)
>
>
> # python setup.py develop
> running develop
> running egg_info
> writing paster_plugins to Allura.egg-info/paster_plugins.txt
> writing requirements to Allura.egg-info/requires.txt
> writing Allura.egg-info/PKG-INFO
> writing top-level names to Allura.egg-info/top_level.txt
> writing dependency_links to Allura.egg-info/dependency_links.txt
> writing entry points to Allura.egg-info/entry_points.txt
> reading manifest file 'Allura.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> warning: no files found matching 'allura/public/favicon.ico'
> writing manifest file 'Allura.egg-info/SOURCES.txt'
> running build_ext
> Creating /root/anvil/lib/python2.7/site-packages/Allura.egg-link (link to .)
> Allura 0.1dev is already the active version in easy-install.pth
> Installed /root/src/allura/Allura
> Processing dependencies for Allura==0.1dev
> error: Installed distribution WebOb 1.0.8 conflicts with requirement WebOb==1.1.1
>
>
>
>
>
>

> De : Cory Johns [cjohns@slashdotmedia.com]

> Envoyé : lundi 15 avril 2013 18:01

> À : allura-users@incubator.apache.org

> Objet : Re: WebOb conflict
>
>
>
> Eugène,
>
>
>
> Our requirements actually list WebOb 1.0.8 (in requirements-common.txt), which is what
we use at SourceForge and what we've tested with and can confirm works.  The 1.1.1 requirement
appears to be coming from WebTest, indicating you have a higher version than the 1.4.0 specified
in requirements-common.txt, yet not the newest version which specifies >= 1.2 for WebOb.
>
>
> If you wish to try running with WebOb 1.2.3, you could try upgrading your WebTest version,
but since we haven't tested with those versions, I can't say that it will work without further
error.  My recommendation would be to downgrade WebTest to 1.4.0 and WebOb to 1.0.8 but I
don't know of any specific issues with the newer versions that would cause issues, so it may
be worth a try.
>
>
>
>
> - Cory
>
>
>

> On Sun, Apr 14, 2013 at 4:04 PM, Eugène Adell >
wrote:
>
> Hello
>
> when installing Allura, I get an error at this step :
>
>
> $ python setup.py develop
>
> error: Installed distribution WebOb 1.2.3 conflicts with requirement WebOb==1.1.1
>
>
> Do I need to force an install with WebOb 1.1.1 ?
>



--

Dave Brondsema : dave@brondsema.net

http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Re: Subversion server setting on apache & mod_dav_svn

2013-04-22T15:28:56Z

Here's the latest version of the patch
https://sourceforge.net/p/allura/pastebin/517557273e5e837ec65122c1/


diff -rup subversion-1.7.7.orig/subversion/libsvn_repos/repos.c
subversion-1.7.7/subversion/libsvn_repos/repos.c
--- subversion-1.7.7.orig/subversion/libsvn_repos/repos.c	2012-11-15
16:04:07.000000000 +0000
+++ subversion-1.7.7/subversion/libsvn_repos/repos.c	2012-12-07
23:06:10.352959642 +0000
@@ -1286,7 +1286,7 @@ svn_repos_create(svn_repos_t **repos_p,
  * on errors (which would be permission errors, probably) so that
  * we the user will see them after we try to open the repository
  * for real.  */
-static svn_boolean_t
+svn_boolean_t
 check_repos_path(const char *path,
                  apr_pool_t *pool)
 {
diff -rup subversion-1.7.7.orig/subversion/mod_dav_svn/repos.c
subversion-1.7.7/subversion/mod_dav_svn/repos.c
--- subversion-1.7.7.orig/subversion/mod_dav_svn/repos.c	2012-11-15
16:04:07.000000000 +0000
+++ subversion-1.7.7/subversion/mod_dav_svn/repos.c	2012-12-07
23:06:18.291130038 +0000
@@ -1288,10 +1288,13 @@ dav_svn_split_uri(request_rec *r,

   else
     {
-      /* SVNParentPath was used instead: assume the first component of
+      /* SVNParentPath was used instead: figure out which component of
          'relative' is the name of a repository. */
-      const char *magic_component, *magic_end;
+      extern svn_boolean_t check_repos_path(const char *path, apr_pool_t *pool);
+      const char *magic_component = NULL, *magic_end;
+      char *repos_path;

+     do {
       /* A repository name is required here.
          Remember that 'relative' always starts with a "/". */
       if (relative[1] == '\0')
@@ -1309,16 +1312,34 @@ dav_svn_split_uri(request_rec *r,
           /* ### Request was for parent directory with no trailing
              slash; we probably ought to just redirect to same with
              trailing slash appended. */
+         if (!magic_component)
           magic_component = relative + 1;
+         else {
+          magic_component = apr_pstrcat(r->pool, magic_component,
+                                        relative, NULL);
+         }
           relative = "/";
         }
       else
         {
+         if (!magic_component)
           magic_component = apr_pstrndup(r->pool, relative + 1,
                                          magic_end - relative - 1);
+         else {
+          char *tmp_magic_component;
+
+          tmp_magic_component = apr_pstrndup(r->pool, relative,
+                                             magic_end - relative);
+          magic_component = apr_pstrcat(r->pool, magic_component,
+                                        tmp_magic_component, NULL);
+         }
           relative = magic_end;
         }

+      repos_path = svn_path_join(fs_parent_path, magic_component,
+                                 r->pool);
+     } while (check_repos_path(repos_path, r->pool) != TRUE);
+
       /* return answer */
       *repos_basename = magic_component;
     }
@@ -1472,6 +1493,7 @@ cleanup_fs_access(void *data)
 }


+#if 0
 /* Helper func to construct a special 'parentpath' private resource. */
 static dav_error *
 get_parentpath_resource(request_rec *r,
@@ -1527,6 +1549,7 @@ get_parentpath_resource(request_rec *r,
   *resource = &comb->res;
   return NULL;
 }
+#endif

 /* --------------- Borrowed from httpd's mod_negotiation.c -------------- */

@@ -1955,6 +1978,7 @@ get_resource(request_rec *r,
   xslt_uri = dav_svn__get_xslt_uri(r);
   fs_parent_path = dav_svn__get_fs_parent_path(r);

+#if 0
   /* Special case: detect and build the SVNParentPath as a unique type
      of private resource, iff the SVNListParentPath directive is 'on'. */
   if (fs_parent_path && dav_svn__get_list_parentpath_flag(r))
@@ -1978,6 +2002,7 @@ get_resource(request_rec *r,
           return NULL;
         }
     }
+#endif

   /* This does all the work of interpreting/splitting the request uri. */
   err = dav_svn_split_uri(r, r->uri, root_path,
@@ -3264,8 +3289,13 @@ deliver(const dav_resource *resource, ap
         {
           apr_hash_index_t *hi;
           apr_hash_t *dirents;
+          int root_path_len = strlen(resource->info->repos->root_path);
           const char *fs_parent_path =
-            dav_svn__get_fs_parent_path(resource->info->r);
+            apr_pstrcat(resource->info->r->pool,
+                        dav_svn__get_fs_parent_path(resource->info->r),
+                        resource->info->r->uri
+                        + ((root_path_len > 1) ? root_path_len : 0),
+                        NULL);

           serr = svn_io_get_dirents3(&dirents, fs_parent_path, TRUE,
                                      resource->pool, resource->pool);







On 4/17/13 4:41 PM, Dave Brondsema wrote:
> On SourceForge our SVN servers run with a patch to SVNParentPath to support
> recursion.  http://subversion.tigris.org/issues/show_bug.cgi?id=3588 has some
> patches for it, but they are old.  I'm seeing if I can get the latest version of
> our patch public that works with a recent release of Subversion.
> 
> On 4/17/13 5:02 AM, 王再國 wrote:
>> I think so. "inotifywait, or a simple cron job would probably be easier."
>>
>> project has subproject. recursively sub project.
>> allura neighborhood can invite project to other neighborhood.
>> This will change all relation path.
>> I don't know sourceforge how to setting svn server.
>> but I know have many event handler or script.
>>
>> now, I use apache macro module.
>>
>> 
>>  
>>    DAV svn
>>    SVNParentPath /scm/svn$nh_project
>>      ...
>>  
>> 
>>
>> NameVirtualHost 192.168.22.121
>> >
>>  Use SVNSetup /p/allura
>>  Use SVNSetup /p/test
>>  Use SVNSetup /p/test/sub1
>> 
>>
>> and I need to sync the conf with allura neighborhood; project; subproject.
>> sourceforge how to setting svn server???
>>
>> wangaguo
>>
>>
>> 2013/4/17 王再國 >
>>
>>     if project & repos below.
>>     /p/allura/svn
>>     /p/testproject01/svn
>>     /p/testproject02/svn
>>
>>     and /tmp/svn/ is SVNParentPath
>>
>>     maybe symlink below.
>>     /tmp/svn/allura-svn
>>     /tmp/svn/testproject01-svn
>>     /tmp/svn/testproject02-svn
>>
>>     but the web url is not below.
>>     http://svn.allura.org/p/allura/svn
>>     http://svn.allura.org/p/testproject01/svn
>>
>>     web url is below.
>>     http://svn.allura.org/allura-svn
>>     http://svn.allura.org/testproject01-svn
>>
>>     wangaguo
>>
>>
>>
>>     2013/4/16 Tim Van Steenburgh >     >
>>
>>         One idea would be to use bash + inotifywait to watch /tmp/svn, and
>>         rename + symlink new repo directories to another location, and use that
>>         location as the SVNParentPath. I'm not totally sure it would work, but
>>         maybe worth a try?
>>
>>         Tim
>>
>>         On Tuesday, April 16, 2013 at 2:58 AM, 王再國 wrote:
>>
>>>         If all repos in the /tmp/svn then set SVNParentPath on /tmp/svn is ok.
>>>         But allura has three level neighborhood; project; repos.
>>>         SVNParentPath only support one level parent path. no recursive.
>>>         e.g. /p/allura/svn1, In apache conf, I only can seting to the allura
>>>         project.
>>>
>>>         wangaguo
>>>
>>>
>>>         2013/4/16 王再國 >
>>>
>>>             Hi.
>>>             svn can set SVNParentPath for multiple repository.
>>>             But allura scm direcotry stucture is neighborhood/project/repos.
>>>             How to setting up svn apache & mod_dav_svn for allura svn folder.
>>>
>>>             wangaguo
>>>
>>>
>>>
>>
>>
>>
> 
> 
> 



-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Re: WebOb conflict

2013-04-22T15:05:06Z

Eugène,

Your pip log shows it failing when installing matplotlib which is causing
Pylons to get skipped.  Tim tells me that this is an issue with pip trying
to install matplotlib before numpy, even though numpy is in the file first.
 The work-around is to manually running `pip install numpy==1.6.1` in the
virtualenv before running `pip install -r requirements.txt`.

Sorry for the difficulty on this one.  You could also try using the Vagrant
image that Tim posted in another thread.


On Fri, Apr 19, 2013 at 4:55 PM, Eugène Adell  wrote:

> Hello,
> still bad when trying your method.
>
> After mkvirtualenv it seems ok :
>
> # pip freeze
> argparse==1.2.1
> wsgiref==0.1.2
>
> After " pip install -r requirements.txt " the freeze command returns the
> same result as before. But during "python setup.py develop", the problem
> occurs. The freeze then returns this :
>
> # pip freeze
> Warning: cannot find svn location for Ming==0.3.3dev-20130322
> Warning: cannot find svn location for EasyWidgets==0.2dev-20130116
> Allura==0.1dev
> Babel==0.9.6
> BeautifulSoup==3.2.1
> Creoleparser==0.7.4
> ## FIXME: could not find svn URL in dependency_links for this package:
> EasyWidgets==0.2dev-20130116
> FormEncode==1.2.6
> Jinja2==2.6
> Markdown==2.3.1
> ## FIXME: could not find svn URL in dependency_links for this package:
> Ming==0.3.3dev-20130322
> PIL==1.1.7
> Pygments==1.6
> Pylons==1.0.1
> Pypeline==0.1dev
> TurboGears2==2.2.2
> WebError==0.10.3
> WebFlash==0.1a9
> WebHelpers==1.3
> WebOb==1.2.3
> WebTest==2.0.5
> argparse==1.2.1
> chardet==2.1.1
> crank==0.6.4
> datadiff==1.1.5
> docutils==0.10
> feedparser==5.1.3
> httplib2==0.8
> iso8601==0.1.4
> mock==1.0.1
> nose==1.3.0
> oauth2==1.5.211
> pymongo==2.5
> pysolr==3.0.6
> python-dateutil==2.1
> python-openid==2.2.5
> requests==1.2.0
> textile==2.1.5
> wsgiref==0.1.2
>
> I put the two logs coming from "pip install" and "python setup.py" here :
> http://95.154.250.47/alluralogs/
>
> Thanks a lot
>
>
>
>
>
>
> De : Cory Johns [cjohns@slashdotmedia.com]
> Envoyé : vendredi 19 avril 2013 15:33
> À : allura-users@incubator.apache.org
> Objet : Re: WebOb conflict
>
>
> I'm really at a loss here, as I tested the build myself on a fresh
> virtualenv created with:
>
>
>     [cjohns allura]$ mkvirtualenv test-allura --no-site-packages
>     New python executable in test-allura/bin/python27
>     Also creating executable in test-allura/bin/python
>     Installing setuptools............done.
>     [cjohns allura]$ workon test-allura
>     (test-allura)[cjohns allura]$ pip freeze
>     wsgiref==0.1.2
>
>     (test-allura)[cjohns allura]$ pip install -r requirements.txt
> ...
>     (test-allura)[cjohns allura]$ pip freeze | egrep 'Pylons|WebOb'
>     Pylons==1.0
>     WebOb==1.0.8
>
>
> Other than a build error on matplotlib, everything went as expected and I
> ended up with the expected versions.
>
>
> My advice would be to ensure that you start with a fresh virtualenv with
> --no-site-packages explicitly stated, ensure it has no unexpected initial
> packages via pip freeze, and perform the pip install -r requirements.txt
> before installing any additional libraries.
>
>
>
> On Thu, Apr 18, 2013 at 5:49 AM, Eugène Adell 
> wrote:
>
>
> I get the same problem on a fresh VM with a fresh virtualenv. I am
> following this doc :
>
> https://sourceforge.net/p/allura/git/ci/master/tree/README.markdown
>
> Now, the error looks like this :
>
> ...
> Searching for Pylons
> Reading http://pypi.python.org/simple/Pylons/
> Reading http://www.pylonshq.com/
> Best match: Pylons 1.0.1
> Downloading
> http://pypi.python.org/packages/source/P/Pylons/Pylons-1.0.1.tar.gz#md5=6cb880d75fa81213192142b07a6e4915
> Processing Pylons-1.0.1.tar.gz
> Running Pylons-1.0.1/setup.py -q bdist_egg --dist-dir
> /tmp/easy_install-7xHulp/Pylons-1.0.1/egg-dist-tmp-nBfo7J
> warning: no previously-included files matching '*' found under directory
> 'tests/test_units/session'
> warning: no previously-included files matching '.DS_Store' found anywhere
> in distribution
> warning: no previously-included files matching '*.hgignore' found anywhere
> in distribution
> warning: no previously-included files matching '*.hgtags' found anywhere
> in distribution
> Adding Pylons 1.0.1 to easy-install.pth file
>
> Installed /root/anvil/lib/python2.7/site-packages/Pylons-1.0.1-py2.7.egg
> Reading http://www.pylonshq.com/download/1.0
>
> error: Installed distribution WebOb 1.2.3 conflicts with requirement
> WebOb==1.1.1
>
>
>
>
> ________________________________________
> De : Cory Johns [cjohns@slashdotmedia.com]
> Envoyé : mardi 16 avril 2013 16:20
>
> À : allura-users@incubator.apache.org
> Objet : Re: WebOb conflict
>
>
> Dave makes a good point.  Instead of trying to triage specific version
> conflicts, a better approach would be to create a fresh virtualenv (making
> sure not to include site packages, although that's been the default
> behavior for a while; but you might want to check your virtualenv /
> mkvirtualenv version just to be sure) and then install just the required
> libraries with:
>
>   pip install -r requirements.txt
>
> As Dave mentioned, the README file has more detailed instructions.
>
>
>
> On Mon, Apr 15, 2013 at 5:55 PM, Dave Brondsema  > wrote:
> Hey Eugène, just wondering did you install with a fresh python virtual
> environment and the requirements.txt file?  If you follow the instructions
> in
> the README to do that I don't think you'd have any version errors.
>
> On 4/15/13 2:06 PM, Eugène Adell wrote:
> >
> > Still not good, is there any way to find the root cause ? Again, thanks
> for helping
> >
> > # pip list
> > Allura (0.1dev)
> > argparse (1.2.1)
> > Babel (0.9.6)
> > Beaker (1.6.4)
> > BeautifulSoup (3.2.1)
> > beautifulsoup4 (4.1.3)
> > chardet (2.1.1)
> > crank (0.6.4)
> > Creoleparser (0.7.4)
> > datadiff (1.1.5)
> > decorator (3.4.0)
> > docutils (0.10)
> > Warning: cannot find svn location for EasyWidgets==0.2dev-20130116
> > EasyWidgets (0.2dev-20130116)
> > feedparser (5.1.3)
> > ForgeWiki (0.0dev)
> > FormEncode (1.2.6)
> > httplib2 (0.8)
> > iso8601 (0.1.4)
> > Jinja2 (2.6)
> > Mako (0.8.0)
> > Markdown (2.3.1)
> > MarkupSafe (0.15)
> > Warning: cannot find svn location for Ming==0.3.3dev-20130322
> > Ming (0.3.3dev-20130322)
> > mock (1.0.1)
> > nose (1.3.0)
> > oauth2 (1.5.211)
> > PIL (1.1.7)
> > Pygments (1.6)
> > Pylons (1.0)
> > pymongo (2.5)
> > Pypeline (0.1dev)
> > pysolr (3.0.6)
> > python-dateutil (2.1)
> > python-openid (2.2.5)
> > repoze.lru (0.6)
> > requests (1.2.0)
> > Routes (1.13)
> > simplejson (3.1.3)
> > Tempita (0.5.1)
> > textile (2.1.5)
> > TurboGears2 (2.2.2)
> > waitress (0.8.2)
> > WebError (0.10.3)
> > WebFlash (0.1a9)
> > WebHelpers (1.3)
> > WebOb (1.0.8)
> > WebTest (1.4.0)
> > wsgiref (0.1.2)
> >
> >
> > # python setup.py develop
> > running develop
> > running egg_info
> > writing paster_plugins to Allura.egg-info/paster_plugins.txt
> > writing requirements to Allura.egg-info/requires.txt
> > writing Allura.egg-info/PKG-INFO
> > writing top-level names to Allura.egg-info/top_level.txt
> > writing dependency_links to Allura.egg-info/dependency_links.txt
> > writing entry points to Allura.egg-info/entry_points.txt
> > reading manifest file 'Allura.egg-info/SOURCES.txt'
> > reading manifest template 'MANIFEST.in'
> > warning: no files found matching 'allura/public/favicon.ico'
> > writing manifest file 'Allura.egg-info/SOURCES.txt'
> > running build_ext
> > Creating /root/anvil/lib/python2.7/site-packages/Allura.egg-link (link
> to .)
> > Allura 0.1dev is already the active version in easy-install.pth
> > Installed /root/src/allura/Allura
> > Processing dependencies for Allura==0.1dev
> > error: Installed distribution WebOb 1.0.8 conflicts with requirement
> WebOb==1.1.1
> >
> >
> >
>
> > De : Cory Johns [cjohns@slashdotmedia.com cjohns@slashdotmedia.com>]
>
> > Envoyé : lundi 15 avril 2013 19:06
>
> > À : allura-users@incubator.apache.org allura-users@incubator.apache.org>
>
> > Objet : Re: WebOb conflict
> >
> >
> > It looks like the conflict is coming from your version of Pylons.  We're
> using 1.0, while you appear to have 1.0.1 installed.  That .0.1 release
> apparently updated quite a few requirements.
> >
> >
> >
>
> > On Mon, Apr 15, 2013 at 12:40 PM, Eugène Adell  > wrote:
> >
> >
> > Hello
> >
> > thanks ; after downgrading I still got a conflict error :
> >
> > # pip list
> > Allura (0.1dev)
> > argparse (1.2.1)
> > Babel (0.9.6)
> > BeautifulSoup (3.2.1)
> > beautifulsoup4 (4.1.3)
> > chardet (2.1.1)
> > crank (0.6.4)
> > Creoleparser (0.7.4)
> > datadiff (1.1.5)
> > docutils (0.10)
> > Warning: cannot find svn location for EasyWidgets==0.2dev-20130116
> > EasyWidgets (0.2dev-20130116)
> > feedparser (5.1.3)
> > ForgeWiki (0.0dev)
> > FormEncode (1.2.6)
> > httplib2 (0.8)
> > iso8601 (0.1.4)
> > Jinja2 (2.6)
> > Markdown (2.3.1)
> > Warning: cannot find svn location for Ming==0.3.3dev-20130322
> > Ming (0.3.3dev-20130322)
> > mock (1.0.1)
> > nose (1.3.0)
> > oauth2 (1.5.211)
> > PIL (1.1.7)
> > Pygments (1.6)
> > Pylons (1.0.1)
> > pymongo (2.5)
> > Pypeline (0.1dev)
> > pysolr (3.0.6)
> > python-dateutil (2.1)
> > python-openid (2.2.5)
> > requests (1.2.0)
> > textile (2.1.5)
> > TurboGears2 (2.2.2)
> > waitress (0.8.2)
> > WebError (0.10.3)
> > WebFlash (0.1a9)
> > WebHelpers (1.3)
> > WebOb (1.0.8)
> > WebTest (1.4.0)
> > wsgiref (0.1.2)
> >
> >
> > # python setup.py develop
> > running develop
> > running egg_info
> > writing paster_plugins to Allura.egg-info/paster_plugins.txt
> > writing requirements to Allura.egg-info/requires.txt
> > writing Allura.egg-info/PKG-INFO
> > writing top-level names to Allura.egg-info/top_level.txt
> > writing dependency_links to Allura.egg-info/dependency_links.txt
> > writing entry points to Allura.egg-info/entry_points.txt
> > reading manifest file 'Allura.egg-info/SOURCES.txt'
> > reading manifest template 'MANIFEST.in'
> > warning: no files found matching 'allura/public/favicon.ico'
> > writing manifest file 'Allura.egg-info/SOURCES.txt'
> > running build_ext
> > Creating /root/anvil/lib/python2.7/site-packages/Allura.egg-link (link
> to .)
> > Allura 0.1dev is already the active version in easy-install.pth
> > Installed /root/src/allura/Allura
> > Processing dependencies for Allura==0.1dev
> > error: Installed distribution WebOb 1.0.8 conflicts with requirement
> WebOb==1.1.1
> >
> >
> >
> >
> >
> >
>
> > De : Cory Johns [cjohns@slashdotmedia.com cjohns@slashdotmedia.com>]
>
> > Envoyé : lundi 15 avril 2013 18:01
>
> > À : allura-users@incubator.apache.org allura-users@incubator.apache.org>
>
> > Objet : Re: WebOb conflict
> >
> >
> >
> > Eugène,
> >
> >
> >
> > Our requirements actually list WebOb 1.0.8 (in requirements-common.txt),
> which is what we use at SourceForge and what we've tested with and can
> confirm works.  The 1.1.1 requirement appears to be coming from WebTest,
> indicating you have a higher version than the 1.4.0 specified in
> requirements-common.txt, yet not the newest version which specifies >= 1.2
> for WebOb.
> >
> >
> > If you wish to try running with WebOb 1.2.3, you could try upgrading
> your WebTest version, but since we haven't tested with those versions, I
> can't say that it will work without further error.  My recommendation would
> be to downgrade WebTest to 1.4.0 and WebOb to 1.0.8 but I don't know of any
> specific issues with the newer versions that would cause issues, so it may
> be worth a try.
> >
> >
> >
> >
> > - Cory
> >
> >
> >
>
> > On Sun, Apr 14, 2013 at 4:04 PM, Eugène Adell  > wrote:
> >
> > Hello
> >
> > when installing Allura, I get an error at this step :
> >
> >
> > $ python setup.py develop
> >
> > error: Installed distribution WebOb 1.2.3 conflicts with requirement
> WebOb==1.1.1
> >
> >
> > Do I need to force an install with WebOb 1.1.1 ?
> >
>
>
>
> --
>
> Dave Brondsema : dave@brondsema.net
>
> http://www.brondsema.net : personal
> http://www.splike.com : programming
>               <><
>

Allura Vagrant box

2013-04-19T20:57:16Z

For those interested in a pre-built, self-contained Allura development environment, we've upload
a new Vagrant box file containing a ready-to-go Allura VM built on Ubuntu 12.04. Instructions
for getting started are located here: https://sourceforge.net/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/


--
Tim Van Steenburgh

RE:WebOb conflict

2013-04-19T20:55:47Z

Hello,
still bad when trying your method. 

After mkvirtualenv it seems ok :

# pip freeze
argparse==1.2.1
wsgiref==0.1.2

After " pip install -r requirements.txt " the freeze command returns the same result as before.
But during "python setup.py develop", the problem occurs. The freeze then returns this :

# pip freeze
Warning: cannot find svn location for Ming==0.3.3dev-20130322
Warning: cannot find svn location for EasyWidgets==0.2dev-20130116
Allura==0.1dev
Babel==0.9.6
BeautifulSoup==3.2.1
Creoleparser==0.7.4
## FIXME: could not find svn URL in dependency_links for this package:
EasyWidgets==0.2dev-20130116
FormEncode==1.2.6
Jinja2==2.6
Markdown==2.3.1
## FIXME: could not find svn URL in dependency_links for this package:
Ming==0.3.3dev-20130322
PIL==1.1.7
Pygments==1.6
Pylons==1.0.1
Pypeline==0.1dev
TurboGears2==2.2.2
WebError==0.10.3
WebFlash==0.1a9
WebHelpers==1.3
WebOb==1.2.3
WebTest==2.0.5
argparse==1.2.1
chardet==2.1.1
crank==0.6.4
datadiff==1.1.5
docutils==0.10
feedparser==5.1.3
httplib2==0.8
iso8601==0.1.4
mock==1.0.1
nose==1.3.0
oauth2==1.5.211
pymongo==2.5
pysolr==3.0.6
python-dateutil==2.1
python-openid==2.2.5
requests==1.2.0
textile==2.1.5
wsgiref==0.1.2

I put the two logs coming from "pip install" and "python setup.py" here : http://95.154.250.47/alluralogs/

Thanks a lot






De : Cory Johns [cjohns@slashdotmedia.com]
Envoyé : vendredi 19 avril 2013 15:33
À : allura-users@incubator.apache.org
Objet : Re: WebOb conflict


I'm really at a loss here, as I tested the build myself on a fresh virtualenv created with:



    [cjohns allura]$ mkvirtualenv test-allura --no-site-packages
    New python executable in test-allura/bin/python27
    Also creating executable in test-allura/bin/python
    Installing setuptools............done.
    [cjohns allura]$ workon test-allura
    (test-allura)[cjohns allura]$ pip freeze
    wsgiref==0.1.2

    (test-allura)[cjohns allura]$ pip install -r requirements.txt
...
    (test-allura)[cjohns allura]$ pip freeze | egrep 'Pylons|WebOb'
    Pylons==1.0
    WebOb==1.0.8


Other than a build error on matplotlib, everything went as expected and I ended up with the
expected versions.


My advice would be to ensure that you start with a fresh virtualenv with --no-site-packages
explicitly stated, ensure it has no unexpected initial packages via pip freeze, and perform
the pip install -r requirements.txt before installing any additional libraries.



On Thu, Apr 18, 2013 at 5:49 AM, Eugène Adell  wrote:


I get the same problem on a fresh VM with a fresh virtualenv. I am following this doc :

https://sourceforge.net/p/allura/git/ci/master/tree/README.markdown

Now, the error looks like this :

...
Searching for Pylons
Reading http://pypi.python.org/simple/Pylons/
Reading http://www.pylonshq.com/
Best match: Pylons 1.0.1
Downloading http://pypi.python.org/packages/source/P/Pylons/Pylons-1.0.1.tar.gz#md5=6cb880d75fa81213192142b07a6e4915
Processing Pylons-1.0.1.tar.gz
Running Pylons-1.0.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-7xHulp/Pylons-1.0.1/egg-dist-tmp-nBfo7J
warning: no previously-included files matching '*' found under directory 'tests/test_units/session'
warning: no previously-included files matching '.DS_Store' found anywhere in distribution
warning: no previously-included files matching '*.hgignore' found anywhere in distribution
warning: no previously-included files matching '*.hgtags' found anywhere in distribution
Adding Pylons 1.0.1 to easy-install.pth file

Installed /root/anvil/lib/python2.7/site-packages/Pylons-1.0.1-py2.7.egg
Reading http://www.pylonshq.com/download/1.0

error: Installed distribution WebOb 1.2.3 conflicts with requirement WebOb==1.1.1




________________________________________
De : Cory Johns [cjohns@slashdotmedia.com]
Envoyé : mardi 16 avril 2013 16:20

À : allura-users@incubator.apache.org
Objet : Re: WebOb conflict


Dave makes a good point.  Instead of trying to triage specific version conflicts, a better
approach would be to create a fresh virtualenv (making sure not to include site packages,
although that's been the default behavior for a while; but you might want to check your virtualenv
/ mkvirtualenv version just to be sure) and then install just the required libraries with:

  pip install -r requirements.txt

As Dave mentioned, the README file has more detailed instructions.



On Mon, Apr 15, 2013 at 5:55 PM, Dave Brondsema >
wrote:
Hey Eugène, just wondering did you install with a fresh python virtual
environment and the requirements.txt file?  If you follow the instructions in
the README to do that I don't think you'd have any version errors.

On 4/15/13 2:06 PM, Eugène Adell wrote:
>
> Still not good, is there any way to find the root cause ? Again, thanks for helping
>
> # pip list
> Allura (0.1dev)
> argparse (1.2.1)
> Babel (0.9.6)
> Beaker (1.6.4)
> BeautifulSoup (3.2.1)
> beautifulsoup4 (4.1.3)
> chardet (2.1.1)
> crank (0.6.4)
> Creoleparser (0.7.4)
> datadiff (1.1.5)
> decorator (3.4.0)
> docutils (0.10)
> Warning: cannot find svn location for EasyWidgets==0.2dev-20130116
> EasyWidgets (0.2dev-20130116)
> feedparser (5.1.3)
> ForgeWiki (0.0dev)
> FormEncode (1.2.6)
> httplib2 (0.8)
> iso8601 (0.1.4)
> Jinja2 (2.6)
> Mako (0.8.0)
> Markdown (2.3.1)
> MarkupSafe (0.15)
> Warning: cannot find svn location for Ming==0.3.3dev-20130322
> Ming (0.3.3dev-20130322)
> mock (1.0.1)
> nose (1.3.0)
> oauth2 (1.5.211)
> PIL (1.1.7)
> Pygments (1.6)
> Pylons (1.0)
> pymongo (2.5)
> Pypeline (0.1dev)
> pysolr (3.0.6)
> python-dateutil (2.1)
> python-openid (2.2.5)
> repoze.lru (0.6)
> requests (1.2.0)
> Routes (1.13)
> simplejson (3.1.3)
> Tempita (0.5.1)
> textile (2.1.5)
> TurboGears2 (2.2.2)
> waitress (0.8.2)
> WebError (0.10.3)
> WebFlash (0.1a9)
> WebHelpers (1.3)
> WebOb (1.0.8)
> WebTest (1.4.0)
> wsgiref (0.1.2)
>
>
> # python setup.py develop
> running develop
> running egg_info
> writing paster_plugins to Allura.egg-info/paster_plugins.txt
> writing requirements to Allura.egg-info/requires.txt
> writing Allura.egg-info/PKG-INFO
> writing top-level names to Allura.egg-info/top_level.txt
> writing dependency_links to Allura.egg-info/dependency_links.txt
> writing entry points to Allura.egg-info/entry_points.txt
> reading manifest file 'Allura.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> warning: no files found matching 'allura/public/favicon.ico'
> writing manifest file 'Allura.egg-info/SOURCES.txt'
> running build_ext
> Creating /root/anvil/lib/python2.7/site-packages/Allura.egg-link (link to .)
> Allura 0.1dev is already the active version in easy-install.pth
> Installed /root/src/allura/Allura
> Processing dependencies for Allura==0.1dev
> error: Installed distribution WebOb 1.0.8 conflicts with requirement WebOb==1.1.1
>
>
>

> De : Cory Johns [cjohns@slashdotmedia.com]

> Envoyé : lundi 15 avril 2013 19:06

> À : allura-users@incubator.apache.org

> Objet : Re: WebOb conflict
>
>
> It looks like the conflict is coming from your version of Pylons.  We're using 1.0, while
you appear to have 1.0.1 installed.  That .0.1 release apparently updated quite a few requirements.
>
>
>

> On Mon, Apr 15, 2013 at 12:40 PM, Eugène Adell >
wrote:
>
>
> Hello
>
> thanks ; after downgrading I still got a conflict error :
>
> # pip list
> Allura (0.1dev)
> argparse (1.2.1)
> Babel (0.9.6)
> BeautifulSoup (3.2.1)
> beautifulsoup4 (4.1.3)
> chardet (2.1.1)
> crank (0.6.4)
> Creoleparser (0.7.4)
> datadiff (1.1.5)
> docutils (0.10)
> Warning: cannot find svn location for EasyWidgets==0.2dev-20130116
> EasyWidgets (0.2dev-20130116)
> feedparser (5.1.3)
> ForgeWiki (0.0dev)
> FormEncode (1.2.6)
> httplib2 (0.8)
> iso8601 (0.1.4)
> Jinja2 (2.6)
> Markdown (2.3.1)
> Warning: cannot find svn location for Ming==0.3.3dev-20130322
> Ming (0.3.3dev-20130322)
> mock (1.0.1)
> nose (1.3.0)
> oauth2 (1.5.211)
> PIL (1.1.7)
> Pygments (1.6)
> Pylons (1.0.1)
> pymongo (2.5)
> Pypeline (0.1dev)
> pysolr (3.0.6)
> python-dateutil (2.1)
> python-openid (2.2.5)
> requests (1.2.0)
> textile (2.1.5)
> TurboGears2 (2.2.2)
> waitress (0.8.2)
> WebError (0.10.3)
> WebFlash (0.1a9)
> WebHelpers (1.3)
> WebOb (1.0.8)
> WebTest (1.4.0)
> wsgiref (0.1.2)
>
>
> # python setup.py develop
> running develop
> running egg_info
> writing paster_plugins to Allura.egg-info/paster_plugins.txt
> writing requirements to Allura.egg-info/requires.txt
> writing Allura.egg-info/PKG-INFO
> writing top-level names to Allura.egg-info/top_level.txt
> writing dependency_links to Allura.egg-info/dependency_links.txt
> writing entry points to Allura.egg-info/entry_points.txt
> reading manifest file 'Allura.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> warning: no files found matching 'allura/public/favicon.ico'
> writing manifest file 'Allura.egg-info/SOURCES.txt'
> running build_ext
> Creating /root/anvil/lib/python2.7/site-packages/Allura.egg-link (link to .)
> Allura 0.1dev is already the active version in easy-install.pth
> Installed /root/src/allura/Allura
> Processing dependencies for Allura==0.1dev
> error: Installed distribution WebOb 1.0.8 conflicts with requirement WebOb==1.1.1
>
>
>
>
>
>

> De : Cory Johns [cjohns@slashdotmedia.com]

> Envoyé : lundi 15 avril 2013 18:01

> À : allura-users@incubator.apache.org

> Objet : Re: WebOb conflict
>
>
>
> Eugène,
>
>
>
> Our requirements actually list WebOb 1.0.8 (in requirements-common.txt), which is what
we use at SourceForge and what we've tested with and can confirm works.  The 1.1.1 requirement
appears to be coming from WebTest, indicating you have a higher version than the 1.4.0 specified
in requirements-common.txt, yet not the newest version which specifies >= 1.2 for WebOb.
>
>
> If you wish to try running with WebOb 1.2.3, you could try upgrading your WebTest version,
but since we haven't tested with those versions, I can't say that it will work without further
error.  My recommendation would be to downgrade WebTest to 1.4.0 and WebOb to 1.0.8 but I
don't know of any specific issues with the newer versions that would cause issues, so it may
be worth a try.
>
>
>
>
> - Cory
>
>
>

> On Sun, Apr 14, 2013 at 4:04 PM, Eugène Adell >
wrote:
>
> Hello
>
> when installing Allura, I get an error at this step :
>
>
> $ python setup.py develop
>
> error: Installed distribution WebOb 1.2.3 conflicts with requirement WebOb==1.1.1
>
>
> Do I need to force an install with WebOb 1.1.1 ?
>



--

Dave Brondsema : dave@brondsema.net

http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Re: WebOb conflict

2013-04-19T13:33:40Z

I'm really at a loss here, as I tested the build myself on a fresh
virtualenv created with:

    [cjohns allura]$ mkvirtualenv test-allura --no-site-packages
    New python executable in test-allura/bin/python27
    Also creating executable in test-allura/bin/python
    Installing setuptools............done.
    [cjohns allura]$ workon test-allura
    (test-allura)[cjohns allura]$ pip freeze
    wsgiref==0.1.2
    (test-allura)[cjohns allura]$ pip install -r requirements.txt
...
    (test-allura)[cjohns allura]$ pip freeze | egrep 'Pylons|WebOb'
    Pylons==1.0
    WebOb==1.0.8

Other than a build error on matplotlib, everything went as expected and I
ended up with the expected versions.

My advice would be to ensure that you start with a fresh virtualenv with
--no-site-packages explicitly stated, ensure it has no unexpected initial
packages via pip freeze, and perform the pip install -r requirements.txt
before installing any additional libraries.


On Thu, Apr 18, 2013 at 5:49 AM, Eugène Adell  wrote:

>
> I get the same problem on a fresh VM with a fresh virtualenv. I am
> following this doc :
>
> https://sourceforge.net/p/allura/git/ci/master/tree/README.markdown
>
> Now, the error looks like this :
>
> ...
> Searching for Pylons
> Reading http://pypi.python.org/simple/Pylons/
> Reading http://www.pylonshq.com/
> Best match: Pylons 1.0.1
> Downloading
> http://pypi.python.org/packages/source/P/Pylons/Pylons-1.0.1.tar.gz#md5=6cb880d75fa81213192142b07a6e4915
> Processing Pylons-1.0.1.tar.gz
> Running Pylons-1.0.1/setup.py -q bdist_egg --dist-dir
> /tmp/easy_install-7xHulp/Pylons-1.0.1/egg-dist-tmp-nBfo7J
> warning: no previously-included files matching '*' found under directory
> 'tests/test_units/session'
> warning: no previously-included files matching '.DS_Store' found anywhere
> in distribution
> warning: no previously-included files matching '*.hgignore' found anywhere
> in distribution
> warning: no previously-included files matching '*.hgtags' found anywhere
> in distribution
> Adding Pylons 1.0.1 to easy-install.pth file
>
> Installed /root/anvil/lib/python2.7/site-packages/Pylons-1.0.1-py2.7.egg
> Reading http://www.pylonshq.com/download/1.0
> error: Installed distribution WebOb 1.2.3 conflicts with requirement
> WebOb==1.1.1
>
>
>
> ________________________________________
> De : Cory Johns [cjohns@slashdotmedia.com]
> Envoyé : mardi 16 avril 2013 16:20
> À : allura-users@incubator.apache.org
> Objet : Re: WebOb conflict
>
> Dave makes a good point.  Instead of trying to triage specific version
> conflicts, a better approach would be to create a fresh virtualenv (making
> sure not to include site packages, although that's been the default
> behavior for a while; but you might want to check your virtualenv /
> mkvirtualenv version just to be sure) and then install just the required
> libraries with:
>
>   pip install -r requirements.txt
>
> As Dave mentioned, the README file has more detailed instructions.
>
>
> On Mon, Apr 15, 2013 at 5:55 PM, Dave Brondsema  > wrote:
> Hey Eugène, just wondering did you install with a fresh python virtual
> environment and the requirements.txt file?  If you follow the instructions
> in
> the README to do that I don't think you'd have any version errors.
>
> On 4/15/13 2:06 PM, Eugène Adell wrote:
> >
> > Still not good, is there any way to find the root cause ? Again, thanks
> for helping
> >
> > # pip list
> > Allura (0.1dev)
> > argparse (1.2.1)
> > Babel (0.9.6)
> > Beaker (1.6.4)
> > BeautifulSoup (3.2.1)
> > beautifulsoup4 (4.1.3)
> > chardet (2.1.1)
> > crank (0.6.4)
> > Creoleparser (0.7.4)
> > datadiff (1.1.5)
> > decorator (3.4.0)
> > docutils (0.10)
> > Warning: cannot find svn location for EasyWidgets==0.2dev-20130116
> > EasyWidgets (0.2dev-20130116)
> > feedparser (5.1.3)
> > ForgeWiki (0.0dev)
> > FormEncode (1.2.6)
> > httplib2 (0.8)
> > iso8601 (0.1.4)
> > Jinja2 (2.6)
> > Mako (0.8.0)
> > Markdown (2.3.1)
> > MarkupSafe (0.15)
> > Warning: cannot find svn location for Ming==0.3.3dev-20130322
> > Ming (0.3.3dev-20130322)
> > mock (1.0.1)
> > nose (1.3.0)
> > oauth2 (1.5.211)
> > PIL (1.1.7)
> > Pygments (1.6)
> > Pylons (1.0)
> > pymongo (2.5)
> > Pypeline (0.1dev)
> > pysolr (3.0.6)
> > python-dateutil (2.1)
> > python-openid (2.2.5)
> > repoze.lru (0.6)
> > requests (1.2.0)
> > Routes (1.13)
> > simplejson (3.1.3)
> > Tempita (0.5.1)
> > textile (2.1.5)
> > TurboGears2 (2.2.2)
> > waitress (0.8.2)
> > WebError (0.10.3)
> > WebFlash (0.1a9)
> > WebHelpers (1.3)
> > WebOb (1.0.8)
> > WebTest (1.4.0)
> > wsgiref (0.1.2)
> >
> >
> > # python setup.py develop
> > running develop
> > running egg_info
> > writing paster_plugins to Allura.egg-info/paster_plugins.txt
> > writing requirements to Allura.egg-info/requires.txt
> > writing Allura.egg-info/PKG-INFO
> > writing top-level names to Allura.egg-info/top_level.txt
> > writing dependency_links to Allura.egg-info/dependency_links.txt
> > writing entry points to Allura.egg-info/entry_points.txt
> > reading manifest file 'Allura.egg-info/SOURCES.txt'
> > reading manifest template 'MANIFEST.in'
> > warning: no files found matching 'allura/public/favicon.ico'
> > writing manifest file 'Allura.egg-info/SOURCES.txt'
> > running build_ext
> > Creating /root/anvil/lib/python2.7/site-packages/Allura.egg-link (link
> to .)
> > Allura 0.1dev is already the active version in easy-install.pth
> > Installed /root/src/allura/Allura
> > Processing dependencies for Allura==0.1dev
> > error: Installed distribution WebOb 1.0.8 conflicts with requirement
> WebOb==1.1.1
> >
> >
> >
> > De : Cory Johns [cjohns@slashdotmedia.com cjohns@slashdotmedia.com>]
> > Envoyé : lundi 15 avril 2013 19:06
> > À : allura-users@incubator.apache.org allura-users@incubator.apache.org>
> > Objet : Re: WebOb conflict
> >
> >
> > It looks like the conflict is coming from your version of Pylons.  We're
> using 1.0, while you appear to have 1.0.1 installed.  That .0.1 release
> apparently updated quite a few requirements.
> >
> >
> >
> > On Mon, Apr 15, 2013 at 12:40 PM, Eugène Adell  > wrote:
> >
> >
> > Hello
> >
> > thanks ; after downgrading I still got a conflict error :
> >
> > # pip list
> > Allura (0.1dev)
> > argparse (1.2.1)
> > Babel (0.9.6)
> > BeautifulSoup (3.2.1)
> > beautifulsoup4 (4.1.3)
> > chardet (2.1.1)
> > crank (0.6.4)
> > Creoleparser (0.7.4)
> > datadiff (1.1.5)
> > docutils (0.10)
> > Warning: cannot find svn location for EasyWidgets==0.2dev-20130116
> > EasyWidgets (0.2dev-20130116)
> > feedparser (5.1.3)
> > ForgeWiki (0.0dev)
> > FormEncode (1.2.6)
> > httplib2 (0.8)
> > iso8601 (0.1.4)
> > Jinja2 (2.6)
> > Markdown (2.3.1)
> > Warning: cannot find svn location for Ming==0.3.3dev-20130322
> > Ming (0.3.3dev-20130322)
> > mock (1.0.1)
> > nose (1.3.0)
> > oauth2 (1.5.211)
> > PIL (1.1.7)
> > Pygments (1.6)
> > Pylons (1.0.1)
> > pymongo (2.5)
> > Pypeline (0.1dev)
> > pysolr (3.0.6)
> > python-dateutil (2.1)
> > python-openid (2.2.5)
> > requests (1.2.0)
> > textile (2.1.5)
> > TurboGears2 (2.2.2)
> > waitress (0.8.2)
> > WebError (0.10.3)
> > WebFlash (0.1a9)
> > WebHelpers (1.3)
> > WebOb (1.0.8)
> > WebTest (1.4.0)
> > wsgiref (0.1.2)
> >
> >
> > # python setup.py develop
> > running develop
> > running egg_info
> > writing paster_plugins to Allura.egg-info/paster_plugins.txt
> > writing requirements to Allura.egg-info/requires.txt
> > writing Allura.egg-info/PKG-INFO
> > writing top-level names to Allura.egg-info/top_level.txt
> > writing dependency_links to Allura.egg-info/dependency_links.txt
> > writing entry points to Allura.egg-info/entry_points.txt
> > reading manifest file 'Allura.egg-info/SOURCES.txt'
> > reading manifest template 'MANIFEST.in'
> > warning: no files found matching 'allura/public/favicon.ico'
> > writing manifest file 'Allura.egg-info/SOURCES.txt'
> > running build_ext
> > Creating /root/anvil/lib/python2.7/site-packages/Allura.egg-link (link
> to .)
> > Allura 0.1dev is already the active version in easy-install.pth
> > Installed /root/src/allura/Allura
> > Processing dependencies for Allura==0.1dev
> > error: Installed distribution WebOb 1.0.8 conflicts with requirement
> WebOb==1.1.1
> >
> >
> >
> >
> >
> >
> > De : Cory Johns [cjohns@slashdotmedia.com cjohns@slashdotmedia.com>]
> > Envoyé : lundi 15 avril 2013 18:01
> > À : allura-users@incubator.apache.org allura-users@incubator.apache.org>
> > Objet : Re: WebOb conflict
> >
> >
> >
> > Eugène,
> >
> >
> >
> > Our requirements actually list WebOb 1.0.8 (in requirements-common.txt),
> which is what we use at SourceForge and what we've tested with and can
> confirm works.  The 1.1.1 requirement appears to be coming from WebTest,
> indicating you have a higher version than the 1.4.0 specified in
> requirements-common.txt, yet not the newest version which specifies >= 1.2
> for WebOb.
> >
> >
> > If you wish to try running with WebOb 1.2.3, you could try upgrading
> your WebTest version, but since we haven't tested with those versions, I
> can't say that it will work without further error.  My recommendation would
> be to downgrade WebTest to 1.4.0 and WebOb to 1.0.8 but I don't know of any
> specific issues with the newer versions that would cause issues, so it may
> be worth a try.
> >
> >
> >
> >
> > - Cory
> >
> >
> >
> > On Sun, Apr 14, 2013 at 4:04 PM, Eugène Adell  > wrote:
> >
> > Hello
> >
> > when installing Allura, I get an error at this step :
> >
> >
> > $ python setup.py develop
> >
> > error: Installed distribution WebOb 1.2.3 conflicts with requirement
> WebOb==1.1.1
> >
> >
> > Do I need to force an install with WebOb 1.1.1 ?
> >
>
>
>
> --
> Dave Brondsema : dave@brondsema.net
> http://www.brondsema.net : personal
> http://www.splike.com : programming
>               <><
>
>
>

Re: Error in installing allura platform

2013-04-18T13:52:10Z

On Thursday, April 18, 2013 at 8:46 AM, Thejaswani.G@cognizant.com wrote:
> Hi
> Now i am able to create a user in allura platform.
> Error in creating home directory  for the user.
> I didnt see physical folder structure for the project created in /var/scm/git
> Only the default folder for projects test "p/test" is available in the /scm/git and /scm/svn

You won't see new folders being created here unless you install a new SVN, Git, or Hg tool
in one of your projects. 
> Another attribute error and userstat tool is not available
Please post the full traceback from the log. 
> Please help to fix
> 
> thanks
> thejaswani
> From: G, Thejaswani (Cognizant)
> Sent: Wednesday, April 17, 2013 6:54 PM
> To: allura-users@incubator.apache.org (mailto:allura-users@incubator.apache.org)
> Subject: RE: Error in installing allura platform
> 
> Hi,
> PFA!
> 
> From: G, Thejaswani (Cognizant)
> Sent: Wednesday, April 17, 2013 11:29 AM
> To: allura-users@incubator.apache.org (mailto:allura-users@incubator.apache.org)
> Subject: Error in installing allura platform
> 
> Hi
> when i change the auth_method to ldap in .ini file, I am unable to register a user and
unable to login with ldap admin username saying internal server error
> 
> I installed the libldap2-dev ,python-ldap in chroot environment as suggested in this
thread https://sourceforge.net/p/allura/tickets/_discuss/thread/751106bf/post .But still getting
the same error
> here i attach the logs.Please and check and let me know how to fix it.
> 
> Thanks
> thejaswani
> This e-mail and any files transmitted with it are for the sole use of the intended recipient(s)
and may contain confidential and privileged information. If you are not the intended recipient(s),
please reply to the sender and destroy all copies of the original message. Any unauthorized
review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or
any action taken in reliance on the contents of this e-mail is strictly prohibited and may
be unlawful. 
> 
> 
> Attachments: 
> - tg.log
> 
> - taskd.log
>

RE: Error in installing allura platform

2013-04-18T12:46:26Z

An error occured while fetching this message, sorry !

RE:WebOb conflict

2013-04-18T09:49:56Z


I get the same problem on a fresh VM with a fresh virtualenv. I am following this doc :

https://sourceforge.net/p/allura/git/ci/master/tree/README.markdown

Now, the error looks like this :

...
Searching for Pylons
Reading http://pypi.python.org/simple/Pylons/
Reading http://www.pylonshq.com/
Best match: Pylons 1.0.1
Downloading http://pypi.python.org/packages/source/P/Pylons/Pylons-1.0.1.tar.gz#md5=6cb880d75fa81213192142b07a6e4915
Processing Pylons-1.0.1.tar.gz
Running Pylons-1.0.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-7xHulp/Pylons-1.0.1/egg-dist-tmp-nBfo7J
warning: no previously-included files matching '*' found under directory 'tests/test_units/session'
warning: no previously-included files matching '.DS_Store' found anywhere in distribution
warning: no previously-included files matching '*.hgignore' found anywhere in distribution
warning: no previously-included files matching '*.hgtags' found anywhere in distribution
Adding Pylons 1.0.1 to easy-install.pth file

Installed /root/anvil/lib/python2.7/site-packages/Pylons-1.0.1-py2.7.egg
Reading http://www.pylonshq.com/download/1.0
error: Installed distribution WebOb 1.2.3 conflicts with requirement WebOb==1.1.1



________________________________________
De : Cory Johns [cjohns@slashdotmedia.com]
Envoyé : mardi 16 avril 2013 16:20
À : allura-users@incubator.apache.org
Objet : Re: WebOb conflict

Dave makes a good point.  Instead of trying to triage specific version conflicts, a better
approach would be to create a fresh virtualenv (making sure not to include site packages,
although that's been the default behavior for a while; but you might want to check your virtualenv
/ mkvirtualenv version just to be sure) and then install just the required libraries with:

  pip install -r requirements.txt

As Dave mentioned, the README file has more detailed instructions.


On Mon, Apr 15, 2013 at 5:55 PM, Dave Brondsema >
wrote:
Hey Eugène, just wondering did you install with a fresh python virtual
environment and the requirements.txt file?  If you follow the instructions in
the README to do that I don't think you'd have any version errors.

On 4/15/13 2:06 PM, Eugène Adell wrote:
>
> Still not good, is there any way to find the root cause ? Again, thanks for helping
>
> # pip list
> Allura (0.1dev)
> argparse (1.2.1)
> Babel (0.9.6)
> Beaker (1.6.4)
> BeautifulSoup (3.2.1)
> beautifulsoup4 (4.1.3)
> chardet (2.1.1)
> crank (0.6.4)
> Creoleparser (0.7.4)
> datadiff (1.1.5)
> decorator (3.4.0)
> docutils (0.10)
> Warning: cannot find svn location for EasyWidgets==0.2dev-20130116
> EasyWidgets (0.2dev-20130116)
> feedparser (5.1.3)
> ForgeWiki (0.0dev)
> FormEncode (1.2.6)
> httplib2 (0.8)
> iso8601 (0.1.4)
> Jinja2 (2.6)
> Mako (0.8.0)
> Markdown (2.3.1)
> MarkupSafe (0.15)
> Warning: cannot find svn location for Ming==0.3.3dev-20130322
> Ming (0.3.3dev-20130322)
> mock (1.0.1)
> nose (1.3.0)
> oauth2 (1.5.211)
> PIL (1.1.7)
> Pygments (1.6)
> Pylons (1.0)
> pymongo (2.5)
> Pypeline (0.1dev)
> pysolr (3.0.6)
> python-dateutil (2.1)
> python-openid (2.2.5)
> repoze.lru (0.6)
> requests (1.2.0)
> Routes (1.13)
> simplejson (3.1.3)
> Tempita (0.5.1)
> textile (2.1.5)
> TurboGears2 (2.2.2)
> waitress (0.8.2)
> WebError (0.10.3)
> WebFlash (0.1a9)
> WebHelpers (1.3)
> WebOb (1.0.8)
> WebTest (1.4.0)
> wsgiref (0.1.2)
>
>
> # python setup.py develop
> running develop
> running egg_info
> writing paster_plugins to Allura.egg-info/paster_plugins.txt
> writing requirements to Allura.egg-info/requires.txt
> writing Allura.egg-info/PKG-INFO
> writing top-level names to Allura.egg-info/top_level.txt
> writing dependency_links to Allura.egg-info/dependency_links.txt
> writing entry points to Allura.egg-info/entry_points.txt
> reading manifest file 'Allura.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> warning: no files found matching 'allura/public/favicon.ico'
> writing manifest file 'Allura.egg-info/SOURCES.txt'
> running build_ext
> Creating /root/anvil/lib/python2.7/site-packages/Allura.egg-link (link to .)
> Allura 0.1dev is already the active version in easy-install.pth
> Installed /root/src/allura/Allura
> Processing dependencies for Allura==0.1dev
> error: Installed distribution WebOb 1.0.8 conflicts with requirement WebOb==1.1.1
>
>
>
> De : Cory Johns [cjohns@slashdotmedia.com]
> Envoyé : lundi 15 avril 2013 19:06
> À : allura-users@incubator.apache.org
> Objet : Re: WebOb conflict
>
>
> It looks like the conflict is coming from your version of Pylons.  We're using 1.0, while
you appear to have 1.0.1 installed.  That .0.1 release apparently updated quite a few requirements.
>
>
>
> On Mon, Apr 15, 2013 at 12:40 PM, Eugène Adell >
wrote:
>
>
> Hello
>
> thanks ; after downgrading I still got a conflict error :
>
> # pip list
> Allura (0.1dev)
> argparse (1.2.1)
> Babel (0.9.6)
> BeautifulSoup (3.2.1)
> beautifulsoup4 (4.1.3)
> chardet (2.1.1)
> crank (0.6.4)
> Creoleparser (0.7.4)
> datadiff (1.1.5)
> docutils (0.10)
> Warning: cannot find svn location for EasyWidgets==0.2dev-20130116
> EasyWidgets (0.2dev-20130116)
> feedparser (5.1.3)
> ForgeWiki (0.0dev)
> FormEncode (1.2.6)
> httplib2 (0.8)
> iso8601 (0.1.4)
> Jinja2 (2.6)
> Markdown (2.3.1)
> Warning: cannot find svn location for Ming==0.3.3dev-20130322
> Ming (0.3.3dev-20130322)
> mock (1.0.1)
> nose (1.3.0)
> oauth2 (1.5.211)
> PIL (1.1.7)
> Pygments (1.6)
> Pylons (1.0.1)
> pymongo (2.5)
> Pypeline (0.1dev)
> pysolr (3.0.6)
> python-dateutil (2.1)
> python-openid (2.2.5)
> requests (1.2.0)
> textile (2.1.5)
> TurboGears2 (2.2.2)
> waitress (0.8.2)
> WebError (0.10.3)
> WebFlash (0.1a9)
> WebHelpers (1.3)
> WebOb (1.0.8)
> WebTest (1.4.0)
> wsgiref (0.1.2)
>
>
> # python setup.py develop
> running develop
> running egg_info
> writing paster_plugins to Allura.egg-info/paster_plugins.txt
> writing requirements to Allura.egg-info/requires.txt
> writing Allura.egg-info/PKG-INFO
> writing top-level names to Allura.egg-info/top_level.txt
> writing dependency_links to Allura.egg-info/dependency_links.txt
> writing entry points to Allura.egg-info/entry_points.txt
> reading manifest file 'Allura.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> warning: no files found matching 'allura/public/favicon.ico'
> writing manifest file 'Allura.egg-info/SOURCES.txt'
> running build_ext
> Creating /root/anvil/lib/python2.7/site-packages/Allura.egg-link (link to .)
> Allura 0.1dev is already the active version in easy-install.pth
> Installed /root/src/allura/Allura
> Processing dependencies for Allura==0.1dev
> error: Installed distribution WebOb 1.0.8 conflicts with requirement WebOb==1.1.1
>
>
>
>
>
>
> De : Cory Johns [cjohns@slashdotmedia.com]
> Envoyé : lundi 15 avril 2013 18:01
> À : allura-users@incubator.apache.org
> Objet : Re: WebOb conflict
>
>
>
> Eugène,
>
>
>
> Our requirements actually list WebOb 1.0.8 (in requirements-common.txt), which is what
we use at SourceForge and what we've tested with and can confirm works.  The 1.1.1 requirement
appears to be coming from WebTest, indicating you have a higher version than the 1.4.0 specified
in requirements-common.txt, yet not the newest version which specifies >= 1.2 for WebOb.
>
>
> If you wish to try running with WebOb 1.2.3, you could try upgrading your WebTest version,
but since we haven't tested with those versions, I can't say that it will work without further
error.  My recommendation would be to downgrade WebTest to 1.4.0 and WebOb to 1.0.8 but I
don't know of any specific issues with the newer versions that would cause issues, so it may
be worth a try.
>
>
>
>
> - Cory
>
>
>
> On Sun, Apr 14, 2013 at 4:04 PM, Eugène Adell >
wrote:
>
> Hello
>
> when installing Allura, I get an error at this step :
>
>
> $ python setup.py develop
>
> error: Installed distribution WebOb 1.2.3 conflicts with requirement WebOb==1.1.1
>
>
> Do I need to force an install with WebOb 1.1.1 ?
>



--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Re: Subversion server setting on apache & mod_dav_svn

2013-04-18T03:08:24Z

dave, many thanks.
SVNParentPathRecursive is best solution.

We have old  "forge" platform. want to use allura to replace.
allura install maybe not difficult. but, a production environment, maybe
need svn; git or hg scm server. and more environment setting.

Thanks for your help.

wangaguo


2013/4/18 Dave Brondsema 

> On SourceForge our SVN servers run with a patch to SVNParentPath to support
> recursion.  http://subversion.tigris.org/issues/show_bug.cgi?id=3588 has
> some
> patches for it, but they are old.  I'm seeing if I can get the latest
> version of
> our patch public that works with a recent release of Subversion.
>
> On 4/17/13 5:02 AM, 王再國 wrote:
> > I think so. "inotifywait, or a simple cron job would probably be easier."
> >
> > project has subproject. recursively sub project.
> > allura neighborhood can invite project to other neighborhood.
> > This will change all relation path.
> > I don't know sourceforge how to setting svn server.
> > but I know have many event handler or script.
> >
> > now, I use apache macro module.
> >
> > 
> >  
> >    DAV svn
> >    SVNParentPath /scm/svn$nh_project
> >      ...
> >  
> > 
> >
> > NameVirtualHost 192.168.22.121
> > >
> >  Use SVNSetup /p/allura
> >  Use SVNSetup /p/test
> >  Use SVNSetup /p/test/sub1
> > 
> >
> > and I need to sync the conf with allura neighborhood; project;
> subproject.
> > sourceforge how to setting svn server???
> >
> > wangaguo
> >
> >
> > 2013/4/17 王再國 >
> >
> >     if project & repos below.
> >     /p/allura/svn
> >     /p/testproject01/svn
> >     /p/testproject02/svn
> >
> >     and /tmp/svn/ is SVNParentPath
> >
> >     maybe symlink below.
> >     /tmp/svn/allura-svn
> >     /tmp/svn/testproject01-svn
> >     /tmp/svn/testproject02-svn
> >
> >     but the web url is not below.
> >     http://svn.allura.org/p/allura/svn
> >     http://svn.allura.org/p/testproject01/svn
> >
> >     web url is below.
> >     http://svn.allura.org/allura-svn
> >     http://svn.allura.org/testproject01-svn
> >
> >     wangaguo
> >
> >
> >
> >     2013/4/16 Tim Van Steenburgh  >     >
> >
> >         One idea would be to use bash + inotifywait to watch /tmp/svn,
> and
> >         rename + symlink new repo directories to another location, and
> use that
> >         location as the SVNParentPath. I'm not totally sure it would
> work, but
> >         maybe worth a try?
> >
> >         Tim
> >
> >         On Tuesday, April 16, 2013 at 2:58 AM, 王再國 wrote:
> >
> >>         If all repos in the /tmp/svn then set SVNParentPath on /tmp/svn
> is ok.
> >>         But allura has three level neighborhood; project; repos.
> >>         SVNParentPath only support one level parent path. no recursive.
> >>         e.g. /p/allura/svn1, In apache conf, I only can seting to the
> allura
> >>         project.
> >>
> >>         wangaguo
> >>
> >>
> >>         2013/4/16 王再國 >
> >>
> >>             Hi.
> >>             svn can set SVNParentPath for multiple repository.
> >>             But allura scm direcotry stucture is
> neighborhood/project/repos.
> >>             How to setting up svn apache & mod_dav_svn for allura svn
> folder.
> >>
> >>             wangaguo
> >>
> >>
> >>
> >
> >
> >
>
>
>
> --
> Dave Brondsema : dave@brondsema.net
> http://www.brondsema.net : personal
> http://www.splike.com : programming
>               <><
>

Re: Subversion server setting on apache & mod_dav_svn

2013-04-17T20:41:54Z

On SourceForge our SVN servers run with a patch to SVNParentPath to support
recursion.  http://subversion.tigris.org/issues/show_bug.cgi?id=3588 has some
patches for it, but they are old.  I'm seeing if I can get the latest version of
our patch public that works with a recent release of Subversion.

On 4/17/13 5:02 AM, 王再國 wrote:
> I think so. "inotifywait, or a simple cron job would probably be easier."
> 
> project has subproject. recursively sub project.
> allura neighborhood can invite project to other neighborhood.
> This will change all relation path.
> I don't know sourceforge how to setting svn server.
> but I know have many event handler or script.
> 
> now, I use apache macro module.
> 
> 
>  
>    DAV svn
>    SVNParentPath /scm/svn$nh_project
>      ...
>  
> 
> 
> NameVirtualHost 192.168.22.121
> >
>  Use SVNSetup /p/allura
>  Use SVNSetup /p/test
>  Use SVNSetup /p/test/sub1
> 
> 
> and I need to sync the conf with allura neighborhood; project; subproject.
> sourceforge how to setting svn server???
> 
> wangaguo
> 
> 
> 2013/4/17 王再國 >
> 
>     if project & repos below.
>     /p/allura/svn
>     /p/testproject01/svn
>     /p/testproject02/svn
> 
>     and /tmp/svn/ is SVNParentPath
> 
>     maybe symlink below.
>     /tmp/svn/allura-svn
>     /tmp/svn/testproject01-svn
>     /tmp/svn/testproject02-svn
> 
>     but the web url is not below.
>     http://svn.allura.org/p/allura/svn
>     http://svn.allura.org/p/testproject01/svn
> 
>     web url is below.
>     http://svn.allura.org/allura-svn
>     http://svn.allura.org/testproject01-svn
> 
>     wangaguo
> 
> 
> 
>     2013/4/16 Tim Van Steenburgh      >
> 
>         One idea would be to use bash + inotifywait to watch /tmp/svn, and
>         rename + symlink new repo directories to another location, and use that
>         location as the SVNParentPath. I'm not totally sure it would work, but
>         maybe worth a try?
> 
>         Tim
> 
>         On Tuesday, April 16, 2013 at 2:58 AM, 王再國 wrote:
> 
>>         If all repos in the /tmp/svn then set SVNParentPath on /tmp/svn is ok.
>>         But allura has three level neighborhood; project; repos.
>>         SVNParentPath only support one level parent path. no recursive.
>>         e.g. /p/allura/svn1, In apache conf, I only can seting to the allura
>>         project.
>>
>>         wangaguo
>>
>>
>>         2013/4/16 王再國 >
>>
>>             Hi.
>>             svn can set SVNParentPath for multiple repository.
>>             But allura scm direcotry stucture is neighborhood/project/repos.
>>             How to setting up svn apache & mod_dav_svn for allura svn folder.
>>
>>             wangaguo
>>
>>
>>
> 
> 
> 



-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Re: Error in installing allura platform

2013-04-17T14:10:59Z

It looks like the LdapAuthenticationProvider in allura/lib/plugin.py is missing a `user_project_shortname()`
and `user_registration_date()` method. For a quick fix you could try copying the ones from
the LocalAuthenticationProvider class above it in the same file. I'm not positive that will
fix all the problems but it'd be a good place to start.

Tim

On Wednesday, April 17, 2013 at 1:59 AM, Thejaswani.G@cognizant.com (mailto:Thejaswani.G@cognizant.com)
wrote:

> Hi
> when i change the auth_method to ldap in .ini file, I am unable to register a user and
unable to login with ldap admin username saying internal server error
> 
> I installed the libldap2-dev ,python-ldap in chroot environment as suggested in this
thread https://sourceforge.net/p/allura/tickets/_discuss/thread/751106bf/post .But still getting
the same error
> here i attach the logs.Please and check and let me know how to fix it.
> 
> Thanks
> thejaswani
> This e-mail and any files transmitted with it are for the sole use of the intended recipient(s)
and may contain confidential and privileged information. If you are not the intended recipient(s),
please reply to the sender and destroy all copies of the original message. Any unauthorized
review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or
any action taken in reliance on the contents of this e-mail is strictly prohibited and may
be unlawful. 
> 
> 
> Attachments: 
> - taskd.log
> 
> - tg.log
> 
>

Re: Subversion server setting on apache & mod_dav_svn

2013-04-17T09:02:18Z

I think so. "inotifywait, or a simple cron job would probably be easier."

project has subproject. recursively sub project.
allura neighborhood can invite project to other neighborhood.
This will change all relation path.
I don't know sourceforge how to setting svn server.
but I know have many event handler or script.

now, I use apache macro module.


 
   DAV svn
   SVNParentPath /scm/svn$nh_project
     ...
 


NameVirtualHost 192.168.22.121

 Use SVNSetup /p/allura
 Use SVNSetup /p/test
 Use SVNSetup /p/test/sub1


and I need to sync the conf with allura neighborhood; project; subproject.
sourceforge how to setting svn server???

wangaguo


2013/4/17 王再國 

> if project & repos below.
> /p/allura/svn
> /p/testproject01/svn
> /p/testproject02/svn
>
> and /tmp/svn/ is SVNParentPath
>
> maybe symlink below.
> /tmp/svn/allura-svn
> /tmp/svn/testproject01-svn
> /tmp/svn/testproject02-svn
>
> but the web url is not below.
> http://svn.allura.org/p/allura/svn
> http://svn.allura.org/p/testproject01/svn
>
> web url is below.
> http://svn.allura.org/allura-svn
> http://svn.allura.org/testproject01-svn
>
> wangaguo
>
>
>
> 2013/4/16 Tim Van Steenburgh 
>
>> One idea would be to use bash + inotifywait to watch /tmp/svn, and rename
>> + symlink new repo directories to another location, and use that location
>> as the SVNParentPath. I'm not totally sure it would work, but maybe worth a
>> try?
>>
>> Tim
>>
>> On Tuesday, April 16, 2013 at 2:58 AM, 王再國 wrote:
>>
>> If all repos in the /tmp/svn then set SVNParentPath on /tmp/svn is ok.
>> But allura has three level neighborhood; project; repos.
>> SVNParentPath only support one level parent path. no recursive.
>> e.g. /p/allura/svn1, In apache conf, I only can seting to the allura
>> project.
>>
>> wangaguo
>>
>>
>> 2013/4/16 王再國 
>>
>> Hi.
>> svn can set SVNParentPath for multiple repository.
>> But allura scm direcotry stucture is neighborhood/project/repos.
>> How to setting up svn apache & mod_dav_svn for allura svn folder.
>>
>> wangaguo
>>
>>
>>
>>
>>
>

Re: Subversion server setting on apache & mod_dav_svn

2013-04-17T08:44:46Z

if project & repos below.
/p/allura/svn
/p/testproject01/svn
/p/testproject02/svn

and /tmp/svn/ is SVNParentPath

maybe symlink below.
/tmp/svn/allura-svn
/tmp/svn/testproject01-svn
/tmp/svn/testproject02-svn

but the web url is not below.
http://svn.allura.org/p/allura/svn
http://svn.allura.org/p/testproject01/svn

web url is below.
http://svn.allura.org/allura-svn
http://svn.allura.org/testproject01-svn

wangaguo



2013/4/16 Tim Van Steenburgh 

> One idea would be to use bash + inotifywait to watch /tmp/svn, and rename
> + symlink new repo directories to another location, and use that location
> as the SVNParentPath. I'm not totally sure it would work, but maybe worth a
> try?
>
> Tim
>
> On Tuesday, April 16, 2013 at 2:58 AM, 王再國 wrote:
>
> If all repos in the /tmp/svn then set SVNParentPath on /tmp/svn is ok.
> But allura has three level neighborhood; project; repos.
> SVNParentPath only support one level parent path. no recursive.
> e.g. /p/allura/svn1, In apache conf, I only can seting to the allura
> project.
>
> wangaguo
>
>
> 2013/4/16 王再國 
>
> Hi.
> svn can set SVNParentPath for multiple repository.
> But allura scm direcotry stucture is neighborhood/project/repos.
> How to setting up svn apache & mod_dav_svn for allura svn folder.
>
> wangaguo
>
>
>
>
>

Error in installing allura platform

2013-04-17T05:59:48Z

An error occured while fetching this message, sorry !

Re: Subversion server setting on apache & mod_dav_svn

2013-04-16T14:37:28Z

I was just about to suggest something similar to what Tim suggested, except
to say that you could use write an event handler (using the
@allura.lib.decorators.event_handler decorator) to catch when a repository
was created and create the symlink.  However, I'm not entirely sure what is
required to get the event_handler registered, and while there is a
repo_cloned and repo_refreshed event, the repo_initialized event seems to
be missing.  So, inotifywait, or a simple cron job would probably be easier.

On Tue, Apr 16, 2013 at 2:58 AM, 王再國  wrote:

> If all repos in the /tmp/svn then set SVNParentPath on /tmp/svn is ok.
> But allura has three level neighborhood; project; repos.
> SVNParentPath only support one level parent path. no recursive.
> e.g. /p/allura/svn1, In apache conf, I only can seting to the allura
> project.
>
> wangaguo
>
>
> 2013/4/16 王再國 
>
>> Hi.
>> svn can set SVNParentPath for multiple repository.
>> But allura scm direcotry stucture is neighborhood/project/repos.
>> How to setting up svn apache & mod_dav_svn for allura svn folder.
>>
>> wangaguo
>>
>>
>>
>

Re: Subversion server setting on apache & mod_dav_svn

2013-04-16T14:29:44Z

One idea would be to use bash + inotifywait to watch /tmp/svn, and rename + symlink new repo
directories to another location, and use that location as the SVNParentPath. I'm not totally
sure it would work, but maybe worth a try?

Tim  

On Tuesday, April 16, 2013 at 2:58 AM, 王再國 wrote:

> If all repos in the /tmp/svn then set SVNParentPath on /tmp/svn is ok.
> But allura has three level neighborhood; project; repos.
> SVNParentPath only support one level parent path. no recursive.
> e.g. /p/allura/svn1, In apache conf, I only can seting to the allura project.
>  
> wangaguo
>  
>  
> 2013/4/16 王再國 
> > Hi.
> > svn can set SVNParentPath for multiple repository.
> > But allura scm direcotry stucture is neighborhood/project/repos.
> > How to setting up svn apache & mod_dav_svn for allura svn folder.
> >  
> > wangaguo
> >  
> >  
>