Comments

1260 Comments

@ctubbsii apparently you need permissions on all packages in an update to do stuff to it, so when I edited it to add the dependency, you could no longer manage it. I think we really need a rethink of the Bodhi permissions model, but it's hard to think about what the edges should be. Anyway, I'll push it for now.

I was hoping to hear back from @rdieter , but if we don't soon, we can do that, yeah.

Can folks who seem to be affected by issues with update notification try downgrading fwupd to 1.4.6? See https://bugzilla.redhat.com/show_bug.cgi?id=1896540#c6 .

@rdieter the "immediate movement" has been happening in https://github.com/hughsie/PackageKit/pull/437 . We did some more digging and it seems much less clear that issues with update notification have anything to do with this update, see the tests I ran tonight. Can you check that things reliably work for you with 1.2.2-1 and reliably don't work with 1.2.2-2? I can't say that's the case for me, it seems to be less obvious than that.

Is not installable without a bump to secretstorage. See https://bodhi.fedoraproject.org/updates/FEDORA-2020-06256bf669#comment-1725749 .

BZ#1873845 python-keyring-21.5.0 is available

Is not installable without a bump to secretstorage. See https://bodhi.fedoraproject.org/updates/FEDORA-2020-06256bf669#comment-1725749 .

BZ#1873845 python-keyring-21.5.0 is available
BZ#1873845 python-keyring-21.5.0 is available

This update has been unpushed.

karma

openQA tests on Rawhide suggest this may have broken update check on first login, so I don't think we should push it stable till that is investigated.

It works fine on my test instance, and on lab. It's already been running on lab for several days.

The "unable to serialize" error looks like it comes from this change, but that doesn't seem like it's intended to make anything fatal that wasn't previously fatal. The later errors that seem to be about missing configuration seem more like the problem, but not entirely sure what's going on there.

karma

Per @kalev and @mclasen , depending on mozilla-openh264 is wrong. Recommending it would be OK, but not requiring it.

karma

Per @kalev and @mclasen , depending on mozilla-openh264 is wrong. Recommending it would be OK, but not requiring it.

karma

Per @kalev and @mclasen , depending on mozilla-openh264 is wrong. Recommending it would be OK, but not requiring it.

This should at least have obsoleted the old package names, if not provided them, to prevent --allowerasing being needed to upgrade to Fedora 33.

Hmm. Well, it looks like it and -5 got pushed stable together in the zero-day push. This was pushed 2020-10-23 22:19:59. -5 was pushed 2020-10-23 22:18:47. You'd think this one would've won, but apparently not, -5 did...

We shipped this in RC 1.2 so it needs to go stable. It was not intended to fix the kglobalaccel crash (only to try and stop it breaking logout/login so much), and while it doesn't entirely resolve the logout/login problem, it should at least make it better.

I vaguely remember the whole -gnu thing being some kind of hot debate years ago, but I don't recall the details at all :/

so that'll work just so long as we don't have any lurking packages anywhere that redefine any of those things...:)

karma

I see the problem here.

In the rpm package itself, %_target_platform is defined for each platform in a file under /usr/lib/rpm/platform/, always the same:

[adamw@adam nightlies]$ rpm -ql rpm | grep -v rpmdb.sqlite | xargs strings -f 2>/dev/null | grep -s target_platform
/usr/lib/rpm/platform/aarch64-linux/macros: %_target_platform   %{_target_cpu}-%{_vendor}-%{_target_os}
/usr/lib/rpm/platform/alpha-linux/macros: %_target_platform %{_target_cpu}-%{_vendor}-%{_target_os}
/usr/lib/rpm/platform/alphaev5-linux/macros: %_target_platform  %{_target_cpu}-%{_vendor}-%{_target_os}
/usr/lib/rpm/platform/alphaev56-linux/macros: %_target_platform %{_target_cpu}-%{_vendor}-%{_target_os}
/usr/lib/rpm/platform/alphaev6-linux/macros: %_target_platform  %{_target_cpu}-%{_vendor}-%{_target_os}
/usr/lib/rpm/platform/alphaev67-linux/macros: %_target_platform %{_target_cpu}-%{_vendor}-%{_target_os}

etc. etc. etc. But there is another definition that overrides that one, which may or may not be present on any given system. It's in /usr/lib/rpm/redhat/macros, which is part of the redhat-rpm-config package:

[adamw@adam nightlies]$ grep target_platform /usr/lib/rpm/redhat/macros 
%_target_platform   %{_target_cpu}-%{_vendor}-%{_target_os}%{?_gnu}
[adamw@adam nightlies]$ rpm -qf /usr/lib/rpm/redhat/macros
redhat-rpm-config-172-1.fc33.noarch

That's where the -gnu on the end comes from. If you have redhat-rpm-config package installed, %_target_platform will evaluate to something like x86_64-redhat-linux-gnu. If you don't have it installed, %_target_platform will evaluate to something like x86_64-redhat-linux.

I'm pretty sure that package is always installed during package builds, hence during the build of the package we get the -gnu form and the binaries get installed using that form, as /usr/bin/x86_64-redhat-linux-gnu-pkg-config etc. But the wrapper script is running on the local system, and we can't be sure that the redhat-rpm-config package is installed there; it's not a dependency of anything very critical. In general packagers will have it installed, but otherwise it may very well not be installed.

So the wrapper script cannot really be reliable as written. An ugly hack would be to add the -gnu to the end of the string if it's not there already :/