Xyne wrote:
I sent a message to this list about this yesterday but it seems to have
been lost. It seems that things like to stop working all at once.
I can't get nexuiz-data into the database. I keep getting the following
error:
[x...@sigurd ~]$ /arch/db-community
==> Processing 1 new/updated arch-independent packages for
'community'... Checked out revision 3198.
Validating package arch (any) nexuiz-data
Checking SVN for nexuiz-data
WARNING: nexuiz-data-2.5.1-3-any.pkg.tar.gz does not match PKGBUILD
in community-any Updating DB for community-i686
==> Copying DB file from 'community'...
==> Processing 1 new/updated packages for repository 'community'...
D checkout/nexuiz-data
Checked out revision 3198.
Errors found when adding packages
Updating DB for community-x86_64
==> Copying DB file from 'community'...
==> Processing 1 new/updated packages for repository 'community'...
Checked out revision 3198.
Errors found when adding packages
I've tried removing (svn rm) the PKGBUILD in nexuiz-data/repos/,
commiting the changes and re-releasing the trunk. I've double-checked
that I've followed all the steps for adding and updating the package
against the wiki and my own working scripts. I've even tried bumping
the pkgrel and rebuilding the package.
I've also removed the local svn copy of nexuiz-data, checked it out
again to make sure that I have the same version of the PKGBUILD, and
used that to rebuild the package.
I have no idea what to do now and would appreciate any help.
The package is in ~/staging/community on Sigurd. I also have a copy of
the current PKGBUILD along with the Nexuiz source code in ~/build for
quick rebuilds (all it does is unzip the sources, move them to $pkgdir,
remove some unnecessary Windows and Mac files, then recompress).
Thanks,
Xyne
It looks like _pkgname in the PKGBUILD overrides a variable which is
internal to db-update and happens to have the same name.
Here are the relevant lines in /arch/db-update:
http://pastebin.com/f2b478ad - see my comments on each highlighted line
for what I believe is going on and causes it to fail.
I would suggest losing the _pkgname in the PKGBUILD, but there may be a
better and more universal solution.
