Mailing List Archive

On 16/03/12 12:39, Matt Lewandowsky wrote:
>
> Hi there,
>
> It's been really hard to ignore the numerous threads to this list, the tweets, the forum posts to the various distros' boards, the complaining on various IRC channels, et cetera, regarding the "new" libvpx requirement and the error along the lines of "Requires: libvpx.so.1()(64bit)", usually while installing or updating ffmpeg.
>
> So, I've written up a little guide which should help people confused by what they need to do in order to properly use ffmpeg from ATrpms. :)
>
> The summary of the fix is as follows:
>
> * Enable the atrpms-testing repo.
> * Ensure it has a high priority. (Many people use the priorities yum plugin.)
> * Tell it you only want the libvpx packages.
> * Update your packages.
>
> The advantage of this approach rather than just enabling all of atrpms-testing is that it allows you to follow proper systems administration practices (including making sure that repositories are available for package updates and knowing exactly what is ending up on your system and why).
>
> Without further ado, the (hopefully) all-skill-levels instructions are available at http://www.greenviolet.net/articles/atrpms-ffmpeg-installation-failures-fixed.gv if the summary above wasn't enough to get you on the right path.
>
> The instructions aren't perfect. I know this. They combine "yum best practices" with what's been gleaned from the various atrpms-users threads on the subject, then try to make the result accessible to everyone.
>
> Please feel free to link the page wherever needed. I will update it with whatever is deemed necessary based on feedback. :)
>
> I hope this helps at least one person get out of the perceived dependency hell!
>
> Have fun and be safe,
>
> --Matt Lewandowsky
>

Maybe this is needed, and thank you; but it's my belief that most people
troubled by this are using the RHEL near-clones because they want to get
away from the incessant upgrading imposed by Fedora. They want a system
that delivers good multimedia performance - which AIUI they won't get if
they lock out of 'testing' - and aren't constrained by the need to
maintain a notionally untarnished RHEL-compatible system.
Fedora doesn't provide that, either.

John P


_______________________________________________
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users

On Fri, Mar 16, 2012 at 8:39 AM, Matt Lewandowsky <matt@greenviolet.net> wrote:
>
> Hi there,
>
> It's been really hard to ignore the numerous threads to this list, the tweets, the forum posts to the various distros' boards, the complaining on various IRC channels, et cetera, regarding the "new" libvpx requirement and the error along the lines of "Requires: libvpx.so.1()(64bit)", usually while installing or updating ffmpeg.
>
> So, I've written up a little guide which should help people confused by what they need to do in order to properly use ffmpeg from ATrpms. :)
>
> The summary of the fix is as follows:
>
> * Enable the atrpms-testing repo.
> * Ensure it has a high priority. (Many people use the priorities yum plugin.)
> * Tell it you only want the libvpx packages.
> * Update your packages.
>
> The advantage of this approach rather than just enabling all of atrpms-testing is that it allows you to follow proper systems administration practices (including making sure that repositories are available for package updates and knowing exactly what is ending up on your system and why).
>
> Without further ado, the (hopefully) all-skill-levels instructions are available at http://www.greenviolet.net/articles/atrpms-ffmpeg-installation-failures-fixed.gv if the summary above wasn't enough to get you on the right path.
>
> The instructions aren't perfect. I know this. They combine "yum best practices" with what's been gleaned from the various atrpms-users threads on the subject, then try to make the result accessible to everyone.
>
> Please feel free to link the page wherever needed. I will update it with whatever is deemed necessary based on feedback. :)
>
> I hope this helps at least one person get out of the perceived dependency hell!
>
> Have fun and be safe,
>
> --Matt Lewandowsky
>
> --
> Matt Lewandowsky
> Big Geek
> Greenviolet
> matt@greenviolet.net   http://www.greenviolet.net
> +1 415 578 5782 (US)   +44 844 484 8254 (UK)
>
> _______________________________________________
> atrpms-users mailing list
> atrpms-users@atrpms.net
> http://lists.atrpms.net/mailman/listinfo/atrpms-users

Matt:

Are these instructions for a particular architecture? I'm on Fedora
16 and Fedora 15 at home and these issues were resolved weeks ago. If
you are only talking about CentOS 6, please make that clear so others
aren't confused.

George

_______________________________________________
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users

Date: Fri, 16 Mar 2012 13:35:22 +0000 From: J.Pilk@tesco.net

> Maybe this is needed, and thank you; but it's my belief that most people
> troubled by this are using the RHEL near-clones because they want to get
> away from the incessant upgrading imposed by Fedora. They want a system
> that delivers good multimedia performance - which AIUI they won't get if
> they lock out of 'testing' - and aren't constrained by the need to
> maintain a notionally untarnished RHEL-compatible system.
> Fedora doesn't provide that, either.

