headers
Mike Frysinger | 1 May 2009 07:30
Picon
Favicon
Gravatar

Monthly Gentoo Council Reminder for May

This is your monthly friendly reminder !  Same bat time (typically
the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel
(#gentoo-council  <at>  irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even
vote on, let us know !  Simply reply to this e-mail for the whole
Gentoo dev list to see.

Keep in mind that every GLEP *re*submission to the council for review
must first be sent to the gentoo-dev mailing list 7 days (minimum)
before being submitted as an agenda item which itself occurs 7 days
before the meeting.  Simply put, the gentoo-dev mailing list must be
notified at least 14 days before the meeting itself.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/
Permalink | Reply | 0 comments |
headers
Jorge Manuel B. S. Vicetto | 1 May 2009 21:14
Picon
Favicon
Gravatar

proposed email - Dropping old kde3 eclasses from the tree


Hi.

As the KDE team prepares to add revised eclasses for the KDE3 ebuilds so
we can get 3.5.10 marked stable and then finally ask for KDE4
stabilization, we'd like to drop some old eclasses from the tree. We
plan to drop the kde-base, kde-dist, kde-i18n and kde-source eclasses as
they're no longer used.
So unless someone has any objections, we'll drop the eclasses from the
tree in the next few days.

In case anyone has any doubts about portage reliance on the eclasses,
let me quote Zac:

#gentoo-dev 20:19 < <at> zmedico> jmbsvicetto: it's only an issue for people
upgrading from less than portage-2.1.4, which is pretty rare nowadays

For the KDE team,

--
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
Permalink | Reply | 7 comments |
headers
Petteri Räty | 1 May 2009 21:33
Picon
Favicon

Re: proposed email - Dropping old kde3 eclasses from the tree

Jorge Manuel B. S. Vicetto wrote:
> Hi.
> 
> As the KDE team prepares to add revised eclasses for the KDE3 ebuilds so
> we can get 3.5.10 marked stable and then finally ask for KDE4
> stabilization, we'd like to drop some old eclasses from the tree. We
> plan to drop the kde-base, kde-dist, kde-i18n and kde-source eclasses as
> they're no longer used.
> So unless someone has any objections, we'll drop the eclasses from the
> tree in the next few days.
> 
> In case anyone has any doubts about portage reliance on the eclasses,
> let me quote Zac:
> 
> #gentoo-dev 20:19 < <at> zmedico> jmbsvicetto: it's only an issue for people
> upgrading from less than portage-2.1.4, which is pretty rare nowadays
> 
> 
> For the KDE team,
> 

It's an issue for people who have packages in vdb emerged with portage
older than 2.1.4 (if this was the version where the env started being
added to vdb). I have been maintaining the position that nuking eclasses
doesn't really provide enough benefits to bork these installs. I
recommend just making the eclasses unusable for emerging stuff and
keeping uninstalls working.

Regards,
Petteri
(Continue reading)

Permalink | Reply | 5 comments |
headers
Tobias Scherbaum | 1 May 2009 22:11
Picon
Favicon
Gravatar

Re: proposed email - Dropping old kde3 eclasses from the tree

Am Freitag, den 01.05.2009, 22:33 +0300 schrieb Petteri Räty:
> > #gentoo-dev 20:19 < <at> zmedico> jmbsvicetto: it's only an issue for people
> > upgrading from less than portage-2.1.4, which is pretty rare nowadays
> > 
> > 
> > For the KDE team,
> > 
> 
> It's an issue for people who have packages in vdb emerged with portage
> older than 2.1.4 (if this was the version where the env started being
> added to vdb). I have been maintaining the position that nuking eclasses
> doesn't really provide enough benefits to bork these installs. I
> recommend just making the eclasses unusable for emerging stuff and
> keeping uninstalls working.

Agreed on that, plus we don't have any *real* numbers on how rare
anything less than 2.1.4 *really* is these days.

  Tobias
Permalink | Reply | 0 comments |
headers
Jorge Manuel B. S. Vicetto | 1 May 2009 22:13
Picon
Favicon
Gravatar

Re: proposed email - Dropping old kde3 eclasses from the tree


Petteri Räty wrote:
> Jorge Manuel B. S. Vicetto wrote:
>> Hi.
>>
>> As the KDE team prepares to add revised eclasses for the KDE3 ebuilds so
>> we can get 3.5.10 marked stable and then finally ask for KDE4
>> stabilization, we'd like to drop some old eclasses from the tree. We
>> plan to drop the kde-base, kde-dist, kde-i18n and kde-source eclasses as
>> they're no longer used.
>> So unless someone has any objections, we'll drop the eclasses from the
>> tree in the next few days.
>>
>> In case anyone has any doubts about portage reliance on the eclasses,
>> let me quote Zac:
>>
>> #gentoo-dev 20:19 < <at> zmedico> jmbsvicetto: it's only an issue for people
>> upgrading from less than portage-2.1.4, which is pretty rare nowadays
>>
>>
>> For the KDE team,
>>
> 
> It's an issue for people who have packages in vdb emerged with portage
> older than 2.1.4 (if this was the version where the env started being
> added to vdb). I have been maintaining the position that nuking eclasses
> doesn't really provide enough benefits to bork these installs. I
> recommend just making the eclasses unusable for emerging stuff and
> keeping uninstalls working.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Zac Medico | 1 May 2009 22:18
Picon
Favicon
Gravatar

Re: proposed email - Dropping old kde3 eclasses from the tree


Petteri Räty wrote:
> It's an issue for people who have packages in vdb emerged with portage
> older than 2.1.4 (if this was the version where the env started being
> added to vdb).

It's not really an issue since older versions of portage still
created /var/db/pkg/*/*/environment.bz2 files which are utilized by
>=portage-2.1.4.
--
Thanks,
Zac
Permalink | Reply | 0 comments |
headers
Jeremy Olexa | 1 May 2009 22:49
Picon
Favicon
Gravatar

Re: RFC: best way to introduce USE=prefix

On Sat, Apr 4, 2009 at 2:47 PM, Fabian Groffen <grobian <at> gentoo.org> wrote:
> On 04-04-2009 20:41:34 +0100, Ciaran McCreesh wrote:
>> The two aren't mutually contradictory. Quite the contrary.
>>
>> For EAPI 3, we're aiming to make it illegal to do anything with a flag
>> unless it's either explicitly listed in IUSE or handled via a number of
>> special magic profile variables, so you'd either have to list it
>> everywhere or use one of the profile variables. Once you do that, how
>> you mask / force it is up to you, unless you need some kind of special
>> package manager handling for that flag.
>
> Sounds to me it would be ok then to add it now in use.mask, and then
> EAPI 3 is done, define it in whatever special variable it needs to be
> added to according to the specs then.  IUSE_IMPLICIT -- assuming it can
> be defined in the profiles -- seems like a good way to prepare for that,
> since it makes explicit it is implicit, IMO.

Alright, I have talked to a few people in IRC. This solution seems to work:

* IUSE_IMPLICIT="prefix" in base/make.defaults (for EAPI-3 and greater)
* prefix in base/use.mask (so no profiles will be able to use it
unless specifically unmasked)
* unmask USE=prefix and force it in prefix profiles - not in gentoo-x86 yet

Patch located here if anyone cares to look:
http://dev.gentoo.org/~darkside/tmp/USE-prefix.patch

This is the combined logic of this thread, anything I overlooked?

Thanks,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Petteri Räty | 1 May 2009 22:59
Picon
Favicon

Re: proposed email - Dropping old kde3 eclasses from the tree

Jorge Manuel B. S. Vicetto wrote:
> Petteri Räty wrote:
>> Jorge Manuel B. S. Vicetto wrote:
>>> Hi.
>>>
>>> As the KDE team prepares to add revised eclasses for the KDE3 ebuilds so
>>> we can get 3.5.10 marked stable and then finally ask for KDE4
>>> stabilization, we'd like to drop some old eclasses from the tree. We
>>> plan to drop the kde-base, kde-dist, kde-i18n and kde-source eclasses as
>>> they're no longer used.
>>> So unless someone has any objections, we'll drop the eclasses from the
>>> tree in the next few days.
>>>
>>> In case anyone has any doubts about portage reliance on the eclasses,
>>> let me quote Zac:
>>>
>>> #gentoo-dev 20:19 < <at> zmedico> jmbsvicetto: it's only an issue for people
>>> upgrading from less than portage-2.1.4, which is pretty rare nowadays
>>>
>>>
>>> For the KDE team,
>>>
>> It's an issue for people who have packages in vdb emerged with portage
>> older than 2.1.4 (if this was the version where the env started being
>> added to vdb). I have been maintaining the position that nuking eclasses
>> doesn't really provide enough benefits to bork these installs. I
>> recommend just making the eclasses unusable for emerging stuff and
>> keeping uninstalls working.
> 
>> Regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mounir Lamouri | 2 May 2009 18:17
Picon
Favicon
Gravatar

license issue with fretsonfire

Hi,

I was going to put frets on fire into the tree when I realized the
license of this game [1] is not very easy to get. The source code is
GPL-2 (with this note "some source files derived from other sources might
have differing licenses."), 3 fonts files have specific licenses and the
songs follow this rule "Distribution, modification or commercial usage
of the songs is not allowed.".

I think the code can be considered GPL-2 (i will check if there is no
header specifying something else) and for the fonts, I will have to add
2 licenses not in the tree at the moment.
But what to do with the songs ? I suppose it's not the first GPL game
having "non very clear" license about data. How games team is managing
that ?

[1] http://dev.gentoo.org/~volkmar/fretsonfire_copying.txt

Thanks,
Mounir
Permalink | Reply | 4 comments |
headers
Zac Medico | 2 May 2009 23:02
Picon
Favicon
Gravatar

Re: proposed email - Dropping old kde3 eclasses from the tree


Jorge Manuel B. S. Vicetto wrote:
> Even though this could affect packages merged before portage-2.1.4, the
> only packages that would be affected are packages that haven't had any
> updates since then and that means the eclasses they may use are still
> required and can not be dropped.

As said in my reply to Petteri, even packages merged by earlier
versions of portage are typically fine since older versions of
portage created /var/db/pkg/*/*/environment.bz2 files which can be
utilized by >=portage-2.1.4.
--
Thanks,
Zac
Permalink | Reply | 0 comments |

Gmane