[gentoo-dev] New global use flag: vpx or vp8
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-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
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
On Sat, Jul 31, 2010 at 4:09 PM, "Paweł Hajdan, Jr." 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
On Sat, 31 Jul 2010 16:30:06 +0100 Robert Bridge wrote: > 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. 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. -- Jacob "For then there will be great distress, unequaled from the beginning of the world until now — and never to be equaled again. If those days had not been cut short, no one would survive, but for the sake of the elect those days will be shortened." Are you ready? signature.asc Description: PGP signature
Re: [gentoo-dev] New global use flag: vpx or vp8
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()
On Sat, Jul 31, 2010 at 7:44 AM, Arfrever Frehtes Taifersar Arahesis
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
On 07/31/2010 05: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). Though we might discuss if vpx is really a good name or it shouldn't be vp8. Depends on the libraries / codecs being used. In this case, the library is libvpx. The codec is VP8. ffmpeg already has native support for playback of VP8, so we'll probably be splitting the use flags into two parts: vp8 and and libvpx. I would say, for most ebuilds, just use vp8 use flag. That will be obvious what it means. For webm support, add a use flag just for that. WebM is a *combination* of VP8 + Vorbis. Strictly speaking though, it's still just Matroska, so support for it will probably be native anyway in most stuff. Steve
Re: [gentoo-dev] New global use flag: vpx or vp8
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. Steve
Re: [gentoo-dev] Locale check in python_pkg_setup()
2010-07-31 21:49:50 Alec Warner napisał(a):
> On Sat, Jul 31, 2010 at 7:44 AM, Arfrever Frehtes Taifersar Arahesis
> 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
I want only variables exported to Python processes.
> so how is this any different than:
>
> [[ -n $LC_TYPE ]] && locale=$LC_TYPE
> [[ -n $LC_ALL ]] && locale=$LC_ALL
> locale=${locale:-POSIX}
This code uses non-exported variables.
> 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.
python_pkg_setup() is a rarely called function.
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] New global use flag: vpx or vp8
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()
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()
> "PH" == Paweł Hajdan, 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 OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Locale check in python_pkg_setup()
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()
> "MF" == Mike Frysinger writes: MF> take it up with the POSIX group where they're already working on MF> defining a C.UTF-8/etc... locale. Then they agree with me. Good to know. Thanks. MF> 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. >> The language_country locales are just wrong for root. MF> this is pure opinion Expert opinion. I've seen what can and will go wrong over the entire existance of the concept of locales (on Linux-based systems, at least). -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Locale check in python_pkg_setup()
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()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/31/2010 05:39 PM, James Cloos wrote: >> "PH" == Paweł Hajdan, 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-
