Hi,
Petteri Räty :
> If relevant people already know the policy and act accordingly then
> why do we have this thread in the first place?
Security is (as all the teams), badly understaffed, so sometimes
something like this slips. It was a friendly reminder as it happens
from time to time and sl
On Sun, Jul 18, 2010 at 06:21:03AM +0300, Theo Chatzimichos wrote:
> On Sun, Jul 18, 2010 at 6:13 AM, Jorge Manuel B. S. Vicetto
> wrote:
> > I cross-posted this email to both gentoo-dev and gentoo-council mls as
> > Brian used the former and Alex started this thread in the latter. Which
> > ML do
On Sun, Jul 18, 2010 at 6:13 AM, Jorge Manuel B. S. Vicetto
wrote:
> I cross-posted this email to both gentoo-dev and gentoo-council mls as
> Brian used the former and Alex started this thread in the latter. Which
> ML do we want to use?
I guess Brian posted on gentoo-dev as this usually happens
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17-07-2010 23:33, Brian Harring wrote:
> On Sun, Jul 18, 2010 at 01:05:02AM +0300, Alex Alexander wrote:
>> The Council will have its next meeting on the 26th of July, 2010.
>>
>> The meeting will begin at 1900 UTC.
>>
>> You may use [0] to find out
On Sun, Jul 18, 2010 at 01:54:43AM +, Jorge Manuel B. S. Vicetto wrote:
> this is being used in the tree already.
Doesn't make it right ;)
> IIRC, since the introduction of EAPI-2 in the tree, there were a few
> solutions present to the dev ml and the one agreed by people was the
> abuse of d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 18-07-2010 00:58, Brian Harring wrote:
> On Sun, Jul 18, 2010 at 02:56:05AM +0300, Alexis Ballier wrote:
>> case ${EAPI:-0} in
>> 2|3|4) ;;
>> *) DEPEND="EAPI-TOO-OLD" ;;
>> esac
>>
>> why not:
>>
>> case ${EAPI:-0} in
>> 0|1) DEPEND=
On Sun, Jul 18, 2010 at 02:56:05AM +0300, Alexis Ballier wrote:
> case ${EAPI:-0} in
> 2|3|4) ;;
> *) DEPEND="EAPI-TOO-OLD" ;;
> esac
>
> why not:
>
> case ${EAPI:-0} in
> 0|1) DEPEND="EAPI-TOO-OLD" ;;
> esac
Do not go adding invalid DEPEND like that. Make the eclass die
inst
case ${EAPI:-0} in
2|3|4) ;;
*) DEPEND="EAPI-TOO-OLD" ;;
esac
why not:
case ${EAPI:-0} in
0|1) DEPEND="EAPI-TOO-OLD" ;;
esac
?
Alexis.
signature.asc
Description: This is a digitally signed message part.
On Sun, Jul 18, 2010 at 01:05:02AM +0300, Alex Alexander wrote:
> The Council will have its next meeting on the 26th of July, 2010.
>
> The meeting will begin at 1900 UTC.
>
> You may use [0] to find out the correct time in your timezone.
>
> Here's a draft list of the meeting topics so far:
> *
On Sat, 17 Jul 2010 22:23:03 +0200
Matti Bickel wrote:
> On 07/17/2010 09:58 PM, Matti Bickel wrote:
> > since there's no dev-lang/php-5.1* version in the tree anymore, this
> > eclass is useless. It will be removed on 17th August 2010.
>
> I've just been told by scarabeus that eclass removal is
On 07/17/2010 09:58 PM, Matti Bickel wrote:
> since there's no dev-lang/php-5.1* version in the tree anymore, this
> eclass is useless. It will be removed on 17th August 2010.
I've just been told by scarabeus that eclass removal is a two years
minimum process. So it'll be removed 17th August 2012
Hi,
since there's no dev-lang/php-5.1* version in the tree anymore, this
eclass is useless. It will be removed on 17th August 2010.
signature.asc
Description: OpenPGP digital signature
On 07/17/2010 07:58 PM, Petteri Räty wrote:
>> As the CC'ing should be done by the security folks/the maintainer when a
>> new ebuild is ready, I don't think it needs to be in devmanual. The
>> relevant people should be aware of the process.
>>
> If relevant people already know the policy and act a
On 07/17/2010 08:50 PM, Matti Bickel wrote:
> On 07/17/2010 07:02 PM, Petteri Räty wrote:
>>> Do stabilisations on the security bug so arch team members can skim
>>> through their stabilisation list by just looking for secur...@g.o to
>>> find the vulnerable packages.
>>>
>>> V-Li
>>>
>>
>> If you
On 07/17/2010 07:02 PM, Petteri Räty wrote:
>> Do stabilisations on the security bug so arch team members can skim
>> through their stabilisation list by just looking for secur...@g.o to
>> find the vulnerable packages.
>>
>> V-Li
>>
>
> If you want things to happen this way then it should be at
On 07/17/2010 05:51 PM, Christian Faulhammer wrote:
> Hi,
>
> Thilo Bangert :
>>> please avoid having stabilisation requests
>>> like http://bugs.gentoo.org/show_bug.cgi?id=327877, blocking a
>>> security bug. That way, architecture teams may not see the severity
>>> directly and it slips, leavin
Hi,
Thilo Bangert :
> > please avoid having stabilisation requests
> > like http://bugs.gentoo.org/show_bug.cgi?id=327877, blocking a
> > security bug. That way, architecture teams may not see the severity
> > directly and it slips, leaving users with vulnerable versions longer
> > than needed.
Christian Faulhammer said:
> Hi,
>
> please avoid having stabilisation requests
> like http://bugs.gentoo.org/show_bug.cgi?id=327877, blocking a
> security bug. That way, architecture teams may not see the severity
> directly and it slips, leaving users with vulnerable versions longer
> than nee
On Saturday 17 of July 2010 13:03:33 Petteri Räty wrote:
> On 07/17/2010 01:53 PM, Maciej Mrozowski wrote:
> > After gathering some feedback, after addressing reported issues, now I
> > feel it's ready for public consumption. especially when static-libs is
> > being used more and more often. It's p
On 07/17/2010 01:53 PM, Maciej Mrozowski wrote:
> After gathering some feedback, after addressing reported issues, now I feel
> it's ready for public consumption. especially when static-libs is being used
> more and more often. It's purpose is to become standard eclass for autotools
> build syst
After gathering some feedback, after addressing reported issues, now I feel
it's ready for public consumption. especially when static-libs is being used
more and more often. It's purpose is to become standard eclass for autotools
build systems.
Brief description:
autotools-utils.eclass is autot
21 matches
Mail list logo
