Re: RPM Fusion (EL - free) Package Build Report 2008-09-23

[Xavier Bachelot]

[EMAIL PROTECTED] wrote:
 
 Packages built and released for RPM Fusion (EL - free) testing/5: 4
 
...
 NEW xine-lib-extras-freeworld-1.1.15-2.el5 : Non-free extra codecs for the 
 Xine library
 
Just a note, non-free in the above summary looks wrong while the package
name uses freeworld and the sub-repo is free.

Regards,
Xavier

Re: for users...

[Xavier Bachelot]

Dominik 'Rathann' Mierzejewski wrote:
  The ... and plays DVDs. part is mostly a lie. If you only use
RPMFusion,
 you won't be able to play most DVDs.
 
Speaking on that, is there anything going on to have the missing bits
hosted in a wiser country ? I'd like to at least lurk and possibly help
with this.

Regards,
Xavier

Re: VLC fc8

[Xavier Bachelot]

rontti wrote:


Ok, that's fair, rules of the game are clear to me.  I just like so much 
of this acer modified fedora ( it's really fast, lightweight and simple 
userinterface), very suitable for a netbook.  I woudn't use that on a 
normal computer though. I'll probably continue to use it as long as it's 
compatible with fedora community goodies and don't cause much trouble.  
After that it's time to change.


Let's close this.  Thanks for all.
Regs Tarmo

We're getting off-topic here, but the way forward is to merge back the 
changes made by Linpus and then Acer to Fedora, when applicable. The 
less differences there will be between them, the easier it will be to 
use non-forked version of the packages.


Regards,
Xavier

Re: Finally want to leave infrastructure work to others from now on

[Xavier Bachelot]

 Hi!

 Subject basically says it already: I from now on plan to mostly leave
 all the hard, sometimes painful and often unnoticed and underestimated
 work in the infrastructure area (e.g. setting up and maintaining build
 master, build slaves, CVS and other machines) up to others from now on.

 I basically announced that intention over a year ago (iirc) already, so
 it hopefully shouldn't be that much of a surprise to most people on this
 list. And I'll of course stay around and help out with infra work if
 strictly needed. But I'll try to keep my head down as much as possible
 (¹) -- even if that now and then might mean it takes a little bit longer
 until things get fixed (but otherwise I'll never get rid of that work).

 Some of the reasons for this step:

 - I want to have more time to do other things in Fedora-land/RPM Fusion
 - I would like to see a real RPM Fusion Infrastructure group formed
 that is working as good as Fedora infrastructure; I feel like I'm
 partly a problem on the way to that
 - I often did/had to do infra work in a hurry in the past and sometimes
 did it not as good as it should have been done; especially when it came
 to documenting things (sorry for that)
 - I want to have a little bit more free time for myself/for real life
 - there are liekly way more reasons, but my mind doesn't come up with
 them right now


 So IOW: you main contact for things in the infrastructure area from now
 on is Xavier. He mentioned to me in private that he plans to send a mail
 about future work plans in the infra area to this list soon. Hopefully
 he and others can form a team that is as efficient and properly working
 as Fedora infrastructure is in Fedora.

 Note that I'll continue to do rel-eng work -- e.g. getting stuff into
 the build root when needed and pushing packages regularly. But I hope to
 find someone that help with that sooner or later as well in the process
 to make myself obsolete ;-)

 CU
 knurd

 (¹) I'll of course continue to take care of the ppc builder for the
 short term future, as I'm the only one that has access to it. But the
 owner of that machine indicated that he'd prefer to move the
 plague-builder to a different machine anyway. I guess that process will
 make me unnecessary there soon as well.

Hi Knurd,


First, thanks a lot for all your past, current and futur work on
Fedora/EPEL/Livna/RPM Fusion, you really deserve them.

Then, can you be a little more specific on what are the tasks and thus the
skills involved in helping with both the RPM Fusion infrastructure work
and also on the RPM Fusion for EPEL sub project. As a long time RHL/Fedora
user and less longer time Fedora and EPEL contributor, and also as a
Fedora/RHEL/CentOS sysadmin, I'm interested in both of them and would
certainly like to help, but I don't want to commit to a bigger/harder task
I would be able to cope with. I guess the workload could certainly be
shared over a team rather than exhaust a few individuals anyway.

Regards,
Xavier (yet another one ;-))

Legal opinion : partly non free graphics

[Xavier Bachelot]

Hi,

I'm reviewing a package that is a re-implementation of a proprietary
game. The code is written from scratch, but some of the artwork
(graphics) is still taken from the original game. All of the graphics
are going to be replaced but it's not finished yet. Roughly half of it
has been replaced. Would that be allowed in RPM Fusion or not ?
My feeling is the game is not acceptable until all the graphics have
been replaced, but I'd like more educated opinions. Actually, it would
then be eligible for Fedora, imo.

http://bugzilla.rpmfusion.org/show_bug.cgi?id=1024
http://pushover.sf.net

Regards,
Xavier

Re: RHEL 6 Beta

[Xavier Bachelot]

On 04/23/2010 05:40 PM, Nicolas Chauvet wrote:
 How much of the current RPM Fusion packages maintainer do want to
 support their package in EL-6 also ?

Another alternative could be to have different maintainers for the
Fedora and EL branches, if the Fedora maintainer doesn't want to take
the EL branch too, just like it's done in EPEL. That may allow more
people to participate and more packages to be maintained for the EL
branch. Not sure how much work this would add on the already very
limited workforce of the RPM Fusion infrastructure team though.

Regards,
Xavier

Re: libbluray / libaacs / libbdplus

[Xavier Bachelot]

On 07/09/2010 03:52 PM, Xavier Bachelot wrote:
 Hi,
 
 libbluray is a library to access Blu-Ray disks for video playback. It is
 licensed under the LGPL and as such should be fine for Fedora.
 
 http://www.videolan.org/developers/libbluray.html
 
 However, this will only work with blurays not protected with either AACS
 or BD+. The libraries that allow to play protected blurays are libaacs
 and libbdplus, which can be dlopen'ed by libbluray if present. These
 libraries don't provide the keys needed to allow decryption, the keys
 file needs to be fetched elsewhere. These 2 libraries are licensed under
 LGPL too. Would these 2 libraries be allowed into RPM Fusion or is this
 materials for Livna ? This is only a theoretical question for now, as
 libaacs and libbdplus are not yet public but should be soon, but I
 thought it might worth discuss that before, given the fair amount of
 discussion it took to agree on what to do with libdvdcss.
 
 Regards,
 Xavier
 
 
FYI, I submitted both libbluray and libaacs for review in Fedora.
libbluray : https://bugzilla.redhat.com/show_bug.cgi?id=625602
libaacs : https://bugzilla.redhat.com/show_bug.cgi?id=625603

Regards,
Xavier

Re: Request for update of mjpegtools

[Xavier Bachelot]

Hi,

On 09/03/2010 02:12 AM, salsaman wrote:
 Hi,
 it seems that the current mjpegtools package in rpmfusion is lacking a
 fix which is vital for encoding in LiVES:
 
The mailing list is the wrong place to report a bug, the maintainer(s)
of mjpegtools might not notice this mail, and this then will be lost. if
you want to be sure the persons in charge of this package are notified,
file a bug at http://bugzilla.rpmfusion.org.

Regards,
Xavier

Re: libbluray / libaacs / libbdplus

[Xavier Bachelot]

On 10/13/2010 09:34 PM, Jochen Schmitt wrote:
 
 Am 13.10.2010 21:25, schrieb Xavier Bachelot:
 As expected, libbluray has been accepted and libaacs has been rejected
 by Red Hat Legal team. I hope libaacs will be fine for RPM Fusion and
 I've filed a review request :
 https://bugzilla.rpmfusion.org/show_bug.cgi?id=1453
 
 Odd question: Do you need an official decryption key for using libaacs and
 if it so, where I can get this key?

This library is only an implementation of the AACS specification, and as
such, doesn't provide the keys. To allow playback of (some) commercial
BDs, you'll have to fetch these keys from the internet, the library only
is useless for this purpose. That said, this link might help :
http://forum.doom9.org/showthread.php?t=155671

Regards,
Xavier

Re: libbluray / libaacs / libbdplus

[Xavier Bachelot]

Hi,

 As expected, libbluray has been accepted and libaacs has been rejected
 by Red Hat Legal team. I hope libaacs will be fine for RPM Fusion and
 I've filed a review request :
 https://bugzilla.rpmfusion.org/show_bug.cgi?id=1453
 
 fwiw, libbluray support is currently available for mplayer, mythtv and
 vlc trunk. xine-lib is also supported through an out of tree input
 plugin (see above). I think handbrake also has support, but I'm not sure
 about this one.
 
libbluray just hits Rawhide. If videoplayers maintainers feel like
enabling bluray support, they now can.

Regards,
Xavier

Re: Problem with infrastructure.

[Xavier Bachelot]

On 01/30/2011 01:13 PM, Nicolas Chauvet wrote:
 2011/1/25 Hans de Goede j.w.r.dego...@gmail.com:
 Hi,

 On the subject of rpmfusion's infrastructure, perhaps it is a good idea to
 organize a get together of people interested in this at FOSDEM?

 You can count me in :)
 The people that will be present should register here
 https://fedoraproject.org/wiki/FOSDEM_2011
 I am one of them so we can talk about RPM Fusion, but if Xavier isn't
 here that will be difficult to have a clear schedule of what need to
 be done.
 
 The last talk we lead at FUDcon Zurich on the topic was very much
 about lacking ressources. (both human and machines).
 
I can probably devote a few hours here and there to rpmfusion admin
after some explanations/doc reading on own all the infra bits and pieces
work.
I unfortunately won't be at FOSDEM, it would have been must easier to
get started.

Regards,
Xavier (another one :-)

libdvdcss 1.2.11

[Xavier Bachelot]

Hi,

After many years, there's a new release of libdvdcss. This raises the 
question of who does maintain this package these days. I've asked ANvil 
from livna.org, but it was not clear even to him, so I thought asking 
here might bring some light. This might be a bit off topic, but Livna 
instructs to mail rpmfusion-devel anyway.


Regards,
Xavier

Re: libdvdcss 1.2.11

[Xavier Bachelot]

Salut Remi,

On 11/21/2011 06:16 PM, Remi Collet wrote:

Le 21/11/2011 17:15, Xavier Bachelot a écrit :

Hi,

After many years, there's a new release of libdvdcss. This raises the
question of who does maintain this package these days. I've asked ANvil
from livna.org, but it was not clear even to him, so I thought asking
here might bring some light. This might be a bit off topic, but Livna
instructs to mail rpmfusion-devel anyway.


Check the remi repository ;)

Yes, indeed, I've been pointed at your repo for libdvdcss already. But 
your repo provides much more than libdvdcss and most of the other stuff 
it provides is overlaping with other Fedora reporitories. Don't get me 
wrong, I know for sure you're doing a great work. My point is just that 
it's less convenient than repositories that stack up properly like 
Fedora + RPM Fusion + Livna. I'm not looking at replacing the Livna repo 
with something else, I just want to make sure there is someone to 
maintain libdvdcss in Livna (or another place with a non-replacement 
policy). If there's no maintainer currently, I'll discuss further with 
Anvil on the way forward and I'm willing to step up to be the maintainer 
if needed. Maybe you'll want to step up too :-)


Regards,
Xavier

Re: libdvdcss 1.2.11

[Xavier Bachelot]

On 11/22/2011 05:20 PM, Thorsten Leemhuis wrote:

Hi!

On 21.11.2011 22:37, Xavier Bachelot wrote:

On 11/21/2011 06:16 PM, Remi Collet wrote:

Le 21/11/2011 17:15, Xavier Bachelot a écrit :

After many years, there's a new release of libdvdcss. This raises the
question of who does maintain this package these days. I've asked ANvil
from livna.org, but it was not clear even to him, so I thought asking
here might bring some light. This might be a bit off topic, but Livna
instructs to mail rpmfusion-devel anyway.

Check the remi repository ;)

Yes, indeed, I've been pointed at your repo for libdvdcss already. But
your repo provides much more than libdvdcss and most of the other stuff
it provides is overlaping with other Fedora reporitories. Don't get me
wrong, I know for sure you're doing a great work. My point is just that
it's less convenient than repositories that stack up properly like
Fedora + RPM Fusion + Livna.


+1


I'm not looking at replacing the Livna repo
with something else, I just want to make sure there is someone to
maintain libdvdcss in Livna (or another place with a non-replacement
policy). If there's no maintainer currently, I'll discuss further with
Anvil on the way forward and I'm willing to step up to be the maintainer
if needed. Maybe you'll want to step up too :-)


I'm wondering if those involved and most active in RPM Fusion these days
should first discuss if shipping libdvdcss in RPM Fusion might be the
better solution...

The idea of suggesting to move libdvdcss into RPM Fusion crossed my 
mind, but I re-read the archived threads and refrained from doing so, at 
least for now. I'm genuinely interest in finding out who is the current 
maintainer and who can sign packages for Livna. But now you made the 
suggestion, let's discuss that too :-)


Regards,
Xavier

Re: libdvdcss 1.2.11

[Xavier Bachelot]

On 11/24/2011 04:21 PM, Julian Sikorski wrote:

The more important question is what do we really gain by moving
libdvdcss from livna. It only needs an update every few years it seems,
so does it really matter where it is housed?

Julian


I would be fine with libdvdcss in Livna, but please go back to the 
message that started this thread : we don't know who's the maintainer 
for this package and who can sign packages in Livna. Without an answer 
to this 2 questions, the conclusion might be drawn that Livna is 
actually dying and libdvdcss needs a new home. This new home might or 
might not be RPM Fusion, hence the current discussion.


Regards,
Xavier

Re: libdvdcss 1.2.11

[Xavier Bachelot]

On 11/28/2011 06:50 PM, Kevin Kofler wrote:

I wrote:

I see Remi's builds have now been put into rpm.livna.org, but why did F15
i386 get the el6 build rather than the fc15 one?


And now it has the fc16 one! :-/



It seems it's all been sorted out now, correct rpm versions are at the 
correct locations. However, I've noticed that out of all the currently 
supported distro releases, the F14 and EL5 builds are missing. Not a big 
deal for F14, but EL5 might be a nice addition.


Thanks Remi and Anvil, this is much appreciated.

Regards,
Xavier

libbluray soname bump

[Xavier Bachelot]

Hi,

libbluray has made its first official release a few days ago. The soname 
was bumped to 1.0.0 just before the release, in order to make sure it's 
incompatible with older snapshots they have produced. The snapshots I've 
made and packaged for Fedora are compatible with the release, so 
Fedora/RPM Fusion packages should be fine after a simple rebuild.


I would like to have a clean start with this library and have the 
updated package pushed to devel, but also to all currently active 
releases ( F-16, F-15 and EL-6), despite the soname breakage. Now that 
upstream is ready to push releases, I think it will be easier to keep 
the package in good shape if we follow them.


Affected packages are as follow :

For F17 and F16 :
gvfs(fedora)
mplayer (rpmfusion-free)
xbmc(rpmfusion-free)

For F15 :
mplayer (rpmfusion-free)
xbmc(rpmfusion-free)

EL-6 doesn't have any affected package.

Please let me know if you're ok with that, and I'll proceed with the 
builds and the build overrides request.


Regards,
Xavier

Re: libbluray soname bump

[Xavier Bachelot]

On 12/13/2011 06:35 PM, Nicolas Chauvet wrote:

2011/12/11 Xavier Bachelot xav...@bachelot.org
mailto:xav...@bachelot.org:
  Hi,
 
  libbluray has made its first official release a few days ago. The
soname was
  bumped to 1.0.0 just before the release, in order to make sure it's
  incompatible with older snapshots they have produced. The snapshots I've
  made and packaged for Fedora are compatible with the release, so
Fedora/RPM
  Fusion packages should be fine after a simple rebuild.
 
  I would like to have a clean start with this library and have the updated
  package pushed to devel, but also to all currently active releases (
F-16,
  F-15 and EL-6), despite the soname breakage. Now that upstream is
ready to
  push releases, I think it will be easier to keep the package in good
shape
  if we follow them.
 
  Affected packages are as follow :
 
  For F17 and F16 :
  gvfs(fedora)
  mplayer (rpmfusion-free)
  xbmc(rpmfusion-free)
 
  For F15 :
  mplayer (rpmfusion-free)
  xbmc(rpmfusion-free)
 
  EL-6 doesn't have any affected package.

Hello Xavier,


Hi Nicolas,


Vlc has gained support for libbluray with Rawhide/F-17 so I'm fine with
having it updated ASAP.
But I expect that can wait for the new snapshot.

The updated libbluray is in Rawhide, feel free to build at your 
convenience. It'll be great to have yet another media player with bluray 
support.



For older Fedora releases I'm more doubtful, is there really new
features introduced?
Can't we consider bluray users in need for a new version to move to f16?

Actually this is a bit of a special case. I've been using handmade git 
snapshot until now, and this is the first upstream release. As such I 
think it would be easier for everyone to use what upstream provides us. 
I know this is somewhat against the rule to bump soname during a release 
lifetime, but I feel it worths it.


As I'm writing this, I'm wondering how does one request aa buildroot 
override in RPM Fusion ? This will be needed to have a seamless 
transition in F16 and F15.


Regards,
Xavier

Re: libbluray soname bump

[Xavier Bachelot]

On 12/13/2011 07:44 PM, Xavier Bachelot wrote:

I'll do local builds of mplayer and xbmc to make sure nothing breaks.


mplayer needs the attached patch.
I will look at xbmc next.

