[arch-dev-public] Fwd: [arch-notifications] Core/Extra Cleanup 20-05-2010
Any ideas on this? -------- Original Message -------- Subject: [arch-notifications] Core/Extra Cleanup 20-05-2010 Date: Thu, 20 May 2010 06:24:50 -0400 (EDT) From: repomaint@archlinux.org Reply-To: List for automated notifications <arch-notifications@archlinux.org> To: arch-notifications@archlinux.org Scan complete for extra (x86_64) at /srv/ftp/extra/os/x86_64 The following files are missing in the repo %FILENAME%
Am 20.05.2010 12:33, schrieb Allan McRae:
Any ideas on this?
-------- Original Message -------- Subject: [arch-notifications] Core/Extra Cleanup 20-05-2010 Date: Thu, 20 May 2010 06:24:50 -0400 (EDT) From: repomaint@archlinux.org Reply-To: List for automated notifications <arch-notifications@archlinux.org> To: arch-notifications@archlinux.org
Scan complete for extra (x86_64) at /srv/ftp/extra/os/x86_64 The following files are missing in the repo %FILENAME%
Looks like a broken database entry. But the output doesn't tell us where exactly it was. Did this happen more than once?
On 20/05/10 21:16, Thomas Bächler wrote:
Am 20.05.2010 12:33, schrieb Allan McRae:
Any ideas on this?
-------- Original Message -------- Subject: [arch-notifications] Core/Extra Cleanup 20-05-2010 Date: Thu, 20 May 2010 06:24:50 -0400 (EDT) From: repomaint@archlinux.org Reply-To: List for automated notifications <arch-notifications@archlinux.org> To: arch-notifications@archlinux.org
Scan complete for extra (x86_64) at /srv/ftp/extra/os/x86_64 The following files are missing in the repo %FILENAME%
Looks like a broken database entry. But the output doesn't tell us where exactly it was.
Did this happen more than once?
Only the once. The previous run of the clean-up script ran fine. There were no commits between them... so I guess this is caused by a package moving from someones staging dir in that timeframe.
Am 20.05.2010 13:20, schrieb Allan McRae:
Scan complete for extra (x86_64) at /srv/ftp/extra/os/x86_64 The following files are missing in the repo %FILENAME%
Looks like a broken database entry. But the output doesn't tell us where exactly it was.
Did this happen more than once?
Only the once. The previous run of the clean-up script ran fine. There were no commits between them... so I guess this is caused by a package moving from someones staging dir in that timeframe.
This is where the file name comes from: filename=$(grep -A1 '^%FILENAME%$' "${pkg}/desc" | tail -n1) This would mean that the last line of the 'desc' file is %FILENAME% with no file name following it. I checked the extra x86_64 db, and there is no such entry. *shrugs*
On 20/05/10 21:25, Thomas Bächler wrote:
Am 20.05.2010 13:20, schrieb Allan McRae:
Scan complete for extra (x86_64) at /srv/ftp/extra/os/x86_64 The following files are missing in the repo %FILENAME%
Looks like a broken database entry. But the output doesn't tell us where exactly it was.
Did this happen more than once?
Only the once. The previous run of the clean-up script ran fine. There were no commits between them... so I guess this is caused by a package moving from someones staging dir in that timeframe.
This is where the file name comes from:
filename=$(grep -A1 '^%FILENAME%$' "${pkg}/desc" | tail -n1)
This would mean that the last line of the 'desc' file is %FILENAME% with no file name following it. I checked the extra x86_64 db, and there is no such entry. *shrugs*
The next run worked fine.
Am 20.05.2010 15:32, schrieb Allan McRae:
On 20/05/10 21:25, Thomas Bächler wrote:
Am 20.05.2010 13:20, schrieb Allan McRae:
Scan complete for extra (x86_64) at /srv/ftp/extra/os/x86_64 The following files are missing in the repo %FILENAME%
Looks like a broken database entry. But the output doesn't tell us where exactly it was.
Did this happen more than once?
Only the once. The previous run of the clean-up script ran fine. There were no commits between them... so I guess this is caused by a package moving from someones staging dir in that timeframe.
This is where the file name comes from:
filename=$(grep -A1 '^%FILENAME%$' "${pkg}/desc" | tail -n1)
This would mean that the last line of the 'desc' file is %FILENAME% with no file name following it. I checked the extra x86_64 db, and there is no such entry. *shrugs*
The next run worked fine.
Pierre noticed svn segfaulting during db-update. Looking into dmesg, I saw that both svn and bsdtar segfaulted 10 to 20 times a week over the past 4 weeks (logs don't go back further than that). A bsdtar segfault looks like a likely cause of the above issues. I updated the kernel from 2.6.33.2 to 2.6.33.4 on both gerolde and gudrun (.3 and .4 include a huge number of bugfixes) and rebooted. We'll need to watch if the segfaults still occur.
Am 21.05.2010 10:29, schrieb Thomas Bächler:
Pierre noticed svn segfaulting during db-update.
Looking into dmesg, I saw that both svn and bsdtar segfaulted 10 to 20 times a week over the past 4 weeks (logs don't go back further than that). A bsdtar segfault looks like a likely cause of the above issues.
I updated the kernel from 2.6.33.2 to 2.6.33.4 on both gerolde and gudrun (.3 and .4 include a huge number of bugfixes) and rebooted. We'll need to watch if the segfaults still occur.
I just noticed another svn segfault. Where is this coming from? Any ideas?
On Fri, May 21, 2010 at 11:54 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 21.05.2010 10:29, schrieb Thomas Bächler:
Pierre noticed svn segfaulting during db-update.
Looking into dmesg, I saw that both svn and bsdtar segfaulted 10 to 20 times a week over the past 4 weeks (logs don't go back further than that). A bsdtar segfault looks like a likely cause of the above issues.
I updated the kernel from 2.6.33.2 to 2.6.33.4 on both gerolde and gudrun (.3 and .4 include a huge number of bugfixes) and rebooted. We'll need to watch if the segfaults still occur.
I just noticed another svn segfault. Where is this coming from? Any ideas?
Can you manually run the dbscripts cron jobs? How regular is the segfault?
Am 21.05.2010 19:31, schrieb Aaron Griffin:
On Fri, May 21, 2010 at 11:54 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 21.05.2010 10:29, schrieb Thomas Bächler:
Pierre noticed svn segfaulting during db-update.
Looking into dmesg, I saw that both svn and bsdtar segfaulted 10 to 20 times a week over the past 4 weeks (logs don't go back further than that). A bsdtar segfault looks like a likely cause of the above issues.
I updated the kernel from 2.6.33.2 to 2.6.33.4 on both gerolde and gudrun (.3 and .4 include a huge number of bugfixes) and rebooted. We'll need to watch if the segfaults still occur.
I just noticed another svn segfault. Where is this coming from? Any ideas?
Can you manually run the dbscripts cron jobs? How regular is the segfault?
It was just one since the reboot: May 21 08:09:36 gerolde kernel: svn[8674]: segfault at ffffffff00000008 ip 00007f3be8142eb3 sp 00007fffb8dccd00 error 4 in libapr-1.so.0.4.2[7f3be8131000+2c000] On average, it seems that there were between 2 and 4 segfaults in either svn or bsdtar per day over the last few weeks.
On Thu, May 20, 2010 at 6:25 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 20.05.2010 13:20, schrieb Allan McRae:
Scan complete for extra (x86_64) at /srv/ftp/extra/os/x86_64 The following files are missing in the repo %FILENAME%
Looks like a broken database entry. But the output doesn't tell us where exactly it was.
Did this happen more than once?
Only the once. The previous run of the clean-up script ran fine. There were no commits between them... so I guess this is caused by a package moving from someones staging dir in that timeframe.
This is where the file name comes from:
filename=$(grep -A1 '^%FILENAME%$' "${pkg}/desc" | tail -n1)
This would mean that the last line of the 'desc' file is %FILENAME% with no file name following it. I checked the extra x86_64 db, and there is no such entry. *shrugs*
Maybe it's in package-cleanup now?
participants (3)
-
Aaron Griffin
-
Allan McRae
-
Thomas Bächler