rpmfusion-free-release
In a fit of madness, I bumped the rpmfusion-free-release to 27 before realizing that we hadn't branched yet. And I can't untag the build: $ koji-rpmfusion untag-build f26-free rpmfusion-free-release-27-0.1 ActionNotAllowed: policy violation (tag) Can some admin do this ASAP? So very sorry, I'm incredibly ashamed.. -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: phonon-backend-vlc for EL7
On 02/23/2017 04:38 PM, Orion Poplawski wrote: > I've taken a look at building phonon-backend-vlc for EL7. The version that is > in the el7 branch in git is 0.7.1-1, which does not build because it requires > phonon 4.7.0, and EL7 has phonon 4.6.0. I was able to build 0.6.2-1 fine. > > Is there any objections to me reverting to 0.6.2-1 in git? (I suppose someone > with right access to the git repo could reset the el7 branch to that, but not > sure it's worth it). > > Also, while trying it out via dragon player in an X2Go session I'm getting: > > [7f21a8054578] vdpau_avcodec generic error: Xlib is required for VDPAU > [7f21a8054578] vdpau_avcodec generic error: Xlib is required for VDPAU > [7f21a80a84b8] core video output error: video output creation failed > [7f21c0019cc8] core decoder error: failed to create video output > > If anyone has any ideas that, that would be helpful. > Okay, I figured out these errors - it's because vlc needs the basic libxcb_* video_output plugins, but for some reason they are in the main vlc package rather than vlc-core. This doesn't make since to me since vlc requires vlc-core. I don't want the vlc binaries, but the libraries/plugins needed for playback. -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
phonon-backend-vlc for EL7
I've taken a look at building phonon-backend-vlc for EL7. The version that is in the el7 branch in git is 0.7.1-1, which does not build because it requires phonon 4.7.0, and EL7 has phonon 4.6.0. I was able to build 0.6.2-1 fine. Is there any objections to me reverting to 0.6.2-1 in git? (I suppose someone with right access to the git repo could reset the el7 branch to that, but not sure it's worth it). Also, while trying it out via dragon player in an X2Go session I'm getting: [7f21a8054578] vdpau_avcodec generic error: Xlib is required for VDPAU [7f21a8054578] vdpau_avcodec generic error: Xlib is required for VDPAU [7f21a80a84b8] core video output error: video output creation failed [7f21c0019cc8] core decoder error: failed to create video output If anyone has any ideas that, that would be helpful. -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: ffmpeg for EL7
On 08/31/2016 07:11 PM, Sérgio Basto wrote: > Orion Poplawski, I'd like have an agreement on how put ffmpeg in epel7. > What you say ? may we have one ffmpeg ? , should we have multi ffmpegs > ? etc. So would I. But I seem to have offended Nicolas enough that discussion has stopped. I think that the ffmpegX.Y packages allow for a better transition in the future when 2.8 becomes unsupported, as well as allowing packages that need 3.1 to use it now. But it is definitely more complex and there may be other gotchas. However, I do feel that this is the way more and more packages are going, especially in EPEL. For example, with zabbix, we have zabbix20 and zabbix22, but no "zabbix". If the consensus is to ship 2.8 as ffmpeg now, and then presumably switch to 3.X later and ship ffmpeg-compat-2.8 later, that seems workable as well. Traditionally compat packages have only shipped runtime libs, but you could ship the full thing as well if needed. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: ffmpeg for EL7
On 08/26/2016 01:17 PM, Orion Poplawski wrote: > # yum install ffmpeg > Dependencies Resolved > > > Package Arch Version Repository Size > > Installing: > ffmpeg3.1 x86_64 3.1.2-1.el7 ffmpeg 1.4 M > Installing for dependencies: > ffmpeg3.1-libavdevice x86_64 3.1.2-1.el7 ffmpeg 82 k > ffmpeg3.1-libsx86_64 3.1.2-1.el7 ffmpeg 5.9 M > > Transaction Summary > > Install 1 Package (+2 Dependent packages) Just to be clear: # yum --disablerepo=* --enablerepo=ffmpeg list Available Packages ffmpeg2.8.x86_642.8.7-1.el7 ffmpeg ffmpeg2.8-debuginfo.x86_64 2.8.7-1.el7 ffmpeg ffmpeg2.8-devel.x86_64 2.8.7-1.el7 ffmpeg ffmpeg2.8-libavdevice.x86_64 2.8.7-1.el7 ffmpeg ffmpeg2.8-libs.x86_64 2.8.7-1.el7 ffmpeg ffmpeg3.0.x86_643.0.2-4.el7 ffmpeg ffmpeg3.0-debuginfo.x86_64 3.0.2-4.el7 ffmpeg ffmpeg3.0-devel.x86_64 3.0.2-4.el7 ffmpeg ffmpeg3.0-libavdevice.x86_64 3.0.2-4.el7 ffmpeg ffmpeg3.0-libs.x86_64 3.0.2-4.el7 ffmpeg ffmpeg3.1.x86_643.1.2-1.el7 ffmpeg ffmpeg3.1-debuginfo.x86_64 3.1.2-1.el7 ffmpeg ffmpeg3.1-devel.x86_64 3.1.2-1.el7 ffmpeg ffmpeg3.1-libavdevice.x86_64 3.1.2-1.el7 ffmpeg ffmpeg3.1-libs.x86_64 3.1.2-1.el7 ffmpeg -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: ffmpeg for EL7
On 08/26/2016 01:35 AM, Nicolas Chauvet wrote: > 2016-08-26 0:23 GMT+02:00 Orion Poplawski <or...@cora.nwra.com>: >> On 08/25/2016 02:30 PM, Nicolas Chauvet wrote: >>> 2016-08-25 22:19 GMT+02:00 Orion Poplawski <or...@cora.nwra.com>: >>>> On 08/25/2016 06:28 AM, Dominik 'Rathann' Mierzejewski wrote: >>>>> On Thursday, 25 August 2016 at 10:24, Ralf Corsepius wrote: >>>>>> On 08/25/2016 10:01 AM, Nicolas Chauvet wrote: >>>>> [...] >>>>>>> Specially as ffmpeg doesn't do symbol version, if one process has >>>>>>> dependencies using both version, it will crash. >>>>>> AFAIU, as long as these packages are properly linked (and not libraries >>>>>> not being dlopened), package deps on SONAMEs would conflict and thus >>>>>> prevent such problems. >>>>> >>>>> The point is that not all SONAMEs change with each FFmpeg version bump, >>>>> so, for example, ffmpeg-3.0.x and ffmpeg-3.1.x may have mostly the same >>>>> SONAMEs. >>>> >>>> Here is an attempt at ffmpeg2.8 and ffmpeg3.0. This relies on different >>> I've strictly no question about how not to make conflict between >>> theses, so I'm not even looking at your spec since I don't think they >>> will bring any value to the "discution". >>> Please have a look at ffmpeg-compat for not conflicting with -devel >>> Also please have a look this for not conflicting with ffmpeg version >>> of the same ABI: >>> http://rpms.kwizart.net/fedora/16/SRPMS/ffmpeg4vlc-0.6-0.4.20100612svn.fc13.src.rpm >>> Here are the ABI from ffmpeg upstream: >>> http://ffmpeg.org/download.html#releases >> >> Well, I'll give you the courtesy of looking at your specs, even if you won't >> do the same for me. > You are still in the "How not to make conflicts" question whereas this > question is out of interest over "which version to choose for a > general usage." I'm trying to be concerned with the question - "What happens when the version needed for general usage changes? How can that be done in the least impactful way by planning for that transition now?" > You are still in the false premise that you can have any versions as > soon as they do not conflict for general usage and let packagers > choose theirs. Why is this a false premise? It seems perfectly reasonable to have ffmpeg2.8 to start, and add a ffmpeg3.X when there is a critical mass of other software that requires it. And then keep sliding this forward as necessary, and then when necessary dropping the old ffmpeg2.8, etc. when they are unsupportable. We're talking 8 more years for EL7 to be around. > You have also ignored several of my earlier comments, so I wouldn't > say courtesy is on your side here. I certainly didn't do so intentionally. I've just replied to an earlier email, perhaps that helps. > This discussion has gone wrong, so I'm dropping here. Deep breath, start again. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: ffmpeg for EL7
On 08/25/2016 02:01 AM, Nicolas Chauvet wrote: > 2016-08-24 20:19 GMT+02:00 Orion Poplawski <or...@cora.nwra.com>: >> On 08/24/2016 11:35 AM, Nicolas Chauvet wrote: >>> 2016-08-24 18:55 GMT+02:00 Orion Poplawski <or...@cora.nwra.com>: >>>> On 08/23/2016 12:15 PM, Nicolas Chauvet wrote: >>>>> 2016-08-23 20:06 GMT+02:00 Orion Poplawski <or...@cora.nwra.com>: >>>>>> Does anyone here have any ffmpeg knowledge that would give a reason for >>>>>> preferring anything other than the current ffmpeg 3.1.1 for EL7? Does >>>>>> ffmpeg >>>>>> have a long-term-support branch? >>>>> There is issue with stable vlc-2.2x which I plan to have in el7, also >>>>> the current kodi 0.16 version doesn't cope well with ffmpeg 3.1x >>>>> I think it's easier to have ffmpeg 3.0x in el7, but then I don't know >>>>> other dependencies that might have issue. >>>> >>>> Given the pain of later updates, it might be worth waiting a bit for vlc >>>> 3.0 >>>> and kodi 0.17 to land (or get sufficiently stable). >>> >>> I don't expect vlc-3 in EL7 as a first step. VLC 2.2x is there and >>> more relevant for long term support, and specially since EL8 shoudn't >>> be that far away for vlc-3x. >> >> Okay, although based on past timescales I wouldn't expect EL8 until Q4 2017. > yep, will have a strong stable vlc-3 by then ;) > >>> Based on that ffmpeg-2.8x seems a more relevant ABI to start with EL7. >>> And later we can still update the whole multimedia stack with >>> ffmpeg-3.1+ vlc3+ koji17 then introduce a fmpeg-2.8x as ffmpeg-compat >>> to keep "stable ABI" >>> >>> This has always been a problem to build latest ffmpeg in stable >>> release without to break ABI. we should probably have a "SCL build of >>> ffmpeg" for those that will only rely on the ffmpeg binaries or fast >>> moving projects using the ffmpeg libraries. >> >> One suggestion that's been getting more traction on the EPEL side of things >> is >> to just start with versioned packages that can co-exist. So start with >> ffmpeg2.8 and ffmpeg3.0 from the start. > > I don't quite understand the proposition related to ffmpeg. Using > version in name doesn't seem to say which one should be chosen by > default for link. At run-time this is handled by soname. At build time, we have a couple options: - Only one package could provides the "ffmpeg-devel" name - this would be the "preferred" one. Packages that needed a different version could require the versioned name. - This would also be the default version for people doing "yum install ffmpeg". or as I've done it now, where they all provide the base name, so you get the latest when you ask for just ffmpeg, but you can BR/R the versioned one if necessary. This also allows any installed version to satisfy the generic "ffmpeg"/"ffmpeg-devel" requires. # yum install ffmpeg Resolving Dependencies --> Running transaction check ---> Package ffmpeg3.1.x86_64 0:3.1.2-1.el7 will be installed --> Processing Dependency: ffmpeg3.1-libs(x86-64) = 3.1.2-1.el7 for package: ffmpeg3.1-3.1.2-1.el7.x86_64 --> Processing Dependency: libavcodec.so.57(LIBAVCODEC_57)(64bit) for package: ffmpeg3.1-3.1.2-1.el7.x86_64 --> Processing Dependency: libavdevice.so.57(LIBAVDEVICE_57)(64bit) for package: ffmpeg3.1-3.1.2-1.el7.x86_64 --> Processing Dependency: libavfilter.so.6(LIBAVFILTER_6)(64bit) for package: ffmpeg3.1-3.1.2-1.el7.x86_64 --> Processing Dependency: libavformat.so.57(LIBAVFORMAT_57)(64bit) for package: ffmpeg3.1-3.1.2-1.el7.x86_64 --> Processing Dependency: libavresample.so.3(LIBAVRESAMPLE_3)(64bit) for package: ffmpeg3.1-3.1.2-1.el7.x86_64 --> Processing Dependency: libavutil.so.55(LIBAVUTIL_55)(64bit) for package: ffmpeg3.1-3.1.2-1.el7.x86_64 --> Processing Dependency: libpostproc.so.54(LIBPOSTPROC_54)(64bit) for package: ffmpeg3.1-3.1.2-1.el7.x86_64 --> Processing Dependency: libswresample.so.2(LIBSWRESAMPLE_2)(64bit) for package: ffmpeg3.1-3.1.2-1.el7.x86_64 --> Processing Dependency: libswscale.so.4(LIBSWSCALE_4)(64bit) for package: ffmpeg3.1-3.1.2-1.el7.x86_64 --> Processing Dependency: libavcodec.so.57()(64bit) for package: ffmpeg3.1-3.1.2-1.el7.x86_64 --> Processing Dependency: libavdevice.so.57()(64bit) for package: ffmpeg3.1-3.1.2-1.el7.x86_64 --> Processing Dependency: libavfilter.so.6()(64bit) for package: ffmpeg3.1-3.1.2-1.el7.x86_64 --> Processing Dependency: libavformat.so.57()(64bit) for package: ffmpeg3.1-3.1.2-1.el7.x86_64 --> Processing Dependency: libavresample.so.3()(64bit) for pack
Re: ffmpeg for EL7
On 08/25/2016 02:30 PM, Nicolas Chauvet wrote:
> 2016-08-25 22:19 GMT+02:00 Orion Poplawski <or...@cora.nwra.com>:
>> On 08/25/2016 06:28 AM, Dominik 'Rathann' Mierzejewski wrote:
>>> On Thursday, 25 August 2016 at 10:24, Ralf Corsepius wrote:
>>>> On 08/25/2016 10:01 AM, Nicolas Chauvet wrote:
>>> [...]
>>>>> Specially as ffmpeg doesn't do symbol version, if one process has
>>>>> dependencies using both version, it will crash.
>>>> AFAIU, as long as these packages are properly linked (and not libraries
>>>> not being dlopened), package deps on SONAMEs would conflict and thus
>>>> prevent such problems.
>>>
>>> The point is that not all SONAMEs change with each FFmpeg version bump,
>>> so, for example, ffmpeg-3.0.x and ffmpeg-3.1.x may have mostly the same
>>> SONAMEs.
>>
>> Here is an attempt at ffmpeg2.8 and ffmpeg3.0. This relies on different
> I've strictly no question about how not to make conflict between
> theses, so I'm not even looking at your spec since I don't think they
> will bring any value to the "discution".
> Please have a look at ffmpeg-compat for not conflicting with -devel
> Also please have a look this for not conflicting with ffmpeg version
> of the same ABI:
> http://rpms.kwizart.net/fedora/16/SRPMS/ffmpeg4vlc-0.6-0.4.20100612svn.fc13.src.rpm
> Here are the ABI from ffmpeg upstream:
> http://ffmpeg.org/download.html#releases
Well, I'll give you the courtesy of looking at your specs, even if you won't
do the same for me.
With ffmpeg-compat - it only provides the libs, not the binaries.
ffmpeg-compat doesn't conflict with any other ffmpeg package only if all of
the sonames are different, just like the ffmpeg2.8/3.0-libs packages I
presented.
ffmpeg-compat-devel doesn't conflict because the .so and .pc files are moved
to %{_libdir}/ffmpeg-compat{,/pkgconfig}. So to make use them you need to
pass -L%{_libdir}/ffmpeg-compat or set
PKG_CONFIG_PATH=%{_libdir}/ffmpeg-compat/pkgconfig, which is reasonable.
I couldn't get ffmpeg4vlc to build, but looking at %files:
- it ships binaries, so that conflicts with ffmpeg
- it uses --build-suffix=4vlc - I'm guessing this is added to the library
names - which I suspect is harder to make other projects make use of. No idea.
So here's an updated set including 3.1 that move the libs and .pc files to
%{_libdir}/%{name}. So none of the packages conflict. To use you would
specify -L%{_libdir}/ffmpegX.X or set
PKG_CONFIG_PATH=%{_libdir}/ffmpegX.X/pkgconfig as with ffmpeg-compat-devel.
The problem here would come in with mixing ffmpeg3.0 and ffmpeg3.1, as without
the use of rpath or similar you could end up with a mix of versions of
libraries with the same soname. So I would avoid having both 3.0 and 3.1 if
possible.
> My point is to have EL7 built with ffmpeg28 by default and eventually
> provide an alternative and newer ffmpeg for the binaries.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
# TODO: add make test to %%check section
#global branch oldabi-
#global date20110612
#global rel rc1
%if 0%{?rhel} && 0%{?rhel} <= 6
%global _without_frei0r 1
%global _without_opencv 1
%global _without_vpx 1
%endif
%global versionsuffix 2.8
Summary:Digital VCR and streaming server
Name: ffmpeg%{?versionsuffix}
Version:%{versionsuffix}.7
Release:1%{?date}%{?date:git}%{?rel}%{?dist}
%if 0%{?_with_amr:1}
License:GPLv3+
%else
License:GPLv2+
%endif
URL:http://ffmpeg.org/
%if 0%{?date}
Source0:ffmpeg-%{?branch}%{date}.tar.bz2
%else
Source0:http://ffmpeg.org/releases/ffmpeg-%{version}.tar.xz
%endif
Requires: %{name}-libs%{?_isa} = %{version}-%{release}
BuildRequires: bzip2-devel
%{?_with_celt:BuildRequires: celt-devel}
%{?_with_dirac:BuildRequires: dirac-devel}
%{?_with_faac:BuildRequires: faac-devel}
%{?_with_fdk_aac:BuildRequires: fdk-aac-devel}
BuildRequires: freetype-devel
%{!?_without_frei0r:BuildRequires: frei0r-devel}
BuildRequires: gnutls-devel
BuildRequires: gsm-devel
BuildRequires: lame-devel >= 3.98.3
%{?_with_jack:BuildRequires: jack-audio-connection-kit-devel}
%{!?_without_ladspa:BuildRequires: ladspa-devel}
BuildRequires: libass-devel
%{!?_without_cdio:BuildRequires: libcdio-paranoia-devel}
#libcrystalhd is currently broken
%{?_with_crystalhd:BuildRequires: libcrystalhd-devel}
BuildRequires: libdc1394-devel
Buildrequires: libmodplug-devel
%{?_with_rtmp:BuildRequires: librtmp-devel}
BuildRequires: libtheora-devel
BuildRequires: libv4l-devel
BuildRequires: libvdpau-devel
BuildRequires: libvorbis-devel
%{?!_without_vpx:Bui
Re: ffmpeg for EL7
As a tangential question - anyone know why the ffmpeg package doesn't use the %configure macro? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: ffmpeg for EL7
On 08/25/2016 02:01 AM, Nicolas Chauvet wrote: > 2016-08-24 20:19 GMT+02:00 Orion Poplawski <or...@cora.nwra.com>: >> One suggestion that's been getting more traction on the EPEL side of things >> is >> to just start with versioned packages that can co-exist. So start with >> ffmpeg2.8 and ffmpeg3.0 from the start. > > I don't quite understand the proposition related to ffmpeg. Using > version in name doesn't seem to say which one should be chosen by > default for link. > Specially as ffmpeg doesn't do symbol version, if one process has > dependencies using both version, it will crash. > Also ffmpeg as a 3month release cycle, does it mean a new review each time ? Well, Fedora has basically gone to rubber-stamping versioned packages that are based on existing ones. This seems pretty reasonable to me. It also may not make sense to package all versions. Only the ones that get a lot of uptake from other users. > Using ffmpeg/ffmpeg-compat or ffmpeg-compat28 means to use ffmpeg by > default then ffmpeg-compat28 (with only libs) for the few projects > that needs it. The problem is that at some point you will need to update "ffmpeg", and this will be painful. Avoiding it completely helps with that. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: ffmpeg for EL7
On 08/25/2016 06:28 AM, Dominik 'Rathann' Mierzejewski wrote:
> On Thursday, 25 August 2016 at 10:24, Ralf Corsepius wrote:
>> On 08/25/2016 10:01 AM, Nicolas Chauvet wrote:
> [...]
>>> Specially as ffmpeg doesn't do symbol version, if one process has
>>> dependencies using both version, it will crash.
>> AFAIU, as long as these packages are properly linked (and not libraries
>> not being dlopened), package deps on SONAMEs would conflict and thus
>> prevent such problems.
>
> The point is that not all SONAMEs change with each FFmpeg version bump,
> so, for example, ffmpeg-3.0.x and ffmpeg-3.1.x may have mostly the same
> SONAMEs.
Here is an attempt at ffmpeg2.8 and ffmpeg3.0. This relies on different
sonames for all libraries.
If there was overlap, we could move the libraries into %{_libdir}/ffmpegX.X
and use ldconfig. I was going to start looking at 3.1 next.
As Ralf noted, the -devel (and -debuginfo) packages conflict, though this
could be worked around as well. Also, usually not necessary as you're
generally only building against one at a time.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
# TODO: add make test to %%check section
#global branch oldabi-
#global date20110612
#global rel rc1
%if 0%{?rhel} && 0%{?rhel} <= 6
%global _without_frei0r 1
%global _without_opencv 1
%global _without_vpx 1
%endif
%global versionsuffix 3.0
Summary:Digital VCR and streaming server
Name: ffmpeg%{?versionsuffix}
Version:%{versionsuffix}.2
Release:4%{?date}%{?date:git}%{?rel}%{?dist}
%if 0%{?_with_amr} || 0%{?_with_gmp}
License:GPLv3+
%else
License:GPLv2+
%endif
URL:http://ffmpeg.org/
%if 0%{?date}
Source0:ffmpeg-%{?branch}%{date}.tar.bz2
%else
Source0:http://ffmpeg.org/releases/ffmpeg-%{version}.tar.xz
%endif
Patch0: 0001-configure-add-direct-detection-of-libopencv.patch
Requires: %{name}-libs%{?_isa} = %{version}-%{release}
BuildRequires: bzip2-devel
%{?_with_faac:BuildRequires: faac-devel}
%{?_with_fdk_aac:BuildRequires: fdk-aac-devel}
%{?_with_flite:BuildRequires: flite-devel}
BuildRequires: fontconfig-devel
BuildRequires: freetype-devel
%{!?_without_frei0r:BuildRequires: frei0r-devel}
%{?_with_gme:BuildRequires: game-music-emu-devel}
BuildRequires: gnutls-devel
BuildRequires: gsm-devel
%{?_with_ilbc:BuildRequires: ilbc-devel}
BuildRequires: lame-devel >= 3.98.3
%{!?_without_jack:BuildRequires: jack-audio-connection-kit-devel}
%{!?_without_ladspa:BuildRequires: ladspa-devel}
BuildRequires: libass-devel
BuildRequires: libbluray-devel
%{?_with_bs2b:BuildRequires: libbs2b-devel}
%{?_with_caca:BuildRequires: libcaca-devel}
%{!?_without_cdio:BuildRequires: libcdio-paranoia-devel}
%{?_with_chromaprint:BuildRequires: libchromaprint-devel}
#libcrystalhd is currently broken
%{?_with_crystalhd:BuildRequires: libcrystalhd-devel}
%if 0%{?_with_ieee1394}
BuildRequires: libavc1394-devel
BuildRequires: libdc1394-devel
BuildRequires: libiec61883-devel
%endif
BuildRequires: libgcrypt-devel
BuildRequires: libGL-devel
%{?_with_mfx:BuildRequires: libmfx-devel}
Buildrequires: libmodplug-devel
%{?_with_rtmp:BuildRequires: librtmp-devel}
%{?_with_smb:BuildRequires: libsmbclient-devel}
%{?_with_ssh:BuildRequires: libssh-devel}
BuildRequires: libtheora-devel
BuildRequires: libv4l-devel
BuildRequires: libvdpau-devel
BuildRequires: libvorbis-devel
%{?!_without_vpx:BuildRequires: libvpx-devel >= 0.9.1}
%ifarch %{ix86} x86_64
BuildRequires: libXvMC-devel
%{?!_without_vaapi:BuildRequires: libva-devel >= 0.31.0}
%endif
%{?_with_webp:BuildRequires: libwebp-devel}
%{?_with_netcdf:BuildRequires: netcdf-devel}
%{?_with_amr:BuildRequires: opencore-amr-devel vo-amrwbenc-devel}
%{!?_without_openal:BuildRequires: openal-soft-devel}
%if 0%{!?_without_opencl:1}
BuildRequires: opencl-headers ocl-icd-devel
%if 0%{?fedora} || 0%{?rhel} >= 8
Recommends: opencl-icd
%endif
%endif
%{!?_without_opencv:BuildRequires: opencv-devel}
BuildRequires: openjpeg-devel
BuildRequires: opus-devel
%{!?_without_pulse:BuildRequires: pulseaudio-libs-devel}
BuildRequires: perl(Pod::Man)
%{?_with_rubberband:BuildRequires: rubberband-devel}
BuildRequires: schroedinger-devel
BuildRequires: SDL-devel
%{?_with_snappy:BuildRequires: snappy-devel}
BuildRequires: soxr-devel
BuildRequires: speex-devel
BuildRequires: subversion
%{?_with_tesseract:BuildRequires: tesseract-devel}
#BuildRequires: texi2html
BuildRequires: texinfo
%{?_with_twolame:BuildRequires: twolame-devel}
%{?_with_wavpack:BuildRequires: wavpack-devel}
%{!?_without_x264:BuildRequires: x264-devel >= 0.0.0-0.31}
%{!?_without_x265:BuildRequires: x265-devel}
%{?_with_xvid:BuildRequire
Re: ffmpeg for EL7
On 08/25/2016 07:39 AM, Ralf Corsepius wrote: > On 08/25/2016 02:28 PM, Dominik 'Rathann' Mierzejewski wrote: >> On Thursday, 25 August 2016 at 10:24, Ralf Corsepius wrote: >>> On 08/25/2016 10:01 AM, Nicolas Chauvet wrote: >> [...] >>>> Specially as ffmpeg doesn't do symbol version, if one process has >>>> dependencies using both version, it will crash. >>> AFAIU, as long as these packages are properly linked (and not libraries >>> not being dlopened), package deps on SONAMEs would conflict and thus >>> prevent such problems. >> >> The point is that not all SONAMEs change with each FFmpeg version bump, >> so, for example, ffmpeg-3.0.x and ffmpeg-3.1.x may have mostly the same >> SONAMEs. > > This would mean these are ABI compatible. > > I haven't tried to check and verify actual situation wrt. ffmpeg. Forward, not necessarily backward (compiled with 3.1, running with 3.0). This is where symbol versioning would help. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: ffmpeg for EL7
On 08/24/2016 11:35 AM, Nicolas Chauvet wrote: > 2016-08-24 18:55 GMT+02:00 Orion Poplawski <or...@cora.nwra.com>: >> On 08/23/2016 12:15 PM, Nicolas Chauvet wrote: >>> 2016-08-23 20:06 GMT+02:00 Orion Poplawski <or...@cora.nwra.com>: >>>> Does anyone here have any ffmpeg knowledge that would give a reason for >>>> preferring anything other than the current ffmpeg 3.1.1 for EL7? Does >>>> ffmpeg >>>> have a long-term-support branch? >>> There is issue with stable vlc-2.2x which I plan to have in el7, also >>> the current kodi 0.16 version doesn't cope well with ffmpeg 3.1x >>> I think it's easier to have ffmpeg 3.0x in el7, but then I don't know >>> other dependencies that might have issue. >> >> Given the pain of later updates, it might be worth waiting a bit for vlc 3.0 >> and kodi 0.17 to land (or get sufficiently stable). > > I don't expect vlc-3 in EL7 as a first step. VLC 2.2x is there and > more relevant for long term support, and specially since EL8 shoudn't > be that far away for vlc-3x. Okay, although based on past timescales I wouldn't expect EL8 until Q4 2017. > Based on that ffmpeg-2.8x seems a more relevant ABI to start with EL7. > And later we can still update the whole multimedia stack with > ffmpeg-3.1+ vlc3+ koji17 then introduce a fmpeg-2.8x as ffmpeg-compat > to keep "stable ABI" > > This has always been a problem to build latest ffmpeg in stable > release without to break ABI. we should probably have a "SCL build of > ffmpeg" for those that will only rely on the ffmpeg binaries or fast > moving projects using the ffmpeg libraries. One suggestion that's been getting more traction on the EPEL side of things is to just start with versioned packages that can co-exist. So start with ffmpeg2.8 and ffmpeg3.0 from the start. SCLs are a major pain. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: ffmpeg for EL7
On 08/23/2016 12:15 PM, Nicolas Chauvet wrote: > 2016-08-23 20:06 GMT+02:00 Orion Poplawski <or...@cora.nwra.com>: >> Does anyone here have any ffmpeg knowledge that would give a reason for >> preferring anything other than the current ffmpeg 3.1.1 for EL7? Does ffmpeg >> have a long-term-support branch? > There is issue with stable vlc-2.2x which I plan to have in el7, also > the current kodi 0.16 version doesn't cope well with ffmpeg 3.1x > I think it's easier to have ffmpeg 3.0x in el7, but then I don't know > other dependencies that might have issue. Given the pain of later updates, it might be worth waiting a bit for vlc 3.0 and kodi 0.17 to land (or get sufficiently stable). I've taken Dominik's suggestion and queried[0] the ffmpeg developers. We'll see what they say. [0] - http://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/198246.html -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: ffmpeg for EL7
On 08/23/2016 12:15 PM, Nicolas Chauvet wrote: > 2016-08-23 20:06 GMT+02:00 Orion Poplawski <or...@cora.nwra.com>: >> Does anyone here have any ffmpeg knowledge that would give a reason for >> preferring anything other than the current ffmpeg 3.1.1 for EL7? Does ffmpeg >> have a long-term-support branch? > There is issue with stable vlc-2.2x which I plan to have in el7, also > the current kodi 0.16 version doesn't cope well with ffmpeg 3.1x > I think it's easier to have ffmpeg 3.0x in el7, but then I don't know > other dependencies that might have issue. Seems reasonable for me. I've filed a request for a EL7 build of ocl-icd here: https://bugzilla.redhat.com/show_bug.cgi?id=1369574 > Thx for bootstraping el7 ! Thanks for making it possible! FWIW - I'm focusing on mplayer deps as that's my main use from rpmfusion. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
ffmpeg for EL7
Does anyone here have any ffmpeg knowledge that would give a reason for preferring anything other than the current ffmpeg 3.1.1 for EL7? Does ffmpeg have a long-term-support branch? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: rfpkg build fixed, you can build on koji !
On 07/13/2016 07:02 AM, Nicolas Chauvet wrote: > I've regenerated the repos, you can try any package for now. > I'm still away until the end of the week, for other investigation. el7 builds appear to be working now, yay! Can we get an el7 branch for rfpkg? Thanks. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: rfpkg build fixed, you can build on koji !
On 08/19/2016 03:08 PM, Orion Poplawski wrote: > On 07/13/2016 07:02 AM, Nicolas Chauvet wrote: >> I've regenerated the repos, you can try any package for now. >> I'm still away until the end of the week, for other investigation. > > el7 builds appear to be working now, yay! > > Can we get an el7 branch for rfpkg? Thanks. > > I'll note that the el7 dist tag is the centos (and copr) default of "el7.centos". Not sure if you want to keep that or go with just ".el7" I see some el6 builds ending up with ".el6.3" as well, which probably isn't correct. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
EL composes
What needs to get done to get rpmfusion EL composes working again? Anything others can help with? Thanks. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: rfpkg build fixed, you can build on koji !
On 07/13/2016 07:02 AM, Nicolas Chauvet wrote: > 2016-07-11 22:42 GMT+02:00 Orion Poplawski <or...@cora.nwra.com>: >> On 07/04/2016 02:01 PM, Nicolas Chauvet wrote: >>> Hi, >>> >>> rfpkg build has been fixed, it's now possible to submit build request >>> with rfpkg-1.23-4 >>> http://koji.rpmfusion.org/koji/buildinfo?buildID=851 >>> >>> Please build your packages for f23 to f25 (devel), >>> >>> el7 build might be possible, but it sounds like there are additional >>> issue that needs to be investigated. >> >> yeah, I'm seeing: >> >> >> >> DEBUG util.py:421: >> http://download.fedoraproject.org/pub/epel/7/x86_64/g/GitPython-1.0.1-5.el7.noarch.rpm: >> [Errno 12] Timeout on >> http://download.fedoraproject.org/pub/epel/7/x86_64/g/GitPython-1.0.1-5.el7.noarch.rpm: >> (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 >> seconds') >> DEBUG util.py:421: Trying other mirror. >> DEBUG util.py:421: >> http://mirror.centos.org/centos/7/os/x86_64/Packages/acl-2.2.51-12.el7.x86_64.rpm: >> [Errno 12] Timeout on >> http://mirror.centos.org/centos/7/os/x86_64/Packages/acl-2.2.51-12.el7.x86_64.rpm: >> (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 >> seconds') >> DEBUG util.py:421: Trying other mirror. >> >> so it looks like the builder has some network issues or wrong mock config >> somehow? > > The network is good, but I've experienced the same kind of issue while > using dnf in fedora. > Currently the koji buildroot are generated using mock instead of dnf > to workaround the very same behaviour. > But in el7 we should use yum anyway and the "workaround" does'nt hold there. > Of course while downloading the particular package from the builder, > everything behave correctly. > > I've regenerated the repos, you can try any package for now. > I'm still away until the end of the week, for other investigation. > > Thx > Alas, still the same issue. Thanks for trying. Hopefully you'll be able to sort it out on your return. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: [ANNOUNCE] RPM Fusion infra is back for contributors
On 06/19/2016 04:12 PM, Nicolas Chauvet wrote:
> Hello,
>
> I just want to say that there is now a minimal version of rfpkg available.
> http://koji.rpmfusion.org/koji/packageinfo?packageID=447
>
> This version (rfpkg-1.23.2-1.fc24 so far) is known to allow:
> - clone
> - push
> - few others commands
>
> So contributors should be able to push content to the new infra:
> https://pkgs.rpmfusion.org/cgit for ref (additionally forwared to
> github.com/rpmfusion as R/O mirror)
>
> Known not to work yet
> - new-sources (the file seems to be uploaded
> - srpm
> - build
>
> This mean I will have to manually submit build to the infra until
> theses features are fixed.
> Here is the current code of the tool https://github.com/rpmfusion-infra/rfpkg
> I really hope someone could step up and work on fixing this issue
> since there is still a long road to have the infra side really
> finised.
> (main priority is to have packages out of the infra to mirrors)
>
>
Minor fix to build rfpkg on EL7:
>From 51c76aa1084c4994bb0e9f9852607f39d1156ffe Mon Sep 17 00:00:00 2001
From: Orion Poplawski <or...@cora.nwra.com>
Date: Mon, 27 Jun 2016 15:48:18 -0600
Subject: [PATCH] Handle EL7 bash completion path
---
rfpkg.spec | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rfpkg.spec b/rfpkg.spec
index 7f5f58a..29540f1 100644
--- a/rfpkg.spec
+++ b/rfpkg.spec
@@ -76,7 +76,7 @@ chmod +x $RPM_BUILD_ROOT%{_bindir}/rfpkg-*free
%{python2_sitelib}/rfpkg/
%{python2_sitelib}/rfpkg-%{version}-py%{python2_version}.egg-info/
%{_mandir}/man1/rfpkg.1*
-%if 0%{?fedora}
+%if 0%{?fedora} || 0%{?rhel} >= 7
%dir %{_datadir}/bash-completion
%dir %{_datadir}/bash-completion/completions
%{_datadir}/bash-completion/completions/rfpkg
--
1.8.3.1
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
el7 builds
Nicolas - Can you submit el7 builds of: - a52dec - faad2 - libdca (after merge from master) - libmpeg2 - twolame - xvidcore (after merge from master) They all appear to build fine. Thanks. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: EL-6 push
On 08/27/2015 09:54 AM, Orion Poplawski wrote: > On 08/01/2015 02:51 AM, Nicolas Chauvet wrote: >> 2015-08-01 0:14 GMT+02:00 Orion Poplawski <or...@cora.nwra.com >> <mailto:or...@cora.nwra.com>>: >> >> Yesterday I built a new transcode to because of the ImageMagick soname >> bump in >> RHEL6.7, but haven't seen it in updates-testing yet. Are EL-6 pushes >> still >> happening? >> >> Are you sure that transcode was built using the right version of ImageMagick >> from root.log ? >> If that's the case, I will push it later. But I doubt we had enabled >> centos-cr >> repositories for builders. > > Looks like I hadn't really managed to build it. But now I have: > > http://buildsys.rpmfusion.org/build-status/job.psp?uid=22807 > > with the correct ImageMagick. > Nicolas - could we get that EL-6 updates-testing push now? Thanks. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: EL-6 push
On 08/01/2015 02:51 AM, Nicolas Chauvet wrote: 2015-08-01 0:14 GMT+02:00 Orion Poplawski or...@cora.nwra.com mailto:or...@cora.nwra.com: Yesterday I built a new transcode to because of the ImageMagick soname bump in RHEL6.7, but haven't seen it in updates-testing yet. Are EL-6 pushes still happening? Are you sure that transcode was built using the right version of ImageMagick from root.log ? If that's the case, I will push it later. But I doubt we had enabled centos-cr repositories for builders. Looks like I hadn't really managed to build it. But now I have: http://buildsys.rpmfusion.org/build-status/job.psp?uid=22807 with the correct ImageMagick. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
EL-6 push
Yesterday I built a new transcode to because of the ImageMagick soname bump in RHEL6.7, but haven't seen it in updates-testing yet. Are EL-6 pushes still happening? Thanks. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
akmods installs kernel-debug-devel
I think the provides for the kernel-debug-devel package is causing issues when installing akmods: # repoquery --provides kernel-debug-devel kernel-debug-devel = 3.16.6-200.fc20 kernel-debug-devel(x86-64) = 3.16.6-200.fc20 kernel-debug-devel-x86_64 = 3.16.6-200.fc20 kernel-devel = 3.16.6-200.fc20+debug kernel-devel-uname-r = 3.16.6-200.fc20.x86_64+debug kernel-devel-x86_64 = 3.16.6-200.fc20+debug -- Processing Dependency: kernel-devel-uname-r for package: akmods-0.5.1-3.fc19.noarch --- Package kernel-debug-devel.x86_64 0:3.16.6-200.fc20 will be installed Why does the kernel-debug-devel package have kernel-devel* provides? Or should akmods require something different? https://bugzilla.redhat.com/show_bug.cgi?id=227533 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: mass rebuild plan
On 09/01/2014 10:14 AM, Sérgio Basto wrote: Hi, Mass rebuild is finished ! . Resubmitted all other packages from group 3 that have buildtime 2014-07-18 (July 18) [7] and also removing noarch packages and we got more 2 FTBFS : http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/21108-gecko-mediaplayer-1.0.9-2.fc21/x86_64/build.log Debian has a patch for this - http://anonscm.debian.org/cgit/pkg-multimedia/gecko-mediaplayer.git/tree/debian/patches/np_loadds.patch I tried to check it in, but apparently I don't have access to gecko-mediaplayer. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com
Re: Fedora 21 and EL 7
On 06/14/2014 12:34 AM, Nicolas Chauvet wrote: 2014-06-14 4:32 GMT+02:00 Ken Dreyer ktdre...@ktdreyer.com mailto:ktdre...@ktdreyer.com: Hi folks, Is anyone planning to do a mass rebuild for F21 similar to what was done in Fedora recently? Also, will we have support for EL 7 packages? Yep, I was planning to wait for the fedora mass rebuilt to be pushed in order to start it in RPM Fusion. I think it's done already ? We're past the rebuild and past the Fedora branch. Is there any volunteers to track and fix packages that are failing to build in RPM Fusion ? Sure. For EL7 I was still hoping to move to git before to branch for el7, but we are far from that. I'm still at doig the rpkg frontend for RPM Fusion and nobody seems to even figure out the task. I'm still trying to lists tasks in https://bugzilla.rpmfusion.org/show_bug.cgi?id=3023 It not clear on most of these how one can help out. Now as we are far from that, maybe we could do the mass branching from F-19 and people could start hacking the packages they want in this long term branch. It would be nice to have an EL7 branch soon. I've seen two bugzilla requests now for EL7 branches for packages I work on. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: Build Error (Job 20697): VirtualBox-4_3_14-1_fc21 on fedora-development-rpmfusion_free
On 07/24/2014 01:36 PM, Sérgio Basto wrote: Hi, To build VirtualBox on devel we need latest update of lvm2 which hit rawhide today , rpmfusion builders for devel are using rawhide or F21 branch ? . Looks like rawhide to me, just had a failure: DEBUG util.py:257:lcms2-devel-2.6-3.fc21.x86_64: failure: Packages/l/lcms2-devel-2.6-3.fc21.x86_64.rpm from fedora-rawhide: [Errno 256] No more mirrors to try. So I think we need to switch over to the branched f21 and/or branch ourselves pretty quick. I suspect that is in use F21 branch because root.log don't have any fc22 package . If so we have to wait that lvm2-2.02.108 also hits F21 ... On Qui, 2014-07-24 at 21:23 +0200, rpmfusion-build...@lists.rpmfusion.org wrote: Job failed on arch x86_64 Build logs may be found at http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/20697-VirtualBox-4.3.14-1.fc21/ - Checking for Xcursor: found, OK. Checking for Xinerama: found, OK. Checking for Xrandr: found, OK. Checking for Xmu: found, OK. Checking for Mesa / GLU: found (inactive), OK. Checking for Qt4: found version 4.8.6, OK. Checking for Qt4 devtools: found version 4.8.6, OK. Checking for Python support: found version 2.7.7, OK. Checking for Java support: OK. Checking for PulseAudio: found version 5.0.0 API version 12, OK. Checking for ALSA: found version 1.0.27, OK. Checking for libdevmapper: libdevmapper not found at -ldevmapper or libdevmapper headers not found Check the file /builddir/build/BUILD/VirtualBox-4.3.14/configure.log for detailed error information. Check /builddir/build/BUILD/VirtualBox-4.3.14/configure.log for details RPM build errors: error: Bad exit status from /var/tmp/rpm-tmp.eabDvi (%build) Bad exit status from /var/tmp/rpm-tmp.eabDvi (%build) Child return code was: 1 EXCEPTION: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/VirtualBox.spec'] Traceback (most recent call last): File /usr/lib/python2.6/site-packages/mockbuild/trace_decorator.py, line 70, in trace result = func(*args, **kw) File /usr/lib/python2.6/site-packages/mockbuild/util.py, line 352, in do raise mockbuild.exception.Error, (Command failed. See logs for output.\n # %s % (command,), child.returncode) Error: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/VirtualBox.spec'] LEAVE do -- EXCEPTION RAISED -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
RHEL 7 beta
Would it be possible to start building against RHEL 7 beta? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: RPM Fusion (Fedora - free) Package Build Report 2014-01-12
On 01/12/2014 02:50 PM, rpmfusion-pkgs-rep...@rpmfusion.org wrote: Packages built and released for RPM Fusion (Fedora - free) testing/20: 12 buildsys-build-rpmfusion-20-4 NEW dhewm3-1.3.1.1304-21.git6d8108c.fc20 : Dhewm's Doom 3 engine kplayer-0.7.0-10.20081211cvs.fc20 NEW libbdplus-0.1.0-2.fc20 : Open implementation of BD+ protocol minidlna-1.1.1-1.fc20 mplayer-1.1-18.20140111svn.fc20 Can we get this pushed to stable quickly to fix the broken deps? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: Late branching for F-20 because of FFmpeg deps needfix
On 08/26/2013 04:41 AM, Nicolas Chauvet wrote: Hi, Given that FFmpeg was updated without all dependencies fixed to work with it, I will try to make our devel repository to point to branched/F-20 instead of rawhide. (which should point to F-21 packages already) Please remind that I'm not going to update the mock config accordingly, so this will lead to a difference betweek your mock build and the buildsys. I will also issue a mass rebuild once most of the packages got fixed and branch before the middle of September. Are we any closer to branching? What is left to be fixed? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
nVidia CUDA repository
Just a heads up - with the CUDA 5.5 RC release, nVidia is distributing cuda and the 319 binary driver as rpms via a yum repository. The repo rpm is here: http://developer.download.nvidia.com/compute/cuda/repos/fedora18/x86_64/cuda-repo-fedora18-5.5-0.x86_64.rpm which installs: /etc/yum.repos.d/cuda.repo: [cuda] name=cuda baseurl=http://developer.download.nvidia.com/compute/cuda/repos/fedora18/x86_64 enabled=1 gpgcheck=1 gpgkey=http://developer.download.nvidia.com/compute/cuda/repos/GPGKEY As expected there are conflicts with the rpmfusion repository packages. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
akmods (nvidia) for EL?
I've been happily using kmod-nvidia from elrepo for EL for a while now. However, to deal with some issues in the current EL6 kernels I've been using the kernel-lt kernel from elrepo, which is not compatible with the elrepo kmod-nvidia. For those situations it would be nice to have akmods available. Does this seem like a reasonable thing for rpmfusion to provide? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: akmods (nvidia) for EL?
On 11/21/2012 02:56 PM, Nicolas Chauvet wrote:
2012/11/21 Orion Poplawski or...@cora.nwra.com mailto:or...@cora.nwra.com:
I've been happily using kmod-nvidia from elrepo for EL for a while now.
However, to deal with some issues in the current EL6 kernels I've been using
the kernel-lt kernel from elrepo, which is not compatible with the elrepo
kmod-nvidia. For those situations it would be nice to have akmods
available. Does this seem like a reasonable thing for rpmfusion to provide?
Hi Orion,
Yes it's perfectly reasonable to have akmod and even pre-built kmod-foo for EL.
The problem is that currently we do not implement kABI so we need to rebuild
the kernel for each new kernel. (which kABI would essentially avoid).
I don't have time to lead the work, but we need to rebase the tools
(akmod/kmodtool) into devel in order to get ready for later release (EL-7
eventually).
Nicolas (kwizart)
I'm happy to help out in any way including doing the builds if the needed
packages get branched. I've tested some builds locally with:
buildsys-build-rpmfusion-18-0.2.x86_64.rpm
buildsys-build-rpmfusion-kerneldevpkgs-current-18-0.2.x86_64.rpm
akmods-0.3.8-3.el6.noarch.rpm
kmodtool-1-18.el6.noarch.rpm
akmod-nvidia-304.64-1.el6.x86_64.rpm
With the following changes:
diff -u -r1.10 akmods.spec
--- akmods.spec 24 Nov 2011 17:07:00 - 1.10
+++ akmods.spec 21 Nov 2012 22:28:21 -
@@ -39,7 +39,7 @@
# we create a special user that used by akmods to build kmod packages
Requires(pre): shadow-utils
-%if %fedora =16
+%if 0%{?fedora} =16 || 0%{?rhel}
# for the akmods init script:
Requires(post): /sbin/chkconfig
Requires(preun): /sbin/chkconfig
@@ -73,7 +73,7 @@
install -D -p -m 0755 %{SOURCE0} %{buildroot}%{_sbindir}/akmods
install -D -p -m 0755 %{SOURCE2} %{buildroot}%{_bindir}/akmodsbuild
install -D -p -m 0644 %{SOURCE3} %{buildroot}%{_mandir}/man1/akmodsbuild.1
-%if %fedora =16
+%if 0%{?fedora} =16 || 0%{?rhel}
install -D -p -m 0755 %{SOURCE4} %{buildroot}%{_initrddir}/akmods
%else
install -D -p -m 0644 %{SOURCE7} %{buildroot}%{_unitdir}/akmods.service
@@ -90,7 +90,7 @@
-c User is used by akmods to build akmod packages akmods
%post
-%if %fedora =16
+%if 0%{?fedora} =16 || 0%{?rhel}
# add init script
/sbin/chkconfig --add akmods
# enable init script; users that installed akmods directly or indirectly
@@ -107,7 +107,7 @@
%endif
%preun
-%if %fedora =16
+%if 0%{?fedora} =16 || 0%{?rhel}
if [ $1 = 0 ]; then
/sbin/chkconfig --del akmods
fi
@@ -125,7 +125,7 @@
%attr(-,akmods,akmods) %{_localstatedir}/cache/akmods
%{_bindir}/akmodsbuild
%{_sbindir}/akmods
-%if %fedora =16
+%if 0%{?fedora} =16 || 0%{?rhel}
%{_initrddir}/akmods
%else
%{_unitdir}/akmods.service
I also hacked nvidia-kmod.spec so that akmod-nvidia wouldn't require
nvidia-kmod-common so I could keep using the elrepo nvdia driver package.
This seems to be working - the driver loads and X starts.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
Re: Build Error (Job 13876): mplayer-1_1-1_el6 on el-6-rpmfusion_free
On 07/11/2012 03:26 PM, Orion Poplawski wrote: On 07/02/2012 03:11 PM, Richard Shaw wrote: On Mon, Jul 2, 2012 at 3:55 PM, Nicolas Chauvet kwiz...@gmail.com wrote: What I expect is that ffmpeg in EL-6 will better match with mplayer in F-17 as the ffmpeg version is the same. But others components are involved, so you have to test a mock built and do a minimal runtime test. Building now, but I have limited ability to actually test the resulting binary since I don't have a EL6 install available. I'd be happy to test any mplayer packages for EL6. Is what is in el6 updates-testing the latest, or are there other builds needing testing? mplayer and mencoder are working fine for me on EL6. Unfortunately transcode is not (https://bugzilla.rpmfusion.org/show_bug.cgi?id=2417), but hopefully that can be fixed without affecting mplayer. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
mplayer missing Fedora EPEL bugzilla component
mplayer is missing a Fedora EPEL bugzilla component -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: Build Error (Job 13876): mplayer-1_1-1_el6 on el-6-rpmfusion_free
On 07/02/2012 03:11 PM, Richard Shaw wrote: On Mon, Jul 2, 2012 at 3:55 PM, Nicolas Chauvet kwiz...@gmail.com wrote: What I expect is that ffmpeg in EL-6 will better match with mplayer in F-17 as the ffmpeg version is the same. But others components are involved, so you have to test a mock built and do a minimal runtime test. Building now, but I have limited ability to actually test the resulting binary since I don't have a EL6 install available. I'd be happy to test any mplayer packages for EL6. Is what is in el6 updates-testing the latest, or are there other builds needing testing? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com
Re: Build Error (Job 10863): y4mscaler-9_0-9_el6 on el-6-rpmfusion_free
I get the same error when it goes to the builder1.rpmfusion.org builder. On 11/23/2011 05:32 PM, Richard Shaw wrote: I think the old wilson builder is having issues, which is where this one came from. If you have the time, try submitting a build when there's none in the queue and it should go to the new builder. Richard On Wed, Nov 23, 2011 at 5:38 PM, Orion Poplawskior...@cora.nwra.com wrote: Looks like a (the?) builder is having trouble with EL6 builds. Original Message Subject: Build Error (Job 10863): y4mscaler-9_0-9_el6 on el-6-rpmfusion_free Date: Thu, 24 Nov 2011 00:27:54 +0100 (CET) From: rpmfusion-build...@lists.rpmfusion.org To: or...@cora.nwra.com Job failed on arch x86_64 Build logs may be found at http://buildsys.rpmfusion.org/logs/el-6-rpmfusion_free/10863-y4mscaler-9.0-9.el6/ - DEBUG util.py:284: Executing command: mount -n -t devpts -o gid=5,mode=0620,ptmxmode=0666,newinstance mock_chroot_devpts /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/dev/pts DEBUG util.py:323: Child returncode was: 0 DEBUG backend.py:719: mount -n -t tmpfs mock_chroot_shmfs /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/dev/shm DEBUG util.py:284: Executing command: mount -n -t tmpfs mock_chroot_shmfs /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/dev/shm DEBUG util.py:323: Child returncode was: 0 DEBUG backend.py:769: ['/usr/bin/yum', '--installroot', '/var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/', 'groupinstall', 'buildsys-build'] DEBUG util.py:284: Executing command: ['/usr/bin/yum', '--installroot', '/var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/', 'groupinstall', 'buildsys-build', '--setopt=tsflags=nocontexts'] DEBUG util.py:250: Ignored option -c (probably due to merging -yc != -y -c) DEBUG util.py:250: http://mirror.wilsonet.com/rhel/6/Server/x86_64/os/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 403 DEBUG util.py:250: Trying other mirror. DEBUG util.py:250: Error: Cannot retrieve repository metadata (repomd.xml) for repository: el-server. Please verify its path and try again DEBUG util.py:323: Child returncode was: 1 DEBUG util.py:284: Executing command: umount -n /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/dev/shm DEBUG util.py:323: Child returncode was: 0 DEBUG util.py:284: Executing command: umount -n /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/dev/pts DEBUG util.py:323: Child returncode was: 0 DEBUG util.py:284: Executing command: umount -n /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/proc/filesystems DEBUG util.py:323: Child returncode was: 0 DEBUG util.py:284: Executing command: umount -n /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/tmp/ccache DEBUG util.py:323: Child returncode was: 0 DEBUG util.py:284: Executing command: umount -n /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/var/cache/yum DEBUG util.py:323: Child returncode was: 0 DEBUG util.py:284: Executing command: umount -n /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/sys DEBUG util.py:323: Child returncode was: 0 DEBUG util.py:284: Executing command: umount -n /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/proc DEBUG util.py:323: Child returncode was: 0 DEBUG util.py:111: kill orphans DEBUG util.py:83: remove tree: /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed.tmp INFO backend.py:172: chroot (/var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed) unlocked and deleted DEBUG util.py:111: kill orphans -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com
Fwd: Build Error (Job 10863): y4mscaler-9_0-9_el6 on el-6-rpmfusion_free
Looks like a (the?) builder is having trouble with EL6 builds. Original Message Subject: Build Error (Job 10863): y4mscaler-9_0-9_el6 on el-6-rpmfusion_free Date: Thu, 24 Nov 2011 00:27:54 +0100 (CET) From: rpmfusion-build...@lists.rpmfusion.org To: or...@cora.nwra.com Job failed on arch x86_64 Build logs may be found at http://buildsys.rpmfusion.org/logs/el-6-rpmfusion_free/10863-y4mscaler-9.0-9.el6/ - DEBUG util.py:284: Executing command: mount -n -t devpts -o gid=5,mode=0620,ptmxmode=0666,newinstance mock_chroot_devpts /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/dev/pts DEBUG util.py:323: Child returncode was: 0 DEBUG backend.py:719: mount -n -t tmpfs mock_chroot_shmfs /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/dev/shm DEBUG util.py:284: Executing command: mount -n -t tmpfs mock_chroot_shmfs /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/dev/shm DEBUG util.py:323: Child returncode was: 0 DEBUG backend.py:769: ['/usr/bin/yum', '--installroot', '/var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/', 'groupinstall', 'buildsys-build'] DEBUG util.py:284: Executing command: ['/usr/bin/yum', '--installroot', '/var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/', 'groupinstall', 'buildsys-build', '--setopt=tsflags=nocontexts'] DEBUG util.py:250: Ignored option -c (probably due to merging -yc != -y -c) DEBUG util.py:250: http://mirror.wilsonet.com/rhel/6/Server/x86_64/os/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 403 DEBUG util.py:250: Trying other mirror. DEBUG util.py:250: Error: Cannot retrieve repository metadata (repomd.xml) for repository: el-server. Please verify its path and try again DEBUG util.py:323: Child returncode was: 1 DEBUG util.py:284: Executing command: umount -n /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/dev/shm DEBUG util.py:323: Child returncode was: 0 DEBUG util.py:284: Executing command: umount -n /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/dev/pts DEBUG util.py:323: Child returncode was: 0 DEBUG util.py:284: Executing command: umount -n /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/proc/filesystems DEBUG util.py:323: Child returncode was: 0 DEBUG util.py:284: Executing command: umount -n /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/tmp/ccache DEBUG util.py:323: Child returncode was: 0 DEBUG util.py:284: Executing command: umount -n /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/var/cache/yum DEBUG util.py:323: Child returncode was: 0 DEBUG util.py:284: Executing command: umount -n /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/sys DEBUG util.py:323: Child returncode was: 0 DEBUG util.py:284: Executing command: umount -n /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed/root/proc DEBUG util.py:323: Child returncode was: 0 DEBUG util.py:111: kill orphans DEBUG util.py:83: remove tree: /var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed.tmp INFO backend.py:172: chroot (/var/lib/mock/el-6-x86_64-rpmfusion_free-ef9ef1d85511eaa288c6573afe24882cb53e65ed) unlocked and deleted DEBUG util.py:111: kill orphans
Need debug repository info
There is no repodata in http://download1.rpmfusion.org/free/fedora/releases/14/Everything/x86_64/debug/ and nonfree. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com
transcode rebuild for F14 needed
New version of ImageMagick is in F14 updates-testing Error: Package: transcode-1.1.5-4.fc14.i686 (@rpmfusion-free) Requires: libMagickWand.so.3 Removing: ImageMagick-6.6.2.1-11.fc14.i686 (@anaconda-InstallationRepo-201009181840.i386) libMagickWand.so.3 Updated By: ImageMagick-6.6.4.1-14.fc14.i686 (updates-testing) Not found -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com
Google Earth?
Would Google Earth be acceptable as a rpmfusion package? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com
Install foo2* packages by default?
Do we really want to install the foo2* packages by default? Isn't there some kind of automatic printer driver download feature these days that maybe can be used? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com
Re: transcode for EL-5
On Sat, November 29, 2008 10:21 am, Thorsten Leemhuis wrote: Normally just like in Fedora: File a CVSRequest. For details see: http://rpmfusion.org/Contributors/CVSRequests But I try to make things easier for everyone and thus simply added you to owners.epel.list (sorry, didn't get around to it earlier) and adjusted the ACL some minutes ago. Thanks, building -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane [EMAIL PROTECTED] Boulder, CO 80301 http://www.cora.nwra.com
Re: transcode for EL-5
On Thu, November 27, 2008 10:46 pm, Orion Poplawski wrote: On Sun, November 23, 2008 4:44 am, Thorsten Leemhuis wrote: Further please note that David Juran (transcode maintainer in RPM Fusion) said he wanted to take care of all his packages for EL as well, as long as the dependencies are there: http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-August/000792.html Orion, so getting the dependencies into EPEL/RPM Fusion might be all you need to do ;-) But maybe you want to become co-maintainer for EL? Happy to be. Okay, I've got a version of transcode 1.0.7 that builds on EL-5, but it doesn't look like I'm yet a co-maintainer: Access denied: orion is not in ACL for rpms/transcode/EL-5 Not sure how that gets handled -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane [EMAIL PROTECTED] Boulder, CO 80301 http://www.cora.nwra.com
Re: transcode for EL-5
On Sun, November 23, 2008 5:33 pm, Rex Dieter wrote: Dominik 'Rathann' Mierzejewski wrote: On Sunday, 23 November 2008 at 12:44, Thorsten Leemhuis wrote: On 21.11.2008 22:45, Orion Poplawski wrote: [...] transcode is going to depend on a lot... It's not that bad afaics: * transcode needs libdvdread-devel as BR. We are waiting for that to show up in EPEL for some weeks now. Dominik, Rdieter, what the latest status? We really need to get this solved... Well, someone (I don't remember who) didn't want me to push libdvdread-4.1.3 to EPEL until RPMForge agrees to ship it too. I tried to address some of Dag's concerns on their packager's list, but there have been no replies in that thread for over three weeks. Someone = me. ) I had hoped to avoid inducing dep breakage between repos, but we've stated our case, and the others seem to have rejected it, for now. So, it seems we (epsl vs dag/atrpms) mostly agree to disagree at this point. I'm ok with moving forward with the newer libdvdread/libdvdnav in EPEL. I'll give the other repos a heads-up to expect that soon (for better or worse). Okay, looks like libdvdread is available, thanks! Here are the current missing deps: DEBUG util.py:250: No Package Found for mjpegtools-devel DEBUG util.py:250: No Package Found for ImageMagick-devel = 6.4.0.10 Not sure what would be the trouble with earlier ImageMagicks. Available version is: ImageMagick-devel.i386 6.2.8.0-4.el5_1.1 base -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane [EMAIL PROTECTED] Boulder, CO 80301 http://www.cora.nwra.com
Re: transcode for EL-5
On Sun, November 23, 2008 4:44 am, Thorsten Leemhuis wrote: * transcode needs ImageMagick-devel as BR. That is not yet in EPEL. Orion, could you take care of that? ImageMagick is in the base, but an old version. * transcode needs mjpegtools-devel; two problems: ** mjpegtools again requires SDL_gfx as BR, which is branched, but not built in EPEL. I filed a bug some minutes ago: https://bugzilla.redhat.com/show_bug.cgi?id=472678 Appears to be fixed. ** mjpegtools needs a owner for RPM Fusions EL branch. Orion, would you be willing to take care of that? Yes. Further please note that David Juran (transcode maintainer in RPM Fusion) said he wanted to take care of all his packages for EL as well, as long as the dependencies are there: http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-August/000792.html Orion, so getting the dependencies into EPEL/RPM Fusion might be all you need to do ;-) But maybe you want to become co-maintainer for EL? Happy to be. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane [EMAIL PROTECTED] Boulder, CO 80301 http://www.cora.nwra.com
Re: Introduction
On Sun, November 23, 2008 8:56 am, Thorsten Leemhuis wrote: On 23.11.2008 16:16, Orion Poplawski wrote: I'm having trouble checking out unrar: Try again please -- seems your account had not made it's way to the CVS box. Sorry for the trouble. CU knurd still no go: cvs -d :ext:[EMAIL PROTECTED]:/cvs/nonfree co unrar ssh_exchange_identification: Connection closed by remote host cvs [checkout aborted]: end of file from server (consult above messages if any) -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane [EMAIL PROTECTED] Boulder, CO 80301 http://www.cora.nwra.com
Re: Introduction
On Sun, November 23, 2008 4:44 am, Thorsten Leemhuis wrote: On 21.11.2008 22:45, Orion Poplawski wrote: Dominik 'Rathann' Mierzejewski wrote: On Friday, 21 November 2008 at 17:46, Orion Poplawski wrote: Hello. I'm a long time Fedora contributor and sponsor, and long time livna user. I'm interested in seeing more rpmfusion packages available on EL, and looking to help co-maintain those packages. Welcome aboard. A hearty Welcome from me as well! Are there any specific packages you'd like to see on EL? At the moment - transcode and unrar. unrar is yours now. Note that it's built already, so everything should be fine. I'm having trouble checking out unrar: [EMAIL PROTECTED] nonfree]$ cvs -d :ext:[EMAIL PROTECTED]:/cvs/nonfree co unrar Permission denied (publickey,gssapi-with-mic). cvs [checkout aborted]: end of file from server (consult above messages if any) Anything I'm doing wrong? I've uploaded my ssh public key. Running simple ssh with verbose, I see: ssh_exchange_identification: Connection closed by remote host trying to connect to cvs.rpmfusion.org -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane [EMAIL PROTECTED] Boulder, CO 80301 http://www.cora.nwra.com
Introduction
Hello. I'm a long time Fedora contributor and sponsor, and long time livna user. I'm interested in seeing more rpmfusion packages available on EL, and looking to help co-maintain those packages. Account name: orion -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane [EMAIL PROTECTED] Boulder, CO 80301 http://www.cora.nwra.com
Re: Introduction
Dominik 'Rathann' Mierzejewski wrote: On Friday, 21 November 2008 at 17:46, Orion Poplawski wrote: Hello. I'm a long time Fedora contributor and sponsor, and long time livna user. I'm interested in seeing more rpmfusion packages available on EL, and looking to help co-maintain those packages. Welcome aboard. Are there any specific packages you'd like to see on EL? At the moment - transcode and unrar. transcode is going to depend on a lot... -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane [EMAIL PROTECTED] Boulder, CO 80301 http://www.cora.nwra.com