Regards,
Xavier
? mplayer-1.0-0.126.20110816svn.fc17.src.rpm
? mplayer-1.0-0.127.20110816svn.fc17.src.rpm
? mplayer-1_0-0_126_20110816svn_fc17
? mplayer-1_0-0_127_20110816svn_fc17
? mplayer-export-2011-08-16
? mplayer-fix_configure_for_libbluray.patch
? mplayer.patch
Index: mplayer-new_libbluray_api.patch
===
RCS file: mplayer-new_libbluray_api.patch
diff -N mplayer-new_libbluray_api.patch
--- /dev/null	1 Jan 1970 00:00:00 -
+++ mplayer-new_libbluray_api.patch	14 Dec 2011 00:23:25 -
@@ -0,0 +1,80 @@
+Index: stream/stream_bluray.c
+===
+--- stream/stream_bluray.c	(revision 34125)
 stream/stream_bluray.c	(revision 34126)
+@@ -116,7 +116,7 @@
+ case STREAM_CTRL_GET_NUM_CHAPTERS: {
+ BLURAY_TITLE_INFO *ti;
+ 
+-ti = bd_get_title_info(b-bd, b-current_title);
++ti = bd_get_title_info(b-bd, b-current_title, b-current_angle);
+ if (!ti)
+ return STREAM_UNSUPPORTED;
+ 
+@@ -137,7 +137,7 @@
+ int64_t pos;
+ int r;
+ 
+-ti = bd_get_title_info(b-bd, b-current_title);
++ti = bd_get_title_info(b-bd, b-current_title, b-current_angle);
+ if (!ti)
+ return STREAM_UNSUPPORTED;
+ 
+@@ -156,7 +156,7 @@
+ case STREAM_CTRL_GET_NUM_ANGLES: {
+ BLURAY_TITLE_INFO *ti;
+ 
+-ti = bd_get_title_info(b-bd, b-current_title);
++ti = bd_get_title_info(b-bd, b-current_title, b-current_angle);
+ if (!ti)
+ return STREAM_UNSUPPORTED;
+ 
+@@ -175,7 +175,7 @@
+ BLURAY_TITLE_INFO *ti;
+ int angle = *((int *) arg);
+ 
+-ti = bd_get_title_info(b-bd, b-current_title);
++ti = bd_get_title_info(b-bd, b-current_title, b-current_angle);
+ if (!ti)
+ return STREAM_UNSUPPORTED;
+ 
+@@ -236,7 +236,7 @@
+ }
+ 
+ /* check for available titles on disc */
+-title_count = bd_get_titles(bd, TITLES_RELEVANT);
++title_count = bd_get_titles(bd, TITLES_RELEVANT, angle);
+ mp_msg(MSGT_IDENTIFY, MSGL_INFO, ID_BLURAY_TITLES=%d\n, title_count);
+ if (!title_count) {
+ mp_msg(MSGT_OPEN, MSGL_ERR, MSGTR_BlurayNoTitles);
+@@ -250,7 +250,7 @@
+ BLURAY_TITLE_INFO *ti;
+ int sec, msec;
+ 
+-ti = bd_get_title_info(bd, i);
++ti = bd_get_title_info(bd, i, angle);
+ if (!ti)
+ continue;
+ 
+@@ -284,7 +284,7 @@
+ID_BLURAY_CURRENT_TITLE=%d\n, title + 1);
+ 
+ /* Get current title information */
+-info = bd_get_title_info(bd, title);
++info = bd_get_title_info(bd, title, angle);
+ if (!info)
+ goto err_no_info;
+ 
+Index: configure
+===
+--- configure	(revision 34125)
 configure	(revision 34126)
+@@ -5738,7 +5738,7 @@
+ echocheck Blu-ray support
+ if test $_bluray = auto ; then
+   _bluray=no
+-  statement_check libbluray/bluray.h 'bd_get_title_info(0, 0)' -lbluray  _bluray=yes
++  statement_check libbluray/bluray.h 'bd_get_title_info(0, 0, 0)' -lbluray  _bluray=yes
+ fi
+ if test $_bluray = yes ; then
+   def_bluray='#define CONFIG_LIBBLURAY 1'
Index: mplayer.spec
===
RCS file: /cvs/free/rpms/mplayer/devel/mplayer.spec,v
retrieving revision 1.40
diff -a -u -r1.40 mplayer.spec
--- mplayer.spec	23 Sep 2011 20:54:45 -	1.40
+++ mplayer.spec	14 Dec 2011 00:23:25 -
@@ -6,7 +6,7 @@
 
 Name:   mplayer
 Version:1.0
-Release:0.126.%{pre}%{?dist}
+Release:0.127.%{pre}%{?dist}
 Summary:Movie player playing most video formats and DVDs
 
 Group:  Applications/Multimedia
@@ -32,6 +32,9 @@
 Patch14:%{name}-nodvdcss.patch
 # use system FFmpeg libraries
 Patch18:%{name}-ffmpeg.patch
+# New libbluray API (changeset 34126)
+Patch19:%{name}-new_libbluray_api.patch
+
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 BuildRequires:  SDL-devel
@@ -229,6 +232,7 @@
 %patch8 -p1 -b .manlinks
 %patch14 -p1 -b .nodvdcss
 %patch18 -p1 -b .ffmpeg
+%patch19 -p0 -b .bluray
 
 doconv() {
 iconv -f $1 -t $2 -o DOCS/man/$3/mplayer.1.utf8 DOCS/man/$3/mplayer.1  \
@@ -401,6 +405,9 @@
 %{_datadir}/mplayer/*.fp
 
 %changelog
+* Tue Dec 13 2011 Xavier Bachelot xav...@bachelot.org - 1.0-0.127.20110816svn
+- Add patch for new libbluray API.
+
 * Fri Sep 23 2011 Dominik Mierzejewski rpm at greysector.net - 1.0-0.126.20110816svn
 - 20110816 snapshot
 - drop obsolete pause crash patch

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Xavier Bachelot]

On 01/05/2012 09:13 PM, Kevin Kofler wrote:

On Thursday 05 January 2012, Michael J Gruber wrote:

I don't know anything about rpmfusion packaging and infrastructure, so
I'd be happy if someone picks up xine-ui there. In fact, xine-ui gets
most xine related abrt reports, it seems, and I always found it
difficult to decide whether those are really xine-ui or xine-lib issues.
So, xine-ui would best be put into the xine-lib maintainer's hands
anyways ;)


Well, to be honest, I'd be glad if xine-lib also got a new maintainer.
(Xavier? :-) ) As I wrote, I only really maintain xine-lib because of Kaffeine,
and I'll stop caring about xine-lib the day Kaffeine releases its MPlayer-based
code (or something else not based on xine-lib). In particular, I also really
don't want to maintain xine-ui…

I can help with xine-lib and xine-ui in RPM Fusion, but I'm not sure 
I'll be a good primary maintainer for them. I'm more of a package monkey 
than a developper. Anyway, for some reason, I still value xine-lib and 
I'd hate to see it go away, so I'll take it if nobody else step up to 
the plate. I also use xine-ui, and I could take care of it too, but I 
have the feeling it doesn't receive much upstream love...



Note that xine-lib-extras-freeworld can be merged back into xine-lib when it
moves to RPM Fusion, and the new xine-lib can Obsolete/Provide it. That'll
allow making the packaging a bit less of a wicked mess than it is now.

I'm sure having only one package for all the xine-lib bits will ease the 
life of the both the package and the repos maintainers.


Regards,
Xavier

Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs

[Xavier Bachelot]

On 06/11/2012 06:08 PM, Nicolas Chauvet wrote:
 Hi,
 
 As you may know, the libaacs package from RPM Fusion rely on openssl
 functions that have been disabled in the fedora package for some
 reason.

This is actually libgcrypt, not openssl, but this is the same issue. ECC
is possibly patent-encumbered and thus disabled in both packages.
The issue is still blocked by  Fedora Legal.

 This lead the libaacs package to be partially unuseable for it's target usage.
 
 I would like to list what would be possible workarounds for this
 issue. We likely need to build a openssl-freeworld package:
 - Build a similar package and drop a file in ld.conf.d to make it
 system wide ? (the freetype-freeworld way)
 This seems unpractical as we may produce unknown behavior and
 un-certified code path with others applications.

That was the solution I was looking at, but I've not finished up the
work yet. If this is not an acceptable solution, please let me know so I
don't resume work on it if this is doomed to be rejected.

 - Build a shared object with another SONAME so packages liked with the
 freeworld version will not conflict with package linked with the
 fedora version.
 (It will eventually be possible to relink the so to the the fedora
 SONAME manually in a second step).
 - Build the freeworld version statically.
 
 The question to sync the patch between fedora and RPM Fusion VCS is a
 big question until we move to git, so I hope that progress will be
 made in this area soon.
 If not we may experiment an openssl-freeworld to be possibily behind
 the fedora version.
 
 Any thoughts on that ?

Glad you ask the question on the list, I should have done that myself
earlier.

Regards,
Xavier

Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs

[Xavier Bachelot]

On 06/11/2012 10:56 PM, Ken Dreyer wrote:
 On Mon, Jun 11, 2012 at 12:23 PM, Richard Shaw hobbes1...@gmail.com wrote:
 Unless something other than libaacs will use the freeworld package, I
 think this is a prime example of why there needs to be exceptions to
 the rules :)

 I don't know of any formal approval mechanism here, but my vote would
 be to allow the bundled/static linking for this and just following the
 Fedora guidelines for Provides: bundled(openssl).
 
 Like Richard said, if there's no other app that uses ECC, I think this
 is the right approach.
 
libaacs is probably not the only app that would benefit from ECC
support. For example, openssh, bitcoin, some digital certificates are
using ECC... There are propably others examples, but I've not done an
extended research on the matter. And one would need to make -freeworld
version of at least openssl, libgcrypt and possibly more do have full
coverage.

Anyway, could anyone give some pointers or even spec file for bundling
and static linking ? I'd like to take a look before trying the same for
libaacs.

Regards,
Xavier

Re: libbluray/libaacs not functional?

[Xavier Bachelot]

On 09/09/2012 08:54 AM, Julian Sikorski wrote:
 I just downgraded openssl to the vanilla Fedora version and aacs
 decryption is still working, is that expected? If we only need to ship
 libgcrypt-freeworld, this would make the process much easier.

yes, only libgcrypt is needed. openssl was mentionned only by mistake
and it stick in the thread for no reason.

Regards,
Xavier

Re: No tbb-devel for EPEL 6

[Xavier Bachelot]

On 04/01/2013 09:45 PM, Richard Shaw wrote:

On Mon, Apr 1, 2013 at 2:41 PM, Dominik 'Rathann' Mierzejewski
domi...@greysector.net mailto:domi...@greysector.net wrote:

On Monday, 01 April 2013 at 16:54, Richard Shaw wrote:
  I'm still having trouble building freecad for EL-6. I can use my
local mock
  to install tbb-devel on both x86_64 and i386 configurations but
the builds
  fail on buildsys saying that tbb-devel is not available.
 
  Anyone know what's going on?

It seems to be available directly in RHEL:


ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/tbb-2.2-3.20090809.el6.src.rpm

My CentOS 6.4 box can see it in the repos as well:
$ yum list tbb-devel
Available Packages
tbb-devel.i686   2.2-3.20090809.el6 base
tbb-devel.x86_64 2.2-3.20090809.el6 base
$ cat /etc/centos-release
CentOS release 6.4 (Final


I've gotten used to transient build issues but a plague-client requeue
is usually enough to fix it, but this[1] has been a problem for over a week:

Getting requirements for freecad-0.13-1.el6.src
  -- cmake28-2.8.8-4.el6.x86_64
  -- 1:doxygen-1.6.1-6.el6.x86_64
  -- swig-1.3.40-6.el6.x86_64
  -- graphviz-2.26.0-7.el6.x86_64
  -- gcc-gfortran-4.4.6-3.el6.x86_64
  -- gettext-0.17-16.el6.x86_64
  -- dos2unix-3.1-37.el6.x86_64
  -- desktop-file-utils-0.15-9.el6.x86_64
Error: No Package found for tbb-devel

I don't know what else to do...

Richard

[1]
http://buildsys.rpmfusion.org/logs/el-6-rpmfusion_nonfree/16647-freecad-0.13-1.el6/x86_64/job.log


tbb has been introduced in RHEL 6.4, while it was in EPEL previously and 
has now been removed. Maybe the RPM Fusion builders are still pointing 
at CentOS 6.3 ?


Regards,
Xavier

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Xavier Bachelot]

%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_fb.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_none.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_opengl.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_opengl2.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_raw.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_vaapi.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_vdpau.so
%if %{have_vidix}
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_vidix.so
%endif # vidix
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_xcbshm.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_xcbxv.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_xshm.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_xv.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_xvmc.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_xxmc.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_wavpack.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_xiph.so


%files extras
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_ao_out_jack.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_decode_gdk_pixbuf.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_decode_image.so
#FIXME: %{_libdir}/xine/plugins/%{plugin_abi}/xineplug_inp_smb.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_aa.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_caca.so
%if 0%{!?_without_directfb:1}
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_directfb.so
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_xdirectfb.so
%endif # directfb
%{_libdir}/xine/plugins/%{plugin_abi}/xineplug_vo_out_sdl.so

%files devel
%doc __docs/hackersguide/*
%{_bindir}/xine-config
%{_bindir}/xine-list*
%{_datadir}/aclocal/xine.m4
%{_includedir}/xine.h
%{_includedir}/xine/
%{_libdir}/libxine.so
%{_libdir}/pkgconfig/libxine.pc
%{_mandir}/man1/xine-config.1*
%{_mandir}/man1/xine-list*.1*


%changelog
* Wed Jun 05 2013 Xavier Bachelot xav...@bachelot.org 1.2.3-1
- Update to 1.2.3.
- Merge xine-lib and xine-lib-extras-freeworld.
- Use pristine source.
- Clean up old Obsoletes/Provides.
- Clean up old conditional building.
- Clean up spec.
- Enable VDPAU support.
- Enable VAAPI support.

* Sun Jul 22 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.1.21-3.1
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild

* Sat Jul 21 2012 Kevin Kofler ke...@tigcc.ticalc.org 1.1.21-2.1
- disable libbluray support on F16, libbluray too old

* Mon Jul 16 2012 Kevin Kofler ke...@tigcc.ticalc.org 1.1.21-2
- do not remove DVD plugin, not encumbered (only uses libdvdread/libdvdnav)

* Tue Jun 12 2012 Xavier Bachelot xav...@bachelot.org 1.1.21-1
- Update to 1.1.21.
- Enable libbluray support.

* Sat Mar 10 2012 Rex Dieter rdie...@fedoraproject.org 1.1.20.1-3
- rebuild (ImageMagick)

* Sat Jan 14 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.1.20.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild

* Tue Jan 03 2012 Kevin Kofler ke...@tigcc.ticalc.org 1.1.20.1-1
- update to 1.1.20.1 (bugfix release)
- drop upstreamed link-libdvdread patch

* Sun Nov 20 2011 Kevin Kofler ke...@tigcc.ticalc.org 1.1.20-1
- update to 1.1.20 (#753758)
- use .xz tarball
- drop old conditionals
- drop ESD (esound) support on F17+ (native PulseAudio just works)
- drop autotools patch, run autogen.sh in %%prep instead
- drop unused deepbind patch
- drop xvmclib_header patch, fixed upstream
- use the system libdvdnav (and libdvdread) instead of the bundled one
- fix system libdvdnav support to also link libdvdread
- plugin ABI is now 1.30

* Fri Jul 15 2011 Kevin Kofler ke...@tigcc.ticalc.org 1.1.19-7
- rebuild for new DirectFB (1.5.0)

* Mon Feb 14 2011 Rex Dieter rdie...@fedoraproject.org 1.1.19-6
- split v4l, libv4l handling
- omit v4l(1) bits (f15+)

* Mon Feb 07 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.1.19-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild

* Mon Jan 24 2011 Rex Dieter rdie...@fedoraproject.org - 1.1.19-4
- xvmclib header changes, fixes ftbfs (#635653,#661071)

* Sun Nov 28 2010 Kevin Kofler ke...@tigcc.ticalc.org - 1.1.19-3
- rebuild for new directfb (1.4.11)

* Wed Sep 15 2010 Rex Dieter rdie...@fedoraproject.org - 1.1.19-2
- rebuild (ImageMagick)

* Sun Jul 25 2010 Rex Dieter rdie...@fedoraproject.org - 1.1.19-1
- 1.1.19

* Mon Jul 19 2010 Rex Dieter rdie...@fedoraproject.org - 1.1.18.1-3
- no directfb on arm (yet)

* Tue Jun  1 2010 Ville Skyttä ville.sky...@iki.fi - 1.1.18.1-2
- Rebuild.

* Sun Mar 07 2010 Rex Dieter rdie...@fedoraproject.org - 1.1.18.1-1
- xine-lib-1.1.18.1

* Sun Mar 07 2010 Rex Dieter rdie...@fedoraproject.org - 1.1.18-2
- rebuild (ImageMagick)

* Wed Feb 24 2010 Rex Dieter rdie...@fedoraproject.org - 1.1.18-1
- xine-lib-1.1.18, plugin-abi 1.28 (#567913)

* Sat Dec 12 2009 Rex Dieter rdie...@fedoraproject.org - 1.1.17-3
- bump flac_decoder priority (rh#301861,xine#225)

* Mon

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Xavier Bachelot]

On 06/26/2013 11:38 PM, Nicolas Chauvet wrote:
 
 2013/6/26 Xavier Bachelot xav...@bachelot.org mailto:xav...@bachelot.org
 
 Hi,
 
 ..
  (d) Move the whole thing (back) to RPM Fusion (where it originally was,
 before
   we started needing xine-lib for Amarok and Phonon, which both no 
 longer
   use it). It would go to the Free section, of course.
  My proposal is to go with (d).
 
  The following packages currently depend on xine-lib:
  * gxine
  * (k9copy – already in RPM Fusion, not affected)
  * kaffeine (my package, the reason why I maintain xine-lib in the first
 place)
  * oxine
  * xine-plugin
  * xine-ui
  These packages would have to move to RPM Fusion along with xine-lib.
 
  In Kaffeine's case, upstream is switching from xine-lib to MPlayer in
 their git
  repository, so it will likely have to move to RPM Fusion sooner or 
 later
  anyway. This means the affected packages are basically *xine*.
 
  So my plan is to retire (for my packages, resp. have the respective
 maintainer
  retire) the listed packages in Fedora for Fedora ≥ 17 and get (or have 
 the
  respective maintainer get) them into RPM Fusion Free instead. (I'd 
 take care
  of xine-lib and kaffeine myself, I hope the maintainers of the other 
 packages
  will take care of them.)
 
  Sounds good, I say go for it!
 
  Regards,
 
  Hans
 
 It's probably a bit late for F17, as F19 is almost out the door (!), but 
 I now
 have a specfile merging and cleaning the bits from Fedora and RPM Fusion 
 for
 xine-lib 1.2.3. It's also adding support for VAAPI and VDPAU. 2 patches 
 to allow
 building VAAPI got pushed upstream along the way.
 
 I'm attaching a preliminary version to this mail. It still need a bit of
 cleaning though. Given the changes involved, I think it might be a good 
 idea to
 re-review it.
 
 I would like a update bug open on our bugzilla about this (if not done 
 already)
 I would like a preliminary agreement that the fedora package will be removed.
 Specially as not alll possibilities might be done in order for xine-lib to 
 stay
 in fedora. (such as bundling a special version of libavformat or else in
 xine-lib fedora, as soon as it's not libavcodec)
 
 
Here's the bug : https://bugzilla.rpmfusion.org/show_bug.cgi?id=2857

Regards,
Xavier

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Xavier Bachelot]

Hi Kevin,

On 01/05/2012 08:56 PM, Kevin Kofler wrote:

In Kaffeine's case, upstream is switching from xine-lib to MPlayer in their git
repository, so it will likely have to move to RPM Fusion sooner or later
anyway.


I took a look at kaffeine as found in F19 yesterday, and it is still 
using xine-lib (and does rebuild fine against the xine-lib 1.2.3 rpm I 
prepared). A quick glance at upstream sources showed there are now an 
mplayer and vlc backend too, but it seems vlc is the default. iirc, 
there was also a gstreamer backend at some point, but I don't see it 
anymore. I don't know how to build another backend than the default one. 
Also, latest release is 2 years old.
Do you know more about kaffeine status and would you have any advice on 
the way forward ?


Regards,
Xavier

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Xavier Bachelot]

Hi,

On 01/05/2012 08:56 PM, Kevin Kofler wrote:

The following packages currently depend on xine-lib:
* gxine
* (k9copy – already in RPM Fusion, not affected)
* kaffeine (my package, the reason why I maintain xine-lib in the first place)
* oxine
* xine-plugin
* xine-ui
These packages would have to move to RPM Fusion along with xine-lib.


Fwiw, I've rebuilt all the above packages (but k9copy, not tested yet) 
against the xine-lib 1.2.3 rpm I prepared and all the builds succeeded. 
No runtime tests yet.


Would all the impacted maintainers be ok to move their package to RPM 
Fusion, alongside with xine-lib 1.2 ?


Regards,
Xavier

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Xavier Bachelot]

On 07/10/2013 11:57 AM, Michael J Gruber wrote:

Xavier Bachelot venit, vidit, dixit 10.07.2013 10:58:

Hi,

On 01/05/2012 08:56 PM, Kevin Kofler wrote:

The following packages currently depend on xine-lib:
* gxine
* (k9copy – already in RPM Fusion, not affected)
* kaffeine (my package, the reason why I maintain xine-lib in the first place)
* oxine
* xine-plugin
* xine-ui
These packages would have to move to RPM Fusion along with xine-lib.


Fwiw, I've rebuilt all the above packages (but k9copy, not tested yet)
against the xine-lib 1.2.3 rpm I prepared and all the builds succeeded.
No runtime tests yet.

Would all the impacted maintainers be ok to move their package to RPM
Fusion, alongside with xine-lib 1.2 ?


Yes, more than happy.

great.


I assume that packages such as xine-ui would be
subsumed in other packages then?
I'm not sure to understand what you mean here, but each package would be 
retired from Fedora and a corresponding package be created in RPM 
Fusion. The RPM Fusion maintainer can be the same person as the former 
Fedora maintainer, as a sponsored Fedora packager is entitled to be an 
RPM Fusion packager automatically. Indeed, if the Fedora packager 
doesn't want to keep maintaining his package in RPM Fusion, another 
maintainer will have to be found or else the package would have to 
unfortunately be retired, if no one steps up.



I'd pass over maintainership to the
corresponding superpackage maintainer then.

Michael


Regards,
Xavier

Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs

[Xavier Bachelot]

Hi,

On 06/11/2012 08:27 PM, Xavier Bachelot wrote:
 On 06/11/2012 06:08 PM, Nicolas Chauvet wrote:
  Hi,
  
  As you may know, the libaacs package from RPM Fusion rely on openssl
  functions that have been disabled in the fedora package for some
  reason.
 This is actually libgcrypt, not openssl, but this is the same issue. ECC
 is possibly patent-encumbered and thus disabled in both packages.
 The issue is still blocked by  Fedora Legal.
 
  This lead the libaacs package to be partially unuseable for it's target 
  usage.
  
  I would like to list what would be possible workarounds for this
  issue. We likely need to build a openssl-freeworld package:
  - Build a similar package and drop a file in ld.conf.d to make it
  system wide ? (the freetype-freeworld way)
  This seems unpractical as we may produce unknown behavior and
  un-certified code path with others applications.
 That was the solution I was looking at, but I've not finished up the
 work yet. If this is not an acceptable solution, please let me know so I
 don't resume work on it if this is doomed to be rejected.

I've finally had some time to look into this more and I now have a
libgcrypt-freeworld package build along the same tricks as freetype-freeworld.
This removes the need for pre-calculated VUKs for libaacs and thus allows much
simpler bluray reading.

spec : http://www.bachelot.org/fedora/SPECS/libgcrypt-freeworld.spec
srpm :
http://www.bachelot.org/fedora/SRPMS/libgcrypt-freeworld-1.5.2-1.fc19.1.src.rpm

I'd be glad if someone can take a look and evaluate if that's worth submitting
for review.

  - Build a shared object with another SONAME so packages liked with the
  freeworld version will not conflict with package linked with the
  fedora version.
  (It will eventually be possible to relink the so to the the fedora
  SONAME manually in a second step).
  - Build the freeworld version statically.

I've not cut the solutions above, in order to keep some context, even if this is
not what I've done.

Regards,
Xavier

Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs

[Xavier Bachelot]

Hi Richard,

On 07/19/2013 05:17 PM, Richard Shaw wrote:
 Xavier,
 
 Thanks for taking this up. I recently got a bluray drive for my desktop 
 machine
 but haven't gotten around to trying it yet...
 
It should hopefully be quite straightforward now.
yum install $PREFERRED_VIDEO_PLAYER libaacs libgcrypt-freeworld
then drop a properly filled KEYDB.cfg file in /etc/xdg/aacs.
repoquery says mplayer, vlc, xbmc and xine-lib have support for libbluray.

 Some pre-review comments:
 
 1. Are you planning to keep a minimal diff from the upstream spec?
 
 If not you can remove BuildRoot: and Group: tags.
 
Yes, I'd rather keep the spec as close as possible to Fedora's one. Less
thinking when merging changes from Fedora, lower turnaround for (security) 
updates.

 2. Shouldn't this package Require: the parent package in Fedora? (Requires:
 libgcrypt%{?_isa} = %{version}-%{release})
 
 Perhaps the release part isn't necessary...

Why ? Keep both in sync ? Once libgcrypt-freeworld is installed, the regular
libgcrypt is not really used anymore, so I'm not sure it really matters.

Regards,
Xavier

Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs

[Xavier Bachelot]

Hi,

New version, merging changes from the new Fedora release :
spec : http://www.bachelot.org/fedora/SPECS/libgcrypt-freeworld.spec
srpm :
http://www.bachelot.org/fedora/SRPMS/libgcrypt-freeworld-1.5.3-1.fc19.1.src.rpm

Shall I open a formal review ticket or does anyone think that another approach
than the override Fedora provided lib would be better ?

Regards,
Xavier

Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs

[Xavier Bachelot]

On 08/03/2013 06:00 PM, Richard Shaw wrote:
 Have you been able to set this?
 
 I installed the resultant RPM but even with the ldconf file, all programs seem
 to prefer the official libgcrypt library. In order to force it I had to 
 specify
 the freeworld library with LD_PRELOAD=/path/to/freeworld/lib
 
It works for me, without any trick involved.

Before installing libgcrypt-freeworld :
$ldd /usr/lib64/libaacs.so.0
linux-vdso.so.1 =  (0x7fffe66f)
libgcrypt.so.11 = /lib64/libgcrypt.so.11 (0x003a8340)
libdl.so.2 = /lib64/libdl.so.2 (0x00348f00)
libgpg-error.so.0 = /lib64/libgpg-error.so.0 (0x0034a760)
libpthread.so.0 = /lib64/libpthread.so.0 (0x00348f40)
libc.so.6 = /lib64/libc.so.6 (0x00348e80)
/lib64/ld-linux-x86-64.so.2 (0x00348e00)

After installing libgcrypt-freeworld :
$ ldd /usr/lib64/libaacs.so.0
linux-vdso.so.1 =  (0x7fff34f78000)
libgcrypt.so.11 = /usr/lib64/libgcrypt-freeworld/libgcrypt.so.11
(0x7fdb80dce000)
libdl.so.2 = /lib64/libdl.so.2 (0x00348f00)
libgpg-error.so.0 = /lib64/libgpg-error.so.0 (0x0034a760)
libpthread.so.0 = /lib64/libpthread.so.0 (0x00348f40)
libc.so.6 = /lib64/libc.so.6 (0x00348e80)
/lib64/ld-linux-x86-64.so.2 (0x00348e00)

Sorry for the late answer, I'm on vacation until end of next week, mostly away
from any computer.

Regards,
Xavier

Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs

[Xavier Bachelot]

On 08/08/2013 11:01 PM, Richard Shaw wrote:
 For me the problem wasn't libaacs, but the aacs_info binary which seems to
 independently link to libgcrypt. Before setting the LD_PRELOAD environment
 variable it pretty much gave up getting any information about the blu-ray 
 video,
 afterwards it still failed, but it did try.
 
 # ldd /usr/bin/aacs_info
 linux-vdso.so.1 =  (0x7fff29f5f000)
 libaacs.so.0 = /usr/lib64/libaacs.so.0 (0x003ecf80)
 libgpg-error.so.0 = /usr/lib64/libgpg-error.so.0 (0x00308660)
 libpthread.so.0 = /usr/lib64/libpthread.so.0 (0x00307020)
 libc.so.6 = /usr/lib64/libc.so.6 (0x00306fe0)
 libgcrypt.so.11 = /usr/lib64/libgcrypt.so.11 (0x003ecf40)
 libdl.so.2 = /usr/lib64/libdl.so.2 (0x00307060)
 /lib64/ld-linux-x86-64.so.2 (0x00306fa0)
 
 Richard

Probably an rpath issue with aacs_info, not an issue with libgcrypt-freeworld
itself. I'll take a look asap.

Xavier

Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs

[Xavier Bachelot]

On 08/09/2013 12:37 AM, Xavier Bachelot wrote:
 On 08/08/2013 11:01 PM, Richard Shaw wrote:
 For me the problem wasn't libaacs, but the aacs_info binary which seems to
 independently link to libgcrypt. Before setting the LD_PRELOAD environment
 variable it pretty much gave up getting any information about the blu-ray 
 video,
 afterwards it still failed, but it did try.

 # ldd /usr/bin/aacs_info
 linux-vdso.so.1 =  (0x7fff29f5f000)
 libaacs.so.0 = /usr/lib64/libaacs.so.0 (0x003ecf80)
 libgpg-error.so.0 = /usr/lib64/libgpg-error.so.0 
 (0x00308660)
 libpthread.so.0 = /usr/lib64/libpthread.so.0 (0x00307020)
 libc.so.6 = /usr/lib64/libc.so.6 (0x00306fe0)
 libgcrypt.so.11 = /usr/lib64/libgcrypt.so.11 (0x003ecf40)
 libdl.so.2 = /usr/lib64/libdl.so.2 (0x00307060)
 /lib64/ld-linux-x86-64.so.2 (0x00306fa0)

 Richard
 
 Probably an rpath issue with aacs_info, not an issue with libgcrypt-freeworld
 itself. I'll take a look asap.
 
 Xavier
 
Fixed in cvs, building now.

Xavier

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

[Xavier Bachelot]

On 08/28/2013 07:29 AM, Julian Sikorski wrote:
 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
 

Here's a patch that allows xine-lib-extras-freeworld to build.

Regards,
Xavier
--- xine-lib-1.1.21/src/combined/ffmpeg/ffmpeg_decoder.h.orig	2013-08-28 22:43:33.653572011 +0200
+++ xine-lib-1.1.21/src/combined/ffmpeg/ffmpeg_decoder.h	2013-08-28 22:44:24.087787844 +0200
@@ -35,7 +35,7 @@
 
 typedef struct ff_codec_s {
   uint32_t  type;
-  enum CodecID  id;
+  enum AVCodecID  id;
   const char   *name;
 } ff_codec_t;
 
--- xine-lib-1.1.21/src/combined/ffmpeg/ff_audio_decoder.c.orig	2013-08-28 23:07:28.399833089 +0200
+++ xine-lib-1.1.21/src/combined/ffmpeg/ff_audio_decoder.c	2013-08-28 23:09:41.375423336 +0200
@@ -47,6 +47,11 @@
 
 #define AUDIOBUFSIZE (64 * 1024)
 
+#ifndef AVCODEC_MAX_AUDIO_FRAME_SIZE
+/* from libavcodec/avcodec.h dated Dec 23 2012 */
+#define AVCODEC_MAX_AUDIO_FRAME_SIZE 192000 // 1 second of 48khz 32bit audio
+#endif
+
 typedef struct {
   audio_decoder_class_t   decoder_class;
 } ff_audio_class_t;
--- xine-lib-1.1.21/src/combined/ffmpeg/ff_video_decoder.c.orig	2013-08-28 23:30:14.261671159 +0200
+++ xine-lib-1.1.21/src/combined/ffmpeg/ff_video_decoder.c	2013-08-28 23:30:55.725849741 +0200
@@ -1055,7 +1055,7 @@
 this-bih.biWidth  = _X_BE_16(this-buf[12]);
 this-bih.biHeight = _X_BE_16(this-buf[14]);
 
-this-context-sub_id = _X_BE_32(this-buf[30]);
+/*this-context-sub_id = _X_BE_32(this-buf[30]); */
 
 this-context-slice_offset = calloc(SLICE_OFFSET_SIZE, sizeof(int));
 this-slice_offset_size = SLICE_OFFSET_SIZE;

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

[Xavier Bachelot]

On 08/29/2013 12:14 AM, Nicolas Chauvet wrote:

Yep but BTW what to do with xine-lib 1.2 ?


I've not tried to rebuild and thus neither to possibly fix xine-lib 1.2 
if needed. I'll take a look.



Is it possible to bundle the libav.. .so into the fedora build and add a
xine-lib-extras with ffmpeg enabled ?
I don't know and adding more tricks to the already complex packaging of 
xine-lib and xine-lib-extras-freeworld is not really appealing to me.



Or we don't care and move it into RPM Fusion ?


My option of choice is to fully move xine-lib 1.2 to RPM Fusion, 
together with all depending packages. This will remove the overhead of 
maintaining xine-lib in Fedora and xine-lib-extras-freeworld into RPM 
Fusion. Maintainers of depending packages seem ok with moving to RPM 
Fusion, with the only drawback that they'll need to learn another 
maintenance process (I sent a mail asking about the modernization of 
the RPM Fusion build infra to be more closely matched to Fedora's, but 
did not get an answer [1]).

I have opened a review bug for xine-lib 1.2 [2].
What's not clear to me is if the depending packages that will be moved 
from Fedora need a re-review or not. See [3].



I prefer to have xine-lib removed if there is no forseable solution.


It would be a shame to loose xine-lib. Let's make it not happen :-)


Thx for the patch! BTW (I can set you the ACL by this week-end if you
make an ACL request into our bugzilla).


Ok, will do.

Regards,
Xavier

[1] 
https://lists.rpmfusion.org/pipermail/rpmfusion-developers/2013-July/015250.html

[2] https://bugzilla.rpmfusion.org/show_bug.cgi?id=2857
[3] 
https://lists.rpmfusion.org/pipermail/rpmfusion-developers/2013-July/015245.html

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

[Xavier Bachelot]

On 08/29/2013 11:16 AM, Xavier Bachelot wrote:
 On 08/29/2013 12:14 AM, Nicolas Chauvet wrote:
 Yep but BTW what to do with xine-lib 1.2 ?
 
 I've not tried to rebuild and thus neither to possibly fix xine-lib 1.2 if
 needed. I'll take a look.

fwiw, xine-lib-1.2.3 builds unpatched against ffmpeg 2.0.

Regards,
Xavier

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Xavier Bachelot]

Hi maintainers,

On 01/05/2012 08:56 PM, Kevin Kofler wrote:
 (d) Move the whole thing (back) to RPM Fusion (where it originally was, before
 we started needing xine-lib for Amarok and Phonon, which both no longer
 use it). It would go to the Free section, of course.
 My proposal is to go with (d).
 
 The following packages currently depend on xine-lib:
 * gxine
 * (k9copy – already in RPM Fusion, not affected)
 * kaffeine (my package, the reason why I maintain xine-lib in the first place)
 * oxine
 * xine-plugin
 * xine-ui
 These packages would have to move to RPM Fusion along with xine-lib.

xine-lib 1.2 package review is now done and it will soon be imported into RPM
Fusion and the Fedora package will be retired from F20 and Rawhide.
Consequently, the above packages will need to be imported into RPM Fusion and
retired from Fedora 20 and Rawhide as well.

The packages won't need a re-review to be imported, so you'll just need to
request an RPM Fusion account if you don't have one. Please note all sponsored
Fedora packagers are automatically granted packagers privileges in RPM Fusion.
I'll take care of filing the SCM requests and doing the initial builds, just
provide me with your RPM Fusion username.
See http://rpmfusion.org/Contributors for the account request.

I have requested commit rights for Fedora 20 and devel branches of the packages,
thus, if you wish so, I'll be able to take care of retiring them once everything
is in RPM Fusion.

Also, for those that are not comfortable with taming a different build system,
RPM Fusion is expected to switch to koji+git before F20 final, so fear not :-)

