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
> 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 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 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 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 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
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 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/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/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:
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
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:
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
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.
>>
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 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 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 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 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 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 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.
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
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
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
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.
>>
# 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
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
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
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
>
> 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
-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
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
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
# 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
# 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
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
#
# 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
# Samuli Suominen (03 Mar 2010)
# Masked for QA, security
#
# Internal copies of vuln. libpng, zlib
#
# Masked for removal in 60 days
net-nntp/bnr2
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 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
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 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
-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
>
43 matches
Mail list logo