This reverts commit 985a14100295c99d0c6d712bfbee0ec52a3a1601.
Reverting for now due to some users experiencing no boot entries after
upgrading. See for background:
https://github.com/ostreedev/ostree/pull/1929https://discussion.fedoraproject.org/t/boot-entries-gone-after-upgrade/8026
---
Seems silly to revert this by an additional patch, instead of dropping
the patch that enabled it in the first place. Though I think this
approach has a higher chance of the revert not being accidentally
dropped when doing the next rebase.
Got rpmdiff complaining that the `ostree` and `ostree-tests` packages do
not have an explicit `Requires` on the libraries. Now, symbol versioning
assures us that e.g. the -libs version that we pull for a given `ostree`
package will have the symbols we need, but it doesn't guarantee that
they'll be the exact same version. Let's add the explicit `Requires` to
make this clear since in practice we don't want to have to think about
such mismatches.
I've also taken the opportunity to normalize on the usage of `_isa` and
`epoch` in all the `Requires`.
Doing this before the upstream PR[1] gets merged because upstream CI
needs to be able to build RPMs, which uses this. Anyway, the glob is
kept general so it's equally valid even without path.
[1] https://github.com/ostreedev/ostree/pull/1740
We weren't shipping it in RHEL7 either. It also brings in a dependency
on Python, which is tricky there. (And anyway
`gnome-desktop-testing-runner` isn't even packaged there).
Make it a bcond though so one can still build it if one desires. (And
symmetrically, to *not* build it on Fedora if one desires).
I'm beating Colin to the punch here and making use of the new
`--disable-http2`. What pushed me over the edge was the fact that I
literally could not upgrade my Atomic Workstation with a simple
`rpm-ostree upgrade` without hitting:
https://github.com/ostreedev/ostree/issues/1362
I originally thought this only occurred in low-bandwidth environments,
when in fact it still happens even after upgrading my Internet bundle
and can actually be reproduced very easily in environments where
bandwidth is not an issue. E.g. this currently hangs in the latest
Fedora 27 Atomic Host provisioned in the cloud:
ostree remote add --no-gpg-verify faw27 https://dl.fedoraproject.org/ostree/27/
ostree pull faw27 fedora/27/x86_64/workstation
Until we investigate deeper, let's just play it safe and disable HTTP2.
This should also fix the HTTP2 framing layer people have been hitting.
Let's get this in to confirm it doesn't break the rdgo streams, and then
we can backport the patch for f27 to make sure it gets into the next
TWR?
