Re: Removal from default bugzilla CC list

[Julian Sikorski via rpmfusion-developers]

Am 18.01.24 um 12:57 schrieb Dominik 'Rathann' Mierzejewski via 
rpmfusion-developers:

On Thursday, 18 January 2024 at 12:51, Julian Sikorski via rpmfusion-developers 
wrote:

Hi list,

where can I request to be removed as a co-maintainer/default bugzilla CC for
ffmpeg and mplayer? Bug 6843 is the straw that broke the camel's back,
sorry.


I believe here: https://admin.rpmfusion.org/pkgdb/package/free/ffmpeg/
and here: https://admin.rpmfusion.org/pkgdb/package/free/mplayer/

It's unfortunate that Cisco repo for rawhide was not populated in time.
This is being worked on from two angles, actually. One is getting those
openh264 packages in place, finally, and another is introducing an
openh264 stub into Fedora to avoid broken dependencies in case the
upload is delayed again.

Regards,
Dominik
Thanks! It's not about the bug itself. The intense discussion made me 
realise that I have not contributed to mplayer and/or ffmpeg for a 
really long time. The way I consume media has also changed in the recent 
years so it is just time to move on.


Best regards,
Julian
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

Removal from default bugzilla CC list

[Julian Sikorski via rpmfusion-developers]

Hi list,

where can I request to be removed as a co-maintainer/default bugzilla CC 
for ffmpeg and mplayer? Bug 6843 is the straw that broke the camel's 
back, sorry.


Best regards,
Julian
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

nvidia power management

[Julian Sikorski]

Hello,

I have recently experienced a resume failure with nvidia [1]. Upon 
deeper investigation, it turns out that PreserveVideoMemoryAllocations 
was enabled recently [2]. According to documentation [3] and to Arch 
Wiki [4], for this option to work, nvidia systemd units need to be 
enabled (nvidia-resume is not recommended by Arch). They are not on my 
machine:


$ sudo systemctl status nvidia-suspend.service nvidia-resume.service 
nvidia-hibernate.service

[sudo] hasło użytkownika julas:
○ nvidia-suspend.service - NVIDIA system suspend actions
 Loaded: loaded (/usr/lib/systemd/system/nvidia-suspend.service; 
disabled; vendor preset: disabled)

 Active: inactive (dead)

○ nvidia-resume.service - NVIDIA system resume actions
 Loaded: loaded (/usr/lib/systemd/system/nvidia-resume.service; 
disabled; vendor preset: disabled)

 Active: inactive (dead)

○ nvidia-hibernate.service - NVIDIA system hibernate actions
 Loaded: loaded (/usr/lib/systemd/system/nvidia-hibernate.service; 
disabled; vendor preset: disabled)

 Active: inactive (dead)

I am not sure what Fedora's policy on enabling systemd units by default 
is, but it appears like either the systemd units need to be enabled or
PreserveVideoMemoryAllocations should be rolled back. With 
nvidia-suspend and nvidia-hibernate enabled, my machine does suspend 
correctly again. With nvidia-resume enabled, it also does resume 
properly. Without it, machine resumes but the screen does not re-activate.


Best regards,
Julian

[1] 
https://forums.developer.nvidia.com/t/occassional-failure-to-resume-pci-pm-suspend-nv-pmops-suspend-0x0-0x20-nvidia-returns-5/187091
[2] 
https://pkgs.rpmfusion.org/cgit/nonfree/xorg-x11-drv-nvidia.git/commit/?id=97658520e3e4c36617c0e926932ae1aaf162cc57
[3] 
http://download.nvidia.com/XFree86/Linux-x86_64/470.63.01/README/powermanagement.html
[4] 
https://wiki.archlinux.org/title/NVIDIA/Tips_and_tricks#Preserve_video_memory_after_suspend

___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

Re: Packaging libopenaptx for pipewire

[Julian Sikorski]

Am 17.07.21 um 02:37 schrieb Sérgio Basto:

Hi, Julian

this emsil was marked as SPAM because
   1.0 FORGED_GMAIL_RCVD  'From' gmail.com does not match 'Received'
  headers
   1.0 FORGED_SPF_HELONo description available.
   4.0 SPF_FAIL   SPF: sender does not match SPF record
(fail)
   2.3 FORGED_MUA_MOZILLA Forged mail pretending to be from Mozilla



Hi Sergio,

I am not sure what happened. I tried sending email via the gmane 
gateway. Moreover, Gombos' email was sent as an .eml attachment. Maybe 
this is why my message was flagged as spam.
In the meantime I have realised that libopenaptx maintainer has changed 
the license in version 0.2.1 to explicitly make it incompatible with 
pipewire and/or pulseaudio. As a response, pipewire depends on 
libopenaptx versions up to 0.2.0. Depending on how much work it would be 
to create pipewire-freeworld, it might be worth waiting to see how this 
situation develops.


Best regards,
Julian
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

Re: Packaging libopenaptx for pipewire

[Julian Sikorski]

Am 18.12.20 um 00:17 schrieb Gombos Gergely via rpmfusion-developers:


Re: Packaging libopenaptx for pipewire.eml

Betreff:
Re: Packaging libopenaptx for pipewire
Von:
Gombos Gergely 
Datum:
18.12.20, 00:17

An:
rpmfusion-developers@lists.rpmfusion.org
Kopie (CC):
pa...@iki.fi


Hi,

Update: I received info that aptX patents have expired. I'm optimistic
so I'm submitting to Fedora first. We'll see.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922

Best regards,
Greg

2020. 12.  17, csütörtök keltezéssel 22.22-kor Gombos Gergely ezt írta:

Hi,

I'm the packager of pulseaudio-module-bluetooth-freeworld.
It provides AAC, LDAC and aptX for Bluetooth users. I think quite
many
Fedora users depend on it.

There's a lot going on in Fedora regarding pipewire, and a question
for
me is BT support. The upstream devs of pulseaudio-module-bluetooth-
freeworld are also contributing to pipewire, fortunately.

See this:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/249

It's literally improving day by day.

What seems to be the case is that pipewire can already be built with
aptX and ldac support:
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/spa/meson.build#L31-32

Distros who don't care about licenses so much like Arch already build
it with these as dependencies:
https://www.archlinux.org/packages/extra/x86_64/pipewire/

In Fedora this may not be as simple.:)

LDAC is not an issue, that's packaged in Fedora.

Pali's libopenaptx is not packaged yet:
https://github.com/pali/libopenaptx

It's LGPL2.1, but apparently contains "derived from ffmpeg 4.0
project"
stuff. Is there a chance that this can make its way into Fedora,
given
that ffmpeg is in rpmfusion due to patent encumberance?

If you are sure it can't then I can save myself from waiting for
legal
reviews etc.:)

The other question is then, how to enable aptX in pipewire in case
libopenaptx can only be packaged in rpmfusion?

Only by shipping some pipewire-free which is essentially pipewire
with
added rpmfusion dependencies? Or should we start encouraging upstream
to create some modular system for this, so that these codecs/BT
support
are in more easily replacable libraries? (Like pulseaudio-module-
bluetooth is)

I appreciate your help on this!

Best regards,
Greg

___
rpmfusion-developers mailing list --rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email torpmfusion-developers-le...@lists.rpmfusion.org


Hi,

Fedora is not willing to package libopenaptx due to unclear patent 
situation. In the review you mentioned that using dlopen for bluetooth 
codecs is on pipewire's roadmap. Do we know how far down the line that 
is? Would it make sense to work on pipewire-freeworld package?
In any case, I think it makes sense to put libopenaptx in rpmfusion, 
dlopen or not.


Best regards,
Julian
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

Updating F27 and F26 ffmpeg to 3.3

[Julian Sikorski]

Hi List,

ffmpeg-3.3 was released recently and I would like to suggest that we
update f27 and f26 to it. Unfortunately, mockchain is currenly broken
[1] which means I cannot proceed with my usual local rebuild. Any
suggestions how we could proceed?

Best regards,
Julian

[1] https://github.com/rpm-software-management/mock/issues/65
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

Re: Update ffmpeg in F24 to 3.1.x ?

[Julian Sikorski]

W dniu 23.11.2016 o 09:14, Xavier Bachelot pisze:
> Hi,
> 
> On 23/11/2016 08:41, Michael Cronenworth wrote:
>> On 10/14/2016 11:09 AM, Sérgio Basto wrote:
>>> I think we can perform the mass rebuild (or not) just in F24 without
>>> touching F25 and rawhide.
>>
>> May I ask why a mass rebuild was not performed?
>>
>> I just uncovered an issue with the FFMpeg 3.1 update. Kodi core dumps
>> when attempting to play MPEG2 streams. A rebuild fixes it. I'm pushing
>> through one now for F24.
>>
>> In the future let's please be more careful with these updates. There
>> certainly were some small ABI changes and upstream dropped the ball on
>> announcing them.
>>
>> Thanks,
>> Michael
> 
> There are tools to check for ABI changes, announced or not.
> http://upstream.rosalinux.ru/index.html
> 
> Here's the link for ffmpeg :
> https://abi-laboratory.pro/tracker/timeline/ffmpeg/
> 
> Regards,
> Xavier
> 
Thanks for the link! Having said that, the tracker shows that no symbols
were removed so we would have been at a loss anyway.

Best regards,
Julian

Re: Update ffmpeg in F24 to 3.1.x ?

[Julian Sikorski]

W dniu 12.10.2016 o 16:15, Kevin Kofler pisze:
> Michael Cronenworth wrote:
>> This is not ideal. The ffmpeg 3.0.x branch is not going unmaintained
>> AFAIK. We can't push out a big rebuild of a major library so one, new
>> package can be introduced into F24.
> 
> Huh? Upstream says 3.1 is API- and ABI-compatible to 3.0 (with only one 
> application needed fixing for some reason),

Could you please point me to a reference for this? I looked around a bit
but couldn't find one. Thanks!

 so it should be perfectly
> suitable as an update. This is similar to Qt upgrades that have often been 
> done in Fedora (where there are also a few odd packages that invariably need 
> rebuilding due to (ab)using private Qt APIs).
> 
> Introducing a second package for the new version is a horrible idea, it will 
> lead to symbol conflicts (in applications accidentally transitively linking 
> both versions) and a waste of space. I would just upgrade the existing 
> package to the new version.
> 
> Kevin Kofler
> 

Re: Updating ffmpeg to 3.2 in rawhide

[Julian Sikorski]

W dniu 29.10.2016 o 21:37, Sérgio Basto pisze:
> On Sáb, 2016-10-29 at 11:01 +0200, Julian Sikorski wrote:
>> Hi list,
>>
>> ffmpeg-3.2 was released two days ago. As mentioned by Nicolas, this
>> update is only in scope for F26 currently. The good news is that it
>> is
>> looking better than I ever remember ffmpeg rebase to be:
>> - there are currently 48 ffmpeg dependencies in rpmfusion git
>> - 46 build fine against 3.2 with no changes required
>> - kodi requires an upstream patch [1]
>> - gpac fails due to what looks to be an openssl issue (undefined
>> reference to `SSLeay_add_all_algorithms'), likely caused by the
>> openssl-1.0.2j → openssl-1.1.0b bump in Fedora. build.log attached.
> 
> 
> And about also update ffmpeg in F24 to the same of F25 ? also we should
> think in x265 not yet updated to 2.0+ .

Was a final decision reached regarding this? I saw a discussion thread
on the ML but this is it.

> 
> As my reasons I'd like leave F23 most correctly as possible i.e. with
> appstream , and leave F24 with ffmpeg 3 , for my very personal schedule
> , update in rawhide just after F23 eol, until then I will focus on
> stable and F25 GA . 
> 
> Cheers,
> 
>> Given the above, I would be looking at updating ffmpeg and rebuilding
>> its dependencies next weekend at the latest. Should anyone disagree,
>> please speak up.
>>
>> Best regards,
>> Julian
>>
>> [1]
>> https://github.com/xbmc/xbmc/commit/2e2e7a5e7ff18dcf3ba3fae2d2ea6d0d9
>> b42b7ea

Re: Updating ffmpeg to 3.2 in rawhide

[Julian Sikorski]

W dniu 02.11.2016 o 19:09, Nicolas Chauvet pisze:
> 2016-10-29 11:01 GMT+02:00 Julian Sikorski <beleg...@gmail.com>:
>> Hi list,
>>
>> ffmpeg-3.2 was released two days ago. As mentioned by Nicolas, this
>> update is only in scope for F26 currently. The good news is that it is
>> looking better than I ever remember ffmpeg rebase to be:
>> - there are currently 48 ffmpeg dependencies in rpmfusion git
>> - 46 build fine against 3.2 with no changes required
>> - kodi requires an upstream patch [1]
>> - gpac fails due to what looks to be an openssl issue (undefined
>> reference to `SSLeay_add_all_algorithms'), likely caused by the
>> openssl-1.0.2j → openssl-1.1.0b bump in Fedora. build.log attached.
>>
>> Given the above, I would be looking at updating ffmpeg and rebuilding
>> its dependencies next weekend at the latest. Should anyone disagree,
>> please speak up.
> 
> Thx for your excellent work Julian!
> 
> Just a note that since there is no ABI break, there is no need to
> rebuild everything, I prefer to schedule the rebuild at a later point
> in the f26 development as we will probably have a mass rebuild there
> anyway.
> (and specially after the f25 release since I will need resources to
> build the f25 repos in the coming days).
> 
> I'm fine to have the ffmpeg updated package (along with x264/x265
> update if needed).

Thank you! ffmpeg-3.2 build has now been submitted. As requested, I will
not be queueing a rebuild at this point.

> 
> Btw, do you have time to review the patch I've made for ffmpeg nonfree
> in https://bugzilla.rpmfusion.org/show_bug.cgi?id=4243
> Thx
> 
> 
> 
I do not feel qualified to review the patch in its entirety. What I have
done is incorporated some of the cleanups into the update.

Julian

Re: Updating ffmpeg to 3.2 in rawhide

[Julian Sikorski]

W dniu 02.11.2016 o 19:09, Nicolas Chauvet pisze:
> 2016-10-29 11:01 GMT+02:00 Julian Sikorski 
> <belegdol-re5jqeeqqe8avxtiumw...@public.gmane.org>:
>> Hi list,
>>
>> ffmpeg-3.2 was released two days ago. As mentioned by Nicolas, this
>> update is only in scope for F26 currently. The good news is that it is
>> looking better than I ever remember ffmpeg rebase to be:
>> - there are currently 48 ffmpeg dependencies in rpmfusion git
>> - 46 build fine against 3.2 with no changes required
>> - kodi requires an upstream patch [1]
>> - gpac fails due to what looks to be an openssl issue (undefined
>> reference to `SSLeay_add_all_algorithms'), likely caused by the
>> openssl-1.0.2j → openssl-1.1.0b bump in Fedora. build.log attached.
>>
>> Given the above, I would be looking at updating ffmpeg and rebuilding
>> its dependencies next weekend at the latest. Should anyone disagree,
>> please speak up.
> 
> Thx for your excellent work Julian!
> 
> Just a note that since there is no ABI break, there is no need to
> rebuild everything, I prefer to schedule the rebuild at a later point
> in the f26 development as we will probably have a mass rebuild there
> anyway.
> (and specially after the f25 release since I will need resources to
> build the f25 repos in the coming days).
> 
> I'm fine to have the ffmpeg updated package (along with x264/x265
> update if needed).

Thank you! ffmpeg-3.2 build has now been submitted. As requested, I will
not be queueing a rebuild at this point.

> 
> Btw, do you have time to review the patch I've made for ffmpeg nonfree
> in https://bugzilla.rpmfusion.org/show_bug.cgi?id=4243
> Thx
> 
> 
> 
I do not feel qualified to review the patch in its entirety. What I have
done is incorporated some of the cleanups into the update.

Julian

Updating ffmpeg to 3.2 in rawhide

[Julian Sikorski]

Hi list,

ffmpeg-3.2 was released two days ago. As mentioned by Nicolas, this
update is only in scope for F26 currently. The good news is that it is
looking better than I ever remember ffmpeg rebase to be:
- there are currently 48 ffmpeg dependencies in rpmfusion git
- 46 build fine against 3.2 with no changes required
- kodi requires an upstream patch [1]
- gpac fails due to what looks to be an openssl issue (undefined
reference to `SSLeay_add_all_algorithms'), likely caused by the
openssl-1.0.2j → openssl-1.1.0b bump in Fedora. build.log attached.

Given the above, I would be looking at updating ffmpeg and rebuilding
its dependencies next weekend at the latest. Should anyone disagree,
please speak up.

Best regards,
Julian

[1]
https://github.com/xbmc/xbmc/commit/2e2e7a5e7ff18dcf3ba3fae2d2ea6d0d9b42b7ea


build.log.xz
Description: application/xz

Re: mlt-freeworld Re: updating ffmpeg to 3.1.x in rawhide

[Julian Sikorski]

W dniu 31.07.2016 o 17:12, Sérgio Basto pisze:
> On Dom, 2016-07-31 at 09:41 +0200, Julian Sikorski wrote:
>> The mlt failure is due to php-7.0:
>> http://koji.rpmfusion.org/koji/taskinfo?taskID=15442
> 
> Hello Julian , great work ! , can you share yours scripts :), I'm
> curious ...
> 
> For F25 we need make a new package mlt-freeworld , since we have
> packaged mlt in Fedora proper since F25 but without ffmpeg support, who
> can help ? , should be easy . 
> 
> Thanks , 
> 
Please see attached - that script fetches all ffmpeg deps and does a
mockchain rebuild.
For submitting updates, I don't have a script; it's just a for loop.

Best regards,
Julian


ffmpeg-dep-checker.sh
Description: application/shellscript

Re: updating ffmpeg to 3.1.x in rawhide

[Julian Sikorski]

W dniu 31.07.2016 o 19:19, Jonathan Underwood pisze:
> Oh dear, seems 0.17.4 fails to build on the devel branch with the new
> ffmpeg. Looking into it.
> 
https://xpra.org/trac/changeset/12943/xpra


> xpra/codecs/dec_avcodec2/decoder.c: In function
> '__pyx_pf_4xpra_6codecs_12dec_avcodec2_7decoder_7Decoder_22decompress_image':
> xpra/codecs/dec_avcodec2/decoder.c:7504:9: error:
> 'avcodec_decode_video2' is deprecated
> [-Werror=deprecated-declarations]
>  __pyx_v_len = avcodec_decode_video2(__pyx_v_self->codec_ctx,
> __pyx_v_self->av_frame, (&__pyx_v_got_picture), (&__pyx_v_avpkt));
>  ^~~
> In file included from xpra/codecs/dec_avcodec2/decoder.c:279:0:
> /usr/include/ffmpeg/libavcodec/avcodec.h:4753:5: note: declared here
>  int avcodec_decode_video2(AVCodecContext *avctx, AVFrame *picture,
>  ^
> cc1: all warnings being treated as errors
> error: command 'gcc' failed with exit status 1
> 
> 
> On 31 July 2016 at 18:08, Jonathan Underwood
> <jonathan.underw...@gmail.com> wrote:
>> xpra-codecs-rfeeworld is now updated to 0.17.4 on F23, F24 and devel
>> branches. Builds have been pushed.
>>
>> It looks like there's no need to manually push packages to
>> updates-testing, and that it happens automatically - is that correct?
>>
>> Cheers,
>> Jonathan
>>
>> On 31 July 2016 at 11:09, Jonathan Underwood
>> <jonathan.underw...@gmail.com> wrote:
>>> I'll work on moving to xpra 0.17.4 in fedora this evening, and will do
>>> similarly for the rpm fusion package.
>>>
>>>
>>> On 31 Jul 2016 08:41, "Julian Sikorski" <beleg...@gmail.com> wrote:
>>>>
>>>> W dniu 31.07.2016 o 07:29, Julian Sikorski pisze:
>>>>> W dniu 28.07.2016 o 07:41, Julian Sikorski pisze:
>>>>>> W dniu 28.07.2016 o 04:48, Sérgio Basto pisze:
>>>>>>> On Qua, 2016-07-27 at 20:18 +0200, Julian Sikorski wrote:
>>>>>>>> I have done a test rebuild and found the following:
>>>>>>>> - there are currently 40 packages dependent on ffmpeg
>>>>>>>> - out of those, 37 rebuilt correctly
>>>>>>>> - 3 have failed:
>>>>>>>>   - kodi: failure looks related to curl, not to ffmpeg
>>>>>>>>   - mlt: strange error, something about zval. build.log crashes gedit
>>>>>>>>   - xpra-codecs-freeworld: avcodec_decode_video2 is deprecated
>>>>>>>>
>>>>>>>> Given the small number of failures, I would be aiming to push the new
>>>>>>>> ffmpeg to rawhide and rebuild dependent packages on Saturday. Please
>>>>>>>> speak up if you don't agree.
>>>>>>>
>>>>>>> Julian, I agree , "and rebuild dependent packages on Saturday" do you
>>>>>>> do the mass rebuild ? or need help ?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>> I can do the mass rebuild, I have the privileges now.
>>>>>>
>>>>>> Best regards,
>>>>>> Julian
>>>>>>
>>>>> The mass rebuild has now been completed.
>>>>>
>>>>> Best regards,
>>>>> Julian
>>>>>
>>>> I have now rebuilt kodi as well as the maintainer has fixed the curl
>>>> issue.
>>>> For xpra, there is a patch in upstream svn (revision 12943), but it does
>>>> not apply cleanly to 0.16.x branch. I'll leave it up to the maintainer
>>>> whether backporting is worth the effort, or will it just be easier to
>>>> rebase to 0.17.x
>>>> The mlt failure is due to php-7.0:
>>>> http://koji.rpmfusion.org/koji/taskinfo?taskID=15442
>>>>
>>>> Best regards,
>>>> Julian

Re: updating ffmpeg to 3.1.x in rawhide

[Julian Sikorski]

W dniu 31.07.2016 o 07:29, Julian Sikorski pisze:
> W dniu 28.07.2016 o 07:41, Julian Sikorski pisze:
>> W dniu 28.07.2016 o 04:48, Sérgio Basto pisze:
>>> On Qua, 2016-07-27 at 20:18 +0200, Julian Sikorski wrote:
>>>> I have done a test rebuild and found the following:
>>>> - there are currently 40 packages dependent on ffmpeg
>>>> - out of those, 37 rebuilt correctly
>>>> - 3 have failed:
>>>>   - kodi: failure looks related to curl, not to ffmpeg
>>>>   - mlt: strange error, something about zval. build.log crashes gedit
>>>>   - xpra-codecs-freeworld: avcodec_decode_video2 is deprecated
>>>>
>>>> Given the small number of failures, I would be aiming to push the new
>>>> ffmpeg to rawhide and rebuild dependent packages on Saturday. Please
>>>> speak up if you don't agree.
>>>
>>> Julian, I agree , "and rebuild dependent packages on Saturday" do you
>>> do the mass rebuild ? or need help ?  
>>>
>>> Thanks,
>>>
>> I can do the mass rebuild, I have the privileges now.
>>
>> Best regards,
>> Julian
>>
> The mass rebuild has now been completed.
> 
> Best regards,
> Julian
> 
I have now rebuilt kodi as well as the maintainer has fixed the curl issue.
For xpra, there is a patch in upstream svn (revision 12943), but it does
not apply cleanly to 0.16.x branch. I'll leave it up to the maintainer
whether backporting is worth the effort, or will it just be easier to
rebase to 0.17.x
The mlt failure is due to php-7.0:
http://koji.rpmfusion.org/koji/taskinfo?taskID=15442

Best regards,
Julian

Re: updating ffmpeg to 3.1.x in rawhide

[Julian Sikorski]

W dniu 28.07.2016 o 07:41, Julian Sikorski pisze:
> W dniu 28.07.2016 o 04:48, Sérgio Basto pisze:
>> On Qua, 2016-07-27 at 20:18 +0200, Julian Sikorski wrote:
>>> I have done a test rebuild and found the following:
>>> - there are currently 40 packages dependent on ffmpeg
>>> - out of those, 37 rebuilt correctly
>>> - 3 have failed:
>>>   - kodi: failure looks related to curl, not to ffmpeg
>>>   - mlt: strange error, something about zval. build.log crashes gedit
>>>   - xpra-codecs-freeworld: avcodec_decode_video2 is deprecated
>>>
>>> Given the small number of failures, I would be aiming to push the new
>>> ffmpeg to rawhide and rebuild dependent packages on Saturday. Please
>>> speak up if you don't agree.
>>
>> Julian, I agree , "and rebuild dependent packages on Saturday" do you
>> do the mass rebuild ? or need help ?  
>>
>> Thanks,
>>
> I can do the mass rebuild, I have the privileges now.
> 
> Best regards,
> Julian
> 
The mass rebuild has now been completed.

Best regards,
Julian

Re: rpmfusion rawhide is currently broken hold your build

[Julian Sikorski]

W dniu 30.07.2016 o 15:45, Julian Sikorski pisze:
> W dniu 30.07.2016 o 12:09, Nicolas Chauvet pisze:
>> 2016-07-30 10:04 GMT+02:00 Julian Sikorski <beleg...@gmail.com>:
>>> W dniu 28.07.2016 o 15:29, Nicolas Chauvet pisze:
>>>> 2016-07-28 8:47 GMT+02:00 Nicolas Chauvet <kwiz...@gmail.com>:
>>>>> Hi,
>>>>>
>>>>> As fedora is now branched for f25, we will do the same in RPM Fusion 
>>>>> shortly
>>>>> Now until before it's done we need to adapt the koji external repo URL
>>>>> to switch to f25 rawhide.
>>>>>
>>>>> Unfornunately they aren't published right now, so please hold your master 
>>>>> build
>>>>> http://dl.fedoraproject.org/pub/fedora/linux/development/25/
>>>>> http://dl.fedoraproject.org/pub/fedora/linux/updates/testing/
>>>>
>>>> This is now adapted.
>>>>
>>>> The RPM Fusion branching will occurs in less than a week from now
>>>> (around the 3rd August) as we currently plan.
>>>> f25 branch will be created from master, the latter will then target fc26.
>>>>
>>>> Thx
>>>>
>>> My ffmpeg build has failed. checkout.log contains the following:
>>>
>>> $ git clone -n git://pkgs.fedoraproject.org/free/ffmpeg
>>> /var/lib/mock/f26-build-6125083-623628/root/tmp/scmroot/ffmpeg
>>> Cloning into
>>> '/var/lib/mock/f26-build-6125083-623628/root/tmp/scmroot/ffmpeg'...
>>> fatal: remote error: access denied or repository not exported: /free/ffmpeg
>>
>> We are not bundling on fedoraproject koji, use rfpkg build instead ;)
>> Probably we need to find a way to detect this kind of issue earlier.
>> Anyone to submit a RFE to fedpkg or pyrpkg ?
>>
>> Thx
>>
>>
> Oops, sorry. Looks like I need to drink my coffee and then submit
> builds, not the other way round.
> 
> Best regards,
> Julian
> 
Hmm, now it fails because of buildroot issues - selinux-policy and
kernel-headers are not found.
http://koji.rpmfusion.org/kojifiles/work/tasks/4920/14920/root.log

