[arch-dev-public] update problems on gerolde
Hi gang, I just had an issue with running db-extra: -bash-3.2$ /arch/db-extra Updating DB for extra i686 ==> Processing new/updated packages for repository 'extra'... Checked out revision 3041. Checking SVN for scribus ==> Extracting database to a temporary location... ==> Adding package 'scribus-1.3.3.12-1-i686.pkg.tar.gz' -> Removing existing package 'scribus-1.3.3.11-2'... -> Creating 'desc' db entry... -> Computing md5 checksums... -> Creating 'depends' db entry... ==> Creating updated database file /tmp/db-update.extra-i686.533/build/extra.db.tar.gz No packages to delete Copying new files to '/home/ftp/extra/os/i686/' /bin/cp: cannot create regular file `/home/ftp/extra/os/i686/extra.db.tar.gz': Permission denied /bin/cp: cannot create regular file `/home/ftp/extra/os/i686/extra.db.tar.gz.old': Permission denied Cleaning staging dir Eric just reported that, the db has his user permission, which is why I can't overwrite it: -bash-3.2$ ls -l /home/ftp/extra/os/i686/extra.* -rw-r--r-- 1 eric users 412828 Jun 17 22:44 /home/ftp/extra/os/i686/extra.db.tar.gz -rw-r--r-- 1 eric users 412653 Jun 17 22:44 /home/ftp/extra/os/i686/extra.db.tar.gz.old -rw-rw-r-- 1 ftp ftp-extra 320495 May 21 05:36 /home/ftp/extra/os/i686/extra.db.tar.gz.orig -rw-r--r-- 1 pierre ftp-extra 3066292 Jun 18 03:57 /home/ftp/extra/os/i686/extra.files.tar.gz -rw-r--r-- 1 aaron ftp-extra 3059214 Jun 17 16:41 /home/ftp/extra/os/i686/extra.files.tar.gz.old bye can anyone with permissions can take care of that? thanks -T
Tobias Kieslich schrieb:
Eric just reported that, the db has his user permission, which is why I can't overwrite it: -bash-3.2$ ls -l /home/ftp/extra/os/i686/extra.* -rw-r--r-- 1 eric users 412828 Jun 17 22:44 /home/ftp/extra/os/i686/extra.db.tar.gz -rw-r--r-- 1 eric users 412653 Jun 17 22:44 /home/ftp/extra/os/i686/extra.db.tar.gz.old -rw-rw-r-- 1 ftp ftp-extra 320495 May 21 05:36 /home/ftp/extra/os/i686/extra.db.tar.gz.orig -rw-r--r-- 1 pierre ftp-extra 3066292 Jun 18 03:57 /home/ftp/extra/os/i686/extra.files.tar.gz -rw-r--r-- 1 aaron ftp-extra 3059214 Jun 17 16:41 /home/ftp/extra/os/i686/extra.files.tar.gz.old
bye can anyone with permissions can take care of that? thanks -T
1) This shouldn't happen 2) There should be a cronjob in place to fix the permissions. Dunno what happened to the cron job though, Aaron can probably answer that.
On Wed, 18 Jun 2008, Thomas Bächler wrote:
Tobias Kieslich schrieb:
Eric just reported that, the db has his user permission, which is why I can't overwrite it: -bash-3.2$ ls -l /home/ftp/extra/os/i686/extra.* -rw-r--r-- 1 eric users 412828 Jun 17 22:44 /home/ftp/extra/os/i686/extra.db.tar.gz -rw-r--r-- 1 eric users 412653 Jun 17 22:44 /home/ftp/extra/os/i686/extra.db.tar.gz.old -rw-rw-r-- 1 ftp ftp-extra 320495 May 21 05:36 /home/ftp/extra/os/i686/extra.db.tar.gz.orig -rw-r--r-- 1 pierre ftp-extra 3066292 Jun 18 03:57 /home/ftp/extra/os/i686/extra.files.tar.gz -rw-r--r-- 1 aaron ftp-extra 3059214 Jun 17 16:41 /home/ftp/extra/os/i686/extra.files.tar.gz.old
bye can anyone with permissions can take care of that? thanks -T
1) This shouldn't happen 2) There should be a cronjob in place to fix the permissions.
Dunno what happened to the cron job though, Aaron can probably answer that.
The extra repo and the unstable repo for both arches have that problem. On Tobias's request, I've set the permissions to 664 as temporary fix. My guess is that it was caused by the db-move script which I uses last night to move gimp-devel to extra as the testing x86_64 db has the right permissions. It might have been caused by the way I did it. I first updated the unstable package (unstablepkg on my system, db-unstable on gerolde), checked the output then ran db-move a few minutes later. Perhaps I should've waited longer before running db-move. Or maybe it's a problem with the cron jobs. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
So, this was my fault - when I installed the cron jobs yesterday, I symlinked a crontab file into /etc/cron.d/ assuming it would work. Apparently, it does not. Rather than figure out why, I dumped all those entries into root's crontab. Is anyone aware of why /etc/cron.d was not read?
On Wed, Jun 18, 2008 at 12:16 PM, Aaron Griffin
So, this was my fault - when I installed the cron jobs yesterday, I symlinked a crontab file into /etc/cron.d/ assuming it would work. Apparently, it does not. Rather than figure out why, I dumped all those entries into root's crontab.
Is anyone aware of why /etc/cron.d was not read?
I've always had to restart cron to get it to re-read files I put into /etc/cron.d. I also put files in there, I've never tried symlinks. I've also found /var/log/crond to be very helpful when asking, "why the hell isn't cron running this?!?" I don't know what the script or command was so I can't check the logs myself. Jason
On Wednesday 18 June 2008 20:07:14 Thomas Bächler wrote:
Dunno what happened to the cron job though, Aaron can probably answer that.
The FileDB cronjob did not run last night, too. Seems something went wrong. -- archlinux.de
On Wed, Jun 18, 2008 at 1:19 PM, Pierre Schmitz
On Wednesday 18 June 2008 20:07:14 Thomas Bächler wrote:
Dunno what happened to the cron job though, Aaron can probably answer that.
The FileDB cronjob did not run last night, too. Seems something went wrong.
Can you check and see if this ran last night?
Am Donnerstag, 19. Juni 2008 18:07:38 schrieb Aaron Griffin:
The FileDB cronjob did not run last night, too. Seems something went wrong.
Can you check and see if this ran last night?
Just compare the mtime of e.g. testing.db.tar.gz and testing.files.tar.gz. The filedb script was never run by cron; the last update was a manual one by me. There is something wrong. Don't you have any output from the cron job? -- http://www.archlinux.de
Am Freitag, 20. Juni 2008 08:50:57 schrieb Pierre Schmitz:
Can you check and see if this ran last night?
Just compare the mtime of e.g. testing.db.tar.gz and testing.files.tar.gz. The filedb script was never run by cron; the last update was a manual one by me. There is something wrong. Don't you have any output from the cron job?
However: the main problem is that the crontab calls "/arch/cron-jobs/createFileList" which does not exist. Add an "s" and everything should be fine. :-) -- http://www.archlinux.de
On Fri, Jun 20, 2008 at 6:51 AM, Pierre Schmitz
Am Freitag, 20. Juni 2008 08:50:57 schrieb Pierre Schmitz:
Can you check and see if this ran last night?
Just compare the mtime of e.g. testing.db.tar.gz and testing.files.tar.gz. The filedb script was never run by cron; the last update was a manual one by me. There is something wrong. Don't you have any output from the cron job?
However: the main problem is that the crontab calls "/arch/cron-jobs/createFileList" which does not exist. Add an "s" and everything should be fine. :-)
Well, damn. Thanks for that. I should rely on vim's file completion more 8)
participants (6)
-
Aaron Griffin
-
Eric Belanger
-
Jason Chu
-
Pierre Schmitz
-
Thomas Bächler
-
Tobias Kieslich