Comments

19 Comments
karma

Works

You're welcome! And thanks for the feedback!

Anyway, thank you everyone for the karma points, I'm pushing this one to stable now.

@g6awk, the warnings are caused by packages using the deprecated Lua functions in their scriptlets/triggers, really, it's not a bug in the Lua functions themselves.

You are probably referring to #3270 which indeed didn't make it to 4.20.0, however all it does is silence the warnings for packages that were built with RPM < 4.20.0.

That means, even though the warnings would be gone for a while, they would come back as soon as the affected (and still unfixed) packages are rebuilt with RPM 4.20.0.

No worries, you're welcome!

The utility actually is included in the rpm-build package. Please note, however, that it's not installed into the default $PATH but rather into the /usrl/ib/rpm/ directory as it's a low-level tool, not really meant for end users. The Release Notes do mention this but we should probably clarify them a bit more (making a note here, thanks!).

This update has been unpushed.

Just FTR, I've requested an unpush/revocation via https://pagure.io/releng/issue/11837 because of the push to stable being rushed (the update was only created yesterday). Apologies for the noise related to that.

This update has been unpushed.

This build is based on the same git snapshot as the previous (rc1), with a small compilation regression fix on top: https://github.com/rpm-software-management/rpm/commit/34d983fa2a9b9276fc540b6bd554605b2c72689a

@ozeszty, oh, quite the opposite! Thanks again for noticing this, people might be confused by it so we'd better have a note somewhere. I've added one in the update description (in case somebody actually reads it) and also in the release notes on rpm.org.

OK, it turns out the ** is an undocumented marker that comes from DNF and indicates that the RPMDB was altered outside of DNF, just like the verbose output says during the subsequent transaction.

The reason DNF considers it "altered" is simply that the hash function used by RPM has changed (not the underlying data). This could easily be "fixed" in DNF by making sure the two hashes being compared are of the same length, but since the message only shows in --verbose mode and the double asterisk marker in the "dnf history info" output is only transient, it's probably not worth obsessing over.

The hash returned from the RPM API is a C string and it's handled like that in both libdnf and DNF (I've checked the code) so no assumptions are made about its length that would have to be adapted in DNF. I'm moving this update back to testing now.

Yeah, the asterisks get removed from that hash after the next transaction, for some reason.

@ozeszty, this is indeed strange, thanks for the report. I suspect the warning has to do with us bumping the RPMDB cookie (a hash) to from SHA1 to SHA256 in this release: https://github.com/rpm-software-management/rpm/commit/1db8004b3bcbf073257b4a059915001d512e0686

That said, I can't reproduce this myself. However, looking at dnf history info last after this update, the "End rpmdb" hash indeed looks strange (note the double ** at the end):

# dnf history info last
Transaction ID : 13
Begin time     : Mon 11 Jul 2022 11:44:45 AM EDT
Begin rpmdb    : d45b12fd3dedbf082548dcdccba6f0d3344ab5df
End time       : Mon 11 Jul 2022 11:44:47 AM EDT (2 seconds)
End rpmdb      : fa29c830d06b5fe14cbb5ddd2e064f9772713122 **
[...]

I'll need to investigate further, it might be that DNF or RPM is accessing uninitialized memory when reading/writing the cookie before/after the transaction due to the expected length being changed. Until then, I'm revoking this update so that we stay on the safe side.

This update has been unpushed.

Thanks Miro, I'm going to issue a fixed build.

This update has been unpushed.

Generating an HTML summary works properly now.