[gentoo-dev] Last rites: media-tv/tvmovie2vdr

[Joerg Bornkessel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

# Joerg Bornkessel  (16 May 2016)
# Masked for removal. Dead on upstream
# wrt bug 185947
=media-tv/tvmovie2vdr-0.5.13

removal around 16/Jun/2016

- -- 
Joerg Bornkessel 
GnuPG Key: 0x93EB5F4DAA5832A1
Fingerprint: 0E0A A1EE 1DF4 41D7 A3F5  21C2 93EB 5F4D AA58 32A1
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1
Comment: Signed-off-by: Jörg Bornkessel 

iQJ8BAEBCgBmBQJXOh19XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRTBBQTFFRTFERjQ0MUQ3QTNGNTIxQzI5
M0VCNUY0REFBNTgzMkExAAoJEJPrX02qWDKhd8IP+gKfeNrlfpyMCRmnRhCyEAzG
rNTcsRTDCbBAGbj0pyFBvoG9cL39yG2xKTV5fL+u4oy4ExaU2OtvwYqqWi8WADzf
snVU6LkJjTcy5ui0/+HgHj5CrdNQfQIUgwmrMODMbDxYCSWOlGT70chl4nzqXfYA
lZjgkdE0SpbtaBZAGZdfQrXdn2/V+4174M0jLgCf0QgWnngb5mxeEzraeiXxLQ9e
lhUmifnm8yQHbirlAiXREgEmaxV6ZCOMYGheL5AEYIpqpJib5HrdR4DXYtbi2KUH
xu4DjkFtbe5bO7Q6ckuZrMih1KVtiZzGQQ0SlT5HzIFQIfgRiEcuJwUMQTeOKB7f
ElAPBHa1GH5CTlI8aaS3cpWzBzrHkC/4rCLj/VW7df33W4P8Gkf2VCS/Ln/NbMQv
ZkvFxHwWxh6VR9q5XH+wP74g9yXzzKwcrOJOT+tDeI+FjQyGvqXKDlnXau3Ly5/h
1tVwh159MMuQqa90Q8v/wSd/pUJnmHSu3Vhnvn3e0S2M7Rjs1QAW6gp23EAyE9vH
tlZpkq02dMRvJG8oNQA5CqfkwtEbVnTUAbcNc5R89C2x1GsC7uyKnlgyuT6u1dYT
lVCDTnydC2h4k/yw4BCWmwGekhRpxEgR0iSrer8hz5yCoVQQudpr9pYmVYZTGT6E
vbsSyh2+4vX/FYEaUX8J
=h9u3
-END PGP SIGNATURE-

Re: [gentoo-portage-dev] [PATCH] dblink: add locks for parallel-install with blockers (bug 576888)

[Zac Medico]

On 03/14/2016 11:36 AM, Brian Dolbec wrote:
> On Mon, 14 Mar 2016 11:26:23 +0100
> Alexander Berntsen  wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
> 
>> I can't say much more than "ACK, probably makes sense" really. But
>> please test this *a lot* before merging it.
> 
> 
> I ack as well, the code looks good.  I don't know enough about to be
> able to critique it in detail ;).   But it does look decent and the idea
> of what it is doing sounds good.
> 
> 
>> Regarding the merging of this patch, and th egencache patch that has
>> already been released: I thought we agreed that .29 should be *only*
>> the repoman merger, and then bug fixes go into a .30 where we try to
>> get a stable release with the new repoman. Why was egencache merged
>> anyway? Should we not merge repoman to stable ASAP before doing
>> anything else? That would make .29 easier.
>> - -- 
>> Alexander
>> berna...@gentoo.org
>> https://secure.plaimi.net/~alexander
> 
> With a .29 release coming out very soon after the the .28, the .28
> would not get much more testing for the stabilization.  If only the
> repoman code was changed, it makes it easier to know that any bugs
> submitted for .29 that re not repoman specific, apply to .28 as well.
>  But more that if no non-repoman bugs were filed, then that clears .28
>  for stabilization.