Is this something we can fix?

Julian

Re: rpmfusion rawhide is currently broken hold your build

[Julian Sikorski]

W dniu 28.07.2016 o 15:29, Nicolas Chauvet pisze:
> 2016-07-28 8:47 GMT+02:00 Nicolas Chauvet :
>> Hi,
>>
>> As fedora is now branched for f25, we will do the same in RPM Fusion shortly
>> Now until before it's done we need to adapt the koji external repo URL
>> to switch to f25 rawhide.
>>
>> Unfornunately they aren't published right now, so please hold your master 
>> build
>> http://dl.fedoraproject.org/pub/fedora/linux/development/25/
>> http://dl.fedoraproject.org/pub/fedora/linux/updates/testing/
> 
> This is now adapted.
> 
> The RPM Fusion branching will occurs in less than a week from now
> (around the 3rd August) as we currently plan.
> f25 branch will be created from master, the latter will then target fc26.
> 
> Thx
> 
My ffmpeg build has failed. checkout.log contains the following:

$ git clone -n git://pkgs.fedoraproject.org/free/ffmpeg
/var/lib/mock/f26-build-6125083-623628/root/tmp/scmroot/ffmpeg
Cloning into
'/var/lib/mock/f26-build-6125083-623628/root/tmp/scmroot/ffmpeg'...
fatal: remote error: access denied or repository not exported: /free/ffmpeg

Best regards,
Julian

Re: updating ffmpeg to 3.1.x in rawhide

[Julian Sikorski]

W dniu 28.07.2016 o 04:48, Sérgio Basto pisze:
> On Qua, 2016-07-27 at 20:18 +0200, Julian Sikorski wrote:
>> I have done a test rebuild and found the following:
>> - there are currently 40 packages dependent on ffmpeg
>> - out of those, 37 rebuilt correctly
>> - 3 have failed:
>>   - kodi: failure looks related to curl, not to ffmpeg
>>   - mlt: strange error, something about zval. build.log crashes gedit
>>   - xpra-codecs-freeworld: avcodec_decode_video2 is deprecated
>>
>> Given the small number of failures, I would be aiming to push the new
>> ffmpeg to rawhide and rebuild dependent packages on Saturday. Please
>> speak up if you don't agree.
> 
> Julian, I agree , "and rebuild dependent packages on Saturday" do you
> do the mass rebuild ? or need help ?  
> 
> Thanks,
> 
I can do the mass rebuild, I have the privileges now.

Best regards,
Julian

Re: updating ffmpeg to 3.1.x in rawhide

[Julian Sikorski]

W dniu 27.07.2016 o 22:34, Sandro Mani pisze:
> 
> 
> On 27.07.2016 21:38, Julian Sikorski wrote:
>> [...]
>> http://lesloueizeh.com/belegdol/ffmpeg-3.1.1-1.fc25.src.rpm
> 
> Patch: https://smani.fedorapeople.org/ffmpeg_opj2.patch
> 
> Not sure why they insist on defining OPJ_STATIC, but we're definitely
> not statically linking openjpeg...
> 
> The reason for the build failure is that OPJ_STATIC makes all API
> symbols hidden:
> 
> #define OPJ_API__attribute__ ((visibility ("hidden")))
> 
> 
> Best
> Sandro
> 
Thanks! Do you mind if I send this to ffmpeg upstream? Or would you be
willing to do it in case there are questions?

Best regards,
Julian

Re: updating ffmpeg to 3.1.x in rawhide

[Julian Sikorski]

W dniu 27.07.2016 o 21:27, Sandro Mani pisze:
> 
> 
> On 27.07.2016 21:24, Julian Sikorski wrote:
>> W dniu 27.07.2016 o 20:27, Sandro Mani pisze:
>>>
>>> On 27.07.2016 20:18, Julian Sikorski wrote:
>>>> Hi list,
>>>>
>>>> now that the dust following the f24 release and related infra work
>>>> (thank you everyone involved) has settled, I believe we should update
>>>> ffmpeg to 3.1.x in f25. While we will likely need to update once again
>>>> to 3.2.x before f25 release (ffmpeg runs on 3 monthly schedule as
>>>> opposed to Fedora's 6 months), updating early allows to weed out any
>>>> build issues early on.
>>>> I have done a test rebuild and found the following:
>>>> - there are currently 40 packages dependent on ffmpeg
>>>> - out of those, 37 rebuilt correctly
>>>> - 3 have failed:
>>>> - kodi: failure looks related to curl, not to ffmpeg
>>>> - mlt: strange error, something about zval. build.log crashes gedit
>>>> - xpra-codecs-freeworld: avcodec_decode_video2 is deprecated
>>>>
>>>> Given the small number of failures, I would be aiming to push the new
>>>> ffmpeg to rawhide and rebuild dependent packages on Saturday. Please
>>>> speak up if you don't agree.
>>> Just a curiosity, will you be building against openjpeg2? This would be
>>> a good opportunity to do so, since the openjpeg 1.x series looks dead
>>> upstream and has some unfixed CVEs [1]. According to [2] openjpeg2
>>> support should have landed some time ago in ffmpeg.
>>>
>>> Thanks
>>> Sandro
>>>
>>>
>>> [1]
>>> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=openjpeg_id=5547156=Importance=Fedora_format=advanced
>>>
>>>
>>> [2] https://trac.ffmpeg.org/ticket/2016
>>>
>> Thanks for the idea! The problem is that openjpeg2 build is broken
>> currently:
>>
>> https://trac.ffmpeg.org/ticket/5694
> If you have a ffmpeg-3.1.x SRPM I can have a look if you want, and if
> necessary patch the openjpeg2 package (I maintain it).
> 
> Best
> Sandro
> 
http://lesloueizeh.com/belegdol/ffmpeg-3.1.1-1.fc25.src.rpm

Re: Workaround of some buildroot failure and ffmpeg

[Julian Sikorski]

W dniu 07.07.2016 o 08:17, Julian Sikorski pisze:
> W dniu 06.07.2016 o 23:44, Nicolas Chauvet pisze:
>> There are still some issues with buildroot, some of theses are
>>
>>
>> - ffmpeg is broken in rawhide. probably because of some header changes
>> with opencv. There is a need for someone to look into for a real fix.
> 
> The failure is due to the fact that opencv in rawhide got updated to
> version 3. I have now fixed it by backporting a patch from upstream git.
> In the longer term will need to rebase to 3.1 though.

ffmpeg built but is not listed in koji build for some strange reason,
please may you check?
http://koji.rpmfusion.org/koji/buildinfo?buildID=787
> 
>> - Missing buildroot dependencies. This is a known issue with koji when
>> using external repos (for fedoras package), I can only say that this
>> is a known issue and here is the suggested fix:
>> https://bugzilla.rpmfusion.org/show_bug.cgi?id=3024
>> The workaround still need to be implemented, but it won't work as fine
>> as on the pre-infra where I was the only one to submit build job (and
>> kick a new createrepo task if there are any failure).
>> - Errror with groupadd, should be workarounded, (origial bugzilla is
>> https://bugzilla.redhat.com/show_bug.cgi?id=1060811)
>> - rfpkg needs to be removed from the default buildroot and use
>> rfpkg-minimal instead.
>> This is a simple task that anyone can take. (convert and create
>> rfpkg-minimal rpm package based on fedpkg-minimal)
>>
>> Don't forget that you need rfpkg-1.23.4 from koji.rpmfusion.org to
>> submit build correctly. I will push them before this week-end
>> (hopefully with ffmpeg fixed for rawhide).
>>
>> Thx
>>
>>
> 

Re: How much RAM do the arm builders have?

[Julian Sikorski]

W dniu 06.07.2016 o 13:55, Nicolas Chauvet pisze:
> 2016-07-05 7:35 GMT+02:00 Julian Sikorski 
> <belegdol-re5jqeeqqe8avxtiumw...@public.gmane.org>:
>> Hi list,
>>
>> first of all thank you to Nicolas, Sergio and others for setting up the
>> new infra! Keep up the good work guys!
>> May I ask how much memory do the arm build servers have available? My
>> qmc2 and mame builds have both failed due to memory exhaustion. While I
>> am in the process of moving them to Fedora proper, this issue might end
>> up affecting other packages as well. Both qmc2 and mame built fine on
>> i686 and on x86_64 so this could be used as an indication of how much
>> memory is sufficient.
>> Thank you for the information in advance.
>>
> 
> Arm builder have 2GB, thoses are dedicated hardware, so we cannot add
> more RAM on theses.
> They are the same we have always used, so unless something have
> changed in the toolchain, the package should build fine.
> That been said, there are some memory issues with rsyslog and
> arm-builder01 gone unstable (rebooted since then).
> I don't know if it's the cause or consequence, but I will resubmit
> jobs one by one.

There is no need to resubmit mame - the review request has just been
approved :) I will be moving qmc2 soon too but we can build it on RPM
Fusion for now. Thank you again!

> 
> If it still doesn't build on arm as previously, please use
> ExcludeArch: armv7hl and add a bug entry with a blocker to #2407
> (arm-ftbfs) in our bugzilla.
> 
> FYI, x86_64 builders are 4GB VM, 2vCPU
> 
> Thx
> 
> 

How much RAM do the arm builders have?

[Julian Sikorski]

Hi list,

first of all thank you to Nicolas, Sergio and others for setting up the
new infra! Keep up the good work guys!
May I ask how much memory do the arm build servers have available? My
qmc2 and mame builds have both failed due to memory exhaustion. While I
am in the process of moving them to Fedora proper, this issue might end
up affecting other packages as well. Both qmc2 and mame built fine on
i686 and on x86_64 so this could be used as an indication of how much
memory is sufficient.
Thank you for the information in advance.

Best regards,
Julian

Re: rfpkg build fixed, you can build on koji !

[Julian Sikorski]

W dniu 04.07.2016 o 22:01, Nicolas Chauvet pisze:
> 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.
> 
> 
Things seem to fail on everything but f24 on nonfree - I tried to build
mame and qmc2 on all branches, they all failed. There is an error in
mock_output.log. For f23:

ERROR: Command failed. See logs for output.
 # /usr/sbin/groupadd -g 135 mockbuild

and for rawhide:

INFO: Running in chroot: ['rfpkg', 'sources']
Start: chroot ['rfpkg', 'sources']
Finish: chroot ['rfpkg', 'sources']
Traceback (most recent call last):
  File "/usr/sbin/mock", line 849, in 
main()
  File "/usr/lib/python3.4/site-packages/mockbuild/trace_decorator.py",
line 88, in trace
result = func(*args, **kw)
  File "/usr/sbin/mock", line 664, in main
run_command(options, args, config_opts, commands, buildroot, state)
  File "/usr/lib/python3.4/site-packages/mockbuild/trace_decorator.py",
line 88, in trace
result = func(*args, **kw)
  File "/usr/sbin/mock", line 711, in run_command
commands.chroot(args, options)
  File "/usr/lib/python3.4/site-packages/mockbuild/trace_decorator.py",
line 88, in trace
result = func(*args, **kw)
  File "/usr/lib/python3.4/site-packages/mockbuild/backend.py", line
291, in chroot
user=self.buildroot.chrootuser, cwd=options.cwd)
  File "/usr/lib/python3.4/site-packages/mockbuild/buildroot.py", line
189, in doChroot
env=env, shell=shell, *args, **kargs)
  File "/usr/lib/python3.4/site-packages/mockbuild/trace_decorator.py",
line 88, in trace
result = func(*args, **kw)
  File "/usr/lib/python3.4/site-packages/mockbuild/util.py", line 508, in do
preexec_fn=preexec,
  File "/usr/lib64/python3.4/subprocess.py", line 859, in __init__
restore_signals, start_new_session)
  File "/usr/lib64/python3.4/subprocess.py", line 1457, in _execute_child
raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: 'rfpkg'

Best regards,
Julian

livna finishes at f21

[Julian Sikorski]

Hello,

it seems that livna does not have packages for Fedora releases beyond
f21. Can we somehow fix this? Or would it be possible to bring libdvdcss
into rpm fusion?

Best regards,
Julian

Re: Fedora legal clarification on emulator software

[Julian Sikorski]

W dniu 03.05.2016 o 22:10, Michael Cronenworth pisze:
> Hello,
> 
> 
> Fedora / Red Hat Legal has clarified[1] its stance on emulation
> software, which include game emulators that until now have been
> restrained to RPMFusion. With the clarification today game emulator
> software that doesn't require a proprietary ROM to bootstrap are allowed
> in Fedora. NES/SNES-like emulators may be put into Fedora proper.
> 
> 
> Thanks,
> 
> Michael
> 
> 
> [1]
> https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/thread/OCIB2WAZ6DF3HJZV2OWYOTNRTUZZ6VRX/
> 
> 
I have submitted a review request for moving MAME to Fedora proper:
https://bugzilla.redhat.com/show_bug.cgi?id=1335278

Best regards,
Julian

nailer, gmtk, gnome-mplayer and gecko-mediaplayer

[Julian Sikorski]

Hi list,

the main developer behind nailer, gmtk, gnome-mplayer and
gecko-mediaplayer has switched to Mac in late 2013 [1]. Since then, only
one release was made [2], after which the code has not seen much
activity (2 commits). Github migration has not helped either [3].
All of the above makes me consider retiring the packages. Even though
they are functional, I am not in position to fix any of the bugs reported.
Please let me know what you think.

Best regards,
Julian

[1] https://groups.google.com/forum/#!topic/gnome-mplayer/bG9fBqxk4k0
[2] https://groups.google.com/forum/#!topic/gnome-mplayer/UOi6yI6DiP8
[3] https://github.com/kdekorte

Re: rpmfusion Fedora-23 plans ?

[Julian Sikorski]

W dniu 25.10.2015 o 18:59, Nicolas Chauvet pisze:
> 2015-10-25 17:24 GMT+01:00 Hans de Goede
>  >:
> 
> Hi,
> 
> 
> On 23-10-15 13:57, Sérgio Basto wrote:
> 
> Hello mates
> 
> On Qui, 2015-10-22 at 22:27 +0200, Nicolas Chauvet wrote:
> 
> 2015-10-12 8:30 GMT+02:00 Hans de Goede
>  >:
>  Hi All,
> 
>  I'm getting requests to update the gstreamer
> packages to 1.6.x
>  for Fedora-23:
> 
>  https://bugzilla.rpmfusion.org/show_bug.cgi?id=3794
>  https://bugzilla.rpmfusion.org/show_bug.cgi?id=3795
>  https://bugzilla.rpmfusion.org/show_bug.cgi?id=3796
> 
>  But AFAIK we are not building any packages for F-23
> yet. What
>  are the
>  plans here ?
> Sorry for the lake for answear,
> 
> 
> The development/23 repository layout will probably stay some
> time
> after fedora 23 GA, which means the repository won't be frozen.
> 
> development/23 is basically f22 packaged resigned with the
> f23 key,
> updates-testing will be f23 specifics packages
> (x264/ffmpeg/gst/others)
> 
> 
> Once everything got more into shape, we merge them into
> releases/23
> later, but at least, the plan is still to have usable state from
> end-user point of view at GA time.(1 week delay!)
> 
> As we can see/deduce, kwizart open a window to update F23 with
> x264/ffmpeg/gst/mplayer/others , which means a mass rebuild !
> and I'd
> like try do it in oneshot ...
> 
> Following ImportantDependencyLists [1] I have submit x264-0.148
> yesterday for F23 .
> 
> I think is important show to others mates what is going on so, I had
> publish a copy of what was submit in github [2] (and is only a
> copy!) ,
> I don't know if Julian is available , but I'd like see some
> coordination
> to update ffmpeg to latest (2.8.1) , update mplayer as Dominik
> suggest
> and check if there is more packages to update that imply soname
> bump .
> 
> 
> Having some definite plans what to do with ffmpeg for rpmfusion would
> be great. I plan to update the gstreamer10-* packages to 1.6.x for
> F-23 and gstreamer1-libav now is using ffmpeg rather then libav despite
> its name, so I hope that I can build it against the system ffmpeg.
> 
>  
> We will probably be using the lastest ffmpeg-2.8.1 altought it's not
> completely well known for the amount of work to make that very recent
> version fit.
> Right now x265 and xvidcore are failing.
> 
> Thx
> 
> 
> -- 
> -
> 
> Nicolas (kwizart)
Hi,

I have now pushed mplayer-1.2 to both f22 and master branches. Btw,
should we switch to github now, or continue using kwizart.net?

Julian

Re: rpmfusion Fedora-23 plans ?

[Julian Sikorski]

W dniu 23.10.2015 o 13:57, Sérgio Basto pisze:
> Hello mates 
> 
> On Qui, 2015-10-22 at 22:27 +0200, Nicolas Chauvet wrote:
>> 2015-10-12 8:30 GMT+02:00 Hans de Goede :
>> Hi All,
>> 
>> I'm getting requests to update the gstreamer packages to 1.6.x
>> for Fedora-23:
>> 
>> https://bugzilla.rpmfusion.org/show_bug.cgi?id=3794
>> https://bugzilla.rpmfusion.org/show_bug.cgi?id=3795
>> https://bugzilla.rpmfusion.org/show_bug.cgi?id=3796
>> 
>> But AFAIK we are not building any packages for F-23 yet. What
>> are the
>> plans here ?
>> Sorry for the lake for answear,
>>
>>
>> The development/23 repository layout will probably stay some time
>> after fedora 23 GA, which means the repository won't be frozen.
>>
>> development/23 is basically f22 packaged resigned with the f23 key,
>> updates-testing will be f23 specifics packages
>> (x264/ffmpeg/gst/others)
>>
>>
>> Once everything got more into shape, we merge them into releases/23
>> later, but at least, the plan is still to have usable state from
>> end-user point of view at GA time.(1 week delay!)
>>
> As we can see/deduce, kwizart open a window to update F23 with
> x264/ffmpeg/gst/mplayer/others , which means a mass rebuild ! and I'd
> like try do it in oneshot ... 
> 
> Following ImportantDependencyLists [1] I have submit x264-0.148
> yesterday for F23 .
> 
> I think is important show to others mates what is going on so, I had
> publish a copy of what was submit in github [2] (and is only a copy!) ,
> I don't know if Julian is available , but I'd like see some coordination
> to update ffmpeg to latest (2.8.1) , update mplayer as Dominik suggest
> and check if there is more packages to update that imply soname bump . 
> 
> 
> [1]
> http://rpmfusion.org/ImportantDependencyLists 
> 
> [2]
> https://github.com/sergiomb2/x264/commit/01df16222127c265ad7781fc9a1e9419e1ee64ee
>>
> 
>>
> 
I am back now - but it looks like an f23 ffmpeg has been attempted
already. It failed due to missing deps - I am guessing f23 buildroot is
not completely populated yet.

Julian

Re: orphaning mame-data-extras

[Julian Sikorski]