Regards,
Xavier

Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs

[Xavier Bachelot]

On 07/31/2013 11:21 PM, Xavier Bachelot wrote:

Hi,

New version, merging changes from the new Fedora release :
spec : http://www.bachelot.org/fedora/SPECS/libgcrypt-freeworld.spec
srpm :
http://www.bachelot.org/fedora/SRPMS/libgcrypt-freeworld-1.5.3-1.fc19.1.src.rpm

Shall I open a formal review ticket or does anyone think that another approach
than the override Fedora provided lib would be better ?

Regards,
Xavier


ECC seems to be allowed in Fedora now.
I've filled a bug against libgcrypt requesting to enable it :
https://bugzilla.redhat.com/show_bug.cgi?id=1019126

Once this is done, the libgcrypt-freeworld will become useless.

Regards,
Xavier

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Xavier Bachelot]

On 10/14/2013 10:27 AM, Michael J Gruber wrote:


I'm in rpmfusion's fas, bz and devel-ml now, applied for cvs. [BTW:
self-signed cert on fas makes me feel a bit uneasy.]


Thanks Michael (and Kevin, who replied off-list, too).

Every current (co-)maintainer but Martin have an RPM Fusion account now.
Martin, I'm waiting on your account creation in RPM Fusion to request 
CVS modules for gxine and xine-plugin, all others modules are created.



