From Hemant.Thakre at GoLive.co.in Fri Jul 8 10:11:59 2005 From: Hemant.Thakre at GoLive.co.in (Hemant Thakre) Date: Fri, 08 Jul 2005 15:41:59 +0530 Subject: [cvsspam-devel] CVSspam email body problem Message-ID: <42CE516F.4060507@GoLive.co.in> Recently, I swithed to cvsspam. I configured it correctly and it's working gr8. The problem is in email html body. The filename in email is having hyperlink to the diff. of that perticular file, but that link doesnt work. When I commit more than one file then second file's link point to first file's diff output. Can anybody suggest me how to fix it? I'm using latest CVSspam version. --Hemant From glen at delfi.ee Fri Jul 8 13:49:56 2005 From: glen at delfi.ee (Elan =?iso-8859-13?q?Ruusam=E4e?=) Date: Fri, 8 Jul 2005 16:49:56 +0300 Subject: [cvsspam-devel] encoding from header In-Reply-To: <20050220173300.GD25328@vhost.badgers-in-foil.co.uk> References: <200502152334.54960.glen@delfi.ee> <20050220173300.GD25328@vhost.badgers-in-foil.co.uk> Message-ID: <200507081649.56793.glen@delfi.ee> On Sunday 20 February 2005 19:33, David Holroyd wrote: > On Tue, Feb 15, 2005 at 11:34:54PM +0200, Elan Ruusam?e wrote: > > as from CVSROOT/users file there's possibility to have non-ascii marks > > in From line, there's the need to encode also From: header. > > The attached patch implements a slightly more sophisticated internal > representation for email addresses, and allows words in the 'personal > name' part of an address to be encoded per RFC 2047. > > I don't claim that this handles all possible configurations of an > RFC 822 address; but it does do a better job than the previous > implementation. > > > dave > Attached file: encode_email_personal_name-patch1.diff hello. i've been using this patch for a while and being very satisfied, thank you :) but today i noticed some problem, particularilly, i have patch which allows you to specify --charset argument to cvsspam [1], which will override charset sent to outgoing email. it is used because different locations in cvs have files in different encodings. but the problem is that CVSROOT/users file is in constant encoding (iso8859-1 in my case), and as a side effect the From header gets wrongly encoded. cvsspam called with --charset utf-8 parameter produces mail header: From: Elan =?utf-8?q?Ruusam=e4e?= perhaps you could look into this issue? [1] http://cvs.pld-linux.org/SOURCES/cvsspam-charset-arg.patch -- glen From skoehler at upb.de Fri Jul 8 16:16:10 2005 From: skoehler at upb.de (=?ISO-8859-1?Q?Sven_K=F6hler?=) Date: Fri, 08 Jul 2005 18:16:10 +0200 Subject: [cvsspam-devel] CVSspam email body problem In-Reply-To: <42CE516F.4060507@GoLive.co.in> References: <42CE516F.4060507@GoLive.co.in> Message-ID: <42CEA6CA.9020203@upb.de> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig89BA9DC066F5B467EF2312D5 Content-Type: multipart/mixed; boundary="------------040703070702080706040207" This is a multi-part message in MIME format. --------------040703070702080706040207 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > The filename in email is having hyperlink to the diff. of that > perticular file, but that link doesnt work. I attached the patch. --------------040703070702080706040207 Content-Type: text/plain; name="mail_threading_patch1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mail_threading_patch1.diff" Index: cvsspam.rb =================================================================== RCS file: /var/lib/cvs/cvsspam/cvsspam.rb,v retrieving revision 1.69 diff -u -r1.69 cvsspam.rb --- cvsspam.rb 13 May 2005 20:06:55 -0000 1.69 +++ cvsspam.rb 14 May 2005 10:53:33 -0000 @@ -1235,6 +1235,7 @@ $debug = false $recipients = Array.new $sendmail_prog = "/usr/sbin/sendmail" +$hostname = ENV['HOSTNAME'] || 'localhost' $no_removed_file_diff = false $no_added_file_diff = false $no_diff = false @@ -1748,7 +1749,7 @@ from = EmailAddress.new(ENV['USER'] || ENV['USERNAME'] || 'cvsspam') end unless from.address =~ /@/ - from.address = "#{from.address}@#{ENV['HOSTNAME']||'localhost'}" + from.address = "#{from.address}@#{$hostname}" end smtp = Net::SMTP.new(@smtp_host) blah("connecting to '#{@smtp_host}'") @@ -1764,6 +1765,40 @@ end end + +def make_msg_id(localpart, hostpart) + "" +end + + +# replaces control characters, and a selection of other characters that +# may not appear unquoted in an RFC822 'word', with underscores. (It +# doesn't actually zap '.' though.) +def zap_header_special_chars(text) + text.gsub(/<>()\[\]@,;:\\[\000-\037\177]/, "_") +end + + +# Mail clients will try to 'thread' together a conversation over +# several email messages by inspecting the In-Reply-To and References headers, +# which should refer to previous emails in the conversation by mentioning +# the value of the previous message's Message-Id header. This function invents +# values for these headers so that, in the special case where a *single* file +# is committed to repeatedly, the emails giving notification of these commits +# can be threaded together automatically by the mail client. +def inject_threading_headers(mail) + return unless $fileEntries.length == 1 + file = $fileEntries[0] + name = zap_header_special_chars(file.path) + unless file.fromVer == "NONE" + mail.header("References", make_msg_id("#{name}.#{file.fromVer}", $hostname)) + end + unless file.toVer == "NONE" + mail.header("Message-ID", make_msg_id("#{name}.#{file.toVer}", $hostname)) + end +end + + if $smtp_host require 'net/smtp' mailer = SMTPMailer.new($smtp_host) @@ -1775,6 +1810,7 @@ mailer.send($from_address, $recipients) do |mail| mail.header("Subject", mailSubject) + inject_threading_headers(mail) mail.header("MIME-Version", "1.0") mail.header("Content-Type", "text/html" + ($charset.nil? ? "" : "; charset=\"#{$charset}\"")) if ENV['REMOTE_HOST'] --------------040703070702080706040207-- --------------enig89BA9DC066F5B467EF2312D5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCzqbL7Ww7FjRBE4ARAtDdAJ9mCRb7t045ODIgDYYdUGX8kUcdhwCeNvUl X0Dk+Ctpz5pG9p2Dzv5p9gQ= =SVEX -----END PGP SIGNATURE----- --------------enig89BA9DC066F5B467EF2312D5-- From skoehler at upb.de Fri Jul 8 16:18:17 2005 From: skoehler at upb.de (=?ISO-8859-1?Q?Sven_K=F6hler?=) Date: Fri, 08 Jul 2005 18:18:17 +0200 Subject: [cvsspam-devel] CVSspam email body problem In-Reply-To: <42CE516F.4060507@GoLive.co.in> References: <42CE516F.4060507@GoLive.co.in> Message-ID: <42CEA749.2060400@upb.de> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE1DC734776990F3E7147674C Content-Type: multipart/mixed; boundary="------------090300050007030807040303" This is a multi-part message in MIME format. --------------090300050007030807040303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > The filename in email is having hyperlink to the diff. of that > perticular file, but that link doesnt work. > When I commit more than one file then second file's link point to first > file's diff output. > Can anybody suggest me how to fix it? Damn, my last mail had the wrong patches. Here are the right ones. --------------090300050007030807040303 Content-Type: application/x-bzip2; name="patch-0.2.11-2.patch.bz2" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="patch-0.2.11-2.patch.bz2" QlpoOTFBWSZTWYw91yoAAEPfgGowXP//92YQAAS/59+6MAElChKKZEwT0JpqPU0aZMgDNDUG 1PSZqCVNSehlNBpoD1BoAAAAA0OYACYAAmAAAAAFJiQe9jVNslgubWpC1ByiHVUxBh9LGaIs +PiOLIn9MOvTd3XkNGSigc/vLe9ZK/nXt4JYnkjyOURXC9B55xGTFBGXpBGMhwi6oi1S+CIY sITWIDBw8bF6JaUDBamcsaaY2KpszEcWOSixxmDrT7pMqMTcHoVVtegFwHkhtE7bTFyINCfj ICP4vRu0bqi4MQvZsnaTEVV6SpgsooqmP9jIN9JMRbp2VFyKQUVJ0WkZMOkRJzI1OL5a0rSY fVCK+UrEyKLKPlWITkfzZUy4Xc+Q4kNxoYIqMjRFRKemgJw5apSmSOutHmD6oXx8QauImGqc YTMOZPZ/i7kinChIRh7rlQA= --------------090300050007030807040303 Content-Type: application/x-bzip2; name="patch-0.2.11-1.patch.bz2" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="patch-0.2.11-1.patch.bz2" QlpoOTFBWSZTWQZorLwAAENfgCIwfO//0kgAnQW/5/8qMAFlttTDUyRqGJk2kBpp6gBoZGEa aGg0QSemFPU9QAAAaAAAAlNRMJqnhT9KepoNAAGgAaANQzSvuEltiVUqNt0gQBCGI7sY2UtB ND8MeyExWtqz9VWtZwWkvG64G8Hn4h5iSi8ZL69LioDkN8kSAkFtB3DeGBxQZlbBsDvPFm6D 0BwqmgZCVfBq0igL1slERLoICwGMkbKQLtuLomqDRH+Dyr0EiBqKlJVtknjnUHZQc87w5PDo CzFRRTUdVYYJtxBgRMhI797LbMSiPB5HOZHsBiZ/oPb8E73gGTUUGXLitMR8QFfoSqOScgZQ 8zVso4NuMDyji782mxG0FHJCVuKY2BEKXkKmFmQxrawU2gPMSbac0t0aSmSK2kIcaltQCCnG mUDAjPIJ3xDML5yyay+4LqCdbQmfrYxIpwTefNxuDVkSC0pNyWDz3joya95msFayZ7qgoNn/ TsMHDToBF9RGFfxdyRThQkAZorLw --------------090300050007030807040303-- --------------enigE1DC734776990F3E7147674C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCzqdJ7Ww7FjRBE4ARAoeAAKC1/cM83bwmHNzOTIyEaXd5FnruwQCeKU51 XQtVKJakHNkePTWRy2FbGEM= =OzBb -----END PGP SIGNATURE----- --------------enigE1DC734776990F3E7147674C-- From dave at badgers-in-foil.co.uk Mon Jul 11 15:47:30 2005 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Mon, 11 Jul 2005 15:47:30 +0000 Subject: [cvsspam-devel] [ANN] CVSspam 0.2.12 released Message-ID: <20050711154730.GB11804@vhost.badgers-in-foil.co.uk> CVSspam 0.2.12 is now available, http://www.badgers-in-foil.co.uk/projects/cvsspam/ [I've made a shiny new template for the project page, including an RSS feed of release announcements.] Changes since release 0.2.11: * Email addresses parsed from CVSROOT/users are now stripped of any surrounding quotes, thanks to a patch from Elan Ruusamäe. * A numbering error that caused links from the top-of-mail index to point at the file next to the one they should have pointed at was fixed; as reported by several people. * Ricardo Pardini provided a patch that handles [[Wiki Links]] in the commit log comment. * Newer versions of Ruby don't allow scripts to modify their command-line arguments, so CVSspam altered to avoid doing that. (A problem that was introduced in release 0.2.11 while trying to fix another issue; thanks to Sven Köhler for checking this). * Improve email address handling, so that we can now encode non-ASCII characters in any 'personal name' part of an address. Elan Ruusamäe pointed out the lack of encoding. * Per a suggestion by Corporate Gadfly, the presence of the -kb 'sticky option'[1] on a file now causes CVSspam to avoid producing a diff for that file; handy when diff's inbuilt binary-file detection heuristic fails. The -kb option can be specified when files are added to the repository, or added later with cvs admin. * It is now possible to specify a charset for emails in the 'CVSROOT/loginfo' configuration file (so the setting can vary between CVS modules). This feature was implemented by Elan Ruusamäe. * Handle the case where someone has checked out the entire repository ('cvs co .'); avoid creating email subjects with prefix '[CVS .]'. Thanks to Christopher Petro for the patch. * Allow the internal $max_lines_per_diff option to be set to nil, meaning 'no limit', following Christopher Petro's suggestion. * The CSS formatting for the 'commit log comment' portion of the email now allows long lines to be broken, in mail clients that support this feature. * The documentation now gives an overview of the install process before diving into a description of the steps. * Notification of commits to a given, single file can now be automatically threaded together by mail clients that support this, thanks to a suggestion by Elan Ruusamäe. [1] http://cvsbook.red-bean.com/cvsbook.html#Controlling%20Keyword%20Expansion dave -- http://david.holroyd.me.uk/ From dave at badgers-in-foil.co.uk Mon Jul 11 16:35:45 2005 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Mon, 11 Jul 2005 16:35:45 +0000 Subject: [cvsspam-devel] encoding from header In-Reply-To: <200507081649.56793.glen@delfi.ee> References: <200502152334.54960.glen@delfi.ee> <20050220173300.GD25328@vhost.badgers-in-foil.co.uk> <200507081649.56793.glen@delfi.ee> Message-ID: <20050711163545.GC11804@vhost.badgers-in-foil.co.uk> On Fri, Jul 08, 2005 at 04:49:56PM +0300, Elan Ruusam?e wrote: > but today i noticed some problem, particularilly, i have patch which allows > you to specify --charset argument to cvsspam [1], which will override charset > sent to outgoing email. it is used because different locations in cvs have > files in different encodings. but the problem is that CVSROOT/users file is > in constant encoding (iso8859-1 in my case), and as a side effect the From > header gets wrongly encoded. > > cvsspam called with --charset utf-8 parameter produces mail header: > From: Elan =?utf-8?q?Ruusam=e4e?= > > perhaps you could look into this issue? > > [1] http://cvs.pld-linux.org/SOURCES/cvsspam-charset-arg.patch Would it be reasonable to try and detect the system character encoding, and use that in preference to the --charset argument? Any idea how that detection should work? I've sometimes seen a charset appended to $LANG, but this is not the case on most of the systems I use. I guess that there could simply be an extra option to specify the encoding, but it would be nice for this to 'just work' without the need for extra config. dave -- http://david.holroyd.me.uk/ From dave at badgers-in-foil.co.uk Mon Jul 11 16:37:57 2005 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Mon, 11 Jul 2005 16:37:57 +0000 Subject: [cvsspam-devel] CVSspam email body problem In-Reply-To: <42CE516F.4060507@GoLive.co.in> References: <42CE516F.4060507@GoLive.co.in> Message-ID: <20050711163757.GD11804@vhost.badgers-in-foil.co.uk> Hi there! On Fri, Jul 08, 2005 at 03:41:59PM +0530, Hemant Thakre wrote: > Recently, > I swithed to cvsspam. > I configured it correctly and it's working gr8. > The problem is in email html body. > The filename in email is having hyperlink to the diff. of that > perticular file, but that link doesnt work. > When I commit more than one file then second file's link point to first > file's diff output. > Can anybody suggest me how to fix it? > I'm using latest CVSspam version. This is a bug that I'd fixed some time ago, but it's been even longer since the 0.2.11 release. Please try the new CVSspam 0.2.12 release, which should fix that problem. ta, dave -- http://david.holroyd.me.uk/ From glen at delfi.ee Thu Jul 14 14:49:01 2005 From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=) Date: Thu, 14 Jul 2005 17:49:01 +0300 Subject: [cvsspam-devel] encoding from header In-Reply-To: <20050711163545.GC11804@vhost.badgers-in-foil.co.uk> References: <200502152334.54960.glen@delfi.ee> <200507081649.56793.glen@delfi.ee> <20050711163545.GC11804@vhost.badgers-in-foil.co.uk> Message-ID: <200507141749.01325.glen@delfi.ee> On Monday 11 July 2005 19:35, David Holroyd wrote: > On Fri, Jul 08, 2005 at 04:49:56PM +0300, Elan Ruusam?e wrote: > > but today i noticed some problem, particularilly, i have patch which > > allows you to specify --charset argument to cvsspam [1], which will > > override charset sent to outgoing email. it is used because different > > locations in cvs have files in different encodings. but the problem is > > that CVSROOT/users file is in constant encoding (iso8859-1 in my case), > > and as a side effect the From header gets wrongly encoded. > > > > cvsspam called with --charset utf-8 parameter produces mail header: > > From: Elan =?utf-8?q?Ruusam=e4e?= > > > > perhaps you could look into this issue? > > > > [1] http://cvs.pld-linux.org/SOURCES/cvsspam-charset-arg.patch > > Would it be reasonable to try and detect the system character encoding, > and use that in preference to the --charset argument? Any idea how that > detection should work? system charset? like something from /etc/sysconfig/i18n? no, i don't think that won't work, because the cvsspam is called with clean enviroment (i don't even have $HOSTNAME set), unless you source that file yourself inside cvsspam. > I've sometimes seen a charset appended to $LANG, but this is not the > case on most of the systems I use. i believe it's because newer linux distributions try to make everything utf8. > I guess that there could simply be an extra option to specify the > encoding, but it would be nice for this to 'just work' without the need > for extra config. default it to latin1 or utf-8 :) it's possible to detect whether file content is in utf8 or something else, by trying to check if all chars make up valid utf8 string, if not -> it's not in utf8. but i really don't think it's cvsspam job to do such detecting :P perhaps also parse lines like "# vim:charset=utf8" but i really vote for $new_var_in_config which defaults to iso8859-1 > dave -- glen From dave at badgers-in-foil.co.uk Thu Jul 14 15:20:20 2005 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Thu, 14 Jul 2005 15:20:20 +0000 Subject: [cvsspam-devel] encoding from header In-Reply-To: <200507141749.01325.glen@delfi.ee> References: <200502152334.54960.glen@delfi.ee> <200507081649.56793.glen@delfi.ee> <20050711163545.GC11804@vhost.badgers-in-foil.co.uk> <200507141749.01325.glen@delfi.ee> Message-ID: <20050714152019.GA14190@vhost.badgers-in-foil.co.uk> On Thu, Jul 14, 2005 at 05:49:01PM +0300, Elan Ruusam?e wrote: > On Monday 11 July 2005 19:35, David Holroyd wrote: > > Would it be reasonable to try and detect the system character encoding, > > and use that in preference to the --charset argument? Any idea how that > > detection should work? > system charset? like something from /etc/sysconfig/i18n? > no, i don't think that won't work, because the cvsspam is called with clean > enviroment (i don't even have $HOSTNAME set), unless you source that file > yourself inside cvsspam. Yeah, well, I don't have a /etc/sysconfig on my Debian laptop. I just hoped that something somewhere in glibc would 'know' the answer somehow... > > I guess that there could simply be an extra option to specify the > > encoding, but it would be nice for this to 'just work' without the need > > for extra config. > default it to latin1 or utf-8 :) > > it's possible to detect whether file content is in utf8 or something else, by > trying to check if all chars make up valid utf8 string, if not -> it's not in > utf8. but i really don't think it's cvsspam job to do such detecting :P > > perhaps also parse lines like "# vim:charset=utf8" The multi-byte sequences in a utf-8 file can also be valid latin1 codepoints. We can't really say that a file _is_ utf-8, though we will sometimes be able to tell if it's _not_. When I originally implemented the encoding header, I thought a little about this, and my conclusion can be summed up with, "Doctor, it hurts when I do this." "Well don't do it then." (Imagine if a commit to a file has the effect of changing its encoding 8) At the end of the day, CVS ignores encoding issues, and CVSspam is basically forced to follow that lead. I belive Subversion fixes this by allowing a per file svn:charset property. > but i really vote for $new_var_in_config which defaults to iso8859-1 Ok, I'll implement something like $system_charset, with a default iso8859-1 as you suggest. Thanks for pointing out the problem, and talking it though. dave -- http://david.holroyd.me.uk/ From skoehler at upb.de Thu Jul 14 15:33:29 2005 From: skoehler at upb.de (=?ISO-8859-1?Q?Sven_K=F6hler?=) Date: Thu, 14 Jul 2005 17:33:29 +0200 Subject: [cvsspam-devel] encoding from header In-Reply-To: <20050711163545.GC11804@vhost.badgers-in-foil.co.uk> References: <200502152334.54960.glen@delfi.ee> <20050220173300.GD25328@vhost.badgers-in-foil.co.uk> <200507081649.56793.glen@delfi.ee> <20050711163545.GC11804@vhost.badgers-in-foil.co.uk> Message-ID: <42D685C9.3090600@upb.de> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBC85D21F0C78869B152953D7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >>but today i noticed some problem, particularilly, i have patch which allows >>you to specify --charset argument to cvsspam [1], which will override charset >>sent to outgoing email. it is used because different locations in cvs have >>files in different encodings. but the problem is that CVSROOT/users file is >>in constant encoding (iso8859-1 in my case), and as a side effect the From >>header gets wrongly encoded. >> >>cvsspam called with --charset utf-8 parameter produces mail header: >>From: Elan =?utf-8?q?Ruusam=e4e?= >> >>perhaps you could look into this issue? >> >>[1] http://cvs.pld-linux.org/SOURCES/cvsspam-charset-arg.patch > > Would it be reasonable to try and detect the system character encoding, > and use that in preference to the --charset argument? Any idea how that > detection should work? > > I've sometimes seen a charset appended to $LANG, but this is not the > case on most of the systems I use. every locale defines a charset to use for i/o. for example the locale "de_DE" defines latin1, while "de_DE@euro" defines latin9 and "de_DE.UTF-8" defines utf-8. As mentioned in another mail, cvsspam might be called with a blank environment, but the current locale is set via the LANG variable or some of the LC_* variables. Event if cvsspam would be called with the user's typical environment provided by a login-shell, we would use the _users_ charset, not the one of the system. I also can imagine a situation, where cvs-repositories have their own encoding. CVS doesn't support setting an encoding, but it's implicitly chosen by the clients. Event the charset for *.java-files might be a different one than for *.xml-files. If you're lucky, someone that manages the project (of which the sources are in the CVS) will decide on the charset to be used for content and filenames in the CVS. That charset would than be written into the cvsspam.conf. BTW: the command-line cvs-client isn't abled to do any charset conversation for filesnames. For example accessing an latin1 CVS from an environment using utf-8 will give scrambled filesnames if they contain non-ASCII characters. The only CVS-client that supports foreign charsets for remote CVS repositories is the Java CVS-client built into the Eclipse IDE. --------------enigBC85D21F0C78869B152953D7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC1oXJ7Ww7FjRBE4ARAhZUAKDYfmCA6l2rQ3JsXI0JXyGRp8x6FwCg5dwl tq/PcR5Z7aN7mlsytPt/UIw= =7OEL -----END PGP SIGNATURE----- --------------enigBC85D21F0C78869B152953D7-- From pardinilist at pardini.net Sat Jul 23 05:04:21 2005 From: pardinilist at pardini.net (Ricardo Pardini) Date: Sat, 23 Jul 2005 02:04:21 -0300 Subject: [cvsspam-devel] Usiing cvsspam as glue for CVS and BugTracker integration Message-ID: <42E1CFD5.4020703@pardini.net> Hello David, first, lets hurray for CVSSpam 0.2.12! Congrats on the release and the new web page. It looks great. Also thanks for crediting me for the simple Wiki Links hack. Now on to something much more ambitious. I've been looking for ways to 'integrate' CVS with a BugTracker, namely Mantis (http://manual.mantisbt.org/), even though I think BugZilla applies too. There is a script supplied by the Mantis developers which should be run from 'commitinfo', which should do the job. There is also a much more complicated system, scmbug (http://files.mkgnu.net/files/scmbug/latest_manual/html/), which tries to implement a generic system for integrating SCM systems (SVN included) with bugtrackers. Both have glaring weaknesses, the checkin script by Mantis is too simple, and scmbug is way too complicated, and neither work on new CVS versions with new formatting strings. The basic idea, in case I'm going too fast, is to commit files and in the commit message, you include the bugtracker's bug id (which should match a regex), and the bugtracker would then assimilate the commit information in many useful ways. I see a common need here: for a given commit, we got to find out which files are being commited, which revisions, which branches are involved, AND the commit message and author and date and ... you get the point. I know of something that does just that, and does it very well: cvsspam. My idea is to allow cvsspam to 'pass on' the information it collects/deduces to an external program, which would be able to do all kinds of things with that, including posting it in Mantis or BugZilla, or formatting it for simpler display on a pager or cellphone, or generate password protected web pages with commit information. The possibilities are endless, and the 'boring' stuff is already done in cvsspam. My proposal is to modify cvsspam such that it can be told to run a specific shell command before it actually sends e-mail. That command can be retrieved from the command-line or from cvsspam.conf. That command would be passed only one argument, which is the full path to a (temporary) XML document, containing mostly all information collected by cvsspam in a to-be-defined schema; on return of the command, cvsspam deletes the XML file and checks the exit code of the command; if it is not zero, it stops and passes that back to CVS. If not, it then proceeds and sends email as usual. That would allow for very simple scripts (well, actually, it must be able to parse/read XML) that can take a multitude of actions based on the information. A few come to mind: * The mentioned Bugtracker integration. Very detailed bug notes can be added. This includes connecting to SQL databases etc. * Generate a 'patch' file containing all the changes made, for simple replication of the changes to another (identical) branch or repository. * Generate a 'revert this commit' patch file or script, which would quickly revert the commit just made. * Pass the received XML file though a XSLT stylesheet, and store the pretty results on the filesystem for later browsing or web publishing. * Simple or intricate access control. The scripts allow/disallow the commit based on, for example, the number of files being commited (impossible to do with commitinfo/loginfo only) * ... goes on forever... What's your opinion on this? Sorry for the long mail, and thanks for cvsspam. -- Ricardo Pardini From skoehler at upb.de Mon Jul 25 20:13:35 2005 From: skoehler at upb.de (=?ISO-8859-15?Q?Sven_K=F6hler?=) Date: Mon, 25 Jul 2005 22:13:35 +0200 Subject: [cvsspam-devel] [BUG] messed up subject-header Message-ID: <42E547EF.2010203@upb.de> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig885343EC338B29CB225A28C9 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi, today i got a cvsspam mail with the subject-header Subject: =3D?ISO-8859-15?q?[CVS_mupad]_vielleicht_h=3De4tte_er_es_so_vers= tand?=3D =3D?ISO-8859-15?q?en??=3D Thunderbird showed the following subject: [CVS mupad] vielleicht h=E4tte er es so verstand =3D?ISO-8859-15?q?en??=3D= The commit comment (2 lines) was: vielleicht h=E4tte er es so verstanden? (man weiss es nicht ...) I think the second ISO-8859-15 thing is wrong. Any idea, what that may have happened? cvsspam 0.2.12 was used. Thx Sven --------------enig885343EC338B29CB225A28C9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC5Ufv7Ww7FjRBE4ARAlk0AKCftBTCdhU96xnL7Tiy4UmBGr5J9ACfaDaf i8cyEwydWSsvYtxFXEjXNmM= =rpsS -----END PGP SIGNATURE----- --------------enig885343EC338B29CB225A28C9-- From dave at badgers-in-foil.co.uk Tue Jul 26 15:42:25 2005 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Tue, 26 Jul 2005 15:42:25 +0000 Subject: [cvsspam-devel] Usiing cvsspam as glue for CVS and BugTracker integration In-Reply-To: <42E1CFD5.4020703@pardini.net> References: <42E1CFD5.4020703@pardini.net> Message-ID: <20050726154225.GB7185@vhost.badgers-in-foil.co.uk> Hi there, sorry for the slow reply, On Sat, Jul 23, 2005 at 02:04:21AM -0300, Ricardo Pardini wrote: > Now on to something much more ambitious. I've been looking for ways > to 'integrate' CVS with a BugTracker, namely Mantis > (http://manual.mantisbt.org/), even though I think BugZilla applies too. > There is a script supplied by the Mantis developers which should be run > from 'commitinfo', which should do the job. There is also a much more > complicated system, scmbug > (http://files.mkgnu.net/files/scmbug/latest_manual/html/), which tries > to implement a generic system for integrating SCM systems (SVN included) > with bugtrackers. Both have glaring weaknesses, the checkin script by > Mantis is too simple, and scmbug is way too complicated, and neither > work on new CVS versions with new formatting strings. > > The basic idea, in case I'm going too fast, is to commit files and > in the commit message, you include the bugtracker's bug id (which should > match a regex), and the bugtracker would then assimilate the commit > information in many useful ways. I see a common need here: for a given > commit, we got to find out which files are being commited, which > revisions, which branches are involved, AND the commit message and > author and date and ... you get the point. I know of something that does > just that, and does it very well: cvsspam. > > My idea is to allow cvsspam to 'pass on' the information it > collects/deduces to an external program, which would be able to do all > kinds of things with that, including posting it in Mantis or BugZilla, > or formatting it for simpler display on a pager or cellphone, or > generate password protected web pages with commit information. The > possibilities are endless, and the 'boring' stuff is already done in > cvsspam. > > My proposal is to modify cvsspam such that it can be told to run a > specific shell command before it actually sends e-mail. That command can > be retrieved from the command-line or from cvsspam.conf. That command > would be passed only one argument, which is the full path to a > (temporary) XML document, containing mostly all information collected by > cvsspam in a to-be-defined schema; on return of the command, cvsspam > deletes the XML file and checks the exit code of the command; if it is > not zero, it stops and passes that back to CVS. If not, it then proceeds > and sends email as usual. > > That would allow for very simple scripts (well, actually, it must be > able to parse/read XML) that can take a multitude of actions based on > the information. A few come to mind: > > * The mentioned Bugtracker integration. Very detailed bug notes can > be added. This includes connecting to SQL databases etc. > * Generate a 'patch' file containing all the changes made, for > simple replication of the changes to another (identical) branch or > repository. > * Generate a 'revert this commit' patch file or script, which would > quickly revert the commit just made. > * Pass the received XML file though a XSLT stylesheet, and store the > pretty results on the filesystem for later browsing or web publishing. > * Simple or intricate access control. The scripts allow/disallow the > commit based on, for example, the number of files being commited > (impossible to do with commitinfo/loginfo only) > * ... goes on forever... > > What's your opinion on this? Connecting CVSspam to a bug tracker is something I've long planned. I need to upgrade the Bugzilla here at work first though, as it's so ancient that it lacks the integration options present in newer versions. I'm looking for more than simply a one-way integration too. I imagine links to bugs in CVSspam emails having a 'title' attribute including the text from the bug's 'summary' field, for instance. So, I'd thought of implementing these features using API's within CVSspam, rather than providing a file-format interface to external scripts. I guess once the former exists, the latter becomes much easier to implement. [Note that as far as access control is concerned, CVSspam currently sits in the wrong place to enforce those decisions: We only have a complete picture of a commit after both commitinfo *and* loginfo hooks have completed, but access control has to be implemented entirely in the commitinfo hook, before the loginfo hooks execute. There are other scripts out there that implement CVS access control IIRC; maybe it would be better to make CVSspam work well with those (if it doesn't already)?] dave -- http://david.holroyd.me.uk/ From dave at badgers-in-foil.co.uk Tue Jul 26 16:10:33 2005 From: dave at badgers-in-foil.co.uk (David Holroyd) Date: Tue, 26 Jul 2005 16:10:33 +0000 Subject: [cvsspam-devel] [BUG] messed up subject-header In-Reply-To: <42E547EF.2010203@upb.de> References: <42E547EF.2010203@upb.de> Message-ID: <20050726161033.GE7185@vhost.badgers-in-foil.co.uk> --Bu8it7iiRSEf40bY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, On Mon, Jul 25, 2005 at 10:13:35PM +0200, Sven K?hler wrote: > today i got a cvsspam mail with the subject-header > > Subject: =?ISO-8859-15?q?[CVS_mupad]_vielleicht_h=e4tte_er_es_so_verstand?= > =?ISO-8859-15?q?en??= > > Thunderbird showed the following subject: > [CVS mupad] vielleicht h?tte er es so verstand =?ISO-8859-15?q?en??= > > The commit comment (2 lines) was: > vielleicht h?tte er es so verstanden? > (man weiss es nicht ...) Looks like the characters '?' and '=' aren't being encoded, as they should be. The attached patch should fix that... Thanks for the bug report! dave -- http://david.holroyd.me.uk/ --Bu8it7iiRSEf40bY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rfc2047_special_chars-patch1.diff" --- cvsspam.rb 2005-07-26 17:17:23.000000000 +0100 +++ cvsspam.rb-fix 2005-07-26 17:17:18.000000000 +0100 @@ -116,6 +116,8 @@ UNDERSCORE = chr("_") SPACE = chr(" ") TAB = chr("\t") + HOOK = chr("?") + EQUALS = chr("=") # encode a header value according to the RFC-2047 quoted-printable spec, # allowing non-ASCII characters to appear in header values, and wrapping @@ -137,7 +139,7 @@ # return a string representing the given character-code in quoted-printable # format def quoted_encode_char(b) - if b>126 || b==UNDERSCORE || b==TAB + if b>126 || b==UNDERSCORE || b==TAB || b==HOOK || b==EQUALS sprintf("=%02x", b) elsif b == SPACE "_" --Bu8it7iiRSEf40bY-- From grstarrett at cox.net Tue Jul 26 16:52:53 2005 From: grstarrett at cox.net (Glen Starrett) Date: Tue, 26 Jul 2005 09:52:53 -0700 Subject: [cvsspam-devel] Usiing cvsspam as glue for CVS and BugTracker integration In-Reply-To: <20050726154225.GB7185@vhost.badgers-in-foil.co.uk> References: <42E1CFD5.4020703@pardini.net> <20050726154225.GB7185@vhost.badgers-in-foil.co.uk> Message-ID: <42E66A65.7020006@cox.net> This is a multi-part message in MIME format. --------------030902020405080808090209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David Holroyd wrote: >> What's your opinion on this? >> >> IMHO, it sounds like there are 2 reasonable solutions to the problem already -- actually 3 if you consider just using the *info script hooks from CVS itself directly. No need to complicate CVSSpam and create yet another interface (somewhere in-between Mantis' implementation and scmbug). ...Not that I've never been accused of over engineering a problem myself, mind you... :) FYI, CVSNT server has support now for a "bug id" on each commit (and edit too, I think) so you can identify which commits go with which bug using the tool instead of parsing the message. It'll be awhile before the GUI front ends include that but it's something to note. >There are other scripts out there that implement CVS access control >IIRC; maybe it would be better to make CVSspam work well with those (if >it doesn't already)?] > > There are several. If you're using CVSNT as the server then you can have access control built into the server (with the chacl and lsacl commands, even to the branch/module level) or any version of server you can use scripts or even file system permissions to get some level of basic control. Regards, Glen Starrett --------------030902020405080808090209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David Holroyd wrote: 
   What's your opinion on this?

