Showing posts with label troubleshooting. Show all posts
Showing posts with label troubleshooting. Show all posts

08 November 2009

bugzilla upgrades and user tokens

It's bugzilla upgrade time for my private install, and I have for the second time run into a strange issue with the tokens system. Since this is the second time and I know how to fix it, here it is for the record.

I have upgrade from v3.0.4 to 3.4.3.

Once the site was up again, saving the site parameters (editparams.cgi) showed a big red warning:

It looks like you didn't come from the right page (you have no valid token for the edit_parameters action while processing the 'editparams.cgi' script). The reason could be one of:
  • You clicked the "Back" button of your web browser after having successfully submitted changes, which is generally not a good idea (but harmless).
  • You entered the URL in the address bar of your web browser directly, which should be safe.
  • You clicked on a URL which redirected you here without your consent, in which case this action is much more critical.
Are you sure you want to commit these changes anyway? This may result in unexpected and undesired results.

[Confirm Changes]

Or throw away these changes and go back to editparams.cgi.



Pushing the button doesn't work (same page shows again).

After much digging last time I discovered that the tokens it refers to are stored in table bugs.tokens, and that the size of the field is wrong in my installation after the upgrade (again).

mysql> use bugs;
mysql> describe tokens;
+-----------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------+--------------+------+-----+---------+-------+
| userid | mediumint(9) | YES | MUL | NULL | |
| issuedate | datetime | NO | | NULL | |
| token | varchar(5) | NO | PRI | NULL | |
| tokentype | varchar(8) | YES | | NULL | |
| eventdata | tinytext | YES | | NULL | |
+-----------+--------------+------+-----+---------+-------+
5 rows in set (0.02 sec)

According to the published schema, token should be varchar(16). http://www.ravenbrook.com/project/p4dti/tool/cgi/bugzilla-schema/index.cgi?action=single&version=3.4.2&view=View+schema#table-tokens

To fix the problem I modified the data type as follows:


mysql> alter table tokens modify column token varchar(16) not null;
Query OK, 20 rows affected (0.32 sec)
Records: 20 Duplicates: 0 Warnings: 0


And then I was able to change my parameters.

https://bugzilla.mozilla.org/show_bug.cgi?id=527780

10 September 2008

error "Not a valid object name" filtering an ex-svn git repo with renames

Under git version 1.5.4.3, which as of writing is the current in ubuntu 8.04 hardy heron, trying to split out a folder from a git repo where the repo was an import from subversion (svn), and the folder was renamed in the past causes a failure as show below:

#!/bin/bash -v
rm -rf test-case
mkdir test-case
cd test-case/
svnadmin create svnrepo
export repo="`pwd`/svnrepo"
mkdir -p import/a
echo '1' >> import/a/file.txt
svn import -m 'initial import' import file://$repo/trunk/
svn co file://$repo/trunk/ checkout
echo '2' >> checkout/a/file.txt
svn ci -m "file modified" checkout
svn mv -m "moving file" file://$repo/trunk/a file://$repo/trunk/b
svn up checkout
echo '3' >> checkout/b/file.txt
svn ci -m "modified again" checkout
svn log -v checkout
mkdir -p gitcopy/a
git svn clone file://$repo/trunk/ gitcopy/a
cd gitcopy/a
git filter-branch --subdirectory-filter a #fails [1]
cd ../../
mkdir gitcopy/b
git svn clone file://$repo/trunk/ gitcopy/b
cd gitcopy/b
git filter-branch --subdirectory-filter b


The marked line above fails with the following error:
[1] Rewrite bcfe73ef303832b6112a2419dc1da5f782672c14 (3/3)fatal: Not a valid object name bcfe73ef303832b6112a2419dc1da5f782672c14:a

This has been fixed in the latest build of git: version 1.6.0.1.294.gda06a and no longer fails.

The "fatal: Not a git repository" error message that filter branch produces doesn't seem to matter.