Can we merge this now? Feedback from the user who reported the issue is
very positive:

https://bugs.gentoo.org/show_bug.cgi?id=576786#c7
-- 
Thanks,
Zac

Re: [gentoo-dev] Proposal for changes for the next EAPI version

[Luis Ressel]

On Mon, 16 May 2016 18:13:33 +0530
Pallav Agarwal  wrote:

> What I'm suggesting is to add a new function post_install_test. The
> function will run only if the build is being run for stabilization
> (either as a part of automated stabilization, or manual) which can be
> controlled by a USE flag. The function would also require independent
> dependencies in case it uses external applications to test the one
> being built.

Could you please elaborate on this? We already have src_test() for
automated tests. Why would we want to run additional tests after the
package has been merged?

-- 
Regards,
Luis Ressel

Luis Ressel 
GPG fpr: F08D 2AF6 655E 25DE 52BC  E53D 08F5 7F90 3029 B5BD


pgpBC7jG9HFAG.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Montag, 16. Mai 2016, 18:21:27 schrieb Andrew Savchenko:
>
> Everyone can and will make mistakes, this is normal. Only those who
> do nothing make no mistakes. I see no reason why developer should
> be discouraged from contributing for a single blunder. Of course,
> if blunder rate is too high, comrel should take an action; but this
> is not the case here.
> 

Just for the record, this is where qa should step in, not comrel. 

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXOfYWXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnkx8UP/RyUttstbaWVUMiAQ1gZBYeh
Ry93bojoZ+nV/H/vjVOGb6f2X2TtbyOx4c8krm/QekA/pMZCppn1oIpNRRaZdoPN
TB165er/86NzXmoez9Hq5HFVFNbT56SFSyiTTT8uzbn2/phOsWy1FkwRD1Fjs4OA
x9TZgrlFrnfwMlUHhtjbVQTuz0Cn+SYo1HSZ61hV5Y1YLm8MwSWZoS1mRDp65rD/
G5umBuhTHQplBY/ZBdvuR2R8/6/hQQfqI7E7wEj5MvUp98nReJjtYSP3c8WWQYhg
3OeGzyO+USIBGciSXu01ZUGQE4r7XnJ7uiq84wbp1PTVWXYCd8G6tmF7dMzgK8EO
GfCfQuDNIAFgJSzIT0u0D1VltX47kdaWVzpet8qsjP+Ucr4cMvYyaDkrTP7cg0cY
8viaMpG3skVsiDRxRBy/E0mBbl0NxzSehZVxGV9x7f/lfsN8WIIlxID4RfisAWPf
haXtclEKppbK9BdHXrBCYKFOBd0botAjYQhGylhwtnM/22N7v5SaHRezV7qaWYhw
VsQiPht9NCZxkG9yVe/sz1J34YtQ8pB/qG2FJ+A7GQd8fjsay3M75UBQ2AJDLLhf
CUOuyLCfZySMbdCPzPw4XevpMEsADnOMd6bal5uyUxQ2SvFDR0ub04mDf52p81Cd
Qme479L9QJk3gKHzoGBw
=uk3n
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Andrew Savchenko]

On Mon, 16 May 2016 10:05:33 +0100 Ciaran McCreesh wrote:
> On Mon, 16 May 2016 15:56:01 +0800
> Ian Delaney  wrote:
> > As long as this persists and is not intervened to polish and tidy up,
> > g-devs will persist in making innocent, naive or incompetent blunders
> > and run the gauntlet of being publicly scolded over errata. I can only
> > express my view that this style of personal demeaning potentially
> > results in embarrassment, public humiliation and drives community
> > members away from participation. The ultimate negative influence. I
> > would never entertain taking on eclass writing with the incumbent qa
> > member delivering assessments under the title of 'code review' in the
> > style he does.
> 
> If you're writing the kind of code that results in you being subjected
> to scathing criticism for breaking metadata generation for the entire
> tree, then discouraging you from contributing can only be good for the
> distribution...
 
