On Wed, Sep 30, 2009 at 7:10 AM, Evangelos Foutras <foutrelis@gmail.com> wrote:
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:
[xyne@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.
What, dbscripts use _foo variables ? Doesn't that completely defeat the guideline we have in PKGBUILD man page : If you need to create any custom variables for use in your build process, it is recommended to name your custom variables with an _ (underscore) prefix. This will prevent any possible name clashes with internal makepkg variables. For example, to store the base kernel version in a variable, use something similar to $_basekernver. It is the PKGBUILD who should use _foo syntax to avoid clashes. If dbscripts does it also, it's not avoiding clashes, it's asking for clashes :) However, if dbscripts used things like $realpkgname $pkgbuild_pkgname or whatever, it would be fine. If a pkgbuild also defined these, it would be pkgbuild's fault of not following the guidelines. This should definitely be fixed.