One scenario I've seen more than I wish is that web servers are doing random media stuff from PHP scripts, and need ffmpeg for this. :/

If the server is using ATrpms as their choice of ffmpeg provider, they're going to hit this. I've heard more than a few people hit it in recent days, which is what prompted me to write this up.

At the same time, those adminning servers with such a need might not need ffmpeg on every machine. If they're only using ATrpms for ffmpeg and friends, snarfing all of atrpms-testing pulls them into the situation where they have an inconsistent environment and it's bound to bite them one way or another. I'm hoping to save at least one admin a couple of aspirin down the road. ;)

Personally, my opinion is that using any long-term support Linux distro for end-user purposes is an exercise in futility...

--Matt

--
Matt Lewandowsky
Big Geek
Greenviolet
matt@greenviolet.net http://www.greenviolet.net
+1 415 578 5782 (US) +44 844 484 8254 (UK)

Date: Fri, 16 Mar 2012 09:48:17 -0400 From: george.galt@gmail.com

> Are these instructions for a particular architecture? I'm on Fedora
> 16 and Fedora 15 at home and these issues were resolved weeks ago. If
> you are only talking about CentOS 6, please make that clear so others
> aren't confused.

To be honest, I have not run Fedora on any of my own systems, ever, so I can't say anything beyond what is in the first sentence of my link:

"Recently, there has been some gnashing of teeth around the Internet regarding the latest ATrpms build of ffmpeg for RHEL and its clones (including Scientific Linux and CentOS)."

Perhaps I should have been clearer in my post to this list, but it's not entirely clear from the various threads who's affected by this at the moment. It's almost certain that RHEL (and kin) is and will be for quite some time, however. Fedora, by its nature, is far more adaptive.

I apologize for any confusion.

--Matt

--
Matt Lewandowsky
Big Geek
Greenviolet
matt@greenviolet.net   http://www.greenviolet.net
+1 415 578 5782 (US)   +44 844 484 8254 (UK)

_______________________________________________
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users

On Fri, Mar 16, 2012 at 11:02 AM, Matt Lewandowsky <matt@greenviolet.net>wrote:

>
> Date: Fri, 16 Mar 2012 09:48:17 -0400 From: george.galt@gmail.com
>
> > Are these instructions for a particular architecture? I'm on Fedora
> > 16 and Fedora 15 at home and these issues were resolved weeks ago. If
> > you are only talking about CentOS 6, please make that clear so others
> > aren't confused.
>
> To be honest, I have not run Fedora on any of my own systems, ever, so I
> can't say anything beyond what is in the first sentence of my link:
>
> "Recently, there has been some gnashing of teeth around the Internet
> regarding the latest ATrpms build of ffmpeg for RHEL and its clones
> (including Scientific Linux and CentOS)."
>
> Perhaps I should have been clearer in my post to this list, but it's not
> entirely clear from the various threads who's affected by this at the
> moment. It's almost certain that RHEL (and kin) is and will be for quite
> some time, however. Fedora, by its nature, is far more adaptive.
>
> I apologize for any confusion.
>


Fedora is already shipping the appropriate libvpx (1.0). Since Atrpms
rebuilt all
the packages linked against it, Fedora is no longer an issue.

Rhel6, on the other hand, is still shipping livvpx 0.9.0,
which is inadequate for the current version of most multimedia libraries.

My only point here is why livbvpx 1.0, libxcb 1.7, and others need to be
hidden in David Jones' locker?
Most packages will not build or install without them. Therefore, unless
one is "savvy" in ATrpms secrets, the repo may be unusable.

I understand that the Fedora patrol people enjoy beating on packagers
that replace their beloved core packages. However, Rhel without several
improvements is completely pointless from a desktop point of view (as a
server
it is as good as anyone could wish for).

Anyway, I think we need to find a better way to distribute Atrpms packages,
or at least, clearly state what is on testing and what is an absolute
necessary core replacement
package. Maybe some big red letters somewhere is enough ...


--
Paulo Roma Cavalcanti
LCG - UFRJ

Date: Fri, 16 Mar 2012 11:54:22 -0300 From: promac@gmail.com

> Fedora is already shipping the appropriate libvpx (1.0). Since Atrpms rebuilt all
> the packages linked against it, Fedora is no longer an issue.

OK, thanks for clearing that up. :)

> Rhel6, on the other hand, is still shipping livvpx 0.9.0,
>
which is inadequate for the current version of most multimedia libraries.

