Ryan Hill | 1 Oct 06:35 2008
Picon

Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets

On Mon, 29 Sep 2008 22:31:46 -0700
Zac Medico <zmedico <at> gentoo.org> wrote:

> > Can package.use syntax be extended to allow set entries?
> >  <at> compiz-fusion -gnome kde kde4
> 
> Perhaps, but we need to clarify how that sort of setting will affect
> nested sets. For example, if  <at> compiz-fusion contains nested sets,
> would those USE settings apply to the nested sets as well? Will
> nested sets be allowed to have independent USE settings from the
> sets that nest them?

Maybe a nested set could inherit the USE flag settings of its parent set
unless it has its own entry in package.use.

Though what happens if a package is in both sets which have
conflicting flags in package.use?  I would say that the nested set has
to have priority.  If not, I can easily imagine people getting confused
when their USE settings for a set are being applied to all but
one or two packages.

--

-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets  <at>  gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
Mike Frysinger | 1 Oct 07:30 2008
Picon

Monthly Gentoo Council Reminder for October

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/

Petteri Räty | 1 Oct 15:48 2008
Picon

Migrating to EAPI 2 and econf

Just a reminder to everyone that when you migrate to EAPI 2 in order to 
use use dependencies remember to migrate your src_compile function too 
or you will be running econf twice if you have a custom src_compile 
function. econf will first be run by the default src_configure function 
and then by your custom src_compile function. Hopefully we will get a QA 
check for this in the near future.

Thilo Bangert | 1 Oct 17:31 2008
Picon

Re: Usages of CVS $Header$ keyword in ebuilds - use cases wanted

"Robin H. Johnson" <robbat2 <at> gentoo.org> said:
> Hi folks,
>
> I'm doing some research on our usages of the $Header$ keyword in our
> main CVS repo.
>
> The primary use-case that has been publicly stated before was for users
> to be able to identify to developers what version of a given ebuild
> they were using.
>
> Q: How much have you utilized the primary use case?
>
> Q: Are there any other use-cases you have and actively use?
>
> For evaluating existing uses of the primary case, I took a glance at
> Bugzilla. There are 624 bugs total that contain a $Header$ with an
> existing Gentoo path. At least 143 of those are for new packages or
> version bumps (they copied existing ebuilds).

it appears we have decided to keep the $Header$ keyword in ebuilds for 
now. however, what about removing it from the ChangeLog?

kind regards
Thilo
Zac Medico | 1 Oct 18:37 2008
Picon

Re: Re: [RFC] PROPERTIES=set for meta-packages that should behave like package sets


Ryan Hill wrote:
> On Mon, 29 Sep 2008 22:31:46 -0700
> Zac Medico <zmedico <at> gentoo.org> wrote:
> 
>>> Can package.use syntax be extended to allow set entries?
>>>  <at> compiz-fusion -gnome kde kde4
>> Perhaps, but we need to clarify how that sort of setting will affect
>> nested sets. For example, if  <at> compiz-fusion contains nested sets,
>> would those USE settings apply to the nested sets as well? Will
>> nested sets be allowed to have independent USE settings from the
>> sets that nest them?
> 
> Maybe a nested set could inherit the USE flag settings of its parent set
> unless it has its own entry in package.use.
> 
> Though what happens if a package is in both sets which have
> conflicting flags in package.use?  I would say that the nested set has
> to have priority.  If not, I can easily imagine people getting confused
> when their USE settings for a set are being applied to all but
> one or two packages.

It seems to me that the most logical approach would be to do some
sort of "incremental" stacking, similar to the way that USE flags
stack in the profiles. Suppose that we have the following settings
in package.use:

  <at> kde-meta    foo bar
  <at> kdeedu-meta -foo

(Continue reading)

Robin H. Johnson | 1 Oct 23:39 2008
Picon

UTF-8 in GLEP56 use flags? WAS: Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt-assistant: ChangeLog qt-assistant-4.4.1.ebuild qt-assistant-4.4.2.ebuild metadata.xml

On Wed, Oct 01, 2008 at 08:13:14PM +0000, Ben de Groot (yngwin) wrote:
> Index: metadata.xml
> ===================================================================
...
> +    <flag name='webkit'>
> +      Enable <pkg>x11-libs/qt-webkit</pkg> support, for more
> +      sophisticated online help display using webkit???s HTML renderer.
> +    </flag>
> +  </use>
>  </pkgmetadata>