W dniu 07.10.2015 o 17:59, Sérgio Basto pisze:
> On Qua, 2015-10-07 at 07:50 +0200, Julian Sikorski wrote:
>> Dear all,
>>
>> please be advised that I am orphaning mame-data-extras. This package has
>> become too much of a burden to maintain with monthly mame releases one
>> one hand and various files included in it lagging behind the mame
>> releases on the other. Not to mention that it was in violation of
>> code-vs-content guideline.
>> I will be putting a dead.package in devel branch in about a week from now.
> 
> GMAMEUI
> Requires: mame-data-extras
> # to load /usr/share/mame/Catver.ini and /usr/share/mame/cheat.7z
> these files will disappear ?

Yes, they will no longer be packaged. I doubt they are required for the
frontend to function, they rather "improve the experience". If users
want them they can download them themselves:
- http://cheat.retrogames.com/ for cheat.7z (at 0.163 atm)
- http://www.progettoemma.net/?catlist for catver.ini (at 0.161 atm)
- http://www.progettosnaps.net/renameset/ for alternative catver.ini

These two files perfectly exemplify the pain in supporting them as a
package: they have alternative upstreams and are not updated every time
new mame comes out. The new rapid release schedule has only made the
issue worse.

> 
> I have not been able to maintain GMAMEUI, since changes in mame , I'd
> like follow gnome-video-arcade [1]
>  
> I'm trying maintain GMAMEUI, because have feature that others don't
> have , maybe export that features to gnome-video-arcade ...
> 
> 
> [1] 
> https://git.gnome.org/browse/gnome-video-arcade/
> 
>> Julian
> 
> Thanks, 
> 

orphaning mame-data-extras

[Julian Sikorski]

Dear all,

please be advised that I am orphaning mame-data-extras. This package has
become too much of a burden to maintain with monthly mame releases one
one hand and various files included in it lagging behind the mame
releases on the other. Not to mention that it was in violation of
code-vs-content guideline.
I will be putting a dead.package in devel branch in about a week from now.

Best regards,
Julian

Re: Updating F-20 to ffmpeg-2.2.11

[Julian Sikorski]

W dniu 05.11.2014 o 17:05, Sérgio Basto pisze:
 On Qua, 2014-11-05 at 07:33 +0100, Julian Sikorski wrote: 
 W dniu 05.11.2014 o 03:55, Sérgio Basto pisze:
 On Dom, 2014-11-02 at 08:02 +0100, Julian Sikorski wrote: 
 W dniu 15.10.2014 o 07:42, Julian Sikorski pisze:
 W dniu 15.10.2014 o 00:38, Sérgio Basto pisze:
 Hi, 

 On Ter, 2014-10-07 at 08:02 +0200, Julian Sikorski wrote: 

 Please be advised that 2.3 was recently removed from the maintained
 branches list:

 https://ffmpeg.org/pipermail/ffmpeg-devel/2014-September/162904.html

 Thus, if we ever rebase F-20, we should use 2.2 and not 2.3.

 The mode I like to work and to coordinate the mass rebuild for a stable
 branch (F-20), is first be test in devel . We have packages in devel, we
 test it for some time and when we can say that are stable , so we could
 *copy* to F-20 , another point was: mass rebuild was for ffmpeg/x264 ,
 not only ffmpeg .
 So it is important have .specs for packages that compile in all Fedora
 releases. Having 2 trees, one for F20, other for devel , is just
 justified when is a very core package like udev or systemd  ... , but
 for rpmfusion the point is other, maintainers are not aware ... 
 So *theoretically* my solution was build ffmpeg 2.2 in devel, test it
 and copy to F-20 , but devel already have 2.3 so is not practical . 

 Moving forward, just update ffmpeg on F20 seems to me acceptable ,
 like you wrote only libavfilter has a soname bump (snip) This means
 that we really only need to rebuild dvdstyler, mpv and xbmc. but we
 miss the test phase, we need guarantee that ffmpeg version was tested ,
 any suggestion ?

 ffmpeg-2.2 was in devel between March and August. Moreover, the reason
 why upstream picked it over 2.3 was that it is used by more downstream
 distros: OpenSUSE, SUSE Enterprise and ROSA [1]. If we let it sit in
 -testing for a bit longer than usual, I believe this will be enough.


 Saying that and giving up mass rebuild ffmpeg/x264 for F-20, no need
 preserve devel as is and we can do the mass rebuild for ffmpeg 2.4 on
 devel , anything pending ?

 I don't think anything has changed since last time: dvbcut and
 kmediafactory fail to rebuild, vlc needs a patch, everything else builds
 fine. David Timms was working on making dvbcut work, but I have not
 heard from him regarding whether he was successful.


 BTW what packages (.spec) do you have ? that are different from stable
 branches to devel ?

 Only ffmpeg and mplayer. ffmpeg due to its numerous dependencies, and
 mplayer because it is highly dependent on ffmpeg.


 Thanks and best regards,


 Thank you.

 [1] https://trac.ffmpeg.org/wiki/Downstreams

 Where do we stand on this?

 I don't change must what I wrote :
 Update ffmpeg on F20 seems to me acceptable ,like you wrote only
 libavfilter has a soname bump ... This means that we really only need to
 rebuild dvdstyler, mpv and xbmc.

 I think you should decide and we need authorization from kwizart . 

Dear Nicolas,

do you agree to updating ffmpeg in F-20 to 2.2.11? 2.1 branch is pretty
much unmaintained upstream and using it is a security risk to our users.
A new release came out recently but it still was an exception to the rule.
The downstream effects are limited to dvdstyler, mpv and xbmc.


 you don't want rebuild others deps right ?  


 cheers 

 I think we should go do it. 2.1 has not seen a release in months which
 means there might be unfixed security issues in it.
 I would only rebuild what we need to (dvdstyler, mpv and xbmc).
 
 yes , we can use security police , we need update ffmpeg to 2.2.10 on
 Fedora 20 , due security concerns . 
 
 kwizart, may we do this update ?, we need your authorization, I will
 rebuild dvdstyler, mpv and xbmc .  
 
 I'm going test it meanwhile .
 
 Thanks, 
 

Dear Sergio,

when would it be convenient for you to do this?

Best regards,
Julian

Re: can someone run make build for all branches of qmc2 and ffmpeg/F-20

[Julian Sikorski]

W dniu 29.11.2014 o 10:09, Mamoru TASAKA pisze:
 Julian Sikorski wrote on 11/29/2014 05:50 PM:
 Hi,

 I cannot do make build due to recent updgrade to F-21:
 https://bugzilla.redhat.com/show_bug.cgi?id=1169033
 Please someone may do me a solid and issue a make build? Everything is
 good to go. Thanks in advance.

 Best regards,
 Julian
 
 
 Sumbitted:
 http://buildsys.rpmfusion.org/build-status/job.psp?uid=21693
 
 Note that this is due to openssl change on Fedora (on
 2013/11/13):
 https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-2013/1144043.html
 
 and see:
 https://bugzilla.redhat.com/show_bug.cgi?id=1071615
 
 Anyway I guess plague needs some fixes.
 
 Regards,
 Mamoru
 
Thanks! For anyone also experiencing this, the bug referenced by Mamoru
contains a workaround.

Best regards,
Julian

Re: can someone run make build for all branches of qmc2 and ffmpeg/F-20

[Julian Sikorski]

W dniu 29.11.2014 o 10:09, Mamoru TASAKA pisze:
 Julian Sikorski wrote on 11/29/2014 05:50 PM:
 Hi,

 I cannot do make build due to recent updgrade to F-21:
 https://bugzilla.redhat.com/show_bug.cgi?id=1169033
 Please someone may do me a solid and issue a make build? Everything is
 good to go. Thanks in advance.

 Best regards,
 Julian
 
 
 Sumbitted:
 http://buildsys.rpmfusion.org/build-status/job.psp?uid=21693
 
 Note that this is due to openssl change on Fedora (on
 2013/11/13):
 https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-2013/1144043.html
 
 and see:
 https://bugzilla.redhat.com/show_bug.cgi?id=1071615
 
 Anyway I guess plague needs some fixes.
 
 Regards,
 Mamoru
 
I have queued ffmpeg/F-20 and qmc2/F-19 with the workaround. Thank you
for your help!

Julian

Re: Updating F-20 to ffmpeg-2.2.10

[Julian Sikorski]

W dniu 05.11.2014 o 03:55, Sérgio Basto pisze:
 On Dom, 2014-11-02 at 08:02 +0100, Julian Sikorski wrote: 
 W dniu 15.10.2014 o 07:42, Julian Sikorski pisze:
 W dniu 15.10.2014 o 00:38, Sérgio Basto pisze:
 Hi, 

 On Ter, 2014-10-07 at 08:02 +0200, Julian Sikorski wrote: 

 Please be advised that 2.3 was recently removed from the maintained
 branches list:

 https://ffmpeg.org/pipermail/ffmpeg-devel/2014-September/162904.html

 Thus, if we ever rebase F-20, we should use 2.2 and not 2.3.

 The mode I like to work and to coordinate the mass rebuild for a stable
 branch (F-20), is first be test in devel . We have packages in devel, we
 test it for some time and when we can say that are stable , so we could
 *copy* to F-20 , another point was: mass rebuild was for ffmpeg/x264 ,
 not only ffmpeg .
 So it is important have .specs for packages that compile in all Fedora
 releases. Having 2 trees, one for F20, other for devel , is just
 justified when is a very core package like udev or systemd  ... , but
 for rpmfusion the point is other, maintainers are not aware ... 
 So *theoretically* my solution was build ffmpeg 2.2 in devel, test it
 and copy to F-20 , but devel already have 2.3 so is not practical . 

 Moving forward, just update ffmpeg on F20 seems to me acceptable ,
 like you wrote only libavfilter has a soname bump (snip) This means
 that we really only need to rebuild dvdstyler, mpv and xbmc. but we
 miss the test phase, we need guarantee that ffmpeg version was tested ,
 any suggestion ?

 ffmpeg-2.2 was in devel between March and August. Moreover, the reason
 why upstream picked it over 2.3 was that it is used by more downstream
 distros: OpenSUSE, SUSE Enterprise and ROSA [1]. If we let it sit in
 -testing for a bit longer than usual, I believe this will be enough.


 Saying that and giving up mass rebuild ffmpeg/x264 for F-20, no need
 preserve devel as is and we can do the mass rebuild for ffmpeg 2.4 on
 devel , anything pending ?

 I don't think anything has changed since last time: dvbcut and
 kmediafactory fail to rebuild, vlc needs a patch, everything else builds
 fine. David Timms was working on making dvbcut work, but I have not
 heard from him regarding whether he was successful.


 BTW what packages (.spec) do you have ? that are different from stable
 branches to devel ?

 Only ffmpeg and mplayer. ffmpeg due to its numerous dependencies, and
 mplayer because it is highly dependent on ffmpeg.


 Thanks and best regards,


 Thank you.

 [1] https://trac.ffmpeg.org/wiki/Downstreams

 Where do we stand on this?
 
 I don't change must what I wrote :
 Update ffmpeg on F20 seems to me acceptable ,like you wrote only
 libavfilter has a soname bump ... This means that we really only need to
 rebuild dvdstyler, mpv and xbmc.
 
 I think you should decide and we need authorization from kwizart . 
 
 you don't want rebuild others deps right ?  
 
 
 cheers 
 
I think we should go do it. 2.1 has not seen a release in months which
means there might be unfixed security issues in it.
I would only rebuild what we need to (dvdstyler, mpv and xbmc).

Best regards,
Julian

Updating F-20 to ffmpeg-2.2.10 (was: ffmpeg-2.4 released)

[Julian Sikorski]

W dniu 15.10.2014 o 07:42, Julian Sikorski pisze:
 W dniu 15.10.2014 o 00:38, Sérgio Basto pisze:
 Hi, 

 On Ter, 2014-10-07 at 08:02 +0200, Julian Sikorski wrote: 

 Please be advised that 2.3 was recently removed from the maintained
 branches list:

 https://ffmpeg.org/pipermail/ffmpeg-devel/2014-September/162904.html

 Thus, if we ever rebase F-20, we should use 2.2 and not 2.3.

 The mode I like to work and to coordinate the mass rebuild for a stable
 branch (F-20), is first be test in devel . We have packages in devel, we
 test it for some time and when we can say that are stable , so we could
 *copy* to F-20 , another point was: mass rebuild was for ffmpeg/x264 ,
 not only ffmpeg .
 So it is important have .specs for packages that compile in all Fedora
 releases. Having 2 trees, one for F20, other for devel , is just
 justified when is a very core package like udev or systemd  ... , but
 for rpmfusion the point is other, maintainers are not aware ... 
 So *theoretically* my solution was build ffmpeg 2.2 in devel, test it
 and copy to F-20 , but devel already have 2.3 so is not practical . 

 Moving forward, just update ffmpeg on F20 seems to me acceptable ,
 like you wrote only libavfilter has a soname bump (snip) This means
 that we really only need to rebuild dvdstyler, mpv and xbmc. but we
 miss the test phase, we need guarantee that ffmpeg version was tested ,
 any suggestion ?
 
 ffmpeg-2.2 was in devel between March and August. Moreover, the reason
 why upstream picked it over 2.3 was that it is used by more downstream
 distros: OpenSUSE, SUSE Enterprise and ROSA [1]. If we let it sit in
 -testing for a bit longer than usual, I believe this will be enough.
 

 Saying that and giving up mass rebuild ffmpeg/x264 for F-20, no need
 preserve devel as is and we can do the mass rebuild for ffmpeg 2.4 on
 devel , anything pending ?
 
 I don't think anything has changed since last time: dvbcut and
 kmediafactory fail to rebuild, vlc needs a patch, everything else builds
 fine. David Timms was working on making dvbcut work, but I have not
 heard from him regarding whether he was successful.
 

 BTW what packages (.spec) do you have ? that are different from stable
 branches to devel ?
 
 Only ffmpeg and mplayer. ffmpeg due to its numerous dependencies, and
 mplayer because it is highly dependent on ffmpeg.
 

 Thanks and best regards,

 
 Thank you.
 
 [1] https://trac.ffmpeg.org/wiki/Downstreams
 
Where do we stand on this?

Best regards,
Julian

Re: ffmpeg-2.4 released

[Julian Sikorski]

W dniu 15.10.2014 o 00:38, Sérgio Basto pisze:
 Hi, 
 
 On Ter, 2014-10-07 at 08:02 +0200, Julian Sikorski wrote: 

 Please be advised that 2.3 was recently removed from the maintained
 branches list:

 https://ffmpeg.org/pipermail/ffmpeg-devel/2014-September/162904.html

 Thus, if we ever rebase F-20, we should use 2.2 and not 2.3.
 
 The mode I like to work and to coordinate the mass rebuild for a stable
 branch (F-20), is first be test in devel . We have packages in devel, we
 test it for some time and when we can say that are stable , so we could
 *copy* to F-20 , another point was: mass rebuild was for ffmpeg/x264 ,
 not only ffmpeg .
 So it is important have .specs for packages that compile in all Fedora
 releases. Having 2 trees, one for F20, other for devel , is just
 justified when is a very core package like udev or systemd  ... , but
 for rpmfusion the point is other, maintainers are not aware ... 
 So *theoretically* my solution was build ffmpeg 2.2 in devel, test it
 and copy to F-20 , but devel already have 2.3 so is not practical . 
 
 Moving forward, just update ffmpeg on F20 seems to me acceptable ,
 like you wrote only libavfilter has a soname bump (snip) This means
 that we really only need to rebuild dvdstyler, mpv and xbmc. but we
 miss the test phase, we need guarantee that ffmpeg version was tested ,
 any suggestion ?

ffmpeg-2.2 was in devel between March and August. Moreover, the reason
why upstream picked it over 2.3 was that it is used by more downstream
distros: OpenSUSE, SUSE Enterprise and ROSA [1]. If we let it sit in
-testing for a bit longer than usual, I believe this will be enough.

 
 Saying that and giving up mass rebuild ffmpeg/x264 for F-20, no need
 preserve devel as is and we can do the mass rebuild for ffmpeg 2.4 on
 devel , anything pending ?

I don't think anything has changed since last time: dvbcut and
kmediafactory fail to rebuild, vlc needs a patch, everything else builds
fine. David Timms was working on making dvbcut work, but I have not
heard from him regarding whether he was successful.

 
 BTW what packages (.spec) do you have ? that are different from stable
 branches to devel ?

Only ffmpeg and mplayer. ffmpeg due to its numerous dependencies, and
mplayer because it is highly dependent on ffmpeg.

 
 Thanks and best regards,
 

Thank you.

[1] https://trac.ffmpeg.org/wiki/Downstreams

Re: ffmpeg-2.4 released

[Julian Sikorski]

W dniu 04.10.2014 o 11:39, Julian Sikorski pisze:
 W dniu 25.09.2014 o 21:04, Nicolas Chauvet pisze:
 2014-09-25 20:44 GMT+02:00 Sérgio Basto
 ser...@serjux.com
 mailto:ser...@serjux.com:

 On Qui, 2014-09-25 at 20:33 +0200, Nicolas Chauvet wrote:
  2014-09-25 19:27 GMT+02:00 Julian Sikorski
 beleg...@gmail.com
 mailto:beleg...@gmail.com:
  W dniu 25.09.2014 o 17:26, Sérgio Basto pisze:
   On Qui, 2014-09-25 at 07:47 +0200, Julian Sikorski wrote:
   W dniu 21.09.2014 o 23:20, Sérgio Basto pisze:
   On Dom, 2014-09-21 at 19:03 +0200, Julian Sikorski wrote:
   Dear all,
  
   ffmpeg-2.4 was released recently which means we have
  another rebuild
   coming up. I have done a test and only 4 packages have
  failed, which is
   not bad given the extent of API changes:
   - alsa-plugins-freeworld: pcm_a52.c:101:45: error:
  'struct a52_ctx' has
   no member named 'frame'
   - dvbcut: lavfmuxer.cpp:63:57: error: 'av_new_stream' was
  not declared
   in this scope
   - kmediafactory: videofile.cpp:74:45: error:
  'av_find_stream_info' was
   not declared in this scope (mencoder needs to be rebuilt
  first)
- vlc: configure: error: libavcodec versions 56 and
  later are not
   supported yet.
  
   Given that we are close to branching (?), what would be
  the good time to
   do the rebuild?
  
   yes, I don't see any problem, I can do the mass rebuild of
  others
   packages, no problem.
  
   My question if we ever put this updates on F20 ? I'd like
  put it at
   least on update-testing. I can made a list of the
  packages, with
   ffmpeg / x264 dependencies, that should stay on
  update-testing for more
   time than usual, but is not my decision .
  
  
   Best regards,
  
   ffmpeg-2.4.1 has now been built. I will take care of
  rebuilding mplayer.
 
 
 
  Can we care about rebuilding all dependencies at the same time ?
 
 yes of course , I will take care ,

 but may I build all for new ffmpeg /x624 for F20 ?


 SO I NAK the ffmpeg update in F-20 because the way the update was done
 in Rawhide.
 I don't want to hear about it. This is not acceptable not to have
 coordinated the update.
 PERIOD.


 -- 
 -

 Nicolas (kwizart)
 
 In case this gets reconsidered at some point in the future: I have done
 a test rebuild of F-20 dependecies against ffmpeg-2.3.4, and all 37 have
 built correctly.
 Moreover, only libavfilter has a soname bump (please find rpmsodiff
 output attached). This means that we really only need to rebuild
 dvdstyler, mpv and xbmc.
 
 Best regards,
 Julian
 
Please be advised that 2.3 was recently removed from the maintained
branches list:

https://ffmpeg.org/pipermail/ffmpeg-devel/2014-September/162904.html

Thus, if we ever rebase F-20, we should use 2.2 and not 2.3.

Best regards,
Julian

Re: ffmpeg-2.4 released

[Julian Sikorski]

W dniu 07.10.2014 o 08:02, Julian Sikorski pisze:
 W dniu 04.10.2014 o 11:39, Julian Sikorski pisze:
 W dniu 25.09.2014 o 21:04, Nicolas Chauvet pisze:
 2014-09-25 20:44 GMT+02:00 Sérgio Basto
 ser...@serjux.com
 mailto:ser...@serjux.com:

 On Qui, 2014-09-25 at 20:33 +0200, Nicolas Chauvet wrote:
  2014-09-25 19:27 GMT+02:00 Julian Sikorski
 beleg...@gmail.com
 mailto:beleg...@gmail.com:
  W dniu 25.09.2014 o 17:26, Sérgio Basto pisze:
   On Qui, 2014-09-25 at 07:47 +0200, Julian Sikorski wrote:
   W dniu 21.09.2014 o 23:20, Sérgio Basto pisze:
   On Dom, 2014-09-21 at 19:03 +0200, Julian Sikorski wrote:
   Dear all,
  
   ffmpeg-2.4 was released recently which means we have
  another rebuild
   coming up. I have done a test and only 4 packages have
  failed, which is
   not bad given the extent of API changes:
   - alsa-plugins-freeworld: pcm_a52.c:101:45: error:
  'struct a52_ctx' has
   no member named 'frame'
   - dvbcut: lavfmuxer.cpp:63:57: error: 'av_new_stream' was
  not declared
   in this scope
   - kmediafactory: videofile.cpp:74:45: error:
  'av_find_stream_info' was
   not declared in this scope (mencoder needs to be rebuilt
  first)
- vlc: configure: error: libavcodec versions 56 and
  later are not
   supported yet.
  
   Given that we are close to branching (?), what would be
  the good time to
   do the rebuild?
  
   yes, I don't see any problem, I can do the mass rebuild of
  others
   packages, no problem.
  
   My question if we ever put this updates on F20 ? I'd like
  put it at
   least on update-testing. I can made a list of the
  packages, with
   ffmpeg / x264 dependencies, that should stay on
  update-testing for more
   time than usual, but is not my decision .
  
  
   Best regards,
  
   ffmpeg-2.4.1 has now been built. I will take care of
  rebuilding mplayer.
 
 
 
  Can we care about rebuilding all dependencies at the same time ?
 
 yes of course , I will take care ,

 but may I build all for new ffmpeg /x624 for F20 ?


 SO I NAK the ffmpeg update in F-20 because the way the update was done
 in Rawhide.
 I don't want to hear about it. This is not acceptable not to have
 coordinated the update.
 PERIOD.


 -- 
 -

 Nicolas (kwizart)

 In case this gets reconsidered at some point in the future: I have done
 a test rebuild of F-20 dependecies against ffmpeg-2.3.4, and all 37 have
 built correctly.
 Moreover, only libavfilter has a soname bump (please find rpmsodiff
 output attached). This means that we really only need to rebuild
 dvdstyler, mpv and xbmc.

 Best regards,
 Julian

 Please be advised that 2.3 was recently removed from the maintained
 branches list:
 
 https://ffmpeg.org/pipermail/ffmpeg-devel/2014-September/162904.html
 
 Thus, if we ever rebase F-20, we should use 2.2 and not 2.3.
 
 Best regards,
 Julian
 
As expected, everything builds against ffmpeg-2.2.9 too. Relevant sodiff
attached.

