-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 betelge...@gentoo.org wrote:
On 03/02/2010 08:27 PM, Arfrever Frehtes Taifersar Arahesis wrote:
Members of Gentoo Python Project have agreed to deprecate
# Samuli Suominen ssuomi...@gentoo.org (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 scarab...@gentoo.org:
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
# Samuli Suominen ssuomi...@gentoo.org (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 scarab...@gentoo.org:
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
# Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010)
# Masked for QA, security
#
# Internal copies of vuln. libpng, zlib
#
# Masked for removal in 60 days
net-nntp/bnr2
# Samuli Suominen ssuomi...@gentoo.org (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 ssuomi...@gentoo.org wrote:
# Samuli Suominen ssuomi...@gentoo.org (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
# Samuli Suominen ssuomi...@gentoo.org (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 ssuomi...@gentoo.org (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
-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 ssuomi...@gentoo.org wrote:
# Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010)
# Masked for QA, security
#
# Internal copies of vuln. zlib,
On Wed, 03 Mar 2010 13:09:49 +0200
Petteri Räty betelge...@gentoo.org wrote:
On 3.3.2010 11.23, Nirbheek Chauhan wrote:
2010/3/3 Tomáš Chvátal scarab...@gentoo.org:
Removing eclass functions like this is not allowed by current policy. If
you want to do it, you should discuss about changing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 03 Mar 2010 09:47:37 +0100
Tomáš Chvátal scarab...@gentoo.org 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.
Dne 3.3.2010 12:32, Joshua Saddler napsal(a):
On Wed, 03 Mar 2010 13:35:10 +0200
Samuli Suominen ssuomi...@gentoo.org wrote:
# Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010)
# Masked for QA, security
#
# Internal copies of vuln. zlib, jpeg, speex and likely
# others
#
#
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 ssuomi...@gentoo.org wrote:
# Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010)
# Masked for QA, security
#
# Internal copies of vuln. zlib, jpeg,
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()
-
# Samuli Suominen ssuomi...@gentoo.org (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 scarab...@gentoo.org 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 you
On 03/03/2010 02:40 PM, Ryan Hill wrote:
On Wed, 03 Mar 2010 13:09:49 +0200
Petteri Räty betelge...@gentoo.org wrote:
On 3.3.2010 11.23, Nirbheek Chauhan wrote:
2010/3/3 Tomáš Chvátal scarab...@gentoo.org:
Removing eclass functions like this is not allowed by current policy. If
you want to
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 ssuomi...@gentoo.org 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
Michael Sterrett mr_bon...@gentoo.org 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
On Wednesday 03 March 2010 18:29:13 Mark Loeser wrote:
Michael Sterrett mr_bon...@gentoo.org 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
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 - cups
On Thu, Mar 4, 2010 at 12:15 AM, Mart Raudsepp l...@gentoo.org 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
On Wed, Mar 3, 2010 at 8:59 AM, Markos Chandras hwoar...@gentoo.org wrote:
On Wednesday 03 March 2010 18:29:13 Mark Loeser wrote:
Michael Sterrett mr_bon...@gentoo.org said:
I've remove the mask for games-fps/openarena.
The mask was done without consulting the games team.
This is no
On Wed, 03 Mar 2010 17:55:41 +0200
Petteri Räty betelge...@gentoo.org 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
On 3 March 2010 19:45, Mart Raudsepp l...@gentoo.org 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
On 3 March 2010 19:54, Nirbheek Chauhan nirbh...@gentoo.org 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
On 03/03/10 15:51, Ben de Groot wrote:
On 3 March 2010 19:45, Mart Raudsepp l...@gentoo.org 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 Raudseppl...@gentoo.org wrote:
I don't believe we should selectively cripple one GUI toolkit with not
having proper printing support out of the box on a
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 enable that
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
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
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
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 l...@gentoo.org 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
On 3 March 2010 19:45, Mart Raudsepp l...@gentoo.org 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
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 developer,
On Wed, Mar 03, 2010 at 11:08:07PM -0800, Joshua Saddler wrote:
On 3 March 2010 19:45, Mart Raudsepp l...@gentoo.org 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
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
Eclasses
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 of functions
41 matches
Mail list logo
