You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just updated Debian from bullseye to bookworm and shortly after that (having called the bookworm version of reprepro successfully from my unchanged scripts) I updated just the reprepro package to the Debian experimental version (5.4.2-1). Immediately my scripts triggered the below error during calls to reprepro includedeb. But after a few repetitions of the same command (I tried to bring up a reproducible case) I suddenly found that the error had stopped from appearing (I did not downgrade in the meantime, reprepro: This is reprepro version 5.4.2).
My gut feeling is that we're looking at a "database" update that crashes in between a "transaction" which no ACID properties, thus after each crash the "old" record is gone, but the "new" record never landed in the "database".
BDB0696 Duplicate data items are not supported with sorted data
Internal error of the underlying BerkeleyDB database:
Within references.db subtable references at put: BDB0067 DB_KEYEXIST: Key/data pair already exists
The text was updated successfully, but these errors were encountered:
After re-reading Issue #18 I realize that calling reprepro check and reprepro export while preparing the bug report may have been the commands that "fixed" the database instead.
I just updated Debian from bullseye to bookworm and shortly after that (having called the bookworm version of reprepro successfully from my unchanged scripts) I updated just the reprepro package to the Debian experimental version (5.4.2-1). Immediately my scripts triggered the below error during calls to
reprepro includedeb
. But after a few repetitions of the same command (I tried to bring up a reproducible case) I suddenly found that the error had stopped from appearing (I did not downgrade in the meantime,reprepro: This is reprepro version 5.4.2
).My gut feeling is that we're looking at a "database" update that crashes in between a "transaction" which no ACID properties, thus after each crash the "old" record is gone, but the "new" record never landed in the "database".
The text was updated successfully, but these errors were encountered: