[gentoo-dev] New global use flag: vpx or vp8

2010-07-31 Thread Hanno Böck
vpx for supporting googles vp8 codec used in webm.

At the moment this is only mplayer and ffmpeg, but it's pretty obvious that 
apps supporting vp8 will start popping up everywhere (currently working on 
arista ebuild which will support it).

Though we might discuss if vpx is really a good name or it shouldn't be vp8.

-- 
Hanno Böck  Blog:   http://www.hboeck.de/
GPG: 3DBD3B20   Jabber/Mail:ha...@hboeck.de


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Locale check in python_pkg_setup()

2010-07-31 Thread Arfrever Frehtes Taifersar Arahesis
2010-07-30 04:36:22 Brian Harring napisał(a):
 On Fri, Jul 30, 2010 at 01:16:42AM +0200, Arfrever Frehtes Taifersar Arahesis 
 wrote:
  --- python.eclass
  +++ python.eclass
  @@ -355,6 +355,8 @@
  # Check if phase is pkg_setup().
  [[ ${EBUILD_PHASE} != setup ]]  die ${FUNCNAME}() can be used 
  only in pkg_setup() phase
   
  +   local locale
  +
  if [[ $# -ne 0 ]]; then
  die ${FUNCNAME}() does not accept arguments
  fi
  @@ -407,6 +409,16 @@
  unset -f python_pkg_setup_check_USE_flags
  fi
   
  +   locale=$(python -c 'import os; print(os.environ.get(LC_ALL, 
  os.environ.get(LC_CTYPE, os.environ.get(LANG, POSIX')
 
 You're using python to get the exported env.  Don't.  Use bash (you're 
 invoking python from freaking bash after all)...

Given variable can be set, but not exported.

 bug 328047 is induced by a patch we add (it's not in upstream python).  

This patch comes from upstream.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] New global use flag: vpx or vp8

2010-07-31 Thread Paweł Hajdan, Jr.
On 7/31/10 4:37 AM, Hanno Böck wrote:
 vpx for supporting googles vp8 codec used in webm.
 
 At the moment this is only mplayer and ffmpeg, but it's pretty obvious that 
 apps supporting vp8 will start popping up everywhere (currently working on 
 arista ebuild which will support it).

Just verifying: does the vpx USE flag in ffmpeg control the support for
encoding vp8, decoding it, or both? How should www-client/chromium
depend on ffmpeg to make sure it will support vp8?

 Though we might discuss if vpx is really a good name or it shouldn't be vp8.

It might also be webm. Not sure what's more intuitive for people. Also,
nteresting question would be whether to enable the flag by default an in
which profiles (desktop?).

Paweł



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] New global use flag: vpx or vp8

2010-07-31 Thread Robert Bridge
On Sat, Jul 31, 2010 at 4:09 PM, Paweł Hajdan, Jr.
phajdan...@gentoo.org wrote:
 On 7/31/10 4:37 AM, Hanno Böck wrote:
 Though we might discuss if vpx is really a good name or it shouldn't be vp8.

 It might also be webm. Not sure what's more intuitive for people. Also,
 nteresting question would be whether to enable the flag by default an in
 which profiles (desktop?).

Speaking as a user, I would ask what the standard file ending is? Most
users won't know what the codec is, they will just know is foo.webm or
foo.vpx/8.

Just a thought if debating the name.

RobbieAB.



Re: [gentoo-dev] New global use flag: vpx or vp8

2010-07-31 Thread Mike Frysinger
On Saturday, July 31, 2010 14:27:14 Jacob Godserv wrote:
 Honestly not sure what convention is for naming, but I found this
 recently, and thought I might throw it out there:
 
  ~ $ euse -i lame
 
 [+ C  ] lame - Prefer using LAME libraries for MP3 encoding support
 
 
 While, as a user, I prefer this to be mp3, I also understand there may
 be more than one library for such-and-so, so I'm willing to read up on
 USE flags to find out which is the best to use. Overall, I would prefer
 naming according to the names of the libraries they'll enable.

that example isnt relevant.  notice how the description includes the word 
prefer and isnt just enable mp3 support.

USE=mp3 is how you get mp3 support.  if there are multiple options (like 
ffmpeg or lame or mpg123 or something else), then USE=lame shows up to select 
one particular implementation over another.  but it would still be:
USE=mp3 lame
-mike


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Locale check in python_pkg_setup()

2010-07-31 Thread Alec Warner
On Sat, Jul 31, 2010 at 7:44 AM, Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org wrote:
 2010-07-30 04:36:22 Brian Harring napisał(a):
 On Fri, Jul 30, 2010 at 01:16:42AM +0200, Arfrever Frehtes Taifersar 
 Arahesis wrote:
  --- python.eclass
  +++ python.eclass
  @@ -355,6 +355,8 @@
      # Check if phase is pkg_setup().
      [[ ${EBUILD_PHASE} != setup ]]  die ${FUNCNAME}() can be used 
  only in pkg_setup() phase
 
  +   local locale
  +
      if [[ $# -ne 0 ]]; then
              die ${FUNCNAME}() does not accept arguments
      fi
  @@ -407,6 +409,16 @@
              unset -f python_pkg_setup_check_USE_flags
      fi
 
  +   locale=$(python -c 'import os; print(os.environ.get(LC_ALL, 
  os.environ.get(LC_CTYPE, os.environ.get(LANG, POSIX')

 You're using python to get the exported env.  Don't.  Use bash (you're
 invoking python from freaking bash after all)...

 Given variable can be set, but not exported.

If the variable is set but not exported then it is local to the shell
env.  When bash goes to exec() python the local shell variables are
not in the env; so os.environ() will not contain them.

anta...@kyoto ~ $ foo=BAR
anta...@kyoto ~ $ echo $foo
BAR
anta...@kyoto ~ $ python -c 'import os; print os.environ.get(foo)'
None
anta...@kyoto ~ $ export foo
anta...@kyoto ~ $ python -c 'import os; print os.environ.get(foo)'
BAR

so how is this any different than:

[[ -n $LC_TYPE ]]  locale=$LC_TYPE
[[ -n $LC_ALL ]]  locale=$LC_ALL
locale=${locale:-POSIX}

if you want to keep it short; or the longer version with more ifs and
less shell magic.  Normally I'm not a big performance man myself; but
this is in an eclass used by lots of packages; not just one ebuild.


 bug 328047 is induced by a patch we add (it's not in upstream python).

 This patch comes from upstream.

 --
 Arfrever Frehtes Taifersar Arahesis




Re: [gentoo-dev] New global use flag: vpx or vp8

2010-07-31 Thread Steve Dibb

On 07/31/2010 12:51 PM, Mike Frysinger wrote:

On Saturday, July 31, 2010 14:27:14 Jacob Godserv wrote:

Honestly not sure what convention is for naming, but I found this
recently, and thought I might throw it out there:

  ~ $ euse -i lame

[+ C  ] lame - Prefer using LAME libraries for MP3 encoding support


While, as a user, I prefer this to be mp3, I also understand there may
be more than one library for such-and-so, so I'm willing to read up on
USE flags to find out which is the best to use. Overall, I would prefer
naming according to the names of the libraries they'll enable.


that example isnt relevant.  notice how the description includes the word
prefer and isnt just enable mp3 support.


The description is misleading, and needs to be changed.  Just because 
something has an mp3 and a lame use flag, it does not mean that flipping 
on lame means that the application will prefer lame over mad or mpg123.


/nit

Steve



Re: [gentoo-dev] New global use flag: vpx or vp8

2010-07-31 Thread Mike Frysinger
On Saturday, July 31, 2010 16:02:51 Steve Dibb wrote:
 On 07/31/2010 12:51 PM, Mike Frysinger wrote:
  On Saturday, July 31, 2010 14:27:14 Jacob Godserv wrote:
  Honestly not sure what convention is for naming, but I found this
  
  recently, and thought I might throw it out there:
~ $ euse -i lame
  
  
  [+ C  ] lame - Prefer using LAME libraries for MP3 encoding support
  
  
  While, as a user, I prefer this to be mp3, I also understand there may
  be more than one library for such-and-so, so I'm willing to read up on
  USE flags to find out which is the best to use. Overall, I would prefer
  naming according to the names of the libraries they'll enable.
  
  that example isnt relevant.  notice how the description includes the word
  prefer and isnt just enable mp3 support.
 
 The description is misleading, and needs to be changed.  Just because
 something has an mp3 and a lame use flag, it does not mean that flipping
 on lame means that the application will prefer lame over mad or mpg123.

sounds like a bug in the package, or the package metadata.xml needs updating.  
the current lame desc sounds fine to me.
-mike


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Locale check in python_pkg_setup()

2010-07-31 Thread Petteri Räty
On 07/31/2010 11:10 PM, Arfrever Frehtes Taifersar Arahesis wrote:

 If the variable is set but not exported then it is local to the shell
 env.  When bash goes to exec() python the local shell variables are
 not in the env; so os.environ() will not contain them.

 anta...@kyoto ~ $ foo=BAR
 anta...@kyoto ~ $ echo $foo
 BAR
 anta...@kyoto ~ $ python -c 'import os; print os.environ.get(foo)'
 None
 anta...@kyoto ~ $ export foo
 anta...@kyoto ~ $ python -c 'import os; print os.environ.get(foo)'
 BAR
 
 I want only variables exported to Python processes.
 

export -p

Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Locale check in python_pkg_setup()

2010-07-31 Thread James Cloos
 PH == Paweł Hajdan, phajdan...@gentoo.org writes:

PH Another thing we can consider is making UTF8 the default setup in
PH Gentoo. I think most people (including me) don't care whether it's
PH C or UTF8 as long as it works.

Forcing utf-8 will only be reasonable when there is a C.UTF-8 and/or
a POSIX.UTF-8 locale.

That should be done upstream in glibc, but were they to refuse then
Gentoo should add it to the glibc ebuild.

The language_country locales are just wrong for root.  They are often
broken (locales like en_US force case-insensitive colation, meaning that
a command such as 'rm [a-z]*' will unlink(2) 'Makefile' and similar files
which one would not expect to match) and cause bugs.

In fact, glibc's insistance that C and POSIX are ascii rather than raw
unspecified eight bit is itself a bug.

Utf8 is nice, but forcing the lang_country locales on root is not.

-JimC
-- 
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6



Re: [gentoo-dev] Locale check in python_pkg_setup()

2010-07-31 Thread Mike Frysinger
On Saturday, July 31, 2010 17:39:27 James Cloos wrote:
 Paweł Hajdan writes:
  Another thing we can consider is making UTF8 the default setup in
  Gentoo. I think most people (including me) don't care whether it's
  C or UTF8 as long as it works.
 
 Forcing utf-8 will only be reasonable when there is a C.UTF-8 and/or
 a POSIX.UTF-8 locale.
 
 In fact, glibc's insistance that C and POSIX are ascii rather than raw
 unspecified eight bit is itself a bug.

yeah, no.  take it up with the POSIX group where they're already working on 
defining a C.UTF-8/etc... locale.

 That should be done upstream in glibc, but were they to refuse then
 Gentoo should add it to the glibc ebuild.

this doesnt really make sense, upstream or down.  if you wanted to talk about 
setting default LANG in the baselayout, then that's about the only reasonable 
possibility (especially since we already do this to a degree).  screwing with 
default locale when no locale variables are set is madness.

 The language_country locales are just wrong for root.  They are often
 broken (locales like en_US force case-insensitive colation, meaning that
 a command such as 'rm [a-z]*' will unlink(2) 'Makefile' and similar files
 which one would not expect to match) and cause bugs.

this is pure opinion
-mike


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Locale check in python_pkg_setup()

2010-07-31 Thread Mike Frysinger
On Saturday, July 31, 2010 18:14:50 James Cloos wrote:
 Mike Frysinger writes:
  screwing with default locale when no locale variables are set is
  madness.
 
 I never said anything about changing C or POSIX.  Only about creating
 C.UTF-8 and/or POSIX.UTF-8.

sorry, i misread.  thought you were talking about changing default behavior 
and not just the creation of new locales.

  The language_country locales are just wrong for root.
 
  this is pure opinion
 
 Expert opinion.

i'm sure you're of that opinion ;).  my point was that the default isnt going 
to change in Gentoo that doesnt go through glibc, and that is most likely to 
not change either.
-mike


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Re: Locale check in python_pkg_setup()

2010-07-31 Thread Jonathan Callen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/31/2010 05:39 PM, James Cloos wrote:
 PH == Paweł Hajdan, phajdan...@gentoo.org writes:
 
 PH Another thing we can consider is making UTF8 the default setup in
 PH Gentoo. I think most people (including me) don't care whether it's
 PH C or UTF8 as long as it works.
 
 Forcing utf-8 will only be reasonable when there is a C.UTF-8 and/or
 a POSIX.UTF-8 locale.
 
 That should be done upstream in glibc, but were they to refuse then
 Gentoo should add it to the glibc ebuild.
 
 The language_country locales are just wrong for root.  They are often
 broken (locales like en_US force case-insensitive colation, meaning that
 a command such as 'rm [a-z]*' will unlink(2) 'Makefile' and similar files
 which one would not expect to match) and cause bugs.
 
 In fact, glibc's insistance that C and POSIX are ascii rather than raw
 unspecified eight bit is itself a bug.
 
 Utf8 is nice, but forcing the lang_country locales on root is not.
 
 -JimC

You can create a POSIX.UTF-8 locale right now, using the same
/etc/locale.gen mechanism that is used for generating other locales
(localedef will output a few warnings, but the generated locale works
just fine from what I can see).  If you want a C.UTF-8 locale, then you
just need to symlink /usr/share/i18n/locales/C to POSIX (or call
localedef directly as localedef --add-to-archive -i POSIX -f UTF-8
C.UTF-8).

If there are any issues with those locales besides the warnings that
localedef outputs, I haven't seen them yet.

- -- 
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJMVLH7AAoJELHSF2kinlg4+VYQAIB/Qc3Oq6lmK6tgiXADjk1Y
ICMCTbxyuCRNkfllwVqqIKEMUE/UmkqIjkY2/1m2uHp3kIm8tErSa1AohdSoJncc
7LIH17daM7T9XylA7DoqX7et3E3mtl8SerGHFMQ7ae0qYMUkbnNeyeUq4mVhH35G
IazjLFCIn0KlLmsim+8ILh8OQ4NWGK1JQlqXDluxHb3BVK37XDLWmvz5gG1+CTmS
KrmL3ek+BujiHOfAuvc86jFi9rWMP/yPh8OMIOsG41e/4hdNnhhhwiF0MHRs6bpO
Ql3FLsQjS5J7o6MC5690r/Ov/qHj/PAVITXft5cEQhq/gK17sg5TM5zs1JZxNMpH
T5z8LuSJenB6hF/+Gk0aew0XKig52539KZRnYShyl9z0QlLUlmwj0L3t8cFnm1in
2ttaeVttc4P2gwaF5Uf4ljEPFJ5w3lVIsXtRJklcPOjDUlCwnpYU0y5GS7RtAXJG
l/4Ax2/yW8P070dg7AoYh1WVTY1ChsyRNTECFYfge8ra5OnXT9HJPVBm7FFTof+L
IYXJ8zOGnDm32xsiov0LsrYC5KiD+FixkqTiPUHnbZm9KmI/HCyvnODm3cD+k8ts
Ht4JXxdVPEjv37bpDgdSbrI2vFb3sfpdH/wY1LMoAU00p9f/xwM2d9R1i+Q08CBV
74aYdVDpAQi5Kqevehw8
=7bB7
-END PGP SIGNATURE-