On Sat, 22 Nov 2008, Aaron Griffin wrote:

On Sat, Nov 22, 2008 at 8:06 PM, Eric Bélanger 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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

On Sat, 22 Nov 2008, Aaron Griffin wrote:

On Sat, Nov 22, 2008 at 9:40 PM, Eric Bélanger wrote:

...

On Sat, 22 Nov 2008, Aaron Griffin wrote:

...

On Sat, Nov 22, 2008 at 8:06 PM, Eric Bélanger 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! -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Am Sun, 23 Nov 2008 02:23:45 -0600 schrieb "Aaron Griffin" :

Pulled the new DB scripts to /arch-new - please ignore the error about add and del dirs until I update devtools 8)

[andyrtr@gerolde staging]$ tree . |-- core | |-- add | `-- del |-- extra | |-- add | | |-- firefox-3.0.4-1-x86_64.pkg.tar.gz | | |-- firefox-i18n-3.0.4-1-x86_64.pkg.tar.gz | | |-- nss-3.12.1-1-x86_64.pkg.tar.gz | | |-- sqlite3-3.6.6-1-x86_64.pkg.tar.gz | | `-- xulrunner-1.9.0.4-1-x86_64.pkg.tar.gz | `-- del `-- testing |-- add `-- del 9 directories, 5 files [andyrtr@gerolde staging]$ sh /arch-new/db-extra64 Updating DB for extra x86_64 -------------------------------------------------- It looks like you have an old staging dir The 'add' and 'del' dirs are no longer used. Please delete staging/<reponame>/{add,del} and ensure you are using the newest devtools -------------------------------------------------- /arch-new/db-update: line 93: [: too many arguments No packages to add Nothing to copy, no work done Sure, Allan's fault but... -Andy

On Sat, Nov 22, 2008 at 11:37 PM, Eric Bélanger wrote:

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!

Did I pick a bad night to update packages? I received the same error when using /arch/db-extra64 and now those packages have gone AWOL.

On Sun, Nov 23, 2008 at 10:29 PM, Aaron Griffin wrote:

On Sun, Nov 23, 2008 at 11:51 PM, Thayer Williams wrote:

...

On Sat, Nov 22, 2008 at 11:37 PM, Eric Bélanger wrote:

...

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!

Did I pick a bad night to update packages? I received the same error when using /arch/db-extra64 and now those packages have gone AWOL.

Actually, the chmod errors should be harmless (I removed the || return 1). Please test /arch-new/* if you get a chance.

Running the new db-scripts generates: [thayer@gerolde ~]$ /arch-new/db-extra64 error: db generation is already in progress (started by thayer) 0022

On Mon, Nov 24, 2008 at 12:06 AM, Eric Bélanger wrote:

On Mon, 24 Nov 2008, Thayer Williams wrote:

...

On Sun, Nov 23, 2008 at 10:29 PM, Aaron Griffin wrote:

...

On Sun, Nov 23, 2008 at 11:51 PM, Thayer Williams wrote:

...

On Sat, Nov 22, 2008 at 11:37 PM, Eric Bélanger wrote:

...

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!

Did I pick a bad night to update packages? I received the same error when using /arch/db-extra64 and now those packages have gone AWOL.

Actually, the chmod errors should be harmless (I removed the || return 1). Please test /arch-new/* if you get a chance.

Running the new db-scripts generates:

[thayer@gerolde ~]$ /arch-new/db-extra64 error: db generation is already in progress (started by thayer) 0022

remove the hidden lock file in /srv/tmp

Thanks, Eric I didn't see this until this morning, but it appears someone has already removed it. However, the x86_64 packages I pushed last night are stilling missing in action. They were cleared from ~/staging when I initially ran the /arch/ db scripts, but they're still not listed in the repos. Is there something else I need to refresh/update?

On Mon, Nov 24, 2008 at 7:40 AM, Aaron Griffin wrote:

On Mon, Nov 24, 2008 at 9:38 AM, Thayer Williams wrote:

...

On Mon, Nov 24, 2008 at 12:06 AM, Eric Bélanger wrote:

...

On Mon, 24 Nov 2008, Thayer Williams wrote:

...

On Sun, Nov 23, 2008 at 10:29 PM, Aaron Griffin wrote:

...

On Sun, Nov 23, 2008 at 11:51 PM, Thayer Williams wrote:

...

On Sat, Nov 22, 2008 at 11:37 PM, Eric Bélanger wrote: > > 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!

Did I pick a bad night to update packages? I received the same error when using /arch/db-extra64 and now those packages have gone AWOL.

Actually, the chmod errors should be harmless (I removed the || return 1). Please test /arch-new/* if you get a chance.

Running the new db-scripts generates:

[thayer@gerolde ~]$ /arch-new/db-extra64 error: db generation is already in progress (started by thayer) 0022

remove the hidden lock file in /srv/tmp

Thanks, Eric I didn't see this until this morning, but it appears someone has already removed it. However, the x86_64 packages I pushed last night are stilling missing in action. They were cleared from ~/staging when I initially ran the /arch/ db scripts, but they're still not listed in the repos. Is there something else I need to refresh/update?

Well, in that case, I probably blew them up. See if they're in /srv/package-cleanup

Nah, they aren't there either. What if I just rebuild the packages, scp them to ~/staging and then run the new db script? These are all trivial non-binary packages so it wouldn't take much effort to do so.

On Mon, Nov 24, 2008 at 8:31 AM, Aaron Griffin wrote:

On Mon, Nov 24, 2008 at 10:00 AM, Thayer Williams wrote:

...

On Mon, Nov 24, 2008 at 7:40 AM, Aaron Griffin wrote:

...

On Mon, Nov 24, 2008 at 9:38 AM, Thayer Williams wrote:

...

On Mon, Nov 24, 2008 at 12:06 AM, Eric Bélanger wrote:

...

On Mon, 24 Nov 2008, Thayer Williams wrote:

...

On Sun, Nov 23, 2008 at 10:29 PM, Aaron Griffin wrote: > > On Sun, Nov 23, 2008 at 11:51 PM, Thayer Williams > wrote: >> >> On Sat, Nov 22, 2008 at 11:37 PM, Eric Bélanger >> wrote: >>> >>> 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! >> >> Did I pick a bad night to update packages? I received the same error >> when using /arch/db-extra64 and now those packages have gone AWOL. > > Actually, the chmod errors should be harmless (I removed the || return > 1). Please test /arch-new/* if you get a chance. >

Running the new db-scripts generates:

[thayer@gerolde ~]$ /arch-new/db-extra64 error: db generation is already in progress (started by thayer) 0022

remove the hidden lock file in /srv/tmp

Thanks, Eric I didn't see this until this morning, but it appears someone has already removed it. However, the x86_64 packages I pushed last night are stilling missing in action. They were cleared from ~/staging when I initially ran the /arch/ db scripts, but they're still not listed in the repos. Is there something else I need to refresh/update?

Well, in that case, I probably blew them up. See if they're in /srv/package-cleanup

Nah, they aren't there either.

What if I just rebuild the packages, scp them to ~/staging and then run the new db script? These are all trivial non-binary packages so it wouldn't take much effort to do so.

Yep, that's really all the scripts to anyway. Do the svn mojo, scp to gerolde, check md5sums, and I think that's it.

Cool, I think that took care of it!