I'll be more than happy to leave the lead to you in all things xine-ui,
whether on the fedora or the rpmfusion side.

I've the feeling that together with moving xine-lib back to RPM Fusion, 
I'm somewhat signing to be the maintainer for all the dependant packages 
as well. I'm not sure I'll be able to give them all the love they need, 
especially as I'm not using all of them, thus I'm more than happy to 
have co-maintainers.


Also, I've requested commit rights to all the Fedora packages to be able 
to retire them, so if you want me to handle that, please make sure to 
grant me permission on them. So far I have only xine-lib, kaffeine and 
oxine. Missing are xine-ui, gxine and xine-plugin.


Regards,
Xavier

Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs

[Xavier Bachelot]

On 10/15/2013 10:13 AM, Xavier Bachelot wrote:

ECC seems to be allowed in Fedora now.
I've filled a bug against libgcrypt requesting to enable it :
https://bugzilla.redhat.com/show_bug.cgi?id=1019126

Once this is done, the libgcrypt-freeworld will become useless.


ECC-enabled libgcrypt is now available in Koji :
https://admin.fedoraproject.org/updates/libgcrypt-1.5.3-2.fc19
https://admin.fedoraproject.org/updates/libgcrypt-1.5.3-2.fc20

Not tested yet, I will test and give karma this evening.

Make sure to remove libgcrypt-freeworld if you have it installed or at 
least comment out /etc/ld.so.conf.d/libgcrypt-freeworld-*.conf and run 
ldconfig before testing.


Regards,
Xavier

Re: [RPM Fusion] Issue with fedora's openssl package for libbluray/libaacs

[Xavier Bachelot]

On 10/22/2013 11:27 AM, Xavier Bachelot wrote:

On 10/15/2013 10:13 AM, Xavier Bachelot wrote:

ECC seems to be allowed in Fedora now.
I've filled a bug against libgcrypt requesting to enable it :
https://bugzilla.redhat.com/show_bug.cgi?id=1019126

Once this is done, the libgcrypt-freeworld will become useless.


ECC-enabled libgcrypt is now available in Koji :
https://admin.fedoraproject.org/updates/libgcrypt-1.5.3-2.fc19
https://admin.fedoraproject.org/updates/libgcrypt-1.5.3-2.fc20

Not tested yet, I will test and give karma this evening.


Tested OK and karma given.
A major roadblock has been removed, enjoy :-)

Xavier

Re: Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Xavier Bachelot]

Hi,

On 10/13/2013 11:36 AM, Xavier Bachelot wrote:

Hi maintainers,

On 01/05/2012 08:56 PM, Kevin Kofler wrote:

(d) Move the whole thing (back) to RPM Fusion (where it originally was, before
 we started needing xine-lib for Amarok and Phonon, which both no longer
 use it). It would go to the Free section, of course.
My proposal is to go with (d).

The following packages currently depend on xine-lib:
* gxine
* (k9copy – already in RPM Fusion, not affected)
* kaffeine (my package, the reason why I maintain xine-lib in the first place)
* oxine
* xine-plugin
* xine-ui
These packages would have to move to RPM Fusion along with xine-lib.


xine-lib 1.2 package review is now done and it will soon be imported into RPM
Fusion and the Fedora package will be retired from F20 and Rawhide.
Consequently, the above packages will need to be imported into RPM Fusion and
retired from Fedora 20 and Rawhide as well.

The packages won't need a re-review to be imported, so you'll just need to
request an RPM Fusion account if you don't have one. Please note all sponsored
Fedora packagers are automatically granted packagers privileges in RPM Fusion.
I'll take care of filing the SCM requests and doing the initial builds, just
provide me with your RPM Fusion username.
See http://rpmfusion.org/Contributors for the account request.

I have requested commit rights for Fedora 20 and devel branches of the packages,
thus, if you wish so, I'll be able to take care of retiring them once everything
is in RPM Fusion.

Also, for those that are not comfortable with taming a different build system,
RPM Fusion is expected to switch to koji+git before F20 final, so fear not :-)

Regards,
Xavier

All packages have been imported, rebuilt and pushed to RPM Fusion Fedora 20 free 
repository.

The packages have been dead.package'ed in Fedora' GIT for f20 and master 
branches.

The next remaining task is to retire the packages in the pkgdb. Unfortunately, 
commit rights are not enough to be able to do that, so I've requested 
approveacls rights. Either grant me this right or retire the packages on your 
own. If you retire the packages, make sure to do f20 first, then devel.

See 
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Package_DB

I'll take care of comps, spins and upstream release monitoring next.

Thanks to everyone involved, we are really close now.

Regards,
Xavier

Re: wl-kmod for F-18

[Xavier Bachelot]

Nicolas Viéville nicolas.vievi...@univ-valenciennes.fr a écrit :
 According to the situation in this case the only alternative
I have is to submit a new job (that I can re-submit eventually if
needed), but the counter part is to bump the minor release version
number, even if the package was not not modified (here it's just a
build
problem). I just wanted some clarification about this: is it OK to
proceed this manner or bumping the minor release version number is
reserved for other types of actions?

Yes, it's OK to bump the release in this case, if you don't want to wait for 
the original submitter to resubmit.
There is no other hard rule on the release tag than to keep it higher in the 
latest branches than in the earliers.

Regards,
Xavier

Re: comps-devel update needed for xine-lib 1.2

[Xavier Bachelot]

On 11/13/2013 06:33 AM, Rex Dieter wrote:
 On 11/12/2013 06:29 PM, Kevin Kofler wrote:
 Hi,

 I filed:
 https://bugzilla.rpmfusion.org/show_bug.cgi?id=3003
 over 2 weeks ago. It still hasn't got any attention. Can somebody please
 take care of the required comps-devel.xml.in updates?
 
 done.
 
 -- rex

Oops, sorry about that, I overlooked the RPM Fusion part. I should have
taken care of adding these to RPM Fusion comps at the same time I
removed them from Fedora comps.

Regards,
Xavier

Re: repoview not being updated

[Xavier Bachelot]

On 11/26/2013 08:21 AM, Hans de Goede wrote:

Hi all,

Can one of the admins please fix repoview updating, currently it is
not being updated, ie:
http://download1.rpmfusion.org/free/fedora/development/rawhide/x86_64/os/repoview/gstreamer1-libav.html


Points to the quite old 1.1.3, rather then the less old 1.2.0, or the
recent 1.2.1

Regards,

Hans


Hi,

Already filed in bugzilla :
https://bugzilla.rpmfusion.org/show_bug.cgi?id=3032

Regards,
Xavier

Re: Packaging 3-rd party repositories in rpmfusion

[Xavier Bachelot]

On 02/03/2014 10:52 AM, Hans de Goede wrote:

Hi,

On 02/03/2014 02:14 AM, Ralf Corsepius wrote:

[2nd attempt to answer to this. My initial response from quite a while
age seems to have gone lost.]

On 01/29/2014 12:12 PM, Alec Leamas wrote:

Formally, this is about review request 3152 for dropbox-repo [1]. From
a more practical POV, it's about users being able to install software
like dropbox more or less out of the box, an area where I think we
really need to improve (as can be seen in all those Fedora XX post
installation guide out there).

My basic understanding is that current Fedora guidelines needs a
interpretation in the rpmfusion context. Those brand new GL for 3-rd
party repos are in [2] (discussions in [3]). For now, I think they can
be abridged to:
- Non-free repos can not be part of Fedora yum configuration.
- In some cases free repos can be part of the configuration after
FESCO/Fedora legal approval.

Now, IMHO this doesn't really make much sense for rpmfusion for three
reasons:
- rpmfusion does not ban non-free software, it's one of the very
reasons it exists.
- FESCO/Fedora legal cannot approve anything in rpmfusion.
- We already have a list of endorsed 3-rd party repos [4].

To handle this, my simple proposal is that we handles packaged yum
repositories like this:
- It's ok to package yum repositories listed in [4].
- If anyone wants to change the list in [4] this should be announced
here on rpmfusion-devel, and not done until we agree on it (similar to
how we handle bundling exceptions).

Thoughts. out there?


All in all, I am not OK with rpmfusion shipping other party's repos,
because such repos are out of Fedora's/Rpmfusion's control/influence.

They open up an arbitrary amount of opportunities for these 3rd
parties to break, corrupt and damage Fedora installations (Package
conflicts, low quality packages, malware, spyware,
intruded/dead/broken 3rd party servers, etc), without Fedora/RPMfusion
being able to do anything against it.

In other words, I'd recommend not doing so, because you guys are
likely to be facing very tough times in cases something goes wrong
with these endorsed 3rd party repos.


+1

Regards,

Hans


I'm in agreement with Ralf too.
imho, one of the biggest selling point for repositories like RPM 
Fusion is the insurance the Fedora packaging guidelines are enforced and 
thus the packages will integrate properly with the remaining of the 
ecosystem. Some other repositories, including some that are proposed for 
integration in RPM Fusion, are well known for theit low quality 
packaging, hence the need for smart tricks like lpf. I think this bears 
a high risk to backfire on unsuspecting users, and from my 
understanding, providing more lpf packages is probably a better 
solution, even if the maintenance cost is indeed higher.


Regards,
Xavier

Re: Packaging 3-rd party repositories in rpmfusion

[Xavier Bachelot]

On 02/03/2014 11:04 PM, Alec Leamas wrote:

On 2/3/14, Hans de Goede j.w.r.dego...@gmail.com wrote:

Hi,

On 02/03/2014 10:03 PM, Thorsten Leemhuis wrote:

Hi!

On 03.02.2014 10:52, Hans de Goede wrote:

On 02/03/2014 02:14 AM, Ralf Corsepius wrote: [...]

In other words, I'd recommend not doing so, because you guys are
likely to be facing very tough times in cases something goes
wrong with these endorsed 3rd party repos.

+1


RPM Fusion is something most Fedora users will enable, so IMHO it's
the ideal place to give users something at hand to reach software that
can't be in Fedora or RPM Fusion for various reasons â EURO  flash player
for example.


On  a sidenote, flash is already available as lpf-flash-plugin. But
that's another story.


Packages with repo files otoh might not be best way. I guess the best
way forward would be a small app that points out the risks and
explains that RPM Fusion is not responsible for content from other
repos; if the users ACks that let the app put repo file in place.

Just my 2 cent because I always wanted something like the above. Ohh,
and because my name came up recently in this discussion, as one of
those that was (is?) considered to be on the (inactive) RPM Fusion
steering committee. Might be wise to set up a new one. I'm fine if
those that are most active simply organize something and put it in
place, you have my blessing. If that's not enough: if you want a
official vote or something else from me just let me know when and
where to give what's needed ;-)


+1 to all of the above, I too am fine with some app to enable
additional repos or some such, I just don't like any form of
yum install automatically enabling new out of our control
repos.

Regards,

Hans


Hi,

+1 also from me.  I'll  update system-config-repo to handle packaged
repos in a way forcing user to confirm the actual copying to
/etc/yum.repos.d before it's done. Shouldn't be a big deal, I've had
it in mind while hacking it up.

To clarify, this means that also I agree on that some magic enabling
of an external repo just by installing a package isn't really a good
idea.

+1 for system-config-repo, user interaction is much better than silent 
enablement of repositories on package installation. I would just like a 
feature to remove all packages coming from a given repo when it is 
disabled by the user, in order not to left installed packages that will 
not receive (security) updates anymore.


Also, iirc, some repos are providing packages with known security flaws. 
While some users might need these repo/software for good or bad reasons, 
they should be warned to be extra careful. I'm thinking of AcrobatReader 
here, but there might be others.



Unless there is more input in this thread  I will  update
system-config repo and make corresponding changes to my review
request. Then  we'll see if someone has the nerves the actually do the
review :)

Thanks for all input!

Cheers,

--alec


Regards,
Xavier

Buildroot override / Retire package [was : Re: EPEL libbluray soname bump in]

[Xavier Bachelot]

On 01/04/2014 07:14 PM, Xavier Bachelot wrote:

how to request an override in RPM Fusion is not documented, so
I did not know it was even possible. If anyone feels like explaining the
process, I might add it to the wiki, to avoid other people wasting time
searching about this like I did. And while I think about it, how to
retire a package is not documented either, but I should be able to
recollect the process from memory and logs.


I did to not get any input on the buildroot override and the part on 
package retirement is probably not perfect, but I went ahead anyway and 
added the following to the wiki :

http://rpmfusion.org/Contributors?action=diffrev1=50rev2=51

Anyone that knows better is welcome to fill in the blank.

Regards,
Xavier

Re: EPEL libbluray soname bump in

[Xavier Bachelot]

On 01/04/2014 07:14 PM, Xavier Bachelot wrote:

Hi,

On 01/03/2014 10:05 PM, Orion Poplawski wrote:

I'd like to call attention to:

Setting up Upgrade Process
Resolving Dependencies
-- Running transaction check
--- Package libbluray.x86_64 0:0.2-0.6.20110710git51d7d60a96d06.el6 will be
updated
-- Processing Dependency: libbluray.so.0()(64bit) for package:
mencoder-1.0-0.140.20120205svn.el6.1.x86_64
--- Package libbluray.x86_64 0:0.5.0-2.el6 will be an update
-- Finished Dependency Resolution
Error: Package: mencoder-1.0-0.140.20120205svn.el6.1.x86_64
(@rpmfusion-free-el6-updates-testing-x86_64/6.1)
Requires: libbluray.so.0()(64bit)
Removing: libbluray-0.2-0.6.20110710git51d7d60a96d06.el6.x86_64
(@epel-6-x86_64/6.1)
libbluray.so.0()(64bit)
Updated By: libbluray-0.5.0-2.el6.x86_64 (epel-testing)
Not found

https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12460/libbluray-0.5.0-2.el6



The update has been unpushed.

The karma messages is not the right place to discuss, so let's do it here.

The only dependency for this library is mplayer from RPM Fusion. mplayer
maintainer is ok to rebuild, but RPM Fusion admin is not ok to grant a
buildroot override. I know the update is a soname bump, it was my
mistake to build an early libbluray version in EPEL, and I won't do it
again, but I don't see how plainly refusing the buildroot override
without explanation from any side is helping, especially when the
maintainer of the one and only depending package is ok to rebuild. I'm
just trying to have a maintainable and useful library in EPEL, and I'd
rather drop it than keep it this way, because it is missing a lot of
features and will break sooner or later. People will just have to wait
for RHEL 7 and clones to get it again.

In short, I don't want to maintain this old libbluray in EPEL 6 and
there's nothing I can do to avoid the temporary breakage unless RPM
Fusion admin changes his mind, so either one find a way to have it
updated then mplayer rebuilt against it, either I'll probably drop it
and other dependant packages (which will require an mplayer rebuild anyway).


What I expected to happen is now happening, libbluray in EPEL 6 is too 
old to be useful and people wanting to use it are asking for an update.


Nicolas, can you please explain why you are not willing to grant a 
buildroot override ? As already explained, I need it to be able to push 
an update and ensure the dependency breakage will be kept to a minimum 
rather than a full 15 days until the package goes from EPEL testing to 
EPEL stable (which might very well never happen if the update is shot 
down because it breaks dependency, like it already happened once), plus 
the time needed to rebuild and push mplayer in RPM Fusion.
Chicken and egg problem, if you ask me, and the override is the only way 
to ease it, especially when the involved packages are spanning over 
multiple repositories.


