Just a comment after reading #516578 - there is no indication that reprepro is seg faulting with these errors, these are "normal" reprepro errors where checksums fail and every time, reprepro has quit normally (AFAICT) and left the lockfile behind.
Building libc6-dev_2.7-18em1_i386.deb in /opt/reprepro/grip/incoming
dpkg-deb: building package `libc6-dev' in
`/opt/reprepro/grip/incoming/libc6-dev_2.7-18em1_i386.deb'.
ERROR: '/opt/reprepro/grip/incoming/libc6-dev_2.7-18em1_i386.deb' cannot be
included as 'pool/main/g/glibc/libc6-dev_2.7-18em1_i386.deb'.
Already existing files can only be included again, if they are the same, but:
md5 expected: 389f4d699e2f387fe3b085ec93da921b, got:
c4d7e16626ef5a62400c2baf6e8974ca
sha1 expected: 25c59c1fef6a2b76b769a13d7ce6abd640a8f527, got:
8cd7d34d0f998350b5033de07c361dcdd152c4c2
sha256 expected:
1df620c8d3944b53f7afd2bab8355517330c496ea8af409ac37f311733ea2fdc, got:
76f8fced24edc16920265a58e0521263c4cfd3c0848ebddc5a68cd8
a5254832d
size expected: 3257304, got: 3257302
There have been errors!
dpkg-architecture: warning: Specified GNU system type i486-linux-gnu does not
match gcc system type x86_64-linux-gnu.
Building libc6-i686_2.7-18em1_i386.deb in /opt/reprepro/grip/incoming
dpkg-deb: building package `libc6-i686' in
`/opt/reprepro/grip/incoming/libc6-i686_2.7-18em1_i386.deb'.
dpkg-architecture: warning: Specified GNU system type i486-linux-gnu does not
match gcc system type x86_64-linux-gnu.
Building locales_2.9-2em1_all.deb in /opt/reprepro/grip/incoming
dpkg-deb: building package `locales' in
`/opt/reprepro/grip/incoming/locales_2.9-2em1_all.deb'.
ERR: reprepro has locked /opt/reprepro/grip - removing
at /usr/bin/em_autogrip line 432
The script now checks for a lockfile immediately before making the next
call to reprepro and deletes it by force - which is making me nervous.
I'm logging the current output of the script that is updating the local
repo and each time reprepro is asked to include a .deb where it already
had the same version with a different checksum, I get a complaint from
the script that the lockfile still exists when the next reprepro
command is issued several seconds later.
I have to check for the lockfile in three places in the code, so the
log now includes details of what the script was doing when the lockfile
was found:
ERROR: '/opt/reprepro/grip/incoming/acpi-support-base_0.109-11em1_all.deb'
cannot be included as 'pool/main/a/acpi-support/acpi-support-base_0.
109-11em1_all.deb'.
Already existing files can only be included again, if they are the same, but:
md5 expected: 6b28df4abf8e50f2ed41b4160905cb8b, got:
ba54f3ae071ce4838e5f0bde4e057141
sha1 expected: a44d321331cb940c770c0e89d296c1a90fd98835, got:
8c6a69e665cce2d39fca56f0bf1cd888a0384943
sha256 expected:
92ded78d200ed98c6e0836c5f3ed8401e3bd73286574e276bd0dedaa899aa432, got:
1f1ee38ba2930521a4e56ebf2b3ab3af30ec9a49354660d4b2e2e17
7664a40ed
size expected: 4354, got: 4356
There have been errors!
INF: cleaning grip incoming directory
INF: Adding coreutils
INF: Preparing to add single coreutils binary (6.12-2)
Building coreutils_6.12-2em1_amd64.deb in /opt/reprepro/grip/incoming
dpkg-deb: building package `coreutils' in
`/opt/reprepro/grip/incoming/coreutils_6.12-2em1_amd64.deb'.
ERR: reprepro has locked /opt/reprepro/grip - removing lockfile {grip_binary}
at /usr/bin/em_autogrip line 432
Here the lockfile was found after an error, when the time came to
process the next package built. (The actual reprepro STDOUT output is
not captured by the script, only STDERR).
A worrying listing is this one:
ERROR: '/opt/reprepro/grip/incoming/coreutils_6.12-2em1_i386.deb' cannot be
included as 'pool/main/c/coreutils/coreutils_6.12-2em1_i386.deb'.
Already existing files can only be included again, if they are the same, but:
md5 expected: 81a89c9ee67748dc33b9c47c20092833, got:
57d01d11e50d609d1e7045d454995607
sha1 expected: 6fef809a84faff324e64336180370f293e6e75e0, got:
f49c73b41e35b521ccc97532d97b270a417bd10f
sha256 expected:
f8a3c02bc8dafa00157b88e5508b02243f63dd5a1fe840e1509b61b74ab10b5c, got:
a09642993b220a11004f5c2f478ba4f2d4498022a34d0ffbb84a64802e9953cb
size expected: 1519060, got: 1519062
There have been errors!
INF: Preparing to add single coreutils binary (6.12-2)
dpkg-architecture: warning: Specified GNU system type mips-linux-gnu does not
match gcc system type x86_64-linux-gnu.
Building coreutils_6.12-2em1_mipsel.deb in /opt/reprepro/grip/incoming
dpkg-deb: building package `coreutils' in
`/opt/reprepro/grip/incoming/coreutils_6.12-2em1_mipsel.deb'.
dpkg-architecture: warning: Specified GNU system type mips-linux-gnu does not
match gcc system type x86_64-linux-gnu.
Building coreutils_6.12-2em1_mips.deb in /opt/reprepro/grip/incoming
dpkg-deb: building package `coreutils' in
`/opt/reprepro/grip/incoming/coreutils_6.12-2em1_mips.deb'.
ERR: reprepro has locked /opt/reprepro/grip - removing lockfile {grip_binary
foreach} at /usr/bin/em_autogrip line 432
ERR: reprepro has locked /opt/reprepro/grip - removing lockfile {grip_binary}
at /usr/bin/em_autogrip line 432
INF: Preparing to add single coreutils binary (6.12-2)
dpkg-architecture: warning: Specified GNU system type mipsel-linux-gnu does not
match gcc system type x86_64-linux-gnu.
Building coreutils_6.12-2em1_mipsel.deb in /opt/reprepro/grip/incoming
dpkg-deb: building package `coreutils' in
`/opt/reprepro/grip/incoming/coreutils_6.12-2em1_mipsel.deb'.
ERR: reprepro has locked /opt/reprepro/grip - removing lockfile {grip_binary}
at /usr/bin/em_autogrip line 432
INF: Preparing to add single coreutils binary (6.12-2)
dpkg-architecture: warning: Specified GNU system type powerpc-linux-gnu does
not match gcc system type x86_64-linux-gnu.
Building coreutils_6.12-2em1_powerpc.deb in /opt/reprepro/grip/incoming
dpkg-deb: building package `coreutils' in
`/opt/reprepro/grip/incoming/coreutils_6.12-2em1_powerpc.deb'.
INF: cleaning grip incoming directory
There, a standard reprepro command:
reprepro -b ${base}${grip_name} includedeb $suite
${base}${grip_name}/incoming/$f
has not produced error output, yet the lockfile is left behind because
the very next call to the same function (grip_binary) generates a
message that the lockfile had to be removed. This repeats later when
grip_binary is again in use when the lockfile needs to be removed.
Maybe it's not just on error, maybe reprepro is leaving lockfiles around at
other times?
Is reprepro exiting before processing is complete? Does reprepro
control the lockfile directly? The same log now appears to be showing
that even checksum errors do not always leave the lockfile in place.
I'll attach the log (compressed), once the run is complete and I've had
a chance to put the modified scripts into SVN so that you can follow
what the scripts are doing.
Current scripts are available using the following:
$ sudo apt-get install emdebian-tools
$ sudo apt-get update
$ sudo apt-get dist-upgrade
$ sudo apt-get install emdebian-grip-server
That should leave you with emdebian-tools 1.4.16 (1.5.0 is waiting in
NEW) and the scripts are in the emdebian-grip-server package.
SVN is at:
http://buildd.emdebian.org/svn/browser/current/host/trunk/emdebian-tools/trunk/grip
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgps70gIrG8Uc.pgp
Description: PGP signature
