Bugzilla Bug 129395

The ViewCVS project has been renamed to ViewVC and it has a number of changes
which prevent it from working with the current ViewCVS ebuilds. I sent an email
about this to Lance Albertson <ramereth@gentoo.org>, who maintains the ViewCVS
ebuilds, and he wanted me to post the information here. Here's the relevant
discussion:

Lance Albertson wrote:
> Russell Yanofsky wrote:
> > 1) With the name change, a lot of files have been renamed. For example,
> > viewcvs.cgi is now viewvc.cgi, viewcvs.conf is viewvc.conf, and so on.
> 
> Yes, this will probably cause a lot of problems. What kind of
> recommendations have you been giving to your users for this upgrade?
> I'll have to think about possible solutions to this.

We don't really have an upgrade procedure. The only thing a user needs to do is
install ViewVC to a new location (which is done by default since ViewVC
installs itself to /usr/local/viewvc-VERSION"), copy over the old config file,
and update the web server to point to the to the new .cgi scripts. 

> 2) The CGI scripts, shell scripts, and Mod_Python stubs under the "bin"
> > directory now have both "CONF_PATHNAME" and "LIBRARY_DIR" paths
> > hardcoded into them. All other hardcoded paths that were in the ViewVC
> > sources and configuration files have been removed. This looks like it
> > would affect the "files/rebuild" script.
> 
> That's probably because I skipped using your install script since it
> wasn't non-interactive. I think that was the reason at least, I don't
> quite remember. This probably means that I need to change the current
> ebuild to use the installer script so that the paths get installed
> properly. Generally webapp-config stores a copy of the webapp in
> /usr/share/webapp, then copies the relevant files to the vhost location
> of choice. I'm not sure how to deal with your method since you actually
> run an installer of sorts. Webapp-config might get fussy with that :-).
> I may need to contact the webapp-config maintainers to see what they
> think should happen.

It's perfectly ok to bypass the installer. If anything it is easier to bypass
it now that paths are only hardcoded in "bin/" scripts instead all over ViewVC.

I don't know how to integrate ViewVC better with webapp-config, though. ViewVC
is really not designed to be copied into a virtual host. The only ViewVC file a
web server should have to see is the viewvc.cgi file. For example, on my web
server I install ViewVC into "/var/www/russ/viewvc", and then have a link at
"/var/www/russ/htdocs/viewvc.py" pointing to
"/var/www/russ/viewvc/bin/cgi/viewvc.cgi"

> 3) ViewVC has an optional dependency on app-text/highlight, which can be
> > used to colorize source files instead of enscript.
> 
> Can you use both highlight and enscript, or only one or the other?

Just one or the other. I think if you try to enable both in a single
configuration, enscript takes precedence. But it's not something you should
have to worry about at install time. Enscript and highlight coexist fine
together on the same machine, and you could use enscript on one vhost and
highlight on other.

(In reply to comment #0)

webapp folks: FYI, this is one of the viewvc devs, not a random user :-)

> Lance Albertson wrote:
> > Russell Yanofsky wrote:
> > > 1) With the name change, a lot of files have been renamed. For example,
> > > viewcvs.cgi is now viewvc.cgi, viewcvs.conf is viewvc.conf, and so on.
> > 
> > Yes, this will probably cause a lot of problems. What kind of
> > recommendations have you been giving to your users for this upgrade?
> > I'll have to think about possible solutions to this.
> 
> We don't really have an upgrade procedure. The only thing a user needs to do is
> install ViewVC to a new location (which is done by default since ViewVC
> installs itself to /usr/local/viewvc-VERSION"), copy over the old config file,
> and update the web server to point to the to the new .cgi scripts. 

Ah ok, makes sense

> > 2) The CGI scripts, shell scripts, and Mod_Python stubs under the "bin"
> > > directory now have both "CONF_PATHNAME" and "LIBRARY_DIR" paths
> > > hardcoded into them. All other hardcoded paths that were in the ViewVC
> > > sources and configuration files have been removed. This looks like it
> > > would affect the "files/rebuild" script.
> > 
> > That's probably because I skipped using your install script since it
> > wasn't non-interactive. I think that was the reason at least, I don't
> > quite remember. This probably means that I need to change the current
> > ebuild to use the installer script so that the paths get installed
> > properly. Generally webapp-config stores a copy of the webapp in
> > /usr/share/webapp, then copies the relevant files to the vhost location
> > of choice. I'm not sure how to deal with your method since you actually
> > run an installer of sorts. Webapp-config might get fussy with that :-).
> > I may need to contact the webapp-config maintainers to see what they
> > think should happen.
> 
> It's perfectly ok to bypass the installer. If anything it is easier to bypass
> it now that paths are only hardcoded in "bin/" scripts instead all over ViewVC.
> 
> I don't know how to integrate ViewVC better with webapp-config, though. ViewVC
> is really not designed to be copied into a virtual host. The only ViewVC file a
> web server should have to see is the viewvc.cgi file. For example, on my web
> server I install ViewVC into "/var/www/russ/viewvc", and then have a link at
> "/var/www/russ/htdocs/viewvc.py" pointing to
> "/var/www/russ/viewvc/bin/cgi/viewvc.cgi"

