[gentoo-dev] Paper: Normalized source code repositories
Hi folks, some while ago I've already talked a bit about the OSS-QM project and it's source code repositories, which include upstreams together with downstream's (distros, etc) changes. Here's a paper describing it more in datail, from automated upstream imports down to also importing downstream/distro changes automatically. The latter works quite well for recent Debian packages (at least when following their own policies ;-o), as they tell quite exactly which patches have to be applied (and their order). For Gentoo it's more complicated, as I dont know a way to exact that information yet. http://www.metux.de/download/oss-qm/normalized_repository.pdf cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
[gentoo-dev] RFC: fox.eclass update
Hi folks, The fox eclass accumulated a lot of cruft over the years. Specifically, it includes quite a bit of code to support versions loong gone from our tree. The only officially supported versions now are 1.6 and 1.7. Thus, I've edited it a bit. Main points are EAPI2 phase support and a lot of variable quoting. Posting this for review as the diff is rather largish and I'm known to have the usual typo in it ;) Comments welcome. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: fox.eclass update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 16.9.2010 15:31, Matti Bickel napsal(a): > Posting this for review as the diff is rather largish and I'm known to > have the usual typo in it ;) Your mail lacks the attachment :) Tom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkySHgQACgkQHB6c3gNBRYfX/wCfapaZNILD7SQrYfgAZXDGZXA8 +xwAoKex7dx+cm90t+XcEjQmns/AtWb5 =b9z+ -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: fox.eclass update
On 09/16/2010 03:31 PM, Matti Bickel wrote:
--
Now complete with attachments :)
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/fox.eclass,v 1.8 2008/10/12 12:31:36
mabi Exp $
# fox eclass
#
# This eclass allows building SLOT-able FOX Toolkit installations
# (x11-libs/fox: headers, libs, and docs), which are by design
# parallel-installable, while installing only one version of the utils
# (dev-util/reswrap) and apps (app-editors/adie, sci-calculators/calculator,
# x11-misc/pathfinder, and x11-misc/shutterbug).
#
# Version numbering follows the kernel-style odd-even minor version
# designation. Even-number minor versions are API stable, which patch
# releases aimed mostly at the library; apps generally won't need to be
# bumped for a patch release.
#
# Odd-number versions are development branches with their own SLOT and
# are API unstable; changes are made to the apps, and likely need to be
# bumped together with the library.
#
# Here are sample [R]DEPENDs for the fox apps
# 1.6: 'x11-libs/fox:1.6'
# 1.7: '~x11-libs/fox-${PV}'
#
# EAPI phase trickery borrowed from enlightenment.eclass
inherit autotools versionator
FOX_EXPF="src_unpack src_compile src_install pkg_postinst"
case "${EAPI:-0}" in
2|3|4) FOX_EXPF+=" src_prepare src_configure" ;;
*) ;;
esac
EXPORT_FUNCTIONS ${FOX_EXPF}
FOX_PV="${FOX_PV:-${PV}}"
FOXVER=`get_version_component_range 1-2 ${FOX_PV}`
FOX_APPS="adie calculator pathfinder shutterbug"
FOX_CHART="chart"
DESCRIPTION="C++ based Toolkit for developing Graphical User Interfaces easily
and effectively"
HOMEPAGE="http://www.fox-toolkit.org/";
SRC_URI="http://www.fox-toolkit.org/ftp/fox-${FOX_PV}.tar.gz";
IUSE="debug doc profile"
if [ "${PN}" != fox ] ; then
FOX_COMPONENT="${FOX_COMPONENT:-${PN}}"
fi
if [ -z "${FOX_COMPONENT}" ] ; then
DOXYGEN_DEP="doc? ( app-doc/doxygen )"
fi
if [ "${PN}" != reswrap ] ; then
RESWRAP_DEP="dev-util/reswrap"
fi
DEPEND="${DOXYGEN_DEP}
${RESWRAP_DEP}
=sys-devel/automake-1.4*
>=sys-apps/sed-4"
S="${WORKDIR}/fox-${FOX_PV}"
fox_src_unpack() {
unpack ${A}
cd "${S}"
hasq src_prepare ${FOX_EXPF} || fox_src_prepare
}
fox_src_prepare() {
# fox changed from configure.in to configure.am in 1.6.38
local confFile="configure.ac"
[[ -r "configure.in" ]] && confFile="configure.in"
# Respect system CXXFLAGS
sed -i -e 's:CXXFLAGS=""::' $confFile || die "sed ${confFile} error"
# don't build apps from top-level (i.e. x11-libs/fox)
# utils == reswrap
for d in ${FOX_APPS} utils windows ; do
sed -i -e "s:${d}::" Makefile.am || die "sed Makefile.am error"
done
# use the installed reswrap for everything else
for d in ${FOX_APPS} ${FOX_CHART} tests ; do
sed -i -e 's:$(top_builddir)/utils/reswrap:reswrap:' \
${d}/Makefile.am || die "sed ${d}/Makefile.am error"
done
# use the installed headers and library for apps
for d in ${FOX_APPS} ; do
sed -i \
-e "s:-I\$(top_srcdir)/include
-I\$(top_builddir)/include:-I\$(includedir)/fox-${FOXVER}:" \
-e 's:$(top_builddir)/src/libFOX:-lFOX:' \
-e 's:\.la::' \
${d}/Makefile.am || die "sed ${d}/Makefile.am error"
done
eautoreconf
}
fox_src_configure() {
local myconf
use debug && myconf="${myconf} --enable-debug" \
|| myconf="${myconf} --enable-release"
econf \
${FOXCONF} \
${myconf} \
$(use_with profile profiling) \
|| die "configure error"
}
fox_src_compile() {
hasq src_configure ${FOX_EXPF} || fox_src_configure
cd "${S}/${FOX_COMPONENT}"
emake || die "compile error"
# build class reference docs (FOXVER >= 1.2)
if use doc && [ -z "${FOX_COMPONENT}" ] ; then
cd "${S}/doc"
make docs || die "doxygen error"
fi
}
fox_src_install() {
cd "${S}/${FOX_COMPONENT}"
emake install \
DESTDIR="${D}" \
htmldir=/usr/share/doc/${PF}/html \
artdir=/usr/share/doc/${PF}/html/art \
screenshotsdir=/usr/share/doc/${PF}/html/screenshots \
|| die "install error"
# create desktop menu items for apps
case ${FOX_COMPONENT} in
adie)
newicon big_gif.gif adie.gif
make_desktop_entry adie "Adie Text Editor" adie.gif
;;
calculator)
newicon bigcalc.gif foxcalc.gif
make_desktop_entry calculator "FOX Calculator"
foxcalc.gif
Re: [gentoo-dev] RFC: fox.eclass update
On Thu, 16 Sep 2010 16:24:18 +0200, Matti Bickel wrote: > On 09/16/2010 03:31 PM, Matti Bickel wrote: > -- > Now complete with attachments :) Hey Matti, few quick things. * Can you add eclass-manpages documentation? * econf doesn't need to "|| die" * What is the mysterious FOXCONF variable in econf for? (could just be documented? or removed?)
Re: [gentoo-dev] Paper: Normalized source code repositories
On Thu, 16 Sep 2010 09:47:57 +0200 Enrico Weigelt wrote: > > Hi folks, More spam? jer
Re: [gentoo-dev] RFC: fox.eclass update
On Thu, 16 Sep 2010 09:41:30 -0500 Jeremy Olexa wrote: > * econf doesn't need to "|| die" Is that a novelty change? Most of the tree still does econf || die ... jer
Re: [gentoo-dev] RFC: fox.eclass update
On 09/16/2010 04:41 PM, Jeremy Olexa wrote:
> Hey Matti, few quick things.
Thanks, all done. FOXCONF is now documented (though not set by default).
Updated diff and eclass attached.
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: fox.eclass
# @MAINTAINER:
# m...@gentoo.org
# @BLURB: Functionality required the FOX Toolkit and it's applications
# @DESCRIPTION:
# This eclass allows building SLOT-able FOX Toolkit installations
# (x11-libs/fox: headers, libs, and docs), which are by design
# parallel-installable, while installing only one version of the utils
# (dev-util/reswrap) and apps (app-editors/adie, sci-calculators/calculator,
# x11-misc/pathfinder, and x11-misc/shutterbug).
#
# Version numbering follows the kernel-style odd-even minor version
# designation. Even-number minor versions are API stable, which patch
# releases aimed mostly at the library; apps generally won't need to be
# bumped for a patch release.
#
# Odd-number versions are development branches with their own SLOT and
# are API unstable; changes are made to the apps, and likely need to be
# bumped together with the library.
#
# Here are sample [R]DEPENDs for the fox apps
# 1.6: 'x11-libs/fox:1.6'
# 1.7: '~x11-libs/fox-${PV}'
#
# EAPI phase trickery borrowed from enlightenment.eclass
inherit autotools versionator
FOX_EXPF="src_unpack src_compile src_install pkg_postinst"
case "${EAPI:-0}" in
2|3|4) FOX_EXPF+=" src_prepare src_configure" ;;
*) ;;
esac
EXPORT_FUNCTIONS ${FOX_EXPF}
# @ECLASS-VARIABLE: FOX_PV
# @DESCRIPTION:
# The version of the FOX Toolkit provided or required by the package
FOX_PV="${FOX_PV:-${PV}}"
# @ECLASS-VARIABLE: FOXVER
# @INTERNAL
# @DESCRIPTION:
# The major.minor version of FOX_PV, usually acts as $SLOT and is used in
# building the applications
FOXVER=`get_version_component_range 1-2 ${FOX_PV}`
# @ECLASS-VARIABLE: FOX_APPS
# @INTERNAL
# @DESCRIPTION:
# The applications originally packaged in the FOX Toolkit
FOX_APPS="adie calculator pathfinder shutterbug"
FOX_CHART="chart"
# @ECLASS-VARIABLE: FOXCONF
# @DEFAULT_UNSET
# @DESCRIPTION:
# Set this to add additional configuration options during src_configure
DESCRIPTION="C++ based Toolkit for developing Graphical User Interfaces easily
and effectively"
HOMEPAGE="http://www.fox-toolkit.org/";
SRC_URI="http://www.fox-toolkit.org/ftp/fox-${FOX_PV}.tar.gz";
IUSE="debug doc profile"
if [ "${PN}" != fox ] ; then
FOX_COMPONENT="${FOX_COMPONENT:-${PN}}"
fi
if [ -z "${FOX_COMPONENT}" ] ; then
DOXYGEN_DEP="doc? ( app-doc/doxygen )"
fi
if [ "${PN}" != reswrap ] ; then
RESWRAP_DEP="dev-util/reswrap"
fi
DEPEND="${DOXYGEN_DEP}
${RESWRAP_DEP}
=sys-devel/automake-1.4*
>=sys-apps/sed-4"
S="${WORKDIR}/fox-${FOX_PV}"
fox_src_unpack() {
unpack ${A}
cd "${S}"
hasq src_prepare ${FOX_EXPF} || fox_src_prepare
}
fox_src_prepare() {
# fox changed from configure.in to configure.am in 1.6.38
local confFile="configure.ac"
[[ -r "configure.in" ]] && confFile="configure.in"
# Respect system CXXFLAGS
sed -i -e 's:CXXFLAGS=""::' $confFile || die "sed ${confFile} error"
# don't build apps from top-level (i.e. x11-libs/fox)
# utils == reswrap
for d in ${FOX_APPS} utils windows ; do
sed -i -e "s:${d}::" Makefile.am || die "sed Makefile.am error"
done
# use the installed reswrap for everything else
for d in ${FOX_APPS} ${FOX_CHART} tests ; do
sed -i -e 's:$(top_builddir)/utils/reswrap:reswrap:' \
${d}/Makefile.am || die "sed ${d}/Makefile.am error"
done
# use the installed headers and library for apps
for d in ${FOX_APPS} ; do
sed -i \
-e "s:-I\$(top_srcdir)/include
-I\$(top_builddir)/include:-I\$(includedir)/fox-${FOXVER}:" \
-e 's:$(top_builddir)/src/libFOX:-lFOX:' \
-e 's:\.la::' \
${d}/Makefile.am || die "sed ${d}/Makefile.am error"
done
eautoreconf
}
fox_src_configure() {
use debug && FOXCONF+=" --enable-debug" \
|| FOXCONF+=" --enable-release"
econf ${FOXCONF} \
$(use_with profile profiling)
}
fox_src_compile() {
hasq src_configure ${FOX_EXPF} || fox_src_configure
cd "${S}/${FOX_COMPONENT}"
emake || die "compile error"
# build class reference docs (FOXVER >= 1.2)
if use doc && [ -z "${FOX_COMPONENT}" ] ; then
cd "${S}/doc"
make docs || die "doxygen error"
fi
}
fox_src_install() {
cd "${S}/${FOX_COMPONENT}"
emake install \
DESTDIR="${D}" \
htmldir=/usr/share/doc/${PF}/html \
artdir=/usr/share/doc/${PF}/html/a
Re: [gentoo-dev] RFC: fox.eclass update
On Thu, 16 Sep 2010 17:44:00 +0200, Jeroen Roovers wrote: > On Thu, 16 Sep 2010 09:41:30 -0500 > Jeremy Olexa wrote: > >> * econf doesn't need to "|| die" > > Is that a novelty change? Most of the tree still does econf || die ... It is just extra (not needed) code. econf() has died by itself since BEFORE 2005. git blame shows this commit: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;f=bin/ebuild.sh;h=d9fc4acc572c6647a4f27b838d35d27d805d190e which is a migration commit into svn from cvs (without history) in 2005. So novelty or not, whatever, not needed. :) (Besides the numerous threads about 'which helpers die by themself and not' - its easy to read the code, esp bash) -Jeremy
Re: [gentoo-dev] RFC: fox.eclass update
В Чтв, 16/09/2010 в 17:44 +0200, Jeroen Roovers пишет: > On Thu, 16 Sep 2010 09:41:30 -0500 > Jeremy Olexa wrote: > > > * econf doesn't need to "|| die" > > Is that a novelty change? Most of the tree still does econf || die ... econf is function that dies on its own. But still there is one case where || die after econf can be useful - very-very long list of econf options you have to edit rather frequently. econf \ parameter1 \ parameter2 \ ... \ parameterN || die In case || die is absent and developer forgot '\' at the end of line portage will not abort build: econf with shortened list of options will succeed and next most probably absent command `parameterk parameter$((k +1)) ... parameterN` will have no || die at the end. In general case || die after econf is redundant and should be dropped. -- Peter.
Re: [gentoo-dev] RFC: fox.eclass update
В Чтв, 16/09/2010 в 16:24 +0200, Matti Bickel пишет:
> +FOXVER=`get_version_component_range 1-2 ${FOX_PV}`
It's better to prefer $() style over ``:
http://mywiki.wooledge.org/BashFAQ/082
> if [ "${PN}" != fox ] ; then
> FOX_COMPONENT="${FOX_COMPONENT:-${PN}}"
> fi
>
> -if [ "${FOXVER}" != "1.0" ] && [ -z "${FOX_COMPONENT}" ] ; then
> +if [ -z "${FOX_COMPONENT}" ] ; then
> DOXYGEN_DEP="doc? ( app-doc/doxygen )"
> fi
It's better to use [[ ]] and avoid quotes since ebuilds are bash
scripts.
> - elibtoolize
> + eautoreconf
Hm, is this change necessary?
> + if ( ! use doc ) && [ -d "${D}/usr/share/doc/${PF}/html" ] ;
> then
Subshell looks redundant here.
> + epause
It's better to avoid epause as it makes build slower at the same time
it's most probable that nobody is looking on the screen at the moment[1]
and portage will print all elog messages at the end of the build in any
case.
[1] while emerge output is one of those things one can observe for ages
(like water, fire and others working) still it's possible no one
thoughtfully staring at the screen...
--
Peter.
Re: [gentoo-dev] RFC: fox.eclass update
On 09/16/2010 08:32 PM, Peter Volkov wrote:
> В Чтв, 16/09/2010 в 16:24 +0200, Matti Bickel пишет:
>> +FOXVER=`get_version_component_range 1-2 ${FOX_PV}`
>
> It's better to prefer $() style over ``:
> http://mywiki.wooledge.org/BashFAQ/082
Hmm, I prefer Backticks personally, as I like to conserve space whenever
possible. But for consistency with the rest of the tree, I changed that
to $() in the diff.
>> - elibtoolize
>> + eautoreconf
>
> Hm, is this change necessary?
I might be missing something here, but the change in recent fox versions
to configure.ac instead of configure.in forces a run of autoconf, afaik.
Thanks for the comments, updated eclass attached.
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: fox.eclass
# @MAINTAINER:
# m...@gentoo.org
# @BLURB: Functionality required the FOX Toolkit and it's applications
# @DESCRIPTION:
# This eclass allows building SLOT-able FOX Toolkit installations
# (x11-libs/fox: headers, libs, and docs), which are by design
# parallel-installable, while installing only one version of the utils
# (dev-util/reswrap) and apps (app-editors/adie, sci-calculators/calculator,
# x11-misc/pathfinder, and x11-misc/shutterbug).
#
# Version numbering follows the kernel-style odd-even minor version
# designation. Even-number minor versions are API stable, which patch
# releases aimed mostly at the library; apps generally won't need to be
# bumped for a patch release.
#
# Odd-number versions are development branches with their own SLOT and
# are API unstable; changes are made to the apps, and likely need to be
# bumped together with the library.
#
# Here are sample [R]DEPENDs for the fox apps
# 1.6: 'x11-libs/fox:1.6'
# 1.7: '~x11-libs/fox-${PV}'
#
# EAPI phase trickery borrowed from enlightenment.eclass
inherit autotools versionator
FOX_EXPF="src_unpack src_compile src_install pkg_postinst"
case "${EAPI:-0}" in
2|3|4) FOX_EXPF+=" src_prepare src_configure" ;;
*) ;;
esac
EXPORT_FUNCTIONS ${FOX_EXPF}
# @ECLASS-VARIABLE: FOX_PV
# @DESCRIPTION:
# The version of the FOX Toolkit provided or required by the package
FOX_PV="${FOX_PV:-${PV}}"
# @ECLASS-VARIABLE: FOXVER
# @INTERNAL
# @DESCRIPTION:
# The major.minor version of FOX_PV, usually acts as $SLOT and is used in
# building the applications
FOXVER=$(get_version_component_range 1-2 ${FOX_PV})
# @ECLASS-VARIABLE: FOX_APPS
# @INTERNAL
# @DESCRIPTION:
# The applications originally packaged in the FOX Toolkit
FOX_APPS="adie calculator pathfinder shutterbug"
FOX_CHART="chart"
# @ECLASS-VARIABLE: FOXCONF
# @DEFAULT_UNSET
# @DESCRIPTION:
# Set this to add additional configuration options during src_configure
DESCRIPTION="C++ based Toolkit for developing Graphical User Interfaces easily
and effectively"
HOMEPAGE="http://www.fox-toolkit.org/";
SRC_URI="http://www.fox-toolkit.org/ftp/fox-${FOX_PV}.tar.gz";
IUSE="debug doc profile"
if [[ ${PN} != fox ]] ; then
FOX_COMPONENT="${FOX_COMPONENT:-${PN}}"
fi
if [[ -z ${FOX_COMPONENT} ]] ; then
DOXYGEN_DEP="doc? ( app-doc/doxygen )"
fi
if [[ ${PN} != reswrap ]] ; then
RESWRAP_DEP="dev-util/reswrap"
fi
DEPEND="${DOXYGEN_DEP}
${RESWRAP_DEP}
=sys-devel/automake-1.4*
>=sys-apps/sed-4"
S="${WORKDIR}/fox-${FOX_PV}"
fox_src_unpack() {
unpack ${A}
cd "${S}"
hasq src_prepare ${FOX_EXPF} || fox_src_prepare
}
fox_src_prepare() {
# fox changed from configure.in to configure.am in 1.6.38
local confFile="configure.ac"
[[ -r "configure.in" ]] && confFile="configure.in"
# Respect system CXXFLAGS
sed -i -e 's:CXXFLAGS=""::' $confFile || die "sed ${confFile} error"
# don't build apps from top-level (i.e. x11-libs/fox)
# utils == reswrap
for d in ${FOX_APPS} utils windows ; do
sed -i -e "s:${d}::" Makefile.am || die "sed Makefile.am error"
done
# use the installed reswrap for everything else
for d in ${FOX_APPS} ${FOX_CHART} tests ; do
sed -i -e 's:$(top_builddir)/utils/reswrap:reswrap:' \
${d}/Makefile.am || die "sed ${d}/Makefile.am error"
done
# use the installed headers and library for apps
for d in ${FOX_APPS} ; do
sed -i \
-e "s:-I\$(top_srcdir)/include
-I\$(top_builddir)/include:-I\$(includedir)/fox-${FOXVER}:" \
-e 's:$(top_builddir)/src/libFOX:-lFOX:' \
-e 's:\.la::' \
${d}/Makefile.am || die "sed ${d}/Makefile.am error"
done
eautoreconf
}
fox_src_configure() {
use debug && FOXCONF+=" --enable-debug" \
|| FOXCONF+=" --enable-release"
econf ${FOXCONF} \
$(use_with profile profiling)
}
fox_src_compile() {
hasq src_configure ${FOX_EXPF} || fox
Re: [gentoo-dev] RFC: fox.eclass update
On Thursday, September 16, 2010 14:51:39 Matti Bickel wrote:
> +#1.6: 'x11-libs/fox:1.6'
> +# 1.7: '~x11-libs/fox-${PV}'
first line is using a tab while second is spaces. both should be tabs.
> FOX_PV="${FOX_PV:-${PV}}"
while you're here, i'd change to:
: ${FOX_PV:=${PV}}
> for d in ${FOX_APPS} ; do
your prepare func should declare 'd' as local
> + if use doc && [[ -z ${FOX_COMPONENT} ]] ; then
> + cd "${S}/doc"
> make docs || die "doxygen error"
> fi
should be `emake`, and better to use -C "${S}"/doc so that you dont change
$PWD on people
> + if ! use doc && [[ -d ${D}/usr/share/doc/${PF}/html ]] ; then
> + rm -fr "${D}/usr/share/doc/${PF}/html"
> fi
you dont really need the -d check as the -f option to rm will keep it from
warning on missing dirs
use doc || rm -rf "${D}"/usr/share/doc/${PF}/html
> + if [[ -f ${D}/usr/bin/fox-config ]] ; then
> + mv "${D}/usr/bin/fox-config" "${D}/usr/bin/fox-${FOXVER}-config"
> fi
seems like you would want || die here
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: fox.eclass update
В Чтв, 16/09/2010 в 15:29 -0400, Mike Frysinger пишет:
>
> > FOX_PV="${FOX_PV:-${PV}}"
>
> while you're here, i'd change to:
> : ${FOX_PV:=${PV}}
Why? This looks less readable...
--
Peter.
Re: [gentoo-dev] RFC: fox.eclass update
On 09/16/2010 09:29 PM, Mike Frysinger wrote:
>> +if [[ -f ${D}/usr/bin/fox-config ]] ; then
>> +mv "${D}/usr/bin/fox-config" "${D}/usr/bin/fox-${FOXVER}-config"
>> fi
>
> seems like you would want || die here
Why? I can't imagine how that could fail.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [RFC] Handling of test USE flag in ebuilds
Am 16.09.2010 03:46, schrieb Ryan Hill: > On Wed, 15 Sep 2010 19:02:00 +0200 > Thomas Sachau wrote: > >> From discussion on IRC, it seems, like there are different options, so i >> would like to clarify this >> policy: >> >> The test USE flag is (i am only talking about portage now, since i am most >> familar with it) an >> internal flag, which is added by portage for every ebuild and >> enabled/disabled based on >> FEATURES=test or not. It is not managed via USE= line in make.conf or >> package.use settings. So in >> handling and setting, it is pretty much the same as for the arch USE flags, >> which are also only >> internally used and added, but never exposed to the users. >> Now i see the opinion, that it should always be added to IUSE, when it is >> referenced in the ebuild. >> This adds it to the visible USE flags in emerge output (imho pointless, >> since it is no option, which >> can be enabled/disabled like the other USE flags), but otherwise does change >> nothing. >> >> Because of this, i would like to discourage the addition of test USE flag to >> IUSE, since it is just >> an internal USE flag, which should not be exposed to the user. > > Well, it does indicate the presence of optional dependencies. > > I've always thought the test USE flag being forced by FEATURES=test was > messed up. Why can't it be controlled package-by-package, with FEATURES=test > just enabling USE=test by default? > > Controling the test USE flag alone without the test FEATURE is useless, since it wont run the src_test phase. And being able to disable the test USE flag with FEATURES=test will result in missing deps or build-system args. Can you tell me any reason, why you want to expose and control the test USE flag independently of FEATURES=test? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Handling of test USE flag in ebuilds
Am 16.09.2010 04:01, schrieb Samuli Suominen: > On 09/15/2010 08:02 PM, Thomas Sachau wrote: >> From discussion on IRC, it seems, like there are different options, so i >> would like to clarify this >> policy: >> >> The test USE flag is (i am only talking about portage now, since i am most >> familar with it) an >> internal flag, which is added by portage for every ebuild and >> enabled/disabled based on >> FEATURES=test or not. It is not managed via USE= line in make.conf or >> package.use settings. So in >> handling and setting, it is pretty much the same as for the arch USE flags, >> which are also only >> internally used and added, but never exposed to the users. >> Now i see the opinion, that it should always be added to IUSE, when it is >> referenced in the ebuild. >> This adds it to the visible USE flags in emerge output (imho pointless, >> since it is no option, which >> can be enabled/disabled like the other USE flags), but otherwise does change >> nothing. >> >> Because of this, i would like to discourage the addition of test USE flag to >> IUSE, since it is just >> an internal USE flag, which should not be exposed to the user. > > Of course it should be exposed to user, it makes reading deptree a lot > easier and helps resolving e.g. circular dependencies by temporarily > disabling the flag for say, random dev-perl package. Which deptree are you talking about? The --tree output of portage does not show you any USE flag conditionals. Additionally, if you disable the flag with FEATURES=test enabled, test phases will fail, so those packages will fail to install, i dont think, that this is the better option. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] About wormo's situation?
Hello I have seen some package metadatas still referring to wormo as their maintainer: $ grep -r wormo */*/metada* app-admin/ulogd/metadata.xml: wo...@gentoo.org app-arch/pdv/metadata.xml: wo...@gentoo.org www-client/lynx/metadata.xml: wo...@gentoo.org But, reading http://bugs.gentoo.org/show_bug.cgi?id=72682 looks like she retired some time ago. What is her real situation? Should that packages be moved to maintainer-needed (if nobody cares about them)? Please note that this problem appeared because a user mailed us about some unresolved problem with ulogd since a lot of time. Thanks a lot for clarifying this :-) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About wormo's situation?
On Thu, 16 Sep 2010 23:12:10 +0200, Pacho Ramos wrote: > Hello > > I have seen some package metadatas still referring to wormo as their > maintainer: > $ grep -r wormo */*/metada* > app-admin/ulogd/metadata.xml: wo...@gentoo.org > app-arch/pdv/metadata.xml: wo...@gentoo.org > www-client/lynx/metadata.xml: wo...@gentoo.org > > > But, reading http://bugs.gentoo.org/show_bug.cgi?id=72682 looks like she > retired some time ago. What is her real situation? Should that packages > be moved to maintainer-needed (if nobody cares about them)? > > Please note that this problem appeared because a user mailed us about > some unresolved problem with ulogd since a lot of time. > > Thanks a lot for clarifying this :-) Quote from bug: "..increase her activity by proxy-maintaining some packages" and http://bugs.gentoo.org/custom_userhistory.cgi?matchstr=wo...@gentoo.org shows recent activity. So, I don't know..have you tried contacting her via direct email? :) Otherwise if there is no action on bugs, I'd wager that it is 'ok' for you to fix - especially if you communicate and willing to fix what you break. -Jeremy
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-zope/zope-dublincore: ChangeLog zope-dublincore-3.8.0.ebuild
Il giorno gio, 16/09/2010 alle 21.47 +, Arfrever Frehtes Taifersar Arahesis (arfrever) ha scritto: > - -zope-dublincore-3.6.3.ebuild: > - Delete. > + -zope-dublincore-3.6.3.ebuild, +zope-dublincore-3.8.0.ebuild: > + Version bump. If you remove the "Delete" from the ChangeLog with the following commit you can as well not add it in the first place. Can't you just write "Version bump and cleanup"? -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: fox.eclass update
On Thursday, September 16, 2010 16:24:14 Matti Bickel wrote:
> On 09/16/2010 09:29 PM, Mike Frysinger wrote:
> >> + if [[ -f ${D}/usr/bin/fox-config ]] ; then
> >> + mv "${D}/usr/bin/fox-config" "${D}/usr/bin/fox-${FOXVER}-config"
> >>
> >>fi
> >
> > seems like you would want || die here
>
> Why? I can't imagine how that could fail.
then the `die` should never be called
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: fox.eclass update
On Thursday, September 16, 2010 15:41:27 Peter Volkov wrote:
> В Чтв, 16/09/2010 в 15:29 -0400, Mike Frysinger пишет:
> > > FOX_PV="${FOX_PV:-${PV}}"
> >
> > while you're here, i'd change to:
> > : ${FOX_PV:=${PV}}
>
> Why? This looks less readable...
only because your eyes arent tuned to it
-mike
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-zope/zope-dublincore: ChangeLog zope-dublincore-3.8.0.ebuild
2010-09-16 23:50:44 Diego Elio Pettenò napisał(a): > Il giorno gio, 16/09/2010 alle 21.47 +, Arfrever Frehtes Taifersar > Arahesis (arfrever) ha scritto: > > - -zope-dublincore-3.6.3.ebuild: > > - Delete. > > + -zope-dublincore-3.6.3.ebuild, +zope-dublincore-3.8.0.ebuild: > > + Version bump. > > If you remove the "Delete" from the ChangeLog with the following commit > you can as well not add it in the first place. Some people were against delaying of describing of changes to later commits. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [RFC] Handling of test USE flag in ebuilds
On Thu, 16 Sep 2010 22:42:02 +0200 Thomas Sachau wrote: > Controling the test USE flag alone without the test FEATURE is useless, since > it wont run the > src_test phase. ...then don't do that? :P > And being able to disable the test USE flag with FEATURES=test will result in > missing deps or build-system args. Add something like this to the beginning of the default src_test: hasq test $USE || return 0 I'm sure there's a reason it won't work I'm not thinking of, but that's the jist of the idea. > Can you tell me any reason, why you want to expose and control > the test USE flag independently of FEATURES=test? So it can be controlled on a per-package basis? Circular dependencies, unwanted dependencies, excessive testsuites, perpetually failing testsuites that no one bothers to fix... You can mask the flag but it's inconsistant and unintuitive. FWIW I currently have 22 packages that have the test flag masked in package.use.mask, and probably a dozen more I just haven't gotten around to masking. In any case, this is straying off topic. I believe the current policy is this: if your package's test suite requires extra dependencies, add a test USE flag and make them conditional on that. I don't think there's any reason it should change. -- fonts, gcc-porting, we hold our breath, we spin around the world toolchain, wxwidgetsyou and me cling to the outside of the earth @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: fox.eclass update
On Thu, 16 Sep 2010 18:34:17 -0400
Mike Frysinger wrote:
> On Thursday, September 16, 2010 15:41:27 Peter Volkov wrote:
> > В Чтв, 16/09/2010 в 15:29 -0400, Mike Frysinger пишет:
> > > > FOX_PV="${FOX_PV:-${PV}}"
> > >
> > > while you're here, i'd change to:
> > > : ${FOX_PV:=${PV}}
> >
> > Why? This looks less readable...
>
> only because your eyes arent tuned to it
What exactly is the advantage though? Is it something to do with command vs
assignment?
--
fonts, gcc-porting, we hold our breath, we spin around the world
toolchain, wxwidgetsyou and me cling to the outside of the earth
@ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: RFC: fox.eclass update
On Thursday, September 16, 2010 23:51:21 Ryan Hill wrote:
> On Thu, 16 Sep 2010 18:34:17 -0400 Mike Frysinger wrote:
> > On Thursday, September 16, 2010 15:41:27 Peter Volkov wrote:
> > > В Чтв, 16/09/2010 в 15:29 -0400, Mike Frysinger пишет:
> > > > > FOX_PV="${FOX_PV:-${PV}}"
> > > >
> > > > while you're here, i'd change to:
> > > > : ${FOX_PV:=${PV}}
> > >
> > > Why? This looks less readable...
> >
> > only because your eyes arent tuned to it
>
> What exactly is the advantage though? Is it something to do with command
> vs assignment?
i guess if you like typing the same variable name twice, then the old style is
for you. i do not like.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: fox.eclass update
В Чтв, 16/09/2010 в 18:34 -0400, Mike Frysinger пишет:
> On Thursday, September 16, 2010 15:41:27 Peter Volkov wrote:
> > В Чтв, 16/09/2010 в 15:29 -0400, Mike Frysinger пишет:
> > > > FOX_PV="${FOX_PV:-${PV}}"
> > >
> > > while you're here, i'd change to:
> > > : ${FOX_PV:=${PV}}
> >
> > Why? This looks less readable...
>
> only because your eyes arent tuned to it
Instead of explicit variable assignment (what was intended) you suggest
to call `:` command and implicitly assign variable with bash parameter
expansion...
--
Peter.
Re: [gentoo-dev] RFC: fox.eclass update
On Friday, September 17, 2010 01:06:19 Peter Volkov wrote:
> В Чтв, 16/09/2010 в 18:34 -0400, Mike Frysinger пишет:
> > On Thursday, September 16, 2010 15:41:27 Peter Volkov wrote:
> > > В Чтв, 16/09/2010 в 15:29 -0400, Mike Frysinger пишет:
> > > > > FOX_PV="${FOX_PV:-${PV}}"
> > > >
> > > > while you're here, i'd change to:
> > > > : ${FOX_PV:=${PV}}
> > >
> > > Why? This looks less readable...
> >
> > only because your eyes arent tuned to it
>
> Instead of explicit variable assignment (what was intended) you suggest
> to call `:` command and implicitly assign variable with bash parameter
> expansion...
what exactly is your point ? there is no performance difference. my style
suggestion however is significantly more compact and has no redundancy.
-mike
signature.asc
Description: This is a digitally signed message part.
