[sr #110994] savane.conf.php: missing $sys_vcs_dir

[Ineiev]

Update of sr#110994 (group administration):

  Status:None => Postponed  
 Assigned to:None => ineiev 

___

Follow-up Comment #1:

The list of repositories will be blank until the specified path is populated
with Git repositories; it makes little sense to point at a place that doesn't
exist.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110993] Cvs.pm: bad cvs permission setup

[Ineiev]

Update of sr#110993 (group administration):

  Status:None => Done   
 Assigned to:None => ineiev 

___

Follow-up Comment #1:

Thank you, I left the command without the -R.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110993] Cvs.pm: bad cvs permission setup

[Ineiev]

Update of sr#110993 (group administration):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110994] savane.conf.php: missing $sys_vcs_dir

[Jing Luo]

Follow-up Comment #2, sr#110994 (group administration):


[comment #1 comment #1:]
> The list of repositories will be blank until the specified path is populated
with Git repositories; it makes little sense to point at a place that doesn't
exist.

It's still blank even after the path is populated with git repos generated by
sv_groups and GitMakeArea.

Unlike cvs, bzr, or svn, in site-specific, the "Use Git" page contructs git
repo url using a variable $repo_list, which is defined in a function in
include/vcs.php. $repo_list will be empty if $sys_vcs_dir is not defined. From
what I can tell in the git log, it seems that this way of supporting multiple
git repos for one group was introduced around 2017. On other vcs, the url is
contructed using $project->getUnixName().


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #109703] package savane for debian

[Jing Luo]

Follow-up Comment #3, sr#109703 (group administration):

Is this being worked on? I'm interested in making a generic qemu image though.
A deb package would only get the php and perl scripts installed, and a lot of
things may not work. Savane also depends on  deprecated software that is no
longer available on debian bullseye or bookworm.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110994] savane.conf.php: missing $sys_vcs_dir

[Ineiev]

Follow-up Comment #3, sr#110994 (group administration):

[comment #2 comment #2:]
> It's still blank even after the path is populated with git repos generated
by sv_groups and GitMakeArea.

To be on the same page: the page works substantially when *both* the path is
populated and the variable is set.

> On other vcs, the url is contructed using $project->getUnixName().

Yes; for other VCS, the code doesn't check the presence of the repos.

Both approaches work when the tree of the repositories are in place and the
variables are set correctly; when anything is missing, it doesn't matter if
the page is empty or not. the point is, nothing should be missing.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #109703] package savane for debian

[Ineiev]

Follow-up Comment #4, sr#109703 (group administration):

[comment #3 comment #3:]
> Savane also depends on  deprecated software that is no longer available on
debian bullseye or bookworm.

Please be more specific. we are definitely much more interested in making
Savane work with current software than in running it in abstract simulated
environments.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110994] savane.conf.php: missing $sys_vcs_dir

[Jing Luo]

Follow-up Comment #4, sr#110994 (group administration):


[comment #3 comment #3:]
> [comment #2 comment #2:]
> > It's still blank even after the path is populated with git repos generated
by sv_groups and GitMakeArea.
> 
> To be on the same page: the page works substantially when *both* the path is
populated and the variable is set.

OK, let me clarify my point.

I mentioned that $sys_vcs_dir is missing in savane.conf.php.in because there
is no documentation/instruction anywhere to tell a newbie to set it up.

The purpose of savane.conf.php is to tell a user what need to be configured
for savane to work, is it not?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #109703] package savane for debian

[Jing Luo]

Follow-up Comment #5, sr#109703 (group administration):


[comment #4 comment #4:]
> [comment #3 comment #3:]
> > Savane also depends on  deprecated software that is no longer available on
debian bullseye or bookworm.
> 
> Please be more specific. we are definitely much more interested in making
Savane work with current software than in running it in abstract simulated
environments.


Debian bullseye (-> Trisquel 11) removed all python 2 packages and those who
depend on them from the repo. These are the packages that are removed:
1. Mailman 2.1 (lists.gnu), Mailman 3 uses python 3 but Savane can't work with
Mailman 3 without a lot of changes in both the frontend and the backend, and
replacing lists.gnu is in FSF sysadmin's realm
2. ViewVC 1.2.y or before, but there is a 1.3.0-dev that uses python 3

This doesn't work for me:
3. libnss-mysql, it segfaults

Partially working or needed patches:
4. hgweb's and viewvc's wsgi or fcgi scripts, they depend on python-flup. Only
cgi scripts are working
5. loggerhead's wsgi script, I had to hardcode the repo's path in the script
6. sv_membersh's way to invoke "hg serve --stdio" will be aborted because of a
safety check (?). It needs to be invoked by a wrapper script "hg-ssh" that
comes with mercurial.

Probably there's more.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #110994] savane.conf.php: missing $sys_vcs_dir

[Ineiev]

Follow-up Comment #5, sr#110994 (group administration):


[comment #4 comment #4:]
> 
> I mentioned that $sys_vcs_dir is missing in savane.conf.php.in because there
is no documentation/instruction anywhere to tell a newbie to set it up.

Correct, the documentation is missing.

> The purpose of savane.conf.php is to tell a user what need to be configured
for savane to work, is it not?

Not exactly; the purpose of savane.conf.php is to tell frontend what settings
to use.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/

[sr #109703] package savane for debian

[Ineiev]

Follow-up Comment #6, sr#109703 (group administration):

[comment #5 comment #5:]
> > > *Savane* also depends on  deprecated software that is no longer
available on debian bullseye or bookworm.

(The emphasis is mine.)

> Debian bullseye (-> Trisquel 11) removed all python 2 packages and those who
depend on them from the repo. These are the packages that are removed:
> 1. Mailman 2.1 (lists.gnu), Mailman 3 uses python 3 but Savane can't work
with Mailman 3 without a lot of changes in both the frontend and the backend,
and replacing lists.gnu is in FSF sysadmin's realm

I'm puzzled. TTBOMK, neither frontend nor any backend scripts depend on
Mailman. the only Savannah connection to Mailman I can think of is via an
unreleased script dwelling in l...@lists.gnu.org.

> 2. ViewVC 1.2.y or before, but there is a 1.3.0-dev that uses python 3

Savane doesn't depend on this.

> This doesn't work for me:
> 3. libnss-mysql, it segfaults

It does work at Savannah.

> Partially working or needed patches:
> 4. hgweb's and viewvc's wsgi or fcgi scripts, they depend on python-flup.
Only cgi scripts are working

Could you elaborate? why cgi scripts aren't sufficient?

> 5. loggerhead's wsgi script, I had to hardcode the repo's path in the
script

I don't understand what you are speaking about here.

> 6. sv_membersh's way to invoke "hg serve --stdio" will be aborted because of
a safety check (?). It needs to be invoked by a wrapper script "hg-ssh" that
comes with mercurial.

Thank you; let us fix that.

> Probably there's more.

So far I can only see one minor issue with sv_membersh.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/