I don't think there is any precedence here, but Unicode should not turn
up in the English useflag descriptions, at least not while we are still
generating use.local.desc for users.

This one was really annoying, U+2019 "Right single quotation mark",
which renders identically to an apostrophe, at least on my fonts.

It briefly broke the use.local.desc generation, because that had been
set for ASCII.

Should we allow UTF-8 in the English variant? Are all the programs that
still read use.local.desc UTF-8 safe? Do we have a deprecation schedule
for use.local.desc being removed totally?

--

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2 <at> gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
(Continue reading)

Alexis Ballier | 2 Oct 01:04 2008
Picon

Re: Migrating to EAPI 2 and econf

On Wed, 01 Oct 2008 16:48:05 +0300
Petteri Räty <betelgeuse <at> gentoo.org> wrote:

> Just a reminder to everyone that when you migrate to EAPI 2 in order
> to use use dependencies remember to migrate your src_compile function
> too or you will be running econf twice if you have a custom
> src_compile function. econf will first be run by the default
> src_configure function and then by your custom src_compile function.

Also don't forget about eclasses that export src_compile; and that's
where it becomes more tricky :(

Alexis.
Ben de Groot | 2 Oct 01:30 2008
Picon

Re: UTF-8 in GLEP56 use flags?

Robin H. Johnson wrote:
> On Wed, Oct 01, 2008 at 08:13:14PM +0000, Ben de Groot (yngwin) wrote:
>> Index: metadata.xml
>> ===================================================================
> ...
>> +    <flag name='webkit'>
>> +      Enable <pkg>x11-libs/qt-webkit</pkg> support, for more
>> +      sophisticated online help display using webkit???s HTML renderer.
>> +    </flag>
>> +  </use>
>>  </pkgmetadata>
> 
> I don't think there is any precedence here, but Unicode should not turn
> up in the English useflag descriptions, at least not while we are still
> generating use.local.desc for users.
> 
> This one was really annoying, U+2019 "Right single quotation mark",
> which renders identically to an apostrophe, at least on my fonts.
> 
> It briefly broke the use.local.desc generation, because that had been
> set for ASCII.
> 
> Should we allow UTF-8 in the English variant? Are all the programs that
> still read use.local.desc UTF-8 safe? Do we have a deprecation schedule
> for use.local.desc being removed totally?
> 
The xml header in each metadata.xml states that the content is UTF-8
encoded, and any XML parser has to be able to handle this. Also, when
used literally in xml, the 5 special characters & ' " < >  cause a
well-formedness error, as far as I know. U+2019 is the recommended form
(Continue reading)

Robin H. Johnson | 2 Oct 01:21 2008
Picon

Re: Usages of CVS $Header$ keyword in ebuilds - use cases wanted

On Wed, Oct 01, 2008 at 05:31:21PM +0200, Thilo Bangert wrote:
> > For evaluating existing uses of the primary case, I took a glance at
> > Bugzilla. There are 624 bugs total that contain a $Header$ with an
> > existing Gentoo path. At least 143 of those are for new packages or
> > version bumps (they copied existing ebuilds).
> it appears we have decided to keep the $Header$ keyword in ebuilds for 
> now. however, what about removing it from the ChangeLog?
The Debian pkg generation was the only use-case that didn't have an
immediate other solution. The Prefix guys need it while we are still on
CVS, but said it could vanish on the other side of the Git migration.

So probably just keep it everywhere until we switch VCS.

Random plug: Interested in VCS migration? Subscribe to the gentoo-scm
list.

--

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2 <at> gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Robin H. Johnson | 2 Oct 01:37 2008
Picon

Re: UTF-8 in GLEP56 use flags?

On Thu, Oct 02, 2008 at 01:30:34AM +0200, Ben de Groot wrote:
> The xml header in each metadata.xml states that the content is UTF-8
> encoded, and any XML parser has to be able to handle this. Also, when
> used literally in xml, the 5 special characters & ' " < >  cause a
> well-formedness error, as far as I know. U+2019 is the recommended form
> of using the apostrophe. So in my opinion, if we want to use xml, we
> should use unicode properly.
"xmllint --valid" is my check for well-formedness, and it says the
single quotes are fine.

According to http://www.w3.org/TR/xml11/#dt-chardata the chars "&" and
"<", ">" have "MUST" as their requirements for being escaped. Double and
single quotes "MAY" be escaped.

--

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2 <at> gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Gmane