On Sun, Nov 23, 2008 at 1:37 AM, Eric Bélanger <[EMAIL PROTECTED]> wrote: > On Sat, 22 Nov 2008, Aaron Griffin wrote: > >> On Sat, Nov 22, 2008 at 9:40 PM, Eric Bélanger >> <[EMAIL PROTECTED]> wrote: >>> >>> On Sat, 22 Nov 2008, Aaron Griffin wrote: >>> >>>> On Sat, Nov 22, 2008 at 8:06 PM, Eric Bélanger >>>> <[EMAIL PROTECTED]> wrote: >>>>> >>>>> Hi, >>>>> >>>>> The db script for extra x86_64 is stuck: >>>>> >>>>> $ /arch/db-extra64 >>>>> error: db generation is already in progress (started by andyrtr) >>>>> rm: cannot remove `/srv/tmp/.repolock.extra.x86_64': Operation not >>>>> permitted >>>>> >>>>> That was started hours ago. Can someone with root power remove the lock >>>>> file >>>>> to fix it? >>>> >>>> Fixed it. I'm fixing some oopses I made with the dbscripts now. If >>>> this happens again, let me know - I commented out the chmod crap for >>>> now >>>> >>>> >>> >>> I'm not sure if it's part of the oopses, but it seems that the problem is >>> that the script for x86_64 doesn't remove the lock file because it can't >>> find it. Error message on running db-extra64: >>> error: repo lock doesn't exist... something went terribly wrong! >>> >>> A /srv/tmp/.repolock.extra.x86_64 lockfile was left with 644 permissions >>> for >>> my user. I removed it manually to not block updates for other users. >> >> I think this is related to bug 10888 - where sourcing the PKGBUILD >> overwrites the $arch local var, so it's always i686 (as $foo of an >> array, foo, evaluates to the first array item, which is usually i686). >> >> I will have this fixed in a few hours or so >> >> > > I don't know if it's already taken care of in your upcoming fixes, but > currently, when there are multiple packages in the staging directory, the > arch variable get resetted to i686 after processing the first package. > Therefore the rest of them fail with a "wrong architecture" error message > (full error message below). I've by-pass this problem by running the db > script with only one package in my staging repo at all time. > > $ /arch/db-extra64 > Updating DB for extra x86_64 > ==> Processing new/updated packages for repository 'extra'... > Checked out revision 19444. > Validating package arch (x86_64) centerim > Checking SVN for centerim > Validating package arch (i686) django > ERROR: django-1.0.2-1-x86_64.pkg.tar.gz was built for the wrong > architecture > Validating package arch (i686) lsof > ERROR: lsof-4.81-1-x86_64.pkg.tar.gz was built for the wrong architecture > Validating package arch (i686) mtr > ERROR: mtr-0.75-1-x86_64.pkg.tar.gz was built for the wrong architecture > Validating package arch (i686) scons > ERROR: scons-1.1.0.d20081104-1-x86_64.pkg.tar.gz was built for the wrong > architecture > Validating package arch (i686) xorg-apps > ERROR: xorg-apps-7.4-1-x86_64.pkg.tar.gz was built for the wrong > architecture > Validating package arch (i686) xorg-server-utils > ERROR: xorg-server-utils-7.4-2-x86_64.pkg.tar.gz was built for the wrong > architecture > ==> Extracting database to a temporary location... > ==> Adding package 'centerim-4.22.6-1-x86_64.pkg.tar.gz' > -> Removing existing package 'centerim-4.22.5-3'... > -> Creating 'desc' db entry... > -> Computing md5 checksums... > -> Creating 'depends' db entry... > ==> Creating updated database file > '/srv/tmp/db-update.extra-x86_64.1030/build/extra.db.tar.gz' > No packages to delete > Copying new files to '/srv/ftp//extra/os/x86_64/' > /bin/chmod: changing permissions of > `/srv/ftp//extra/os/x86_64//extra.db.tar.gz': Operation not permitted > /bin/chmod: changing permissions of > `/srv/ftp//extra/os/x86_64//extra.db.tar.gz.old': Operation not permitted > Cleaning staging dir > error: repo lock doesn't exist... something went terribly wrong!
Pulled the new DB scripts to /arch-new - please ignore the error about add and del dirs until I update devtools 8)