Also, I'd really like to document how to request a buildroot override in 
the wiki, so any explanation is welcome. I've asked several time already 
on the IRC channel and also on the mailing list.


Regards,
Xavier

Re: broken deps in rawhide

[Xavier Bachelot]

On 03/25/2014 12:24 AM, Sérgio Basto wrote:
 Hi, 
 libcdio [1] and libass [1] has bumped soname in rawhide therefore we
 have some broken deps in rawhide . 
 
 bino
 mpv
 oxine
 pcsxr
 
 please submit a rebuilt for each . 

oxine has been rebuilt.

Regards,
Xavier

Re: ffmpeg-2.2 released

[Xavier Bachelot]

On 03/25/2014 07:29 PM, Julian Sikorski wrote:
 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
 

xine-lib and lightspark have been rebuilt.

Regards,
Xavier

Re: cairo-dock dependency broken

[Xavier Bachelot]

On 06/03/2014 03:34 AM, Steve Roylance wrote:

# yum install cairo-dock-plug-ins cairo-dock
Loaded plugins: fastestmirror, priorities, versionlock
Loading mirror speeds from cached hostfile
  * fedora: mirror.aarnet.edu.au
  * rpmfusion-free: rpmfusion.mirror.uber.com.au
  * rpmfusion-free-updates: rpmfusion.mirror.uber.com.au
  * rpmfusion-nonfree: rpmfusion.mirror.uber.com.au
  * rpmfusion-nonfree-updates: rpmfusion.mirror.uber.com.au
  * updates: mirror.aarnet.edu.au
Resolving Dependencies
-- Running transaction check
--- Package cairo-dock.i686 0:3.2.1-2.fc20 will be installed
--- Package cairo-dock-plug-ins.i686 0:3.2.1-2.fc20 will be installed
-- Processing Dependency: libetpan.so.16 for package:
cairo-dock-plug-ins-3.2.1-2.fc20.i686
-- Finished Dependency Resolution
Error: Package: cairo-dock-plug-ins-3.2.1-2.fc20.i686 (rpmfusion-free)
Requires: libetpan.so.16
Available: libetpan-1.1-7.fc20.i686 (fedora)
libetpan.so.16
Installed: libetpan-1.5-1.fc20.i686 (@updates)
   ~libetpan.so.17


Please file a bug against cairo-doc at bugzilla.rpmfusion.org, it likely 
needs to be rebuilt with the newer libetpan. Or rather file a bug 
against libetpan at bugzilla.redhat.com as the update is a soname bump 
and this should not happen in regular circumstances.


Regards,
Xavier

Re: repo data rebuild

[Xavier Bachelot]

On 21/08/2014 20:40, Michael Cronenworth wrote:
 Hello,
 
 Can someone regenerate the repo data[1] for rawhide? The repo data is
 dated Aug 12th but the last push seems to be Aug 14th. This is causing
 my XBMC build to fail[2] (missing ffmpeg package).
 
 Thanks,
 Michael
 
 P.S. This mailing list either heavily delays email or drops it completely.
 
 [1]
 http://buildsys.rpmfusion.org/plague-results/fedora-development-rpmfusion_free/repodata/
 
 [2]
 http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/20896-xbmc-13.2-1.fc21/x86_64/root.log
 

Actually, I think the issue is with the rpmfusion-free-needsign-rawhide
repo, not with rpmfusion-free-rawhide. The repodatas contain references
to packages that have been moved to the regular repos already.

I'm seeing the same issue with another build :
http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/20900-xine-ui-0.99.9-1.fc21/x86_64/root.log

Regards,
Xavier

Re: repo data rebuild

[Xavier Bachelot]

On 22/08/2014 21:44, Xavier Bachelot wrote:
 On 21/08/2014 20:40, Michael Cronenworth wrote:
 Hello,

 Can someone regenerate the repo data[1] for rawhide? The repo data is
 dated Aug 12th but the last push seems to be Aug 14th. This is causing
 my XBMC build to fail[2] (missing ffmpeg package).

 Thanks,
 Michael

 P.S. This mailing list either heavily delays email or drops it completely.

 [1]
 http://buildsys.rpmfusion.org/plague-results/fedora-development-rpmfusion_free/repodata/

 [2]
 http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/20896-xbmc-13.2-1.fc21/x86_64/root.log

 
 Actually, I think the issue is with the rpmfusion-free-needsign-rawhide
 repo, not with rpmfusion-free-rawhide. The repodatas contain references
 to packages that have been moved to the regular repos already.
 
 I'm seeing the same issue with another build :
 http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/20900-xine-ui-0.99.9-1.fc21/x86_64/root.log
 
 Regards,
 Xavier
 
I've filed https://bugzilla.rpmfusion.org/show_bug.cgi?id=3344.

Regards,
Xavier

Re: repo data rebuild

[Xavier Bachelot]

On 23/08/2014 14:33, Sérgio Basto wrote:
 On Sex, 2014-08-22 at 21:44 +0200, Xavier Bachelot wrote: 
 On 21/08/2014 20:40, Michael Cronenworth wrote:
 Hello,

 Can someone regenerate the repo data[1] for rawhide? The repo data is
 dated Aug 12th but the last push seems to be Aug 14th. This is causing
 my XBMC build to fail[2] (missing ffmpeg package).

 Thanks,
 Michael

 P.S. This mailing list either heavily delays email or drops it completely.

 [1]
 http://buildsys.rpmfusion.org/plague-results/fedora-development-rpmfusion_free/repodata/

 [2]
 http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/20896-xbmc-13.2-1.fc21/x86_64/root.log


 Actually, I think the issue is with the rpmfusion-free-needsign-rawhide
 repo, not with rpmfusion-free-rawhide. The repodatas contain references
 to packages that have been moved to the regular repos already.

 I'm seeing the same issue with another build :
 http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/20900-xine-ui-0.99.9-1.fc21/x86_64/root.log
 
 
 I confirm builder try catch ffmpeg-libs-2.3.2-1.fc21.x86_64 from
 plague-results , when it is publish in  rpmfusion-free-rawhide. 
 So I simple do a new build on devel to regenerate the repo data of
 rpmfusion-free-needsign-rawhide 
 

Thanks Sérgio, it fixed the repodata and thus allowed xine-ui package to
build. And thanks too for the xbmc build.

Regards,
Xavier

Re: ffmpeg-2.4 released

[Xavier Bachelot]

On 25/09/2014 07:47, 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
 
xine-lib passed a local rebuild and is now building in plague.

Regards,
Xavier

Re: ffmpeg-2.4 released

[Xavier Bachelot]

On 26/09/2014 14:15, Sérgio Basto wrote:
 On Qui, 2014-09-25 at 21:18 +0100, Sérgio Basto wrote:
 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.

 Sorry I'm in work and can't focus, I already sent incomplete emails
 etc,
 but you NACK because ffmpeg 2.4 was submit in devel ? we can roll back
 it , it easy to roll back it. 

 I understand, how things should roll out , first commit in devel , and
 copy along branches and that is the way that should be done . So yes
 it
 was forbidden commit on devel for not roll out to branch , am I the
 coordinator ? , we can fix it, is not a big deal. I will take care of
 everything 
 Thanks, 

 I have to go now ,
 
 I'll try catch kwizart on irc this weekend to see what we can do, and
 also plan do the mass rebuild this weekend until then, I'm busy . 
 If I am the coordinator, please don't submit more builds with 
 +- rebuild (ffmpeg-2.4) and disable needsign repo , since nothing was
 yet publish, moreover is more difficult to me do the mass rebuild
 correctly because I have to track down which packages already sent it to
 rebuild. 


Ssome packages were published already :
ffmpeg
mplayer
xine-lib

Additionnaly, k3b-extras-freeworld was built earlier today but is not
pushed yet.

I'm not sure what remains to be rebuilt against ffmpeg 2.4, but at least
mplayer, xine-lib and k3b-extras-freeworld can be removed from the list.

Regards,
Xavier

Re: Livna broken

[Xavier Bachelot]

Hi kevin,

On 17/03/2015 19:29, Kevin Kofler wrote:
 rpm.livna.org has been broken for several days now. Does anybody know what's 
 up there? If Livna is not coming back, where should we get libdvdcss from 
 now?
 
No idea what's going on with Livna, but it seems more or less abandonned
for quite some time now.

You can get libdvdcss from remi repo, but be careful, it also brings
other stuff that overlap with Fedora.

Would any of the active packagers or admins object to bring libdvdcss
back into RPM Fusion ?
If not, I'll submit a review.

Regards,
Xavier

Re: State of the RPM Fusion repository for f22

[Xavier Bachelot]

On 29/04/2015 09:54, Nicolas Chauvet wrote:

Progress is been made, but there is probably some tasks that can be done
by someone else.
For example this one: https://bugzilla.rpmfusion.org/show_bug.cgi?id=3606


Patch attached to the bug.

Regards,
Xavier

Re: livna finishes at f21

[Xavier Bachelot]

On 21/06/2016 22:11, Stuart Gathman wrote:
> On 06/21/2016 03:48 PM, Mario Blättermann wrote:
>> Don't know about the reasons anymore why libdvdcss is not in
>> rpmfusion... But if you want to have it, consider to enable the repo
>> of Remi Collet:
>> http://rpms.famillecollet.com/
> 
> Probably because of this: http://www.copyright.gov/fedreg/2015/80fr65944.pdf
> 
> As I read it, it is still illegal to watch MPAA DVDs with linux in the
> US (what a lobby!)  And they could go after someone distributing
> software that enables watching MPAA DVDs.  This, of course, goes WAY
> beyond enforcing copyright to my mind, but IANAL. 
> 
RPM Fusion is not based in the US, so US laws don't apply. My
understanding is RPM Fusion servers are located in France and as such,
French laws apply.
The organization hosting the code for libdvdcss is Videolan and it is
also based in France. According to them, libdvdcss is legal in France.

http://www.videolan.org/legal.html

Based on this, I would tend to think libdvdcss could be packaged in RPM
Fusion, but IANAL either.
Maybe Videolan could provide some legal guidance on this possibility ?

In the case RPM Fusion would allow libdvdcss, I'd be happy to submit a
review, but this is probably jumping the gun at this point :-)

Regards,
Xavier

Re: please update homepage wikipage

[Xavier Bachelot]

On 21/07/2016 14:37, Xavier Bachelot wrote:


BTW about wikipage can someone edit http://rpmfusion.org/keys and
correct one link:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=3314


The ACL for this page is AdminGroup:read,write,revert. I don't know who
is currently in this AdminGroup, but I think it might be worth having a
list of "trusted" wiki editors, add their names to this group and update
ACLs on all restricted pages to allow AdminGroup.


The link to the key was fixed too.

Regards,
Xavier

Re: please update homepage wikipage

[Xavier Bachelot]

Hi Sérgio,

On 21/07/2016 05:51, Sérgio Basto wrote:

Hi Xavier , Could you please fix rawhide links in "Browse available
packages"

links for rawhide:
download1.rpmfusion.org/free/fedora/development/rawhide/Everything/source/SRPMS/repoview/index.html

we miss the world "Everything/" in URL and we also have links to armhfp .


The links have been updated for Rawhide.

I also wanted to edit the page again to add EL7 but got hit by an issue 
with the captcha. I got the same question as for my previous edit, 
answered it, and got "TextCha: Wrong answer! Go back and try again..."
Removing the wiki cookie doesn't help, neither does using a different 
browser. Anyone from Infra can help with this ?


BTW about wikipage can someone edit http://rpmfusion.org/keys and correct one 
link:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=3314

The ACL for this page is AdminGroup:read,write,revert. I don't know who 
is currently in this AdminGroup, but I think it might be worth having a 
list of "trusted" wiki editors, add their names to this group and update 
ACLs on all restricted pages to allow AdminGroup.


Regards,
Xavier

Re: libdvdcss in RPM Fusion ?

[Xavier Bachelot]

Hi Michael,

On 07/07/2016 23:51, Michael Cronenworth wrote:
> On 07/02/2016 04:47 PM, Xavier Bachelot wrote:
>> Any comments are welcome, I'll enhance the wiki page with them.
>> I'm especially interested in comments_against_  hosting libdvdcss in RPM
>> Fusion, with facts on why it would be bad.
>> Once we'll have enough input, we can then collectively try to reach a
>> decision on what to do with libdvdcss.
> 
> Can you reach out to VideoLAN on their reasoning?
> 
> Kodi has decided to force bundling of libdvd{css,nav,read} and my
> attempts at removing libdvdcss support result in a non-functional Kodi
> in regards to reading DVDs. Even non-encrypted DVDs.
> 

The reasoning is VideoLAN is a French organization and libdvdcss is
legal in France.
See http://www.videolan.org/legal.html

Starting from that point, the first question to answer to be able to
distribute libdvdcss in RPM Fusion is which laws do apply to RPM Fusion.
As all (?) of the servers are hosted in France, I believe the French law
applies and thus it should be safe. But indeed, that is just what I
understand from RPM Fusion infrastructure and I might be wrong.

Second question is, do the people that run the RPM Fusion infra and thus
might be considered liable for the distributed content accept the
potential legal risk, which is pretty low if French laws apply, but is
still non-null. Also, just like I'm unsure where the servers are
located, I'm unsure of the Infra head count and names.

I'll reach out to VideoLAN as soon as we have answers to the above
questions.
Also, once the above are answered, we can then talk about how the RPM
Fusion contributors feel about libdvdcss, but my (biased) feeling is
most of current contributors are ok . However, there have been some
people that were advert to having libdvdcss in RPM Fusion in the past. I
don't know who they are, what were their exact reasoning, if they are
still active or not and if they've changed their mind. That's why I was
calling especially for opinions against distributing libdvdcss.

Regards,
Xavier

libdvdcss in RPM Fusion ?

[Xavier Bachelot]

Hi,

It's been a few years we did not discuss hosting libdvdcss in RPM
Fusion, and as Livna seems to be really dead now, I'd like to have this
discussion again.

As this has already been discussed many time, I gathered some
information in a wiki page :

http://rpmfusion.org/libdvdcss

Any comments are welcome, I'll enhance the wiki page with them.
I'm especially interested in comments _against_ hosting libdvdcss in RPM
Fusion, with facts on why it would be bad.
Once we'll have enough input, we can then collectively try to reach a
decision on what to do with libdvdcss.

Regards,
Xavier

Re: mirrors Re: RPM Fusion branched tree for Fedora 25 published

[Xavier Bachelot]

Hi Sérgio,