And being RHEL, it is unlikely to get a useful bump until RHEL 7, for better or for worse.

> My only point here is why livbvpx 1.0, libxcb 1.7, and others need to be hidden in David Jones' locker?
> Most packages will not build or install without them. Therefore, unless
>
one is "savvy" in ATrpms secrets, the repo may be unusable.

I 120% agree here. For most repos (not just RPM-based), "testing" means "Beware all ye who enter here" and not "system overrides".

> I understand that the Fedora patrol people enjoy beating on packagers
> that replace their beloved core packages. However, Rhel without several
>
improvements is completely pointless from a desktop point of view (as a server
> it is as good as anyone could wish for).

To be honest, I don't think just Fedora should be complaining. Any sysadmin with multiple systems who doesn't need the same third-party software on all of them shouldn't be surprised by some of his machines unexpectedly having different versions of base-OS packages.

And, as I noted, ffmpeg is amazingly not-uncommon for creating thumbnails of uploaded videos and such on web servers. And, again, I'll reiterate my opinion that long-term-support distros are a foolish thing to use for generic desktop stuff.

> Anyway, I think we need to find a better way to distribute Atrpms packages,
> or at least, clearly state what is on testing and what is an absolute necessary core replacement
>
package. Maybe some big red letters somewhere is enough ...

The problem with just some big red letters is the extant documentation all over the place (especially in half-competent "tutorials" that inflict nothing but pain on the reader in the long term). Just tracking it all down is likely impossible; getting it all updated is certainly so.

In my mind, the sanest approach is to somehow move the packages that override base-OS stuff from -testing into something else with a reasonable grace period (3 months?) for people to change over. It would, of course, have to somehow be communicated to whoever installs updates on the various systems that use ATrpms (the biggest challenge, in my mind).

During that switchover period, there should be a focus on writing good documentation on how to properly use the (for now, I'll call it) "-override" repo with the various supported distros in various scenarios (server, end-user, etc.). Also, it should make clear which packages are likely to cause "fun" when mixed and matched with other packages from other sources (such as libxcb 1.7).

By having the documentation ready and at a high quality level by the time the switchover completes, I can see ATrpms coming out with a higher-quality reputation due to the transparency. The various user camps (e.g. Fedora, RHEL server, RHEL end-user) will have had adequate chance to provide input and make sure that the situation is as they are comfortable with.

I am, of course, by no means trying to dictate as the sole course forward for ATrpms. :) I've been thinking about it for a bit with this whole libvpx thing and how to make it better, and this seems doable and low-impact. With the information that Fedora has "special needs" (in comparison to RHEL installations, my point of view is skewed toward server use), this really does seem like a sane way forward that would make everyone happy without as much chance of a repeat of this confusion once the transition period is over.

If nothing else, I hope that I'm adding constructiveness to this, considering I'm pretty much an unknown on this list.

--Matt


--
Matt Lewandowsky
Big Geek
Greenviolet
matt@greenviolet.net http://www.greenviolet.net
+1 415 578 5782 (US) +44 844 484 8254 (UK)

On Fri, 16 Mar 2012, Matt Lewandowsky wrote:

> Personally, my opinion is that using any long-term support Linux
> distro for end-user purposes is an exercise in futility...

Just for the record, I'm one who pursues that futility, adamantly
running CentOS 6 on my production purposed laptop. It will stay until
the hardware fails or I simply can't use it for my primary work of
writing.

Further, I heartily recommend this sort of thing to anyone who isn't a
typical Linux user. That is, everyone I help migrate from some other OS
is unlikely to ever appreciate what your stated opinion takes for
granted. I'm willing to bet you'd be surprised how many folks insist on
using long life distros on the desktop simply because they have
long-term support.

Even with the current difficulty, I think it's still quite manageable
and I'm still a big fan of ATrmps, and I very much appreciate the
offered tutorial.

Ed Hurst
--------
Open for Business - http://ofb.biz/
Kiln of the Soul - http://soulkiln.org/
blog - http://soulkiln.myopera.com/

_______________________________________________
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users

From an end user perspective, this sounds like a good idea, but right now
AtRPMS is a one-man-show when it comes to build, createrepo, push, etc.
I've been chatting with Axel on and off about delegating some of those
responsibilities such that when he needs to step away the repos continue
getting updates. We've not gotten past the chatting phase, but if anyone
else is willing to help, that would be nice. :)

Having said that, a fourth repo like centosplus (atrpms-plus?) probably
makes sense especially for the EL-based repos for libvpx, QT, etc. which
are required to get MythTV working but are not "testing", they're fairly
stable.

http://wiki.centos.org/AdditionalResources/Repositories

/Brian/