That's kind of the impression I got when I was trying to fix this up before. So
what you're saying is, I could install a majority of this in a global location
say, /usr/share/viewvc-<version>, then just have webapp-config setup the cgi
files properly for each vhost? Each vhost should be able to handle each of
their configs properly in this fashion?

> > 3) ViewVC has an optional dependency on app-text/highlight, which can be
> > > used to colorize source files instead of enscript.
> > 
> > Can you use both highlight and enscript, or only one or the other?
> 
> Just one or the other. I think if you try to enable both in a single
> configuration, enscript takes precedence. But it's not something you should
> have to worry about at install time. Enscript and highlight coexist fine
> together on the same machine, and you could use enscript on one vhost and
> highlight on other.

Ok, I'll apply that to the deps so it can be either with a preference to
enscript.

Is the latest snapshot I can get off your website the best source for me to
test the upcoming changes?

Thanks for the reply and creating this bug :-)

(In reply to comment #1)

> That's kind of the impression I got when I was trying to fix this up before.
> So what you're saying is, I could install a majority of this in a global
> location say, /usr/share/viewvc-<version>, then just have webapp-config
> setup the cgi files properly for each vhost? Each vhost should be able to
> handle each of their configs properly in this fashion?

It should, and I think that is the way to go. But where would you put the
configuration file and templates in that kind of setup? That stuff really
shouldn't be going under htdocs/, especially since the configuration file can
contain database passwords and other sensitive information like the names of
forbidden CVS modules.

> Is the latest snapshot I can get off your website the best source for me to
> test the upcoming changes?

You should use the rc1 tarball instead of the nightly snapshots. The final
tarball should be exactly like rc1 except for documentation updates and
possibly some bugfixes.

Ok, I was way off in my last post. To be able to support vhosts, pretty much
all of the ViewVC files have to copied to individual vhost directories and not
stored in a global location. The scripts in the "bin" directory can't be
installed globally because they refer to specific viewvc.conf files. The .py
files in lib/ could conceivably be installed globally in the future, but not
right now because of a quirk in the configuration handling code that looks for
template files relative to the location of "lib/viewvc.py"

Also, I was wrong in assuming that webapp-config was putting the configuration
files and templates under "htdocs," so those comments don't apply. 

Anyway I was messing around with the ebuild and think I came up with something
that works with the RC1 tarball. Here's a list of changes I made:

1) Changed SRC_URI to point at tigris.org
2) Added new "highlight" USE flag that adds dependency on "app-text/highlight"
3) Replaced several mentions of ViewCVS with ViewVC and updated many changed
paths.
4) Removed "standalone" USE flag and stopped installing standalone script to
/usr/sbin directory (it's still available, see 7)
5) Removed commitid-fix.patch. It no longer applies and I think RC1 already
includes a fix for that issue.
6) Changed "doexe" to "doins" for Mod_Python files
7) Copied bin/ directory to ${MY_HOSTROOTDIR} so vhost installations can have
access to scripts like "cvsdbadmin" and "standalone.py" that make use of their
configuration files.
8) Added "python_mod_optimize" and "python_mod_cleanup" from the python eclass
to compile .py files in lib/ directory to bytecode.
9) Updated the files/reconfig script to substitute paths correctly 

Attaching new ebuild and reconfig script now...

Created an attachment (id=84343) [edit]
viewvc-1.0.0_rc1.ebuild

Created an attachment (id=84344) [edit]
files/reconfig

Is there anything in particular you guys want wrobel's or my feedback on?

ViewVC 1.0.0 was released yesterday. The ebuild I attached before should work
with it as long as the source url is changed to
http://viewvc.tigris.org/files/documents/3330/31766/viewvc-1.0.0.tar.gz

Ok, thanks for letting me know! I'll see if I can get this in portage and
change things around in the next few days. Sorry for my lag in getting this
done.

ViewVC 1.0.1 has been released on 20-Jul-2006.

http://viewvc.tigris.org/files/documents/3330/33320/viewvc-1.0.1.tar.gz