Best regards,
Julian
	sonames only in ffmpeg-libs-2.1.5-1.fc20 [1]:
libavfilter.so.3	/usr/lib64/libavfilter.so.3.90.100

	sonames only in ffmpeg-libs-2.2.9-1.fc20 [2]:
libavfilter.so.4	/usr/lib64/libavfilter.so.4.2.100

	common sonames:
libavcodec.so.55	/usr/lib64/libavcodec.so.55.39.101	/usr/lib64/libavcodec.so.55.52.102
libavdevice.so.55	/usr/lib64/libavdevice.so.55.5.100	/usr/lib64/libavdevice.so.55.10.100
libavformat.so.55	/usr/lib64/libavformat.so.55.19.104	/usr/lib64/libavformat.so.55.33.100
libavresample.so.1	/usr/lib64/libavresample.so.1.1.0	/usr/lib64/libavresample.so.1.2.0
libavutil.so.52	/usr/lib64/libavutil.so.52.48.101	/usr/lib64/libavutil.so.52.66.100
libpostproc.so.52	/usr/lib64/libpostproc.so.52.3.100	/usr/lib64/libpostproc.so.52.3.100
libswresample.so.0	/usr/lib64/libswresample.so.0.17.104	/usr/lib64/libswresample.so.0.18.100
libswscale.so.2	/usr/lib64/libswscale.so.2.5.101	/usr/lib64/libswscale.so.2.5.102

--- ffmpeg-libs-2.1.5-1.fc20/libavcodec.so.55	2014-07-09 00:08:31.0 +0200
+++ ffmpeg-libs-2.2.9-1.fc20/libavcodec.so.55	2014-10-07 08:19:24.013645000 +0200
@@ -11,2 +11,3 @@
 av_bitstream_filter_next	T
+av_codec_get_chroma_intra_matrix	T
 av_codec_get_codec_descriptor	T
@@ -19,2 +20,3 @@
 av_codec_next	T
+av_codec_set_chroma_intra_matrix	T
 av_codec_set_codec_descriptor	T
@@ -64,2 +66,3 @@
 av_packet_new_side_data	T
+av_packet_pack_dictionary	T
 av_packet_ref	T
@@ -67,2 +70,3 @@
 av_packet_split_side_data	T
+av_packet_unpack_dictionary	T
 av_packet_unref	T

Re: How to test build for F21+rpmfusion devel ?

[Julian Sikorski]

W dniu 07.10.2014 o 22:58, David Timms pisze:
 On 04/10/14 23:57, David Timms wrote:
 On 02/10/14 22:52, David Timms wrote:
 On 02/10/14 15:36, Julian Sikorski wrote:
 ..
 Which packages are remaining please ?

 dvbcut and kmediafactory.
 ...
 I did a mock test build with:
 mock -r fedora-rawhide-x86_64-rpmfusion_free --rebuild
 /home/davidt/rpmbuild/SRPMS/dvbcut-0.6.1-17.svn179.fc20.src.rpm

 This build completed.

 So am wondering, what mock config to do the testing/changes that this
 thread is discussing ?
 
 I possibly missed responses to this email... is there a mock config I
 can use to test the combination of repos that cause the FFMpeg 2.4
 attempt to fail ?
 
 Thanks, Dave.
 
FFmpeg-2.4 was pulled from devel. This means that the only way you can
test it at the moment is by using mockchain. I have uploaded the
ffmpeg-2.4 srpm for you:
http://lesloueizeh.com/belegdol/ffmpeg-rebuild/ffmpeg-2.4-1.fc22.src.rpm

Best regards,
Julian

Re: ffmpeg-2.4 released

[Julian Sikorski]

W dniu 25.09.2014 o 21:04, Nicolas Chauvet pisze:
 2014-09-25 20:44 GMT+02:00 Sérgio Basto
 ser...@serjux.com
 mailto:ser...@serjux.com:
 
 On Qui, 2014-09-25 at 20:33 +0200, Nicolas Chauvet wrote:
  2014-09-25 19:27 GMT+02:00 Julian Sikorski
 beleg...@gmail.com
 mailto:beleg...@gmail.com:
  W dniu 25.09.2014 o 17:26, Sérgio Basto pisze:
   On Qui, 2014-09-25 at 07:47 +0200, Julian Sikorski wrote:
   W dniu 21.09.2014 o 23:20, Sérgio Basto pisze:
   On Dom, 2014-09-21 at 19:03 +0200, Julian Sikorski wrote:
   Dear all,
  
   ffmpeg-2.4 was released recently which means we have
  another rebuild
   coming up. I have done a test and only 4 packages have
  failed, which is
   not bad given the extent of API changes:
   - alsa-plugins-freeworld: pcm_a52.c:101:45: error:
  'struct a52_ctx' has
   no member named 'frame'
   - dvbcut: lavfmuxer.cpp:63:57: error: 'av_new_stream' was
  not declared
   in this scope
   - kmediafactory: videofile.cpp:74:45: error:
  'av_find_stream_info' was
   not declared in this scope (mencoder needs to be rebuilt
  first)
- vlc: configure: error: libavcodec versions 56 and
  later are not
   supported yet.
  
   Given that we are close to branching (?), what would be
  the good time to
   do the rebuild?
  
   yes, I don't see any problem, I can do the mass rebuild of
  others
   packages, no problem.
  
   My question if we ever put this updates on F20 ? I'd like
  put it at
   least on update-testing. I can made a list of the
  packages, with
   ffmpeg / x264 dependencies, that should stay on
  update-testing for more
   time than usual, but is not my decision .
  
  
   Best regards,
  
   ffmpeg-2.4.1 has now been built. I will take care of
  rebuilding mplayer.
 
 
 
  Can we care about rebuilding all dependencies at the same time ?
 
 yes of course , I will take care ,
 
 but may I build all for new ffmpeg /x624 for F20 ?
 
 
 SO I NAK the ffmpeg update in F-20 because the way the update was done
 in Rawhide.
 I don't want to hear about it. This is not acceptable not to have
 coordinated the update.
 PERIOD.
 
 
 -- 
 -
 
 Nicolas (kwizart)

In case this gets reconsidered at some point in the future: I have done
a test rebuild of F-20 dependecies against ffmpeg-2.3.4, and all 37 have
built correctly.
Moreover, only libavfilter has a soname bump (please find rpmsodiff
output attached). This means that we really only need to rebuild
dvdstyler, mpv and xbmc.

Best regards,
Julian
	sonames only in ffmpeg-libs-2.1.5-1.fc20 [1]:
libavfilter.so.3	/usr/lib64/libavfilter.so.3.90.100

	sonames only in ffmpeg-libs-2.3.4-1.fc20 [2]:
libavfilter.so.4	/usr/lib64/libavfilter.so.4.11.100

	common sonames:
libavcodec.so.55	/usr/lib64/libavcodec.so.55.39.101	/usr/lib64/libavcodec.so.55.69.100
libavdevice.so.55	/usr/lib64/libavdevice.so.55.5.100	/usr/lib64/libavdevice.so.55.13.102
libavformat.so.55	/usr/lib64/libavformat.so.55.19.104	/usr/lib64/libavformat.so.55.48.100
libavresample.so.1	/usr/lib64/libavresample.so.1.1.0	/usr/lib64/libavresample.so.1.3.0
libavutil.so.52	/usr/lib64/libavutil.so.52.48.101	/usr/lib64/libavutil.so.52.92.100
libpostproc.so.52	/usr/lib64/libpostproc.so.52.3.100	/usr/lib64/libpostproc.so.52.3.100
libswresample.so.0	/usr/lib64/libswresample.so.0.17.104	/usr/lib64/libswresample.so.0.19.100
libswscale.so.2	/usr/lib64/libswscale.so.2.5.101	/usr/lib64/libswscale.so.2.6.100

--- ffmpeg-libs-2.1.5-1.fc20/libavcodec.so.55	2014-07-09 00:08:31.0 +0200
+++ ffmpeg-libs-2.3.4-1.fc20/libavcodec.so.55	2014-10-03 08:15:03.239106000 +0200
@@ -11,2 +11,3 @@
 av_bitstream_filter_next	T
+av_codec_get_chroma_intra_matrix	T
 av_codec_get_codec_descriptor	T
@@ -19,2 +20,3 @@
 av_codec_next	T
+av_codec_set_chroma_intra_matrix	T
 av_codec_set_codec_descriptor	T
@@ -30,2 +32,4 @@
 av_dup_packet	T
+av_dv_codec_profile	T
+av_dv_frame_profile	T
 av_fast_malloc	T
@@ -64,5 +68,8 @@
 av_packet_new_side_data	T
+av_packet_pack_dictionary	T
 av_packet_ref	T
+av_packet_rescale_ts	T
 av_packet_shrink_side_data	T
 av_packet_split_side_data	T
+av_packet_unpack_dictionary	T
 av_packet_unref	T
@@ -87,2 +94,4 @@
 av_shrink_packet	T
+av_vdpau_alloc_context	T
+av_vdpau_get_profile	T
 av_vdpau_hwaccel_get_render2	T
@@ -98,2 +107,5 @@
 avcodec_copy_context	T
+avcodec_dct_alloc	T
+avcodec_dct_get_class	T
+avcodec_dct_init	T
 avcodec_decode_audio3	T
@@ -127,2 +139,3 @@
 avcodec_flush_buffers	T
+avcodec_free_context

Re: ffmpeg-2.4 released

[Julian Sikorski]

W dniu 02.10.2014 o 07:41, Julian Sikorski pisze:
 W dniu 02.10.2014 o 01:46, Sérgio Basto pisze:
 On Qua, 2014-10-01 at 19:38 +0200, Julian Sikorski wrote: 
 W dniu 25.09.2014 o 20:51, Sérgio Basto pisze:
 On Qui, 2014-09-25 at 19:27 +0200, Julian Sikorski wrote: 
 W dniu 25.09.2014 o 17:26, Sérgio Basto pisze:
 On Qui, 2014-09-25 at 07:47 +0200, Julian Sikorski wrote: 
 W dniu 21.09.2014 o 23:20, Sérgio Basto pisze:
 On Dom, 2014-09-21 at 19:03 +0200, Julian Sikorski wrote: 
 Dear all,

 ffmpeg-2.4 was released recently which means we have another rebuild
 coming up. I have done a test and only 4 packages have failed, which 
 is
 not bad given the extent of API changes:
 - alsa-plugins-freeworld: pcm_a52.c:101:45: error: 'struct a52_ctx' 
 has
 no member named 'frame'
 - dvbcut: lavfmuxer.cpp:63:57: error: 'av_new_stream' was not declared
 in this scope
 - kmediafactory: videofile.cpp:74:45: error: 'av_find_stream_info' was
 not declared in this scope (mencoder needs to be rebuilt first)
  - vlc: configure: error: libavcodec versions 56 and later are not
 supported yet.

 Given that we are close to branching (?), what would be the good time 
 to
 do the rebuild?

 yes, I don't see any problem, I can do the mass rebuild of others
 packages, no problem.

 My question if we ever put this updates on F20 ? I'd like put it at
 least on update-testing. I can made a list of the packages, with
 ffmpeg / x264 dependencies, that should stay on update-testing for more
 time than usual, but is not my decision .  


 Best regards, 

 ffmpeg-2.4.1 has now been built. I will take care of rebuilding mplayer.

 Best regards,
 Julian

 Hi, please wait, let's wait to know if kwizart allow us to put ffmpeg
 2.3.3 in F20, we think it is better and we have strong reasons , like
 explained in
 https://lists.rpmfusion.org/pipermail/rpmfusion-developers/2014-September/017393.html

 Kwizart , do you allow this exception ? 


 Thanks, 

 Just to be clear: I only pushed it to devel. F20 is still an open 
 question.

 yes , but I want copy from devel to F20, the state of art , before
 upgrading to ffmpeg 2.4 , and it is more easier , clean etc , if just
 after this (update ffmpeg to 2.4) . ...


 Thanks, 

 If we ever decide to upgrade f20 (which I don't think we will given the
 current fiasco), please do not overwrite the f20 spec with f21 one. I
 suggest comparing the two and upgrading in parallel, something like git
 cherry-pick.

 Hi , Julian , that is the point, this is cvs , we don't have upgrading
 in parallel, I try rolling devel to branches and yes overwrite the f20
 spec and what is in f20 spec is discard. Is the only rule of
 organization that we have .
 
 I was not aware we have that rule. Until now, I was maintaining seperate
 branches for ffmpeg and mplayer. I still believe that upgrading F-20
 independently is better as it preserves the history better.

Case in point: rawhide ffmpeg has celt support disabled by default
because the package has been retired in fedora. There is no reason to
drop it in F-20.
I have compared the F-20 and devel spec files, and the following changes
are required if we decide to upgrade:
- version bump to 2.3.x
- rename README to README.md in %doc
Please do not overwrite the F20 ffmpeg spec file. I think only makes
sense for packages where the branches were kept at the same version at
all times, which is not the case here.

Best regards,
Julian

 

 But the main problem was and still is, lack of time , so I and kwizart
 (writing off-list) haven't much time next days and he point to try again
 (the mass rebuild) no this weekend but next weekend, meantime
 ffmpeg-2.3.3 still on devel (I think) . 

 This is an ancient system so it give much work do all mass rebuild, see
 if we can make a new builder happen.

 Kwizart roll back to ffmpeg-2.3 , because though we haven't patches for
 vlc build against ffmpeg2-4 and lack of time of course . 
 
 What was wrong with the vlc patch I linked to?
 

 Please be patient ...

 Julian
 

Re: ffmpeg-2.4 released

[Julian Sikorski]

W dniu 01.10.2014 o 16:38, Ankur Sinha pisze:
 On Fri, 2014-09-26 at 14:29 +0200, Xavier Bachelot wrote:
 mplayer
 
 I'm still seeing this on my F21 up to date system:
 
 Error: nothing provides libavutil.so.54()(64bit) needed by
 mplayer-1.1-28.20140919svn.fc21.x86_64. nothing provides
 libavutil.so.54()(64bit) needed by
 mplayer-1.1-28.20140919svn.fc21.x86_64
 
 
 Is this related to the rebuild, or is it another issue?
 
It is related. Try doing
# yum downgrade ffmpeg\*

Best regards,
Julian

Re: ffmpeg-2.4 released

[Julian Sikorski]

W dniu 25.09.2014 o 20:51, Sérgio Basto pisze:
 On Qui, 2014-09-25 at 19:27 +0200, Julian Sikorski wrote: 
 W dniu 25.09.2014 o 17:26, Sérgio Basto pisze:
 On Qui, 2014-09-25 at 07:47 +0200, Julian Sikorski wrote: 
 W dniu 21.09.2014 o 23:20, Sérgio Basto pisze:
 On Dom, 2014-09-21 at 19:03 +0200, Julian Sikorski wrote: 
 Dear all,

 ffmpeg-2.4 was released recently which means we have another rebuild
 coming up. I have done a test and only 4 packages have failed, which is
 not bad given the extent of API changes:
 - alsa-plugins-freeworld: pcm_a52.c:101:45: error: 'struct a52_ctx' has
 no member named 'frame'
 - dvbcut: lavfmuxer.cpp:63:57: error: 'av_new_stream' was not declared
 in this scope
 - kmediafactory: videofile.cpp:74:45: error: 'av_find_stream_info' was
 not declared in this scope (mencoder needs to be rebuilt first)
  - vlc: configure: error: libavcodec versions 56 and later are not
 supported yet.

 Given that we are close to branching (?), what would be the good time to
 do the rebuild?

 yes, I don't see any problem, I can do the mass rebuild of others
 packages, no problem.

 My question if we ever put this updates on F20 ? I'd like put it at
 least on update-testing. I can made a list of the packages, with
 ffmpeg / x264 dependencies, that should stay on update-testing for more
 time than usual, but is not my decision .  


 Best regards, 

 ffmpeg-2.4.1 has now been built. I will take care of rebuilding mplayer.

 Best regards,
 Julian

 Hi, please wait, let's wait to know if kwizart allow us to put ffmpeg
 2.3.3 in F20, we think it is better and we have strong reasons , like
 explained in
 https://lists.rpmfusion.org/pipermail/rpmfusion-developers/2014-September/017393.html

 Kwizart , do you allow this exception ? 


 Thanks, 

 Just to be clear: I only pushed it to devel. F20 is still an open question.
 
 yes , but I want copy from devel to F20, the state of art , before
 upgrading to ffmpeg 2.4 , and it is more easier , clean etc , if just
 after this (update ffmpeg to 2.4) . ...
 
 
 Thanks, 
 
If we ever decide to upgrade f20 (which I don't think we will given the
current fiasco), please do not overwrite the f20 spec with f21 one. I
suggest comparing the two and upgrading in parallel, something like git
cherry-pick.

Julian

Re: ffmpeg-2.4 released

[Julian Sikorski]

W dniu 21.09.2014 o 19:11, Julian Sikorski pisze:
 W dniu 21.09.2014 o 19:03, Julian Sikorski pisze:
 Dear all,

 ffmpeg-2.4 was released recently which means we have another rebuild
 coming up. I have done a test and only 4 packages have failed, which is
 not bad given the extent of API changes:
 - alsa-plugins-freeworld: pcm_a52.c:101:45: error: 'struct a52_ctx' has
 no member named 'frame'
 - dvbcut: lavfmuxer.cpp:63:57: error: 'av_new_stream' was not declared
 in this scope
 - kmediafactory: videofile.cpp:74:45: error: 'av_find_stream_info' was
 not declared in this scope (mencoder needs to be rebuilt first)
  - vlc: configure: error: libavcodec versions 56 and later are not
 supported yet.

 Given that we are close to branching (?), what would be the good time to
 do the rebuild?

 Best regards,
 Julian

 Please excuse my replying to myself. Some of the work seems already done:
 - alsa-plugins: looking at arch seems to indicate this can be fixed by
 updating to 1.0.28
 - vlc:
 https://projects.archlinux.org/svntogit/packages.git/tree/trunk/vlc-2.1.5-ffmpeg-2.4.patch?h=packages/vlc
 
 Best regards,
 Julian
 
May I ask what are we waiting for with rawhide? I have done a local
rebuilt, found fixes for 2 out of 4 failing packages and rebuilt ffmpeg.
This is how we have always done it in the past and it has always worked.
Looking at the buildsys.rpmfusion.org, Nicolas has attempted to rebuild
the dependencies, and some have failed:
- vlc needs the patch I linked to
- ffmpegthumbs needs vlc to be built first
- mlt needs vlc to be built first
- xbmc was already taken care of
- audacious-plugins-freeworld and acoustid-fingerprinter seem to be a
buildsys issue

Looks like we are almost there. The two remaining packages have not been
touched by upstream in ages and maybe we should reconsider whether it is
worth carrying them.

Best regards,
Julian

Re: ffmpeg-2.4 released

[Julian Sikorski]

W dniu 01.10.2014 o 23:03, David Timms pisze:
 On 02/10/14 03:51, Julian Sikorski wrote:
 ...
 Looks like we are almost there. The two remaining packages have not been
 touched by upstream in ages and maybe we should reconsider whether it is
 worth carrying them.
 
 Which packages are remaining please ?
 
dvbcut and kmediafactory.

J

Re: ffmpeg-2.4 released

[Julian Sikorski]

W dniu 01.10.2014 o 19:43, Ankur Sinha pisze:
 On Wed, 2014-10-01 at 19:23 +0200, Julian Sikorski wrote:
 t is related. Try doing
 # yum downgrade ffmpeg\*
 
 I only have 2.3.3 here:
 
 [asinha@localhost  99_Current_papers]$ rpm -qa \*ffmpeg\*
 ffmpeg-libs-2.3.3-3.fc21.x86_64
 gstreamer-ffmpeg-0.10.13-13.fc21.x86_64
 ffmpeg-2.3.3-3.fc21.x86_64
 
 Should I still attempt the downgrade?
 
Actually, despite what the changelog says, this release of mplayer still
requires ffmpeg-2.4.1.
Can you try these packages in the meantime?
http://lesloueizeh.com/belegdol/ffmpeg-rebuild/

Best regards,
Julian

Re: ffmpeg-2.4 released

[Julian Sikorski]

W dniu 25.09.2014 o 17:26, Sérgio Basto pisze:
 On Qui, 2014-09-25 at 07:47 +0200, Julian Sikorski wrote: 
 W dniu 21.09.2014 o 23:20, Sérgio Basto pisze:
 On Dom, 2014-09-21 at 19:03 +0200, Julian Sikorski wrote: 
 Dear all,

 ffmpeg-2.4 was released recently which means we have another rebuild
 coming up. I have done a test and only 4 packages have failed, which is
 not bad given the extent of API changes:
 - alsa-plugins-freeworld: pcm_a52.c:101:45: error: 'struct a52_ctx' has
 no member named 'frame'
 - dvbcut: lavfmuxer.cpp:63:57: error: 'av_new_stream' was not declared
 in this scope
 - kmediafactory: videofile.cpp:74:45: error: 'av_find_stream_info' was
 not declared in this scope (mencoder needs to be rebuilt first)
  - vlc: configure: error: libavcodec versions 56 and later are not
 supported yet.

 Given that we are close to branching (?), what would be the good time to
 do the rebuild?

 yes, I don't see any problem, I can do the mass rebuild of others
 packages, no problem.

 My question if we ever put this updates on F20 ? I'd like put it at
 least on update-testing. I can made a list of the packages, with
 ffmpeg / x264 dependencies, that should stay on update-testing for more
 time than usual, but is not my decision .  


 Best regards, 

 ffmpeg-2.4.1 has now been built. I will take care of rebuilding mplayer.

 Best regards,
 Julian
 
 Hi, please wait, let's wait to know if kwizart allow us to put ffmpeg
 2.3.3 in F20, we think it is better and we have strong reasons , like
 explained in
 https://lists.rpmfusion.org/pipermail/rpmfusion-developers/2014-September/017393.html
 
 Kwizart , do you allow this exception ? 
 
 
 Thanks, 
 
Just to be clear: I only pushed it to devel. F20 is still an open question.

Best regards,
Julian

Re: ffmpeg-2.4 released

[Julian Sikorski]

