stable

rpm-4.17.1-2.fc36

FEDORA-2022-763dfc66f1 created by mdomonko 2 years ago for Fedora 36

Rebase to rpm 4.17.1 (http://rpm.org/wiki/Releases/4.17.1)

Note: During the first DNF transaction following the one in which this update is applied, a spurious warning will be shown if you run DNF in --verbose mode: RPMDB altered outside of DNF. You may ignore this warning as it's caused by a change in the algorithm used to generate the RPMDB hash.

How to install

Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:

sudo dnf upgrade --refresh --advisory=FEDORA-2022-763dfc66f1

This update has been submitted for testing by mdomonko.

2 years ago

This update's test gating status has been changed to 'waiting'.

2 years ago

mdomonko edited this update.

2 years ago

This update's test gating status has been changed to 'failed'.

2 years ago

This update's test gating status has been changed to 'waiting'.

2 years ago

This update's test gating status has been changed to 'passed'.

2 years ago

This update has been pushed to testing.

2 years ago
User Icon bojan commented & provided feedback 2 years ago
karma

Works.

User Icon pawef9 provided feedback 2 years ago
karma

This update can be pushed to stable now if the maintainer wishes

2 years ago
User Icon andilinux commented & provided feedback 2 years ago
karma

works

User Icon andilinux commented & provided feedback 2 years ago
karma

works

User Icon imabug provided feedback 2 years ago
karma
User Icon ibims commented & provided feedback 2 years ago
karma

LGTM.

User Icon ozeszty commented & provided feedback 2 years ago
karma

During the next update after installing this one I noticed in dnf output RPMDB altered outside of DNF, that's expected and not an indication of some tampering with my system, right?

karma

no issues

User Icon churchyard commented & provided feedback 2 years ago
karma

Trying to reproduce the same problem as in FEDORA-2022-37913de00f:

$ fedpkg clone python3.11
$ cd python3.11
$ fedpkg --release rawhide prep
...
Switched to branch 'rpm-build'
+ /usr/bin/git branch --set-upstream-to=master
branch 'rpm-build' set up to track 'master'.
...
+ exit 0

Turns out, it's config dependent:

$ git config --global init.defaultBranch main
$ fedpkg --release rawhide prep
...
Switched to branch 'rpm-build'
+ /usr/bin/git branch --set-upstream-to=master
fatal: the requested upstream branch 'master' does not exist
hint: 
hint: If you are planning on basing your work on an upstream
hint: branch that already exists at the remote, you may need to
hint: run "git fetch" to retrieve it.
hint: 
hint: If you are planning to push out a new local branch that
hint: will track its remote counterpart, you may want to use
hint: "git push -u" to set the upstream config as you push.
hint: Disable this message with "git config advice.setUpstreamFailure false"
error: Bad exit status from /var/tmp/rpm-tmp.nlgSCi (%prep)

This update has been unpushed.

Similarly to FEDORA-2022-37913de00f, a fix is on the way.

mdomonko edited this update.

New build(s):

  • rpm-4.17.1-2.fc36

Removed build(s):

  • rpm-4.17.1-1.fc36

Karma has been reset.

2 years ago

This update has been submitted for testing by mdomonko.

2 years ago

@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.

@mdomonko there are no asterisks after end hash from that update on my computer.

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

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.

This update has been submitted for testing by mdomonko.

2 years ago
User Icon imabug provided feedback 2 years ago
karma

This update has been pushed to testing.

2 years ago

mdomonko edited this update.

2 years ago

mdomonko edited this update.

2 years ago

This update's test gating status has been changed to 'failed'.

2 years ago

This update's test gating status has been changed to 'passed'.

2 years ago
User Icon mhayden commented & provided feedback 2 years ago
karma

Working fine.

This update can be pushed to stable now if the maintainer wishes

2 years ago

This update has been submitted for stable by mdomonko.

2 years ago
User Icon ozeszty provided feedback 2 years ago
karma
User Icon ozeszty commented & provided feedback 2 years ago
karma

@mdomonko I hope I haven't wasted your time.

@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.

This update has been pushed to stable.

2 years ago

Please login to add feedback.

Metadata
Type
bugfix
Karma
3
Signed
Content Type
RPM
Test Gating
Autopush Settings
Unstable by Karma
-3
Stable by Karma
disabled
Stable by Time
disabled
Dates
submitted
2 years ago
in testing
2 years ago
in stable
2 years ago
modified
2 years ago

Automated Test Results