RPM Fusion update report 2020-07-07
by noreply@rpmfusion.org
RPM Fusion update report
------------------------
Section free:
-------------
Fedora 31
-------------
Pushed to testing:
deadbeef-1.8.4-1.fc31
qmplay2-20.07.04-1.fc31
Pushed to stable:
ffmpeg-4.2.3-6.fc31
gstreamer-plugins-ugly-0.10.19-35.fc31
Fedora 32
-------------
Pushed to testing:
cinelerra-gg-5.1.2020.06-1.fc32
deadbeef-1.8.4-1.fc32
qmplay2-20.07.04-1.fc32
x264-0.159-10.20200409git296494a.fc32
Pushed to stable:
HandBrake-1.3.3-2.fc32
cinelerra-gg-5.1-59.20191231git3878a69.fc32
…
[View More]ffmpeg-4.2.3-6.fc32
gstreamer-plugins-ugly-0.10.19-35.fc32
kodi-18.7-2.fc32
vlc-3.0.11-4.fc32
xine-lib-1.2.10-8.fc32
EL 6
-------------
Pushed to testing:
Pushed to stable:
EL 7
-------------
Pushed to testing:
ffmpeg-3.4.8-1.el7
Pushed to stable:
EL 8
-------------
Pushed to testing:
deadbeef-1.8.4-1.el8
ffmpeg-4.2.3-6.el8
Pushed to stable:
Section nonfree:
-------------
Fedora 31
-------------
Pushed to testing:
unifi-5.13.32-1.fc31
Pushed to stable:
Fedora 32
-------------
Pushed to testing:
unifi-5.13.32-1.fc32
Pushed to stable:
EL 6
-------------
Pushed to testing:
Pushed to stable:
EL 7
-------------
Pushed to testing:
Pushed to stable:
EL 8
-------------
Pushed to testing:
Pushed to stable:
Theses packages will be available in main mirror in a few hours. Wait for local mirrors to sync
Please report any issue to https://bugzilla.rpmfusion.org
[View Less]
4 years, 5 months
RPM Fusion update report 2020-07-04
by noreply@rpmfusion.org
RPM Fusion update report
------------------------
Section free:
-------------
Fedora 31
-------------
Pushed to testing:
gstreamer-plugins-ugly-0.10.19-35.fc31
Pushed to stable:
get_iplayer-3.26-1.fc31
libva-intel-driver-2.4.1-2.fc31
ppsspp-1.10.0-1.fc31
shotcut-20.06.28-1.fc31
vdr-vaapidevice-0.7.0-18.20190526gitd19657b.fc31
Fedora 32
-------------
Pushed to testing:
HandBrake-1.3.3-2.fc32
cinelerra-gg-5.1-59.20191231git3878a69.fc32
ffmpeg-4.2.3-5.fc32
gstreamer-plugins-ugly-0.10.19-35.…
[View More]fc32
kodi-18.7-2.fc32
vlc-3.0.11-4.fc32
xine-lib-1.2.10-8.fc32
Pushed to stable:
get_iplayer-3.26-1.fc32
ppsspp-1.10.0-1.fc32
shotcut-20.06.28-1.fc32
vdr-vaapidevice-0.7.0-18.20190526gitd19657b.fc32
EL 6
-------------
Pushed to testing:
Pushed to stable:
EL 7
-------------
Pushed to testing:
Pushed to stable:
EL 8
-------------
Pushed to testing:
Pushed to stable:
Section nonfree:
-------------
Fedora 31
-------------
Pushed to testing:
Pushed to stable:
steam-1.0.0.64-1.fc31
Fedora 32
-------------
Pushed to testing:
Pushed to stable:
steam-1.0.0.64-1.fc32
EL 6
-------------
Pushed to testing:
Pushed to stable:
EL 7
-------------
Pushed to testing:
Pushed to stable:
steam-1.0.0.64-1.el7
EL 8
-------------
Pushed to testing:
Pushed to stable:
steam-1.0.0.64-1.el8
Theses packages will be available in main mirror in a few hours. Wait for local mirrors to sync
Please report any issue to https://bugzilla.rpmfusion.org
[View Less]
4 years, 5 months
Kodi: joystick peripheral not working?
by Wade Berrier
Hello,
Anyone have any luck with the joystick peripheral addon?
I have PS4 controllers attached via bluetooth, and they work as expected in
Steam.
They haven't worked for a while in Kodi, unfortunately I'm not sure when
they stopped (several months ago?).
Here's what I see in the logs:
2020-07-03 13:51:59.201 T:140146413371840 DEBUG: CAddonSettings[peripheral.joystick]: loading setting definitions
2020-07-03 13:51:59.201 T:140146413371840 DEBUG: CAddonSettings[peripheral.joystick]: …
[View More]loading setting values
2020-07-03 13:51:59.201 T:140146413371840 DEBUG: CSettingsManager: requested setting (driver_sdl) was not found.
2020-07-03 13:51:59.201 T:140146413371840 DEBUG: CAddonSettings[peripheral.joystick]: failed to find definition for setting driver_sdl. Creating a setting on-the-fly...
2020-07-03 13:51:59.201 T:140146413371840 INFO: AddOnLog: Joystick Support: Enabling joystick interface "udev"
2020-07-03 13:51:59.201 T:140146413371840 INFO: AddOnLog: Joystick Support: Disabling joystick interface "udev"
Also, it shows the same "Disabling joystick interface" whether I choose
"Linux" or "udev" for the driver. It almost looks like the driver
supports SDL, but maybe it's not enabled in this build?
Anyone have any ideas?
Thanks,
Wade
[View Less]
4 years, 5 months
Re: [x264/f30: 7/7] Merge branch 'f29' into f30
by Dominik 'Rathann' Mierzejewski
On Friday, 04 October 2019 at 10:23, Nicolas Chauvet wrote:
> Please consider to use cherry-pick next time.
> I don't see the point to compute a merge resolution for the changelog
> because of a single fix.
> This is craziness.
Cherry-picking only makes sense when the branches are too diverged. I
did cherry-pick from f29 to el7 for that reason. The others are more or
less the same. All the fixes that went into all branches should have
been applied to the oldest applicable branch …
[View More]first and then merged
upwards. This wasn't done, hence the current merge commits look uglier
than they could be. They will be much cleaner in the future if this
workflow is followed.
Christopher over at fedora devel list has some valid points in favour of
this way[1]:
Git has excellent branch merging features. Merging branches, rather than
cherry-picking across them, results in commits representing the same
changeset being present in multiple branches, making it easier to search
git history and identify which branches contain a specific change.
Regards,
Dominik
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
[View Less]
4 years, 5 months
Updating Cinelerra-GG version numbering
by FeRD
Robert-André mentioning Cinelerra-GG and reminding me of the need to update
it also brought to mind another issue I wanted to raise.
Since I inherited the package, and in strict accordance with the Fedora
Packaging Guidelines, the package versioning has stored snapshot details in
the RPM Release field for each build, complete with snapshot date and git
commit ID. That makes the NVR of the latest build this unwieldy mess:
cinelerra-gg-5.1-58.20191231git3878a69
As you can see, we're up to …
[View More]release *fifty-eight* of "Cinelerra-GG version
5.1". That is, in part, because the current versioning doesn't accurately
capture the upstream situation.
Cinelerra-GG is a fork of a fork of a project, for all sorts of
organizational and philosophical reasons, and version 5.1 is the upstream
version it was forked from. The source project has moved on ("Cinelerra HV"
is at version 7.2 currently), but in terms of the -GG fork the 5.1 version
number is meaningless. There will likely never be a release of version 5.2,
or 6.0, or whatever. They are equally unlikely to sync back up with any
other fork's version numbering.
This is even tacitly acknowledged by the -GG project. Since September 2018,
Cinelerra-GG has officially been at "version Infinity"[1], and uses a
monthly rolling-release model. A new version is published on the last day
of each month. Since the 2019-08[-30] release, at my request[2], those
monthly releases are published with a YYYY-MM tag in the project Git repo,
satisfying (in my reading) all of the Fedora Packaging Guidelines
requirements for those date tags to be considered upstream version numbers.
As a result, rather than having the "cinelerra-gg-5.1" package continue on
at the same version number until the end of time, receiving ever-increasing
release numbers while we tag new releases as if they're snapshots (when
they're not), I'd like to do the following:
1. Retain the "5.1" version number for consistency's sake, and since
it's still used *internally *by the source code. (The folder name where
the source lives inside the repo is "cinelerra-5.1".)
2. Incorporate the YYYY-MM tag format into the version number, by
translating the dash to a period. The version numbering would follow the
template 5.1.%{git_tag}, AKA 5.1.YYYY.MM.
3. Drop all of the git commit and date info from our the release
numbering, at least for builds made from monthly tagged releases and not
actual snapshots.
As a result, rather than:
cinelerra-gg-5.1-59.20200630gitXXXXXXX
the next update would be:
cinelerra-gg-5.1.2020.06-1
Does anyone have any objections, see any potential issues I've overlooked
that would make this a bad idea, or simply feel I'd be violating the
Packaging Guidelines with this change? Please raise any concerns now, and
I'll alter my plans accordingly.
Does the change require an exception to the standard package version
numbering? In my view it's consistent with Fedora policy[3], but if I need
to formally request an exception I can open a bugzilla ticket for that
request.
[1]: https://en.wikipedia.org/wiki/Cinelerra#Cinelerra-GG_Infinity
[2]: https://www.cinelerra-gg.org/bugtracker/view.php?id=288
[3]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/
[View Less]
4 years, 5 months
RPM Fusion update report 2020-07-01
by noreply@rpmfusion.org
RPM Fusion update report
------------------------
Section free:
-------------
Fedora 31
-------------
Pushed to testing:
get_iplayer-3.26-1.fc31
libva-intel-driver-2.4.1-2.fc31
ppsspp-1.10.0-1.fc31
shotcut-20.06.28-1.fc31
vdr-vaapidevice-0.7.0-18.20190526gitd19657b.fc31
Pushed to stable:
chromium-browser-privacy-83.0.4103.116-1.fc31
Fedora 32
-------------
Pushed to testing:
get_iplayer-3.26-1.fc32
gstreamer-ffmpeg-0.10.13-26.fc32
gstreamer-plugins-base-0.10.36-27.fc32
libva-intel-driver-…
[View More]2.4.1-2.fc32
ppsspp-1.10.0-1.fc32
shotcut-20.06.28-1.fc32
vdr-vaapidevice-0.7.0-18.20190526gitd19657b.fc32
Pushed to stable:
chromium-browser-privacy-83.0.4103.116-1.fc32
gstreamer-0.10.36-27.fc32
EL 6
-------------
Pushed to testing:
Pushed to stable:
EL 7
-------------
Pushed to testing:
Pushed to stable:
EL 8
-------------
Pushed to testing:
Pushed to stable:
buildsys-build-rpmfusion-30-5.el8
Section nonfree:
-------------
Fedora 31
-------------
Pushed to testing:
steam-1.0.0.64-1.fc31
Pushed to stable:
Fedora 32
-------------
Pushed to testing:
steam-1.0.0.64-1.fc32
Pushed to stable:
EL 6
-------------
Pushed to testing:
Pushed to stable:
EL 7
-------------
Pushed to testing:
steam-1.0.0.64-1.el7
Pushed to stable:
nvidia-390xx-kmod-390.138-1.el7
nvidia-kmod-440.100-1.el7
nvidia-modprobe-440.100-1.el7
nvidia-persistenced-440.100-1.el7
nvidia-settings-390xx-390.138-1.el7
nvidia-settings-440.100-1.el7
nvidia-xconfig-440.100-1.el7
xorg-x11-drv-nvidia-390xx-390.138-1.el7
xorg-x11-drv-nvidia-440.100-1.el7
EL 8
-------------
Pushed to testing:
steam-1.0.0.64-1.el8
Pushed to stable:
nvidia-390xx-kmod-390.138-1.el8
nvidia-kmod-440.100-1.el8
nvidia-kmod-440.100-2.el8
nvidia-modprobe-440.100-1.el8
nvidia-persistenced-440.100-1.el8
nvidia-settings-390xx-390.138-1.el8
nvidia-settings-440.100-1.el8
nvidia-xconfig-440.100-1.el8
xorg-x11-drv-nvidia-390xx-390.138-1.el8
xorg-x11-drv-nvidia-440.100-1.el8
Theses packages will be available in main mirror in a few hours. Wait for local mirrors to sync
Please report any issue to https://bugzilla.rpmfusion.org
[View Less]
4 years, 5 months