W dniu 25.09.2014 o 20:56, Sérgio Basto pisze:
 
 On Qui, 2014-09-25 at 19:27 +0200, Julian Sikorski wrote: 
 W dniu 25.09.2014 o 17:26, Sérgio Basto pisze:
 On Qui, 2014-09-25 at 07:47 +0200, Julian Sikorski wrote: 
 W dniu 21.09.2014 o 23:20, Sérgio Basto pisze:
 On Dom, 2014-09-21 at 19:03 +0200, Julian Sikorski wrote: 
 Dear all,

 ffmpeg-2.4 was released recently which means we have another rebuild
 coming up. I have done a test and only 4 packages have failed, which is
 not bad given the extent of API changes:
 - alsa-plugins-freeworld: pcm_a52.c:101:45: error: 'struct a52_ctx' has
 no member named 'frame'
 - dvbcut: lavfmuxer.cpp:63:57: error: 'av_new_stream' was not declared
 in this scope
 - kmediafactory: videofile.cpp:74:45: error: 'av_find_stream_info' was
 not declared in this scope (mencoder needs to be rebuilt first)
  - vlc: configure: error: libavcodec versions 56 and later are not
 supported yet.

 Given that we are close to branching (?), what would be the good time to
 do the rebuild?

 yes, I don't see any problem, I can do the mass rebuild of others
 packages, no problem.

 My question if we ever put this updates on F20 ? I'd like put it at
 least on update-testing. I can made a list of the packages, with
 ffmpeg / x264 dependencies, that should stay on update-testing for more
 time than usual, but is not my decision .  


 Best regards, 

 ffmpeg-2.4.1 has now been built. I will take care of rebuilding mplayer.

 Best regards,
 Julian

 Hi, please wait, let's wait to know if kwizart allow us to put ffmpeg
 2.3.3 in F20, we think it is better and we have strong reasons , like
 explained in
 https://lists.rpmfusion.org/pipermail/rpmfusion-developers/2014-September/017393.html

 Kwizart , do you allow this exception ? 


 Thanks, 

 Just to be clear: I only pushed it to devel. F20 is still an open question.
 
 yes , but I want copy from devel to F20, the state of art , before
 upgrading to ffmpeg 2.4 , will be  more easier , clean etc , and  just
 after this update (on F20), update devel to ffmpeg 2.4 
 
 Thanks, 
 
Hi,

it seems like we had a bit of misunderstanding. I was under the
impression we are good to go with 2.4 in rawhide, and 2.2/2.3 for F20 is
what we were discussing.
I don't think it makes sense to roll back now, let's just rebuild the
dependencies to minimise breakage time.
I think I should apply for the ffmpeg deps commit access moving forward,
so that there are more people who can do the rebuild.

Best regards,
Julian

Re: ffmpeg-2.4 released

[Julian Sikorski]

W dniu 21.09.2014 o 23:20, Sérgio Basto pisze:
 On Dom, 2014-09-21 at 19:03 +0200, Julian Sikorski wrote: 
 Dear all,

 ffmpeg-2.4 was released recently which means we have another rebuild
 coming up. I have done a test and only 4 packages have failed, which is
 not bad given the extent of API changes:
 - alsa-plugins-freeworld: pcm_a52.c:101:45: error: 'struct a52_ctx' has
 no member named 'frame'
 - dvbcut: lavfmuxer.cpp:63:57: error: 'av_new_stream' was not declared
 in this scope
 - kmediafactory: videofile.cpp:74:45: error: 'av_find_stream_info' was
 not declared in this scope (mencoder needs to be rebuilt first)
  - vlc: configure: error: libavcodec versions 56 and later are not
 supported yet.

 Given that we are close to branching (?), what would be the good time to
 do the rebuild?
 
 yes, I don't see any problem, I can do the mass rebuild of others
 packages, no problem.
 
 My question if we ever put this updates on F20 ? I'd like put it at
 least on update-testing. I can made a list of the packages, with
 ffmpeg / x264 dependencies, that should stay on update-testing for more
 time than usual, but is not my decision .  
 
 
 Best regards, 
 
ffmpeg-2.4.1 has now been built. I will take care of rebuilding mplayer.

Best regards,
Julian

Re: ffmpeg-2.4 released

[Julian Sikorski]

W dniu 22.09.2014 o 16:57, Sérgio Basto pisze:
 On Seg, 2014-09-22 at 06:50 +0200, Julian Sikorski wrote: 
 W dniu 22.09.2014 o 05:35, Ralf Corsepius pisze:
 On 09/21/2014 11:20 PM, Sérgio Basto wrote:
 On Dom, 2014-09-21 at 19:03 +0200, Julian Sikorski wrote:
 Dear all,

 ffmpeg-2.4 was released recently which means we have another rebuild
 coming up. I have done a test and only 4 packages have failed, which is
 not bad given the extent of API changes:
 - alsa-plugins-freeworld: pcm_a52.c:101:45: error: 'struct a52_ctx' has
 no member named 'frame'
 - dvbcut: lavfmuxer.cpp:63:57: error: 'av_new_stream' was not declared
 in this scope
 - kmediafactory: videofile.cpp:74:45: error: 'av_find_stream_info' was
 not declared in this scope (mencoder needs to be rebuilt first)
   - vlc: configure: error: libavcodec versions 56 and later are not
 supported yet.

 Given that we are close to branching (?), what would be the good time to
 do the rebuild?

 yes, I don't see any problem, I can do the mass rebuild of others
 packages, no problem.

 My question if we ever put this updates on F20 ?

 No. If I understand correctly, this is an API/ABI incompatible upgrade
 and not an ordinary update. This means, unless there are very good
 reasons (e.g. security critical bug fixes), which make such upgrades
 inevitably necessary, such upgrades are harmful and should not happen.
 Keep in mind, people might build other packages based on your packages,
 which might break because of your upgrade.

 I'd like put it at
 least on update-testing.
 Sorry, but this can't work.

 Ralf

 I tend to agree with Ralf here. Having said that, I believe we should do
 something about F-20. It is currently tracking ffmpeg-2.1 branch, which
 seems to be unmaintained [1]. Looking at the API changes [2], updating
 to 2.2/2.3 should be relatively painless.
 
 Hi, as you may know, I have some difficulties in deal with foreigner
 language (English). IIUC , upgrade to ffmpeg-2.3 in F-20 , also have
 API/ABI incompatible.
 Of course I'm not saying put ffmpeg-2.4 in F-20 without testing ,  2.3
 is tested on F-21 Alpha , I have 2 machines and one vm , and don't found
 any bug . 
 For me is fine put ffmpeg-2.3 / x264-0.142 in F-20 updates-testing , but
 as Ralf point out, we are breaking some rules . 
 
 
 Best regards,
 Julian

 [1] http://ffmpeg.org/olddownload.html
 [2] http://upstream-tracker.org/versions/ffmpeg.html
 
Hello,

my apologies, I should have expressed myself more clearly. The reason I
was suggesting 2.3 as an alternative to 2.4 is that it is less
disruptive. Please have a look at the soname versions below:

- ffmpeg-2.1:
libavutil  52. 48.101
libavcodec 55. 39.101
libavformat55. 19.104
libavdevice55.  5.100
libavfilter 3. 90.100
libavresample   1.  1.  0
libswscale  2.  5.101
libswresample   0. 17.104
libpostproc52.  3.100

- ffmpeg-2.3:
libavutil  52. 92.100
libavcodec 55. 69.100
libavformat55. 48.100
libavdevice55. 13.102
libavfilter 4. 11.100
libavresample   1.  3.  0
libswscale  2.  6.100
libswresample   0. 19.100
libpostproc52.  3.100

As you can see, the major versions are all the same for everything
except libavfilter. In contrast, ffmpeg-2.4 has the following:

libavutil  54.  7.100
libavcodec 56.  1.100
libavformat56.  4.101
libavdevice56.  0.100
libavfilter 5.  1.100
libavresample   2.  1.  0
libswscale  3.  0.100
libswresample   1.  1.100
libpostproc53.  0.100

Every single library got a soname bump.
The upstream-tracker.org website reveals that no symbols were removed
between ffmpeg-2.1 and ffmpeg-2.3. Conversely, ffmpeg-2.4 has 20 symbols
removed vs 2.3.3.
Finally, the reason I was suggesting moving away from ffmpeg-2.1 is due
to the top of the Old releases page [3]:
These releases are not actively maintained and thus we discourage their use.

Best regards,
Julian

[1] http://ffmpeg.org/olddownload.html

ffmpeg-2.4 released

[Julian Sikorski]

Dear all,

ffmpeg-2.4 was released recently which means we have another rebuild
coming up. I have done a test and only 4 packages have failed, which is
not bad given the extent of API changes:
- alsa-plugins-freeworld: pcm_a52.c:101:45: error: 'struct a52_ctx' has
no member named 'frame'
- dvbcut: lavfmuxer.cpp:63:57: error: 'av_new_stream' was not declared
in this scope
- kmediafactory: videofile.cpp:74:45: error: 'av_find_stream_info' was
not declared in this scope (mencoder needs to be rebuilt first)
 - vlc: configure: error: libavcodec versions 56 and later are not
supported yet.

Given that we are close to branching (?), what would be the good time to
do the rebuild?

Best regards,
Julian

Re: ffmpeg-2.4 released

[Julian Sikorski]

W dniu 21.09.2014 o 19:03, Julian Sikorski pisze:
 Dear all,
 
 ffmpeg-2.4 was released recently which means we have another rebuild
 coming up. I have done a test and only 4 packages have failed, which is
 not bad given the extent of API changes:
 - alsa-plugins-freeworld: pcm_a52.c:101:45: error: 'struct a52_ctx' has
 no member named 'frame'
 - dvbcut: lavfmuxer.cpp:63:57: error: 'av_new_stream' was not declared
 in this scope
 - kmediafactory: videofile.cpp:74:45: error: 'av_find_stream_info' was
 not declared in this scope (mencoder needs to be rebuilt first)
  - vlc: configure: error: libavcodec versions 56 and later are not
 supported yet.
 
 Given that we are close to branching (?), what would be the good time to
 do the rebuild?
 
 Best regards,
 Julian
 
Please excuse my replying to myself. Some of the work seems already done:
- alsa-plugins: looking at arch seems to indicate this can be fixed by
updating to 1.0.28
- vlc:
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/vlc-2.1.5-ffmpeg-2.4.patch?h=packages/vlc

Best regards,
Julian

Re: ffmpeg-2.4 released

[Julian Sikorski]

W dniu 22.09.2014 o 05:35, Ralf Corsepius pisze:
 On 09/21/2014 11:20 PM, Sérgio Basto wrote:
 On Dom, 2014-09-21 at 19:03 +0200, Julian Sikorski wrote:
 Dear all,

 ffmpeg-2.4 was released recently which means we have another rebuild
 coming up. I have done a test and only 4 packages have failed, which is
 not bad given the extent of API changes:
 - alsa-plugins-freeworld: pcm_a52.c:101:45: error: 'struct a52_ctx' has
 no member named 'frame'
 - dvbcut: lavfmuxer.cpp:63:57: error: 'av_new_stream' was not declared
 in this scope
 - kmediafactory: videofile.cpp:74:45: error: 'av_find_stream_info' was
 not declared in this scope (mencoder needs to be rebuilt first)
   - vlc: configure: error: libavcodec versions 56 and later are not
 supported yet.

 Given that we are close to branching (?), what would be the good time to
 do the rebuild?

 yes, I don't see any problem, I can do the mass rebuild of others
 packages, no problem.

 My question if we ever put this updates on F20 ?
 
 No. If I understand correctly, this is an API/ABI incompatible upgrade
 and not an ordinary update. This means, unless there are very good
 reasons (e.g. security critical bug fixes), which make such upgrades
 inevitably necessary, such upgrades are harmful and should not happen.
 Keep in mind, people might build other packages based on your packages,
 which might break because of your upgrade.
 
 I'd like put it at
 least on update-testing.
 Sorry, but this can't work.
 
 Ralf
 
I tend to agree with Ralf here. Having said that, I believe we should do
something about F-20. It is currently tracking ffmpeg-2.1 branch, which
seems to be unmaintained [1]. Looking at the API changes [2], updating
to 2.2/2.3 should be relatively painless.

Best regards,
Julian

[1] http://ffmpeg.org/olddownload.html
[2] http://upstream-tracker.org/versions/ffmpeg.html

Re: mass rebuild plan

[Julian Sikorski]

W dniu 05.09.2014 03:15, Orion Poplawski pisze:
 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.
 
 
 
I have committed the patch now, thank you for finding it!

Best regards,
Julian

ffmpeg-2.3.1 released

[Julian Sikorski]

Dear all,

