[arch-dev-public] Corrupted DBs
http://bugs.archlinux.org/task/8241 It appears some packages built for x86_64 were pushed to the i686 repos. I've manually fixed what I could. Please let me know if any more crop up, and please be more careful in the future. This is the exact reason I'd prefer automated tools for this process - to prevent human error. The following packages were affected: ngrep ntop ssldump tcptraceroute
On Sun, 7 Oct 2007 04:50:53 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote: Hi,
This is the exact reason I'd prefer automated tools for this process - to prevent human error.
as I know, no automated tool from our devtools check if the architecture is right. Just tagging,cvs commits and upload are automated. Ok, normally it uploads to the right directory, but what happen if not. Why don't we check for the architecture in the package file name. Since our db-scripts works with the new filenames, we can check it there. I have looked over the db-inc script and made following changes (no, they are not in the actual script, just my thoughts): -------patch begin--------- --- db-inc 2007-10-07 07:05:45.000000000 -0400 +++ db-inc_new 2007-10-07 07:11:09.000000000 -0400 @@ -93,7 +93,7 @@ # This means the sync db could actually be unpacked/repacked twice in # one db-* invocation, but it's not a huge performance hit. -if [ -d $stagedir/add -a "`ls $stagedir/add`" ]; then +if [ -d $stagedir/add -a "`ls $stagedir/add/*-${arch}.pkg.tar.gz`" ]; then cd $TMPDIR echo "==> Processing new/updated packages for repository '$reponame'..." >&2 @@ -119,7 +119,7 @@ fi # move the package files into the ftp directory - mv -f $stagedir/add/*.pkg.tar.gz $ftppath + mv -f $stagedir/add/*-${arch}.pkg.tar.gz $ftppath fi if [ -d $stagedir/del -a "`ls $stagedir/del`" ]; then @@ -153,7 +153,7 @@ fi # remove the package files - rm -f $stagedir/del/*.pkg.tar.gz + rm -f $stagedir/del/*-${arch}.pkg.tar.gz fi if [ "$updatelists" ]; then ---patch end------ That will move the files only, if the filename has the right architecture. Example: one is uploading foo-1.2-1-i686.pkg.tar.gz to the /home/staging/extra64/add/ directory. Now he runs db-extra64, but the script won't move the package to the ftp dir, because the architecture is wrong. What do you think about it? Daniel
On 10/7/07, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
On Sun, 7 Oct 2007 04:50:53 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
Hi,
This is the exact reason I'd prefer automated tools for this process - to prevent human error.
as I know, no automated tool from our devtools check if the architecture is right. Just tagging,cvs commits and upload are automated. Ok, normally it uploads to the right directory, but what happen if not.
Why don't we check for the architecture in the package file name. Since our db-scripts works with the new filenames, we can check it there.
I have looked over the db-inc script and made following changes (no, they are not in the actual script, just my thoughts):
-------patch begin---------
--- db-inc 2007-10-07 07:05:45.000000000 -0400 +++ db-inc_new 2007-10-07 07:11:09.000000000 -0400 @@ -93,7 +93,7 @@ # This means the sync db could actually be unpacked/repacked twice in # one db-* invocation, but it's not a huge performance hit.
-if [ -d $stagedir/add -a "`ls $stagedir/add`" ]; then +if [ -d $stagedir/add -a "`ls $stagedir/add/*-${arch}.pkg.tar.gz`" ]; then cd $TMPDIR echo "==> Processing new/updated packages for repository '$reponame'..." >&2 @@ -119,7 +119,7 @@ fi
# move the package files into the ftp directory - mv -f $stagedir/add/*.pkg.tar.gz $ftppath + mv -f $stagedir/add/*-${arch}.pkg.tar.gz $ftppath fi
if [ -d $stagedir/del -a "`ls $stagedir/del`" ]; then @@ -153,7 +153,7 @@ fi
# remove the package files - rm -f $stagedir/del/*.pkg.tar.gz + rm -f $stagedir/del/*-${arch}.pkg.tar.gz fi
if [ "$updatelists" ]; then
---patch end------
That will move the files only, if the filename has the right architecture.
Example: one is uploading foo-1.2-1-i686.pkg.tar.gz to the /home/staging/extra64/add/ directory. Now he runs db-extra64, but the script won't move the package to the ftp dir, because the architecture is wrong.
What do you think about it?
This looks great and is exactly what I was thinking. My "automated tool" comment was more of a way to explain why I want to enforce usage of things like extrapkg. I want to see what I can do about breaking our DB scripts out into a git repo, so we can start messing with them. Thanks for the patch, I'll get to it shortly
participants (2)
-
Aaron Griffin
-
Daniel Isenmann