Comments

23 Comments

NAK, this is a bad design, see https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CWQIAKEI6Q7VJJWNGFSRW7ZR47RLFLGY/

Please DO NOT submit updates to stable releases before this is all settled and agreed upon in rawhide.

BZ#1988902 Add macros.build-constraints

NAK, this is a bad design, see https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CWQIAKEI6Q7VJJWNGFSRW7ZR47RLFLGY/

Please DO NOT submit updates to stable releases before this is all settled and agreed upon in rawhide.

BZ#1988902 Add macros.build-constraints

annobin-9.21-1.fc32.x86_64 got rid of the ICE: errors, but only after "ccache -C"

BZ#1817659 annobin ICE: attempting to access a gcc command line option that is not stored in global_options

Dropped armv7 revert breaking ARMv7 on some devices.

So this isn't actually based on testing, is it?

These are the two patches I dropped in the rebase because they're in 4.15.1 and they're https://github.com/rpm-software-management/rpm/commit/03c56049a92e0f4f22e4e4f582c59c3f4802553d https://github.com/rpm-software-management/rpm/commit/8e70d0ae413a99fedf0d9b1a8469e641a1fb85d5

The third patch that reverts the detection is still in the Fedora package. So this stuff is exactly as it was in F31 GA.

Dropped armv7 revert breaking ARMv7 on some devices.

WHAT? The two dropped reverts are what went upstream as submitted by yourself, and are part of 4.15.1, the third revert that is in Fedora I left alone and is what I complained about upstream. If you applied some totally different patches to Fedora than what went upstream and didn't even bother to mention it upstream, I'm not going to have a whole lot of sympathy.

karma

Working fine here. Certainly better than the non-installable version currently in F30...

BZ#1702062 mscore cannot be installed due to dependency on qt5-qtbase(x86-64) = 5.11.3

@ignatenkobrain, you obsoleted a fairly critical security update with this nice-to-have enhancement update, invalidating the testing on the original package thus delaying it's route to stable, and dropping the security rating on the way. Damage already done on this one, but don't do that again! Please edit the type and severity on this one to security to match the original if bodhi still allows that.

No I can't:

Builds : pmatilai does not have commit access to rpm-ostree

Builds : Update for rpm-ostree-2018.7-3.fc28 already exists

I'd also prefer not to mix up rpm update testing with something else.

Just so that people know where things stand: this should NOT be pushed to stable yet despite the karma target reached already. This needs time and breadth of testing more than positive karma. If nothing comes up, I'll consider stable by end of next week.

Fixes #1532539, thanks for that.

BZ#1532539 [PATCH] Invalid definitions in macros.perl

FWIW the reason for unpushing is the just-emerged https://bugzilla.redhat.com/show_bug.cgi?id=1514608 which looks like a regression in hardlink handling, and the last thing we need right before EOL is a new regression.

This update has been unpushed.

jflory7, this update is not the cause of your problems, something else is. Possibly libsolv appearing older in f27 than f26, but that'd be some cache/mirror artifact because libsolv-0.6.30-1.fc27 exists for F27. But this is not the place to sort out such problems, and adding negative karma to an update pushed to stable already a month ago will not help either.

karma

Working fine based on an evenings worth of general usage.

BZ#1492852 New release (0.8.4) available

adamwill, yup - thanks for pointing it out. New update submitted for F25 (and rawhide).

besser82, do NOT mess with other peoples updates without at least asking first!

This update is very much intentionally sitting in testing still, never mind whatever the karma value.

This update has been unpushed.

pspacek, rpm breaking parallel builds seems unlikely since 4.13.0 consists of very little else than what was already included as patches. A more likely candidate would seem like this change to redhat-rpm-config https://bugzilla.redhat.com/show_bug.cgi?id=1384938:

commit 9a4753b3e469942e4eb29442944838d584f347c0
Author: Jason Tibbitts <tibbs@math.uh.edu>
Date:   Mon Oct 17 13:47:22 2016 -0500

Remove hardcoded limit of 16 CPUs for make -j

You'd have to be using redhat-rpm-config from rawhide to hit that though. But please open a bug on the breakage nevertheless, update comments are terrible for tracking bugs.