ffmpeg-2.3.1 has been released recently. I have done a test rebuild, and
only 3 packages have failed:
- audacious-plugins-freeworld: fails due to missing glib.h - looks like
it is not related to ffmpeg
- xbmc: fails during debuginfo extraction
(/usr/lib/rpm/find-debuginfo.sh: line 127: 23577 Bus error
 (core dumped) eu-strip --remove-comment $r $g -f $1 $2
- kmediafactory: fails due to QtWebKit/QtWebView - also not related to
ffmpeg.

The rpmsodiff output is attached.
As none of the build errors are related to ffmpeg, I am going to push it
to rawhide this evening if noone objects.

Best regards,
Julian
	common sonames:
libavcodec.so.55	/usr/lib64/libavcodec.so.55.52.102	/usr/lib64/libavcodec.so.55.69.100
libavdevice.so.55	/usr/lib64/libavdevice.so.55.10.100	/usr/lib64/libavdevice.so.55.13.102
libavfilter.so.4	/usr/lib64/libavfilter.so.4.2.100	/usr/lib64/libavfilter.so.4.11.100
libavformat.so.55	/usr/lib64/libavformat.so.55.33.100	/usr/lib64/libavformat.so.55.48.100
libavresample.so.1	/usr/lib64/libavresample.so.1.2.0	/usr/lib64/libavresample.so.1.3.0
libavutil.so.52	/usr/lib64/libavutil.so.52.66.100	/usr/lib64/libavutil.so.52.92.100
libpostproc.so.52	/usr/lib64/libpostproc.so.52.3.100	/usr/lib64/libpostproc.so.52.3.100
libswresample.so.0	/usr/lib64/libswresample.so.0.18.100	/usr/lib64/libswresample.so.0.19.100
libswscale.so.2	/usr/lib64/libswscale.so.2.5.102	/usr/lib64/libswscale.so.2.6.100

--- ffmpeg-libs-2.2.5-1.fc22/libavcodec.so.55	2014-08-05 07:50:15.736192986 +0200
+++ ffmpeg-libs-2.3.1-1.fc22/libavcodec.so.55	2014-08-03 11:19:58.288098000 +0200
@@ -32,2 +32,4 @@
 av_dup_packet	T
+av_dv_codec_profile	T
+av_dv_frame_profile	T
 av_fast_malloc	T
@@ -68,2 +70,3 @@
 av_packet_ref	T
+av_packet_rescale_ts	T
 av_packet_shrink_side_data	T
@@ -104,2 +107,5 @@
 avcodec_copy_context	T
+avcodec_dct_alloc	T
+avcodec_dct_get_class	T
+avcodec_dct_init	T
 avcodec_decode_audio3	T
@@ -133,2 +139,3 @@
 avcodec_flush_buffers	T
+avcodec_free_context	T
 avcodec_free_frame	T
@@ -177,2 +184,3 @@
 avpriv_dv_frame_profile2	T
+avpriv_exif_decode_ifd	T
 avpriv_find_pix_fmt	T
@@ -199,2 +207,4 @@
 avpriv_mpegaudio_decode_header	T
+avpriv_pix_fmt_bps_avi	R
+avpriv_pix_fmt_bps_mov	R
 avpriv_put_string	T
@@ -235,2 +245,4 @@
 ff_fdct_sse2	T
+ff_fdctdsp_init	T
+ff_fdctdsp_init_x86	T
 ff_fft_end	T
@@ -252,2 +264,3 @@
 ff_idct_xvid_sse2_put	T
+ff_idctdsp_init	T
 ff_jpeg_fdct_islow_10	T
@@ -264,2 +277,3 @@
 ff_mdct_init_fixed_32	T
+ff_pixblockdsp_init	T
 ff_raw_pix_fmt_tags	R

	14 symbols added
R avpriv_pix_fmt_bps_avi
R avpriv_pix_fmt_bps_mov
T av_dv_codec_profile
T av_dv_frame_profile
T av_packet_rescale_ts
T avcodec_dct_alloc
T avcodec_dct_get_class
T avcodec_dct_init
T avcodec_free_context
T avpriv_exif_decode_ifd
T ff_fdctdsp_init
T ff_fdctdsp_init_x86
T ff_idctdsp_init
T ff_pixblockdsp_init

# template for libavcodec.so.55 version script
FFMPEG_2.3.1 {
global:
	av_dv_codec_profile;
	av_dv_frame_profile;
	av_packet_rescale_ts;
	avcodec_dct_alloc;
	avcodec_dct_get_class;
	avcodec_dct_init;
	avcodec_free_context;
	avpriv_exif_decode_ifd;
	avpriv_pix_fmt_bps_avi;
	avpriv_pix_fmt_bps_mov;
	ff_fdctdsp_init;
	ff_fdctdsp_init_x86;
	ff_idctdsp_init;
	ff_pixblockdsp_init;
};

--- ffmpeg-libs-2.2.5-1.fc22/libavdevice.so.55	2014-08-05 07:50:15.736192986 +0200
+++ ffmpeg-libs-2.3.1-1.fc22/libavdevice.so.55	2014-08-03 11:19:58.288098000 +0200
@@ -1,2 +1,4 @@
 avdevice_app_to_dev_control_message	T
+avdevice_capabilities_create	T
+avdevice_capabilities_free	T
 avdevice_configuration	T

	2 symbols added
T avdevice_capabilities_create
T avdevice_capabilities_free

# template for libavdevice.so.55 version script
FFMPEG_2.3.1 {
global:
	avdevice_capabilities_create;
	avdevice_capabilities_free;
};

libavfilter.so.4 definitions unchanged

--- ffmpeg-libs-2.2.5-1.fc22/libavformat.so.55	2014-08-05 07:50:15.736192986 +0200
+++ ffmpeg-libs-2.3.1-1.fc22/libavformat.so.55	2014-08-03 11:19:58.288098000 +0200
@@ -23,2 +23,3 @@
 av_format_get_video_codec	T
+av_format_inject_global_side_data	T
 av_format_set_audio_codec	T
@@ -63,4 +64,6 @@
 av_set_pts_info	T
+av_stream_get_end_pts	T
 av_stream_get_parser	T
 av_stream_get_r_frame_rate	T
+av_stream_get_side_data	T
 av_stream_set_r_frame_rate	T

	3 symbols added
T av_format_inject_global_side_data
T av_stream_get_end_pts
T av_stream_get_side_data

# template for libavformat.so.55 version script
FFMPEG_2.3.1 {
global:
	av_format_inject_global_side_data;
	av_stream_get_end_pts;
	av_stream_get_side_data;
};

--- ffmpeg-libs-2.2.5-1.fc22/libavresample.so.1	2014-08-05 07:50:15.736192986 +0200
+++ ffmpeg-libs-2.3.1-1.fc22/libavresample.so.1	2014-08-03 11:19:58.288098000 +0200
@@ -10,2 +10,3 @@
 avresample_get_matrix	T
+avresample_get_out_samples	T
 avresample_is_open	T

	1 symbols added
T avresample_get_out_samples

# template for libavresample.so.1 version script
FFMPEG_2.3.1 {
global:
	avresample_get_out_samples;
};

--- ffmpeg-libs-2.2.5-1.fc22/libavutil.so.52	2014-08-05 07:50:15.736192986 

Re: ffmpeg-2.2 released

[Julian Sikorski]

W dniu 24.03.2014 18:56, Michael Cronenworth pisze:
 Julian Sikorski wrote:
 ffmpeg-2.2 was released today. I did a test rebuild and all but one deps
 have compiled successfully (I could not believe it myself). The only one
 that failed was mlt, but the failure was due to freetype and not due to
 ffmpeg. As such, I will be pushing it to devel shortly unless someone
 objects.
 Moreover, given the long time until Fedora 21 release, I think we should
 consider pushing this as F20 update. Fedora did some exceptions this
 release cycle too (Mesa 10, Gnome 3.12). What do you think?
 
 I have no objection. Would it be best to wait for a 2.2.1 release before
 pushing to F20?
 
We can wait, no problem.
I have submitted the build, the following packages need to be rebuilt:

acoustid-fingerprinter
alsa-plugins-freeworld
audacious-plugins-freeworld
bino
bombono-dvd
chromaprint-tools
dvbcut
dvdstyler
ffmpegthumbnailer
ffmpegthumbs
gpac
guvcview
k3b-extras-freeworld
kmediafactory
libquicktime
libvdpau-va-gl
lightspark
minidlna
mlt
moc
mpd
mplayer
mpv
openmw
qmmp-plugins-freeworld
vdr-softhddevice
vlc
wxsvg
xbmc
xine-lib
xmms2-freeworld

Best regards,
Julian

ffmpeg-2.2 released

[Julian Sikorski]

Dear all,

ffmpeg-2.2 was released today. I did a test rebuild and all but one deps
have compiled successfully (I could not believe it myself). The only one
that failed was mlt, but the failure was due to freetype and not due to
ffmpeg. As such, I will be pushing it to devel shortly unless someone
objects.
Moreover, given the long time until Fedora 21 release, I think we should
consider pushing this as F20 update. Fedora did some exceptions this
release cycle too (Mesa 10, Gnome 3.12). What do you think?

Best regards,
Julian

Re: little mass rebuild required Re: x264 so bump

[Julian Sikorski]

W dniu 15.03.2014 16:54, Sérgio Basto pisze:
 On Sex, 2014-03-14 at 03:16 +, Sérgio Basto wrote: 
 Hi,

 On Qua, 2014-03-05 at 23:37 +, Sérgio Basto wrote: 
 Hi, 
 with x264 submitted into rawhide we need rebuild 


   * List what requires x264: 

 (build in first place) 

   * ffmpeg 
   * libquicktime 

 (others) 

   * avidemux 
   * mplayer 
   * ffmpeg-compat 
   * gstreamer1-plugins-ugly 
   * gstreamer-plugins-ugly 
   * mythtv 
   * vlc 


 Reference : http://rpmfusion.org/ImportantDependencyLists (updated)

 Today, x264 updated git stable version and we got again, soname bump.
 I already had prepared x264-0.142-1.20140314gitaff928d_bootstrap, we
 will need another little mass rebuild, I will commit into cvs and if
 ok , I submit tag and build .
 
 
 x264-0.142-1.20140314gitaff928d_bootstrap built on rawhide ! please
 rebuilt 
 (in first place) 
 
   * ffmpeg 
   * libquicktime 
 
 (others) 
 
   * avidemux 
   * mplayer 
   * ffmpeg-compat 
   * gstreamer1-plugins-ugly 
   * gstreamer-plugins-ugly 
   * mythtv 
   * vlc 
 
 Thanks, 

ffmpeg rebuild submitted.

Cheers,
Julian

 
 x264 seems that updates every two months, not change much code, so it
 relative safe do this little mass rebuilds and seems to me, the better,
 for helping out on devel this lib.

 Best regards,
 

Re: little mass rebuild required Re: x264 so bump

[Julian Sikorski]

W dniu 18.03.2014 07:17, Julian Sikorski pisze:
 W dniu 15.03.2014 16:54, Sérgio Basto pisze:
 On Sex, 2014-03-14 at 03:16 +, Sérgio Basto wrote: 
 Hi,

 On Qua, 2014-03-05 at 23:37 +, Sérgio Basto wrote: 
 Hi, 
 with x264 submitted into rawhide we need rebuild 


   * List what requires x264: 

 (build in first place) 

   * ffmpeg 
   * libquicktime 

 (others) 

   * avidemux 
   * mplayer 
   * ffmpeg-compat 
   * gstreamer1-plugins-ugly 
   * gstreamer-plugins-ugly 
   * mythtv 
   * vlc 


 Reference : http://rpmfusion.org/ImportantDependencyLists (updated)

 Today, x264 updated git stable version and we got again, soname bump.
 I already had prepared x264-0.142-1.20140314gitaff928d_bootstrap, we
 will need another little mass rebuild, I will commit into cvs and if
 ok , I submit tag and build .


 x264-0.142-1.20140314gitaff928d_bootstrap built on rawhide ! please
 rebuilt 
 (in first place) 

   * ffmpeg 
   * libquicktime 

 (others) 

   * avidemux 
   * mplayer 
   * ffmpeg-compat 
   * gstreamer1-plugins-ugly 
   * gstreamer-plugins-ugly 
   * mythtv 
   * vlc 

 Thanks, 
 
 ffmpeg rebuild submitted.
 
 Cheers,
 Julian

Ditto mplayer

Cheers,
Julian

 

 x264 seems that updates every two months, not change much code, so it
 relative safe do this little mass rebuilds and seems to me, the better,
 for helping out on devel this lib.

 Best regards,

 

Re: x264 and ffmpeg - here we go again

[Julian Sikorski]

W dniu 02.11.2013 02:52, Sérgio Basto pisze:
 On Qui, 2013-10-31 at 07:45 +0100, Julian Sikorski wrote:
 we should definitely do x264 first to save time. 
 
 OK!, x264 built with bootstrap , we can follow, this wiki page 
 http://rpmfusion.org/ImportantDependencyLists first paragraph
 Mass rebuild when bumping SO version of x264 and ffmpeg .
 
 Thanks and best regards, 
 
ffmpeg build submitted. I will update mplayer later.

Best regards,
Julian

Re: x264 and ffmpeg - here we go again

[Julian Sikorski]

W dniu 30.10.2013 22:18, Nicolas Chauvet pisze:
 2013/10/30 Sérgio Basto ser...@serjux.com
 mailto:ser...@serjux.com
 
 On Qua, 2013-10-30 at 07:22 +0100, Julian Sikorski wrote:
  W dniu 29.10.2013 22:11, Sérgio Basto pisze:
   On Ter, 2013-10-29 at 14:32 -0600, Ken Dreyer wrote:
   If we push ffmpeg 2.1 before we branch, we would ship F20 with a
   broken VLC, in that case?
  
   No, of course we won't ship VLC broken  .
  
   We just ship F20 in day of release or very closer until then we have
   time to fix VLC .
  
  I have just confirmed that VLC is not broken, it builds. I have cooked
  up a mock config containing a mix of F20 fedora repos and rawhide
  rpmfusion ones, and VLC was built successfully. I am rebuilding
  everything else as we speak. The results are likely to be even better
  than before, but I would like to be absolutely certain.
 
 Hi x264 stable git version just updated, some minutes ago , so I have
 x264-0.138-1.20131030gitc628e3b.fc19.src.rpm to submit .
 
 May be do all mass rebuild together we will have less work , what do you
 think ?
 
 About if we submit or not ? , don't want sounds rude, but my opinion
 is : what we are waiting for ? :)
 
 May I bootstrap x264 ?
 
 I'm not against it, but I should mention that there are few runtime
 issue that can arise even if the package is building fine. (such the one
 described in the ffmpeg2theora bugreport).
 
 There is also an issue with gpac that trigger a patch in x264. I really
 think gpac is culpid here (and shouldn't rely on libpng or else). Any
 chances to fix it on your side ?
 
 Beside that I'm fine with the update.
 Vlc 2.1.1 should rise-up soon, but the rdp API issue that is only in
 rawhide will not be fixed. librdp failed to version it's api appropriately.
 
 Thx for the hard work.
 
 
 Nicolas (kwizart)
 
With librdp out of the way, it looks as follows:

$ find -name success | sort
./audacious-plugins-freeworld-3.4.1-1.fc20/success
./chromaprint-tools-1.0-2.fc20/success
./dvbcut-0.6.1-14.svn179.fc20/success
./dvdstyler-2.6-0.1_rc2.fc20/success
./ffmpeg-2.1-1.fc20/success
./ffmpeg2theora-0.29-7.fc20/success
./ffmpegthumbs-4.11.1-1.fc20/success
./gpac-0.5.0-7.20130914svn.fc20/success
./guvcview-1.6.1-6.fc20/success
./libquicktime-1.2.4-12.fc20/success
./lightspark-0.7.2-4.20130827git.fc20/success
./minidlna-1.1.0-2.fc20/success
./mlt-0.9.0-1.fc20/success
./moc-2.5.0-0.10.beta1.fc20/success
./mpd-0.18-0.1.git0e0be02.fc20/success
./mplayer-1.1-14.20130811svn.fc20/success
./mpv-0.1.7-4.fc20/success
./openmw-0.26.0-6.fc20/success
./qmmp-plugins-freeworld-0.7.2-2.fc20/success
./vlc-2.1.0-2.fc20/success
./wxsvg-1.2.1-1.fc20/success
./x264-0.136-1.20131005git3361d59.fc20/success
./xbmc-13.0-0.1.Gotham_alpha8.fc20/success
./xine-lib-1.2.4-2.fc20/success
$ find -name fail | sort
./acoustid-fingerprinter-0.6-5.fc20/fail
./bino-1.4.2-4.fc20/fail
./bombono-dvd-1.2.2-4.fc20/fail
./ffmpegthumbnailer-2.0.8-6.fc20/fail
./kmediafactory-0.8.1-9.fc20/fail

If we do this, we should definitely do x264 first to save time. I think
runtime issues can be taken care of later, given they don't break our
buildroot.

Best regards,
Julian

Re: ffmpeg - here we go again

[Julian Sikorski]

W dniu 29.10.2013 22:11, Sérgio Basto pisze:
 On Ter, 2013-10-29 at 14:32 -0600, Ken Dreyer wrote:
 If we push ffmpeg 2.1 before we branch, we would ship F20 with a
 broken VLC, in that case?
 
 No, of course we won't ship VLC broken  .
 
 We just ship F20 in day of release or very closer until then we have
 time to fix VLC . 
 
I have just confirmed that VLC is not broken, it builds. I have cooked
up a mock config containing a mix of F20 fedora repos and rawhide
rpmfusion ones, and VLC was built successfully. I am rebuilding
everything else as we speak. The results are likely to be even better
than before, but I would like to be absolutely certain.

Best regards,
Julian

ffmpeg - here we go again

[Julian Sikorski]

Hi list,

ffmpeg-2.1 is out. preliminary rebuild shows 21 successes and 8 failures
- and 4 of those are due to vlc's libfreerdp issues.
I think we should branch first in any case:

$ find -name success | sort
./audacious-plugins-freeworld-3.4.1-1.fc20/success
./chromaprint-tools-1.0-2.fc20/success
./dvbcut-0.6.1-14.svn179.fc20/success
./dvdstyler-2.6-0.1_rc2.fc20/success
./ffmpeg-2.1-1.fc20/success
./ffmpeg2theora-0.29-7.fc20/success
./gpac-0.5.0-7.20130914svn.fc20/success
./guvcview-1.6.1-6.fc20/success
./libquicktime-1.2.4-12.fc20/success
./lightspark-0.7.2-4.20130827git.fc20/success
./minidlna-1.1.0-2.fc20/success
./moc-2.5.0-0.10.beta1.fc20/success
./mpd-0.18-0.1.git0e0be02.fc20/success
./mplayer-1.1-14.20130811svn.fc20/success
./mpv-0.1.7-4.fc20/success
./openmw-0.26.0-6.fc20/success
./qmmp-plugins-freeworld-0.7.2-2.fc20/success
./wxsvg-1.2.1-1.fc20/success
./x264-0.136-1.20131005git3361d59.fc20/success
./xbmc-13.0-0.1.Gotham_alpha8.fc20/success
./xine-lib-1.2.4-2.fc20/success
$ find -name fail | sort
./acoustid-fingerprinter-0.6-5.fc20/fail
./bino-1.4.2-4.fc20/fail
./bombono-dvd-1.2.2-4.fc20/fail
./ffmpegthumbnailer-2.0.8-6.fc20/fail
./ffmpegthumbs-4.11.1-1.fc20/fail
./kmediafactory-0.8.1-9.fc20/fail
./mlt-0.9.0-1.fc20/fail
./vlc-2.1.0-2.fc20/fail

Re: ffmpeg - here we go again

[Julian Sikorski]

W dniu 29.10.2013 21:11, Sérgio Basto pisze:
 On Ter, 2013-10-29 at 20:21 +0100, Julian Sikorski wrote: 
 Hi list,

 ffmpeg-2.1 is out. preliminary rebuild shows 21 successes and 8 failures
 - and 4 of those are due to vlc's libfreerdp issues.
 I think we should branch first in any case:

 $ find -name success | sort
 ./audacious-plugins-freeworld-3.4.1-1.fc20/success
 ./chromaprint-tools-1.0-2.fc20/success
 ./dvbcut-0.6.1-14.svn179.fc20/success
 ./dvdstyler-2.6-0.1_rc2.fc20/success
 ./ffmpeg-2.1-1.fc20/success
 ./ffmpeg2theora-0.29-7.fc20/success
 ./gpac-0.5.0-7.20130914svn.fc20/success
 ./guvcview-1.6.1-6.fc20/success
 ./libquicktime-1.2.4-12.fc20/success
 ./lightspark-0.7.2-4.20130827git.fc20/success
 ./minidlna-1.1.0-2.fc20/success
 ./moc-2.5.0-0.10.beta1.fc20/success
 ./mpd-0.18-0.1.git0e0be02.fc20/success
 ./mplayer-1.1-14.20130811svn.fc20/success
 ./mpv-0.1.7-4.fc20/success
 ./openmw-0.26.0-6.fc20/success
 ./qmmp-plugins-freeworld-0.7.2-2.fc20/success
 ./wxsvg-1.2.1-1.fc20/success
 ./x264-0.136-1.20131005git3361d59.fc20/success
 ./xbmc-13.0-0.1.Gotham_alpha8.fc20/success
 ./xine-lib-1.2.4-2.fc20/success
 $ find -name fail | sort
 ./acoustid-fingerprinter-0.6-5.fc20/fail
 ./bino-1.4.2-4.fc20/fail
 ./bombono-dvd-1.2.2-4.fc20/fail
 ./ffmpegthumbnailer-2.0.8-6.fc20/fail
 ./ffmpegthumbs-4.11.1-1.fc20/fail
 ./kmediafactory-0.8.1-9.fc20/fail
 ./mlt-0.9.0-1.fc20/fail
 ./vlc-2.1.0-2.fc20/fail
 
 acoustid-fingerprinter
 bino
 bombono-dvd
 ffmpegthumbnailer
 
 Already doesn't compile for ffmpeg-2.0, so IMHO you can submit it. 
 
 Thanks, 
 
There is still time needed to queue the rebuilds. I am happy to wait
post-branch, but if others disagree I can submit it now.

Best regards,
Julian

Re: ffmpeg - here we go again

[Julian Sikorski]

W dniu 29.10.2013 21:32, Ken Dreyer pisze:
 If we push ffmpeg 2.1 before we branch, we would ship F20 with a
 broken VLC, in that case?
 
 I vote that we branch sooner than later, since Beta is scheduled to
 ship in a month. Pushing back the branch date even further seems
 risky.
 
 - Ken

Keep in mind that vlc is broken for other reason:

rdp.c: In function 'preConnectHandler':
rdp.c:201:25: error: 'rdpSettings' has no member named 'sw_gdi'
 p_instance-settings-sw_gdi = true; /* render in buffer */
 ^
rdp.c:202:25: error: 'rdpSettings' has no member named 'fullscreen'
 p_instance-settings-fullscreen = true;
 ^
rdp.c:203:25: error: 'rdpSettings' has no member named 'hostname'
 p_instance-settings-hostname = strdup( p_sys-psz_hostname );
 ^
rdp.c:204:25: error: 'rdpSettings' has no member named 'username'
 p_instance-settings-username =

it seems that mock has pulled librdp from rawhide. There is no mock
rpmfusion config for f20 so testing is a bit harder, but I will try
nevertheless and see what happens.

Best regards,
Julian

Re: Late branching for F-20 because of FFmpeg deps needfix

[Julian Sikorski]

W dniu 27.08.2013 13:47, Nicolas Chauvet pisze:
 2013/8/27 Hans de Goede
 j.w.r.degoede-re5jqeeqqe8avxtiumw...@public.gmane.org
 mailto:j.w.r.dego...@gmail.com
 ...
  
 
 I've fixed libquicktime, gstreamer1-libav and frogatto (for new
 boost, not ffmpeg, building now).
 
 But it seems something has gone wrong with gstreamer1-libav, the
 build completed successfully, but:
 
 http://buildsys.rpmfusion.org/__plague-results/fedora-__development-rpmfusion_free/__gstreamer1-libav/1.1.3-2.fc20/
 
 http://buildsys.rpmfusion.org/plague-results/fedora-development-rpmfusion_free/gstreamer1-libav/1.1.3-2.fc20/
 only has debuginfo rpms, and the logs at:
 
 http://buildsys.rpmfusion.org/__logs/fedora-development-__rpmfusion_free/18240-__gstreamer1-libav-1.1.3-2.fc20/
 
 http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/18240-gstreamer1-libav-1.1.3-2.fc20/
 are also incomplete, maybe the disk is full ?
 
 The disk isn't full, but the changes to track the fedora development/f20
 repository instead of rawhide was not completed.
 Please bump and resubmit a new job to test if everything went right this
 time (you shouldn't have any build with .fc21).
 
 
  
 
 
 If you want me to help with other packages, a list of packages
 needing work would be useful.
 
 The failure page is probably helpful
 http://buildsys.rpmfusion.org/build-status/failed.psp
 Search for the recent failure submited by me.
 I can eventually requeue the build if a previous dependency has succeeded.
 
 Nicolas (kwizart)
Also see my earlier e-mail, I have posted the results of local rebuild

Best regards,
Julian

Re: x264 soname change for rawhide

[Julian Sikorski]

W dniu 14.07.2013 18:30, Sérgio Basto pisze:
 On Dom, 2013-07-14 at 09:17 -0500, Richard Shaw wrote: 
 On Sat, Jul 13, 2013 at 4:33 PM, Sérgio Basto ser...@serjux.com
 wrote:
 Hi,
 before update x264 to last stable commit
 
 We can analyze ABI changes with pkgdiff ,
 abi-compliance-checker and
 abi-dumper
 
 pkgdiff
 x264-debuginfo-0.130-3.20130502git1db4621.fc20.i686.rpm
 x264-debuginfo-0.133-1.20130709git585324f.fc20.i686.rpm
 -details
 
 http://www.serjux.com/pkgdiff_reports/x264-debuginfo/0.130-3.20130502git1db4621.fc20_to_0.133-1.20130709git585324f.fc20/changes_report.html
 
 http://www.serjux.com/pkgdiff_reports/x264/0.130-3.20130502git1db4621.fc20_to_0.133-1.20130709git585324f.fc20/changes_report.html
  


 Glad to see those tools are getting some use. I've got the official
 abi-dumper packages in testing. Feel free to give it karma to get it
 into stable faster.
 
 Ops I forgot that. Done . 

 avidemux-2.6.4-5.fc20.src.rpm
 mythtv-0.26.0-9.fc20.src.rpm 


 I don't have any updates planned for either of these packages so feel
 free to rebuild as needed or let me know when I need to kick them off.

 About bump ffmpeg, Julian Sikorski is in better place to say, if we
 should bump it or not.
 But thinking about it, we just need bootstrap x264, when both (x264 and
 ffmpeg) bump soname. In this case, I can just push x264 and after we
 will see, if ffmpeg bumps or not , therefore I will bump x264 soname in
 rawhide, if no one replies in short time ... ok ? 
 
 Thanks, 
 
I think we should bump. The sooner we do it, the more time we have to
fix the breakage.
I'll see how many packages rebuild and post the results here later today.

Best regards,
Julian

Re: x264 soname change for rawhide

[Julian Sikorski]

W dniu 01.08.2013 10:38, Julian Sikorski pisze:
 W dniu 14.07.2013 18:30, Sérgio Basto pisze:
 On Dom, 2013-07-14 at 09:17 -0500, Richard Shaw wrote: 
 On Sat, Jul 13, 2013 at 4:33 PM, Sérgio Basto ser...@serjux.com
 wrote:
 Hi,
 before update x264 to last stable commit
 
 We can analyze ABI changes with pkgdiff ,
 abi-compliance-checker and
 abi-dumper
 
 pkgdiff
 x264-debuginfo-0.130-3.20130502git1db4621.fc20.i686.rpm
 x264-debuginfo-0.133-1.20130709git585324f.fc20.i686.rpm
 -details
 
 http://www.serjux.com/pkgdiff_reports/x264-debuginfo/0.130-3.20130502git1db4621.fc20_to_0.133-1.20130709git585324f.fc20/changes_report.html
 
 http://www.serjux.com/pkgdiff_reports/x264/0.130-3.20130502git1db4621.fc20_to_0.133-1.20130709git585324f.fc20/changes_report.html
  


 Glad to see those tools are getting some use. I've got the official
 abi-dumper packages in testing. Feel free to give it karma to get it
 into stable faster.

 Ops I forgot that. Done . 

 avidemux-2.6.4-5.fc20.src.rpm
 mythtv-0.26.0-9.fc20.src.rpm 


 I don't have any updates planned for either of these packages so feel
 free to rebuild as needed or let me know when I need to kick them off.

 About bump ffmpeg, Julian Sikorski is in better place to say, if we
 should bump it or not.
 But thinking about it, we just need bootstrap x264, when both (x264 and
 ffmpeg) bump soname. In this case, I can just push x264 and after we
 will see, if ffmpeg bumps or not , therefore I will bump x264 soname in
 rawhide, if no one replies in short time ... ok ? 

 Thanks, 

 I think we should bump. The sooner we do it, the more time we have to
 fix the breakage.
 I'll see how many packages rebuild and post the results here later today.
 
 Best regards,
 Julian
 
Ok, this time changes are more severe:
- 10 packages rebuilt successfully:
  * audacious-plugins-freeworld-3.4-1.fc20
  * cmus-2.5.0-2.fc20
  * dvdstyler-2.5-1.fc20
  * ffmpeg-2.0-1.fc20
  * ffmpegthumbs-4.10.1-2.fc20
  * guvcview-1.6.1-4.fc20
  * mplayer-1.1-12.20130801svn.fc20
  * qmmp-plugins-freeworld-0.7.1-1.fc20
  * vlc-2.1.0-0.5.pre2.fc20
  * wxsvg-1.1.15-2.fc20
- 21 packages fail to rebuild:
  * acoustid-fingerprinter-0.6-3.fc20
  * alsa-plugins-freeworld-1.0.27-1.fc20
  * bino-1.4.2-2.fc20
  * bombono-dvd-1.2.2-2.fc20
  * chromaprint-tools-0.7-5.fc20
  * dvbcut-0.6.1-11.svn179.fc20
  * ffmpeg2theora-0.29-4.fc20
  * ffmpegthumbnailer-2.0.8-4.fc20
  * gpac-0.5.0-4.fc20
  * k3b-extras-freeworld-2.0.2-11.fc20
  * kmediafactory-0.8.1-8.fc20
  * libquicktime-1.2.4-7.fc20
  * lightspark-0.7.2-2.fc20.1
  * minidlna-1.0.26-2.fc20
  * mlt-0.8.8-5.fc20
  * mpd-0.17.3-3.fc20
  * picard-freeworld-1.1-3.fc20
  * x264-0.133-1.20130709git585324f.fc20
  * xbmc-12.2-3.fc20
  * xine-lib-extras-freeworld-1.1.21-6.fc20
  * xmms2-freeworld-0.8-8.fc20
13 of the failures seem to be caused by removal of
AVCODEC_MAX_AUDIO_FRAME_SIZE. I have now committed updated mplayer and
ffmpeg, but I will hold of building for a week or so so that maintainers
have the time to fix their packages.

Best regards,
Julian

Re: mass rebuild for x264/ffmpeg/mplayer on F19

[Julian Sikorski]

W dniu 25.05.2013 14:00, Sérgio Basto pisze:
 On Sáb, 2013-05-25 at 10:27 +0200, Andrea Musuruane wrote: 
 On Sat, May 25, 2013 at 1:43 AM, Sérgio Basto 
 sergio-icfkjj3otdhqt0dzr+a...@public.gmane.org
 wrote:
 [...]
 9 - build what requires ffmpeg.
 repoquery --releasever=19 --whatrequires ffmpeg\*1.1\*
 --source
 --alldeps | grep -vP x264|ffmpeg-1.1|gpac|^mplayer|vlc|
 mythtv|
 libquicktime|mjpegtools | sort -u
 
 [...]
 
 list 9 -
 acoustid-fingerprinter-0.6-2.fc19.src.rpm
 alsa-plugins-freeworld-1.0.26-3.fc19.src.rpm
 audacious-plugins-freeworld-3.3.4-1.fc19.src.rpm
 bino-1.4.1-2.fc19.src.rpm
 bombono-dvd-1.2.2-1.fc19.src.rpm
 chromaprint-tools-0.7-4.fc19.src.rpm
 cmus-2.5.0-1.fc19.src.rpm
 devede-3.23.0-1.fc19.src.rpm
 dvbcut-0.6.1-10.svn179.fc19.src.rpm
 dvd95-1.6p0-5.fc19.src.rpm
 dvd-slideshow-0.8.0-6.fc19.src.rpm
 dvdstyler-2.4.3-1.fc19.src.rpm
 ffmpeg2theora-0.29-3.fc19.src.rpm
 ffmpegthumbnailer-2.0.8-3.fc19.src.rpm
 ffmpegthumbs-4.10.1-1.fc19.src.rpm
 get_iplayer-2.80-6.fc19.src.rpm
 guvcview-1.6.1-3.fc19.src.rpm
 imagination-3.0-9.fc19.src.rpm
 k3b-extras-freeworld-2.0.2-10.fc19.src.rpm
 kdenlive-0.9.6-1.fc19.src.rpm
 kmediafactory-0.8.1-7.fc19.src.rpm
 lightspark-0.7.2-1.fc19.src.rpm
 minidlna-1.0.26-1.fc19.src.rpm
 miro-5.0.4-3.fc19.src.rpm
 mjpegtools-2.0.0-6.fc19.src.rpm
 mlt-0.8.8-3.fc19.src.rpm
 mpd-0.17.3-2.fc19.src.rpm
 picard-freeworld-1.1-2.fc19.src.rpm
 qmmp-plugins-freeworld-0.7.0-1.fc19.src.rpm
 vdrsync-0.1.3-16.PRE1.050322.fc19.src.rpm
 wxsvg-1.1.15-1.fc19.src.rpm
 xbmc-12.2-1.fc19.src.rpm
 xine-lib-extras-freeworld-1.1.21-5.fc19.src.rpm
 xmms2-freeworld-0.8-7.fc19.src.rpm
 

 These queries seems wrong to me because you are extracting both BR and
 Requires. For example devede does not BR ffmpeg, it just requires it
 at runtime. Rebuilding it is unneeded.
 Hi,
 by points 
 1 - Is not a problem, rebuild one package more. The opposite would be,
 miss packages builds.
 2 - not Buildrequires, but requires of binaries rpms , yeah query
 builrequires is a good idea.
 3 - devede requires ffmpeg by spec and you are right devede does need
 rebuild by ffmpeg update, because does change anything. But when we
 query the rpm, we don't have a way to know it, as it is possible put in
 a .spec a buildrequires that doesn't change build results ... , other
 point of view devede use ffmpeg in runtime changing ffmpeg may be not
 compatible, we only know testing it . 
 4 - thanks for point out this question.
 
 Best regards,
 
It's probably too late now, but here are my 2 cents:
- packages having mplayer in dependencies (like gmtk) do not need to be
rebuilt at all - they don't link to mplayer, they just use the executable
- this is what I use to get the deps whenever I am testing a new ffmpeg
build:

repoquery --disablerepo=* --enablerepo=rpmfusion-{non,}free-rawhide
--whatrequires --source `repoquery --provides --disablerepo=*
--enablerepo=rpmfusion-free-rawhide ffmpeg-libs` | sort | uniq | sed
's/-[^-]*-[^-]*\.[^.]*\.[^.]*$//'

which currently yields the following:

acoustid-fingerprinter
alsa-plugins-freeworld
audacious-plugins-freeworld
bino
bombono-dvd
chromaprint-tools
cmus
dvbcut
dvdstyler
ffmpeg
ffmpeg2theora
ffmpegthumbnailer
ffmpegthumbs
gpac
guvcview
k3b-extras-freeworld
kmediafactory
libquicktime
lightspark
minidlna
miro
mlt
mpd
mplayer
picard-freeworld
qmmp-plugins-freeworld
vlc
wxsvg
x264
xbmc
xine-lib-extras-freeworld
xmms2-freeworld

Best regards,
Julian

ffmpeg-compat question

[Julian Sikorski]

Hi,

I was wondering why are we shipping 0.6 as ffmpeg-compat and not 0.7.
From ffmpeg download page:

- 0.6: This release is not actively maintained and thus we discourage
its use. If you want to maintain this old version, contact us.

- 0.7: It contains almost all features and bugfixes of 0.8.14 while
being compatible with the 0.6 ABI and API.

Best regards,
Julian

Re: mass rebuild for x264/ffmpeg/mplayer on F19

[Julian Sikorski]

W dniu 25.05.2013 01:43, Sérgio Basto pisze:
 Review 
 
 On Sex, 2013-05-24 at 08:13 +0200, Nicolas Chauvet wrote:
 Ok,

 Please bootstrap x264/ffmpeg ASAP, It would be fine to have the
 rebuilt done this week-end.
 
 Built x264 with bootstrap , we also have mplayer updates ...  
 
 So steps are:
 1 - build x264 with bootstrap.
 2 - build ffmpeg

ffpeg is now rebuilt.

Julian

Re: mass rebuild for x264/ffmpeg/mplayer on F19

[Julian Sikorski]

W dniu 25.05.2013 14:03, Sérgio Basto pisze:
 On Sáb, 2013-05-25 at 11:32 +0200, Julian Sikorski wrote: 
 W dniu 25.05.2013 01:43, Sérgio Basto pisze:
 Review 

 On Sex, 2013-05-24 at 08:13 +0200, Nicolas Chauvet wrote:
 Ok,

 Please bootstrap x264/ffmpeg ASAP, It would be fine to have the
 rebuilt done this week-end.

 Built x264 with bootstrap , we also have mplayer updates ...  

 So steps are:
 1 - build x264 with bootstrap.
 2 - build ffmpeg

 ffpeg is now rebuilt.
 
 waiting for :) 
 5 - build mplayer 
 6 - build libquicktime (vlc and mjpegtools need it)
 
 