On Fri, Mar 16, 2012 at 11:45 AM, Matt Lewandowsky <matt@greenviolet.net>wrote:

> Date: Fri, 16 Mar 2012 11:54:22 -0300 From: promac@gmail.com
>
> > Fedora is already shipping the appropriate libvpx (1.0). Since Atrpms
> rebuilt all
> > the packages linked against it, Fedora is no longer an issue.
>
> OK, thanks for clearing that up. :)
>
>
> > Rhel6, on the other hand, is still shipping livvpx 0.9.0,
> > which is inadequate for the current version of most multimedia libraries.
>
> And being RHEL, it is unlikely to get a useful bump until RHEL 7, for
> better or for worse.
>
>
> > My only point here is why livbvpx 1.0, libxcb 1.7, and others need to be
> hidden in David Jones' locker?
> > Most packages will not build or install without them. Therefore, unless
> > one is "savvy" in ATrpms secrets, the repo may be unusable.
>
> I 120% agree here. For most repos (not just RPM-based), "testing" means
> "Beware all ye who enter here" and not "system overrides".
>
>
> > I understand that the Fedora patrol people enjoy beating on packagers
> > that replace their beloved core packages. However, Rhel without several
> > improvements is completely pointless from a desktop point of view (as a
> server
> > it is as good as anyone could wish for).
>
> To be honest, I don't think just Fedora should be complaining. Any
> sysadmin with multiple systems who doesn't need the same third-party
> software on all of them shouldn't be surprised by some of his machines
> unexpectedly having different versions of base-OS packages.
>
> And, as I noted, ffmpeg is amazingly not-uncommon for creating thumbnails
> of uploaded videos and such on web servers. And, again, I'll reiterate my
> opinion that long-term-support distros are a foolish thing to use for
> generic desktop stuff.
>
>
> > Anyway, I think we need to find a better way to distribute Atrpms
> packages,
> > or at least, clearly state what is on testing and what is an absolute
> necessary core replacement
> > package. Maybe some big red letters somewhere is enough ...
>
> The problem with just some big red letters is the extant documentation all
> over the place (especially in half-competent "tutorials" that inflict
> nothing but pain on the reader in the long term). Just tracking it all down
> is likely impossible; getting it all updated is certainly so.
>
> In my mind, the sanest approach is to somehow move the packages that
> override base-OS stuff from -testing into something else with a reasonable
> grace period (3 months?) for people to change over. It would, of course,
> have to somehow be communicated to whoever installs updates on the various
> systems that use ATrpms (the biggest challenge, in my mind).
>
> During that switchover period, there should be a focus on writing good
> documentation on how to properly use the (for now, I'll call it)
> "-override" repo with the various supported distros in various scenarios
> (server, end-user, etc.). Also, it should make clear which packages are
> likely to cause "fun" when mixed and matched with other packages from other
> sources (such as libxcb 1.7).
>
> By having the documentation ready and at a high quality level by the time
> the switchover completes, I can see ATrpms coming out with a higher-quality
> reputation due to the transparency. The various user camps (e.g. Fedora,
> RHEL server, RHEL end-user) will have had adequate chance to provide input
> and make sure that the situation is as they are comfortable with.
>
> I am, of course, by no means trying to dictate as the sole course forward
> for ATrpms. :) I've been thinking about it for a bit with this whole libvpx
> thing and how to make it better, and this seems doable and low-impact. With
> the information that Fedora has "special needs" (in comparison to RHEL
> installations, my point of view is skewed toward server use), this really
> does seem like a sane way forward that would make everyone happy without as
> much chance of a repeat of this confusion once the transition period is
> over.
>
> If nothing else, I hope that I'm adding constructiveness to this,
> considering I'm pretty much an unknown on this list.
>
>
> --Matt
>
>
> --
> Matt Lewandowsky
> Big Geek
> Greenviolet
> matt@greenviolet.net http://www.greenviolet.net
> +1 415 578 5782 (US) +44 844 484 8254 (UK)
>
> _______________________________________________
> atrpms-users mailing list
> atrpms-users@atrpms.net
> http://lists.atrpms.net/mailman/listinfo/atrpms-users
>

Hi Matt,

thanks for the docu, which BTW you can also place on atrpms.net itself
- it is a worspress installation intended for people to place docu on
it.

On Fri, Mar 16, 2012 at 06:55:28AM -0700, Matt Lewandowsky wrote:
> At the same time, those adminning servers with such a need might
> not need ffmpeg on every machine. If they're only using ATrpms for
> ffmpeg and friends, snarfing all of atrpms-testing pulls them into
> the situation where they have an inconsistent environment and it's
> bound to bite them one way or another. I'm hoping to save at least
> one admin a couple of aspirin down the road. ;)

