I've just hit this bug myself and did some digging to figure out what's
going on.
When BerkleyDB is told to open "packages.legacy.db" it uses the
previous state information and actually tries to open "packages.db",
which does not exist at the time. Reprepro takes a path that makes it
treat it as a
Hi Steve,
Am 05.10.23 um 12:50 schrieb Steve McIntyre:
I've got time to debug this issue now, happy to help however...
Please have a look at #1051537. That might be related.
I did not have the time to look at the proposed patch and would be happy if you
tested that.
Thanks,
Bastian
Am 06.09.22 um 15:24 schrieb L.P.H. van Belle:
*( why do we need reprepro 5.4.1-1 )
It is experimental because it has a major feature that needs the db upgrade:
multiple versions of one package in the same repo.
It is your choice to install experimental packages. You decide whether you need
t
I can confirm this also.
I tested stretch reprepro upgrades upto testing..
All my reprepro databases corrupted, im now rebuilding it all again.
*( why do we need reprepro 5.4.1-1 )
I compile for Debian and Ubuntu, I needed the latest version to get the Ubuntu
packages in.
Greetz,
Louis
Package: reprepro
Version: 5.4.1-1
Severity: important
Tags: upstream
Hello,
I recently tested an upgrade of reprepro from the version in bullseye
(5.3.0-1.2) to the experimental version (5.4.1-1) to allow us to use
the Limit feature.
After the database migration, no packages are found in the da
5 matches
Mail list logo
