On Sun 16 Dec 2018 at 14:46:54 +0100, Rhialto wrote:
> regpkg: ERROR: The metalog file (/vol1/rhialto/destdir.amd64/METALOG.sanitised) does not
> contain entries for the following files or directories
> which should be part of the base-util-root syspkg:
> ./bin/\133
> --- makesyspkgs ---
> *** [makesyspkgs] Error code 128
> nbmake[1]: stopped in /mnt/vol1/rhialto/cvs/src/distrib/sets
> 1 error
From the cvs history, I see that the last struggle with this was in 2014.
Here is a potential patch:
Index: join.awk
===================================================================
RCS file: /cvsroot/src/distrib/sets/join.awk,v
retrieving revision 1.6
diff -u -r1.6 join.awk
--- join.awk 24 Oct 2014 22:19:44 -0000 1.6
+++ join.awk 16 Dec 2018 15:08:42 -0000
@@ -30,6 +30,8 @@
# join.awk F1 F2
# Similar to join(1), this reads a list of words from F1
# and outputs lines in F2 with a first word that is in F1.
+# For purposes of matching the first word, both instances are
+# canonicalised via unvis(word); the version from F2 is printed.
# Neither file needs to be sorted
function unvis(s) \
@@ -79,17 +81,16 @@
exit 1
}
while ( (getline < ARGV[1]) > 0) {
- $1 = unvis($1)
- words[$1] = $0
+ f1 = unvis($1)
+ words[f1] = $0
}
delete ARGV[1]
}
-// { $1 = unvis($1) }
+{ f1 = unvis($1) }
-$1 in words \
+f1 in words \
{
- f1=$1
$1=""
print words[f1] $0
}
This join.awk script is used to take the file names that are in a
PLIST-type file and select just those same lines from the METALOG file.
I think that the issue was that the join.awk script would unvis() the
file names in all cases.
The PLIST would have /bin/[ (which is vis()ed to \133 at regpkg:810 to
spec1) and the METALOG would have /bin/\133 too. The resulting output
metalog-type file spec2 would contain the unvis()ed /bin/[ again. This
would happen at cvs/src/distrib/sets/regppkg line 818.
Then after that there would be a check at regpkg:836 which compares if
spec1 and spec2 contain the same names, but this is not the case since
one of them is unvis()ed. Hence the error message, which for our
purposes is likely spurious.
I fix the undesired unvis()ing in the first chunk of the diff. As it
was, changing $1 (the first field of the line) changes $0, the line as a
whole. Then the unvis()ed line from the METALOG is stored (and maybe
later printed). Using a temporary to store the unvis()ed version, to be
used as the key, preserves the original version.
Likewise, in the remaining changes, I reinstate the unvis() call, but
also use a temporary for cleanness.
So this presumes that the METALOG file is properly vis()ed, but I think
that is a fairly safe assumption.
Comments? Ok to commit?
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power
\X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond
Attachment:
signature.asc
Description: PGP signature