On 14/08/2016 02:51, Sérgio Basto wrote:
> Xavier , 
> Can you add to homepage (http://rpmfusion.org/RPM%20Fusion) ? 
> 
> Version 25 / branched 
> 
> http://download1.rpmfusion.org/free/fedora/development/25/Everything/
> 
> http://download1.rpmfusion.org/free/fedora/updates/testing/25/
> 
> we also already have :
> 
> rpmfusion-free-release-25.noarch.rpm  
> rpmfusion-free-release-26.noarch.rpm  
> rpmfusion-free-release-branched.noarch.rpm
> rpmfusion-free-release-rawhide.noarch.rpm
> 
> and can be add to page http://rpmfusion.org/Configuration .
> 
> Thanks
> 
All done. I've also removed Fedora 22.

Regards,
Xavier

Re: Introduction and a Question

[Xavier Bachelot]

Hi Sean,

On 31/01/2017 19:46, Sean Callaway wrote:
> Good morning,
> 
> My name is Sean Callaway and I'm a Linux SA in southern California. I
> currently am the maintainer of two packages for EPEL
> (openvpn-auth-ldap and re2c).
> 
> I am interested in seeing about getting Discord, a gaming chat client,
> into rpmfusion-nonfree. I have a working package in my Copr
> (https://copr.fedorainfracloud.org/coprs/seancallaway/discord/) and am
> getting ready to create my review request. I've read through the docs,
> but most of them are written for Fedora specifically and, as this is a
> binary release for nonfree, I'm not sure they apply fully. Either way,
> I'm left with at least the following question: what permission is
> required from Discord to have this included in RPMFusion? Is a
> developer's quick go-ahead
> (https://twitter.com/crmarsh/status/819615137531183105) enough?
> 
To get a package into RPM Fusion, it needs to be reviewed, like for
Fedora, although some of the rules in RPM Fusion are more relaxed.
You also need to be sponsored, but if you are already a sponsored
packager in Fedora, you automatically get the same status in RPM Fusion.

See https://rpmfusion.org/Contributors for details on the process.

Also, you shouldn't use Fedora's copr for stuff that wouldn't be allowed
into Fedora, so I think your copr repository for discord breaks this rule.
https://fedoraproject.org/wiki/Category:Copr#Content

Hope this helps,
Xavier
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org

Re: [Announce] RPM Fusion for EL is restored - EL7 support started

[Xavier Bachelot]

Hi,

On 27/01/2017 09:53, Simone Caronni wrote:
> Hello,
> 
> On Thu, Jan 26, 2017 at 10:25 AM, Nicolas Chauvet  > wrote:
> 
> For the record EL6 repo is provided as i686 and x86_64 whereas EL7 is
> only provided as x86_64 at this time. This lead to an issue with
> multilib packages in our infra (same as EPEL). So here is the possible
> workaround:
> If there is no specific arched dependencies (either binary only or
> because of limited BR)
> The best way is to build the same package on el6, I will also tag the
> build on el7, so both i686 and x86_64 build from el6 will be available
> on el7.
> This is what I expect to use for libtxc_dxtn (and steam eventually).
> 
> 
> There was a discussion to introduce an i686 target for EPEL 7, but
> unfortunately there was no progress on that.

Maybe last weekend Fosdem got things moving forward again for 32 bits
EPEL 7 ?

> Would it be possible to consider the i686 target in EL7 using the
> alternative architectures of CentOS in RPMFusion?
> 
> This of course would make things diverge a bit from EPEL, where there is
> no 32 bit target, and some packages would actually stay in EPEL in their
> 64 bit form.
> 
> Tree is here: http://mirror.centos.org/altarch/7/
> 
How much of 32 bits EPEL 7 do we need ?
Is steam streaming really that important ?
Or in other words, can we start with just CentOS 32 bits and add EPEL 32
bits only when it comes to light ?

I guess I can probably find out on my own with a custom mock conf. I'm
wondering about the buildsys-build group though, as this is provided by
EPEL iirc, and I'm not sure how to handle that.

So far, there has only been 3 packages that I couldn't build for EL7
because of them being 32 bits only. Namely, that is steam, zsnes and
unace. There are probably more, but I'll give at least these 3 and
libtxc_dxtn a try, if I get a working mock setup.

Regards,
Xavier


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

Re: [Announce] RPM Fusion for EL is restored - EL7 support started

[Xavier Bachelot]

On 08/02/2017 23:41, Xavier Bachelot wrote:
> Hi,
> 
> On 27/01/2017 09:53, Simone Caronni wrote:
>> Hello,
>>
>> On Thu, Jan 26, 2017 at 10:25 AM, Nicolas Chauvet <kwiz...@gmail.com
>> <mailto:kwiz...@gmail.com>> wrote:
>>
>> For the record EL6 repo is provided as i686 and x86_64 whereas EL7 is
>> only provided as x86_64 at this time. This lead to an issue with
>> multilib packages in our infra (same as EPEL). So here is the possible
>> workaround:
>> If there is no specific arched dependencies (either binary only or
>> because of limited BR)
>> The best way is to build the same package on el6, I will also tag the
>> build on el7, so both i686 and x86_64 build from el6 will be available
>> on el7.
>> This is what I expect to use for libtxc_dxtn (and steam eventually).
>>
>>
>> There was a discussion to introduce an i686 target for EPEL 7, but
>> unfortunately there was no progress on that.
> 
> Maybe last weekend Fosdem got things moving forward again for 32 bits
> EPEL 7 ?
> 
>> Would it be possible to consider the i686 target in EL7 using the
>> alternative architectures of CentOS in RPMFusion?
>>
>> This of course would make things diverge a bit from EPEL, where there is
>> no 32 bit target, and some packages would actually stay in EPEL in their
>> 64 bit form.
>>
>> Tree is here: http://mirror.centos.org/altarch/7/
>>
> How much of 32 bits EPEL 7 do we need ?
> Is steam streaming really that important ?
> Or in other words, can we start with just CentOS 32 bits and add EPEL 32
> bits only when it comes to light ?
> 
> I guess I can probably find out on my own with a custom mock conf. I'm
> wondering about the buildsys-build group though, as this is provided by
> EPEL iirc, and I'm not sure how to handle that.
> 
> So far, there has only been 3 packages that I couldn't build for EL7
> because of them being 32 bits only. Namely, that is steam, zsnes and
> unace. There are probably more, but I'll give at least these 3 and
> libtxc_dxtn a try, if I get a working mock setup.
> 
Ok, my hacked mock conf worked, all 4 of them built fine. No run test
though.

It seems cleaner to me to build against CentOS AltArch rather than
building for el6 and tagging for el7, but I don't have enough data to
shape up a real opinion.

Thoughts ?

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

Re: phonon-backend-vlc for EL7

[Xavier Bachelot]

On 24/02/2017 01:20, Orion Poplawski wrote:
> On 02/23/2017 04:38 PM, Orion Poplawski wrote:
>> I've taken a look at building phonon-backend-vlc for EL7.  The version that 
>> is
>> in the el7 branch in git is 0.7.1-1, which does not build because it requires
>> phonon 4.7.0, and EL7 has phonon 4.6.0.  I was able to build 0.6.2-1 fine.
>>
>> Is there any objections to me reverting to 0.6.2-1 in git?  (I suppose 
>> someone
>> with right access to the git repo could reset the el7 branch to that, but not
>> sure it's worth it).
>>
>> Also, while trying it out via dragon player in an X2Go session I'm getting:
>>
>> [7f21a8054578] vdpau_avcodec generic error: Xlib is required for VDPAU
>> [7f21a8054578] vdpau_avcodec generic error: Xlib is required for VDPAU
>> [7f21a80a84b8] core video output error: video output creation failed
>> [7f21c0019cc8] core decoder error: failed to create video output
>>
>> If anyone has any ideas that, that would be helpful.
>>
> 
> Okay, I figured out these errors - it's because vlc needs the basic libxcb_*
> video_output plugins, but for some reason they are in the main vlc package
> rather than vlc-core.  This doesn't make since to me since vlc requires
> vlc-core.  I don't want the vlc binaries, but the libraries/plugins needed for
> playback.
> 
This very much looks like what is discussed here :
https://bugzilla.rpmfusion.org/show_bug.cgi?id=4394
The vlc packaging could probably be arranged to better fit packages that
only depends on the vlc libs.

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

Re: EL7 bootstrap status

[Xavier Bachelot]

On 12/01/2017 19:19, Sérgio Basto wrote:
> On Qui, 2017-01-12 at 07:54 -0600, Richard Shaw wrote:
>> Many of the mythtv dependencies may very well be taken care of now,
>> my last attempt was shortly after 0.28 was released and I could use
>> the qt5 from EPEL. 
>>
>> Here's the list of packages that it took for me to get a good build:
...snip...
> 
> 
> many of these packages are already built see 
> http://koji.rpmfusion.org/mash/free/el7/x86_64/repoview/
> 
Both mythtv and xmltv are built but there is an issue with xmltv in the
pkgdb, so it can't be tagged yet. I've sent Richard a mail about that.

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

Re: libdvdcss in RPM Fusion ?

[Xavier Bachelot]

On 06/09/2016 10:03, Nicolas Chauvet wrote:

2016-09-06 9:48 GMT+02:00 Ralf Corsepius <rc040...@freenet.de>:

On 09/01/2016 06:56 PM, Xavier Bachelot wrote:


Nicolas, can you share your thoughts on this?


libdvdcss's legal situation in Germany is widely unclear[1].

According to German laws cracking "wirksame technische Maßnahmen“
("effective technical measures") of copy protection is unlawful.

The fundamental question in this context is: "Does CSS (still) qualify as an
effective technical measures of copy protection?"

Answer: Nobody knows. Only courts would be able to answer this question.

I.e. the legal risks of libdvdcss have not changed for years, i.e. should
libdvdcss binaries enter RPMFusion, esp. German RPMFusion mirror
owners/mirror managers are not unlikely to be confronted with legal action.


How many legal action have occurred ?



My understanding is a lot of countries have provision for 
inter-operability (including the US). I don't know if such a provision 
exists in Germany, but that would then allow to ship libdvdcss safely.


I had a short discussion with Adrian about mirrors. I may not be 
transcribing his words exactly, but he basically said shipping libdvdcss 
is not worst than all the patent encumbered stuff for US mirrors. We can 
still reach specifically to mirror admins to get their feeling.


If mirroring libdvdcss is still a concern, we may want to ship libdvdcss 
in a dedicated repo so mirrors can exclude it easily.
If that is not enough, we might do as Fedora does for openh264, that is 
use the RPM Fusion infra for the SCM and building the package, but 
upload it to another host. Given Pix mail from this morning, I guess it 
could be where Livna was hosted. That is more burden on the RPM Fusion 
infra and infra admins though... And it is not as straight-forward and 
convenient for end-users.


Regards,
Xavier

PS: the link to the page I created in the wiki about libdvdcss :
http://rpmfusion.org/libdvdcss

Re: libdvdcss in RPM Fusion ?

[Xavier Bachelot]

Hi,

On 05/09/2016 15:56, Andrea Musuruane wrote:

On Fri, Sep 2, 2016 at 9:10 PM, Nicolas Chauvet > wrote:

> As a package maintainer and end-user, I think it'd be valuable to have
> libdvdcss in RPM Fusion.
>
> If there is some concern about mirroring, though, perhaps we could
create a
> *third* repository for this sort of even more dubious package?
Which I guess
> at the moment would just be libdvdcss and anything that depends on
it. Then
> mirrors that don't / can't ship it simply don't mirror this
additional repo.

That reminds me how openh264 is dealt with in fedora.
Can anyone sum-up the existing methods used by various distro about
this issue ?


I did a little research.


Thanks for the research, this is much appreciated.


libdvdcss is Mageia Tainted repository, an official Mageia repository
that hosts packages that they may infringe on patents and copyright laws
in some countries. E.g. most multimedia codecs are shipped in this
repository.

Mageia is backed up by a French non-profit organization (just like RPM 
Fusion).



It is included in Arch Linux, in the extra repository (i.e. non core
packages).

libdvdcss is not included in Debian, Ubuntu and SUSE.

Debian users must use Debian Multimedia repository - which is not part
of the Debian project but it is maintained by Debian developers or
maintainers and therefore it seems similar to RPM Fusion.
https://anonscm.debian.org/git/pkg-multimedia/libdvdcss.git/tree/debian


Debian multimedia also provides libdvd-pkg. `dpkg-reconfigure
libdvd-pkg` may be used to build and install  libdvdcss* package(s).
https://anonscm.debian.org/git/pkg-multimedia/libdvdcss-pkg.git/tree/debian


This package is also provided in Ubuntu 15.10+ and it must how their
users must install libdvdcss:
https://help.ubuntu.com/community/RestrictedFormats/PlayingDVDs


Debian/Ubuntu uses can also use a VideoLAN repository to install libdvdcss:
http://www.videolan.org/developers/libdvdcss.html


VideoLAN also hosts a repository for SuSE users which includes libdvdcss.

Libdvdcss is already packaged for Fedora in Remi's RPM repository and in
United RPMS.
http://rpms.famillecollet.com/fedora/24/remi/i386/repoview/libdvdcss.html 



The problem with Remi's repo is it ships much more than just libdvdcss, 
and at least some of the packages it ships will replace packages from 
Fedora.



http://unitedrpms.sourceforge.net/x86_64/repoview/libdvdcss.html



Is United RPMs here to stay or was that a temporary workaround while the
RPM Fusion infra was worked on ?
Sérgio, maybe ?


Summarizing, these are the methods we can implement:

 1. ship libdvdcss in the free repository
 2. ship libdvdcss in a newly created repository
 3. ship a package that can build and install libdvdcss in the free
repository


I'd like to add :
3.5 : use RPM Fusion for SCM and build, but ship the binaries from 
elsewhere (ala openh264 in Fedora, built in Fedora infra, but shipped 
from Cisco)



 4. don't ship libdvdcss and refer to another (non RPM Fusion
maintained) repository

Maybe we should ask various RPM Fusion mirror maintainers what they
think about and what is their preferred method to ship libdvdcss.

Bye,

Andrea



Regards,
Xavier

Re: Buildroot override request

[Xavier Bachelot]

On 07/09/2016 08:33, Nicolas Chauvet wrote:

Hi,

You can now use koji-rpmfusion tag-build f2?-{,non}free-override
your_rpmfusion_build_nvr for rpmfusion build to request an override
tag. This will trigger a regen-repo task (if there is a metadata
issue, that migh be possible to workaround to force a regen-repo
task).

It's not possible to tag a fedora package, (that's a manual task), so
please ask on bugzilla and assign the request to me if needed.

Untag is not possible yet, I will need to fix the koji-hub policy

This should be reported in our wiki.


Done : http://rpmfusion.org/Contributors#Requesting_a_buildroot_override

Regards,
Xavier

Re: libdvdcss in RPM Fusion ?

[Xavier Bachelot]

On 23/07/2016 08:27, Michael Cronenworth wrote:

On 07/08/2016 12:59 PM, Xavier Bachelot wrote:

The reasoning is VideoLAN is a French organization and libdvdcss is
legal in France.
Seehttp://www.videolan.org/legal.html

Starting from that point, the first question to answer to be able to
distribute libdvdcss in RPM Fusion is which laws do apply to RPM Fusion.
As all (?) of the servers are hosted in France, I believe the French law
applies and thus it should be safe. But indeed, that is just what I
understand from RPM Fusion infrastructure and I might be wrong.

Second question is, do the people that run the RPM Fusion infra and thus
might be considered liable for the distributed content accept the
potential legal risk, which is pretty low if French laws apply, but is
still non-null. Also, just like I'm unsure where the servers are
located, I'm unsure of the Infra head count and names.

I'll reach out to VideoLAN as soon as we have answers to the above
questions.
Also, once the above are answered, we can then talk about how the RPM
Fusion contributors feel about libdvdcss, but my (biased) feeling is
most of current contributors are ok . However, there have been some
people that were advert to having libdvdcss in RPM Fusion in the past. I
don't know who they are, what were their exact reasoning, if they are
still active or not and if they've changed their mind. That's why I was
calling especially for opinions against distributing libdvdcss.


Nicolas, can you share your thoughts on this?


Now that the summer vacations are coming to an end, hopefully more 
people are around and can raise their voice.
Infra people, packages maintainers, mirror admins, end-users, don't be 
shy, let us know what you think about including libdvdcss in RPM Fusion.


Regards,
Xavier

Re: Update ffmpeg in F24 to 3.1.x ?

[Xavier Bachelot]

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

Re: EL7 bootstrap status

[Xavier Bachelot]

On 12/01/2017 02:51, Richard Shaw wrote:

As far as MythTV goes, I would like it to be available for EL7 but
there's just too many missing dependencies last time I worked on it and
I don't have time to take on more packages.


From the build log :
http://koji.rpmfusion.org/kojifiles/work/tasks/1319/71319/root.log

mythtv only needs a couple EPEL packages to be branched in order to build :
No Package found for perl(Image::Size)
No Package found for perl(Net::UPnP::ControlPoint)
No Package found for perl(Net::UPnP::QueryResponse)

That indeed doesn't mean all run time dependencies are here, I'll be 
checking that later on.


It would be awesome if you could request the branches for these packages.

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

Re: EL7 bootstrap status

[Xavier Bachelot]

On 12/01/2017 11:13, Nicolas Chauvet wrote:

2017-01-12 11:08 GMT+01:00 Xavier Bachelot <xav...@bachelot.org>:

On 12/01/2017 02:51, Richard Shaw wrote:


As far as MythTV goes, I would like it to be available for EL7 but
there's just too many missing dependencies last time I worked on it and
I don't have time to take on more packages.


From the build log :
http://koji.rpmfusion.org/kojifiles/work/tasks/1319/71319/root.log

mythtv only needs a couple EPEL packages to be branched in order to build :
No Package found for perl(Image::Size)
No Package found for perl(Net::UPnP::ControlPoint)
No Package found for perl(Net::UPnP::QueryResponse)

That indeed doesn't mean all run time dependencies are here, I'll be
checking that later on.

It would be awesome if you could request the branches for these packages.




I've requested the branch for the 2 packages.


Thoses are perl dependencies, maybe we can have help from the perl SIG.
xmltv is also failing because of missing perl dependencies.


xmltv needs :
perl(HTTP::Cache::Transparent)
perl(Lingua::EN::Numbers::Ordinate)
perl(Lingua::Preferred) >= 0.2.4
perl(Log::TraceMessages)
perl(Tk::TableMatrix)

I'll look at them later.

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

Re: EL7 bootstrap status

[Xavier Bachelot]

On 12/01/2017 11:08, Xavier Bachelot wrote:


That indeed doesn't mean all run time dependencies are here, I'll be
checking that later on.


Nonfree is clean

However, Free does have a few unresolvable deps :

package: 10:buildsys-build-rpmfusion-kerneldevpkgs-current-20-100.x86_64 
from rf-free

  unresolved deps:
 kernel-devel-uname-r = 0:3.19.5-100.fc20.x86_64
package: foo2hiperc-0.20130618-1.el7.x86_64 from rf-free
  unresolved deps:
 lcms
package: foo2hp-0.20130618-1.el7.x86_64 from rf-free
  unresolved deps:
 lcms
package: foo2lava-0.20130618-1.el7.x86_64 from rf-free
  unresolved deps:
 lcms
package: foo2oak-0.20130618-1.el7.x86_64 from rf-free
  unresolved deps:
 lcms
package: foo2qpdl-0.20130618-1.el7.x86_64 from rf-free
  unresolved deps:
 lcms
package: foo2slx-0.20130618-1.el7.x86_64 from rf-free
  unresolved deps:
 lcms
package: foo2xqx-0.20130618-1.el7.x86_64 from rf-free
  unresolved deps:
 lcms
package: foo2zjs-0.20130618-1.el7.x86_64 from rf-free
  unresolved deps:
 lcms
 argyllcms
package: kdenlive-0.9.10-1.el7.x86_64 from rf-free
  unresolved deps:
 kde-runtime >= 0:4.14.8
package: mythweb-0.27.4-2.el7.noarch from rf-free
  unresolved deps:
 php-MythTV >= 0:0.27.4
 mythffmpeg
package: openshot-1.4.3-3.el7.noarch from rf-free
  unresolved deps:
 pygoocanvas

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

Re: EL7 bootstrap status

[Xavier Bachelot]

On 12/01/2017 12:36, Xavier Bachelot wrote:

xmltv is also failing because of missing perl dependencies.


xmltv needs :
perl(HTTP::Cache::Transparent)
perl(Lingua::EN::Numbers::Ordinate)
perl(Lingua::Preferred) >= 0.2.4
perl(Log::TraceMessages)
perl(Tk::TableMatrix)

I'll look at them later.


I've requested the EL7 branch for all of the above packages.

Nicolas, you are the PoC for all of the EL5 and EL6 branches, feel free 
to request commit on the EL7 branch.


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

Re: EL7 bootstrap status

[Xavier Bachelot]

On 08/01/2017 20:52, Xavier Bachelot wrote:
> Hi,
> 
> Quick status on RPM Fusion for EL7...
> 
> The infra is ready and some packages have already been built :
> https://koji.rpmfusion.org/mash/free/el7/x86_64/repoview/
> https://koji.rpmfusion.org/mash/nonfree/el7/x86_64/repoview/
> 

Here's what I have built so far :
* Free :
 amule
 audacity-freeworld
 avidemux
 exfat-utils
 fceux
 ffmpeg-compat
 ffmpegthumbnailer
 foo2zjs
 fuse-exfat
 gstreamer1-libav
 gstreamer1-plugins-bad-freeworld
 gstreamer1-plugins-ugly
 gstreamer-plugins-bad
 imagination
 k3b-extras-freeworld
 kdenlive
 libde265
 libmimic
 libmms
 libmpeg3
 libquicktime
 libshairport
 libvdpau-va-gl
 megamario
 minidlna
 mjpegtools
 motion
 mp3gain
 mpd
 mythweb
 openshot
 simplescreenrecorder
 smplayer
 sox-plugins-freeworld
 transcode
 vokoscreen

* Nonfree :
 faac
 gstreamer-plugins-bad-nonfree
 pdflib-lite
 snes9x
 tarsnap
 xv


And here's what is still broken with the corresponding scratch builds :

free/audacious-plugins-freeworld
Task info: http://koji.rpmfusion.org/koji/taskinfo?taskID=71276

free/freetype-freeworld
Task info: http://koji.rpmfusion.org/koji/taskinfo?taskID=71277

free/freshplayerplugin
Task info: http://koji.rpmfusion.org/koji/taskinfo?taskID=71279

free/get_iplayer
Task info: http://koji.rpmfusion.org/koji/taskinfo?taskID=71280

free/kodi
Task info: http://koji.rpmfusion.org/koji/taskinfo?taskID=71281

free/lives
Task info: http://koji.rpmfusion.org/koji/taskinfo?taskID=71284

free/mixxx
Task info: http://koji.rpmfusion.org/koji/taskinfo?taskID=71286

free/mplayer
Task info: http://koji.rpmfusion.org/koji/taskinfo?taskID=71288

free/mythtv
Task info: http://koji.rpmfusion.org/koji/taskinfo?taskID=71289

free/obs-studio
Task info: http://koji.rpmfusion.org/koji/taskinfo?taskID=71290

free/tvheadend
Task info: http://koji.rpmfusion.org/koji/taskinfo?taskID=71292

free/xmltv
Task info: http://koji.rpmfusion.org/koji/taskinfo?taskID=71293

free/zsnes
Task info: http://koji.rpmfusion.org/koji/taskinfo?taskID=71294

nonfree/caja-dropbox
Task info: http://koji.rpmfusion.org/koji/taskinfo?taskID=71295

nonfree/steam
Task info: http://koji.rpmfusion.org/koji/taskinfo?taskID=71296

nonfree/unace
Task info: http://koji.rpmfusion.org/koji/taskinfo?taskID=71298

Please report any issue with the packages already built
Also, feel free to take care of any package that has not been built yet,
just make sure to answer this mail or drop a line in #rpmfusion to avoid
duplicated work.

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

Re: EL7 status?

[Xavier Bachelot]

On 02/01/2017 17:32, Nicolas Chauvet wrote:

2017-01-02 17:06 GMT+01:00 Karel Volný :


Hi,

thanks,


Afaiu, everything is ready for EL7, but no push has happened yet.
Nicolas is waiting for more packages to be available, most notably ffmpeg
I guess.
There is a mash tree somewhere, but I don't have the url at hand.
Also, using 'rfpkg' to build for EL7 worked for me.



it doesn't work for me, because I need ... ffmpeg :-)


The current consensus is to have ffmpeg 2.8x in epel7 "by default".
Then it will be possible to have a ffmpeg-latest or ffmpeg3 next (I
still prefer the former as it will be relevant for both epel and
fedora).
That been said it will only be allowed to link to the default ffmpeg
(2.8x) to avoid relinking error when a process has different version
of ffmpeg libs linked.


ffmpeg has now been built, thanks to Nicolas.
You guys can all go wild, hit the builders heavily and help with turning 
up RPM Fusion for EL7 into a reality...


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

Re: new to RPM Fusion

[Xavier Bachelot]

On 28/12/2016 19:03, Chuck Anderson wrote:
> Hi All,
> 
> I've been a Fedora packager for many years and now I'd like to join
> the RPM Fusion community, primarily to assist Andy with the transition
> of the zoneminder package from Fedora.  I'm also interested in
> packaging emulators, sound fonts, and some video related packages.
> 
> I've joined this list, the bugzilla, and FAS.  My FAS username is cra.
> 
> Thanks,
> Chuck

Hi Chuck,

Welcome to RPM Fusion. As you're already a sponsored Fedora packager,
you are also entitled to the same status in RPM Fusion. Feel free to
submit and do reviews, it works mostly the same here as in Fedora.
I wish you a nice journey with us :-)

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

Re: EL7 status?

[Xavier Bachelot]

Hi Karel,

On 02/01/2017 16:32, Karel Volný wrote:


pls, what's the status of EL7 repos?


Afaiu, everything is ready for EL7, but no push has happened yet.
Nicolas is waiting for more packages to be available, most notably 
ffmpeg I guess.

There is a mash tree somewhere, but I don't have the url at hand.
Also, using 'rfpkg' to build for EL7 worked for me.

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

EL7 bootstrap status

[Xavier Bachelot]

Hi,

Quick status on RPM Fusion for EL7...

The infra is ready and some packages have already been built :
https://koji.rpmfusion.org/mash/free/el7/x86_64/repoview/
https://koji.rpmfusion.org/mash/nonfree/el7/x86_64/repoview/

I've locally built a selection of packages :
* Free :
amule
audacious-plugins-freeworld
audacity-freeworld
avidemux
exfat-utils
fceux
ffmpeg-compat
ffmpegthumbnailer
foo2zjs
freetype-freeworld
freshplayerplugin
fuse-exfat
get_iplayer
gstreamer1-libav
gstreamer1-plugins-bad-freeworld
gstreamer1-plugins-ugly
gstreamer-plugins-bad
imagination
k3b-extras-freeworld
kdenlive
kodi
libde265
libmimic
libmms
libmpeg3
libquicktime
libshairport
libvdpau-va-gl
lives
megamario
minidlna
mixxx
mjpegtools
motion
mp3gain
mpd
mplayer
mythtv
mythweb
obs-studio
openshot
simplescreenrecorder
smplayer
sox-plugins-freeworld
transcode
tvheadend
vokoscreen
xmltv
zsnes

* Nonfree :
caja-dropbox
faac
gstreamer-plugins-bad-nonfree
pdflib-lite
snes9x
steam
tarsnap
unace
xv

Most of them succeed, and I'm going to make a real build for them soon.
Unfortunately, there is currently an issue with the EL7 buildroot.

Here's the list of failed build :
* Free :
audacious-plugins-freeworld
--> Error: No Package found for audacious-devel >= 3.4
--> Error: No Package found for libbinio-devel
--> Error: No Package found for libmms-devel

freshplayerplugin
--> Error: No Package found for ragel

get_iplayer
--> Error: No Package found for file-libs >= 5.14-14

gstreamer1-plugins-bad-freeworld
--> Error: No Package found for libmimic-devel
--> Error: No Package found for libmms-devel
--> Error: No Package found for mjpegtools-devel >= 2.0.0

gstreamer1-plugins-ugly
--> Error: No Package found for libsidplay-devel >= 1.36.0

gstreamer-plugins-bad
--> Error: No Package found for libmimic-devel
--> Error: No Package found for libmms-devel
--> Error: No Package found for mjpegtools-devel >= 2.0.0

libde265
--> not branched for el7.
--> git master builds fine for el7.

libmpeg3
--> Error: No Package found for libquicktime-devel

lives
--> not branched for el7
--> git master doesn't build for el7 :
  Error: No Package found for GLee-devel
  Error: No Package found for pkgconfig(libfreenect)
  Error: No Package found for pkgconfig(libmatroska)
  Error: No Package found for pkgconfig(mjpegtools)
  Error: No Package found for python3-devel

mixxx
--> Error: No Package found for portmidi-devel

mjpegtools
--> Error: No Package found for libquicktime-devel >= 0.9.8

motion
--> Error: No Package found for ffmpeg-compat-devel

mpd
--> Error: No Package found for libmms-devel

mplayer
--> build error, not investigated.

mythtv
--> Error: No Package found for perl(Image::Size)
--> Error: No Package found for perl(Net::UPnP::ControlPoint)
--> Error: No Package found for perl(Net::UPnP::QueryResponse)

obs-studio
--> not branched for el7
--> git master doesn't build for el7 :
  Error: No Package found for speexdsp-devel

simplescreenrecorder
--> not branched for el7.
--> git master builds fine for el7.

transcode
--> Error: No Package found for ffmpeg-compat-devel >= 0.4.9-0.46.20080614
--> Error: No Package found for libmpeg3-devel
--> Error: No Package found for libquicktime-devel >= 0.9.8
--> Error: No Package found for mjpegtools-devel
--> Error: No Package found for pvm

tvheadend
--> not branched for el7
--> git master doesn't build for el7 :
  Error: No Package found for hdhomerun-devel

xmltv
--> Error: No Package found for perl(HTTP::Cache::Transparent)
--> Error: No Package found for perl(Lingua::EN::Numbers::Ordinate)
--> Error: No Package found for perl(Lingua::Preferred) >= 0.2.4
--> Error: No Package found for perl(Log::TraceMessages)
--> Error: No Package found for perl(Tk::TableMatrix)

zsnes
--> something related to ExclusiveArch: i686 probably


* Nonfree :
caja-dropbox
--> configure: error: couldn't find pygtk

faac
--> build error, not investigated

gstreamer-plugins-bad-nonfree
--> Error: No Package found for faac-devel

unace
--> something related to ExclusiveArch: i686 probably

Please note I have requested the missing EL7 branches.

Feel free to take care of the packages you care about, especially if
they failed my local build. Request the missing EPEL 7 branches,
investigate the build failures, be nice to people around you, make the
world a better place, send me beer, all of this will help ;-)

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

