The Dribble, Freshrpms and Livna teams, already joined by some Fedora contributors, are proud to announce the RPM Fusion project.
RPM Fusion aims to bring together many packagers from various 3rd party repos and build a single add-on repository for Fedora and Red Hat Enterprise Linux.
We don't have a repository ready for end users yet, but we are actively working on merging the following ones:
* http://dribble.org.uk/ * http://freshrpms.net/ * http://rpm.livna.org/
We will have two distinct repositories: free and non-free. Free will contain Open Source Software (as defined by the Fedora Packaging Guidelines) which can't be included in Fedora -- for example because it might be patent encumbered in the US. Non-free will contain everything else which is not free software (as defined by the Fedora Licensing Guidelines), like software with public available source-code that has "no commercial use" restrictions or the graphics drivers from AMD and Nvidia.
Repositories and infrastructure will follow Fedora where possible. This means using Fedora's packaging guidelines (except for legal), Fedora's review process for new submissions, Fedora's VCS structure etc.
It will contain add-on packages and not replacements in relation to the base package set. Whereby the base package set is defined as: RHEL/CentOS + EPEL or Fedora (Fedora 7+).
It will contain kernel module packages in the main repo, even if Fedora will drop them (which looks likely as of August 2007).
We aim to provide support for all 'current' versions of Fedora including devel, for i386, ppc, ppc64 and x86_64.
We hope to attract new Fedora packagers and many other 3rd party repositories.
Please join our mailing list at: http://lists.fedoraunity.org/mailman/listinfo/repo-merge-discussion
Hans de Goede wrote:
The Dribble, Freshrpms and Livna teams, already joined by some Fedora contributors, are proud to announce the RPM Fusion project.
RPM Fusion aims to bring together many packagers from various 3rd party repos and build a single add-on repository for Fedora and Red Hat Enterprise Linux.
We don't have a repository ready for end users yet, but we are actively working on merging the following ones:
* http://dribble.org.uk/ * http://freshrpms.net/ * http://rpm.livna.org/
Though not within the Fedora official structure, merging these throws away one of the major points for end users in Fedora. Congrats on this effort. Noticeably missing is ATrpms however.
We will have two distinct repositories: free and non-free. Free will contain Open Source Software (as defined by the Fedora Packaging Guidelines) which can't be included in Fedora -- for example because it might be patent encumbered in the US. Non-free will contain everything else which is not free software (as defined by the Fedora Licensing Guidelines), like software with public available source-code that has "no commercial use" restrictions or the graphics drivers from AMD and Nvidia.
Thanks for this split. Hopefully we will able to link to the free part from within Fedora.
Rahul
Rahul Sundaram wrote:
Hans de Goede wrote:
We don't have a repository ready for end users yet, but we are actively working on merging the following ones:
* http://dribble.org.uk/ * http://freshrpms.net/ * http://rpm.livna.org/Noticeably missing is ATrpms however.
ATrpms (Axel) has been involved in the merger talks from day one, unfortunately we (rpmfusion and atrpms) couldn't come to terms and have each gone our seperate ways (as good friends), but who knows what the future will bring.
Regards,
Hans
Hans de Goede wrote:
Rahul Sundaram wrote:
Hans de Goede wrote:
We don't have a repository ready for end users yet, but we are actively working on merging the following ones:
* http://dribble.org.uk/ * http://freshrpms.net/ * http://rpm.livna.org/Noticeably missing is ATrpms however.
ATrpms (Axel) has been involved in the merger talks from day one, unfortunately we (rpmfusion and atrpms) couldn't come to terms and have each gone our seperate ways (as good friends), but who knows what the future will bring.
Regards,
Hans
Great work Hans, this is really a big step forward to making it easier for Fedora user to get those apps that we don't ship in Fedora itself.
Read ya, Phil
On Tue, 2007-09-11 at 09:16 +0200, Hans de Goede wrote:
ATrpms (Axel) has been involved in the merger talks from day one, unfortunately we (rpmfusion and atrpms) couldn't come to terms and have each gone our seperate ways (as good friends), but who knows what the future will bring.
Hopefully the two repos can at least coordinate enough that they don't step on each other. I'm sure everyone has had the frustration with apps such as mplayer that are in multiple repos, all packaged differently, and all updated at different times so you wind up with crazy dependency issues preventing regular updates and such.
Great work Hans, this is really a big step forward to making it easier for Fedora user to get those apps that we don't ship in Fedora itself.
Yes, +1 to that.
Also, +1 to the fact its not as good a news as if ATrpms had also been incorporated. If rpmfusion and ATrpms turn out as (in)compatible as say livna and ATrpms are now, then on a practical level the merger is no where near as useful as it could have been.
Heres hoping you iron out your differences in the future sometime.
Chris
On Tue, 2007-09-11 at 09:16 +0200, Hans de Goede wrote:
ATrpms (Axel) has been involved in the merger talks from day one, unfortunately we (rpmfusion and atrpms) couldn't come to terms and have each gone our seperate ways (as good friends), but who knows what the future will bring.
Is the discussion of the issues related to integration available on some public archive somewhere? I've been following developments on ATRPMs for a while now and have to say that there are a lot of great and elegant stuff in their system. I would love to see a concerted effort. I would REALLY hate to give up one for another. Right now, I'm balancing livna and ATRMS with repo-specific "exclude"s MANUALLY. Not fun for me, and probably not within the capability of many a user. --
Richi Plana
On 9/11/07, Hans de Goede j.w.r.degoede@hhs.nl wrote:
Rahul Sundaram wrote:
Hans de Goede wrote:
We don't have a repository ready for end users yet, but we are actively working on merging the following ones:
* http://dribble.org.uk/ * http://freshrpms.net/ * http://rpm.livna.org/Noticeably missing is ATrpms however.
ATrpms (Axel) has been involved in the merger talks from day one, unfortunately we (rpmfusion and atrpms) couldn't come to terms and have each gone our seperate ways (as good friends), but who knows what the future will bring.
didnt his leaving have something to do with no enterprise linux support? supporting enterprise linux is in the future plans for rpmfusion, correct?
On 9/11/07, Richi Plana myfedora@richip.dhs.org wrote:
On Tue, 2007-09-11 at 09:16 +0200, Hans de Goede wrote:
ATrpms (Axel) has been involved in the merger talks from day one, unfortunately we (rpmfusion and atrpms) couldn't come to terms and have each gone our seperate ways (as good friends), but who knows what the future will bring.
Is the discussion of the issues related to integration available on some public archive somewhere? I've been following developments on ATRPMs for a while now and have to say that there are a lot of great and elegant stuff in their system. I would love to see a concerted effort. I would REALLY hate to give up one for another. Right now, I'm balancing livna and ATRMS with repo-specific "exclude"s MANUALLY. Not fun for me, and probably not within the capability of many a user.
Ah I remember now, I wont comment on what Axel wrote, instead I'll just say come to your own conclusions:
http://lists.fedoraunity.org/pipermail/repo-merge-discussion/2007-May/000137...
architecture. And it seems..lame...to me to have a multimedia application can't detect new codecs on the system at runtime.
You owe me a new keyboard. :)P
-jef
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Hi,
Tuesday 11 of September 2007 08:38:19 Hans de Goede napisał(a):
RPM Fusion aims to bring together many packagers from various 3rd party repos and build a single add-on repository for Fedora and Red Hat Enterprise Linux.
great,
It will contain add-on packages and not replacements in relation to the base package set. Whereby the base package set is defined as: RHEL/CentOS + EPEL or Fedora (Fedora 7+).
hmmm.... I'm not sure I understand it correctly... let's have an example.
Fedora doesn't have 'lame'. RPM Fusion will have 'lame', right? But You will _not_ rebuild k3b with lame support, because You don't want to replace "base" package set (k3b is in base). Right?
Another example: inclusion of mp3 support libraries, but without rebuilding audio players.
If this is the case, wouldn't such a repo be useless?
regards,
PS. Please clarify this if I misunderstood the point.
On Tue, 11 Sep 2007 20:03:51 +0200 Jaroslaw Gorny jaroslav@aster.pl wrote:
Another example: inclusion of mp3 support libraries, but without rebuilding audio players.
If this is the case, wouldn't such a repo be useless?
With things like gstreamer you don't have to rebuild audio apps. gstreamer plugins will plug into the base gstreamer framework and audio apps just make use of whatever plugins are available.
On 9/11/07, Jaroslaw Gorny jaroslav@aster.pl wrote:
Another example: inclusion of mp3 support libraries, but without rebuilding audio players.
If this is the case, wouldn't such a repo be useless?
not for audio applications which are smart enough to know how to do detect availability of optional libraries at runtime or use a plugin architecture. And it seems..lame...to me to have a multimedia application can't detect new codecs on the system at runtime.
-jef
On Tue, 2007-09-11 at 10:09 -0800, Jeff Spaleta wrote:
On 9/11/07, Jaroslaw Gorny jaroslav@aster.pl wrote:
Another example: inclusion of mp3 support libraries, but without rebuilding audio players.
If this is the case, wouldn't such a repo be useless?
not for audio applications which are smart enough to know how to do detect availability of optional libraries at runtime or use a plugin architecture. And it seems..lame...to me to have a multimedia application can't detect new codecs on the system at runtime.
-2 points from Jef for that pun.
-sv
Tuesday 11 of September 2007 20:09:16 Jeff Spaleta napisał(a):
On 9/11/07, Jaroslaw Gorny jaroslav@aster.pl wrote:
Another example: inclusion of mp3 support libraries, but without rebuilding audio players.
If this is the case, wouldn't such a repo be useless?
not for audio applications which are smart enough to know how to do detect availability of optional libraries at runtime or use a plugin architecture. And it seems..lame...to me to have a multimedia application can't detect new codecs on the system at runtime.
Are they lame or not, it's not my point here. They are in distro, so maybe they're not so lame after all. Simple kde player included in kdemultimedia-extras (noatun) won't handle mp3 without rebuild. And this is the default player in KDE. If somebody just downloads mp3 file and clicks it - noatun starts and stops immediately. It can be frustrating for user to download all 'fusion' packages responsible for mp3 handling, and still not being able to play a file.
K3b is in distro too. Although I have libmad installed (freshrpms), k3b complains that no support for mp3 decoding can be found. So I guess, k3b should be rebuilt with libmad-devel in order to use this feature.
But these are only examples - maybe not the lucky ones. What I'm asking for is a general 'rule':
We provide foo-lib. There's some package that can be rebuilt with foo-lib and gain some extra features, but we don't do this. Is it really the best solution?
regards,
On 11/09/2007, Hans de Goede j.w.r.degoede@hhs.nl wrote:
The Dribble, Freshrpms and Livna teams, already joined by some Fedora contributors, are proud to announce the RPM Fusion project.
RPM Fusion aims to bring together many packagers from various 3rd party repos and build a single add-on repository for Fedora and Red Hat Enterprise Linux.
Nice -- so this is like the old RPMforge, but with a unified packaging policy (rather than a confederation of repositories)?
ATrpms was one of the only repos that I always advised against installing for usability reasons. Because of the large amount of package replacements in AT, updating with ATrpms in yum.repos.d often causes very invasive changes, and when things go wrong finding the issue becomes a pain.
I don't mean to diminish the service ATrpms provides, but it is in my opinion a fundamentally different animal from the other third party repos. More of a community-built "service pack" than a collection of applications.
David Hollis wrote:
On Tue, 2007-09-11 at 09:16 +0200, Hans de Goede wrote:
ATrpms (Axel) has been involved in the merger talks from day one, unfortunately we (rpmfusion and atrpms) couldn't come to terms and have each gone our seperate ways (as good friends), but who knows what the future will bring.
Hopefully the two repos can at least coordinate enough that they don't step on each other. I'm sure everyone has had the frustration with apps such as mplayer that are in multiple repos, all packaged differently, and all updated at different times so you wind up with crazy dependency issues preventing regular updates and such.
Jaroslaw Gorny wrote:
Tuesday 11 of September 2007 20:09:16 Jeff Spaleta napisał(a):
On 9/11/07, Jaroslaw Gorny jaroslav@aster.pl wrote:
Another example: inclusion of mp3 support libraries, but without rebuilding audio players.
If this is the case, wouldn't such a repo be useless?
[...]
K3b is in distro too. Although I have libmad installed (freshrpms), k3b complains that no support for mp3 decoding can be found. So I guess, k3b should be rebuilt with libmad-devel in order to use this feature.
k3b-extras-nonfree is provided by livna. k3b seems to be a bad example. I do understand what you are saying but in this exact case ... ;-)
Jonathan Steffan daMaestro
Jaroslaw Gorny <jaroslav <at> aster.pl> writes:
Simple kde player included in kdemultimedia-extras (noatun) won't handle mp3 without rebuild.
This is not true. Noatun from the default Fedora package can play MP3s here. I think akode-extras and/or kdemultimedia-extras-nonfree (both from Livna) is the magic package here.
K3b is in distro too. Although I have libmad installed (freshrpms), k3b complains that no support for mp3 decoding can be found. So I guess, k3b should be rebuilt with libmad-devel in order to use this feature.
You need k3b-extras-nonfree from Livna.
We provide foo-lib. There's some package that can be rebuilt with foo-lib and gain some extra features, but we don't do this. Is it really the best solution?
That's what plugins are for.
In other cases, there may be other solutions, for example ld.so.conf library overrides. This is what freetype-freeworld (approved for Livna, waiting on account creation) is doing for libfreetype, the proprietary graphics card drivers for libGL etc. There's even a package within Fedora doing that, though of course not for legal reasons (ATLAS, which replaces the unoptimized reference implementations of BLAS and LAPACK that way).
And then there's always the solution to have a new package like audacity-nonfree which Conflicts: audacity. But if a plugin package can be provided instead, that's much preferred.
Kevin Kofler
Casey Dahlin wrote:
ATrpms was one of the only repos that I always advised against installing for usability reasons. Because of the large amount of package replacements in AT, updating with ATrpms in yum.repos.d often causes very invasive changes, and when things go wrong finding the issue becomes a pain.
I don't mean to diminish the service ATrpms provides, but it is in my opinion a fundamentally different animal from the other third party repos. More of a community-built "service pack" than a collection of applications.
Or a fork of the distribution.
Warren Togami wtogami@redhat.com
Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
Thanks for this split. Hopefully we will able to link to the free part from within Fedora.
Unfortunately I don't think you will be able to. The stuff in the free part (or most of it, at least) is going to be exactly the stuff which Legal is most uncomfortable with: Free Software, but patent-encumbered in the US.
You _might_ be able to refer to the non-free part for NVidia and stuff, but I guess there's probably also going to be stuff that's legally murky at least in the US in there. (For example, the proprietary drivers might be a violation of the Linux kernel's GPL (version 2) license.)
Kevin Kofler
Kevin Kofler wrote:
Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
Thanks for this split. Hopefully we will able to link to the free part from within Fedora.
Unfortunately I don't think you will be able to. The stuff in the free part (or most of it, at least) is going to be exactly the stuff which Legal is most uncomfortable with: Free Software, but patent-encumbered in the US.
Trust me. I am aware of the legal details. See https://www.redhat.com/archives/fedora-advisory-board/2007-July/msg00032.htm.... It is just waiting on Max Spevack to get final advice from Legal.
Rahul
On Tue, 11 Sep 2007 20:02:40 +0000 (UTC) Kevin Kofler kevin.kofler@chello.at wrote:
Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
Thanks for this split. Hopefully we will able to link to the free part from within Fedora.
Unfortunately I don't think you will be able to. The stuff in the free part (or most of it, at least) is going to be exactly the stuff which Legal is most uncomfortable with: Free Software, but patent-encumbered in the US.
And really, if we could reference it, then why the crap couldn't we just package it in our repo?
Kevin Kofler wrote:
Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
Thanks for this split. Hopefully we will able to link to the free part from within Fedora.
Unfortunately I don't think you will be able to. The stuff in the free part (or most of it, at least) is going to be exactly the stuff which Legal is most uncomfortable with: Free Software, but patent-encumbered in the US.
There's a wide spectrum between "right in Fedora" and "not acknowledging its existence."
Whereas before Red Hat became subject to liability for merely saying the word "Livna" in public, we might be able to move to a tacit and well-disclaimed "suggestion" that users use the Free half of rpmfusion. So we could go from having to say "Never heard of it" to being able to say "Its over there, and I know about it, but I really can't recommend that you use it (by clicking this button right here)"
You _might_ be able to refer to the non-free part for NVidia and stuff, but I guess there's probably also going to be stuff that's legally murky at least in the US in there. (For example, the proprietary drivers might be a violation of the Linux kernel's GPL (version 2) license.)
Kevin Kofler
Hallo,
Tuesday 11 of September 2007 21:54:40 Kevin Kofler napisał(a):
In other cases, there may be other solutions, for example (...)
And then there's always the solution to have a new package like audacity-nonfree which Conflicts: audacity. But if a plugin package can be provided instead, that's much preferred.
Thanks a lot for clarification, Kevin. Both general and my app-specific "issues" :)
regards,
Jesse Keating wrote:
On Tue, 11 Sep 2007 20:02:40 +0000 (UTC) Kevin Kofler kevin.kofler@chello.at wrote:
Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
Thanks for this split. Hopefully we will able to link to the free part from within Fedora.
Unfortunately I don't think you will be able to. The stuff in the free part (or most of it, at least) is going to be exactly the stuff which Legal is most uncomfortable with: Free Software, but patent-encumbered in the US.
And really, if we could reference it, then why the crap couldn't we just package it in our repo?
There is a lot of differences between pointing to the repository and including the packages directly as I already explained in Fedora Advisory Board list so I won't rehash all the arguments again now. Please read the releated threads if you missed it. In short, it is not possible to include patent-encumbered packages directly in the repository as long as it hosted in US. Pointing to it might very well be possible.
Rahul
Jesse Keating wrote:
On Tue, 11 Sep 2007 20:02:40 +0000 (UTC) Kevin Kofler kevin.kofler@chello.at wrote:
Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
Thanks for this split. Hopefully we will able to link to the free part from within Fedora.
Unfortunately I don't think you will be able to. The stuff in the free part (or most of it, at least) is going to be exactly the stuff which Legal is most uncomfortable with: Free Software, but patent-encumbered in the US.
And really, if we could reference it, then why the crap couldn't we just package it in our repo?
There is a lot of differences between pointing to the repository and including the packages directly as I already explained in Fedora Advisory Board list so I won't rehash all the arguments again now. Please read the related threads if you missed it. In short, it is not possible to include patent-encumbered packages directly in the repository as long as it hosted in US. Pointing to it might very well be possible.
Rahul
Michel Salim wrote:
On 11/09/2007, Hans de Goede j.w.r.degoede@hhs.nl wrote:
The Dribble, Freshrpms and Livna teams, already joined by some Fedora contributors, are proud to announce the RPM Fusion project.
RPM Fusion aims to bring together many packagers from various 3rd party repos and build a single add-on repository for Fedora and Red Hat Enterprise Linux.
Nice -- so this is like the old RPMforge, but with a unified packaging policy (rather than a confederation of repositories)?
But the reason you need additional 3rd party repositories in the first place is when the unified one has a policy that prohibits certain packages from being there. Will that still be the case?
On 11/09/2007, Les Mikesell lesmikesell@gmail.com wrote:
Michel Salim wrote:
On 11/09/2007, Hans de Goede j.w.r.degoede@hhs.nl wrote:
The Dribble, Freshrpms and Livna teams, already joined by some Fedora contributors, are proud to announce the RPM Fusion project.
RPM Fusion aims to bring together many packagers from various 3rd party repos and build a single add-on repository for Fedora and Red Hat Enterprise Linux.
Nice -- so this is like the old RPMforge, but with a unified packaging policy (rather than a confederation of repositories)?
But the reason you need additional 3rd party repositories in the first place is when the unified one has a policy that prohibits certain packages from being there. Will that still be the case?
I meant that RPMforge is a collection of third-party repos, while RPM Fusion will actually be a single repository.
I do not mean 'unified' as in "merged with Fedora", I meant unified as in "one packaging policy for all the merged repos". Sorry if it's not clear from context.
On Tue, 2007-09-11 at 15:50 -0400, Casey Dahlin wrote:
ATrpms was one of the only repos that I always advised against installing for usability reasons. Because of the large amount of package replacements in AT, updating with ATrpms in yum.repos.d often causes very invasive changes, and when things go wrong finding the issue becomes a pain.
I have to agree. At first, I would avoid ATRPMs simply because it would provide packages (using the same names) as the ones in Fedora. It took me a while before I realized that many of these "duplicate packages" were there because of some added feature which (I'm guessing) inherently couldn't be separated into parts (Modularity).
One example is ATRPMS' spamassassin package. As I understand it, ATRPMS spamassassin package makes use of Vipul's Razor (http://razor.sourceforge.net/) thereby increasing spamassassin's value. Unfortunately, spamassassin razor functionality probably couldn't be separated into an optional package and Axel decided to name the combined integrated package spamassassin (as opposed to, say, spamassassin-razor ... which, by the by, it still a kludge IMO).
Or his bugzilla seems to require ruby, ImageMagick, and perl-GD*. (again perhaps added functionality that couldn't be packaged separately and still calling it the same package).
Axel has, however, made very good decisions technically (like changing library names to include major versions so that different versioned libraries could be installed in parallel, kmdl has the ability to pull in the correct kernel modules for any arbitrary kernel version if they existed in the repository). That and he has packages that aren't available in other repos (like asterisk and mythtv) made me decide to use his repository as well.
As for some decisions that I'm half-and-half with, they would include using newer versions of packages (which didn't work for me because the newer version of mjpegtools wouldn't work) and the fact that there are times when there would be no compromising between his personal taste and that of others.
I think it's always good to take the good things from various schemes and throw away the bad ones to form a cohesive whole. If people could get over personal pride and bigotry, that is. --
Richi Plana
On Tue, 2007-09-11 at 14:06 -0400, Jesse Keating wrote:
On Tue, 11 Sep 2007 20:03:51 +0200 Jaroslaw Gorny jaroslav@aster.pl wrote:
Another example: inclusion of mp3 support libraries, but without rebuilding audio players.
If this is the case, wouldn't such a repo be useless?
With things like gstreamer you don't have to rebuild audio apps. gstreamer plugins will plug into the base gstreamer framework and audio apps just make use of whatever plugins are available.
Now if only that were as easy as "yum install gstreamer-plugin-lame" or "yum install lame-plugin-gstreamer" (in case you wanted to do "yum install lame lame-plugin-*"). --
Richi Plana
Chris Jones wrote:
Also, +1 to the fact its not as good a news as if ATrpms had also been incorporated. If rpmfusion and ATrpms turn out as (in)compatible as say livna and ATrpms are now, then on a practical level the merger is no where near as useful as it could have been.
Yeah, +10 to it being nowhere as good as if ATrpms were included in the merger, since the bulk of the overlap/conflicts in the 3rd-party repo world are between livna and ATrpms. Now they'll just be between rpmfusion and ATrpms. Suck. End-users still lose.
On 11/09/2007, Jarod Wilson jwilson@redhat.com wrote:
Chris Jones wrote:
Also, +1 to the fact its not as good a news as if ATrpms had also been incorporated. If rpmfusion and ATrpms turn out as (in)compatible as say livna and ATrpms are now, then on a practical level the merger is no where near as useful as it could have been.
Yeah, +10 to it being nowhere as good as if ATrpms were included in the merger, since the bulk of the overlap/conflicts in the 3rd-party repo world are between livna and ATrpms. Now they'll just be between rpmfusion and ATrpms. Suck. End-users still lose.
Yeah but it sucks less and end-users lose less. My conflicts have been between freshrpms and livna on occasion. Plus once all the dust has settled maybe things can be tweaked and merges can be discussed again. Its a good thing.
Anyway, nvidia will soon be open source their drivers in response to ATI and we'll lose a whole lot of conflict in one go. :D
<Porcine volant>
Cheers Chris
On Tue, 2007-09-11 at 15:26 -0600, Richi Plana wrote:
On Tue, 2007-09-11 at 14:06 -0400, Jesse Keating wrote:
On Tue, 11 Sep 2007 20:03:51 +0200 Jaroslaw Gorny jaroslav@aster.pl wrote:
Another example: inclusion of mp3 support libraries, but without rebuilding audio players.
If this is the case, wouldn't such a repo be useless?
With things like gstreamer you don't have to rebuild audio apps. gstreamer plugins will plug into the base gstreamer framework and audio apps just make use of whatever plugins are available.
Now if only that were as easy as "yum install gstreamer-plugin-lame" or "yum install lame-plugin-gstreamer" (in case you wanted to do "yum install lame lame-plugin-*").
It is that easy. go to rpm.livna.org and download the correct repository rpm. Once this is installed, type:
yum install gstreamer-plugins-bad
This will install the mp3 codec along with a bunch of other 'bad' codecs.
R.
On Tue, 2007-09-11 at 16:05 -0400, Jesse Keating wrote:
On Tue, 11 Sep 2007 20:02:40 +0000 (UTC) Kevin Kofler kevin.kofler@chello.at wrote:
Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
Thanks for this split. Hopefully we will able to link to the free part from within Fedora.
Unfortunately I don't think you will be able to. The stuff in the free part (or most of it, at least) is going to be exactly the stuff which Legal is most uncomfortable with: Free Software, but patent-encumbered in the US.
And really, if we could reference it, then why the crap couldn't we just package it in our repo?
The installer asks you to locate your time-zone. Couldn't you use this as a trigger for including the US patent encumbered stuff for non US citizens.
Oh and could this be used for setting my paper preference to A4 by default instead of having to change this each time I set up a printer?
R.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On 9/11/07, Rodd Clarkson rodd@clarkson.id.au wrote:
The installer asks you to locate your time-zone. Couldn't you use this as a trigger for including the US patent encumbered stuff for non US citizens.
I'm pretty sure it would be just as inappropriate for me, as a US citizen, to be in a US embassy in Spain as it would be for me to be in Seattle.
-jef"Clearly the solution is to start supporting US passport swiping technology at install time, so that each US citizen can 'register' with the US government their intent to perform a Fedora install, and the US government can tell the installer exactly what that US citizen is allowed to install, based on their personalized US government profile. Registered republicans would be unable to install 'gimp', registered Democrats would be unable to install 'gnucash', and Libertarians would be forced to install a government approved keylogger"spaleta
On 11/09/2007, Rodd Clarkson rodd@clarkson.id.au wrote:
Oh and could this be used for setting my paper preference to A4 by default instead of having to change this each time I set up a printer?
That is actually a good idea! Shouldn't something like this be standardized in Freedesktop.org ?
On Tue, 2007-09-11 at 21:49 -0400, Michel Salim wrote:
On 11/09/2007, Rodd Clarkson rodd@clarkson.id.au wrote:
Oh and could this be used for setting my paper preference to A4 by default instead of having to change this each time I set up a printer?
That is actually a good idea! Shouldn't something like this be standardized in Freedesktop.org ?
and with more and more distros using system-config-printer tied in there, too.
-sv
On Wed, 2007-09-12 at 10:37 +1000, Rodd Clarkson wrote:
On Tue, 2007-09-11 at 15:26 -0600, Richi Plana wrote:
On Tue, 2007-09-11 at 14:06 -0400, Jesse Keating wrote:
On Tue, 11 Sep 2007 20:03:51 +0200 Jaroslaw Gorny jaroslav@aster.pl wrote:
Another example: inclusion of mp3 support libraries, but without rebuilding audio players.
If this is the case, wouldn't such a repo be useless?
With things like gstreamer you don't have to rebuild audio apps. gstreamer plugins will plug into the base gstreamer framework and audio apps just make use of whatever plugins are available.
Now if only that were as easy as "yum install gstreamer-plugin-lame" or "yum install lame-plugin-gstreamer" (in case you wanted to do "yum install lame lame-plugin-*").
It is that easy. go to rpm.livna.org and download the correct repository rpm. Once this is installed, type:
yum install gstreamer-plugins-bad
I'm sorry. You missed my point. You can't just install lame and it's accompanying application plugins. Sure, you can install gstreamer-plugins-bad, but even different repositories have support for different libraries.
Speaking of gstreamer-plugins-bad, I don't even grab mine from any repository. I have to compile my own as I use the timidity and wildmidi plugins (which aren't enabled in any of the repos, as far as I can tell). --
Richi Plana
On Tue, 2007-09-11 at 16:53 -0800, Jeff Spaleta wrote:
On 9/11/07, Rodd Clarkson rodd@clarkson.id.au wrote:
The installer asks you to locate your time-zone. Couldn't you use this as a trigger for including the US patent encumbered stuff for non US citizens.
I'm pretty sure it would be just as inappropriate for me, as a US citizen, to be in a US embassy in Spain as it would be for me to be in Seattle.
Okay, well then include a question about citizenship in the installer and use that!
R.
Rodd Clarkson (rodd@clarkson.id.au) said:
The installer asks you to locate your time-zone. Couldn't you use this as a trigger for including the US patent encumbered stuff for non US citizens.
Oh and could this be used for setting my paper preference to A4 by default instead of having to change this each time I set up a printer?
Doesn't LC_PAPER cover this?
Bill
Le mardi 11 septembre 2007 à 15:17 -0600, Richi Plana a écrit :
Unfortunately, spamassassin razor functionality probably couldn't be separated into an optional package and Axel decided to name the combined integrated package spamassassin
"Spamassassion rezor functionnality" is one config setting upstream sets to off by default because razor licensing prohibits use in a commercial context. So you just need to chnage this setting to use fedora sa with razor as-is
Try again
Le mardi 11 septembre 2007 à 23:19 -0400, Bill Nottingham a écrit :
Rodd Clarkson (rodd@clarkson.id.au) said:
The installer asks you to locate your time-zone. Couldn't you use this as a trigger for including the US patent encumbered stuff for non US citizens.
Oh and could this be used for setting my paper preference to A4 by default instead of having to change this each time I set up a printer?
Doesn't LC_PAPER cover this?
If apps respected it. locale|grep PAPER LC_PAPER="fr_FR.UTF-8 ← should not be letter
So many apps hardcode letter by default and revert to it at the slightest excuse it's not even remotely funny. (another favorite is if you press print in the app before powering on your printer, the system will remember the printer was stopped and you have to go into system-config-printer to restart the print queue)
Richi Plana wrote:
On Wed, 2007-09-12 at 10:37 +1000, Rodd Clarkson wrote:
On Tue, 2007-09-11 at 15:26 -0600, Richi Plana wrote:
On Tue, 2007-09-11 at 14:06 -0400, Jesse Keating wrote:
On Tue, 11 Sep 2007 20:03:51 +0200 Jaroslaw Gorny jaroslav@aster.pl wrote:
Another example: inclusion of mp3 support libraries, but without rebuilding audio players.
If this is the case, wouldn't such a repo be useless?
With things like gstreamer you don't have to rebuild audio apps. gstreamer plugins will plug into the base gstreamer framework and audio apps just make use of whatever plugins are available.
Now if only that were as easy as "yum install gstreamer-plugin-lame" or "yum install lame-plugin-gstreamer" (in case you wanted to do "yum install lame lame-plugin-*").
It is that easy. go to rpm.livna.org and download the correct repository rpm. Once this is installed, type:
yum install gstreamer-plugins-bad
I'm sorry. You missed my point. You can't just install lame and it's accompanying application plugins. Sure, you can install gstreamer-plugins-bad, but even different repositories have support for different libraries.
Speaking of gstreamer-plugins-bad, I don't even grab mine from any repository. I have to compile my own as I use the timidity and wildmidi plugins (which aren't enabled in any of the repos, as far as I can tell).
Argh, you are right they aren't enabled in livna. Next time please file a bug about things like this. I specially packaged libtimidity and wildimidi for Fedora so that I could enable them, I'll do a new gstreamer-plugins-bad for livna fixing this shortly.
Regards,
Hans
On 12/09/2007, Rodd Clarkson rodd@clarkson.id.au wrote:
On Tue, 2007-09-11 at 15:26 -0600, Richi Plana wrote:
...
Now if only that were as easy as "yum install gstreamer-plugin-lame" or "yum install lame-plugin-gstreamer" (in case you wanted to do "yum install lame lame-plugin-*").
It is that easy. go to rpm.livna.org and download the correct repository rpm. Once this is installed, type:
yum install gstreamer-plugins-bad
Exactly. Not specific.
This will install the mp3 codec along with a bunch of other 'bad' codecs.
Quite. Again, it would be nice to be able to install *the plugin that's wanted*.
And *only* the plugin that's wanted.
Bill Crawford wrote:
On 12/09/2007, Rodd Clarkson rodd@clarkson.id.au wrote:
yum install gstreamer-plugins-bad
This will install the mp3 codec along with a bunch of other 'bad' codecs.
Quite. Again, it would be nice to be able to install *the plugin that's wanted*.
And *only* the plugin that's wanted.
Balance this with the convenience, useful for most users, to not have to hunt for codecs/plugins, install one package and be sure the multimedia playing troubles are solved.
On 12/09/2007, Nicu Buculei nicu_fedora@nicubunu.ro wrote: ...
Balance this with the convenience, useful for most users, to not have to hunt for codecs/plugins, install one package and be sure the multimedia playing troubles are solved.
"not have to hunt for" => either
1) *all* plugins, evar, are in the one package, innit OR 2) each plugin is appropriately named (and perhaps we need some extra Provides: or maybe a package that pulls in appropriate ones via Requires:, so that one can indeed install "DVD support" and get libdvd{read,nav,css} pulled in, the last of them should of course be optional).
Seriously, that's half the problem. When I want "mp3 playing" support, I have to install "xine-lib-moles" ...
On Wed, 2007-09-12 at 08:08 +0200, Nicolas Mailhot wrote:
Le mardi 11 septembre 2007 à 23:19 -0400, Bill Nottingham a écrit :
Rodd Clarkson (rodd@clarkson.id.au) said:
The installer asks you to locate your time-zone. Couldn't you use this as a trigger for including the US patent encumbered stuff for non US citizens.
Oh and could this be used for setting my paper preference to A4 by default instead of having to change this each time I set up a printer?
Doesn't LC_PAPER cover this?
If apps respected it. locale|grep PAPER LC_PAPER="fr_FR.UTF-8 ← should not be letter
Hmmm, I get
[rodd@localhost ~]$ locale | grep PAPER LC_PAPER="en_US.UTF-8"
I use US english, but I live in Australia (which is used as my timezone) so what should it do?
Personally, I think it should default to ISO (A4) and then this might get the attention of US developers who find themselves using the wrong paper and fixing this properly. I don't know how many countries use non-ISO paper sizes, but there can't be too many (Rumor has it, it's the US and one small country nobody knows the name of)
So many apps hardcode letter by default and revert to it at the slightest excuse it's not even remotely funny. (another favorite is if you press print in the app before powering on your printer, the system will remember the printer was stopped and you have to go into system-config-printer to restart the print queue)
I thought this was fixed, but maybe it isn't. It was (however) very annoying.
R.
Rahul Sundaram wrote:
Jesse Keating wrote:
On Tue, 11 Sep 2007 20:02:40 +0000 (UTC) Kevin Kofler kevin.kofler@chello.at wrote:
Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
Thanks for this split. Hopefully we will able to link to the free part from within Fedora.
Unfortunately I don't think you will be able to. The stuff in the free part (or most of it, at least) is going to be exactly the stuff which Legal is most uncomfortable with: Free Software, but patent-encumbered in the US.
And really, if we could reference it, then why the crap couldn't we just package it in our repo?
There is a lot of differences between pointing to the repository and including the packages directly as I already explained in Fedora Advisory Board list so I won't rehash all the arguments again now. Please read the releated threads if you missed it. In short, it is not possible to include patent-encumbered packages directly in the repository as long as it hosted in US. Pointing to it might very well be possible.
Seriously though, this is just plain dumb wrong:
If we cannot include the packages in our own repositories but we can point to other repositories that do have the packages, nothing prevents us from distributing the appropriate /etc/yum.repos.d/ files in the fedora-release package.
So, I'll back up Jesse's question:
And really, if we could reference it, then why the crap couldn't we just package it in our repo?
Jeroen van Meeuwen wrote:
Seriously though, this is just plain dumb wrong:
If we cannot include the packages in our own repositories but we can point to other repositories that do have the packages, nothing prevents us from distributing the appropriate /etc/yum.repos.d/ files in the fedora-release package.
This is again different from including the packages. The details are important from a legal perspective.
So, I'll back up Jesse's question:
And really, if we could reference it, then why the crap couldn't we just package it in our repo?
Same answer. Go and read the Fedora Advisory Board list threads which already answer this question.
Rahul
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
Seriously though, this is just plain dumb wrong:
If we cannot include the packages in our own repositories but we can point to other repositories that do have the packages, nothing prevents us from distributing the appropriate /etc/yum.repos.d/ files in the fedora-release package.
This is again different from including the packages. The details are important from a legal perspective.
Sure it is different from including the packages ourselves, that wasn't the point. My point is, that if we can refer to anything, we might as well include the configuration files for those third party repositories that hold the packages we can't ship/include.
In other words: there's no difference in being allowed to link to anything and actually shipping the link in that very package.
Functionally, the effects of the latter actually isn't anything different from shipping the packages from a host set up on the other side of the pond.
So, I'll back up Jesse's question:
And really, if we could reference it, then why the crap couldn't we just package it in our repo?
This time, substitute "our repo" for:
"some repo being 'ours' -though not really /ours/- (but replicated over non-US mirrors only?)".
Next reply I'll send you a regex.
Same answer.
Can't be.
Go and read the Fedora Advisory Board list threads which
already answer this question.
On 12/09/2007, Bill Crawford billcrawford1970@gmail.com wrote:
Seriously, that's half the problem. When I want "mp3 playing" support, I have to install "xine-lib-moles" ...
A viable solution will be to use Gentoo-esque "USE flags". Tag (sub)packages with what feature they provide -- e.g. MP3, DVD playback -- and also the package(s) for which they enable this functionality.
Thus xine-lib-moles will have this:
<functionality name="mp3" for="xine-lib" />
If xine-lib is installed on your computer, and you ask for MP3 support, it will install xine-lib-moles; if not, it won't. Likewise, if you have enabled MP3 support and then later install xine-lib, it should pull in xine-lib-moles as well.
Thoughts? This could almost be fitted into Provides: / Requires:, but I don't think it actually can.
Regards,
On Wed, 2007-09-12 at 10:02 +0200, Hans de Goede wrote:
Richi Plana wrote:
Speaking of gstreamer-plugins-bad, I don't even grab mine from any repository. I have to compile my own as I use the timidity and wildmidi plugins (which aren't enabled in any of the repos, as far as I can tell).
Argh, you are right they aren't enabled in livna. Next time please file a bug about things like this. I specially packaged libtimidity and wildimidi for Fedora so that I could enable them, I'll do a new gstreamer-plugins-bad for livna fixing this shortly.
I was wondering why there was a wildmidi-related patch in the srpm. Sorry if I hadn't filed a bug report. It's hard to tell what was intended and what isn't. Would it interest you to know that on my machine, I also have the mpeg2enc and nassink plugins enabled?
Hans, how about this for an idea: re-write the gstreamer-plugins-bad.spec so that it puts the various plugins in separate packages and make gstreamer-plugins-bad a virtual package that Requires all of the plugins to pull them in?
I was going to do that for my system, privately. Unfortunately, I don't know how to rename the main part of the sub-packages name. I was planning on using the scheme "gstreamer-plugin-<module>" for the modules and "gstreamer-plugins-bad" for the virtual package, but I can't figure out how to change the root name. I'd really rather not use "gstreamer-plugins-bad-<module>" if possible (actually, I'd rather not use ANY filenames, if possible. I've posted several times against the idea of storing meta-info in filenames). Any ideas? --
Richi Plana
Jeroen van Meeuwen wrote:
There is a lot of differences between pointing to the repository and including the packages directly as I already explained in Fedora Advisory Board list so I won't rehash all the arguments again now. Please read the releated threads if you missed it. In short, it is not possible to include patent-encumbered packages directly in the repository as long as it hosted in US. Pointing to it might very well be possible.
Seriously though, this is just plain dumb wrong:
If we cannot include the packages in our own repositories but we can point to other repositories that do have the packages, nothing prevents us from distributing the appropriate /etc/yum.repos.d/ files in the fedora-release package.
Or, if you need another level of indirection, include a repo that doesn't itself have anything controversial but has a package that configures yum for repos that might.
So, I'll back up Jesse's question:
And really, if we could reference it, then why the crap couldn't we just package it in our repo?
Or - why not move the entire repo to places that can have all the contents? What's the point of even worrying about this issue?
On Wed, 12 Sep 2007, Bill Crawford wrote:
On 12/09/2007, Nicu Buculei nicu_fedora@nicubunu.ro wrote: ...
Balance this with the convenience, useful for most users, to not have to hunt for codecs/plugins, install one package and be sure the multimedia playing troubles are solved.
"not have to hunt for" => either
- *all* plugins, evar, are in the one package, innit
OR 2) each plugin is appropriately named (and perhaps we need some extra Provides: or maybe a package that pulls in appropriate ones via Requires:, so that one can indeed install "DVD support" and get libdvd{read,nav,css} pulled in, the last of them should of course be optional).
Couldn't this be managed by rpmfusion using a comps file, and grouping various packages with "DVD support," "MP3 support," or whatnot? `yum groupinstall "DVD Support"`...
Jima
Jeroen van Meeuwen wrote:
In other words: there's no difference in being allowed to link to anything and actually shipping the link in that very package.
Functionally, the effects of the latter actually isn't anything different from shipping the packages from a host set up on the other side of the pond.
We can't primarily concerned with functionality without understanding the legal implications.
Same answer.
Can't be.
It is. All the different scenarios were hashed out there. Read them first completely.
Rahul
On Wed, 2007-09-12 at 13:31 +0300, Nicu Buculei wrote:
Bill Crawford wrote:
On 12/09/2007, Rodd Clarkson rodd@clarkson.id.au wrote:
yum install gstreamer-plugins-bad
This will install the mp3 codec along with a bunch of other 'bad' codecs.
Quite. Again, it would be nice to be able to install *the plugin that's wanted*.
And *only* the plugin that's wanted.
Balance this with the convenience, useful for most users, to not have to hunt for codecs/plugins, install one package and be sure the multimedia playing troubles are solved.
The Right Way(TM) (IMHO) to do that is to have a system that will 1) find the name of the correct plugin to handle the multimedia file from a directory, and 2) yum install it on-the-fly. Remember that formats and plugins are popping up left and right. Some are encompassing, some are more esoteric. You'll either be forced to keep updating the one-package-to-rule-them-all file everytime something new comes up, or you have the automated system I just mentioned. You can't have one big package for all the plugins that you can enable at one time and have the users hunt manually for the others as they come up.
Besides, it's also possible to create a virtual package (say: gstreamer-plugins-audio ... to illustrate that we do not need to follow the upstream packaging scheme. They have their reasons for packaging things -good, -bad, -base and -ugly and they MIGHT not coincide with the needs of our users) and have that virtual package pull in the individual plugin packages. IF they really wanted the world. --
Richi Plana
On Wed, 12 Sep 2007 08:41:06 -0500 (CDT) Jima jima@beer.tclug.org wrote:
Couldn't this be managed by rpmfusion using a comps file, and grouping various packages with "DVD support," "MP3 support," or whatnot? `yum groupinstall "DVD Support"`...
This sounds like a good thought. The problem would be "what if I don't have xine, but installing mp3 support drags in xine just for the plugin?" Usually the answer is "well, use conditionals" which are a way to say "only include this package, if this other package is already selected or installed". However I think there is some desire to do away with conditionals.
On 12/09/2007, Richi Plana myfedora@richip.dhs.org wrote:
On Wed, 2007-09-12 at 13:31 +0300, Nicu Buculei wrote:
Bill Crawford wrote:
On 12/09/2007, Rodd Clarkson rodd@clarkson.id.au wrote:
yum install gstreamer-plugins-bad
This will install the mp3 codec along with a bunch of other 'bad' codecs.
Quite. Again, it would be nice to be able to install *the plugin that's wanted*.
And *only* the plugin that's wanted.
Balance this with the convenience, useful for most users, to not have to hunt for codecs/plugins, install one package and be sure the multimedia playing troubles are solved.
The Right Way(TM) (IMHO) to do that is to have a system that will 1) find the name of the correct plugin to handle the multimedia file from a directory, and 2) yum install it on-the-fly. Remember that formats and plugins are popping up left and right. Some are encompassing, some are more esoteric. You'll either be forced to keep updating the one-package-to-rule-them-all file everytime something new comes up, or you have the automated system I just mentioned. You can't have one big package for all the plugins that you can enable at one time and have the users hunt manually for the others as they come up.
Codec Buddy:
http://fedoraproject.org/wiki/Releases/FeatureCodecBuddy
though in F-8 it won't integrate with third-party repos just yet, so it will probably only redirect you to Fluendo's shop.
On 12/09/2007, Richi Plana myfedora@richip.dhs.org wrote:
Hans, how about this for an idea: re-write the gstreamer-plugins-bad.spec so that it puts the various plugins in separate packages and make gstreamer-plugins-bad a virtual package that Requires all of the plugins to pull them in?
+2
I was going to do that for my system, privately. Unfortunately, I don't know how to rename the main part of the sub-packages name. I was planning on using the scheme "gstreamer-plugin-<module>" for the modules and "gstreamer-plugins-bad" for the virtual package, but I can't figure out how to change the root name. I'd really rather not use "gstreamer-plugins-bad-<module>" if possible (actually, I'd rather not use ANY filenames, if possible. I've posted several times against the idea of storing meta-info in filenames). Any ideas?
Yes, this is an excellent plan. The only thing that stopped me doing it myself was that I'd have ended up having to rebuild a load of *other* packages to change their Requires: and so on ...
On 12/09/2007, Richi Plana myfedora@richip.dhs.org wrote:
Hans, how about this for an idea: re-write the gstreamer-plugins-bad.spec so that it puts the various plugins in separate packages and make gstreamer-plugins-bad a virtual package that Requires all of the plugins to pull them in?
That's how FreshRPMS packaged gstreamer in the past, AFAIK -- until upstream actually moved to aggregating plugins based on quality.
On 12/09/2007, Jima jima@beer.tclug.org wrote:
Couldn't this be managed by rpmfusion using a comps file, and grouping various packages with "DVD support," "MP3 support," or whatnot? `yum groupinstall "DVD Support"`...
I think that's the best suggestion on how to balance packaging versus usability, so far ...
From the UI perspective, many users will indeed want to just say "give
me support for playing MP3" or "I want to watch a DVD now".
On 12.09.2007 17:44, Bill Crawford wrote:
On 12/09/2007, Jima jima@beer.tclug.org wrote:
Couldn't this be managed by rpmfusion using a comps file, and grouping various packages with "DVD support," "MP3 support," or whatnot? `yum groupinstall "DVD Support"`...
I think that's the best suggestion on how to balance packaging versus usability, so far ...
FYI for Livna I tried something else, but it didn't work out. I just used the same groups as Fedora in Livna (as Fedora Extras did in the past for Core as well) and made some crucial packages 'type="default"' -- for example gstreamer-plugins-ugly for the "GNOME Desktop Environment" . I assumed anaconda would then install gstreamer-plugins-ugly by default as "GNOME Desktop Environment" is selected by default. But anaconda/pirut did not do that (and I assume it still don't).
I think they should (I filed a bug, but it got closed iirc), as that way would be the cleanest for a 3rd party repo to get the right packages (e.g. depending on the groups they selected) to the users.
Cu knurd
On Wed, 2007-09-12 at 15:20 +0200, Jeroen van Meeuwen wrote:
Sure it is different from including the packages ourselves, that wasn't the point. My point is, that if we can refer to anything, we might as well include the configuration files for those third party repositories that hold the packages we can't ship/include.
In other words: there's no difference in being allowed to link to anything and actually shipping the link in that very package.
Hold on. I think you two are on different pages here. You're both making sense, but seem to be talking about different things.
Rahul, exactly what constitutes "linking" or "pointing" to these external packages? Do you mean a Note in some documentation somewhere? Perhaps in the distro or on a website somewhere? Or is it an actual entry in /etc/yum.respos.d/ pointing directly to the repo where the packages can be downloaded from? --
Richi Plana
Thorsten Leemhuis wrote:
On 12.09.2007 17:44, Bill Crawford wrote:
On 12/09/2007, Jima jima@beer.tclug.org wrote:
Couldn't this be managed by rpmfusion using a comps file, and grouping various packages with "DVD support," "MP3 support," or whatnot? `yum groupinstall "DVD Support"`...
I think that's the best suggestion on how to balance packaging versus usability, so far ...
FYI for Livna I tried something else, but it didn't work out. I just used the same groups as Fedora in Livna (as Fedora Extras did in the past for Core as well) and made some crucial packages 'type="default"' -- for example gstreamer-plugins-ugly for the "GNOME Desktop Environment" . I assumed anaconda would then install gstreamer-plugins-ugly by default as "GNOME Desktop Environment" is selected by default. But anaconda/pirut did not do that (and I assume it still don't).
At our site, we include a custom repo adding default items to the same groups (exactly as you described), and it works for us here (using f7).
-- Rex
On Wed, 12 Sep 2007 17:58:37 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
FYI for Livna I tried something else, but it didn't work out. I just used the same groups as Fedora in Livna (as Fedora Extras did in the past for Core as well) and made some crucial packages 'type="default"' -- for example gstreamer-plugins-ugly for the "GNOME Desktop Environment" . I assumed anaconda would then install gstreamer-plugins-ugly by default as "GNOME Desktop Environment" is selected by default. But anaconda/pirut did not do that (and I assume it still don't).
I think they should (I filed a bug, but it got closed iirc), as that way would be the cleanest for a 3rd party repo to get the right packages (e.g. depending on the groups they selected) to the users.
At initial install time, if the livna repo is added, then what is selected by default is the aggregate of all the repos contents of a group. So yes, at install time this would be selected. After that though, stuff isn't magically "added" just because it's marked as a default in a group when you launch pirut, nor should it.
On 9/12/07, Les Mikesell lesmikesell@gmail.com wrote:
Or, if you need another level of indirection, include a repo that doesn't itself have anything controversial but has a package that configures yum for repos that might.
oh classy. So how would that work from a user perspective?
Let's say the repo you describe exists... let's call it the repo-clearinghouse repo. It essentially holds release packages for each addon repo that can be installed thus configuring the client to pull packages from different addon repos.
Obviously yum install repoA-release will install the release package for repoA, as held in the clearinghouse repo... but how do you expose things in a way that a user can ask which addon repo they need to configure?
Say I want support for the new foo codec that can't be shipped in Fedora. Do i look in repoA or repoB or repoC ? How would the repo-clearinghouse repo expose that repoA was the correct location to find all things related to foo codec? How do I ask which repo to configure through interaction with the repo-clearinghouse metadata specifically to get access to all foo codec related packages?
-jef
Richi Plana wrote:
Rahul, exactly what constitutes "linking" or "pointing" to these external packages? Do you mean a Note in some documentation somewhere? Perhaps in the distro or on a website somewhere? Or is it an actual entry in /etc/yum.respos.d/ pointing directly to the repo where the packages can be downloaded from?
I am not talking about any repo files. Just a pointer in documentation or in any application. The details are explained in FAB list. That requires Legal to look into this. No amount of layman arguments can help us make a decision and legal perspectives doesn't always make logical sense which many tend to assume.
Rahul
On 9/12/07, Bill Crawford billcrawford1970@gmail.com wrote:
On 12/09/2007, Richi Plana myfedora@richip.dhs.org wrote:
Hans, how about this for an idea: re-write the gstreamer-plugins-bad.spec so that it puts the various plugins in separate packages and make gstreamer-plugins-bad a virtual package that Requires all of the plugins to pull them in?
+2
-100
The discussion on how gstreamer's source codebase needs to be happening with gstreamer upstream. if gstreamer upstream continues to aggregate, splitting modules out one by one is guaranteed to be a fragile exercise of frustration. If it makes sense for the users of distributions to consume the modules as separate packages then it makes just as much sense for the gstreamer upstream to treat the modules as separate codebases so the entire gstreamer user/developer/tester base can consume them piecemeal as well.
Everyone who wants to see more modularity, feel free to bring this desire up with the gstreamer upstream and make a reasoned argument to try to persuade them to change how they are packaging the modules.
-jef"I'd love to consume gstreamer modules piecemeal for testing"spaleta
Jeff Spaleta wrote:
On 9/12/07, Les Mikesell lesmikesell@gmail.com wrote:
Or, if you need another level of indirection, include a repo that doesn't itself have anything controversial but has a package that configures yum for repos that might.
oh classy. So how would that work from a user perspective?
Let's say the repo you describe exists... let's call it the repo-clearinghouse repo. It essentially holds release packages for each addon repo that can be installed thus configuring the client to pull packages from different addon repos.
Obviously yum install repoA-release will install the release package for repoA, as held in the clearinghouse repo... but how do you expose things in a way that a user can ask which addon repo they need to configure?
How does a user know about any other package and decide if they would like yum to install it? A name convention for packages so something like 'yum search repo' would find a list of repos that yum could add to itself.
Say I want support for the new foo codec that can't be shipped in Fedora. Do i look in repoA or repoB or repoC ? How would the repo-clearinghouse repo expose that repoA was the correct location to find all things related to foo codec? How do I ask which repo to configure through interaction with the repo-clearinghouse metadata specifically to get access to all foo codec related packages?
'yum info repoA-release' might describe why you would want to install access to that repo, perhaps to the extent of having the package list or at least the ones that you felt could be legally mentioned everywhere. But, I thought the point of rpm-fusion was to become the only extra repo you might need so this decision wouldn't be too complicated.
On 12.09.2007 18:13, Jesse Keating wrote:
On Wed, 12 Sep 2007 17:58:37 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
FYI for Livna I tried something else, but it didn't work out. I just used the same groups as Fedora in Livna (as Fedora Extras did in the past for Core as well) and made some crucial packages 'type="default"' -- for example gstreamer-plugins-ugly for the "GNOME Desktop Environment" . I assumed anaconda would then install gstreamer-plugins-ugly by default as "GNOME Desktop Environment" is selected by default. But anaconda/pirut did not do that (and I assume it still don't).
I think they should (I filed a bug, but it got closed iirc), as that way would be the cleanest for a 3rd party repo to get the right packages (e.g. depending on the groups they selected) to the users.
At initial install time, if the livna repo is added, then what is selected by default is the aggregate of all the repos contents of a group. So yes, at install time this would be selected.
No, it's not, if you don't change anything after activating livna. Only if you unselect the gnome group (which is enabled by default) once and select it again, then the livna-package gets added as well.
(BTW, even livna-specific groups that are marked as "default" don't get installed, thus there is not even a way to get the livna-release package automatically installed with anaconda in F7; yes, there is a bug about it somewhere in bugzilla, but it got closed)
After that though, stuff isn't magically "added" just because it's marked as a default in a group when you launch pirut, nor should it.
I'm not really sure about the "nor should it" part. Maybe yes, maybe no.
Example: For user "eve" that is a tough girl and remembers to enable livna during install it would really be the easiest solution if she gets some of the livna packages by default depending on the groups she selects/that got selected by anaconda/yum by default.
But consider user "adam", who forgot to enable livna during install or was not able to do so -- for him it would mean that he needs to look through all all the groups and guess which packages he might needs to add to get the important stuff.
The only "workaround" today afaics: create special groups, e.g. "livna/rpmfusion gnome" and "livna/rpmfusion kde" and mark the "livna/rpmfusion gnome" group as default. Then adam can easily select the group later and eve will get the gnome package by default. But then evetoo would need to remember to switch of both the "livna/rpmfusion gnome" and "Fedora gnome" and enable both "livna/rpmfusion kde" and "Fedora KDE" if she wants to use KDE -- that sucks as well.
If there is any better way: please let me know.
CU knurd
On 12.09.2007 18:12, Rex Dieter wrote:
Thorsten Leemhuis wrote:
On 12.09.2007 17:44, Bill Crawford wrote:
On 12/09/2007, Jima jima@beer.tclug.org wrote:
Couldn't this be managed by rpmfusion using a comps file, and grouping various packages with "DVD support," "MP3 support," or whatnot? `yum groupinstall "DVD Support"`...
I think that's the best suggestion on how to balance packaging versus usability, so far ...
FYI for Livna I tried something else, but it didn't work out. I just used the same groups as Fedora in Livna (as Fedora Extras did in the past for Core as well) and made some crucial packages 'type="default"' -- for example gstreamer-plugins-ugly for the "GNOME Desktop Environment" . I assumed anaconda would then install gstreamer-plugins-ugly by default as "GNOME Desktop Environment" is selected by default. But anaconda/pirut did not do that (and I assume it still don't).
At our site,
kde-redhat?
we include a custom repo adding default items to the same groups (exactly as you described),
KDE I suppose?
and it works for us here (using f7).
Yeah, it works, afaics only because you have to select KDE always. But it doesn't work for the default install with gnome, as gnome is selected already as default, and todays anaconda does not add the packages from the 3rd party repo to the to-be-installed-pacakge-set if you don't switch off gnome once and reenable it.
CU knurd
On 9/12/07, Les Mikesell lesmikesell@gmail.com wrote:
'yum info repoA-release' might describe why you would want to install access to that repo, perhaps to the extent of having the package list or at least the ones that you felt could be legally mentioned everywhere. But, I thought the point of rpm-fusion was to become the only extra repo you might need so this decision wouldn't be too complicated.
rpm-fusion is actually... 2 repos. free and non-free. But if repo-fusion is the only extra repo(s) that the redirectory is going to actual contain information for.. then i very much doubt that the redirection trick provides any cover from a legal perspective. But what the hell do I know.
-jef"Anyone happen to have a C implementation of the generalized Lomb periodogram for quadrature signals with Lagrangian amplitude envelope decay functions just sitting around collecting dust that I could mooch?"spaleta
On Wed, 2007-09-12 at 08:27 -0800, Jeff Spaleta wrote:
On 9/12/07, Bill Crawford billcrawford1970@gmail.com wrote:
On 12/09/2007, Richi Plana myfedora@richip.dhs.org wrote:
Hans, how about this for an idea: re-write the gstreamer-plugins-bad.spec so that it puts the various plugins in separate packages and make gstreamer-plugins-bad a virtual package that Requires all of the plugins to pull them in?
+2
-100
The discussion on how gstreamer's source codebase needs to be happening with gstreamer upstream. if gstreamer upstream continues to aggregate, splitting modules out one by one is guaranteed to be a fragile exercise of frustration. If it makes sense for the users of distributions to consume the modules as separate packages then it makes just as much sense for the gstreamer upstream to treat the modules as separate codebases so the entire gstreamer user/developer/tester base can consume them piecemeal as well.
No, the needs and requirements of upstream and that of Fedora's users do not necessarily coincide. They have a reason to package things the way they did, and believe me, it has nothing to do with what users want. They are most certainly not trying to make it hard for users, and if asked they might sometimes give in, but they have their own concerns. If asked to separate them, they will most likely say that it is the distro's or the packagers responsibility to do that.
We already have several of Fedora's users asking for it, so there obviously is a demand. If someone thinks the users are being stupid, then I suggest that enlightening them and showing them the error of their ways is the correct approach. But the correct approach isn't to say that upstream always cares about the needs and requirements of their users. Most of upstream's decision are based on development or legal decisions. Sometimes the needs and wants of the users, the packagers and upstream developers sometimes coincide and THAT'S when it makes sense to go to them, but such isn't always the case. --
Richi "ah, what the heck?" Plana
On Wed, 2007-09-12 at 09:51 -0400, Michel Salim wrote:
Codec Buddy:
http://fedoraproject.org/wiki/Releases/FeatureCodecBuddy
though in F-8 it won't integrate with third-party repos just yet, so it will probably only redirect you to Fluendo's shop.
Ahh, but the mindset and the infrastructure are there! :)
It's really the computer's task to figure everything out that it can and only go back to humans for things that it can't. But to do that needs the right kind of programming. Not the easiest thing, but we shouldn't shy away from the challenge. --
Richi Plana
On Wed, 2007-09-12 at 08:27 -0800, Jeff Spaleta wrote:
On 9/12/07, Bill Crawford billcrawford1970@gmail.com wrote:
On 12/09/2007, Richi Plana myfedora@richip.dhs.org wrote:
Hans, how about this for an idea: re-write the gstreamer-plugins-bad.spec so that it puts the various plugins in separate packages and make gstreamer-plugins-bad a virtual package that Requires all of the plugins to pull them in?
+2
-100
The discussion on how gstreamer's source codebase needs to be happening with gstreamer upstream.
+1. This should be worked out upstream.
/B
On Wed, 2007-09-12 at 21:49 +0530, Rahul Sundaram wrote:
I am not talking about any repo files. Just a pointer in documentation or in any application. The details are explained in FAB list. That requires Legal to look into this. No amount of layman arguments can help us make a decision and legal perspectives doesn't always make logical sense which many tend to assume.
In other words, Fedora's lawyers have deemed it risky (or even downright illegal) to include in the distro .repo files that would allow users to download, say, US-illegal codecs even if the repository itself physically and logistically isn't connected to Fedora. But pointers in documents can.
There we go. That's what the legal experts are saying. Do I have it about right? --
Richi Plana
Richi Plana wrote:
On Wed, 2007-09-12 at 10:02 +0200, Hans de Goede wrote:
Richi Plana wrote:
Speaking of gstreamer-plugins-bad, I don't even grab mine from any repository. I have to compile my own as I use the timidity and wildmidi plugins (which aren't enabled in any of the repos, as far as I can tell).
Argh, you are right they aren't enabled in livna. Next time please file a bug about things like this. I specially packaged libtimidity and wildimidi for Fedora so that I could enable them, I'll do a new gstreamer-plugins-bad for livna fixing this shortly.
I was wondering why there was a wildmidi-related patch in the srpm.
Well, because I intended to enable wildmidi support as soon as wildmidi got approved, but I forgot :|
Sorry if I hadn't filed a bug report. It's hard to tell what was intended and what isn't. Would it interest you to know that on my machine, I also have the mpeg2enc and nassink plugins enabled?
mpeg2enc should already be enabled I indeed missed nas thats enabled now too
Hans, how about this for an idea: re-write the gstreamer-plugins-bad.spec so that it puts the various plugins in separate packages and make gstreamer-plugins-bad a virtual package that Requires all of the plugins to pull them in?
I think this is a bad idea, we really want the user to have todo less to get a complete set of codecs, not more.
It might be an idea to put some of the less often used sinks (jack, nas, ?) in a -extras package though, to avoid pulling in deps most people don't have a use for.
Regards,
Hans
So if I install MP3 support, I get as dependancies the KDE mp3 plugins and an entire KDE multimedia subsystem, even though I don't use KDE?
This seems to fail to take into account what it is we want to support mp3s, and how we want to do it. On the one hand that seems like more info than the user cares about, but on the other hand, if you end up pulling two desktop environments along with your single codec for dependancies (I've seen a few fedora users who did not realize they had a full KDE install on their system because they installed a few QT-based games).
Bill Crawford wrote:
On 12/09/2007, Jima jima@beer.tclug.org wrote:
Couldn't this be managed by rpmfusion using a comps file, and grouping various packages with "DVD support," "MP3 support," or whatnot? `yum groupinstall "DVD Support"`...
I think that's the best suggestion on how to balance packaging versus usability, so far ...
From the UI perspective, many users will indeed want to just say "give
me support for playing MP3" or "I want to watch a DVD now".
On Wed, 12 Sep 2007 18:44:40 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
No, it's not, if you don't change anything after activating livna. Only if you unselect the gnome group (which is enabled by default) once and select it again, then the livna-package gets added as well.
I wonder if this is different if you kickstart and add the repo in kickstart. Might be worth trying.
Casey Dahlin wrote:
So if I install MP3 support, I get as dependancies the KDE mp3 plugins and an entire KDE multimedia subsystem, even though I don't use KDE?
This seems to fail to take into account what it is we want to support mp3s, and how we want to do it. On the one hand that seems like more info than the user cares about, but on the other hand, if you end up pulling two desktop environments along with your single codec for dependancies (I've seen a few fedora users who did not realize they had a full KDE install on their system because they installed a few QT-based games).
If they didn't know and they can miss the diskspace, then why is this a problem?
Regards,
Hans
Bill Crawford (billcrawford1970@gmail.com) said:
I think that's the best suggestion on how to balance packaging versus usability, so far ...
From the UI perspective, many users will indeed want to just say "give
me support for playing MP3" or "I want to watch a DVD now".
Why not just have the package system key off of mime-types when you try and play a file?
Bill
Thorsten Leemhuis wrote:
On 12.09.2007 18:12, Rex Dieter wrote:
Thorsten Leemhuis wrote:
On 12.09.2007 17:44, Bill Crawford wrote:
On 12/09/2007, Jima jima@beer.tclug.org wrote:
Couldn't this be managed by rpmfusion using a comps file, and grouping various packages with "DVD support," "MP3 support," or whatnot? `yum groupinstall "DVD Support"`...
I think that's the best suggestion on how to balance packaging versus usability, so far ...
FYI for Livna I tried something else, but it didn't work out. I just used the same groups as Fedora in Livna (as Fedora Extras did in the past for Core as well) and made some crucial packages 'type="default"' -- for example gstreamer-plugins-ugly for the "GNOME Desktop Environment" . I assumed anaconda would then install gstreamer-plugins-ugly by default as "GNOME Desktop Environment" is selected by default. But anaconda/pirut did not do that (and I assume it still don't).
At our site,
kde-redhat?
@ UNL.
We add items to various groups, say, kde-desktop, and then $ yum groupinstall kde-desktop not only includes the fedora items, but our added ones as well.
-- Rex
On Wed, 2007-09-12 at 14:14 -0400, Jesse Keating wrote:
On Wed, 12 Sep 2007 18:44:40 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
No, it's not, if you don't change anything after activating livna. Only if you unselect the gnome group (which is enabled by default) once and select it again, then the livna-package gets added as well.
I wonder if this is different if you kickstart and add the repo in kickstart. Might be worth trying.
It is because then the repo gets set up "initially"
When doing the interactive install, we don't take the time hit of having to re-determine all of the defaults, etc based on the added repo. That said, some future (F9 hopefully; didn't have enough time to get it all in for F8) changes might make that a lot less painful
Jeremy
On 12.09.2007 20:14, Jesse Keating wrote:
On Wed, 12 Sep 2007 18:44:40 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
No, it's not, if you don't change anything after activating livna. Only if you unselect the gnome group (which is enabled by default) once and select it again, then the livna-package gets added as well.
I wonder if this is different if you kickstart and add the repo in kickstart. Might be worth trying.
Well, I don't think it will change anything even if it does work.
Reply from Jeremy in https://bugzilla.redhat.com/show_bug.cgi?id=239167#c1 :
Adding the repository happens _after_ the default packages are selected (also, the default selection is under control of anaconda and not entirely based on the comps file). For F7 at least, this isn't going to change. With some of the bigger changes with how package repositories tie in with package selections, etc, this may end up changing in the future but not guaranteed to do so.
I have no idea if anything changed for F8.
CU knurd
On 12.09.2007 20:27, Rex Dieter wrote:
Thorsten Leemhuis wrote:
On 12.09.2007 18:12, Rex Dieter wrote:
Thorsten Leemhuis wrote:
On 12.09.2007 17:44, Bill Crawford wrote:
On 12/09/2007, Jima jima@beer.tclug.org wrote:
Couldn't this be managed by rpmfusion using a comps file, and grouping various packages with "DVD support," "MP3 support," or whatnot? `yum groupinstall "DVD Support"`...
I think that's the best suggestion on how to balance packaging versus usability, so far ...
FYI for Livna I tried something else, but it didn't work out. I just used the same groups as Fedora in Livna (as Fedora Extras did in the past for Core as well) and made some crucial packages 'type="default"' -- for example gstreamer-plugins-ugly for the "GNOME Desktop Environment" . I assumed anaconda would then install gstreamer-plugins-ugly by default as "GNOME Desktop Environment" is selected by default. But anaconda/pirut did not do that (and I assume it still don't).
At our site,
kde-redhat?
@ UNL. We add items to various groups, say, kde-desktop, and then $ yum groupinstall kde-desktop not only includes the fedora items, but our added ones as well.
That should work for livna as well. Say you installed with KDE and now want to switch to gnome you should get the gstreamer-plugins-ugly as well. Other way around worked, too -- but I did not try it in the past past months.
But it does not work directly in the installer properly...
Cu knurd
On Wed, 2007-09-12 at 12:00 -0600, Richi Plana wrote:
On Wed, 2007-09-12 at 21:49 +0530, Rahul Sundaram wrote:
I am not talking about any repo files. Just a pointer in documentation or in any application. The details are explained in FAB list. That requires Legal to look into this. No amount of layman arguments can help us make a decision and legal perspectives doesn't always make logical sense which many tend to assume.
In other words, Fedora's lawyers have deemed it risky (or even downright illegal) to include in the distro .repo files that would allow users to download, say, US-illegal codecs even if the repository itself physically and logistically isn't connected to Fedora. But pointers in documents can.
There we go. That's what the legal experts are saying. Do I have it about right?
It's called contributory infringement.
In the United States, 35 U.S.C. § 271(b) defines (active) induced infringement: "Whoever actively induces infringement of a patent shall be liable as an infringer."
This means, we cannot point to a repo which contains software which infringes upon software patents, or we are just as liable as the people actually infringing the patents. We can't include a repo file, nor can we say "the files are over there".
Not in CodecBuddy, not in yum, not in a tree, not with a cat.
No.
~spot
On 9/12/07, Hans de Goede j.w.r.degoede@hhs.nl wrote:
I think this is a bad idea, we really want the user to have todo less to get a complete set of codecs, not more.
Am I reading this correctly... are you arguing that aggregation is advisable at the packaging level for gstreamer plugins. Doesn't this contradict your previously communicated view that upstream aggregation is un-advisable as expressed for the case of kdesdk?
Welcome to my world of gray.
-jef"or is it grey?"spaleta
On 12.09.2007 20:28, Jeremy Katz wrote:
On Wed, 2007-09-12 at 14:14 -0400, Jesse Keating wrote:
On Wed, 12 Sep 2007 18:44:40 +0200
[...] When doing the interactive install, we don't take the time hit of having to re-determine all of the defaults, etc based on the added repo. That said, some future (F9 hopefully; didn't have enough time to get it all in for F8) changes might make that a lot less painful
thx Jeremy for clarifying that (and tia for fixing it in the long term hopefully). I'll think about a solution for rpmfusion (likely the rpmfusion specific groups -- that's not perfect, but better than nothing. I even always wanted to do that for livna in the past months as well, but did not come around to it...)
CU knurd
Le mercredi 12 septembre 2007 à 08:17 -0800, Jeff Spaleta a écrit :
On 9/12/07, Les Mikesell lesmikesell@gmail.com wrote:
Or, if you need another level of indirection, include a repo that doesn't itself have anything controversial but has a package that configures yum for repos that might.
oh classy. So how would that work from a user perspective?
I hope yum has a check somewhere to forbid installation of unknown default-on repositories.
On Wed, 2007-09-12 at 21:42 +0200, Nicolas Mailhot wrote:
Le mercredi 12 septembre 2007 à 08:17 -0800, Jeff Spaleta a écrit :
On 9/12/07, Les Mikesell lesmikesell@gmail.com wrote:
Or, if you need another level of indirection, include a repo that doesn't itself have anything controversial but has a package that configures yum for repos that might.
oh classy. So how would that work from a user perspective?
I hope yum has a check somewhere to forbid installation of unknown default-on repositories.
how on earth would yum know? Do you want yum to have special behavior if it detects a .repo file? That's just ludicrous. If you cannot trust the repo then don't use it. That's it.
-sv
Le mercredi 12 septembre 2007 à 21:42 +0200, Nicolas Mailhot a écrit :
Le mercredi 12 septembre 2007 à 08:17 -0800, Jeff Spaleta a écrit :
On 9/12/07, Les Mikesell lesmikesell@gmail.com wrote:
Or, if you need another level of indirection, include a repo that doesn't itself have anything controversial but has a package that configures yum for repos that might.
oh classy. So how would that work from a user perspective?
I hope yum has a check somewhere to forbid installation of unknown default-on repositories.
There is a difference between trusting a repo and trusting it to authorize other repos
On Wed, 2007-09-12 at 22:58 +0200, Nicolas Mailhot wrote:
Le mercredi 12 septembre 2007 à 21:42 +0200, Nicolas Mailhot a écrit :
Le mercredi 12 septembre 2007 à 08:17 -0800, Jeff Spaleta a écrit :
On 9/12/07, Les Mikesell lesmikesell@gmail.com wrote:
Or, if you need another level of indirection, include a repo that doesn't itself have anything controversial but has a package that configures yum for repos that might.
oh classy. So how would that work from a user perspective?
I hope yum has a check somewhere to forbid installation of unknown default-on repositories.
There is a difference between trusting a repo and trusting it to authorize other repos
trusting the repo to have packagers who won't do that stuff.
-sv
On 9/12/07, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
There is a difference between trusting a repo and trusting it to authorize other repos
This is a rat hole. If repositories are going to maliciously add additional repositories, then the packages from that repo can very well do pretty much all sorts of malicious reconfiguration. I don't see why repo configuration is any more sensitive than other package payloads or scriptlet actions. Hell you don't even need to add an additional file all you need to do is add additional repository definitions in the repo file you already provide. I simply don't understand how you could protect a client system from a repository that wanted to ensure that a new repository definition was installed and enabled by default.
On top of that there are justifiable reasons to need to add additional repo files and additional repository tags inside a repo file due to repository re-organization.
-jef
[12.Eyl.07 15:43 -0400] seth vidal:
On Wed, 2007-09-12 at 21:42 +0200, Nicolas Mailhot wrote:
I hope yum has a check somewhere to forbid installation of unknown default-on repositories.
how on earth would yum know? Do you want yum to have special behavior if it detects a .repo file?
Not for .repo files, but it would be nice to check for GPG keys it installs.
If you cannot trust the repo then don't use it.
Building a chain of trust that way looks wrong.
Unfortunately, because Red Hat IS a USA-based company, they (and all us Americans) cannot make a distro available that is directly connected in ANY fashion to repositories containing patented technologies that do not have an license explicitly stating that there will be no repercussions for such aforementioned inclusion scenarios to be applied. This is why Fedora has such a bad rep (I am not saying it is a bad distro, I use it for everything!) with uninformed people (people making the choice of using Linux for the first time). Though I think CodecBuddy NEEDS support for reading through repositories to find codecs because there ARE Free codecs not in the Fedora DVD by default and should be able to be detected and installed.
On 9/12/07, Tom spot Callaway tcallawa@redhat.com wrote:
On Wed, 2007-09-12 at 08:38 -0500, Les Mikesell wrote:
Or - why not move the entire repo to places that can have all the contents? What's the point of even worrying about this issue?
It's not where the repo sits, its where Red Hat is based out of.
~spot
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
We might be in hot water still, but at least liability could possibly not be claimed if it is in the Terms of Use of this community list of repositories...
On 9/12/07, Casey Dahlin cjdahlin@ncsu.edu wrote:
King InuYasha wrote:
Unfortunately, because Red Hat IS a USA-based company, they (and all us Americans) cannot make a distro available that is directly connected in ANY fashion to repositories containing patented technologies that do not have an license explicitly stating that there will be no repercussions for such aforementioned inclusion scenarios to be applied. This is why Fedora has such a bad rep (I am not saying it is a bad distro, I use it for everything!) with uninformed people (people making the choice of using Linux for the first time). Though I think CodecBuddy NEEDS support for reading through repositories to find codecs because there ARE Free codecs not in the Fedora DVD by default and should be able to be detected and installed.
Maybe web2.0 is the solution :) . What if we have a way to query a list of repos that is stored on a central site that can be appended to by anyone? Then we might be able to disclaim responsibility for pointing it out.
Except that now it's mentioned on the list, and will be in the publicly viewable list archives, which smacks of premeditation. ;)
On 9/12/07, *Tom spot Callaway* <tcallawa@redhat.com mailto:tcallawa@redhat.com> wrote:
On Wed, 2007-09-12 at 08:38 -0500, Les Mikesell wrote: > Or - why not move the entire repo to places that can have allthe
> contents? What's the point of even worrying about this issue? It's not where the repo sits, its where Red Hat is based out of. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com <mailto:fedora-devel-list@redhat.com> https://www.redhat.com/mailman/listinfo/fedora-devel-list <https://www.redhat.com/mailman/listinfo/fedora-devel-list>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
King InuYasha wrote:
Unfortunately, because Red Hat IS a USA-based company, they (and all us Americans) cannot make a distro available that is directly connected in ANY fashion to repositories containing patented technologies that do not have an license explicitly stating that there will be no repercussions for such aforementioned inclusion scenarios to be applied. This is why Fedora has such a bad rep (I am not saying it is a bad distro, I use it for everything!) with uninformed people (people making the choice of using Linux for the first time). Though I think CodecBuddy NEEDS support for reading through repositories to find codecs because there ARE Free codecs not in the Fedora DVD by default and should be able to be detected and installed.
Maybe web2.0 is the solution :) . What if we have a way to query a list of repos that is stored on a central site that can be appended to by anyone? Then we might be able to disclaim responsibility for pointing it out.
On 9/12/07, *Tom spot Callaway* <tcallawa@redhat.com mailto:tcallawa@redhat.com> wrote:
On Wed, 2007-09-12 at 08:38 -0500, Les Mikesell wrote: > Or - why not move the entire repo to places that can have all the > contents? What's the point of even worrying about this issue? It's not where the repo sits, its where Red Hat is based out of. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com <mailto:fedora-devel-list@redhat.com> https://www.redhat.com/mailman/listinfo/fedora-devel-list <https://www.redhat.com/mailman/listinfo/fedora-devel-list>
We might be in hot water still, but at least liability could possibly not be claimed if it is in the Terms of Use of this community list of repositories...
On 9/12/07, Casey Dahlin cjdahlin@ncsu.edu wrote:
King InuYasha wrote:
Unfortunately, because Red Hat IS a USA-based company, they (and all us Americans) cannot make a distro available that is directly connected in ANY fashion to repositories containing patented technologies that do not have an license explicitly stating that there will be no repercussions for such aforementioned inclusion scenarios to be applied. This is why Fedora has such a bad rep (I am not saying it is a bad distro, I use it for everything!) with uninformed people (people making the choice of using Linux for the first time). Though I think CodecBuddy NEEDS support for reading through repositories to find codecs because there ARE Free codecs not in the Fedora DVD by default and should be able to be detected and installed.
Maybe web2.0 is the solution :) . What if we have a way to query a list of repos that is stored on a central site that can be appended to by anyone? Then we might be able to disclaim responsibility for pointing it out.
On 9/12/07, *Tom spot Callaway* <tcallawa@redhat.com mailto:tcallawa@redhat.com> wrote:
On Wed, 2007-09-12 at 08:38 -0500, Les Mikesell wrote: > Or - why not move the entire repo to places that can have all the > contents? What's the point of even worrying about this issue? It's not where the repo sits, its where Red Hat is based out of. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com <mailto:fedora-devel-list@redhat.com> https://www.redhat.com/mailman/listinfo/fedora-devel-list <https://www.redhat.com/mailman/listinfo/fedora-devel-list>-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
<rant> You know what!!?!?!?
Software Patents suck... So do algorithm patents on ubiquitous things, like mp3.... and stupid licensing like for DVD, etc. </rant>
Now that it is out of my system.... Then how do you propose to be able to point to them without stabbing yourselves? It would be nice if some of the this problem could be fixed, and CodecBuddy doesn't count.... If Fedora had something like Ubuntu's codec searcher, then I would be happy. But we don't have that, and that is probably the only thing that Ubuntu has that I want in Fedora....
On 9/12/07, Tom spot Callaway tcallawa@redhat.com wrote:
On Wed, 2007-09-12 at 22:00 -0500, King InuYasha wrote:
We might be in hot water still, but at least liability could possibly not be claimed if it is in the Terms of Use of this community list of repositories...
We're almost certainly still liable. Sorry.
~spot
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On 9/12/07, King InuYasha ngompa13@gmail.com wrote:
<rant> You know what!!?!?!?
Software Patents suck... So do algorithm patents on ubiquitous things, like mp3.... and stupid licensing like for DVD, etc.
</rant>
Now that it is out of my system.... Then how do you propose to be able to point to them without stabbing yourselves? It would be nice if some of the this problem could be fixed, and CodecBuddy doesn't count.... If Fedora had something like Ubuntu's codec searcher, then I would be happy. But we don't have that, and that is probably the only thing that Ubuntu has that I want in Fedora....
Other than moving the entire personell and company to outside of the US.. and not doing business in the US.. not sure.
Le mercredi 12 septembre 2007 à 19:15 -0500, King InuYasha a écrit :
Unfortunately, because Red Hat IS a USA-based company, they (and all us Americans) cannot make a distro available that is directly connected in ANY fashion to repositories containing patented technologies that do not have an license explicitly stating that there will be no repercussions for such aforementioned inclusion scenarios to be applied.
I'd have an evil plan. That would be to register rpmfusion.us and rpmfusion.eu (or rpmfusion.org), have all fedora docs point to rpmfusion.us, and do whatever is possible outside of USA in the other one.
I wonder if that'd satisfy lawyers.
Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
I'd have an evil plan. That would be to register rpmfusion.us and rpmfusion.eu (or rpmfusion.org), have all fedora docs point to rpmfusion.us, and do whatever is possible outside of USA in the other one.
Unfortunately, I think many users wouldn't find the real rpmfusion that way.
Kevin Kofler
Richi Plana wrote:
On Wed, 2007-09-12 at 21:49 +0530, Rahul Sundaram wrote:
I am not talking about any repo files. Just a pointer in documentation or in any application. The details are explained in FAB list. That requires Legal to look into this. No amount of layman arguments can help us make a decision and legal perspectives doesn't always make logical sense which many tend to assume.
In other words, Fedora's lawyers have deemed it risky (or even downright illegal) to include in the distro .repo files that would allow users to download, say, US-illegal codecs even if the repository itself physically and logistically isn't connected to Fedora. But pointers in documents can.
There we go. That's what the legal experts are saying. Do I have it about right?
We do not know yet if pointers to a repository are ok since the legal situation has changed.
http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/2717
Last time we consulted with legal, it was ok to point a website as long as it didn't host directly such a software repository and we didn't include information on what to find in such websites (ie) pointing to a website like fedorafaq.org is ok as long as we don't tell them "go here for mp3 codecs".
Rahul
Le Jeu 13 septembre 2007 08:46, Kevin Kofler a écrit :
Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
I'd have an evil plan. That would be to register rpmfusion.us and rpmfusion.eu (or rpmfusion.org), have all fedora docs point to rpmfusion.us, and do whatever is possible outside of USA in the other one.
Unfortunately, I think many users wouldn't find the real rpmfusion that way.
But then one could have documentation and word-of-mouth documenting one just has to replace .us with .org/.eu in the fedora-approved repo files for stuff to just work. Not to mention the power of google in that case - I doubt it would rank the .eu site higher than the other one.
On Thu, 2007-09-13 at 13:20 +0530, Rahul Sundaram wrote:
We do not know yet if pointers to a repository are ok since the legal situation has changed.
http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/2717
Last time we consulted with legal, it was ok to point a website as long as it didn't host directly such a software repository and we didn't include information on what to find in such websites (ie) pointing to a website like fedorafaq.org is ok as long as we don't tell them "go here for mp3 codecs".
Since I'm now the "Fedora Legal Contact Person", I formally relayed this question to the Red Hat lawyers 10 minutes ago (in person, no less).
They're going to get back to me with a response.
~spot
Tom "spot" Callaway wrote:
On Thu, 2007-09-13 at 13:20 +0530, Rahul Sundaram wrote:
We do not know yet if pointers to a repository are ok since the legal situation has changed.
http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/2717
Last time we consulted with legal, it was ok to point a website as long as it didn't host directly such a software repository and we didn't include information on what to find in such websites (ie) pointing to a website like fedorafaq.org is ok as long as we don't tell them "go here for mp3 codecs".
Since I'm now the "Fedora Legal Contact Person", I formally relayed this question to the Red Hat lawyers 10 minutes ago (in person, no less).
Thanks very much. I have been trying to get someone to do it for months together now with pretty much no response.
They're going to get back to me with a response.
Excellent. Do you want to be listed as the legal contact in http://fedoraproject.org/wiki/Legal instead of Max Spevack?
Rahul
On Thu, 2007-09-13 at 20:12 +0530, Rahul Sundaram wrote:
Excellent. Do you want to be listed as the legal contact in http://fedoraproject.org/wiki/Legal instead of Max Spevack?
Yep. I talked to Max about that yesterday and he was more than happy to pass that burden on to me.
~spot
Tom "spot" Callaway wrote:
On Thu, 2007-09-13 at 20:12 +0530, Rahul Sundaram wrote:
Excellent. Do you want to be listed as the legal contact in http://fedoraproject.org/wiki/Legal instead of Max Spevack?
Yep. I talked to Max about that yesterday and he was more than happy to pass that burden on to me.
I have updated the page. You might want to get legal AT fedoraproject.org to point to you now.
Rahul
Is there a way for new packagers to get involved with RPM Fusion? I have a set of packages that can't go into Fedora's main repository for various reasons (emulators, non-free, etc.) and would be willing to maintain the packages for them.
Kelly Miller wrote:
Is there a way for new packagers to get involved with RPM Fusion? I have a set of packages that can't go into Fedora's main repository for various reasons (emulators, non-free, etc.) and would be willing to maintain the packages for them.
Hi,
Yes new packagers are invited to join us, please subscribe to: http://lists.fedoraunity.org/mailman/listinfo/repo-merge-discussion
And introduce yourself there, the review procedure for rpmfusion will be just like the one for Fedora, except that we won't be using flags (we will probably be using blocker bugs but this still needs to be discussed).
You can file review requests for any packages you have ready for review here: https://bugzilla.rpmfusion.org/
I just noticed that we currently don't have a package review component, I will ask the bugzilla admin to add one in the mean time just pick any component, we will reassign the bug to to a more appropriate component when that becomes available.
Regards,
Hans
On 13.09.2007 20:03, Hans de Goede wrote:
Kelly Miller wrote:
Is there a way for new packagers to get involved with RPM Fusion? I have a set of packages that can't go into Fedora's main repository for various reasons (emulators, non-free, etc.) and would be willing to maintain the packages for them.
[...] And introduce yourself there, the review procedure for rpmfusion will be just like the one for Fedora, except that we won't be using flags (we will probably be using blocker bugs but this still needs to be discussed).
+1 for blocker bugs
You can file review requests for any packages you have ready for review here: https://bugzilla.rpmfusion.org/
One note: before submitting packages please check if you package is in either freshrpms, dribble or livna already. If it is it's likely that the old maintainer will take care of it in rpmfusion as well (but maybe you can help as co-maintainer)
[...]
CU knurd
On 12/09/2007, Brian Pepple bpepple@fedoraproject.org wrote:
On Wed, 2007-09-12 at 08:27 -0800, Jeff Spaleta wrote:
...
The discussion on how gstreamer's source codebase needs to be happening with gstreamer upstream.
+1. This should be worked out upstream.
Source packaging != binary packaging ...
glibc comes as several packages (glibc-common, glibc, glibc-headers, nscd, glibc-devel) which are all built from a single source package (glibc).
If we're going to argue that upstream packaging should reflect this ...
On 12/09/2007, Jeff Spaleta jspaleta@gmail.com wrote: ...
-jef"Anyone happen to have a C implementation of the generalized Lomb periodogram for quadrature signals with Lagrangian amplitude envelope decay functions just sitting around collecting dust that I could mooch?"spaleta
If you can transform them to runge-kutta form there's an old IOCCC entry that might do it for you ... ;)
On 9/14/07, Ian Chapman packages@amiga-hardware.com wrote:
Rodd Clarkson wrote:
Oh and could this be used for setting my paper preference to A4 by default instead of having to change this each time I set up a printer?
+1 - love it! :-)
Hmmm for some reason I have to change my paper to Letter from A4 every time I setup a printer in various applications..
Hans de Goede wrote:
We don't have a repository ready for end users yet, but we are actively working on merging the following ones:
* http://dribble.org.uk/ * http://freshrpms.net/ * http://rpm.livna.org/
Cool...
Have you spoken to the guys over at RPMforge too? They have a load of high-quality packages and perhaps they would be a good partner in this as well... Even if it's just by agreeing now to step on each other. :)
Cheers!
/Thomas
Umm, freshrpms.net is part of RPMForge last I checked, but, also last I checked, RPMForge was mostly RHEL packages....
On 9/15/07, Thomas M Steenholdt tmus@tmus.dk wrote:
Hans de Goede wrote:
We don't have a repository ready for end users yet, but we are actively working on merging the following ones:
* http://dribble.org.uk/ * http://freshrpms.net/ * http://rpm.livna.org/Cool...
Have you spoken to the guys over at RPMforge too? They have a load of high-quality packages and perhaps they would be a good partner in this as well... Even if it's just by agreeing now to step on each other. :)
Cheers!
/Thomas
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
[13.Eyl.07 01:36 +0300] Sertaç Ö. Yıldız:
[12.Eyl.07 15:43 -0400] seth vidal:
On Wed, 2007-09-12 at 21:42 +0200, Nicolas Mailhot wrote:
I hope yum has a check somewhere to forbid installation of unknown default-on repositories.
how on earth would yum know? Do you want yum to have special behavior if it detects a .repo file?
Not for .repo files, but it would be nice to check for GPG keys it installs.
On a second thought, I realized that yum cannot do anything about trust at the moment. And my mindset about trust here (based on public keys being installed or not) was completely flawed. I’ve seen a package executing “rpm --import” from postinstall scriptlet and maybe it’s possible even from preinstall.
If I cannot express my distrust on a repository (or specifically a public key) I cannot express my trust either. And probably this must be solved at the rpm level.
Rpm apparently has some (undocumented) code about this: | $ rpm --trust | --trust: missing argument
But IIUC at the moment it handles the situation similar to what I’d thought: NOTTRUSTED is similar to NOKEY.
As it is, GPG signature verification reduces to a mere integrity check if one wants to use external repositories.
On 9/11/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Jesse Keating wrote:
On Tue, 11 Sep 2007 20:02:40 +0000 (UTC) Kevin Kofler kevin.kofler@chello.at wrote:
Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
Thanks for this split. Hopefully we will able to link to the free part from within Fedora.
Unfortunately I don't think you will be able to. The stuff in the free part (or most of it, at least) is going to be exactly the stuff which Legal is most uncomfortable with: Free Software, but patent-encumbered in the US.
And really, if we could reference it, then why the crap couldn't we just package it in our repo?
There is a lot of differences between pointing to the repository and including the packages directly as I already explained in Fedora Advisory Board list so I won't rehash all the arguments again now. Please read the releated threads if you missed it. In short, it is not possible to include patent-encumbered packages directly in the repository as long as it hosted in US. Pointing to it might very well be possible.
Rahul
Yes! I cought a bit late on this thread but I can't be happier! I started a threat that asked this exact question: why doesn't fedora link to external repositories after users agreeing to some sort of ULA.
What is the update on this topic? I really hope fedora goes ahead and links to sites outside US that can legally host files.
It is a shame that worldwide users had to "suffer" because of US legislative even if their countries (like mine) don't recognize software patents.
Hope this changes in the future so please post a quick reply about status of this issue.
Thank you in advance, Valent.
Valent Turkovic wrote:
On 9/11/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Jesse Keating wrote:
On Tue, 11 Sep 2007 20:02:40 +0000 (UTC) Kevin Kofler kevin.kofler@chello.at wrote:
Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
Thanks for this split. Hopefully we will able to link to the free part from within Fedora.
Unfortunately I don't think you will be able to. The stuff in the free part (or most of it, at least) is going to be exactly the stuff which Legal is most uncomfortable with: Free Software, but patent-encumbered in the US.
And really, if we could reference it, then why the crap couldn't we just package it in our repo?
There is a lot of differences between pointing to the repository and including the packages directly as I already explained in Fedora Advisory Board list so I won't rehash all the arguments again now. Please read the releated threads if you missed it. In short, it is not possible to include patent-encumbered packages directly in the repository as long as it hosted in US. Pointing to it might very well be possible.
Rahul
Yes! I cought a bit late on this thread but I can't be happier! I started a threat that asked this exact question: why doesn't fedora link to external repositories after users agreeing to some sort of ULA.
What is the update on this topic?
We are still waiting on legal input.
Rahul
On 9/11/07, Casey Dahlin cjdahlin@ncsu.edu wrote:
Kevin Kofler wrote:
Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
Thanks for this split. Hopefully we will able to link to the free part from within Fedora.
Unfortunately I don't think you will be able to. The stuff in the free part (or most of it, at least) is going to be exactly the stuff which Legal is most uncomfortable with: Free Software, but patent-encumbered in the US.
There's a wide spectrum between "right in Fedora" and "not acknowledging its existence."
Whereas before Red Hat became subject to liability for merely saying the word "Livna" in public, we might be able to move to a tacit and well-disclaimed "suggestion" that users use the Free half of rpmfusion. So we could go from having to say "Never heard of it" to being able to say "Its over there, and I know about it, but I really can't recommend that you use it (by clicking this button right here)"
ha, ha :) great idea the "don't click this button" button :)
On 9/12/07, Rodd Clarkson rodd@clarkson.id.au wrote:
On Tue, 2007-09-11 at 16:53 -0800, Jeff Spaleta wrote:
On 9/11/07, Rodd Clarkson rodd@clarkson.id.au wrote:
The installer asks you to locate your time-zone. Couldn't you use this as a trigger for including the US patent encumbered stuff for non US citizens.
I'm pretty sure it would be just as inappropriate for me, as a US citizen, to be in a US embassy in Spain as it would be for me to be in Seattle.
Okay, well then include a question about citizenship in the installer and use that!
R.
Yup, I support that. There a lot of us - non US fedora users and we would really welcome these changes.
Valent from Croatia.
On 10/25/07, Valent Turkovic valent.turkovic@gmail.com wrote:
On 9/12/07, Rodd Clarkson rodd@clarkson.id.au wrote:
On Tue, 2007-09-11 at 16:53 -0800, Jeff Spaleta wrote:
On 9/11/07, Rodd Clarkson rodd@clarkson.id.au wrote:
The installer asks you to locate your time-zone. Couldn't you use this as a trigger for including the US patent encumbered stuff for non US citizens.
I'm pretty sure it would be just as inappropriate for me, as a US citizen, to be in a US embassy in Spain as it would be for me to be in Seattle.
Okay, well then include a question about citizenship in the installer and use that!
R.
Yup, I support that. There a lot of us - non US fedora users and we would really welcome these changes.
Valent from Croatia.
I'm technically a non US fedora user. But you gentlemen have to understand the situation - RedHat's base is registered in the USA. And RedHat's legal team has enough work to do defending itself from patent trolls, and possibly Judases to really attempt to fight for things like "boxed" codecs, etc.
devel@lists.stg.fedoraproject.org
-
Arthur Pemberton -
Bill Crawford -
Bill Nottingham -
Brian Pepple -
Casey Dahlin -
Chris Jones -
Christopher Brown -
Christopher Stone -
David Hollis -
Hans de Goede -
Ian Chapman -
Jarod Wilson -
Jarosław Górny -
Jef Spaleta -
Jeremy Katz -
Jeroen van Meeuwen -
Jesse Keating -
Jima -
Jon Ciesla -
Jonathan Steffan -
Kelly Miller -
Kevin Kofler -
Les Mikesell -
Michel Salim -
Neal Gompa -
Nicolas Mailhot -
Nicu Buculei -
Phil Knirsch -
Rahul Sundaram -
Rex Dieter -
Richi Plana -
Rodd Clarkson -
Sertaç Ö. Yıldız -
Seth Vidal -
Stephen John Smoogen -
Thomas M Steenholdt -
Thorsten Leemhuis -
Tom Callaway -
Valent Turkovic -
Warren Togami