(1) I expect now patches from you to make a workable audacious based on our audacious package. Apparently you have the interest and the time to do it ?
RF's audacious has unmet dependencies. It's as simple as that. It lacks audacious-plugins.
(2) No, they are not compatible, we know. Share to help with this too ? You first have to convince the Fedora people that they will not introduce new incompatibilities before starting.
Nay. Please read again how my tiny repo tries to "fix/hack" the 4 libs from EPEL that break RF's MPlayer and VLC.
Should the Fedora people be insensitive, what prevents you from just "suck in" the newer libdvdread, libdvdnav, libcaca and lzo from EPEL and just rebuild RF's VLC and MPlayer?
Because, honestly, a good deal of people only need the MPlayer+VLC+gstream stuff from RF. My understanding is that RF is so huge that it's very hard to manage, but... I'm afraid I have to say it's quite a "static" repo which doesn't try to rebuild anything!
Shall I simply stop doing RPMforge ?
Hopefully not, *but* how about 400 rock-solid packages in RF instead of 8,000 packages with: some abandoned; some broken; etc.?
Is that the position you prefer to force me into ? Because I certainly did not force you into using the repository.
Nobody is trying to force anyone into anything. It just happens that your repo is the only one to offer VLC, for instance. And I personally needed a quick & dirty hack to accommodate RF with EPEL. That's all.
I don't know even why you want to use RPMforge, there must be something that is missing from EPEL ?
Yes. Let me state again: yum --enablerepo=rpmforge install gstreamer-plugins-bad gstreamer-plugins-ugly gstreamer-ffmpeg yum --enablerepo=rpmforge install mplayer mplayer-fonts mplayer-skins mplayerplug-in smplayer yum --enablerepo=rpmforge install vlc
That's all I need from VLC. Dozens of multimedia dependent packages though. Some of them legally unsuitable for EPEL.
And RPM Fusion doesn't even have VLC.
I am happy to learn what you want to do though, because it is easy to criticize, but it takes time to do some work.
I know, and I understand that you are now vexed, but, like I said: instead of 8,000 packages in RF, better have 400 rock-solid ones?
(And I hope the solution is not another repository, because we have been there :-))
The solution is *always* another repo. Why do you believe there are so many Linux distros? Are they really NEEDED? Nope. They're more than 3-4 distros because people can NOT cooperate properly, and their quick fix is to fork and whatnot.
Cheers, R-C
__________________________________________________________________ Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php
On Jun 29, 2009, at 4:42 PM, Radu-Cristian FOTESCU wrote:
I know, and I understand that you are now vexed, but, like I said: instead of 8,000 packages in RF, better have 400 rock-solid ones?
i look to rpmforge for a wide variety of packages, none of which have anything to do with mplayer, VLC or media of any sort. i look forward with keen anticipation to the announcement that all the other packages i don't care about will be dropped in order to better focus scarce developer time and energy on the packages i do care about (in the interest of improving the quality of the repository, of course) :)
seriously, if the fix is so easy, why not just submit the patch?
-steve
-- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v http://five.sentenc.es
On Mon, 29 Jun 2009, Radu-Cristian FOTESCU wrote:
(1) I expect now patches from you to make a workable audacious based on our audacious package. Apparently you have the interest and the time to do it ?
RF's audacious has unmet dependencies. It's as simple as that. It lacks audacious-plugins.
I am still waiting for it. I am willing to give you commit access to fix all the things that irritate you. I offered the same to others.
If you wonder why I did not fix it myself, because I lack the time and interest to fix it. It was maintained by matthias in the past, and he left. I could remove the packages, but that would not help.
At least now if someone wants to install it, they can see it does not work and may offer a fix. Nobody did until now, maybe you can change it.
If not, no harm done, it stays the same until I find the time and nothing else to do. Which will not happen very soon though.
Believe me, I am not sitting here waiting for a new task to complete. But if someone else has some time to help I can give you the authority to fix it and you get my respect for it too :)
(2) No, they are not compatible, we know. Share to help with this too ? You first have to convince the Fedora people that they will not introduce new incompatibilities before starting.
Nay. Please read again how my tiny repo tries to "fix/hack" the 4 libs from EPEL that break RF's MPlayer and VLC.
Should the Fedora people be insensitive, what prevents you from just "suck in" the newer libdvdread, libdvdnav, libcaca and lzo from EPEL and just rebuild RF's VLC and MPlayer?
I recommend you to go and try do it and see how much else depends on these and what no longer builds because of it and how much time you end up spending for something that doesn't do more than before eventually if you make it work.
Should I rebuild it just because EPEL upgraded their libraries ? Will EPEL fix the compatibility with the clamav package, a conflict they introduced ?
Because, honestly, a good deal of people only need the MPlayer+VLC+gstream stuff from RF. My understanding is that RF is so huge that it's very hard to manage, but... I'm afraid I have to say it's quite a "static" repo which doesn't try to rebuild anything!
RPMforge has about 20 to 30 new commits every week, and we do update lots of packages regularly. The hard ones we may not do unless there is a compelling reason and it still compiles against older distributions.
Again, I wouldn't mind if you send me patches to update something, but believe me it is more than a simple update of the version. An automated buildsystem that would rebuild all dependencies would be great, I don't have it though.
Shall I simply stop doing RPMforge ?
Hopefully not, *but* how about 400 rock-solid packages in RF instead of 8,000 packages with: some abandoned; some broken; etc.?
We have those 400 rock solid packages, even more than that. I'd say less than 5% are in a bad shape. And audacious is probaby one of the more visible ones. But again, why do you expect me to fix them, when you have a need for it ?
What is the difference between a package that cannot be installed, and a package that is not available ?
The first is easier to fix than the second. The problem is that nobody offered a fix. Everyone expects it to be fixed.
Is that the position you prefer to force me into ? Because I certainly did not force you into using the repository.
Nobody is trying to force anyone into anything. It just happens that your repo is the only one to offer VLC, for instance. And I personally needed a quick & dirty hack to accommodate RF with EPEL. That's all.
Fine, but then stop demanding something to be fixed, because you're talking about the little free time I have. Send me a fix, or even better offer to fix it yourself.
I don't know even why you want to use RPMforge, there must be something that is missing from EPEL ?
Yes. Let me state again: yum --enablerepo=rpmforge install gstreamer-plugins-bad gstreamer-plugins-ugly gstreamer-ffmpeg yum --enablerepo=rpmforge install mplayer mplayer-fonts mplayer-skins mplayerplug-in smplayer yum --enablerepo=rpmforge install vlc
That's all I need from VLC. Dozens of multimedia dependent packages though. Some of them legally unsuitable for EPEL.
And RPM Fusion doesn't even have VLC.
Then do something about it. Instead of a consumer (and complainer), become a producer (and contributor).
I am happy to learn what you want to do though, because it is easy to criticize, but it takes time to do some work.
I know, and I understand that you are now vexed, but, like I said: instead of 8,000 packages in RF, better have 400 rock-solid ones?
We have maybe 7600 solid ones (in fact I don't think we have 8000 packages).
(And I hope the solution is not another repository, because we have been there :-))
The solution is *always* another repo. Why do you believe there are so many Linux distros? Are they really NEEDED? Nope. They're more than 3-4 distros because people can NOT cooperate properly, and their quick fix is to fork and whatnot.
The difference is that you can only install one distribution, but you can install tons of incompatible repositories.
And the believe that one repo will rule them all (which is what Fedora and EPEL wants you to believe) is just debunked by yourself above :-)
The most important reason I still have RPMforge is because I don't want to let my users down because there is no real upgrade path (the fact that you for some reason need RPMforge is the proof).
If the last user wants to turn off the light, then I know I can start doing something else ;-)
PS To be honest, we could use some more people that want to help, if something is missing or not being maintained, offer to maintain it ! But don't expect me (or dries, christoph, fabian, ...) to fix it because that simply *does* *not* *scale*.
PS2 I discussed with christoph to set up a proper project management system that would encourage collaboration more. But we don't need more bugs, we need more people to help fix bugs, really.
Dag Wieers napsal(a):
The difference is that you can only install one distribution, but you can install tons of incompatible repositories.
And the believe that one repo will rule them all (which is what Fedora and EPEL wants you to believe) is just debunked by yourself above :-)
The most important reason I still have RPMforge is because I don't want to let my users down because there is no real upgrade path (the fact that you for some reason need RPMforge is the proof).
If the last user wants to turn off the light, then I know I can start doing something else ;-)
PS To be honest, we could use some more people that want to help, if something is missing or not being maintained, offer to maintain it ! But don't expect me (or dries, christoph, fabian, ...) to fix it because that simply *does* *not* *scale*.
PS2 I discussed with christoph to set up a proper project management system that would encourage collaboration more. But we don't need more bugs, we need more people to help fix bugs, really.
I'd like to say this. Dag et al have done wonderful job and I thank you for it Dag. But we (the community, fellow I know, myself) have been wanting and willing to cooperate on much huge basis, I personally feel this way. I'm talking about rpmrepo.org project. I guess Dag's interest in this project was driven by the problems with his repo too which some of you are complaining about. The aim was to create platform, not strictly focused on enterprise. We wanted create something mixed. Something with enterprise, testing, backport levels and efforts. The project has been started but never really haven't happened.
So we have centosplus and extras which are the repos with "access denied" for packages inclusion. Dag's rpmforge which is so huge with a lot of dependencies not suitable for "testing/bleeding edge/alternative" packages. So what's the suitable repo? That's why people are going to run own repos.... :o( I do it myself.
I guess we need suitable platform we can use within the centos community and we need it now. Regards, David Hrbáč
The aim was to create platform, not strictly focused on enterprise. We wanted create something mixed. Something with enterprise, testing, backport levels and efforts. The project has been started but never really haven't happened.
I'll go on the record as being willing to volunteer to help with a distribution/version neutral repo. Such a thing would benefit my business. Is anyone currently leading this project?
--------------------------------- Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/
On 30 Jun 2009, at 9:46 AM, Geoff Galitz wrote:
The aim was to create platform, not strictly focused on enterprise. We wanted create something mixed. Something with enterprise, testing, backport levels and efforts. The project has been started but never really haven't happened.
I'll go on the record as being willing to volunteer to help with a distribution/version neutral repo. Such a thing would benefit my business. Is anyone currently leading this project?
I am willing to help too, the problems is the barriers to entry on the Centos side seem quite high, there is no published guidelines on how to contribute.
On the Fedora/EPEL side how ever there are published guidelines and mechanisms to allow people who want to contribute to get in.
Anyway thats my too cents.
Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Geoff Galitz napsal(a):
I'll go on the record as being willing to volunteer to help with a distribution/version neutral repo. Such a thing would benefit my business. Is anyone currently leading this project?
The "project" is to be found here http://rpmrepo.org/ I guess there's no leadership right now. David
On 06/30/2009 11:03 AM, David Hrbác( wrote:
The "project" is to be found here http://rpmrepo.org/ I guess there's no leadership right now.
rpmrepo.org suffered from a too-many-cooks and everyone wanting to workout what the other guys were upto before deciding to do much - there were a few exceptions to that - but in a nutshell, things didnt move, at all.
I would whole heartedly recommend that if there is an interest in getting rpmrepo off the ground, lets converge in the mailing list there http://rpmrepo.org/mailman/listinfo/rpmrepo-devel and see if we can get it off the ground, once again.
- KB
Geoff Galitz wrote:
The aim was to create platform, not strictly focused on enterprise. We wanted create something mixed. Something with enterprise, testing, backport levels and efforts. The project has been started but never really haven't happened.
I'll go on the record as being willing to volunteer to help with a distribution/version neutral repo. Such a thing would benefit my business. Is anyone currently leading this project?
Geoff Galitz Blankenheim NRW, Germany http://www.galitz.org/ http://german-way.com/blog/
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
rpmforge..:)
On Tue, 30 Jun 2009, David Hrbáč wrote:
Dag Wieers napsal(a):
The difference is that you can only install one distribution, but you can install tons of incompatible repositories.
And the believe that one repo will rule them all (which is what Fedora and EPEL wants you to believe) is just debunked by yourself above :-)
The most important reason I still have RPMforge is because I don't want to let my users down because there is no real upgrade path (the fact that you for some reason need RPMforge is the proof).
If the last user wants to turn off the light, then I know I can start doing something else ;-)
PS To be honest, we could use some more people that want to help, if something is missing or not being maintained, offer to maintain it ! But don't expect me (or dries, christoph, fabian, ...) to fix it because that simply *does* *not* *scale*.
PS2 I discussed with christoph to set up a proper project management system that would encourage collaboration more. But we don't need more bugs, we need more people to help fix bugs, really.
I'd like to say this. Dag et al have done wonderful job and I thank you for it Dag. But we (the community, fellow I know, myself) have been wanting and willing to cooperate on much huge basis, I personally feel this way. I'm talking about rpmrepo.org project. I guess Dag's interest in this project was driven by the problems with his repo too which some of you are complaining about. The aim was to create platform, not strictly focused on enterprise. We wanted create something mixed. Something with enterprise, testing, backport levels and efforts. The project has been started but never really haven't happened.
Yes, I feel not happy about it.
So we have centosplus and extras which are the repos with "access denied" for packages inclusion. Dag's rpmforge which is so huge with a lot of dependencies not suitable for "testing/bleeding edge/alternative" packages. So what's the suitable repo? That's why people are going to run own repos.... :o( I do it myself.
I guess we need suitable platform we can use within the centos community and we need it now.
The biggest problem for me is that we do not have the infrastructure in RPMforge. I still need to build the x86 and x86_64 stuff, Fabian does the PPC packages.
Various people maintain SPEC files and contribute changes. But they only get pushed when Fabian or me initiate it. I don't want to sit in the middle, but without setting up new infrastructure and processes we'll continue to use what works now.
It's not optimal, but it works.
And we know about things that can be improved, but without people helping with QA and automate reporting problems, we just continue the way it is.
Dag Wieers napsal(a):
The biggest problem for me is that we do not have the infrastructure in RPMforge. I still need to build the x86 and x86_64 stuff, Fabian does the PPC packages.
Yes, "we" don't. As for me, there's no time and need to reinvent the wheel. There are many etalons to look at (Suse builder, fedora infrastructure).
Various people maintain SPEC files and contribute changes. But they only get pushed when Fabian or me initiate it. I don't want to sit in the middle, but without setting up new infrastructure and processes we'll continue to use what works now.
I can't see any easy way to change the state too.
It's not optimal, but it works.
And we know about things that can be improved, but without people helping with QA and automate reporting problems, we just continue the way it is.
Yes, it works and it works for me too. But everyday praxis shows that it 's been overcome. David
-
Andrew Colin Kissa -
Dag Wieers -
David Hrbác( -
David Hrbáč
-
Geoff Galitz -
Karanbir Singh -
Radu-Cristian FOTESCU -
Steve Huff -
William Warren