Hello
Please see attached news item for reviewing as part of the fix for
http://bugs.gentoo.org/show_bug.cgi?id=346491
Thanks
Title: Change on CAMERAS handling in libgphoto2-2.4.10
Author: Pacho Ramos
Content-Type: text/plain
Posted: 2011-02-13
Revision: 1
News-Item-Format: 1.0
Display-If-Insta
On Sun, 13 Feb 2011 18:03:41 +0100
Pacho Ramos wrote:
> Please see attached news item for reviewing as part of the fix for
> http://bugs.gentoo.org/show_bug.cgi?id=346491
CAMERAS=* shouldn't be legal. Since the strict IUSE stuff was dropped
from EAPI 4, and since IUSE isn't complete in any EAPI,
El dom, 13-02-2011 a las 17:09 +, Ciaran McCreesh escribió:
> On Sun, 13 Feb 2011 18:03:41 +0100
> Pacho Ramos wrote:
> > Please see attached news item for reviewing as part of the fix for
> > http://bugs.gentoo.org/show_bug.cgi?id=346491
>
> CAMERAS=* shouldn't be legal. Since the strict IUS
On Saturday, February 12, 2011 21:37:29 Diego Elio Pettenò wrote:
> Il giorno sab, 12/02/2011 alle 18.21 -0500, Mike Frysinger ha scritto:
> > patching packages in the tree is a huge hassle,
> > you add hassle to end users who d/l random packages and try to build
> > things
> > themselves, and you
On Sun, 2011-02-13 at 17:09 +, Ciaran McCreesh wrote:
> On Sun, 13 Feb 2011 18:03:41 +0100
> Pacho Ramos wrote:
> > Please see attached news item for reviewing as part of the fix for
> > http://bugs.gentoo.org/show_bug.cgi?id=346491
>
> CAMERAS=* shouldn't be legal. Since the strict IUSE stuf
On Sun, 13 Feb 2011 20:31:23 +0100
Pacho Ramos wrote:
> Wouldn't be any shorter way to build all CAMERAS? We don't want to
> default to enabling all, with the new way of handling this, if CAMERAS
> is not set or is empty, nothing will be built but, if CAMERAS="*"
> shouldn't be used, what should w
On 13-02-2011 16:53:40 +, Arfrever Frehtes Taifersar Arahesis wrote:
> arfrever11/02/13 16:53:40
>
> Modified: make.defaults
> Log:
> Don't include ${USE} in the first assignment to USE in make.defaults files
> to avoid incorrect interactions between enabled and disabled flags in
> dif
On Sun, 2011-02-13 at 19:34 +, Ciaran McCreesh wrote:
> On Sun, 13 Feb 2011 20:31:23 +0100
> Pacho Ramos wrote:
> > Wouldn't be any shorter way to build all CAMERAS? We don't want to
> > default to enabling all, with the new way of handling this, if CAMERAS
> > is not set or is empty, nothing
On Sun, Feb 13, 2011 at 1:34 PM, Ciaran McCreesh
wrote:
> Why not specify all the CAMERAS you know about as being on by default in
> the profile? Users who care enough can override this with an explicit
> subset.
> --
> Ciaran McCreesh
This is how ALSA_CARDS and LCD_DEVICES are handled now. Its l
2011-02-13 20:43:12 Fabian Groffen napisał(a):
> On 13-02-2011 16:53:40 +, Arfrever Frehtes Taifersar Arahesis wrote:
> > arfrever11/02/13 16:53:40
> >
> > Modified: make.defaults
> > Log:
> > Don't include ${USE} in the first assignment to USE in make.defaults
> > files to avoid incorr
On Sun, 2011-02-13 at 14:00 -0600, Matthew Summers wrote:
> On Sun, Feb 13, 2011 at 1:34 PM, Ciaran McCreesh
> wrote:
> > Why not specify all the CAMERAS you know about as being on by default in
> > the profile? Users who care enough can override this with an explicit
> > subset.
> > --
> > Ciaran
Il giorno dom, 13/02/2011 alle 14.22 -0500, Mike Frysinger ha scritto:
>
> thus it's a lot more sane in the long term to assume that packages
> support the
> latest rather than patching everyone (and being forced to carry those
> custom
> patches indefinitely) to set the ceiling at the last "kno
On Sun, 13 Feb 2011 21:00:31 +0100
Pacho Ramos wrote:
> If rest of gnome team agrees, I think we could go with, but I still
> fail to see what is the "technical" problem on allowing CAMERAS="*"
> to be used :-|
'cameras_*' isn't a valid use flag name, so the package mangler can't
just pass the *
On 13-02-2011 21:10:23 +0100, Arfrever Frehtes Taifersar Arahesis wrote:
> > Is there any resource you can point me to where it explains more
> > carefully why and when this has changed?
>
> PMS
> 5.2.4 make.defaults
> 5.3.1 Incremental Variables
Ok, I clearly had missed that. A long time ago I
Il giorno dom, 13/02/2011 alle 22.05 +0100, Arfrever Frehtes Taifersar
Arahesis ha scritto:
> Stabilization of Python 2.7.* will begin on 2011-03-13.
Are you expecting all the testsuites currently failing with 2.7 to be
fixed by that date? I'm pretty sure there are still a few around for
which th
On Sunday, February 13, 2011 15:16:58 Diego Elio Pettenò wrote:
> Il giorno dom, 13/02/2011 alle 14.22 -0500, Mike Frysinger ha scritto:
> > thus it's a lot more sane in the long term to assume that packages
> > support the latest rather than patching everyone (and being forced to
> > carry those c
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2011-02-13 23h59 UTC.
Removals:
net-misc/asterisk-app_nv_faxdetect 2011-02-10 11:21:15 scarabeus
app-misc/mved 2011-02-10 11:24:42 scarabeus
x11-misc/tra
On Thu, Feb 10, 2011 at 14:36, Diego Elio Pettenò wrote:
> Remember that for *all* QA masking, the rule is simple
Could you point me to the Q/A policies and rules? I'm curious now,
seeing this intense discussion about what's right for Q/A, what the
official Q/A docs say.
--
Jacob
"For
18 matches
Mail list logo