Everyone can and will make mistakes, this is normal. Only those who
do nothing make no mistakes. I see no reason why developer should
be discouraged from contributing for a single blunder. Of course,
if blunder rate is too high, comrel should take an action; but this
is not the case here.



Best regards,
Andrew Savchenko


pgpfYLIkdBuJr.pgp
Description: PGP signature

Re: [gentoo-dev] NEW: split portage/repoman releases now in the tree

[Francesco Riosa]

2016-05-16 3:39 GMT+02:00 Brian Dolbec :

>
> portage-2.3.0_rc1 and repoman-2.3.0_rc1 are now in the tree.
>
> portage-2.3.0_rc1 is essentially the portage 2.2.28 release with only a
> few small patches applied.  It mostly just installs less code, namely
> the repoman code.
>
> So, now servers and other systems that do not require repo Q/A ability
> will no longer get repoman installed anyway.
>
> repoman-2.3.0_rc1 is the stage2 rewrite code. The checks are now
> modular, and using the portage plugin system. The system is not yet
> fully plug and play. Those changes will take place in the stage3
> re-writes.
>
> The two packages will remain in the same portage git repo, although the
> repoman code has been moved into it's own pkg directory.  It is too
> tied into portage api's to be on it's own just yet.  An that
> is not likely to happen until we get a stable portage API.  This new
> system does allow for semi-independant releases for both repoman and
> portage.  When important API's change, it will require both to be
> release at the same time.  So you can look forward to seeing the minor
> version number to get more frequent bumps than it has this last decade.
>
> Currently, the portage ebuild does not RDEPEND on the repoman ebuild.
> You will have to explicitly emerge it for it to be installed. It has
> been suggested to add a use flag enabled RDEPEND (default on) for the
> dev profile.  I will also be adding that to the portage- release
> for all profiles in the coming days.
>
> NOTES:  Repoman now depends on lxml for it's xml parsing and error
> checking along with now using metadata.xsd.  It now will report a lot
> more errors than the previous buggy code everyone has been using.
>
> I want to thank the following people for their help and contributions
> to make these releases:
>
> Zac Medico 
> Alexander Bernsten 
> Dirkjan Ochtman  for the base xml re-write code
> Michal Gorny  for the metadata.xsd changes
> Göktürk Yüksek  for the metadata.xml test ebuilds
> patches.
> Mike Gilbert  for all the testing on the rewite code,
> and a number of gen-b0rk repo test ebuilds.
>
> Coacher for the recent testing, bug reports and patches.
> And anyone else I missed ;)
>
> So, please report any issues with either the ebuilds or installs, bugs,
> etc... you know the drill ;)
>
> Don't forget, please contribute more test case ebuilds to the gen-b0rk
> repo.  The better the test ebuild coverage we have, the better our Q/A
> tools (like repoman) will be and the less often things will be released
> broken.
>
> Thank you
> --
> Brian Dolbec 
>
>
> Thank you Brian and all the persons involved

Re: [gentoo-dev] NEW: split portage/repoman releases now in the tree

[M. J. Everitt]