IMHO, it sounds like there are 2 reasonable solutions to the problem already -- actually 3 if you consider just using the *info script hooks from CVS itself directly.  No need to complicate CVSSpam and create yet another interface (somewhere in-between Mantis' implementation and scmbug).

...Not that I've never been accused of over engineering a problem myself, mind you... :)

FYI, CVSNT server has support now for a "bug id" on each commit (and edit too, I think) so you can identify which commits go with which bug using the tool instead of parsing the message.  It'll be awhile before the GUI front ends include that but it's something to note.

There are other scripts out there that implement CVS access control
IIRC; maybe it would be better to make CVSspam work well with those (if
it doesn't already)?]

There are several.  If you're using CVSNT as the server then you can have access control built into the server (with the chacl and lsacl commands, even to the branch/module level) or any version of server you can use scripts or even file system permissions to get some level of basic control.

Regards,

Glen Starrett

--------------030902020405080808090209-- From McCoolS at darden.virginia.edu Wed Jul 27 19:13:42 2005 From: McCoolS at darden.virginia.edu (McCool, Scott) Date: Wed, 27 Jul 2005 15:13:42 -0400 Subject: [cvsspam-devel] Additional emails/actions for certain files Message-ID: <2283A534B699ED419AB5F6EE0D6A197B825BF0@mail1.darden.virginia.edu> I have a set of files within our repository that I need to treat differently... In addition to the normal cvsspam notifications I'd like an additional email to go to a subset of recipients (basically need to watch for changes to certain files then notify our DBA, who won't/can't monitor all the checkins for all the modules). Is there any easy way to accomplish this with cvsspam? -Scott From grstarrett at cox.net Wed Jul 27 21:07:08 2005 From: grstarrett at cox.net (Glen Starrett) Date: Wed, 27 Jul 2005 14:07:08 -0700 Subject: [cvsspam-devel] Additional emails/actions for certain files In-Reply-To: <2283A534B699ED419AB5F6EE0D6A197B825BF0@mail1.darden.virginia.edu> References: <2283A534B699ED419AB5F6EE0D6A197B825BF0@mail1.darden.virginia.edu> Message-ID: <42E7F77C.8030309@cox.net> McCool, Scott wrote: >I have a set of files within our repository that I need to treat >differently... In addition to the normal cvsspam notifications I'd like >an additional email to go to a subset of recipients (basically need to >watch for changes to certain files then notify our DBA, who won't/can't >monitor all the checkins for all the modules). > >Is there any easy way to accomplish this with cvsspam? > > Yes! In your loginfo file list the most specific module first with the CVSSpam command to send to your DBA, then set up a more generic one (or just use "DEFAULT") to handle your 'normal' requests. E.g.: ^some/specific/module /path/to/collect_diffs.rb --to user1@example.com --to dba@example.com %{sVv} DEFAULT /path/tocollect_diffs.rb --to user1@example.com %{sVv} Glen Starrett From McCoolS at darden.virginia.edu Thu Jul 28 18:07:35 2005 From: McCoolS at darden.virginia.edu (McCool, Scott) Date: Thu, 28 Jul 2005 14:07:35 -0400 Subject: [cvsspam-devel] Additional emails/actions for certain files Message-ID: <2283A534B699ED419AB5F6EE0D6A197B825DF7@mail1.darden.virginia.edu> Thanks! Still working on a regex to watch for specific files within a directory in each module (rather then just the parent directory which includes more then the DBA cares about), but I suspect that's a regex issue not a cvs/cvsspam issue. -Scott =20 -----Original Message----- From: Glen Starrett [mailto:grstarrett@cox.net]=20 Sent: Wednesday, July 27, 2005 5:07 PM To: McCool, Scott Cc: cvsspam-devel@lists.badgers-in-foil.co.uk Subject: Re: [cvsspam-devel] Additional emails/actions for certain files McCool, Scott wrote: >I have a set of files within our repository that I need to treat=20 >differently... In addition to the normal cvsspam notifications I'd like >an additional email to go to a subset of recipients (basically need to=20 >watch for changes to certain files then notify our DBA, who won't/can't >monitor all the checkins for all the modules). > >Is there any easy way to accomplish this with cvsspam? > =20 > Yes! In your loginfo file list the most specific module first with the CVSSpam command to send to your DBA, then set up a more generic one (or just use "DEFAULT") to handle your 'normal' requests. E.g.: ^some/specific/module /path/to/collect_diffs.rb --to user1@example.com --to dba@example.com %{sVv} DEFAULT /path/tocollect_diffs.rb --to user1@example.com %{sVv} Glen Starrett From grstarrett at cox.net Thu Jul 28 19:00:41 2005 From: grstarrett at cox.net (Glen Starrett) Date: Thu, 28 Jul 2005 12:00:41 -0700 Subject: [cvsspam-devel] Additional emails/actions for certain files In-Reply-To: <2283A534B699ED419AB5F6EE0D6A197B825DF7@mail1.darden.virginia.edu> References: <2283A534B699ED419AB5F6EE0D6A197B825DF7@mail1.darden.virginia.edu> Message-ID: <42E92B59.5000707@cox.net> This is a multi-part message in MIME format. --------------000805000207070509080604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit When in doubt, just create a few regex's. CVS will go down the list and use the first one that matches. ^module/dir/.*\.sql ...to DBA... ^module/otherdir/.*\.db ...to DBA... DEFAULT ...to everyone else... I always use http://regular-expressions.info/ for reference when working (or fighting, depending on the mood) with regex's. There are lots of other places to look for help with regex's. Glen Starrett McCool, Scott wrote: >Thanks! Still working on a regex to watch for specific files within a >directory in each module (rather then just the parent directory which >includes more then the DBA cares about), but I suspect that's a regex >issue not a cvs/cvsspam issue. > >-Scott > > >-----Original Message----- >From: Glen Starrett [mailto:grstarrett@cox.net] >Sent: Wednesday, July 27, 2005 5:07 PM >To: McCool, Scott >Cc: cvsspam-devel@lists.badgers-in-foil.co.uk >Subject: Re: [cvsspam-devel] Additional emails/actions for certain files > >McCool, Scott wrote: > > > >>I have a set of files within our repository that I need to treat >>differently... In addition to the normal cvsspam notifications I'd like >> >> > > > >>an additional email to go to a subset of recipients (basically need to >>watch for changes to certain files then notify our DBA, who won't/can't >> >> > > > >>monitor all the checkins for all the modules). >> >>Is there any easy way to accomplish this with cvsspam? >> >> >> >> > >Yes! In your loginfo file list the most specific module first with the >CVSSpam command to send to your DBA, then set up a more generic one (or >just use "DEFAULT") to handle your 'normal' requests. > >E.g.: > >^some/specific/module /path/to/collect_diffs.rb --to user1@example.com >--to dba@example.com %{sVv} DEFAULT /path/tocollect_diffs.rb --to >user1@example.com %{sVv} > > >Glen Starrett > > > >_______________________________________________ >cvsspam-devel mailing list >cvsspam-devel@lists.badgers-in-foil.co.uk >http://lists.badgers-in-foil.co.uk/mailman/listinfo/cvsspam-devel > > > --------------000805000207070509080604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit When in doubt, just create a few regex's.  CVS will go down the list and use the first one that matches.

^module/dir/.*\.sql   ...to DBA...
^module/otherdir/.*\.db   ...to DBA...
DEFAULT    ...to everyone else...

I always use http://regular-expressions.info/ for reference when working (or fighting, depending on the mood) with regex's.  There are lots of other places to look for help with regex's.

Glen Starrett


McCool, Scott wrote: 
Thanks!  Still working on a regex to watch for specific files within a
directory in each module (rather then just the parent directory which
includes more then the DBA cares about), but I suspect that's a regex
issue not a cvs/cvsspam issue.

-Scott
 

-----Original Message-----
From: Glen Starrett [mailto:grstarrett@cox.net] 
Sent: Wednesday, July 27, 2005 5:07 PM
To: McCool, Scott
Cc: cvsspam-devel@lists.badgers-in-foil.co.uk
Subject: Re: [cvsspam-devel] Additional emails/actions for certain files

McCool, Scott wrote:

  
I have a set of files within our repository that I need to treat 
differently... In addition to the normal cvsspam notifications I'd like
    

  
an additional email to go to a subset of recipients (basically need to 
watch for changes to certain files then notify our DBA, who won't/can't
    

  
monitor all the checkins for all the modules).

Is there any easy way to accomplish this with cvsspam?
 

    

Yes!  In your loginfo file list the most specific module first with the
CVSSpam command to send to your DBA, then set up a more generic one (or
just use "DEFAULT") to handle your 'normal' requests.

E.g.:

^some/specific/module /path/to/collect_diffs.rb --to user1@example.com
--to dba@example.com %{sVv} DEFAULT /path/tocollect_diffs.rb --to
user1@example.com %{sVv}


Glen Starrett



_______________________________________________
cvsspam-devel mailing list
cvsspam-devel@lists.badgers-in-foil.co.uk
http://lists.badgers-in-foil.co.uk/mailman/listinfo/cvsspam-devel
--------------000805000207070509080604-- From grstarrett at cox.net Thu Jul 28 19:03:17 2005 From: grstarrett at cox.net (Glen Starrett) Date: Thu, 28 Jul 2005 12:03:17 -0700 Subject: [cvsspam-devel] Additional emails/actions for certain files In-Reply-To: <42E92B59.5000707@cox.net> References: <2283A534B699ED419AB5F6EE0D6A197B825DF7@mail1.darden.virginia.edu> <42E92B59.5000707@cox.net> Message-ID: <42E92BF5.8030406@cox.net> This is a multi-part message in MIME format. --------------060504040807090807030904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Oops -- I think that was wrong. I think CVS looks by the module only for the match, I'm pretty sure it doesn't look for specific file names. Glen Starrett Glen Starrett wrote: > When in doubt, just create a few regex's. CVS will go down the list > and use the first one that matches. > > ^module/dir/.*\.sql ...to DBA... > ^module/otherdir/.*\.db ...to DBA... > DEFAULT ...to everyone else... --------------060504040807090807030904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Oops -- I think that was wrong.  I think CVS looks by the module only for the match, I'm pretty sure it doesn't look for specific file names.

Glen Starrett


Glen Starrett wrote:
When in doubt, just create a few regex's.  CVS will go down the list and use the first one that matches.

^module/dir/.*\.sql   ...to DBA...
^module/otherdir/.*\.db   ...to DBA...
DEFAULT    ...to everyone else...

--------------060504040807090807030904--