[gentoo-dev] Re: [RFC] GLes and OpenVG related management
Luca Barbato posted on Sun, 22 Aug 2010 22:49:19 +0200 as excerpted: gles - prefer using egl+opengles instead of glx+opengl openvg - enable openvg support For anyone else as clueless as I was, the wikipedia entries and a short descriptive excerpt from each: http://en.wikipedia.org/wiki/GLES OpenGL for Embedded Systems (OpenGL ES) is a subset of the OpenGL 3D graphics API designed for embedded devices such as mobile phones, PDAs, and video game consoles. OpenGL ES is managed by the not-for-profit technology consortium, the Khronos Group, Inc. http://en.wikipedia.org/wiki/Openvg OpenVG is a standard API designed for hardware-accelerated 2D vector graphics. It is aimed primarily at cell phones, media and gaming consoles such as the PlayStation 3, and other consumer electronic devices. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Please help us decide naming scheme for cmake use calls
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, as we discussed on scons.eclass thread at -dev ml we should have some nice naming scheme for use_xxx calls with cmake and scons. And it should be done in same fashion. for both So please head up to the formus poll [1] and vote for your favorite. The vote is open for 30 days starting 23. 8. 2010. This call is for developers/ht/at only. Users can't vote on this one. Cheers [1] http://forums.gentoo.org/viewtopic-t-841360.html - Tomáš Chvátal Gentoo Linux Developer [Cluster/Council/KDE/QA/Sci/X11] E-Mail : scarab...@gentoo.org GnuPG FP: 94A4 5CCD 85D3 DE24 FE99 F924 1C1E 9CDE 0341 4587 GnuPG ID: 03414587 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxyKo8ACgkQHB6c3gNBRYcxwwCeLafmCrz+ZfxkfRcGJX0Fb41v FsoAn2jdpxjRpOv5QwlqNrFBz4u8HqKj =q0uR -END PGP SIGNATURE-
Re: [gentoo-dev] Please help us decide naming scheme for cmake use calls
2010/8/23 Tomáš Chvátal scarab...@gentoo.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, as we discussed on scons.eclass thread at -dev ml we should have some nice naming scheme for use_xxx calls with cmake and scons. And it should be done in same fashion. for both So please head up to the formus poll [1] and vote for your favorite. just pick one. I'm sure Mike would be happy if you followed the 'standard' but I doubt he would be heartbroken if you went the other way. I don't really see the point of voting on which color we should paint the bikeshed[1]. (for those who live under a rock and have never built a bikeshed) [1] http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality The vote is open for 30 days starting 23. 8. 2010. This call is for developers/ht/at only. Users can't vote on this one. Cheers [1] http://forums.gentoo.org/viewtopic-t-841360.html - Tomáš Chvátal Gentoo Linux Developer [Cluster/Council/KDE/QA/Sci/X11] E-Mail : scarab...@gentoo.org GnuPG FP : 94A4 5CCD 85D3 DE24 FE99 F924 1C1E 9CDE 0341 4587 GnuPG ID : 03414587 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxyKo8ACgkQHB6c3gNBRYcxwwCeLafmCrz+ZfxkfRcGJX0Fb41v FsoAn2jdpxjRpOv5QwlqNrFBz4u8HqKj =q0uR -END PGP SIGNATURE-
[gentoo-dev] Last rites: conary, conary-policy, rmake, flickrfs
+# Dirkjan Ochtman d...@gentoo.org (23 Aug 2010) +# Unmaintained, uninstallable on version of Python we ship. +# Bugs 267346, 267347, 267348, 267356. +# Masked for removal in 30 days. +app-admin/conary +app-admin/conary-policy +app-admin/rmake +sys-fs/flickrfs Cheers, Dirkjan
Re: [gentoo-dev] Please help us decide naming scheme for cmake use calls
as we discussed on scons.eclass thread at -dev ml we should have some nice naming scheme for use_xxx calls with cmake and scons. And it should be done in same fashion. for both So please head up to the formus poll [1] and vote for your favorite. Apparently I don't even have a dev forum account set up (and I don't care), but count my vote as who cares if there's such an option. -- Best Regards Piotr Jaroszyński
Re: [gentoo-dev] The future of sys-apps/openrc in Gentoo
On Sun, Jul 04, 2010 at 09:03:41PM -0400, Olivier Cr?te wrote: On Sun, 2010-07-04 at 18:15 -0400, Mike Frysinger wrote: which is trivial to fix and anyone with commit privs could have done. it certainly doesnt warrant a paniced the sky is falling message. I think this is a great occasion to dump our stupid custom crap and switch to SystemD, PolicyKit, NetworkManager, etc. Anyone with half a brain already dropped our stuff. And the lack of use of modern tools is the reason I don't use Gentoo on my work computer anymore. I wasn't looking to run Ubuntu, but thanks anyway 8)
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
Le lundi 05 juillet 2010 à 08:57 +, Duncan a écrit : [lots of stuff about bashisms and posix] So let's stabilize OpenRC and be done with it, and /then/ we can debate where we want to go from there. YES, let's get it stable. However please consider not re-adding bashisms and/or not make it less POSIX shell compliant than it already is at light speed. It is a great thing that openrc tries to achieve and allows more use of openrc than basic desktop/server gentoo usage (think embedded and other distros). At least one other distro did this move a while ago (debian) and I don't think they will go back. Seeing they are also moving to a dependency based init system, they probably could just run a fork of openrc (for their init scripts are not exactly compatible with what we do). -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Re: New eclass: scons.eclass
On Sun, 22 Aug 2010 23:03:44 +0200 Maciej Mrozowski reave...@gmail.com wrote: I'd suggest providing all src_* phases except src_unpack. Providing a blank src_configure() would be fine but... Even src_prepare that calls base_src_prepare - to get PATCHES and epatch_user support - for simplicity requiring EAPI-2 as providing src_unpack in buildsystem eclasses is a bad design (like providing src_prepare in scm eclasses - this one is yet to be fixed). Why would I do that? If an ebuild needs to use base_src_prepare(), why can't it simply inherit the base eclass? Nothing buildsystem-specific needs to be done in src_prepare() here. And requiring EAPI=2 is even more pointless as SCons doesn't mostly distinguish between 'configure' and 'build' phases. Also calling base_src_install in scons_src_install if possible would be nice (DOCS, HTML_DOCS support) - to make it resemble cmake-utils, autotools-utils, and a bit of distutils, qt4-edge and gnome2 eclasses. Even more pointless. Although we can assume many of the SConstruct files use the name 'install' for their 'install' target, we can't do that for 'DESTDIR' or how a particular project calls it. Not to mention some don't provide such a thing at all. Every SCons-based ebuild should redefine src_install(). -- Best regards, Michał Górny http://mgorny.alt.pl xmpp:mgo...@jabber.ru signature.asc Description: PGP signature
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/23/2010 10:05 AM, Gilles Dartiguelongue wrote: Le lundi 05 juillet 2010 à 08:57 +, Duncan a écrit : [lots of stuff about bashisms and posix] So let's stabilize OpenRC and be done with it, and /then/ we can debate where we want to go from there. YES, let's get it stable. However please consider not re-adding bashisms and/or not make it less POSIX shell compliant than it already is at light speed. It is a great thing that openrc tries to achieve and allows more use of openrc than basic desktop/server gentoo usage (think embedded and other distros). At least one other distro did this move a while ago (debian) and I don't think they will go back. Seeing they are also moving to a dependency based init system, they probably could just run a fork of openrc (for their init scripts are not exactly compatible with what we do). There are still some bugs we are working on fixing. Once we are ready for it to move stable we will. Anyone that is wanting to help get things moving a bit faster can always join #gentoo-base and provide patches and help resolve known issues. - -- == Jory A. Pratt anarchy -at- gentoo.org Gentoo Mozilla Lead GPG: 2C1D 6AF9 F35D 5122 0E8F 9123 C270 3B43 5674 6127 == -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxykOIACgkQwnA7Q1Z0YSeN3wCfYQjJ9CJzvQqncQvUMqqwwBax cAQAn2ojNSggCJk6uf4LG4l7uojP6uoL =l1Re -END PGP SIGNATURE-
Re: [gentoo-dev] Please help us decide naming scheme for cmake use calls
On Mon, Aug 23, 2010 at 02:56:23PM +0200, Piotr Jaroszy??ski wrote: Apparently I don't even have a dev forum account set up If anyone wants their developer status on the forums who doesn't have it then send us an e-mail to forum-m...@gentoo.org or pop into #gentoo-forums and we'll sort it out for you. Cheers, tomk pgp2bspNZmf5y.pgp Description: PGP signature
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On Monday, August 23, 2010 11:05:45 Gilles Dartiguelongue wrote: However please consider not re-adding bashisms and/or not make it less POSIX shell compliant than it already is at light speed. no one was talking about doing anything of the sort -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New eclass: scons.eclass
On Sun, 22 Aug 2010 20:39:23 +0200
Michał Górny gen...@mgorny.alt.pl wrote:
The third revision, almost all suggestions applied. The ChangeLog:
151ddf2 Support passing a flag list to scons_clean_makeopts().
82a3ee7 Output the resulting flag list in scons_clean_makeopts()
instead of assigning it.
8062ec7 Provide a blank src_configure() for EAPI 2+.
33b4406 Drop default pkg_setup() -- no longer necessary.
44188e0 escons(): set SCONSOPTS implicitly if they are unset.
0f2ea92 Fix tests to use underscores in function names.
ccf1ef9 Introduce SCONSOPTS and use it instead of MAKEOPTS.
501ba41 Rename scons_use() to use_scons(), and the related vars.
681d73f Print the complete SCons command line in escons().
194e52e Use @DEFAULT-UNSET.
42aec9f Remove incorrect @CODE use.
Attaching the eclass r3 and a diff against r2.
--
Best regards,
Michał Górny
http://mgorny.alt.pl
xmpp:mgo...@jabber.ru
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: scons.eclass
# @MAINTAINER:
# gen...@mgorny.alt.pl
# @BLURB: helper functions to deal with SCons buildsystem
# @DESCRIPTION:
# This eclass provides a set of function to help developers sanely call
# dev-util/scons and pass parameters to it.
# -- public variables --
# @ECLASS-VARIABLE: SCONS_MIN_VERSION
# @DESCRIPTION:
# The minimal version of SCons required for the build to work.
# @DEFAULT-UNSET
# @ECLASS-VARIABLE: SCONSOPTS
# @DESCRIPTION:
# The default set of options to pass to scons. Similar to MAKEOPTS,
# supposed to be set in make.conf. If unset, will be generated from
# MAKEOPTS.
# @DEFAULT-UNSET
# @ECLASS-VARIABLE: EXTRA_ESCONS
# @DESCRIPTION:
# The additional parameters to pass to SCons whenever escons() is used.
# @DEFAULT-UNSET
# @ECLASS-VARIABLE: USE_SCONS_TRUE
# @DESCRIPTION:
# The default value for truth in scons-use() (1 by default).
: ${USE_SCONS_TRUE:=1}
# @ECLASS-VARIABLE: USE_SCONS_FALSE
# @DESCRIPTION:
# The default value for false in scons-use() (0 by default).
: ${USE_SCONS_FALSE:=0}
# -- ebuild variables setup --
if [[ -n ${SCONS_MIN_VERSION} ]]; then
DEPEND==dev-util/scons-${SCONS_MIN_VERSION}
else
DEPEND=dev-util/scons
fi
# -- exported phase functions --
case ${EAPI:-0} in
1|0) EXPORT_FUNCTIONS src_compile;;
*) EXPORT_FUNCTIONS src_configure src_compile;;
esac
# @FUNCTION: scons_src_configure
# @DESCRIPTION:
# A blank src_configure() for SCons packages not using explicit
# configure phase.
scons_src_configure() {
debug-print-function ${FUNCNAME} $...@}
}
# @FUNCTION: scons_src_compile
# @DESCRIPTION:
# The exported src_compile() implementation. Simply calls escons().
scons_src_compile() {
debug-print-function ${FUNCNAME} $...@}
escons || die 'escons failed.'
}
# -- public functions --
# @FUNCTION: escons
# @USAGE: [scons-arg] ...
# @DESCRIPTION:
# Call scons, passing the supplied arguments, ${MAKEOPTS} and
# ${EXTRA_ESCONS}. Similar to emake.
escons() {
debug-print-function ${FUNCNAME} $...@}
# if SCONSOPTS are _unset_, create them from MAKEOPTS
if [[ -n ${SCONSOPTS+1} ]]; then
export SCONSOPTS=$(scons_clean_makeopts)
fi
set -- scons ${SCONSOPTS} ${EXTRA_ESCONS} $...@}
echo $...@} 2
$...@}
}
# @FUNCTION: scons_clean_makeopts
# @USAGE: [makeflags] [...]
# @DESCRIPTION:
# Strip the supplied makeflags (or ${MAKEOPTS} if called without
# an argument) of options not supported by SCons and make sure --jobs
# gets an argument. Output the resulting flag list (suitable
# for an assignment to SCONSOPTS).
scons_clean_makeopts() {
local new_makeopts
debug-print-function ${FUNCNAME} $...@}
if [[ ${#} -eq 0 ]]; then
debug-print Using MAKEOPTS: ${MAKEOPTS}
set -- ${MAKEOPTS}
else
# unquote if necessary
set -- ${*}
fi
while [[ ${#} -gt 0 ]]; do
case ${1} in
# clean, simple to check -- we like that
--jobs=*|--keep-going)
new_makeopts=${new_makeopts+${new_makeopts} }${1}
;;
# need to take a look at the next arg and guess
--jobs)
if [[ ${#} -gt 1 ${2} =~ [0-9]+ ]]; then
new_makeopts=${new_makeopts+${new_makeopts} }${1} ${2}
shift
else
# no value means no limit, let's pass a random int
new_makeopts=${new_makeopts+${new_makeopts} }${1}=255
fi
;;
# strip other long options
--*)
;;
# short option hell
-*)
local str new_optstr
new_optstr=
str=${1#-}
while [[ -n ${str} ]]; do
case ${str} in
k*)
new_optstr=${new_optstr}k
;;
# -j needs to come last
j)
if [[ ${#} -gt 1 ${2} =~ [0-9]+ ]]; then
new_optstr=${new_optstr}j ${2}
shift
else
new_optstr=${new_optstr}j 255
fi
;;
# otherwise, everything after -j is treated as an arg
j*)
new_optstr=${new_optstr}${str}
break
;;
esac
str=${str#?}
done
if [[ -n ${new_optstr} ]]; then
new_makeopts=${new_makeopts+${new_makeopts} }-${new_optstr}
fi
;;
esac
shift
Re: [gentoo-dev] New eclass: scons.eclass
On Monday, August 23, 2010 12:24:54 Michał Górny wrote:
The third revision, almost all suggestions applied. The ChangeLog:
if there are suggestions you've actively ignored, those should be noted
44188e0 escons(): set SCONSOPTS implicitly if they are unset.
ccf1ef9 Introduce SCONSOPTS and use it instead of MAKEOPTS.
i'm not sure caching the value and using it in between runs is a good idea.
unless you also cache the thing you're caching and compare it to make sure
your cache is no longer invalid.
i.e. export _SCONSOPTS_MAKEOPTS=${MAKEOPTS}, and then on every escons
invocation, make sure ${MAKEOPTS} hasnt changed in which case you need to
regenerate it. or just avoid the cache altogether and leave SCONSOPTS as a
hook specific to scons.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] New eclass: scons.eclass
On Mon, 23 Aug 2010 12:39:50 -0400
Mike Frysinger vap...@gentoo.org wrote:
On Monday, August 23, 2010 12:24:54 Michał Górny wrote:
The third revision, almost all suggestions applied. The ChangeLog:
if there are suggestions you've actively ignored, those should be
noted
I've replied to the specific suggestions but if you want, here's a
short summary:
- stripping ! from varname in use_scons() suggestion (I don't see a
real point there as I replied you),
- src_prepare() calling base_src_prepare() (it is better to inherit
base within the specific ebuild),
- src_install() calling base_src_install() (the base.eclass
implementation calls make).
i'm not sure caching the value and using it in between runs is a good
idea. unless you also cache the thing you're caching and compare it
to make sure your cache is no longer invalid.
i.e. export _SCONSOPTS_MAKEOPTS=${MAKEOPTS}, and then on every escons
invocation, make sure ${MAKEOPTS} hasnt changed in which case you
need to regenerate it. or just avoid the cache altogether and leave
SCONSOPTS as a hook specific to scons.
Can do, though I don't see a reason why anyone would mangle MAKEOPTS in
a middle of an ebuild using SCons.
PS Why don't your mails contain 'Reply-To' header like others do?
--
Best regards,
Michał Górny
http://mgorny.alt.pl
xmpp:mgo...@jabber.ru
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On Mon, 2010-08-23 at 17:05 +0200, Gilles Dartiguelongue wrote: Le lundi 05 juillet 2010 à 08:57 +, Duncan a écrit : [lots of stuff about bashisms and posix] So let's stabilize OpenRC and be done with it, and /then/ we can debate where we want to go from there. YES, let's get it stable. However please consider not re-adding bashisms and/or not make it less POSIX shell compliant than it already is at light speed. It is a great thing that openrc tries to achieve and allows more use of openrc than basic desktop/server gentoo usage (think embedded and other distros). At least one other distro did this move a while ago (debian) and I don't think they will go back. Seeing they are also moving to a dependency based init system, they probably could just run a fork of openrc (for their init scripts are not exactly compatible with what we do). Other distributions are going one step further and are going for shell-free boot. We should follow that lead. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: New eclass: scons.eclass
On Monday 23 of August 2010 17:11:47 Michał Górny wrote: On Sun, 22 Aug 2010 23:03:44 +0200 Maciej Mrozowski reave...@gmail.com wrote: I'd suggest providing all src_* phases except src_unpack. Providing a blank src_configure() would be fine but... Even src_prepare that calls base_src_prepare - to get PATCHES and epatch_user support - for simplicity requiring EAPI-2 as providing src_unpack in buildsystem eclasses is a bad design (like providing src_prepare in scm eclasses - this one is yet to be fixed). Why would I do that? If an ebuild needs to use base_src_prepare(), why can't it simply inherit the base eclass? Nothing buildsystem-specific needs to be done in src_prepare() here. And requiring EAPI=2 is even more pointless as SCons doesn't mostly distinguish between 'configure' and 'build' phases. Because if you're to provide src_prepare, for EAPI2 you need to provide src_unpack as well but it's wrong in buildsystem eclasses as I already pointed out (since src_unpack:EAPI1 - src_unpack:EAPI2 + src_prepare:EAPI2), and requiring EAPI-2 allows you to avoid it. If you don't care for PATCHES or user_patches and hence compliance with other buildsystem eclasses, feel free. Also calling base_src_install in scons_src_install if possible would be nice (DOCS, HTML_DOCS support) - to make it resemble cmake-utils, autotools-utils, and a bit of distutils, qt4-edge and gnome2 eclasses. Even more pointless. Although we can assume many of the SConstruct files use the name 'install' for their 'install' target, we can't do that for 'DESTDIR' or how a particular project calls it. Not to mention some don't provide such a thing at all. Every SCons-based ebuild should redefine src_install(). Like I said, if you don't care for consistency with the rest, feel free to ignore. If SCons is unpredictable, then don't provide *any* phases and only functions and rename it to scons-utils to match its purpose (we're quite likely planning to rename cmake-utils.eclass to cmake.eclass for said consistency, unfortunately it was introduced in first place with such name and provided phases). What I hate is deliberately introduced inconsistency in ebuild API's. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23/08/10 18:26, Olivier Crête wrote: Other distributions are going one step further and are going for shell-free boot. We should follow that lead. Why? Presumably they're doing it by writing programs that do their own parsing and executing, which means they'll need a maintainer just for that program and they'll have to go through a few iterations to get the initial bugs out, and then people will have to learn how to use the different-yet-again language that goes with it. Why not rely on a prebuilt parser that devs already have to know to look after ebuilds? I'm happy to accept that there might be some very good reasons (respawning a shell for each script is time consuming/expensive?), but without describing what those reasons are, it's not a direction we should just be following blindly... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkxyuXMACgkQu7rWomwgFXrqSwCgjANV5zpo/uYrML+q1mCXHVgI ghcAn2oRJMUl4V+L4UHhEABYUs58e9c5 =jen/ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On Mon, 2010-08-23 at 19:09 +0100, Mike Auty wrote: On 23/08/10 18:26, Olivier Crête wrote: Other distributions are going one step further and are going for shell-free boot. We should follow that lead. Why? Presumably they're doing it by writing programs that do their own parsing and executing, which means they'll need a maintainer just for that program and they'll have to go through a few iterations to get the initial bugs out, and then people will have to learn how to use the different-yet-again language that goes with it. Why not rely on a prebuilt parser that devs already have to know to look after ebuilds? Systemd uses ini style files for configuration (and symlinks). So there really isn't much of a parser in there. And obviously, they're going through some bugfixing right now, so when F14/F15 are out there, we can just take their complete solution ;) -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On 23/08/10 02:28 PM, Olivier Crête wrote: On Mon, 2010-08-23 at 19:09 +0100, Mike Auty wrote: On 23/08/10 18:26, Olivier Crête wrote: Other distributions are going one step further and are going for shell-free boot. We should follow that lead. Why? Presumably they're doing it by writing programs that do their own parsing and executing, which means they'll need a maintainer just for that program and they'll have to go through a few iterations to get the initial bugs out, and then people will have to learn how to use the different-yet-again language that goes with it. Why not rely on a prebuilt parser that devs already have to know to look after ebuilds? Systemd uses ini style files for configuration (and symlinks). So there really isn't much of a parser in there. And obviously, they're going through some bugfixing right now, so when F14/F15 are out there, we can just take their complete solution ;) What are you actual complaints about openrc? What is wrong with using shell for bootup, it works, it's fast (especially with openrc's ability to be executed with dash) and _extremely_ flexible.
Re: [gentoo-dev] New eclass: scons.eclass
On Monday, August 23, 2010 13:16:38 Michał Górny wrote:
On Mon, 23 Aug 2010 12:39:50 -0400 Mike Frysinger wrote:
i'm not sure caching the value and using it in between runs is a good
idea. unless you also cache the thing you're caching and compare it
to make sure your cache is no longer invalid.
i.e. export _SCONSOPTS_MAKEOPTS=${MAKEOPTS}, and then on every escons
invocation, make sure ${MAKEOPTS} hasnt changed in which case you
need to regenerate it. or just avoid the cache altogether and leave
SCONSOPTS as a hook specific to scons.
Can do, though I don't see a reason why anyone would mangle MAKEOPTS in
a middle of an ebuild using SCons.
i agree, but you might as have it work properly in all cases instead of
flaking out randomly on ebuild authors. i think someone told me something
similar recently in a bug report about cvs.eclass ..
PS Why don't your mails contain 'Reply-To' header like others do?
you can subscribe to a list but have delivery turned off
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] The future of sys-apps/openrc in Gentoo
On 07/05/2010 03:03 AM, Olivier Crête wrote: On Sun, 2010-07-04 at 18:15 -0400, Mike Frysinger wrote: which is trivial to fix and anyone with commit privs could have done. it certainly doesnt warrant a paniced the sky is falling message. I think this is a great occasion to dump our stupid custom crap and switch to SystemD, PolicyKit, NetworkManager, etc. Anyone with half a brain already dropped our stuff. And the lack of use of modern tools is the reason I don't use Gentoo on my work computer anymore. Not suitable for all our use-cases, not as stable as openrc nowadays, not as fast as suggested and for server usage plainly wrong. I'd put openrc on freedesktop btw. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
[gentoo-dev] Re: gentoo-x86 commit in perl-core/IO-Compress:
* Mike Frysinger (vapier) vap...@gentoo.org:
vapier 10/08/23 20:01:12
Modified: IO-Compress-2.027.ebuild IO-Compress-2.024.ebuild
IO-Compress-2.026.ebuild ChangeLog
IO-Compress-2.025.ebuild IO-Compress-2.030.ebuild
IO-Compress-2.021.ebuild
Log:
Add proper blockers to old split packages #274443.
RDEPEND=virtual/perl-Scalar-List-Utils
=virtual/perl-Compress-Raw-Zlib-${PV}
- =virtual/perl-Compress-Raw-Bzip2-${PV}
+ =virtual/perl-Compress-Raw-Bzip2-${PV}
+ !perl-core/Compress-Zlib
+ !perl-core/IO-Compress-Zlib
+ !perl-core/IO-Compress-Bzip2
+ !perl-core/IO-Compress-Base
DEPEND=${RDEPEND}
#test? ( dev-perl/Test-Pod )
How long do you think the blockers should exist?
12 months ago they were removed from perl-core.
16 months ago they were moved from dev-perl to perl-core. Do you want to
block them too?
Why didn't anybody reply to
mid.gmane.org/20100803082816.tac2b81f...@veller.net
It's the same problem.
--
Regards
Re: [gentoo-dev] The future of sys-apps/openrc in Gentoo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/23/2010 04:21 PM, Luca Barbato wrote: On 07/05/2010 03:03 AM, Olivier Crête wrote: On Sun, 2010-07-04 at 18:15 -0400, Mike Frysinger wrote: which is trivial to fix and anyone with commit privs could have done. it certainly doesnt warrant a paniced the sky is falling message. I think this is a great occasion to dump our stupid custom crap and switch to SystemD, PolicyKit, NetworkManager, etc. Anyone with half a brain already dropped our stuff. And the lack of use of modern tools is the reason I don't use Gentoo on my work computer anymore. Not suitable for all our use-cases, not as stable as openrc nowadays, not as fast as suggested and for server usage plainly wrong. I'd put openrc on freedesktop btw. lu Agreed. For example, if one does cluster management with pacemaker or heartbeat you need to stick to more traditional shell based init scripts. Except for the lack of manpower, it would be nice to offer our users different flavors of system startups, but dropping openrc would not be a good idea. - -- Anthony G. Basile, Ph.D. Gentoo Developer -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxy2mYACgkQl5yvQNBFVTWXagCeMSxOP31Ze32pexpBLh9m0H0T u5UAnjhiMPMGjnu5MULrfwibGORBC31A =UXGG -END PGP SIGNATURE-
[gentoo-dev] [rfc] Making a Makefile respect custom CFLAGS
Hello! I assume this Makefile to work with any non-GNU make: CFLAGS=`sdl-config --cflags` -Wall -Wextra LDFLAGS=`sdl-config --libs` OBJ=tron.o pixel.o .PHONY: clean run tron: $(OBJ) run: tron ./tron clean: rm -f *.o tron Now how would we fix this to respect custom CFLAGS (and LDFLAGS) in a way that does not require GNU make (i.e. simply-expanded variables): [Recursively-expanded variables are] the only sort supported by other versions of make. [1] Any proposals for a generic solution that is upstream-suitable? While the Makefile presented here is not likely to go into the tree I had similar cases before so I felt like bringing this up. Thanks! Best, Sebastian [1] http://www.gnu.org/software/make/manual/make.html#Flavors
Re: [gentoo-dev] Re: gentoo-x86 commit in perl-core/IO-Compress:
On Monday, August 23, 2010 16:25:37 Torsten Veller wrote:
* Mike Frysinger (vapier) vap...@gentoo.org:
Log:
Add proper blockers to old split packages #274443.
RDEPEND=virtual/perl-Scalar-List-Utils
=virtual/perl-Compress-Raw-Zlib-${PV}
- =virtual/perl-Compress-Raw-Bzip2-${PV}
+ =virtual/perl-Compress-Raw-Bzip2-${PV}
+ !perl-core/Compress-Zlib
+ !perl-core/IO-Compress-Zlib
+ !perl-core/IO-Compress-Bzip2
+ !perl-core/IO-Compress-Base
How long do you think the blockers should exist?
12 months ago they were removed from perl-core.
16 months ago they were moved from dev-perl to perl-core. Do you want to
block them too?
i re-added them because i just hit them on a box that while not kept up-to-
date every week, i wouldnt consider old. i also dont think the 12 months
quote there fully encapsulates the time frame of things being in stable. this
box certainly was up-to-date less than 12 months ago and it apparently missed
this blocker time frame.
personally, i'd let these blockers sit for quite some time since it is really
no overhead and doesnt require maintenance.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] The future of sys-apps/openrc in Gentoo
On Monday, August 23, 2010 16:21:44 Luca Barbato wrote: I'd put openrc on freedesktop btw. we've sort of already settled into the places ... jumping to another place doesnt gain us much. current infrastructure also already enables all the Gentoo devs who wish to contribute (git/http/xml/bugzilla/etc...). -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [RFC ECLASS PATCH] Include exact Hg revision data for repeatability from logs.
The existing EHG_REVISION is the target revision, usually 'tip', so it
doesn't help us reproduce a bug if the upstream tree has moved since log
creation.
Example output:
* Work directory: /var/tmp/portage/ global id: 44cff02c8042 branch: default
Signed-off-by: Robin H. Johnson robb...@gentoo.org
Index: mercurial.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/mercurial.eclass,v
retrieving revision 1.12
diff -p -w -b -B -u -r1.12 mercurial.eclass
--- mercurial.eclass2 Apr 2010 18:29:39 - 1.12
+++ mercurial.eclass23 Aug 2010 21:20:41 -
@@ -116,12 +116,20 @@ function mercurial_fetch {
fi
# Checkout working copy:
- einfo Creating working directory in ${WORKDIR}/${module} (revision:
${EHG_REVISION})
+ einfo Creating working directory in ${WORKDIR}/${module} (target
revision: ${EHG_REVISION})
hg clone \
${EHG_QUIET_CMD_OPT} \
--rev=${EHG_REVISION} \
${EHG_STORE_DIR}/${EHG_PROJECT}/${module} \
${WORKDIR}/${module} || die hg clone failed
+ # An exact revision helps a lot for testing purposes, so have some
output...
+ # id num branch
+ # fd6e32d61721 6276 default
+ local HG_REVDATA=($(hg identify -n -b -i ${WORKDIR}/${module}))
+ local HG_REV_ID=${HG_REVDATA[0]}
+ local HG_REV_NUM=${HG_REVDATA[1]}
+ local HG_REV_BRANCH=${HG_REVDATA[2]}
+ einfo Work directory: ${WORKDIR}/${module} global id: ${HG_REV_ID}
branch: ${HG_REV_BRANCH}
}
# @FUNCTION: mercurial_src_unpack
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgppGdqt5Bi6K.pgp
Description: PGP signature
Re: [gentoo-dev] [rfc] Making a Makefile respect custom CFLAGS
On Monday, August 23, 2010 17:01:10 Sebastian Pipping wrote: CFLAGS=`sdl-config --cflags` -Wall -Wextra LDFLAGS=`sdl-config --libs` SDL_CONFIG = sdl-config CPPFLAGS += `$(SDL_CONFIG) --cflags` CFLAGS += -Wall -Wextra LDLIBS += `$(SDL_CONFIG) --libs` although the SDL_CONFIG is crap anyways and you should be using autoconf and using gcc-specific-ish flags like -Wall -Wextra while not using GNU make seems kind of dumb. Now how would we fix this to respect custom CFLAGS (and LDFLAGS) in a way that does not require GNU make (i.e. simply-expanded variables): why is that a problem ? everyone and their dog has `gmake`. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [rfc] Making a Makefile respect custom CFLAGS
On Mon, 23 Aug 2010 23:01:10 +0200 Sebastian Pipping sp...@gentoo.org wrote: I assume this Makefile to work with any non-GNU make: CFLAGS=`sdl-config --cflags` -Wall -Wextra LDFLAGS=`sdl-config --libs` OBJ=tron.o pixel.o .PHONY: clean run tron: $(OBJ) run: tron ./tron clean: rm -f *.o tron I wouldn't be so sure about that. POSIX make manpage doesn't seem to provide a suffix-rule to link multiple .o files into a binary; but that might be just not expressed clearly enough for me. Now how would we fix this to respect custom CFLAGS (and LDFLAGS) in a way that does not require GNU make (i.e. simply-expanded variables): [Recursively-expanded variables are] the only sort supported by other versions of make. [1] Any proposals for a generic solution that is upstream-suitable? While the Makefile presented here is not likely to go into the tree I had similar cases before so I felt like bringing this up. Thanks! I personally tend to completely redefine the suffix rules, moving 'private' CFLAGS/LIBS to a LCFLAGS/LLIBS or similar. For a reference, you may take a look at: http://github.com/mgorny/autoupnp/blob/master/Makefile -- Best regards, Michał Górny http://mgorny.alt.pl xmpp:mgo...@jabber.ru signature.asc Description: PGP signature
Re: [gentoo-dev] New eclass: scons.eclass
On Mon, 23 Aug 2010 16:22:35 -0400
Mike Frysinger vap...@gentoo.org wrote:
On Monday, August 23, 2010 13:16:38 Michał Górny wrote:
On Mon, 23 Aug 2010 12:39:50 -0400 Mike Frysinger wrote:
i'm not sure caching the value and using it in between runs is a
good idea. unless you also cache the thing you're caching and
compare it to make sure your cache is no longer invalid.
i.e. export _SCONSOPTS_MAKEOPTS=${MAKEOPTS}, and then on every
escons invocation, make sure ${MAKEOPTS} hasnt changed in which
case you need to regenerate it. or just avoid the cache
altogether and leave SCONSOPTS as a hook specific to scons.
Can do, though I don't see a reason why anyone would mangle
MAKEOPTS in a middle of an ebuild using SCons.
i agree, but you might as have it work properly in all cases instead
of flaking out randomly on ebuild authors.
We're hitting another corner case then. What if user modifies SCONSOPTS
in the middle of an ebuild? We could export another variable keeping
resulting SCONSOPTS and comparing it with the current SCONSOPTS -- but
what if the ebuild author randomly hit the same flags that resulted
from MAKEOPTS-SCONSOPTS conversion (and changed MAKEOPTS at the same
time)?
If we consider it like that, we end up with the idea that re-generating
SCONSOPTS every time escons() is called is the only feasible solution
-- but I don't really think it is worth to waste the time considering
it.
--
Best regards,
Michał Górny
http://mgorny.alt.pl
xmpp:mgo...@jabber.ru
signature.asc
Description: PGP signature
Re: [gentoo-dev] New eclass: scons.eclass
On Monday, August 23, 2010 19:02:21 Michał Górny wrote:
On Mon, 23 Aug 2010 16:22:35 -0400 Mike Frysinger wrote:
On Monday, August 23, 2010 13:16:38 Michał Górny wrote:
On Mon, 23 Aug 2010 12:39:50 -0400 Mike Frysinger wrote:
i'm not sure caching the value and using it in between runs is a
good idea. unless you also cache the thing you're caching and
compare it to make sure your cache is no longer invalid.
i.e. export _SCONSOPTS_MAKEOPTS=${MAKEOPTS}, and then on every
escons invocation, make sure ${MAKEOPTS} hasnt changed in which
case you need to regenerate it. or just avoid the cache
altogether and leave SCONSOPTS as a hook specific to scons.
Can do, though I don't see a reason why anyone would mangle
MAKEOPTS in a middle of an ebuild using SCons.
i agree, but you might as have it work properly in all cases instead
of flaking out randomly on ebuild authors.
We're hitting another corner case then. What if user modifies SCONSOPTS
in the middle of an ebuild? We could export another variable keeping
resulting SCONSOPTS and comparing it with the current SCONSOPTS -- but
what if the ebuild author randomly hit the same flags that resulted
from MAKEOPTS-SCONSOPTS conversion (and changed MAKEOPTS at the same
time)?
If we consider it like that, we end up with the idea that re-generating
SCONSOPTS every time escons() is called is the only feasible solution
-- but I don't really think it is worth to waste the time considering
it.
then keep it simple and separate:
escons() {
debug-print-function ${FUNCNAME} $...@}
set -- scons $(scons_clean_makeopts) ${SCONSOPTS} ${EXTRA_ESCONS}
$...@}
echo $...@} 2
$...@}
}
now you dont have to worry about changes between invocations and the developer
has a clear path -- if they need to force a serial build for example, they can
either append MAKEOPTS, SCONSOPTS, or pass it straight to escons. no cache
confusion or desync between the vars.
-mike
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re:unsubscribe
Free as in Freedom --- On Mon, 23/8/10, gentoo-dev+h...@lists.gentoo.org gentoo-dev+h...@lists.gentoo.org wrote: From: gentoo-dev+h...@lists.gentoo.org gentoo-dev+h...@lists.gentoo.org Subject: Digest of gentoo-dev@lists.gentoo.org issue 831 (42344-42393) To: kunalbhar...@yahoo.com Date: Monday, 23 August, 2010, 8:38 PM Topics (messages 42344 through 42393): [gentoo-dev] Treecleaner Project: Maintainer-needed page 42344 - Markos Chandras hwoar...@gentoo.org [gentoo-dev] Treecleaner Project: Maintainer-needed page 42345 - Alec Warner anta...@gentoo.org [gentoo-dev] Treecleaner Project: Maintainer-needed page 42346 - Markos Chandras hwoar...@gentoo.org [gentoo-dev] Treecleaner Project: Maintainer-needed page 42347 - Thilo Bangert bang...@gentoo.org [gentoo-dev] Wiki(es) for Gentoo ?! 42348 - Thilo Bangert bang...@gentoo.org [gentoo-dev] Treecleaner Project: Maintainer-needed page 42349 - Markos Chandras hwoar...@gentoo.org [gentoo-dev] Lastrite: qt-faststart, modplugplay, playspc, realbasic, btg, old etheme pkgs 42350 - Samuli Suominen ssuomi...@gentoo.org [gentoo-dev] Gentoo calendar for tracking Gentoo events 42351 - Thilo Bangert bang...@gentoo.org [gentoo-dev] Treecleaner Project: Maintainer-needed page 42352 - Robin H. Johnson robb...@gentoo.org [gentoo-dev] Gentoo calendar for tracking Gentoo events 42353 - Mike Frysinger vap...@gentoo.org [gentoo-dev] Wiki(es) for Gentoo ?! 42354 - Alex Legler a...@gentoo.org [gentoo-dev] Treecleaner Project: Maintainer-needed page 42355 - Markos Chandras hwoar...@gentoo.org [gentoo-dev] Gentoo calendar for tracking Gentoo events 42356 - Thilo Bangert bang...@gentoo.org [gentoo-dev] Gentoo calendar for tracking Gentoo events 42357 - Thilo Bangert bang...@gentoo.org [gentoo-dev] Wiki(es) for Gentoo ?! 42358 - Thilo Bangert bang...@gentoo.org [gentoo-dev] Wiki(es) for Gentoo ?! 42359 - Alex Legler a...@gentoo.org [gentoo-dev] Lastrite: ferrisloki, stldb4, fampp2, libferrisstreams 42360 - Samuli Suominen ssuomi...@gentoo.org [gentoo-dev] Lastrite: ferrisloki, stldb4, fampp2, libferrisstreams 42361 - Mike Frysinger vap...@gentoo.org [gentoo-dev] Lastrite: ferrisloki, stldb4, fampp2, libferrisstreams 42362 - Samuli Suominen ssuomi...@gentoo.org [gentoo-dev] Lastrite: ferrisloki, stldb4, fampp2, libferrisstreams 42363 - Mike Frysinger vap...@gentoo.org [gentoo-dev] updated elass documentation syntax 42364 - Mike Frysinger vap...@gentoo.org [gentoo-dev] updated elass documentation syntax 42365 - ??? scarab...@gentoo.org [gentoo-dev] updated elass documentation syntax 42366 - Mike Frysinger vap...@gentoo.org [gentoo-dev] updated elass documentation syntax 42367 - ??? scarab...@gentoo.org [gentoo-dev] updated elass documentation syntax 42368 - Mike Frysinger vap...@gentoo.org [gentoo-dev] New eclass: scons.eclass 42370 - Michał Górny gen...@mgorny.alt.pl [gentoo-dev] New eclass: scons.eclass 42371 - Alex Alexander wi...@gentoo.org [gentoo-dev] New eclass: scons.eclass 42373 - Michał Górny gen...@mgorny.alt.pl [gentoo-dev] New eclass: scons.eclass 42374 - Michał Górny gen...@mgorny.alt.pl [gentoo-dev] updated elass documentation syntax 42375 - Mike Frysinger vap...@gentoo.org [gentoo-dev] Re: New eclass: scons.eclass 42376 - Michał Górny gen...@mgorny.alt.pl [gentoo-dev] Re: New eclass: scons.eclass 42377 - Luca Barbato lu_z...@gentoo.org [gentoo-dev] [RFC] GLes and OpenVG related management 42378 - Luca Barbato lu_z...@gentoo.org [gentoo-dev] Re: New eclass: scons.eclass 42379 - Mike Frysinger vap...@gentoo.org [gentoo-dev] Re: New eclass: scons.eclass 42380 - Maciej Mrozowski reave...@gmail.com [gentoo-dev] Re: New eclass: scons.eclass 42382 - Mike Frysinger vap...@gentoo.org [gentoo-dev] Re: New eclass: scons.eclass 42383 - Tomáš Chvátal scarab...@gentoo.org [gentoo-dev] Re: New eclass: scons.eclass 42384 - Mike Frysinger vap...@gentoo.org [gentoo-dev] libtool.eclass cleanup 42385 - Mike Frysinger vap...@gentoo.org [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2010-08-22 23h59 UTC 42386 - Robin H. Johnson robb...@gentoo.org [gentoo-dev] Re: [RFC] GLes and OpenVG related management 42387 - Duncan 1i5t5.dun...@cox.net [gentoo-dev] Please help us decide naming scheme for cmake use calls 42388 - Tomáš Chvátal scarab...@gentoo.org [gentoo-dev] Please help us decide naming scheme for cmake use calls 42389 - Alec Warner anta...@gentoo.org [gentoo-dev] Last rites: conary, conary-policy, rmake, flickrfs 42390 - Dirkjan Ochtman d...@gentoo.org [gentoo-dev] Please help us decide naming scheme for cmake use calls 42391 - Piotr Jaroszyński pe...@gentoo.org [gentoo-dev] The future of sys-apps/openrc in Gentoo 42392 - Jon Portnoy
Re: [gentoo-dev] [RFC ECLASS PATCH] Include exact Hg revision data for repeatability from logs.
On 08/23/10 23:23, Robin H. Johnson wrote:
The existing EHG_REVISION is the target revision, usually 'tip', so it
doesn't help us reproduce a bug if the upstream tree has moved since log
creation.
Example output:
* Work directory: /var/tmp/portage/ global id: 44cff02c8042 branch:
default
Signed-off-by: Robin H. Johnson robb...@gentoo.org
Index: mercurial.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/mercurial.eclass,v
retrieving revision 1.12
diff -p -w -b -B -u -r1.12 mercurial.eclass
--- mercurial.eclass 2 Apr 2010 18:29:39 - 1.12
+++ mercurial.eclass 23 Aug 2010 21:20:41 -
@@ -116,12 +116,20 @@ function mercurial_fetch {
fi
# Checkout working copy:
- einfo Creating working directory in ${WORKDIR}/${module} (revision:
${EHG_REVISION})
+ einfo Creating working directory in ${WORKDIR}/${module} (target
revision: ${EHG_REVISION})
hg clone \
${EHG_QUIET_CMD_OPT} \
--rev=${EHG_REVISION} \
${EHG_STORE_DIR}/${EHG_PROJECT}/${module} \
${WORKDIR}/${module} || die hg clone failed
+ # An exact revision helps a lot for testing purposes, so have some
output...
+ # id num branch
+ # fd6e32d61721 6276 default
+ local HG_REVDATA=($(hg identify -n -b -i ${WORKDIR}/${module}))
+ local HG_REV_ID=${HG_REVDATA[0]}
+ local HG_REV_NUM=${HG_REVDATA[1]}
+ local HG_REV_BRANCH=${HG_REVDATA[2]}
+ einfo Work directory: ${WORKDIR}/${module} global id: ${HG_REV_ID}
branch: ${HG_REV_BRANCH}
}
# @FUNCTION: mercurial_src_unpack
+1 Robin :) Ship it!
--
Krzysztof Pawlik nelchael at gentoo.org key id: 0xF6A80E46
desktop-misc, java, apache, ppc, vim, kernel, python...
signature.asc
Description: OpenPGP digital signature