On 16/05/16 02:39, Brian Dolbec wrote:
> portage-2.3.0_rc1 and repoman-2.3.0_rc1 are now in the tree.
w00t :D
> portage-2.3.0_rc1 is essentially the portage 2.2.28 release with only a
> few small patches applied.  It mostly just installs less code, namely
> the repoman code.
>
> So, now servers and other systems that do not require repo Q/A ability
> will no longer get repoman installed anyway.
>
> repoman-2.3.0_rc1 is the stage2 rewrite code. The checks are now
> modular, and using the portage plugin system. The system is not yet
> fully plug and play. Those changes will take place in the stage3
> re-writes.
Sounds promising :]
> The two packages will remain in the same portage git repo, although the
> repoman code has been moved into it's own pkg directory.  It is too
> tied into portage api's to be on it's own just yet.  An that
> is not likely to happen until we get a stable portage API.  This new
> system does allow for semi-independant releases for both repoman and
> portage.  When important API's change, it will require both to be
> release at the same time.  So you can look forward to seeing the minor
> version number to get more frequent bumps than it has this last decade.
>
> Currently, the portage ebuild does not RDEPEND on the repoman ebuild.
> You will have to explicitly emerge it for it to be installed. It has
> been suggested to add a use flag enabled RDEPEND (default on) for the
> dev profile.  I will also be adding that to the portage- release
> for all profiles in the coming days.
'repoman' use flag for portage? something I'll need to add, since I
don't make (proper) use of profiles ..
> NOTES:  Repoman now depends on lxml for it's xml parsing and error
> checking along with now using metadata.xsd.  It now will report a lot
> more errors than the previous buggy code everyone has been using.
Uh-oh, breakage alert .. you mean repoman now enforces more rules, I
like .. :D
> I want to thank the following people for their help and contributions
> to make these releases:
>
>   Zac Medico 
>   Alexander Bernsten 
>   Dirkjan Ochtman  for the base xml re-write code
>   Michal Gorny  for the metadata.xsd changes
>   Göktürk Yüksek  for the metadata.xml test ebuilds
>   patches.
>   Mike Gilbert  for all the testing on the rewite code,
>   and a number of gen-b0rk repo test ebuilds.
>   
>   Coacher for the recent testing, bug reports and patches.
>   And anyone else I missed ;)
>
> So, please report any issues with either the ebuilds or installs, bugs,
> etc... you know the drill ;)
>
> Don't forget, please contribute more test case ebuilds to the gen-b0rk
> repo.  The better the test ebuild coverage we have, the better our Q/A
> tools (like repoman) will be and the less often things will be released
> broken.
>
> Thank you
Great job to Brian and all the other contributors! Keep up the good work.

Did we find a mechanism to trap updates to the EAPI not being in sync
with portage updates necessarily (I found an edge case bug #577546 - zac
has already given some useful thoughts)?

MJE



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Proposal for changes for the next EAPI version

[Pallav Agarwal]

Hi,
I am a student selected for GSoC 2016. One of the things in my proposal
requires the ebuilds to carry a mechanism to test the built software by
running some script provided by the maintainer of the ebuild.
This would be basically similar to whatever tests an Arch Tester would do,
however made easier by the fact that it would be written by the maintainer.
This could be to test whatever bug the ebuild fixes, or the basic
functionality of the software. This would help to automate the
stabilization of the built packages (which my project on
continuous stabilization wishes to accomplish).

What I'm suggesting is to add a new function post_install_test. The
function will run only if the build is being run for stabilization (either
as a part of automated stabilization, or manual) which can be controlled by
a USE flag. The function would also require independent dependencies in
case it uses external applications to test the one being built.

I wanted to know other opinions on this matter.

Thanks,
Pallav Agarwal

Re: [gentoo-dev] NEW: split portage/repoman releases now in the tree

[Sam Jorna]

On Sun, May 15, 2016 at 06:39:22PM -0700, Brian Dolbec wrote:
> 
> portage-2.3.0_rc1 and repoman-2.3.0_rc1 are now in the tree.
 
> I want to thank the following people for their help and contributions
> to make these releases:
> 
>   Zac Medico 
>   Alexander Bernsten 
>   Dirkjan Ochtman  for the base xml re-write code
>   Michal Gorny  for the metadata.xsd changes
>   Göktürk Yüksek  for the metadata.xml test ebuilds
>   patches.
>   Mike Gilbert  for all the testing on the rewite code,
>   and a number of gen-b0rk repo test ebuilds.
>   
>   Coacher for the recent testing, bug reports and patches.
>   And anyone else I missed ;)