[bounce #9] 
Could someone bring viewvc-1.0.1 into portage, please?
Thanks!

I just entered an RFE for an Ikiwiki Ebuild, Bug 144453.  Though Ikiwiki
doesn't require ViewVC, hence I can't see making that bug dependent on this
one, it does gain nice functionality with ViewVC installed.  Just FYI.

is there a postinstall-new-en.txt to go with this yet at all...?

so far so good here, using a viewvc-1.0.1 ebuild (nothing bar the version
number changed and touch a postinstall-new-en.txt in there)...will update this
if i find any issues...

I'm extremely sorry that I haven't been too responsive in this bug lately. I've
had a lot of real-life stuff keeping me busy lately. If you can find another
dev to help me maintain this ebuild, that would be great! 

Gah, silly fat fingers.. sorry about that..

version bump on the ebuild filename works properly with released
viewvc-1.0.2.tar.gz downloaded to /usr/portage/distfiles

I recommend committing this ebuild to cvs with released viewvc-1.0.2:
http://viewvc.tigris.org/files/documents/3330/34450/viewvc-1.0.2.tar.gz

with Attachment #84343 [edit] (viewvc ebuild on this bug) renamed to
viewvc-1.0.2.ebuild

and file:
/usr/portage/www-apps/viewcvs/files/viewcvs-mysql-4.0.sql

copied into the files dir of the viewvc ebuild directory.

could some kindly Gentoo dev put this in portage? or at least restart this
discussion thread?

Regards,

  -Brian

(In reply to comment #16)

> could some kindly Gentoo dev put this in portage? or at least restart this
> discussion thread?

Sorry, I've been pretty busy. I'm currently working on getting this done. I'll
let you know when I get it completed.

Created an attachment (id=99899) [edit]
Update to version 1.0.3 URL and CVSNT support

I've added yet another update to the ebuild with contains the URL for version
1.0.3 and supports CVSNT. The original CVSNT support was added by David Somers
(http://www.omz13.com/, which is also the place you can get CVSNT ebuilds).

*** Bug 152611 has been marked as a duplicate of this bug. ***

Hi,

Yesterday I tested this ebuild using the 1.0.3 update.  I found the following:

1. I needed to copy postinstall-new-en.txt from the stable viewcvs ebuild into
the files directory of ViewVC ebuild for the ebuild to complete.

2. ViewVC as installed by the ebuild looks for libswigpy.so.0.  This file is
not provided by SWIG 1.3.25, which is the current stable version of SWIG in
Gentoo.  In order to use ViewVC to browse my Subversion repository I needed to
downgrade to SWIG 1.3.21 which does provide libswigpy.so.0.

Newer versions of SWIG including 1.3.25 no longer use or require files like
libswigpy.so, this thread gives some clue
http://sourceforge.net/mailarchive/message.php?msg_id=36305905.

I searched the Viewvc tigris site and found no issues or posts related to
libswigpy.so.0 problems.  Furthermore I found reference to versions of SWIG
higher than 1.3.25 in use
http://viewvc.tigris.org/servlets/ReadMsg?listName=users&msgNo=4239

According to the ViewVC documentation ViewVC requires "Subversion 1.2 or later
and its SWIG Python bindings", with the SWIG Python bindings being created when
 Subversion is built.

The version of Subversion ebuild I used was 1.2.3-r2.

May be this is an issue with the Subversion ebuild or perhaps the version of
Subversion I was using.

Regards,


Warren. 

ping.

This one seems to be somewhat neglected by Lance.  Perhaps it could be
reassigned to a dev who would test the ebuild and get it into portage?

Regards,

   - Brian

FWIW, I am using the version 1.0.3 ebuild as attached, except that I have
changed mine to dep on virtual/mysql instead of dev-db/mysql.  (I believe this
ebuild was written before virtual/mysql was in the tree.)

My installation is as follows on x86:

[I] www-apps/viewvc [1]
     Available versions:  (~)1.0.0_rc1 (~)1.0.0 (~)1.0.1 (~)1.0.3
     Installed versions:  1.0.3(01:04:28 12/09/06)(-apache apache2 -cvsgraph
-enscript -highlight mod_python mysql -vhosts)
     Homepage:            http://viewvc.org/
     Description:         ViewVC, a web interface to cvs and subversion

The attached 1.0.3 ebuild is working just fine for me.

Except for having to touch files/postinstall-new-en.txt I too confirm that the
1.0.3 ebuild installed fine.

I added viewvc-1.0.3 to the webapps overlay. Please test and let me know if
there are any issues that need to be resolved before moving it to the main
tree.

Fixed in www-apps/viewvc. Arches, please test and keyword/stable
www-apps/viewvc so we can punt www-apps/viewcvs.

normal severity

(In reply to comment #26)
> Fixed in www-apps/viewvc. Arches, please test and keyword/stable
> www-apps/viewvc so we can punt www-apps/viewcvs.

 It is far from 30 days, so why should we stable on x86?  Is it that urgent?

x86 stable.

I'm glad this finally was updated :)

~ppc keyword added.

added ~amd64

ppc stable

~sparc keyworded, will stable when the time comes.