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 attachment 84343 [details] viewvc-1.0.0_rc1.ebuild
Created attachment 84344 [details] 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 [details] (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 attachment 99899 [details] 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.