Well, I'd like to point out once again that while it sound scary
"atrpms-testing for RHEL" really means "solid packages that reaplce
RHEL packages". There is no instability or inconsistency couple with
these packages. But years ago there were people complaining about
placing these into atrpms proper and so they ended up in the
deactivated repo.

A bad name for a repo? In this case very much.
--
Axel.Thimm at ATrpms.net

_______________________________________________
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users

On Fri, Mar 16, 2012 at 07:02:53AM -0700, Matt Lewandowsky wrote:
>
> Date: Fri, 16 Mar 2012 09:48:17 -0400 From: george.galt@gmail.com
>
> > Are these instructions for a particular architecture? I'm on Fedora
> > 16 and Fedora 15 at home and these issues were resolved weeks ago. If
> > you are only talking about CentOS 6, please make that clear so others
> > aren't confused.
>
> To be honest, I have not run Fedora on any of my own systems, ever,
> so I can't say anything beyond what is in the first sentence of my
> link:

> "Recently, there has been some gnashing of teeth around the
> Internet regarding the latest ATrpms build of ffmpeg for RHEL and its
> clones (including Scientific Linux and CentOS)."

The final trigger for updating libvpx was actually the breakage that
was coming for the update in Fedora. libvpx was alteady in Fedora
testing and I managed to update libvpx only "seconds" before it moved
out libvpx.so.0.
--
Axel.Thimm at ATrpms.net

_______________________________________________
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users

On Fri, Mar 16, 2012 at 11:54:22AM -0300, Paulo Cavalcanti wrote:
> My only point here is why livbvpx 1.0, libxcb 1.7, and others need to be
> hidden in David Jones' locker?
> Most packages will not build or install without them. Therefore, unless
> one is "savvy" in ATrpms secrets, the repo may be unusable.
>
> I understand that the Fedora patrol people enjoy beating on packagers
> that replace their beloved core packages. However, Rhel without several
> improvements is completely pointless from a desktop point of view (as a
> server
> it is as good as anyone could wish for).

The people complaining about package replacement are (or were) indeed
from the Fedora camp. And perhaps the arguments were used to put forth
other repos or for other political games. But if there is a real need
for stability that may be jeopardized by replacing packages it is in
the Enterprise sector.

This is why back then we said to make sure "atrpms" proper is not
replacing RHEL packages.

> Anyway, I think we need to find a better way to distribute Atrpms packages,
> or at least, clearly state what is on testing and what is an absolute
> necessary core replacement
> package. Maybe some big red letters somewhere is enough ...

The repos need a restucturing which offering different contents. Maybe
"atrpms" continues to function as until now and other names (other
than "testing") can be used for various collections that can even
replace upstream packages (like "atrpms-media" for example).
--
Axel.Thimm at ATrpms.net

_______________________________________________
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users

Hi,

On Fri, Mar 16, 2012 at 12:17:58PM -0400, Brian Long wrote:
> >From an end user perspective, this sounds like a good idea, but right now
> AtRPMS is a one-man-show when it comes to build, createrepo, push, etc.
> I've been chatting with Axel on and off about delegating some of those
> responsibilities such that when he needs to step away the repos continue
> getting updates. We've not gotten past the chatting phase, but if anyone
> else is willing to help, that would be nice. :)

That's an important topic by itself, but probably orthogonal to what
we are discussing here.

I don't mind changing policies based on some majority opinion from the
community - after all I started this repo as an offering to the
community. :)

> Having said that, a fourth repo like centosplus (atrpms-plus?) probably
> makes sense especially for the EL-based repos for libvpx, QT, etc. which
> are required to get MythTV working but are not "testing", they're fairly
> stable.

If we decide that atrpms-testing should fork into a real testing repo
and "atrpms-extra/plus/media/anything" or any other structure, I'm all
for it.

For the direct access to the build system instead of the "triggering
the human batch processor" we should have a different thread - and
most probably on atrpms-devel as the people interested on getting a
better build infrastruture are probably lurking there more than on the
users list.
--
Axel.Thimm at ATrpms.net

_______________________________________________
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users

On 3/17/2012 12:02 PM, Axel Thimm wrote:
> The repos need a restucturing which offering different contents. Maybe
> "atrpms" continues to function as until now and other names (other
> than "testing") can be used for various collections that can even
> replace upstream packages (like "atrpms-media" for example).

I just want to say thanks Axel for making MythTV workable on RHEL and my
chosen distro, CentOS. Without your great resource it would be a *much*
more difficult process.

Many thanks.

_______________________________________________
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users