Hi Simon, Iain, You seem to have a lot on your plate.
My best guess is to start all over again -- completely remove Scmbug from the repository and install it by running scmbug_install_glue first. If that doesn't work, there may still be problems related to policy consolidate_cvs_messages, and you should set it to "0" in glue.conf. On Fri, 2008-04-11 at 14:42 +0100, Simon Brooke wrote: > I'm trying to set up a system which integrates: > > CVS 1.12.13-8 (Official Debian package) > Bugzilla 3.0.2 (local install from source; reason: LDAP authentication) > Mediawiki 1.10.1 (local install from source; reason, LDAP authentication) > SCMBug 0.23.4 (debain packages from files.mkgnu.net) > Mylyn 2.3.2.v20080402-2100 (from http://www.eclipse.org/mylyn/downloads/ via > Eclipse 'Find and install') > > (Mylyn is an Eclipse/CVS integration tool) > > Everything worked until I added scmbug into the mix :-( > > However, I'm doing some things not strictly in line with the default scmbug > install, and I also had a little difficulty with the documentation. Any help > greatly appreciated! > > ==Failure when committing== > > When attempting to commit from within Eclipse, I get errors of the form: > The server reported an error while performing the "cvs commit" command. > [product-name]: cvs commit: warning: commitinfo line contains no format > strings: > [product-name]: "perl -I/var/lib/cvs/CVSROOT/lib/scmbug > /var/lib/cvs/CVSROOT/bin/scmbug_activity.pl > /var/lib/cvs/CVSROOT/etc/scmbug/glue.conf activity_commit > consolidate_cvs_messages" > [product-name]: Appending defaults (" %r/%p %s"), but please be aware that > this usage is > [product-name]: deprecated. This isn't an error. CVS 1.12.x basically says that its "acting" in CVS 1.11.x mode. That's ok. > [product-name]: cvs [commit aborted]: Message verification failed This IS a problem. I don't understand why you are getting this. Was any additional information reported ? I suspect cvs_consolidate_messages may be to blame -- set it to 0 before you install the glue. > This may relate to a problem which was reported when I ran > scmbug_install_glue: > > cvs commit: warning: Set to use deprecated info format strings. Establish > compatibility with the new info file format strings (add a temporary '1' in > all info files after each '%' which doesn't represent a literal percent) > and set UseNewInfoFmtStrings=yes in CVSROOT/config. After that, convert > individual command lines and scripts to handle the new format at your > leisure. > > I presume this relates to the files commitinfo, loginfo, editinfo, etc in > /var/lib/cvs/CVSROOT, but as so far I've managed to get by without making > changes to the Debian distributed CVS files I'd rather not hack these; and, > frankly, I have too much live data belonging to too many products in the CVS > to risk breaking things. If someone could give me a clear pointer to what > this problem is and how to fix it I'd be most grateful. Scmbug is aware of the CVS 1.12.x differences, and when scmbug_install_glue is run it will use the appropriate commitinfo, loginfo, etc. templates that contain parameters CVS 1.12.x can understand. Also, I'm not sure what you mean by: > I presume this relates to the files commitinfo, loginfo, editinfo, etc > in /var/lib/cvs/CVSROOT, but as so far I've managed to get by without > making changes to the Debian distributed CVS files I'd rather not hac You should not need to make any changes to "the Debian distributed CVS files". There's no such thing. CVS produces these files on 'cvs init'. CVS, not Debian. And the templates Scmbug provides are the exact copies of the ones CVS 1.11.x or 1.12.x provides. I hope you haven't added any new hooks to these files -- perhaps that's why you may be manually modifying these. In any case, scmbug_install_glue will preserve existing hooks -- it won't trash them away. > ==Formatting of bug tags== > > Mylyn prefers bug tags to be formatted '#bugXXXX', where XXX is the bug > number. I have a recipe for MediaWiki and for CVSWeb which accepts this > format. Therefore I have changed > > log_bugid_regex => '#bug([\d]*)', > > and > > log_body_regex => '#bug.*?:\s*(.*)' > > Are there likely to be any problems with using this bug tag format? You'll just have to play with these expressions until you get them right. Perhaps # needs to be escaped \#. These expressions are the least of your problems. > I haven't fully understood from the documentation how the glue.conf file gets > created. Initially I copied glue.conf.template to a new file glue.conf in > /etc/scmbug and edited that, but that was clearly wrong and so I've now > edited /usr/share/scmbug/glue/etc/scmbug/glue.conf.template directly, and > then rerunning scmbug_install_glue. However, I'm still not getting the right > values ending up in /var/lib/cvs/CVSROOT/etc/scmbug/glue.conf, unless I > directly cat the glue.conf.template into it after running > scmbug_install_glue, which doesn't seem to be the right thing to do. scmbug_install_glue is the proper way to install glue.conf. The reason for not "getting the right values" depends on what you "edited directly". Some glue variables are overwritten by your arguments to scmbug_install_glue. > It wasn't at all clear to me from the manual whether one ought to edit the > supplied glue.conf.template or not, and where scmbug_install_glue would read > it from. Looking at the source it appears to read /etc/scmbug/glue.conf, but > I confess I'm not confident of that. The fact that scmbug_install_glue does > not overwrite the glue.conf file in CVSROOT/etc/scmbug when it is rerun seems > to me unhelpful. Nope, the source is reading from <CVSROOT>/etc/scmbug/glue.conf. I assure you that scmbug_install_glue writes glue.conf in the appropriate location. HOWEVER, if you have already ran scmbug_install_glue (practically meaning, glue.conf already exists), scmbug_install_glue will not blindly overwrite glue.conf. It will expect you (ask you to, actually) to manually modify the temporary copy produced in /tmp/Scmbug.$$ when scmbug_install_glue is running. This is necessary because of possible differences between different versions of glue.conf. You should not edit glue.conf.template. After you install Scmbug, and the glue seems to work, THEN you can edit <CVSROOT>/etc/scmbug/glue.conf. ***NOT*** manually, but by first extracting the source of your glued repository. $ export CVSROOT=/var/lib/cvs $ cvs co . $ edit CVSROOT/etc/scmbug/glue.conf $ cvs commit CVSROOT/etc/scmbug/glue.conf *** HOWEVER *** since I'm suspecting a possible problem with policy consolidate_cvs_messages, edit glue.conf.template to set this policy to 0, and then run scmbug_install_glue for the first time.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