Re: Newcomer seeking sponsorship

[Xavier Bachelot]

Hi Andy,

On 28/12/2016 15:44, Andrew Bauer wrote:

Hi Xavier, The conversation with Fedora was in an email conversation.
For lack of a better place, I've put the conversation here for
review:
https://gist.github.com/knnniggett/87962ab97a6ffbc139083b07d0522231

I'll ping Chuck regarding this conversation so we can get him into it
if needed.

ZoneMinder searches for and links against ffmpeg & vlc headers, if it
finds them, during build time. Adding ffmpeg/vlc after the fact
doesn't work currently because these get flagged as not present
during the build. Consequently, the code, which makes the api calls
to those libraries, will not be present in any of zoneminder's
executables. I don't currently know of a simple way to separate
zoneminder into the pieces requiring h264 and the pieces that do not.
Perhaps there is something I am not thinking of at the moment so feel
free to continue the conversation.

I was thinking about dlopen'ing, but that is likely not a very practical 
solution.

Thus RPM Fusion it goes...


I didn't mean to overstate my sponsorship with Fedora. It was more of
a casual "hey I'll sponsor you if you need sponsorship" sort of
thing. I'm learning this as I go, and I'm just beginning to get
involved with EPEL, Fedora, and RPMFusion.


All 3 are tightly coupled : EPEL packages are just different branches in 
Fedora git (and somewhat stricter rules and longer support), and RPM 
Fusion follows the same packaging rules as Fedora (minus the patent 
restriction) and provides packages that cannot be in Fedora and EPEL.
As a consequence, a Fedora sponsored packager automatically gets granted 
the same privileges in RPM Fusion.


You're very welcome to join us, it's a fun place to be :-)

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

Re: Newcomer seeking sponsorship

[Xavier Bachelot]

Hi Andy,

On 27/12/2016 19:52, Andrew Bauer wrote:

Greetings,
My real name is Andy, and I just went through the RPMFusion crash course for 
submitting my first package, zoneminder.
https://bugzilla.rpmfusion.org/show_bug.cgi?id=4393

I am part of the upstream zoneminder development team, and currently manage 
zmrepo.zoneminder.com. At the moment, zmrepo is the only third party repo with 
all of zoneminder's dependencies found in one place. If permitted, I would 
eventually like to move the zoneminder package to RPMFusion.

Additionally, I've got to find new homes for several of zoneminder's 
dependencies as well. I listed these in the bug report above. I don't expect 
this to be a fast process.

Some of you may know that zoneminder currently exists in the Fedora 25 repo. I 
have been in discussion with the Fedora packaging team to have it removed, 
moving forward. Because the surveillance industry has adopted h264 as the 
defacto streaming standard, zoneminder does not belong in the Fedora repo. 
Today, zoneminder will build w/o ffmpeg/h264 support but that makes it 
incompatible with nearly all modern ip cameras.

In any case, I'm getting help from Fedora, but I also need someone from 
RPMFusion to sponsor. Anyone willing?

About packaging, is it possible for zoneminder to stay in Fedora without 
the h264 support (or any other patent encumbered stuff) and just package 
the parts that are forbidden in RPM Fusion ?


Is the discussion with the Fedora maintainer(s) available ? In a bug or 
whatever ?


About sponsorship, if you are already sponsored in Fedora, you will be 
automatically sponsored for RPM Fusion on request. If not, you can 
indeed be sponsored in RPM Fusion directly, but the preferred way is to 
be sponsored in Fedora first.


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

Re: Unable to approve ACLS in pkgdb

[Xavier Bachelot]

On 27/03/2017 07:04, Jonathan Dieter wrote:

Sorry if this is known to be not working, but I'm unable to approve
ACLs in https://admin.rpmfusion.org/pkgdb.

It goes around and around for a long time, and then I finally get the
following error:

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST
/pkgdb/acl/pending/approve.

Reason: Error reading from remote server

Apache/2.4.6 (CentOS) Server at admin.rpmfusion.org Port 443


This is most probably the same issue, but I got the same error yesterday 
evening when requesting an ACL in pkgdb (xrick fwiw).


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

Re: Mass rebuild for f26 is almost finished

[Xavier Bachelot]

On 25/03/2017 04:09, Sérgio Basto wrote:
> Hi,
> Almost all packages have been rebuilt, we have these FTBFS (so far) : 
> 
> ./bombono-dvd/ftbfs
> ./dhewm3/ftbfs
> ./libdvbcsa/ftbfs
> ./lightspark/ftbfs
> ./mythtv/ftbfs
> ./openmw/ftbfs
> ./qt5-qtwebengine-freeworld/ftbfs
> ./simplescreenrecorder/ftbfs
> ./sonic-visualiser-freeworld/ftbfs
> ./stella/ftbfs
> ./tvheadend/ftbfs
> ./xine-plugin/ftbfs
> ./zboy/ftbfs
> 
xine-plugin is fixed.


That is only for the free packages, the nonfree packages have not been
bumped and rebuilt yet.

Also, about the FTBFS, most of them are issues with the new aarch64,
ppc64 and ppc64le arches. The quick and dirty fix, but also incorrect in
most cases, is to exclude the failing arches, however this needs to be
revisited later. There are tracker bugs in Fedora bugzilla for this, do
we have the same for RPM Fusion, and if not shouldn't we have too ?
https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Build_Failures

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

Re: libbluray soname bump

[Xavier Bachelot]

On 09/03/2017 17:11, Xavier Bachelot wrote:
> Hi,
> 
> I'm going to update libbluray in rawhide (and f26 as I believe its early
> enough in the release cycle) to version 1.0.0, which includes a soname
> bump. This is a critical path package.
> 
> According to repoquery, the following packages will need to be rebuild :
> 
> In Fedora :
> - gvfs
> 
> In RPM Fusion :
> - ffmpeg
> - mplayer
> - mpv
> - vdr-xineliboutput
> - vlc
> - xine-lib
> 
> I can take care of the rebuilds for RPM Fusion, but I don't have enough
> privileges to do the same for gvfs in Fedora, so it will need to be
> coordinated with gvfs maintainer(s).
> 
> RPM Fusion maintainers, let me know if you want me to either take care
> of the rebuild or leave it to me.
> 
Just to make sure everyone knows, the needed RPM Fusion rebuilds will be
handled as part of the F26 mass rebuild which is about to happen real soon.

That also means building against F26 currently will fail if your package
has a build requires on any of the above packages, until they are rebuilt.

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

Re: libbluray soname bump

[Xavier Bachelot]

On 09/03/2017 17:38, Björn 'besser82' Esser wrote:
> Am 09.03.2017 um 17:34 schrieb Xavier Bachelot:
>> oops, with the proper fedora devel mail now...
>>
>> On 09/03/2017 17:11, Xavier Bachelot wrote:
>>> Hi,
>>>
>>> I'm going to update libbluray in rawhide (and f26 as I believe its early
>>> enough in the release cycle) to version 1.0.0, which includes a soname
>>> bump. This is a critical path package.
>>>
>>> According to repoquery, the following packages will need to be rebuild :
>>>
>>> In Fedora :
>>> - gvfs
>>>
>>> In RPM Fusion :
>>> - ffmpeg
>>> - mplayer
>>> - mpv
>>> - vdr-xineliboutput
>>> - vlc
>>> - xine-lib
>>>
>>> I can take care of the rebuilds for RPM Fusion, but I don't have enough
>>> privileges to do the same for gvfs in Fedora, so it will need to be
>>> coordinated with gvfs maintainer(s).
>>>
>>> RPM Fusion maintainers, let me know if you want me to either take care
>>> of the rebuild or leave it to me.
>>>
>>> Shall you have anything to discuss about this update, feel free to reach
>>> out to me by mail or irc (xavierb on freenode).
>>>
>>> Regards,
>>> Xavier
>>>
>>
> 
> Well, I'm a provenpackager and can take care of rebuilding gvfs for
> Fedora.  Just let me know, when you updated libblueray.