Thank you to everyone involved! :)

-- 
Sam Jorna
GnuPG Key: D6180C26


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: bugfix for get-flag()

[rindeal]

> [Looks like your mailer is broken. All the tabs in your patch have
> been mangled and appear as spaces.]
>
>> +   # reverse loop
>> +   set -- ${!var}
>> +   local i=${#}
>> +   while [[ ${i} > 0 ]] ; do
>> +   local arg="${!i}"
>
> Using the positional parameters looks needlessly complicated here.
> Why not use an array, like this (untested):
>
> local -a flags=(${!var})
> for (( i=${#flags[@]}-1; i>=0; i-- )); do
>
> Below you can use ${flags[i]} instead of ${arg} then.

Done.

I've also changed comments and added examples section to docs.

So this is what it looks like now:

diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
index e0b19e9..217d33b 100644
--- a/eclass/flag-o-matic.eclass
+++ b/eclass/flag-o-matic.eclass
@@ -534,18 +534,26 @@ strip-unsupported-flags() {
 # @USAGE: 
 # @DESCRIPTION:
 # Find and echo the value for a particular flag.  Accepts shell globs.
+#
+# Example:
+# @CODE
+# CFLAGS="-march=i686 -O1"
+# get-flag -march # outputs "-march=i686"
+# get-flag march  # outputs "i686"
+# get-flag '-O*'  # outputs "-O1"
+# @CODE
 get-flag() {
-   local f var findflag="$1"
-
-   # this code looks a little flaky but seems to work for
-   # everything we want ...
-   # for example, if CFLAGS="-march=i686":
-   # `get-flag -march` == "-march=i686"
-   # `get-flag march` == "i686"
+   local var pattern="${1}"
for var in $(all-flag-vars) ; do
-   for f in ${!var} ; do
-   if [ "${f/${findflag}}" != "${f}" ] ; then
-   printf "%s\n" "${f/-${findflag}=}"
+   local i flags=( ${!var} )
+   for (( i=${#flags[@]}-1; i>=0; i-- )) ; do
+   local needle="-${pattern#-}" # force dash on
+   local haystack="${flags[i]%%=*}" # we're comparing flags, not values
+   if [[ ${haystack##${needle}} == '' ]] ; then
+   # preserve only value if only flag name was provided
+   local ret="${flags[i]#-${pattern}=}"
+   # ${ret} might contain `-e` or `-n` which confuses echo
+   printf '%s\n' "${ret}"
return 0
fi
done

[gentoo-dev] Re: USE flag proposal: memcached

[Dirkjan Ochtman]

On Sat, May 14, 2016 at 5:19 PM, Dirkjan Ochtman  wrote:
> I suppose the description can just be "Enable memcached support".

I went ahead and committed a slightly modified description to
use.desc. I also filed bugs against lighttpd (583158) and gearmand
(583160) to rename their flags from memcache to memcached. Anything
else to do here?

(Sorry if this is maybe slightly quick after the initial announcement;
it seemed like there was little discussion here, and today is a day
off so I have some time to do stuff...)

Cheers,

Dirkjan

[gentoo-dev] eclass/vdr-plugin-2.eclass EAPI=6 changes, plz review

[Joerg Bornkessel]

Hallo,
after my last commit disaster,
i bring my changes to review before i break some things again.

- Added changes to make it work with eapi=6
- removed some unneeded code parts (never they was used in any
ebuilds, i though they was integrated to make the eclass more
flexibel,...)


-- vdr-plugin-2.eclass 2016-05-15 22:03:21.807417485 +0200
+++ vdr-plugin-2.eclass.new 2016-05-15 22:01:10.0 +0200
@@ -1,4 +1,4 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2016 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Id$

@@ -90,7 +90,7 @@
 # @CODE

 # Applying your own local/user patches:
-# This is done by using the
+# This is done by using the
 # (EAPI = 4,5) epatch_user() function of the eutils.eclass,
 # (EAPI = 6) eapply_user function integrated in EAPI = 6.
 # Simply add your patches into one of these directories:
@@ -104,10 +104,7 @@
 inherit flag-o-matic toolchain-funcs unpacker

 case ${EAPI:-0} in
-   4|5)
-   ;;
-   6)
-   ewarn "EAPI 6 support for test purpose only, plz report bugs to
v...@gentoo.org"
+   4|5|6)
;;
*) die "EAPI ${EAPI} unsupported."
;;
@@ -156,6 +153,7 @@
 #  EBUILD=${CATEGORY}/${PN}
 #  EBUILD_V=${PVR}
 #  EOT
+#  obsolet? fix me later...
{
echo "VDRPLUGIN_DB=1"
echo "CREATOR=ECLASS"
@@ -232,6 +230,7 @@
#sed -i Makefile \
#   -e "s:^DVBDIR.*$:DVBDIR = ${DVB_INCLUDE_DIR}:" \
#   -e 's:-I$(DVBDIR)/include:-I$(DVBDIR):'
+   # obsolet? fix me later...

if ! grep -q APIVERSION Makefile; then
ebegin "  Converting to APIVERSION"
@@ -289,7 +288,7 @@
 linguas_support() {
 #  Patching Makefile for linguas support.
 #  Only locales, enabled through the LINGUAS (make.conf) variable will be
-#  "compiled" and installed.
+#  compiled and installed.

einfo "Patching for Linguas support"
einfo "available Languages for ${P} are:"
@@ -311,12 +310,9 @@
 vdr_i18n() {
 #  i18n handling was deprecated since >=media-video/vdr-1.5.9,
 #  finally with >=media-video/vdr-1.7.27 it has been dropped entirely
and some
-#  plugins will fail to "compile" because they're still using the old
variant.
+#  plugins will fail to compile because they're still using the old
variant.
 #  Simply remove the i18n.o object from Makefile (OBJECT) and
 #  remove "static const tI18nPhrase*" from i18n.h.
-#
-#  Plugins that are still using the old method will be pmasked until
they're
-#  fixed or in case of maintainer timeout they'll be masked for removal.

gettext_missing

@@ -391,6 +387,7 @@

# Plugins need to be compiled with position independent code,
otherwise linking
# VDR against it will fail
+   # depricated if fi, as we have only >=vdr-2 in the tree, fix me
later...
if has_version ">=media-video/vdr-1.7.13"; then
append-cxxflags -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE
fi
@@ -500,7 +497,9 @@
die "vdr-plugin-2_src_prepare not called!"
fi

-   [[ ${PATCHES[@]} ]] && epatch "${PATCHES[@]}"
+   [[ ${EAPI} == [45] ]] && [[ ${PATCHES[@]} ]] && epatch "${PATCHES[@]}"
+   [[ ${EAPI} == "6" ]] && [[ ${PATCHES[@]} ]] && eapply "${PATCHES[@]}"
+
debug-print "$FUNCNAME: applying user patches"

vdr-plugin-2_src_util prepare
@@ -522,14 +521,12 @@
fi
cd "${S}"

-   BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-all }}
-   emake ${BUILD_PARAMS} \
-   ${BUILD_TARGETS} \
-   LOCALEDIR="${TMP_LOCALE_DIR}" \
-   LOCDIR="${TMP_LOCALE_DIR}" \
-   LIBDIR="${S}" \
-   TMPDIR="${T}" \
-   || die "emake failed"
+   emake all ${BUILD_PARAMS} \
+   LOCALEDIR="${TMP_LOCALE_DIR}" \
+   LOCDIR="${TMP_LOCALE_DIR}" \
+   LIBDIR="${S}" \
+   TMPDIR="${T}" \
+   || die "emake all failed"
;;
esac

@@ -570,12 +567,11 @@

local SOFILE_STRING=$(grep SOFILE Makefile)
if [[ -n ${SOFILE_STRING} ]]; then
-   BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install }}
-   einstall ${BUILD_PARAMS} \
-   ${BUILD_TARGETS} \
-   TMPDIR="${T}" \
-   DESTDIR="${D}" \
-   || die "einstall (makefile target) failed"
+   emake install \
+   ${BUILD_PARAMS} \
+   TMPDIR="${T}" \
+   DESTDIR="${D}" \
+   || die "emake install (makefile target) failed"
else
dev_check "Plugin use still the old Makefile handling"
insinto "${VDR_PLUGIN_DIR}"
@@ -609,9 +605,14 @@
create_header_checksum_file ${vdr_plugin_list}
create_plugindb_file ${vdr_plugin_list}

-   local docfile
-   for docfile in README* HISTORY CHANGELOG; do
-   [[ -f ${docfile} ]] && dodoc ${docfile}
+   local commondoc=( README* HISTORY CHANGELOG )
+   for docfile in "${commondoc[@]}"; do
+   if [[ ${EAPI} == "6" ]]; then
+   local DOCS="${DOCS} ${docfile}"
+   

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ciaran McCreesh]

On Mon, 16 May 2016 15:56:01 +0800
Ian Delaney  wrote:
> As long as this persists and is not intervened to polish and tidy up,
> g-devs will persist in making innocent, naive or incompetent blunders
> and run the gauntlet of being publicly scolded over errata. I can only
> express my view that this style of personal demeaning potentially
> results in embarrassment, public humiliation and drives community
> members away from participation. The ultimate negative influence. I
> would never entertain taking on eclass writing with the incumbent qa
> member delivering assessments under the title of 'code review' in the
> style he does.

If you're writing the kind of code that results in you being subjected
to scathing criticism for breaking metadata generation for the entire
tree, then discouraging you from contributing can only be good for the
distribution...

-- 
Ciaran McCreesh

Re: [gentoo-dev] NEW: split portage/repoman releases now in the tree

[Dirkjan Ochtman]

On Mon, May 16, 2016 at 3:39 AM, Brian Dolbec  wrote:
> repoman-2.3.0_rc1 is the stage2 rewrite code. The checks are now
> modular, and using the portage plugin system. The system is not yet
> fully plug and play. Those changes will take place in the stage3
> re-writes.

Thanks for working on this, it sounds great!

Cheers,

Dirkjan

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Aaron Bauman]

On Monday, May 16, 2016 3:56:01 PM JST Ian Delaney wrote:
> On Sat, 14 May 2016 21:04:17 -0400
> Rich Freeman  wrote:
> 
> I hope I won't regret this
> 
> > On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman  wrote:
> > > On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:
> >  [...]
> >  [...]
> >  [...]
> >  
> > > Applying that same rationale, it would be unfair to say that an
> > > undescribed level of professionalism in communication is required
> > > as well.  Nothing here violates the CoC.
> 
> No but it violates elements simply lot listed in the CoC. DO we need a
> better CoC?
> 

Apparently we do, because people will continue to find ways to complain about 
words and feelings.

> This undescribed level of professionalism is presumed assumed
> knowledge, or 'understood', however the evidence suggests it is FAR
> from 'understood'.
> 

No, everyone just has a different tolerance for words that hurt or don't hurt.  
Perceived intentions or the tone of a person behind a computer really doesn't 
matter to most. 

> Here is a point worth highlighting.  While I find the language used to
> deliver the message an affront to my social senses, b-man does not and
> deems it apt to the situation. Herein therefore lies the dilemma.
> Being a communication instance, there are no clear rights or wrongs,
> but pure shades of grey. There are forms that most find fine and other

Next on bookshelves we will have "50 shades of Gentoo"... who is ready?!

> most find a violation of social etiquette. The result is that this
> style of submissions and responses re issues over QA are tacitly
> accepted as valid and therefore endorsed. There is at least one other
> dev in high authority who has all but ticked the message as justified
> in the circumstances, while in other instances has placed a cross to
> the same dev's reply in a separate thread.
> 
> This is predominantly why I refrain from sticking my neck out over
> this type of issue. Inevitably, by weight of numbers in the community,
> there will be someone who will vehemently reject and counter the point
> posed and attempt to shout it down as tripe. The point will be lost, or
> at least diluted to a meaningless mush.
> 

I appluad your efforts to ensure that the social aspect of Gentoo is a 
pleasant one.  The bottom line is that nothing wrong was said in this 
instance.

> > If you're only able to behave in a professional manner if the
> > standards of professionalism are explicitly spelled out, I think
> > you're missing the point.
> > 

Again, people come from various backgrounds and ideals so maybe it should be 
spelled out?  That is completely unfeasible though hence the new book...

> > Ultimately it is an attitude.  When you point out a mistake make it
> > either about:
> > 1.  Helping the person who made the mistake to improve because you
> > want to see them make better contributions (which they aren't going to
> > do if you drive them off).
> > 2.  If you feel that somebody simply isn't going to cut it, then by
> > all means report them so that their commit access can be revoked.
> 

I would prefer a simple "seriously" email vice a report to QA and the 
revocation of my commit access.

> rich0 here has hit the target a bullseye. The underlying attitude in
> the initial post displays a belief of justification and entitlement to
> 'shout down' the colleague and treat him with disdain over the blunder.
> This is NOT a bootcamp with paid drill sargeants.
> 
> As long as this persists and is not intervened to polish and tidy up,
> g-devs will persist in making innocent, naive or incompetent blunders

blunder: "a stupid or careless mistake."  Are you redefining the word here or 
just calling the original violation stupid?  Because that would seriously hurt 
some feelings.  Semantics... what a condundrum.

> and run the gauntlet of being publicly scolded over errata. I can only
> express my view that this style of personal demeaning potentially
> results in embarrassment, public humiliation and drives community
> members away from participation. The ultimate negative influence. I
> would never entertain taking on eclass writing with the incumbent qa
> member delivering assessments under the title of 'code review' in the
> style he does.
> 

Thankfully someone is doing it.  If you choose not to contribute, out of fear 
of an individual behind a computer, you should reevaluate why you are doing 
this.

> It is clear he has learned that he is not only entitled but expected to
> shout at folk for misdemeanours. hasufell also believed this, and
> scoffed when I suggested to him directly one never needs to shout, but
> rather speak in tempered moderate terms.
> 
> Try it some time mgorny. The sky will not cave in.
> 

Entitlement and privilege.  The true essence of this whole problem.  No one 
here wants to feel as though someone else is better or superior to them.  I 
can only imagine though, that people believe 

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Consus]

On 15:56 Mon 16 May, Ian Delaney wrote:
> On Sat, 14 May 2016 21:04:17 -0400
> Rich Freeman  wrote:
> 
> I hope I won't regret this
> 
> > On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman  wrote:
> > > On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:  
> >  [...]  
> >  [...]  
> >  [...]  
> > >
> > > Applying that same rationale, it would be unfair to say that an
> > > undescribed level of professionalism in communication is required
> > > as well.  Nothing here violates the CoC.
> > >  
> > 
> 
> No but it violates elements simply lot listed in the CoC. DO we need a
> better CoC?

You need a better pair of balls; there is a chance that you will stop
getting offended by random emails.

[gentoo-dev] Re: [PATCH] flag-o-matic.eclass: bugfix for get-flag()

[Ryan Hill]

On Sun, 15 May 2016 21:35:41 +0200
rindeal  wrote:

> apart from the tests, the patch now looks like this:

Please posts the tests too.

-- 


pgpudg4Ys0VCN.pgp
Description: OpenPGP digital signature