Re: [gentoo-dev] SourceForge changed all Git URLs
Nikos Chantziaras schrieb: This is a heads-up to all devs who provide/maintain live ebuilds of projects hosted on SourceForge. Live ebuilds won't work anymore. EGIT_REPO_URI has to updated on all ebuilds. Appending /projectname should be enough (for example, git://lmms.git.sourceforge.net/gitroot/lmms should become git://lmms.git.sourceforge.net/gitroot/lmms/lmms). Does this only affect the git repo urls or also svn etc? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: SourceForge changed all Git URLs
On 09/04/2009 09:14 AM, Justin wrote: Nikos Chantziaras schrieb: This is a heads-up to all devs who provide/maintain live ebuilds of projects hosted on SourceForge. Live ebuilds won't work anymore. EGIT_REPO_URI has to updated on all ebuilds. Appending /projectname should be enough (for example, git://lmms.git.sourceforge.net/gitroot/lmms should become git://lmms.git.sourceforge.net/gitroot/lmms/lmms). Does this only affect the git repo urls or also svn etc? Only Git.
Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
On Mon, Aug 31, 2009 at 5:12 PM, Mounir Lamourivolk...@gentoo.org wrote: It's even worst when we try to use ACCEPT_LICENSE to have a free operating system. FWIW: Given the state of ebuilds, I think this should never be attempted unless the user knows it may not be accurate[1]. We should not attempt to guarantee such statement, IMO. LGPL-2.1 is free for both but LGPL-2 isn't and we can suppose, most LGPL-2 licensed packages in the tree are LGPL-2+ actually. How are we, the non-lawyer types, suppose to know that? TBH, I don't care and am not going to put much effort beyond reading the header of COPYING or glancing at the HOMEPAGE to see what license they are using. I think you are attempting to add much complexity to ebuilds that will ultimately fail. Of course, you can volunteer to audit every license and every ebuild. Thanks in advance for that =P Thanks for putting work into making Gentoo better, I just am not convinced on this subject. -Jeremy [1]: Look at how long bug 268796 took to get resolved. 4 months, rather quickly too. Ebuilds stated GPL-2, when they were in fact BSD, GPL-3, LGPL-2.
Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)
Le 03/09/2009 23:27, Mounir Lamouri a écrit :
But the content of the license is the same. That only means you can use
a newer one.
I mean we do not need a new license file for that. It's up to upstream
to write somewhere if it's GPL-2 or GPL-2+, am I right ?
Yes, that's for upstream to figure out. For instance, the kernel is
GPL-2 only while some other pacakges are 2+.
I don't want to sound like an ass, but that's why I think we shouldn't
bother too much with LICENSE and all that stuff.
We're not _lawyers_. None of us can guarantee that :
1) the LICENSE field in our ebuilds are correctly set according to what
upstream says.
2) that the actual code of the package is indeed under that license and
not tainted by some other code.
For instance, I'm still working on migrating all the X11 packages to the
MIT license (mainly for cleaning purposes), but in fact, each and
every package should have its own license file (like today) because the
MIT license requires that we acknowledge all major contributions to the
code. Therefore, using a template like ${PORTAGE}/licences/MIT does is
probably not a good idea from a legal point of view.
And the X code being over 15 years old, only God knows who we should be
thanking for this million lines of code.
While you're idea is very nice on paper, actually doing it requires much
_much_ more work than just adding operators and sets to portage.
Rémi
Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)
On Friday 04 September 2009 16:01:41 Rémi Cardona wrote:
For instance, I'm still working on migrating all the X11 packages to the
MIT license (mainly for cleaning purposes), but in fact, each and
every package should have its own license file (like today) because the
MIT license requires that we acknowledge all major contributions to the
code. Therefore, using a template like ${PORTAGE}/licences/MIT does is
probably not a good idea from a legal point of view.
Is that really a problem? I admit to not being around for the original design
decisions, but I would assume that the purpose of having LICENSE in ebuilds
is to tell users what licence the package is under (whether or not it's
accurate is a different matter), and the purpose of having the licences
themselves in the tree is so that it's easy for users to look them up and
decide whether they want to accept the conditions or not. For that purpose,
the exact list of credits is irrelevant. Also, I'm not a lawyer, but I would
think that the licence's requirement for credit is satisfied by the credits
being included in the source code - it doesn't require acknowledgement when
merely talking about the software or stating the fact that it's under a
particular licence, just when distributing it.
Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)
Le 04/09/2009 20:52, David Leverton a écrit : Is that really a problem? To me, it's not. :) I admit to not being around for the original design decisions, but I would assume that the purpose of having LICENSE in ebuilds is to tell users what licence the package is under (whether or not it's accurate is a different matter), and the purpose of having the licences themselves in the tree is so that it's easy for users to look them up and decide whether they want to accept the conditions or not. For that purpose, the exact list of credits is irrelevant. That was just an example to show that unless we go through a precise and thorough audit of all the packages we offer, the LICENSE variable is _informational_ at best. Having tools to manipulate those variables is very misleading since users will (rightfully) assume that we've done our homework and that upstream did too. I don't intend to stop anyone from creating new tools, but I just want us all to realize the limits of what is being done here. Cheers, Rémi
Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)
On Fri, 04 Sep 2009 22:04:46 +0200 Rémi Cardona r...@gentoo.org wrote: Having tools to manipulate those variables is very misleading since users will (rightfully) assume that we've done our homework and that upstream did too. Why not use EAPI 4 to make sure people have done that homework then? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Last rites: www-plugins/gnash
# Rémi Cardona r...@gentoo.org (04 Sep 2009) # Masked for removal in 60 days, old and unmaintained in Gentoo # Uses removed VIDEO_CARDS flag (see bug #282981) www-plugins/gnash Cheers, Rémi
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: www-plugins/gnash
Le 04/09/2009 22:41, Andrew John Hughes a écrit : So there'll be no Free Flash support in Gentoo any more? I hope someone will pick this up, this is a high priority FSF project after all. There's media-libs/swfdec that's still offically maintained by the Gnome herd. As far as gnash is concerned, it can still be saved by a willing maintainer. Nothing more, nothing less. Cheers, Rémi
Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
Mounir Lamouri wrote: However I do notice that GPL-2+ could make things easier. Why not introduce a license group for it like @GPL-2+ or so, instead? That would be transparent and use existing means. I don't understand where the black magic is. It would be in the implementation and in the non-transparency. How can a user understabnd that GPL-2+ refers to a group of license files but GPL-2 refers to a single file? He may guess but it's not obvious, especially if it hasn#t been like that in the past, which is the case. However, a group will not add the information in the ebuild. In other words, I will have GPL-2 and GPL-3 with GPL-2+ in ACCEPT_LICENSE but I will not have GPL-2+ packages if i set only GPL-3 in ACCEPT_LICENSE. I propose support for license groups in ebuilds then, I guess. Sebastian
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: www-plugins/gnash
Le vendredi 04 septembre 2009 à 22:56 +0200, Rémi Cardona a écrit : Le 04/09/2009 22:41, Andrew John Hughes a écrit : So there'll be no Free Flash support in Gentoo any more? I hope someone will pick this up, this is a high priority FSF project after all. There's media-libs/swfdec that's still offically maintained by the Gnome herd. As far as gnash is concerned, it can still be saved by a willing maintainer. Nothing more, nothing less. Cheers, Rémi Okay, if nobody want to maintain gnash, I'll maintain it... how is it possible to remove gnash ... jesus :D Regards, Romain. -- Romain Perier Gentoo Linux Developer Site: http://dev.gentoo.org/~mrpouet Blog: http://planet.gentoo.org/developers/mrpouet FP: 5728 DC13 9600 864E 2C37 7D1F 3791 7B66 3B94 72EF signature.asc Description: Ceci est une partie de message numériquement signée
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: www-plugins/gnash
I've used the gnash plugin because earlier Flash releases were so problematic (crashing Flash would generally crash Firefox). But generally migrated away from Flash as it seemed to become more and more of an advertising distribution medium that one had no user control over (this is a subjective impression). Gnash also seemed to be unable to play more recent versions of Flash files. Is gnash still under development (as an open source alternative to Adobe flash)? If so, then it would seem to make sense to keep the plugin alive. Where does this all go with the evolution towards more open media formats (HTML 3.x?). It is my impression currently that a consensus could not be agreed upon for a standard open non-proprietary format for audio/video files. Robert On 9/4/09, Romain Perier mrpo...@gentoo.org wrote: Le vendredi 04 septembre 2009 à 22:56 +0200, Rémi Cardona a écrit : Le 04/09/2009 22:41, Andrew John Hughes a écrit : So there'll be no Free Flash support in Gentoo any more? I hope someone will pick this up, this is a high priority FSF project after all. There's media-libs/swfdec that's still offically maintained by the Gnome herd. As far as gnash is concerned, it can still be saved by a willing maintainer. Nothing more, nothing less. Cheers, Rémi Okay, if nobody want to maintain gnash, I'll maintain it... how is it possible to remove gnash ... jesus :D Regards, Romain. -- Romain Perier Gentoo Linux Developer Site: http://dev.gentoo.org/~mrpouet Blog: http://planet.gentoo.org/developers/mrpouet FP: 5728 DC13 9600 864E 2C37 7D1F 3791 7B66 3B94 72EF
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: www-plugins/gnash
On 09/05/2009 01:24 AM, Robert Bradbury wrote: I've used the gnash plugin because earlier Flash releases were so problematic (crashing Flash would generally crash Firefox). But generally migrated away from Flash as it seemed to become more and more of an advertising distribution medium that one had no user control over (this is a subjective impression). Gnash also seemed to be unable to play more recent versions of Flash files. Is gnash still under development (as an open source alternative to Adobe flash)? If so, then it would seem to make sense to keep the plugin alive. Where does this all go with the evolution towards more open media formats (HTML 3.x?). It is my impression currently that a consensus could not be agreed upon for a standard open non-proprietary format for audio/video files. Flash *is* an open format; Adobe opened up its specs a while ago. It's just that the only full implementation of it isn't open (Adobe Flash).
Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
Sebastian Pipping wrote: However, a group will not add the information in the ebuild. In other words, I will have GPL-2 and GPL-3 with GPL-2+ in ACCEPT_LICENSE but I will not have GPL-2+ packages if i set only GPL-3 in ACCEPT_LICENSE. I propose support for license groups in ebuilds then, I guess. That seems like a reasonable solution. So, an ebuild can do something like LICENSE=@GPL-2+ and that will expand to whatever the definition of the GPL-2+ license group happens to be. When a new version of GPL license comes out, we simple add it to that group, and none of the corresponding ebuilds have to be updated. -- Thanks, Zac
