Received: from [10.1.2.49] (root@raven.ravenbrook.com [193.82.131.18]) by raven.ravenbrook.com (8.9.3/8.9.3) with ESMTP id RAA17315 for ; Tue, 30 Jan 2001 17:00:35 GMT Mime-Version: 1.0 X-Sender: gdr@pop3 Message-Id: Date: Tue, 30 Jan 2001 09:00:07 -0800 To: p4dti-staff@ravenbrook.com From: Gareth Rees Subject: Test report for release 0.5.1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Gerry Thompson and I installed release 0.5.1 on FreeBSD 3.0. (Note that this is not a supported operating system for the P4DTI. Nonetheless we were able to get it to work, after a number of tricky problems.) 1. Line 16 of bugzilla.py says: error = 'P4DTI TeamTrack interface error' It should of course say "Bugzilla", not "TeamTrack". 2. When I started the replicator for the first time, I got this error: Traceback (innermost last): File "replicator.py", line 1332, in run self.poll() File "replicator.py", line 823, in poll changed_issues, _, dt_marker = self.dt.changed_entities() File "dt_bugzilla.py", line 444, in changed_entities bugs = self.bugzilla.all_bugs_since(last) File "bugzilla.py", line 532, in all_bugs_since changed = self.fetch_rows_as_list_of_dictionaries( File "bugzilla.py", line 192, in sqlquote raise error, ("sqlquote given non-string %s." % str(value)) P4DTI TeamTrack interface error: sqlquote given non-string 2001-01-29 18:23:27.00. I looked at this in the debugger and it turns out that the offending value is the 'date' argument to 'all_bugs_since' which has this value: Now take a look at this command and traceback: >>> dt.bugzilla.execute('select * from bugs') 2001-01-30 02:56:09 UTC P4DTI-00 replicator0 execute 'select * from bugs' Traceback (innermost last): File "", line 1, in ? File "bugzilla.py", line 57, in execute rows = self.cursor.execute(sql) File "/usr/local/lib/python1.5/site-packages/MySQLdb.py", line 194, in execute return self._query(query) File "/usr/local/lib/python1.5/site-packages/MySQLdb.py", line 284, in _query self._rows = self._result and self._fetch_all_rows() or () File "/usr/local/lib/python1.5/site-packages/MySQLdb.py", line 374, in _fetch_all_rows return _fetchall(self._result, self.arraysize, self._fetch_type) File "/usr/local/lib/python1.5/site-packages/MySQLdb.py", line 150, in _fetchall rows = r = list(apply(result.fetch_row, args)) File "/usr/local/lib/python1.5/site-packages/DateTime/ISO.py", line 102, in ParseDateTime return DateTime.DateTime(year,month,day,hour,minute,second) mxDateTime.RangeError: month out of range (1-12) It seems clear that the problem is in the DateTime module. But why is the DateTime module being used at all? DateTime isn't installed on swan.ravenbrook.com and the integration works fine there. Well, it turns out that the MySQLdb module has one behaviour when DateTime is installed, and a different behaviour when DateTime is not installed. Here's some code from MySQLdb.py illustrating this: try: try: from mx import DateTime # new packaging except ImportError: import DateTime # old packaging from DateTime import Date, Time, Timestamp, ISO, \ DateTimeType, DateTimeDeltaType [snip] except ImportError: # no DateTime? We'll muddle through somehow. from time import strftime [etc] So I made my own empty DateTime.py module in the same directory as the replicator (this overrides the installed DateTime module). The replicator then worked fine. 3. Michael Biczinsky wants to know: will TeamShare be supporting the interim builds (4402, 4407 etc) in the event that 4.5 is not out in time? 4. In the documentation, we shouldn't use "the Integration" where we mean "the P4DTI". "Integration" already has a meaning in Perforce and we don't want to confuse the issue even more than it is already. 5. In configure_bugzilla, the "Assigned_To" field is made "required" in the Perforce jobspec. But what if a bug isn't assigned to anyone? (Bugs start out not being assigned to anyone.) In that case we get an error from Perforce when we try to update the job: p4 results: '[{'severity': 3, 'data': "Error in job specification.\012Missing required field 'Assigned_To'.\012", 'code': 'error', 'generic': 4}]' Probably the Assigned_To field should be optional, with no Preset. But note that the user_translator will need to deal with an empty Assigned_To field. 6. In problem number 5 above, you only get the error message above when you have verbose set to 1. Otherwise, all you see is the following: Perforce error: The Perforce client exited with error code 256. Is the server down or the server address incorrect? This is completely unhelpful. So it looks to me as though the change to p4.py that made it take account of the exit code was too thorough: it allows a useless exit code to obscure a useful error message. I suggest providing both the exit code and the error message (if any) in the Python exception. 7. To try to solve problem 5 above, I tried making the field 'optional'. But this didn't work because Perforce changed 'optional' to 'once'. A little investigation showed that Perforce consistently changes the disposition of a field from 'optional' to 'once' when there's a Preset for that field. 8. MySQL 3.22.32 doesn't work with Bugzilla. Users can't log in to Bugzilla. The reason appears to be that the MySQL function encrypt($string) which is used to generate the encrypted password behaves differently from encrypt($string, substring($string, 0, 2)) which is used to check it. I was able to work around this by changing encrypt($string) in globals.pl to encrypt($string, '\$1'). So is this another incompatibility between MySQL and Bugzilla? Note that Gerry had installed a pre-built FreeBSD package of MySQL-3.22.32.