[gentoo-dev] BOINC needs maintainer
Hi, currently BOINC supposed to be maintained by the science team, but we are not really carrying about it. Is there anyone around whole likes to take this over? Thanks for your help, Justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: intel-sdp-r1.eclass
On 15/02/16 15:35, Michał Górny wrote:
> On Mon, 15 Feb 2016 14:37:41 +0100
> "Justin Lecher (jlec)" wrote:
>
>> On 15/02/16 13:59, Michał Górny wrote:
>>> On Mon, 15 Feb 2016 09:16:53 +0100
>>> "Justin Lecher (jlec)" wrote:
>>>
>>>> # @ECLASS-VARIABLE: INTEL_SUBDIR
>>>> # @DEFAULT_UNSET
>>>> # @DESCRIPTION:
>>>> # The package sub-directory where it will end-up in /opt/intel
>>>> # To find out its value, you have to do a raw install from the Intel tar
>>>> ball
>>>
>>> To be honest, I find this kinda terrible. There's a huge block of docs
>>> which makes me feel small and confused. Maybe it'd useful to give some
>>> semi-complete example on top (in global doc)?
>>
>> That makes definitely make sense. We will add one.
>>
>> Although nobody other then the maintainer of this eclass will ever use it.
>
> Remember that maintainers can change. It's better to have good then
> have new maintainers figure out all stuff over again.
>
>>>> # e.g. CLI_install/rpm/intel-vtune-amplifier-xe-cli
>>>> : ${INTEL_BIN_RPMS:=()}
>>>
>>> $ : ${foo:=()}
>>> $ declare -p foo
>>> declare -- foo="()"
>>>
>>> In other words, it doesn't work the way you expect it to.
>>
>> I already wondered about this. Is there any way to force a variable to
>> be an array in bash? Or define it as an empty array?
>
> Look at e.g. python-utils-r1.
>
> To check for array:
>
> if [[ $(declare -p foo) != "declare -a"* ]]; then
> ...
> fi
>
> To default to empty, simple (yet a bit imperfect) way:
>
> [[ ${foo[@]} }] || foo=()
And what about the default assignment for the man page?
>
>>>> # @ECLASS-VARIABLE: INTEL_SINGLE_ARCH
>>>> # @DESCRIPTION:
>>>> # Unset, if only the multilib package will be provided by intel
>>>> : ${INTEL_SINGLE_ARCH:=true}
>>>
>>> This is really weird. It sounds like I'm supposed to do:
>>>
>>> inherit intel-sdp-r1
>>> unset INTEL_SINGLE_ARCH
>>>
>>> I suggest you used positive logic instead.
>>
>> The wording is wrong. Setting it to anything but "true" like
>> "INTEL_SINGLE_ARCH=false" works. We will fix the wording.
>
> I still think positive logic is better. That is, a variable which
> defaults to, say, unset, and changes behavior if it becomes set to
> non-empty value.
we will look into that.
>
>>>> _isdp_big-warning() {
>>>>debug-print-function ${FUNCNAME} "${@}"
>>>>
>>>>case ${1} in
>>>>pre-check )
>>>>echo ""
>>>
>>> Don't mix echo with ewarn.
>>
>> Why?
>
> Because they won't go through the same output channels.
>
>>>>
>>>> comp_full="${ED}/${INTEL_SDP_DIR}/linux/bin/${arch}/${comp}"
>>>
>>> Double slash imminent (ED has one).
>>
>> Always? Per definition?
>
> Yes, sadly. i wanted to change this but it's unlikely to go since it
> makes EAPI migration hard. If you really want to cover both cases, you
> can always do ${foo%/}/bar.
>
>>>> # @CODE
>>>
>>> Err, this is not code, you know.
>>
>> This is needed for nice formatting. Otherwise there is no line break
>
> Add an empty line between the two. That should do it correctly, without
> code blocks in devmanual.
That will introduce an empty line between the two points.
>
>>>>#maybe use nullglob or [[ $(echo ${dir/*lic) !=
>>>> "${dir}/*lic" ]]
>>>>[[ $( ls "${dir}"/*lic 2>/dev/null ) ]]; ret=$?
>>>
>>> Maybe you should use something sane indeed.
>
> Maybe file_exists from eutils could help here btw.
>
>>> Wouldn't you be able to collapse that into one loop?
>>
>> no, because the first has ${INTEL_X86}.rpm as suffeix and the later has
>> ${INTEL_X86}.rpm.
>
> Er... am I reading wrong, or did you just type the same thing twice?
right, it should be ${INTEL_X86}.rpm vs noarch.rpm
>
>>>>einfo "Unpacking ${rb}"
>>>>rpm2tar -O ${r} | tar xvf - | sed -e \
>>>>"s:^\.:${EROOT#/}:g" > /dev/null; assert
>>>> "unpackin
Re: [gentoo-dev] RFC: intel-sdp-r1.eclass
On 15/02/16 13:59, Michał Górny wrote:
> On Mon, 15 Feb 2016 09:16:53 +0100
> "Justin Lecher (jlec)" wrote:
>
>> # Copyright 1999-2016 Gentoo Foundation
>> # Distributed under the terms of the GNU General Public License v2
>> # $Id$
>>
>> # @ECLASS: intel-sdp-r1.eclass
>> # @MAINTAINER:
>> # Justin Lecher
>> # David Seifert
>> # Sci Team
>> # @BLURB: Handling of Intel's Software Development Products package
>> management
>>
>> if [[ ! ${_INTEL_SDP_R1_ECLASS_} ]]; then
>>
>> case "${EAPI:-0}" in
>
> :-0 is meaningless here.
>
>> 6) ;;
>> *) die "EAPI=${EAPI} is not supported" ;;
>
> If at all, it could be helpful here.
We had that before, will fix it.
>
>> esac
>>
>> # @ECLASS-VARIABLE: INTEL_DID
>> # @DEFAULT_UNSET
>> # @DESCRIPTION:
>> # The package download ID from Intel.
>> # To find out its value, see the links to download in
>> # https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
>> #
>> # e.g. 8365
>> #
>> # Must be defined before inheriting the eclass
>>
>> # @ECLASS-VARIABLE: INTEL_DPN
>> # @DEFAULT_UNSET
>> # @DESCRIPTION:
>> # The package name to download from Intel.
>> # To find out its value, see the links to download in
>> # https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
>> #
>> # e.g. parallel_studio_xe
>> #
>> # Must be defined before inheriting the eclass
>>
>> # @ECLASS-VARIABLE: INTEL_DPV
>> # @DEFAULT_UNSET
>> # @DESCRIPTION:
>> # The package download version from Intel.
>> # To find out its value, see the links to download in
>> # https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
>> #
>> # e.g. 2016_update1
>> #
>> # Must be defined before inheriting the eclass
>>
>> # @ECLASS-VARIABLE: INTEL_TARX
>> # @DESCRIPTION:
>> # The package extention.
>
> Extension. Or if you're not on Windows, then 'suffix'.
Fair enough.
>
>> # To find out its value, see the links to download in
>> # https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
>> #
>> # e.g. tar.gz
>> #
>> # Must be defined before inheriting the eclass
>> : ${INTEL_TARX:=tgz}
>>
>> # @ECLASS-VARIABLE: INTEL_SUBDIR
>> # @DEFAULT_UNSET
>> # @DESCRIPTION:
>> # The package sub-directory where it will end-up in /opt/intel
>> # To find out its value, you have to do a raw install from the Intel tar ball
>
> To be honest, I find this kinda terrible. There's a huge block of docs
> which makes me feel small and confused. Maybe it'd useful to give some
> semi-complete example on top (in global doc)?
That makes definitely make sense. We will add one.
Although nobody other then the maintainer of this eclass will ever use it.
>
>> # @ECLASS-VARIABLE: INTEL_SKIP_LICENSE
>> # @DEFAULT_UNSET
>> # @DESCRIPTION:
>> # Possibility to skip the mandatory check for licenses. Only set this if
>> there
>> # is really no fix.
>>
>> # @ECLASS-VARIABLE: INTEL_RPMS_DIR
>> # @DESCRIPTION:
>> # Main subdirectory which contains the rpms to extract.
>> : ${INTEL_RPMS_DIR:=rpm}
>>
>> # @ECLASS-VARIABLE: INTEL_X86
>> # @DESCRIPTION:
>> # 32bit arch in rpm names
>> #
>> # e.g. i486
>> : ${INTEL_X86:=i486}
>>
>> # @ECLASS-VARIABLE: INTEL_BIN_RPMS
>> # @DESCRIPTION:
>> # Functional name of rpm without any version/arch tag
>> # Has to be a bash array
>> #
>> # e.g. ("icc-l-all-devel")
>> #
>> # if the rpm is located in a directory other than INTEL_RPMS_DIR you can
>> # specify the full path
>> #
>> # e.g. CLI_install/rpm/intel-vtune-amplifier-xe-cli
>> : ${INTEL_BIN_RPMS:=()}
>
> $ : ${foo:=()}
> $ declare -p foo
> declare -- foo="()"
>
> In other words, it doesn't work the way you expect it to.
I already wondered about this. Is there any way to force a variable to
be an array in bash? Or define it as an empty array?
>
>> # @ECLASS-VARIABLE: INTEL_AMD64_RPMS
>> # @DESCRIPTION:
>> # AMD64 single arch rpms. Same syntax as INTEL_BIN_RPMS
>> # Has to be a bash array
>> : ${INTEL_AMD64_RPMS:=()}
>>
>> # @ECLASS-VARIABLE: INTEL_X86_RPMS
>> # @DESCRIPTION:
>> # X86 single arch rpms. Same syntax as INTEL_BIN_RPMS
>> # Has to be a bash array
>> : ${INTEL_X86_RPMS:=()}
>>
>> # @ECLASS-VARIABLE: INTEL_DAT_RPMS
>> # @DESCRIPTION:
>> # Functional name of rpm of common data
[gentoo-dev] RFC: intel-sdp-r1.eclass
Hi everyone,
We (actually mostly soap) rewrote parts of the intel-sdp.eclass and
decided to revbump it. Please review our changes.
Changes are:
* Move from EAPI=5 to 6
* Adopt to changed packaging layout
* Use ABI_ instead of multilib
* Drop eclipse support
* Require all RPM lists to be arrays
* Don't record in installation db
Thanks,
Justin
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$
# @ECLASS: intel-sdp-r1.eclass
# @MAINTAINER:
# Justin Lecher
# David Seifert
# Sci Team
# @BLURB: Handling of Intel's Software Development Products package management
if [[ ! ${_INTEL_SDP_R1_ECLASS_} ]]; then
case "${EAPI:-0}" in
6) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac
# @ECLASS-VARIABLE: INTEL_DID
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package download ID from Intel.
# To find out its value, see the links to download in
# https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
#
# e.g. 8365
#
# Must be defined before inheriting the eclass
# @ECLASS-VARIABLE: INTEL_DPN
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package name to download from Intel.
# To find out its value, see the links to download in
# https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
#
# e.g. parallel_studio_xe
#
# Must be defined before inheriting the eclass
# @ECLASS-VARIABLE: INTEL_DPV
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package download version from Intel.
# To find out its value, see the links to download in
# https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
#
# e.g. 2016_update1
#
# Must be defined before inheriting the eclass
# @ECLASS-VARIABLE: INTEL_TARX
# @DESCRIPTION:
# The package extention.
# To find out its value, see the links to download in
# https://registrationcenter.intel.com/RegCenter/MyProducts.aspx
#
# e.g. tar.gz
#
# Must be defined before inheriting the eclass
: ${INTEL_TARX:=tgz}
# @ECLASS-VARIABLE: INTEL_SUBDIR
# @DEFAULT_UNSET
# @DESCRIPTION:
# The package sub-directory where it will end-up in /opt/intel
# To find out its value, you have to do a raw install from the Intel tar ball
# @ECLASS-VARIABLE: INTEL_SKIP_LICENSE
# @DEFAULT_UNSET
# @DESCRIPTION:
# Possibility to skip the mandatory check for licenses. Only set this if there
# is really no fix.
# @ECLASS-VARIABLE: INTEL_RPMS_DIR
# @DESCRIPTION:
# Main subdirectory which contains the rpms to extract.
: ${INTEL_RPMS_DIR:=rpm}
# @ECLASS-VARIABLE: INTEL_X86
# @DESCRIPTION:
# 32bit arch in rpm names
#
# e.g. i486
: ${INTEL_X86:=i486}
# @ECLASS-VARIABLE: INTEL_BIN_RPMS
# @DESCRIPTION:
# Functional name of rpm without any version/arch tag
# Has to be a bash array
#
# e.g. ("icc-l-all-devel")
#
# if the rpm is located in a directory other than INTEL_RPMS_DIR you can
# specify the full path
#
# e.g. CLI_install/rpm/intel-vtune-amplifier-xe-cli
: ${INTEL_BIN_RPMS:=()}
# @ECLASS-VARIABLE: INTEL_AMD64_RPMS
# @DESCRIPTION:
# AMD64 single arch rpms. Same syntax as INTEL_BIN_RPMS
# Has to be a bash array
: ${INTEL_AMD64_RPMS:=()}
# @ECLASS-VARIABLE: INTEL_X86_RPMS
# @DESCRIPTION:
# X86 single arch rpms. Same syntax as INTEL_BIN_RPMS
# Has to be a bash array
: ${INTEL_X86_RPMS:=()}
# @ECLASS-VARIABLE: INTEL_DAT_RPMS
# @DESCRIPTION:
# Functional name of rpm of common data which are arch free
# without any version tag
# Has to be a bash array
#
# e.g. ("openmp-l-all-devel")
#
# if the rpm is located in a directory different to INTEL_RPMS_DIR you can
# specify the full path
#
# e.g. CLI_install/rpm/intel-vtune-amplifier-xe-cli-common
: ${INTEL_DAT_RPMS:=()}
# @ECLASS-VARIABLE: INTEL_SINGLE_ARCH
# @DESCRIPTION:
# Unset, if only the multilib package will be provided by intel
: ${INTEL_SINGLE_ARCH:=true}
MULTILIB_COMPAT=( abi_x86_{32,64} )
inherit check-reqs eutils multilib-build versionator
_INTEL_PV1=$(get_version_component_range 1)
_INTEL_PV2=$(get_version_component_range 2)
_INTEL_PV3=$(get_version_component_range 3)
_INTEL_PV4=$(get_version_component_range 4)
_INTEL_PV=""
[[ -n ${_INTEL_PV4} ]] && _INTEL_PV+="${_INTEL_PV4}-"
[[ -n ${_INTEL_PV1} ]] && _INTEL_PV+="${_INTEL_PV1}"
[[ -n ${_INTEL_PV2} ]] && _INTEL_PV+=".${_INTEL_PV2}"
[[ -n ${_INTEL_PV3} ]] && _INTEL_PV+=".${_INTEL_PV3}"
[[ -n ${_INTEL_PV4} ]] && _INTEL_PV+="-${_INTEL_PV4}"
_INTEL_URI="http://registrationcenter-download.intel.com/akdlm/irc_nas/${INTEL_DID}/${INTEL_DPN}";
if [ ${INTEL_SINGLE_ARCH} == true ]; then
SRC_URI="
abi_x86_32? ( ${_INTEL_URI}_${INTEL_DPV}_ia32.${INTEL_TARX} )
abi_x86_64? ( ${_INTEL_URI}_${INTEL_DPV}_intel64.${INTEL_TARX}
)"
else
SRC_URI="${_INTEL_URI}_${INTEL_DPV}.${INTEL_TARX}"
fi
LICENSE="Intel-SDP"
# Future work, #394411
#SLOT="${_INTEL_PV1}.${_INTEL_PV2}"
SLOT="0"
RESTRICT="mirror"
RDEPEND=""
DEPEND="app-arch/rpm2targz"
_INTEL_SDP_YEAR=${INTEL_DPV}
_INTEL_SDP_YEAR=${_INTEL_SDP_YEAR%_sp*}
_INTEL_SDP_YEAR=${_INTEL_SDP_YEAR%_update*}
# @ECLASS-VARIABLE: INTEL_SDP_DIR
# @DESCRIPTION:
# Full rootl
[gentoo-dev] Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2016-02-14
On 03/02/16 21:46, Dirkjan Ochtman wrote: > On Tue, Feb 2, 2016 at 3:18 PM, Justin Lecher (jlec) wrote: >> Could you please sum up the thread and come up with some precise >> question we should discuss or vote on. > > The question is: what language should we use for XML validation in the future? > > There are two main contenders: RELAX NG (with a compact and an XML > serialization) and XML Schema. Of course conversion between these > schema formats is possible, but the question is what the canonical > language should be and what other formats would be provided (and how). > > Summary: > > - I contended that RELAX NG compact serialization is more readable, > and that DTD and RELAX NG validation are equally fast. I don't have > much experience with XML Schema, but I do have a conversion tool for > RNC (compact RELAX NG) -> RNG (RELAX NG XML syntax). > - Michał has used both RELAX NG and XML Schema, and prefers the > latter. It's more popular, and it seems that cross-referencing things > is not supported (trivially) in RELAX NG, whereas it should be in XML > Schema. > - Robin prefers XML Schema, but can live with both. > - trang seems to be a pretty decent tool for schema conversion, but it > doesn't handle XML Schema as an input language (likely because of the > complexity of XML Schema). > - There is a standard for referring to RELAX NG or XML Schema schemas > from XML documents, which would be useful for tool authors. > - emacs nXML mode works only with RNC schema, which is a reason for > Ulrich to prefer it. > - Brian seems to like RNC for readability/flexibility reasons. > > I hope other will jump in if they feel I missed > something/misrepresented their opinions. > > Cheers, > > Dirkjan > Thanks Dirkjan for the summary. Justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [PATCH 0/5] RFC: Patches for wxwidgets.eclass
On 02/02/16 23:36, Ryan Hill wrote: > On Mon, 1 Feb 2016 12:08:28 +0100 > Justin Lecher wrote: > >> while tracking down the following error when running "egencache" >> >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found >> GENTOO.GIT//eclass/wxwidgets.eclass: line 84: get_libdir: command not found >> >> I found that the global scope get_libdir() usage of the wxwidgets.eclass >> doens't work on EAPI=6. The following patches correct some minor things >> and block EAPI=6 for now until the eclass is ready. >> >> Justin Lecher (5): >> wxwidgets.eclass: Update Copyright year >> wxwidgets.eclass: Fix whitespaces >> wxwidgets.eclass: unset unneeded variables in global scope after usage >> wxwidgets.eclass: Only inherit eclass ones >> wxwidgets.eclass: Add EAPI support >> >> eclass/wxwidgets.eclass | 33 - >> 1 file changed, 24 insertions(+), 9 deletions(-) >> > > 1. I don't think most of this is necessary but go ahead I guess. Most of them are trivial, but excluding EAPI=6 from supported EAPIs is essential. The usage of get_libdir needs to be moved to a phase function. Which should perhaps be coupled with an env variable which is checked in the later function to ensure the phase function has been run. > 2. When did we start posting every @&#$! eclass change to g-dev? File a bug > like a normal person. (There's already one open you could have used) I feel pretty "normal" when sending eclass changes to g-dev. Having code reviewed which influences a larger number of packages at once in the most public and open way is something we should strive for, isn't it? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [PATCH 4/5] wxwidgets.eclass: Only inherit eclass ones
On 02/02/16 00:18, Duncan wrote: > Justin Lecher posted on Mon, 01 Feb 2016 12:08:32 +0100 as excerpted: > > [Title/description only comment, body quote snipped] > > What about eclass twos and eclass threes? > > IOW, s/ones/once/ > yeah, I have some weaknesses with those words :D Thanks for spotting. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 3/3] cmake-utils.eclass: Define default EAPI to 0
On 26/01/16 15:10, Davide Pesavento wrote:
> On Tue, Jan 26, 2016 at 1:50 PM, Michał Górny wrote:
>> Dnia 26 stycznia 2016 13:36:00 CET, Davide Pesavento
>> napisał(a):
>>> On Mon, Jan 25, 2016 at 9:29 PM, Justin Lecher wrote:
Signed-off-by: Justin Lecher
---
eclass/cmake-utils.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 01de9a5..23339ab 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -112,7 +112,7 @@ _CMAKE_UTILS_ECLASS=1
# for econf and is needed to pass TRY_RUN results when
>>> cross-compiling.
# Should be set by user in a per-package basis in
>>> /etc/portage/package.env.
-case ${EAPI} in
+case ${EAPI:-0} in
2|3|4|5|6) : ;;
*) die "EAPI=${EAPI:-0} is not supported" ;;
esac
--
2.7.0
>>>
>>> Why?
>>
>> Indeed, why? I think it would be cleaner to simply quote the parameter to
>> case.
>>
>
> AFAIK even quoting would be unnecessary in this context (assuming bash).
>
Guys, if you are sure, that it is enough, then I will drop it. I just
thought there has to be something. But I tested it and it's unnecessary.
At least with latest bash.
Justin
Re: [gentoo-dev] [PATCH 00/16] devmanual: update the docs for post git-migration #558642
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 17/01/16 08:55, Gokturk Yuksek wrote: > Hi, > > The following patch series attempt to update devmanual to replace > the instances of CVS with their git equivalents. I tried to keep > the changes small in favor of updating the docs over multiple > iterations of patch series. The intention is to get the bare bone > changes in so that the quiz questions can be answered. > > Currently not included in the series are: - References to CVS in > sections about herds since they will have to be rewritten per GLEP > 67 soon anyway. See: > https://bugs.gentoo.org/show_bug.cgi?id=572144 - I am not sure > about what to do with the subsection Ebuild Functions/Miscellaneous > Files/ChangeLog. The ChangeLog files still exist in the rsync tree, > however they are of little importance in terms of development. > Thanks a bunch for all your work. Please direct the mail to devman...@gentoo.org. That alias takes care of the devmanual changes. Justin -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWm7CRXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiIMwP/2/9RGTZYlPjjmmc8kao77kg C0ogMmWjsazNSdUcMztqwyDNMPMtCf1ZbVLq/MJYxFkKH6lXocP6/MDoOgIrACCU gCQhOASG/8fVyLAyT/719qsXPZpEXAqKAImHkB+jvw4SG0W7+uORQWUGXAKd5Oic ZAfWhqBjCkk7pWlP8u+UIM1E8fb3e1KPednbAetNCdRQRiCh77X5BJODAMc25T3O vu5qMxB2UDp4tjZ2+rKahcHabgIgp4vbkNk91t5tskOu9aiQCDCkVyBbsUVlfWd+ PHMxfXI+p19K8eIv7tocdX3bKVdyCtaaB6bBddb9G0skM1Kpi5PK0W2+2H/jBEvL YfQ0gNAENhPK5aAPGR9Z1ulN7aSaiWMEExfF6rTx+5BF+IKzcH4n4jKsE2AIw25c hJC0DlugAW7IXUi7QKCSpbejw+BhjtWppo5f8bgGK+pUot6rbKmItfgcCFOtyZjV oFKL5ZiGpclPaYw8bBh9woFypc1K1cHCkDXrFbag1BXTugit2f0qK2716uL45UcT xqGp1uJ/lm4dS91sptfjOCFVs76df8xl8jzr3zEwmfgac0bjCR7MVucTBvHmP06A UCtNNvKI6GRfjC1BtZ+WpW+Mg6wBcdIu8I46r9wdciVbwqJ8KHAoQ0/o2RRVLYbP Uv/ioCuMAUpTAFbUhPVt =p90x -END PGP SIGNATURE-
Re: [gentoo-dev] News item: Python ABIFLAGS rebuild needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/12/15 16:11, Mike Gilbert wrote: > On Sat, Dec 12, 2015 at 3:54 AM, Ulrich Mueller > wrote: >>> On Fri, 11 Dec 2015, Mike Gilbert wrote: >> >>> It is worth noting that GLEP 42 makes no mention of EAPI, and >>> current versions of portage do support slots in dependency >>> atoms used in news items. >> >>> I guess it's a matter of documenting this somewhere. Where >>> would that be? >> >> We should update GLEP 42 and introduce a News-Item-Format 1.1 >> that supports EAPI 5 for dependency syntax. >> >> (This has come up several times in the past already, but for >> some reason nobody is willing to take the initiative for updating >> the GLEP. Everyone seems to be happy with a workaround for their >> own news item.) > > Thank you. After skimming thought GLEP 1 to refresh my memory, I > have filed bug 568068 to propose the change. > > https://bugs.gentoo.org/show_bug.cgi?id=568068 > The council has been approved NEWS item format 1.1 supporting EAPI=5 style package dependency specification. Justin -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWk3FPXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmi29sP/Rsz7INlTIZiPNJiM1vksPQk s2jgBA3J6CeFc8L8H6WsCEvNpPGmPbj/X+5cYpkbaGRaKfEBarRMuld4328wd4bh z9LlKvrHo+83yB5y6njgDiFW0w/CrskoOW4JoJN5XNanvzQkt5FbJwNoUY/l2IYg ezC6B3TlbDnCci2tnkzAZtjbeHd3DB6hrKuY4SWsSB55blmE24EqNp78e7BId4PA oZZM7ju97OsdjgEFJ6eGa0csi/UiZVGwVLj94I5580Ai+2BGWBDXsoevUqg62PlN eKm1j3afq/bTrcK1MciY+zv4IT5w0/x3gJmn+Tj2V8apxcurgJjbC8h3tWQ67DJ8 99hpiGqCBwCNU8Mpl59ZIkce239S8X8XZ4tmWbLeqZIWJ6yPiF2sRFxD3N5d+Asp zlo7/EzJDrbDr3RXtq9x79VgG+PNJGci1CYoyzr/Pf2WkW9ss4Fie5oB8dXET9+n HJdslP/zlqcAr5kogNeg+Mt68Jms7RQavRJDpaFqvmWGWMV9iAJp4W9dFEovfmoI 8ekMBuEgSU2he0gp6CpAuZy5ufV97q8uz3nv1KcPqCIDtg7J/dvmKZSOmp7Qg+Id ZR1l0vAE6gXzwx1dIw/gbHXWVNudoKRNjQmQ6Ki5ApOKl4PZRb04XTGHeDONT90E V9+Ltk9kxNfPQgHMo1I+ =wBq6 -END PGP SIGNATURE-
Re: [gentoo-dev] packages to grab
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/01/16 22:07, Julian Simioni wrote: > I'd love to proxy-maintain app-admin/pwgegn: it's used by > app-admin/pass which I use quite a bit. Hi Julian, do you need a proxy or do you have someone to work with? Justin -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWkggQXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiFC8QAI9jgNdZJh3bHeIaNNqeMfAj 6uiYrfHOp0Z4jhAwgeJ+Sdos0fuEdsyQWmbWtoNMkTpRmSjN3BG2Q7fkNmLcowxE 4epTbdQzZAHAznWKb9JGBHFIHj3ninkZEt41OYx38RX30QoheKTTdb4fm2I1gNU5 NJkCFVXrPSOOiQhf34lu/Z7jphnpyjV0H35XJjmxQoQ1q6kYIgQpGEa6IkTwS+qb BEJogkhw/CTR1tBbgkiQDUntLt3SAlab4hfdpSL1WbLHKOS1i9tF2V2PTCiAn0wy 4YkZ2F0LY2SE3baLw5zVikzJqg3VHwBbH7O94+MGy32Y02HlRpVgvqS5mY/TdB6d uRw6A+rQcFUXvQ4uFmiAg3d4sp4IxR526kfrg+NtYMdz4PJPgJvC8LDoa8TsSXXG SJ5E9TJ64xwjJsw1Hh454pTDW//6bKdW3DDhsrKGDlSmOVj7iH6uvh60ulUg97pT goYJSXERnAHHO90Vdo72v/Efi8IFZvjUPbQc0LwQhMPWCHjnTo7pwJwG3xkn8be4 aypMqn/Z91cR2fkcJwurRtFh/JQKYLYj2zEKquBRgcgqQo4Hwk9oH9hf+IUG4yOF 8B29rZDjQKh/PBgPeyi5qHJHdHxhH8/A5qecrOou9F2OntjDqB6kNbiGFcBLAf5a SgbwXehru1VIT/CKv/2T =XZD+ -END PGP SIGNATURE-
Re: [gentoo-dev] packages to grab
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/01/16 10:14, Justin Lecher (jlec) wrote: > I already did that. 90% of all packages can be associated with > some project. I will post a PR for review later. > Please comment if you disagree with some herd/project assignments. https://github.com/gentoo/gentoo/pull/623 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWj4I6XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmi95sP/0TBkRpuN7kmwlEgekHPIBSb ouaSMza4mFZCUnGQihndU4S/sDS0XgWzT9wihs5fOniDY1PSeATlW+PCGpFj42KB CbfIwrTevfmpvVmgpwyjUcxLc6KhYGC8lLYgvhq/o7/176scLPX0tDg7ZfQ2px9i jE8oqGW9fLufl4d+dBQg5jiAgPuN+pGK55oBdrd7vfnUtDp/3NxHdHG6rCg+YxA7 LuOHgl6zEoeZVYXsMGRJg/VF4UzKztk3QqsO2giP/0vhnaxfJPG7OcuvDp8fgtkS TiFoMtMi96xWAU30eK5odV+C8imw1KDhwAHXpzWojSQ+mAxFHxCMle8BtALSFi/v 7TS0ud/VPnoT2isj2sSM95jl2s40WEo9sU0e0GpK6Ms9YfiLC/ZsCuSVEyrjcxrG 4v4PAm/TDHzOI6UJk1ZlMHYzAPudzMoucC3lkTqmngJFn0VtyHPbAiGc0MAMyWRe Vfxz6FXRnaER7h7TkYHzS80oszHspug32AZ45///BbP2sm9kvoYRj/K8BuPiELfb puHIITv7q9aeS6csz2fxfALWNOgR6bo5YHqGKzKJpeO1x1cOpRrJJqoo6dIy6LUj C53QICirg8bTif7By+F8ST3PHg5wc0sOgsv6kZPVvwNUAt2QJ8sScpbiw8XDZRKv 7bumtPUo4LGr0v1avOUR =GgKG -END PGP SIGNATURE-
Re: [gentoo-dev] packages to grab
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/01/16 09:47, Dirkjan Ochtman wrote: > On Thu, Jan 7, 2016 at 4:40 PM, Matthew Thode > wrote: >> gonna take these unless anyone yells at me. >> >> modified: dev-python/ipaddress/metadata.xml modified: >> dev-python/lz4/metadata.xml modified: >> dev-python/mysqlclient/metadata.xml > > It would probably make sense to put these in the Python project, > too? I already did that. 90% of all packages can be associated with some project. I will post a PR for review later. Justin -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWj34IXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmi3s4QAI0MLYDo2yqN04azi/Gm+XQI Ix7r56MVdLqlcF0+hVaehQYdkcIVOtvcWi6RaAAGnS7uFw7/cc9C9mAkSp6aQJ2N aGHRl85orgYcaKICU+qAr6t3bsgHd2rG4MTpkwyplX+xiUYBfaYfPU45ttC3b8A+ peGxcOKHs8BVkA5LzO3ZeXjdZ3jsdQRh+onNwj8Kiei9QPqbjjkZUkc6DbxYwGVu oiXgRkYPgjtmOIXjRkWlwKHxCAmA0DErJ2B8LqYdc4jMomherumKsNkDooyUkpvB CnKlF3Bi0MDKYb9g9EBPEkmy0zUZNA1WBJg9JH7uMG1BmThLj8KFHmZCtpItRZwd x6rwRIXexPBFF5P8hWMxm5rKEucd4TPX4PK/vTX+ne8ARG/NTWH4V8SOpJJdmD8M LJ987THWK/edzCVZ0yXNL2tYN3R4A/6TW1TaJBiTWnNewhFbtZOGv8KqEgedu2x9 mFOxpjIQF7yqIAj88AQZ+9SdBm4Ox/fR8DL18nmSmeQv/yi9oj32Psygusd+sCRl IkZQMYqtdAouZgi1rvOtHrfPYoEOnsR30UrtZeXWOGYRCoR9UGlmuNknKwOlXqRx Uws/cqj3NdaQVrtlIYUuOj6KyPsTqT0Ht6M6Usu32Dxcx2foNQTqASrXejABrRc3 tAa8yKiTrX/ftG75oisS =MHwA -END PGP SIGNATURE-
[gentoo-dev] packages to grab
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear everyone, due to changes in real life I need to cut back vastly my day to day maintainer work starting in February. So far I have no clue how much time I can devote to Gentoo in nearer future. I will move all packages I maintain [1] to the associated projects if possible. All devs are free to take what ever you are interested in. I am also happy to proxy contributors if they like to maintain a package. My plan is to focus more on task which I can handle more flexible. Regarding the projects I am involved in I have the following ideas: _Recruiters_ We are again actively looking for someone who is doing the review session. The candidate should have solid knowledge about the various aspects for Gentoo reaching from packaging to institutional aspects. Further, you should be able to work with inexperienced contributors and have fun teaching the necessary bits. Secondly, I would like to work strategically on our recruitment process. This includes reworking of the quizzes and a general assessment of the process as well as new options. We won't change anything over night, but I really think we can do simpler and better. In case you are interested in either topic, feel free to drop a mail to recruit...@gentoo.org. _Science_ We are understaffed for a long time. So in case you like to join feel free to do so. This is also and especially directed to the community. I strongly encourage you to contribute via PR to the overlay or the main gentoo.git. If you have proven yourself in contributions and still nobody encouraged you to become a full dev, don't hesitate to express your wish and we will manage your recruitment. _Council_ My council duties should not be affected. _Other project_ For the time being, I need to drop most work there. Cheers, Justin 1) http://euscan.gentooexperimental.org/maintainers/jlec%40gentoo.org/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWjm0WXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiRJEP/iUdqEAjHiBsQ3sWsXG/kFkc XYYk5L/zcimN7IddWU/6+uo2hsDDHfFuN0C3HYXV6GWqUOmegz9Enb9gteSOfL1X Lmsi+OOAHuTeYzhltoxVzXipyO7+TBPDHHF52XTLruZQkwXeBSO0Eo3Gg6LruwFu WdJoqKTyTaX0kweYngO4ZIQ6oh0H5wHgreJInKgDZMA9eGbImx4NOnEXbtE6X9le OFtN5vZBEEsrwXy4V56k/Af96x5EkmLXFCeaTTsgk90bUuKXnTzmRQ1Q6za1OOro vcZoEEWcwFnyQ5DF4/srWxtkivprf0FR34jeT2RQhekJDcih2PMaHAWc/HhZnQ0b eAde/O4vUfioLtYWZ6fZdAg+98wa/oYA8kVwijXpaDzYCva9hbZDtkwcky22tCd7 Gaxku+aN5CwB8hFoEIinxT47GAIXK1MYRojURSsT5m9R/+BOGiaavzM4DHMFXWZq VhLI5EjYapq9eqe7rHpHzGj06vZA3YioqCXGcyiMHg78qd2WfaupEydVCyxP75v8 +YQHpyojVcxkmdDEc7ZFSHPQ+ti+QwcWzr1UZ23YRnwsYKD/+Ip9dDq8BQlkTno+ dH70jHG1G6E8SjZD8pg52EEKdoxlhS+XGsgiVSvTlnVcrfbSAwdh48kMI3iCLinB nxlJKWBCBHEQPbXXP4WV =dGQ9 -END PGP SIGNATURE-
[gentoo-dev] [gentoo-dev-announce] Last rites: sci-libs/libbufr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Justin Lecher (29 Dec 2015) # Fails to build and test runs # No reverse deps # #370021, #478614, #513964 sci-libs/libbufr -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWgkswXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiEOIP/Rtom3pnl6rBmx0eMUOFL4E+ szr74nNaptRWsef2xXcJW5fBDl6IifLnWjHaVGaYSDAKyvBFM9QBlbKlk+Oa/YZs O6aybzDfWiQg0nV3nSeiJ6w580AG167qb9Aung1FP4SrqvoGluK+jTMlm9Gh5aT8 v7zDZRS96oqpDYtnOIyFgOMbvxJ7+hDAcVEKzqTbJy7CHU/SfL9OQwpdcmMN417K 0Ys/eHTkH0LIWtHuuH48muvWYtsotvaIttbhKDPWo4Fq00v1RA/GZmx3RA352jGx bEqvdApRmFea9aqzEOPAOYe41Es8yDBjXw/YqPxZP17Bof7WHr6Kex/lu1bcK2o+ W2tBsTEHLcvYapqbJsQJ34XmA0ywkBwGp2hUQVMcfYCIjOIsvO4jHQ2+QiF5zg0G Qd5G3obzW7vnZkXrhMwZ2Yf+vI8rKA3Vrdto54OJdbE56QR+lzp6YU+K12aWbsVQ 1l+g76d+mpo/ocZ465bOhGORRmV7BE1lK1TbY1mjwaUDny/oBVH6S+QO5at4/Mfw prkaZhtmsFs5QYrUGK6FxSRpr2+WzFj1Vgw7jThDXBqGr90PI5+JDK2MxMn9+VYx Bwhe2HC60t9sdibsW4aCUhQ0YnxK+PKl6l7uucvwTZdcnPJtmzKagvuEBAutVdNK GpKh/PN8T5crpvLJL3iC =frfY -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] check-reqs.eclass: Replace obsolete df option -m with -k
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 28/12/15 16:41, Michał Górny wrote: > Dnia 28 grudnia 2015 16:27:43 CET, Justin Lecher > napisał(a): >> Using kbi as base unit for calculation as linux and bsd only have >> -k as common option > > It's 'kibibyte', or KiB in short. Updated, I had the suspicion that it wasn't correct, but didn't do any research. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWgVkVXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmi3AkQALwjL7LRN3AcmQnWBHy56YFK 3YmDwFUDZZ9aA6doO3C5TVKzwBc/+WopqS7sDb8djC4yMmPVJqZJIYmwNbkch7SE UamDfBo8d8asbW+KmfKdOm56IWlL3P+ObPD3qaUcVsOkfw4q4iF5VK55Of7l/Va2 oh1rugmQ22nY0lcSo1QCioiuwqsivQnBdnK+iEHNXxEiF+WFg2MXnedcVF0blGii iXTqJZXavjTanXANPyHn35WpPIw6cQR+vYjXT9JX8uDqchfKtgooYNsatGSc7Osi 0vykwSa4/A7SKrksyPdQ5/NcSArQZEk9M6udEEChx6LLuURtsMMKPEeAxF45CMGR Pqc6InN2xU8eocAHm2eZO+Pj065Pvio3WSXCL4LCADwU9mlktb6GJZIEpOBVs3QP WrV7TFzikbiW4vKfD0nvv3o6IqcwNQQeoPbBOiigPnXOGzJGVklMs8g/VOQvslsZ ALscmFhKmhbS5ISpivXhbQMaZlChhXLCJHmsED2Mf2C5rIuOUxSLjly05K6v7+gB 1Zowqny/nFa6Z9OejNmuSyk0OB/PLV1U0cel0lmsL6RKpRDl9g3YUsIsE09GDWdx x8CWsJXB0YdIaQ8b7TC39/DdT9o2nwddKlfHZVHwXzfq4zn++lU1yq1AAh0fecOz PTt3IvS+XyZlR7Npt298 =OXj4 -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH 5/9] check-reqs.eclass: Replace obsolete df option -m with -B ###
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 28/12/15 15:24, Michał Górny wrote:
> Dnia 28 grudnia 2015 09:43:51 CET, Justin Lecher
> napisał(a):
>> Signed-off-by: Justin Lecher ---
>> eclass/check-reqs.eclass | 2 +- 1 file changed, 1 insertion(+), 1
>> deletion(-)
>>
>> diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass
>> index 138bfec..a32f8f8 100644 --- a/eclass/check-reqs.eclass +++
>> b/eclass/check-reqs.eclass @@ -306,7 +306,7 @@ check-reqs_disk()
>> { ${size} \ "disk space at \"${path}\""
>>
>> -space_megs=$(df -Pm "${1}" 2>/dev/null | awk 'FNR == 2 {print
>> $4}') + space_megs=$(df -P -B 1048576 "${1}" 2>/dev/null | awk
>> 'FNR == 2 {print $4}')
>
> I don't want to spoil the party but '-B' doesn't seem portable. I
> don't see that option in FreeBSD man page.
The source code says
case 'm': /* obsolescent, exists for BSD compatibility */
So it might silently go away. Let me have a look at the BSD sources.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0
iQJ8BAEBCgBmBQJWgUclXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiiUgP/itabhl/43o8fY79y/cuZuRW
xmvQirepGlHrqVZvgOGiBxyK2q0wpVhrsgHe/hwkK/lV8NA+C0eOIUW2wlwLiyEN
T6UavwPFdoZ4YgNuj9m8ZCNbZVrJUyEFP01RUWuHyEah6MFBg+D8Jtl8vWNlzZKm
W8z3KPDTrDhpcg8i+r9D915RARpo9wraTc/LvK8QXF51YuBcn1MWsRjd50g2FQiu
R6Epylw7EmAL4AT9bhx7skdBS2z5GRHJQFEObYqtxve0PDdXOvw8SOcxwcqQXCv2
ZCEuVCURfOlOOVdL1mgfIJa/h1FMO3n1NjrZXFFZtVNs1T3sYm9/lyYjGuYQIFP3
ITkIVPBunjgbmG+wNRFOonNRDnxY0Y8F0AiaDNi07WpbkAoo52oHz9gWL/hsdhDd
vfH074JoIVtoXS6yeaESPSwOlurQ30bwhpAz7xzWLW8sWopyR+sGkuW7AQ9PkmZc
mwVX6ZIWBdZ6Zk5Ae7UNi3Lc3akSrz4GkiAlbLmxg946BMrTfJFIPBFvR82TkkNw
+mRPJUPuiCWDDDyDKNCpGb/YQB8kjkiWHZkr1Id7PLhIIDkeuccVqvEvzTNU22pk
DdQkUt9L69FxTE8OtskEDueaINaBMtBpGpPh5K+arsKUt85jIX4oM25IXau8HAWx
mDTncoD6QRn2dNXuf5gx
=O924
-END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH 5/9] check-reqs.eclass: Replace obsolete df option -m with -B ###
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 28/12/15 14:58, Andrew Savchenko wrote:
> Hi,
>
> On Mon, 28 Dec 2015 09:43:51 +0100 Justin Lecher wrote:
>> Signed-off-by: Justin Lecher ---
>> eclass/check-reqs.eclass | 2 +- 1 file changed, 1 insertion(+), 1
>> deletion(-)
>>
>> diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass
>> index 138bfec..a32f8f8 100644 --- a/eclass/check-reqs.eclass +++
>> b/eclass/check-reqs.eclass @@ -306,7 +306,7 @@ check-reqs_disk()
>> { ${size} \ "disk space at \"${path}\""
>>
>> -space_megs=$(df -Pm "${1}" 2>/dev/null | awk 'FNR == 2 {print
>> $4}') + space_megs=$(df -P -B 1048576 "${1}" 2>/dev/null | awk
>> 'FNR == 2 {print $4}')
>
> Why not "-BM"? IMHO, this will be more readable, though, of
> course, both arguments are semantically correct.
>
Because the output is different to the original version.
$ (0) df -Pm /
Filesystem 1048576-blocks Used Available Capacity Mounted on
/dev/root 47244 25665 19157 58% /
$ (0) df -P -B 1048576 /
Filesystem 1048576-blocks Used Available Capacity Mounted on
/dev/root 47244 25665 19157 58% /
$ (0) df -P -BM /
Filesystem 1048576-blocks Used Available Capacity Mounted on
/dev/root 47244M 25665M19157M 58% /
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0
iQJ8BAEBCgBmBQJWgUQzXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiAEUP/RQJRmOaXjUD5orDBpXj/nvj
CszwErjdwR43HwEsWeNVGMX1dXd0l1KM5p8tK5d4cn2u920VG8U8ef+SsfJhmfbn
tnlM7hOhLmWZOqp57YpLeOvEpz0gqfjgKw3b/5Ywg4ISacufgAwNxbsSBnEmqQYv
wETPveQAVETa0SoKD3Ki9PLRVVMN1t+/azMc9hn7+Tm2dth0QoF2sQ3Tm5VbQG/H
BfQ4IWAUgpSrU991uliOt7kVTXTEShScSVPVACNoU63qtbNrYU92XGlDCAzPBsjp
E8l7jdrlHXlgqu8zh+wvrJ/1qw3t3eqnB96pGe8HAfhdeJ6cVd3mNZITMNmmRl/G
IaIdQ1dZlQLmP1ywK3bxS0ehi4XCmaQJKxP0vNAcnrlY41ea8qHp6UhrHT69c+Nr
WKCKmanfaadsoLQkHgFiy4kGuXna20XyBdyr1zP9y6L8aSz8Cq6WbESkFu3aNgFT
FTNOW4Z6fFwEc/Le3Kaowk8arv9E7yryjkqWzl4EO2nwUReg/4UmfkqgBCSOFh0z
JUd1Xvoaeo6hiSEw/VmL+D/HCzlm7Z+SRtNKDR3d8gsyCY0lVMBZscBYdSpAKbn2
5RkkynZdR52Y+1cr8Rt9G7Uz+AaX82L19+WgYd9y5dcUynNJgDU5+SRFT1/hZfSR
eO0pNmZ9ywefEvYh/2Mc
=4hR/
-END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH 0/9] Cleanup and EAPI=6 support for check-reqs.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 28/12/15 10:35, Andrew Savchenko wrote: > Hi, > > On Mon, 28 Dec 2015 09:43:46 +0100 Justin Lecher wrote: >> Dear all, >> >> please review my suggestion to the check-reqs.eclass according to >> cleanups and EAPI=6 support. Any further ideas you like to see >> implemented? > > It would be useful to allow users to include swap space for memory > estimation. Sometimes this is the only way to build package > without cross-compiling. So I propose something like: > > CHECKREQS_MEMORY_USE_SWAP="yes|no" > > which can be set on command line, in make.conf or in per-package > env setup. > > This option should be disabled by default, of course. > > Best regards, Andrew Savchenko > Hi Andrew, could you please file a bug for this? We do not bind this to any EAPI as this is an additional feature. Thanks, Justin -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWgQOKXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiUGwQALGC6G1QpuNLmRoi3HNO4SwF TrFEpiEqBRhYN09PQQOs82ke8m6MkU7miBZazv9ty/GwVz1x+aNsRj3b7IY6kT9S gTTjUcUFtn62mZtym0OFBqlOcjeeHcPMFCfQxBJ5Opgayjcr2//xd8cEj6TH8z11 M4vLvXbQ7283+0bvbd3g0G+JMquF51z+A87zZEu950sTKv2ZF35FBECzqCEmWYOM /o0qj089VxGppvRuA5JWS/BfH/Rjxe4XvdJv9PEwfNX/S9rLHOYi63mb8d2eyINO Eug8pkVSxXl9sGllanVYYNo/WlVZZQDZRwzAV6AsBBKU7QP+OHPjST0ikV2TE0nP eRZ1biekprTYWaL6eucTh8VRhBPewHRC33cElWOYW9mqPz0bF+R1jTgNMU6+D96x j5Uzx/gi1AXN6dnK8B2TqEBbsvBXig6mHiszI2c81A55GrPmpYXZiYpeOKpklopz vwb0h021gTFYScxynthomDDFVWdUprkePHtR3rPLwbiL/aAx0FbVf6yi5QBJBmuM HOSlYtOUK/8yYwl9fXTymvWBJlMbXqUToRsKU+/98S97JnxMBju6JVB+m4+R8PE3 YOQrZirU9JqyOxQZ4f9NHwiwnlGth732qQ3GZd4sVkxNG7b/v0YzEVvrzJtIHo7R lk1NIx/RFE2BQ4YVNrv7 =nfVS -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH 8/8] virtualx.eclass: Simplify API into single virtx()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 30/11/15 18:40, Davide Pesavento wrote:
>
> The scenario of bug 517976 is different. I think a minimized test
> case is the following (untested):
>
> foo() { die "meh" return 0 }
>
> src_test() { virtx foo }
>
This example will still break the build, although the Xvfb session
wouldn't get killed. Let's move the discussion to the bug.
Justin
* Scanning for an open DISPLAY to start Xvfb ...
debug: virtx: XDISPLAY=0
debug: virtx: /usr/bin/Xvfb :0 -screen 0 1280x1024x24
* Starting Xvfb on $DISPLAY=0 ...
debug: virtx: emake "foo"
* ERROR: app-misc/dummy-1::dummy failed (test phase):
* meh
*
* Call stack:
* ebuild.sh, line 133: Called src_test
* environment, line 2076: Called virtx 'foo'
* environment, line 2699: Called nonfatal 'foo'
* isolated-functions.sh, line 105: Called foo
* environment, line 987: Called die
* The specific snippet of code:
* die "meh";
*
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0
iQJ8BAEBCgBmBQJWXUt6XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiWGsQALjFU4Z+1yUOUWGyBf7n31hc
FUAq/ZnsFEd8ZPKRSyZVY+os/PjbwMCQQk0U7hUySLZ43mSfzC0aelKMAXx6BYoS
ss8jp2s5LoeIV+YdCIUiIE/y4GHvYwln61W+XrM6TslEaAMVbrKuKoa/TvzE6mrN
Et9ebl7E6LpwTMc72jdGd8KWtkLdl2Ddgt99pKcC9vA7IEZPGlci/Nz7AtHycP3m
YectPEzWVdirNlRcKCDxcCdHbYH1mKjd3kjtatb6nDXURhM4l4qL/OZEdx5mKpyp
EAu+7RzU7XOgyUMuvwWpPtmA/jaR6VSEWJY9W+EwYS3LwNRJczADfEGzE2EGCj+r
0iSOvF2b9DqgO800ENSPH7iUgvgw3pTLqMdUSHsvZg5dw1u08S1DCuB2T1/9Nfin
OUk/zsGELJQ5C0m7a1vugG1PNBmjKNlaKtW+bIDitPgL71GCeQ2QU0Oo5SKRH+bv
Qp2mguaR3nL1xm6MrnRT7bIKW92FRDT2P3eHTRylWg495/i8veaiUL/QBwnegOU5
En4kCyaBusujyT2l5DZnYb6RNOfUWlFQOquaKbK1yRtDsk7tG+HfRkSQR4s6Dlo4
sIdCrjhvgDeTy+6DwcXGWex1nG2ZUkLu36O6uIEFphTgbG3dlXYE1lvrGLwIHyZg
/5PC3gOTW6R0s/DfzDDh
=8pwz
-END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH 4/8] virtualx.eclass: Ban deprecated functionality in EAPI > 5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 29/11/15 10:57, Michał Górny wrote:
> On Sat, 28 Nov 2015 17:21:00 +0100 Justin Lecher
> wrote:
>
>> Signed-off-by: Justin Lecher ---
>> eclass/virtualx.eclass | 5 + 1 file changed, 5 insertions(+)
>>
>> diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
>> index 230897b..a5e5457 100644 --- a/eclass/virtualx.eclass +++
>> b/eclass/virtualx.eclass @@ -59,6 +59,8 @@ case
>> ${VIRTUALX_REQUIRED} in RDEPEND="" ;; optional|tests) + [[
>> ${EAPI} == [2345] ]] \ + || die 'Values "optional" and
>> "tests"
>> are unsupported for VIRTUALX_REQUIRED'
>
> You don't mention EAPI here, which can get confusing.
Valid point.
>
>> # deprecated section YAY. eqawarn "VIRTUALX_REQUIRED=optional and
>> VIRTUALX_REQUIRED=tests are deprecated." eqawarn "You can drop
>> the variable definition completely from ebuild," @@ -177,6 +179,9
>> @@ virtualmake() { Xmake() { debug-print-function ${FUNCNAME}
>> "$@"
>>
>> +[[ ${EAPI} == [2345] ]] \ + || die "${FUNCNAME} is removed
>> in
>> EAPI > 5; use Xemake -j1 instead" + eqawarn "you should not
>> execute make directly" eqawarn "rather execute Xemake -j1 if you
>> have issues with parallel make" VIRTUALX_COMMAND="emake -j1"
>> virtualmake "$@"
>
> Still, if you introduced virtx earlier, you wouldn't have to
> change this die message later on ;-).
>
Principally you are right, but resorting the patches generates lots of
merge conflicts. But let me practice my git skills
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0
iQJ8BAEBCgBmBQJWWulWXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiDUwP/09Q4xMEfaPeAlBIrv120PDc
uqkJeBGHuKDtR6gmgydg+5bVdj6UwElZUsOaNMuBMkCAcrnHfP2WQ/lJafooK4K+
baiVqyFXTKemR8ob2hNLLD5lrvWijvjzc9TAutpfVvJm/NnGNRF2BpmnNKMtVWBO
0RP1pl+Wfjbzzb52KT96GUeeJqunY0EReuoZ2U9pG1HAnVbOGNacxkeSeJA+pfQ4
FQPqhnDAOQMS0p/uXro8h8TeDRIF2wwcRvmCOePKjRF/Ut6sw1/Pogj6iuTxTyaz
m16ebTJmJ1GKc5mk6Fy4yDp6OR8tdgVwYsq+tjq9fMARqDOA/eJRS0I6/uIgaj0h
0dHzBYXxtTBixseVvPXAHY80RWSf5nseTceYVPSuHp+PRAhkrVneWsWfnBelqyzS
Xj+jAPxDRU4gPat3SFt1fRER6A9Ij5VzRTHEEca/kjFvzwxmRs+MxDd7AN8IJK/v
IhfDCgWf6kth0iCKHUkPZgd/ZOoHOUW4rMsGylObWQpCKz9Uzlo/T44Mj5Lr38nK
Ydr1AND394O+74EOSGl2IcQiEFUQcrRIkUyOHIqBex/GAaL1wbyfcQ2u7mtNmddm
Jc5jIM/FzmcDAnZgkxii69fjGb46HsPBUtriAmPydh7mN/ahHy0sPbQqxT3ANYxU
QTYUPft2ma0fmb9TJjO4
=ZaQj
-END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH 4/8] virtualx.eclass: Ban deprecated functionality in EAPI > 5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 28/11/15 16:57, Michał Górny wrote:
>
>
> Dnia 28 listopada 2015 15:08:52 CET, "Justin Lecher (jlec)"
> napisał(a): On 28/11/15 15:03, Michał Górny
> wrote:
>>>>
>>>>
>>>> Dnia 28 listopada 2015 14:24:17 CET, Justin Lecher
>>>> napisał(a):
>>>>> Signed-off-by: Justin Lecher ---
>>>>> eclass/virtualx.eclass | 4 1 file changed, 4
>>>>> insertions(+)
>>>>>
>>>>> diff --git a/eclass/virtualx.eclass
>>>>> b/eclass/virtualx.eclass index a7f17ec..615ff0e 100644 ---
>>>>> a/eclass/virtualx.eclass +++ b/eclass/virtualx.eclass @@
>>>>> -59,6 +59,7 @@ case ${VIRTUALX_REQUIRED} in RDEPEND="" ;;
>>>>> optional|tests) + [[ ${EAPI} == [2345] ]] || die 'Values
>>>>> "optional" and "tests" are unsupported for
>>>>> VIRTUALX_REQUIRED'
>>>>
>>>> You can now make eutils conditional to EAPI.
>
> So your idea is only import eutils for EAPIs where I will need
> eqawarn
>>> from an eclass? As we have no ETA for that to change, I don't
>>> see a
> good reason to fix that inherit right now.
>
>> No, only import it for EAPIs in which you actually use it. EAPI 6
>> will die instead, unless you missed some more qa warnings.
Good catch. Thanks
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0
iQJ8BAEBCgBmBQJWWc9dXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmi2k4P/ip/shOkEwCXPZlPFeY4qiP1
F8fsBAri7M3xlki9DjAp+LoVFVAxVTvoYn8HFWp84gCOjTHSoLbiVpRiX+jKdbUl
dcoSrbGtaaKNT038kLrsRsZQTEzARJR3pw2MZdBb4my38c71Vei8uWwZv1CXM1Pi
uch5bGjzAbDHHbBa07vkgxNpm03D1fe9d2K8kdxbsFXfTRs25fODP+6R7fzifarc
zCYH2Ritif7FXwLwEc1nwveEVt3TnQyxEdPcN5yHYFpQ6GVRQsfJJDk/QauHh9x+
kUnmLwhrzc8AhLltboo1lZgXH7/8W1OaXbHPYtAuk3zEETuKBBzNFp8nlDvFLtfp
1h9sH9VZCddYy2ckA2BCIRosXyAznzgGS1ub0BQsHyjH+ji++pn4ju4LoJLT7i0v
fE07E59ipgA0yq0DbPLp5n/6yhnADj0/C9GaT9FVN+YJYceMejyU3v+Ofn7KRD7n
3p8fU4EUFfU0XqufhwTdKuXpcwg2VJm1eSt5DLs4JpA2yNlpgyZev3n+mo1jFrIM
RMK9xlcWbsz4oiRUS+uFCVJ4pK6Xa8lqk3BhvbPTCh1tapWivQ00O9iNyj8Wfoeo
jV4KQi8ai+1juT+vYvDU3yr831uux4I70D+qfMci+/pQnzHl8AIRicSygUTCD9sl
S1MUVE31Ydqg70FjlDAB
=NqmF
-END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH 8/8] virtualx.eclass: Simplify API into single virtx()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 28/11/15 16:28, Davide Pesavento wrote:
>> else - nonfatal ${VIRTUALX_COMMAND} "$@" +
>> nonfatal "$@"
>
> Please take the opportunity to clean this up, possibly only in
> EAPI=6 if you don't want to risk breaking existing ebuilds. See bug
> 517976 for details.
>
>> retval=$?
The return value is recorded and gets evaluated correctly.
src_test() {
virtx false
}
results in
* Scanning for an open DISPLAY to start Xvfb ...
debug: virtx: XDISPLAY=1
debug: virtx: /usr/bin/Xvfb :1 -screen 0 1280x1024x24
* Starting Xvfb on $DISPLAY=1 ...
debug: virtx: emake "false"
* ERROR: app-misc/dummy-1::dummy failed (test phase):
* virtx: the emake failed.
*
* Call stack:
* ebuild.sh, line 133: Called src_test
* environment, line 2072: Called virtx 'false'
* environment, line 2700: Called die
* The specific snippet of code:
* [[ ${retval} -ne 0 ]] && die "${FUNCNAME}: the
${VIRTUALX_COMMAND} failed.";
*
Am I missing something?
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0
iQJ8BAEBCgBmBQJWWc1jXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiWGcQAK6VSEgzlaUaJ+AEC/I+M+Rz
uHOmaEE005MsTpUf8GoRY35fnMNkICES9QLZjaSjliBJ6H/WdGDGcqm7rg5yx0j5
v12vv3LMrFX2D/+2SkTurMlGj0gOz+F27ted/p9tmJJLf0KcbusPiJvmjybNjNH+
5ksLdZEdnAj1p9qmXfoJ8IlKHO82GUn2cNS9O0XFW9WhSzmOaE+WOp2hQtX0HzUE
Y6vcVjl5ZD+RDvc2+7oFptOQxGyEZdP43JikAEsfISHnjA4AtYHMLjIHvItaVdoD
8qbG5WAwp0fg1BwqNM6G9neAbknKeGIBLXNBx1QxVj3toz3j3QR88RB1nyovGNp2
7LZjEWYW9/jLpXVTLTg+vwsM6IgvehFdErlXEcWR/q/Gk5Q7C86o3oN4RPaQ93HV
ElxL24u/j1CW1mFzXTgKbM4rxlD8G/aROxiKAh5+66ywSrW1SRhpHSYJxriioco3
iwUyZmBtfCB40+DAHl3cX+yxQ/pKMiR7oN67fsx3F8LEalorcONq5w2e1d0bVbgs
EqdlUqxZKyI6fUK67+rI6Nd2ZBduUpm9mTvJHovPMQ3gK2hyRiE6FkhLf53aMR4S
9cmq1Bmqqw3KGTlIu45gKP6NxUr/+n1dg2LYpZF72eKKhPkNOO68YogKS073VEWc
DJGgOFCpJQIV+BLid0VF
=Nh/f
-END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH 4/8] virtualx.eclass: Ban deprecated functionality in EAPI > 5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 28/11/15 15:03, Michał Górny wrote:
>
>
> Dnia 28 listopada 2015 14:24:17 CET, Justin Lecher
> napisał(a):
>> Signed-off-by: Justin Lecher ---
>> eclass/virtualx.eclass | 4 1 file changed, 4 insertions(+)
>>
>> diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
>> index a7f17ec..615ff0e 100644 --- a/eclass/virtualx.eclass +++
>> b/eclass/virtualx.eclass @@ -59,6 +59,7 @@ case
>> ${VIRTUALX_REQUIRED} in RDEPEND="" ;; optional|tests) + [[
>> ${EAPI} == [2345] ]] || die 'Values "optional" and "tests" are
>> unsupported for VIRTUALX_REQUIRED'
>
> You can now make eutils conditional to EAPI.
So your idea is only import eutils for EAPIs where I will need eqawarn
from an eclass? As we have no ETA for that to change, I don't see a
good reason to fix that inherit right now.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0
iQJ8BAEBCgBmBQJWWbV0XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiyCoP/3KdY8bSc6sw89Rs2xxl1wOo
iZX3dFjq8ya8xd2AU4uMoFyJY/SitAl+/dtcmRGloirZ7o/Y7YT2/Z6s1G+GCqOe
fXfivtGTGcGivI7F2Rs4ls8xtS3d4TWUKDR5R70kF8MMSNd+fxTtscqBUSQw8sJb
g1nzUeNFgylUraGsCUGXTrXoPzaFRQYNCipufI4JuvL90Agr8PC6v4TsgKew9WO+
MM/R4YnpFxubF2zw4m5qbIdbn28FVGg0mbuDc/QFLFhNApevMJacQG783k1f1TDJ
99Gj+pPj2TgfyVVnhJYvE7s05v8vmrecX//TOvvdKYXEjoB0IR/pyAtr3rOWF+M5
VjFWL3rfeZbKOEeQ52fRfzidOxR/thBZp/flZoJKLZmJ7baBewkpVGt+4d1KwZCM
/KRm/1snnZY5GnspH/zxa/MI+azNWkjKKS7PW2zbNwBWQ56aiAcA4vBkBfEBfqoR
NbRFyrBm7eEEjIwRHYj5SJuTMd236gnuXEQWeAU5o8HNnh2qiVHjdHnaF4ld/QIo
0n7DYDeJqBeF8D274Ubd4KrQMH9LE2WbKZgNfBxpJdqPRBP6FJhvAtTQW1iqXNpt
O4Lp9FO2jiP54Q6GWYmE8s1R2D1dXbTL10PmhGOec4tRWcrMAo5nlIwriezhHnKL
NAEsc1lyU5vHp9OGwcjX
=yI1e
-END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH 10/29] python-utils-r1.eclass: Make heredocs consistent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 22/11/15 20:50, Micha? Górny wrote:
> --- eclass/python-utils-r1.eclass | 10 +- 1 file changed, 5
> insertions(+), 5 deletions(-)
>
> diff --git a/eclass/python-utils-r1.eclass
> b/eclass/python-utils-r1.eclass index 7617c3f..6fb1ec5 100644 ---
> a/eclass/python-utils-r1.eclass +++
> b/eclass/python-utils-r1.eclass @@ -933,11 +933,11 @@
> python_wrapper_setup() {
>
> local x for x in "${nonsupp[@]}"; do -cat
> >"${workdir}"/bin/${x}
> <<__EOF__ || die -#!/bin/sh -echo "${x} is not supported by
> ${EPYTHON}" >&2 -exit 127 -__EOF__ + cat
> >"${workdir}"/bin/${x}
> <<-_EOF_ || die + #!/bin/sh +
> echo "${x} is not supported by
> ${EPYTHON}" >&2 + exit 127 +_EOF_
Why not indenting this line?
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0
iQJ8BAEBCgBmBQJWUvCNXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiqWwQAJaI+wQ35CBxT7ZSxLMBtA3x
TtafJinkacJBbSzxgXHnQ/RprAoRO6Utg2ijJh3rYxu8LCD6Al/iF23MtcdzhBWe
oU6KXVzCQI5A+47EFDGifD+GHWkIDwcCepKF+4xKpUGSeN4sxLrENAXt4YysjFPo
QN29+zx4IAsCj/EZmi5ViVCZGA2UdedCkbwbhXUJ5hYXNAS1XPQjFvVCKWp57Ayt
Njj4sVgOJB7kWcZYV6URzv1TFPENSbEI3/H3RpVJAQCnzQLDux0Evy5dNlBG73RU
OnX2mXdZYWibIYgLR6zCtZpiOKcmiIOBlx/PZSgT0ylrHsgzPt7+WY3AEZxtcr+X
9Hii2Qb4WfOXAaVIDSIwUgg44AVSKY5yz+IRmQ6Q7L7u4qmQUMs6JEIb4LJ2oCRH
wbmA/D3exiVEGTzeKI3DQnupkpCeEdtY70R38DmI7Jv6vyLI8mvxw/muTaDh2wF7
7PB3S1HPYsfoje+7GO9g4Bq0xVwssn4XqIvRzwO82nbGHCLA8kPT4q0sevl5iUQY
c+g8X4n34re/wj/uH0j1skkx49VNrZvd0HZ7JzT4XcGK6s673SK8pcJLlYzjInpF
IO4PqBZkRkYPPhyfj8YjbtluquPtQExVBAAQOWF/LlZ9AzHhxkgoxv4lwxFK56/l
NPR5/VPzuJOHWB5pcG2C
=XqEp
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 16/11/15 10:14, Alexis Ballier wrote: > Probably those that want to ban it should fix the(ir) tree so that > developers have no pain in bumping to eapi6? Versioned APIs are made to have incompatible changes. What do you like to see? Someone dropping all usages of that eclass from all ebuilds which are using it so that the maintainer can bump without thinking? I agree with you later statement that the eclasses have been announced to be a great solution when using autotools based packages, and dropping it now means going back to the old. But the changes needed are just straight forward, drop the eclass and use the default functions of EAPI=6. Plus the autotools.eclass when you need to run autoreconf and friends. > While I agree we should move away from those eclasses, the "I > decided to throw the crap at other developers with eapi6 without > deprecation period" is a bit hard to grasp. Esp. when these > eclasses were advertised as the way to go not so long ago... > I don't really understand what deprecation you like to see? We cannot use EAPI=6 right now and when it starts to exist, nothing will be broken. So you have some to time to adopt your thinking until you write your first ebuild in EAPI=6. At which particular point do you seen problems coming up? What do you think will make maintainers struggle with that change? Justin -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWSaIHXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiQqgQAJPqJhNCzec5w/wBNhMAI/AO gu086aIIwHoc1mRCPtkgrfY/UhT6unO3U+V+/MBnyRJB5tJc+6AgM//ovt8ctsyb Aylog8w77mT/v9GULq1PPPRIy0p+Eh3XvhxNWdFZgu4BAVde/4b3rQEklIPiwAiC FQy23LQEZh4wG8CldoR6ULBR0CUO8Ff6xNFVqXvgjhnH+I7BehRP47OE5SiiobCK /4bKb9UjKZqnrttagPlaf6DrzidJd4XgHPrhQSoTA6uLubB0uR7EdrwlgYlR3FES LWbT4kO9RG9GZo1y4mrNxGTugiF3OFwJX5UHJT55lwNPDHcUsNhl3Yyjb9Vc9f9W Ro/6x7gY5dchDARy1LU3419tRzPGvxeyKkc6Z21Ie374LQYuhhKQiPzjW6oSc+j2 MFDzjBphdqXuiSYeC608Q3KGoYruV2fSGhqQDdAsSADkBBXktBApOZpjyrYXv6W1 xwN/FYHE21lZHjCTUJQEz2+5fdZ0VxRtQPQKautkB8+rhfobrexafMVYt8hjB6fG JvCTOb5Yo8VpWs7i/Zls5jB87y6uYrSFGlbbCrMu6vO7m/KrhZZjQ9dpHpeQ78qj grhcoxi2xtvfa72j/eVxgDYHhXjoJLmJ/60dsUt75IwAcVhtwEg6OWVowXxAGmgD DNG/UIoC9yKzVxkAaEm/ =zJp2 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 16/11/15 10:01, Alexis Ballier wrote:
> On Fri, 13 Nov 2015 23:53:05 + (UTC) "Michał Górny"
> wrote:
>
>> commit: ad4c142684afb096e8fff2937ae5c5c3385dd22e Author:
>> Michał Górny gentoo org> AuthorDate: Fri Nov
>> 13 18:46:33 2015 + Commit: Michał Górny
>> gentoo org> CommitDate: Fri Nov 13 23:52:53 2015 +
>> URL:
>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad4c1426
>>
>> autotools-{utils,multilib}.eclass: Ban for EAPI=6
>>
>> Ban autotools-utils.eclass and dependant
>> autotools-multilib.eclass for EAPI=6 to avoid them being
>> accidentally enabled. The former eclass should be replaced with
>> inline code, the latter with multilib-minimal.eclass.
>
>
> Not that I particularly like those eclasses, but I seem to have
> missed the deprecation warnings for these. I hope you're planning
> in submitting patches "fixing" consumers...
Probably the developers should fix their ebuilds when they bump to
EAPI=6. While I haven't looked at the change exactly, Michał announced
it as a EAPI >= 6 Ban. So no backwards breakages expected.
Justin
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0
iQJ8BAEBCgBmBQJWSZyJXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiHY4P/0TjhS4isDESbDHkSgcWhdgs
aSexsiCJs1bCaTjGAH2Hn8cPaesV0CO96BMFWgjq/io/B+N1x+h5RbhbI/zXHXpK
I9sziWWI68J7SvumVEtkoccM4bdWDKj+pdsqCnyJYp0qkTVZbUBNK0vpUYBhIQRt
4LMCEZvo9me1FmBtdv5RssqkLw2nqcb3sfsQ5uQ7icdIR1rRp9OTNdT3/LQAOQ3l
nGDz/fZpHOlUhyMdCEtSzv51ZBvejFcuRrSea2jnqOdkcnDwOY8Fo9HH0iv1rVmd
SZkAV4yZSz+0OveisjPhQSa1h/uquv49KLcLp6CfPA5228POy/RhFwGx4ZLRhbe3
tlFUApr4ozI4Danry5SlMu2YadJdf+zPu7e/FLwdIVzv7eqZa8ov8cOHyNICVKpr
JZsFvk/7pyL0TB+zfo/MZCU5KY72HOcmi5yL7FpDyYg0m/0cn6bH+FHN/rUxpuLT
inztt4MThZUb+Oubd40GRpD8xSmhgQYo90Us10tb/6xU5tGD7+ZtvENKvPQsMQgp
Zh0tkzpp+jJpqlJ7lupa/f5EjWxhXefD5fkrtxjTAO9aIU6JoY6MWd3uqKndSwjA
WrdxnX/lPkDSTqLqPYvPxLYebBuAyKojeIEGaF558ELcwUxNRJdK84CqRsNsLwHe
vtEeQFPh0f3cl/+9EZju
=TvwF
-END PGP SIGNATURE-
[gentoo-dev] Last rites: sci-chemistry/pymol-apbs-plugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Justin Lecher (12 Nov 2015) # deprecated version of the plugin. # sci-chemistry/pymol includes the newer version sci-chemistry/pymol-apbs-plugin -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWRLrjXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiJMYP/AkrEAsNp/oPL1K7vg4EHcMF mUgsfnF9qIVjnbil6w72hzBV0dWaHMi2KUGx5srp9ExKZ5FdWjDcrlayEWpgDr5d w7uAcsls1YJtEUVEkJwiOxgFwhS+9qBc+mLt0BFNTRDov62S+tQN18+P752OIz2p lujnOecElJUdzfgIaq9B4ZRrhsgoua/gjqimuoGCzc+CdDgKIV6TcbWL7OZwHxsW sDGqd58U3l9YiJUqPwp4E5JyxV/pNS/4iIMNgco8cLdm/RZ0vTC9mZ5SVYehU5dM clFKYmhaPHz4iwgDBcwEjHDgedbsGR21xSR6xcoSyrpgO5OaRb5juWo1BxN6ED4Y 2WDc+7VPXblOJ4mje/lmRAzwFkfnKcU7vC4w9oGtn+lFk0nMBroL3eJ6Ef6Rc0zs ND/SWaucSazxKKhZ/PbJa1T/FbaL0XmhjI8JRYMFGah/gVz6XDUIpFpNmwhM25xB FpOw0miaTSUxhRBs0u8sVwDXAxKsxu6IuqNk7nFRnAozRr2F2tPGpRyWX6FpDBxZ FXE6mbHUlzFKKW6/cbRETTQeK0f7Dp0wdysz2+ss0PjcLknZKucOV9V/wspGH54V bNyxsqtgb3fnURu3xtcKsi3p6InJIR7XOqIS5gAgycSvlTFbzrm/yhVQ3NAeVhGD W5u4Za9vQiQdxCy88ThS =dfd/ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/pyfltk/, dev-python/pyfltk/files/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/11/15 11:43, Jeroen Roovers wrote: > On Sun, 8 Nov 2015 08:50:51 +0100 Michał Górny > wrote: > >> you just removed the last version supporting python2.7. As a >> result, matplotlib and pygene can't be installed at all: > > pyfltk-1.3.3 works absolutely fine with python2.7. I wonder who > removed _that_. > I cannot see that it ever was supported. But thanks for reporting, I will look into that. Justin -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWPzu7XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmilMUP/2cSXGiVqVxmflt31n4StC2v icOQ5uzmyJDxgvNKa90rGwNjGS5Y/xuKSTPb7aMF61GpuzCAyg4j5XQsDFIq2Low km5GBmfUBHid6veWqlhOXvQ933NTAgT8kk4Dv5rhCfUhwOhKSWS0e71PUohTxAcn QodDBnIdNlei4eqYuoZ27vmE0+fHONhQo+Pe8ihYSAvpMwsQUeGJkzrb2A6RWJxs gs6GpkZc0ekFusTHxyOB30I49b30YczCyWjRa8xUsRXFoeuYd0G3tGrUjmtQAkZw 83blEfPUzmKko1Z/V9DCZUDMaKaIqZGQs9QEBFiZEyMbfKTFecNHDRds1Iammeqe B6T2OugFCe6Hwxmafc5Pkue6MrYbsuzlrGJuVI5CS81rEgcjfgIj1c24mYlFhN3J xtEFXh7L+Fae4JKzvvyOuEMygid4juXDn2B2cqfJASEEi2u3Guc2Ff0GJbmdzj6D ubgtmHa8h8k4dj6kVpcXcLqAbC6iXMY1ymNcSbfH8FKx7fN+inB/tu3ILx9D6/Ht h358tKHHmJu5s9Xj87qxwuE/hE5LEzfLOHOCLAUOGOdblMxPOIyYwjOBvEdGYy6z js4NXuy6CjWPBxkzyWxMkBEpbQP4D/6Y3rQCJO8YNkisNxGDIIZj0HorahKT71jM F4/vkc99+GZvCh+xHqQ7 =wxYx -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/pyfltk/, dev-python/pyfltk/files/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/11/15 08:50, Michał Górny wrote: > On Sun, 8 Nov 2015 06:57:38 + (UTC) "Jeroen Roovers" > wrote: > >> commit: b39f2acde24b95c4be5ed1e83c3a0d71fc58ab11 Author: >> Jeroen Roovers gentoo org> AuthorDate: Sun Nov 8 >> 06:53:39 2015 + Commit: Jeroen Roovers gentoo >> org> CommitDate: Sun Nov 8 06:53:39 2015 + URL: >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b39f2acd >> >> dev-python/pyfltk: Old. >> >> Package-Manager: portage-2.2.24 >> >> dev-python/pyfltk/Manifest | 1 - >> .../files/pyfltk-1.3.0-format-security.patch | 74 >> -- >> .../files/pyfltk-1.3.0-linux-3.x-detection.patch | 15 - >> dev-python/pyfltk/pyfltk-1.3.0-r2.ebuild | 50 >> --- 4 files changed, 140 deletions(-) > > And you just removed the last version supporting python2.7. As a > result, matplotlib and pygene can't be installed at all: > > https://qa-reports.gentoo.org/output/gentoo-ci/cb08652/1.html#l184 > https://qa-reports.gentoo.org/output/gentoo-ci/cb08652/1.html#l424 > > There are probably even more silent breakages (which will cause > Portage to randomly kill python2.7 in more and more packages via > package.use). > > Please *BE MORE CAREFUL* when removing stuff. Reverted now. > I just fixed it. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWPwKEXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiWg0P/1aDLLbZlraf/jpfve4Hgg7Y BlB3VKmlzct4/gxgoyMd6l2qQE1tgViSzydpzEXV6n5l8Lc0xtDTdAUGy3pB9hLT lbWKMQQLfFKs4dW6JaGCUUrjdSv3sGvqNtYY+T9v1yGgEfJJvAjkkl+Le0mAJJ/u BELZSzrW13NRZdF2UEEJCJSTqJwmGyhuAlHHXSEyalSQmmPd+uZp+0xhgICoATG6 k/0h6uJ1//97gx9sMCDKyDAJerkyxNV4U7xFgjHMYEL4WoYhE1LCSfIOPHVR/k/i zJc/hTCYxmncAKsbglVNw3nQmBMsBXAnwYOiqQLkMykGA/aBeFYwRtE65uwzudHw fQUspahRJo1vBln/LjivLoXBlVlE6/62btDsmAFHFar/Q3EHif2UbpUzfoFuKCL5 Ey/yWmXJ81/XO9xafzM4xCrgfa7Uh9UYAf+ZRfhIKmfIFgzZFTCmxcL5/Z9KBOMU 1yFyiuSD5kSW6GtY6oIsia0NgXTBPBf8tKor9XRZaUDlm2k+WLcD4+jAlatYY501 U0gdlAuMCGR4se5/PszsClOvfluTe5K21Bd9TJVelmo/OwQFVwE8XJ7mvCuZdNBZ K1MoNricD7pUYrStrZ3QaD0oV7W5QfB+9OQcmjgEp7SrXd/VtBfxghlxJZ9EQXNN uk68bXFbHULaDwhfzUjL =5nR4 -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH v1] enable gccgo for all platform
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 How about a virtual here? -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWN8OuXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmipKsQALPnDU6VwMdevmupO78LRk0d F5Nu3U6bjEq/roAZYHBEAztFLLG+0fywvvObuhgEloCRpbfhf07QJUdX2LB/n2ep iTGYkEfYYI565SkWF7CXnpE70g88KRPbFDYGgky1jfhmlQrJM5HpnZa0cy+cGGM/ peAnDjCha0pdvJtRWUGdonR+A1dsLso8z+hQmCVxmWqQkZT0rsxAzAVXlpg/3QFE YevCio+ijwMwQV2wzD0gU4EtNKdaRXK1XKgI18UsOBwTYhGOlW5VWtjiixXZVGaC L2QbZiNggCRlv4JuQsW8dEb3p29lQJmtRClMjq7AMjbD6Mzt2aVfbDqkhYLq3gS7 +bGepyX5dG3FVMFAnpfOyH/0+xAzV2L418/mGLJupfJfoF2yXNT76sGFKYsCrFgX iA/dlBsfKhGNoYc4V7JH/ONuUHaMzgLq20opHeOkiPVB2Esv+2QWXQkppwVXQhBq 4w/Nge8HG7rEJ/dzg0ePLwQ6zCq7TafuwV8nTTE+gEfuitleQusQdkjEAHAYFRWH W+L1t+W/W5jtAy6rPv93cWClAsuBTyEPHJpoaxa57cRUtwU1AxRvawKj2XwxrBAq 0h6PYd+qQh46kNS9tdGCEg8PXOdU2QedFPk+4iKrbccGJ6tnaUCt89oFfcBjHn27 NXQQXQoiLv8WA1n3twLg =t7Bd -END PGP SIGNATURE-
[gentoo-dev] [gentoo-dev-announce] Last rites: dev-python/scientificpython
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Justin Lecher (01 Nov 2015) # Obsolete package # Incompatible to recent numpy version # No upstream activity dev-python/scientificpython -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWNiehXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmivfUP/0qFS2mNj3TKJyb127cpGRn1 6A1BWrEnuBkpu3baSB11T/9aL8NgO0HRzO9rhjJ+pbDXBUgExqphefE9vy7zy5GP QuyG7+dan+UNac4WKDDvAuFHpx4Jx5MpnW/tPMAFX7dr5/tTsQitYz8azVeOMVRM t2iqPkUcIYAy6hhQdU2KgT/FYQB9DtTm+MDWeEM7XwIQMcBUDvg8rxv0NihEAoll 5jmXKUJd+3YRGYBJ/INtoDCt88Qg/VUbxuvmDiJSWwLB7IKLsfYlES7hSkLak6bl GqOWWadxrSUwz43yH5hlsjxqLDZBBnLlCh29OTsz2ZZzA+Sl0o8pcAzs9YBv34VA n6ZC5fuvAONu4byQSf1IUK4imqDcg3escTqCijUEuTXJSZlkTD0sQ3fbR5vwRvmj 2ndtsEt+DxE+wXQ6e16nYjoQc9D0+zLjN7xch0nX7uEbUjpFR1llLa7H7KlHxLsP DYLBLo+eK5s8K8m/d2IRAJFT1e73jryK8CqJDAlslQthX1pcwpwQF/vZqsT0rfOK JvMiTqq9QMZVFBq6ILm8A1MZ8kuXauyrfPZdwrKoLhaVnAcSnqHn9I7x2UqZ67vg u7gGYEWhGw7Zj5snzIfh0wZkhnzJp7zPxJlgHXmVxvGPu5ik2Os/Sp9DS6gAYA4/ B2IKpZeam4oOdLkjXpIK =4DLE -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/intelhex/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 21/10/15 19:32, Justin Lecher (jlec) wrote: > On 21/10/15 19:21, Ciaran McCreesh wrote: >> On Wed, 21 Oct 2015 01:25:53 +0200 hasufell >> wrote: >>> Also, my package manager chokes on it. Repoman not, so that >>> looks like a bug. > >> s/Repoman/Portage/ > >> Portage will quite happily let you specify KEYWORDS=":)". > > > Lot's of ebuilds have "-*", which is the negation of what Mike set. > So why is that working but "*" not? > > Justin > Reading PMS helps ;) -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWJ8xoXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmi5PsP/1Iqaux1VzlibKC7WRgmqayS p2yuyPka8qH+q1XGQidMNaXLsGFhaK2+JUkZo8BqbjlsxhNOIPpme55qCUi1MQD1 nvPJuDZu3yvA96EZsNRpeDflqmY/hDs3SpZjP1Tk+25Oy5kzBi5keH2yjT7Vpsxx ynR0q8zFChnB9URg9ahE5NgXmz36rCX2aK4mq7eNWbD6kqgz16bvXkzoHYnYLsl1 mSrYdMNy4g6LkEpgros9VVG8Pft6mxvsN0/X2R5O8RzsPYaQBT6lTGjlp2R1uHCG FOc9JV1KR1E2TklbstN4szQYAWPdngyqCpl67XgxZ2q6LXmnjg/DlXaKokFXezvq K/iz2drqZVXmWN1V6S5bHUhtrgqCG2Ja7ri+t84uaZK/MRZnhCs4l1RGE5A6uIAX np0lmgeZ/lgmvSPlRAWA6cqHzofBTvBdjcOoDCkktvz0i8/k1CnDrxmlReRX7abv X4VAuNPl0L1BJixuFW9LN6YVIb5uLpOpamgekpFRZADsB0eWZMWYEaMMkB0phngl sN6xUkY0q7PP/RKL1nQZd9KMLr8k1WOgz3byp49cmagKkfDJSghm/cDctVxJU3lN N0RvnTaD11j4DAs+ZhbVL173pz5hfeT90sJ72fc2HkgISRhVDxLGpFeEbawEkuNs DndQxeE8y5Er8Rv60eAF =f0Li -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/intelhex/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 21/10/15 19:21, Ciaran McCreesh wrote: > On Wed, 21 Oct 2015 01:25:53 +0200 hasufell > wrote: >> Also, my package manager chokes on it. Repoman not, so that >> looks like a bug. > > s/Repoman/Portage/ > > Portage will quite happily let you specify KEYWORDS=":)". > Lot's of ebuilds have "-*", which is the negation of what Mike set. So why is that working but "*" not? Justin -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWJ8xAXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiAWMP/3BafTzLvjKl3ovDQF9RY74R feZ73xa1UX6BpPaBzGqPG8p+5nlN+1aKrC0AkF/rfT1l46/GVGj9eQrCyMeMVUpb lZG6XU40rozDeiYg1Gyg8TXIO1tARJEbs1dkYsAcKhZcNChlc2/m16fk37SkfBQk wAL1qNCEJSmLe3+cIgTi46u+zoxaroYUKAlhiQp3PHeTBG2DXj+P5UN7IvwhHwHf p23CJQVNZHnGC+SQ0Cn3rCdsPIIQx+V2iM/veJfrhIaofUEfSTzwZU2l6NhaOPNt NUUH932oTOm8j6gqfJRBcdRoY9aG5wTWe2/3tcyIYwY9Z+2vltsVEWCZjKdDRErU 1TfGfo3KeP7oyTJ/cH70ea6tcuoeykD6mdUFIcq34qQ5dDzQxdbltP4jPjxym1vS o588dfVHQeGs7yGl1lCAWtl8BH10BvNE0zdI8wP2X/buP6v2r1pbmzQmDuQRBNlI vko/CSw1bHO1dj/L+wFWT+sschb/Gc9oBwknd7UGmdAeLlRxs1OD7eO9VbRL7AQU Fp9xhae+pLAw1hd2ds/YCG5dPq4TLW4wTXQzTrwWPK3xajab4eea+/xER+V9EMx9 HRSumA0mdN8DRNg0N4yLm2iMYjV/zv4XhmTZuNxw3JBM1xzw2ovCt2EGxbfdWw// x3wSoO287X/GAcVaGqv3 =OJI7 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: /
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/10/15 13:33, Andreas K. Huettel wrote: > >> You should (almost) never commit reverse-merges of >> git.gentoo.org master[0]. > >> Instead, you have to use git pull --rebase=preserve origin >> master > >> in case you get "push conflicts" [1] > > > Which I tried several times, but git steadfast refused to sign the > commit properly. Maybe a new bug somewhere? > > There was/is a bug when you explicitly set user.singingkey. But that is fixed in 2.6.1-r2 Justin -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWGPgcXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmi+QYP/3l6pH0GJrSk1bbhVS5bKOEY m6ConS8Z3tqGAsOdT72Ia5FyAla2VewQ32eANWyx8/MRRGOl9Nrv9LOP1s0Zskaa nGK9PPRX5n+xTLICyaV7Mmq2awhfD7Ao1n1pxu4csCtSpTWivWlW/E9tLj6+oluu KLT4NPj9WOULLEveZzaqRuKfI9uD2JsJw+XGr3TfI5ZDqirvOnYFbwEJibN34eER OS3U8PxiUqxAFoTsf1WovFJbqOMJC3pkz35zfS/FLHPa7QRl0ngYi/tglOJR77MR XevOliNkZ7ukYTft+ODywBS6PF6y9xDUsO1RrtBF2KdMsmvXoprTzFTAOPjAtIhC ipAOPftK23S5vwWQCTnYPJLmaL/15wCfHJ8Bdbw6Zcm/0XLs1HvXYlQuZtbTiLe5 l45Cfh8uGNNuLMeNyw6baMhl6qSVkOIA7FlL58TwNeIrYIXqBYEd11NLia5ZIfba iTpiXxt+6flRxnjiMjZPtuTcXe6WhRTk9qHblmashDYKL03NclYiPIXwkOFEA8C+ +qyXY3X3OmOwvmx4CKJbP6x1AL6c1ZT91ewyL1ZHEV2U4s85z6yfDOhgknbg6A08 nPDCkp+LhDknvZjgKLaSHdGW2nkeyhh+25HRhLm6EgXU3HsRymAY3eiiv6/d/5wd cV0Zur6JKyhkGRLjqVF7 =o+qG -END PGP SIGNATURE-
Re: [gentoo-dev] tcltk herd empty
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 30/09/15 15:02, Justin (jlec) wrote: > Hi, > > is no active maintainer for tcltk in Gentoo anymore. > > Please stand up or try to remove tcltk support from your packages. > > Justin > Hi, so it seems there is some interest. Following things are to be done: 1. Stable tcl/tk-8.6 There have been some API changes, so packages exhibit needed to be adopted. https://bugs.gentoo.org/show_bug.cgi?id=tcltk-8.6 But there are only 5 bugs left. 2. General package maintenance tcltk is maintaining quite some packages which have open bugs from time to time. Nothing serious (except for tkimg, which is bundling tiff, jpeg, png ...) https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CO NFIRMED&bug_status=IN_PROGRESS&email1=tcltk%40gentoo.org&emailassigned_t o1=1&emailtype1=substring&list_id=2929948&query_format=advanced&resoluti on=--- I joined the herd because lot's of science packages are depending on tcl/tk, but I need to cut down a little. So hopefully we will find someone else. In case there are question, feel free to contact me. Justin -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWEOAGXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiiuEQAJf95MtwwwLCX2/84FkA7xWF 2NNdxdBrakK8Hn9UX4ifu+qyFfM4YZEVucKWktlMHjtTt9Ss9UEO/3rkMGz6T1Jg 355WWbVkkbK9n6mMrz3bVL/Iu/qjbTdWvAJygDAIoLugOa3GQZGoP2X2lyHCvVVI 92D8QtasSSn8fGP/IpzA3hlLCb0iOQgegla0UAtmFS0K70+HOne3476ZMKIdHgCn 8Hk0VPb6QVwykOQUg0qZaOzD4koqc7YlimmVhwIqMswP5F7Ilppt2c442fO66LZb XLfR5mXggmzz3mTumvQj8ezNNstvjO7R691D13xAve1L9O4raK7INJadBRGjOoTE 0s09JQMtUsJX89FQsYCyJ8eZmhJTHSA9Ynb84LjmPc5w85WeZHLqOnVNyyV6mqXU L0p8U4+POxAUX0iMz72sqAfAnnbN5UDvG2oAMqNz0Oz8cVlrys/zxHKI+g6QKTqX 14sabHJLCpyRI6pqLmqrBEhg57BRjGme3xX6EfA5djQqh6r33mHQ0MY8Esmq7kAQ lflhErXcOHEEUKgDjrsTbsdATB5f5C36jKBK7gdKiz5JSZnIrzIyKmrNvYi6IOtF ykzYXhUEiMTtCB6PtRKUdMacr/60aE0rWdTk2zGyfjEmlU7dsB73fphyhcSZNWgl qvkS5rFjvuqviBy+Vpak =hHni -END PGP SIGNATURE-
Re: [gentoo-dev] obsolete remote-id types
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 26/09/15 14:58, Michał Górny wrote:
> Dnia 2015-09-26, o godz. 13:19:28 "Justin Lecher (jlec)"
> napisał(a):
>
>> Hello,
>>
>> I will drop gitorius and google-code from metadata.{xml,dtd}.
>> Any objections?
>
> Shouldn't we wait till Google Code is officially closed?
>
Probably better. But gitorius can be removed.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0
iQJ8BAEBCgBmBQJWBqDfXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiVjYP/iFMNqo9rr+phcAsG+v4g2lM
UfK0TgPbOfBDfdthsblGnkP1Vg4vxvnyYB2gf2F+xHlt69JON9tzbLglfX/4s7UT
mGzqVc5NiOpZFxhUWxgzJH8SUhnZRS7jGrIp6RRwR/DOWUqNT/pcVgvDCxf2qyz6
kqWoAfXTN9HXw7XLVEVqFy2eviwi3XS6N4cRl2Raohcz+E2YzCveMHhM4krT9p08
oP6mxjfDcidDl08HKXlTap7MGUfoYlWX9HDbIe2/u5xzMNt5iFnJ9kEZa0CLmXt0
D9Bvrk2pdZRl9pIyNz1HeRwd5r3+vtp3B/jCa1YliZ+VmJs0m3XdPduSUcWYCKF+
CetAq8vMyeTDA2sVZ8oIrhvtVRagEE71EAsAlQBynJPZqqqF+ozAiG1nhyF/6qNG
kgj/kxz5bxV5EFgpaXs2vFdoz9eLoRSTs0eRNdRLtML24SDFTgBUBqfHdud/zEL3
5Rs4knBv8AOujPFs3uHAyeDE6UXuyMulaMgB1QyTZL/P4d6HydTT/W1C3qpHzHKh
uzh7S/2Yx8RYj8abSxuQnNIBAm0iC69L4KTU7jVaQ4siwBj4WpXB0Vr+RLkCQrOc
VVj2b6SqnT25aKDQuzGvcBbnP4XfHUtnZLGaqBj/lNPu28Wzxvlw78c/P/2HcArB
UBK1ItU3Wwqg/KSCbWU1
=O38X
-END PGP SIGNATURE-
[gentoo-dev] obsolete remote-id types
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello,
I will drop gitorius and google-code from metadata.{xml,dtd}. Any
objections?
Thanks,
Justin
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0
iQJ8BAEBCgBmBQJWBn9AXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmi/usQAI0RvTbqQI2AL/zW+/cWVrRa
OOjSqdPtamBpc/E53jZPmwlhnn0eVCwFFrUROGi6+trvXNwFup/8sWCFThiFscvj
Oz1gzqy9KFBl3wpCUtluJCMafQ9EAQ/3m4gL4CD8li0i7GWbVqjA0wTW5pKsm0Mn
XwVjzm4/Se0YBAX0blc2YxU/luEZ9nO5rIpIuV4qb52f82J2NWnLGfcQQ5rvKL47
gKhfoKPMcFF41JkoZji8rIv0mLbiYQd3rzUPqI3iV75lXcbzmHTVxYTPXSAC9/xN
SJ1YZstoGNBBA6C0XE75GQzmozQMXGT37cLjrAuJe0oVxUCb+8rc4OWuzaqm9yl1
LBxrmazSZjwJI1IBiURVPvDkpryC3I+aKTB6yMEO5Ju6pzgKSi0HtOXFuzTqKyWP
ROSW6I1a6jSghWBQ863Y+Aa8bon+QRLdT+H3Dn320URA8NgZoooM6R6hIVp8Se0P
MBo2PAfrimnhVGVgMADctupuKUdEvOQgSv4U+OuT4ZfmBojfFyLMtSGY/2AvvkO+
GbBtqYUMEHaocLaWW3WizZUj+K401W4Y/2aLg/tQnEIJgkgTpxaJs7YkjnVteWwM
Qch9D7E2QKEn+0eFEh1xZUKZspkWKSoOV6KLPNp+xEIdt9s9SdLbC/EjFDy2ByGA
j8eUqHu4J7/w2m9IYITo
=/MqA
-END PGP SIGNATURE-
Re: [gentoo-dev] Updating all Manifest to contain SHA256 SHA512 WHIRLPOOL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi there, I did a first fix run. https://github.com/jlec/gentoo/commit/0df86dcca0aa981fa7bdba633653697e2b 40781c Although my script checks whether the size and SHA256 changed, but better you could also take a look. Thanks, Justin -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJWAaq2XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiu4oQALR2JdGsAYF9UoTefwH6pic6 LZQWlkiMrvAY8SvsE6g9gW9IDzSzuZtbi4EgN0nkvYWskN9KlyUyMOQH/snbpAsd eiijG98pFNqEa4nBJBDuBUjPPjZ8M30i6/dsHMEW3HCgi73Va1Rr/6U5l+eO111b W578EhpAqcIhRenr9ssbUEA0EdTKsZYdbtpZDGrrXy9+Zw0ZOwAXqQyeylML1kJN usr08KHyqi9VMom19G1EeENO9XTKU9hHoCkHjSnfsl/Zi3KJT7VQXhBLIEcxuX8m WeGQ+tGA0Ih1G1zNfepUle3eCV1gaXu6h+m+wUDk2enMCJPIFtDUbI/gDOvf3Gny uZhl9MHFUcYuGiroAXHiZUEGvvhjDMXwciUavvsR/813L+uqt+rgiDA7YMNmVjeV dACcaxH76zHweHQh5IKm4V63a2cuwLvpq6WVviiwUPNrI32B4C8WAM79SfbQDILL Il4QJvTYJKLfgcz2RCsnfBIT5jdvrmJLD6yozGpHP8/EaBtiAhvtAkT5H7JTv8yv /9QR5rMoEQczeJGJVV+nPvSePZs1WxMAP5RraElL/Jdu7nnZf++WD/H9YmnvXZfi TJqOyETEJ+tisyx5z/EXaBAS0hZVl7Hswu1gItZoiDEF0FdOgvJU0tJA/rOSftmB Nv4KyknRPPm8pwcAn4z8 =WapW -END PGP SIGNATURE-
Re: [gentoo-dev] Updating all Manifest to contain SHA256 SHA512 WHIRLPOOL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20/09/15 19:41, Robin H. Johnson wrote: > On Fri, Sep 18, 2015 at 10:58:22AM +0200, Justin (jlec) wrote: >> Hello, >> >> there are quite a number of Manifest still not containing one or >> more of the three hashes. I would like to update them as far as >> we can download the sources. > 540 of 17841 Manifest files have the problem, about 3%. Quick way > to find them: find -name Manifest |xargs egrep -v '^DIST .* [0-9]+ > (SHA256|SHA512|WHIRLPOOL)' |cut -d: -f1|uniq > >> Procedure would be: 1. Download package 2. verify current hashes >> match 3. Calculate new 4. commit >> >> Following question need to be answered first: >> >> Does anybody have any general objections, remarks or ideas on >> that? > Good luck finding some of them; there are fetch-restricted packages > in that set. > yeah, I know. I will try what I can get and will put some information up on the remaining packages. When we have an overview, we can act. >> 2. Any suggestion how to do this? repoman has a manifest-check >> function but that is not functioning (bug filed). Any other tool >> around? Perhaps using pkgcheck? >> >> Ugly hack would be, tampering the downloaded sources and run >> repoman manifest which would redownload the tarball and check >> again. > I tested, and this worked: ebuild ... fetch ebuild ... manifest > tested with dev-scheme/hop/hop-2.0.1.ebuild. > > The distfile was downloaded, verified, and the Manifest got > updated correctly. thanks for confirming. I will do an extra check that the present sha256 sum didn't change. thanks for the comment, Justin -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJV/vY1XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiZb8QAKhAGKo1gKZxILFyhU+Az5l3 VsJeJF6F0ZnclgUQSDKaqY06VxTjsG1W9SUDx0VYrqfJcSkIODZ55RjCio22f+tP 6DA5z6sTwcBOcRIunWjjWD4rHrSgHj/HodzShFnTdSt8R6hzFumZWRaFXfN1DUj8 nibH3n1o6flAm8eV7ZxbypZ5Y1QOtFqxJc6fuHLeeSsJwu1iph/OnNagdx3ZCU29 RsiKxIjjWDLtew2BWCSSNTD7ORLNmogTis5xRAuQXevvwZ+wtXGhUNQmb9tlWkHW O0ndCVtH3+yiEPn+s+2TRbnYE0KE2Ce4vnGsmq1zuf0zzwXhKmgPNBLVihHU83nF M0bWPvqM7bdIGKZmdhfG4HOY0TE/9HZ7SHgr7u3OTgy+cqvouDoQf3XROKO9cgRQ iVMsNwjWJe4wZs5LAfgq0ancNZKHN0iorp0nDbE/cvkMUf5MkB/v3fz/C7XnYcFg 54f7uluO2NQDv6852iGE4usYECQByHdZ+eU0ZPyPw/elrGbhaaBN+h4SBoVd6G4d vgpUTBCO1pVSZV2Rwx2AeDEin0An9r4+s2wHi0IXI/p0yQbLQ+rHCQpOpK72HrdH 5O8dVr7zNiI96Qd5iN04Q0gNyTrmaSAevsNdhnLxouwlclKhtRY7tirlcEZQ7t4V Tlv5pykl8ITH9g5IS1yf =dwyV -END PGP SIGNATURE-
Re: [gentoo-dev] Always specify SLOT we know a package is compatible with (even if only one SLOT exists at the moment ebuild is added)
On 19/09/15 12:36, hasufell wrote: > Hmm, you are suggesting to do this even for packages that only > have one SLOT anyway? I'm really not sure about this. Depending on > the SLOT-naming-scheme that will be introduced it may require > massive changes as well. It's hard to look into the future. I > personally think it is enough to do that for multislot packages. > I think, pro-actively considering the case of new slots makes sense because of the reasons stated. But I would suggest that we should go for "No SLOT set, the PM assumes :0". That way, the SLOT is fixed and no upgrade to the new version would happen, but we have lesser amount of SLOTs to set. Justin
Re: [gentoo-dev] symlinks in the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/09/15 15:19, hasufell wrote: > +1 for banning symlinks > mrueg just mentioned a very crucial point. There are filesystem which don't support symlinks and would break everything. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJV9CkFXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmi1ZoP/RwfCG1w0Rz9NcMx+ZSI2BaU sQ5AJnvGK44G3v+H7gCz5GtdHUVkFcKzZ0o6FPQnBeSO4B2Ja42d4Sl/L5Hp+K11 h3lMzqZ8t4d2g+d5Vdu4dSt2doPwH0hPQmSZJ3mUUtTZphacxo3iAL1oYZ6c6FKw thU4Cd52VLVuYIzekFP3pqW5g2iAyOKP/Z2+icJ8ljF9Y1NgdHjqDkKHLZ7U0cHt RmCj0K6xctIH+nJ5PEIo2z5EvJqMb7f9B8ijkCGAZFu8mWI0BBma+OSnPvF6zjtF e1X6IP7B7j2q57oRCHpnSG19T1wDnfJZaqZD+wpUb4EV6ITme8E3JT/4OG4OJF/0 W7/dJHYNkEAbgWoDjagsEQNuqda3BbOyv6IoXze0CUlTkGwW8wOVDUhPPnTBF8JL Yf9WEbbECT4sRSi8ZdaUd+8M0b1gnazPBdRHCndxn530mxdicHZ6Ereup7fhRUPx OoqvRNHJhQPX5UazbBhw/YyFq7Y1G5dg1kvZFuv50Uohmy4D1plE1dyPg0hdFwRB UewKUl5j6CA2VKUTBFsdSBMhu/KRG/Bv4ThO7vTKhqITTwAoUXpTmLO1T7FoadIe 0DohHo3lMg2B45f0aRq8rMcgGFv8LGa5hYAzy11uU07CVHAWxfIGkMUFUvwVo3cO PsyI27ZZVfrE38MflVgs =4NpN -END PGP SIGNATURE-
[gentoo-dev] symlinks in the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I would like to discuss the pro and cons of usage of symlinks in the tree, which are possible now as we aren't bound to CVS anymore We have quite a number of ebuilds already in the tree defining functionality for both, regular version and live versions. These are typical candidates. Same for different package versions with the same ebuild. What is your opinion on making heavy use of symlinks here? Personally I would ban symlinks and duplicated code. One ebuild for one version. And in case you like to propagate changes over several ebuilds, just use tools like meld. A drawback is that tools like sed break symlinks and write back a plain files. And last, we have potential breakages if people don't give enough care when doing stabilizations and removal of version. nevertheless, we would slim the tree and reduce work when changing things like HOMEPAGE. So please discuss this matter. Justin -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJV9CSoXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiIZ0P/0q6jSuGZzZ4lDiu87GIYMiC ndRzHsR/OGT9paB01pkoQogOt9+AMKdNd434n2to+HbuNf7Le5cWP7MBAdD/ydzV H+5zE98Mu9h8IXTRvuxv6eTSRPFsnnDPuMAS+28D7WwDBcmOhl4we/hRyfq0+JFw s5XojNlrk7YZLynZs8SHcgqq5CbaKbjLMsVSTnVXKeA1NcaB0lPFjI0JraCqW4xS BgIA2MrrR5XM2imvmBInanwJZ+VOVvHD1jxTlfUQeF7qJusTY5fTnVncvnIo72Fh E2Rz/+vrWFe+CvQV63IpgbtC2oYP5OMidnfZSQynRbGsK9w3rm25cXOlyXjLA98O sv/wNHvVk3+SIvIviN3yDjOOG5q1zeW33UtZfz5iKu3E7dUGw6B2a/qjC9m9lIQH GGDu7csYnW8aSLiEJPGsJsduTqw/+G5p8DWMGuHss6xu6DyZKJPRxgd4VlDkLIiE ZCgoHCGhQX3LDEOlzh7+j01A1AOO4SfTZqqDch8f6jiLYmx0dw4Rcz6Lth+cAzn+ fjTdq8A1P5umV8NiwGZtx8GtPoEWRpEV0zuhZHWXjvFSIxpn2TBUi+pETo421wXH 9QDQD5Q/9Wf/Wckyb86+OEhwBGoPXib2sF1BOTWONXHECvQ5xuqXy2Ux34HJHbou Que3NfC4OiQKXSJv1jae =K93a -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: using Ninja in more CMake-based packages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/06/15 22:14, Johannes Huber wrote:
> Am Sonntag 07 Juni 2015, 17:08:57 schrieb Michał Górny:
>> Hello, developers.
>
> Hello Michal,
>
>> As you probably know already, CMake sucks a lot. One of its more
>> sucky features is that it generates Makefiles that fail a lot. In
>> particular, they fail at verbose build logs that are cluttered
>> with useless CMake intermediate commands and hard to read. But
>> also they sometimes deadloop hard in faulty dependency scanning
>> [1].
>>
>> Those two issues can be solved by switching CMake to use Ninja
>> instead of make. As you may know, Ninja is the fancy building
>> tool that is faster and much harder to use than make. However, it
>> integrates with CMake much better and with less hackery. In
>> particular, the verbose build log is free of useless CMake
>> percentage printing output and other non-sense, and contains only
>> real build commands. It also gets dependency scanning right.
>>
>> Sadly, there are two problems with using Ninja:
>>
>> 1) it will not work with some packages,
>>
>> 2) it introduces an extra dep (on Ninja).
>>
>> The first issue is a bit complex. Sometimes the problem lies in
>> CMake itself (not all CMake magic works in Ninja for some
>> reason), sometimes in the project (relying on Makefile stuff),
>> sometimes in the ebuild. For example, with Ninja you can't do '-C
>> subdirectory' to run targets from a specific subdirectory. So, we
>> can't force Ninja everywhere.
>>
>> The second issue is a bit easier. GNU make is part of @system,
>> ninja would be considered an extra package being installed. Do we
>> consider it fine to require it randomly? Or do we need to justify
>> the extra dep by benefits of building a particular package with
>> Ninja? Is sane verbose build log a good enough benefit?
>>
>> So, what do you think? Should I start switching random packages
>> to Ninja whenever it works?
>>
>> Oh, and this would be done via something like: :
>> ${CMAKE_MAKEFILE_GENERATOR:=Ninja}
>>
>> before inherit line. To respect user forcing another generator,
>> and to get deps right.
>>
>> [1]:https://bugs.gentoo.org/show_bug.cgi?id=546336
>
> KDE herd maintains ~1000 packages and the majority relies on CMake.
> I am not aware of any reports about GNU make related build files.
> So i would vote for the reliable GNU make generator.
>
I tested ninja some while ago on some big cmake science projects and I
found it to be faster. So I would vote for Micheals suggestion. Though
I also never faced any problems with the makefiles either. It's purely
that I found ninja to work smooth and fast.
Justin
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0
iQJ8BAEBCgBmBQJVdKc1XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF
OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiDBQP/R2vvdQGBOUGHX5wNHCjJxoy
XPQdJq7Y+ihrDj+630/EIzvncZjLXpJ1r03ftfQ8Km38m1dIL9HHVIX4Z6NHokwe
bmEs1VAQk+3NajmzB4Wt6xJoiIPiQiIDeNLAYhe8MVL1qK+LW5sgC8gV7PWwau7b
7CsBbPJOE1Y/rcjc8B3c630hE8WXAfQ1lnIBR7EzNsnNwTp5s8F4u7JktZSKkSSc
g1545i8EBaV2eHeEatIqEpB2oGDp2eDZjeLny7nlCU0FO0MfFFsTWBXEJHUDIto4
ammwydyWLGBACU97jBkoePgSp54ekAW3XdtMFG9KT7/rArtgDY06wWFH2BqA0tcx
qYGXqT1QBzjjUmTyQmHflKv3Zx233RD2h4J2g9A0wE5CKZViKdfKWADG0tyIRlOI
ooZKj7sp/iKZbgQqVdHPqySw7clUFi0LGUr7RQr/RUC1z+ROSb+x+dCkSV9ujPSF
A8acKoEu7cjjGU4P/RFiWbHR/czMXiv21VmAvD4sdqibkYlfR/YWyctz0JMzfIdz
tB6ZDpedB3Qsu0tTdlnOYiCMpoMH/ZBK3vjLcG/72BkqjyyD32xJu1KVVARao+ZQ
4cOxNXDA35yeOnZ77pNLNhkS8CToGuijqtUdkDhYq+rhLFOkNcTbl+fR88UuTeAH
ZwGZmZGkP1jubaDIN+NL
=17Cu
-END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Indention in metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/06/15 14:48, Andrew Udvare wrote: > On 07/06/15 05:12, Alexis Ballier wrote: >> On Sat, 6 Jun 2015 22:00:14 -0400 Mike Gilbert >> wrote: >> >>> Compatibility with sed scripts is not something I care about. ... > However, I do not disagree an XML parser is better than sed for > the purpose. There are plenty of XML pretty printers. > So you guys think I am using sed for this? Really? Still you need to tell a XML formatter what indention style to use. Justin -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJVdKaSXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiepMP/j+/jp2yP0Jqj8UKzbTkWbND 2cD2fJdn5op9rfbAt4NuVFofU3/MbnaloITsadHNV1j3Nz9fX2sTB4sr5GPrRNfj K+nqdLA7TCsCY0OVMGerCEmkCQ/pfzmcHjm4G3Ktx8GDmOPD7dkt5abMez2phz+A uXJwKrLyQxk/o5OxuryMU1VFLw7oyDRgbo4tJi8Rp4ZCeeT2UpHmr6T1wgrhgfk3 K59kN3NPz86t7u/9sRSD4RteGZrLrisAXFzwMkiRvmy7ZtPRgbao5zWronqOPe7Z N6yhCUXqaWi3aRS0Rx+Bfn6QHwVat4xTYVcNV2DIN5FWAiwe1PS4zKSi1cSts7rU 6ARAOkwz3DZ6v9PFT+y2QawGvN6Ve1TEvKsl5gmFrhOHaejiNYE4EyF7sYt3aqmk hv2Wh+E+q6qjYy6ghOUuMgiCNHhAw1966nRPMJF8H1baLrTZSZU1E+MGYdx0EcFu EmsnHGqAjbFFVtesTf+FN6KDf/YOeppt8ReKJ88SY8zy0z5AwQ4tUC+DcnGukFDt n1yz+innTSgVce0oKdB8dheaBliTu6aNXlee+9jya1gevijb8axM9Q9xK281Fa8j rewFaQHqxmXVKkACTavcskDMrW3OQMs5to60yTTXnRxyja0riJ8a1xlG0DwAl45h COAKrMqMqsH93qw1TD1w =a8iK -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: Indention in metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/06/15 17:21, Michael Orlitzky wrote: > On 06/06/2015 08:22 AM, Justin Lecher (jlec) wrote: >> >> * linewidth >> 80 (why do we have this short limit still in >> 2015) >> > > It's ancient typographic wisdom that the optimal measure (number of > characters in column of text) is somewhere between 45 and 75. It > varies somewhat depending on the typeface and the leading (spacing > between lines, more or less), but everyone agrees that anything > over 80 is uncomfortable to read. > > There's always one guy who will claim that he's perfectly > comfortable reading a single line of text that extends into his > kitchen; rather than argue, the old 80-character terminal thing > gets cited. So that's not the real reason but you still hear it > because it's less subjective. > While I generally understand and agree with your argument, we are talking about problems which arise because of indention adding whitespaces in front. That means the effective content to read is much shorter. Plus it is markup so we have a significant portion of the line being semi-important to read. Justin -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJVcxR7XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiusEP/3w9ldEOGD0HwUThJwN9m+3+ EA415TX0onbq2zOG7nj+8DvNHj/TAh/wz3cP+rl90D1q/fOdRGV9hHpQMeAhQVTT f7zpE9Kf9Em6Cv+DZMnK6HYWm9n51cDtoMVZZvKoyOwjM/kmAvFjwQx8EfYrOJ+p Ch7ceEv7j3TORWV6QynFtLSQtCvBckvgNwnuIHmyUfi+begt+LnpgB8Is4HfJgQr 0YPmP+pZFl0trmKQS6vyHTpEK2HqZ9OPIPFFwA6mjABesYe+qTt9FDgTf+CPzHVo rSM6F+82p+ZybShH+K7NNWKT17X0ePQf2+mKoSDVspft12+QKrZ2ceJnr4TOGVK4 mwYYkxcPatTNi5dkEL9JzQxiq5+hMPsDYJJDHdMldEmaubW5mP+0t1o7KPugQxF+ naX+Dxlbd7murkXOJw+9/3R2DlXLxPudlkTbggINSgZsa6ZQQnB3A/hFh+FgANZY +SPBpgGKTNVf3I13DydIVtvzPgIzHd69xD3jrNFD/wjHr78Ot/0gnpw0Sf9O6eeB Mbjnl/I2FyMzKA8y1kVlCCcivm88VrdPzt/E0yoRxKjCxaqzyrMzCpk5XPzpfR2t mJOYYYBoBsojDEtqUAGm30d6CJ6tHo9ChnFt8zFc7MNECwLyEqZe6V68IC7vifB5 Jsqwbqrsc0tnwdaJfKMA =q6KY -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: Indention in metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/06/15 14:07, Ulrich Mueller wrote: >> On Sat, 6 Jun 2015, Duncan wrote: > >>> *If* we should agree on using tabs, then we should also >>> standardise the tab width. Using the same rules for indenting >>> and whitespace as for ebuilds (i.e., tab stops every four >>> positions) suggests itself: >>> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html#i ndenting-and-whitespace > >>> >> (Somewhat) More seriously, standardizing the tab size defeats >> the purpose, letting people decide for themselves, particularly >> when it's to be the declared horizontal spacing standard in a >> file such as this, where mixed spaces and tabs can be avoided, so >> someone's personal setting shouldn't be mixed up by someone using >> spaces instead > > It plays a role when at the same time there is a policy about the > line width. For example, the devmanual has this (about _ebuilds_, > not about metadata.xml): > > # Where possible, try to keep lines no wider than 80 positions. # A > 'position' is generally the same as a character — tabs are four # > positions wide, and multibyte characters are just one position > wide. > > This would make no sense with the width of a tab being arbitrary. > >> (and if it is, the non-standard spaces in place of tabs is >> simply much more obvious, allowing easier detection /due/ to the >> non-standardized tabsize, and replacing with tabs as >> appropriate). > > I don't understand this part. We would have either spaces or tabs, > but not both. And e.g. Emacs can highlight tabs (with > whitespace-mode) so there's no problem seeing them. > >> But IMO it's all simply bikeshedding, regardless. > > Maybe. But standardising it could simplify life when updating > metadata files with a script. > Exactly, that was my intention. How about * indent with tab * tab == 4 spaces * linewidth >> 80 (why do we have this short limit still in 2015) Justin -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJVcuYOXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmigYkQAIGipC0pMA0JcMTu4aoTM+jj 5T8QOd+zh7SxyuELiie6ZJV+JsccyXZsFZjqYOHptVfqsOuLXlhqv+mC/iAH/zjg pAqyA1BYbuf8D5j1liF7t85CT8K4C9gUfNOjIQbVMqaLubEO4+Kzc8ik+LQ4O9Ca 06Sp1bwtBbcNNzpsLZ/Xa60uCGWgdcopcLEujtP34AxSVfa9NgyWs7a1ceRKMv8m +9T3WryOB6dzLQu1da+nUIOnlkwxau0mlDuwA2F968F5ewbophRf+0Tn5FiSu/zb D0wm3LX0pPIk/l/r9BN7mZHh/yokO6iyMcGhSUyNdUys2G3b2LvOOoXW1MfX8SWE YlZVZhzpImG/yVJu6dr7LSHmXo4NNZ8ZZb7uTgKM2NvyO3tX0BZt8RyAXipRP5+X YFuXDf70zagnuAe/iUfw8+vFqb+JzShAvnD7DI7XpoKOkGl1W5XN06suDzUsSRfx F9lFUk4kD2Xwp0zZpTBncCAzcidSbikUQM/CaBATg+62PwvQisvSBtnz0+eGUSMI iUPj8fJhyuZCoYOPEq+wvTdQwYfpd8PLhKxlTEjDb2qY6uVbqxaznE2A6tmkBG9K 5MriinvGOkjdfxvv+rNwPiMDrnaTgljuXEg64mgUz/7/3m3jb1lyYHMIzoiJpIBH ynDhu68FZTXb+RUVc2wo =+HgJ -END PGP SIGNATURE-
[gentoo-dev] RFC: Indention in metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi everyone, Can we get an agreement on how we are indenting metadata.xml? I like to properly format and indent metadata.xml, but without having an agreement or policy on the indention, I make unhappy by choosing the wrong. The two options which are already suggested are * 2 spaces * single tab So what should it be? Jusitn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJVcqCPXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmivxIP/3Vdv8fLVThtEdjknncX8txq DSEj1m+pEqVw53noSQscbvjRkiAiGg50xtZFC5zcJVC7cRSIAADGUByakt7w+Lmk D2cHWfQLJr5ZqGMholHdHJC7G7PXDJZ4D90Rt8qL7I1aGjMzWtGXzkzx2+OD+j8F jy8XAa2I30/Rgof+fsUp1mgglv5c4Y94CbJcnkbERuyxA5miB2d1E3i3iiIcoLmB M2fs0DN3oOQT8Fhwp2fJhoRH+aXlayC8o5PbBEKc6xGU5nfvtfvqqGHa9eoqLgXv vpZXIwKm9vujXoPi7DDBMKAPPqDD1OSKBV0fvbwx0Q94H7XzmSmtFW45gPdAyrF2 rwL3dlLcswDsblv46LHmj+m3/VFJagSccrKaH/I4uf4z2+RhjwNO2R+Z66/EYH3n hvoYWQTx0Y+YI2kKKpXymK5e9ZgO7x+dxBHwLpa13JcJP0sMESQbN4jmJ5Rob0xV bqtTsn+/O/rB1iMMC2V1fq3cQT9AQZT3OKnyiXM6nwLDgae30cY4gCUkOqc/ULxp Eakb5D82HlSWIo840BXNAoGOWI7vFrtaKndDukWn+kKk1SeKm3j2ocwzQ7Rzxsa8 60hfE2tsuo0wQBLxslxYyZnv/kPBS9PS8RtZrLpS5V6D4BGS/32zuBVhN1eP9dQ0 dz0kj1uvehcz5/Dhgms4 =e7QN -END PGP SIGNATURE-
[gentoo-dev] Version Bumps
Dear fellow devs, The following behavior is not an appropriate procedure for a version bump! "Seems like a trivial version bump, simply renaming the xxx ebuild works." Please check packages more carefully e.g. comparing configure.ac, Makefile.am, README, INSTALL, setup.py, requirements.txt and what all those names are. Thank you, Jusitn
Re: [gentoo-dev] RFC: new eclass emboss-r1 (obsoletes emboss and embassy eclass)
On 21/02/15 20:36, Michał Górny wrote:
>> # @ECLASS-VARIABLE: EBO_EXTRA_ECONF # @DEFAULT_UNSET #
>> @DESCRIPTION: # Extra config options passed to econf, similar to
>> EXTRA_ECONF.
>
> Similar as in how? That it must not be used in ebuilds but in
> make.conf?
Probably missleading name. All the consuming packages have a >90%
identical buildsystem. We thought this option to add an easy way to
handle the rest. But this should be an eclass/ebuild variable and not
used by the user.
>
>>
>> case ${EAPI:-0} in 5) ;; *) die "this eclass doesn't support <
>> EAPI 5" ;; esac
>>
>> if [[ -f "${FILESDIR}"/${P}_fix-build-system.patch ]]; then
>
> This looks terribly hacky. I'm not convinced you can rely on test
> like this working properly in all cases, and I'm pretty convinced
> it's a terribly unpredictable form of an API.
I already thought that this isn't the best way. This means, always
running eautoreconf. As said before, we can be nearly 100% sure that
there always be a reconf needed.
>> SRC_URI="ftp://emboss.open-bio.org/pub/EMBOSS/${EF}.tar.gz ->
>> embassy-${EN}-${PVR}.tar.gz"
>
> Why PVR? Why not just ${EF}? :P
Upstream sucks and updates packages without version bumping. so we
need to have it more fine graded.
>> # 2. Patches with "${FILESDIR}"/${PF}.patch, if present
>
> Ugly API, I dare say. Prefer explicit.
Agreed.
Thanks for the comments,
Justin
Re: [gentoo-dev] RFC: new eclass emboss-r1 (obsoletes emboss and embassy eclass)
On 21/02/15 20:19, hasufell wrote: > Justin Lecher (jlec): >> Hi all, >> >> we got a nice user contribution which fixes several bugs and >> potential security implications. As a result we need to have >> changes to the emboss eclass. >> >> The new eclass is simply move forward to use autools-utils.eclass >> which results in quite some incompatibilities to the old one. >> Therefor we revbumped the name. >> >> >> Please comment, >> >> Justin >> > > Just a side note... since people want to even set up a review > mailing list, we should make clear that attaching patches is not > the proper way. > > Please inline them. You can also use 'git format-patch' and 'git > send-email' or copy-paste them (make sure to disable automatic > line breaks then). > Sure makes sense. Will do in future. My email client show text/plain so I didn't thought about it.
[gentoo-dev] RFC: new eclass emboss-r1 (obsoletes emboss and embassy eclass)
Hi all,
we got a nice user contribution which fixes several bugs and potential
security implications. As a result we need to have changes to the emboss
eclass.
The new eclass is simply move forward to use autools-utils.eclass which
results in quite some incompatibilities to the old one. Therefor we
revbumped the name.
Please comment,
Justin
# Copyright 1999-2015 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: emboss-r1.eclass
# @MAINTAINER:
# sci-biol...@gentoo.org
# j...@gentoo.org
# ted.tanbe...@gmail.com
# @AUTHOR:
# Original author: Author Olivier Fisette
# Next gen author: Justin Lecher
# Next gen author: Ted Tanberry
# @BLURB: Use this to easy install EMBOSS and EMBASSY programs (EMBOSS add-ons).
# @DESCRIPTION:
# The inheriting ebuild must set at least EAPI=5 and provide EBO_DESCRIPTION
before the inherit line.
# KEYWORDS should be set. Additionally "(R|P)DEPEND"encies and other standard
# ebuild variables can be extended (FOO+=" bar").
#
# Example:
#
# EAPI="5"
#
# EBO_DESCRIPTION="applications from the CBS group"
#
# inherit emboss-r1
# @ECLASS-VARIABLE: EBO_DESCRIPTION
# @DESCRIPTION:
# Should be set. Completes the generic description of the embassy module as
follows:
#
# EMBOSS integrated version of ${EBO_DESCRIPTION},
# e.g.
# "EMBOSS integrated version of applications from the CBS group"
#
# Defaults to the upstream name of the module.
# @ECLASS-VARIABLE: EBO_EXTRA_ECONF
# @DEFAULT_UNSET
# @DESCRIPTION:
# Extra config options passed to econf, similar to EXTRA_ECONF.
case ${EAPI:-0} in
5) ;;
*) die "this eclass doesn't support < EAPI 5" ;;
esac
if [[ -f "${FILESDIR}"/${P}_fix-build-system.patch ]]; then
AUTOTOOLS_AUTORECONF=1
fi
inherit autotools-utils eutils flag-o-matic
HOMEPAGE="http://emboss.sourceforge.net/";
LICENSE="LGPL-2 GPL-2"
SLOT="0"
IUSE="mysql pdf png postgres static-libs X"
DEPEND="
dev-libs/expat
dev-libs/libpcre:3
sci-libs/plplot
sys-libs/zlib
mysql? ( virtual/mysql )
pdf? ( media-libs/libharu )
png? ( media-libs/gd[png] )
postgres? ( dev-db/postgresql:= )
X? ( x11-libs/libXt )"
RDEPEND="${DEPEND}"
if [[ ${PN} == embassy-* ]]; then
EMBASSY_PACKAGE=yes
# The EMBASSY package name, retrieved from the inheriting ebuild's name
EN=${PN:8}
# The full name and version of the EMBASSY package (excluding the Gentoo
# revision number)
EF=$(echo ${EN} | tr "[:lower:]" "[:upper:]")-${PV}
: ${EBO_DESCRIPTION:=${EN}}
DESCRIPTION="EMBOSS integrated version of ${EBO_DESCRIPTION}"
SRC_URI="ftp://emboss.open-bio.org/pub/EMBOSS/${EF}.tar.gz ->
embassy-${EN}-${PVR}.tar.gz"
DEPEND+="
>=sci-biology/emboss-6.6.0[mysql=,pdf=,png=,postgres=,static-libs=,X=]"
S="${WORKDIR}"/${EF}
fi
# @FUNCTION: emboss_src_prepare
# @DESCRIPTION:
# Does the following things
#
# 1. Patches with "${FILESDIR}"/${P}_fix-build-system.patch, if present,
# and eventually runs eautoreconf in autotools-utils
# 2. Patches with "${FILESDIR}"/${PF}.patch, if present
# 3. Applies ${PATCHES[@]} via autotools-utils.eclass
#
emboss-r1_src_prepare() {
if [[ -f "${FILESDIR}"/${P}_fix-build-system.patch ]]; then
mv configure.{in,ac} || die
epatch "${FILESDIR}"/${P}_fix-build-system.patch
fi
[[ -f "${FILESDIR}"/${PF}.patch ]] && epatch "${FILESDIR}"/${PF}.patch
autotools-utils_src_prepare
}
# @FUNCTION: emboss_src_configure
# @DESCRIPTION:
# runs econf with following options.
#
# $(use_with X x)
# $(use_with png pngdriver)
# $(use_with pdf hpdf)
# $(use_with mysql mysql)
# $(use_with postgres postgresql)
# $(use_enable static-libs static)
# --enable-large
# --without-java
# --enable-systemlibs
# --docdir="${EPREFIX}/usr/share/doc/${PF}"
# ${EBO_EXTRA_ECONF}
emboss-r1_src_configure() {
local myeconfargs=(
$(use_with X x)
$(use_with png pngdriver "${EPREFIX}/usr")
$(use_with pdf hpdf "${EPREFIX}/usr")
$(use_with mysql mysql "${EPREFIX}/usr/bin/mysql_config")
$(use_with postgres postgresql "${EPREFIX}/usr/bin/pg_config")
--enable-large
--without-java
--enable-systemlibs
--docdir="${EPREFIX}/usr/share/doc/${PF}"
${EBO_EXTRA_ECONF}
)
[[ ${EMBASSY_PACKAGE} == yes ]] && \
append-cppflags "-I${EPREFIX}/usr/include/emboss"
autotools-utils_src_configure
}
EXPORT_FUNCTIONS src_prepare src_configure