Thanks Björn, I've rebuilt libbluray for rawhide, please proceed with
gvfs rebuild at your earlier convenience.

I will follow up with f26 and request a buildroot override.

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

Re: xpra-codecs-freeworld needs maintainer !

[Xavier Bachelot]

On 17/04/2017 13:09, Sérgio Basto wrote:
> On Seg, 2017-04-17 at 12:44 +0200, Xavier Bachelot wrote:
>> On 17/04/2017 12:27, Antonio Trande wrote:
>>>
>>> I take it.
>>>
>>> On 04/17/2017 12:18 PM, Sérgio Basto wrote:
>>>>
>>>> Hello , 
>>>>
>>>> https://bugzilla.rpmfusion.org/show_bug.cgi?id=4432
>>>>
>>>> Since maintainer looks like is unresponsive , I'd add someone as
>>>> maintainer of this package. 
>>>>
>>>> Thanks,
>>>>
>> I was looking at fixing the broken deps in F25 right now.
>> I guess there's no need to duplicate work on this, so here's the work
>> in
>> progress patch to update to 1.0 to match f24 and F25, another patch
>> will
>> be needed to update to 1.0.2 to match rawhide and f26.
> 
> Please coordinate with Antonio Trande, you could take the bug report to
> flag that you are working on it . 
> 
> 
The patch was just some very preliminary work.The build that was running
while I sent the mail failed on some ffmpeg defines issue.
As Antonio is willing to adopt the package and as I'm not really
interested in xpra beside fixing the dependency issue, I'm leaving this
to Antonio's very capable hands, I'm sure I'll find something else
useful to RPM Fusion to work on ;-)

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

Re: xpra-codecs-freeworld needs maintainer !

[Xavier Bachelot]

On 17/04/2017 12:27, Antonio Trande wrote:
> I take it.
> 
> On 04/17/2017 12:18 PM, Sérgio Basto wrote:
>> Hello , 
>>
>> https://bugzilla.rpmfusion.org/show_bug.cgi?id=4432
>>
>> Since maintainer looks like is unresponsive , I'd add someone as
>> maintainer of this package. 
>>
>> Thanks,
>>
I was looking at fixing the broken deps in F25 right now.
I guess there's no need to duplicate work on this, so here's the work in
progress patch to update to 1.0 to match f24 and F25, another patch will
be needed to update to 1.0.2 to match rawhide and f26.

Regards,
Xavier


>From 42467d3666478779e760f00e647f564478d5ecbc Mon Sep 17 00:00:00 2001
From: Xavier Bachelot <xav...@bachelot.org>
Date: Mon, 17 Apr 2017 12:40:16 +0200
Subject: [PATCH] 1.0; sync with Fedora

---
 xpra-codecs-freeworld.spec | 31 +++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/xpra-codecs-freeworld.spec b/xpra-codecs-freeworld.spec
index b22e8ab..245232a 100644
--- a/xpra-codecs-freeworld.spec
+++ b/xpra-codecs-freeworld.spec
@@ -1,11 +1,11 @@
 Name:   xpra-codecs-freeworld
-Version:0.17.5
-Release:2%{?dist}
+Version:1.0
+Release:1%{?dist}
 Summary:Additional codecs for xpra using x264 and ffmpeg
 
 License:GPLv2+
-URL:http://www.xpra.org/
-Source0:http://xpra.org/src/xpra-%{version}.tar.xz
+URL:https://www.xpra.org/
+Source0:https://xpra.org/src/xpra-%{version}.tar.xz
 
 BuildRequires:  python2-devel pygobject2-devel pygtk2-devel
 BuildRequires:  libXtst-devel
@@ -28,7 +28,7 @@ x264 and ffmpeg.
 
 
 %build
-CFLAGS="%{optflags}" %{__python} setup.py build \
+CFLAGS="%{optflags}" %{__python2} setup.py build \
 --with-enc_x264 \
 --with-dec_avcodec2 \
 --with-csc_swscale \
@@ -37,27 +37,34 @@ CFLAGS="%{optflags}" %{__python} setup.py build \
 
 %install
 mkdir destdir
-%{__python} setup.py install --skip-build --root destdir
+%{__python2} setup.py install \
+--skip-build \
+--root destdir \
+--verbose
 
 mkdir -p %{buildroot}%{python_sitearch}/xpra/codecs/
-pushd destdir%{python_sitearch}/xpra/codecs/
+pushd destdir%{python2_sitearch}/xpra/codecs/
 cp -pr csc_swscale dec_avcodec2 enc_x264 libav_common \
-%{buildroot}%{python_sitearch}/xpra/codecs/
+%{buildroot}%{python2_sitearch}/xpra/codecs/
 popd
 
-#drop shebangs from python_sitearch
-find %{buildroot}%{python_sitearch}/xpra -name '*.py' \
+#drop shebangs from python2_sitearch
+find %{buildroot}%{python2_sitearch}/xpra -name '*.py' \
 -exec sed -i '1{\@^#!/usr/bin/env python@d}' {} \;
 
 #fix permissions on shared objects
-find %{buildroot}%{python_sitearch}/xpra -name '*.so' \
+find %{buildroot}%{python2_sitearch}/xpra -name '*.so' \
 -exec chmod 0755 {} \;
 
 %files
-%{python_sitearch}/xpra/codecs/*
+%{python2_sitearch}/xpra/codecs/*
 %license COPYING
 
 %changelog
+* Mon Apr 17 2017 Xavier Bachelot <xav...@bachelot.org> - 1.0-1
+- Update to 1.0.
+- Sync specfile with Fedora.
+
 * Tue Mar 21 2017 RPM Fusion Release Engineering <kwiz...@rpmfusion.org> - 0.17.5-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
 
-- 
2.9.3


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

Re: xpra-codecs-freeworld needs maintainer !

[Xavier Bachelot]

On 18/04/2017 12:08, Antonio Trande wrote:


On 04/18/2017 11:48 AM, Antonio Trande wrote:

Despite your patch for ffmpeg31, xpra still fails with following error:
https://paste.fedoraproject.org/paste/FUA8uWN~mNELJYwEicqWaV5M1UNdIGYhyRLivL9gydE=/raw



The error is not visible.
Here:
https://paste.fedoraproject.org/paste/HfxvIwfHrYW7FrcDllrZBl5M1UNdIGYhyRLivL9gydE=/raw



I'm surprised, I just built it again, and it works for me.
The patch is supposed to fix exactly that error.

The way I did it is :
- clone the repo
- apply patch 1 and 2 to master branch
- rfpkg --release 25 mockbuild

The next steps would be :
- commit to master after uploading the 1.0 tarball and updating 
.gitignore and sources

- merge master into f25 and f24
- apply third patch to master
- merge master into f26
and indeed do the needed builds along the way.

Also you should look at enabling x265, xvid and possibly more.

Generally speaking, I think having commit rights to both Fedora's xpra 
and its RPM Fusion counterpart would ease keeping both in sync.


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

libbluray soname bump

[Xavier Bachelot]

Hi,

I'm going to update libbluray in rawhide (and f26 as I believe its early 
enough in the release cycle) to version 1.0.0, which includes a soname 
bump. This is a critical path package.


According to repoquery, the following packages will need to be rebuild :

In Fedora :
- gvfs

In RPM Fusion :
- ffmpeg
- mplayer
- mpv
- vdr-xineliboutput
- vlc
- xine-lib

I can take care of the rebuilds for RPM Fusion, but I don't have enough
privileges to do the same for gvfs in Fedora, so it will need to be 
coordinated with gvfs maintainer(s).


RPM Fusion maintainers, let me know if you want me to either take care 
of the rebuild or leave it to me.


Shall you have anything to discuss about this update, feel free to reach 
out to me by mail or irc (xavierb on freenode).


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

Re: libbluray soname bump

[Xavier Bachelot]

oops, with the proper fedora devel mail now...

On 09/03/2017 17:11, Xavier Bachelot wrote:

Hi,

I'm going to update libbluray in rawhide (and f26 as I believe its early
enough in the release cycle) to version 1.0.0, which includes a soname
bump. This is a critical path package.

According to repoquery, the following packages will need to be rebuild :

In Fedora :
- gvfs

In RPM Fusion :
- ffmpeg
- mplayer
- mpv
- vdr-xineliboutput
- vlc
- xine-lib

I can take care of the rebuilds for RPM Fusion, but I don't have enough
privileges to do the same for gvfs in Fedora, so it will need to be
coordinated with gvfs maintainer(s).

RPM Fusion maintainers, let me know if you want me to either take care
of the rebuild or leave it to me.

Shall you have anything to discuss about this update, feel free to reach
out to me by mail or irc (xavierb on freenode).

Regards,
Xavier


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

Re: xpra-codecs-freeworld needs maintainer !

[Xavier Bachelot]

On 17/04/2017 12:44, Xavier Bachelot wrote:
> On 17/04/2017 12:27, Antonio Trande wrote:
>> I take it.
>>
>> On 04/17/2017 12:18 PM, Sérgio Basto wrote:
>>> Hello , 
>>>
>>> https://bugzilla.rpmfusion.org/show_bug.cgi?id=4432
>>>
>>> Since maintainer looks like is unresponsive , I'd add someone as
>>> maintainer of this package. 
>>>
>>> Thanks,
>>>
> I was looking at fixing the broken deps in F25 right now.
> I guess there's no need to duplicate work on this, so here's the work in
> progress patch to update to 1.0 to match f24 and F25, another patch will
> be needed to update to 1.0.2 to match rawhide and f26.
> 
> Regards,
> Xavier
> 
Hi Antonio,

Please take a look at the 3 attached patches.
First two fix both building and deps issue for F25 and f24.
Third update to 1.0.2 for F26 and Rawhide.

It's only compile tested.

Hopefully you weren't already working on this...

Regards,
Xavier

>From a7f27ed212b731ccae0725ee52c5b1ac485ecfc9 Mon Sep 17 00:00:00 2001
From: Xavier Bachelot <xav...@bachelot.org>
Date: Mon, 17 Apr 2017 12:40:16 +0200
Subject: [PATCH 1/3] Update to 1.0 Sync spec with Fedora

---
 xpra-codecs-freeworld.spec | 31 +++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/xpra-codecs-freeworld.spec b/xpra-codecs-freeworld.spec
index b22e8ab..245232a 100644
--- a/xpra-codecs-freeworld.spec
+++ b/xpra-codecs-freeworld.spec
@@ -1,11 +1,11 @@
 Name:   xpra-codecs-freeworld
-Version:0.17.5
-Release:2%{?dist}
+Version:1.0
+Release:1%{?dist}
 Summary:Additional codecs for xpra using x264 and ffmpeg
 
 License:GPLv2+
-URL:http://www.xpra.org/
-Source0:http://xpra.org/src/xpra-%{version}.tar.xz
+URL:https://www.xpra.org/
+Source0:https://xpra.org/src/xpra-%{version}.tar.xz
 
 BuildRequires:  python2-devel pygobject2-devel pygtk2-devel
 BuildRequires:  libXtst-devel
@@ -28,7 +28,7 @@ x264 and ffmpeg.
 
 
 %build
-CFLAGS="%{optflags}" %{__python} setup.py build \
+CFLAGS="%{optflags}" %{__python2} setup.py build \
 --with-enc_x264 \
 --with-dec_avcodec2 \
 --with-csc_swscale \
@@ -37,27 +37,34 @@ CFLAGS="%{optflags}" %{__python} setup.py build \
 
 %install
 mkdir destdir
-%{__python} setup.py install --skip-build --root destdir
+%{__python2} setup.py install \
+--skip-build \
+--root destdir \
+--verbose
 
 mkdir -p %{buildroot}%{python_sitearch}/xpra/codecs/
-pushd destdir%{python_sitearch}/xpra/codecs/
+pushd destdir%{python2_sitearch}/xpra/codecs/
 cp -pr csc_swscale dec_avcodec2 enc_x264 libav_common \
-%{buildroot}%{python_sitearch}/xpra/codecs/
+%{buildroot}%{python2_sitearch}/xpra/codecs/
 popd
 
-#drop shebangs from python_sitearch
-find %{buildroot}%{python_sitearch}/xpra -name '*.py' \
+#drop shebangs from python2_sitearch
+find %{buildroot}%{python2_sitearch}/xpra -name '*.py' \
 -exec sed -i '1{\@^#!/usr/bin/env python@d}' {} \;
 
 #fix permissions on shared objects
-find %{buildroot}%{python_sitearch}/xpra -name '*.so' \
+find %{buildroot}%{python2_sitearch}/xpra -name '*.so' \
 -exec chmod 0755 {} \;
 
 %files
-%{python_sitearch}/xpra/codecs/*
+%{python2_sitearch}/xpra/codecs/*
 %license COPYING
 
 %changelog
+* Mon Apr 17 2017 Xavier Bachelot <xav...@bachelot.org> - 1.0-1
+- Update to 1.0.
+- Sync specfile with Fedora.
+
 * Tue Mar 21 2017 RPM Fusion Release Engineering <kwiz...@rpmfusion.org> - 0.17.5-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
 
-- 
2.9.3

>From 0b8afcb17fb0d23aa0d480b97456afc27d329781 Mon Sep 17 00:00:00 2001
From: Xavier Bachelot <xav...@bachelot.org>
Date: Mon, 17 Apr 2017 22:00:12 +0200
Subject: [PATCH 2/3] Add patch to allow building against ffmpeg 3.1

---
 xpra-1.0-ffmpeg_31.patch   | 25 +
 xpra-codecs-freeworld.spec |  6 ++
 2 files changed, 31 insertions(+)
 create mode 100644 xpra-1.0-ffmpeg_31.patch

diff --git a/xpra-1.0-ffmpeg_31.patch b/xpra-1.0-ffmpeg_31.patch
new file mode 100644
index 000..de11bca
--- /dev/null
+++ b/xpra-1.0-ffmpeg_31.patch
@@ -0,0 +1,25 @@
+diff -Naur xpra-1.0/xpra/codecs/enc_ffmpeg/encoder.pyx xpra-1.0-modified/xpra/codecs/enc_ffmpeg/encoder.pyx
+--- xpra-1.0/xpra/codecs/enc_ffmpeg/encoder.pyx	2016-12-06 11:56:26.0 +0100
 xpra-1.0-modified/xpra/codecs/enc_ffmpeg/encoder.pyx	2017-04-17 21:34:56.279164116 +0200
+@@ -132,10 +132,8 @@
+ int FF_PROFILE_H264_HIGH
+ int FF_PROFILE_H264_HIGH_10
+ int FF_PROFILE_H264_HIGH_10_INTRA
+-int FF_PROFILE_H264_MULTIVIEW_HIGH
+ int FF_PROFILE_H264_HIGH_422
+ int FF_PROFILE_H264_HIGH_422_INTRA
+-int FF_PROFILE_H264_STEREO_HIGH
+ int FF_PROFILE_H264_HIGH_444
+ int FF_PROFILE_H264_HIGH_444_PREDICTIVE
+ int FF_PROFILE_H264_

Re: lame for Fedora

[Xavier Bachelot]

On 03/05/2017 19:53, Sérgio Basto wrote:
> The rules of RPMFusion is move all packages to Fedora when it is
> possible , after be in Fedora we may retire it in Fusion ... 
> So don't see any problem .  
> 
> On Wed, 2017-05-03 at 13:41 -0400, Christian Schaller wrote:
>> Hi Sergio and Nicolas,
>> Red Hat legal has now given the go-ahead for shipping mp3 encoding
>> with Fedora. I noticed you were the last persons to add a changelog
>> entry to the lame package in rpmfusion. Would you be interested in
>> migrating the package to the Fedora repositories? Any other mp3
>> encoding library is also ok to move over now.
>>
>> Sincerely,
>> Christian F.K. Schaller

Beside lame, there are several other packages that could be moved from
RPM Fusion to Fedora proper, as both mp3 decoding and encoding are now
cleared from potential patent issues.

Here's what a quick search gives :

cAudio-freeworld.src : MP3 support for cAudio
lame.src : Free MP3 audio compressor
libmp3splt.src : Libraries for the mp3Splt project
mp3diags.src : Find and fix Problems in MP3 Files
mp3fs.src : FUSE filesystem to transcode FLAC to MP3 on the fly
mp3gain.src : Lossless MP3 volume adjustment tool
mp3splt-gtk.src : Gtk frontend for mp3splt
mp3splt.src : A Free, command-line, AlbumWrap and mp3wrap file exctractor
vdr-mp3.src : Sound playback plugin for VDR

Please note the list is possibly wrong because of dependencies on other
RPM Fusion packages (vdr-mp3 ?) and is also probably missing some
packages, but that should be a good starting point.

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

Re: Introduction and looking for a sponsorship

[Xavier Bachelot]

Hi Robert-André,

Le 19/01/2018 à 15:48, Robert-André Mauchin a écrit :

Hello,

I'm Robert-André, I have been using Fedora and RPMFusion for several years and
I've started contributing as a packager for Fedora in August of last year.
Since then, I have packaged near 50 apps or libraries [1] and reviewed over
1,000 packages [2].


Impressive :-)


I intend to contribute to RPMFusion the same way, I'm looking to package qTox
which depends on FFMPEG, and help reviewing other package (like the Deepin
packages which are waiting, and which I already reviewed Fedora side). Thus I
applied to the Packager group and I'm looking for someone to sponsor me.

The good news is any Fedora packager is automatically granted packager's 
status in RPM Fusion, so you can start submitting packages and doing 
reviews.


Welcome to RPM Fusion !

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