November 2018 - rpmfusion-developers

OpenShot dependencies not in EL7: rpmfusion or Fedora/EPEL?

by FeRD

Since EL7 ffmpeg is getting some attention, I thought I'd take the opportunity to revisit something I've been sitting on for a couple of months now, because I'm at an impasse. This started with Sergio, but fell to me when I took over maintenance of OpenShot, and I've taken it as far as I can... but I'm unsure how to proceed, now. It's a little convoluted, so I apologize that this gets long. We've long wanted to bring OpenShot to EL7, the problem is its dependencies. EPEL doesn't package PyQt5 (python3-qt5), and the reason is that they don't package SIP for Python 3 (python3-sip) which it requires. However, EPEL *does* contain SIP for Python 2 (as python-sip) — but *only* the Python 2 build is packaged, and at an ancient version that wouldn't support our PyQt5 anyway. So, because we need PyQt5 for OpenShot, and we need a Python 3 SIP for PyQt5, we need to package both of those up ourselves. Which gets even trickier, because our Python 3 SIP isn't allowed to interfere with the existing EPEL python-sip. The advice Rex Dieter gave Sergio @epel-devel was that it has to be a completely separate package, of just the Python 3 build, installable alongside the existing (different-version) python-sip. [1] In fact (as I eventually worked out), it has to be a completely *customized* package. The macros SIP installs (/usr/lib/rpm/macros.d/macros.sip from sip.rpm, usually shared between python2-sip and python3-sip) have to be placed in a different file, *and *they all have to be renamed, so that macros.python3-sip doesn't override macros.sip. And then, because of that, the python3-qt5.spec for EL7 also has to be completely different from the standard Fedora python-qt5.spec: The python2 build had to be removed entirely. (It couldn't simply be skipped, because it was "primary" and some shared files were only generated during that phase.) Then the python3 build had to be made "primary", and modified to use a different set of SIP macro names from our macros.python3-sip. Long story short, I've done all that work. The repos for the customized packages are here: SIP: https://github.com/ferdnyc/el7-python3-sip PyQt5: https://github.com/ferdnyc/el7-python3-qt5 and both packages are built for EPEL (ppc64le and x86_64) in COPR: python3-sip: https://copr.fedorainfracloud.org/coprs/ferdnyc/python3-sip/ python3-qt5: https://copr.fedorainfracloud.org/coprs/ferdnyc/python3-qt5/ *My question now becomes, are these modified packages eligible for inclusion in... I don't even really know how EL7 packaging works, would it be inclusion in Fedora? Inclusion in EPEL? Or can they live in rpmfusion?* If they can go into rpmfusion, because they're un-provided dependencies for one of our packages, then great. I can open review bugs and start that process. But if they need to go into Fedora/EPEL/whatever, I'm not a packager there yet (I started that process, but wasn't able to make time to complete it), so perhaps someone else can shepherd them through that part of the process? [1]: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj...

6 years, 1 month

3
3
0 / 0

Re: [chromium-freeworld/f27] AUTO IMPORT FEDORA:70.0.3538.77; No. of merged commits:4

by Dominik 'Rathann' Mierzejewski

Hi, On Sunday, 11 November 2018 at 08:07, hellbanger wrote: > commit 0df91d8e7a37ac3b4ee23ba44f5c8d869f4670e5 > Author: Akarshan Biswas <akarshan.biswas(a)gmail.com> > Date: Sun Nov 11 12:37:15 2018 +0530 > > AUTO IMPORT FEDORA:70.0.3538.77; No. of merged commits:4 Why aren't you merging properly, with Fedora commits visible in RPMFusion git history? This way makes it difficult to see the differences between Fedora and RPMFusion package. Regards, Dominik -- Fedora https://getfedora.org | RPMFusion 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

6 years, 1 month

3
3
0 / 0

Re: Upgrading EL7 with a newer ffmpeg

by Sergio

Yes , my work now is incompatible with open source development , sorry. Sent from my AndroidEm 11/11/2018 1:44 da tarde, Antonio Trande <anto.trande(a)gmail.com> escreveu: > > Do you need a packager for FFmpeg on el7? > > On 11/11/18 12:52, Nicolas Chauvet wrote: > > Le ven. 21 sept. 2018 à 21:01, Nicolas Chauvet <kwizart(a)gmail.com> a écrit : > >> > >> 2018-09-21 20:54 GMT+02:00 Sérgio Basto <sergio(a)serjux.com>: > >> > >>> > >>> I have one vm with epel 7 , have you any scratch build (or src.rpm) ? > >>> what you mean or where are "forwarded the patches" ? > >> The patches to compile ffmpeg 3.3 in el7 are available into the f27 branch. > >> So you can submit a scratch build for el7 based on the fc27 branch as a start. > > > > Still anyone to be able to work on this ? > > Thx > > > > -- > --- > Antonio Trande > Fedora Project > mailto 'sagitter at fedoraproject dot org' > GPG key: 0x5E212EE1D35568BE > GPG key server: https://keys.fedoraproject.org/ > > _______________________________________________ > rpmfusion-developers mailing list -- rpmfusion-developers(a)lists.rpmfusion.org > To unsubscribe send an email to rpmfusion-developers-leave(a)lists.rpmfusion.org

6 years, 1 month

1
0
0 / 0

Introducing new koji rpmfusion namespace : cuda

by Nicolas Chauvet

I've just introduced a new namespace: cuda The intend is to be able to build cuda only applications or applications that can have cuda options. The (same than rpi) idea is to have few packages to be introduced in this repo and allow to use a symlink to the free(or nonfree) SCM URL for packages that need optimized version, such as ffmpeg, etc Thoses build will end with a specific dist tag: fc29cuda (1) and only built on x86_64 (for now, but we may have ppc64le or aarch64 support if relevant). The intend is to start with the cuda namespace with only the master branch using cuda 10.0, but we may introduce others branches for cuda-9.2 (or even cuda-9.0 at the oldest). The "first" idea is to drop the fedora/el branch to only maintain This cuda buildroot will use the official cuda package from nvidia official repositories (altought a local mirror without their messy packaged driver). This is still an open question to re-package the cuda compiler in our repo. The first step is to avoid a duplicate work. The buildroot will default to define %global _with_cuda 1, so current rpmfusion packages in the free section using this rpm conditional will enable the relevant features (ffmpeg already support that if one wants to have a look). The repository will contains few specifics packages for the cuda that may replace fedora/rpmfusion counterparts (with a higher dist). Same as rpi feature: I really would like someone interested in to take over the packaging work of this feature. (1), It's still questionable if the dist should have cuda10.0 or cuda9.2 given the idea would be to maintain older cuda version until relevant -- - Nicolas (kwizart)

6 years, 1 month

1
1
0 / 0

RPM Fusion update report 2018-11-10

by noreply＠rpmfusion.org

RPM Fusion update report ------------------------ Section free: ------------- Fedora 27 ------------- Pushed to testing: VirtualBox-5.2.22-1.fc27 VirtualBox-kmod-5.2.22-1.fc27 Pushed to stable: Fedora 28 ------------- Pushed to testing: VirtualBox-5.2.22-1.fc28 VirtualBox-kmod-5.2.22-1.fc28 chromium-freeworld-70.0.3538.77-1.fc28 Pushed to stable: Fedora 29 ------------- Pushed to testing: VirtualBox-5.2.22-1.fc29 VirtualBox-kmod-5.2.22-1.fc29 chromium-freeworld-70.0.3538.77-2.fc29 gstreamer1-plugins-ugly-1.14.4-2.fc29 mixxx-2.2.0-0.4.rc.20181106gitfaf1a67.fc29 x264-0.155-2.20180806git0a84d98.fc29 Pushed to stable: kodi-18.0-0.16.b5.fc29 EL 6 ------------- Pushed to testing: Pushed to stable: EL 7 ------------- Pushed to testing: VirtualBox-5.2.22-1.el7 VirtualBox-kmod-5.2.22-1.el7 Pushed to stable: Section nonfree: ------------- Fedora 27 ------------- Pushed to testing: Pushed to stable: Fedora 28 ------------- Pushed to testing: Pushed to stable: Fedora 29 ------------- Pushed to testing: Pushed to stable: EL 6 ------------- Pushed to testing: Pushed to stable: EL 7 ------------- Pushed to testing: Pushed to stable: Theses packages will be available in main mirror in few minutes. Wait for local mirrors to sync Please report any issue to https://bugzilla.rpmfusion.org

6 years, 1 month

1
0
0 / 0

Re: [ffmpeg] Fixes for cuda enabled repo

by Dominik 'Rathann' Mierzejewski

Hi, Nicolas. On Friday, 09 November 2018 at 18:37, Nicolas Chauvet wrote: > commit 8ce6dfb678c50dbc4094f9d99c58264091b00235 > Author: Nicolas Chauvet <kwizart(a)gmail.com> > Date: Fri Nov 9 18:36:20 2018 +0100 > > Fixes for cuda enabled repo > > ffmpeg.spec | 23 +++++++++++++---------- > 1 file changed, 13 insertions(+), 10 deletions(-) > --- > diff --git a/ffmpeg.spec b/ffmpeg.spec > index 48452eb..0f55274 100644 > --- a/ffmpeg.spec > +++ b/ffmpeg.spec [...] > %ifarch %{cuda_arches} > -%global _with_cuda 1 > %global _with_cuvid 1 > %global _with_libnpp 1 > %endif Why? > @@ -42,6 +42,7 @@ > %global _without_cdio 1 > %global _without_frei0r 1 > %global _without_gpl 1 > +%global _without_vidstab 1 > %global _without_x264 1 > %global _without_x265 1 > %global _without_xvid 1 Why? [...] > @@ -321,6 +323,7 @@ mkdir -p _doc/examples > cp -pr doc/examples/{*.c,Makefile,README} _doc/examples/ > > %build > +export PATH=${PATH}:%{_cuda_bindir} > %{ff_configure}\ > --shlibdir=%{_libdir} \ > %if 0%{?_without_tools:1} Why are you adding this unconditionally? > @@ -381,7 +384,7 @@ install -pm755 tools/qt-faststart %{buildroot}%{_bindir} > %endif > > %ldconfig_scriptlets libs > -%ldconfig_scriptlets libavdevice%{?flavor} > +%ldconfig_scriptlets -n libavdevice%{?flavor} > > %if 0%{!?_without_tools:1} > %files Please don't mix CUDA-related changes with general fixes in the same commit. Regards, Dominik -- Fedora https://getfedora.org | RPMFusion 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

6 years, 1 month

1
0
0 / 0

[Bug 5072] New: Review Request: buildsys-build-rpmfusion-rpi - Tools and files used by the rpmfusion-rpi buildsys

by RPM Fusion Bugzilla

https://bugzilla.rpmfusion.org/show_bug.cgi?id=5072 Bug ID: 5072 Summary: Review Request: buildsys-build-rpmfusion-rpi - Tools and files used by the rpmfusion-rpi buildsys Product: Package Reviews Version: Current Hardware: x86_64 OS: GNU/Linux Status: NEW Severity: enhancement Priority: P1 Component: Review Request Assignee: rpmfusion-package-review(a)rpmfusion.org Reporter: kwizart(a)gmail.com CC: rpmfusion-package-review(a)rpmfusion.org Group: Package Reviews namespace: rpi SRPM: http://dl.kwizart.net/review/buildsys-build-rpmfusion-rpi-29-1.src.rpm SPEC: http://dl.kwizart.net/review/buildsys-build-rpmfusion-rpi.spec Summary: Tools and files used by the rpmfusion-rpi buildsys This package is needed by the rpi namespace and contains few RPM macros needed there. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

6 years, 1 month

1
3
0 / 0

[Bug 5073] New: Review Request: buildsys-build-rpmfusion-cuda - Tools and files used by the rpmfusion-cuda buildsys

by RPM Fusion Bugzilla

https://bugzilla.rpmfusion.org/show_bug.cgi?id=5073 Bug ID: 5073 Summary: Review Request: buildsys-build-rpmfusion-cuda - Tools and files used by the rpmfusion-cuda buildsys Product: Package Reviews Version: Current Hardware: x86_64 OS: GNU/Linux Status: NEW Severity: enhancement Priority: P1 Component: Review Request Assignee: rpmfusion-package-review(a)rpmfusion.org Reporter: kwizart(a)gmail.com CC: rpmfusion-package-review(a)rpmfusion.org Group: Package Reviews namespace: cuda SRPM: http://dl.kwizart.net/review/buildsys-build-rpmfusion-cuda-29-1.src.rpm SPEC: http://dl.kwizart.net/review/buildsys-build-rpmfusion-cuda.spec Summary: Tools and files used by the rpmfusion-cuda buildsys This package is needed by the cuda namespace and contains few RPM macros needed there. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

6 years, 1 month

1
3
0 / 0

How to make ZoneMidner package web server agnostic

by Andrew Bauer

For those that don’t know, ZoneMinder is a (surveillance) video management system. It takes video streams from surveillance cameras, and stores the video files to designated storage locations. It also stores metadata related to each video event into a backend dB. Since the underlying daemons run as the web account user, the locations ZoneMinder writes to must be owned by that same user account. As the package maintainer and upstream developer for the ZoneMinder project, one of the items on my to-do list has been to figure out a way to make the ZoneMinder package distro agnostic. On RedHat, ZoneMinder is traditionally built against Apache, but I’ve written the specfile such that, today, one can build against nginx by changing the web user & group name globals found at the top of the specfile. This of course works fine for a single offline user who knows how to roll their own package. However, I have yet to come up with a sensible solution that works for a hosted repository. Here are the problems as I see them: - files & folders that must be owned by the web account user - files with with the same name, but different content, depending on what webserver is being used - The web account user is inserted in zm.conf, the systemd unit file, and tmpfiles.d config during build via make macro. Here are possible solutions I have looked into, but don’t particularly care for: - Multiple buildroots within the same specfile. This sounds like total insanity to me. - Use of sed in %post to split ZoneMinder into subpackages each with content specific to each supported web server. This sounds very hackish, and I’m not sure if if can be done w/o multiple buildroots - Being part of upstream, I do have “hidden option C” available to me. I could update ZoneMinder zmupdate.pl script to allow the end user to arbitrarily change the web account user after the fact e.g. “zmupdate.pl –web_user nginx”. The downside to this approach is that is significantly widens the scope to include all users running ZoneMinder, including those using on obscure distros with weird filesystem structures. I maintain the specfile on the ZoneMinder github site, which you can view here: https://github.com/ZoneMinder/zoneminder/blob/master/distros/redhat/zonem... If anyone knows of an existing package that has overcome a similar problem, please point me to it. I don’t want to make the opening arguments of this message too long, so I’ll stop here and wait for follow up questions and comments.

6 years, 1 month

3
2
0 / 0

Introducing new koji rpmfusion namespace : rpi

by Nicolas Chauvet

Hi, I've just introduced a new pkgdb namespace: rpi The intend is to be able to build "downstream" raspberrypi optimized build using raspberry-vc The idea is to have few packages to be introduced in this repo (kernel-rpi raspberry-vc, chromium-rpi etc) and allow to use a symlink to the free(or nonfree) SCM URL for packages that need optimized version, such as ffmpeg,vlc,kodi, etc Thoses build will end with a specific dist tag: fc29rpi and only built on armhfp (not aarch64 that is not relevant for raspberry-vc currently). The buildroot will default to define %global _with_rpi 1, so current rpmfusion packages in the free section using this rpm conditional will enable the relevant feature (such as mmal api, omxil_rpi can be considered as deprecated in most cases). The repository will contains few specifics packages for the rpi that may replace rpmfusion counterparts (with a higher dist). In term, it will be possible to create rpi spins using this additional repository. On a side note: I really would like someone interested in to take over the packaging work of this feature. -- - Nicolas (kwizart)

6 years, 1 month

4
12
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

rpmfusion-developers November 2018