mplayer build submitted.

Julian

Re: buildsys out of disk space?

[Julian Sikorski]

W dniu 06.05.2013 17:17, Richard Shaw pisze:
 I was working on some new mythtv builds and saw this in the log after it
 failed:
 
 install: error writing
 '/builddir/build/BUILDROOT/mythtv-0.26.0-9.fc20.x86_64/usr/lib64/libmythtv-0.26.so.0.26.0':
 No space left on device
 
 Is the builder out of space?
 
 Thanks,
 Richard
Yes, it is:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2777

Julian

Re: ffmpeg-1.2 update

[Julian Sikorski]

W dniu 20.03.2013 23:53, Nicolas Chauvet pisze:
 2013/3/18 Nicolas Chauvet
 kwiz...@gmail.com
 mailto:kwiz...@gmail.com
 
 2013/3/18 Julian Sikorski
 beleg...@gmail.com
 mailto:beleg...@gmail.com
 
 W dniu 18.03.2013 21:16, Nicolas Chauvet pisze:
  2013/3/18 Julian Sikorski
  beleg...@gmail.com
 mailto:beleg...@gmail.com
  mailto:beleg...@gmail.com
 mailto:beleg...@gmail.com
 
  Dear all,
 
  ffmpeg-1.2 was released recently. I have run a round of
 dep rebuilds and
  the only packages that failed to rebuild were bino,
 lightspark and
  dvbcut. None of these failures point directly to ffmpeg
 though.
  I'd opt for pushing this into devel and F-19 ASAP, and
 then maybe even
  to F-18 - but that one should be carefully considered.
  rpmsodiff output is attached.
 
  devel is rawhide aka fedora-20 right now,  Any update must
 pass rawhide
  usability tests before anything else.
  As always I would like to have a sum-up of the ABI changes
 involved if any.
 
  I'm not fundamentally against having ffmpeg-1.2 in
 branched/F-19 at a
  later point. I just know some later ffmpeg update was locked
 by vlc
  because they will build but the rework needed to make it run
 will be
  done in the next vlc, not vlc bugfix.
 
  Nicolas (kwizart)
 
  Ps: I also don't have seen much mplayer update recently
 
 
 
 
 As you can see from the rpmsodiff output, only one symbol was
 removed.
 
 I should apologize, I've miss to see the rpmdiff output was attached in
 the first message.
 So the rpmsodiff looks more safe than I expected.
 There is a need to know the reason from this symbol removal, but this
 should be better to expect to F-19 soon, indeed.
 
 That been said, there are still pending FTBFS from the F-19 mass
 rebuild, and some of theses are related to ffmpeg API. So unless there
 is a newer version compatible with current ffmpeg, it would like them to
 be moved to ffmpeg-compat (motion failed to catch it despite my attempt).
 
 Nicolas (kwizart)
Hardware acceleration was overhauled so this might be the reason for
symbol removal.
I have now committed the updated spec so that maintainers can look into
fixing their packages, I'll submit a build in several days.

Best regards,
Julian

ffmpeg-1.2 update

[Julian Sikorski]

Dear all,

ffmpeg-1.2 was released recently. I have run a round of dep rebuilds and
the only packages that failed to rebuild were bino, lightspark and
dvbcut. None of these failures point directly to ffmpeg though.
I'd opt for pushing this into devel and F-19 ASAP, and then maybe even
to F-18 - but that one should be carefully considered.
rpmsodiff output is attached.

Best regards,
Julian
common sonames:
libavcodec.so.54/usr/lib64/libavcodec.so.54.86.100  
/usr/lib64/libavcodec.so.54.92.100
libavdevice.so.54   /usr/lib64/libavdevice.so.54.3.102  
/usr/lib64/libavdevice.so.54.3.103
libavfilter.so.3/usr/lib64/libavfilter.so.3.32.100  
/usr/lib64/libavfilter.so.3.42.103
libavformat.so.54   /usr/lib64/libavformat.so.54.59.106 
/usr/lib64/libavformat.so.54.63.104
libavutil.so.52 /usr/lib64/libavutil.so.52.13.100   
/usr/lib64/libavutil.so.52.18.100
libpostproc.so.52   /usr/lib64/libpostproc.so.52.2.100  
/usr/lib64/libpostproc.so.52.2.100
libswresample.so.0  /usr/lib64/libswresample.so.0.17.102
/usr/lib64/libswresample.so.0.17.102
libswscale.so.2 /usr/lib64/libswscale.so.2.1.103
/usr/lib64/libswscale.so.2.2.100

--- ffmpeg-libs-1.1.3-1.fc19/libavcodec.so.54   2013-03-11 00:15:08.0 
+0100
+++ ffmpeg-libs-1.2-1.fc20/libavcodec.so.54 2013-03-18 19:00:56.916374000 
+0100
@@ -166,2 +166,3 @@
 avpriv_check_timecode_rate T
+avpriv_color_frame T
 avpriv_copy_bits   T
@@ -173,2 +174,3 @@
 avpriv_dv_frame_profile2   T
+avpriv_find_pix_fmtT
 avpriv_flac_is_extradata_valid T
@@ -207,2 +209,3 @@
 ff_dnxhd_get_cid_table T
+ff_dsputil_initT
 ff_faandct T
@@ -263,2 +266 @@
 ff_simple_idct_put_mmx T
-ff_vdpau_vc1_decode_pictureT

1 symbols removed
T ff_vdpau_vc1_decode_picture

3 symbols added
T avpriv_color_frame
T avpriv_find_pix_fmt
T ff_dsputil_init

# template for libavcodec.so.54 version script
FFMPEG_1.2 {
global:
avpriv_color_frame;
avpriv_find_pix_fmt;
ff_dsputil_init;
};

libavdevice.so.54 definitions unchanged

--- ffmpeg-libs-1.1.3-1.fc19/libavfilter.so.3   2013-03-11 00:15:08.0 
+0100
+++ ffmpeg-libs-1.2-1.fc20/libavfilter.so.3 2013-03-18 19:00:56.916374000 
+0100
@@ -19,4 +19,6 @@
 avfilter_af_aconvert   D
+avfilter_af_afade  D
 avfilter_af_afifo  D
 avfilter_af_aformatD
+avfilter_af_allpassD
 avfilter_af_amerge D
@@ -35,2 +37,6 @@
 avfilter_af_atempo D
+avfilter_af_bandpass   D
+avfilter_af_bandreject D
+avfilter_af_bass   D
+avfilter_af_biquad D
 avfilter_af_channelmap D
@@ -39,5 +45,9 @@
 avfilter_af_ebur128D
+avfilter_af_equalizer  D
+avfilter_af_highpass   D
 avfilter_af_join   D
+avfilter_af_lowpassD
 avfilter_af_panD
 avfilter_af_silencedetect  D
+avfilter_af_treble D
 avfilter_af_volume D
@@ -118,2 +128,3 @@
 avfilter_vf_blackframe D
+avfilter_vf_blend  D
 avfilter_vf_boxblurD
@@ -141,2 +152,3 @@
 avfilter_vf_histeq D
+avfilter_vf_histogram  D
 avfilter_vf_hqdn3d D
@@ -144,2 +156,3 @@
 avfilter_vf_idet   D
+avfilter_vf_il D
 avfilter_vf_kerndeint  D
@@ -151,2 +164,3 @@
 avfilter_vf_noformat   D
+avfilter_vf_noise  D
 avfilter_vf_null   D
@@ -169,2 +183,3 @@
 avfilter_vf_split  D
+avfilter_vf_stereo3d   D
 avfilter_vf_subtitles  D

15 symbols added
D avfilter_af_afade
D avfilter_af_allpass
D avfilter_af_bandpass
D avfilter_af_bandreject
D avfilter_af_bass
D avfilter_af_biquad
D avfilter_af_equalizer
D avfilter_af_highpass
D avfilter_af_lowpass
D avfilter_af_treble
D avfilter_vf_blend
D avfilter_vf_histogram
D avfilter_vf_il
D avfilter_vf_noise
D avfilter_vf_stereo3d

# template for libavfilter.so.3 version script
FFMPEG_1.2 {
global:
avfilter_af_afade;
avfilter_af_allpass;
avfilter_af_bandpass;
avfilter_af_bandreject;
avfilter_af_bass;
avfilter_af_biquad;
avfilter_af_equalizer;
avfilter_af_highpass;
avfilter_af_lowpass;
avfilter_af_treble;
avfilter_vf_blend;
avfilter_vf_histogram;
avfilter_vf_il;
avfilter_vf_noise;
avfilter_vf_stereo3d;
};

--- ffmpeg-libs-1.1.3-1.fc19/libavformat.so.54  2013-03-11 00:15:08.0 
+0100
+++ ffmpeg-libs-1.2-1.fc20/libavformat.so.542013-03-18 19:00:56.916374000 
+0100
@@ -5,2 +5,3 @@
 av_codec_get_tag   T
+av_codec_get_tag2  T
 av_convert_lang_to T
@@ -120,2 +121,3 @@
 avpriv_set_pts_infoT
+ff_codec_get_idT
 ff_inet_aton   T

2 symbols added
T av_codec_get_tag2
T ff_codec_get_id

# template for libavformat.so.54 version script
FFMPEG_1.2 {
global:
av_codec_get_tag2;
ff_codec_get_id;
};

--- ffmpeg-libs-1.1.3-1.fc19/libavutil.so.522013-03-11 00:15:08.0 
+0100
+++ ffmpeg-libs-1.2-1.fc20/libavutil.so.52  2013-03-18 19:00:56.916374000 
+0100
@@ -25,2 +25,3 @@
 av_bprint_clearT
+av_bprint_escape  

Re: ffmpeg-1.2 update

[Julian Sikorski]

W dniu 18.03.2013 21:16, Nicolas Chauvet pisze:
 2013/3/18 Julian Sikorski
 beleg...@gmail.com
 mailto:beleg...@gmail.com
 
 Dear all,
 
 ffmpeg-1.2 was released recently. I have run a round of dep rebuilds and
 the only packages that failed to rebuild were bino, lightspark and
 dvbcut. None of these failures point directly to ffmpeg though.
 I'd opt for pushing this into devel and F-19 ASAP, and then maybe even
 to F-18 - but that one should be carefully considered.
 rpmsodiff output is attached.
 
 devel is rawhide aka fedora-20 right now,  Any update must pass rawhide
 usability tests before anything else.
 As always I would like to have a sum-up of the ABI changes involved if any.
 
 I'm not fundamentally against having ffmpeg-1.2 in branched/F-19 at a
 later point. I just know some later ffmpeg update was locked by vlc
 because they will build but the rework needed to make it run will be
 done in the next vlc, not vlc bugfix.
 
 Nicolas (kwizart)
 
 Ps: I also don't have seen much mplayer update recently
 
 
 
 
As you can see from the rpmsodiff output, only one symbol was removed.
More details can be seen here:
http://upstream-tracker.org/versions/ffmpeg.html
vlc builds indeed, I can look into setting up a test environment to
check whether it runs. In any case, f20 is eons away so there will be
plenty of time to fix this.
When it comes to mplayer, each branch contains the latest mplayer that
will build together with ffmpeg shipped on said branch. ffmpeg-1.2
allows building today's snapshot, so the update limit has not been
reached yet.

Julian

Re: updated ffmpeg.spec for rhel5 too

[Julian Sikorski]

W dniu 23.01.2013 09:58, Farkas Levente pisze:
 and of course the spec file:-)
 
 On 01/23/2013 09:51 AM, Farkas Levente wrote:
 hi,
 there is a little bit modified ffmpeg.spec file which can be build on
 rhel6 and rhel5 too (and of course fedora too). it'd be nice to update
 rpmfusion spec file to this.
 regards.

 
Nicolas,

do we have an EL branch for ffmpeg?

Julian

Re: updated ffmpeg.spec for rhel5 too

[Julian Sikorski]

W dniu 30.01.2013 19:44, Farkas Levente pisze:
 On 01/30/2013 07:13 PM, Julian Sikorski wrote:
 W dniu 23.01.2013 09:58, Farkas Levente pisze:
 and of course the spec file:-)

 On 01/23/2013 09:51 AM, Farkas Levente wrote:
 hi,
 there is a little bit modified ffmpeg.spec file which can be build on
 rhel6 and rhel5 too (and of course fedora too). it'd be nice to update
 rpmfusion spec file to this.
 regards.


 Nicolas,

 do we have an EL branch for ffmpeg?
 
 of course:-)
 
I'm not sure where this is supposed to go then. EL-6 ffmpeg is at
0.10.6, whereas your spec is based on 1.0.1. I think Nicolas is a better
person to talk to since I have no clue about RHEL.

Julian

Re: updated ffmpeg.spec for rhel5 too

[Julian Sikorski]

W dniu 30.01.2013 19:56, Farkas Levente pisze:
 On 01/30/2013 07:52 PM, Julian Sikorski wrote:
 W dniu 30.01.2013 19:44, Farkas Levente pisze:
 On 01/30/2013 07:13 PM, Julian Sikorski wrote:
 W dniu 23.01.2013 09:58, Farkas Levente pisze:
 and of course the spec file:-)

 On 01/23/2013 09:51 AM, Farkas Levente wrote:
 hi,
 there is a little bit modified ffmpeg.spec file which can be build on
 rhel6 and rhel5 too (and of course fedora too). it'd be nice to update
 rpmfusion spec file to this.
 regards.


 Nicolas,

 do we have an EL branch for ffmpeg?

 of course:-)

 I'm not sure where this is supposed to go then. EL-6 ffmpeg is at
 0.10.6, whereas your spec is based on 1.0.1. I think Nicolas is a better
 person to talk to since I have no clue about RHEL.
 
 i'm just fix a few thing in
 /rpmfusion/free/fedora/development/rawhide/source/SRPMS/ffmpeg-1.0.1-1.fc19.src.rpm
 to be able to build on rhel5/6 too and thought i'd be useful to send it
 to you since (as you was in the changelog entry of the spec) to be able
 to use to build rhel package too.
 regards.
 
OK, this makes it clearer what I should diff it against. Will have a
look later.

Julian

Re: ffmpeg: here we go again

[Julian Sikorski]

W dniu 19.01.2013 13:19, Sérgio Basto pisze:
 On Sáb, 2013-01-19 at 12:16 +, Sérgio Basto wrote: 
 Meanwhile I build x264-0.129 (soname bump) to rawhide (though that
 already have new ffmpeg there)  .
 
 Meanwhile I built x264-0.129 (soname bump) to rawhide (though that
 already have new ffmpeg there)  .
 
What needs to be built first? x264 or ffmpeg?

Julian

Re: ffmpeg: here we go again

[Julian Sikorski]

W dniu 20.01.2013 22:09, Julian Sikorski pisze:
 W dniu 19.01.2013 13:19, Sérgio Basto pisze:
 On Sáb, 2013-01-19 at 12:16 +, Sérgio Basto wrote: 
 Meanwhile I build x264-0.129 (soname bump) to rawhide (though that
 already have new ffmpeg there)  .

 Meanwhile I built x264-0.129 (soname bump) to rawhide (though that
 already have new ffmpeg there)  .

 What needs to be built first? x264 or ffmpeg?
 
 Julian
 
I can see that Nicolas built the new ffmpeg now. Sorry I could not help,
was away travelling.

Julian

ffmpeg: here we go again

[Julian Sikorski]

Hi list,

ffmpeg-1.1 was released today. Out of 32 deps we are carrying, only 2
failed to rebuild (bino and motion). Given how early in F-19 cycle we
are, I'm inclined to push it sooner than later. Keep in mind that
dvdstyler and kmediafactory can only be rebuilt in the 2nd round.
I'll commit the changes and submit a build a few days later.

Regards,
Julian

Re: buildsystem mame

[Julian Sikorski]

W dniu 2012-12-20 01:41, Sérgio Basto pisze:

On Sáb, 2012-11-10 at 11:57 +0100, Julian Sikorski wrote:

W dniu 08.11.2012 21:43, Sérgio Basto pisze:

On Dom, 2012-10-28 at 16:42 +, Sérgio Basto wrote:

On Dom, 2012-10-28 at 07:38 +0100, Julian Sikorski wrote:



It built, but the process took 600 minutes. This is still a bit slow
IMO. I'll just build the missing mame-0.147 for F-18 and hold on with
u-releases until we get more memory for the buildsys.



14860 (mame): Build on target fedora-18-rpmfusion_nonfree succeeded.


i686: builder1.rpmfusion.org Status:  done/done Build Time:  85 minutes
x86_64: builder1.rpmfusion.org Status:  done/done Build Time:  210
minutes

My bet is a problem only with rawhide (F19) build system.

http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_nonfree/14859-mame-0.147u1-2.fc19/i686/root.log
we can see in this link that we have lots of Cannot allocate memory ,
while on F18 we don't have .

I remember see a failed build log with VirtualBox on F19 like Memory
exhausted , but never in F18


Comparing building mame-0_147u2 on F16, F17 , F18 and Rawhide

http://buildsys.rpmfusion.org/build-status/job.psp?uid=14967

http://buildsys.rpmfusion.org/build-status/job.psp?uid=14966

http://buildsys.rpmfusion.org/build-status/job.psp?uid=14976

http://buildsys.rpmfusion.org/build-status/job.psp?uid=14907

F16 Build Time =~ 96 minutes
F17 Build Time =~ 107 minutes
but F18 Build Time =~ 1250 minutes !?!
and F19 Build Time =~ 676 minutes

So my guess was totally wrong , So what is the the problem ?  is from
new releases ?




Just for comparison, here is how long it took on my machine (yum and
root cache fully updated, no ccache):

F-17 x86_64:  38 minutes 0 seconds
F-18 x86_64:  40 minutes 58 seconds
devel x86_64: 44 minutes 51 seconds

So, it seems there is nothing that much different cpu-time-wise. I asked
on the devel ML how to get some memory usage stats, will report back
once I have them.



Hi,
mame-0_147u4-1

build in less of 130 minutes in all branches F19, F18, F17 and F16 .

this is problem is fixed ? if yes let close the bug
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2554


Thanks,

It's not fixed, it's worked around. I had to disable dwz [1] to make it 
work. The bug should stay open until the builder gets enough memory so 
that it is not needed any more IMO.


Regards,
Julian

[1] http://fedoraproject.org/wiki/Features/DwarfCompressor

Re: x264 soname bump on rawhide

[Julian Sikorski]

