I have to report the same as Hans before - I just cannot find the 'retire'
functionality anywhere nearby
and in addition, rfpkg doesn't work for me
so I did the steps manually
I know there's a lot of work to be done to make the infrastructure perfect
and too few helping hands, but if things cannot be fixed now, then - pretty
please with sugar on top - at least fix/temporarily change the docs so the
wiki lists just what really works now (or mark things "not ready yet, don't
try that"), and on the list, don't refer people to undocumented things (if
it can be used, it should be documented)
BaseOS QE - Daemons
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
:: "Never attribute to malice what can
:: easily be explained by stupidity."
So every new packages now go to f25 updates repos.
A recall of the updates policy https://fedoraproject.org/wiki/Updates_Policy
Please concentrate on devel for new content.
I would just mention that there were an issue with mpg123 that is not
in our f25-free GA repos despite it would need to be there to avoid
breaking dependencies we GA tree.
The workaround for downsteam remix is to grab the package from Fedora
updates (or updates-testing currently).
If you install from kickstart and do not want to enable updates repos,
you should disable mpg123 dependencies or get a dedicated repository
with the package from Fedora in it.
Nicolas, ask me to bring this discussion to the mailing list .
Nicolas sorry for the delay , I had a big cold, I'm ok now (it just an
excuse :) )
OK, all story is in
and in https://bugzilla.rpmfusion.org/show_bug.cgi?id=4145
and we have 48 packages depends on ffmpeg-libs.
First, ABI changes of ffmpeg 3.0.x to 3.1.x ?
"There are no SONAME changes, only new symbols added to the libraries,
so they're backwards compatible and no rebuild of dependencies should
be required" . "mpv will break" .
My arguments, I read today
http://fedoraproject.org/wiki/Updates_Policy#All_other_updates and it
have one exceptions list, we have some items that can be applied to
this case, like :
- The update doesn't change ABI/API and nothing needs to be rebuilt
against the new version. (almost)
- The update fixes serious bugs that many fedora users are
ffmpeg-3.0 is a major version that had short duration, it was the first
version of an major version (3.0.x), so we expect have more bugs, also
vlc now requires ffmpeg 3.1.x and we have to maintain it about more 9
months (F24 be an fresh version also counts).
Finally Nicolas wrote: "I'm sure we should have a decision better
sooner than later about this (...) I'm reserving my last arguments for
the mailing list".
I hope have one decision, quickly and close this subject (update ffmpeg
in F24 to 3.1.x ? ).
Sérgio M. B.
Just a quick note that I've made a package push today.
(and reverted the ffmpeg update to 3.1.x in f24 because of report: rfbz#4334).
On a side note this time the repo was generated with newer tools, so
in short it should be a step forward to have support for weak
dependencies in RPM Fusion. (or maybe it even fixed it).
If your package already use weak dependencies, it should now take
effects in the current repos from f23/f24 updates and f25/rawhide.
Please reminds that rich dependencies or boolean dependencies are
still not allowed per Fedora Guidelines IIRC.
If any side effects, please report an infrastructure bug.
I'm going to remove the ARM build for Kodi unless someone can give me a compelling
reason to keep it. The Kodi build has never worked even if it was successfully building.
You have to tell Kodi at compile time what graphics processor you want to support.
One build of Kodi only supports one ARM graphics engine. I didn't see this until I
was trying to fix the broken ARM build this week. Up until now Kodi was compiling
with AMLogic support (Mali GPUs) and since we don't ship the graphics driver this
build would never work if someone tried to use Kodi on a Fedora ARM install.
2016-11-21 12:33 GMT+01:00 David Timms <dtimms(a)rpmfusion.org>:
> Summary of changes:
> 9064cb5... rebuild for ffmpeg-3.0.3 (*)
> (*) This commit already existed in another branch; no separate mail sent
@David, please commit in the devel branch first next time.
then merge back to older branches if you want to stay in sync in all
your branches including keeping history of patches in the same order.
Now you can only cherry-pick from devel to older branches until we fork
I really would like to have this build in time for f25 GA...