-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dne 3.3.2010 08:52, Ryan Hill napsal(a):
> On Wed, 03 Mar 2010 08:52:55 +0200
> Petteri Räty wrote:
>
>> On 03/02/2010 08:27 PM, Arfrever Frehtes Taifersar Arahesis wrote:
>>> Members of Gentoo Python Project have agreed to deprecate the following
>
# Samuli Suominen (03 Mar 2010)
# Masked for QA, security
#
# Internal copies of vuln. libraries
# GLSA 200606-11, GLSA 200807-03 and likely more
#
# http://bugs.gentoo.org/show_bug.cgi?id=247363
#
# Removed in 60 days
dev-lang/squeak
2010/3/3 Tomáš Chvátal :
>>> Removing eclass functions like this is not allowed by current policy. If
>>> you want to do it, you should discuss about changing policy.
>>
>> ?!
>>
>> since when?
>>
> Since ever.
> If you change eclass abi you need to rename it.
>
I think you can *add* functions and
# Samuli Suominen (03 Mar 2010)
# Masked for QA, security
#
# Internal copy of vuln. libltdl, CVE-2009-3736
#
# Bugs 252402, 296953, 296954, 215252, 297649
#
# Masked for removal in 60 days
net-libs/libnetdude
net-analyzer/netdude
net-im/naim
On 3.3.2010 11.23, Nirbheek Chauhan wrote:
> 2010/3/3 Tomáš Chvátal :
Removing eclass functions like this is not allowed by current policy. If
you want to do it, you should discuss about changing policy.
>>>
>>> ?!
>>>
>>> since when?
>>>
>> Since ever.
>> If you change eclass abi you nee
# Samuli Suominen (03 Mar 2010)
# Masked for QA, security
#
# Internal copies of vuln. libpng, zlib
#
# Masked for removal in 60 days
net-nntp/bnr2
# Samuli Suominen (03 Mar 2010)
# Masked for QA, security
#
# Internal copies of vuln. zlib, jpeg, speex and likely
# others
#
# http://bugs.gentoo.org/show_bug.cgi?id=255453
#
# Masked for removal in 60 days.
games-fps/openarena
On Wed, 03 Mar 2010 13:35:10 +0200
Samuli Suominen wrote:
> # Samuli Suominen (03 Mar 2010)
> # Masked for QA, security
> #
> # Internal copies of vuln. zlib, jpeg, speex and likely
> # others
> #
> # http://bugs.gentoo.org/show_bug.cgi?id=255453
> #
> # Masked for removal in 60 days.
> games-fp
# Samuli Suominen (03 Mar 2010)
# Masked for QA, security
#
# After over an year of no word from maintainers
#
# Internal copy of vuln. libltdl, CVE-2009-3736
#
# Masked for removal in 60 days
app-shells/pdsh
# Samuli Suominen (03 Mar 2010)
# Masked for QA, security
#
# After more than a year of no word from maintainers
#
# Internal copy of vulnerable libpcre, bug 258330
# Remote command execution, CVE-2009-4016, bug 303735
# Build issues, bug 212255
#
# Masked for removal in 60 days.
net-irc/ircd-hybr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dne 3.3.2010 12:32, Joshua Saddler napsal(a):
> On Wed, 03 Mar 2010 13:35:10 +0200
> Samuli Suominen wrote:
>
>> # Samuli Suominen (03 Mar 2010)
>> # Masked for QA, security
>> #
>> # Internal copies of vuln. zlib, jpeg, speex and likely
>> # others
On Wed, 03 Mar 2010 13:09:49 +0200
Petteri Räty wrote:
> On 3.3.2010 11.23, Nirbheek Chauhan wrote:
> > 2010/3/3 Tomáš Chvátal :
> Removing eclass functions like this is not allowed by current policy. If
> you want to do it, you should discuss about changing policy.
> >>>
> >>> ?!
> >>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 03 Mar 2010 09:47:37 +0100
Tomáš Chvátal wrote:
> >> Removing eclass functions like this is not allowed by current
> >> policy. If you want to do it, you should discuss about changing
> >> policy.
> >
> > since when?
> >
> Since ever.
> If y
> Dne 3.3.2010 12:32, Joshua Saddler napsal(a):
> > On Wed, 03 Mar 2010 13:35:10 +0200
> > Samuli Suominen wrote:
> >
> >> # Samuli Suominen (03 Mar 2010)
> >> # Masked for QA, security
> >> #
> >> # Internal copies of vuln. zlib, jpeg, speex and likely
> >> # others
> >> #
> >> # http://bugs.ge
On 03/03/2010 02:58 PM, Ryan Hill wrote:
>> Dne 3.3.2010 12:32, Joshua Saddler napsal(a):
>>> On Wed, 03 Mar 2010 13:35:10 +0200
>>> Samuli Suominen wrote:
>>>
# Samuli Suominen (03 Mar 2010)
# Masked for QA, security
#
# Internal copies of vuln. zlib, jpeg, speex and likely
>
Petteri Räty wrote:
On 03/02/2010 08:27 PM, Arfrever Frehtes Taifersar Arahesis wrote:
Members of Gentoo Python Project have agreed to deprecate the following
functions
in EAPI <=2:
- python_version()
- python_mod_exists()
- python_tkinter_exists()
- distutils_python_version()
- distu
Ciaran McCreesh posted on Wed, 03 Mar 2010 12:47:41 + as excerpted:
> On Wed, 03 Mar 2010 09:47:37 +0100
> Tomáš Chvátal wrote:
>> >> Removing eclass functions like this is not allowed by current
>> >> policy. If you want to do it, you should discuss about changing
>> >> policy.
>> >
>> > si
# Samuli Suominen (03 Mar 2010)
# Masked for QA, security
#
# Internal copy of vuln. libltdl, CVE-2009-3736
#
# http://bugs.gentoo.org/show_bug.cgi?id=277089
#
# Masked for removal in 60 days
dev-lang/gnu-smalltalk
On 03/03/2010 02:47 PM, Ciaran McCreesh wrote:
> On Wed, 03 Mar 2010 09:47:37 +0100
> Tomáa Chvátal wrote:
Removing eclass functions like this is not allowed by current
policy. If you want to do it, you should discuss about changing
policy.
>>>
>>> since when?
>>>
>> Since ever.
>>
On 03/03/2010 02:40 PM, Ryan Hill wrote:
> On Wed, 03 Mar 2010 13:09:49 +0200
> Petteri Räty wrote:
>
>> On 3.3.2010 11.23, Nirbheek Chauhan wrote:
>>> 2010/3/3 Tomáš Chvátal :
>> Removing eclass functions like this is not allowed by current policy. If
>> you want to do it, you should dis
I've remove the mask for games-fps/openarena.
The mask was done without consulting the games team.
On Wed, Mar 3, 2010 at 8:09 AM, Samuli Suominen wrote:
> On 03/03/2010 02:58 PM, Ryan Hill wrote:
>>> Dne 3.3.2010 12:32, Joshua Saddler napsal(a):
On Wed, 03 Mar 2010 13:35:10 +0200
Sam
Michael Sterrett said:
> I've remove the mask for games-fps/openarena.
>
> The mask was done without consulting the games team.
This is no reason to remove the mask. The games team had more than
enough time to fix the package. I'll be adding the mask back as the
package is vulnerable via multi
On Wednesday 03 March 2010 18:29:13 Mark Loeser wrote:
> Michael Sterrett said:
> > I've remove the mask for games-fps/openarena.
> >
> > The mask was done without consulting the games team.
>
> This is no reason to remove the mask. The games team had more than
> enough time to fix the package.
On E, 2010-03-01 at 13:40 -0800, Zac Medico wrote:
> On 03/01/2010 01:24 PM, Ben de Groot wrote:
> > For some reason beyond my understanding, we have the cups useflag
> > enabled by default in profiles. This has started to generate circular
> > dependencies, at least for desktop profile users (gtk
On Thu, Mar 4, 2010 at 12:15 AM, Mart Raudsepp wrote:
> I don't think there was any such problem until poppler maintainers
> decided to unsplit poppler into one big packages with USE flags again
> instead of the nice split poppler, poppler-glib (that should have been
> named poppler-cairo probably
On Wed, Mar 3, 2010 at 8:59 AM, Markos Chandras wrote:
> On Wednesday 03 March 2010 18:29:13 Mark Loeser wrote:
>> Michael Sterrett said:
>> > I've remove the mask for games-fps/openarena.
>> >
>> > The mask was done without consulting the games team.
>>
>> This is no reason to remove the mask.
On Wed, 03 Mar 2010 17:55:41 +0200
Petteri Räty wrote:
> On 03/03/2010 02:40 PM, Ryan Hill wrote:
> > Is this actually documented anywhere? Or is this another of our
> > "this-is-policy-because-everyone-knows-it's-policy" policies? I know there
> > was a technical issue with removing pkg_*_rm
On 3 March 2010 19:45, Mart Raudsepp wrote:
> I don't believe we should selectively cripple one GUI toolkit with not
> having proper printing support out of the box on a desktop profile,
> while others do, just because maintainers are lazy.
I'm not talking about selectively disabling cups. My pro
On 3 March 2010 19:54, Nirbheek Chauhan wrote:
> Also of note is that we've made efforts to split packages to avoid
> circular dependencies[1]. So it's really silly to add circular deps by
> un-splitting packages.
I think it's silly to split packages for no good reason. And doing it to
avoid circ
On 03/03/10 15:51, Ben de Groot wrote:
> On 3 March 2010 19:45, Mart Raudsepp wrote:
>
>> I don't believe we should selectively cripple one GUI toolkit with not
>> having proper printing support out of the box on a desktop profile,
>> while others do, just because maintainers are lazy.
>>
chrome://messenger/locale/messengercompose/composeMsgs.properties:
On 03/03/10 15:51, Ben de Groot wrote:
On 3 March 2010 19:45, Mart Raudsepp wrote:
I don't believe we should selectively cripple one GUI toolkit with not
having proper printing support out of the box on a desktop profile,
w
I'm not talking about selectively disabling cups. My proposal is
>>> to no longer enable the cups useflag in the base profile. I don't
>>> think cups should be part of the base profile, and as a result
>>> cascading to the desktop profile. And a lot of people seem to
>>> agree. Users can always ena
chrome://messenger/locale/messengercompose/composeMsgs.properties:
I'm not talking about selectively disabling cups. My proposal is
to no longer enable the cups useflag in the base profile. I don't
think cups should be part of the base profile, and as a result
cascading to the desktop profil
On 03/03/10 20:17, Dale wrote:
> chrome://messenger/locale/messengercompose/composeMsgs.properties:
>> I'm not talking about selectively disabling cups. My proposal is
>>
> to no longer enable the cups useflag in the base profile. I don't
> think cups should be part of the base profile,
chrome://messenger/locale/messengercompose/composeMsgs.properties:
On 03/03/10 20:17, Dale wrote:
chrome://messenger/locale/messengercompose/composeMsgs.properties:
I'm not talking about selectively disabling cups. My proposal is
to no longer enable the cups useflag in the base profile. I don'
On 03/03/2010 09:41 PM, Dale wrote:
So in the situation above, removing cups doesn't help any? The user
would still have to work around the dependency problem. Is there not a
better way to handle this?
Agreed that there should be better ways of handling things.
However, at the very least if so
chrome://messenger/locale/messengercompose/composeMsgs.properties:
On 03/03/2010 09:41 PM, Dale wrote:
So in the situation above, removing cups doesn't help any? The user
would still have to work around the dependency problem. Is there not a
better way to handle this?
Agreed that there should
On Wednesday 03 March 2010 22:51:10 Ben de Groot wrote:
> On 3 March 2010 19:45, Mart Raudsepp wrote:
> > I don't believe we should selectively cripple one GUI toolkit with not
> > having proper printing support out of the box on a desktop profile,
> > while others do, just because maintainers are
> On 3 March 2010 19:45, Mart Raudsepp wrote:
> > I don't believe we should selectively cripple one GUI toolkit with not
> > having proper printing support out of the box on a desktop profile,
> > while others do, just because maintainers are lazy.
>
> It is not something that is necessary for r
On 03/03/2010 11:39 PM, Ryan Hill wrote:
>>
>> Also policies should be changed when they don't make sense any more as I
>> said in my first response but I am not sure if that's the case here.
>
> The problem is I don't think this is actually a policy. One of the first
> projects I did as a develo
On Wed, Mar 03, 2010 at 11:08:07PM -0800, Joshua Saddler wrote:
>
> > On 3 March 2010 19:45, Mart Raudsepp wrote:
> > > I don't believe we should selectively cripple one GUI toolkit with not
> > > having proper printing support out of the box on a desktop profile,
> > > while others do, just beca
> On Thu, 04 Mar 2010, Petteri Räty wrote:
> If we decide allowing removal of functions, we should come up with a
> common procedure like the eclass removal policy:
> http://devmanual.gentoo.org/eclass-writing/index.html
I think removal of functions is a special case of "Adding and Updating
E
On 03/04/2010 09:39 AM, Ulrich Mueller wrote:
>> On Thu, 04 Mar 2010, Petteri Räty wrote:
>
>> If we decide allowing removal of functions, we should come up with a
>> common procedure like the eclass removal policy:
>> http://devmanual.gentoo.org/eclass-writing/index.html
>
> I think removal
43 matches
Mail list logo
