[gentoo-dev] Please review fortran-2.eclass
Hi all,
please review and comment the attached eclass.
Purpose of this eclass is the correct setting of a working fortran
compiler. There are numerous bugs which suffer from one or the other
defect here. Anybody who touch a fortran package knows what I am talking
about.
Currently we support two fortran compilers in the tree, soonish there
will be three. But we also like to like to allowed any out-of-tree
compiler. So depending on gcc[fortran] or virtual/fortran doesn't
fullfill the needs for one or the other reason, which I will not
elaborate again.
Our solution:
1. Depend on virtual/fortran. This will force the ordinary user to use
gfortran through gcc[fortran]. Or the intel compiler has to be selected
via FC=ifort. With this also any other solution can be selected.
2. Test whether FC is a working fortran compiler. Why? gcc:4.5[fortran]
and gcc:4.6[-fortran] can be emerged and gcc-4.6 selected. Thereby
virtual/fortran dependdencies are fullfiled but no working compiler is
there. Same happens in many other constellations.
3. Test for openmp support. For a mixture of the above reasons, it is
impossible to depend on openmp capabilities if user do change anything
from default.
4. Get_fcomp is needed for some packages which do not work with the full
name, e.g. seperate makefiles for intel and gnu compiler.
5. Once FC is working, set all other variable possibly defining fortran
compilers of any flavour to FC.
6. It is still possible without any change to ebuilds to integrate the
test functions in the toolchain-funcs eclass later, if we decide this is
a better way to handle those functions.
Thanks for attention, justin
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# Author Justin Lecher
# Test functions provided by Sebastien Fabbro and Kacper Kowalik
# @ECLASS: fortran-2.eclass
# @MAINTAINER:
# j...@gentoo.org
# s...@gentoo.org
# @BLURB: Packages, which need a fortran compiler should inherit this eclass.
# @DESCRIPTION:
# If you need a fortran compiler, inherit this eclass. This eclass tests for
# working fortran compilers. Optional, it checks for openmp capability of the
# current fortran compiler through FC_NEED_OPENMP=1.
# Only phase function exported is pkg_setup.
# @ECLASS-VARIABLE: FC_NEED_OPENMP
# @DESCRIPTION:
# Set FC_NEED_OPENMP=1 in order to test FC for openmp capabilities
#
# Default is 0
inherit toolchain-funcs
DEPEND="virtual/fortran"
RDEPEND="${DEPEND}"
# internal function
#
# FUNCTION: _have-valid-fortran
# DESCRIPTION:
# Check whether FC returns a working fortran compiler
_have-valid-fortran() {
local base=${T}/test-tc-fortran
cat <<- EOF > "${base}.f"
end
EOF
$(tc-getFC "$@") "${base}.f" -o "${base}" >&/dev/null
local ret=$?
rm -f "${base}"*
return ${ret}
}
# internal function
#
# FUNCTION: _fortran-has-openmp
# DESCRIPTION:
# See if the fortran supports OpenMP.
_fortran-has-openmp() {
local flag
case $(tc-getFC) in
*gfortran*|pathf*)
flag=-fopenmp ;;
ifort)
flag=-openmp ;;
mpi*)
local _fcomp=$($(tc-getFC) -show | awk '{print $1}')
FC=${_fcomp} _fortran-has-openmp
return $? ;;
*)
return 0 ;;
esac
local base=${T}/test-fc-openmp
# leave extra leading space to make sure it works on fortran 77 as well
cat <<- EOF > "${base}.f"
call omp_get_num_threads
end
EOF
$(tc-getFC "$@") ${flag} "${base}.f" -o "${base}" >&/dev/null
local ret=$?
rm -f "${base}"*
return ${ret}
}
# @FUNCTION: get_fcomp
# @DESCRIPTION:
# Returns the canonical name or the native compiler of the current fortran
compiler
#
# e.g.
#
# x86_64-linux-gnu-gfortran -> gfortran
get_fcomp() {
case $(tc-getFC) in
*gfortran* )
echo "gfortran" ;;
ifort )
echo "ifc" ;;
pathf*)
echo "pathcc" ;;
mpi*)
local _fcomp=$($(tc-getFC) -show | awk '{print $1}')
echo $(FC=${_fcomp} get_fcomp) ;;
* )
echo $(tc-getFC) ;;
esac
}
# @FUNCTION: fortran-2_pkg_setup
# @DESCRIPTION:
# Setup functionallity, checks for a valid fortran compiler and optionally for
its openmp support.
fortran-2_pkg_setup() {
_have-valid-fortran || \
die "Please emerge the current gcc with USE=fortran or export
FC defining a working fortran compiler"
export FC=$(tc-getFC)
export F77=$(tc-getFC)
export F90=$(tc-getFC)
export F95=$(tc-getFC)
if [[ ${FC_NEED_OPENMP} == 1 ]]; then
_fortran-has-openmp || \
Re: [gentoo-dev] Please review fortran-2.eclass
On 6/13/11 11:06 AM, justin wrote:
> # @FUNCTION: fortran-2_pkg_setup
> # @DESCRIPTION:
> # Setup functionallity, checks for a valid fortran compiler and optionally
> for its openmp support.
> fortran-2_pkg_setup() {
> _have-valid-fortran || \
> die "Please emerge the current gcc with USE=fortran or export
> FC defining a working fortran compiler"
> export FC=$(tc-getFC)
> export F77=$(tc-getFC)
> export F90=$(tc-getFC)
> export F95=$(tc-getFC)
> if [[ ${FC_NEED_OPENMP} == 1 ]]; then
> _fortran-has-openmp || \
> die "Please emerge current gcc with USE=openmp or export FC
> with compiler that supports OpenMP"
> fi
> }
>
> EXPORT_FUNCTIONS pkg_setup
I wonder if it's possible to take advantage of EAPI4's pkg_pretend, and
fall back to pkg_setup for older EAPIs. pkg_pretend makes it possible to
fix the setup before running emerge, instead of things breaking in the
middle.
It's just a suggestion.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Please review fortran-2.eclass
On 6/13/11 11:19 AM, "Paweł Hajdan, Jr." wrote:
> On 6/13/11 11:06 AM, justin wrote:
>> # @FUNCTION: fortran-2_pkg_setup
>> # @DESCRIPTION:
>> # Setup functionallity, checks for a valid fortran compiler and optionally
>> for its openmp support.
>> fortran-2_pkg_setup() {
>> _have-valid-fortran || \
>> die "Please emerge the current gcc with USE=fortran or export
>> FC defining a working fortran compiler"
>> export FC=$(tc-getFC)
>> export F77=$(tc-getFC)
>> export F90=$(tc-getFC)
>> export F95=$(tc-getFC)
>> if [[ ${FC_NEED_OPENMP} == 1 ]]; then
>> _fortran-has-openmp || \
>> die "Please emerge current gcc with USE=openmp or export FC
>> with compiler that supports OpenMP"
>> fi
>> }
>>
>> EXPORT_FUNCTIONS pkg_setup
>
> I wonder if it's possible to take advantage of EAPI4's pkg_pretend, and
> fall back to pkg_setup for older EAPIs. pkg_pretend makes it possible to
> fix the setup before running emerge, instead of things breaking in the
> middle.
>
> It's just a suggestion.
>
You are right. Thought about it, but refused it, because I din't want to
force EAPI=4. But right I can just use a fall back for EAPI<4. Thanks
for the suggestion.
[gentoo-dev] Packages up for grabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I have no interest in the following packages anymore. Most of them are low maintenance and/or supposed to be co-maintained by other herds 1) dev-util/ticpp 2) dev-vcs/qsvn 3) kde-misc/kcometen4 4) kde-misc/kgrubeditor 5) kde-misc/plasmatvgr 6) kde-misc/kanyremote 7) media-gfx/simple-scan 8) media-gfx/smile 9) media-gfx/pictureflow 10) media-sound/qpitch 11) media-sound/qtagger 12) media-video/avidemux 13) net-im/qutim 14) net-news/canto 15) sys-apps/daemonize 16) x11-misc/touchfreeze If you plan to pick any of these, please remove me from metadata.xml while you are at it. - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJN9djpAAoJEPqDWhW0r/LCBGAP/0lurPdOpR10NZmQzklTDfLg CG1ydzIDZlEQqg2AVxDuIM0S4w3B4v3CzNkU9yDmpPpxWSygcAyBYFRNw1WgwUqh tLpuEfpezhR5PNhs2GUAIrbJ8AMBN2qM3SaFEqzVBr+vwko6IbtBG1gblF+EqYM0 zOy2HV2ggui6/K8v6CV0KHLiEFH8RyCOuzkXv/F3bSqwiagDkUAHR9D5A0JoR2q6 IroP+PD4xaeEbvJxaAb1Or8Ng2lJYenLwOZhKgjXwm6XlDgl+gqbvXT86MfZDmQ5 9YpFBmEtRCiRLv4E+M91109m8xlAFJbP52kRhAwRRRtJeygNo19j4wPr9BXZJm1S YxGhVX3+ABEMbFx0lbp2SXXI5B5dR3NcqtA4J4cZlJahAB8U1KgF2gvvHPA63o09 Vg84sNPhvunO6dYjBSk/Z+BWiidDRsPIk6GSydudZTPYzwzzO7ZpCpWf52VjZyp4 guJ7lGT9AbRr7NJEYkwKp2IyfnlVSyvVAR9Fz0m/x0f4hqM5QrS0wofRIRrUsTjq rAKdKVc1O8gLVdHA6k8hXW02YVpOqcPnh/X1x1r+us8KGzQVLwX674X6JVBc1ahH 56TCqjBlUHgjWZwSkekbMMrznIJbPWhbwxwXX28wHAqtFgRaTGilTLxptQVM+xbd Q/LUbUsmsYTT/WwCdv2y =Qrda -END PGP SIGNATURE-
Re: [gentoo-dev] Reviving webapp-config
On 06/13/11 01:44, Maciej Mrozowski wrote: > On Friday 10 of June 2011 20:08:00 Ciaran McCreesh wrote: >> On Thu, 9 Jun 2011 16:37:46 -0500 >> >> Matthew Summers wrote: >>> After consultation and discussion at length with several developers, I >>> am writing to announce the impending revival of the tool known as >>> app-admin/webapp-config effective immediately. >> >> You might want to chuck it out and start from scratch... >> >> Much of the difficulty with the original webapp-config was that it was >> designed to work on Windows. Stuart's plan was to create a distribution >> and operating system independent way of dealing with web apps, sort of >> like CPAN; Gentoo was merely the testbed. If your goals don't match >> that, you're probably better rethinking everything than trying to revive >> something that was designed for a completely different purpose. > > Also, for pure Gentoo needs it may be better to replace webapp-config with > package manager and eclasses. How does that handle multiple installs etc.? > So to install web apps to /usr/share or sth and provide apache config files > to > set up those webapps like Debian does for instance ZOMG NOES. That stuff is horrible, it randomly patches the webserver config wrongly, then restarts the webserver - so installing nagios knocks out your apache. Which then makes for some funny debugging ... Let's aim higher than that, please, I don't want random misbehaviour :) - so dispatch-conf would be > utilized for tracking config file modifications and uninstall via unmerge > > One major obstacle is that we have quite a number of web servers to support > if > we're to provide out of the box experience for those web apps. > So provide a default config for, say, apache, and then figure out if that can be transcribed to others easily. Maybe it can be turned into simple templates to generate all configs from? -- Patrick Lauer http://service.gentooexperimental.org Gentoo Council Member and Evangelist Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds
Re: [gentoo-dev] Please review fortran-2.eclass
On 6/13/11 11:19 AM, "Paweł Hajdan, Jr." wrote:
> On 6/13/11 11:06 AM, justin wrote:
>> # @FUNCTION: fortran-2_pkg_setup
>> # @DESCRIPTION:
>> # Setup functionallity, checks for a valid fortran compiler and optionally
>> for its openmp support.
>> fortran-2_pkg_setup() {
>> _have-valid-fortran || \
>> die "Please emerge the current gcc with USE=fortran or export
>> FC defining a working fortran compiler"
>> export FC=$(tc-getFC)
>> export F77=$(tc-getFC)
>> export F90=$(tc-getFC)
>> export F95=$(tc-getFC)
>> if [[ ${FC_NEED_OPENMP} == 1 ]]; then
>> _fortran-has-openmp || \
>> die "Please emerge current gcc with USE=openmp or export FC
>> with compiler that supports OpenMP"
>> fi
>> }
>>
>> EXPORT_FUNCTIONS pkg_setup
>
> I wonder if it's possible to take advantage of EAPI4's pkg_pretend, and
> fall back to pkg_setup for older EAPIs. pkg_pretend makes it possible to
> fix the setup before running emerge, instead of things breaking in the
> middle.
>
> It's just a suggestion.
>
Now using the new pkg_pretend for EAPI=4
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# Author Justin Lecher
# Test functions provided by Sebastien Fabbro and Kacper Kowalik
# @ECLASS: fortran-2.eclass
# @MAINTAINER:
# j...@gentoo.org
# s...@gentoo.org
# @BLURB: Packages, which need a fortran compiler should inherit this eclass.
# @DESCRIPTION:
# If you need a fortran compiler, inherit this eclass. This eclass tests for
# working fortran compilers. Optional, it checks for openmp capability of the
# current fortran compiler through FC_NEED_OPENMP=1.
# Only phase function exported is pkg_setup.
# @ECLASS-VARIABLE: FC_NEED_OPENMP
# @DESCRIPTION:
# Set FC_NEED_OPENMP=1 in order to test FC for openmp capabilities
#
# Default is 0
inherit toolchain-funcs
DEPEND="virtual/fortran"
RDEPEND="${DEPEND}"
# internal function
#
# FUNCTION: _have-valid-fortran
# DESCRIPTION:
# Check whether FC returns a working fortran compiler
_have-valid-fortran() {
local base=${T}/test-tc-fortran
cat <<- EOF > "${base}.f"
end
EOF
$(tc-getFC "$@") "${base}.f" -o "${base}" >&/dev/null
local ret=$?
rm -f "${base}"*
return ${ret}
}
# internal function
#
# FUNCTION: _fortran-has-openmp
# DESCRIPTION:
# See if the fortran supports OpenMP.
_fortran-has-openmp() {
local flag
case $(tc-getFC) in
*gfortran*|pathf*)
flag=-fopenmp ;;
ifort)
flag=-openmp ;;
mpi*)
local _fcomp=$($(tc-getFC) -show | awk '{print $1}')
FC=${_fcomp} _fortran-has-openmp
return $? ;;
*)
return 0 ;;
esac
local base=${T}/test-fc-openmp
# leave extra leading space to make sure it works on fortran 77 as well
cat <<- EOF > "${base}.f"
call omp_get_num_threads
end
EOF
$(tc-getFC "$@") ${flag} "${base}.f" -o "${base}" >&/dev/null
local ret=$?
rm -f "${base}"*
return ${ret}
}
# @FUNCTION: get_fcomp
# @DESCRIPTION:
# Returns the canonical name or the native compiler of the current fortran
compiler
#
# e.g.
#
# x86_64-linux-gnu-gfortran -> gfortran
get_fcomp() {
case $(tc-getFC) in
*gfortran* )
echo "gfortran" ;;
ifort )
echo "ifc" ;;
pathf*)
echo "pathcc" ;;
mpi*)
local _fcomp=$($(tc-getFC) -show | awk '{print $1}')
echo $(FC=${_fcomp} get_fcomp) ;;
* )
echo $(tc-getFC) ;;
esac
}
# @FUNCTION: fortran-2_pkg_pretend
# @DESCRIPTION:
# Setup functionallity, checks for a valid fortran compiler and optionally for
its openmp support.
fortran-2_pkg_pretend() {
_have-valid-fortran || \
die "Please emerge the current gcc with USE=fortran or export
FC defining a working fortran compiler"
export FC=$(tc-getFC)
export F77=$(tc-getFC)
export F90=$(tc-getFC)
export F95=$(tc-getFC)
if [[ ${FC_NEED_OPENMP} == 1 ]]; then
_fortran-has-openmp || \
die "Please emerge current gcc with USE=openmp or export FC
with compiler that supports OpenMP"
fi
}
# @FUNCTION: fortran-2_pkg_setup
# @DESCRIPTION:
# Setup functionallity, checks for a valid fortran compiler and optionally for
its openmp support, used in EAPI < 4.
fortran-2_pkg_setup() {
has ${EAPI:-0} 0 1 2 3 && fortran-2_pkg_pretend
}
case "${EAPI:-0}" in
0|1|2|3)
EXPORT_FUNCTIONS pkg_setup;;
4)
EXPORT_FUNCTIONS pkg_pretend;;
*) die "EAP
Re: [gentoo-dev] Packages up for grabs
On Mon, Jun 13, 2011 at 12:31 PM, Markos Chandras wrote: > 2) dev-vcs/qsvn > 3) kde-misc/kcometen4 > 4) kde-misc/kgrubeditor > 5) kde-misc/plasmatvgr > 6) kde-misc/kanyremote > 8) media-gfx/smile > 9) media-gfx/pictureflow > 10) media-sound/qpitch > 11) media-sound/qtagger > 12) media-video/avidemux > 13) net-im/qutim > 16) x11-misc/touchfreeze > > If you plan to pick any of these, please remove me from metadata.xml > while you are at it. The above will still stay at either KDE or Qt, just remove yourself from them
Re: [gentoo-dev] Packages up for grabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 13/06/2011 05:09 ??, Theo Chatzimichos wrote: > On Mon, Jun 13, 2011 at 12:31 PM, Markos Chandras wrote: >> 2) dev-vcs/qsvn >> 3) kde-misc/kcometen4 >> 4) kde-misc/kgrubeditor >> 5) kde-misc/plasmatvgr >> 6) kde-misc/kanyremote >> 8) media-gfx/smile >> 9) media-gfx/pictureflow >> 10) media-sound/qpitch >> 11) media-sound/qtagger >> 12) media-video/avidemux >> 13) net-im/qutim >> 16) x11-misc/touchfreeze >> >> If you plan to pick any of these, please remove me from metadata.xml >> while you are at it. > > The above will still stay at either KDE or Qt, just remove yourself from them > Thank you very much for stepping up and keep an eye on these packages. afaik all of them are bug-free except avidemux that needs a version bump. - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJN9iPdAAoJEPqDWhW0r/LColsP/Ap30D+XxUPYZV5DN6350kOB WN6j/nEzTsHVFPhj6qNoqxOxQbCHu/AxELrj7CA/ZEkaS3Ia7P3Wl2wfqG2Dx0p+ i6fec0Yr+sdn+t80lLHfb76tyedxPw5ryX11B6t2WeMvNHGiAdJFQB1ey1a4uWsq Q2WNgzsCZdh0nMqOCSfkns+O+JnS6SmjEpEcOsozi8BcUSoN61R4QFnpWLE1iz8w Plbu293Pm42oRCTLGurhNyOSdGSkXeVLG9oDOBynx51nSAxD3f8dV6O5ePB64HEH jnwer/JAvnj9o57GPH0QGdNcC3mqirYAG91vm/1hhZSxgkoUXlPVuj36O+IpIGzl Xh6/gbCpq1rlMQzoS5vLzZSngyeRt17hTIJTGzN5TKXEA9Dd+29ZAyNFMaLLwly0 K3an2ppHcgEP2kSjj++okfi3ItiOOIVVFcKBHKPkB+4AJwlgoBepOiQ5JTTAHW8H Ywg1gURX8u8mW/6aplCvg1jT5v/YtSyPGeXb/gqE6jJTiiPWej5KziMqmWPaQ6uV b/VlU1fLOUsTVew6FJuoKRJ38idbTPcch8o1BOzUb6NQCOsND/td4Avxc6pr0/sJ k0pyTgNlbz0jFjJ5mLksan3N1NkwAj5wwOX1gTQNWcveJlD/dVFnUVawkm2NN3HO sHEVupRF12VG0JMu68gF =WwEQ -END PGP SIGNATURE-
Re: [gentoo-dev] Reviving webapp-config
On Monday 13 of June 2011 11:35:08 Patrick Lauer wrote: > On 06/13/11 01:44, Maciej Mrozowski wrote: > > On Friday 10 of June 2011 20:08:00 Ciaran McCreesh wrote: > >> On Thu, 9 Jun 2011 16:37:46 -0500 > >> > >> Matthew Summers wrote: > >>> After consultation and discussion at length with several developers, I > >>> am writing to announce the impending revival of the tool known as > >>> app-admin/webapp-config effective immediately. > >> > >> You might want to chuck it out and start from scratch... > >> > >> Much of the difficulty with the original webapp-config was that it was > >> designed to work on Windows. Stuart's plan was to create a distribution > >> and operating system independent way of dealing with web apps, sort of > >> like CPAN; Gentoo was merely the testbed. If your goals don't match > >> that, you're probably better rethinking everything than trying to revive > >> something that was designed for a completely different purpose. > > > > Also, for pure Gentoo needs it may be better to replace webapp-config > > with package manager and eclasses. > > How does that handle multiple installs etc.? Multiple version installs? Package slotting could be utilized. If multiple instances of the same version - of course it doesn't but nothing prevents you (or eclass - pkg_config() phase) from creating apache config for each virtualhost (for instance) you want particular webapp served. It's not like one really needs to bluntly copy webapp code to deploy it multiple times, usually it's sufficient to fiddle with and . Sometimes patches are needed of course. > > So to install web apps to /usr/share or sth and provide apache config > > files to set up those webapps like Debian does for instance > > ZOMG NOES. > That stuff is horrible, it randomly patches the webserver config > wrongly, then restarts the webserver - so installing nagios knocks out > your apache. Which then makes for some funny debugging ... > > Let's aim higher than that, please, I don't want random misbehaviour :) I forgot the word 'Debian' triggers some unhandled exceptions within your processing queue ;) Seriously, Debian-way of handling web apps isn't bad at all from my experience (I'm not sysadmin however, I just happened to maintain a few web/dev servers), certainly better out-of-the-box experience and better organized than what we have IMHO (save webapp-config). As for httpd service auto restarts - I believe that was never suggested for Gentoo anyway, just "a bit Debian-like" apache config layout - bug 296271. > - so dispatch-conf would be > > > utilized for tracking config file modifications and uninstall via unmerge > > > > One major obstacle is that we have quite a number of web servers to > > support if we're to provide out of the box experience for those web > > apps. > > So provide a default config for, say, apache, and then figure out if > that can be transcribed to others easily. Maybe it can be turned into > simple templates to generate all configs from? -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages up for grabs
On Mon, Jun 13, 2011 at 3:01 PM, Markos Chandras wrote: > 7) media-gfx/simple-scan I'm taking this since it's likely to be integrated with GNOME 3.2 or 3.4 Thanks, -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/qa: index.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11-06-2011 20:48, Mike Frysinger wrote: > On Saturday, June 11, 2011 16:24:00 Ciaran McCreesh wrote: >> On Sat, 11 Jun 2011 15:58:43 -0400 Mike Frysinger wrote: So, effectively the QA team lead can appoint the people who elect him. I'm not at all implying that Diego would abuse his position, but still I think that this is not a sane situation. >>> >>> it does seem trivial to remove people who disagree with you and thus >>> cement an echo chamber >> >> Are you talking in a hypothetical future situation, or has this already >> happened? If so, can you point to an example of where Diego's been >> removing people for disagreeing with him, rather than for disagreeing >> with the Council? > > how is disagreeing with a Council decision valid grounds either ? punting > people because they disagree with any group isn't really valid. > -mike It was not about disagreeing with Council but actively going against an approved policy when the team is responsible for enforcing policies in the tree. This is why in my proposal for the review of GLEP 48 I added a point stating that acting against established policies would constitute ground to be removed from the team. The point about the QA lead having to approve anyone wanting to join the team should be evaluated with the background that the council will surely pay attention to who the QA lead accepts or refuses in the team and that if he acts in an inappropriate manner he may be subject to a devrel bug. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN9piSAAoJEC8ZTXQF1qEPI8MP/3reALc0xY6JXhOQ1mIDiDjh tugb3K7DYxWn4o3g78CBc1EDjZG+WTnoNTvhBC3KnFvdR2jCyuTyoxTgrdiyMCBt Z92klv9fWYwn5IgjRXD3PthG//uen+fpWS5BAvL9PjjeqiR5WOGlfavqbutsAvmy 7zCerkrNgBIzUyvgDBTRMcnftNMwbXu/fOtkVp9m203KjZuvzge606OKBcjiKYbG uZ+Vw2pMfvJ0MycoRdI3a411/RuouISpRlWKoQR6QpFtgago9qf4Gx4MqY1qXaV9 2iY/fBAau1AmVy3IAqFDG1IvBM1QDr9C3wuGqX2nlLQF8V+3BazIputV3sqYhxwd scxJSzJlH+SMnO5+IkyR2Y7WaW9byIQb/pV/weIxfGqEoXmx7kfVSyal55rwLTYF Yd7n0Y8RtHZswYCIxYpZ/kTAlJDl+lpMIJ3lsu9CIIrrc6SgWrQZL4XVEM/CkdVl Oi5VH/6XQrYaVYF53lHPow7LWeRMf/eT/1ZRy164Gsp3x/G1t4GfKYS8egiMSqAy 6TF0Le/tJqBreanwvihVJRas3D27I74//0asIQeu9jgxRnAvaWOvMx5uCFTMfr5k E1rt5Bl7i5qRLs//hA9MPEGa9Tywx5muf9SQ3BH2D8jNlHcOWdDUntylcU1ZTeOA D9Ahs1NzxyQbOzxvTQG9 =QNSu -END PGP SIGNATURE-
[gentoo-dev] Packages that explicitly DEPEND on sys-apps/sed
Judging from [1], a couple of thousands of ebuilds DEPEND on sys-apps/sed, which is a system package (in profiles/base/packages) since at least 2004. It boils down to some 2535 ebuilds, 1409 packages and 14 eclasses, some requiring a version as high as 4.0.5, which went stable in 2003. What do you say. Do we keep them or prune them from the tree? jer [1] http://tinderbox.dev.gentoo.org/misc/dindex/sys-apps/sed
Re: [gentoo-dev] Packages that explicitly DEPEND on sys-apps/sed
On Tue, 14 Jun 2011 05:58:56 +0200 Jeroen Roovers wrote: > Judging from [1], a couple of thousands of ebuilds DEPEND on > sys-apps/sed, which is a system package (in profiles/base/packages) > since at least 2004. It boils down to some 2535 ebuilds, 1409 packages > and 14 eclasses, some requiring a version as high as 4.0.5, which went > stable in 2003. To follow up on that, some 496 ebuilds explicitly DEPEND on sys-apps/sed, with only a few apparently needing 4.1.5 and just the one seemingly requiring 4.2 (though it isn't obvious from the actual sed invocation). I haven't checked which of those RDEPEND on sys-apps/sed too, but it shouldn't be many. That means some two thousand acquire this DEPEND from an eclass, so for the majority of packages, this redundancy could be easily fixed, while the rest of them would probably keep inspiring developers new and old to keep introducing the dep or indeed be insecure about removing it. jer
Re: [gentoo-dev] Packages that explicitly DEPEND on sys-apps/sed
On Tue, Jun 14, 2011 at 06:14:06AM +0200, Jeroen Roovers wrote: > On Tue, 14 Jun 2011 05:58:56 +0200 > Jeroen Roovers wrote: > > > Judging from [1], a couple of thousands of ebuilds DEPEND on > > sys-apps/sed, which is a system package (in profiles/base/packages) > > since at least 2004. It boils down to some 2535 ebuilds, 1409 packages > > and 14 eclasses, some requiring a version as high as 4.0.5, which went > > stable in 2003. Since sys-apps/sed is a system package, I would vote for removing the dependency from the ebuilds/eclasses. William pgpSsg0R1RLJy.pgp Description: PGP signature
Re: [gentoo-dev] Packages that explicitly DEPEND on sys-apps/sed
On 06/13/2011 08:58 PM, Jeroen Roovers wrote: > Judging from [1], a couple of thousands of ebuilds DEPEND on > sys-apps/sed, which is a system package (in profiles/base/packages) > since at least 2004. It boils down to some 2535 ebuilds, 1409 packages > and 14 eclasses, some requiring a version as high as 4.0.5, which went > stable in 2003. > > What do you say. Do we keep them or prune them from the tree? It's worth noting that stage1 and stage2 tarballs do not contain full system sets. Therefore, we can't assume that sys-apps/sed will be included in those stages unless we use something other than the system set to pull it into the stage1. A couple of possible a solutions are: A) Modify $PORTDIR/scripts/bootstrap.sh to ensure that sed is installed in stage1. B) Keep a sys-apps/sed dependency in the sys-apps/portage ebuilds, so that bootstrap.sh will pull sed into stage1 as a dependency of sys-apps/portage. -- Thanks, Zac