W dniu 23.11.2012 22:04, Sérgio Basto pisze:
 On Sex, 2012-11-23 at 09:52 +0100, Nicolas Chauvet wrote: 
 2012/11/23 Julian Sikorski beleg...@gmail.com
 W dniu 22.11.2012 18:16, Sérgio Basto pisze: 
  Hi,
  in rawhide x264 soname change from .125 to .128
 
  repoquery --releasever=18 x264-libs --whatrequires --source
 | sort -u
  avidemux-2.5.6-9.fc18.src.rpm
  ffmpeg-0.11.2-1.fc18.src.rpm
  ffmpeg-compat-0.6.6-3.fc18.src.rpm
  gstreamer1-plugins-ugly-1.0.2-1.fc18.src.rpm
  gstreamer-plugins-ugly-0.10.19-4.fc18.src.rpm
  libquicktime-1.2.4-3.fc18.src.rpm
  mplayer-1.1-2.fc18.src.rpm
  mythtv-0.25.2-3.fc18.src.rpm
  vlc-2.0.4-1.fc18.src.rpm
 
  so we need rebuild on rawhide avidemux, ffmpeg ,
  ffmpeg-compat,
  gstreamer1-plugins-ugly, gstreamer-plugins-ugly,
 libquicktime,
  mplayer,  mythtv and vlc .
 
  Sorry for any inconvenience ,
 
  Btw and push it to F18 with ffmpeg-1.0 ?
 
  Thanks,
 
 
 +1 from me, and IIRC Nicolas was fine with it too (the ffmpeg
 part at
 least).


 Yep, I'm good with having ffmpeg/x264 updated by this week-end.
 You can start right now.
 
 OK, I'm going put x264 .128 in F18 with bootstrap , after build
 ffmpeg-1.0 we will need rebuild x264 ( unboostrap ) . 
 
 Thanks,
 
ffmpeg build has been started.

Julian

Re: x264 soname bump on rawhide

[Julian Sikorski]

W dniu 22.11.2012 18:16, Sérgio Basto pisze:
 Hi,
 in rawhide x264 soname change from .125 to .128  
 
 repoquery --releasever=18 x264-libs --whatrequires --source | sort -u
 avidemux-2.5.6-9.fc18.src.rpm
 ffmpeg-0.11.2-1.fc18.src.rpm
 ffmpeg-compat-0.6.6-3.fc18.src.rpm
 gstreamer1-plugins-ugly-1.0.2-1.fc18.src.rpm
 gstreamer-plugins-ugly-0.10.19-4.fc18.src.rpm
 libquicktime-1.2.4-3.fc18.src.rpm
 mplayer-1.1-2.fc18.src.rpm
 mythtv-0.25.2-3.fc18.src.rpm
 vlc-2.0.4-1.fc18.src.rpm
 
 so we need rebuild on rawhide avidemux, ffmpeg ,  ffmpeg-compat,
 gstreamer1-plugins-ugly, gstreamer-plugins-ugly, libquicktime, 
 mplayer,  mythtv and vlc .
 
 Sorry for any inconvenience ,
 
 Btw and push it to F18 with ffmpeg-1.0 ? 
 
 Thanks, 
 
+1 from me, and IIRC Nicolas was fine with it too (the ffmpeg part at
least).

Julian

Re: x264 soname bump on rawhide

[Julian Sikorski]

W dniu 23.11.2012 01:21, Sérgio Basto pisze:
 On Sex, 2012-11-23 at 00:39 +0100, Julian Sikorski wrote: 
 W dniu 22.11.2012 18:16, Sérgio Basto pisze:
 Hi,
 in rawhide x264 soname change from .125 to .128  

 repoquery --releasever=18 x264-libs --whatrequires --source | sort -u
 avidemux-2.5.6-9.fc18.src.rpm
 ffmpeg-0.11.2-1.fc18.src.rpm
 ffmpeg-compat-0.6.6-3.fc18.src.rpm
 gstreamer1-plugins-ugly-1.0.2-1.fc18.src.rpm
 gstreamer-plugins-ugly-0.10.19-4.fc18.src.rpm
 libquicktime-1.2.4-3.fc18.src.rpm
 mplayer-1.1-2.fc18.src.rpm
 mythtv-0.25.2-3.fc18.src.rpm
 vlc-2.0.4-1.fc18.src.rpm

 so we need rebuild on rawhide avidemux, ffmpeg ,  ffmpeg-compat,
 gstreamer1-plugins-ugly, gstreamer-plugins-ugly, libquicktime, 
 mplayer,  mythtv and vlc .

 Sorry for any inconvenience ,

 Btw and push it to F18 with ffmpeg-1.0 ? 

 Thanks, 

 +1 from me, and IIRC Nicolas was fine with it too (the ffmpeg part at
 least).
 
 Julian, please begin with rebuild ffmpeg on rawhide 
 
 Thanks, 
 
Done.

Julian

Re: buildsystem mame

[Julian Sikorski]

W dniu 08.11.2012 21:43, Sérgio Basto pisze:
 On Dom, 2012-10-28 at 16:42 +, Sérgio Basto wrote: 
 On Dom, 2012-10-28 at 07:38 +0100, Julian Sikorski wrote:


 It built, but the process took 600 minutes. This is still a bit slow
 IMO. I'll just build the missing mame-0.147 for F-18 and hold on with
 u-releases until we get more memory for the buildsys.


 14860 (mame): Build on target fedora-18-rpmfusion_nonfree succeeded.


 i686: builder1.rpmfusion.org Status:  done/done Build Time:  85 minutes
 x86_64: builder1.rpmfusion.org Status:  done/done Build Time:  210
 minutes

 My bet is a problem only with rawhide (F19) build system. 

 http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_nonfree/14859-mame-0.147u1-2.fc19/i686/root.log
 we can see in this link that we have lots of Cannot allocate memory ,
 while on F18 we don't have . 

 I remember see a failed build log with VirtualBox on F19 like Memory
 exhausted , but never in F18
 
 Comparing building mame-0_147u2 on F16, F17 , F18 and Rawhide 
 
 http://buildsys.rpmfusion.org/build-status/job.psp?uid=14967 
 
 http://buildsys.rpmfusion.org/build-status/job.psp?uid=14966
 
 http://buildsys.rpmfusion.org/build-status/job.psp?uid=14976
 
 http://buildsys.rpmfusion.org/build-status/job.psp?uid=14907
 
 F16 Build Time =~ 96 minutes
 F17 Build Time =~ 107 minutes
 but F18 Build Time =~ 1250 minutes !?!
 and F19 Build Time =~ 676 minutes
 
 So my guess was totally wrong , So what is the the problem ?  is from
 new releases ? 
 
 
 
Just for comparison, here is how long it took on my machine (yum and
root cache fully updated, no ccache):

F-17 x86_64:  38 minutes 0 seconds
F-18 x86_64:  40 minutes 58 seconds
devel x86_64: 44 minutes 51 seconds

So, it seems there is nothing that much different cpu-time-wise. I asked
on the devel ML how to get some memory usage stats, will report back
once I have them.

Julian

Re: ffmpeg 1.0

[Julian Sikorski]

W dniu 01.11.2012 23:18, Nicolas Chauvet pisze:
 2012/10/31 Julian Sikorski
 beleg...@gmail.com
 mailto:beleg...@gmail.com
 
 W dniu 20.10.2012 20:53, Julian Sikorski pisze:
  W dniu 04.10.2012 19 tel:04.10.2012%2019:04, Julian Sikorski pisze:
  Hi,
 
  ffmpeg 1.0 was released a few days ago. It is definitely suited for
  devel. I'll prepare a build soon-ish, and then we can see if the
 fallout
  is small enough to warrant trying to squeeze it into F-18.
 
  Regards,
  Julian
 
  OK, it's been long enough :) I have submitted a ffmpeg-1.0 build,
 and a
  compatible mplayer build will be submitted later.
 
  Julian
 
 How bad is the fallout? What are the opinions on pushing this to
 F-18 too?
 
 
 I'm fine with having this version on F-18. But given that there is an
 ABI change, there is a need to re-create the current list of rebuilt.
 
 BTW, I've made a little update on the ffmpeg spec related to current
 sources.
 The most notable change is to rely on the builtin rmtp implementation.
 
 Thx
 
 
Here is the updated list for rawhide: 8 failures, 22 successes.

Rebuilt successfully:
k3b-extras-freeworld-2.0.2-8.fc19
ffmpeg2theora-0.29-1.fc19
guvcview-1.6.1-1.fc19
mpd-0.16.8-5.fc19
dvbcut-0.6.1-7.svn179.fc19
bombono-dvd-1.2.0-7.20120615gitcdab110.fc19
audacious-plugins-freeworld-3.3.2-1.fc19
miro-5.0.4-1.fc19
chromaprint-tools-0.7-2.fc19
gpac-0.5.0-1.fc19
bino-1.4.1-1.fc19
libquicktime-1.2.4-3.fc19
x264-0.125-5.20121006git68dfb7b.fc19
qmmp-plugins-freeworld-0.6.3-1.fc19
xine-lib-extras-freeworld-1.1.21-3.fc19
mplayer-1.1-3.20121008svn.fc19
alsa-plugins-freeworld-1.0.26-1.fc19
xbmc-12.0-0.1.Frodo_alpha6.fc19
ffmpegthumbnailer-2.0.8-1.fc19
dvdstyler-2.3-1.fc19
wxsvg-1.1.9-1.fc19
lightspark-0.7.0-1.fc19

Failed:
acoustid-fingerprinter-0.5.1-6.fc19
kmediafactory-0.8.1-3.fc19
vlc-2.0.4-1.fc19
minidlna-1.0.25-1.fc19
motion-3.3.0-trunkREV534.fc19.3
vbam-1.8.0.1097-2.fc19
kdemultimedia-extras-freeworld-4.7.2-5.fc19
mlt-0.8.0-2.fc19

Out of those, kmediafactory, minidlna and motion fail due to glibc, vlc
due to kernel, and kdemultimedia-extras-freeworld should be retired [1].
So it seems we have only 3 genuine ffmpeg-related failures. Looks good
to me :)

Julian

[1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=2561

Re: ffmpeg 1.0

[Julian Sikorski]

W dniu 03.11.2012 19:01, Andrea Musuruane pisze:
 On Sat, Nov 3, 2012 at 10:38 AM, Julian Sikorski beleg...@gmail.com wrote:
 Out of those, kmediafactory, minidlna and motion fail due to glibc, vlc
 due to kernel, and kdemultimedia-extras-freeworld should be retired [1].
 So it seems we have only 3 genuine ffmpeg-related failures. Looks good
 to me :)
 
 The minidlna issue has been already reported upstream and it is
 related to ffmpeg 1.0:
 http://sourceforge.net/tracker/?func=detailaid=3577137group_id=243163atid=1121516
 
 Archlinux has a made a rather ugly but effective workaround:
 https://projects.archlinux.org/svntogit/community.git/commit/trunk/PKGBUILD?h=packages/minidlnaid=28a9dbed703e5242d8419567171ba61e52fe4fa4
 
 I didn't like it very much. After googling a bit more, I found out the
 following patch:
 http://inmmc.org/ftp/soft/minidlna.diff
 
 I will commit an updated version of minidlna based on it soon.
 
 Bye,
 
 Andrea.
 
Good catch. In that case, motion and kmediafactory are actually failing
because of ffmpeg as well.

Julian

builder1.rpmfusion.org has 1 thread blocked by something

[Julian Sikorski]

Hi,

in my futile attempts to build mame-0.147u2 I have noticed that
something is blocking 1 out of 4 builder1.rpmfusion.org threads. If that
is not an artifact, maybe it is eating memory mame build needs so badly?
Could someone please have a look?

Regards,
Julian

Re: buildsystem mame

[Julian Sikorski]

W dniu 29.10.2012 07:14, Julian Sikorski pisze:
 W dniu 29.10.2012 00:54, Sérgio Basto pisze:
 On Dom, 2012-10-28 at 21:42 +0100, Julian Sikorski wrote:
 Keep in mind that it was 0.147u1 which was built for rawhide, and
 0.147
 for F-18. 

 You haven't test 0.147u1 or other than 0.147 on F-18 builder
 http://buildsys.rpmfusion.org/logs/fedora-18-rpmfusion_nonfree/ .

 I don't understand if you are saying that 0.147u1 have a specific
 problem that makes memory exhausted, that 0.147 doesn't ? 
 
 I am not saying that, I am saying that we are not comparing the same
 thing here, so we should be cautious when drawing conclusions.
 

 If not, what bigger test build 0.147u1 to F-18 to see if just take about
 190 minutes.
 
 I will do it once mame-0.147 gets pushed to F-18 stable. It got missed
 before which leads to dependency problems.
 

 Other suggestion is limit the builder to build one package each time. 

 Thanks and best regards, 

 
 Regards,
 Julian
 
I filed this into bugzilla:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2554

Julian

Re: buildsystem mame

[Julian Sikorski]

W dniu 29.10.2012 00:54, Sérgio Basto pisze:
 On Dom, 2012-10-28 at 21:42 +0100, Julian Sikorski wrote:
 Keep in mind that it was 0.147u1 which was built for rawhide, and
 0.147
 for F-18. 
 
 You haven't test 0.147u1 or other than 0.147 on F-18 builder
 http://buildsys.rpmfusion.org/logs/fedora-18-rpmfusion_nonfree/ .
 
 I don't understand if you are saying that 0.147u1 have a specific
 problem that makes memory exhausted, that 0.147 doesn't ? 

I am not saying that, I am saying that we are not comparing the same
thing here, so we should be cautious when drawing conclusions.

 
 If not, what bigger test build 0.147u1 to F-18 to see if just take about
 190 minutes.

I will do it once mame-0.147 gets pushed to F-18 stable. It got missed
before which leads to dependency problems.

 
 Other suggestion is limit the builder to build one package each time. 
 
 Thanks and best regards, 
 

Regards,
Julian

Re: buildsystem mame

[Julian Sikorski]

W dniu 27.10.2012 21:21, Julian Sikorski pisze:
 W dniu 27.10.2012 12:52, Dan Horák pisze:
 Dan Horák píše v So 27. 10. 2012 v 12:48 +0200: 
 Nicolas Chauvet píše v So 27. 10. 2012 v 12:40 +0200: 
 Yesterday.
 Le 27 oct. 2012 10:43, Julian Sikorski 
 belegdol-re5jqeeqqe8avxtiumwx3w-xmd5yjdbdmrexy1tmh2...@public.gmane.org 
 a écrit :

 W dniu 11.10.2012 07:28, Julian Sikorski pisze:
 W dniu 11.10.2012 00:27, Nicolas Chauvet pisze:
 2012/10/10 Julian Sikorski 
 belegdol-Re5JQEeQqe8AvxtiuMwx3w-XMD5yJDbdMReXY1tMh2IBg-XMD5yJDbdMSQIYZ4X/+isw-xmd5yjdbdmrexy1tmh2ibh2eb7je5...@public.gmane.org:
 W dniu 2012-10-10 12:22, Leigh Scott pisze:

 Hi Julian,


 If I could somehow force only one build at a
 time, this could help. Otherwise we might need to bump the builder
 memory - how much does it have now?
 That's the point, the builder is lacking memory, but only during link
 time of a given build.
 I've reproduced the problem on a similar builder. I will try to
 reproduce using a f18 target.

 Please do not submit any mame jobs for now.
 Thx

 Nicolas (kwizart)

 Sure, no problem. If the memory is the only issue, I can consider
 donating some. Let me know what your tests show and what type of memory
 is needed.

 Julian

 Where do we stand on this? If RPM Fusion is no longer able to supply
 up-to-date mame packages, I need to look for another solution.

 Regards,
 Julian

 Hi Julian,

 I was only able to test a f18 target
 Yesterday. And it has failed the same as f19.

 There are actions ongoing to solve this from the infra side.

 Btw. Is there a way to lower the memory usage needed at link time until the
 problem is solved ?

 the trick used in Fedora on s390/ppc/arm for some packages (webkit, ...)
 was to switch from -g to -g1 (generates less debuginfos) and use
 -Wl,--no-keep-memory -Wl,--reduce-memory-overheads
 options for the linker

 and it looks like this:

 %build
 %ifarch s390 %{arm}
 # Use linker flags to reduce memory consumption on low-mem architectures
 %global optflags %{optflags} -Wl,--no-keep-memory 
 -Wl,--reduce-memory-overheads
 %endif
 %ifarch s390
 # Decrease debuginfo verbosity to reduce memory consumption even more
 %global optflags %(echo %{optflags} | sed 's/-g/-g1/')
 %endif



  Dan

 I have now submitted a build with first of the workarounds enabled.
 Let's see if it helps.
 
 Julian
 
It built, but the process took 600 minutes. This is still a bit slow
IMO. I'll just build the missing mame-0.147 for F-18 and hold on with
u-releases until we get more memory for the buildsys.

Regards,
Julian

Re: buildsystem mame

[Julian Sikorski]

W dniu 28.10.2012 17:42, Sérgio Basto pisze:
 On Dom, 2012-10-28 at 07:38 +0100, Julian Sikorski wrote:
 
 
 It built, but the process took 600 minutes. This is still a bit slow
 IMO. I'll just build the missing mame-0.147 for F-18 and hold on with
 u-releases until we get more memory for the buildsys.
 
 
 14860 (mame): Build on target fedora-18-rpmfusion_nonfree succeeded.
 
 
 i686: builder1.rpmfusion.org Status:  done/done Build Time:  85 minutes
 x86_64: builder1.rpmfusion.org Status:  done/done Build Time:  210
 minutes
 
 My bet is a problem only with rawhide (F19) build system. 
 
 http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_nonfree/14859-mame-0.147u1-2.fc19/i686/root.log
 we can see in this link that we have lots of Cannot allocate memory ,
 while on F18 we don't have . 
 
 I remember see a failed build log with VirtualBox on F19 like Memory
 exhausted , but never in F18
 
 So I will submit new VirtaulBox release on F18 first .
 
 Best regards and thanks, 
 
Keep in mind that it was 0.147u1 which was built for rawhide, and 0.147
for F-18.

Regards,
Julian

Re: buildsystem mame

[Julian Sikorski]

W dniu 28.10.2012 21:42, Julian Sikorski pisze:
 W dniu 28.10.2012 17:42, Sérgio Basto pisze:
 On Dom, 2012-10-28 at 07:38 +0100, Julian Sikorski wrote:


 It built, but the process took 600 minutes. This is still a bit slow
 IMO. I'll just build the missing mame-0.147 for F-18 and hold on with
 u-releases until we get more memory for the buildsys.


 14860 (mame): Build on target fedora-18-rpmfusion_nonfree succeeded.


 i686: builder1.rpmfusion.org Status:  done/done Build Time:  85 minutes
 x86_64: builder1.rpmfusion.org Status:  done/done Build Time:  210
 minutes

 My bet is a problem only with rawhide (F19) build system. 

 http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_nonfree/14859-mame-0.147u1-2.fc19/i686/root.log
 we can see in this link that we have lots of Cannot allocate memory ,
 while on F18 we don't have . 

 I remember see a failed build log with VirtualBox on F19 like Memory
 exhausted , but never in F18

 So I will submit new VirtaulBox release on F18 first .

 Best regards and thanks, 

 Keep in mind that it was 0.147u1 which was built for rawhide, and 0.147
 for F-18.
 
 Regards,
 Julian
 
Moreover, these error occur during the setup stage, not during build.

Regards,
Julian

Re: buildsystem mame

[Julian Sikorski]

W dniu 11.10.2012 07:28, Julian Sikorski pisze:
 W dniu 11.10.2012 00:27, Nicolas Chauvet pisze:
 2012/10/10 Julian Sikorski 
 belegdol-re5jqeeqqe8avxtiumwx3w-xmd5yjdbdmrexy1tmh2...@public.gmane.org:
 W dniu 2012-10-10 12:22, Leigh Scott pisze:

 Hi Julian,


 If I could somehow force only one build at a
 time, this could help. Otherwise we might need to bump the builder
 memory - how much does it have now?
 That's the point, the builder is lacking memory, but only during link
 time of a given build.
 I've reproduced the problem on a similar builder. I will try to
 reproduce using a f18 target.

 Please do not submit any mame jobs for now.
 Thx

 Nicolas (kwizart)

 Sure, no problem. If the memory is the only issue, I can consider
 donating some. Let me know what your tests show and what type of memory
 is needed.
 
 Julian
 
Where do we stand on this? If RPM Fusion is no longer able to supply
up-to-date mame packages, I need to look for another solution.

Regards,
Julian

Re: buildsystem mame

[Julian Sikorski]

W dniu 27.10.2012 12:52, Dan Horák pisze:
 Dan Horák píše v So 27. 10. 2012 v 12:48 +0200: 
 Nicolas Chauvet píše v So 27. 10. 2012 v 12:40 +0200: 
 Yesterday.
 Le 27 oct. 2012 10:43, Julian Sikorski 
 belegdol-re5jqeeqqe8avxtiumw...@public.gmane.org a écrit :

 W dniu 11.10.2012 07:28, Julian Sikorski pisze:
 W dniu 11.10.2012 00:27, Nicolas Chauvet pisze:
 2012/10/10 Julian Sikorski 
 belegdol-Re5JQEeQqe8AvxtiuMwx3w-XMD5yJDbdMReXY1tMh2IBg-XMD5yJDbdMSQIYZ4X/+iSw@public.gmane.orgrg:
 W dniu 2012-10-10 12:22, Leigh Scott pisze:

 Hi Julian,


 If I could somehow force only one build at a
 time, this could help. Otherwise we might need to bump the builder
 memory - how much does it have now?
 That's the point, the builder is lacking memory, but only during link
 time of a given build.
 I've reproduced the problem on a similar builder. I will try to
 reproduce using a f18 target.

 Please do not submit any mame jobs for now.
 Thx

 Nicolas (kwizart)

 Sure, no problem. If the memory is the only issue, I can consider
 donating some. Let me know what your tests show and what type of memory
 is needed.

 Julian

 Where do we stand on this? If RPM Fusion is no longer able to supply
 up-to-date mame packages, I need to look for another solution.

 Regards,
 Julian

 Hi Julian,

 I was only able to test a f18 target
 Yesterday. And it has failed the same as f19.

 There are actions ongoing to solve this from the infra side.

 Btw. Is there a way to lower the memory usage needed at link time until the
 problem is solved ?

 the trick used in Fedora on s390/ppc/arm for some packages (webkit, ...)
 was to switch from -g to -g1 (generates less debuginfos) and use
 -Wl,--no-keep-memory -Wl,--reduce-memory-overheads
 options for the linker
 
 and it looks like this:
 
 %build
 %ifarch s390 %{arm}
 # Use linker flags to reduce memory consumption on low-mem architectures
 %global optflags %{optflags} -Wl,--no-keep-memory 
 -Wl,--reduce-memory-overheads
 %endif
 %ifarch s390
 # Decrease debuginfo verbosity to reduce memory consumption even more
 %global optflags %(echo %{optflags} | sed 's/-g/-g1/')
 %endif
 
 
 
   Dan
 
I have now submitted a build with first of the workarounds enabled.
Let's see if it helps.

Julian

Re: ffmpeg 1.0

[Julian Sikorski]

W dniu 04.10.2012 19:04, Julian Sikorski pisze:
 Hi,
 
 ffmpeg 1.0 was released a few days ago. It is definitely suited for
 devel. I'll prepare a build soon-ish, and then we can see if the fallout
 is small enough to warrant trying to squeeze it into F-18.
 
 Regards,
 Julian
 
OK, it's been long enough :) I have submitted a ffmpeg-1.0 build, and a
compatible mplayer build will be submitted later.

Julian